1 / 28

LNA and DOA

LNA and DOA. Aditya Akella 3/11/2010. A Layered Naming Architecture for the Internet. Hari Balakrishnan , Karthik Lakshminarayanan , Sylvia Ratnasamy , Scott Shenker , Ion Stoica , Michael Walfish From Sigcomm 2004. Architectural “Brittleness”. Hosts are tied to IP addresses

bebe
Download Presentation

LNA and DOA

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. LNA and DOA Aditya Akella 3/11/2010

  2. A Layered Naming Architecture for the Internet HariBalakrishnan, KarthikLakshminarayanan, Sylvia Ratnasamy, Scott Shenker, Ion Stoica, Michael Walfish From Sigcomm 2004

  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 • 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 • LNA 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 • Which entities should be named? • What should names look like? • 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 onlyto relevant aspects of underlying structure

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

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

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

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

  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 • Which entities should be named? • What should names look like? • What should names resolve to? • DOA

  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 ownlocation, but also to chosen delegates

  16. Take-Home Points from LNA • Two flat naming layers fix brittleness • SIDs and EIDs • Delegation is a powerful primitive • The follow-on DOA paper shows that • 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

  17. Middleboxes No LongerConsidered Harmful Michael Walfish, Jeremy Stribling, Maxwell Krohn, HariBalakrishnan, Robert Morris, and Scott Shenker From OSDI 2004

  18. The Problem • Middlebox: interposed entity doing more than IP forwarding (NAT, firewall, cache, …) • Not in harmony with the Internet architecture Firewall B NAT Host A Host D 10.1.1.4 New traffic class C • No unique identifiers and on-path blocking: • Barrier to innovation • Workarounds add complexity

  19. Reactions to the Problem • Purist: can’t live with middleboxes • Pragmatist: can’t live without middleboxes • Pluralist (crazy researchers): purist, pragmatist both right • DOAgoal: Architectural extension in which: • Middleboxes first-class Internet citizens • Harmful effects reduced, good effects kept • New functions arise

  20. DOA: Delegation-Oriented Architecture Firewall B NAT Host A Host D 10.1.1.4 0xf12312 0xf12312 C Architectural extension to Internet. Core properties (borrowed from LNA): 1. Use globally unique identifiers for hosts 2. Let receivers, senders invoke (and revoke) off-path boxes: delegation primitive

  21. Globally Unique Identifiers for Hosts (EIDs) • Location-independent, flat, big namespace • Hash of a public key  self-certification, security • EIDs Carried in packets body source EID IP hdr transport hdr destination EID DOA hdr

  22. Delegation Primitive Let hosts invoke, revoke off-path boxes • Receiver-invoked: sender resolves receiver’s EID to • An IP address or • An EID or sequence of EIDs • DOA header has destination stack of EIDs • Sender-invoked:push EID onto this stack body source EID IP hdr transport hdr destination EID stack

  23. DOA in a Nutshell Source EID: es IP: is DHT Delegate IP: j Process <eh, j> LOOKUP(eh) DOA j End-host EID: eh IP: ih body IP is j transport transport DOA es eh DOA es eh DOA Packet • End-host replies to source by resolving es • Authenticity, performance: discussed in the paper

  24. A Bit More About DOA • Incrementally deployable (same as LNA). • Requires: • Changes to hosts and middleboxes • No changes to IP routers (design requirement) • Global resolution infrastructure for flat IDs

  25. Off-path Firewall Firewall Source EID: es IP: is eh (ih, Rules) End-host eFW Sign (MAC) Network Stack eh eFW j EID: eFW j j es [eFW eh] is Verify <eFW, j> <eh, eFW> DHT es eh j ih EID: eh ih

  26. Off-path Firewall: Benefits • Simplification for end-users who want it • Instead of a set of rules, one rule: • “Was this packet vetted by my FW provider?” • Firewall can be anywhere, leading to: • Third-party service providers • Possible market for such services • Providers keeping abreast of new applications DOA enables this; doesn’t mandate it.

  27. Reincarnated NAT es ed es ed is is 5.1.9.9 10.1.1.3 ed 10.1.1.3 5.1.9.9 10.1.1.3 10.1.1.1 Source EID: es IP: is 5.1.9.9 Destination EID: ed ed DHT NAT NATed network • End-to-end communication • Port fields not overloaded • Especially useful when NATs are cascaded

  28. Summary and Conclusion • DOA’s goals: architectural extension to: • Reduce middleboxes’ badness + keep goodness • DOA’s properties: • Topology-independent, globally unique host ids • Let end-hosts invoke off-path boxes • DOA lets users, adminsoutsource functions • Competitive market in managed services • Can reconcile the purist and the pragmatist • Delegation: new property, not new philosophy

More Related