Mike_Benna@mindlink.UUCP (Mike Benna) (03/11/91)
Based on some of the things Toby has said about LAP-M packet assembling
I'm led to believe that LAP-M packets have a header, a _variable_ length
data area, and then a frame end marker/crc.
What I'd like to know is how the data stream can be formatted so that
the header doesn't need to contain the length of the subsequent data but
that the receiving modem can somehow determine the length of the data
portion of the frame.
The only practical solution I can think of is to escape certain
characters when they occur in the data portion of the frame but if this
is the case then there must be some characters which take more bandwidth
than others. What are these characters (if they exist)?
Mike
--
---> Mike Benna, Vancouver, B.C., Canada
MindSpan Technologies Corp. - Video Game Design and Development
EMAIL: Mike_Benna@mindlink.UUCP or ...!van-bc!rsoft!mindlink!Mike_Bennadcarr@hobbit.gandalf.ca (Dave Carr) (03/12/91)
In <5098@mindlink.UUCP> Mike_Benna@mindlink.UUCP (Mike Benna) writes: >Based on some of the things Toby has said about LAP-M packet assembling >I'm led to believe that LAP-M packets have a header, a _variable_ length >data area, and then a frame end marker/crc. >What I'd like to know is how the data stream can be formatted so that >the header doesn't need to contain the length of the subsequent data but >that the receiving modem can somehow determine the length of the data >portion of the frame. Similar to HDLC. The data links inserts 0's into the data stream so that no more than five 1's are in a row. Then, it defines the pattern 01111110 as a flag, used for start and end of frame delimiting. To start/end a frame, the USART overrides the bit stuffing logic to produce a flag. The receiver knows how many bytes were received BETWEEN the flags. The last 2/4 are the CRC 16/32. Note, the data between the flags does not need to be a multiple of 8 bits. This is useful when compression results in an odd number of bits.
lstowell@pyrnova.pyramid.com (Lon Stowell) (03/13/91)
In article <5098@mindlink.UUCP> Mike_Benna@mindlink.UUCP (Mike Benna) writes: >Based on some of the things Toby has said about LAP-M packet assembling >I'm led to believe that LAP-M packets have a header, a _variable_ length >data area, and then a frame end marker/crc. > >What I'd like to know is how the data stream can be formatted so that >the header doesn't need to contain the length of the subsequent data but >that the receiving modem can somehow determine the length of the data >portion of the frame. > >The only practical solution I can think of is to escape certain >characters when they occur in the data portion of the frame but if this >is the case then there must be some characters which take more bandwidth >than others. What are these characters (if they exist)? The frames are delimited by Flag characters. If these are in the datastream, they are stuffed (by the hardware level) to prohibit the receivers detecting an end of frame...just like HDLC or SDLC. No escaping is needed, as the hardware layer stuffs and destuffs zero's to maintain flag dectection.
tnixon@hayes.uucp (03/13/91)
In article <5098@mindlink.UUCP>, Mike_Benna@mindlink.UUCP (Mike Benna) writes: > What I'd like to know is how the data stream can be formatted so that > the header doesn't need to contain the length of the subsequent data but > that the receiving modem can somehow determine the length of the data > portion of the frame. LAPM, like MNP3, LAPB, LAPD, and many other protocols, is based on the High-level data link control (HDLC) frame format specified in ISO 3309. This uses a particular sequence of bits (01111110), known as a "flag", to delimit frames. Whenever five 1 bits appear in sequence in the frame contents, a 0 bit is inserted for transparency, so a flag sequence never appears in the frame contents. Thus, there's no need for the receiver to know in advance the length of the information part of the frame; all it does it look for the closing flag. It then knows that the preceeding two or four bytes (depending on whether you're using 16- or 32-bit frame check sequences) is the FCS, and everything before that and after the frame header is the data. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
ronald@robobar.co.uk (Ronald S H Khoo) (03/19/91)
tnixon@hayes.uucp writes: > LAPM, like MNP3, LAPB, LAPD, and many other protocols, is based on > the High-level data link control (HDLC) frame format specified in > ISO 3309. This uses a particular sequence of bits (01111110), known > as a "flag", to delimit frames. Toby, the Internet RFC (1171) for their point-to-point protocol describes an async addendum to 3309 as PDAD1/1984. Do you know if this ever passed, and if any of your (or anyone else's :-) modems will convert sync/async this way, including conversion of the sync bit-stuffing <-> the async character stuffing, maybe + data rate conversion as well ? Might be damned useful that, given the expense and non-standardness of synchronous serial cards for PCs ... -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
tnixon@hayes.uucp (03/20/91)
In article <1991Mar18.181406.18104@robobar.co.uk>, ronald@robobar.co.uk (Ronald S H Khoo) writes: > Toby, the Internet RFC (1171) for their point-to-point protocol describes > an async addendum to 3309 as PDAD1/1984. Do you know if this ever > passed, and if any of your (or anyone else's :-) modems will > convert sync/async this way, including conversion of the sync > bit-stuffing <-> the async character stuffing, maybe + data rate conversion > as well ? Might be damned useful that, given the expense and non-standardness > of synchronous serial cards for PCs ... Yes; the start-stop framing mode for HDLC is defined in ISO 3309 Addendum 1, which was published last year. I wrote the original draft, by the way; it was adopted with only minor editorial modifications. Hayes does support start-stop HDLC in our V-series error control modems, both for point-to-point modem error control (to allow error control to be retrofitted to async-only Smartmodem 1200s), and for "async X.25" (which is now being studied in CCITT Study Group VII). Of course, this requires a compatible device or process on both ends of the line -- which may not be what you want. Hayes has another feature in our modems called AutoSync. This allows the modem to be hook to the async port of a PC, and connected to a _synchronous_ host remotely. The modem does conversion from async to sync, by stripping start and stop bits, calculating FCS, adding flags, and inserting zero bits for transparency (and the opposite on reception). The DTE rate MUST be higher than the line rate to keep up with the async-to-sync conversion process; the modem uses buffering and flow control, as you might expect. Unlike start-stop HDLC (which is wholly implemented either in the modem or in the PC), AutoSync "splits" the protocol so that the procedural aspects are implemented in the PC software, but the low-level framing and error detection functions are built into the modem. It's great for laptops, most of which don't have sync cards available at any price. -- Toby -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net