信号からフレームへ — ビット列をどこで区切るか

実際のEthernetフレームの構造を、先頭から並べます。

フィールド            オクテット   役割
プリアンブル              7        受信側を送信側の刻みに同期させる
SFD                       1        区切りの確定「次から本体」
宛先MACアドレス           6        ここからが「フレーム」
送信元MACアドレス         6
(802.1Qタグ)             (4)       VLAN使用時のみ
タイプ/長さ               2        中身のプロトコル種別
ペイロード            46-1500      運ばれるデータ(タグ付き時 42-1500)
FCS                       4        伝送誤りの検査
フレーム間ギャップ        12        次のフレームとの間隔

注目してほしいのは先頭の2つ、プリアンブルとSFDです。この8オクテットが、先ほどの2つの問題に順番に答えています。

プリアンブルの7オクテットは 10101010 の繰り返しです。0と1が規則正しく交互に現れるので、受信側は「相手は今このくらいの速さで刻んでいる」と読み取りタイミングを合わせ込めます。これが同期(クロック回復)です。ただしこれは古典的な10Mb/sのEthernetでの説明です。より高速な規格の物理層で、同期をどこまでプリアンブルに頼っているかは、本教材は IEEE 802.3 本文で確認できていません。

ただし同期はできても、区切りはまだ決まりません。 10101010 を7回繰り返した信号は、どの周期も全く同じ見た目だからです。「交番している最中だ」とは分かっても、「その何番目にいるのか」は判別できません。区切りが決まるのは、次の1オクテットを見た瞬間です。

10101010 10101010 10101010 10101010 10101010 10101010 10101010  ← プリアンブル(7オクテット)
10101011                                                        ← SFD(1オクテット)
     ^
     ここだけ 0 ではなく 1。交番パターンが破れる
     → 「次のビットから宛先MACアドレス」と確定

SFDのパターンは 10101011 で、プリアンブルと違うのは末尾の1ビットだけです。ずっと ...0 で終わっていた並びが、ここで初めて ...1 で終わる。この「期待が裏切られる瞬間」が合図になります。

もう1つ、区切りの話に直結する数え方の問題があります。Ethernetには最小フレームサイズ64オクテットという制約がありますが、この64がどこからどこまでなのかは、意外と取り違えられています。

答えは宛先MACアドレスからFCSまでです。プリアンブルとSFDの8オクテットは含みません。

プリアンブル(7) + SFD(1)     含まない  ← 本体を読むための「助走」
宛先MAC(6) + 送信元MAC(6)     含む
タイプ/長さ(2)                含む
ペイロード(最小46)            含む
FCS(4)                        含む
                            ─────
                            6+6+2+46+4 = 64

Linuxカーネルの定数がこの数え方を裏づけています。include/uapi/linux/if_ether.h の ETH_ZLEN は60(FCSを除いた最小)で、FCSの4オクテットを足すと64です。RFC 2544 が挙げるベンチマーク用のサイズ列 64, 128, 256, 512, 1024, 1280, 1518 も同じ数え方です。

つまりプリアンブルとSFDはフレームの一部として数えられていません。区切りを見つけるための仕掛けは、区切られた中身そのものには含まれない、という線引きです。

上限も見ておきます。1つのフレームで運べるペイロードの最大長が 1500オクテット、これをMTU(最大転送単位)と呼びます。近い数字が複数あって混乱しやすいので整理します。

値      範囲                              カーネル定数
1500    ペイロードのみ                    ETH_DATA_LEN
1514    ヘッダ14 + ペイロード(FCS除く)     ETH_FRAME_LEN
1518    上記 + FCS 4

「MTU 1500にヘッダが含まれる」という誤解がありますが、1500はペイロードだけです。どこで規定されているかははっきり辿れ、RFC 894 は「the maximum length of an IP datagram sent over an Ethernet is 1500 octets」と述べ、RFC 3635 も「The defined standard MTU for ethernet-like interfaces is 1500 octets」としています。

ただし条件が変わると数字も変わります。802.3 の LLC/SNAP を使う構成では上限が 1492 になり、RFC 1042 はこの値が1500と等しくないことをわざわざ注意しています。規格文書が念を押すほど取り違えられやすい箇所です。

なお1500を超えるジャンボフレーム(9000オクテットが多い)はIEEE 802.3 の標準に含まれません。対応機器は珍しくありませんが、9000という値も業界の慣行です。「規格で決まっているのだから経路途中の機器も対応しているはず」と考えると、1台の非対応機器で通信が成立しなくなります。