Framing errors with TCP-IP

Hi,

Does framing errors occur frequently with TCP-IP networks?  How does
the network detect a framing error (Using CRC)?   On which layer does
the framing error occur - (The data link layer?)?

Your time, effort and suggestions will be greatly appreciated
Jaco

jaco_versfeld@hotmail.com (Jaco Versfeld) writes:
> Does framing errors occur frequently with TCP-IP networks?

The question makes no sense in that context.  'Framing' is something
that happens in the link layer, below IP.

So, as written, the answer has to be "no," since framing in TCP/IP.

Framing errors do occur on some types of link layers used for TCP/IP
networks.

>  How does
> the network detect a framing error (Using CRC)?

Typically, no, though I suppose it's possible.  A "framing error"
means that you've violated the protocol used to describe the
boundaries between packets (or other data units).  The exact
definition of such an error (and how it would be detected) depends on
the link layer in use, and you haven't mentioned any of interest.

>   On which layer does
> the framing error occur - (The data link layer?)?

Yep.

-- 
James Carlson, Solaris Networking              <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

"Jaco Versfeld" <jaco_versfeld@hotmail.com> wrote in message
news:e48813da.0308060140.3d1e8e8b@posting.google.com...
> Hi,
>
> Does framing errors occur frequently with TCP-IP networks?  How does
> the network detect a framing error (Using CRC)?   On which layer does
> the framing error occur - (The data link layer?)?
>
> Your time, effort and suggestions will be greatly appreciated
> Jaco

Examinations time again?

On Wed, 06 Aug 2003 07:21:16 -0400, James Carlson wrote:

> 
> Typically, no, though I suppose it's possible.  A "framing error"
> means that you've violated the protocol used to describe the
> boundaries between packets (or other data units).  The exact
> definition of such an error (and how it would be detected) depends on
> the link layer in use, and you haven't mentioned any of interest.

For example, a Framing error in Ethernet is a packet which is not a
multiple of 8 bits in length - not a whole number of octets. Ethernet
controllers are not built to be able to send these, and they are detected
by the controller chip before even considering the checksum - the checksum
cannot even be reliably located in such packets.
 
Steve

Thanks for the replies.

Does Ethernet uses an asynchronuous transmission such that it can
determine if the received packet's data is a multiple of 8 bits?


Regards,
Jaco

On Thu, 07 Aug 2003 00:05:54 -0700, Jaco Versfeld wrote:

> Thanks for the replies.
> 
> Does Ethernet uses an asynchronuous transmission such that it can
> determine if the received packet's data is a multiple of 8 bits?
> 
> 
> Regards,
> Jaco

It's not asynchronous. It uses manchester encoding, which is a combined
clock-and-data signal. Something along the lines of a logical zero being
sent as 10 where as logical 1 is sent as 01, IIRC. I can't remember the
name for this.

I can't remember how start and end of frame are delimited, and how it
avoids the carried data making a delimiter in the middle of a frame.
Funnily enough, I remember exactly how HDLC does that, and vaguely
remember how Token Ring does it, but Ethernet... It's been a long time...

Steve

"Steve Horsley" <steve.horsley1@virgin.NO_SPAM.net> writes:
> It's not asynchronous. It uses manchester encoding, which is a combined
> clock-and-data signal. Something along the lines of a logical zero being
> sent as 10 where as logical 1 is sent as 01, IIRC. I can't remember the
> name for this.

"Manchester encoding?"  ;-}

It's basically the same as XOR-ing the clock and data together, and it
means you always have a nice transition to look at to recover your
timing, regardless of the data pattern.  You have this data stream,
for example:

         1   0   1   1   1   0   0
data    ----____------------________
clock   __--__--__--__--__--__--__--

And the output (encoded) stream is the XOR of these:

        --____----__--__--____--__--
        |  ||  ||  ||  ||  ||  ||  |

Notice how there's a transition (high-to-low or low-to-high) in the
middle of every bit time.

> I can't remember how start and end of frame are delimited, and how it
> avoids the carried data making a delimiter in the middle of a frame.
> Funnily enough, I remember exactly how HDLC does that, and vaguely
> remember how Token Ring does it, but Ethernet... It's been a long time...

If I recall correctly, end of frame on Ethernet is just going silent
-- you stop transmitting bits.  Since there are no more transitions
present, that's a coding violation, and the receiver picks up the lack
of clock as "end of frame."

-- 
James Carlson, Solaris Networking              <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

steve.horsley1@virgin.NO_SPAM.net meinte am 07.08.03
zum Thema "Re: Framing errors with TCP-IP":

> On Thu, 07 Aug 2003 00:05:54 -0700, Jaco Versfeld wrote:

>> Thanks for the replies.
>>
>> Does Ethernet uses an asynchronuous transmission such that it can
>> determine if the received packet's data is a multiple of 8 bits?
>>
>>
>> Regards,
>> Jaco

> It's not asynchronous. It uses manchester encoding, which is a

I do _not_ agree here.

You mix up self-clocking and synchronous transmission here.

In a synchronous transmission, sender and receiver always stay
synchronized, it is hence particularly not necessary for a receiver
to determine the beginning and the end of a frame.

(To make the confusion complete, I would like to refer to ATM,
the layer 1 of which is a perfect example of synchronous data transfer ;-))

Ethernet is exactly the same like V.24 or RS-232 or other asynchronous
data transfer standards, where a number of start bits (the preamble
in case of ethernet) allow the reconstruction of the clock signal.
(Please keep in mind, that the very point here is not the reconstruction
of the clock _rate_ but the reconstruction of the clock _phase_ here.)

> combined clock-and-data signal. Something along the lines of a
> logical zero being sent as 10 where as logical 1 is sent as 01,
> IIRC. I can't remember the name for this.

In principle, Ethernet is coded with a self clocking code. However,
I don't know whether the self clocking property is that important
here as the clock rate and clock phase may be reconstructed=20
quite well from the preamble. But it would allow to adjust
any skew here. In my opinion, Manchester Encoding is chosen
amongst others for bandwidth reasons (the signal bandwidth
is different depending on the coding scheme you chose) and=20
perhaps even to keep the line free from direct current. But perhaps
we have an electrical engineer who can complete and correct this.


> I can't remember how start and end of frame are delimited, and how

I think it was defined by Lewis Carrol in "Alice in Wonderland"
(please correct me, if I'm wrong): Begin with the beginning,
and then go on until you come to an end and then stop.

An Ethernet-Frame starts with a preamble, comprising 7 octetts
10101010 (or starting with 0, I don't know yet) at the beginning
and then ending with an octett 10101011. (Or the other way round
respectively, have a look in a good textbook for this.)
(And please, any IEEE Members: I know, that you totally disagree
here and insist an Ethernet Frame will start with a preamble
of 63 alternating bits and a duplication of the last one in=20
the 64th place. But usually NICs and MAUs are quite ignorant
and do not even notice the very difference.)

Depending on whether you belong to the church of IEEE, an ethernet
frame's length can be read from the lengh field, or, if you
belong to the church of DIX, an Ethernet Frame simply ends somewhere.
After the last bit, the current on the line has to drop to zero
within three bit times. When there is any settling due to the
low path properties of a carrier, this is eliminated by the
strict octet framing: An Ethernet frame has to be made up by
an integral number of whole octets. After an Ethernet frame,
an interframe gap has to be obeyed.

HTH=20

DB
--
Mit so einen begrenzten,dass ich gar nicht sage psychisch- retardierten
Individuum,m=F6chte ich mich keinesfalls weiter
rekreieren.
(Hannelore Brigic in d.s.w.c.)

Detlef.Bosau@tesionmail.de (Detlef Bosau) wrote in message news:<8rmLtkvjSJB@Detlef.Bosau>...
> (...)
> Ethernet is exactly the same like V.24 or RS-232 or other asynchronous
> data transfer standards, where a number of start bits (the preamble
> in case of ethernet) allow the reconstruction of the clock signal.
> (Please keep in mind, that the very point here is not the reconstruction
> of the clock  rate  but the reconstruction of the clock  phase  here.)
> 
> > combined clock-and-data signal. Something along the lines of a
> > logical zero being sent as 10 where as logical 1 is sent as 01,
> > IIRC. I can't remember the name for this.
> 
> In principle, Ethernet is coded with a self clocking code. However,
> I don't know whether the self clocking property is that important
> here as the clock rate and clock phase may be reconstructed 
> quite well from the preamble. But it would allow to adjust
> any skew here. In my opinion, Manchester Encoding is chosen
> amongst others for bandwidth reasons (the signal bandwidth
> is different depending on the coding scheme you chose) and 
> perhaps even to keep the line free from direct current. But perhaps
> we have an electrical engineer who can complete and correct this.


I think "self-clocking" is probably synonymous with your term "adjust
for any skew".

All synchronous protocols need periodic "clock deskewing".  If you
attempted to just match clock rates over the course of a single 1500
byte Ethernet packet without any reclocking, you'd need the sender's
and receiver's clocks synchronized within less than 1 part per 24000
(which would be darn tough), or the receiver would drift complete off
data bits by the end of the frame.  The receiver's clock *is*
synchronized during the preamble, but is continuously resync'd as
clock signals go by.  With various tweaks, this is true of all
synchronous line disciplines.

Manchester encoding provides a fairly continuous stream of clock
transitions with a very simple implementation, but requires
considerable extra signal bandwidth (x2).  Manchester encoding
guarantees at least one signal transition for each bit (although there
will be 1.5 on average).  This means that the receiver needs only to
be able to sync his clock to within 20% or so of the senders (although
in practice it's much better than that).

Other schemes, such as group encoding, can reduce the number of extra
transitions, but require greater clock stability.  For example a 5/4
encoding scheme can transmit four data bits in each five "signal"
bits, and guarantee that at least one signal transition occurs in each
group.  The clocks then have to be stable enough to stay in sync
during the worst case interval between signal transitions (eg. a
single transition early in one group followed by a single transition
late in the next group).

Schemes such as SDLC use bit stuffing to insert data into the stream
(which is removed by the receiver) to force signal transitions at
short enough intervals that the receiver can keep his clock
synchronized.  Bit stuffing typically has pretty low overhead, but
does effectively make your link data rate variable, which is a PITA.

As an aside, typical RS-232 asynchronous serial communications require
that each side's clock is accurate to within 2% of the nominal data
rate.  The receiver syncs up his clock at the leading edge of the
start bit, but never resyncs during the frame (hence "asynchronous"). 
Assuming the sender and receiver are both off 2%, but in different
directions, the receiver would be 42% of a bit width off center by the
time he got to the first stop bit on an 8-bit+parity "frame."  IOW,
just about ready to fall off the bit entirely.

Detlef.Bosau@tesionmail.de (Detlef Bosau) wrote in message news:<8rmLtkvjSJB@Detlef.Bosau>...
>(...)
> In my opinion, Manchester Encoding is chosen
> amongst others for bandwidth reasons (the signal bandwidth
> is different depending on the coding scheme you chose) and 
> perhaps even to keep the line free from direct current.


BTW, Manchester encoding does not eliminate DC current flow, although
differential Manchester does.