Subject: Re: ARP, MCAP, signature

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 12 Jan 1999 10:22:17 -0800

Kenji,

The problem with having the signature reserved is that it will
always be zero, thus it does not perform the function it is
intended for. The intended function is to differentiate between
two link fragments that have identical datagram labels,
offsets, bufsizes, etc.

I think we should keep the signature field as it is currently
defined. If this poses a problem later when bus bridges
re-use a bus id number on multiple buses, then we can solve the
problem by defining a new way to guarantee 1394 network wide
unique signature values.

-myron

> -----Original Message-----
> From: Kenji Fujisawa [mailto:[email-masked]]
> Sent: Wednesday, December 23, 1998 5:56 PM
> To: [email-masked]
> Subject: Re: ARP, MCAP, signature
>
>
> >Signature -----------------------------
>
> >We should define the signature as:
> >> signature: A 16 bit value unique among all nodes on the
> 1394 bus. In
> >> single 1394 bus networks, the signature is the most significant
> >> 16-bits of the sender's NODE_ID register. In multiple-bus
> 1394 networks,
> >> the use of the sender's node ID should be re-examined to maintain
> >> the requirement that the signature values be unique among all nodes
> >> connected in the 1394 network. Because the signature may not always
> >> be the sender's node ID, using the signature for any
> purpose other than
> >> link fragment reassembly is fraught with error and is strongly
> >>discouraged.
>
> I can live with this, but I prefer to change this 16-bit field as
> a 'reserved'.
>
> Kenji Fujisawa
>

---

From: Venkata Tanikella <[email-masked]>
Date: Tue, 12 Jan 1999 12:16:39 -0800

Myron,

Pl find my responses embedded.

>problem by defining a new way to guarantee 1394 network wide

I am attaching an earlier e-mail posted to the thread wrt signature.

Kenji Fujisawa wrote:
> 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

So, for my understanding, we are still going to have a signature field for
reassembly purposes. And it is very likely to pose a problem in the bridged
environment as said above. Then shouldn't we consider resolving the signature
issue in the bridged environment  now itself. My concern is if we cannot
rely on the BusId generating a unique number seem tobe scary; For instance
taking 16 bits from EUI-64 won't produce unique numbers, so I am worried at
the possibility of increasing the the number of signature bits to tackle
bridged environment. Or do we have to look at Gasp header ?

-Venkat