The TCP/IP protocol suite
was designed to let machines, connected by a variety of
network technologies (e.g.
Ethernet, telephone-wires,
radio, satellites, ATM,
etc.), communicate with each other. Today it is best known as the
protocol used for the Internet, the
global network that grew from the experiments of the U.S. Defense
Advanced Research Project Agency on the ARPANET.
One of the most important aspects of the IP suite is the abstraction from the physical networks it uses. In a way, IP provides a virtual ``physical'' network on top of a heterogenous structure of connected real physical networks.
The expression ``physical network'' comes from Comer's book [DC91]. Another commonly used expression for the physical network is Local Area Network (LAN). Both physical network and LAN seem to be used by most authors as a reference to the physical transmission technology as well as the Network Interface layer on top of it. The hardware implementation aspects will be avoided as much as possible, so the term LAN is used for clarity.
The goal in this chapter is to introduce a way of describing networks, to describe the TCP/IP protocol suite using this method and to introduce an implementation architecture view for future reference.
When discussing networks, different conceptual views can be used. One view is how the computers and networks are connected to one another and another view is a layered view of how the protocols operate on top of each other. The former will be called: `` network view'' and the latter: `` protocol stack view''. The protocol stack view is discussed first in the various incarnations it can appear in. After this, the relationship between the network view and the protocol stack view is shown.
A common way to describe networks is to use ``layers'' stacked on top of each other. Higher layers use the services of the layer(s) below it to hide the complexity of even lower layers. In Figure 2.1 an example stack is shown. Layer 3 uses the services provided by layer 2 to do its task, and layer 2 uses the services provided by layer 1 to do its tasks, which is to provide the services it offers to layer 3. So indirectly layer 3 is using layer 1, but this way layer 3 has no need to know how to use the services provided by layer 1.
The idea is that, should it exist, another layer with equivalent functionality could be used to provide layer 1's services to layer 2, without needing to modify layer 2 or 3 (see Figure 2.1).
Figure 2.1: Stacked model of protocol services
When talking about networks, the main function is to communicate between geographically separated machines, therefore a common trait of stacked models for networks is that the lowest layer provides the service of physically transmitting encoded information across a distance. The physically separated machines want to `understand' each other so they have to speak the same `language' on both ends at the same layer interface. The language is usually called a protocol, but for the example of a conversation, the human analogue is used (see Figure 2.2). There two `persons' communicate using speech. In this example, the layers appear in two distinct components or nodes called persons. The protocol layers are represented by protocol entities because they represent something that performs an operation. The nodes or persons consist of a number of these protocol entities stacked on top of each other. The vibrations in the air in Figure 2.2 need not be directly created by a mouth, but could have been transmitted using a telephone system, the combined system of air and telephone system is a new `physical communications layer' which is invisible to the brain interpreting English. In the figure, the layers can be seen as `virtually' communicating directly (the dashed arrows show this), even though they are using the lower layer's services to indirectly transport the language (represented by the black arrows).
Figure 2.2: Communication example between two talking nodes
In the above example, the term ``combined'' is used to say that two layers, one of which is the real ``transmitter'' (the telephone system), function as one. This idea can be generalized to a Service Provider and Service User view. In Figure 2.3 the idea of using a telephone system is shown as an added service and then hidden again as being invisible to the sound transmission service user. The combination of the air and the telephone system is the sound transmission service provider.
Figure 2.3: Service User and Service Provider view
Another way to describe networks is used when the interconnection of physical components and the geographically distributed nature of the network-parts is more important than the functional structure of protocols within one component (or one network). This will be called the `` Network View'' (see Figure 2.4). Several types of interconnection structures exist, but usually that internal structure is not important and a cloud is used to indicate that there is a network, but no further details are needed.
When the two views are combined, the network cloud from the network view usually
represents the lowest layer that provides the actual transmission
service. Each
component connected to the network can be shown with its internal layers
visible. As the level of abstraction is increased , the resulting
distributed protocol stack
view (as shown in Figure 2.3) can be seen in Figure 2.5.
Figure 2.5: From Network view to distributed protocol stack view
The two most important reference models for the description of computer network protocol layers are the Reference Model of Open Systems Interconnection, a 7 layer model created by the International Organization for Standardization ( OSI) and the TCP/IP Internet Layering Model, a 5 layer model, by the Internet Engineering Task Force ( IETF). With a bit of imagination, these models can be related to each other (see Figure 2.6).
Figure 2.6: OSI and IETF layer models for network protocols
The OSI model is used for general situations and for new network technologies. The TCP/IP protocol was developed before the OSI model even existed, therefore it has its own layer-model. However, the basic concept of layers is the same in both models. Since the focus in this thesis is on the TCP/IP protocol suite, the IETF model is best suited as an environment for describing the various functions of the protocols.
Each layer in the reference model provides a group of functions. Although different protocols are often completely incompatible, when mapped to the reference model the functionality of the layers is more or less the same. Below a summary of this functionality of the layers is given. In Figure 2.6 the relation between the two is shown. The dotted lines between the two models show the approximate relationship of the layers.
The physical layer describes the functions of the cables and connectors, voltages, wavelengths for encoding the bits, etc. used to connect the hosts and nodes in the network. An example of this would be coaxial cable (used in Ethernet) or unshielded twisted pair (UTP) category 5. The category 5 of the UTP cable is an example of what can be specified at the physical layer. Usually the physical layer is not described independently of the Network Interface layer.
In the TCP/IP model, the physical layer is never specified, a driver is assumed to exist that provides layer 2 functionality.
This layer takes the bits from higher layers and creates network specific frames which are then transmitted to another endpoint on the LAN. It provides an address space on the LAN and some addressing modes like point-to-point ( unicast), point-to-multipoint ( multicast) and broadcast.
When several LANs are linked together, an internet is created. The address spaces of the LANs are generally not compatible or overlapping. To be able to address each endpoint of the internet from every other endpoint on the same internet, a new unified address space must be defined for the entire internet. An address in this address space is called an ``Internet Address'' as opposed to a physical address off the Network Interface.
Not just the physical address is different between LANs, but also the frame size and frame headers. In a way the Internet Layer acts as a new network interface layer with a unified address space and a single frame format, in the TCP/IP protocol suite the frames are called IP-packets.
To connect different LANs together, an IP router is used to translate between them (see Figure 2.7 A).
The service the Internet Layer provides to higher layers is an unreliable connectionless datagram transmission service within a unified address space on top of a variety of LANs. If more reliability or `in order' delivery must be guaranteed, higher layers must provide that function.
The Transport layer provides two additional services on top of the Internet Layer; Port Numbers (additional address space) and transport protocols.
An IP level address that identifies the host uniquely to the ``outside world'' is provided per LAN interface card. To distinguish between different applications running on that host, additional address space, in the form of port numbers, is provided by the transport layer.
As already hinted at in the Internet Layer description, some applications may want a reliable service and in-order delivery. Other kinds of transport protocols with, for example, real-time (like) services or `in order' but not reliable services can be defined on this level.
Applications protocols are designed for a specific purpose, e.g. a protocol to transfer files (like the File Transfer Protocol in the TCP/IP protocol suite) or a protocol to access a machine from a remote location (Telnet, a remote terminal application). The entities using these protocols, the applications, are usually separated into two parts; a server-part and a client-part. Now the value of the additional addressing information, as supplied by the Transport Layer can be appreciated. Established application protocols have well known port numbers, so a client application can address its server counterpart directly.
In the IETF world, three main types of components can be identified. Hosts, routers and LANs. Of course, these components consist of ``real-world'' devices like computers, network interface cards, cables, routers, etc., but for the purpose of discussing how a network works, a schematic view of these components is sufficient.
In table 2.1, the three most important components are listed and described. Hosts and routers are connected to the LAN. When two different LANs are interconnected, the routing entities translate between them using the Internet Protocol. The devices connected to the network (i.e. the hosts and routers) are usually called nodes.
| LAN | A LAN is represented by a cloud, because the interconnection structure is not relevant to higher layers. Since the LAN is defined to be the physical layer and the network interface layer (see 2.7 B), part of the physical component of the hosts and routers is represented by the cloud. |
| IP router | An IP router is represented by a box with connections to at least two LANs. |
| IP host | A host is represented by a circle with connections to (at least) one LAN. Because a LAN cloud is used and not the physical network cable, part of the host exists in the LAN cloud. Thus the circle represents the LAN Service User. |
Figure 2.7: Relation between the network view and the distributed protocol stack view
In Figure 2.7 A, two LANs are shown connected to each other via an IP router. Hosts 1 and 2 are connected to LAN 1 and hosts 3 and 4 are connected to LAN 2. When layers 1 and 2 are integrated to be represented by `LAN' and layers above the IP layer are the `upper protocol layers' (see 2.7 B). The equivalent distributed protocol stack view of 2.7 A is shown in Figure 2.7 C. The IP layer entities of the hosts make use of the LAN service providers (LAN 1 and LAN 2), the upper protocol layers use the services of the IP layer for their operations. If the IP layer functions are regarded as a black box, the LAN services become invisible. The IP router only interacts with the LAN services, so if only the IP layer services are seen, the router has no external interactions and `disappears' from view. The dashed line in Figure 2.7 C shows the layers within the IP service provider.
The network view of the interpretation just described can be seen in Figure 2.7 D. An IP network with IP-hosts can be seen. All hosts are now connected to the same network. The IP router is now integrated as part the network.
A more abstract view is the Service User and Service Provider view. Applied to Figure 2.7 D, an IP service provider and an IP service user are shown. The point of interaction, also called a Service Access Point ( SAP), shown in the 2.7 E by a small oval ``hole'', represents the place and the means by which the service primitives of the Service Provider are approached and received. The SAP only indicates that there is a clearly defined interface, not how it is implemented or used. This view is very useful when the interaction to higher layers and not the messy details of the LAN technologies used are of interest.
In the previous section, the TCP/IP protocol suite was discussed as if the protocol layers were just black boxes, e.g. LAN, IP, UPL (Upper Protocol Layers). Even when shown as part of a node. In a TCP/IP protocol suite implementation it is necessary to open up the black boxes and look inside.
The protocol entities on a host as described previously are not
the actual protocol handling functions that do the dirty work. E.g. the
IP entity in an implementation of the TCP/IP protocol suite consists of
an IP protocol handling function, an ICMP protocol handling
function and an IGMP protocol handling function. But only the IP protocol handling
function provides the IP unreliable network service, ICMP and IGMP
handling functions make use of this service for their own communication.
In the IETF it is convention to place support protocols (e.g. ICMP, IGMP
and ARP) in the same layer as the protocol used to transport them.
In this section, each layer and the TCP/IP protocol handling functions within it are discussed to show their functionality in the TCP/IP suite of protocols.
Figure 2.8: TCP/IP protocol implementation model
In Figure 2.8 an overview is given of the main protocols used in the TCP/IP protocol suite and the relations between them. The lines between the boxes indicate which protocols are used ``on the way out'' to the physical network. E.g. FTP uses TCP which uses IP which uses the Network interface which uses the network's physical medium. The path used by protocols involved in multicasting are emphasized, because later the focus will be on those paths.
In this layer, the TCP/IP protocol defines the first step in the abstraction from the physical network. The Address Resolution Protocol (ARP) and its counterpart Reverse ARP (RARP) provide the conversion functions from IP to LAN address and visa versa respectively. ARP and RARP are usually placed on this level, because each LAN has its own method of addressing hosts connected to it. Reverse ARP is used to help workstations with no local storage to get their IP address. This is not very relevant to the problem in this thesis, so this will not be discussed further.
ARP on the other hand is going to be very important as a basis to understand the resolution of multicast addresses. ARP will be discussed in more detail in Section 2.4.
Another property of this layer is that it defines some capabilities or services for the Internet Layer to use: Frame size, addressing capabilities (unicast, multicast, broadcast), Quality of Service ( QoS) parameters, etc.
The Internet Layer provides a similar service as the Network Interface Layer, but this time defined independent of the capabilities of the lower layer. That means that additional protocols might be needed at this level (or below this level; ARP is placed in the NI layer, because it is very specific to the IP protocol layer as well as the type of LAN used).
The Internet Protocol provides a single address space of 32 bits to higher layers. In section 2.3, a detailed description is given of the IP address space. The IP address space is completely independent of the LAN, thanks to the local address resolution provided by ARP.
No guarantees are provided for the delivery of packets; duplication in the network, packet-loss, corruption and out of order delivery of packets may occur. Any form of reliability must be provided by higher layers.
An important function of this layer is the routing function of IP. Internetworks are typically connected in a maze like structure with routers as intermediate nodes and the physical networks between them (see also Figure 2.14 in Section 2.5.3). When there is more than one unique route to chose from, the best route must be chosen for the packets to reach the destination address.
Besides the Internet Protocol (IP), two additional support protocols are considered to be part of the Internet Protocol layer; Internet Control Message Protocol ( ICMP) and Internet Group Management Protocol ( IGMP). ICMP is used to exchange error messages and (traffic) control messages. IGMP is used to administrate subscriptions to multicast host groups and exchanging membership information with multicast routers. A more detailed description of IGMP will be given when IP multicasting is explained in Chapter 3.
Two Transport Protocols are defined in the TCP/IP protocol suite; Transmission Control Protocol ( TCP) and User Datagram Protocol ( UDP). TCP is the most complex protocol of the two, it offers a connection oriented, reliable FIFO (First In, First Out) data-stream transmission service. For unicast transmissions over a relatively short time period, TCP is ideal.
UDP offers only port numbers and an optional checksum in addition to IP's unreliable datagram service. This simplicity makes it necessary for applications using UDP services to perform their own checks and recovery solutions in case of errors (packet-loss, out of order delivery, etc.).
Transport protocols only transport data without any structure, application protocols typically add structure to the stream of data. Usually Application Protocols are integrated into real applications, causing the applications to be identified with the protocol. Examples of Application Protocols are the File Transfer Protocol (FTP), Telnet, Network File System (NFS), Service Message Block (SMB), etc.
IP has an address space of 32 bits, divided into classes. The usual notation of IP-addresses is in `dotted-decimal', 32 bits divided into 4 groups of 8 bits and written in decimal notation separated by dots (e.g. 130.89.181.91). The classes are shown in the table 2.2.
| Class | lower bound | to | upper bound | type | |
| A | 0.0.0.0 | to | 127.255.255.255 | Unicast | |
| B | 128.0.0.0 | to | 191.255.255.255 | Unicast | |
| C | 192.0.0.0 | to | 223.255.255.255 | Unicast | |
| D | 224.0.0.0 | to | 239.255.255.255 | Multicast | |
| E | 240.0.0.0 | to | 247.255.255.255 | Reserved |
Figure 2.9: IP's 32 bit address space Class allocation
IP address spaces are allocated per network ID, the class determines the size
of the address-space per allocated network. See Figure 2.9. Net-id's
are allocated to organizations, so usually the networks of one net-id are
behind a single IP router. This makes routing packets very easy. Depending on
the size of the address space needed, a Class A, B or C address is allocated.
Since the entire Internet has a single address space, there must be a single
organization for keeping track of the assigned addresses. This organization is
the IANA, which has distributed the IP address space in a
hierarchical way.
Therefore regional and local registration authorities
handle the load of assigning and re-assigning IP numbers (host-IDs and
net-IDs).
At a higher level, different connections/services on the same machine are
addressed by port-numbers (at the TCP/UDP level).
On the Internet, `Well Known
Numbers' are defined for certain services, these are managed by the IANA. The
Internet Standard 2 [IANA94] holds an overview
of
standardized IP-addresses and port-numbers.
Several levels of broadcast are supported, a few examples are given in Table 2.3.
| IP address | Description |
| 255.255.255.255 | Limited Broadcast, only on the local subnet |
| netid.255.255.255 | Class A net-directed broadcast |
| netid.netid.255.255 | Class B net-directed broadcast |
| netid.netid.netid.255 | Class C net-directed broadcast |
Two IP hosts on the same LAN communicating with each other must know each other's LAN address as well. If an algorithmic relation between the IP address and the LAN address of a host does not exist, another method must be found to determine the LAN address of the other party. The Address Resolution Protocol (ARP) was developed to do just that. ARP is a low-level protocol that hides the LAN address space for higher layers. The following quotation describes the layer-context ARP should be placed in: ``We consider it as part of the physical network system, and not as part of the internet protocols.'' [DC91]. Some might argue that ARP should be placed at the same level as IP, because it uses the LAN service to transport its packets. Both views have their merits, but in this thesis the ARP entity is shown as part of the Network Interface layer.
Ethernet is an example of a situation where the physical address is not algorithmically related to the IP address. The Ethernet physical address is assigned to the interface card in the factory and the IP number belonging to the interface is assigned by the network administrator where the card is used.
First the problem of address resolution within a LAN is shown for both a
broadcast LAN (like Ethernet) and a non-broadcast LAN. After that, a
situation is shown where two LANs are connected via an IP router. In the
figures, the ARP entity is shown as a ``layer'' on top of the LAN and
below the IP layer.
Figure 2.10: Time-sequence example of ARP on a broadcast LAN
Ethernet is a good example of a broadcast LAN, Figure 2.10 shows a time-sequence diagram of ARP on such a LAN.
Consider the situation where a machine X has to send a data-packet to
machine Y, but it only knows the IP address of machine Y
( 
), its own IP address ( 
) and Ethernet
address ( 
). X needs Y's Ethernet address
( 
) to transmit directly to Y. In order to find
, the IP layer will ask the the ARP entity on machine X
to resolve to an Ethernet address. The ARP entity sends
out an ARP request containing and the pair
( , ) to all machines using an
Ethernet broadcast method ( 
). All machines on the
network receive the broadcast ( 
), but only the
machine with as IP address recognizes the address as
its own and responds ( 
) with the pair
( , ) directly to .
After receiving the address-pair for machine Y ( 
), the
IP entity on machine X can now send directly to the IP entity on machine
Y using ( 
).
For reasons of efficiency, the ARP on each host uses a cache of the (LAN address,IP address) pairs. For more complete description of ARP, see [DC91]. The above example assumes that no entries exist in the ARP cache.
Ethernet is just one example of a LAN technology, with other kinds of LANs other implementations of ARP must be created to fit the particular network properties. As will be shown with ATM, this is not always trivial when a broadcast option is not available.
Figure 2.11: Time-sequence example of ARP on a non-broadcast LAN
Later ATM will be used as Network Interface layer. Currently ATM does not provide a broadcast option, it can therefore be used as an example for a LAN technology without broadcast option. When a broadcast option is not available, how can an IP address be resolved to a LAN address?
The solution used for Classical IP and ARP over ATM [ML94] is a
special ATMARP server
and a well known way to connect to it. The ATMARP server responds to every
ATMARP request on a Logical IP Subnet ( LIS) with the correct IP/ATM-address
combination or a negative response (to indicate that it has received the
request, but cannot resolve the address).
In Figure 2.11, the difference with ARP in a broadcast
network is clear: When the IP entity on host X wants to know the LAN
address of host Y, the ARP entity on host X contacts the ARP
server ( 
), assuming the ARP server knows the
IP/LAN address combination for host Y, the ARP server responds with host
Y's IP and LAN address pair ( 
). With the LAN
address of Y, host X can now send directly to Y
( 
). Although less `arrows' can be seen in
Figure 2.11 than in Figure 2.10, remember that a
broadcast has the same ``cost'' on an Ethernet as a unicast.
As can be seen, an IP implementation on top of ATM must rely on a single entity on the network to resolve addresses. If the ARP server fails, the system fails, unless a backup system has been defined. ARP on Ethernet, on the other hand, only requires each machine to know its own IP address and LAN address. When a single machine breaks down, only that machine is affected (as far as address resolution is concerned).
Figure 2.12: Time-sequence example of ARP with a router and two LANs
In Figure 2.12 two Ethernet LANs are shown, connected via an IP
router (R). Host X wants to transmit a packet to host Y (and X only
knows Y's IP address).
Each host has a routing table, which tells the IP entity whether an address is on the local network or behind a router. This is possible, because each IP address consists of a network ID and a host ID part. If the network ID of the destination IP address matches the local network's ID, the IP address is directly reachable.
If the address of Y is behind the router, host X sends the packet
directly to the router using its known LAN address
( ). The router's IP entity tries to resolve Y's
IP address on Ethernet 2. If the router's ARP entity for Ethernet 2
does not have Y's (IP address, LAN address) pair in the cache and it is
not listed in the routing table as being reachable through another
router, it must resolve the IP address of Y using the ARP service. The
ARP entity on the router does an ARP request on Ethernet 2 to resolve
Y's LAN address (this situation is shown in Figure 2.12).
Resolving Y's IP address to a LAN address on Ethernet 2 is the same
procedure as shown in Figure 2.10. After Y's IP address is
resolved (labels 
), the router sends the
packet it received from host X to host Y using Y's LAN address
( 
).
In the thesis, the focus will be limited to the set of protocol entities relevant for the implementation of IP multicasting on top of ATM. With an implementation, the location of the functionality within the layers is important. Although already described in Section 2.2, the protocol entities are shown here in the context of the physical components they will be implemented on. A basic understanding of how the components are connected together is also useful in understanding how the Internet Protocol functions on a set of interconnected LANs. In this context, the term nodes can be used to distinguish the IP-routers (intermediate nodes) and IP-hosts (end nodes) from the interconnecting network.
In this and other documents about network protocols, the terms node, host and router are used often. The terms have a special meaning and a relation to each other.
A node is a physical entity connected to the network, which implements the protocol specified with it (e.g. ``IP node'' when IP is implemented or ``ATM node'' when ATM is implemented on that node). If the protocol is not specified, it should be clear from the context.
A router (or a switch, in the case of ATM) is a node that performs some forwarding function on the data carriers. E.g. IP routers forwards IP packets to the next hop in the path to their destination address.
A host is a node that can only operate as end-point of a communication at this protocol level and never performs routing functions at that protocol level.
Protocol entities are groups of functions that reside in a node. Peer
protocol entities in different nodes exchange information, using a
protocol across the network. Together the peer protocol entities form a protocol layer. As explained in
Section 2.2 and shown in Figure 2.8, the IETF
groups different protocol entities in a single layer. Another way to
represent that is to use a user 'plane' and a
control 'plane'. The protocols (UDP, TCP, IP) form the user plane, they
simply transport data for their Service Users. IGMP, ICMP, ARP and RARP
are support protocols that make it possible for the user plane protocols to function properly. Therefore, they are
part of the control plane.
The protocol entities are represented by boxes (within) the layered representation (see Figure 2.13). Not all protocol entities shown in Figure 2.13 have to be present in an implementation of the TCP/IP protocol suite on a node. E.g. the IGMP protocol entity is not needed if IP multicasting functionality is not used. This also applies to the Network Interface layer, e.g. it may be possible to have a Network Interface layer implementation without broadcast support.
In the rest of this thesis, the focus will be mostly on IP multicasting and the integration with ATM and Classical IP and ARP over ATM. The protocol entities most important in that context are: UDP, IGMP, IP and the entire Network Interface layer.
Figure 2.13: Architectural view of the protocol functions in the IP-nodes
Note that in Figure 2.13 applications may sometimes access IP layer functions directly. Two network management applications, ping and traceroute, use ICMP and IP respectively. Ping is used to check the reachability and operational status of another host and traceroute uses some special features of the IP-packet header values to find out which route is taken to reach another host. It is assumed that IP multicasting applications initiate the joining and leaving of host groups by talking directly to the IGMP functionality.
The IP router has no need for transport or application protocols when it
only needs to transfer IP packets from one LAN to another. But an IP
host with two or more connections (to different LANs) can also function
as a router. The model of the IP router in Figure 2.13 shows the
minimum number of layers for router functionality.
Of course, the same exceptions apply as in the IP host. Multicasting was added later, so a router may not have IGMP and multicast routing capabilities. The network interface layer can be described for both types of nodes equally. The network interface layer may not have support for multicasting and/or broadcasting.
Figure 2.14: IP network structure
An internet can be seen as a set of LANs connected to each other
using IP-routers. Each network can be based on one of a variety of networking
technologies. When two computers (IP-hosts) on different networks communicate,
their traffic is routed through the IP-routers across the intermediate
networks.
The interconnected structure of these networks is such that it is usually possible to choose from several routes between the two hosts. There are some options in the internet protocol to help select the best route. These options specify certain qualities of the network, like high throughput or high reliability. The routers may or may not have the ability to use these options. When a network or IP-router in one route to the destination host is not operational, an intermediate router can chose another route to reach the same destination IP-host.
In Figure 2.14 (a part of) an internet is shown. The IP hosts and IP routers correspond to the two architectural views shown in Figure 2.13. The routers connect the LAN clouds. Two connected IP hosts are shown (A and B), they are connected to LANs (A to I, B to X). When a packet is routed from A to B, the routers can choose from several possible paths. Route 1 in Figure 2.14 is: A--1--3--7--B. If router 1 should break down, route 2 can be chosen as an alternative: A--4--5--6--B. Only if routers 1 and 4 break down at the same time, host A is completely cut off from the network.
In this chapter a way of describing networks has been presented and that method will be used in the rest of this thesis. Whether the protocol stack view or the network view is used, depends on what aspect of a network must be described. For a complete qualitative understanding, the combination of the two may be used to describe the inter-operation of the elements of a communication protocol. Additionally, time-sequence diagrams (as used in the ARP examples) can be used to describe the temporal behaviour of a protocol.
As example and also as introduction, the TCP/IP protocol suite has been discussed in an architectural model. In the next chapter, multicasting will be added to this model and in chapters 4 and 5, the network interface layer is replaced with an ATM based system.
