Dear Howard,
Thank you very much for the response. Everything is starting to come
together now. I still have one problem though---
>8000 bps, or every 193rd bit, is used for framing and control. 1536
>Kbps + 8 Kbps = 1544 Kbps = 1.544 Mbps.
I see how it works so there would be 1544 Kbps, but 1544Kbps = 1.5078125Mbps
(1544Kpbs * (1 Mbps/1024Kpbs)). When the phone company tells us that we're
getting 1.544 Mbps, do they really mean that we're getting 1544 Kbps??
Sincerely,
Fred Danson
>From: "Howard C. Berkowitz" <[EMAIL PROTECTED]>
>Reply-To: "Howard C. Berkowitz" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: A few quick Remote Access questions
>Date: Tue, 13 Feb 2001 15:09:12 -0500
>
> >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]
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]