論理リンク制御の理解

はじめに

IEEE 標準 802.2 では、論理リンク制御（LLC）を 802.3、802.5、およびその他のネットワークで使用するデータリンク制御層として定義しています。

前提条件

要件

Cisco は、以下のトピックの知識を持つことを推奨します。

• LLC の基本理解

使用コンポーネント

この文書は特定のソフトウェアおよびハードウェア バージョンに制限されているものではありません。

このドキュメントの情報は、特定のラボ環境でのデバイスから作成されました。 このドキュメントで使用されているすべてのデバイスは、クリアされた（デフォルト）構成で開始されています。

Conventions

文書の規則についての詳細は、Cisco Technical Tips Conventionsを参照してください。

コネクションレス型のデータ転送は、一般に LLC タイプ 1、または LLC1 と呼ばれます。 コネクションレス型サービスでは、データリンクやリンクステーションを確立する必要はありません。 サービスアクセスポイント（SAP）が有効化された後、SAPは同じくコネクションレスサービスを使用するリモートSAPと情報を送受信することができます。 コネクションレス型サービスは、モード設定コマンド（SABMEなど）を持たず、状態情報を保持する必要がありません。

コネクションオリエンテッドなデータ転送は、LLCタイプ2（LLC2）と呼ばれる。 接続指向のサービスには、リンク局の確立が必要である。 リンク局を確立する場合，モード設定コマンドが必要である。 以後、各リンク局はリンク状態情報の保持に責任を持つ。

LLCの実装

LLC2 は、SNA (Systems Network Architecture) がLANまたは仮想LAN上で動作するときは必ず実装される。 また、LLC2はフレームリレーに直接カプセル化されています。 ルーターは単にLLC2フレームを渡すこともあれば、LLC2リンクステーションを実装することもあります。 NetBIOSもLLCを使用します。 NetBIOS は LLC1 を使ってリソースを探します。 ルータは、これらの機能のいずれかが有効になっている場合、LLC2スタックを実装します。

• データリンクスイッチング (DLSw) (LAN への接続)

• ローカル ACK 付リモートソースルーティングブリッジ (RSRB)

• チャネルインターフェースプロセッサ (CIP)

• Advanced Peer-to-Black (LANへの高度な接続)

• Local Source-Route Bridging (RSMG、LSRB、LSMF、RSMF)

• Advanced Source-Link (RSMF、RSMF)SNASw）

• 同期データリンク制御（SDLC）からLCC変換（SDLLC）

トラブルシューティングのために知っておくべき基本情報

ほとんどの問題を分離して解決するには、LLCに関する基本知識があれば十分です。 LLC1では，リンク状態やセッションを保持する必要がないため，問題が発生することはほとんどありません。

1. 確立しないセッション

2. 断続的に失敗する確立したセッション

これらの問題を解決するには、以下のトピックについて知っておく必要があります。

• LLCフレームフォーマット

• LLC2モードとセッション確立

• LLC2 Asynchronous Balanced Mode（非同期バランスモード Operation

• LLC2 Error Conditions

LLC Frame Formats

このセクションでは、LLCフレームフォーマットに関する情報を提供します。

dddd ddxxxxxx xx1xxxxx xxx1

Dest. Addr.IEEE DefinedGroup Address

CCCC CC11000F 1111010P 0011011F 0011011P 1111100F 0111101z 1111111z 0011

xx-xx0F-1F43-5363-736F-7F87-97AF-BFE3-F3

Unnumbered formatDisconnect ModeDisconnectUnnumbered Ack.SABMEFrame RejectXIDTest

ssss ssxxxxxx xx1xxxxx xxx1

Source AddressIEEE definedResponse LPDU

CCCC CC010000 00010000 01010000 1001

xx-xx01-xx05-xx09-xx

Supervisory FormatReceiver ReadyReceiver Not ReadyReject

ssss sss0

xxxx

Information format

LLCフレームは、LPDU（LLC Protocol Data Unit）と呼ばれます。 であり、以下のような書式になっています。

DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field(0 or more bytes)

DSAPフィールド

宛先サービスアクセスポイント（DSAP）は、LPDUが意図するSAPを識別します。 DSAP は、6 つのアドレスビット、ユーザビット（U）、個人／グループ（I/G）ビットで構成され、以下に示すような構成となっている。

D-D-D-D-D-D-D-I/G

Uビットは、アドレスがIEEEで定義されているか（1）、ユーザ定義であるか（0）を示す。 I/Gビットは、SAPがグループアドレス（1）か個人アドレス（0）かを示す。 この目的のためには、これらのビットはどちらもあまり重要ではありません。 本当に知る必要があるのは、DSAPがLPDUの宛先であることだけです。 3709>

SSAPフィールド

ソースサービスアクセスポイント（SSAP）は、LPDUを発信したSAPを特定する。 SSAPは、6つのアドレスビット、ユーザビット（U）、コマンド／レスポンス（C／R）ビットから構成され、以下に示すような構成となっている。

S-S-S-S-S-S-U-C/R

Uビットは、アドレスがIEEEで定義されているか（1）、ユーザ定義であるか（0）を示す。 C/R ビットは、LPDU がコマンドであるかレスポンスであるかを示す。 LPDUフレームを受信した場合、C/RビットはSSAPの一部とはみなされません。 したがって、通常、SSAPは左端の7ビットのみとみなされる。

Control Field

LPDU制御フィールドは、コマンド、レスポンス、シーケンス番号の情報を含んでいます。 特定の LLC2 セッションで何が起こるかを判断するためには、制御フィールドをどのようにデコードするかを知っている必要があります。 しかし、デコード情報は容易に入手可能です。

フレームには3つのタイプがあります。

• Iフレーム

• 監視フレーム

• 番号なしフレーム

それぞれのタイプで制御フィールドの形式が異なっていますが、制御フィールドの2ビットで簡単に区別することが可能です。

X-X-X-X-X-X-X-0 = I FrameX-X-X-X-X-X-0-1 = Supervisory FrameX-X-X-X-X-X-1-1 = Unnumbered frame

以下、各タイプのコントロールフィールドについて説明します。

Iフレーム

Iフレームは、リンク局間で情報（コネクション指向）を含む連番LPDUを転送することができます。 Iフレームの形式は，NSカウントとNRカウントを含みます。 NSカウントは，現在転送中のLPDUのシーケンス番号（モジュロ128）です。 NRカウントは、送信側が受信を期待する次のLPDUのIフレームのシーケンス番号である。 後で役立つように、NRは “次の受信 “を意味すると覚えておくとよい。

NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F

P/Fビットは、コマンドLPDUではPビット、レスポンスLPDUではFビットと呼ばれます。 P/F ビットはコマンド LPDU で設定され、リモートリンク局に対してこのビットを設定した応答の送信を要求する。 この場合、P ビットをセットして送信したコマンドに対して、F ビットをセットしたレスポンスを 1 つだけ受信する必要があります。 3709>

Supervisory Frame

監視フレームは、Iフレームの確認（RR）、Iフレームの再送要求（REJ）、Iフレームの一時停止要求（RNR）など監視制御機能を実行するものである。 監視フレームは、情報フィールドを含まない。 したがって、監視フレームは送信局のNSに影響を与えないので、NSフィールドを含まない。 以下、監視フレームのフォーマットです。

0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F

「S」ビットは監視フレームの種類を示す

• B’00’ = Receiver Ready

  局はRRを用いて受信準備ができていることを示し、次に到着予定のIフレームのNRカウントが含まれています。 RRフレームを送信すると、NR-1までの番号のIフレームを相手局から受信したことを確認する。

• B’01’=Receiver Not Ready

  局は、RNRを用いて、局が一時的に受信準備ができていないことを指示する。 RNRはまた、同じ規則RRに従うNRカウントを含む。 RNRの一時的な期間は、必ずしもネットワークの問題を示唆するものではありません。 RNR が持続する場合は、末端局での輻輳を調べてください。

• B’10’=Reject

  局はREJを使用してNRカウントに示された番号から始まるIフレームLPDUの再送を要求する。 REJは深刻な問題を示すものではありません（回復可能であることを意味します）。 REJコマンドが多く見られる場合は、逆方向のIフレームの欠落（ドロップ）を探してください。 REJ をフレーム拒否（FRMR）と混同しないでください。 FRMRは番号のないフレームであり、常に重大な問題を示しています。

Unnumbered Frames

Unumberedフレームは、例えばモード設定コマンドと応答のようなリンク制御機能を提供します。 また、場合によっては、非番号制の情報フレームを送信することができる。 番号無しフレームは、長さが1バイトのみである。 NRやNRSのカウントのためのフィールドは含まれません。 以下は、番号なしフレームのフォーマットである。

M-M-M-P/F-M-M-1-1

Mビットは非番号制フレームの種類を示します。

• B’00011’=DM Response (0x1F)

  リンク局は非同期切断モードにあることを報告するためにDMレスポンスを送出します。 これは、リンクがアクティブでないことを意味する。 アクティブであったリンク局が突然DMを送信し始めた場合，リンク局がリセットされた可能性があります。

• B’01000’=DISC コマンド（0x53）

  リンク局は非同期平衡モードを終了させるために DISC を送信します。 DISCコマンドは，相手リンク局に対して動作の停止を通知します。 DISCコマンドに対する正しい応答は、UA（ABMの場合）、またはDM（ADMの場合）です。

• B’01100’=UA Response(0x73)

  リンク局はSABMEおよびDISCコマンドに応答してUAを送信します。

• B’01111’=SABME Command(0x7F)

  リンク局はSABMEを送って非同期の平衡モードでのデータ転送を開始させます。 SABMEに対する正しい応答はUAである。 リンク局はSABMEコマンドを受信すると、NRとNSのカウントを0にリセットする。 送信局は、UAレスポンスを受信したときに同様に行う。

• B’10001’=FRMR Response(0x87)

  リンク局は、相手リンク局から受信するLPDUにエラーがあることを報告するためにFrame Reject Responseを送信します。 FRMRが表示された場合，FRMRを送信した局は回復不能なエラーを検出したことになります。 エラーの原因ではありません。 FRMRエラーが発生した後に到着したフレームは、DISCまたはSABMEを受信するまで無視されます。

  FRMR応答はFRMR状態の原因に関する情報を含みます。

  バイト0と1はフレーム拒否を引き起こしたLPDUの制御フィールドの内容が入っています。 2 バイト目と 3 バイト目は、それぞれ NS と NR のカウントを含む。 バイト4には、以下に示すように、エラーの種類を識別するためのいくつかのビットが含まれる：

  0-0-0-V-Z-Y-W-X

  Vビットは、バイト0および1のコントロールフィールドが伝えるNS番号が無効であることを示す。 NSは、最後のNSに最大受信ウィンドウサイズを加えた値以上であれば、無効である。 この条件が発生した場合、リンク局は FRMR 応答ではなく REJ LPDU を送信します。

  Z ビットは、制御フィールドがバイト 0 と 1 で示す NR が、次の I フレームまたは既に送信されたが確認されていない I フレームのいずれにも該当しないことを示します。

  NRのカウントは、既に確認されているIフレームを参照している場合、またはまだ送信されていないフレームをスキップしてカウントしている場合のみ、無効となります。 前者は、この種のエラーの最も一般的なケースです。 このタイプのエラーが表示された場合、通常はフレームが順番通りに受信されていないことを意味し、順番通りにフレームを配信しているネットワークを探す必要があります。 送信側のリンクステーションが順序を無視して送信した可能性もありますが、非常に低いです。

  Yビットは，受信したLPDUのIフィールドの長さが利用可能なバッファの容量を超えたことを示しています。 この状況が発生した場合、ネットワークではなく、エンドステーションの問題を探します。

  The X bit indicates that the LPDU contained an I field when it should not have, or the FRMR response was received that not contain 5 bytes. これは、ネットワークの問題ではなく、エンドステーションの問題のように見えます。

  Wビットは、サポートされていないLPDUを受信したことを示します。 これは、エンドステーションの問題です。

• B’10111′ XID Command or Response

  リンク局はXIDコマンドを使用して、送信ノードの特性を伝え、リモートリンク局にXIDレスポンスで対応させる。 リンク局は、SNA形式を含むさまざまな形式でXIDを送受信することができます。

• B’11100′ TESTコマンドまたはレスポンス

  リンク局は、リモートリンク局にできるだけ早くTESTレスポンスで応答するようにTESTコマンドを送信する。 TESTコマンドは，一般にソースルートブリッジ環境での経路探索に使用されます。

  

LLC 制御フィールド概要

0xF または 0xF レスポンス

LLC2 Modes and Session Establishment

LLC2の動作モードは2つある。

• 非同期バランスモード拡張

• 非同期切断モード

Asynchronous Balanced Mode Extended (ABME)

ABMEは2リンクステーション間のバランス動作モードであり、ABMEは、非同期切断モードである。 バランスモードとは、どちらかの局がもう一方のリンク局から独立して、いつでもコマンドを送ることができることを指す。 アンバランスモードで動作するSDLCとは対照的です。 アンバランスモードでは、二次局は一次局からのポーリングを待たないとデータを送信できない。 バランスモード動作の結果、LLC2 回路では、従来の意味でのポーリングは発生しません。 ステーションはセッションを維持するためにキープアライブを送信しますが、SDLCのように最適なパフォーマンスを得るためにこれらを頻繁に送信する必要はありません。 このため、キープアライブタイマは通常 10 秒以上です。 エンドステーションはオーバーヘッドを減らすためにこのキープアライブタイマーを増やすことができることに注意することが重要です。 3709>

局は、UA to to SABMEコマンドを送信または受信した後、ABMEに入ります。 ABMEのとき、局は番号付き情報フレームの送受信が可能です。

Asynchronous Disconnect Mode (ADM)

局がABMEを終了する前と後、局は非同期切断モードとなります。 ADMではリンクが論理的に切断されるため，Iフレームや監視フレームを送信することはできません。 このため、I フレームや監視フレームは送信できません。

• DISCコマンド受信

• リンクステーション起動

• DM応答受信

• リトライ制限を消化

次に、リンクステーション起動シーケンス例について述べます。

To1 4000.0840.0001 8800.5a94.7d94 SABME F0F07FTo1 4000.0840.0001 8800.5a94.7d94 UA F0F173To 1 4000.0840.00018800.5a94.7d94 RR nr=0 F0F001To1 4000.0840.0001 8800.5a94.7d94 INFO nr=0 ns=0 F0F00000 ...To1 4000.0840.0001 8800.5a94.7d94 RR nr=1 F0F101 To1 4000.0840.0001 8800.5a94.7d94 INFO nr=1 ns=1 F0F00202 ...To1 4000.0840.0001 8800.5a94.7d94 RR nr=2 F0F101To1 4000.0840.0001 8800.5a94.7d94 INFO nr=2 ns=2 F0F00000 ...

LLC2 Asynchronous Balanced Mode Operation

ASBMで動作する局には、一次局、二次局という厳格な感覚はありません。 局はデータ転送のためにポーリングしたり、ポーリングされたりする必要はありません。 局は非同期でどの局にもデータを送信できます。 局はピアツーピアの関係を持っている。

一次と二次という厳密な意味はありませんが、送信局は、送信した番号付き情報フレームごとに受信局から確認応答と呼ばれるリンクレベルの応答を必要とします。 ある局は、確認応答がないフレームの数が限界に達するまで、他の局にIフレームを送信し続けることができます。 この数は「ウィンドウサイズ」と呼ばれ、通常デフォルトは7です。送信局が応答を停止して待つ必要がないように、待ち時間の多い回路ではウィンドウサイズを大きくすることができます。 これは、特にLLCがローカルに確認される状況では、通常必要ではありません。 送信局が送信ウィンドウに到達すると、受信局に応答を送らせるためにポーリングビットを設定します。 ルータでは、ウィンドウサイズは、llc2 local-windowと呼ばれる。

受信局には、一定数のIフレームが到着するか、タイマーの期限が切れるまで確認応答を保留するオプションがあります。 これらのパラメータは、それぞれN3およびT2と呼ばれます。 この方法では、複数のフレームを1つのRRフレームで確認したり、確認応答をIフレームに重ねて送信したりすることができます。 Ciscoは、N3カウンターをllc2 ack-maxと呼んでいます。 デフォルト値の3は、ルーターが3つのIフレームを受信するか、T2タイマーまたはllc2 ack-delay-timeが期限切れになるまで、ルーターが確認応答を保留することを表します。

パートナー局を考慮せずに、ある局でこれらのパラメータを変更すると、応答時間とスループットに影響を与える可能性があります。 例えば、送信局のlocal-windowが5に設定され、受信局がack-maxに7、ack-delay-timeに500ミリ秒の値を持つ場合、何が起こるかを考えてみましょう。

この場合、送信局は5フレームを送信し、確認応答を待ってから続行します。 受信側は7フレームを受信するまで確認応答を保留するので、500ミリ秒の遅延時間が経過するまで確認応答は送信されません。 受信側のack-maxの値を下げれば、パフォーマンスを劇的に向上させることができます。

もう一つの一般的なLLC2パラメータは、Tiタイマーと呼ばれています。 ルーターはこれをllc2 idle-timeと呼びます。 Ti タイマーの目的は、I フレームが送信されていない期間中、LLC2 セッションをアクティブに維持することです。 こ の値を下げ る と 、 ス ルー プ ッ ト と パフ ォーマ ン ス を向上 さ せ る こ と がで き ません。 Ti タイマーが満了すると、受信機からの応答を引き起こすために poll ビットをオンにして RR フレームが送信されます。 局が応答しない場合、llc2 n2 で定義された再試行回数が経過するまで、llc2 tpf-time の後に再試行されます。 このとき，セッションは破棄されます。

LLC2回線のオーバーヘッドを減らすためにアイドル時間を増加させ，ローカルackの代替として調整することができます。 200 個の DSPU が 1 つの NCP に接続されている例を考えてみましょう。 各 PU は独立した LLC2 セッションを維持します。 それぞれが 10 秒ごとにキープアライブを送信すると、毎秒 20 フレームのオーバーヘッドが発生します。 アイドル時間を30秒にすると、オーバーヘッドフレームの量は1秒間に6.67フレームに減ります。 このアプローチの欠点は、ステーションがパートナーが到達不能であることを発見するのに時間がかかることです。 しかし、状況によっては、これは良いことかもしれません。

LLC2 Tunable Parameters

±10 frames。

これらのパラメータの値はshow llcコマンドで確認できます。

ibu-7206#sh llcLLC2 Connections: total of 1 connectionsTokenRing3/0 DTE: 4001.68ff.0000 4000.0000.0001 04 04 state NORMALV(S)=5, V(R)=5, Last N(R)=5, Local window=8, Remote Window=127akmax=3, n2=8, Next timer in 8076xid-retry timer 0/60000 ack timer 0/1000p timer 0/1000 idle timer 8076/10000rej timer 0/3200 busy timer 0/9600akdelay timer 0/100 txQ count 0/2000

LLC2パラメータの設定例

両端にトークンリングLANを持つ通常のDLSw+ネットワークにおいて，LLC2パラメータの設定は発信側トークンリングインタフェースで行われます。

LLC2セッションは2つに分かれています。 したがって，LLC2パラメータの設定は次のように行います。

hostname dlsw1!source-bridge ring-group 100!dlsw local-peer ...dlsw remote-peer ...!interface token-ring 0source-bridge 10 1 100llc2 tpf-timer 2000llc2 n2 20hostname dlsw2! source-bridge ring-group 100! dlsw local-peer ...dlsw remote-peer ...! interface token-ring 0source-bridge 20 1 100llc2 tpf-timer 2000llc2 n2 20

注：これらの構成は，関連するLLC2パラメータの構成だけを抜粋しています。

LLC2パラメータの構成は，FEP（DLSw1ルータ宛）およびPC（DLSw2ルータ宛）のLLC2パラメータと一致させる必要があります。 セントラルサイトのDLSw+ピアがCIPルータ上にある場合、構成は若干異なります。

リモートDLSw+ルータの構成は変更されません。 ただし、セントラルサイトのLLC2セッションは、CIPとIOSのLLC2スタック間となります。 CIPはメインフレームを表し、メインフレームからIOSに向かうLLC2パラメータは、（CIP上の）LANトークンリング上のアダプタの下に設定されます。 IOS からメインフレームに向かう LLC2 パラメータは、発信側インタフェースに設定されます。 例：

hostname dlsw1! source-bridge ring-group 100! dlsw local-peer ...dlsw remote-peer ...!interface channel 0/2llc2 tpf-timer 2000llc2 n2 20lan tokenring 0source-bridge 10 1 100adapter 0 4000.7513.0000llc2 tpf-timer 2000llc2 n2 20

注：これらの構成は、関連するLLC2パラメータの構成だけを抜粋したものです。

CIPルーターがLAN経由でローカル局に接続する場合、CIPアダプターの下にLLC2パラメーターだけが必要です。 そして、LLC2パラメータはPCのパラメータと一致させることになります。

hostname rtr1! source-bridge ring-group 100! interface channel 0/2lan tokenring 0source-bridge 10 1 100adapter 0 4000.7513.0000llc2 tpf-timer 2000llc2 n2 20

注：これらの構成は、LLC2パラメータの構成に関連するものだけを抜粋して示しています。

ブリッジグループ経由でDLSw+に接続する場合，LLC2パラメータはDLSW+のブリッジグループステートメントで設定されます。

注：ethernet 0インタフェースでもLLC2の設定は可能ですが，これらのパラメータは影響を与えません。 DLSw bridge-group LLC2 は Cisco IOS Software Release 11.3 で新規に追加されました。

ルータがエンドステーションとして構成されている場合（SNASwやDSPUなど）、発信インタフェースでLLC2パラメータを設定する必要があります。 すべての仮想インタフェースがLLC2パラメータの設定をサポートしているわけではないことに注意してください。 例えば

Note: These skimmed configurations show only relevant LLC2 parameter configuration.

hostname snasw1!Interface fastethernet 0/0llc2 tpf-timer 2000llc2 n2 20!snasw cpname neta.snasw1snasw port FASTETH0 FastEthernet0/0 conntype nohpr

LLC2 Error Conditions

LLC2 セッションの一部のエラーは正常かつ回復可能ですが，例えば，時々発生するフレームの欠番やフレームの順序がずれていることが挙げられます。 これらは通常、REJと再送信されたフレームになります。 過剰な再送信は正常ではないので、原因を特定し、問題を解決する必要があります。 過剰な再送信は、ドロップ、複数のパス、輻輳、過度の遅延が原因で発生することがあります。

LLC2の一部のエラーは回復不可能で、常にセッションの停止につながります。 これらのエラーは専らプロトコル違反です。 これらのエラーは、ステーションが未定義のコントロールフィールドや他の誤った情報を送信したときに発生する可能性があります。 これらのプロトコル違反は、ステーションが FRMR 応答を送信する原因となることがあります。 FRMR応答を送信するステーションは、ほとんどの場合、違反者ではなく、単なるメッセンジャーである。 FRMRは、FRMRがなぜ送られたかを特定する情報を含んでおり、それは最も一般的には、局が他の局に対して、すでに承認したIフレームを再送するよう要求するときです。 フレームを再送信できないため（すでに廃棄しているため）、LLC セッションを終了するほかはありません。 このようなエラーが発生した場合、最も考えられる原因はフレームの順序が狂っていることです。