This chapter aims to provide an introduction to the B-ISDN ATM and Internet protocols in the context of the basic protocol layering principles. It discusses internetworking between the B-ISDN and Internet networks. It also provides the basic knowledge to help readers better understand the following chapters on satellite internetworking with terrestrial networks, ATM over satellite and Internet over satellite. The evolution of both the B-ISDN ATM and Internet protocols are also discussed. When you have completed this chapter, you should be able to:
ATM is a fast packet-oriented transfer mode based on asynchronous time division multiplexing and it uses fixed-length (53 bytes) cells, each of which consists of an information field (48 bytes) and a header (5 bytes), as shown in Figure 3.1. The header is used to identify cells belonging to the same virtual channel and thus used in appropriate switching functions. Cell sequence integrity is preserved per virtual channel. The ATM is a result of the standardisation processes of the B-ISDN by the ITU-T.
Figure 3.1 ATM cell
Figure 3.2 Functions of the ATM protocol stack
The B-ISDN protocol reference model consists of three planes: user plane for transporting user information; control plane responsible for call control, connection control functions and signalling information; and management plane for layer management and plane management functions. The relationship between OSI layers and B-ISDN ATM protocol model layers can be described as the following, as illustrated in Figure 3.2:
The number of 53 bytes is not only an unusual number (not even an even number), but also a relatively small number for a network layer packet. There are a few trade-offs involved here, including packetisation delay, packet overhead and functionality, queuing delay in switch buffers, and political compromise.
Standard digital (PCM) voice uses a constant stream of bits at 64 kbit/s. It was one of the most imported services considered at the time for evolution towards to the B-ISDN. The voice is sampled 8000 per second at 4 kHz frequency bandwidth. Each sample is coded using eight bits – 8000 eight-bit samples/s results in a data rate of 64 kbit/s.
To fill a cell of 40 bytes of payload, the first voice sample sits around in the partially filled cell for 40 sample times and then the cell is sent into the network. That first voice sample is therefore 5 ms old before the cell even gets sent. This is called ‘packetisation delay’ and it is very important for real-time traffic such as voice.
In satellite communications, the delay is in the order of 250 ms in each direction. Such a long delay may cause someone to experience problems in telephony communications, because the delay can interfere with normal conversational interactions. Even lower delays in the order of 10–100 ms may cause problems due to echo in a voice network and analogue-to-digital conversion. To keep delay to a minimum, small cells are desirable.
However, there must be some overhead on the cell for the protocol switching functions so that the cell can be forwarded to the right place and processed correctly. Using a five-byte header, the percentage of the bandwidth that is used by the header can be very high. Optical transmission technology was the main consideration at the time. Wireless transmission now becomes more and more important for better mobility today. If the cell is too small it will loss efficiency. The key is to try to balance the delay characteristics with the efficiency. A five-byte header with a 48-byte payload results in less than 10% overhead, as shown in Figure 3.3.
Figure 3.3 Trade-off between delay and cell payload efficiency
Data services are less sensitive to delay, but more sensitive to loss. Delay is important to real time services and network management and control. Delay variation is also important. Delay variation is that different cells can experience different delays when they traverse the network.
For example, consider a high-speed link with a 100-byte message to be transmitted. Further assume that this link is shared with 100 other streams of data. The best case for queuing delay is that there is no other data to send when the message arrives. Just send it, and effectively the queuing is almost zero. The worst case would be to wait for each of the other 100 streams to send their 100-byte message first.
Consider this worst case. If the payload is very small, one has to send so many cells that efficiency is quite poor, as shown in Figure 3.4. If the cell is too large, the amount of time the cell has have to wait for all these other cells to go, increases.
Figure 3.4 Delay due to packetisation and queuing
When the cells become bigger and bigger, the time to wait for a cell before one can get access to the link goes up, and it essentially goes up linearly. It can be seen that small cell sizes can have a large delay due to a large number of cells need to process, and delay will also become large if the payload becomes large as it takes time to process large cell. Therefore, delay and delay variation are more uncertain in packet networks than in circuit networks.
Naturally, the important question of picking a cell size involves extensive analysis of technical concerns. In Europe, in fact, one of the major concerns was the packetisation delay because Europe consists of many small countries hence distance is small within each of the telephone networks. Thus, they do not need to deploy very much echo cancellation technology.
In North America, the distance within the countries is large, causing telephone companies to deploy echo cancellation technology. Thus, North Americans generally favoured a large cell with 64 octets of payload and a five-octet header, while Europeans generally favoured a smaller cell of 32 octets of payload and a four-octet header. One of the big differences was the concern about how to handle voice, since telephony services generate most of the revenue at the time and major traffic in the telecommunication networks.
A political compromise was made, resulting in 48 octets for the payload with intensive averaging between 64 and 32 octets. Of course, this turned out to be too large to avoid the use of echo cancellers while failing to preserve the efficiency of 64 octets. Very soon, the Internet traffic had a very rapid increase and exceeds telephony traffic; the size of the ATM cell is not important any more, however, the principles used to achieve optimisation and compromise to be acceptable at a global scale still are.
Given that the Internet is now supporting all types of multimedia services and applications, the new generation of the networks are focusing on more efficient network protocols and architecture for efficient support of IP networks and applications as well as its future development.
The main functions of the ATM layer is to transport the cells between two terminals across the network. It is the core of the ATM protocol stack. There are two different forms of header format for an ATM cell: one for the user network interface (UNI) between user terminal equipment and network node inter connections and the other for the network node interface (NNI), as illustrated in Figure 3.5.
Figure 3.5 The ATM cell header format at the UNI and NNI
The generic flow control (GFC) field occupies the first four bits in the header. It is only defined on the UNI between users and networks. It is not used in the NNI, which is the interface between switches. The GFC field can be used for flow control or for building a multiple access so that the network can control ATM cell flows from user terminals into the network.
The important fields for switching in the header are the virtual path identifier (VPI) and virtual channel identifier (VCI) fields. A number of virtual connections through an ATM switch are shown in Figure 3.6. Within the switch, there has to be a connection table (or routing table) and that connection table associates a VPI/VCI and port number with another port number and another VPI/VCI.
Figure 3.6 Connection/routing table in ATM switch
As an example shown in Figure 3.6, when a cell comes into the switch, the switch looks up the value of the VPI/VCI from the header. Assume that the incoming VPI/VCI is 0/37. The cell came in on port 1, the switch looks in the port 1 entries and discovers that this cell has to go to port 3. When being sent out on port 3, according to the connection/routing table, the VPI/VCI value is changed to 0/76, but the information content remains the same. The change of port number is at the physical layer and the change of VPI/VCI is at the link layer.
The VPI/VCI values change for two reasons. First, if the values were unique, there would only be about 17 million different values for use as only eight bits are used for VPI/VCI. As networks get very large, 17 million connections will not be enough for an entire network. Second, it is impossible to guarantee that in each newly established connection has a unique value in the world.
It is interesting to note that both of these considerations are becoming quite important in the Internet, where a limited number of TCP/IP addresses are available where 32 bits are used for IPv4 (Internet Protocol version 4). If the address space were made large enough to serve as universal addresses, the overhead in comparison to the payload in the cell would become larger that 128 bits are used for IPv6 (Internet Protocol version 6) – the new generation of IP.
Consequently, the VPI/VCI value is only meaningful in the context of the given interface/port number. In fact, in this example ‘37’ is used on in both interfaces/port numbers, however, but there is no ambiguity because they are considered in the context of different physical interfaces. There is a separate entry for 37 for port 2, which of course goes to a different destination.
So the combination of the VPI/VCI values allows the network to associate a given cell with a given connection, and therefore it can be routed to the right destination. The idea to have two values to identify a channel within the physical layer is illustrated in Figure 3.7. A virtual path is a bundle of virtual channels. The VPI is eight bits, providing up to 256 different bundles. Of course, the individual virtual channels have unique VCI values within each VPI, but the VCI values may be reused in different virtual paths.
Figure 3.7 Concept of VP and VC in the physical layer
ATM allows two different ways of getting connections to an ATM network, as shown in Figures 3.8 and 3.9. These two figures show how the network can support a ‘bundle’ of connections and how to switch the ‘bundle’ of connections as well as individual connection within it.
Figure 3.8 Example of VP switching
Figure 3.9 Example of VC and VP switching
By default the one-bit cell loss priority (CLP) field is set as 0 indicating high priority and 1 indicating low priority. If network congestion occurs, cells with this bit set to 1 should be discarded before cells that have the bit set to 0. Consider the reasons why cells may be marked as expendable. First, this may be set by the terminal. This may be desirable, for example, in a wide area network (WAN) with a price drop for these low-priority cells. This could also be used to set a kind of priority for different types of traffic when one were aware to over use a committed service level. The ATM network can also set this bit for traffic management purposes in the traffic contract. These bits are used to identify the network control and manage traffic for the control and management plane and data traffic for the user plane.
The payload type (PT) identifier has three bits in it. The first bit is used to distinguish data cells from cells of operation, administration and maintenance (OMA). The second bit is called the congestion experience bit. This bit is set if a cell passes through a point in the network that is experiencing congestion. The third bit is carried transparently by the network. Currently, its only defined use is in one of the ATM adaptation layer type 5 (AAL5) for carrying IP packets.
The last eight-bit header error check (HEC) field is needed because if a cell is going through a network and the VPI/VCI values have errors, it will be delivered to the wrong place. As a security issue, it was deemed useful to put some error checking on the header. Of course, the HEC is also used, depending on the physical medium, for example in synchronous digital hierachy (SDH), to delineate the cell boundaries.
HEC actually has two modes. One is a detection mode where if there is an error with the cyclic redundant check (CRC) calculation, the cell is discarded. The other mode allows the correction of one-bit errors. Whether one or the other mode is used depends on the actual medium in use. If fibre optics are used, one-bit error correction may make a lot of sense because typically the errors are isolated random errors. It may not be the right thing to do if errors tend to come in bursts in the medium, such as copper and wireless link. When one-bit error correction is used, it increases the risk of a multiple-bit error being interpreted as a single-bit error, mistakenly ‘corrected’. So the error detection capabilities drop when the correction mode is used.
Notice that the HEC is recalculated link by link because it covers the VPI and VCI values which change as ATM cells are transported through the network.
AAL is divided into two sublayers, as shown in Figure 3.2: segmentation and reassembly (SAR) and convergence sublayers (CS).
The role of the AAL is to define how to put the information of different types of services into the ATM cell payload. The services and applications are different and therefore require different types of AAL. It is important to know what kinds of services are required. Figure 3.10 illustrates the results of the ITU-T's efforts for defining service classes.
Figure 3.10 Service classes and their attributes
Figure 3.11 shows AAL type 1 (AAL1) for Class A, illustrating the use of the 48-byte payload. One byte of the payload must be used for AAL1 protocol, and another byte is optional.
Figure 3.11 AAL 1 packet format for Class A
Convergence sublayer indication (CSI) consists of one bit. It indicates the existence of an eight-bit pointer if CSI 1 and no existence if CSI
0. Sequence number (SN) can be used for cell loss detection and providing time stamps using adaptive clock methods. Sequence number protection (SNP) protects the SN by using CRC.
There are a number of functions here, including detecting lost cells and providing time stamps to support a common clock between the two end systems. It is also possible that this header could be used to identify byte boundaries by emulating a connection and identifying subchannels within the connection.
The primary objective for the adaptive clock method is to obtain clock agreement, making sure to be able to play out the original information stream. For example, in a 64 kbit/s voice service, the transmitter collects voice samples, fills up cells and sends those cells into the network at about once every 5.875 ms (transmits 47 octets at a speed of one octet every 125 µs). The receiver is shown in Figure 3.12. The receiver plays out the original bit stream at 64 kbit/s. This is where we see the impact of variation and delay.
Figure 3.12 Illustration of the adaptive clock method
Using the adaptive clock method, the receiver establishes a buffer based on the characteristics of the connection at 64 kbits. It establishes a watermark and then collects some cells up to about the watermark. Then the receiver unwrap the bits from the payload and plays them out as a stream of bits at 64 kbit/s.
If the play out is too fast, the buffer becomes empty because the cells will be arriving a little bit too slow compared to rate of emptying them. Thus, we will have a buffer starvation problem. If it is a little bit too fast, the buffer will start to fill, and eventually it will overrun the buffer. Then cells get lost. The solution is that the receiver observes the fill of the buffer relative to the watermark. If it starts to get empty, it slows the (output) clock down because the clock is going a little fast. If it starts to get too full, it speeds the (output) clock up. This way, the receiver's output clock rate stays centred around the transmitter's clock.
The size of the buffer must be a function of how variable the arrival rate is for the cells. If the cells arrive in bursts, a large buffer is required. The larger the burst is the larger the buffer size is required. There is a lot of delay variation when the cells traverse the network. Bigger buffers also cause a larger delay. Cell delay variation (CDV) is a very important factor in QoS, thus it is an important parameter in traffic management.
Another important factor is the effect of losing a cell. Part of the protocol is a sequence number, which is not meant to maintain the sequence of the cells, but to detect loss. If a cell is lost, the receiver should detect the loss and essentially put in a substitute cell. Otherwise, the clock rate becomes unstable.
It is interesting to note that with this kind of scheme, one can maintain a circuit-like connection of virtually any speed over ATM. As it is so important in supporting telephony service, AAL 1 is called a telephony circuit emulator.
AAL type 2 (AAL2) is being defined for Class B, but it is not fully developed. This AAL is important, because it will allow ATM to support the burst nature of traffic to be exploited for packet voice, packet video and so on. It also allows half-full cells to be transmitted. Figure 3.13 illustrates the functions and frame format of the AAL2. The SN is the same as used in AAL1, IT indicates the information type, LI indicates the length indicator of the information in the payload and the CRC for error detection.
Figure 3.13 AAL 2 packet format for Class B
In AAL type 3/4 (AAL3/4), the protocol puts a header before and a trail after the original data, then the information is chopped into 44-byte chunks. The cell payloads include two bytes of header and two bytes of trailer, so this whole construct is exactly 48 bytes. Figure 3.14 illustrates the functions and frame format of the AAL3/4. AAL3/4 is a combination original specification of AAL 3 and AAL 4.
Figure 3.14 AAL 3/4 packet format for Classes C and D
The header functions include the common part identifier (CPI) field of one byte, which identifies the type of traffic and certain values that are to be implemented in the other fields of the headers and trailers. The beginning tag (Btag) field of one byte is used to identify all the data associated with this session. The buffer allocation size (BAsize) of two bytes defines the size of the buffer in the receiver for the data. The alignment field (AL) is filler to 32-bit align the trailer. The end tag (Etag) is used with the Btag in the header to correlate all traffic associated with the payload. The length field specifies the length of the payload in bytes.
Note that there is a CRC check on each cell to check for bit errors. There is also an MID (message ID). The MID allows the multiplexing and interleaving of large number of different message onto a single virtual channel. This is useful when the cost of a connection is very expensive since it helps to guarantee high utilisation of that connection. There also fields for segment type (ST) and sequence number (SN).
The other data-oriented adaptation layer is AAL type 5 (AAL5). It was designed particularly for carrying the Internet IP packet using the full 48 bytes of the ATM payload. Here, the CRC is appended at the end and the padding is such that this whole construct is exactly an integral number of 48-byte chunks. This fits exactly into an integral number of cells, so the construct is broken up into 48-byte chunks and put into cells. Figure 3.15 illustrates the functions and frame format of the AAL5.
Figure 3.15 AAL 5 format for Internet protocol
To determine when to reassemble and when to stop reassembling, remember the third bit for PT in the ATM header. This bit is zero except for the last cell in the packet (when it is one).
A receiver reassembles the cells by looking at the and, for a given
, reassembles them into the larger packet. This means that a single
may support only one stream of packet at a time. Multiple conversations may not be interleaved on a given connection. This is attractive when connections are cheap.
The first requirement for interpretability of the terminal equipment with the ATM network and network nodes with network nodes within the network is to transmit information successfully at the physical level over physical media including fibre, twisted pairs, coaxial cable, terrestrial wireless and satellite links.
As shown in Figure 3.2 the physical layer (PL) is divided into two sublayers: the physical medium (PM) and transmission convergence (TC) sublayers.
The PM sublayer contains only the PM-dependent functions (such as bit encoding, the characteristics of connectors, the property of the transmission media, etc.). It provides bit transmission capability including bit alignment, performs line coding and also conversions of electrical, optical and radio signals if necessary. Optical fibre has been chosen originally as the physical medium for the ATM; coaxial, twisted pair cables and radio wireless links including satellite can also be used. It includes bit-timing functions such as the generation and reception of waveforms suitable for the medium and also insertion and extraction of bit-timing information.
In an ATM network, a terminal needs to have a cell to send data into the network. To keep the network receiving ATM cells correctly, the terminal still has to send an ‘empty’ cell into the network if there is nothing to send, because the ATM also makes use of the features of the HEC field and fixed size of the ATM cells for framing. One of the functions of the TC sublayer is to insert empty cells for transmission and remove empty cells when they get to the destination in order to keep the cell streams constant.
Because of the different kinds of details in the coupling between the fibre and other physical media, the TC sublayer differs, depending on the physical layer transmission of the ATM cells. The TC sublayer mainly has five functions, as shown in Figure 3.2.
As the ATM is a protocol defining an asynchronous mode, the ATM cells have to be transmitted over network technologies. In the ITU-T I-series standards, a target solution and evolutional solution are defined for public ATM networks at transmission speeds of 155.520 Mbit/s or higher.
Figure 3.16 shows the target solution recommended by the ITU-T I-series standards. It suggested that a transmission scheme at the physical layer should transmit ATM cells directly, but only provides 26/27 ATM cells to the ATM layer for user data so that the 1/27 cell can be used for supporting operation, management and administration (OMA) functions. The choice of the 1/27 cell used for OMA is to make the ATM cell transmission scheme compatible with evolutional approaches using the SDH standards for ATM cell transmissions. The physical layer transmission is 155.520 Mbit/s, which is the same as the SDH standards physical layer transmission speed. The ATM layer is 149.760 Mbit/s, which is the same as the SDH payload.
Figure 3.16 The ITU-T target solution for ATM cell transmission
The ITU-T defined the evolutional approach to transmit ATM cells over SDH. The essential feature of SDH is to keep track of boundaries of streams that do not really depend on the particular medium. Although it was originally designed for transmission over fibre, it can in fact operate over other media.
The SDH mode type 1 (STM-1) frame is transmitted at 155 Mbit/s, as shown in Figure 3.17. The bytes are transmitted across the medium a row at a time, wrapping to the next row. It takes nominally 125 ms to transmit all nine rows forming the SDH STM-1 frame. The 125-ms frame makes it compatible with the digital telephony circuit 64 kbit/s which is 125 ms per byte.
Figure 3.17 SDH STM-1 frame
The first nine bytes of each row have various overhead functions. For example, the first two bytes are used to identify the beginning of the frame so that the receiver can lock onto this frame.
In addition, although not shown here, there is another column of bytes included in the ‘synchronous payload envelope’, which is additional overhead, with the result that each row has 260 bytes of information. Consequently, 260 bytes per row 9 rows
8 bits divided by 125 ms, equals 149.76 Mbit/s of payload, which is the same as the target solution.
The STM-1 in the international carrier networks will be the smallest package available in terms of the SDH. The bit rates for SDH STM-4 are four times the bit rates of the STM-1.
SDH also has some nice features for getting to higher rates – like 622 Mbit/s – it becomes basically a recipe of taking four of these STM-1 structures and simply interleaving the bytes to get to 622 Mbit/s (STM-4). There are additional steps up to 1.2 gigabits, 2.4 gigabits and so on. And at least in theory, the recipe makes it simple to get to a speed interface from low-speed ones.
Using the header error check (HEC) of the ATM cell delineates the cells within the SDH payload (VC-4 container). The receiver, when it is trying to find the cell boundaries, takes five bytes to check if they form a header or not. It does the HEC calculation on the first four bytes and matches that calculation against the fifth byte. If it matches, the receiver then counts 48 bytes and tries the calculation again. And if it finds that calculation correct several times in a row, it can probably safely assume that it has found the cell boundaries. If it fails, it just slides the window by one bit and tries the calculation again.
This kind of process must be used because we don't really know what is in the 48 bytes of payload, but the chances that the user data would contain these patterns separated by 48 bytes is essentially zero for any length of time.
For empty cells, the HEC is calculated by first calculating the CRC value, then performing an ‘exclusive or’ operation of the CRC value with a bit pattern called the coset, resulting in a non-zero HEC. Thus, the HEC is unique from the zeros in the empty cells, and the HEC may still be used for cell delineation. At the receiving end, another ‘exclusive or’ operation is performed, resulting in the original CRC for comparison.
The payload in an STM-1 frame is 135 563 Mbit/s, assuming that the entire cell payload may carry user information.
ATM provides a well-defined interface for networking purposes between users and network, between network nodes (switches) and between networks.
Two elements can be used to describe a reference configuration of the user–network access of B-ISDN: functional groups and reference points. Figure 3.18 gives the reference configuration. The broadband network terminal type 1 (B-NT1) and type 2 (B-NT2) are broadband network terminators. The B-NT2 provides an interface allowing other type of TE rather than the broadband TE to be connected to the broadband network.
Figure 3.18 B-ISDN reference configuration
Figure 3.19 ATM interfaces network node interconnections
B-NT1 functions are similar to layer 1 of the OSI reference model and some of the functions are:
B-NT2 functions are similar to layer 1 and higher layers of the OSI model. Some functions of B-NT2 are:
B-TE1 and B-TE2 are broadband terminal equipment. B-TE1 can be connected directly to the network from the reference and
. B-TE2 can only be connected to the network via a broadband adapter.
B-TA is broadband terminal adapter. It allows the B-TE2, which cannot be connected directly, to be connected to the broadband network.
and
indicate reference points between the terminal and the B-NT2 and between B-NT2 and B-NT1 respectively. Reference point characteristics are:
In Figure 3.19, first consider the private ATM network in the upper left corner. The interface between the terminal and the switch is referred to as the private user-to-network interface (UNI). The interface to the public network is a public UNI.
Within a private ATM network, there is the issue of connecting multiple switches together into an ATM network. This is referred to as the network node interface (NNI). In some ways, the NNI is misnamed because it is really more than an interface. It is a protocol that allows multiple devices to be interconnected in somewhat arbitrary topologies and still work as one single network. There is a corresponding protocol in the public arena called the public NNI.
The broadband inter-carrier interface (B-ICI) specifies how two carriers can use ATM technology to multiplex multiple services onto one link, thereby exchanging information and cooperating to offer services.
The ATM data exchange interface (DXI) allows a piece of existing Internet equipment – in this case, a router – to access the ATM network without having to make a hardware change. The hardware impact is in a separate channel service unit/data service unit (CSU/DSU). A typical physical layer for the DXI is a data-oriented interface such as the Ethernet frame.
The CSU-DSU takes the frames, chops them up into cells, does traffic shaping if required by the traffic contract, and ends up with a UNI.
The broadband inter-carrier interface (B-ICI), in its initial version, is a multiplexing technique. It specifies how two carriers can use ATM technology to multiplex multiple services onto one link, thereby exchanging information and cooperating to offer services.
The services specified in the B-ICI are: cell relay service, circuit emulation service, frame relay and switched multi-megabit data service (SMDS). Users of the carrier network do not ‘see’ this interface, but it is important because it will help provide services across carriers.
The connections involve routing through switching across the networks. There are two technologies.
One technique is called a permanent virtual connection (PVC). This will be done through some forms of service order process. It requires network management system to communicate to the various devices what the VCI-VPI values are and what the translations are. For example, the network management system tells the switch what entries to make in its connection table for each of the switches from the source to the destination.
There are some environments for which this is most reasonable. If there are a small number of devices attached to the ATM network, and these devices tend not to move around very much, this behaves much as telephone network private lines. This tends to make a lot of sense when there is a large community of interest between two locations. Because it takes a while to set up these connections, and to leave them up, but not to try to tear them down and set them up in a very dynamic fashion. That is why these are called permanent virtual connections. These function like a private network.
A second technique for establishing a connection through a network is called a switched virtual connection (SVC). This allows a terminal to set up and tear down connections dynamically.
The way SVC operates is that one of the VPI/VCI values is predefined for the signalling protocol to control the connections. The value is VPI-0/VCI-5, and this connection is terminated by the call processing function. Of course, the ‘receiving’ terminal also has VPI-0/VCI-5 terminating at the call processing function for this (or another) switch.
A protocol called the ‘signalling protocol’ is used on the VPI-0/VCI-5 connection to communicate with the switch, passing information to allow the connection to be set up or to be torn down (or to even be modified while it is in existence). The result is dynamic connection configuration. Further, these connections can be established and torn down as quickly as required.
Note that the connection that is set up for actual information transfer should not use VPI-0/VCI-5 which is reserved for network siginalling and call processing functions. The other connection passing around the call processing function does not interact with the call processing functions within the switch.
The signalling capability for ATM networks has to satisfy the following functions:
Signalling functions may also support multi-connection calls and multi-party calls. A multi-connection call requires the establishment of several connections to set up a composite call comprising various types of traffic like voice, video, image and data. It will also have the capability of not only removing one or more connections from the call but also adding new connections to the existing ones. Thus the network has to correlate the connections of a call. A multi-party call contains several connections between more than two end-users, such as conferencing calls.
Signalling messages are conveyed out of band in dedicated signalling virtual channels in broadband networks. There are different types of signalling virtual channels that can be defined at the B-ISDN user-to-network interface. They can be described as follows:
A signalling protocol needs some sort of addressing scheme. Private networks will probably use OSI Network Service Access Point (NSAP) type addressing (ISO/IEC8348), primarily because an administrative process exists. The public carriers will probably use E.164 numbers.
In order for an addressing scheme to be useful, there must be a standardised address format that is understood by all of the switches within a system. For instance, when making phone calls within a given country, there is a well-defined phone number format. When calling between countries, this format is usually modified to include information like a ‘country code’.
Each call set-up message contains the information in these fields twice – once identifying the party that is being called (destination) and once identifying the calling party (source).
Figure 3.20 shows the three address formats. The first byte in the address field identifies which of the address formats is being used. (Values for this field other than the three listed here are reserved and/or used for other functions.)
Figure 3.20 ATM address format
The three address formats are:
Regardless of the numbering plan used, it is very important that a network implementer obtains official globally unique numbers to prevent confusion later on when network islands are connected together.
Following the DCC or ICD fields – or immediately following the E.164 in the case of the E.164 format – is the ‘routing field.’ For DCC and IDC, this is the information that contains the address that is being called (or is placing the call).
This ‘routing field’ can be thought of as an address space. The term ‘routing field’ implies that there is more to the field than a simple address. In particular, the addressing mechanism will very probably be hierarchical to assist in the routing.
Each address in the routing field may refer to a particular switch, or it may even refer to a particular UNI on a switch. If it refers only to a switch, then more information will be needed to find the exact UNI that is specified. On the other hand, if it specifies a UNI, then this is sufficient to serve as a unique, globally significant address.
In Figure 3.20, let us consider the case in which the first 13 bytes only specify a particular switch, as opposed to a particular UNI. In this case, the switching system must still find the appropriate UNI for the call.
This could be done using the next six bytes, called the ‘end-system ID’. End systems, or terminals, could contain additional addressing information. For instance, the terminal could supply the last six bytes to the switch to identify the particular UNI. This way an entire switch could be assigned a 13-byte address, and the individual switch would then be responsible for maintaining and using the ‘end-system ID’.
This mechanism might be particularly attractive to a user desiring a large ‘virtual private network’, so that the user would obtain ‘switch addresses’ from an oversight organisation and then locally administer the end-system IDs. This would have the advantage of allowing the user organisation to administer the individual addresses without involving the outside organisation. However, anyone outside the organisation desiring to call a given UNI would have to know both the routing field and the end-system ID.
The six bytes of the end-system ID are not specified, so its use can be left up to the manufacturers. A common anticipated use of the end-system ID is to use the six bytes (48 bits) for the unique 48-bit MAC address that is assigned to each network interface card (NIC).
Of course, both the ATM switch and the terminal must know these addresses in order to route calls, send signalling messages etc. This information can be obtained automatically using the integrated link management interface (ILMI). The switch typically will provide the 13 most significant bytes (routing field) while the terminal provides the next six bytes (end-system ID).
The ATM network does not use the selector (SEL) byte, but it passes transparently through the network as a ‘user information field’. Thus, the SEL can be used to identify entities in the terminal, such as a protocol stack.
Network resource management concerns three aspects: the traffic to be offered (described by using traffic parameters and descriptors); the quality of service (QoS) agreed upon (that the user terminals to get and the networks to provide); and the compliance requirements to check if the user terminals have got the QoS required and networks have provided the QoS expected.
To provide QoS, the ATM network should allocate network resources including bandwidth, processor and buffer space capacities to ensure good performance using congestion and flow controls, for example to provide particular transmission capacities to virtual channels.
Traffic management includes the following mechanisms:
Traffic characteristics can be described by using the following parameters known as the traffic descriptors:
The QoS parameters describe the service requirements from user applications including:
There are five performance parameters that characterise the performance achieved by the networks: throughput; connection blocking probability; cell loss probability; switching delay; and delay variation.
ATM networks must fairly and predictably allocate the resources of the network. In particular, the network must support various traffic types and provide different service levels.
For example, voice requires very low delay and low delay variation. The network must allocate the resources to guarantee this. The concept used to solve this problem is called network management managing the network resources and network traffic.
When a connection is to be set up, the terminal initiating the service specifies a traffic contract (traffic characteristics and QoS requirements). This allows the network to examine the existing network utilisation and determine whether in fact a connection can be established that will be able to accommodate this usage. If the network resources are not available, the connection can be rejected.
While this all sounds fine, the problem is that the traffic characteristics for a given application are seldom known exactly. Considering a web page transfer we may think we understand that application, but in reality we are not certain ahead of time how big the page going to be, or even how often a transfer is going to happen. Consequently, we cannot necessarily identify precisely what the traffic characteristics are.
Thus, the idea of traffic policing is useful. The network ‘watches’ the cells coming in on a connection to see if they abide by the contract. Those that violate the contract have their cell loss priority (CLP) bit set. The network has the options to discard these cells now or when the network starts to get into a congested state.
In theory, if the network resources are allocated properly, discarding all the cells with a cell loss priority bit marked will result in maintaining a level of utilisation at a good operational point in the network. Consequently, this is critical in being able to achieve the goal of ATM: to guarantee the different kinds of QoS for the different traffic types. There are many functions involved in the traffic control of the networks.
Connection admission control (CAC) can be defined as the set of actions taken by the network during the call set-up phase to establish whether a connection can be made. A connection request can only be accepted if sufficient network resources are available to establish the end-to-end connection maintaining its required QoS and not affecting the QoS of existing connections in the network by this new connection.
There are two classes of parameters considered for the CAC. They can be described as follows:
Each ATM switch along the connection path in the network will be able to check if there are enough resources for the connection to meet the required QoS.
Usage parameter control (UPC) and network parameter control (NPC) perform similar functions at the user-to-network interface and network-to-node interface, respectively. They indicate the set of actions performed by the network to monitor and control the traffic on a connection in terms of cell traffic volume and cell routing validity. This function is also known as the ‘police function’. The main purpose of this function is to protect the network resources from malicious connection and equipment malfunction, and to enforce the compliance of every connection to its negotiated traffic contract. An ideal UPC/NPC algorithm meets the following features:
The CLP (cell loss priority) bit in the header of an ATM cell allows users to generate different priority traffic flows and the low-priority cells can be discarded to protect the network performance for high-priority cells. The two priority classes are treated separately by the network UPC/NPC functions.
Congestion control plays an important role in the effective traffic management of ATM networks. Congestion is a state of network elements in which the network cannot assure the negotiated QoS to already existing connections and to new connection requests. Congestion may happen because of unpredictable statistical fluctuations of traffic flows or a network failure.
Congestion control is a network means of reducing congestion effects and preventing congestion from spreading. It can assign CAC or UPC/NPC procedures to avoid overload situations. To mention an example, congestion control can minimise the peak bit rate available to a user and monitor this. Congestion control can also be done using explicit forward congestion notification (EFCN). A node in the network in a congested state may set an EFCN bit in the cell header. At the receiving end, the network element may use this indication bit to implement protocols to reduce the cell rate of the connection during congestion.
Traffic shaping changes the traffic characteristics of a stream of cells on a connection. It spaces properly the cells of individual connections to decrease the peak cell rate and also reduces the cell delay variation. Traffic shaping must preserve the cell sequence integrity of the connection. Traffic shaping is an optional function for both network operators and end users. It helps the network operator in dimensioning the network more cost effectively and it is used to ensure conformance to the negotiated traffic contract across the user-to-network interface in the customer premises network. It can also be used for user terminals to generate traffic of cells conforming to a traffic contract.
The traffic contract is based on something called the generic cell rate algorithm (GCRA). This algorithm specifies precisely when a stream of cells either violates or does not violate the traffic contract. Consider a sequence of arrivals of cells. This sequence is run with the algorithm to determine which cells (if any) violate the contract.
The algorithm is defined by two parameters: the increment parameter ‘I’ and the limit parameter ‘L’. The GCRA can be implemented by either of the two algorithms: leaky bucket algorithm or virtual scheduling algorithm. Figure 3.21 shows a flow chart of the algorithms.
The two algorithms served the same purpose: to make certain that cells are conforming (arrival within the bound of an expected arrival time) or nonconforming (arrival sooner than an expected arrival time).
Sometimes referred to as a ‘continuous-state leaky bucket’. Think about this as a bucket with a hole in it. To make this a little more concrete, assume that ‘water’ is being poured into the bucket and that it leaks out at one unit of water per cell time. Every time a cell comes into the network that contains data for this connection, units of water are poured into the bucket. Of course, then the water starts to drain out one unit per time slot constantly. Figure 3.22 shows the leaky bucket illustrating the GCRA.
The size of the bucket is defined by the sum of the two parameters . Any arrival cell that causes the bucket to overflow when
units are added in violates the contract.
Figure 3.21 Generic cell rate (GCRA) algorithm
Figure 3.22 Leaky bucket algorithm (LBA)
If the bucket was empty initially, a lot of cells can go into the bucket. The bucket would eventually fill up if the cells arrive too quickly. Then it would be better to slow down. In fact, the overall rate that can be handled is the difference between the size of and the leak rate.
affects the long-term cell rate, and
affects short-term cell rate because it affects the size of the bucket. This controls how cells can burst through the network.
Let us consider the leaky bucket algorithm with a smooth traffic example. In Figure 3.23, the cell times are separated left to right equally in time. The state of the bucket just before the cell arrival time is represented by , and the state of the bucket just afterwards is represented by
.
Figure 3.23 An illustration of smooth traffic coming to the leaky bucket – GCRA(1.5, 0.5)
Assume the bucket is empty and a cell comes in on this connection. One-and-a-half units of water are added into the bucket. (Each cell contains one-and-a-half units of information. This is the increment parameter, = 1.5.) However, we can only leak one unit per cell time. By the time the next cell arrives, one unit has drained out and, of course, by carefully planning this example, another cell comes in so the other
units are added into the bucket. Now the bucket is one-half plus one-and-a-half – it is exactly full.
At the next time, if a cell came in, that cell would violate the contract because there is not enough room to put 1.5 units into this bucket. So let us assume that we are obeying the rules. We do not send a cell and the bucket level stays the same; then it finally drains out and, of course, you can see we are back where we started.
The reason this is a ‘smooth’ traffic case is because it tends to be very periodic. In this case, every two out of three cell times a cell is transmitted, and we assume that this pattern goes on indefinitely. Of course, two out of three is exactly the inverse of the increment parameter, 1.5. This can be adjusted with the and the leak rate so that the parameter can be any increment desired – 17 out of 23, 15 out of 16 and so on. There is essentially full flexibility to pick the parameters to get any fine granularity of rate.
Now let us consider an example of more burst traffic. To make this burst, increase the limit parameter L to 7 and just slow things down; the increment parameter I is 4.5, so the bucket is 11.5 deep, as shown in Figure 3.24.
Figure 3.24 Illustration of burst traffic coming to the leaky bucket – GCRA(4.5, 7)
In this example, send three cells and the bucket becomes exactly full after three cells. Now the rate is still only draining one unit per time but the increment is 4.5. Obviously, it will take time to let the bucket level go down before another cell can be sent.
The bucket will become empty completely if the waiting times are long enough. The bucket can then accept another burst of three cells. This illustrates the effect of increasing the limit parameter to allow more burst type of traffic. Of course, this is especially critical for a typical data application.
In the virtual scheduling algorithm (VSA), is the parameter used to space the time between two consecutive arrival cells. It allows the space of two cells to be smaller than
, but that must be larger than (
–
). The total shift of time for a consecutive set of cells is controlled to be less that
. Figure 3.25 illustrates the concept of the VSA. It shows that the inter-arrival time between cell 1 and cell 2 should be greater than or equal to
. If cell 2 arrives earlier than the inter-arrival time
but later than (
–
), cell 2 is still considered as a conforming cell. Otherwise, cell 2 is considered a nonconforming cell.
Figure 3.25 Virtual scheduling algorithm (VSA)
The developments of the Internet protocols have followed quite different paths from the ATM protocols, leading to the standards for networking today. In the early years, the Internet was developed and used mainly by universities, research institutes, industry, military and the United States government. The main network technologies were campus networks and dial-up terminals and servers interconnected by backbone networks. The main applications were email, file transfer and telnet.
The explosion development of the Internet started in the mid-1990s, when the WWW provided a simple interface to ordinary users who did not need to know anything about the Internet technology by a simple click. The impact was far beyond people's imagination and entered our daily lives for information access, communications, entertainment, e-commerce, e-government and so on. New applications and services are developed every day using WWW based on the Internet.
In the meantime, the technologies and industries have started to converge so that computers, communications, broadcast, and mobile and fixed networks cannot be separated from each other any longer. All of these are supported by the Internet. The original design of the Internet could not meet the increasing demands and requirements therefore the Internet Engineering Task Force (IETF) started to work on the next generation of networks. The IPv6 is the result of the development of the next generation of Internet networks. The third/fourth generation (3/4G) mobile networks have also taken all-IP networks for mobile communications. Here we provide a brief introduction to the Internet protocols, and will leave further discussion to the later chapters on the next generation of Internet including IPv6 from the viewpoints of protocol, performance, traffic engineering and QoS support for future Internet applications and services relevant to satellite networking.
Internet networking is an outcome of the evolution of computer and data networks. There are many technologies available to support different data services and applications using different methods for different types of networks. The network technologies include local area network (LAN), metropolitan area network (MAN) and wide area network (WAN) using star, bus ring, tree and mesh topologies and different media access control mechanisms.
Like ATM, the Internet is not a transmission technology but a network protocol. Unlike ATM, the Internet was developed to allow different technologies to be able to internetwork together using the same type of network layer packets to be transported across different network technologies.
LAN is widely used to connect computers together in a room, building or campus. MAN is a high-speed network to connect LANs together in metropolitan areas. WAN is used across a country, continent or a globe. Before the Internet, bridges were used to interconnect many different types of networks at link level by translating functions and frames formats and adapting transmission speeds between different network technologies. Interconnecting different types of networks using different protocols together to form a larger network becomes a great challenge. The Internet protocol has taken a complete different approach from the translation between different network protocols and technologies, by introducing a common connectionless protocol called the Internet Protocol (IP) in which data is carried by the packets across different network technologies.
Protocol hierarchy and layering principles are also important concepts to deal with the complexity of network design. The Internet protocols define the functions of network layers and above. Details on how to transport the network packet across different types of network technologies are considered as low layer functions, defined within the individual network technologies, as long as the technology is able to provide frames with payload and link layer functions capable of carrying the Internet packet across the network of the technology. On top of the network layer is the transport layer, and then the application layer.
Figure 3.26 Internet packets over routers and sub-networks
The Internet network layer function is connectionless, providing best-effort services. The whole network consists of many sub-networks, each of which can be of any type of network technology including LAN, MAN and WAN. User terminals can communicate directly with each other in the same sub-network using broadcast frames in shared media such as LAN, point-to-point link frames such as dialup links and multi-service frames such as WAN.
Routers are at the edge of the sub-networks and connect the sub-networks together, they can communicate with each other directly and also with user terminals in the same sub-networks. In other words, the Internet routers are interconnected together by many different network technologies. Each packet generated by source terminals carries the destination and source addresses of the terminals, and can be delivered to the destination terminal on the same sub-network or to a router on the same sub-network. The router is able to receive the packet and forward it to the next router identified bythe routing protocols, until the packet reaches its destination.
In the Internet reference model, there is only one network layer protocol, that is the Internet Protocol (IP). It is a unique protocol making use of the transmission services provided by the different types of network technologies (such as Ethernet, WiFi, 3/4G mobile networks or satellite networks) below, and providing end-to-end network layer service to the transport layer protocols above.
The IP packets may be carried across different type of networks, but their IP format stays the same. Any protocol above the IP layer can only access the functions provided by the IP packet. Therefore the differences of the networks are screened out by the IP layer as shown in Figure 3.26.
Figure 3.27 shows the format of the IP version 4 (IPv4) packet.
Figure 3.27 IP packet header format
The following is a brief discussion on each field of the IP packet header.
Table 3.1 Option fields of the IPv4 packet header
Option | Description |
Security | Specifies how secret the datagram is |
Strict source routing | Gives complete path to follow |
Loose source routing | Gives a list of routers not be missed |
Record route | Makes each router append its IP address |
Time stamp | Makes each router append its address and time stamp |
The IP address used in the source and destination address fields of the IP packet is 32 bits long. It can have up to three parts. The first part identifies the class of the network address from A to E, the second part is the network identifier (net-id) and the third part is the host identifier (host-id). Figure 3.28 shows the formats of the IPv4 addresses.
Figure 3.28 IP address formats
In class A and B addresses, there are a large number of host-id. The hosts can be grouped into subnets each of which is identified by using the high-order host-id bits. A subnet mask is introduced to indicate the split among the net-id, sub-net-id and host-id.
Similarly, there is a large number of net-id in the class C addresses. Some of the lower order bits of the net-id can be grouped together to form a supernet. This is also called classless inter domain routing (CIDR) addressing. Routers do not need to know anything within the supernet or the domain.
Class A, B and C addresses identify the attachment point of the hosts. Class D addresses identify the multicast address (like radio channel) but not an attachment point in the network. Class E is reserved for future use. There are also some special addresses shown in Figure 3.29.
Figure 3.29 Special IP addresses
An Internet address is used to identify a sub-network in the context of Internet. Each address consists of two parts: one identifies uniquely a sub-network and the other a host computer. The physical address is used to identify a network terminal related to the transmission technologies. For example, we can use a telephone number to identify individual telephones in the telephony networks, and an Ethernet address to identify each network interface card (NIC) uniquely for Ethernet networks.
Each host (laptop, smartphone, or workstation), by installing an Ethernet NIC, will have the unique Ethernet address worldwide. A host can send data to another host or to all hosts in the Ethernet by broadcasting using the other hosts' addresses or Ethernet broadcasting address.
Each host also has a unique IP address in the Internet. All the hosts in the Ethernet have the same network identifier (net-id) forming a sub-network. The sub-networks can be connected to the Internet by using routers. All routers exchange information using routing protocols to find out the topology of the Internet and calculate the best router to be used for forwarding packets to their destinations.
Clearly, the host can send a packet to another host directly within the same sub-network. If the other host is outside of the sub-network, the host can send the packet to a router. The router can forward the packet to the next one until the packets reach their destinations or send to the host if the router is on the destination network. Therefore, the Internet can be seen as a network of interconnected routers by using many different network transmission technologies. However, the transmissions of the Internet packets between the routers need to use the native addresses and data frames of the network technologies. As the native address identifies access points to the network technology and the Internet address identifies the host, a mapping is required to specify the identified host attached to the network access point together forming a part of the sub-net.
A network manager can set up such a mapping manually for small networks, but it is preferable to have network protocols to map them automatically in a global scale.
Address resolution protocol (ARP) is a protocol used to find the mapping between the IP address and network address such as an Ethernet address (RFC 826). Within the network, a host can ask for the network address giving an IP address to get the mapping. If the IP address is outside the network, the host will forward the IP address to a router (it can be a default or proxy).
Reverse address resolution protocol (RARP) is the protocol used to solve the reverse problem, that is, to find the IP address giving a network address such as Ethernet. This is normally resolved by introducing a RARP server (RFC 903). The server keeps a table of the address mapping. An example of using RARP is when a booting machine does not have an IP address and needs to contact a server to get an IP address to be attached to the Internet.
The dynamic host configuration protocol (DHCP) server maintains a database of available IP addresses and configuration information. When it receives a request from a host, it dynamically allocates an IP address and network configuration information to the host. The protocol is specified in detail by RFC 2131, which has been updated by RFC 3396 and RFC 4361.
Each router in the Internet has a routing table showing the next router or default router to forward packets to for all the destinations. As the Internet becomes larger and larger it is impractical or impossible to configure the routing table manually, although in the early days and for small networks manual configuration of network was carried out for convenience but was error prone. Protocols have to be developed to configure the Internet automatically and dynamically.
A part of the Internet owned and managed by a single organisation or by a common policy can form a domain or autonomous system (AS). The interior gateway routing protocol (IGRP) is used for IP routing within the domain. Between domains, the exterior gateway routing protocol (EGRP) has to be used as political, economic or security issues often need to be taken into account.
The original routing protocol was called the routing information protocol (RIP), which used the distance vector algorithm. Within the domain, each router has a routing table of the next router leading to the destination network. The router periodically exchanges its routing table information with its neighbour routers, and updates its routing table based on the new information received.
Due to its slow convergence problem, a new routing protocol was introduced in 1979, using the link state algorithm. The protocol was also called the link state routing protocol. Instead of getting routing information from its neighbour, each router using the link state protocol collects information on the links and sends link state information of its own and received link state information of the other neighbours by flooding the network with the link state information. Every router in the network will have the same set of link state information and can calculate independently the routing table. This solved the problems of the RIP for large-scale networks.
In 1988, the IETF began work on a new interior gateway routing protocol, called open shortest path first (OSPF) based on the link state protocol, which became a standard in 1990 (refer to RFC 2328 and RFC 5340). It is also based on algorithms and protocols published in open literatures (this is the reason the word ‘open’ appears in the name of the protocol), and is designed to support: a variety of distance metrics, adaptive to changes in topology automatically and quickly; routing based on type of service and real-time traffic; load balancing; hierarchical systems and some levels of security; and also deals with routes connected to the Internet via a tunnel.
The OSPF supports three kinds of connections and networks including point-to-point lines between two routers, multicast networks (such as LAN), and multi-access networks without broadcasting (such as WAN).
When booting, a router sends a HELLO message. Adjacent routers (designated routers in each LAN) exchange information. Each router periodically floods link state information to each of its adjacent routers. Database description messages include the sequence numbers of all the link state entries, sent in the Internet packets. Using flooding, each router informs all the other neighbour routers. This allows each router to construct the graph for its domain and compute the shortest path to form a routing table.
All an interior gateway protocol has to do is move packets as efficiently as possible. Exterior gateway routers have to worry about politics a great deal. EGRP is fundamentally a distance vector protocol, but with additional mechanisms to avoid the problems associated with the distance vector algorithm. Each EGRP router keeps track of the exact path used to solve the problems of distance vector. EGRP is also called the board gateway protocol (BGP), as specified by RFC 4271.
The transport layer protocols appear on the hosts defining a communication protocol between two hosts. When a packet arrives in a host, it decides which application process to handle the data, e.g. email, telnet, ftp or WWW. There are also additional functions including reliability, timing, flow control and congestion control. There are two protocols at the transport layer within the Internet reference model.
TCP is a connection-oriented, end-to-end reliable protocol. It provides reliable inter-process communication between pairs of processes in host computers. One of the hosts acts as a server and the other as a client. The client initiates a request actively for connection to the server using three-way handshakes while the server waits passively for a connection. Very few assumptions are made as to the reliability of the network technologies carrying the Internet packets. TCP assumes that it can obtain a simple, potentially unreliable datagram service from the lower level protocols (such as IP). In principle, TCP should be able to operate above a wide spectrum of communication systems ranging from hard-wired LAN and packet-switched networks to wireless LAN, wireless mobile networks and satellite networks.
Figure 3.30 illustrates the TCP segment header.
Figure 3.30 The TCP segment header
The functions of the fields are the following:
To identify the separate data streams that a TCP may handle, the TCP provides the port identifier. Since port identifiers are selected independently by each TCP they might not be unique. To provide for unique addresses within each TCP, IP address and port identifier are used together to create a unique socket throughout all sub-networks in the Internet.
A connection is fully specified by the pair of sockets at the ends. A local socket may participate in many connections to different foreign sockets. A connection can be used to carry data in both directions, that is, it is ‘full duplex’.
The TCP are free to associate ports with processes however they choose. However, several basic concepts are necessary in any implementation. Well-known sockets are a convenient mechanism for a priori associating socket addresses with standard services. For instance, the ‘telnet-server’ process is permanently assigned to a socket number of 23, FTP-data 20 and FTP-control 21, TFTP 69, SMTP 25, POP3 110 and WWW HTTP 80.
System ports (numbers 0–1023 are assigned by the IETF standards, user ports (numbers 1024–4915) are assigned by the Internet assigned name authority (IANA), and dynamin private ports (49152–65535) are not assigned and free for any use.
A connection is specified in the system call OPEN by the local and foreign socket arguments. In return, the TCP supplies a (short) local connection name by which the user refers to the connection in subsequent calls. There are several things that must be remembered about a connection. To store this information we imagine that there is a data structure called a transmission control block (TCB). One implementation strategy would have the local connection name be a pointer to the TCB for this connection. The OPEN call also specifies whether the connection establishment is to be actively pursued or passively waited for.
The procedures used to establish connections utilise the synchronisation (SYN) control flag and involve an exchange of three messages. The first message is the request to establish a connection fron the client process to the server process; the second message is to reply to the request from the server to the client, and the third message is the confirm the connection from the client to the server. This exchange has been termed a three-way handshake. The connection becomes ‘established’ when sequence numbers have been synchronised in both directions. The clearing of a connection also involves the exchange of segments, in this case carrying the finish (FIN) control flag.
The data that flows on the connection may be thought of as a stream of octets. The sending process indicates in each system call SEND that the data in that call (and any preceding calls) should be immediately pushed through to the receiving process by setting of the PUSH flag.
The sending TCP is allowed to collect data from the sending process and to send that data in segments at its own convenience, until the push function is signalled, then it must send all unsent data. When a receiving TCP sees the PUSH flag, it must not wait for more data from the sending TCP before passing the data to the receiving process. There is no necessary relationship between push functions and segment boundaries. The data in any particular segment may be the result of a single SEND call, in whole or part, or of multiple SEND calls.
One of the functions in the TCP is end-host based congestion control for the Internet. This is a critical part of the overall stability of the Internet. In the congestion control algorithms, TCP assumes that, at the most abstract level, the network consists of links for packet transmission and queues for buffering the packets. Queues provide output buffering on links that can be momentarily oversubscribed. They smooth instantaneous traffic bursts to fit the link bandwidth.
When demand exceeds link capacity long enough to cause the queue buffer to overflow, packets must get lost. The traditional action of dropping the most recent packet (‘tail dropping’) is no longer recommended, but it is still widely practised. Various random early detection (RED) schemes have been developed for active queue management.
TCP uses sequence numbering and acknowledgements (ACKs) on an end-to-end basis to provide reliable, sequenced, once-only delivery. TCP ACKs are cumulative, that is, each one implicitly ACKs every segment received so far. If a packet is lost, the cumulative ACK will cease to advance.
Since the most common cause of packet loss is congestion in the traditional wired network technologies, TCP treats packet loss as an indicator of network congestion (but such an assumption is not applicable in wireless or satellite networks where packet loss is more likely to be caused by transmission errors). This happens automatically, and the sub-networks need not to know anything about IP or TCP. It simply drops packets whenever it must, though some packet-dropping strategies are fairer than others.
TCP recovers from packet losses in two different ways. The most important one is by a retransmission of lost packets when timeout occurs. If an ACK fails to arrive after a certain period of time, TCP retransmits the oldest unacknowledged packet. Taking this as a hint that the network is congested, TCP waits for the retransmission to be acknowledged (ACKed) before it continues, and it gradually increases the number of packets in flight as long as a timeout does not occur again.
The timeout for retransmission can impose a significant performance penalty, as the sender will be idle during the timeout interval and restarts with a congestion window of one following the timeout (slow start). To allow recovery from the occasional lost packet in a bulk transfer, an alternate scheme known as “fast retransmission” and “fast recovery” have been developed in RFC 2001.
This scheme relies on the fact that when a single packet is lost in a bulk transfer, the receiver continues to return ACKs to subsequent data packets, but they will not actually acknowledge (ACK) any data. These are known as ‘duplicate acknowledgements’ or ‘dupacks’. The sending TCP can use dupacks as a hint that a packet has been lost, and it can retransmit it without waiting for a timeout. Dupacks effectively constitute a negative acknowledgement (NAK) for the packet whose sequence number is equal to the acknowledgement field in the incoming TCP packet. TCP currently waits until a certain number of dupacks (currently three) are seen prior to assuming a loss has occurred; this helps avoid an unnecessary retransmission in the face of out-of-sequence delivery.
In addition to congestion control, the TCP also deals with flow control to prevent the sender overrunning the receiver. The TCP ‘congestion avoidance’ (RFC 5681) algorithm is the end-to-end system congestion control and flow control algorithm used by TCP. This algorithm maintains a congestion window (cwnd) between the sender and receiver, controlling the amount of data in flight at any given point in time. Reducing cwnd reduces the overall bandwidth obtained by the connection; similarly, raising cwnd increases the performance, up to the limit of the available bandwidth.
TCP probes for available network bandwidth by setting cwnd at one packet and then increasing it by one packet for each ACK returned from the receiver. This is known as ‘slow-start’ mechanism. When a packet loss is detected (or congestion is signalled by other mechanisms), cwnd is set back to one and the slow-start process is repeated until cwnd reaches one half of its previous setting before the loss. Cwnd continues to increase past this point, but at a much slower rate than before to avoid congestion. If no further losses occur, cwnd will ultimately reach the window size advertised by the receiver. Figure 3.31 illustrates an example of the congestion control and congestion avoidance algorithm.
Figure 3.31 Congestion control and avoidance
The UDP is defined to make available a datagram mode of the transport layer protocol defined in RFC 768. This protocol assumes that the Internet protocol (IP) is used as the underlying protocol.
This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol provides connectionless service and does not provide any guarantee on delivery, duplicate protection and order of delivery, or even make any effort to recover any lost data. Therefore, it makes the protocol very simple and particularly useful for real-time data transportation. Retransmission of any lost packet for real-time applications may not be required or even useful, as it is very difficult to meet the real-time requirement for any retransmission scheme.
Figure 3.32 illustrates the UDP datagram header format.
Figure 3.32 The UDP datagram header format
The functions of the fields of the UDP datagram header are discussed here.
The major uses of this protocol are the Internet name server, and the trivial file transfer, and recently for real-time applications such as VoIP, video streaming and multicast where retransmission of lost data is undesirable. The well-known ports are defined in the same way as the TCP.
Since there are vast numbers of computers and network terminals interconnected by using LANs, MANs and WANs and the Internet protocols operating on these networks, a key to success will be the ability to allow for interoperability between these network technologies and ATM. A key to success of future Internet is its ability to support QoS and to provide a uniform network view to higher layer protocols and applications.
Here we introduce briefly the native IP over ATM (or classic IP over ATM), including the mode of operation, address resolution mechanisms used to map Internet addresses directly into ATM addresses and the Internet encapulations (Figure 3.33).
Figure 3.33 Protocol stacks for LAN emulation and classical IP over ATM
The alternative method of carrying network layer packets across an ATM network is known as LAN emulation (LANE). As the name suggests, the function of the LANE protocol is to emulate a local area network on top of an ATM network. Specifically, the LANE protocol defines mechanisms for emulating either an IEEE 802.3 Ethernet or an 802.5 token ring LAN.
The transport of any network layer protocol over an overlay mode ATM network involves two aspects: packet encapsulation and address resolution. Both of these aspects have been tackled by the IETF, and are described below.
The IETF has defined in RFC 2684 a method for transporting network or link layer packets across an ATM (AAL 5) connection and also for multiplexing multiple protocols over a single ATM virtual connection. As with LANE, there is value to reusing the same connection for all data transfers between two nodes since this conserves the connection resource space, and saves on connection set-up latency, after the first connection set up. This is only possible, however, as long as only unspecified bit rate (UBR) or available bit rate (ABR) connections are used – if the network layer requires QoS guarantees then every distinct flow will typically require its own connection.
In order to allow connection re-use, there must be a means for a node that receives a network layer packet across an ATM connection to know what kind of packet has been received, and to what application or higher level entity to pass the packet to; hence, the packet must be prefixed with a multiplexing field. Two methods for doing this are defined in RFC 2684:
The VC multiplexing encapsulation may be used where direct application-to-application ATM connectivity, bypassing lower level protocols, is desired. As discussed earlier, however, such direct connectivity precludes the possibility of internetworking with nodes outside the ATM network.
The LLC/SNAP encapsulation is the most common encapsulation used in the IP over ATM protocols. The ITU-T has also adopted this as the default encapsulation for multiprotocol transport over ATM. In related work, IP over ATM for a maximum transfer unit (MTU) size has the default value of 9180 bytes. It does, however, allow for negotiation of the MTU beyond this size, to the AAL5 maximum of 64 kbytes, since important performance improvements can be gained by using larger packet sizes. This also mandates the use of IP path MTU discovery by all nodes implementing IP over ATM to preclude the inefficiency of IP fragmentation.
In order to operate IP over ATM, a mechanism must be used to resolve IP addresses to their corresponding ATM addresses. For instance, consider the case of two routers connected across an ATM network. If one router receives a packet across a LAN interface, it will first check its next-hop table to determine through which port, and to what next-hop router, it should forward the packet. If this look-up indicates that the packet is to be sent across an ATM interface, the router will then need to consult an address resolution table to determine the ATM address of the destination next-hop router (the table could also be configured, of course, with the VPI/VCI value of a PVC connecting the two routers).
This address resolution table could be configured manually, but this is not a very scalable solution. RFC 1577 has defined a protocol to support automatic address resolution of IP addresses. This protocol is known as ‘classical IP over ATM’ and introduces the notion of a logical IP sub-net (LIS). Like a normal IP sub-net, an LIS consists of a group of IP nodes (such as hosts or routers) that connect to a single ATM network and belong to the same IP sub-net.
To resolve the addresses of nodes within the LIS, each LIS supports a single ATM address resolution protocol (ATMARP) server, while all nodes (LIS clients) within the LIS are configured with the unique ATM address of the ATMARP server. When a node comes up within the LIS, it first establishes a connection to the ATMARP server, using the configured address. Once the ATMARP server detects a connection from a new LIS client, it transmits an inverse ARP request to the attaching client and requests the node's IP and ATM addresses, which it stores in its ATMARP table.
Subsequently, any node within the LIS wishing to resolve a destination IP address would send an ATMARP request to the server, which would then respond with a ATMARP reply if an address mapping is found. If not, it returns an ATM_NAK response to indicate the lack of a registered address mapping. The ATMARP server ages out its address table for robustness, unless clients periodically refresh their entry with responses to the servers inverse ARP queries. Once an LIS client has obtained the ATM address that corresponds to a particular IP address, it can then set up a connection to the address.
The operation of the classical model is very simple. It does, however, suffer from a number of limitations. One of these limitations is indicated by the phrase ‘classical’. What this means is that the protocol does not attempt to change the IP host requirement that any packet for a destination outside the source node's IP sub-net must be sent to a default router. This requirement, however, is not a good fit to the operation of IP over ATM, and a whole class of other ‘non-broadcast multi-access’ (NBMA) networks. In all such networks, it is possible to define multiple LIS, and the network itself could support direct communications between two hosts on two different LIS.
However, since RFC 1577 preserves the host requirements, in the context of IP over ATM, communications between two nodes on two different LIS on the same ATM network must traverse each ATM router on the intermediate hops on the path between the source and destination nodes. This is clearly inefficient, since the ATM routers become bottlenecks; this also precludes the establishment of a single connection with a requested QoS between the two nodes.
1 Explain the concepts of the ATM protocol and technology.
2 Discuss the functions of ATM Adaptation Layers (AAL) and the type of services they provide.
3 Use a sketch to explain how to transport ATM cells using an E1 connection.
4 Explain the concepts of VP and VC switches.
5 Explain how to achieve QoS and efficient utilisation of network resources.
6 Describe the leaky bucket and virtual scheduling algorithms.
7 Explain the functions of the Internet Protocol (IP).
8 Explain the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) and their differences.
9 Explain the concept of classical IP over ATM.