⟦978063abd⟧

TextFile

% run this through LaTeX with the appropriate wrapper

\f

\chapter	{Overview}\label{overview}
This document describes a non-proprietary implementation of some of the
protocols defined by the International Organization for Standardization
and International Electrotechnical Commission (ISO/IEC),
the International Telegraph and Telephone Consultative Committee (CCITT),
and the European Computer Manufacturer Association (ECMA).%
\footnote{In the interests of brevity,
unless otherwise noted,
the term ``OSI'' is used to denote these parallel protocol suites.}

The purpose of making this software openly available is to
accelerate the process of the development of applications in the OSI
protocol suite.
Experience indicates that the development of application level protocols takes
as long as or significantly longer than the lower level protocols.
By producing a non-proprietary implementation of the OSI protocol stack,
it is hoped that researchers in the academic, public, and commercial arenas
may begin working on applications immediately.
Another motivation for this work is to foster the development of OSI protocols
both in the European RARE and the U.S.~DARPA/NSF Internet communities.
The Internet community is widely known as having pioneered
computer-communications since the early {\oldstyle 1970}'s.
This community is rich in knowledge in the field,
but currently is not actively experimenting with the OSI protocols.
By producing an openly available implementation,
it is hoped that the OSI protocols will become quickly widespread in the
DARPA/NSF Internet,
and that a productive (and {\em painless\/}) transition in the Defense
Data Network (DDN) might be promoted.
The RARE community is the set of corresponding European academic and research
organizations.
While they do not have the same long implementation experience as the Internet
community,
they have a deep committment to International Standards.
It is intended that this release gives vital early access to prototype
facilities.

\f

\section	{Fanatics Need Not Read Further}
This software can support several different network services below the
transport service access point (TSAP).
One of these network services
is the \dod/ Transmission Control Protocol (TCP)\cite{TCP}.%
\footnote{Although the TCP corresponds most closely to offering a transport
service in the OSI model,
the TCP is used as a connection-oriented network protocol
(i.e., as co-service to X.25).}
This permits the development of the higher level protocols in a robust and
mature internet environment, while providing us the luxury of not having to
recode anything when moving to a network where the OSI Transport Protocol (TP)
is used to provide the TSAP.
However, the software also operates over pure OSI lower levels of software.
it is mainly used in that fashion~---~outside of the United States.

Of course,
there will always be ``zealots of the pure faith'' making claims to the effect
that:
\begin{quote}\em
TCP/IP is dead!
Any work involving TCP/IP simply dilutes the momentum of OSI.
\end{quote}
or, from the opposite end of the spectrum, that
\begin{quote}\em
The OSI protocols will never work!
\end{quote}
Both of these statements,
from diametrically opposing protocol camps are, of course, completely
unfounded and largely inflammatory.
TCP/IP is here, works well,
and enjoys a tremendous base of support.
OSI is coming, and will work well,
and when it eventually comes of age,
it will enjoy an even larger base of support.

The role of ISODE,
in this maelstrom that generates much heat and little light,
is to provide a useful transition path between the two protocol suites in which
complementary efforts can occur.
The ISODE approach is to use the strengths of both the DDN and OSI protocol
suites in a cooperative and positive manner.
For a more detailed exposition of these ideas,
kindly refer to \cite{ISO.on.DDN}.

\f

\section	{The Name of the Game}\label{name}
The name of the software is the ISODE.
The official pronunciation of the ISODE,
takes four syllables: {\em I-SO-D-E}.
This choice is mandated by fiat, not by usage,
in order to avoid undue confusion.

Please, as a courtesy, do not spell ISODE any other way.
For example, terms such as ISO/DE or ISO-DE do not refer to the software!
Similarly, do not try to spell out ISODE in such a way as to imply an
affiliation with the International Organization for Standardization.
There is no such relationship.
The {\em ISO\/} in ISODE is not an acronym for this organization.
In fact, the {\em ISO\/} in ISODE doesn't really meaning anything at all.
It's just a catchy two syllable sound.

\f

\section	{Operating Environments}
This release is coded entirely in the {\em C\/} programming
language\cite{C.Language},
and is known to run under the following operating systems
(without any kernel modifications):
\begin{itemize}
\item	Berkeley \unix/\\
The software should run on any faithful port of 4.2\bsd/ or 4.3\bsd/ \unix/.
The particular system used was a Sun Microsystems (Sun-3) workstation running
Sun \unix/~4.2 release~3.4.
Other sites have reported running the software on a \vax/-750,
a \vaxstation/ running \ultrix/,
an Integrated Solutions workstation,
a Sun Microsystems workstation running SunOS releases~3.2 through 3.5,
a Sun Microsystems workstation (Sun-3 and Sun-386i) running SunOS release 4.0,
and a RT/PC running 4.3\bsd/.%
\footnote{Do not however, attempt to compile the software with the SunPro
\pgm{make} program!
It is not, contrary to any claims, compatible with the standard \pgm{make}
facility.
On SunOS release~4.0, you will need to use the version of \pgm{make} in
the \file{/usr/old/} directory.}

In addition to using the native TCP facilities of Berkeley \unix/,
the software has also be interfaced to version~4.0 and~5.0 
of the SunLink X.25 package
(although Sun may have to supply you with some modified \verb"sgtty" and
\verb"ioctl" include files).
The optional SunLink Communications Processor running DCP 3.0~software has
also been tested with the software.

\item	AT\&T \unix/\\
The software should run on any faithful port of SVR2 \unix/ or SVR3 \unix/.
One of the systems tested was running with an
Excelan \exos/ 8044 TCP/IP card.
The Excelan package implements the networking semantics of the 4.1a\bsd/ \unix/
kernel.
As a consequence,
the software should run on any faithful port of 4.1a\bsd/ \unix/,
with only a minor amount of difficultly.
As of this writing however,
this speculation has not been verified.
The particular system used was a Silicon Graphics IRIS workstation.%
\footnote{This test was made with an earlier release of this software,
and access to an SGI workstation was not available when the current version of
the software tested.
However, the networking interface is still believed to be correct for the
Excelan package.}

Another system was running the WIN TCP/IP networking package.
The WIN package implements the networking semantics of the 4.2\bsd/ \unix/
kernel.
The particular system used was a 3B2 running System~V release~2.0.4,
with WIN/3B2 version~1.0.

Another system was also running the WIN TCP/IP networking package
but under System~V release~3.0.
The WIN package on SVR3 systems emulates the networking semantics of the
4.2\bsd/ \unix/ kernel but uses STREAMS and TLI to do so.

\item	AIX\\
The software should run on the IBM AIX Operating System
which is a UNIX-based derivative of AT\&T's System~V.
The particular system used was a RT/PC system running version~2.1.2
of AIX.

\item	HP-UX\\
The software should run on HP's \unix/-like operating system, HP-UX.
The particular system used was an Indigo 9000/840 system running version
A.B1.01 of HP-UX.
The system has also reported to have run on an HP 9000/350 system under
version~6.2 of HP-UX.

\item	ROS\\
The software should run on the Ridge Operating system, ROS.
The particular system used was a Ridge-32 running version 3.4.1 of ROS.

\item	Pyramid OsX\\
The software should run on a Pyramid computer running OsX.
The particular system used was a Pyrmaid~98xe running version 4.0 of OsX.
\end{itemize}

Since a Berkeley \unix/ system is the primary development platform for ISODE,
this documentation is somewhat slanted toward that environment.

\f

\section	{Organization of the Release}
A strict layering approach has been taken in the organization of the release.
The documentation mimics this relationship approximately:
the first two volumes describe,
in top-down fashion,
the services available at each layer;
the third volume describes some applications built using these facilities;
the fourth volume describes a facility for building applications based on a
programming language, rather that network-based, model;
and,
the fifth volume describes a complete implementation of the OSI Directory.

In \volone/,
the ``raw'' facilities available to applications are described,
namely four libraries:
\begin{itemize}
\item	the \man libacsap(3n) library,
	which implements the OSI Association Control Service (ACS);

\item	the \man librosap(3n) library,
	which implements different styles of the OSI Remote Operations Service
	(ROS);

\item	the \man librtsap(3n) library,
	which implements the OSI Reliable Transfer Service (RTS);
	and,

\item	the \man libpsap(3) library,
	which implements the OSI abstract syntax and transfer mechanisms.
\end{itemize}

In \voltwo/,
the services upon which the application facilities are built are described,
namely three libraries:
\begin{itemize}
\item	the \man libpsap2(3n) library,
	which implements the OSI presentation service;

\item	the \man libssap(3n) library,
	which implements the OSI session service;
	and,

\item	the \man libtsap(3n) library,
	which implements an OSI transport service access point.
\end{itemize}

In \volthree/,
some application programs written using this release are described,
including:
\begin{itemize}
\item	An implementation of the ISO FTAM
	which runs on Berkeley or AT\&T \unix/.
	FTAM, which stands for File Transfer, Access and Management,
	is the OSI file service.
	The implementation provided is fairly complete in the context
	of the particular file services it offers.
	It is a minimal implementation in as much as it offers only four core
	services: transfer of text files, transfer of binary files,
	directory listings, and file management.

\item	An implementation of an FTAM/FTP gateway,
	which runs on Berkeley \unix/.

\item	An implementation of the ISO VT
	which runs on Berkeley \unix/.
	VT, which stands for Virtual Terminal, is the OSI terminal service.
	The implementation consists of a basic class, TELNET profile
	implementation.

\item	An implementation of the ``little services'' often used for debugging
	and amusement.

\item	An implementation of a simple image database service.
\end{itemize}

In \volfour/,
a ``cooked'' interface for applications using remote operations is described,
which consists of three programs and a library:
\begin{itemize}
\item	the \man rosy(1) compiler,
	which is a stub-generator for specifications of Remote Operations;

\item	the \man posy(1) compiler,
	which is a structure-generator for ASN.1 specifications;

\item	the \man pepy(1) compiler,
	which reads a specification for an application and produces a program
	fragment that builds or recognizes the data structures (APDUs in OSI
	argot) which are communicated by that application;
	and,

\item	the \man librosy(3n) library,
	which is a library for applications using this distributed
	applications paradigm.
\end{itemize}

In \volfive/,
the QUIPU directory is described,
which currently consists of several programs and a library:
\begin{itemize}
\item	the \man quipu(8c) program,
	which is a Directory System Agent (DSA);

\item	the \man dish(1c) family of programs,
	which are a set of DIrectory SHell commands;
	and,

\item	the \man libdsap(3n) library,
	which is a library for applications using the Directory.
\end{itemize}

\f

\section	{A Note on this Implementation}
Although the implementation described herein might form the basis for a
production environment in the near future,
this release is not represented as as ``production software''.

However,
throughout the development of the software,
every effort has been made to employ good software practices which result in
efficient code.
In particular,
the current implementation avoids excessive copying of bytes as data moves
between layers.
Some rough initial timings of echo and sink entities at the transport and
session layers indicate data transfer rates quite competitive with a raw TCP
socket (most differences were lost in the noise).
The work involved to achieve this efficiency was not demanding.

Additional work was required so that programs utilizing the \man libpsap(3)
library could enjoy this level of performance.
Although data transfer rates at the reliable transfer and remote operations
layers are not as good as raw TCP,
they are still quite impressive
(on the average,
the use of a ROS interface (over presentation, session, and ultimately the TCP)
is only 20\% slower than a raw TCP interface).

\f

\section	{Changes Since the Last Release}\label{isode:changes}
A brief summary of the major changes between v~\isodeprevrsn/ and v~\isodevrsn/
are now presented.
These are the user-visible changes only;
changes of a strictly internal nature are not discussed.

\begin{itemize}
\item	A unified logging facility was added, this is described in
Section~\ref{logging} in \voltwo/.

\item	Explicit support for OSI session version~2 was added to the QOS
	parameters used on connection-establishment.
	Consult Section~\ref{tsap:qos} in \voltwo/.

\item	A new string format for presentation addresses is now used.
	Consult Section~\ref{addr:encodings} in \volone/.

\item	The \man isoentities(5) file has been modified to use this new
	format.
	Although the old format is still recognized,
	support will be removed in the next release.
\end{itemize}

As a rule,
the upgrade procedure is a two-step process:
first,
attempt to compile your code, keeping in mind the changes summary relevant to
the code;
and,
second,
once the code successfully compiles,
run the code through \man lint(1) with the supplied lint libraries.

Although
every attempt has been made to avoid making changes which would affect
previously coded applications,
in some cases incompatible changes were required in order to
achieve a better overall structure.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦978063abd⟧ TextFile

Derivation

TextFile
