Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!GUNTER-ADAM.ARPA!AFDDN.TCP-IP From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Fact or fiction Message-ID: <8703241855.AA09116@ucbvax.Berkeley.EDU> Date: Tue, 24-Mar-87 13:32:39 EST Article-I.D.: ucbvax.8703241855.AA09116 Posted: Tue Mar 24 13:32:39 1987 Date-Received: Thu, 26-Mar-87 01:59:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 54 Approved: tcp-ip@sri-nic.arpa 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. -------