Subject: Re: P1394a BRC input

From: Peter Johansson <[email-masked]>
Date: Tue, 29 Jun 1999 15:58:32 EDT

Tom, your EMail of June 16 was very useful to the BRC. It helped focus our
efforts to improve the "broadcast channel manager" concept. We reached a
consensus that there is, in fact, no broadcast channel manager---only an
"enhanced" isochronous resource manager. The changes are in the P1394a draft
candidate for recirculation ballot, which will be available soon as a PDF
file.

In the meantime, responses to your comments are intermixed below.

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]

********
In a message dated 99-06-16 12:57:03 EDT, [email-masked]
writes:

<<Section 9.20

The statement in the first sentence that the BCM register is optional could
be confusing. It is optional under the conditions stated in the following
sentences. Maybe a reference to 9.15 should be made.

The last paragraph references section 9.26 which should be 9.27. This may
have been noticed already by someone else, I am not sure anymore.>>

As a result of all the changes alluded to above, the first paragraph of this
clause now reads: "This register is optional and if implemented shall be a
quadlet register located at offset 0x234 within initial register space. All
isochronous resource manager-capable nodes shall implement the
BROADCAST_CHANNELS register."

I think this is much clearer than it was before!

The last paragraph no lonfer references any clause.

<<Section 9.25

I think that the wording of the 2nd rule and its explanation in the last two
paragraphs is vague. Maybe an example as below would help (please correct me
if my example is wrong).>>

Again, your comments have helped the BRC to simplify. The revised rule is "A
node’s force_root variable shall not be set TRUE unless the node is more
capable than the current root."

Your example (not reproduced here) is correct, Tom. The BRC agrees it might
be valuable to include as an informative annex, but time and workload prevent
its incorporation into the P1394a candidate destined for recirculation
ballot. Perhaps a 1394 Trade Association "white paper" would be useful?

<<The new rule currently has a double negation ("shall not be set TRUE unless
....) and leavers open who takes the action and what should happen in case
the node is more capable. If my understanding is correct, I would suggest a
rewording of the new rule that seems to capture all we need to say:

...if a node detects that it is more capable than the current root, it shall
force itself to become root by:
         --- setting its OWN force_root,
         --- sending a PHY config packet to clear force_root on other nodes
         --- generating a bus reset.>>

See the comment above; the revised rule is what is necessary to avoid a
"bidding war" between two nodes to become the root.

<<Section 9.27

From the current text it is not clear for me whether or not channel 31 is now
reserved for async streams as used e.g. by IP1394 and P1394.1. The first
paragraph sais "... is responsible to allocate a channel ....".  Channel 31
is only mentioned in step g). My understanding is that P1394a in the e-mail
discussion agreed to explicitly reserve channel 31 as the default async
stream channel and to forbid any isoch application to use this channel. If
this understanding is correct I would suggest to make an update of section
8.3.2.3.8 in 1394-1995 (the CHANNELS_AVAILABLE CSR) that explicitly states
this.>>

A new clause has been added to the draft, CHANNELS_AVAILABLE register, which
makes it explicit that isochronous resource managers compliant with P1394a
automatically allocate channel 31.

<<If the BCM changes the default channel, is c31 still reserved for async
streams or can isoch applications then start using c31?>>

The BCM can't change the default broadcast channel; the value of 31 is now
hard-wired in the channel field of the BROADCAST_CHANNEL register.

<<Is the BCM register unchanged after a bus reset? If so, doesn't step g)
need to re-allocate that channel instead of channel 31?>>

No, the valid bit zeros as the result of a bus reset. At the isochronous
resource manager it instantly flips to one---since the IRM automatically
allocates channel 31.

<<If c31 is ALWAYS reserved for async streams, is there ever a need for the
BCM to change the channel?>>

No, there is no need to change the channel.

<<If there is no need to change the default channel, why do we need a BCM? In
that case we simply have a "well-known" default channel.for async streams.>>

In a sense, we DON't need a broadcast channel manager: the isochronous
resource manager is NOT REQUIRED to write to other nodes' BROADCAST_CHANNEL
registers. HOWEVER, we still need the isochronous resource manager to
allocate channel 31 so that no other application is able to do the same.

<<...the standard needs clarification ... Section 9.30>>

<<The STATE_SET register is not defined in 8.3.2.2.1 but 8.3.2.2.2.>>

Thank you; the reference has been corrected.

<<The word "otherwise" in clause c) seems to double the "else" in clause b)>>

I took out the offending "else".

---

From: Nagaraj G <[email-masked]>
Date: Wed, 30 Jun 1999 08:49:55 +0530

Hi Peter,

In clause 9.22 for the definition of BROADCAST_CHANNEL register, the initial
value for the channel field is 31, and you said it is hardwired.

In clause 9.28 for the determination of the IRM, in the 6th paragraph, it
says "A contender that becomes the isochronous resource manager shall update
its own BROADCAST_CHANNEL register by setting the valid bit to one and the
channel field to 31;..."

When the default (hardwired) value for channel field is 31, why should it
update this field every time. Is the updation of valid bit not sufficient in
this case?

Best Regards,

Nagaraj

-----Original Message-----
From: IETF IP over 1394 Working Group
[mailto:[email-masked]]On Behalf Of Peter Johansson
Sent: Wednesday, June 30, 1999 1:29 AM
To: [email-masked]
Subject: Re: P1394a BRC input

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]

********

<<Section 9.20

<<Section 9.25

Your example (not reproduced here) is correct, Tom. The BRC agrees it might
be valuable to include as an informative annex, but time and workload
prevent
its incorporation into the P1394a candidate destined for recirculation
ballot. Perhaps a 1394 Trade Association "white paper" would be useful?

<<The new rule currently has a double negation ("shall not be set TRUE
unless
....) and leavers open who takes the action and what should happen in case
the node is more capable. If my understanding is correct, I would suggest a
rewording of the new rule that seems to capture all we need to say:

<<Section 9.27

<<If there is no need to change the default channel, why do we need a BCM?
In
that case we simply have a "well-known" default channel.for async streams.>>

<<The word "otherwise" in clause c) seems to double the "else" in clause
b)>>