🚀 go-pugleaf

Some added trivia below:

In article <1992Oct28.185442.13371@us-es.sel.de>, watson@us-es.sel.de (Gary Watson (US/ESB)) writes:
|> In article <Bwn2LB.DxA@immd4.informatik.uni-erlangen.de>, mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn) writes:
|> 
|>    [ ... snip, snip]
|> 
|> |> >3. What are intermediate steps between that and X.25? (Layers 2&3)
|> |> 
|> |> Layer 4: TP0, a quite simple transport protocol
|> |> layer 5: the session layer protocol (which I still haven't understood in
|> |>          detail :-)
|> |> layer 6: the presentation layer protocol (perhaps including the optional
|> |>          old 1984 version)
|> |> layer 7: The common application service elements ACSE and RTSE for
|> |>          association control (handshaking) and reliable transfer of huge
|> |>          messages and the X.400 specific MTSE message transfer service
|> |>          element which is already a part of X.400.
|> 
|> X.25 is really only layers 2 & and the lowest sub-layer of layer 3.
|> There are two possibilities for the choices of protocols in the remainder
|> of layer 3 and for layer 4. These can
|> be either :-
|> 
|>      X.25 SNDCP - CNLP - TP4

There also exists a "connectionless transport" entity, however, there
currently are no application profiles (in approved GOSIP's) which
utilize this stack.  Maybe once a full connectionless stack (including
ROSE) is available more interesting ideas will come forth.

|> 
|> OR
|> 
|>      CONS - TP0 (whatever became of 1,2 & 3)

To be complete (NOTE - CONS is a service (as you state below), and
TP0 and X.25 are protocols.  This is always presented in a confusing
fashion, even in standards and other publications):

	X.25 - TP0 (TP4 and TP2 are also acceptable) 

I have not seen a registered profile showing either TP1 or TP3.  Hopefully,
we can at least kill off these two unused options.  However, I'm sure
someone with nothing better to do will invent a profile for these
options as well.

NOTE - the information you supplied above also points out the fundamental
problem with todays implementor's agreements.  Specifically, the existence
of the two network layers effectively fragments the world.  This has been
pointed out many times and TCP/IP folks laugh at OSI ignorance, yet I have
seen no concrete evidence that this issue is disappearing.  In fact, the
TCP/IP "TUBA" community may do more to synergize the OSI world than the
OSI comminity has in the last 8 years.  How's that for irony!!!!

|> 
|> Where the X.25 SNDCP (Subnetwork Dependent Convergence Protocol for X.25 or
|> something like that) basically converts the connection oriented service offered
|> by X.25 to a connection-less service suitable for use by the next highest layer
|> 3 sub-layer, CNLP. CNLP is the Connectionless Network Layer Protocol which is
|> basically the ISO equivalent of the DoD IP. TP4 is Transport Protocol Class 4
|> which is (I think) the only ISO Transport Protocol capable of operating over
|> the kind of unreliable connectionless service offered by CNLP.
|> 
|> CONS is the Connection Oriented Network Service. I don't know if there is also
|> the usual accompanying protocol since it doesn't really do very much. It really
|> only acts as a bit of glue between X.25 and the Transport layer, I don't think
|> any PDUs are exchanged. Some CONS implementations can perform through routing
|> based on the (source, destination) NSAPs which CONS sends as User Data in the
|> X.25 Connect Request.

The concatenation of X.25 connections used to be known as the 
CONSIWU (CONS InterWorking Unit??).  I forgot where this is defined,
however, one place it is required is when concatenating LANS and WANS in
a CONS environment.


|> 
|> -----------
|> Gary Watson 

As with all network trivia, you get what you pay for, and some
times you even get less.......