イーサネットフレーム

イーサネットフレーム︵英語: Ethernet frame︶は、有線LAN規格のイーサネットによる通信で処理されるデータ書式のこと。﹁MACフレーム﹂とも。イーサネットの通信データ処理部はMACと呼び、これはOSI参照モデルの第2層にあたるデータリンク層に位置する。データリンク層プロトコルでのデータ単位(PDU)を一般に﹁フレーム﹂と呼ぶ。通信はイーサネットの各種物理層規格における物理信号を利用し、物理層パケットの内部にイーサネットフレームが含まれた形で送受される^[1]。フレーム送付の前に、送信開始の合図としてプリアンブルとSFDと呼ぶ信号を送る。フレームの先頭には宛先と送信元のMACアドレスがあり、ネットワーク機器による転送処理判断に使われる。フレームの中央にペイロードがあり、任意の主データが配置できる。フレーム末尾にはフレームチェックシーケンス(FCS)があり、転送中のデータ破損を検出することができる。なお、以降では﹁バイト﹂の語を8ビット(1オクテット)の意味として用いる。

構造

イーサネットフレームとそれを含む物理層パケットは、バイナリデータで構成されている。IEEE 802.3では以下の図表に示すフレーム構造を規定している^[1]。データは図の左・表の上から順に送信されるが、各バイト内では最下位ビット(LSB)を最初に送る^[注釈1]。

イーサネットの物理層パケット。プリアンブルとSFDを除いた部分がイーサネットフレーム

イーサネットの物理層パケットとフレームの構造
内容	サイズ[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

物理層パケットは、イーサネットフレームを送る前に以下の信号から始まる^[注釈2]。 ●7バイトのプリアンブル (preamble, ﹁前置き﹂の意) ●1バイトのSFD (start frame delimiter, ﹁フレーム開始の区切り目﹂の意) これらの伝送路上のビットパターンは以下のようになる^[3]。ここでは左のビットから順に送信される形で記載した^[注釈3]。

10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011

プリアンブルではビットの交互パターン10を連続させており、受信側はこれによりビットレベルで容易に同期できる。その後のSFDではこの交互パターンの最後が崩れて11となり、受信側はこれによりバイトレベルで同期しながらフレームの開始を検出できる^[4]。なお、これらの信号はLSBが先頭となる十六進表現を使うことがある。特にPHY (物理層デバイス)・MAC (データリンク層デバイス)間の並列バスであるMIIを経由する場合などでは、以下のように表す。

●100Mbps通信のMIIは4並列バスのため、ニブル値(4ビット値)表現で、プリアンブルは14個の0x5、SFDは0x5 0xDの順となる。 ●1Gbps通信のGMIIは8並列バスのため、バイト値(8ビット値)表現で、プリアンブルは7個の0x55、SFDは0xD5となる。

イーサネットヘッダ

フレーム先頭の以下の欄を﹁イーサネットヘッダ﹂または﹁MACヘッダ﹂と呼ぶ^[5]^[6]。 ●宛先と送信元のMACアドレス (6バイト+6バイト) ●VLANタグ (Qタグは4バイト、Q-in-Qタグは8バイト) - オプションであり必須ではない。 ●タイプ/長さ (2バイト) - 詳細は次節レイヤ2スイッチ(MACブリッジ)はヘッダの内容を見て転送処理を行っている。その処理動作はIEEE 802.1Dで最初に規定され、その後の改版でIEEE 802.1Qに引き継がれている。MACアドレスは、フレームの転送先を判断したり、送信元を記録したりするのに用いる。VLANタグでは、所属するLANと優先度︵QoS︶が示され、同様に転送先や転送タイミングの判断に用いる。

詳細は「MACアドレス」および「VLAN#フレーム書式」を参照

タイプ/長さ

タイプ/長さの欄は、用途が2種類ある^[7]。 ●この値が1536︵0x0600︶以上の場合は、EtherTypeと解釈される。 ●この値が1500︵0x05DC︶以下の場合は、ペイロード長と解釈される。 1500と1536の間の値は未定義。ほとんどのイーサネットフレームがEtherTypeを用いる。EtherTypeは、ペイロード欄にカプセル化されているデータが何のプロトコルかを示すもので、例えば0x0800はIPv4パケット、0x0806はARPフレーム、0x86DDはIPv6フレーム、0x8100はVLANタグつきフレームを表す^[8]。このときフレーム長は明示されていないが、FCSやEOFなどによってフレーム末尾を検出することでフレーム長がわかるようになっている。ペイロード長を用いるフレームの実例については#種類の節を参照のこと。

ペイロード

ペイロードは﹁MACクライアントデータ﹂とも呼び、通信に使う主データを配置する。任意のプロトコルを配置することができ、多くの場合は第3層にあたるIPパケットのデータがIPヘッダを含んだ形で格納される。最小ペイロード長は、VLANタグがある場合は42バイト、ない場合は46バイトである。この値は、フレーム長が最低64バイトになるように設定されており、初期イーサネットでのCSMA/CDの衝突検出にかかる時間によって決まった^[9]。実際のペイロードが最小ペイロード長よりも短い場合は、最小ペイロード長になるまでパディングされる^[注^釈4]。最大ペイロード長は初期には1500バイトと規定されていたが、1998年にIEEE 802.3acでVLANタグ対応のため1504バイト^[11]、2006年にIEEE 802.3asで1982バイトに拡張されている^[12]。規格外の独自仕様であるジャンボフレームでは、さらに大きなペイロード長に対応できる実装もある。

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

フレームチェックシーケンス (FCS) は、送信側がフレーム末尾につける4バイト値で、これにより受信側でフレーム全体のデータ破損を検出して破棄することができる。また、受信側でペイロード長がわからなくてもFCSを検証することでフレームの末尾がわかるようになる^[13]^[14]。 FCSの値は、32ビットの巡回冗長検査 (CRC) であり、イーサネットフレームからFCS欄を除いた部分︵送信元MAC・宛先MAC・長さ/タイプ・ペイロード︶を入力として計算する。この計算ではCRC-32の標準多項式0x04C11DB7を用いる。CRCの値は、最上位ビット (ビット31) を最初に、最下位ビットを最後に送信するようにFCS欄に割り付けられる^[15]。このフレーム受信時には、CRCを同様に計算し、フレーム内のFCSと比較するものとしている^[16]。上記の規定と等価な実装方法として、以下のようなアレンジが施されることがある。

CRCの実装に使われる値
算出方法	順方向(左シフト)	逆方向(右シフト)
CRC多項式	`0x04C11DB7`	`0xEDB88320`
CRC検証値	`0x38FB2284`	`0x2144DF1C`
CRC検証値の補数	`0xC704DD7B`	`0xDEBB20E3`

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

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

フレームの終わり (EOF: end of a frame) は通常、物理層でのデータストリームの終了シンボルやキャリア信号の消失によって示される。特に、リンク確立中のアイドリング信号(継続的なキャリア)が常に送信されるような物理層規格では、明示的にend of dataまたはend of streamのシンボルやシーケンスを使うことがある。 ●10BASE-Tでは、受信側はキャリアの消失によって送信されたフレームの終わりを検出する。 ●1000BASE-X (8b/10bによる1Gbps通信)では、フレーム送信前後に特殊シンボルを送信する^[18]^[19]。

パケット間隔

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

種類

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

イーサネットフレームの種類
種類	タイプ/長さ欄の値	ペイロードの先頭2バイト	備考
Ethernet II^{[注釈 5]}	≥ 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仕様とも呼ぶ^[21]。1979年の仕様公開から事実上の標準として広く普及していたが、1997年のIEEE 802.3xで正式に標準化され、この欄をタイプ/長さとして併用することが明記された^[22]。

最も一般的な Ethernet IIフレーム (DIXフレーム)

この書式以外の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通信がイーサネット通信のほとんどを占めていた^[23]。

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	プロトコルID	ペイロード
6バイト	6バイト	2バイト	1バイト `AA`	1バイト `AA`	1-2バイト	3バイト	2バイト	任意バイト

1987年にリリースされたMac OSのEthertalkでこの書式を使用していた。 1988年のRFC 1042では、IEEE 802.2 LLCのSAP/SNAPフレームに、IPv4通信をカプセル化する仕様が規定された^[24]。FDDI・トークンリング・IEEE 802.11︵EtherTypeを使用する5.9 GHz帯域を除く︶^[25]などで使用されているが、イーサネットではほとんど実装されていない。同様に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 (パケット毎秒)で表現することもあり、回線速度 ÷ 8 ÷ (物理フレーム長 + パケット間隔長) で得られる。1Gbps通信の最短フレームの場合、1G / 8 / 84 = 1488095 ppsと得られ、この値がベンチマークテストに用いられる^[26]。

異常なフレーム

IETFではRMON︵英語版︶と呼ばれるLAN管理機能を規定しており、その一環としてフレームの統計情報の収集機能では異常な書式のフレームを定義している^[27]。主な異常フレームには以下のようなものがある。 ●CRC不一致受信フレームのFCSの値がCRCの算出値に一致しないもの。CRC Alignmentエラーとして計上される。 ●ラントフレーム(runt frame) 最小フレーム長である64バイトより短いもの。CRCが一致するものはUndersize (不足フレーム)、しないものはFragment (途切れたフレーム)として計上される。後者は一般にコリジョン(衝突)によって発生する。その他の考えられる原因として、ネットワークカードの誤動作、バッファアンダーラン、デュプレックスの不一致、ソフトウェアの不具合がある^[28]。 ●長すぎるフレーム最大フレーム長(主に1522バイト)を超えるもの。CRCが一致するものはOversize (超過フレーム), しないものはJabber (饒舌の意)として計上される。前者はジャンボフレームやVLANタグフレームに未対応の機器でそれらのフレームを受信した場合など、後者はフレームの終了を通知・検出できない回路異常などが考えられる。 ●タイプ/長さが未定義値のもの (1501～1535または0～41) ●物理層パケットの異常フレーム終了時の受信ビット数が8の倍数にならない異常や、物理信号が物理層で定義されたシンボルとして認識できない異常などが発生した場合に、PHYがRX_ER通知をMIIバスで通知し、これを検出・計上するものがある。

脚注

[脚注の使い方]

注釈

(一)^ FCSを除く^[2]。 (二)^ プリアンブルとSFDは、LANアナライザでは表示されない。LANアナライザがレイヤ2に渡されたデータ収集する前に、レイヤ1でNICがこれらを取り除いてしまうためである。プリアンブルとSFDが表示可能なレイヤ2キャプチャを使えば物理的な接続問題の検出もできるがこれは高価である。 (三)^ IEEE 802.3規格書4.2節の記載と同じ。LSBが先頭になるバイト値表現とは異なる点に注意。 (四)^ VLANタグがある場合、42および46バイトの最小値の両方が有効である^[10]。 (五)^ "Ethernet I" (イーサネットバージョン1)は8ビットのMACアドレスを使う初期プロトタイプだったが、商用として用いられなかった。

出典

(一)^ ^a ^bIEEE 802.3-2022 ^:section 3.^1.1 (二)^ IEEE 802.3-2022, section 3.3, annex 31A (三)^ 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 (四)^ IEEE 802.3-2022^{:section 4.2.5} (五)^ “イーサネットヘッダ”. IT用語辞典 e-Words. 2023年12月12日閲覧。 (六)^ “IPアドレスとMACアドレスをひも付ける、﹁ARP﹂プロトコルの動きを完全図解”. 日経クロステック. 2023年12月12日閲覧。 (七)^ IEEE 802.3-2022 ^:§3.2.6 (八)^ “IEEE 802 Numbers”. IANA (2015年10月6日). 2023年12月12日閲覧。 (九)^ IEEE 802.3-2022^{:Annex B.1.2,}^B.1.3 (十)^ IEEE 802.1Q-2022^{:Annex G.2.3} (11)^ “IEEE P802.3ac VLAN TAG Task Force”. 2023年12月12日閲覧。 (12)^ “IEEE P802.3as Frame Expansion Task Force”. 2023年12月12日閲覧。 (13)^ “Cyclic Redundancy Check” (PDF). hackersdelight.org (2009年7月28日). 2015年5月3日時点のオリジナルよりアーカイブ。2015年6月2日閲覧。 (14)^ Nanditha Jayarajan (2007年4月20日). “Configurable LocalLink CRC Reference Design” (PDF). xilinx.com. p. 14. 2014年6月30日閲覧。 (15)^ IEEE 802.3-2022^{:section 3.2.9} (16)^ IEEE 802.3-2022^{:section 4.2.4.}^1.2 (17)^ “Specification of CRC Routines V4.5.0 R4.1 Rev 3”. AUTOSAR. p. 24. 2023年12月11日閲覧。 (18)^ Charles E. Spurgeon (February 2000). Ethernet: The Definitive Guide. O'Reilly. pp. 41, 47 2014年6月30日閲覧。 (19)^ IEEE 802.3-2022^:§40.1.3.1 (20)^ IEEE 802.3-2022^{:Section 4.2.3.}² (21)^ Drew Heywood; Zubair Ahmad (2001). Drew Heywood's Windows 2000 Network Services. Sams. p. 53. ISBN 0-672-31741-9 (22)^ IEEE 802.3x-1997. IEEE (23)^ Don Provan (17 September 1993). "Ethernet Framing". Newsgroup: comp.sys.novell. Usenet: 1993Sep17.190654.13335@novell.com。 (HTML-formatted version Archived 18 April 2015 at the Wayback Machine.) — 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. (24)^ A Standard for the Transmission of IP Datagrams over IEEE 802 Networks (英語). February 1988. doi:10.17487/RFC1042. RFC 1042。 (25)^ IEEE 802.11-2016 (26)^ RFC 5180, Annex A.1. Ethernet (27)^ RFC 2819, Section 5. Definitions (28)^ “Troubleshooting Ethernet”. Cisco Systems. 2016年8月13日閲覧。

[1]

[注釈1]

[注釈2]

[3]

[注釈3]

[4]

[5]

[6]

[7]

[8]

[9]

[注

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[注釈 5]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[2]

[10]