サブネットワークアクセスプロトコル
サブネットワークアクセスプロトコル ( SNAP )は、IEEE 802.2 LLCを使用するネットワーク上で、8ビット802.2サービスアクセスポイント(SAP)フィールドで識別できるよりも多くのプロトコルを多重化するためのメカニズムです。 SNAPは、イーサネットタイプフィールド値によるプロトコルの識別をサポートしています。それはまた、ベンダーのプライベートプロトコル識別子空間をサポートしています。 IEEE 802.3、IEEE 802.4、IEEE 802.5、IEEE 802.11、およびその他のIEEE 802物理ネットワーク層、および802.2 LLCを使用するFDDIなどの非IEEE 802物理ネットワーク層で使用されます。
SNAPおよびLSAPフィールドは、受信ノードが各受信フレームを特定のプロトコルを理解する適切なデバイスドライバーに渡すことができるように、送信ノードでパケットに追加されます。
バックグラウンド
Open Systems Interconnect(OSI)モデルは、SAPを使用して、レイヤー(ネットワーク、トランスポート、セッション、および7層モデルの他のレイヤーなど)間の通信を定義します。つまり、どのプロトコルが着信メッセージを処理するかを識別します。特定の層内で、プログラムは相互に合意したプロトコルメカニズムによってデータを交換できます。共通のプロトコルをサポートしないプログラムのペアは、相互に通信できません。したがって、複数のプロトコルがレイヤー内で共存するには、下位プロトコルによって配信されるサービスデータユニットを処理するためにどのプロトコルを呼び出すかを決定する必要があります。
ソースサービスアクセスポイント(SSAP)および宛先サービスアクセスポイント(DSAP)を含むSAPへの最も一般的な参照は、データリンクレイヤーとネットワークレイヤーの境界を指します。レイヤー2での使用、特にIEEE 802.2標準で定義されている論理リンク制御(LLC)サブレイヤーでのみSAPを使用することを考えるのが一般的です。リンクサービスアクセスポイント(LSAP)には、宛先サービスアクセスポイント(DSAP)とソースサービスアクセスポイント(SSAP)の両方が含まれます。 MACステーションは、異なるプロトコルを介して上位層と通信できます。
ISO / IEC TR 11802-1に記録されているように、標準のネットワーク層プロトコルには予約済みのLLCアドレスが割り当てられています。 LLCアドレス空間の半分は、そのような割り当てのために予約されています。他のプロトコルは、2つの方法で収容されています。 1つの方法は、LSAPのローカル割り当てによるもので、LLCアドレス空間の残りの半分が利用可能です。 2番目の方法は、SNAPアドレスと呼ばれるSub-Network Access Protocol(SNAP)と共に使用するために割り当てられた特定の予約済みLLCアドレス値を使用することです。 SNAPアドレスは、各MAC SAPで単一のLSAPを識別します。したがって、SNAPを使用する各プロトコルは、プロトコル識別子を使用する必要があります。したがって、 サブネットワークアクセスプロトコル (SNAP)は、IEEE 802.2 LLCを使用するネットワークで、8ビット802.2サービスアクセスポイント(SAP)フィールドで識別できるよりも多くのプロトコルを多重化するためのメカニズムです。 SNAPは、イーサネットタイプフィールドの値によってプロトコルを特定サポートしそれはまた、ベンダーのプライベートプロトコル識別子空間をサポートしています。 IEEE 802.3、IEEE 802.4、IEEE 802.5、IEEE 802.11、およびその他のIEEE 802物理ネットワーク層、および802.2 LLCを使用するFDDIなどの非IEEE 802物理ネットワーク層で使用されます。
つかいます
SNAPは、IEEE 802 Overview and Architectureドキュメントで指定されている802.2 LLCの拡張です。宛先SAP(DSAP)およびソースSAP(SSAP)にAAまたはABの16進値が含まれる場合、5オクテットSNAPヘッダーは802.2 LLCヘッダーの後に続きます。
802.2 LLCヘッダー | SNAP拡張 | |||
---|---|---|---|---|
DSAP | SSAP | コントロール | OUI | プロトコルID |
1つのオクテット | 1つのオクテット | 1つのまたは2オクテット | 3つのオクテット | 2つのオクテット |
SNAPヘッダーは、3オクテットのIEEE組織固有識別子(OUI)とそれに続く2オクテットのプロトコルIDで構成されます。 OUIが16進数000000の場合、プロトコルIDはSNAPの上で実行されているプロトコルのイーサネットタイプ(EtherType)フィールド値です。 OUIが特定の組織のOUIである場合、プロトコルIDはその組織によってSNAPの上で実行されるプロトコルに割り当てられた値です。
SNAPは通常、3の制御フィールド値を持つUnnumbered Information 802.2プロトコルデータユニット(PDU)で使用され、LSAP値は通常16進AAであるため、SNAPパケットの802.2 LLCヘッダーは通常AA AA 03です。ただし、SNAPは他のPDUタイプでも使用できます。
イーサネットでは、LLCおよびSNAPヘッダーが占める8オクテットにより、イーサネットIIフレーミングの使用と比較して、インターネットプロトコルなどのプロトコルで使用可能なペイロードのサイズが1492バイトに減少します。したがって、EtherType値を持つプロトコルの場合、パケットは通常、LLCおよびSNAPヘッダーではなくイーサネットIIヘッダーで送信されます。他のネットワークタイプでは、リンク層で異なるプロトコルを多重化するために、LLCおよびSNAPヘッダーが必要です。MAC層自体にはEtherTypeフィールドがないため、利用可能なペイロードが大きくなる代替フレーミングはありません。
「なぜ別のサブネットワークヘッダーが必要なのか?」答えは、LLCヘッダーのレイアウト中に行われた決定を補強することでした。 LLCヘッダーの設計時に、ベンダーが登録するすべてのプロトコル値を指定するには、ヘッダー内の単一のオクテット(256の可能な値)で十分であると考えられていました。値が予約され始めたため、LLCヘッダーがすぐにオープン値を使い果たすことが発見されました。 16進数のAAおよびAB値が予約され、追加のヘッダー(SNAPヘッダー)が開発されました。すべてのEtherType値、およびプライベートプロトコル値の複数のスペースをサポートできます。
IETF RFC 1042に従って、IPデータグラムとARPデータグラムは、RFC 894に従ってイーサネットIIヘッダーで送信されるイーサネット/ IEEE 802.3を除き、LLCおよびSNAPヘッダーを使用してIEEE 802ネットワークを介して送信されます。