通信システム
【課題】パケット転送到達性確認を実行してサービス性の向上を図る。
【解決手段】入口転送制御部２ａと出口転送制御部２ｂとの間で、プロバイダドメイン２０内に、重要フロー転送用コネクションＣを確立し、入口転送制御部２ａは、送信元ユーザ端末１ａから転送されたユーザフローパケットが、重要フローパケットｆ１であるか、一般フローパケットｆ２であるかを判別する。重要フローパケットｆ１には、カプセリングを行ってカプセル化重要フローパケットｃｐを生成し、カプセル化重要フローパケットｃｐを重要フロー転送用コネクションＣを通じて転送する。出口転送制御部２ｂは、重要フロー転送用コネクションＣを通じて受信したカプセル化重要フローパケットｃｐをデカプセリングし、デカプセリング後の重要フローパケットｆ１を宛先ユーザ端末３ａへ転送する。
【解決手段】入口転送制御部２ａと出口転送制御部２ｂとの間で、プロバイダドメイン２０内に、重要フロー転送用コネクションＣを確立し、入口転送制御部２ａは、送信元ユーザ端末１ａから転送されたユーザフローパケットが、重要フローパケットｆ１であるか、一般フローパケットｆ２であるかを判別する。重要フローパケットｆ１には、カプセリングを行ってカプセル化重要フローパケットｃｐを生成し、カプセル化重要フローパケットｃｐを重要フロー転送用コネクションＣを通じて転送する。出口転送制御部２ｂは、重要フロー転送用コネクションＣを通じて受信したカプセル化重要フローパケットｃｐをデカプセリングし、デカプセリング後の重要フローパケットｆ１を宛先ユーザ端末３ａへ転送する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol）ネットワーク上で通信を行う通信システムに関する。
【背景技術】
【０００２】
通信ネットワークでは、特定の通信のための帯域を予約し、一定の通信速度や品質を保障する技術であるＱｏＳ（Quality of Service）が行われており、ユーザに対して満足度の高い通信サービスを提供するために、ＱｏＳ保障のニーズが高まっている。ＱｏＳの主な制御としては、転送ＱｏＳ制御およびパケット転送障害検出制御がある。
【０００３】
（１）転送ＱｏＳ制御について。
Ｘ．２５（コネクション型のデータ通信を行うパケット交換用のプロトコル体系）によるＯＳＩ（Open Systems Interconnection）ネットワークでは、エンドノード（Ｘ．２５端末）と、ネットワークノード（Ｘ．２５交換機）とに、Ｘ．２５シグナリングによる呼制御機能が実装されて、転送ＱｏＳ制御が行われている。
【０００４】
転送ＱｏＳ制御の具体的な内容としては、特定の呼を優先して転送する優先転送制御、呼毎に転送帯域を制御する転送帯域制御、特定の呼が相手先に到達したか否かを確認する転送到達性確認制御があり、これら３つの制御がＯＳＩネットワーク上で実現される。
【０００５】
一方、現在の一般的なＩＰネットワークで行われる転送ＱｏＳ制御では、上記の優先転送制御は、Diffserv（Differentiated Services）制御に置き換わり、転送帯域制御は、ＲＳＶＰ（Resource reSerVation Protocol）シグナリングによるIntserv（Integrated Services）制御に置き換わり、転送到達性確認制御は、トランスポート層によるＴＣＰ（Transmission Control Protocol）制御に置き換わっている。
【０００６】
ここで、Diffservは、複数の通信フローをまとめてクラスを作り、クラス毎にＱｏＳを保障するもので、複数のクラス間で相対的な転送性能差をつけることによって、トラフィックの優先転送制御を行うものである。
【０００７】
具体的には、エンドノード（ＩＰ端末）では、フローの種類によるクラス分けを行い、ＩＰｖ４の場合、ＩＰパケットの８ビットのＴＯＳ（Type of Service）フィールドの６ビットを使って、クラス分け情報であるＤＳＣＰ（DiffServ Code Point）を書きこむ（これをマーキングという）。
【０００８】
そして、ネットワークノード（ＩＰルータ）では、ＤＳＣＰ値を参照し、ＤＳＣＰ値により定義されるＰＨＢ（Per-Hop Behavior：Diffserv対応ノードの動作に関する規則を記述したもの）に応じてクラス分けを行ってパケット転送を行う。
【０００９】
また、Intservは、通信フロー毎にＱｏＳを保障するものであり、エンドノードとネットワークノードとの間で、ネットワークの帯域を予約するシグナリング・プロトコルであるＲＳＶＰを使用して、転送帯域を確保する。
【００１０】
さらに、トランスポート層のＴＣＰ制御では、エンドノードとネットワークノード間にコネクションを確立し、パケットを受信したことを示すＡＣＫを送信することで、転送到達性の確認を行う。
【００１１】
（２）パケット転送障害検出制御について。
ＯＳＩネットワークは、呼の状態が監視されており、呼状態に応じて、パケットを転送するか否かの判断を行うことができる。例えば、呼が設定状態ならば、パケットの転送を可とし、呼が切断状態ならば、パケットの転送を不可とする。
【００１２】
一方、ＩＰネットワークは、転送パケットの宛先（デスティネーションアドレス）とルーティングテーブル上のネクストホップとを各ノード上で照合判定して転送していくHOP by HOPが行われる。
【００１３】
また、障害発生時には、障害検出プロトコルとして、経路に位置するルータが送信元に対して障害を知らせるためのＩＣＭＰ（Internet Control Message Protocol）が用いられる。
【００１４】
HOP by HOPのパケット転送時に、経路上のノードで“宛先到達不能”と判定が下された場合、判定したノードは、ＩＣＭＰ宛先到達不能メッセージ（ICMP Unreachable）を生成し、判定対象となったパケットの転送元ノード（ソースアドレス）へ送信する。これにより、ICMP Unreachableを受信した転送元ノードが、パケット転送障害が発生したことを検出することができる。
【００１５】
従来のＱｏＳ保障に関する技術として、カプセル化したＩＰパケットを、プロトコル制御プログラムをスルーして、アプリケーションプログラムに透過的に転送することで、プラットフォームに依存しないプロトコル処理を行う技術が提案されている（特許文献１参照）。
【００１６】
また、パケット内の格納データ種別に応じた優先度を設定して、ネットワークへ送出することで、重要な情報を含むパケットの優先的な処理を行う技術が提案されている（特許文献２参照）。
【特許文献１】特開２００４−１５９０２１号公報（段落番号〔００１９〕、第１図）
【特許文献２】特開２００２−１４１９４５号公報（段落番号〔００１１〕、〔００１２〕、第１図）
【発明の開示】
【発明が解決しようとする課題】
【００１７】
ネットワーク管理ドメインを意識して、上記の転送ＱｏＳ制御について考える。ネットワーク管理ドメインをサービスプロバイダとユーザとに分離した場合、ＯＳＩネットワークで実行される、上述した優先転送制御、転送帯域制御および転送到達性確認制御については、サービスプロバイダの介在を無くしては制御することはできない。
【００１８】
また、ＩＰネットワークについても、Diffservベースの優先転送制御およびＲＳＶＰの帯域制御に関しては、サービスプロバイダの介在を要するが、ＴＣＰ制御による転送到達性確認については、プロバイダの介在は全く必要としない。
【００１９】
その結果、サービスプロバイダは、ＯＳＩネットワークにおいては転送到達性をユーザにコミットすることが可能であるが、ＩＰネットワークにおいてはコミットすることができないことになる。
【００２０】
すなわち、Ｘ．２５など従来のネットワーク技術では、呼制御やコネクションの状態をネットワーク側で把握していたため、ユーザ通信（ユーザデータの到達性）を通信キャリア／サービスプロバイダが保障できていた。しかし、ＩＰネットワーク上では、プロバイダは、Ｘ．２５などのネットワーク技術で保障できていたユーザデータの到達性を保障できないといった問題があった。
【００２１】
次にネットワーク管理ドメインを意識して、上記のパケット転送障害検出制御について考える。ネットワーク管理ドメインをサービスプロバイダとユーザとに分離した場合、ＯＳＩネットワークでは、呼の状態をプロバイダとユーザとで情報を共有している。
【００２２】
このため、呼が切断しているか否かを、ユーザとプロバイダとは同時に検出することができ、また、パケットを転送するか否かの判断についても、ユーザとプロバイダとは同時に認識することができる（すなわち、ＯＳＩネットワークでは、プロバイダおよびユーザともに、パケット転送可否判断が可能）。
【００２３】
一方、ＩＰネットワークでは、上述したように、パケットが転送されていく経路上のネットワークノードにて、“宛先到達不能”と判定が下されると、エンドノードへICMP Unreachableが送信され、エンドノードがICMP Unreachableを受信する、といった流れで、ユーザとプロバイダとが共に障害を検出する。
【００２４】
ＩＰネットワークの場合は、各ノードのルーティングテーブルは動的に変更されることが想定されており、「次のユーザパケット転送時には宛先到達不能ではなくなる（＝新たなネクストホップが見つかる）」ことを想定した制御であるため、経路上のノードが転送したパケットが“宛先到達不能”だからといって、継続的にＩＰネットワークがパケット転送障害になる（常にパケット転送が不可となる）というわけではない。
【００２５】
このように、ＩＰネットワークでは、転送パケットに対する「宛先到達不能」は判明するのだが、宛先到達不能後に次のパケットを転送する場合や、しばらく転送すべきパケットが存在しなかった後にパケットを転送する場合などでは、パケット転送が可能であるか否かの判断がされることがないため、パケット転送可否判断ができないといった問題があった。
【００２６】
本発明はこのような点に鑑みてなされたものであり、ＩＰネットワーク上におて、パケット転送の到達性確認およびパケット転送の可否判断を可能にして、ネットワーク品質およびサービス性の向上を図った通信システムを提供することを目的とする。
【課題を解決するための手段】
【００２７】
上記課題を解決するために、ネットワーク上で通信を行う通信システムが提供される。この通信システムは、送信元ユーザ端末と、宛先ユーザ端末と、前記送信元ユーザ端末から転送されたパケットの転送制御を行う入口転送制御部を含み、プロバイダドメインの入口エッジに配置される入口エッジノードと、前記入口エッジノードから転送された前記パケットの転送制御を行う出口転送制御部を含み、前記プロバイダドメインの出口エッジに配置される出口エッジノードとを備える。
【００２８】
ここで、入口転送制御部と出口転送制御部との間で、プロバイダドメイン内に、重要フロー転送用コネクションを確立し、入口転送制御部は、送信元ユーザ端末から転送されたユーザフローパケットが、重要フローパケットであるか、一般フローパケットであるかを判別して、重要フローパケットには、カプセリングを行ってカプセル化重要フローパケットを生成し、カプセル化重要フローパケットを重要フロー転送用コネクションを通じて転送する。出口転送制御部は、重要フロー転送用コネクションを通じて受信したカプセル化重要フローパケットをデカプセリングし、デカプセリング後の重要フローパケットを宛先ユーザ端末へ転送する。
【発明の効果】
【００２９】
ＩＰネットワーク上のプロバイダドメイン内で、パケット転送の到達性確認を実行して、ネットワーク品質およびサービス性の向上を図る。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の実施の形態を図面を参照して説明する。図１は通信システムの原理図である。通信システム１は、ユーザドメイン１０、３０、プロバイダドメイン２０を含むＩＰネットワーク上で通信を行うシステムであり、送信元ユーザ端末１ａ、宛先ユーザ端末３ａ、入口エッジノード２−１、出口エッジノード２−２から構成される（なお、本発明が対象とするパケットは、ＩＰパケットであり非ＩＰパケットは対象としない）。
【００３１】
送信元ユーザ端末１ａは、ユーザドメイン１０内に位置する端末であり、入口エッジノード２−１と接続する。宛先ユーザ端末３ａは、ユーザドメイン３０内に位置する端末であり、出口エッジノード２−２と接続する。
【００３２】
入口エッジノード２−１は、入口転送制御部２ａを含み、プロバイダドメイン２０の入口エッジに配置される。入口転送制御部２ａは、送信元ユーザ端末１ａから転送されたパケットの転送制御を行う。
【００３３】
出口エッジノード２−２は、出口転送制御部２ｂを含み、プロバイダドメイン２０の出口エッジに配置される。出口転送制御部２ｂは、入口エッジノード２−１から転送されたパケットの転送制御を行う。
【００３４】
ここで、入口転送制御部２ａと出口転送制御部２ｂとの間で、プロバイダドメイン２０内に、論理的なコネクションである重要フロー転送用コネクションＣが確立される。
入口転送制御部２ａは、送信元ユーザ端末１ａから転送された、ユーザパケットのトラフィックフローであるユーザフローパケットを受信すると、そのユーザフローパケットが、重要フローパケットｆ１であるか、または一般フローパケットｆ２であるかを判別する。
【００３５】
重要フローパケットｆ１には、カプセリングを行って、カプセル化重要フローパケットｃｐを生成し、カプセル化重要フローパケットｃｐを重要フロー転送用コネクションＣを通じて転送する。なお、一般フローパケットｆ２の場合は、通常のＩＰルーティングによるHOP by HOP転送によって、宛先ユーザ端末３ａへ転送する。
【００３６】
出口転送制御部２ｂは、重要フロー転送用コネクションＣを通じて受信したカプセル化重要フローパケットｃｐをデカプセリングし、デカプセリング後の重要フローパケットｆ１を宛先ユーザ端末３ａへ転送する。
【００３７】
なお、重要フローパケットｆ１とは、あらかじめユーザとプロバイダ間で契約された、転送到達性を保障すべきユーザフローパケットのことであり、重要フロー定義情報（以下、単に重要フロー定義）が記載されたパケットである。
【００３８】
また、重要フローパケットｆ１は、プロバイダドメイン２０内では、カプセル化されて転送されるため、転送到達性が保障されるだけでなく、秘匿性も確保される。なお、一般フローパケットｆ２とは、重要フローパケットｆ１以外のユーザフローパケットのことである。
【００３９】
図２は重要フローパケットｆ１と一般フローパケットｆ２の転送の流れを示す概念図である。ステップＳ１〜Ｓ４は、重要フローパケットｆ１の流れを示し、ステップＳ５、Ｓ６は一般フローパケットｆ２の流れを示す。
【００４０】
〔Ｓ１〕入口エッジノード２−１内の入口転送制御部２ａには、受信したユーザフローパケットが、重要フローパケットｆ１であるか否かを検索するための重要フロー定義が、ＡＣＬ（Access Control List：特定のユーザ端末からのパケット送信を許可したり、拒否したりすることが記述された条件文のリスト）に設定される。
【００４１】
重要フロー定義としては、例えば、入口エッジノード２−１および出口エッジノード２−２のユーザ側Ｉ／Ｆ（インタフェース）のＩＰアドレス（送信元ユーザ端末１ａと接続する入口エッジノード２−１のユーザ側Ｉ／Ｆアドレスと、宛先ユーザ端末３ａと接続する出口エッジノード２−２のユーザ側Ｉ／Ｆアドレス）や、重要フローの契約関係者のｅ−ｍａｉｌアドレス（ユーザ担当者、ユーザ担当のプロバイダ営業者、プロバイダ保守者など）がある。なお、重要フロー定義についてまとめた内容を図３に示す。
【００４２】
〔Ｓ２〕入口エッジノード２−１に重要フロー定義が設定されると、入口転送制御部２ａは、入口エッジノード２−１から出口エッジノード２−２の方向へ、プロバイダドメイン２０内部のネットワークであるプロバイダネットワーク２０−１間において、重要フロー転送用コネクションＣを確立する。
【００４３】
具体的には、重要フロー定義が入口エッジノード２−１へ投入されることにより、出口エッジノード２−２のユーザ側Ｉ／ＦのＩＰアドレスを宛先とした重要フロー転送用コネクションＣが自動設定される。
【００４４】
重要フロー転送用コネクションＣが設定されると、重要フロー転送用コネクションＣのＴＣＰポート（ポート番号）が、入口エッジノード２−１の入口転送制御部２ａと出口エッジノード２−２の出口転送制御部２ｂに記憶される。
【００４５】
記憶された重要フロー転送用コネクションＴＣＰポートは、入口エッジノード２−１においては、重要フロー転送用コネクションヘッダＨに反映され、出口エッジノード２−２においては、受信パケットが重要フローパケットｆ１であるか否かの判定に用いられる。
【００４６】
〔Ｓ３〕入口転送制御部２ａは、送信元ユーザ端末１ａから転送されたユーザフローパケットを受信すると、重要フロー定義にもとづいて、重要フローパケットｆ１を抽出する。そして、重要フロー転送用コネクションヘッダＨを付加して、重要フローパケットｆ１をカプセル化し、カプセル化重要フローパケットｃｐを生成し、カプセル化重要フローパケットｃｐを重要フロー転送用コネクションＣを通じて転送する。
【００４７】
〔Ｓ４〕出口転送制御部２ｂは、重要フロー転送用コネクションＣを通じて受信したカプセル化重要フローパケットｃｐをデカプセリングし、デカプセリング後の重要フローパケットｆ１を宛先ユーザ端末３ａへ転送する。
【００４８】
〔Ｓ５〕送信元ユーザ端末１ａは、入口エッジノード２−１に、一般フローパケットｆ２を転送し、入口転送制御部２ａは、送信元ユーザ端末１ａから転送された一般フローパケットｆ２を受信すると、通常のＩＰルーティングにより、プロバイダネットワーク２０−１へ転送する。
【００４９】
〔Ｓ６〕出口転送制御部２ｂは、ＩＰルーティングにより、プロバイダネットワーク２０−１内を転送された一般フローパケットｆ２を受信すると、一般フローパケットｆ２を宛先ユーザ端末３ａへ転送する。
【００５０】
次にＩＰネットワーク上における通信システム１の具体的な構成例について説明する。図４は通信システムの全体構成を示す図である。通信システム１−１は、ユーザドメイン１０、３０、プロバイダドメイン２０を含むＩＰネットワーク上で通信を行うシステムである。
【００５１】
ユーザドメイン１０−１〜１０−３は、プロバイダドメイン２０に対して、ＵＮＩ（User Network Interface：プロバイダの通信設備とユーザの通信設備との接続点）１を介して接続する。また、ユーザドメイン３０−１、３０−２は、プロバイダドメイン２０に対して、ＵＮＩ２を介して接続する。
【００５２】
プロバイダドメイン２０には、ルーティング機能を有する、エッジノード２１−１、２１−２、２２−１、２２−２およびコアノードＲ１〜Ｒ５が含まれる。エッジノード２１−１、２１−２は、ＵＮＩ１側のエッジに位置し、エッジノード２２−１、２２−２は、ＵＮＩ２側のエッジに位置する。
【００５３】
ユーザドメイン１０−１〜１０−３の内部それぞれは、バス形態のネットワークで構成されており、ユーザドメイン１０−１には、基幹業務系システムセンタ１１が配置し、ユーザドメイン１０−２には、ユーザ端末１２が配置し、ユーザドメイン１０−３には、ユーザ端末１３が配置している。そして、基幹業務系システムセンタ１１は、エッジノード２１−１に接続し、ユーザ端末１２、１３は、エッジノード２１−２に接続する。
【００５４】
ユーザドメイン３０−１、３０−２の内部それぞれは、バス形態のネットワークで構成されており、ユーザドメイン３０−１には、基幹業務系システムセンタ３１とユーザ端末３２が配置し、ユーザドメイン３０−２には、ユーザ端末３３、３４およびルータ３５が配置して、ユーザ端末３３、３４は、ルータ３５と接続している。そして、基幹業務系システムセンタ３１とユーザ端末３２は、エッジノード２２−１に接続し、ルータ３５は、エッジノード２２−２に接続する。
【００５５】
エッジノード２１−１は、図１で示した入口転送制御部２ａおよび出口転送制御部２ｂの両方の機能を持つ転送制御部２１ａを有する。エッジノード２２−１は、図１で示した入口転送制御部２ａおよび出口転送制御部２ｂの両方の機能を持つ転送制御部２２ａを有する。なお、エッジノード２１−２、２２−２も同様の転送制御部を有するが、図示は省略している。
【００５６】
ここで、エッジノード２１−１の転送制御部２１ａに重要フロー定義がＡＣＬに設定されると、エッジノード２１−１からエッジノード２２−１の方向に、重要フロー転送用コネクションＣ１が自動的に確立する。
【００５７】
重要フロー転送用コネクションＣ１は、エッジノード２１−１からエッジノード２２−１へ重要フローパケットｆ１を転送するＴＣＰコネクションであり、プロバイダドメイン２０内で通過するノードは、エッジノード２１−１、コアノードＲ１、Ｒ２、エッジノード２２−１の順となっている。
【００５８】
また、エッジノード２２−１の転送制御部２２ａに重要フロー定義がＡＣＬに設定されると、エッジノード２２−１からエッジノード２１−１の方向に、重要フロー転送用コネクションＣ２が自動的に確立する。
【００５９】
重要フロー転送用コネクションＣ２は、エッジノード２２−１からエッジノード２１−１へ重要フローパケットｆ１を転送するＴＣＰコネクションであり、プロバイダドメイン２０内で通過するノードは、エッジノード２２−１、コアノードＲ３、Ｒ４、エッジノード２１−１の順となっている。
【００６０】
このように、重要フロー転送用コネクションは、片方向ずつ設定して、プロバイダドメイン２０を通過するユーザフローパケットの転送到達性の保障サービスを実現する。ただし、対象とするユーザフローパケットは、ユーザとプロバイダとの間で契約した重要フローパケットｆ１に限定する。
【００６１】
（１）基幹業務系システムセンタ１１からユーザ端末３２へ重要フローパケットを転送する場合について。
基幹業務系システムセンタ１１は、ユーザフローパケットｆ０をエッジノード２１−１へ転送する。エッジノード２１−１内の転送制御部２１ａは、あらかじめ設定された重要フロー定義によって、受信したユーザフローパケットｆ０の中から、重要フローパケットｆ１と一般フローパケットｆ２とに振り分ける。
【００６２】
一般フローパケットｆ２は、通常のＩＰルーティングで転送されるが、重要フローパケットｆ１は、転送制御部２１ａにて重要フロー転送用コネクションヘッダでカプセリングされ、重要フロー転送用コネクションＣ１上を転送される。
【００６３】
エッジノード２２−１内の転送制御部２２ａは、パケットを受信すると、あらかじめ記憶された重要フロー転送用コネクションＴＣＰポートによって、受信パケットが重要フローパケットであるか否かを判別する。カプセリングされた重要フローパケットであれば、重要フロー転送用コネクションヘッダをデカプセリングし、デカプセリング後の重要フローパケットｆ１をユーザ端末３２へ転送する。
【００６４】
（２）基幹業務系システムセンタ３１から基幹業務系システムセンタ１１へユーザフローを転送する場合について。
基幹業務系システムセンタ３１は、ユーザフローパケットｆ０をエッジノード２２−１へ転送する。エッジノード２２−１内の転送制御部２２ａは、あらかじめ設定された重要フロー定義によって、受信したユーザフローパケットｆ０の中から、重要フローパケットｆ１と一般フローパケットｆ２とに振り分ける。
【００６５】
一般フローパケットｆ２は、通常のＩＰルーティングで転送されるが、重要フローパケットｆ１は、転送制御部２２ａにて重要フロー転送用コネクションヘッダでカプセリングされ、重要フロー転送用コネクションＣ２上を転送される。
【００６６】
エッジノード２１−１内の転送制御部２１ａは、パケットを受信すると、あらかじめ記憶された重要フロー転送用コネクションＴＣＰポートによって、受信パケットが重要フローパケットであるか否かを判別する。カプセリングされた重要フローパケットであれば、重要フロー転送用コネクションヘッダをデカプセリングし、デカプセリング後の重要フローパケットｆ１を基幹業務系システムセンタ１１へ転送する。
【００６７】
なお、片方向ずつ重要フロー転送用コネクションを確立するので、フロー振り分けに用いる重要フロー定義は、プロバイダドメイン２０の入口側のエッジノードにのみ設定すればよい。図４に示す例では、双方向で重要フロー転送用コネクションＣ１、Ｃ２を確立して通信を行うので、エッジノード２１−１、２２−１に対して、互いに独立に重要フロー定義を設定することになる。
【００６８】
次に重要フロー転送用コネクションＣの自動設定について説明する。図５は重要フロー転送用コネクションＣが自動設定されるまでのシーケンスを示す図である。
〔Ｓ１１〕プロバイダ保守者等によって、入口エッジノード２−１の入口転送制御部２ａに対して、ＡＣＬエントリとして、重要フロー定義が設定される。
【００６９】
〔Ｓ１２〕入口転送制御部２ａは、重要フロー定義が設定されると、確認要求（ＳＹＮ）を出口エッジノード２−２の出口転送制御部２ｂに転送する。
〔Ｓ１３〕出口転送制御部２ｂは、ＳＹＮおよび確認応答（ＡＣＫ）を入口転送制御部２ａへ転送する。
【００７０】
〔Ｓ１４〕入口転送制御部２ａは、ＳＹＮを出口エッジノード２−２の出口転送制御部２ｂに転送する。
〔Ｓ１５〕入口転送制御部２ａおよび出口転送制御部２ｂは、重要フロー転送用コネクションＣのＴＣＰポートを記憶する。このような流れにより、重要フロー定義に記載されている、入口エッジノード２−１のユーザ側Ｉ／Ｆアドレスと、出口エッジノード２−２のユーザ側Ｉ／Ｆアドレスとの間に、重要フロー転送用コネクションＣが自動的に確立される。
【００７１】
次にフロー判別後のパケット処理についてフローチャートを用いて説明する。上述の図４では、プロバイダドメイン２０内のノードに対して、エッジノード（プロバイダのネットワークエッジに配置され、転送制御部を含み、ユーザ側Ｉ／Ｆの機能を持つノード）と、コアノード（プロバイダのネットワーク内部に配置され、フォワーディング機能を持つノード）とに区別して説明したが、実際は、エッジノードとコアノードの機能は、１つのノードに含めることが可能である。このようなノードをプロバイダノードとし、プロバイダノードにおけるフロー転送の流れについて図６に示す。
【００７２】
図６はフロー判別後のパケット処理のフローチャートを示す図である。
〔Ｓ２１〕プロバイダノードは、パケットを受信する。
〔Ｓ２２〕プロバイダノードは、受信パケットが自宛か否かを判断する。自宛でない場合はステップＳ２３へいき、自宛の場合はステップＳ２７へいく。
【００７３】
〔Ｓ２３〕プロバイダノードで受信されたパケットが自宛でないということは、その受信パケットは、ユーザトラフィック（ユーザが送出したパケット）ということである。プロバイダノードは、ＡＣＬエントリ（重要フロー定義）を検索し、検索の結果、受信パケットが重要フローパケットｆ１か否かを判断する。重要フローパケットｆ１でなければ、ステップＳ２４へ、重要フローパケットｆ１ならばステップＳ２５へいく。
【００７４】
〔Ｓ２４〕プロバイダノードは、受信パケットを一般フローパケットｆ２として転送する（一般フローパケットｆ２は、ＩＰルーティングによるHOP by HOPによって転送される）。
【００７５】
〔Ｓ２５〕プロバイダノードは、受信パケットに重要フロー転送用コネクションヘッダＨを付与してカプセリングし、カプセル化重要フローパケットｃｐを生成する。
〔Ｓ２６〕プロバイダノードは、カプセル化重要フローパケットｃｐを重要フロー転送用コネクションＣを通じて送信する。
【００７６】
〔Ｓ２７〕プロバイダノードは、受信パケットのヘッダを検索して、現在確立している重要フロー転送用コネクションＣ用のＴＣＰポートのポート番号が記載されているか否かを検索する。重要フロー転送用コネクションＣ用のＴＣＰポートのポート番号が記載されていなければステップＳ２８へいき、記載されていればステップＳ２９へいく。
【００７７】
〔Ｓ２８〕受信パケットは、制御トラフィック（制御パケット）であるので、プロバイダノードは、制御パケット用の通常の処理を行う。
〔Ｓ２９〕プロバイダノードは、重要フロー転送用コネクションヘッダＨを削除してデカプセリングし、デカプセリング後の重要フローパケットｆ１をユーザサイトへ転送する。
【００７８】
次にＡＣＬエントリを用いて重要フローパケットであることの検索を行う場合について具体例を挙げて説明する。図７は重要フローパケットの検索処理を説明するための図である。
【００７９】
重要フローである条件（重要フロー定義項目）を例えば、Destination IP Addressが送信元ユーザ端末１ａのＩＰアドレス（192.168.10.10）であり、かつType of Serviceフィールド（８ビット）の低遅延（low delay）ビットと高信頼性（reliability）ビットが立っていることとする（低遅延ビットはType of Serviceの４ビット目、高信頼性ビットはType of Serviceの６ビット目である）。入口転送制御部２ａは、この重要フロー定義が記載されたＡＣＬエントリを保持する。
【００８０】
入口転送制御部２ａは、送信元ユーザ端末１ａから送信されたユーザパケットの受信時、パケットヘッダを読み取り、ＡＣＬエントリによって検索する。パケットヘッダのDestination IP Addressが11000000 10101000 00001010 00001010（＝192.168.10.10）であり、Type of Serviceが00010100であれば、受信したユーザパケットは重要フローパケットｆ１であることを認識して、重要フローパケットｆ１のための転送処理を行う。
【００８１】
次に重要フロー転送用コネクションヘッダＨについて説明する。図８は重要フロー転送用コネクションヘッダＨを示す図ある。重要フロー転送用コネクションヘッダＨは、ＩＰヘッダ部ｈ１、ＴＣＰヘッダ部ｈ２および拡張部ｈ３から構成され、カプセリング時に、重要フローパケットｆ１であるユーザパケットに対して付加される。図８に示すように、重要フロー転送用コネクションヘッダＨは、汎用的なＩＰヘッダやＴＣＰヘッダを流用したものである。
【００８２】
ＩＰヘッダ部ｈ１のSource IP Addressのフィールドには、重要フロー定義の定義項目である、入口エッジノード２−１のユーザ側Ｉ／Ｆアドレスが記載される。また、Destination IP Addressのフィールドには、重要フロー定義の定義項目である、出口エッジノード２−２のユーザ側Ｉ／Ｆアドレスが記載される。
【００８３】
ＴＣＰヘッダ部ｈ２のSource Portのフィールドには、重要フロー転送用コネクションＣのソースＴＣＰポートの番号が記載され、Destination Portのフィールドには、重要フロー転送用コネクションＣのデスティネーションＴＣＰポートの番号が記載される。
【００８４】
なお、拡張部ｈ３には、Service-Flow-Import Timeというデータが記載されているが、これは、入口エッジノード２−１がユーザパケットを受信したときの受信時刻を記載するものである。
【００８５】
次に転送到達性確認処理および転送障害検出処理について説明する。図９はユーザパケット通信時の転送到達性確認処理および転送障害検出処理を示すシーケンス図である。
〔Ｓ３１〕入口エッジノード２−１と出口エッジノード２−２との間に重要フロー転送用コネクションＣが確立する。
【００８６】
〔Ｓ３２〕入口転送制御部２ａは、重要フローパケットｐ１、ｐ２を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
〔Ｓ３３〕出口転送制御部２ｂは、重要フローパケットｐ１を受信したことを示すＡＣＫ１と、重要フローパケットｐ２を受信したことを示すＡＣＫ２とを入口エッジノード２−１へ送信する。入口転送制御部２ａは、内部にＡＣＫ待ちタイマを有しており、規定時間内にＡＣＫ１、２を受信することで、重要フローパケットｐ１、ｐ２が正常に転送されたことを確認する。
【００８７】
〔Ｓ３４〕入口転送制御部２ａは、重要フローパケットｐ３、ｐ４を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
〔Ｓ３５〕出口転送制御部２ｂは、重要フローパケットｐ３を受信したことを示すＡＣＫ３と、重要フローパケットｐ４を受信したことを示すＡＣＫ４とを入口エッジノード２−１へ送信する。入口転送制御部２ａは、規定時間内にＡＣＫ３、４を受信することで、重要フローパケットｐ３、ｐ４が正常に転送されたことを確認する。
【００８８】
〔Ｓ３６ａ〕入口転送制御部２ａは、重要フローパケットｐ５を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
〔Ｓ３６ｂ〕入口転送制御部２ａは、規定時間に達しても、ＡＣＫを受信できないので、再度、重要フローパケットｐ５を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
【００８９】
〔Ｓ３７〕入口転送制御部２ａは、重要フローパケットｐ５の確認応答であるＡＣＫを受信できずタイムアウトとなり、転送障害が発生したことを認識する。
〔Ｓ３８〕入口転送制御部２ａは、転送障害検出回数をインクリメントして、統計情報である転送障害ログ情報を障害検出時刻とともに保存する。
【００９０】
〔Ｓ３９〕入口転送制御部２ａは、重要フロー契約した重要フローパケットの転送到達性確認が取れない場合（転送障害を検出した場合）、重要フロー定義を参照して、契約関係者にｅ−ｍａｉｌで通知する。転送障害検出の情報が関係者に通知されることにより、ユーザは、パケット転送の可否判断を行うことが可能になる。
【００９１】
ここで、転送障害ログ情報は、ＳＬＡ（Service Level Agreement：ユーザとプロバイダとの間で、サービスの内容、範囲、品質に対する要求水準を明確にして、それが達成できなかった場合のルールを含めて、あらかじめ合意した契約）にもとづく指標データとして、ＩＰネットワークを管理するためのネットワーク管理システム（ＮＭＳ：Network Management System）から定期的に収集される。
【００９２】
ＳＬＡとしては、上記のステップＳ３９のように、「転送到達性確認が取れない場合は、関係者にメールで通知する」といった他にも、例えば、「平日の時刻７：００−２２：００における年間の転送障害検出回数を１２回以下とする」、「平日の時刻７：００−２２：００における年間の平均網内遅延時間を１秒以下とする」などがある。転送障害ログ情報は、定期的に保守者に収集され、かつユーザに対してもＳＬＡの証明データとして開示されて、ＳＬＡが満たされているかの状態確認が行われる。
【００９３】
図１０はユーザパケット無通信時の転送到達性確認処理および転送障害検出処理を示すシーケンス図である。重要フローパケットｆ１が通信されていない時間帯においても、転送到達性確認処理および転送障害検出処理を継続的に実施するために、入口エッジノード２−１からからダミーパケット（例えば、keep aliveパケット）を生成して送信する。
【００９４】
〔Ｓ４１〕入口エッジノード２−１と出口エッジノード２−２との間に重要フロー転送用コネクションＣが確立する。
〔Ｓ４２〕入口エッジノード２−１の入口転送制御部２ａは、keep aliveパケットｐ１１を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
【００９５】
〔Ｓ４３〕出口エッジノード２−２の出口転送制御部２ｂは、keep aliveパケットｐ１１を受信したことを示すＡＣＫ１１を入口エッジノード２−１へ送信する。入口転送制御部２ａは、内部にＡＣＫ待ちタイマを有しており、規定時間内にＡＣＫ１１を受信することで、keep aliveパケットｐ１１が正常に転送されたことを確認する。
【００９６】
〔Ｓ４４ａ〕入口転送制御部２ａは、keep aliveパケットｐ１２を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
〔Ｓ４４ｂ〕入口転送制御部２ａは、規定時間に達しても、ＡＣＫを受信できないので、再度、keep aliveパケットｐ１２を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
【００９７】
〔Ｓ４５〕入口転送制御部２ａは、keep aliveパケットｐ１２の確認応答であるＡＣＫを受信できずタイムアウトとなり、転送障害が発生したことを認識する。
〔Ｓ４６〕入口転送制御部２ａは、転送障害検出回数をインクリメントして、転送障害ログ情報を障害検出時刻とともに保存する。
【００９８】
〔Ｓ４７〕入口転送制御部２ａは、重要フロー契約したユーザパケットの転送到達性確認が取れない場合（転送障害を検出した場合）、重要フロー定義を参照して、契約関係者にｅ−ｍａｉｌで通知する。
【００９９】
次にパケット転送時間の計測処理について説明する。図１１はパケット転送時間の計測処理を示すシーケンス図である。
〔Ｓ５１〕入口エッジノード２−１と出口エッジノード２−２との間に重要フロー転送用コネクションＣが確立する。
【０１００】
〔Ｓ５２〕入口転送制御部２ａは、送信元ユーザ端末１ａから送信された重要フローパケットの受信時刻Ｔｓ１を計測する。
〔Ｓ５３〕入口転送制御部２ａは、受信時刻Ｔｓ１をヘッダに付与して、重要フローパケットｐ２１を出口エッジノード２−２へ転送する。
【０１０１】
〔Ｓ５４ａ〕出口転送制御部２ｂは、重要フローパケットｐ２１を受信すると、受信時刻Ｔｒ１を計測する。
〔Ｓ５４ｂ〕出口転送制御部２ｂは、転送時間Ｔ１（＝Ｔｒ１−Ｔｓ１）を算出して保存する。
【０１０２】
〔Ｓ５５〕入口転送制御部２ａは、送信元ユーザ端末１ａから送信された重要フローパケットの受信時刻Ｔｓ２を計測する。
〔Ｓ５６〕入口転送制御部２ａは、受信時刻Ｔｓ２をヘッダに付与して、重要フローパケットｐ２２を出口エッジノード２−２へ転送する。
【０１０３】
〔Ｓ５７ａ〕出口転送制御部２ｂは、重要フローパケットｐ２２を受信すると、受信時刻Ｔｒ２を計測する。
〔Ｓ５７ｂ〕出口転送制御部２ｂは、転送時間Ｔ２（＝Ｔｒ２−Ｔｓ２）を算出して保存する。
【０１０４】
〔Ｓ５８〕出口転送制御部２ｂは、転送時間Ｔ１、Ｔ２、・・・Ｔｎに対して、単位時間当たりの平均値を算出して、その平均値である平均網内遅延時間を統計情報として記憶する。平均網内遅延時間は、ＳＬＡにもとづく指標データとして、ＩＰネットワークを管理するためのＮＭＳから定期的に収集される。
【０１０５】
例えば、ＳＬＡにおいて、「平日の時刻７：００−２２：００における年間の平均網内遅延時間を１秒以下とする」とした項目があれば、平均網内遅延時間は定期的に保守者に収集され、かつユーザに対してもＳＬＡの証明データとして開示されて、ＳＬＡが満たされているかの状態確認が行われる。
【０１０６】
以上説明したように、通信システム１では、プロバイダドメイン２０内の転送到達性確認処理を実行するので、ＯＳＩネットワークと同様にＩＰネットワークにおいても、サービスプロバイダとしてユーザフローの転送到達性をユーザにコミットすることが可能になる。
【０１０７】
また、ＯＳＩネットワークと同様にＩＰネットワークにおいても、サービスプロバイダとしてユーザフローの転送障害を検出でき、その結果、ユーザへの転送障害や転送不可状態の通知、ユーザとのサービスレベル契約（ＳＬＡ）にもとづく指標データ（転送障害ログ情報）の採取が可能となる。
【０１０８】
さらに、サービスプロバイダとしてユーザフローの網内伝送時間を計測でき、その結果、ユーザとのサービスレベル契約（ＳＬＡ）に基づく指標データ（平均網内遅延時間）の採取が可能となる。
【０１０９】
また、ユーザとのサービス契約で対象ユーザフローを決定（重要フロー契約）することにより、サービスプロバイダとしてサービスメニューの多様化が図れる。
さらにまた、ＮＧＮ（Next Generation Network）のU-Planeの基盤になっているＭＰＬＳ（Multi Protocol Label Switching）ネットワークの場合、設備更新時には、コアルータを含むすべてのプロバイダドメイン２０内の設備更新が必要であるが、通信システム１の機能を適用することにより、プロバイダドメイン２０内の設備の更新は、重要フロー契約ユーザを収容するエッジルータだけで済むことができ、スモールスタート（サービス開発の際、最初から大規模・多機能化をせずに、シンプルな設備でスタートさせる）が可能になる。
【図面の簡単な説明】
【０１１０】
【図１】通信システムの原理図である。
【図２】重要フローパケットと一般フローパケットの転送の流れを示す概念図である。
【図３】重要フロー定義の内容を示す図である。
【図４】通信システムの全体構成を示す図である。
【図５】重要フロー転送用コネクションが自動設定されるまでのシーケンスを示す図である。
【図６】フロー判別後のパケット処理のフローチャートを示す図である。
【図７】重要フローパケットの検索処理を説明するための図である。
【図８】重要フロー転送用コネクションヘッダを示す図ある。
【図９】ユーザパケット通信時の転送到達性確認処理および転送障害検出処理を示すシーケンス図である。
【図１０】ユーザパケット無通信時の転送到達性確認処理および転送障害検出処理を示すシーケンス図である。
【図１１】パケット転送時間の計測処理を示すシーケンス図である。
【符号の説明】
【０１１１】
１ 通信システム
１０、３０ ユーザドメイン
２０ プロバイダドメイン
１ａ 送信元ユーザ端末
３ａ 宛先ユーザ端末
２−１ 入口エッジノード
２ａ 入口転送制御部
２−２ 出口エッジノード
２ｂ 出口転送制御部
Ｃ 重要フロー転送用コネクション
ｃｐ カプセル化重要フローパケット
ｆ１ 重要フローパケット
ｆ２ 一般フローパケット
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol）ネットワーク上で通信を行う通信システムに関する。
【背景技術】
【０００２】
通信ネットワークでは、特定の通信のための帯域を予約し、一定の通信速度や品質を保障する技術であるＱｏＳ（Quality of Service）が行われており、ユーザに対して満足度の高い通信サービスを提供するために、ＱｏＳ保障のニーズが高まっている。ＱｏＳの主な制御としては、転送ＱｏＳ制御およびパケット転送障害検出制御がある。
【０００３】
（１）転送ＱｏＳ制御について。
Ｘ．２５（コネクション型のデータ通信を行うパケット交換用のプロトコル体系）によるＯＳＩ（Open Systems Interconnection）ネットワークでは、エンドノード（Ｘ．２５端末）と、ネットワークノード（Ｘ．２５交換機）とに、Ｘ．２５シグナリングによる呼制御機能が実装されて、転送ＱｏＳ制御が行われている。
【０００４】
転送ＱｏＳ制御の具体的な内容としては、特定の呼を優先して転送する優先転送制御、呼毎に転送帯域を制御する転送帯域制御、特定の呼が相手先に到達したか否かを確認する転送到達性確認制御があり、これら３つの制御がＯＳＩネットワーク上で実現される。
【０００５】
一方、現在の一般的なＩＰネットワークで行われる転送ＱｏＳ制御では、上記の優先転送制御は、Diffserv（Differentiated Services）制御に置き換わり、転送帯域制御は、ＲＳＶＰ（Resource reSerVation Protocol）シグナリングによるIntserv（Integrated Services）制御に置き換わり、転送到達性確認制御は、トランスポート層によるＴＣＰ（Transmission Control Protocol）制御に置き換わっている。
【０００６】
ここで、Diffservは、複数の通信フローをまとめてクラスを作り、クラス毎にＱｏＳを保障するもので、複数のクラス間で相対的な転送性能差をつけることによって、トラフィックの優先転送制御を行うものである。
【０００７】
具体的には、エンドノード（ＩＰ端末）では、フローの種類によるクラス分けを行い、ＩＰｖ４の場合、ＩＰパケットの８ビットのＴＯＳ（Type of Service）フィールドの６ビットを使って、クラス分け情報であるＤＳＣＰ（DiffServ Code Point）を書きこむ（これをマーキングという）。
【０００８】
そして、ネットワークノード（ＩＰルータ）では、ＤＳＣＰ値を参照し、ＤＳＣＰ値により定義されるＰＨＢ（Per-Hop Behavior：Diffserv対応ノードの動作に関する規則を記述したもの）に応じてクラス分けを行ってパケット転送を行う。
【０００９】
また、Intservは、通信フロー毎にＱｏＳを保障するものであり、エンドノードとネットワークノードとの間で、ネットワークの帯域を予約するシグナリング・プロトコルであるＲＳＶＰを使用して、転送帯域を確保する。
【００１０】
さらに、トランスポート層のＴＣＰ制御では、エンドノードとネットワークノード間にコネクションを確立し、パケットを受信したことを示すＡＣＫを送信することで、転送到達性の確認を行う。
【００１１】
（２）パケット転送障害検出制御について。
ＯＳＩネットワークは、呼の状態が監視されており、呼状態に応じて、パケットを転送するか否かの判断を行うことができる。例えば、呼が設定状態ならば、パケットの転送を可とし、呼が切断状態ならば、パケットの転送を不可とする。
【００１２】
一方、ＩＰネットワークは、転送パケットの宛先（デスティネーションアドレス）とルーティングテーブル上のネクストホップとを各ノード上で照合判定して転送していくHOP by HOPが行われる。
【００１３】
また、障害発生時には、障害検出プロトコルとして、経路に位置するルータが送信元に対して障害を知らせるためのＩＣＭＰ（Internet Control Message Protocol）が用いられる。
【００１４】
HOP by HOPのパケット転送時に、経路上のノードで“宛先到達不能”と判定が下された場合、判定したノードは、ＩＣＭＰ宛先到達不能メッセージ（ICMP Unreachable）を生成し、判定対象となったパケットの転送元ノード（ソースアドレス）へ送信する。これにより、ICMP Unreachableを受信した転送元ノードが、パケット転送障害が発生したことを検出することができる。
【００１５】
従来のＱｏＳ保障に関する技術として、カプセル化したＩＰパケットを、プロトコル制御プログラムをスルーして、アプリケーションプログラムに透過的に転送することで、プラットフォームに依存しないプロトコル処理を行う技術が提案されている（特許文献１参照）。
【００１６】
また、パケット内の格納データ種別に応じた優先度を設定して、ネットワークへ送出することで、重要な情報を含むパケットの優先的な処理を行う技術が提案されている（特許文献２参照）。
【特許文献１】特開２００４−１５９０２１号公報（段落番号〔００１９〕、第１図）
【特許文献２】特開２００２−１４１９４５号公報（段落番号〔００１１〕、〔００１２〕、第１図）
【発明の開示】
【発明が解決しようとする課題】
【００１７】
ネットワーク管理ドメインを意識して、上記の転送ＱｏＳ制御について考える。ネットワーク管理ドメインをサービスプロバイダとユーザとに分離した場合、ＯＳＩネットワークで実行される、上述した優先転送制御、転送帯域制御および転送到達性確認制御については、サービスプロバイダの介在を無くしては制御することはできない。
【００１８】
また、ＩＰネットワークについても、Diffservベースの優先転送制御およびＲＳＶＰの帯域制御に関しては、サービスプロバイダの介在を要するが、ＴＣＰ制御による転送到達性確認については、プロバイダの介在は全く必要としない。
【００１９】
その結果、サービスプロバイダは、ＯＳＩネットワークにおいては転送到達性をユーザにコミットすることが可能であるが、ＩＰネットワークにおいてはコミットすることができないことになる。
【００２０】
すなわち、Ｘ．２５など従来のネットワーク技術では、呼制御やコネクションの状態をネットワーク側で把握していたため、ユーザ通信（ユーザデータの到達性）を通信キャリア／サービスプロバイダが保障できていた。しかし、ＩＰネットワーク上では、プロバイダは、Ｘ．２５などのネットワーク技術で保障できていたユーザデータの到達性を保障できないといった問題があった。
【００２１】
次にネットワーク管理ドメインを意識して、上記のパケット転送障害検出制御について考える。ネットワーク管理ドメインをサービスプロバイダとユーザとに分離した場合、ＯＳＩネットワークでは、呼の状態をプロバイダとユーザとで情報を共有している。
【００２２】
このため、呼が切断しているか否かを、ユーザとプロバイダとは同時に検出することができ、また、パケットを転送するか否かの判断についても、ユーザとプロバイダとは同時に認識することができる（すなわち、ＯＳＩネットワークでは、プロバイダおよびユーザともに、パケット転送可否判断が可能）。
【００２３】
一方、ＩＰネットワークでは、上述したように、パケットが転送されていく経路上のネットワークノードにて、“宛先到達不能”と判定が下されると、エンドノードへICMP Unreachableが送信され、エンドノードがICMP Unreachableを受信する、といった流れで、ユーザとプロバイダとが共に障害を検出する。
【００２４】
ＩＰネットワークの場合は、各ノードのルーティングテーブルは動的に変更されることが想定されており、「次のユーザパケット転送時には宛先到達不能ではなくなる（＝新たなネクストホップが見つかる）」ことを想定した制御であるため、経路上のノードが転送したパケットが“宛先到達不能”だからといって、継続的にＩＰネットワークがパケット転送障害になる（常にパケット転送が不可となる）というわけではない。
【００２５】
このように、ＩＰネットワークでは、転送パケットに対する「宛先到達不能」は判明するのだが、宛先到達不能後に次のパケットを転送する場合や、しばらく転送すべきパケットが存在しなかった後にパケットを転送する場合などでは、パケット転送が可能であるか否かの判断がされることがないため、パケット転送可否判断ができないといった問題があった。
【００２６】
本発明はこのような点に鑑みてなされたものであり、ＩＰネットワーク上におて、パケット転送の到達性確認およびパケット転送の可否判断を可能にして、ネットワーク品質およびサービス性の向上を図った通信システムを提供することを目的とする。
【課題を解決するための手段】
【００２７】
上記課題を解決するために、ネットワーク上で通信を行う通信システムが提供される。この通信システムは、送信元ユーザ端末と、宛先ユーザ端末と、前記送信元ユーザ端末から転送されたパケットの転送制御を行う入口転送制御部を含み、プロバイダドメインの入口エッジに配置される入口エッジノードと、前記入口エッジノードから転送された前記パケットの転送制御を行う出口転送制御部を含み、前記プロバイダドメインの出口エッジに配置される出口エッジノードとを備える。
【００２８】
ここで、入口転送制御部と出口転送制御部との間で、プロバイダドメイン内に、重要フロー転送用コネクションを確立し、入口転送制御部は、送信元ユーザ端末から転送されたユーザフローパケットが、重要フローパケットであるか、一般フローパケットであるかを判別して、重要フローパケットには、カプセリングを行ってカプセル化重要フローパケットを生成し、カプセル化重要フローパケットを重要フロー転送用コネクションを通じて転送する。出口転送制御部は、重要フロー転送用コネクションを通じて受信したカプセル化重要フローパケットをデカプセリングし、デカプセリング後の重要フローパケットを宛先ユーザ端末へ転送する。
【発明の効果】
【００２９】
ＩＰネットワーク上のプロバイダドメイン内で、パケット転送の到達性確認を実行して、ネットワーク品質およびサービス性の向上を図る。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の実施の形態を図面を参照して説明する。図１は通信システムの原理図である。通信システム１は、ユーザドメイン１０、３０、プロバイダドメイン２０を含むＩＰネットワーク上で通信を行うシステムであり、送信元ユーザ端末１ａ、宛先ユーザ端末３ａ、入口エッジノード２−１、出口エッジノード２−２から構成される（なお、本発明が対象とするパケットは、ＩＰパケットであり非ＩＰパケットは対象としない）。
【００３１】
送信元ユーザ端末１ａは、ユーザドメイン１０内に位置する端末であり、入口エッジノード２−１と接続する。宛先ユーザ端末３ａは、ユーザドメイン３０内に位置する端末であり、出口エッジノード２−２と接続する。
【００３２】
入口エッジノード２−１は、入口転送制御部２ａを含み、プロバイダドメイン２０の入口エッジに配置される。入口転送制御部２ａは、送信元ユーザ端末１ａから転送されたパケットの転送制御を行う。
【００３３】
出口エッジノード２−２は、出口転送制御部２ｂを含み、プロバイダドメイン２０の出口エッジに配置される。出口転送制御部２ｂは、入口エッジノード２−１から転送されたパケットの転送制御を行う。
【００３４】
ここで、入口転送制御部２ａと出口転送制御部２ｂとの間で、プロバイダドメイン２０内に、論理的なコネクションである重要フロー転送用コネクションＣが確立される。
入口転送制御部２ａは、送信元ユーザ端末１ａから転送された、ユーザパケットのトラフィックフローであるユーザフローパケットを受信すると、そのユーザフローパケットが、重要フローパケットｆ１であるか、または一般フローパケットｆ２であるかを判別する。
【００３５】
重要フローパケットｆ１には、カプセリングを行って、カプセル化重要フローパケットｃｐを生成し、カプセル化重要フローパケットｃｐを重要フロー転送用コネクションＣを通じて転送する。なお、一般フローパケットｆ２の場合は、通常のＩＰルーティングによるHOP by HOP転送によって、宛先ユーザ端末３ａへ転送する。
【００３６】
出口転送制御部２ｂは、重要フロー転送用コネクションＣを通じて受信したカプセル化重要フローパケットｃｐをデカプセリングし、デカプセリング後の重要フローパケットｆ１を宛先ユーザ端末３ａへ転送する。
【００３７】
なお、重要フローパケットｆ１とは、あらかじめユーザとプロバイダ間で契約された、転送到達性を保障すべきユーザフローパケットのことであり、重要フロー定義情報（以下、単に重要フロー定義）が記載されたパケットである。
【００３８】
また、重要フローパケットｆ１は、プロバイダドメイン２０内では、カプセル化されて転送されるため、転送到達性が保障されるだけでなく、秘匿性も確保される。なお、一般フローパケットｆ２とは、重要フローパケットｆ１以外のユーザフローパケットのことである。
【００３９】
図２は重要フローパケットｆ１と一般フローパケットｆ２の転送の流れを示す概念図である。ステップＳ１〜Ｓ４は、重要フローパケットｆ１の流れを示し、ステップＳ５、Ｓ６は一般フローパケットｆ２の流れを示す。
【００４０】
〔Ｓ１〕入口エッジノード２−１内の入口転送制御部２ａには、受信したユーザフローパケットが、重要フローパケットｆ１であるか否かを検索するための重要フロー定義が、ＡＣＬ（Access Control List：特定のユーザ端末からのパケット送信を許可したり、拒否したりすることが記述された条件文のリスト）に設定される。
【００４１】
重要フロー定義としては、例えば、入口エッジノード２−１および出口エッジノード２−２のユーザ側Ｉ／Ｆ（インタフェース）のＩＰアドレス（送信元ユーザ端末１ａと接続する入口エッジノード２−１のユーザ側Ｉ／Ｆアドレスと、宛先ユーザ端末３ａと接続する出口エッジノード２−２のユーザ側Ｉ／Ｆアドレス）や、重要フローの契約関係者のｅ−ｍａｉｌアドレス（ユーザ担当者、ユーザ担当のプロバイダ営業者、プロバイダ保守者など）がある。なお、重要フロー定義についてまとめた内容を図３に示す。
【００４２】
〔Ｓ２〕入口エッジノード２−１に重要フロー定義が設定されると、入口転送制御部２ａは、入口エッジノード２−１から出口エッジノード２−２の方向へ、プロバイダドメイン２０内部のネットワークであるプロバイダネットワーク２０−１間において、重要フロー転送用コネクションＣを確立する。
【００４３】
具体的には、重要フロー定義が入口エッジノード２−１へ投入されることにより、出口エッジノード２−２のユーザ側Ｉ／ＦのＩＰアドレスを宛先とした重要フロー転送用コネクションＣが自動設定される。
【００４４】
重要フロー転送用コネクションＣが設定されると、重要フロー転送用コネクションＣのＴＣＰポート（ポート番号）が、入口エッジノード２−１の入口転送制御部２ａと出口エッジノード２−２の出口転送制御部２ｂに記憶される。
【００４５】
記憶された重要フロー転送用コネクションＴＣＰポートは、入口エッジノード２−１においては、重要フロー転送用コネクションヘッダＨに反映され、出口エッジノード２−２においては、受信パケットが重要フローパケットｆ１であるか否かの判定に用いられる。
【００４６】
〔Ｓ３〕入口転送制御部２ａは、送信元ユーザ端末１ａから転送されたユーザフローパケットを受信すると、重要フロー定義にもとづいて、重要フローパケットｆ１を抽出する。そして、重要フロー転送用コネクションヘッダＨを付加して、重要フローパケットｆ１をカプセル化し、カプセル化重要フローパケットｃｐを生成し、カプセル化重要フローパケットｃｐを重要フロー転送用コネクションＣを通じて転送する。
【００４７】
〔Ｓ４〕出口転送制御部２ｂは、重要フロー転送用コネクションＣを通じて受信したカプセル化重要フローパケットｃｐをデカプセリングし、デカプセリング後の重要フローパケットｆ１を宛先ユーザ端末３ａへ転送する。
【００４８】
〔Ｓ５〕送信元ユーザ端末１ａは、入口エッジノード２−１に、一般フローパケットｆ２を転送し、入口転送制御部２ａは、送信元ユーザ端末１ａから転送された一般フローパケットｆ２を受信すると、通常のＩＰルーティングにより、プロバイダネットワーク２０−１へ転送する。
【００４９】
〔Ｓ６〕出口転送制御部２ｂは、ＩＰルーティングにより、プロバイダネットワーク２０−１内を転送された一般フローパケットｆ２を受信すると、一般フローパケットｆ２を宛先ユーザ端末３ａへ転送する。
【００５０】
次にＩＰネットワーク上における通信システム１の具体的な構成例について説明する。図４は通信システムの全体構成を示す図である。通信システム１−１は、ユーザドメイン１０、３０、プロバイダドメイン２０を含むＩＰネットワーク上で通信を行うシステムである。
【００５１】
ユーザドメイン１０−１〜１０−３は、プロバイダドメイン２０に対して、ＵＮＩ（User Network Interface：プロバイダの通信設備とユーザの通信設備との接続点）１を介して接続する。また、ユーザドメイン３０−１、３０−２は、プロバイダドメイン２０に対して、ＵＮＩ２を介して接続する。
【００５２】
プロバイダドメイン２０には、ルーティング機能を有する、エッジノード２１−１、２１−２、２２−１、２２−２およびコアノードＲ１〜Ｒ５が含まれる。エッジノード２１−１、２１−２は、ＵＮＩ１側のエッジに位置し、エッジノード２２−１、２２−２は、ＵＮＩ２側のエッジに位置する。
【００５３】
ユーザドメイン１０−１〜１０−３の内部それぞれは、バス形態のネットワークで構成されており、ユーザドメイン１０−１には、基幹業務系システムセンタ１１が配置し、ユーザドメイン１０−２には、ユーザ端末１２が配置し、ユーザドメイン１０−３には、ユーザ端末１３が配置している。そして、基幹業務系システムセンタ１１は、エッジノード２１−１に接続し、ユーザ端末１２、１３は、エッジノード２１−２に接続する。
【００５４】
ユーザドメイン３０−１、３０−２の内部それぞれは、バス形態のネットワークで構成されており、ユーザドメイン３０−１には、基幹業務系システムセンタ３１とユーザ端末３２が配置し、ユーザドメイン３０−２には、ユーザ端末３３、３４およびルータ３５が配置して、ユーザ端末３３、３４は、ルータ３５と接続している。そして、基幹業務系システムセンタ３１とユーザ端末３２は、エッジノード２２−１に接続し、ルータ３５は、エッジノード２２−２に接続する。
【００５５】
エッジノード２１−１は、図１で示した入口転送制御部２ａおよび出口転送制御部２ｂの両方の機能を持つ転送制御部２１ａを有する。エッジノード２２−１は、図１で示した入口転送制御部２ａおよび出口転送制御部２ｂの両方の機能を持つ転送制御部２２ａを有する。なお、エッジノード２１−２、２２−２も同様の転送制御部を有するが、図示は省略している。
【００５６】
ここで、エッジノード２１−１の転送制御部２１ａに重要フロー定義がＡＣＬに設定されると、エッジノード２１−１からエッジノード２２−１の方向に、重要フロー転送用コネクションＣ１が自動的に確立する。
【００５７】
重要フロー転送用コネクションＣ１は、エッジノード２１−１からエッジノード２２−１へ重要フローパケットｆ１を転送するＴＣＰコネクションであり、プロバイダドメイン２０内で通過するノードは、エッジノード２１−１、コアノードＲ１、Ｒ２、エッジノード２２−１の順となっている。
【００５８】
また、エッジノード２２−１の転送制御部２２ａに重要フロー定義がＡＣＬに設定されると、エッジノード２２−１からエッジノード２１−１の方向に、重要フロー転送用コネクションＣ２が自動的に確立する。
【００５９】
重要フロー転送用コネクションＣ２は、エッジノード２２−１からエッジノード２１−１へ重要フローパケットｆ１を転送するＴＣＰコネクションであり、プロバイダドメイン２０内で通過するノードは、エッジノード２２−１、コアノードＲ３、Ｒ４、エッジノード２１−１の順となっている。
【００６０】
このように、重要フロー転送用コネクションは、片方向ずつ設定して、プロバイダドメイン２０を通過するユーザフローパケットの転送到達性の保障サービスを実現する。ただし、対象とするユーザフローパケットは、ユーザとプロバイダとの間で契約した重要フローパケットｆ１に限定する。
【００６１】
（１）基幹業務系システムセンタ１１からユーザ端末３２へ重要フローパケットを転送する場合について。
基幹業務系システムセンタ１１は、ユーザフローパケットｆ０をエッジノード２１−１へ転送する。エッジノード２１−１内の転送制御部２１ａは、あらかじめ設定された重要フロー定義によって、受信したユーザフローパケットｆ０の中から、重要フローパケットｆ１と一般フローパケットｆ２とに振り分ける。
【００６２】
一般フローパケットｆ２は、通常のＩＰルーティングで転送されるが、重要フローパケットｆ１は、転送制御部２１ａにて重要フロー転送用コネクションヘッダでカプセリングされ、重要フロー転送用コネクションＣ１上を転送される。
【００６３】
エッジノード２２−１内の転送制御部２２ａは、パケットを受信すると、あらかじめ記憶された重要フロー転送用コネクションＴＣＰポートによって、受信パケットが重要フローパケットであるか否かを判別する。カプセリングされた重要フローパケットであれば、重要フロー転送用コネクションヘッダをデカプセリングし、デカプセリング後の重要フローパケットｆ１をユーザ端末３２へ転送する。
【００６４】
（２）基幹業務系システムセンタ３１から基幹業務系システムセンタ１１へユーザフローを転送する場合について。
基幹業務系システムセンタ３１は、ユーザフローパケットｆ０をエッジノード２２−１へ転送する。エッジノード２２−１内の転送制御部２２ａは、あらかじめ設定された重要フロー定義によって、受信したユーザフローパケットｆ０の中から、重要フローパケットｆ１と一般フローパケットｆ２とに振り分ける。
【００６５】
一般フローパケットｆ２は、通常のＩＰルーティングで転送されるが、重要フローパケットｆ１は、転送制御部２２ａにて重要フロー転送用コネクションヘッダでカプセリングされ、重要フロー転送用コネクションＣ２上を転送される。
【００６６】
エッジノード２１−１内の転送制御部２１ａは、パケットを受信すると、あらかじめ記憶された重要フロー転送用コネクションＴＣＰポートによって、受信パケットが重要フローパケットであるか否かを判別する。カプセリングされた重要フローパケットであれば、重要フロー転送用コネクションヘッダをデカプセリングし、デカプセリング後の重要フローパケットｆ１を基幹業務系システムセンタ１１へ転送する。
【００６７】
なお、片方向ずつ重要フロー転送用コネクションを確立するので、フロー振り分けに用いる重要フロー定義は、プロバイダドメイン２０の入口側のエッジノードにのみ設定すればよい。図４に示す例では、双方向で重要フロー転送用コネクションＣ１、Ｃ２を確立して通信を行うので、エッジノード２１−１、２２−１に対して、互いに独立に重要フロー定義を設定することになる。
【００６８】
次に重要フロー転送用コネクションＣの自動設定について説明する。図５は重要フロー転送用コネクションＣが自動設定されるまでのシーケンスを示す図である。
〔Ｓ１１〕プロバイダ保守者等によって、入口エッジノード２−１の入口転送制御部２ａに対して、ＡＣＬエントリとして、重要フロー定義が設定される。
【００６９】
〔Ｓ１２〕入口転送制御部２ａは、重要フロー定義が設定されると、確認要求（ＳＹＮ）を出口エッジノード２−２の出口転送制御部２ｂに転送する。
〔Ｓ１３〕出口転送制御部２ｂは、ＳＹＮおよび確認応答（ＡＣＫ）を入口転送制御部２ａへ転送する。
【００７０】
〔Ｓ１４〕入口転送制御部２ａは、ＳＹＮを出口エッジノード２−２の出口転送制御部２ｂに転送する。
〔Ｓ１５〕入口転送制御部２ａおよび出口転送制御部２ｂは、重要フロー転送用コネクションＣのＴＣＰポートを記憶する。このような流れにより、重要フロー定義に記載されている、入口エッジノード２−１のユーザ側Ｉ／Ｆアドレスと、出口エッジノード２−２のユーザ側Ｉ／Ｆアドレスとの間に、重要フロー転送用コネクションＣが自動的に確立される。
【００７１】
次にフロー判別後のパケット処理についてフローチャートを用いて説明する。上述の図４では、プロバイダドメイン２０内のノードに対して、エッジノード（プロバイダのネットワークエッジに配置され、転送制御部を含み、ユーザ側Ｉ／Ｆの機能を持つノード）と、コアノード（プロバイダのネットワーク内部に配置され、フォワーディング機能を持つノード）とに区別して説明したが、実際は、エッジノードとコアノードの機能は、１つのノードに含めることが可能である。このようなノードをプロバイダノードとし、プロバイダノードにおけるフロー転送の流れについて図６に示す。
【００７２】
図６はフロー判別後のパケット処理のフローチャートを示す図である。
〔Ｓ２１〕プロバイダノードは、パケットを受信する。
〔Ｓ２２〕プロバイダノードは、受信パケットが自宛か否かを判断する。自宛でない場合はステップＳ２３へいき、自宛の場合はステップＳ２７へいく。
【００７３】
〔Ｓ２３〕プロバイダノードで受信されたパケットが自宛でないということは、その受信パケットは、ユーザトラフィック（ユーザが送出したパケット）ということである。プロバイダノードは、ＡＣＬエントリ（重要フロー定義）を検索し、検索の結果、受信パケットが重要フローパケットｆ１か否かを判断する。重要フローパケットｆ１でなければ、ステップＳ２４へ、重要フローパケットｆ１ならばステップＳ２５へいく。
【００７４】
〔Ｓ２４〕プロバイダノードは、受信パケットを一般フローパケットｆ２として転送する（一般フローパケットｆ２は、ＩＰルーティングによるHOP by HOPによって転送される）。
【００７５】
〔Ｓ２５〕プロバイダノードは、受信パケットに重要フロー転送用コネクションヘッダＨを付与してカプセリングし、カプセル化重要フローパケットｃｐを生成する。
〔Ｓ２６〕プロバイダノードは、カプセル化重要フローパケットｃｐを重要フロー転送用コネクションＣを通じて送信する。
【００７６】
〔Ｓ２７〕プロバイダノードは、受信パケットのヘッダを検索して、現在確立している重要フロー転送用コネクションＣ用のＴＣＰポートのポート番号が記載されているか否かを検索する。重要フロー転送用コネクションＣ用のＴＣＰポートのポート番号が記載されていなければステップＳ２８へいき、記載されていればステップＳ２９へいく。
【００７７】
〔Ｓ２８〕受信パケットは、制御トラフィック（制御パケット）であるので、プロバイダノードは、制御パケット用の通常の処理を行う。
〔Ｓ２９〕プロバイダノードは、重要フロー転送用コネクションヘッダＨを削除してデカプセリングし、デカプセリング後の重要フローパケットｆ１をユーザサイトへ転送する。
【００７８】
次にＡＣＬエントリを用いて重要フローパケットであることの検索を行う場合について具体例を挙げて説明する。図７は重要フローパケットの検索処理を説明するための図である。
【００７９】
重要フローである条件（重要フロー定義項目）を例えば、Destination IP Addressが送信元ユーザ端末１ａのＩＰアドレス（192.168.10.10）であり、かつType of Serviceフィールド（８ビット）の低遅延（low delay）ビットと高信頼性（reliability）ビットが立っていることとする（低遅延ビットはType of Serviceの４ビット目、高信頼性ビットはType of Serviceの６ビット目である）。入口転送制御部２ａは、この重要フロー定義が記載されたＡＣＬエントリを保持する。
【００８０】
入口転送制御部２ａは、送信元ユーザ端末１ａから送信されたユーザパケットの受信時、パケットヘッダを読み取り、ＡＣＬエントリによって検索する。パケットヘッダのDestination IP Addressが11000000 10101000 00001010 00001010（＝192.168.10.10）であり、Type of Serviceが00010100であれば、受信したユーザパケットは重要フローパケットｆ１であることを認識して、重要フローパケットｆ１のための転送処理を行う。
【００８１】
次に重要フロー転送用コネクションヘッダＨについて説明する。図８は重要フロー転送用コネクションヘッダＨを示す図ある。重要フロー転送用コネクションヘッダＨは、ＩＰヘッダ部ｈ１、ＴＣＰヘッダ部ｈ２および拡張部ｈ３から構成され、カプセリング時に、重要フローパケットｆ１であるユーザパケットに対して付加される。図８に示すように、重要フロー転送用コネクションヘッダＨは、汎用的なＩＰヘッダやＴＣＰヘッダを流用したものである。
【００８２】
ＩＰヘッダ部ｈ１のSource IP Addressのフィールドには、重要フロー定義の定義項目である、入口エッジノード２−１のユーザ側Ｉ／Ｆアドレスが記載される。また、Destination IP Addressのフィールドには、重要フロー定義の定義項目である、出口エッジノード２−２のユーザ側Ｉ／Ｆアドレスが記載される。
【００８３】
ＴＣＰヘッダ部ｈ２のSource Portのフィールドには、重要フロー転送用コネクションＣのソースＴＣＰポートの番号が記載され、Destination Portのフィールドには、重要フロー転送用コネクションＣのデスティネーションＴＣＰポートの番号が記載される。
【００８４】
なお、拡張部ｈ３には、Service-Flow-Import Timeというデータが記載されているが、これは、入口エッジノード２−１がユーザパケットを受信したときの受信時刻を記載するものである。
【００８５】
次に転送到達性確認処理および転送障害検出処理について説明する。図９はユーザパケット通信時の転送到達性確認処理および転送障害検出処理を示すシーケンス図である。
〔Ｓ３１〕入口エッジノード２−１と出口エッジノード２−２との間に重要フロー転送用コネクションＣが確立する。
【００８６】
〔Ｓ３２〕入口転送制御部２ａは、重要フローパケットｐ１、ｐ２を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
〔Ｓ３３〕出口転送制御部２ｂは、重要フローパケットｐ１を受信したことを示すＡＣＫ１と、重要フローパケットｐ２を受信したことを示すＡＣＫ２とを入口エッジノード２−１へ送信する。入口転送制御部２ａは、内部にＡＣＫ待ちタイマを有しており、規定時間内にＡＣＫ１、２を受信することで、重要フローパケットｐ１、ｐ２が正常に転送されたことを確認する。
【００８７】
〔Ｓ３４〕入口転送制御部２ａは、重要フローパケットｐ３、ｐ４を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
〔Ｓ３５〕出口転送制御部２ｂは、重要フローパケットｐ３を受信したことを示すＡＣＫ３と、重要フローパケットｐ４を受信したことを示すＡＣＫ４とを入口エッジノード２−１へ送信する。入口転送制御部２ａは、規定時間内にＡＣＫ３、４を受信することで、重要フローパケットｐ３、ｐ４が正常に転送されたことを確認する。
【００８８】
〔Ｓ３６ａ〕入口転送制御部２ａは、重要フローパケットｐ５を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
〔Ｓ３６ｂ〕入口転送制御部２ａは、規定時間に達しても、ＡＣＫを受信できないので、再度、重要フローパケットｐ５を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
【００８９】
〔Ｓ３７〕入口転送制御部２ａは、重要フローパケットｐ５の確認応答であるＡＣＫを受信できずタイムアウトとなり、転送障害が発生したことを認識する。
〔Ｓ３８〕入口転送制御部２ａは、転送障害検出回数をインクリメントして、統計情報である転送障害ログ情報を障害検出時刻とともに保存する。
【００９０】
〔Ｓ３９〕入口転送制御部２ａは、重要フロー契約した重要フローパケットの転送到達性確認が取れない場合（転送障害を検出した場合）、重要フロー定義を参照して、契約関係者にｅ−ｍａｉｌで通知する。転送障害検出の情報が関係者に通知されることにより、ユーザは、パケット転送の可否判断を行うことが可能になる。
【００９１】
ここで、転送障害ログ情報は、ＳＬＡ（Service Level Agreement：ユーザとプロバイダとの間で、サービスの内容、範囲、品質に対する要求水準を明確にして、それが達成できなかった場合のルールを含めて、あらかじめ合意した契約）にもとづく指標データとして、ＩＰネットワークを管理するためのネットワーク管理システム（ＮＭＳ：Network Management System）から定期的に収集される。
【００９２】
ＳＬＡとしては、上記のステップＳ３９のように、「転送到達性確認が取れない場合は、関係者にメールで通知する」といった他にも、例えば、「平日の時刻７：００−２２：００における年間の転送障害検出回数を１２回以下とする」、「平日の時刻７：００−２２：００における年間の平均網内遅延時間を１秒以下とする」などがある。転送障害ログ情報は、定期的に保守者に収集され、かつユーザに対してもＳＬＡの証明データとして開示されて、ＳＬＡが満たされているかの状態確認が行われる。
【００９３】
図１０はユーザパケット無通信時の転送到達性確認処理および転送障害検出処理を示すシーケンス図である。重要フローパケットｆ１が通信されていない時間帯においても、転送到達性確認処理および転送障害検出処理を継続的に実施するために、入口エッジノード２−１からからダミーパケット（例えば、keep aliveパケット）を生成して送信する。
【００９４】
〔Ｓ４１〕入口エッジノード２−１と出口エッジノード２−２との間に重要フロー転送用コネクションＣが確立する。
〔Ｓ４２〕入口エッジノード２−１の入口転送制御部２ａは、keep aliveパケットｐ１１を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
【００９５】
〔Ｓ４３〕出口エッジノード２−２の出口転送制御部２ｂは、keep aliveパケットｐ１１を受信したことを示すＡＣＫ１１を入口エッジノード２−１へ送信する。入口転送制御部２ａは、内部にＡＣＫ待ちタイマを有しており、規定時間内にＡＣＫ１１を受信することで、keep aliveパケットｐ１１が正常に転送されたことを確認する。
【００９６】
〔Ｓ４４ａ〕入口転送制御部２ａは、keep aliveパケットｐ１２を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
〔Ｓ４４ｂ〕入口転送制御部２ａは、規定時間に達しても、ＡＣＫを受信できないので、再度、keep aliveパケットｐ１２を、重要フロー転送用コネクションＣを通じて、出口エッジノード２−２へ転送する。
【００９７】
〔Ｓ４５〕入口転送制御部２ａは、keep aliveパケットｐ１２の確認応答であるＡＣＫを受信できずタイムアウトとなり、転送障害が発生したことを認識する。
〔Ｓ４６〕入口転送制御部２ａは、転送障害検出回数をインクリメントして、転送障害ログ情報を障害検出時刻とともに保存する。
【００９８】
〔Ｓ４７〕入口転送制御部２ａは、重要フロー契約したユーザパケットの転送到達性確認が取れない場合（転送障害を検出した場合）、重要フロー定義を参照して、契約関係者にｅ−ｍａｉｌで通知する。
【００９９】
次にパケット転送時間の計測処理について説明する。図１１はパケット転送時間の計測処理を示すシーケンス図である。
〔Ｓ５１〕入口エッジノード２−１と出口エッジノード２−２との間に重要フロー転送用コネクションＣが確立する。
【０１００】
〔Ｓ５２〕入口転送制御部２ａは、送信元ユーザ端末１ａから送信された重要フローパケットの受信時刻Ｔｓ１を計測する。
〔Ｓ５３〕入口転送制御部２ａは、受信時刻Ｔｓ１をヘッダに付与して、重要フローパケットｐ２１を出口エッジノード２−２へ転送する。
【０１０１】
〔Ｓ５４ａ〕出口転送制御部２ｂは、重要フローパケットｐ２１を受信すると、受信時刻Ｔｒ１を計測する。
〔Ｓ５４ｂ〕出口転送制御部２ｂは、転送時間Ｔ１（＝Ｔｒ１−Ｔｓ１）を算出して保存する。
【０１０２】
〔Ｓ５５〕入口転送制御部２ａは、送信元ユーザ端末１ａから送信された重要フローパケットの受信時刻Ｔｓ２を計測する。
〔Ｓ５６〕入口転送制御部２ａは、受信時刻Ｔｓ２をヘッダに付与して、重要フローパケットｐ２２を出口エッジノード２−２へ転送する。
【０１０３】
〔Ｓ５７ａ〕出口転送制御部２ｂは、重要フローパケットｐ２２を受信すると、受信時刻Ｔｒ２を計測する。
〔Ｓ５７ｂ〕出口転送制御部２ｂは、転送時間Ｔ２（＝Ｔｒ２−Ｔｓ２）を算出して保存する。
【０１０４】
〔Ｓ５８〕出口転送制御部２ｂは、転送時間Ｔ１、Ｔ２、・・・Ｔｎに対して、単位時間当たりの平均値を算出して、その平均値である平均網内遅延時間を統計情報として記憶する。平均網内遅延時間は、ＳＬＡにもとづく指標データとして、ＩＰネットワークを管理するためのＮＭＳから定期的に収集される。
【０１０５】
例えば、ＳＬＡにおいて、「平日の時刻７：００−２２：００における年間の平均網内遅延時間を１秒以下とする」とした項目があれば、平均網内遅延時間は定期的に保守者に収集され、かつユーザに対してもＳＬＡの証明データとして開示されて、ＳＬＡが満たされているかの状態確認が行われる。
【０１０６】
以上説明したように、通信システム１では、プロバイダドメイン２０内の転送到達性確認処理を実行するので、ＯＳＩネットワークと同様にＩＰネットワークにおいても、サービスプロバイダとしてユーザフローの転送到達性をユーザにコミットすることが可能になる。
【０１０７】
また、ＯＳＩネットワークと同様にＩＰネットワークにおいても、サービスプロバイダとしてユーザフローの転送障害を検出でき、その結果、ユーザへの転送障害や転送不可状態の通知、ユーザとのサービスレベル契約（ＳＬＡ）にもとづく指標データ（転送障害ログ情報）の採取が可能となる。
【０１０８】
さらに、サービスプロバイダとしてユーザフローの網内伝送時間を計測でき、その結果、ユーザとのサービスレベル契約（ＳＬＡ）に基づく指標データ（平均網内遅延時間）の採取が可能となる。
【０１０９】
また、ユーザとのサービス契約で対象ユーザフローを決定（重要フロー契約）することにより、サービスプロバイダとしてサービスメニューの多様化が図れる。
さらにまた、ＮＧＮ（Next Generation Network）のU-Planeの基盤になっているＭＰＬＳ（Multi Protocol Label Switching）ネットワークの場合、設備更新時には、コアルータを含むすべてのプロバイダドメイン２０内の設備更新が必要であるが、通信システム１の機能を適用することにより、プロバイダドメイン２０内の設備の更新は、重要フロー契約ユーザを収容するエッジルータだけで済むことができ、スモールスタート（サービス開発の際、最初から大規模・多機能化をせずに、シンプルな設備でスタートさせる）が可能になる。
【図面の簡単な説明】
【０１１０】
【図１】通信システムの原理図である。
【図２】重要フローパケットと一般フローパケットの転送の流れを示す概念図である。
【図３】重要フロー定義の内容を示す図である。
【図４】通信システムの全体構成を示す図である。
【図５】重要フロー転送用コネクションが自動設定されるまでのシーケンスを示す図である。
【図６】フロー判別後のパケット処理のフローチャートを示す図である。
【図７】重要フローパケットの検索処理を説明するための図である。
【図８】重要フロー転送用コネクションヘッダを示す図ある。
【図９】ユーザパケット通信時の転送到達性確認処理および転送障害検出処理を示すシーケンス図である。
【図１０】ユーザパケット無通信時の転送到達性確認処理および転送障害検出処理を示すシーケンス図である。
【図１１】パケット転送時間の計測処理を示すシーケンス図である。
【符号の説明】
【０１１１】
１ 通信システム
１０、３０ ユーザドメイン
２０ プロバイダドメイン
１ａ 送信元ユーザ端末
３ａ 宛先ユーザ端末
２−１ 入口エッジノード
２ａ 入口転送制御部
２−２ 出口エッジノード
２ｂ 出口転送制御部
Ｃ 重要フロー転送用コネクション
ｃｐ カプセル化重要フローパケット
ｆ１ 重要フローパケット
ｆ２ 一般フローパケット
【特許請求の範囲】
【請求項１】
ネットワーク上で通信を行う通信システムにおいて、
送信元ユーザ端末と、
宛先ユーザ端末と、
前記送信元ユーザ端末から転送されたパケットの転送制御を行う入口転送制御部を含み、プロバイダドメインの入口エッジに配置される入口エッジノードと、
前記入口エッジノードから転送された前記パケットの転送制御を行う出口転送制御部を含み、前記プロバイダドメインの出口エッジに配置される出口エッジノードと、
を備え、
前記入口転送制御部と前記出口転送制御部との間で、前記プロバイダドメイン内に、重要フロー転送用コネクションを確立し、
前記入口転送制御部は、前記送信元ユーザ端末から転送されたユーザフローパケットが、重要フローパケットであるか、一般フローパケットであるかを判別して、前記重要フローパケットには、カプセリングを行ってカプセル化重要フローパケットを生成し、前記カプセル化重要フローパケットを前記重要フロー転送用コネクションを通じて転送し、
前記出口転送制御部は、前記重要フロー転送用コネクションを通じて受信した前記カプセル化重要フローパケットをデカプセリングし、デカプセリング後の前記重要フローパケットを前記宛先ユーザ端末へ転送する、
ことを特徴とする通信システム。
【請求項２】
前記入口転送制御部は、前記送信元ユーザ端末と接続する前記入口エッジノードのユーザ側インタフェースアドレスと、前記宛先ユーザ端末と接続する前記出口エッジノードのユーザ側インタフェースアドレスとが記載された、前記ユーザフローパケットが前記重要フローパケットであるか否かを検索するための重要フロー定義情報が設定されると、
双方の前記ユーザ側インタフェースアドレスの間で、前記重要フロー転送用コネクションが自動的に確立し、
前記入口転送制御部および前記出口転送制御部は、前記重要フロー転送用コネクションのポート番号を記憶し、
前記入口転送制御部は、前記ポート番号を含むヘッダを前記重要フローパケットに付与して、前記カプセル化重要フローパケットを生成し、
前記出口転送制御部は、受信パケットに前記ポート番号が含まれている場合には、前記受信パケットが前記カプセル化重要フローパケットであると認識してデカプセリングする、
ことを特徴とする請求項１記載の通信システム。
【請求項３】
前記入口転送制御部は、前記重要フロー転送用コネクションを介して前記重要フローパケットを転送した場合に、前記出口転送制御部から送信されるべき確認応答を規定時間内に受信できない場合には、前記重要フローパケットの転送契約を行った関係者に対して、転送到達性を確認できない旨を通知することを特徴とする請求項１記載の通信システム。
【請求項４】
前記入口転送制御部は、無通信時にも前記重要フロー転送用コネクションを介してダミーパケットを転送して転送到達性の確認を行い、前記出口転送制御部から送信されるべき確認応答を規定時間内に受信できない場合には、前記重要フローパケットの転送契約を行った関係者に対して、転送到達性を確認できない旨を通知することを特徴とする請求項１記載の通信システム。
【請求項５】
前記入口転送制御部は、前記送信元ユーザ端末から送信された前記重要フローパケットの受信時刻である第１の受信時刻を計測し、前記第１の受信時刻を前記重要フローパケットに付加して、前記重要フロー転送用コネクションを通じて転送し、
前記出口転送制御部は、前記重要フロー転送用コネクションを通じて受信した前記重要フローパケットの受信時刻である第２の受信時刻を計測し、前記第２の受信時刻から前記第１の受信時刻の差分である転送時間を求め、ｎ個の前記重要フローパケットに対して求めた前記転送時間を平均化して平均網内遅延時間を算出して、保守側に通知することを特徴とする請求項１記載の通信システム。
【請求項１】
ネットワーク上で通信を行う通信システムにおいて、
送信元ユーザ端末と、
宛先ユーザ端末と、
前記送信元ユーザ端末から転送されたパケットの転送制御を行う入口転送制御部を含み、プロバイダドメインの入口エッジに配置される入口エッジノードと、
前記入口エッジノードから転送された前記パケットの転送制御を行う出口転送制御部を含み、前記プロバイダドメインの出口エッジに配置される出口エッジノードと、
を備え、
前記入口転送制御部と前記出口転送制御部との間で、前記プロバイダドメイン内に、重要フロー転送用コネクションを確立し、
前記入口転送制御部は、前記送信元ユーザ端末から転送されたユーザフローパケットが、重要フローパケットであるか、一般フローパケットであるかを判別して、前記重要フローパケットには、カプセリングを行ってカプセル化重要フローパケットを生成し、前記カプセル化重要フローパケットを前記重要フロー転送用コネクションを通じて転送し、
前記出口転送制御部は、前記重要フロー転送用コネクションを通じて受信した前記カプセル化重要フローパケットをデカプセリングし、デカプセリング後の前記重要フローパケットを前記宛先ユーザ端末へ転送する、
ことを特徴とする通信システム。
【請求項２】
前記入口転送制御部は、前記送信元ユーザ端末と接続する前記入口エッジノードのユーザ側インタフェースアドレスと、前記宛先ユーザ端末と接続する前記出口エッジノードのユーザ側インタフェースアドレスとが記載された、前記ユーザフローパケットが前記重要フローパケットであるか否かを検索するための重要フロー定義情報が設定されると、
双方の前記ユーザ側インタフェースアドレスの間で、前記重要フロー転送用コネクションが自動的に確立し、
前記入口転送制御部および前記出口転送制御部は、前記重要フロー転送用コネクションのポート番号を記憶し、
前記入口転送制御部は、前記ポート番号を含むヘッダを前記重要フローパケットに付与して、前記カプセル化重要フローパケットを生成し、
前記出口転送制御部は、受信パケットに前記ポート番号が含まれている場合には、前記受信パケットが前記カプセル化重要フローパケットであると認識してデカプセリングする、
ことを特徴とする請求項１記載の通信システム。
【請求項３】
前記入口転送制御部は、前記重要フロー転送用コネクションを介して前記重要フローパケットを転送した場合に、前記出口転送制御部から送信されるべき確認応答を規定時間内に受信できない場合には、前記重要フローパケットの転送契約を行った関係者に対して、転送到達性を確認できない旨を通知することを特徴とする請求項１記載の通信システム。
【請求項４】
前記入口転送制御部は、無通信時にも前記重要フロー転送用コネクションを介してダミーパケットを転送して転送到達性の確認を行い、前記出口転送制御部から送信されるべき確認応答を規定時間内に受信できない場合には、前記重要フローパケットの転送契約を行った関係者に対して、転送到達性を確認できない旨を通知することを特徴とする請求項１記載の通信システム。
【請求項５】
前記入口転送制御部は、前記送信元ユーザ端末から送信された前記重要フローパケットの受信時刻である第１の受信時刻を計測し、前記第１の受信時刻を前記重要フローパケットに付加して、前記重要フロー転送用コネクションを通じて転送し、
前記出口転送制御部は、前記重要フロー転送用コネクションを通じて受信した前記重要フローパケットの受信時刻である第２の受信時刻を計測し、前記第２の受信時刻から前記第１の受信時刻の差分である転送時間を求め、ｎ個の前記重要フローパケットに対して求めた前記転送時間を平均化して平均網内遅延時間を算出して、保守側に通知することを特徴とする請求項１記載の通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１０−４５６０５（Ｐ２０１０−４５６０５Ａ）
【公開日】平成２２年２月２５日（２０１０．２．２５）
【国際特許分類】
【出願番号】特願２００８−２０８３４５（Ｐ２００８−２０８３４５）
【出願日】平成２０年８月１３日（２００８．８．１３）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２２年２月２５日（２０１０．２．２５）
【国際特許分類】
【出願日】平成２０年８月１３日（２００８．８．１３）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]