Internet-Draft Takeshi Saito 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 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" transmission of IP packets on IEEE1394 bus, and following three methods are being standardized. T. Saito [Page 1] Internet Draft draft-saito-ip1394-mcap-ext-00.txt February 1999 (1)IP broadcast /IP multicast on 1394 async stream (default channel) (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.) T. Saito [Page 3] Internet Draft draft-saito-ip1394-mcap-ext-00.txt February 1999 (2)Either the sender or the receiver triggers this protocol. In other 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 T. Saito [Page 4] Internet Draft draft-saito-ip1394-mcap-ext-00.txt February 1999 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)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 T. Saito [Page 5] Internet Draft draft-saito-ip1394-mcap-ext-00.txt February 1999 (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) "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=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. 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") T. Saito [Page 10] Internet Draft draft-saito-ip1394-mcap-ext-00.txt February 1999 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. + 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 T. Saito [Page 11] Internet Draft draft-saito-ip1394-mcap-ext-00.txt February 1999 Phone: +81-44-549-2230 E-mail: saiken@csl.rdc.toshiba.co.jp Yoshiaki Takabatake Toshiba R&D Center 1 Komukai-Toshiba, Saiwai, Kawasaki, Kanagawa 210-8582 Japan Phone: +81-44-549-2230 E-mail: tkbtk@csl.rdc.toshiba.co.jp Mikio Hashimoto Toshiba R&D Center 1 Komukai-Toshiba, Saiwai, Kawasaki, Kanagawa 210-8582 Japan Phone: +81-44-549-2230 E-mail: hashi@csl.rdc.toshiba.co.jp T. Saito [Page 12]