🚀 go-pugleaf

saint@stonyman.hac.com (Kathy Saint) writes:

>We're looking for a high-level explanation of ISODE to give to someone
>who is somewhat familiar with computer science.  If anyone has such an
>explanation, or a reference to an article in a magazine or journal, I'd
>appreciate a reply.

>Thanks in advance,
>Kathy.

Here is an extract from something that appeared in print last year.

/mtr
///////
The ISODE (pronounced I-SO-D-E), or ISO Development Environment, is
a collection of library routines and programs that implements an
extensive set of OSI upper-layer services.  The ISODE
implementation of the upper-layers of OSI is interesting in four
     respects:

      - it provides extensive automatic tools for the development of
	OSI applications; 

      - it supports OSI applications on top of both OSI and TCP/IP-based
	networks; 

      - it provides a novel approach to the problems of OSI coexistence
	with and transition from the Internet suite of protocols; and,

      - it is openly available (non-proprietary).

     The ISODE was originally developed in 1986 at the Northrop Research
     and Technology Center as a means to experiment with OSI
     applications.  Current support for the ISODE comes from Performance
     Systems International (PSI) and partially from the U.S.~Defense
     Advanced Research Projects Agency (DARPA).

     The ISODE is an openly available implementation, available for a
     minimal distribution fee from any of several international
     distribution sites, via both postal and on-line means.  There is an
     implicit ``hold-harmless'' clause contained in the software,
     although no signatures, letters of intent, or other such legal
     encumbrances need be exchanged in order to receive a source release
     of the software.  Once a copy of the ISODE is obtained, any party
     is free to make use of the software for any legal purpose,
     including re-selling it for a profit (modified or not), providing
     that the authors and distribution sites are held harmless from any
     legal entanglements.

     This style of openly available source coupled with contributions
     from the user community is reminiscent of the early days of
     DARPA-sponsored networking, when researchers freely exchanged their
     findings in order to facilitate rapid understanding of the
     technology.  However, the policy is in sharp contrast to the modern
     trend of so-called ``public domain'' software that can be used only
     for non-commercial purposes.  The openly-available/no restrictions
     model is particularly appropriate for the ISODE, whose original
     authors felt that the dearth of OSI implementations combined with
     the frenzy for OSI-based systems outweighed the potentially huge
     financial opportunity that could be made with a high-quality,
     relatively complete implementation of OSI.  Northrop management was
     far-sighted enough to agree with this posture, which in turn set
     the tone for subsequent sponsors of the ISODE.

     The ISODE contains four parts:

      - a set of application service elements;

      - a collection of ASN.1 tools;

      - presentation and session services; and,

      - interfaces to transport and network layer realizations.

     The ISODE currently reflects the Standards as they existed towards
     the end of~1988.

     As a result of continuing development and cooperation, the ISODE
     now contains implementations of the four main OSI applications:
     message handling (MHS), file service (FTAM), directory services,
     and terminal service, plus a gateway between FTAM and the Internet
     File Transfer Protocol (FTP), and a gateway between MHS and the
     Internet Simple Mail Transfer Protocol (SMTP).  Finally, the ISODE
     contains a network management implementation, but not the OSI
     network management protocol.

     The ISODE was initially developed as a tool for studying how OSI
     applications could be built.  However, since then it has grown into
     a system extensively used in international pilots of OSI services,
     and it been pressed into service as a reference implementation of
     the core aspects of OSI.

     The ISODE is really a programming kit: the 6.0 release available in
     January of 1990, contained everything but the message handling
     software, and consisted of approximately~250,000 lines of C code,
     along with a five volume user's manual of over~1000 pages. ISODE
     runs on different variants of the \unix/ operating system, and does
     not require any changes to the operating system.

     Building Distributed Applications

     Although the ISODE can be programmed at several levels, it provides
     a set of semi-automatic tools, termed The Applications Cookbook,
     which can be used to rapidly construct OSI applications.

     In OSI, there is a concise notation for describing programs that
     use remote operations.  The ISODE contains a compiler which reads
     this notation and produces equivalent procedure calls in the C
     programming language.  When a program calls one of these routines, a
     run-time library is invoked which initiates a remote procedure call
     across the network.  Another compiler defines C data structures
     equivalent to the ASN.1 structures defined by the notation.
     Finally, a third compiler generates C code to map between the C and
     ASN.1 structures.

     The impact of a system such as the Applications Cookbook is that it
     frees the programmer from worrying about network-specifics: the
     programmer deals with the application-specific aspects of the
     system, and the Cookbook deals with how the application talks to
     the network.

     Transport-Independence

     When the ISODE was originally developed in January of 1986, there
     were very few networks and systems which supported the OSI
     transport service.  In contrast, the Internet suite of protocols,
     and in particular, it's reliable transport protocol, the TCP, were
     widely deployed even at that time (and are even more so today).

     To solve this problem, a transport service convergence protocol
     (TSCP) between the TCP and the OSI transport service was developed,
     known as the RFC1006 method. This particular TSCP is a simple
     protocol that runs over the TCP and makes the service it offers
     appear to be identical to the OSI transport service.  This is an
     important abstraction in that it allowed the development of native
     OSI applications, that behaved as if they were running in a pure
     OSI environment. Later, when some pure OSI environments became
     available, the same applications ran without even being
     re-compiled: they were simply reloaded with a new transport library!

     This development led to an important abstraction in the ISODE
     called the transport switch.  When the ISODE is configured, one or
     more transport-stacks are defined. A transport-stack is simply a
     combination of protocols which offer the OSI transport service,
     e.g., TP4 over CLNP, or TP0 over X.25, or RFC1006 over TCP. When a
     connection is to be initiated, the transport-switch examines the
     destination address and automatically invokes the correct
     transport-stack. Once a connection is established, the appropriate
     transport-stack is used exclusively for that connection.

     Initially, the transport-switch was written with the belief that
     there would be only a few transport-stacks that it would have to
     know about.  However, many in the new generation of network
     technologies are likely to use their own transport service.  As a
     result, some predict that by mid-90's there will be many competing
     transport services, all useful, but few interworking. In cases such
     as these, the transport-switch will prove useful in providing a
     transparent mechanism for OSI applications to run on these new
     technologies.

     Transition to OSI

     Being able to run OSI applications over TCP/IP-based  networks might
     be an interesting approach towards the transition to OSI. But, if
     one site has OSI applications running on top of TP4/CLNP, and
     another runs the same applications over RFC1006/TCP, then how can
     these two sites interoperate?

     The solution is to provide a device called a transport-service
     bridge (or active transport layer relay in ISO parlance).  This is a
     device which supports at least two different transport-stacks.
     When a connection comes in on one stack, it starts a connection
     with the second stack and then starts shuffling data. 

     Of course, such a device is outside the scope of OSI as it performs
     functions which are not allowed within the framework of the OSI
     model.  As such, it should not be surprising that this ``solution''
     is not perfect: issues such as accounting, access control, and load
     balancing have yet to be resolved.  But, in many environments, the
     use of TS-bridges has proven crucial in achieving interoperability
     between communities.  For example, many sites run TCP/IP over their
     local area network and also have a host with an international-X.25
     connection.  By running a TS-bridge on this host, all of the
     machines on the local area network are able to access OSI services
     available anywhere in the international-X.25 network.---
Marshall Rose

------- End of Forwarded Message