Network Layer

Here we find the first place in the protocol stack that has some idea of end-to-end (sender to receiver) communication. There is also knowledge of what the "network cloud" looks like on the inside.

Services of the network layer

When you buy data communications services you often buy the services of the network layer. So a customer may contract with a carrier to provide an IP connection to a public data network like the Internet. The customer wants a clean, simple interface. It doesn't want to think about

technology used past the interface to the network layer
the topology of the network
multiple addressing schemes

Theoretically we have four possible types of service which may be provided to the transport layer, the combinations are formed by crossing connection-oriented versus connection-less with reliable versus unreliable. In actual use the real contenders are reliable connection-oriented, and unreliable connectionless. Remember that a connection-less, unreliable subnet can support connection-oriented, reliable communication. It's all a matter of where the responsibility lies (e.g. in the network layer, or above it).

Connection-less, unreliable (datagram)

The argument here (made by Internet people) is that networks will always be unreliable, no matter what you do in the network layer, so transport layers will always have to have error and flow control. Why repeat this in the network layer? Hosts are cheap (capable of doing more complex stuff in transport layer), some types of data need speed over reliability, the public infrastructure should remain simple and basic.

Each router knows something about how to further the progress of each packet, and it makes its decsision by looking at the destination address contained in the packet. Since reliable delivery is guaranteed in the transport layer, the routers don't have to do anything special when a connection is torn down (they don't know about the connections).

The programmers interface to a datagram subnet is quite simple: send_packet() and receive_packet()

Connection-oriented, reliable (virtual circuit)

The PSTN is the model here, with customers not wanting to deal with complexity and wanting to rely on the carrier for a reliable channel. Some types of data (synchronous) are much easier to do with a reliable service. ATM is designed like this.

Each virtual circuit is uniquely identified by being given a number in each router. Each packet of data has the virtual circuit identified in it, so the routers know how to pass the packet along. The virtual circuits are released and the identifiers are freed when the circuit is torn down.

The programmers interface to a virtual circuit subnet is a bit more complex:

Design issue	Datagram subnet	Virtual Circuit subnet
Setup	None needed	Required
State	Not state info in subnet	Switches hold state which defines VCs
Routing	Packets are independent	Single route, pre-determined
Router failures	Only packets in failed router are lost	VC must be rebuilt
Congestion control	Difficult to do at network layer	Pre-allocation of buffers makes problem easy

Reliability

Can the net be as reliable as the phone system?

Phone system

phone switches are big mainframes, they know network topology, compute route, sets up connection for call (vc and time slots)
notice that:
no smarts in the network, all in the controller. the switches are very dumb
the controller is very expensive
1 billion DS0s in OC192 - the switch controller knows them all for the network it controls
scaling is: trunk speed * number of trunks (i.e. bad)
system can't adapt: only point of control is at connection setup
large setup cost means you have to have lengthy conversations to amortize the cost
not good for simple 1 packet exchanges (e.g. web, POS)
services must be constrained (e.g. only DS0 calls) since it is NP hard to mix different services (bin packing problem)
system is very fragile - call state is spread along the path in the switches; lose one you lose the whole call

Alternative is packet network

picture: cloud versus string, routers instead of switches
intelligence and work is distributed throughout the network
scaling is: trunk speed (networks can be bigger and cheaper)
architecturally agnostic: easy to incorporate strings as part of the cloud - not true in the reverse (hard to put IP clouds into ATM strings)
can adapt at any time scale consistent with the speed of light - data is self-describing, intelligence is distributed
no setup to amortize - supports single packet transactions
no constraint on services - mix and match different speeds of service
the best part: the bigger the network gets, the more reliable it is
Telcos do a a great marketing con job on "five nines" reliability. They need super-high component reliability to get their system to work at all
Graph
system rel versus network diameter (hops)
IP network - gradually rises from 0.9 with diameter
telco - decreases from 0.9 slow curve as the networks get bigger
This relationship forces the telcos to work very hard to get reliability - the switches must be fantastic
IP networks - routers aren't as important, the very structure gives reliability

Theory of random graphs
An arbitrarily connected graph, with a degree slightly above fully connected (just epsilon above) has the property that the graph is almost certainly connected. If you go above epsilon then there is almost no failure that will disconnect the graph. This was the original motivation for the net, even though the math wasn't known at the time.
Basic reason
Strings fail if any single part fails
Clouds fail only when everything fails

IP routers aren't particularly reliable, they are cheap. They could certainly be better. The market determines this; cost has been more important than reliability. Now there is demand for telco reliability as voice moves to IP, so IP routers will be improved. The fact that the net works at all, given the relative unreliability of the components, hints at the underlying mathematical stuctural advantage of clouds versus strings.