Re: [RPRWG] CRC check in each node?
Robin
My first thoughts was that we could drop packets with corrupted payload
because of BW-saving, and also to avoid that those packet, in transit, could
delay another ones that may have latency requirements, and may be delayed by
such packets. But after all this discussion, I guess the need that SP may
have (for SLAs) to deliver corrupted payload packets are more strong than
that....
Angela
----- Original Message -----
From: "Robin Olsson" <robino@xxxxxxxxxxx>
To: "Angela T. Faber" <afaber@xxxxxxxxxxxxx>
Sent: Friday, June 29, 2001 5:08 PM
Subject: Re: [RPRWG] CRC check in each node?
> Hi Angela and all
>
> Yes you are right, CT/SF really comes down to jitter since the delay
depends on packet size.
>
> No, if you do CT you can not make your forwarding decision based on the
payload CRC. But you can of course make the decission based on any header
validation check (CRC or something else) which I beleive you should do.
>
> But let me get back to my question (again) - why do you want to discard an
packet with error in the payload in intermediate nodes? Anyone have an
answer?
>
> Robin
>
> "Angela T. Faber" wrote:
>
> > Hi Robin
> >
> > Thanks a lot for the explanation!
> >
> > One question: in one of your previous emails, you said that "...
Everyone
> > need to store some parts of the packet (at least the header) to process
the
> > packet. The question really comes to whether the delay depends on the
packet
> > size or not and whether it does so regardless of contention or not. Even
cut
> > through may store a complete packet due to contention..."
> > Does it mean that CT also can process CRC before making a decision
whether
> > to discard or forward the frame? I know this CT vs. SF is very debatable
> > issue, but I'm just trying to understand if CRC checking is feasible
also in
> > CT...
> >
> > Thanks again!
> >
> > Angela
> >
> > ----- Original Message -----
> > From: "Robin Olsson" <robino@xxxxxxxxxxx>
> > To: "Angela T. Faber" <afaber@xxxxxxxxxxxxx>
> > Cc: "ieee 802.17 list" <stds-802-17@xxxxxxxx>
> > Sent: Friday, June 29, 2001 3:36 PM
> > Subject: Re: [RPRWG] CRC check in each node?
> >
> > > Hi Angela.
> > >
> > > Consider the links A -> B -> C -> D -> E
> > >
> > > A sources a packet with correct CRC. If you detect an error in node B,
you
> > will count the error in node B (for fault location purposes), and insert
the
> > correct CRC inverted. Node C will then either see that 1) the CRC is
> > inverted, that means there is no errors on the incoming link to C or 2)
the
> > CRC is not inverted neither correct, that means that the error occured
on
> > Node Cs inbound link (C insertes the correct CRC inverted and node D and
E
> > may also be able to detect errors on the inbound link). Regardless, the
> > end-point E is still able to see that the packet is errored, hence keep
> > statistics per flow/customer if required.
> > >
> > > Using a bit instead of the CRC inverted is more complicated to
implement
> > (since where will you put it) and does not yield the same level of
coverage,
> > since the packet can only be a part of erreror detection on one link
(i.e.,
> > the first link with an error).
> > >
> > > If the error occur in the header the packet is discarded and the error
> > information is lost and can not be realted to any specific flow.
However, si
> > nce the header will be a percentage of the average packet size, the
number
> > of errored packets can be approximated with being proportinal to the
number
> > of detected error packets. If more precise bit-error rates are required,
> > some other mechanism is probably required since the packet size is
variable.
> > >
> > > Robin
> > >
> > > "Angela T. Faber" wrote:
> > >
> > > > Robin
> > > >
> > > > Maybe I am missing something from your email below. If we change the
> > value
> > > > of the CRC (or add a bit to indicate it) to say that the error was
> > already
> > > > accounted for in the node that first detected it, how about other
errors
> > > > that may occur in this packet downstream from the node that changed
the
> > CRC?
> > > > Only packets with "correct" CRC would then be able to detect those
> > errors?
> > > >
> > > > Angela
> > > >
> > > > ----- Original Message -----
> > > > From: "Robin Olsson" <robino@xxxxxxxxxxx>
> > > > To: "igorz" <igorz@xxxxxxxxxx>
> > > > Cc: "ieee 802.17 list" <stds-802-17@xxxxxxxx>
> > > > Sent: Wednesday, June 27, 2001 3:13 PM
> > > > Subject: Re: [RPRWG] CRC check in each node?
> > > >
> > > > >
> > > > > Hi Igor and all
> > > > >
> > > > > Yes, if there is no additional indication wether the error is
already
> > > > detected or not. Either by a seperate bit or by replacing the CRC
with
> > the
> > > > correct value inverted. Note, that only errored CRCs will have their
CRC
> > > > value altered! A sane packet will keep it's original CRC calculation
> > from
> > > > the source. In my oppinion this will satisfy the requirement from a
lot
> > of
> > > > people about not having end-to-end CRC coverage if the CRC is
> > re-calculated
> > > > in intermediate nodes.
> > > > >
> > > > > Robin
> > > > >
> > > > > igorz wrote:
> > > > >
> > > > > > Robin,
> > > > > >
> > > > > > wouldn't the intentionally bad CRC mask off all of the
subsequent
> > > > errors?
> > > > > >
> > > > > > Igor
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > > > > > [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Robin
> > Olsson
> > > > > > Sent: Tuesday, June 26, 2001 12:37 PM
> > > > > > To: Mike Takefman
> > > > > > Cc: ieee 802.17 list
> > > > > > Subject: Re: [RPRWG] CRC check in each node?
> > > > > >
> > > > > > Hi Mike and all
> > > > > >
> > > > > > If we try and look away from how LAN and Ethernet is done today
and
> > just
> > > > > > concentrate on what to be solved. The far easiest way to provide
> > error
> > > > > > statistics for a given flow is to not remove the packets. This
will
> > work
> > > > > > even with different system vendors on the same ring. And I can
not
> > > > imagine
> > > > > > that any carrier will not want the possibility to have error
> > statistics
> > > > per
> > > > > > customer/SLA. This IS different from etehernet and LANs - there
is
> > no
> > > > > > concept of carrier capabilities and isn't that one of the
reasons
> > for
> > > > > > wanting RPR in the metro?
> > > > > >
> > > > > > I do not understand why anyone wants to remove the packets - for
> > > > bandwidth
> > > > > > optimization? I do not beleive that it is important to optimize
> > > > bandwidth
> > > > > > for the case of errored packets. I would rather optimize in
order to
> > > > avoid
> > > > > > errored packets. Fault location? Can be solved differently (see
> > below).
> > > > > >
> > > > > > Header error check:
> > > > > > Needed for validation the control information used within RPR
> > itself.
> > > > > > Packets with errored headers are discarded, since we do not know
> > what to
> > > > do
> > > > > > with them or what customer/SLA it belongs to.
> > > > > >
> > > > > > Payload error check:
> > > > > > Only monitoring. Can be used for determing where errors are
injected
> > > > (fault
> > > > > > location). Also needed to keep track of performance statistics
on
> > the
> > > > > > interfaces. Can be accompanied with an error indication telling
that
> > > > this
> > > > > > packet is already discovered to be in error further upstream.
This
> > would
> > > > > > increase the fault location efficiency. Draw back is that it
must be
> > > > placed
> > > > > > in 1) the header, meaning a need for store and forward or 2) in
the
> > end
> > > > of
> > > > > > the packets, do we share it with the CRC? or 3) a special faulty
CRC
> > > > value
> > > > > > (e.g., the correct CRC inverted) to be inserted instead of the
> > received
> > > > > > value.
> > > > > >
> > > > > > I do not want to post an oppinion on store-and-forward as a
concept,
> > I
> > > > just
> > > > > > do not think that the argument for using it should be error
location
> > or
> > > > > > packet discarding since error location that can be solved
> > differently
> > > > and
> > > > > > discarding errored packets is not (in my view) a desired
behaviour.
> > > > > >
> > > > > > Robin
> > > > > >
> > > > > > Mike Takefman wrote:
> > > > > >
> > > > > > > All,
> > > > > > >
> > > > > > > An interesting point from 802.1D 1998 is the following.
> > > > > > >
> > > > > > > "Note that the frame is completely received
> > > > > > > before it is relayed as the Frame Check Sequence (FCS)
> > > > > > > is to be calculated and the frame discarded if in
> > > > > > > error."
> > > > > > >
> > > > > > > It strikes me that if an 802.1D bridge must not relay a packet
> > > > > > > with a bad FCS, there is nothing wrong with removing it in
> > > > > > > the transit path of the 802.17 MAC (assuming that it can be
> > > > > > > done). We are not changing the operation that will
> > > > > > > occur, just making it happen sooner.
> > > > > > >
> > > > > > > I did not see an example of guaranteeing deliverly of
> > > > > > > a packet with "good" address and "bad" contents in current 802
> > > > > > > networks. The FCS will alias bad address and bad contents and
> > > > > > > since .1D specifies that packets with FCS errors will be
removed
> > > > > > > I do not understand how anything with an FCS error continues
to
> > > > > > > flow to an end station unless the LAN is a single segment.
> > > > > > >
> > > > > > > I would appreciate a pointer to the relevant part of the
standard
> > > > > > > that describes how to do this type of operation across
multiple
> > > > > > > segments.
> > > > > > >
> > > > > > > thanks,
> > > > > > >
> > > > > > > mike
> > > > >
> > > > > --
> > > > > ---------------------------------------
> > > > > Robin Olsson
> > > > > Vitesse Semiconductors, Denmark
> > > > > Phone: +45 4596 9659
> > > > > fax: +45 4596 9699
> > > > > ---------------------------------------
> > > > >
> > > > >
> > >
> > > --
> > > ---------------------------------------
> > > Robin Olsson
> > > Vitesse Semiconductors, Denmark
> > > Phone: +45 4596 9659
> > > fax: +45 4596 9699
> > > ---------------------------------------
> > >
> > >
>
> --
> ---------------------------------------
> Robin Olsson
> Vitesse Semiconductors, Denmark
> Phone: +45 4596 9659
> fax: +45 4596 9699
> ---------------------------------------
>
>