How to implement OSI protocols?

Thread View: comp.protocols.iso

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Alexander Bochannek Sat, 11 May 1991 15:37

#1243

Author: Alexander Bochannek
Date: Sat, 11 May 1991 15:37

44 lines
2304 bytes

Hi!

Let me quote Marshall T. Rose "In OSI, a reference model is used to describe
computer communications. The Model is inherently abstract. It does not specify:

- programming language bindings,
- operating system bindings,

..."

So, what does this mean? It means, everybody is free to implement the protocols
as he likes. But, hey, we have this neat layer structure and we have this 
primitives.
I don't know ISODE in detail, so I don't know how the inter-protocol communi-
cation is made. What does the community think about this approach:

- each protocol is one seperate process (I know what Comer thinks about this)

- inter-protocol communication is through an IPC facility (I vote for a mixture
  of messages and shared memory, but this is yet to be discussed)

- through this communication path the protocol processes send primitives

- the configuration of which process is allowed to talk to which other is (in
  the best case dynamically) handled by one central networking daemon

- the files associated with each protocol could be hold in a seperate directory
  structure like /net/layer-number (This is because it is frustrating to search
  for configuration files throughout the whole system)

- the hardware access part (layer one and MAC for Ethernet) need not necessarily
  be implemented as a device driver but as the same kind of process as the other
  layers (for exchangeability's sake)

These are just some ideas which came to my mind reading OSI books and being
frustrated with my daily work administering our local TCP/IP net and the
connection to the Internet.

OK, if anybody out there likes these ideas, wants to discuss them or just likes
to flame me because I'm sooo stupid and ISODE already has similar or better 
features, email me.

Alex

How (not) to implement OSI protocols

#1245

Author: John A. Shriver
Date: Mon, 13 May 1991 15:01

16 lines
1243 bytes

I would think that this would create the sort of slow non-performing
ISO implementation that gives new protocol implementations a bad name.

There was once an implmentation of TCP/IP for V6 UNIX on a PDP-11/45
that was provided by BBN, that was architected in a way reminiscent of
what you describe.  On a 1 Mbps token ring LAN, the Telnet protocol
implementation ran at 300 baud with 100% CPU utilization.

I know of commerical products that have used architectures like this,
and have been reviled for their atrocious performance.

I would strongly recommend reading RFC 817: Clark, D.D., "Modularity
and efficiency in protocol implementation", July 1982.  While it is
about the IP protocol suite, it is every bit as appropriate to
avoiding ISO implementations that are strangled by their own Computer
Science elegance.

Re: How to implement OSI protocols?

#1244

Author: Carl S. Gutekunst
Date: Mon, 13 May 1991 15:59

32 lines
2091 bytes

>It means, everybody is free to implement the protocols as he likes.

No, the language and operating system bindings can be done however you like.
(And in fact, they are done lots of different ways.) The protocols, however,
are defined by the standards.

Various industry groups (including X/Open and UI) are busily working to define
bindings. This is a very good thing, IMHO. But it is a very different thing
from defining protocols. I just reviewed two different application programmer
interfaces to X.25. They were quite a bit different, and have consider effect
on the architecture of the programs that would use them. But the X.25 packet-
layer protocol is unaffected.

>- each protocol is one seperate process (I know what Comer thinks about this)

The preferred implemention in commercial UNIX these days is each protocol (or
other logical division) in a streams module, in the kernel. Applications chose
the pieces that they need, and string them together. For example, an X.400 '84
RTS would push an appropriate transport and the session layers; an X.400 '88
RTS would also need to push the presentation layer and ACSE.

>These are just some ideas which came to my mind reading OSI books and being
>frustrated with my daily work administering our local TCP/IP net and the
>connection to the Internet.

Um, if you are frustrated administering a TCP/IP network, you ain't seen
nothing yet. Present day OSI stacks require vastly more administrative work,
as well as far more network understanding, than any modern TCP/IP network. We
are a long way from even designing (let alone implementing) the tools that
will make the OSI stack easily managable.

<csg>

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads