Subject: Re: ARP, MCAP, signature

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 12 Jan 1999 15:21:58 -0800

Venkata,

Questions are answered below.

> I am relatively uneducated on GASP; Could you please give
> some pointers as
> to how I can get information on it or forward any information
> that you have ?

The first definition of the GASP header was presented on
this list in the document:
http://www.ietf.org/internet-drafts/draft-johansson-ip1394-asynch-streams-00
.txt

The GASP header was later discussed in the December p1394.1 (Bridging) meeting,
where the fields of the header changed from the original proposal to the
below three fields:
- 16 bit source node ID
- 24 bit OUI value
- 24 bit OUI dependent value
These fields are basically the same as the original proposal. In addition
a value for the TAG field in the tcode = 0xA packet header is defined to
identify GASP headers.

The 16 bit source id in the GASP header allows the bridge
to identify the source node id to do some magic that allows
the recipient of the async stream to appropriately respond
back to the source. If the source node id is embedded in a packet
the bridge must know about a particular protocol. The GASP
solution with TAG value provide the bridge well known steps to
identify the source node id.

The IP/1394 WG has already agreed to ;-) always use the GASP
header in all IP/1394 asynchronous streams. This
applies to IP broadcast, IP multicast, ARP and MCAP packets. If for
some strange reason IP unicast packets use async streams, they too
must use GASP.

> Looking at GASP headers, and taking the nodeid from there
> looks fine to me;

We cannot simply remove the signature field in the link
fragment header because IP unicast over asynchronous WRITE does not
use the GASP header.  However, we can use the source node
id from the GASP header and ignore the signature in the link
frag header when packets pass over async streams. When
passing over asyc write packets, signature can be used as defined.

> I am presuming GASP is only relevant in a bridged environment;
> If that is true in a non-bridged environment we still need a
> signature and it has to be valid isn't it ?

Generally, we want no knowledge of whether we are in a bridged
environment or not, thus GASP is sort of relevant in non-bridged
networks.

-myron

---

From: Venkata Tanikella <[email-masked]>
Date: Tue, 12 Jan 1999 17:01:49 -0800

Myron,
        Thanks for the info on GASP, I am better off now.

>environment or not, thus GASP is sort of relevant in non-bridged

OK then GASP is relevant only for (Async) stream traffic, whether it is
bridged or non-bridge environment.

And Yes generally we want no knowledge of whether we are in a bridged
environment or not; This is desirable for signature also; But if we leave
"signature" as it is defined now, we may not meet this objective, as
explained below.

Let us come to signature in the case of fragmented traffic using Async Writes.
I am quoting from an earlier e-mail today :

>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.

I am also quoting the new proposed defintion for "signature"

> 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.

That essentially means that at this point of time we do not want to define
the "signature" contents when sending a fragment to a remote bus node using
Async Write.
 And Given that
        - "signature" is the most 16 bits of the NODE_ID register when sending a
fragment to a node in a single bus environment and
        - the uncertainity at this time that NODE_ID register may not reflect the
BUSID in a bridged environment,

we would potentially end up using a diffrent defintion for signature when
we move to multiple bus environment. (And we got to be aware that we are in
bridged or nonbridged environment). Having diffrent mechanisms would lead
to chaos from a receipeint's perspective as explained below:

Given that the first point of distinction in fragmentation and reassembly is
the "signature", (With the second as "dgl"), and with the current draft
assumption that we don't have to look into link level headers for
reassembly, odds are high that the fragments one from a local node, and one
from a remote node (Each deploying diffrent mechanisms for filling
"signature") generate the same signature. In the true spirit of "signature"
this is not so good;

I therefore propose that we drop the "signature" altogether  (or make it
reserved with all zeros), and instead always get the link level "source
node Id" as the first point of distinction in fragmentation and reassembly.
In essence this is like taking the GASP route in the case of Async Streams,
and has the same benifits that I am listing here again

        - In a bridged environment bridges would automatically change the
          source node Id approprately;

        - Get sheilded from remote bus resets and we would be better off
          fragmentation and reassembly wise in terms of packet dropping;

There were objections that one does not want to look at link level headers,
but given the benifits, I feel it is worth it. [ I also could not see how
a unique id could be generated without using either of "1394 Node Id" or
"EUI-64", or an "Ip address" (which is not preffered being a higher layer
entity?) ;  Node Id Register won't work with legacy problems;  EUI-64 or
Ipaddress need more bits; ]

>-myron

regards,
Venkat