ws@tools.uucp (Wolfgang Solfrank) (01/26/91)
I'm trying to make sense out of Annex B and C of the Blue Book Recommendation X.25. According to Annex B, there is no transition between states r2 and r3, p6 and p7 and d2 and d3 resp. The interface goes from r2 to r1 on transfer of a restart indication, from p6 to p1 on transfer of a clear indication and from d2 to d1 on the transfer of a reset indication. But in Annex C it says the DCE should, when receiving some invalid packet, send a restart indication with "Local procedure error" and enter state r3. Similarly the DCE should send a clear indication in state p6 and enter state p7, and a reset indication in state d2 and enter state d3. The description in the recommendation itself seem to favor the interpretation according to Annex B: 3.3.3 Restart collision Restart collision occurs when a DTE and a DCE simultaneously transfer a restart request and a restart indication packet. Under these circumstances, the DCE will consider that the restart is completed. The description of the procedures for clear collision in 4.1.9 and for reset collision in 4.4.3.3 are similarly phrased. (These even explicitly specify a state transition to state p1 and d1 resp.) All this seems to imply that Annex C is wrong, but as an annex "forms an integral part of the Recommendation" I want to be shure. Can someone shed a little light on this? -- ws@tools.uucp (Wolfgang Solfrank, TooLs GmbH) +49-228-230088
jon@ifi.uio.no (Jon lnes) (01/28/91)
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
csg@pyramid.pyramid.com (Carl S. Gutekunst) (01/31/91)
>According to Annex B, there is no transition between states r2 and r3, p6 >and p7 and d2 and d3 resp.... But in Annex C it says the DCE should, when >receiving some invalid packet, send a restart indication with "Local >procedure error" and enter state r3. You are confusing NORMAL conditions and ERROR conditions. The Annex B state diagrams cover only normal operation; Annex C covers all states and condi- tions (except for timeouts), and ERROR conditions in particular. So yes, r2 to r3, p6 to p7, and d2 to d3 transitions are all missing from Annex B, but so are several other "error" transitions. Collision is a NORMAL condition, not an ERROR, and is covered by both Annex B and C. Look at Table C-2/X.25, under the r3 column, first event (Restart Request). This is the collision case, and the table specifies that you go to state r1. An invalid packet is an ERROR condition, and is covered only by Annex C. <csg>
csg@pyramid.pyramid.com (Carl S. Gutekunst) (02/01/91)
In article <CMM.0.88.665054845.jon@gode.ifi.uio.no> jon@ifi.uio.no (Jon lnes) writes: >In this case one DTE is required to act as a DCE for channel number >allocation - which one is determined from the RESTART procedure. Also note that this procedure is found exclusively in ISO8882; X.25(1984) does not consider DTE-DTE operation at all. And, according to ISO 8208 Addendum 3, this procedure is optional. I don't like it for the reason Jon mentioned: in the case of Restart collision (which for most equipment happens every time frame level is established), you can theoretically get into a race. ISO says to use a "randomly chosen time delay" for retransmitting the Restart. Random?! Sure.... Better to just hard-configure one of the DTEs as a DCE. And in fact, ISO recommends this as preferable, in fine print after the specification for the auto-selecting Restart procedure. (Actually, the ISO "X.25" documents contain a number of extensions like this that just aren't a very good idea. Setting T1 on REJ frames, for example.) <csg>
dkhusema@immd4.informatik.uni-erlangen.de (Dirk Husemann) (02/01/91)
csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >In article <CMM.0.88.665054845.jon@gode.ifi.uio.no> jon@ifi.uio.no (Jon lnes) writes: >>In this case one DTE is required to act as a DCE for channel number >>allocation - which one is determined from the RESTART procedure. >Also note that this procedure is found exclusively in ISO8882; X.25(1984) does >not consider DTE-DTE operation at all. And, according to ISO 8208 Addendum 3, >this procedure is optional. I don't like it for the reason Jon mentioned: in >the case of Restart collision (which for most equipment happens every time >frame level is established), you can theoretically get into a race. ISO says Theoretically, okay, but I think it should be possible to make that time delay random enough, to get that procedure working. >to use a "randomly chosen time delay" for retransmitting the Restart. Random?! >Sure.... Better to just hard-configure one of the DTEs as a DCE. And in fact, - well, I think that just works fine as long as you stay inside your local net (IEEE 802 net, e.g.), yet - IMHO - difficulties arise, once your DTE starts communicating with a DTE on a net not administrated by yourself (e.g. your DTE is on a IEEE 802.3 net, the call leaves this net via a level 2 router - not an IWU - enters another remote net via an level 2 router there. Assuming that this remote net is under different administration, it may very well be the case that both of the DTEs are `hard-wired' to play DTE - what now?). Also, I assume that we don't want to restrict communication between LAN X.25 stations to matching DTE-DCE-pairs. How do you propose to solve the problem of two LAN stations within your local LAN both playing DTE (or DCE, in this case it doesn't matter) trying to communicate? I guess the solution as suggested by ISO 8208 is a possible solution to this problem. >ISO recommends this as preferable, in fine print after the specification for >the auto-selecting Restart procedure. I think it just mentions that under certain circumstances it might be the case that this procedure needn't to be supported. At least I couldn't extract any preferences from the text ... >(Actually, the ISO "X.25" documents contain a number of extensions like this >that just aren't a very good idea. Setting T1 on REJ frames, for example.) As I said it is a far better idea than to `hard-wire' it (I don't like the expression `hard-wired', it associates soldering and such stuff 8=) Dirk Husemann X.400: <S=husemann;OU=informatik;P=uni-erlangen;A=dbp;C=de> RFC822: Dirk.Husemann@immd4.informatik.uni-erlangen.de
jon@ifi.uio.no (Jon lnes) (02/04/91)
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
ws@tools.uucp (Wolfgang Solfrank) (02/05/91)
I'm not convinced by your interpretation of the Annexes. First of all it would result in different interpretations of the state of the interface by the DTE and the DCE. Consider the following: DTE sends RESTART REQUEST DTE sends e.g. a REGISTRATION REQUEST DCE sends RESTART INDICATION Now the DTE views the interface in the r1 state, while for the DCE it is in the r3 state. This will eventually be corrected thru a timeout, but I do not consider this situation optimal. What further confuses me, is the fact that the DCE is (according to Annex C) supposed to RESTART the interface on these error conditions only in state r2, but not in state r1. -- ws@tools.uucp (Wolfgang Solfrank, TooLs GmbH) +49-228-230088