Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!caen!zaphod.mps.ohio-state.edu!rpi!uupsi!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: Date: 28 Jan 91 09:27:25 GMT References: Sender: jon@ifi.uio.no (Jon \lnes) Organization: Dept. of Informatics, University of Oslo, Norway Lines: 23 Nntp-Posting-Host: gode.ifi.uio.no In-Reply-To: ws@tools.uucp (Wolfgang Solfrank)'s message of 25 Jan 91 18:08:08 GMT To: ws@tools.uucp (Wolfgang Solfrank) Originator: jon@gode.ifi.uio.no According to my interpretation of X.25 you are right, and the state tables are wrong. Examining the ISO sources for X.25 DTE operation (ISO8208) I found the same error: E.g. receiving a CLEAR INDICATION after sending a CLEAR REQUEST leads to a transition to the CLEAR INDICATION state according to the tables, while according to the text, the Clear procedure is completed, and the state transition should be to state READY. Note that for RESTART packets one condition exists where a RESTART collision requires a repeated RESTART procedure: If communication is from one DTE to another woth no intervening DCE (e.g. when using X.25 in a LAN), and the Reference Number Facility is not used for channel number allocation. In this case one DTE is required to act as a DCE for channel number allocation - which one is determined from the RESTART procedure. The DTE sending the RESTART will continue to act as a DTE, while a DTE receiving a RESTART (from another DTE) will act as a DCE for channel number allocation. This situation is not resolved if a RESTART collision occurs. Apart from this rather exotic case, a RESTART/CLEAR/RESET collision completes the procedure - presumably both ends detected the same error. Jon Oelnes, Norwegian Computing Center, Oslo E-mail: Jon.Olnes@nr.no or jon@ifi.uio.no