A Layered Naming Architecture for the Internet by Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, Michael Walfish

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


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

http://www.wustl.edu/arl

Key Architectural Questions

1. Which entities should be named?

2. What should names look like?

3. What should names resolve to?


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 onlyto relevant aspects of underlying structure

(to avoid limitations in flexibility & functionality)







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







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 http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt

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., email id, search string)

App session

App-specific search/lookupreturns 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 EID TCP SID …IP

Transport

App session

Application


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

• 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’ <name, value, type, class, TTL>

• Caching servers caches replies

Documents

A Layered Naming Architecture for the Internet by Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, Michael Walfish