IS-ISは拡張が繰り返されて多くの機能が盛り込まれています。IS-ISの関連文書と主要な拡張内容について説明します。
Contents
- 拡張内容
- RFC2973 IS-IS Mesh Groups
- RFC3719 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)
- RFC3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS)
- RFC4444 Management Information Base for Intermediate System to Intermediate System (IS-IS)
- RFC5301 Dynamic Hostname Exchange Mechanism for IS-IS
- RFC5302 Domain-Wide Prefix Distribution with Two-Level IS-IS
- RFC5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies
- RFC5304 IS-IS Cryptographic Authentication
- RFC5305 IS-IS Extensions for Traffic Engineering
- RFC5306 Restart Signaling for IS-IS
- RFC5308 Routing IPv6 with IS-IS
- RFC5309 Point-to-Point Operation over LAN in Link State Routing Protocols
拡張内容
IS-ISはIPに依存せず汎用性が高いことから当初のOSIネットワークのIGPという役割を越えて様々な使われ方をしています。Integrated IS-ISの拡張機能はRFCだけでもかなりの分量があります。このページでは下表のIntegrated IS-ISのIPルーティングに関する拡張について説明します。
| RFC | 用途 |
| RFC2973 | メッシュグループ |
| RFC3719 | ISO/IEC10589の推奨する実装 |
| RFC3787 | RFC1195の推奨する実装 |
| RFC4444 | IS-ISのMIB |
| RFC5301 | ISのホスト名を通知 |
| RFC5302 | レベル2からレベル1へのLSP送信 |
| RFC5303 | スリーウェイハンドシェーク |
| RFC5304 | MD5認証の追加 |
| RFC5305 | MPLS-TEに関する拡張 |
| RFC5306 | グレースフルリスタート |
| RFC5308 | IPv6への対応 |
| RFC5309 | ブロードキャスト回線をポイントツーポイント回線として使用する |
概要のページでも説明している通りIntegrated IS-ISの拡張は基本的にTLVオプションの追加によって行われます。一覧はこちらで確認できます。
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xml
IS-ISドキュメント関係図
RFC2973 IS-IS Mesh Groups
ポイントツーポイント回線（ATMやフレームリレーなどの仮想回線を含む）を使用してメッシュ接続する場合に不要なPDUの送信を抑えるための機能拡張です。この機能はローカルでのみ有効で基本的にIS間での情報交換は発生しませんが、トポロジー全体で統一した設定が必要です。設定は静的であるためトポロジーが変化のないことが条件となります。定義された追加のオプションはありません。
例えば下図のIS1からLSPを送信するとIS2、IS3、IS4へ直接届きます。次にIS2はIS1のLSPをIS3とIS4に送信しますが、IS3とIS4はすでに同じLSPを持っているため無駄な送信になります。このような無駄な転送が発生しないように、パスをグループにまとめLSPを受け取ったパスと同じグループのパスには送信しない動作を行うのがMesh Groupsの機能です。
メッシュグループを使用する（meshGroupEnabled）場合、各回線は以下の状態のいずれかになります。
| 状態 | 変数 | 意味 |
| meshInactive | – | メッシュグループが無効 |
| meshBlocked | – | LSPを送信しない |
| meshSet | meshGroup | メッシュグループが有効 |
メッシュグループの基本動作は3つあります。
・LSPを受け取ったパスがグループに設定されている
・LSPを受け取ったパスがグループに設定されていない
・自ら作成したLSP
LSPを受け取ったパスがグループに設定されている
受け取ったポートがmeshSet（ポートにグループ設定がされている）の場合、同じメッシュグループとmeshBlockedポート以外のポートから送信します。ただし、CSNP受信時の動作については変更されていないため、初期化時などに相手からCNSPを受信し相手に足りていないLSPが存在する場合には同じグループ内でも転送（要求による返信）される可能性があります。
下図はGroup10が設定されたインターフェースから受け取ったLSPを同じGroup10のポートとBlockedポート以外から送信しています。同じグループのポートはすでに受け取っているので送信しないという考え方です。
LSPを受け取ったパスがグループに設定されていない
受け取ったポートがmeshInactiveの場合はmeshBlocked以外のポートから送信します。
下図はグループ設定が行われていないInactiveのポートから受け取ったLSPをBlocked以外のポートから送信しています。グループ設定が行われていないポートからのLSPは通常通りすべてのポートから転送しますが、明確にブロックされているポートは除外します。
自ら作成したLSP
自分が作成したLSPはmeshBlockedポート以外のポートから送信します。ただし、初期化時にはすべての状態のポートに送信します。
下図は自分が作成したLSPをBlocked以外のポートから送信しています。自分が作成したLSPは自分しか知り得ないためすべてのポートから送信します。
RFC3719 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)
ISO/IEC10589を実装する場合の推奨を示しています。標準の定義ではなくすでに存在する機器の傾向から実装におけるIS-ISの解釈をまとめています。理論的には問題ない場合でも実装した機器が適切に動作・互換することが目的です。
１）可変の定数
・MaxAge ＝ 20分（規定通り）
・ISISHoldingMultiplier ＝ 3（規定値10）
２）定数の変数
・ID長 ＝ 6オクテット（固定）
・maximumAreaAddresses ＝ 3（0でも可、0は3として扱われる）
・PDUヘッダの” Version/Protocol ID Extension”と”Version” ＝ 1
PDUヘッダ内には2つの”Version”フィールドが存在しています。”Version/Protocol ID Extension”はプロトコルのバージョンと示されていますが、”Version”の役割はISO/IEC10589でも記されていません。このRFCでは両方の値を1に設定し、それ以外の場合は破棄しなければならないとしています。
３）4つのメトリックのサポート
・ほとんとの実装においてデフォルトメトリック以外は使用されず、デフォルトメトリックのみを考慮する
４）大きなサイズのPDUを受信する場合の対応
・ネットワーク全体でReceiveLSPBufferSizeの値を同じにする
・少なくてもReceiveLSPBufferSizeと同じ大きさのMTUをサポートしない回線ではIS-ISを有効にしない
・LSPにoriginatingLSPBufferSize TLVを含める
・LSP受信時にoriginatingLSPBufferSize TLVをチェックする
・ローカルよりも大きいPDUの受信をNotifications and Alarmsを使用して報告する
・ネットワークの一貫性を維持するために受信した大きなPDUを破棄しない
５）隣接関係がUPになるまではIIHをパディングする
自分と相手のバッファのサイズが異なる場合、不正な片側のISがLSPを受信できずに不整合なルートが作成されてしまう可能性があります。その問題を回避するためバッファ（PDUのサイズ）が異なる場合は隣接関係を強制的に解消されるようにIIHを最大値までパディングします。ISO/IEC10589規定の「初めのIIHのみパディングを行う」からの変更です。
６）ゼロチェックサムで受け取ったLSPをエラーとして処理する
ISO/IEC10589ではゼロチェックサムのLSPはパージするとされていますが、混乱をもたらすためLSPを取り込む前に削除されるべきであるとしています。
７）破損したPDUのパージ
無効なチェックサムで受信したLSPはパージするのではなく、混乱をもたらすためLSPを取り込む前にLSPが削除されるべきであるとしています。
８）ポイントツーポイントIIH PDUのIDの確認（ISO/IEC10589の不備の補間）
ポイントツーポイント回線では受信したIIHを無条件に隣接として受け入れるため、IIHの破損などで誤った隣接を認識してしまう可能性があります。そこでIIHで受信したIDを隣接のIDと比較を行い、異なっている場合には隣接関係は削除される方法を示しています。
９）ISがシャットダウンした場合のLSPの扱いについて
ISがシャットダウンするとLSPはパージされますがMaxAgeを迎えるまで削除されないため、新しいLSPよりもシーケンスナンバーが新しいと判断される可能性に関しての注意です。
１０）CSNPの完全なセットの作例
RFC5306などで要求されるCSNPの完全なセットの指定方法を示しています。
１１）過負荷状態のDISが作成する疑似ノードLSPのオーバーロードビットを無視する
IS-ISはISが過負荷状態に陥るとLSP内のLSPDBOLにフラグを立てます。これによってLSPの格納を妨げる一時的な問題に対応できます。ただし同時に完全な情報がそろわないことから正しいルートを計算できない可能性があります。そこでDISが過負荷に陥った際には疑似ノードのLSPDBOLは設定しない。また設定されていても無視する実装をするべきであるとしています。
RFC3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS)
RFC1195を実装する場合の推奨を示しています。標準の定義ではなくすでに存在する機器の傾向から実装におけるIntegrated IS-ISの解釈をまとめています。理論的には問題ない場合でも実装した機器が適切に動作・互換することが目的です。
１）以下の機能は使用されていないので受信した場合は無視します
・IDRP用TLV（コード131のTLV）
・認証情報用TLV（コード133のTLV）
２）オーバーロードビットの実装
ISの過負荷状態を通知するオーバーロードビットを、BGPなどと連携しトラフィックの受け入れができていないことを通知する実装にすると実用的であることが示されています。そのほかに以下の事が再確認されています。
・疑似ノードのオーバーロードビットは無視する
・オーバーロードビットがセットされたLSPのIP到達可能性情報は直接接続しているものとして扱う
３）ワイドメトリックへの移行
RFC3784で定義されたワイドメトリックを使用する場合はIS-ISを動作するすべてのデバイスでサポートしている必要があることと、従来のメトリックからワイドメトリックへの移行手順とSPF計算の変更箇所が示されています。RFC5305（RFC3784）を参照
４）ポイントツーポイント回線におけるISH PDUについて
IPのみの環境においてはポイントツーポイント回線で隣接関係の開始時にISH PDUの送信は不要であるとしています。
５）アタッチドビットの扱い
アタッチドビットはISが他のエリアに到達できることを表すために使用します。ここではローカルルーティングテーブルにデフォルトルートがある場合にアタッチドビットが設定できる実装が存在することを示しています。
６）デフォルトルートについて
RFC1195ではレベル1でのデフォルトルートは許可されていませんが、有用な場合は実装する場合があることを示しています。
７）Protocols Supported TLVの不完全性について
RFC1195から追加されたProtocols Supported TLVは十分に定義されておらず発生する問題の解決には不完全でありITU-Tで解決に取り組んでいることが示されている。
８）IPインターフェースアドレスについて
Integrated IS-ISでは隣接関係構築時にIPサブネットが同じであるかどうかをチェックしません。IPアドレスがどのようなものでも隣接関係が構築されます。複数のDISが選択されたり、不正なルートが発生するなど、いくつかの問題を回避するためにはIIH PDUにIPインターフェースアドレス（TLV 132）を含め同じサブネットに属するかどうかを確認する必要があります。
RFC4444 Management Information Base for Intermediate System to Intermediate System (IS-IS)
Integrated IS-ISの管理オブジェクトを定義します。MIBツリーにMIB-2としてisisMIBを追加します。isisMIBノードのオブジェクトIDは138で階層は1.3.6.1.2.1.138です。Integrated IS-ISはOSIのIS-ISの拡張版ですが、このRFCによって管理上は異なるプロトコルとなります。
OSIのシステムマネジメントとインターネットのシステムマネジメントは両方ともASN.1を使用してOIDツリー（X.660）に対してマッピングしていることは同じですが、ISO10589はGDMO（ISO/IEC10165）を使用するのに対してRFC4444はSMIv2（RFC2578）を基準にしてMIBを作成します。OSIのIS-ISはGDMOを使用したオブジェクトが定義されていて、Integrated IS-ISにはこのRFCでインターネットのオブジェクトが定義されることになります。IS-ISとIntegrated IS-ISではオブジェクト定義の構造が全く異なりOIDやオブジェクト名も違っているため厳密な比較はできませんが、OID数の単純比較ではRFC4444のオブジェクトは250を超えており、OSI IS-IS（ISO10589）の170ほどから1.5倍ほどに増えています。これまで発行されているRFCのオブジェクトなども対象となっていて例えばワイドメトリックスに対するオブジェクトなども含まれています。このRFCで定義されている一部のオブジェクト（全体の3分の1程度）はOSIのIS-ISのオブジェクトへの関係（REFERENCE）がRFC内で示されています。
OSIプロトコルのIS-IS（ISO10589（ISO10733 / X.283））と比べると以下のような違いがあります。
| IS-IS | Integrated IS-IS | |
| システム管理情報 | ISO10589 （ISO10733 ｜ X.283） | RFC4444 |
| 構文 | GDMO, ASN.1 （X.680） | ASN.1 （X.680） |
| 表記法（ルール） | GDMO （ISO/IEC10165-4, X.722） | SMIv2 （RFC2578） |
| 定義物 | MIB | MIB-2 （MIB-1に対するMIB-2） |
| OID | 2.13.0.1 | 1.3.6.1.2.1.138 |
| 通信プロトコル | CMIP | SNMP |
RFC5301 Dynamic Hostname Exchange Mechanism for IS-IS
ISのホスト名を通知するTLVを追加します。ISの識別はID（システムID）によって行われますが、数字での識別のため判別しやすいとは言えません。ISのホスト名を通知することでISを明確に識別することができるようになります。新しくTLVオプションとしてDynamic Name（Type 137）を追加します。
| Code | 137 |
| Length | Valueの長さ |
| String | 1-255バイトの文字列 |
RFC5302 Domain-Wide Prefix Distribution with Two-Level IS-IS
レベル2からレベル1へルート情報（IP到達可能性情報）を送信するための拡張です。RFC1195 のIntegrated IS-ISではルーティングフィードバックによる不適切なルートを回避するため、レベル1内のL1L2 ISまでのルートはアタッチドフラグによるルート（実質デフォルトルート）を使用し、逆方向であるレベル2内のL1L2 ISまでのルートはレベル1から転用したレベル2のルート情報によってルーティングを行います。つまりエリアやレベル2で発生するルート情報の二次的な利用をレベル1からレベル2への一方向に限定することで不適切なルートの発生を抑えています （下図） 。
大体の場合はこの動作で問題ありませんが、レベル1のエリアに対しても他のエリアのIP到達可能性情報が必要となる場合にはこの拡張によってレベル2からレベル1へルート情報を配送できるようにします。ただしルーティングフィードバックが発生しないようにレベル2からレベル1への配送時にup/downビットを1に設定します。このビットが設定されているIP到達可能性情報はレベル1からレベル2への配送には使用しないことでルーティングフィードバックが発生しないようにしています。
up/downビットはTLV128、130のデフォルトメトリックフィールドの予約済み最高位ビット（ビット8：0固定）を再定義して使用します。
RFC5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies
ポイントツーポイント回線において隣接関係を構築する際にスリーウェイハンドシェークを使用します。OSIのIS-ISでは、ISはポイントツーポイント回線でHelloパケットを受信すると相手側に到達可能（隣接）であると認識し、同期プロセスに入る準備を行います。このポイントツーポイント回線上の動作は認識が一方的であるため、同時点で相手に自分の状態を知らせる機会を与えることができず自分の認識と相手の認識にずれが生じる可能性があります。ポイントツーポイント回線にスリーウェイハンドシェークを導入することによってHelloパケット（DownもしくはInitialaizing）に対するレスポンス（InitialaizingもしくはUp）を得ることができるため同時点での認識を合わせることができるようになります。またこのRFCでは回線IDの上限を回避するためポイントツーポイント回線の回線IDをすべて共通固定にした実装にも対応しています。
Hello PDUに以下のオプションを使用します。コードとして240（0xF0）が追加されます。
| Code | 240 |
| Length | Valueの長さ |
| Adjacency Three-Way State | 隣接に対する状態 0 — Up 1 — Initialaizing 2 — Down |
| Extended Local Circuit ID | ISのこの回線に割り当てられた一意のID。 |
| Neighbor System ID | すでにネイバーからこのオプションを含むIIHを受信している場合、ネイバーのシステムID |
| Neighbor Extended Local Circuit ID | すでにネイバーからこのオプションを含むIIHを受信している場合、ネイバーの拡張ローカルサーキットID |
IS-ISのスリーウェイハンドシェークは下図の動作になります。このRFCによる認識プロセスはIIH内にステータスを含めるなどの違いはありますが、基本的にブロードキャスト回線の隣接と同じ動作となります。
この動作を見るとIIHがつながっているように見えるためTCPセッションのスリーウェイハンドシェークと同じように見えますが前提としている環境が異なるため性質が少し異なります。TCPがデータグラムネットワーク（IP）上で動作するため不特定多数の中から1つの相手とセッションを確立するのに対して、IS-ISの隣接はポイントツーポイント回線のサブネット上での動作が前提であるため必ず一対一です。TCPはIPアドレスやポート番号でセッションを識別したりSequence NumberやAcknowlegement Numberを使用してセッションの同期を管理しますが、IS-ISの隣接はネイバーの状態だけ管理を行います。どちらのスリーウェイハンドシェークも相手が自分を認識したことを知ることで隣接となるのは同じですがIS-ISの隣接はTCPのように必ず”3Way”となるわけではなく下図のように各ISが個別のIIHを1往復するだけで隣接となります。
RFC5304 IS-IS Cryptographic Authentication
認証にMD5認証を追加します。OSIのIS-ISでは認証方式としてクリアテキストパスワードのみ対応していましたが、セキュリティを向上させるためHMAC-MD5の認証を追加します。PDUで使用するPDUオプションは同じ10でHMAC-MD5の認証タイプコード54が追加されています。現在IS-ISで使用する認証タイプコードは以下のように決まっています。
| Code | 10 |
| Length | 認証情報の長さ |
| Authentication Type | 0 — 予約（ISO10589） 1 — クリアテキストパスワード（ISO10589） 2 — 予約（ISO10589） 3 — CRYPTO_AUTH（RFC5310） 4-53 — Unassigned 54 — HMAC-MD5（RFC5304） 55-254 — Unassingned 255 — ドメイン内プライベート認証（ISO10589） |
| Authentication Value | 認証値 |
最新の情報は以下のサイトから確認できます。
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xml#isis-tlv-codepoints-10
RFC5305 IS-IS Extensions for Traffic Engineering
MPLS-TEに対応するため新しく3つのTLVが定義されます。MPLS-TEはRFC2702で定義されていてこのRFCではIS-ISをMPLS-TEに対応させるための拡張という位置づけになります。この拡張によってデフォルトメトリックは6bitから3オクテットに拡張されます。
CODE 22 Extended IS Reachability
このTLVはISの到達可能性情報を扱います。ISのIDに対してメトリックとIPアドレスを紐づける情報が付加されます。メトリックはデフォルトメトリックのみを対象とし長さが3オクテットに拡張されています。デフォルトメトリック以外の情報はサブTLVの形で埋め込まれる構造をしていて必要に応じて付加されます。サブTLVはTLVと同じ構造をしていてサブタイプ、サブTLVの長さ、サブTLVの値の順で記述します。このTLVはTLVタイプ2のIntermediate System Neighborsを置き換えます。
| Code | 22 |
| Length | Valueの長さ |
| System ID and Pseudonode No | ISの疑似ノードID（1オクテット）付きのシステムID（6オクテット） |
| Default Metric | 1-16777214 3オクテットのメトリック値 |
| Length of sub-TLVs | サブTLVの長さ |
| Sub-type | 下表参照 |
| Sub-TLV Length | |
| Sub-TLV Value |
サブTLVは下表のように定義されます。この中でSub-TLVタイプ6のIPv4 interface addressがTLVタイプ132のIP Interface Addressを置き換え、Sub-TLVタイプ8のIPv4 neighbor addressがTLVタイプ2のIntermediate System Neighborsを置き換えます。そのほかのSub-TLVタイプはMPLS用となりRSVP-TEのパス計算で使用されます。
サブTLVタイプ
| Sub-TLV タイプ | Length(octets) | Name |
| 3 | 4 | Administrative group |
| 6 | 4 | IPv4 interface address |
| 8 | 4 | IPv4 neighbor address |
| 9 | 4 | Maximum link bandwidth |
| 10 | 4 | Reservable link bandwidth |
| 11 | 32 | Unreserved bandwidth |
| 18 | 3 | TE Default metric |
| 250-254 | Reserved for cisco specific extensions | |
| 255 | Reserved for future expansion |
CODE 135 Extended IP Reachability
IPプレフィックスに対するリンク情報を扱います。IPプレフィックスに対してメトリックと制御情報を付加します。メトリックはデフォルトメトリックのみを対象とします。下図では4オクテットのメトリックフィールドが定義されていますが、メトリック自体は3オクテットでエンコードされます。つまりIS到達可能性情報と同じ3オクテットのメトリック幅になります。コントロール情報ではアップダウンビットの設定とサブTLVの有無、プレフィックスの長さが指定されます。サブTLVが設定されていますがこのRFCでは定義されていないため0に設定します。プレフィックスの長さはIPv4 Prefixフィールドのプレフィックスの長さを指定します。このTLVはRFC1195のTLVタイプ128と130の IP Reachability Informationを置き換えます。
| Code | 135 |
| Length | Valueの長さ |
| Metric Information | 1-16777214 3オクテットのメトリック値 |
| Control Information | bit8 — up/down information bit7 — presence of sub-TLVs bit1-6 — prefix length up/downビットが1の場合はレベル2からレベル1への情報であることを示す presence of sub-TLVsが1の場合はサブTLVが存在することを示す prefix lengthは0-32の値でIPv4 prefixの長さを示す |
| IPv4 prefix |
IPv4のプレフィックス この値は可変長でprefix lengthの値によって変化する prefix length 0 = 0オクテット prefix length 1-8 = 1オクテット prefix length 9-16 = 2オクテット prefix length 17-24 = 3オクテット Prefix length 25-32 = 4オクテット |
| Length of sub-TLVs | サブTLVの長さ |
| Sub-type | 定義なし |
| Sub-TLV Length | |
| Sub-TLV Value |
CODE 134 Traffic Engineering Router ID
ISを識別するための新しいTLVです。RFC1195においてIPアドレスでISを特定するのはTLVタイプ132のIP Interface AddressですがこのアドレスはISに設定されたIPアドレスの中から選択されるためインターフェースの状態によって変化する可能性があります。このTLVでは固定的なルータIDを表すことで安定したアドレスがあることが保証されます。
| Code | 22 |
| Length | Router IDの長さ |
| Router ID | IS固有のIPアドレス |
RFC5306 Restart Signaling for IS-IS
ISを再起動する際に発生する問題に対応するためのTLVです。いわゆるグレースフルリスタート機能です。このTLVをネイバーに通知することによってネイバーは再起動中でも隣接状態を保持し続けるため、IS-ISのプロセスが再起動中にルーティングが停止しないようになります。この機能はISの制御機能と転送機能を独立して維持できることを前提とし、ポイントツーポイント回線のスリーウェイハンドシェーク（RFC5303）も有効になっている必要があります。また、再起動を行うISのネイバーもこの機能を解釈できる必要があります。このRFCではISを再起動する際の再同期に関する機能と、ISを起動する際に公告を抑制する機能が盛り込まれています。
追加のオプションとしてオプションコード211が追加されます。
| Code | 211 |
| Length | Valueの長さ（ID Length + 3） |
| Flags |
bit1 — RR（ Restart Request） bit2 — RA（Restart Acknowledgement） bit3 — SA（Suppress adjacency advertisement） |
| Remaining Time | 再起動ISに対する隣接がタイムアウトするまでの時間 |
| Restarting Neighbor ID | 再起動するISのネイバーのシステムID。RRフラグを含むIIHを受け取ったことを明示するため、RAフラグを設定したIIHを返信するISのシステムIDを設定する |
タイマー
| T1 | インターフェースごとに設定されるタイマー。このタイマーが満了するとRRビットが設定されたIIHを送信する。デフォルト3秒 |
| T2 | IS-ISのインスタンスごとに設定されるタイマー。このタイマー（正確にはT2とT3の小さいほう）が満了するまでに同期を完了しなければならない。デフォルト60秒 |
| T3 | ISに設定されるタイマー。この時間内にISの全てのインスタンスを再起動しDBの同期を完了しなければならない。初期値は65535秒、ネイバーから受信するRAの含んだIIH PDUのRemaining Timeの最小値で置き換えられる。全てのT2が終了するとキャンセルされる。 |
制御機能の再起動に伴うLSPの再取得
制御機能と転送機能が独立して機能している場合、ISは自由なタイミングで制御機能を再起動することができます。ただ、その際に再起動ISが初期化されたIIHの送信することによってネイバーとの隣接が解消されます。
・ポイントツーポイント回線の場合、Three-Way Handshake for IS-IS Point-to-Point Adjacencies オプションのAdjacency Three-Way State がDownに設定されたIIHの受信
・ブロードキャスト回線の場合、Intermediate System NeighborsオプションのLAN Addressが空のIIHの受信
隣接が解消されるとSPFの再計算とLSPの広告が連鎖的に起こり経路が変わります。この動作はIS-ISの通常の動作で問題ではありませんが、ネットワーク全体に与える影響は単純にISを再起動したときと違いはありません。またローカルのLSPにほとんど変化がない場合にはネットワークに負荷を与えるだけのものとなってしまいます。
この機能では制御機能と転送機能が独立しているメリットを活かしてIIHにリスタートオプションを追加して制御機能だけを再起動した際にネイバーと隣接関係を保持させながらLSPの同期を行い極力ネットワークに負荷を与えずに収束させ問題の発生を抑えます。
１）再起動IS（IS1）は制御機能を再起動します。制御機能と転送機能が分離されていると、制御機能の再起動はどのタイミングでも行えます。再起動後に各タイマーをスタートさせます。タイマーの初期値は図の通りとなっています。
２）IS1はT1が満了するとRRビットを設定したIIHを送信します。再起動を行ったISはネイバーに隣接状態を保持させることとLSPの同期をいち早く終わらせる必要があります。IIHにRRビットを設定することによってネイバーに対してIS1が再起動を行った事を伝えます。この時、初期化されたIIHをそのまま送信すると隣接が解消されてしまうため、ポイントツーポイント回線の場合はステータスがInit、ブロードキャスト回線の場合はIntermediate System NeighborsオプションのLAN Addressが前回と同じMACアドレスをセットしたものを使用します。
ネイバーであるIS2はIIHを受信すると通常通りの更新動作を行ったうえで、RRビットが設定されていることでIS1に対する隣接を”Restart mode”としてマークします。RRビットの設定されたIIHによるHolding Timeの更新は初めの1回だけであるため、Holding Timeが満了するまでに同期を終えRRビットの設定されていないIIHを受信し再起動モードのマークをはがす必要があります。IS2の隣接の動作に変化はないためIS1に対するHolding Timeが満了すると隣接は解消されます。
IS3もネイバーですが、こちらは再起動オプションに非対応であるためIIHを受信し通常の更新動作を行いますが、RRフラグは無視されます。
３）再起動オプションに対応したISはRRビットが設定されたIIHを受信したことと、IS1に対する隣接の有効期限を知らせる必要があるため、IS2はIIHにRAビットを設定することによってRRビットが設定されたIIHを受信したことをIS1に対して伝えます。そして同じIIH内のRemaining TimeにIS1に対する隣接のHolding Timeを設定することで有効期限を伝えます。同時にIFがLANインターフェースである場合にはRestarting Neighbor IDにIS2のシステムIDを設定します。これは複数のISが再起動する場合の識別で使用されます。
IS1はRAフラグが設定されたIIHを受信すると通常の動作としてIS2と隣接（UP）となります。そしてIS2の持つIS1に対する隣接の有効期限を知りIIHのRemaining Timeの値をT3に設定します。もし、このオプションに対応する複数のネイバーが存在する場合は一番小さな値を設定します。IS1はT3が満了するまでに同期を終えなければなりません。もしT3の満了までに同期が終わらなければ（T2よりもT3が先に満了した場合も同様）は通常の更新プロセスが再開されて再起動オプションのフラグが設定されていない通常のIIHをすべてのインターフェースから送信しネイバーは隣接関係を更新します。図では同時にIS3もIIHを送信していますが、これはIS3がDISで1秒ごとにIIHを送信するためです。IS3は再起動オプションに対応していないためこのIIHにはRAフラグなどは設定されません。
４）ここまでで隣接が保持されたことが確認できたため続いてLSPの同期作業を開始します。IS1の隣接の中でこのオプションに対応し一番プライオリティ（プライオリティ＋MACアドレス）の高いネイバーがCSNPを送信します（ポイントツーポイント回線のネイバーは無条件にCSNPを送信します）。下図の場合はIS2が対象となります。また同時にすべてのLSPに対してSRMフラグを設定（LSPを送信）します。IS1はCSNPとLSPを受信することで必要なLSPと同期状態を管理することができます。
５）IS1はCSNPとLSPを使ってすべてのLSPを受信したことを確認できるとすべてのタイマーをキャンセルしIS2に対してRRビットの解除された通常のIIHを送信します。
IS2はIIHを受信するとIS1に対する隣接の再起動モードのマークを解除して通常の隣接となります。
この説明ではDISであるIS3は全く機能していないですが、DISは10秒間隔でCSNPを送信するためタイミングによってはIS2のCSNPよりも早く送信する可能性があります。
制御機能の起動時のLSA配布の抑制
この機能は前の「制御機能の再起動」に対する機能とは異なり、IS-ISの開始する際の影響を抑えます。この「開始」はISの初回起動時ではなくプロセスが停止した後開始するような再起動よりも長い停止後に開始することを指しています。この機能はすでに隣接は失われてはいるがLSPは残存している可能性のある状態で開始する際に発生する問題に対応します。この場合、起動したISが作成するLSPのシーケンスナンバーよりもネットワーク上に残存しているLSPのシーケンスナンバーの方が新しく見えてしまうことになり、これにより起動ISによってより高いシーケンスナンバーのLSPを作成するまで正しくないルートができてしまう可能性があります。この機能では開始したISによって残存しているLSPよりも新しいLSPが作成できるまで、ネイバーに対して隣接への広告を抑制させることで不正なルートが発生しないようにします。
１）下図ではIS1のプロセスが停止しIS2との隣接は失われていますが、IS2にはIS1のLSPが残っている状態です。ISが開始するとT2が開始されます。
２）起動ISは通常のIIHのやり取りによって隣接関係がUPの状態になるとT1を開始すると同時にSAビットを設定したIIHを送信します。SAビットを設定したIIHを受信したIS2は以前に再起動ISから受信したLSAの配布を抑制します。同時に過負荷ビットの設定したLSPを送信します。このLSPによってIS2がSPF計算でIS1経由のルートを計算しなくなります。この過負荷ビット（LSPDBOL）を設定したLSPを受信した時の動作はIS-ISの標準の動作です。
３）IS1はT1が満了するとRRとSAビットが設定されたIIHを送信します。RRビットが設定されていることよってIS2は隣接を再起動モードとマークしHolding Timeを更新します。
４）IS2はIS1に対してSAビットを設定したIIHを送信します。このIIHを受信したIS1はIS2がLSP広告を抑制している状態であることを認識します。同時にIS2はRAビットの設定されたIIHを送信します。このIIHにはIS2のHolding Timeが設定されていて、IS1はT3をこの値に更新します。IS1はT3が満了するまでに同期を終える必要があります。
５）起動ISはネイバーとLSPの同期をとり、自身の新しいLSPをネイバーのLSPと比較します。もし、自身の新しいLSPよりも大きいシーケンスナンバーを持つLSPが存在する場合は、自身の新しいLSPのシーケンスナンバーをより大きいシーケンスナンバーに更新します。下図はIS2がシーケンスナンバーが5の古いLSPをIS1に送信している様子です。IS1では受信したLSPが自分の保持するLSPと異なるためこのLSPを無視し、自分の持つLSPのシーケンスナンバーを受信したものよりも大きい値（6）に更新します。この動作はIS-ISの標準の機能です。
６）新しくシーケンスナンバーを更新したLSPをIS1が送信しIS2のLSP DBが更新されます。
７）IS1のインターフェースで同期が完了（CSNPと確認応答を受信）するとT1はキャンセルされSAビットのみが設定されたIIHを送信します。RRビットがクリアされているのでIS2は再起動モードがクリアされてHolding Timeが更新されます。
８）さらにすべてのT1のキャンセルによってT2がキャンセルもしくは満了すると通常のIIHが送信されます。このSAビットがクリアされた通常のIIHによってネイバーは隣接に対するアップデートの抑制を解除し新しいLSPをネットワーク内に伝搬します。そしてすべてのT2がキャンセルされるとT3がキャンセルされてIS1は通常の動作へ移ります。もしT3の満了までに同期が終わらなければ（T2よりもT3が先に満了した場合も同様）は通常の更新プロセスが再開されて再起動オプションのフラグが設定されていない通常のIIHをすべてのインターフェースから送信しネイバーは隣接関係を更新します。
RFC5308 Routing IPv6 with IS-IS
Integrated IS-ISをIPv6に対応させるオプションです。Integrated IS-ISはOSIネットワーク用のプロトコルであるIS-ISをIPにも対応させた位置づけであるため、ルーティングに必要な情報の転送をIPに依存せずに行えます。OSPFのようにIPv6対応としてOSPFv3を作成するようなことが必要がなく、IPv4に対応した時と同じようにこのオプションを追加することでIPv6に対応します。実装の対応は必要ですがSPFのアルゴリズムに変更はありません。ただし、メトリックが拡張されているため、SPF内で使用するMaxPathMetric（Max_Path_Metric）は1,023から4,261,412,864（0xFE000000、2 ^ 32-2 ^ 25）へ変更されます。IPv6に対応したことによってProtocols Supported オプションのNLPID（Network Layer Protocol Identifier）として142（0x8E）が追加されます。NLPIDについてはPDU一覧のオプション（CODE 129 Protocols Supported）を参照してください。
2つのTLVが追加されています。
CODE 232 IPv6 Interface Address TLV
IPv6アドレスのインターフェースアドレスを記述します。役割はRFC1195のIP Interface Address（CODE 132）と同じですが、複数のIPv6アドレスを含める場合は最大が15になっています。
使用されるPDU：L1IIH, L2IIH, P2PIIH, L1LSP
| Code | 232 |
| Length | Valueの長さ |
| Interface Address | インターフェースに設定されたIPv6アドレス |
CODE 236 IPv6 Reachability TLV
IPv6アドレスの到達可能性情報（プレフィックス、メトリックなど）を記述します。役割はRFC1195のIP Internal Reachability Information（CODE 128）と同じです。
使用されるPDU：L1LSP, L2LSP
| Code | 236 |
| Length | Valueの長さ |
| Metric | 1-16777214までの整数 回線のメトリック。3オクテットの数値ですが、4オクテットで符号化されます。 |
| U — up/down bit | 0 — 通常 1 —レベル2からレベル1へ配布された場合 |
| X — external original bit | 0 — 通常 1 — 別のルーティングプロトコルからIS-ISに配布された場合 |
| S — subtlv present bit | 0 — 通常 1 — SubTLVが存在する場合 |
| Prefix Length | Prefixの長さ |
| Prefix | IPv6プレフィックス |
| Sub-TLV Length | Sub-TLVの長さ |
| Sub-TLVs | Sub-TLVの中でTLV形式の情報を持ちます Type — Sub-TLVタイプ（1オクテット） Length — Sub-TLVのValueの長さ（1オクテット） Value — Sub-TLVの値 |
RFC5309 Point-to-Point Operation over LAN in Link State Routing Protocols
ブロードキャスト回線をポイントツーポイント回線として扱います。Ethernetのようなブロードキャスト回線に2つのISだけが接続されている場合、DISの選定や疑似ノードの作成は理論的に無駄な動作です。この拡張では2台のISがブロードキャスト回線で隣接になる場合にポイントツーポイント回線としての動作を行うことで無駄な動作を省けることを説明しています。ただし、この拡張では具体的な方法は示されておらず概念だけが説明されています。
IS-ISとしては以下の動作を行います。
・ブロードキャスト回線がポイントツーポイント回線として設定されている場合、LANのHelloパケットを受信すると削除する
・ブロードキャスト回線でポイントツーポイントのHelloパケットを受信すると削除する
物理回線がポイントツーポイントの回線はアンナンバード設定にできることが一つの特徴であり一般的に使用されます。しかしブロードキャスト回線上のポイントツーポイント接続では物理回線がブロードキャスト回線であるため隣接のアドレスの解決を避けることはできません。選択肢としては以下の方法があります。
・ARPを使用する
ARPを使用することで転送先のMACアドレスを取得します。つまりブロードキャスト回線の通常の使用方法です。ただし、インターフェースのIPアドレスをアンナンバードにする場合は、ARPをISの内部IPアドレスからMACアドレスに解決するように実装しなければなりません。
・静的構成を使用する
相手のIPアドレスもしくはMACアドレスを事前に登録しておきます。IS-ISはインターフェースを使用する際に登録されたアドレスに対して送信します。この方法はアンナンバードが使用できます。
・自動で学習する
IS間のルーティングプロトコルからリモートISのMACアドレスを自動で学習します。ただし、”ルーティングプロトコル”が具体的に何であるかは示されていません。
この拡張ではIS-IS以外にOSPFv2、OSPFv3も対象に含まれています。