Download document 8758078

serval-­‐arch.org Serval: An End-­‐Host Stack for Service-­‐Centric Networking Erik Nordström David Shue, Prem Gopalan, Rob Kiefer, Mat Arye, Steven Ko, Jen Rexford, Mike Freedman Princeton University The Internet of the 1970s Killer Apps: telnet, Sp IMP 2 SRI IMP 4 Utah IMP 3 UCSB IMP 1 UCLA Network designed for accessing hosts The Internet of the 2000s Datacenter Datacenter Users agnosYc of actual service locaYon and host What does Service Access Involve? 1.  Locate a nearby service datacenter –  Map service name to locaYon 2.  Connect to service –  Establish data flow to instance –  Load balance between pool of replicas 3.  Maintain connecYvity to service –  Migrate between interfaces and networks Today’s (Overloaded) AbstracYons •  Service is IP + port –  Exposes locaYon –  Specifies app. protocol –  One service per IP TCP/IP connect (IP + port) ApplicaYon demux (IP + port) Transport •  Flow is “five tuple” –  Binds flow to interface and locaYon –  Cannot migrate between interfaces or networks Network Service Access Today Enterprise Network Datacenter Transit Provider 4G Cellular Provider Datacenter Finding a Service LocaYon Enterprise Network Transit Provider DNS 4G Cellular Provider Load-­‐Balanced Web Service •  DNS binds service to locaYon at client (early binding) –  Caching and ignoring TTL exacerbates the problem –  Slow failover when instance or load balancer fail ConnecYng to Service Enterprise Network Transit Provider 4G Cellular Provider Load-­‐Balanced Web Service •  Datacenter LB maps single IP to mulYple servers –  Must do this for every packet on path -­‐> fate sharing –  Increases complexity and cost Maintaining ConnecYvity to Service Enterprise Network Transit Provider VM MigraYon 4G Cellular Provider Datacenter •  Migrate VMs to balance load in the cloud –  Requires flat addressing or tunneling within datacenter Maintaining ConnecYvity to Service Enterprise Network 4G MulY-­‐ Homing Datacenter Transit Provider Datacenter Cellular Provider Physical Mobility •  Flows break when switching networks or interfaces ContribuYons •  Naming abstracYons –  Services, flows –  Clean role separaYon in the network stack •  SoSware architecture for services (Serval) –  Service-­‐level control/data plane split –  Service-­‐level events Naming AbstracYons Today’s (Overloaded) AbstracYons TCP/IP connect (IP + port) ApplicaYon demux (IP + port) Transport forward (IP) Network Serval AbstracYons •  Serval cleans the slate –  (But not completely) Serval •  Network layer unmodified! ApplicaYon •  Service Access Layer (SAL) Transport –  Connects to services –  Maintains connecYvity Service Access forward (IP) Network Serval AbstracYons •  Service = ServiceID –  Group of processes with idenYcal funcYonality •  Flow = FlowID –  Invariant demux key –  Host-­‐local, ephemeral •  LocaYon = IP address –  LocaYon, interface –  Can change dynamically Serval connect (serviceID) ApplicaYon Transport demux ( s erviceID ) Service flowID Access forward (IP) Network A Clean Role SeparaYon in the Stack •  What you access (serviceID), over which flows (flowIDs), and at which service instance (IP address) TCP/IP ApplicaYon connect (IP + port) Transport connect (serviceID) demux (IP + port) Service Access Network Serval demux ( s erviceID ) fl owID forward (IP) forward (IP) Service Names (ServiceIDs) Provider prefix Provider-­‐specific Self-­‐cerYfying •  ServiceIDs allocated in blocks –  Prefix ensures global uniqueness –  Prefix-­‐based aggregaYon and LPM •  A ServiceID late binds to service instance –  ServiceID in first packet of connecYon –  Service-­‐level rouYng and forwarding A Service-­‐Aware Network Stack connect(sock, serviceID) bind(sock, serviceID) listen(sock) Network stack must resolve service to instance for client Network stack must adver/se service for server SoSware Architecture Serval End-­‐host Architecture Service Controller ApplicaYon Service Control API FlowID Socket ServiceID Flow Table Ac;on Sock/Addr Service Table Dest Address Next Hop IP Forwarding Table 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 noYfy service controller Prefix E DROP default FORWARD Send to A5 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 noYfy service controller Prefix E DROP default FORWARD Send to A5 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 noYfy service controller Prefix E DROP default FORWARD Send to A5 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 noYfy service controller Prefix E DROP default FORWARD Send to A5 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 noYfy service controller Prefix E DROP default FORWARD Send to A5 Service Access with Serval X
Service Router d
Internet c
X
a
Datacenter e
Adding a Service Instance Register Service X Service Controller ApplicaYon bind(X) S listen() FlowID Socket ServiceID X Ac;on DMX Sock/Addr Add DEMUX rule s Removing a Service Instance Service Controller ApplicaYon Unregister Service X close() S FlowID Socket ServiceID X Ac;on DMX Sock/Addr s Remove DEMUX rule Control Plane: The Service Controller Service X @ address a Service Controller Service Controller DNS Control Plane: The Service Controller Service X @ address d Service Controller FlowID Socket ServiceID X Ac;on FWD Sock/Addr d Add FORWARD rule Service Access with Serval X
bind(X) X d,e Service Router X/24 c
c
@
4
X/2
Internet d
c
X
a
Datacenter e
bind(X) ConnecYng to Service X Service Controller ApplicaYon S socket() FlowID 2 Allocates local flowID Socket s ServiceID X Ac;on FWD Sock/Addr c a ConnecYng to Service X ApplicaYon S connect(X) FlowID 2 Socket s ServiceID X Ac;on FWD Sock/Addr c a To c a c 2 -­‐ X SYN Load Balancing in Service Router FlowID From a Socket c a c 2 -­‐ X SYN ServiceID X Ac;on Sock/Addr FWD d,e f To e a e 2 -­‐ X SYN Service Instance Providing Service X ApplicaYon S FlowID From a Socket e a e 2 -­‐ X SYN ServiceID X Ac;on DMX Sock/Addr s Service Instance Providing Service X ApplicaYon Sc S accept() FlowID 3 To a Socket sc e e a 3 2 SYN-­‐ACK ServiceID X Ac;on DMX Sock/Addr s Service Access with Serval a c X SYN a e X SYN X
X d,e Service Router d
Internet a
e a SYN-­‐ACK e a data c
X
Datacenter e
Ad hoc Service Discovery Accessing service X connect(X) b a CK A
-­‐
N
Y
S
X b a * X SYN a ServiceID Ac;on default FORWARD c a SYN-­‐A
CK X Rule State “broadcast” c What does Service Access Involve? 1.  LocaYng a nearby service datacenter –  Map service name to locaYon 2.  ConnecYng to service –  Establish data flow to instance –  Load balance between pool of replicas 3.  Maintaining connecYvity to service –  Migrate between interfaces and networks MigraYon of Flows sC fC1 a1 a3 a2 a4 Host C Migrate flow a1 -­‐> a2 fS1 Host S RSYN RSYN-­‐ACK ACK sS MulYpath with MulYple Subflows sC fC1 a1 a3 fS1 fC2 a2 a4 fS2 Host C Add flow a2 <-­‐> a4 Host S SYN SYN-­‐ACK ACK sS Prototype •  End-­‐host network stack (28,000 LOC) –  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 Incremental Deployment App TCP/IP Translator Serval Incremental Deployment Translator App Serval TCP/IP Translator TCP/IP Use of MigraYon on Clients WiFi Cellular Saves > 900 MB cellular data per month Single Serval TCP connecYon that never breaks Uses of MigraYon on Servers Load balancing across NICs Throughput (Mbps)
1000
800
Flow 1 moved to eth1 600
400
Both flows use eth0 200
Flow 1
Flow 2
0
0
2
4
6
8
Time (s)
10
12
Uses of MigraYon on Servers MigraYng VMs across subnets Throughput (Mbps)
200
Flow 1
150
100
VM changes subnet, acquiring new address 50
0
0
1
2
3
4
Time (s)
VM migrates flow to new address 5
6
7
CompeYYve Performance TCP Throughput Mean (Mbit/s) TCP/IP 934.5 Serval 933.8 Translator 932.1 Service Table Throughput IP forwarding Serval Mbit/s 987 872 Kpkt/s 388.4 142.8 ApplicaYons are Easy to Port Applica;on Iperf TFTP wget Elinks browser Firefox browser Mongoose webserver Memcached server Memcached client Codebase 5,934 3,452 87,164 115,224 4,615,324 8,831 8,329 12,503 Changes 240 90 207 234 70 425 159 184 SDN to the Edges! •  SDN about network-­‐wide visibility and control –  Today’s “SDN” (OpenFlow) primarily focuses on layer-­‐2 / layer-­‐3 abstracYons •  Serval extends SDN model to the network edge –  New programming abstracYons for services, flows, hosts, and interfaces –  Service-­‐level control/data plane split •  Joint service and network control Summary of ContribuYons •  New naming abstracYons –  Clean role separaYon in the stack –  Makes it easier to build and manage services •  SoSware architecture for services –  Flexible service resoluYon and discovery –  Maintains robust connecYvity –  Joint service and network management serval-­‐arch.org @servalnetwork Papers, demos, source code (GPL) online Related Work •  Locator/idenYfier separaYon –  HIP, i3, HAIR, DOA, LISP, LNA •  Data-­‐oriented networking –  DONA, CCNx •  Support for mobility and migraYon –  TCP Migrate, Mobile IP, ROAM •  MulYpath and mulY-­‐homing –  MPTCP, SCTP, Shim6