Subject: Re: Potential New WG Charter

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 1 Jun 1999 09:34:14 -0700

Saito-san,

Can you please re-post this with instructions to make it a WG draft? This
way it will appear on the IP/1394 Charter web page. Putting the draft on the
web page is the best way to foster discussion.

Thanks,

-myron

> -----Original Message-----
> From: Takeshi Saito [mailto:[email-masked]]
> Sent: Tuesday, June 01, 1999 9:00 AM
> To: [email-masked]
> Subject: Re: Potential New WG Charter
>
>
> Phillipe-san,
>
> I am an author of "IP over isochronous 1394" draft
> (draft-saito-ip1394-mcap-ext-00.txt). I am still interested in
> IP over iso1394 issue, and we are trying to implement it.
> But it seems that not many people are interested in this issue
> for now. So I am very happy if somebody is also interested in
> this topic, and if we can discuss it.
> (I am not sure how many people are interested in IP-iso1394 topic,
> but I think the best place to discuss this is here in this WG.)
>
> Regards
>
>
> >> 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
>
> --
> Takeshi "Ken" Saito
>
> Toshiba R&D center      [email-masked]
>

---

From: Takeshi Saito <[email-masked]>
Date: Thu, 3 Jun 1999 00:06:22 +0900

Ikezaki-san

>> Dear Saito-san,
>> Do you have any plan to resolve making specification
>> on IP over Iso1392 if handled in this wg?

Yes. Do you have another idea of appropriate place to
decide IP over iso1394 spec? Or are there any activities
of IP over iso1394?

Regards.

--
Takeshi "Ken" Saito

---

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

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,

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

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

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