Subject: IP over 1394 iso channel

From: Takeshi Saito <[email-masked]>
Date: Fri, 12 Feb 1999 17:58:13 +0900

IP1394ers,

Here is the draft about "IP over 1394 iso channel". I propose this as
an extension of MCAP. Comments are welcome.

Regards.

Takeshi "Ken" Saito
Toshiba R&D Center

------------------------------------------------

Internet-Draft                                             Takeshi Saito
<draft-saito-ip1394-mcap-ext-00.txt>                 Yoshiaki Takabatake
Expires: August 1999                                     Mikio Hashimoto
                                                      Toshiba R&D Center
                                                           February 1999

An Extension of MCAP for Data Transmission on IEEE1394 Isochronous Channel

Status of this memo

     This document is an Internet-Draft.  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.''

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
     (US West Coast).

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

T. Saito                                                        [Page 1]

Internet Draft     draft-saito-ip1394-mcap-ext-00.txt      February 1999

    (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-saito-ip1394-mcap-ext-00.txt      February 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-saito-ip1394-mcap-ext-00.txt      February 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-saito-ip1394-mcap-ext-00.txt      February 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-saito-ip1394-mcap-ext-00.txt      February 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" 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 (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 (Type=3)

T. Saito                                                        [Page 6]

Internet Draft     draft-saito-ip1394-mcap-ext-00.txt      February 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-saito-ip1394-mcap-ext-00.txt      February 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-saito-ip1394-mcap-ext-00.txt      February 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 (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-saito-ip1394-mcap-ext-00.txt      February 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 (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= $B#3 (B) (#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. 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

T. Saito                                                       [Page 10]

Internet Draft     draft-saito-ip1394-mcap-ext-00.txt      February 1999

    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.

    + This  draft  specifies how the IP flow   or AV flow is  transferred on
    single IEEE1394 bus. 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-13.txt,.ps, February 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
    Toshiba R&D Center
    1 Komukai-Toshiba,
    Saiwai, Kawasaki, Kanagawa
    210-8582 Japan
    Phone: +81-44-549-2230

T. Saito                                                       [Page 11]

Internet Draft     draft-saito-ip1394-mcap-ext-00.txt      February 1999

    E-mail: [email-masked]

    Yoshiaki Takabatake
    Toshiba R&D Center
    1 Komukai-Toshiba,
    Saiwai, Kawasaki, Kanagawa
    210-8582 Japan
    Phone: +81-44-549-2230
    E-mail: [email-masked]

    Mikio Hashimoto
    Toshiba R&D Center
    1 Komukai-Toshiba,
    Saiwai, Kawasaki, Kanagawa
    210-8582 Japan
    Phone: +81-44-549-2230
    E-mail: [email-masked]

T. Saito                                                       [Page 12]