Network Services deployments in Data Centers

Application Delivery controllers are already part of the many data centers where there are multiple servers to serve the content to end users. ADCs balance the incoming connections to multiple servers for high availability and also to ensure that load is shared.

Let us see where they fit in the data center architectures as listed in here. 

You might have heard the term 'Network Services Layer'.  This particular area contains network security devices, ADCs and WAN optimization devices.  Many traditional data centers don't have this layer, but newer data centers have this layer.  This layer works in conjunction with Core switching layer. 

Core switches are expected to be configured to pass the selective traffic to network services layer.  There is no change expected in access switch layer or SAN switch layer.  One can have security at these layers too for additional security,  but I guess it will be some more time before data center administrators add any additional security at access level.

Before getting into the details of capabilities of core switches, devices in network switch layer,  let us first visit the addressing of typical data centers:

Many time private IP addresses are used for servers.  Though public IP address can be assigned to server(s) if there is only one for a domain name or in case of DNS load balancing, it is my observation that many times only private IP addresses are assigned.  There are several reasons:

•  If there is a need in future to expand to multiple servers due to load or high availability considerations,  no changes would be necessary except for some configuration in ADCs and bring up new server (or virtual machine).
• Many times, servers need to communicate with other internal servers such as database servers, SANs, application servers etc.. .   Private network gives comfort of security as well as reduce the need for number of public IP addresses.
• For a given domain name,  multiple services may need to be exposed.  Also, for each service, different physical server or different virtual machine may be required.  Private IP addressing with ADCs translating to right private IP address on incoming connections help in facilitating this. If public IP address is used, then all services need to be put in same physical server or virtual machine.

Typically private centers have one domain name and multiple services. Public data centers have multiple domain names and multiple services in each domain.  Each domain name + service name combination may contain multiple servers serving the content/users.    You might have heard term called server farm.  A given server farm is identified by  IP address (resolved IP of domain name ) and Service (Ex: Port 80, 25 etc..). Server farm is configured with IP addresses of real servers serving the content.  ADCs do this job of selecting the least loaded server dynamically upon receiving client connection and awards the connection to selected real server.  In recent times, real servers are subdivided into multiple subsets and each server farm provides additional configuration (rules) to select the subset.  Then least loaded server is selected from this subset.  One example deployment may put  all videos, images and static content  in some servers (set1) and other servers serve the dynamic content (set2).   ADCs can be configured with rules to select set1 for URL containing some file extensions and set2 for everything else. I hope server farm concept is clear.

It is important to understand how ADCs are deployed first:

Small data centers don't have two tier architecture of switches. Jut a simple ADC is good enough. This acts as switch as well as Load balancer.  ADCs have L2 switch and one or more Ethernet MACs.  Ethernet MACs are connected to the network that gets connected to the WAN links and servers get connected to the L2 switch. Basically, in simple deployments ADC acts as access layer switch on server side and Core router/switch on the core network side.  Let us call this as 'simple data center'.

In complex data centers or in public data centers, two tier architectures are required. In this case, core switches are configured to pass the traffic coming from core network to the ADCs and traffic from server network to ADCs for load balancing purposes.  Traffic from server network might go to ADCs without any special configuration in core switches if the client to server packets were translated with SNAT. Due to this SNAT,  server to client traffic will have DIP as the ADC ip address and hence packets will go to ADCs without any special configuration in the core switches. Data centers are complex because it needs to handle large amount of traffic and/or has large number of server farms.  Due to this, some times one ADC may not be enough to take the load of all server farms.  Multiple ADC devices are used in those cases with each ADC handling traffic belonging to few server farms.  In these cases, core switches are expected to provide facilities to segment the traffic on server farm basis and redirect the traffic to ADCs for balancing the traffic across servers within server farm.  To give an example:  If a data center has 100 server farms and 10 ADCs, then the core switch should have capability of segmenting the traffic 100 ways and passing 10 sets of traffic to appropriate ADCs.   This is typically achieved via VLANs.  

As discussed above each server farm is identified on incoming traffic (from core network) by public IP address (resolved IP of domain name) and the port.  If there are 100 server farms, then 100 VLAN IDs are required.  Core switches can be configured to generate VLAN ID based on the incoming traffic.  Core switches have this capability called 'rules'.  Rule can be created with selectors (in this case destination IP and destination port) and action as 'redirect' with VLAN ID and Port on which to transmit.  Switches, when the traffic matches with this kind of rule, adds VLAN ID to the packet and transmits the packets on the port indicated in the rule.

Let us take an example of public data center.  Let us assume that there are two domain names - www.example1.com (P1 public IP address) and www.example2.com (P2 public IP address)   www.example1.com has two services - Port 80 and Port 25.   www.example2.com has one one service - Port 80.   Example1 company wanted four servers - P11, P12, P13, P14 to serve Port 80 content and 1 server for Port 25.  Example2 has two servers P21 and P22 to server port 80 content.  It was decided to use ADC1 and ADC2 with ADC1 handling two server farms of www.example1.com and ADC2 handling www.example2.com server farm.   Let us also assume that ADCs are deployed in two-arm mode.  On one arm it expects client-to-traffic to land and another arm it expects server to client traffic land.  Let us assume that VLAN11 and VLAN12 are for client and server traffic of www.example1.com. And VLAN21 and VLAN22 are for client and server traffic of www.example2.com.  Let us also assume that two physical ports PR11 & PR12 and PR21 & PR22 are used to connect to ADC1 and ADC2 respectively. 

In above deployment, core switch cluster is expected to be configured with following rules:

• On ports that are towards the Internet:
• Source IP : ANY  Destination IP: P1  Destination Port : 80 or 25 --------> Add VLAN11 and send on PR11.
• Source IP : ANY Destination IP: P2  Destination Port : ANY --------> Add VLAN21 and send on PR21.
• On ports that are toward the Servers
• Source IP:  P11 Subnet,  Destination IP: ANY, Source Port 80, 25 ----> Add VLAN12 and send on PR12.
• Source IP:  P21 Subnet,  Destination IP: ANY -------> Add VLAN22 and send on PR22.

ADCs/Server load balancing devices would need to have capability to instantiate VLAN interfaces based on VLAN ID.

Network Security Devices and WAN Optimization devices also can be deployed in similar way.  It is good if all functions are available in the same device. This would only require one set of VLAN configuration in the switch. If  these devices are independent to each other, then switch need to configure multiple VLANs to pass traffic from one device to another via switch.  If routing is allowed, then the one device can have route to another device and switch will pass the traffic from one system to another as any switch do. 

In above example, ADC1 is handling two server farms. But it is also possible to divide these two servers across two different ADCs even though they belong to same domain. As long as service is different, it should be possible.  It is also possible to use one ADC for multiple domain names too.  In this case, ADCs or network security devices provide 'virtual instance' to ensure that traffic of two different domain names are independent and isolated. I am too lazy to type in the configuration required on switches for these two configurations, but I think you got the picture :-)

Data Center Switch requirements for new Data Center Architectures

Traditionally data centers have three tiers of switches -  Core switches,  Aggregate switches and Access switches.

• Core Switches :  These switches connect to the network which are connected to the WAN links. This is farthest switch farm with respect to servers.
• Access Switches :  These switches are also called top-of-rack switches.  Servers (Web Servers, Email Servers, Application Servers, Database Servers and others for which data center is built) get connected to the ports of these switches. 
• Aggregation Switches:  Aggregation switches is intermediate switch layer which is sandwiched between Core and Access switch layers.  Aggregation switch aggregates the traffic between core and access layers.  Note that there could be lot of traffic among servers (Specifically among application, web and database servers). This traffic need not be seen by the core switches.  This traffic just need to be among the access layer switches.  Aggregation layer eliminates the traffic being seen by every switch.  Core switches only see the traffic going to/coming from WAN/Corporate network.  Aggregation layer also reduces the traffic among access layer switches.

It was necessary to have three tiers in earlier data center architectures due to

•  Large number of physical machines serving the content requires large number of Ethernet ports.  Due to poor density of the ports on the switches, multiple access layer switches were necessary. Multiple switches means there is lot more traffic across access layer switches. One more hierarchy of switches enable good throughput by eliminating mesh kind of access layer switches for intra switch traffic.

What are some of the changes in Data Centers? One big change is collapse of three tiers to two tiers. Aggregation layer is disappearing.  Let us see what is making this change.

• Virtualizaton technology is reducing the number of physical machines:  This implies that there are less number of ports.
• Traffic on each port is increasing : Virtualization and Mulitcore processor are enabling multiple applications in one physical machine.  It is not uncommon to see the requirement of multi-gig traffic on a single port.
• 10G and in future 40G/100G ports are facilitating the unified fabric for both kinds of traffic - Application traffic and SAN traffic, thus eliminating number of ports and interconnects.

These technologies are reducing the cost by reducing equipment, interconnects, by amount of power required and amount of cooling required. It also reduces the maintenance and hence reduction in cost.

What kind of features one would expect in the switches in new data centers:

• Latency of traffic should be very less:  By eliminating the aggregation layer itself reduces the latency. But that is not good enough for SAN traffic, Video and Voice workloads.  Non-blocking switching or cut-through switching is expected to support real time traffic such as Video, Voice etc..   Traditionally, switches oversubscribe the bandwidth, that is, switches are not capable of receiving and transmitting of traffic of all ports at the same time with full port bandwidth. Hence the packets get blocked.  In non-blocking switches,  they are expected to send and receive traffic equal to number ports * each port bandwidth.  If there are ten 1G ports, switches are expected to receive 10G traffic and send 10G traffic.  
•  802.1qbb (Priority based Flow Control):  When there is a congestion in the receiving node, 802.3x pause frame is generated normally. This makes all the traffic pause for some time. This standard allows pause frame generation on 802.1p priority levels. It lets the high priority traffic flow. Switches are expected to honor and generate theses kinds of frames.
• 802.1qaz (Enhanced Traffic Selection):  This standard allows the bandwidth allocation for different priority levels or group of priority levels.  It lets higher priority bandwidth to be consumed lower priority traffic if there is no higher priority traffic.  SAN traffic would need to be going with higher priority levels. This feature is also expected to be supported by data center switches.
• 802.1qau (Congestion Notification):  This standard allows end nodes to communicate the congestion notification.  It lets the end node receiving the congestion notification to apply rate limiting on the out traffic.  This feature is also expected to be supported by data center switches.
• Port Density should be high.
• Multi-Path support is required - I am not sure whether there are any standard at this time, but spanning tree is not used in these cases as it only provides one path. 
• VEPA Support would be required eventually. Due to VEPA,  it may need to support C-VLAN and P-VLANs.
• Large number of VLANs support is required to work with other network services such as ADCs, WAN Optimization and Network Security (Firewall, IPS, IPSec VPN etc..). 
• Ability to redirect the traffic not only based on L2 and L3 fields, but also L4 fields such as TCP, UDP Source and destination ports. 
• Any switch architecture should work with VM migration from one physical server to new physical server.
• Public Data Center networks require Virtual Instance kind of concept within the switches to reuse VLANs (across different subscribers) due to limited number of VLAN IDs.  

IPv6 deprecates NAT that is popular in IPv4 world - Is this really true?

I am not sure though.  There is no doubt that there are large number of IP addresses available in IPv6 world.  Though NAT was started due to the IPv4 address resource exhaustion, it has been used for many other purposes such as

•  Avoid renumbering of the majority of network in corporations when they change their service provider or when the companies get merged.  When the service provider is changed or companies get merged, only few devices such as routers,  firewalls & NAT devices , IPSec VPN devices and Server such as DNS need to be updated.  Rest of the network addressing can remain same as NAT devices front end the network to external world.
• When corporate networks have multiple ISP connections,  two scenarios are possible - There is load balancing of connections across multiple ISP connections and failover of connections to other ISP network in case of failure of primary ISP connection.  In both cases,  in IPv4 world, NAT devices take care of balancing and routing the traffic to appropriate ISP connections, that is, end hosts are not aware of this. End hosts are always assigned with fixed private IP addresses and NAT device takes care of translating those addresses with IP address of the ISP connection on which the packets are going to be transferred to.  In case of IPv6 network, without NAT support, each end host should take care of this on their own. This may be possible when every host runs routing protocol, but not sure whether it is practical.  By doing NAT in IPv6 world, this would be similar to IPv4 world and the burden of balancing and failing over the connection resides with NAT devices.
• Security by obscurity is one another thing IPv4 NAT is providing which will be lost in IPv6 if every end host communicates with the external world on its own.

To me, above problems can be solved in some fashion or other such as Provider Independent IP addresses. This might increase the burden on the Internet core routers as there would be large number of routes. Though at this time, I am not sure whether this is practical, but I am sure some solution would be found.

But main reason I would believe NAT would continue to exist is due to Server Load balancing devices (And ADC devices).   SLB devices are expected to find out the least loaded server and award the connection to that server.  It is expected that connections are destined to one IP address (This IP address is called Virtual IP address) and server identifies the least loaded real server and redirects the connection to that server. Redirection of the connection typically involves Destination NAT where the DIP of the original connection packets are replaced with the real server IP address and vice versa on SIP (Source IP) for packets going from real server to client.  Also to ensure that the packet from the server passes through the same SLB device, source NAT is also applied with 'source IP' replaced with IP address of SLB device.  Since 'source IP' seen by real server is same even though connections came from multiple clients, there is a possibility of two different clients using the same source port. Hence source port translation is also required at the SLB device.  Due to this, I believe all considerations which are applicable for IPv4 NAT are valid here in Ipv6 world too.

One can say that there are other alternatives to address translation such as DNS based load balancing where different DNS requests are given with different real server IP addresses. But this is not accurate and there is a possibility of some real servers getting loaded more than others.  Another solution that can be suggested is to do only MAC translation.  Though this works, but it works only if both SLB device and real servers are on the same link.
Due to limitations on different approaches, Load balancing with NAT would continue to be required in many deployments.  So, don't rule out NAT even when we all move to IPv6.

If you believe I am wrong here, please drop a comment.

Validity of performace metrics?

Many security appliance vendors and ADC vendors provide performance metrics with respect to throughput and connection rate. But if you look deeply, none of these metrics are valid for actual deployments. At most, they are useful for developers to identify the bottlenecks in the software.

If you look at closely, throughput numbers are given with UDP traffic directed to some arbitrary port. Connection rate is given with respect to number of TCP connection establishments (3 way handshake) and termination by TCP RST packet. None of these are real deployment scenarios. How much of traffic is really UDP in real world? How many connections are really TCP with just connection establishment? How often the connections are terminated by TCP RST packets. So, the numbers being given by device vendors are useful for themselves to figure out the device or software bottlenecks.  But these are not sufficient to make end users to relate to their networks and traffic.

Many security devices and ADCs have application protocol capabilities.

• Firewall devices have ALGs (Application Level gateways) for each complex protocol to open holes in the firewall for dynamic data connections. Examples: FTP, SIP, MGCP, H.323, RTSP, DNS, L2TP, PPTP etc..
  
• IPS devices have application intelligent protocols. Similar examples as firewall.
• Anti Virus functionality typically implements proxies to collect the data for scanning. Example proxies: HTTP, HTTPS, FTP, SMTP, PoP3, IMAP etc..
• URL content filtering feature not only interprets HTTP protocol data, but also does quite a bit of content matching (regular expression search).
  
• ADC devices also contain application protocols such as HTTP, HTTPS, FTP, SIP, RTSP etc..

It is fair to expect the throughput and connection rate for all application protocols which are supported by the device.

Connection rate should not only involve TCP connection establishment, but also should have the data that is normally interpreted by the device. In addition, the size of data is reasonable. It is true that the size of data can be different in different deployments, but using some reasonable size for data during connection establishment is required.

Throughput numbers are also expected to be given with respect to application protocols. Whatever size of the data is chosen should be clearly documented. My suggestion to device vendors to give throughput numbers for different sizes of protocol data. Another aspect  is number of connections used in throughput measurements. I observed that device vendors use very less number of connections with large amount of data to get the best numbers. They do give good numbers as most of the connection state information resides in the cache. Any medium sized deployment would have more than few thousand of connections going through simultaneously.  So,  it would be good if device vendors give throughput numbers with large number of sessions.

So, don't go by marketing numbers. Ask for more performance data with respect to applications, number of flows etc.. You would be surprised to see the difference in results. Really..

Application Delivery Controllers versus Server Load balancing devices

Server Load Balancing (SLB):

Let us first revisit the "Server Load balancing" concept and its features. Server Load balancing was invented during initial stages of web in late 1990 and early 2000s. At that time the pages served were mostly static. So simple Layer4 load balancing was good enough to do balancing of TCP connections across multiple servers in the server farm. Load balancing device, typically, is assigned with Public IP address. When client connection lands on this public IP address, this device figures out the best server that can serve the connection and hands over the connection to the server by doing "Destination NAT", that is, destination IP address of remote client generated packets gets translated with IP address of server selected. To ensure that packets going to client from server are accepted by the client, response packets from the server would undergo source IP address translation. By this clients only see the public IP address in response packets. Now, let us discuss some SLB features.

• MAC Level redirection : When servers in the server farm have public IP address, this option can be used instead of doing "Destination NAT". Server Load balancing (SLB) device should be placed in the traffic path to ensure this mode works. In this mode, SLB device selects the server in the farm and modifies the destination MAC address with the server MAC address. Optionally it can also change the Source MAC with the SLB device MAC.
  
• Additional Source NAT : This mode is useful in assymetric routing topologies. When destination NAT is done on the client packets, it is required to do source IP translation on server to client traffic. For this to happen, server to client traffic must pass through the same SLB device that did the DNAT on the client traffic. Source NAT is done on the client traffic with the SLB device IP address to ensure that the traffic come to the SLB device even if the servers' routing tables are configured with some other default gateway.
  
• Multiple different algorithms to select the server: Based on SLB deployment and need, several different ways of scheduling connections to server can be chosen. Following are some of the methods.
  

• Round Robin : Each server is treated same from capability perspective and servers are chosen on round robin fashion. If there are 2 servers in the server farm, then alternate connections are given to each server.
  
• Weighted Round Robin : Typically each server is given a weight 1 to 10, 10 is assigned to server that can serve 10 connections for every 1 connection served by server that has weight 1. Until weight number of consecutive connections are assigned to a server, next server is not chosen.
  
• Least Connections : In both Round robin and Weigthted round robin methods, it is assumed that the all connections are almost equal with respect to duration of connection, amount of traffic that is sent on each connection and processing power used by each connection on the server. But in reality it is not true. In 'Least Connection' method new connections is given to server which is serving least number of connections at that time. SLB device maintains the count of active connections with each server to facilitate this scheduling.
  
• Weighted Least Connections : All servers can't be assumed to be equally powerful and this feature allows deploying servers of different processing power capabilities. Each server can be given a weight. If 2 and 5 weights are given to server 1 and server2, it means that server2 is powerful enough to serve 5/2 times the active connections simultaneously than server1. SLB device keeps this weight in mind in deciding the best server for new connections.
  
• Fastest Response time : Though 'Least connections' and 'Weighted Least connections' do their best to distribute the connections, there can be situations where many high processing connections are given to one server. Any new connections going that server can overwhelm that server and due to that connections may not be served well. Any connection that does deep data mining function could overwhelm the server. To take care of these situations, it is better to monitor the processing power left in each server for new connections. What is the better way than monitoring the response time of servers. Though it is not 100% way of finding the least utilized server with response time, it is close as long as monitoring for response time is happening continuously. Some SLB devices monitor the response time as part of health checking. That is not good enough as health checks happen once in a while. Response time measurements must be done on response to real client traffic.
  
• Fill-and-go-next : Green is the buzz word now - Save power and save on cooling costs. Round Robin and other methods above distribute the traffic to all servers. Even when there is less load across servers, they are all used and thereby not giving chance to any server to go to any power saving modes. When this mode is chosen, SLB device uses one server to full utilization before selecting next server. Typical configuration include the number of connections a server can handle and when to start warming the next server. For example if 10000 and 8000 numbers are given, after 8000 active connections on existing server, next connection is given to next server to bring that server up to the full power and both servers are used until 18000 active connections and then another server is warmed up and so on. This mode can be combined with Round Robin method where this is used to balance the traffic across all warmed up servers.
  

• Syn Flood Detection and Prevention (DDoS Prevention): This feature is common in servers from last few years. But detection and prevention at central place in SLB allows administrators not worry about feature availability in all servers or enabling this feature in servers. This feature prevents attackers from sending large number of SYN packets without completing the TCP connection establishment phase. SLB devices using this feature detect the SYN flood attack without consuming its resources using SYN-Cookie mechanism. Only when three way handshake is complete, connection is awarded to server in the server farm.
• Traffic Anomaly detection and Traffic Policing: DDoS attacks such as Syn flood detection is really thing of a past. Newer kind of attacks complete TCP connections and issue requests that consume CPU power there by creating Denial of Service for genuine users. Since these attacks complete the connection, it is possible to track the users by their IP addresses. Traffic anomaly detection feature allows administrators to configure the baseline traffic characteristics based on normal day activity. SLB devices based on this configuration detect any anomaly and can take corrective actions such as:

Throttling the traffic coming from identified IP addresses : Throttling the traffic can be on "Simultaneous active connections", "Connection Rate", "Packet/Byte Rate".


Blocking the traffic from identified IP addresses for certain time.


• Health Checking: SLBs are expected to use servers that are online. To ensure that, SLBs typically do health checks on servers to ensure that they are alive. Some types of the health checks that can be configured are:

ICMP Ping : Using this check SLB knows that the server machine is active.


TCP Connection Checks : These checks allow SLBs know that a given TCP Service is running. Note that it is possible that Machine is alive, but the user process listing for TCP connections is dead. This check allows SLBs to check the TCP Server liveness.


Application Health Checks: These checks allow SLB to know whether the application is running well on the TCP Service. Note that TCP Server may be running in the server, but application that acts on the application data could be different user process than the process that is listening for TCP connections. Hence it is important to have these health checks enabled in the SLB devices.


• Persistence: For some end applications, it is necessary that all connections coming from one client go to the same server. This is necessary if the application maintains some state across connections coming from the client. It necessitates temporary and dynamic binding state in SLB devices. When there is no matching bind state, one server is chosen for the connection and immediately binds the client IP address with the chosen server IP address. Any new connection from this client is given to same server without server selection process. To ensure that these bindings don't consume large amount of memory on SLB devices, these bindings are removed after certain amount of inactivity. As you can see later, binding are implemented using cookies in case of HTTP connections without having need to store binding state in the SLB. Cookie received in each request would indicate the bound server.

Application Delivery Controllers (ADC):

Server Load balancing based on L3-L4 ( Source IP, Destination IP and Ports) does not solve all issues with different kinds of applications running on the servers. It requires L7 intelligence in the SLB devices to meet the load balancing requirements of newer kind of applications. Since they have L7 intelligence in making load balancing decision, I guess these devices are being called 'Application Delivery Controllers". In short they are called ADCs.

First generation of ADCs were trying to solve challenges associated with E-commerce and Session-persisting HTTP based applications. One challenge is to ensure all connections go the server which was chosen for the first connection from the client. This is necessary due to the fact the applications on the server maintain user state in the memory and this state is updated with the user selections until user logs out. This challenge has another twist where these connections are SSL encrypted.

First generation ADCs solve these challenges using HTTP protocol intelligence in ADC devices.

• Persistence using HTTP Cookies : Though IP based persistence works decently, it fails when a given user IP address changes across connections. This can happen if the user router gets new IP address in the life of user session. I believe another possibility is due to different NAT addresses usage by some ISPs. That is, ISP might use one NAT IP address for one connections and another NAT IP address for other connections of same user. Due to these issues IP address persistence does not work in all cases . In addition, IP address persistence occupies some memory in SLB devices. Alternative for HTTP based applications is to use HTTP Cookies. HTTP Cookies allow servers to relate the connections belonging to the same session. Same mechanism is used by ADCs to relate user connections. ADCs define their own cookie for storing the selected server in encrypted/encoded cookie data. When new HTTP connection is received, it checks whether it has its cookie and value. If not, it assumes that this is first connection of session and adds a Cookie in the response going to client with encoded/encrypted selected server information. Any further connections coming from the same user to this site would have this new cookie and this cookie value is used by SLB to map the connection to the server. Since this cookie belongs to the SLB, SLB devices remove the cookie from the request before sending it to the server.
• SSL Termination : E-Commerce web sites require SSL/TLS Security and also session persistence. To facilitate this, SLBs provide SSL termination capability. This capability in addition also offloads CPU intensive SSL processing to ADCs and thereby saving CPU cycles on server for application processing.
  

Second generation ADCs extend above functionality with HTTP Optimization, L7 protocol data based server selection, threat security features and multiple virtual instances.

HTTP Optimization features:

• HTTP Connection pooling : HTTP protocol allows multiple transactions in one TCP connection. This feature in ADCs multiplex multiple client connections into few connections to the server. Without this feature, there are as many TCP connections to the Server from SLB as number of TCP connections it is terminating. With this feature, there are only few TCP connections towards server, there by saving some CPU cycles and memory on the servers. Though the amount of saving one can have with this feature is debatable, this is one feature many ADCs support.
  
• HTTP Compression: HTTP compression using gzip and other algorithms can save bandwidth by compressing the response data. ADC devices offload this capability from the Servers there by making server CPU cycles available for application processing.
  
• HTTP Caching & Delta Encoding: HTTP Caching feature between clients and servers avoids duplicate file download if content was not changed on the server. But there are many instances where file/data content change but not significantly. This feature allows only difference (delta) being sent to the clients rather than complete content there by saving bandwidth usage. Since delta encoding requires significant CPU cycles, ADCs offload this functionality from HTTP Servers.
  

Programmatic L7 Protocol content based Server Selection:

SLBs traditionally don't look at the application protocol data to make server selection. ADCs augment the criteria for selecting the server with protocol data such as HTTP data. Some examples where protocol intelligence is required:

• Multiple server farms with each each farm having different content.
  
• Different server farms for Mobile users and Normal users.
• Different response on errors based on browser type.
• Prioritization/throttling/shaping of requests to specific URL resources upon congestion.
• Addition/Modification of request/responses based on the type of applications running on the server farm.
• Combination of above.

Since each deployment has its own requirements, one configuration solution for all is not sufficient. Hence ADCs provide flexible mechanism using 'rules' similar to IPS devices which provide rules for detecting vulnerabilities. Rules are created by administrators using the application protocol (eg. HTTP) keywords exposed by ADCs. Typically each protocol element is exposed as keyword. Multiple rules can be created with each rule having keywords and associated values. ADCs internally match the connection data with the rules. First match of rule with respect to values of keywords is used to take actions as per the rule. Actions can be 'Selection of Server farm', traffic policing etc..

Threat Security:

Since ADCs are becoming a central location for all requests going to the data center servers, this is place to enforce threat security and thereby offloading threat security functionality from the servers. Some of the threat security functions ADCs support are:

• Traffic Policing based on protocol intelligence: ADCs with protocol intelligence can do better job of DDOS prevention than SLBs. Baseline traffic can be much beyond typical 5 tuples. It can include URL pattern, User-Agent, Cookie values and beyond.
  
• Web Application Firewall: There are many attacks that are being exploited by attackers on web server applications including SQL injections, XSS (Cross Site Scripting), LFI (Local File include) and RFI (Remote File Include). ADCs are increasingly offloading this functionality from the servers. It not only improves server performance, but also administrators can configure signatures at one place i.e ADC.

Virtual Instances:

This feature is not common in ADCs today. But I believe this is going to become critical feature moving forward to ensure that multiple server farms belonging to multiple domains corresponding to different customers are supported by one or few ADCs. One ADC device should be able to support multiple customer server farms in public data centers. There are two types of virtual instances possible - In first type. One executable image supports multiple instances. Here configuration data and run time data are stored separatetly and even provide UI/CLI with role based access to configuration belonging to virtual instances. Second type of Virtual instance is to have multiple images with each image for one virtual instance. In this case, even if there is any issue with one virtual instance, other instances are not affected, there by providing good isolation. First type can provide large number of instances where second type is limited to few tens. I personally think that Linux container approach is better for second type as this is lean and uses common Operating system and TCP/IP stack image. Only user processes are instantiated multiple times as number of containers.

Third generation ADCs:

What are the features one would expect from third generation ADCs. I can think of few based on where data center market is heading.

• Cloud Computing : Traditionally ADCs are configured with all servers in a given server farm. It works well when manual intervention is required to setup/take-off servers from server farm. Administrators are used to configure the ADCs accordingly. In Cloud computing, servers are no longer physical. They are virtual. They can be added and removed dynamically and programmatically. They also can be disabled and enabled dynamically without manual intervention. Some use cases - virtual instances are brought up and down based on the load on the servers or based on time of day, holidays etc.. Since they are coming up and going down dynamically, it is expected that ADCs also would get this information dynamically.
• Beyond HTTP Servers (SIP, CIFS, SMTP, IMAP etc..): HTTP had been and is dominant in data centers today. It is changing with cloud computing. Many organizations are expected to host their internal servers too in the cloud. They include mail servers, File Servers etc.. Third generation ADCs are expected to balance the traffic across Email Servers, File Servers etc.. In addition it is expected to have optimization features to save network bandwidth. File Servers today dominantly support CIFS. ADCs are expected to have CIFS proxy that can save bandwidth by doing delta encoding, caching and de-duplication etc..