LLCに関するオリエンテーション

　バージョン２イーサネットの中に、プロトコルの開発者たちは、新しいイーサタイプ識別子を Xerox に対して登録するものだと思っていました。 1982 年（ 802.3 が完成した年）には、150 以上の異なるイーサタイプがありました。 IEEE は広く開かれた、国際標準を作りたかいと考えました。Xerox に対して登録するという考えは、新しいモデルにふさわしくありませんでした。 すでに登録されたイーサタイプを使う代わりに、IEEE は SAP 識別子によって標準化を開かれたものにしようとしましたのです。

　ある意味で、SAP はバージョン２のイーサタイプと同じ機能を果たします。 両方とも、第３層で機能するエージェント−受信したフレームを解釈することができます−が何かを指し示します。 LLC 層は、さらに進んだ処理を行うには、どこへフレームを渡せばよいのかを決定しなければならないのですが、そのために DSAP を使います。 ちょうどバージョン２イーサネットのデータリンク層でイーサタイプを調べるようにです。 送信元および宛先ステーションは、自らのサービスアクセス点を選ぶことができる、としたので、 標準登録という考えは必要でなくなるはずでした。

　しかしながら、この理論には混乱しやすい点が一つあります。 例えば、もし自分がノベルの NetWare という SAP を選んだとすると、その SAP を相手に通知するための何らかの方法が必要になります。 これは XID −識別のために交換されるフレーム−を通じて実現されます。 問題は、双方が「自分たちはノベルの NetWare を使うのであって、他のプロトコルを使うのではない」ということを、さらに合意しなければならないということです。 例を使って、もう少しわかりやすく説明してみます。

　自分はノベル NetWare のつもりで SAP コード E0 （ HEX ）を使うことに決めました。 さて、これを相手に通知するために XID フレームを生成することになります。 「NOVELL NETWARE」という文字列を送ればよいのでしょうか？ それとも、ノベルであることを知らせるために、1234 という番号を割り当てるべきでしょうか？ このようににし見てくると、プロトコル処理エージェントのために、さらに前もって標準となる取り決めが必要であることがわかります。 Xerox には、すでにそれがありました。イーサタイプのことです。

　結果として、今日、ネットワークを流れるフレームの中に見られる DSAP と SSAP の番号は同じです！ つまり、以下の「標準的な」番号を使うという一般的な合意ができているのです。
IBM は SNA として 4 の倍数を複数個、用います（ SAP=04、SAP=08 など）。
ノベルの NetWare は SAP=F0 を使用します。
NetBIOS は SAP=E0 です。
Banyan Vines は SAP=BA となります。
IP は？ それはまた別のところで、、、
IP はイーサタイプとほとんど同じように設計されました。 そして、802 のフレームを使って IP にアクセルするためには、IEEE によって予約された特別な SAP を必要とします。 この仕組み SNAP （ Sub-Network Access Protocol ）については、別のところで説明します。