イーサネットのカプセル化方式を整理する

■ イーサネット

  イーサネット(Ethernet)は、1972 年、
  ゼロックスのパロアルト研究所で研究が始められた。

  オリジナルバージョンであるイーサネットバージョン1は、
  1980年に、DEC、Intel、Xerox の三社によってリリースされた。
  この最初のイーサネット標準は、3社の頭をとってDIXイーサネットと呼ばれる。
  あるいは単にイーサネット(Ethernet)と呼ぶ場合も多い。

  その後、1982年にバージョン2がリリースされた。

■ イーサネット 2
   Novell:Ethernet_Ⅱ
   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ヘッダでは、イーサネットⅡで使用されている
  イーサタイプの値を、そのまま埋め込むことはできない。 

  この違いを埋めるために
  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
HOME　|　 BACK
PC用眼鏡【管理人も使ってますがマジで疲れません】解約手数料０円【あしたでんき】 Yahoo 楽天 NTT-X Store
無料ホームページ無料のクレジットカード海外格安航空券ふるさと納税海外旅行保険が無料！海外ホテル