-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Howard C. Berkowitz
Sent: Thursday, June 14, 2001 6:28 AM
To: [EMAIL PROTECTED]
Subject: Re: ARP and TCP/IP layering [7:8335]
I'm simultaneously amused and confused by some of the debates on the
list, especially with respect to protocol architecture. True, in many
cases, it is important to know what Cisco is looking for in tests,
which is not necessarily the same as what the protocol designers had
in mind. But a lot of the discussions have the flavor of the sort
of sports debates: "Would Muhammad Ali have beaten Joe Louis?"
OSI, in its _basic_ 7 layer form, is a useful tool for
conceptualizing and educating. That's it. Certain concepts, like the
generic relationship between layers, protocol encapsulation, etc.,
are generally useful. But I assure you, from personal experience in
ISO, IETF, CCITT/ITU-T, and ANSI, nobody spends more than a few
seconds thinking about what layer something goes into.
Indeed, some of the layers are there for political reasons,
especially the session layer. The major reason the session layer was
separated out is to give an existing CCITT committee from the
teletext work something to do. The functions of session quite
reasonably could be given to transport and application, which is
usually the case in IP stacks. Ironically, one of the few stacks I
know of that truly has seven layers, NFS, comes out of the IP, not
OSI, world.
CL: Dare I ask the difference between Layer 3 switching and Routing? ;->
>ARP was developed without reference to the OSI reference model. That's the
>easiest way to think about it. ;-) Cisco books that coerce protocols into
>the strict 7 layers are simplifying the truth. In many cases a protocol
>doesn't fit into a linear stack. ARP lies in a control plane. Its
>functionality is similar to call setup tasks in a WAN network.
>
>To understand ARP it helps to use the ISO document called "The Internal
>Organization of the Network Layer," which relaxes the rigid boundaries
>between Layer 2 and Layer 3. ARP resides in the Subnetwork Dependent
>Convergence Facility. Lots of words but if you think about them, they make
>sense.
>
>Howard has answered this question a ZILLION times. Check the archives. I'm
>sure he says it much better than I do. ;-)
>
>Priscilla
>
>At 11:50 AM 6/13/01, John Neiberger wrote:
>>This topic has come up a few times in the past and I don't think we ever
>>came to a common agreement. Several people made good arguments on both
>>sides. I don't recall the specific argument, but I believe someone even
>>made a convincing argument that it was an application layer function.
>>Perhaps someone here remembers that thread and could refresh our
> >memories.
John, and I think you know I'm not picking on you, people certainly
can argue about things. At the same time, I want to make the
distinction between secondary and primary sources. A secondary
source, in the Cisco context, is something primarily derived from a
course, or other Cisco materials. These materials aren't necessarily
what the Cisco developers would have said.
A primary source is an RFC, or an ISO document, etc., or someone who
was directly involved in the standards or product development. Even
there, there will be conflicts. It is quite common to see people
here referring to the interpretation of IP in RFC 760, 791, etc.,
when these have been superceded by RFC 1812.
> >
>>When most people think of host-to-host communications they think of one
>>layer on one device speaking to the corresponding layer of another
>>device. In this case of ARP I personally feel that we have the network
>>layer of one device speaking to the datalink layer of another. Even
>>that point is a little shaky because at the destination the packet must
>>reach the network layer to be recognized, but the information desired
>>from the end station is layer two, not layer three.
>>
>>I would also suggest that we determine the layer at which a function
>>resides by looking at the layer that originated the request for
>>information.
That is generally valid, and, in fact, is a fair description of the
formal OSI concept of service layering as distinct from protocol
layering. The distinction between services and protocols is rarely
taught, mostly because the instructional people think it's too
abstract.
>In this case, it's the desire of the network layer in one
>>device to speak to the network layer of another device that initiates
>>this entire process. An ARP is generated at the request of the network
>>layer. This ARP seeks out the destination device, gathers the necessary
>>information, and delivers that information to the network layer of the
>>originating device.
>>
>>Because of those two arguments I'd say that the ARP function overlaps
>>both the network and datalink layer. It is a datalink frame generated
>>at the request of the network layer, and it just doesn't fit perfectly
> >into either layer.
No, it's that the datalink and network layers don't fit the necessary
function of ARP. More precisely, the datalink and network layers,
when not split into control and forwarding, are an expecially bad fit.
> >
>>Then again, I may be wrong. :-)
>>
>>Regards,
>>John
>>
>> >>> "Dr Rita Puzmanova" 6/13/01 7:58:53 AM >>>
>>Hi all,
>>
>>Trivial yet fundamental question. I have seen ARP described as part of
>>the network (internet) layer so many times that I have started to
>>believe it belongs there (although I know well that it operates "as
>>if"
>>the Layer 2 protocol - as per OSI RM). Now I have eventually come
>>across
>>Doug Comer's statement: "It's part of the network interface layer."
>>
>>I should not ask where the truth is but still I will. That would mean
>>quite a lot of books are incorrect in this (including Cisco
>>materials).
>>
>>Rita
>________________________
>
>Priscilla Oppenheimer
>http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=8749&t=8335
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
