IPv4 over IEEE 1394
Extracted elements (29)
MCAP uses a cooperative protocol over the existing broadcast channel rather than a dedicated management channel so that all IP-capable nodes, which must already monitor the broadcast channel, can participate without requiring extra channel allocation or separate signaling infrastructure.
The datagram label (dgl) field is per-sender rather than globally unique to keep the 1394 link-level fragmentation scheme simple; recipients identify fragments by combining source_ID with dgl, avoiding any need for a centralized label allocator.
The MCAP 100 ms delay between the initial advertisement of a newly allocated channel and first data transmission allows all prospective receivers on the bus to observe the channel advertisement before data arrives, preventing silent packet loss at receivers that have not yet tuned to the new channel.
IPv4 over 1394 as specified may not operate correctly across IEEE P1394.1 Serial Bus bridges because node IDs are variable per enumerated bus and no standard cross-bridge ID mapping exists at the time of publication.
A bus reset SHALL invalidate all multicast channel mappings and zero all MCAP advertisement interval timers. Nodes without prior channel ownership SHALL NOT attempt channel allocation or send MCAP solicitations until at least ten seconds after bus reset completion.
A multicast source SHALL advertise channel mappings at least every ten seconds; except when relinquishing ownership, the expiration time in each advertisement SHALL be at least 60 seconds in the future from the time of transmission.
After bus reset, a prior channel owner SHOULD reuse the same channel number and MAY attempt reallocation immediately; if a different channel number is desired, the owner SHALL wait at least one second after bus reset completion before allocation.
All broadcast IP datagrams SHALL use asynchronous stream packets with the channel number from the BROADCAST_CHANNEL register, and SHALL NOT be transmitted when the valid bit in BROADCAST_CHANNEL is zero (e.g., immediately after a bus reset).
All link fragments of all partially reassembled IP datagrams SHALL be discarded by recipients upon a Serial Bus reset; senders SHALL also discard not-yet-transmitted link fragments of partially transmitted datagrams.
An IP-capable node SHALL implement configuration ROM with a unit directory, SHALL have max_rec of at least 8 (supporting 512-octet block payloads), SHALL be isochronous resource manager capable, and SHALL support both reception and transmission of asynchronous streams.
If a received link fragment overlaps another fragment identified by the same source_ID and dgl, previously accumulated fragments in the reassembly buffer SHALL be discarded and reassembly MAY recommence with the most recently received fragment.
MCAP messages SHALL NOT be fragmented and SHALL be encapsulated as ether_type 0x8861 within a GASP stream packet on the broadcast channel. Individual MCAP messages are always transported unfragmented.
Recipients of a 1394 ARP request or response SHALL ignore it unless the most significant ten bits of the source_ID are equal to 0x3FF or to the most significant ten bits of the recipient's own NODE_IDS register, preventing cross-bus confusion.
Recipients of MCAP messages SHALL ignore messages whose source_ID top 10 bits are neither 0x3FF nor the recipient's own bus ID, limiting MCAP to the local Serial Bus domain.
The sender_unicast_FIFO address advertised in 1394 ARP SHALL NOT change except as the result of a power reset, providing a stable unicast delivery endpoint for IP datagrams.
Unicast IP datagrams requiring best-effort delivery SHALL be contained within block write transactions addressed to the source_ID and sender_unicast_FIFO obtained from a 1394 ARP response; asynchronous stream packets SHOULD NOT be used for unicast as they consume channel numbers.
When a channel mapping expires (expiration seconds elapsed since last advertisement), multicast recipients SHALL stop reception on that channel; the owner SHALL send MCAP advertisements with expiration=0 for 30 seconds, then deallocate the channel in the IRM's CHANNELS_AVAILABLE register.
When overlapping channel mappings are detected, owners with smaller physical IDs (least significant six bits of source_ID) SHALL cease transmission on invalid channel numbers; the owner with the largest physical ID need not take action.
The Multicast Channel Allocation Protocol (MCAP) is a cooperative protocol exchanged over the broadcast channel; it uses Advertise (opcode 0) and Solicit (opcode 1) messages to map IP multicast group addresses to Serial Bus channel numbers other than the default broadcast channel.
The sspd field in 1394 ARP encodes link/PHY speed as values 0–5 corresponding to S100–S3200; the field SHALL be set to the lesser of sender link speed and PHY speed. Speed codes above 5 are RESERVED.
This document creates the 'CSR Protocol Identifiers' IANA registry: a 24-bit namespace concatenated with IANA's OUI (0x00 005E) to form a globally unique 48-bit protocol identifier. Values 0 and 0xFFFFFF are reserved; value 1 is assigned to this document. Remaining values are allocated to IESG standards-track documents.
Serial Bus is an unsecured link layer vulnerable to denial-of-service attacks, eavesdropping, and identity spoofing. Implementers using Serial Bus for IPv4 SHOULD apply appropriate countermeasures at application or higher layers, as no security is provided at the 1394 link level.
Channel ownership transfer: the releasing owner decrements expiration in each advertisement until it reaches zero; other sources observing expiration ≤ 60 seconds SHALL begin advertising with refreshed expiration ≥ 60 seconds. If no new owner appears when the timer expires, the owner deallocates the channel. Contention for ownership is resolved by largest physical ID.
A 1394 ARP request/response is exactly 32 octets containing: hardware_type (0x0018), protocol_type (0x0800), hw_addr_len (16), IP_addr_len (4), opcode (1=request, 2=response), sender_unique_ID (64 bits, EUI-64), sender_max_rec, sspd (speed code), sender_unicast_FIFO (48-bit offset), sender_IP_address, and target_IP_address.
An MCAP message begins with a 4-octet header (length, reserved, opcode) followed by zero or more 20-octet group address descriptors, each containing length, type (SHALL be 1), expiration (seconds timestamp), channel (0–63), speed, bandwidth (SHALL be zero), and group_address.
First fragment encapsulation header is two quadlets: lf (2 bits, value 1), datagram_size (the IP Total Length minus one), ether_type (0x0800), and dgl (16-bit datagram label, same for all fragments of one datagram). Subsequent fragments replace ether_type with fragment_offset.
The Configuration ROM unit directory SHALL contain a Unit_Spec_ID entry (key 0x12, value 0x00 005E — IANA's OUI) and a Unit_SW_Version entry (key 0x13, value 0x000001), uniquely identifying the device as compliant with this standard.
The Global Asynchronous Stream Packet (GASP) format prefixes asynchronous stream packets with source_ID (16 bits, sender's node ID), specifier_ID (24 bits, SHALL be 0x00 005E — IANA's OUI), and version (SHALL be 1), consuming two quadlets before the encapsulated data payload.
Unfragmented encapsulation header is one quadlet: lf field (2 bits, SHALL be zero), reserved bits, and ether_type (16 bits) indicating the payload type — 0x0800 for IPv4, 0x0806 for 1394 ARP, 0x8861 for MCAP.