🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.protocols.iso
Article #1097

Re: X.25 collisions

#1097
From: Jon lnes
Date: Sun, 03 Feb 1991 18:41
32 lines
2888 bytes
About RESTART collisions, X.25 operation in LANs, and selection of DTE or
DCE mode for channel number allocation:
In a LAN, an X.25 DTE implementation must operate separate DTE entities for
each communication partner, as opposed to the one-to-one operation of a
conventional DTE-DCE pair. Thus, one node may well act as a DTE for
communication with another node, and as a DCE towards a third node. This
may be an administrative pain, but it is perfectly possible to configure
the information statically.
To relieve the network administrator of this work, it is better to go for
a more dynamic solution, and one option is the RESTART procedure for
selecting DTE or DCE characteristics. The main point is: You do not want
to restrict your communication partners to a preconfigured set. If you need
to talk to a new node via X.25/LAN, just create a new DTE-entity, and issue
a RESTART. Our X.25 on Ethernet UNIX kernel implementation creates DTE
entities in mbufs when necessary, and deletes inactive entities when a
timer goes off. We implement the RESTART procedure, and we believe we can
handle the RESTART collision situation properly.
However, the easiest solution is to use the Reference Number Facility -
another of these ISO afterthoughts/addendums. With this facility, a DTE
originating a CALL uses channel number 0, and includes in the facility the
actual channel number for the partner to use. The partner sends the CALL
CONFIRMATION on the indicated channel, and includes the Reference Number
Facility stating its own selected number. Thus, the two partners will use
different channel numbers for incoming and outgoing packets on the same
channel. With this solution, the CALL COLLISION situation disappears, and
the RESTART procedure can be skipped.
We implemented the Reference Number Facility as well, and although in many
aspects it is an ungly hack, it makes things a lot more easy. The facility
should be mandatory for X.25/LAN operation.

Jon Oelnes, Norwegian Computing Center, Oslo
E-mail: Jon.Olnes@nr.no    or     jon@ifi.uio.no
Technical Details
Message-ID: <CMM.0.88.665606495.jon@gode.ifi.uio.no>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!nuug!ifi!jon
References: <WS.91Jan25190808@karl.tools.uucp> <CMM.0.88.665054845.jon@gode.ifi.uio.no> <143094@pyramid.pyramid.com> <1991Feb1.095514.7003@informatik.uni-erlangen.de>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!nuug!ifi!jon
From: jon@ifi.uio.no (Jon lnes)
Newsgroups: comp.protocols.iso
Subject: Re: X.25 collisions
Message-ID: <CMM.0.88.665606495.jon@gode.ifi.uio.no>
Date: 3 Feb 91 18:41:34 GMT
References: <WS.91Jan25190808@karl.tools.uucp>
        <CMM.0.88.665054845.jon@gode.ifi.uio.no> <143094@pyramid.pyramid.com>
        <1991Feb1.095514.7003@informatik.uni-erlangen.de>
Sender: jon@ifi.uio.no (Jon \lnes)
Organization: Dept. of Informatics, University of Oslo, Norway
Lines: 32
Nntp-Posting-Host: gode.ifi.uio.no
In-Reply-To: dkhusema@immd4.informatik.uni-erlangen.de (Dirk Husemann)'s
        message of 1 Feb 91 09:55:14 GMT
Originator: jon@gode.ifi.uio.no