>I've been reading through the Sybex BCRAN book and have a few "quick"
>questions:
I like your questions. There's always a need to observe if the
emperor is really wearing any clothes. You point out a number of
inconsistencies, which, in many cases, have historical causes.
>
> First, I understand the theoretical difference between Autoconfigure
>and Autodiscovery, but in the book, it appears that the different commands
>do the same thing. For Autoconfigure, the book says "The modem autoconfigure
>command is used to instruct the router to use this feature. This feature
>will detect the type of modem connected to the router and then supply the
>initialization string to the modem-- a process that can require up to five
>seconds."
> It sounds as if the modem autoconfigure command also performs
>autodiscovery functions. Did they really mean to say that the command is
>modem autoconfigure modem_type ?
Yakov Rekhter, one of the patron saints of routing and the IETF
(formerly at IBM, formerly Cisco Fellow, and now at Juniper), once
wrote, "at a sufficiently high level, everything is the same."
You are correct that both autodiscovery (for LANs) and autoconfigure
(for modems) both do things necessary to get the physical and data
link layers to work. The interface types and protocols are very
different, and were in all probability developed by different people
who didn't talk to one another. As far as I can tell, CLI developers
have no equivalent of Martha Stewart as arbiter of good taste and
grammar. Internally, Nortel does in principle have some committees
that oversee the consistency of command languages in new products,
but I'd hardly call it high priority. Other vendors' mileage will
vary.
>
> The second question that I have involves RTS and CTS.
Part of the problem is that RTS and CTS were originally developed as
part of the EIA RS-232 standard. Originally, when RS-232 was
started, it was purely intended for use between a data terminal
equipment (DTE) and a data circuit terminating equipment (DCE). In
the minds of the developers, DTE=computer and DCE=modem.
Modems of the time (1970 or so) often worked over half-duplex lines.
Long before hub-and-spoke topologies such as frame relay, there were
analog hub-and-spoke topologies in which the hub was a Master
Computer that sent out a poll -- an invitation to transmit -- that
could be heard by all slaves. When a slave recognized an invitation
addressed to it, and it had something to say, it would assert RTS to
bid for the transmit rights to the line. Think of listening for your
poll as similar to waiting for a shared Ethernet to become quiet, or
to receive the token. Depending on the analog technologies in use, it
could take up to several seconds before your modem was ready to
transmit and sent CTS.
>The stated
>function of RTS from the book is "Request to send is one of the two hardware
>flow control wires. It signals that the DTE can receive data from the DCE.
>This depends on having sufficient buffers available." The states function of
>CTS from the book is "Clear to send is the second hardware flow control
>wire, and it signals that the DCE is ready to receive from the DTE." I
>previously thought that there were two steps to hardware flow control using
>RTS and CTS.
The use of RTS and CTS to control traffic between a computer and a
local device such as a printer came later. RTS and CTS weren't
designed, per se, for this application, and you may equally well see
DTR and DSR used for this sort of flow control.
>I used to think that the sending side would first send a RTS
>message to the receiving side, and in turn the receiving side would send a
>CTS message so that the sending side would know that the receiving side was
>ready for data. The thing that gets me with their explanation is that they
>say that CTS is used by the DCE saying that it is ready to receive, and RTS
>is used by the DTE saying that it is ready to receive. My impression from
>this explanation is that it is a one step process, but I still dont see how
>this would work. How does it really work??
>
>My third question is: What exactly is the difference between ISDN PRI and a
>leased line T1??
Electrically: no difference
Bit framing: no difference, although ISDN is probably more likely to use ESF
Channelization: T1 is not necessarily channelized.
When channelized, it is most commonly channelized
into 64 Kbps DS0's or multiples of 64 Kbps.
For voice applications, call control can be channel associated
(bit-robbing) or common channel. The latter is similar to ISDN.
PRI is channelized into DS0's, of which one, the D channel,
is designated as a control channel.
>
>And Finally, my last question is: How the heck do they get the number 1.544
>Mbs for the speed of a T1? When I multiply 24 (# of B channels) by 64Kbs I
>get 1536kbs. 1536Kbs converted to Mbs (1536/1024)is 1.500 Mbs! Where are the
>other 0.44 Mbs at??
8000 bps, or every 193rd bit, is used for framing and control. 1536
Kbps + 8 Kbps = 1544 Kbps = 1.544 Mbps.
>
>If anyone can answer atleast one of the questions, please do. I know that
>I'm digging real deep here, but thats how I learn best. Thanks.
>
>Fred Danson
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
