JP5370588B2 - 通信システム、ノード、制御装置、通信方法およびプログラム - Google Patents

Description

（関連出願についての記載）
本発明は、日本国特許出願：特願２０１０−１２３０５４号（２０１０年５月２８日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。

本発明は、通信システム、ノード、制御装置、通信方法およびプログラムに関し、特に、ネットワークに配置されたノードによりパケットを転送して通信を実現する通信システム、ノード、制御装置、通信方法およびプログラムに関する。

非特許文献１、２に示すとおり、近年、オープンフロー（ＯｐｅｎＦｌｏｗ）という技術が提案されている。オープンフローは、通信をエンドツーエンドのフローとして捉え、フロー単位で経路制御、障害回復、負荷分散、最適化を行うものである。転送ノードとして機能するオープンフロースイッチは、オープンフローコントローラとの通信用のセキュアチャネルを備え、オープンフローコントローラから適宜追加または書き換え指示されるフローテーブルに従って動作する。フローテーブルには、フロー毎に、パケットヘッダと照合する照合規則（ＦｌｏｗＫｅｙ／マッチングキー）と、処理内容を定義したアクション（Ａｃｔｉｏｎ）と、フロー統計情報（Ｓｔａｔｓ）との組が定義される（図３０参照）。

図３１に、非特許文献２に定義されているアクション名とアクションの内容を例示する。ＯＵＴＰＵＴは、パケットを指定ポート（インタフェース）に出力するアクションである。ＳＥＴ＿ＶＬＡＮ＿ＶＩＤからＳＥＴ＿ＴＰ＿ＤＳＴは、パケットヘッダのフィールドを修正するアクションである。

例えば、オープンフロースイッチは、最初のパケット（ｆｉｒｓｔ ｐａｃｋｅｔ）を受信すると、フローテーブルから、受信パケットのヘッダ情報に適合する照合規則（ＦｌｏｗＫｅｙ）を持つエントリを検索する。検索の結果、受信パケットに適合するエントリが見つかった場合、オープンフロースイッチは、受信パケットに対して、当該エントリのアクションフィールドに記述された処理内容を実施する。一方、前記検索の結果、受信パケットに適合するエントリが見つからなかった場合、オープンフロースイッチは、セキュアチャネルを介して、オープンフローコントローラに対して受信パケットを転送し、受信パケットの送信元・送信先に基づいたパケットの経路の決定を依頼し、これを実現するフローエントリを受け取ってフローテーブルを更新する。

Nick McKeownほか７名、"OpenFlow: Enabling Innovation in Campus Networks"、［online］、［2010年2月26日検索］、インターネット〈URL：http://www.openflowswitch.org//documents/openflow-wp-latest.pdf〉 "OpenFlow Switch Specification" Version 1.0.0. (Wire Protocol 0x01) ［2010年4月1日検索］、インターネット〈URL：http://www.openflowswitch.org/documents/openflow-spec-v1.0.0.pdf〉

なお、上記の非特許文献の各開示を、本書に引用をもって繰り込むものとする。

以下の分析は、本発明者によってなされたものである。上記受信パケットの経路の決定依頼を受けたオープンフローコントローラは（図３３のｓ２ Ｐａｃｋｅｔ−Ｉｎ参照）、受信パケットの転送経路を決定する。前記受信パケットおよび同一フローに属する後続パケットをホスト（Ｂ）に転送するには、前記転送経路上にあるすべてのオープンフロースイッチ（図３３のノード＃１およびノード＃２）に、フローエントリを設定する必要がある。また、オープンフローコントローラはネットワーク管理者の指示等に基づいて設定済みのフローエントリについて、アクションの変更を行う場合があり、その際、フローエントリの変更・削除を行う必要がある。

上記フローエントリの設定・変更・削除がオープンフロープロトコルで行われる場合（非特許文献２の「４．６ Ｆｌｏｗ Ｔａｂｌｅ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｍｅｓｓａｇｅｓ」参照）、オープンフローコントローラとオープンフロースイッチ間の通信に遅延が生じることがあり、一部のオープンフロースイッチにおけるフローエントリの設定・変更・削除が間に合わず、経路上のオープンフロースイッチにおいて、パケットがフローテーブル上の意図しないフローエントリに一致し、意図しないアクションが実行されるという問題点がある。

図３２は、ホスト（Ａ）からホスト（Ｂ）宛てのパケットを受信したオープンフロースイッチ（ノード＃１）が、コントローラに対しフローエントリの作成要求を行った際、中継スイッチ(ノード＃２)に対するマッチングキーＸを持つフローエントリの設定が遅延した例である。図３２の例では、ノード＃２において、設定されるべきフローエントリのマッチングキーＸと競合（オープンフロープロトコルではマッチングキーとして任意のヘッダフィールドの部分一致を許可しており、フローエントリ間での競合回避はフローエントリの検索順によって制御される）するマッチングキーＢを持つフローエントリが存在している。そのため、ノード＃２において、ホスト（Ａ）から送信されたパケットは、フローエントリの設定が完了するまでの間、本来出力されるべきポート＃２ではなくポート＃１へ転送されてしまう（図３２のＳＴ８）。このように、オープンフロープロトコルではフローエントリの設定遅延により意図しないパケット転送（アクション実行）が容易に発生し得る。

上記の対策として、図３３に示すように、（オープンフロー）コントローラが、ノード＃１、＃２に対してフローエントリを送信（図３３のｓ３、ｓ６のＦｌｏｗＭｏｄ（Ａｄｄ）参照）するとともに、オープンフロープロトコルに規定されているＢａｒｒｉｅｒ Ｒｅｑｕｅｓｔを送信することが考えられる（図３３のｓ４ Ｂａｒｒｉｅｒ Ｒｅｑｕｅｓｔ；Ｂａｒｒｉｅｒ Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙについては非特許文献２の「５．３．７ Ｂａｒｒｉｅｒ Ｍｅｓｓａｇｅ」参照）。Ｂａｒｒｉｅｒ Ｒｅｑｕｅｓｔを受信したノードは、Ｂａｒｒｉｅｒ Ｒｅｑｕｅｓｔ受信前に受信した処理の実行を完了し、「Ｂａｒｒｉｅｒ Ｒｅｐｌｙ」（図３３のｓ５）として、応答する。これにより、（オープンフロー）コントローラは、フローエントリが正しく設定されていることを確認できる。しかしながら、この方法では、フローエントリを設定したすべてのノードと、Ｂａｒｒｉｅｒ Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙをやり取りすることになり、ユーザパケットを送信できるまでの時間（図３３のｓ１（Ｕｓｅｒ Ｐａｃｋｅｔ）〜ｓ１０（Ｕｓｅｒ Ｐａｃｋｅｔ）が長くなってしまうという問題点がある。

もう一つの方法として、上記Ｂａｒｒｉｅｒ Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙに代えて、Ｓｔａｔｓ Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙを用いて、各ノードが該当するエントリを持っているかどうかを確かめる方法もあるが、この場合も、上記Ｂａｒｒｉｅｒ Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙを用いる場合と同様に、フローエントリを設定したすべてのノードと該当するフローエントリが設定されているか否かをやり取りする必要が生じ、ユーザパケットを送信できるまでの時間（図３３のｓ１（Ｕｓｅｒ Ｐａｃｋｅｔ）〜ｓ１０（Ｕｓｅｒ Ｐａｃｋｅｔ）が長くなってしまう。

また、上記Ｂａｒｒｉｅｒ Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙ、Ｓｔａｔｓ Ｒｅｑｕｅｓｔ／Ｒｅｐｌｙを用いるいずれの方法も、フローエントリ設定後、ノードの障害等によってフローエントリの一部が消失してしまったような場合に、意図しないアクションが実行されてしまう事態を回避することができない。

本発明は、上記した事情に鑑みてなされたものであってその目的とするところは、上記のとおり、ノードにおいて、適切でない処理規則（フローエントリ）がヒットし、意図しない処理が実行されることを抑止することのできる通信システム、ノード、制御装置、通信方法およびプログラムを提供することにある。

本発明の第１の視点によれば、パケットを処理するノードと、パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを、前記ノードに通知する制御装置とを含み、前記ノードは、受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記制御装置から通知された前記第一の識別子とが対応するか否かにより判定する通信システムが提供される。

本発明の第２の視点によれば、制御装置からの指示に従ってパケットを処理するノードであって、パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを、前記制御装置から受信し、受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記制御装置から受信した前記第一の識別子とが対応するか否かにより判定するノードが提供される。

本発明の第３の視点によれば、パケットを処理するノードを制御する制御装置であって、パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを生成し、前記処理規則と前記第一の識別子を、受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記第一の識別子とが対応するか否かにより判定する前記ノードに対して通知する制御装置が提供される。

本発明の第４の視点によれば、制御装置からの指示に従ってパケットを処理するノードの通信方法であって、パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを、前記制御装置から受信し、受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記制御装置から受信した前記第一の識別子とが対応するか否かにより判定する通信方法が提供される。本方法は、受信パケットを処理するノードという、特定の機械に結びつけられている。

本発明の第５の視点によれば、パケットを処理するノードを制御する制御装置による通信方法であって、パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを生成し、前記処理規則と前記第一の識別子を、受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記第一の識別子とが対応するか否かにより判定する前記ノードに対して通知する通信方法が提供される。本方法は、受信パケットを処理するノードに前記処理規則を設定する制御装置という、特定の機械に結びつけられている。

本発明の第６の視点によれば、制御装置からの指示に従ってパケットを処理するノードに、パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを、前記制御装置から受信する処理と、受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記制御装置から受信した前記第一の識別子とが対応するか否かにより判定する処理とを実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

本発明の第７の視点によれば、パケットを処理するノードを制御する制御装置に、パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを生成する処理と、前記処理規則と前記第一の識別子を、受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記第一の識別子とが対応するか否かにより判定する前記ノードに対して通知する処理とを実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

本発明によれば、データ転送ネットワークに配置されたノードにおいて、意図しない処理が実行されることを抑止することが可能になる。

本発明の概要を説明するための図である。 本発明の概要を説明するための別の図である。 本発明の第１の実施形態の通信システムの構成を示す図である。 本発明の第１の実施形態の制御装置（コントローラ）の構成を表したブロック図である。 図４の制御装置（コントローラ）のフローエントリＤＢに保持される情報を説明するための図である。 図４の制御装置（コントローラ）の検証情報ＤＢに保持される情報を説明するための図である。 本発明の第１の実施形態のノードの構成を表したブロック図である。 図７のノードのフローテーブルに保持される情報を説明するための図である。 検証情報を含んだ（付加した）パケットの一例である。 図９の検証情報付き追加ヘッダの構成例を示す図である。 本発明の第１の実施形態の制御装置（コントローラ）の動作を表したフローチャートである。 本発明の第１の実施形態のノードの動作を表したフローチャートである。 本発明の第１の実施形態の通信システムにおける一連の流れを説明するための参考図である。 本発明の第１の実施形態の通信システムにおける一連の流れを説明するためのシーケンス図である。 本発明の第２の実施形態の制御装置（コントローラ）のフローエントリＤＢに保持される情報を説明するための図である。 本発明の第２の実施形態の制御装置（コントローラ）の検証情報ＤＢに保持される情報を説明するための図である。 本発明の第２の実施形態のノードの構成を表したブロック図である。 図１７のノードのフローテーブルに保持される情報を説明するための図である。 検証情報を含んだ（埋め込んだ）パケットの一例である。 本発明の第２の実施形態の制御装置（コントローラ）の動作を表したフローチャートである。 本発明の第２の実施形態のノードの動作を表したフローチャートである。 本発明の第３の実施形態の制御装置（コントローラ）のフローエントリＤＢに保持される情報を説明するための図である。 本発明の第３の実施形態の制御装置（コントローラ）の検証情報ＤＢに保持される情報を説明するための図である。 本発明の第３の実施形態のノードのフローテーブルに保持される情報を説明するための図である。 本発明の第４の実施形態の制御装置（コントローラ）のフローエントリＤＢに保持される情報を説明するための図である。 本発明の第４の実施形態の制御装置（コントローラ）の検証情報ＤＢに保持される情報を説明するための図である。 本発明の第４の実施形態のノードのフローテーブルに保持される情報を説明するための図である。 本発明の第５の実施形態で用いるパケットの一例である。 図２８の検証情報付き追加ヘッダの構成例を示す図である。 非特許文献２に記載のフローエントリの構成を表した図である。 非特許文献２に記載されているアクション名とアクションの内容を示す図である。 非特許文献２のオープンフローコントローラ（コントローラ）とフロースイッチ（ノード）の動作を説明するための図である。 非特許文献２のオープンフロープロトコルを用いて、フローエントリを確実に設定するための一連の流れを説明するための参考図とシーケンス図である。

はじめに、本発明の概要について説明する。以下、この概要に付記した図面参照符号は、専ら理解を助けるための例示であり、図示の態様に限定することを意図するものではない。図１に示すように、本発明の通信システムのノード１０（図１のノード＃２参照）は、パケットを受信した際に、自装置が保持している処理規則の中の照合規則（マッチングキー）を用いて受信パケットに適合する処理規則を抽出する（ステップ１）。次に、ノード１０（図１のノード＃２参照）は、前記抽出した処理規則に関連付けられている識別子が、前記受信したパケットに含まれる識別子と一致することを確認する（ステップ２）。なお、ノード１０が、処理規則に関連付けられている識別子と、受信したパケットに含まれる識別子とが一致することを確認する場合について述べたが、本発明はこれに限らない。例えば、ノード１０が、処理規則に関連付けられている識別子と、受信したパケットに含まれている識別子とが互いに対応関係にあることを確認するような場合等も含まれる。以降のステップや実施形態においても同様である。前記確認の結果、処理規則に関連付けられている識別子が、前記受信したパケットの識別子と一致することが確認できたら、ノード１０（図１のノード＃２参照）は、当該処理規則に従って処理を実行する（ステップ３）。

ここで、上記した識別子は、制御装置（コントローラ）２０によって、処理規則に関連付けて生成された情報であり、少なくとも受信パケットに適合し得る処理規則同士を識別できるように生成・付与される。従って、照合規則（マッチングキー）による検索で抽出された処理規則であっても、識別子が一致しない場合、当該処理規則のアクションは実行されないことになる。ユーザパケットに識別子を含める態様としては、図１、図２に示すようにユーザパケットに付加する形態のほか、ユーザパケットの特定の領域に埋め込む形態など（図１９参照）、種々の形態を採用することができる。

以上により、冒頭に述べた、処理規則の設定遅れや、ノードの障害等によってフローエントリの一部が消失してしまったような場合に、意図しないアクションが実行されてしまう事態を回避することができる。

図１の例では、照合規則（マッチングキー）を用いて受信パケットに適合する処理規則を抽出した後、前記抽出した処理規則に関連付けられた識別子が、前記受信したパケットの識別子と一致することを確認するものとして説明したが、図２に示すように、識別子を用いて受信パケットに適合する処理規則を抽出した後、前記抽出した処理規則の照合規則（マッチングキー）が、前記受信したパケットの内容（照合規則（マッチングキー）の照合対象となるヘッダ情報）と一致することを確認する方法も採用できる。

この場合も、識別子による検索で抽出された処理規則であっても、照合規則（マッチングキー）が受信パケットの内容（ヘッダ情報）と一致しない場合、当該処理規則のアクションは実行されないことになる。図１の場合と同様に、処理規則の設定遅れ等により、意図しないアクションを実行してしまうといった事態を回避することができる。

［第１の実施形態］
続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。図３は、本発明の第１の実施形態に係る通信システムの構成を示す図である。図３を参照すると、３つのノード１０と、制御装置（コントローラ）２０と、ノード１０を経由して通信するホスト（Ａ）、（Ｂ）が示されている。なお、図３の例では、３つのノード１０と、制御装置（コントローラ）２０と、２つのホスト（Ｈｏｓｔ（Ａ）、Ｈｏｓｔ（Ｂ））を示しているが、それぞれの数は、あくまで例示であり、それぞれ任意の数とすることができる。

図４は、制御装置（コントローラ）２０の詳細構成を表した図である。図４を参照すると、制御装置（コントローラ）２０は、処理規則（フローエントリ）と当該処理規則と関連付けられた検証情報を格納したフローエントリデータベース（フローエントリＤＢ）２１と、ノード通信部２６を介して収集されたノード１０の接続関係に基づいてネットワークトポロジ情報を構築するトポロジ管理部２２と、トポロジ管理部２２にて構築されたネットワークトポロジ情報に基づいてパケットの転送経路および該転送経路上のノード１０に実行させるアクションを求める経路・アクション計算部２３と、経路・アクション計算部２３および検証情報生成部２８にて計算された処理規則（フローエントリ）および検証情報を関連付けてフローエントリＤＢ２１に登録し、ノード１０からの処理規則（フローエントリ）の追加要求への対応や処理規則（フローエントリ）および検証情報の更新などを行うフローエントリ管理部２４と、制御メッセージ処理部２５と、ノード１０との通信を行うノード通信部２６と、フローエントリ管理部２４からの要求に応じて処理規則に含める検証情報を生成または検証情報データベース（検証情報ＤＢ）２７から取り出す検証情報生成部２８と、を備えて構成される。ここで、検証情報は、照合規則に基づく受信パケットと処理規則との照合結果を検証するために用いられる上記識別子相当の情報を指すものとする。

さらに、制御メッセージ処理部２５は、ノード１０から受信した制御メッセージを解析して、必要な処理を行うメッセージ解析・処理部２５１と、ノード１０に送信するメッセージを生成するメッセージ生成部２５２とを備えて構成される。

図５は、フローエントリＤＢ２１に保持される情報（フローエントリおよび検証情報）を模式的に表した図である。例えば、図５の上から１〜３番目のエントリは、ＤＰＩＤ（ノード１０の識別子；Ｄａｔａｐａｔｈ Ｉｄｅｎｔｉｆｉｅｒ）が１〜３のノードにそれぞれ設定される処理規則（フローエントリ）および処理規則に関連付けられた検証情報を示している（上から４〜６番目のエントリも同様。）。

ＤＰＩＤが１であるノード（例えば、図３のノード＃１）は、上記上から１番目のエントリのとおり、「Ａ」というマッチングキーに適合するパケットを受信した場合に、そのアクションフィールド（Ａｃｔｉｏｎｓ）に従い、検証情報「ＣＡ」を含むヘッダを付加してから、９番ポートから出力する処理を実行する。同様に、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）は、ＤＰＩＤが１であるノード（例えば、図３のノード＃１）から「Ａ」というマッチングキーに適合するパケットを受信すると、６番ポートから出力する処理を実行する。そして、ＤＰＩＤが３であるノード（例えば、図３のノード＃３）は、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）から「Ａ」というマッチングキーに適合するパケットを受信すると、当該パケットから検証情報「ＣＡ」を含むヘッダを除去してから、１番ポートから出力する処理を実行する。以上により、「Ａ」というマッチングキーに適合するパケットに、検証情報「ＣＡ」を付加し、検証情報「ＣＡ」と照合させつつ指定した経路にて転送させる制御が実現される。なお、図５のマッチングキー「Ａ」、「Ｂ」、「Ｘ」は、実際には、図３０に示したような受信パケットのヘッダと照合するルール（ＦｌｏｗＫｅｙ；但し、ワイルドカードを利用可能）によって構成される。

図６は、検証情報ＤＢ２７に保持される情報（検証情報）を模式的に表した図である。図６に示すように、検証情報ＤＢ２７には、上記したマッチングキー「Ａ」、「Ｂ」、・・・、「Ｘ」と、検証情報「ＣＡ」、「ＣＢ」、・・・、「ＣＸ」の対応関係が保持される。検証情報生成部２８は、フローエントリ管理部２４から要求された処理規則（フローエントリ）対応する検証情報を生成して、それを検証情報ＤＢ２７に登録する処理を行う。このような検証情報は、例えば、照合規則（以下、「マッチングキー」とする。）やその他情報を引数とする所定の関数（ハッシュ関数等）を用いて、少なくとも、受信パケットと適合する複数の照合規則のそれぞれに対応する複数の処理規則の中で一意、つまり、これら処理規則に少なくとも同一の検証情報が付与されないよう生成することができる。また、乱数により統計的に一意な検証情報を生成することもできる（具体例は、後に詳述する。）。検証情報ＤＢ２７は競合する可能性のある複数の処理規則（フローエントリ）間での検証情報重複を防ぐ目的のものであり、必ずしも図６の形式である必要はない。また、検証情報の重複を確率・統計的に回避することにより、検証情報ＤＢ２７を省略することも可能である。

なお、ノード１０に対して追加または更新を指示した処理規則（フローエントリ）および当該処理規則に関連付けられた検証情報を保持する必要が無い場合、フローエントリＤＢ２１は省略することが可能である。同様に、処理規則に関連付けて生成した検証情報を保持する必要が無い場合、検証情報ＤＢ２７を省略することも可能である。また、フローエントリＤＢ２１や検証情報ＤＢ２７を別途外部サーバ等に設ける構成も採用可能である。

上記のような制御装置（コントローラ）２０は、非特許文献１、２のオープンフローコントローラに、少なくとも上記検証情報生成部２８と、ノード１０に処理規則（フローエントリ）と当該処理規則に関連付けらけた検証情報を設定する機能を追加することにより実現することが可能である。

図７は、ノード１０の詳細構成を表した図である。図７を参照すると、ノード１０は、制御装置（コントローラ）２０と通信する制御装置通信部１１と、フローテーブル１３を管理するフローテーブル管理部１２と、パケットバッファ１４と、転送処理部１５とを備えて構成される。なお、ノード１０は、必ずしもパケットバッファ１４を備えていなくともよい。

転送処理部１５は、テーブル検索部１５３と、アクション実行部１５４とを含んで構成される。テーブル検索部１５３は、ある処理規則（フローエントリ）に関連付けられた検証情報と、受信パケットに付加された検証情報とを照合し、一致するか否かを判定する検証情報照合部１５２を含んで構成され、フローテーブル１３から、受信パケットに適合するマッチングキーを持つ処理規則（フローエントリ）であって、検証情報が一致する処理規則の処理内容（アクション）をアクション実行部１５４に出力する。アクション実行部１５４は、前記テーブル検索部１５３から出力された処理内容（アクション）を実行する。

上記のようなノード１０は、オープンフロースイッチに、上記検証情報照合部１５２を追加するとともに、そのフローテーブル１３を、処理規則（フローエントリ）に関連付けて検証情報を保持可能な構成とすることで実現することも可能である。また、上記のようなノード１０の検証情報照合部１５２を含むテーブル検索部１５３は、ノード１０を構成するコンピュータに実行させるプログラムによって実現することもできる。

図８は、図５のＤＰＩＤが２であるノード（図３のノード＃２）のフローテーブル１３に保持される情報（フローエントリおよび検証情報）を模式的に表した図である。図８に示すように、フローテーブル１３には、図５のフローエントリＤＢ２１の該当するＤＰＩＤのエントリと同一内容のフローエントリおよび検証情報が設定される。図５のＤＰＩＤが１、３であるノード（図３のノード＃１、＃３）にも、同様に、それぞれのＤＰＩＤに対応するフローエントリおよび検証情報が設定されることになる。

図９は、制御装置（コントローラ）２０により設定されたアクション（Ｓｅｔ Ｈｅａｄｅｒ ｉｎｃｌｕｄｉｎｇ “ＣＡ”；図５のＤＰＩＤ＝１のノードのアクション（Ａｃｔｉｏｎｓ）参照）に基づき、ノード１０にて作成される検証情報付きパケットの構成を説明するための図である。図９の例では、検証情報付きパケット３２は、検証情報を含んだ検証情報付き追加ヘッダ３３をユーザパケット３１の先頭に付加した構成となっている。

図１０は、上記検証情報付き追加ヘッダ３３の構成例を示す図である。図１０の例では、検証情報付き追加ヘッダ３３は、ＭＡＣ宛先アドレス（ＭＡＣ ＤＡ）、ＭＡＣ送信元アドレス（ＭＡＣ ＳＡ）、上位プロトコルタイプ（Ｅｔｈｅｒ Ｔｙｐｅ）、トータルヘッダ長（Ｔｏｔａｌ Ｌｅｎｇｔｈ）に、検証情報を付加した構成となっている。なお、図１０の例では、マッチングキーと乱数を引数とする所定の関数（ハッシュ関数等）により算出した値（ｆ（ｍａｔｃｈｉｎｇ ｋｅｙ，ｒａｎｄ））を検証情報としている。

続いて、上記した制御装置（コントローラ）２０およびノード１０の動作について説明する。図１１は、上記制御装置（コントローラ）２０の動作を表したフローチャートである。図１１を参照すると、制御装置（コントローラ）２０は、ノード１０から問い合わせ（処理規則の作成要求；図１２のステップＳ１１１参照）を受けると（ステップＳ００１；Ｐａｃｋｅｔ−Ｉｎ）、前記問い合わせに係るパケットに検証情報が含まれているか否かを確認する（ステップＳ００２）。ここで、問い合わせに係るパケットに検証情報が含まれている場合（ステップＳ００２のＹｅｓ）、当該パケットに対応する処理規則は作成済みであるため、制御装置（コントローラ）２０は、フローエントリＤＢ２１から当該パケットに対応する処理規則および当該処理規則に関連付けられた検証情報を取り出して（ステップＳ０１２）、ステップＳ００８に進む。

一方、問い合わせに係るパケットに検証情報が含まれていない場合（ステップＳ００２のＮｏ）、制御装置（コントローラ）２０は、トポロジ管理部２２にて構築されたネットワークトポロジ情報を取得し、パケットの転送経路を計算する（ステップＳ００３）。

前記パケットの転送経路を計算の結果、経路を作成できない、経路上のノードが故障している等の理由により、転送できないと判定した場合（ステップＳ００４のＮｏ）を除き、制御装置（コントローラ）２０は、前記計算された転送経路に対応するアクションを計算する（ステップＳ００５）。続いて、当該経路上の各ノード１０に適用する処理規則（フローエントリ）に関連付ける検証情報を生成する（ステップＳ００６）。さらに、制御装置（コントローラ）２０は、当該問い合わせに係るパケットが属するフローを特定するためのマッチングキーおよび前記アクションを含む当該経路上の各ノード１０に適用する処理規則（フローエントリ）を生成する（ステップＳ００７）。

処理規則（フローエントリ）および検証情報の取得または生成が完了すると、制御装置（コントローラ）２０は、前記生成した処理規則（フローエントリ）および検証情報の設定指示（Ｆｌｏｗ Ｍｏｄ（Ａｄｄ））を生成し（ステップＳ００８）、当該処理規則（フローエントリ）によって実現されるパケット転送経路上のノード１０に対して、処理規則（フローエントリ）および検証情報の設定指示（Ｆｌｏｗ Ｍｏｄ（Ａｄｄ））を送信する（ステップＳ００９）。

その後、ノード１０がパケットをバッファしていない場合（ステップＳ０１０のＮｏ）、制御装置（コントローラ）２０は、パケットの出力指示（Ｐａｃｋｅｔ−Ｏｕｔ）を行う（ステップＳ０１１）。このパケットの出力指示は、出力すべきパケット（ステップＳ００１のＰａｃｋｅｔ−Ｉｎで受信したパケット）と、当該パケットに対し実行すべきアクション（検証情報の付与と指定ポートから出力）とを指示すること、あるいは、出力すべきパケット（ステップＳ００１のＰａｃｋｅｔ−Ｉｎで受信したパケット）と、当該パケットに対し実行すべきアクション（フローテーブルの検索）を指示することによって行われる。なお、ノード１０がパケットをバッファしている場合（ステップＳ０１０のＹｅｓ）、後に説明するように、ノード１０にパケットの出力処理を行わせることができるため、制御装置（コントローラ）２０側の処理は省略される。

図１２は、ノード１０の動作を表したフローチャートである。図１２を参照すると、ノード１０は、ホストや他のノード１０からパケットを受信すると（ステップＳ１０１）、フローテーブル１３から、受信パケットに適合するマッチングキーを持つ処理規則（フローエントリ）を検索する（ステップＳ１０２）。

ステップＳ１０２にて、処理規則（フローエントリ）を抽出できた場合（ステップＳ１０３のＹｅｓ）、ノード１０は、受信パケットに検証情報が含まれているか否かを確認する（ステップＳ１０４）。なお、本実施形態においては、受信パケットに追加ヘッダが付加されているか否かにより、検証情報が含まれているか否かを判別することができる。

ここで、受信パケットに検証情報が含まれていない場合、ノード１０は、抽出した処理規則（フローエントリ）に記述されたアクションを実行する（ステップＳ１０７）。

一方、ステップＳ１０４にて、受信パケットに検証情報が含まれていると判定された場合、ノード１０は、受信パケットに含まれている検証情報と、前記抽出した処理規則（フローエントリ）に関連付けられている検証情報とを照合する（ステップＳ１０５）。

前記検証情報同士が一致した場合、ノード１０は、抽出した処理規則（フローエントリ）に記述されたアクションを実行する（ステップＳ１０７）。つまり、検証情報が含まれているパケットについてアクションを実行するには、マッチングキーによる検索にて適合する処理規則（フローエントリ）が見つかることに加えて、処理規則（フローエントリ）に関連付けられた検証情報が受信パケットのものと一致することが必要となっている。

一方、ステップＳ１０３で受信パケットに適合する処理規則（フローエントリ）が見つからなかった場合および処理規則（フローエントリ）が見つかったが検証情報同士が一致しない場合、ノード１０は、抽出した処理規則（フローエントリ）に記述されたアクションを実行することなく、ステップＳ１１１に進み、制御装置（コントローラ）２０に対し問い合わせ（受信パケットに対応する処理規則（フローエントリ）および検証情報の作成および送信要求）を行う。

ステップＳ１１１では、ノード１０は、受信パケットをパケットバッファ１４に保存するとともに、制御装置（コントローラ）２０に、受信パケットを送信し、処理規則および検証情報の作成を要求する。その後は、制御装置（コントローラ）２０にて、図１１に示す手順に従って処理規則および検証情報を含む応答処理が行われる。

制御装置（コントローラ）２０から、処理規則（フローエントリ）および検証情報の設定指示（Ｆｌｏｗ Ｍｏｄ（Ａｄｄ））を受信すると、ノード１０は、自身のフローテーブル１３に、Ｆｌｏｗ Ｍｏｄ（Ａｄｄ）に従い処理規則（フローエントリ）と当該処理規則に関連付けられた検証情報を設定する（ステップＳ１１２）。

次に、ノード１０は、パケットバッファ１４に受信パケットが保存されているか否かを確認し（ステップＳ１１３）、保存されていれば（ステップＳ１１３のＹｅｓ）、当該受信パケットを読み出し（ステップＳ１１４）、前記設定した処理規則（フローエントリ）に定められた処理内容（アクション；検証情報の付与と受信パケットの指定ポートからの出力）を実行する（ステップＳ１０７）。これにより、受信パケットが次ホップのノードに転送される。

一方、ノード１０がパケットバッファ１４を備えていない場合など、ノード１０がユーザパケットを保持していない場合（ステップＳ１１３のＮｏ）、制御装置（コントローラ）２０からのパケット出力指示（Ｐａｃｋｅｔ−Ｏｕｔ）が受信される（ステップＳ１１６）。

前記パケット出力指示（Ｐａｃｋｅｔ−Ｏｕｔ）を受信したノード１０は、パケットバッファ１４を備えている場合にはパケットバッファ１４にパケットが保存されているか否かを確認し（ステップＳ１１７）、保存されていれば（ステップＳ１１７のＹｅｓ）、当該パケットを読み出し（ステップＳ１１８）、パケット出力指示（Ｐａｃｋｅｔ−Ｏｕｔ）とともに受信した処理内容（アクション；ここでは、受信パケットの検証情報の付与と指定ポートからの出力、または、フローテーブルの検索）を実行する（ステップＳ１０７）。また、パケットを保存していない場合（ステップＳ１１７のＮｏ）、ノード１０は、パケット出力指示（Ｐａｃｋｅｔ−Ｏｕｔ）とともに受信したパケットについて、パケット出力指示（Ｐａｃｋｅｔ−Ｏｕｔ）とともに受信した処理内容（アクション；ここでは、パケットの検証情報の付与と指定ポートからの出力、または、フローテーブルの検索）を実行する（ステップＳ１０７）。これにより、受信パケットが次ホップのノードに転送される。

図１３、図１４は、ホスト（Ａ）からホスト（Ｂ）宛てのパケットを受信したノード＃１が、制御装置（コントローラ）２０に対し問い合わせ（処理規則および検証情報の作成要求）を行ってから、ホスト（Ｂ）にパケットが届けられるまでの一連の流れを説明するための参考図とシーケンス図である。

図１３、図１４に示すように、ホスト（Ａ）が、ノード＃１に対し、ホスト（Ｂ）宛てのユーザパケットを送信すると（図１３、図１４のＳＴ１；Ｕｓｅｒ Ｐａｃｋｅｔ）、ノード＃１は、フローテーブル１３の検索の結果、受信したパケットに適合する処理規則（フローエントリ）が無い未知のパケットであると判定し（図１２のステップＳ１０３のＮｏ）、制御装置（コントローラ）２０に対し問い合わせ（処理規則（フローエントリ）および検証情報の作成要求）を行う（図１３、図１４のＳＴ２；Ｐａｃｋｅｔ−Ｉｎ）。

前記問い合わせ（処理規則（フローエントリ）および検証情報の作成要求）を受けた制御装置（コントローラ）２０は、図１１のフローチャートに従って、当該パケットの転送経路上のノード＃１〜＃３に設定すべき処理規則（フローエントリ）および検証情報（ＣＡ）を作成し、ノード＃１〜＃３に対し、それぞれ送信する（図１３、図１４のＳＴ３−１〜ＳＴ５−１；Ｆｌｏｗ Ｍｏｄ（Ａｄｄ） ｗ／ ＣＡ）。

ノード＃１〜＃３は、制御装置（コントローラ）２０から送信された処理規則（フローエントリ）と検証情報（ＣＡ）を自装置のフローテーブル１３に追加するとともに、バッファＩＤが付加されている場合には当該パケットに対するアクションを実行する（図１３、図１４のＳＴ３−２〜ＳＴ５−２）。以下の説明では、ノード＃２には、何らかの理由で、図１３、図１４のＳＴ４−１で送信された処理規則（フローエントリ）および検証情報（ＣＡ）が到達せず、ノード＃２のフローテーブル１３には、処理規則（フローエントリ）および検証情報（ＣＡ）が追加されなかったものとする。

ここで、ノード＃１は、ＳＴ３−１にて受信した処理規則中のアクション（図５のＤＰＩＤ＝１、マッチングキー＝Ａ、検証情報＝ＣＡのアクション（Ａｃｔｉｏｎｓ）参照）に従い、検証情報（ＣＡ）を含んだ追加ヘッダを付加したユーザパケットを生成し（図９参照）、指定ポート（ノード＃２に接続されたポート）から出力する処理を実行する（図１３、図１４のＳＴ６）。

検証情報（ＣＡ）を含んだ追加ヘッダが付加されたユーザパケットを受信すると、ノード＃２は、フローテーブル１３の検索の結果、受信したパケットに適合する処理規則（フローエントリ）が無い、あるいは、受信したパケットに適合する処理規則（フローエントリ）があるが検証情報が一致しないと判定し（図１２のステップＳ１０３のＮｏまたはステップ１０６のＮｏ）、制御装置（コントローラ）２０に対し問い合わせ（処理規則（フローエントリ）および検証情報の作成要求）を行う（図１３、図１４のＳＴ８；Ｐａｃｋｅｔ−Ｉｎ）。

前記問い合わせ（処理規則（フローエントリ）および検証情報の作成要求）を受けた制御装置（コントローラ）２０は、図１１のフローチャートに従って、当該パケットの転送経路上のノード＃２に設定すべき処理規則（フローエントリ）および検証情報（ＣＡ）を取得し（図１１のステップＳ０１２）、ノード＃２に対し、送信する（図１３、図１４のＳＴ９；Ｆｌｏｗ Ｍｏｄ（Ａｄｄ） ｗ／ ＣＡ）。

ノード＃２は、制御装置（コントローラ）２０から送信された処理規則（フローエントリ）および検証情報を自装置のフローテーブル１３に追加するとともに、バッファＩＤが付加されている場合にはアクションを実行する（図１３、図１４のＳＴ１０）。

ここで、ノード＃２は、ＳＴ１０にて受信した処理規則中のアクション（図５のＤＰＩＤ＝２、マッチングキー＝Ａ、検証情報＝ＣＡのアクション（Ａｃｔｉｏｎｓ）参照）に従い、検証情報（ＣＡ）を含んだ追加ヘッダが付加されたユーザパケットを、指定ポート（ノード＃３に接続されたポート）から出力する処理を実行する（図１３、図１４のＳＴ１１）。

検証情報（ＣＡ）を含んだ追加ヘッダが付加されたユーザパケットを受信すると、ノード＃３は、フローテーブル１３の検索の結果、受信したパケットに適合する処理規則（フローエントリ）であり、検証情報も一致すると判定し（図１２のステップＳ１０３のＹｅｓかつステップ１０６のＹｅｓ）、抽出・確認した処理規則（フローエントリ）に定められたアクションを実行する（図１３、図１４のＳＴ１２）。

具体的には、ノード＃３は、ＳＴ１２にて抽出・確認した処理規則中のアクション（図５のＤＰＩＤ＝３、マッチングキー＝Ａ、検証情報＝ＣＡのアクション（Ａｃｔｉｏｎｓ）参照）に従い、ユーザパケットから検証情報（ＣＡ）を含んだ追加ヘッダを除去した後、指定ポート（ホスト（Ｂ）に接続されたポート）から出力する処理を実行する（図１３、図１４のＳＴ１３）。

以上のように、本実施形態によれば、処理規則（フローエントリ）のマッチングキーが、受信パケットのヘッダ情報と一致するだけでなく、別途制御装置（コントローラ）２０にて生成された検証情報が一致することを条件として、アクションを実行するようにしているため、冒頭に述べた意図しない処理規則（フローエントリ）のアクションが実行されるという事態を回避することができる。

なお、本実施形態では、検証情報の付加を要しないパケットの存在を考慮してステップＳ１０４において、受信パケットに検証情報が含まれていない場合、検証情報の照合を行わずにアクションを実行することとしているが、受信パケットに検証情報が含まれていない場合、例外なくアクションの実行を抑止するようにしてもよい。

［第２の実施形態］
続いて、本発明の第２の実施形態について図面を参照して詳細に説明する。上記本発明の第１の実施形態では、検証情報を含んだ追加ヘッダによりパケットに検証情報を付加するものとして説明したが、追加ヘッダを用いずに検証情報をパケットに含めることもできる。以下、追加ヘッダを用いずに検証情報をパケットに含めるようにした第２の実施形態について説明する。なお、第２の実施形態のノード１０および制御装置（コントローラ）２０の基本的な構成は、上記第１の実施形態と同等であるので、以下、相違点を中心に説明を行う。

図１５は、本実施形態の制御装置（コントローラ）２０のフローエントリＤＢ２１に保持される情報（フローエントリ）を模式的に表した図である。第１の実施形態との相違点は、フローエントリＤＢ２１に独立した検証情報フィールドを持たず、フローエントリのマッチングキーフィールドに、検証情報（ＣＡ）を含んだマッチングキーが格納されている点と、アクションとして、ＭＡＣ ＤＡフィールドに検証情報を書き込む（元に戻す）処理（厳密には、ＭＡＣ ＤＡフィールドの値のＤｎ’（図１９参照）への置換と復元）が規定されている点である。以下、オリジナルのＭＡＣ ＤＡフィールドの値を「Ｄｎ」とし、検証情報（ＣＡ）を含むよう変換された後の値を「Ｄｎ’」とする。

例えば、図１５のＤＰＩＤが１であるノード（例えば、図３のノード＃１）は、「Ａ」というマッチングキーに適合するパケットを受信した場合に、そのアクションフィールド（Ａｃｔｉｏｎｓ）に従い、パケットのＭＡＣ ＤＡフィールドに、検証情報（ＣＡ）を含む値Ｄ１’をセットしてから、９番ポートから出力する処理を実行する。ＤＰＩＤが２であるノード（例えば、図３のノード＃２）は、ＤＰＩＤが１であるノード（例えば、図３のノード＃１）からＭＡＣ ＤＡフィールドに検証情報（ＣＡ）がセットされたパケット（マッチングキーＡ’に適合するパケット）を受信すると、６番ポートから出力する処理を実行する。そして、ＤＰＩＤが３であるノード（例えば、図３のノード＃３）は、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）からＭＡＣ ＤＡフィールドに検証情報（ＣＡ）がセットされたパケット（マッチングキーＡ’に適合するパケット）を受信すると、そのＭＡＣ ＤＡフィールドを元々の受信パケットのＭＡＣ ＤＡと同じ内容（Ｄ１）に書き戻してから、１番ポートから出力する処理を実行する。以上により、転送経路の先頭ホップのノードにて検証情報「ＣＡ」を付加し、検証情報「ＣＡ」と照合させつつ、指定した経路にて転送させる制御が実現される。

図１６は、本実施形態の制御装置（コントローラ）２０の検証情報ＤＢ２７に保持される情報（検証情報）を模式的に表した図である。第１の実施形態との相違点は、ＭＡＣ ＤＡフィールドを元々の受信パケットのＭＡＣ ＤＡと同じ内容に書き戻すためのＯｒｉｇｉｎａｌ ＭＡＣ ＤＡフィールドの内容（図１５のＤ１、Ｄ２、ＤＸに相当。）と、この書き戻し処理を実行させる最終ホップのノード番号が追加されている点である。

図１７は、本実施形態のノード１０ａの詳細構成を表した図である。第１の実施形態のノード１０の構成を表した図７との相違点は、上記検証情報の相違に伴い、検証情報照合部１５２ａの照合動作が異なるため（後に詳述）、検証情報照合部１５２ａ、テーブル検索部１５３ａ、転送処理部１５ａがそれぞれ置き換えられている点である。

図１８は、図１５のＤＰＩＤが２であるノード（図３のノード＃２）のフローテーブル１３に保持される情報（フローエントリ）を模式的に表した図である。図１８に示すように、フローテーブル１３には、図１５のフローエントリＤＢ２１から該当するＤＰＩＤのフローエントリが設定される。図１５のＤＰＩＤが１、３であるノード（図３のノード＃１、＃３）にも、同様に、それぞれのＤＰＩＤに対応するフローエントリが設定されることになる。

図１９は、制御装置（コントローラ）２０により設定されたアクション（Ｓｅｔ ＭＡＣ ＤＡ ｔｏ Ｄ１’；図１５のＤＰＩＤ＝１のノードのアクション（Ａｃｔｉｏｎｓ）参照）に基づき、ノード１０にて書き換えられるパケットの構成を説明するための図である。図１９の例では、検証情報付きパケット３２ａは、ユーザパケット３１のＭＡＣ ＤＡフィールドに、図１９の下段に示す４８ビットの情報を書き込んだ構成となっている。なお、図１９の例では、検証情報を含むことを示す８ビットの固定データ、関数ｆ_１（最終ホップのノードのＤＰＩＤ，オリジナルのＭＡＣ ＤＡ）、関数ｆ_２（マッチングキー，乱数）を書き込むものとしているが、これはあくまで一例であり、検証情報の格納に用いるフィールドや、検証情報の内容、オリジナルのデータを縮退するための関数等は適宜変更することができる。

続いて、本実施形態の動作について説明する。図２０は、本発明の第２の実施形態の制御装置（コントローラ）の動作を表したフローチャートである。第１の実施形態の制御装置（コントローラ）の動作を表した図１１と相違するのは、ステップＳ００２ａにおいて、問い合わせを受けたパケットに検証情報が含まれているか否かを確認する際に、追加ヘッダではなく、ＭＡＣ ＤＡに上述した固定データ（図１９参照）が書き込まれているか否かを確認する点である。その他は、第１の実施形態と同等であるので説明を省略する。

図２１は、本発明の第２の実施形態のノード１０ａの動作を表したフローチャートである。第１の実施形態のノード１０の動作を表した図１２と相違するのは、ステップＳ１０４ａにおいて、受信パケットに検証情報が含まれているか否かを確認する際に、追加ヘッダではなく、ＭＡＣ ＤＡに上述した固定データ（図１９参照）が書き込まれているか否かを確認する点と、最終ホップのノードが追加ヘッダの削除ではなく、アクションに従ってオリジナルのＭＡＣ ＤＡフィールドを復元してからパケットを転送する点である。その他は、第１の実施形態と同等であるので説明を省略する。

以上のように、本発明は、既存パケットの特定のフィールドに検証情報を含める形態でも実現することが可能である。

［第３の実施形態］
続いて、本発明の第３の実施形態について図面を参照して詳細に説明する。上記本発明の第１の実施形態では、各ノードが同一の検証情報をそのフローテーブルのフローエントリに関連付けて格納するものとして説明したが、各ノードがそれぞれ異なる検証情報にて照合を行う構成も採用可能である。以下、各ノードがそれぞれ異なる検証情報にて照合を行うようにした第３の実施形態について説明する。なお、第３の実施形態のノード１０および制御装置（コントローラ）２０の基本的な構成は、上記第１の実施形態と同等であるので、以下、相違点を中心に説明を行う。

図２２は、本実施形態の制御装置（コントローラ）２０のフローエントリＤＢ２１に保持される情報（フローエントリおよび検証情報）を模式的に表した図である。第１の実施形態との相違点は、各ノードの検証情報の生成処理（図１１のステップＳ００６）をノード数分実行しておき、フローエントリＤＢ２１に独立した検証情報フィールドを持たない代わりに、アクションフィールドに、それぞれ異なる検証情報を含んだ追加ヘッダを付加させる処理を追加した点である（各ノードがそれぞれ異なる検証情報含んだヘッダを付加するため、フローエントリに関連付けられた検証情報が当該フローエントリ内に記述されることになり、独立して検証情報とフローエントリの対応関係を保持する必要がないため、検証情報フィールドは不要となる）。

例えば、図２２のＤＰＩＤが１であるノード（例えば、図３のノード＃１）は、「Ａ１」というマッチングキーに適合するパケットを受信した場合に、そのアクションフィールド（Ａｃｔｉｏｎｓ）に従い、検証情報（Ｃ２Ａ）を格納した追加ヘッダを受信パケットに付加してから、９番ポートから出力する処理を実行する。同様に、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）は、ＤＰＩＤが１であるノード（例えば、図３のノード＃１）から、検証情報（Ｃ２Ａ）を格納した追加ヘッダが付加されたパケット（マッチングキーＡ２に適合するパケット）を受信すると、追加ヘッダの検証情報（Ｃ２Ａ）を検証情報（Ｃ３Ａ）に書き換えた後、６番ポートから出力する処理を実行する。そして、ＤＰＩＤが３であるノード（例えば、図３のノード＃３）は、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）から、検証情報（Ｃ３Ａ）を格納した追加ヘッダが付加されたパケット（マッチングキーＡ３に適合するパケット）を受信すると、当該パケットから追加ヘッダを除去した後、１番ポートから出力する処理を実行する。以上により、転送経路の先頭ホップのノードから順番に、検証情報を書き換えながら、その検証情報と照合させつつ、指定した経路にて転送させる制御が実現される。

図２３は、本実施形態の制御装置（コントローラ）２０の検証情報ＤＢ２７に保持される情報（検証情報）を模式的に表した図である。第１の実施形態との相違点は、ＤＰＩＤフィールドが追加され、ノード毎に、マッチングキーと、検証情報の対応関係が格納されている点である。なお、これはあくまで一例であり、検証情報ＤＢ２７に保持される情報は、検証情報生成のための関数等に依存して、適宜変更することができる。

図２４は、図２２のＤＰＩＤが２であるノード（図３のノード＃２）のフローテーブル１３に保持される情報（フローエントリおよび検証情報）を模式的に表した図である。図２４に示すように、フローテーブル１３には、図２２のフローエントリＤＢ２１から該当するＤＰＩＤのフローエントリおよび検証情報が設定される。図２２のＤＰＩＤが１、３であるノード（図３のノード＃１、＃３）にも、同様に、それぞれのＤＰＩＤに対応するフローエントリおよび検証情報が設定されることになる。

本実施形態は第１の実施形態と比較して、制御装置が各ノードの検証情報を生成する点と個々のノードで行われるアクションが異なるのみであり、基本的な動作は第１の実施形態と同一であるので説明は省略する（図１１、図１２参照）。

以上のように、個々のノードが処理規則中のアクションにより、検証情報を書き換えていく本実施形態によれば、第１の実施形態と比較して、ある通信フローに対してマッチングキーの異なるフローエントリを経路上のノードに設定することが可能となる。

［第４の実施形態］
続いて、本発明の第４の実施形態について図面を参照して詳細に説明する。本発明の第４の実施形態は、上記本発明の第２の実施形態と第３の実施形態とを組み合わせたものであり、追加ヘッダを用いずに、かつ、各ノードがそれぞれ異なる検証情報にて照合を行うものである。なお、第４の実施形態のノード１０および制御装置（コントローラ）２０の基本的な構成は、上記第１〜３の実施形態と同等であるので、以下、相違点を中心に説明を行う。

図２５は、本実施形態の制御装置（コントローラ）２０のフローエントリＤＢ２１に保持される情報（フローエントリ）を模式的に表した図である。第３の実施形態との相違点は、アクションフィールドに、それぞれ異なる検証情報を含んだ追加ヘッダを付加させる処理ではなく、ＭＡＣ ＤＡフィールドの値を各ノードの検証情報を含む値に書き換えていき最終ホップで復元する処理が追加されている点である。

例えば、図２５のＤＰＩＤが１であるノード（例えば、図３のノード＃１）は、「Ａ」というマッチングキーに適合するパケットを受信した場合に、そのアクションフィールド（Ａｃｔｉｏｎｓ）に従い、パケットのＭＡＣ ＤＡフィールドに検証情報（Ｃ２Ａ）を含む値Ｄ１’をセットしてから、９番ポートから出力する処理を実行する。同様に、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）は、ＤＰＩＤが１であるノード（例えば、図３のノード＃１）からＭＡＣ ＤＡフィールドに検証情報（Ｃ２Ａ）がセットされたパケット（マッチングキーＡ’に適合するパケット）を受信すると、パケットのＭＡＣ ＤＡフィールドを、検証情報（Ｃ３Ａ）を含む値Ｄ１”に書き換えた後、６番ポートから出力する処理を実行する。そして、ＤＰＩＤが３であるノード（例えば、図３のノード＃３）は、ＤＰＩＤが２であるノード（例えば、図３のノード＃２）からＭＡＣ ＤＡフィールドに検証情報（Ｃ３Ａ）がセットされたパケット（マッチングキーＡ”に適合するパケット）を受信すると、そのＭＡＣ ＤＡフィールドを元々の受信パケットのＭＡＣ ＤＡと同じ内容（Ｄ１）に書き戻してから、１番ポートから出力する処理を実行する。以上により、転送経路の先頭ホップのノードにて検証情報を順次書き換え、かつ、検証情報と照合させ、指定した経路にて転送させる制御が実現される。

図２６は、本実施形態の制御装置（コントローラ）２０の検証情報ＤＢ２７に保持される情報（検証情報）を模式的に表した図である。第３の実施形態との相違点は、ＭＡＣ ＤＡフィールドを元々の受信パケットのＭＡＣ ＤＡと同じ内容に書き戻すためのＯｒｉｇｉｎａｌ ＭＡＣ ＤＡフィールドの内容（図２５のＤ１、Ｄ２、ＤＸに相当。）と、この書き戻し処理を実行させる最終ホップのノード番号が追加されている点である。なお、これはあくまで一例であり、検証情報ＤＢ２７に保持される情報は、検証情報生成のための関数等に依存して、適宜変更することができる。

図２７は、図２５のＤＰＩＤが２であるノード（図３のノード＃２）のフローテーブル１３に保持される情報（フローエントリ）を模式的に表した図である。図２７に示すように、フローテーブル１３には、図２５のフローエントリＤＢ２１から該当するＤＰＩＤのフローエントリが設定される。図２５のＤＰＩＤが１、３であるノード（図３のノード＃１、＃３）にも、同様に、それぞれのＤＰＩＤに対応するフローエントリが設定されることになる。

本実施形態は第１の実施形態と比較して、制御装置が各ノードの検証情報を生成する点と個々のノードで行われるアクションが異なるのみであり、基本的な動作は第１の実施形態と同一であるので説明は省略する（図１１、図１２参照）。

以上のように、個々のノードが処理規則中のアクションにより、検証情報を書き換えていく本実施形態によれば、第２の実施形態と比較して、ある通信フローに対してマッチングキーの異なるフローエントリを経路上のノードに設定することが可能となる。

［第５の実施形態］
続いて、本発明の第５の実施形態について図面を参照して詳細に説明する。上記本発明の第３の実施形態では、追加ヘッダにはただ一つの検証情報を格納するものとして説明したが、追加ヘッダに、転送経路上の各ノードがそれぞれ照合すべき検証情報を格納しておき、当該追加ヘッダが付加されたパケットを受信したノードが、それぞれ自身が参照すべき検証情報を特定して、照合動作を行う構成も採用可能である。以下、追加ヘッダに複数の検証情報を格納可能とした第５の実施形態について説明する。なお、第５の実施形態のノード１０および制御装置（コントローラ）２０の基本的な構成は、上記第３の実施形態と同等であるので、以下、相違点を中心に説明を行う。

図２８は、本発明の第５の実施形態で用いるパケットの一例である。図２８の例では、検証情報付きパケット３２ｂは、検証情報を含んだ検証情報付き追加ヘッダ３３ｂをユーザパケット３１の先頭に付加した構成となっている。

図２９は、上記検証情報付き追加ヘッダ３３ｂの構成例を示す図である。図２９の例では、検証情報付き追加ヘッダ３３ｂは、ＭＡＣ宛先アドレス（ＭＡＣ ＤＡ）、ＭＡＣ送信元アドレス（ＭＡＣ ＳＡ）、上位プロトコルタイプ（Ｅｔｈｅｒ Ｔｙｐｅ）、トータルヘッダ長（Ｔｏｔａｌ Ｌｅｎｇｔｈ）に、ＤＰＩＤと検証情報との組を複数付加した構成となっている。なお、図２９の例では、個々のノードのマッチングキーと乱数を引数とする所定の関数（ハッシュ関数等）により算出した値（ｆ（ｍａｔｃｈｉｎｇ ｋｅｙ，ｒａｎｄ））を検証情報としている。

本実施形態は第１の実施形態と比較して、制御装置が各ノードの検証情報を生成する点と個々のノードがＤＰＩＤを用いて自身の検証情報を取り出して照合動作を行う点が異なるのみであり、基本的な動作は第１の実施形態と同一であるので説明は省略する（図１１、図１２参照）。

以上のように、本発明は、個々のノードの検証情報を格納した追加ヘッダを付加する構成でも実現可能であり、第３の実施形態と比較して、個々のノードで検証情報を書き換える処理を省略できるという利点がある。

以上、本発明の好適な実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。上記した実施形態の制御装置（コントローラ）２０、２０ａは、専用のサーバとして実現することもでき、ノード１０、１０ａ、１０ｂとしては、上記オープンフロースイッチのほか、ＩＰ網におけるルータ、ＭＰＬＳ（Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）網におけるＭＰＬＳスイッチにて実現することができる。その他、サーバがネットワーク内のノードを集中管理するようなネットワークであれば、本発明を適用することが可能である。

また、上記した第５の実施形態では、追加ヘッダにノード識別子（ＤＰＩＤ）を含めることで、各ノードが自装置が照合すべき検証情報を特定するものとして説明したが、追加ヘッダ中の先頭または末尾の検証情報から使用していき、検証情報が使用済みであることを示す使用済みフラグを立てていく方法や、照合に用いた検証情報を各ノードが追加ヘッダから順次削除していく方法も採用可能である。

また、上記した各実施形態では、最終ホップのノードが追加ヘッダの除去やＭＡＣ ＤＡフィールドを書き戻すものとして説明したが、ホスト側でこれらの処理を行う構成も採用可能である。

また、上記した各実施形態で説明した検証情報として、非特許文献２のＦｌｏｗ Ｃｏｏｋｉｅなどのコントローラがフローエントリを一意に特定するために生成する情報を用いることも可能である。

また、上記した各実施形態では、制御装置２０に検証情報生成部２８を備えるものとして説明したが、ノード１０同士あるいはノード１０と制御装置２０で同期を取る、各ノード１０に検証情報の生成関数や引数を割り当てておくなどして、各ノード１０が検証情報を作成可能であれば、各ノードに、検証情報生成部を生成する構成も採用可能である。

最後に、本発明の好ましい形態を要約する。

［第１の形態］
（上記第１の視点による通信システム参照）

［第２の形態］
第１の形態において、
前記識別子は、照合規則に基づく受信パケットと処理規則との照合結果を検証するために用いられることを特徴とする通信システム。

［第３の形態］
第１、第２の形態において、
前記ノードは、受信パケットと照合規則とを照合して、受信パケットと適合する照合規則に対応する処理規則を検索し、受信パケットの識別子と検索された処理規則に関連付けられた識別子とが対応する場合、検索した処理規則により受信パケットの処理を実行する通信システム。

［第４の形態］
第１、第２の形態において、
前記ノードは、受信パケットの識別子に対応する識別子と関連付けられた処理規則を検索し、該処理規則に対応する照合規則と受信パケットとが照合により適合する場合、検索した処理規則により受信パケットの処理を実行する通信システム。

［第５の形態］
第１〜第４の形態において、
前記識別子は、少なくとも、受信パケットと適合する複数の照合規則のそれぞれに対応する複数の処理規則の中で一意である通信システム。

［第６の形態］
第１〜第４の形態において、
前記識別子は、統計的に一意である通信システム。

［第７の形態］
第１〜第６の形態において、
前記ノードは、受信パケットに、識別子を格納した追加ヘッダが付加されているか否かにより、受信パケットに、前記受信パケットの識別子が含まれているか否かを判定する通信システム。

［第８の形態］
第１〜第６の形態において、
前記ノードは、受信パケットの所定のフィールドに、識別子が格納されているか否かにより、受信パケットに、前記受信パケットの識別子が含まれているか否かを判定する通信システム。

［第９の形態］
第１〜第６、第８いずれか一の形態において、
前記制御装置は、
パケットの転送経路の始点に位置するノードが、受信パケットの所定のフィールドの情報を、識別子を含んだ情報に置き換えてから、当該パケットを転送し、
前記転送経路の終点に位置するノードが、受信パケットの所定のフィールドの情報を、置き換え前の内容に書き戻してから、当該パケットを転送するよう、前記各ノードを制御する通信システム。

［第１０の形態］
第１〜第９いずれか一の形態において、
前記制御装置は、
パケットの転送経路上のノードに設定する処理規則に対し、それぞれ異なる識別子を設定し、前記転送経路上のノードが、順次、受信パケットの識別子を次ホップのノードの識別子に書き換える動作を行うよう、前記各ノードを制御する通信システム。

［第１１の形態］
第１〜第７、第１０いずれか一の形態において、
前記制御装置は、
パケットの転送経路の始点に位置するノードが、受信パケットに、識別子を含んだ追加ヘッダを付加してから、当該パケットを転送し、前記転送経路の終点に位置するノードが、前記追加ヘッダを除去してから、当該パケットを転送するよう、前記各ノードを制御する通信システム。

［第１２の形態］
第７、第１１いずれか一の形態において、
前記追加ヘッダには、パケットの転送経路上のノードにて、それぞれ判定に用いられる複数の識別子が格納されている通信システム。

［第１３の形態］
（上記第２の視点によるノード参照）

［第１４の形態］
（上記第３の視点による制御装置参照）

［第１５の形態］
（上記第４の視点による通信方法参照）

［第１６の形態］
（上記第５の視点による通信方法参照）

［第１７の形態］
（上記第６の視点によるプログラム参照）

［第１８の形態］
（上記第７の視点によるプログラム参照）

なお、上記第１３〜第１８の形態は、上記第１の形態と同様に、第２〜第１２の形態に展開することが可能である。

なお、上記の非特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

１０、１０ａ、１０ｂ ノード
１１ 制御装置通信部
１２ フローテーブル管理部
１３ フローテーブル
１４ パケットバッファ
１５、１５ａ 転送処理部
２０ 制御装置
２１ フローエントリデータベース（フローエントリＤＢ）
２２ トポロジ管理部
２３ 経路・アクション計算部
２４ フローエントリ管理部
２５ 制御メッセージ処理部
２６ ノード通信部
２７ 検証情報データベース（検証情報ＤＢ）
２８ 検証情報生成部
３１ ユーザパケット
３２、３２ａ、３２ｂ 検証情報付きパケット
３３、３３ｂ 検証情報付き追加ヘッダ
１５２、１５２ａ 検証情報照合部
１５３、１５３ａ テーブル検索部
１５４ アクション実行部
２５１ メッセージ解析・処理部
２５２ メッセージ生成部

Claims (32)

1. パケットを処理するノードと、
   パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを、前記ノードに通知する制御装置とを含み、
   前記ノードは、受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記制御装置から通知された前記第一の識別子とが対応するか否かにより判定する
   ことを特徴とする通信システム。
2. 前記第一および第二の識別子は、照合規則に基づく受信パケットと処理規則との照合結果を検証するために用いられることを特徴とする
   請求項１に記載の通信システム。
3. 前記ノードは、受信パケットと照合規則とを比較して、受信パケットに対応する処理規則を検索し、前記第二の識別子と検索された処理規則に関連付けられた前記第一の識別子とが対応する場合、検索した処理規則により受信パケットの処理を実行する
   ことを特徴とする請求項１または２に記載の通信システム。
4. 前記ノードは、前記第二の識別子に対応する前記第一の識別子と関連付けられた処理規則を検索し、該処理規則に対応する照合規則と受信パケットとが対応する場合、検索した処理規則により受信パケットの処理を実行する
   ことを特徴とする請求項１または２に記載の通信システム。
5. 前記第一および第二の識別子は、少なくとも、受信パケットに対応する複数の照合規則のそれぞれに対応する複数の処理規則の中で一意である
   請求項１から４いずれか一に記載の通信システム。
6. 前記第一および第二の識別子は、統計的に一意であることを特徴とする
   請求項１から４いずれか一に記載の通信システム。
7. 前記ノードは、受信パケットに、前記第二の識別子を格納した追加ヘッダが付加されているか否かにより、受信パケットに、前記第二の識別子が含まれているか否かを判定する請求項１から６いずれか一の通信システム。
8. 前記ノードは、受信パケットの所定のフィールドに前記第二の識別子が格納されているか否かにより、受信パケットに、前記第二の識別子が含まれているか否かを判定する請求項１から６いずれか一の通信システム。
9. 前記制御装置は、
   パケットの転送経路の始点に位置するノードが、受信パケットの所定のフィールドの情報を、前記第二の識別子を含んだ情報に置き換えてから、当該パケットを転送し、
   前記転送経路の終点に位置するノードが、受信パケットの所定のフィールドの情報を、置き換え前の内容に書き戻してから、当該パケットを転送するよう、前記各ノードを制御する請求項１から６、８いずれか一の通信システム。
10. 前記制御装置は、
    パケットの転送経路上のノードに設定する処理規則に対し、それぞれ異なる前記第一の識別子を設定し、前記転送経路上のノードが、受信パケットに付与する前記第二の識別子を次ホップのノードに対応する前記第一の識別子に書き換える動作を行うよう、前記各ノードを制御する請求項１から９いずれか一の通信システム。
11. 前記制御装置は、
    パケットの転送経路の始点に位置するノードが、受信パケットに、前記第二の識別子を含んだ追加ヘッダを付加してから、当該パケットを転送し、前記転送経路の終点に位置するノードが、前記追加ヘッダを除去してから、当該パケットを転送するよう、前記各ノードを制御する請求項１から７いずれか一の通信システム。
12. 前記追加ヘッダには、パケットの転送経路上のノードにて、それぞれ判定に用いられる複数の前記第二の識別子が格納されている請求項７または１１の通信システム。
13. 制御装置からの指示に従ってパケットを処理するノードであって、
    パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを、前記制御装置から受信し、
    受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記制御装置から受信した前記第一の識別子とが対応するか否かにより判定する
    ことを特徴とするノード。
14. 前記第一および第二の識別子は、照合規則に基づく受信パケットと処理規則との照合結果を検証するために用いられることを特徴とする
    請求項１３に記載のノード。
15. 受信パケットと照合規則とを比較して、受信パケットに対応する処理規則を検索し、前記第二の識別子と検索された処理規則に関連付けられた前記第一の識別子とが対応する場合、検索した処理規則により受信パケットの処理を実行する
    ことを特徴とする請求項１３または１４に記載のノード。
16. 前記第二の識別子に対応する前記第一の識別子と関連付けられた処理規則を検索し、該処理規則に対応する照合規則と受信パケットとが対応する場合、検索した処理規則により受信パケットの処理を実行する
    ことを特徴とする請求項１３または１４に記載のノード。
17. 前記第一および第二の識別子は、少なくとも、受信パケットに対応する複数の照合規則のそれぞれに対応する複数の処理規則の中で一意である
    請求項１３から１６いずれか一に記載のノード。
18. 前記第一および第二の識別子は、統計的に一意であることを特徴とする
    請求項１３から１６いずれか一に記載のノード。
19. 受信パケットに、前記第二の識別子を格納した追加ヘッダが付加されているか否かにより、受信パケットに、前記第二の識別子が含まれているか否かを判定する請求項１３から１８いずれか一のノード。
20. 受信パケットの所定のフィールドに前記第二の識別子が格納されているか否かにより、受信パケットに、前記第二の識別子が含まれているか否かを判定する請求項１３から１８いずれか一のノード。
21. パケットを処理するノードを制御する制御装置であって、
    パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを生成し、
    前記処理規則と前記第一の識別子を、受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記第一の識別子とが対応するか否かにより判定する前記ノードに対して通知する
    ことを特徴とする制御装置。
22. 前記処理規則と前記第一の識別子との対応関係を管理する
    ことを特徴とする請求項２１に記載の制御装置。
23. 複数の前記ノードの少なくとも１つに、前記第二の識別子をパケットに付与して転送する処理を前記ノードに実行させるための処理規則を通知する
    ことを特徴とする請求項２１または２２に記載の制御装置。
24. 前記第一および第二の識別子は、少なくとも、受信パケットに対応する複数の照合規則のそれぞれに対応する複数の処理規則の中で一意である
    請求項２１から２３いずれか一に記載の制御装置。
25. 前記第一および第二の識別子は、統計的に一意であることを特徴とする
    請求項２１から２３いずれか一に記載の制御装置。
26. パケットの転送経路の始点に位置するノードが、受信パケットの所定のフィールドの情報を、前記第二の識別子を含んだ情報に置き換えてから、当該パケットを転送し、
    前記転送経路の終点に位置するノードが、受信パケットの所定のフィールドの情報を、置き換え前の内容に書き戻してから、当該パケットを転送するよう、前記各ノードを制御する請求項２１から２５いずれか一の制御装置。
27. パケットの転送経路上のノードに設定する処理規則に対し、それぞれ異なる前記第一の識別子を設定し、前記転送経路上のノードが、受信パケットに付与する前記第二の識別子を次ホップのノードに対応する前記第一の識別子に書き換える動作を行うよう、前記各ノードを制御する請求項２１から２６いずれか一の制御装置。
28. パケットの転送経路の始点に位置するノードが、受信パケットに、前記第二の識別子を含んだ追加ヘッダを付加してから、当該パケットを転送し、前記転送経路の終点に位置するノードが、前記追加ヘッダを除去してから、当該パケットを転送するよう、前記各ノードを制御する請求項２１から２５いずれか一の制御装置。
29. 制御装置からの指示に従ってパケットを処理するノードの通信方法であって、
    パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを、前記制御装置から受信し、
    受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記制御装置から受信した前記第一の識別子とが対応するか否かにより判定する
    ことを特徴とする通信方法。
30. パケットを処理するノードを制御する制御装置による通信方法であって、
    パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを生成し、
    前記処理規則と前記第一の識別子を、受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記第一の識別子とが対応するか否かにより判定する前記ノードに対して通知する
    ことを特徴とする通信方法。
31. 制御装置からの指示に従ってパケットを処理するノードに、
    パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを、前記制御装置から受信する処理と、
    受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記制御装置から受信した前記第一の識別子とが対応するか否かにより判定する処理と
    を実行させることを特徴とするプログラム。
32. パケットを処理するノードを制御する制御装置に、
    パケットに含まれる情報と比較するための照合規則と該照合規則に対応するパケットの処理ルールとを含む処理規則と、該処理規則を識別するための第一の識別子とを生成する処理と、
    前記処理規則と前記第一の識別子を、受信パケットに対応する処理規則による受信パケットの処理の可否を、受信パケットに付与された第二の識別子と、前記第一の識別子とが対応するか否かにより判定する前記ノードに対して通知する処理と
    を実行させることを特徴とするプログラム。

Images