Re: [RPRWG] Backplane ring study group
Raj,
Please excuse the delay in responding.
I wanted to wait for our reflector to be setup, so that we can
avoid unnecessarily flooding other reflectors.
The nature of backplane failures depends on the configuration
chosen for the backplane, and configuration options could change
based on inputs from the SG/WG. With that disclaimer, I'll attempt
to answer your question.
>> David, I am sure you have considered this but I did not recollect having
>> seen any thought on the following question:
>>
>> If a P1796 backplane bus were to pass thru a bunch of line cards
>> and some common resources will the removal of any of these cards/resource
>> cause a 802.17-like protection switching event to happen?
As per the strawman configuration, this would invoke wrapping or
steering, depending on which option was supported. The interleaved
nature of the backplane would ensure the removal of a card does
not sever the connectivity.
>> Further, will the removal of card map to an
>> event like that of a removal of node on a 802.17 ring?
As per the strawman, yes.
>> How will empty slots be handled?
As per the strawman, consecutive card slots with one terminator
between the populated and unpopulated slots.
>> Will I need an active backplane or could I use a passive backplane?
As per the strawman proposal, passive.
Of course, this strawman is only one possibility. A star connection
(as has been discussed in Ethernet) is also possible.
I tend to prefer the strawman proposal to a star, since it provides
connectivity without an active backplane and/or special routing slot.
Also, the cost is incremental, in that each card provides its
"switching" component. And, for small numbers of cards, a shortest-path
dual ring connection is actually fairly efficient, from a pin-bandwidth
perspective.
However, we're still a study group and haven't delved into this in detail.
** What are your favorite backplane configuration options?
** As a practical implementer, your inputs are most valued.
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@alum.mit.edu
>> -----Original Message-----
>> From: Raj Sharma [mailto:raj@luminous.com]
>> Sent: Wednesday, May 05, 2004 3:04 PM
>> To: David V James; STDS-802-17@listserv.ieee.org
>> Subject: RE: [RPRWG] Backplane ring study group
>>
>>
>> David, I am sure you have considered this but I did not recollect having
>> seen any thought on the following question:
>>
>> If a P1796 backplane bus were to pass thru a bunch of line cards
>> and some
>> common resources will the removal of any of these cards/resource
>> cause a 802.17-like
>> protection switching event to happen? Further, will the removal
>> of card map to an
>> event like that of a removal of node on a 802.17 ring?
>> How will empty slots be handled? Will I need an active backplane
>> or could I
>> use a passive backplane?
>>
>> raj
>>
>>
>>
>>
>> > -----Original Message-----
>> > From: owner-stds-802-17@listserv.ieee.org
>> > [mailto:owner-stds-802-17@listserv.ieee.org]On Behalf Of David V James
>> > Sent: Wednesday, May 05, 2004 12:46 PM
>> > To: STDS-802-17@listserv.ieee.org
>> > Subject: [RPRWG] Backplane ring study group
>> >
>> >
>> > All,
>> >
>> > At the 12Apr2004 MSC meeting, a PAR was approved for:
>> > P1796 Resilient backplane ring (RBR)
>> >
>> > We cannot meet as a working group until the submitted PAR is
>> > approved by the IEEE. In the meantime, however, we can have
>> > an organizing study group teleconference:
>> >
>> > Scheduled Conference Date: Friday, May 07, 2004
>> > Scheduled Start Time: 1:30 p.m. Pacific Daylight Time
>> > Scheduled End Time: 3:30 p.m. Pacific Daylight Time
>> > Dial-in Number: 1-702-835-5000 (Las Vegas, Nevada)
>> > Participant Access Code: 17960504
>> >
>> > The wording of the submitted PAR scope is as follows:
>> > "Resilient backplane ring (RBR) is a backplane interconnect
>> > based on the
>> > dual-ring resilient topology of Resilient Packet Ring and
>> > the 802 MAC
>> > addressing structure. RBR includes features appropriate for the
>> > low-latency
>> > backplane environment: destination-based flow control, low-power
>> > short-haul
>> > PHY, backplane-to-backplane links, transport of IEEE-1394
>> > isochronous
>> > data,
>> > and support of IEEE-1596 memory-update operations."
>> >
>> > Background material includes:
>> > http://grouper.ieee.org/groups/msc/MSC200404/RbrSlides2004Mar31.pdf
>> > http://grouper.ieee.org/groups/msc/MSC200401/RprBackplane.pdf
>> >
>> > Items on the agenda include:
>> > 1) Formulation of email reflector lists.
>> > 2) Review of approved PAR.
>> > 3) Sollicitation of technical inputs and strawman proposals.
>> > 4) Discussion of related activities.
>> > 5) Future meeting schedule.
>> > 6) Other items as requested.
>> >
>> > In particular, this is an opportunity to suggest directions, revisions
>> > of the slides and objectives, and/or strawman proposals. While the
>> > background information may look pretty, its content should not be
>> > viewed as a constraint/limitation as we move forward.
>> >
>> > I appoligize for the short notice, but things have been delayed as
>> > an offered host has failed to materialize as expected.
>> >
>> > Since teleconferences are free (see freeconference.com, for
>> > such things),
>> > we can have these as often as desired.
>> >
>> > 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@alum.mit.edu
>> >
>>