Subject: Revised BCM selection process

From: Peter Johansson <[email-masked]>
Date: Mon, 3 May 1999 17:21:41 EDT

In order to satisfy requirements for extensibility for future standards, the
BCM election process described in P1394a has been revised.

It still follows closely the process described in earlier
Draft-IETF-IP1394-IPv4 documents: the goal is to have the isochronous
resource manager and the braodcast channel manager be one and the same node.
This resolves the election VERY quickly after a bus reset.

The revised algorithm diverges when the isochronous resource manager is not
BCM-capable. Whereas the old process employed a deterministic back off and
resulted in the victory of the BCM candidate with the largest physical ID,
the new algorithm requires that the BCM candidate set its own root hold-off
(RHB) bit and initiate a bus reset. This should result in the BCM candidate
becoming the isochronous resource manager and therefore becoming the BCM.

The details are contained in 99-005r1, an excerpt from the forthcoming final
draft of P1394a. You are encouraged to download the PDF file from
ftp://ftp.symbios.com/pub/standards/io/1394/P1394a; look in the /Documents
directory.

Regards,

Peter Johansson
Chair, IEEE P1394a BRC

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Kenji Fujisawa <[email-masked]>
Date: Wed, 5 May 1999 06:08:35 +0900

>becoming the isochronous resource manager and therefore becoming the BCM.

It seems this clause corresponds step f).

: f) If the current isochronous resource manager does not implement the
:    BROADCAST_CHANNEL register, a new isochronous resource manager that
:    is also broadcast channel manager-capable shall be selected.
:    A candidate broadcast channel manager shall set its own force_root
:    variable TRUE, clear those of all other nodes to FALSE and then
:    initiate a bus reset. The broadcast channel manager selection
:    algorithm resumes with a);

Then, why the BCM shall allocate #31 in step g) ?
If #31 is allocated by some other applications or by some other nodes,
what the BCM should do?
Note that current typical BCM is implemented by the software,
it is NOT guaranteed that the BCM process is fastest.

: g) The broadcast channel manager shall allocate channel number 31
                                   ================================
:    from its own CHANNELS_AVAILABLE register and then update its
:    own BROADCAST_CHANNEL register with the allocated channel number
:    and set the valid bit to one.    [snip]

For others information, 'bcm_ID' field in the BROADCAST_CHANNEL register
is removed by this revision.
Are there any other big changes?

Best Regards,

Kenji Fujisawa