doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc2734.txt b/doc/rfc/rfc2734.txt
new file mode 100644
index 0000000..50c4e30
--- /dev/null
+++ b/doc/rfc/rfc2734.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                       P. Johansson
+Request for Comments: 2734                      Congruent Software, Inc.
+Category: Standards Track                                  December 1999
+
+
+                          IPv4 over IEEE 1394
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+ABSTRACT
+
+   This document specifies how to use IEEE Std 1394-1995, Standard for a
+   High Performance Serial Bus (and its supplements), for the transport
+   of Internet Protocol Version 4 (IPv4) datagrams; it defines the
+   necessary methods, data structures and codes for that purpose. These
+   include not only packet formats and encapsulation methods for
+   datagrams, but also an address resolution protocol (1394 ARP) and a
+   multicast channel allocation protocol (MCAP). Both 1394 ARP and MCAP
+   are specific to Serial Bus; the latter permits management of Serial
+   Bus resources when used by IP multicast groups.
+
+TABLE OF CONTENTS
+
+   1. INTRODUCTION.....................................................2
+   2. DEFINITIONS AND NOTATION.........................................4
+      2.1 Conformance..................................................4
+      2.2 Glossary.....................................................4
+      2.3 Abbreviations................................................6
+      2.4 Numeric values...............................................6
+   3. IP-CAPABLE NODES.................................................6
+   4. LINK ENCAPSULATION AND FRAGMENTATION.............................7
+      4.1 Global asynchronous stream packet (GASP) format..............8
+      4.2 Encapsulation header.........................................9
+      4.3 Link fragment reassembly....................................11
+   5. SERIAL BUS ADDRESS RESOLUTION PROTOCOL (1394 ARP)...............11
+   6. CONFIGURATION ROM...............................................14
+      6.1 Unit_Spec_ID entry..........................................14
+      6.2 Unit_SW_Version entry.......................................14
+
+
+
+Johansson                   Standards Track                     [Page 1]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+      6.3 Textual descriptors.........................................15
+   7. IP UNICAST......................................................16
+   8. IP BROADCAST....................................................17
+   9. IP MULTICAST....................................................17
+      9.1 MCAP message format.........................................18
+      9.2 MCAP message domain.........................................21
+      9.3 Multicast receive...........................................21
+      9.4 Multicast transmit..........................................22
+      9.5 Advertisement of channel mappings...........................23
+      9.6 Overlapped channel mappings.................................23
+      9.7 Transfer of channel ownership...............................24
+      9.8 Redundant channel mappings..................................25
+      9.9 Expired channel mappings....................................25
+      9.10 Bus reset..................................................26
+   10. IANA CONSIDERATIONS............................................26
+   11. SECURITY CONSIDERATIONS........................................27
+   12. ACKNOWLEDGEMENTS...............................................27
+   13. REFERENCES.....................................................28
+   14. EDITOR'S ADDRESS...............................................28
+   15. Full Copyright Statement.......................................29
+
+1. INTRODUCTION
+
+   This document specifies how to use IEEE Std 1394-1995, Standard for a
+   High Performance Serial Bus (and its supplements), for the transport
+   of Internet Protocol Version 4 (IPv4) datagrams. It defines the
+   necessary methods, data structures and codes for that purpose and
+   additionally defines methods for an address resolution protocol (1394
+   ARP) and a multicast channel allocation protocol (MCAP)---both of
+   which are specific to Serial Bus.
+
+   The group of IEEE standards and supplements, draft or approved,
+   related to IEEE Std 1394-1995 is hereafter referred to either as 1394
+   or as Serial Bus.
+
+   1394 is an interconnect (bus) that conforms to the CSR architecture,
+   ISO/IEC 13213:1994. Serial Bus permits communications between nodes
+   over shared physical media at speeds that range, at present, from 100
+   to 400 Mbps. Both consumer electronic applications (such as digital
+   VCRs, stereo systems, televisions and camcorders) and traditional
+   desktop computer applications (e.g., mass storage, printers and
+   tapes), have adopted 1394. Serial Bus is unique in its relevance to
+   both consumer electronic and computer domains and is EXPECTED to form
+   the basis of a home or small office network that combines both types
+   of devices.
+
+
+
+
+
+
+Johansson                   Standards Track                     [Page 2]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+   The CSR architecture describes a memory-mapped address space that
+   Serial Bus implements as a 64-bit fixed addressing scheme. Within the
+   address space, ten bits are allocated for bus ID (up to a maximum of
+   1,023 buses), six are allocated for node physical ID (up to 63 per
+   bus) while the remaining 48 bits (offset) describe a per node address
+   space of 256 terabytes. The CSR architecture, by convention, splits a
+   node's address space into two regions with different behavioral
+   characteristics. The lower portion, up to but not including 0xFFFF
+   F000 0000, is EXPECTED to behave as memory in response to read and
+   write transactions. The upper portion is more like a traditional IO
+   space: read and write transactions in this area usually have side
+   effects. Control and status registers (CSRs) that have FIFO behavior
+   customarily are implemented in this region.
+
+   Within the 64-bit address, the 16-bit node ID (bus ID and physical
+   ID) is analogous to a network hardware address---but 1394 node IDs
+   are variable and subject to reassignment each time one or more nodes
+   are added to or removed from the bus.
+
+   NOTE: Although the 16-bit node ID contains a bus ID, at present there
+   is no standard method to connect separately enumerated Serial Buses.
+   Active development of a standard for Serial Bus to Serial Bus bridges
+   is underway in the IEEE P1394.1 working group. Unless extended by
+   some future standard, the IPv4 over 1394 protocols specified by this
+   document may not operate correctly across bridges.
+
+   The 1394 link layer provides a packet delivery service with both
+   confirmed (acknowledged) and unconfirmed packets. Two levels of
+   service are available: "asynchronous" packets are sent on a best-
+   effort basis while "isochronous" packets are guaranteed to be
+   delivered with bounded latency. Confirmed packets are always
+   asynchronous but unconfirmed packets may be either asynchronous or
+   isochronous. Data payloads vary with implementations and may range
+   from one octet up to a maximum determined by the transmission speed
+   (at 100 Mbps, named S100, the maximum asynchronous data payload is
+   512 octets while at S400 it is 2048 octets).
+
+   NOTE: Extensions underway in IEEE P1394b contemplate additional
+   speeds of 800, 1600 and 3200 Mbps.
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                   Standards Track                     [Page 3]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+2. DEFINITIONS AND NOTATION
+
+2.1 Conformance
+
+   When used in this document, the keywords "MAY", "OPTIONAL",
+   "RECOMMENDED", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD" and "SHOULD
+   NOT" differentiate levels of requirements and optionality and are to
+   be interpreted as described in RFC 2119.
+
+   Several additional keywords are employed, as follows:
+
+   EXPECTED: A keyword used to describe the behavior of the hardware or
+   software in the design models assumed by this standard. Other
+   hardware and software design models may also be implemented.
+
+   IGNORED: A keyword that describes bits, octets, quadlets or fields
+   whose values are not checked by the recipient.
+
+   RESERVED: A keyword used to describe either objects---bits, octets,
+   quadlets and fields---or the code values assigned to these objects;
+   the object or the code value is set aside for future standardization.
+   A RESERVED object has no defined meaning and SHALL be zeroed by its
+   originator or, upon development of a future standard, set to a value
+   specified by such a standard. The recipient of a RESERVED object
+   SHALL NOT check its value. The recipient of an object whose code
+   values are defined by this standard SHALL check its value and reject
+   RESERVED code values.
+
+2.2 Glossary
+
+   The following terms are used in this standard:
+
+   address resolution protocol: A method for a requester to determine
+   the hardware (1394) address of an IP node from the IP address of the
+   node.
+
+   bus ID: A 10-bit number that uniquely identifies a particular bus
+   within a group of multiple interconnected buses. The bus ID is the
+   most significant portion of a node's 16-bit node ID. The value 0x3FF
+   designates the local bus; a node SHALL respond to requests addressed
+   to its 6-bit physical ID if the bus ID in the request is either 0x3FF
+   or the bus ID explicitly assigned to the node.
+
+   encapsulation header: A structure that precedes all IP data
+   transmitted over 1394. See also link fragment.
+
+   IP datagram: An Internet message that conforms to the format
+   specified by STD 5, RFC 791.
+
+
+
+Johansson                   Standards Track                     [Page 4]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+   link fragment: A portion of an IP datagram transmitted within a
+   single 1394 packet. The data payload of the 1394 packet contains both
+   an encapsulation header and its associated link fragment. It is
+   possible to transmit datagrams without link fragmentation.
+
+   multicast channel allocation protocol: A method for multicast groups
+   to coordinate their use of Serial Bus resources (channels) if
+   multicast datagrams are transmitted on other than the default
+   broadcast channel.
+
+   multicast channel owner: A multicast source that has allocated a
+   channel for one or more multicast addresses and transmits MCAP
+   advertisements to communicate these channel mapping(s) to other
+   participants in the IP multicast group. When more than one source
+   transmits MCAP advertisements for the same channel number, the source
+   with the largest physical ID is the owner.
+
+   node ID: A 16-bit number that uniquely identifies a Serial Bus node
+   within a group of multiple interconnected buses. The most significant
+   ten bits are the bus ID and the least significant six bits are the
+   physical ID.
+
+   node unique ID: A 64-bit number that uniquely identifies a node among
+   all the Serial Bus nodes manufactured worldwide; also known as the
+   EUI-64 (Extended Unique Identifier, 64-bits).
+
+   octet: Eight bits of data.
+
+   packet: Any of the 1394 primary packets; these may be read, write or
+   lock requests (and their responses) or stream data. The term "packet"
+   is used consistently to differentiate Serial Bus primary packets from
+   1394 ARP requests/responses, IP datagrams or MCAP
+   advertisements/solicitations.
+
+   physical ID: On a particular bus, this 6-bit number is dynamically
+   assigned during the self-identification process and uniquely
+   identifies a node on that bus.
+
+   quadlet: Four octets, or 32 bits, of data.
+
+   stream packet: A 1394 primary packet with a transaction code of 0x0A
+   that contains a block data payload. Stream packets may be either
+   asynchronous or isochronous according to the type of 1394 arbitration
+   employed.
+
+
+
+
+
+
+
+Johansson                   Standards Track                     [Page 5]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+2.3 Abbreviations
+
+   The following are abbreviations that are used in this standard:
+
+      1394 ARP Address resolution protocol (specific to 1394)
+      CSR      Control and status register
+      CRC      Cyclical redundancy checksum
+      EUI-64   Extended Unique Identifier, 64-bits
+      GASP     Global asynchronous stream packet
+      IP       Internet protocol (within this document, IPv4)
+      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
+   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.
+
+   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.
+
+   In either case, if a mapping exists for the group address for other
+   than the default channel, an MCAP advertise message is EXPECTED
+   within ten seconds. Upon receipt of an MCAP advertise message that
+   describes one or more channel mappings, the intended multicast
+   recipient may receive IP datagrams on the indicated channel number(s)
+   until the expiration time.
+
+   If multiple MCAP advertise messages are observed that specify the
+   same group address, the channel number SHALL be obtained from the
+   advertisement message with the largest physical ID, which SHALL be
+   obtained from the least significant six bits of source_ID from the
+   GASP header.
+
+
+
+
+
+Johansson                   Standards Track                    [Page 21]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+   If no MCAP advertise message is received for a particular group
+   address within ten seconds, no multicast source(s) are active for
+   channel(s) other than the default. Either there is there is no
+   multicast data or it is being transmitted on the default channel.
+
+   Once a multicast recipient has observed an advertisement for the
+   desired group address, it MAY receive multicast data on either the
+   default broadcast channel or the channel number(s) indicated but it
+   SHALL continue to monitor the default broadcast channel for MCAP
+   advertisements for the same group address in order to refresh the
+   expiration time of channel number(s) in use.
+
+9.4 Multicast transmit
+
+   An IP-capable device that wishes to transmit multicast data on other
+   than the default channel SHALL first ascertain whether or not another
+   multicast source has already allocated a channel number for the group
+   address. The intended multicast source may transmit an MCAP
+   solicitation request with one or more group address descriptors.
+
+   Whether or not a solicitation request has been transmitted, the
+   intended multicast source SHALL monitor the broadcast channel for
+   MCAP advertisements. If a channel mapping already exists for the
+   group address, an MCAP advertisement SHOULD be received within ten
+   seconds. In this case the intended multicast source may commence
+   transmission of IP datagrams on the indicated channel number(s) and
+   may continue to do so until their expiration time. The multicast
+   source SHALL monitor MCAP advertisements in order to refresh the
+   expiration time of channel number(s) in use.
+
+   When no other multicast source has established a channel mapping for
+   the group address, the intended multicast source may attempt to
+   allocate a channel number from the isochronous resource manager's
+   CHANNELS_AVAILABLE register according to the procedures described in
+   IEEE P1394a. If the channel number allocation is successful, the
+   multicast source SHALL advertise the new channel mapping(s) as soon
+   as possible. Once 100 ms elapses subsequent to the initial
+   advertisement of a newly allocated channel number , the multicast
+   source may transmit IP datagrams using the channel number advertised.
+
+   Multicast IP datagrams may be transmitted on the default channel
+   until the sender observes (or transmits) an advertisement that
+   specifies non- default channel mapping(s) for the multicast
+   addresses. This permits the smooth transition of multicast from the
+   default channel to an explicitly allocated channel.
+
+
+
+
+
+
+Johansson                   Standards Track                    [Page 22]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+   Once a multicast source has advertised a channel mapping, it SHALL
+   continue to transmit MCAP advertisements for the channel mapping
+   unless it either a) transfers ownership to another multicast source,
+   b) permits the channel mapping to expire without transfer or c) in
+   the case of overlapped channel mappings, relinquishes control of the
+   channel mapping to another multicast source.
+
+9.5 Advertisement of channel mappings
+
+   Each multicast source SHALL periodically broadcast an advertisement
+   of all IP multicast group addresses for which it has allocated a
+   channel number different from the default multicast channel number.
+   An advertisement SHALL consist of a single MCAP message with an
+   opcode of zero that contains one or more group address descriptors
+   (one for each group address assigned a channel number other than that
+   specified by the BROADCAST_CHANNEL register).
+
+   Within each group address descriptor, the group_address and channel
+   fields associate an IP multicast group address with a Serial Bus
+   channel number. The speed field specifies the maximum 1394 speed at
+   which any of the senders within the IP multicast group is permitted
+   to transmit data.  The expiration field specifies the current time or
+   a future time after which the channel mapping(s) are no longer valid.
+   Except when a channel owner intends to relinquish ownership (as
+   described in 9.7 below), the expiration time SHALL be at least 60
+   seconds in the future measured from the time the advertisement is
+   transmitted.
+
+   No more than ten seconds SHALL elapse from the transmission of its
+   most recent advertisement before the owner of a channel mapping
+   initiates transmission of the subsequent advertisement. The owner of
+   a channel mapping SHOULD transmit an MCAP advertisement in response
+   to a solicitation as soon as possible after the receipt of the
+   request.
+
+9.6 Overlapped channel mappings
+
+   When two intended multicast sources wish to transmit to the same IP
+   multicast group and no channel mapping exists for the group address,
+   there is a chance that both will allocate channel numbers and both
+   will advertise the channel mappings. These channel mappings overlap,
+   i.e., the same group address is mapped to more than one channel
+   number in MCAP advertisements with nonzero expiration times.
+
+   Multicast channel owners SHALL monitor MCAP advertisements in order
+   to detect overlapped channel mappings. MCAP advertisements whose
+   expiration field has a value less than 60 SHALL be ignored for the
+   purpose of overlapped channel detection. When an overlapped channel
+
+
+
+Johansson                   Standards Track                    [Page 23]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+   mapping is detected, the owner with the largest physical ID (as
+   determined by the least significant six bits of source_ID from the
+   GASP header) is NOT REQUIRED to take any action. The channel numbers
+   advertised by owners with smaller physical IDs are invalid; their
+   owners SHALL cease transmission of both IP datagrams and MCAP
+   advertisements that use the invalid channel numbers. As soon as these
+   channel mappings expire , their owners SHALL deallocate any unused
+   channel numbers as described in 9.8 below.
+
+   Recipients of MCAP advertisements that detect overlapped channel
+   mappings SHALL ignore the advertisements from multicast channel
+   owner(s) with the smaller physical IDs and SHALL NOT transmit IP
+   datagrams that use the invalid channel number. It is possible for
+   some channel mappings in a single MCAP advertisement to be valid even
+   if others SHALL be IGNORED as a result of overlap.
+
+9.7 Transfer of channel ownership
+
+   The owner of a channel mapping may cease multicast transmission on a
+   particular channel, in which case it SHOULD invalidate the channel
+   mapping and in some cases deallocate the channel number. Because
+   other multicast sources may be using the same channel mapping, an
+   orderly process is defined to transfer channel ownership.
+
+   The owner of an existing channel mapping that wishes to release the
+   mapping SHALL commence a timer to measure the time remaining before
+   the anticipated release of the mapping and its associated channel.
+   Until the timer counts down to zero, the owner SHOULD continue to
+   transmit MCAP advertisements for the affected channel but SHALL
+   adjust expiration in each advertisement to reflect the time remaining
+   until the channel is to be deallocated. If the owner is unable to
+   transmit MCAP advertisements until the timer reaches zero, it SHALL
+   initiate a bus reset. Otherwise, the sequence of expiration times
+   transmitted by the owner intending to release the mapping SHALL
+   decrease with each succeeding advertisement.  If other multicast
+   source(s) are using the same channel mapping and observe an
+   expiration time less than or equal to 60 seconds, they SHALL commence
+   transmitting MCAP advertisements for the channel mapping with
+   refreshed expiration times greater than or equal to 60 seconds that
+   maintain the channel mapping. Any contention that occurs between
+   multiple sources that attempt to claim ownership of the channel
+   mapping SHALL be resolved as described in 9.8. If the original owner
+   observes an MCAP advertisement for the channel to be relinquished
+   before its own timer has expired, it SHALL NOT deallocate the channel
+   number.
+
+
+
+
+
+
+Johansson                   Standards Track                    [Page 24]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+   Otherwise, if the owner's timer expires without the observation of a
+   MCAP advertisement by another node, the owner of the channel number
+   SHALL subsequently deallocate the channel as described in 9.8. If the
+   intended owner of the channel mapping observes an MCAP advertisement
+   whose expiration field is zero, orderly transfer of the channel(s)
+   from the former owner has failed. The intended owner SHALL either
+   stop reception and transmission on the expired channel number(s) or
+   allocate different channel number(s) as specified by 9.4.
+
+9.8 Redundant channel mappings
+
+   When ownership of a channel mapping is transferred from one multicast
+   source to another, it is possible for more than one device to claim
+   ownership. This results in redundant MCAP advertisements, transmitted
+   by different sources, each of which specifies the same multicast
+   group address and channel. A procedure similar to that of 9.6 SHALL
+   resolve the contention for channel ownership.
+
+   Multicast channel owners SHALL monitor MCAP advertisements in order
+   to detect redundant channel mappings. MCAP advertisements whose
+   expiration field has a value less than 60 SHALL be ignored for the
+   purpose of redundant channel detection. When a redundant channel
+   mapping is detected, the owner with the largest physical ID (as
+   determined by the least significant six bits of source_ID from the
+   GASP header) is NOT REQUIRED to take any action. The owner(s) with
+   smaller physical IDs SHALL cease transmission of MCAP advertisements
+   for the redundant channel number but SHALL NOT deallocate the channel
+   number.
+
+9.9 Expired channel mappings
+
+   A channel mapping expires when expiration seconds have elapsed since
+   the most recent MCAP advertisement. At this time, multicast
+   recipients SHALL stop reception on the expired channel number(s).
+   Also at this time, the owner of the channel mapping(s) SHALL transmit
+   an MCAP advertisement with expiration cleared to zero and SHALL
+   continue to transmit such advertisements until 30 seconds have
+   elapsed since the expiration of the channel mapping. Once this
+   additional 30-second period has elapsed, the owner of the channel
+   mapping(s) SHALL deallocate the channel number(s) and indicate their
+   availability in the isochronous resource manager's CHANNELS_AVAILABLE
+   register.
+
+   If an IP-capable device observes an MCAP advertisement whose
+   expiration field is zero, it SHALL NOT attempt to allocate any of the
+   channel number(s) specified until 30 seconds have elapsed since the
+   most recent such advertisement.
+
+
+
+
+Johansson                   Standards Track                    [Page 25]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+9.10 Bus reset
+
+   A bus reset SHALL invalidate all multicast channel mappings and SHALL
+   cause all multicast recipients and senders to zero all MCAP
+   advertisement interval timers.
+
+   Prior owners of multicast channel mappings may reallocate a channel
+   number from the isochronous resource manager's CHANNELS_AVAILABLE
+   register and resume broadcast of MCAP advertisements as soon as a
+   channel is allocated. If channel reallocation is attempted, the prior
+   owner SHOULD use the same channel number allocated prior to the bus
+   reset and may commence reallocation immediately upon completion of
+   the bus reset so long as the same channel number is reused. If the
+   prior owner elects to allocate a different channel number, it SHALL
+   wait until at least one second has elapsed since the completion of
+   the bus reset before attempting to allocate a new channel number.
+
+   Intended or prior recipients or transmitters of multicast on other
+   than the default channel SHALL NOT transmit MCAP solicitation
+   requests until at least ten seconds have elapsed since the completion
+   of the bus reset.  Multicast data on other than the default channel
+   SHALL NOT be received or transmitted until an MCAP advertisement is
+   observed or transmitted for the IP multicast group address.
+
+   Intended or prior transmitters of multicast on other than the default
+   channel that did not own a channel mapping for the IP multicast group
+   address prior to the bus reset SHALL NOT attempt to allocate a
+   channel number from the isochronous resource manager's
+   CHANNELS_AVAILABLE register until at least ten seconds have elapsed
+   since the completion of the bus reset. Subsequent to this ten second
+   delay, intended or prior transmitters of multicast may follow the
+   procedures specified by 9.4 to allocate a channel number and
+   advertise the channel mapping.
+
+10. IANA CONSIDERATIONS
+
+   This document necessitates the creation and management of a new name
+   space (registry) by IANA. The need for such a registry arises out of
+   the method by which protocol interfaces are uniquely identified by
+   bus standards compliant with ISO/IEC 13213:1994, CSR Architecture.
+   This is explained in more detail in section 6; the essence is that a
+   globally unique 48-bit number SHALL identify the document that
+   specifies the protocol interface. The 48-bit number is the
+   concatenation of 0x00 005E (a registration ID, or RID, granted to
+   IANA by the IEEE Registration Authority) and a second 24-bit number
+   administered by IANA.
+
+
+
+
+
+Johansson                   Standards Track                    [Page 26]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+   The IEEE RA RECOMMENDS that the policy for management of the second
+   24-bit number be chosen to maximize the quantity of usable numbers
+   with the range of possible values. In particular, the IEEE RA
+   RECOMMENDS that the assignment scheme not apply a structure to the
+   number (e.g., the allocation of a version field within the number)
+   since this would tend to waste large portions of the range.
+
+   The new name space is "CSR Protocol Identifiers". The values zero and
+   0xFF FFFF are reserved and SHALL NOT be allocated by IANA. The value
+   one is allocated to this document. The remaining numbers SHALL be
+   managed by IANA and allocated as necessary to identify Internet-
+   Drafts that become IESG standards track documents.
+
+   Regardless of the assignment method elected by IANA, a registry of
+   all assigned version numbers SHOULD be maintained at one or more
+   Internet sites and should clearly identify the relevant standard
+   identified by the combination of the RID and version number.
+
+11. SECURITY CONSIDERATIONS
+
+   This document specifies the use of an unsecured link layer, Serial
+   Bus, for the transport of IPv4 datagrams. Serial Bus is vulnerable to
+   denial of service attacks; it is also possible for devices to
+   eavesdrop on data or present forged identities. Implementers who
+   utilize Serial Bus for IPv4 SHOULD consider appropriate counter-
+   measures within application or other layers.
+
+12. ACKNOWLEDGEMENTS
+
+   This document represents the efforts of the IP/1394 Working Group.
+   The editor wishes to acknowledge the contributions made by all the
+   active participants, either on the reflector or at face-to-face
+   meetings, which have advanced the technical content.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                   Standards Track                    [Page 27]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+13. REFERENCES
+
+   Normative reference to standards under development at the time of
+   this document's publication shall utilize the most current draft
+   until such time as it is replaced by an approved standard.
+
+   [1] IEEE Std 1394-1995, Standard for a High Performance Serial Bus
+
+   [2] ISO/IEC 13213:1994, Control and Status Register (CSR)
+       Architecture for Microcomputer Buses
+
+   [3] IEEE Project P1394a, Draft Standard for a High Performance Serial
+       Bus (Supplement)
+
+   [4] IEEE Project P1394b, Draft Standard for a High Performance Serial
+       Bus (Supplement)
+
+   [5] Postel, J., "Internet Protocol Darpa Internet Program Protocol
+       Specification", RFC 791, September 1981.
+
+   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", RFC 2119, March 1997.
+
+14. EDITOR'S ADDRESS
+
+   Peter Johansson
+   Congruent Software, Inc.
+   98 Colorado Avenue
+   Berkeley, CA  94602
+
+   Phone: (510) 527-3926
+   Fax:   (510) 527-3856
+   EMail: pjohansson@aol.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                   Standards Track                    [Page 28]
+
+RFC 2734                  IPv4 over IEEE 1394              December 1999
+
+
+15.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johansson                   Standards Track                    [Page 29]
+