Network Working Group P. Johansson
Request for Comments: 2734 Congruent Software, Inc.
Category: Standards Track December 1999
IPv4 over IEEE 1394
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（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.
この文書は、インターネットプロトコルバージョン4（IPv4）のデータグラムの輸送のために、高性能シリアル・バス（およびそのサプリメント）のためのIEEE STD 1394から1995まで、標準を使用する方法を指定します。その目的のために必要なメソッド、データ構造およびコードを定義します。これらは、パケットフォーマット及びデータグラムのカプセル化方法だけでなく、アドレス解決プロトコル（ARP 1394）とマルチキャストチャネル割当プロトコル（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
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.
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.
：1994 1394はCSRアーキテクチャ、ISO / IEC 13213に準拠して相互接続（バス）です。共有物理メディア上のノード間でシリアルバスを許可通信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ビット固定アドレス指定方式として実装されていることをメモリマップのアドレス空間を記述する。アドレス空間内で、10ビットは（1,023バスの最大まで）バスIDのために割り当てられ、残りの48ビット（オフセット）は、ノードごとのアドレス空間を説明しながら、6個（バス当たり63まで）は、ノードの物理的なIDのために割り当てられています256テラバイトの。 CSRアーキテクチャは、慣例により、異なる行動特性を持つ2つの領域にノードのアドレス空間を分割します。 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.
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 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リンク層は、両方の確認（認知）と未確認パケットとパケット配信サービスを提供します。サービスの二つのレベルが用意されています：「アイソクロナス」パケットが有界レイテンシーで配信されることが保証されている一方で、「非同期」パケットは、ベストエフォート方式で送信されます。確認されたパケットは常に非同期であるが、未確認パケットは、非同期または等時性のいずれであってもよいです。データペイロードは、実装に応じて変化し、1つのオクテットから伝送速度によって決定される最大値までの範囲とすることができる（S400でそれが2048オクテットであるS100と命名100Mbpsで、で、最大非同期データペイロードは512オクテットです）。
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.
この文書で使用されている場合は、キーワード「MAY」は、「オプション」、「推奨」、「REQUIRED」、「NOT SHALL」「（SHALL）」、および要件と選択性のレベルを区別し、にある「ない（SHOULD NOT）」「べきです」 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.
EXPECTED：この規格で想定した設計モデルでは、ハードウェアやソフトウェアの振る舞いを記述するために使用するキーワード。その他のハードウェアおよびソフトウェアの設計モデルも実現することができます。
IGNORED: A keyword that describes bits, octets, quadlets or fields whose values are not checked by the recipient.
IGNORED：値受信者によって確認されていないビット、オクテット、カドレットまたはフィールドの説明をキーワード。
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.
アドレス解決プロトコル：ハードウェア（1394）ノードのIPアドレスからIPノードのアドレスを決定するためのリクエスタ方法。
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.
マルチキャストチャネル所有者：1つまたは複数のマルチキャストアドレスのためのチャネルを割り当てられ、IPマルチキャストグループ内の他の参加者にこれらのチャネルマッピング（単数または複数）を通信するためにMCAP広告を送信したマルチキャストソース。複数のソースが同じチャネル番号の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.
オクテット：8ビットのデータ。
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.
クアドレット：データの4つのオクテット、または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.
ストリームパケット：ブロックデータペイロードを含んは0x0Aのトランザクションコードと1394プライマリパケット。ストリームパケットは、使用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
CSR制御およびステータスがCRC巡回冗長チェックサムEUI-64拡張一意識別子、64ビットGASPグローバル非同期ストリームパケットIPインターネットプロトコルレジスタ1394のARPアドレス解決プロトコル（1394年に特異的）（この文書内で、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.
進数と16進数は、この規格内で使用されます。社説慣例により、小数点以下の数字が最も頻繁量や回数を表すために使用されています。アドレスが均一表される値は、10進形式でより進形式でより明白である根本的な構造を有する場合にも使用される16進数で表されます。
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.
小数点以下の数字はアラビア数字によって、またはその英語名で表現されています。 A 9および - - 16進数0xを接頭文字から数字で表されているが0に設定さ読みやすさのためにF.、16進数は、スペースで区切られた4桁のグループに分離されます。
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で指定された一般的な形式のコンフィギュレーションROMを実施しなければならない：1994及び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;
- 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 |
+------------------------------------+
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.
注：S800と高速の速度で最大データペイロードを低減することができる（しかし、増加されません）IEEE P1394bによる標準化の結果として。
The maximum data payload for asynchronous requests and responses may also be restricted by the capabilities of the sending or receiving node(s); this is specified by max_rec in either the bus information block or 1394 ARP response.
非同期の要求と応答のための最大データペイロードはまた、送信または受信ノード（単数または複数）の能力によって制限されてもよいです。これは、バス情報ブロックまたは1394のARP応答のいずれかでmax_recによって指定されます。
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）より小さくてもよいです。これは、カプセル化フォーマットはまた、IPデータグラムの1394リンクレベルの断片化と再構築を許可する必要があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
source_IDフィールドには、送信ノードのノードIDを指定すると、送信者のNODE_IDSレジスタの上位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.
specifier_ID_hiとspecifier_ID_loフィールド一緒に、IANAにIEEE登録機関（RA）によって割り当てられた24ビットの組織的一意識別子（OUI）の値は0x00 005Eを含まなければなりません。
The version field SHALL be one.
バージョンフィールドは1でなければなら。
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フォーマットは、非同期ストリームパケット形式のデータペイロードの最初の二つのquadletを利用するので、表1に引用された最大のペイロードを効果的に8つのオクテットによって低減されます。フォロー句で、データペイロードの最初のクワドレットへの言及は、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Unfragmented encapsulation header format
図2 - 非分割カプセル化ヘッダ・フォーマット
The lf field SHALL be zero.
LFフィールドはゼロでなければなら。
The ether_type field SHALL indicate the nature of the datagram that follows, as specified by the following table.
以下の表で指定されETHER_TYPEフィールドは、次のデータグラムの性質を示さなければなりません。
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_TYPEの異なる値によって識別される他のネットワークプロトコルは、本明細書で定義されるカプセル化フォーマットを使用してもよいが、そのような使用は、この文書の範囲外です。
In cases where the length of the datagram exceeds the maximum data payload supported by the sender and all recipients, the datagram SHALL be broken into link fragments; the first two quadlets of the data payload for the first link fragment SHALL conform to the format shown below.
データグラムの長さは、送信者とすべての受信者がサポートする最大データペイロードを超える場合には、データグラムはリンクフラグメントに分割しなければなりません。第一リンクフラグメントのデータペイロードの最初の二つクワドレットは、以下に示すフォーマットに適合しなければなりません。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lf|rsv| datagram_size | ether_type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dgl | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - First fragment encapsulation header format
図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+------------------------+
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データグラム全体のエンコードされたサイズ。 datagram_sizeの値は、IPデータグラムのすべてのリンクのフラグメントに対して同一でなければならないし、データグラムのIPヘッダーの全長の値より1つ少なくしなければならない（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：このフィールドは、最初のリンクフラグメント中に存在するとIPv4データグラムを示す0x0800での値を持つものとします。
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.
fragment_offset：このフィールドは、目以降のリンクフラグメントに存在し、IPデータグラムの先頭からのオフセット、オクテットで、フラグメントを指定しなければなりません。データグラム（IPヘッダの開始）の最初のオクテットは、ゼロのオフセットを有します。第一リンクフラグメント中fragment_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：DGL（データグラムラベル）の値は、IPデータグラムのすべてのリンク断片で同じものでなければなりません。送信者は、連続した、断片化されたデータグラムのDGLをインクリメントしなければなりません。 DGLのインクリメント値がゼロに65,535戻ってからラップしないものとします。
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データグラムは、関係なく、送信（ブロック書き込み要求又はストリームパケット）の形態の上記のカプセル化ヘッダーの1つが先行するものとします。これは、それらの送信のモードに関係なく、データグラムの均一なソフトウェア処理が可能となります。
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データグラムの受信者は、単一のデータグラムからすべてのリンク断片を同定するために送信者のsource_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.
リンクフラグメントを受信すると、受信者はfragment_offsetによって指定された場所でIPデータグラム再構成バッファ内の（カプセル化ヘッダに存在しない）データペイロードを配置することができます。再構成バッファのサイズはdatagram_sizeから決定することができます。
If a link fragment is received that overlaps another fragment identified by the same source_ID and dgl, the fragment(s) already accumulated in the reassembly buffer SHALL be discarded. A fresh reassembly may be commenced with the most recently received link fragment. Fragment overlap is determined by the combination of fragment_offset from the encapsulation header and data_length from the 1394 packet header.
リンク断片が同一のsource_IDとDGLによって識別別の断片をオーバーラップする受信された場合、既に再構成バッファに蓄積された断片（単数または複数）は捨てられるもの。新鮮な再構築は、最も最近受信したリンクフラグメントを開始することができます。断片の重複1394パケットヘッダからカプセル化ヘッダとDATA_LENGTHからfragment_offsetの組み合わせによって決定されます。
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データグラムと送信者（S）の全リンクフラグメントを廃棄します。
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 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要求はブロードキャストIPデータグラムと同じ手段で送信しなければなりません。 1394のARP応答は、同じ方法で送信されてもよいし、彼らは1394 ARPリクエストによって識別されるsender_unicast_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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も参照）。 （非同期ストリームパケット又はブロック書き込み要求のパケットのヘッダのGASPヘッダから得られたかどうか）のsource_IDフィールドの最上位10ビットが0x3FFどちらかに等しい場合を除き1394のARP要求または応答の受信者はそれを無視します受信者のNODE_IDSレジスタの上位10ビット。
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.
hardware_type：このフィールドは、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.
protocol_type：このフィールドは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_addr_len：このフィールドは、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要求を示すために、1と2でなければなら。
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_unique_ID：このフィールドは、送信側のノードユニークIDを含まなければならないと送信者のバス情報ブロックに指定されたものと同じものでなければなりません。
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：このフィールドは、送信者のコンフィグレーション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速度は、PHYは、送信、受信またはパケットを繰り返すことができる最大速度です。以下の表は、SSPDに使用されるエンコーディングを指定します。指定されていないすべての値は、将来の標準化のために予約されています。
Table 2 - Speed codes
表2 - スピード・コード
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：一緒にこれらのフィールドは、送信者のユニキャストFIFOのオフセット部6で指定した形式のIPデータグラムの受信に利用可能な送信者のFIFOのオフセットを48ビットの結果を除き、変更しないものと特定しなければなりません電源リセット。
sender_IP_address: This field SHALL specify the IP address of the sender.
sender_IP_address：このフィールドは、送信者の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.
target_IP_address：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は、この規格で指定された形式でユニットディレクトリを含まなければなりません。 1994：ISO / IEC 13213で指定されたユニットディレクトリは、Unit_Spec_IDとUnit_SW_Versionエントリを含まなければなりません。
The unit directory may also contain other entries permitted by ISO/IEC 13213:1994 or IEEE P1212r.
1994またはIEEE P1212r：単位のディレクトリには、ISO / IEC 13213によって許可され、他のエントリが含まれていてもよいです。
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エントリは、デバイスのインターネットプロトコル機能のアーキテクチャの定義を担当する組織を指定するユニットディレクトリで即時エントリです。
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 - Unit_Spec_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.
unit_spec_IDの値が0x00で005E、IEEE RAからIANAによって得られた登録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_Versionエントリはunit_spec_IDと組み合わせて、ユニットのソフトウェアインタフェースを定義するドキュメントを特定し、ユニットディレクトリに即時のエントリです。
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 - Unit_SW_Versionエントリフォーマット
The value of unit_sw_version SHALL be one, which indicates that the device complies with the normative requirements of this standard.
unit_sw_versionの値は、デバイスがこの規格の規定の要件に準拠していることを示す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対応ノードはUnit_Spec_IDエントリとUnit_SW_Versionエントリの「IPv4の」のコンテンツとテキスト記述子に「IANA」のコンテンツとテキスト記述子を関連付けるべきです。
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" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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データグラムは、次のトランザクションコードのうちの1つを有する1394プライマリパケット内の受信者に送信することができます。
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.
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);
- ローカル・シリアル・バス上の任意の2つのノード間の最大伝送速度を提供する1394台のバスマネージャによって維持SPEED_MAP。バスマネージャは、スピードマップを構築するためにバストポロジーを解析します。ノード間の最大伝送速度は、介在するノードの能力を反映しています。今度は速度が最大データペイロードを暗示する（表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).
最大データ・ペイロードは、送信者、受信者、およびすべての介在するノードの物理層（最後の送信者と受信者によってインデックスさ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_MAPは、バスリセットの後、すべての1394個のノードによって送信された自己識別パケットから導出されます。 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.
その品質のサービスのベストエフォート1394件のブロック書き込みトランザクションのデータペイロード内に含まれるものとする（SHALL）されたユニキャストIPデータグラムは、1394 ARP応答から取得したのsource_IDとsender_unicast_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の仕様に従ってカプセル化されると、非同期ストリームパケットにより搬送されます。 IP放送のためのサービス提供のない品質はBROADCAST_CHANNELレジスタで指定されたIP放送のために使用されるチャネル数が1394の上にありません。
All broadcast IP datagrams SHALL use asynchronous stream packets whose channel number is equal to the channel field from the BROADCAST_CHANNEL register.
すべてのブロードキャストIPデータグラムは、そのチャンネル番号BROADCAST_CHANNELレジスタからのチャンネルフィールドに等しい非同期ストリームパケットを使用しなければなりません。
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バスリセットに続く第2最長1のために以前に割り当てられたチャネル番号（複数可）の使用を可能にするが、IP対応のノードはいつでも非同期ストリーム・パケットを送信しないものとし、そのBROADCAST_CHANNELレジスタの有効ビットはゼロです。有効ビットが自動的にバスリセットによってゼロにクリアされるので、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マルチキャストは、そのチャンネル番号BROADCAST_CHANNELレジスタからのチャンネルフィールドに等しい非同期ストリームパケットを使用しなければなりません。具体的には、データグラムは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対応のノードには、次の2つのいずれかの条件が満たされる場合にのみ、ベストエフォート型の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
- ストリームパケット内のチャネル番号はBROADCAST_CHANNELレジスタのチャネル番号フィールドと同じであり、同じレジスタの有効ビットは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マルチキャストアドレスで（BROADCAST_CHANNELレジスタで指定されたデフォルトのチャンネル番号以外の）単一チャネル番号の共用のための施設やメソッドを定義していません。
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パケットのデータ部分として輸送され、フォーマットは以下に例示しています。メッセージの最初の4つのオクテットは固定されています。残りは、特定のIPマルチキャストグループに関する情報をエンコード各々が可変長タプルからなります。個々のMCAPメッセージは断片化されてはならないと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 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. |
+----------------------------------------------------------------+
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
チャンネル：このフィールドは、包括的な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.
group_address：この可変長フィールドには、特定のIPマルチキャストグループのIPアドレスを指定しなければなりません。 group_addressの長さは、オクテット単位で、長さフィールドから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メッセージを無視します。送信者ののsource_IDは、カプセル化されたMCAPメッセージに先行するGASPヘッダに含まれています。 MCAPメッセージの受信者は、GASPヘッダーからのsource_IDの最も重要な10ビットを検査しなければなりません。彼らは0x3FFもしくは受信者のNODE_IDSの最も重要な10ビットレジスタのいずれかに等しくない場合、受信者はメッセージを無視しなければなりません。
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、のsource_IDの最下位6ビットを有するノードです。
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対応デバイスは、第一のグループアドレスとBROADCAST_CHANNELレジスタによって指定されたデフォルトチャネル以外のチャネルの数との間に存在するチャネルマッピング（もしあれば）を確認するものとします。そのようなデバイスは、所望のチャネルマッピング（S）のためのブロードキャストチャネル上の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.
意図したマルチキャスト受信者は、次の10秒の間隔より早く広告をブロードキャストするマルチキャストチャネル所有者（複数可）を要求するためにMCAPの勧誘要求を送信してもよいです。 MCAP懇請リクエストの発信元は、それらが送信されるレートを制限するものとします。 10秒が経過するまで勧誘要求を送信するに引き続いて、発信者は別のMCAP懇請リクエストを送信してはなりません。
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.
マッピングがデフォルトチャネル以外のグループアドレスのために存在する場合はいずれの場合も、MCAP宣伝メッセージは10秒以内に期待されています。一つ以上のチャンネルマッピングを説明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は、メッセージが同じグループ・アドレスを指定することが観察されたアドバタイズする場合、チャンネル番号は、GASPヘッダからのsource_IDの最下位6ビットから得なければならない最大の物理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宣伝メッセージが10秒以内に特定のグループアドレスに対して受信された場合、マルチキャストソース（S）は、デフォルト以外のチャネル（S）のためにアクティブではありません。そこには、マルチキャストデータがないか、それがデフォルトのチャネル上で送信されているがありどちらか。
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.
マルチキャスト受信者は、所望のグループアドレスのための広告を観察した後、それはデフォルトの放送チャンネルまたは示されたチャンネル番号（S）のいずれかでマルチキャストデータを受信することができるが、それは、同じグループのためのMCAP広告のデフォルトのブロードキャストチャネルを監視し続けるSHALL使用中のチャンネル番号（複数可）の有効期限を更新するために取り組みます。
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対応デバイス。意図したマルチキャストソースは、1つ以上のグループアドレス記述子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広告のための放送チャネルを監視しなければなりません。チャネルマッピングが既にグループアドレスのために存在している場合、MCAP広告が10秒以内に受信されなければなりません。この場合、意図されたマルチキャストソースは、示されたチャンネル番号（複数可）上の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に記載の手順に従って、アイソクロナスリソースマネージャのCHANNELS_AVAILABLEレジスタからチャンネル番号を割り当てることを試みることができます。チャンネル番号の割り当てが成功した場合は、マルチキャストソースはできるだけ早く新しいチャンネルマッピングを広告するものとします。 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.
マルチキャストソースはチャンネルマッピングをアドバタイズした後、それはどちらかのa）は、別のマルチキャストソースに所有権を転送しない限り、チャンネルマッピングのためのMCAP広告を送信し続けるものと、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マルチキャストグループアドレスの広告を放送するものとします。広告は、1つ以上のグループ・アドレス・ディスクリプタ（BROADCAST_CHANNELレジスタによって指定された以外のチャンネル番号を割り当てられた各グループアドレスについて1つ）が含まれ、ゼロのオペコードを有する単一の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.
各グループ・アドレス・ディスクリプタ内、group_addressおよびチャネルフィールドは、シリアル・バス・チャンネル番号とIPマルチキャストグループアドレスを関連付けます。速度場は、IPマルチキャストグループ内の送信者のいずれかがデータを送信することが許可される最大1394の速度を指定します。有効期限フィールドには、現在の時間またはチャネルマッピング（s）は、もはや有効である後に将来の時間を指定します。チャンネル所有者は、（下記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.
2つの意図したマルチキャストソースが同じ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 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.
マルチキャストチャネルの所有者は重複チャネルのマッピングを検出するためにMCAP広告を監視しなければなりません。その有効期限フィールド60より小さい値を持つMCAP広告は重複チャネル検出の目的のために無視されます。重複チャンネルマッピングが検出された場合、最大の物理ID（GASPヘッダーからのsource_IDの最下位6ビットによって決定される）を有する所有者は、任意のアクションを取る必要はありません。小さな物理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広告を送信することができない場合は、バスリセットを開始しなければなりません。そうでない場合は、マッピングを解放するように意図所有者によって送信された有効期限のシーケンスは、各後続の広告に減少SHALL。他のマルチキャストソース（S）が同じチャンネルマッピングを使用して未満または60秒に等しい有効期限を遵守している場合、それらはより大きい又は維持する60秒に等しいリフレッシュ満了時間でチャネルマッピングのMCAP広告を送信開始しなければなりませんチャネルマッピング。 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に記載されるようにそうでなければ、チャンネル番号の所有者は、その後、チャネルを解放SHALL。チャンネルマッピングの意図された所有者は、その有効期限フィールドにゼロであるMCAP広告を観察する場合、前所有者からチャネル（単数または複数）の整然とした転送が失敗しました。意図した所有者が期限切れのチャンネル番号（S）の受信と送信を停止、または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ヘッダーからのsource_IDの最下位6ビットによって決定される）を有する所有者は、任意のアクションを取る必要はありません。小さな物理IDの所有者（複数可）は、冗長チャンネル番号のMCAP広告の送信を停止SHALLが、チャンネル番号の割り当てを解除ないもの。
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広告から経過した時に、チャンネルマッピングの有効期限が切れます。このとき、マルチキャスト受信者が期限切れのチャンネル番号（複数可）の受信を停止しなければなりません。また、この時点で、チャネルマッピング（S）の所有者は、ゼロにクリア期限付きMCAP広告を送付すると30秒チャネルマッピングの有効期限からの経過するまで、そのような広告を送信し続けるものとします。この付加的な30秒の期間が経過すると、チャネルマッピング（S）の所有者は、チャンネル番号（複数可）を解放し、アイソクロナスリソースマネージャのCHANNELS_AVAILABLEレジスタにおけるそれらの利用可能性を示さなければなりません。
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.
マルチキャストチャネルマッピングの前の所有者は、アイソクロナスリソースマネージャのCHANNELS_AVAILABLEレジスタからのチャンネル番号を再配分し、チャネルが割り当てられるとすぐにMCAP広告の放送を再開してもよいです。チャネルの再配置が試みられた場合は、前所有者があれば、同じチャンネル番号が再利用されるようにリセットバスリセットの前に割り当てられた同じチャネル番号を使用する必要があり、バスの完了時に直ちに再割り当てを開始することができます。前所有者が異なるチャンネル番号を割り当てることを選択した場合、少なくとも一つの第二は、新たなチャンネル番号を割り当てる前に、バスリセットの完了経過するまで、それが待つSHALL。
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懇請リクエストを送信してはなりません。デフォルトのチャネル以外のマルチキャストデータを受信したりMCAP広告を観察したり、IPマルチキャストグループアドレスに送信されるまで送信されないものとします。
Intended or prior transmitters of multicast on other than the default channel that did not own a channel mapping for the IP multicast group address prior to the bus reset SHALL NOT attempt to allocate a channel number from the isochronous resource manager's CHANNELS_AVAILABLE register until at least ten seconds have elapsed since the completion of the bus reset. Subsequent to this ten second delay, intended or prior transmitters of multicast may follow the procedures specified by 9.4 to allocate a channel number and advertise the channel mapping.
意図または少なくとも10秒まで、アイソクロナスリソースマネージャのCHANNELS_AVAILABLEレジスタからチャンネル番号を割り当てようとしないものとバスリセット前にIPマルチキャストグループアドレスのためのチャネルマッピングを所有していなかったデフォルトチャンネル以外でのマルチキャストの前に送信機バスリセットが完了してから経過しました。マルチキャストの、この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によって新しい名前空間（レジストリ）の作成と管理を必要とします。 1994、CSRアーキテクチャ：そのようなレジストリの必要性は、プロトコルインターフェイスを一意にISO / IEC 13213に準拠したバス規格によって識別される方法から生じます。これは、セクション6で詳細に説明します。本質は、グローバルに一意の48ビットの数は、プロトコル・インタフェースを指定する文書を識別しなければならないということです。 48ビットの数が0x00の005Eの連結（登録ID、またはRID、IEEE登録機関によってIANAに付与された）と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データグラムの輸送のための無担保リンク層、シリアルバスの使用を指定します。シリアル・バスは、サービス拒否攻撃に対して脆弱です。デバイスは、データまたは存在鍛造アイデンティティを盗聴することも可能です。 IPv4のシリアル・バスを利用実装者は、アプリケーションや他の層内の適切な対策を検討すべきです。
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ワーキンググループの取り組みを表しています。エディタは、反射板の上または技術的な内容を進めてきた対面会議、のいずれかで、すべてのアクティブな参加者の貢献を認めることを希望します。
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 STD 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]ポステル、J.、 "インターネットプロトコルDARPAインターネットプログラムプロトコル仕様"、RFC 791、1981年9月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[6]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月を。
Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94602
ピーター・ヨハンソン合同ソフトウェア株式会社98コロラドアベニューバークレー、CA 94602
Phone: (510) 527-3926 Fax: (510) 527-3856 EMail: pjohansson@aol.com
電話：（510）527-3926ファックス：（510）527-3856 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。