Subject: Re: ARP, MCAP, signature

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

Venkata,

> There were objections that one does not want to look at link
> level headers, but given the benefits, I feel it is worth it.

I don't mind throwing architectural purity out the window,
but I'm not sure extracting the source id from the 1394 async
write packet solves the problem because I'm not sure the
bridge will ensure the 10 bit bus ids it generates are
unique across the entire 1394 network.

For now we would not be functionally worse off, just architecturally,
by extracting the source node ID from the 1394 async write packet
header.

> [ 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; ]

The only option I see, that I really hate, is to put the
entire EUI-64 in the link frag header. Yuk!! Adding 48 bits
to link frag headers is ridiculous given the concerns
we had about the current 64 bits of link fragment header.

-myron

---

From: Kenji Fujisawa <[email-masked]>
Date: Wed, 13 Jan 1999 11:10:37 +0900

>unique across the entire 1394 network.

The source nodeID MUST be unique because it is used to return
a write response packet.

Kenji Fujisawa

---

From: Venkata Tanikella <[email-masked]>
Date: Tue, 12 Jan 1999 18:09:43 -0800

Myron,
        My response embedded.
>unique across the entire 1394 network.

I think bridge has to. Isn't that what is talked about in the "GASP".
If bridge doesn't ensure that in the GASP, how are we thinking that it works
with GASP (Where we said that we take the source node Id of the "GASP" header
as the signature.).

(Let us say Bridge folks need not use the BusNo; They may come up with some
virtual BusId Number who knows, but they shall sure ensure that this 16 bit
node Id is unique across the connected Buses; And sure shall they use the
same mechanism whether in GASP headers or in Async Write headers)

Do you agree with that ? Or am I missing something here ?

>we had about the current 64 bits of link fragment header.

me too feel the same; But I see the link header as a viable option; We can
even do way with Signature altogether; Save another 16bits.

>-myron
regards,
Venkat

---

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

>The source nodeID MUST be unique because it is used to return

Yes that's a valid point; So why can't we take the source node Id from
the link header as the first point of distinction (The current "signature")
in our fragmentation and reassembly.

(Also the earlier objections regarding the dependenc on link level APIs to
provide info was more so related to the packet length; I can't imagine anyone
providing an API to notify an incoming indication without providing the source
node Id. This has to be done to be able to send a reponse back; IF there are
indeed some creative guys out there let them rethink about it; )

>Kenji Fujisawa
-Venkat

---

From: Kenji Fujisawa <[email-masked]>
Date: Wed, 13 Jan 1999 11:38:03 +0900

>in our fragmentation and reassembly.

As I wrote before, it was for Async Streams.
But now, we have src_ID in a GASP header.

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

Kenji Fujisawa

---

From: Venkata Tanikella <[email-masked]>
Date: Tue, 12 Jan 1999 18:44:55 -0800

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

Yes this is what my intent too;

If (async) streams get source Id from Gasp header;
If Async Write, We SHOULD get it from Link Headers (from Link APIs);

I missed Kenji's point earlier.

regards,
Venkat

---

From: Myron Hattig <[email-masked]>
Date: Wed, 13 Jan 1999 00:11:30 -0800

> The source nodeID MUST be unique because it is used to return

It seems this would be required, but I would like to hear from
some of the bridging folks instead of just assuming this to be
true.

-myron

---

From: Myron Hattig <[email-masked]>
Date: Wed, 13 Jan 1999 00:19:21 -0800

> indeed some creative guys out there let them rethink about it; )

I don't disagree with the direction this thread is going, but I do
disagree with some of the comments here.

An API only need to provide the payload of the 1394 packet and the
length of the payload. Any 1394 packet header information such as
tcode, priority, 48 bit offset, TAG value, or source node id is not
needed by most applications. Does a receive Ethernet packet API pass
the source Ethernet or EtherType address up to the IP layer receive
function? I don't think so. The same is true for receiving 1394
packets.

---

From: Myron Hattig <[email-masked]>
Date: Wed, 13 Jan 1999 00:21:06 -0800

> If Async Write, We SHOULD get it from Link Headers (from Link APIs);

Does anyone know if getting source ID from async write packet is
a problem for current 1394 APIs in use?

Thanks,

-myron

---

From: Sivananda Ramnath <[email-masked]>
Date: Wed, 13 Jan 1999 14:42:44 +0530

Hello,

> function? I don't think so. The same is true for receiving 1394

   Well, while it is not necessary fro an API to do so, it is usally very useful
   to pass on all the link headers as well since it is not possible for the API
   provider to predict all the info that will be required by the API user. Pretty
   much all the APIs that I have seen have passed this info up, on all
   Microsoft platforms for eg, the entire header is usally available.

   The lower layer API that we are implementing also passes all 1394 headers
   upward, so I think it is reasonable to expect that Source Node Id will be
   availble to higher layers.

Sivanand
([email-masked])