Subject: Revised BCM selection process

From: Peter Johansson <[email-masked]>
Date: Tue, 4 May 1999 01:23:18 EDT

I posted an outdated PDF file to the P1394a FTP site earlier today; it was
missing a section on "Determination of the root (cable environment)" that
describes use of RHB in detail.

If you've downloaded 99-005r1 prior to your receipt of this message, please
get a fresh copy 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: "Hattig, Myron" <[email-masked]>
Date: Thu, 6 May 1999 09:22:41 -0700

Peter,

> <<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.>>
>
> It is theoretically impossible for some other node to
> allocate channel 31,
> since the BCM owns the CHANNELS_AVAILABLE register. But I
> take your point
> about software implementations of the BCM.

I agree with Kenji. This problem certainly is theoretically possible if
the BCM/Broadcast channel text does not explicitly state, the IRM/BCM
node will not accept any read/lock requests until *after* it allocates
channel 31. The concern increases  with nodes that implement the BCM
in higher layer software modules while leaving the IRM implementation
in lower layers.

BTW, I agree with your other comments that the BCM implementation should
reside in lower layers with the IRM, but this is not reality today for many
of
the platforms on which IP/1394 will be first implemented.

By adding the above clause to the BCM/Broadcast Channel text,  we help
avoid problems that may occur with interfaces that have the BCM and
IRM implemented at different layers.

-myron

---

From: Venkat Tanikella <[email-masked]>
Date: Thu, 6 May 1999 15:47:33 -0700

Peter,

-----Original Message-----
From: Peter Johansson <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, May 03, 1999 2:22 PM
Subject: Revised BCM selection process

>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.
>

As I understand from  section 8.3.1 Node Capabilities taxonomy, there is no
necessity that an IRM capable is also CM capable. For the scheme mentioned
here to work, then it has to be explicitly stated that the BCM should
necessarily be CM capable. This seem to be missing in the document.

Or from section 9.23, "Determination of the root" in this document is it the
intention to say that if a BCM candidate node is not CM capable, it should
not force root itself ? (And in which case on a bus where there are only
two  IP capable nodes (among many other nodes) with out CM capability cannot
have IP, as none of them could become BCM ?)

regards,
Venkat

>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: Venkat Tanikella <[email-masked]>
Date: Thu, 6 May 1999 20:23:39 -0700

Using a available channel rather than a fixed channel like 31, seem to be a
better Idea.

On OHCI,  I am wondering if we could acheive the desired effect by disabling
the Async Receive in the SID interrupt? May be any OHCI implmentors can
comment on this.

Also as a side thought -  If it is really possible to reserve a specified
fixed channel, in all implementations hardware or software, then I am
wondering why at all we need the boradcast channel register and the BCM
procedure, if we can declare that a specific channel is always designated as
broadcast channel ? In other words irrespective of whether a BCM is present
or not set aside a channel as reserved. Is it not reasonable to set aside
one channel out of 64, all the time, assuming there could be potentially
atleast two  ip nodes on a 1394 bus ?  Also on a bus with 63 nodes, assuming
a sender - listener per channel an average of 2 channels are available per
node, can we not afford to set aside one channel exclusively for broadcast ?

-Venkat

-----Original Message-----
From: Kenji Fujisawa <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, May 06, 1999 6:54 PM
Subject: Re: Revised BCM selection process

>I could not find how to disable the Physical Request function for
>the Bus Management CSR registers (such as CHANNELS_AVAILABLE reg)
>in the OHCI spec 1.0.  Would you teach me if it exists?
>
>If it can't be disabled, it means we can not achieve following
>restriction by the OHCI 1.0.
>
>>>BCM CAPABILITY NEEDS TO BE IN THE SAME COMPONENT THAT IMPLEMENTS THE IRM,
>>>WHETHER THAT IS HARDWARE OR SOFTWARE.
>
>I think it can not be accepted in the real world.
>
>I prefer following approach.
>
>:Also, I think dynamic allocation increases the probability of proper
>:operation in implementations where the BCM and IRM are implemented within
>:different modules.
>
>Kenji Fujisawa
>

---

From: Peter Johansson <[email-masked]>
Date: Fri, 7 May 1999 13:58:49 EDT

In a message dated 99-05-06 12:22:53 EDT, [email-masked] writes:

<<I agree with Kenji. This problem [of another requester allocating channel
31] certainly is theoretically possible if the BCM/Broadcast channel text
does not explicitly state, the IRM/BCM node will not accept any read/lock
requests until *after* it allocates channel 31. The concern increases  with
nodes that implement the BCM in higher layer software modules while leaving
the IRM implementation in lower layers.>>

We're getting down to fine details here. Strictly speaking, the BCM/IRM may
accept lread requests unconditionally---between the time some node reads
CHANNELS_AVAILABLE and subsequently attempts a lock some other node may have
beaten it to the punch. The BCM/IRM may accept lock requests, so long as it
does not allocate channel 31 BEFORE it has marked it allocated in the bit
mask. Of course, the simplest solution is for the bit that represents channel
31 to be set to one almost immediately after a bus reset---but this is an
implementation choice that need not be constrained by the standard.

I will work on some language that addresses your concern and post it to the
reflector. In a naive sense, simply the requirement that the BCM "shall
allocate channel 31" carries with it all of the considerations you
raise---but I understand that it may be better to be overly cautious in the
standard.

<<BTW, I agree with your other comments that the BCM implementation should
reside in lower layers with the IRM, but this is not reality today for many
of the platforms on which IP/1394 will be first implemented.>>

So let's examine the impact when the BCM doesn't reside there and determine
the best approach to support migration to the better solution.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: "Wooten, David" <[email-masked]>
Date: Fri, 7 May 1999 14:59:17 -0500

Peter,

Is it true that the tags used for the asynchronous packets over the
broadcast channel are different from any of the currently defined
isochronous ones so that devices can still filter based on usage?  I don't
care much either way cause I think that if the AV folks can grab a default
broadcast channel (63) the other people who also have legitimate uses can
too. ;-)

David Wooten

> From: Peter Johansson [mailto:[email-masked]]
> Sent: Friday, May 07, 1999 12:59 PM
> To: [email-masked]

---

From: Peter Johansson <[email-masked]>
Date: Sat, 8 May 1999 14:11:20 EDT

In a message dated 99-05-07 16:36:14 EDT, [email-masked] writes:

<<Is it true that the tags used for the asynchronous packets over the
too.>>

The meaning of TAG (which specifies stream packet format) depends upon
context, asynchronous or isochronous:

                Stream type
TAG     Asynchronous     Isochronous

 0       unspecified     unspecified
 1          GASP       IEC 61883-1:1998
 2        reserved         reserved
 3        reserved         reserved

By the way, my recollection is that you were in favor of this overlapped use
of TAG. Actually, I think one MUST know the context, asynchronous or
isochronous, before filtering. So there is nothing to be gained by assigning
different TAG values to GASP and IEC 61883.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: "Wooten, David" <[email-masked]>
Date: Sat, 8 May 1999 14:39:39 -0500

Peter,

I believe you when you say that I suggested that the tag values have
overlapped usage.  That doesn't mean that I remember what was decided.  I
also don't doubt that we must make sure that we don't put isochronous and
asynchronous stream traffic on the same channel.  So, is it your belief
that, from a specification point of view, we can catch people before they
end up choosing channel 31 (hint, your answer had better be "yes". ;)

David Wooten

> Sent: Saturday, May 08, 1999 1:11 PM

---

From: Venkat Tanikella <[email-masked]>
Date: Thu, 20 May 1999 10:44:06 -0700

-----Original Message-----
From: Peter Johansson <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, May 20, 1999 8:42 AM
Subject: Re: Revised BCM selection process

>In a message dated 99-05-20 04:32:59 EDT, [email-masked]
writes:
>
><<...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.>>
>
>I believe it's essential to create such a hierarchy, NOW, while we still
can.
>The point is that there are going to be some future needs, not all of which
>have been imagined yet, that can only be met by placing them in the root.
The
>"adjustable cycle master" for P1394.1 needs is one such example, the
>desirability of a P1394b node as root in a mixed environment is another.

From "future needs, not all of which have been imagined yet that can only be
met by placing them in the root", I see a problem. As of today with the
current BCM selection process, an IP capable node shall essentially be
    - CM capable
    - IRM capable (as per 1394-1995)
    - BCM capable

Say we make an IP1394 implementation as per this, and whatever is the latest
IP1394 spec. Now if there is a future compulsary need, not imagined yet that
has to be placed on root, that implies that all the existing IP1394
implementations need to upgrade themselves to implement the  *new
responsibility* associated with the root.  Please not that more than new
implementation efforts it is a interoperability issue across the time line
when we figure out more such responsibilities on the root. And also this is
not just a problem from IP1394 perspective, but for any other functionality
with such needs as IP1394.

From this perspective I would say the current IP1394 spec can not be frozen
effectively all such future needs are effectively imagined and realized.
Alternatively we need a IP1394 spec that does not require such a close
association with BCM capability, or we should have a BCM solution that is
not so tightly associated with the "root",  as long as there is scope for
more responsibilites not imagined yet to be associated with root.

To me the problem stems from the fact that there are two requirements on
BCM, simultaneously
    - Always allocating channel 31.
    - Also to become root.

If we break this capability into two individual capabilities, let us say for
the disussion sake,

minimalBCM
     - Check for a valid Broad Cast Channel register of superBCM below,
       and if it is not valid, Allocate channel 31, irrespective of whether
it is IRM
       or not. (And store this channel information in an independent
register, like in
        the old NPM). This would take care of other dependednt specs like
IP1394.

superBCM
    - minimalBCM + initiate a force_root, if not root + IRM + Broadcast
Channel
      Register. This would take care of the stringent requirements of
bridging.

then by stating that IP1394 capable nodes need to be only minimalBCM
capable, this would make the IP1394 spec stable across all future variations
in other related specs.

There could be loop holes in this, but I beleive any thing that is worked
out by  introducing finer classification in the existing BCM on above lines
shall work better for all process involved with broadcast.

Please let me know If I am missing some thing grossly here.

-Venkat

---

From: Peter Johansson <[email-masked]>
Date: Thu, 20 May 1999 15:13:52 EDT

In a message dated 99-05-20 14:11:19 EDT, [email-masked] writes:

<<I was under the impression that first bus reset would clear the force_root
flag on all nodes. I did not see clearly mentioned anywhere that force_root
is sticky, neither the opposite of course. It can only be implied by looking
at reset_start_actions, reset_complete_actions etc.>>

No, once the PHY register RHB bit is set to one it stays set to one unless
zeroed by a power reset or a PHY configuration packet. This is true of both
IEEE Std 1394-1995 and draft standard P1394a.

<<Is this [the hurry to allocate channel 31] because there is theoretically a
window of opportunity that 31 gets allocated by someone else that is not a
BCM candidate?>>

No, it is because P1394.1 has an immediate need for a well-known channel
immediately after a bus reset or else isochronous traffic may be compromised
throughout the entire net of interconnected buses.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Peter Johansson <[email-masked]>
Date: Thu, 20 May 1999 15:13:51 EDT

In a message dated 99-05-20 13:44:11 EDT, [email-masked] writes:

<<Please let me know If I am missing some thing grossly here.>>

I don't know how gross it is or isn't, but we're miscommunicating in some
important ways...

<<Say we make an IP1394 implementation as per this, and whatever is the
latest IP1394 spec. Now if there is a future compulsary need, not imagined
yet that has to be placed on root, that implies that all the existing IP1394
implementations need to upgrade themselves to implement the  *new
responsibility* associated with the root.  Please not that more than new
implementation efforts it is a interoperability issue across the time line
when we figure out more such responsibilities on the root. And also this is
not just a problem from IP1394 perspective, but for any other functionality
with such needs as IP1394.>>

Existing IP1394 implementations do NOT need to be retrofitted with the new
capabilities. The whole idea of the hierarchy if to preserve existing
software investment and at the same time make it possible to add new
(possibly essential) features in the future.

If some NEW node comes along and clears your for_root variable, DON'T get in
a turf war with it over who should be root! You may rely on the fact that it
knows that it is more capable than you are---otherwise it would be a
violation of the rules for it to set its own RHB to one.

<<From this perspective I would say the current IP1394 spec can not be frozen
effectively all such future needs are effectively imagined and realized.
Alternatively we need a IP1394 spec that does not require such a close
association with BCM capability, or we should have a BCM solution that is not
so tightly associated with the "root",  as long as there is scope for more
responsibilites not imagined yet to be associated with root.>>

As explained above, IPv4 over 1394 can be frozen.

If you want to propose another BCM solution, it will have to meet the needs
of P1394.1 for TIMELY availability of a well-known channel number. No, i
don't think the proposal below works.

<<To me the problem stems from the fact that there are two requirements on
BCM, simultaneously

<<If we break this capability into two individual capabilities, let us say
for the disussion sake,

minimalBCM: Check for a valid Broad Cast Channel register of superBCM below,
and if it is not valid, Allocate channel 31, irrespective of whether it is
IRM or not. (And store this channel information in an independent register,
like in the old NPM). This would take care of other dependednt specs like
IP1394.

superBCM: minimalBCM + initiate a force_root, if not root + IRM + Broadcast
Channel Register. This would take care of the stringent requirements of
bridging.

By stating that IP1394 capable nodes need to be only minimalBCM capable, this
would make the IP1394 spec stable across all future variations in other
related specs.

There could be loop holes in this, but I beleive any thing that is worked out
by  introducing finer classification in the existing BCM on above lines shall
work better for all process involved with broadcast.>>

This is simple? A few questions...

What happens if the epsilon minus minus minimal BCM can't get channel 31?

Why would I choose to implement the minimal BCM? It's duties seem more
complicated than the "super" BCM.

IP-capable nodes have to implement both the BROADCAST_CHANNEL register and
some other similar register. Which one do they believe?

Where are you going to get a well-known address for this other register?

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: Fri, 21 May 1999 12:54:51 +0300

Hi,

can.
The
>If we don't have an orderly way to incrementally extend the root's
>capabilities, as justified, we run a serious risk of boxing ourdelves into
a
>corner in future.

A general-capability hierarchy, is a different thing that a set of
requirements
to be placed on root nodes. For such requirement we could possibly set
a hierarchy if needed. I agree that we should find a way to extend
the root's capabilities in an orderly way, but is the current proposal
an orderly way?

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.

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.

---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------

---

From: "Allison, Art" <[email-masked]>
Date: Fri, 21 May 1999 09:14:02 -0400

I admit to only having a surface level understanding, but this proposal
seems fundamentally more sound and robust than previous ones.
Art
::{)

-----Original Message-----
From: Dimitris Staikos [mailto:[email-masked]]
Sent: Friday, May 21, 1999 5:55 AM
To: [email-masked]
Subject: Re: Revised BCM Selection Process

Hi,

can.
The
a

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 21 May 1999 08:42:28 -0700

Art,

And then there are the details ....

The detail that is missing from this proposal is the identification
of the resource. In the case of BCM the "resource" is the channel
number. Other capabilities may have other resources.

Despite this deficiency, I think Dimitris idea is a better idea
to elect a "winner" than reading a bunch of registers. I'm wondering
if the info to elect a winner cannot exist in extended self ID packets.
This removes the need to elect a winner via reads/writes of registers.

Even Ditmitris idea of a single register with all capabilities is better
than one register per capability. With a single register the "winning"
algorithm could simply be the node with the largest value wins.

The reading of the registers would still be necessary to learn of
specific resources necessary (e.g. channel number). However, if
the resource is fixed as in the case of channel 31, there is no
need for the resource register at all.

I'm still wondering why the channel *must* be a fixed value.

-myron

> From: Allison, Art [mailto:[email-masked]]
> Sent: Friday, May 21, 1999 6:14 AM