Subject: MCAP descriptor question

From: Bernecker Herbert <[email-masked]>
Date: Mon, 25 Jan 1999 07:55:13 +0100

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

---

From: Takeshi Saito <[email-masked]>
Date: Mon, 25 Jan 1999 20:34:33 +0900

Kenji,

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

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

---

From: Morihisa Momona <[email-masked]>
Date: Mon, 25 Jan 1999 22:35:08 +0900

Dear Mr. Saito

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

>>>> How i can differentiate between asynchronous and isochronous streams ?

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

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

>I currently consider the following format.

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

---

From: Takeshi Saito <[email-masked]>
Date: Wed, 27 Jan 1999 20:20:30 +0900

Momona-san,

Thank you very much for your comment.

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

:-)

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

>> I currently consider the following format.

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

---

From: Takeshi Saito <[email-masked]>
Date: Thu, 28 Jan 1999 11:22:18 +0900

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
   |     length    |    type(=2)   | Flow ID type  |   protocol    |

                      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

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 29 Jan 1999 13:06:20 -0800

Ken,

It's great to see there is interest in this and people are thinking
about it. The level of interest determines whether or not we can
justify continuing the life of this WG after IPv4 1394, DHCP
extensions for 1394, and 1394 SNMP MIB are delivered.

> (This is separate issue from current IP1394/ARP/MCAP draft.)

-myron