RFC 2734
IPv4 over IEEE 1394
RFC 2734: IPv4 over IEEE 1394 🎀
Okay bestie, here's the header tea ✨ This is RFC 2734, called IPv4 over IEEE 1394. P. Johansson of Congruent Software, Inc. wrote it. It's a Standards Track document from the Network Working Group, dated December 1999. The title block doesn't list anything it obsoletes or updates 💅
Status of this Memo ✨
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 And distribution of this memo is unlimited 🦋
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. 🌸
ABSTRACT
Okay so this doc is all about how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (plus its supplements), to carry Internet Protocol Version 4 (IPv4) datagrams 🚌 It's giving complete toolkit: packet formats, encapsulation methods, and data structures and codes for that purpose. It also includes an address resolution protocol (1394 ARP) and a multicast channel allocation protocol (MCAP). Both 1394 ARP and MCAP are specific to Serial Bus. MCAP is the one that manages Serial Bus resources when IP multicast groups are using them 🔥
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
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.......................................291. INTRODUCTION ✨
So this section sets the scene 🎬 It specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), to transport Internet Protocol Version 4 (IPv4) datagrams. It defines the methods, data structures and codes needed for that, and it also defines methods for an address resolution protocol (1394 ARP) and a multicast channel allocation protocol (MCAP). Both of those are specific to Serial Bus 💖
The whole group of IEEE standards and supplements related to IEEE Std 1394-1995, whether they're draft or approved, is called either 1394 or Serial Bus from here on 🫶
1394 is an interconnect (bus) that follows the CSR architecture, ISO/IEC 13213:1994. Serial Bus lets nodes talk over shared physical media at speeds that currently range from 100 to 400 Mbps 🚀 Consumer electronics (digital VCRs, stereo systems, televisions and camcorders) AND traditional desktop computer stuff (mass storage, printers and tapes) have both adopted 1394. That's what makes Serial Bus so unique: it's relevant to both consumer electronics and computers, and it's EXPECTED to be the basis of a home or small office network that mixes both kinds of devices 🏠
The CSR architecture describes a memory-mapped address space, which Serial Bus implements as a 64-bit fixed addressing scheme 🧩 Inside that space, 10 bits are for bus ID (up to 1,023 buses), 6 bits are for node physical ID (up to 63 per bus), and the remaining 48 bits (offset) describe a per-node address space of 256 terabytes. By convention, the CSR architecture splits each node's address space into two regions that behave differently. The lower portion, up to but not including 0xFFFF F000 0000, is EXPECTED to act like memory when it gets read and write transactions. The upper portion is more like a traditional IO space, where read and write transactions usually have side effects. Control and status registers (CSRs) with FIFO behavior are usually put in this upper region 🎀
Within that 64-bit address, the 16-bit node ID (bus ID plus physical ID) is kinda like a network hardware address 🙈 The difference is that 1394 node IDs are variable and get reassigned every time 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 gives you a packet delivery service with both confirmed (acknowledged) and unconfirmed packets 📦 There are two levels of service. "Asynchronous" packets go out on a best-effort basis, while "isochronous" packets are guaranteed to be delivered with bounded latency ⭐ Confirmed packets are always asynchronous, but unconfirmed packets can be either one. Data payloads vary between implementations and can range from one octet up to a maximum set by the transmission speed. At 100 Mbps (named S100), the maximum asynchronous data payload is 512 octets, while at S400 it's 2048 octets 👑
NOTE: Extensions underway in IEEE P1394b contemplate additional speeds of 800, 1600 and 3200 Mbps. 🌈
2. DEFINITIONS AND NOTATION 🦋
2.1 Conformance
When this document uses the keywords "MAY", "OPTIONAL", "RECOMMENDED", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD" and "SHOULD NOT", they set the levels of requirement and optionality, and they're interpreted as described in RFC 2119 🎀
There are a few extra keywords too 💅
EXPECTED: a keyword describing how the hardware or software behaves in the design models this standard assumes. Other hardware and software design models may also be implemented 🧠
IGNORED: a keyword describing bits, octets, quadlets or fields whose values the recipient does not check 🙈
RESERVED: a keyword describing either objects (bits, octets, quadlets and fields) or the code values assigned to those objects. The object or code value is set aside for future standardization. A RESERVED object has no defined meaning and SHALL be zeroed by its originator, or, once a future standard exists, set to a value that standard specifies. 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
Here's the glossary, the vocab list you need to know 📖
address resolution protocol: a method for a requester to figure out the hardware (1394) address of an IP node from that node's IP address 🔍
bus ID: a 10-bit number that uniquely identifies a particular bus inside a group of multiple interconnected buses. The bus ID is the most significant part 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 goes in front of 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 📨
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's possible to transmit datagrams without link fragmentation ✂️
multicast channel allocation protocol: a method for multicast groups to coordinate how they use Serial Bus resources (channels) when multicast datagrams go out on something other than the default broadcast channel 📡
multicast channel owner: a multicast source that has allocated a channel for one or more multicast addresses, and that sends MCAP advertisements to tell other participants in the IP multicast group about these channel mappings. When more than one source sends 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 inside 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 can be read, write or lock requests (and their responses), or stream data. The term "packet" is used consistently to tell Serial Bus primary packets apart from 1394 ARP requests and responses, IP datagrams, or MCAP advertisements and solicitations 📦
physical ID: on a particular bus, this 6-bit number is assigned dynamically during the self-identification process, and it 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 can be either asynchronous or isochronous, depending on the type of 1394 arbitration used 🌊
2.3 Abbreviations ✨
Okay, bestie, here are the abbreviations this standard uses 📚
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 protocol2.4 Numeric values 🔢
Okay so this standard uses both decimal and hexadecimal numbers. The editorial convention is that decimal numbers are mostly used for quantities or counts 💅 Addresses are always written in hexadecimal, and hex also shows up when the value has an internal structure that's easier to see in hex than in decimal. It's giving clarity 🫶
Decimal numbers are written with Arabic numerals or with their English names. Hexadecimal numbers start with 0x and use the digits 0 - 9 and A - F. For legibility, hex numbers are split into groups of four digits, with a space between each group ✨
For example, both 42 and 0x2A represent the same numeric value. Iconic 🧚
3. IP-CAPABLE NODES 🎀
Not every Serial Bus device can send or receive 1394 ARP requests/responses or IP datagrams. An IP-capable node SHALL fulfill the following minimum requirements, no exceptions 👑
- 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;
- 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 🦋
Okay, the main vibe here: all IP datagrams (broadcast, unicast or multicast), 1394 ARP requests/responses, and MCAP advertisements/solicitations that get sent via 1394 block write requests or stream packets SHALL be encapsulated inside the packet's data payload. The max size of that data payload, in octets, depends on the speed the packet is sent at 💖
Here's the table, bestie:
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 max data payload for asynchronous requests and responses might also be restricted by what the sending or receiving node(s) can handle. That's set by max_rec, either in the bus information block or in the 1394 ARP response 🌸
So, for either of those reasons, the max data payload that can be sent between IP-capable nodes may be less than the default 1500 octet maximum transmission unit (MTU) this document specifies. That means the encapsulation format also has to allow 1394 link-level fragmentation and reassembly of IP datagrams. Main character energy for sure 🎀
NOTE: IP-capable nodes may operate with an MTU size larger than the default, but how a larger MTU gets configured is out of scope for this document 🧚
4.1 Global asynchronous stream packet (GASP) format 💜
Some IP datagrams, plus 1394 ARP requests and responses, may be carried in asynchronous stream packets. When they are, the format SHALL conform to the global asynchronous stream packet (GASP) format specified by IEEE P1394a. The GASP diagram below is informative and only reproduced here for ease of reference 📸
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 formatThe source_ID field SHALL specify the node ID of the sending node, and it SHALL be equal to the most significant 16 bits of the sender's NODE_IDS register. Very specific, very important 💅
The specifier_ID_hi and specifier_ID_lo fields together SHALL contain the value 0x00 005E, which is the 24-bit organizationally unique identifier (OUI) the IEEE Registration Authority (RA) assigned to IANA 🌈
The version field SHALL be one. Simple but iconic ✨
NOTE: Because the GASP format uses the first two quadlets of the data payload in an asynchronous stream packet, the max payloads in Table 1 are effectively reduced by eight octets. In the clauses that follow, any mention of the first quadlet of the data payload means the first quadlet usable for an IP datagram or 1394 ARP request or response. When the GASP format is used, that's the third quadlet of the data payload for the packet. 🙈
4.2 Encapsulation header 🎀
All IP datagrams sent over 1394 get prefixed by an encapsulation header, in one of the formats below 🦋
If a whole IP datagram can be sent in a single 1394 packet, it's unfragmented, and the first quadlet of the data payload SHALL conform to the format 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 formatThe lf field SHALL be zero.
The ether_type field SHALL indicate what kind of datagram follows, as the table below shows:
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 here, but using them that way is outside the scope of this document. 🧚
In cases where the datagram is longer than the max data payload that the sender and all recipients support, 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 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 formatThe second and subsequent link fragments (up to and including the last) SHALL conform to the format 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 formatHere's how each field works 💖
lf: 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.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, whether they're sent as block write requests or stream packets, SHALL be preceded by one of the encapsulation headers described above. That's what makes handling datagrams uniform in software, no matter how they were sent 🫶 It's giving consistency 💅
4.3 Link fragment reassembly ✨
okay so when an IP datagram gets chopped up and sent across more than one 1394 packet, the receiver has to be able to tell which pieces belong together. bestie, this is the big moment 🧩. the recipient SHALL use both the sender's source_ID (grabbed from either the asynchronous packet header or the GASP header) and the dgl to identify all the link fragments from a single datagram. no mixing up your friends' pieces 💅
when a link fragment shows up, the recipient may drop its data payload (without the encapsulation header) into an IP datagram reassembly buffer, right at the spot marked by fragment_offset. the size of that buffer can be worked out from datagram_size. it's giving puzzle-building energy 🎀
now the drama 😭. if a new fragment overlaps a fragment that's already there (same source_ID and dgl), the fragments already sitting in the reassembly buffer SHALL be thrown out. after that, a fresh reassembly may be started using the most recently received link fragment. overlap gets checked using fragment_offset from the encapsulation header together with data_length from the 1394 packet header. not me starting over, but it's the rule 💀
and finally, when a Serial Bus reset happens, things get wiped clean 🫧. recipients SHALL discard all link fragments of all partially reassembled IP datagrams, and senders SHALL discard all link fragments that haven't been transmitted yet from all partially transmitted IP datagrams. fresh start, no leftovers ✨
5. SERIAL BUS ADDRESS RESOLUTION PROTOCOL (1394 ARP) 🦋
okay this section is about finding a device's hardware address from its IP address. ngl the methods are super tied up with whatever transport medium the device is using 🙈. so in here (and everywhere else in this doc), the acronym 1394 ARP only refers to an address resolution protocol whose methods and data structures are specific to 1394. iykyk 🧚
1394 ARP requests SHALL be sent the same way broadcast IP datagrams are sent. 1394 ARP responses MAY go out the same way, or they MAY be sent as block write requests aimed at the sender_unicast_FIFO address that was identified in the 1394 ARP request. a 1394 ARP request or response is 32 octets long and SHALL match the format shown in 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 carried in asynchronous stream packets SHALL be wrapped in the GASP format from 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 that comes 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. this is the filter that keeps the noise out 🫶
here's how each field gets used in a 1394 ARP request/response, bestie 💖:
hardware_type: this one says 1394 and SHALL have a value of 0x0018.protocol_type: this SHALL be 0x0800, which means the protocol addresses in the 1394 ARP request/response follow the IP address format.hw_addr_len: this is the size, in octets, of the 1394-dependent hardware address tied to an IP address, and it SHALL be 16.IP_addr_len: this is the size, in octets, of an IP version 4 (IPv4) address, and it SHALL be 4.opcode: this SHALL be one for a 1394 ARP request and two for a 1394 ARP response.sender_unique_ID: this SHALL hold the node unique ID of the sender, and it SHALL match what's in the sender's bus information block.sender_max_rec: this SHALL equal the value ofmax_recin the sender's configuration ROM bus information block.sspd: this SHALL be set to the lesser of the sender's link speed and PHY speed. the link speed is the max speed the link can send or receive packets at. the PHY speed is the max speed the PHY can send, receive, or repeat packets at. the table below shows the encoding forsspd. every value that isn't listed is 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_hiandsender_unicast_FIFO_lo: together these SHALL specify the 48-bit offset of the sender's FIFO that's available for receiving IP datagrams, in the format given by section 6. the offset of a sender's unicast FIFO SHALL NOT change, except as the result of a power reset. stable as a rock 🪨sender_IP_address: this SHALL specify the IP address of the sender. 🌈target_IP_address: in a 1394 ARP request, this SHALL specify the IP address the sender wants a response from. in a 1394 ARP response, it SHALL be IGNORED 🙃
6. CONFIGURATION ROM 💜
ok so the configuration ROM for IP-capable nodes SHALL have a unit directory in the format this standard defines. that unit directory SHALL contain Unit_Spec_ID and Unit_SW_Version entries, as set out in ISO/IEC 13213:1994. it's giving organized 🗂️
the unit directory may also have other entries that are allowed 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. it names the organization in charge of the architectural definition of the device's Internet Protocol capabilities.
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, which is the registration ID (RID) that IANA got from the IEEE RA. that value tells you the IETF and its technical committees are the ones maintaining this standard 🫧
6.2 Unit_SW_Version entry 🌸
the Unit_SW_Version entry is an immediate entry in the unit directory. together with unit_spec_ID, it points to 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 means the device complies with the normative requirements of this standard 🏆
6.3 Textual descriptors 📝
textual descriptors in the configuration ROM are OPTIONAL. when they're there, they add extra descriptive info that's meant to be readable by a human 👀. IP-capable nodes SHOULD attach a textual descriptor with the content "IANA" to the Unit_Spec_ID entry, and a textual descriptor with the content "IPv4" to the Unit_SW_Version entry.
the figure below shows a unit directory from an IP-capable node, including the OPTIONAL textual descriptors. the descriptor leaves aren't technically part of the unit directory, but for simplicity they're drawn right after it 🧚
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
7. IP UNICAST ✨
okay so a unicast IP datagram can be sent to a recipient inside a 1394 primary packet with one of these transaction codes 💅
tcode Description Arbitration
+--------------------------------------+
| 0x01 | Block write | Asynchronous |
| 0x0A | Stream packet | Isochronous |
| 0x0A | Stream packet | Asynchronous |
+--------------------------------------+block writes are the move when you want 1394 link-level acknowledgement but don't need bounded latency for the packet (quality of service) 🧚
isochronous stream packets give you quality of service guarantees, but there's no 1394 link-level acknowledgement 🦋
asynchronous stream packets only get a mention for completeness 🙈 this method SHOULD NOT be used for IP unicast, because it gives you neither 1394 link-level acknowledgment nor quality of service, and it eats up a valuable resource, a channel number. no thank you 💀
no matter which IP unicast method you use (asynchronous or isochronous), the sender of a unicast IP datagram is the one who has to figure out the maximum data payload for each packet 👑 you can get that info from:
- the SPEED_MAP kept by the 1394 bus manager, which gives the maximum transmission speed between any two nodes on the local Serial Bus. the bus manager analyzes bus topology to build the speed map, and the max speed between nodes reflects what the nodes in between can do. that speed then 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 (that last one is already baked into the SPEED_MAP entry indexed by sender and recipient) 🌸
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 with best-effort quality of service SHALL be contained within the data payload of 1394 block write transactions addressed to the source_ID and sender_unicast_FIFO from a 1394 ARP response 🫶
if a unicast block write request doesn't get an acknowledgement back, it's uncertain whether the target actually got the data payload 😭
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 need quality of service other than best-effort are beyond the scope of this standard 🌈
8. IP BROADCAST
broadcast IP datagrams get encapsulated following section 4 and ride along in asynchronous stream packets 🧚 there's no quality of service for IP broadcast over 1394. the channel number used for IP broadcast is set by the BROADCAST_CHANNEL register 🎀
all broadcast IP datagrams SHALL use asynchronous stream packets whose channel number equals the channel field from the BROADCAST_CHANNEL register 💖
even though 1394 lets you reuse previously allocated channel numbers for up to one second after 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 🙅♀️ a bus reset automatically clears that valid bit to zero, so this blocks 1394 ARP and broadcast IP until the IRM allocates a channel number. patience is a virtue, bestie ⏳
9. IP MULTICAST
multicast IP datagrams get encapsulated following section 4 and get transported in stream packets 🦋 asynchronous streams are used for best-effort IP multicast, and quality of service other than best-effort is beyond the scope of this standard 💅
by default, all best-effort IP multicast SHALL use asynchronous stream packets whose channel number equals the channel field from the BROADCAST_CHANNEL register. datagrams addressed to 224.0.0.1 and 224.0.0.2 SHALL use this channel number, no exceptions 👑 best-effort IP multicast for other group addresses may use a different channel number, but only if that channel number is allocated and advertised before use, as described below 🌸
IP-capable nodes may transmit best-effort IP multicast only if one of these two conditions is met:
- the channel number in the stream packet equals the channel number field in the BROADCAST_CHANNEL register AND the valid bit in that same register is one; or
- for other channel number(s), some source of IP multicast has allocated and is advertising the channel number being used.
the rest of this section describes a multicast channel allocation protocol (MCAP) that both IP multicast sources and recipients use whenever a channel number other than the default is in play 🧚 MCAP is a cooperative protocol: the participants swap messages over the broadcast channel that every IP-capable node on a particular Serial Bus uses.
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 they come from a multicast channel owner or a recipient, are carried as the data portion of a GASP packet and have the format shown below ✨ the first four octets are fixed. the rest is made of variable-length tuples, and each one describes a particular IP multicast group. individual MCAP messages SHALL NOT be fragmented, and they SHALL be encapsulated within a stream packet as ether_type 0x8861 💜
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 formathere's how the fields in an MCAP message work 🎀
length: this field SHALL contain the size, in octets, of the entire MCAP message.
opcode: this field SHALL have one of the values in 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 rest of the MCAP message is variable in length and SHALL consist of zero or more group address descriptors, formatted like this 🌈
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 formatand the group address descriptor fields work like this 🧚
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 means "this is a group address descriptor" 🔥
expiration: what this field does depends on the opcode. for solicit messages the expiration field SHALL be IGNORED. otherwise, for advertisements, this field SHALL contain a time-stamp, in seconds, that marks a future time after which the channel number in channel may no longer be used ⏳
channel: this field is only valid for advertise messages, and in that case it SHALL specify an allocated channel number in the range zero to 63 inclusive. all other values are RESERVED. 🙈
speed: this field is only valid for advertise messages, and in that case it SHALL specify the speed at which stream packets for the indicated channel are transmitted. Table 2 has the encoding used for speed 💖
bandwidth: this field SHALL be zero. it's kept in the group address descriptor so future MCAP extensions can add quality of service and use 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 worked out from the length of the group address descriptor by subtracting 12 from the length field 🧮
9.2 MCAP message domain
MCAP messages only carry information that's valid for the local Serial Bus they're sent on 🌍 recipients of MCAP messages SHALL IGNORE all MCAP messages from anywhere other than the local bus, like so. the source_ID of the sender is in the GASP header that comes right before 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 those bits 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 🙅♀️
inside 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, which is the least significant six bits of source_ID 👑
9.3. Multicast receive 🦋
okay so if you're an IP-capable device and you want to receive multicast data, you 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. you may observe the MCAP advertisements on the broadcast channel for the desired channel mapping(s) 👀
an intended multicast recipient may transmit MCAP solicitation requests to ask multicast channel owner(s) to broadcast advertisements sooner than the next ten second interval 📣 but the originators of those solicitation requests SHALL limit how often they send them. after sending one, the originator SHALL NOT send another MCAP solicitation request until ten seconds have elapsed. no spamming, bestie 🙅♀️
in either case, if a mapping exists for the group address for a channel other than the default, an MCAP advertise message is expected within ten seconds ⏰ once you get an MCAP advertise message that describes one or more channel mappings, you may receive IP datagrams on the indicated channel number(s) until the expiration time. it's giving clean handoff 💅
if multiple MCAP advertise messages specify the same group address, the channel number SHALL be obtained from the advertisement message with the largest physical ID, and that physical ID SHALL be obtained from the least significant six bits of source_ID from the GASP header 🧠
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. so either there is no multicast data, or it's being sent on the default channel. 🤷♀️
once a multicast recipient has seen 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 keep monitoring the default broadcast channel for MCAP advertisements for the same group address so it can refresh the expiration time of the channel number(s) in use. keeping the vibes fresh 🌸
9.4. Multicast transmit 🎀
okay transmitters, listen up 📢 an IP-capable device that wants to transmit multicast data on anything other than the default channel SHALL first check whether another multicast source has already allocated a channel number for the group address. you may send an MCAP solicitation request with one or more group address descriptors if you want 🙋♀️
whether or not you sent a solicitation request, 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. then the intended multicast source may start sending IP datagrams on the indicated channel number(s), and may keep doing so until their expiration time. the multicast source SHALL monitor MCAP advertisements to refresh the expiration time of the channel number(s) in use 🔄
now if no other multicast source has set up a channel mapping for the group address, the intended multicast source may try to allocate a channel number from the isochronous resource manager's CHANNELS_AVAILABLE register, following the procedures described in IEEE P1394a 🧩 if the allocation works, the multicast source SHALL advertise the new channel mapping(s) as soon as possible. once 100 ms has passed since that first advertisement of a newly allocated channel number, the multicast source may transmit IP datagrams using the advertised channel number. ✨
also, multicast IP datagrams may be sent on the default channel until the sender sees (or sends) an advertisement that specifies non-default channel mapping(s) for the multicast addresses. this is what makes the switch from the default channel to an explicitly allocated channel smooth 🧈
last but not least, once a multicast source has advertised a channel mapping, it SHALL keep transmitting MCAP advertisements for that channel mapping, unless it either a) transfers ownership to another multicast source, b) lets the channel mapping expire without transfer, or c) in the case of overlapped channel mappings, gives up control of the channel mapping to another multicast source. no ghosting 👻
9.5. Advertisement of channel mappings 📻
each multicast source SHALL periodically broadcast an advertisement of all IP multicast group addresses it has allocated a channel number for, as long as that channel number is different from the default multicast channel number. an advertisement SHALL consist of a single MCAP message with an opcode of zero, containing one or more group address descriptors (one for each group address assigned a channel number other than the one specified by the BROADCAST_CHANNEL register) 🗂️
inside each group address descriptor, the group_address and channel fields link an IP multicast group address to a Serial Bus channel number 🔗 the speed field gives the maximum 1394 speed at which any sender in the IP multicast group is allowed to transmit data 🏎️ and the expiration field gives the current time, or a future time, after which the channel mapping(s) are no longer valid ⏳ unless a channel owner intends to give up ownership (as described in 9.7 below), the expiration time SHALL be at least 60 seconds in the future, measured from when the advertisement is sent.
no more than ten seconds SHALL pass after the owner's most recent advertisement before the owner of a channel mapping sends the next one. and if someone asks for an advertisement with a solicitation, the owner of a channel mapping SHOULD send an MCAP advertisement in response as soon as possible after receiving the request 🙌
9.6. Overlapped channel mappings 👯♀️
okay, drama alert 🚨 when two intended multicast sources want to transmit to the same IP multicast group and no channel mapping exists for that group address, there's a chance that both of them allocate channel numbers and both advertise their channel mappings. these channel mappings overlap, meaning 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 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 mapping is detected, the owner with the largest physical ID (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, so those owners SHALL stop transmitting both IP datagrams and MCAP advertisements that use the invalid channel numbers. as soon as those 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 the multicast channel owner(s) with the smaller physical IDs, and they SHALL NOT transmit IP datagrams that use the invalid channel number. it's possible for some channel mappings in a single MCAP advertisement to still be valid even though others SHALL be ignored because of the overlap. not everything in the group chat is cancelled 🫶
9.7. Transfer of channel ownership 🤝
the owner of a channel mapping may stop multicast transmission on a particular channel. in that 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, there's an orderly process for transferring channel ownership 💌
the owner of an existing channel mapping that wants to release the mapping SHALL start a timer to measure the time left before the mapping and its associated channel are anticipated to be released ⏱️ until that timer counts down to zero, the owner SHOULD keep transmitting 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 can't transmit MCAP advertisements before the timer reaches zero, it SHALL initiate a bus reset.
⚠️ babe, a bus reset is a big deal, so the owner should really try to send those advertisements in time!
otherwise, the sequence of expiration times transmitted by the owner who is releasing the mapping SHALL decrease with each advertisement it sends. if other multicast source(s) are using the same channel mapping and see an expiration time less than or equal to 60 seconds, they SHALL start transmitting MCAP advertisements for the channel mapping with refreshed expiration times greater than or equal to 60 seconds, so the mapping stays alive 💖 any contention between multiple sources trying to claim ownership of the channel mapping SHALL be resolved as described in 9.8. and if the original owner sees an MCAP advertisement for the channel being relinquished before its own timer has expired, it SHALL NOT deallocate the channel number. 🙅♀️
otherwise, if the owner's timer expires without anyone else's MCAP advertisement being observed by another node, the owner of the channel number SHALL then deallocate the channel as described in 9.8. if the intended owner of the channel mapping sees an MCAP advertisement whose expiration field is zero, the orderly transfer of the channel(s) from the former owner has failed 💀 in that case, 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 moves from one multicast source to another, it's possible for more than one device to claim ownership. this leads to redundant MCAP advertisements, sent by different sources, each specifying the same multicast group address and channel. a procedure similar to the one in 9.6 SHALL resolve the contention for channel ownership 🥊
multicast channel owners SHALL monitor MCAP advertisements 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 (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 stop transmitting MCAP advertisements for the redundant channel number, but they SHALL NOT deallocate the channel number. 🧚♀️
9.9 Expired channel mappings 🥀
okay so a channel mapping expires once expiration seconds have passed since the most recent MCAP advertisement 😭 at that point, multicast recipients SHALL stop reception on the expired channel number(s). the owner of the mapping(s) SHALL also send an MCAP advertisement with expiration cleared to zero, and keep sending those until 30 seconds have passed since the mapping expired. after that extra 30 seconds, the owner SHALL deallocate the channel number(s) and mark them as available in the isochronous resource manager's CHANNELS_AVAILABLE register ✨ it's giving clean handoff, bestie 💅
if an IP-capable device spots an MCAP advertisement with expiration set to zero, it SHALL NOT try to allocate any of the channel number(s) listed until 30 seconds have passed since the most recent one of those advertisements 🙈 no sneaking in early, periodt 🛑
9.10 Bus reset 🌪️
a bus reset SHALL invalidate all multicast channel mappings, and it SHALL cause every multicast recipient and sender to zero all their MCAP advertisement interval timers 🧹 full reset, no cap 🫶
previous owners of multicast channel mappings can grab a channel number back from the CHANNELS_AVAILABLE register and start sending MCAP advertisements again as soon as a channel is allocated 🦋 if they try to reallocate, the previous owner SHOULD use the same channel number they had before the reset. they can start reallocating right after the reset finishes, as long as they keep the same channel number 💜 if they decide to pick a different channel number instead, they SHALL wait at least one second after the reset is complete before trying to allocate it 🕰️ patience is a whole vibe 🌸
recipients or transmitters who were meant to use multicast on a channel other than the default one, or who used to, SHALL NOT send MCAP solicitation requests until at least ten seconds have passed since the reset finished 📵 also, multicast data on a channel other than the default one SHALL NOT be received or transmitted until an MCAP advertisement has been observed or sent for that IP multicast group address 👀 no vibes without the receipt, iykyk 🤫
transmitters who were meant to send multicast on a non-default channel, or who used to, and who did NOT own a channel mapping for that IP multicast group address before the reset, SHALL NOT try to allocate a channel number from CHANNELS_AVAILABLE until at least ten seconds have passed since the reset finished 🧁 after that ten second wait, those transmitters can follow the procedures in 9.4 to allocate a channel number and advertise the channel mapping 🎀 ready, set, slay 🔥
10. IANA CONSIDERATIONS 📚
this document needs IANA to create and manage a brand new name space (registry) 🗂️ the reason is how protocol interfaces get uniquely identified by bus standards that follow ISO/IEC 13213:1994, CSR Architecture. we go deeper into that in section 6, but the big idea is this: a globally unique 48-bit number SHALL identify the document that specifies the protocol interface 🔑 that 48-bit number is made by sticking together 0x00 005E (a registration ID, or RID, given to IANA by the IEEE Registration Authority) and a second 24-bit number that IANA manages 💖
the IEEE RA recommends that the policy for managing that second 24-bit number be picked so you get the most usable numbers across the whole range 🌈 specifically, the IEEE RA recommends that the assignment scheme NOT give the number any structure, like carving out a version field inside it, because that would tend to waste big chunks of the range 🙅♀️ nobody wants wasted numbers, bestie
the new name space is called "CSR Protocol Identifiers" 🏷️ the values zero and 0xFF FFFF are reserved, and they SHALL NOT be allocated by IANA ❌ the value one goes to this document 🦋 the remaining numbers SHALL be managed by IANA and handed out as needed to identify Internet-Drafts that become IESG standards track documents 🌟
no matter how IANA decides to assign them, a registry of every assigned version number SHOULD be kept at one or more Internet sites 📜 it should also clearly show which standard goes with each combination of RID and version number 🧠 clear labels, big brain energy ✨
11. SECURITY CONSIDERATIONS 🚨
okay this one is serious, so listen up 🥺 this document describes using an unsecured link layer, Serial Bus, to carry IPv4 datagrams 😱 Serial Bus is open to denial of service attacks, and devices can also eavesdrop on data or fake their identities 💀 anyone who uses Serial Bus for IPv4 SHOULD think about proper countermeasures in the application or other layers 🛡️ please protect yourself, the internet is not a safe place without it 🫠
12. ACKNOWLEDGEMENTS 💜
this document is the work of the IP/1394 Working Group 🥰 the editor wants to give a huge shout-out to every active participant, whether they showed up on the reflector or at the in-person meetings, for moving the technical content forward 🫶 you all are the real MVPs 👑
13. REFERENCES 📖
normative references to standards that were still being developed when this document was published SHALL use the most current draft until it gets replaced by an approved standard 📌 (the wording above is the same rule, just vibing a bit more 💅)
- [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 💌
the editor's contact info, in case you need to slide into their inbox 📬
Peter Johansson
Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA 94602
Phone: (510) 527-3926
Fax: (510) 527-3856
EMail: pjohansson@aol.com15. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (1999). All Rights Reserved. 🌸
this document and its translations may be copied and shared with others, and derivative works that comment on or explain it, or help with implementing it, may be written, copied, published and distributed, in whole or in part, with no restrictions of any kind 🦋 as long as the copyright notice and this paragraph are included on every copy and derivative work 🧾 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 🚫 the exceptions are developing Internet standards, where the copyright procedures in the Internet Standards process must be followed, or translating it into languages other than English 🌍
the limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️
this document and the information in it are 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 💖
📦 where this page comes from
- ietf: rfc2734 1999-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms