Subject: Re: stds-1394: Re: Revised BCM Election Process

From: Peter Johansson <[email-masked]>
Date: Fri, 21 May 1999 12:01:34 EDT

In a message dated 99-05-21 06:11:57 EDT, [email-masked] writes:

<<What I would think of an orderly way, would be something like a
ROOT_CAPABILITIES csr, implemented on new nodes, that uses a bit for each
type of capability that is or will be defined in the future. This way with
*one* simple check a node can find out if it is more capable or not for being
the root. It won't have to check for BCM, then for P1394b, then for something
else, etc. Then an extended Serial Bus Manager, can read the
ROOT_CAPABILITIES of all nodes, and forceroot the best node. If we have a
hierarchy on root-capabilities, then the SBM can elect the best node, even
without knowing what each capability bit means! No timings, no multiple
contentions, and no extra traffic no matter how many root-capabilities are
defined in the future. SBM election is clearly defined and stable, and P1394a
provides a good way (abdicate bit) for a more capable SBM to shutdown a less
capable SBM. This looks to me like an orderly, extensible and clean
solution.>>

This proposal doesn't meet the P1394.1 needs for timeliness.

1) If there is no bus manager, how is a BCM elected?

2) If the bus manager is not aware of the existence of ROOT_CAPABILITIES, how
is a BCM selected?

Also, the appeal of ROOT_CAPABILITIES is illusory. There is no need to first
check for X, then check for Y, then check for Z and so on. If it's understood
that there is a hierarchy, you check for the tell-tale signs of the highest
element in the hierarchy you implement. If it's present in the root, you are
not more capable than the root and are not permitted to set your won
force_root TRUE. If it's absent in the root, you are more capable and may
proceed in your attempt to become root.

<<Similarly we could extend the same kind of idea for other, software related
protocols that don't have to be on the root. So we can easily define various
types of software protocols that need a manager to be elected, and have the
eSBM perform the contention and select the manager of each protocol, no
matter whether it knows about the protocol or not.>>

This is off the immediate topic, which is the BCM election process in P1394a,
but consideration has been given to having some sort of "name service" and or
"contention facilitation registers" in the extended bus managers. In the
discussions I've had, the proposals have always been abandoned as incomplete
solutions. For example, how much space is enough space to register and point
to these various managers?

I've come to put my faith in a different approach: avoid the need for
"managers" as new protocols are developed. Perhaps you think this is
hypocritcal, since I am advocating for the BCM. I see it differently: a)
there are a finite number of fundamental capabilties necessary for Serial
Bus; b) 1394-1995 identified some, but not all of them; c) we've discovered a
fundamental need for a default broadcast channel (this is not a need
particular to any one protocol) and d) there may be some more fundamental
capabilities (like P1394b arbitration) that must be added in the future, but
"fundamental" capabilities are, by definition, self-limiting.

Each time a call is made to add a new "fundamental" capability to the root,
the standard of proof will be higher and higher. This is not a process that
will be friendly to the whimsical or unjustified addition of new complexity
or new functionality.

In all of the discussion of the BCM I have heard much skepticism about *how*
it is to be selected. I have not heard any challenges to its fundamental
nature.

If there is widespread agreement that the BCM is fundamental, let's not argue
against its selection process on the grounds that, if adopted, it will breed
more unwelcome complexity in the future. Let's attack the problem of how we
add a fundamental capability to Serial Bus at this late state. Here are my
proposed criteria for judging solutions:

* TIMELINESS P1394.1 requires the ability to promptly use a well-known
channel to keep cycle masters on different buses in frequency lock with each
other.

* DISTRIBUTED ALGORITHM I think we should avoid the necessity for a single
node (e.g., the bus manage) to makes things work unless it is the node with
the "new" capabilities itself.

* SIMPLICITY Always a term subject to much debate. To put in in more concrete
terms, implementation of BCM capability needs to be simple "enough" so that
the facility becomes ubiqutous. Of course, this is just a tautological
reflection of the assertion that the BCM is fundamental.

By those criteria, I think the BCM contention proces described in 99-005r1 is
the best proposal advanced to date.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 21 May 1999 11:00:32 -0700

I also believe the part of Dimtris idea about the SBM is problematic for the
reason's
Peter states below.

I was advocating using a single register to identify all capabilities. Any
candidate winner MUST
be IRM capable as with past proposals. Additional registers could be used to
identify capability
specific resources (e.g. channel numbers). If we can separate resource
identification from the
election process, an alternative election process may use self id packet
extensions.

Consider these additions to Peter's requirements:
* EXTENSIBILITY Allow other capabilities to be added at a later time.  See
mail from Venkat.

* SEPARATE ELECTION PROCESS & RESOURCE IDENTIFICTION MECHANISMS. See above
explanation.

> will be friendly to the whimsical or unjustified addition of

I like the idea of extended self id packets even more because it will
require a mod
to the 1394.a spec or some 1394 spec thus prevent someone from simply
increasing
the value of a register in an implementation to become the highest capable
node. Of
course we must agree on a single register first.

-myron