Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!hayes!tnixon
From: tnixon@hayes.uucp
Newsgroups: comp.dcom.modems
Subject: Re: Reliable and Compression Protocols -- how do they sync up?
Message-ID: <3913.280b3f55@hayes.uucp>
Date: 16 Apr 91 18:15:49 GMT
References: <1991Apr14.062847.16418@colnet.uucp>
Distribution: na
Organization: Hayes Microcomputer Products, Norcross, GA
Lines: 80

In article <1991Apr14.062847.16418@colnet.uucp>, res@colnet.uucp
(Rob Stampfli) writes: 

> I understand the basics of how MNP and V.42 work, but I have never seen
> anyone describe exactly how two modems negotiate a reliable protocol and,
> possibly, compression.  How do they do this?  Does one end send a special
> set of characters to the other end and look for a response?  Do they use
> special tones or timing sequences?  If I am calling an intelligent modem
> from a "dumb" one, what should I expect to see while the intelligent casts
> about trying to figure out the capabilities of the modem on the other end?

[How can I do this _briefly_?  :-)  ]

A V.42 originating modem will initially send a series of XON (DC1; 
11h) characters, with alternating parity bits (11h, 91h), separated 
by 8 to 16 mark bits (this was felt to be very difficult for a 
human typist to accidentally generate, thereby reducing the 
possibility of a non-error-control originating modem being mistaken 
for an error-control modem).  It listens for the answering modem to 
send a series of repeated "EC" character patterns.  If it receives 
this pattern, it assumes that the answering modem has V.42 LAPM 
capability, and goes on to establish the LAPM protocol.

To establish the LAPM protocol, the originating modem first sends an 
Exchange Identification (XID) command frame.  This frame contains
the options that the modem desires to negotiate, in
Type/Length/Value format.  The answering modem analyzes this frame, 
selects from the options offered, and specifies the options to be 
used during the connection in an XID Response frame (I'm 
intentionally leaving out the "what ifs", such as "what if the XID 
command frame is corrupted by line noise?").  The originating modem 
then sends a SABME (Set Asynchronous Balanced Mode Extended) frame, 
the answerer responds with a UA (Unnumbered Acknowledge) frame, and 
the protocol is established and ready for data transfer.

If the EC pattern is not received, a V.42 originating modem will 
attempt the Alternative protocol (MNP compatible), by sending an MNP 
"Link Request" frame one or more times using the start/stop 
character-oriented framing mode (MNP2).  If the answering modem 
replies with an LR frame, the originating modem responds with a Link 
Acknowledge frame, and the MNP protocol is established.  The LR 
frames contain the MNP protocol options, in T/L/V encoding; there is 
not a separate parameter negotiation phase (which is why MNP can't 
renegotiate parameters during a connection, but LAPM can).

Data compression is one of the options negotiated in the XID or LR 
exchange.  The originating modem specifies all the different types 
of data compression that it supports on the given protocol.  The 
answering modem selects from among those, or none, and responds.  

The modems don't use any special tones to identify error control 
capability.  Timing _is_ used, in the sense that if the modem 
doesn't see the character pattern or protocol frame expected from 
the other side within a specified timeout period, it gives up and 
assumes the other modem doesn't support error control (although it 
may retry the frame several times before giving up).

If you call an error control modem from a dumb modem, you won't see 
ANYTHING (unless the error control modem you're calling is a Hayes 
modem, in which case you might see a pattern of space and backspace 
characters, which Hayes V-series modems use to detect the presence 
of pre-V.42 proprietary Hayes error control schemes).  That's 
because the CALLING (originating) modem sends first in both LAPM and 
MNP.  If, on the other hand, the DUMB modem was answering and being 
called by a V.42 modem, it would first see XONs with alternating 
parity for about 750 milliseconds, followed by one or two spurts of 
"garbage" data (the MNP protocol attempt), followed by nothing when 
the error-control modem falls back to non-error-control mode.

	-- Toby

P.S.  I represent Hayes in CCITT Study Group XVII, and helped write 
big chunks of V.42.  The "Detection Phase" part of the V.42 standard 
originated in a contribution to the CCITT from Hayes.

-- 
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