idnits 2.17.1 draft-ietf-ip1394-ip-over-iso1394-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([61883]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 378 has weird spacing: '...already has (...' == Line 532 has weird spacing: '... + This pro...' == Line 533 has weird spacing: '...t might be de...' == Line 537 has weird spacing: '... as the origi...' == Line 556 has weird spacing: '...col and inter...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1999) is 8991 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1394' -- Possible downref: Non-RFC (?) normative reference: ref. '61883' Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Takeshi Saito 2 Yoshiaki Takabatake 3 Expires: March 2000 Mikio Hashimoto 4 Kei-ichi Teramoto 5 Corporate R&D Center 6 Toshiba Corp 7 September 1999 9 "IP over iso1394" and 10 "AV over iso1394" controlled by an extension of MCAP. 12 Status of this memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 IEEE1394 bus is a link layer network with isochronous transfer mode 37 capability. Therefore it is quite natural that there appears 38 following demands. (1)Transmit specific IP flow through a certain 39 isochronous channel of IEEE1394 bus. (2)Transmit specific AV flow 40 (such as MPEG2-TS with CIP header[61883]) through a certain 41 isochronous channel of IEEE1394 bus (and control these flows by IP 42 applications). To realize these, this draft proposes the protocol 43 with following features. (1)Notify the relation between channel ID 44 and IP flow. (2)Notify the bandwidth of the isochronous 45 channel. (3)Notify the direction of the IP flow transmitted through 46 the channel. (4)Notify the attribute of the flow. This protocol is 47 defined as the extension of MCAP (Multicast Channel Allocation 48 Protocol). 50 1. Introduction 52 IP1394 working group is discussing on how to transport the Internet 53 packets on IEEE1394 bus. Current draft[ip1394] supports "best effort" 54 transmission of IP packets on IEEE1394 bus, and following three 55 methods are being standardized. 57 (1)IP broadcast /IP multicast on 1394 async stream (default channel 58 specified by the BROADCAST_CHANNEL register) 60 (2)IP multicast on 1394 async stream 62 (3)IP unicast on 1394 async write 64 On the other hand, IEEE1394 is a link layer network with isochronous 65 transfer mode capability. Therefore it is quite natural that there 66 appear following demands. 68 (1)Transmit a specific IP flow through a certain isochronous 69 channel of IEEE1394 bus. 71 (2)Transmit a specific AV flow (such as MPEG2-TS with CIP 72 header[61883]) through a certain isochronous channel of IEEE1394 73 bus (and control these flows by IP applications) 75 To realize these, this draft proposes a protocol with following 76 features. 78 (1)Notify the relation between the channel ID and the IP flow. 80 (2)Notify the bandwidth of the isochronous channel 82 (3)Notify the direction of the IP flow transferred through the 83 channel 85 (4)Notify the attribute of the flow 87 This protocol is defined as the extension of MCAP(Multicast Channel 88 Allocation Protocol)[ip1394], because MCAP has already had the 89 capability of (1) and (2) above. 91 In this document, we explain the brief of MCAP first. Then we 92 introduce the overview of the extended features of MCAP. 94 2. A Brief of MCAP 96 MCAP is used when one wants to transport a specific IP multicast 97 packets on a specific IEEE1394 asynchronous stream (channel). MCAP 98 notifies the relation between IP multicast address and asynchronous 99 stream channel number through which the IP multicast packets are 100 transferred. Following is the example format of MCAP packet when there 101 is only one IP multicast address to be notified. 103 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | length | reserved | opcode | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | length | type(=1) | reserved | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | expiration | channel | speed | reserved | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | bandwidth | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | | 115 + group_address + 116 | | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 Figure 1. MCAP packet format (type = 1) 120 (Notification of the relation between IP multicast address 121 and channel ID) 123 First four bytes are MCAP message header, and following fields are 124 MCAP address descriptor. "Type = 1" means this MCAP packet is used to 125 notify the relation between IP multicast address and IEEE1394 channel 126 where the IP multicast packets are transferred. 128 Suppose IP multicast packets addressed to IP multicast address ip_M 129 are transferred through the asynchronous stream whose channel ID = #y, 130 then "channel" field of the packet is #y, and "group_address" field is 131 ip_M, and this packet is sent through the "default channel". 133 Further more, "length" field in MCAP message header indicates the 134 whole length of the MCAP message, and "opcode" field carries the value 135 meaning "Advertise" or "Solicitation". "Length" field of the address 136 descriptor is the length of the whole of the address descriptor 137 fields, "expiration" means the valid time of the relationship. "Speed" 138 field represents the bit-speed at which the IP multicast flow is 139 transferred. "Bandwidth" field is not used in this type. 141 3. Extended MCAP; Protocol Overview 143 This draft assumes following two. 145 (1)Both the sender and the receiver of a certain IP flow or AV flow 146 are connected to a same IEEE1394 bus. 148 (The case IEEE1394 bridge is used is for further study. The case the 149 IP or AV flow traverses over several subnets is also for further 150 study.) 152 (2)Either the sender or the receiver triggers this protocol. In other 154 words, "third party setup" is out of scope in this document. 156 3.1 Transmission of the IP flow on IEEE1394 isochronous channel 158 First, we explain the case the specific IP flow is transferred through 159 a certain isochronous channel of the IEEE1394 bus. Suppose IP flow 160 transmission is done between node A (IP address = ip_A) and node B (IP 161 address = ip_B) 163 Note that the direction of the IP flow could be either "from node A to 164 node B" or "from node B to node A". Here we assume that the direction 165 of the IP flows is from node A to node B for a while. 167 IP_node_A Iso Resource Manager IP_node_B 169 <-------------------------------------------------------> 170 Session Control (ip_A, port_A, ip_B, port_B) 172 ----------------------------> 173 Allocate Channel ID(#x) & Bandwidth(Y bps) 175 --------------------------------------------------------> 176 MCAP(type=2) (#x, IP flow descriptor, Y bps, receive) 178 ========================================================> 179 (the specific) IP flow (on isochronous channel #x) 180 (ip_A, port_A, ip_B, port_B) 182 Figure 2. MCAP procedure 183 (when both the IP flow and the control are in the same direction) 185 Before the transmission of the IP flow, upper layer session control 186 (such as RTSP[rtsp]) sets up a specific IP flow between the node A and 187 the node B. We represent the IP flow as follows. 189 (Sender_IP_address, Sender_port, Receiver_IP_address, Receiver_port) 190 = (ip_A, port_A, ip_B, port_B) 192 Note that "port" represents either TCP port or UDP port. The number of 193 IP flows could be plural, but Figure 2 shows the case of just one IP 194 flow. 196 Then, the user wants to transfer the IP flow through IEEE1394 197 isochronous channel with a certain QoS capability. 199 We assume the node A, setting up of the session, knows how many 200 communication resources (such as bandwidth) are needed for the 201 session. Node A reserves the channel ID and bandwidth by accessing the 202 isochronous resource manager on the IEEE1394 bus. 204 Then the node A notifies the node B, which is receiver node, the 205 followings. These are (1)flow ID (which identifies the IP flow), (2) 206 the channel ID of the isochronous channel where the IP flow is 207 transmitted, (3) the bandwidth of the isochronous channel, and (4) the 208 direction of the IP flow, using MCAP. 210 Note that MCAP (type=1) already has (1), (2) and (3) 211 capability above. 213 Here we define new MCAP type (type = 2). When type field of the MCAP 214 packet is two, then the MCAP packet is one to notify the relation 215 between the IP flow identifier and the channel ID of the isochronous 216 channel of the IEEE1394 bus to the target. The packet format follows. 218 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | length | reserved | opcode | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | length | type(=2) | Flow ID type |D| reserved | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | expiration | channel | speed | reserved | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | bandwidth | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | | 230 + Flow ID + 231 | | 232 + + 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 3. MCAP packet format 237 (type = 2, notification between the flow ID and the channel) 239 We call least 6 quadlets "IP flow descriptor". The differences between 240 type=1 format are that the value of type field is two, "flow ID type", 241 "D (direction) bit", and "flow ID" are newly defined. 243 When "type" field is two, the IP flow descriptor specifies the 244 relation between specific IP flow(s) and the 1394 isochronous channel 245 through which the IP flow passes. 247 "Flow ID type" field represents the type of the flow ID format. 249 "D (direction) bit" has following meaning according to its value. 251 0; Receive the IP flow 252 (the MCAP message and the IPv4 flow go in the same direction) 253 1; Send the IP flow 254 (the MCAP message and the IPv4 flow go in the opposite 255 direction) 257 "channel" field specifies a allocated channel number of the 258 isochronous channel, where the IP flow is transmitted. 260 "bandwidth" field specifies the bandwidth allocated for the 261 channel. The format of the field is as same as grammar of the 262 bandwidth available register on IEEE1394-1995[1394]. 264 "Flow ID type" specifies the type of flow ID, and indicates address 265 family of network address and transport protocol used in the flow 266 ID. In this section of this draft, the only values of the "flow ID 267 type" in this section are two and three, which respectively represents 268 (Sender_address, Sender_Port, Receiver_address, Receiver_Port). 270 Flow ID type=2; Address Family: IPv4 271 Transport Protocol: TCP 273 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Source IPv4 address | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Destination IPv4 address | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Source TCP Port | Destination TCP Port | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 4. Format of flow ID (Flow ID Type=2) 285 Flow ID type=3; Address Family: IPv4 286 Transport Protocol: UDP 288 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Source IPv4 address | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Destination IPv4 address | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Source UDP Port | Destination UDP Port | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 5. Format of flow ID (Flow ID Type=3) 300 Above is the case when the direction of the IP flow is from node A to 301 node B. But there is the case where the direction of the IP flow is 302 opposite. In this case, Figure 6 shows the protocol sequence, where 303 the value of "D bit" turns out to be one (send the flow). 305 IP_node_A Isochronous Resource Manager IP_node_B 307 <-------------------------------------------------------> 308 Session Control(ip_B, port_B, ip_A, port_A) 310 ----------------------------> 311 Allocate channel ID(#x), & bandwidth(Y bps) 313 --------------------------------------------------------> 314 MCAP(type=2) (#x, IP flow descriptor, Y bps, send) 316 <======================================================== 317 (the specific) IP flow (on isochronous channel #x) 318 (ip_B, port_B, ip_A, port_A) 320 Figure 6. MCAP procedure 321 (when direction of the IP flow and the control is opposite.) 323 Note that one MCAP packet can carry more than one IP flow descriptor. 324 Also note that this MCAP packet is sent as 1394 unicast (async write) 325 when the notified IP flow is an unicast flow. 327 3.2 Transmission of AV flow on IEEE1394 isochronous channel 329 In this section, we describe the case AV flow is controlled by IP 330 application, and a specific AV flow is transmitted through a specific 331 IEEE1394 isochronous channel. A "Specific AV flow" means here AV flow 332 defined by IEC61883 standard[61883], including MPEG2-TS and DV format 333 AV data. 335 As same as section 3.1, the specific AV flow is transmitted between 336 the node A (IP address=ip_A) and the node B (IP address=ip_B). 338 Note that the direction of the AV flow could either "from node A to 339 node B" or "from node B to node A". We also assume that the direction 340 of the AV flows is from node A to node B for a while. 342 IP_node_A Isochronous Resource Manager IP_node_B 344 <-------------------------------------------------------> 345 Session Control (IP application) 347 ----------------------------> 348 Allocate channel ID(#x) & bandwidth(Y bps) 350 --------------------------------------------------------> 351 MCAP(type=3) (#x, IP flow descriptor, Y bps, receive) 353 ========================================================> 354 AV flow (on isochronous channel #x) (IEC 61883 format) 356 Figure 7 MCAP procedure 357 (when both the IP flow and the control are in the same direction) 359 Before transmitting the specific AV flow, setting up of the AV flow 360 using upper layer session procedure is done between the node A and the 361 node B. The detail of the session procedure is out of scope in this 362 document. 364 Then, the user wants to transmit the AV flow through IEEE1394 365 isochronous channel with a certain QoS capability. 367 We assume the node A, setting up of the session, knows how many 368 communication resources (such as bandwidth) are needed for the 369 session. Node A reserves the channel ID and bandwidth by accessing the 370 isochronous resource manager on the IEEE1394 bus. 372 Then the node A notifies the node B, which is receiver node, the 373 followings. These are (1)the attribute of the AV flow, (2) the channel 374 ID of the isochronous channel where the AV flow is transmitted, (3) 375 the bandwidth of the isochronous channel, and (4) the direction of the 376 AV flow, also using MCAP. 378 Note that MCAP (type=1) already has (2) and (3) capability 379 above. 381 Here we define new MCAP type (type = 3). When type field of the MCAP 382 packet is three, then the MCAP packet is one to notify the relation 383 among the attributes of the AV flow, the sender/receiver of the AV 384 flow, and the channel ID of the isochronous channel of the IEEE1394 385 bus. Type=3 represents that the AV flow is in IEC61883 format. The 386 packet format follows. 388 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | length | reserved | opcode | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | length | type(=3) |FlowID type(=1)|D| reserved | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | expiration | channel | speed | reserved | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | bandwidth | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 + Flow ID + 401 | | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 8. MCAP packet format (Flow ID Type=3) 405 (type = 3, notification between the AV flow and the channel, 406 and AV packet format(= IEC61883 specified)) 408 The differences between section 3.1 format are that the value of type 409 field is three, and "flow ID type" is one. 411 When "type" field is three, the IP flow descriptor specifies the 412 relation between specific IEC61883 format AV flow(s) and the 1394 413 isochronous channel through which the AV flow passes. 415 "Flow ID type" field (= one) represents the type of the flow ID 416 format. 418 "channel" field specifies a allocated channel number of the 419 isochronous channel, where the AV flow is transmitted. 421 "D (direction) bit" has following meaning according to its value. 423 0; Receive the AV flow 424 (the MCAP message and the AV flow go in the same direction) 426 1; Send the AV flow 427 (the MCAP message and the AV flow go in the opposite direction) 429 "bandwidth" field specifies the bandwidth allocated for the 430 channel. The format of the field is as same as grammar of the 431 bandwidth available register on IEEE1394-1995[1394]. 433 "Flow ID type" specifies the type of flow ID. In this draft, only 434 value of the "flow ID type" is one, which specifies (Sender_address, 435 Receiver_address), and the address family is IPv4. 437 Flow ID type=1; 438 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Source IPv4 address | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Destination IPv4 address | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Figure 9. Flow ID format (Flow ID type = 1) 448 Above is the case when the direction of the AV flow is from node A to 449 node B. But there is the case where the direction of the AV flow is 450 opposite. In this case, Figure 10 shows the protocol sequence, where 451 the value of "D bit" turns out to be one (send the flow). 453 IP_node_A Isochronous Resource Manager IP_node_B 455 <-------------------------------------------------------> 456 Session Control (by IP applications) 458 ----------------------------> 459 Allocate Channel ID(#x) & bandwidth(Y bps) 461 --------------------------------------------------------> 462 MCAP(type=3) (#x, IP flow descriptor, Y bps, send) 464 <======================================================== 465 AV flow (on isochronous channel #x) (IEC61883 format) 467 Figure 10. MCAP procedure 468 (when both the AV flow and the control are opposite direction) 470 Note that one MCAP packet can carry more than one IP flow descriptor. 471 Also note that this MCAP packet can be sent as 1394 unicast (async 472 write). 474 4. Interconnection of plural IEEE1394 buses 476 Plural IEEE1394 buses can be connected via IEEE1394 bridge or IEEE1394 477 router. In IEEE1394 bridge environment, all (bridge aware) 1394 nodes 478 can communicate with one on another 1394 bus in 1394 specific manner. 479 But IEEE1394 bridge specification is now under discussion in 1394 480 community. 482 In IEEE1394 router environment, nodes on one 1394 bus can communicate 483 with nodes on another 1394 bus on IP. Note that these IEEE1394 buses 484 can belong to same IP subnet when IEEE1394 router behaves like "IP 485 bridge", which is the bridge not using MAC address but IP address to 486 route the IP packets. 488 In IEEE1394 router environment, the proposed extended MCAP can be used 489 as resource reservation protocol on inter-1394 environment. Suppose 490 that IP_node_A on IEEE1394_Bus_1, which communicates with IP_node_B on 491 IEEE1394_bus_2 connected via IP_bridge, wants to reserve bandwidth (Y 492 bps). 494 IP_node_A IRM_1 IP_bridge IRM_2 IP_node_B 496 <-------------------------------------------------------> 497 Session Control (by IP applications) 499 -----------> 500 Allocate Channel ID(#x) & bandwidth(Y bps) 502 --------------------> 503 MCAP (#x, IP flow descriptor, Y bps) 505 -----------> 506 Allocate Channel ID(#z) & bandwidth(Y bps) 508 -------------------------------> 509 MCAP (#z, IP flow descriptor, Y bps) 511 =========================> =========================> 512 IP/AV flow (on #x) IP/AV flow (on #z) 514 Figure 11. MCAP on plural 1394 environment 516 IP_node_A can send an MCAP packet to make a reservation to IP_node_B 517 (Destination IP address = IP_node_B). The IP_Bridge can recognize it 518 as the MCAP packet by seeing its Ethertype field, and for reserving 519 bandwidth by checking its type field. The IP_Bridge decides the 520 direction of IP_node_B (IEEE1394_bus_2), makes a reservation of Y bps 521 on IEEE1394_bus_2, reserves isochronous channel #z by accessing IRM_2 522 on IEEE1394_bus_2, memorizes the relation between #x on IEEE1394_bus_1 523 and #z on IEEE1394_bus_2, and forwards the MCAP packet to IP_node_B. 525 By these procedure, isochronous path with Y bps bandwidth is 526 established between IP_node_A and IP_node_B. Then IP_node_A (or 527 IP_node_B) can send IP/AV packet through the reserved isochronous 528 channel. 530 5. Future Works 532 + This protocol is defined as the extension of MCAP (Multicast 533 Channel Allocation Protocol), but it might be defined as separate 534 protocol. 536 + There are only two "opcode" types ("Advertise" and "Solicitation") 537 as the original MCAP draft. There might some needs to prepare such 538 acknowledge messages as "Advertise Ack" and "Solicitation Ack" to 539 ensure that the target node recognizes the message. 541 + "Opcode" types ("Advertise" and "Solicitation") may not be 542 appropriate for the proposed purpose. New opcode types such as 543 "Indication" might be appropriate. 545 + Currently, the authors don't consider "RSVP over 1394" deeply 546 because there are not enough end-to-end RSVP environment yet on 547 the Internet. 549 The current scope of this document is to transmit (real-time) IP 550 packet on local 1394 network(s), and to control AV transmission 551 using IP. 553 + This draft specifies how the IP flow or AV flow is transferred on 554 local IEEE1394 bus(es). But the case when the flow is traversed over 555 several IP subnets, and the protocol bindings between this proposed 556 protocol and inter-subnet resource reservation protocol such as 557 RSVP[rsvp] is needed, is for further study. The combination of this 558 protocol and RSVP is one possible solution (RSVP uses the MCAP 559 extension as 1394 link reservation). 561 + The "direction" bit may not be needed because the node can specify 562 the direction of the flow by analizing the flow ID field. 564 Security Considerations 566 Security issues are not discussed in this document. 568 Acknowledgements 570 We would like to thank Mr.Kenji Fujisawa for having discussions. 572 References 574 [1394] IEEE 1394-1995: "Standard for a High Performance Serial Bus" 576 [61883] ISO/IEC 61883: "Specifications of Digital Interface for 577 Consumer Electronic Audio/Video Equipment" 579 [ip1394] P. Johansson, "IPv4 over IEEE 1394", internet-draft 580 [rsvp] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin. 581 " Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 582 Specification", RFC2205, September 1997. 584 [rtsp] H. Schulzrinne, A. Rao, R. Lanphier. 585 "Real Time Streaming Protocol (RTSP)", RFC2326, April 1998. 587 Author's address 589 Takeshi Saito 590 Corporate R&D Center 591 Toshiba Corp, 592 1 Komukai-Toshiba, 593 Saiwai, Kawasaki, Kanagawa 594 210-8582 Japan 595 Phone: +81-44-549-2230 596 E-mail: saiken@csl.rdc.toshiba.co.jp 598 Yoshiaki Takabatake 599 Corporate R&D Center 600 Toshiba Corp, 601 1 Komukai-Toshiba, 602 Saiwai, Kawasaki, Kanagawa 603 210-8582 Japan 604 Phone: +81-44-549-2230 605 E-mail: tkbtk@csl.rdc.toshiba.co.jp 607 Mikio Hashimoto 608 Corporate R&D Center 609 Toshiba Corp, 610 1 Komukai-Toshiba, 611 Saiwai, Kawasaki, Kanagawa 612 210-8582 Japan 613 Phone: +81-44-549-2230 614 E-mail: hashi@csl.rdc.toshiba.co.jp 616 Kei-ichi Teramoto 617 Corporate R&D Center 618 Toshiba Corp, 619 1 Komukai-Toshiba, 620 Saiwai, Kawasaki, Kanagawa 621 210-8582 Japan 622 Phone: +81-44-549-2230 623 E-mail: teramoto@csl.rdc.toshiba.co.jp