Outline The “Next” Internet: More of the Same?prs/15-744-F12/lectures/14-FIA.pdf · • Named Internet Architecture • Content centric networking - data is a first class entity

1

15-744: Computer Networking

L-14 Future Internet Architecture

Readings

• Required:• Serval paper• Extra reading on Mobility First

• Relevant earlier meeting:• CCN -> Named Data Network

2

Outline

• Motivation and discussion

• Some proposals:• CCN• Nebula• Mobility First

• XIA

3

The “Next” Internet: More of the Same?

4

Internet 2Next GenerationInternet

IntegratedServicesNetworks

FutureInternetArchitecture

Performance DiverseService, QoS “-ilities”

Internet Architecture Fixed Change Me!

2

Four “FIA” Projects

• Mobility First• Mobility as the norm rather than the exception –

generalizes delay tolerant networking• Named Internet Architecture

• Content centric networking - data is a first class entity

• Nebula• Internet centered around cloud computing data

centers that are well connected• eXpressive Internet Architecture

• Focus on trustworthiness, evolvability

5

Key Internet Features

What we learned about the current Internet:• Simple core with smart endpoints• The IP narrow waist supports evolution• Addresses have topological meaning• Packet-based communication• All IP hosts can exchange packets• Non-essential functions are services• End-to-end transport protocols• Security is not part of the architecture

6

But maybe there are better ways …

Outline


• Some proposals:• CCN• Nebula: slides …• Mobility First

• XIA

7

CCN Discussion

• Simple core with smart endpoints• The IP narrow waist supports evolution• Addresses have topological meaning• Packet-based communication• All IP hosts can exchange packets• Non-essential functions are services• End-to-end transport protocols• Security is not part of the architecture

8

3

Outline

• Motivation and discussion• Some proposals:

• CCN• Nebula

• Overview• Serval

• Mobility First

• XIA: Wednesday

9

Motivation and Challenges

Cloud UserSensor

AdviceDoctor

An internet that supports trustworthy cloud computing:

10

• Security and trustworthiness• Correctness

• Highly available and reliable services• Whenever, wherever

• Evolve with technology• Low latency, increasing bandwidth

• Economic and regulation

NEBULA Internet Architecture

• NEBULA data plane (NDP)• Flexible wrt policy, distributed, verifiable

• NEBULA control plane: virtual & extensible networking (NVENT) • Trust, isolation• Independent from NDP

• NEBULA core(Ncore)• Routers and datacenters

11

Data Plane Design

• Data plane interface allows an arbitrary control plane over a fixed data plane• Control plane can implement different security

policies• Packet forwarding based on a path spec that

includes 4 elements per AD hop1. An identifier domain for the domain 2. A Proof of Consent (PoC) – proves provider

consented to forwarding the packet3. A Proof of Provenance (POP) – nodes prove to

downstream nodes that they forwarded packet4. An token that encodes policy rules for how to

forward packet, e.g., QoS, middleboxes, …12

4

NDP Packet Header

• Focus is on expressing and enforcing policies• Was the packet authorized (PoC)?• Internal resource (token)?• Did it actually follow the PoC path (PoP)?

13

Routing and Forwarding in Nebula

• NDP requests path

• NVENT picks based on policy

• Assured path return to NDP

• Inserted into NDP packet

• Path is checked on every step

14

ICING: Verifying and Enforcing Paths

• Assumes a separate mechanism for path selection• Each node must:

1. Verify that path is approved2. Verify that path has been correctly so far3. Prove to downstream nodes that it has seen packet

15

“Verifying and enforcing network paths with ICING”, Jad Naous, Michael Walfish, et. al, CoNext 2011

NEBULA Core

• Ncore is highly connected and high capacity router that also functions as a data center• Forwarding and computing “close”

• High availability via redundant high throughput links

• A routing complex from multiple chassis

16

5

Outline

• Motivation and discussion• Some proposals:

• CCN• Nebula

• Overview• Serval (based on slides by authors)

• Mobility First

• XIA: Wednesday

17

The Internet of the 1970s

Network designed for accessing hosts

Killer Apps: telnet, ftp

IMP 1UCLA

IMP 4Utah

IMP 2SRI

IMP 3UCSB

Users agnostic of actual service location and host

The Internet of the 2000s

DatacenterDatacenter


What does Service Access Involve?

1. Locate a nearby service datacenter• Map service name to location

2. Connect to service • Establish data flow to instance• Load balance between pool of replicas

3. Maintain connectivity to service• Migrate between interfaces and

networks

6

Today’s (Overloaded) Abstractions

• Service is IP + port• Exposes location• Specifies app. protocol• One service per IP

• Flow is “five tuple”• Binds flow to interface

and location• Cannot migrate

between interfaces or networks

TCP/IPTCP/IP

demux (IP + port)demux (IP + port)

NetworkNetwork

connect (IP + port)connect (IP + port)

TransportTransport

ApplicationApplication

CellularProviderCellularProvider

EnterpriseNetwork

EnterpriseNetwork

4G4G

TransitProviderTransit

Provider

Service Access Today



Finding a Service Location

Load-BalancedWeb Service


• DNS binds service to location at client (early binding)– Caching and ignoring TTL exacerbates the problem– Slow failover when instance or load balancer fail

DNS

Connecting to Service



• Datacenter LB maps single IP to multiple servers– Must do this for every packet on path -> fate sharing– Increases complexity and cost

7

Maintaining Connectivity to Service

VM Migration

VM Migration


• Migrate VMs to balance load in the cloud– Requires flat addressing or tunneling within datacenter

CellularProviderCellularProvider

EnterpriseNetwork

EnterpriseNetwork

4G4G

Maintaining Connectivity to Service

PhysicalMobilityPhysicalMobility

Multi-HomingMulti-

Homing

• Flows break when switching networks or interfaces

Contributions

• Naming abstractions• Services, flows• Clean role separation in the network stack

• Software architecture for services (Serval)• Service-level control/data plane split• Service-level events

Today’s (Overloaded) Abstractions

TCP/IPTCP/IP


NetworkNetworkforward (IP)forward (IP)

connect (IP + port)connect (IP + port)

TransportTransport


8

ServiceAccessServiceAccessNetworkNetworkforward (IP)forward (IP)

Serval Abstractions

• Serval cleans the slate• (But not completely)

• Network layer unmodified!

• Service Access Layer (SAL)• Connects to services• Maintains connectivity

TransportTransport


ServalServal

Serval Abstractions

• Service = ServiceID• Group of processes with

identical functionality• Flow = FlowID

• Invariant demux key• Host-local, ephemeral

• Location = IP address• Location, interface• Can change dynamically

connect (serviceID)connect (serviceID)

TransportTransport


demux ( )serviceID

NetworkNetworkforward (IP)forward (IP)

ServiceAccessServiceAccessflowID

ServalServal

A Clean Role Separation in the Stack

• What you access (serviceID), over which flows (flowIDs), and at which service instance (IP address)

TCP/IPTCP/IP ServalServal


forward (IP)forward (IP) forward (IP)forward (IP)

connect (IP + port)connect (IP + port) connect (serviceID)connect (serviceID)

demux ( )serviceIDflowID

TransportTransport

NetworkNetwork


ServiceAccessServiceAccess

Service Names (ServiceIDs)

• ServiceIDs allocated in blocks• Prefix ensures global uniqueness• Prefix-based aggregation and LPM

• A ServiceID late binds to service instance• ServiceID in first packet of connection• Service-level routing and forwarding

Provider prefix

Provider-specific Self-certifying

9

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 advertise service

for server

Contributions

• Naming abstractions• Services, flows• Clean role separation in the network stack

• Software architecture for services (Serval)• Service-level control/data plane split• Service-level events

Service Controller

Serval End-host Architecture

ServiceID Action Sock/AddrFlowID Socket

Application

DestAddress

Next Hop

IP Forwarding TableIP Forwarding Table

Flow TableFlow Table Service TableService Table

ServiceControl API

ServiceControl API

Data Plane: The Service Table

ServiceID Action 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 notify service controller

Prefix E DROP

default FORWARD Send to A5

10

Internet

Service Access with Serval

XX

XX

aa

ccdd

eeDatacenter

ServiceRouter

Adding a Service Instance


ApplicationService

Controller

SS bind(X)listen()

Add DEMUX rule

X DMX s

RegisterService X

Removing a Service Instance


Application

Service Controller

SS close()

Remove DEMUX rule

X DMX s

UnregisterService X

Control Plane: The Service Controller

Service Controller

Service X@ address a

Service Controller

DNS

11

Control Plane: The Service Controller


Service Controller

Add FORWARD rule

X FWD d

Service X@ address d

Internet


XX

XX

aa

ccdd

eeDatacenter

X d,e

X/24 c

ServiceRouter

bind(X)

bind(X)

Service Controller

Connecting to Service X


Application

S socket()

X FWD c2 s

Allocates local flowID

a

Connecting to Service X


Application

S connect(X)

X FWD c2 s

aa 2 SYNc - X

To c

12

Load Balancing in Service Router


X FWD d,e

fcTo eFrom a

a 2 SYNe - Xa 2 SYNc - X

Service Instance Providing Service X


Application

X DMX s

a 2 SYNe - X

S

eFrom a

Service Instance Providing Service X


Application

accept()

X DMX s3 sc

SSc

eTo a

e 3 SYN-ACKa 2

Internet


XX

XX

aa

ccdd

eeDatacenter

a SYNc X

e SYN-ACKa

a SYNe X

X d,e

e dataa

ServiceRouter

13

What does Service Access Involve?

1. Locating a nearby service datacenter• Map service name to location

2. Connecting to service • Establish data flow to instance• Load balance between pool of replicas

3. Maintaining connectivity to service• Migrate between interfaces and

networks

Migration of Flows

sCsC sSsS

fS1fS1fC1fC1 a1

a2

a3

Host CHost C Host SHost Sa4

RSYN

RSYN-ACK

ACK

Migrate flowa1 -> a2

Multipath with Multiple Subflows

sCsC sSsS

fS1fS1fC1fC1

fS2fS2fC2fC2

a1

a2

a3

Host CHost C Host SHost Sa4

SYN

SYN-ACK

ACK

Add flowa2 <-> a4

Use of Migration on Clients

WiFiCellular

Single Serval TCP connection that never breaks

Saves > 900 MB cellular data per month

Saves > 900 MB cellular data per month

14

Outline


• Some proposals:• CCN• Nebula• Mobility First: slides Venkat

• XIA: Wednesday

64

Looking Ahead

• Two more lectures on “the Internet”• XIA project• QoS and video distribution

• Then we switch to edge networks• Three lectures on wireless• Three lectures on other edge networks

• Done!

65

Outline The “Next” Internet: More of the Same?prs/15-744-F12/lectures/14-FIA.pdf · • Named Internet Architecture • Content centric networking - data is a first class entity

Documents