Rethinking the Internet Architecture

1
Rethinking the Internet Architecture

• Bob Braden
• USC Information Sciences Institute
• Marina del Rey, CA
• Univ of Mass.
• May 15, 2003

2
What is Network Architecture ?

• A set of fundamental design principles, which can
  guide detailed protocol engineering.
• Architecture both a science and an art.

3
Network Architecture

• Informal architectural ideas guided the design of
  the Internet protocols, but formal discussion of
  the Internet architecture only came 10 years
  later...
• The Design Philosophy of the DARPA Internet
  Protocols, David D. Clark, SIGCOMM 88, p.106.
• The boundaries of architecture are fuzzy
• Bounded from above by requirements
• Bounded from below by engineering.

4
Network Architecture

• The Network architecture metaphor emerged from
  mathematical sciences (CS), not engineering.
• Simplicity is vital, and elegance is desirable
• Founded upon Computer-Sciency kinds of
  concepts...
• Modularity
• Naming -- global vs. local
• Communication state -- Where how?
• Indirection
• Resource allocation
• Security boundaries -- Where and how?
• Etc...

5
The End-to-End PrincipleFoundation of the
Internet architecture

• Rubric Dumb network, smart end systems (Exact
  opposite of telephone network!)
• Dumb network
• Provides only least common service
• Datagram service no connection state in routers
• Best effort all packets treated equally.
• Can lose, duplicate, reorder packets.
• Smart hosts
• Maintain state to enhance network service (e.g.,
  reliability, ordering...)
• Fate-sharing If a host crashes and loses comm
  state, applications that are communicating share
  this fate.

6
Philosophical Gap

• Deep philosphical gap
• Telecommunications Engineers
• The Internet is under-engineered -- it does not
  solve all problems in the most optimal and
  controllable manner.
• We like certainty and complexity.
• Internet Designers
• Optimal is NOT the point. The future
  adaptability of the Internet to new technologies
  and new services requires that we NOT
  over-engineer the Internet!
• We like elegance and simplicity, and we can
  tolerate uncertainty. Live with it!

7
So, Where are We?

• The Internet design has been very successful
• Scaled into a huge worldwide infrastructure
• Adapted to many new comm technologies
• Frame Relay, ATM, wireless, optical, ...
• Easily adapted to unforeseen applications -- Web,
  P2P
• Adapts over a huge dynamic range -- O(106)
• BUT...
• Serious new challenges -- new requirements and
  issues
• Loss of technical coherence

8
New Challenges to Architecture

• Commercial Internet
• Business models -- ISPs need to be able to make
  money
• Need to harness competition to drive innovation
• Legal, political, and public policy issues
• Erosion of trust (Loss of innocence)
• Spam/viruses/worms/DDoS attacks/...
• New technologies and applications
• Optical networking
• IP telephony

9
Loss of Technical Coherence

• Equipment vendors want to sell boxes
• They are busily designing point solutions to
  specific problems often in conflict, lacking in
  generality.
• Looks like a downward spiral into technical chaos.

10
Internet Architectural Principles

• P1. Multiplexing
• P2. Transparency
• P3. Universal connectivity
• P4. End-to-End argument
• P5. Subnet heterogeneity
• P6. Common Bearer Service
• P7. Forwarding context
• P8. Global addressing

• P9. Routing
• P10. Regions
• P11. Protocol Layering
• P12. Minimal Dependency
• P13. Security
• P14. Congestion
• P15. Resource Allocation
• P16. Mobility

11
Ooops...

• Every one of these 16 architectural principle
  categories is problematic in some manner!
• (a) Being broken for commercial reasons
• (b) Being broken to obtain additional
  functionality
• (c) Protected against unwise optimization only by
  constant struggle in the IETF.
• (d) Represent real unmet requirements
• (e) Mods suggested by researchers.
• (f) Mods urged by mysterious government agencies
• Details? Need another 2 hours!

12
NewArch -- the Dream

• Could a new Internet architecture restore some
  technical coherence and meet new requirements?
• A small DARPA-funded project, NewArch, has been
  trying to answer this question.
• Objective to figure out what the Internet
  architecture would have been if we had known in
  1979 what we know today.
• Ignore compatibility/transition issues.

13

• NewArch Players
• Dave Clark, John Wroclawski, Karen Sollins, a
  cast of GRAs at MIT.
• Bob Braden, Ted Faber, Aaron Falk, Venkata
  Pingali at ISI.
• Mark Handley Scott Shenker at ICIR.
• Noel Chiappa (retired)

14
NewArch -- the Process

• Re-examine the requirements and assumptions

15
Original Internet Requirements (1)

• Survivability (robustness)
• Messages must get through, no matter what.
• Service generality
• Support widest possible set of applications and
  service models, from FTP to Telnet to packet
  video and voice.
• Diverse network sub-net technologies
• Heterogeneity is fundamental must communicate
  across arbitrary interconnection of links -LANs,
  WANs, wireless, satellite, ...

16
INTERNET
Host
Host
packet
subnet
R
subnet
R
R
subnet
Router gateway
Hosts
17
(No Transcript)
18
Internet Architecture Deep Assumptions

• Packet switching
• Unit of data is a packet
• Packets are statistically multiplexed (not TDM)
• Strict protocol layering
• Successive layers of functional abstraction
• Header encapsulation
• Headers added/removed in strict LOFO order --
  Stackmodel.
• Hop-by-hop forwarding
• More robust than source-routed or
  connection-oriented subnetworks.

19
Erosion of the End-to-End Principle

• A current architectural battleground
• Middle boxes process user packets inside the
  network.
• E.g., web caches and proxies, application-level
  firewalls, NAT boxes, performance-enhancing
  proxies,
• They perform useful functions but violate the E2E
  Principle.
• That is more than religion -- they reduce
  robustness, generality, extensibility, and
  simplicity.

20
Marbling the Internet Layer Cake
Application layer SMTP, HTTP, ...
5
4.5 TLS
Transport layer TCP, UDP, SCTP...
4
3.5 IPsec
Internet layer IP
3
2.5 MPLS
Link layer (subnet-specific)
2
Physical layer
1
21
NewArch -- the Process

• Re-examine the requirements and assumptions
• Try to understand implications for the Internet
  architecture of economic, political, and social
  forces.
• Examine a set of propositions of the form
• What if we relaxed assumption X?
• What if we added assumption Y?
• and pursue a few of the promising Xs and Ys.

22
Sample of Propositions Considered

• Relaxed assumption X
• X All packets (e.g., no bit streams)
• X Protocol layering
• X Network locator end-point identifier
• Added assumption Y
• Y Provide regions of trust
• Y Support ubiquitous mobility
• Y Carry congestion state in packet headers
• Y Empower users to choose ISPs (gt competition)

23
NewArch -- the Results

• A lot of talk...
• 18 3-hour teleconferences, 3 face-face meetings
• 28 internal working papers
• A few conference papers
• Perhaps some new research directions
• Quite a lot of overlap with earlier work, but
  within a more comprehensive framework.
• Too many ideas, too little time... !

24
Project Publications

• Clark, D., Wroclawski, J., Sollins, K., Braden,
  R., "Tussle in Cyberspace Defining Tomorrow's
  Internet". ACM SIGCOMM 2002.
• Katabi, D., Handley, M., Rohrs, C., "Congestion
  Control for High Bandwidth-Delay Product
  Networks", ACM SIGCOMM 2002.
• David Clark, Aaron Falk, Venkata Pingali, and
  Robert Braden, "FARA Reorganizing the Addressing
  Architecture". March 2003.
• Karen Sollins, "Recursively invoking Linnaeus A
  Taxonomy of Distributed Naming Systems". February
  2003.
• Xiaowei Yang, "NIRA A New Internet Routing
  Architecture". January 2003.
• Braden, R., Faber, T., Handley, M., "From
  Protocol Stack to Protocol Heap -- Role-Based
  Architecture". HotNets-I, Princeton, NJ, October
  2002.

25
From Protocol Stack to Protocol Heap--
Role-Based Architecture (RBA)

• Bob Braden, Ted Faber
• USC Information Sciences Institute
• Mark Handley
• ICSI Center for Internet Research
• ACM HotNets IPrinceton UniversityOctober 28,
  2002

26
Outline

• Motivation
• Overview of Role-Based Architecture (RBA)
• Using RBA
• Related Work
• Conclusions

27
Motivation

• The IETF has become an architectural pretzel
  factory.
• Layer violations
• Sub-layer proliferation
• E.g., MPLS at 2.5, IPsec at 3.5, and TLS at 4.5.
• Feature interactions
• Cross-product complexity
• Erosion of E2E model -- middleboxes
• Firewalls, NATs, proxies, caches, ...
• A paradise for lovers of complexity
• Can we somehow reduce the complexity and increase
  the architectural flexibility?

28
Motivation ...

• Suggestion 1 Replace the traditional protocol
  layering paradigm with a more general model.
• Many of these problems seem to be related to
  traditional layering.
• Suggestion 2 Provide a protocol mechanism to
  attach additional metadata to data packets --
  in-band signaling -- for middleboxes.
• Attach color-coded stickies to packets in the
  network.
• These suggestions led to the concepts of
  Role-Based Architecture (RBA)
• Giving up layering has profound consequences for
  how we think about protocols.

29
What Does Non-Layered Mean?

• Traditional layered architecture
• Modularity
• Functional unit for each protocol layer.
• Packet header format
• Sub-header for each layer, forming a logical
  stack.
• Header processing rules
• Order Headers processed in order by layer (LOFO)
• Access A functional module can read/write only
  its own sub-header

30

• Non-Layered architecture
• Modularity
• Role Functional spec of a communication building
  block.
• Packet header format
• An arbitrary collection of sub-headers role
  data.
• These are Role-Specific Headers (RSHs).
• RSHs are addressed to roles.
• Header data structure is now a logical heap of
  RSHs.
• Processing rules need new rules for order,
  access.

31
RSH Processing in a Node
Network Node
Role A
Role C
Role B
Write
Read
Heap
Packet
32
Objectives of RBA (1)

• Clarity
• Replace layer violations with architected role
  interactions
• Flexibility
• Roles have more flexible relationships than
  layers
• Extensibility
• Roles are modular and hopefully orthogonal. No
  layer restrictions.
• Inband Signaling
• RSHs can act as stickies, e.g., to control
  middle boxes.
• Auditability
• Can leave RSHs after they have been consumed,
  to signal to downstream nodes that a function has
  been performed.

33
Objectives of RBA (2)

• Portability
• Allow roles to be sited arbitrarily on nodes.
• For extra credit mobile roles that migrate among
  nodes
• Re-Modularization
• Current monolithic protocol layers are large and
  complexcan re-modularize into smaller units.
• This is not a new idea
• It is unclear how far one should go towards
  micro-roles
• But RBA gives us freedom of choice on functional
  granularity
• Security
• Hide particular role data (Dont muck with my
  meta-data!)
• RSH might be unit for encryption of role data

34
Brief Overview of RBA

• Outline
• Role Data
• Role Definition
• Naming and Addressing
• Processing Rules
• Trivial Example
• Implementation Packet Layout

35
More About Role Data

• RSHs can be added, modified, or deleted as a
  packet is forwarded.
• RSHs subdivide the header information (meta-data)
  along role boundaries.
• Granularity of RSHs is an important design
  parameter
• Trade off processing overhead against reusability
• RSHs generally carry metadata, but some may not,
  only modifying processing by their presence.

36
Defining Roles

• Roles communicate with each other only via RSHs
• (for role mobility)
• Roles may have local APIs to node software.
• A fully-specified role will be specified by
• Its internal state, its algorithms, its APIs, and
  the RSHs it will send and receive.
• Generic roles
• Want to be able to derive a full role
  specification from a generic functional
  definition by stepwise refinement.
• Aid reasoning about protocols and for developing
  new roles.

37
More about Roles

• A role instantiation called an actor.
• (MJH doesnt like the Hollywoodiness of this
  term)
• Roles are often coupled in conjugate pairs
• E.g., Encrypt, Decrypt Compress, Expand
  Fragment, Reassemble
• (Undecided Is a conjugate pair one distributed
  role with two actors, or two interrelated roles?)

38
Naming and Addressing in RBA

• Role type is identified by unique name RoleID
• Color-coded
• RSHs are addressed to role(s)
• Assume an address space for nodes NodeID
  IP addr
• ltRoleAddrgt ltRoleIDgt _at_ ltNodeIDgt ltRoleIDgt _at_
  
• Wildcard NodeID RSH will be processed by any
  instance of the RoleID that it encounters along
  the path.
• Symbolically, an RSH is RSH( ltRoleAddrgt, ...
  ltRSHbodygt )
• (More accurately RSH( ltRoleAddrgtltaccess
  bitsgt, ... ) )

39
Processing Rules

• A Role R on node X may access an RSH if
• (1) The RSH is explicitly addressed to R
  RoleAddr R_at_X or R_at_,
• (2) or R is promiscously listening for RoleID R
  that is addressed by RSH
• Either may be restricted by access control bits.
• Enforce Sequencing rules
• Legal ordering of conjugate roles
• compress -gt expand, or encrypt -gt decrypt
• Proper nesting compress -gt encrypt -gt decrypt -gt
  expand
• Use presence/absence of RSHs (between nodes) plus
  precedence rules for roles (within the same node).

40
Simple Example Using RBA

• RSH( HBHforward_at_ dest-NodeID, src-NodeID
  ), / -gt Forwarding role instance
  in every router / RSH( Deliver_at_dest-NodeID
  serviceID, src-processID, payload ),
  / Deliver payload to specific service at
  dest node /
• RSH( Reassemble_at_dest-NodeID offset, MFflag,
• RSH( TrustScope_at_ ltlocal scopegt )

41
Possble RBA Packet Layout
Index Vector
...
Payload
Heap Area
RSH format
Element of Index Vector
Length (bytes)
DDescr
Flags
RoleID
NodeID or zero
RSH Body
Stack
Flags
Byte Offset
Chain
Access
Bits
42
Using RBA -- Possibilities

• Pure RBA architecture
• All functions, from current link layer to
  applications, using roles.
• RBA only above the Link Layer
• Probably want to treat the link layer as
  god-given.
• RBA only above IP layer
• Retain forwarding efficiency of IP in routers.
• RBA overhead then only in end systems and
  middleboxes
• RBA only in app layer
• We need an application layer architecture RBA
  could be a nifty framework for it. Would still
  help immensely with middleboxes.
• RBA only as abstraction for reasoning about
  protocols.

43
Related Work

• Hasnt this all been done before? Not really...
• Modular construction of protocol stacks
• Peterson et. al. 1991 (X-kernel), Tschudin 1991.
• Protocol decomposition into micro-protocols
• For re-usability customization -- OMalley
  Peterson 1992, BhattiSchlichting 1995, Kohler
  et al 2000 (Click), Kohler et al 1999 (Prolac).
• For performance -- Haas 1991, Zitterbart et al
  1993.
• These all focused on protocol implementations,
  not on the protocols themselves.
• RBA is orthogonal concept in fact, the earlier
  work may provide a basis for realizing RBA.

44
Conclusions ...

• This is a position paper.
• We did not build an RBA prototype.
• We have worked through some simple examples.
• Some of the basic definitions are still subject
  to debate.
• I hope I have convinced you that a non-layered
  approach to protocols might not be totally crazy.
• But we are so used to thinking in a layerist
  manner that using RBA does twist the head a bit.

45
Conclusions

• Advantages of RBA
• Modularizes functionality better then layering
  does.
• Provides an explicit place for middlebox metadata
• Should create fewer unexpected feature
  interactions
• Disadvantages of RBA
• Replacement of deployed protocols
• Less efficient (header space, processing).
• Greater flexibility may itself increase
  complexity and confusion.

46

• http//www.isi.edu/newarch/