Routing%20Research%20Group@ietf64%20%20Routing%20in%20a%20Future%20Internet%20Architecture%20

1
Routing Research Group_at_ietf64Routing in a
Future Internet Architecture Contributions from
the NewArch ProjectBob Braden, USC/ISI
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 .

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/

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/

5
General NewArch Publications

• Tussle paper
• Clark, Wroclawski, Sollins, Braden, Tussle in
  Cyberspace Defining Tomorrows 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/

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

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?

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.

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.

10
Acknowledgment

• The rest of this presentation is heavily based
  upon Xiaoweis 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.

11
We Want to Let Users Choose Domain-Level Routes
ATT
UUNET

• Our hypothesis
• User choice stimulates competition.
• Competition fosters innovation.
• Validation requires market deployment.
• NIRA the technical foundation.

Local ISP
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

13
NIRAs Addressing
Core
B2
B1
1/16
2/16
13/32 21/32

• Strict provider-rooted hierarchical addressing
• Using fixed-length sub-field of prefix per level
• An address represents a valid route to the core.

11/32
12/32
R3
R2
R1
131/48 211/48
111/48 121/48
N3
122/48
N1
N2
1111000 1211000
1312000 2112000
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.

15
Basic Forwarding Algorithm
Core
B2
B1
1/16
2/16
13/32 21/32
11/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.

12/32
R1
R3
R2
131/48 211/48
111/48 121/48
N3
122/48
N1
N2
1312000 2112000
1111000 1211000
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 destinations addresses and
  optional topology information.
• Combining information from TIPP and NRLS, a user
  is able to select an initial route.

17
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
R3
R2
N3
N1
N2
1111000 1211000
temporarily unusable
18
Topology Map -- Bob's View
Core
B1

• User can then construct partial topology map of
  HIS routes to core.

R1
R3
R2
N1
1111000 1211000
19
Name-to-Route Lookup Service (NRLS)
Foo.com server
Core
Alice.foo.com 1312000 2112000
B2
B1

• An enhanced DNS service

R1
R3
R2
N3
N1
N2
1111000 1211000
Alice.foo.com 1312000 2112000
20
NIRA Summary

• User choice
• Choosing addresses ? choosing routes ? choosing
  providers
• Failure Handling
• Reactive Unreachable or timeout gt new route
• Proactive TIPP may signal route failure
• No global routing knowledge
• Consideration of provider compensation mechanisms
• "Evaluation shows NIRA is feasible."

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.

22

• (backup slides follow)

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

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
• IPs linkage of location with identity
• Universal transparency
• Network-layer multicast is fundamental

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

26
Routers Forwarding Tables
Uphill table
Core
B2
B1
1/16
2/16
1/16 B1

• Uphill table providers
• Downhill table customers, self
• Bridge table all others

13/32 21/32
11/32
12/32
Downhill table
R1
R3
R2
111/48 121/48
131/48 211/48
111/48 N1
11/96 self
N3
122/48
N1
N2
1111000 1211000
1312000 2112000
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.

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

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