ノベル独自フレームフォーマット

　ノベルのフレームフォーマットは 802.3 仕様の予備リリースに基づいています。 ノベルがこのフォーマットをリリースした後、LLC ヘッダが付加され、互換性がなくなりました。




データリンクヘッダ

オフセット 0-5: 宛先

イーサネットフレームの最初の６バイトは宛先です。宛先は送られたデータフレームがどのアダプタへのものかを指定します。 宛先がすべて１のものはブロードキャストで、これはすべての受信イーサネットアダプタによって読み込まれます。

宛先の最初の３バイトは IEEE によってアダプタのベンダに割り当てられており、ベンダが特定できます。

宛先のフォーマットにイーサネットの実装による違いはありません。

オフセット 6-11: 送信元

イーサネットフレームの次の６バイトは発信元です。発信元はどのアダプタでメッセージが作られたかを特定します。 宛先と同じように最初の３バイトによってカードのベンダを指定します。

発信元のフォーマットにイーサネットの実装による違いはありません。

オフセット 12-13: 長さ

イーサネットの 13-14 バイト目は長さの情報です。32 ビットの CRC、DLC アドレス、長さ情報自身で、プリアンブルは含まれません。 イーサネットフレームは 64 バイト〜 1518 バイトの範囲内です。

ユーザデータとフレームチェックシーケンス（ FCS ）

データ: 46-1500 バイト

データリンクヘッダの後に、46 バイトから 1500 バイトのデータが続きます。 ノベルのフレームでは、ユーザデータは IPX（ノベルのネットワーク層プロトコル）ヘッダで始まります。 IPX の最初の２バイトはチェックサムとして使うことができ、値が FFFF であれば、チェックサムとして使われていないということを意味します。 チェックサムは通常使われておらず、デバイスドライバは発信元のすぐ後に来る FFFF でノベルフレームと 802.3 フレームを見分けます。 この FFFF が出てくるまでは、ノベルフレームも 802.3 フレームも同じように見えます。

最後の４バイト

アダプタに読み込まれる最後の４バイトは、フレームチェックシーケンス、または CRC です。 同軸の電圧がゼロに戻ったとき、アダプタは受取った最後の４バイトが、 多項式によって生成されたチェックサムに反していないかを調べます。 計算されたチェックサムが、フレームのチェックサムと一致しないとき、 そのフレームは捨てられ、ステーションのメモリバッファには取り込まれません。

ノベルイーサネットフレームフォーマットのための覚え

　「ノベルのクライアントは NetWare のために、ただ一つのフレームフォーマットを使用します。」

　このことを十分に理解するためにはもう少し説明が必要です。

　NET.CFG ファイルの LOAD と BIND の設定によって、 ノベルのサーバは４つのイーサネットフレームタイプのどれでも扱うことができます。 ノベルのクライアントはファイルサーバ（あるいは VLM ディレクトリサーバ）の場所を突き止めるために NET.CFG の中のリストを使います。 クライアントは NET.CFG のリストの上に書かれているフレームタイプから試み始め、 「もっとも近いサーバを見つける」というメッセージをブロードキャストします。 どのファイルサーバ（あるいは VLM ディレクトリサーバ）も応えなければ、クライアントは次のフレームフォーマットで試します。 クライアントはリブートされるまで、ファイルサーバから応答のあった、そのフレームフォーマットを使用します。

　結果としてノベルのクライアントは、４つのフォーマットのうち一つだけを最終的に使うことになります。 NetWare は同時に複数のフォーマットを使うことはできません。 最初に応えたサーバによってフレームフォーマットが決まるのです。 この動作は NCP や SPX によって使われるフレームフォーマットによって制限されます。 クライアントが TPC/IP を使っていたら、他のフレームフォーマット（通常はバージョン２）よりも、 IP プロトコルが使われることになるということです。