NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/protocol/iso/1443

Internet Message Format | 1992-12-22 | 4.0 KB

Path: sparky!uunet!pipex!bnr.co.uk!stc!iann
From: [e-mail] (Ian Newman)
Newsgroups: comp.protocols.iso
Subject: Re: OSI and standard modules (like packet) ?
Date: 22 Dec 1992 10:24:51 GMT
Organization: BNR Europe, New Southgate, London.
Lines: 69
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: bnsgs152.bnr.co.uk

In article <[e-mail]> [e-mail] writes:
>[e-mail] (Jan Ferre') writes:
>
>>Now here's my proposal: Why not define a set of interfaces for specific
>>computerseries and especially for specific operating systems in order to
>>ease PD programmers to get started. I suggest something like:
>>   Interface to TP is done via device OSITP on DOS.
>>   Packets to the interface are submitted as struct { bla bla bla } and the
>>   results will be returned as struct {blu blu blu}.
>
>Excellent idea! Why don't you start writing a proposal, post it here,
>then we'll discuss it and then we'll see whether anyone wants to
>write a demo implementation.

What is the difference between what you're planning to propose and what AT&T's
TLI (Transport Library Interface) does for you at Transport Layer? In fact,
X/Open have their XTI (X/Open Transport Interface) standard and their XAP
(X/Open Application/Presentation) interface standard, which is the equivalent
of AT&Ts APLI (Application/Presentation Library Interface), etc. There are
alos X/Open draft standards for local syntaxes etc (e.g. XOM).

>>It should be possible to identify several 'cuts' in the 7 layer model - in
>>fact a cut is needed at least for every possible split possibility: In the
>>Nordic Government OSI Profile there should be a cut to provide for 8802-3
>>and -5, a cut to provide for 8878 as contrast to 8473, a cut for 8073, and a
>>cut in 8650 to provide interface for the different layer 7 applications.
>
>I would suggest only 2 cuts: one cut near the network layer and
>one cut that offers ACSE, RTSE and ROSE to the higher layers together
>with BER/PER/... parsing service (that's what application programmers need if
>they want to implement a FTAM client prototype within a few days.)
>The cut within the network layer need not necessarily be one of the
>cuts in the OSI RM. The module below the near-network-cut should
>contain the network specific software (e.g. an async HDLC/X.25 driver
>for COM1 and COM2, an CLNP driver over a packer driver, a 'for further
>study' CONS module using AX.25, etc.). The module between the two cuts
>would perform all the OSI protocol machinery (from transport to ROSE)
>in which both the network and the application programmer aren't very
>interessted.

You are confusing 'cuts' with interfaces, surely? Interfaces should be defined
at the Transport Layer (since this is the basic Transport service), and then
probably above ACSE/Presentation, to provide a basic Application service,
suitable for any Application Process.

Combinations of protocols are generally referred to as 'profiles'. This is a
different issue.

>>My dream (let's call it a wish for christmas) is to go to SIMTEL to get
>>layer 1,3,5, to buy layer 2 and 7 from IBM and to buy layer 6 and 4 from
>>Nonsence-soft in Yougoslavia. Or at least to be able to get hold of
>>resonable modules from different sources.

You can do that now with the lower 4 layers! Most Transport products for
workstations (e.g HP, Sun, etc.) will conform to a standard TLI (either
AT&T or X/Open - these are virtually identical anyway).

>Perhaps a seperate module for each OSI RM layer isn't even necessary.
>Developing nice APIs is a lot of work, so let's concentrate on a few only!

Agreed! Let's use the ones that are available!

Ian.

--
-----------------------------------------------------------------------------
Ian Newman, BNR Europe Ltd.,              | [e-mail]
Transmission Software Development (Dept. GM21),     | Phone : [phone]
Oakleigh Road South, London N11 1HB, UK.      | Fax   : [phone]