JP2014216680A - 疎通確認装置、ネットワークシステム、疎通確認方法、および疎通確認プログラム - Google Patents

Abstract

【課題】転送部毎に任意の転送ルールを設定可能なネットワークについて、任意の区間における疎通確認を行う装置を提供する。【解決手段】疎通確認装置１は、転送部毎に任意の転送ルールを設定可能なネットワークについて、通信の疎通を確認すべき疎通確認区間の指定を受け付ける疎通確認要求受信部３０と、前記指定を受け付けた指定確認区間における前記転送ルールに応じた確認用データを生成する確認用パケット生成部３２と、確認用パケット生成部により生成された確認用データを前記ネットワークに送出し、返信された前記確認用データを参照して前記疎通確認区間において疎通が正常になされているか否かを判定する確認結果判定部３６とを備える。【選択図】図４

Description

本発明は、疎通確認装置、ネットワークシステム、疎通確認方法、および疎通確認プログラムに関する。

従来、Ｌ２スイッチで構成されたネットワークでは、ＭＡＣアドレスを利用してパケット転送がされ、ルータで構成されたネットワークでは、ＩＰアドレスを利用してパケット転送がされている。これらのネットワーク内では、同一の転送装置内で異なる転送方法が混在することは無かった。

また、例えばルータによって構成されるネットワーク（ＩＰネットワーク）においては、宛先ＩＰアドレスによってのみ転送が行われ、その上位プロトコル（ＩＣＭＰ（Internet Control Message Protocol；非特許文献１参照）、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）など）が異なっていたとしても、同じルールでパケット転送処理が行われる。

従って、従来のネットワーク（例えばＩＰネットワーク）においては、仮にＩＣＭＰパケットの到達が確認できれば、同一のＩＰアドレス宛のＴＣＰパケットやＵＤＰパケットも到達することが保証される。そのため、疎通の確認には、何れかの種類のパケットの到達を確認すれば十分であり、これによって任意のＩＰパケットの疎通確認が可能であった。その具体的な手法の一つとして、ＩＣＭＰパケットを利用するｐｉｎｇなどが挙げられる。

ＲＦＣ７９２、ＩＮＴＥＲＮＥＴ ＣＯＮＴＲＯＬ ＭＥＳＳＡＧＥ ＰＲＯＴＯＣＯＬ、２０１３年２月１２日検索、インターネット＜URL:http://www.rfcsearch.org/rfcview?lookup_type=RFC&lookup_num=792＞ ＯｐｅｎＦｌｏｗ Ｓｗｉｔｃｈ Ｓｐｅｃｉｆｉｃａｔｉｏｎ、２０１３年２月１３日検索、インターネット＜URL:https://www.opennetworking.org/images/stories/downloads/specification/openflow-spec-v1.3.1.pdf＞ ＭＰＬＳ Ｊａｐａｎ ２０１２ における発表資料（Ｐ．２６）、２０１３年２月１３日検索、インターネット＜URL:http://www.mpls.jp/presentations/m.tsukuda_mpls_japan_2012.pdf＞

ところで、近年、ＳＤＮ（Software Defined Network）の実現方式の１つとして、ＯｐｅｎＦｌｏｗ（非特許文献２参照）が提唱されており、ＯＮＦ（Open Network Foundation）によって仕様策定が進められている。ＯｐｅｎＦｌｏｗを利用したネットワークとは、ＯｐｅｎＦｌｏｗコントローラ（以下、ＯＦＣと称する）とＯｐｅｎＦｌｏｗスイッチ（以下、ＯＦＳと称する）によって構成されるネットワークであり、ＯＦＣからＯＦＳに対してパケットの転送ルールを自由に設定可能であり、その転送ルールによって仮想ネットワークを構築可能な技術である。ＯＦＳで構成されるネットワークにおいては、様々なパケット転送方法を持つ仮想ネットワークを自由に構成可能である。すなわち、ＯｐｅｎＦｌｏｗを利用したネットワークでは、同一の転送装置内に異なる転送方法が混在することがあり得る。

図１は、ＯｐｅｎＦｌｏｗを利用したネットワークを概念的に示す図である。ＯｐｅｎＦｌｏｗを利用したネットワークでは、図１に示すように転送装置（図中、ＯＦＳ（１）〜ＯＦＳ（６））を備える物理ＮＷ（ネットワーク）から、仮想ＮＷ１〜３を構築することができる。例えば、仮想ＮＷ１では、送信元ＩＰアドレスが192.168.0/24であり、送信先ＩＰアドレスが192.168.10/24であり、且つプロトコルがＴＣＰであるパケットが転送されるという転送ルールを適用することが可能である。また、仮想ＮＷ２では、ＭＡＣアドレスに基づく転送ルールが、仮想ＮＷ３では、プロトコルがＵＤＰであり、且つ送信先ポート番号が３０００番に対する転送ルールが規定されているというように、様々な転送ルールの仮想ＮＷが同一の物理ＮＷ上に構築される場合がある。

従来のＬ２スイッチで構成されたネットワークやルータで構成されたネットワークの場合、例えば、ある種類・転送方法のパケットについて転送装置（１）→（４）の疎通が確認されれば、任意の種類・転送方法のパケットについて転送装置（１）→（４）の疎通が確認されたことになる。しかしながら、ＯｐｅｎＦｌｏｗを利用したネットワークでは、例えば仮想ＮＷ３において転送装置（１）→（４）の疎通が確認されたとしても、仮想ＮＷ１において転送装置（１）→（４）の疎通が確認されたことにはならない。ＯｐｅｎＦｌｏｗを利用したネットワークのように、各転送装置に任意の転送ルールを設定可能なネットワークでは、仮想ＮＷ間で、送信元と送信先が同じであっても転送経路が異なる場合があるからである。

これに対し、ＣＣ／ｐｉｎｇを利用した方式が提示されている（非特許文献３参照）。しかしながら、この方式は、作成される仮想ネットワークが、従来のＬ２／Ｌ３ネットワークのみであることを前提としているため、各転送装置に任意の転送ルールを設定可能なネットワークに適用することができない場合がある。

本発明は、このような事情を考慮してなされたものであり、転送部毎に任意の転送ルールを設定可能なネットワークについて、任意の区間における疎通確認を行うことを目的の一つとする。

本発明の一態様は、転送部毎に任意の転送ルールを設定可能なネットワークについて、通信の疎通を確認すべき疎通確認区間の指定を受け付ける受付部と、前記指定を受け付けた指定確認区間における前記転送ルールに応じた確認用データを生成する生成部と、前記生成部により生成された確認用データを前記ネットワークに送出し、返信された前記確認用データを参照して前記疎通確認区間において疎通が正常になされているか否かを判定する判定部と、を備える疎通確認装置である。

本発明の一態様によれば、転送部毎に任意の転送ルールを設定可能なネットワークについて、任意の区間における疎通確認を行うことができる。

ＯｐｅｎＦｌｏｗを利用したネットワークを概念的に示す図である。 本実施形態に係る疎通確認装置１の通信環境を例示した図である。 疎通確認装置１のハードウェア構成の一例を示す図である。 疎通確認装置１の機能構成の一例を示す図である。 試験管理情報４０として格納されるデータの構造の一例を示す図である。 疎通確認装置１により実行される処理の流れを示すフローチャートの一例である。 確認用パケットのヘッダ部分のフォーマットの一例を示す図である。 デフォルトの確認用パケットのヘッダ部分の一例を示す図である。 疎通確認処理が適用されるネットワークシステムの一部を例示した図である。 図９に示す仮想ＮＷの設定情報の一例を示す図である。 試験管理情報４０として可能されるデータの一例である。 確認用パケット生成部３２がデフォルトの確認用パケット（ＴＣＰ版）に、ＴＴＬとＩＰアドレスを格納した確認用パケットの一例を示す図である。 １つのＳｒｃに対して複数のＤｓｔが存在する仮想ＮＷの一例を示す図である。 図１３に示す仮想ＮＷを仮想的に分割したサブＮＷの一例を示す図である。

［構成］
以下、図面を参照し、本発明の疎通確認装置、ネットワークシステム、疎通確認方法、および疎通確認プログラムの実施形態について説明する。図２は、本実施形態に係る疎通確認装置１の通信環境を例示した図である。疎通確認装置１は、例えば、ＯＦＣ１００およびトポロジ管理装置２００に接続される。疎通確認の対象とされるネットワークＮＷは、ＯＦＳ（１）〜（６）が互いに通信を行うことで機能する。各ＯＦＳは、ＯＦＣ１００からの指示に応じて設定される条件に従って、パケットの転送処理を行う。各ＯＦＳは、ＯｐｅｎＦｌｏｗプロトコルに従って動作する。例えば、各ＯＦＳは、ＴＴＬ（Time To Live）の値が「１」である確認用パケット（確認用データの一例である）を受信すると、ＯＦＣ１００に対してＰａｃｋｅｔＩｎ処理を行う。

ＯＦＣ１００は、例えば、ネットワークＮＷ内の全てのＯＦＳと通信可能に接続され（直接であってもよいし、ＯＦＳなどを介在させてもよい）、各ＯＦＳに対する処理を実施するためのＯｐｅｎＦｌｏｗプロトコルスタックが搭載されている。ＯＦＣ１００は、各ＯＦＳにおける転送ルールを設定する。また、ＯＦＣ１００は、疎通確認装置１からの指示に従い、疎通確認用パケットの送信、およびＯＦＳからのイベントのハンドリングを行い、ハンドリングした情報を疎通確認装置１に返信する。

トポロジ管理装置２００は、ネットワークＮＷ上に構築されている各仮想ネットワークのトポロジ情報を管理する。トポロジ管理装置２００は、仮想ネットワーク毎に、利用しているＯＦＳを一意に定める情報（以下、ＯＦＳのＩＤ）、ＯＦＳの接続関係情報、仮想ネットワーク構築ルールなどを管理しており、任意の仮想ネットワークにおける任意のＯＦＳ間のホップ数を算出することができる。また、トポロジ管理装置２００は、マウス、キーボード、表示装置などのユーザインターフェースを備え、オペレータによる疎通確認区間の指定などを受け付けると共に、仮想ネットワークのトポロジ情報を表示したり、疎通確認装置１による確認結果を表示したりする。なお、これに限らず、疎通確認装置１がユーザインターフェースを備えてもよいし、ＯＦＣ１００と疎通確認装置１、トポロジ管理装置２００と疎通確認装置１、或いはこれらの全てが一体化されてもよい。

図３は、疎通確認装置１のハードウェア構成の一例を示す図である。疎通確認装置１は、例えば、ＣＰＵ１０とドライブ装置１２と、記憶装置１６と、メモリ装置１８と、インターフェース装置２０とを備える。

ＣＰＵ１０は、記憶装置１６やメモリ装置１８に格納された各種プログラムを実行する。ドライブ装置１２には、ＵＳＢメモリ、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ＳＤカードなどの記憶媒体１４が装着される。記憶装置１６は、例えば、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ、ＲＯＭ（Read Only Memory）等を含む。メモリ装置１８は、例えば、ＲＡＭ（Random Access Memory）やレジスタ等を含む。インターフェース装置２０は、ＯＦＣ１００やトポロジ管理装置２００に接続するための装置である。

図４は、疎通確認装置１の機能構成の一例を示す図である。疎通確認装置１は、トポロジ管理装置２００においてオペレータによって指定された仮想ネットワーク上の疎通確認区間の情報を受け取り、ＯＦＣのＰａｃｋｅｔＯｕｔ／ＰａｃｋｅｔＩｎ機能を利用して疎通確認処理を実施する。

疎通確認装置１は、例えば、疎通確認要求受信部３０と、確認用パケット生成部３２と、ＯＦＣ連携部３４と、確認結果判定部３６と、確認結果送信部３８とを備える。これらの機能部は、例えば、記憶装置１６に格納されたプログラムをＣＰＵ１０が実行することにより機能するソフトウェア機能部である。なお、これらの機能部がそれぞれ独立したプログラムによって記述されている必要は無い。また、これらの機能部の一部または全部は、ＬＳＩ（Large Scale Integration）やＩＣ（Integrated Circuit）などのハードウェア機能部であってもよい。また、疎通確認装置１は、メモリ装置１８や記憶装置１６に、試験管理情報４０を格納する。

疎通確認要求受信部３０は、トポロジ管理装置２００から、疎通確認要求を受信する。疎通確認要求には、疎通確認区間における仮想ＮＷの転送ルール、疎通確認区間のＳｒｃ（起点）およびＤｓｔ（終点）のＯＦＳのＩＤ、およびホップ数などの情報が含まれる。転送ルールとしては、例えば、＜送信先ＩＰ（送信先のＩＰアドレス）＝192.168.0/24、プロトコル＝ＵＤＰ＞といった内容が規定される。また、ＯＦＳのＩＤとしては、例えばデータパスＩＤなどが用いられる。疎通確認要求受信部３０は、疎通確認要求を受信すると、その要求を一意に識別するための情報（以下、要求識別情報）を生成し、疎通確認区間のＳｒｃおよびＤｓｔのＯＦＳのＩＤと共に試験管理情報４０としてメモリ装置１８や記憶装置１６に格納する。図５は、試験管理情報４０として格納されるデータの構造の一例を示す図である。

確認用パケット生成部３２は、メモリ装置１８や記憶装置１６に格納された情報に基づき、疎通確認に利用する確認用パケットを生成してＯＦＣ連携部３４に出力する。確認用パケットの生成処理の詳細については、後述する。なお、本実施形態においては、疎通確認装置１が確認用パケットの生成を行うものとしたが、疎通確認装置１が確認用パケットの生成条件のみを決定し、その条件を例えばＯＦＣ１００に送信し、ＯＦＣ１００が確認用パケットを生成するといった流れで処理が行われてもよい。

ＯＦＣ連携部３４は、確認用パケット生成部３２が生成した確認用パケットを受け取ると共にＳｒｃのＯＦＳのＩＤをメモリ装置１８や記憶装置１６から読み込み、パケットの送信指示（ＰａｃｋｅｔＯｕｔ指示）をＳｒｃのＯＦＣに送信する。また、ＯＦＣ連携部３４は、ＤｓｔのＯＦＳが送信したイベント情報（ＰａｃｋｅｔＩｎ情報）をＯＦＣ１００経由で受信し、確認結果判定部３６に出力する。

確認結果判定部３６は、ＯＦＣ連携部３４から入力されたＰａｃｋｅｔＩｎ情報と、試験管理情報４０に含まれる要求識別情報とを比較することにより、トポロジ管理装置２００から入力されたＳｒｃのＯＦＳとＤｓｔのＯＦＳの間の疎通が確認できたか否かを判定する。確認結果送信部３８は、確認結果判定部３６による判定結果をトポロジ管理装置２００に送信する。

［処理の流れ］
図６は、疎通確認装置１により実行される処理の流れを示すフローチャートの一例である。まず、疎通確認装置１は、トポロジ管理装置２００から疎通確認要求を受信するまで待機する（ステップＳ３００）。トポロジ管理装置２００から疎通確認要求を受信すると、疎通確認要求受信部３０は、受信した情報をメモリ装置１８や記憶装置１６に格納する（ステップＳ３０２）。

次に、確認用パケット生成部３２が、確認用パケットの生成処理を行う（ステップＳ３０４〜Ｓ３２０）。図７は、確認用パケットのヘッダ部分のフォーマットの一例を示す図である。図７に示すように、確認用パケットは、例えばＩＰｖ４に基づいて生成される。ＩＰｖ６に基づいて確認用パケットを生成する場合、対応する箇所を適宜変換すればよい。確認用パケットは、イーサヘッダとＩＰヘッダが結合したものに、ＩＣＭＰヘッダ、ＴＣＰヘッダ、ＵＤＰヘッダのいずれかが付加されたフォーマットで生成される。

図６に戻り、説明を行う。まず、確認用パケット生成部３２は、疎通確認区間における転送ルールにおいて、ＩＰよりも上位のプロトコルの指定が有るか否かを判定する（ステップＳ３０４）。プロトコルの指定が無い場合、確認用パケット生成部３２は、ＵＤＰパケットをデフォルトの確認用パケットとする（ステップＳ３０６）。一方、プロトコルの指定が有る場合、確認用パケット生成部３２は、指定されたプロトコルでデフォルトの確認用パケットを生成する（ステップＳ３０８）。

図８は、デフォルトの確認用パケットのヘッダ部分の一例を示す図である。図８に示すように、デフォルトの確認用パケットにおいて、イーサヘッダの送信元ＭＡＣアドレスにはＯＦＣ１００のＭＡＣアドレスが、送信先ＭＡＣアドレスには任意のＭＡＣアドレスが、それぞれ入力される。また、デフォルトの確認用パケットにおいて、ＩＰヘッダの送信元ＩＰアドレスにはＯＦＣ１００のＩＰアドレスが、送信先ＩＰアドレスには任意のＩＰアドレス（プライベート、ブロードキャスト、マルチキャスト、ネットワークを除く）が、それぞれ入力される。

また、デフォルトの確認用パケットがＩＣＭＰパケットである場合（疎通確認区間における転送ルールにおいて、プロトコルの指定がＩＣＭＰである場合）、ＩＣＭＰヘッダのタイプには「０」が入力される。デフォルトの確認用パケットがＴＣＰパケットである場合（プロトコルの指定がＴＣＰである場合）、ＴＣＰヘッダの送信元ポート番号および送信先ポート番号には「０」が入力される。デフォルトの確認用パケットがＵＤＰパケットである場合（プロトコルの指定がＴＣＰである場合）、ＴＣＰヘッダの送信元ポート番号および送信先ポート番号には「０」が入力される。これらの値は、通常のパケットのヘッダには入力されない値（あり得ない値）であるため、仮に確認用パケットが仮想ＮＷの外部に流出し、疎通確認とは無関係な機器が受信したとしても、確認用パケットは、受信した機器において、トランスポート層よりも上位のプロトコルスタックにより破棄されることになる。この結果、疎通確認のためのパケット転送が、意図せぬ不都合を生じさせるのを防止することができる。

図６に戻り、説明を行う。確認用パケット生成部３２は、ステップＳ３０８の処理を行った後、疎通確認区間における転送ルールにおいて、指定されたプロトコルがＴＣＰまたはＵＤＰであるか、或いはＩＣＭＰであるかを判定する（ステップＳ３１０）。

指定されたプロトコルがＴＣＰまたはＵＤＰである場合、確認用パケット生成部３２は、疎通確認区間における転送ルールにおいて、送信先ポート番号の指定が有るか否かを判定する（ステップＳ３１２）。送信先ポート番号の指定が有る場合、確認用パケット生成部３２は、デフォルトの確認用パケットのチェックサム領域を不正な値に改変する（ステップＳ３１４）。

係る処理は、後述するステップＳ３１８において転送ルールに応じた情報を格納する（上書きする）ため、上記のように、送信先ポート番号に「０」を入力した効果が無くなることを考慮したものである。チェックサム領域を改変することで、例えば確認用パケットが仮想ＮＷの外部に流出して無関係な機器が受信した場合でも、確認用パケットは、受信した機器においてプロトコルスタックにより破棄されることになる。但し、チェックサム領域を改変する処理は、送信先ポート番号に「０」を格納する処理よりも若干、処理負荷が大きいため、送信先ポート番号に「０」を格納する処理を優先し、送信先ポート番号の指定が有るために「０」が上書きされる場合にのみ、チェックサム領域の改変を行う。これによって、疎通確認装置１は、疎通確認のためのパケット転送が、意図せぬ不都合を生じさせるのを防止すると共に、処理負荷の増大を抑制することができる。

一方、指定されたプロトコルがＩＣＭＰである場合、確認用パケット生成部３２は、疎通確認区間における転送ルールにおいて、タイプの指定が有るか否かを判定する（ステップＳ３１６）。タイプの指定が有る場合、確認用パケット生成部３２は、デフォルトの確認用パケットのチェックサム領域を改変する（ステップＳ３１４）。係る処理の趣旨は、ステップＳ３１２→Ｓ３１４の流れと同様である。

次に、確認用パケット生成部３２は、デフォルトの確認用パケットに、疎通確認区間における転送ルールに応じた情報を格納する（ステップＳ３１８）。また、確認用パケット生成部３２は、ＩＰヘッダのＴＴＬ領域にホップ数を、ペイロード等に要求識別情報を、それぞれ格納する（ステップＳ３２０）。確認用パケット生成部３２は、ペイロード領域に代えて、ＩＰヘッダの識別子領域等に要求識別情報を入力してもよい。

図６に戻り、説明を行う。ＯＦＣ連携部３４は、ＯＦＣ１００に対して、生成した確認用パケットと、疎通確認区間におけるＳｒｃのＯＦＳのＩＤとを送信し、ＰａｃｋｅｔＯｕｔ機能を呼び出すことにより、疎通確認実施を依頼する（ステップＳ３２２）。ＯＦＣ１００は、疎通確認区間におけるＳｒｃのＯＦＳに対して、ＰａｃｋｅｔＯｕｔ処理によって確認用パケットを送信する。

この結果、疎通確認区間にあるＯＦＳは、ＴＴＬを１ずつ減らしながら確認用パケットを転送する。ＴＴＬが１の確認用パケットを受信したＯＦＳは、ＴＴＬを１減らすことでＴＴＬをゼロとし、ＯＦＣ１００に対してＴＴＬ ＩｎｖａｌｉｄによるＰａｃｋｔＩｎ処理を行う。ＰａｃｋｔＩｎされた情報（以下、ＰａｃｋｔＩｎ情報）には、ＰａｃｋｔＩｎ処理の対象となった確認用パケットが含まれている。従って、確認用パケットはＯＦＣ１００に戻ってくる仕組みとなっている。ＯＦＣ１００は、ＰａｃｋｅｔＩｎ情報と、それを送信したＯＦＳを特定する情報（以下、ＯＦＳ特定情報）を、疎通確認装置１のＯＦＣ連携部３４に送信する。

確認結果判定部３６は、ＯＦＣ連携部３４がＯＦＣ１００から受信したＰａｃｋｔＩｎ情報とＯＦＳ特定情報に基づき、疎通確認区間において疎通が正常になされているか否かを判定する（ステップＳ３２４；疎通確認結果判定）。より具体的には、確認結果判定部３６は、ＰａｃｋｅｔＩｎ情報からＰａｃｋｅｔＩｎ発生理由および確認用パケットを取り出し、更に確認用パケットに格納されている要求識別情報を取り出す。次に、確認結果判定部３６は、試験管理情報４０を参照し、上記取り出した要求識別情報に対応するＤｓｔのＯＦＳのＩＤを試験管理情報４０から取得する。そして、確認結果判定部３６は、ＰａｃｋｅｔＩｎ発生理由がＴＴＬ Ｉｎｖａｌｉｄであり、且つＯＦＣ連携部３４が受信したＯＦＳ特定情報と、試験管理情報４０から取得したＤｓｔのＯＦＳのＩＤが一致すれば、疎通が正常になされていると判定する。一方、確認結果判定部３６は、ＯＦＣ連携部３４が受信したＯＦＳ特定情報と、試験管理情報４０から取得したＤｓｔのＯＦＳのＩＤが一致しない場合、ＴＴＬ Ｉｎｖａｌｉｄ以外の理由でＰａｃｋｅｔＩｎされてきた場合、ＰａｃｋｅｔＯｕｔから一定時間経過してもＰａｃｋｅｔＩｎされてこない場合は、該当する疎通確認区間について、疎通が正常になされていないと判定する。

確認結果送信部３８は、確認結果判定部３６による疎通確認結果を、例えばトポロジ管理装置２００に送信する（ステップＳ３２６）。トポロジ管理装置２００は、疎通確認結果を表示装置に表示させる。これによって、オペレータが疎通確認結果を視認することができる。

なお、ＯＦＣ１００とＯＦＳ（疎通確認区間におけるＳｒｃまたはＤｓｔのＯＦＳ）の間の疎通が正常になされていない場合、ＰａｃｋｅｔＩｎが返ってこないため、疎通確認区間内での疎通は正常になされているにも関わらず、確認結果判定部３６は「疎通が正常になされていない」という疎通確認結果を出力することが想定される。これを回避するために、疎通確認装置１は、ＯＦＣ１００に、定期的に各ＯＦＳとの間の疎通確認を行わせてよい。この疎通確認は、例えば、返信を要求するパケット（確認用パケットとは異なるパケット）を各ＯＦＳに送信し、返信を確認することで行われる。これによって、確認結果判定部３６の判定精度を向上させることができる。

［適用例］
以下、上記説明した疎通確認処理が適用される場面について、より具体的に説明する。図９は、疎通確認処理が適用されるネットワークシステムの一部を例示した図である。図９に示すように、ＩＰアドレスが192.168.0.0/24に属するコンピュータＸから、ＩＰアドレスが192.168.1.0/24に属するコンピュータＹへのパケット送信は、ＩＤがＡであるＯＦＳ、ＩＤがＢであるＯＦＳ、ＩＤがＣであるＯＦＳ、ＩＤがＤであるＯＦＳの順に転送されて行われるように設定されている。図１０は、図９に示す仮想ＮＷの設定情報の一例を示す図である。図１０において、「Output＝port#x」とは、各ＯＦＳにおける次のＯＦＳが接続されているネットワークポートの番号を意味する。例えば、ＩＤがＢのＯＦＳでは、ＩＤがＣのＯＦＳが接続されるポートの番号となる。

このような場面で、疎通確認装置１が受信する疎通確認要求は、例えば、図１０の「Matching Field」に格納されたものを転送ルールとし、疎通確認区間がＳｒｃのＯＦＳ（ＩＤ＝Ａ）とＤｓｔのＯＦＳ（ＩＤ＝Ｄ）で特定され、ホップ数が４といった情報を含む。これによって、試験管理情報４０には、図１１に示すデータが格納される。

確認用パケット生成部３２が生成するデフォルトの確認用パケットは、図８に示す通りである（プロトコル指定ＴＣＰであるため、ＴＣＰヘッダがイーサヘッダおよびＩＰヘッダに付加される）。これに対し、確認用パケット生成部３２は、ホップ数＝４をＴＴＬ領域に格納し、送信元ＩＰアドレスおよび送信先ＩＰアドレスを、それぞれ仮想ＮＷの設定情報における送信元ＩＰアドレスおよび送信先ＩＰアドレスで上書きする。但し、ＩＰヘッダに格納するＩＰアドレスは、例えばそれぞれのセグメントの先頭アドレスとする。図１２は、確認用パケット生成部３２がデフォルトの確認用パケット（ＴＣＰ版）に、ＴＴＬとＩＰアドレスを格納した確認用パケットの一例を示す図である。

このような確認用パケットがＰａｃｋｅｔＯｕｔ処理によってＳｒｃのＯＦＳに送信されると、ＯＦＳ（ＩＤ＝Ａ、Ｂ、Ｃ、Ｄ）は、ＴＴＬを１ずつ減らしながら確認用パケットを転送する。ＴＴＬが１の確認用パケットを受信したＤｓｔのＯＦＳ（ＩＤ＝Ｄ）は、ＴＴＬを１減らすことでＴＴＬをゼロとし、ＯＦＣ１００に対してＴＴＬ ＩｎｖａｌｉｄによるＰａｃｋｔＩｎ処理を行う。

［マルチキャスト、ラウンドロビン等への適用］
ＯＦＳによって実現可能な通信方法は、１対１のユニキャスト通信だけでなく、１対多数のマルチキャスト通信や、負荷分散実現のためのラウンドロビンなどが実現可能である。ＯＦＳがこれらの通信をサポートしている場合、疎通確認要求は、全てのＤｓｔのＯＦＳ、および分岐点の次のＯＦＳを特定する情報を含めるように規定する。図１３は、１つのＳｒｃに対して複数のＤｓｔが存在する仮想ＮＷの一例を示す図である。疎通確認装置１は、図１３に示すような仮想ＮＷの全体について疎通確認を行う場合、分岐点の次のＯＦＳ（図中、ＩＤ＝Ｃ、Ｆのもの）を一方の仮Ｄｓｔとすると共に他方の仮Ｓｒｃとして仮想ＮＷを分割し、分割した各サブＮＷについて疎通確認を行う。図１４は、図１３に示す仮想ＮＷを仮想的に分割したサブＮＷの一例を示す図である。図１４において、「Ｓｒｃ*」、「Ｄｓｔ*」は、分割によって生じた仮のＳｒｃ、Ｄｓｔを示している。疎通確認装置１は、図１４に示すＤｓｔ（Ｄｓｔ*を含む）のＯＦＳの全てについて確認用パケットを生成し（図１４における疎通確認区間（１）〜（５））、対応するＳｒｃ（Ｓｒｃ*を含む）のＯＦＳに送信する。なお、分割に伴いホップ数も分割され、これに応じてＴＴＬが上書きされる。この結果、疎通が正常になされていれば、全てのＤｓｔのＯＦＳからＰａｃｋｅｔＩｎ情報が返ってくることになる。ＰａｃｋｅｔＩｎ情報に対する疎通確認判定については、上記説明と同じである。

［まとめ］
以上説明した本実施形態の疎通確認装置、ネットワークシステム、疎通確認方法、および疎通確認プログラム（以下、疎通確認装置１等）によれば、疎通確認区間における転送ルールに応じた確認用パケットを生成してＳｒｃのＯＦＳ（転送部）に送出するため、ＯＦＳ毎に転送ルールを設定可能なネットワークについて、任意の区間における疎通確認を行うことができる。

また、本実施形態の疎通確認装置１等によれば、ネットワーク外の機器が確認用パケットを受信したとき、その機器において、トランスポート層よりも上位のプロトコルスタックで確認用パケットが破棄されるため、疎通確認のためのパケット転送が、意図せぬ不都合を生じさせるのを防止することができる

なお、本実施形態におけるＯＦＣ連携部３４および確認結果判定部３６が、特許請求の範囲における「判定部」の一例である。

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

１‥疎通確認装置、１０‥ＣＰＵ、３０‥疎通確認要求受信部、３２‥確認用パケット生成部、３４‥ＯＦＣ連携部、３６‥確認結果判定部、３８‥確認結果送信部、４０‥試験管理情報、１００‥ＯＦＣ、２００‥トポロジ管理装置

Claims (8)

1. 転送部毎に任意の転送ルールを設定可能なネットワークについて、通信の疎通を確認すべき疎通確認区間の指定を受け付ける受付部と、
   前記指定を受け付けた疎通確認区間における前記転送ルールに応じた確認用データを生成する生成部と、
   前記生成部により生成された確認用データを前記疎通確認区間の起点である前記転送部に送出し、返信された前記確認用データを参照して前記疎通確認区間において疎通が正常になされているか否かを判定する判定部と、
   を備える疎通確認装置。
2. 請求項１記載の疎通確認装置であって、
   前記生成部は、前記ネットワーク外の機器が前記確認用データを受信したとき、該機器において、トランスポート層よりも上位のプロトコルスタックで前記確認用データが破棄されるように、前記確認用パケットを生成する、
   疎通確認装置。
3. 請求項１または２記載の疎通確認装置であって、
   前記転送部は、ＯｐｅｎＦｌｏｗスイッチであり、
   前記判定部は、ＰａｃｋｅｔＯｕｔおよびＰａｃｋｅｔＩｎの機能を用いて前記確認用データを前記疎通確認区間内で転送させる、
   疎通確認装置。
4. 請求項１から３のうちいずれか１項記載の疎通確認装置であって、
   前記生成部は、前記疎通確認区間が複数方向に分岐する分岐点を含む場合、該分岐点の次の転送部で前記疎通確認区間を分割した仮区間のそれぞれについて前記確認用データを生成し、
   前記判定部は、前記仮区間のそれぞれに、対応する前記確認用データを送出し、前記仮区間のそれぞれについて疎通が正常になされているか否かを判定する、
   疎通確認装置。
5. 請求項１から４のうちいずれか１項記載の疎通確認装置であって、
   前記確認用データとは異なるデータを前記ネットワーク内の転送部に送信し、該データを送信した転送部からの返信を確認することによって、前記ネットワーク内の転送部との間の疎通を確認することを、定期的に行う、
   疎通確認装置。
6. 請求項１から５のうちいずれか１項記載の疎通確認装置と、
   前記転送部と、
   前記転送部に対して転送ルールを設定するコントローラと、
   を備えるネットワークシステム。
7. コンピュータが、
   転送部毎に任意の転送ルールを設定可能なネットワークについて、通信の疎通を確認すべき疎通確認区間の指定を受け付け、
   前記指定を受け付けた指定確認区間における前記転送ルールに応じた確認用データを生成し、
   前記生成部により生成された確認用データを前記ネットワークに送出し、返信された前記確認用データを参照して前記疎通確認区間において疎通が正常になされているか否かを判定する、
   疎通確認方法。
8. コンピュータに、
   転送部毎に任意の転送ルールを設定可能なネットワークについて、通信の疎通を確認すべき疎通確認区間の指定を受け付けさせ、
   前記指定を受け付けた指定確認区間における前記転送ルールに応じた確認用データを生成させ、
   前記生成部により生成された確認用データを前記ネットワークに送出させ、返信された前記確認用データを参照して前記疎通確認区間において疎通が正常になされているか否かを判定させる、
   疎通確認プログラム。

Images