Network Architecture R02 Name Based Nets

1
Network Architecture (R02) Name Based Nets?

• Jon Crowcroft,
• http//www.cl.cam.ac.uk/jac22
• http//www.cl.cam.ac.uk/teaching/0910/R02/

2
Shochs Mnemonic Mantra

• Name - what it is
• Readable/semantics/organisation
• Attributedx.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

3
Addresses

• Pure location last component in route
• Hierarchy loose source route
• Identifier ! address ( name)
• IP addresses are a mix
• Interface
• Prefix matching - distributed hierarchy!

4
Multicast/Anycast addresses

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

5
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

6
Where can we update things

• DNS Name -gt
• Local addr NAT Dyn DNS
• IP Address -gt
• See later (xxx)
• Lower layer label
• Label switching
• All need state in the net somewhere
• NAT, router or switch, respectively)

7
Bug in internet

• Transport uses IP address as part of end state
  - includes routing hint!
• Many mobility (and multipath) hacks to hide this
  mistake!

8
Mobile gt State Update

• Whether you do it with name/addr, route inject,
  or label,
• If you move, then
• other end has to know, and
• New peers have to know, or
• Someone has to proxy for you in your old place -gt
  triangular routing (bad)
• Big problem is update procedure
• Workload
• Security!

9
Cellular (GPRS, 3G etc) Data

• Is below IP for now
• So you dont 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.

10
What breaks if we update our IP?

• See 88 and LISP
• Need to update routes
• Need other end of live transport session to know
• Need DNS entry to reflect thisso 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 cant
  reach us
• Both routedns update may take time if securely
  done (e.g. if ID Is allocated via HIP)

11
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?

12
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!

13
Global Server Load Balancing
Dima Krioukov dima_at_nortelnetworks.com Alex Kit
akit_at_winstar.com October 24, 2000
14
Purpose

• Existing methods
• New technique
• Analysis
• Applicability considerations

15
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

16
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 ?

17
1. Introduction

• Logic GSLB ? IDC ? ASP ? Hosting

18
Hosting
Infrastructure
Web User
Content Owner
IDC Owner
ISP
OSS
19
ASP
IDC
Infrastructure
ISP/Backbone
End Customer
ASP
Applications
Access
Operations
20
IDC
IDC
LB Tier
Core (Routing)
Load Balancing (L4 Switching)
Distribution (L3 Switching)
Port Density (L2 Switching)
Servers
Tier
Tier
Tier
SAN
21
Requirements to IDCs

• High Availability (HA)

• Local

• Global

• Load Balancing (LB)

• Local

• Global

• Proximity (including congestion)

• Load

22
2. Generic SLB and LSLB

• SLB 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

23
LSLB Forwarding

• LSNAT
• DSR
• Tunneling

24
LSNAT
Router
X
LB
Y
S1
S2
S3
25
LSNAT Source NAT
Router
X
LB
Y
S1
S2
S3
26
DSR
Router
1
LB
3
2
S1
S2
S3
27
Tunneling
Router
1
LB
3
2
S1
S2
S3
28
3. GSLB

• DNS Based
• HRI
• TDF
• Latest Trends

29
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

30
LPRP

• Transport
• UDP
• TCP
• HTTP

• Operation
• Periodic Updates
• Periodic Requests
• Triggered Updates

IDC3
LB
IDC1
LB
IDC2
LB
31
PRP

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

32
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

33
How it works
IDC3
LB
Client
Customer
LDNS
IDC1
ADNS
RDNS
IDC2
LB
34
How it works
IDC3
LB
Client
Customer
LDNS
IDC1
ADNS
RDNS
IDC2
LB
35
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

36
3.2 HRI

• GSLB Routing
• To what?
• BGP
• IGP
• By what?
• RS
• Router
• LB

37
To what

• IGP?
• BGP
• Route filtering (both ways)
• No ECMP

Router
Client
38
By what

• RS

IDC1
IDC2
Router
Router
BGP
BGP
RS
RS
39
By what

• Router

IDC1
IDC2
Router
Router
LB
RS
RS
RS
40
By what

• LB

IDC2
IDC1
Router
Router
BGP
BGP
LB
LB
RS
RS
RS
RS
41
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

42
3.3 TDF

• GSLB X TDF
• NAT Based
• Tunneling

Client
43
Why wrong IDC?

• Failure of, disabled or non-implemented LPRP
• Cached DNS records
• Other retardation effects (LPRP, BGP)

44
NAT Based
IDC1, wrong
V1.1 V1.2
IDC2, right
Client
V2.1 V2.2
45
Remote Servers
IDC1, wrong
V1.1
IDC2, right
Client
V2.1
46
Tunneling

• Next section

47
Analysis

• Pros
• Fixes errors optimally

• Cons
• ip verify reverse-path

Router
Router
Client
48
Analysis

• Pros
• Fixes errors optimally

• Cons
• ip verify reverse-path

Router
Router
Client
49
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)

50
Internet Infiltrations
IDC1
LB
Customer
Client
LB
LB
LB
IDC2
LB
51
Internet Infiltrations
IDC1
LB
Customer
Client
LB
LB
LB
IDC2
LB
52
LDNS modifications in CDNs
IDC1
LB
Customer
LDNS
Client
ASP Backbone
IDC2
LB
53
4. Virtual Block Injection (VBI)

• Inject not VS host routes, but blocks of GSLBed
  VSs ? IDC (LB) failures are handled by the
  routing protocol
• Use tunneling TDF in case of individual VS failure

54
How it works
Client
AS2
AS1
V/20, AS3
V/20, AS3
55
How it works
Client
AS2
AS1
V/20, AS3
56
How it works
Client
AS2
AS1
V/20, AS3
V/20, AS3
57
Testing

• Needed
• LB
• BGP
• Tunnels

• Linux
• Linux Virtual Server (LVS,Wensong Zhang,Julian
  Anastasov)
• Zebra
• Tunnels

58
Test Network
59
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!

60
Route Flapping
Client
Router
AS2
AS1
V/20, AS3
V/20, AS3
61
Solution for UDP

• Session table entry exchange for long sessions

Client
Router
AS2
AS1
V/20, AS3
V/20, AS3
62
Solution for UDP

• Session table entry exchange for long sessions

Client
Router
AS2
AS1
V/20, AS3
V/20, AS3
63
Solution for TCP

• If LB receives packet
• Destined to a VS
• No SYN
• No session table entry
• Not via the tunnels
• Forward via all the tunnels

Client
Router
AS2
AS1
V/20, AS3
V/20, AS3
64
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

65
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

66
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.or
  g/
• VBI Testing http//www.krioukov.net/dima/VBI/

67
IPNL A NAT-Extended Internet Architecture

• Paul Francis
• Tahoe Network
• Remakrishna Gummadi
• UC Berkeley

68
About title

• Extension of NAT
• Modify only hosts and NAT boxes

• Suitable IA
• Improving IPv4s
• scalability
• size
• Keeping its property
• Long-lived addresses,Robustness-statelessness,
  Address independence, Packet hijacking resistance

69
Answer Question

• Some extension of NAT
• Suitable Internet Architecture

?
70
Outline

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

71
Basic(0)--NAT

• Network address translation
• Advantages
• Connect private network
• Isolate private network
• Disadvantages
• Unaddressable hosts

72
Basics(1)--concepts

• Topology

• Terminologies
• FQDN, MRIP, RN, EHIP
• Addresses
• FQDN,
• IPNL address
• Local IP, Global IP(composed of MRIP, RN, EHIP)
• IPNL Header next

Global
private
frontdoor
private
internal nl-router
private
73
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)

74
Basics(2)--routing
IPNL Header
75
Basic(2)--routing

• Knowledge of IPNL host routers

HOST (1)FQDN EHIP (2)one or more nl-routers
Internal nl-router (1)its neighbors (2)FQDN, IP
pair list (3)Routing information
Frontdoor Entry for all realms behind it
76
Example1 Routing by FQDN
77
DestAddress M3R6H3
Example2 Routing by IPNL addresses
78
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
79
Experiment

• Testbed
• netperf benchmark
• Result
• Good! No degradation of throughput at all
• Latency associated with failure connection
  depends on routes refresh frequency

80
Testbed
81
Review question

• Maintain characteristics of IPv4
• Long-lived addresses
• Robustness
• Address independence
• Packet hijacking resistance
• Solve
• Scalability
• Address depletion

?
?
?
?
?
?
82

• NICE

83
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

84
Comparisons with IPv6

• IPNL
• Completely isolate sites
• Less expensive
• Simpler transition
• Easier security administration

• IPv6pure
• Less Header rewriting
• Simpler auto-address configuration

Advantages disappear in IPv6on4 env
85
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?

86
Resource Discovery Using an Intentional Naming
System
Hari Balakrishnan MIT Lab for Computer
Sciencehttp//wind.lcs.mit.edu/hari_at_lcs.mit.edu
With William Adjie-Winoto, Elliot Schwartz,
Jeremy Lilley, Anit Chakraborty
87
Application Location-dependent wireless services

• Access, control services, communicate with them
• Handle mobility group communication

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

• Configuration
• Routing
• Discovery
• Adaptation
• Security privacy

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

• Mostly static topology services
• Deploying new services cumbersome
• Applications cannot learn about network
• Failures are common!
• High management cost

Routers
Servers
90
Ad hoc configuration

• Static configuration impossible
• DHCP-like configuration undesirable
• Over wireless, pre-configured subnetworks and
  broadcasts problematic
• Solution Distributed, randomized address
  assignment

Coalesce? Route?
addr ar mask mr
addr br mask mr
addr cr mask n
91
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

92
Design goals

• Names must be descriptive, signifying application
  intent

Expressiveness
Name resolvers must track rapid changes
Responsiveness
System must overcome resolver and service failure
Robustness
Name resolvers must self-configure
Easy configuration
93
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

94
INS architecture overview
camera510.lcs.mit.edu
Lookup
image
INR self-configuration

• Intentional Name Resolvers (INR) form a
  distributed overlay

Integrate resolution and message routing
95
How does it work?
Virtual space partitions Domain Space Resolvers
Scaling?
INR
DSR
96
INS service model
application
Early binding
INR
Late binding
query
Intentional anycast
Intentional multicast
Application-level routing using intentional names
97
Whats in a name?

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

• Names are queries
• Attribute-value matches
• Range queries
• Wildcard matches

98
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)

99
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

100
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

101
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

102
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

103
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

104
Virtual space partitioning
vspacecamera
vspace5th-floor
Routing updates for each vspace
105
INR Implementation
OverlayManager
Network Monitor
RouteManager
Client Manager
NameTreeSet
vspaceneighbors
Forwarder
lookup
Intentional anycast, multicast
Communicator
Mobility Sockets
Incoming message
TCP/UDP
106
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

107
WIND
108
(No Transcript)
109
(No Transcript)
110
(No Transcript)
111
(No Transcript)
112
(No Transcript)
113
(No Transcript)
114
(No Transcript)
115
(No Transcript)
116
Status performance

• Java implementation of INS applications
• PC-based resolver performance
• 1 resolver several thousand names _at_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/)

117
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

118
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

119
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

120
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

121
Future Internet Architecture
Use each other to add value
Flexible IP routers
Scheduling, buffer mgmt
122
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

123
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!