Name Based Net Architectures

Network Architecture (R02) Name Based Nets?

Jon Crowcroft, http://www.cl.cam.ac.uk/~jac22

http://www.cl.cam.ac.uk/teaching/0910/R02/

Shoch’s Mnemonic Mantra

Name - what it is Readable/semantics/organisation Attributed…x.500 & INS & DNS Service Name

Address - where “it” is Identity perhaps Location hints perhaps

Route - how to get to it Consult a map (Build a map?)

Name-address binding - resolvers Address-route binding - forwarders

Addresses

Pure location = last component in route Hierarchy = loose source route Identifier != address ( == name)

IP addresses are a mix Interface Prefix matching - distributed hierarchy!

Multicast/Anycast “addresses”

Are really names You can tell because you need to bind Late binding…

Mobility & Address Re-Use

If we run out of address space: Look at usage in space & time Re-use of addresses when hosts not

active Re-allocation of addresses to where

more use Can do by updating routing or… Non global addresses +state

Where can we update things

1. DNS Name ->Local addr + NAT + Dyn DNS

n IP Address ->n See later (xxx)

n Lower layer label…n Label switching

All need state in the net somewhere NAT, router or switch, respectively)

Bug in internet

Transport uses IP address as part of “end” state - includes routing hint!

Many mobility (and multipath) hacks to hide this mistake!

Mobile => State Update

Whether you do it with name/addr, route inject, or label,

If you move, thenn other end has to know, and n New peers have to know, orn Someone has to proxy for you in your old place ->

triangular routing (bad) Big problem is update procedure

Workload Security!

Cellular (GPRS, 3G etc) Data

Is below IP for now So you don’t see this, but Does manage device location, and then either

Routeable addr for active device NAT Re-do adress and rely on phone being only client

(and HTTP level recovery - standard in most web 2.0 systems)

Big problems if you want to be “always on” for data.

What breaks if we update our IP?

See 8+8 and LISP Need to update routes Need other end of live transport session to know Need DNS entry to reflect this…so new peers can

reach us at new place Both route update and DNS update might

take time….so Need help during hysteresis (temporary triangle) May be gap during which some new peers can’t

reach us… Both route&dns update may take time if securely

done (e.g. if ID Is allocated via HIP)

My crazy idea

Address swapping In a really big system, there are as many

pople moving from A to B as from B to A over sufficient time scale (e.g on roads)

So why not swap addresses? And use the people you swapped addresses with as

“care of” for temporary triangles during handover While you tell the other end

What happens when both ends do this?

For static systems sometimes need a transparent choice

Load balancers or DDoS avoidance Replicated Services Migrating Services

Lots of the techniques give hint on how to do mobile, and how not to!

Global Server Load Balancing

Dima Krioukov [dima@nortelnetworks.com]Alex Kit [akit@winstar.com]

October 24, 2000

Purpose

Existing methods New technique Analysis Applicability considerations

Plan Introduction

What are ASPs? Requirements to IDCs

LSLB Load Sharing NAT (LSNAT) Direct Server Return (DSR) Tunneling

GSLB DNS Based Host Route Injection (HRI) Triangle Data Flow (TDF) Latest Trends

New Technique – Virtual Block Injection (VBI) Description Testing Analysis

Applicability Considerations Conclusions and References

Abbreviations

LB = Load Balancing/Balancer SLB = Server LB LSLB = Local SLB GSLB = Global SLB HA = High Availability RS = Real Server/Service VS = Virtual Server/Service VIP = VS IP address LSNAT = Load Sharing NAT DSR = Direct Server Return

PRP = Proximity Report Protocol LRP = Load Report Protocol LPRP = PRP + LRP HRI = Host Route Injection VBI = Virtual Block Injection TDF = Triangle Data Flow IDC = Internet Data Center CDN = Content Delivery Network ASP = Application Service Provider CASP = Content/Collocation and

Application Service Provider AIP = Application Infrastructure

Provider xyP = ?

1. Introduction

Logic: GSLB IDC ASP Hosting

Hosting

Infrastructure

Web User Content Owner IDC Owner ISP

OSS

ASP

Infrastructure

End Customer ASP Applications

Operations

ISP/Backbone

Access

IDC

IDC

IDCCore

(Routing)

Distribution(L3 Switching)

Tier Tier Tier

LB TierLoad Balancing(L4 Switching)

Port Density(L2 Switching)

Servers

SAN

Requirements to IDCs

• Load Balancing (LB)

IDC1 IDC2

Client

– Local– Global

– Local– Global

· Proximity (“including” congestion)· Load

• High Availability (HA)

HA ⊂ LB

2. Generic SLB and LSLBSLB = VS RS Health Checking

Layer 2 Layer 3 Layer 4 Layer 7

SLB Algorithm Round Robin Least Connections Server Response Time Server Load Hashing

SLB Forwarding Session Tables Timers

LSLB Forwarding

LSNAT DSR Tunneling

LSNAT

Router

LB

S1 S2 S3

src/dstLayer Ingress

Client_PortS1_Portdst

Client_IPS1_IPdst

LB_MACS1_MACdst

Client_Port

Virtual_Portdst

Client_IPVirtual_IPdst

dst Router_MAC

Virtual_MAC

Client_Port

Client_IP

LB_MAC

Client_Port

Client_IP

Router_MAC

S1_IPsrcL3

src

src

src

src

src

Virtual_IPL3

S1_PortL4

Virtual_PortL4

S1_MACL2

Y

Virtual_MACL2

X

EgressSegment

X

Y

LSNAT + Source NAT

Router

LB

S1 S2 S3

src/dst

Layer Ingress

LB_V_PortS1_Portdst

LB_V_IPS1_IPdst

LB_V_MACS1_MACdst

Client_Port

Virtual_Portdst

Client_IPVirtual_IPdst

dst Router_MAC

Virtual_MAC

LB_V_Port

LB_V_IP

LB_V_MAC

Client_Port

Client_IP

Router_MAC

S1_IPsrcL3

src

src

src

src

src

Virtual_IPL3

S1_PortL4

Virtual_PortL4

S1_MACL2

Y

Virtual_MACL2

X

EgressSegment

X

Y

DSR

Router

LB

S1 S2 S3Virtual_Po

rt

Client_Port

Virtual_IPClient_IPS1_MAC

Virtual_MAC

2

Client_Port

Virtual_Port

Client_IPVirtual_IP

Router_MAC

S1_MAC

3src/dst

Layer 1

Virtual_Portdst

Virtual_IPdst

dst Virtual_MAC

Client_Port

Client_IP

Router_MAC

src

src

src

L3

L4

L21

23

Tunneling

Router

LB

S1 S2 S3

Int: V_IP

Int: C_IP

V_PortC_Port

Ext: S1_IP

Ext: LB_IP

S1_MACLB_MAC

2

C_PortV_PortC_IPV_IP

R_MAC

S1_MAC

3src/dst

Layer 1

V_Portdst

V_IPdst

dst V_MAC

C_Port

C_IP

R_MAC

src

src

src

L3

L4

L21

23

3. GSLB

DNS Based HRI TDF Latest Trends

3.1 DNS Based

GSLB = Name VS (DNS+) Smart DNS

Load and availability awareness Load Report Protocol (LRP)

Proximity and congestion awareness Proximity Report Protocol (PRP)

LB DNS Functionality DNS Server DNS Proxy

Caching DNS Traffic Intercept

LPRP Transp

ort UDP TCP HTTP

Operation Periodic

Updates Periodic

Requests Triggered

Updates

IDC1

LB

IDC2

LB

IDC3

LB

PRP

RTT Effective bandwidth Number of hops Number of AS hops IGP metric

Proximity to the client LDNS, not to the client

LRP

VS Health Up Down Backup only

VS Load Number of sessions Response Time

LB Load Number of sessions Capacity threshold CPU

RS/Content Load Network Load

bps pps

QoS Security

How it works

IDC1

IDC2

LB

IDC3

LB

CustomerLDNS

ADNS

Client

RDNS

1

2 3

455

6

6

6

How it works

IDC1

IDC2

LB

IDC3

LB

CustomerLDNS

ADNS

Client

RDNS

7

7

810

119

Analysis

Pros Accurate load info Accurate proximity

info Perfect solution… in

some cases and if certain conditions are met

Cons DNS – wrong target Proximity between

client and its LDNS Caching

LB LDNS Application

Complexity Hard to find optimal

values for various timers (TTL, cache timeouts, etc.) and prefix lengths

3.2 HRI

GSLB = Routing+ To what?

BGP IGP

By what? RS Router LB

To what

IGP? BGP

Route filtering (both ways) No ECMP

Client

IDC1

IDC2

Router

By what

RS

IDC1

Router

RS

BGP

IDC2

Router

RS

BGP

By what

Router

IDC1

Router

RS

IDC2

Router

RS RS

LB

By what

LB

IDC2

Router

RS RS

LB

IDC1

Router

RS RS

LB

BGP BGP

Analysis

Pros Simplicity No new protocols

are needed Proximity is handled

by routing Load handling?

Cons Single backbone*

Its own Single ISP

Too many routes Less accurate load

and proximity info Only local load Optimal routing?

Route flapping*

3.3 TDF

GSLB = X + TDF NAT Based Tunneling

Client

IDC1, “wrong”

IDC2,“right”

Why “wrong” IDC?

Failure of, disabled or non-implemented LPRP

Cached DNS records Other retardation effects (LPRP, BGP)

NAT Based

Client

IDC1, “wrong”

V1.1; V1.2

IDC2,“right”

3

21

1

V1.1

CCV2.

2dst

V1.1Csr

cL3

32

V2.1; V2.2

“Remote Servers”

Client

IDC1, “wrong”

V1.1

IDC2,“right”

21

C

V1.1

41

V1.1

CV1.1

V2.1

dst

V2.1

V1.1

srcL

3

32

V2.1

3

4

Tunneling

Next section

Analysis

Pros Fixes errors

optimally

Cons ip verify reverse-path

Client

IDC1, “wrong”

IDC2,“right”

Router

Router

Analysis

Pros Fixes errors

optimally

Cons ip verify reverse-path

Client

IDC1, “wrong”

IDC2,“right”

Router

Router

3.4 Latest Trends, Radicalism

Internet infiltration

Going to the client edge

Going to the client Modifying the client

LB presence in strategic locations (HydraGPS, Speedera)

LDNS modifications (Speedera)

Application modifications (SRV RRs)

Internet Infiltrations

IDC2

LB

IDC1

LB

Customer

LB

LB

LB

ClientLB

LB

LB

Internet Infiltrations

IDC2

LB

IDC1

LB

Customer

LB

LB

LB

Client

LB

LB

LDNS modifications in CDNs

IDC2

LB

IDC1

LB

CustomerLDNSClient

ASP Backbone

4. Virtual Block Injection (VBI)

Inject not VS host routes, but blocks of GSLB’ed VSs IDC (LB) failures are handled by the routing protocol

Use tunneling TDF in case of individual VS failure

How it works

ISP1 ISP2

IDC1, R1/20 IDC2, R2/20

AS1 AS2

V/20, AS3V/20, AS3

Client

How it works

ISP1 ISP2

IDC1, R1/20 IDC2, R2/20

AS1 AS2

V/20, AS3

Client

How it works

ISP1 ISP2

IDC1, R1/20 IDC2, R2/20

AS1 AS2

V/20, AS3V/20, AS3

Client

Testing

Needed LB BGP Tunnels

Linux Linux Virtual Server

(LVS,Wensong Zhang,Julian Anastasov)

Zebra Tunnels

Test Network

Analysis

Pros All of HRI, plus No host route injection Working TDF Perfect VS health

handling VS load LRP Obvious simplifications

in more “ideal” cases

Cons LB load stop

advertisement? BGP – proximity tool? Discontinuous AS?

Route flapping!

Route Flapping

ISP1 ISP2

IDC1, R1/20 IDC2, R2/20

AS1 AS2

V/20, AS3V/20, AS3

Client

RouterUDPTCP

Solution for UDPSession table entry exchange for long sessions

ISP1 ISP2

IDC1, R1/20 IDC2, R2/20

AS1 AS2

V/20, AS3V/20, AS3

Client

Router

Solution for UDPSession table entry exchange for long sessions

ISP1 ISP2

IDC1, R1/20 IDC2, R2/20

AS1 AS2

V/20, AS3V/20, AS3

Client

Router

Solution for TCPIf LB receives

packet Destined to a VS No SYN No session table

entry Not via the

tunnelsForward via all

the tunnelsISP1 ISP2

IDC1, R1/20 IDC2, R2/20

AS1 AS2

V/20, AS3V/20, AS3

Client

Router

5. Applicability Considerations

GSLB of Small number of VSs (or RSs)

by an ISP* by its customer

Big number of VSs (between IDCs) CASP = ISP CASP ≠ ISP

CASP has its own backbone CASP does not have control over customer access CASP has control over customer access**

CASP does not have its own backbone CASP is multihomed to the same ISP CASP is multihomed to different ISPs*

6. Conclusions

No ideal GSLB method For some “ideal” network scenarios,

there are some “ideal” solutions For realistic network scenarios, there

are rapidly improving realistic solutions Good competition Lack of comparative testing in the

production-like environment

References

On ASPs: Nortel, ASP Industry Consortium, Network Magazine, IRG

Vendors: Alteon, ArrowPoint, Foundry, F5, Cisco, Nortel, Radware, HydraWEB, Speedera, Resonate

RFCs: LSNAT, SRV, DNS for LB, SLB draft (work in progress)

Open Source: LVS, http://www.linuxvirtualserver.org/

VBI Testing: http://www.krioukov.net/~dima/VBI/

IPNL: A NAT-Extended Internet Architecture

Paul Francis Tahoe Network

Remakrishna Gummadi UC Berkeley

About title

Suitable IASuitable IA Improving IPv4’s

scalability size

Keeping its property Long-lived

addresses,Robustness-statelessness, Address independence, Packet hijacking resistance

Extension of NATExtension of NAT Modify only hosts

and NAT boxes

Answer Question

Some extension of NAT

Suitable Internet Architecture

?

Outline

IPNL basics Key attributes of IPNL Review question Other works Comparison with IPv6 Discussion

Basic(0)--NAT

Network address translation Advantages

Connect private network Isolate private network

Disadvantages Unaddressable hosts

Basics(1)--concepts

TopologyTopology TerminologiesTerminologiesFQDN, MRIP, RN, EHIP

AddressesAddresses FQDN, IPNL address

Local IP, Global IP(composed of MRIP, RN, EHIP)

IPNL Header next…IPNL Header next…

internal nl-router

Global

private private

frontdoor private

EHIPRNMRIP

Terms

FQDN

Realm Number

Middle Realm End Host ID/IP

Fully qualified Domain Name - DNS

New thing (AS)?

Realm based IP? Now Real specific

(like non routeable Ips)

Basics(2)--routing

Optional FQDN header

(variable)

Optional global header

(16)

Local header(24)

IPNL Header

Basic(2)--routing

Knowledge of IPNL host & routers

HOST:HOST:

(1)FQDN & EHIP

(2)one or more

nl-routers

Internal nl-router:Internal nl-router:

(1)its neighbors

(2)FQDN, IP pair list

(3)Routing information

Frontdoor:Frontdoor:

Entry for all realms behind it

Example1: Routing by FQDN

Example2: Routing by IPNL addresses

DestAddress: M3:R6:H3

Key attributes of IPNL Reuse existing infrastructure Utilize FQDN Extend IP address space

Isolate site addressing Separate local and global header Realm number independence In-flight IPNL address resolution Location

MRIP RN EHIP

Experiment

Testbed “netperf” benchmark

Result Good! No degradation of throughput at

all Latency associated with failure

connection depends on routes refresh frequency

Testbed

Review question

Maintain characteristics of IPv4 Long-lived addresses Robustness Address independence Packet hijacking resistance

Solve Scalability Address depletion

Other works

AVES “A waypoint service approach to connect

heterogeneous internet address space” by Eugene Ng, Ion Stoica, Hui Zhang (CMU)

TRIAD By D.R. Cheriton, M. Gritter(stanford)

IPv6

Comparisons with IPv6

IPNL IPNL Completely isolate

sites Less expensive Simpler transition Easier security

administration

IPv6pureIPv6pure Less Header

rewriting Simpler auto-

address configuration Advantages disappear in

IPv6on4 env

Discussions

EHIP 4 Byte? Too long header? Complexity analysis of IPNL?

Routing algorithm Experiment convincing? Does IPNL have a bright future? Quality of the paper?

Resource Discovery Using an Intentional Naming System

Hari Balakrishnan MIT Lab for Computer Sciencehttp://wind.lcs.mit.edu/hari@lcs.mit.edu

With: William Adjie-Winoto, Elliot Schwartz, Jeremy Lilley, Anit Chakraborty

Application: Location-dependent wireless services

Access, control services, communicate with them

Handle mobility & group communication

Spontaneous networking

Locate other useful services (e.g., nearest café)Where?

App should be able to conveniently specify a resource and access it

Automatically obtain map of region & discover devices, services and people there

Challenges

Configuration Routing Discovery Adaptation Security & privacy

Dynamic, mobile environment with no pre-configured support for internetworking or service location

Today

Routers

DNSHostname

Address

Mostly static topology & services

Deploying new services cumbersome

Applications cannot learn about network

Failures are common! High management cost

Servers

Clients

Ad hoc configuration Static configuration impossible DHCP-like configuration undesirable

Over wireless, pre-configured subnetworks and broadcasts problematic

Solution: Distributed, randomized address assignment

addr = ar

mask = mr

addr = br

mask = mr

[ar:mr]

addr = cr

mask = n

Coalesce?Route?

Resource discovery Why is this hard?

Dynamic environment (mobility, performance changes, etc.)

No pre-configured support, no centralized servers

Must be easy to deploy (“ZERO” manual configuration)

Heterogeneous services & devices Approach: a new naming system &

resolution architecture

Design goals

Responsiveness Name resolvers must track rapid changes

Robustness System must overcome resolver and service failure

Easy configuration

Name resolvers must self-configure

Names must be descriptive, signifying application intent

Expressiveness

Intentional Naming System (INS) principles

Names are intentional, based on attributes Apps know WHAT they want, not WHERE

INS integrates resolution and forwarding Late binding of names to nodes

INS resolvers replicate and cooperate Soft-state name exchange protocol with periodic

refreshes INS resolvers self-configure

Form an application-level overlay network

INS architecture overview

[building = ne-43[room = 510]]

[entity = camera]

Intentional name

Intentional Name Resolvers (INR) form a distributed overlay

Integrate resolution and message routing

image

Lookup

camera510.lcs.mit.edu

INR self-configuration

How does it work?

INRINR

DSRDSR

Application-leveloverlay networkformed based on

performance

Inter-domaininformation viaDSR protocol

Exchange namesas if they were routes

Virtual space partitionsDomain Space Resolvers

Scaling?

INS service model

INRINR

Self-configuring app-leveloverlay network

formed based on performance

Soft-state namedissemination

applicationapplication

Early bindingEarly binding

Late bindingLate binding queryqueryset of namesset of names

IntentionalanycastIntentional

multicast

Application-level routing using intentional names

[vspace = thermometer][building = ne-43

[room = *]][temperature < 620F]

data

[vspace = netgroup][department = arch-lab [state = oregon [city = hillsboro]]][rank = admin]

data

What’s in a name?

Names are queries Attribute-value matches Range queries Wildcard matches

[vspace = camera][building = ne-43

[room = 504]][resolution=800x600]][access = public][status = ready]

Names are descriptive Providers announce names

Expressive name language (like XML) Resolver architecture decoupled from language

Responsiveness: Late binding Mapping from name to location(s) can

change rapidly Integrate resolution and message

routing to track change INR resolves name by lookup-and-

forward, not by returning address lookup(name) is a route Forward along route

A name can map to one location (“anycast”) or to many (“multicast”)

Late binding services Intentional anycast

INR picks one of several possible locations Choice based on service-controlled metric

[contrast with IP anycast] Overlay used to exchange name-routes

Intentional multicast INR picks all overlay neighbors that “express

interest” in name Message flows along spanning tree Overlay used to transfer data too

Robustness: Names as soft-state Resolution via network of replicated

resolvers Names are weakly consistent, like network-

layer routes Routing protocol to exchange names

Fate sharing with services, not INRs Name unresolved only if service absent

Soft-state with expiration is robust against service/client failure No need for explicit de-registration

Self-configuring resolvers INRs configure using a distributed

topology formation protocol DSR (DNS++) maintains list of candidate

and active INRs INR-to-INR “ping” experiments for “link

weights” Current implementation forms (evolving)

spanning tree INRs self-terminate if load is low

Efficient name lookups Data structure

Lookup AND operations among orthogonal attributes For values pick the value(s) satisfying the lookup

Polynomial-time in worst case

Scaling issues

Two potential problems Lookup overhead Routing protocol overhead

Load-balancing by spawning new INR handles lookup problem

Virtual space partitioning handles routing protocol problem Just spawning new INR is insufficient

Virtual space partitioning

vspace=camera vspace=5th-floor

Delegate this to another INR

Routing updates for each vspace

INR ImplementationOverlayManager

NetworkMonitor

RouteManager

ClientManager

Forwardervspaceneighbors

NameTreeSet

CommunicatorMobilitySockets

TCP/UDP

lookup

Intentional anycast,multicast

Incoming message

Applications Wireless Networks of Devices (WIND)

Location-dependent mobile applications Floorplan: A navigation tool Camera: An image/video service Printer: A smart print spooler TV & jukebox Network-independent “instant messaging” Location-support system for services and clients

to learn location

WIND

Status & performance Java implementation of INS & applications PC-based resolver performance

1 resolver: several thousand names @100-1000 lookups/s Discovery time linear in hops

Scalability Virtual space partitions for load-shedding Wide-area design in progress

Deployment Hook in wide-area architecture to DNS Standardize virtual space names (like MIME)

Paper at SOSP 17 (http://wind.lcs.mit.edu/)

Related work Domain Name System

Differences in expressiveness and architecture Service Location Protocol

More centralized, less spontaneous Berkeley Service Discovery Service

Authentication, fixed hierarchies for wide-area Jini:

INS for self-configuring fault-tolerant discovery Universal Plug-and-Play & SSDP

XML-based descriptions; INS fits well Intentional names in other contexts

E.g., Discover query routing, DistributedDirector

Application-Level Networks

Increasing number of services that set up application-level overlay networks

Distributed Web caches Replica management systems Transcoders Multi-party communication Naming systems Net news

What Do They Have in Common?

Form an overlay over IP Nodes exchange meta-data information Nodes forward messages based on

meta-data Incorporate configuration machinery Fault/crash recovery Load balancing

Supporting Application-Level Networks General protocols for meta-data

dissemination Fault-tolerance primitives Self-configuring overlays

Bootstrap and placement Neighbor formation Load balancing

Security and privacy primitives

Future Internet Architecture

Resourcemanagement

Flexible IP routers

Traffic engineering

Congestion Manager

Scheduling,buffer mgmt

Middleware

...Cache & replica

management Self-configuringoverlays

INS

Media transcoders

Performance discovery Service

location Jini UPnPE-speak T-spaces

Decentralizedsecurity

Use each other to add value

Conclusion Achieving self-organizing networks requires a flexible

naming system for resource discovery INS works in dynamic, heterogeneous networks Expressiveness: names convey intent Responsiveness: late binding Robustness: soft-state name dissemination Configuration: Resolvers self-configure

Application-level overlay networks are a good way to build flexible, self-organizing network applications

For next week (Tuesday 27th oct)

I want each of you to read about location/identifier split proposals in the Internet community (e.g. LISP)

And come up with What do they solve What do they not solve… And email me 1 slide with that on! Which YOU will present!

And we will discuss how the desiderata (requirements) changed!