タイプ2の要求

タイプ2 LLC の要求(コマンド)/応答(レスポンス)

タイプ2 LLC には以下のフレームがあります

情報フレーム ( I-Frame )
受信既準備 ( RR )
受信未準備 ( RNR )
拒否 ( REJ )
拡張非同期平衡モード設定 ( SAMBE )
切断 ( DISC )
番号なし確認応答 ( UA )
切断モード ( DM )
フレーム拒否 ( FRMR )

 タイプ1で定義されたフレームはすべて、技術的にタイプ2にも取り入れられました。 しかしながらどのフレームがタイプ1特有で、どのフレームがタイプ2特有であるかは知っておくべきです。 UI フレームはタイプ1だったか、タイプ2だったかということを聞かれたとき、 すべてのタイプ1はタイプ2に含まれるから、タイプ2であるということもできるのですが、「タイプ1のフレームです」と応えるのが理に適っています。


I-Frame : 情報フレーム

 「I」情報フレームはシーケンス番号のついたデータとしてやり取りされます。 「I」フレームには現在送っているデータを示すシーケンス番号( NS )がついています。 加えて、「I」フレームには次に受取るべきフレームの番号が含まれています。


タイプ2の管理コマンド

 管理コマンドには情報フィールドは含まれません。したがってシーケンス番号は増えません。

RR : 受信既準備

 RR フレームは、前に送られたデータの確認応答に使われますが、新しく送るデータは持っていません。 さらに送るデータがあれば、NS= を送ります。「 NS= 」がなければ、RR (や RNR )と一緒に「 NR= 」が送られます。

RNR : 受信未準備

 RNR はステーションが一時的にビジーで、現在 I フレームを受けることができないということです。 RNR が送られたすぐ後には、受信準備ができていることを示す RR を送ることが期待されています。

REJ : 拒否

 REJ は REJ で指示されたフレームで始まる、1つまたは複数のフレームでの応答を要求するために使われます。 たとえば、ステーションが、NS=0、NS=1、NS=2 を送ったとします。 しかし、番号 2 のフレームが通信中に失われ、受信側の受取ったのが、NS=0 と NS=2 だとします。 このような場合、受信側は NS=2 として REJ を送ります。このことは NS=2 のフレームから再送をすることを意味します。 REJ は、再送の丁寧な要求です。


番号のついていないタイプ2のコマンド

SABME : 拡張非同期平衡モード設定

 これは、LLC で通信をしているステーション間の、リンクの確立のために使われます。 タイプ2のコネクションは SABME から始まります。 確認応答をすべきステーションが SABME を受信したら(つまり今のコネクションから)、未確定の確認応答は取り消され、 他方が全く新しいコネクションを再確立することになったとみなされます。

DISC : 切断

 コネクションを終了したい場合には、DISC (切断)を送ります。これは発信元がデータリンクコネクションを止める動作に入ったということを宛先に通知するものです。 すると宛先も切断モードに入らなければなりません。DISC を受けたときに確認応答が未確定であれば、確認応答は取り消されます。 他方が、何からの理由で停止動作に入ったとみなされるからです。


応答

 I フレーム、RR、RNR、REJ は応答フレームです。以下のものも応答となります。

UA : 番号なし確認応答

DM : 切断モード

 DM はステーションが切断モードに入ったことを示します。通常は DISC の後に見られます。 一方が切断すれば、他方は切断モードに入ります。

FRMR : フレーム拒否

 FRMR は最も誤解され易いものです。802.2 の仕様では、このフレームは再送によって訂正できないような状態になったときに送られるとあります。 つまり、FRMR は大惨事状態を示します。FRMR を発見したならば、デバイスドライバのバグやハードウェア障害を疑ってみましょう。 ネットワークでフレームが失われたときは、REJ が送られるのであって、FRMR ではないからです。

 FRMR を引き起こす原因は、、、

無効なフレームを受信しました。例えば、、、
許可されていない I フィールドを持つ管理または番号なしフレーム
不必要なファイナルビットを受けました
要求もしていないのに期待していない UA(番号なし確認応答)を受けました
情報フィールドの長さが XID で確立した最大長を超えました
それまでに送られていない番号の確認応答( NR= )を送りました

 FRMR に対する応答は実装に依存します。LLC は、訂正できるように設計されているか、あるいは単にハングアップするような実装をもっているでしょう。

FRMR を見つけたら、誰が、何のために送っているのかを突き止めるようにしましょう。