イーサネットフレーム（）は、有線LAN規格のイーサネットによる通信で処理されるデータ書式のこと。「MACフレーム」とも。
イーサネットの通信データ処理部はMACと呼び、これはOSI参照モデルの第2層にあたるデータリンク層に位置する。データリンク層プロトコルでのデータ単位(PDU)を一般に「フレーム」と呼ぶ。通信はイーサネットの各種物理層規格における物理信号を利用し、物理層パケットの内部にイーサネットフレームが含まれた形で送受されるIEEE 802.3-2022 。
フレーム送付の前に、送信開始の合図としてプリアンブルとSFDと呼ぶ信号を送る。フレームの先頭には宛先と送信元のMACアドレスがあり、ネットワーク機器による転送処理判断に使われる。フレームの中央にペイロードがあり、任意の主データが配置できる。フレーム末尾にはフレームチェックシーケンス(FCS)があり、転送中のデータ破損を検出することができる。
なお、以降では「バイト」の語を8ビット(1オクテット)の意味として用いる。
構造 イーサネットフレームとそれを含む物理層パケットは、バイナリデータで構成されている。IEEE 802.3では以下の図表に示すフレーム構造を規定している。データは図の左・表の上から順に送信されるが、各バイト内では最下位ビット(LSB)を最初に送る。
+ イーサネットの物理層パケットとフレームの構造 内容 サイズ[Byte] 範囲 プリアンブル 7 ↑物理層パケット(72–1534)↓ SFD 1 宛先MACアドレス 6 ↑イーサネットフレーム(64–1526)↓ 送信元MACアドレス 6 (VLANタグ) (4 or 8) タイプ/長さ 2 ペイロード 46-1500 FCS 4 パケット間隔 12
ここではMTUが1500バイト以下のペイロード長を持つものを示した。ギガビットイーサネット以降では、ジャンボフレームと呼ばれるさらに大きなフレームの対応を実装した製品もある。
また、VLANタグはオプションとして括弧で示しており必須ではない。通常は4バイトであるが、二重タグの場合は8バイトとなる。
プリアンブルとSFD
物理層パケットは、イーサネットフレームを送る前に以下の信号から始まる。
7バイトのプリアンブル (preamble, 「前置き」の意) 1バイトのSFD (start frame delimiter, 「フレーム開始の区切り目」の意)
これらの伝送路上のビットパターンは以下のようになるIEEE 802.3-2022, section 3.2.1 Preamble field, section 3.2.2 Start Frame Delimiter (SFD) field, section 4.2.5 Preamble generation, section 4.2.6 Start frame sequence。ここでは左のビットから順に送信される形で記載した。
プリアンブルではビットの交互パターン10を連続させており、受信側はこれによりビットレベルで容易に同期できる。その後のSFDではこの交互パターンの最後が崩れて11となり、受信側はこれによりバイトレベルで同期しながらフレームの開始を検出できるIEEE 802.3-2022。
なお、これらの信号はLSBが先頭となる十六進表現を使うことがある。特にPHY (物理層デバイス)・MAC (データリンク層デバイス)間の並列バスであるMIIを経由する場合などでは、以下のように表す。 100Mbps通信のMIIは4並列バスのため、ニブル値(4ビット値)表現で、プリアンブルは14個の0x5、SFDは0x5 0xDの順となる。 1Gbps通信のGMIIは8並列バスのため、バイト値(8ビット値)表現で、プリアンブルは7個の0x55、SFDは0xD5となる。
イーサネットヘッダ フレーム先頭の以下の欄を「イーサネットヘッダ」または「MACヘッダ」と呼ぶ。
宛先と送信元のMACアドレス (6バイト+6バイト) VLANタグ (Qタグは4バイト、Q-in-Qタグは8バイト) - オプションであり必須ではない。 タイプ/長さ (2バイト) - 詳細は次節
レイヤ2スイッチ(MACブリッジ)はヘッダの内容を見て転送処理を行っている。その処理動作はIEEE 802.1Dで最初に規定され、その後の改版でIEEE 802.1Qに引き継がれている。MACアドレスは、フレームの転送先を判断したり、送信元を記録したりするのに用いる。VLANタグでは、所属するLANと優先度（QoS）が示され、同様に転送先や転送タイミングの判断に用いる。
タイプ/長さ タイプ/長さの欄は、用途が2種類あるIEEE 802.3-2022 。 この値が1536（0x0600）以上の場合は、EtherTypeと解釈される。 この値が1500（0x05DC）以下の場合は、ペイロード長と解釈される。
1500と1536の間の値は未定義。
ほとんどのイーサネットフレームがEtherTypeを用いる。EtherTypeは、ペイロード欄にカプセル化されているデータが何のプロトコルかを示すもので、例えば0x0800はIPv4パケット、0x0806はARPフレーム、0x86DDはIPv6フレーム、0x8100はVLANタグつきフレームを表す。このときフレーム長は明示されていないが、FCSやEOFなどによってフレーム末尾を検出することでフレーム長がわかるようになっている。
ペイロード長を用いるフレームの実例については#種類の節を参照のこと。
ペイロード ペイロードは「MACクライアントデータ」とも呼び、通信に使う主データを配置する。任意のプロトコルを配置することができ、多くの場合は第3層にあたるIPパケットのデータがIPヘッダを含んだ形で格納される。
最小ペイロード長は、VLANタグがある場合は42バイト、ない場合は46バイトである。この値は、フレーム長が最低64バイトになるように設定されており、初期イーサネットでのCSMA/CDの衝突検出にかかる時間によって決まったIEEE 802.3-2022。実際のペイロードが最小ペイロード長よりも短い場合は、最小ペイロード長になるまでパディングされる。
最大ペイロード長は初期には1500バイトと規定されていたが、1998年にIEEE 802.3acでVLANタグ対応のため1504バイト、2006年にIEEE 802.3asで1982バイトに拡張されている。規格外の独自仕様であるジャンボフレームでは、さらに大きなペイロード長に対応できる実装もある。
フレームチェックシーケンス フレームチェックシーケンス (FCS) は、送信側がフレーム末尾につける4バイト値で、これにより受信側でフレーム全体のデータ破損を検出して破棄することができる。また、受信側でペイロード長がわからなくてもFCSを検証することでフレームの末尾がわかるようになる。
FCSの値は、32ビットの巡回冗長検査 (CRC) であり、イーサネットフレームからFCS欄を除いた部分（送信元MAC・宛先MAC・長さ/タイプ・ペイロード）を入力として計算する。この計算ではCRC-32の標準多項式0x04C11DB7を用いる。CRCの値は、最上位ビット (ビット31) を最初に、最下位ビットを最後に送信するようにFCS欄に割り付けられるIEEE 802.3-2022。このフレーム受信時には、CRCを同様に計算し、フレーム内のFCSと比較するものとしているIEEE 802.3-2022。
上記の規定と等価な実装方法として、以下のようなアレンジが施されることがある。 + CRCの実装に使われる値 算出方法 順方向(左シフト) 逆方向(右シフト) CRC多項式 0x04C11DB7 0xEDB88320 CRC検証値 0x38FB2284 0x2144DF1C CRC検証値の補数 0xC704DD7B 0xDEBB20E3 ビット列を逆順にして演算することがある。フレーム内の他の欄は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通信)では、フレーム送信前後に特殊シンボルを送信するIEEE 802.3-2022。
パケット間隔 パケット間隔は、 IFG (interframe gap) または IPG (interpacket gap)とも呼ぶ。送信側はフレーム送信終了後に次のフレームを送信するまで最低96ビット（12バイト）のアイドル状態を維持する必要がある。これもCSMA/CDの物理的制約に基づいて決められているIEEE 802.3-2022。
種類 イーサネットフレームには歴史的にいくつかの種類がある。主なものを下表に示したが、現在ではこのうち Ethernet II 以外のものはほとんど使われていない。
+ イーサネットフレームの種類 種類 タイプ/長さ欄の値 ペイロードの先頭2バイト 備考 Ethernet II ≥ 1536 任意 DIX仕様とも。今日最も一般的に使用される。 ノベルIPXカプセル ≤ 1500 0xFFFF ベンダ固有書式。 IEEE 802.2 LLC カプセル ≤ 1500 SAPアドレス IEEE 802.3初期仕様の1つ。 IEEE 802.2 SNAP カプセル ≤ 1500 0xAAAA IEEE 802.3初期仕様の1つ。
これら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年代半ばまで使われた。 イーサネットヘッダノベル独自ペイロード宛先MAC送信元MAC長さ識別子データ6バイト6バイト2バイト2バイト0xffff任意バイト
長さ欄のすぐ後にIPXパケットが始まる。これは規格準拠ではないが、ペイロードの先頭2バイトを0xFFFFとしており、次節のIEEE 802.2 LLC カプセルでそのパターンになることはごく稀であるため、実用上は他の書式と識別可能だった。ただし、DECnetの初期の形式では、この仕様が混乱を招いたものがある。
IP普及がまだ進んでいなかった時代は、NetWareでデフォルトだったこの形式によるIPX通信がイーサネット通信のほとんどを占めていた (HTML-formatted version ) — a classic series of Usenet postings by Novell's Don Provan that have found their way into numerous FAQs and are widely considered the definitive answer to the Novell Frame Type usage.。
IEEE 802.2 LLC カプセル ペイロード部分にLLCパケットを置くもの。LLCヘッダには、SAP (service access points) と呼ばれる2つのアドレス値が含まれている。制御バイトの値によってコネクションレス型・コネクション型の通信モードのどちらでも動作できる。
イーサネットヘッダ802.2 LLC ヘッダペイロード宛先MAC送信元MAC長さ宛先SAPアドレス送信元SAPアドレス制御6バイト6バイト2バイト1バイト1バイト1-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値を入れることができる。
イーサネットヘッダ802.2 LLC ヘッダSNAP拡張ペイロード宛先MAC送信元MAC長さ宛先SAP送信元SAP制御OUIプロトコルID6バイト6バイト2バイト1バイトAA1バイトAA1-2バイト3バイト2バイト任意バイト
1987年にリリースされたMac OSのEthertalkでこの書式を使用していた。
1988年のでは、IEEE 802.2 LLCのSAP/SNAPフレームに、IPv4通信をカプセル化する仕様が規定された。FDDI・トークンリング・IEEE 802.11（EtherTypeを使用する5.9 GHz帯域を除く）IEEE 802.11-2016などで使用されているが、イーサネットではほとんど実装されていない。同様にIPv6もIEEE 802.2 LLC SAP/SNAPを用いたイーサネット通信が可能であるが、これもまたほとんど使用されていない。
最大スループット イーサネットのスループットは以下の式で表せる。
ここで、「回線速度」はファーストイーサネットなら100Mbps、ギガビットイーサネットなら1Gbpsなどの物理層規格の値をそのまま採る。一方、「伝送効率」はいくつかの観点で計算されることがあり、いずれも共通の分母を持つ。
ペイロード伝送の効率 = (ペイロード長) ÷ (物理層パケット長 + パケット間隔長) ネットワーク運用効率として示される値。VLANタグの有無によって値が変わる。 フレーム伝送の効率 = (フレーム長) ÷ (物理層パケット長 + パケット間隔長) ネットワークスイッチ性能として示される値。イーサネットヘッダを含む。 物理層パケット伝送の効率 = (物理層パケット長) ÷ (物理層パケット長 + パケット間隔長) チャネル占有率として示される値。プリアンブル・SFD・イーサネットヘッダを含む。
これらの式を用いた伝送効率の計算例を下表に示す。
最短フレーム (タグなし) 最短フレーム (タグつき) 最長フレーム (タグなし) 最長フレーム (タグつき) サイズ ペイロード長 46バイト 42バイト 1500バイト 1500バイト フレーム長 64バイト 64バイト 1518バイト 1522バイト 伝送効率 ペイロード率 54.76% (=46/84) 50.00% (=42/84) 97.53% (=1500/1538) 97.28% (=1500/1542) フレーム率 76.19% (=64/84) 76.19% (=64/84) 98.70% (=1518/1538) 98.70% (=1522/1542) 物理層パケット率 85.71% (=72/84) 85.71% (=72/84) 99.22% (=1526/1538) 99.22% (=1530/1542)
スループットはこれらの伝送効率を用いて計算することができる。例えば1000BASE-Tでタグつきフレームを通信させる場合の最大スループットは、上表の最右列の値を1Gbps倍して、それぞれ972.8 Mbps, 987.0 Mbps, 992.2 Mbpsと得る。
スイッチ性能としてのスループットは、pps (パケット毎秒)で表現することもあり、
で得られる。1Gbps通信の最短フレームの場合、 = 1488095 ppsと得られ、この値がベンチマークテストに用いられる, Annex A.1. Ethernet。
異常なフレーム IETFではと呼ばれるLAN管理機能を規定しており、その一環としてフレームの統計情報の収集機能では異常な書式のフレームを定義している, Section 5. Definitions。主な異常フレームには以下のようなものがある。
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バスで通知し、これを検出・計上するものがある。
脚注
注釈
出典