Network Working Group P. Johansson
Request for Comments: 2734 Congruent Software, Inc.
Category: Standards Track December 1999
Network Working Group P. Johansson
Request for Comments: 2734 Congruent Software, Inc.
Category: Standards Track December 1999
IPv4 over IEEE 1394
IEEE 1394上的IPv4
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件规定了如何使用IEEE Std 1394-1995高性能串行总线标准（及其补充）传输互联网协议版本4（IPv4）数据报；它定义了用于该目的的必要方法、数据结构和代码。这些协议不仅包括数据报的数据包格式和封装方法，还包括地址解析协议（1394 ARP）和多播信道分配协议（MCAP）。1394 ARP和MCAP都是串行总线专用的；后者允许在IP多播组使用时管理串行总线资源。
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
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.......................................29
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
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.
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.
与IEEE Std 1394-1995相关的IEEE标准和补充（草案或批准）组在下文中称为1394或串行总线。
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.
1394是一种符合CSR体系结构ISO/IEC 13213:1994的互连（总线）。串行总线允许节点之间通过共享物理介质进行通信，通信速度目前为100到400 Mbps。消费者电子应用（如数字录像机、立体声系统、电视和摄像机）和传统台式计算机应用（如大容量存储、打印机和磁带）都采用了1394。串行总线在消费者电子和计算机领域都具有独特的相关性，有望成为家庭或小型办公网络的基础，将这两种设备结合在一起。
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.
CSR体系结构描述了串行总线作为64位固定寻址方案实现的内存映射地址空间。在地址空间中，为总线ID分配了10位（最多1023条总线），为节点物理ID分配了6位（最多63条总线），而剩余的48位（偏移量）描述了256 TB的每个节点地址空间。按照惯例，CSR架构将节点的地址空间划分为两个具有不同行为特征的区域。较低的部分（不包括0xFFFF F000 0000）预计将作为内存响应读写事务。上面的部分更像传统的IO空间：该区域中的读写事务通常会产生副作用。通常具有FIFO行为的控制和状态寄存器（CSR）在该区域实现。
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.
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.
注意：尽管16位节点ID包含总线ID，但目前没有连接单独枚举串行总线的标准方法。IEEE P1394.1工作组正在积极开发串行总线到串行总线网桥的标准。除非通过未来的标准进行扩展，否则本文档指定的IPv4 over 1394协议可能无法跨网桥正确运行。
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).
1394链路层为确认（已确认）和未确认的数据包提供数据包传递服务。提供两个级别的服务：“异步”数据包以最大努力的方式发送，而“等时”数据包保证以有限的延迟交付。确认的数据包始终是异步的，但未确认的数据包可以是异步的，也可以是等时的。数据有效载荷随实现而变化，范围从一个八位字节到由传输速度确定的最大值（在100 Mbps，命名为S100时，最大异步数据有效载荷为512个八位字节，而在S400时为2048个八位字节）。
NOTE: Extensions underway in IEEE P1394b contemplate additional speeds of 800, 1600 and 3200 Mbps.
注：IEEE P1394b中正在进行的扩展考虑了800、1600和3200 Mbps的额外速度。
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.
本文件中使用的关键词“可”、“可选”、“推荐”、“必需”、“应”、“不应”、“应”和“不应”区分了要求和可选性的等级，并应按照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.
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.
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.
地址解析协议：请求者根据IP地址确定IP节点硬件（1394）地址的方法。
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.
总线ID：一个10位的数字，它唯一地标识一组多个互连总线中的特定总线。总线ID是节点16位节点ID的最重要部分。值0x3FF指定本地总线；如果请求中的总线ID为0x3FF或显式分配给节点的总线ID，则节点应响应针对其6位物理ID的请求。
encapsulation header: A structure that precedes all IP data transmitted over 1394. See also link fragment.
封装头：位于通过1394传输的所有IP数据之前的结构。另请参见链接片段。
IP datagram: An Internet message that conforms to the format specified by STD 5, RFC 791.
IP数据报：符合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 is possible to transmit datagrams without link fragmentation.
链路片段：在单个1394数据包中传输的IP数据报的一部分。1394数据包的数据有效载荷包含封装报头及其关联的链路片段。可以在没有链路碎片的情况下传输数据报。
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.
多播信道所有者：为一个或多个多播地址分配信道并传输MCAP播发以将这些信道映射传达给IP多播组中的其他参与者的多播源。当多个源为同一频道号传输MCAP播发时，具有最大物理ID的源为所有者。
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.
节点ID：一个16位的数字，用于唯一标识多条互连总线组中的串行总线节点。最高有效的10位是总线ID，最低有效的6位是物理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).
节点唯一ID：在全球制造的所有串行总线节点中唯一标识节点的64位数字；也称为EUI-64（扩展唯一标识符，64位）。
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.
数据包：1394个主数据包中的任意一个；这些可能是读、写或锁定请求（及其响应）或流数据。术语“数据包”一致用于区分串行总线主数据包与1394 ARP请求/响应、IP数据报或MCAP广告/请求。
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.
物理ID：在特定总线上，此6位数字在自标识过程中动态分配，并唯一标识该总线上的节点。
quadlet: Four octets, or 32 bits, of data.
四位字节：四个八位字节，或32位数据。
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.
流数据包：1394主数据包，事务代码为0x0A，包含块数据有效负载。根据所采用的1394仲裁的类型，流分组可以是异步的或等时的。
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
1394 ARP地址解析协议（特定于1394）CSR控制和状态寄存器CRC循环冗余校验和EUI-64扩展唯一标识符，64位GASP全局异步流数据包IP Internet协议（本文档中为IPv4）MCAP多播信道分配协议
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.
十进制数字由阿拉伯数字或其英文名称表示。十六进制数的前缀为0x，并由字符集0-9和A-F中的数字表示。为了清晰易读，十六进制数被分成四个数字组，每组由空格分隔。
For example, both 42 and 0x2A represent the same numeric value.
例如，42和0x2A都表示相同的数值。
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:
并非所有串行总线设备都能够接收和传输1394 ARP请求/响应或IP数据报。具有IP能力的节点应满足以下最低要求：
- 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;
- 应按照ISO/IEC 13213:1994规定的通用格式实现配置ROM，并应实现IEEE P1394a规定的总线信息块和本标准规定的单元目录；
- 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;
- 其总线信息块中的max_rec字段应至少为8；这表示能够接受数据负载为512个八位字节的块写入请求和异步流数据包。同样的能力也适用于读取请求；也就是说，该节点应能够发送具有512个八位字节的数据有效载荷的块响应分组；
- it SHALL be isochronous resource manager capable, as specified by IEEE P1394a;
- 按照IEEE P1394a的规定，它应具有同步资源管理功能；
- it SHALL support both reception and transmission of asynchronous streams as specified by IEEE P1394a; and
- 它应支持IEEE P1394a规定的异步流的接收和传输；和
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.
通过1394块写入请求或流数据包传输的所有IP数据报（广播、单播或多播）、1394 ARP请求/响应和MCAP广告/请求应封装在数据包的数据有效载荷内。数据有效载荷的最大大小（以八位字节为单位）受数据包传输速度的限制。
Table 1 - Maximum data payloads (octets)
表1-最大数据有效载荷（八位字节）
Speed Asynchronous Isochronous
+------------------------------------+
| S100 | 512 | 1024 |
| S200 | 1024 | 2048 |
| S400 | 2048 | 4096 |
| S800 | 4096 | 8192 |
| S1600 | 8192 | 16384 |
| S3200 | 16384 | 32768 |
+------------------------------------+
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.
注：由于IEEE P1394b的标准化，S800及以上速度下的最大数据有效载荷可能会减少（但不会增加）。
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.
异步请求和响应的最大数据有效载荷也可能受到发送或接收节点的能力的限制；这由max_rec在总线信息块或1394 ARP响应中指定。
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.
出于上述任一原因，可在具有IP能力的节点之间传输的最大数据有效负载可能小于本文档指定的默认1500八位字节最大传输单元（MTU）。这要求封装格式还允许1394链路级分段和重新组装IP数据报。
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.
注意：支持IP的节点可以在MTU大小大于默认值的情况下运行，但配置更大MTU的方式超出了本文档的范围。
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.
一些IP数据报以及1394 ARP请求和响应可以通过异步流数据包传输。使用异步流数据包时，其格式应符合IEEE P1394a规定的全局异步流数据包（GASP）格式。以下所示的GASP格式仅供参考，仅为便于参考而复制。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图1-GASP格式
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.
源ID字段应指定发送节点的节点ID，并应等于发送方节点ID寄存器的最高有效16位。
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.
说明符_ID_hi和说明符_ID_lo字段一起应包含值0x00 005E，即IEEE注册机构（RA）分配给IANA的24位组织唯一标识符（OUI）。
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.
注：由于GASP格式在异步流数据包格式中使用了数据有效载荷的前两个四元组，表1中引用的最大有效载荷有效地减少了八个八位字节。在下面的条款中，对数据有效载荷的第一个四元字节的引用意味着可用于IP数据报或1394 ARP请求或响应的第一个四元字节。使用GASP格式时，这是数据包的数据有效载荷的第三个四元组。
All IP datagrams transported over 1394 are prefixed by an encapsulation header with one of the formats illustrated below.
通过1394传输的所有IP数据报都以封装头作为前缀，其格式如下所示。
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.
如果整个IP数据报可以在单个1394数据包内传输，则该数据包是不分段的，并且数据有效载荷的第一个四元组应符合下面所示的格式。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图2-未分段封装标头格式
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 |
+-------------------------+
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.
注：其他网络协议（由不同的ether_类型值标识）可使用本文定义的封装格式，但此类使用不在本文件范围内。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图3-第一个片段封装头格式
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图4-后续片段封装头格式
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字段应指定IP数据报中链路片段的相对位置，如下表所示。
lf Position
+------------------------+
| 0 | Unfragmented |
| 1 | First |
| 2 | Last |
| 3 | Interior |
+------------------------+
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).
datagram_size：整个IP数据报的编码大小。对于IP数据报的所有链路片段，数据报_大小的值应相同，且应小于数据报IP报头中的总长度值（见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.
ether_type：该字段仅出现在第一个链路片段中，其值应为0x0800，表示IPv4数据报。
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.
片段_偏移量：该字段仅在第二个和后续链接片段中存在，并应以八位字节为单位指定片段从IP数据报开始的偏移量。数据报的第一个八位组（IP报头的开头）的偏移量为零；第一个链接片段中片段_offset的隐式值为零。
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.
dgl：对于IP数据报的所有链路片段，dgl（数据报标签）的值应相同。发送方应增加连续、分段数据报的dgl；dgl的增量值应从65535回到零。
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.
所有IP数据报，无论传输模式如何（块写入请求或流数据包），都应以上述封装报头之一开头。这允许对数据报进行统一的软件处理，而不考虑其传输模式。
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.
通过一个以上1394数据包传输的IP数据报的接收者应使用发送者的源ID（从异步数据包报头或GASP报头获得）和dgl来识别单个数据报的所有链路片段。
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.
在接收到链路片段后，接收者可以将数据有效载荷（不包括封装头）放置在由片段_offset指定的位置处的IP数据报重组缓冲区中。重组缓冲区的大小可根据数据报大小确定。
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.
如果接收到的链接片段与由相同源ID和dgl标识的另一个片段重叠，则应丢弃重新组装缓冲区中已累积的片段。可以使用最近接收到的链路片段开始新的重新组装。片段重叠由来自封装头的片段_偏移量和来自1394数据包头的数据_长度的组合确定。
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.
在检测到串行总线复位后，接收方应丢弃所有部分重新组装的IP数据报的所有链路片段，而发送方应丢弃所有部分传输的IP数据报的所有尚未传输的链路片段。
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.
根据设备相应的IP地址确定设备硬件地址的方法与设备使用的传输介质紧密相连。在下面的描述和本文档中，首字母缩略词1394 ARP仅适用于地址解析协议，其方法和数据结构特定于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
1394 ARP请求应通过与广播IP数据报相同的方式传输；1394 ARP响应可以以相同的方式传输，或者它们可以作为发往服务器的块写入请求传输
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.
发送方\单播\由1394 ARP请求标识的FIFO地址。1394 ARP请求/响应为32个八位字节，应符合图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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图5-1394 ARP请求/响应格式
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.
异步流数据包传输的1394 ARP请求和响应应封装在IEEE P1394a规定的GASP格式内（另见4.1）。1394 ARP请求或响应的接收方应忽略该请求或响应，除非源ID字段的最高有效十位（无论是从异步流数据包的GASP报头还是块写入请求的数据包报头获得）等于0x3FF或接收方节点ID寄存器的最高有效十位。
Field usage in a 1394 ARP request/response is as follows:
1394 ARP请求/响应中的字段用法如下：
hardware_type: This field indicates 1394 and SHALL have a value of 0x0018.
硬件类型：该字段表示1394，其值应为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.
协议类型：该字段的值应为0x0800；这表明1394 ARP请求/响应中的协议地址符合IP地址的格式。
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.
hw_addr_len：此字段表示与IP地址关联的1394相关硬件地址的大小（以八位字节为单位），其值应为16。
IP_addr_len: This field indicates the size, in octets, of an IP version 4 (IPv4) address and SHALL have a value of 4.
IP地址：此字段表示IP版本4（IPv4）地址的大小（以八位字节为单位），其值应为4。
opcode: This field SHALL be one to indicate a 1394 ARP request and two to indicate a 1394 ARP response.
操作码：该字段应为一个表示1394 ARP请求，两个表示1394 ARP响应。
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.
sender_max_rec：该字段应等于sender配置ROM总线信息块中的max_rec值。
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.
sspd：该字段应设置为发送方链路速度和物理层速度中的较小值。链路速度是链路可以发送或接收分组的最大速度；PHY速度是PHY可以发送、接收或重复数据包的最大速度。下表规定了sspd使用的编码；所有未指定的值都保留用于将来的标准化。
Table 2 - Speed codes
表2-速度代码
Value Speed
+---------------+
| 0 | S100 |
| 1 | S200 |
| 2 | S400 |
| 3 | S800 |
| 4 | S1600 |
| 5 | S3200 |
+---------------+
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_unicast_FIFO_hi和sender_unicast_FIFO_lo：这些字段一起应指定可用于接收第6节规定格式的IP数据报的发送方FIFO的48位偏移量。发送方单播FIFO的偏移量不得改变，除非由于电源重置。
sender_IP_address: This field SHALL specify the IP address of the sender.
发送方IP地址：此字段应指定发送方的IP地址。
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.
目标IP地址：在1394 ARP请求中，此字段应指定发送方希望得到响应的IP地址。在1394 ARP响应中，应忽略它。
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.
IP节点的配置ROM应包含本标准规定格式的单元目录。根据ISO/IEC 13213:1994的规定，机组目录应包含机组规格ID和机组SW版本条目。
The unit directory may also contain other entries permitted by ISO/IEC 13213:1994 or IEEE P1212r.
机组目录还可能包含ISO/IEC 13213:1994或IEEE P1212r允许的其他条目。
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.
Unit_Spec_ID条目是Unit目录中的直接条目，指定负责设备Internet协议功能架构定义的组织。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图6-单位规格ID输入格式
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.
单位规格ID的值应为0x00 005E，即IANA从IEEE RA获得的注册ID（RID）。该值表示IETF及其技术委员会负责维护本标准。
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.
Unit_SW_版本条目是Unit目录中的直接条目，与Unit_spec_ID一起指定定义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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图7-单元软件版本输入格式
The value of unit_sw_version SHALL be one, which indicates that the device complies with the normative requirements of this standard.
装置软件版本的值应为1，表明装置符合本标准的规范性要求。
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.
配置ROM中的文本描述符是可选的；当存在时，它们提供额外的描述性信息，以便于人类用户理解。支持IP的节点应将文本描述符与单元规格ID条目的“IANA”内容相关联，将文本描述符与单元SW版本条目的“IPv4”内容相关联。
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.
下图说明了由具有IP能力的节点实现的单元目录；它包括可选的文本描述符。尽管文本描述符的叶子不是单元目录的一部分，但为了简单起见，它们直接显示在单元目录之后。
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" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图9-样本单元目录和文本描述符
A unicast IP datagram may be transmitted to a recipient within a 1394 primary packet that has one of the following transaction codes:
单播IP数据报可在具有以下事务代码之一的1394主分组内发送给接收者：
tcode Description Arbitration
+--------------------------------------+
| 0x01 | Block write | Asynchronous |
| 0x0A | Stream packet | Isochronous |
| 0x0A | Stream packet | Asynchronous |
+--------------------------------------+
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).
块写入请求适用于需要1394链路级确认，但在数据包交付过程中不需要有限延迟（服务质量）的情况。
Isochronous stream packets provide quality of service guarantees but no 1394 link-level acknowledgement.
等时流数据包提供服务质量保证，但没有1394链路级确认。
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.
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:
无论采用的是异步还是等时的IP单播方法，单播IP数据报的发送方都有责任确定每个数据包中可能使用的最大数据有效负载。必要的信息可从以下方面获得：
- 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);
- 由1394总线管理器维护的速度映射，它提供本地串行总线上任意两个节点之间的最大传输速度。总线管理器分析总线拓扑以构建速度图；节点之间的最大传输速度反映了介入节点的能力。速度反过来意味着最大数据有效载荷（见表1）；
- the sender_max_rec field in a 1394 ARP response; or
- 1394 ARP响应中的sender_max_rec字段；或
- 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).
最大数据有效载荷应为发送方、接收方和所有介入节点的PHY实现的最大数据有效载荷中的最小值（最后一个隐含在发送方和接收方索引的SPEED_MAP条目中）。
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.
注意：SPEED_映射是从总线复位后所有1394节点发送的自我ID数据包中导出的。具有IP能力的节点可以直接观察自ID分组。
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.
服务质量最好的单播IP数据报应包含在1394块写入事务的数据有效负载内，该事务通过1394 ARP响应发送到源ID和发送方单播FIFO。
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.
注意：由于目标不再正常工作，可能由于报头CRC错误而未收到数据包，或者可能已成功收到数据包，但响应中发送的确认已损坏，因此可能不存在确认。
Unicast IP datagrams that require quality of service other than best-effort are beyond the scope of this standard.
除尽力而为外，要求服务质量的单播IP数据报不在本标准的范围内。
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.
广播IP数据报根据第4节的规范进行封装，并通过异步流数据包进行传输。没有为1394上的IP广播提供服务质量。用于IP广播的频道号由广播频道寄存器指定。
All broadcast IP datagrams SHALL use asynchronous stream packets whose channel number is equal to the channel field from the BROADCAST_CHANNEL register.
所有广播IP数据报应使用异步流数据包，其信道号等于广播信道寄存器中的信道字段。
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.
尽管1394允许在总线复位后最多1秒内使用先前分配的信道号，但具有IP能力的节点在其广播信道寄存器中的有效位为零时不得传输异步流数据包。由于有效位通过总线重置自动清除为零，因此在IRM分配频道号之前，禁止使用1394 ARP或广播IP。
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.
多播IP数据报根据第4节的规范进行封装，并通过流数据包进行传输。异步流用于尽力而为的IP多播；除尽力而为外的服务质量超出本标准的范围。
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多播应使用异步流数据包，其信道号等于广播信道寄存器中的信道字段。特别是，发送至224.0.0.1和224.0.0.2的数据报应使用该信道号。对于其他IP组播组地址的尽力而为IP组播可以使用不同的信道号，如果这样的信道号在使用之前被分配和通告，如下所述。
IP-capable nodes may transmit best-effort IP multicast only if one of the following two conditions is met:
只有满足以下两个条件之一时，具有IP能力的节点才可以传输尽力而为的IP多播：
- 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
- 流分组中的信道号等于广播信道寄存器中的信道号字段，且同一寄存器中的有效位为1；或
- for other channel number(s), some source of IP multicast has allocated and is advertising the channel number used.
- 对于其他频道号，某些IP多播源已分配并正在公布所使用的频道号。
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.
本节的其余部分描述了IP多播源和接收方在使用默认信道号以外的信道号时使用的多播信道分配协议（MCAP）。MCAP是一种协作协议；参与者通过特定串行总线上所有支持IP的节点使用的广播通道交换消息。
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.
警告：本文档未定义通过多个IP多播地址共享单个频道号（广播频道寄存器指定的默认频道号除外）的设施和方法。
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.
MCAP消息，无论是由多播信道所有者还是接收者发送，都作为GASP数据包的数据部分传输，其格式如下所示。消息的前四个八位字节是固定的；其余部分由可变长度元组组成，每个元组对特定IP多播组的信息进行编码。单个MCAP消息不应分段，并应封装在一个流数据包中，类型为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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图10-MCAP消息格式
Field usage in an MCAP message is as follows:
MCAP消息中的字段用法如下所示：
length: This field SHALL contain the size, in octets, of the entire MCAP message.
长度：此字段应包含整个MCAP消息的大小（以八位字节为单位）。
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. |
+----------------------------------------------------------------+
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.
消息数据：MCAP消息的其余部分长度可变，应包含零个或多个组地址描述符，格式如下所示。
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图11-MCAP组地址描述符格式
length: This field SHALL contain the size, in octets, of the MCAP group address descriptor.
长度：此字段应包含MCAP组地址描述符的大小（以八位字节为单位）。
type: This field SHALL have a value of one, which indicates a group address descriptor.
类型：该字段的值应为1，表示组地址描述符。
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.
频道：此字段仅对播发消息有效，在这种情况下，它应指定分配的频道号，范围为0到63（含63）。所有其他值均保留。
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.
速度：此字段仅对播发消息有效，在这种情况下，它应指定指定指定信道的流数据包的传输速度。表2规定了用于速度的编码。
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.
带宽：该字段应为零；它在组地址描述符中分配，以适应MCAP的未来扩展，这些扩展指定服务质量并利用串行总线的同步功能。
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.
组地址：此可变长度字段应指定特定IP多播组的IP地址。组_地址的长度（以八位字节为单位）是从组地址描述符的长度中减去长度字段中的12得到的。
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.
MCAP消息携带的信息仅对传输它们的本地串行总线有效。MCAP消息的接收者应忽略来自本地总线以外的所有MCAP消息，如下所示。发送方的源ID包含在封装的MCAP消息之前的GASP头中。MCAP消息的接收者应检查来自GASP报头的源ID的最高有效十位；如果它们不等于0x3FF或接收方节点ID寄存器的最高有效十位，则接收方应忽略该消息。
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.
在MCAP消息域中，通道映射的所有者由MCAP播发的GASP头中的source_ID字段标识。所有者是具有最大物理ID（源ID的最低有效六位）的节点。
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).
希望接收多播数据的具有IP能力的设备应首先确定存在于组地址和信道号之间的信道映射（如果有），而不是广播信道寄存器指定的默认信道。这样的设备可以观察广播信道上的MCAP广告以获得期望的信道映射。
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.
预期的多播接收者可以发送MCAP请求，以便请求多播信道所有者在下一个10秒间隔之前广播广告。MCAP征集请求的发起人应限制其传输速率。发送征集请求后，发起者不得发送另一个MCAP征集请求，直到10秒过去。
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.
在任何一种情况下，如果默认通道以外的组地址存在映射，则应在10秒内发出MCAP播发消息。在接收到描述一个或多个信道映射的MCAP播发消息后，预期的多播接收者可以在指定的信道号上接收IP数据报，直到过期时间。
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.
如果观察到多个指定相同组地址的MCAP播发消息，则应从具有最大物理ID的播发消息中获取信道号，该物理ID应从GASP报头的源_ID的最低有效六位中获取。
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.
如果在十秒钟内未收到特定组地址的MCAP播发消息，则除默认情况外，通道的多播源均未处于活动状态。要么没有多播数据，要么在默认信道上传输。
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.
一旦多播接收者观察到所需组地址的播发，它可以在默认广播频道或频道号上接收多播数据指示，但应继续监控同一组地址的MCAP广告的默认广播频道，以刷新正在使用的频道号的过期时间。
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.
希望在非默认信道上传输多播数据的具有IP能力的设备应首先确定另一个多播源是否已为组地址分配信道号。预期的多播源可以发送具有一个或多个组地址描述符的MCAP请求。
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.
无论是否发送了请求请求，预期多播源应监控广播频道的MCAP广告。如果组地址已存在通道映射，则应在10秒内收到MCAP播发。在这种情况下，预期多播源可以开始在所指示的信道号上传输IP数据报，并且可以继续这样做，直到它们的到期时间。多播源应监控MCAP播发，以刷新正在使用的频道号的过期时间。
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.
当没有其他多播源为组地址建立信道映射时，预期多播源可尝试根据IEEE P1394a中描述的过程从同步资源管理器的信道可用寄存器分配信道号。如果信道号分配成功，多播源应尽快公布新的信道映射。一旦在新分配的信道号的初始通告之后经过100 ms，多播源可以使用通告的信道号发送IP数据报。
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.
多播IP数据报可以在默认信道上传输，直到发送方观察（或传输）为多播地址指定非默认信道映射的广告为止。这允许多播从默认通道平滑过渡到显式分配的通道。
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.
一旦一个多播源公布了一个频道映射，它应继续为频道映射发送MCAP公告，除非它a）将所有权转移到另一个多播源，b）允许频道映射在没有转移的情况下过期，或c）在频道映射重叠的情况下，放弃对到另一个多播源的通道映射的控制。
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).
每个多播源应定期广播其分配了不同于默认多播信道号的信道号的所有IP多播组地址的广告。广告应包括一条操作码为零的MCAP消息，该消息包含一个或多个组地址描述符（每个组地址分配一个频道号，而不是广播频道寄存器指定的频道号）。
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.
在每个组地址描述符中，组地址和通道字段将IP多播组地址与串行总线通道号相关联。速度字段指定允许IP多播组中的任何发送方传输数据的最大1394速度。expiration字段指定通道映射不再有效的当前时间或未来时间。除非频道所有者打算放弃所有权（如下文9.7所述），否则到期时间应至少为60秒，从广告传输时开始计算。
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.
在频道映射的所有者发起后续广告的传输之前，从其最近广告的传输开始的时间不得超过10秒。通道映射的所有者应在收到请求后尽快发送MCAP广告以响应请求。
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.
当两个预期的多播源希望传输到同一IP多播组，且组地址不存在信道映射时，两者都有可能分配信道号，并且都将公布信道映射。这些通道映射重叠，即同一组地址映射到MCAP播发中的多个通道号，过期时间不为零。
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
多播信道所有者应监控MCAP播发，以检测重叠信道映射。出于重叠通道检测的目的，应忽略过期字段值小于60的MCAP播发。当一个重叠的通道
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.
如果检测到映射，则不需要具有最大物理ID的所有者（由GASP标头中源_ID的最低有效六位确定）采取任何操作。物理ID较小的所有者发布的频道号无效；其所有者应停止传输使用无效通道号的IP数据报和MCAP广告。一旦这些通道映射过期，其所有者应按照下文9.8所述，解除分配任何未使用的通道号。
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.
检测到重叠信道映射的MCAP播发的接收者应忽略来自具有较小物理ID的多播信道所有者的播发，并且不得传输使用无效信道号的IP数据报。即使由于重叠而忽略其他通道映射，单个MCAP播发中的某些通道映射也可能有效。
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.
希望发布映射的现有信道映射的所有者应启动计时器，以测量映射及其相关信道预期发布之前的剩余时间。在计时器倒数为零之前，所有者应继续为受影响的频道发送MCAP广告，但应调整每个广告中的过期时间，以反映频道被取消分配之前的剩余时间。如果所有者在计时器达到零之前无法发送MCAP广告，则应启动总线复位。否则，打算发布映射的所有者发送的过期时间序列应随着每个后续广告的发布而减少。如果其他多播源使用相同的信道映射，并且观察到到期时间小于或等于60秒，则它们应开始为信道映射发送MCAP广告，刷新到期时间大于或等于60秒，以保持信道映射。多个源之间发生的任何争用，如试图声明信道映射的所有权，应按照9.8中所述解决。如果原始所有者在其自己的计时器到期之前观察到要放弃的频道的MCAP广告，则不得取消分配频道号。
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.
否则，如果所有者的计时器到期，而另一节点未观察到MCAP播发，则信道号的所有者随后应按照9.8中所述解除分配信道。如果频道映射的预期所有者观察到到期字段为零的MCAP播发，则从前所有者有序传输频道失败。预期所有者应停止接收和传输过期的信道号，或按照9.4规定分配不同的信道号。
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.
当信道映射的所有权从一个多播源转移到另一个多播源时，可能有多个设备声明所有权。这会导致冗余MCAP播发，由不同的源传输，每个源指定相同的多播组地址和通道。类似于9.6的程序应解决信道所有权的争用。
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.
多播信道所有者应监控MCAP播发，以检测冗余信道映射。出于冗余通道检测的目的，应忽略过期字段值小于60的MCAP播发。当检测到冗余通道映射时，不需要具有最大物理ID（由GASP报头的源_ID的最低有效六位确定）的所有者采取任何操作。具有较小物理ID的所有者应停止传输冗余通道号的MCAP广告，但不得取消分配通道号。
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.
自最近一次MCAP播发以来已过过期秒时，通道映射将过期。此时，多播接收者应停止接收过期频道号。同样在此时，频道映射的所有者应发送到期清除为零的MCAP广告，并应继续发送此类广告，直到频道映射到期后30秒。一旦额外的30秒时间过去，通道映射的所有者应取消分配通道号，并在同步资源管理器的通道可用寄存器中指示其可用性。
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.
如果具有IP能力的设备观察到到期字段为零的MCAP播发，则在最近一次此类播发后30秒之前，不得尝试分配任何指定的频道号。
A bus reset SHALL invalidate all multicast channel mappings and SHALL cause all multicast recipients and senders to zero all MCAP advertisement interval timers.
总线重置应使所有多播信道映射无效，并应使所有多播接收者和发送者将所有MCAP播发间隔计时器归零。
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.
多播信道映射的先前所有者可以从同步资源管理器的信道可用寄存器重新分配信道号，并在分配信道后立即恢复MCAP播发的广播。如果试图重新分配信道，则先前的所有者应使用在总线重置之前分配的相同信道号，并且可以在总线重置完成后立即开始重新分配，只要重复使用相同的信道号。如果先前的所有者选择分配不同的通道号，则在尝试分配新的通道号之前，应等待总线复位完成后至少一秒钟。
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.
在总线复位完成后至少10秒之前，非默认信道上的预期或先前多播接收者或发送者不得发送MCAP请求。在观察到或传输IP多播组地址的MCAP广告之前，不得接收或传输默认信道以外的多播数据。
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.
在总线重置之前，除默认信道外，未拥有IP多播组地址信道映射的预期或先前多播发送器不得尝试从同步资源管理器的信道可用寄存器分配信道号，直到完成重置后至少10秒总线复位。在该10秒延迟之后，多播的预期或先前发射机可遵循9.4规定的程序分配信道号并公布信道映射。
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.
本文件要求IANA创建和管理新的名称空间（注册表）。这种注册的需要源于协议接口由符合ISO/IEC 13213:1994《CSR体系结构》的总线标准唯一标识的方法。第6节对此进行了更详细的解释；其实质是，一个全局唯一的48位数字应标识指定协议接口的文件。48位数字是0x00 005E（IEEE注册机构授予IANA的注册ID或RID）和IANA管理的第二个24位数字的串联。
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.
IEEE RA建议选择第二个24位数字的管理策略，以便在可能的值范围内最大化可用数字的数量。特别是，IEEE RA建议分配方案不将结构应用于数字（例如，数字内版本字段的分配），因为这将浪费大部分范围。
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.
新的名称空间是“CSR协议标识符”。零值和0xFF FFFF保留，IANA不应分配。值1分配给此文档。剩余的数字应由IANA管理，并根据需要分配，以确定成为IESG标准跟踪文件的互联网草案。
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.
无论IANA选择何种分配方法，应在一个或多个互联网站点上维护所有分配版本号的登记册，并应明确标识RID和版本号组合确定的相关标准。
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.
本文档指定使用不安全链路层串行总线传输IPv4数据报。串行总线易受拒绝服务攻击；设备也可能窃听数据或伪造身份。使用IPv6的串行总线的实施者应在应用程序或其他层中考虑适当的对策。
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.
本文件代表了IP/1394工作组的努力。编辑希望感谢所有积极参与者在reflector或面对面会议上所做的贡献，这些贡献提高了技术内容。
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
[1] IEEE标准1394-1995，高性能串行总线标准
[2] ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture for Microcomputer Buses
[2] ISO/IEC 13213:1994，微机总线的控制和状态寄存器（CSR）体系结构
[3] IEEE Project P1394a, Draft Standard for a High Performance Serial Bus (Supplement)
[3] IEEE项目P1394a，高性能串行总线标准草案（补充）
[4] IEEE Project P1394b, Draft Standard for a High Performance Serial Bus (Supplement)
[4] IEEE项目P1394b，高性能串行总线标准草案（补充）
[5] Postel, J., "Internet Protocol Darpa Internet Program Protocol Specification", RFC 791, September 1981.
[5] Postel，J.，“互联网协议Darpa互联网程序协议规范”，RFC 7911981年9月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94602
Peter Johansson Congrent Software，Inc.加利福尼亚州伯克利市科罗拉多大道98号，邮编94602
Phone: (510) 527-3926 Fax: (510) 527-3856 EMail: pjohansson@aol.com
电话：（510）527-3926传真：（510）527-3856电子邮件：pjohansson@aol.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。