ネットワーク・ワーキンググループ P.Johansson Request for Comments: 2734 Congruentソフトウェア社 カテゴリー : 標準追跡 1999年12月 IPv4 over IEEE 1394 IEEE 1394の上のIPv4 このメモの状態 このドキュメントはインターネットを指定します、標準は、インターネットコミュニティーのためのプロトコルを追跡します、また改良のための議論および提案を要求します。 このプロトコルの標準化状態およびステータスに関しては「インターネットの公式プロトコル規格(Official Protocol Standards)」(STD 1)の現在の版を参照してください。 このメモの分配は無制限です。 著作権のある通知 著作権(C)、インターネット社会(1999)。 著作権保有。 アブストラクト このドキュメントは、インターネット・プロトコル・バージョン4(IPv4)データグラムの輸送のためにIEEE Std 1394-1995、高機能シリアルバス(High Performance Serial Bus)(またその補足)のための基準を使用する方法を指定します; それはその目的のために必要な方法、データ構造およびコードを定義します。 これらはパケット・フォーマットおよびデータグラム用のカプセル化方法だけでなくアドレス・リゾリューション・プロトコルも(1394のARP)含んでいます、またマルチキャスト・チャンネル割付けプロトコル(MCAP)。 1394のARPおよびMCAPの両方はシリアルバスに特有です; IPマルチキャストグループによって使用された時、後のものは、シリアルバス資源の管理を許します。 目次 1. はじめに。.....................................................2 2.定義および記法。.........................................4 2.1 適合。..................................................4 2.2 用語辞典。.....................................................4 2.3 略語。................................................6 2.4 数値価値。...............................................6 3. IP対応のノード(IP-CAPABLE NODES)。...................................6 4.LINK ENCAPSULATION AND FRAGMENTATION。............................7 4.1、グローバルな非同期流れパケット(GASP)..............8 4.2カプセル化ヘッダーをフォーマットする。...................................9 4.3は破片リアセンブリをリンクします。...................................11 5.連続するバス・アドレス・レゾルーション・プロトコル(1394のARP)...............11 6.配置ROM。...............................................14 6.1 Unit_Spec_IDエントリー。..........................................14 6.2 Unit_SW_Versionエントリー。......................................14 6.3 本文のディスクリプタ。.........................................15 7. IPユニキャスト(IP UNICAST)。...............................................16 8.IP放送(IP BROADCAST)。....................................................17 9.IPマルチキャスト。....................................................17 9.1 MCAPメッセージフォーマット。.........................................18 9.2 MCAPメッセージ領域。.........................................21 9.3マルチキャスト受理。...........................................21 9.4マルチキャスト送信。........................................ チャンネル写像...........................23 9.6 の..22 9.5 広告、オーバーラップしたチャンネル写像。..............................23 9.7 はチャンネル所有権に移ります。..............................24 9.8 、余分のチャンネル写像。.................................25 9.9 は終了しました、チャンネル写像。...................................25 9.10 バス・リセット .................................................26 10.IANA考察(IANA CONSIDERATIONS) ........................................26 11.セキュリティ考察 .......................................27 12.確認応答 ...............................................27 13.参照 .....................................................28 14.エディターアドレス ...............................................28 15.全著作権表示 ......................................29 1. はじめに このドキュメントは、インターネット・プロトコル・バージョン4(IPv4)データグラムの輸送のためにIEEE Std 1394-1995、高機能シリアルバス(High Performance Serial Bus)(またその補足)のための基準を使用する方法を指定します。 それはその目的のために必要な方法、データ構造およびコードを定義し、アドレス・リゾリューション・プロトコル(1394のARP)およびマルチキャスト・チャンネル割付けプロトコル(MCAP)(それらの両方はシリアルバスに特有である)用方法をさらに定義します。 IEEEの基準および補足のグループ、草案、あるいは承認した、IEEE Std 1394-1995に関連づけられた、今後1394あるいはシリアルバスとしてどちらかを参照されます。 1394はCSRアーキテクチャー、ISO/IEC 13213:1994に一致するinterconnect(バス)です。 シリアルバスは、現在、100〜400のMbpsで、及ぶ速度の共有された物理的なメディア上のノード間のコミュニケーションを許します。 消費者電子出願(ディジタルVCR、ステレオ・システム、テレビおよびカムコーダーのような)、および従来のデスクトップ・コンピュータ適用(例えば多量記憶装置、プリンタおよびテープ)の両方は、1394を採用しました。 シリアルバスは、電子消費者およびコンピューター領域の両方へのその関連において独特で、両方のタイプの装置を組み合わせる家か小さなオフィス・ネットワークの基礎を形成するEXPECTEDです。 CSRアーキテクチャーは、64ビットの固定アドレシング・スキームとしてシリアルバスがインプリメントする、メモリをマップされたアドレス空間について記述します。 アドレス空間内では、10ビットがバスID(最高1,023台のバスまでの)に分配されます、6はノードに分配されます、残りの48ビット(オフセット)が記述している一方、物理的なID(1台のバス当たり63まで)1つの、256テラバイトのノード・アドレス空間につき。 CSRアーキテクチャーは協定によって、異なる行動の特性を備えた2つの地方へノードのアドレス空間を分割します。 下部、まで、しかし0xFFFF F000 0000を含んでいないこと、メモリとして作用するEXPECTEDである、読まれた、また処理を書きます。 上部はむしろ従来のIOスペースに似ています:このエリアの処理を読み書く、通常副作用を持っています。 FIFO振る舞いを行っているコントロールとステータスの登録(CSR)は、この地域の中で慣習的にインプリメントされます。 64ビットのアドレス内では、16ビットのノードID(バスIDおよび物理的なID)がネットワーク・ハードウェア・アドレスと類似しています―――しかし、1394のノードIDは毎時間再委託に可変で従属します、1つ以上のノードは増されるか、あるいはバスから取り除かれます。 注:16ビットのノードIDはバスIDを含んでいますが、現在、別々に数えあげられた連続物バス(Serial Buses)を接続する標準の方法はありません。 連続するバスブリッジへのシリアルバスのための基準の活発な開発は、IEEE P1394.1ワーキンググループにおいて進行中です。 もしある将来の標準によって拡張されなかったならば、このドキュメントによって指定された1394のプロトコル上のIPv4はブリッジを横切って正確に作動しないかもしれません。 1394のリンク層はパケット・デリバリーサービスに頑固な(認められた)パケットおよび未確認パケットを供給します。 サービスの2レベルは利用可能です:「非同期」パケットは上に送られます、1つの、最良-「等時性の」パケットが弾んだ潜在で伝えられることを保証されている一方、努力基礎。 頑固なパケットは常に非同期です。しかし、未確認パケットは非同期かもしれないか、等時性かもしれません。 データ・ペイロードはインプリメンテーションに応じて変わり、送信速度(S100と命名される100のMbpsでは、S400では、それが2048オクテットである一方、最大の非同期データ・ペイロードが512オクテットです)によって決定された最大まで1オクテットから変動してもよい。 注:IEEE P1394bにおいて進行中のエクステンションは、800,1600のおよび3200 Mbpsの追加の速度を熟考します。 2. 定義および記法 2.1 適合 いつ、このドキュメントの中で使用された、キーワード「MAY」、「OPTIONAL」、「RECOMMENDED」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、および「SHOULD NOT」必要条件とoptionalityのレベルを差別化する、また解釈されるためにある、として、RFC 2119に記述されました。 いくつかの追加のキーワードは以下のように使用されます: EXPECTED:キーワードは、いつも、この標準によって仮定された設計モデルにハードウェアかソフトウェアの振る舞いについて記述しました。 他のハードウェアおよびソフトウェアは、モデルがさらにインプリメントされるかもしれないように設計します。 IGNORED:値が受取人によってチェックされないビット、オクテット、quadletsあるいはフィールドについて記述するキーワード。 RESERVED:キーワードはいつもオブジェクト(ビット、オクテット、quadletsおよびフィールド)あるいはこれらのオブジェクトに割り当てられたコード価値のいずれかについて記述しました; オブジェクトあるいはコード価値は将来の標準化のために無効にされます。 RESERVEDオブジェクトは定義された意味およびSHALLを持っていません、その発明者によってzeroedされるか、将来の標準の開発に際して、そのような標準によって指定された値に着手する。 RESERVEDオブジェクトSHALL NOTの受取人、その値をチェックします。 コード価値がこの標準のSHALLによって定義されるオブジェクトの受取人、その値をチェックし、RESERVEDを拒絶する、値をコード化します。 2.2 用語辞典 次の用語はこの標準の中で使用されます: アドレス・リゾリューション・プロトコル:依頼人がノードのIPアドレスからのIPノードのハードウェア(1394)アドレスを決定するべき方法。 バスID:多数の相互に連絡したバスのグループ内の特別のバスをユニークに識別する、10ビットの数。 バスIDはノードの16ビットのノードIDの最も重要な部分です。 値0x3FFはローカルバスを指定します; ノードSHALL、リクエストに応答する、リクエスト中のバスIDが0x3FFあるいはノードに明示的に割り当てられたバスIDのいずれかである場合、その6ビットの物理的なIDへアドレスしました。 カプセル化ヘッダー:1394以上送信されたIPデータにすべて先行する構造。 さらにリンク破片を参照してください。 IPデータグラム:STD、RFC 791 5によって指定されたフォーマットに一致するインターネットメッセージ。 リンク破片:単一の1394のパケット内に送信された、IPデータグラムの部分。 1394のパケットのデータ・ペイロードはカプセル化ヘッダーおよびその関連するリンク破片の両方を含んでいます。 リンク分割のないデータグラムを送信することは可能です。 マルチキャスト・チャンネル割付けプロトコル:マルチキャスト・データグラムがデフォルト放送チャンネル以外のものの上で送信される場合に、シリアルバス資源(チャンネル)のそれらの使用を調整する、マルチキャスト・グループ用の方法。 マルチキャスト・チャンネル所有者:1つ以上のマルチキャスト・アドレスにチャンネルを分配しており、これらのチャンネル写像(s)を通信するためにMCAP広告を送信するマルチキャスト出所、IPマルチキャストグループの他の参加者。 1つを越える出所が同じチャンネル番号のMCAP広告を送信する場合、最大の物理的なIDを備えた出所は所有者です。 ノードID:多数の相互に連絡したバスのグループ内のシリアルバスノードをユニークに識別する、16ビットの数。 最も著しい10ビットはバスIDです。また、最も著しくない6ビットは物理的なIDです。 ノード、ユニークなID:世界的に製造されたすべてのシリアルバスノード中にユニークにノードを識別する、64ビットの数; さらにEUI-64(拡張ユニークな確認者(Extended Unique Identifier)、64ビット)として知られていました。 オクテット:データの8ビット。 パケット:1394の主要なパケットのうちのいかなるもの; これらは読み取り、書き込みあるいはロック・リクエスト(またそれらのレスポンス)か、流れデータかもしれません。 用語「パケット」はシリアルバス予備選挙パケットと1394のARPのリクエスト/レスポンス、IPデータグラムあるいはMCAP広告/懇請を区別するために一貫して使用されます。 物理的なID:特別のバスで、この6ビットの数は、自己同一視プロセスの間にダイナミックに割り当てられ、ユニークにそのバス上のノードを識別します。 quadlet:4オクテットあるいはデータの32ビット。 流れパケット:ブロック・データ・ペイロードを含んでいる0x0Aの処理コードを備えた1394の主要なパケット。 ストリーム・パケットは使用された1394の仲裁のタイプによって非同期かもしれないしあるいは等時性かもしれません。 2.3 略語 下記はこの標準の中で使用される略語です: 1394のARPアドレス・リゾリューション・プロトコル(1394に特有)CSRコントロール(CSR Control)、およびステータスは、周期的な余剰チェックサムEUI-64が拡張したCRCを登録します、ユニークな確認者(Unique Identifier)、および64ビットのGASP、グローバルな非同期流れパケットIPインターネットプロトコル(このドキュメント、IPv4内の)MCAPマルチキャスト(MCAP Multicast)チャンネル、割付けプロトコル 2.4 数値価値 10進および16進法の数はこの標準内に使用されます。 編集の協定によって、10進番号は量または計算を表わすために最も頻繁に使用されます。 アドレスは、16進法の数(表わされた値が10進のフォーマットより16進法のフォーマットにおいてより明白な、根本的な構造を持っている場合、それらはさらに使用される)によって一様に表わされます。 10進の数はアラビア数字によって、あるいはそれらの英語の名前によって表わされます。 16進法の数は0xによって前に付けられ、0の(9とA)Fを課された性格からの数字によって表わされます。 読みやすさのために、16進法番号は、スペースによって分離された4つの数字のグループへ分離されます。 例えば、42および0x2Aの両方は同じ数値の値を表わします。 3. IP対応ノード すべてのシリアルバス装置は、1394のARPのリクエスト/レスポンスあるいはIPデータグラムの受理および送信ができるとは限りません。 IP-有能なノードSHALL、次の最小の必要条件を満たす: - それ、ISO/IEC 13213:1994によって指定された、一般フォーマット中のSHALL道具配置ROM、およびSHALLは、IEEE P1394aおよびこの標準によって指定されたユニットディレクトリーによって指定されたバス情報ブロックをインプリメントします; - そのバス情報ブロックSHALLの中のmax_recフィールド、少なくとも8である; これは、ブロック書き込みが要求すると受け入れる能力、および512オクテットのデータ・ペイロードを備えた非同期流れパケットを示します。 同じ能力、SHALL、さらに読み込み要求に当てはまる; すなわち、ノードSHALL、512オクテットのデータ・ペイロードを備えたブロック・レスポンス・パケットを送信することができること - それ、SHALL、IEEE P1394aによって指定されるように有能な等時性の資源マネージャーである; - それ、SHALL支援、IEEE P1394aによって指定されるような非同期流れの受理、および送信の両方; そして 4. リンク・カプセル化および分割 IPデータグラム(放送、ユニキャストあるいはマルチキャスト)、1394のARPのリクエスト/レスポンス、および1394のブロックによって転送されるMCAP広告/懇請はすべて、リクエストあるいは流れパケットSHALLを書きます、パケットのデータ・ペイロード内にカプセルに入れられます。 データ・ペイロードの最大のサイズは、オクテットで、パケットが送信される速度によって抑制されます。 テーブル1-最大のデータ・ペイロード(オクテット) 速度 非同期、等時性の +------------------------------------+ | S100 | 512 | 1024 | | S200 | 1024 | 2048 | | S400 | 2048 | 4096 | | S800 | 4096 | 8192 | | S1600 | 8192 | 16384 | | S3200 | 16384 | 32768 | +------------------------------------+ 注:S800の速度での最大のデータ・ペイロード、またより速くIEEE P1394bによって標準化の結果縮小されるかもしれない(しかし増加させられないだろう)。 非同期リクエストおよびレスポンス用の最大のデータ・ペイロードは、さらに、送るかあるいは受信ノード(s)の能力によって制限されるかもしれません; これは、バス情報ブロックあるいは1394のARPのレスポンスのいずれかでmax_recによって指定されます。 これらの理由のどちらかについては、IP対応のノード間で伝達可能な最大のデータ・ペイロードがこのドキュメントによって指定されたデフォルト1500オクテットの最大の送信ユニット未満(MTU)かもしれません。 これは、カプセル化フォーマットが1394のリンクレベルの分割およびIPデータグラムのリアセンブリをさらに許すことを必要とします。 注:IP対応のノードは、デフォルトより大きなMTUサイズで作動するかもしれません。しかし、より大きなMTUが形成される手段はこのドキュメントの範囲外です。 4.1 グローバルな非同期流れパケット(GASP)フォーマット 1394のARPのリクエストおよびレスポンスと同様にいくつかのIPデータグラムも非同期流れパケットによって輸送されるかもしれません。 非同期流れパケットが使用される場合、それらのフォーマット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| チャンネル| 0x0A | sy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | header_CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source_ID | specifier_ID_hi | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |specifier_ID_lo| version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +--- データ ---+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data_CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図1-GASPフォーマット source_ID フィールドSHALL、送るノードおよびSHALLのノードIDを指定する、送信器のNODE_IDS登録の最も著しい16ビットと等しい。 specifier_ID_hiとspecifier_ID_loのフィールド、ともにSHALL、005値0x00 E(IEEE登録権威(IEEE Registration Authority)(RA)によってIANAに割り当てられた24ビットの組織的にユニークな確認者(OUI))を含んでいます。 バージョン・フィールドSHALL、1です。 注:GASPフォーマットが非同期流れパケット・フォーマット中のデータ・ペイロードの最初の2のquadletsを利用するので、テーブル1に引用された最大のペイロードは8オクテット有効に縮小されます。 続く節では、データ・ペイロードの第1のquadletへの言及が、IPデータグラムあるいは1394のARPのリクエストには使用可能な第1 quadletあるいはレスポンスを意味します。 GASPフォーマットが使用される場合、これはパケット用のデータ・ペイロードの第3のquadletです。 4.2 カプセル化ヘッダー 1394以上輸送されたIPデータグラムはすべて、下に絵入りのフォーマットのうちの1つを備えたカプセル化ヘッダーによって前に付けられます。 IPデータグラム全体が単一の1394のパケット内に送信されるかもしれない場合、それは破砕していません、そしてデータ・ペイロードSHALLの第1の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| 予約 | ether_type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図2-Unfragmentedカプセル化ヘッダー・フォーマット lfフィールドSHALL、0です。 ether_typeフィールドSHALL、次のテーブルによって指定されるように続くデータグラムの性質を示します。 ether_type Datagram +-------------------------+ | 0x0800 | IPv4 | | 0x0806 | 1394 ARP | | 0x8861 | MCAP | +-------------------------+ 注:ether_typeの異なる値によって識別された他のネットワーク・プロトコルは、ここに定義されたカプセル化フォーマットを使用するかもしれません。しかし、そのような使用はこのドキュメントの範囲の外部であります。 データグラムの長さが送信器およびすべての受取人によって支援された最大のデータ・ペイロードを超過する時に、データグラムSHALL、リンク破片へ壊れている; 第1のリンク破片SHALLのためのデータ・ペイロードの最初の2のquadletsは、下に示されたフォーマットに一致します。 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 | 予約 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図3-第1の破片カプセル化ヘッダー・フォーマット 第2および後のリンク破片(最後以下の)SHALLは下に示されたフォーマットに一致します。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lf|rsv| datagram_size | rsv | fragment_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dgl | 予約 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図4-後の破片(s)カプセル化ヘッダー・フォーマット フィールドの定義および使用法は以下のとおりです: lfフィールドSHALL、次のテーブルによってコード化されるようにIPデータグラム内のリンク破片の相対的な位置を指定します。 lf 位置 +------------------------+ | 0 | Unfragmented | | 1 | 先頭 | | 2 | 最後 | | 3 | Interior | +------------------------+ datagram_size:IPデータグラム全体のコード化されたサイズ。 datagram_size SHALLの値、IPデータグラムおよびSHALLのすべてのリンク破片に対して同じである、データグラムのIPヘッダー(STD 5(RFC 791)を参照)中の長さの合計の値未満で1です。 ether_type:このフィールドは第1のリンク破片およびSHALLの中にのみあります、0x0800(それはIPv4データグラムを示す)の値を持っています。 fragment_offset:このフィールドは第2の中にのみあります。また、後のリンク破片およびSHALLはIPデータグラムの始めからの破片に、オクテットで、オフセットを指定します。 データグラム(IPヘッダーのスタート)の第1のオクテットは、0のオフセットを持っています; 第1のリンク破片中のfragment_offsetの暗黙の値は0です。 dgl:dgl(データグラム・ラベル)SHALLの値、IPデータグラムのすべてのリンク破片に対して同じです。 連続で破片にされたデータグラム用の送信器SHALLインクリメントdgl; 0への65,535からのdgl SHALLラップのインクリメントされた値。 すべてのIP(All IP)データグラム、送信(ブロック、リクエストあるいは流れパケットを書く)SHALLのモードにかかわらず、上記の記述されたカプセル化ヘッダーのうちの1つによって先行されます。 これは、それらの送信のモードに配慮のないデータグラムの一定のソフトウェア処理を許します。 4.3 リンク破片リアセンブリ 1つを越える1394のパケットSHALLによって送信された、IPデータグラムの受取人、単一のデータグラムからのリンク破片をすべて識別するために送信器のsource_ID(非同期パケット・ヘッダーあるいはGASPヘッダーのいずれかから得られた)、およびdglの両方を使用します。 リンク破片の受取に際して、受取人はIPデータグラム・リアセンブリ・バッファー内にfragment_offsetによって指定された位置にデータ・ペイロード(カプセル化ヘッダーを欠席する)を置いてもよい。 リアセンブリ・バッファーのサイズはdatagram_sizeから決定されるかもしれません。 同じsource_IDおよびdglによって識別された別の破片をオーバーラップさせるリンク破片が、受け取られる場合、リアセンブリに既に蓄積された破片(s)SHALLをバッファーする、廃棄されます。 新鮮なリアセンブリは最も最近受信リンク破片で始められるかもしれません。 破片、オーバーラップする、1394のパケット・ヘッダーからのカプセル化ヘッダーおよびdata_lengthからのfragment_offsetのコンビネーションによって決定されます。 シリアルバスリセット(受取人(s)SHALL)の検知で、すべての部分的に再集合されたIPデータグラムおよび送信器(s)SHALLのリンク破片をすべて廃棄する、すべてを廃棄する、ない、すべての部分的に送信されたIPデータグラムのまだ送信されたリンク破片。 5. 連続するバス・アドレス・レゾルーション・プロトコル(1394のARP) その対応するIPアドレスからの装置のハードウェア・アドレスを決定する方法は、装置によって利用された輸送ミディアムに解決できないほどに拘束されます。 このドキュメントより下の、およびそのドキュメントの全体にわたる記述では、頭文字1394 ARPが、単独で方法およびデータ構造が1394に特有のアドレス・リゾリューション・プロトコルに関係します。 1394のARPは、放送されたIPデータグラムと同じ手段によってSHALLが送信されることを要求します; 1394のARPレスポンスMAY、同じ方法で送信される、あるいはそれら、MAY、ブロック書き込みリクエストがアドレスしたとともに、送信される、に、その 1394のARPのリクエストによって識別されたsender_unicast_FIFOアドレス。 1394のARPのリクエスト/レスポンスは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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図5 ―1394のARPリクエスト/レスポンスフォーマット 1394のARPは要求します、そして非同期流れパケットSHALLによって輸送されたレスポンス、IEEE P1394a(4.1も参照)によって指定された、GASPフォーマット内にカプセルに入れられます。 source_IDフィールド(非同期流れパケットのGASPヘッダーあるいはブロック書き込みリクエストのパケット・ヘッダーから得られたとしても)の最も著しい10ビットが、0x3FFあるいは受取人のNODE_IDS登録の最も著しい10ビットのいずれかと等しくなければ、1394のARPのリクエストの受取人あるいはレスポンスSHALLはそれを無視します。 1394のARPのリクエスト/レスポンス中のフィールドの使用法は以下のとおりです: hardware_type:このフィールドは、1394とSHALLが0x0018の値を持っていることを示します。 protocol_type:このフィールドSHALL、0x0800の値を持っている; これは、1394のARPのリクエスト/レスポンス中のプロトコル・アドレスがIPアドレスのためのフォーマットに一致することを示します。 hw_addr_len:このフィールドはIPアドレスおよびSHALLに関連した、1394-扶養家族ハードウェア・アドレスに、オクテットで、サイズを示します、16の値を持っています。 IP_addr_len:このフィールドはIPバージョン4(IPv4)アドレスおよびSHALLに、オクテットで、サイズを示します、4の値を持っています。 opcode:このフィールドSHALL、1394のARPの応答を示すために1394のARPのリクエストおよび2を示すために1です。 sender_unique_ID:このフィールドSHALL、ノードを含んでいる、送信器およびSHALLのユニークなID、送信器のバス情報ブロックの中で指定されたそれと等しい。 sender_max_rec:このフィールドSHALL、送信器の配置ROMバス情報ブロック中のmax_recの値と等しい。 sspd:このフィールドSHALL、送信器のリンク速度およびPHY速度のより劣ったものにセットされます。 リンク速度はリンクがパケットを送るか受け取るかもしれない最高速度です; PHY速度はPHYがパケットを送るか、受け取るかもしれないし、繰り返すかもしれない最高速度です。 下記のテーブルは、sspdのために使用された符号づけを指定します; 指定されない値はすべて将来の標準化用のRESERVEDです。 テーブル2-スピードコード Value Speed +---------------+ | 0 | S100 | | 1 | S200 | | 2 | S400 | | 3 | S800 | | 4 | S1600 | | 5 | S3200 | +---------------+ sender_unicast_FIFO_hi、およびsender_unicast_FIFO_lo:これらのフィールド、ともにSHALL、セクション6までに指定されたフォーマットの中でIPデータグラムの受取に利用可能な送信器のFIFOの48ビットのオフセットを指定します。 力リセットの結果の場合以外の送信器のユニキャストFIFO SHALL NOT変更のオフセット。 sender_IP_address:このフィールドSHALL、送信器のIPアドレスを指定します。 target_IP_address:1394のARPのリクエストの中で、このフィールドSHALL、送信器がレスポンスを要求するIPアドレスを指定します。 1394のARPのレスポンスで、それ、SHALL、IGNOREDです。 6. 配置ROM IP対応のノード用の配置ROM(Configuration ROM)SHALL、この標準によって指定されたフォーマットにユニットディレクトリーを含んでいます。 ユニットディレクトリーSHALL、ISO/IEC 13213:1994によって指定されるようにUnit_Spec_IDとUnit_SW_Versionのエントリーを含んでいます。 ユニットディレクトリーは、さらに、ISO/IEC 13213:1994あるいはIEEE P1212rによって許された他のエントリーを含んでいるかもしれません。 6.1 Unit_Spec_IDエントリー 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図6 - Unit_Spec_IDエントリー・フォーマット unit_spec_ID SHALLの値、0x00 005E(IANAによってIEEE RAから得られた登録ID(RID))です。 値は、IETFおよびその技術的な委員会がこの標準のメンテナンスに責任を負うことを示します。 6.2 Unit_SW_Versionエントリー Unit_SW_Versionエントリーはunit_spec_IDと結合して、ユニットのソフトウェア・インターフェースを定義するドキュメントを指定するユニットディレクトリー中の即時のエントリーです。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x13 | unit_sw_version (0x00 0001) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図7 - Unit_SW_Versionエントリー・フォーマット unit_sw_version SHALLの値、一つ(それはこの標準の標準の必要条件に装置が応じることを示す)です。 6.3 本文のディスクリプタ 配置ROMの内の本文のディスクリプタはOPTIONALです; それらが付加的な記述的な情報を供給する現在が人間のユーザに理解可能なつもりだった時。 IP対応のノード、SHOULD、Unit_Spec_IDエントリーを備えた「IANA」の内容を備えた本文のディスクリプタ、およびUnit_SW_Versionエントリーのための「IPv4」の内容を備えた本文のディスクリプタを関連させます。 下記の図は、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" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図9 - サンプル・ユニットディレクトリーおよび本文のディスクリプタ 7. IPユニキャスト ユニキャストIPデータグラムは、次の処理コードのうちの1つを持っている、1394の主要なパケット内の受取人に送信されるかもしれません: tcode Description Arbitration +------------------------------------------------+ | 0x01 | Block write | アシンクロナス(非同期) | | 0x0A | Stream packet | アイソクロナス | | 0x0A | Stream packet | アシンクロナス(非同期) | +------------------------------------------------+ ブロックwrite リクエストは、1394のリンクレベルの認識が要求されるが、パケット(サービスの質)の配達の中に弾んだ潜在の必要はない場合、適切です。 等時性の流れパケットは、サービス保証の質だが1394リンクレベルの認識がないを提供します。 最後の方法、非同期流れパケット、完全のためにのみ言及されます。 この方法SHOULD NOT、それが1394のリンクレベルの認識にもサービスの質にも備えるので、IPユニキャストのために使用される―――また価値のある資源(チャンネル番号)を消費します。 使用された非同期あるいは等時性であるIPユニキャスト方法にかかわらず、それは各パケットの中で使用されるかもしれない最大のデータ・ペイロードを決定する、ユニキャストIPデータグラムの送信器の責任です。 必要な情報は次のものから得られるかもしれません: - 1394のバス・マネージャー(それはローカルのシリアルバス上の任意の2つのノード間の最大の送信速度を提供する)によって維持されたSPEED_MAP。 バス・マネージャーは速度地図を構築するためにバス・トポロジを分析します; ノード間の最大の送信速度は、介在するノードの能力を反映します。 速度は次には最大のデータ・ペイロードを意味します(テーブル1を参照); - 1394のARPのレスポンスでsender_max_recフィールド; あるいは - この標準の範囲外の他の方法。 最大のデータ・ペイロードSHALL、送信器、受取人、およびすべての介在するノード(最後のものはインデックスが送信器と受取人によって付けられた、SPEED_MAPエントリーにおいて暗黙です)のPHYによってインプリメントされた最低最大のデータ・ペイロードです。 Johansson基準は、IEEE 1394 12月の1999年の上の[16ページ]RFC 2734 IPv4を追跡します 注:SPEED_MAPは、バス・リセットの後に続く1394のノードすべてによって送信された、自己-IDパケットに由来します。 IP対応のノードは自己-IDパケットを直接観察するかもしれません。 サービスの質が最良の努力SHALLであるユニキャストIP(Unicast IP)データグラム、1394のブロックのデータ・ペイロード内に含まれている、処理を書く、1394のARPの応答から得られたsource_IDおよびsender_unicast_FIFOにアドレスしました。 認識がユニキャスト・ブロック書き込みリクエストに応じて受け取られない場合、データ・ペイロードが目標によって受け取られたかどうか不確かです。 注:目標がもはや機能的でなく、ヘッダーCRCエラーのためにパケットを受け取らなかったかもしれないか、パケットを成功裡に受け取るかもしれないし、反応して送られたacknowledgeが悪くなったので、認識は不在かもしれません。 最良の努力以外にサービスの質を要求するユニキャストIP(Unicast IP)データグラムはこの標準の範囲外です。 8. IP放送 放送IP(Broadcast IP)データグラムはセクション4の仕様書によればカプセルに入れられ、非同期流れパケットによって輸送されます。 1394以上放送されたIPに対するサービス準備の質はありません。 IP放送のために使用されたチャンネル番号は、BROADCAST_CHANNEL登録によって指定されます。 チャンネル番号がBROADCAST_CHANNEL登録からのチャンネル・フィールドと等しいすべての放送IPデータグラムSHALL使用非同期流れパケット。 1394はバス・リセットの後に続く1秒以内で以前に割り付けられたチャンネル番号(s)の使用を許しますが、IP対応のノード、SHALL NOT、いつでも非同期流れパケットを送信する、それらのBROADCAST_CHANNEL登録中の有効なビットは0です。 有効なビットがバス・リセットによって0に自動的に取り除かれるので、IRMがチャンネル番号を割り付けるまで、これは1394のARPあるいは放送IPの使用を禁止します。 9. IPマルチキャスト マルチキャストIP(Multicast IP)データグラムはセクション4の仕様書によればカプセルに入れられ、流れパケットによって輸送されます。 非同期流れは最良の努力IPマルチキャストのために使用されます; 最良の努力以外のサービスの質はこの標準の範囲外です。 Johansson基準は、IEEE 1394 12月の1999年の上の[17ページ]RFC 2734 IPv4を追跡します デフォルトによって、チャンネル番号がBROADCAST_CHANNEL登録からのチャンネル・フィールドと等しいすべての最良の努力IPマルチキャストSHALL使用非同期流れパケット。 データグラムは、特に224.0.0.1および224.0.0.2のSHALL使用にこのチャンネル番号を出しました。 下に記述されるように、そのようなチャンネル番号が使用に先立って割り付けられ広告される場合、他のIPマルチキャストグループ・アドレス用の最良の努力IPマルチキャストは異なるチャンネル番号を利用するかもしれません。 次の2つの条件のうちの1つに遭遇する場合のみ、IP対応のノードは最良の努力IPマルチキャストを送信するかもしれません: - 流れパケット中のチャンネル番号は、BROADCAST_CHANNEL登録中のチャンネル数フィールドと等しい。また、同じ登録中の有効なビットは1です; あるいは - 他のチャンネル番号(s)については、IPマルチキャストのある源が割り付けており、使用されたチャンネル番号を広告しています。 このセクションの残りは、デフォルト以外のチャンネル番号が使用された場合は常に、IPマルチキャスト出所および受取人の両方によって使用されたマルチキャスト・チャンネル割付けプロトコル(MCAP)について記述します。 MCAPは協同のプロトコルです; 参加者は、特別のシリアルバスですべてのIP対応のノードによって使用される、放送チャンネル上のメッセージを交換します。 CAUTION:このドキュメントは1つを越えるIPマルチキャストアドレスによって、単一のチャンネル番号(BROADCAST_CHANNEL登録によって指定されたデフォルト・チャンネル番号以外の)の共有された使用のために設備と方法を定義しません。 9.1 MCAPメッセージフォーマット MCAPメッセージは、マルチキャスト・チャンネル所有者あるいは受取人によって送られたとしても、GASPパケットのデータ部分として輸送され、フォーマットを下に例証します。 メッセージの最初の4オクテットは固定します; 残りは、各々のどれが特別のIPマルチキャストグループに関する情報をコード化するかという可変長さtuplesから成ります。 個々のMCAP(Individual MCAP)メッセージSHALL NOT、である、破片になった、そしてSHALL、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メッセージ中のフィールドの使用法は以下のとおりです: 長さ:このフィールドSHALL、MCAPメッセージ全体に、オクテットに、サイズを含んでいます。 opcode:このフィールドSHALL、テーブルによって下に指定された値のうちの1つを持っています。 opcode 名前 コメント +----------------------------------------------------------------+ | 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. | +----------------------------------------------------------------+ メッセージデータ:MCAPメッセージの残りは長さとSHALLに可変です、下に絵入りのフォーマットを備えた、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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ | タイプ | 予約 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | expiration | チャンネル | 速度 | 予約 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 帯域幅 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + group_address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図11 - MCAPグループ・アドレス・ディスクリプタ・フォーマット 長さ:このフィールドSHALL、MCAPグループ・アドレス・ディスクリプタのオクテットに、サイズを含んでいます。 タイプ:このフィールドSHALL、一つ(それはグループ・アドレス・ディスクリプタを示す)の値を持っています。 終了:このフィールドの使用法はopcodeによれば変わります。 のために、メッセージを求める、終了フィールドSHALL、IGNOREDです。 広告のために、そうでなければ、このフィールドSHALL、時間を含んでいる―型押しをする、数秒で、それは、チャンネルによって指定されたチャンネル番号がもはや使用されていないかもしれない、将来の時を指定します。 チャンネル:このフィールドは有効です、のために(のみ)メッセージを広告する、その場合にはそれ、SHALL、63まで範囲0の中で、割り付けられたチャンネル番号を指定する、包括的。 他のすべての値はRESERVEDです。 速度:このフィールドは有効です、のために(のみ)メッセージを広告する、その場合にはそれ、SHALL、速度を指定する、どれで、示されたチャンネル用パケットを流す、送信されます。 テーブル2は、速度のために使用された符号づけを指定します。 帯域幅:このフィールドSHALL、0である; MCAPにサービスの質を指定し、シリアルバスの等時性の能力を利用する、将来の拡張を適応させるために、それは、グループ・アドレス・ディスクリプタの中で割り付けられます。 group_address:この可変長さフィールドSHALL、特別のIPマルチキャストグループのIPアドレスを指定します。 group_addressの長さはオクテットで、長さフィールドから12を引くことにより、グループ・アドレス・ディスクリプタの長さに由来します。 Johansson基準は、IEEE 1394 12月の1999年の上の[20ページ]RFC 2734 IPv4を追跡します 9.2 MCAPメッセージ領域 MCAPメッセージは、それらが送信されるローカルのシリアルバスにのみ有効な情報を伝えます。 MCAPメッセージSHALL IGNOREすべての受取人、以下のようにローカルバス以外のものからのMCAPメッセージ。 送信器のsource_IDは、カプセルに入れられたMCAPメッセージに先行するGASPヘッダーに含まれています。 MCAPメッセージSHALLの受取人、GASPヘッダーからのsource_IDの最も著しい10ビットを検査する; それらが一方の0x3FFと等しくないか、受取人のNODE_IDSの中で最も著しい10ビットが登録する場合、受取人SHALL IGNORE、メッセージ。 MCAPメッセージ領域内では、チャンネル写像の所有者が、MCAP広告のGASPヘッダー中のsource_IDフィールドによって識別されます。 所有者は最大の物理的なID、source_IDの最も著しくない6ビットを備えたノードです。 9.3 マルチキャスト受理 マルチキャスト・データSHALLを最初に受け取りたいIP対応の装置、グループ・アドレスとチャンネルの間に存在するチャンネル写像(もしあれば)を確認する、BROADCAST_CHANNEL登録によって指定されたデフォルト・チャンネル以外に番号を付けます。 そのような装置は、希望のチャンネル写像(s)のための放送チャンネル上のMCAP広告を観察するかもしれません。 意図したマルチキャスト受取人は広告を第2(10の)の次の間隔よりすぐに放送することをマルチキャスト・チャンネル所有者(s)に要求するためにMCAP懇請リクエストを送信してもよい。 MCAP懇請の発明者は、SHALLがそれらが送信されるレートを制限することを要求します。 懇請リクエスト(発明者SHALL NOT)を送ることの後に続く、10秒が経過するまで、別のMCAP懇請リクエストを送ります。 写像がデフォルト・チャンネル以外のもののためのグループ・アドレスに向かって存在する場合、MCAP、メッセージが10秒以内のEXPECTEDであると広告する。(いずれの場合も、) MCAPの受取で、1つ以上のチャンネル写像について記述するメッセージを広告する、意図したマルチキャスト受取人は、終了時間まで示されたチャンネル番号(s)上のIPデータグラムを受け取ってもよい。 複合の場合、MCAP、同じグループ・アドレスを指定するメッセージが観察されると広告する、チャンネル数SHALL、最大の物理的なID(GASPヘッダーからのsource_IDの最も著しくない6ビットからそのSHALLは得られる)を備えた広告メッセージから得られます。 Johansson基準は、IEEE 1394 12月の1999年の上の[21ページ]RFC 2734 IPv4を追跡します 場合、MCAPはない、10秒以内の特別のグループ・アドレスのためにメッセージが受け取られると広告する、マルチキャスト出所はない(s)デフォルト以外にチャンネル(s)には活発です。 どちらかはそこにそこにあります、マルチキャスト・データあるいはそれでない、デフォルト・チャンネル上で送信されています。 一度マルチキャスト受取人が希望のグループ・アドレスの広告を観察したならば、それ、デフォルト放送チャンネルあるいはチャンネル番号(s)のいずれか上のMAY受理マルチキャスト・データ、示された、しかしそれ、SHALL、使用の中でチャンネル番号(s)の終了時間をリフレッシュするために同じグループ・アドレスのMCAP広告のためのデフォルト放送チャンネルをモニターし続けること 9.4 マルチキャスト送信 デフォルト・チャンネルSHALL以外のものの上のマルチキャスト・データを最初に送信したい、IP対応の装置、別のマルチキャスト出所がグループ・アドレスに既にチャンネル番号を分配したかどうか確認します。 意図したマルチキャスト出所は、1人以上のグループ・アドレス・ディスクリプタを備えたMCAP懇請リクエストを送信するかもしれません。 懇請リクエストは送信されましたか、意図したマルチキャスト出所SHALL、MCAP広告のための放送チャンネルをモニターします。 既に写像するチャンネルがグループ・アドレスに向かって存在する場合、MCAP広告SHOULD、10秒以内に受け取られます。 この場合、意図したマルチキャスト出所は、示されたチャンネル番号(s)上のIPデータグラムの送信を始めるかもしれないし、それらの終了時間までそうし続けるかもしれません。 マルチキャスト出所SHALLモニターMCAP広告、使用の中でチャンネル番号(s)の終了時間をリフレッシュするために 他のマルチキャスト出所がグループ・アドレス用のチャンネル写像を確立していない場合、意図したマルチキャスト出所はIEEE P1394aに記述された手続きによる等時性の資源マネージャーのCHANNELS_AVAILABLE登録からのチャンネル番号を割り付けることを試みるかもしれません。 チャンネル数割付けが成功する場合、マルチキャスト出所SHALL、できるだけ早く新しいチャンネル写像(s)を広告します。 一度100ミリセカンドが経過すれば、新しく割り付けられたチャンネル番号の初期の広告の後に続く、マルチキャスト出所はチャンネル番号を使用して、IPデータグラムを送信するかもしれません、広告しました。 送信器がnon-マルチキャスト・アドレス用のデフォルト・チャンネル写像(s)-を指定する広告を観察するまで(あるいは送信)、マルチキャストIP(Multicast IP)データグラムはデフォルト・チャンネル上で送信されるかもしれません。 これは、デフォルト・チャンネルから明示的に割り付けられたチャンネルへマルチキャストの滑らかな推移を許します。 Johansson基準は、IEEE 1394 12月の1999年の上の[22ページ]RFC 2734 IPv4を追跡します 一度マルチキャスト出所がチャンネル写像を広告したならば、それ、SHALL、チャンネル写像のMCAP広告の送信し続け、でないならば、それ、一方のa)は別のマルチキャスト出所に所有権を転送します、b)は、オーバーラップしたチャンネル写像の場合のトランスファーあるいはc)なしでチャンネル写像が終了することを可能にします、別のマルチキャスト出所にチャンネル写像のコントロールを譲ります。 9.5 チャンネル写像の広告 各マルチキャスト出所SHALLは、それがデフォルト・マルチキャスト・チャンネル番号と異なるチャンネル番号を分配したすべてのIPマルチキャストグループ・アドレスの広告を周期的に放送しました。 広告SHALL、1人以上のグループ・アドレス・ディスクリプタ(各グループ・アドレスの1つはBROADCAST_CHANNEL登録によって指定されたそれ以外にチャンネル番号を割り当てました)を含んでいる0のopcodeを備えた単一のMCAPメッセージから成ります。 各グループ・アドレス・ディスクリプタ内では、group_addressとチャンネルのフィールドがシリアルバスチャンネル番号にIPマルチキャストグループ・アドレスを関連させます。 速度フィールドは、IPマルチキャストグループ内の送信器のうちのいかなるものでもデータを送信することを許される、最大の1394の速度を指定します。 終了フィールドは後に現在の時間あるいは将来の時間を指定します、チャンネル写像(s)はもはやどれではありませんか、有効。 以外は、チャンネル所有者が所有権(9.7に下に記述されたとともに)を放棄するつもりの場合、終了時間SHALL、広告が送信される時から測定された将来に少なくとも60秒です。 高々10秒、SHALL、チャンネル写像の所有者が後の広告の送信を始める前に、その最も最近の広告の送信から経過します。 チャンネル写像SHOULDの所有者、リクエストの受取の後に懇請に応じてできるだけ早くMCAP広告を送信します。 9.6 オーバーラップしたチャンネル写像 2つの意図したマルチキャスト出所が同じIPマルチキャストグループに送信したく、チャンネル写像がグループ・アドレスに向かって存在しない場合、両方がチャンネル番号を割り付けるだろうという可能性があります。また、両方はチャンネル写像を広告するでしょう。 これらのチャンネル写像はオーバーラップします、つまり、同じグループ・アドレスはゼロでない終了回を備えたMCAP広告中の1つを越えるチャンネル番号に写像されます。 マルチキャスト・チャンネル所有者SHALLモニターMCAP広告、オーバーラップしたチャンネル写像を検知するために 終了フィールドがオーバーラップしたチャンネル検知の目的で無視されること未満の値を持っているMCAP広告。 いつ、オーバーラップしたチャンネル Johansson基準は、IEEE 1394 12月の1999年の上の[23ページ]RFC 2734 IPv4を追跡します 写像は検知されます。最大の物理的なID(GASPヘッダーからのsource_IDの最も著しくない6ビットによって決定されたとともに)を持った所有者は、任意の処置を講ずるNOT REQUIREDです。 より小さな物理的なIDを持った所有者によって広告されたチャンネル番号は無効です; 無効のチャンネル番号を使用するIPデータグラムおよびMCAP広告の両方のそれらの所有者SHALL中止送信。 これらのチャンネル写像が終了すると直ちに、それらの所有者SHALL deallocate、9.8に下に記述されるような任意の未使用のチャンネル番号。 オーバーラップしたチャンネル写像SHALLを検知するMCAP広告の受取人は、無効のチャンネル番号を使用するより小さな物理的なIDおよびSHALL NOT送信IPデータグラムでマルチキャスト・チャンネル所有者(s)からの広告を無視します。 有効なのが単一のMCAP広告中のいくつかのチャンネル写像にとって可能です、も、他のもの、SHALL、IGNOREDである、の結果、オーバーラップします。 9.7 チャンネル所有権のトランスファー チャンネル写像の所有者は、特別のチャンネル上のマルチキャスト送信を中止してもよい、その場合にはそれ、SHOULD、チャンネル写像を無効にし、ある場合にはチャンネル番号を非割り付ける。 他のマルチキャスト出所が同じチャンネル写像を使用しているかもしれないので、整然としたプロセスはチャンネル所有権を転送すると定義されます。 写像SHALLをリリースしたい既存のチャンネル写像の所有者、写像およびその関連するチャンネルの予期されるリリースの前に残りの時間を測定するためにタイマーを始めます。 タイマーが0まで数えるまで、所有者SHOULD、影響を受けたチャンネルのMCAP広告だがSHALLの送信し続け、チャンネルがdeallocatedされることになっているまで残りの時間を反映するために各広告中の終了を調節します。 タイマーが0に達するまで、所有者がMCAP広告を送信することができない場合、それ、SHALL、バス・リセットを始めます。 そうでなければ、各次の広告を備えた写像SHALL減少をリリースするつもりの所有者によって送信された終了回のシーケンス。 場合、他のマルチキャスト出所(s)同じチャンネル写像を使用しており、終了が60秒以下の時間を計るのに気づく、それら、SHALL、チャンネル写像を維持する60秒以上のリフレッシュされた終了回を備えたチャンネル写像のMCAP広告を送信し始めます。 多数の出所間に生じるすべての主張、チャンネル写像SHALLの所有権を要求するその試み、9.8に記述されるように解決されます。 オリジナルの所有者がそれ自身のタイマーが終了した前に放棄されるチャンネルのMCAP広告を観察する場合、それ、SHALL NOT、チャンネル番号を非割り付ける。 Johansson基準は、IEEE 1394 12月の1999年の上の[24ページ]RFC 2734 IPv4を追跡します そうでなければ、所有者のタイマーが別のノードによるMCAP広告についての観察なしで終了する場合、チャンネル数SHALLの所有者、9.8に記述されるようなチャンネルを続いて非割り付ける。 チャンネル写像の意図した所有者が終了フィールドが0であるMCAP広告を観察すれば、前の所有者からのチャンネル(s)の整然とした転送は失敗しました。 意図した所有者SHALL、吐き出されたチャンネル番号(s)上の一方の停止受理、および送信、あるいは9.4までに指定されるような異なるチャンネル番号(s)を割り付けます。 9.8 余分のチャンネル写像 チャンネル写像の所有権が1つのマルチキャスト出所から別のものまで転送される場合、所有権を要求することは1つを越える装置にとって可能です。 これは、異なる出所(その各々は同じマルチキャスト・グループ・アドレスおよびチャンネルを指定する)によって送信されて、余分のMCAP広告に帰着します。 9.6のSHALLのそれに似ている手続き、チャンネル所有権のための主張を解決します。 マルチキャスト・チャンネル所有者SHALLモニターMCAP広告、余分のチャンネル写像を検知するために 終了フィールドが余分のチャンネル検知の目的で無視されること未満の値を持っているMCAP広告。 余分のチャンネル写像が検知される場合、最大の物理的なID(GASPヘッダーからのsource_IDの最も著しくない6ビットによって決定されたとともに)を持った所有者は、任意の処置を講ずるNOT REQUIREDです。 余分のチャンネル番号のMCAP広告のより小さな物理的なID SHALL中止送信を持った所有者(s)だがSHALL NOTは、チャンネル番号を非割り付けます。 9.9 吐き出されたチャンネル写像 終了秒が最も最近のMCAP広告以来経過した場合、チャンネル写像は終了します。 この時(吐き出されたチャンネル番号(s)上のマルチキャスト受取人SHALL停止受理)に。 さらにこの時に、チャンネル写像(s)SHALLの所有者、0とSHALLに取り除かれた終了を備えたMCAP広告を送信する、30秒がチャンネル写像の終了以来経過するまで、そのような広告を送信し続けること 一度この付加的な30秒期間が経過したならば、チャンネル写像(s)SHALLの所有者、チャンネル番号(s)を非割り付けて、等時性の資源マネージャーのCHANNELS_AVAILABLE登録中のそれらの有効性を示す。 IP対応の装置が終了フィールドが0であるMCAP広告を観察する場合、それ、30秒が非常に最近のもの以来経過するまで指定された、チャンネル番号(s)のうちのいかなるものでも割り付ける、SHALL NOT試み、そのような広告。 Johansson基準は、IEEE 1394 12月の1999年の上の[25ページ]RFC 2734 IPv4を追跡します 9.10 バス・リセット バスはSHALLをリセットしました、マルチキャスト・チャンネル写像およびSHALLをすべて無効にする、0すべてにマルチキャスト受取人および送信器をすべてもたらす、MCAP広告間隔タイマー。 マルチキャスト・チャンネル写像の先の所有者は、等時性の資源マネージャーのCHANNELS_AVAILABLE登録からのチャンネル番号を再び割り付けるかもしれないし、チャンネルが割り付けられると直ちにMCAP広告に放送されて、再開するかもしれません。 チャンネル再配分が試みられる場合、先の所有者SHOULD、バス・リセットに先立って割り付けられた同じチャンネル番号を使用し、バスの完成で再配分を直ちに始めてもよい、リセットする、同じチャンネル番号が再使用される限り。 先の所有者が異なるチャンネル番号を割り付けることに決定する場合、それ、SHALL、少なくとも1秒が新しいチャンネル番号を割り付けることを試みる前にバス・リセットの完成以来経過するまで、待ちます。 少なくとも10秒がバス・リセットの完成以来経過するまで、デフォルト・チャンネルSHALL NOT以外のものの上のマルチキャストの意図した受取人あるいは先の受取人、発信機は、MCAP懇請リクエストを送信します。 デフォルト・チャンネルSHALL NOT以外のものの上のマルチキャスト・データ、MCAP広告がIPマルチキャストグループ・アドレスのために観察されるか送信されるまで、受け取られるか送信される。 バスに先立ったIPマルチキャストグループ・アドレス用のチャンネル写像を所有しなかったデフォルト・チャンネル以外のものの上のマルチキャストの意図した発信機あるいは先の発信機は、少なくとも10秒がバス・リセットの完成以来経過するまで等時性の資源マネージャーのCHANNELS_AVAILABLE登録からのチャンネル番号を割り付ける、SHALL NOT試みをリセットしました。 この10秒の遅延の後に続くので、マルチキャストの意図した発信機あるいは先の発信機は、チャンネル番号を割り付けて、かつチャンネル写像を広告するために9.4までに指定された手続きに従ってもよい。 10. IANA考察 このドキュメントは、IANAによって新しい名前スペース(登録)の生成および管理を必要とします。 そのような登録の必要は、ISO/IEC 13213:1994,CSRアーキテクチャー(CSR Architecture)で準拠のバス基準によってプロトコル・インターフェースがユニークに識別される方法から発生します。 これは、セクション6に、より詳細に説明されます; 本質は、全体的にユニークな48ビット数SHALLがプロトコル・インターフェースを指定するドキュメントを識別するということです。 48ビットの数は0x00 005E(登録ID(すなわちRID)はIEEE登録権威(IEEE Registration Authority)によってIANAに与えられました)およびIANAによって処理された別の24ビットの数の連結です。 Johansson基準は、IEEE 1394 12月の1999年の上の[26ページ]RFC 2734 IPv4を追跡します IEEE RA RECOMMENDS、それ、第2の24ビットの数の管理用の政策、可能な値の範囲を備えた使用可能な数の量を最大限にするために選ばれます。 項目の中で、IEEE RA RECOMMENDS、それ、割り当てスキーム、ない、これは範囲の大部分を浪費する傾向があるので、数(例えば数の内のバージョン・フィールドの割付け)に構造を適用します。 新しい名前スペースは「CSRプロトコル確認者(CSR Protocol Identifiers)」です。 値0および0xFF FFFFは予約でSHALL NOTです、IANAによって割り付けられます。 値1つはこのドキュメントに分配されます。 残る数SHALL、IANAによって管理され、インターネットを識別するのに必要なときに割り付けられる―IESG基準になる為替手形はドキュメントを追跡します。 IANA(すべての割り当てられたバージョン数SHOULDの登録)によって選ばれた、割り当て方法にかかわらず、1つ以上のインターネットサイトで維持され、RIDおよびバージョン番号のコンビネーションによって識別された適切な標準を明白に識別するべきである。 11. セキュリティ考察 このドキュメントは、IPv4データグラムの輸送のために無保証のリンク層(シリアルバス)の使用を指定します。 シリアルバスはサービス攻撃の否認に弱い; データあるいは現在の鍛造された同一性を盗み聞きすることは、さらに装置にとって可能です。 IPv4 SHOULDのためのシリアルバスを利用するImplementersは適切なカウンター-適用あるいは他の層内の手段-を考慮します。 12. 確認応答 このドキュメントは、IP/1394ワーキンググループの努力を表わします。 エディターは、すべての活動的な参加者によって、一方の反射器上で、あるいは直接の会(それらは技術的な内容を進めた)でなされた寄付を認めたい。 Johansson基準は、IEEE 1394 12月の1999年の上の[27ページ]RFC 2734 IPv4を追跡します 13. 参照 そのような時間が良いとされた標準と取り替えられるまで、このドキュメントの出版の時の開発中の標準への標準の言及は、最多の現在の為替手形を利用するものとします。 [1] IEEE Std 1394-1995、高機能連続するバス(High Performance Serial Bus)のための基準 [2] マイクロコンピュータ・バス(Microcomputer Buses)のためのISO/IEC 13213:1994,コントロール、およびステータス・レジスター(Status Register)(CSR)アーキテクチャー [3] IEEEプロジェクトP1394a(IEEE Project P1394a)、高機能連続するバス(High Performance Serial Bus)(サプリメント)のための規格案 [4] IEEEプロジェクトP1394b(IEEE Project P1394b)、高機能連続するバス(High Performance Serial Bus)(サプリメント)のための規格案 [5] ポストL、J。「インターネット・プロトコルDarpaインターネットプログラム・プロトコル・スペック。」RFC、1981年9月791。 [6] Bradner、S、「要求レベル(Requirement Levels)を示すRFCの中の使用のためのキーワード。」RFC、1997年3月2119。 14. エディターのアドレス ピーターJohansson一致するソフトウェア社、98のコロラド通りバークレー(CA 94602) 電話:(510)527-3926のファックス:(510)527-3856のEMail:pjohansson@aol.com Johansson基準は、IEEE 1394 12月の1999年の上の[28ページ]RFC 2734 IPv4を追跡します 15. 十分な著作権のあるステートメント 著作権(C)、インターネット社会(1999)。 著作権保有。 このドキュメントおよびその翻訳は他のものおよび派生的な工場にコピーされ供給されるかもしれません、そのコメント、の上で、あるいはそうでなければそれについて説明するか、そのインプリメンテーションを助ける、準備されているかもしれない、もし上記の著作権通知およびこのパラグラフがすべてのそのようなコピーおよび派生的な工場に含まれていれば任意の種類の制限なしで、全体の中で、あるいは一部分、公表され分配されて、コピーしました。 しかしながら、このドキュメントはそれ自身著作権のある通知あるいはインターネット学会あるいは他のインターネット組織への言及の削除によってのように任意の方法で修正されないかもしれません、以外は、求められるような、インターネット基準を開発する目的で、その場合には、インターネット基準(Internet Standards)プロセスに定義された著作権のための手続きに続くに違いない、あるいは求められるような、英語以外にそれを言語に翻訳するために 上に与えられた、制限のある許可は永続し、インターネット学会あるいはその後継者によって無効にされないでしょう、あるいは割り当てます。 ここに含まれていたこのドキュメントおよび情報は、「AS IS」方式および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、PARTICULAR PURPOSE。 確認応答 RFCエディター(RFC Editor)機能のために資金を提供することは、インターネット学会によって現在提供されます。 Johansson基準は[29ページ]を追跡します