Subject: next steps related to bridging

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 16 Dec 1998 17:16:48 -0800

Hi all,

I attended the IEEE p1394.1 Bridging meeting last week.
We discussed moving the definition of the GASP
header to the p1394.a specification. We also discussed
moving NPM election and the usage of the NETWORK_CHANNEL
register to the p1394.a specification.

-------------------GASP------------------------
No one attending the bridging meeting opposed
moving the definition of the GASP header to
the p1394.a specification. Given the cross
representation between the p1394.1 and p1394.a groups,
it is highly likely the GASP header will become part
of the p1394.a spec. The steps are for the p1394.1
chair (Dick Scheel) to submit a letter to the p1394.a
chair (Peter Johansson) requesting the GASP header
be part of the p1394.a spec, then the p1394.a spec
will be modified.

If the IP/1394 agrees to use the GASP header,
the IP/1394 spec must appropriately
support the GASP header. Specifically, the IP/1394
spec must use IANA's OUI (aka RAC) value (0x00005E)
in the GASP header, change the ARP packet format,
change the MCAP packet format, and do something
related to the signature field in the link
fragment header.

-------------------BROADCAST--------------------
The idea wrt the NETWORK_CHANNEL register and NPM,
is to create a general purpose 1394 broadcast mechanism.
This change ensures ARP and IP broadcast will cover entire
multiple-bus 1394 networks. Other protocols need a 1394
broadcast mechanism as well.

First, the IP/1394 WG must agree to the following:
1) Change the NETWORK_CHANNEL register name
to BROADCAST_CHANNEL (or some other appropriate name).
2) Change NPM name to Broadcast Channel Manager (BCM).
3) Move the usage of the BROADCAST_CHANNEL register
specified in the IP/1394 spec to the p1394.a spec.
4) Move the BCM election process to the p1394.a
Spec.

If the IP/1394 WG agrees to these steps, then the
IP/1394 Co-Chairs must submit a letter to the p1394.a
chair requesting the p1394.a spec to incorporate
the appropriate text from the IP/1394 spec. Then
the IP/1394 spec must be modified to remove the
appropriate text and add the minimal text needed
for implementers to find the BROADCAST_CHANNEL
and BCM election in the p1394.a spec.

-------------------SUMMARY------------------
The schedule for the p1394.a group is to have
rev 3 of the draft completed by Feb or March.
The IP/1394 group is only dependent on having
a revision of the draft including the desired
text. (IP/1394 has already reference a draft
version of an IEEE spec by using async stream
and NETWORK_CHANNEL.) I suspect our requested
modificatons to the p1394.a spec would be done
by the beginning of February.

On December 21st, I'll summarize the responses
to this mail and indicate the direction to be
taken by the WG. Whether we have rough
consensus or not will be determined by the
responses or lack of responses to this mail.
A lack of response will indicate a lack of
opposition.

If someone returns from the Holidays to
learn of these steps and is opposed to the
direction of the IP/1394 WG, we'll address
their concerns. Consensus through absenteeism
is not acceptable, but neither is delaying all
progress until January.

If these steps are confusing or you have opinions
about GASP or broadcast, please speak up.

Happy Holidays,

-myron
WG Co-Chair

---

From: "Wooten, David" <[email-masked]>
Date: Thu, 17 Dec 1998 09:24:48 -0600

Kaz,

I would agree with you if the IP/1394 working group had produced a standard
that had a chance of working when 1394-1394 bridges were present.  The 1394a
and 1394.1 folks are not trying to generalize the outcome of this group,
they are trying to correct the outcome of this group so that 1394a and
1394.1 and IP/1394 might actually have some chance of coexisting in the
future.  Since the solution that is being proposed seems to have been
validated by members of all three working groups, it is to be preferred over
any solution that is selected by any single one of those working groups.

As a point of historical accuracy, the IP/1394 group got the
NETWORK_CHANNELs register from the 1394a folks by asking for it.  It was not
something that the IP group had within its power to just grab.  This group
knew it needed to ask for this allocation because the 1394a group told it.
The reason for having a NETWORK_CHANNELS register comes from the invention
of asynchronous channels.  Asynchronous channels were invented by people in
the 1394a working group in order to help the IP group solve a problem with
the use of broadcast writes on 1394.  So, strictly speaking, the
NETWORK_CHANNELS register concept was not a work-product of this group.

In summary, I would advise against any isolationist attitude.  There are a
lot of interrelationships among the activities surrounding/using 1394 and
unless the groups work closely together, there is going to be chaos.  I
would advise support of what Myron is proposing.

David Wooten

> -----Original Message-----
> From: Kaz Honda [mailto:[email-masked]]
> Sent: Thursday, December 17, 1998 3:22 AM
> To: [email-masked]
> Subject: Re: next steps related to bridging
>
>
> "Hattig, Myron" <[email-masked]> wrote:
> >
> > My opinion is the IP/1394 should follow the necessary
> > steps to support GASP and move the NPM/NETWORK_CHANNELs
> > functionality to p1394.a to provide a general purpose 1394
> > broadcast mechanism.
>
> I strongly disagree. This WG was organized in summer 1997 and since
> then we've made some efforts to standardize how to send IP datagram
> over 1394. NPM/NETWORK_CHANNELs are part of our efforts and are
> invented for the purpose of IP1394. If other standardizing bodies want
> to generalize them, they can do whatever they want. But we should not
> be affected by this.
>
> If they want to generalize our outcome, all they have to do is make
> reference to our specs. Period.
>
> We've already done the interoperability test to verify the
> NPM/NETWORK_CHANNELs that we defined works well. I don't see any
> reason that p1394.a people need any modification. Nevertheless, why do
> we have to pass our control to p1394.a?  Why do we have to wait until
> p1394.a generalizes our outcome?
>
> Anyway, I don't want to delay standardizing IP/1394 spec any longer.
>
> --
> Kaz Honda <[email-masked]>
> R&D Dept., ITC                   Fone: +81-3-5448-8401
> Sony Corporation                 Phax: +81-3-5448-8977
>

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 17 Dec 1998 09:08:08 -0800

All,

I don't agree with many of David's comments, but I
also don't see any point in responding to them. The
only reason for this note is so that people don't
confuse my lack of response with agreement.

-myron

> From: Wooten, David [mailto:[email-masked]]
> Sent: Thursday, December 17, 1998 7:25 AM
> To: [email-masked]
> Subject: RE: next steps related to bridging
>
>
> Kaz,
>
> I would agree with you if the IP/1394 working group had
> produced a standard that had a chance of working when
> 1394-1394 bridges were present.  The 1394a and 1394.1 folks
> are not trying to generalize the outcome of this group, they
> are trying to correct the outcome of this group so that 1394a
> and 1394.1 and IP/1394 might actually have some chance of
> coexisting in the future.  Since the solution that is being
> proposed seems to have been validated by members of all three
> working groups, it is to be preferred over any solution that
> is selected by any single one of those working groups.
>
> NETWORK_CHANNELs register from the 1394a folks by asking for
> it.  It was not something that the IP group had within its
> power to just grab.  This group knew it needed to ask for
> this allocation because the 1394a group told it.  The reason
> for having a NETWORK_CHANNELS register comes from the
> invention of asynchronous channels.  Asynchronous channels
> were invented by people in the 1394a working group in order
> to help the IP group solve a problem with the use of
> broadcast writes on 1394.  So, strictly speaking, the
> In summary, I would advise against any isolationist attitude.
>  There are a lot of interrelationships among the activities
> surrounding/using 1394 and unless the groups work closely
> together, there is going to be chaos.  I would advise support
> of what Myron is proposing.
>
> David Wooten
>

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 17 Dec 1998 09:03:46 -0800

David,

In the past you have only expressed the opinion that the
GASP header is needed to make IP/1394 work through bridges.
Kaz's comments only relate to the NETWORK_CHANNEL usage
and NPM election. Do you now think bridges need the NETWORK_CHANNEL
usage and NPM election in the .a spec? Or do you just think it
would be useful to bridges?

-myron

---

From: "Wooten, David" <[email-masked]>
Date: Thu, 17 Dec 1998 12:04:50 -0600

As we talked about in Monterey, the NETWORK_CHANNEL would be useful for some
bridging functions.  Specifically, we need a way to do clock adjustment on
buses.  We don't want to have to allocate yet another channel when the
NETWORK_CHANNEL would suffice (we'd use the channel isochronously which
would not interfere with its asynchronous use.)

David Wooten

> From: Hattig, Myron [mailto:[email-masked]]
> Sent: Thursday, December 17, 1998 11:04 AM

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 18 Dec 1998 10:55:23 -0800

Kaz,

My expectation is the text from the IP/1394 draft
will be directly copied to the p1394.a, after all
there is one person editing both specs. ;-)

Given the cross representation among the WGs and
the consensus for keeping the usage of the
NETWORK_CHANNEL and the election of the NPM the
same as it is in the ip/1394 spec, I'm not
worried about the control issue. I'm assuming
modifications to the p1394.a spec will be open, so
all of us can monitor and provide input as we see fit.

As far as the schedule, there should be no additional
time to get NETWORK_CHANNEL/NPM in the p1394a spec
than it will take to get the GASP header in the
p1394a spec. With active participation, I think the
p1394.a spec could easily be done by February 1st. I'm
taking liberties by suggesting dates for Peter to
get work done without having knowledge his other
commitments. Peter should verify or deny whether
Feb 1 is a realistic date.

While the p1394.a spec is being updated, the
IP/1394 WG must adjust of ARP, MCAP, and signature.
We should be able to accomplish this by February 1st.

To summarize, I'm not worried about loosing control
of the NETWORK_CHANNEL/NPM definitions. The schedule
has already slipped. February is the first light at
the end of the tunnel I've seen since we've started
the bridging discussion.

If the p1394.a and ip/1394 specs get modified by Feb 1st,
then the Ip/1394 WG will take a week to do a WG last call.
Barring any objections in the WG last call, we submit the
ip/1394 spec to the IESG after the WG last call.

Does this satisfy your concerns and answer your questions?

-myron

> Sent: Friday, December 18, 1998 1:32 AM
> "Hattig, Myron" <[email-masked]> wrote:
> >
> > Kaz,
> >
> > I appreciate your comments and sentiment. I would like
> > to understand whether your concern is actually with
> > the loss of ownership or a slip in the schedule.
>
> My concern is both.
>
> If we lose the ownership(or control) of the NPM/NETWORK_CHANNEL, there
> is a chance for p1394a folks to modify it. On the other hand, the NPM
> is a foundamental element for IP1394. If the NPM is modified, IP1394
> spec must be reconsidered again to fit the modified NPM. That means
> IETF WG has to wait until p1394a is finalized.
>
> When will p1394a spec be finalized?
> When will IETF be able to submit I-D to the IESG?
>
> If we surely can submit I-D to the IESG in the very near future, no
> problem. But who knows?
>
> If p1394a folks just try to include the NPM with no modification into
> the spec, then it is okay with me because IETF WG can move forward
> independently. This does not cause any delay of schedule. In this
> sense, I don't mind if we pass the ownership/control of the
> NPM/NETWORK_CHANNEL to p1394a.
>
> As for GASP header, I don't care about it very much, because we can
> regard our current IP1394 spec as bridge-unaware spec. When
> 1394-bridge emerges to the market, we'll simply obsolete the
> current spec and create the new one. We can cross that bridge when we
> come to it. :-p
> Again, if p1394a spec will be finalized so soon, and it will not
> affect our schedule to submit I-D, I'm happy with that.
>
> --