(57)【要約】【課題】資源割り当て管理サーバの負荷を抑えることが可能なネットワークシステムを提供する。【解決手段】ルータを介して、発信側装置と着信側装置との間で情報通信を行うために、ルータに対して、ＱｏＳの設定を行う資源管理サーバを備えたネットワークシステムであって、着信側装置が資源管理サーバに対して送信したＱｏＳ生成要求に対する応答を受信する手段と、着信側装置から発信側装置に対して、ＱｏＳ設定情報を含むトークンを送信する手段と、トークンに含まれるＱｏＳ設定情報に基づいて、ルータのＱｏｓを設定する手段とを備えた。【選択図】図１
2008263421.tif 000002
【特許請求の範囲】
【請求項１】
ルータを介して、発信側装置と着信側装置との間で情報通信を行うために、前記ルータに対して、ＱｏＳの設定を行う資源管理サーバを備えたネットワークシステムであって、
前記着信側装置が前記資源管理サーバに対して送信したＱｏＳ生成要求に対する応答を受信する手段と、
前記着信側装置から前記発信側装置に対して、ＱｏＳ設定情報を含むトークンを送信する手段と、
前記トークンに含まれる前記ＱｏＳ設定情報に基づいて、前記ルータのＱｏｓを設定する手段と
を備えたことを特徴とするネットワークシステム。
【請求項２】
前記ルータは、前記トークンの宛先アドレスが前記発信側装置であり、前記トークンの送信元アドレスが前記着信側装置である場合に、前記ＱｏＳ設定情報に基づいて、Ｑｏｓを設定することを特徴とする請求項１に記載のネットワークシステム。
【請求項３】
前記トークンは、ライフタイムを有し、該トークンライフタイム期間中は、前記資源管理サーバに対して、前記ＱｏＳ生成要求を送信することなく前記ルータのＱｏＳライフタイムの更新が可能であることを特徴とする請求項１または２に記載のネットワークシステム。
【請求項４】
前記ルータは、前記トークンの正当性が確認できた場合に、前記ＱｏＳ設定情報に基づいて、Ｑｏｓを設定することを特徴とする請求項１から３のいずれかに記載のネットワークシステム。
【請求項５】
前記発信側装置と着信側装置との間で情報通信を行う度に異なる暗号鍵を用いて、前記トークン内の情報を暗号化することを特徴とする請求項１から４のいずれかに記載のネットワークシステム。
【請求項６】
ルータを介して、発信側装置と着信側装置との間で情報通信を行うために、前記ルータに対して、ＱｏＳの設定を行う資源管理サーバを備えたネットワークシステムにおける資源割り当て方法であって、
前記着信側装置が前記資源管理サーバに対して送信したＱｏＳ生成要求に対する応答を受信するステップと、
前記着信側装置から前記発信側装置に対して、ＱｏＳ設定情報を含むトークンを送信するステップと、
前記トークンに含まれる前記ＱｏＳ設定情報に基づいて、前記ルータのＱｏｓを設定するステップと
を有することを特徴とする資源割り当て方法。
【請求項７】
ルータを介して、発信側装置と着信側装置との間で情報通信を行うために、前記ルータに対して、ＱｏＳの設定を行う資源管理サーバを備えたネットワークシステム上で動作する資源割り当てプログラムであって、
前記着信側装置が前記資源管理サーバに対して送信したＱｏＳ生成要求に対する応答を受信する処理と、
前記着信側装置から前記発信側装置に対して、ＱｏＳ設定情報を含むトークンを送信する処理と、
前記トークンに含まれる前記ＱｏＳ設定情報に基づいて、前記ルータのＱｏｓを設定する処理と
をコンピュータに行わせることを特徴とする資源割り当てプログラム。
【請求項８】
前記ルータのＱｏｓを設定する処理は、前記トークンの宛先アドレスが前記発信側装置であり、前記トークンの送信元アドレスが前記着信側装置である場合に、前記ＱｏＳ設定情報に基づいて、Ｑｏｓを設定することを特徴とする請求項７に記載の資源割り当てプログラム。
【請求項９】
前記トークンは、ライフタイムを有し、該トークンライフタイム期間中は、前記資源管理サーバに対して、前記ＱｏＳ生成要求を送信することなく前記ルータのＱｏＳライフタイムの更新が可能であることを特徴とする請求項７または８に記載の資源割り当てプログラム。
【請求項１０】
前記ルータのＱｏｓを設定する処理は、前記トークンの正当性が確認できた場合に、前記ＱｏＳ設定情報に基づいて、Ｑｏｓを設定することを特徴とする請求項７から９のいずれかに記載の資源割り当てプログラム。
【請求項１１】
前記発信側装置と着信側装置との間で情報通信を行う度に異なる暗号鍵を用いて、前記トークン内の情報を暗号化することを特徴とする請求項７から１０のいずれかに記載の資源割り当てプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、効率的にネットワーク資源を割り当てることができるネットワークシステム、資源割り当て方法及び資源割り当てプログラムに関する。
【背景技術】
【０００２】
ネットワークのＱｏＳ（Quality of Service）ポリシーなどをコントロールするためのプロトコルとしてＣＯＰＳ（Common Open Policy Service；共通オープン・ポリシー・サービス）という方式がある（非特許文献１〜３）。これは、必要に応じて集中管理サーバからルータなどにポリシ（例えばどのようなＱｏＳを設定するか）を指示するものであり、ネットワーク・システムのポリシー（運用方針）に関する情報をルータに配布し、ルータの設定をするためのプロトコルである。これによってネットワークのポリシー制御を行うことが可能である。
【０００３】
ＰＩＢ（Policy Information Base；ポリシー情報ベース）は、ネットワーク機器の管理に定義されていたＭＩＢ（Management Information Base；管理情報ベース）に類似した形式で表現されたポリシー情報のデータベースである。ＣＯＰＳは、クライアント−サーバ型のデータベース配布プロトコルで、ＰＩＢで管理されたポリシー情報を通知する。ＣＯＰＳにはオープンソース方式とプロビジョン方式の２種類があり、前者はルータなどＰＥＰ（Policy Enforcement Point）と呼ばれるノードからＰＤＰ（Policy Decision Point：ＣＯＰＳサーバ）と呼ばれるノードへリクエストを出し、それに応答する形でポリシーを通知する方式、後者はＰＤＰが独自に判断して、一方的にＰＥＰにポリシーを通知する方式である。
【０００４】
また、ＣＯＰＳの一方式として、ＲＳＶＰ（Resource Reservation Protocol）と組み合わせたＣＯＰＳ−ＲＳＶＰと呼ばれる方式もある。これは、図１０に示すように、ＲＳＶＰシグナルを受信したＣＯＰＳ対応ルータ（図１０（１）、（４）、（７））が、資源割り当てを行ってよいかをＣＯＰＳサーバへ毎回問い合わせを行い（図１０（２）、（５））、ＣＯＰＳサーバがどの程度の資源を割り当てるかを判断し、ルータへ指示を出す（図１０（３）、（６））ものである。
【０００５】
このＣＯＰＳ−ＲＳＶＰは、ＲＳＶＰシグナルがくれば、それに応じて資源割り当てを行う、または試みるものであるが、なぜその資源割り当てを行う必要があるか否かについては一切関知しない。すなわち、本当にアプリケーションを利用しようとして資源割り当てが要求されているか否かを関知していない。これに対して、非特許文献４、５などでは、セッション（アプリケーションとのやり取り）毎に資源割り当てを行う方式について提案されている。この方式は、図１１に示すように、クライアントがアプリケーションサーバへアクセスした際に、アプリケーションサーバはＣＯＰＳサーバへ資源割り当てを要求し、その結果をトークンとして受領する。そしてアプリケーションサーバからクライアントへトークンを返す。その後、クライアントはネットワークに対して資源割り当ての要求を出す（例えばＲＳＶＰなどを用いて）が、その際にトークンをそのメッセージに付加する（図１１（１）〜（４））。後は、ＣＯＰＳ−ＲＳＶＰと同じように、各ルータはトークンつきの資源割当要求をＣＯＰＳサーバに出し、ＣＯＰＳサーバは状況に応じて割り当てるべき資源を応答する（図１１（５）〜（８））。
【非特許文献１】http://www.ietf.org/rfc/rfc2748.txt
【非特許文献２】http://www.ietf.org/rfc/rfc2749.txt
【非特許文献３】http://www.ietf.org/rfc/rfc4261.txt
【非特許文献４】http://www.ietf.org/rfc/rfc3520.txt
【非特許文献５】http://www.ietf.org/rfc/rfc3521.txt
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来の方式においては、ルータ毎にＣＯＰＳサーバに対する問い合わせ／応答が必要となってしまう。ＣＯＰＳサーバが逐一ネットワークの状況を監視、把握しているという前提の下、なるべくその時点の状況に即した状態で資源を割り当てるという意味においては優れるが、Ｄｉｆｆｓｅｒｖのように最終的にクラス分けを行うだけのようなサービスの場合、そこまでの細かなコントロールは意味を成さない可能性が高い。また、割り当てられた資源の維持のために更新手続き等が必要となるが、「いつからいつまでその資源を維持しなければならない」といったような情報を、セッション毎にすべてＣＯＰＳサーバが維持管理しなければならず、また更新手続き用のシグナリングの度に、資源割り当てのときと同様の処理が行われるため、ＣＯＰＳサーバへの負荷が非常に大きくなってしまうという問題がある。
【０００７】
なお、Ｄｉｆｆｓｅｒｖとは、ネットワーク内においてＱｏＳを提供するための仕組みのひとつであり、トラフィックをクラスに分類し、それぞれのクラス毎にＱｏＳを適用する手法である。実際には、エッジルータでのクラス分け（ＩＰヘッダのＴＯＳフィールド、ＩＰｖ６のＴｒａｆｆｉｃ  Ｃｌａｓｓフィールド値などの決定）と、これらの値を基に各ルータで帯域制限等の制御を行うものである。
【０００８】
本発明は、このような事情に鑑みてなされたもので、クライアントやアプリケーションサーバなどのエンドノードに権限を委譲し、ＣＯＰＳサーバ等の資源割り当て管理サーバの負荷を抑えることが可能なネットワークシステム、資源割り当て方法及び資源割り当てプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は、ルータを介して、発信側装置と着信側装置との間で情報通信を行うために、前記ルータに対して、ＱｏＳの設定を行う資源管理サーバを備えたネットワークシステムであって、前記着信側装置が前記資源管理サーバに対して送信したＱｏＳ生成要求に対する応答を受信する手段と、前記着信側装置から前記発信側装置に対して、ＱｏＳ設定情報を含むトークンを送信する手段と、前記トークンに含まれる前記ＱｏＳ設定情報に基づいて、前記ルータのＱｏｓを設定する手段とを備えたことを特徴とする。
【００１０】
本発明は、前記ルータは、前記トークンの宛先アドレスが前記発信側装置であり、前記トークンの送信元アドレスが前記着信側装置である場合に、前記ＱｏＳ設定情報に基づいて、Ｑｏｓを設定することを特徴とする。
【００１１】
本発明は、前記トークンは、ライフタイムを有し、該トークンライフタイム期間中は、前記資源管理サーバに対して、前記ＱｏＳ生成要求を送信することなく前記ルータのＱｏＳライフタイムの更新が可能であることを特徴とする。
【００１２】
本発明は、前記ルータは、前記トークンの正当性が確認できた場合に、前記ＱｏＳ設定情報に基づいて、Ｑｏｓを設定することを特徴とする。
【００１３】
本発明は、前記発信側装置と着信側装置との間で情報通信を行う度に異なる暗号鍵を用いて、前記トークン内の情報を暗号化することを特徴とする。
【００１４】
本発明は、ルータを介して、発信側装置と着信側装置との間で情報通信を行うために、前記ルータに対して、ＱｏＳの設定を行う資源管理サーバを備えたネットワークシステムにおける資源割り当て方法であって、前記着信側装置が前記資源管理サーバに対して送信したＱｏＳ生成要求に対する応答を受信するステップと、前記着信側装置から前記発信側装置に対して、ＱｏＳ設定情報を含むトークンを送信するステップと、前記トークンに含まれる前記ＱｏＳ設定情報に基づいて、前記ルータのＱｏｓを設定するステップとを有することを特徴とする。
【００１５】
本発明は、ルータを介して、発信側装置と着信側装置との間で情報通信を行うために、前記ルータに対して、ＱｏＳの設定を行う資源管理サーバを備えたネットワークシステム上で動作する資源割り当てプログラムであって、前記着信側装置が前記資源管理サーバに対して送信したＱｏＳ生成要求に対する応答を受信する処理と、前記着信側装置から前記発信側装置に対して、ＱｏＳ設定情報を含むトークンを送信する処理と、前記トークンに含まれる前記ＱｏＳ設定情報に基づいて、前記ルータのＱｏｓを設定する処理とをコンピュータに行わせることを特徴とする。
【００１６】
本発明は、前記ルータのＱｏｓを設定する処理は、前記トークンの宛先アドレスが前記発信側装置であり、前記トークンの送信元アドレスが前記着信側装置である場合に、前記ＱｏＳ設定情報に基づいて、Ｑｏｓを設定することを特徴とする。
【００１７】
本発明は、前記トークンは、ライフタイムを有し、該トークンライフタイム期間中は、前記資源管理サーバに対して、前記ＱｏＳ生成要求を送信することなく前記ルータのＱｏＳライフタイムの更新が可能であることを特徴とする。
【００１８】
本発明は、前記ルータのＱｏｓを設定する処理は、前記トークンの正当性が確認できた場合に、前記ＱｏＳ設定情報に基づいて、Ｑｏｓを設定することを特徴とする。
【００１９】
本発明は、前記発信側装置と着信側装置との間で情報通信を行う度に異なる暗号鍵を用いて、前記トークン内の情報を暗号化することを特徴とする。
【発明の効果】
【００２０】
本発明によれば、トークンを用いることにより、ルータに設定されるＱｏＳの維持管理（ライフタイム更新）処理を分散することができるため、中央のサーバがすべてを管理する必要がなくなり、ネットワークシステム全体の効率を向上させることができるという効果が得られる。また、ＱｏＳ設定を行える方向性を導入することにより、不正な資源割り当て要求を防ぐことができる。また、ＳＩＰを用いたＰ２Ｐ通信についても、ＳＩＰクライアント間のＱｏＳを同様に管理することができるという効果が得られる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の一実施形態による資源割り当て方法を図面を参照して説明する。図１は同実施形態のネットワークシステムの構成を示す図である。図１に示すように、ネットワークシステムは、ユーザ端末（End-Host）１、アプリケーションサーバ（以下、ＡＰＰＳと称する）２、資源管理サーバ（Resource management Server）３を少なくとも備え、例えばＡＰＰＳ２が動画配信サーバでＥＨ１がそのクライアントであるような構成である。また、ＳＩＰを利用したクライアント同士の通信の場合には、発信者のＳＩＰクライアント（User Agent Client、ＵＡＣと称する）４、着信者ＳＩＰクライアント（User Agent Server、以下ＵＡＳと称する）５、ＳＩＰサーバ６１、６２からなる。また、本発明によるネットワークは、Ｄｉｆｆｓｅｒｖ対応のコアネットワークであり、エッジルータ７１〜７６、８を備えている。ただし、エッジルータ８は、必ずしもＤｉｆｆｓｅｒｖを使用する必要はない。本発明は、エッジルータ７１〜７６に対してＱｏＳの設定を行うものである。すなわち、ある送信元からある宛先へと向かうパケットに対してＤＳＣＰ（Differentiated Services Code Point）値を設定することにより、ネットワーク内ではそのパケットがＤＳＣＰ値に応じて優先的に転送されるようにするものである。
【００２２】
なお、ＱｏＳをコントロールするためのシグナリングとして、ＮＳＩＳ等が提案されているが、本発明は特にそれに限定するものではない。ここでは、不可欠な要素に絞って、どのようなメッセージをやり取りする必要があるかを説明するが、これらの内容は、既存のＮＳＩＳ等のシグナリングの一要素として取り扱うことができる。ＮＳＩＳ（Next Step In Signaling）とは、ネットワーク上で送信先までの帯域を予約し、通信品質を確保するプロトコルであるＲＳＶＰを発展させ、一般化させた方式である。様々なシグナリングを実装するシグナリングレイヤ（ＮＳＬＰ：NSIS Signaling Layer Protocol）と、シグナリングをＮＳＩＳエンティティ間（ＮＳＩＳをサポートしたルータなど）で転送するための仕組みを提供するトランスポートレイヤ（ＮＴＬＰ：Nsis Transport Layer Protocol）からなる。ＮＳＬＰとして様々な方式を実装することができ、例えばＲＳＶＰと同等の働きをさせたり、Ｄｉｆｆｓｅｒｖのコントロール用シグナリングとしたりすることが可能である。
【００２３】
次に、本発明において想定しているサービスモデルについて説明する。ここでいうサービスモデルとは、ネットワーク事業者が、アプリケーションサービスを提供者に対して、一定の帯域を保証するサービスを提供するものである。例えば、動画を配信するサービス提供者に対して帯域を保証するもので、サービスのユーザは動画受信に必要な帯域を個別に割り当ててもらい、他のアプリケーショントラフィックから影響を受けずに、動画を楽しむことができるようにするものである。
【００２４】
ただし、動画配信サービス全体に割り当てられる帯域は有限であるため、動画配信サービスの提供者は、なるべくユーザに対する帯域割り当ての無駄を省ように、ＱｏＳそのものの設定に関する権限はネットワーク事業者が管理する資源管理サーバ３が行うが、これをどのように維持するかという点に関しては、アプリケーション提供者およびそのユーザに権限（ＱｏＳ設定のライフタイム更新に関する権限）を委譲する。また、アプリケーション提供者が、ネットワークのＱｏＳに対して対価を支払っているため、ユーザは信用できるとは限らないという想定で、アプリケーション提供者がＱｏＳの維持管理を主導するものとする。
【００２５】
一方、ＳＩＰを利用したＩＰ電話のようなＰ２Ｐ通信については、ＵＡＣ（発信者）４だけでなく、ＵＡＳ（着信者）５も一般ユーザであるため、全く同様なサービスモデルというわけにはいかないが、ＳＩＰを利用した通信の場合、ＳＩＰサーバ６１、６２がＵＡＣ４−ＵＡＳ５に対する権限委譲を仲介することによって、ＵＡＣ４−ＵＡＳ５間だけでＱｏＳの維持を可能とする。
【００２６】
次に、資源管理サーバ３（ＲＳ）との情報共有について説明する。資源管理サーバ３は受信したシグナリングパケットがどのユーザに関するものであるかを知り、その正当性を確認するために、各ユーザクライアントとの間で「ＩＤ情報」と「共有秘密鍵（ユーザ鍵）情報」を共有しておく必要がある。ここで、ＩＤ情報は資源管理サーバ３がユーザクライアントを一意に識別できるもので、例えば、ＵＲＩやＩＰアドレス、証明書などである。共有秘密鍵情報は、ユーザから秘密の情報（後述する一時鍵）を暗号化するためのもので、それが復号できるか否かを検証することによって、正しいユーザからのシグナルであるかを確認するものである。
【００２７】
次に、図２を参照して、資源管理サーバ３の機能構成を説明する。資源管理サーバ３は、ユーザ情報を管理するユーザ情報管理部３１と、外部との間でシグナリング処理を行うシグナリング処理部３２と、資源割り当てを行うＱｏＳ管理部３３とからなる。これらは既存の様々な方式で採用されているものを流用することができる。また、ユーザ情報管理部３１は資源管理サーバ３とは別のノード（例えば認証サーバなど）に存在してもよい。
【００２８】
次に、シグナリング処理部３２が処理するシグナリング種別（トークン）について説明する。本発明では、資源管理サーバ３が発行するトークンを基に、エッジルータ７１〜７６が資源割り当てを行う。なお、以下の説明における「発信者」とはセッションを開始のきっかけとなるノードのことで例えばユーザ端末１やＵＡＣ４であり、また「着信者」とはセッション開始を受け入れるノードのことで例えばＡＰＰＳ２やＵＡＳ５である。
【００２９】
（１）ＩＮＩＴＩＡＬトークン
セッション開始時に発信者から着信者（またはＳＩＰサーバ）へ送るトークンである。
（２）ＡＵＴＨＥＮＴＩＣＡＴＥＤトークン
着信者からこれを返すことにより、経路上のルータがＱｏＳの設定を行うものである。なお、ＱｏＳの設定は双方向について行う。
（３）ＲＥＦＲＥＳＨトークン
発信者から着信者（またはＳＩＰサーバ）へ送るＱｏＳライフタイム更新のための要求である。
（４）ＲＥＱＵＥＳＴトークン
ＳＩＰによるＰ２Ｐ通信の場合に、ＵＡＣ４からＵＡＳ５に最初に送られるトークンで、ＳＩＰサーバ６１、６２から受け取ったＡＵＴＨＥＮＴＩＣＡＴＥＤトークンの次に送信されるものである。
（５）ＡＣＣＥＰＴＥＤトークン
ＳＩＰによるＰ２Ｐ通信の場合に、ＵＡＣ４からＵＡＳ５に送られたＲＥＦＲＥＳＨまたはＲＥＱＵＥＳＴトークンに対して、ＵＡＳ５からＵＡＣ４に送られ、ＡＵＴＨＥＮＴＩＣＡＴＥＤトークンと同様の働きをするものである。
（６）ＴＥＮＴＡＴＩＶＥトークン
新しいセッションが開始される予定であることを通知するためのトークンであり、ＳＩＰサーバ６１、６２からＵＡＳ５へ通知されるものである。
【００３０】
なお、Ｑｏｓの設定を「双方向」について行うとは、発信者から着信者への向き、着信者から発信者への向きの両方に関して帯域割り当てを行うことを意味する。また、ＡＵＴＨＥＮＴＩＣＡＴＩＥＤトークン及びＡＣＣＥＰＴＥＤトークンは着信者からのみ送出することができるものである。また、同一セッションに関する限り、ひとつのトークンを使いまわし、必要な部分だけを変更して使用する。すなわち、次にトークンを送るために、前回受信したトークンを保持しておかなければならない。
【００３１】
次に、トークンの安全性について説明する。トークンの中には様々な情報が含まれるが、トークンを構成する要素の中でエッジルータがＱｏＳの設定を行うために直接使用する情報（ＱｏＳコントロール情報）を含むのはＡＵＴＨＥＮＴＩＣＡＴＥＤトークンとＡＣＣＥＰＴＥＤトークンだけである。他のトークンにＱｏＳコントロール情報が含まれていてもよいが、他のトークンにおいてＱｏＳコントロール情報は意味を持たない情報である。そして、このＱｏＳコントロール情報は資源管理サーバ３のみが作成することができ、各ルータおよびＡＰＰＳ２は閲覧のみ許されるものである。これによって、不正な資源割り当てが為されることを防ぐ。また、資源割り当ては着信者主導であり（ＲＳＶＰなども同様である）、これは、発信者側からの要求に対して着信者が応えない限り資源割り当てが為されないということを意味している。また、発信者からＩＮＩＴＩＡＬトークン、ＲＥＦＲＥＳＨトークンを送り、着信者がそれに応じてＡＵＴＨＥＮＴＩＣＡＴＥＤトークン、ＡＣＣＥＰＴＥＤトークンを返すことにより、資源予約、更新が行われる。さらに、着信側が発信側からのトークンを検証し、不正なトークンに対して応答しない仕組みも備えている。
【００３２】
すなわち、安全性を確保するために、「ユーザ・アプリケーションサーバが偽ってルータのＱｏＳ割り当てを実施することができないこと」、「アプリケーションサーバが、ＱｏＳ割り当ての更新（時間延長）を主導すること」、「正しい通信ペア（サーバとクライアント）に対してのみ有効に動作する」という点を満たすようにしている。
【００３３】
次に、トークンに必要な暗号鍵について説明する。暗号鍵は全部で６種類必要となり、さらにその中で共有秘密鍵方式と公開鍵暗号方式を用いるものに分類される。
＜公開鍵暗号＞
・Ｋｑｓ、Ｋｑｐ：ＱｏＳコントロール保護用（改ざん防止）
秘密鍵は基本的には資源管理サーバ３のみが保有し、公開鍵は、ルータ、ＡＰＰＳ２が保有する。
・Ｋａｓ、Ｋａｐ：発行機関による認証情報保護用（改ざん防止）
秘密鍵は資源管理サーバ３のみが保有し、公開鍵はＡＰＰＳ２が保有する。
・Ｋｕａｓ、Ｋｕａｐ：ＳＩＰアプリケーション使用時の認証子（デジタル署名）作成用
ＵＡＣ４がペアを作成し、ＵＡＣ４とＵＡＳ５がペアを共有する。また、ＱｏＳ管理部３３部に公開鍵Ｋｕａｐを載せておく。
【００３４】
＜共有秘密鍵暗号＞
・Ｋｕ：ユーザ鍵
資源管理サーバ３とユーザ端末１があらかじめ共有する。それぞれのユーザ毎に異なるＫｕが存在する。
・Ｋｔ：ユーザ情報秘匿およびトークンの保護（認証子計算）用
セッション毎にユーザが作成する。また、ＡＰＰＳ２とユーザ端末１（またはＵＡＣ４とＵＡＳ５、ＳＩＰプロキシ）が共有する。
・Ｋａｐｐ：  アプリケーションサーバ鍵
ＡＰＰＳ２がトークンに情報を保存するために使用する。また、ＡＰＰＳ２単体で保持する。
【００３５】
次に、トークンの構成について説明する。図３にトークンの構成を示す。図３に示すように、トークンは「セッション情報部（Ｓｅｓｓｉｏｎ）」、「ＱｏＳコントロール部」「発行機関情報部」、「サーバ情報部」、「ユーザ情報部」、「タイムスタンプ・認証子部」からなる。それぞれに含まれる情報は以下の通りである。
【００３６】
＜セッション情報部＞
セッション情報部は、どのセッションに関する情報であるかを識別する為の情報であり、初めてトークンを受け取ったＡＰＰＳ２（またはＳＩＰサーバ）および資源管理サーバ３がＩＮＩＴＩＡＬトークンのユーザ情報を解読する際に共有鍵を特定するための情報である。ただし、この情報は例えばＮＳＩＳメッセージの他の要素で置換できる場合には不要となる。セッション情報部は、送信元アドレス、宛先アドレス、宛先ポート、送信元ポートおよびユーザＩＤ（資源管理サーバ３のユーザ情報管理部にノードを一意に特定するＩＰアドレスが登録されていないような場合）から構成する。
【００３７】
＜ＱｏＳコントロール部＞
ＱｏＳコントロール部は、エッジルータがＱｏＳの設定を行うための情報で、資源管理サーバ３が作成し、Ｋｑｓで暗号化するものである。ＱｏＳコントロール部は、さらに、セッション情報群、ＱｏＳライフタイム、トークンライフタイム及び公開鍵Ｋｕａｐから構成する。セッション情報群は、着信者（ＡＰＰＳ２など）の情報、発信者（ユーザ）の情報、ＤＳＣＰ値及びクライアントサーバ間の通信か、Ｐ２Ｐ通信であるかを示すフラグ等で構成する。ＱｏＳライフタイムは、エッジルータがそのＱｏＳ設定を維持する期間（例えば１分）であり、すなわち一回のＡＵＴＨＥＮＴＩＣＡＴＥＤ／ＡＣＣＥＰＴＥＤトークンでエッジルータがＱｏＳを設定する期間である。トークンライフタイムは、発行機関情報のトークンライフタイムと同値（発行期間情報はルータは参照できないため、ここにコピーを置かれる）。公開鍵Ｋｕａｐは、ＳＩＰを利用したＰ２Ｐ通信の場合に、エッジルータがトークンの検証に用いるために利用するもので、ＳＩＰを使わない場合は不要である。
【００３８】
ＡＵＴＨＥＮＴＩＣＡＴＥＤトークン・ＡＣＣＥＰＴＥＤトークンは、このセッション情報で発信者情報と着信者情報を記述しているため、ルータはパケットの送信元アドレスと宛先アドレスをチェックし、このセッション情報と比較することで、ＱｏＳを設定すべきか否かを判定することが可能である。例えば送信元と宛先が逆になっている場合など、これに合致しない場合には、そのパケットを無視する。なお、セッション情報群としているのは、複数のセッション情報を保持することを許容しており、ひとつのトークンで複数経路の制御が可能となる。また、そのトークンを受信した当該エッジルータとは無関係なアドレスに関するＱｏＳ設定は行わず、その部分は無視する。また、セッション毎に設定するライフタイムを変更したい場合にはＱｏＳライフタイムはセッション情報部に組み込んでもよい。
【００３９】
＜発行機関情報部＞
発行機関情報部は、資源管理サーバ３およびユーザに関する情報で、資源管理サーバ３が作成し、Ｋａｓで暗号化するものである。発行機関情報は、発行した資源管理サーバ３のユーザＩＤ（例えばホスト名やＵＲＩ、ＩＰアドレスなど）、発行時刻、トークンライフタイム（そのトークンそのものの有効期限。これが切れると、トークンの効力は失われ、受信したルータおよびＡＰＰＳ２はそのトークンを破棄する、またはエラーを返す）、ユーザ情報（例えばホスト名やＵＲＩなどのユーザＩＤ、ユーザのＩＰアドレス）から構成する。ユーザＩＤは、資源管理サーバ３がユーザを一意に識別できるものでなければならない。ＦＱＤＮ（完全修飾ドメイン名）やＵＲＩなどが望ましい。
【００４０】
＜サーバ情報部＞
サーバ情報部は、ＡＰＰＳ２が利用する情報で、Ｋａｐｐで暗号化されるものである。サーバ情報は、トークンの再送攻撃を防ぐために、次回受信トークンに含まれるべきシーケンス番号を格納して、発信者（ＥＨ）に送信し、受信時はこのシーケンスが用いられているか否かを確認するためのシーケンス番号から構成する。サーバ情報はサーバで管理すべきセッション毎の情報を削減する役割を持ち、またパケットロスなどへの耐性向上のための役割も持っている。Ｋａｐｐは当該ＡＰＰＳ２のみが保持するものなので、ＡＰＰＳ２依存の情報を何でも格納可能である。
【００４１】
＜ユーザ情報部（ＡＵＴＨＥＮＴＩＣＡＴＥＤトークン）＞
ＡＵＴＨＥＮＴＩＣＡＴＥＤトークンは、発信者と着信者および資源管理サーバ３での情報交換用の情報であり、基本的にはユーザが生成した一時鍵Ｋｔで暗号化されるものである。着信者から発信者への方向のＡＵＴＨＥＮＴＩＣＡＴＥＤトークンでは必ずＫｔでの暗号化となる。ＩＮＩＴＩＡＬトークンではＫｕで暗号化される。
【００４２】
発信者への情報は、Ｋｔで暗号化され、ＱｏＳライフタイム、トークンライフタイム、シーケンス番号、セッション情報、時差から構成する。ＱｏＳライフタイムは、セッション情報群のＱｏＳライフタイムと同じである。トークンライフタイムは、発行機関情報のトークンライフタイムと同値である。シーケンス番号は、サーバ情報部の次回シーケンスと同値である。ユーザはこれを見て、次回のＲＥＦＲＥＳＨトークンにこの値を用いてトークンを形成する。なお、ＳＩＰを使う場合には、ＳＩＰサーバへのＲＥＦＲＥＳＨとＵＡＳへのＲＥＦＲＥＳＨを別々に行う必要があるため、ＡＵＴＨＥＮＴＩＣＡＴＥＤトークンのシーケンス番号をＵＡＣで保持しておく必要がある。セッション情報は、ＱｏＳコントロール情報部のセッション情報と同じ（ＱｏＳコントロール部はＥＨが解読できないため）である。時差は、着信者が送ってきた時刻との差分を時差とすることによって、およそどのぐらい着信者と時刻がずれているかがわかるため、それを送信者に伝える。送信者は次回トークンを送る際に、この値を後述のタイムスタンプに加えることによって、時刻基準をおよそ併せることができる。
【００４３】
ＳＩＰ用情報は、ＵＡＳ５が参照する情報であり、ＵＡＳ５のＫｕで暗号化され、ＱｏＳライフタイム、トークンライフタイム、シーケンス番号、セッション情報、本セッションのＫｔ（ＵＡＣが作成したもの）、公開鍵ペアＫｕａｓから構成する。ＱｏＳライフタイム、トークンライフタイム、シーケンス番号及びセッション情報は、発信者への情報と同一である。なお、セッション毎に設定するライフタイムを変更したい場合にはＱｏＳライフタイムはセッション情報部に組み込んでもよい。ＳＩＰ用情報は、後述するＵＡＣ４−ＵＡＳ５間のセッションに関する情報を与えるためのものであり、ＳＩＰサーバからＵＡＣ４へのＡＵＴＨＥＮＴＩＣＡＴＥＤトークンに格納されており、そのままＵＡＣ４からＵＡＳ５へと転送されるＲＥＦＲＥＳＨトークンである。これはＵＡＳ５のユーザ鍵Ｋｕで暗号化されているため、ＵＡＳ５でのみ暗号化を解除することができる。
【００４４】
＜ユーザ情報部（ＡＣＣＥＰＴＥＤトークン）＞
ＡＣＣＥＰＴＥＤトークンは、ＳＩＰを使う場合に、ＵＡＳ５（着信者）からＵＡＣ１（発信者）へ送られるトークンにおける情報交換用の情報であり、ＵＡＣ４から伝えられた鍵Ｋｔで暗号化される。
【００４５】
発信者への情報は、鍵Ｋｔで暗号化され、ＱｏＳライフタイム、トークンライフタイム、シーケンス番号、セッション情報、時差から構成する。ＱｏＳライフタイムは、セッション情報群のＱｏＳライフタイムと同じである。トークンライフタイムは、発行機関情報のトークンライフタイムと同値である。シーケンス番号は、ＳＩＰ用情報の次回シーケンスと同値であり、ＵＡＣ４はこれを見て、次回のＲＥＦＲＥＳＨトークンにこの値を用いてトークンを形成する。セッション情報は、ＱｏＳコントロール情報部のセッション情報と同じ（ＱｏＳコントロール部はＥＨが解読できないため）である。時差は、着信者が送ってきた時刻との差分を時差とすることによって、およそどのぐらい着信者と時刻がずれているかがわかるため、それを送信者に伝える。送信者は次回トークンを送る際に、この値を後述のタイムスタンプに加えることによって、時刻基準をおよそ併せることができる。
【００４６】
ＳＩＰ用情報は、ＵＡＳ５が参照する情報でありＵＡＳ５の鍵Ｋｕで暗号化され、スクランブル用（同じデータが載ると暗号化の結果が同じ値になるため）タイムスタンプと次回シーケンス番号とから構成する。なお、ＱｏＳライフタイム、トークンライフタイム等の情報が不正に書き換えられた場合には、ルータにおいて検出可能なので、破棄またはエラーが返されることになる。
【００４７】
＜ユーザ情報部（ＩＮＩＴＩＡＬトークン）＞
ＩＮＩＴＩＡＬトークンに関しては鍵Ｋｔではなくユーザ鍵Ｋｕで暗号化される。スクランブル用（同じデータが載ると暗号化の結果が同じ値になるため）タイムスタンプ、ユーザＩＤ、ユーザが生成した一時鍵Ｋｔ、公開鍵ペアＫｕａｓ、Ｋｕａｐから構成する。公開鍵ペアＫｕａｓ、Ｋｕａｐは、ＳＩＰ通信のときにのみ載せる情報で、鍵Ｋｕａｓ、Ｋｕａｐはセッション毎に生成するのが望ましい。
【００４８】
＜ユーザ情報部（ＲＥＦＲＥＳＨトークン）＞
ＲＥＦＲＥＳＨトークンは、直前に受信したＡＰＰＳ（またはＵＡＳ）からのシーケンス番号を格納するシーケンス番号とＳＩＰ用情報とから構成する。ＳＩＰ用情報は、ＵＡＳ５から受け取ったＡＣＣＥＰＴＥＤトークンにＳＩＰ用情報が含まれている場合も同様にそのまま格納する。なお、この情報はＵＡＳ５の鍵Ｋｕで暗号化されているため、ＵＡＣ４は解読できない。なお、ＵＡＳ５がＳＩＰ用情報を受け取った場合、それを解読してＳＩＰ情報内のシーケンス番号とＳＩＰ用情報の外側のシーケンス情報（シーケンス番号）を比較することで、ＡＰＰＳ２での再送攻撃防御と同じことが可能となる。また、ＳＩＰアプリケーションではない場合（すなわちＡＰＰＳとの通信を行う場合）には、ＳＩＰ用情報は付加されない。
【００４９】
＜ユーザ情報部（ＲＥＱＵＥＳＴトークン）＞
ＲＥＱＵＥＳＴトークンは、シーケンス番号（特に意味を成さないため、０となる）と
ＳＩＰ用情報とから構成する。ＳＩＰ用情報は、ＵＡＣ４がＳＩＰサーバから受け取ったＡＵＴＨＥＮＴＩＣＡＴＥＤトークンのユーザ情報部にＳＩＰ用情報が含まれていた場合、その直後にＵＡＳ５に送信するＲＥＱＵＥＳＴトークンにそのまま格納する。なお、この情報はＵＡＳ５の鍵Ｋｕで暗号化されているため、ＵＡＣ４は解読できない。
【００５０】
＜タイムスタンプ・認証子部＞
タイムスタンプ・認証子部は、トークンが正当なものであるかを検証するための情報である。ここでいう正当性とは、正しいエンドノード同士がやり取りしているトークンであることである。クライアント・サーバモデルにおいては、ユーザ端末１とＡＰＰＳ２が共通の鍵Ｋｔを保持しているため、これを用いてトークン全体のＨＭＡＣ−ＭＤ５（鍵付きハッシュ関数）などのメッセージ認証子を付加する。ＵＡＣ４−ＵＡＳ５間のトークンの場合には、ＵＡＣ４およびＵＡＳ５はＳＩＰ用情報で交換された秘密鍵Ｋｕａｓを利用してデジタル署名を付加する。正当性は、同様にデジタル署名を計算して同じ値が得られたか否かで判断する。また途中のエッジルータは、ＱｏＳコントロール情報の中に格納された鍵Ｋｕａｐを用いてデジタル署名を検証し、正しければＱｏＳの設定（ライフタイムの更新）を行い、正しくなければ破棄、またはエラーを返す。タイムスタンプは、再送攻撃防御に用いられ、時差を加味して記入する。一定時間以上過去の時刻から来たトークンは受信側で破棄する。認証子は、ＨＭＡＣ−ＭＤ５などのメッセージ認証子またはデジタル署名で構成する。
【００５１】
次に、セッション情報について説明する。ユーザ端末１（ＵＡＣ、ＵＡＳも同様）およびＡＰＰＳ２（ＳＩＰサーバもＡＰＰＳと同じ扱いである）はそれぞれがセッションを管理し、それぞれに対してトークンによるＱｏＳリフレッシュを行うが、本発明による方法は、資源管理サーバ３は必ずしもセッションを管理する必要はない。ただし、ＱｏＳ管理部３３がＱｏＳ割り当てに際してそれを必要とするのであれば、管理する必要がある。セッション情報エントリの構成要素としては、自ＩＰアドレス、自ポート番号、相手のＩＰアドレス、ポート番号、ユーザＩＤ、一時鍵Ｋｔ、シーケンス番号（着信側から前回受信したトークンに含まれていた値を記憶する）、ＱｏＳライフタイム、トークンライフタイム、時差（ユーザ端末１、ＵＡＣ４だけに有効）、公開鍵ペアＫｕａｓ、Ｋｕａｐ（ＳＩＰを利用する際に必要）、サーバ情報部（ＳＩＰサーバからのトークンについていたサーバ情報部だけを保存しておく）、関連セッション情報（ＳＩＰを利用する際に必要）が上げられる。ただし、関連セッション情報は、ＵＡＣ４はＳＩＰサーバとのセッションとＵＡＳ５とのセッションを関連付けしておかなければならない。
【００５２】
次に、図４を参照して、ユーザ端末１がＡＰＰＳ２と通信するクライアント・サーバモデルにおけるセッション開始時の処理動作を説明する。まず、ユーザ端末１とＡＰＰＳ２が通信を開始すると、ユーザ端末１はＡＰＰＳ２へＩＮＩＴＩＡＬトークンを送り、一時鍵ＫｔとユーザＩＤを伝える（ステップＳ１）。その際、ユーザ端末１上でもセッション情報エントリを確立し、受信したＡＰＰＳ２も同様にセッション情報エントリを確立する。これは、このセッションに関してＱｏＳコントロールを行うための管理情報である。ＩＮＩＴＩＡＬトークンのＳｅｓｓｉｏｎ部に含まれるユーザＩＤは、ＩＰアドレスやＵＲＩなどの情報でで構成される。また、ユーザ情報部に含まれる一時鍵Ｋｔ（およびタイムスタンプなど）はＫｕで暗号化する。また、ＡＰＰＳ２は後の処理のためにこのＩＮＩＴＩＡＬトークンを当該セッションに紐付けてしばらく保持しておく。ここでは、ＩＮＩＴＩＡＬトークンの送信タイミングが、データ通信開始後になっているが、これは前後が逆になってもよい。重要なのはアプリケーションレベルで行われる認証手順が完了する前にＩＮＩＴＩＡＬトークンがＡＰＰＳ２に届いていることである。
【００５３】
次に、ＡＰＰＳ２は通常通りアプリケーションでユーザ認証を行う（ステップＳ２）。ここで行う認証方式自体はアプリケーションに依存する。そして、認証が成功した場合、ＡＰＰＳ２は、資源管理サーバ３へＱｏＳ生成要求を送る（ステップＳ３）。このとき、ＡＰＰＳ２は、内部に保持しているＩＮＩＴＩＡＬトークンの内容をそのまま受け渡す。
【００５４】
次に、資源管理サーバ３は、トークン内のＳｅｓｓｉｏｎ部のユーザＩＤを基にユーザ鍵を取得し、ユーザ情報部を解読して一時鍵Ｋｔを得る。そして、資源管理サーバ３は、ＱｏＳ管理部３３に対してそのユーザへ割り当てるべきＱｏＳを問い合わせ、トークンに含まれるＱｏＳコントロール情報、発行機関情報を生成し、その他の部分はダミー情報でもよい。ＱｏＳコントロール情報部のセッション情報群は１セッション分とし、着信側をＡＰＰＳ２、発信側をユーザ端末１とする。続いて、資源管理サーバ３は、作成したトークンと、一時鍵ＫｔをＡＰＰＳ２に伝えることによりトークン応答を送信する（ステップＳ４）。これによりＡＰＰＳ２はセッション情報エントリを完成させる。
【００５５】
次に、ＡＰＰＳ２は受信したトークンにさらにサーバ情報部とユーザ情報部、タイムスタンプ・認証子部を生成しＡＵＴＨＥＮＴＩＣＡＴＥＤトークンとしてユーザ端末１に送信する（ステップＳ５）。ユーザ情報部には、トークンのＱｏＳコントロール部から抜き出したセッション情報、次回受け取るべきシーケンス番号（次のサーバ情報部と同じ値）を含め、取得した一時鍵Ｋｔで暗号化する。なお、ＱｏＳコントロール部は、ＡＰＰＳ２が公開鍵Ｋａｐを所持しているため解読できる。また、サーバ情報部は、次回受け取るべきシーケンス番号、およびその他必要な情報をＡＰＰＳ２独自の鍵Ｋａｐｐで暗号化する。また認証子は一時鍵Ｋｔを用いた鍵付ハッシュ（例えばＨＭＡＣ−ＭＤ５など）とし、計算範囲は、トークン全体とし、認証子部を０として計算する。
【００５６】
次に、ＡＰＰＳ２とユーザ端末１の間のエッジルータは、ＡＵＴＨＥＮＴＩＣＡＴＥＤトークンのＱｏＳコントロール部をチェックし、このセッションに関するＱｏＳの設定（Ｄｉｆｆｓｅｒｖ）を行う。ここで行うチェック内容は、ＱｏＳコントロール部が公開鍵Ｋｑｐで正しく解読できること、トークンライフタイムが期限切れになっていないこと、受け取ったトークンのＩＰヘッダの宛先アドレスがセッション情報の発信側、ＩＰヘッダの送信元アドレスがセッション情報の着信側となっていること、すなわち方向性が着信側からのＡＵＴＨＥＮＴＩＣＡＴＥＤであることである。
【００５７】
次に、ＡＵＴＨＥＮＴＩＣＡＴＥＤトークンを受信したユーザ端末１は、Ｓｅｓｓｉｏｎ部を基にセッション情報エントリを検索し、一時鍵Ｋｔで受信トークンのユーザ情報部を解読し、セッション情報エントリを完成する。同時に、リフレッシュを行うためのタイマ管理を開始する。また、受信したトークンのタイムスタンプと、ユーザ端末１自身の時刻との差を計算し、その値をセッション情報エントリの時差に格納する。この時差は次回以降のＲＥＦＲＥＳＨトークン送信時に利用する。
【００５８】
なお、各エッジルータがＤｉｆｆｓｅｒｖの設定を行う際には、セッション毎にライフタイムを設定し、期間が満了すればそのエントリを削除する。なおそのライフタイムが、トークンのＱｏＳコントロール部のＱｏＳライフタイムである。ライフタイムが満了する前に、次のＡＵＴＨＥＮＴＩＣＡＴＥＤトークンによってライフタイムを更新（リフレッシュ）する必要がある。また、受信したトークンのタイムスタンプが大きく現在時刻よりずれていれば（例えば１０秒以上）、再送攻撃を防ぐためそのトークンは破棄する。
【００５９】
次に、図５を参照して、セッション継続中のＱｏＳを維持する動作を説明する。ユーザ端末１（発信側）で各セッションに関するＱｏＳライフタイムを監視しておき、期限の半分程度の時間が経過した段階で、ＲＥＦＲＥＳＨトークンをＡＰＰＳ２に対して送信する（ステップＳ１１）。このとき、セッション情報エントリのシーケンス番号をユーザ情報部に格納し一時鍵Ｋｔで暗号化し、セッション情報エントリの時差の分だけ時刻を調整してタイムスタンプをＲＥＦＲＥＳＨトークンに格納するとともに、一時鍵Ｋｔを用いて認証子を計算する。
【００６０】
次に、ＡＰＰＳ２は受信したトークンのサーバ情報部を解読してシーケンス番号を取得するとともに、Ｓｅｓｓｉｏｎ部を基に一時鍵Ｋｔを検索し、ユーザ情報を解読してその中のシーケンス番号と一致するか否かをチェックする。さらに、その一時鍵Ｋｔ使って認証子を計算して検証する。また、ＱｏＳコントロール部または発行機関情報部のトークンライフタイムが失効していないか否かをチェックする。そして、トークンライフタイムが失効していれば、そのトークンを破棄し、該当セッション情報エントリも破棄する。また、ＡＰＰＳ２は、トークンライフタイムの残りが期限の半分程度まで減っていれば、再度ＱｏＳ生成要求を資源管理サーバ３へ送り（ステップＳ１２）、トークン応答を受ける（ステップＳ１３）。
【００６１】
先に行ったチェックの結果、特に問題が無い場合、または、資源管理サーバ３からトークン応答を受けた場合、ＡＰＰＳ２は、シーケンス番号をランダムに決めることによって更新して、サーバ情報部、ユーザ情報部に格納し（同じ値）、それぞれ暗号鍵で暗号化しＡＵＴＨＥＮＴＩＣＡＴＥＤトークンをユーザ端末１へ送信する（ステップＳ１４）。ＡＰＰＳ２とユーザ端末１と間のエッジルータは、ＡＵＴＨＥＮＴＩＣＡＴＥＤトークンのＱｏＳコントロール部をチェックし、当該セッションに関するＱｏＳの設定（ライフタイムの更新）を行う。また、ＲＥＦＲＥＳＨトークンを受信したユーザ端末１は、セッション情報エントリを更新し、リフレッシュ行うためのタイマも更新し、受信したトークンのタイムスタンプと、ユーザ端末１自身の時刻との差を計算し、その値をセッション情報エントリの時差に格納する。この時差は次回以降のＲＥＦＲＥＳＨトークン送信時に利用する。なお、ＲＥＦＲＥＳＨトークン、またはＡＵＴＨＥＮＴＩＣＡＴＥＤトークンを受信したノードに該当するセッションが無ければ、そのトークンを無視する。
【００６２】
次に、図６、図７を参照して、ＵＡＣ４がＳＩＰサーバ６１、６２を経由してＵＡＳ５とのセッションを確立した後ＵＡＣ４とＵＡＳ５が直接通信するＳＩＰを利用したＰ２Ｐモデルにおけるセッション開始時の動作を説明する。ここでは、ＳＩＰサーバ６１、６２はクライアントサーバモデルのサーバ、ＵＡＣ４はクライアントと見なすことができるものとして説明する。
【００６３】
まず、ＳＩＰ  ＩＮＶＩＴＥ後に、ＵＡＣ４は、ＩＮＩＴＩＡＬトークンをＳＩＰサーバ６２に対して送信する（ステップＳ２１）。このＩＮＩＴＩＡＬトークンには、公開鍵ペアＫｕａｓ、Ｋｕａｐが含まれる。これを受けて、ＳＩＰサーバ６２はＩＮＩＴＩＡＬトークン受信によって、セッション情報エントリを作成する。この時点では、ＵＡＣ４とＳＩＰサーバ６２のアドレス、ポート番号、ユーザＩＤのみエントリに登録する。これら以外は暗号化されているため解読できない。さらに、後の処理のためにＩＮＩＴＩＡＬトークンを当該セッションに紐付けてしばらく保持しておく。以後のＳＩＰ認証に失敗した場合には、当該セッションエントリを削除し、以下のトークンに関連する処理も行われない。
【００６４】
次に、ＳＩＰ  ＩＮＶＩＴＥメッセージがＵＡＳ５最寄のＳＩＰサーバ６１に到達すると、ＳＩＰサーバ６１は、ＴＥＮＴＡＴＩＶＥトークンをＵＡＳ５に対して送信する（ステップＳ２２）。ここで、通知される情報は、ＳＩＰサーバ６１のＩＰアドレス、ポート番号（ＳＩＰシグナル用）、およびＵＡＣ４のＩＰアドレスとポート番号である。このとき、ある程度の時間がたっても、所定の手順が発生しなければ、このエントリは削除する。
【００６５】
次に、ＴＥＮＴＡＴＩＶＥトークンを受信したＵＡＳ５は、単に将来セッションができそうであるということだけを認識し、セッション情報エントリを作成し、ＳＩＰサーバ６１のアドレス、ポート番号を関連セッション情報として保存する。続いて、ＳＩＰサーバ６１はＳＩＰ  ＩＮＶＩＴＥをＵＡＳ５に送信する（ステップＳ２３）。ＴＥＮＴＡＴＩＶＥトークンによって作成されたセッション情報エントリによって、ＵＡＳ５はこのＳＩＰシグナリングに関するセッションが既存セッションであると認識できる。すなわち、ＩＰアドレス、ポート番号、関連セッション情報がＳＩＰ  ＩＮＶＩＴＥの情報と一致しているため既存セッションであると認識できる。この時点でＵＡＳ５はトークンに関する処理は何も行わない。
【００６６】
次に、ＵＡＳ５はＳＩＰサーバ６２、６１経由で「ＳＩＰ  ２００／ＯＫ」を返す（ステップＳ２４、Ｓ２５）。ＵＡＣ４最寄のＳＩＰサーバ６２が「ＳＩＰ  ２００／ＯＫ」を受信することによって、ＵＡＣ４およびＵＡＳ５のメディア情報（ＵＡＣ４、ＵＡＳ５がお互いに直接データ通信に用いるＩＰアドレス、ポート番号）およびＵＡＳ５のユーザＩＤを知ることができる。このＳＩＰサーバのセッション情報エントリの関連セッション情報にＵＡＳ５の情報を登録する。
【００６７】
次に、ＳＩＰサーバ６２先に入手したＩＮＩＴＩＡＬトークンと、ＵＡＣ４、ＵＡＳ５のメディア情報とユーザＩＤを、ＱｏＳ生成要求として資源管理サーバ３に送信する（ステップＳ２６）。これを受けて、資源管理サーバ３は、トークン内のＳｅｓｓｉｏｎ部のユーザＩＤを基にユーザ鍵を取得し、ユーザ情報部を解読してＵＡＣ４の一時鍵Ｋｔを得る。続いて、資源管理サーバ３は、ＱｏＳ管理部３３へそのユーザへ割り当てるべきＱｏＳを問い合わせ、トークンを生成する。この際に、ユーザ情報部に含まれていた公開鍵ＫｕａｐをＱｏＳコントロール部に含める。また、ＱｏＳコントロール情報、発行機関情報を構成し、ユーザ情報部にはＵＡＳ５へ通知するべき情報であるＳＩＰ用情報をＵＡＳ５のユーザ鍵Ｋｕで暗号化したものを格納する。そのため、ＵＡＳ５のユーザＩＤからＵＡＳのＫｕを検索しておく必要がある。その他の部分はダミー情報とする。また、ＱｏＳコントロール情報部のセッション情報群は２セッション分とし、［着信側、発信側］＝［ＳＩＰサーバ、ＵＡＣ］および［ＵＡＳ、ＵＡＣ］とする。ただし、ＳＩＰサーバとＵＡＣ間のＱｏＳ設定が不要であれば、（ＳＩＰサーバ、ＵＡＣ）のセッション情報は省き、１セッション分としてもよい。
【００６８】
次に、作成したトークンと、取り出した一時鍵ＫｔをＳＩＰサーバ６２へ伝え、トークン応答を行う（ステップＳ２７）。そして、ＳＩＰサーバ６２はセッション情報エントリを完成させる。ＱｏＳコントロール部にＳＩＰサーバ、ＵＡＣ間のセッション情報がない場合でも、セッション情報エントリは登録する必要がある。これは、結果としてはトークンによるＱｏＳ設定は為されないが、セッション管理を行わなければ、ＵＡＣがトークンの更新を行うことができなくなるためである。なお、資源管理サーバ３から受信したトークンのユーザ情報部にはＳＩＰ用情報がすでに含まれているため、ＳＩＰサーバでは、さらにＵＡＣ向けの通常のユーザ情報を追記する。
【００６９】
次に、ＳＩＰサーバ６２は受信したトークンにさらにサーバ情報部とユーザ情報部、タイムスタンプ・認証子部を生成しＡＵＴＨＥＮＴＩＣＡＴＥＤトークンとしてＵＡＣに送信する（ステップＳ２８）。ＳＩＰサーバ６１、６２、ＵＡＣ４間のエッジルータは、ＡＵＴＨＥＮＴＩＣＡＴＥＤトークンのＱｏＳコントロール部をチェックし、当該セッションに関する記述があればＱｏＳの設定（Ｄｉｆｆｓｅｒｖ）を行う。
【００７０】
次に、ＡＵＴＨＥＮＴＩＣＡＴＥＤトークンを受信したＵＡＣ４は、Ｓｅｓｓｉｏｎ部を基にセッション情報エントリを検索し、一時鍵Ｋｔで受信トークンのユーザ情報部を解読し、セッション情報エントリを完成する。セッション情報として登録されるのは、ＵＡＳ−ＵＡＣ間およびＵＡＣ−ＳＩＰサーバ間のセッションに関するものである。そして、ＵＡＣ−ＵＡＳ間の通信時に書き換えられるためトークンのサーバ情報部をセッション情報エントリに保存しておく。
【００７１】
次に、ＵＡＣ４はＡＵＴＨＥＮＴＩＣＡＴＥＤトークンを変形して、ＲＥＱＵＥＳＴトークンとしてＵＡＳ５へ送信する（ステップＳ２９）。ＡＵＴＨＥＮＴＩＣＡＴＥＤトークンのユーザ情報部は一時鍵Ｋｔで解読したあと、ＳＩＰ用情報の部分だけを新たなユーザ情報部とする。暗号化はすでにＵＡＳのＫｕで為されているので不要である。ＵＡＣ−ＵＡＳ間で送受されるトークンには、認証子の部分にＨＭＡＣ−ＭＤ５ではなく、ディジタル署名を用いる。この署名は、ＵＡＣが生成した秘密鍵Ｋｕａｓを用い、計算範囲は、ＨＭＡＣ−ＭＤ５を用いた場合と同様である。
【００７２】
ＵＡＳ５はＲＥＱＵＥＳＴトークンを受信すると、トークンのＳｅｓｓｉｏｎ部からセッション情報エントリを検索して該当するセッションがあるか否かを確認し、あればユーザ情報部を自身のＫｕで解読し、なければ、トークンを破棄する。また、ユーザ情報部から秘密鍵Ｋｕａｓ、一時鍵Ｋｔ等の情報を読み取り、セッション情報エントリに登録する。そして、ＵＡＳ５はＡＣＣＥＰＴＥＤトークンを作成し、ＵＡＣ４へ送信する（ステップＳ３０）。ユーザ情報部にはもともとのセッション情報とシーケンス番号に０を格納し、一時鍵Ｋｔで暗号化する。また、サーバ情報部にＵＡＳ５が発生したシーケンス番号を格納し、一時鍵Ｋｔで暗号化し、認証子の部分にＨＭＡＣ−ＭＤ５ではなく、ディジタル署名を用いる。この署名は、ＵＡＣ４が生成した秘密鍵Ｋｕａｓを用いる。
【００７３】
次に、ＵＡＣ−ＵＡＳ間のエッジルータは、ＱｏＳコントロール部のセッション情報群をチェックする。ＵＡＣ−ＵＡＳ間のセッションに関して、Ｐ２Ｐフラグがセットされているため、ＱｏＳコントロール部に含まれている公開鍵Ｋｕａｐを用いて、トークンに付加されているディジタル署名を検証し、正しければ、ＱｏＳの設定を行い、正しくなければ、その場で破棄する。
【００７４】
次に、ＡＣＣＥＰＴＥＤトークンを受信したＵＡＣ４は、Ｓｅｓｓｉｏｎ部を基にセッション情報エントリを検索し、Ｋｔで受信トークンのユーザ情報部を解読し、セッション情報エントリを完成する。また、サーバ情報部も解読し、次回シーケンス番号として登録しておくと同時に、リフレッシュを行うためのタイマ管理を開始する。時差の取り扱いは、前述した手順と同様である。以上の動作によって、ＵＡＣ−ＵＡＳ間のＱｏＳが設定されることになる。
【００７５】
なお、図６においてはＩＮＩＴＩＡＬトークンの送信タイミングが、ＳＩＰ  ＩＮＶＩＴＥ後になっているが、これは前後が逆になってもよい。重要なのはＳＩＰレベルで行われる認証手順が完了する前にＩＮＩＴＩＡＬトークンがサーバに届いていることである。また、ＳＩＰの認証が行われない場合には、認証成功とみなしてよい。また、図６においてはＵＡＣメディア情報をＳＩＰ認証の後で取得するようになっているが、最初のＩＮＶＩＴＥ後（その場合ＩＮＩＴＩＡＬトークンの方が先に届いている必要がある）、ＵＡＳからの２００／ＯＫ受信後でもよい。また、ＳＩＰを用いる場合、ユーザＩＤはＵＲＩであるのが望ましい。
【００７６】
次に、図８を参照して、セッション継続中のＵＡＣ−ＵＡＳ間のＱｏＳを維持する動作を説明する。まず、ＵＡＣ４（発信側）で各セッションに関するＱｏＳライフタイムを監視しておき、期限の半分程度の時間が経過した段階で、ＵＡＣ４は、ＲＥＦＲＥＳＨトークンをＵＡＳ５に送信する（ステップＳ４１）。ユーザ情報は前回取得したシーケンス番号（次回シーケンス番号）で、一時鍵Ｋｔで暗号化する。
【００７７】
ＵＡＳ５はＲＥＦＲＥＳＨトークンを受信すると、トークンのＳｅｓｓｉｏｎ部からセッション情報エントリを検索して該当するセッションがあるか否かを確認し、あれば、ユーザ情報部とサーバ情報部を一時鍵Ｋｔで解読し、シーケンス番号があっているか否かをさらにチェックし、あっていなければトークンを破棄する。また、該当するセッションがなければトークンを破棄する。そして、ＵＡＳ５はＡＣＣＥＰＴＥＤトークンを作成し、ＵＡＣ４へ送信する（ステップＳ４２）。
【００７８】
次に、ＵＡＣ−ＵＡＳ間のエッジルータは、ＱｏＳコントロール部のセッション情報群をチェックする。ＵＡＣ−ＵＡＳ間のセッションに関して、Ｐ２Ｐフラグがセットされているため、ＱｏＳコントロール部に含まれている公開鍵Ｋｕａｐを用いて、トークンに付加されているディジタル署名を検証し、正しければ当該セッションに関するライフタイムを更新する。ＡＣＣＥＰＴＥＤトークンを受信したＵＡＣ４は、Ｓｅｓｓｉｏｎ部を基にセッション情報エントリを検索し、一時鍵Ｋｔで受信トークンのユーザ情報部を解読し、セッション情報エントリを完成する。また、サーバ情報部も解読し、次回シーケンス番号として登録しておく。同時に、リフレッシュを行うためのタイマ管理を更新する。
【００７９】
図９に示すように、ＵＡＣ−ＳＩＰサーバ間のトークンリフレッシュの場合には、ＳＩＰサーバがＵＡＣ４から受信したＲＥＦＲＥＳＨトークン（ステップＳ５１）を資源管理サーバ３へＱｏＳ要求として送信し（ステップＳ５１）、このトークン応答（ステップＳ５２）に基づいて、ＳＩＰサーバ６２がＵＡＣ４に対して、ＡＵＴＨＥＮＴＩＣＡＴＥＤトークンを送信する（ステップＳ５３）ことによって、トークンライフタイムが更新される。資源管理サーバ３で必要なほとんどの情報はＱｏＳコントロール部と発行機関情報部に記述されており、もし公開鍵を作り直したい場合には、ＵＡＣ４はこのＲＥＦＲＥＳＨのタイミングで新たな公開鍵ペアを生成してユーザ情報部に組み込めばよい。なお、ＵＡＣ−ＳＩＰサーバ間のリフレッシュはトークンライフタイムを更新するために必須である。また、トークンが更新されたので、ＡＵＴＨＥＮＴＩＣＡＴＥＤトークンのユーザ情報部には新たにＳＩＰ用情報が含まれており、ＵＡＣはＡＵＴＨＥＮＴＩＣＡＴＥＤトークン受信後に、図７のＳ２９、Ｓ３０と全く同様にしてＵＡＳへＲＥＱＵＥＳＴトークンを送信し、ＡＣＣＥＰＴＥＤトークンを受信する必要がある。 
【００８０】
このように、トークンを用いることにより、ルータに設定されるＱｏＳの維持管理（ライフタイム更新）処理を分散することができるため、中央のサーバがすべてを管理する必要がなくなり、ネットワークシステム全体の効率を向上させることができる。また、ＱｏＳ設定を行える方向性を導入することにより、不正な資源割り当て要求を防ぐことができる。また、ＳＩＰを用いたＰ２Ｐ通信についても、ＳＩＰクライアント間のＱｏＳを同様に管理することができる。
【図面の簡単な説明】
【００８１】
【図１】本発明の一実施形態におけるネットワークシステム全体の構成を示す図である。
【図２】図１に示す資源管理サーバ３の構成を示すブロック図である。
【図３】トークンの構成を示す説明図である。
【図４】図１に示すシステムにおける資源割り当て動作を示すシーケンス図である。
【図５】図１に示すシステムにおける資源割り当て動作を示すシーケンス図である。
【図６】図１に示すシステムにおける資源割り当て動作を示すシーケンス図である。
【図７】図１に示すシステムにおける資源割り当て動作を示すシーケンス図である。
【図８】図１に示すシステムにおける資源割り当て動作を示すシーケンス図である。
【図９】図１に示すシステムにおける資源割り当て動作を示すシーケンス図である。
【図１０】従来技術によるＣＯＰＳ−ＲＳＶＰの動作を示す説明図である。
【図１１】従来技術によるセッションを意識した資源割り当ての動作を示す説明図である。
【符号の説明】
【００８２】
１・・・ユーザ端末（ＥＨ）、２・・・アプリケーションサーバ（ＡＰＰＳ）、３・・・資源管理サーバ（ＲＳ）、３１・・・ユーザ情報管理部、３２・・・シグナリング処理部、３３・・・ＱｏＳ管理部、４・・・ＳＩＰクライアント（ＵＡＣ）、５・・・ＳＩＰクライアント（ＵＡＳ）、６１、６２・・・ＳＩＰサーバ、７１〜７６、８・・・ルータ
【図１】
2008263421.tif 000003
【図２】
2008263421.tif 000004
【図３】
2008263421.tif 000005
【図４】
2008263421.tif 000006
【図５】
2008263421.tif 000007
【図６】
2008263421.tif 000008
【図７】
2008263421.tif 000009
【図８】
2008263421.tif 000010
【図９】
2008263421.tif 000011
【図１０】
2008263421.tif 000012
【図１１】
2008263421.tif 000013