1. A Layered Naming Architecture for the Internet Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, Michael Walfish IRIS Project [NSF]

2. Architectural Discontents in Today’s Internet Lack of features End-to-end QoS, host control over routing, end-to-end multicast,… Lack of protection and accountability Denial-of-service (DoS) Architecture is brittle

3. Architectural Brittleness Hosts are tied to IP addresses Mobility and multi-homing pose problems Services are tied to hosts A service is more than just one host: replication, migration, composition Packets might require processing at intermediaries before reaching destination “Middleboxes” (NATs, firewalls, …)

4. Naming Can Help Our thesis: proper naming can cure some ills Layered naming provides layers of indirection and shielding Many proposals advocate large-scale, overarching architectural change Routers, end-hosts, services Our proposal: Changes “only” hosts and name resolution Synthesis of much previous work

5. Internet Naming is Host-Centric Two global namespaces: 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 Motivated by host-centric applications

6. The Trouble with Host-Centric Names Host-centric names are fragile If a name is based on mutable properties of its referent, it is fragile Example: If Joe’s Web page www.berkeley.edu/~hippie moves to www.wallstreetstiffs.com/~yuppie, Web links to his page break Fragile names constrain movement IP addresses are not stable host names DNS URLs are not stable data names

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

8. Name Services and Hosts Separately Service identifiers (SIDs) are host- independent 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

9. The Naming Layers User-level descriptors (e.g., search) App session App-specific search/lookup returns SID Transport Resolves SID to EID Opens transport conns IP Resolves EID to IP Bind to EID Use SID as handle IP hdrEIDTCPSID… IP Transport App session Application

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

11. SIDs and EIDs should be Flat 0xf436f0ab527bac9e8b100afeff394300 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” Stable-name principle: A stable name should not impose restrictions on the entity it names

12. Resolution Service Flat Names Enable Flexible Migration <A HREF= http://f012012/pub.pdf >here is a paper <A HREF= http://f012012/pub.pdf >here is a paper HTTP GET: /docs/pub.pdf 10.1.2.3 /docs/ 20.2.4.6 HTTP GET: /~user/pubs/pub.pdf (10.1.2.3,80, /docs/) (20.2.4.6,80, /~user/pubs/) /~user/pubs/ SID abstracts all object reachability information Objects: any granularity (files, directories) Benefit: Links (referrers) don’t break Domain H Domain Y

13. Flat Names are a Two-Edged Sword Global resolution infrastructure needed Perhaps as “managed DHT” infrastructure Lack of local name control Lack of locality Not user-friendly User-level descriptors are human-friendly

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

15. Delegation Names usually resolve to “location” of entity Packets might require processing at intermediaries before reaching destination Such processing today violates layering Only element identified by packet’s IP destination should inspect higher layers 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

16. Delegation Enables Architecturally-Sound Intermediaries EID d IP ipd EID s Firewall EID f IP ipf Dest EIDMapping df fipf Delegate can be anywhere in the network, not necessarily on the IP path to d (ipd) SID/EID can resolve to sequence of delegates ipf EID d TCP hdr Packet structure (dests only) Resolution svc

17. Application-Layer Intermediaries EID s Spam/virus filter SID v, EID eidv, IP ipv Dest EID/SIDMapping SID fmid[v, ms] SID veidv ipv... Mail server SID ms Goal: Email to user must traverse spam filter en route to mail server fmid is SID for composed service ipv EID eidv TCP SID v data SID ms msg Resolution svc

18. Related Work Most direct inspiration: HIP + i3 + SFR Prototype: Delegation-Oriented Arch. (DOA) EID proposals: Nimrod, HIP, Peernet Mobility/multihoming: Mobile IP, IPv6, Migrate Intermediaries: IPNL, TRIAD, UIP, P6P, MIDCOM SID-like proposals: URNs, Globe, ONH Other architecture proposals PIP, Nimrod, IPv6, Active Networks, … FARA, Smart Packets, Network Pointers, Predicate Routing, Role-based Architecture

19. Take-Home Points Flat names are now plausible Two flat naming layers fix brittleness SIDs and EIDs Delegation is a powerful primitive

20. The Future? With flat SID/EID + delegation: Like hosts, data becomes first-class entity Middleboxes gracefully accommodated IP will continue to be a rigid infrastructure But naming is more malleable and can reduce architectural brittleness Deployment requires Changes to hosts Global resolution infrastructure