Packetizer Logo
Understanding OSI

6 Dialogues and all that

6.1 Overview of the Session Layer

Having spent a lot of time thinking about service improvements on the QOS of the Network Service (by some error correcting protocol), it requires a mind-shift to appreciate the Session Layer. Here we are not concerned with errors, reliability, or multiplexing. If such concerns cannot be adequately addressed by the standards of the Transport Layer, they go unaddressed. In this layer and all the above layers, we assume that the reliability of the communications path provided by the Transport Layer is as good as we need, or at least, as good as can be obtained by end-system protocol exchanges. The only failure we will see is a T-DISCONNECT indication, but it is important to realise that that can occur at any time, with loss of data in transit in both directions - this cannot be prevented, and application designers have to be prepared for it.

What we can hope to do, however, is to control the issuing of disconnects (provision of orderly termination), except when they are the result of a network generated N-DISCONNECT or N-RESET that the Transport Layer cannot resolve: these latter occurrences should be infrequent if we are using an appropriate Transport Class, but cannot be totally eliminated. In the Session Layer they are called aborts. Thus in the Session Service, there is no mention of "disconnecting". Instead we speak of releasing the connection (or orderly termination) and of aborting the connection (or disorderly termination).

This is one example of the sort of problem that might have faced application designers who had to design a protocol to support some application if there were no Session Layer, and they had to design a direct interaction with the Transport Layer. Thus an important focus of the rest of this discussion on the middle layers (and a part of the discussion on the application layer) is an attempt to answer the question: "If I am asked to design a protocol to support a distributed application in my own specialised domain of knowledge, what facilities/tools are available to me beyond opening a connection, transmitting octet-string messages in both directions, and disconnecting?"

So we ask ourselves: "Given the nature of the Transport Service, what might application designers have to worry about that is not really anything to do with their application? What sort of tools might be wanted?" The broad answer, given earlier, is "dialogue control and dialogue separation", we now need to cover this in some detail.

We have already touched on some possible problem areas when discussing the Transport Layer, and in the earlier discussion of the Session Layer when we were concerned with the overall OSI architecture. The main points to be discussed further in this section are:

Before ending this overview, it is important to recognise that the session layer is not really a single monolithic protocol. Rather it is an almost random collection of largely independent service primitives, each of which invokes a quite limited exchange of messages over the Transport Service and represents one particular tool that is available for use by an application designer. These service primitives (and the corresponding messages) are grouped into what are called functional units, and at the start of a session connection there is agreement on the functional units to be used on that connection.

In the case of the simplest possible use of the session layer by an application designer, the only primitives used are S-CONNECT, S-DATA, S-P-ABORT (P for provider - an upcoming T-DISCONNECT), and S-U-ABORT (U for user - a disorderly termination by one or other user), mapping simply and directly to the corresponding Transport Layer primitives with little added value and little complexity for implementors.

In addition to this set of primitives (called the kernel functional unit - actually the kernel includes one other, discussed later), an application designer makes a conscious choice that some (or none) of the other functional units of the session layer (negotiated release of the connection, token control of data transfer, the expedited service, minor synchronization, etc) are useful in support of his application, and obtains the required functionality by specifying that the corresponding service primitive be issued.

The alert reader will be beginning to ask the question: "How can application designers specify that a Session Service primitive is to be issued when the Presentation Layer is between them and the Session Service?" In fact, it is a correct question. Application designers indeed cannot invoke Session Service primitives, but what they can do is invoke Presentation Service primitives that correspond in a direct and almost one for one manner to the Session Service primitives, so we can loosely talk about the issuing of Session Service primitives.

6.2 Historical development

In order to understand fully the Why? of the Session Layer, it is necessary to appreciate some of the historical background. In 1984, there was a well-developed Session Standard produced by ECMA. What is ECMA? ECMA (European Computer Manufacturers' Association) is the "club" of European computer manufacturers. However, all major computer manufacturers have some European manufacturing plant, and are eligible to become members of ECMA. Despite its name, ECMA is effectively the club of all computer manufacturers world wide, with a primary role of contributing to OSI standards development. As such, ECMA has from the beginning had a very a strong input into ISO standardization activity in the OSI area. Its influence in the development of the OSI Reference Model and of most of the main OSI standards has been strong and has far outweighed what would be expected from the name "European". There is no comparable input with any other continental title. If the reader is interested in looking at the archives of early OSI papers, the technical content of the very first input into the OSI Reference Model makes an interesting study. There were papers from the USA, from France, from Japan, from the UK, and from ECMA. Only the ECMA paper had a seven layer model, broadly similar to what eventually emerged as the standard. So in 1984, ECMA had a Session Layer Standard with most of the features we have suggested as candidates for support in the Session Layer, and there was a strong lobby for this to become the ISO Standard. Unfortunately, there was also in existence CCITT Recommendation S.62, (later to become renamed T.62), part of the Teletex suite, with an even stronger lobby for that to be adopted as the Session Layer Standard.

Teletex has already been referred to in connection with the Transport Layer, and the pressures on Session were just as great. CCITT wished to be able to re-write the Teletex specification to use the Session Service Definition, with no change to the bits on the line. This meant that the S.62 protocol had to be imported lock stock and barrel into the OSI Session Layer.

There were some areas where the ECMA work and the CCITT work were very similar, some areas where they noticeably diverged but with identical functionality, and some areas of completely different functionality. During 1984 a major effort was expended to a tight time-scale to merge together the CCITT work and the ECMA work. The result was the current ISO Session Standard. In broad terms, the protocol (and much of the terminology in the protocol) followed the S.62 specification (as it had to), with added protocol messages where appropriate to support ECMA features. The service notation more nearly followed the ECMA work, and hence there are some (unimportant) mismatches between the names given to protocol messages and their corresponding service primitives.

What was the end result? Importantly, the work was completed in a timely manner. But instead of finding just one screw-driver and one hammer in the tool-kit, the application designer finds two of each! One is ECMA derived, and one is CCITT-derived. These tools differ slightly, but not significantly, in their functionality, and there are no very good technical reasons for using one rather than the other.

The bad side effect, however, was that from that day almost to this (mid 1990s), arguments continue among application designers on whether to use "activities and two-way alternate" (the CCITT legacy) or "major synchronization and two-way simultaneous" (the ECMA legacy). This argument has been particularly important in preventing the adoption of common building blocks for bulk data transfer, discussed later in the section on FTAM (File Transfer, Access, and Management), and for RTSE (Reliable Transfer Service Element).

Did the result enable the Teletex specification to be re-written using the Session Service primitives? Yes and no. When CCITT went on to develop the X.400 Recommendation, it was originally written to use Session Service primitives (the Presentation Layer was not sufficiently far developed to be usable at that stage - late 1984), but there was a strong lobby for the bulk data transfer part of X.400 (RTSE) to be compatible with Teletex. The Session Layer was sufficiently faithful to S.62 that people were able to claim that that had been achieved. In practice it is doubtful if anyone has attempted to interwork an existing Teletex implementation to an X.400 implementation, and even more doubtful that it would actually work! But what mattered was that the "political" issue was resolved (nobody today even mentions Teletex compatibility). All parties were happy to accept that, in writing X.400 to use Session Service primitives, the bits on the line would be compatible with Teletex - provided, of course, that TP0 was used, with no offering of other classes. And so we find the CCITT X.400 Recommendation requiring the use of TP0. But we must now return to the technical content of the Session Layer.

6.3 Tokens and collisions

One of the problems with designing protocols is that when an application A receives a message over the network from application B, the receiver A generally does not know whether, at the time that the message was sent by B, the state of the sender B was based on the most recent message sent by A, or whether, at that time, the most recent message had not yet been received. In many cases of protocol design this can produce uncertainty and complications, and failure to analyze fully such collision cases can be one of the greatest sources of errors in protocol design.

A similar problem can arise in implementation of protocols which use two way simultaneous transmission: the implementation does not know whether to wait for a queue to become free to transmit a message, or whether to wait for a message to arrive. Put another way, the operating system interfaces have to permit the implementation to be able to handle the two partially-independent processes of sending and receiving at the same time, in a way which does not soak up CPU cycles. In languages and systems with a well-developed process concept and with an interrupt capability, this generally poses no problems, but with simpler systems and languages a protocol based on two-way simultaneous traffic can be difficult to handle.

A solution to both problems is to use the communications medium in a strictly two-way alternate manner: application A transmits a series of messages, identifies the end of the series of messages, then waits for messages to come in; application B waits for received messages and processes them until it receives the message identifying the end of the sequence and then proceeds to transmit a series of messages in reply, again identifying the end of that sequence. Thus the right to send alternates between the two applications, and we say that they "pass the turn" between them. If an application designer wishes to work in this sort of way, then managing that two-way alternate dialogue needs to be planned out, and standardization of messages and functions (and hence service primitives) to support such a mode of operation is one of the functions of the Session Layer.

Of course, where round-trip times between A and B are long, this can be a very inefficient way to work, and it would be better to design a protocol using two-way simultaneous transmission, and to put the effort in to get it right and to implement it using an appropriate infrastructure. The decision of which approach to take has to be the application designer's, and the Session Layer therefore provides both the option of two-way simultaneous (TWS) operation (effectively a do-nothing Session Layer in this regard) and also the option of two-way alternate (TWA) operation, in which protocol messages (supported by Session Service primitives) are defined to allow management of the two-way alternate dialogue.

The Session Layer Standards use the concept of a data token. This is a conceptual token that gives the right to transmit data (to issue the S-DATA request primitive). At the start of a session connection, there is agreement on whether to operate in two-way alternate mode or not (this cannot later be changed - perhaps a mistake in the design), and if so, where the token is to be positioned initially. Thereafter, if you have the token, you can issue S-DATA requests, and will not get any S-DATA indications. You can pass the token by issuing an S-TOKEN-GIVE request (resulting in an S- TOKEN-GIVE indication at the other end of the communications path). If you do not have the token, you can request it with an S-TOKEN-PLEASE request (which produces a corresponding indication). The receiver of an S-TOKEN-PLEASE indication may completely ignore it (this is an unconfirmed service), or may respond with an S-TOKEN-GIVE request, perhaps after completing some set of transmissions related to current operations.

The above text implies some degree of "free-will" on the part of the application. What it really means is that what happens is not determined by the Session Layer. The application designer may (and often will) completely determine when an S-TOKEN-GIVE request or an S-TOKEN-PLEASE request are to be issued, and the action to be taken on an S-TOKEN-PLEASE indication. Equally, application designers may determine that, for their application, there is no useful purpose served by S-TOKEN-PLEASE, and that primitive will never be issued or received. This discussion has again illustrated the "tool-kit" nature of the Session Layer.

Once a token concept has been introduced, it can be used for other purposes to help avoid collision problems in the operation or use of the session layer itself. Thus in addition to the data token described above, there are also tokens call the minor synchronization token, the major/activity token, and the release token. These are described in more detail in the relevant section below.

Using the S-TOKEN-GIVE primitive, one or more of the tokens held by an application (including all of them) can be passed to its peer. The Session Service also, however, contains an additional primitive (and a corresponding protocol message) which passes all tokens that are held. This is the S-CONTROL-GIVE request and indication. This is, of course, an example of having two almost identical screw-drivers in the tool-kit - a consequence of the ECMA and Teletex merger (S-CONTROL-GIVE is largely there to support Teletex). However, it is important for the reader - a potential application designer - to recognise that whilst passing all tokens using S-CONTROL-GIVE or using S-TOKEN-GIVE may be identical as far as the Session Layer is concerned, it is perfectly permissible for the application designer to carry different application semantics (different meaning at the application level) to these two ways of passing tokens. In principle, S-TOKEN-GIVE could be restricted to pure session semantics - passing tokens for the right to transmit certain session primitives - whilst S-CONTROL-GIVE could transfer rights to initiate some very application-specific actions. This is one of many examples in the session layer where there are primitives whose effects in terms of the session layer itself are identical, but where, because they are different primitives, they provide the opportunity for signalling different application semantics associated with the same session effect.

6.4 Orderly termination and negotiated release

We have already discussed at some length the problems of disorderly termination - the uncontrolled issuing of a T-DISCONNECT. The session layer provides two orderly release mechanisms, both supported by the S-RELEASE request, indication, response, and confirm primitives. In the simplest case (the facility in the kernel functional unit), the Session Layer provides a very simple exchange. Application A issues an S-RELEASE request to its Session Layer with the semantics "I want to end this connection as soon as possible in an orderly manner", and ceases all transmissions (but still receives any incoming material). The Session Layer then uses a T-DATA transmission to provide delivery of an S-RELEASE indication to application B, which then completes any further data transmissions (normal or expedited) that it considers appropriate before issuing the S-RELEASE response to its Session Layer with the semantics "OK I am done, you can disconnect when you get this". Again T-DATA is used to transmit the corresponding session message, causing an S-RELEASE confirm, and the session layer supporting application A would then normally issue a T-DISCONNECT. This exchange is shown in figure 6.1: S-RELEASE handshake, and it can be seen that there is no data in transit in either direction when the T-DISCONNECT is issued, so orderly release has been achieved.

There are a few problems with this basic mechanism, and a few additional observations to make. First of all, it may be useful to retain the transport connection for future use for another session connection (perhaps for another application). This is, of course, invisible to the application, and is not shown in the Session Service Definition. It is, however, part of the session protocol supporting S-RELEASE that there is negotiation in the S-RELEASE exchange of whether to retain the transport connection for possible reuse or not. (The session implementation where the S-RELEASE request was issued says - on the message supporting the S-RELEASE request/indication - whether it is happy to have the connection retained, and the peer session implementation confirms or refuses retention on the message supporting the S-RELEASE response/confirm.) This retention of the transport connection is not permitted (an easy way of solving problems) if transport expedited is in use on this transport connection, as use of S-EXPEDITED in the following connection could, in principle and in some circumstances, arrive before the message supporting the S-RELEASE response/confirm, and hence arrive during the lifetime of the previous session connection and be delivered to the wrong application. There have been recurring discussions within the Session Layer group about "mending" this problem, and allowing retention even when transport expedited is in use, but this has not yet (1995) resulted in a change to the Standard.

The second point to make is that one cannot remove all access to T-DISCONNECT. An upcoming T-DISCONNECT indication (as a result of a network failure from which the Transport Protocol in use cannot recover) can occur at any time, and cannot be avoided. This loss of the connection has to be passed up to the application, and this is handled by the S-P-ABORT indication in the Session Service. Application designers must clearly specify the action to be taken when such an indication occurs. (As an aside, an action involving immediately reestablishing the connection is not appropriate. If such action is wanted, then the appropriate class of Transport Protocol should be used.) It is also important to allow an application designer the freedom to specify a disorderly termination, either because there is no response in a reasonable time to an S-RELEASE request, or because of the immediacy of the situation requiring termination. To support this, the S-U-ABORT request and indication primitives are provided.

Thirdly, the S-RELEASE primitives (request/indication and response/confirm) all carry user data, so the application can, for example, pass charging information as part of the release process. Of course, if the release collides with (is disrupted by) an upcoming T-DISCONNECT (resulting in an S-P-ABORT), or an S-U-ABORT is issued by the peer, the user data on the S-RELEASE will not be delivered. But that is expected. A more interesting situation arises if both sides issue an S-RELEASE request at the same time (a collision situation). The effect in the first Session Standard was as shown in figure 6.2: Collision of S-RELEASE. One of the S-RELEASE response/confirms (and its associated user data) was not delivered, because the transport connection was prematurely terminated. This illustrates the sort of problems that can arise from collisions. This was reported as a defect in the Session Standard, and a number of solutions were discussed to resolve the problem and ensure the delivery of both S-RELEASE confirms in the collision case. The result was an amendment to the Standards, using something called the rapid amendment procedures (which involve much less balloting and time than a normal amendment or revision to a standard). The amendment required the acceptor of the connection to delay the issue of an S-RELEASE response if an S-RELEASE request he had already issued (the collision case) until the S-RELEASE confirm was received, and to leave disconnection to the peer entity. The result is shown in figure 6.3: Resolution of S-RELEASE collisions, and it can be seen that both S-RELEASE exchanges now complete without loss.

We said above that what has been described is the basic mechanism. A natural extension is to change the meaning of the messages slightly so that the S-RELEASE request/indication says "I think we have finished, do you?", with the S-RELEASE response/confirm saying "Yes, we have, please disconnect", or saying "No, I would like to continue, please ignore this exchange." This is called the negotiated release mechanism. In the non-collision case, the only problem is knowing what semantics is intended (agreeing that S-RELEASE should be negotiated or non-negotiated). This is accomplished by agreeing a separate functional unit which uses the same messages as those of the kernel, but with the differing semantics, and the ability to say "No" as well as "Yes".

In the collision case, however, life is now rather more complicated. Of course, one could forbid a "No" response in the collision case, but the decision was taken to provide a token (the release token) to control the issuance of an S-RELEASE if the negotiated release functional unit was in use, preventing collisions from occurring. (Solving the above-mentioned defect in the non-negotiated case by applying token control there too was considered, but rejected as being too much of a change from the original Standard.)

The S-RELEASE primitives are an important feature of the Session Layer. Almost every application layer standard in OSI has a normal termination using S-RELEASE (usually non-negotiated).

The alert reader will have a lot of questions bubbling up. For example, if an S-RELEASE request has been issued, exactly what can you then do? We have said you cannot issue S-DATA requests, but can you (for example) issue an S-U-ABORT request? We would expect the answer to be "Yes", and indeed it is. In general, however, the issuing of a service primitive puts the service into a new state, in which the set of permitted events (primitives you can validly issue and primitives you might receive) is reduced. A detailed specification of what events produce transitions to what states, and what events can occur in particular states, is hard to do in ordinary English, and the Session Protocol Standard contains twenty-six pages of State Tables that provide a clear and precise specification of these issues. The curious reader is invited to postulate some questions and to seek their answer by inspection of the State Tables in the Session Standards.

Note that what we are really talking about is what an application designer needs to be concerned with: we are not talking about where in implementation code particular checks are performed. Saying that, in a certain state, only certain primitives can be issued, is a strong statement constraining what a legal application protocol design can specify. Saying that, in a certain state, certain primitives can be received is more like tutorial information, saying that (in this state), no other primitives need be considered by the application protocol designer.

State Tables are used in almost all OSI standards, but their use in the Session Layer is perhaps the most important because of the very large number of collision cases and disrupting services that can occur in this layer, and have to be very carefully treated if bugs are not to be present in the standards. Dialogue control and separation issues are very much about the interaction of events occurring approximately simultaneously at the two ends. Token control helps, but many cases have to be addressed by careful enumeration of what can occur, and specification of the appropriate response to ensure a coherent service. It is the difficulty of getting this sort of thing correct that is the major justification for a separate layer which concentrates on solving these problems in a general way for use by all application designers.

6.5 Minor and major synchronization

6.5.1 Introduction

The problem to be solved here has already been described. We want to provide mechanisms which will enable an application designer to specify simply and easily the checkpointing of the state of the distributed application in a way that is not affected by messages in transit. This requires a sort of synchronization of the activities of both ends, and a clear separation of the dialogues (message exchanges) before and after the synchronization point (the point at which the application designer can specify checkpointing). So we are concerned with synchronization, and/or dialogue separation.

6.5.2 Minor synchronization

Figure 6.4: Minor synchronisation points shows a clear dialogue separation in a one-way flow of normal data (no use of expedited) achieved by the simple means of inserting a synchronization message into the one-way flow. This is perfectly adequate for many applications, where the application designer would specify checkpointing by application A when it issues the S-SYNC-MINOR (as the service primitive is called) request, and checkpointing by application B when it receives the S-SYNC-MINOR indication. (It is important here to note that the Session Layer in no way specifies checkpointing - it has no such concept - all that it provides is an exchange of messages that provide synchronization and dialogue separation.)

If synchronization points are to be useful, it is desirable to be able to identify them later, and for this purpose the session layer serially numbers each synchronization point that is established, and delivers the number as a parameter of the appropriate service primitives.

Again we must consider what it means if minor synchronization primitives collide. From one point of view, this is a nonsense, for their use is in relation to a one-way flow of data, so having them issued only by the sender is clearly sensible. This leads us to the view that the ownership of the data token would be a sensible way to control the issuing of minor synchronization point requests, preventing collisions of such messages, and hence potential problems with the numbering of the synchronization points. This would be a good solution if use of the session connection could switch from time-to-time between two-way simultaneous use and two-way-alternate use, but as was pointed out earlier, the decision on these modes (and hence the existence of the data token) is made once and for all when the session connection is first established. There is therefore a separate and distinct token controlling the issue of minor synchronization primitives, and hence preventing their collision.

It would be wrong to leave this discussion with the impression that the S-SYNC-MINOR exchange can only be used for checkpointing, or must be used for checkpointing. The application designer is in full control. If the exchange provided by S-SYNC-MINOR is useful (and it is a pretty simple exchange) to carry some other application semantics, that is not ruled out. An example of this is presented in the discussion of FTAM.

6.5.3 Major synchronization

Now let us consider the somewhat harder problem. We want to provide a similar dialogue separation and potential for checkpointing in an arbitrarily complicated dialogue with two-way flow of data and the occasional use of expedited data in both directions. And we want to do this in a reasonably efficient manner, without too many round-trip times.

There are obviously other special cases of dialogue patterns that could be considered (for example, one-way with occasional use of expedited in the same direction), but these are not nearly as common as the case addressed by minor synchronization, and it seems inappropriate to do more than address that very common simple case plus the most general dialogue possible.

Suppose then, in a general dialogue, that application A decides it is time to checkpoint, and seeks to establish a synchronization point. An S-SYNC-MAJOR request is issued, and travels on normal T-DATA to application B. Application A stops sending. Clearly the issue of the S-SYNC-MAJOR request cannot be the synchronization point (the point of dialogue separation), because as shown in figure 6.5: Dialogue 1 and sync messages cross, there are still messages originated as part of dialogue one that are on their way to A. On the other hand, the issuing of the S-SYNC-MAJOR indication to application B could well form the point of dialogue separation (the synchronization point) between dialogue one and dialogue two. Let us try to make that work. At this point then, if the application designer so determines, application B checkpoints its state, and then initiates dialogue two by issuing an S-SYNC-MAJOR response which is delivered to application A as an S-SYNC-MAJOR confirm, establishing the major synchronization point at A and enabling A to checkpoint its state at this point and then continue with dialogue two. This is shown in figure 6.6: Possible redesign for major sync. Does this work?

It is clear that it almost does. All requests or responses issued by A in dialogue one (whether they use transport expedited or transport normal data), will be delivered to B in dialogue one. Equally anything issued by A in dialogue two is delivered to B in dialogue two. Anything issued by B in dialogue one is delivered to A in dialogue one, and any normal data issued by B in dialogue two is delivered to A in dialogue two. But ..... whoops!.... anything issued by B in dialogue two which is carried on the transport expedited path may get delivered to application A in dialogue one, as shown in figure 6.7: No dialogue separation for expedited. We have a bust protocol design. Back to the drawing-board.

The root of the problem is that A cannot distinguish between M1 and M2 in the figure, and we need to "send a ferret down the expedited tunnel" to flush out the rabbits and hold up the others - in other words, to mark the division between M1 and M2. This transmission is not visible in the service, but the protocol message is called the PREPARE message. The rule for the session protocol machine is that any material carried on the expedited channel prior to the arrival of the ferret will be processed and result in indications to the application in the normal way, but once the ferret has arrived, nothing else is processed until the second ferret (represented by the message carrying the S-SYNC-MAJOR response/confirm) comes out of the normal data tunnel (see figure 6.8: Major sync exchange with PREPARE). Material in the expedited tunnel is only processed and delivered to the application when (and immediately after) the S-SYNC-MAJOR confirm has been issued. Thus we have now achieved our clear dialogue separation, and checkpointing can take place at the synchronization points if the application designer so specifies. The PREPARE message is often described as "protecting dialogue two". It ensures a clean start to that dialogue, preventing messages properly part of that dialogue from "leaking" into dialogue one.

The major synchronization handshake is efficient and effective apart from one minor(?) problem. Any use of expedited data in any of the protocols providing it (X.25 level 3, Transport protocols) imposes a round-trip delay before further expedited data can be sent (this is effectively the flow control mechanism preventing overrun on the expedited path, where there is no explicit flow control). This is not normally a problem, as a series of expedited transmissions in quick succession is not what the service is intended to support.

However, as was pointed out earlier, the TP4 protocol not only delays any subsequent expedited data until earlier expedited has been acknowledged, it also delays the transmission of any normal data until the expedited has been acknowledged. Thus the effective handshake for S-SYNC-MAJOR looks like figure 6.9: Major sync with TP4 if TP4 is in use (but only if TP4 is in use), with the start of dialogue two transmissions by application B being delayed by the transport layer by a full round-trip time after the check-point. If use of this service is infrequent, there is no problem, but if it is used to mark the beginning and end of short dialogues in support of transaction processing (an application described later), then the problem can become an issue, with those who ardently believe in use of TP4 strenuously opposing any use of the session major synchronization function. This will be discussed further when CCR and TP are discussed in a later chapter 9.

Another point to discuss is collision of two attempts at major synchronization. As the reader will be expecting, this is handled by yet another token, the major/activity token. (It has this name because it also serves to control the issue of the "activity" primitives described below).

There is one further issue to consider in relation to synchronization points. It is all very well for an application design to propose checkpointing and issue the appropriate session primitives, but it is often highly desirable for both parties to know (reasonably quickly) that the other party has indeed secured the checkpoint data, so that earlier checkpoint data can be deleted from disk. In the case of a major synchronization, application A issues the service primitive, and the synchronization point (and hence any associated application procedures such as checkpointing) occurs at B prior to the response/confirm. Thus A knows that B has performed the appropriate procedures (as specified by the application designer) when the S-SYNC-MAJOR confirm is received. Moreover, A is not allowed to transmit (by the rules of the Session Layer) in dialogue two until the S-SYNC-MAJOR confirm has been received. It is a simple step for an application designer to require checkpointing before such transmissions, and hence the arrival at application B of data in dialogue two can be used as a signal that the application procedures associated with the major synchronization handshake have been completed. The application designer could then specify or allow the deletion of earlier checkpoint data. If this were not considered appropriate, it would be perfectly possible for the application designer (assuming all tokens were with application A) to require application A to issue an S-SYNC-MINOR request when checkpointing for the major synchronization point had been completed.

6.5.4 Confirmation of minor synchronization

In the case of S-SYNC-MINOR the situation is not so clear. There is only a one-way flow of messages and no "blocking". As soon as the S-SYNC-MINOR request is issued by application A, it can be immediately followed by further S-DATA requests, and application B is not transmitting anyway. Moreover, if A has control (has all the tokens), but in particular has the minor synchronization token, then B cannot be told to respond with a minor sync when checkpointing is complete without passing the token and producing potential confusion over confirmation of a sync point or the request to establish a new one. There are many ways of overcoming this problem, but in recognition of it, the S-SYNC-MINOR service primitive has been made what is usually called optionally confirmed. That is, the Session Layer allows (but does not require) a response/confirm to occur. If such a confirmation is indeed used, the pattern of exchanges is as shown in figure 6.10: Minor sync acknowledgements. It is for the application designer to specify whether and when such a confirmation is to be issued, and the associated application semantics (there are no session semantics). The Session Layer provides one other widget on this particular tool: there is a (yes/no) parameter on the S-SYNC-MINOR request/indication that allows the application to indicate whether confirmation is wanted or not. Again, like many parameters in the Session Service, there are no Session Layer semantics associated with it. An application designer may choose to be perverse, and require confirmation if the parameter is set to "No" and require no confirmation if it is set to "Yes". Parameters of this sort, where the name appears to imply some semantics but there is in fact no Session Layer requirement, are usually the result of naming fields in messages (and providing parameters in the corresponding service primitive) in a way that fits the Teletex usage. The field is present, and named according to Teletex usage, but the Teletex application rules are not imported into the Session Standards, and other application designers may use these fields in totally different ways if they so wish.

6.6 Resynchronization

It will frequently be the case that recovery back to some previous checkpoint takes place after a complete system or application crash. In this case the session connection is lost, and a new session connection has to be established for any recovery operation. There are parameters on the S-CONNECT primitive to specify a Session Connection Identifer and an Initial Synchronization Point Serial Number. The Session Layer places no semantics or restrictions on the use of the Session Connection Identifier, although it is described as four fields: Calling SS-user Reference, Called SS-user Reference, Common Reference, and Additional Reference Information, reflecting the way it is used in Teletex. It can, if appropriate, be used to identify earlier session connections which failed, and the Initial Synchronization Point Serial Number can be interpreted (if the application designer so specifies) as the identification of the checkpoint taken at that synchronization point in that old connection.

It can, however, happen that one or other of the applications detects that some problem has arisen even when the connection is intact. Perhaps flow is blocked and is not getting cleared. Perhaps (see exception reporting below) the session protocol identifies a problem - perhaps it has been passed a token it already has - which it reports to the application. It can then be desirable to have a tool available that will bypass flow control, clear out the connection (a disorderly and truncated termination of dialogue one), with a clean start to a new dialogue, probably following reloading from some identified checkpoint (synchronization point). Again, the session layer does not talk about reloading checkpoint data, but what it does provide is an S-RESYNCHRONIZE request, indication, response, and confirm that provides disorderly (potential loss of data) termination of dialogue one and a clean start (similar to major sync) to dialogue two, with identification of a sync point number "to which resynchronization is taking place".

If resynchronization was closely tied to checkpointing, it would be reasonable for the entire state of the session connection (in particular, the positions of all tokens) to be restored to the position they had when the identified sync point was established. But that is not the case. Checkpointing is a matter for the application designer (who may indeed preserve as part of the checkpoint information the position of tokens), and the Session Layer merely allows tokens to be repositioned (using exactly the same hand-shake as is used at the start of a connection) when resynchronization takes place.

The basic resync exchange is very similar to the major sync exchange, and in particular the clean start to dialogue two with the PREPARE message to protect it is identical. The difference, however, lies in the need to bypass flow control and discard any data left in dialogue one (purging the connection of dialogue one), in both directions. This involves a further PREPARE message, this time issued by the session layer supporting the application that initiated the resync. The initial handshake is as shown in figure 6.11: Purging for resynchronize, and the rules for each protocol machine are given below (The complete handshake is shown in figure 6.12: Complete resynchronize exchange):

There are a number of questions that will be bubbling up in the reader's mind, and these are dealt with below.

6.6.1 What about buffers in the upper layers?

We have implicitly assumed in the above discussion that there is no buffering between the session layer functionality and the application layer functionality in the implementation. Suppose, however, that the session, presentation, and application are implemented as independent processes communicating via buffered messages with back-pressure flow control between these processes.

Even if the S-RESYNCHRONIZE indication can bypass these buffers and signal to the application, we have to make sure that any messages in the buffers are cleared out as the S-RESYNCHRONIZE indication and confirm primitives are passed up (or we need to pass up the PREPARE to cause the application to read and discard). Thus the "purge" associated with resynchronization has to be recognised and implemented at all layers above the session layer.

Most implementors have recognised these issues, and it is now "conventional wisdom" that independent implementations of the three upper layers is not a good approach. Rather session, presentation and application functionality are probably best bundled into a single process.

None of this discussion is, of course, the concern of the standards, relating purely to implementation architecture. It does, however, serve to make the point that the layering in the seven layer model (and particularly the service primitive "interface") is a useful and convenient tool for defining clearly the bits to be sent up and down the line. It is not, and was never intended to be, a prescription for an implementation architecture.

6.6.2 What about a blocked expedited flow?

Another question that is often asked is: "Does the application have access to the transport expedited flow? If so, suppose that has got blocked and the PREPARE cannot get through?" Taking these in turn, there is indeed an S-EXPEDITED request and indication primitive that maps quite simply onto transport expedited. Moreover, if application A is sending S-EXPEDITED requests faster (even allowing for a round-trip time - which may be short - between each message) than they can be handled by the application, then either expedited data has to be discarded, or the expedited acknowledgement has to be delayed (preventing a following PREPARE message on the expedited flow). However, provided the application is not failing completely to process the expedited data, the blockage should hopefully clear in a finite time, and (provided there is little or no buffering on the expedited path from one session implementation to the other) there will be no noticeable delay on the resynchronization even if a delayed acknowledgement policy for S-EXPEDITED is implemented.

It would seem at first sight that discard of expedited would violate the Standards, but it is at least arguable that such action (in the case of overload), if accompanied by an S-P-EXCEPTION-REPORT indication (a session primitive described later) to both applications would be a perfectly conforming implementation, and would prevent blockage of the resynchronization procedures. It would also be possible to accept the delaying of expedited acks for some time-out period linked to the needs of the actual application, but this would require a close link between the transport layer's issuing of expedited acknowledgements and the application implementation.

The only internationally standardised OSI application layer protocol currently (1995) specifying the issue of S-EXPEDITED requests is the Virtual Terminal protocol (discussed later), and it is only for implementations of that that this issue has to be carefully considered.

This discussion, interesting as it may be, goes beyond the scope of this book. It has hopefully served to illustrate the importance of considering the complete implementation of all layers in relation to an application, and to reinforce the point that the existence of International Standards does not eliminate the need for intelligent planning of implementations.

6.6.3 What about TP0 and TP4?

The reader will remember that transport expedited is not available if TP0 is in use. Thus there can be no PREPARE message (making both the major sync and the resync procedures much simpler), and indeed the resync will then be incapable of bypassing flow control if flow is completely blocked.

For implementations expecting TP0 to be used, and where the application designer has indeed made use of resync, it is important to design the total implementation so that there is minimal buffering anywhere in the path between the two applications, and so that there is some intelligence in or above the session layer that will ensure that normal data flow is not blocked for an indefinite period. If this were done in the session layer, it could again be handled by an S-P-EXCEPTION indication and discard on a long-term blockage. If handled in a higher layer, then the only available exception signal would be an ABORT, and this could perfectly well be issued by an implementation issuing a resync and getting no reply, so little is gained.

The TP4 situation is somewhat different. Here expedited is available, but introduces a round-trip delay. Whilst this is a problem in the case of major sync for applications that might issue this primitive fairly often, it is not considered a problem for resync. By its very nature (disorderly termination of dialogue one, lost messages), it represents an exceptional situation that cannot be expected to occur frequently, so a round-trip delay is not a big issue.

6.6.4 What about collision of resynchronization handshakes?

We might expect yet another token to control the issue of S-RESYNCHRONIZE requests and hence to prevent collisions of this hand-shake. In fact, this is not the case. Remember that resync is a way of getting out of messes, and that it is important that it should not be blocked unnecessarily, so token control in this case is not appropriate.

The procedures for the hand-shake have been fully worked out to take account of collisions between two sequences. It makes the procedures significantly more complicated than presented here, and is best summarised by saying that the procedures of the resync quoting the earliest sync point number (or that from the connection initiator if they are equal) completes much as described above, and the procedures for the other attempt are abandoned.

In fact, these collision procedures give rise to an interesting sequence of permitted exchanges. If application A issues an S-RESYNCHRONIZE request quoting sync point number 8 (say), then application B (on receipt of the corresponding indication), instead of replying with an S-RESYNCHRONIZE response quoting 8, is permitted to reply with another S-RESYNCHRONIZE request quoting any earlier number (7 say). A can reply to this with a resync request quoting 5 (say), and so on until (in principle), a request is made to resync to the start of the connection. This then has to be accepted.

This sequence can be important when a minor synchronization is "destroyed" by a following and colliding resync. Consider figure 6.13: Responding to a resync with a resync: Application A has issued an S-SYNC-MINOR request which establishes at A the sync point with serial number 20 (say), and shortly after, for whatever reason, issues an S-RESYNCHRONIZE request proposing a resynchronize back to sync point 20. Unfortunately, the S-SYNC-MINOR indication is never issued, because the PREPARE for the resync overtakes it and the session layer commences purging. (The terminology used in standards work is to say that resynchronize is a disrupting service, in this case disrupting the minor synchronize service, preventing the completion of the S-SYNC-MINOR request/indication sequence.) When the S-RESYNCHRONIZE indication is eventually issued to the application, requesting resynchronization to sync point 20, application B has no knowledge of such a sync point, and can only respond with an S-RESYNCHRONIZE to an early sync point (19 say), which A can then accept.

6.6.5 What can be done while waiting for resynchronize to complete?

In the description of the resynchronize and the major sync sequences we said that "Application A stops sending normal and expedited data". The detailed description of these services specifies precisely what can be done while waiting for these sequences to complete, and the interested reader is invited, as an exercise, to examine the State Tables in the Session Service Standard, and to list the request primitives that can be issued between the issue of an S-RESYNCHRONIZE request and receipt of the corresponding S-RESYNCHRONIZE confirm. A similar exercise can be conducted for the S-SYNC-MAJOR sequence. It will be observed that in all circumstances an S-U-ABORT is permitted, to abruptly terminate the session connection, but that little else is permitted.

6.7 Flavours of resynchronize

In the earliest work on the Session Standards, there were only two "flavours" of S-RESYNCHRONIZE (a third was added later, and is described at the end of this clause). The "flavours" are identified by parameters in the service and protocol. One case was called resynchronize restart, and one was called resynchronize abandon. In the case of restart, an earlier sync point number is quoted, and a chain of successive resyncs with decreasing sync point number can occur, or a resync abandon can be issued. (Similarly, a resync abandon can be issued if a resync restart is pending but not completed). A resync abandon request/indication cannot be disrupted (expect by an abort), and has to be answered by a resync response/confirm. The synchronization serial number variable after completion of the resync abandon is set higher than any used so far in this connection. Thus the implied semantics of restart is "going back to an earlier sync point", whilst that of abandon is "getting a clean start". Again, however, the reader will perceive that all that is really happening is the setting of a variable used to identify future synchronization points.

The Session Standards do put one further restriction on resync restart. It is not permitted to quote a sync point earlier than the latest major sync, the view being that major dialogue separation is created by major syncs, and that resyncs operate within that dialogue. Although major sync as such is not used in Teletex, the philosophy of a major sync-like division that one never goes back beyond is present there, and is reflected in the provision here.

Shortly before the finalization of the Session Standard, because of a request from the FTAM (File, Transfer, Access and Management) group, another flavour of resync called resync set was introduced. In the case of resync set, any arbitrary sync point number is quoted on both the request/indication and on the response/confirm. It is the one quoted on the response/confirm that determines the setting of the sync point serial number variable, and it is for the application designer to determine how these numbers are used, and what they mean.

This completes the rather lengthy discussion of resynchronization. In its full glory it is quite a complex set of services, and for further detail the Session Service Standard should be read.

6.8 Bypassing token control for data transfer

As with so much in networking, the moment controls are put in place, there are reasons for allowing them to be bypassed. This is also true of token control of data transfer. Two arguments were presented (again quite late in the development of the Session Standards) for being able to send (a small amount of) data "in violation of the turn", that is, when not possessing the data token.

The first point comes from the possible use of the data token in support of data transfer to and from terminals. Two types of handling for dumb terminals could be identified in the early 1980s. In the first case, output from the host and input from the keyboard were both permitted to travel across the network simultaneously, and any contention for use of the screen was solved by some simple merging process, or by the human user voluntarily refraining from typing at certain times. If this communication was being supported by the OSI stack, this would correspond to two-way simultaneous use of session, with no data token. The second type of handling involved the concept of "keyboard locked". The keyboard was either unlocked, when the human user could type, and what was typed appeared on the screen and was transmitted to the host, or was locked, preventing typing, and the host transmitted material to the screen. If this communication was supported by OSI, this communication would correspond to two-way alternate use of session, with the presence or absence of the data token at the terminal end controlling the keyboard lock.

In practice, however, such systems usually had a single line at the bottom of the screen displaying "system status", and the host could transmit data to that bottom line even if the keyboard was unlocked (the data token was with the terminal end). Thus we have our first example of a possible requirement to be able to transmit small amounts of data in violation of the turn. Of course, it might be possible to use expedited data (which is not affected by the data token) for this purpose, but the possible overtaking of normal data is not desirable, and the amount of user data available in the S-EXPEDITED-DATA request and indication (once transport and session headers have been taken out of the 32 octets available in the Network Service) is a maximum of only 14 octets, which is not really enough.

The second argument came from the group defining standards for the Presentation Layer. At this time their protocol was in a very early stage of development, but it seemed clear that the Presentation Layer would provide primitives in its service which should be invocable by an application (to invoke services specific to that layer) even if that application did not have the data token - services unconnected with the transfer of data. But the support of such services would probably involve the Presentation Protocol machines in the exchange (perhaps the two-way simultaneous exchange) of some data to carry out the service, and such an exchange would be prevented if the application had selected the two-way alternate functional unit. One option might have been for the Presentation Layer to "track" the position of the data token, and to use S-TOKEN-GIVE requests (unknown to the application) to enable the Presentation Layer exchange of messages, and to reposition the token correctly at the end of that exchange. This looked not merely complicated, but in some sense a violation of the partitioning of functions into layers. The Presentation Layer should have no concern with tokens.

It could be argued that this latter point (and earlier ones about the problem of purging buffers on a resync because session primitives were not issued directly to the application) was clear support for the view that the architectural model was wrong, and that the Presentation Layer should have been positioned below the Session Layer. It was, however, much too late in the day for any such arguments to be seriously advanced, and other solutions had to be found.

The response was to introduce a new pair of service primitives: S-TYPED-DATA request/indication, permitting the transfer of a different "type" of data over the session connection. This other type of data would not be subject to token control. As far as the service is concerned, S-TYPED-DATA is identical to S-DATA apart from the lack of token control: it carries unlimited user data, goes on the transport normal flow, and hence is subject to normal flow control, does not involve an end-to-end round-trip for each transmission, and so on. As far as the service is concerned, it looks a bit like the use of the Q-bit in X.25, providing two different "colours" of data message, red and blue. In the protocol, however, there are a number of differences. S-DATA can be subject to segmentation in the session layer, and concatenation of messages supporting S-DATA and other session primitives (particularly token passing) within a single T-DATA transmission is permitted. Neither of these "optimization" features are available with S-TYPED-DATA, so at the protocol level it is not quite like the Q-bit of X.25, which is literally a single on/off bit in normal data messages.

It would appear at first sight that the S-TYPED-DATA primitives should be made available only in two-way alternate mode (only when there is a data token). However, this would have involved the Presentation Layer in having two different protocol specifications in terms of the mapping of messages to Session Service primitives: in TWS operation, messages would map to S-TYPED-DATA, and in TWA operation, messages would map to S-DATA. This was considered somewhat undesirable, so S-TYPED-DATA was made available as a normal part of the Session Service, available in both TWA and TWS operation, and selected as a separate functional unit. (Note that whilst this is not part of the Session Kernel Function unit, when the OSI Presentation Service is the user of the Session Service, it is a mandatory part of the provision if required to support the presentation protocol).

6.9 Activities

Remarkably little has been said above about Teletex, given the historical introduction. It is here that this is rectified! The Teletex exchange was concerned with the delivery of documents typed in on a Teletex machine, or being sent for printing by a Teletex machine. The transmission of such documents was an independent activity that the Teletex system engaged in, and the session connection was a sequence of such activities.

Normal operation was two-way alternate as far as the bulk data transfer was concerned - documents were going one way or the other, but a single connection could support both directions of transfer in sequence. The connection began with the exchange of capability data, designed to determine the capabilities of the Teletex machine to handle documents that might be sent to it or originate from it. It looked at such issues as whether it could print in "landscape" format (a page on its side) or "portrait" format (a page in an upright position), and the character repertoire it could handle (Teletex included not just the Latin alphabet, but Japanese as well as an optional feature). This was a two way exchange, and in order to provide support for the exchange, S-CAPABILITY-DATA request/indication/response/confirm primitives were introduced into the Session Service. (These are there to enable the Teletex specification to be rewritten using the Session Services, but as noted earlier, this has never actually been done, and X.400 - the nearest one gets to that exercise - chose not to issue S- CAPABILITY-DATA requests. Thus there are no Internationally Standardised protocols today that make any reference to S-CAPABILITY-DATA.)

Having exchanged capability data, the end with control (holding all the tokens) started an activity. (There was a protocol message saying this was what it was doing, and it allowed the activity to be named, and the initial value of the sync point serial number variable to be set for this activity.) This was a one-way unconfirmed exchange. To support it, we have the S-ACTIVITY-START request/indication. The Teletex system then transferred a document as a one-way flow, with checkpointing within it if it was large, and then ended the activity with a two-way exchange that was effectively a major synchronization point on completion of which checkpoint data for checkpoints established during the activity could be discarded. (Here you see the philosophy of not being able to resynchronize to points earlier than major synchronization points). As well as being able to have an orderly termination of an activity, it was also possible to discard the activity (abandon the transfer, again with release of any checkpoint data established, and with deletion of any partially received material), or interrupt the activity. In the latter case, checkpoint data would be retained, and at a later date the activity could be resumed from some checkpoint. Both interruption and discard were equivalent in their effect on the dialogue to resynchronization: they produced a disorderly termination of dialogue one (the activity being discarded/interrupted) and a protected start for the following activity.

To support these messages, we get S-ACTIVITY-END, S-ACTIVITY-DISCARD, and S-ACTIVITY-INTERRUPT, all as confirmed services (request, indication, response, confirm), and S-ACTIVITY-RESUME as an unconfirmed service (request and indication) in addition to the S-ACTIVITY-START request/indication mentioned above.

S-ACTIVITY-RESUME has three additional parameters over S-ACTIVITY-START, called Old Activity Identifier, Old Session Connection Identifier and Initial Synchronization Point Serial Number. As usual, the Session Layer places no semantics on the first two, and merely uses the third to initialise the sync point serial number variable. The names derive from the use Teletex makes of these fields.

The synchronization point establishment is clearly the same as the minor synchronization concept coming from ECMA, and the Teletex message was used to support both, with no doubling of service primitives. The "activity end" is effectively the same as a major synchronization, and both the "activity discard" and the "activity interrupt" are the same as resynchronization (except that chaining of request/indication sequences does not, of course, occur). Moreover, we need token control on "activity interrupt" and "activity discard" to ensure that collisions do not occur due to their more-or-less simultaneous issue by both of the communicating partners. In the end, it became clear that the simplest solution was indeed the addition of these extra primitives. It is, however, important for the reader to recognise that, in the session specification, the exchange of messages, the use of PREPARE, the purging of dialogue one, and the stacking up of transport expedited to protect dialogue two occurs for activity end, discard and interrupt in exactly the same way as for the major sync and resync exchanges. There is nothing new to understand.

Token control is used to prevent collisions of activity primitive exchanges, and in fact the same token was used for controlling major sync and for controlling the issuing of activity primitives, hence the name major/activity token.

Some readers may have seen tutorial text in which the PREPARE message is not shown on activity interrupt and activity discard. Why? Follow the tortuous route: Teletex involves TP0; TP0 does not support T-EXPEDITED-DATA; PREPARE is carried on T-EXPEDITED-DATA; therefore PREPARE will not be issued in many actual instances of use of session activity. (Note that CCITT Recommendation X.400 insists on the use of TP0, although the corresponding ISO standard does not. If other classes of transport protocol are in use, however, then a line monitor will indeed see a PREPARE message associated with activity termination.

It is now important to disentangle the Teletex semantics from the Session Layer semantics (the latter being by far the most important for the OSI application designer and the reader of this book). The above description has so far very much mixed both together. First, there are no restrictions in the Session Layer on the use of S-ACTIVITY-START or S-ACTIVITY-RESUME to commence an activity. There are two extra parameters on the resume primitives, but otherwise their effects are identical. No constraints are placed on the use of the activity identifier, the old activity identifier or the old sync point serial number fields. If application designers wish to use these primitives and fields in the same way as teletex, they can of course do so. But if they want to be perverse and use S-ACTIVITY-RESUME to start "new" activities, and S-ACTIVITY-START to resume interrupted ones, they can equally do so. In the same way, interrupting or discarding an activity is absolutely identical in terms of any effect on the session layer: they both produce disorderly termination of the activity. Secondly, note that most tutorials show the application that initiates an activity as the one that terminates it. This is not a restriction imposed by the session layer: the major/activity token can be passed during an activity, enabling termination of the activity by the other application.

So ... coming from the ECMA stable we have the concept of a session connection consisting of a series of dialogues separated by major synchronization points, with minor synchronization points placed between them, and with resync as the only mechanism for disorderly termination of a dialogue and a clean start to a new one. Coming from the CCITT stable, we have the concept of a session connection consisting of a series of activities which are begun and terminated (with an orderly end or a disorderly interrupt or discard), with minor synchronization points placed within them, and with the only data exchange outside activities being the exchange of capability data. Before reading further, readers are invited to put themselves in the role of the committee in 1984, and to come up with a sensible merger of these two approaches!

The first point to reinforce (discussed earlier) was the decision to "build" the session facilities from a series of functional units. These are listed below in the discussion on connection establishment, but critically, there is an activity functional unit. Application designers determine which functional units are needed to support their applications, and agreement on these functional units is made when the session connection is established. In particular, the activity functional unit will have been selected or not. Whilst it might be unusual to select both the major synchronization functional and the activity functional unit, we do not wish to prohibit such selection. Let us assume that any combination of the functional units can be selected, and in the discussion below that (apart from the activity functional unit) all functional units have been selected.

If the activity functional unit is not selected, then the session connection is used in the "pure" ECMA manner (see figure 6.14: Pure "ECMA" use of a session connection) - there are a series of dialogue units separated by major synchronization points, with minor synchronization points between them, and with resynchronization at any time. There is no use of capability data or of activity primitives.

On the other hand, if the activity functional unit is selected (see figure 6.15: Full session sync services in use), then each activity looks rather like a "pure-ECMA" connection, with major and minor synchronization points and resynchronization within it, and with only capability data transfer and the passing of tokens before an activity commences and between activities.

There was some discussion on the use of S-DATA in the activity case. In "pure" teletex, this is never issued outside of activities, but the decision was taken to permit this (and typed data and expedited data transmission) as well as capability data between activities. In the event, this produced a number of later problems, particularly for the session layer, as an S-DATA request can be issued outside an activity by one application, with the corresponding S-DATA indication within an activity because the data transfer crossed with an activity start coming from the other end. In the late 1980s, there was some discussion on whether to reverse the decision to allow S-DATA requests outside activities, or whether to make S-ACTIVITY-START and S-ACTIVITY-RESUME into confirmed services to help to address this problem, but this was never done, and application designers who choose to allow data transfer outside activities (when the activity functional unit is selected) have to be aware that they are responsible for handling any problems that might arise from this collision case.

6.10 Exception reports

We have already briefly mentioned the S-P-EXCEPTION-REPORT indication as a means (if the exception reporting functional unit has been selected by the application) by which the session layer can inform the application of problems detected within the session layer implementation without having to abort the connection.

The Session Service also provides the ability for higher layers (including the application itself) to make such signals, through the provision of an S-U-EXCEPTION-REPORT request/indication. The session rules specify that if either of these primitives is issued, then the only permitted actions by the applications are the issuing of an S-RESYNCHRONIZE or the aborting of the connection with an S-U-ABORT. Typically, an application designer selecting this functional unit will specify that the response to an upcoming S-P-EXCEPTION-REPORT indication will be a resynchronize in some specified circumstances, and an abort in other circumstances. Note, however, that if an application designer does specify use of this functional unit, then the application specification is not complete unless the handling of this indication at any point in the connection is properly specified.

6.11 Negotiation and connection establishment issues

The S-CONNECT request/indication and response/confirm primitives are supported by transmission using T-DATA request/indication primitives. They carry a number of parameters that are used to ensure that the two implementations are in agreement on the facilities available on the session connection and on the initial state in terms of the value of the sync point serial number variable and the position of tokens.

The session describes the establishment of this agreement as negotiation, as one end proposes in the request/indication, and the other end determines anything left optional. Whilst the application layer designer could in principle (given a suitable protocol design) leave the offer and the response as an implementation-dependent choice constrained only by the session rules, it is more common to find the exchange completely determined by the specification of the application.

One case where some element of implementation-dependent choice is permitted is in the use of the resynchronize functional unit in FTAM (File Transfer, Access and Management). FTAM defines a protocol that is capable of operating with or without this functional unit, so an implementation A initiating a connection to support FTAM transfers will propose use of this functional unit if and only if it can support this within its FTAM implementation. Similarly, if use is proposed by A, the responding implementation B will accept the proposal if and only if it can support its use within its FTAM implementation.

The full list of session functional units and the service primitives that their selection permits is (for convenience) given in figure 6.16: Session functional units and primitives. Note that the kernel functional unit is not negotiable: the associated service primitives are always available. Use of the remaining functional units and the associated service primitives is negotiated. (The reader is cautioned that this list is taken from the version of ISO 8326, the Session Service Definition, dated 1990, and that standards undergo an ongoing process of update and revision. The latest version should be consulted for any serious use.)

The S-CONNECT request/indication contains a bit-map notionally identifying the functional units needed by the application. Before transmitting the corresponding message, the session layer implementation notionally removes from the bit-map the bits corresponding to any functional units that it cannot support, and passes the message across. (I said "notionally" here, because the only thing that is visible on the line is the actual functional units proposed by the total implementation, and OSI standards do not constrain or specify internal implementation architectures - a point made frequently in earlier text.) In the receiving system, the bit-map is again reduced according to the capability of that session layer implementation before the S-CONNECT indication is issued. Finally, the responding application may make further reductions before the bit-map is passed (unchanged) through the two session layer implementations to the initiating application, this ensuring common agreement by all parties on what has been selected for use.

The existence of particular tokens is determined by the selection of functional units. Thus selection of the two-way alternate functional unit means that the data token exists. Selection of the minor synchronization functional unit means that the minor synchronize token exists, and so on. Whenever the bit-map contains a proposal or confirmation for a particular functional unit, the positioning of any corresponding token is also addressed. In the request/indication, the token is positioned as "my side", "your side", or "you choose". In the response/confirm, the final resolution of the last case is made.

The value to be used for the first synchronization point to be established on the connection (the initial synchronization point serial number) is also determined in the exchange. The initiator of the connection proposes a value (in the range 0 to 999 999), and the acceptor determines the final value as this or some lower value.

Another "negotiation" in the protocol (not visible in the service) supporting the S-CONNECT primitive is the version of the session protocol in use. All International Standards are subject to revision, and where such revision changes bits on the line or procedures, it is important to be able to identify which version of a protocol specification is to be used on a connection. Thus negotiation (the initiator provides a bit-map of the versions supported, the responder selects) of the version to be used is an important aspect of ensuring interworking.

Finally, it should be note that the S-CONNECT primitives all carry user data. In the first version of the Session Standards this was up to 512 octets, which leads into the discussion below.

6.12 Lengths of user data fields

Around the time that the Session Standards were stabilising, there was discussion within the OSI architecture group about "piggy-backing" of connection establishment. The reader will have noted that both the Network and the Transport Service provide user data (128 octets) on their CONNECT primitives, but that the layer above (Transport and Network) makes no use of this to carry connection establishment messages. T-CONNECT is carried in N-DATA and S-CONNECT is carried in T-DATA. If this were carried to the extreme, we would have about five round trips before an application could begin to do useful work: one to establish the network connection, followed by one to establish the transport connection, followed by one to establish the session connection, followed by one to establish the presentation connection, probably followed by one to negotiate the initial state of the application. This is clearly not acceptable.

The discussion concluded that there were good reasons (in terms of multiplexing and re-use) for avoiding "piggy-backing" in the lower layers, but that it was desirable to carry as a single T-DATA request/indication the S-CONNECT request/indication with (in its user data parameter) an embedded P-CONNECT request/indication with (in its user data parameter) embedded messages for any necessary application request/indication exchange. The corresponding reply from the other end-system would contain the S-CONNECT response/confirm with (in its user data parameter) an embedded P-CONNECT response/confirm with (in its user data parameter) embedded messages for any necessary application response/confirm exchange. Of course, we have to ensure that either connections in all layers are accepted, or that connections in all layers are refused, prohibiting mixed situations, but otherwise there are no problems from this piggy-backing of the upper layer exchanges.

This approach not only allows a reduction of round-trips - it confers the more important advantage that what is notionally the session layer response can be conditioned by the application being supported. Thus in the case of FTAM use of the resynchronize functional unit being proposed, the session implementation may be capable of supporting that for the X.400 application, but not for the FTAM application (for reasons of implementation architecture and product bundling). It is therefore desirable to be able to ascertain, before the session connection is accepted, which application is going to use it. This is achieved by the piggy-backing.

There is, however, one problem, which surfaced into a major "row" in about 1986. It was resolved by a special week-long meeting of experts from the session and presentation layers and the major applications which were being standardised in Helsinki. The meeting discussed a number of issues of common concern in the upper layers, but the primary problem being addressed was the length of the user data parameter of the S-CONNECT primitives.

There were two primary arguments coming from the presentation and application groups. The first argument related directly to the fact that messages from the presentation layer and potentially a number of application standards that were to use the session connection all had to be fitted into the 512 octets of the S-CONNECT user data parameter. The Presentation Layer Standards were by now sufficiently close to completion that it was apparent that the length of messages they might require was potentially unlimited (but highly dependent on the needs of the applications that were to use the connection). It was also apparent that as new applications were developed in the future, predicting now the likely size of initialization messages such an unknown application might need to exchange was very hard. Thus determining a "sensible" partitioning of any fixed length field between the different groups was not possible. With one voice the users of the session service said "We have to have a user data parameter of unlimited length. Please!"

The second argument requires an understanding of the functions of the Presentation Layer, presented briefly in earlier text, and discussed more fully in the next chapter. The important point, however, is that in the OSI architecture, application designers do not determine the bit-pattern (and hence the length) of their messages. The actual encoding of the information exchange is a matter for the presentation layer, and could be extremely verbose or extremely compact. It could even vary according to the relative bandwidth of the network and CPU power of the communicating systems. (At one extreme, spending CPU cycles on heavy compression could be sensible, at the other extreme it would not be.) This makes working with a fixed length almost impossible. Application designer literally do not know whether the information flow they are specifying can be fitted into 512 octets or not.

The session layer experts countered with two arguments of their own. First, that the standardization process had been completed for the Session Standards, and that a number of implementations were already out in the field. Making a change now would be disruptive, and could lose OSI credibility. Secondly, it really is irresponsible to transmit large amounts of data in the S-CONNECT, where there is no provision for checkpointing within the large transmission. Said the session Experts "OK - just maybe 512 octets is not enough. But surely a fixed length of 64K octets would be ample to meet any practical need?" The users replied "WE WANT UNLIMITED USER DATA. WE WANT UNLIMITED USER DATA." And at the end of the week, the agreement was indeed unlimited user data, not just on the S-CONNECT, but (to avoid any further problems), on all the Session Service primitives.

This change was promulgated in International Standards as a formal new version of the Session Protocol, making Session the first of the main OSI standards to introduce a second version, and to test out the effectiveness of version negotiation. In practice, however, implementors very quickly got the message that version 2 was where all the action was going to be, and there are few (if any) version 1 implementations in use today. On the other hand, it is probably true that all messages sent in anger so far are less than 512 octets in length.