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
24
Embed
A Layered Naming Architecture for the Internet by Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, Michael Walfish.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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-to-
end multicast,…
• Lack of protection and accountability– Denial-of-service (DoS)
• 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
• 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
• Implementation
edu gov …
…wustl
Wustl name server …
…
Root 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