Re: [RPRWG] Rough outline of PAR for the RPR on the backplane
In 1997 there was:
http://www.reed-electronics.com/ednmag/archives/1997/110697/23le.htm
An then you follow the thread to:
http://www.sebringring.com/
Now, you know the rest of the story...
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxx]On Behalf Of Mike Takefman
> Sent: Thursday, April 08, 2004 6:28 AM
> To: STDS-802-17@xxxxxxxxxxxxxxxxx
> Subject: 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
>