Packetizer

5 Sorting out the mess

5.1 Introduction to the middle layers

In the next three chapters, we introduce and discuss some of the concepts underlying the three layers that are at the heart of OSI, the Transport Layer, the Session Layer, and the Presentation Layer. Whereas one could argue that a network is "OSI" if and only if it runs protocols providing the OSI Network Service (connectionless or connection-oriented) across it, one could equally argue that an application protocol is "OSI" if and only if it runs over these three middle-layer protocols. It is also appropriate to remind the reader at this time that it is in these three layers that we are expecting to address issues that are independent of both the technology used for communication and of the application that is the subject of the communication.

Thus in these three layers, and these three layers alone, one can reasonably expect OSI to become "complete" and "stable". Such stability is inherently dependent on stability in the specification of the OSI Network Service (which provides the technology independence to these layers) and on stability in the broad identified application-independent requirements that determine the functions to be performed in these layers. As discussed above, it became evident in the early 1990s that assumptions of stability in these two areas were becoming invalid, and new work was initiated to extend the functionality of the transport layer and surrounding services. Nonetheless, it remains the principle that once completed, OSI standards in these middle layers should remain relatively impervious to future changes in technology, or to the need to develop standards for new applications.

As a final introductory point, it should be noted that the issue of connectionless versus connection-oriented services was originally discussed in relation to end-to-end transport mechanisms, with the expectation underlying earlier text that applications would want a connection-oriented type of service. There are two concepts that are important to this discussion:

  • individual messages that might or might not get through (connectionless); versus
  • a stream of messages delivered in sequence with any loss or failure signalled to both end systems (connection-oriented);

These twin concepts can be applied to the actual service used by an application. One can conceive of some applications (but maybe not many!) where use of connectionless communication without attempting any form of error recovery is acceptable.

To support this, and paralleling the UDP (User Datagram Protocol) that is a lesser known but equal partner to TCP in the TCP/IP suite, the OSI stack includes connectionless services mapped right up to the application layer. The connectionless services and protocols in the middle layers are much simpler than the connection-oriented services and protocols, and are ignored in the following discussion until a final section of this chapter covers this material. Thus the following discussion is concerned solely with the provision of connection-oriented services to the application, albeit obtained (in the case of the Transport Layer) using either a connection-oriented or a connectionless Network Service.

5.2 Overview of the Transport Layer

The Transport Layer Standards address the issue of providing mechanisms that will improve the overall quality of the end-to-end service which is in use. The quality of an end-to-end communications path will normally be highly dependent on where it is going to. For some paths there may be heavily overloaded and unreliable switches in use, whilst for other paths from the same end-system there may be no congestion problems and highly robust switches. In the former case an application will frequently need mechanisms operating between the two end-systems (a Transport Layer protocol) to correct from network failures and to provide a reliable communications path. Such protocols can clearly be made independent of the actual application in use, and can sensibly be standardised as an application independent standard. We say protocols (plural), because the functions to be performed will depend on the quality of the end-to-end communications path and could vary from a do-nothing protocol for use over a highly reliable path to a very complex protocol if the path is very poor. There is, of course, an infinite range of possible variation in a network communications path, and hence a potentially infinite set of "useful" transport layer protocols. Standardization requires the selection of a small number of such protocols to meet the range of needs.

In OSI, we talk about the class of Transport Protocol, Transport Protocol Class 0 to Transport Protocol Class 4 - effectively five protocols (see figure 5.1: Classes of transport protocol). The usual abbreviation in the literature for (for example) Transport Protocol Class 4 is either TC4 or (more commonly) TP4. The principle of the OSI Transport Layer is that all five protocols will be supported by a general-purpose implementation, with an appropriate selection made for each instance of communication. Of course, if an implementation is designed for a rather specialised environment (for example, for use only over network paths consisting of a single high-quality PTT-provided X.25 hop), then corners can be cut and protocols designed for a less reliable path need not be implemented. In the early days of deployment of OSI implementations, one frequently found systems implementing only one protocol class, resulting in serious interworking problems (this is discussed later), but increasingly today one finds implementations with the full range of capability, and with the ability to select and negotiate with the other end-system about which one to employ.

5.3 Quality of Service

In order to give some precision to a discussion of "quality", it is necessary to define what constitutes the "quality" of a network path. The Network Service definition includes the concept of the quality of service (QOS) provided by a connection-oriented or a connectionless transmission in terms of a number of parameters such as cost, delay, probability of loss, probability of undetected errors, throughput, and so on. Values associated with some (but not all) of these parameters are carried in network protocols, and can in principle be used to affect the route taken by a connectionless transmission or by a connection.

These same parameters are passed down in service primitives from an application when a connection is being established, to reflect its needs, and are passed to the Network Layer that can use them to help determine the best route to be taken by this communication. They are, however, also used in the Transport Layer, in conjunction with knowledge of the quality of service being provided by the network for this particular communication path, to determine which of several possible protocols to employ in the Transport Layer to meet more nearly the QOS needs of the application. Of course, not all aspects of quality of service can be improved by an end-to-end protocol. An obvious example is the round-trip delay time. If this is poor, there is nothing the two end-systems can do to improve it. Nonetheless, there are a number of aspects of QOS that an appropriate choice of Transport Protocol can improve.

The idea of improving on a poor underlying service is fundamental to the use of the connectionless Network Service, where the lossy nature of the network path makes it necessary to improve the service by end-to-end error recovery and reordering in order to support most applications. In the TCP/IP suite, it is TCP (Transmission Control Protocol) that performs this role. This protocol is often compared with TP4. Whilst there are many similarities, there are none-the-less differences in the details of the service provided.

There are five main aspects of quality that the Transport Layer addresses. These are:

  • cost of the communication (see 5.4);
  • available bandwidth (see 5.5);
  • recovery from errors which are signalled by the Network Layer (the network generated N-RESET and N-DISCONNECT primitives) in the connection-oriented service (see 5.6);
  • recovery from unsignalled loss or reordering of messages (predominantly in the connectionless service, but potentially in the connection-oriented service too) (see 5.7);
  • detection of corrupted messages where the corruption was not detected and dealt with by a lower layer (see 5.8).

5.4 Cost reduction

How does one reduce the cost of transmission? One obvious suggestion would be to provide data compression to reduce the amount of data transmitted. Provided charging over this network path was based on the number of bits transmitted, and not simply on a message count, this could be quite effective. (It could also improve the effective bandwidth seen by the application.) For better or for worse, this is not a feature of the Transport Layer of OSI. Compression is seen as an issue related to the way in which information is represented, and hence as something which is the concern of the presentation layer, and compression features are not present in any of the Transport Classes.

So how else can cost reduction be achieved? The trick is to consider the possibility of several connections running between the same pair of end-systems. In the tarrifing of many PTTs, the cost of an X.25 connection is a combination of a volume charge for the amount of data sent, with a holding charge for the length of time the connection is kept open. For certain types of traffic, for example, that generated by a user on a terminal logged in to a remote host computer, the two charges are often about equal.

Suppose, then, that we have twenty terminals physically attached to one computer system, and all logged in to the same remote computer system. In the simplest approach, each would have its own X.25 connection, and we would be paying, say (for example), 60 pence per minute. But now suppose we were able to introduce a protocol that provided multiplexing of all those twenty logical channels of communication onto a single X.25 connection. This would not affect the volume charges, but would effectively eliminate the holding charges, resulting in a halving of the total cost to about 30 pence per minute. This is one of the functions performed by the OSI Transport Layer (in classes 2, 3, and 4): multiplexing. Multiplexing in the Transport Layer is in principle no different from multiplexing in the Network Layer: it involves tagging each message with an identification of the logical channel (transport connection) it relates to, transmission over the shared carrier (the single network connection), and separation at the receiving end. Figure 5.2: Transport layer multiplexing shows multiplexing of four channels onto a single network connection carrier.

5.5 Bandwidth improvement

Again, we recognise that, for better or worse, standards for compression are not a part of the OSI Transport Layer. So how do we improve bandwidth?

The recognition here is that it might be possible to establish multiple network paths which are wholly independent (different links at the two ends, different networks involved) but which can be used together to provide what appears to the application as a single communication path whose bandwidth is the sum of the individual paths.

Figure 5.3: Transport layer splitting shows a single logical path being split between four carrier paths. If the Transport Layer part of figure 5.3 is turned upside down, it looks remarkable like figure 5.2, so this technique is often called downwards multiplexing. The necessary features in the protocol are, however, very different. The problem with downward multiplexing is that packets sent in sequence (alternately say) on the two paths will not necessarily arrive in sequence at the receiving end, due to delay variations. Thus there is a requirement to number each message and to resequence at the receiving end. This requirement is, however, no different from the requirement to resequence messages that have got out of order because a connectionless Network Service is being used. Thus support for bandwidth improvement is indistinguishable from support for error recovery when operating over the connectionless network service.

5.6 Recovery from signalled errors

This is a feature which relates only to the connection-oriented service. The connectionless service has only the N-UNITDATA primitives, and does not provide any signalling of loss.

In many countries, the introduction of X.25 in the late 1970s produced an initial service in which unreliability and overload in the network switches produced a relatively high frequency of network- generated N-RESET primitives (signalling loss of data, but with the connection intact) and of N-DISCONNECT primitives (signalling loss of a connection). If you were using the connection for a terminal login session, the loss of data was usually fairly easily recovered, but the loss of the connection meant you were usually forcibly logged out, with all that that implies in terms of loss of work in progress. Providing protection against such transient network failures seemed like a high priority. Today, the reliability of PTT-provided X.25 services is generally much higher, and in many countries network-generated resets and disconnects hardly ever appear. Nonetheless, private networks can still be configured in such a way that overloads are frequent, or can be based on older equipment where hardware reliability is poor.

Protection against such signalled errors requires the numbering and storage of every message that is sent, with discard of the stored message when its receipt at the remote end-system has been acknowledged. Following a network-generated reset (or after reestablishing the connection on a network-generated disconnect), when messages may have been lost, a simple exchange can determine which messages to resend, and the communication continues with the break largely invisible (except for a possible time delay) to the application. There are no retransmissions on timers: action is taken to see what has been lost and retransmit only when a signalled N-RESET or N-DISCONNECT occurs.

One of the more sophisticated features of the Network Service is the provision, within that service, for so-called end-to-end acknowledgement of data (the D - for delivery - bit of X.25, mapping into the N-DATA-ACK service primitive). If the D-bit is used, the network layer signals acceptance of a message if and only if it has been accepted by the Transport Layer of the remote end-system, not just by the nearest network node. This provides a ready means for discarding stored messages without introducing additional message exchanges in the Transport Layer. Unfortunately (from the point of view of the Transport Layer), the D-bit facility (the N-DATA-ACK service primitive) is optional in the Network Service. Thus the Transport Layer protocol needs to be able to provide explicit acknowledgements if the N-DATA-ACK is not supported on this communications path.

Transport Classes 1 and 3 provide recovery from signalled errors using this approach.

5.7 Recovery from unsignalled errors

This requirement produces the most complicated protocol features. The errors being addressed here are loss of messages and reordering of messages - precisely the sorts of error that are a characteristic feature of the connectionless network service. Thus only those classes (and in fact it is only one class - TP4) that support this feature are capable of being used over the connectionless network service. In addition to numbering and storing messages, the lack of any concept of a D-bit in the connectionless service makes it necessary to transmit explicit acknowledgement messages (which of course may get lost due to error or overrun!), and to set timers running with retransmission when material is not received. This protocol is also characterised by a "heart-beat" transmission based on the expiry of an idle timer. If the protocol is operating over the connection-oriented service, it takes no account of N-RESET and N-DISCONNECT primitives, nor is any use made of N-DATA-ACK: "recovery" takes place only when a message has been unacknowledged for too long, and an attempt is made to re-establish a lost network connection only when the connection is needed to transmit or re-transmit data.

The resulting protocol (TP4) is considered by many to be both complex and also expensive on network bandwidth, particularly if used when it is not in fact needed (for example, over a reliable PTT-provided X.25 connection). Nonetheless, it is the only protocol that can cope with the connectionless network service, and is capable of being used over a connection-oriented service as well, and hence it provides the realistic option for those wishing to implement only a single class of transport protocol.

5.8 Extra error detection

There is a potential problem with the error detection features provided in the lower layers. These are based on the Data Link Layer's so-called cyclic redundancy codes (CRCs). No matter how good the CRC is at detecting errors, the fundamental problem with this approach is that errors are detected only if they occur on an actual link. Thus a CRC is calculated and appended to a message on transmission, checked on reception, and recalculated for what is usually a slightly changed message (header fields often change from link to link) before transmission on the next link. Errors which are introduced due to bus or memory failures within the network node thus go undetected. Again, in the late 1970s, when OSI was developing, computers used for network nodes often had less inherent internal error detection circuitry than the main-frames that formed the end-systems. Thus there was considerable attention on trying to provide an error detection capability that was as reliable as the communicating end-systems.

The connectionless internet protocol (the main protocol supporting the connectionless network service) made some attempt to address this problem. It required that, if the header of a message was modified by a node, the redundancy check information was not recalculated from scratch, but rather was amended in accordance with the amendment made to the header. This makes undetected errors less likely, but still possible. The necessary cure is to generate redundancy check information using only that part of the message that should be transmitted unchanged end-to-end, to carry that redundancy check information with the message transparently through the network, and to check it at the receiving end-system. This feature is provided only in TP4, which again strengthens the case for TP4 implementation.

5.9 Packaging into TP0 to TP4

What then are the main characteristics of the TP0 to TP4 Standards? (Refer again to figure 5.1) TP0 is a very very simple protocol. Apart from identifying itself in connection establishment, it is a do-nothing protocol. Each request for a transport connection involves the establishment of a single new network connection, and messages received as T-DATA requests from the Session Layer are passed as N-DATA requests to the Network Layer, unchanged. TP0 is even more basic than that. Because fielding network-generated N-RESET messages is the job of the Transport Layer, there is no corresponding T-RESET primitive defined in the Transport Service, so if an N-RESET indication is received, TP0 has no choice but to generate an N-DISCONNECT request to drop the network connection, and to signal upwards a T-DISCONNECT.

There is one other problem with TP0. In the early discussions on the definition of the connection-oriented Network Service, that part of X.25 which supported N-EXPEDITED (messages that bypass flow control in a non-destructive manner) - the so-called X.25 INTERRUPT packet - carried only one octet of user data. It was determined that, because of the need to carry headers for upper layers, a minimum requirement for the N-EXPEDITED primitive was 32 octets of user data. At the time, it looked as if X.25 (1980) would not be changed, but there was a strong "political" lobby for the Network Service to be completely supported by X.25, so the N-EXPEDITED service was made an optional feature of the Network Service, and TP0, the do-nothing service, was designed to make no use of N-EXPEDITED. This means that, with TP0 in use, even though X.25 did eventually modify the INTERRUPT packet to support N-EXPEDITED with 32 octets of user data, the T-EXPEDITED service primitive cannot be used. This has some important knock-on effects on the upper layers, which will be discussed later.

Turning now to TP1: the TP1 protocol provides for recovery from signalled errors (N-RESET and N-DISCONNECT indications) as described above. It provides a simple and low-overhead option for operation over the connection-oriented network service when the rate of signalled errors is too high for TP0 to be a reasonable option. If an N-DISCONNECT indication appears, and the connection cannot be reestablished in a reasonable (agreed by the two ends) time (a bulldozer has gone through the line), then a T-DISCONNECT indication is issued. TP1, by contrast with TP0, is a "respectable protocol", in that it fully supports and maps T-EXPEDITED. If N-EXPEDITED is not available, or if the D-bit is not available, then TP1 will introduce its own acknowledgement messages in order to provide acknowledgements and its own flow control. By never exercising Network Layer flow control, it can provide support for T-EXPEDITED even if N-EXPEDITED is unavailable.

Transport Protocol Classes are not hierarchical. The next in sequence is TP2, but this does not provide the functions of TP1. TP2's sole function is the provision of multiplexing (the cost reduction discussion). If TP2 is in use, a new logical channel can be added to the logical channels using a network connection without any disruption to any existing channel. However, if an N-RESET or an N-DISCONNECT indication appears, a T-DISCONNECT indication is issued on all the multiplexed channels. Thus in circumstances where such indications are a frequent occurrence, any cost-savings in TP2 may be more than balanced by the increased disruption that such indications cause.

TP3 is simply a combination of the features of TP1 and TP2 - multiplexing and recovery from signalled errors.

TP4 is the all-singing all-dancing protocol described above which will operate over a connectionless or connection-oriented service, provides multiplexing of multiple transport connections onto a single network path, can map onto multiple network paths (downward multiplexing), ignores signalled errors, and detects and recovers from lost, out of order, and corrupted messages. TP4 does, however, have some problems, the most significant being its treatment of expedited data. The "rules" written into the Reference Model require that whilst expedited data may overtake normal data, normal data should never overtake expedited data. When expedited is provided within a connection-oriented service in which all messages are sequenced, simply as a relaxation of flow control rules, then this is clearly and easily achieved. When, however, an attempt is made to support expedited data in the Transport Layer over a connectionless service, it is somewhat harder to guarantee that a later normal message will not arrive ahead of an expedited message, due to them taking different routes. TP4 solves this problem by delaying the transmission of subsequent normal data until receipt of any expedited data has been acknowledged by the receiving end-system. This introduces an effective round-trip-time blockage on the normal flow whenever expedited data is sent. The problem does not arise in any other Transport Class. This property leads some experts to oppose protocol options above the Transport Layer that make use of expedited data, and particularly to oppose use of the Session Layer major synchronization primitives that are described later.

5.10 Interaction with Teletex

One of the major developments within CCITT in the late 1970s was the development of the Teletex service, with the definition of the relevant protocols to operate over X.25.

Teletex was intended to provide a similar service to the rather ancient Telex, but with a much broader character set, and operating over normal (X.25-based) public data networks, rather than requiring a dedicated network.

Whilst today their are few people who would argue that Teletex compatibility is an important requirement for anything, in the late 1970s and early 1980s there was an important and powerful lobby for such compatibility. In particular, there was (in relation to the Transport Layer) a desire to be able to rewrite the specification of S.70 (now T.70) in terms of the issue of T-service primitives, in such a way that the actual bits transmitted down the line in the use of X.25 would be identical to the existing specification.

The Teletex Transport Protocol was essentially a do-nothing protocol, with the only added value being extra parameters in the connection establishment messages for further addressing fan-out within end-systems. It made no use of expedited data. The TP0 protocol was specifically designed to provide the requested Teletex compatibility, and it was this as well as the decision to make N-EXPEDITED optional (see the earlier discussion) that led to TP0 not supporting the T-EXPEDITED primitives.

There was a further problem. If the Transport Layer is going to work by having all classes of protocol implemented by most systems, with the appropriate protocol "plugged in" for each connection, then there has to be an agreement between the two end-systems on what is "the appropriate protocol" to plug in. This requires parameters in the initial connect messages to offer and agree one of the classes (class negotiation). Such a feature was not, of course, present in the Teletex protocol, that had just the one class, so negotiation of classes cannot be bit-compatible with Teletex. The Standards permit an implementor of class 0 to handle zero only, and not to negotiate, to cope with Teletex, but implementation of full negotiation is nonetheless recommended to allow full open working with non-Teletex systems.

5.11 Implementation of Transport Classes

In the ideal world, all classes will be implemented by all end-systems. Deployed systems in the 1990s do not, however, represent the ideal world. Pressure to get OSI products onto the market quickly have led to selection of a single Transport Class for initial implementation, and selection of specific classes in procurement profiles. Purchasers of OSI products should look carefully at the Transport Classes that have been implemented or are promised for implementation. The different classes do not interwork. Even in the case of TP3 versus TP1 and TP2 (where each of TP1 and TP2 is a subset, functionally, of TP3) an implementation of TP3 alone will not interwork with an implementation of TP1 alone. This is even more true for TP0 and TP4. The views of the Encyclopedia Galactica - 20085 version are given in figure 5.4: Encyclopedia Galactica, p31945.

The ISO Standard and the CCITT/ITU-T Recommendation both contain conformance clauses requiring specific classes to be implemented (in order to try to ensure interworking), but in this area the desires of the two groups (ISO is broadly the club of computer vendors, and CCITT/ITU-T is broadly the club of the PTTs) diverged, and different text appears. In Recommendation X.224, implementation of TP0 is mandatory. All else is optional. In ISO 8073 implementation of either TP0 or TP2 is mandatory, with a fairly complex set of rules which say, in particular, that if TP4 is implemented, then TP2 shall be implemented.

If we turn to the GOSIP specifications (Government OSI Profile), which specify requirements for government purchases, we find (slightly confusingly) a USA GOSIP and a UK GOSIP. These differ significantly in coverage, have totally different text even in common areas, but more importantly express differing requirements in some important areas. Transport Classes is one of these. USA GOSIP requires TP4, but recognises TP0 for connection to a PTT X.25 public network, and recommends TP2 because that is a requirement of the ISO Standard if TP4 is implemented. By contrast, UK GOSIP requires TP0, but recommends TP2 again for ISO conformance.

What is happening in practice? Interest in TP1, 2, and 3 is minimal. Many implementations support either TP0 (particularly over X.25) or TP4 (particularly over the connectionless Network Service), and frequently little or nothing else. Note also that TP4 over the connectionless Network Service over an X.25 tunnel is a very different protocol from TP4 over the connection-oriented Network Service over individual X.25 virtual circuits. Implementation of the latter is very much less common than implementation of the former. At this point the reader is cautioned that situations like these change quite rapidly, and that in this area the above discussion may soon be little more than a description of past history. Nonetheless, the issues were very real ones for procurement in the 1990s.

5.12 Selection of classes for an instance of communication

Let us assume the best possible scenario:

  • all network switches (nodes, intermediate systems) support protocols on each of their links to other intermediate systems which permit that link to form part of an end-to-end connectionless path or to form part of an end-to-end connection-oriented path;
  • all end-systems similarly support connectionless or connection-oriented communication with each of the intermediate systems that they are connected to;
  • all end-systems support all Transport Classes, including TP4 over both the connection-oriented and the connectionless Network Service.

It is important here to remember the "Internal Organization of the Network Layer": the connection-oriented Network Service can be supported by an X.25 link with no additional protocol over X.25, and with one X.25 virtual circuit for each Network Service connection; the connectionless Network Service can also be supported by an X.25 link using what is termed "tunneling through", where a single X.25 connection is opened up when needed to transmit traffic to that intermediate system, and closed down when there is no traffic. Both uses of X.25 are fully standardised and implementable. In the same way, a simple link to a router can be used to pass connectionless traffic in a straightforward manner, but can also be used to carry the X.25 protocol to support the connection-oriented service. Thus the above assumption that any route which works for connection-oriented will work for connectionless is not an impossible one.

Having said that, deployed intermediate systems today usually either:

  • handle connectionless traffic (received from a dedicated line, from Ethernet, or from an X.25 public network interface) using the Connectionless Internet Protocol on all links, and "tunnelling through" X.25; or
  • handle connection-oriented traffic (received from a dedicated line, from Ethernet, or from an X.25 public network interface) using the X.25 protocol over the dedicated line and the Ethernet;

They do not normally do both. Similarly, end-systems packages will often support only the connection-oriented use of network interfaces and links or only the connectionless use of those interfaces and links. In both cases, however, the situation is rapidly changing in the mid-1990's, with a number of intermediate systems and end-system packages becoming available that have the dual Network Service capability. This situation can be expected to increase, and our scenario essentially says: "Let us assume that the choice of which Network Service and which Transport Class to use is not dictated by which have been implemented, but rather by which will get us to a particular end-system, or which is possible through a particular set of routers: all are available."

What then are the pros and cons? The advantages and disadvantages of running an end-to-end connection using the connection-oriented approach as opposed to using the connectionless approach is something on which there is no general agreement. It frequently becomes a religious war, and can also get confused with the TCP/IP versus OSI debate, where OSI is frequently equated to X.25 (connection-oriented) and TCP/IP uses the connectionless approach. (The reader of this text should by now recognise that OSI should not be equated to X.25, and has both approaches firmly established within it).

Here are some points (some almost contradictory) which some people will argue strongly for (but others will argue that they are either not true or not important!). It is hard to make a reasoned technical judgment:

  • Connectionless networks are more robust in establishing new routes if links or nodes go down.
  • Connection-oriented networks degrade more gracefully if loss of nodes or links produces a major traffic overload on the remainder of the network.
  • Loss of messages is recovered with at worst about a single-link round-trip delay in the connection-oriented case, but can require an end-to-end round-trip delay in the TP4 over connectionless case.
  • TP4 over connectionless works well with traffic losses of up to 5%, but degrades badly (in terms of throughput and delay) at higher traffic losses. The connection-oriented approach (because recovery is done on a link by link basis and flow control prevents loss due to overrun) performs better in lossy and congested situations.
  • In pure connection-oriented (relaying using the OSI Network Service mapping from link to link) as opposed to real X.25 networks (where additional protocols operate) the route taken by a connection is established once and for all at connection-establishment time, and loss of a link or node produces an N-DISCONNECT indication to both ends and requires major end-to-end action to reestablish a new connection on a different route. In the connectionless case, routes are dynamically established on a per-packet basis, and loss of a node or link at worst produces loss or duplication of a small number of packets.
  • Highly dynamic routing protocols to support the automatic dissemination of routing information to intermediate systems have been developed to support the connectionless network service, and routing for connection-oriented has in the past tended to be based on human configuration of relatively static routing tables.
  • There is no reason why routing techniques developed for connectionless traffic should not be used to route connections, and increasingly implementations supporting both approaches will use dynamic routing techniques and a single routing table for both sorts of traffic.
  • The basic protocol for connectionless communication is much simpler and cheaper to implement than that for X.25 (because of the additional flow control and error recovery), and runs faster on cheap routers.
  • The full Connectionless Internet Protocol is at least as complicated and slow to run as X.25 because of its fragmentation and reassembly capabilities, per-packet routing based on quality of service optimization, and notification of discard.
  • The cost (in terms of network traffic/charges and in terms of end-system CPU utilization) of running TP4 over the connectionless network service and tunneling through a PTT's X.25 network for a single transport connection to a remote end-system on that PTT's network is very much higher than supporting that transport connection with TP0 directly over X.25.
  • If a PTTs X.25 network is being used to link two Ethernet sites, with a large number of independent connections running from different end-systems at one site to different end-systems at another site (see figure 5.5: Multiple communications over X.25), the connection-oriented approach requires a separate X.25 virtual circuit for each connection (TP2 and TP3 can't help in this case, because the end-systems are all different), whereas the connectionless approach with TP4 automatically multiplexes the traffic over the PTTs X.25 network onto a single X.25 virtual circuit, reducing costs;
  • TP4 over connection-oriented has slight CPU-usage advantages over TP4 over connectionless over an X.25 interface, but these are small and unimportant.

So where does that leave us on selection of transport classes? If both end-systems are directly connected to a PTT's reliable X.25 network, the simplest option is TP0, and it should be selected if there is unlikely to be another (simultaneous but independent) connection required between the same end-systems. If more than one connection is likely, then using TP2 does not add a great deal of complexity, but does allow the same X.25 virtual circuit to be used for all connections, and hence gives cost savings with many PTT tariffing systems.

By contrast, if a PTT's network is used by a pair of intermediate systems to handle traffic between them, and that traffic is the result of a number of transport connections running between different end-systems, then TP4 and connectionless is likely to produce cost savings.

If a PTTs network is not involved, then the choice is less clear cut, and the general points made above about connectionless versus connection-oriented become more prominent. If the connectionless approach is taken and the path is predominantly one of linked X.25 (private network) connections, then this probably involves unnecessary CPU cycles and network traffic compared with the connection-oriented approach, perhaps using TP1 or TP3 if one of the linked X.25 networks is a bit unreliable.

Use of TP4 over the connection-oriented Network Service will provide advantages over TP1 or TP3 only if there is a significant unsignalled corruption or loss of packets, as opposed to network generated resets and disconnects.

Little more can be said. It is one thing to act as God (full knowledge) to determine the "best" choice in particular circumstances, it is a somewhat different matter for an end-system to obtain enough knowledge about the possible network paths to an intended destination in order to make sensible decisions.

For a sending implementation requested to make a new transport connection to an end-system, the decision-taking process might go as follows (see figure 5.6: Choice of transport protocol class):

  • Do I have an existing TP2 or TP3 connection to this end-system? If so, it is probably sensible to add this new connection into the existing multiplex, provided the quality of service matches reasonably that requested for this transport connection, otherwise ...
  • Should I attempt to use connectionless traffic, or should I establish a new network connection to this end-system? This will bring in most of the considerations above. If the decision is connectionless, then we use TP4 and that ends the matter, but if the decision is connection-oriented then ...
  • We establish a network connection, requesting a quality of service based on what is required by the application, and note the actual quality of service parameters returned. Based on the actual quality of service parameters and/or some in-built knowledge, we can decide whether we need TP1 or 3 for reliability, or maybe even TP4. We can also decide (again based on in-built knowledge) whether we are likely to want another connection to the same end-system, and if so whether network charges would be reduced by use of TP2 or TP3 instead of TP0 or TP2 with the further possibility of using TP4.
  • We further decide which other classes to offer as alternatives. If we have implemented them all (which we are assuming), we list as alternatives all other classes, or maybe we exclude only those that we know will be unworkable (for example, if we know the path is unreliable, the other end-system might not, and we should avoid offering TP0 or TP2).
  • The Transport Layer connect packet is then despatched (using an N-DATA request), and the remote end-system then goes through a similar process to determine whether to accept the class we said we preferred, or to accept one of the alternatives we offered, or to reject the connection.
  • If the transport connection attempt fails (using connectionless network service or using connection-oriented), we can then decide to retry the transport connection establishment using the other form of network service, or using a different selection of classes over the connection-oriented service. (This really applies if our scenario is not wholly true: network routes may only be possible using connectionless or only possible using connection-oriented, or the remote end-system may only have implemented some Transport Classes.)
  • Eventually we have a transport connection, or have decided to give up!

The above sounds pretty horrendous. Computer software would be hard to configure to take these sorts of decisions in a sensible manner. It is, therefore, not surprising that people tend to say: "To hell with it, if we are going out over an X.25 link we will use TP0 over connection-oriented, and otherwise we will use TP4 over connectionless. It may not be optimal, but it is simple!"

Where it is known that certain heavily-used end-systems have paths for which one of the other options is the best, these can be built-in specifically and relatively statically as a selection table. The situation is, of course, further complicated by the knowledge that, at the present time, some end-system connectivity can only be obtained using connectionless, some only using connection-oriented, and by differing recommendations from profiling and procurement groups. Deployment of the Interworking Unit of TR10172 (described in 4.2) may be the only option.

5.13 The OSI Transport Service

The formal definition of the Transport Service as a set of primitives parallels very closely the Network Service Definition, which is not surprising as the main purpose of the Transport Layer is Quality of Service improvements, not the introduction of new types of service. In fact, the Transport Service Definition is actually significantly simpler than the Network Service Definition for two reasons:

  • The end-to-end versus link-by-link acknowledgement of the Network Service (the N-DATA-ACK primitives) is there largely to support TP1 and TP3, and has no equivalent in the Transport Service.
  • The N-RESET primitive is there to support partial failure of the network. Recovery is either undertaken by the Transport Layer, or, if this is not possible (TP0 or TP2 in use), a more serious "disconnect" failure is generated. Thus N-RESET is also absent from the Transport Service.

All this makes the Transport Service the slimmest, simplest, and cleanest of all the layer services. In the description below of the mapping of T-service primitives to N-service primitives, the use of the connection-oriented Network Service is assumed. Where the connectionless Network Service is in use, all primitives map to N-UNITDATA. The Transport Service consists of:

  • The T-CONNECT request, indication, response and confirm primitives (with corresponding protocol messages carried in N-DATA primitives) used to negotiate the Transport Class and to set up a connection (including adding a new connection to a multiplexed set of connections). It carries 128 octets of user data, but the user data is not used by the OSI Session Layer protocol.
  • The T-DATA request and indication primitives (also carried in N-DATA, with a header octet to distinguish this usage of N-DATA from that supporting T-CONNECT, and with some extra parameters in those classes that need to number messages, perform acknowledgements, add flow control, and so on) which has a single parameter that is unlimited user data. (Note that the Transport Protocol provides segmentation, and segment sizes are negotiable. If one end-system requests 128 octet segments in the protocol, then the other end-system has to accede. This means that implementation of segmentation in the Transport Layer is mandatory: if 128 octet segments are negotiated, then under normal X.25 operation there will be no use of the M-bit for segmentation in X.25 level 3.)
  • The T-EXPEDITED-DATA request and indication primitives used to carry data which non-destructively bypasses flow control. Where N-EXPEDITED-DATA is available, the T-EXPEDITED-DATA maps to N-EXPEDITED-DATA, otherwise it is not available (TP0) or is mapped to N-DATA, with flow control within the transport protocol. It carries up to 16 octets of user data.
  • The T-DISCONNECT request and indication primitives that are used to tear down a connection when it is finished with. This is a destructive service, and will bypass flow control and cause the discard of any data not already delivered. These primitives, like the T-CONNECT primitives, also carry 128 octets of user data.

In order to understand fully the Session Layer, two points should be noted about the Transport Service. These are discussed below.

First, it is a two-way simultaneous service, with normal data and expedited data flowing in both directions, with normal data not overtaking normal data, expedited data not overtaking expedited data, normal data not overtaking expedited data, but expedited data possibly (but not necessarily) overtaking normal data. (See figure 5.7: Transport service for data transmission)

Whilst the OSI Transport Service is frequently equated with the service provided by TCP in the TCP/IP suite (with TCP being functionally very similar to TP4 - but certainly not bit-compatible), there are some significant differences in detail, one of which relates to expedited data. The roughly equivalent concept in TCP is urgent data. Urgent data can be submitted when flow is blocked, but it does not overtake normal data. To obtain it, the receiver must read (and store or discard) all earlier normal data. What TCP does provide is a notification (effectively a single bit) that there is urgent data stacked up waiting to be read. If the OSI Session Layer had been built on the TCP-style of service, it would have been very different: not necessarily better, not necessarily worse, but different. There are specifications of how to map protocols designed for OSI onto TCP, and vice-versa, and there are even implementations of OSI stacks on top of TCP. The differences between expedited and urgent are usually not properly covered, but as most applications (in both TCP and OSI) make little or no use of these services (and if they do they are in unusual circumstances) the differences tend not to be critical.

The second point to make is the disruptive nature of the disconnect primitives. If a disconnect is issued, earlier normal or expedited data can potentially be overtaken and is discarded. Equally, messages in the reverse direction may have been issued, but will never be received due to the issuance of the disconnect. (See figure 5.8: Destruction of data by T-DISCONNECT). It is also possible for two disconnects issued by the two ends of the connection to collide inside the network (or within lower layer handlers), and to mutually cancel each other with non-delivery of the user-data carried by them, or for a disconnect to collide with a network-generated disconnect and mutually cancel, with one side seeing only a disconnect issued with user data and the other side seeing only a network-generated disconnect. (See figure 5.9: Collision of disconnects). Thus the issuing of a disconnect is somewhat fraught with problems, and usually needs to be preceded with some form of "Have we finished?", "Yes, we have", "OK, I'll disconnect" dialogue to provide what is usually called an orderly termination for the application's dialogue. In TCP, there is added functionality to provide orderly termination as well as disorderly abort that is missing in the ISO service. (It is added by the OSI Session Layer).

5.14 The Connectionless Transport Service

The Connectionless Transport Service is normally seen as a simple passing through (much as TP0 passes through the connection-oriented Network Service) of the connectionless network service, with little added value. There is just one service: a T-UNITDATA request and indication primitive.

There are, in fact, two main pieces of added value. The first is some additional addressing information that can provide fan-out within the end-system (called the transport selector). Addressing selectors exist in both the connection-oriented service (when they appear as parameters on connect primitives) and in the connectionless service (when they appear as added parameters with every data message - the UNITDATA request and indication primitives) in all the three middle layers. The need for this wealth of addressing information and their general function is described later.

The second piece of added value is the addition of an end-to-end checksum in TP4 to provide protection against undetected corruption of messages in the network. The Connectionless Internet Protocol provides a checksum on every message, but that protects only the header information, not the up-to-64K (about) of user data. Detection of any corruption of the user data relies either on error detection (and perhaps correction) by the sub-networks carrying the CLIP message, or on the end-to-end checking of the Transport Layer. If errors are detected, the message is simply discarded, and it is invisible to both users of the Transport Service whether discard occurred in the Transport Layer for this reason, or at a lower layer, or by complete loss within the network.

<< >>