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]
