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) Brittleness of Architecture… Source:

Architectural “brittleness” Internet is widely used to access services/ data but they are tied to hosts –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

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:

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 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:

1: Name services/data, separate from the hosts ‘Service identifiers’ (SIDs) are host-independent service/ data names ‘End-point identifiers’ (EIDs) are location- independent host names Protocols bind to names, and resolve them –Apps should use SIDs as data handles –Transport connections should bind to EIDs Binding principle: Names should bind protocols only to relevant aspects of underlying structure (to avoid limitations in flexibility & functionality) Source:

Key Architectural Questions 1.Which entities should be named? 2.What should names look like? 3.What should names resolve to? Source:

2: SIDs and EIDs should be ‘Flat’ 0axsdfkjl1234sadfadsf234234sdfasf00df ‘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” Flat-name principle: Persistent names will not impose restrictions on the elements they refer to Source:

Key Architectural Questions 1.Which entities should be named? 2.What should names look like? 3.What should names resolve to? Source:

3: Resolution and Delegation 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 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 Based on slides at

4: Sequence 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) Sequence principle: Destinations, as specified by sources and also resolution of SIDs and EIDs, should be generalizable to sequences of destinations

Architecture - two new naming layers User-level descriptors (e.g., id, search string) App session App-specific search/lookup returns SID Transport Resolves SID to >=1 (EID,transport,port) Opens transport conns IP Resolves EID to IP Bind to EID Use SID as handle IP hdr EIDTCPSID… IP Transport App session Application Source:

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 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 ‘Resource records’ Caching servers caches replies