Serval: Software Defined Service-Centric Networking
34
-
Upload
open-networking-summits -
Category
Technology
-
view
105 -
download
3
Transcript of Serval: Software Defined Service-Centric Networking
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
