RE: Fw: [RPRWG] CRC check in each node?
Hi,
I guess the argument boils down to:
a)link integrity (regeneration of crc at each hop regardless of whether the
previous crc was errored)
vs
b)data correctness (maintain the original crc end to end and have higher
layers do a strip).
An orthogonal issue, that everybody accepts is that the rpr header nust be
protected independently
and that packets should be discarded when the header is corrupted.
option a) is SONET like, since it is regenerated per hop and is basically
information about a specific leg.
option b) is ATM-AAL5 like since it is end to end and is not manipulated
during transit.
My comments are that
1) it is complicated to implement a scheme that does a+b in one go
(stomp/invert crc etc)
2) HEC is probably enough to give us link integrity, and it is regenerated
at each hop anyway.
3) SONET link is on a much coarser scale than per packet (it is per sonet
frame).
4) If operator requirement for number of correct packets is a relevant
issue, then during encapsulation
RPR probably must add its own CRC and during de-capsulation (I mean when
packets leave the ring) CRC
should be checked. Is this really a requirement? Does ATM report how many
"correct" cells arrive?
We are talking about 1e-10 ber and beyond here.
5) There was an issue about "dark" fiber link integrity. I'd go with a
control(OAM) packet solution (say every X milliseconds)
>>-----Original Message-----
>>From: Robert Castellano [mailto:rc@xxxxxxxxx]
>>Sent: Tuesday, July 03, 2001 16:12
>>To: Reuven Zeitak; ieee 802.17 list
>>Subject: RE: Fw: [RPRWG] CRC check in each node?
>>
>>
>>Reuvan,
>>
>>In ATM networks only an HEC was required on the header, since
>>data and link integrity is provided by the underlying STM, SONET,
>>or PDH, transmission layer. Since ATM cells are asynchronous
>>to the SONET frame, SONET overhead frame checks providing the
>>link integrity
>>did
>>not suffice to guard against misrouting. The ATM HEC is provided to
>>protect against misrouting. In SONET/ATM, the link error performance
>>is provided by the section, line, path overhead, and misrouting is
>>provided by the ATM-HEC. If the SONET frame is corrupted, but doesn't
>>affect the ATM header, then SONET error statistics are
>>updated, but the
>>cell (with corrupted data) is still routed by the ATM
>>network. ATM cell
>>payload integrity is performed by the ATM Adaptation Layer at
>>the ends of
>>the VC.
>>
>>This is analogous to what has been discussed regarding having
>>separate header/data integrity checks for RPR. Since GbE and 10GbE
>>do not have the SONET overhead equivalents, a similar check on the
>>entire data payload allows these transmission technologies to provide
>>similar performance monitoring capabilities in an RPR network. One
>>of the goals of RPR is to achieve SONET-like resilience for
>>packet ring networks.
>>
>>The data CRC provides the link performance monitoring, while the
>>header check prevents misrouting. One could argue that the CRC used
>>to protect the data portion of the frame is strictly an RPR
>>specific frame
>>integrity check that is independent of any user CRCs that
>>also might be part
>>of the payload. In this case the RPR frame check is strictly
>>used by the
>>RPR stations and is stripped when the frame is given to the
>>client. The
>>client
>>would then have to rely on its own client-level frame CRCs in order to
>>validate
>>the payload. This is the paradigm used in ATM.
>>
>>
>> regards,
>>
>> bob
>>
>>Robert Castellano
>>Jedai Broadband Networks
>>rc@xxxxxxxxx <mailto:rc@xxxxxxxxx>
>>(732) 758-9900 x236
>>
>>
>>-----Original Message-----
>>From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
>>[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of
>>Reuven Zeitak
>>Sent: Tuesday, July 03, 2001 1:47 AM
>>To: ieee 802.17 list
>>Subject: RE: Fw: [RPRWG] CRC check in each node?
>>
>>
>>
>>Hi Everybody,
>>
>>I have been following this interesting thread. I want
>>to rock the boat a bit here to make sure all points have
>>been considered:
>>Question: Is a CRC on data really what we want?
>>
>>Consider:
>>
>>ATM only has a HEC and does not protect data,
>>it is left to the application.
>>
>>In some sense RPR is just an encapsulation of user data
>>and has to be agnostic to the data content. As it was pointed
>>out here, Users may want to keep on getting the data even if
>>there are link errors. Maybe the application has a sophisticated error
>>recovery method. Maybe it has none. Is it the RPR layer's job to
>>provide the application an error indication?
>>
>>We clearly need some kind of BER measure (in the SONET jargon)
>>to verify if the link is alive. Isnt the HEC good enough for that?
>>HEC errors are to be discarded at the next node anyway, so that
>>there is no issue of double counting an error.
>>
>>reuven
>>
>>--------------------------------------------------------------
>>--------------
>>-----------------------------
>>Reuven Zeitak PhD
>>
>>Modeling And Algorithms
>>Native Networks
>>2 Granit St., P.O.Box 7165
>>Petah Tikva, Israel
>>Tel: +972-3-920-2800 x 875
>>Fax: +972-3-9210080
>>reuven.zeitak@xxxxxxxxxxxxxxxxxx
>>www.nativenetworks.com
>>
>>The Native Way = Ethernet Simplicity + SONET Reliability
>>
>>