RE: Clause 46: Start of frame reception
Hi Ben,
It doesn't seem like the rules for reception are strict enough to keep a bad
frame from being interpreted as good. Let's say the implementation requires
both rules (/S/ in lane 0, /SFD/ in lane 3) and take this case for example:
Lane 0 1 2 3
/S/ P P P
/SFD/ D D D <--Frame 1 is not
received, bad /SFD/
D D D D
...
D T I I
I I I I
I /S/ P /SFD/ <--Frame 2 received, good /S/ from
D D D D *previous* frame plus good
/SFD/
D D D D this frame
...
D D T I
Is it correct to receive "Frame 2" as a good frame, even though its /S/
character did not occur in Lane 0 ?
thanks,
Danielle
*******************************************
Danielle Lemay
Design Engineer, Nishan Systems
dlemay@xxxxxxxxxxxxxxxxx
408-519-3985
> -----Original Message-----
> From: Ben Brown [mailto:bbrown@xxxxxxxx]
> Sent: Friday, May 11, 2001 11:00 AM
> To: Danielle Lemay
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: Re: Clause 46: Start of frame reception
>
>
>
>
> Danielle,
>
> Danielle Lemay wrote:
> >
> > Ben,
> >
> > If a MAC receives this frame and only /S/ is required for reception,
> > where is the frame supposed to start ?
> >
> > Lane 0 1 2 3
> > /S/ P P P
> > P P /SFD/ D
> > D D D D
> > D D D /SFD/
> > D D D D
> > ...
>
> It depends upon your implementation. If your implementation
> is designed to really know nothing about lanes, then your RS
> only checks that /S/ comes in lane 0 then sends everything else
> to the MAC. The MAC will parse the data as it arrives, find the
> first SFD and start the packet on the first D.
>
> If your implementation cares about lane alignment, then
> your RS is allowed to ignore the data on lanes 1 & 2 and
> discards all bytes up to the second SFD.
>
> The case you've described above is arguably a no win case.
> The preamble should never have been shortened by a single
> byte so it should never occur in the first place. An SFD
> that falls where your first SFD does is likely a bit error
> somewhere converting the 0x55 to a 0xD5. Also, if the
> second byte in lane 3 is not an SFD, it is probably also
> due to a bit error. The second SFD in your example is
> probably part of the SA but now you're thinking it is
> the SFD so you'll likely get a CRC error on the packet.
>
> The bottom line is that this scenario is, in all likelihood,
> a bad packet that will not be correctly received. However,
> the first 2 paragraphs above describe how you're supposed
> to handle it.
>
> Regards,
> Ben
>
> >
> > thanks,
> > Danielle
> >
> > > -----Original Message-----
> > > From: Ben Brown [mailto:bbrown@xxxxxxxx]
> > > Sent: Friday, May 11, 2001 6:58 AM
> > > To: Danielle Lemay
> > > Cc: stds-802-3-hssg@xxxxxxxx
> > > Subject: Re: Clause 46: Start of frame reception
> > >
> > >
> > >
> > >
> > > Danielle,
> > >
> > > I think you have it backwards:
> > >
> > > Danielle Lemay wrote:
> > > >
> > > > Hi,
> > > >
> > > > What are the rules for receiving the start of a frame?
> > > >
> > > > On transmission, the following rules apply:
> > > >
> > > > a) /S/ must appear in lane 0
> > > > b) /SFD/ must appear in lane 3
> > > > c) Only Preamble may appear between /S/ and /SFD/
> > > > d) Preamble may be of any length
> > >
> > > All but rule c are applicable to the RECEIVE side of the RS
> > > (Clause 46). The RS doesn't check the content of the preamble
> > > other than to verify that there is an /S/ in lane 0. It is
> > > allowed to discard packets that don't have the SFD on lane 3
> > > but even this is not necessary. The MAC is defined as 1 bit
> > > wide so it knows and cares nothing about lanes.
> > >
> > > On transmission, a MAC will transmit exactly 7 bytes of preamble
> > > and 1 byte of SFD. The RS converts the first byte of preamble
> > > to /S/ and aligns the /S/ to lane 0 by modifying the IPG
> > > according to the rules of the Deficit Idle Counter (DIC). The
> > > RS never modifies the length nor the content of the preamble
> > > other than the first byte. For that matter, there is nothing
> > > currently in the standard that allows for the preamble length
> > > or content to be modified by any sublayer. However, the receive
> > > RS must be able to receive a preamble of a modified length with
> > > modified content should it receive one. (Go figure :)
> > >
> > > >
> > > > Clause 46 suggests that only (a) is necessary to
> receive a frame.
> > > > Is that the intention ?
> > >
> > > Yes, rule a is the only necessary rule. Rule b is allowed but
> > > not necessary.
> > >
> > > Regards,
> > > Ben
> > >
> > > >
> > > > thanks,
> > > > Danielle
> > > >
> > > > *******************************************
> > > > Danielle Lemay
> > > > Design Engineer, Nishan Systems
> > > > dlemay@xxxxxxxxxxxxxxxxx
> > > > 408-519-3985
> > >
> > >
> > > --
> > > -----------------------------------------
> > > Benjamin Brown
> > > AMCC
> > > 2 Commerce Park West
> > > Suite 104
> > > Bedford NH 03110
> > > 603-641-9837 - Work
> > > 603-491-0296 - Cell
> > > 603-626-7455 - Fax
> > > 603-798-4115 - Home Office
> > > bbrown@xxxxxxxx
> > > -----------------------------------------
> > >
>
>
> --
> -----------------------------------------
> Benjamin Brown
> AMCC
> 2 Commerce Park West
> Suite 104
> Bedford NH 03110
> 603-641-9837 - Work
> 603-491-0296 - Cell
> 603-626-7455 - Fax
> 603-798-4115 - Home Office
> bbrown@xxxxxxxx
> -----------------------------------------
>