特許 7188156 通信システム、および、導通確認方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-12-05

(45)【発行日】2022-12-13

(54)【発明の名称】通信システム、および、導通確認方法

(51)【国際特許分類】

   H04L 45/0377 20220101AFI20221206BHJP

   H04L 43/10 20220101ALI20221206BHJP

【ＦＩ】

H04L45/0377

H04L43/10

【請求項の数】 3

(21)【出願番号】P 2019020597

(22)【出願日】2019-02-07

(65)【公開番号】P2020129715

(43)【公開日】2020-08-27

【審査請求日】2021-06-02

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】三好 勇樹

(72)【発明者】

【氏名】工藤 伊知郎

(72)【発明者】

【氏名】大澤 浩

(72)【発明者】

【氏名】鈴木 裕志

(72)【発明者】

【氏名】西岡 孟朗

(72)【発明者】

【氏名】林 裕平

【審査官】羽岡 さやか

(56)【参考文献】

【文献】米国特許出願公開第２００９／００３７７１３（ＵＳ，Ａ１）

【文献】特開２０１６－２２５８７７（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１８／０１３１５９０（ＵＳ，Ａ１）

【文献】特開２０１６－１４６５５５（ＪＰ，Ａ）

【文献】特開２０１６－１４９６９２（ＪＰ，Ａ）

【文献】特開２０１５－１５４２５２（ＪＰ，Ａ）

【文献】J. Halpern, Ericsson et al.，Service Function Chaining (SFC) Architecture，Request for Comments: 7665，Internet Engineering Task Force (IETF)，2015年10月31日，P.1-32

【文献】Y. Jiang et al.，Fault Management in Service Function Chaining，draft-jxc-sfc-fm-02.txt，2015年07月06日，P.1-13

【文献】P. Quinn et al.，Network Service Header (NSH)，Request for Comments: 8300，2018年01月，P.1-40

【文献】三好 勇樹 Yuki MIYOSHI，ＢＧＰＦｌｏｗｓｐｅｃおよびＶＲＦを用いたサービスチェイニング実現方式における，導通確認試験方式，電子情報通信学会２０１９年総合大会講演論文集 通信２ PROCEEDINGS OF THE 2019 IEICE GENERAL CONFEREN，2019年03月05日，P.12，B-6-12

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ １２／００－４５／８５１

(57)【特許請求の範囲】

【請求項1】

サービスチェインを構成する１以上のサービス装置と、前記サービスチェインを構成するサービス装置の導通確認を行う導通確認装置とを備える通信システムであって、
前記導通確認装置は、
所定のフラグと導通確認の対象となるサービスチェインのユーザのユーザ属性情報とを付与した導通確認パケットを生成し、生成した導通確認パケットを、前記導通確認パケットのTTL（Time to live）値を１から前記サービスチェインを構成するサービス装置の数まで増やしながら、前記サービスチェインの入口となるサービス装置に接続されるエッジルータへ送信するパケット生成部と、
前記サービスチェインを構成するサービス装置それぞれからSNMP（Simple Network Management Protocol）により当該サービス装置における前記導通確認パケットの受信数を示す情報を取得するメッセージ受信部と、
前記サービス装置それぞれから送信された、前記導通確認パケットの受信数を示す情報に基づき、前記導通確認パケットがどのサービス装置を経由したかを示す経路を特定し、前記特定した経路が、前記導通確認の対象となるサービスチェインの経路と同じか否かを判定する判定部と、
を備え、
前記サービス装置は、
前記所定のフラグが付与された導通確認パケットの受信数をカウントするカウント部と、
SNMPにより前記導通確認パケットの受信数を示す情報の取得要求を受け付けると、当該取得要求に応じて、前記導通確認パケットの受信数を示す情報を前記導通確認装置へ送信するメッセージ送信部と、
受信した前記導通確認パケットのTTL値を１減算し、減算の結果、TTL値が１以上である前記導通確認パケットを、当該導通確認パケットに付与されたユーザ属性情報に基づき、前記サービスチェインの次のサービス装置へ転送する転送部と、
を備えることを特徴とする通信システム。

【請求項2】

前記所定のフラグは、
前記導通確認パケットのＩＰヘッダ領域に付与される
ことを特徴とする請求項１に記載の通信システム。

【請求項3】

サービスチェインを構成する１以上のサービス装置と、前記サービスチェインの導通確認を行う導通確認装置とを備える通信システムにおいて実行される導通確認方法であって、
前記導通確認装置が、
所定のフラグと導通確認の対象となるサービスチェインのユーザのユーザ属性情報とを付与した導通確認パケットを生成し、生成した導通確認パケットを、前記導通確認パケットのTTL（Time to live）値を１から前記サービスチェインを構成するサービス装置の数まで増やしながら、前記サービスチェインの入口となるサービス装置に接続されるエッジルータへ送信するステップと、
前記サービス装置が、
前記所定のフラグが付与された導通確認パケットの受信数をカウントするステップと、
SNMP（Simple Network Management Protocol）により前記導通確認パケットの受信数を示す情報の取得要求を受け付けると、当該取得要求に応じて、前記導通確認パケットの受信数を示す情報を前記導通確認装置へ送信するステップと、
受信した前記導通確認パケットのTTL値を１減算し、減算の結果、TTL値が１以上である前記導通確認パケットを、当該導通確認パケットに付与されたユーザ属性情報に基づき、前記サービスチェインの次のサービス装置へ転送するステップと、
前記導通確認装置が、
前記サービスチェインを構成するサービス装置それぞれからSNMPにより当該サービス装置における前記導通確認パケットの受信数を示す情報を取得するステップと、
前記サービス装置それぞれから送信された、前記導通確認パケットの受信数を示す情報に基づき、前記導通確認パケットがどのサービス装置を経由したかを示す経路を特定し、前記特定した経路が、前記導通確認の対象となるサービスチェインの経路と同じか否かを判定するステップと、
を含むことを特徴とする導通確認方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信システム、および、導通確認方法に関する。

【背景技術】

【0002】

従来から、仮想化されたコンピュータネットワークを利用するために必要な機能（サービス）を柔軟に選択して設定できるサービスチェイニングが提案されている。

【0003】

ＩＰルーティングによりサービスチェイニングを行う場合、サービスチェイニングの対象となるサービス群に接続されるエッジルータが、受信したトラフィックからユーザ属性を判断し、判断したユーザ属性に応じて、使用されるサービス群とそれらを連結するネットワーク経路とを決定する。これにより、トラフィックのユーザ属性に応じたサービス提供を実現できる。

【0004】

このサービスチェイニングにおいて、各サービスが運用者の意図する通りにチェイニングされているかを導通試験等により確認する必要がある。

【先行技術文献】

【非特許文献】

【0005】

【文献】RFC7665（サービスチェイニング）、［平成31年1月25日検索］、インターネット＜URL：https://tools.ietf.org/html/rfc7665＞

【文献】RFC8300（Network Service Header (NSH)）、［平成31年1月25日検索］、インターネット＜URL：https://tools.ietf.org/html/rfc8300＞

【発明の概要】

【発明が解決しようとする課題】

【0006】

ここで、動的に形成されたサービスチェインにおいて、各サービスが運用者の意図する通りにチェイニングされているかを従来の導通試験等により確認することが困難であるという問題がある。

【0007】

例えば、サービスチェインの導通試験のため、pingを実施する場合を考える。この場合、エッジルータからサービスチェインの最後のサービス宛に導通確認パケットを送信することで、最後のサービスにパケットが到達したことは確認できるが、どのサービスを経由して最後のサービスまで到達したかを確認することはできない（問題１）。

【0008】

また、サービスチェインにおける各サービスはNFV（Network Functions Virtualization）技術により動的に生成・削除される。そのため、サービス情報（各サービスのＩＰアドレス等）も動的に変更されるので、導通試験を行うためには、変更される都度、サービス情報の確認が必要になる（問題２）。

【0009】

さらに、問題１，２を解決するため、導通確認パケットに専用のヘッダ（Network Service Header (NSH)）を実装した専用プロトコルが提案されているが、サービスチェインの作成に上記の専用プロトコルが実装された装置を使う必要がある（問題３）。

【0010】

そこで、本発明は、前記した問題を解決し、動的に形成されたサービスチェインにおいて、各サービスが運用者の意図する通りにチェイニングされているかを容易に確認できるようにすることを課題とする。

【課題を解決するための手段】

【0011】

前記した課題を解決するため、本発明は、サービスチェインを構成する１以上のサービス装置と、前記サービスチェインを構成するサービス装置の導通確認を行う導通確認装置とを備える通信システムであって、前記導通確認装置は、所定のフラグと導通確認の対象となるサービスチェインのユーザのユーザ属性情報とを付与した導通確認パケットを生成し、生成した導通確認パケットを、前記サービスチェインの入口となるサービス装置に接続されるエッジルータへ送信するパケット生成部と、前記サービスチェインを構成するサービス装置それぞれから前記導通確認パケットの受信を示す情報を受信するメッセージ受信部と、前記サービス装置それぞれから送信された、前記導通確認パケットの受信を示す情報に基づき、前記導通確認パケットがどのサービス装置を経由したかを示す経路を特定し、前記特定した経路が、前記導通確認の対象となるサービスチェインの経路と同じか否かを判定する判定部とを備え、前記サービス装置は、所定のフラグが付与された導通確認パケットを受信した場合、前記導通確認パケットの受信を示す情報を前記導通確認装置へ送信するメッセージ送信部と、受信した前記導通確認パケットに付与されたユーザ属性情報に基づき、前記導通確認パケットを前記サービスチェインの次のサービス装置へ転送する転送部と、備えることを特徴とする。

【発明の効果】

【0012】

本発明によれば、動的に形成されたサービスチェインにおいて、各サービスが運用者の意図する通りにチェイニングされているかを容易に確認することができる。

【図面の簡単な説明】

【0013】

【図1】図１は、第１の実施形態における通信システムの概要を説明する図である。

【図2】図２は、第１の実施形態における通信システムの動作例を説明する図である。

【図3】図３は、第１の実施形態における導通確認装置の構成例を示す図である。

【図4】図４は、第１の実施形態における導通確認装置の処理手順の例を示すフローチャートである。

【図5】図５は、第２の実施形態における通信システムの動作例を説明する図である。

【図6】図６は、導通確認プログラムを実行するコンピュータの例を示す図である。

【発明を実施するための形態】

【0014】

以下、図面を参照しながら、本発明を実施するための形態（実施形態）を第１の実施形態および第２の実施形態に分けて説明する。本発明は、以下に説明する各実施形態に限定されない。

【0015】

［第１の実施形態］
［概要］
まず、図１および図２を用いて、第１の実施形態の通信システムの概要を説明する。通信システムは、図１に示すように、導通確認装置１０と、チェイニングコントローラ２０と、エッジルータ３０と、サービスチェインを構成する１以上のサービス（サービス装置）４０とを備える。例えば、通信システムは、Ｎ個のサービス４０（サービス４０－１～サービス４０－Ｎ）を備え、これらのサービス４０の組み合わせによりサービスチェインが構成される。サービスチェインを構成するサービス４０は、例えば、認証サービスやファイアウォール機能を提供する装置であり、NFV技術により動的に生成・削除される。

【0016】

導通確認装置１０は、所定のフラグと導通確認の対象となるサービスチェインのユーザのユーザ属性とを付与した導通確認パケットを用いて、サービスチェインの導通確認を行う。

【0017】

チェイニングコントローラ２０は、サービスチェインに関する各種情報を記憶する。例えば、チェイニングコントローラ２０は、トラフィックのユーザ属性を判断する方法、当該トラフィックに適用するサービス４０に関する情報を記憶する。一例を挙げると、チェイニングコントローラ２０は、サービスチェインごとに当該サービスチェインの対象となるトラフィックのユーザ属性（例えば、5tuple等のヘッダ情報）と、当該サービスチェインを構成するサービス４０の識別情報（サービス情報）とを記憶する。

【0018】

サービス４０は、サービスチェインにおいて仮想化されたコンピュータネットワークを利用するために必要な機能（サービス）を提供する装置（サービス装置）である。各サービス４０は、メッセージ送信部および転送部（図示省略）を備える。メッセージ送信部は、所定のフラグが付与された導通確認パケットを受信した場合、当該導通確認パケットの受信を通知するメッセージを導通確認装置１０へ送信する。転送部は受信した導通確認パケットをサービスチェインの次のサービス４０へ転送する。各サービス４０は、例えば、所定の監視ネットワーク（図２参照）経由で導通確認装置１０と接続される。

【0019】

エッジルータ３０は、外部ネットワーク（図２参照）とサービス４０との境界に設置されるルータである。エッジルータ３０は、チェイニングコントローラ２０からユーザ属性とサービス情報とを取得する。その後、エッジルータ３０は、外部ネットワークから受信したトラフィックのパケットのユーザ属性と、上記の取得したユーザ属性とサービス情報とに基づき、当該パケットが経由すべき後段のサービス４０群を決定する。

【0020】

そして、エッジルータ３０は、当該パケットが後段のサービス４０群を経由するためのネットワーク経路を決定する。例えば、エッジルータ３０は、パケットを受信すると、そのパケットのネットワーク経路を決定し、そのネットワーク経路の入口（つまり、当該サービスチェインの入口）となるサービス４０に当該パケットを転送する。その後、当該パケットは、上記のネットワーク経路をたどりサービスチェインの最後のサービス４０まで流れる。

【0021】

導通確認装置１０は、チェイニングコントローラ２０から、導通確認の対象となるサービスチェインのユーザのユーザ属性（ユーザ属性情報）、サービス情報（当該サービスチェインを構成するサービス４０を示した情報）を取得する。そして、導通確認装置１０は、ユーザの実ドラフィックと同様のユーザ属性を付与した導通確認パケットをエッジルータ３０から流す。なお、この導通確認パケットには、実トラフィックと区別するためのフラグを挿入する。導通確認パケットはサービスチェイン設定により、経路上の各サービス４０を意識することなく最終サービス（例えば、サービス４０－Ｎ）まで流れる。例えば、導通確認装置１０が、エッジルータ３０へ送信した導通確認パケットは、エッジルータ３０から、サービス４０－１からサービス４０－Ｎに到達する。

【0022】

ここで、図２を用いて、通信システムの動作例を詳細に説明する。例えば、導通確認装置１０は、チェイニングコントローラ２０から、導通確認の対象となるサービスチェインのユーザ属性、サービス情報を取得する（Ｓ１）。その後、導通確認装置１０は、所定のフラグとＳ１で取得したユーザ属性とを付与した導通確認パケットを生成し、エッジルータ３０へ送信する（Ｓ２）。また、エッジルータ３０は、チェイニングコントローラ２０からユーザ属性、サービス情報を取得する（Ｓ３）。その後、エッジルータ３０が導通確認パケットを受信すると、Ｓ３で取得した情報と、当該導通確認パケットに付与されたユーザ属性により、後段のサービス群とネットワーク経路とを決定し（Ｓ４）、サービス群の最初のサービス４０（例えば、サービス４０－１）へ導通確認パケットを送信する（Ｓ５）。

【0023】

Ｓ５の後、各サービス４０は、フラグが付与された導通確認パケットを後段の各サービス４０へ転送するとともに、導通確認パケットが到着したことを示すメッセージを導通確認装置１０へ送信する。

【0024】

例えば、サービス４０－１が導通確認パケットを受信すると、サービス４０－１に導通確認パケットが到着したことを示すメッセージを導通確認装置１０へ送信する（Ｓ６）。また、サービス４０－５が、サービス４０－１から転送された導通確認パケットを受信すると、サービス４０－５に導通確認パケットが到達したことを示すメッセージ（到達メッセージ）を導通確認装置１０へ送信する（Ｓ７）。なお、フラグのある導通確認パケットは、サービスチェインの最後のサービス４０（例えば、サービス４０－５）において破棄される。

【0025】

そして、導通確認装置１０は、各サービス４０から送信された到達メッセージをもって試験良好か否かを判定する（Ｓ８）。例えば、導通確認装置１０は、Ｓ１で取得したサービス情報から得られた、導通確認の対象となるサービスチェインの経路がサービス４０－１→サービス４０－５である場合を考える。この場合、導通確認装置１０は、到達メッセージそれぞれの送信元のサービス４０およびタイムスタンプの値に基づき特定した導通確認パケットの経路を特定し、特定した経路がサービス４０－１→サービス４０－５であれば、試験良好（各サービス４０が運用者の意図する通りにチェイニングされている）と判定する。

【0026】

［構成］
次に、図３を用いて、導通確認装置１０の構成例を説明する。導通確認装置１０は、例えば、図３に示すように入出力部１１と、記憶部１２と、制御部１３とを備える。

【0027】

入出力部１１は、ネットワーク経由で各種データを入出力するためのインタフェースを司る。例えば、入出力部１１は、インターネット等の外部ネットワーク経由で導通確認パケットを送信したり、監視ネットワーク経由で到達メッセージ等を受信したりするためのインタフェースを司る。

【0028】

記憶部１２は、制御部１３が各種処理を実行する際に参照する各種情報を記憶する。制御部１３は、導通確認装置１０全体の制御を行う。制御部１３は、例えば、パケット生成部１３１と、メッセージ受信部１３２と、判定部１３３とを備える。

【0029】

パケット生成部１３１は、導通確認パケットであることを示す所定のフラグと確認対象となるサービスチェインのユーザのユーザ属性とを付与した導通確認パケットを生成し、エッジルータ３０へ送信する。

【0030】

例えば、パケット生成部１３１は、チェイニングコントローラ２０から、導通確認の対象となるサービスチェインのユーザのユーザ属性、サービス情報を取得する。そして、パケット生成部１３１は、取得したユーザ属性情報および所定のフラグを付与した導通確認パケットを生成し、エッジルータ３０へ送信する。なお、上記の所定のフラグは、例えば、導通確認パケットのＩＰヘッダ領域に付与される。また、パケット生成部１３１は、チェイニングコントローラ２０から取得した導通確認の対象となるサービスチェインのサービス情報（サービスチェインにおいて経由するサービス４０を示した情報）を記憶部１２に記憶する。

【0031】

メッセージ受信部１３２は、サービス４０それぞれから当該サービス４０における導通確認パケットの受信を通知する情報（例えば、到達メッセージ）を受信する。

【0032】

判定部１３３は、サービス４０それぞれから送信された、導通確認パケットの受信を示す情報（例えば、到達メッセージ）に基づき、導通確認パケットがどのサービス４０を経由したかを示す経路を特定する。そして、判定部１３３は、特定した経路が、導通確認の対象となるサービスチェインの経路と同じか否かを判定する。

【0033】

例えば、記憶部１２に記憶されたサービス情報の示す、サービスチェインにおいて経由するサービス４０が、サービス４０－１→サービス４０－５である場合を考える。

【0034】

ここで、メッセージ受信部１３２がサービス４０－１からの到達メッセージとサービス４０－５からの到達メッセージとを受信したとき、判定部１３３は、到達メッセージそれぞれの送信元のサービス４０およびタイムスタンプの値に基づき、導通確認パケットの経路がサービス４０－１→サービス４０－５であることを特定する。この経路は、上記の記憶部１２に記憶された導通確認の対象となるサービスチェインの経路（サービス４０－１→サービス４０－５）と同じであるので、判定部１３３は、各サービス４０が運用者の意図する通りにチェイニングされていると判定する。一方、判定部１３３が特定した経路が上記の記憶部１２に記憶された導通確認の対象となるサービスチェインの経路（サービス４０－１→サービス４０－５）と同じではない場合、判定部１３３は、各サービスが運用者の意図する通りにチェイニングされていないと判定する。そして、判定部１３３は、上記の判定の結果を、例えば、入出力部１１経由で外部に出力する。

【0035】

［処理手順］
次に、図４を用いて導通確認装置１０の処理手順の例を説明する。まず、導通確認装置１０のパケット生成部１３１は、チェイニングコントローラ２０から、導通確認の対象となるサービスチェインのユーザのユーザ属性、サービス情報を取得する（Ｓ２１）。そして、パケット生成部１３１は、Ｓ２１で取得したユーザ属性と、所定のフラグとを付与した導通確認パケットを生成し、エッジルータ３０へ送信する（Ｓ２２）。

【0036】

Ｓ２２の後、メッセージ受信部１３２が、各サービス４０から、導通確認パケットが到達したことを示すメッセージ（到達メッセージ）を受信すると（Ｓ２３）、判定部１３３は、Ｓ２３で受信した到達メッセージに基づき、導通確認パケットが経由したサービスの経路を特定する（Ｓ２４）。

【0037】

そして、判定部１３３は、Ｓ２４で特定した経路が、導通確認の対象のサービスチェインの経路と同じか否かを判定する（Ｓ２５）。つまり、判定部１３３は、Ｓ２４で特定した経路が、Ｓ２１で取得したサービス情報の示すサービスチェインの経路と同じか否かを判定する。ここで、判定部１３３は、Ｓ２４で特定した経路が、導通確認の対象のサービスチェインの経路と同じと判定した場合（Ｓ２５でＹｅｓ）、運用者の意図通りにチェイニングされていると判定する（Ｓ２６）。一方、判定部１３３は、Ｓ２４で特定した経路が、導通確認の対象のサービスチェインの経路と同じではない判定した場合（Ｓ２５でＮｏ）、判定部１３３は、運用者の意図通りにチェイニングされていないと判定する（Ｓ２７）。

【0038】

このようにすることで、動的に形成されたサービスチェインについて、導通確認装置１０は、各サービス４０が運用者の意図する通りにチェイニングされているかを容易に確認できる。

【0039】

［第２の実施形態］
次に、図５を用いて第２の実施形態の通信システムを説明する。第２の実施形態の通信システムの導通確認装置１０は、異なるTTL値を設定した導通確認パケットを送信し、各サービス４０において当該導通確認パケットをカウントするパケットカウンタの値を確認することにより、各サービス４０が運用者の意図する通りにチェイニングされているか否かを以下のようにして確認する。

【0040】

例えば、導通確認装置１０は、まず、導通確認パケットのTTL（Time to live）値を、１からＮ（サービスチェインを構成するサービス４０の数）まで増やしながら、エッジルータ３０へ送信する。エッジルータ３０は、導通確認装置１０から送信された導通確認パケット群をサービスチェインの入口となるサービス４０へ転送する。そして、各サービス４０は、導通確認パケットを受信すると、パケットカウンタの値をインクリメントする。

【0041】

その後、導通確認装置１０は、各サービス４０のパケットカウンタの値を取得し、取得した各サービス４０のパケットカウンタの値から、導通確認パケットの経路を特定する。そして、導通確認装置１０は、特定した経路が、当該ユーザ属性に対応するサービスチェインの経路と同じであれば、運用者の意図通りにチェイニングされていると判定する。

【0042】

図５を用いて、第２の実施形態の通信システムの例を具体的に説明する。ここでも、確認対象のサービスチェインの経路は、図２と同様、サービス４０－１→サービス４０－５である場合を例に説明する。

【0043】

まず、導通確認装置１０のパケット生成部１３１は、図２のＳ１と同様に、チェイニングコントローラ２０から、導通確認の対象となるサービスチェインのユーザのユーザ属性、サービス情報を取得する（Ｓ１１）。

【0044】

そして、パケット生成部１３１は、Ｓ１１で取得したユーザ属性と、所定のフラグとを付与した導通確認パケットを生成し、エッジルータ３０へ送信する。ここで、パケット生成部１３１は、導通確認パケットのTTL値を１からサービスチェインを構成するサービス数であるＮまで増やしながら、エッジルータ３０へ送信する。例えば、導通確認の対象となるサービスチェイン上のサービス４０が２個なので、パケット生成部１３１は、TTL値が１と２のパケット（導通確認パケット）を生成し、エッジルータ３０へ送信する（Ｓ１２）。

【0045】

図５のＳ１３～Ｓ１５は、図２のＳ３～Ｓ５と同様なので説明を省略する。Ｓ１５の後、各サービス４０は、所定のフラグが挿入された導通確認パケットを受信すると、パケットカウンタの値を１増加させる。また、各サービス４０は、受信した導通確認パケットのTTL値を１減少させる。そして、各サービス４０は、減少させたTTL値が１以上である導通確認パケットをサービスチェインの次のサービス４０へ転送する。

【0046】

例えば、図５に示すサービス４０－１が、TTL値＝１の導通確認パケットと、TTL値＝２の導通確認パケットとを受信した場合、パケットカウンタの値を＋２にする。そして、サービス４０－１は、それぞれの導通確認パケットのTTL値を１減少させる。すなわち、サービス４０－１は、TTL値＝１の導通確認パケットのTTL値を「０」にし、TTL値＝２の導通確認パケットのTTL値を「１」にする。そして、サービス４０－１は、TTL値が「０」となった導通確認パケットを廃棄し、TTL値が「１」となった導通確認パケットをサービスチェインの次のサービス４０－５へ転送する。

【0047】

その後、サービス４０－５が、TTL値＝１の導通確認パケットを受信すると、パケットカウンタの値を「＋１」にする。また、サービス４０－５は、TTL値＝１の導通確認パケットのTTL値を「０」にする。そして、サービス４０－５は、TTL値が「０」になった導通確認パケットを廃棄する。なお、サービス４０－２，４０－３，４０－４には、導通確認パケットが到達しないので、パケットカウンタの値は「±０」である。

【0048】

その後、導通確認装置１０は、SNMP（Simple Network Management Protocol）等で、パケットカウンタの値を各サービス４０から取得する（Ｓ１５）。例えば、導通確認装置１０のメッセージ受信部１３２は、SNMPで、サービス４０－１～４０－５からパケットカウンタの値を取得する。その結果、メッセージ受信部１３２は、サービス４０－１は「＋２」、サービス４０－２，４０－３，４０－４は「±０」、サービス４０－５は「＋１」という情報を得る。これにより、導通確認装置１０の判定部１３３は、導通確認パケットが、エッジルータ３０→サービス４０－１（パケットカウンタの値「＋２」）→サービス４０－５（パケットカウンタの値「＋１」）と流れていることを確認することができる（Ｓ１６）。

【0049】

つまり、サービス４０－１→サービス４０－５という経路は、記憶部１２に記憶された導通確認の対象となるサービスチェインの経路（サービス４０－１→サービス４０－５）と同じであるので、判定部１３３は、各サービス４０が運用者の意図する通りにチェイニングされていると判定する。一方、判定部１３３が、サービス４０－１～４０－５から取得したパケットカウンタの値に基づき特定した経路が、記憶部１２に記憶された導通確認の対象となるサービスチェインの経路（サービス４０－１→サービス４０－５）と同じではない場合、各サービス４０が運用者の意図する通りにチェイニングされていないと判定する。

【0050】

以上説明した導通確認装置１０は、SNMPを用いて導通確認パケットの経路を確認するので、各サービス４０に、導通確認パケットの到達メッセージを送信するよう設定する必要がなくなる。よって、導通確認装置１０は、各サービス４０が運用者の意図する通りにチェイニングされているかをより容易に確認することができる。

【0051】

［プログラム］
また、上記の実施形態で述べた導通確認装置１０の機能を実現するプログラムを所望の情報処理装置（コンピュータ）にインストールすることによって実装できる。例えば、パッケージソフトウェアやオンラインソフトウェアとして提供される上記のプログラムを情報処理装置に実行させることにより、情報処理装置を導通確認装置１０として機能させることができる。ここで言う情報処理装置には、デスクトップ型またはノート型のパーソナルコンピュータ、ラック搭載型のサーバコンピュータ等が含まれる。また、その他にも、情報処理装置にはスマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）等の移動体通信端末、さらには、ＰＤＡ（Personal Digital Assistant）等がその範疇に含まれる。また、導通確認装置１０を、クラウドサーバに実装してもよい。

【0052】

図６を用いて、上記の導通確認プログラムを実行するコンピュータの一例を説明する。図６に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。

【0053】

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１およびＲＡＭ（Random Access Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。

【0054】

ここで、図６に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。前記した実施形態で説明した各種データや情報は、例えばハードディスクドライブ１０９０やメモリ１０１０に記憶される。

【0055】

そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。

【0056】

なお、上記のプログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、上記のプログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮやＷＡＮ（Wide Area Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

【符号の説明】

【0057】

１０ 導通確認装置
１１ 入出力部
１２ 記憶部
１３ 制御部
１３１ パケット生成部
１３２ メッセージ受信部
１３３ 判定部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】