Re: Fw: [RPRWG] CRC check in each node?
Based on my knowledge of IEEE 802.5, I would expect that there will be some
type of management (LLC) traffic that is executed at the RPR MAC level, as
opposed to the PHY layer. This traffic will be a miniscule fraction of the
total bandwidth, but will guarantee all nodes get occasional traffic and are
able to report their status.
I am not proposing this idea as the right solution, just as one possible
solution that has been used in past protocols.
Best regards,
Robert D. Love
Chair, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@xxxxxxxx Fax: 208 978-1187
----- Original Message -----
From: <afaber@xxxxxxxxxxxxx>
To: "Reuven Zeitak" <reuven.zeitak@xxxxxxxxxxxxxxxxxx>
Cc: "ieee 802.17 list" <stds-802-17@xxxxxxxx>
Sent: Tuesday, July 03, 2001 9:38 AM
Subject: RE: Fw: [RPRWG] CRC check in each node?
>
>
> Hello Reuven
>
> This is an interesting issue.
>
> We could leave the span management (i.e., to identification of possible
> faults/degradations in the segment) for the PHY layer, and RPR could only
> perform the Header CRC check so that we don't misroute packets. However,
if
> we don't count payload errored packets we don't know what is the % of the
> traffic that is error-free. I think the service provider will want to
> monitor SLA, and will want to know how many packets it is delivering and
> what is the % of the errored packets being delivered. Although we don't
> need to check for payload CRC at every node, it could be performed only
> once, at the edge of the RPR network, before delivering it to the client.
>
> Now I have another question to the group: if we leave span management for
> the PHY layer to do (what I think is the best thing to do), how do we
check
> the communication between PHY and RPR inside the box? If I have constant
> traffic being passed to RPR, than it is fine because I see that the
packets
> are being delivered. However, how do I know if I am not receiving any
> traffic from my PHY because I may have a problem between the PHY and RPR
> (the PHY is not going to say anything to RPR) or simply because I don't
> have any traffic? ATM has a OAM flow being sent in parallel to solve
> this...
> Any thoughts on that?
>
> Angela
>
>
>
>
>
> Reuven Zeitak
> <reuven.zeitak@nativenet To: "ieee 802.17
list" <stds-802-17@xxxxxxxx>
> works.com> cc: (bcc: Angela
T. Faber/Telcordia)
> Subject: RE: Fw:
[RPRWG] CRC check in each node?
> 07/03/01 01:46 AM
>
>
>
>
>
>
>
>
> 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
>
>
>
>