RFC2734 日本語訳
2734 IPv4 over IEEE 1394. P. Johansson. December 1999. (Format: TXT=69314 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Johansson Request for Comments: 2734 Congruent Software, Inc. Category: Standards Track December 1999
コメントを求めるワーキンググループP.ヨハンソン要求をネットワークでつないでください: 2734年の一致しているソフトウェアInc.カテゴリ: 標準化過程1999年12月
IPv4 over IEEE 1394
IEEE1394の上のIPv4
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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 Std1394-1995を使用する方法を指定します、HighパフォーマンスSerial Bus(そして、補足)のためのStandard、インターネットプロトコルバージョン4(IPv4)データグラムの輸送のために。 それはそのために必要なメソッド、データ構造、およびコードを定義します。 これらはデータグラムのためのパケット・フォーマットとカプセル化メソッドだけではなく、アドレス解決プロトコル(1394ARP)とマルチキャストチャンネル配分プロトコル(MCAP)も含んでいます。 1394ARPとMCAPの両方がSerial Busに特定です。 IPマルチキャストグループによって使用されると、後者はSerial Busリソースの管理を可能にします。
TABLE OF CONTENTS
目次
1. INTRODUCTION.....................................................2
2. DEFINITIONS AND NOTATION.........................................4
2.1 Conformance..................................................4
2.2 Glossary.....................................................4
2.3 Abbreviations................................................6
2.4 Numeric values...............................................6
3. IP-CAPABLE NODES.................................................6
4. LINK ENCAPSULATION AND FRAGMENTATION.............................7
4.1 Global asynchronous stream packet (GASP) format..............8
4.2 Encapsulation header.........................................9
4.3 Link fragment reassembly....................................11
5. SERIAL BUS ADDRESS RESOLUTION PROTOCOL (1394 ARP)...............11
6. CONFIGURATION ROM...............................................14
6.1 Unit_Spec_ID entry..........................................14
6.2 Unit_SW_Version entry.......................................14
1. 序論…2 2. 定義AND記法…4 2.1順応…4 2.2用語集…4 2.3の略語…6 2.4 数値値…6 3. IPできるノード…6 4. カプセル化と断片化をリンクしてください…7 4.1 グローバルな非同期なストリームパケット(GASP)形式…8 4.2カプセル化ヘッダー…9 4.3 断片再アセンブリをリンクしてください…11 5. 連続のバスアドレス解決プロトコル(1394年のアルプ)…11 6. 構成ROM…14 Spec_ID6.1の_エントリー…14 SW_バージョン6.2の_エントリー…14
Johansson Standards Track [Page 1] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[1ページ]。
6.3 Textual descriptors.........................................15
7. IP UNICAST......................................................16
8. IP BROADCAST....................................................17
9. IP MULTICAST....................................................17
9.1 MCAP message format.........................................18
9.2 MCAP message domain.........................................21
9.3 Multicast receive...........................................21
9.4 Multicast transmit..........................................22
9.5 Advertisement of channel mappings...........................23
9.6 Overlapped channel mappings.................................23
9.7 Transfer of channel ownership...............................24
9.8 Redundant channel mappings..................................25
9.9 Expired channel mappings....................................25
9.10 Bus reset..................................................26
10. IANA CONSIDERATIONS............................................26
11. SECURITY CONSIDERATIONS........................................27
12. ACKNOWLEDGEMENTS...............................................27
13. REFERENCES.....................................................28
14. EDITOR'S ADDRESS...............................................28
15. Full Copyright Statement.......................................29
6.3の原文の記述子…15 7. IPユニキャスト…16 8. IPは放送されました…17 9. IPマルチキャスト…17 9.1 MCAPメッセージ・フォーマット…18 9.2MCAPメッセージドメイン…21 9.3マルチキャストは受信されます…21 9.4マルチキャストは伝わります…22 9.5 チャンネルマッピングの広告…23 9.6はチャンネルマッピングを重ね合わせました…23 9.7 チャンネル所有権の転送…24 9.8 余分なチャンネルマッピング…9.9が吐き出した25はマッピングを向けます…25 9.10 リセットをバスで運んでください…26 10. IANA問題…26 11. セキュリティ問題…27 12. 承認…27 13. 参照…28 14. エディタのアドレス…28 15. 完全な著作権宣言文…29
1. INTRODUCTION
1. 序論
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.
このドキュメントはIEEE Std1394-1995を使用する方法を指定します、HighパフォーマンスSerial Bus(そして、補足)のためのStandard、インターネットプロトコルバージョン4(IPv4)データグラムの輸送のために。それは、そのために必要なメソッド、データ構造、およびコードを定義して、アドレス解決プロトコル(1394ARP)とマルチキャストチャンネル配分プロトコル(MCAP)のためにさらに、メソッドを定義します。---それの両方が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 Std1394-1995に関連する草稿の、または、承認されたIEEE規格と補足のグループは今後1394かSerial Busと呼ばれます。
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 連続のBusは共有された物理的なメディアの上の速度におけるノードのコミュニケーションにその範囲を可能にします、現在のところ、100〜400Mbps。 消費者電子応用学(デジタルVCRsや、ステレオ方式や、テレビやカムコーダなどの)と(例えば、大容量記憶、プリンタ、およびテープ)が1394に採用した伝統的なデスクトップコンピュータアプリケーションの両方 連続のBusは関連性で家電とコンピュータドメインの両方にユニークであり、両方のタイプのデバイスを結合するホームか小さい企業内ネットワークの基礎を形成するEXPECTEDです。
Johansson Standards Track [Page 2] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[2ページ]。
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アーキテクチャはSerial Busが64ビットの固定ロケーション体系として実装するメモリで写像しているアドレス空間について説明します。 アドレス空間の中では、バスID(最大最大1,023台のバス)のために10ビットを割り当てて、残っている48ビット(相殺する)が256のノードアドレス空間あたりのaにテラバイトについて説明している間、ノードの物理的なID(最大1バスあたり63)のために6を割り当てます。 コンベンションによるCSRアーキテクチャは異なった行動の特性でノードのアドレス空間を2つの領域に分けます。 0xFFFF F000 0000を密かに企てますが、含まない下位部はメモリとして読書に対応して振る舞って、トランザクションを書くEXPECTEDです。 上部はさらに伝統的なIOスペースに似ています: この領域でトランザクションを読み書きしてください。通常、副作用を持ってください。 先入れ先出し法の振舞いを持っているコントロールとステータスレジスタ(CSRs)がこの領域で通例に実装されます。
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を含んでいますが、現在のところ、別々に列挙されたSerial Busesを接続する標準方法が全くありません。 Serial BusブリッジへのSerial Busの規格の活発な開発はIEEE P1394.1ワーキンググループで進行中です。 何らかの将来の規格によって広げられない場合、このドキュメントによって指定された1394のプロトコルの上のIPv4はブリッジの向こう側に正しく作動しないかもしれません。
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つの八重奏から伝送速度に従って決定している最大まで変化するかもしれません(S100は、それがS400の2048の八重奏ですが、最大の非同期データペイロードが100Mbpsの512の八重奏であると命名しました)。
NOTE: Extensions underway in IEEE P1394b contemplate additional speeds of 800, 1600 and 3200 Mbps.
以下に注意してください。 IEEE P1394bの進行中の拡大は800の追加速度、1600と3200Mbpsを熟考します。
Johansson Standards Track [Page 3] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[3ページ]。
2. DEFINITIONS AND NOTATION
2. 定義と記法
2.1 Conformance
2.1 順応
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.
そして、本書では使用されると、「任意」の、そして、「お勧め」の「5月」というキーワードが「必要です」、“SHALL"、「」、“SHOULD"、「」 要件とoptionalityのレベルを差別化してください、そして、RFC2119で説明されるように解釈されることになっているべきになってください。
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.
無視される: 値があるビットについて説明するキーワード、八重奏、quadletsまたは分野が受取人でチェックしませんでした。
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.
予約される: キーワードは以前はよくオブジェクトについて説明していました。---ビット、八重奏、quadlets、および分野---これらのオブジェクトに割り当てられたコード値。 オブジェクトかコード値が今後の標準化のためにかたわらに置かれます。 RESERVEDオブジェクトには定義された意味が全くなくて、将来の規格の開発のときに、SHALLは創始者によってゼロに合わせられているか、またはそのような規格によって指定された値にセットします。 RESERVEDオブジェクトSHALL NOTの受取人は値をチェックします。 コード値がその値と廃棄物RESERVEDコードが評価するこの標準のSHALLチェックで定義されるオブジェクトの受取人。
2.2 Glossary
2.2 用語集
The following terms are used in this standard:
次の用語はこの規格に使用されます:
address resolution protocol: A method for a requester to determine the hardware (1394) address of an IP node from the IP address of the node.
解決プロトコルを扱ってください: リクエスタがノードのIPアドレスからのIPノードのハードウェア(1394)アドレスを決定するメソッド。
bus ID: A 10-bit number that uniquely identifies a particular bus within a group of multiple interconnected buses. The bus ID is the most significant portion of a node's 16-bit node ID. The value 0x3FF designates the local bus; a node SHALL respond to requests addressed to its 6-bit physical ID if the bus ID in the request is either 0x3FF or the bus ID explicitly assigned to the node.
IDをバスで運んでください: 倍数のグループの中で唯一特定のバスを特定する10ビットの数はバスとインタコネクトしました。 バスIDはノードの16ビットのノードIDの最も重要な部分です。 値の0x3FFはローカルバスを指定します。 SHALLが要求におけるバス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データグラム: RFC791、形式に従うインターネットメッセージはSTD5で指定しました。
Johansson Standards Track [Page 4] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[4ページ]。
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.
断片をリンクしてください: IPデータグラムの一部が1394年の単一のパケットの中を伝わりました。 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.
マルチキャストチャンネル配分プロトコル: デフォルト放送チャンネルを除いて、マルチキャストデータグラムで伝えられるなら、マルチキャストのためのメソッドは、彼らのSerial Busリソース(チャンネル)の使用を調整するために分類されます。
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広告を扱って、伝えます。 1つ以上の情報筋が同じ論理機番のために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: 倍数のグループの中で唯一Serial Busノードを特定する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: すべてのSerial Busノードの中で唯一ノードを特定する64ビットの数は世界中製造されていました。 また、EUI-64(拡張Unique Identifier、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広告/懇願とSerial Busのプライマリパケットを区別するのに一貫して使用されます。
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.
quadlet: データの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年の仲裁のタイプに従って、ストリームパケットは、非同期であるか、または同一時間であるかもしれません。
Johansson Standards Track [Page 5] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[5ページ]。
2.3 Abbreviations
2.3 略語
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
1394ARP Address解決プロトコル(1394に特定の)CSR ControlとステータスレジスタCRC Cyclical冗長チェックサムEUI-64 Extended Unique Identifier、64ビットのGASP Globalの非同期なストリームパケットIPインターネットプロトコル(このドキュメントの中にIPv4)MCAP Multicastチャンネル配分は議定書を作ります。
2.4 Numeric values
2.4 数値値
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進数によって一様に表されます。(また、表された値が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進数は、文字集合0--9とAから0xによって前に置かれていて、ケタによって表されます--F.For、16進数は空間によって切り離された4ケタのグループに切り離されます。
For example, both 42 and 0x2A represent the same numeric value.
例えば、42と0x2Aの両方が同じ数値を表します。
3. IP-CAPABLE NODES
3. IPできるノード
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;
- そして、それ、SHALLがISO/IECによって指定された一般形式で構成ROMを実装する、13213:1994、SHALLは、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;
- バス情報の最大_rec分野はSHALLを妨げます。少なくとも8になってください。 これは、ブロックを受け入れる能力が512の八重奏のデータペイロードで要求と非同期なストリームパケットを書くのを示します。 また、同じ能力SHALLは、要求を読むのに申し込みます。 それはそうであり、ノードはSHALLです。512の八重奏のデータペイロードでブロック応答パケットを伝えることができてください。
Johansson Standards Track [Page 6] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[6ページ]。
- it SHALL be isochronous resource manager capable, as specified by
IEEE P1394a;
- それ、SHALL、IEEE P1394aで、指定されるとしてできる同一時間の資源管理プログラムになってください。
- it SHALL support both reception and transmission of asynchronous
streams as specified by IEEE P1394a; and
- それ、SHALLはレセプションとIEEE P1394aによる指定されるとしての非同期なストリームの送信の両方をサポートします。 そして
4. LINK ENCAPSULATION AND FRAGMENTATION
4. リンクカプセル化と断片化
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.
すべてのIPデータグラム(放送、ユニキャストまたはマルチキャスト)、1394ARPはブロックが要求かストリームパケットSHALLに書く1394で移される/応答と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 |
+------------------------------------+
非同期な同一時間の+を促進してください。------------------------------------+ | 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応答で最大_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.
以下に注意してください。 MTUサイズがデフォルトより大きい状態でIPできるノードは作動するかもしれませんが、より大きいMTUが構成される手段はこのドキュメントの範囲を超えています。
Johansson Standards Track [Page 7] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[7ページ]。
4.1 Global asynchronous stream packet (GASP) format
4.1 グローバルな非同期なストリームパケット(GASP)形式
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.
1394のいくつかのIPデータグラム、ARP要求、および応答が非同期なストリームパケットを通して輸送されるかもしれません。 非同期なストリームパケットが使用されているとき、それらの形式SHALLはIEEE P1394aによって指定されたグローバルな非同期なストリームパケット(GASP)形式に従います。 以下で例証されたGASP形式は、INFORMATIVEであって、参照だけの容易さのために再生されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data_length |tag| channel | 0x0A | sy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header_CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_ID | specifier_ID_hi |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|specifier_ID_lo| version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+--- data ---+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data_CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ_長さ|タグ| チャンネル| 0x0A| sy| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ヘッダー_CRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース_ID| 特許説明書の作成書_ID_、こんにちは。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |特許説明書の作成書_ID_最低気温| バージョン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +--- データ---+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ_CRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - GASP format
図1--GASP形式
The source_ID field SHALL specify the node ID of the sending node and SHALL be equal to the most significant 16 bits of the sender's NODE_IDS register.
ソース_ID分野SHALLは送付者のNODEの最も重要な16ビットへの同輩がIDSが登録する_であったなら送付ノードとSHALLのノードIDを指定します。
The specifier_ID_hi and specifier_ID_lo fields together SHALL contain the value 0x00 005E, the 24-bit organizationally unique identifier (OUI) assigned by the IEEE Registration Authority (RA) to IANA.
特許説明書の作成書_ID_最低気温はSHALLを一緒にさばきます。そして、特許説明書の作成書_ID_、こんにちは、値0x00の005E、IEEE Registration Authority(RA)によってIANAに割り当てられた組織的の24ビットのユニークな識別子(OUI)を含んでください。
The version field SHALL be one.
バージョン分野SHALLは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形式が非同期なストリームパケット・フォーマットでデータペイロードの最初の2quadletsを利用するので、事実上、Table1で引用された最大積載量は8つの八重奏で減少します。 従う節では、データペイロードの最初のquadletの参照はIPデータグラムに、使用可能なquadletか1394ARPが要求する1番目か応答を意味します。 GASP形式が使用されているとき、これはパケットのためのデータペイロードの3番目のquadletです。
Johansson Standards Track [Page 8] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[8ページ]。
4.2 Encapsulation header
4.2 カプセル化ヘッダー
All IP datagrams transported over 1394 are prefixed by an encapsulation header with one of the formats illustrated below.
すべてのIPデータグラムが1394以上を輸送しました。形式の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が形式に従わせるデータペイロードの最初のquadletは以下で例証しました。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lf| reserved | ether_type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lf| 予約されます。| エーテル_タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Unfragmented encapsulation header format
図2--Unfragmentedカプセル化ヘッダー形式
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.
エーテル_タイプ分野SHALLは以下のテーブルによって指定されるように続くデータグラムの自然を示します。
ether_type Datagram
+-------------------------+
| 0x0800 | IPv4 |
| 0x0806 | 1394 ARP |
| 0x8861 | MCAP |
+-------------------------+
エーテル_タイプデータグラム+-------------------------+ | 0×0800| IPv4| | 0×0806| 1394 アルプ| | 0×8861| 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.
以下に注意してください。 エーテル_タイプの異価によって特定された他のネットワーク・プロトコルはここに定義されたカプセル化書式を使用するかもしれませんが、そのような使用はこのドキュメントの範囲の外にあります。
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で支えた場合では、リンク断片は細かく分けられてください。 最初のリンク断片SHALLのためのデータペイロードの最初の2quadletsが以下に示された書式に一致しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lf|rsv| datagram_size | ether_type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dgl | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lf|rsv| データグラム_サイズ| エーテル_タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dgl| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - First fragment encapsulation header format
図3--最初に、断片カプセル化ヘッダー形式
Johansson Standards Track [Page 9] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[9ページ]。
The second and subsequent link fragments (up to and including the last) SHALL conform to the format shown below.
SHALLが以下に示された書式に従わせる2番目の、そして、その後のリンク断片(最終を含めた)。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lf|rsv| datagram_size | rsv | fragment_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dgl | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lf|rsv| データグラム_サイズ| rsv| 断片_は相殺されました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dgl| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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分野SHALLはIPデータグラムの中にリンク断片の相対的な位置を指定します、以下のテーブルによってコード化されるように。
lf Position
+------------------------+
| 0 | Unfragmented |
| 1 | First |
| 2 | Last |
| 3 | Interior |
+------------------------+
lf Position+------------------------+ | 0 | Unfragmentedしました。| | 1 | 1番目| | 2 | 最終| | 3 | 内部| +------------------------+
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).
データグラム_サイズ: 全体のIPデータグラムのコード化されたサイズ。 値、すべてのリンクと同じくらいがIPデータグラムとSHALLの断片であったなら、データグラム_サイズSHALLにおいて、データグラムのIPヘッダー(STD5を見てください、RFC791)のTotal Lengthの値ある以下がそうです。
ether_type: This field is present only in the first link fragment
and SHALL have a value of 0x0800, which indicates an IPv4
datagram.
エーテル_タイプ: この分野は最初のリンク断片だけに存在しています、そして、SHALLには、0×0800の値があります。(それは、IPv4データグラムを示します)。
fragment_offset: This field is present only in the second and
subsequent link fragments and SHALL specify the offset, in octets,
of the fragment from the beginning of the IP datagram. The first
octet of the datagram (the start of the IP header) has an offset
of zero; the implicit value of fragment_offset in the first link
fragment is zero.
断片_は相殺されました: この分野は2番目の、そして、その後のリンク断片だけに存在しています、そして、SHALLはオフセットを指定します、IPデータグラムの始まりからの断片の八重奏で。 データグラム(IPヘッダーの始まり)の最初の八重奏には、ゼロのオフセットがあります。 最初のリンク断片で相殺された断片_の暗黙の値はゼロです。
Johansson Standards Track [Page 10] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[10ページ]。
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(データグラムラベル)SHALLにおいて、IPデータグラムのすべてのリンク断片のための同じくらいはそうです。 送付者SHALLは連続して、断片化しているデータグラムのためにdglを増加します。 6万5535〜ゼロまでのdgl 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のモードにかかわらず、上の説明されたカプセル化ヘッダーのひとりによって先行されてください。 これは関係なしでデータグラムの一定のソフトウェア処理を彼らのトランスミッションの方法に可能にします。
4.3 Link fragment reassembly
4.3 リンク断片再アセンブリ
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.
IPデータグラムの受取人は1万1394パケットSHALLが単一のデータグラムからすべてのリンク断片を特定するのに送付者のソース_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.
リンク断片を受け取り次第、受取人は断片_オフセットで指定された位置のIPデータグラム再アセンブリバッファの中にデータペイロード(カプセル化ヘッダーを欠席する)を置くかもしれません。 再アセンブリバッファのサイズはデータグラム_サイズから決定しているかもしれません。
If a link fragment is received that overlaps another fragment identified by the same source_ID and dgl, the fragment(s) already accumulated in the reassembly buffer SHALL be discarded. A fresh reassembly may be commenced with the most recently received link fragment. Fragment overlap is determined by the combination of fragment_offset from the encapsulation header and data_length from the 1394 packet header.
リンク断片が受け取られているなら、それは_同じソースのIDとdglによって特定された別の断片を重ね合わせます、捨てられて、再アセンブリバッファSHALLに既に蓄積された断片。 新鮮な再アセンブリは最も最近容認されたリンク断片で始められるかもしれません。 断片オーバラップは1394年のパケットのヘッダーからカプセル化ヘッダーとデータ_の長さから相殺された断片_の組み合わせで決定します。
Upon detection of a Serial Bus reset, recipient(s) SHALL discard all link fragments of all partially reassembled IP datagrams and sender(s) SHALL discard all not yet transmitted link fragments of all partially transmitted IP datagrams.
Serial Busリセットの検出のときに、受取人SHALLはすべての部分的に組み立て直されたIPデータグラムのすべてのリンク断片を捨てます、そして、送付者SHALLはすべての部分的に伝えられたIPデータグラムのすべてのまだ伝えられるというわけではないリンク断片を捨てます。
5. SERIAL BUS ADDRESS RESOLUTION PROTOCOL (1394 ARP)
5. 連続のバスアドレス解決プロトコル(1394年のアルプ)
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アドレスから装置のハードウェア・アドレスを決定する方法は解決できなく装置によって利用された輸送培地に結ばれます。 以下での記述、およびこのドキュメント中の1394ARPが唯一方法とデータ構造が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
1394ARPは、SHALLが放送IPデータグラムと同じ手段で伝えられるよう要求します。 同様に、1394のARP応答が伝えられるかもしれませんか、またはブロックが記述された要求を書くようにそれらは伝えられるかもしれません。
Johansson Standards Track [Page 11] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[11ページ]。
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.
ARPが要求する1394年までに特定された送付者_ユニキャスト_先入れ先出し法アドレス。 1394ARP要求/応答は32の八重奏です、そして、SHALLは図5によって例証された形式に従います。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hardware_type (0x0018) | protocol_type (0x0800) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hw_addr_len | IP_addr_len | opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+--- sender_unique_ID ---+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender_max_rec| sspd | sender_unicast_FIFO_hi |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender_unicast_FIFO_lo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender_IP_address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| target_IP_address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ハードウェア_タイプ(0×0018)| プロトコル_タイプ(0×0800)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hw_addr_len| _IP addr_len| opcode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +--- 送付者の_のユニークな_ID---+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _送付者最大_rec| sspd| 送付者_ユニキャスト_先入れ先出し法_、こんにちは。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者_ユニキャスト_先入れ先出し法_最低気温| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者_IP_アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目標_IP_アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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要求と応答が非同期な流れのパケットでSHALLを輸送しました。IEEE P1394aによって指定されたGASP形式の中で要約されてください(また、4.1を見てください)。 ソース_ID分野(非同期な流れのパケットのGASPヘッダーか1ブロックのパケットのヘッダーから得るか否かに関係なく、要求を書く)の最も重要な10ビットが0x3FFか受取人の最も重要な10ビットのNODE_IDSレジスタのどちらかと等しくない場合、1394年のARP要求の受取人か応答SHALLがそれを無視します。
Field usage in a 1394 ARP request/response is as follows:
1394ARP要求/応答における分野用法は以下の通りです:
hardware_type: This field indicates 1394 and SHALL have a value of
0x0018.
ハードウェア_タイプ: この分野は、1394とSHALLには0×0018の値があるのを示します。
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.
_タイプについて議定書の中で述べてください: この分野SHALLには、0×0800の値があります。 これは、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年について依存するハードウェア・アドレスでは、アドレスとSHALLは16の値を持っています。
Johansson Standards Track [Page 12] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[12ページ]。
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)では、アドレスとSHALLは4の値を持っています。
opcode: This field SHALL be one to indicate a 1394 ARP request and
two to indicate a 1394 ARP response.
opcode: これは1394年のARP要求を示す1と示す2が1394年のARP応答であったなら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.
送付者の_のユニークな_ID: この分野SHALLは指定されたそれへの同輩が送付者のバス情報ブロックであったなら送付者とSHALLのノード固有のIDを含んでいます。
sender_max_rec: This field SHALL be equal to the value of max_rec
in the sender's configuration ROM bus information block.
_送付者最大_rec: これは最大_の値への同輩が送付者の構成ROMバス情報ブロックの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 |
+---------------+
値の速度+---------------+ | 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.
そして、送付者_ユニキャスト_先入れ先出し法_、こんにちは、送付者_ユニキャスト_先入れ先出し法_最低気温: これらはSHALLを一緒にさばきます。送付者のセクション6によって指定された形式でIPデータグラムの領収書に利用可能な先入れ先出し法の48ビットのオフセットを指定してください。 パワーリセットの結果以外の送付者のユニキャストFIFO SHALL NOT変化のオフセット。
sender_IP_address: This field SHALL specify the IP address of the
sender.
送付者_IP_アドレス: この分野SHALLはIP送信者のアドレスを指定します。
target_IP_address: In a 1394 ARP request, this field SHALL specify
the IP address from which the sender desires a response. In a 1394
ARP response, it SHALL be IGNORED.
_IP_アドレスを狙ってください: 1394年のARP要求では、この分野SHALLは送付者が応答を望んでいるIPアドレスを指定します。 1394年のARP応答でそれ、SHALL、IGNOREDになってください。
Johansson Standards Track [Page 13] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[13ページ]。
6. CONFIGURATION ROM
6. 構成ROM
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できるノードSHALLが形式にユニットディレクトリを含んでいるので、構成ROMはこの規格で指定しました。 ISO/IECによって指定されるようにユニットディレクトリSHALLがUnit_Spec_IDとUnit_SW_バージョンエントリーを含んでいる、13213:1994
The unit directory may also contain other entries permitted by ISO/IEC 13213:1994 or IEEE P1212r.
また、ユニットディレクトリは1994年までにISO/IEC13213:受入れられた他のエントリーかIEEE P1212rを含むかもしれません。
6.1 Unit_Spec_ID entry
6.1 ユニット_Spec_IDエントリー
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×12| ユニット_仕様_ID、(0×00 005E)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 - Unit_Spec_ID entry format
図6--ユニット_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.
値、_ユニット_仕様ID SHALLにおいて、005E、登録ID(RID)がIANAでIEEE RAから得た0×00はそうです。 値は、IETFとその専門委員会はこの規格の維持に責任があるのを示します。
6.2 Unit_SW_Version entry
6.2 ユニット_SW_バージョンエントリー
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_バージョンエントリーはユニット_仕様_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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×13| ユニット_sw_バージョン、(0×00、0001)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 - Unit_SW_Version entry format
図7--ユニット_SW_バージョン入力フォーマット
The value of unit_sw_version SHALL be one, which indicates that the device complies with the normative requirements of this standard.
もの(装置がこの標準の要件に従うのを示す)が標準であったなら、ユニット_の値は_バージョンSHALLをswします。
Johansson Standards Track [Page 14] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[14ページ]。
6.3 Textual descriptors
6.3 原文の記述子
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できるノードSHOULDは「ユニット_SW_バージョンエントリーへのIPv4"」の内容でユニット_仕様_IDエントリーがある"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のできるノードによって実行されたユニットディレクトリを例証します。 それは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" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ディレクトリ_長さ(4)| CRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×12| ユニット_仕様_ID、(0×00 005E)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×81| 原文の記述子オフセット(3)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×13| ユニット_sw_バージョン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0×81| 原文の記述子オフセット(5)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原文の_の記述子_長さ(3)| CRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +--- ゼロ---+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 「私」| 「A」| 「N」| 「A」| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原文の_の記述子_長さ(3)| CRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +--- ゼロ---+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 「私」| 「P」| 「v」| "4" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 - Sample unit directory and textual descriptors
図9--サンプルユニットディレクトリと原文の記述子
Johansson Standards Track [Page 15] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[15ページ]。
7. IP UNICAST
7. IPユニキャスト
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 |
+--------------------------------------+
tcode記述Arbitration+--------------------------------------+ | 0×01| ブロックは書きます。| 非同期| | 0x0A| 流れのパケット| 同一時間| | 0x0A| 流れのパケット| 非同期| +--------------------------------------+
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.
最後の方法(非同期な流れのパケット)は単に完全性のために言及されます。 この方法SHOULD NOT、IPユニキャストに使用されてください、1394年のリンク・レベル承認もサービスの質も備えないので---そして、貴重なリソース、論理機番を消費します。
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);
- 地方のSerial Busの上のどんな2つのノードの間の最大の伝送速度を提供する1394年のバスマネージャによって維持されたSPEED_MAP。 バスマネージャは速度地図を構成するためにバストポロジーを分析します。 ノードの間の最大の伝送速度は介入しているノードの能力を反映します。 速度は順番に最大のデータペイロードを含意します(Table1を見てください)。
- the sender_max_rec field in a 1394 ARP response; or
- 1394年のARP応答における送付者_最大_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).
最大のデータペイロードSHALL、すべての介入しているノードの送付者によって実行された中で最も大きいデータペイロードの最小限と、受取人とPHYs(最終は送付者と受取人によって索引をつけられたSPEED_MAPエントリーで暗に示されている)になってください。
Johansson Standards Track [Page 16] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[16ページ]。
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.
以下に注意してください。 バスリセットへのその後のすべての1394のノードによって伝えられた自己IDパケットからSPEED_MAPを得ます。 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.
含まれて、サービスの質がベストエフォート型SHALLであるユニキャストIPデータグラムは1394年のブロックのデータペイロードの中に1394年のARP応答から得られたソース_IDと送付者_ユニキャスト_先入れ先出し法に記述された取引を書きます。
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データグラムがこの規格の範囲を超えています。
8. IP BROADCAST
8. 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放送より多くの1394へのサービスの質支給が全くありません。 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データグラムSHALLが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個の許可証ですが、以前にの使用はバスリセットへのその後の1秒まで論理機番を割り当てて、IPできるノードSHALL NOTはそれらのBROADCAST_CHANNELレジスタの有効なビットがゼロであるどんな時にも非同期な流れのパケットを伝えます。 有効なビットがバスでリセットのゼロを合わせるために自動的にきれいにされるので、これはIRMまでのIPが論理機番を割り当てる1394年のARPか放送の使用を禁止します。
9. IP MULTICAST
9. 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マルチキャストに使用されます。 ベストエフォート型を除いたサービスの質はこの規格の範囲を超えています。
Johansson Standards Track [Page 17] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[17ページ]。
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マルチキャストSHALLはBROADCAST_CHANNELレジスタから論理機番がチャンネル分野と等しい非同期な流れのパケットを使用します。 そして、特に、データグラムが.0を224.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:
以下の2つの条件の1つが会われる場合にだけ、IPできるノードはベストエフォート型IPマルチキャストを伝えるかもしれません:
- the channel number in the stream packet is equal to the channel
number field in the BROADCAST_CHANNEL register and the valid bit in
the same register is one; or
- 流れのパケットの論理機番は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は協力的なプロトコルです。 関係者は特定のSerial Busの上のすべての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.
警告: このドキュメントは1つ以上のIPマルチキャストアドレスでただ一つの論理機番(BROADCAST_CHANNELレジスタによって指定されたデフォルト論理機番を除いた)の共有された使用のための施設と方法を定義しません。
9.1 MCAP message format
9.1 MCAPメッセージ・フォーマット
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つの八重奏が固定されています。 残りは可変長のtuplesから成ります。それはそれぞれ特定のIPマルチキャストグループの情報をコード化します。 個々のMCAPメッセージSHALL NOT、断片化されてください、SHALL、エーテル_タイプ0x8861として流れのパケットの中で要約されてください。
Johansson Standards Track [Page 18] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[18ページ]。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | reserved | opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ message data +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| 予約されます。| opcode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + メッセージデータ+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
長さ: この分野SHALLは全体のMCAPメッセージの八重奏におけるサイズを含んでいます。
opcode: This field SHALL have one of the values specified by the
table below.
opcode: この分野SHALLは以下のテーブルで値の1つを指定させます。
opcode Name Comment
+----------------------------------------------------------------+
| 0 | Advertise | Sent by a multicast channel owner to |
| | | broadcast the current mapping(s) from one |
| | | or more group addresses to their |
| | | corresponding channel number(s). |
| 1 | Solicit | Sent to request multicast channel owner(s) |
| | | to advertise the indicated channel |
| | | mapping(s) as soon as possible. |
+----------------------------------------------------------------+
opcode Name Comment+----------------------------------------------------------------+ | 0 | 広告| マルチキャストチャンネル所有者で、発信します。| | | | 1から現在のマッピングを放送してください。| | | | または、以上がアドレスを分類する、それら| | | | 対応する論理機番。 | | 1 | 請求してください。| マルチキャストチャンネル所有者を要求するために、送ります。| | | | 示されたチャンネルの広告を出すために| | | | できるだけ早く、(s)を写像します。 | +----------------------------------------------------------------+
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メッセージの残りは長さで可変です、そして、SHALLがゼロから成るか、または形式がある、より多くのグループアドレス記述子が以下で例証しました。
Johansson Standards Track [Page 19] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[19ページ]。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | type | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| expiration | channel | speed | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ group_address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| タイプ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 満了| チャンネル| 速度| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 帯域幅| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + グループ_アドレス+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11 - MCAP group address descriptor format
図11--MCAPグループアドレス記述子形式
length: This field SHALL contain the size, in octets, of the MCAP
group address descriptor.
長さ: この分野SHALLはMCAPグループアドレス記述子の八重奏におけるサイズを含んでいます。
type: This field SHALL have a value of one, which indicates a
group address descriptor.
以下をタイプしてください。 この分野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.
満了: opcodeによると、この分野の用法は異なります。 満了がSHALLをさばくという請求メッセージに関しては、IGNOREDになってください。 さもなければ、広告のために、この分野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.
以下を精神を集中させてください。 メッセージ、その場合それの広告を出してください。この分野が有効である、唯一、SHALLは範囲でゼロ〜63に包括的に割り当てられた論理機番を指定します。 他のすべての値が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.
速度: この分野が有効である、唯一、メッセージの広告を出してください、そして、どれがそれをケースに入れるかでSHALLが速度を指定するかは示されたチャンネルのためのどの流れのパケットで伝えられるか。 テーブル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.
帯域幅: これは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.
_アドレスを分類してください: この可変長フィールドSHALLは特定のIPマルチキャストグループのIPアドレスを指定します。 グループアドレス記述子の長さから長さの分野から12を引き算することによって、八重奏における、グループ_アドレスの長さを得ます。
Johansson Standards Track [Page 20] RFC 2734 IPv4 over IEEE 1394 December 1999
ヨハンソンStandardsは1999年12月にIEEE1394の上でRFC2734IPv4を追跡します[20ページ]。
9.2 MCAP message domain
9.2 MCAPメッセージドメイン
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 IGNOREの受取人。 送付者のソース_IDは要約のMCAPメッセージに先行するGASPヘッダーに含まれています。 SHALLがGASPヘッダーからソース_IDの最も重要な10ビット離れたところで調べるMCAPメッセージの受取人。 それらであるなら、受取人の0x3FFか最も重要な10ビットのどちらかのNODE_IDSレジスタへの同輩、受取人SHALL IGNOREはメッセージではありませんか?
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ヘッダーのソース_ID分野によって特定されます。 所有者は最も大きい物理的なIDがあるノード、ソース_IDの最も重要でない6ビットです。
9.3 Multicast receive
9.3マルチキャストは受信されます。
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).
最初にマルチキャストデータSHALLを受け取りたがっているIPできる装置は、それを写像する(もしあれば)チャンネルがグループアドレスとBROADCAST_CHANNELレジスタによって指定されたデフォルトチャンネル以外の論理機番の間に存在するのを確かめます。 そのような装置は、必要なチャンネルのための放送チャンネルに関するMCAP広告が(s)を写像しているのを観測するかもしれません。
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.
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.
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.
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.
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.
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.
Johansson Standards Track [Page 21] RFC 2734 IPv4 over IEEE 1394 December 1999
Johansson Standards Track [Page 21] RFC 2734 IPv4 over IEEE 1394 December 1999
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.
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.
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.
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.
9.4 Multicast transmit
9.4 Multicast transmit
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.
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.
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.
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.
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.
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.
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.
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.
Johansson Standards Track [Page 22] RFC 2734 IPv4 over IEEE 1394 December 1999
Johansson Standards Track [Page 22] RFC 2734 IPv4 over IEEE 1394 December 1999
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.
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.
9.5 Advertisement of channel mappings
9.5 Advertisement of channel mappings
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).
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).
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.
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.
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.
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.
9.6 Overlapped channel mappings
9.6 Overlapped channel mappings
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.
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.
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
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
Johansson Standards Track [Page 23] RFC 2734 IPv4 over IEEE 1394 December 1999
Johansson Standards Track [Page 23] RFC 2734 IPv4 over IEEE 1394 December 1999
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.
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.
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.
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.
9.7 Transfer of channel ownership
9.7 Transfer of channel ownership
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 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.
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.
Johansson Standards Track [Page 24] RFC 2734 IPv4 over IEEE 1394 December 1999
Johansson Standards Track [Page 24] RFC 2734 IPv4 over IEEE 1394 December 1999
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.
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.
9.8 Redundant channel mappings
9.8 Redundant channel mappings
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.
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.
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.
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.
9.9 Expired channel mappings
9.9 Expired channel mappings
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.
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.
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.
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.
Johansson Standards Track [Page 25] RFC 2734 IPv4 over IEEE 1394 December 1999
Johansson Standards Track [Page 25] RFC 2734 IPv4 over IEEE 1394 December 1999
9.10 Bus reset
9.10 Bus reset
A bus reset SHALL invalidate all multicast channel mappings and SHALL cause all multicast recipients and senders to zero all MCAP advertisement interval timers.
A bus reset SHALL invalidate all multicast channel mappings and SHALL cause all multicast recipients and senders to zero all MCAP advertisement interval timers.
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.
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.
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.
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.
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.
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. IANA CONSIDERATIONS
10. IANA CONSIDERATIONS
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.
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.
Johansson Standards Track [Page 26] RFC 2734 IPv4 over IEEE 1394 December 1999
Johansson Standards Track [Page 26] RFC 2734 IPv4 over IEEE 1394 December 1999
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.
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.
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.
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.
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.
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.
11. SECURITY CONSIDERATIONS
11. SECURITY CONSIDERATIONS
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.
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.
12. ACKNOWLEDGEMENTS
12. ACKNOWLEDGEMENTS
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.
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.
Johansson Standards Track [Page 27] RFC 2734 IPv4 over IEEE 1394 December 1999
Johansson Standards Track [Page 27] RFC 2734 IPv4 over IEEE 1394 December 1999
13. REFERENCES
13. REFERENCES
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.
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, Standard for a High Performance Serial Bus
[2] ISO/IEC 13213:1994, Control and Status Register (CSR)
Architecture for Microcomputer Buses
[2] ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture for Microcomputer Buses
[3] IEEE Project P1394a, Draft Standard for a High Performance Serial
Bus (Supplement)
[3] IEEE Project P1394a, Draft Standard for a High Performance Serial Bus (Supplement)
[4] IEEE Project P1394b, Draft Standard for a High Performance Serial
Bus (Supplement)
[4] IEEE Project P1394b, Draft Standard for a High Performance Serial Bus (Supplement)
[5] Postel, J., "Internet Protocol Darpa Internet Program Protocol
Specification", RFC 791, September 1981.
[5] Postel, J., "Internet Protocol Darpa Internet Program Protocol Specification", RFC 791, September 1981.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
14. EDITOR'S ADDRESS
14. EDITOR'S ADDRESS
Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94602
Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94602
Phone: (510) 527-3926 Fax: (510) 527-3856 EMail: pjohansson@aol.com
Phone: (510) 527-3926 Fax: (510) 527-3856 EMail: pjohansson@aol.com
Johansson Standards Track [Page 28] RFC 2734 IPv4 over IEEE 1394 December 1999
Johansson Standards Track [Page 28] RFC 2734 IPv4 over IEEE 1394 December 1999
15. Full Copyright Statement
15. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright (C) The Internet Society (1999). All Rights Reserved.
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.
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.
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.
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
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Johansson Standards Track [Page 29]
Johansson Standards Track [Page 29]
一覧
スポンサーリンク
