|
FasTrack for Information Highway: The Application Switch
Imagine that in
order for us to get to our destination, we all have to go through
the same toll booth and then cross a bridge with only one lane.
Sound daunting? Well, this is a good metaphor for Internet traffic
when it first came into existence. Obviously, such a bottleneck
would quickly become unacceptable as we all became increasingly
tired of waiting. Then someone had an idea to install more booths
and build more lanes so that more traffic could move through more
swiftly, reaching its destination in a shorter period of time. This
is similar to what we have today: a switching network. However,
eventually a switching network also becomes inadequate because there
is simply too much traffic: important traffic, not-so-important
traffic, useless traffic, and even some harmful traffic.
Unfortunately, there is no way for the switches to tell all this
different types of traffic apart and so all the traffic competes for
limited toll booths and lanes, and just like rush hour traffic, all
one can do is wait.
The waiting is not too bad for the most part, even by today’s
standard, if you are in smaller networks in an office or at a home
network. However, we cannot say the same for sites like Google,
Yahoo and other larger Internet web sites. As the demand for network
bandwidth increases and as more applications are being added—such as
bandwidth-demanding music and video downloads, Voice over IP, video
conferencing, and so on—the pressure mounts for a next-generation
switch that can handle the load intelligently.
So, going back to the toll booth and
bridge crossing analogy, consider this: why can’t we dedicate some
of the booths and some of the lanes for certain types of
traffic—like a FasTrak system for the Internet? In other words, why
is it that we cannot provide a certain amount of bandwidth to only
certain types of network applications, but throttle others?
For many years now, several network
manufacturers have been racing to come up with an answer to the need
for increased performance, better security, and a more intelligent
network switch. The technology that has been developed is commonly
known as an Application Switch or Content Switch.
Some of the key
design goals for this switch are the ability to:
 |
Understand
network applications (FTP, HTTP, HTTPS, SMTP, etc. |
|
Provide
accelerated network application-based performanc |
|
Handle SSL
encryption |
|
Provide
enhanced Quality of Service (QoS) based on network applications |
|
Provide
enhanced availability through load-balancing and fail-over |
|
Provide
enhanced security at the application level |
In order to understand the
applications and content the switch is serving, the switch is
architected roughly between layers 4 to 7 of the Open System
Interconnection (OSI) model.
OSI Model & Switch Technologies
|
OSI Layer
|
OSI
Description |
Switch
Technologies |
|
Layer 7
|
Application |
Application
Based
|
|
Layer 6
|
Presentation |
Application
Based
|
|
Layer 5
|
Session |
Application
Based
|
|
Layer 4
|
Transport |
Application
Based
(a.k.a.
Content Switch)
|
|
Layer 3
|
Network |
Routing
Based
(a.k.a.
Layer 3 Switch)
|
|
Layer 2
|
Data Link |
Hardware Based
(a.k.a. Layer 2 Switch)
|
|
Layer 1
|
Physical |
N/A |
|
Physical Link |
Physical Link |
Physical Link |
Some of the key
benefits of deploying an Application Switch are:
|
Provide
network application optimization for much faster network
application performance |
|
Provide
In-memory caching to reduce network traffic |
|
Provide SSL
encryption acceleration |
|
Provide
policies-based Quality of Service (QoS) based on users, network
applications/contents, and devices |
|
Provide
robust high availability, load-balancing and fail-over |
|
Provide
protection from known and unknown application-layer and from
layer 4 to 7 Denial-of-Server (DoS) attacks |
The original concept of the
Application Switch is to increase the performance of network-based
applications. However, as time goes on, the Application Switch
itself is being used more like an Application Server. By definition,
the more applications that are added to the switch, the slower it
will run, therefore defeating the original purpose of the switch.
The challenge here is to find a balance between increasing the
switch’s performance and increasing its functionality.
One reason we have not seen the
Application Switch more widely deployed is because of its price
tag. An Application Switch easily costs $10,000 per device, and
some cost much more. So at this time, switches are being deployed
mainly in very high-value environments where their cost can be
justified.
Just like the Layer 2 switch when it
first came out, it was sold for up to $1,000 per port. Today, we can
get Layer 2 switches for less than $10 per port.
Besides the issue of price,
currently the Application Switch is primarily optimized for Internet
traffic. For most organizations, the heaviest use may not be
Internet-based applications like HTTP, HTTPS, FTP or SMTP, but other
types of enterprise-wide traffic such as databases, file & print,
backup, and other server-based applications and authentications.
Despite some of the shortcomings,
finding ways to speed up all layers of the OSI model is the right
thing to do to ensure the growth of the Internet and Intranet-based
applications. As we move more resources away from client desktops
to more network and/or server-centric architecture, we will
definitely need to solve the issue of performance between
end-devices and network and/or server-centric resources.
By
Benson Yeung, Senior Partner
Back to Top 
Information Request Form
|
|
