Subject: Potential New WG Charter

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 27 May 1999 10:28:03 -0700

Our WG charter in the IETF Web pages is outdated. Below is
the proposed charter text. Please review and comment on text. After
a few day's I'll submit the charter (with updates based on comments)
to be posted on IETF web pages.

Thanks,

-myron

Description of Working Group:

The IP/1394 WG formed in the summer of 1997 after a single BOF. Our goal is
to enable TCP/IP over IEEE 1394 in devices with a wide range of
capabilities.
Example devices are network-devices such as PCs, as well as, devices such as
cameras, VCRs, and TVs, which are not traditionally networked. The WG
expects
these IP/1394 devices to communicate with hosts across the global Internet
and within a single home Intranet.

IEEE 1394 is a family of related documents: IEEE Std 1394-1995, the only
formally approved IEEE 1394 standard, IEEE P1394a, a supplement to the
original
that contains corrections and enhancements, and IEEE P1394.1, ongoing work
to
define homogeneous 1394 to 1394 bridges. The IP/1394 WG continues a close
liaison with P1394.1 to help insure IP/1394 devices communicate through 1394
bridges. A similar liaison exists with P1394a to insure ARP, Multicast
Channel Allocation Protocol (MCAP), and IP broadcast can utilize the P1394a
broadcast channel.

The IP/1394 WG plans to deliver the following two documents:
* IPv4 over 1394 Specification. For only IPv4, this document includes:
  * Encapsulation of ARP, MCAP, IP unicast, IP multicast, and IP broadcast.
  * The ARP protocol that maps IP unicast addresses to a 64 bit 1394
address.
  * The MCAP protocol that maps IP multicast addresses to 1394 channels.
  * A mapping of IP Broadcast addresses to the P1394a broadcast channel.
  * An IEEE 1212 Unit Directory that allows dynamic loading of IP/1394
drivers.
* 1394 Extensions for DHCP

The IP/1394 WG considered work on an IPv6 over 1394 specification, a 1394
SNMP
MIB, and methods to relate 1394 services (including a 1394 isochronous
service)
to other Quality of Service (QoS) IETF work. Unfortunately, there was not
enough interest to motivate the WG to produce drafts on any of these topics.
One WG member produced an IPv6 over 1394 ID; this draft should be the
starting
point for any future IPv6 over 1394 work. The WG plans to shutdown without
producing IPv6, a MIB, or any QoS related documents.

Goals and Milestones:
Apr 98     Interoperability Test of IP unicast, IP Broadcast, ARP     - DONE
Jun 98     Interoperability Test of IP multicast use of MCAP          - DONE
Jun 99     Submit IPv4 over 1394 for publication as a Proposed Standard
Oct 99     Submit DHCP extensions for 1394 to HCP WG
Nov 99     Interoperability Test of entire IPv4 over 1394 RFC
Dec 99     Shut down working group

---

From: Peter Johansson <[email-masked]>
Date: Thu, 27 May 1999 13:56:06 EDT

In a message dated 99-05-27 13:28:26 EDT, [email-masked] writes:

<<The IP/1394 WG continues a close liaison with P1394.1 to help insure
IP/1394 devices communicate through 1394 bridges.>>

To put a fine point on it, IP/1394 WG maintains close P1394.1 liaison so that
the behaviors of devices compliant with TODAY's draft standard for IP over
1394 will not prevent the development of TOMORROW's draft standard for IP
over 1394 that permits operations across bridges.

Myron has indicated that Area Director's are unhappy with charter material
that mentions the necessity of future work without promising to deliver the
work. This is a bit of a pickle. I hope Myron will share this message with
the ADs and see if there is some slight misunderstanding.

I would suggest wording such as: "The IP/1394 WG has maintained close liason
with IEEE P1394.1 to insure that design choices by both working groups do not
preclude the eventual development of an IPv4 over 1394 specification that
enables IPv4 across bridges. However, the development of such a specification
is not within the current scope of the WG and is not contemplated at this
time."

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 27 May 1999 12:36:19 -0700

> the ADs and see if there is some slight misunderstanding.

To clarify, the ADs did not like an earlier version of the draft that read the
like the WG would deliver something, but did not state what that deliverable
was. I agree with them in that case. I don't know if they generally object to
mentioning future work, but I'll let them speak for themselves. They are on
this list so they have heard Peter's comments.

Here's my view of Peter's comments. If there is a need for future-work after
the WG shuts-down, then the a new WG would form. The comment about IPv6
in the charter gives a starting point for future-work. The "continues a close
liaison" text gives a starting point for future IP/1394-p1394.1 work.  I think
the charter is already going above and beyond its strict purpose by giving
pointers to future IPv6 and bridging work; however, this text answers questions
that people usually ask about IP/1394. IMHO, any additional text about
future-work would cause the charter to stray too far from it's strict purpose.
If I were to change the charter, I would remove all text related to future-work,
not add more text about future work.

-myron

---

From: Peter Johansson <[email-masked]>
Date: Thu, 27 May 1999 15:48:11 EDT

In a message dated 99-05-27 15:36:23 EDT, [email-masked] writes:

<<If I were to change the charter, I would remove all text related to
future-work, not add more text about future work.>>

If you restrict the choices available to people, sometimes they have to agree
with you!  :^)

If the only two choices are a) leave an inaccurate statement in the charter
that creates the false impression that operation across bridges is enabled by
today's draft standard or b) take the sentence out entirely, I will (of
course) agree with the second option.

But I still think the third choice is best: describe the fact that the
current activity of the group (liaison) is for the purpose of leaving the
door open for future work.

More than enough said on this topic...

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 27 May 1999 16:31:22 -0700

What companies can we expect to participate in interop testing
if we hold it in Nov 99? What is your confidence level? Is
there a better date?

It would be best to respond to the list, but if you want to hide this
information, you can respond to me privately with a note to not
reveal your company name.

Thanks,

-myron

> -----Original Message-----
> From: Hattig, Myron [mailto:[email-masked]]
> Sent: Thursday, May 27, 1999 10:28 AM
> To: [email-masked]
> Subject: Potential New WG Charter
>
>

---

From: Boucachard <[email-masked]>
Date: Fri, 28 May 1999 19:11:23 +0900

Myron,

Sorry to not directly comment the charter, but I remember seeing
a proposal for "IP over Isochoronous 1394" on this reflector, could you
please let me know what happened to this proposal and what is the status
regarding this WG.

Thanks

Philippe Boucachard

-----Original Message-----
From:   Hattig, Myron [SMTP:[email-masked]]
Sent:   Friday, May 28, 1999 2:28 AM
To:
Subject:        Potential New WG Charter

Thanks,

-myron

Goals and Milestones:

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 28 May 1999 08:43:57 -0700

Phillipe,

No need to apologize. Discussion like this is the reason for the text in the
charter;
hopefully people interested in these topics will speak up.

Attached are a few emails I saved on this topic. In addition to the problem
outlined in the emails, there is a fundamental problem with 1394 isoch
services -
there can only be one sender per channel - this a requirement in the IEEE
1394-1995
Std.  The reason for this is to keep all isoch traffic to less than 80% of
the 125 us
cycle time. If this 80% of 125 us is violated, then 1394 jitter boundaries
are violated
thus throwing off expected isoch delivery.

In past discussions we thought this was a problem because we thought TCP/IP
mcast
required support for multiple senders on same IP mcast addr. Here is a
solution we
have discussed in the past. This is a change in isoch usage that does not
break 1394's
timely delivery requirements but does not strictly follow the one sender per
channel
1394 rule.  The idea is to pass a token between multiple senders on a single
channel.
Only the single sender with the token will send on the isoch channel during
a single
cycle time. Different senders can send during different time cycles once
they get
the token.

As far as the emails below, they discuss modifying the MCAP data so that the
bandwidth
parameter is used.

-myron

-----
Message-ID: <[email-masked]>
From: Bernecker Herbert <[email-masked]>
To: [email-masked]
Subject: MCAP descriptor question
Date: Sun, 24 Jan 1999 23:55:13 -0700
X-Mailer: Internet Mail Service (5.5.2448.0)

Hallo IP1394ers,

I have a question about the MCAP group address descriptor format.
How i can differentiate between asynchronous and isochronous streams ?
There is only a field for the channel.
                             1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  length     |      type       |         reserved              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  expiration |    channel      |    speed      |   reserved    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                            bandwith                           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                         group_address                         |
         + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Regards.

 Herbert Bernecker

-----
Message-ID: <[email-masked]>
From: Takeshi Saito <[email-masked]>
To: [email-masked]
Subject: Re: MCAP descriptor question
Date: Mon, 25 Jan 1999 04:34:33 -0700
X-Mailer: Internet Mail Service (5.5.2448.0)

Kenji,

I am also interested in IP over 1394 isochronous channel (as you know :-).

>>> I have a question about the MCAP group address descriptor format.
>>> How i can differentiate between asynchronous and isochronous streams ?

Kenji> The original question is how to identify asynchronous or isochronous
Kenji> from an MCAP descriptor.
Kenji> We may use a 'bandwith' field.

Yes, it is already prepared :-).

But in this case, I rather prefer to define new type of MCAP,
and send it through 1394 unicast (or async write) because original
MCAP (type=1) is used for notifying channel/IP_MC_address info.

Kenji> But we are not sure whether a group_address is enough to identify
Kenji> the 'flow'. We may need
Kenji>         Sender Address,
Kenji>         Receiver Address,
Kenji>         Protocol,
Kenji>         Sender Port-number,
Kenji>         Receiver Port-number,
Kenji>         and some other information.

and the flow's direction.

Kenji> In such case, we need to define other MCAP descriptor type.

I currently consider the following format.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             length            |    reserved   |     opcode    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     length    |    type(=2)   | protocol(IPv4)| Flow ID type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   expiration  |    channel    |     speed     |D|  reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           bandwidth                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                           Flow ID                             +
   | (Sender_IP_addr, Receiver_IP_addr, Sender_port, Receiver_port)|
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D; direction ("send the flow", or "receive the flow")
Flow ID type; Flow ID format
 = (Sender_IP_addr, Receiver_IP_addr, Sender_port, Receiver_port)

I think we can also set to deliver non-IP AV stream using this
protocol extention.

Regards.

--
Takeshi "Ken" Saito

Toshiba R&D center      [email-masked]

-----
Message-ID: <[email-masked]>
From: Morihisa Momona <[email-masked]>
To: [email-masked]
Subject: Re: MCAP descriptor question
Date: Mon, 25 Jan 1999 06:35:08 -0700
X-Mailer: Internet Mail Service (5.5.2448.0)

Dear Mr. Saito

My name is Morihisa Momona.
I am a new comer to this e-mail refrector.

>Kenji,
>
>I am also interested in IP over 1394 isochronous channel (as you know :-).
>
>
>>>> I have a question about the MCAP group address descriptor format.
>>>> How i can differentiate between asynchronous and isochronous streams ?

I am also interested in using the 1394 isochronous stream for IP.

>But in this case, I rather prefer to define new type of MCAP,
>and send it through 1394 unicast (or async write) because original
>MCAP (type=1) is used for notifying channel/IP_MC_address info.

I think it is reasonable to define a new MCAP descriptor type
for this purpose.

>Kenji> In such case, we need to define other MCAP descriptor type.
>
>I currently consider the following format.
>
>
>                        1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |             length            |    reserved   |     opcode    |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |     length    |    type(=2)   | protocol(IPv4)| Flow ID type  |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   expiration  |    channel    |     speed     |D|  reserved   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                           bandwidth                           |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                                                               |
>   +                           Flow ID                             +
>   | (Sender_IP_addr, Receiver_IP_addr, Sender_port, Receiver_port)|
>   +                                                               +
>   |                                                               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>D; direction ("send the flow", or "receive the flow")
>Flow ID type; Flow ID format
> = (Sender_IP_addr, Receiver_IP_addr, Sender_port, Receiver_port)

In genelal, transport layer protocol ID is neccesary to specify the flow
in addition to the above information.

I also recommend to consider the model of int-serv and RSVP.
RSVP defines various bandwidth reservation styles, as follows.

    FF(Fixed-Filter) style:
        Bandwidth is dedicated to a single flow.
        Receiver and sender of the flow is explicitly specified in
        bandwidth reservation.

    WF(Wildcard-Filter) style:
        Multiple flows addressed to the same receiver share the bandwidth.
        Receiver is specified, however, no sender is explicitly specified.

    SE(Shared-Explicit) style:
        Multiple flows addressed to the same receiver share the bandwidth.
        Receiver and multiple sources are explicitly specified.

I think that WF and SE styles are effective for multicast applications,
such as conferencing, where multiple senders join the conference,
and transmit the data to the multicast group,
but, are not likely to transmit simultaneously.

FF style reservation is supported in your descriptor, however,
the other styles are not.
I think the several descriptors should be defined accordging to
the bandwidth reservation style.

Regards,

Morihisa MOMONA

-----
Message-ID: <[email-masked]>
From: Takeshi Saito <[email-masked]>
To: [email-masked]
Subject: Re: MCAP descriptor question
Date: Wed, 27 Jan 1999 04:20:30 -0700
X-Mailer: Internet Mail Service (5.5.2448.0)

Momona-san,

Thank you very much for your comment.

momo> I am also interested in using the 1394 isochronous stream for IP.

:-)

>> But in this case, I rather prefer to define new type of MCAP,
>> and send it through 1394 unicast (or async write) because original
>> MCAP (type=1) is used for notifying channel/IP_MC_address info.

momo> I think it is reasonable to define a new MCAP descriptor type
momo> for this purpose.

Kenji> In such case, we need to define other MCAP descriptor type.
>>
>> I currently consider the following format.
>>
>>
>> 1                   2                   3
>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |             length            |    reserved   |     opcode    |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |     length    |    type(=2)   | protocol(IPv4)| Flow ID type  |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |   expiration  |    channel    |     speed     |D|  reserved   |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |                           bandwidth                           |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |                                                               |
>> +                           Flow ID                             +
>> | (Sender_IP_addr, Receiver_IP_addr, Sender_port, Receiver_port)|
>> +                                                               +
>> |                                                               |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> D; direction ("send the flow", or "receive the flow")
>> Flow ID type; Flow ID format
>> = (Sender_IP_addr, Receiver_IP_addr, Sender_port, Receiver_port)

momo> In genelal, transport layer protocol ID is neccesary to specify the
flow
momo> in addition to the above information.

Yes, thank you very much.

One idea is that "protocol" field should be used for the purpose
(I mean "protocol" field is to identify layer 4 protocol).
In addition, "type = 2" indicates "channel allocation notice for
*IPv4* flow".

To use both "protocol" field and "flow ID type" is another idea.

momo> I also recommend to consider the model of int-serv and RSVP.

I think MCAP can live with RSVP. But I consider "just-1394-case"
first.

momo> RSVP defines various bandwidth reservation styles, as follows.

momo>     FF(Fixed-Filter) style:
momo>         Bandwidth is dedicated to a single flow.
momo>         Receiver and sender of the flow is explicitly specified in
momo>         bandwidth reservation.

momo>     WF(Wildcard-Filter) style:
momo>         Multiple flows addressed to the same receiver share the
bandwidth.
momo>         Receiver is specified, however, no sender is explicitly
specified.

momo>     SE(Shared-Explicit) style:
momo>         Multiple flows addressed to the same receiver share the
bandwidth.
momo>         Receiver and multiple sources are explicitly specified.

momo> I think that WF and SE styles are effective for multicast
applications,
momo> such as conferencing, where multiple senders join the conference,
momo> and transmit the data to the multicast group,
momo> but, are not likely to transmit simultaneously.

momo> FF style reservation is supported in your descriptor, however,
momo> the other styles are not.

I think "WF over 1394" and "SE over 1394" are almost impossible,
because 1394 channel can have only one sender.

(I think "IP Multicast over 1394 iso channel" is possible using the
proposed idea, BTW.)

momo> I think the several descriptors should be defined accordging to
momo> the bandwidth reservation style.

I don't think "several descriptors" can solve the problem.

My intention for now is that "IP flow over 1394 channel" first,
then "RSVP FF-style using MCAP".

Regards.

--
Takeshi "Ken" Saito

Toshiba R&D center      [email-masked]

-----
Message-ID: <[email-masked]>
From: Takeshi Saito <[email-masked]>
To: [email-masked]
Subject: Re: MCAP descriptor question
Date: Wed, 27 Jan 1999 19:22:18 -0700
X-Mailer: Internet Mail Service (5.5.2448.0)

IP1394ers,

Here are some more detail of IP over 1394 iso channel issues.
(This is separate issue from current IP1394/ARP/MCAP draft.)

Suppose IP flow transmission is done between node A (IP address =
ip_A) and node B (ip_B), both of which are on the same IEEE1394 bus.
Note that the direction of the IP flow could
be either "from node A to node B" or "from node B to node A".

Here we assume that the direction of the IP flows is from node A to
node B for a while, and the user (say node_A) wants to transfer the IP
flow through IEEE1394 isochronous channel with a certain QoS
capability.

   IP_node_A            Iso Resource Manager            IP_node_B

       <------------------------------------------------------->
              Session Control ( such as RTSP )

       ---------------------------->
  Allocate Channel ID(#x) & Bandwidth(X bps)

       -------------------------------------------------------->
        MCAP(type=2) (#x, IP_flow_ID, X bps, receive)

       ========================================================>
           (the specific) IP flow (on isochronous channel #x)
                      (ip_A, port_A, ip_B, port_B)

                        Figure 1. MCAP procedure
       (when both the IP flow and the control are in the same direction)

Here,

(Sender_IP_address, Sender_port, Receiver_IP_address, Receiver_port)
        = (ip_A, port_A, ip_B, port_B)

Then the node A reserves the channel ID and bandwidth, and
notifies the node B the relation between the IP flow and the
channel (and so on). To realize this, I propose new MCAP type
(type = 2).

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             length            |    reserved   |     opcode    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     length    |    type(=2)   | Flow ID type  |   protocol    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   expiration  |    channel    |     speed     |D|  reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           bandwidth                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                           Flow ID                             +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 2. MCAP packet format
      (type = 2, notification between the flow ID and the channel)

We call least 6 quadlets "IP flow descriptor". This MCAP packet is
sent as 1394 async write (unicast).

When "type" field is two, the IP flow descriptor specifies the relation
between specific IPv4 flow(s) and the 1394 isochronous channel through
which the IPv4 flow passes.

"Flow ID type" field represents the type of the flow ID format.

"protocol" field specifies the transport protocol of the flow
this packet specifies.

"channel" field specifies a allocated channel number of the
isochronous channel, where the IP flow is transmitted.

"D (direction) bit" has following meaning according to its value.

        0; Receive the IP flow
        (the MCAP message and the IPv4 flow go in the same direction)

        1; Send the IP flow
        (the MCAP message and the IPv4 flow go in the opposite direction)

"bandwidth" field specifies the bandwidth allocated for the
channel. The format of the field is as same as grammar of the
bandwidth available register on IEEE1394-1995.

"Flow ID type" specifies the type of flow ID. In this section of
this draft, the only value of the "flow ID type" is two, which
represents (Sender_IP_address, Sender_Port, Receiver_IP_address,
Receiver_Port) is specified.

Flow ID type=2;
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Source IP address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Destination IP address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Source Port                 |    Destination Port           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3. Format of flow ID (Type=2)

I also think that this procedure is available when we want to notify
to send (or receive) IEC61883 AV flows by IP applications using
another new MCAP type. Also note that we can extend this to IPv6 flow.

As I mentioned before, RSVP can use this for link layer reservation
and notification.

I plan to submit the related draft soon if possible.

Regards.

--
Takeshi "Ken" Saito

Toshiba R&D center      [email-masked]

---

From: Boucachard <[email-masked]>
Date: Mon, 31 May 1999 14:49:53 +0900

Myron,

Thank you for the material and the explaination on particular problem
for IP Multicast over Isochornous 1394, this interesting problem seems
to be a source for ideas of solution being more or less powerfull or simple,
like for example how to treat the need of some station to be able to send
more than others, how to deal with fairness at the token distribution algorithm
level, etc...

But what I do not understand is where these discussions and the general
domain of IP over Isochronous 1394 are being treated and
written down to specifications, since now "IP V4 over 1394"
has passed the WG last call, will that be discussed in another WG?
What is the common opinion?

best regards

Philippe Boucachard

==================================================
Philippe Boucachard
 International Standard Planning Department
 International Standard Planning Division
 International Standard Planning Center
 Canon Inc
 30-2 Shimomaruko 3-Chome Ohta-ku Tokyo 146-8501, Japan
 Email: [email-masked]
 Tel +81-3-3758-2111
 Fax +81-3-5482-5957
==================================================

-----Original Message-----
From:   Hattig, Myron [SMTP:[email-masked]]
Sent:   Saturday, May 29, 1999 12:44 AM
To:     [email-masked]
Subject:        Re: Potential New WG Charter

Phillipe,

-myron

-----

Hallo IP1394ers,

Regards.

 Herbert Bernecker

-----

Kenji,

                        1                   2                   3

Regards.

--
Takeshi "Ken" Saito

-----

Dear Mr. Saito

    FF(Fixed-Filter) style:

Regards,

Morihisa MOMONA

-----

Momona-san,

:-)

Regards.

--
Takeshi "Ken" Saito

-----

IP1394ers,

                        Figure 1. MCAP procedure

Here,

                        1                   2                   3

        0; Receive the IP flow

        1; Send the IP flow

Flow ID type=2;
                        1                   2                   3

Regards.

--
Takeshi "Ken" Saito