RE: Fw: [RPRWG] CRC check in each node?
Angela,
Yes my point was that for ATM networks, SONET error performance
counters provides the underlying span management. The ATM HEC
was not used to provide span management, but to prevent cell
misrouting. We need similar mechanisms for RPR. RPR networks
utilizing SONET PHY can utilize SONET physical layer overhead
for span management, and an RPR header checksum (HEC) to prevent
RPR frame misrouting. For RPR networks utilizing 1GbE, 10GbE PHY, the RPR
header checksum (HEC) prevents RPR frame misrouting, and an RPR frame check
on the data is used to
perform span management.
As previously mentioned on this thread there needs to be a way
of identifying an error in the data and only counting once on a
particular span. Some have suggested having a payload error
indication bit in the RPR header. The problem with using a
bit in the header, is this bit can not be transmitted until the last byte of
the frame is received and the CRC is calculated. This precludes any sort of
cut-through implementation. This error indication needs to be in the RPR
frame trailer or encoded in the CRC trailer.
thanks,
bob
Robert Castellano
Jedai Broadband Networks
rc@xxxxxxxxx <mailto:rc@xxxxxxxxx>
(732) 758-9900 x236
-----Original Message-----
From: afaber@xxxxxxxxxxxxx [mailto:afaber@xxxxxxxxxxxxx]
Sent: Tuesday, July 03, 2001 11:20 AM
To: rc@xxxxxxxxx
Cc: Reuven Zeitak; ieee 802.17 list
Subject: RE: Fw: [RPRWG] CRC check in each node?
Bob
Maybe I misunderstood your email below (and since I don't know GbE, please
let me know if I am wrong), but when SONET/SDH is used with ATM, ATM can
rely on the PHY for span management. However, RPR will also use GbE, and
now I'm not sure if we can rely on GbE to provide this functionality... I
know GbE does not have all the resilience/OAMP functionality as provided by
SONET/SDH/OTN, but do you think than RPR would need to check CRC-payload,
and also provide all those counts (errored packets, discarded packets, etc.
) at each node so that we can identify that the link may have a problem?
Regards
Angela
"Robert
Castellano" To: "Reuven Zeitak"
<reuven.zeitak@xxxxxxxxxxxxxxxxxx>, "ieee 802.17
<rc@xxxxxxxxx list" <stds-802-17@xxxxxxxx>
> cc: (bcc: Angela T.
Faber/Telcordia)
Subject: RE: Fw: [RPRWG] CRC
check in each node?
07/03/01
10:12 AM
Please
respond to rc
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