rfc2734.txt

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

   Regardless of the IP unicast method employed, asynchronous or
   isochronous, it is the responsibility of the sender of a unicast IP
   datagram to determine the maximum data payload that may be used in
   each packet. The necessary information may be obtained from:

   - the SPEED_MAP maintained by the 1394 bus manager, which provides
     the maximum transmission speed between any two nodes on the local
     Serial Bus. The bus manager analyzes bus topology in order to
     construct the speed map; the maximum transmission speed between
     nodes reflects the capabilities of the intervening nodes. The speed
     in turn implies a maximum data payload (see Table 1);

   - the sender_max_rec field in a 1394 ARP response; or

   - other methods beyond the scope of this standard.

   The maximum data payload SHALL be the minimum of the largest data
   payload implemented by the sender, the recipient and the PHYs of all
   intervening nodes (the last is implicit in the SPEED_MAP entry
   indexed by sender and recipient).






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


   NOTE: The SPEED_MAP is derived from the self-ID packets transmitted
   by all 1394 nodes subsequent to a bus reset. An IP-capable node may
   observe the self-ID packets directly.

   Unicast IP datagrams whose quality of service is best-effort SHALL be
   contained within the data payload of 1394 block write transactions
   addressed to the source_ID and sender_unicast_FIFO obtained from a
   1394 ARP response.

   If no acknowledgement is received in response to a unicast block
   write request it is uncertain whether or not the data payload was
   received by the target.

   NOTE: An acknowledgment may be absent because the target is no longer
   functional, may not have received the packet because of a header CRC
   error or may have received the packet successfully but the
   acknowledge sent in response was corrupted.

   Unicast IP datagrams that require quality of service other than
   best-effort are beyond the scope of this standard.

8. IP BROADCAST

   Broadcast IP datagrams are encapsulated according to the
   specifications of section 4 and are transported by asynchronous
   stream packets. There is no quality of service provision for IP
   broadcast over 1394. The channel number used for IP broadcast is
   specified by the BROADCAST_CHANNEL register.

   All broadcast IP datagrams SHALL use asynchronous stream packets
   whose channel number is equal to the channel field from the
   BROADCAST_CHANNEL register.

   Although 1394 permits the use of previously allocated channel
   number(s) for up to one second subsequent to a bus reset, IP-capable
   nodes SHALL NOT transmit asynchronous stream packets at any time the
   valid bit in their BROADCAST_CHANNEL register is zero. Since the
   valid bit is automatically cleared to zero by a bus reset, this
   prohibits the use of 1394 ARP or broadcast IP until the IRM allocates
   a channel number.

9. IP MULTICAST

   Multicast IP datagrams are encapsulated according to the
   specifications of section 4 and are transported by stream packets.
   Asynchronous streams are used for best-effort IP multicast; quality
   of service other than best-effort is beyond the scope of this
   standard.



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


   By default, all best-effort IP multicast SHALL use asynchronous
   stream packets whose channel number is equal to the channel field
   from the BROADCAST_CHANNEL register. In particular, datagrams
   addressed to 224.0.0.1 and 224.0.0.2 SHALL use this channel number.
   Best-effort IP multicast for other IP multicast group addresses may
   utilize a different channel number if such a channel number is
   allocated and advertised prior to use, as described below.

   IP-capable nodes may transmit best-effort IP multicast only if one of
   the following two conditions is met:

   - the channel number in the stream packet is equal to the channel
     number field in the BROADCAST_CHANNEL register and the valid bit in
     the same register is one; or

   - for other channel number(s), some source of IP multicast has
     allocated and is advertising the channel number used.

   The remainder of this section describes a multicast channel
   allocation protocol (MCAP) employed by both IP multicast sources and
   recipients whenever a channel number other than the default is used.
   MCAP is a cooperative protocol; the participants exchange messages
   over the broadcast channel used by all IP-capable nodes on a
   particular Serial Bus.

   CAUTION: This document does not define facilities and methods for
   shared use of a single channel number (other than the default channel
   number specified by the BROADCAST_CHANNEL register) by more than one
   IP multicast address.

9.1 MCAP message format

   MCAP messages, whether sent by a multicast channel owner or
   recipient, are transported as the data portion of a GASP packet and
   have the format illustrated below. The first four octets of the
   message are fixed; the remainder consists of variable-length tuples,
   each of which encodes information about a particular IP multicast
   group. Individual MCAP messages SHALL NOT be fragmented and SHALL be
   encapsulated within a stream packet as ether_type 0x8861.












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


                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            length             |    reserved   |     opcode    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                          message data                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 10 - MCAP message format

   Field usage in an MCAP message is as follows:

      length: This field SHALL contain the size, in octets, of the
      entire MCAP message.

      opcode: This field SHALL have one of the values specified by the
      table below.

       opcode    Name       Comment
      +----------------------------------------------------------------+
      |   0   | Advertise | Sent by a multicast channel owner to       |
      |       |           | broadcast the current mapping(s) from one  |
      |       |           | or more group addresses to their           |
      |       |           | corresponding channel number(s).           |
      |   1   |  Solicit  | Sent to request multicast channel owner(s) |
      |       |           | to advertise the indicated channel         |
      |       |           | mapping(s) as soon as possible.            |
      +----------------------------------------------------------------+

      message data: The remainder of the MCAP message is variable in
      length and SHALL consist of zero or more group address descriptors
      with the format illustrated below.

















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


                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     length    |      type     |            reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   expiration  |    channel    |     speed     |    reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           bandwidth                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         group_address                         +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 11 - MCAP group address descriptor format

      length: This field SHALL contain the size, in octets, of the MCAP
      group address descriptor.

      type: This field SHALL have a value of one, which indicates a
      group address descriptor.

      expiration: The usage of this field varies according to opcode.
      For solicit messages the expiration field SHALL be IGNORED.
      Otherwise, for advertisements, this field SHALL contain a time-
      stamp, in seconds, that specifies a future time after which the
      channel number specified by channel may no longer be used.

      channel: This field is valid only for advertise messages, in which
      case it SHALL specify an allocated channel number, in the range
      zero to 63 inclusive. All other values are RESERVED.

      speed: This field is valid only for advertise messages, in which
      case it SHALL specify the speed at which stream packets for the
      indicated channel are transmitted. Table 2 specifies the encoding
      used for speed.

      bandwidth: This field SHALL be zero; it is allocated in the group
      address descriptor to accommodate future extensions to MCAP that
      specify quality of service and utilize the isochronous
      capabilities of Serial Bus.

      group_address: This variable length field SHALL specify the IP
      address of a particular IP multicast group. The length of
      group_address, in octets, is derived from the length of the group
      address descriptor by subtracting 12 from the length field.





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


9.2 MCAP message domain

   MCAP messages carry information valid only for the local Serial Bus
   on which they are transmitted. Recipients of MCAP messages SHALL
   IGNORE all MCAP messages from other than the local bus, as follows.
   The source_ID of the sender is contained in the GASP header that
   precedes the encapsulated MCAP message. A recipient of an MCAP
   message SHALL examine the most significant ten bits of source_ID from
   the GASP header; if they are not equal to either 0x3FF or the most
   significant ten bits of the recipient's NODE_IDS register, the
   recipient SHALL IGNORE the message.

   Within an MCAP message domain, the owner of a channel mapping is
   identified by the source_ID field in the GASP header of an MCAP
   advertisement. The owner is the node with the largest physical ID,
   the least significant six bits of source_ID.

9.3 Multicast receive

   An IP-capable device that wishes to receive multicast data SHALL
   first ascertain the channel mapping (if any) that exists between a
   group address and a channel number other than the default channel
   specified by the BROADCAST_CHANNEL register. Such a device may
   observe the MCAP advertisements on the broadcast channel for the
   desired channel mapping(s).

   An intended multicast recipient may transmit MCAP solicitation
   requests in order to request multicast channel owner(s) to broadcast
   advertisements sooner than the next ten second interval. Originators
   of MCAP solicitation requests SHALL limit the rate at which they are
   transmitted. Subsequent to sending a solicitation request, the
   originator SHALL NOT send another MCAP solicitation request until ten
   seconds have elapsed.