Transcript Wash U DARPA PCES PI Meeting Report

A Layered Naming Architecture
for the Internet
by
Hari Balakrishnan,
Karthik Lakshminarayanan, Sylvia Ratnasamy,
Scott Shenker, Ion Stoica, Michael Walfish
Position paper, ACM SIGCOMM, Sep 2004
Presented by
Shobana Padmanabhan, Andrew Levine
Sep 28, 2004
CSE 7701
Outline
•
•
•
•
•
•
Introduction
Design Principles
Architecture
Flat names
Related work
Conclusion
Shobana
Andrew
Introduction
Internet has been very successful but its architecture is far from ideal..
there have been many critiques and counter-proposals..
• Authors liberally borrow from these and
– distill some basic principles and
– synthesis these into a coherent architecture
• Some of the counter-proposal references are:
– Preventing DoS with “capabilities”
• sender should first obtain permission to send in the form of
tokens or capabilities
– Role-based Architecture, instead of layered architecture as
layering violations are caused by
• “middle boxes”, multi-way interactions such as QoS,
multicast, overlay routing, tunneling etc.,
– Programmable routers for end-to-end services, …
– IPv6, …
Internet’s architectural issues
• Lack of features
– End-to-end QoS, host control over routing, end-toend multicast,…
• Lack of protection and accountability
– Denial-of-service (DoS)
• Brittleness of Architecture…
Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt
Architectural “brittleness”
•
Internet is widely used to access services/
data but they are tied to hosts
http://www.nasdaq.com/ticker.htm
– But a service is more than a host and so problems
with replication, migration, composition
•
Hosts are tied to IP addresses
– Mobility and multi-homing pose problems
•
Packets might require processing at
intermediaries before reaching destination
– “Middleboxes” (NATs, firewalls, …)
• Problems: violation of IP semantics, making
Internet application-specific,…
Based on slides at http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt
Remedy
• Many proposals advocate large-scale architectural changes such as
routers, end-hosts, services
– But the size of router infrastructure renders these changes almost
impossible. Ex: IPv6 changes
– References:
• Decouple transport and networking layers to address mobility,
multi-homing
– Nimrod, HIP
• Same decoupling to address problems from private addressing
realms such as NATs
– UIP
• Source-directed indirection
– i3
• SID be flat
– SFR
• EID be flat
– HIP, UIP
• Scalable resolution of flat names
– DHTs
“Naming”
• Authors avoid issues inherently involving routers
– Full DoS protection, QoS, fine-grained control over
routing
• “Naming” is more malleable and can solve some
problems
– Layered naming provides layers of indirection and
shielding
– Proposed changes are only to hosts and name
resolution and hence more deployable (compared to
changing routers)
Internet naming is host-centric
• Two global namespaces only: DNS and IP
addresses
• These namespaces are host-centric
– IP addresses: network location of host
– DNS names: domain of host
– Both closely tied to an underlying structure
• This imposes problems…
Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt
Problems with host-centric names
• Host-centric names are not direct and are
impersistent
– If a name is based on mutable properties of the element
its referring to, its not persistent
– Ex. If ARL web site moves from arl.wustl.edu to
www.wustl.edu/arl, links to original URL will break
• Impersistent names constrain movement
– IP addresses are not stable host names
– DNS URLs are not stable data names
• Impersistent names constrain replication
• In this sense, data and services are second-class
network citizens
Key Architectural Questions
1. Which entities should be named?
2. What should names look like?
3. What should names resolve to?
Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt
1: Name services/data, separate from the hosts
Binding principle: Names should bind protocols only
to relevant aspects of underlying structure
(to avoid limitations in flexibility & functionality)
• ‘Service identifiers’ (SIDs) are host-independent
service/ data names
• ‘End-point identifiers’ (EIDs) are locationindependent host names
• Protocols bind to names, and resolve them
– Apps should use SIDs as data handles
– Transport connections should bind to EIDs
Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt
Key Architectural Questions
1. Which entities should be named?
2. What should names look like?
3. What should names resolve to?
Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt
2: SIDs and EIDs should be ‘Flat’
0axsdfkjl1234sadfadsf234234sdfasf00df
Flat-name principle: Persistent names will not
impose restrictions on the elements they refer to
• ‘Flat names’ impose no structure on entities
– Structured names stable only if name structure matches
natural structure of entities
– Can be resolved scalably using, e.g., DHTs
• Flat names can be used to name anything
– Once you have a large flat namespace, you never need
other global “handles”
Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt
Key Architectural Questions
1. Which entities should be named?
2. What should names look like?
3. What should names resolve to?
Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt
3: Resolution and Delegation
Delegation principle: A network entity should be able
to direct resolutions of its name not only to its own
location, but also to chosen delegates
• Names usually resolve to “location” of entity
– SID would resolve to (EID, transport, port) triple
– EID would resolve to an IP address
• Packets might require processing at intermediaries
before reaching destination
– Such processing today violates ‘trust’ and layering
• Only element identified by packet’s IP destination
should inspect higher layers
• Fix, by making delegation part of architecture
Based on slides at http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt
4: Sequence of destinations
Sequence principle: Destinations, as specified by
sources and also resolution of SIDs and EIDs,
should be generalizable to sequences of destinations
• Traditional IP routing
– Routing protocol chooses packet’s path through network
• Source routing protocols
– Sources can specify path
– In loose source routing, multiple points in the path
• Make this available at endpoint and service layers
– (i.e.) sources and receivers should be able to specify a sequence of
destinations
• endpoints (EIDs) or services (SIDs)
• Combining this with Principle 3
– Endpoints and services should be able to have their names resolve to
a sequence of IDs (IP addrs or EIDs)
Architecture - two new naming layers
User-level descriptors
(e.g., email id, search string)
Application
App-specific search/lookup
returns SID
Use SID as handle App session
App session
Resolves SID to >=1 (EID,transport,port)
Opens transport conns
Bind to EID
Transport
Transport
Resolves EID to IP
IP
IP hdr EID TCP SID …
Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt
IP
Architecture – SID resolution details
• If SID is a data item
– SID resolution layer would also receive an application directive
• Ex: for a web page, pathname on the web server might also be
returned
• Functionality in an application-independent library
– But since it would be under app’s control and since some apps might
want different behavior, lets look at what app does instead
• From the triple, app would communicate with the specified
EID using the specified transport and port
• The transport protocol, now bound to EIDs, would use host’s
EID as src and the one from triple as destination
• Multiple triples for simultaneous connections or back-up if a
connection failed
• If all triples fail, app would reinvoke SID resolution layer to
re-resolve SID for new triples
Architecture – EID resolution details
• The transport protocol prepares packet(s) to send
and passes them down to EID resolution layer
• Destination EID is resolved into IP address(es)
– Multiple IPs for multi-homed hosts
– Also, when a logical endpoint represented a collection of
machines, each with its own IP address
• Host’s IP address becomes the src IP and the IP
from the resolution layer is the destination IP
• If dest host is unreachable, EID layer uses other IP
addresses, if any
• If all fail, it will re-resolve EID, in case the dest IP
has changed
Architecture – EIDs and SIDs in packets
• Since end-hosts are identified by EIDs, they go in
the packet
• Since SIDs name services or data, they only go in
each ‘application data unit’ (ADU) communicated
between sender and receiver
– Actual location in data streams would vary by app and
what the SID is being used for
• Ex: SID for SMTP server would be in email header
• SID for HTTP web proxy in HTTP header
Architecture not so brittle anymore
•
•
SIDs overcome problems with DNS-based
URLs
EIDs provide natural solution to mobility and
multi-homing
– If endpoint changes its IP address, EID resolution
layer will re-resolve to find the new IP address
• => continued operation when mobile hosts
• Smooth failover for multi-homed hosts
•
Delegation gracefully replaces “middleboxes”
with intermediaries
Backup slides
Domain Name System (DNS)
•
•
•
•
•
•
DNS maps user-friendly names into router-friendly addresses
Naming system, in general, maintains bindings of names & values
Name server is a specific implementation of a resolution mechanism that is on
the network and that can be queried by sending a message
Prior to DNS, a central table in hosts.txt was manually maintained and mailed
out for deployment and hosts did a local look-up in their copy!
DNS uses hierarchical name space. The table is partitioned into disjoint pieces
and distributed (in name servers) throughout Internet.
Logical
gov
edu
wustl
•
…
…
Implementation
Root name server
Wustl name server
…
A name server per ‘zone’
…
Domain Name System (DNS)
•
•
•
•
Clients query name servers (for translating URLs, mail id’s etc.) and if they don’t
have the info, they return a pointer to a server that the client should query next.
Thus, DNS is a hierarchy of name servers rather than domains
‘Resource records’ <name, value, type, class, TTL>
Caching servers caches replies