Subject: Re: Ignore ARP requests from remote buses

From: "Wooten, David" <[email-masked]>
Date: Fri, 9 Oct 1998 14:37:42 -0500

Tony,

Responses below.

David Wooten

                -----Original Message-----
                From:   Tony Li [mailto:[email-masked]]
                Sent:   Friday, October 09, 1998 1:38 PM
                To:     [email-masked]
                Subject:        Re: Ignore ARP requests from remote buses

                |  Toni,

                David...  I'm decidedly male.  Really.

                <<DRW: Sorry for the gender bending.  I have a support
person called Toni so it's kind of reflex action for me.>>

                |  I was misusing the term 'bridge' in the 1394.1 context.
In that context,
                |  the protocols are 'supported' by routing 1394 packets
using 1394 node ID's
                |  and channel numbers.  They aren't using IP addresses for
routing.

                Understood.  However, if they are tampering with L3 packets
in an L2
                device, they are certainly much more intelligent than one
would expect.

                <<DRW: right now, I think the 1394.1 committee is resigned
to have to get inside CIP headers to adjust the cycle number.  'Bridge' will
also need to reassign channel numbers as isochronous packets move between
buses.  It will also have to worry about channel and bandwidth allocation
after a bus reset.  Will also have to deal with notification when bandwidth
or channel allocation is lost due to contention.  This is what is needed for
AV/C and isochronous protocol support.  So, most of the smarts have little
to do with cracking packets.>>

                |  It might have been better to have used the term 'router'
for the things that
                |  are used to allow communications between two or more 1394
buses, but that
                |  had some scary connotations also.  Maybe we should call
these things
                |  'gluons'.  I'm sure that the particle physics people wont
mind us co-opting
                |  one of their terms.

                I think that the industry-standard term 'brouter' might as
well be used.
                Until, of course, the marketeers get hold of it.  ;-)

                Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 9 Oct 1998 13:39:24 -0700

|               <<DRW: right now, I think the 1394.1 committee is resigned
|  to have to get inside CIP headers to adjust the cycle number.  'Bridge' will
|  also need to reassign channel numbers as isochronous packets move between
|  buses.  It will also have to worry about channel and bandwidth allocation
|  after a bus reset.  Will also have to deal with notification when bandwidth
|  or channel allocation is lost due to contention.  This is what is needed for
|  AV/C and isochronous protocol support.  So, most of the smarts have little
|  to do with cracking packets.>>

And it has to twiddle ARP packets.  And it is going to have to deal with
MCAP and twiddle that.

Tony