🚀 go-pugleaf

Hey line eater, for all you do, this line's for you.

In article <424@gould9.UUCP> joel@gould9.UUCP (Joel West) writes:
>Could someone please help me out?  I'm familiar with TCP/IP, and, to 
>some degree, X.25.  I've even heard of MAP.  But what does it mean when 
>someone says they will be using the "ISO" protocol?

It means that they will be using some or all of the hundreds (literally) of 
protocols ISO and/or CCITT are suggesting now or have in the past six to ten 
years.  It also means that they want you to buy their product.

Find out what they mean.  A good default is (layer 1) rs-232-c/v.35; (layer
2) LAP B; (layer 3) X.25.  They may also support such things as X.75 but don't
bet on it.  Layers 4 and up will be their own protocols.

>What does it mean, "DECNET will conform to ISO?"

It means DEC wants you to buy DECNET.

>To get to the bottom line, is the standard well-defined enough that I can 
>write an "ISO driver" that will talk to an arbitrary box some point in the 
>future?  
>
No.  The standards for layers 4 and up are WAY up in the middle of the air (see
that wheel inside that other wheel?)

Dan'l Danehy-Oakes


"And as for all their tempting ideas,
 well, Hare didn't care.
 The lost spectacles were his own affair.
 And (after all) Hare did have a spare
 pair."

Jethro Tull

It is also worth mentioning that I don't think anyone has yet found a
criterion by which "ISO" is somehow "better" than the ARPA protocol suite,
other than its well-trumpeted status as a "future world standard". In fact,
in many ways the ISO network and transport protocols are demonstrably worse
than IP/TCP.

Given that two hundred years ago a system of weights and measures was
invented in Europe that (unlike ISO protocols) is simpler, easier to use and
without question far superior to what was in common use in the US, and given
that two hundred years later we're still not using it, I'm not holding my
breath for an overnight conversion to ISO.

Phil Karn

> /* Written  7:04 pm  Apr  3, 1986 by djo@ptsfd.UUCP in ico:net.dcom */

> It means that they will be using some or all of the hundreds (literally) of 
> protocols ISO and/or CCITT are suggesting now or have in the past six to ten 
> years.  It also means that they want you to buy their product.
Partially true, but misleading.  There are indeed a number of
protocols definede, but they are at a number of different levels of
the reference model. 

> Find out what they mean.  A good default is (layer 1) rs-232-c/v.35; (layer
> 2) LAP B; (layer 3) X.25.  They may also support such things as X.75 but don't
> bet on it.  Layers 4 and up will be their own protocols.
Some good advice.  Anyone buying or implementing ANY protocol should
find out what they mean.  You really need to know what the standards
are for each layer.  This is true for protocols such as TCP/IP as well
(just because two vendors support TCP/IP doesn't mean that they
support the same physical media).  As far as layer 1 is concerned, ISO
has already adopted the IEEE 802.{3,4} families.  There are standards
at Layers 1-5 and Draft International Standards at layers 6 and 7.  To
be a real ISO network, you must support the standards at all layers.
Some vendors will have their own protocols at the higher layers for
services specific to that vendor.  There are also "national"
guidelines for the implementation of the various protocols to ensure
conformance between the various vendors.  For example, the National
Bureau of Standards will soon issue an X.400 product description which
specifies which options are mandator/optional/etc. for a US
implementation of X.400.  Similar specifications exist for other
protocols such as transport. 

In essence, it will be possible to build an ISO-OSI product that will
work with other vendors implementations.  The MAP and TOP
specifications are just such a set of guidelines.  TOP specifies such
things as IEEE 802.3 as the physical layer, IEEE 802.2 as the link
layer, ISO connectionless network protocol at the network layer,
ISO transport class 4 (NBS spec) for the transport layer, ISO session
(specific subsets) at the session layer, ISO ASN.1 at the presentation
layer and ISO FTAM and CASE at the application layer.  There is more
to it than just those, but this list specifies a full ISO protocol
suite at all layers.  By implementing to the specifications,
compatible implementations can be made.  The vendors are also working
together to pass conformance tests on their products.

> >What does it mean, "DECNET will conform to ISO?"
> It means DEC wants you to buy DECNET.
It also means that DEC will provide ISO transport protocols on DECNET.
They will probably provide some of the higher level protocols as well.
They have announced availability of ISO transport class 4 already.

> No.  The standards for layers 4 and up are WAY up in the middle of the air (see
> that wheel inside that other wheel?> )
Not true!  Standard protocols exist for layers 4 and 5.  Layers 6 and
7 have gone to DIS form (Draft International Standard) and are
supposed to go for 6 month ballot in June.  There should be
International Standards at all 7 layers by the end of 1986.  Standards
DIS level are also stable enough for an initial implementation.
Transport has been a standard for quite some time.  Session a little
less, but it has been about a year.

For some additional information on how real OSI is, the March 1986
issue of "Computer" (IEEE Computer Society) has an article in it's
Standards section (page 97) about making OSI work.

Also, the March 1986 issue of IEEE Spectrum has articles about TOP and
MAP.

In article <102@ico.UUCP> dougm@ico.UUCP (Doug McCallum) writes:
>Not true!  Standard protocols exist for layers 4 and 5.  Layers 6 and
>7 have gone to DIS form (Draft International Standard) and are
>supposed to go for 6 month ballot in June.  There should be
>International Standards at all 7 layers by the end of 1986.  Standards
>DIS level are also stable enough for an initial implementation.
>Transport has been a standard for quite some time.  Session a little
>less, but it has been about a year.

I beg to differ.  It isn't officially adopted as a standard until the
big books come out every four years (1988 books due out around 1989).

Dan'l Danehy-Oakes


"The opinions expressed above are no one's but my own, and especially do
not represent the opinion of the person to whom I am responding."

> In article <102@ico.UUCP> dougm@ico.UUCP (Doug McCallum) writes:
> >Not true!  Standard protocols exist for layers 4 and 5.  Layers 6 and
> >7 have gone to DIS form (Draft International Standard) and are
> >supposed to go for 6 month ballot in June.  There should be
> >International Standards at all 7 layers by the end of 1986.  Standards
> >DIS level are also stable enough for an initial implementation.
> >Transport has been a standard for quite some time.  Session a little
> >less, but it has been about a year.
> 
> I beg to differ.  It isn't officially adopted as a standard until the
> big books come out every four years (1988 books due out around 1989).
> 
> Dan'l Danehy-Oakes

Well, to correct the correction, I wasn't incorrect (at least not
completely).  The standards I was refering to are "ISO" standards, not
CCITT.

In the 1984 CCITT Red Books (note the 1984 and CCITT) CCITT is
publishing the Layer 4 (X.224) and Layer 5 (X.225) standards.  Also,
they are publishing the X.400 family.  X.409 is very similar to the
ISO Abstract Syntax Notations which is part of the layer 6 standard
and the rest of X.400 covers an application layer protocol, etc.  That
covers most of the bases.

Now the real clarification.  ISO and CCITT are not the same thing.  I
should have been more careful in specifying which standards body I was
referring to.  The adoption procedure within ISO is a little faster
than within CCITT.  ISO standards get approved at TC97 meetings which
happen on the order of once per year.  CCITT standards are approved at
the end of 4 year study periods.  Then there are the various national
standards bodies that all have different rules.

				Doug McCallum
				Interactive Systems Corp.
				{ima, hao, cbosgd}!ico!dougm

> > >Not true!  Standard protocols exist for layers 4 and 5.  Layers 6 and
> > >7 have gone to DIS form (Draft International Standard) and are
> > >supposed to go for 6 month ballot in June.  There should be
> > >International Standards at all 7 layers by the end of 1986....
> > >Doug McCallum

Can someone clarify for me how layer 7 can be standardized without
knowing the application?   I think the difficulty in making higher
layer protocols is that you can't optimize them for a variety of
services.  I'm working from a context of metropolitan area networks
(basically grown from LANs) where one hopes to have integrated
services (data, voice, video - the usual catch-words).  You can't
even run these all through the same MAC (physical/data-link) level
never mind transport and session layers.

What do these proposed layer 4-7 protocols do, and what kinds of traffic
do they apply to?

-Mark Garrett
Bellcore

In article <76@petrus.UUCP> karn@petrus.UUCP (Phil R. Karn) writes:

> It is also worth mentioning that I don't think anyone has yet found a
> criterion by which "ISO" is somehow "better" than the ARPA protocol suite,
> other than its well-trumpeted status as a "future world standard". In fact,
> in many ways the ISO network and transport protocols are demonstrably worse
> than IP/TCP.
> ...

Please post some additional information supporting this statement.  I
would be the first to agree that the ISO standards are not perfect, but I
am curious as to why you believe TCP/IP is better.
-- 
Stephen J. Langdon                  ...!{ihnp4,cbosgd,hplabs,sun}!amdahl!sjl

[ The article above is not an official statement from any organization
  in the known universe. ]

> Can someone clarify for me how layer 7 can be standardized without
> knowing the application?
> ...
> -Mark Garrett
> Bellcore

There will be many layer 7 protocols.  It depends on the application.  The
MAP standard will include several:

	FTAM	File Transfer, Access, and Management (from the ISO)
	CASE	Common Application Service Element (from the ISO)
	MMS	Manufacturing Message Service (from the EIA)

More will be defined as the need arises.  Some working groups within ISO,
ANSI, and other organizations are working on virtual terminal protocols,
data base access protocols, job transfer protocols, and you-name-it
protocols.  I hope they don't make them mutually exclusive on a single LAN.

-----------------------------------------------------
Frederic W. Brehm       (ihnp4!princeton!siemens!fwb)
Siemens Research and Technology Laboratories
105 College Road East
Princeton, NJ 08540
(609) 734-3336

> Can someone clarify for me how layer 7 can be standardized without
> knowing the application?   I think the difficulty in making higher
> layer protocols is that you can't optimize them for a variety of
> services.  I'm working from a context of metropolitan area networks
> (basically grown from LANs) where one hopes to have integrated
> services (data, voice, video - the usual catch-words).  You can't
> even run these all through the same MAC (physical/data-link) level
> never mind transport and session layers.
> 
> What do these proposed layer 4-7 protocols do, and what kinds of traffic
> do they apply to?
> 
> -Mark Garrett
> Bellcore

There are "classes" of application that are known.  For example, File
Transfer and Access (FTAM), electronic messaging (X.400), etc.

If you look at the function of each layer, you can see that it is
possible to standardize a lot of the common functions that are
supposed to be done at a particular layer.

Session basically manages a transport session and de-multiplexes a
transport connection a little further.  (Transport gets you to a
protocol and session gets you to the application)  There is also the
possibility of checkpointing a session to avoid having to restart at
the beginning in the event of a transport failure.

Presentation is supposed to manage data types between the two
applications.  ASN.1 (part of the presentation protocol) defines an
encoding for data that is machine independent (perhaps in a more
complex way than is necessary).  Character sets, etc. are also handled
at this layer.

Application is supposed to define a set of common primitives for
classes of applications.  FTAM defines the protocol for accessing and
manipulating files.  CASE defines a set of Common Application Service
Elements from which other application layer protocols can be built.
Other application layer protocols in the works are a "virtual
terminal" protocol for remote login and a "directory services"
protocol for accessing a network directory.

It isn't possible to define a standard for every application yet to be
conceived, but it is possible to define them for the common classes of
application.  There will be a lot of vendor specific protocols
providing services which aren't standardized.  Some of these vendor
specific protocols may eventually become the basis for new standards.
With user groups such as the GM-MAP group, standards can gain
acceptance and even convince some vendors to support the standards.

As a disclaimer, I don't necessarily feel that the OSI standards are
better than other network protocols, but it appears that they are
gaining acceptance.  A LOT of vendors have announced support and a
relatively large number have shown implementations at such trade shows
as NCC and Autofact.

Hope this helps,
			Doug McCallum
			{cbosgd, hao, ima}!ico!dougm

Sounds like we've got some experts out there who understand FTAM.  Let
me pose a question I've been wondering about for awhile.

How does FTAM compare with network filesystems such as Sun's NFS, AT&T's
RFS, and IBM PC type file service networks?  Is FTAM a suitable replacement
for these systems, or does it do the same thing, just not as well, or is
it strictly an FTP replacement?  Does anyone care to predict the evolution
of remote filesystems as OSI becomes pervasive?

	Mark

We have been running ISO and TCP-Ip in parallel for some time now at INRIA.
This will be reported in the next USENIX conference. Each has pro and
contras, so lets state the advantages:

For TCP-IP:
Already established, comes with a lot of applications likes FTP, TELNET,
RLOGIN, SMTP, RSH, etc. Available today on a large range of computer. This is
not the case of ISO: the only standard application available today is X400,
and in a certain sense the Teletex.

For OSI:
Getting agreed upon by a large number of manufacturer. Technically much
better than TCP-IP, which hardly matches the services of the OSI transport,
but does none of the functionalities of the session or presentation layers.

We are running OSI on X25 and on Ethernet. We use X25 layer 3 on Ethernet,
according to DIS8881, above IEEE802.2 LLC1. We establish X400 connections
on an operational basis we other systems in UK and Germany; note that the
OSI was independantly developped on these systems. It is extremely easy to set
up a random connection using the OSI protocol and X25 networks, whilst to do
the same with IP you have to formally interconnect networks.

From an architectural point of view, ISO gives you the choice between
connection oriented and connectionless networks. In the latter case of
ISO-IP & TC-4, you have exactly the same repartition of function has with IP
& TCP, with one advantage to IP due to short headers: the IP adresses are 32
bits, while the ISO NSAP addresses can be 20 bytes. On the other hand, there
is a possibility with TC4 to negociate the usage of transport level checksum
on a per-connection basis.

We have measured almost the same throughputs for TCP and the OSI session, in
file transfer applications. The OSI code is slightly smaller than the TCP
code in the kernel (both are implemented as "sockets" protocols).

Christian Huitema (<huitema@gipsy.uucp>)