■ 参考URL
http://www.cam.hi-ho.ne.jp/puffin/compendium/J_EN-FrFmt.html
http://www.geocities.jp/cckik/ether.html
2003/08/01 pm
イーサネットのカプセル化方式を整理する
■ イーサネット
イーサネット(Ethernet)は、1972 年、
ゼロックスのパロアルト研究所で研究が始められた。
オリジナルバージョンであるイーサネットバージョン1は、
1980年に、DEC、Intel、Xerox の三社によってリリースされた。
この最初のイーサネット標準は、3社の頭をとってDIXイーサネットと呼ばれる。
あるいは単にイーサネット(Ethernet)と呼ぶ場合も多い。
その後、1982年にバージョン2がリリースされた。
■ イーサネット 2
Novell:Ethernet_U
Cisco：arpa
DIXは、1982 年に、バージョン2のイーサネットをリリースした。
以来、ほとんど全てのバージョン1が、バージョン2に置き換わっている。
一般にTCP/IPでも、バージョン2のフレームが使用されている。
イーサネット2フレームでは、宛先アドレス、送信元アドレスの次に、
イーサタイプという2バイトのフィールドが続く。
このイーサタイプフィールドは、イーサネットで運ぶ上位層プロトコルを
識別するために用いられる。
|← Data Link Header →|
+-----------+-------+------+----------------------------------------+---+
|Destination|Source |Type |Data |FCS|
|Address |Address| | | |
+-----------+-------+------+----------------------------------------+---+
6 6 2 Variale 4 bit
イーサタイプフィールドは、1500(16進数で05DC)より大きい値を取る。
一方、IEEE802.3シリーズの長さフィールドは、1500以下の値を取る。
これは、データ部分の最大長が1500バイトであることに起因する。
これにより、イーサネット系フレームかIEEE802.3系フレームかを識別できる。
■ IEEE 802.3
IEEE802委員会は、1980年2月、
イーサネットの国際標準を作成するためのプロジェクトを始めた。
IEEEでは、DIXイーサネットをベースとして検討を進めた。
その結果、IEEE802.3標準では、
DIXイーサネットのイーサタイプフィールドを廃止して、
替わりに長さフィールドを設けて、データ部分の長さを表すことにした。
このためIEEE802.3標準では、ネットワーク層プロトコルの識別ができない。
なお、IEEE802.3標準の長さフィールド値は、必ず1500(05DC)以下になる。
MACフレームのデータ部分の最大長は1500バイトだから。
このことは、DIXイーサネットフレーム（イーサタイプ使用）か
IEEEフレーム（長さフィールド使用）かの識別に役立つ。
|← Data Link Header →|
+-----------+-------+------+----------------------------------------+---+
|Destination|Source |Length|Data |FCS|
|Address |Address| | | |
+-----------+-------+------+----------------------------------------+---+
6 6 2 Variale 4 bit
IEEE802.3標準の初期バージョンでは、
ネットワーク層のパケットを直接データフィールドに格納する(Raw方式)。
当初はLANのネットワーク層といえばIPX一色だったので、
上位層プロトコルの判別ができなくても問題なかったのである。
しかし、その後TCP/IPプロトコルが台頭し、IPとARPの判別が必要になった。
NICは、受信したマックフレームを、
どのネットワーク層プロトコルに渡せばよいか、判別しなければならない。
そこで、IEEE802.3標準の最終バージョンでは、
後述するLLCヘッダやSNAPフィールドを、合わせて使うことが規定された。
■ 802.3 Raw
Novell: Ethernet_802.3
Cisco: novell-ether
IEEE802.3標準の初期バージョンをベースとして
ノベル社が独自にリリースしたカプセル化フォーマット。
NetWare 3.11以前のデフォルトフレームタイプになっている。
Raw(生)と呼ぶのは、データ部分に直接上位層パケットを格納するため。
802.3 Rawを使ってIPXパケットをカプセル化する場合には、
IPXパケットの先頭にあるチェックサムフィールドの値を、常にFFFFとする。
これにより、Rawフレームと他のカプセル化を使用したフレームとを判別できる。
RawはIEEE802.3初期バージョンをベースにしているので、
上位層プロトコルを識別するためのフィールドがない。
当時はまだ、IPXが全盛の時期であり、こうした仕様で問題なかった。
|← Data Link Header →|
+-----------+-------+------+----------------------------------------+---+
|Destination|Source |Length|IPX Packet |FCS|
|Address |Address| |(0xFFFF･･･) | |
+-----------+-------+------+----------------------------------------+---+
6 6 2 Variale 4 bit
ノベル社がこの独自フォーマットをリリースしてから2年後、
IEEE802.3標準の最終バージョンが発表された。最終バージョンでは、
長さフィールドの後ろに、LLC ヘッダを付加する形に修正された。
このため、この時点でノベル社のカプセル化フォーマット(Raw)は、
国際標準規格との互換性がなくなってしまった。
そこでノベル社は、NetWare 3.12以降のデフォルトのカプセル化タイプとして、
後述するIEEE802.2 LLCを採用している。
■ IEEE 802.2 LLC
Novell: Ethernet_802.2
Cisco: sap
IEEE802.3標準のフレームに、
ノード間のリンク制御に使用するLLCヘッダを追加するための仕様。
LLCヘッダは3バイトからなり、データ部分の先頭に配置される。
LLCヘッダーでは、
サービスアクセスポイント(SAP)という概念を導入している。
LSAP(Link Service Access Point)は、LLCデータを受信する役割を、
SSAP(Source Service Access Point)は、LLCデータを送信する役割を持つ。
ノベル社では、当初はRawフレームを使用していたが、
NetWare 3.12以降は、デフォルトのカプセル化タイプとしてLLCを採用した。
|← Data Link Header →|← LLC Header →|
+-----------+-------+------+----+----+-------+----------------------+---+
|Destination|Source |Length|DSAP|SSAP|Control|Data |FCS|
|Address |Address| | | | | | |
+-----------+-------+------+----+----+-------+----------------------+---+
6 6 2 1 1 1 Variale 4 bit
LLCヘッダでも、
イーサタイプと互換する形での上位層プロトコル識別ができない。
そこで後に、LLCを更に拡張したSNAPフィールドが定義された。
SNAPフィールドを使用する場合には、
DSAPとSSAPフィールドに、共に16進でAA（10進数で170）が入る。
逆にSAPフィールドがAAAA以外の場合は、
LLCヘッダのみを使用しており、SNAPフィールドは使っていない。
■ SNAP
Novell：Ethernet_SNAP
Cisco: snap
イーサネットバージョン2では、イーサタイプフィールドを使って、
上位層プロトコルタイプを指定することができるが、
802.2 LLCヘッダでは、イーサネットUで使用されている
イーサタイプの値を、そのまま埋め込むことはできない。
この違いを埋めるために
SNAP（サブネットワークアクセスプロトコル）が作られた。
SNAPでは、802.2 LLCヘッダの後ろに、さらにSNAPフィールドを付加する。
SNAPフィールドは5オクテットで構成され、
ここに上位層プロトコルのタイプを記述することができる。
|← Data Link Header →|← LLC Header →|←SNAP Field→|
+-----------+-------+------+----+----+-------+--------+-----+-------+---+
|Destination|Source |Length|DSAP|SSAP|Control|Protocol|Type |Data |FCS|
|Address |Address| | | | |ID | | | |
+-----------+-------+------+----+----+-------+--------+-----+-------+---+
6 6 2 1 1 1 3 2 Variale 4 bit
こうして、DIXイーサネット系のカプセル化方式と
IEEE系のカプセル化方式とが、互換性を得ることができた。
なお、Cisco独自のCDPプロトコルでは、このSNAPを使用している。
■ まとめ
■ 参考URL
http://www.cam.hi-ho.ne.jp/puffin/compendium/J_EN-FrFmt.html
http://www.geocities.jp/cckik/ether.html
2003/08/01 pm