Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!texbell!vector!telecom-gateway From: lars@salt.acc.com (Lars J Poulsen) Newsgroups: comp.dcom.telecom Subject: Re: TCP/IP over ISDN Basic Rate Message-ID: Date: 13 Nov 89 19:34:51 GMT Sender: news@vector.Dallas.TX.US Reply-To: lars@salt.acc.com (Lars J Poulsen) Organization: Advanced Computer Communications, Santa Barbara, California Lines: 30 Approved: telecom-request@vector.dallas.tx.us X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@vector.dallas.tx.us X-TELECOM-Digest: volume 9, issue 508, message 2 of 7 In article kaufman@Neon.Stanford. edu (Marc T. Kaufman) writes: >The maintenance of frame sync on ISDN circuits would certainly allow >you to send DATA at the frame rate (8 KB/sec), but then you would lose >the "out-of- band" information of the HDLC frame, such as FLAG and >IDLE. I always felt that BOPs were a MUCH cleaner way of maintaining >packet synchronization than kludges like Transparent Bisync (DLE-SOH, >DLE-SYN, DLE-ETX, DLE-DLE, etc). Just before HDLC became ubiquitous, DEC designed the last byte-oriented protocol: DDCMP. This is full-duplex, sliding-window and all that good stuff. It also allows transparent binary 8-bit data. DDCMP frames start with a byte count and end with a CRC. You'd still need some idle pattern, DDCMP has a sync character defined. > Besides, this is only going to work >on pure digital ISDN-ISDN circuits. What happens when one end of the >connection is a remote X.25 dial-up? The same thing that always happened when the two ends are dissimilar. They won't talk to each other. What happens when one end is async data and the other end is synchronous ? They won't talk to each other. This should not preclude us from designing a better protocol. / Lars Poulsen (800) 222-7308 or (805) 963-9431 ext 358 ACC Customer Service Affiliation stated for identification only My employer probably would not agree if he knew what I said !!