Network Working Group Wayne McCoy Request for Comments: 1008 June 1987 IMPLEMENTATION GUIDE FOR THE ISO TRANSPORT PROTOCOL Status of this Memo This RFC is being distributed to members of the Internet community in order to solicit comments on the Implementors Guide. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors. Distribution of this memo is unlimited. IMPLEMENTATION GUIDE FOR THE ISO TRANSPORT PROTOCOL 1 Interpretation of formal description. It is assumed that the reader is familiar with both the formal description technique, Estelle [ISO85a], and the transport protocol as described in IS 8073 [ISO84a] and in N3756 [ISO85b]. 1.1 General interpretation guide. The development of the formal description of the ISO Transport Protocol was guided by the three following assumptions. 1. A generality principle The formal description is intended to express all of the behavior that any implementation is to demonstrate, while not being bound to the way that any particular implementation would realize that behavior within its operating context. 2. Preservation of the deliberate nondeterminism of IS 8073 The text description in the IS 8073 contains deliberate expressions of nondeterminism and indeterminism in the behavior of the transport protocol for the sake of flexibility in application. (Nondeterminism in this context means that the order of execution for a set of actions that can be taken is not specified. Indeterminism means that the execution of a given action cannot be predicted on the basis of system state or the executions of other actions.) McCoy [Page 1] RFC 1008 June 1987 3. Discipline in the usage of Estelle A given feature of Estelle was to be used only if the nature of the mechanism to be described strongly indicates its usage, or to adhere to the generality principle, or to retain the nondeterminism of IS 8073. Implementation efficiency was not a particular goal nor was there an attempt to directly correlate Estelle mechanisms and features to implementation mechanisms and features. Thus, the description does not represent optimal behavior for the implemented protocol. These assumptions imply that the formal description contains higher levels of abstraction than would be expected in a description for a particular operating environment. Such abstraction is essential, because of the diversity of networks and network elements by which implementation and design decisions are influenced. Even when operating environments are essentially identical, design choice and originality in solving a technical problem must be allowed. The same behavior may be expressed in many different ways. The goal in producing the transport formal description was to attempt to capture this equivalence. Some mechanisms of transport are not fully described or appear to be overly complicated because of the adherence to the generality principle. Resolution of these situations may require significant effort on the part of the implementor. Since the description does not represent optimal behavior for the implemented protocol, implementors should take the three assumptions above into account when using the description to implement the protocol. It may be advisable to adapt the standard description in such a way that: a. abstractions (such as modules, channels, spontaneous transitions and binding comments) are interpreted and realized as mechanisms appropriate to the operating environment and service requirements; b. modules, transitions, functions and procedures containing material irrelevant to the classes or options to be supported are reduced or eliminated as needed; and c. desired real-time behavior is accounted for. The use in the formal description of an Estelle feature (for instance, "process"), does not imply that an implementation must necessarily realize the feature by a synonymous feature of the operating context. Thus, a module declared to be a "process" in an Estelle description need not represent a real process as seen by a host operating system; "process" in Estelle refers to the McCoy [Page 2] RFC 1008 June 1987 synchronization properties of a set of procedures (transitions). Realizations of Estelle features and mechanisms are dependent in an essential way upon the performance and service an implementation is to provide. Implementations for operational usage have much more stringent requirements for optimal behavior and robustness than do implementations used for simulated operation (e.g., correctness or conformance testing). It is thus important that an operational implementation realize the abstract features and mechanisms of a formal description in an efficient and effective manner. For operational usage, two useful criteria for interpretation of formal mechanisms are: [1] minimization of delays caused by the mechanism itself; e.g., --transit delay for a medium that realizes a channel --access delay or latency for channel medium --scheduling delay for timed transitions (spontaneous transitions with delay clause) --execution scheduling for modules using exported variables (delay in accessing variable) [2] minimization of the "handling" required by each invocation of the mechanism; e.g., --module execution scheduling and context switching --synchronization or protocols for realized channel --predicate evaluation for spontaneous transitions Spontaneous transitions represent nondeterminism and indeterminism, so that uniform realization of them in an implementation must be questioned as an implementation strategy. The time at which the action described by a spontaneous transition will actually take place cannot be specified because of one or more of the following situations: a. it is not known when, relative to any specific event defining the protocol (e.g., input network, input from user, timer McCoy [Page 3] RFC 1008 June 1987 expirations), the conditions enabling the transition will actually occur; b. even if the enabling conditions are ultimately deterministic, it is not practical to describe all the possible ways this could occur, given the different ways in which implementations will examine these conditions; and c. a particular implementation may not be concerned with the enabling conditions or will account for them in some other way; i.e., it is irrelevant when the action takes place, if ever. As an example of a), consider the situation when splitting over the network connection, in Class 4, in which all of the network connections to which the transport connection has been assigned have all disconnected, with the transport connection still in the OPEN state. There is no way to predict when this will happen, nor is there any specific event signalling its occurrence. When it does occur, the transport protocol machine may want to attempt to obtain a new network connection. As an example of b), consider that timers may be expressed succinctly in Estelle by transitions similar to the following: from A to B provided predicate delay( timer_interval ) begin (* action driven by timeout *) end; But there are operations for which the timer period may need to be very accurate (close to real time) and others in which some delay in executing the action can be tolerated. The implementor must determine the optimal behavior desired for each instance and use an appropriate mechanism to realize it, rather than using a uniform approach to implementing all spontaneous transitions. As an example of the situation in c), consider the closing of an unused network connection. If the network is such that the cost of letting the network connection remain open is small compared cost of opening it, then an implementation might not want to consider closing the network connection until, say, the weekend. Another implementation might decide to close the network connection within 30 msec after discovering that the connection is not busy. For still another implementation, this could be McCoy [Page 4] RFC 1008 June 1987 meaningless because it operates over a connectionless network service. If a description has only a very few spontaneous transitions, then it may be relatively easy to implement them literally (i.e., to schedule and execute them as Estelle abstractly does) and not incur the overhead from examining all of the variables that occur in the enabling conditions. However, the number and complexity of the enabling conditions for spontaneous transitions in the transport description strongly suggests that an implementation which realizes spontaneous transitions literally will suffer badly from such overhead. 1.2 Guide to the formal description. So that implementors gain insight into interpretation of the mechanisms and features of the formal description of transport, the following paragraphs discuss the meanings of such mechanisms and features as intended by the editors of the formal description. 1.2.1 Transport Protocol Entity. 1.2.1.1 Structure. The diagram below shows the general structure of the Transport Protocol Entity (TPE) module, as given in the formal description. >From an abstract operational viewpoint, the transport protocol Machines (TPMs) and the Slaves operate as child processes of the the TPE process. Each TPM represents the endpoint actions of the protocol on a single transport connection. The Slave represents control of data output to the network. The internal operations of the TPMs and the Slave are discussed below in separate sections. This structure permits describing multiple connections, multiplexing and splitting on network connections, dynamic existence of endpoints and class negotiation. In the diagram, interaction points are denoted by the symbol "O", while (Estelle) channels joining these interaction points are denoted by McCoy [Page 5] RFC 1008 June 1987 * * * The symbol "X" represents a logical association through variables, and the denotations <<<<<<< >>>>>>> V V V indicate the passage of data, in the direction of the symbol vertices, by way of these associations. The acronyms TSAP and NSAP denote Transport Service Access Point and Network Service Access Point, respectively. The structure of the TSAPs and NSAPs shown is discussed further on, in Parts 1.2.2.1 and 1.2.2.2. |<-----------------TSAP---------------->| ----------O---------O---------O---------O---------O--------- | TPE * * * | | * * * | | ____O____ ____O____ ____O____ | | | | | | | | | | | TPM | | TPM | | TPM | | | | | | | | | | | |___X___| |__X_X__| |___X___| | | V V V V | | V multiplex V V V | | >>>>>>>> <<<<<<<<<<< V V | | V V split V V | | V V V V | | ---X---- ---X---- ---X---- | | |Slave | |Slave | |Slave | | | |__O___| |__O___| |__O___| | | V V V | | V V V | |-----------------O------------O--------O------------------| NSAP |<------>| NSAP McCoy [Page 6] RFC 1008 June 1987 The structuring principles of Estelle provide a formal means of expressing and enforcing certain synchronization properties between communicating processes. It must be stressed that the scheduling implied by Estelle descriptions need not and in some cases should not be implemented. The intent of the structure in the transport formal description is to state formally the synchronization of access tovariables shared by the transport entity and the transport connection endpoints and to permit expression of dynamic objects within the entity. In nearly all aspects of operation except these, it may be more efficient in some implementation environments to permit the TPE and the TPMs to run in parallel (the Estelle scheduling specifically excludes the parallel operation of the TPE and the TPMs). This is particularly true of internal management ("housekeeping") actions and those actions not directly related to communication between the TPE and the TPMs or instantiation of TPMs. Typical actions of this latter sort are: receipt of NSDUs from the network, integrity checking and decoding of TPDUs, and network connection management. Such actions could have been collected into other modules for scheduling closer to that of an implementation, but surely at the risk of further complicating the description. Consequently, the formal description structure should be understood as expressing relationships among actions and objects and not explicit implementation behavior. 1.2.1.2 Transport protocol entity operation. The details of the operation of the TPE from a conceptual point of view are given in the SYS section of the formal description. However, there are several further comments that can be made regarding the design of the TPE. The Estelle body for the TPE module has no state variable. This means that any transition of the TPE may be enabled and executed at any time. Choice of transition is determined primarily by priority. This suggests that the semantics of the TPE transitions is that of interrupt traps. The TPE handles only the T-CONNECT-request from the user and the TPM handle all other user input. All network events are handled by the TPE, in addition to resource management to the extent defined in the description. The TPE also manages all aspects of connection references, including reference freezing. The TPE does not explicitly manage the CPU resource for the TPMs, since this is implied by the Estelle scheduling across the mod