1 / 24

A Layered Naming Architecture for the Internet

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.

edward
Download Presentation

A Layered Naming Architecture for the Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. Outline • Introduction • Design Principles • Architecture • Flat names • Related work • Conclusion Shobana Andrew

  3. 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, …

  4. 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

  5. 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

  6. 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

  7. “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)

  8. 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

  9. 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

  10. Key Architectural Questions • Which entities should be named? • What should names look like? • What should names resolve to? Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt

  11. 1: Name services/data, separate from the hosts Binding principle: Names should bind protocols onlyto 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 location-independent 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

  12. Key Architectural Questions • Which entities should be named? • What should names look like? • What should names resolve to? Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt

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

  14. Key Architectural Questions • Which entities should be named? • What should names look like? • What should names resolve to? Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt

  15. 3: Resolution and Delegation Delegation principle: A network entity should be able to direct resolutions of its name not only to its ownlocation, 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

  16. 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)

  17. Architecture - two new naming layers Application Use SID as handle App session Bind to EID Transport EID TCP SID … IP hdr IP User-level descriptors(e.g., email id, search string) App-specific search/lookup returns SID App session Resolves SID to >=1 (EID,transport,port) Opens transport conns Transport Resolves EID to IP IP Source: http://nms.lcs.mit.edu/talks/layerednames-sigcomm04.ppt

  18. 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

  19. 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

  20. 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

  21. 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

  22. Backup slides

  23. Domain Name System (DNS) gov edu … wustl … Root name server Wustl name server … A name server per ‘zone’ … • 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

  24. 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

More Related