>The OSI term is "relay." I like that.
>
>A relay that forwards (relays) protocol data units (PDUs) based on
>network-layer information is a router. (Let's outlaw terminology that would
>say "a device that switches packets based on network-layer information is a
>router." It's just too confusing.)
>
>A relay that forwards (relays) PDUs based on data-link-layer information is
>a bridge.
Even that can be a flawed definition -- consider ATM and frame switches.
>Modern-day, high-speed, multiple-port bridges are called switches.
>
>Wouldn't it be nice if we could get everyone to use this simple
>terminology!? &;-)
>
>Priscilla
I've always liked the formal OSI terminology. When I used the term
"relay" in my first couple of books, however, the reviewers
consistently hated it.
It's ironic that ISO developed some very precise descriptions for
what they term "routeing", which is _not_ part of the OSI Reference
Model but a separate document. The irony comes in because far too
many sources treat the reference model (indeed, the reference model
without its four subsequent annexes) as the totality of OSI.
Relays are defined in the "OSI Routeing Framework" document.
Complementing this quite nicely is the "Internal Organization of the
Network Layer" document, which gives a precise context for many
things that usually get hand-waving, such as the layering of ARP
mechanisms and of virtual circuit service. The ISO functional
profile system described in ISO Technical Report 10000 gives a
compact and precise notation for relays.
>
>
>At 10:25 PM 1/23/01, Peter Van Oene wrote:
>>In keeping with Howard's previous comment, let's try and sponsor some
>>clarity in the technical world and ban the word switch. In this context,
>>we are talking about control vs forwarding. Packets can be routed in the
>>sense of being sent to their respective IP next hop in hardware vs in a
>>traditional software process. In this sense, we are forwarding traffic
>>based on IP layer information at optimal speed. We are making forwarding
>>decisions based on forwarding table state that has been created by a
>>control function at the IP layer. We are not in any way bridging anything
>>which the term "switch" tends to convey.
>>
>>
>>
>>*********** REPLY SEPARATOR ***********
>>
>>On 1/23/2001 at 7:06 PM Bolton, Travis wrote:
>>
>> >Plus routing of packets is done more quickly when done at the Switch level
>> >rather than having to go through the router for every packet.
>> >
>> >-----Original Message-----
>> >From: Flem [mailto:[EMAIL PROTECTED]]
>> >Sent: Tuesday, January 23, 2001 6:21 PM
>> >To: [EMAIL PROTECTED]
>> >Cc: [EMAIL PROTECTED]
>> >Subject: Re: But isn't that the routers job???
>> >
>> >
>> >Or just do 'sh process cpu' on a router and see all
>> >processes that needs cpu intervention .
>> >
>> >
>> >flem
>> >
>> >
>> >--- Priscilla Oppenheimer <[EMAIL PROTECTED]> wrote:
>> >> The other major thing the CPU has to do besides
>> >> switch (route) packets to
>> >> their output interface is learn the network
>> >> topology. It learns the network
>> >> topology and the best path to remote networks by
>> >> participating in routing
>> >> protocols.
>> >>
>> >> Some other things that the CPU does (depending on
>> >> the configuration) is
>> >> access lists, fancy queuing, SAP, ZIP, NAT, handle
>> >> input at the console,
>> >> SNMP, CDP, HSRP, IGMP, PIM, STUN, proxy stuff, and a
>> >> zillion other TLAs and
>> >> FLAs. &:-)
>> >>
>> >> Priscilla
>> >>
>> >> At 11:05 PM 1/22/01, you wrote:
>> >> >Hey Group,
>> >> > Me again. I'm reading for my CIT and am at
>> >> the section where it goes
>> >> >into detail of the various switching methods in the
>> >> router (i.e., silicon,
>> >> >CEF, autonomous, etc.) I understand how all this
>> >> works and understand how the
>> >> >SP takes a lot of the stress away from the RP and
>> >> this is good because your
>> >> >avoiding bogging the RP/CPU down. I have a problem
>> >> with these statements
>> >> >though and want some clarification...
> > >> >
>> >> >Taken form the book (Lammle's CIT p. 173):
>> >> >
>> >> > "This is just another reason why switching is
>> >> such a good practice. Why
>> >> >burden the RP with every packet if it's not
>> >> necessary? By using switching
>> >> >methods, the RP is free to use valuable CPU time on
>> >> more important things
>> >> >than doing route lookups for every packet that
>> >> comes in the router."
>> >> >
>> >> >Correct me if I'm wrong but isn't that what a
>> >> routers supposed to do??? What
>> >> >else does the RP have to do that is more important
>> >> than ROUTING? I may be
>> >> >overanalyzing this but it just seems that he's
>> >> saying that the RP has better
>> >> >things to do like make coffee, rather than route.
>> >> >
>> >> >Basically, could somebody give me a list of some
>> >> other things the RP/CPU has
>> >> >to do other than route lookups...(I know there are
>> >> access-lists and other CPU
>> >> >things here, I just would like a solid list to
>> >> remember). Thanks team,
>> >> >
>> >> >Mark Zabludovsky ~ CCNA, CCDA, 3/4-NP
>> >> ><A HREF="mailto:
>> >> [EMAIL PROTECTED]">[EMAIL PROTECTED]</A>
>> >> >
>> >> > "Even if I knew I had only 1 more week to
>> >> live, I would still schedule
>> >> >my CCIE lab. I would just have to work a little
>> >> harder I guess. After all,
>> >> >without any goals in life, I'm dead already."
>> >> >
>> >> ~Mark Zabludovsky~
>> >> >
>> >> >_________________________________
>> >> >FAQ, list archives, and subscription info:
>> >> >http://www.groupstudy.com/list/cisco.html
>> >> >Report misconduct and Nondisclosure violations to
>> >> [EMAIL PROTECTED]
>> >>
>> >>
>> >> ________________________
>> >>
>> >> Priscilla Oppenheimer
>> >> http://www.priscilla.com
>> >>
>> >> _________________________________
>> >> FAQ, list archives, and subscription info:
>> >> http://www.groupstudy.com/list/cisco.html
>> >> Report misconduct and Nondisclosure violations to
>> >[EMAIL PROTECTED]
>> >
>> >
>> >__________________________________________________
>> >Do You Yahoo!?
>> >Yahoo! Auctions - Buy the things you want at great prices.
>> >http://auctions.yahoo.com/
>> >
>> >_________________________________
>> >FAQ, list archives, and subscription info:
>> >http://www.groupstudy.com/list/cisco.html
>> >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>> >
>> >_________________________________
>> >FAQ, list archives, and subscription info:
>> http://www.groupstudy.com/list/cisco.html
>> >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>>
>>
>>---
>>Peter A. van Oene
>>Juniper Networks Inc.
>>
>>_________________________________
>>FAQ, list archives, and subscription info:
>>http://www.groupstudy.com/list/cisco.html
>>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
>
>________________________
>
>Priscilla Oppenheimer
>http://www.priscilla.com
>
>_________________________________
>FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
