OSPFで使用するパケットについて説明します。概要ではパケットの種類と役割について、それ以降ではパケットの作成と、送信時、受信時の動作についてまとめています。
Contents
■概要
OSPFでは5つのパケットを使用して他のルータと情報をやり取ります。OSPFでは大きく分けると近隣のルータを認識するネイバーの関係と、LSAを交換する隣接関係の2つの関係がありますが、ネイバーの関係はHelloパケット、隣接関係（LSAの同期）はそれ以外のパケットを使用します。
パケットの種類
OSPFで使用するパケットは以下の種類があります。ルータが以下のパケットを作成、送信します。Helloはネイバーを発見して認識するためにOSPFとして動作するすべてのインターフェースから送信します。Hello以外のパケットはネイバーの中から隣接関係になる相手に対して送信します。なおOSPFのLSAパケットはデータパケットよりも優先して処理されます。
| パケット | 役割 | 目的 | 送信先 |
| Hello | ルータの存在を通知する | ネイバーの発見と維持 | 隣り合うOSPFルータ |
| Database Description | 保持している情報の一覧 | 隣接関係の構築とDB更新 | 隣接関係の相手 |
| Link State Request | 情報提供を要求 | ||
| Link State Update | 情報を提供 | ||
| Link State Acknowledgment | 受け取り確認 |
Helloパケットの役割
Helloパケットは主にネイバーの発見、ネットワークタイプの決定、存在通知・確認に使用します。Helloパケットは常に一方的な送信で通常は10秒間隔で送信します。受け取ったHelloパケットに自分のルータIDが含まれていればネイバーとなり、Helloパケットが途切れるとネイバー関係は解消されます。
Helloパケットの役割
・存在の通知・確認
・ネイバーの検知
・DRの選出
・隣接の適正検査
相手とネイバーになるためにはHelloパケット含まれている以下のパラメータが自分の設定と一致していなければなりません。
・NetworkMask
・HelloInterval
・RouterDeadInterval
・オプションのEビット
Hello以外のパケットの役割
Helloパケット以外のパケットはネイバーの間でLSAの同期で使用します。Helloパケットでネイバーを認識したルータは次の段階としてLSAを同期し隣接関係になることを目指します。その際にHelloパケット以外の4つのパケットが使用されます。
同期で使用するパケット
・Database Descriptionパケット
・Link State Requestパケット
・Link State Updateパケット
・Link State Acknowledgmentパケット
これらのパケットは下図のように関係しています。Database Descriptionパケットでリストの交換を、それ以降ではRequest、Update、Ackパケットを使用してLSAの交換を行います。
パケットの構造
OSPFパケットの構造はIPヘッダに続いてOSPFヘッダ、OSPFデータが続いた構造になっています。IPヘッダにはOSPFパケットを届けるために適切な宛先とOSPFパケットを含んでる旨が示されています。OSPFヘッダはすべてのOSPFパケットの先頭に位置していてパケットの基本情報が含まれます。OSPFデータはパケットの種類ごとに必要となる情報が含まれます。
送信アドレス
OSPFパケットの送信は以下のいずれかのアドレスを使用します。OSPFのパケットは基本的に1ホップでやり取りされ転送は行われないためリンクローカルマルチキャストアドレスが使用されます。LSAの初期同期やLSAの再送、転送が必要となるバーチャルリンクなどの場合にはユニキャストアドレスが使用されます。
| アドレス名 | アドレス | 受信するルータ |
| AllSPFRouters | 224.0.0.5 | 回線内のすべてのルータ |
| AllDRouters | 224.0.0.6 | 回線内のDR、BDR |
| Unicast | 相手のIPアドレス | 特定のルータ |
■詳細
ここではOSPFで使用するパケットの作成と送受信する際のルールについて説明します。ここでの説明はRFC2328で指定されているパケットの作成、送信、受信の際のシーケンスをまとめたものです。動作の概念は「OSPFのインターフェース」、「OSPFの同期とタイマー」などのページを確認してください。
OSPFプロトコルとパケットの関係
OSPFがOSPFパケットを作成する構造を簡単に表すと下図のようになります。HelloパケットとDatabase DescriptionパケットとLink State RequestパケットはOSPFの各データ構造を元にして必要に応じて個別に作成され、それ以外のパケットはフラッディングプロシージャを通して作成されます。フラッディングプロシージャはLSAの同期を行うために必要となるパケットの作成手続きです。このページの以降の説明では各データ構造とフラッディングプロシージャからどのようにパケットが作成されるのかを説明します。OSPFの持つ各データ構造は「OSPFネットワークの構造」ページの補足を参照してください。
| データ構造 | 意味 |
| プロトコルデータ構造 | OSPF全体で共通の情報群 |
| エリアデータ構造 | エリアで共通の情報群 |
| インターフェースデータ構造 | インターフェースで共通の情報群 |
| ネイバーデータ構造 | ネイバーで共通の情報群 |
IPヘッダ
OSPFはIP上で動作するプロトコルであるため、OSPFパケットはIPによってカプセル化されます。
パケットの送信
IPパケットでOSPFパケットを送信する際には以下のフィールドにOSPFの指定する情報を設定します。
| パケットのフィールド | 意味 |
| Time to Live | マルチキャストをする場合、シングルホップのため1 |
| Protocol | OSPFのプロトコル番号89 |
| Source Address | 送信インターフェースのIPアドレス。unnumberedの場合はルータのいずれかのIPアドレスを設定 |
| Destination Address | 送信先のIPアドレス。AllSPFRouters、AllDRouters、Unicastのいずれかで、Unicastの場合はネイバーデータ構造のNeighbor IP address。どのアドレスを使用するかは下表参照 |
| Data | 各OSPFパケットを設定 |
パケットの受信
IPではOSPFパケットを受信すると受け入れのチェックの後にOSPFプロセスに渡されます。
OSPFがIPに求めるチェックは以下の内容です
１）IP のHeader Checksumが正常であること。
２）宛先アドレスは受信インターフェースのIPアドレスもしくはAllSPFRouters または AllDRoutersである
３）プロトコル番号が89である
４）送信元アドレスが受信インターフェースのIPアドレスでない
チェックを通過するとOSPFのデータはOSPFプロセスに引き渡されます。この時、Source AddressとDestination AddressはOSPF内で使用するために保持する必要があります。
OSPFパケットヘッダ
すべてのOSPFパケットは24バイトのパケットヘッダで始まります。OSPFパケットヘッダにはこのパケットを受け入れるかどうかを判断するための情報が含まれています。
パケットの送信
OSPFパケットヘッダは下図のように作成されます。ルータ同士がネイバーや隣接関係になるためには一部の項目が回線内で同じである必要があります。チェックサムと認証については「OSPF パケットフォーマット」ページの認証フィールドでも説明しています。下図の赤字は構成可能なパラメータです。
| パケットのフィールド | 意味 |
| Version | RFC2328に準拠する場合2 |
| Packet Type | OSPFヘッダに続くデータの種類（HelloパケットやLink State Updateパケットなど）を1から5で指定 |
| Packet length | OSPFパケット全体の長さ |
| Router ID | 発信元のルータID。プロトコルデータ構造のRouter IDから設定 |
| Area ID | インターフェースの属するエリアID。OSPFパケットを送信するインターフェースのインターフェースデータ構造から設定 |
| Checksum | 認証フィールドを除くOSPFパケット全体のチェックサム。暗号認証の場合には計算しない |
| AuType | 認証方法のタイプ。OSPFパケットを送信するインターフェースのインターフェースデータ構造からAuTypeを設定 |
| Authentication | 認証情報。OSPFパケットを送信するインターフェースのインターフェースデータ構造からAuthentication Keyを設定 |
パケットの受信
OSPSパケットの場合は以下のフィールドの値が受信したインターフェースと同じかどうかチェックされます。異なる場合はドロップします。
以降で説明する各パケットタイプごとの入力処理が行われます。
パケットヘッダ受け入れチェック
１）Vresionフィールドが2である
２）Area IDフィールドが次のいずれかである
a）Area IDが同じであること、そのうえでPoint to Point以外の場合はIPサブネットが同じである
b）受信したルータがABRで、受信したパケットのArea IDがバックボーンを示していること、そのうえで送信元のRouter IDがバーチャルリンクとして設定したものと同じである
３）宛先IPアドレスがAllDRoutersのパケットはDR、BDRのみ受信する
４）AuTypeフィールドがインターフェースに設定したものと同じ
５）Authenticationフィールドによって認証できる
Helloパケット
Helloパケットはインターフェースから送信されてネイバーの発見と維持、隣接関係の構築、DR・BDRの選定に使用されます。Helloパケットはそのほかのパケットと異なりインターフェースによって状態に関係なく送信されます。そのため同期中であっても送受信の動作が起こり、場合によっては同期を中断するようなイベントを起動します。
パケットの因果関係
Helloパケットの送信はHello Intervalタイマーによって送信されるため基本的にパケット同士の因果関係はなくネイバーがどのような状態であっても送信されます。ただし、NBMA回線の場合はHelloパケットの受信に返信する動作を行います。
パケットの送信
Helloパケットで使用されるフィールドは以下のように作成されます。下図の赤字は構成可能なパラメータです。パケットのフィールドの並びは変えてあります。
| パケットのフィールド | 意味 |
| Options | OSPFのオプションの機能に対する対応状況。RFC2328で規定されているのはbit2のE-bitのみでエリアデータ構造のExternalRoutingCapabilityから設定 |
| Network Mask | インターフェースに割り当てられたサブネットマスク。インターフェースデータ構造のIP interface maskから設定。ポイントツーポイント、バーチャルリンクでは0.0.0.0 |
| Hello Interval | Helloパケットを送信する間隔。インターフェースデータ構造のHelloIntervalから設定 |
| Rtr Pri | ルータの優先順位。インターフェースデータ構造のRouter Priorityから設定 |
| Router Dead Interval | ネイバーをダウンしたと判断するまでの秒数。インターフェースデータ構造のRouterDeadIntervalから設定 |
| Designated Router | この回線のDRのルータID。インターフェースデータ構造のDesignated Routerから設定。未決定の場合は0.0.0.0（初期値） |
| Backup Designated Router | この回線のBDRのルータID。インターフェースデータ構造のBackup Designated Routerから設定。未決定の場合は0.0.0.0（初期値） |
| Neighbor | ネイバーのルータIDのリスト。インターフェースデータ構造のList of neighboring routersから設定 |
Helloパケットの送信はHello Timerによって制御されています。タイマーの時間が経過するとパケットが送信されてタイマーはリセットされます。回線がNBMAの場合はネイバーの状態がDownの場合PollIntervalごとに、それ以外の場合はHelloIntervalの間隔で送信されます。
| タイマー | インターバル | 値 | 意味 |
| Hello Timer | HelloInterval | 10秒 | Helloパケットの送信間隔 |
NBMA回線でのHello送信
HelloパケットはHello Timerによって送信タイミングが決まりますが、NBMA回線ではDR・BDRになることのできるルータから受信したHelloパケットに応答する形でもHelloパケットを送信します。Helloパケットは存在確認だけでなくDR・BDRの選定プロセスにも使用しているため、DRが不在になったような場合に選定プロセスが機能するための動作です。NBMA回線では役割によって以下のようにHelloパケットを送信します。
| ルータ | 送信先 |
| DR・BDR、DRになることのできるルータ | すべてのネイバーにユニキャスト |
| それ以外 | DR・BDRにユニキャスト |
パケットの受信
Helloパケットを受信すると以下のフィールドの値が受信したインターフェースと同じかどうかチェックされます。異なる場合はドロップします。次にインターフェースデータ構造のList of neighboring routersを検索してネイバーの情報を探します。ブロードキャスト回線の場合はIPアドレス、ポイントツーポイント回線、仮想回線の場合はルータIDで検索します。もし存在しない場合はネイバー情報を作成します。
受け入れチェック
以下のチェックを行い不一致が発生する場合にはパケットは削除されます。
１）Network Mask、Hello Interval、Router Dead Intervalがインターフェースデータ構造と一致すること。ただし、Point to Point 回線とバーチャルリンクはNetwork Maskは無視されます
２）オプションフィールドのExternalRoutingCapability（Eビット）の設定はエリアデータ構造と一致する必要があります（オプションフィールド全体ではない）。
ネイバー情報の照会、作成
チェックを通るとList of neighboring routersに一致するルータがあるかどうかを以下の情報で照会します。
・ブロードキャスト回線の場合はIPヘッダのソースアドレス
・ポイントツーポイント回線、バーチャルリンクの場合はOSPFパケットヘッダのルータID
一致するものがない場合はネイバー情報をネイバーデータ構造に以下の通り作成します。
ブロードキャスト回線、ポイントツーマルチポイント回線、NBMA回線の場合
・StateをDownに設定
・ルータPriority、DR、BDRを同じように設定
ポイントツーポイント回線の場合
・Neighbor IP addressに送信元アドレスを設定
発生するイベント
ネイバー情報の照会、作成が済むとHelloパケットの残りの情報からネイバーとインターフェースの各イベントが起動されます。ここで発生する各イベントは各ステートマシンの動作に繋がります。各ステートマシンの詳細は「OSPFの同期とタイマー」、「OSPFのインターフェース」のページを参照してください。
・Neighbor state machineのイベント
１）Helloパケットを受信することでHelloReceivedイベントを起動。このイベントによってInactivity Timerを再起動（上図）
２）NeighborフィールドにこのルータIDが含まれている場合は2-WayReceivedイベントを起動、それ以外の場合は1-WayReceivedイベントを起動
・Interface state machine のイベント
１）ネイバーのRtr Priフィールドが変更されている場合はNeighborChangeイベントを起動
２）インターフェースの状態がWaitingでDRは指定されているが、BDRが指定されていない（0.0.0.0）の場合はBackupSeenイベントを起動。Waiting以外の場合はネイバーが新しいDRとして宣言している場合、または現時点でDRが不在の場合はNeighborChangeイベントを起動
３）インターフェースの状態がWaitingでBDRが指定されている場合BackupSeenイベントを起動。Waiting以外の場合はネイバーが新しいBDRとして宣言している場合、または現時点でBDRが不在の場合はNeighborChangeイベントを起動
Database Descriptionパケット
Database Descriptionパケットは隣接するネイバーと現在のLSAの保持状態を同期するために使用するパケットです。自分の持つLSAの一覧を送信し合い、相手との違いからRequest list （Link state request list）を作成します。Database Descriptionパケットは初期同期時のみに使用するパケットで、ExStartとExchangeのみで作成します。Loading以降で使用されるLink State Requestパケット、Link State Updateパケット、Link State Acknowledgmentパケットはつながりのある動作として使用されますが、Database DescriptionパケットはRequest listを使用するために単体で使用されます。
パケットの因果関係
Database Descriptionパケットは初めはネイバーの状態がExStartになったインターフェースから任意のタイミングで送信されます。Database Descriptionパケットを受信するとマスター・スレーブを決定し、それ以降はマスターから送信したパケットにスレーブが返信を行う形で送信されます。そのためパケットの因果関係は下図のようにDatabase Descriptionパケットの受信に伴ってDatabase Descriptionパケットを送信する関係を持ちます。
パケットの送信
Database Descriptionパケットは以下のように作成され送信されます。下図の赤字は構成可能なパラメータです。
| パケットのフィールド | 意味 |
| Interface MTU | 断片化せずに送信できるIPデータグラムのサイズ。バーチャルリンクの場合は0 |
| Options | Helloパケットのオプションフィールドを参照 |
| I | 初期状態を示すフラグビット。初めて送信する場合に設定 |
| M | Database summary listの残りを示すフラグビット。送信するLSAが残存している場合に設定 |
| MS | マスターを表すフラグビット。ネイバーデータ構造のMaster/Slaveから設定。ネイバーのDatabase Descriptionパケットを受信することによるネゴシエーションにより決定 |
| DD sequence number | Database Descriptionセッションを管理するためのシーケンス番号。ネイバーデータ構造のDD Sequence Numberから設定 ※この情報は元情報が決められておらず、RFC2328では「（時刻のような）一意の値」とされています |
| An LSA Header | LSAのヘッダのみを格納。ネイバーデータ構造のDatabase summary listから設定 ※この情報はそのエリアのLSDBのLSAヘッダのみで構成されます。ネゴシエーションを行うExStartの段階では空となります。Database summary listはネイバーに対する状態がExStartになった時点で作成されます。 |
Database DescriptionパケットはExStartとExchangeのいずれかで使用されるため、隣接関係が必要と判断されたネイバーに対して以下のタイミングで送信されます
| ネイバーの状態 | 送信タイミング |
| ExStart | RxmtIntervalタイマーが切れることによって送信 |
| Exchange | ・Masterの場合同じDDシーケンス番号のDatabase Descriptionパケットの受信で新規送信。前のDDシーケンス番号のDatabase Descriptionパケットの受信もしくはRxmtInterval経過で再送 ・Slaveの場合新しいDatabase Descriptionパケット受信で新しいDatabase Descriptionパケット送信、それ以外の場合は再送 |
Loading、Fullの状態ではRouterDeadInterval経過後に再送用のDatabase Descriptionパケットを削除します。その後にDatabase Descriptionパケットを受信した場合はSeqNumberMismatchイベントを起動します。
パケットの受信
Database Descriptionパケットを受信すると以下のように処理が行われます。
１）Last received Database Description packetにDatabase Descriptionパケットの情報を保存します（下図a）。この情報はDatabase Descriptionパケットの新旧を識別するために使用します。
２）受信インターフェースが受け入れることのできるサイズよりも大きいInterface MTUが設定されている場合は受信しません。
３）受信したネイバーの状態によって下表のようにNeighbor state machineイベントを起動します。
| ネイバーの状態 | 動作・イベント生成条件 |
| Down、Attempt、2-Way | 拒否する |
| init | 2-WayReceivedイベントを起動し2-WayもしくはExStartに遷移 |
| ExStart | マスター、スレーブを決定しNegotiationDoneイベントを起動。またOptionフィールドをNeighbor Optionsに登録（上図b）。 自分がスレーブの場合には受け取ったDD シーケンス番号をネイバーデータ構造のDD Sequence Numberに設定（上図のc）。 |
| Exchange | この状態ではマスターの主導でサマリーリストの交換を行う。 マスターが同じDatabase Descriptionパケットを受信した場合は破棄。スレーブが同じDatabase Descriptionパケットを受信した場合は最後に送信したDatabase Descriptionパケットを再送。マスター・スレーブともにDatabase Descriptionパケットが重複しておらず以下のいずれかの状態の場合はSeqNumberMismatchイベントを起動し処理を停止。 ・MSビットの状態がマスター/スレーブの状態と矛盾している ・Iビットが設定されている ・optionsフィールドがNeighbor Optionsフィールドと異なる ・マスターの場合は同じシーケンス番号でない場合 ・スレーブの場合はネイバーデータ構造よりも1つ大きいシーケンス番号でない場合 |
| Loading、Full | 重複パケットの場合 ・マスターの場合は削除 ・スレーブの場合は前に送信したDatabase Descriptionパケットを再送 重複パケット以外の場合は削除してSeqNumberMismatchイベントを起動 |
| – | ルータで処理できるLSAのタイプでない場合（スタブエリアにおけるType-5含む）はSeqNumberMismatchイベントを起動 |
４）上表以外の場合はLSDBを検索してLSAを確認します。もしLSAが存在しない、もしくは受信したLSAの方が新しい場合は下図のようにRequest listに追加します。またルータがマスターかスレーブによって下表の動作も行います。
| マスターの場合 | DDシーケンス番号をインクリメント。Database DescriptionパケットでLSAの一覧を送信済みで、相手のMoreが0の場合ExchangeDoneイベントを起動。そうでない場合は新たなDatabase Descriptionパケットを送信 |
| スレーブの場合 | ネイバーデータ構造のDD シーケンス番号に受信したDatabase DescriptionパケットのDDシーケンス番号を設定（上図のb）。受信したDatabase DescriptionパケットのMoreが0で、スレーブの送信するDatabase DescriptionパケットのMoreが0の場合ExchangeDoneイベントを起動 |
Link State Requestパケット
Link State RequestパケットはLSAの送信をネイバーに依頼するためのパケットで初期同期時のみ使用されます。Exchange、Loading状態で作成します。このパケットを受信すると相手が持っていないLSAを知ることができます。
パケットの因果関係
Link State Requestパケットの因果関係は下図のようになっています。送信するのはRequest listに情報が存在している場合のみです。Link State Requestパケットの送信で初期同期の一連の動作がスタートします。Link State RequestパケットはLink State Updateパケット送信のトリガーの一つで、Link State Requestパケットを受信するとフラッディングプロシージャに連携します。
パケットの送信
Link State Requestパケットは下図のように作成されます。ネイバーデータ構造のRequest listに登録されている各LSAヘッダ情報からLS Type、Link State ID、Advertising RouterのみがLink State Requestパケットにセットされます。この指定ではLSAを一意に指定していますが、インスタンスは区別しません。
| パケットのフィールド | 意味 |
| LS type | 要求するLSAのLS Type |
| Link State ID | 要求するLSAのLink State ID |
| Advertising Router | 要求するLSAのルータID |
Link State Requestパケットを送信するのはネイバーの状態がExchangeかLoadingの場合のみです。いずれの場合もRequest listにLSAがエントリーされている場合にLink State Requestパケットを送信します。Request listにLSAがエントリーするのは初期同期時のみであるため、Link State Requestパケットは初期同期だけで作成されるパケットということになります。このパケットはLSAが受信できるまでRxmtInterval間隔で再送信されます。Request listのLSAはネイバーからLS UpdateでLSAを受信することで削除されます。Request listが空になるとLoading Doneイベントが起動します。
パケットの受信
Link State Requestパケットを受信するとLink State Updateパケットの送信に繋がりますが、Link State Requestパケットを受信した時点で直接Retransmission listに入るわけではありません。以下のようにLSDBに対象のLSAが存在するかどうかを確認しフラッディングプロシージャに連携します。フラッディングプロシージャの詳細は次のLink State Updateパケットで説明しています。
| ネイバーの状態 | 動作 |
| Exchange、Loading、Full | ・LSDBを確認しLSAが存在する場合はLink State Update送信プロシージャに入力 ・LSDBにLSAが存在しない場合はBadLSReqイベントを起動 |
| それ以外 | 削除 |
Link State Updateパケット
Link State UpdateパケットはLSAを運ぶために使用するパケットです。ExchangeからFullの状態で作成します。Link State Updateパケットの送受信はフラッディングプロシージャの処理で行われます。フラッディングプロシージャではLink State UpdateパケットのほかにLink State Acknowledgmentパケットの処理も含まれていますが、ここではLink State Updateパケットのみを説明し、Link State Acknowledgmentパケットについては次のLink State Acknowledgmentパケットの項で説明しています。以下の説明ではパケットの送信、受信の順番で説明していますが、送信の動作はパケットの受信によっても発生するため受信の動作を行った後で送信の動作に入るケースがあることに注意してください。実際RFC2328ではLink State Updateパケットの受信は「13. The Flooding Procedure」、Link State Updateパケットの送信は「13.3 Next step in the flooding procedure」で説明されており、送信動作は受信動作のサブセクションとなっています。
パケットの因果関係
Link State Updateパケットは最も因果関係が複雑です。Link State Updateパケットを送信するきっかけは下図の赤丸で示したようにLink State Requestパケットを受信した場合（つまり初期同期）、新規作成（LSAの更新）、Link State Updateパケットを受信した場合です。Link State Updateパケットを受信するとLink State UpdateパケットかLink State Acknowledgmentパケットを送信します。
パケットの送信
Link State Updateパケットを作成するのはRxmtIntervalが満了した時点でRetransmission list（Link state retransmission list）に登録されているLSAを使用します。Retransmission listに登録される情報はLink State Requestパケットによってネイバーから要求があった場合と、Link State Updateパケットで新しいLSAを受信した場合、新規LSAが発生した場合です。ただし、Retransmission listにLSAが登録されるのは送信プロシージャの中で行われます。例えばLink State Requestパケットによって受け取ったLSAヘッダはLink State Requestパケット受信時ではなく、LSAを送信するためにプロシージャに通す過程でRetransmission listに登録されます。
Link State UpdateパケットはOSPFのパケットヘッダに続いてこのパケットに格納されているLSAの数を示すフィールドがあり、その後に各LSAを連続して格納します。各LSAはプロトコルデータ構造もしくはエリアデータ構造から下図のように格納します。このパケットは複数のLSAを1つのパケットにまとめることができます。つまりLink State UpdateパケットにはLink State Requestパケットから要求されたLSA、Link State Updateパケットで受信したLSA、新規作成したLSAが相乗りする可能性があります。
| パケットのフィールド | 意味 |
| # LSAs | LSAsフィールドに設定されたLSAの数 |
| LSAs | Retransmission listを元に以下のLSAを設定 ・Router-LSA — すべてのルータ ・Network-LSA — DRを持つルータ ・Summary-LSA — ABR ・AS-External-LSA — ASBR（仮想リンクとスタブエリアを除く） |
Link State UpdateパケットはRxmtInterval経過時に送信されます。送信はDR、BDR、DR Otherなどのネイバーに対する状態に関係なくすべてのルータで下記の送信プロシージャで行われますが、対象となるインターフェースは下表に示した範囲に限定されます。ただし、パケットの受信プロシージャ内で送信される（送信プロシージャの前に送信される）LSAはこの限りではありません。送信先はIPヘッダのセクションで説明した宛先が使用されます。
| LSA | 配布するインターフェース |
| AS-external-LSAs | バーチャルリンクとスタブエリアに接続するインターフェース以外のすべてのインターフェースから配布 |
| その他のLSA | このLSAはエリアに固有のLSAであるため同じエリアに接続するインターフェースから配布 |
LSAの送信プロシージャ
LSAのRetransmission listの登録からパケットの作成・送信の動作はこのプロシージャで行われます。上で説明しているように対象となるLSAはLink State Requestパケットで受信したLSA、Link State Updateパケットで受信したLSA、新規作成したLSAです。このプロシージャは受信のプロシージャの後に実行されます。RxmtIntervalを経過してもLink State Acknowledgmentパケットを受け取らなかった場合は再送することになります。ブロードキャスト回線の場合は上で説明したアドレスで送信されます。NBMAの場合はユニキャストで送信されます。
１）次のステップでネイバーごとにLSAを送信する必要があるかを判断
a Exchangeよりも低い場合は次のネイバーを確認
b ExchangeもしくはLoadingの場合はRequest listを確認
・保持するLSAがRequest listのLSAよりも古い場合は次のネイバーを確認
・Request listと同じ場合はRequest listのLSAを削除
・保持するLSAがRequest listのLSAよりも新しい場合はRequest listのLSAを削除
c 送信元のネイバーである場合次のネイバーを確認
d ネイバーのLSA状態を判断できないのでRetransmission listに登録
２）インターフェースからLSAの送信を検討。Retransmission listに登録されていない場合送信しない
３）対象のLSAがDR、BDRから送信されている場合は次のインターフェースを確認
４）BDRがLSAを受信した場合は次のインターフェースを確認。DRがLSAを受信した場合は同じインターフェースから送信
５）LSAを送信。LS AgeはInfTransDelay（>0）分インクリメント
このプロシージャでRequest listが空になるとLoading Doneイベントを起動します。Request list から削除するのはLink State UpdateパケットによってLSAを受信した場合のみであるため、LoadingDoneが発生するのはLink State Updateパケットを受信した場合のみということになります。
パケットの受信
Link State Updateパケットを受信するとまずネイバーの状態（下表）をチェックします。Exchangeより低い状態でLink State Updateパケットを受信した場合はパケットを削除します。それ以外場合は受信プロシージャを実行します。以下のプロシージャの中ではLSAを受信した結果、LSDBへの登録、LSAの転送、Link State Acknowledgmentパケットの返信が検討されます。LSAの転送は前のLink State Updateパケットの送信に繋がり、ACKの送信は次で説明するACKパケットの送信に繋がります。Request list から対象のLSAを削除する動作は送信のプロシージャで行われます。
| ネイバーの状態 | Link State Updateパケットに対する動作 |
| Exchangeより低い状態 | 削除 |
| Exchange以上 | 受信プロシージャの実行 |
受信プロシージャ
１）チェックサム確認（不正な場合は削除）
２）LS-Typeの確認（未知の場合は削除）
３）スタブ領域の場合にLS-Type5を受信した場合は削除
４）Fullの状態で、LS ageがMaxAgeと同じ場合はLSAを削除しACKのみ送信元に送信
５）もし受信したLSAがLSDBに存在しない、もしくは新しいLSAの場合は次の動作を実行
a LSDBにすでに存在し新しいLSAがMinLSArrival未満の場合は破棄し次のLSAを取得
b それ以外の場合はLSAを送信
c すべてのネイバーのRetransmission listからデータベースのコピーを削除
d LSAをLSDBにインストールし受信時間を記録。ルーティングテーブルの再計算
e 場合によりLS ACKを送信
f 自分が発信したLSAの場合、そのLSAを再更新して発信するか削除
６）Request listが残っている場合はエラーが存在。BadLSReqイベントを起動
７）受信したLSAがLSDBと同じ場合、次の手順を行う
a Retransmission listに登録されている場合、暗黙の確認応答として処理
b 場合によってACKを送信
８）上記以外は受け取ったLSAよりも自分の持つLSAが最新。LS AgeがMaxAgeに同じで、LSシーケンス番号がMaxSequenceNumberに等しい場合は破棄。それ以外の場合はMinLSArrival以内でない限り、自分の持つLSAを送信元に対して送信。この時のLSA送信ではRetransmission listに登録しない
Link State Acknowledgmentパケット
Link State Acknowledgmentパケットは確認応答のために作成します。Link State Acknowledgmentパケットの送信はフラッディングプロシージャの一部ですがここではLink State Acknowledgmentパケットの処理のみを切り出して説明します。上のLink State Updateパケットの受信プロシージャの結果Link State Acknowledgmentパケットの送信が必要と判断された場合に実行されます。OSPFのパケットヘッダに続いて各LSAのヘッダーのみが連続で格納される形で作成されます。受信した側は各LSAのヘッダー情報からどのLSAに対する確認応答を知ることができます。Link State Acknowledgmentパケットは遅延確認応答で送信することができます。
パケットの因果関係
Link State Acknowledgmentパケットの因果関係はシンプルです。基本的にLink State Updateパケットを受信すると送信されます。ただしすべてのLink State Updateパケットに一律対応するのではなく、送信する場合としない場合があり判断はLink State Updateパケットの受信プロシージャもしくは以下で説明する送信パターンによって決定します。また送信先も受信した元のアドレスによって異なります。Link State Acknowledgmentパケットを受信してもRetransmission listの削除のみであり、次につながるパケットはありません。
パケットの送信
Link State Acknowledgmentパケットの送信はLink State Updateパケットを受信した際に行われます。Link State Updateの項でも説明しているようにLink State Updateパケットを受信すると、同じLSAを含んだLink State Updateパケットを送信する動作に移行する場合がありますが、Link State Updateパケット送信に移行しなかったLSAに対してのみこのLink State Acknowledgmentパケットを送信することになります（Link State Updateの受信プロシージャで判断）。Link State Acknowledgmentパケットは受信したLSAの確認応答で作成されるためパケットには受信したLSAのLSAヘッダが格納されます。
| パケットのフィールド | 意味 |
| An LSAs Header | ネイバーのRetransmission listから削除可能と判断されたLSAなどで、送信が必要と判断されたLSAのLSAヘッダ |
Link State Acknowledgmentパケットの送信条件はRFC2328の表19にまとめられています。下表はその表を意訳したものです。直接確認応答はLSAを受信するとネイバーのIPアドレスに直接送信されます。遅延確認応答ではインターフェースに関連付けされているすべてのネイバーに送信されます。ブロードキャスト回線の場合はマルチキャストが行われ、NBMA回線では状態がExchange以上のネイバーに対してユニキャストされます。遅延確認応答をどれほど遅延させるのかについては決まりはありませんが送信間隔はRxmtInterval 未満にしておかなければLink State Updateパケットの再送が発生します。Link State Acknowledgmentパケットは一連の手続きの最後に送信するため再送はありません。
遅延確認応答の特徴
１）複数のLSAの確認応答を1つのパケットで済ませることができる
２）送信がマルチキャストの場合は複数のネイバーに対して1度で確認応答を示すことができる
３）Link State Updateに対する応答パケットを複数のルータが送信する場合、Link State Acknowledgmentパケットの偏りをなくしてランダム化できる
| ケース | BDR | 他のすべての状態 |
| 自分が送信したLSAを受信 | 送信しない | 送信しない |
| 全く新しいLSAを受信 | 送信元がDRの場合は遅延確認応答を送信 DR Otherの場合は何もしない |
遅延確認応答を送信 |
| 自分の持つのと同じLSAを受信 暗黙の確認応答として扱った | 送信元がDRの場合は遅延確認応答を送信 DR Otherの場合は何もしない |
送信しない |
| 自分の持つのと同じLSAを受信 暗黙の確認応答として扱わなかった | 直接確認応答を送信 | 直接確認応答を送信 |
| 無効化されたLSAを受信 | 直接確認応答を送信 | 直接確認応答を送信 |
上表は一見するとBDRが特別扱いされていて動きが見えてきませんがLSA同期の法則に沿った動作が規定されています。これらの動作を理解するポイントは以下の点です
・Link State AcknowledgmentパケットはLink State Updateパケットを受信したインターフェースからのみ送信
・Link State Updateパケットによる暗黙的な確認応答ができる場合には送信しない
・なるべく複数のLSAをまとめる
・受信に時間を要する可能性のある場合には遅延確認応答で送信
・不測の場合には特定のネイバーに直接送信
パケットの受信
Link State Acknowledgmentパケットを受信するとRetransmission listから対象のLSAを削除します。Link State Acknowledgmentパケットは通信の最後に受信するものであるためそれ以上の動作、イベントの起動はありません。
| ネイバーの状態 | 動作 |
| Exchangeより低い | Link State Acknowledgmentパケットを削除 |
| それ以外 | 次の処理を実行する ・LSAがRetransmission listに存在することを確認、存在しない場合は次のLink State Acknowledgmentパケットを確認 ・LSAがRetransmission listに存在する場合はリストから削除して次のLink State Acknowledgmentパケットを確認 ・上記のいずれでもない場合はログを記録して次のLink State Acknowledgmentパケットを確認 |