Transcript Brief History of the Internet(1)

Rethinking the Internet Architecture
Bob Braden
USC Information Sciences Institute
Marina del Rey, CA
Univ of Mass.
May 15, 2003
Masy 2003
Bob Braden -- New Arch
1
What is “Network Architecture” ?
• A set of fundamental design principles, which can
guide detailed [protocol] engineering.
Architecture: both
a science and
an art.
Masy 2003
Bob Braden -- New Arch
2
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.
Masy 2003
Bob Braden -- New Arch
3
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...
Masy 2003
Bob Braden -- New Arch
4
The End-to-End Principle:
Foundation 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.
Masy 2003
Bob Braden -- New Arch
5
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 overengineer the Internet!
• We like elegance and simplicity, and we can tolerate uncertainty. Live
with it!
Masy 2003
Bob Braden -- New Arch
6
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
Masy 2003
Bob Braden -- New Arch
7
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
Masy 2003
Bob Braden -- New Arch
8
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.
Masy 2003
Bob Braden -- New Arch
9
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
Masy 2003
P9. Routing
P10. Regions
P11. Protocol Layering
P12. Minimal Dependency
P13. Security
P14. Congestion
P15. Resource Allocation
P16. Mobility
Bob Braden -- New Arch
10
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!
Masy 2003
Bob Braden -- New Arch
11
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.
Masy 2003
Bob Braden -- New Arch
12
• 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)
Masy 2003
Bob Braden -- New Arch
13
NewArch -- the Process
• Re-examine the requirements and assumptions
Masy 2003
Bob Braden -- New Arch
14
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, ...
Masy 2003
Bob Braden -- New Arch
15
INTERNET
Host
Host
packet
R
subnet
R
subnet
R
subnet
Router [gateway]
Hosts
Masy 2003
Bob Braden -- New Arch
16
Masy 2003
Bob Braden -- New Arch
17
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 -- “Stack”model.
• Hop-by-hop forwarding
– More robust than source-routed or connection-oriented subnetworks.
Masy 2003
Bob Braden -- New Arch
18
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.
Masy 2003
Bob Braden -- New Arch
19
Marbling the Internet Layer Cake
Application layer
5
4
3
2
1
Masy 2003
SMTP, HTTP, ...
Transport layer
TCP, UDP, SCTP...
Internet layer
IP
4.5
TLS
3.5 IPsec
2.5 MPLS
Link layer
(subnet-specific)
Physical layer
Bob Braden -- New Arch
20
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.
Masy 2003
Bob Braden -- New Arch
21
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:
•
•
•
•
Masy 2003
Y= Provide regions of trust
Y= Support ubiquitous mobility
Y= Carry congestion state in packet headers
Y= Empower users to choose ISPs (=> competition)
Bob Braden -- New Arch
22
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... !
Masy 2003
Bob Braden -- New Arch
23
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.
Masy 2003
Bob Braden -- New Arch
24
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 I
Princeton University
October 28, 2002
Masy 2003
Bob Braden -- New Arch
25
Outline
• Motivation
• Overview of Role-Based Architecture (RBA)
• Using RBA
• Related Work
• Conclusions
Masy 2003
Bob Braden -- New Arch
26
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?
Masy 2003
Bob Braden -- New Arch
27
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.
Masy 2003
Bob Braden -- New Arch
28
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 subheader
Masy 2003
Bob Braden -- New Arch
29
• 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.
Masy 2003
Bob Braden -- New Arch
30
RSH Processing in a Node
Network Node
Role
A
RSH
1
Role
C
Role
B
RSH
2
Payload
RSH 3
Heap
Packet
Masy 2003
Bob Braden -- New Arch
31
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.
Masy 2003
Bob Braden -- New Arch
32
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 complex;
can 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 (Don’t muck with my meta-data!)
– RSH might be unit for encryption of role data
Masy 2003
Bob Braden -- New Arch
33
Brief Overview of RBA
• Outline
–
–
–
–
–
–
Masy 2003
Role Data
Role Definition
Naming and Addressing
Processing Rules
Trivial Example
Implementation: Packet Layout
Bob Braden -- New Arch
34
More About Role Data
• RSHs can be added, modified, or deleted as a
packet is forwarded.
• RSHs subdivide the header information (metadata) 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.
Masy 2003
Bob Braden -- New Arch
35
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.
Masy 2003
Bob Braden -- New Arch
36
More about Roles
• A role instantiation called an actor.
• (MJH doesn’t 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?)
Masy 2003
Bob Braden -- New Arch
37
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]
– <RoleAddr> ::= <RoleID> @ <NodeID> | <RoleID> @ *
Wildcard NodeID: RSH will be processed by any instance of
the RoleID that it encounters along the path.
• Symbolically, an RSH is:
RSH( <RoleAddr>, ... ; <RSHbody> )
(More accurately: RSH( <RoleAddr>:<access bits>, ... ) )
Masy 2003
Bob Braden -- New Arch
38
Processing Rules
• A Role R on node X may access an RSH if:
(1) The RSH is explicitly addressed to R
RoleAddr = R@X or R@*,
(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 -> expand, or encrypt -> decrypt
– Proper nesting: compress -> encrypt -> decrypt -> expand
– Use presence/absence of RSHs (between nodes) plus precedence
rules for roles (within the same node).
Masy 2003
Bob Braden -- New Arch
39
Simple Example Using RBA
{ RSH( HBHforward@* ; dest-NodeID, src-NodeID ),
/* -> Forwarding role instance in every router */
RSH( Deliver@dest-NodeID ; serviceID, srcprocessID,
payload
),
/* Deliver payload to specific service at dest node */
RSH( Reassemble@dest-NodeID ; offset, MFflag},
RSH( TrustScope@* ; <local scope> )
}
Masy 2003
Bob Braden -- New Arch
40
Possble RBA Packet Layout
Index
Vector
RSH
...
Payload
Heap Area
Element of Index Vector
RoleID
RSH format
Flags
NodeID or zero
Flags
Masy 2003
Stack
Chain
Access
Bits
DDescr
Length (bytes)
RSH Body
Byte Offset
Bob Braden -- New Arch
41
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.
Masy 2003
Bob Braden -- New Arch
42
Related Work
• Hasn’t 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 -O’Malley & Peterson 1992, Bhatti&Schlichting 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
Masy 2003
Bob Braden -New Arch
43
provide a basis for realizing
RBA.
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.
Masy 2003
Bob Braden -- New Arch
44
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.
Masy 2003
Bob Braden -- New Arch
45
• http://www.isi.edu/newarch/
Masy 2003
Bob Braden -- New Arch
46