leong@PO1.ANDREW.CMU.EDU (John Leong) (06/12/86)
Having been involved with the ISO Transport Protocol definition a few years ago (started when it still an ECMA draft spec and a very very prelimary draft ISO spec from the Tokyo or was it Berlin meeting), it was very interesting to read the RFC983 "ISO Transport Services on Top of the TCP". I am afraid the RFC is very much NOT in the spirite of things. Every (newer) ISO protocol specification must be accompanied by a service specification. The primitives defined in the service specification is intended solely for explaination of the service offered by the protocol. Like the OSI reference model (from which it is derived), it is not an implementation guide. Furthermore, the primitives defines LOCAL INTERFACE and not PROTOCOL. Actually if you look at protocols for every layer, (e.g. Session) the service primitives and terminology (straight out of OSI) such as SAP's looks virtually identical. The actual service implementation at the interface is very dependent on the local operating system environment. Hence Connection Request, Connection Confirmation, Connection Indication etc. are manifested differently in an UNIX 4.2 socket environment from that of an VMS-VAX or whatever other operating system environment. It is definitely not the intent to have the primivites encoded and transported in a peer-to-peer fashion as a protocol. In that case, a service specification have to be defined for this "new" protocol and we quickly get into a recursion-with-no-exit situation!!! In general, it is important for one to produce good generic protocol interface design so that a particluar protocol implementation or even the protocol itself can easily be replaced without affecting the code in the upper or lower layer. A well designed generic interface can be used for every layer although the data structure associated with a primitive will most likely to be different. The UNIX 4.2 socket mechanism is a good start. One final note, for people who is really interested in implementation of the Transport and Session Protocols, the best set of documentation I have seen (besides the offical specification) can be obtained from : National Bureau of Standards, @* Institute for Computer Sciences and Technology, @* Center for Computer Systems Engineering, @* Systems and NetworkArchitecture Division The set is produced under contract by BBN back in 1980/81. It contains service specification, protocol specification, as well as implementation guide including wonderful pseudo codes. While the Transport Protocol spec is not 100% ISO spec, it is 99% close.
mrose@nrtc-gremlin.UUCP (06/13/86)
As one of the authors of the RFC, I feel I should clear up some
misconceptions you have regarding it.
At no point in rfc983 is it said how to implement the interface to
the TSAP. What is said is how you can build such an interface on
top of the TCP. That is, given the abstract service definitions for
the TP, instructions are given as to how one can map those onto the
services provided by the TCP. From our perspective, a proper
implementation of rfc983 exhibits the following properties:
- it has the TSAP interface that you want on your host
- it uses the protocol defined in the rfc
We have such an implementation for Berkeley 4.2 UNIX. I imagine
that an implementation for TOPS-20 would look entirely different,
both in actual internal code (the protocol engine) and in the
interface code (subroutine library). The same goes for VAX/VMS,
obviously. But, they would all speak the same protocol (as defined
in rfc983).
Perhaps the problem here, is that it appears to you that rfc983
specifies an "ISO protocol". This is certainly not our intention.
the rfc specifies a DDN-style protocol which provides ISO
services. It is the intent of rfc983 to permit standard ISO
protocols to run on top of the TCP. It is not the intent to build
ISO-like protocols for the ARPA Internet.
I completely agree with your statement that:
"In general, it is important for one to produce good generic
protocol interface design so that a particular protocol
implementation or even the protocol itself can easily be
replaced without affecting the code in the upper or lower
layer."
But I fail to see how rfc983 violates this concern. Quite the
contrary: rfc983 rips out the ISO TP internals and substitutes
calls to the services provided by the TCP!
/mtr