イーサネットフレーム

イーサネットフレームの構造と役割

イーサネットフレームは、有線LANの標準規格であるイーサネットでデータ通信を行う際に使用される、データの書式です。これは「MACフレーム」とも呼ばれ、OSI参照モデルのデータリンク層（第2層）に位置するMAC（Media Access Control）によって処理されます。データリンク層におけるデータの単位（PDU）は一般的に「フレーム」と呼ばれます。

イーサネット通信では、物理層の様々な規格に基づいて物理信号が利用され、その内部にイーサネットフレームが組み込まれて送受信されます。フレームの送受信に先立ち、送信開始の合図としてプリアンブルとSFDという信号が送られます。フレームの先頭には、宛先と送信元のMACアドレスが含まれており、ネットワーク機器が転送処理の判断に利用します。フレームの中央部にはペイロードがあり、任意のデータが格納されます。フレームの末尾にはフレームチェックシーケンス（FCS）があり、転送中のデータ破損を検出することができます。

以降の説明では、「バイト」という用語を8ビット（1オクテット）の意味で使用します。

フレームの構成要素

イーサネットフレームと、それを含む物理層パケットは、バイナリデータで構成されています。IEEE 802.3では、以下に示すフレーム構造が規定されています。


[フレーム構造の図表は省略]


データは図の左側、表の上から順に送信されますが、各バイト内では最下位ビット（LSB）が最初に送信されます。

この図表では、MTU（Maximum Transmission Unit）が1500バイト以下のペイロード長を持つものが示されています。ギガビットイーサネット以降では、ジャンボフレームと呼ばれる、より大きなフレームを扱う製品も存在します。また、VLAN（Virtual Local Area Network）タグはオプションであり、通常は4バイトですが、二重タグの場合は8バイトになります。

プリアンブルとSFD

物理層パケットは、イーサネットフレームを送信する前に、以下の信号で始まります。

7バイトのプリアンブル（preamble）：同期用信号
1バイトのSFD（Start Frame Delimiter）：フレーム開始の区切りを示す信号

これらの信号のビットパターンは、以下のようになります。

[ビットパターンの記述は省略]

プリアンブルでは、ビットの交互パターン「10」が連続しており、これにより受信側はビットレベルでの同期を容易に行うことができます。続くSFDでは、この交互パターンの最後に「11」が現れることで、受信側はバイトレベルでの同期を取りながらフレームの開始を検出できます。

これらの信号は、LSBが先頭となる十六進表現で表されることがあります。特に、PHY（物理層デバイス）とMAC（データリンク層デバイス）間の並列バスであるMIIを経由する場合などでは、以下のように表されます。

100Mbps通信のMIIでは、4並列バスのため、ニブル値（4ビット値）でプリアンブルは14個の「0x5」、SFDは「0x5 0xD」となります。
1Gbps通信のGMIIでは、8並列バスのため、バイト値（8ビット値）でプリアンブルは7個の「0x55」、SFDは「0xD5」となります。

イーサネットヘッダ

フレーム先頭の以下の欄を「イーサネットヘッダ」または「MACヘッダ」と呼びます。

宛先MACアドレス（6バイト）
送信元MACアドレス（6バイト）
VLANタグ（4バイトまたは8バイト）：オプション
タイプ/長さ（2バイト）：詳細は後述

レイヤ2スイッチ（MACブリッジ）は、ヘッダの内容を見て転送処理を行います。その処理動作はIEEE 802.1Dで規定され、その後IEEE 802.1Qに引き継がれています。MACアドレスは、フレームの転送先を判断したり、送信元を記録したりするのに使用されます。VLANタグは、所属するLANと優先度（QoS）を示し、転送先や転送タイミングの判断に利用されます。

タイプ/長さ

タイプ/長さの欄は、以下の2つの用途があります。

値が1536（0x0600）以上の場合は、EtherTypeとして解釈されます。
値が1500（0x05DC）以下の場合は、ペイロード長として解釈されます。
1500から1536の間の値は未定義です。

ほとんどのイーサネットフレームはEtherTypeを使用します。EtherTypeは、ペイロード欄にカプセル化されているデータが何のプロトコルであるかを示すもので、例えば「0x0800」はIPv4パケット、「0x0806」はARPフレーム、「0x86DD」はIPv6フレーム、「0x8100」はVLANタグ付きフレームを表します。この場合、フレーム長は明示されていませんが、FCSやEOFなどによってフレーム末尾を検出することでフレーム長がわかります。

ペイロード長を用いるフレームの実例については、後述の「種類」の節を参照してください。

ペイロード

ペイロードは「MACクライアントデータ」とも呼ばれ、通信に使う実際のデータが配置されます。任意のプロトコルを配置することができ、多くの場合、IPパケットのデータがIPヘッダを含んだ形で格納されます。

最小ペイロード長は、VLANタグがある場合は42バイト、ない場合は46バイトです。これは、フレーム長が最低64バイトになるように設定されており、初期のイーサネットにおけるCSMA/CD|CSMA_CDの衝突検出にかかる時間によって決定されました。実際のペイロードが最小ペイロード長よりも短い場合は、最小ペイロード長になるまでパディングされます。

最大ペイロード長は、初期には1500バイトと規定されていましたが、1998年にIEEE 802.3acでVLANタグに対応するため1504バイト、2006年にIEEE 802.3asで1982バイトに拡張されています。規格外の独自仕様であるジャンボフレームでは、さらに大きなペイロード長に対応できます。

フレームチェックシーケンス（FCS）

フレームチェックシーケンス（FCS）は、送信側がフレーム末尾に付加する4バイトの値で、これにより受信側はフレーム全体のデータ破損を検出して破棄することができます。また、受信側でペイロード長がわからなくても、FCSを検証することでフレームの末尾を知ることができます。

FCSの値は、32ビットの巡回冗長検査（CRC）であり、イーサネットフレームからFCS欄を除いた部分（送信元MAC、宛先MAC、長さ/タイプ、ペイロード）を入力として計算されます。この計算には、CRC-32の標準多項式0x04C11DB7が用いられます。CRCの値は、最上位ビット（ビット31）を最初に、最下位ビットを最後に送信するようにFCS欄に割り付けられます。受信時には、同様にCRCを計算し、フレーム内のFCSと比較します。

上記の規定と同等の実装方法として、以下のようなアレンジが施されることがあります。

ビット列を逆順にして演算することがあります。フレーム内の他の欄がLSBが先頭に来る形式であるため、FCSもこれに合わせてあらかじめビット列を逆順にして右シフトのCRC多項式を用いる方が効率的です。
受信時に送信側と同じ方法でCRCを算出するのではなく、FCSを含む受信フレーム全体にCRC算出を行うことがあります。この結果、エラーがなければ常に同じ非ゼロの値が得られるため、これを「CRC検証値」や「CRCマジックチェック」などと呼びます。
CRC算出の回路実装では、LFSRに記録する値は補数を取らないことがあります。この場合は、送信時や取得時に補数変換する必要があります。

これらの方式により、演算に使用される値にはバリエーションがあります。

フレームの終わり（物理層）

フレームの終わり（EOF: end of a frame）は通常、物理層でのデータストリームの終了シンボルやキャリア信号の消失によって示されます。特に、リンク確立中のアイドリング信号（継続的なキャリア）が常に送信されるような物理層規格では、明示的にend of dataまたはend of streamのシンボルやシーケンスが使われることがあります。

10BASE-Tでは、受信側はキャリアの消失によって送信されたフレームの終わりを検出します。
1000BASE-X（8b/10bによる1Gbps通信）では、フレーム送信前後に特殊シンボルを送信します。

パケット間隔

パケット間隔は、IFG（interframe gap）またはIPG（interpacket gap）とも呼ばれます。送信側は、フレーム送信終了後に次のフレームを送信するまで、最低96ビット（12バイト）のアイドル状態を維持する必要があります。これも、CSMA/CD|CSMA_CDの物理的な制約に基づいています。

イーサネットフレームの種類

イーサネットフレームには、歴史的にいくつかの種類があります。主なものを以下に示しますが、現在ではEthernet II以外のものはほとんど使われていません。

[フレームの種類の一覧表は省略]

これらの4種類は、タイプ/長さ欄やペイロード欄の差異によって識別でき、同じ物理媒体上に共存できます。また、いずれにもVLANタグを付けることができます。

Ethernet II

Ethernet IIは、タイプ/長さ欄をEtherTypeとして使うフレームです。DEC、Intel、Xeroxの3社が主に設計・規定したもので、3社の頭文字を取ってDIX仕様とも呼ばれます。1979年の仕様公開から事実上の標準として広く普及していましたが、1997年のIEEE 802.3xで正式に標準化され、この欄をタイプ/長さとして併用することが明記されました。

この書式以外の3種はすべて、この欄を長さ（ペイロード長）として使うよう規定されています。この仕様は、1983年のIEEE 802.3初版に基づいており、標準化の際にDIX仕様から変更されましたが、1997年の改版時に併用として先祖返りする形となっています。

ノベルIPXカプセル

ペイロード部分にIPXパケットを置くものです。1983年にノベルがIEEE 802.3策定中の仕様をもとにしてNetWareなどに独自実装したプロトコルで、1990年代半ばまで使われました。

長さ欄のすぐ後にIPXパケットが始まります。これは規格準拠ではありませんが、ペイロードの先頭2バイトを「0xFFFF」としているため、次のIEEE 802.2 LLCカプセルでそのパターンになることはごく稀であり、実用上は他の書式と識別できました。ただし、DECnetの初期の形式では、この仕様が混乱を招いたものがあります。

IP普及がまだ進んでいなかった時代は、NetWareでデフォルトだったこの形式によるIPX通信がイーサネット通信のほとんどを占めていました。

IEEE 802.2 LLCカプセル

ペイロード部分にLLCパケットを置くものです。LLCヘッダには、SAP（service access points）と呼ばれる2つのアドレス値が含まれています。制御バイトの値によって、コネクションレス型とコネクション型の通信モードのどちらでも動作できます。

この書式は、過去には多くの社内LANでイーサネットとトークンリングやFDDIとのトランスペアレント変換ブリッジに使われましたが、現在一般的なネットワークではほとんど使われません。ノベルのNetWare4.10以降では、デフォルトのIPX通信にも使われましたが、ほとんどはIP通信に移行しています。

IEEE 802.2 SNAPカプセル

SNAP（Subnetwork Access Protocol）は、IEEE 802.2 LLCを拡張し、特にEtherTypeを格納する欄を設けてプロトコルの識別ができるようにしたものです。

LLCヘッダのSAPがともに「0xAA」の場合、LLCヘッダの後にSNAPヘッダを置くことができます。SNAPヘッダでは、プロトコルID欄にEtherType値を入れることができます。

1987年にリリースされたMac OSのEthertalkでこの書式が使用されていました。1988年のRFC 1042では、IEEE 802.2 LLCのSAP/SNAPフレームに、IPv4通信をカプセル化する仕様が規定されました。FDDI、トークンリング、IEEE 802.11（EtherTypeを使用する5.9GHz帯域を除く）などで使用されていますが、イーサネットではほとんど実装されていません。同様にIPv6もIEEE 802.2 LLC SAP/SNAPを用いたイーサネット通信が可能ですが、これもまたほとんど使用されていません。

最大スループット

イーサネットのスループットは、以下の式で表せます。

スループット = 回線速度 × 伝送効率

ここで「回線速度」は、ファーストイーサネットなら100Mbps、ギガビットイーサネットなら1Gbpsといった、物理層規格の値をそのまま使用します。一方、「伝送効率」は、いくつかの観点で計算されることがあり、いずれも共通の分母を持ちます。

ペイロード伝送の効率 = (ペイロード長) ÷ (物理層パケット長 + パケット間隔長)
ネットワーク運用効率として示される値。VLANタグの有無によって値が変わります。
フレーム伝送の効率 = (フレーム長) ÷ (物理層パケット長 + パケット間隔長)
ネットワークスイッチ性能として示される値。イーサネットヘッダを含みます。
物理層パケット伝送の効率 = (物理層パケット長) ÷ (物理層パケット長 + パケット間隔長)
チャネル占有率として示される値。プリアンブル、SFD、イーサネットヘッダを含みます。

[伝送効率の計算例の表は省略]

スループットは、これらの伝送効率を用いて計算することができます。例えば、1000BASE-Tでタグ付きフレームを通信する場合の最大スループットは、表の最右列の値に1Gbpsを掛けて、それぞれ972.8Mbps、987.0Mbps、992.2Mbpsとなります。

スイッチ性能としてのスループットは、pps（パケット毎秒）で表現することもあり、以下の式で求められます。

pps = 回線速度 ÷ 8 ÷ (物理フレーム長 + パケット間隔長)

1Gbps通信の最短フレームの場合、1G / 8 / 84 = 1488095ppsとなり、この値がベンチマークテストに用いられます。

異常なフレーム

IETFでは、RMONと呼ばれるLAN管理機能が規定されており、その一環としてフレームの統計情報収集機能で異常な書式のフレームが定義されています。主な異常フレームには、以下のようなものがあります。

CRC不一致：受信フレームのFCSの値が、CRCの算出値と一致しないもの。CRC Alignmentエラーとして計上されます。
ラントフレーム（runt frame）：最小フレーム長である64バイトよりも短いもの。CRCが一致するものはUndersize（不足フレーム）、しないものはFragment（途切れたフレーム）として計上されます。後者は一般的にコリジョン（衝突）によって発生します。その他の原因として、ネットワークカードの誤動作、バッファアンダーラン、デュプレックスの不一致、ソフトウェアの不具合などが考えられます。
長すぎるフレーム：最大フレーム長（主に1522バイト）を超えるもの。CRCが一致するものはOversize（超過フレーム）、しないものはJabberとして計上されます。前者は、ジャンボフレームやVLANタグフレームに対応していない機器でそれらのフレームを受信した場合などに、後者はフレームの終了を通知・検出できない回路異常などが考えられます。
タイプ/長さが未定義の値のもの（1501～1535または0～41）。
物理層パケットの異常：フレーム終了時の受信ビット数が8の倍数にならない異常や、物理信号が物理層で定義されたシンボルとして認識できない異常が発生した場合に、PHYがRX_ER通知をMIIバスで通知し、これを検出・計上するものがあります。

もう一度検索