Understanding

 WLAN  architectures  and  their  applications  

 
   
Table  of  contents  
Executive  summary  .................................................................................................................  3  
Evolution  of  Wi-­‐Fi  ...................................................................................................................  3  
Centralized  controller  architecture  .........................................................................................  4  
Distributed  controllerless  architecture  ....................................................................................  4  
Logical  network  planes  ...........................................................................................................  7  
Campus  networks  ...................................................................................................................  9  
Campus  network  architecture  .............................................................................................  9  
Access  layer  ..........................................................................................................................  10  
Distribution  layer  ..................................................................................................................  10  
Core  layer  .............................................................................................................................  10  
Decision  criteria  for  wireless  architecture  .........................................................................  11  
Controller-­‐based  architectures  ..........................................................................................  12  
Benefits  of  controller-­‐based  architectures  ...........................................................................  13  
Myths  about  controller-­‐based  architectures  ........................................................................  17  
Controllerless  architecture  ................................................................................................  20  
Advantages  of  controllerless  architectures  ..........................................................................  20  
Challenges  with  controllerless  architectures  ........................................................................  22  
Which  architecture  should  I  deploy?  .....................................................................................  22  
WLAN  controller  evolution  ...................................................................................................  23  
Remote  networks  .................................................................................................................  26  
Decision  criteria  for  a  branch  ............................................................................................  26  
Branch  with  basic  wireless  services  ...................................................................................  28  
Branch  with  advanced  services  .........................................................................................  29  
Conclusion  ............................................................................................................................  31  
 
 
 
 
   

 
Executive  summary  
 
This  white  paper  describes  the  evolution  of  Wi-­‐Fi  networks  and  the  two  architectures,  
centralized  and  distributed  that  can  be  leveraged  depending  on  the  network  requirements.  
The  core  of  the  centralized  architecture  is  the  WLAN  controller.    
 
WLAN  controllers  reside  at  the  distribution  layer  of  the  campus  architecture.  They  handle  AP  
traffic  termination,  user  authentication  and  policy  enforcement.    
 
With  a  distributed  architecture,  the  access  points  (AP)  coordinate  amongst  them  to  apply  
common  policies  and  enable  mobility  across  APs.  With  this  architecture,  the  AP  traffic  
terminates  right  at  the  access  layer.  User  authentication  and  policy  enforcement  happens  at  
the  AP  to  which  a  user  is  currently  associated.    
 
We  will  discuss  the  differing  requirements  across  campus  and  branch  networks  that  ultimately  
drive  the  selection  of  architecture,  as  well  as  how  these  two  architectures  handle  WLAN  related  
functions  and  the  implications  of  their  approach  on  networks.    
 
Evolution  of  Wi-­‐Fi  
 
During  the  early  days  of  Wi-­‐Fi,  wireless  networks  were  deployed  as  convenience  networks  and  
were  not  mission-­‐critical.  It  was  very  common  even  for  large  organizations  to  deploy  just  a  few  
APs  in  areas  such  as  conference  rooms,  cafes  and  CTO  offices.    
 
This  deployment  allowed  network  administrators  to  build  wireless  networks  using  fat  Aps,  also  
known  as  autonomous  APs,  because  performance,  quality  of  service  (QoS),  mobility,  scalability  
and  manageability  of  these  devices  were  not  critical.  To  deploy  fat  APs,  the  IT  staff  had  to  
manually  configure  every  AP  they  deployed.    
 
However,  as  wireless  technology  progressed  and  as  organizations  discovered  the  advantages  of  
wireless  networks,  the  scale  of  wireless  deployment  grew.  This  led  to  scalability  and  
manageability  challenges  that  hindered  the  growth  of  fat  AP  networks,  and  drove  the  creation  
of  centralized  architecture  with  controller-­‐based  WLANs  that  coordinated  thin  APs.    
 
In  controller-­‐based  WLAN  technology  with  thin  APs,  the  key  non-­‐real-­‐time  functions  are  
centralized  at  the  controller.  In  a  typical  controller-­‐based  deployment,  the  administrator  does  
not  have  to  touch  every  AP  on  the  network.  Rather,  the  control,  data  and  management  plane  
are  centralized  on  the  controller.    
 
This  architecture  can  act  as  an  overlay  to  an  existing  wired  network  infrastructure,  allowing  
WLANs  to  scale  to  a  large  number  of  APs,  providing  a  single  point  of  management  and  
configuration  for  the  entire  network.  The  development  of  controller-­‐based  WLAN  technology  
greatly  helped  in  the  adoption  of  large-­‐scale  wireless  networks.    
 

 
In  the  past  few  years,  advancements  in  AP  hardware  technology,  such  as  advanced  CPU  and  
memory  capabilities,  have  opened  up  the  possibility  of  a  distributed  WLAN  system.  These  
modern  APs  allow  wireless  vendors  to  distribute  the  management,  control  and  data  paths  
amongst  APs  without  the  need  for  a  physical  controller.    
 
This  architecture  is  suitable  for  small  or  remote  WLAN  deployments  where  the  network  
requires  an  enterprise-­‐grade  solution  that  can  be  managed  from  a  single  interface.  If  the  scale  
of  users  and  devices  on  the  network  are  not  complex  and  do  not  require  the  additional  benefits  
of  a  controller-­‐based  architecture,  then  distributed  networks  work  well.  
   
Centralized  controller  architecture    
 
Today,  the  controller-­‐based  architecture  is  the  primary  architecture  that  is  used  in  large  campus  
deployments.  Typically,  university  campuses,  hi-­‐tech  companies,  large  enterprises  and  large  
healthcare  facilities  fall  into  this  category.  Security  conscious  customers  like  the  government,  
military,  finance  and  insurance  companies  also  prefer  to  go  with  a  purpose  built  controller  
appliance  to  serve  their  wireless  needs.    
 
Organizations  with  large  Layer  2  domains  that  do  not  want  a  major  overhaul  to  their  edge  
network,  like  adding  and  deleting  VLANs,  also  prefer  to  go  with  the  overlay  model  offered  by  
controllers.  Medium  sized  campuses  like  K-­‐12  school  districts,  mid-­‐sized  enterprises,  hospitality  
and  some  healthcare  facilities  with  advanced  requirements  also  prefer  to  go  with  a  controller  in  
order  to  leverage  the  benefits  of  an  overlay  architecture  and  the  advanced  security  and  
mobility  features  that  a  controller  can  provide.    
 
Key  benefits  of  a  centralized,  controller-­‐based  architecture:    
1. Centralized  configuration  for  VLAN,  QoS  and  policy  enforcement    
2. Centralized  Layer  3  mobility    
3. Centralized  encryption  
4. Efficient  broadcast  and  multicast  control  
5. Scaling  and  orchestration  of  mobility  services  
6. Future  proofs  the  network    
 
Distributed  controllerless  architecture    
The  advancements  in  AP  hardware  technology,  like  enhanced  CPUs  and  memory,  have  opened  
up  the  possibility  of  a  distributed  WLAN  architecture.  With  intelligent  distributed  coordination  
software,  these  APs  have  departed  from  fat  APs  and  borrow  from  controller-­‐based  architecture.    
 
Key  benefits  of  a  distributed,  controllerless  architecture:    
1. Simple  to  deploy  
2. Self-­‐optimizing  and  self-­‐healing  
3. Built-­‐in  enterprise  class  security  

 
 4. Lower  cost  
5. Minimal  IT  supervision  
6. Path  for  migration  to  controller-­‐based  (with  some  WLAN  vendors)  
 
Smaller  campuses  that  only  have  a  few  hundred  users  in  a  standalone  building  typically  choose  
this  architecture.  Many  medium  sized  organizations  that  need  basic  WLAN  functionality  but  
have  limited  IT  resources  also  prefer  going  with  this  architecture.  
 

 
Customers  have  to  be  aware  of  the  gray  area  in  the  medium  sized  campuses  where  both  the  
architectures  might  seem  to  be  a  fit.  Campuses  such  as  K-­‐12  school  districts,  smaller  enterprises,  
hospitality  and  some  healthcare  facilities  with  advanced  requirements  often  deploy  the  
controller-­‐based  architecture.  Often  the  need  for  mobility  services  or  the  demand  for  
consistent  security  policy  enforcement  will  drive  customers  to  invest  in  a  controller-­‐based  
architecture.  When  IT  resources  are  limited  or  there  is  not  a  contiguous  RF  domain,  customers  
will  usually  invest  in  a  controllerless  architecture  and  if  their  requirements  evolve,  then  add  a  
controller  at  a  later  time.  It  is  highly  recommended  to  consider  all  the  factors  discussed  in  this  
white  paper  before  making  a  decision  regarding  architecture.    
 
A  remote  or  distributed  deployment  is  an  operation  with  multiple  locations  that  are  
geographically  distributed  across  a  limited  geography  or  across  the  entire  globe.  This  would  
include  home  offices  for  large  high-­‐tech  enterprises,  a  satellite  campus  for  a  university,  retail  
chains  and  hotel  chains.    
 

 
These  days,  organizations  are  more  distributed  than  ever  because  of  the  cost  savings  and  
increased  productivity  associated  with  employing  a  distributed  workforce.  A  distributed  
enterprise  might  be  a  collection  of  branch  offices,  home  offices,  or  a  combination  of  both.    
 
The  number  of  distributed  sites  and  the  user  density  at  these  sites  vary  across  organizations.  
For  larger  distributed  organizations,  a  centralized  network  management  system  is  critical  in  
regards  to  being  able  to  scale  up  to  support  a  large  number  of  sites  with  unified  configuration  
and  policies.  
 
The  key  deciding  factors  that  will  determine  the  best  architecture  for  a  remote  deployment  are  
the  services  that  are  required  in  the  branch  or  home  office.  This  can  be  classified  into  two  
major  categories.  
 
Basic  services  –  This  includes  reliable  and  secure  wireless  access  that  is  easy  to  deploy,  manage  
and  maintain.  In  this  scenario  the  branch  office  might  already  have  a  network  infrastructure  
comprised  of  a  Layer  2  switch  and  WAN  termination  equipment.    
 
Wireless  sits  on  top  of  this  and  enables  secure  connectivity.  A  controllerless  solution  is  an  ideal  
choice  for  these  deployments.  Some  of  the  benefits  of  a  controllerless  solution  in  these  
environments  include  reliable  and  secure  wireless  access,  secure  corporate  connectivity,  site  
survivability,  and  zero-­‐touch  provisioning  with  centralized  management.    
 

 
Advanced  services  –  There  are  certain  branch  deployments  that  need  advanced  cloud-­‐based  
services  on  top  of  basic  wireless  access.  Some  of  these  services  include  unification  of  wired  and  
wireless  networks,  intelligent  WAN  optimization,  multiple  uplinks,  policy-­‐based  routing  and  
unified  threat  management.    
 
These  services  are  typically  delivered  by  a  centralized  architecture  from  a  small  form-­‐factor  
controller  that  is  optimized  for  the  branch.    
 
Some  greenfield  branch  deployments  that  don’t  have  any  network  infrastructure  in  place  and  
require  basic  wireless  service,  also  deploy  a  centralized  architecture  to  consolidate  all  branch  
services  into  a  single  platform.    
 
Finally,  if  there  is  an  existing  campus  network  that  is  already  using  a  centralized  architecture,  
then  in  most  cases  it  makes  sense  to  also  deploy  a  centralized  architecture  at  the  branch,  in  
order  to  maintain  architectural  and  operational  uniformity.    
 
WLAN  vendors  have  put  in  a  lot  of  innovation  to  support  a  wide  array  of  architectures.  Every  
customer  network  is  going  to  be  different,  and  the  requirements  and  success  criteria  for  a  
network  upgrade  varies.  It  is  critical  that  customers  look  at  the  upgrade  at  all  levels  and  select  
the  best  architecture  to  deliver  a  robust,  secure  and  intelligent  mobility  network.    
 
Logical  network  planes  
 
Distinguishing  the  differences  between  architectures  requires  an  understanding  of  the  critical  
functions  performed  by  a  WLAN  architecture.  These  functions  can  be  divided  into  three  logical  
categories  as  follows:  
1. Control  plane  –  Responsible  for  making  forwarding  decisions  and  programming  the  data  
plane.  
2. Data  plane  –  Responsible  for  processing  and  forwarding  data.  
3. Management  plane  –  Responsible  for  configuration,  monitoring,  upgrades  and  
troubleshooting.  
These  functions  are  supported  by  both  architectures.  The  following  table  shows  the  
fundamental  differences  between  the  two  architectures  relative  to  the  network  planes.  
 
  Control  plane   Data  Plane   Management  Plane  
Centralized   Controller   Controller   Controller/NMS  
architecture  
Distributed   AP   AP   AP/NMS  
architecture  
 
Now  that  you  understand  the  WLAN  architectures  and  what  led  to  their  development,  let’s  
discuss  the  various  networks  and  their  requirements  that  drive  the  selection  of  the  best  
architecture  for  your  deployment.  
 

 
    

 
CAMPUS  NETWORKS  
 
Campus  deployments  are  networks  that  cover  a  large  contiguous  space  that  may  span  several  
buildings  and  host  thousands  of  users  with  co-­‐located  data  centers  where  resources  are  hosted.  
This  can  be  a  building  or  a  group  of  buildings  that  host  thousands  of  users  in  one  location.  
 
Examples  of  campus  deployments  are  corporate  campuses,  large  hospitals,  and  higher-­‐
education  campuses.  In  these  deployments,  the  WLAN  is  typically  the  primary  access  method  
for  the  network,  and  is  used  by  multiple  classes  of  users  and  devices.  
 
In  order  to  understand  the  implications  of  wireless  architectures  on  a  typical  campus  network,  
it  is  important  to  understand  the  common  approach  and  key  consideration  that  goes  into  
designing  wired  enterprise  networks.  
 
Campus  network  architecture  
 
Traditional  wired  campus  architecture  involves  three  layers:  the  access  layer,  the  distribution  
layer  and  the  core.  In  the  following  sections  we  will  discuss  the  key  factors  that  are  considered  
while  designing  each  of  the  layers  in  the  wired  network.    
 

 
 
 

 
Access  layer  
 
Any  device  that  allows  users  to  connect  to  the  network  is  considered  an  access  layer  device.  
These  are  typically  switches  deployed  in  wiring  closets  on  each  floor  of  a  building.  VLAN  
assignment,  ACLs,  and  QoS  are  typically  configured  on  a  per  port  basis  to  enable  a  secure  
reliable  wired  network  that  the  users  can  plug  into.    
 
While  designing  the  access  layer  it  is  a  best  practice  to  have  a  layered  architecture.    This  
ensures  that  the  failure  of  a  switch  does  not  impact  the  entire  network.  In  addition,  some  
deployments  have  redundant  power  supplies  built  into  each  switch  that  draw  power  from    
different  sources  to  avoid  outages.  Enabling  multi-­‐gig  links  between  the  access  layer  and  the  
distribution  layer  for  traffic  aggregation  is  common  in  many  deployments.    
 
Distribution  layer  
 
The  main  function  of  a  distribution  layer  is  to  provide  the  access  layer  with  connectivity  to  the  
core  layer.  The  distribution  layer  is  responsible  for  routing  packets,  filtering  packets  and  WAN  
connectivity.  Since  the  most  basic  function  of  the  distribution  layer  is  to  connect  the  access  
layer  devices,  it  is  a  best  practice  to  ensure  that  the  distribution  layer  devices  can  carry  
extremely  high  volumes  of  traffic.    
 
Similar  to  the  access  layer,  redundancy  is  a  key  consideration  for  this  layer.  While  the  failure  of  
an  access  layer  device  could  potentially  affect  hundreds  of  users,  the  failure  of  a  distribution  
layer  device  could  affect  thousands.  Hence  the  distribution  layer  devices  are  usually  deployed  in  
pairs  with  redundant  links  back  to  the  access  layer  devices.    
 
Redundant  power  supplies  and  supervisor  engines  are  of  critical  importance  in  highly  available  
networks.  Hot  Standby  Routing  Protocol  (HSRP)  is  typically  used  to  provide  fault  tolerance.  
Lastly,  the  distribution  layer  devices  are  connected  to  the  core  layer  using  10  gig  uplinks  or  
more;  in  large  campuses  a  40  gig  uplink  is  not  uncommon.  Multiple  uplinks  are  configured  for  
link  aggregation  and  redundancy.  
 
Core  layer  
 
Campus  networks  that  contain  two  or  more  switch  blocks  require  a  core  layer  to  connect  each  
switch  block  to  other  switch  blocks.  The  most  important  consideration  at  the  core  layer  is  
speed,  because  devices  at  the  core  layer  must  perform  switching  between  the  switch  blocks  at  
very  high  speeds.  Since  speed  is  important,  the  core  layer  is  not  where  network  policies,  
firewalls,  or  any  type  of  filtering  should  be  performed.    
 
Similar  to  the  lower  layers,  redundancy  is  yet  another  important  consideration  for  this  layer.  
The  failure  of  the  core  layer  can  potentially  take  down  the  network.  The  distribution  layer  is  
typically  connected  to  the  core  layer  using  redundant  links,  typically  multi-­‐gig  per  link  so  that  
the  large  amount  of  traffic  is  being  carried  across  these  links.    

 
  
Decision  criteria  for  wireless  architecture  
 
The  common  requirements  that  any  campus  deployment  looks  for:  
 
Ease  of  installation  –  Regardless  of  the  architecture  chosen,  a  WLAN  network  has  to  co-­‐exist  
with  a  wired  backend  as  explained  above.  The  scale  of  the  wired  network  varies  for  every  
organization.  It  is  extremely  important  for  the  WLAN  architecture  to  seamlessly  integrate  with  
the  wired  network  in  place.    
 
For  large  to  medium  sized  campuses,  touching  every  switch  at  the  access  layer  is  not  a  viable  
option.  Centralizing  configuration  is  extremely  critical.  With  BYOD,  WLAN  requirements  are  
becoming  more  complex  wherein  users  are  given  different  network  access  control  rights  based  
on  factors  like  device,  location  and  time  of  day,  and  has  to  integrate  with  multiple  backend  
servers  for  authentication  and  authorization.    
 
As  the  complexity  of  the  network  grows,  centralizing  functions  seems  more  logical  and  cost  
effective.  The  architecture  in  place  should  be  as  non-­‐disruptive  as  possible  to  the  wired  
network  infrastructure.    
 
High  performance  and  adaptive  RF  –  Users  today  carry  two,  if  not  three,  Wi-­‐Fi  enabled  devices.  
Most  of  these  newer  generation  devices  do  not  have  an  Ethernet  adapter.  This  makes  wireless  
the  de-­‐facto  choice  of  technology  for  providing  access.  The  combination  of  density  of  users  and  
devices  poses  a  big  challenge  to  the  network  administrators  supporting  networks.    
 
In  order  to  have  robust  RF  in  the  campus,  the  WLAN  infrastructure  should  actively  gather  
session  performance  metrics  from  mobile  devices  and  use  this  information  to  intelligently  steer  
clients  to  the  closest  AP  and  the  best  radio  on  the  WLAN.  The  architecture  should  support  
proactive  and  deterministic  RF  algorithms,  which  should  dynamically  optimize  Wi-­‐Fi  client  
performance;  even  while  users  roam  and  RF  conditions  change.    
 
Application  visibility  and  control  –  With  the  rapid  changes  in  the  device  landscape,  the  
application  landscape  has  also  changed  significantly.  Users  do  not  only  consume  traditional  
applications  like  email,  voice  and  basic  file  services,  but  they  are  moving  towards  Cloud,  
Virtualized  Desktop  Infrastructure  (VDI)  and  video  streaming  applications.    
 
The  architecture  in  place  should  be  able  to  provide  visibility  into  applications  that  are  being  
consumed  in  the  network  and  be  capable  of  applying  the  right  bandwidth  management  rules  so  
that  the  important  applications  get  higher  priority.  
 
UCC  applications  –  Communication  technologies  have  changed  dramatically  over  the  past  few  
years.  The  era  of  standalone  voice  communication  is  slowly  fading  away.  UCC  applications  like  
Lync,  Skype,  Hangouts  and  Jabber  pose  a  serious  challenge  to  the  traditional  voice  
infrastructure.    

 
  
The  underlying  access  network  should  not  only  be  able  to  identify  these  applications,  but  also  
assure  QoS  and  provide  as  much  visibility  as  possible  for  an  administrator  to  proactively  make  
capacity  planning  decisions.    
 
Broadcast  and  multicast  control  –  Devices  like  Apple  TV  and  Chromecast  tabs  are  changing  the  
way  information  is  shared  between  users.  These  devices  have  given  a  chance  to  eliminate  
expensive  video  projectors  and  replace  them  with  small  form  factor  and  less  expensive  devices,  
which  is  being  embraced  widely  as  part  of  the  all-­‐wireless  strategy  in  many  campus  
deployments.    
 
Given  the  inherent  limitations  of  protocols  that  these  devices  use,  such  as  mDNS  and  SSDP,  the  
access  network  needs  to  be  intelligent  enough  to  identify,  intercept  and  control  these  
broadcast/multicast  traffic  created  by  these  protocols,  which  can  be  quite  detrimental  to  the  
network.    
 
Seamless  mobility  –  The  definition  of  a  wireless  network  is  that  the  users  are  going  to  be  
mobile.  The  network  should  follow  the  user  within  an  enterprise  and  apply  the  right  policies  
associated  with  the  user.  When  users  move  they  might  be  on  the  same  or  different  Layer  2  
domain.    
 
In  a  large  campus  network  that  has  hundreds  of  active  users,  wherein  each  user  has  multiple  
devices,  mobility  plays  a  key  role  irrespective  of  the  architecture  being  chosen.  The  underlying  
architecture  should  ensure  a  seamless  user  experience  while  performing  all  the  key  tasks  as  
mentioned  in  the  previous  statement,  regardless  of  where  they  are  in  the  enterprise.    
 
Integration  with  other  third-­‐party  engines  –  A  campus  network  today  requires  multiple  
linkages  to  a  given  external  application  server.  Examples  may  be  UCC  infrastructure,  analytics  
infrastructure,  real-­‐time  location  services  (RTLS)  systems,  and  student  schedule  databases.  This  
is  going  to  vary  widely  for  every  customer  deployment.  The  architecture  in  place  should  provide  
options  to  seamlessly  integrate  with  these  third-­‐party  engines  without  hassle.    
 
Controller-­‐based  architectures    
 
The  core  component  in  a  centralized  architecture  is  a  controller.  WLAN  controllers  reside  at  the  
distribution  layer  of  the  campus  architecture.  They  handle  AP  termination,  user  authentication  
and  policy  enforcement.    
 
The  wireless  user  traffic  is  typically  a  similar  path  as  that  of  any  wired  traffic,  traversing  the  
various  layers  of  the  campus  topology  as  seen  below.  The  highly  redundant  and  over  
engineered  wired  network  remains  untouched  in  this  overlay  model.    
 
 

 
  
 
 
Benefits  of  controller-­‐based  architectures  
 
A  centralized  thin  AP  architecture  has  the  following  key  benefits  for  a  campus  network:    
 
Centralizes  configuration  –  A  controller-­‐based  architecture  does  not  require  complex  changes  
in  the  access  network  to  fulfill  a  basic  requirement  of  separate  SSIDs  for  employees  and  guests.  
APs  plug  into  the  edge  VLANs  that  are  present  at  the  access  layer,  and  the  user  VLANs  are  
defined  and  managed  only  on  the  controller.    
 
Relevant  services  like  DHCP,  NAT  and  RADIUS  are  also  centrally  anchored  on  the  controller  to  
serve  wireless  users,  regardless  of  which  AP  they  connect  through,  enabling  a  plug  and  play  
architecture.    

 
      
Centralized  QoS  enforcement  and  security  –  A  controller-­‐based  architecture  is  inline  to  the  
user  traffic  which  enables  the  purpose  built  controller  platform  to  perform  inspection  on  the  
user  traffic,  and  apply  the  right  QoS  and  security  policies  needed.    
 
Centralizing  these  settings  enables  the  network  to  scale  easily  for  both  static  and  mobile  clients.  
The  application  state  for  wireless  users  is  maintained  at  one  place,  which  makes  functions  like  
bandwidth  management,  policing  and  QoS  control  easier.    

 
                      
Optimized  Layer  3  mobility  –  Controllers  obviates  the  need  for  complex  wired  network  design  
to  allow  for  Layer  3  mobility  as  the  user  VLANs  are  all  centralized.  These  calls  for  a  cleaner  
design  on  the  wired  side  as  the  user  traffic  now  takes  a  predictable  path  without  over  
burdening  any  entity  on  the  network.    
 
Lastly,  the  state  associated  to  the  user,  applications  and  mobility  are  all  maintained  in  one  
location,  which  helps  the  network  scale,  and  also  enables  faster  troubleshooting  in  case  of  any  
issues.    
 

       

 
Centralized  encryption  –  Controllers  have  built-­‐in  crypto  engines  that  are  capable  of  
encrypting/decrypting  802.11  packets.  With  WPA2  enterprise  security  for  wireless  users,  the  
data  is  encrypted  all  the  way  from  the  user’s  endpoint  to  the  WLAN  controller  that  resides  in  
the  distribution  layer.  This  end-­‐to-­‐end  security  is  important  for  deployments  like  the  military,  
government  agencies  and  insurance  companies.    
 

 
Smarter  broadcast  and  multicast  control  –  By  virtue  of  being  inline  to  the  user  traffic,  a  
controller  is  able  to  intercept  and  optimize  broadcast  and  multicast  traffic  on  the  wireless  
network,  while  intelligently  handling  the  important  traffic.    
 
This  ensures  increased  airtime  utilization  and  avoids  unwanted  disruptions  like  flooding  etc.  
Vendors  have  built  special  handlers  for  services  like  mDNS  and  SSDP  to  enable  plug  and  play  
networking  from  one  central  location.    
 

                         
Scaling  of  mobility  services  –  A  wireless  network  is  the  primary  access  network  in  most  
deployments  today.  The  requirements  that  campus  networks  have,  the  trends  in  a  campus  that  
point  to  increased  user  and  device  density  and  the  need  for  these  networks  to  integrate  with  
other  third-­‐party  engines  like  the  UCC  infrastructure;  a  centralized  controller  orchestrates  these  

 
complex  tasks  efficiently.  The  WLAN  controller  is  not  only  an  AP  termination  box,  but  the  brains  
behind  the  primary  access  network  that  enables  services  and  helps  a  campus  network  scale.    
   

                               
 
Extending  lifespan  of  Access  Points  –  As  network  requirements  evolve,  requiring  new  features  
that  have  increasing  demand  on  the  CPU  and  memory  of  the  edge  devices  (Access  Points),  
Controllers  with  their  advanced  processing  and  large  memory  footprints  enable  customers  to  
extend  the  lifespan  of  Access  Points  to  handle  these  software  advances  by  offloading  the  APs.    
 
Myths  about  controller-­‐based  architectures  
 
A  centralized  architecture  offers  several  benefits  for  a  campus  network.  Given  the  benefits,  the  
controller’s  strategic  location  in  the  network  and  an  unrealistic  requirement  expectation  by  end  
users  to  have  an  always-­‐on  network  –  there  have  been  several  myths  floating  around.  Mostly  
these  claims  are  pushed  by  WLAN  vendors  that  have  a  stake  in  promoting  controllerless  
architecture.  
 
In  order  to  understand  these  concerns  one  should  look  at  it  from  an  overall  network  
standpoint.  As  a  reminder  please  refer  back  to  the  traditional  campus  architecture  that  was  
covered  earlier.    
 
Let  us  look  at  some  of  these  claims:    
 
1. Claim  1  –  A  controller  is  a  single  point  of  failure    
 
A  WLAN  controller  is  not  any  more  of  a  ‘single  point  of  failure’  as  compared  to  any  other  
networking  infrastructure  deployed  in  a  campus.  If  you  look  at  the  campus  architecture,  

 
 it  consists  of  three  layers.  An  outage  in  any  of  these  layers  affects  the  network  in  
different  ways.    
 
An  outage  in  the  access  layer  takes  down  the  APs  and  other  wired  endpoints  connected  
to  it.  An  outage  in  the  distribution  layer  can  potentially  bring  down  a  block  of  the  access  
layer  and  leave  the  users  stranded.  An  outage  at  the  core  layer  can  potentially  impact  
the  entire  network.  The  IT  administrator  has  to  plan  for  these  outages  and  design  a  
redundant  network.    
 
The  WLAN  controller  that  resides  in  the  distribution  layer  follows  similar  guidelines.  
WLAN  vendors  have  innovated  around  redundancy  algorithms  and  clustering  
capabilities  to  ensure  that  there  is  a  seamless  and  hitless  failover  in  the  event  that  the  
primary  controller  fails.    
 
Designing  the  best  practice  for  a  controller-­‐based  deployment  recommends  distributing  
the  WLAN  load  across  multiple  boxes  with  enough  resource  leeway  on  each  box  so  that  
the  network  is  able  to  self-­‐heal  by  falling  back  to  another  box  in  the  event  of  a  failure.    
 
2. Claim  2  –  In  a  controller-­‐based  deployment,  the  user  traffic  has  to  traverse  the  wired  
network  twice  to  reach  the  destination    
 
In  order  to  better  understand  the  claim,  it  is  critical  for  one  to  understand  the  following:  
According  to  Gartner,  “With  BYOD  and  the  emergence  of  cloud-­‐based  applications  80%  
of  the  traffic  in  a  campus  flows  in  the  north-­‐south  direction”.    
 
Based  on  the  previous  section,  a  typical  campus  network  is  multi-­‐layered.  User  traffic  
has  to  traverse  the  three  logical  layers  before  it  reaches  its  destination.  The  destination  
could  either  be  the  local  server  farm  or  the  Internet.  A  controller  in  this  environment  
does  not  change  the  path  of  user  traffic  in  any  significant  way.    
 
Applications  like  Unified  Communications  (UC)  are  slowly  being  adopted  in  campuses.  
The  RTP  packets  that  carry  the  media  is  peer-­‐to-­‐peer  in  most  cases,  which  alters  the  
network  path  to  east-­‐west.  High-­‐speed  links  on  the  wired  side  combined  with  the  right  
QoS  enforcement  at  various  points  in  the  network  ensure  that  there  is  no  bottleneck.    
 
Furthermore,  WLAN  vendors  are  evolving  their  architecture  to  support  software  defined  
networking  (SDN)  protocols  like  OpenFlow  to  their  controller-­‐based  architecture;  so  
customers  get  the  best  of  both  worlds  wherein  there  is  a  centralized  overlay  
architecture  and  support  for  the  most  optimum  traffic  engineering  rules.  
   
3. Claim  3  –  Controllers  cannot  scale  to  demanding  new  standards  like  11ac    
 
In  line  with  Claim  1,  a  WLAN  controller  is  not  any  more  of  a  bottleneck  as  compared  to  

 
 wired  network  infrastructure  present  in  a  campus.  As  per  the  campus  topology  
described  above,  there  are  multiple  appliances  that  are  inline  to  user  traffic.  
 
 
Typically,  appliances  that  are  inline  to  user  traffic  are  designed  to  handle  a  large  volume  
of  packets  in  both  directions.  A  WLAN  controller  is  also  a  purpose  build  platform  that  
has  a  multi  gigabit  data  forwarding  capacity.    
 
Furthermore,  one  has  to  keep  in  mind  that  the  theoretical  and  the  real  world  
throughput  are  two  very  different  numbers.  Just  because  the  Wi-­‐Fi  network  is  802.11ac  
capable,  it  does  not  mean  that  the  users  associated  to  this  802.11ac  AP  will  consume  >  1  
Gbps  of  bandwidth  all  the  time.    
 
There  is  a  combination  of  factors  that  determine  the  peak  throughput:  client  chipset  
capabilities,  client  SNR,  Tx/Rx  rates,  interference,  application  characteristics,  and  Wi-­‐Fi  
overhead.  From  a  recent  study  in  an  all-­‐wireless  office  environment  with  802.11ac  
deployed  across  the  campus,  the  peak  per-­‐user  throughput  has  been  observed  to  only  
be  in  the  150-­‐600  Kbps  range.    
 
In  addition,  as  explained  in  the  previous  section,  WLAN  vendors  are  evolving  their  
architecture  in  the  future  to  support  software  defined  networking  (SDN)  protocols  like  
OpenFlow  that  will  enable  them  to  program  the  most  optimal  path  for  user  traffic  based  
on  real  time  context.    
 
4. Claim  4  –  Controllers  are  complex  to  install  and  manage    
 
A  WLAN  controller  is  a  highly  multi-­‐purpose  appliance.  A  typical  controller  from  most  
vendors  not  only  supports  the  traditional  WLAN  functions,  but  also  has  an  integrated  
stateful  firewall,  a  context  engine,  VPN  concentrator,  a  Layer  2  and  Layer  3  switch,  
network  management  functions,  and  WAN  functions.  Given  the  increased  functionality,  
and  the  strategic  nature  of  the  appliance,  it  adds  some  amount  complexity  to  the  
deployment.    
 
WLAN  vendors  have  resorted  to  several  approaches  to  make  installation  and  day-­‐to-­‐day  
management  simpler  with  the  help  of  wizards  and  intuitive  workflows.  The  WLAN  
administrator  responsible  for  this  network  needs  to  be  moderately  experienced  and  
familiar  with  TCP/IP  to  ensure  optimum  design.  The  benefits  that  a  centralized  
architecture  brings  to  campus  networks  have  been  proven.    
 
5. Claim  5  –  Controller-­‐based  deployment  increase  the  total  cost  of  ownership    
 
By  virtue  of  having  a  dedicated  appliance,  a  standby  appliance  for  redundancy  and  
associated  licenses  for  other  value  added  functionality,  the  cost  of  a  controller-­‐based  
deployment  is  marginally  higher  than  the  distributed  architecture.    

 
  
But  one  has  to  keep  in  mind  the  benefits  that  the  architecture  offers  and  its  strategic  
importance  to  the  network’s  business  and  technical  needs  before  making  an  
architectural  decision  that  purely  based  on  cost  and  complexity.    
 
Controllerless  architecture  
 
The  core  components  in  a  distributed  architecture  are  the  APs.  In  this  model  the  AP  terminates  
right  at  the  access  layer.  User  authentication  and  policy  enforcement  happen  at  the  AP  to  
which  a  user  is  currently  associated.  
   
Once  dropped  at  the  access  layer,  the  WLAN  traffic  follows  the  same  path  as  that  of  any  wired  
traffic  traversing  the  various  layers  before  reaching  its  destination.  Unlike  controller-­‐based  
architecture,  the  wired  network  needs  to  be  modified  based  on  wireless  network  requirements.    
 
Advantages  of  controllerless  architectures  
 
Some  of  the  benefits  of  a  controllerless  architecture  are  as  follows:    
 
1. Simple  to  deploy  –  The  controllerless  architecture  revolves  around  simplicity.  WLAN  
vendors  have  taken  the  core  control  plane  intelligence  that  is  centralized  on  a  controller  
and  moved  it  into  software.  
 
Newer  generation  access  points  with  enhanced  memory  and  processing  power  take  
advantage  of  this  software,  along  with  distributed  algorithms  that  function  between  the  
APs  for  day-­‐to-­‐day  operation  without  the  need  to  have  a  centralized  appliance  in  the  
network.    
 
Over-­‐the-­‐air  provisioning,  centralized  configuration  and  management  makes  this  
architecture  very  attractive  to  smaller  campuses  and  distributed  deployments.    
 
2. Self-­‐optimizing  and  self-­‐healing  –  Key  functions  like  RF  optimization,  role-­‐based  access  
control,  and  QoS  enforcement  are  distributed  across  the  APs  deployed.  Not  relying  on  
one  piece  of  hardware  for  key  WLAN  functions  takes  the  onus  off  of  a  central  appliance,  
thereby  reducing  the  chances  of  a  single  point  of  failure.    
 
Most  distributed  architectures  have  a  way  to  elect  a  master  AP  amongst  the  APs  
deployed  that  is  able  to  act  as  a  virtual  controller  for  the  deployment.  This  AP  hosts  the  
central  console  for  configuration,  visibility  and  firmware  updates.    
 
Intelligent  algorithms  ensure  that  the  master  AP  is  used  only  for  configuration  and  
visibility,  but  the  control  plane  itself  exists  amongst  the  APs  deployed  to  offer  a  highly  
robust  and  a  self-­‐healing  network.  This  architecture  is  built  on  top  of  the  legacy  fat  AP  
architecture  with  some  benefits  borrowed  from  centralized  controller-­‐based  

 
 architecture.    
 
3. Enterprise  grade  security  –  Similar  to  the  controller-­‐based  architecture,  the  
controllerless  architecture  has  a  built-­‐in  stateful  firewall  that  keeps  track  of  the  state  of  
network  connections  travelling  across  it.  The  firewall  can  be  programmed  to  distinguish  
legitimate  packets  for  different  types  of  connections.    
 
Only  packets  matching  a  known  connection  state  will  be  permitted  by  the  firewall,  
others  will  be  rejected.  The  firewall  provides  identity-­‐based  controls  to  enforce  
application-­‐layer  security,  prioritization,  traffic  forwarding,  and  network  performance  
policies  for  wired  and  wireless  networks.    
 
Using  the  built-­‐in  firewall,  organizations  can  enforce  network  access  policies  that  specify  
whom  may  access  the  network,  which  areas  of  the  network  they  may  access,  and  the  
performance  thresholds  of  various  applications.    
 
For  organizations  adopting  emerging  applications  such  as  Voice  over  Wi-­‐Fi,  the  firewall  
module  provides  advanced  voice  management  capabilities  with  enhanced  visibility  and  
control  into  voice  sessions.    
 
4. Simple  to  expand  –  Growing  a  controllerless  network  is  just  as  easy  as  plugging  in  
additional  APs  on  the  same-­‐wired  network,  typically  the  same  subnet.  The  distributed  
algorithms  ensure  organic  growth  with  automated  provisioning  capabilities  wherein  the  
new  AP  automatically  joins  the  existing  network  and  inherits  the  configuration  without  
user  intervention.    
 
Multiple  APs  can  work  cohesively  in  a  subnet  and  across  multiple  subnets  with  special  
configurations  to  enable  mobility  and  other  related  services.    
 
5. Lower  cost  –  Given  the  APs  are  the  heart  of  a  distributed  architecture;  the  overall  cost  
of  the  deployment  is  lower  as  compared  to  traditional  controller-­‐based  architecture.  In  
addition,  lack  of  support  for  advanced  features  and  services  on  a  controllerless  
architecture  removes  the  need  for  additional  software  licenses  that  a  customer  would  
want  to  buy.  
 
The  reduction  in  need  for  additional  software  licenses  further  lowers  the  total  cost  of  
the  deployment,  which  is  very  attractive  to  smaller  enterprises  with  a  challenging  IT  
budget.    
 
6. Minimum  IT  support  –  Vendors  have  taken  the  utmost  care  to  ensure  that  the  services  
offered  by  a  controllerless  architecture  are  easy  to  deploy  and  do  not  require  a  team  of  
network  engineers  to  install  and  manage.  This  makes  controllerless  architecture  a  
perfect  choice  for  small  campuses  and  other  distributed  remote  office  deployments.    
 

 
 7. Built-­‐in  migration  path  –  Aruba  is  unique  in  offering  a  built-­‐in  migration  path  for  
organizations  that  want  to  transition  from  a  controllerless  to  a  controller-­‐based  
architecture.    
 
Controllerless  APs  can  easily  convert  to  controller-­‐based  APs  once  they  find  a  controller  
appliance  on  the  network.  Once  converted,  the  WLAN  administrators  can  enjoy  all  the  
benefits  of  a  centralized  controller-­‐based  deployment  as  explained  in  the  previous  
sections.    
 
Which  architecture  should  I  deploy?  
 
In  order  to  select  the  best  architecture  for  your  unique  requirements,  let  us  divide  the  campus  
deployment  into  three  different  categories  based  on  size  and  scope.    
 
1.  Large  campus  –  Groups  of  buildings  in  one  or  multiple  locations  that  require  hundreds  to  
thousands  of  APs  to  provide  wireless  access.  These  buildings  often  have  a  contiguous  RF  
domain.  Typically,  university  campuses,  higher  education,  hi-­‐tech  companies,  large  enterprises,  
financial  services  and  large  healthcare  facilities  fall  into  this  category.  
 
2.  Medium  campus  –  Group  of  buildings  in  one  location  that  is  typically  served  by  a  few  
hundred  APs.  These  buildings  might  have  a  contiguous  RF  domain  while  In  some  cases  these  
buildings  might  not  have  a  contiguous  RF  domain    
 
3.  Small  campus  –  Standalone  building  in  one  location  that  is  typically  served  by  a  few  dozen  
APs.    
 

 
  
 
Large  campus  environments  typically  deploy  a  controller-­‐based  architecture  due  to  the  
following  drivers:    (a)  ease  of  management  across  a  large  network;  (b)  roaming  performance  
across  a  contiguous  RF  domain;  (c)  ease  of  applying  a  consistent  security  and  QoS  policy  across  
a  large  network.  
 
Medium  sized  campuses  such  as  K-­‐12  school  districts,  smaller  enterprises,  hospitality  and  some  
healthcare  facilities  with  advanced  requirements  often  deploy  the  controller-­‐based  architecture.  
Often  the  need  for  mobility  services  or  the  demand  for  consistent  security  policy  enforcement  
will  drive  customers  to  invest  in  a  controller-­‐based  architecture.  When  IT  resources  are  limited  
or  there  is  not  a  contiguous  RF  domain,  customers  will  usually  invest  in  a  controllerless  
architecture  and  if  their  requirements  evolve,  then  add  a  controller  at  a  later  time.    
 
Smaller  campuses  that  have  a  few  hundred  users  in  a  standalone  building  usually  deploy  a  
controllerless  architecture.    
 
We  recommend  customers  to  not  only  think  of  the  requirements  today,  but  also  future  
requirements.  Be  strategic  and  build  a  future-­‐proof  network.    
 
WLAN  controller  evolution  
 

 
  
 
Software-­‐defined  networking  (SDN)  as  a  technology  has  slowly  started  to  gain  traction  in  the  
data  center  world.  The  fundamental  concept  of  SDN  is  the  separation  of  a  network’s  control  
plane  and  forwarding  planes  to  make  it  easier  to  optimize  each  other.  The  WLAN  space  is  also  
going  through  similar  changes.    
 
With  extensive  knowledge  about  users,  devices,  application  and  location  the  WLAN  controller  
has  an  abundance  of  contextual  information.  It  is  a  natural  move  for  WLAN  vendors  to  couple  
the  SDN  functionality  within  the  centralized  controller  so  that  customers  can  build  mobility-­‐
defined  networks.    
 
In  this  environment,  a  controller  acts  as  a  brain,  providing  an  abstract,  centralized  view  of  the  
overall  network.  In  the  above  figure,  the  SDN  controller  hosts  applications  and  services.  
Through  the  controller,  network  administrators  can  quickly  and  easily  create  and  push  out  
decisions  on  how  the  underlying  systems  in  the  forwarding  plane,  switches  and  APs,  will  handle  
traffic.    
 
The  most  common  protocol  used  in  SDN  networks  to  facilitate  communication  between  the  
controller  (called  the  southbound  API)  and  the  switches  is  called  OpenFlow.  An  SDN  
environment  also  uses  open  application  programmatic  interfaces  (APIs)  to  support  all  the  
services  and  applications  running  over  the  network.    
 

 
These  APIs,  commonly  called  northbound  APIs,  facilitate  innovation  and  enable  efficient  service  
orchestration  and  automation.  As  a  result,  SDN  enables  a  network  administrator  to  shape  
traffic  and  deploy  services  that  address  changing  business  needs,  without  having  to  touch  each  
individual  switch  or  router  in  the  forwarding  plane.    
 
This  means  –  when  user  A  makes  a  Lync  call  to  User  B,  the  SDN  controller  is  able  to  dynamically  
program  the  path  that  the  RTP  media  packets  should  take,  such  that  not  all  user  traffic  is  sent  
upstream  to  the  controller.  Rather,  the  media  packets  take  the  most  optimized  path  without  
losing  the  centralized  intelligence  and  operational  benefits  of  having  a  WLAN  controller.    
 
This  will  be  the  next  major  innovation  that  makes  wireless,  coupled  with  SDN  technology,  a  
strategic  part  of  the  network.  Wireless  employed  at  the  core  and  the  wired  network  the  way  it  
is  today,  acting  as  an  overlay  to  the  wireless  traffic.    
 
 
   

 
REMOTE  NETWORKS  
 
A  remote  or  a  distributed  deployment  is  an  operation  with  multiple  locations  that  are  
geographically  distributed  across  a  limited  geography,  or  across  the  entire  globe.  Examples  of  
remote  networks  are  home  offices  for  large  hi-­‐tech  enterprises,  a  satellite  campus  for  a  
university,  retail  chains  and  hotel  chains.    
 
These  days,  organizations  are  more  distributed  than  ever  because  of  the  cost  saving  and  
increased  productivity  that  is  associated  with  employing  a  distributed  workforce.  A  distributed  
enterprise  might  be  a  collection  of  branch  offices,  home  offices,  or  a  combination  of  both.  The  
number  of  distributed  sites  and  user  density  vary  across  organizations.  The  way  in  which  these  
remote  sites  connect  to  the  data  center  or  headquarters  also  varies.  Some  enterprises  use  
services  such  as  MPLS,  while  others  use  VPNs.    
 
Decision  criteria  for  a  branch  
 
For  remote  deployments  there  are  some  key  questions  that  one  must  answer  in    
order  to  determine  the  architecture  that  best  fits  the  needs.    
 
These  factors  are  as  follows:    
1. Size  of  the  deployment  –  The  number  of  users  and  devices  vary  based  on  organizations.  
2. Type  of  branch  –  In  general  a  branch  can  be  classified  either  as  a  
a. Greenfield  branch  –  Wherein  there  is  no  underlying  network  infrastructure  
present,  there  is  the  potential  to  deliver  a  “branch  in  a  box”  solution.  
b. Brownfield  branch  –  Where  there  is  already  a  basic  network  in  place  that  might  
include  the  WAN  infrastructure  or  a  Layer  2/Layer  3  switch.    
3. Service  requirements  –  Of  all  the  factors,  the  key  deciding  factor  that  will  determine  
one  architecture  over  the  other  are  the  services  that  are  required  in  the  branch.  This  can  
be  classified  into  two  major  categories  
a. Basic  services  –  This  includes  reliable  and  secure  wireless  access  that  is  easy  to  
deploy,  manage  and  maintain.  
b. Advanced  services  –  This  includes  cloud-­‐based  services  like  WAN  optimization,  
content  filtering  and  policy-­‐based  routing  that  enables  next  generation  services  
in  addition  to  secure  wireless  access.  
4. Existing  campus  network  –  Lastly,  the  architectural  decision  for  a  distributed  
environment  is  often  influenced  heavily  by  the  existing  campus  architecture  in  order  to  
maintain  architectural  and  operational  uniformity.    
 

 
  
 

 
Branch  with  basic  wireless  services  

 
The  size,  scale  and  the  scope  of  any  branch  office  is  typically  less  than  what  one  would  see  in  a  
campus.  In  a  branch  office  environment,  scalability  of  services  and  mobility  become  less  
important.  It  is  more  important  to  have  a  solution  that  is  plug-­‐and-­‐play,  highly  redundant  and  
resilient  to  WAN  outages.    
 
Controllerless  architecture,  with  all  the  innovation  that  vendors  have  put  in,  becomes  an  ideal  
choice  for  large  distributed  enterprises  over  a  controller-­‐based  architecture  for  brownfield  
branches.  
   
Features  that  can  be  delivered  by  a  controllerless  branch  architecture  include:    
 
Reliable  wireless  access  –  Deliver  reliable  wireless  access  to  connect  the  endpoint  devices  with  
minimal  IT  staff.    
 
Authentication  and  security  –  Provide  secure  network  access  to  the  endpoints,  and  keep  the  
network  secure  against  rogues  and  other  attacks.  
 
QoS  –  For  multimedia  applications,  the  branch  network  needs  to  support  enterprise  class  QoS  
to  support  applications  like  voice,  video  and  UCC.    
 

 
Plug-­‐and-­‐play  services  –  The  branch  network  needs  to  support  newer  generation  services  like  
an  Apple  TV  and  Chromecast  so  that  users  can  build  an  all  wireless  office  environment.  
 
Cloud-­‐based  zero  touch  provisioning  –  Given  the  number  of  branch  offices  that  an  enterprise  
might  have,  the  more  plug  and  play  the  solution  is,  the  easier  it  is  to  roll  out  in  large  scale.    
 
Secure  corporate  connectivity  –  Depending  on  the  traffic  type,  the  branch  office  solution  needs  
to  be  able  to  route  traffic  back  to  HQ  securely  so  that  the  users  at  the  branch  can  get  their  work  
done.  
 
Centralized  management  –  It  is  critical  that  an  administrator  is  able  to  install,  manage  and  
troubleshoot  these  distributed  branch  networks  from  one  central  location.  
 
Branch  with  advanced  services    

 
 
In  the  previous  section  we  looked  at  a  simplistic  branch  that  needed  wireless  access.  A  
controllerless  deployment  was  an  ideal  fit.  There  are  certain  branch  deployments  that  need  
advanced  services  on  top  of  wireless  access.    
 
Features  that  can  be  delivered  by  a  controller-­‐based  branch  architecture  include:    
 

 
Unification  of  wired  and  wireless  policies  –  Some  of  these  branch  office  appliances  will  need  
wired  Ethernet  ports  for  plugging  in  devices  like  cameras,  phones  and  printers.  Similar  policies  
for  wired  and  wireless  devices  need  to  be  applied  in  this  environment.  A  controller-­‐based  
architecture  enables  unification  of  security  policies,  and  further  helps  with  management  and  
troubleshooting  of  the  branch  network  as  a  whole.  
 
Intelligent  and  dynamic  WAN  optimization  –  Techniques  like  compression  and  acceleration  
further  ensure  that  the  scarce  WAN  resources  are  utilized  effectively.    
 
Survivability  –  The  branch  needs  the  capability  to  support  multiple  uplinks  from  ISPs,  and  
implement  policy-­‐based  routing  to  use  the  WAN  resources  efficiently.  
 
Advanced  security  –  Large  distributed  organizations  need  an  array  of  techniques  to  combat  
blended  attacks.  Managing  multiple,  separate  security  tools  can  be  overwhelming,  inefficient  
and  expensive.  Advanced  tools  that  enable  Unified  Threat  Management  (UTM)  are  beneficial  
for  these  branches.  
 
Content-­‐based  classification,  behavioral  analysis  and  reputation-­‐based  systems  further  enable  
the  visibility  and  control  that  is  needed  to  track  usage,  and  further  control  branch  traffic.  
Centralized  encryption  ensures  that  all  user  traffic  is  encrypted,  and  guarantees  comprehensive  
end-­‐to-­‐end  security.    
 
Multiple  uplink  options  –  In  the  case  of  a  WAN  failure,  the  branch  network  should  be  able  to  
offer  alternative  uplink  options  like  3G  and  4G,  so  that  the  network  is  highly  available.  
 
Architectural  parity  with  a  campus  network  –  For  a  customer  who  is  used  to  a  controller-­‐based  
architecture  at  the  campus,  having  smaller  form  factor  appliances  with  built-­‐in  WLAN  controller  
functionality  at  the  branch  will  maintain  architectural  and  operational  consistency.    
 
Greenfield  branch  with  basic  wireless  services  –  A  brand  new  branch  even  with  basic  wireless  
requirements  should  consider  the  appliance-­‐based  unified  wired  and  wireless  solution  in  order  
to  deliver  an  integrated  network.  
 
These  branch  services  can  be  fulfilled  by  a  cloud-­‐enabled  services  controller.    
 
   

 
Conclusion  
 
The  early  days  of  enterprise  WLAN  saw  the  first  architectural  battle  between  fat  APs  and  
controller-­‐based  thin  APs.  The  battle  was  won  by  the  thin  AP-­‐based  centralized  architecture,  
both  in  technology  and  the  marketplace.    
 
The  next-­‐generation  battle  in  the  WLAN  is  now  focused  on  which  architecture  is  more  efficient  
and  resilient,  centralized  or  distributed.  In  this  white  paper  we  have  looked  at  the  attributes  
and  unique  benefits  of  each  of  these  architectures.    
 
For  large  to  medium  sized  campus  deployments  consisting  of  hundreds  or  thousands  of  access  
points  and  concurrently  servicing  thousands  of  users,  the  benefits  of  a  centralized  controller  are  
evident.  However,  for  certain  stand-­‐alone  deployments,  a  dedicated  controller  may  pose  
certain  technical  or  economic  hurdles,  wherein  a  distributed  architecture  fits  in.    
 
There  is  definitely  a  gray  area  between  the  medium  and  large  campuses  where  either  
architecture  seems  to  be  a  fit  in  its  own  way.  It  is  up  to  the  customer  to  look  at  the  business  
and  technical  requirements  that  they  are  trying  to  solve  today,  think  about  how  the  network  
will  evolve  in  upcoming  years,  and  pick  the  best  architecture  that  satisfies  both  present  and  
future  needs.    
 
Remote  deployments  are  becoming  more  common  these  days.  This  could  be  an  extension  of  a  
corporate  campus  or  a  distributed  retail  chain.  For  deployments  like  these  with  basic  wireless  
access,  a  distributed  model  has  been  the  architecture  of  choice.    
 
As  the  deployment  grows,  some  vendors,  like  Aruba  Networks,  enable  customers  to  migrate  
from  a  distributed  to  centralized  architecture  by  simply  adding  a  controller  to  the  network  and  
upgrading  the  AP  software.  
 
In  cases  where  the  campus  is  already  using  a  centralized  architecture,  and  the  IT  team  is  already  
familiar  with  it,  one  can  add  a  form  factor  controller  to  each  remote  site  to  maintain  
architectural  consistency.    
 
Lastly,  for  remote  sites  that  not  only  need  wireless  access,  but  also  require  advanced  cloud  
services  like  WAN  optimization,  policy-­‐based  routing  and  some  wired  Ethernet  ports,  using  a  
controller  at  each  branch  has  been  the  preferred  route.    
 
WLAN  vendors  have  developed  significant  innovation  to  enable  a  wide  array  of  architectures.  
Each  customer  network  is  different;  the  requirements  and  success  criteria  for  each  network  
varies.  It  is  critical  that  that  customers  look  at  their  requirements  and  select  the  architecture  
that  best  enables  them  to  succeed  today  and  as  their  business  grows.