Packet and circuit switching - Page 2

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View
Re: Packet and circuit switching

Quoted text here. Click to load it

Technically, you 'could' have BGP running within a network without an IGP.
Neighbors just need to be 'found,' and directly connected neighbors are
easily found.
Remote neighbors can be reached with a series of static routes.
In the majority of cases, this is a silly arrangement, but entirely
possible.

Perhaps the instructor made some clarifying statement* to that effect ?


* See the reference to silly arrangement.     ;-)





Re: Packet and circuit switching
On Sun, 20 Aug 2006 22:40:02 -0500, John Agosta wrote:

Quoted text here. Click to load it


Yes, that's is possible, and in a triangle you do not even need static
routes unless you are using loopback addresses as peering addresses...
Anyway, I was surprised by the fact this instructor said you do not need
an IGP..


Re: Packet and circuit switching
Hmm, ok, not the best example of CCNA curriculum material - someone was
trying very hard to show how to verbosely complicate a reasonably
straightforward difference.

(1) Circuit Switched:
The "circuit", the "communications channel", the "connection" is established
before any data is transferred.
So when you make a "traditional" telephone call you dial the number, the
system connects you to the destination phone, if it's not busy it rings, but
you don't start to talk until the other person answers.  Then for the
duration of that phone call your speech follows the same electronic pathway
until one party hangs up.

(2) Packet Switched:
"Connectionless, best effort" - the system starts to transfer data from the
source in packets as soon as it is ready to go, whether or not the
destination is ready.  Furthermore each packet could take a different route
to the destination.  Other layer protocols manage the reliability/control
issues.

This is fine for "data" of course, but demonstrates the issues that have to
be resolved when you want to implement Voice/Telephony over IP.

Aubrey



Re: Packet and circuit switching

Quoted text here. Click to load it

Thank you! At least someone understands where I come from!

Quoted text here. Click to load it

I really like this simple explaination!

Quoted text here. Click to load it

Is this an anology with sending an e-mail?

The Dude



Re: Packet and circuit switching
Quoted text here. Click to load it

KISS is nearly always best  :-)

Quoted text here. Click to load it

Yes, particularly if there are a number of routers between your locally
hosted email client and your email server.
But it also applies to downloading a webpage or up/downloading a file with
FTP/TFTP.

But remember connectionless best-effort packet switching occurs at the Layer
3 Network (or Internet) Layer.  Transport and Application Layer protocols
ensure a session or virtual circuit has been established first if one is
required, such as for email or FTP.  But TFTP, which uses UDP doesn't
bother.

Aubrey



Re: Packet and circuit switching
Thankyou-great explanation and simple enough for me to understand ;)

Aubrey Adams wrote:
Quoted text here. Click to load it


Re: Packet and circuit switching

Quoted text here. Click to load it

So, you are saying that " Circuit switched " is similar to TCP and " packet
switched" is similar to UDP, correct?

The Dude



Re: Packet and circuit switching
Quoted text here. Click to load it

Well, maybe, sort off :-)

Review the operation of the TCP/IP suite of protocols.

Start from the top, let's say a web server has received a request for HTTP
data to be sent to a host somewhere.
So the Application layer presents the HTTP data to the Transport layer.
TCP, says ok, let's see if the host which requested the HTTP data is ready
to receive it.
The 3 way establishment process occurs, with protocol datagrams containing
Sequence Numbers and Acknowledgements being exchanged - ok, good to go.
The HTTP data is chopped up into segments with TCP fields added, including
source & destination ports, so that the data will end up in the destination
host web browser and not its email client.  The Internet layer encapsulates
these segments into packets with the destination (and source) IP address and
off they go with routers directing the packets towards the destination
network.

Now not all of these packets may make it to the requesting host.  The TCP
acknowledging process notifies the source of those packet(segments) that did
arrive, so lost segments (packets) are re-sent and maybe the window size is
also adjusted.
Halfway through delivering the webpage one of the intermediate links goes
down.  So using the destination network address the routers will re-route
the packets along other routes.  If significantly more packets are lost and
time delays occur TCP will say, whoa, time to re-establish the "link".  And
then it tries to start the process again.

So I guess you can say TCP tries to set up a "circuit switched"
communication process while IP is using connectionless packet switched
communications.

Remember, though, the above is a grossly simplified scenario and
explanation.

Aubrey




Re: Packet and circuit switching

Quoted text here. Click to load it

I am sorry, but any attempt to relate TCP, which is a host-resident software
process to explain how L1 circuit switching works
is going a couple steps over the edge for me.  TCP and UDP and
Absolutely_Nothing to do with the issue of circuit or packet switching.
Trying to make that connection is like trying to say there is a similarity
between a Porsche 911 and a jar of apple sauce. Two totally unrelated
issues. Sorry to be harsh, but attempting to make a connection between these
processes is
probably going to add to the level of confusion instead of clarify things.






Re: Packet and circuit switching

Quoted text here. Click to load it

Finally, you were being honest. Please, next time, do not try to explain
things that you do not understand to the others.

 TCP and UDP and
Quoted text here. Click to load it

The only level of confusion so far has been added by your posts only. Yes,
you should be sorry for being harsh too.
Mr. Adams seems to understand the subject very well, and the way he explains
things has been excellent!
Thank you Mr. Adams!

The Dude



Re: Packet and circuit switching

Quoted text here. Click to load it

Hey Dude, thanks for the kind words, but I think you're close to being a bit
a harsh too.
John knows his stuff, I just explain things differently to him.

Aubrey



Re: Packet and circuit switching

Quoted text here. Click to load it


What in heaven's name are you talking about?


Quoted text here. Click to load it

You either have me confused with someone else, or just confused.

Quoted text here. Click to load it



Re: Packet and circuit switching
Quoted text here. Click to load it

Hey John I think you missed this --->> "Well, maybe, sort off :-)" <<--- in
my post.

After more years than I care to think about I would go for "some
understanding mixed with a bit of confusion" over "totally confused
ignorance" anytime.  As long as the recipient of the information is aware
that the explanation is simplified and incomplete and based on a model or
analogy I would say they have a good starting point to develop their
understanding more completely.

TCP is "connection-oriented" and "reliable", UDP is "connectionless" and
"unreliable", IP is "connectionless" and "best effort".
Between IP and one of the other protocols you get a workable data link.  If
it aids initial understanding to make an analogous link between a TCP
"connection"/"session"/"conversation" and Layer 1 "circuit switching" then I
don't see the problem.  As long as "what they *don't* know" is stressed and
recognised as much, or preferably more, as "what they *do* know" then in my
view they can only go forward.

Aubrey



Re: Packet and circuit switching

Aubrey Adams wrote:
Quoted text here. Click to load it

That's extremely dangerous. And wrong to push your philosophy (which is
of that nature) onto others. Some people , including myself, would
rather not learn wrong information, and would prefer no explanation to
a wrong one.


Quoted text here. Click to load it

Even if you make him aware, it's still bad to do that.

It shouldn't be wrong or contain bits of confusion to make a "story" of
how it works tell better.
But actually I think your explanation wasn't so distorted.

I've actually heard far more dangerous story tellers.  Stories that I
won't repeat because I'd like to keep them forgotton.

Ok, i'll tell one of them. , one of the stories was that a company
making their own NICs will throw away the first and last NIC becuase
they're all 0s and all 1s , and those are broadcasts!!!!!!

Of course, the reason why that one is wrong is becasue the company
wouldn't make the full range. The first 3 bytes of the MAC are issued,
and wouldn't be all 0s, and they'd start with those first 3 bytes.  I
don'tk now if they'd throw away the last one or just avoid making it. I
suppose it depends how sophisticated their equipment is. And the All 0
MAC isn't and wasn't ever a broadcast. It may have been issued to
somebody- or not - more likely not because it could be confused with
all 0s MAC displayed on a computer screen because of a problem reading
MAC address.


I used to hear many such stories. After that and another similar one ,
I didn't take a word seriously anymore.

They're ok when you know it already and want to correct misinformation.

I'm not comparing your explanation to that story, but you see why I
have disdain for stories. And even minor sentences can create huge
confusion.

I had a book that says that the OSI is a reference model, that's all it
is, it's conceptual .   Which is not true at all.  It's a network
architecture and a reference model.  And that was supposed to be a good
book.  So please, no misinformation. Misinformation takes 10* longer to
unlearn than it does to learn.

Though of course it's better when you warn people of misinformation
first, so they don't hang on every word.    The worst misinformers  are
those that you think probably know what they're talking about and are
serious, and cause you to hang onto every word.

And i've had some pretty bad ones that answer "Yes" when the answer is
"No"(but they didn't understand the question). Perhaps if they'd said
"Sort Of". I wouldn't have taken it so seriously and learnt the wrong
thing.  But still it's not good to do that.


Re: Packet and circuit switching
Quoted text here. Click to load it

It's only "dangerous" when the instructor delivers the simplified "story" as
the "whole complete truth" and /or the learner believes it to be so.
Hence my stress on the learner always needing to know what they don't know.
And it's not my philosophy, it's the implementation of age old teaching and
learning strategies.

Quoted text here. Click to load it

How do people move from knowing nothing to knowing a lot then?
If it is bad to learn this way why is there the CCNA, then the CCNP and
finally the CCIE?
If anyone being trained in networking has to know almost everything then
there would only be the CCIE.
Ask anyone who, after completing CCNA routing, goes onto the CCNP how they
felt about CCNP1/BSCI.
I know I was initially furious - why wasn't static routing completely and
properly explained before?
Why wasn't ip unumbered covered?  Why weren't *all* the routing protocols
compared? Why wasn't OSPF covered completely?
The answers are now clear of course.  I was only able to ask these questions
because I now knew the basics and was ready to deal with these issues in the
BSCI course.
That's why in college/university there are 101 courses, followed by 201,
then 220, then 301, then 310, etc.

Quoted text here. Click to load it

Thanks, I don't think it was that distorted either.  Consider a class full
of 17-19 year olds, usually all male, and who consider themselves computing
and networking experts purely because they reformat and reload Windows onto
their overclocked PC once a week and know all the hacks for some
first-person shoot'em up game which they can play with 6 other people
connected via a hub.  These guys aren't going to immerse themselves in a 2
hour theory lecture giving an in-depth explanation on TCP/IP followed by a 2
hour lab analysing its configuration and operation.  The only way (for the
majority) is simple and initially incomplete but true "stories", getting
down into the hands on stuff asap, then expanding on the skills developed
with more detailed explanations later on.

Quoted text here. Click to load it

But these are just networking myths and untruths.  People who spread them
are showing how much they don't know, not how much they do know.

Aubrey



Re: Packet and circuit switching
Just to one thing picked from below:

Could you give an example of an implemented OSI model infrastructure?

Regards,
Frank

On Sun, 13 Aug 2006 06:45:17 -0700, q_q_anonymous@yahoo.co.uk wrote:

Quoted text here. Click to load it




Re: Packet and circuit switching
GM / Boeing     Implemented an OSI system back in the late 80s. It was
called MAP/TOP.
There were a few companies selling OSI protocol suites back then, too.
A company called "Tocuh OSI" from Scott's Valley, California sold such
software.
I have installed it. The US Government had also implemented some OSI systems
as defined within its "USGOSIP"(United States Government Open Systems
Interconnect Profile) parameters.

Most, if not all of the efforts to migrate towards OSI ended after Internet
use became 'commercially' available.

-ja



Quoted text here. Click to load it



Re: Packet and circuit switching
Funny, that the same (?) US government, called the Department of Defense
developed the DARPA net, which is the Internet based on...

One of the reasons the the OSI model never made it, is because of the long
specifications of the interlayer communications within the software.

Nice, but not practical...

Anyway, the discussion was on mis-information, right?

So, that brings us to the fundamental question: What is truth?
And that question is is not supposed to be answered in this news-group, I
guess.


On Mon, 14 Aug 2006 10:23:07 -0500, John Agosta wrote:

Quoted text here. Click to load it


Site Timeline