AFDDN.TCP-IP@GUNTER-ADAM.ARPA.UUCP (03/24/87)
Comments (especially corrections) welcome, DDN X.25 has always been a source of confusion to a lot of people. I want to get the record straight for once. There are two types of X.25 service in DDN; Basic and Standard. I don't want to get into the details of X.25, except where the DDN does interesting things. Basic X.25---This is the easy one. Hosts can use the DDN as if it was PDN. The D-bit, Q-bit, and M-bit are passed transparently through the network. The PSN End-to-end modules set up the the internal End-to-end connection to establish the X.25 virtual circuit. Each X.25 packet is viewed as a "meesage" by the End-to-End module. Multiple virtual circuits are allowed between a given host pair. What I would like to know is: Does the End-to-End module set up multiple End-to-End connections? If not, how does End-to-End sort which "messages" go with which virtual circuit. Standard X.25---This is the interesting one, available in PSN 6.0 initially. I assume here that if you use the Standard Service facilities field then the node "assumes" you to be placing an interoperable call and "all" the packets get passed to the IOP module. The IOP mudule is a logical 1822 host created in software. The user data is extracted from X.25 packets and used to form 1822 messages which are then passed to the End-to-End module for transmission through the network. The Q-bit and D-bit are not passed through the network. All X.25 acks are only locally significant. Each packet, or complete packet sequence is assumed to be an IP datagram. Therefore the M-bit is used locally to send a datagram larger than 1 packet as a complete packet sequence. The user data portions of the complete packet sequence are agregated into a single "message" which is then passed to the End-to-End module. A datagram, sent as a single packet or a complete sequence, cannot be longer than the 1822 maximum message length. Only one End-to- End connection can be established between any two host pairs at a given precedence level (let's leave precedence out now). Question: What will the node do if you try to set up a second virtual circuit between a host pair already having one End-to-End connection established? Will the node simply clear the call? A related IOP question: The 1822 spec call for the hardware to pad messages out to specific length boundaries (16 or 32 bits, I don't remember at the moment). If an 1822 host sends a message to another 1822 host, the hardware on the receiving end strips the padding. What happens if an 1822 host sends a message to a Standard X.25 host. The padding added by the hardware of the sending host is added to the user data in the X.25 packet (or sequence) that gets sent to the receiving host. The IP module of that host will then be passed a buffer of data as a datagram that's longer than the length field in the IP header says it should really be. This shouldn't be a problem, but I know of one host that got confused by this. It took the guy debugging the interface a couple of days to figure out the problem. Is all this really accurate or have I glitched a bit somewhere? A lot of this stuff will change with the advent of PSN 7.0. Anybody know exactly what's gonna change? Darrel B. -------
Mills@UDEL.EDU.UUCP (03/26/87)
Darrel, While I can't speak to all the points in your message, I can confirm that the tailing bits you impute to the 1822-X.25 message occur on ordinary 1822-1822 messages as well. It is well known that the padding bits will always add up to 16 bits to the length of the message. I would suspect, so far unverified, that this can happen on a Standard X.25-X.25 message as well. From an implementor's point of view, this bug seldom bites more than once. Dave
ahill@CC7.BBN.COM.UUCP (03/27/87)
Darrel, I'll take a crack at answering your knowledgable inquiries. Basic X.25 allows multiple VCs between a given host pair. Each VC gets its own connection at level 3. X.25 traffic is encapslated in 1822 and delivered to the subnet. The traffic is subject to 1822 restrictions. All traffic between host pairs is on one dynamic subnet connection. X.25 acts like a software host so 1822 delivers the encapslated data to X.25 which handles the L3 connection control. Your understanding of Standard X.25 is correct. The answer to your question is Yes. IOP strives to do the reasonable thing about hardware padding on messages. BBN believes that there was a problem during the early days of IOP but the software has been corrected. If this is not the case I hope people will speak up and let us know. PSN 7.0 will make significant changes in the way X.25 traffic is handled as well as major modifications to the subnet E-E. X.25 and AHIP (1822) will be handled as peer protocols thus elimnating the need for IOP and significantly improving X.25 performance. RFC978 might help you understand some of the features of PSN 7.0. Regards, Alan