Network (JANET)
3.4 A Technical Digression
In a message switching network, the data to be transferred from the source, in the form of a complete message, is prefixed with an address which defines the destination, and the message-plus-address is passed from the source to the net- work. The address is used to route the complete message across the network, which does not retain any information about the route the message takes. This is the model that is used for telegraph traffic, and is now used for text messages for mobile phones.
In a packet switching network, data is transferred across the network in small packets. The address of the destination is appended to each packet as it is trans- mitted from the source. The switch(es) in the network use this address to deter- mine a route for the packet of data to its destination, and this is done afresh for every packet which is submitted for transmission. In the majority of cases, the data to be transmitted will not fit in to a single packet, and the total transmis- sion takes the form of several packets, which may well take differing routes across the network before arriving at their destination. It is this form of switch- ing which forms the basis of most current networks. A packet switching net- work can operate in a “connectionless” mode, in which the route for each packet is determined afresh. A packet switching network can also operate in a “connec- tion-oriented” mode; when a user wishes to transfer data, the network first cre- ates a connection, known as a “virtual circuit”, between the source and the destination, and then all subsequent packets of traffic flow along this virtual circuit. Paradoxically, nearly all speech traffic is now carried on connectionless packet switching networks, but the telephone user sees a connection oriented service.
The benefits of packet switching are in scalability and resilience against failure.
As a network grows, and more locations are added, new sites can simply be con- nected to their nearest switch. If a switch becomes overloaded, it is a relatively simple matter to add another switch, or to replace a switch by a more powerful one. If the underlying physical network becomes overloaded, extra links can be added. Because of the way in which switches cooperate to route packets, there is very little to be done by way of administration. If a switch, or a network connec- tion, fails the remaining switches and connections will continue to operate; if each locations is connected to more than one switch, and if each switch is con- nected to several other switches, it is perfectly possible for the failure of a single switch or connection to leave the entire network still fully connected.
3.4.2 Protocols and Network Architecture
When designing a network it is essential to break down the software which is needed to allow information to be transmitted between programs running in separate locations into manageable units. This breakdown takes two forms, into interfaces and protocols. The software at each location is treated conceptually as a number of layers, each of which offers services to the layer “above” it, imple- menting these services using the services offered to it by the layer “below” it.
Breaking the software down in this way allows the “higher” layers to be shielded from the details of how the services it provides are implemented by the “lower”
layers. The highest layer deals directly with users’ applications, while the lowest layer, sometimes called the “physical” layer, deals directly with the hardware forming the transmission system. The detailed description of the ways in which a higher layer can request services from a lower layer, and of the lower layers responses to these requests, define the “interface” between a pair of adjacent layers. The complete set of layers is frequently referred to as a “stack”, not to be confused with the stack which forms part of the internal register set of many computers.
As well as this flow of data up and down between the separate layers at each loca- tion, there is a conceptual flow of information between layers at the same level at the two ends of the data link. Again there is a detailed description of what types of exchange can take place between corresponding layers at the two ends of the link, and this set of conventions is referred to as the “protocol” for that layer. In fact, there is no direct exchange of information between the corre- sponding layers. Rather, each layer passes information down, via the appropri- ate interfaces into the successive layers below it at one end until the information reaches the physical layer, where it is transferred across the data link, then up through the interfaces, finally reaching the corresponding layer at the far end.
At first sight this looks to be a very cumbersome way of proceeding. It has one huge advantage. Provided that the interfaces between layers and the protocols across layers are preserved, it is possible to replace any implementation of a layer with a completely different one, for example replacing a link running over a copper cable with one running over an optical fibre, without changing any other part of the implementation.
In practice, it is normal to separate the protocol stack, with the lower layers implemented on a small front end computer. At the same time, these lower lay- ers, but only the lower layers, will be implemented on the computers that act as switches within the network.
3.4.3 Network Reliability
All equipment is liable to fail. The reliability of a unit can be measured in several ways. One way looks at how long the unit runs before it fails, and how long it then takes to bring it back into service. Both of these are essentially statistical measures, and are respectively known as the “mean time between failures”
(MTBF) and the “mean time to repair” (MTTR). The quantity 1 – (MTTR/MTBF)
gives a measure of the fraction of time for which the unit is usable. It is often called the availability, and expressed as a percentage. So a unit which on average runs for 1000 hours between failures, and is then repaired in 3 hours would have an availability of 99.7%.
It is often possible to design a system in such a way that unreliable units can be combined to give improved overall availability. For example, we might have a situation in which the user can make use of either one of two units, each with an
MTBF of 100 hours, an MTTR of 1 hour, and an availability of 99%. There is a 1%
chance that when it is being used this first unit will fail. We arrange that if the unit that is being used fails, the failure is detected by the system, and the work is automatically transferred to the other unit. This second unit has a 99% proba- bility that it is working, and the overall probability of both units having failed is 1% of 1%, or 1 in 10,000.
It is of course also possible to design a system in such a way that reliable units are combined to give reduced overall availability. This will arise if the user requires both units to be working at the same time. In the case of the two units above, each has a 99% probability of working, but if they must both be working the overall availability falls to 98%.
A large network contains switches used to route traffic, and lines to carry the traffic between switches. We can connect each site (or switch) to more than one switch; this will allow the site (or switch) to continue working if one of the lines, or one of the switches, fails. There are of course costs. The obvious one is the cost of the extra lines and switches. Less obvious is the cost of rerouting traffic in the event of a failure, since this requires software that is capable of detecting the failure, and then automatically carrying out the rerouting. Connectionless protocols have this property by default, as each packet is routed afresh.
It is important when discussing system reliability to realize that the perception of users may be very different from that of those running the system. Users are, quite rightly, concerned with their own work. If the part(s) of the system that they are using keeps breaking down they will view it as unreliable. If the break- downs that occur affect only a small subset of users, those running the system, who think in terms of overall reliability, may well assert that the system is reli- able. From their limited perspectives, both are right.