🚀 go-pugleaf

Archive-name: osi-protocols
Last-modified: $Date: 92/12/14 18:42:41 $
Version: $Revision: 1.1 $

Frequently Asked Questions about OSI with Answers
-------------------------------------------------

This text is a monthly posting to the USENET group comp.protocols.iso.
Its purpose is to give answers to some of the most often appearing
questions in this group, to offer a minimal starting point in the
learning curve of OSI beginners and to collect interesting information
that appeared in USENET discussions.

Another FAQ (Archive-Name: standards) which is posted to
comp.protocols.iso and comp.std.misc contains information about the
international standardization organizations (ISO, CCITT, ...), where
their documents are available, what Internet recources provide
information about standards etc.

You should be aware that reading this text will not replace reading a
good book about OSI!!!

If you have a suggestion how this text might be improved or have a text
that you would like to be added, please send it to Markus Kuhn
<mskuhn@immd4.informatik.uni-erlangen.de>.

This FAQ is crossposted to news.answers and won't expire there on well
managed news systems until the next version has been posted. As a
consequence of being crossposted to news.answers, this text will also
be automatically archived on many FAQ servers all over the world (e.g.
look with anonymous ftp at pit-manager.mit.edu [18.172.1.27] in
directory /pub/usenet/news.answers). You'll find there also many other
answers to frequently asked questions.

Don't be angry if anything in this text is incorrect. As with all
information exchanged on USENET, you only get what you pay for and the
current author isn't payed a single pfennig for this FAQ. Better mail
me the correction!

I hope you enjoy it ...

Markus


Contents
--------

  What is OSI?
  What is the OSI reference model?
  What is ASN.1?
! What OSI standards are there?
! How are OSI and TCP/IP related?
  Which is better: TCP/IP or OSI?
! Which free OSI implementations are available?
  New and planned OSI standards
! Books and Journals

A '+' in the first column marks a topic that has been added since this
FAQ has been posted the last time and a '!' marks a change.



What is OSI?
------------
                   "the first successful worldwide attempt to develop a set
                    of comprehensive standards for computer communications"
                                                             (Uyless Black)

OSI is an abbreviation for Open Systems Interconnection. In the early
80's people in several standardization committees all over the world
felt that the time has come to develop a set of non-proprietary
standard protocols that will hopefully replace one day most of the
vendor dependent specifications and that will make the way free for
easy and highly flexible world wide computer communication. It took
nearly a decade before a first results have been produced: a reference
model and a set of layer standards beginning with physical cable
definitions up to distributed databases and information systems
together with management and security tools. The process of
standardization hasn't been finished yet and probably won't be in the
next decade, but we now have already a powerful set of protocols for
the most important applications. These specifications have been
published as ISO standards and CCITT recommendations.


What is the OSI reference model?
--------------------------------

A good international standard should be flexible and extensible. In
order to achive this goal, it seems to be a good idea to separate a
complex structure like a computer protocol in several modules. Each
module should be of manageable size and if different techniques are
available for a certain aspect of a protocol, then the separation in
modules allows quite easily to change this part of the whole system
(e.g. the cable specification or the encoding of data) without touching
the rest of the specification.

The OSI Reference Model divides the communication process between two
application programms in 7 intermediate layers. Each layer provides a
certain kind of service to the next higher layer. This service is
provided by communicating with the same layer in the remote host using
the service provided by the next lower layer. Some of the layers may be
implemented in physical devices, some may be part of the operating
system and some may be included in application programms. Most layers
provide their service by forwarding protocol data units to the next
layer together with an added or removed header or by performing other
functions and state changes.

The OSI Reference Model only defines the abstract notion of layers and
does not specify whether the boundaries between the layers have to be
visible and documented in implementations. There are other standards
that define application program interfaces (APIs) between the operating
system and the application and these APIs often correspond to a layer
boundary in the OSI Reference Model.

The classic standard diagram that is normally used to describe the OSI
RM looks like this:


     End System                      End System

     +-------+                       +-------+
     |   7   |                       |   7   |     Application Layer
     +-------+                       +-------+
     |   6   |                       |   6   |     Presentation Layer
     +-------+                       +-------+
     |   5   |      Intermediate     |   5   |     Session Layer
     +-------+         System        +-------+
     |   4   |                       |   4   |     Transport Layer
     +-------+     +-----------+     +-------+
     |   3   |     |     3     |     |   3   |     Network Layer
     +-------+     +-----+-----+     +-------+
     |   2   |     |  2  |  2  |     |   2   |     Data Link Layer
     +-------+     +-----+-----+     +-------+
     |   1   |     |  1  |  1  |     |   1   |     Physical Layer
     +-------+     +-----+-----+     +-------+
         |            |     |            |
         +------------+     +----...-----+


The PHYSICAL LAYER provides the service of transfering bits from one
end of the physical medium to the other. This includes the
specification of the medium (wire, coax cable, fiber optics, radio
signals, laser signals, microwave signals, seismic waves, ... :-) as
well as the connectors, the modulation techniques, environmental limits
etc.

The DATA LINK LAYER uses the bit transfer ability of the physical layer
to provide a secured link between two hosts. This includes functions
like error detection and correction, separating data blocks,
controlling media access etc.

In a network, not every computer has to be connected to each other
directly. Hosts should be able to forward data packets according to an
address field that has been attached to the packet. The NETWORK LAYER
provides the service of routing and delivering a packet to any host in
the network. In intermediate systems where there's no application
program involved in the communication, the packets are only processed
by the lower three layers.

Each layer (especially 2 and 3) can operate in two different modes. In
the CONNECTION ORIENTATED (CO) mode, the communication goes through
several stages similar to a telephone call: (1) dail, (2) wait until
the connection has been established, (3) communicate, (4) close
connection, (5) wait until close of the connection has been confirmed.
The connection orientated mode guarantees that no packets are lost and
that all packets arrive in the same order in which they have been sent.
In contrary in the CONNECTIONLESS (CL) mode, only a datagramm service
is provided similar to the postal letter service. No one guarantees
that the letters arrive in the same order in which they have been sent
and every intermediate system is allowed to discard a packet if the
buffers are full. In CL-mode systems, higher layers have to deal with
retransmission of lost packets etc.

It has been often discussed, whether the network layer should provide
the CONS (connection orientated network service) or the CLNS and now
both alternatives have been defined in OSI standard protocols. As most
applications want to exchange several packets in sequence they need a
CO-mode service. The TRANSPORT LAYER has been introduced in order to
hide the differences between several network concepts (CO vs. CL and
other things like maximum packet size and quality of service) from the
connection orientated transport service (COTS) user. In the case of a
CO network the COTS is quite simple to provide, but over a CL network,
complete error correction and flow control has to be provided in the
transport layer.

The main advantage of the CLNS is higher efficiency because less CPU 
cycles for complex flow control algorithms are needed in intermediate
systems (routers). If no connection orientated transport service is
needed, then the response time may be significantly shorter over a
CLNS. CONS on the other hand makes accounting for network providers
easier, as only correctly delivered packets are counted. The headers of
the connection orientated network protocol packets may be much shorter
as the full address is not required each time which might be relevant
on slow lines. In addition many existing nets are CO, e.g. X.25 nets,
the telephone net and ISDN.

The SESSION LAYER offers to include synchronisation points in the
stream of exchanged packets and to go back to one of the previous sync
points. This might be useful if large files are transfered and it is
possible after a breakdown to recover without having to retransfer the
whole file. The session layer offers no added  functionality, it only
provides the means to negotiate a recovery. The recovery has to be done
by the application and not by the software that implements the session
layer. This is the reason why some people consider the session layer as
one of the darker places of the OSI model especially as this part of
the standard is quite complex and difficult to understand. Perhaps it
would have been a better choice to include the session layer
functionality somewhere in the application layer ...

The PRESENTATION LAYER allows to negotiate between different possible
representations of the data that will be transfered. This makes sense
if several optional ASN.1 encodings or other syntaxes (e.g. the X
Windows System protocol) are possible.

And finally the APPLICATION LAYER provides an application specific
service. This is not the application itself, but the application layer
is directly used by an application program. For instance an electronic
mail user interface program might use the X.400 application layer in
order to send a message to another host. Here the application layer
will deal with things like address resolution, routing decisions,
transfering and converting (even very huge) messages etc. Other
application layer standards offer services like accessing remote file
systems, controlling video terminals and transaction systems etc.

In addition to the 7 layers, the OSI Reference Model defines a
management and a security architecture that includes all 7 layers.


What is ASN.1?
--------------

Most protocols are defined as sets of protocol data units (PDUs) that
might be exchanged between two hosts. A PDU is a sequence of bytes that
one host uses to tell the other one something according to the rules of
the protocol. Quite early in the OSI project, it has been recognized
that a formal way of defining the syntax of PDUs was needed similar to
the context free Backus-Naur grammars (BNF) that are used to define the
syntax of programming languages. ASN.1 (abstract syntax notation number
1) plays the same role in defining OSI protocols that BNF plays in the
definition of a programming language: it gives a precise and parseable
specification how PDUs are structured and which structures are allowed,
but it say's nothing about the meaning of a PDU. This is still defined
in English language in the OSI standards.

ASN.1 specifies only the 'abstract syntax' of a PDU. This means that it
only say's that e.g. a PDU consists of 2 integer numbers (of arbitrary
size), one optional UTC time value and one ISO 10646 string or
alternatively one ASCII string. ASN.1 doesn't define the 'transfer
syntax', i.e. the way in which the values in the abstract systax (e.g.
{2, 42, 1992-10-6 10:09:34, "Hey!"}) are encoded in a bit string.
Several different transfer syntaxes have been defined. The most widely
used one is BER (basic encoding rules). Other transfer syntaxes are
simplified BER subsets or provide a one-to-one mapping between abstract
value and the bit string for cryptographic applications or are
optimized with regard to CPU time or PDU length.

An example:

       NonsenseProtocol ::= CHOICE {
                              testPDU [0] TestPDU,  -- Our example
                              getFile [1] GetFile   -- another possible PDU
                            }

       TestPDU ::= SEQUENCE {
                     aNumber INTEGER,
                     anotherNumber INTEGER,
                     today UTCTime OPTIONAL,
                     theText CHOICE {
                               multilingualText ISO10646String,
                               standardText     VisibleString
                             }
                   }

The BER encoding consists of tag-length-value triples for both composed
types (CHOICE, SEQUENCE, SEQUENCE OF, SET, SET OF, tags, ...) and
primitive types (integers, strings, ...). The tag identifies the type
of the value (e.g. 0 for testPDU and 1 for getFile) and the length
defines the end of the TLV triple. This allows an implementation to
jump efficiently over (perhaps even unknown) values and makes ASN.1
defined protocols very extensible.

Aa an example the encoding of the value {2, 42, 1992-10-6 10:09:34,
"Hey!"} of type NonsenseProtocol:

  a0 80 ----------------------- Length encoding: indefinite.
   +--------------------------- Explicit tag: [0] means that we took
                                the testPDU alternative of the choice.
                                
  30 80 ----------------------- again indefinite length form, as we don't
   |                            know how long the SEQUENCE will finally be.
   |                            Consequently, the end of the SEQUENCE will
   |                            have to be marked by a 00 00 component.
   +--------------------------- This is a composite type SEQUENCE.

  02 01 02 -------------------- The value 2.        
   |  +------------------------ Length of the value: 1 byte.
   +--------------------------- This is an INTEGER value.

  02 01 02 -------------------- The value 2.        
   |  +------------------------ Length of the value: 1 byte.
   +--------------------------- This is another INTEGER value.

  17 0d 39 32 31 30 30 36 31 30 30 39 33 34 5a
   |  | --------------------------------------
   |  |                 +------ The encoded date and time.
   |  +------------------------ Length: 13 bytes.
   +--------------------------- Type: UTCTime.

  1a 04 48 65 79 21
   |  | -----------
   |  |      +----------------- The value: 'Hey!' coded in ASCII.  
   |  +------------------------ This is 4 bytes long.
   +--------------------------- We used the VisibleString alternative
                                of CHOICE.

  00 00 ----------------------- This is the end of the indefinite length
                                SEQUENCE.

  00 00 ----------------------- This is the end of the explicitly tagged
                                CHOICE alternative TestPDU.

Another very important ASN.1 concept and data type are object
identifiers. These are lists of integers that uniquely identify any
object in a protocol, e.g. a X.400 body part, a DFR document type, a
X.500 attribute type, a public key algorithm, a protocol version etc.
If one object identifier is yours, then only you are allowed to append
further numbers to your OID and create new object identifiers that only
belong to you. You may give some of your newly created object
identifiers to other people and then they also have the right of
creating whole subtrees in the OID space. The highest levels in this
tree belong to ISO and CCITT and they have already reserved OIDs for
many organizations. This allows you for instance to define your own
X.400 high-end cyberspace body part and it won't collide with someone
elses self defined body part if a prefix of the OID belongs to you. As
many options in OSI protocols are identified by OIDs, it is very easy
for implementors to extend the protocols without getting in conflict
with older implementations which will know that they don't know this
new OID. Many protocols exchange sets of OIDs that identify their
implemented subsets and extensions after the connection has been
established and automatically determine the biggest common subset of
all optional protocol features that both may use.

Today ASN.1/BER are also used in many non-OSI protocols and file
formats and there are a number of tools (ASN.1 compilers) available
that help to create parsers automatically from ASN.1 specifications.


What OSI standards are there?
-----------------------------

As two organizations have been involved in the OSI standardization
process, many of the specifications have been published as both ISO
standards and CCITT recommendations. In these cases, both versions are
"technically aligned" or one of both versions is a subset of the other
one.

The OSI Reference Model is defined in ISO 7498. Part one and CCITT
recommendation X.200 describe the details of the seven layer model and
three other parts describe the Security Architecture, Naming and
Addressing and the Management Framework.

Formal protocol description methods are defined in ISO 8807 (LOTOS,
Language Of Temporal Ordering and Specification), ISO 9074 (ESTELLE)
and ISO 9496 (CHILL) and ISO 9646 standardizes methods for conformance
testing e.g. the Tree and Tabular Combined Notation (TTCN) for test
suits. ISO TR 10167 (Application guidelines for ESTELLE, LOTOS and SDL)
includes a number of examples of systems, showing how each of them can
be specified using these three standards. International registration
procedures for things like OSI document types, object identifiers,
virtual terminal profiles and control objects and application process
titles are described in ISO 9834 and X.660. Registration means that a
world wide unique identifier will be reserved for your extension to an
OSI protocol, which guarantees that extensions developed by different
people won't collide with each other and possible future ISO
extensions.

ISO 8824 and X.208 standardize ASN.1 and ISO 8825|X.209 the Encoding
Rules (BER and soon others) for it.

The details of the Security Framework are defined in ISO 10181 and ISO
10745 describes the Upper Layers Security Model. Several security
techniques are standardized in ISO 9796 (Digital Signature Scheme
Giving Message Recovery) and ISO 9798 (Entity Authentication
Mechanisms, Symmetric Techniques and Public Key Algorithms). You may
register your own cryptographic algorithms as defined in ISO 9979.

Many OSI standards have been divided in two documents, the service
definition and the protocol specification in order to separate the
description of the functionality from the description of the
protocol realization.

Layer seven has been further subdivided in several modules (service
elements), as some of them may be useful for more than one one
application. This Application Layer Structure is defined in ISO 9545
and CCITT X.207. The Association Control Service Element (ACSE) (ISO
8649|X.217 service definition and ISO 8650|X.227 protocol definition)
manages the establishment of a connection between two remote
applications. CCR (Commitment, Concurrency and Recovery) is a service
element that provides services needed for keeping distributed databases
consistent (ISO 9804/9805|X.861/871), ISO 9066 and CCITT X.218/228
define the Reliable Transfer Service Element (RTSE) that transfers huge
messages savely from one node to the next one with recovery etc. (e.g.
used by e-mail) an the Remote Operations Service Element (ROSE) allows
a client to execute operations at a server process and to receive the
results or error indications.

Now, it's time to come to the most interesting part of the whole OSI
story, the application services and protocols:

ISO 9595 and CCITT X.710 define the Common Management Information
Service and ISO 9596|X.711 the Common Management Information Protocol
(CMIP) that may be used for controlling all parts of a computer
network, e.g. routers, queues, environmental sensors, accounts,
security logs, installed software versions, clocks etc. ISO 10164
describes these various aspects of System Management and ISO 10165
standardizes the Management Information Model used for controlling all
these devices.

FTAM (File Transfer, Access and Management) is a protocol defined in
ISO 8571 that has been designed for both simple file transfers a la
kermit and DoD ftp and for directly accessing remote file systems like
NFS etc.

The Virtual Terminal (VT) service and protocol specified in ISO 9040
and ISO 9041 allow a host to control a terminal with screen and
keyboard and similar devices like printers. Today, only the Basic Class
VT has been specified which covers character orientated terminals. This
service is comparable to DoD telnet and the X.3/X.28/X.29 PAD protocol,
but much more powerful. It includes also control of cursor movement,
colors, character sets and attributes, access rights, synchronisation,
multible pages, facility negotation etc. This means that the huge
number of classic terminal type definitions (e.g. in UNIX termcap or
terminfo) are unnecessary, as the VT protocol includes the corrsponding
commands for one abstract virtual terminal that only have to be
converted by the local implementation to the actual terminal control
sequences. Consequently, not every host needs to know every type of
terminal with VT.

ISO 8831 and ISO 8832 define the Job Transfer and Manipulation (JTM)
protocol and service that may be used to control the disposition of the
programs and files and the execution of processes on remote hosts, to
querry their status and to retrieve the results.

The X.400 electronic mail system, also known as Message Handling System
(MHS) is specified in CCITT X.400-X.440 and in ISO 10021. The system
consists of Message Transfer Agents (MTAs), that store and forward
messages through the network and User Agents (UAs) that present the
mail to the end user and allow him/her to send mail. The X.400 P1
protocol which is used between MTAs is based on the RTSE. The MTAs
transfer the messages to and from the UAs using the P3 protocol or by
local means (e.g. the file system if both processes run on the same
host). The Message Transfer System (MTS) that is formed by all MTAs may
be used for Interpersonal Messaging (IPM) or for other purposes (e.g.
system management). The MTS is used for sending mails to other peoples
directly or via Distribution Lists (DLs) and to transport delivery
reports (after the message has been delivered or discarded) and
receipt/non-receipt notifications (after the message has been read by
the recipient or deleted without ever having been seen by the
recipient) back to the sender. MTAs may be capable of converting
message body part types (e.g. different character sets or voice data
encodings) and rerouting if default links were unavailable.

X.500-X.521 and ISO 9594 specify the OSI Directory Service (DS). The DS
is a distributed database used for storing information about people,
organizations, application processes (e.g. MTAs or public DFR servers),
routing tables etc. X.500 may be used to search the X.400 addresses of
people interactively as well as other attributes like their phone
number, postal address, prefered delivery method (fax, mail, etc.),
photo and public keys. X.509 specifies a distributed authentication
framework based on the DS. The X.500 directory information base is
structured hierarchically, i.e. the entries that represent real world
objects (countries, persons, servers, management information, news
groups, distribution lists, groups of persons, organizational roles,
etc.) are connected to a world wide tree. Each entry has a number of
attributes with standardized or localiy defined attributes and a unique
Distinguished Name that describes its location in the tree. Generally,
there are nodes for countries under the root and nodes for
organizations under each country and these may be further subdivided
and contain person entries etc. But also other tree stuctures are
possible. Powerful search querries allow the implementation of very
comfortable Directory User Agents (DUAs, the clients) that provide
users the ability to find information stored in the interconnected
Directory System Agents (DSAs, the servers). The DSAs talk to each
other using the Directory System Protocol (DSP). DUAs send their
querries and modification commands to the DSAs using the Directory
Access Protocols.

The Document Filing and Retrieval (DFR) service and protocol are
defined in ISO 10166. A document store may contain a large number of
documents (ASCII textes, word processing files, hypertext files, but
also software packages etc.) together with attributes like title, name
of the author, date of creation and latest modification, version
number, pointers to other copies of the same document, pointers to
older versions, language, summary, keyword list, access rights, lock
semaphores and so on. Documents may be arranged in a tree and described
with attributes very similar to the X.500 database. DFR allows the
implementation of an easy to use distributed information retrieval
system similar to the Internet gopher. In addition to the gopher
protocol, the DFR protocol provides the ability to store and modify
documents, access control, searches on attributes, a version control
mechanism and other things. Documents may also be represented by links
to other DFR servers and a unique identifier is assigned to each
document by the system, so that the user need not be aware that he/she
accesses several servers while browsing through the document (and
perhaps hypertext) space. Documents may be of various types (e.g. ODA,
SGML and HyTime, X.400 IPM messages, binary).

The Bibliographic Search, Retrieval and Update Service and Protocol
(SR) are defined in ISO 10162/10163. It is based on NISO Z39.50. (Who
writes more? I haven't seen the specification yet!)

An Interlibrary Loan Service and Protocol (IL?) are specified in ISO
10160/10161 for library applications.

ISO 10031 defines Distributed Office Applications (DOA).

The Manufacturing Message Specification (MMS) Service and Protocol have
been defined for controlling and integrating industrial automation
systems (ISO 9506).

An application layer protocol for Remote Database Access (RDA) is
specified in ISO 9579 and a Distributed Transaction Processing Model,
Service and Protocol is defined in ISO 10026 and X.850/860/870.

This was a very short overview on the application layer and now let's
dive into the deeper layers.

The OSI presentation layer service and protocol are defined in ISO
8822/8823 and X.216/226. A connectionless mode protocol version is
specified in ISO 9576.

The OSI session layer service and protocol are defined in ISO 8326/8327
and CCITT X.215/225. The connection less variant is specified in ISO
9548.

The OSI transport layer service and protocol are defined in ISO
8072/8073 and X.214/224. These standards define 5 different flavours of
one transport protocol for the connection orientated transport service.
TP0 is the simplest version and assumes, that the network service is
reliable enough for the application. TP1 provides recovery, i.e. after
a network failure the transport layer implementation is capable of
automatically reestablishing the connection with out notifying the
higher layers. TP1 won't detect errors that are not signaled by the
network layer e.g. by a disconnect message. TP2 allows to multiplex
several transport connections over a single network connection and TP3
provides both recovery and multiplexing (TP1+TP2=TP3). Finally, TP4
provides all this together plus error detection, error correction and
packet resequencing. TP4 has to be used over unreliable connectionless
networks. ISO 8602 defines a protocol for the connectionless transport
service (COTS) and ISO 11570 a transport protocol identification
mechanism.

The network service and the secrets of OSI network service access point
(NSAP) addresses are defined in ISO 8348 and X.213. ISO 8648 defines
the internal organization of the network layer in 3 sublayers and ISO
8880 describes protocol combinations for the network service. ISO 10028
specifies the relaying function of an intermediate system.

The connectionless network service may be provided by the
connectionless network protocol (CLNP, also known as ISO IP) defined in
ISO 8473. In combination with CLNP, the End System to Intermediate
System Routing Information Exchange Protocol (ESIS) defined in ISO
9542, the Intermediate System to Intermediate System Routing
Information Exchange Protocol (ISIS) defined in ISO 10589 and the
Protocol for Exchange of Inter-Domain Routing Information (ISO 10747)
may be used. CLNP is normally used together with TP4 as the transport
layer.

The connection orientated network service (CONS) may be provided by
X.25 (ISO 8202) as defined in ISO 8878|X.223. ISO 8881 extends X.25 for
use in local area networks, ISO 10732 describes some details of using
X.25 for providing the CONS over the telephone network and ISO 10588
describes how to use X.25 over X.21/X.21bis lines for providing the
CONS. ISO 10177 defines an intermediate system using X.25/CONS and ISO
10030 is the ESIS version for X.25/CONS. Using ISDN (the new digital
telefone network) for providing the CONS is specified in ISO 9574.

And another layer: the Data Link Service is defined in ISO 8886|X.212.
Most data link layer protocols are based on the High-level Data Link
Control (HDLC) family of error correction protocols. These are
described in the standards ISO 3309/4335/7478/7809/8471/8885. One
popular HDLC protocol is the subset LAPB defined in ISO 7776, which is
often used with X.25 on point-to-point lines. ISO 8802 (also known as
IEEE 802) defines several LAN systems, e.g. ISO 8802-3 is the well
known Ethernet (CSMA/CD) specification. ISO 8802-2 defines the data
link layer protocol for LANs Logical Link Control (LLC). LLC1 ist the
connectionless and LLC2 the connection orientated version. The Fiber
Distributed Data Interface (FDDI) is a fiber optic LAN system for 100
MBit/s specified in ISO 9314.

The Physical Layer Service Definition is defined in ISO 10022|X.211.
The physical layers of LANs are in most cases defined in the same
documents as the layer 2 descriptions. There are also many ISO and IEC
standards for all kinds of plugs and connectors.

OSI standards define a lot of options and they may be combined in a
huge variety of ways in order to be suitabe for all kinds of
requirements (and sometimes for political reasons :-( ). Consequently
if you have two boxes that claim to be OSI conforming, this doesn't
mean that you can plug them together and they will work together,
because they can e.g. use different lower layer protocols and different
higher layer options. In order to create standards that allow that
conforming and compatible products will interoperate, profiles have
been defined. A profile is a selection of options and combinations
defined in protocol standards that guarantees that implementations of
the profile will be able to communicate. Technical report ISO TR 10000
gives the ISO profile framework. 'A' profiles have been defined for
application layer protocols (e.g. AFT11 in the international
standardized profile ISO ISP 10607 for a simple FTAM file transfer
subset and AOM12 in ISO ISP 11183 is an enhanced management protocol
subset), 'T' profiles define layer 1-4 stacks (ISO ISP 10609) and 'F'
profiles are for file formats (e.g. FOD36 is a de luxe version of ODA).

A good list of all OSI related standards and their current status is
printed twice a year in the ACM SIGCOM journal Computer Communication
Review. A list of CCITT standards is available from the Teledoc mail
server described in the standards FAQ where you'll also find a short
list of other ISO standards relevant to computing. For more information
order the orange ISO Catalogue from your national ISO member body.


How are OSI and TCP/IP related?
-------------------------------

TCP/IP is a suite of protocols that have been developed by the US
Department of Defence and that are used on the Internet. Software
supporting TCP/IP is part of nearly every UNIX distribution today.
TCP/IP is not a OSI protocol and does not fit in the OSI reference
model. However, the service provided by IP is very similar to the
connectionless network service provided by CLNP and so IP is generally
called a layer 3 protocol. Similarly, TCP may be compared with TP4 and
can be seen as a layer 4 protocol in the reference model. The major
differences are the address space which is a 4 byte sequence in IP and
up to 20 bytes in OSI and the fact that TCP is a stream orientated
protocol that doesn't provide any protocol data unit boundaries. Other
details are a few missing features in TCP/IP like quality of service
negogiation and routing restrictions.

The Internet standard RFC 1006 defines a method of providing the
connection orientated transport service (COTS) for OSI over TCP. This
is done using a packet length indicator and the TP0 protocol. RFC 1006
is only an interim solution and there are long term plans to introduce
CLNP in the Internet. OSI Services that are used today on the Internet
(e.g. the X.400 and X.500 pilots) use RFC 1006 over TCP/IP.

The higher layer protocols in the DoD/Internet suite may be mapped as
follows:

       DoD/Internet                   OSI
     ----------------------------------------------------------------
       ftp                            FTAM
       RFC822, SMTP, MIME             X.400
       telnet, rlogin                 VT
       Gopher+, WWW                   DFR
       WAIS                           SR    (both are based on Z39.50)
       SNMP                           CMIP
       USENET                         X.gc
       X Windows System               (will be included in OSI)
       NTP                            (under consideration by CCITT)
       OSPF, ISIS                     ISIS

Internet Protocols with no OSI equivalent today:

       Relay Chat, IRC                OSI has only a standard name for this
                                      so far: synchronous group communication
       Talk                           might perhaps be defined as a VT profile

OSI protocols with no TCP/IP equivalent:

       X.500                          perhaps finger :-)
       JTM
       parts of DFR
       parts of X.gc
       RDA
       MMS
       Interlibrary Loan Protocol


Which is better: TCP/IP or OSI?
-------------------------------

This question periodically results in flame wars in comp.protocols.iso.
If you have missed the last one, here are a few opinions:

  Neither.  In theory, OSI has the more advanced feature set,
  including significantly more sophisticated application protocols
  including some for services not available at all in the TCP/IP suite.
  In practice, TCP/IP is much more widely implemented and deployed, so
  you are much more likely to find TCP/IP products to suit your needs,
  and typically at much lower prices than equivalent OSI products.

                                                  don provan
                                                  donp@novell.com

[Others are welcome!]


Which free OSI implementations are available?
---------------------------------------------

ISODE (pronounce it ISO-D-E, but don't call it the ISO Development
Environment) implements ISO layers 4-7 on UNIX systems. Among the
supported lower layer stacks are RFC1006/TCP/IP and various X.25 and
CLNP implementations. With ISODE you get ASN.1 tools and
implementations of X.500 (QUIPU) and FTAM. Version 8.0 is the last
public domain version and an ISODE Consortium has been founded that
will coordinate further development on a commercial basis. A free Patch
No. 1 with bug fixes for ISODE 8.0 has been provided by the ISODE
Consortium which can be ftped from isode.com.

The ISODE and QUIPU mailing list archives are available via anonymous
ftp and gopher from info.educom.edu. The isode and quipu are in
/pub/isode and /pub/quipu respectively.

PP is a X.400 message transfer agent and a gateway to other e-mail
systems based on ISODE. The current public domain version is 6.0 and
further commercial development will be done by the ISODE Consortium.

Both ISODE and PP are available from many anonymous ftp servers, e.g.
from cs.ucl.ac.uk in directory src.

OSIMIS is UCL's OSI management system. It does not intend to provide a
comprehensive set of OSI management facilities but rather to show how
the rich OSI Management functionality can be exploited and to provide
facilities of a generic OSI management platform. In particular,
extended support through an object-oriented (C++) Application Program
Interface (API) is provided to implementors of management applications
in both agent and manager roles, which hides the details of management
information access through the OSI management service/protocol CMIS/P.
The system has been developed using ISODE 7.0 and GNU C++. To get a
copy ftp to cs.ucl.ac.uk [128.16.5.31] and retrieve the file
proof/osimis-2.99.tar.Z as usual in binary mode.

[Posted by Peter Kay <P.Kay@massey.ac.nz>:]

The clients of ISODE 8.0 have now been ported to OS/2. (pepsy, pepy,
posy, rosy, isoc, imisc, ftam, dish, de and sd). They are available by
anonymous ftp from cc-vms1.massey.ac.nz (130.123.1.4), in the files
os2isode80.zip (for those who want to rebuild the system) or
os2isode-runtime.zip (for those who only want the executables). I
suggest you copy and read the file os2readme first.

The port was based on Essex Systems Inc TCP/2 package. It will NOT work
with any others. To run the programs you will need the TCP/2 package.
To rebuild the system you will also need its Developers Kit and the
Microsoft C v6.0 compiler.

[Posted by Graham Wheeler <gram@aim1.aztec.co.za>:]

An MS-DOS-based ESTELLE compiler/interpreter should be on simtel, in
the Networks directory, with the name PEW2_1.ZIP.


New and planned OSI standards
-----------------------------

A group is working on an 'asynchronous group communication' standard
based on X.400, X.500 and DFR. This will include a news system similar
to but more sophisticated then USENET and facilities for joint editing
of documents and voting/polling. The name of the draft document is
currently X.gc.

X.400(1988) has been extended by voice, EDI and file transfer body
parts and other details, many bugs in the specification have been fixed
and the new 1992 version is expected to be published very soon.

An addendum 1 (filestore management) to FTAM now defines a hierarchical
file system with subdirectories, links, paths etc. Previously, paths
have been long file names and were OS dependent (e.g. / in Unix, \ in
MS-DOS) and directories have been treated like files (e.g. '.').

HDLC has been extended by an asynchronous mode that defines how to use
the layer 2 framing with start/stop bits and byte stuffing on the ports
that are part of every PC. Check ISO 3309 addendum 1-3.

ISO is working on an OSI based remote procedure call standard (ISO CD
11578).


Books and Journals
------------------

[Posted by Even Splett <e_splett@trofs.enet.dec.com> and others with
comments collected by Khac Binh Su <kbs@ccr-p6.ccr.jussieu.fr> and
others:]

Data communications, computer networks and OSI
Halsall, Fred
549 p.
Addison-Wesley
ISBN 0-201-18244-0

Networking in open systems; international seminar, Oberlech, Austria,
Muller, Gunter. Blanc, Robert P.
Berlin, Springer-Verlag, c1987
Lecture notes in computer science; 248
441 p.
QA76.L42 v.248 1987
ISBN 3540177078

OSI explained; end-to-end computer communication standards.
Henshall, John,  Shaw, Sandy.
Ellis Horwood Ltd.
distributed by John Wiley & Sons Ltd.
217 p.
TK5105.5.H47
ISBN 0745802532  Ellis Horwood
ISBN 0470211008  Halsted Press

  Very good on transport and above, including a consolidation by 3
  examples that shows how the upper layers work together to extablish an
  association, transfer data, and release it. It also has a chapter each
  on FTAM, X.400, and X.500, but does very little with ASN.1, a real
  weakness in an otherwise excellent book.  Its other virtue: it is under
  250 pages.

Open systems; the basic guide to OSI and its implementation.
Judge, Peter J.
QED Information Sciences
Authorised reprint of -- Sutton, Surrey, Computer Weekly. (ISBN 1853840092)
184 p.
TK5105.5.J83  1989
ISBN 0894353101

Open Systems
Karial, Henry S.
JA71.K32 1969

OSI: a model for computer communications standards
Black, Uyless D.
Prentice Hall
TK5105.5.B5656  1991
ISBN 0-13-637133-7

The Open Book : A practical perspective on OSI
Rose, Marshall T
Tk5105.5.R67  1989
Prentice Hall
ISBN 0-13-643016-3

  It is fun reading, and it gives you the general idea about the whole
  stuff. One of its most interesting topics is transition: how to migrate
  to OSI from a TCP/IP oriented world. Excellent, but not cheap. In
  Germany it is 150,-- DM.

  I started with Marshall T. Rose's The Open Book - a practical 
  perspective on OSI by Prentice-Hall. It came out in 1991 so it is quite
  up to data, but not cheap (at least in Finland).

  Its not a exclusive book on the upper layers of the OSI.  Nevertheles,
  his presentation of the upper layers in a couple of chapters is 
  sufficient enough to start.

Complete guide to ISO protocols Vol 1
Thomas, Steve
Springer Verlag
ISBN 0387970231

Handbook of computer communications standards Vol 1
The open systems interconnection (OSI) model
Stallings, William   1989
ISBN 0-672-22664-2 Howard W. Sams & Company
ISBN 002948071x    Macmillan

  This book is OK, but lacks the finer details.

An introduction to open systems interconnection
MacKinnon, Dennis
254 p.
Computer Science Press  1990
TK 5105 M3335  1990
ISBN 0716781808

Standards for open systems interconnection
Knowles
Blackwell Scientific Publications
ISBN 0632018682

OSI in microcomputer LANs
Strom, Jim.
125 p.
Manchester: NCC Publications, 1989.
TK 5105.5 S87  1989
ISBN 0850127114 (pbk)

ASN.1, The Tutorial and Reference
Douglas Steedman
Technology Appraisals, Grove House, 551 London Road, Isleworth
(FAX 44 81 569 9569)
ISBN 1 871802 06 7

OPEN SYSTEMS INTERCONNECTION
by Gray DICKSON and Alan LLOYD
Prentice Hall Australia  (1992)
ISBN 0 13 640111 2

ISODE 8.0 Manual

  The ISODE  manual is a nice reference material if you are looking for
  implementation details of the upper layers. In fact, looking at ISODE
  code is probably the best way to see how the "theoritical" stuff
  applied.

Teleinformatique by Nussbaumer,
published by Presses polytechniques
romandes (french version)

  The vol 3&4 are the best books available in french for the upper
  layers.

Computer Networks by Andrew Tannenbaum

  This book explains accurately the general aspects of problems up-to
  layer 6. Layer 7's description is a bit vague

  A very nice introduction in computer communication that also covers OSI. 
  Highly recommended for cumputer science students!

Communication Network Protocols - OSI Explained
Brian W. Marsden
Chartwell-Bratt (UK)
1991 (3rd edition)
ISBN 0-86238-276-9

  It is extremely idiosyncratic, and should not be read except in
  conjunction with another book. Also, only some of it is about OSI. It
  is, however (a) very cheap (15 UK pounds), and (b) the only book I know
  of which talks about the UK Coloured Book protocols. These had a major
  impact on some parts of OSI, particularly JTM, as well as being
  interesting in their own right.

[End of osi-protocols FAQ]

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
----- Anyone participating in the use of MS-DOS, Heroin or Cocaine is -----
---- simply not getting the most out of life possible. (Brian Downing) ----