home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ip1394-ipv4-04.txt < prev    next >
Text File  |  1997-10-28  |  26KB  |  684 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.       Network Working Group                                       P. Johansson
  8.       Internet-Draft                                  Congruent Software, Inc.
  9.       <draft-ietf-ip1394-ipv4-04.txt>
  10.       Expires: April, 1998
  11.  
  12.  
  13.  
  14.                                  Ipv4 over IEEE 1394
  15.  
  16.  
  17.       STATUS OF THIS DOCUMENT
  18.  
  19.       This document is an Internet-Draft. Internet-Drafts are working
  20.       documents of the Internet Engineering Task Force (IETF), its areas, and
  21.       its working groups. Note that other groups may also distribute working
  22.       documents as Internet-Drafts.
  23.  
  24.       Internet-Drafts are draft documents valid for a maximum of six months
  25.       and may be updated, replaced, or obsoleted by other documents at any
  26.       time. It is inappropriate to use Internet-Drafts as reference material
  27.       or to cite them other than as "work in progress."
  28.  
  29.       To view the entire list of current Internet-Drafts, please check the
  30.       "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  31.       Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
  32.       munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  33.       ftp.isi.edu (US West Coast).
  34.  
  35.       ABSTRACT
  36.  
  37.       This document specifies how to use IEEE Std 1394-1995, Standard for a
  38.       High Performance Serial Bus (and its supplements), for the transport of
  39.       Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary
  40.       methods, data structures and code for that purpose and additionally
  41.       defines a standard method for Address Resolution Protocol (ARP).
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.       Expires: April, 1998                                            [Page 1]
  64.  
  65.  
  66.       Internet-Draft 04           Ipv4 over 1394                  October 1997
  67.  
  68.  
  69.       TABLE OF CONTENTS
  70.  
  71.       1. INTRODUCTION.......................................................3
  72.       2. DEFINITIONS AND NOTATION...........................................4
  73.          2.1 Conformance....................................................4
  74.          2.2 Glossary.......................................................4
  75.          2.3 Abbreviations..................................................5
  76.       3. IP-CAPABLE NODES...................................................5
  77.       4. LINK ENCAPSULATION AND FRAGMENTATION...............................6
  78.       5. ARP................................................................6
  79.       6. IP UNICAST.........................................................8
  80.          6.1 Asynchronous IP unicast........................................9
  81.          6.2 Isochronous IP unicast........................................10
  82.       7. IP BROADCAST......................................................10
  83.       8. IP MULTICAST......................................................10
  84.       9. SECURITY CONSIDERATIONS...........................................10
  85.       10. ACKNOWLEDGEMENTS.................................................10
  86.       11. REFERENCES.......................................................10
  87.       12. EDITORÆS ADDRESS.................................................11
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.       Expires: April, 1998                                            [Page 2]
  126.  
  127.  
  128.       Internet-Draft 04           Ipv4 over 1394                  October 1997
  129.  
  130.  
  131.       1. INTRODUCTION
  132.  
  133.       This document specifies how to use IEEE Std 1394-1995, Standard for a
  134.       High Performance Serial Bus (and its supplements), for the transport of
  135.       Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary
  136.       methods, data structures and codes for that purpose and additionally
  137.       defines a standard method for Address Resolution Protocol (ARP).
  138.  
  139.       The group of IEEE standards and supplements, draft or approved, related
  140.       to IEEE Std 1394-1995 is hereafter referred to either as 1394 or as
  141.       Serial Bus.
  142.  
  143.       1394 is an interconnect (bus) that conforms to the CSR architecture,
  144.       ISO/IEC 13213:1994. Serial Bus implements communications between nodes
  145.       over shared physical media at speeds that range from 100 to 400 Mbps.
  146.       Both consumer electronic applications (such as digital VCRÆs, stereo
  147.       systems, televisions and camcorders) and traditional desktop computer
  148.       applications (e.g., mass storage, printers and tapes), have adopted
  149.       1394. Serial Bus is unique in its relevance to both consumer electronic
  150.       and computer domains and is expected to form the basis of a home or
  151.       small office network that combines both types of devices.
  152.  
  153.       The CSR architecture describes a memory-mapped address space that Serial
  154.       Bus implements as a 64-bit fixed addressing scheme. Within the address
  155.       space, ten bits are allocated for bus ID (up to a maximum of 1,023
  156.       buses), six are allocated for node physical ID (up to 63 per bus) while
  157.       the remaining 48 bits (offset) describe a per node address space of 256
  158.       terabytes. The CSR architecture, by convention, splits a nodeÆs address
  159.       space into two regions with different behavioral characteristics. The
  160.       lower portion, up to but not including 0xFFFF F000 0000, is expected to
  161.       behave as memory in response to read and write transactions. The upper
  162.       portion is more like a traditional IO space: read and write transactions
  163.       to the control and status registers (CSRÆs) in this area usually have
  164.       side effects. Registers that have FIFO behavior customarily are
  165.       implemented in this region.
  166.  
  167.       Within the 64-bit address, the 16-bit node ID (bus ID and physical ID)
  168.       is analogous to a network hardware address---but 1394 node ID's are
  169.       variable and subject to reassignment each time one or more nodes are
  170.       added or removed from the bus.
  171.  
  172.       The 1394 link layer provides a datagram service with both confirmed
  173.       (acknowledged) and unconfirmed datagrams. The confirmed datagram service
  174.       is called "asynchronous" while the unconfirmed service is known as
  175.       "isochronous." Other than the presence or absence of confirmation, the
  176.       principal distinction between the two is quality of service: isochronous
  177.       datagrams are guaranteed to be delivered with bounded latency. Datagram
  178.       payloads vary with implementations and may range from one octet up to a
  179.       maximum determined by the transmission speed (at 100 Mbps, named S100,
  180.       the maximum asynchronous data payload is 512 octets while at S400 it is
  181.       2048 octets).
  182.  
  183.  
  184.  
  185.  
  186.  
  187.       Expires: April, 1998                                            [Page 3]
  188.  
  189.  
  190.       Internet-Draft 04           Ipv4 over 1394                  October 1997
  191.  
  192.  
  193.       NOTE: Extensions underway in IEEE P1394b contemplate additional speeds
  194.       of 800, 1600 and 3200 Mbps; engineering prototypes are planned for early
  195.       1998.
  196.  
  197.       2. DEFINITIONS AND NOTATION
  198.  
  199.       2.1 Conformance
  200.  
  201.       Several keywords are used to differentiate levels of requirements and
  202.       optionality, as follows:
  203.  
  204.       expected: A keyword used to describe the behavior of the hardware or
  205.       software in the design models assumed by this standard. Other hardware
  206.       and software design models may also be implemented.
  207.  
  208.       ignored: A keyword that describes bits, octets, quadlets, octlets or
  209.       fields whose values are not checked by the recipient.
  210.  
  211.       may: A keyword that indicates flexibility of choice with no implied
  212.       preference.
  213.  
  214.       reserved: A keyword used to describe objects-bits, octets, quadlets,
  215.       octlets and fields-or the code values assigned to these objects in cases
  216.       where either the object or the code value is set aside for future
  217.       standardization. Usage and interpretation may be specified by future
  218.       extensions to this or other standards. A reserved object shall be zeroed
  219.       or, upon development of a future standard, set to a value specified by
  220.       such a standard. The recipient of a reserved object shall not check its
  221.       value. The recipient of a defined object shall check its value and
  222.       reject reserved code values.
  223.  
  224.       shall: A keyword that indicates a mandatory requirement. Designers are
  225.       required to implement all such mandatory requirements to assure
  226.       interoperability with other products conforming to this standard.
  227.  
  228.       should: A keyword that denotes flexibility of choice with a strongly
  229.       preferred alternative. Equivalent to the phrase "is recommended."
  230.  
  231.       2.2 Glossary
  232.  
  233.       The following terms are used in this standard:
  234.  
  235.       address resolution protocol: A method for a requester to determine the
  236.       hardware (1394) address of an IP node from the IP address of the node.
  237.  
  238.       bus ID: A 10-bit number that uniquely identifies a particular bus within
  239.       a group of bridged buses. The bus ID is the most significant portion of
  240.       a node's 16-bit node ID.
  241.  
  242.       IP datagram: An Internet message that conforms to the format specified
  243.       by RFC 791.
  244.  
  245.       link fragment: A portion of an IP datagram transmitted within a single
  246.       1394 packet. The data payload of the 1394 packet contains both a link
  247.  
  248.  
  249.       Expires: April, 1998                                            [Page 4]
  250.  
  251.  
  252.       Internet-Draft 04           Ipv4 over 1394                  October 1997
  253.  
  254.  
  255.       fragment header and its associated link fragment. It is possible to
  256.       transmit datagrams without fragmentation.
  257.  
  258.       link fragment header: A structure that precedes all IP datagrams (or
  259.       each fragment thereof) when they are transmitted over 1394. See also
  260.       link fragment.
  261.  
  262.       local bus ID: A bus ID with the value 0x3FF. A node shall respond to
  263.       transaction requests addressed to its 6-bit physical ID if the bus ID in
  264.       the request is either 0x3FF or a bus ID explicitly assigned to the node.
  265.  
  266.       node ID: A 16-bit number that uniquely identifies a Serial Bus node .
  267.       The most significant 10 bits are the bus ID and the least significant 6
  268.       bits are the physical ID.
  269.  
  270.       node unique ID: A 64-bit number that uniquely identifies a node among
  271.       all the Serial Bus nodes manufactured worldwide; also known as the
  272.       EUI-64 (Extended Unique Identifier, 64-bits).
  273.  
  274.       octet: Eight bits of data.
  275.  
  276.       packet: Any of the 1394 primary packets; these may be read, write or
  277.       lock requests (and their responses) or stream data. The term "packet" is
  278.       used consistently to differentiate 1394 packets from ARP or IP
  279.       datagrams, which are also (generically) packets.
  280.  
  281.       physical ID: On a particular bus, this 6-bit number is dynamically
  282.       assigned during the self-identification process and uniquely identifies
  283.       a node on that bus.
  284.  
  285.       quadlet: Four octets, or 32 bits, of data.
  286.  
  287.       stream packet: A 1394 primary packet with a transaction code of 0x0A
  288.       that contains a block data payload. Stream packets may be either
  289.       asynchronous or isochronous according to the type of 1394 arbitration
  290.       employed.
  291.  
  292.  
  293.       2.3 Abbreviations
  294.  
  295.       The following are abbreviations that are used in this standard:
  296.  
  297.          ARP    Address resolution protocol
  298.          CSR    Control and status register
  299.          CRC    Cyclical redundancy checksum
  300.          EUI-64 Extended Unique Identifier, 64-bits (essentially equivalent to
  301.                 names used elsewhere, such as global unique ID or world-wide
  302.                 unique ID)
  303.          IP     Internet protocol (within the context of this document, IPv4)
  304.  
  305.       3. IP-CAPABLE NODES
  306.  
  307.  
  308.  
  309.  
  310.  
  311.       Expires: April, 1998                                            [Page 5]
  312.  
  313.  
  314.       Internet-Draft 04           Ipv4 over 1394                  October 1997
  315.  
  316.  
  317.       Not all 1394 devices are capable of the reception and transmission of
  318.       ARP or IP datagrams. An IP-capable node shall fulfill the following
  319.       minimum 1394 requirements:
  320.  
  321.          - the max_rec field in its bus information block shall be at least 8;
  322.            this indicates an ability to accept write requests with data
  323.            payload of 512 octets. The same ability shall also apply to read
  324.            requests; that is, the node shall be able to transmit a response
  325.            packet with a data payload of 512 octets;
  326.  
  327.  
  328.       4. LINK ENCAPSULATION AND FRAGMENTATION
  329.  
  330.       All IP datagrams (broadcast, unicast or multicast), as well as ARP
  331.       requests and responses, that are transferred via 1394 block write
  332.       requests or stream packets shall be encapsulated within the packet's
  333.       data payload. The maximum size of data payload, in octets, is
  334.       constrained by the speed at which the packet is transmitted.
  335.  
  336.  
  337.                            Table 1 - Maximum data payloads
  338.  
  339.                          Speed   Asynchronous   Isochronous
  340.                        +------------------------------------+
  341.                        |  S100 |      512     |     1024    |
  342.                        |  S200 |     1024     |     2048    |
  343.                        |  S400 |     2048     |     4096    |
  344.                        |  S800 |     4096     |     8192    |
  345.                        | S1600 |     8192     |    16384    |
  346.                        | S3200 |    16384     |    32768    |
  347.                        +------------------------------------+
  348.  
  349.       The maximum data payload may also be restricted by the capabilities of
  350.       the sending or receiving node; this is specified by max_rec in the bus
  351.       information block.
  352.  
  353.       For either of these reasons, the minimum capabilities between any two
  354.       IP-capable nodes may be less than the 2024 octet MTU specified by this
  355.       document. This necessitates 1394 link level fragmentation of IP
  356.       datagrams, which provides for the ordering and reassembly of link
  357.       fragments when necessary.
  358.  
  359.       NOTE: The working group has arrived at rough consensus that link
  360.       encapsulation and fragmentation shall be utilized for all IP datagrams.
  361.       The details of the headers necessary have yet to be determined. As a
  362.       consequence, the remainder of section 6 has been deleted from this
  363.       revision of the working draft; the deleted text has not been marked by
  364.       change bars.
  365.  
  366.       5. ARP
  367.  
  368.       ARP datagrams shall be transmitted by the same means as broadcast IP
  369.       datagrams. The data payload of an Address Resolution Protocol (ARP)
  370.       datagram is 56 octets and shall conform to the format illustrated below.
  371.  
  372.  
  373.       Expires: April, 1998                                            [Page 6]
  374.  
  375.  
  376.       Internet-Draft 04           Ipv4 over 1394                  October 1997
  377.  
  378.  
  379.  
  380.       NOTE: The contents of the ARP datagram are agreed but its exact format
  381.       remains subject to change.
  382.  
  383.                               1                   2                   3
  384.           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
  385.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  386.          | 0 |         reserved          |      ether_type (0x0806)      |
  387.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  388.          |    hardware_type (0x0018)     |    protocol_type (0x0800)     |
  389.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  390.          |  hw_addr_len  |  IP_addr_len  |            opcode             |
  391.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  392.          |                                                               |
  393.          +---                     sender_unique_ID                    ---+
  394.          |                                                               |
  395.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  396.          |         sender_node_ID        |     sender_unicast_FIFO_hi    |
  397.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  398.          |                      sender_unicast_FIFO_lo                   |
  399.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  400.          | sender_max_rec|                    reserved                   |
  401.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  402.          |                        sender_IP_address                      |
  403.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  404.          |                                                               |
  405.          +---                     target_unique_ID                    ---+
  406.          |                                                               |
  407.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  408.          |         target_node_ID        |     target_unicast_FIFO_hi    |
  409.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  410.          |                      target_unicast_FIFO_lo                   |
  411.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  412.          | target_max_rec|                    reserved                   |
  413.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  414.          |                        target_IP_address                      |
  415.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  416.  
  417.                            Figure 4 - ARP datagram format
  418.  
  419.        Field usage in an ARP datagram is as follows:
  420.  
  421.          hardware_type: This field indicates 1394 and shall have a value of
  422.          0x0018.
  423.  
  424.          protocol_type: This field shall have a value of 0x0800; this
  425.          indicates that the protocol addresses in the ARP request or response
  426.          conform to the format for IP addresses.
  427.  
  428.          hw_addr_len: This field indicates the size, in octets, of the 1394-
  429.          dependent hardware address associated with an IP address and shall
  430.          have a value of 20.
  431.  
  432.  
  433.  
  434.  
  435.       Expires: April, 1998                                            [Page 7]
  436.  
  437.  
  438.       Internet-Draft 04           Ipv4 over 1394                  October 1997
  439.  
  440.  
  441.          IP_addr_len: This field indicates the size, in octets, of an IP
  442.          version 4 (IPv4) address and shall have a value of 4.
  443.  
  444.          opcode: This field shall be one to indicate an ARP request and two to
  445.          indicate an ARP response.
  446.  
  447.          sender_unique_ID: This field shall contain the node_unique_ID of the
  448.          sender and shall be equal to that specified in the sender's bus
  449.          information block.
  450.  
  451.          sender_node_ID: This field shall contain the most significant 16 bits
  452.          of the sender's NODE_IDS register.
  453.  
  454.          sender_unicast_FIFO_hi and sender_unicast_FIFO_lo: These fields
  455.          together shall specify the 48-bit offset of the sender's FIFO
  456.          available for the receipt of IP datagrams in the format specified by
  457.          section 6. The offset of a sender's unicast FIFO shall not change,
  458.          either as a result of a bus reset, power reset or other circumstance,
  459.          unless the new FIFO offset is advertised by an unsolicited ARP
  460.          response datagram.
  461.  
  462.          sender_max_rec: This field shall be equal to the value of max_rec in
  463.          the senderÆs configuration ROM bus information block.
  464.  
  465.          sender_IP_address: This field shall specify the IP address of the
  466.          sender.
  467.  
  468.          target_unique_ID: In an ARP request, this field shall be all ones. In
  469.          an ARP response, it shall be set to the value of sender_unique_ID
  470.          from the corresponding ARP request.
  471.  
  472.          target_node_ID: In an ARP request, this field shall be all ones. In
  473.          an ARP response, it shall be set to the value of sender_node_ID from
  474.          the corresponding ARP request.
  475.  
  476.          target_unicast_FIFO_hi and target_unicast_FIFO_lo: In an ARP request,
  477.          these fields shall be all ones. In an ARP response, they shall be set
  478.          to the value of sender_unicast_FIFO_hi and sender_unicast_FIFO_lo
  479.          from the corresponding ARP request.
  480.  
  481.          target_max_rec: In an ARP request, this field shall be zero. In an
  482.          ARP response, it shall be equal to the value of max_rec from the
  483.          corresponding ARP request.
  484.  
  485.          target_IP_address: In an ARP request, this field shall specify the IP
  486.          address from which the responder desires a response. In an ARP
  487.          response, it shall be set to the value of sender_IP_address from the
  488.          corresponding ARP request.
  489.  
  490.       6. IP UNICAST
  491.  
  492.       IP unicast may be transmitted to a recipient within a 1394 primary
  493.       packet that has one of the following transaction codes:
  494.  
  495.  
  496.  
  497.       Expires: April, 1998                                            [Page 8]
  498.  
  499.  
  500.       Internet-Draft 04           Ipv4 over 1394                  October 1997
  501.  
  502.  
  503.                         tcode   Description     Arbitration
  504.                       +--------------------------------------+
  505.                       |  0x01 | Block write   | Asynchronous |
  506.                       |  0x0A | Stream packet | Isochronous  |
  507.                       |  0x0A | Stream packet | Asynchronous |
  508.                       +--------------------------------------+
  509.  
  510.       Block write requests are suitable when 1394 link-level acknowledgement
  511.       of the datagram is desired but there is no need for bounded latency in
  512.       the delivery of the packet (quality of service).
  513.  
  514.       Isochronous stream packets provide quality of service guarantees but not
  515.       1394 link-level acknowledgement.
  516.  
  517.       The last method, asynchronous stream packets, is mentioned only for the
  518.       sake of completeness. This method should not be used, since it provides
  519.       for neither 1394 link-level acknowledgment nor quality of service---and
  520.       consumes a valuable resource, a channel number.
  521.  
  522.       NOTE: Regardless of the IP unicast method employed, asynchronous or
  523.       isochronous, it is the responsibility of the sender of a unicast IP
  524.       datagram to determine the maximum data payload that may be used in each
  525.       packet. The necessary information may be obtained from:
  526.  
  527.          - the SPEED_MAP maintained by the 1394 bus manager and provides a
  528.             maximum transmission speed between any two nodes on the local
  529.             Serial Bus. The speed in turn implies a maximum data payload (see
  530.             Table 1).
  531.  
  532.       NOTE: The SPEED_MAP is derived from the self-ID packets transmitted by
  533.       all 1394 nodes subsequent to a bus reset. An IP-capable node may observe
  534.       the self-ID packets directly;
  535.  
  536.          - the target_max_rec field in an ARP response. This document requires
  537.            a minimum value of 8 (equivalent to a data payload of 512 octets).
  538.            Nodes that operate at S200 and faster are encouraged but not
  539.            required to implement correspondingly larger values for
  540.            target_max_rec; or
  541.  
  542.          - other methods beyond the scope of this standard.
  543.  
  544.       The maximum data payload shall be the minimum of the largest data
  545.       payload implemented by the sender, the recipient and the PHYs of all
  546.       intervening nodes.
  547.  
  548.       6.1 Asynchronous IP unicast
  549.  
  550.       Unicast IP datagrams that do not require any quality of service shall be
  551.       contained within the data payload of 1394 block write transactions
  552.       addressed to the target_node_ID and target_unicast_FIFO obtained from an
  553.       ARP response packet.
  554.  
  555.  
  556.  
  557.  
  558.  
  559.       Expires: April, 1998                                            [Page 9]
  560.  
  561.  
  562.       Internet-Draft 04           Ipv4 over 1394                  October 1997
  563.  
  564.  
  565.       If no acknowledgement is received in response to a unicast block write
  566.       request, the state of the target is ambiguous.
  567.  
  568.       NOTE: An acknowledgment may be absent because the target is no longer
  569.       functional, may not have received the packet because of a header CRC
  570.       error or may have received the packet successfully but the acknowledge
  571.       sent in response was corrupted.
  572.  
  573.       6.2 Isochronous IP unicast
  574.  
  575.       Unicast IP datagrams that require quality of service shall be contained
  576.       within the data payload of 1394 isochronous stream packets.
  577.       The details of coordination between nodes with respect to allocation of
  578.       channel number(s) and bandwidth is beyond the scope of this standard.
  579.  
  580.       7. IP BROADCAST
  581.  
  582.       The 1394 facilities, whether asynchronous stream packets or block write
  583.       requests with a destination_ID of 0xFFFF, have yet to be determined by
  584.       the working group.
  585.  
  586.       The use of asynchronous streams for IP broadcast requires some method
  587.       for the allocation of a channel number and the communication of this
  588.       channel number to all IP-capable nodes. The method has yet to be agreed
  589.       by the working group.
  590.  
  591.       On the other hand, if block write requests with a destination_ID of
  592.       0xFFFF are used, it will be necessary to propose a fixed 48-bit
  593.       destination_offset to IEEE P1394a.
  594.  
  595.  
  596.       8. IP MULTICAST
  597.  
  598.       Many of the details of multicast remain outside the scope of this draft
  599.       in its present form (but are expected to be added by the working group
  600.       as the draft is advanced).
  601.  
  602.       IP multicast shall use stream packets, either asynchronous or
  603.       isochronous, according to the quality of service required.
  604.  
  605.       9. SECURITY CONSIDERATIONS
  606.  
  607.       This document raises no security issues.
  608.  
  609.       10. ACKNOWLEDGEMENTS
  610.  
  611.       This document represents work in progress by the IP / 1394 Working
  612.       Group. The editor wishes to acknowledge the contributions made by all
  613.       the active participants, either on the reflector or at face-to-face
  614.       meetings, which have advanced the technical content.
  615.  
  616.       11. REFERENCES
  617.  
  618.       [1] IEEE Std 1394-1995, Standard for a High Performance Serial Bus
  619.  
  620.  
  621.       Expires: April, 1998                                           [Page 10]
  622.  
  623.  
  624.       Internet-Draft 04           Ipv4 over 1394                  October 1997
  625.  
  626.  
  627.  
  628.       [2] ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture
  629.           for Microcomputer Buses
  630.  
  631.       [3] IEEE Project P1394a, Draft Standard for a High Performance Serial
  632.           Bus (Supplement)
  633.  
  634.       [4] IEEE Project P1394b, Draft Standard for a High Performance Serial
  635.           Bus (Supplement)
  636.  
  637.       12. EDITORÆS ADDRESS
  638.  
  639.       Peter Johansson
  640.       Congruent Software, Inc.
  641.       3998 Whittle Avenue
  642.       Oakland, CA  94602
  643.  
  644.       (510) 531-5472
  645.       (510) 531-2942 FAX
  646.       pjohansson@aol.com
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.       Expires: April, 1998                                           [Page 11]
  684.