name based net architectures
TRANSCRIPT
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 [[email protected]]Alex Kit [[email protected]]
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/[email protected]
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!