JP6926734B2 - 経路制御装置および経路制御方法 - Google Patents

Description

本発明は、トラフィックフローが通過する経路を制御する装置および方法に係わる。

近年、端末からアプリケーションへのアクセス遅延を削減するために、クラウド上ではなくエッジサーバにアプリケーションを配置する構成が実用化されている。この場合、エッジサーバは、トラフィックフローがエッジサーバ内に配置されている１または複数のアプリケーションを通過するように経路制御を実行する。また、エッジサーバは、必要に応じて、そのトラフィックフローをクラウド上に配置されている他のアプリケーション（例えば、業務アプリケーション等）に導く。なお、モバイルネットワークにおいては、エッジサーバは、例えば、基地局の近くに配置される。

図１は、エッジサーバを備えるネットワークの一例を示す。図１に示す例では、組織Ａの業務アプリケーション３００がクラウド上に配置されている。なお、「組織」は、例えば、企業または法人に相当する。組織Ａに属する端末１００は、エッジサーバ２００に収容されている。なお、エッジサーバ２００は、組織Ａとは異なる組織Ｄにより管理および運用されている。エッジサーバ２００を管理および運用する組織Ｄは、例えば、通信キャリア（モバイルネットワークにおいては、携帯電話事業者）に相当する。そして、端末１００は、エッジサーバ２００を介して業務アプリケーション３００にアクセスすることができる。

エッジサーバ２００は、複数のアプリケーションを収容できる。図１に示す例では、エッジサーバ２００は、組織Ａのアプリケーション＃１、および組織Ｂのアプリケーション＃２、＃３を収容している。また、エッジサーバ２００は、経路指定受付部２０１および経路制御部２０２を備える。経路指定受付部２０１は、トラフィックフローの経路を指定する経路指定情報を受け付ける。経路制御部２０２は、経路指定受付部２０１が受け付けた経路指定情報に従って、トラフィックフローの経路を制御する。

例えば、端末１００から業務アプリケーション３００へのアクセスは、以下のポリシを満足することが推奨されるものとする。
（１）アプリケーション＃１により事前処理を実行する
（２）アプリケーション＃１の前にアプリケーション＃２によるセキュリティ処理を実行する
（３）アプリケーション＃２の前にアプリケーション＃３によるフィルタ処理を実行する
この場合、端末１００から業務アプリケーション３００へ向かうフローは、順番に、アプリケーション＃３、アプリケーション＃２、アプリケーション＃１を通過するように制御される。

なお、関連する技術は、例えば、特許文献１、２に開示されている。

特開２００４−１５７７１３号公報 特開２０１７−４１８４６号公報

上述したネットワークにおいて、エッジサーバ２００内でのトラフィックフローの経路は、例えば、端末１００から指定される。ただし、端末１００は、端末１００が属する組織以外の組織のアプリケーションを認識していないことがある。図１に示す例では、端末１００は、組織Ｂのアプリケーション＃２、＃３を認識していないかも知れない。この場合、アプリケーション＃２、＃３を通過するトラフィックフローを生成することはできない。

この問題は、例えば、上述したポリシ（２）（３）を事前に端末１００に通知しておけば解決され得る。ただし、この場合、セキュリティ対策を行うか否かが端末により判断されることになるので、好ましい運用形態ではない。

また、組織Ａの管理者は、通常、組織Ｂのアプリケーションの構成を把握していない。例えば、組織Ａと組織Ｂとの間で組織Ｂのセキュリティソフト（ここでは、アプリケーション＃２）を使用する契約が結ばれたものとする。ただし、組織Ａの管理者は、セキュリティソフトの入力側にフィルタソフト（ここでは、アプリケーション＃３）が配置されるべきである旨を知らない。この場合、図１に示す経路を設定することは困難である。

加えて、図１に示す例では、トラフィックフローの宛先は業務アプリケーション３００である。すなわち、アプリケーション＃１は、トラフィックフローの宛先ではない。この場合、アプリケーション＃１は、トラフィックフローの経路を指定する権限を有していない。

このように、従来技術においては、エッジサーバ内でのトラフィックフローの経路の設定が困難なことがある。すなわち、従来技術においては、エッジサーバ内で所望のアプリケーションを通過するトラフィックフローの設定が困難なことがある。

本発明の１つの側面に係わる目的は、トラフィックフローの経路を柔軟に指定できる装置および方法を提供することである。

本発明の１つの態様の経路制御装置は、複数のエンティティを収容するサーバ内でトラフィックフローの経路を制御する。この経路制御装置は、前記サーバ内の所定の範囲において前記トラフィックフローの経路を指定する権限を表す制御情報を発行する発行部と、前記複数のエンティティの中の１つのエンティティから、前記トラフィックフローの経路を指定する経路指定情報および前記制御情報を受信したときに、前記経路指定情報が前記所定の範囲内で経路を指定しているか判定する受付部と、前記経路指定情報が前記所定の範囲内で経路を指定するときに、前記経路指定情報に基づいて前記トラフィックフローの経路を制御する経路制御部と、を備える。

上述の態様によれば、トラフィックフローの経路を柔軟に指定できる。

エッジサーバを備えるネットワークの一例を示す図である。 本発明の実施形態に係わるエッジサーバを含むネットワークの一例を示す図である。 経路を指定する手順の一例を示す図（その１）である。 経路を指定する手順の一例を示す図（その２）である。 図３に示す手順に対応するシーケンス図である。 図４に示す手順に対応するシーケンス図である。 トークンのフォーマットの一例を示す図である。 経路指定情報管理テーブルの例を示す図である。 経路情報テーブルの一例を示す図である。 トークンに基づいてトラフィックフローを処理する方法の一例を示す図である。 図１０に示す方法に対応するシーケンス図である。 トークン発行部の処理の一例を示すフローチャートである。 経路指定受付部の処理の一例を示すフローチャートである。 経路制御部の処理の一例を示すフローチャートである。 端末の構成の一例を示す図である。 端末管理装置の構成の一例を示す図である。 エッジサーバの構成の一例を示す図である。 エッジサーバ管理装置の構成の一例を示す図である。 他の実施形態の例を示す図である。

図２は、本発明の実施形態に係わるエッジサーバを含むネットワークの一例を示す。図２に示す例では、組織Ａの業務アプリケーション３０がクラウド上に配置されている。なお、「組織」は、例えば、企業または法人に相当する。業務アプリケーション３０は、サーバコンピュータ（目的サーバ）に実装されている。組織Ａに属する端末１０は、エッジサーバに接続することができる。図２に示す例では、端末１０は、エッジサーバ４０に収容される。エッジサーバ４０は、組織Ａとは異なる組織Ｄにより管理および運用されている。エッジサーバ４０を管理および運用する組織Ｄは、例えば、通信キャリア（モバイルネットワークにおいては、携帯電話事業者）に相当する。そして、端末１０は、エッジサーバ４０を介して業務アプリケーション３０にアクセスする。なお、以下の記載では、端末１０からクラウドへ信号を伝送するリンクを「アップリンク」と呼ぶことがある。クラウドから端末１０へ信号を伝送するリンクを「ダウンリンク」と呼ぶことがある。

端末管理装置２０は、組織Ａに属する端末を管理する。即ち、端末管理装置２０は、端末１０を含む複数の端末を管理する。例えば、端末管理装置２０は、各端末がアクセスする業務アプリケーションを認識している。図２では、端末管理装置２０は、端末１０が業務アプリケーション３０を利用することを認識している。また、端末管理装置２０は、トークン要求部２１を備える。トークン要求部２１は、エッジサーバ管理装置５０に対して後述するトークンを要求することができる。

エッジサーバ４０は、複数のアプリケーションを収容することができる。図２に示す例では、エッジサーバ４０は、組織Ａのアプリケーション＃１、組織Ｂのアプリケーション＃２、＃３、および組織Ｃのアプリケーション＃４、＃５を収容している。アプリケーション＃１は、業務アプリケーション３０の前処理を実行する。アプリケーション＃２は、セキュリティ処理を実行する。セキュリティ処理は、例えば、ファイアウォール機能を提供する。アプリケーション＃３は、フィルタ処理を実行する。アプリケーション＃４は、ログ処理を実行する。ログ処理は、エッジサーバを通過するトラフィックフローを記録する。アプリケーション＃５は、キャプチャ処理を実行する。キャプチャ処理は、エッジサーバを通過するトラフィックフロー中のパケットを保存する。

エッジサーバ４０は、経路指定受付部４１および経路制御部４２を備える。経路指定受付部４１は、エッジサーバ４０内でのトラフィックフローの経路を指定する経路指定情報を受け付ける。このとき、経路指定受付部４１は、経路指定情報により指定される経路を許可するか否かを判定する。経路制御部４２は、経路指定受付部４１が受け付けた経路指定情報に従って、トラフィックフローの経路を制御する。

エッジサーバ管理装置５０は、エッジサーバ４０を管理する。したがって、エッジサーバ管理装置５０は、エッジサーバ４０と同様に、組織Ｄにより運用される。また、エッジサーバ管理装置５０は、トークン発行部５１を備える。トークン発行部５１は、端末管理装置２０またはエッジサーバ４０からの要求に応じてトークンを発行する。尚、エッジサーバ４０およびエッジサーバ管理装置５０は、１台のコンピュータで実現してもよいし、複数のコンピュータで実現してもよい。また、エッジサーバ管理装置５０は、複数のエッジサーバ４０を管理してもよい。

上記構成のコンピューティング環境において、組織Ａは、業務アプリケーション３０へのアクセスに際して、以下のポリシを有しているものとする。なお、組織Ａと組織Ｂとの間でアプリケーション＃２の使用に関する契約が成立しているものとする。すなわち、組織Ａにとって、アプリケーション＃２は信頼できるソフトウェアである。
（Ａ１）アプリケーション＃１により事前処理を実行する。
（Ａ２）アプリケーション＃１を実行する前に組織Ｂのアプリケーション＃２によるセキュリティ処理を実行する。
したがって、アプリケーション＃１は、ポリシＡ２を満足するために、アプリケーション＃１を通過するトラフィックフローがアプリケーション＃１の前にアプリケーション＃２を通過することを指定する経路指定情報を生成する機能を備える。

組織Ｂは、アプリケーション＃２の実行に際して、以下のポリシを有しているものとする。なお、組織Ｂと組織Ｃとの間でアプリケーション＃４の使用に関する契約が成立しているものとする。すなわち、組織Ｂにとって、アプリケーション＃４は信頼できるソフトウェアである。
（Ｂ１）アプリケーション＃２を実行する前にアプリケーション＃３によるフィルタ処理を実行する。
（Ｂ２）アプリケーション＃３を実行する前に組織Ｃのアプリケーション＃４によるログ処理を実行する。
したがって、アプリケーション＃２は、ポリシＢ１およびＢ２を満足するために、アプリケーション＃２を通過するトラフィックフローがアプリケーション＃２の前にアプリケーション＃３および＃４を通過することを指定する経路指定情報を生成する機能を備える。

組織Ｃは、アプリケーション＃４の実行に際して、以下のポリシを有しているものとする。
（Ｃ１）アプリケーション＃４を実行する前にアプリケーション＃５によるキャプチャ処理を実行する。
したがって、アプリケーション＃４は、ポリシＣ１を満足するために、アプリケーション＃４を通過するトラフィックフローがアプリケーション＃４の前にアプリケーション＃５を通過することを指定する経路指定情報を生成する機能を備える。

上記構成のコンピューティング環境において、エッジサーバ４０は、エッジサーバ４０に収容される端末のトラフィックフローの経路を制御する。図２に示す例では、エッジサーバ４０は、端末１０のアップリンクトラフィックフローおよびダウンリンクトラフィックフローを、指定された１または複数のアプリケーションを通過させる。

このとき、エッジサーバ４０は、複数のトラフィックフローの中から端末１０と業務アプリケーション３０との間のトラフィックフローを識別する必要がある。ここで、トラフィックフローは、例えば、ＩＰアドレスおよびＬ４ポート番号により識別される。但し、例えば、業務アプリケーション３０がＳａａＳ（Software as a Service）として提供される場合には、複数の端末が同じ宛先ＩＰアドレスおよび宛先Ｌ４ポート番号を使用するので、宛先ＩＰアドレス／宛先Ｌ４ポート番号でトラフィックフローを識別することはできない。また、送信元ＩＰアドレスは、端末１０がネットワークに接続されるときに端末１０に動的に割り当てられる。さらに、送信元Ｌ４ポート番号は、トラフィックフローが生成されるときに、未使用のポート番号の中から動的に選択される。したがって、送信元ＩＰアドレスおよび送信元Ｌ４ポート番号でトラフィックフローを識別すること困難である。

端末１０に対して固定的に設定されている識別情報を使用すれば、エッジサーバ２０は端末１０のトラフィックフローを識別できるかも知れない。ただし、ＢＹＯＤ（Bring Your Own Device）環境においては、端末１０のトラフィックフローは、業務アプリケーション３０にアクセスするトラフィックフローだけでなく、私用のトラフィックフローを含む。よって、この場合、端末１０から業務アプリケーション３０にアクセスするトラフィックフローを識別することは困難である。

そこで、本発明の実施形態に係わる経路制御方法では、「トークン」を用いてトラフィックフローが識別される。トークンは、所定のトラフィックフローに対してエッジサーバ４０内での経路を指定するために生成される。そして、このトークンは、端末１０が業務アプリケーション３０にアクセスする際に、端末１０から送信されるパケットに付与される。また、エッジサーバ４０は、トークンが付与されたパケットを受信すると、そのトークンに対して指定されている経路を通過するようにそのパケットを処理する。この結果、エッジサーバ４０は、端末１０と業務アプリケーション３０との間のトラフックフローが所望のアプリケーションを通過するように、そのトラフックフローの経路を制御できる。

図３〜図４は、トラフィックフローの経路を指定する手順の一例を示す。また、図５〜図６は、図３〜図４に対応するシーケンス図である。

Ｓ１において、端末管理装置２０に実装されるトークン要求部２１は、エッジサーバ管理装置５０に実装されるトークン発行部５１に対してトークンを要求する。この例では、トークン要求部２１は、端末１０のＢＹＯＤ環境上の端末アプリケーションが送信または受信するトラフィックフローについての経路指定権限を代表するトークンを要求する。したがって、トークン要求部２１から要求されるトークン要求は、以下の情報を含む。
・端末ＩＤ：端末１０
・フローの識別：トークンによる

なお、ＢＹＯＤ環境においては、上述したように、トラフィックフローが設定される前は、パケットのヘッダに格納される要素（アドレス、ポート番号等）によって業務アプリケーション３０に係わるトラフィックフローを識別することはできない。よって、「フローの識別」としてトークンを使用する方法が選択される。ただし、トラフィックフローが設定される前に、パケットのヘッダに格納される要素によって業務アプリケーション３０に係わるトラフィックフローを識別できるときは、「フローの識別」としてその要素がトークン発行部５１に通知されるようにしてもよい。

Ｓ２において、トークン発行部５１は、トークン要求部２１から要求されたトークンを発行（または、生成）する。トークン発行部５１により発行されるトークンは、図７に示すように、トークンＩＤ、発行元組織ＩＤ、発行元エンティティＩＤ、発行先エンティティＩＤ、発行先組織ＩＤ、発行先エンティティＩＤ、対象エッジサーバＩＤ、対象フロー情報、対象フロー区間情報、発行時刻、有効期間、電子署名を含む。なお、「エンティティ」は、ハードウェアまたはソフトウェアに限定されるものではなく、コンピュータ処理の要素を表す。この実施例では、トークン要求部２１、経路指定受付部４１、経路制御部４２、トークン発行部５１は、それぞれ１つのエンティティである。また、各アプリケーションは、それぞれ１つのエンティティである。

トークンＩＤは、各トークンを識別する。なお、トークンＩＤは、例えば、シリアル番号により実現される。

発行元組織ＩＤは、トークンを発行する組織を識別する。この例では、トークン発行部５１を備えるエッジサーバ管理装置５０は、組織Ｄにより管理されている。よって、発行元組織ＩＤは、組織Ｄを表す。また、発行元エンティティＩＤは、トークンを発行するエンティティを識別する。この例では、発行元エンティティＩＤは、エッジサーバ管理装置５０を表す。

発行先組織ＩＤは、トークンの発行先の組織を識別する。即ち、発行先組織ＩＤは、トークンを要求してきた組織を識別する。発行先エンティティＩＤは、トークンの発行先のエンティティを識別する。即ち、発行先エンティティＩＤは、トークンを要求してきたエンティティを識別する。例えば、Ｓ２においては、端末管理装置２０からトークンが要求される。よって、発行先組織ＩＤは組織Ａを表し、発行先エンティティＩＤは端末管理装置２０を表す。

対象エッジサーバＩＤは、トークンが有効なエッジサーバを識別する。なお、トークンが複数のエッジサーバにおいて有効であるときは、そのトークンが有効な範囲が指定される。この場合、複数のエッジサーバは、例えば、ワイルドカードを用いて表される。

対象フロー情報は、トークンの権限が有効なトラフィックフローを表す。この例では、対象フロー情報は、端末ＩＤ、5tuple、トークンＩＤを含む。端末ＩＤは、対象トラフィックフローを送信または受信する端末を表す。5tupleは、ＩＰヘッダに格納される送信元ＩＰアドレス、宛先ＩＰアドレス、送信元Ｌ４ポート番号、宛先Ｌ４ポート番号、プロトコル番号を表す。5tupleの各要素は、ワイルドカードを用いて表されてもよい。トークンＩＤは、トークンを識別する。

対象フロー区間情報は、対象トラフィックフローに対して経路指定が許可される区間を表す。発行時刻は、トークンが発行された時刻を表す。有効期間は、トークンの有効期間を表す。電子署名は、「トークンＩＤ」から「有効期間」までの各フィールドの値に基づいて計算されるハッシュ値をエッジサーバ管理装置５０の秘密鍵で暗号化することにより生成される。

Ｓ２において生成されるトークンの主要な要素は、以下の通りである。なお、以下の記載において、「＃１」により識別されるトークンを「トークン＃１」と呼ぶことがある。
＜トークン＃１の内容＞
・トークンＩＤ：＃１
・対象フロー情報：トークン＃１（端末１０）
・対象フロー区間：＊＊＊
「対象フロー情報：トークン＃１」は、トークン＃１により識別されるトラフィックフローに対してトークンの権限が有効である状態を表す。「＊＊＊」は、許可される区間が指定されていない状態を表す。この場合、エッジサーバ４０内の全区間において対象トラフィックフローに対して経路指定が許可される。

Ｓ３において、トークン発行部５１は、Ｓ２で生成したトークン＃１を表すトークン情報を経路指定受付部４１に送信する。トークン情報は、図７に示す「トークンＩＤ」から「有効期間」までの各フィールドの値を表す。

Ｓ４において、トークン要求部２１は、トークン発行部５１により発行されたトークン＃１を端末１０に配布する。端末１０において、トークン＃１は、ＢＹＯＤ処理部により受信され、不図示のメモリに格納される。

Ｓ５において、トークン要求部２１は、上述した組織ＡのポリシＡ１に基づいて、業務アプリケーション３０にアクセスする際に要求されるエンティティにトークン＃１を送信する。すなわち、トークン要求部２１は、トークン発行部５１により発行されたトークン＃１をアプリケーション＃１に配布する。

Ｓ６において、アプリケーション＃１は、上述した組織ＡのポリシＡ２に基づいて、経路指定情報を生成する。すなわち、「Ａ２：アプリケーション＃１を実行する前に組織Ｂのアプリケーション＃２によるセキュリティ処理を実行する」を実現するための経路指定情報が生成される。具体的には、図３に示す経路Ｒ＃１を指定する経路指定情報が生成される。そして、アプリケーション＃１は、生成した経路指定情報を経路指定受付部４１に送信する。このとき、アプリケーション＃１は、経路指定情報と共にトークン＃１を経路指定受付部４１に送信する。

Ｓ６においてアプリケーション＃１から経路指定受付部４１に送信される経路指定情報は、例えば、下記のように表される。
＜経路指定情報＞
・経路：アプリ＃２→アプリ＃１（ＵＬ）
この例では、経路指定情報は、アップリンク上の経路を表す。ただし、トラフィックフローは、通常、アップリンクフローおよびダウンリンクフローから構成される。ダウンリンク上の経路を表すときは、経路指定情報は「アプリ＃１→アプリ＃２」である。

経路指定受付部４１は、経路指定情報により指定される経路がトークン＃１により許可されるか否かを判定する。具体的には、トークン＃１の「対象フロー区間」により許可される範囲内で経路が指定されているか否かが判定される。この例では、トークン＃１は、エッジサーバ４０内の全区間において対象トラフィックフローに対して経路指定を許可している。したがって、経路指定受付部４１は、アプリケーション＃１から受信した経路指定情報を受け付ける。このように、トークンは、エッジサーバ４０内の所定の範囲においてトラフィックフローの経路を指定する権限を表す制御情報の一例である。

図８（ａ）は、経路指定情報管理テーブルの一例を示す。経路指定情報管理テーブルは、経路指定受付部４１により生成される。そして、経路指定受付部４１は、新たな経路指定情報を受け付けたときに、対応するレコードを経路指定情報管理テーブルに追加する。

「トークンＩＤ」は、経路指定情報とともに受信したトークンを識別する。「対象フロー」は、経路指定の対象となるトラフィックフローを表し、経路指定情報とともに受信したトークンから抽出される。「経路」は、受信した経路指定情報により指定される経路を表す。よって、Ｓ６においては、下記のレコードが生成される。
・トークンＩＤ：トークン＃１
・対象フロー：トークン＃１により識別されるトラフィックフロー
・経路：アプリ＃２→アプリ＃１

なお、経路指定受付部４１は、Ｓ６でアプリケーション＃１から受信したトークンの内容を、Ｓ３でトークン発行部５１から受信したトークン情報と照合してもよい。この照合を行うことにより、経路指定受付部４１は、アプリケーション＃１から受信したトークン＃１が正規のトークンであるか否かを確認できる。すなわち、経路指定受付部４１は、不正な経路指定を排除できる。また、経路指定受付部４１は、受信したトークンの電子署名を利用して、そのトークンが改ざんされていないことを確認できる。よって、電子署名による確認だけで十分なケースでは、トークン発行部５１から経路指定受付部４１へトークン情報を送信しなくてもよい。この場合、エッジサーバ４０内のメッセージの伝送量が削減される。

上述したＳ１〜Ｓ６により、組織ＡのポリシＡ１、Ａ２を満足する経路指定が実現される。すなわち、アプリケーション＃２、＃１を順番に通過する経路指定が実現される。

ただし、アプリケーション＃２は、組織Ｂにより管理されている。そして、アプリケーション＃１は、組織Ｂのポリシを認識していない。よって、アプリケーション＃１は、組織Ｂに対して経路指定を依頼する。このとき、アプリケーション＃１は、組織Ａのポリシを満足する範囲内で、組織Ｂに対して経路指定を依頼する必要がある。そこで、アプリケーション＃１は、トークン発行部５１に対して、組織Ａのポリシを満足する範囲内で経路を指定する権限を代表するトークンを要求する。

Ｓ７において、アプリケーション＃１は、トークン発行部５１に対して、新たなトークンを要求する。このとき、アプリケーション＃１は、トークン要求と共にトークン＃１をトークン発行部５１に送信する。ここで、Ｓ７においてアプリケーション＃１からトークン発行部５１に送信されるトークン要求は、以下の情報を含む。
＜トークン要求＞
・対象フロー情報：トークン＃１（端末１０）
・対象フロー区間：＊＊＊→アプリ＃２→アプリ＃１（ＵＬ）
なお、「＊＊＊→アプリ＃２→アプリ＃１」は、アプリケーション＃２の入力側で経路を指定する権限を表す。

Ｓ８において、トークン発行部５１は、アプリケーション＃１から要求されたトークンを発行するか否かを判定する。具体的には、トークン発行部５１は、要求された経路指定範囲がトークン＃１に対して許可されている経路指定範囲の一部であるか否か判定する。この例では、要求された経路指定範囲は「アプリケーション＃２の入力側」であり、トークン＃１に対して許可されている経路指定範囲は「全区間」である。よって、トークン発行部５１は、アプリケーション＃１からの要求に対して新たなトークンを生成する。

Ｓ８において生成されるトークンの主要な要素は、以下の通りである。なお、以下の記載において、「＃２」により識別されるトークンを「トークン＃２」と呼ぶことがある。
＜トークン＃２の内容＞
・トークンＩＤ：＃２
・対象フロー情報：トークン＃１（端末１０）
・対象フロー区間：＊＊＊→アプリ＃２→アプリ＃１（ＵＬ）
なお、トークン＃２は、トークン＃１により識別されるトラフィックフローについて、アプリケーション＃２の入力側で経路を指定する権限を表す。そして、トークン発行部５１は、生成したトークン＃２をアプリケーション＃１へ送信する。

Ｓ９において、トークン発行部５１は、Ｓ８で生成したトークン＃２を表すトークン情報を経路指定受付部４１に送信する。

Ｓ１０において、アプリケーション＃１は、アプリケーション＃２にトークン＃２を送信する。すなわち、アプリケーション＃１は、トークン＃２により規定される範囲内で経路を指定する権限をアプリケーション＃２に与える。具体的には、アプリケーション＃２の入力側で経路を指定する権限がアプリケーション＃１からアプリケーション＃２に与えられる。

Ｓ１１において、アプリケーション＃２は、上述した組織ＢのポリシＢ１、Ｂ２に基づいて、経路指定情報を生成する。すなわち、「Ｂ１：アプリケーション＃２を実行する前にアプリケーション＃３によるフィルタ処理を実行する」および「Ｂ２：アプリケーション＃３を実行する前に組織Ｃのアプリケーション＃４によるログ処理を実行する」を実現するための経路指定情報が生成される。具体的には、図４に示す経路Ｒ＃２を指定する経路指定情報が生成される。そして、アプリケーション＃２は、生成した経路指定情報を経路指定受付部４１に送信する。このとき、アプリケーション＃２は、経路指定情報と共にトークン＃２を経路指定受付部４１に送信する。

Ｓ１１においてアプリケーション＃２から経路指定受付部４１に送信される経路指定情報は、例えば、下記のように表される。
＜経路指定情報＞
・経路：アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１（ＵＬ）
経路指定受付部４１は、アプリケーション＃２から受信した経路指定情報を許可するか否かを判定する。具体的には、トークン＃２の「対象フロー区間」により許可される範囲内で経路が指定されているか否かが判定される。この例では、トークン＃２は、アプリケーション＃２の入力側において対象トラフィックフローに対して経路指定を許可する。したがって、経路指定受付部４１は、アプリケーション＃２から受信した経路指定情報を受け付ける。

経路指定受付部４１は、新たな経路指定情報を受け付けたときに、対応するレコードを経路指定情報管理テーブルに追加する。Ｓ１１においては、図８（ａ）に示すように、下記のレコードが生成される。
・トークンＩＤ：トークン＃２
・対象フロー：トークン＃１により識別されるトラフィックフロー
・経路：アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１

上述したＳ７〜Ｓ１１により、組織ＢのポリシＢ１、Ｂ２を満足する経路指定が実現される。すなわち、アプリケーション＃２を実行する前にアプリケーション＃４、＃３を順番に通過する経路指定が実現される。

ただし、アプリケーション＃４は、組織Ｃにより管理されている。そして、アプリケーション＃２は、組織Ｃのポリシを認識していない。よって、アプリケーション＃２は、組織Ｃに対して経路指定を依頼する。このとき、アプリケーション＃２は、組織Ｂのポリシを満足する範囲内で、組織Ｃに対して経路指定を依頼する必要がある。そこで、アプリケーション＃２は、トークン発行部５１に対して、組織Ｂのポリシを満足する範囲内で経路を指定する権限を代表するトークンを要求する。

Ｓ１２において、アプリケーション＃２は、トークン発行部５１に対して、新たなトークンを要求する。このとき、アプリケーション＃２は、トークン要求と共にトークン＃２をトークン発行部５１に送信する。ここで、Ｓ１２においてアプリケーション＃２からトークン発行部５１に送信されるトークン要求は、以下の情報を含む。
＜トークン要求＞
・対象フロー情報：トークン＃１（端末１０）
・対象フロー区間：＊＊＊→アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１（ＵＬ）
なお、「＊＊＊→アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１」は、アプリケーション＃４の入力側で経路を指定する権限を表す。

Ｓ１３において、トークン発行部５１は、アプリケーション＃２から要求されたトークンを発行するか否かを判定する。具体的には、トークン発行部５１は、要求された経路指定範囲がトークン＃２に対して許可されている経路指定範囲の一部であるか否かを判定する。この例では、要求された経路指定範囲は「アプリケーション＃４の入力側」であり、トークン＃２に対して許可されている経路指定範囲は「アプリケーション＃２の入力側」である。よって、トークン発行部５１は、アプリケーション＃２からの要求に対して新たなトークンを生成する。

Ｓ１３において生成されるトークンの主要な要素は、以下の通りである。尚、以下の記載において、「＃３」により識別されるトークンを「トークン＃３」と呼ぶことがある。
＜トークン＃３の内容＞
・トークンＩＤ：＃３
・対象フロー情報：トークン＃１（端末１０）
・対象フロー区間：＊＊＊→アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１（ＵＬ）
なお、トークン＃３は、トークン＃１により識別されるトラフィックフローについて、アプリケーション＃４の入力側で経路を指定する権限を表す。そして、トークン発行部５１は、生成したトークン＃３をアプリケーション＃２へ送信する。

Ｓ１４において、トークン発行部５１は、Ｓ１３で生成したトークン＃３を表すトークン情報を経路指定受付部４１に送信する。

Ｓ１５において、アプリケーション＃２は、アプリケーション＃４にトークン＃３を送信する。すなわち、アプリケーション＃２は、トークン＃３により規定される範囲内で経路を指定する権限をアプリケーション＃４に与える。具体的には、アプリケーション＃４の入力側で経路を指定する権限がアプリケーション＃２からアプリケーション＃４に与えられる。

Ｓ１６において、アプリケーション＃４は、上述した組織ＣのポリシＣ１に基づいて、経路指定情報を生成する。すなわち、「Ｃ１：アプリケーション＃４を実行する前にアプリケーション＃５によるキャプチャ処理を実行する」を実現するための経路指定情報が生成される。そして、アプリケーション＃４は、生成した経路指定情報を経路指定受付部４１に送信する。このとき、アプリケーション＃４は、経路指定情報と共にトークン＃３を経路指定受付部４１に送信する。

Ｓ１６においてアプリケーション＃４から経路指定受付部４１に送信される経路指定情報は、例えば、下記のように表される。
＜経路指定情報＞
・経路：アプリ＃５→アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１（ＵＬ）
経路指定受付部４１は、アプリケーション＃４から受信した経路指定情報を許可するか否かを判定する。具体的には、トークン＃３の「対象フロー区間」により許可される範囲内で経路が指定されているか否かが判定される。この例では、トークン＃３は、アプリケーション＃４の入力側において対象トラフィックフローに対して経路指定を許可する。したがって、経路指定受付部４１は、アプリケーション＃４から受信した経路指定情報を受け付ける。

経路指定受付部４１は、新たな経路指定情報を受け付けたときに、対応するレコードを経路指定情報管理テーブルに追加する。Ｓ１６においては、図８（ａ）に示すように、下記のレコードが生成される。
・トークンＩＤ：トークン＃３
・対象フロー：トークン＃１により識別されるトラフィックフロー
・経路：アプリ＃５→アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１

上述したＳ１２〜Ｓ１６により、組織ＣのポリシＣ１を満足する経路指定が実現される。すなわち、アプリケーション＃４を実行する前にアプリケーション＃５を通過する経路指定が実現される。

Ｓ１７において、経路指定受付部４１は、受信した経路指定情報に基づいて、トラフィックフローの経路を決定する。この例では、経路指定受付部４１は、Ｓ６、Ｓ１１、Ｓ１６において経路指定情報を受け付けている。また、経路指定に必要な情報は、図８（ａ）に示す経路指定情報管理テーブルに記録されている。よって、経路指定受付部４１は、経路指定情報管理テーブルに基づいて、トークン＃１により識別されるトラフィックフローの経路を決定する。

この例では、Ｓ１６で受け付けた経路「アプリ＃５→アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１」は、Ｓ６で受け付けた経路「アプリ＃２→アプリ＃１」およびＳ１１で受け付けた経路「アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１」を含んでいる。この場合、経路指定受付部４１は、Ｓ１６で受け付けた経路を表す経路情報を経路制御部４２に通知する。このとき、経路指定受付部４１は、経路情報と共に、対象トラフィックを識別するトークンを経路制御部４２に送信する。即ち、Ｓ１６で受け付けた経路を表す経路情報およびトークン＃１が経路指定受付部４１から経路制御部４２に与えられる。なお、経路指定受付部４１は、経路指定に係わる全てのトークン（すなわち、トークン＃１〜＃３）を経路制御部４２に通知してもよい。

経路制御部４２は、経路指定受付部４１から与えられる経路情報を経路情報テーブルに格納する。経路情報テーブルは、図９に示すように、対象トラフィックフローを識別するトークンに対応づけて「経路」を格納する。この例では、トークン＃１に対して「アプリ＃５→アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１」が登録されている。また、トークン＃５に対して「アプリ＃８→アプリ＃７→アプリ＃６」が登録されている。このように、エッジサーバ４０内に格納されるアプリケーションは、トークンに対応づけてグループ化される。

経路制御部４２は、経路指定受付部４１から与えられる経路情報に基づいて対象トラフィックフローの経路を設定する。この実施例では、端末１０からクラウドに向かうアップリンクにおいて、トークン＃１により識別されるトラフィックフローに対して以下の経路設定が行われる。
・端末１０から送信されるトラフィックフローをアプリケーション＃５に導く
・アプリケーション＃５により処理されたトラフィックフローをアプリケーション＃４に導く
・アプリケーション＃４により処理されたトラフィックフローをアプリケーション＃３に導く
・アプリケーション＃３により処理されたトラフィックフローをアプリケーション＃２に導く
・アプリケーション＃２により処理されたトラフィックフローをアプリケーション＃１に導く
・アプリケーション＃１により処理されたトラフィックフローを業務アプリケーション３０に導く

このように、エッジサーバ４０は、トークンに対してグループ化された１または複数のアプリケーションを通過するように、トークンが付与されたパケットのルーティングを実行する。図９に示す例では、トークン＃１が付与されたパケットは、アプリケーション＃５、＃４、＃３、＃２、＃１を順番に通過するように制御される。また、トークン＃５が付与されたパケットは、アプリケーション＃８、＃７、＃６を順番に通過するように制御される。

尚、業務アプリケーション３０から端末１０に向かうダウンリンクに対しては、アップリンクとは逆の経路が設定される。すなわち、経路制御部４２は、ダウンリンクにおいては、トークン＃１により識別されるトラフィックフローがアプリケーション＃１、＃２、＃３、＃４、＃５を順番に通過するように経路設定を行う。

図１０は、トークンに基づいてトラフィックフローを処理する方法の一例を示す図である。図１１は、図１０に示す方法に対応するシーケンス図である。ここでは、端末１０から業務アプリケーション３０に向かうアップリンクのトラフィックフローについて説明する。

Ｓ１８において、端末１０は、クラウド上に配置されている業務アプリケーション３０にアクセスするトラフィックフローを生成する。このトラフィックフローは、例えば、端末１０に実装されている端末アプリケーションにより生成される。なお、このトラフィックフローにより伝送される各パケットの宛先アドレスは、業務アプリケーション３０を表す。

Ｓ１９において、端末１０は、業務アプリケーション３０に向かうトラフィックフローに対して対応するトークンを付与する。具体的には、端末１０は、Ｓ４において端末管理装置２０から受信したトークン＃１を、業務アプリケーション３０に向かうトラフィックフローに付与する。このとき、トークン＃１は、このトラフィックフローにより伝送される各パケットのヘッダ内の所定の領域に書き込まれる。なお、トークンは、例えば、ＢＹＯＤアプリケーションによりトラフィックフローに付与される。

Ｓ２０において、エッジサーバ４０の経路制御部４２は、トラフィックフローに付与されているトークンを確認する。そして、端末１０から送信されるトラフィックフローにトークン＃１が付与されているときは、経路制御部４２は、Ｓ１７で設定された経路に従ってそのトラフィックフローを処理する。即ち、経路制御部４２は、このトラフィックフローを、順番に、アプリケーション＃５、＃４、＃３、＃２、＃１に導く。具体的には、アプリケーション＃１による事前処理が実行される前に、このトラフィックフローに対してキャプチャ処理、ログ処理、フィルタ処理、セキュリティ処理が順番に実行される。そして、アプリケーション＃１による事前処理が実行された後、エッジサーバ４０は、このトラフィックフローを業務アプリケーション３０に送信する。

図１２は、トークン発行部５１の処理の一例を示すフローチャートである。なお、トークン発行部５１は、常時、トークン要求を待ち受けている。

Ｓ１０１において、トークン発行部５１は、トークン要求を受信する。Ｓ１０２において、トークン発行部５１は、トークン要求と共に、先に発行したトークンを受信したか否かを判定する。

先に発行したトークンを受信していないときは、トークン発行部５１は、Ｓ１０３において、トークン要求の内容が予め契約されているか否かを判定する。そして、トークン要求の内容が予め契約されているときは、トークン発行部５１は、Ｓ１０４において、要求されたトークンを発行する。このとき、トークン発行部５１は、発行したトークンの内容を表すトークン情報を経路指定受付部４１に通知してもよい。この後、トークン発行部５１は、Ｓ１０７において、次のトークン要求を待ち受ける。一方、トークン要求の内容が予め契約されていないときは、トークン発行部５１は、Ｓ１０８において、エラーメッセージを出力する。

トークン要求と共に先に発行されたトークンを受信したときは（Ｓ１０２：Ｙｅｓ）、トークン発行部５１は、Ｓ１０５において、受信したトークン要求を許可するか否か判定する。具体的には、トークン発行部５１は、新たに要求されたトークンの権限の範囲が、先に発行されたトークンの権限の範囲内か否かを判定する。

先に発行されたトークンの権限の範囲内で新たなトークンが要求されたときは、トークン発行部５１は、Ｓ１０６において、要求されたトークンを発行する。このとき、トークン発行部５１は、新たに発行するトークンの内容を表すトークン情報を経路指定受付部４１に通知してもよい。この後、トークン発行部５１は、Ｓ１０７において、次のトークン要求を待ち受ける。一方、新たに要求された権限の範囲が、先に発行されたトークンの権限の範囲を超えているときは、トークン発行部５１は、Ｓ１０８において、エラーメッセージを出力する。

例えば、組織Ａと組織Ｄとの間で、端末１０と業務アプリケーション３０との間のトラフィックフローの経路を指定する権限を組織Ａが有する旨の契約が結ばれているものとする。この場合、図３に示す例では、トークン発行部５１は、端末管理装置２０からトークン要求を受信すると、Ｓ１０４でトークンを発行する。また、図４に示す例では、アプリケーション＃１から受信するトークン要求により要求される権限の範囲は、トークン＃１の権限の範囲内である。よって、トークン発行部５１は、アプリケーション＃１からトークン要求を受信すると、Ｓ１０６でトークンを発行する。

図１３は、経路指定受付部４１の処理の一例を示すフローチャートである。経路指定受付部４１は、例えば、トークン発行部５１からトークン情報を受信したときに処理を開始する。或いは、経路指定受付部４１は、経路指定情報を受信したときに処理を開始してもよい。

Ｓ１１１において、経路指定受付部４１は、経路指定情報およびトークンを受信する。Ｓ１１２において、経路指定受付部４１は、受信したトークンが改ざんされてないかチェックする。このとき、経路指定受付部４１は、図７に示す電子署名またはトークン発行部５１から受信するトークン情報を利用して改ざんをチェックする。

Ｓ１１３において、経路指定受付部４１は、受信したトークンが表す権限の範囲内（すなわち、対象フロー区間内）で経路が指定されているか否かを判定する。そして、受信したトークンが表す対象フロー区間内で経路が指定されていれば、経路指定受付部４１は、Ｓ１１４において、経路指定情報により指定される経路を経路指定情報管理テーブルに登録する。一方、受信したトークンが表す対象フロー区間を越えて経路が指定されているときは、経路指定受付部４１は、Ｓ１１８において、エラーメッセージを出力する。

Ｓ１１５〜Ｓ１１６において、経路指定受付部４１は、新たな経路指定情報を待ち受ける。そして、新たな経路指定情報を受信すると、経路指定受付部４１の処理はＳ１１２に戻る。一方、新たな経路指定情報を受信することなく所定の待ち時間が経過したときは、経路指定受付部４１は、経路指定情報管理テーブルに基づいて、エッジサーバ４０内の経路を決定する。経路指定情報管理テーブルに対象トークンに対して複数の経路が登録されているときは、例えば、他のすべての経路を包含する経路が選択される。そして、経路指定受付部４１は、Ｓ１１７において、決定した経路を表す経路情報を経路制御部４２に通知する。

図１４（ａ）は、トラフィックフローの開始時における経路制御部４２の処理の一例を示すフローチャートである。ここでは、端末１０が業務アプリケーション３０へのアクセスを開始するものとする。

Ｓ１２１において、経路制御部４２は、端末１０から送信されるトラフィックフローを受信する。Ｓ１２２において、経路制御部４２は、そのトラフィックフローに付与されているトークンを検出する。この例では、各パケットのヘッダに「トークン＃１」が挿入されているものとする。

Ｓ１２３において、経路制御部４２は、対象トラフィックフローから検出したトークンに対応する経路を通過するようにその対象トラフィックフローを処理する。例えば、図３〜図４に示す手順によって図９に示す経路情報テーブルが作成されているものとする。この場合、トークン＃１に対して経路「アプリ＃５→アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１」が登録されている。したがって、経路制御部４２は、対象トラフィックフローを、順番に、アプリケーション＃５、＃４、＃３、＃２、＃１に導く。

Ｓ１２４において、対象トラフィックフロー中のパケットのヘッダ情報を取得し、トークンに対応づけて経路情報テーブルに記録する。ヘッダ情報は、送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号のうちの少なくとも１つを含む。

図１４（ｂ）は、トラフィックフローが確立された後の経路制御部４２の処理の一例を示すフローチャートである。ここでは、図１４（ａ）に示す手順により、経路情報テーブルにおいて、対象トラフィックフローのトークンに対応づけてヘッダ情報が記録されているものとする。Ｓ１３１において、経路制御部４２は、トラフィックフローを受信する。このとき、経路制御部４２は、トラフィックフロー中のパケットからヘッダ情報を取得する。Ｓ１３２において、経路制御部４２は、経路情報テーブルを参照し、対象トラフィックフローから取得したヘッダ情報に対応する経路を通過するようにその対象トラフィックフローを処理する。なお、経路制御部４２は、図１４（ａ）に示す処理を実行することなく、図１４（ｂ）に示す手順でトラフィックフローを制御してもよい。

図１５は、端末１０の構成の一例を示す。端末１０は、ＣＰＵ１０１、メモリ１０２、ネットワークインタフェース１０３を備える。ＣＰＵ１０１、メモリ１０２、ネットワークインタフェース１０３は、バス１０４に接続されている。

ネットワークインタフェース１０３は、例えば、ＬＴＥインタフェースまたは無線ＬＡＮインタフェース等により実現される。また、ネットワークインタフェース１０３は、ルータ等の中継装置を介して、端末管理装置２０およびエッジサーバ４０と通信を行うことができる。メモリ１０２は、プログラムを格納することができる。この例では、メモリ１０２には、ＢＹＯＤアプリケーションプログラムおよび端末アプリケーションプログラムが格納されている。ＢＹＯＤアプリケーションプログラムは、端末アプリケーションが動作する環境を構築する。ＣＰＵ１０１は、メモリ１０２に格納されているプログラムを実行する。なお、トラフィックフローにトークンを付与する処理は、例えば、ＣＰＵ１０１がＢＹＯＤアプリケーションプログラムを実行することで実現される。

図１６は、端末管理装置２０の構成の一例を示す。端末管理装置２０は、ＣＰＵ２０１、メモリ２０２、ネットワークインタフェース２０３を備える。ＣＰＵ２０１、メモリ２０２、ネットワークインタフェース２０３は、バス２０４に接続されている。

ネットワークインタフェース２０３は、ルータ等の中継装置を介して、端末１０およびエッジサーバ４０、エッジサーバ管理装置５０と通信を行うことができる。メモリ２０２は、プログラムを格納することができる。この例では、メモリ２０２には、トークン要求部２１の処理を記述したプログラムが格納されている。ＣＰＵ２０１は、メモリ２０２に格納されているプログラムを実行する。なお、トークン要求部２１の機能は、メモリ２０２に格納されているプログラムをＣＰＵ２０１が実行することで実現される。

図１７は、エッジサーバ４０の構成の一例を示す。エッジサーバ４０は、ＣＰＵ４０１、メモリ４０２、ネットワークインタフェース４０３を備える。ＣＰＵ４０１、メモリ４０２、ネットワークインタフェース４０３は、バス４０４に接続されている。なお、エッジサーバ４０は、複数のネットワークインタフェース４０３を備えていてもよい。

ネットワークインタフェース４０３は、例えば、Ethernet（登録商標）または無線ＬＡＮインタフェース等により実現される。また、ネットワークインタフェース４０３は、ルータまたは基地局等の中継装置を介して、端末１０、端末管理装置２０、エッジサーバ管理装置５０、クラウド上の通信機器（例えば、業務アプリケーション３０が実装されているコンピュータ）と通信を行うことができる。

メモリ４０２は、プログラムを格納することができる。この例では、経路指定受付部４１の処理を記述したプログラムおよび経路制御部４２の処理を記述したプログラムがメモリ４０２に格納されている。また、メモリ４０２を利用して仮想マシンが構築され得る。各仮想マシンは、１または複数のアプリケーションが動作する環境を構築する。ＣＰＵ４０１は、メモリ４０２に格納されているプログラムを実行する。なお、経路指定受付部４１および経路制御部４２の機能は、メモリ４０２に格納されているプログラムをＣＰＵ４０１が実行することで実現される。例えば、ＣＰＵ４０１は、図１３に示すフローチャートの処理を記述したプログラムを実行することで経路指定受付部４１の機能を提供する。

図１８は、エッジサーバ管理装置５０の構成の一例を示す。エッジサーバ管理装置５０は、ＣＰＵ５０１、メモリ５０２、ネットワークインタフェース５０３を備える。ＣＰＵ５０１、メモリ５０２、ネットワークインタフェース５０３は、バス５０４に接続されている。

ネットワークインタフェース５０３は、ルータ等の中継装置を介して、端末管理装置２０およびエッジサーバ４０と通信を行うことができる。メモリ５０２は、プログラムを格納することができる。この例では、メモリ５０２には、トークン発行部５１の処理を記述したプログラムが格納されている。ＣＰＵ５０１は、メモリ５０２に格納されているプログラムを実行する。なお、トークン発行部５１の機能は、メモリ５０２に格納されているプログラムをＣＰＵ５０１が実行することで実現される。例えば、ＣＰＵ５０１は、図１２に示すフローチャートの処理を記述したプログラムを実行することでトークン発行部５１の機能を提供する。

＜バリエーション＞
図４に示すＳ７において、トークン要求中の対象フロー区間は、「アプリケーション＃２の入力側（＊＊＊→アプリ＃２）」であってもよい。この場合、Ｓ８において発行されるトークン＃２の権限の範囲は、「アプリケーション＃２の入力側（＊＊＊→アプリ＃２）」である。

同様に、Ｓ１２において、トークン要求中の対象フロー区間は、「アプリケーション＃４の入力側（＊＊＊→アプリ＃４）」であってもよい。この場合、Ｓ１３において発行されるトークン＃３の権限の範囲は、「アプリケーション＃４の入力側（＊＊＊→アプリ＃４）」である。

経路指定情報は、与えられたトークンの権限の範囲内の経路のみを記述してもよい。すなわち、Ｓ１１の経路指定情報は、アプリケーション＃２の入力側の経路「アプリ＃４→アプリ＃３→アプリ＃２」のみを記述し、Ｓ１６の経路指定情報は、アプリケーション＃４の入力側の経路「アプリ＃５→アプリ＃４」のみを記述する。

この場合、経路指定受付部４１は、図８（ｂ）に示すように、以下の経路指定情報を受信することになる。
Ｓ６：アプリ＃２→アプリ＃１
Ｓ１１：アプリ＃４→アプリ＃３→アプリ＃２
Ｓ１６：アプリ＃５→アプリ＃４
したがって、経路指定受付部４１は、これらの経路を結合することにより、トークン＃１に対応するトラフィックフローの経路「アプリ＃５→アプリ＃４→アプリ＃３→アプリ＃２→アプリ＃１」を決定する。

＜他の実施形態＞
図２に示す例では、エッジサーバ４０から独立してエッジサーバ管理装置５０が設けられており、エッジサーバ４０は、エッジサーバ管理装置５０と連携することにより、トラフィックフローの経路を制御する経路制御装置として動作する。ただし、本発明はこの構成に限定されるものではない。例えば、図１９（ａ）に示すように、エッジサーバ管理装置５０の機能（すなわち、トークン発行部５１）がエッジサーバ４０の中に実装されるようにしてもよい。この場合、トークン発行部５１を含むエッジサーバ４０は、トラフィックフローの経路を制御する経路制御装置として動作する。

また、図２に示す例では、１台のエッジサーバ４０に対して１台のエッジサーバ管理装置５０が設けられているが、本発明はこの構成に限定されるものではない。例えば、図１９（ｂ）に示すように、複数のエッジサーバ４０ａ〜４０ｎに対して１台のエッジサーバ管理装置５０が設けられるようにしてもよい。この場合、各エッジサーバ４０ａ〜４０ｎは、エッジサーバ管理装置５０と連携することにより、トラフィックフローの経路を制御する経路制御装置として動作する。

図３〜図４に示す例では、トラフィックフローの経路が複数のエンティティによって指定されるが、本発明はこの構成に限定されるものではない。例えば、１つのエンティティがエッジサーバ４０内のすべての経路を指定してもよい。この場合、エッジサーバ４０内の全区間に渡って経路を指定する権限を表すトークンが発行される。

上述の実施例では、トラフィックフローの確立前にパケットヘッダから各トラフィックフローを識別できないケースを考慮し、端末１０は、トラフィックフローの初出時にそのトラフックフローにトークンを付与する。そして、エッジサーバ４０は、トークンに基づいてトラフィックフローの経路を制御する。但し、トラフィックフローの確立前にパケットヘッダから所望のトラフィックフローを識別できるケースでは、エッジサーバ４０は、トークンを用いることなくトラフィックフローの経路を制御してもよい。

例えば、アクセスすべき業務アプリケーションの宛先ＩＰアドレス／宛先Ｌ４ポート番号によりトラフィックフローが識別されるものとする。この場合、エッジサーバ４０は、新たなトークンを要求するときに、トラフィックフローを識別する情報として、その宛先ＩＰアドレス／宛先Ｌ４ポート番号をトークン発行部５１に通知する。そうすると、トークン中にその宛先ＩＰアドレス／宛先Ｌ４ポート番号が設定される。図７に示す例では、宛先ＩＰアドレス／宛先Ｌ４ポート番号は、対象フロー情報として設定される。そして、このトークンは、対応する経路情報と共に経路制御部４２に与えられる。経路制御部４２は、指定された宛先ＩＰアドレス／宛先Ｌ４ポート番号に基づいてトラフィックフローの経路を制御できる。よって、端末１０は、トラフィックフローにトークンを付与する必要はなく、端末管理装置２０は、端末１０へトークンを送信する必要はない。

１０ 端末
２０ 端末管理装置
２１ トークン要求部
３０ 業務アプリケーション
４０ エッジサーバ
４１ 経路指定受付部
４２ 経路制御部
５０ エッジサーバ管理装置
５１ トークン発行部

Claims (5)

1. 複数のエンティティを収容するサーバ内でトラフィックフローの経路を制御する経路制御装置であって、
   前記複数のエンティティの中のいずれかのエンティティからの要求に応じて、トラフィックフローの経路を指定する権限を表す制御情報を発行する発行部と、
   前記複数のエンティティの中のいずれかのエンティティから受け付ける経路指定情報を許可するか否かを判定する受付部と、
   前記受付部により許可された経路指定情報に基づいてトラフィックフローの経路を制御する経路制御部と、を備え、
   前記発行部は、前記複数のエンティティの中の第１のエンティティから、前記サーバ内の第１の範囲においてトラフィックフローの経路を指定する権限を表す第１の制御情報、および、前記サーバ内の第２の範囲においてトラフィックフローの経路を指定する権限の要求を受信したときに、前記第２の範囲が前記第１の範囲に含まれていれば、前記第２の範囲においてトラフィックフローの経路を指定する権限を表す第２の制御情報を発行すると共に、前記第１のエンティティおよび前記受付部に前記第２の制御情報を送信し、
   前記受付部は、前記複数のエンティティの中の第２のエンティティから、トラフィックフローの経路を指定する経路指定情報を受信したときに、前記経路指定情報が前記第２の制御情報により指定される第２の範囲内で経路を指定していれば、前記経路指定情報を許可する
   ことを特徴とする経路制御装置。
2. 前記発行部は、前記第２のエンティティから、前記第２の制御情報、および、前記サーバ内の第３の範囲においてトラフィックフローの経路を指定する権限の要求を受信したときに、前記第３の範囲が前記第２の範囲に含まれていれば、前記第３の範囲においてトラフィックフローの経路を指定する権限を表す第３の制御情報を発行すると共に、前記第２のエンティティおよび前記受付部に前記第３の制御情報を送信し、
   前記受付部は、前記複数のエンティティの中の第３のエンティティから、トラフィックフローの経路を指定する第２の経路指定情報を受信したときに、前記第２の経路指定情報が前記第３の制御情報により指定される第３の範囲内で経路を指定していれば、前記第２の経路指定情報を許可する
   ことを特徴とする請求項１に記載の経路制御装置。
3. 複数のエンティティを収容するエッジサーバ装置であって、
   前記複数のエンティティの中のいずれかのエンティティから受け付ける経路指定情報を許可するか否かを判定する受付部と、
   前記受付部により許可された経路指定情報に基づいてトラフィックフローの経路を制御する経路制御部と、を備え、
   当該エッジサーバ装置は、前記複数のエンティティの中のいずれかのエンティティからの要求に応じて当該エッジサーバ装置内でのトラフィックフローの経路を指定する権限を表す制御情報を発行するエッジサーバ管理装置に接続し、
   前記エッジサーバ管理装置は、前記複数のエンティティの中の第１のエンティティから、当該エッジサーバ装置内の第１の範囲においてトラフィックフローの経路を指定する権限を表す第１の制御情報、および、当該エッジサーバ装置内の第２の範囲においてトラフィックフローの経路を指定する権限の要求を受信したときに、前記第２の範囲が前記第１の範囲に含まれていれば、前記第２の範囲においてトラフィックフローの経路を指定する権限を表す第２の制御情報を発行すると共に、前記第１のエンティティおよび前記受付部に前記第２の制御情報を送信し、
   前記受付部は、前記複数のエンティティの中の第２のエンティティから、トラフィックフローの経路を指定する経路指定情報を受信したときに、前記経路指定情報が前記第２の制御情報により指定される第２の範囲内で経路を指定していれば、前記経路指定情報を許可する
   ことを特徴とするエッジサーバ装置。
4. 複数のアプリケーションを格納するエッジサーバと、
   前記エッジサーバを介して目的サーバにアクセスする端末と、
   前記エッジサーバ内の所定の範囲において前記端末と前記目的サーバとの間のトラフィックフローの経路を指定する権限を表す制御情報を発行するエッジサーバ管理装置と、を備え、
   前記エッジサーバは、
   前記複数のアプリケーションの中のいずれかのアプリケーションから受け付ける経路指定情報を許可するか否かを判定する受付部と、
   前記受付部により許可された経路指定情報に基づいてトラフィックフローの経路を制御する経路制御部と、を含み、
   前記エッジサーバ管理装置は、前記複数のアプリケーションの中の第１のアプリケーションから、前記エッジサーバ内の第１の範囲においてトラフィックフローの経路を指定する権限を表す第１の制御情報、および、前記エッジサーバ内の第２の範囲においてトラフィックフローの経路を指定する権限の要求を受信したときに、前記第２の範囲が前記第１の範囲に含まれていれば、前記第２の範囲においてトラフィックフローの経路を指定する権限を表す第２の制御情報を発行すると共に、前記第１のアプリケーションおよび前記受付部に前記第２の制御情報を送信し、
   前記受付部は、前記複数のアプリケーションの中の第２のアプリケーションから、トラフィックフローの経路を指定する経路指定情報を受信したときに、前記経路指定情報が前記第２の制御情報により指定される第２の範囲内で経路を指定していれば、前記経路指定情報を許可し、
   前記経路指定情報が前記受付部により許可されたときは、前記経路制御部は、前記経路指定情報に基づいて前記トラフィックフローの経路を制御する
   ことを特徴とするネットワークシステム。
5. 複数のエンティティを収容するサーバ内でトラフィックフローの経路を制御する経路制御方法であって、
   前記複数のエンティティの中の第１のエンティティから、前記サーバ内の第１の範囲においてトラフィックフローの経路を指定する権限を表す第１の制御情報、および、前記サーバ内の第２の範囲においてトラフィックフローの経路を指定する権限の要求を受信したときに、前記第２の範囲が前記第１の範囲に含まれていれば、前記第２の範囲においてトラフィックフローの経路を指定する権限を表す第２の制御情報を発行し、
   前記複数のエンティティの中の第２のエンティティから、トラフィックフローの経路を指定する経路指定情報を受信したときに、前記経路指定情報が前記第２の制御情報により指定される第２の範囲内で経路を指定していれば、前記経路指定情報を許可し、
   前記経路指定情報が許可されたときに、前記経路指定情報に基づいて前記トラフィックフローの経路を制御する、
   ことを特徴とする経路制御方法。

Images