1 / 29

NewArch Project: A Strengthened Internet Architecture

Explore contributions from the NewArch Project, funded by DARPA, focusing on internet architecture for the future. Delve into economic viability, trustworthiness, and user empowerment in routing.

cmcnulty
Download Presentation

NewArch Project: A Strengthened Internet Architecture

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. Routing Research Group@ietf64Routing in a Future Internet Architecture –Contributions from the NewArch ProjectBob Braden, USC/ISI Braden: RRG @ ietf64 Nov 05

  2. The NewArch Research Project • Funded by DARPA: July 2000 – June 2003. • Primary Participants: • MIT: Dave Clark*, John Wroclawski, Karen Sollins • ISI: Bob Braden, Ted Faber, Aaron Falk • ICIR (Berkeley): Mark Handley • Other: Noel Chiappa • Grad students: Xiaowai Yang**, Dina Katabi, Joanna Kulik, Venkata Pingali * “The Internet Architect” ~ 1980 –1990 ** The primary source of this talk . Braden: RRG @ ietf64 Nov 05

  3. The NewArch Project • Ambition: "Develop and evaluate … a strengthened Internet architecture for the 10-20 year time frame“ • Results: • Review of changing requirements • High-level exploration of some key architectural issues and ideas • Conference and workshop papers • (slightly monumental) Final Report http://www.isi.edu/newarch/ Braden: RRG @ ietf64 Nov 05

  4. Some Ideas that NewArch Considered • Economics (business models, “tussle”, etc.) • “Trustworthiness” (security and robustness) • Greater architectural heterogeneity • Ubiquitous mobility • Expanded application architecture • Meta-architecture http://www.isi.edu/newarch/ Braden: RRG @ ietf64 Nov 05

  5. General NewArch Publications • Tussle paper • Clark, Wroclawski, Sollins, Braden, “Tussle in Cyberspace: Defining Tomorrow’s Internet.” ACM SIGCOMM 2002. • Architectural Overview • Clark, Sollins, Wroclawski, Faber, “Addressing Reality: An Architectural Response to Real-World Demands on the Evolving Internet.” ACM SIGCOMM 2003 FDNA Workshop. • Final Technical Report • Clark et. al., “NewArch: Future Generation Internet Architecture”. Final Technical Report for DARPA. See: http://www.isi.edu/newarch/ Braden: RRG @ ietf64 Nov 05

  6. Specific NewArch Research Initiatives • Global internetwork without a global address space: FARA • [Clark et al, Trans on Networking, June 2005] • Routing architecture for user empowerment: NIRA • [Wang, Sigcomm 2003] • Explicit Congestion Control: XCP • [Katabi et al, Sigcomm 2002] • Non-layered architecture (Role-Based Architecture) • [Braden et al, Hotnets I, 2002] • Regionalization • [Sollins et al, Sigcomm 2003 FDNA Workshop] Braden: RRG @ ietf64 Nov 05

  7. Routing in NewArch • Issues we discussed: • Is “routing architecture” fundamentally separable from the overall network architecture? • Hypothesis [Chiappa]: the existing routing paradigms do not scale; need map-based routing (NIMROD). • How do the goals of economic viability and trustworthiness impact the routing architecture? • Can user empowerment be achieved with scalable routing? Braden: RRG @ ietf64 Nov 05

  8. Goal: User Empowerment Give end users (some) control over: • Inter-domain routing • Use inter-ISP competition to encourage introduction of improved network-level services (e.g., QoS, multicasting, …) • Application-layer elements within the network. • Relays, proxies, firewalls, other middle boxes. Braden: RRG @ ietf64 Nov 05

  9. Routing for User Empowerment • Xiaowei Yang's MIT thesis described an architecture for user-empowered inter-domain routing: NIRA. • “NIRA: A New Internet Routing Architecture”, Xiaowei Yang, ACM Sigcomm 2003 FDNA Workshop, August 2003. • NIRA represents a significant rethinking about inter-domain routing. • It is RESEARCH; probably not final answer, but important ideas. Braden: RRG @ ietf64 Nov 05

  10. Acknowledgment • The rest of this presentation is heavily based upon Xiaowei’s slides, with her kind permission. • Xiaowei is now on the CS faculty of UC Irvine. • The RRG might invite Xiaowei to present her own work. Braden: RRG @ ietf64 Nov 05

  11. We Want to Let Users Choose Domain-Level Routes AT&T UUNET • Our hypothesis: • User choice stimulates competition. • Competition fosters innovation. • Validation requires market deployment. • NIRA: the technical foundation. Local ISP Braden: RRG @ ietf64 Nov 05

  12. Central Ideas of NIRA • Built on earlier ideas of explicit routing, up/down routing. • Defines efficient representation of explicit route for common case. • Assuming today's generally tree-shaped inter-domain topology, with providers and customers • "Core" in the center. • Strict provider-rooted hierarchical addressing Braden: RRG @ ietf64 Nov 05

  13. Alice Bob NIRA’s Addressing Core B2 B1 1::/16 2::/16 1:3::/32 2:1::/32 • Strict provider-rooted hierarchical addressing • Using fixed-length sub-field of prefix per level • An address represents a valid route to the core. 1:1::/32 1:2::/32 R2 R3 R1 1:3:1::/48 2:1:1::/48 1:1:1::/48 1:2:1::/48 1:2:2::/48 N3 N1 N2 1:1:1::1000 1:2:1::1000 1:3:1::2000 2:1:1::2000 Braden: RRG @ ietf64 Nov 05

  14. NIRA Addressing • A source and a destination address unambiguously represent a common type of route (strictly up & down) • General routes may use source routing headers • Scalable because… • Financial factors limit the size of core. • Provider hierarchy is shallow. • A domain has a limited number of providers. • Leaving out a number of important details – see paper. Braden: RRG @ ietf64 Nov 05

  15. 1:1:1::1000 up down 1:3:1::2000 Alice Bob Basic Forwarding Algorithm Core B1 B2 1::/16 2::/16 1:3::/32 2:1::/32 1:1::/32 1:2::/32 • Uphill and downhill routing tables in each router. • Look up destination address in the downhill table (for short-cut). • If no match, look up the source address in the uphill table. R1 R2 R3 1:3:1::/48 2:1:1::/48 1:1:1::/48 1:2:1::/48 1:2:2::/48 N3 N1 N2 1:3:1::2000 2:1:1::2000 1:1:1::1000 1:2:1::1000 Braden: RRG @ ietf64 Nov 05

  16. System Components of NIRA • Addressing • Route discovery • Topology Information Propagation Protocol (TIPP) • A user learns his addresses and topology information (static) and perhaps route availability (dynamic) • Name-to-Route mapping • Name-to-Route Lookup Service (NRLS) – an enhanced DNS service • A user learns destination’s addresses and optional topology information. • Combining information from TIPP and NRLS, a user is able to select an initial route. Braden: RRG @ ietf64 Nov 05

  17. Alice Bob What does TIPP Do? Core B1 B2 X • Propagates addresses and topology (controlled by policy) • May proactively notify of route unavailability • User can then construct partial topology map of HIS routes to core. R1 R2 R3 N3 N1 N2 1:1:1::1000 1:2:1::1000 temporarily unusable Braden: RRG @ ietf64 Nov 05

  18. Bob Topology Map -- Bob's View Core B1 • User can then construct partial topology map of HIS routes to core. R1 R2 R3 N1 1:1:1::1000 1:2:1::1000 Braden: RRG @ ietf64 Nov 05

  19. Alice Bob Name-to-Route Lookup Service (NRLS) Foo.com server Core Alice.foo.com 1:3:1::2000 2:1:1::2000 B1 B2 • An enhanced DNS service R1 R2 R3 N3 N1 N2 1:1:1::1000 1:2:1::1000 Alice.foo.com 1:3:1::2000 2:1:1::2000 Braden: RRG @ ietf64 Nov 05

  20. NIRA Summary • User choice • Choosing addresses  choosing routes  choosing providers • Failure Handling • Reactive: Unreachable or timeout => new route • Proactive: TIPP may signal route failure • No global routing knowledge • Consideration of provider compensation mechanisms • "Evaluation shows NIRA is feasible." Braden: RRG @ ietf64 Nov 05

  21. Issues for the RRG • Is user empowerment a good idea, in general? • Should user empowerment be a requirement for inter-domain routing, in particular? • Is the NIRA approach a fruitful direction? • “NIRA: A New Internet Routing Architecture”, Xiaowei Yang, ACM Sigcomm 2003 FDNA Workshop, August 2003. Braden: RRG @ ietf64 Nov 05

  22. (backup slides follow) Braden: RRG @ ietf64 Nov 05

  23. NewArch Final Technical ReportConclusions • Future architecture should design for: • User Empowerment • Tussle [SIGCOMM 2002] • Trust-modulated transparency • Packet aggregates as a network abstraction • Varying amounts of control state in the network (not only datagrams) • Freedom from requiring a global address space • Application control over network services [QoS, etc.] • Ease of user configuration Braden: RRG @ ietf64 Nov 05

  24. NewArch Conclusions • Retain fundamental Internet nature: • An application-independent data carriage service based on variable-length packets. • But, re-examine some assumptions: • Pure datagrams • Global addresssing • IP’s linkage of location with identity • Universal transparency • [Network-layer] multicast is fundamental Braden: RRG @ ietf64 Nov 05

  25. What is Network Architecture? • Network architecture defines: [FTR 2.] • What the network is for. • How it accomplished those functions. • How the system is broken into fundamental objects • How those parts interact; assumptions each part makes. • Also, it should be explicit about what is NOT specified. • Meta-architecture • FARA defines a class of architectures. Instantiated one specific FARA-based architecture, FARA-M [FARA paper: 2003 FDNA] Braden: RRG @ ietf64 Nov 05

  26. Alice Bob Routers’ Forwarding Tables Uphill table Core B1 B2 1::/16 2::/16 1:3::/32 2:1::/32 1:1::/32 1:2::/32 Downhill table • Uphill table: providers • Downhill table: customers, self • Bridge table: all others R1 R2 R3 1:1:1::/48 1:2:1::/48 1:3:1::/48 2:1:1::/48 1:2:2::/48 N3 N1 N2 1:1:1::1000 1:2:1::1000 1:3:1::2000 2:1:1::2000 Braden: RRG @ ietf64 Nov 05

  27. Provider Compensation • Contractual agreements. • Users cannot use arbitrary routes. • Providers use policy checking to prevent illegitimate route usage. • Direct business relationships • Common case: verify source address • General case: packet filtering • Indirect business relationship: end users pay remote providers • Policy is made upon the originator or the consumer of a packet. • An open and general problem. Working in progress with Jennifer Mulligan and David Clark. • Various billing schemes are possible. • Flat fee, usage-based billing. Braden: RRG @ ietf64 Nov 05

  28. Related Work • Routing architecture proposals • Nimrod [RFC 1992], Inter-Domain Policy Routing [RFC 1478], Scalable Inter-Domain Routing Architecture [Estrin92], TRIAD [Cheriton00], Feedback Based Routing [Zhu02] • Addressing schemes • PIP [Francis93], SIP [Deering93], IPv6 [RFC 3513], Provider-rooted addresses [Tsuchiya91] [Francis94] • My work: • Supports user choice • Scalable • Evaluation Braden: RRG @ ietf64 Nov 05

  29. Looking Forward • New provider compensation model • Packet-level authentication • Stable routing with user choice • Deployment of NIRA • Tools, methodologies, and principles to guide system design and understanding • Benchmark simulation configurations • Robust protocol design Braden: RRG @ ietf64 Nov 05

More Related