RFC2734


Network Working Group                                            P. Johansson
Request for Comments: 2734                               Congruent Software Inc.
カテゴリ: トラック標準                                            1999年12月

             IPv4 over IEEE 1394

本覚書の地位
 本覚書はインターネットコミュニティのためにインターネット標準トラックプロトコル
を指定し、改善のためのディスカッションやサジェスチョンを求めるものである。
このプロトコルの標準化事情と状況については"Internet Official Protocol Standard"の
最新版を参照のこと。この覚書の記述に制限はない。

著作権
 Copyright c  The Internet Society(1999)     すべての権利を保有

概要
 本覚書はInternet Protocol Version 4(Ipv4)データグラムの転送のために、IEEE Std 
1394-1995 高性能シリアルバス(とその付属品)標準をいかに使用するかを述べたもので
あり、必要な方法、データ構造、コードを定めている。ここにはデータグラムのパケット
フォーマットとカプセル化の方法だけでなく、アドレスリゾルーションプロトコル(1394 
ARP)とマルチキャストチャネルアロケーションプロトコル(MCAP)が含まれている。
1394 ARPとMCAPの双方ともシリアルバスを特定する。後者はIPマルチキャストグル
ープが使用するときシリアルバスリソースの管理を認める。

目 次
1. 初めに
2. 定義と注釈
2.1 適合性
2.2 用語解説
2.3 略語
2.4 数値
3. IP対応ノード
4. リンクカプセル化とフラグメンテーション
4.1 グローバル非同期ストリームパケット(GASP)フォーマット
4.2 カプセルヘッダ
4.3 リンクフラグメント再アッセンブリ
5. シリアルバスアドレスリゾルーションプロトコル(1394 ARP)
6. コンフィグレーションROM
6.1 ユニットスペックIDエントリ
6.2 ユニットスイッチバージョンエントリ
6.3 テキスト記述子
7. IP ユニキャスト
8. IP ブロードキャスト
9. IP マルチキャスト
9.1 MCAPメッセージフォーマット
9.2 MCAPメッセージドメイン
9.3 マルチキャスト受信
9.4 マルチキャスト送信
9.5 チャネルマッピング広告
9.6 オーバーラップチャネルマッピング
9.7 チャネル所有権の移譲
9.8 冗長チャネルマッピング
9.9 エクスパイアチャネルマッピング
9.10  バスリセット
10.IANAについて
11.セキュリティについて
12.感謝
13.参照
14.著者住所
15.著作権全文

1. はじめに
 本文書はインターネットプロトコルバージョン4(Ipv4)データグラム転送のための
IEEE Std 1394-1995 高性能シリアルバス(及びその付属物)標準の使い方を指定したも
のである。必要な方法、データ構造、コードを定義し、また付加的にアドレスソルーショ
ンプロトコル(1394 ARP)およびマルチキャストチャネルアロケーションプロトコル
(MCAP)も定義した。双方ともシリアルバスを特定する。
 
 一連のIEEEスタンダードおよび補足は草稿でも公認のものでも、IEEE Std 1394-1995
に関連するものは、今後1394としてかあるいはシリアルバスとして参照される。

 1394は相互連結(バス)であり、CSRアーキテクチャ ISO/IEC 13213:1994に従う。
シリアルバスは共有する物理媒体上のノード間を現在100Mbpsから400Mbpsの範囲の速
度で情報を伝達することを可能にする。消費家電(たとえばデジタルVCR、ステレオシス
テム、テレビ、カムコーダー)と伝統的デスクトップコンピュータ関連機器(大容量記憶
装置、プリンタ、テープ等)の双方ともが1394を採用している。シリアルバスは消費家電
とコンピュータの双方の領域に適合する唯一のものであり、両方タイプのの機器を繋げる
SOHOネットワークの基礎を作ると「期待されている」。

 CSRアーキテクチャはシリアルバスが64ビット固定アドレススキームとして組み込ま
れるメモリマップアドレススペースを説明している。アドレススペースのうち、10ビット
はバスID(最高1,023バスまで)に割り当てられ、6ビットはノード物理ID(1バスあた
り63まで)に割り当てられる。残り48ビット(オフセット)は256テラバイトの各ノー
ドのアドレススペースを示している。CSRアーキテクチャは協定により、ノードアドレス
スペースを分割し異なる行動特性を持つ2つの領域に分ける。下部は0XFFFFを含まない 
F000  0000までで、リードとライトトランザクションへのレスポンスにおいてメモリとし
て行動することを「期待される」。上位は伝統的なIOスペースに似ている。このエリアの
リードとライトトランザクションは常に側面効果がある。FIFO行動を持つコントロール・
ステータスレジスタ(CSRs)は習慣的にこの領域に組み込まれる。

 64ビットアドレス内で、16ビットノードID(バスIDおよび物理ID)は、ネットワー
クハードウエアアドレスに機能上類似している。しかし1394ノードIDは不定で、1つか
それ以上のノードが加わるかバスから移動する度に再アサインメントを必要とする。

 注:16ビットノードIDはバスIDを含んでいるが、現在、列挙したシリアルバスを個別
に接続する標準的方法はない。シリアルバスからシリアルバスへのブリッジのための標準
の開発がIEEE P1394、 1ワーキンググループで積極的に行われている。将来の標準によ
って書きなおされなければ、本文書で記述した1394上のIpv64プロトコルはブリッジを越
えては正確に動作しないかもしれない。

 1394リンク層は確認済み(公認の)パケットと未確認のパケット双方にパケットデリバ
リーサービスを提供する。2つのレベルのサービスが有効である。「非同期」パケットはベ
ストエフォートを基礎に送られる。一方「アイソクロノス(等時性)」パケットは限られた
待ち時間で送られることが保障されている。確認済みパケットは常に非同期であるが、未
確認パケットは非同期であるかもしれないし、等時性であるかもしれない。データペイロ
ードは実装に伴って変化し、1オクテットから伝送速度によって決められた最高までに及
ぶ(100MbpaをS100と言う、最大データペイロードは512オクテットだが、S400でそ
れは2048オクテットである)。
 注:IEEE P1394bで行われている拡張で800、1600、3200Mbpsのスピードの追加を
考慮中である。

2. 定義と注釈
2.1 適合性
 「かもしれない」、「オプショナル」、「薦める」、「要求される」、「はずである」「しない
であろう」、「すべきだ」、「すべきでない」は、本文書で使用するとき、要求及び選択のレ
ベルを区別し、RFC 2119で規定したものとして解釈される。

いくつかの追加的キーワードが使われる、以下に示す。

「期待される」:この標準で想定されるデザインモデルのハードウエア又はソフトウエアの
動作を説明するのに使われるキーワード。他のハードウエアとソフトウエアのデザインモ
デルもまた実装されるかもしれない。

「無視する」:その値が受信者にチェックされないビット、オクテット、カドレット、フィ
ールドを説明するキーワード

「予約する」:オブジェクト、即ちビット、オクテット、カドレット、フィールドあるいは
これらオブジェクトに割り当てられるコード値を説明するのに用いられるキーワード。オ
ブジェクトにしてもコード値にしても将来の標準化のためにとって置かれる。「予約され
た」オブジェクトは定義された意味をもたず、創始者にゼロにされるか、将来の標準を開
発する上で、その標準によって指定された値を設定される「であろう」。「予約された」オ
ブジェクトの受信者はその値をチェックし「ないであろう」。本標準でコード値が定義され
たオブジェクトの受信者はその値をチェックし「予約された」コード値を拒否するであろ
う。

2.2 用語の解説
 次の用語が本標準で使われる。

アドレスリゾルューションプロトコル:要求側がノードのIPアドレスから、ある1つのIP
ノードのハードウエア(1394)アドレスを決定する方法。

バスID:多くの多重相互接続バスの中の特定のバスを唯一識別する10ビットの数。この
バスIDはノードの16ビットノードIDの最上位部分である。0x3FFはローカルバスを示
している。ノードは、リクエストのバスIDが0x3FFであるか、バスIDが明白にそのノー
ドに割り当てられているなら、その6ビット物理IDをアドレス指定しているリクエストに
レスポンスを返す「であろう」。
カプセルヘッダ:1394上を伝送するすべてのIPデータの先頭にある構造。リンクフラグ
メントを参照。
IPデータグラム:RFC 791 STD 5で指定したフォーマットに従ったインターネットメッ
セージ。
リンクフラグメント:シングル1394パケットの中で伝送されるIPデータグラムの一部。
1394パケットのデータぺイロードはカプセルヘッダとそれに対応するリンクフラグメント
を含んでいる。リンクフラグメンテーションなしでデータグラムを伝送することが可能で
ある。
マルチキャストチャネルアロケーションプロトコル:マルチキャストデータグラムがデフ
ォルト以外のブロードキャストチャネルで伝送される時、マルチキャストグループがシリ
アルバスリソース(チャネル)の使用を調整する方法。
マルチキャストチャネル所有者:ひとつあるいはそれ以上のマルチキャストアドレスに1
つのチャネルを割り当て、IPマルチキャストグループの他の参加者にこれらのチャネルマ
ッピングを伝えるためMCAP広告を送信するマルチキャストソース。1つ以上のソースが
同じチャネルbノMCAP広告を伝送するとき、一番大きな物理IDを持つソースが所有者
である。
ノードID:多くの多重相互バスの中で1つのシリアルバスノードを唯一識別する16ビッ
ト数。最上位10ビットはバスIDで、最下位6ビットは物理IDである。
ノードユニークID:世界レベルで作成されるすべてのシリアルバスノードの中で1つのバ
スノードを唯一識別する64ビット数。EUI-64(エクステンディド・ユニーク・アイデン
ティファイア、64ビット)としても知られている。
オクテット:8ビットのデータ
パケット:すべての1394のプライマリーパケット。リード、ライト、ロックリクエスト(及
びそのリスポンス)、ストリームデータが考えられる。「パケット」という言葉は、シリア
ルバスプライマリーパケットと1394 ARPリクエスト/リスポンス、IPデータグラム、MCAP
広告/請求とを区別するために常に使われる。
物理ID:特定のバスで、この6ビット数は自己認識の過程でダイナミックに割り当てられ、
そのバス上のノードを唯一識別する。
カドレット:4オクテットあるいは32ビットのデータ
ストリームパケット:0x0Aのトランザクションコード付きの1394プライマリーパケット
、ブロックデータペイロードを含んでいる。ストリームパケットは使用する1394アービト
レーションのタイプによって非同期であるかもしれないし等時性であるかもしれない。

2.3 略語
 次のものは、本標準で用いられる略語である。
 1394 ARP  アドレスリゾリューションプロトコル(1394固有)
 CSR    コントロール・ステータスレジスタ
 CRC    サイクリカルリダンダンシーチェック
 EUI-64   拡張ユニークアイデンティファイア、64ビット
 GASP    グローバル非同期ストリームパケット
 IP     インターネットプロトコル(本ドキュメント内、Ipv4)
 MCAP   マルチキャストチャネルアロケーションプロトコル

2.4 数値
 10進数及び16進数が本標準で使われる。編集の都合で、10進数は数量やカウントに最
も多く用いられ、アドレスは16進数で示されるが、示される数値が10進数形式より16進
数形式の方がより判りやすい基本的構造を持っているときも用いられる。
 10進数はアラビア数字か英語名で表示され、16進数は0xを前に付け0-9、A-Fの文字で
表される。見やすさのため、16進数はスペースで区切られた4桁の数字に区切られる。
 たとえば、42と0x42は同じ数値を表している。

3 IP対応ノード
 すべてのシリアルバスが1394 ARP リクエスト/リスポンスあるいはIPデータグラムの
受信及び送信が出来るわけではない。IP対応ノードは下記の最低限の要求を満足させる「は
ずである」。
 −ISO/IEC 13213:1994で指定される一般フォーマットのコンフィグレーションROM
を実装する「はずである」。また、IEEE P1394aで指定されるバスインフォメーションブ
ロック及び本標準で指定されるユニットディレクトリを実装する「はずであれる」。
 −そのバスインフォメーションブロックのマックス_レコードフィールドは少なくとも
8である「はずである」。これはブロックライトリクエスト及び512オクテットのデータペ
イロード付きの非同期ストリームパケットを受け入れる能力を示している。同じ能力はま
たリードリクエストにも適用する「はずである」。即ちノードは512オクテットのデータペ
イロード付きブロックリスポンスパケットを伝送できる「はずである」。
 −それはIEEE P1394aで指定されるように、等時性リソースマネジャー対応である「は
ずである」。
 −それはIEEE P1394aで指定されるように、非同期ストリームの受信及び送信の双方を
サポートする「はずである」。

4.リンクカプセル化及びフラグメンテーション
 1394ブロックライトリクエストあるいはストリームパケット経由で送信されるIPデー
タグラム(ブロードキャスト、ユニキャスト、マルチキャスト)、1394 ARP リクエスト
/リスポンス、MCAP広告/請求のすべてがパケットのデータペイロードの中でカプセル化さ
れる「はずである」。データペイロードの最大サイズは、オクテットで、パケットが送信さ
れるスピードによって制限される。

       表1 マクシマムデータペイロード

       速度    非同期    等時性
       +----------------------------------+
         |   S100  |      512      |  1024  |
            |   S200  |     1024      |  2048  |
            |   S400  |     2048      |  4096  |
            |   S800  |     4096      |  8192  |
            |  S1600  |     8192      | 16384  |
            |  S3200  |    16384      | 32768  |
            +----------------------------------+

 注:S800及びそれ以上の速度のマクシマムデータペイロードはIEEE P1394Bによる標
準化の結果、減少するかもしれない(増加することはないであろうから)。
 非同期のリクエストとリスポンス用のマクシマムデータペイロードは送信ノードあるい
は受信ノードの能力によっても制限されるかもしれない。即ちこれはバスインフォメーシ
ョンブロックあるいは1394 ARPリスポンスのいずれかのマックス_レコードによって指
定される。
 これらの理由のいずれかのため、IP対応ノード間で伝送できるマクシマムデータペイロ
ードは本ドキュメントで指定されるデフォルトのS1500オクテットのマキシマムトランス
ミッションユニット(MTU)以下であるかもしれない。このことはカプセル化フォーマット
もまたIPデータグラムの1394リンクレベルのフラグメンテーションと再アッセンブリを
認めることを要求している。
 注:IP対応ノードはデフォルトより大きいMPUサイズで作動するかもしれない。しか
しより大きなMPUが構成されたときの手段は本ドキュメントでは関知しない。

4.1 グローバル非同期ストリームパケット(GASP)フォーマット
 いくつかのIPデータグラムは、1394 ARPリクエスト及びリスポンスと同様、非同期
ストリームパケット経由で伝送されるであろう。非同期ストリームパケットが使われると
き、そのフォーマットはIEEE P1394aで指定されるグローバル非同期ストリームパケット
(GASP)に合致す「べきである」。下記に描いたGASPフォーマットは「情報提供のため」
で参照し易いように再度作成された。

                       1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          データ長           |tag| チャンネル|  0x0A |   sy  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           ヘッダ_CRC                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           ソース_ID           |        specifier_ID_hi        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |specifier_ID_lo|                  バージョン           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +---                          データ                         ---+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           データ_CRC                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            図1 GSAP フォーマット

 ソース_IDフィールドは送信ノードのノードIDを指定し「なければならず」、また送信
側のNODE-ID レジススタの最上位16ビットに等しい「はずである」。
 Specifier-ID-hiとspecifier-ID-loフィールドはともに0x0O 005E値、IEEEレジストレ
ーション・オーソリティ(RA)によってIANAに割り当てられた24ビット構成のユニークア
イデンティファイア(OUI)を含んでいる「はずである」。
 バージョンフィールドは1つである「はずである」。
 注:GASPフォーマットは非同期ストリームパケットフォーマットのデータペイロード
の第1・第2カドレットを利用するため、表1に引用したマクシマムペイロードは8オク
テットによって効果的に減少される。続く文節で、データペイロードの第1カドレットを
参照することは第1カドレットがIPデータグラムあるいは1394  ARPリクエスト又はリ
スポンスにとって有益であることを意味する。GASPフォーマットが使用されるとき、こ
れはパケット用データペイロードの第3カドレットである。

4.2 カプセルヘッダ
 1394上で伝送されるIPデータグラムはすべて下記に示すフォーマットの1つを持つカ
プセルヘッダが先頭に付いている。
 完全なIPデータグラムがシングル1394パケットの中で伝送されるなら,それはフラグ
メントされず、データペイロードの第1カドレットは下記に示すフォーマットに合致する
「はずである」。
                        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|            予約           |    いずれかのタイプ          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          図2 フラグメントされていないカプセルヘッダフォーマット

 lfフィールドは0である「はずである」。
 いずれかのタイプ・フィールドは下表に示されるように後続のデータグラムの性質を示
している「はずである」。

                  いずれかのタイプ データグラム
                    +-------------------------+
                    |   0x0800   |   IPv4     |
                    |   0x0806   |   1394 ARP |
                    |   0x8861   |   MCAP     |
                    +-------------------------+
 注:いずれかのタイプの指定によって識別される他のネットワークプロトコルもここで
定義するカプセル化フォーマットを使用するかもしれないが、そのような使用に関して本
ドキュメントは関知しない。
 データグラムの長さが送信側や全受信者にサポートされているマクシマムデータペイロ
ードを超えている場合、データグラムはリンクフラグメントに分けられる「はずである」。
第1番目のリンクフラグメント用のデータペイロードの第1・第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| データグラムサイズ    |         いずれかのタイプ      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              dgl              |              予約             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            図3 第1フラグメントのカプセルヘッダフォーマット

 第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|    データグラムサイズ |  rsv  |   フラグメント・オフセット    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              dgl              |              予約             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        図4 後続フラグメントのカプセルヘッダフォーマット

 フィールドの定義および使用法は以下のとおりである、
 lfフィールドは、下表によってコード化されるように、IPデータグラム内のリンクフラ
グメントの相対的な位置を指定する。
                        lf          位置
                     +------------------------+
                     |   0   | フラグメント無 |
                     |   1   |  先頭          |
                     |   2   |  最後          |
                     |   3   |  内部        |
                     +------------------------+
 データグラムサイズ:IPデータグラム全体のエンコードサイズ。データグラムサイズの値
は、1つのIPデータグラムの全リンクフラグメントと同じである「はずで」、データグラム
のIPヘッダ(STD 5、RFC 791を参照)中のトータル長以内である「はずである」。
いずれかのタイプ:このフィールドは第1リンクフラグメント中にのみあり、それはIPv4
データグラムを示す0x0800の値を持ってい「なければならない」。
フラグメント・オフセット:このフィールドは第2及び後続のリンクフラグメントにのみ存
在し、IPデータグラムの始めから、オクテットで、フラグメントのオフセットを指定する
「はずである」。データグラムの第1オクテット(IPヘッダのスタート)は零のオフセット
を持っている。第1リンクフラグメントのフラグメント・オフセットの暗黙の値は0であ
る。
dgl:dgl(データグラム・ラベル)値は1つのIPデータグラムの全フラグメントが同じであ
る「はずである」。送信側は続けてdglをインクリメントする「はずである」。dglのインク
リメント値は65,535から0までを循環する「はずである」。

 すべてのIP(All IP)データグラムは、送信モード(ブロックライトリクエストあるいはス
トリームパケット)にかかわらず、上述カプセルヘッダのうちの1つを先頭に付加し「なけ
ればならない」。このことは、それらの送信モードを配慮せず、データグラムの画一化した
ソフトウェア処理を認めることである。

4.3 リンクフラグメント再アセンブリ
 1つ以上の1394パケットを経由して送信されたIPデータグラムの受信者は、シングルデ
ータグラムからの全リンクフラグメントを識別するために、送信側のソース_ID(非同期パ
ケットヘッダあるいはGASPヘッダのいずれから得られる)およびdglの両方を使用する「は
ずである」。
 リンクフラグメントの受信に際して、受信者はIPデータグラム再リアセンブリバッファ
内のフラグメントオフセットによって指定された位置にデータ・ペイロード(カプセルヘッ
ダの無い)を置く。再アセンブリバッファのサイズはデータグラムサイズによって決まる。
  リンクフラグメントが、受信されるとき、同じソース_IDおよびdglによって識別され
た他のフラグメントをオーバーラップするなら、再リアセンブリバッファに既に蓄積され
たフラグメントは廃棄される「はずである」。最新の再アセンブリは最も新しく受信したリ
ンクフラグメントで行われるであろう。フラグメントのオーバーラップは、カプセルヘッ
ダからのフラグメントオフセットと1394パケットヘッダからのデータ長との組み合わせで
決まる。
 シリアルバスリセットの検出で、受信者は部分的に再アッセンブルされた全IPデータグ
ラム、リンクフラグメントのすべてを廃棄する「はずである」し、送信側は、部分的に送
信されたすべてのIPデータグラムのまだ送信されていないリンクフラグメントを廃棄する
「はずである」。

5. シリアルバスアドレスリゾルーションプロトコル(1394 ARP)
 その対応するIPアドレスからデバイスのハードウェア・アドレスを決定する方法は、デ
バイスに使われる伝送媒体に複雑に結びついている。下記の、およびこのドキュメント全
体にわたる記述では、頭文字1394 ARPは、単にその方法およびデータ構造が1394を指す
アドレスリゾリューションプロトコルに関するだけである。
 1394 ARPリクエストは、IPデータグラムのブロードキャストと同じ手段によって送信さ
れる「はずである」。すなわち、1394 ARPレスポンスも同じ手段で送信し「てよい」。1394 ARP
リクエストも同じように伝送して「よく」、あるいは1394 ARPリクエストにより識別され
る送信側ユニキャストFIFOアドレスに宛てたブロックライトリクエストとして伝送されて
も「よい」。1394のARPリクエスト/レスポンスは32オクテットであり、また図5に描かれ
たフォーマットに合致する「はずである」。
                       1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ハードウエアタイプ (0x0018)|  プロトコルタイプ(0x0800)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  hw_addr_len  |  IP_addr_len  |            opcode             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +---                   送信側_ユニークID                  ---+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+-+-+
   | 送信側_max_rec|      sspd     | 送信側_ユニキャスト_FIFO_hi   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              送信側_ユニキャスト_FIFO_lo                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       送信側_IP_アドレス                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ターゲット_IP_アドレス                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           図5  1394のARPリクエスト/レスポンスフォーマット

 非同期ストリームパケットで伝送される1394 ARPリクエスト及びリスポンスは、IEEE 
P1394a(4.1を参照)によって指定された、GASPフォーマット内でカプセル化される「はず
である」。1394 ARPリクエストあるいはレスポンスの受信者はソース_IDフィールド(非同
期ストリームパケットのGASPヘッダから得たても、あるいはブロックライトリクエストの
パケットヘッダから得ても)の最上位10ビットが、0x3FFもしくは受信者のノード_IDSレ
ジスタの最上位10ビットのいずれとも等しくなければ、それを無視する「であろう」。
 1394 ARPリクエスト/レスポンス中のフィールドの使用法は以下のとおりである:
ハードウエアタイプ:このフィールドは、1394を指し、0x0018の値を取る「はずである」。
プロトコルタイプ:このフィールドは0x0800の値を取る「はずである」。これは、1394 ARP
のリクエスト/レスポンス中のプロトコルアドレスがIPアドレス用フォーマットに合致す
ることを示している。
hw_addr_len:このフィールドはIPアドレスに関連する1394に従属したハードウェアアド
レスのサイズをオクテットで示す、16の値を取る「はずである」。
IP_addr_len:このフィールドはIPバージョン4(IPv4)アドレスのサイズを、オクテットで
示す。4の値を取る「はずである」。
opcode:このフィールドは、1394 ARPリクエストを示すとき1で、1394 ARPリスポンスを
示すとき2である「はずである」。
送信側_ユニーク_ID:このフィールドは送信側のノードユニークIDを含み、送信側バスイ
ンフォメーションブロックで指定されるものと等しい「はずである」。
送信側_max_rec:このフィールドは、送信側のコンフィグレーションROMバスインフォメー
ションブロック中のmax_rec値と等しい「はずである」。
sspd:このフィールドは、送信側のリンク速度およびPHY速度より遅く設定される「はずで
ある」。リンク速度とはリンクがパケットを送信するか受信する最高速度である。PHY速度
とはPHYがパケットを送信、受信、反復する最高速度である。下表は、sspdのために使用
される符号化を指定する。指定されない値はすべて将来の標準化のための予約である。

           表2 スピードコード
                            Value   Speed
                          +---------------+
                          |   0   |  S100 |
                          |   1   |  S200 |
                          |   2   |  S400 |
                          |   3   |  S800 |
                          |   4   | S1600 |
                          |   5   | S3200 |
                          +---------------+
送信側_ユニキャスト_FIFO_hiおよび送信側_ユニキャスト_FIFO_lo:これらのフィールド
は、ともに6章によって指定されたフォーマットの中でIPデータグラムの受信に有効であ
る送信側FIFOの48ビットのオフセットによって指定される「はずである」。送信側_ユニ
キャスト_FIFOは、パワーリセットの結果として以外には、変更「しないはずである」。
 送信側_IP_アドレス:このフィールドは、送信側のIPアドレスを指定する「はずである」。
 ターゲット_IP_アドレス:1394 ARPリクエストの中で、このフィールドは、送信側がレス
ポンスを要求するIPアドレスを指定する「はずである」。1394 ARPレスポンスでは、それ
は、無視される「はずである」。

6. コンフィギュレーションROM
 IP対応ノード用のコンフィギュレーションROMは、この標準によって指定されるフォー
マット中にユニットディレクトリを含んでいる「であろう」。ユニットディレクトリは、
ISO/IEC 13213:1994によって指定されるようにユニット_Spec_IDとユニット_SW_Version
のエントリを含んでいる「はずである」。
 ユニットディレクトリは、さらに、ISO/IEC 13213:1994あるいはIEEE P1212rによって
許された他のエントリを含んでいるかもしれない。
6.1 ユニット_Spec_IDエントリ
 ユニット_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     |           ユニット_spec_ID (0x00 005E)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               図6  ユニット_Spec_IDエントリフォーマット

 ユニット_spec_IDの値は、0x00 005Eで、IEEE RAからのIANAによって得られるレジス
トレーションID(RID))である「はずである」。値はIETFとその技術委員会が本標準の保守
に責任を持つことを示している。

6.2 ユニット_SW_Versionエントリ
 ユニット_SW_Versionエントリは、ユニットディレクトリの中の直接エントリである。そ
れは、ユニット_spec_IDと結合して、ユニットのソフトウェア・インタフェースを定義す
るドキュメントを指定する。
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x13     |         ユニット_sw_version (0x00 0001)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             図7  ユニット_SW_Versionエントリフォーマット

 ユニット_sw_version 値は、1である「はずである」、それはデバイスが本標準の規範的
要求を守ることを示している。

6.3 テキスト記述子
 コンフィギュレーションROM内のテキスト記述子は「オプショナル」である。存在する
とき、それらは付加的な記述的な情報を提供し、人間のユーザに理解可能であることを目
指している。IP対応ノードは、テキスト記述子によってユニット_Spec_IDエントリを持つ
「IANA」の内容を連想させ、またテキスト記述子によりユニット_SW_Versionエントリ用の
「IPv4」の内容を連想させる「はずである」。
 下図は、IP対応ノード-によって組み込まれたユニットディレクトリを示す、それは「オ
プショナル」なテキスト記述子を含んでいる。テキスト記述子はユニットディレクトリの
一部でなくとも、単純にするため、ユニットディレクトリ直後に示される。
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ディレクトリ_長  (4)    |              CRC              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x12     |        ユニット_spec_ID (0x00 005E)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x81     |        テキスト記述子オフセット  (3)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x13     |            ユニット_sw_version                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0x81     |        テキスト記述子オフセット (5)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  テキスト_記述子_長(3)    |               CRC              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +---                         ゼロ                           ---+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      "I"      |      "A"      |      "N"      |      "A"      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | テキスト_記述子_長    (3) |              CRC              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +---                          ゼロ                          ---+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      "I"      |      "P"      |      "v"      |      "4"      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      図9   ユニットディレクトリおよびテキスト記述子の例

7. IPユニキャスト
 ユニキャストIPデータグラムは、次のトランザクションコードのうちの1つを持ってい
る1394プライマリパケット内の受信者に送信される「かもしれない」。
              tcode     記述       アービトレーション
            +-----------------------------------------------------+
            |  0x01 | ブロックライト   | アシンクロナス(非同期) |
            |  0x0A | ストリームパケット | アイソクロナス         |
            |  0x0A | ストリームパケット | アシンクロナス(非同期) |
            +-----------------------------------------------------+

 ブロックライトリクエストは、1394のリンクレベルの確認応答が望まれるが、パケット
デリバリにおいて限定した待ち時間を必要としないときに相応しい。(サービス品質)。
 等時性ストリームパケットは、サービス品質に保証をあたえるが、1394リンクレベルの
確認応答がない。
 最後の方法、非同期ストリームパケットは、完全性のためにのみ言及される。この方法
は、IPユニキャストに使う「べきでない」。なせなら1394リンクレベルの確認応答もサー
ビス品質も提供せず、価値ある資源、チャネル数を消費するからである。
 非同期でも等時性でも使われるIPユニキャスト方法にかかわらず、各パケットの中で使
用されるであろうマキシムデータペイロードを決定することは、ユニキャストIPデータグ
ラムの送信側の責任である。必要な情報が次のものから得られるであろう:
- 1394のバス・マネージャによって維持されるSPEED_MAPは、ローカルシリアルバス上の
任意の2つのノード間の最大送信速度を提供する。バス・マネージャはスピードマップ
を構築するためにバス・トポロジを分析する。即ち、ノード間の最大送信速度は、介在
するノードの能力を反映する、速度はこの場合マクシマムデータペイロードを意味する
(表1を参照)。
 - 1394 ARPのレスポンスので送信側_max_recフィールド、あるいは
 - この標準の関知しない他の方法。
 マクシマムデータペイロードは、すべての介在するノードの送信側、受信側およびPHY
によってインプリメントされた最大のデータペイロードの最小のものである「はずである」
(最後のものは送信側と受信者によって指数化されたSPEED_MAPエントリにおいて暗黙のも
のである)。
 注:SPEED_MAPは、バスリセットの後に続くすべての1394のノードによって送信される自
己-IDパケットから引き出される。IP対応のノードは自己-IDパケットを直接観察する。
 サービス品質がベストエフォート型ユニキャストIPデータグラムは、1394のブロックラ
イトトランザクションのデータペイロード内に含まれている「はずである」。そのトランザ
クションは1394 ARPリスポンスから得られるソース_IDおよび送信側_ユニキャスト_FIFO
に宛てたものである。
 ユニキャストブロックライトリクエストへのリスポンスにおいて確認応答が受信されな
ければ、データペイロードがターゲットによって受け取られたかどうかは確かでない。
 注:ターゲットがもはや機能していないため、確認応答がないかも知れず、ヘッダCRCエ
ラーのためにパケットを受け取らなかったかもしれない。あるいは、パケットを成功裡に
受け取ったが、レスポンスで送信された確認応答が改悪されたかもしれない。
 ベストエフォート型以外にサービス品質を要求するユニキャストIPデータグラムはこの
標準では関知しない。
8. IPブロードキャスト
 ブロードキャストIPデータグラムは4章の仕様に従いカプセル化され、非同期ストリー
ムパケットによって伝送される。1394上のブロードキャストIPに対するサービス品質の供
給はない。IPブロードキャスト用に使用されるチャンネル番号は、BROADCAST_CHANNELレ
ジスタによって指定される。
 すべてのブロードキャストIPデータグラムは、チャンネル番号がBROADCAST_CHANNELレ
ジスタからのチャンネルフィールドと等しい非同期ストリームパケットを使用する「はず
である」。
 1394はバスリセットの後に続く1秒以内に以前に割り付けられたチャンネル番号の使用
を許すが、IP対応ノードは、それらのBROADCAST_CHANNELレジスタ中の有効なビットが0
のときはいつも、非同期ストリームパケットを送信「しないはずである」。有効なビットが
バスリセットによって自動的に0にされるので、IRMがチャンネル番号を割り付けるまで、
1394 ARPあるいはブロードキャストIPの使用を禁止する。

9. IPマルチキャスト
 マルチキャストIPデータグラムは4章の仕様に従いカプセル化され、ストリームパケッ
トによって伝送される。
 非同期ストリームはベストエフォート型IPマルチキャストのために使用される、。ベス
トエフォート型以外のサービス品質についてはこの標準では関知しない。
 デフォルトによって、すべてのベストエフォート型IPマルチキャストは非同期ストリー
ムパケットを使用する「はずである」。そのパケットのチャンネル番号はBROADCAST_CHANNEL
レジスタからのチャンネルフィールドに等しい。特に、224.0.0.1および224.0.0.2に宛て
たデータグラムはこのチャンネル番号を使用する「はずである」。
 下に記述されるように、チャンネル番号が使用に先立って割り付けられ広告される場合、
他のIPマルチキャストグループ・アドレス用のベストエフォート型IPマルチキャストは
異なるチャンネル番号を利用するかもしれない。
 次の2つの条件のうちの1つが合いさえすればに、IP対応のノードはベストエフォート
型IPマルチキャストを送信するかもしれない
―ストリームパケット中のチャンネル番号は、BROADCAST_CHANNELレジスタ中のチャンネル
数フィールドと等しい。また、同じレジスタ中の有効ビットは1ある。あるいは
― 他のチャンネル番号については、IPマルチキャストのあるソースが割り付けて、使用す
るチャンネル番号を広告している。
 この章の残りは、デフォルト以外のチャンネル番号が使用された場合は常に、IPマルチ
キャストソースおよび受信者の両方によって使用されたマルチキャストチャンネルアロケ
ーションプロトコル(MCAP)について記述する。
 MCAPは共同のプロトコルです。即ち参加者は、特別のシリアルバス上ですべてのIP対応
ノードによって使用され、ブロードキャストチャンネル上のメッセージを交換する。
 注:このドキュメントは、1つ以上のIPマルチキャストアドレスによって単一のチャンネ
ル番号(BROADCAST_CHANNELレジスタによって指定されたデフォルトチャンネル番号以外)
の共有使用のための設備と方法を定義するものではない。
9.1 MCAPメッセージフォーマット
 MCAPメッセージは、マルチキャスト・チャンネル所有者によって、あるいは受信者によ
って送られたとしても、GASPパケットのデータ部分として送信され、以下に示すフォーマ
ットを持つ。
メッセージの最初の4オクテットは固定であり、残りは可変長のタブルから成り、その各々
が特別のIPマルチキャストグループに関する情報をコード化する。個々のMCAP(Individual 
MCAP)メッセージは、フラグメントされず、ether_type 0x8861としてストリームパケット
内でカプセル化される「はずである」。
                        1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             長さ              |      予約     |     opcode    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                        メッセージデータ                       +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 図10  MCAPメッセージフォーマット

 MCAPメッセージ中のフィールドの使用法は以下のとおりです:
長さ:このフィールドは、MCAPメッセージ全体のサイズをオクテットで含んでいる「であろ
う」。
opcode:このフィールドは、下表で指定された値のうちの1つをとる「であろう」。       

    opcode    名前             コメント
      +------------------------------------------------------------------+
      |   0   |  広告   | 1つあるいはそれ以上のグループアドレス       |
      |       |           | からそれらが通信しているチャネル番号へ    |
      |       |           | カレントマッピングをブロードキャスト        |
      |       |           | するためマルチキャス所有者によって送られる。 |
      |   1   |  請求   | 指示されたチャネルマッピングをできるだけ   |
      |       |           | 早く広告するためマルチキャスト所有者         |
      |       |           | にリクエストを送る。                  |
      +------------------------------------------------------------------+
メッセージデータ:MCAPメッセージの残りは長さが可変である「はずである」また、下図に
示すフォーマットを備えた、0あるいはそれ以上のグループ・アドレス・ディスクリプタか
らなる「はずである」。
                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      長さ     |     タイプ    |              予約             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    憾スパイア   |   チャンネル  |      速度     |      予約     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            帯域幅                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         group_address                         +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         図11  MCAPグループ・アドレス・ディスクリプタ・フォーマット

 長さ:このフィールドは、MCAPグループアドレスディスクリプタのサイズをオクテットで、
持つ「はずである」。
 タイプ:このフィールドは、グループアドレスディスクリプタを示す1つの値を持ってい
る「はずである」。
 エクスパイア:このフィールドの使用法はopcodeによって変わる。メッセージを求める
ために、エクスパイアフィールドは「無視」される「はずである」。
 さもなくば、広告のために、このフィールドは、タイムスタンプを数秒のうち持つ「は
ずである」。それは、チャンネルによって指定されるチャンネル番号がもはや使用されなく
なる、将来の時間を指定する。
 チャンネル:このフィールドは、メッセージを広告のためにのみ有効である、その場合に
は、0から63までの範囲で、割り付けられたチャンネル番号を指定する「はずである」。他
のすべての値は「予約」である。
 速度:このフィールドは広告メッセージのためにのみ有効である。その場合には、指定さ
れたチャネル用のストリームパケットが送信される速度を指定する「はずである」。表2は、
速度のために使用される符号化を指定する。
 帯域幅:このフィールドは0である「はずである」。サービス品質を指定し、シリアルバ
スの等時性能力を利用するMCAPに、将来の拡張を適応させるために、グループアドレスデ
ィスクリプタの中に割り付けられる。
group_address:この可変長フィールドは、特別のIPマルチキャストグループのIPアドレ
スを指定する「はずである」。group_addressの長さはオクテットで、長さフィールドから
12を引くことにより、グループ・アドレス・ディスクリプタの長さを求める。

9.2 MCAPメッセージドメイン
 MCAPメッセージは、それらが送信されるローカルシリアルバスにのみ有効な情報を伝え
る。MCAPメッセージの受信者は次のような、ローカルバス以外からのMCAPメッセージをす
べて「無視」する「はずである」。たとえば、
送信側のソースIDは、カプセル化MCAPメッセージの先頭にあるGASPヘッダに含まれてい
る。
MCAPメッセージの受信者は、GASPヘッダからのソースIDの最上位10ビットを調べ、それ
らが0x3FFでもなく、受信者NODE_IDSレジスタの最上位10ビットにも等しくなければ、
受信者はメッセージを「無視」する「はすである」。
 MCAPメッセージドメイン内では、チャンネルマッピング所有者は、MCAP広告のGASPヘ
ッダ中のソースIDフィールドによって識別される。所有者は最大の物理IDを持つノード
で、ソース_IDの最下位6ビットである。

9.3 マルチキャスト受理
 マルチキャストデータを受信したいIP対応デバイスは、グループアドレスと
BROADCAST_CHANNELレジスタによって指定されたデフォルト以外のチャンネル番号の間に
存在するチャンネルマッピング(もしあれば)を最初に確認する「はずである」、
そのようなデバイスは、予定したチャンネルマッピングのためのブロードキャストチャン
ネル上のMCAP広告を観察する「はずである」。
 予定したマルチキャスト受信者は次の10秒のインターバルより早く広告を放送すること
をマルチキャスト・チャンネル所有者に要求するためにMCAP懇請リクエストを送信しても
よい。
 MCAP懇請リクエストの創始者は、それらが送信される割合を制限する「はずである」。懇
請リクエストを送ることに続いて、創始者は10秒が経過するまで、別のMCAP懇請リクエ
ストを送ることは「しないはずである」。
 他の場合、マッピングがデフォルト以外のチャンネルのためのグループアドレスに対し
て存在する場合、MCAP広告メッセージが10秒以内に「期待される」。1つかそれ以上のチ
ャネルマッピングを描くMCAP広告メッセージの受信において、予定したマルチキャスト受
信者は、エクスアイア時間まで示されたチャンネル番号上のIPデータグラムを受信しても
よい。
 複数のMCAP広告メッセージが同じグループアドレスを指定したと見られるなら、チャン
ネル番号は、最大の物理的IDを備えた広告メッセージから得られる「はずである」、その
物理IDはGASPヘッダからのソース_IDの最下位6ビットから得られる「はずである」。
 10秒のうちに特別なグループアドレスのためにMCAP広告メッセージを受信しなければ、
デフォルト以外のチャネルに対しアクティブであるマルチキャストソースはない。マルチ
キャストデータがあってもなくてもデフォルトチャンネル上で送信されている。
 一旦マルチキャスト受信者が希望のグループ・アドレスの広告を見れば、デフォルトブ
ロードキャストチャンネル上でも、示されたチャンネル番号上でもマルチキャストを受信
しても「よい」、しかし、使用中のチャンネル番号のエクスパイア時間をリフレッシュする
ために同じグループ・アドレスのMCAP広告のためのデフォルトブロードキャストチャンネ
ルをモニタし続ける「はずである」。

9.4 マルチキャスト送信
 デフォルト以外のチャンネルの上のマルチキャストデータを送信したい、IP対応デバイ
スは、別のマルチキャストソースが既にグループアドレスにチャンネル番号を割り当てた
かどうか最初に確認する。予定したマルチキャストソースは、1つかそれ以上のグループ・
アドレス・ディスクリプタを備えたMCAP懇請リクエストを送信するかもしれない。
  懇請リクエストが送信されたか否か、予定したマルチキャストソースはMCAP広告のた
めのブロードキャストチャンネルをモニタする「はずである」。チャネルマッピングがグル
ープアドレスのために存在するなら、MCAP広告は、10秒以内に受信されなければ「ならな
い」。この場合、予定したマルチキャストソースは、示されたチャンネル番号上のIPデー
タグラムの送信を始めるかもしれないし、それらのエクスパイア時間までそうし続けるか
もしれない。マルチキャストソースは、使用中でチャンネル番号のエクスパイア時間をリ
フレッシュするためにMCAP広告をモニタする「はずである」。
 他のマルチキャストソースがグループアドレス用のチャンネルマッピングを確立してい
ない場合、予定したマルチキャストソースはIEEE P1394aに記述された手続きに従い等時
性の資源マネージャのCHANNELS_AVAILABLEレジスタからチャンネル番号を割り付けようと
するかもしれない。チャンネル番号割付けが成功する場合、マルチキャストソースは、で
きるだけ早く新しいチャンネルマッピングを広告する「はずである」。一旦新しく割り付け
られたチャンネル番号の初期広告の後100msが経過すれば、マルチキャストソースは広告
されたチャンネル番号を使用して、IPデータグラムを送信するかもしれない。送信側がマ
ルチキャストアドレス用のノン・デフォルトチャンネルマッピングを指定する広告を見る
(あるいは送信する)まで、マルチキャストIPデータグラムはデフォルト・チャンネル上で
送信されるかもしれない。これは、デフォルト・チャンネルから明白に割り付けられたチ
ャンネルへのマルチキャストのスムースな移転を可能にする。
 一度マルチキャストソースがチャンネルマッピングを広告したならば、以下の条件を満
たすまで、チャンネルマッピングのMCAP広告を送信し続ける「はずである」、a)所有権
を他のマルチキャストソースに移譲する。b)移譲しないでチャネルマッピングがエクスパ
イアするのを認めるc)オーバーラップしたチャネルマッピングの場合、チャンネルマッピ
ングのコントロールを他のマルチキャストソースに移す。

9.5 チャンネルマッピング広告
 各マルチキャストソースは、デフォルトマルチキャストチャンネル番号と異なるチャン
ネル番号を割り付けるために、すべてのIPマルチキャストグループアドレスの広告を周期
的に放送する「はずである」。広告は、1つあるいはそれ以上のグループアドレスディスク
リプタを含む0のopcodeを持つ単一のMCAPメッセージで成り立つ「はずである」
(BROADCAST_CHANNELレジスタによって指定されたもの以外のチャンネル番号が割り当て
られた各グループアドレスのためのもの)。
 各グループ・アドレス・ディスクリプタ内では、group_addressとチャンネルフィールド
がIPマルチキャストグループ・アドレスをシリアルバスチャンネル番号に結びつける。ス
ピードフィールドは、送信側のだれもがIPマルチキャストグループの中でデータ送信を許
される最大の1394の速度を指定する。エクスパイアフィールドは、チャネルマッピングが
それ以上有効ではない現在の時間あるいは将来の時間を指定する。チャンネル所有者が所
有権(9.7に記述されるように)を放棄するつもりの時以外は、エクスパイア時間は、広告が
送信された時から測った将来の時間の中で最低でも60秒である「はずである」。
 最新の広告が送信されてから、チャンネルマッピングの所有者が続く広告の送信を始め
るまでに10秒が経過するに過ぎない「はずである」。チャンネルマッピングの所有者は、
リクエストの受信後、懇請に応じてできるだけ早くMCAP広告を送信する「べきである」。

9.6 オーバーラップチャンネルマッピング
 2つの意図したマルチキャストソースが同じIPマルチキャストグループに送信しようと
し、チャンネルマッピングがグループ・アドレスに対し存在しない場合、双方がチャンネ
ル番号を割り付け、また、双方がチャンネルマッピングを広告するチャンスがある。これ
らのチャンネルマッピングはオーバーラップする。つまり、同じグループ・アドレスはノ
ンゼロエクスパイア時間を持つMCAP広告において1つ以上のチャンネル番号にマッピング
される。
 マルチキャスト・チャンネル所有者は、オーバーラップしたチャンネルマッピングを検
出するために、MCAP広告をモニタする「はずである」。エクスパイアフィールドが60以下
の値を持つMCAP広告は、オーバーラップしたチャンネル検出の目的のため無視される「は
ずである」。オーバーラップチャンネルマッピングが検出されたとき、最大物理ID(GASP
ヘッダからのソースIDの最下位6ビットによって決定するので)を持つ所有者はどんな行
動を取ることも「要求されない」。より小さな物理IDを持った所有者によって広告された
チャンネル番号は無効である。それらの所有者は、無効のチャンネル番号を使用するIPデ
ータグラムおよびMCAP広告の双方の送信を中止する「はずである」。これらのチャンネル
マッピングがエクスパイアすると直ちに、それらの所有者は、9.8に示すようなすべての未
使用のチャンネル番号の割り当てを解除する「はずである」。
 オーバーラップチャンネルマッピングを検知するMCAP広告の受信者は、より小さな物理
IDを持つマルチキャストチャネル所有者からの広告を無視するで「はずである」。また無効
のチャンネル番号を使用するIPデータグラムを送信しない「はずである」。たとえオーバ
ーラップの結果として他のものが「無視」される「はずであろう」とも、単一のMCAP広告
中のいくつかのチャンネルマッピングが有効であることは可能である。

9.7 チャンネル所有権の移譲
 チャンネルマッピングの所有者は、特別のチャンネル上のマルチキャスト送信を中止し
てもよい、その場合にはそれはチャンネルマッピングを無効にし、ある場合にはチャンネ
ル番号の割り付けを解除する「べきである」。他のマルチキャストソースが同じチャンネル
マッピングを使用しているかもしれないので、チャンネル所有権を移譲するために秩序だ
ったプロセスが定義される。
 マッピングをリリースしたい既存のチャンネルマッピング所有者は、マッピングおよび
その関連するチャンネルの予期されるリリースの前に残りの時間を測定するためにタイマ
を始動させる。タイマが0をカウントするまでに、所有者は、影響を受けたチャンネルに
MCAP広告を送信し続ける「はずである」、しかし、チャンネルが割り当てを解除されること
になるまで残りの時間を反映するために各広告中のエクスパイアを調節する。タイマが0
に達するまでに、所有者がMCAP広告を送信することができない場合、それは、バスリセッ
トを始める。そうでなければ、マッピングをリリースするつもりの所有者によって送信さ
れる一連のエクスパイア時間は、各々の後に継ぐ広告を減少させる。他のマルチキャスト
ソースが同じチャンネルマッピングを使用しており、エクスパイアが60秒かそれ以下と見
たときは、それらは、チャネルマッピングを維持する60秒かそれ以上のリフレッシュされ
たエクスパイア時間を持つチャンネルマッピングのためにMCAP広告の送信を始めるで「あ
ろう」。チャンネルマッピングの所有権を要求しようとする多数のソース間に生じるすべて
の競合は、9.8に記述されるように解決する。オリジナルの所有者がそれ自身のタイマがエ
クスパイアする前に放棄されるであろうチャンネルのMCAP広告を見れば、それは、チャン
ネル番号の割り付けを解除する「はずである」。
 他方、所有者のタイマが別のノードによるMCAP広告をみることなしにエクスパイアする
なら、チャンネル番号の所有者は、9.8に記述されるようにチャネルの割り付けを後で解除
する。チャンネルマッピングの予定した所有者がエクスパイアフィールドが0であるMCAP
広告を見たとき、前の所有者からのチャンネルの秩序だった移譲は失敗である。意図した
所有者は、エクスパイアチャンネル番号上の受信及び送信を止めるか、9.4で指定するよう
に異なるチャンネル番号(s)を割り付ける「はずである」。

9.8 冗長チャンネルマッピング
 チャンネルマッピングの所有権が1つのマルチキャストソースから別のソースに移譲さ
れるとき、1つ以上のデバイスが所有権を要求することが可能である。このことは冗長MCAP
広告が異なるソースによって送信され、その各々は同じマルチキャスト・グループ・アド
レスおよびチャンネルを指定しているという結果になる。9.6に似た手続きは、チャンネル
所有権の競合を解決する「はずである」。
 マルチキャスト・チャンネル所有者は、冗長チャンネルマッピングを検出するためにMCAP
広告をモニタする。エクスパイアフィールドが60以下の値を持つMCAP広告は冗長チャン
ネル検出の目的のため無視される「はずである」。冗長チャンネルマッピングが検出された
時、最大物理ID(GASPヘッダからのソース_IDの最下位6ビットによって決定されるように)
を持った所有者は、どんな行動をとることも「要求されない」。より小さな物理IDを持つ
所有者は、冗長チャネル番号のためのMCAP広告を中止する「はずである」が、チャンネル
番号の割り付けを解除「しないはずである」。

9.9 エクスパイアチャンネルマッピング
 最新のMCAP広告が出されてからエクスパイア時間が経過した場合、チャンネルマッピン
グはエクスパイアする。このとき、マルチキャスト受信者は、エクスパイアチャネル番号
での受信を中止する「はずである」。さらにこのとき、、チャンネルマッピングは、0にク
リアされたエクスパイアを持つMCAP広告を送信する「はずである」、またチャンネルマッ
ピングのエクスパイアから30秒が経過するまで、そのような広告を送信し続ける「はずで
ある」。
 一旦この付加的な30秒期間が経過した後は、チャンネルマッピングの所有者は、チャン
ネル番号の割り付けを解除し、かつ等時性資源マネージャーのCHANNELS_AVAILABLEレジス
タの中でそれらの有効性を示す「はずである」。
 IP対応デバイスはエクスパイアフィールドが0であるMCAP広告を見たなら、最新のその
ような広告が出されてから30秒経過するまではどんなチャンネル番号も割付けしようと
「しないはずである」。

9.10 バスリセット
 バスリセットは、マルチキャストチャンネルマッピングをすべて無効にする「はずであ
る」且つ、すべてのマルチキャスト受信者および送信者にすべてのMCAP広告インタバルタ
イマを0にさせる「はずである」。
 マルチキャストチャンネルマッピングの前所有者は、等時性の資源マネージャの
CHANNELS_AVAILABLEレジスタからのチャンネル番号を再び割り付けそしてチャンネルが割
り付けられると直ちにMCAP広告のブロードキャストが再開するかもしれない。チャンネル
再割り当てが試みられる場合、前所有者は、バスリセットに先立って割り付けられたと同
じチャンネル番号を使用し「なければならず」、同じチャンネル番号が再使用される限りバ
スリセットの完了後直ちに再配分を始めてもよい。前所有者が異なるチャンネル番号を割
り付けることを選んだなら、それは新しいチャンネル番号を割り付けることを試みる前に
バスリセットの完了から最低1秒が経過するまで待つ「はずである」。
 デフォルトチャネル以外のマルチキャスの予定したあるいは前の受信者や送信者は、バ
スリセットの完了から少なくとも10秒が経過するまで、MCAP請求リクエストを送信「しな
いはずである」。デフォルトチャンネル以外のものマルチキャストデータは、MCAP広告がIP
マルチキャストグループ・アドレスのために観察されるか送信されるまで、受信あるいは
送信され「ないはずである」。
 バスリセットに先立ったIPマルチキャストグループアドレス用のチャンネルマッピング
を所有しなかったデフォルト以外のチャンネルの上のマルチキャストの予定した送信者あ
るいは前送信者は、バス・リセットの完了から少なくと見10秒経過するまで等時性資源マ
ネージャのCHANNELS_AVAILABLEレジスタからのチャンネル番号を割り付けようとは「しな
いはずである」。この10秒の遅延の後に続いて、マルチキャストの予定した送信者あるい
は前送信者は、チャンネル番号を割り付けて、かつチャンネルマッピングを広告するため
に9.4で指定された手続きに従うかもしれない。
10. IANAについて
 このドキュメントは、IANAによる新しい名前スペース(レジストリ)の生成および管理を
必要とする。そのようなレジストリの必要は、ISO/IEC 13213:1994,CSRアーキテクチャに
准じたバス規格によって唯一識別されるプロトコルインタフェースの方法から発生する。
これは、6章でより詳細に説明される。本質的には、全体的にユニークな48ビット数が、
プロトコルインタフェースを指定するドキュメントを識別する「はずである」ということ
である。48ビット数は0x00 005E(レジストレーションIDもしくはRID、IEEEレジストレ
ーションオーソリティによってIANAに与えらた)とIANAによって管理される2番目の24
ビット数との連結である。
 IEEE RA は、可能な値の範囲内での使用可能な数の量を最大にするために選ばれた2番
目の24ビット数の管理政策を「推薦する」。特に、IEEE RA は、割り当てスキームは構造
に数を当てはめるのではない(例えば数内でのバージョン・フィールドの割り付け)こと
を「薦める」、なぜならこれは範囲の大部分を浪費する傾向があるためである。
 新しい名前スペースは「CSRプロトコル識別子」である。0値および0xFF FFFFは予約さ
れ、IANAによって割り当てられ「ないはずである」。1値がこのドキュメントに割り当てら
れる。残る数は、IANAによって管理され、IESG規格のトラック文書となる規格案を識別す
るのに必要であるとして割り当てられる。
 IANAによって選ばれた割り当て方法に関係なく、すべての割り当てられたバージョンナ
ンバーのレジストリは1つあるいはそれ以上のインタネットサイトによって維持され「な
ければならず」また、RIDとバージョンナンバのコンビネーションで識別される適切な規格
を明白に識別しなければならない。
11. セキュリティについて
 このドキュメントは、IPv4データグラムの伝送のために、無保証のリンク層、シリアル
バスの使用を指定する。シリアルバスはサービス攻撃を拒否するのが苦手である。即ち、
デバイスがデータを盗むあるいは偽造された独自性を示すことも出来る。IPv4 用のシリア
ルバスを利用する作成者はアプリケーションあるいは他のレイヤーの中で適切な対抗手段
を考えなければ「ならない」
12. 謝意
 このドキュメントは、IP/1394ワーキンググループの努力を表している。著者は、すべて
の活動的な参加者によってなされた貢献を、技術的な内容を提案した反射鏡の上でもある
いは直接の会合ででも、知りたいと願っている。

13. 参照
 承認された規格に置きかえられる時まで、このドキュメントの出版にあたり開発中の標
準を参考にするときは、最新の規格案を使うはずである。
[1] IEEE Std 1394-1995、高性能シリアルバスのための規格
[2] ISO/IEC 13213:1994、マイクロコンピュータ・バスのための,コントロール・ステータ
ス・レジスタ(CSR)アーキテクチャ
[3] IEEEプロジェクトP1394a、高性能シリアルバス(サプリメント)のための規格案
[4] IEEEプロジェクトP1394b、高性能シリアルバス(サプリメント)のための規格案
[5] ポストL、J。「インターネット・プロトコルDarpaインターネットプログラム・プロト     
コル・スペック。」RFC 791、1981年9月。
[6] Bradner、S、「要求レベルを示すRFCの中の使用のためのキーワード。」RFC 2119、1997
年3月。

14. 編者のアドレス
Peter Johansson
Congruent Software Inc.
98 Colorado Avenue
Berkeley, CA  94602 
電話:(510)527-3926
ファックス:(510)527-3856
EMail:pjohansson@aol.com

15. 全著作権文
 著作権(C)、Internet Society1999)。著作権保有。

 このドキュメントおよびその翻訳はコピーされ他のものに供給されるかもしれず、コメ
ントをしたり、他の方法で説明したり、実行を手助けしたりの派生的仕事が用意され、ど
んな種類の制限もなく全部または一部がコピーされ、出版され、配布されるかもしれない。、
もし上記の著作権通知およびこのパラグラフがすべてのそのようなコピーおよび派生的作
業を含んでいる条件であるなら。しかしながら、このドキュメントそれ自身はどんな方法、
たとえば著作権通知の抹消、あるいはインターネット学会あるいは他のインターネット組
織への参照など、でも修正されないであろう。ただし以下の場合は例外とする。インター
ネット規格を開発する目的のため必要とされるとき、その場合には、インターネット規格
プロセスで定義された著作権のための手続きが後に続かなければならない、あるいは英語
以外の言語にそれを翻訳することを求められたときである。
 上記で与えられた、制限付きの許可は永続し、インターネット学会あるいはその後継者
もしくは受託人によって無効にされことはないであろう。
 ここに含まれているこのドキュメントおよび情報は、「AS IS」ベースで提供され、また
「インタネットソサイエティおよびインタネットエンジニアリングタスク集団は、すべて
の保証を拒否する。すなわち、表現されていても暗黙でも、ここでの情報の使用が特別の
目的のための商業性もしくは適合性についてのいかなる権利もしくはいかなる暗黙の保障
を犯すものではないあらゆる保証を含んでいるがそれに限らない保証である。

お知らせ
 RFC編集機能のための資金提供が、インターネット学会によって現在なされています。


1

2





 Copyright(C) 2001 by Etuko Ooishi

メールの宛先。
 一つ上へ
目 次 へ