Re: Fw: [RPRWG] CRC check in each node?
Hi Kumar:
I agree with you. I think most of us are in agreement on need for a header CRC
to protect everything that relates to payload delivery, and for preserving
payload CRC end-to-end.
Unlike SONET where bit errors wouldn't cause voice/video data to go to wrong
places - over a packet transport such as RPR a CRC error in the header is a
cause for packet drop since we don't know the delivery end points.
TDM data over SONET/SDH slots can proceed with CRC error to the end point, since
network paths are pre-configured. Incorrect payload CRC makes no major
difference in this case, as these data types are tolerant of bit errors.
- If voice/video is transported over IP (all inside the payload area), a correct
header CRC but a bad payload CRC is also a cause for packet drop since we don't
know if the network addresses (that deliver the payload to final end point off
the RPR ring) within the payload area are correct.
- Packet-oriented transports, such as those for RPR, would have to drop packets
at the intermediate node - not because payload is intolerant of CRC errors, but
because of errors in packet delivery parameters - whether in RPR header or
possibly header fields within the payload area (if VoIP is used, for instance).
- If the payload contains only voice/video data (and no network information) and
the payload relies on RPR to deliver the content from end to end, then we may
provide an option for sending to the end node a packet with a correct RPR header
CRC but bad payload CRC.
Best regards,
Pankaj
Kumar Kovvali wrote:
> Hi Pankaj,
> Comparing to SONET, the forwarding decision whether to drop or pass
> through is
> explicit/out of band based on slot number in SONET; thus a bit error can't
> cause a byte to
> go to a wrong place. If addressing is with-in the packet stream then bit
> errors in any of
> header portion would cause problems you listed. So the alternative is to a
> header checksum; so if the
> rpr has an additional mac-header that has ring-sa/da/len/crc (CRC-10?),)(and
> the packet crc is relevant
> at add/drop points only) then forwding decision at each node is protected.
> Considering non-data traffic such as voice/video etc., it can tolerate
> higher bit errors - thus
> forwarding packet towards destination without validating packet-crc is
> better for those
> applications.
> -Kumar
>
>
> -----Original Message-----
> From: Pankaj K Jha [mailto:pkj@xxxxxxxxxxx]
> Sent: Friday, June 29, 2001 7:47 PM
> To: Angela T. Faber
> Cc: ieee 802.17 list
> Subject: Re: Fw: [RPRWG] CRC check in each node?
>
> Hi Robin:
> Propagation of errored packets all the way to the destination may have its
> roots
> in SONET/SDH networks (I admit I don't know the reasons for token ring
> properties). In SONET networks one establishes a dedicated path (through a
> series of nodes) between a source and a destination node. The bandwidth pipe
> is
> dedicated between the end station, and other nodes don't (aren't allowed to)
> mess with the packets within the pipe.
>
> Since SONET/SDH primarily carried PDH traffic that didn't have an addressing
> within the packet for a particular intermediate node (a bunch of DS0
> channels),
> and the fact that circuit was untouched by intermediate nodes, the data was
> delivered to the end nodes.
>
> With POS, the situation didn't change, because you still have a
> point-to-point
> dedicated link (through one or more nodes in between). Intermediate nodes
> still
> must carry data all the way to the destination. Since it is a PPP, the end
> node
> is the one that takes it off the ring.
>
> The significance of doing so is almost negligible in packet-oriented
> transports.
> Unlike SONET/SDH carrying PDH, with IP transport it is very easy to address
> any
> node and run SNMP and monitor RMON MIBs, Ethernet MIB, other L2/L3 MIBs,
> etc. at
> any node. So if Node C has been dropping packets, you can see it easily
> using
> standard SNMP tools from any other place in the network.
>
> No additional SLA advantages are gained in this case by delivering packets
> to
> the end node. In any case, if CRC check fails, how do we even know who the
> end
> node is? The MAC address may be corrupted, and we cannot rely on the MAC
> value.
> Source stripping also may not happen because source MAC address may have got
> corrupted. If there was a chain of Ethernet switches sending packets from
> Node A
> to Node F, Node B doesn't forward the packet to the destination node,
> because it
> doesn't even know for sure who the destination node is. The packet may go
> anywhere in the network, depending on what got corrupted in the L3 header (I
> guess on ring networks you can make a case that even if things get
> corrupted,
> even a bad TTL value will eventually expire, so it doesn't hurt, but then I
> don't think we're getting any benefits in doing so).
>
> Also, inverting CRC, or setting a bit, or any other method doesn't help the
> destination node determine which of the intermediate nodes found the CRC
> error,
> because the intermediate node hasn't inserted its node ID in the packet.
>
> Please advise if you see any flaw in the logic here.
>
> Regards,
> Pankaj
>
> "Angela T. Faber" wrote:
>
> > Folks
> >
> > Please see the discussion below I was having with Robin. It was my fault
> > that the group was not copied (I forgot!!)
> >
> > 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
> > > ---------------------------------------
> > >
> > >