Hi everybody,
let me share my understanding with u.
At DLL, CRC is done and this way only ethernet header
correctness is checked.
AT IP level, checksum is there to detect bad dgram.
Here checksum on the header only. Since some header
fields change (e.g., time to live), this is
recomputed and verified at each point that the
internet header is processed.
Here there is no error control on further data.
And at TCP level, checksum is calculated for the whole
data following the TCP header including header.
But now, problem may occur when something like,
control singnals stop functioning in the network
interface and the interface stores zeroes at the
places of real data.
These "all zero" messages appear to have valid
checksums. Although messages containing undetected
errors will occasionally be passed to higher levels
of protocol, it is likely that they will not make
sense at that level. In the case of TCP most such
messages will be ignored, but some could cause a
connection to be aborted.
This way its always better to have a checksum
computing routine at each layer.
-
Aneuya.
--- "Philip J. Nesser II" <[EMAIL PROTECTED]> wrote: >
Jacob,
>
> There are many reasons for their to be multiple
> checksums. Try to think of
> a large network with many types of network media,
> MTU sizes, and
> intermediate nodes. The whole world is not
> ethernet.
>
> Here is a trivial example (happened to a client of
> mine so I know that it is
> not just a hypothetical example):
>
> 1. Packet goes from host A to Router 1 via
> ethernet.
> 2. Packet is read by ethernet driver on Router 1
> and the ethernet CRC is
> good and the packet is accepted.
> 3. Router 1 has a bug which corrupts the packet in
> memory.
> 4. Router 1 sends the packet to Host B via another
> ethernet connection.
> 5. Host B gets the packet and the ethernet CRC is
> good and the packet is
> accepted.
> 6. The IP payload has been corrupted by the bug in
> Router 1, and Host B has
> no idea that the data is wrong.
>
> ---> Phil
>
>
> -----Original Message-----
> From: jacob mathews
> [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, September 01, 2001 12:16 AM
> To: Gaurang Pandya; Chandra Shekar Reddy
> Challagonda; jacob mathews;
> [EMAIL PROTECTED]
> Subject: Re: TCP/IP check sum
>
>
> Hi,
> I understand that packet segmentation occurs at
> transport layer and the fragmentation to MTUs occur
> at
> the network layer.To reduce software overheads the
> transport layer segments the packets to sizes of
> MTUs.In such a scenario each packet has a TCP and IP
> checksum computed and placed in the packet.In the
> data
> link layer in case of ethernet MAC, CRC is computed
> and appended.Now many vendors give TCP/IP checksum
> offload feature in ethernet MAC device.When CRC
> check
> is already done on the frame (which is a more robust
> error detection scheme than TCP/IP checksum!!)why
> again TCP checksum has to be computed at all.The
> status of the packet(good or bad)is already
> known!!Then isn't the check sum offload hardware
> feature redundant and adds to silicon cost!!
>
> Expecting lot of responses!!
> --jacob
>
> --- Gaurang Pandya <[EMAIL PROTECTED]> wrote: > Hi
> chandra,
> >
> > All this packet segmenting and merging at
> Transport
> > layer it self. These things never take place at
> > data link layer.
> > Dont you think so..??
> >
> > Gaurang.
> > --- Chandra Shekar Reddy Challagonda
> > <[EMAIL PROTECTED]> wrote:
> > > Hi Jacob
> > > CRC check is done at the Ethernet MAC layer(or
> > Data
> > > Link Layer
> > > conceptually). This error detection process is
> to
> > > detect the errors at
> > > the MAC layer packets, which is the errors
> caused
> > by
> > > the physical layer
> > > or MAC layer.
> > > In some products single big TCP/IP packet(Jumbo
> > > Packet) can broken into
> > > the small packets at the MAC layer depending on
> > the
> > > maximum size of the
> > > packet that link supports(Some thing like MRU).
> > So
> > > the error in the
> > > datapackets which are broken and sent by the MAC
> > > layer, is detected by
> > > the CRC in the MAC layer. When sender sends the
> > > broken data packets
> > > each separately, at the reciever side also,
> these
> > > all packets are
> > > joined into single packet again before passing
> it
> > to
> > > TCP/IP layer. To
> > > check the errors in joined TCP/IP packet, frame
> > > check is used at that
> > > layer. This is to detect the errors occuring in
> > the
> > > TCP/IP packets due
> > > to breaking up and joining up.
> > > So both has relevant significance at each layer.
> > >
> > > Chandra
> > >
> > > ----- Original Message -----
> > > From: jacob mathews <[EMAIL PROTECTED]>
> > > Date: Tuesday, August 28, 2001 1:35 pm
> > > Subject: TCP/IP check sum
> > >
> > > > Hi,
> > > > On a etherent frame CRC is used for error
> > > detection.
> > > > For TCP/IP frames frame check is done by using
> > > 16bit
> > > > 1's complemet addtion.
> > > > Why is TCP/IP frame check required when the
> same
> > > is
> > > > verified by the ethernet MAC?
> > > > What is then the motivation of providing
> TCP/IP
> > > > checksum overload by some products?
> > > >
> > > > Waiting for responses.
> > > > thanking you,
> > > > jacob
> > > >
> > > >
> > >
> >
>
____________________________________________________________
> > > > Do You Yahoo!?
> > > > Send a newsletter, share photos & files,
> conduct
> > > polls, organize
> > > > chat events. Visit http://in/ groups.yahoo.com
> > > >
> > > >
> > >
> > > > The Information contained and transmitted by
> > this
> > > E-MAIL is proprietary to Wipro Limited and is
> > > intended for use
> > > only by the individual or entity to which it is
> > > addressed, and may contain information that is
> > > privileged,
> > > confidential or exempt from disclosure under
> > > applicable law. If this is a forwarded message,
> > the
> > > content of this
> > > E-MAIL may not have been sent with the authority
> > of
> > > the Company. If you are not the intended
> > recipient,
> > > an agent
> > > of the intended recipient or a person
> responsible
> > > for delivering the information to the named
> > > recipient, you are
> > > notified that any use, distribution,
> transmission,
> > > printing, copying or dissemination of this
> > > information in any way
> > > or in any manner is strictly prohibited. If you
> > have
> > > received this communication in error, please
> > delete
> > > this mail &
> > > notify us immediately at [EMAIL PROTECTED]
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email alerts & NEW webcam video instant
> > messaging with Yahoo! Messenger
> > http://im.yahoo.com
>
>
____________________________________________________________
> Do You Yahoo!?
> Send a newsletter, share photos & files, conduct
> polls, organize chat
> events. Visit http://in/ groups.yahoo.com
>
>
____________________________________________________________
Do You Yahoo!?
Send a newsletter, share photos & files, conduct polls, organize chat events. Visit
http://in/ groups.yahoo.com
