[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet-Draft                                             Takeshi Saito
<draft-ietf-ip1394-ip-over-iso1394-00.txt>           Yoshiaki Takabatake
Expires: March 2000                                      Mikio Hashimoto
                                                       Kei-ichi Teramoto
                                                    Corporate R&D Center
                                                            Toshiba Corp
                                                          September 1999

                         "IP over iso1394" and
          "AV over iso1394" controlled by an extension of MCAP.

Status of this memo

     This document is an Internet-Draft and is in full conformance
     with all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as
     Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as
     "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Abstract

    IEEE1394 bus is a link layer network with isochronous transfer mode
    capability.  Therefore it is quite natural that there appears
    following demands.  (1)Transmit specific IP flow through a certain
    isochronous channel of IEEE1394 bus.  (2)Transmit specific AV flow
    (such as MPEG2-TS with CIP header[61883]) through a certain
    isochronous channel of IEEE1394 bus (and control these flows by IP
    applications).  To realize these, this draft proposes the protocol
    with following features.  (1)Notify the relation between channel ID
    and IP flow.  (2)Notify the bandwidth of the isochronous
    channel. (3)Notify the direction of the IP flow transmitted through
    the channel.  (4)Notify the attribute of the flow. This protocol is
    defined as the extension of MCAP (Multicast Channel Allocation
    Protocol).

1. Introduction

IP1394 working group is discussing on how to transport the Internet
packets on IEEE1394 bus. Current draft[ip1394] supports "best effort"

T.Saito                                                         [Page 1]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

transmission of IP packets on IEEE1394 bus, and following three
methods are being standardized.

    (1)IP broadcast /IP multicast on 1394 async stream (default channel
       specified by the BROADCAST_CHANNEL register)

    (2)IP multicast on 1394 async stream

    (3)IP unicast on 1394 async write

On the other hand, IEEE1394 is a link layer network with isochronous
transfer mode capability. Therefore it is quite natural that there
appear following demands.

    (1)Transmit a specific IP flow through a certain isochronous
    channel of IEEE1394 bus.

    (2)Transmit a specific AV flow (such as MPEG2-TS with CIP
    header[61883]) through a certain isochronous channel of IEEE1394
    bus (and control these flows by IP applications)

To realize these, this draft proposes a protocol with following
features.

    (1)Notify the relation between the channel ID and the IP flow.

    (2)Notify the bandwidth of the isochronous channel

    (3)Notify the direction of the IP flow transferred through the
    channel

    (4)Notify the attribute of the flow

This protocol is defined as the extension of MCAP(Multicast Channel
Allocation Protocol)[ip1394], because MCAP has already had the
capability of (1) and (2) above.

In this document, we explain the brief of MCAP first.  Then we
introduce the overview of the extended features of MCAP.

2. A Brief of MCAP

MCAP is used when one wants to transport a specific IP multicast
packets on a specific IEEE1394 asynchronous stream (channel). MCAP
notifies the relation between IP multicast address and asynchronous
stream channel number through which the IP multicast packets are
transferred. Following is the example format of MCAP packet when there
is only one IP multicast address to be notified.

T.Saito                                                         [Page 2]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

                        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(=1)   |            reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   expiration  |    channel    |     speed     |    reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           bandwidth                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         group_address                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1. MCAP packet format (type = 1)
       (Notification of the relation between IP multicast address
                            and channel ID)

First four bytes are MCAP message header, and following fields are
MCAP address descriptor. "Type = 1" means this MCAP packet is used to
notify the relation between IP multicast address and IEEE1394 channel
where the IP multicast packets are transferred.

Suppose IP multicast packets addressed to IP multicast address ip_M
are transferred through the asynchronous stream whose channel ID = #y,
then "channel" field of the packet is #y, and "group_address" field is
ip_M, and this packet is sent through the "default channel".

Further more, "length" field in MCAP message header indicates the
whole length of the MCAP message, and "opcode" field carries the value
meaning "Advertise" or "Solicitation". "Length" field of the address
descriptor is the length of the whole of the address descriptor
fields, "expiration" means the valid time of the relationship. "Speed"
field represents the bit-speed at which the IP multicast flow is
transferred. "Bandwidth" field is not used in this type.

3. Extended MCAP; Protocol Overview

This draft assumes following two.

 (1)Both the sender and the receiver of a certain IP flow or AV flow
are connected to a same IEEE1394 bus.

(The case IEEE1394 bridge is used is for further study. The case the
IP or AV flow traverses over several subnets is also for further
study.)

 (2)Either the sender or the receiver triggers this protocol. In other

T.Saito                                                         [Page 3]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

words, "third party setup" is out of scope in this document.

3.1 Transmission of the IP flow on IEEE1394 isochronous channel

First, we explain the case the specific IP flow is transferred through
a certain isochronous channel of the IEEE1394 bus. Suppose IP flow
transmission is done between node A (IP address = ip_A) and node B (IP
address = ip_B)

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.

   IP_node_A            Iso Resource Manager            IP_node_B

       <------------------------------------------------------->
              Session Control (ip_A, port_A, ip_B, port_B)

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

       -------------------------------------------------------->
        MCAP(type=2) (#x, IP flow descriptor, Y bps, receive)

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

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

Before the transmission of the IP flow, upper layer session control
(such as RTSP[rtsp]) sets up a specific IP flow between the node A and
the node B. We represent the IP flow as follows.

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

Note that "port" represents either TCP port or UDP port. The number of
IP flows could be plural, but Figure 2 shows the case of just one IP
flow.

Then, the user wants to transfer the IP flow through IEEE1394
isochronous channel with a certain QoS capability.

We assume the node A, setting up of the session, knows how many
communication resources (such as bandwidth) are needed for the
session. Node A reserves the channel ID and bandwidth by accessing the

T.Saito                                                         [Page 4]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

isochronous resource manager on the IEEE1394 bus.

Then the node A notifies the node B, which is receiver node, the
followings. These are (1)flow ID (which identifies the IP flow), (2)
the channel ID of the isochronous channel where the IP flow is
transmitted, (3) the bandwidth of the isochronous channel, and (4) the
direction of the IP flow, using MCAP.

        Note that MCAP (type=1) already has (1), (2) and (3)
        capability above.

Here we define new MCAP type (type = 2). When type field of the MCAP
packet is two, then the MCAP packet is one to notify the relation
between the IP flow identifier and the channel ID of the isochronous
channel of the IEEE1394 bus to the target. The packet format follows.

                        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  |D|  reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   expiration  |    channel    |     speed     |    reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           bandwidth                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                           Flow ID                             +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

We call least 6 quadlets "IP flow descriptor". The differences between
type=1 format are that the value of type field is two, "flow ID type",
"D (direction) bit", and "flow ID" are newly defined.

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

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

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

T.Saito                                                         [Page 5]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

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

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

"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[1394].

"Flow ID type" specifies the type of flow ID, and indicates address
family of network address and transport protocol used in the flow
ID. In this section of this draft, the only values of the "flow ID
type" in this section are two and three, which respectively represents
(Sender_address, Sender_Port, Receiver_address, Receiver_Port).

        Flow ID type=2; Address Family: IPv4
                        Transport Protocol: TCP

                        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 IPv4 address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Destination IPv4 address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Source TCP Port             |    Destination TCP Port       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4. Format of flow ID (Flow ID Type=2)

        Flow ID type=3; Address Family: IPv4
                        Transport Protocol: UDP

                        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 IPv4 address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Destination IPv4 address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Source UDP Port             |    Destination UDP Port       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5. Format of flow ID (Flow ID Type=3)

T.Saito                                                         [Page 6]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

Above is the case when the direction of the IP flow is from node A to
node B. But there is the case where the direction of the IP flow is
opposite. In this case, Figure 6 shows the protocol sequence, where
the value of "D bit" turns out to be one (send the flow).

   IP_node_A            Isochronous Resource Manager    IP_node_B

       <------------------------------------------------------->
              Session Control(ip_B, port_B, ip_A, port_A)

       ---------------------------->
  Allocate channel ID(#x), & bandwidth(Y bps)

       -------------------------------------------------------->
           MCAP(type=2) (#x, IP flow descriptor, Y bps, send)

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

                        Figure 6. MCAP procedure
      (when direction of the IP flow and the control is opposite.)

Note that one MCAP packet can carry more than one IP flow descriptor.
Also note that this MCAP packet is sent as 1394 unicast (async write)
when the notified IP flow is an unicast flow.

3.2 Transmission of AV flow on IEEE1394 isochronous channel

In this section, we describe the case AV flow is controlled by IP
application, and a specific AV flow is transmitted through a specific
IEEE1394 isochronous channel. A "Specific AV flow" means here AV flow
defined by IEC61883 standard[61883], including MPEG2-TS and DV format
AV data.

As same as section 3.1, the specific AV flow is transmitted between
the node A (IP address=ip_A) and the node B (IP address=ip_B).

Note that the direction of the AV flow could either "from node A to
node B" or "from node B to node A". We also assume that the direction
of the AV flows is from node A to node B for a while.

T.Saito                                                         [Page 7]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

   IP_node_A            Isochronous Resource Manager    IP_node_B

       <------------------------------------------------------->
                    Session Control (IP application)

       ---------------------------->
  Allocate channel ID(#x) & bandwidth(Y bps)

       -------------------------------------------------------->
         MCAP(type=3) (#x, IP flow descriptor, Y bps, receive)

       ========================================================>
         AV flow (on isochronous channel #x) (IEC 61883 format)

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

Before transmitting the specific AV flow, setting up of the AV flow
using upper layer session procedure is done between the node A and the
node B. The detail of the session procedure is out of scope in this
document.

Then, the user wants to transmit the AV flow through IEEE1394
isochronous channel with a certain QoS capability.

We assume the node A, setting up of the session, knows how many
communication resources (such as bandwidth) are needed for the
session. Node A reserves the channel ID and bandwidth by accessing the
isochronous resource manager on the IEEE1394 bus.

Then the node A notifies the node B, which is receiver node, the
followings. These are (1)the attribute of the AV flow, (2) the channel
ID of the isochronous channel where the AV flow is transmitted, (3)
the bandwidth of the isochronous channel, and (4) the direction of the
AV flow, also using MCAP.

    Note that  MCAP (type=1) already  has (2) and (3)  capability
        above.

Here we define new MCAP type (type = 3). When type field of the MCAP
packet is three, then the MCAP packet is one to notify the relation
among the attributes of the AV flow, the sender/receiver of the AV
flow, and the channel ID of the isochronous channel of the IEEE1394
bus. Type=3 represents that the AV flow is in IEC61883 format. The
packet format follows.

T.Saito                                                         [Page 8]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

                        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(=3)   |FlowID type(=1)|D|  reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   expiration  |    channel    |     speed     |  reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           bandwidth                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Flow ID                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 8.  MCAP packet format (Flow ID Type=3)
      (type = 3, notification between the AV flow and the channel,
              and AV packet format(= IEC61883 specified))

The differences between section 3.1 format are that the value of type
field is three, and "flow ID type" is one.

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

"Flow ID type" field (= one) represents the type of the flow ID
format.

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

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

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

        1; Send the AV flow
        (the MCAP message and the AV 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[1394].

"Flow ID type" specifies the type of flow ID. In this draft, only
value of the "flow ID type" is one, which specifies (Sender_address,
Receiver_address), and the address family is IPv4.

T.Saito                                                         [Page 9]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

Flow ID type=1;
                        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 IPv4 address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Destination IPv4 address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 9.  Flow ID format (Flow ID type = 1)

Above is the case when the direction of the AV flow is from node A to
node B. But there is the case where the direction of the AV flow is
opposite. In this case, Figure 10 shows the protocol sequence, where
the value of "D bit" turns out to be one (send the flow).

   IP_node_A            Isochronous Resource Manager    IP_node_B

       <------------------------------------------------------->
                  Session Control (by IP applications)

       ---------------------------->
     Allocate Channel ID(#x) & bandwidth(Y bps)

       -------------------------------------------------------->
          MCAP(type=3) (#x, IP flow descriptor, Y bps, send)

       <========================================================
         AV flow (on isochronous channel #x) (IEC61883 format)

                       Figure 10. MCAP procedure
     (when both the AV flow and the control are opposite direction)

Note that one MCAP packet can carry more than one IP flow descriptor.
Also note that this MCAP packet can be sent as 1394 unicast (async
write).

4. Interconnection of plural IEEE1394 buses

Plural IEEE1394 buses can be connected via IEEE1394 bridge or IEEE1394
router. In IEEE1394 bridge environment, all (bridge aware) 1394 nodes
can communicate with one on another 1394 bus in 1394 specific manner.
But IEEE1394 bridge specification is now under discussion in 1394
community.

T.Saito                                                        [Page 10]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

In IEEE1394 router environment, nodes on one 1394 bus can communicate
with nodes on another 1394 bus on IP. Note that these IEEE1394 buses
can belong to same IP subnet when IEEE1394 router behaves like "IP
bridge", which is the bridge not using MAC address but IP address to
route the IP packets.

In IEEE1394 router environment, the proposed extended MCAP can be used
as resource reservation protocol on inter-1394 environment. Suppose
that IP_node_A on IEEE1394_Bus_1, which communicates with IP_node_B on
IEEE1394_bus_2 connected via IP_bridge, wants to reserve bandwidth (Y
bps).

   IP_node_A    IRM_1      IP_bridge    IRM_2          IP_node_B

       <------------------------------------------------------->
                  Session Control (by IP applications)

       ----------->
     Allocate Channel ID(#x) & bandwidth(Y bps)

       -------------------->
          MCAP (#x, IP flow descriptor, Y bps)

                              ----------->
                             Allocate Channel ID(#z) & bandwidth(Y bps)

                              ------------------------------->
                              MCAP (#z, IP flow descriptor, Y bps)

       =========================> =========================>
         IP/AV flow (on #x)            IP/AV flow (on #z)

                  Figure 11. MCAP on plural 1394 environment

IP_node_A can send an MCAP packet to make a reservation to IP_node_B
(Destination IP address = IP_node_B). The IP_Bridge can recognize it
as the MCAP packet by seeing its Ethertype field, and for reserving
bandwidth by checking its type field. The IP_Bridge decides the
direction of IP_node_B (IEEE1394_bus_2), makes a reservation of Y bps
on IEEE1394_bus_2, reserves isochronous channel #z by accessing IRM_2
on IEEE1394_bus_2, memorizes the relation between #x on IEEE1394_bus_1
and #z on IEEE1394_bus_2, and forwards the MCAP packet to IP_node_B.

By these procedure, isochronous path with Y bps bandwidth is
established between IP_node_A and IP_node_B. Then IP_node_A (or
IP_node_B) can send IP/AV packet through the reserved isochronous
channel.

T.Saito                                                        [Page 11]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

5. Future Works

    + This    protocol is defined  as the   extension of MCAP (Multicast
    Channel Allocation Protocol),  but it might  be defined as  separate
    protocol.

    + There are only two  "opcode" types ("Advertise" and "Solicitation")
    as the  original MCAP draft. There  might some needs to prepare such
    acknowledge messages as "Advertise Ack" and "Solicitation Ack" to
    ensure that the target node recognizes the message.

    + "Opcode" types ("Advertise" and "Solicitation") may not be
    appropriate for the proposed purpose. New opcode types such as
    "Indication" might be appropriate.

    + Currently, the authors don't consider "RSVP over 1394" deeply
    because there are not enough end-to-end RSVP environment yet on
    the Internet.

    The current scope of this document is to transmit (real-time) IP
    packet on local 1394 network(s), and to control AV transmission
    using IP.

    + This draft specifies how the IP flow or AV flow is transferred on
    local IEEE1394 bus(es). But the case when the flow is traversed over
    several IP subnets, and the protocol bindings between this proposed
    protocol and  inter-subnet resource   reservation protocol such   as
    RSVP[rsvp] is needed, is for further study. The combination of this
    protocol and RSVP is one possible solution (RSVP uses the MCAP
    extension as 1394 link reservation).

    + The "direction" bit may not be needed because the node can specify
    the direction of the flow by analizing the flow ID field.

Security Considerations

    Security issues are not discussed in this document.

Acknowledgements

   We would like to thank Mr.Kenji Fujisawa for having discussions.


References

[1394] IEEE 1394-1995: "Standard for a High Performance Serial Bus"

[61883] ISO/IEC 61883: "Specifications of Digital Interface for
Consumer Electronic Audio/Video Equipment"

[ip1394] P. Johansson, "IPv4 over IEEE 1394", internet-draft
draft-ietf-ip1394-ipv4-16.txt,.ps, August 1999

T.Saito                                                        [Page 12]


Internet-Draft  draft-ietf-ip1394-ip-over-iso1394-00.txt  September 1999

[rsvp] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin.
" Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC2205, September 1997.

[rtsp] H. Schulzrinne, A. Rao, R. Lanphier.
"Real Time Streaming Protocol (RTSP)", RFC2326, April 1998.

Author's address

    Takeshi Saito
    Corporate R&D Center
    Toshiba Corp,
    1 Komukai-Toshiba,
    Saiwai, Kawasaki, Kanagawa
    210-8582 Japan
    Phone: +81-44-549-2230
    E-mail: saiken@csl.rdc.toshiba.co.jp

    Yoshiaki Takabatake
    Corporate R&D Center
    Toshiba Corp,
    1 Komukai-Toshiba,
    Saiwai, Kawasaki, Kanagawa
    210-8582 Japan
    Phone: +81-44-549-2230
    E-mail: tkbtk@csl.rdc.toshiba.co.jp

    Mikio Hashimoto
    Corporate R&D Center
    Toshiba Corp,
    1 Komukai-Toshiba,
    Saiwai, Kawasaki, Kanagawa
    210-8582 Japan
    Phone: +81-44-549-2230
    E-mail: hashi@csl.rdc.toshiba.co.jp

    Kei-ichi Teramoto
    Corporate R&D Center
    Toshiba Corp,
    1 Komukai-Toshiba,
    Saiwai, Kawasaki, Kanagawa
    210-8582 Japan
    Phone: +81-44-549-2230
    E-mail: teramoto@csl.rdc.toshiba.co.jp

T.Saito                                                        [Page 13]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/