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-03.txt < prev    next >
Text File  |  1997-08-21  |  44KB  |  1,056 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.       IETF IP over 1394 Working Group                             P. Johansson
  8.       WG Draft:  03                                                   (Editor)
  9.       Expires in six months                                        August 1997
  10.  
  11.  
  12.  
  13.                                   IP over IEEE 1394
  14.                             (High Performance Serial Bus)
  15.                                      Revision 3
  16.                                    August 21, 1997
  17.  
  18.                              <draft-ietf-ip1394-ipv4-03.txt>
  19.  
  20.  
  21.       STATUS OF THIS DOCUMENT
  22.  
  23.       This document is an Internet-Draft. Internet-Drafts are working
  24.       documents of the Internet Engineering Task Force (IETF), its areas, and
  25.       its working groups. Note that other groups may also distribute working
  26.       documents as Internet-Drafts.
  27.  
  28.       Internet-Drafts are draft documents valid for a maximum of six months
  29.       and may be updated, replaced, or obsoleted by other documents at any
  30.       time. It is inappropriate to use Internet-Drafts as reference material
  31.       or to cite them other than as "work in progress."
  32.  
  33.       To view the entire list of current Internet-Drafts, please check the
  34.       "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  35.       Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
  36.       munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  37.       ftp.isi.edu (US West Coast).
  38.  
  39.       ABSTRACT
  40.  
  41.       This document specifies how to use IEEE Std 1394-1995, Standard for a
  42.       High Performance Serial Bus (and its supplements), for the transport of
  43.       Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary
  44.       methods, data structures and code for that purpose and additionally
  45.       defines a standard method for Address Resolution Protocol (ARP).
  46.  
  47.       EXPIRATION DATE
  48.  
  49.       February, 1998
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.       Expires: February, 1998                                         [Page 1]
  64.  
  65.  
  66.       Internet-Draft 03            IP over 1394                    August 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.................................................6
  76.       3. IP-CAPABLE NODES...................................................6
  77.       4. BROADCAST_IP_CHANNEL...............................................6
  78.       5. IP MANAGER.........................................................7
  79.       6. LINK ENCAPSULATION AND FRAGMENTATION...............................8
  80.          6.1. Link fragment header..........................................9
  81.          6.2. Fragment reassembly..........................................10
  82.       7. ARP...............................................................11
  83.       8. IP UNICAST........................................................14
  84.          8.1. Asynchronous IP unicast......................................15
  85.          8.2. Isochronous IP unicast.......................................15
  86.       9. IP BROADCAST......................................................15
  87.       10. IP MULTICAST.....................................................16
  88.       11. SECURITY CONSIDERATIONS..........................................16
  89.       12. ACKNOWLEDGEMENTS.................................................16
  90.       13. REFERENCES.......................................................16
  91.       14. EDITORÆS ADDRESS.................................................16
  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: February, 1998                                         [Page 2]
  126.  
  127.  
  128.       Internet-Draft 03            IP over 1394                    August 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 code 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 1394.
  149.       Serial Bus is unique in its relevance to both consumer electronic and
  150.       computer domains and is expected to form the basis of a home or small
  151.       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 network.
  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 range from one byte up to a maximum determined by the
  179.       transmission speed (at 100 Mbps, named S100, the maximum asynchronous
  180.       data payload is 512 bytes while at S400 it is 2048 bytes).
  181.  
  182.       NOTE: Extensions underway in IEEE P1394b contemplate additional speeds
  183.       of 800, 1600 and 3200 Mbps; engineering prototypes are planned for early
  184.       1998.
  185.  
  186.  
  187.       Expires: February, 1998                                         [Page 3]
  188.  
  189.  
  190.       Internet-Draft 03            IP over 1394                    August 1997
  191.  
  192.  
  193.  
  194.       2. DEFINITIONS AND NOTATION
  195.  
  196.       2.1. Conformance
  197.  
  198.       Several keywords are used to differentiate levels of requirements and
  199.       optionality, as follows:
  200.  
  201.       expected: A keyword used to describe the behavior of the hardware or
  202.       software in the design models assumed by this standard. Other hardware
  203.       and software design models may also be implemented.
  204.  
  205.       ignored: A keyword that describes bits, bytes, quadlets, octlets or
  206.       fields whose values are not checked by the recipient.
  207.  
  208.       may: A keyword that indicates flexibility of choice with no implied
  209.       preference.
  210.  
  211.       reserved: A keyword used to describe objects-bits, bytes, quadlets,
  212.       octlets and fields-or the code values assigned to these objects in cases
  213.       where either the object or the code value is set aside for future
  214.       standardization. Usage and interpretation may be specified by future
  215.       extensions to this or other standards. A reserved object shall be zeroed
  216.       or, upon development of a future standard, set to a value specified by
  217.       such a standard. The recipient of a reserved object shall not check its
  218.       value. The recipient of a defined object shall check its value and
  219.       reject reserved code values.
  220.  
  221.       shall: A keyword that indicates a mandatory requirement. Designers are
  222.       required to implement all such mandatory requirements to assure
  223.       interoperability with other products conforming to this standard.
  224.  
  225.       should: A keyword that denotes flexibility of choice with a strongly
  226.       preferred alternative. Equivalent to the phrase "is recommended."
  227.  
  228.       2.2. Glossary
  229.  
  230.       The following terms are used in this standard:
  231.  
  232.       address resolution protocol: A method for a requester to determine the
  233.       hardware (1394) address of an IP node from the IP address of the node.
  234.  
  235.       bus ID: A 10-bit number that uniquely identifies a particular bus within
  236.       a group of bridged buses. The bus ID is the most significant portion of
  237.       a node's 16-bit node ID.
  238.  
  239.       byte: Eight bits of data.
  240.  
  241.       doublet: Two bytes, or 16 bits, of data.
  242.  
  243.       link fragment header: A quadlet that precedes all IP datagrams (or
  244.       fragments thereof) when they are transmitted over 1394. See also link
  245.       fragment.
  246.  
  247.  
  248.  
  249.       Expires: February, 1998                                         [Page 4]
  250.  
  251.  
  252.       Internet-Draft 03            IP over 1394                    August 1997
  253.  
  254.  
  255.       local bus ID: A bus ID with the value 0x3FF. A node shall respond to
  256.       transaction requests addressed to its 6-bit physical ID if the bus ID in
  257.       the request is either 0x3FF or a bus ID explicitly assigned to the node.
  258.  
  259.       IP datagram: An Internet message that conforms to the format specified
  260.       by RFC 791. It consists of the 20-byte IP header, options (if they are
  261.       present) and the data that immediately follows.
  262.  
  263.       kilobyte: A quantity of data equal to 2 ** 10 bytes.
  264.  
  265.       link fragment: A portion of an IP datagram transmitted within a single
  266.       1394 packet. The data payload of the 1394 packet contains both a link
  267.       fragment header and its associated link fragment. It is possible to
  268.       transmit datagrams without fragmentation.
  269.  
  270.       node ID: A 16-bit number that uniquely identifies a Serial Bus node
  271.       within a 1394 subnet. The most significant 10 bits are the bus ID and
  272.       the least significant 6 bits are the physical ID.
  273.  
  274.       node unique ID: A 64-bit number that uniquely identifies a node among
  275.       all the Serial Bus nodes manufactured world-wide; also known as the
  276.       EUI-64 (Extended Unique Identifier, 64-bits).
  277.  
  278.       packet: Any of the 1394 primary packets. The term "packet" is used
  279.       consistently to differentiate 1394 packets from ARP or IP datagrams,
  280.       which are also (generically) packets.
  281.  
  282.       physical ID: On a particular bus, this 6-bit number is dynamically
  283.       assigned during the self-identification process and uniquely identifies
  284.       a node on that bus.
  285.  
  286.       quadlet: Four bytes, or 32 bits, of data.
  287.  
  288.       stream packet: A 1394 primary packet with a transaction code of 0x0A
  289.       that contains a block data payload. Stream packets may be either
  290.       asynchronous or isochronous according to the type of 1394 arbitration
  291.       employed.
  292.  
  293.       subnet: Either a single 1394 bus or else two or more 1394 buses with
  294.       uniquely enumerated bus ID's connected by bridges. When a subnet
  295.       consists of only one bus, there is no requirement for the bus ID to be
  296.       anything other than 0x3FF, the local bus ID.
  297.  
  298.       terabyte: A quantity of data equal to 2 ** 40 bytes.
  299.  
  300.       unit: A component of a Serial Bus node that provides processing, memory,
  301.       I/O or some other functionality. Routers, terminal servers and
  302.       workstations are an example of a unit. Once the node is initialized, the
  303.       unit provides a CSR interface that is typically accessed by device
  304.       driver software at an initiator. A node may have multiple units, which
  305.       normally operate independently of each other.
  306.  
  307.       unit architecture: The specification of the interface to and the
  308.       behaviors of a unit implemented within a Serial Bus node.
  309.  
  310.  
  311.       Expires: February, 1998                                         [Page 5]
  312.  
  313.  
  314.       Internet-Draft 03            IP over 1394                    August 1997
  315.  
  316.  
  317.  
  318.       2.3. Abbreviations
  319.  
  320.       The following are abbreviations that are used in this standard:
  321.  
  322.          ARP    Address resolution protocol
  323.          CSR    Control and status register
  324.          CRC    Cyclical redundancy checksum
  325.          EUI-64 Extended Unique Identifier, 64-bits (essentially equivalent to
  326.                 names used elsewhere, such as global unique ID or world-wide
  327.                 unique ID)
  328.          IP     Internet protocol (within the context of this document, IPv4)
  329.  
  330.       3. IP-CAPABLE NODES
  331.  
  332.       Not all 1394 devices are necessarily capable of ARP or the reception and
  333.       transmission of IP datagrams. An IP-capable node shall fulfill the
  334.       following minimum 1394 requirements:
  335.  
  336.          - the max_rec field in its bus information block shall be at least 8;
  337.            this indicates an ability to accept write requests with data
  338.            payload of 512 bytes. The same ability shall also apply to read
  339.            requests; that is, the node shall be able to transmit a response
  340.            packet with a data payload of 512 bytes;
  341.  
  342.          - it shall be isochronous resource manager capable, as specified by
  343.            1394-1995;
  344.  
  345.          - it shall support both reception and transmission of asynchronous
  346.            streams as specified by P1394a; and
  347.  
  348.          - it shall implement the BROADCAST_IP_CHANNEL register.
  349.  
  350.       4. BROADCAST_IP_CHANNEL
  351.  
  352.       This register is required for IP-capable nodes. It shall be located at
  353.       offset 0xFFFF F000 0214 within the node's address space and shall
  354.       support quadlet read and write requests, only. The format of the
  355.       register is shown below.
  356.  
  357.                               1                   2                   3
  358.           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
  359.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  360.          |1|v|               reserved                        |  channel  |
  361.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  362.  
  363.                        Figure 1 - BROADCAST_IP_CHANNEL format
  364.  
  365.       Upon a node power reset or a bus reset, the entire register (with the
  366.       exception of the most significant bit) shall be cleared to zero.
  367.  
  368.       The most significant bit (a constant one) differentiates the presence of
  369.       the BROADCAST_IP_CHANNEL register in an IP manager-capable node from the
  370.  
  371.  
  372.  
  373.       Expires: February, 1998                                         [Page 6]
  374.  
  375.  
  376.       Internet-Draft 03            IP over 1394                    August 1997
  377.  
  378.  
  379.       value (all zeros) returned when offset 0xFFFF F000 0214 is read at
  380.       node(s) that do not implement this register.
  381.  
  382.       The valid bit (abbreviated as v above), when set to one, indicates that
  383.       the channel field contains meaningful information.
  384.  
  385.       NOTE: IP-capable nodes shall not transmit either ARP or broadcast IP
  386.       datagrams until one second after the valid bit is first set to one
  387.       subsequent to a bus reset.
  388.  
  389.       The channel field shall be initialized by the IP manager (see below) to
  390.       identify the channel number shared by IP-capable nodes for ARP, IP
  391.       broadcast and certain IP multicast addresses.
  392.  
  393.       Only the valid bit and the channel field may be changed by quadlet write
  394.       requests; the data value in the write request shall be ignored for all
  395.       other bit positions.
  396.  
  397.       5. IP MANAGER
  398.  
  399.       In order for ARP or broadcast IP datagrams to function on 1394, a
  400.       prerequisite is the presence of an IP manager. Each Serial Bus has its
  401.       own IP manager which performs these functions:
  402.  
  403.          - the allocation of a channel number for ARP and broadcast IP; and
  404.  
  405.          - the communication of that channel number to all IP-capable nodes on
  406.            the same bus.
  407.  
  408.       Without the presence of an IP manager on Serial Bus, IP-capable nodes
  409.       are unable to use the ARP and broadcast IP methods specified by this
  410.       document. If other methods (for example, a search of configuration ROM)
  411.       permit IP-capable nodes to discover each other they may be able to send
  412.       and receive IP datagrams.
  413.  
  414.       Since more than one IP manager-capable nodes may be present, it is
  415.       necessary to select one node from the contenders. Subsequent to any
  416.       Serial Bus reset the new IP manager shall be determined by a distributed
  417.       algorithm executed by all the IP manager-capable nodes. The algorithm is
  418.       straightforward: the IP manager-capable node with the largest 6-bit
  419.       physical ID shall be the IP manager. The steps in the algorithm are as
  420.       follows:
  421.  
  422.         a) An IP manager-capable node shall also a contender for the role of
  423.            isochronous resource manager. The contender bit its self-ID packet
  424.            shall be set to one;
  425.         b) Subsequent to a bus reset, isochronous resource manager contention
  426.            takes place during the self-identification process specified by
  427.            1394-1995;
  428.         c) If the new isochronous resource manager is also IP manager-capable
  429.            it is the new IP manager and shall proceed with g);
  430.         d) An IP manager-capable node that loses contention for the role of
  431.            isochronous resource manager shall wait one second before it
  432.            attempts to become the IP manager. If a write request addressed to
  433.  
  434.  
  435.       Expires: February, 1998                                         [Page 7]
  436.  
  437.  
  438.       Internet-Draft 03            IP over 1394                    August 1997
  439.  
  440.  
  441.            the BROADCAST_IP_CHANNEL register is received before one second
  442.            elapses, another node is the IP manager;
  443.         e) Otherwise, the node shall read the BROADCAST_IP_CHANNEL register of
  444.            any contenders with a larger physical ID (these nodes were
  445.            identified by their self-ID packets). The candidate IP manager
  446.            shall read the BROADCAST_IP_CHANNEL register in the contender with
  447.            the largest physical ID and progress downward. If the register is
  448.            implemented, the IP manager is determined to be a different node.
  449.            The losing contender shall ignore the contents of
  450.            BROADCAST_IP_CHANNEL returned in the read response and shall wait
  451.            for the valid bit of its own register to be set before transmitting
  452.            any ARP or IP datagrams;
  453.         f) If no contender with a physical ID larger than the candidate IP
  454.            manager's physical ID also implemented the BROADCAST_IP_CHANNEL
  455.            register, the search is complete and the candidate becomes the new
  456.            IP manager;
  457.         g) The IP manager shall attempt to allocate a channel number from the
  458.            CHANNELS_AVAILABLE register (note that the IP manager may also be
  459.            the isochronous resource manager). If a channel number is
  460.            allocated, the IP manager shall write this value, along with a
  461.            valid bit of one, to the BROADCAST_IP_CHANNEL register of all the
  462.            IP-capable nodes on the bus. Either a broadcast write request or a
  463.            series of directed write requests may be used to propagate the
  464.            information. Otherwise, if no channel number is available, the IP
  465.            manager shall take no action (all valid bit(s) were cleared by the
  466.            bus reset);
  467.  
  468.       When the IP manager is unable to allocate a channel for ARP and
  469.       broadcast IP, a warning should be communicated to a user that IP
  470.       initialization cannot complete because of a lack of Serial Bus
  471.       resources. The user should be advised to reconfigure or remove other
  472.       devices if she wishes to make use of IP.
  473.  
  474.       6. LINK ENCAPSULATION AND FRAGMENTATION
  475.  
  476.       All IP datagrams (broadcast, unicast or multicast), as well as ARP
  477.       requests and responses, that are transferred via 1394 block write
  478.       requests or stream packets shall be encapsulated within the packet's
  479.       data payload. The maximum size of data payload, in bytes, varies with
  480.       the speed at which the packet is transmitted.
  481.  
  482.  
  483.                            Table 1 - Maximum data payloads
  484.  
  485.                          Speed   Asynchronous   Isochronous
  486.                        +------------------------------------+
  487.                        |  S100 |      512     |     1024    |
  488.                        |  S200 |     1024     |     2048    |
  489.                        |  S400 |     2048     |     4096    |
  490.                        |  S800 |     4096     |     8192    |
  491.                        | S1600 |     8192     |    16384    |
  492.                        | S3200 |    16384     |    32768    |
  493.                        +------------------------------------+
  494.  
  495.  
  496.  
  497.       Expires: February, 1998                                         [Page 8]
  498.  
  499.  
  500.       Internet-Draft 03            IP over 1394                    August 1997
  501.  
  502.  
  503.       The maximum data payload may also be restricted by the capabilities of
  504.       the sending or receiving node; this is specified by max_rec in the bus
  505.       information block.
  506.  
  507.       For either of these reasons, the minimum capabilities between any two
  508.       IP-capable nodes may be less than the 2024 byte MTU specified by this
  509.       document. This necessitates 1394 link level fragmentation of IP
  510.       datagrams, which provides for the ordering and reassembly of link
  511.       fragments when necessary.
  512.  
  513.       NOTE- Link fragmentation is orthogonal to the question of whether or not
  514.       datagrams should be preceded with an additional header, such as
  515.       LLC/SNAP. The usage of LLC/SNAP in the first (or only) fragment of a
  516.       datagram is an open issue that has a bearing on the charter of the IP /
  517.       1394 working group and is not yet resolved.
  518.  
  519.       6.1. Link fragment header
  520.  
  521.       All datagrams transported over 1394 are prefixed by a link fragment
  522.       header with one of the two formats illustrated below.
  523.  
  524.       If an entire IP datagram may be transmitted within a single 1394 packet
  525.       it is unfragmented and the first quadlet of the data payload shall
  526.       conform to the format illustrated below.
  527.  
  528.                               1                   2                   3
  529.           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
  530.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  531.          |         0         |  reserved |           ether_type          |
  532.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  533.  
  534.                    Figure 2 - Unfragmented datagram header format
  535.  
  536.       The ether_type field shall specify the nature of the datagram that
  537.       follows, as specified by the following table.
  538.  
  539.                                 ether_type   Datagram
  540.                               +-----------------------+
  541.                               |    0x800   |    IP    |
  542.                               |    0x806   |   ARP    |
  543.                               +-----------------------+
  544.  
  545.       In cases where the length of the datagram exceeds the maximum data
  546.       payload between any two nodes, the datagram shall be broken into link
  547.       fragments; the first quadlet of the data payload for each link fragment
  548.       shall follow the format shown below.
  549.  
  550.                               1                   2                   3
  551.           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
  552.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  553.          |m| fragment_offset |    dgl    |           signature           |
  554.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  555.  
  556.                     Figure 3 - Fragmented datagram header format
  557.  
  558.  
  559.       Expires: February, 1998                                         [Page 9]
  560.  
  561.  
  562.       Internet-Draft 03            IP over 1394                    August 1997
  563.  
  564.  
  565.  
  566.       The definition and usage of the fields is as follows:
  567.  
  568.          more: If there are other link fragments for the IP datagram whose
  569.          offset value(s) are greater than fragment_offset, the more bit
  570.          (abbreviated as m above) shall be one. When the more bit is zero this
  571.          is the last fragment of the datagram.
  572.  
  573.          For each IP datagram, there shall be exactly one link fragment whose
  574.          more bit is zero.
  575.  
  576.          dgl: The value of dgl shall be the same for all fragments of an IP
  577.          datagram. The sender shall increment the value of dgl for successive,
  578.          fragmented datagrams and the value of dgl shall wrap from 63 back to
  579.          zero. This field shall be assigned a monotonically increasing
  580.          sequence number by the sender of the datagram.
  581.  
  582.          signature: The sender shall assign a signature value to all of its
  583.          link fragments such that signature is reasonably expected to be
  584.          unique among all the IP-capable nodes on the bus. Unless the sender
  585.          has knowledge (beyond the scope of this standard) that a particular
  586.          signature value is unique, the sender shall initialize this field to
  587.          the most significant 16-bits of its own NODE_IDS register.
  588.  
  589.          The value 0xFFFF is reserved and shall not be transmitted in the
  590.          signature field.
  591.  
  592.       NOTE- Although the most common signature value may be the sender's own
  593.       node ID, the recipient of a fragmented datagram shall not impute any
  594.       such meaning and shall use signature only for link fragment reassembly.
  595.  
  596.       All datagrams sent by block write requests or stream packets shall have
  597.       one of the above described link fragment headers as the first quadlet of
  598.       their data payload. This permits uniform software treatment of datagrams
  599.       without regard to the mode of their transmission.
  600.  
  601.       6.2. Fragment reassembly
  602.  
  603.       The recipient of a fragmented datagram shall use both signature and dgl
  604.       for orderly link fragment reassembly. Together, signature and dgl, are
  605.       intended to uniquely all the fragments from a single datagram. The
  606.       recipient shall verify the IP header checksum of the reassembled
  607.       datagram.
  608.  
  609.       Upon receipt of a datagram fragment, the recipient may place the data
  610.       payload (absent the link fragment header) within an IP datagram
  611.       reassembly buffer at the quadlet offset specified by fragment_offset.
  612.       The size of the reassembly buffer may be determined either by a) the MTU
  613.       size of 2024 bytes specified by this standard, b) the total length of
  614.       the datagram as specified by the IP header or c) by other means outside
  615.       of the scope of this standard.
  616.  
  617.       If a datagram fragment is received that overlaps another fragment for
  618.       the same signature and dgl, the fragment(s) already accumulated in the
  619.  
  620.  
  621.       Expires: February, 1998                                        [Page 10]
  622.  
  623.  
  624.       Internet-Draft 03            IP over 1394                    August 1997
  625.  
  626.  
  627.       reassembly buffer shall be discarded and a fresh reassembly commenced
  628.       with the most recently received fragment. Fragment overlap is determined
  629.       by the combination of fragment_offset from the link fragment header and
  630.       data_length from the packet header.
  631.  
  632.       The dgl field is part of the unique identification of an IP datagram; it
  633.       may also invalidate partially reassembled datagram(s) from the same
  634.       sender. For all reassembly buffers whose signature value is equal to the
  635.       signature of a received fragment, the following procedure is followed to
  636.       discard partial datagrams:
  637.  
  638.         a) the two's complement of dgl is added to the value of dgl for each
  639.            partially reassembled datagram and the result is truncated to six
  640.            bits; and
  641.         b) if the most significant bit of the result is one, the partially
  642.            reassembled datagram shall be discarded.
  643.  
  644.       This algorithm eliminates the need for a reassembly time-out on
  645.       individual reassembly buffers. Partially reassembled datagrams whose dgl
  646.       is offset by more than 32 from a newly arrived dgl are discarded.
  647.  
  648.       7. ARP
  649.  
  650.       Address Resolution Protocol (ARP) is accomplished on 1394 by means of
  651.       asynchronous stream packets transmitted with the channel number
  652.       specified by all of the IP-capable nodes' BROADCAST_IP_CHANNEL register.
  653.       The data payload of an ARP datagram is 48 bytes and shall conform to the
  654.       format illustrated below.
  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: February, 1998                                        [Page 11]
  684.  
  685.  
  686.       Internet-Draft 03            IP over 1394                    August 1997
  687.  
  688.  
  689.                               1                   2                   3
  690.           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
  691.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  692.          | 0 |         reserved          |      ether_type (0x0806)      |
  693.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  694.          |    hardware_type (0x0018)     |    protocol_type (0x0800)     |
  695.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  696.          |  hw_addr_len  |  IP_addr_len  |            opcode             |
  697.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  698.          |                                                               |
  699.          +---                     sender_unique_ID                    ---+
  700.          |                                                               |
  701.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  702.          |         sender_node_ID        |     sender_unicast_FIFO_hi    |
  703.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  704.          |                      sender_unicast_FIFO_lo                   |
  705.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  706.          |                        sender_IP_address                      |
  707.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  708.          |                                                               |
  709.          +---                     target_unique_ID                    ---+
  710.          |                                                               |
  711.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  712.          |         target_node_ID        |     target_unicast_FIFO_hi    |
  713.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  714.          |                      target_unicast_FIFO_lo                   |
  715.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  716.          |                        target_IP_address                      |
  717.          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  718.  
  719.                            Figure 4 - ARP datagram format
  720.  
  721.       The first quadlet shown above is the link fragment header already
  722.       described in section 6. Field usage in the remainder of an ARP datagram
  723.       is as follows:
  724.  
  725.          hardware_type: This field indicates 1394 and shall have a value of
  726.          0x0018.
  727.  
  728.          protocol_type: This field shall have a value of 0x0800; this
  729.          indicates that the protocol addresses in the ARP request or response
  730.          conform to the format for IP addresses.
  731.  
  732.          hw_addr_len: This field indicates the size, in bytes, of the 1394-
  733.          dependent hardware address associated with an IP address and shall
  734.          have a value of 16.
  735.  
  736.          IP_addr_len: This field indicates the size, in bytes, of an IP
  737.          version 4 (IPv4) address and shall have a value of 4.
  738.  
  739.          opcode: This field shall be one to indicate an ARP request and two to
  740.          indicate an ARP response.
  741.  
  742.  
  743.  
  744.  
  745.       Expires: February, 1998                                        [Page 12]
  746.  
  747.  
  748.       Internet-Draft 03            IP over 1394                    August 1997
  749.  
  750.  
  751.          sender_unique_ID: This field shall contain the node_unique_ID of the
  752.          sender and shall be equal to that specified in the sender's bus
  753.          information block.
  754.  
  755.          sender_node_ID: This field shall contain the most significant 16 bits
  756.          of the sender's NODE_IDS register.
  757.  
  758.          sender_unicast_FIFO_hi and sender_unicast_FIFO_lo: These fields
  759.          together shall specify the 48-bit offset of the sender's FIFO
  760.          available for the receipt of IP datagrams in the format specified by
  761.          section 8. The offset of a sender's unicast FIFO shall not change,
  762.          either as a result of a bus reset, power reset or other circumstance,
  763.          unless the new FIFO offset is advertised by an unsolicited ARP
  764.          response datagram.
  765.  
  766.          sender_IP_address: This field shall specify the IP address of the
  767.          sender.
  768.  
  769.          target_unique_ID: In an ARP request, this field shall be set to ones.
  770.          In an ARP response, it shall be set to the value of sender_unique_ID
  771.          from the corresponding ARP request.
  772.  
  773.          target_node_ID: In an ARP request, this field shall be set to ones.
  774.          In an ARP response, it shall be set to the value of sender_node_ID
  775.          from the corresponding ARP request.
  776.  
  777.          target_unicast_FIFO_hi and target_unicast_FIFO_lo: In an ARP request,
  778.          these fields shall be set to ones. In an ARP response, they shall be
  779.          set to the value of sender_unicast_FIFO_hi and sender_unicast_FIFO_lo
  780.          from the corresponding ARP request.
  781.  
  782.          target_IP_address: In an ARP request, this field shall specify the IP
  783.          address from which the responder desires a response. In an ARP
  784.          response, it shall be set to the value of sender_IP_address from the
  785.          corresponding ARP request.
  786.  
  787.       Both ARP requests and responses shall be transmitted with the same
  788.       channel number in their stream packet header. This permits nodes other
  789.       than the requester to eavesdrop ARP responses and cache the information.
  790.  
  791.       NOTE: The 16-bit node ID's of any IP-capable nodes are volatile and
  792.       likely to change each time Serial Bus is reset. This could provoke a
  793.       storm of ARP requests and responses subsequent to each bus reset---which
  794.       is also a time when it is extremely desirable for all 1394 applications
  795.       to hold their bus utilization to a minimum. Bus resets are also likely
  796.       to occur in pairs. Because of this, implementers are strongly encouraged
  797.       to make judicious use of ARP requests, both in their timing and
  798.       frequency. Although some strategies may be self-evident, the possible
  799.       impact upon 1394 bus utilization is important enough that they bear
  800.       mention below:
  801.  
  802.          - Flush the ARP cache when a bus reset is observed but defer updates
  803.            until a particular IP address is requested by an application;
  804.  
  805.  
  806.  
  807.       Expires: February, 1998                                        [Page 13]
  808.  
  809.  
  810.       Internet-Draft 03            IP over 1394                    August 1997
  811.  
  812.  
  813.          - Eavesdrop ARP responses; and
  814.  
  815.          - If OS support for 1394 permits, build the ARP cache for the IP
  816.            service layer on the basis of node unique ID (EUI-64) and permit a
  817.            (presumably lower level) 1394 service layer to reestablish the
  818.            correlation between EUI-64 and 16-bit node ID after each reset.
  819.            Because all 1394 applications share the need to maintain a mapping
  820.            between  EUI-64 and node ID it is probable that operating systems
  821.            will provide this facility.
  822.  
  823.       8. IP UNICAST
  824.  
  825.       IP unicast may be transmitted to a recipient within a 1394 primary
  826.       packet that has one of the following transaction codes:
  827.  
  828.                         tcode   Description     Arbitration
  829.                       +--------------------------------------+
  830.                       |  0x01 | Block write   | Asynchronous |
  831.                       |  0x0A | Stream packet | Isochronous  |
  832.                       |  0x0A | Stream packet | Asynchronous |
  833.                       +--------------------------------------+
  834.  
  835.       Block write requests are suitable when 1394 link-level acknowledgement
  836.       of the datagram is desired but there is no need for bounded latency in
  837.       the delivery of the packet (quality of service).
  838.  
  839.       Isochronous stream packets provide quality of service guarantees but not
  840.       1394 link-level acknowledgement.
  841.  
  842.       The last method, asynchronous stream packets, is mentioned only for the
  843.       sake of completeness. This method should not be used, since it provides
  844.       for neither 1394 link-level acknowledgment nor quality of service---and
  845.       consumes a valuable resource, a channel number.
  846.  
  847.       NOTE: Regardless of the IP unicast method employed, asynchronous or
  848.       isochronous, it is the responsibility of the sender of a unicast IP
  849.       datagram to determine the maximum data payload that may be used in each
  850.       packet. The necessary information may be obtained from:
  851.  
  852.          - the SPEED_MAP maintained by the 1394 bus manager. This provides a
  853.            maximum transmission speed between any two nodes on the local
  854.            Serial Bus and is derived from the self-ID packets transmitted by
  855.            all 1394 nodes subsequent to a bus reset;
  856.  
  857.          - the self-ID packets themselves, in the case where no 1394 bus
  858.            manager is present;
  859.  
  860.          - the max_rec field in the target's bus information block. This
  861.            document requires a minimum value of 8 (equivalent to a data
  862.            payload of 512 bytes). Nodes that operate at S200 and faster are
  863.            encouraged but not required to implement correspondingly larger
  864.            values for max_rec; or
  865.  
  866.          - other methods beyond the scope of this standard.
  867.  
  868.  
  869.       Expires: February, 1998                                        [Page 14]
  870.  
  871.  
  872.       Internet-Draft 03            IP over 1394                    August 1997
  873.  
  874.  
  875.  
  876.       8.1. Asynchronous IP unicast
  877.  
  878.       Unicast IP datagrams that do not require any quality of service shall be
  879.       contained within the data payload of 1394 block write transactions
  880.       addressed to the target_node_ID and target_unicast_FIFO obtained from an
  881.       ARP response packet. The first quadlet of the data payload of the block
  882.       write request shall be the link fragment header specified by section 6.
  883.  
  884.       If the IP datagram cannot be encapsulated within a single 1394 packet,
  885.       it shall be split into multiple link fragments for transmission in a
  886.       separate 1394 packet, also specified in section 6.
  887.  
  888.       If no acknowledgement is received in response to a unicast block write
  889.       request, the state of the target is ambiguous. The sender of the IP
  890.       datagram or fragment should either abandon transmission of the datagram
  891.       or retransmit from the first (or only) link fragment. If the datagram is
  892.       retransmitted the sender shall use a different value for dgl.
  893.  
  894.       NOTE: An acknowledgment may be absent because the target is no longer
  895.       functional, may not have received the packet because of a header CRC
  896.       error or may have received the packet successfully but the acknowledge
  897.       sent in response was corrupted.
  898.  
  899.       8.2. Isochronous IP unicast
  900.  
  901.       Unicast IP datagrams that require quality of service shall be contained
  902.       within the data payload of 1394 isochronous stream packets. The first
  903.       quadlet of the data payload of the stream packet shall be the link
  904.       fragment header specified by section 6.
  905.  
  906.       NOTE: Isochronous IP unicast is a degenerate case of IP multicast that
  907.       requires quality of service: a multicast group in which only two nodes
  908.       participate as talker and listener.
  909.  
  910.       The details of coordination between the two nodes with respect to
  911.       allocation of channel number(s) and bandwidth is beyond the scope of
  912.       this standard. The channel number used for isochronous IP unicast shall
  913.       be different from the channel field in the BROADCAST_IP_CHANNEL
  914.       register.
  915.  
  916.       9. IP BROADCAST
  917.  
  918.       Broadcast IP datagrams are encapsulated and fragmented according to the
  919.       specifications of section 6 and are transported by asynchronous stream
  920.       packets. There is no quality of service provision for IP broadcast over
  921.       1394. The channel number used for IP broadcast is specified by the
  922.       BROADCAST_IP_CHANNEL register.
  923.  
  924.       The channel number specified by BROADCAST_IP_CHANNEL is intended for
  925.       datagrams that the sender wishes to transmit to all IP-capable nodes on
  926.       the local bus or subnet. Broadcast addresses include all of the
  927.       following:
  928.  
  929.  
  930.  
  931.       Expires: February, 1998                                        [Page 15]
  932.  
  933.  
  934.       Internet-Draft 03            IP over 1394                    August 1997
  935.  
  936.  
  937.          - TBD: Add list of IP addresses valid for broadcast
  938.  
  939.       All IP datagrams addressed to one of the preceding addresses shall use
  940.       asynchronous stream packets whose channel number is equal to the channel
  941.       field from the BROADCAST_IP_CHANNEL number.
  942.  
  943.       10. IP MULTICAST
  944.  
  945.       Many of the details of multicast remain outside the scope of this draft
  946.       in its present form (but are expected to be added by the working group
  947.       as the draft is advanced).
  948.  
  949.       IP multicast shall use stream packets, either asynchronous or
  950.       isochronous, according to the quality of service required. Unless the
  951.       address of a multicast group is one specified in section 9, the channel
  952.       number used to identify a multicast group shall be different from the
  953.       channel field in the BROADCAST_IP_CHANNEL register.
  954.  
  955.       The coordination of multicast groups, for example, "join" and "leave"
  956.       requests and their affect on the channel number allocation, are
  957.       unresolved.
  958.  
  959.       11. SECURITY CONSIDERATIONS
  960.  
  961.       This document raises no security issues.
  962.  
  963.       12. ACKNOWLEDGEMENTS
  964.  
  965.       This document represents work in progress by the IP / 1394 Working
  966.       Group. The editor wishes to acknowledge the contributions made by all
  967.       the active participants, either on the reflector or at face-to-face
  968.       meetings, that have advanced the technical content.
  969.  
  970.       13. REFERENCES
  971.  
  972.       [1] IEEE Std 1394-1995, Standard for a High Performance Serial Bus
  973.  
  974.       [2] ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture
  975.           for Microcomputer Buses
  976.  
  977.       [3] IEEE Project P1394a, Draft Standard for a High Performance Serial
  978.           Bus (Supplement)
  979.  
  980.       [4] IEEE Project P1394b, Draft Standard for a High Performance Serial
  981.           Bus (Supplement)
  982.  
  983.       14. EDITORÆS ADDRESS
  984.  
  985.       Peter Johansson
  986.       Congruent Software, Inc.
  987.       3998 Whittle Avenue
  988.       Oakland, CA  94602
  989.  
  990.  
  991.  
  992.  
  993.       Expires: February, 1998                                        [Page 16]
  994.  
  995.  
  996.       Internet-Draft 03            IP over 1394                    August 1997
  997.  
  998.  
  999.       (510) 531-5472
  1000.       (510) 531-2942 FAX
  1001.       pjohansson@aol.com
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.  
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.       Expires: February, 1998                                        [Page 17]
  1056.