CLARK, David. Designing an Internet.
MIT Press. 2018.
Chapter 5
The Architecture of the Internet
1
Internet Architecture original goals
2
1. Internet communication must continue despite loss of networks or gateways.
2. The Internet must support multiple types of communications service.
3. The Internet architecture must accommodate a variety of networks.
4. The Internet architecture must permit distributed management of its resources.
5. The Internet architecture must be cost effective.
6. The Internet architecture must permit host attachment with a low level of effort.
7. The resources used in the Internet architecture must be accountable.
Internet Architecture original goals
3
1.
Survivability in the Face of Failure
2.
Types of service
3.
Varieties of networks
4.
Distributed management
5.
Cost effectiveness
6.
Cost of attaching a host
7.
Accountability
Internet Architecture Requirements
1.
Robustness/Resilience
2.
Internetworking
3.
Heterogeneity
4.
Distributed management
5.
Cost
6.
Ease of Attachment
7.
Accountability
1. Security
2. Availability and resilience
3. Economic viability
4. Better management
5. Better Meet society’s needs
6. Longevity
7. Support for tomorrow’s computing
8. Exploit tomorrow’s networking
9. Support tomorrow’s applications
10. Fit for purpose (it works?)
4
1988 List 2008 List
CLARK, David. Designing an Internet.
MIT Press. 2018.
Chapter 6
Architecture and Function
5
What a Network Does?
6
How we describe, in architectural terms, what a network does?
Range of behavior is defined by the
expressive power of the packet header.
Per-Hop Behavior (PHB) is not just
forwarding.
Framework to describe PHB execution
7
Alignment of interests: aligned or adverse
Relationship between the sender of the packet and the owner of the element that implements the PHB.
Delivery: intentional, contingent, topological, or coerced
How the packet arrives at the element that implements the PHB?
Parametrization: explicit or implicit
The packet triggers the execution of a PHB, and
the data in the packet is the input to that PHB.
Pruning the Space of Options
8
Aligned If the sender wants the PHB to be executed, then intentional delivery and explicit arguments make sense. Contingent delivery may be suitable in some cases (e.g., the basic forwarding function), but explicit arguments (e.g., the address field) still make sense.
Adverse If the sender does not want the PHB to be
executed (it represents the interests of the receiver, not the sender), then the receiver cannot expect the sender to provide any explicit arguments to the PHB. In this
case, the PHB must depend on implicit arguments. Also, the PHB cannot count on intentional delivery, so
coerced delivery is the best option, with contingent or topological delivery as a fallback.
Example: NAT boxes
9
NAT boxes implement a PHB that is not simple
forwarding but includes rewriting of the source or destination address field.
Disrupted assumptions:
Single, global address space
No per-flow state in forwarding elements.
NAT boxes are an example of intentional delivery with explicit parameters (the addresses and port numbers).
If the interests of the end points are aligned, NATs are normally a small nuisance;
if the interests are not aligned, they provide a measure of protection, and in that respect fall into the coerced category.
Example: Firewalls
10
Are an example of a PHB that is adverse to the
interests of the hostile sender (potential attacker) and thus must depend on implicit information.
The firewall has the poorly defined task of trying to distinguish good behavior from bad, based on whatever hints can be gleaned from the packets.
Sometimes users want the blocking to succeed
(when they are being attacked) and sometimes
they want it to fail (when some third party, such
as a conservative government, is trying to block
their access to other sites on the Internet).
Example: Tunnels and overlay networks
11
This PHB causes the packet to be sent to the
destination address in the outer packet, not the inner packet.
When the packet reaches that destination, a PHB there must either remove the outer packet or reencapsulate the inner packet in a new outer packet.
The encapsulated packet is the explicit information used as input to the end point of the tunnel.
Sometimes the starting point of the tunnel is contingent or topological, sometimes it is
coincident with the sender, and sometimes it is
intentional.
Tussle and Regions
12
Different actors within the network (the sender, the receiver, the ISPs, other third-party participants) have the right to control certain parts of the network, and
within each such region of the network, the PHBs found there will be used to further the intentions of that actor.
The design of applications can also shift the balance of power among the various actors.
but from the point of view of balance of control, I
believe that a network operator should have to offer a very strong justification for inserting a service into a communication where neither end point requested or expected it to be there.
Generality
13
The taxonomy of delivery modes, alignment of
interests, and parameter modes applies equally to both packet-level PHBs and higher-level services.
One could use the term PHB generally to mean any service element that is inserted into a data flow or restrict the term to lower-level functions like firewalls or routers.
Since my goal is to discuss the role of
architecture, I am most concerned with cases
where a PHB justifies adding to the expressive
power of the packet.
Architectural Alternatives for Expressive Power
14
Addressing
Increasing the Expressive Power of a Design
Blank “scratch pad” in the packet
Pushdown stack model
A heap
Active networks
Per-Flow State
Signaling and state setup
State initiation bit
Maintaining state in intermediate elements
In-network state associated with receivers
Other issues
17
PHBs and Control of Network Resources
Debugging
Expressive Power and Evolvability
