Software-Defined Networking for Services

enginestagΔίκτυα και Επικοινωνίες

26 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

65 εμφανίσεις

Software
-
Defined Networking

for Services

Mike Freedman

Joint work with Erik Nordstrom, David
Shue
, Rob Kiefer,

Mat
Arye
,
Prem

Gopalan
, Jen Rexford

Princeton University

Presented at NYC Software
-
Defined Networking
Meetup

December 19, 2011

serval
-
arch.org

Software Defined Networking


Expose API of data
-
plane


External control through


Packet handling via rule installation


Flow monitoring via rule counters


Deployment scenarios


Centralized controller


Layer 2/3 abstractions


Single administrative domain


…helps network operators

Controller

Switches

Cellular

Provider

Enterprise

Network

Physical

Mobility

4G

Multi
-
Site

Online Service

Provider

Replicated

Web Service

Partitioned

Storage

Service

Load

Balancer

Multi
-

H
oming

VM

Migration

[
a,g
]

[
h
,
n
]

[
o,
t
]

[
u
,
z
]

Transit

Provider

Failure

Challenges: Multiplicity and Dynamism

Challenges: Multiplicity and Dynamism


Replica selection?


Problem: Pool of live replicas changes, client needs to find good one


Keep fresh DB mapping end
-
hosts to services


Combine DNS / global traffic manager with local
stateful

load balancer


Home
-
brew monitoring and updates to DNS /
LBs


Insufficient visibility into services (e.g., virtual hosting or multi
-
tenants)


VM Mobility?


Problem: Live VM migration restricted to layer
-
2 subnet


Either stretch layer
-
2 across DC/WAN or use tunneling to soft switch


Client mobility?


Problem: Changing IP addresses cause connections to break


Cellular and
WiFi

providers often different admin domains

Abstraction Mismatch:


These are all service/app
-
level
concerns we’re trying to solve
through network hacks

Limitations of current SDN /
OpenFlow


Hard to program


Use in single admin domain


Currently limited to layer 2/3


Insufficient visibility



Serval

End
-
host

Stack

Frenetic

Programming

Language

New Abstractions for Network Services


Higher programming abstractions


Higher
-
level naming for services


System abstractions for connections
/ flows / interfaces


Semantics of services and
conn’s


Visibility b/w net, hosts, services



Frenetic

Programming

Language

Serval

End
-
host

Stack

Basic
Serval

Functionality


Socket abstraction on
serviceIDs
, not
IP:port


Apps connect() and bind() on
serviceIDs


Stack/network aware of app notion of service endpoint


Apps connect to service instance, not
IP:port


Connect() is name resolution and load
-
balanced
anycast


Packets on connected flow sent directly b/w endpoints


Connections can leverage network dynamism & diversity


Endpoints can change
addr
/interface via in
-
band signals


Connections can simultaneously use multiple interfaces



What are “services”?


Set of app instances that offer identical function


Client can initiate connection to any instance, but
maintains with one (due to session state)


ServiceIDs


Location independent


Hierarchically delegated (IANA


Google


YouTube)


Format: Prefix for uniqueness/delegation

Core of
Serval

Architecture:

Service Access Layer (SAL)


SAL between network and transport layers


Handles services and connections



TCP/IP

Serval

Transport

demux

(IP + port)

Network

forward (IP)

forward (IP)

Application

bind (IP + port)

bind (
serviceID
)

Service

Access

demux

( )


serviceID


flowID

[NSDI’12]

Serval

End
-
Host Architecture

Transport

Kernel

Network

Stack

User

Space

Application

Service
Controller

FlowID

Socket

Flow Table

Data Delivery

ServiceID

Action

Sock/
Addr

Service Table

Service

Access

Network

Dest

Address

Next Hop

IP Forwarding Table

connect(s,X
)

send(s
)

Service Table (SIB) Actions

ServiceID

Action

Rule State

Prefix

A

FORWARD

Send to
addr

A1

Prefix

B

FORWARD

Send to

[A2, A3, A4
]

Prefix

C

DEMUX

Send

to l
ocal sock

s

Prefix D

DROP

Prefix E

DELAY

Queue

and notify
l
ocal
netlink

sock
c

*

FORWARD

Send to A5

Service routing tables

Service Access

X

X

*

e

X

f,g

*

b

Transport

s
X

X

s
X

*

e

App

*

b

IP

a

b

c

d

e

f

g

Service
-
aware
anycast

IP

Service Access

a

b

c

d

e

f

g

X

X

*

e

X

f,g

*

b

Transport

s
X

SYN

X

s
X

*

e

App

*

b



First (SYN) packet routed on
serviceID

Connection affinity and direct return

IP

Service Access

a

b

c

d

e

f

g

X

X

*

e

X

f,g

*

b

Transport

s
X

SYN

X

s
X

*

e

App

*

b



Response piggybacks IP address of resolved destination



All subsequent packets directly between endpoints

Serval

End
-
Host Architecture

Kernel

Network

Stack

FlowID

Socket

Flow Table

User

Space

Application

Service
Controller

Data Delivery

Socket

Service

Control API

ServiceID

Action

Sock/
Addr

Service Table

Active
Sockets

bind() close()


Control
-
Plane Protocol


Service router


DNS or other DB


OpenFlow

controller

Conn’d

Flow

SYN
Datagram

Dest

Address

Next Hop

IP Forwarding Table

fre
net
ic >>

Transport

FlowID

Socket

Flow Table

Service

Access

Network

a1

a2

flowID

f
C2

IP

interfaces

Socket
s

flowID

f
C1

Flow
demux’d

by unique local
flowID
, not “5
tuple


Application

Connections can have multiple flows

Service
Controller

a1

Prototype and Incremental Deployment


End
-
host network stack


Multi
-
platform (Linux, Android, BSD)


Runs in user space and in the kernel


Flexible, decentralized service discovery


Unmodified applications: end
-
host can translate
between
IP:port

and
serviceIDs


Unmodified end
-
hosts: TCP
-
to
-
Serval

translator


Handling legacy
middleboxes

/
NATs

via
encap




Uses and Deployment Scenarios


(Wide
-
area) datacenter services


Dynamic load balancing between machines,
NICs


Layer
-
3 VM migration: layer
-
3 multi
-
rooted DC network


Ad
-
hoc networks


Service discovery fundamental, late binding useful for
DTNs


Mobile clients


Service naming and discovery, for both infrastructure & ad
-
hoc


Client mobility between cell towers without Mobile IP


Client mobility between wired,
WiFi
, and 3G based on policy,
changing network conditions

Managing networks and services


Service and forwarding table state similar


SIB: <service prefix | ACTION | STATE>


FIB: <layer 2
-
3 bitmask | ACTION | STATE>


Software 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,
connection/host/service statistics

Controller

Switches

Summary


Need for new network abstractions


“Services” as basic network abstraction


Service and connection management layer b/w network / transport


Support for multiplicity (naming, discovery) and dynamism (service
adaptation, connection migration)


Network management requires programmability



Clean
architecture that provides “right” abstractions


Does so by mostly returning to “dumb” network of 1970s


Re
-
empowering end
-
hosts + opening up APIs

serval
-
arch.org



Papers, demos, source code online