Subject: Bridges and TCP/IP

From: "Michael D. Johas Teener" <[email-masked]>
Date: Mon, 12 Oct 1998 11:15:20 -1000

There seem to be some very strong statements going back and forth on the
relationship between bridges and the IP1394 effort. Can we please calm down
a bit on this. Let's look at the way the market exists and is developing
and see if there is a reasonable way to proceed.

1) It is understood that the internet protocols are the standard (and will
continue to be the standard for wide area networking). Indeed, in many
environments it is also the standard for local areas (once things like
NetBIOS, IPX, AppleTalk, etc fade away, the IETF protocols will become
pervasive).

2) The CE people are *not* going to use TCP/IP (much less the higher layer
protocols) for their camcorders, stereos, CD players, etc. I'm not going to
justify this ... it is, however, a fact and one that I deal with daily.
They do, however, feel like they can use the AV/C protocols used in 1394,
and have a vast number of products already shipping. Given the relative
immaturity of the 1394 market (first ship only 3 years ago), the
penetration is remarkable. The estimates by the CE companies show over 100
million units shipped in the year 2001. So ... we have to deal with the IEC
61883 protocols as well. Those who advocate these protocols are quite aware
that they *must* change their protocols to support bridges.

3) The PC people want to use 1394 for disks and printers ... *low cost*
printers. Disks use yet another protocol, called SBP-2, and the printer
guys are piggybacking on that protocol (if you want to argue about it, talk
to Microsoft, not me). This is another fact. Once again, the SBP-2 people
know that there will be some kind of SBP-3 to support bridges.

4) The CE digital photography people want yet another protocol, DPP,
designed for direct connection between cameras and printers. This allows a
generic camera to drive a generic printer. I believe this will be shipping
in products as well, sometime next year. I think DPP will also need to
change to support bridges.

This means we have a number of protocols we *must* deal with, without
prejudice, if possible. On top of all this, the expectation is that a
1394-1394 bridge must be inexpensively implemented (a single IC, I have a
personal feeling that a two portal S100/S100beta bridge -including phys-
must cost less than $10 in mass production).

I think this means that we cannot assume a 1394 bridge is very smart. It
*can* translate addresses to a certain extent as long as the location of
the address is trivial to determine and the table management can be done
slowly (the virtual IDs concept, as well as setting up the remapping of
isoch channel numbers can be done by some cheap, slow processor ... or even
remotely from the bridge itself).

Given all this, I still believe that a generic 1394-1394 bridge can (must)
support IP1394, and also believe that IP1394 can (must) be bridge aware. I
don't think the IP1394 people can ask for router functionality in a bridge
*much* more that must already be done to support *bridge aware* versions of
AV/C, SBP-2, and DPP. Similarly, the bridging people are probably willing
to accommodate the needs of IP1394, as long as the requirements are not too
onerous (note that Dave Wooten already said that he expects the 1394.1
people to support some kind of packet-specific remapping of address fields,
if that is needed).

So. Can we just make progress and stop complaining about each others
biases, procedures, and natural and predictable cross-ignorance. Let's just
try to educate each other, and be open to different ideas while that
process is under way.
========================================================================
Michael D. Johas Teener, Chief Technical Officer, Zayante, Inc.
269 Mt. Hermon Rd. #201, Scotts Valley, CA 95066-4000, USA
voice: +1-831-461-4901  fax: +1-831-461-1394  page: [email-masked]
email: [email-masked] PGP IDs: RSA 0x177754E1, D-H/DSS 0x3179D202
======================== http://www.zayante.com ========================

---

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 12 Oct 1998 17:45:15 -0700

Mike,

Thanks for the comments for calmness.  I think harsh words have
decreased in the last week or so. I hope we can continue this trend to
focus on our next steps.

I agree that IP will NOT be the protocol of choice for camcorders, VCRs,
TVs,
hardrives, scanners, etc.

I also agree that we will have need to make some modifications to the
IP/1394 spec
so IP devices work with 1394 bridges.

The problem is how do we move forward from here. We have 3 possibilities
(that I'm aware of):
1) Include a clause suggested by Peter, move forward with the spec
2) Don't include the clause suggested by Peter, move forward with the spec
3) Postpone moving forward with the spec until we better understand the
relationship with
bridges and IP

We have already acknowledged that all three options will require changes to
the IP spec
in order for IP devices to work with bridges.

-myron

---

From: Richard Humpleman - SISA <[email-masked]>
Date: Thu, 15 Oct 1998 14:16:01 -0700

Only the brave (or foolish) make predictions as below (Myron and
Michael).

So let me be brave (or foolish)...
I think that 1394 technology won't graduate to 'Home Network' status
from 'MM Peripheral Interface' status, without: Internet Protocol
support and, of course, Multiple room support at a Consumer price level
(~$25 for a bridge, ~$15 for a NIC and ~$0 for a B repeater).

Light-hearted comment from
Richard Humpleman,
Samsung Information Systems America,
San Jose,
CA 95134,
USA.
Tel: 408-544-5490.

-----Original Message-----
From: Hattig, Myron [mailto:[email-masked]]
Sent: Monday, October 12, 1998 5:45 PM
To: [email-masked]
Subject: Re: Bridges and TCP/IP

Mike,

The problem is how do we move forward from here. We have 3 possibilities
(that I'm aware of):
1) Include a clause suggested by Peter, move forward with the spec
2) Don't include the clause suggested by Peter, move forward with the
spec
3) Postpone moving forward with the spec until we better understand the
relationship with
bridges and IP

We have already acknowledged that all three options will require changes
to
the IP spec
in order for IP devices to work with bridges.

-myron

---------------
There seem to be some very strong statements going back and forth on the
relationship between bridges and the IP1394 effort. Can we please calm
down
a bit on this. Let's look at the way the market exists and is developing
and see if there is a reasonable way to proceed.

1) It is understood that the internet protocols are the standard (and
will
continue to be the standard for wide area networking). Indeed, in many
environments it is also the standard for local areas (once things like
NetBIOS, IPX, AppleTalk, etc fade away, the IETF protocols will become
pervasive).

2) The CE people are *not* going to use TCP/IP (much less the higher
layer
protocols) for their camcorders, stereos, CD players, etc. I'm not going
to
justify this ... it is, however, a fact and one that I deal with daily.
They do, however, feel like they can use the AV/C protocols used in
1394,
and have a vast number of products already shipping. Given the relative
immaturity of the 1394 market (first ship only 3 years ago), the
penetration is remarkable. The estimates by the CE companies show over
100
million units shipped in the year 2001. So ... we have to deal with the
IEC
61883 protocols as well. Those who advocate these protocols are quite
aware
that they *must* change their protocols to support bridges.

3) The PC people want to use 1394 for disks and printers ... *low cost*
printers. Disks use yet another protocol, called SBP-2, and the printer
guys are piggybacking on that protocol (if you want to argue about it,
talk
to Microsoft, not me). This is another fact. Once again, the SBP-2
people
know that there will be some kind of SBP-3 to support bridges.

4) The CE digital photography people want yet another protocol, DPP,
designed for direct connection between cameras and printers. This allows
a
generic camera to drive a generic printer. I believe this will be
shipping
in products as well, sometime next year. I think DPP will also need to
change to support bridges.

1394-1394 bridge must be inexpensively implemented (a single IC, I have
a

isoch channel numbers can be done by some cheap, slow processor ... or
even

Given all this, I still believe that a generic 1394-1394 bridge can
(must)
support IP1394, and also believe that IP1394 can (must) be bridge aware.
I
don't think the IP1394 people can ask for router functionality in a
bridge
*much* more that must already be done to support *bridge aware* versions
of
AV/C, SBP-2, and DPP. Similarly, the bridging people are probably
willing
to accommodate the needs of IP1394, as long as the requirements are not
too
onerous (note that Dave Wooten already said that he expects the 1394.1
people to support some kind of packet-specific remapping of address
fields,
if that is needed).

biases, procedures, and natural and predictable cross-ignorance. Let's
just

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 15 Oct 1998 15:42:37 -0700

[WG Co-Chair Hats ON]

Hello,

There is WG rough consensus that the draft should not be held up or
postponed until the p1394.1 WG and IP/1394 WG have a clear understanding
of how both types of devices will peacefully co-exist. Some work will
very likely be required in the future to modify the IP/1394 Spec to
support 1394 bridges. Also, there may be small clause(s) added to
the next revision(s) of the IP/1394 Spec that will ease this future
effort.

Note the p1394.1 group is meeting as this mail is being sent, so I
suspect responses from the folks supporting the postponement of the
IP/1394 Spec will be posted over the next week or so.

We are now considering the matter of postponing the IP/1394 Spec to
better support 1394 bridges closed.

Tony and Myron

[WG Co-Chair Hats OFF]

---

From: "Wooten, David" <[email-masked]>
Date: Fri, 16 Oct 1998 02:45:24 -0500

I strenuously object to your determination that "the matter of postponing
the IP/1394 Spec to better support 1394 bridges closed."  You make not that
the 1394.1 group was currently meeting and that they were looking at this
issue and that you would expect to hear from the members of that group when
the meeting had reached some conclusion.  Then you preemptively decide to
close the issue that the 1394.1 group was going to comment on.  This is not
appropriate behavior.  Perhaps the 1394.1 group should form its own task
group to define IP over 1394 and declare the work being done by the group
that you chair to be irrelevant?

David Wooten

-----Original Message-----
From:   Hattig, Myron [SMTP:[email-masked]]
Sent:   Thursday, October 15, 1998 5:43 PM
To:     [email-masked]
Subject:        Re: Bridges and TCP/IP

[WG Co-Chair Hats ON]

Hello,

Tony and Myron

[WG Co-Chair Hats OFF]

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 16 Oct 1998 12:08:32 -0700

David,

Here are some comments to help ensure the below responses are clear.
I, and many other IP/1394 WG members, are in strong favor of bridging WG
members and IP WG members working together through the issues.

This mail thread only addresses the issue of postponing the IP/1394
spec while the bridging work firms-up. Maybe we are having a disconnect
on the meaning of "postponing". By "Postponing", I meant the IP/1394
spec does not advance through the IETF Standardization process until
the bridging work is complete enough to know exactly how IP and bridges
will co-exists.

"Postponing" does not mean we will not add additional clauses to the
current draft to fix whatever issues we know about now or before
the IP/1394 spec is at a stage in the IETF standardization process in
which it is harder to change. The comment from my original mail:
> Also, there may be small clause(s) added to
was to support any changes required by known issues.

More responses below.

Wooten, David wrote:
> the meeting had reached some conclusion.

Note my comment about still adding clause(s)to support bridges.

> Then you preemptively decide to
> close the issue that the 1394.1 group was going to comment on.

We only closed the issue on indefinitely postponing the IP/1394
Spec while we wait for the bridging work to firm up. The door
remains open to solve problems when there is hope of solving
them. If first-step recommendations come back from the bridging
working group that gain support of the IP/1394 WG members then
we will change the IP/1394 spec. A past indication of this is
our dialogue about the Peter's proposed change related to help
ARP work with bridges. Peter's suggestion was not being strongly
opposed by anyone.

> This is not appropriate behavior.
> Perhaps the 1394.1 group should form its own task

I'll follow Mike Teener's suggestion and stay away from this type of
dialogue.
I'm really trying to work with the bridging group as best I can, while doing

what's best for the IP/1394 working group. I hope to be a participant in the

bridging WG soon to further both bridging and IP efforts while avoiding this

type of dialogue.

Also, the determination to close the issue was not made solely by myself nor

lightly. I asked the opinion of several WG members and discussed this with
the Tony.  For the single issue that was addressed by this email "postponing
the IP/1394 spec", there was neither support from the individuals polled
nor support in responses on the reflector. Based on the email traffic
alone we have rough consensus as defined by the IETF. I polled the
individuals to make sure I was not misinterpreting the group. Again, this
does
not mean that the two WGs should not work together, it just means IP/1394
cannot wait indefinitely for the bridging WG to finish.

Best regards,

-myron

---

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 19 Oct 1998 12:49:58 -0700

> From: Wooten, David [mailto:[email-masked]]
> Sent: Sunday, October 18, 1998 11:33 AM
>
> The problem is not that
> 1394.1 might want to use persistent node ID's (a.k.a.,
> virtual node ID's)
> but that we have no way of preventing ARP packets with an
> 0x3FF bus number
> from getting off the local bus.  Obviously, a bus number of
> 0x3FF is not
> useful as an address for a node that might be on another bus
> and can/will
> actually cause problems in identifying nodes (multiple nodes
> will seem to have the same address.)

The general IP problem (on single bus or multi-bus networks) is
where does the ARP source_unique_node_Id come from. Currently
it comes for the node_id register.

A solution suggested by someone on this list in the past was to
add a persistent or virutal node_id register, then use the
following algorithm.

If (persistent_node_id != INIT_VALUE)
{
    ArpSourceUniqueNodeID = persistent_node_id_register;
}
else
{
    ArpSourceUniqueNodeID = node_id_register;
}

I think this solves the problem of future devices that support a
persistent_node_id_register.

The additional suggested requirement to support bridges is that IP
devices ignore ARP packets with 3FF. This is not feasible because
most buses in operation today use a value of 3FF in their node_id
registers. A clause to ignore ARP packets with 3FF would break IP
on most buses in operation today.

If the bridging WG can define a specific 10 bit bus ID value
(e.g. 0x3FE, 0x0, 0x1) to always be the 10 most significant bits
in the node_ids of all nodes on all buses when a bridge is present,
the IP/1394 Spec can state that all ARP packets with this special
10 bit value (e.g. 0x3FE, 0x0, 0x1) in the source_unique_node_id
will be ignored.

Combining the clause in the IP/1394 spec to ignore ARP packets
with the special bus id value and the persistent_node_id_register
solves problems with:
- legacy devices not connected by bridges
- new devices not connected by bridges
- communication between new devices and legacy devices not
  connected by bridges
- new devices connected by bridges

Not supported are:
- legacy device connected by bridges
- communication between new devices and legacy devices
  connected by bridges

Legacy IP devices will never communicate with any other IP devices
when a bridge is present because the bridge will set the special
value to the node_id register to the legacy device, the legacy
device will copy its node_id register to the ARP
source_unique_node_Id field in the ARP packet, then all devices
will ignore those ARP packets because the IP/1394 spec said to do so.

I don't see any way to support these final two cases given our current
constraints.

-myron

---

From: "Wooten, David" <[email-masked]>
Date: Mon, 19 Oct 1998 15:29:10 -0500

Myron,

Replies below.

David Wooten

-----Original Message-----
From:   Hattig, Myron [SMTP:[email-masked]]
Sent:   Monday, October 19, 1998 2:50 PM
To:     Wooten, David; [email-masked]'
Subject:        RE: Bridges and TCP/IP

<<DRW: This is only a possibility with B devices that might support
persistent node ID's.  It does not address the issue that 1394-1995 and
1394a devices (even the bridge aware ones) most likely will not have a
persistent_node_id_register.  Other problem is that if a device gets it's
virtual ID from a bridge and uses that in an ARP, then legacy devices on the
local bus will not be able to respond.>>

<<DRW; I can't see why it helps for the source or destination of an ARP
packet would benefit from knowing that a bridge is present.  This algorithm
seems to reverse the problem that we have with the bus number being 0x3FF in
that, instead of a device on a remote bus sending a response to the wrong
source, we have the problem that a device on the local bus that has a
matching address will not respond.

Also, what kind of constraint does this place on IP after a bus reset.  In
other words, how long do nodes wait to see if their node_ids register is
going to be set?>>

Combining the clause in the IP/1394 spec to ignore ARP packets
with the special bus id value and the persistent_node_id_register
solves problems with:
-       legacy devices not connected by bridges
        <<DRW: didn't know that there was a problem to solve here.>>

-       new devices not connected by bridges
<<DRW; sure, as long as you don't want them to talk to legacy devices.>>

- communication between new devices and legacy devices not
  connected by bridges
<<DRW:  How's that?  Don't you mean "when no bridge is present.>>

Not supported are:

<<DRW: why did you list this as one of the cases that your solution fixes?>>

<<DRW: Given that we expect to have bridges, and we expect to have new
devices, why the heck would we deploy stuff that we know is going to become
obsolete when we have it.  You know

-myron

---

From: "Wooten, David" <[email-masked]>
Date: Mon, 19 Oct 1998 15:10:35 -0500

Tony,

My sentences were not contradictory.  I expect that 1394.1 to have a lot of
work to do after it reaches agreement with the IP on 1394 group on how to
de-couple the work.

I have no compunction about invalidating work that busted.  Until someone
identifies a future path for IP over bridges, the existing spec is broken
and should not be deployed.

David Wooten

-----Original Message-----
From:   Tony Li [SMTP:[email-masked]]
Sent:   Monday, October 19, 1998 2:57 PM
To:     Wooten, David
Cc:     [email-masked]
Subject:        Re: Bridges and TCP/IP

[email-masked] (Wooten, David) writes:

> I'm not suggesting that the IP/1394 WG members postpone their spec until
> 1394.1 determines how to do bridging.  I am suggesting that the IP/1394 WG
> and the 1394.1 working groups arrive at a solution to the current ARP
> problem that will allow both groups to go about their business, largely
> independently.

David,

Your two sentences are contradictory.  If we make changes to ARP at this
point, not only will it postpone the spec, but it will also invalidate the
existing implementations.

Further, fixing ARP is only one small fraction of the changes necessary to
operate across a bridge.  Please see my previous comment about MCAP.

Regards,
Tony

---

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 20 Oct 1998 13:36:30 -0700

David,

> persistent node ID's.

Obviously we are talking about future devices. That may be .b devices,
it may be devices specifically build to work with bridges.

> It does not address the issue that
> 1394-1995 and

Will devices have some idea what their perisitent node Id is? If
so replace register with that variable, data structure, cache, or
whatever its called.

> Other problem is that if a
> device gets it's

At one point you said a bridge could translate virtual node IDs
to physical node ID even when the source and destination of the
packet are on the same bus. Is this still true?

> packet would benefit from knowing that a bridge is present.

The point of the algorithm is not to know whether there is a
bridge present or not. The point of the algorithm is to provide
the device the capability by which it can determine what value
it should use in protocols the require embedding a node id in
protocols so other devices can later direct a 1394 packet back
to the original device. In TCP/IP, we know this is a problem with
ARP, MCAP, DHCP. In SBP-2, I think this is a problem with
login_owner_ids and address pointers. Are there similar
problems with other protocols?

> This algorithm
> source, we have the problem that a device on the local bus that
> has a matching address will not respond.

I don't understand this point. Why would it not respond?

> other words, how long do nodes wait to see if their node_ids
> register is going to be set?>>

TCP/IP services are recover from 1-2 second lapses. The TCP/IP stack
could delay a period of time after a bus rest before being active. If
the OS is dynamically loading drivers and enumerating the bus before
the TCP/IP stack is available anyway, I doubt any additional delays
would be noticed.

>         <<DRW: didn't know that there was a problem to solve here.>>

I'm listing all cases to make sure nothing gets broke as with the case
of IP devices ignoring ARP packets with 3FF.

> <<DRW:  How's that?  Don't you mean "when no bridge is present.>>

Yes, when bridge is present.

My response was triggered by your previous comment of:

> Obviously, a bus number of 0x3FF is not useful as an
> address for a node that might be on another bus and
> can/will actually cause problems in identifying nodes
> (multiple nodes will seem to have the same address.)

I've provided a suggestion that does not solve enough of
the problems to be useful, but hopefully it has provoked
some additional thoughts. Also, I hope it is realized that
this is not just an ARP problem or even just a TCP/IP
problem with MCAP and DHCP. It is also not a problem that
a bridge can solve by itself.

The problem must be solved in the end node whenever the
end node must embed a node ID into a protocol with the
purpose of having other devices communicate back to
the end node with that node ID. It appears this is a
problem for the login_owner_ids in SPB-2. I strongly
suspect it is a problem in other protocols as well.
Do people agree?

Are there other proposals to solve this problem?

-myron