rfc2734.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,447 行 · 第 1/5 页

   packet SHALL use both the sender's source_ID (obtained from either
   the asynchronous packet header or the GASP header) and dgl to
   identify all the link fragments from a single datagram.

   Upon receipt of a link fragment, the recipient may place the data
   payload (absent the encapsulation header) within an IP datagram
   reassembly buffer at the location specified by fragment_offset. The
   size of the reassembly buffer may be determined from datagram_size.

   If a link fragment is received that overlaps another fragment
   identified by the same source_ID and dgl, the fragment(s) already
   accumulated in the reassembly buffer SHALL be discarded. A fresh
   reassembly may be commenced with the most recently received link
   fragment. Fragment overlap is determined by the combination of
   fragment_offset from the encapsulation header and data_length from
   the 1394 packet header.

   Upon detection of a Serial Bus reset, recipient(s) SHALL discard all
   link fragments of all partially reassembled IP datagrams and
   sender(s) SHALL discard all not yet transmitted link fragments of all
   partially transmitted IP datagrams.

5. SERIAL BUS ADDRESS RESOLUTION PROTOCOL (1394 ARP)

   Methods to determine the hardware address of a device from its
   corresponding IP address are inextricably tied to the transport
   medium utilized by the device. In the description below and
   throughout this document, the acronym 1394 ARP pertains solely to an
   address resolution protocol whose methods and data structures are
   specific to 1394.

   1394 ARP requests SHALL be transmitted by the same means as broadcast
   IP datagrams; 1394 ARP responses MAY be transmitted in the same way
   or they MAY be transmitted as block write requests addressed to the



Johansson                   Standards Track                    [Page 11]

RFC 2734                  IPv4 over IEEE 1394              December 1999


   sender_unicast_FIFO address identified by the 1394 ARP request. A
   1394 ARP request/response is 32 octets and SHALL conform to the
   format illustrated by Figure 5.

                       1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    hardware_type (0x0018)     |    protocol_type (0x0800)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  hw_addr_len  |  IP_addr_len  |            opcode             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +---                     sender_unique_ID                    ---+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | sender_max_rec|      sspd     |     sender_unicast_FIFO_hi    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      sender_unicast_FIFO_lo                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        sender_IP_address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        target_IP_address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 5 - 1394 ARP request/response format

   1394 ARP requests and responses transported by asynchronous stream
   packets SHALL be encapsulated within the GASP format specified by
   IEEE P1394a (see also 4.1). The recipient of a 1394 ARP request or
   response SHALL ignore it unless the most significant ten bits of the
   source_ID field (whether obtained from the GASP header of an
   asynchronous stream packet or the packet header of a block write
   request) are equal to either 0x3FF or the most significant ten bits
   of the recipient's NODE_IDS register.

   Field usage in a 1394 ARP request/response is as follows:

      hardware_type: This field indicates 1394 and SHALL have a value of
      0x0018.

      protocol_type: This field SHALL have a value of 0x0800; this
      indicates that the protocol addresses in the 1394 ARP
      request/response conform to the format for IP addresses.

      hw_addr_len: This field indicates the size, in octets, of the
      1394-dependent hardware address associated with an IP address and
      SHALL have a value of 16.




Johansson                   Standards Track                    [Page 12]

RFC 2734                  IPv4 over IEEE 1394              December 1999


      IP_addr_len: This field indicates the size, in octets, of an IP
      version 4 (IPv4) address and SHALL have a value of 4.

      opcode: This field SHALL be one to indicate a 1394 ARP request and
      two to indicate a 1394 ARP response.

      sender_unique_ID: This field SHALL contain the node unique ID of
      the sender and SHALL be equal to that specified in the sender's
      bus information block.

      sender_max_rec: This field SHALL be equal to the value of max_rec
      in the sender's configuration ROM bus information block.

      sspd: This field SHALL be set to the lesser of the sender's link
      speed and PHY speed. The link speed is the maximum speed at which
      the link may send or receive packets; the PHY speed is the maximum
      speed at which the PHY may send, receive or repeat packets. The
      table below specifies the encoding used for sspd; all values not
      specified are RESERVED for future standardization.

                        Table 2 - Speed codes

                            Value   Speed
                          +---------------+
                          |   0   |  S100 |
                          |   1   |  S200 |
                          |   2   |  S400 |
                          |   3   |  S800 |
                          |   4   | S1600 |
                          |   5   | S3200 |
                          +---------------+

      sender_unicast_FIFO_hi and sender_unicast_FIFO_lo: These fields
      together SHALL specify the 48-bit offset of the sender's FIFO
      available for the receipt of IP datagrams in the format specified
      by section 6. The offset of a sender's unicast FIFO SHALL NOT
      change, except as the result of a power reset.

      sender_IP_address: This field SHALL specify the IP address of the
      sender.

      target_IP_address: In a 1394 ARP request, this field SHALL specify
      the IP address from which the sender desires a response. In a 1394
      ARP response, it SHALL be IGNORED.







Johansson                   Standards Track                    [Page 13]

RFC 2734                  IPv4 over IEEE 1394              December 1999


6. CONFIGURATION ROM

   Configuration ROM for IP-capable nodes SHALL contain a unit directory
   in the format specified by this standard. The unit directory SHALL
   contain Unit_Spec_ID and Unit_SW_Version entries, as specified by
   ISO/IEC 13213:1994.

   The unit directory may also contain other entries permitted by
   ISO/IEC 13213:1994 or IEEE P1212r.

6.1 Unit_Spec_ID entry

   The Unit_Spec_ID entry is an immediate entry in the unit directory
   that specifies the organization responsible for the architectural
   definition of the Internet Protocol capabilities of the device.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x12     |            unit_spec_ID (0x00 005E)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6 - Unit_Spec_ID entry format

   The value of unit_spec_ID SHALL be 0x00 005E, the registration ID
   (RID) obtained by IANA from the IEEE RA. The value indicates that the
   IETF and its technical committees are responsible for the maintenance
   of this standard.

6.2 Unit_SW_Version entry

   The Unit_SW_Version entry is an immediate entry in the unit directory
   that, in combination with the unit_spec_ID, specifies the document
   that defines the software interface of the unit.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x13     |          unit_sw_version (0x00 0001)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 7 - Unit_SW_Version entry format

   The value of unit_sw_version SHALL be one, which indicates that the
   device complies with the normative requirements of this standard.






Johansson                   Standards Track                    [Page 14]

RFC 2734                  IPv4 over IEEE 1394              December 1999


6.3 Textual descriptors

   Textual descriptors within configuration ROM are OPTIONAL; when
   present they provide additional descriptive information intended to
   be intelligible to a human user. IP-capable nodes SHOULD associate a
   textual descriptor with a content of "IANA" with the Unit_Spec_ID
   entry and a textual descriptor with a content of "IPv4" for the
   Unit_SW_Version entry.

   The figure below illustrates a unit directory implemented by an IP-
   capable node; it includes OPTIONAL textual descriptors. Although the
   textual descriptor leaves are not part of the unit directory, for the
   sake of simplicity they are shown immediately following the unit
   directory.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      directory_length (4)     |              CRC              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x12     |            unit_spec_ID (0x00 005E)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x81     |         textual descriptor offset (3)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x13     |                unit_sw_version                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x81     |         textual descriptor offset (5)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | textual_descriptor_length (3) |              CRC              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +---                          zeros                          ---+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      "I"      |      "A"      |      "N"      |      "A"      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | textual_descriptor_length (3) |              CRC              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +---                          zeros                          ---+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      "I"      |      "P"      |      "v"      |      "4"      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 9 - Sample unit directory and textual descriptors





Johansson                   Standards Track                    [Page 15]

RFC 2734                  IPv4 over IEEE 1394              December 1999


7. IP UNICAST

   A unicast IP datagram may be transmitted to a recipient within a 1394
   primary packet that has one of the following transaction codes:

              tcode   Description     Arbitration
            +--------------------------------------+
            |  0x01 | Block write   | Asynchronous |
            |  0x0A | Stream packet | Isochronous  |
            |  0x0A | Stream packet | Asynchronous |
            +--------------------------------------+

   Block write requests are suitable when 1394 link-level
   acknowledgement is desired but there is no need for bounded latency
   in the delivery of the packet (quality of service).

   Isochronous stream packets provide quality of service guarantees but
   no 1394 link-level acknowledgement.

   The last method, asynchronous stream packets, is mentioned only for
   the sake of completeness. This method SHOULD NOT be used for IP
   unicast, since it provides for neither 1394 link-level acknowledgment
   nor quality of service---and consumes a valuable resource, a channel
   number.