コンテンツにスキップ

「イーサネットフレーム」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集
削除された内容 追加された内容
ビジュアルウィキテキスト
m →構造: 脚注を編集 (ProveIt使用)。スタイル調整。空白調整。 [fmt]
m Bot作業依頼#Cite webテンプレートのdeadlink、deadlinkdate引数の移行
 
(4人の利用者による、間の4版が非表示)
1行目: 1行目:
'''イーサネットフレーム'''（{{lang-en|Ethernet frame}}）は、有線[[LAN]]規格の[[イーサネット]]による通信で処理されるデータ書式のこと。「MACフレーム」とも。
[[コンピュータネットワーク]]において、'''イーサネットフレーム'''（{{lang-en|Ethernet frame}}）とは、[[イーサネット]]における[[フレーム (ネットワーク)|フレーム]]であり、[[データリンク層]]の[[Protocol Data Unit|プロトコルデータユニット]]である。イーサネットフレームは、基礎となる{{仮リンク|イーサネット物理層|en|Ethernet physical layer}}の転送機構を使用して転送される。つまり、イーサネットリンク上の[[パケット]]は、[[ペイロード (コンピュータ)|ペイロード]]としてイーサネットフレームを転送する<ref name="IEEE 802.3 Clause 3.1.1">{{cite web
| url = https://ieeexplore.ieee.org/document/7428776/
| title = 3.1.1 Packet format | work = IEEE Standard for Ethernet, 802.3-2015 – section one
| year = 2016
| accessdate = 2018-04-12
| page = 108 | format = PDF
| url-access = registration
}}</ref>。


イーサネットの通信データ処理部は[[媒体アクセス制御|MAC]]と呼び、これは[[OSI参照モデル]]の第2層にあたる[[データリンク層]]に位置する。データリンク層プロトコルでのデータ単位([[Protocol Data Unit|PDU]])を一般に「[[フレーム (ネットワーク)|フレーム]]」と呼ぶ。通信はイーサネットの各種[[イーサネット#物理層の規格仕様|物理層規格]]における物理信号を利用し、[[#物理層パケット|物理層パケット]]の内部にイーサネットフレームが含まれた形で送受される<ref name="802.3_3.1.1">IEEE 802.3-2022 {{rp|section 3.1.1}}</ref>。
イーサネットフレームの前には、[[プリアンブル]]と開始フレーム識別子（SFD: start frame delimiter）が続く。これらは[[物理層]]のイーサネットパケットの一部である。各イーサネットフレームはイーサネットヘッダで始まる。イーサネットヘッダの最初の2つのフィールドは宛先と送信元の[[MACアドレス]]である。フレームの中央部はペイロードデータである。ペイロードデータには、フレームで伝送される他のプロトコル（[[Internet Protocol]]など）の任意のヘッダを含む。フレームは、[[Frame Check Sequence|フレームチェックシーケンス]](FCS)で終わる。これは、データの転送中の破損を検出するために使用される32ビットの[[巡回冗長検査]](CRC)である。

フレーム送付の前に、送信開始の合図として[[#プリアンブル|プリアンブル]]と[[#SFD|SFD]]と呼ぶ信号を送る。フレームの先頭には宛先と送信元の[[MACアドレス]]があり、ネットワーク機器による転送処理判断に使われる。フレームの中央にペイロードがあり、任意の主データが配置できる。フレーム末尾には[[Frame Check Sequence|フレームチェックシーケンス]](FCS)があり、転送中のデータ破損を検出することができる。

なお、以降では「[[バイト (情報)|バイト]]」の語を8ビット(1[[オクテット (コンピュータ)|オクテット]])の意味として用いる。


==構造==
==構造==
イーサネットフレームとそれを含む[[#物理層パケット|物理層パケット]]は、バイナリデータで構成されている。[[IEEE 802.3]]では以下の図表に示すフレーム構造を規定している<ref name="802.3_3.1.1" />。データは図の左・表の上から順に送信されるが、各バイト内では[[最下位ビット]](LSB)を最初に送る{{efn|[[frame check sequence|FCS]]を除く<ref>IEEE 802.3-2022, section 3.3, annex 31A</ref>。}}。
{{See also|en:Physical Coding Sublayer|物理符号化サブレイヤ}}
伝送路上のデータパケットとそのペイロードとしてのフレームは、バイナリデータで構成されている。イーサネットは最上位[[オクテット (コンピュータ)|オクテット]]を先頭にしてデータを送信する。ただし、各オクテット内では、最下位[[ビット]]が最初に送信される{{efn|[[frame check sequence|フレームチェックシーケンス]] (FCS) は異なるビット順序を使用する。<ref>{{Cite web |url=http://standards.ieee.org/findstds/standard/802.3-2012.html |title=802.3-2012 – IEEE Standard for Ethernet |accessdate=2014-02-09 |date=2012-12-28 |format=PDF |website=ieee.org |publisher=IEEE Standards Association |quote=Opcodes are transmitted high-order octet first. Within each octet, bits are transmitted least-significant bit first. […] Each octet of the MAC frame, with the exception of the FCS, is transmitted least significant bit first. |at=section 3.3, annex 31A}}</ref>}}。


[[File:ethernet frame.svg|thumb|center|600px|イーサネットの物理層パケット。プリアンブルとSFDを除いた部分がイーサネットフレーム]]
イーサネットフレームの内部構造は、IEEE 802.3に規定されている<ref name="IEEE 802.3 Clause 3.1.1" />。以下の表は、[[Maximum Transmission Unit|MTU]]が1500オクテットまでのペイロードサイズについて、送信されたときのイーサネットパケットと内部のフレームを示している{{Efn|プリアンブルとSFDの先頭のビットパターンは、左側に記載している方から送信されるビット列として記載している（最下位ビットからは送信されるオクテット値としてではない）。この表記は、IEEE 802.3規格で使用されているものと一致する。}}。[[ギガビットイーサネット]]などの高速イーサネットの実装では、[[ジャンボフレーム]]と呼ばれるより大きなフレームに対応している。


{| class="wikitable" style="text-align: center;"
{| class="wikitable" style="text-align:center; margin:0 auto;"
|+ 802.3イーサネットのパケットとフレームの構造
|+ イーサネットの物理層パケットとフレームの構造{{anchors|物理層パケット}}
|-
! 内容 !! サイズ[Byte] !! colspan=2 | 範囲
|-
| [[#プリアンブル|プリアンブル]] || 7 || rowspan=2 | || rowspan=8 style="background-color:#fdd;" | ↑<br/>物理層パケット<br/>(72–1534)<br/>↓
|-
| [[#SFD|SFD]] || 1
|-
| [[#イーサネットヘッダ|宛先MACアドレス]] || 6 || rowspan=6 style="background-color:#fdd;" | ↑<br/>イーサネットフレーム<br/>(64–1526)<br/>↓
|-
| [[#イーサネットヘッダ|送信元MACアドレス]] || 6
|-
| ([[#イーサネットヘッダ|VLANタグ]]) || (4 or 8)
|-
|-
| [[#タイプ/長さ|タイプ/長さ]] || 2
! レイヤ !! プリアンブル !! SFD !! 送信先MAC !! 送信元MAC !![[IEEE 802.1Q|802.1Q]]タグ（オプション） !! [[EtherType]] ([[#Ethernet II|Ethernet&nbsp;II]]) /長さ ([[IEEE&nbsp;802.3]]) !! ペイロード !! [[Frame Check Sequence|フレームチェックシーケンス]]（32ビット[[巡回冗長検査|CRC]]） !! [[パケット間隔]] (IPG)
|-
|-
| [[#ペイロード|ペイロード]] || 46-1500
|
| 7&nbsp;octets || 1&nbsp;octet || 6&nbsp;octets || 6&nbsp;octets || (4&nbsp;octets) || 2&nbsp;octets || {{nowrap|46–1500 octets}} || {{nowrap|4 octets}} || 12&nbsp;octets
|-
|-
| [[#FCS|FCS]] || 4
| L2<br/>イーサネットフレーム
| colspan="2" | || colspan="6" style="background:#fdd;"| {{nowrap|← 64–1522 octets →}} ||
|-
|-
| L1<br/>イーサネットパケット & IPG
| [[#IFG|パケット間隔]] || 12
| colspan="8" style="background:#fdd;"| {{nowrap|← 72–1530 octets →}} || style="background:#fdd;" | {{nowrap|← 12 octets →}}
|}
|}


ここでは[[Maximum Transmission Unit|MTU]]が1500バイト以下のペイロード長を持つものを示した。[[ギガビットイーサネット]]以降では、[[ジャンボフレーム]]と呼ばれるさらに大きなフレームの対応を実装した製品もある。
オプションの802.1Qタグは、フレーム内の追加スペースを消費する。このオプションのフィールドサイズは上記の表の括弧内に示されている。{{仮リンク|IEEE 802.1ad|en|IEEE 802.1ad}} (Q-in-Q) では、1つのフレーム内に複数のタグを含めることができる。上記の表にはこのオプションは示されていない。


また、VLANタグはオプションとして括弧で示しており必須ではない。通常は4バイトであるが、[[VLAN#二重タグ|二重タグ]]の場合は8バイトとなる。
=== {{Anchors|イーサネットパケット}}イーサネットパケット（物理層） ===


==== {{Anchors|SFD}}プリアンブルと開始フレーム識別子 ====
=== {{Anchors|プリアンブル|SFD|プリアンブルと開始フレーム識別子}}プリアンブルとSFD ===
[[File:ethernet frame.svg|thumb|right|upright=2.6|イーサネットパケット内のイーサネットフレーム。SFDはパケットのプリアンブルの終わりとフレームの始まりを示す<ref name="802.3-2012" />。]]
{{See also|プリアンブル}}


[[#物理層パケット|物理層パケット]]は、イーサネットフレームを送る前に以下の信号から始まる{{Efn|プリアンブルとSFDは、[[LANアナライザ]]では表示されない。LANアナライザがレイヤ2に渡されたデータ収集する前に、レイヤ1で[[ネットワークカード|NIC]]がこれらを取り除いてしまうためである。プリアンブルとSFDが表示可能なレイヤ2キャプチャを使えば物理的な接続問題の検出もできるがこれは高価である。}}。
イーサネットパケットは、7オクテットの[[プリアンブル]]と1オクテットの開始フレーム識別子（SFD: start frame delimiter）で始まる{{Efn|プリアンブルと開始フレーム識別子は、[[LANアナライザ]]では表示されない。LANアナライザがデータを収集するOSIレイヤ2に渡される前に、これらのビットがOSIレイヤ1で[[ネットワークカード]] (NIC) によって取り除かれるためである。プリアンブルと開始フレーム識別子をキャプチャして表示することができるレイヤ2キャプチャもあるが、それらは高価であり、主に物理的な接続性に関連する問題を検出するために使用される。}}。プリアンブルは、1と0のビットが交互に現れる56ビット（7バイト）のパターンで構成されているため、ネットワーク上のデバイスは受信クロックを簡単に同期させて、ビットレベルの同期をとることができる。その後に続くSFDで、バイトレベルの同期を提供し、新しい着信フレームをマークする。大きなシンボルの代わりにシリアルビットを送信するイーサネットの変種では、プリアンブルの（コード化されていない）伝送路上のビットパターンは、フレームのSFD部分と合わせて<code>10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011</code>となり<ref name="802.3-2012">{{Cite web |url=http://standards.ieee.org/findstds/standard/802.3-2012.html |title=802.3-2012 – IEEE Standard for Ethernet |accessdate=2014-02-09 |date=2012-12-28 |format=PDF |website=ieee.org |publisher=IEEE Standards Association}}</ref>{{rp|sections 4.2.5 and 3.2.2}}、ビットは左から右へ順番に送信される<ref name="802.3-2012">{{Cite web |url=http://standards.ieee.org/findstds/standard/802.3-2012.html |title=802.3-2012 – IEEE Standard for Ethernet |accessdate=2014-02-09 |date=2012-12-28 |format=PDF |website=ieee.org |publisher=IEEE Standards Association}}</ref>{{rp|sections 4.2.5}}。


* 7バイトの'''[[プリアンブル]]''' (preamble, 「前置き」の意)
SFDは8ビット（1バイト）の値で、イーサネットパケットの最初のフィールドであるプリアンブルの終わりと、イーサネットフレームの始まりを示す。SFDはプリアンブルのビットパターンを崩し、実際のフレームの開始を知らせるように設計されている<ref name="802.3-2012" />{{rp|section 4.2.5}}。SFDの直後に宛先[[MACアドレス]]が続く。宛先MACアドレスは、イーサネットフレームの最初のフィールドである。SFDは二進数シーケンス<code>10101011</code>（イーサネットLSBの最初のビット順序で<code>0xD5</code>、10進<code>213</code>）である<ref name="802.3-2012" />{{rp|sections 3.2.2, 3.3, 4.2.6}}。
* 1バイトの'''SFD''' (start frame delimiter, 「フレーム開始の[[区切り文字|区切り目]]」の意)


これらの伝送路上のビットパターンは以下のようになる<ref>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</ref>。ここでは左のビットから順に送信される形で記載した{{Efn|IEEE 802.3規格書4.2節の記載と同じ。[[最下位ビット|LSB]]が先頭になるバイト値表現とは異なる点に注意。}}。
イーサネットMACを物理媒体に接続するには、物理層トランシーバ回路（[[PHY (チップ)|PHY]]）が必要である。PHYとMACとの間の接続は物理媒体とは無関係であり、媒体独立インターフェース（[[media-independent interface|MII]]、GMII、RGMII、SGMII、XGMII）のバスを使用する。[[100メガビット・イーサネット|ファストイーサネット]]トランシーバチップはMIIバスを使用する。これは4ビット（1[[ニブル]]）幅のバスであるため、プリアンブルは14個の0x5として表され、SFDは（ニブルとして）<code>0x5 0xD</code>となる。[[ギガビットイーサネット]]トランシーバチップは8ビット幅のインターフェイスであるGMIIバスを使用するので、プリアンブルとSFDは<code>0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xD5</code>（バイト単位）になる。
{{center|<code>10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011</code>}}


プリアンブルではビットの交互パターン<code>10</code>を連続させており、受信側はこれによりビットレベルで容易に同期できる。その後のSFDではこの交互パターンの最後が崩れて<code>11</code>となり、受信側はこれによりバイトレベルで同期しながらフレームの開始を検出できる<ref>IEEE 802.3-2022{{rp|section 4.2.5}}</ref>。
===フレーム（データリンク層）===


なお、これらの信号は[[最下位ビット|LSB]]が先頭となる[[十六進法|十六進表現]]を使うことがある。特に[[PHY]] (物理層デバイス)・[[媒体アクセス制御|MAC]] (データリンク層デバイス)間の並列バスである[[Media-independent_interface|MII]]を経由する場合などでは、以下のように表す。
====ヘッダ====
* [[100メガビット・イーサネット|100Mbps通信]]の[[Media-independent_interface|MII]]は4並列バスのため、ニブル値(4ビット値)表現で、プリアンブルは14個の<code>0x5</code>、SFDは<code>0x5 0xD</code>の順となる。
ヘッダには、宛先と送信元の[[MACアドレス]]（それぞれ6オクテット）、EtherTypeフィールド、およびオプションで[[IEEE 802.1Q]]タグまたは{{仮リンク|IEEE 802.1ad|en|IEEE 802.1ad}}タグがある。
* [[ギガビットイーサネット|1Gbps通信]]の[[Media-independent_interface#GMII|GMII]]は8並列バスのため、バイト値(8ビット値)表現で、プリアンブルは7個の<code>0x55</code>、SFDは<code>0xD5</code>となる。


===イーサネットヘッダ===
EtherTypeフィールドの長さは2オクテットであり、2つの異なる目的のために使われる。この値が1500以下の場合は、オクテット単位のでペイロードのサイズを意味し、1536以上の場合は、フレームのペイロードにカプセル化されているプロトコルを示す[[EtherType]]として使用されることを示す。EtherTypeとして使用される場合、フレームの長さは[[パケット間隔]]と有効な[[Frame Check Sequence|フレームチェックシーケンス]]（FCS）の位置によって決まる。
フレーム先頭の以下の欄を「イーサネットヘッダ」または「MACヘッダ」と呼ぶ<ref>{{cite web|url=https://e-words.jp/w/%E3%82%A4%E3%83%BC%E3%82%B5%E3%83%8D%E3%83%83%E3%83%88%E3%83%98%E3%83%83%E3%83%80.html|title=イーサネットヘッダ|website=IT用語辞典 e-Words|access-date=2023-12-12}}</ref><ref>{{cite web|url=https://xtech.nikkei.com/atcl/nxt/column/18/01606/032400005/|title=IPアドレスとMACアドレスをひも付ける、「ARP」プロトコルの動きを完全図解|website=日経クロステック|access-date=2023-12-12}}</ref>。


* 宛先と送信元の'''[[MACアドレス]]''' (6バイト+6バイト)
[[IEEE 802.1Q]]タグ、[[IEEE 802.1ad]]タグ（オプション）は4オクテットのフィールドで、[[Virtual Local Area Network|仮想LAN]]のメンバーシップとIEEE 802.1pプライオリティを示す。タグの最初の2オクテットはタグプロトコル識別子 (TPID: Tag Protocol IDentifier) と呼ばれ、フレームが802.1Qまたは802.1adタグ付きであることを示す。802.1Qの場合のTPIDは<code>0x8100</code>、802.1adの場合は<code>0x88a8</code>である。
* '''[[VLAN]]タグ''' ([[タグVLAN|Qタグ]]は4バイト、[[VLAN#二重タグ|Q-in-Qタグ]]は8バイト) - オプションであり必須ではない。
* '''[[#タイプ/長さ|タイプ/長さ]]''' (2バイト) - 詳細は次節


[[レイヤ2スイッチ]](MACブリッジ)はヘッダの内容を見て転送処理を行っている。その処理動作は[[IEEE 802.1D]]で最初に規定され、その後の改版で[[IEEE 802.1Q]]に引き継がれている。MACアドレスは、フレームの転送先を判断したり、送信元を記録したりするのに用いる。VLANタグでは、所属するLANと優先度（[[Quality of Service|QoS]]）が示され、同様に転送先や転送タイミングの判断に用いる。
====ペイロード====
{{main|MACアドレス|VLAN#フレーム書式}}
最小ペイロードサイズは、802.1Qタグが存在する場合は42オクテット、存在しない場合は46オクテットである{{Efn|ペイロードの最小サイズは、イーサネットLANアーキテクチャの[[CSMA/CD|衝突検出]]に使用される512ビットのスロット時間によって決まる。}}。実際のペイロードが最小ペイロードよりも小さい場合は、最小ペイロードサイズになるまでパディングバイトが追加される{{Efn|802.1Qが存在する場合、42および46オクテットの最小値の両方が有効である<ref>IEEE 802.1Q-2011, Annex G</ref>。}}。最大ペイロードサイズは1500オクテットである。非標準の[[ジャンボフレーム]]では、最大ペイロードサイズを大きくすることができる。


=== タイプ/長さ ===
====フレームチェックシーケンス====
タイプ/長さの欄は、用途が2種類ある<ref>IEEE 802.3-2022 {{rp|§3.2.6}}</ref>。
[[Frame Check Sequence|フレームチェックシーケンス]] (FCS) は、受信側でフレーム全体内の破損データの検出を可能にする4オクテットの[[巡回冗長検査]] (CRC) である。FCSの値は、保護されたMACフレームフィールド（送信元アドレスと宛先アドレス、長さ/タイプフィールド、MACクライアントデータ、パディング。つまり、FCS以外の全てのフィールド）の関数として計算される<ref name="802.3-2012" />{{rp|section 3.2.9}}。
* この値が1536（<code>0x0600</code>）以上の場合は、[[EtherType]]と解釈される。
* この値が1500（<code>0x05DC</code>）以下の場合は、ペイロード長と解釈される。


1500と1536の間の値は未定義。
CRCコードを含む受信フレームデータに対してCRCアルゴリズムを実行すると、CRCは多項式で除算されたデータの剰余であるため、エラーのない受信データに対しては常にゼロになる。ただし、この手法ではエラーの検出に失敗する可能性があり、末尾にゼロがあるデータも同じゼロ残差になる。これを回避するために、ペイロードデータの最後に付加される前に送信側によってFCSは[[補数]]が取られる（ビットごとに反転される）<ref name="802.3-2012" />{{rp|section 3.2.9}}。この方法では、データが正しく受信されたとき、アルゴリズムの結果は常に<code>0xC704DD7B</code>（マジックナンバーまたはCRC32剰余と呼ばれる）になる。これにより、FCSフィールドが実際に開始される場所を知らなくても、フレームを受信してFCSを検証することができる<ref>{{Cite web |url=http://www.hackersdelight.org/crc.pdf |title=Cyclic Redundancy Check |accessdate=2015-06-02 |date=2009-07-28 |format=PDF |website=hackersdelight.org |deadlinkdate=May 2018 |archiveurl=https://web.archive.org/web/20150503014404/http://www.hackersdelight.org/crc.pdf |archivedate=3 May 2015}}</ref><ref>{{Cite web |url=http://www.xilinx.com/support/documentation/application_notes/xapp562.pdf |title=Configurable LocalLink CRC Reference Design |accessdate=2014-06-30 |author=Nanditha Jayarajan |date=2007-04-20 |format=PDF |website=xilinx.com |page=14}}</ref>。

ほとんどのイーサネットフレームがEtherTypeを用いる。EtherTypeは、ペイロード欄にカプセル化されているデータが何のプロトコルかを示すもので、例えば<code>0x0800</code>は[[IPv4]]パケット、<code>0x0806</code>は[[Address Resolution Protocol|ARP]]フレーム、<code>0x86DD</code>は[[IPv6]]フレーム、<code>0x8100</code>は[[VLAN]]タグつきフレームを表す<ref name="ethtypes">{{cite web|url=https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1|title=IEEE 802 Numbers|date=2015-10-06|website=|publisher=[[IANA]]|access-date=2023-12-12}}</ref>。このときフレーム長は明示されていないが、[[#FCS|FCS]]や[[#EOF|EOF]]などによってフレーム末尾を検出することでフレーム長がわかるようになっている。

ペイロード長を用いるフレームの実例については[[#種類]]の節を参照のこと。

===ペイロード===
ペイロードは「MACクライアントデータ」とも呼び、通信に使う主データを配置する。任意のプロトコルを配置することができ、多くの場合は第3層にあたる[[Internet Protocol|IP]]パケットのデータがIPヘッダを含んだ形で格納される。

最小ペイロード長は、VLANタグがある場合は42バイト、ない場合は46バイトである。この値は、フレーム長が最低64バイトになるように設定されており、初期イーサネットでの[[CSMA/CD]]の衝突検出にかかる時間によって決まった<ref>IEEE 802.3-2022{{rp|Annex B.1.2, B.1.3}}</ref>。実際のペイロードが最小ペイロード長よりも短い場合は、最小ペイロード長になるまで[[ゼロパディング|パディング]]される{{Efn|VLANタグがある場合、42および46バイトの最小値の両方が有効である<ref>IEEE 802.1Q-2022{{rp|Annex G.2.3}}</ref>。}}。

最大ペイロード長は初期には1500バイトと規定されていたが、1998年に[[IEEE 802.3]]acでVLANタグ対応のため1504バイト<ref>{{cite web|url=https://www.ieee802.org/3/ac/|title=IEEE P802.3ac VLAN TAG Task Force|access-date=2023-12-12}}</ref>、2006年に[[IEEE 802.3]]asで1982バイトに拡張されている<ref>{{cite web|url=https://www.ieee802.org/3/as/|title=IEEE P802.3as Frame Expansion Task Force|access-date=2023-12-12}}</ref>。規格外の独自仕様である[[ジャンボフレーム]]では、さらに大きなペイロード長に対応できる実装もある。

===フレームチェックシーケンス {{anchors|FCS}} ===
[[Frame Check Sequence|フレームチェックシーケンス]] (FCS) は、送信側がフレーム末尾につける4バイト値で、これにより受信側でフレーム全体のデータ破損を検出して破棄することができる。また、受信側でペイロード長がわからなくてもFCSを検証することでフレームの末尾がわかるようになる<ref>{{Cite web |url=http://www.hackersdelight.org/crc.pdf |title=Cyclic Redundancy Check |accessdate=2015-06-02 |date=2009-07-28 |format=PDF |website=hackersdelight.org |archiveurl=https://web.archive.org/web/20150503014404/http://www.hackersdelight.org/crc.pdf |archivedate=2015-05-03 |url-status=dead|url-status-date=May 2018}}</ref><ref>{{Cite web |url=http://www.xilinx.com/support/documentation/application_notes/xapp562.pdf |title=Configurable LocalLink CRC Reference Design |accessdate=2014-06-30 |author=Nanditha Jayarajan |date=2007-04-20 |format=PDF |website=xilinx.com |page=14}}</ref>。

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

上記の規定と等価な実装方法として、以下のようなアレンジが施されることがある。
{| class="wikitable floatright"
|+ CRCの実装に使われる値
! 算出方法
| 順方向(左シフト) || 逆方向(右シフト)
|-
! CRC多項式
| <code>0x04C11DB7</code> || <code>0xEDB88320</code>
|-
! CRC検証値
| <code>0x38FB2284</code> || <code>0x2144DF1C</code>
|-
! CRC検証値の補数
| <code>0xC704DD7B</code> || <code>0xDEBB20E3</code>
|-
|}
* ビット列を逆順にして演算することがある。フレーム内の他の欄はLSBが先頭に来る形式であるため、FCSもこれに合わせてあらかじめビット列を逆順にして右シフトのCRC多項式を用いるほうが効率が良い。
* 受信時に送信側と同じ方法でCRCを算出するのではなく、FCSを含む受信フレーム全体にCRC算出を行うことがある。この結果、エラーがなければ常に同じ非ゼロの値が得られるため、これを「CRC検証値」「CRCマジックチェック」などと呼ぶ<ref>{{cite web|url=https://www.autosar.org/fileadmin/user_upload/standards/classic/4-1/AUTOSAR_SWS_CRCLibrary.pdf#page=24|title=Specification of CRC Routines V4.5.0 R4.1 Rev 3|page=24|publisher=[[AUTOSAR]]|access-date=2023-12-11}}</ref>。
* CRC算出の回路実装では、[[LFSR]]に記録する値は[[補数]]をとらないことがある。この場合は、送信時や取得時に補数変換する必要がある。
これらの方式により、演算に用いる値は右表のようなバリエーションがある。
{{clear}}


=== {{Anchors|EOF|EOD|End of frame}}フレームの終わり（物理層） ===
=== {{Anchors|EOF|EOD|End of frame}}フレームの終わり（物理層） ===
フレームの終わり (EOF: end of a frame) は通常、物理層でのデータストリームの終わりのシンボル、またはキャリア信号の消失によって示される。例えば[[10BASE-T]]では、受信側はキャリアの消失によって送信されたフレームの終わりを検出する。後の仕様の物理層では、特にキャリアがフレーム間で継続的に送信される場合に、曖昧さを避けるために明示的な''end of data''または''end of stream''のシンボルやシーケンスを使用する。例えば[[8b/10b]]によるギガビットイーサネットでは、フレームが送信される前後に特別なシンボルを送信する<ref>{{Cite book |author=Charles E. Spurgeon |title=Ethernet: The Definitive Guide |url=https://books.google.com/books?id=MRChaUQr0Q0C&printsec=frontcover&source=gbs_ge_summary_r&redir_esc=y#v=onepage&q&f=false |date=February 2000 |accessdate=2014-06-30 |publisher=O'Reilly |pages=41, 47}}</ref><ref>{{Cite web |url=http://standards.ieee.org/getieee802/download/802.3-2012_section3.pdf |title=40.1.3.1 Physical Coding Sublayer (PCS) |accessdate=2014-07-06 |date=2012-12-28 |format=PDF |work=IEEE Standard for Ethernet, 802.3-2012 – section three |page=183}}</ref>。
フレームの終わり (EOF: end of a frame) は通常、物理層でのデータストリームの終了シンボルやキャリア信号の消失によって示される。特に、リンク確立中のアイドリング信号(継続的なキャリア)が常に送信されるような物理層規格では、明示的に''end of data''または''end of stream''のシンボルやシーケンスを使うことがある。


* [[10BASE-T]]では、受信側はキャリアの消失によって送信されたフレームの終わりを検出する。
==={{Anchors|Interpacket gap}}パケット間隔（物理層）===
* [[ギガビットイーサネット|1000BASE-X]] ([[8b/10b]]による1Gbps通信)では、フレーム送信前後に特殊シンボルを送信する<ref>{{Cite book |author=Charles E. Spurgeon |title=Ethernet: The Definitive Guide |url=https://books.google.com/books?id=MRChaUQr0Q0C&printsec=frontcover&source=gbs_ge_summary_r&redir_esc=y#v=onepage&q&f=false |date=February 2000 |accessdate=2014-06-30 |publisher=O'Reilly |pages=41, 47}}</ref><ref>IEEE 802.3-2022{{rp|§40.1.3.1}}</ref>。
[[パケット間隔]] (IPG: interpacket gap) は、パケット間のアイドル時間である。パケットが送信された後、送信側は次のパケットを送信する前に最低96ビット（12オクテット）のアイドル状態を維持する必要がある。

==={{Anchors|インターパケットギャップ|インターフレームギャップ|IFG|IPG}}パケット間隔===
[[パケット間隔]]は、 IFG (interframe gap) または IPG (interpacket gap)とも呼ぶ。送信側はフレーム送信終了後に次のフレームを送信するまで最低96ビット（12バイト）のアイドル状態を維持する必要がある。これも[[CSMA/CD]]の物理的制約に基づいて決められている<ref>IEEE 802.3-2022{{rp|Section 4.2.3.2}}</ref>。


==種類==
==種類==
イーサネットフレームには歴史的にいくつかの種類がある。主なものを下表に示したが、現在ではこのうち [[#Ethernet II|Ethernet II]] 以外のものはほとんど使われていない。
{| class="wikitable floatright" style="text-align: center; margin-left: 1.5em; margin-right: 0;"

{| class="wikitable" style="white-space:nowrap;"
|+ イーサネットフレームの種類
|+ イーサネットフレームの種類
|-
|-
! フレームの種類 !! Ethertypeまたは長さ !! ペイロード開始の2バイト
! 種類 !! [[#タイプ/長さ|タイプ/長さ]]<br/>欄の値 !! [[#ペイロード|ペイロード]]の<br/>先頭2バイト !! 備考
|-
|-
| [[#Ethernet II|Ethernet II]]{{Efn|"Ethernet I" (イーサネットバージョン1)は8ビットのMACアドレスを使う初期プロトタイプだったが、商用として用いられなかった。}} || ≥ 1536 || 任意
| Ethernet II || ≥ 1536 || Any
| style="white-space:normal;" | DIX仕様とも。今日最も一般的に使用される。
|-
|-
| Novell raw IEEE 802.3 || ≤ 1500 || 0xFFFF
| [[#ノベルIPXカプセル|ノベルIPXカプセル]] || ≤ 1500 || <code>0xFFFF</code> || ベンダ固有書式。
|-
|-
| IEEE 802.2 LLC || ≤ 1500 || Other
| [[#IEEE 802.2 LLC カプセル|IEEE 802.2 LLC カプセル]] || ≤ 1500 || SAPアドレス || IEEE 802.3初期仕様の1つ。
|-
|-
| IEEE 802.2 SNAP || ≤ 1500 || 0xAAAA
| [[#SNAP|IEEE 802.2 SNAP カプセル]] || ≤ 1500 || <code>0xAAAA</code> || IEEE 802.3初期仕様の1つ。
|}
|}


これら4種はタイプ/長さ欄やペイロード欄の差異によって識別でき、同じ物理媒体上に共存できる。また、いずれもVLANタグがつけられる。
イーサネットフレームにはいくつかの種類がある。


===Ethernet II===
* Ethernet IIフレーム（イーサネットバージョン2{{Efn|イーサネットバージョン1は8ビットのMACアドレスを使用する初期のイーサネットプロトタイプに使われていたが、商用には使用されなかった。}}またはDIXフレームともいう）は、[[Internet Protocol]]で直接使用されることが多い、今日最も一般的に使用されている種類である。
'''Ethernet II'''は、[[#タイプ/長さ|タイプ/長さ]]欄を[[EtherType]]として使うフレーム。
* [[ノベル (企業)|ノベル]] raw [[IEEE 802.3]] non-standard variation frame
* [[IEEE 802.2]] [[論理リンク制御|Logical Link Control]] (LLC) frame
* [[IEEE 802.2]] {{仮リンク|Subnetwork Access Protocol|en|Subnetwork Access Protocol}} (SNAP) frame


[[ディジタル・イクイップメント・コーポレーション|DEC]]・[[インテル|Intel]]・[[ゼロックス|Xerox]]の3社が主に設計・規定したもので、3社の頭文字をとって'''DIX仕様'''とも呼ぶ<ref>{{Cite book |author=Drew Heywood |title=Drew Heywood's Windows 2000 Network Services |year=2001 |publisher=Sams |isbn=0-672-31741-9 |page=53 |author2=Zubair Ahmad}}</ref>。1979年の仕様公開から[[事実上の標準]]として広く普及していたが、1997年の[[IEEE 802.3]]xで正式に標準化され、この欄をタイプ/長さとして併用することが明記された<ref>{{cite book|url=https://standards.ieee.org/ieee/802.3x/1082/ |title=IEEE 802.3x-1997|publisher=IEEE}}</ref>。
異なるフレームタイプは異なるフォーマットと[[Maximum Transmission Unit|MTU]]値を持つが、同じ物理媒体上に共存できる。右の表のようにフレームの種類を区別することができる。


[[Image:Ethernet Type II Frame format.svg|thumb|center|700px|最も一般的な Ethernet IIフレーム (DIXフレーム)]]
さらに、4つのイーサネットフレームの種類全てに、オプションでIEEE 802.1Qタグを含めることができ、それが属するVLANとその優先順位（[[Quality of Service]]）を識別できる。このカプセル化は{{仮リンク|IEEE 802.3ac|en|IEEE 802.3ac}}で定義されており、最大フレームを4オクテット増加させる。


この書式以外の3種はすべてこの欄を長さ(ペイロード長)として使うよう規定されている。この仕様は1983年の[[IEEE 802.3]]初版に基づいており、標準化の際にDIX仕様から変更されたものであるが、1997年の改版時に併用として先祖返りする形となっている。
IEEE 802.1Qタグは、送信元アドレスとEtherType/Lengthフィールドの間に配置される。タグの最初の2オクテットは、タグプロトコル識別子(TPID: Tag Protocol IDentifier)0x8100である。これはタグがない場合のEtherType/Lengthフィールドと同じ場所にあるため、EtherType値が0x8100であることはフレームがタグ付けされていることを意味し、実際のEtherType/Lengthはタグの後ろに配置される。タグの後ろの2オクテットはタグ制御情報(TCI: Tag Control Information)（IEEE 802.1pの優先度（Quality of Service）とVLAN ID）である。タグの後には、上記の種類のいずれかによる、フレームの残りの部分が続く。


===Ethernet II===
===ノベルIPXカプセル ===
ペイロード部分に[[IPX/SPX|IPX]]パケットを置くもの。1983年に[[ノベル (企業)|ノベル]]がIEEE 802.3策定中の仕様をもとにして[[NetWare]]などに独自実装したプロトコルで、1990年代半ばまで使われた。
'''Ethernet IIフレーム'''（設計の主要な参加者である[[ディジタル・イクイップメント・コーポレーション|DEC]]、[[インテル|Intel]]、[[ゼロックス|Xerox]]から'''DIXイーサネット'''ともいう<ref>{{cite book |title=Drew Heywood's Windows 2000 Network Services |author=Drew Heywood |author2=Zubair Ahmad |publisher=Sams |year=2001 |isbn=0-672-31741-9 |page=53}}</ref>）は、宛先・送信元MACアドレスの前に、2オクテットの[[EtherType]]フィールドを定義する。EtherTypeは、[[フレーム (ネットワーク)|フレーム]]データによって[[カプセル化 (通信)|カプセル化]]された上位層プロトコルを識別するのに使用する。例えば、EtherType値0x0800は、フレームに[[IPv4]]データグラムが含まれていることを示す。同様に、0x0806のEtherTypeは[[Address Resolution Protocol|ARP]]フレーム、0x86DDは[[IPv6]]フレームを示し、0x8100は前述の通りIEEE 802.1Qタグの存在を示す。
{| class="wikitable"
|-
!colspan=3|イーサネットヘッダ
!colspan=2|ノベル独自ペイロード
|-
!宛先MAC
!送信元MAC
!長さ
!識別子
!データ
|-
|6バイト
|6バイト
|2バイト
|2バイト<br/><code>0xffff</code>
|任意バイト
|}


長さ欄のすぐ後にIPXパケットが始まる。これは規格準拠ではないが、ペイロードの先頭2バイトを<code>0xFFFF</code>としており、次節の[[#IEEE 802.2 LLC カプセル|IEEE 802.2 LLC カプセル]]でそのパターンになることはごく稀であるため、実用上は他の書式と識別可能だった。ただし、[[DECnet]]の初期の形式では、この仕様が混乱を招いたものがある。
[[Image:Ethernet Type II Frame format.svg|thumb|center|700px|最も一般的なイーサネットフレームのフォーマットであるEthernet II]]


[[Internet Protocol|IP]]普及がまだ進んでいなかった時代は、NetWareでデフォルトだったこの形式によるIPX通信がイーサネット通信のほとんどを占めていた<ref>{{Cite newsgroup |url=https://groups.google.com/group/bit.listserv.novell/browse_thread/thread/d00a24530625714c |title=Ethernet Framing |last=Don Provan |date=17 September 1993 |newsgroup=comp.sys.novell |message-id=1993Sep17.190654.13335@novell.com}} ([http://www.ee.siue.edu/~bnoble/comp/networks/frametypes.html HTML-formatted version] {{webarchive|url=https://web.archive.org/web/20150418013816/http://www.ee.siue.edu/~bnoble/comp/networks/frametypes.html |date=18 April 2015 }}) — 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.</ref>。
この業界標準規格が正式な[[IEEE]]標準化プロセスを経るにつれて、EtherTypeフィールドは新しい802.3標準規格のデータ長フィールドに変更された{{Efn|オリジナルのイーサネットフレームでは、データ長は明示せず、それを囲むフレーミングで長さを定義する。}}。受信者はまだフレームを解釈する方法を知る必要があるので、規格では長さに続いて、タイプを指定するために[[IEEE 802.2]]ヘッダが要求された。何年も後に、802.3x-1997規格、および802.3規格のそれ以降のバージョンでは、両方の種類のフレーミングが正式に承認された。Ethernet IIフレームは、その単純さと低いオーバーヘッドにより、イーサネットLANでは最も一般的である。


===IEEE 802.2 LLC カプセル===
Ethernet IIのフレーミングを使用するフレームとオリジナルの802.3フレーミングを使用するフレームを同じイーサネットセグメントで使用できるようにするには、EtherType値を1536（0x0600）以上にする必要がある。802.3フレームのペイロードフィールドの最大長が1500オクテット（0x05DC）であるため、その値が選択された。従って、フィールドの値が1536以上の場合、フレームはEthernet IIフレームでなければならず、そのフィールドはEtherTypeを表す<ref>{{cite book|author=LAN MAN Standards Committee of the IEEE Computer Society|title=IEEE Std 802.3x-1997 and IEEE Std 802.3y-1997|publisher=The Institute of Electrical and Electronics Engineers, Inc.|date=20 March 1997|pages=28–31}}</ref>。それが1500以下の場合、それはIEEE 802.3フレームでなければならず、そのフィールドは長さを表す。1500と1536の間の値は未定義である<ref>IEEE Std 802.3-2005, 3.2.6</ref>。この規約により、ソフトウェアはフレームがEthernet IIフレームかIEEE 802.3フレームかを判断することができ、同じ物理媒体上で両方の規格を共存させることができる。
ペイロード部分に[[論理リンク制御|LLC]]パケットを置くもの。LLCヘッダには、SAP (service access points) と呼ばれる2つのアドレス値が含まれている。制御バイトの値によって[[コネクションレス型]]・コネクション型の通信モードのどちらでも動作できる。


{| class="wikitable"
===ノベル raw IEEE 802.3===
|-
ノベルのraw 802.3フレームフォーマットは、初期のIEEE 802.3の開発作業に基づくものである。ノベルはこれを出発点として、イーサネットを介した独自の{{仮リンク|Internetwork Packet Exchange|en|Internetwork Packet Exchange|label=IPX|redirect=1}}ネットワークプロトコルの初の実装を作成した。raw 802.3フレームフォーマットでは、LLCヘッダを使用せず、長さフィールドのすぐ後にIPXパケットが開始する。これはIEEE 802.3規格には準拠していないが、IPXでは常に最初の2オクテットを0xFFとするので（IEEE 802.2 LLCでそのパターンになることは理論的にはあり得るが、極めて可能性が低い）、他のイーサネット実装と同じ物理媒体上で共存できる。ただし、[[DECnet]]の初期のいくつかの形式は、この仕様によって混乱している。
!colspan=3|イーサネットヘッダ
!colspan=3|802.2 LLC ヘッダ
!rowspan=2|ペイロード
|-
!宛先MAC
!送信元MAC
!長さ
!宛先SAPアドレス
!送信元SAPアドレス
!制御
|-
|6バイト
|6バイト
|2バイト
|1バイト
|1バイト
|1-2バイト
|任意バイト
|}
この書式は、過去には多くの社内LANでイーサネットと[[トークンリング]]や[[FDDI]]とのトランスペアレント変換[[ブリッジ (ネットワーク機器)|ブリッジ]]に使われたが、現在一般的なネットワークではほとんど使われない。ノベルの[[NetWare]]4.10以降ではデフォルトのIPX通信にも使われたが、ほとんどは[[Internet Protocol|IP]]通信に移行している。


===IEEE 802.2 SNAP カプセル===
ノベルの[[NetWare]]は、1990年代半ばまでデフォルトでこのフレームタイプを使用しており、NetWareが広く普及しIPがまだ普及していなかった頃には、世界のイーサネットトラフィックのほとんどはIPXを伝送するraw 802.3フレームフォーマットを介していた。NetWare 4.10以降、IPXを使用するときのNetWareのデフォルトはLLCによるIEEE 802.2（NetWareフレームタイプEthernet_802.2）である<ref>{{cite newsgroup | author=Don Provan | title=Ethernet Framing | date=17 September 1993 | newsgroup=comp.sys.novell | message-id=1993Sep17.190654.13335@novell.com | url=https://groups.google.com/group/bit.listserv.novell/browse_thread/thread/d00a24530625714c }} ([http://www.ee.siue.edu/~bnoble/comp/networks/frametypes.html HTML-formatted version] {{webarchive|url=https://web.archive.org/web/20150418013816/http://www.ee.siue.edu/~bnoble/comp/networks/frametypes.html |date=18 April 2015 }}) &nbsp;— 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.</ref>。
{{anchors|SNAP}}
'''SNAP''' (Subnetwork Access Protocol)は、IEEE 802.2 LLCを拡張し、特に[[EtherType]]を格納する欄を設けてプロトコルの識別ができるようにしたもの。


LLCヘッダのSAPがともに値<code>0xAA</code>の場合、LLCヘッダの後に以下のようなSNAPヘッダを置くことができる。SNAPヘッダでは、プロトコルID欄にEtherType値を入れることができる。
===IEEE 802.2 LLC===
{{Main|IEEE 802.2}}
[[OSI参照モデル]]用に設計されたプロトコルの中には、コネクション型とコネクションレス型の両方のネットワークサービスを提供するIEEE 802.2 LLCカプセル化の上で直接動作するものもある。


{| class="wikitable" style="white-space:nowrap;"
IEEE 802.2 LLCのカプセル化は、[[Internet Protocol|IP]]を介したNetWareへの移行がまだ完了していない大企業のNetWare環境を除いて、現在、一般的なネットワークでは広く使用されていない。過去には、多くの企業ネットワークで、IEEE 802.2を使用して、イーサネットと[[トークンリング]]や[[FDDI]]ネットワーク間のトランスペアレント変換ブリッジをサポートしていた。
|-
!colspan=3|イーサネットヘッダ
!colspan=3|802.2 LLC ヘッダ
!colspan=2|SNAP拡張
!rowspan=2|ペイロード
|-
!宛先MAC
!送信元MAC
!長さ
!宛先SAP
!送信元SAP
!制御
![[MACアドレス#OUI|OUI]]
!プロトコルID
|-
|6バイト
|6バイト
|2バイト
|1バイト<br/><code>AA</code>
|1バイト<br/><code>AA</code>
|1-2バイト
|3バイト
|2バイト
|任意バイト
|}


1987年にリリースされた[[Mac OS]]の[[AppleTalk|Ethertalk]]でこの書式を使用していた。
IEEE 802.2 LLCのSAP/SNAPフレームに、IPv4トラフィックをカプセル化するためのインターネット標準がある<ref>
{{cite web
| url = http://tools.ietf.org/html/rfc1042
| title = RFC1042: A Standard for the Transmission of IP Datagrams over IEEE 802 Networks
| publisher = Network Working Group of the IETF
| date = February 1988
| access-date = 2019-02-07
}}
</ref>。FDDI、トークンリング、[[IEEE 802.11]]（EtherTypeを使用する5.9 GHz帯域を除く）<ref>{{Cite book|title=IEEE Std 802.11-2016: Part 11: Wireless LAN Medium Access Control IEEE (MAC) and Physical Layer (PHY) Specifications.|last=Computer Society|first=IEEE|publisher=IEEE|year=2016|isbn=|location=New York, NY|pages=249}}</ref>やその他のIEEE 802 LANで使用されているが、イーサネットではほとんど実装されていない。IPv6は、IEEE 802.2 LLC SAP/SNAPを使用してイーサネット経由で送信することもできるが、これもまたほとんど使用されていない。


1988年の{{IETF RFC|1042}}では、IEEE 802.2 LLCのSAP/SNAPフレームに、IPv4通信をカプセル化する仕様が規定された<ref>{{Cite IETF |rfc=1042 |title=A Standard for the Transmission of IP Datagrams over IEEE 802 Networks |date=February 1988}}</ref>。FDDI・トークンリング・[[IEEE 802.11]]（EtherTypeを使用する5.9 GHz帯域を除く）<ref>IEEE 802.11-2016</ref>などで使用されているが、[[イーサネット]]ではほとんど実装されていない。同様にIPv6もIEEE 802.2 LLC SAP/SNAPを用いたイーサネット通信が可能であるが、これもまたほとんど使用されていない。
===IEEE 802.2 SNAP===
{{Main|en:Subnetwork Access Protocol}}
802.2 LLCヘッダを調べることによって、その後にSNAPヘッダが続くかどうかを判断することが可能である。LLCヘッダには、OSIの用語で「サービスアクセスポイント」(SAPs: service access points)と呼ばれる2つの8ビットアドレスフィールドが含まれている。送信元と宛先の両方のSAPが値0xAAに設定されている場合、LLCヘッダの後にSNAPヘッダが続く。SNAPヘッダを使用すると、EtherType値を全てのIEEE 802プロトコルで使用でき、プライベートプロトコルIDスペースにも対応できる。


==最大スループット==
IEEE 802.3x-1997では、MACアドレスの後の16ビットフィールドを長さフィールドまたはタイプフィールドとして使用することを明示的に許可するようにIEEEイーサネット規格が変更された。
イーサネットのスループットは以下の式で表せる。
:{{center|1= スループット = 回線速度 × 伝送効率 }}


ここで、「回線速度」は[[ファーストイーサネット]]なら100Mbps、[[ギガビットイーサネット]]なら1Gbpsなどの物理層規格の値をそのまま採る。一方、「伝送効率」はいくつかの観点で計算されることがあり、いずれも共通の分母を持つ。
[[Mac OS]]は、イーサネット上の[[AppleTalk]] v2プロトコルスイート(EtherTalk)にIEEE 802.2 LLC+SNAPカプセル化を使用する。


*'''ペイロード伝送の効率''' = (ペイロード長) ÷ ([[#物理層パケット|物理層パケット]]長 + パケット間隔長)
==最大スループット==
*: ネットワーク運用効率として示される値。VLANタグの有無によって値が変わる。
イーサネットのプロトコルオーバーヘッドをパーセンテージ（IPGを含むパケットサイズ）として次の式で計算できる。
*'''フレーム伝送の効率''' = (フレーム長) ÷ (物理層パケット長 + パケット間隔長)
:<math>\text{Protocol overhead} = \frac{\text{Packet size} - \text{Payload size}}{\text{Packet size}}</math>
*: [[レイヤ2スイッチ|ネットワークスイッチ]]性能として示される値。[[#イーサネットヘッダ|イーサネットヘッダ]]を含む。
イーサネットのプロトコル効率は次の式で計算できる。
*'''物理層パケット伝送の効率''' = (物理層パケット長) ÷ (物理層パケット長 + パケット間隔長)
:<math>\text{Protocol efficiency} = \frac{\text{Payload size}}{\text{Packet size}}</math>
*: チャネル占有率として示される値。[[#プリアンブル|プリアンブル]]・[[#SFD|SFD]]・[[#イーサネットヘッダ|イーサネットヘッダ]]を含む。


これらの式を用いた伝送効率の計算例を下表に示す。
最大効率は、最大許容ペイロードサイズで達成され、その値は以下のように計算される。
:<math>\frac{1500}{1538} = 97.53\%</math>


{|class="wikitable" style="text-align:right;"
タグなしフレームの場合、パケットサイズは最大ペイロード1500オクテット+プリアンブル8オクテット+ヘッダ14オクテット+トレーラ4オクテット+最小パケット間隔12オクテットに=1538オクテットである。最大効率は以下のように計算される。
! colspan=2 |
:<math>\frac{1500}{1542} = 97.28\%</math>
! 最短フレーム<br/> (タグなし)
! 最短フレーム<br/> (タグつき)
! 最長フレーム<br/> (タグなし)
! 最長フレーム<br/> (タグつき)
|-
! rowspan=2 | サイズ
! ペイロード長
| 46バイト || 42バイト || 1500バイト || 1500バイト
|-
! フレーム長
| 64バイト || 64バイト || 1518バイト || 1522バイト
|-
! rowspan=3 | 伝送効率
! ペイロード率
| 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と得る。
802.1Q VLANタグが使用されているとき、スループットは効率から計算できる。
:<math>\text{Throughput} = \text{Efficiency} \times \text{Net bit rate}\,\!</math>
物理層の正味の[[ビットレート]]（ワイヤビットレート）はイーサネットの物理層規格に依存し、10 Mbit/s、100 Mbit/s、1 Gbit/s、10 Gbit/sのいずれかである。その結果、100BASE-TXイーサネットの最大[[スループット]]は、802.1Qなしで97.53 Mbit/s、802.1Qありで97.28 Mbit/sになる。


スイッチ性能としてのスループットは、pps (パケット毎秒)で表現することもあり、
チャネル利用率(Channel utilization)は、プロトコル効率とよく混同される概念である。これは、ペイロードまたはオーバーヘッドのいずれかで、送信されるデータの性質を無視して、チャネルの使用のみを考慮する。物理層は、リンクチャネルや機器はデータフレームと制御フレームの違いを区別できない。チャネル利用率は次のように計算できる。
{{nowrap|回線速度 ÷ 8 ÷ (物理フレーム長 + パケット間隔長)}}
:<math>\text{Channel utilization} = \frac{\text{Time spent transmitting data}}{\text{Total time}}</math>
で得られる。1Gbps通信の最短フレームの場合、{{nowrap|1G / 8 / 84}} = 1488095 ppsと得られ、この値が[[ベンチマークテスト]]に用いられる<ref>{{IETF RFC|5180}}, Annex A.1. Ethernet</ref>。
合計時間(total time)は、チャネルに沿ったラウンドトリップ時間、ホストでの処理時間、およびデータと確認応答の送信時間を考慮したものである。データの送信に費やされた時間(time spent transmitting data)には、データと確認応答が含まれる。


=={{Anchors|RUNT-FRAMES}}ラントフレーム==
==異常なフレーム==
[[IETF]]では{{仮リンク|RMON|en|RMON}}と呼ばれるLAN管理機能を規定しており、その一環としてフレームの統計情報の収集機能では異常な書式のフレームを定義している<ref>{{IETF RFC|2819}}, Section 5. Definitions</ref>。主な異常フレームには以下のようなものがある。
ラントフレーム(runt frame)は、IEEE 802.3の最小長64オクテットより短いイーサネットフレームである。ラントフレームは一般に衝突によって引き起こされる。その他の考えられる原因として、[[ネットワークカード]]の誤動作、[[バッファアンダーラン]]、{{仮リンク|デュプレックスの不一致|en|duplex mismatch}}、ソフトウェアの不具合がある<ref>

{{cite web
* CRC不一致
| url = http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1904.html
: 受信フレームのFCSの値がCRCの算出値に一致しないもの。CRC Alignmentエラーとして計上される。
| title=Troubleshooting Ethernet
* {{Anchors|RUNT-FRAMES|ラントフレーム}}ラントフレーム(runt frame)
| publisher = Cisco Systems
: 最小フレーム長である64バイトより短いもの。CRCが一致するものはUndersize (不足フレーム)、しないものはFragment (途切れたフレーム)として計上される。後者は一般に[[衝突|コリジョン(衝突)]]によって発生する。その他の考えられる原因として、[[ネットワークカード]]の誤動作、[[バッファアンダーラン]]、[[オートネゴシエーション#二重通信モードの不一致|デュプレックスの不一致]]、ソフトウェアの不具合がある<ref>{{Cite web |url=http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr1904.html |title=Troubleshooting Ethernet |accessdate=2016-08-13 |publisher=Cisco Systems}}</ref>。
| access-date = 2016-08-13
* 長すぎるフレーム
}}
: 最大フレーム長(主に1522バイト)を超えるもの。CRCが一致するものはOversize (超過フレーム), しないものはJabber (饒舌の意)として計上される。前者は[[ジャンボフレーム]]や[[VLAN]]タグフレームに未対応の機器でそれらのフレームを受信した場合など、後者は[[#EOF|フレームの終了]]を通知・検出できない回路異常などが考えられる。
</ref>。
* [[#タイプ/長さ|タイプ/長さ]]が未定義値のもの (1501～1535または0～41)
* [[#物理層パケット|物理層パケット]]の異常
: フレーム終了時の受信ビット数が8の倍数にならない異常や、物理信号が物理層で定義されたシンボルとして認識できない異常などが発生した場合に、[[PHY]]がRX_ER通知を[[Media-independent_interface|MII]]バスで通知し、これを検出・計上するものがある。


==脚注==
==脚注==
168行目: 300行目:
===注釈===
===注釈===
{{Notelist}}
{{Notelist}}

===出典===
===出典===
{{Reflist|30em}}
{{Reflist|30em}}

{{イーサネット}}
{{イーサネット}}
{{DEFAULTSORT:いいさねつとふれえむ}}
{{DEFAULTSORT:いいさねつとふれえむ}}

2024年7月14日 (日) 15:50時点における最新版

イーサネットフレーム（英語: 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]。

レイヤ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タグフレームに未対応の機器でそれらのフレームを受信した場合など、後者はフレームの終了を通知・検出できない回路異常などが考えられる。
フレーム終了時の受信ビット数が8の倍数にならない異常や、物理信号が物理層で定義されたシンボルとして認識できない異常などが発生した場合に、PHYがRX_ER通知をMIIバスで通知し、これを検出・計上するものがある。

脚注

[編集]
[脚注の使い方]

注釈

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

出典

[編集]
  1. ^ a b IEEE 802.3-2022 :section 3.1.1
  2. ^ IEEE 802.3-2022, section 3.3, annex 31A
  3. ^ 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
  4. ^ IEEE 802.3-2022:section 4.2.5
  5. ^ “イーサネットヘッダ”. IT用語辞典 e-Words. 2023年12月12日閲覧。
  6. ^ “IPアドレスとMACアドレスをひも付ける、「ARP」プロトコルの動きを完全図解”. 日経クロステック. 2023年12月12日閲覧。
  7. ^ IEEE 802.3-2022 :§3.2.6
  8. ^ “IEEE 802 Numbers”. IANA (2015年10月6日). 2023年12月12日閲覧。
  9. ^ IEEE 802.3-2022:Annex B.1.2, B.1.3
  10. ^ 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. https://books.google.com/books?id=MRChaUQr0Q0C&printsec=frontcover&source=gbs_ge_summary_r&redir_esc=y#v=onepage&q&f=false 2014年6月30日閲覧。 
  19. ^ IEEE 802.3-2022:§40.1.3.1
  20. ^ IEEE 802.3-2022:Section 4.2.3.2
  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. https://standards.ieee.org/ieee/802.3x/1082/ 
  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日閲覧。
速度
全般
組織
媒体
歴史的な規格
応用
トランシーバ
インターフェース
機器
「https://ja.wikipedia.org/w/index.php?title=イーサネットフレーム&oldid=101089264」から取得