Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Masy 2003 Bob Braden -- New Arch 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 2
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 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.
Masy 2003 Bob Braden -- New Arch 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...
Masy 2003 Bob Braden -- New Arch 5
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 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!
Masy 2003 Bob Braden -- New Arch 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
Masy 2003 Bob Braden -- New Arch 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
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 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
Masy 2003 Bob Braden -- New Arch 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!
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 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)
Masy 2003 Bob Braden -- New Arch 14
NewArch -- the Process
• Re-examine the requirements and assumptions
Masy 2003 Bob Braden -- New Arch 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, ...
Masy 2003 Bob Braden -- New Arch 16
R
R
R
Host
Hosts
Host
subnet
subnet
subnet
packet
INTERNET
Router [gateway]
Masy 2003 Bob Braden -- New Arch 17
Masy 2003 Bob Braden -- New Arch 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 -- “Stack”model.
• Hop-by-hop forwarding – More robust than source-routed or connection-oriented subnetworks.
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 20
Link layer
(subnet-specific)
Internet layer
IP
Transport layer TCP, UDP, SCTP...
Application layer SMTP, HTTP, ...
Marbling the Internet Layer Cake
Physical layer
5
3
2
1
4
4.5 TLS
3.5 IPsec
2.5 MPLS
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 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 (=> competition)
Masy 2003 Bob Braden -- New Arch 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... !
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 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 I
Princeton University
October 28, 2002
Masy 2003 Bob Braden -- New Arch 26
Outline
• Motivation
• Overview of Role-Based Architecture (RBA)
• Using RBA
• Related Work
• Conclusions
Masy 2003 Bob Braden -- New Arch 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?
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 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
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 31
RSH Processing in a Node
Role
A Role
B
Role
C
Network Node
Payload RSH
1
RSH
2 RSH 3
Heap
Packet
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 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 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 34
Brief Overview of RBA
• Outline
– Role Data
– Role Definition
– Naming and Addressing
– Processing Rules
– Trivial Example
– Implementation: Packet Layout
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 37
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 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]
– <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 39
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 40
Simple Example Using RBA
{ RSH( HBHforward@* ; dest-NodeID, src-NodeID ), /* -> Forwarding role instance in every router */
RSH( Deliver@dest-NodeID ; serviceID, src-processID, 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 41
Possble RBA Packet Layout
NodeID or zero
RoleID
Flags Stack
Chain Byte Offset
Access
Bits
Element of Index Vector
Index
Vector Heap Area
Payload
Length (bytes) Flags DDescr
RSH Body
RSH
RSH format
...
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 43
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 provide a basis for realizing RBA.
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 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.
Masy 2003 Bob Braden -- New Arch 46
• http://www.isi.edu/newarch/