Subject: signature

From: Kenji Fujisawa <[email-masked]>
Date: Wed, 2 Dec 1998 10:21:56 +0900

>I don't consider the signature field an issue because it is part
>of the link fragment header. Link fragmentation applies to async
>write, async stream, and isoch stream. GASP only applies to async
>streams. I will argue strongly that we are better off duplicating
>fields in the GASP header and link frag header, than reworking
>the link frag header.

>> Peter wrote:
>> >>I am assuming that the NODE_IDS registers on both buses have
>> >>their most significant 10 bits set to 0x3FF.

If this assumption is still applicable, multiple nodes on the
bridged 1394 busses may use the same 'signature'.
'signature' can not be used as an identifier of the sender.

As we discussed at Munich meeting, last year,
the main reason to have the 'signature' is for Async Streams.

        Async Write     have src_ID in 1394 header
        Async Streams   no src_ID in 1394 header
        Isoch Streams   only one sender per channel

IF we adopt GASP format, we don't need the 'signature'.

>I'm not sure what bus_ID and phy_ID you're referring to.

This was the bus_ID/phy_ID fields in an MCAP message format.

Kenji Fujisawa

---

From: Myron Hattig <[email-masked]>
Date: Wed, 2 Dec 1998 08:54:20 -0800

> IF we adopt GASP format, we don't need the 'signature'.

I understand your point now, but I don't agree the signature
is not needed. I don't want the layer of software doing link
fragmentation to be required to look a the 1394 header.
It's probably possible in most 1394 stacks, but messy.

I'm still considering the problem of multiple devices having
the same first 10 bits of 0x3FF in the signature when bridges
are introduced. If we can find a different 16 bit unique number
then our problem would be solved. We also have the  datagram ID
bits to provide uniqueness among packets. It seems taking 16 bits
from the EUI-64 or the devices serial number would provide
the uniqueness we need. I'm not sure though.

-myron

---

From: Kenji Fujisawa <[email-masked]>
Date: Thu, 3 Dec 1998 10:35:17 +0900

>It's probably possible in most 1394 stacks, but messy.

The link fragmentation/reassembly is a part of the link layer.
It is not so bad.

And the ARP layer exists above the link fragmentation/reassembly layer.
"IF" we choose GASP proposal, this modification does not make things
worse.

Passing the link header to the DHCP server module is worse than this.

Kenji Fujisawa

---

From: Myron Hattig <[email-masked]>
Date: Thu, 3 Dec 1998 08:49:57 -0800

> Passing the link header to the DHCP server module is worse than this.

Luckily no one has suggested that.

I guess what I'm really opposed to is being dependent on the GASP
header for functionality other than that needed by bridges because
the briding WG may decide to change the GASP header. I doubt the
brigding WG would break anything needed by IP, but I think
we do want to allow the IP/1394 spec to stand on its own and
the bridging spec to stand on its own. Basically, is the GASP
header specification an integral part of the IP/1394 spec or
does the IP/1394 spec simply reference the GASP header section
of the bridging spec? If IP/1394 references the bridging spec,
the bridging WG is free to do whatever they need to. If we put
the GASP head in the IP/1394 spec, then the bridging group
must either reference the IP/1394 spec or create identical text
that will never change. I don't see how this can work reasonably.

What do people think of changing the ARP as Peter suggested in
the GASP proposal, leaving signature in link frag header, not
changing the MCAP header, and the IP/1394 spec making a
reference to the GASP header in the brigdind spec. This
allows the brigding WG to maintain control over the GASP
header and allows us to move the IP/1394 spec forward at
its own pace. The cost of course are some minor duplications
in functionality.

-myron