Subject: Re: Revised BCM selection process

From: Peter Johansson <[email-masked]>
Date: Mon, 17 May 1999 14:15:44 EDT

In a message dated 99-05-17 08:13:53 EDT, [email-masked]
writes:

<<However I feel not so comfortable if the BCM were to become mandatory for
every IRM. It prefer it to be optional so that only applications that use the
broadcast channel are forced to implement it.>>

I think it's essential that future IRMs also be BCMs.

Given your objections, let's reexamine the functions of the BCM. Maybe there
is room for some adjustment.

As of now, in P1394a 2.x dated May 2 or later, the BCM:

a) shall allocate channel 31;
b) initialize its BROADCAST_CHANNEL register to reflect this allocation;
c) shall confirm the allocation of channel 31 to all other local nodes that
have a BROADCAST_CHANNEL register; and
d) shall attempt to become the IRM (via the force_root variable) if it
discovers that the incumbent IRM is not also a BCM.

Which requirements, in your opinion, are onerous for the IRM and would be
resisted by implementers of the IRM.

I'll guess, on your behalf, that a) and b) are both essential and not the
source of the objections. Is this correct? You would not find it burdensome
to preallocate channel 31 and have a register that shows this allocation?

I'll argue that d) shouldn't be a problem: IRM-capable devices already
implement analogous decision-making logic when they decide to become the IRM
in the absence of an IRM. It should not be too much complexity to expand this
code to encompass a decision to become the IRM if the incumbent is not also a
BCM.

That leaves c), the process of using either a broadcast write or a series of
confirmed writes to copy the BROADCAST_CHANNEL information to other nodes.
Myself, I do not think this is a big deal---but, if this were made optional,
would it change your mind about mandatory support of the BCM in all
IRM-capable nodes?

For all the IETF participants in this thread, if this were optional would the
BCM still be useful for IP over 1394?

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Dimitris Staikos <[email-masked]>
Date: Thu, 20 May 1999 11:12:52 +0300

Hi,

> I think it's essential that future IRMs also be BCMs.

I agree that we should try to avoid forcing BCMs to be IRMs as well.
Yes, indeed adding now BCM requirments to IRM may not be a big
deal really, but in general the capability hierarchy (pg 9.23 in
99-005r1.pdf) seems to be a bad idea altogether.
If we start building on the 'more capable' node concept, then new
problems will soon be met.

Very soon we will need new types of 'capabilities', and I believe that
nobody will implement a capability high in the hierarchy, because it will
take a lot of effort and time to implement and test all others as well,
which will most certainly be quite independent in functionality of one
another.

In my posting about a week ago, I mentioned that one of the inherent
problems of the proposed procedure about an IRM+BCM node
forcerooting itself has to do with the proposed timing.
Consider the following scenario, in the case where the IRM is not
BCM capable:

Nodes A and B have sequential phyIDs so their difference in timing is
15 msec, which is small enough to make the BCM-related processing
execute at the 'same' time on both.

Node A: Checks IRM and finds that it is not BCM capable.
Node B: Checks IRM and finds that it is not BCM capable.
Node A: Sends the forceroot with its own PhyID
Node B: Sends the forceroot with its own PhyID
Node A: Issue Bus Reset
Node B: Issue Bus Reset

Not to mention the fact that we could have 2 bus resets in a very short
time (or more if other nodes are involved in this scenario in various
ways), the question is who will be the root after the second bus reset?
Similarly the same scenario applies in the case of capability hierarchy.
For example consider in the future, when we might have more
capabilities added to the hierarchy, if 10 nodes with varying
capabilities happen to be 'more-capable' than the root and they all
decide that they should become the root, how many bus resets might
happen until the most-capable node becomes the root?

Since we are so much in a hurry to allocate channel 31 from the IRM,
why not make the BCM contention as follows:

Each candidate BCM will try to allocate channel 31 from the IRM,
*immediately* after bus reset. The node that allocates this channel
becomes the BCM, and has to perform any other related duties
(confirming the allocation of channel 31, etc).
Each candidate will have a timeout of 1-2 sec and if by that time
it has not been notified about successful allocation of channel 31
by the BCM, then it knows that there is a problem and might
proceed to take whatever actions required.

This I believe looks equivalent to the proposed functionality and does
not force BCM and IRM functionality on the same node.

---------------------------------------------------------------------------
Dimitris Staikos
[email-masked] (Business mail only please),
[email-masked] (Personal mail), ICQ UIN 169876
Software Systems & Applications Chief Engineer, UniBrain, www.unibrain.com
---------------------------------------------------------------------------
The great pleasure in life is doing what people say you cannot do.
He has the right to criticize who has the heart to help.
Happiness is not a place to travel to. It's a way of getting there.
"Young man, the secret of my success is that at an
    early age I discovered I was not God".
Children require guidance and sympathy far more than instruction.
---------------------------------------------------------------------------