Re: [RPRWG] Rough outline of PAR for the RPR on the backplane
David,
speaking for myself and no one else. I urge all
other RPRWG members and watchers to pipe up if
they have anything to add.
The scope and purpose appear to me to be
acceptably narrow so that this work would not
fall into area's that I would want to do in
dot17. I cannot speak for the 802.3 backplane
people and your references into their work
that was mentioned in the scope.
Politically, I still have reservations about
calling it RPRoBackplane. Taking the ideas
from RPR and building a new backplane protocol
around them but calling it "DVJBus" would be
my preference. I see no need "reference" the
RPR payload after the HEC since it is just
octets followed by a CRC-32. Have you considered
CRC-64 to improve the robustness? :-) Given
that the header is going to be different,
won't you be using 64 bit OUIs? This is
begining to look more and more different from
RPR as to make a reference silly.
Another area that I might look at (since I used
to do fault tolerant computing) would be the
use of redundant memory banks and extensions
in the protocol to make that kind of operation
more efficient.
What if any requirement does MSC have for
broad interest (# of individuals, # of companies)
in order to start a study group and eventually
approve the PAR.
cheers,
mike
David V James wrote:
> Mike,
>
> As per last P802.17 WG meeting, we concluded that
> RPR on the backplane PAR should be provided for comment,
> one week before the MSC meeting.
>
> I'm a bit tired, so this is not as good as it should be.
> Feel free to refine, wordsmith, revise, etc. based on
> suggestions. While the MSC meeting is next Monday night,
> inputs would be most valuable if received before Sunday PM.
>
>
>
> Scope:
> Provide a network-based backplane interconnect, based on
> the ring topology and baseline protocols of P802.17 RPR,
> while retaining the RPR payload (after HEC) format and
> function. While this is not an amendment of P802.17 RPR,
> large portions of that standard will most likely be
> included by reference.
>
> Extensions for the short-latency environment include
> destination-based flow control, hardware-based fault-retry,
> time-of-day synchronization, synchronous data transfers,
> and standardized direct-to-memory {read, write, and
> read-modify-write} operations.
>
> While the standard will include the definition low-power
> short-distance PHYs, these may be included in the standard
> by reference to existing and/or active standards.
>
> Purpose:
> To simplify and supplement the baseline RPR capabilities
> to facilitate their adoption in the backplane (or collection
> of nearby backplanes) environment.
>
> Coordination:
> Sync-Ethernet (when approved)
> through exchange of drafts
> Ethernet on the backplane
> through exchange of drafts
> P802.17
> through PAR review
> through exchange of drafts
> through WG ballot participation
>
> DVJ
>
>
> David V. James
> 3180 South Ct
> Palo Alto, CA 94306
> Home: +1.650.494.0926
> +1.650.856.9801
> Cell: +1.650.954.6906
> Fax: +1.360.242.5508
> Base: dvj@xxxxxxxxxxxx
--
Michael Takefman tak@xxxxxxxxx
Distinguished Engineer, Cisco Systems
Chair IEEE 802.17 Stds WG
3000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399 cell:613-220-6991