[要約] RFC 2734は、高速シリアルインターフェース規格であるIEEE 1394（いわゆるFireWireやi.LINK）ネットワーク上でIPv4パケットを転送するための仕様を定義しています。IEEE 1394の等時性（Isochronous）および非同期転送を用いたIPパケットのカプセル化、ならびにARP（Address Resolution Protocol）のマッピング手順を規定しています。ホームネットワークや家電機器間の高速なIP通信を実現するための技術基準を提供することを目的としています。
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.
Copyright（c）The Internet Society（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
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.
このドキュメントは、インターネットプロトコルバージョン4（IPv4）データグラムの輸送のために、高性能シリアルバス（およびそのサプリメント）の標準であるIEEE STD 1394-1995の使用方法を指定しています。その目的のための必要な方法、データ構造、およびコードを定義し、アドレス解像度プロトコル（1394 ARP）およびマルチキャストチャネル割り当てプロトコル（MCAP）のメソッドをさらに定義します。どちらもシリアルバスに固有です。
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の範囲の速度で共有された物理メディアを介したノード間の通信を許可します。コンシューマー電子アプリケーション（デジタルVCR、ステレオシステム、テレビ、カムコーダーなど）と従来のデスクトップコンピューターアプリケーション（大容量ストレージ、プリンター、テープなど）の両方が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（最大1,023バスのバスまで）に10ビットが割り当てられ、6つはノード物理ID（バスあたり最大63）に割り当てられ、残りの48ビット（オフセット）はノードあたりのアドレススペースを説明します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.
64ビットアドレス内では、16ビットノードID（バスIDおよび物理ID）はネットワークハードウェアアドレスに類似していますが、1394ノードIDは可変であり、1つ以上のノードが追加されるたびに再割り当てされる可能性があります。バスから削除されました。
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ワーキンググループで進行中です。将来の標準で拡張されない限り、このドキュメントで指定された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リンクレイヤーは、確認されたパケットと未確認のパケットの両方を備えたパケット配信サービスを提供します。2つのレベルのサービスが利用可能です。「非同期」パケットが最良のエフォルトベースで送信され、「等学状態」パケットが境界レイテンシで配信されることが保証されています。確認されたパケットは常に非同期ですが、未確認のパケットは非同期または等時期のいずれかです。データペイロードは実装によって異なり、1オクテットから送信速度によって決定される最大値までの範囲です（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.
このドキュメントで使用する場合、キーワードは「可能性があります」、「オプション」、「推奨」、「必須」、「shall」、「shall "、" wuth "wuth"は要件とオプションを区別してはなりません。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: オブジェクト（ビット、オクテット、クワドレット、フィールド）またはこれらのオブジェクトに割り当てられたコード値のいずれかを説明するために使用されるキーワードです。そのオブジェクトまたはコード値は将来の標準化のために確保されています。RESERVEDオブジェクトには定義された意味がなく、その作成者によってゼロに設定されなければならず (SHALL)、あるいは将来の標準の開発時にはそのような標準で指定された値に設定されなければなりません。RESERVEDオブジェクトの受信者はその値を確認してはなりません (SHALL NOT)。本標準によってコード値が定義されているオブジェクトの受信者は、その値を確認し、RESERVEDコード値を拒絶しなければなりません (SHALL)。
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.
bus ID: 相互接続された複数のバスのグループ内で特定のバスを一意に識別する10ビットの数値です。bus IDは、ノードの16ビットのnode IDの最上位部分です。値0x3FFはローカルバスを指定します。要求内のbus IDが0x3FFまたはそのノードに明示的に割り当てられたbus IDのいずれかである場合、ノードはその6ビットのphysical ID宛てのリクエストに応答しなければなりません (SHALL)。
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つ以上のマルチキャストアドレスにチャネルを割り当て、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.
Octet：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
1394 ARPアドレス解像度プロトコル（1394に固有）CSR制御およびステータスレジスタCRC循環冗長チェックサムEUI-64拡張ユニークな識別子、64ビットGASPグローバル非同期ストリームパケットIPインターネットプロトコル（このドキュメント内、IPv4内）
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.
この標準内で10進数と16進数が使用されます。編集規則により、10進数は、量またはカウントを表すために最も頻繁に使用されます。アドレスは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.
10進数は、アラビア語の数字または英語の名前で表されます。16進数は0xで前に付けられ、文字セット0-9およびA -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:
すべてのSerial Busデバイスが1394 ARP要求/応答またはIPデータグラムの受信および送信を実行できるわけではありません。IP対応ノードは、以下の最小要件を満たさなければなりません (SHALL):
- 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を実装しなければならず (SHALL)、IEEE P1394aで規定されたバス情報ブロックおよび本標準で規定されたユニットディレクトリを実装しなければなりません (SHALL)。
- 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でなければならず (SHALL)、これは512オクテットのデータペイロードを持つブロック書き込み要求および非同期ストリームパケットを受け入れる能力を示します。同じ能力は読み取り要求にも適用されなければならず (SHALL)、すなわちノードは512オクテットのデータペイロードを持つブロック応答パケットを送信できなければなりません (SHALL)。
- it SHALL be isochronous resource manager capable, as specified by IEEE P1394a;
- IEEE P1394aで規定されているように、アイソクロナスリソースマネージャ対応でなければなりません (SHALL)。
- it SHALL support both reception and transmission of asynchronous streams as specified by IEEE P1394a; and
- IEEE P1394aで規定されているように、非同期ストリームの受信と送信の双方をサポートしなければなりません (SHALL)。および
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広告/勧誘は、パケットのデータペイロード内にカプセル化されなければなりません (SHALL)。データペイロードの最大サイズ（オクテット単位）は、パケットが送信される速度によって制約されます。
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.
注：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.
非同期リクエストと応答の最大データペイロードは、送信または受信ノードの機能によって制限される場合があります。これは、バス情報ブロックまたは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）よりも少ない場合があります。これには、カプセル化形式が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) フォーマットに準拠しなければなりません (SHALL)。以下に示す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フィールドは送信ノードのnode IDを指定しなければならず (SHALL)、送信者のNODE_IDSレジスタの最上位16ビットと等しくなければなりません (SHALL)。
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フィールドは協調して、IEEE Registration Authority (RA) によってIANAに割り当てられた24ビットの組織的一意識別子 (OUI) である値0x00 005Eを含まなければなりません (SHALL)。
The version field SHALL be one.
versionフィールドは1でなければなりません (SHALL)。
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形式は、非同期ストリームパケット形式でデータペイロードの最初の2つの四角化を利用しているため、表1で引用した最大ペイロードは8オクテットによって効果的に削減されます。以下の条項では、データペイロードの最初の四角形への言及は、IPデータグラムまたは1394 ARP要求または応答に使用可能な最初の四角化を意味します。GASP形式を使用する場合、これはパケットのデータペイロードの3番目の四角形です。
All IP datagrams transported over 1394 are prefixed by an encapsulation header with one of the formats illustrated below.
1394を超えるすべてのIPデータグラムには、以下に示す形式の1つを備えたカプセル化ヘッダーが付いています。
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パケット内で送信できる場合、それは非断片化されており、データペイロードの最初のクワドレットは以下に示すフォーマットに準拠しなければなりません (SHALL)。
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フィールドはゼロでなければなりません (SHALL)。
The ether_type field SHALL indicate the nature of the datagram that follows, as specified by the following table.
ether_typeフィールドは、以下の表で指定されているとおり、後続するデータグラムの性質を示さなければなりません (SHALL)。
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.
データグラムの長さが送信者およびすべての受信者によってサポートされる最大データペイロードを超える場合、データグラムはリンクフラグメントに分割されなければなりません (SHALL)。最初のリンクフラグメントのデータペイロードの最初の2クワドレットは、以下に示すフォーマットに準拠しなければなりません (SHALL)。
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.
2番目以降のリンクフラグメント（最後を含む）は、以下に示すフォーマットに準拠しなければなりません (SHALL)。
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データグラム内におけるリンクフラグメントの相対位置を指定しなければなりません (SHALL)。
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データグラムのすべてのリンクフラグメントで同一でなければならず (SHALL)、そのデータグラムのIPヘッダーにおけるTotal Lengthの値より1小さい値でなければなりません (SHALL)（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を持たなければなりません (SHALL)。
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: このフィールドは2番目以降のリンクフラグメントにのみ存在し、IPデータグラムの先頭からのフラグメントのオフセットをオクテット単位で指定しなければなりません (SHALL)。データグラムの最初のオクテット（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データグラムのすべてのリンクフラグメントで同一でなければなりません (SHALL)。送信者は、連続する断片化データグラムに対してdglをインクリメントしなければならず (SHALL)、インクリメントされたdglの値は65,535からゼロへとラップアラウンドしなければなりません (SHALL)。
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データグラムの前には上述のカプセル化ヘッダーのいずれかが先行しなければなりません (SHALL)。これにより、送信モードに関係なくデータグラムの均一なソフトウェア処理が可能になります。
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の双方を使用しなければなりません (SHALL)。
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によって識別される別のフラグメントと重複するリンクフラグメントが受信された場合、再構築バッファにすでに蓄積されているフラグメントは破棄されなければなりません (SHALL)。直近に受信されたリンクフラグメントを用いて新たな再構築を開始してもよいです。フラグメントの重複は、カプセル化ヘッダーのfragment_offsetと1394パケットヘッダーのdata_lengthの組み合わせによって判定されます。
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.
Serial Busリセットの検出時、受信者は部分的に再構築されたすべてのIPデータグラムのすべてのリンクフラグメントを破棄しなければならず (SHALL)、送信者は部分的に送信されたすべてのIPデータグラムの未送信のすべてのリンクフラグメントを破棄しなければなりません (SHALL)。
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データグラムと同じ手段によって送信されなければなりません (SHALL)。1394 ARP応答は同様の方法で送信されてもよく (MAY)、あるいは1394 ARP要求によって識別されたsender_unicast_FIFOアドレス宛てのブロック書き込み要求として送信されてもよいです (MAY)。1394 ARP要求/応答は32オクテットであり、図5に示すフォーマットに準拠しなければなりません (SHALL)。
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フォーマット内にカプセル化されなければなりません (SHALL)（4.1も参照）。1394 ARP要求または応答の受信者は、source_IDフィールドの最上位10ビット（非同期ストリームパケットのGASPヘッダーまたはブロック書き込み要求のパケットヘッダーから取得されたもののいずれであっても）が0x3FFまたは受信者のNODE_IDSレジスタの最上位10ビットのいずれとも等しくない限り、それを無視しなければなりません (SHALL)。
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を持たなければなりません (SHALL)。
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を持たなければなりません (SHALL)。これは、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を持たなければなりません (SHALL)。
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を持たなければなりません (SHALL)。
opcode: This field SHALL be one to indicate a 1394 ARP request and two to indicate a 1394 ARP response.
opcode: このフィールドは、1394 ARP要求を示すには1、1394 ARP応答を示すには2でなければなりません (SHALL)。
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: このフィールドは送信者のノード一意識別子 (node unique ID) を含まなければならず (SHALL)、送信者のバス情報ブロックで指定されたものと等しくなければなりません (SHALL)。
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の値と等しくなければなりません (SHALL)。
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速度の小さい方に設定されなければなりません (SHALL)。リンク速度は、リンクがパケットを送信または受信できる最大速度です。PHY速度は、PHYがパケットを送信、受信、または中継できる最大速度です。以下の表はsspdに使用されるエンコーディングを指定しています。指定されていないすべての値は将来の標準化のためにRESERVEDとされます。
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: これらのフィールドは協調して、セクション6で指定されたフォーマットでIPデータグラムを受信するために利用可能な送信者FIFOの48ビットオフセットを指定しなければなりません (SHALL)。送信者のユニキャストFIFOのオフセットは、電源リセットの結果を除き、変更してはなりません (SHALL NOT)。
sender_IP_address: This field SHALL specify the IP address of the sender.
sender_IP_address: このフィールドは送信者のIPアドレスを指定しなければなりません (SHALL)。
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アドレスを指定しなければなりません (SHALL)。1394 ARP応答では、これは無視されなければなりません (SHALL)。
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は、本標準で規定されたフォーマットのユニットディレクトリを含まなければなりません (SHALL)。ユニットディレクトリは、ISO/IEC 13213:1994で規定されているように、Unit_Spec_IDおよびUnit_SW_Versionエントリを含まなければなりません (SHALL)。
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エントリは、デバイスのインターネットプロトコル機能のアーキテクチャ定義を担当する組織を指定するユニットディレクトリの即時エントリです。
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の値は、IEEE RAからIANAによって取得された登録ID (RID) である 0x00 005E でなければなりません (SHALL)。この値は、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でなければならず (SHALL)、これはデバイスが本標準の規範的要件に準拠していることを示します。
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内のテキスト記述子は任意 (OPTIONAL) です。存在する場合、人間のユーザが理解できるように意図された追加の説明情報を提供します。IP対応ノードは、Unit_Spec_IDエントリに内容「IANA」のテキスト記述子を関連付け、Unit_SW_Versionエントリに内容「IPv4」のテキスト記述子を関連付けるべきです (SHOULD)。
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対応ノードによって実装されるユニットディレクトリを示しています。これには任意 (OPTIONAL) のテキスト記述子が含まれます。テキスト記述子リーフはユニットディレクトリの一部ではありませんが、単純化のためにユニットディレクトリの直後に示されています。
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 |
+--------------------------------------+
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.
最後の方法である非同期ストリームパケットは、完全性のためにのみ言及されています。この方法は、1394リンクレベルの肯定応答もサービス品質も提供せず、貴重なリソースであるチャネル番号を消費するため、IPユニキャストに使用すべきではありません (SHOULD NOT)。
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バスマネージャーによって維持されているSPEED_MAPは、ローカルシリアルバスの任意の2つのノード間の最大送信速度を提供します。バスマネージャーは、速度マップを構築するためにバストポロジーを分析します。ノード間の最大透過速度は、介在するノードの機能を反映しています。速度は、最大データペイロードを意味します（表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によって実装される最大のデータペイロードの最小値でなければなりません (SHALL)（最後は送信者と受信者によってインデックス付けされる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個のすべてのノードによって送信される自己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 ARP応答から取得されたsource_IDおよびsender_unicast_FIFO宛ての1394ブロック書き込みトランザクションのデータペイロード内に含まれなければなりません (SHALL)。
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.
Best-Effort以外のサービス品質を必要とするユニキャスト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ブロードキャストに使用されるチャネル番号は、BROADCAST_CHANNELレジスタによって指定されています。
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レジスタのchannelフィールドと等しいチャネル番号を持つ非同期ストリームパケットを使用しなければなりません (SHALL)。
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対応ノードは、自身のBROADCAST_CHANNELレジスタ内のvalidビットがゼロである間は、いかなる時も非同期ストリームパケットを送信してはなりません (SHALL NOT)。validビットはバスリセットによって自動的にゼロにクリアされるため、これにより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マルチキャストに使用されます。Best-Effort以外のサービス品質は、この標準の範囲を超えています。
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レジスタのchannelフィールドと等しいチャネル番号を持つ非同期ストリームパケットを使用しなければなりません (SHALL)。特に、224.0.0.1および224.0.0.2宛てのデータグラムはこのチャネル番号を使用しなければなりません (SHALL)。他のIPマルチキャストグループアドレスに対するベストエフォートIPマルチキャストは、以下で説明するように、使用前にそのようなチャネル番号が割り当てられ広告されている場合には、別のチャネル番号を利用してもよいです。
IP-capable nodes may transmit best-effort IP multicast only if one of the following two conditions is met:
IP対応ノードは、次の2つの条件のいずれかが満たされている場合にのみ、Best-Effort 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メッセージは断片化してはならず (SHALL NOT)、ether_type 0x8861としてストリームパケット内にカプセル化されなければなりません (SHALL)。
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.
length: このフィールドは、MCAPメッセージ全体のサイズをオクテット単位で含まなければなりません (SHALL)。
opcode: This field SHALL have one of the values specified by the table below.
opcode: このフィールドは、以下の表で指定された値のいずれかを持たなければなりません (SHALL)。
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.
message data: MCAPメッセージの残りの部分は可変長であり、以下に示すフォーマットを持つ0個以上のグループアドレス記述子で構成されなければなりません (SHALL)。
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.
length: このフィールドは、MCAPグループアドレス記述子のサイズをオクテット単位で含まなければなりません (SHALL)。
type: This field SHALL have a value of one, which indicates a group address descriptor.
type: このフィールドは、グループアドレス記述子を示す値1を持たなければなりません (SHALL)。
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.
expiration: このフィールドの用途はopcodeによって異なります。solicitメッセージの場合、expirationフィールドは無視されなければなりません (SHALL)。そうではなくadvertiseの場合、このフィールドには、channelによって指定されたチャネル番号がそれ以降使用できなくなる将来の時刻を指定する秒単位のタイムスタンプが含まれなければなりません (SHALL)。
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.
channel: このフィールドはadvertiseメッセージの場合にのみ有効であり、その場合、0から63の範囲（両端を含む）で割り当てられたチャネル番号を指定しなければなりません (SHALL)。他のすべての値はRESERVEDです。
speed: This field is valid only for advertise messages, in which case it SHALL specify the speed at which stream packets for the indicated channel are transmitted. Table 2 specifies the encoding used for speed.
speed: このフィールドはadvertiseメッセージの場合にのみ有効であり、その場合、示されたチャネルに対するストリームパケットが送信される速度を指定しなければなりません (SHALL)。表2はspeedに使用されるエンコーディングを指定しています。
bandwidth: This field SHALL be zero; it is allocated in the group address descriptor to accommodate future extensions to MCAP that specify quality of service and utilize the isochronous capabilities of Serial Bus.
bandwidth: このフィールドはゼロでなければなりません (SHALL)。これは、サービス品質を指定し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アドレスを指定しなければなりません (SHALL)。group_addressの長さ（オクテット単位）は、lengthフィールドから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メッセージは、それが送信されるローカルSerial Busに対してのみ有効な情報を伝達します。MCAPメッセージの受信者は、以下のようにローカルバス以外からのすべてのMCAPメッセージを無視しなければなりません (SHALL)。送信者のsource_IDは、カプセル化されたMCAPメッセージの前に先行するGASPヘッダーに含まれています。MCAPメッセージの受信者は、GASPヘッダーからのsource_IDの最上位10ビットを検査しなければならず (SHALL)、それらが0x3FFまたは受信者のNODE_IDSレジスタの最上位10ビットのいずれとも等しくない場合、受信者はそのメッセージを無視しなければなりません (SHALL)。
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レジスタによって指定されたデフォルトチャネル以外のチャネル番号との間に存在するチャネルマッピング（もしあれば）を確認しなければなりません (SHALL)。そのようなデバイスは、希望するチャネルマッピングについてブロードキャストチャネル上の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勧誘要求の発信元は、それが送信されるレートを制限しなければなりません (SHALL)。勧誘要求を送信した後、発信元は10秒が経過するまで別のMCAP勧誘要求を送信してはなりません (SHALL NOT)。
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広告メッセージが予想されます。1つ以上のチャネルマッピングを説明する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 advertiseメッセージが確認された場合、チャネル番号は最大のphysical IDを持つ広告メッセージから取得されなければならず (SHALL)、そのphysical IDはGASPヘッダーからのsource_IDの最下位6ビットから取得されなければなりません (SHALL)。
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.
10秒以内に特定のグループアドレスに対して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.
マルチキャスト受信者は、希望するグループアドレスに対する広告を確認すると、デフォルトのブロードキャストチャネルまたは示されたチャネル番号のいずれかでマルチキャストデータを受信してもよいですが (MAY)、使用中のチャネル番号の有効期限を更新するために、同じグループアドレスに対する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対応デバイスは、まず別のマルチキャスト送信元がそのグループアドレスに対してすでにチャネル番号を割り当てているかどうかを確認しなければなりません (SHALL)。意図されたマルチキャスト送信元は、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広告についてブロードキャストチャネルを監視しなければなりません (SHALL)。そのグループアドレスに対するチャネルマッピングがすでに存在する場合、10秒以内にMCAP広告が受信されるべきです (SHOULD)。この場合、意図されたマルチキャスト送信元は示されたチャネル番号でIPデータグラムの送信を開始してもよく、その有効期限まで送信を継続してもよいです。マルチキャスト送信元は、使用中のチャネル番号の有効期限を更新するためにMCAP広告を監視しなければなりません (SHALL)。
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レジスタからチャネル番号の割り当てを試みてもよいです。チャネル番号の割り当てが成功した場合、マルチキャスト送信元は可能な限り速やかに新しいチャネルマッピングを広告しなければなりません (SHALL)。新しく割り当てられたチャネル番号の最初の広告の後100ミリ秒が経過すると、マルチキャスト送信元は広告されたチャネル番号を使用して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) 別のマルチキャスト送信元に所有権を譲渡する、b) 譲渡することなくチャネルマッピングを失効させる、または c) 重複したチャネルマッピングの場合に別のマルチキャスト送信元へチャネルマッピングの制御を放棄する、のいずれかを行わない限り、そのチャネルマッピングに対するMCAP広告の送信を継続しなければなりません (SHALL)。
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マルチキャストグループアドレスの広告を定期的にブロードキャストしなければなりません (SHALL)。広告は、1つ以上のグループアドレス記述子（BROADCAST_CHANNELレジスタによって指定されたもの以外のチャネル番号が割り当てられた各グループアドレスに対して1つ）を含む、opcodeが0である単一のMCAPメッセージで構成されなければなりません (SHALL)。
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およびchannelフィールドはIPマルチキャストグループアドレスをSerial Busチャネル番号に関連付けます。speedフィールドは、IPマルチキャストグループ内の送信者のいずれかがデータを送信することを許可される最大1394速度を指定します。expirationフィールドは、そのチャネルマッピングが有効ではなくなる現在時刻または将来の時刻を指定します。チャネル所有者が所有権の放棄を意図している場合（以下の9.7で説明）を除き、有効期限は広告が送信された時点から測定して少なくとも60秒先の将来でなければなりません (SHALL)。
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秒を超えて経過してはなりません (SHALL)。チャネルマッピングの所有者は、要求の受信後可能な限り速やかに、勧誘に応答してMCAP広告を送信すべきです (SHOULD)。
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広告を監視しなければなりません (SHALL)。expirationフィールドの値が60未満であるMCAP広告は、重複チャネル検出の目的では無視されなければなりません (SHALL)。重複したチャネルマッピングが検出された場合、最大のphysical IDを持つ所有者（GASPヘッダーからのsource_IDの最下位6ビットによって決定される）はいかなる行動をとることも要求されません (NOT REQUIRED)。より小さいphysical IDを持つ所有者によって広告されたチャネル番号は無効です。それらの所有者は、無効なチャネル番号を使用するIPデータグラムおよびMCAP広告の双方の送信を停止しなければなりません (SHALL)。これらのチャネルマッピングが失効すると直ちに、それらの所有者は以下の9.8で説明されているように未使用のチャネル番号を解放しなければなりません (SHALL)。
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広告の受信者は、より小さいphysical IDを持つマルチキャストチャネル所有者からの広告を無視しなければならず (SHALL)、無効なチャネル番号を使用するIPデータグラムを送信してはなりません (SHALL NOT)。重複の結果として他が無視されなければならない (SHALL) 場合であっても、単一の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.
チャネルマッピングの所有者は特定のチャネルでのマルチキャスト送信を停止してもよく、その場合、チャネルマッピングを無効化すべきであり (SHOULD)、場合によってはチャネル番号を解放すべきです。他のマルチキャスト送信元が同じチャネルマッピングを使用している可能性があるため、チャネル所有権を譲渡するための秩序あるプロセスが定義されています。
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.
マッピングの解放を望む既存のチャネルマッピングの所有者は、マッピングおよびその関連チャネルの予想される解放までの残り時間を測定するためにタイマーを開始しなければなりません (SHALL)。タイマーがゼロにカウントダウンするまで、所有者は影響を受けるチャネルに対するMCAP広告の送信を継続すべきですが (SHOULD)、チャネルが解放されるまでの残り時間を反映するように各広告内のexpirationを調整しなければなりません (SHALL)。所有者がタイマーがゼロになるまでMCAP広告を送信できない場合、バスリセットを開始しなければなりません (SHALL)。そうでない場合、マッピングの解放を意図する所有者によって送信される有効期限のシーケンスは、後続の各広告とともに減少しなければなりません (SHALL)。他のマルチキャスト送信元が同じチャネルマッピングを使用しており、60秒以下の有効期限を確認した場合、それらの送信元はそのチャネルマッピングを維持する60秒以上の更新された有効期限を持つチャネルマッピングのMCAP広告の送信を開始しなければなりません (SHALL)。チャネルマッピングの所有権を主張しようとする複数の送信元間で発生する競合は、9.8で説明されているように解決されなければなりません (SHALL)。元の所有者は、自身のタイマーが満了する前に放棄予定のチャネルに対するMCAP広告を確認した場合、チャネル番号を解放してはなりません (SHALL NOT)。
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)。チャネルマッピングの意図された所有者がexpirationフィールドがゼロであるMCAP広告を確認した場合、以前の所有者からのチャネルの秩序ある譲渡は失敗しています。意図された所有者は、失効したチャネル番号での受信および送信を停止するか、または9.4で規定されているように別のチャネル番号を割り当てなければなりません (SHALL)。
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と同様の手順によって、チャネル所有権の競合を解決しなければなりません (SHALL)。
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広告を監視しなければなりません (SHALL)。expirationフィールドの値が60未満であるMCAP広告は、冗長チャネル検出の目的では無視されなければなりません (SHALL)。冗長なチャネルマッピングが検出された場合、最大のphysical IDを持つ所有者（GASPヘッダーからのsource_IDの最下位6ビットによって決定される）はいかなる行動をとることも要求されません (NOT REQUIRED)。より小さいphysical IDを持つ所有者は、冗長なチャネル番号に対するMCAP広告の送信を停止しなければなりません (SHALL) が、チャネル番号を解放してはなりません (SHALL NOT)。
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広告からexpiration秒が経過すると、チャネルマッピングは失効します。この時点で、マルチキャスト受信者は失効したチャネル番号での受信を停止しなければなりません (SHALL)。またこの時点で、チャネルマッピングの所有者はexpirationをゼロにクリアしたMCAP広告を送信しなければならず (SHALL)、チャネルマッピングの失効から30秒が経過するまでそのような広告の送信を継続しなければなりません (SHALL)。この追加の30秒の期間が経過すると、チャネルマッピングの所有者はチャネル番号を解放し、アイソクロナスリソースマネージャのCHANNELS_AVAILABLEレジスタにおいてその利用可能性を示さなければなりません (SHALL)。
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対応デバイスがexpirationフィールドがゼロであるMCAP広告を確認した場合、直近のそのような広告から30秒が経過するまで、指定されたチャネル番号のいずれも割り当てを試みてはなりません (SHALL NOT)。
A bus reset SHALL invalidate all multicast channel mappings and SHALL cause all multicast recipients and senders to zero all MCAP advertisement interval timers.
バスリセットはすべてのマルチキャストチャネルマッピングを無効化しなければならず (SHALL)、すべてのマルチキャスト受信者および送信者にすべてのMCAP広告間隔タイマーをゼロに設定させなければなりません (SHALL)。
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広告のブロードキャストを再開してもよいです。チャネルの再割り当てを試みる場合、以前の所有者はバスリセット前に割り当てられていたのと同じチャネル番号を使用すべきであり (SHOULD)、同じチャネル番号を再利用する限り、バスリセットの完了直後に再割り当てを開始してもよいです。以前の所有者が異なるチャネル番号を割り当てることを選択した場合、新しいチャネル番号の割り当てを試みる前に、バスリセットの完了から少なくとも1秒が経過するまで待機しなければなりません (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勧誘要求を送信してはなりません (SHALL NOT)。デフォルト以外のチャネルにおけるマルチキャストデータは、そのIPマルチキャストグループアドレスに対するMCAP広告が確認または送信されるまで、受信または送信してはなりません (SHALL NOT)。
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秒が経過するまで、アイソクロナスリソースマネージャのCHANNELS_AVAILABLEレジスタからのチャネル番号の割り当てを試みてはなりません (SHALL NOT)。この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ビットの数値がプロトコルインターフェースを指定する文書を識別しなければならない (SHALL) ということです。この48ビットの数値は、0x00 005E（IEEE Registration AuthorityによってIANAに付与された登録ID (RID)）とIANAによって管理される2つ目の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は、可能な値の範囲で使用可能な数値の量を最大化するために、2番目の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 Protocol Identifiers」です。値ゼロおよび0xFF FFFFは予約されており、IANAによって割り当てられてはなりません (SHALL NOT)。値1は本文書に割り当てられます。残りの数値はIANAによって管理され、IESG標準化過程文書となるインターネットドラフトを識別するために必要に応じて割り当てられなければなりません (SHALL)。
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によって選択された割り当て方法に関係なく、割り当てられたすべてのバージョン番号のレジストリは1つ以上のインターネットサイトで維持されるべきであり (SHOULD)、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データグラムの転送のための保護されていないリンク層であるSerial Busの使用を規定しています。Serial Busはサービス運用妨害攻撃に対して脆弱です。また、デバイスがデータを盗聴したり、偽造された識別情報を提示したりすることも可能です。IPv4のためにSerial Busを利用する実装者は、アプリケーションまたは他の層内で適切な対策を検討すべきです (SHOULD)。
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] Postel、J。、「インターネットプロトコルDARPAインターネットプログラムプロトコル仕様」、RFC 791、1981年9月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためのRFCで使用するためのキーワード」、RFC 2119、1997年3月。
Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94602
Peter Johansson Condaryent Software、Inc。98 Colorado Avenue Berkeley、CA 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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。