Subject: Bus Reset actions, for multicast

From: Venkata Tanikella <[email-masked]>
Date: Tue, 6 Oct 1998 18:10:18 -0700

Hi,

        The spec doesn't say anything about what should happen in a post
        bus reset scenario, in the case of Multicast channel mappings.
        I have a few questions on this.

        Should multicast channel owners reallocate a (prefarably same)
       channel they own (as a "prior isoch channel owner" )?

        Are transmitters supposed to wait till they see a fresh advertisement
       (with a possibly new channel) after a bus reset ?

        How about receivers, should they continue to listen on the same channel,
      till they see a fresh advertisement ? (This may be less trivial,
        if there are no transmitters, except in the case where a NON IP1394
      entity grabs the same channel and starts pumping in totally diffrent
      info)

-Venkat

---

From: Prabhakara Yellai <[email-masked]>
Date: Tue, 6 Oct 1998 19:51:48 PDT

Venkat,
>        bus reset scenario, in the case of Multicast channel mappings.

   Though explicitly not stated, I guess, the nodes start
   everything from scratch (see below my responses to specific
   cases you mentioned).

>       channel they own (as a "prior isoch channel owner" )?

   Not necessary, but could be a good starting point for
   channel allocation procedures. If the node does no longer
   wish to transmit to a given IP multicast group address
   (say, the tx inactivity timer expires and/or TCP/IP stack
   leaves the group during the BUS RESET), it shall not reallocate
   the corresponding channel and one of the nodes that wish
   to tx shall allocate one after having waited for 10 seconds
   (the non-owners shall not transmit SOLICIT messages as
   it will result in lot of traffic on the bus.). However,
   if the owner itself has been removed from the network,
   the non-owner tx nodes will timeout after 10 seconds and
   initiate channel creation.

>       (with a possibly new channel) after a bus reset ?

   Yes. The non-owner transmitters are not supposed to send
   SOLICIT messages. They can initiate channel creation after
   having waited for 10 seconds.
>      entity grabs the same channel and starts pumping in totally
diffrent

   No. The receivers should invalidate the channel mapping on
   bus reset, release the DMA resources and wait for the
   ADVT messages from the corresponding tx nodes (owners).

   I agree with you that the handling of BUS RESET should
   be specified in the draft.

   I don't know if my understanding explained above is in
   line with how the BUS RESET is handled in the current
   implementations at Intel and Sony - can the reps from
   Intel and Sony listening on this mailing list
   let us know how it is handled?

Prabhakara

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

---

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 7 Oct 1998 10:56:24 -0700

On Tuesday, October 06, 1998 7:52 PM, Prabhakara Yellai
[SMTP:[email-masked]] wrote:
> Venkat,
> >        The spec doesn't say anything about what should happen in
> >        a
> post

I think this is the only reasonable action, flush the cached
channel mappings and have owners reallocate. Receivers
should flush their cached channel mappings and wait for
new advertisements.

About the comment suggesting previous channel owners
should maintain ownership after a bus reset, I don't see any
harm in this approach; there is the benefit of only previous
owners attempting to become owener verses all devices
wanting to be an owner (allocating a channel and sending
a solicit msg).  The cost of course is the additional state
that must be maintained to determine a device wants to
be a channel owner but wasn't the owner previous to a bus reset.

In Intel's implementation, we chose to allow the additional traffic
on the bus and not maintain the additional state in the software.
All owner "wannabes" attempt to allocate the channel, send a
solicit in an attempt to become the owner after a bus reset.

We MUST specify that all nodes flesh their cached channel mappings.
I think we should allow implementers to decide whether non-previous
nodes that desire ownership attempt to become owners or not.

I'll add this to the issue list.

-myron

---

From: "Churchill, Richard" <[email-masked]>
Date: Wed, 21 Oct 1998 09:59:39 -0500

My apologies for not getting around to this earlier, but I have been having
an out-of-office experience, with an associated backlog of emails to deal
with ... Please see comments embedded below.

Sincerely,

Richard Churchill,
(281)514-6984,
[email-masked]

-----Original Message-----
From: Prabhakara Yellai [mailto:[email-masked]]
Sent: Tuesday, October 06, 1998 9:52 PM
To: [email-masked]
Subject: Re: Bus Reset actions, for multicast

>   everything from scratch (see below my responses to specific

A channel is an isochronous resource, even if used for asynchronous streams,
and the handling of it is thus covered by the appropriate clauses of the
1394-1995 standard and subsequent drafts.  If you require behavior
consistent with the behavior required for isochronous applications and
resource users, you cannot be far from right.

In the -1995 standard, there are several sub-clauses dealing with this in
clause 8.  (Sorry, I don't have the document in hand to quote specific
clause numbers.  Comments are from memory.)  The revised p1394a draft will
likely have some minor changes to the procedure for allocating isochronous
resources, but the p1394b draft will make several things more explicit in
order to avoid the ambiguities present in the -1995 standard, as well as
adding new facilities.

Following a reset, you do not start from scratch in reallocating resources.
There is a one second period following the reset during which only those
nodes that owned resources at the time the reset was initiated may
reallocate those resources.  Note that the -1995 standard is not terribly
clear about this, but from several discussions on the topic the conclusion
was drawn that the reallocating nodes may only allocate exactly the same
resources OR LESS during this protected interval, and that the -1995
standard can be interpreted to imply this.  P1394b will codify this.  So,
for purposes of forward compatibility, you should require that the same
multicast channel number(s) should be re-claimed the prior owner immediately
following the reset.  Further, if the same resources cannot be reallocated,
or the IRM changes, you must wait one second before performing any
allocations of isochronous resources.

(Notice that if you merge two buses with isochronous traffic, at least one
of the IRMs will change, and all nodes owning resources on the bus whose IRM
lost out must shut down the associated talkers, then wait for the one second
protected period to expire before attempting allocations of new resources.
Thus, though the listeners to overlapped channels on the "losing" bus may
receive stream packets)

The reasoning behind this "same channel" requirement is simple.  Isochronous
talkers that were active prior to the reset are allowed to continue to use
the same channels and bandwidth they used prior to the reset during the one
second protected period following the reset, if the IRM remains the same,
pending reallocation of those resources.  This helps assure good quality of
service through resets, with minimal interruption in isochronous
applications.  However, if the resources (particularly the channel) used
prior to the reset suddenly are used by other applications, problems ensue.
The chances of experiencing such problems go from nil to real if the
reallocating nodes are allowed to take random swipes at the resources
"available" following the reset, thereby risking the quality of service we
were trying to provide.  Ergo, no random swipes, which also means that
allocations of different channel numbers for the same applications cannot be
made until after the one second protected interval has ended.

Subsequent comments are based not upon the IP draft(s), but upon how the
1394-1995 standard and subsequent revisions and extensions expect things to
behave.

>>       channel they own (as a "prior isoch channel owner" )?>
>

From the above discussion, yes.  You must reallocate the same channel
number, and only the prior owner of that channel may do so.  If you cannot
allocate the same channel number, or if the prior owner of that channel is
no-longer present to perform that reallocation, you must wait until the one
second protected interval following the reset has expired to allocate a
channel.

>   having waited for 10 seconds.

If the IRM did not change through the reset (which may be determined from
the topology indicated by the Self_ID packets received during the bus reset
process, etc.) it is safe for listeners to assume that the channel is safe,
pending notification to the contrary ...

>   ADVT messages from the corresponding tx nodes (owners).

The listener SHOULD listen to the same channel used prior to the reset,
since that is the only channel the prior owner is allowed to reallocate
during the one second interval, and talkers on that channel may resume
operation on that channel immediately upon determination that the IRM did
not change through the reset.

>   let us know how it is handled?

I'm sure I've forgotten a few points, but hope this is helpful in
determining how resources should be handled.