rfc2734.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      MCAP     Multicast channel allocation protocol

2.4 Numeric values

   Decimal and hexadecimal numbers are used within this standard. By
   editorial convention, decimal numbers are most frequently used to
   represent quantities or counts. Addresses are uniformly represented
   by hexadecimal numbers, which are also used when the value
   represented has an underlying structure that is more apparent in a
   hexadecimal format than in a decimal format.

   Decimal numbers are represented by Arabic numerals or by their
   English names. Hexadecimal numbers are prefixed by 0x and represented
   by digits from the character set 0 - 9 and A - F. For the sake of
   legibility, hexadecimal numbers are separated into groups of four
   digits separated by spaces.

   For example, both 42 and 0x2A represent the same numeric value.

3. IP-CAPABLE NODES

   Not all Serial Bus devices are capable of the reception and
   transmission of 1394 ARP requests/responses or IP datagrams. An IP-
   capable node SHALL fulfill the following minimum requirements:

   - it SHALL implement configuration ROM in the general format
     specified by ISO/IEC 13213:1994 and SHALL implement the bus
     information block specified by IEEE P1394a and a unit directory
     specified by this standard;

   - the max_rec field in its bus information block SHALL be at least 8;
     this indicates an ability to accept block write requests and
     asynchronous stream packets with data payload of 512 octets. The
     same ability SHALL also apply to read requests; that is, the node
     SHALL be able to transmit a block response packet with a data
     payload of 512 octets;





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


   - it SHALL be isochronous resource manager capable, as specified by
     IEEE P1394a;

   - it SHALL support both reception and transmission of asynchronous
     streams as specified by IEEE P1394a; and

4. LINK ENCAPSULATION AND FRAGMENTATION

   All IP datagrams (broadcast, unicast or multicast), 1394 ARP
   requests/responses and MCAP advertisements/solicitations that are
   transferred via 1394 block write requests or stream packets SHALL be
   encapsulated within the packet's data payload. The maximum size of
   data payload, in octets, is constrained by the speed at which the
   packet is transmitted.

               Table 1 - Maximum data payloads (octets)

                  Speed   Asynchronous   Isochronous
                +------------------------------------+
                |  S100 |      512     |     1024    |
                |  S200 |     1024     |     2048    |
                |  S400 |     2048     |     4096    |
                |  S800 |     4096     |     8192    |
                | S1600 |     8192     |    16384    |
                | S3200 |    16384     |    32768    |
                +------------------------------------+

   NOTE: The maximum data payloads at speeds of S800 and faster may be
   reduced (but will not be increased) as a result of standardization by
   IEEE P1394b.

   The maximum data payload for asynchronous requests and responses may
   also be restricted by the capabilities of the sending or receiving
   node(s); this is specified by max_rec in either the bus information
   block or 1394 ARP response.

   For either of these reasons, the maximum data payload transmissible
   between IP-capable nodes may be less than the default 1500 octet
   maximum transmission unit (MTU) specified by this document. This
   requires that the encapsulation format also permit 1394 link-level
   fragmentation and reassembly of IP datagrams.

   NOTE: IP-capable nodes may operate with an MTU size larger than the
   default, but the means by which a larger MTU is configured are beyond
   the scope of this document.






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


4.1 Global asynchronous stream packet (GASP) format

   Some IP datagrams, as well as 1394 ARP requests and responses, may be
   transported via asynchronous stream packets. When asynchronous stream
   packets are used, their format SHALL conform to the global
   asynchronous stream packet (GASP) format specified by IEEE P1394a.
   The GASP format illustrated below is INFORMATIVE and reproduced for
   ease of reference, only.

                       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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          data_length          |tag|  channel  |  0x0A |   sy  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           header_CRC                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           source_ID           |        specifier_ID_hi        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |specifier_ID_lo|                    version                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +---                           data                          ---+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            data_CRC                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 1 - GASP format

   The source_ID field SHALL specify the node ID of the sending node and
   SHALL be equal to the most significant 16 bits of the sender's
   NODE_IDS register.

   The specifier_ID_hi and specifier_ID_lo fields together SHALL contain
   the value 0x00 005E, the 24-bit organizationally unique identifier
   (OUI) assigned by the IEEE Registration Authority (RA) to IANA.

   The version field SHALL be one.

   NOTE: Because the GASP format utilizes the first two quadlets of data
   payload in an asynchronous stream packet format, the maximum payloads
   cited in Table 1 are effectively reduced by eight octets. In the
   clauses that follow, references to the first quadlet of data payload
   mean the first quadlet usable for an IP datagram or 1394 ARP request
   or response.  When the GASP format is used, this is the third quadlet
   of the data payload for the packet.





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


4.2 Encapsulation header

   All IP datagrams transported over 1394 are prefixed by an
   encapsulation header with one of the formats illustrated below.

   If an entire IP datagram may be transmitted within a single 1394
   packet, it is unfragmented and the first quadlet of the data payload
   SHALL conform to the format illustrated below.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | lf|          reserved         |           ether_type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 2 - Unfragmented encapsulation header format

   The lf field SHALL be zero.

   The ether_type field SHALL indicate the nature of the datagram that
   follows, as specified by the following table.

                      ether_type   Datagram
                    +-------------------------+
                    |   0x0800   |   IPv4     |
                    |   0x0806   |   1394 ARP |
                    |   0x8861   |   MCAP     |
                    +-------------------------+

   NOTE: Other network protocols, identified by different values of
   ether_type, may use the encapsulation formats defined herein but such
   use is outside of the scope of this document.

   In cases where the length of the datagram exceeds the maximum data
   payload supported by the sender and all recipients, the datagram
   SHALL be broken into link fragments; the first two quadlets of the
   data payload for the first link fragment SHALL conform to the format
   shown below.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | lf|rsv|      datagram_size    |           ether_type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              dgl              |            reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 3 - First fragment encapsulation header format



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


   The second and subsequent link fragments (up to and including the
   last) SHALL conform to the format shown below.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | lf|rsv|      datagram_size    |  rsv  |    fragment_offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              dgl              |            reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 4 - Subsequent fragment(s) encapsulation header format

   The definition and usage of the fields is as follows:

      The lf field SHALL specify the relative position of the link
      fragment within the IP datagram, as encoded by the following
      table.

                        lf      Position
                     +------------------------+
                     |   0   |  Unfragmented  |
                     |   1   |  First         |
                     |   2   |  Last          |
                     |   3   |  Interior      |
                     +------------------------+

      datagram_size: The encoded size of the entire IP datagram. The
      value of datagram_size SHALL be the same for all link fragments of
      an IP datagram and SHALL be one less than the value of Total
      Length in the datagram's IP header (see STD 5, RFC 791).

      ether_type: This field is present only in the first link fragment
      and SHALL have a value of 0x0800, which indicates an IPv4
      datagram.

      fragment_offset: This field is present only in the second and
      subsequent link fragments and SHALL specify the offset, in octets,
      of the fragment from the beginning of the IP datagram. The first
      octet of the datagram (the start of the IP header) has an offset
      of zero; the implicit value of fragment_offset in the first link
      fragment is zero.









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


      dgl: The value of dgl (datagram label) SHALL be the same for all
      link fragments of an IP datagram. The sender SHALL increment dgl
      for successive, fragmented datagrams; the incremented value of dgl
      SHALL wrap from 65,535 back to zero.

   All IP datagrams, regardless of the mode of transmission (block write
   requests or stream packets) SHALL be preceded by one of the above
   described encapsulation headers. This permits uniform software
   treatment of datagrams without regard to the mode of their
   transmission.

4.3 Link fragment reassembly

   The recipient of an IP datagram transmitted via more than one 1394
   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