Serval: Software Defined Service-Centric Networking

Post on 18-Jul-2015

106 views 3 download

transcript

Serval:  So*ware  Defined    Service-­‐Centric  Networking  

Jen  Rexford  Erik  Nordstrom,  David  Shue,  Prem  Gopalan,    

Rob  Kiefer,  Mat  Arye,  Steven  Ko,  Mike  Freedman  

Princeton  University  

serval-­‐arch.org  

Internet  of  the  1970s  

Network  designed  for  accessing  a  specific  host.  

IMP  0  h1  

h2  

IMP  1  

h4  

h3  PDP-­‐11  

SDS  Sigma   SDS  940  

UCLA     Stanford  

*p,  telnet  

Service-­‐Centric  Networking  

1970s  

1980s  

1990s  

2000s  

Users  agnosWc  of  actual  service  instance  and  its  locaWon  

Challenges:  MulWplicity  and  Dynamism  

•  Service  with  dynamic  pool  of  replicas  – Challenge:  keep  service  resoluWon  up-­‐to-­‐date  

Replicated  Web  Service  

Load  Balancer  

Failure  Internet  

Challenges:  MulWplicity  and  Dynamism  

•  IaaS  with  dynamic  traffic  demand  – Challenge:  migrate  VMs  to  balance  network  load  

VM  MigraWon  

VM  MigraWon  

Internet  

Challenges:  MulWplicity  and  Dynamism  

• Mobile  end-­‐hosts  with  mulWple  interfaces  – Challenge:  seamless  service  access  across  virtual  migraWons  and  physical  mobility  

Cellular  Provider  

Enterprise  Network  

Physical  Mobility  

4G  

MulW-­‐  Homing  

Transit  Provider  

SupporWng  Modern  Services  

•  Defining  “the  right”  abstracWons  – Service  naming  

– Service-­‐level  events  – Common  APIs  

•  SeparaWng  control  and  data  – Programmability  through  a  well-­‐defined  data  plane  – Policy/control  through  a  flexible  control  plane  

Service-­‐Centric  AbstracWons  

•  Service  =  group  of  processes  with  same  funcWonality  – Have:  IP  address  +  port  number  – Problems:  Slow  DNS  failover  due  to  caching,  inefficient  and  costly  stateful  load  balancers  with  fate  sharing  

– Want:  Service  names  with  a  group  abstracWon  that  hide  composiWon  and  locaWon  

•  Flow  =  dynamic  service  communicaWon  context  – Have:  Five-­‐tuple,  bound  to  interface  and  locaWon  – Problems:  ConnecWons  break  when  addresses  change  – Want:  Flow  names  decoupled  from  locaWon  and  underlying  communicaWon  interface  

A  Clean  Role  SeparaWon  in  the  Stack    

•  Naming  the  right  things  at  the  right  level  – What  you  access  (serviceID),  over  which  flows  (flowIDs),  and  at  which  service  instance  (IP  address)  

TCP/IP   Serval  

Transport  demux  (IP  +  port)  

Network  forward  (IP)  

forward  (IP)  

ApplicaWon  bind  (IP  +  port)   bind  (serviceID)  

Service  Access  

demux  (                                  )      serviceID      flowID  

Service  Names  (ServiceID)  

•  Different  granulariWes  of  services  – EnWre  distributed  Web  service  – Replicated  parWWon  in  back-­‐end  storage  – Set  of  peers  distribuWng  a  common  file  

•  ServiceIDs  allocated  in  blocks  – Ensures  global  uniqueness  – Enables  prefix-­‐based  aggregaWon  

•  ServiceID  carried  in  network  packets  – Service-­‐level  rouWng  – Late-­‐binding  to  a  service  instance  

AcWve  Sockets  

•  ApplicaWons  should  operate  on  service  names  

connect(fd,  serviceID)  bind(fd,  serviceID)  listen(fd)  

Network  stack  must  resolve  service  to  instance  for  client  

Network  stack  must  adver6se  service  for  server  

SeparaWng  Control  and  Data  

Kernel  Network  Stack  

ApplicaWon  Socket  

Service  Control  API  

ServiceID   Ac;on   Sock/Addr  

Service  Table  

bind(X)          close()    Control-­‐Plane  Protocol  

• Service  controller  • DNS  or  other  database  • OpenFlow  controller  

Dest  Address   Next  Hop  

IP  Forwarding  Table  

(un)register  X  

X  

Data  Plane:  The  Service  Table  

ServiceID   Ac;on   Rule  State  

Prefix  A   FORWARD   Send  to  addr  A1  

Prefix  B   FORWARD   Send  to  [A2,  A3,  A4]  

Prefix  C   DEMUX   Send  to  listening  sock  s  

Prefix  D   DELAY  Queue  and  noWfy  service  

controller  

Prefix  E   DROP  

*   FORWARD   Send  to  A5  

The  Service  Table  (SIB)  

ServiceID   Ac;on   Rule  State  

Prefix  A   FORWARD   Send  to  addr  A1  

Prefix  B   FORWARD   Send  to  [A2,  A3,  A4]  

Prefix  C   DEMUX   Send  to  listening  sock  s  

Prefix  D   DELAY  Queue  and  noWfy  service  

controller  

Prefix  E   DROP  

*   FORWARD   Send  to  A5  

The  Service  Table  (SIB)  

ServiceID   Ac;on   Rule  State  

Prefix  A   FORWARD   Send  to  addr  A1  

Prefix  B   FORWARD   Send  to  [A2,  A3,  A4]  

Prefix  C   DEMUX   Send  to  listening  sock  s  

Prefix  D   DELAY  Queue  and  noWfy  service  

controller  

Prefix  E   DROP  

*   FORWARD   Send  to  A5  

The  Service  Table  (SIB)  

ServiceID   Ac;on   Rule  State  

Prefix  A   FORWARD   Send  to  addr  A1  

Prefix  B   FORWARD   Send  to  [A2,  A3,  A4]  

Prefix  C   DEMUX   Send  to  listening  sock  s  

Prefix  D   DELAY  Queue  and  noWfy  service  

controller  

Prefix  E   DROP  

*   FORWARD   Send  to  A5  

The  Service  Table  (SIB)  

ServiceID   Ac;on   Rule  State  

Prefix  A   FORWARD   Send  to  addr  A1  

Prefix  B   FORWARD   Send  to  [A2,  A3,  A4]  

Prefix  C   DEMUX   Send  to  listening  sock  s  

Prefix  D   DELAY  Queue  and  noWfy  service  

controller  

Prefix  E   DROP  

*   FORWARD   Send  to  A5  

Ad  hoc  Service  Discovery  

ServiceID   Ac;on   Rule  State  

*   FORWARD   192.168.1.255  

X  

X  

1  

connect(X)  2  

3  

4  

4  

* X a 1 SRC

DST SYN

a 1 b 3 SRC

DST SYN-ACK

a 1 c 4 SRC

DST SYN-ACK

a  

c  

b  

Service-­‐Level  Forwarding  

Kernel  Network  Stack  

FlowID   Socket  

Flow  Table  

ServiceID   Ac;on   Sock/Addr  

Service  Table  

Dest  Address   Next  Hop  

IP  Forwarding  Table  

Service-­‐level  Forwarding  

Load  Balancing  Example  

Service Access

X

X

X d,e * a

Transport

sX  

X sX

* b

App

X b

IP a

b d

e

c

SYN

e X a 1

2  

b X a 1 SRC

DST

1  

SYN

a 1 e 2 SRC

DST

4  

e X a 1

SYN 3  

Transport  

FlowID   Socket  

Flow  Table  Service  Access  

Network  a1   a2  

flowID    fC2  

IP    interfaces  

Socket  s  

flowID    fC1  

Flow  demux’d  by  unique  local  flowID,  not  “5  tuple”  

ApplicaWon  

ConnecWons  with  MulWple  Flows  

MigraWon  and  MulWpath  

sC   sS  fS1  fC1  

fS2  fC2  

a1  

a2  

a3  

Host  C   Host  S  

a4  

MigraWon  and  MulWpath  

Local  flowID  

Local  Interface  

Remote  Interface  

fC1   a1   a3  

fC2   a2   a4  

Socket  Descriptor  

Remote  ServiceID   Cntrl  Seq  #   Local  

flowIDs  Remote  interfaces  

SC   X   seqC   fC1,  fC2   a3,  a4  

sC   sS  fS1  fC1  

fS2  fC2  

a1  

a2  

a3  

Host  C   Host  S  

a4  

Socket  State  

MigraWon  and  MulWpath  

Local  flowID  

Local  Interface  

Remote  Interface  

fC1   a1   a3  

fC2   a2   a4  

Socket  Descriptor  

Remote  ServiceID   Cntrl  Seq  #   Local  

flowIDs  Remote  interfaces  

SC   X   seqC   fC1,  fC2   a3,  a4  

sC   sS  fS2  

fS1  fC1  

fC2  

a1  

a2  

a3  

Host  C   Host  S  

a4  

a4  

Socket  State  

Prototype  

•  End-­‐host  network  stack  – Linux  kernel  module  

– BSD  sockets  with  AF_SERVAL  protocol  family  – AF_INET  sockets  can  be  accessed  simultaneously  

•  Legacy  middleboxes  /  NATs  handled  via  encap.  

•  Translator  for  incremental  deployment  – Unmodified  apps  and  end-­‐hosts  – Serval  apps  with  unmodified  services  

CompeWWve  Performance  

ApplicaWons  are  Easy  to  Port  

Example  ApplicaWons  

•  Server  replicas  – MulWple  Mongoose  servers  

– Balancing  load  over  live  server  instances  

•  Key-­‐value  store  parWWon  – MulWple  Memcached  servers  

– RouWng  requests  to  parWWons  based  on  the  key  

• MigraWng  flows  – Load  balancing  across  network  interface  cards  – MigraWng  virtual  machines  across  layer-­‐3  networks  

Making  Service  Management  Easier  

Controller  

X  

X  

X  

Managing  Switches  and  Services  

•  Switch  and  service  state  similar  – FIB:    <layer  2-­‐3  mask  |  ACTION  |  STATE>  – SIB:    <service  prefix  |  ACTION  |  STATE>  

•  So*ware  Defined  Networking  – OpenFlow  focuses  on  layer-­‐2/3  – Serval  extends  to  hosts,  services  

•  Read  events  and  write  rules  – With  FIB:    packets,  topology  changes,  flow  counters  – With  SIB:    host/interface  changes,  service  instance  changes,  connecWon/host/service  staWsWcs  

Controller

Switches

Ongoing  Research  

•  SDN  to  the  edges  – Joint  end-­‐host  and  switch  control  

•  So*ware-­‐defined  service  resoluWon  – Leveraging  legacy  systems  like  DNS  and  rouWng  – Ad  hoc,  local  service  discovery  

•  So*ware-­‐defined  path  selecWon  – MulWpath  and  interface  migraWon  in  datacenter  – Interface  selecWon  and  migraWon  on  mobile  devices  

serval-­‐arch.org  

Papers,  demos,  source  code  (GPL)  online