JP4615005B2 - 経路計算装置におけるセッション管理方法およびその経路計算装置 - Google Patents

Description

複数のノードと複数のリンクから構成されるドメインが複数存在し、１つ以上のドメインに対応して１つ以上の経路計算装置が存在し、各経路計算装置は対応する１つ以上ドメインのネットワーク情報のみを把握し、経路計算要求装置と経路計算装置、および経路計算装置と経路計算装置が、プロトコル通信を行うことで、同じもしくは異なるドメインに存在する始点ノードと終点ノードの経路を計算する経路計算装置を備えたネットワークにおいて、経路計算装置におけるセッション管理方法およびその経路計算装置に関する。

従来、複数のノードと複数のリンクから構成されるドメインが複数存在し、１つ以上のドメインに対応して１つ以上の経路計算装置が存在し、各経路計算装置は対応する１つ以上ドメインのネットワーク情報のみを把握し、経路計算要求装置と経路計算装置、および経路計算装置と経路計算装置が、プロトコル通信を行うことで、同じもしくは異なるドメインに存在する始点ノードと終点ノードの経路を計算する経路計算装置を備えたネットワークにおいて、ＰＣＥＰ（Path Computation Element communication Protocol）およびＢＲＰＣ（Backward Recursive PCE-based Computation）がある（非特許文献１、２）。

なお、ドメインの例としては、ＡＳ（Autonomous System）やＩＧＰ（Interior Gateway Protocol）のＡｒｅａが挙げられる。
なお、経路計算要求装置の例としてはノードや管理システムが挙げられる。

この方法では、ＰＣＥＰにより経路計算要求装置と経路計算装置、および経路計算装置と経路計算装置が、プロトコル通信を行い、ＢＲＰＣにより複数の経路計算装置が連携した経路計算を行う。プロトコル通信を行う上で、ＰＣＥＰセッションを確立する。ＰＣＥＰセッションにより通信を行う経路計算要求装置もしくは経路計算装置はＰＣＥＰピアと呼び、１つのＰＣＥＰセッションは２つのＰＣＥＰピアをもつ。経路計算要求を行うＰＣＥＰピアをＰＣＣ（Path Computation Client）、経路計算要求を受け取り経路計算を行いＰＣＣに経路計算応答を行うＰＣＥＰピアをＰＣＥ（Path Computation Element）と呼ぶ。

図１の例では、経路計算装置１がドメイン１、経路計算装置２がドメイン２、経路計算装置３がドメイン３のネットワーク情報を把握しており、ノード１と経路計算装置１、経路計算装置１と経路計算装置２、経路計算装置２と経路計算装置３、がＰＣＥＰによりプロトコル通信を行い、以下のようにノード１とノード１１の間の経路が計算される。

（１）ノード１が、経路計算装置１に対して、ノード１からノード１１の経路計算要求メッセージ（ＰＣＲｅｑ）を送信する。
（２）経路計算装置１が、ノード１１に到達するには、経路計算装置２を経由することを判断する。
（３）経路計算装置１が、経路計算装置２に経路計算要求メッセージを送信する。
（４）経路計算装置２が、ノード１１に到達するには、経路計算装置３を経由することを判断する。
（５）経路計算装置２が、経路計算装置３に経路計算要求メッセージを送信する。
（６）経路計算装置３が、ノード１１が自身の管理しているノードであることを判断し、ドメイン３のネットワーク情報を用い、経路計算要求メッセージを送信してきた経路計算装置２が属するドメインであるドメイン２と接続されるリンク（ノード７とノード９の間のリンク、およびノード８とノード１０の間のリンク）から、ノード１１への経路を計算し、経路および経路のコスト（例:ホップ数）を経路計算結果とする。
（７）経路計算装置３が、経路計算装置２に、上記（６）で求めた経路計算結果を含む経路計算応答メッセージ（ＰＣＲｅｐ）を送信する。
（８）経路計算装置２が、ドメイン２のネットワーク情報と経路計算装置３から受信した経路計算結果をつなぎあわせたものを用い、経路計算要求メッセージを送信してきた経路計算装置１が属するドメインであるドメイン１と接続されるリンク（ノード２とノード４の間のリンク、およびノード３とノード５の間のリンク）から、ノード１１への経路を計算し、経路および経路のコスト（例:ホップ数）を経路計算結果とする。
（９）経路計算装置２が、経路計算装置１に、上記（８）で求めた経路計算結果を含む経路計算応答メッセージを送信する。
（１０）経路計算装置１が、ドメイン１のネットワーク情報と経路計算装置２から受信した経路計算結果をつなぎあわせたものを用い、ノード１から送信された経路計算要求メッセージに含まれる始点ノードであるノード１から、ノード１１への経路を計算し、経路および経路のコスト（例:ホップ数）を経路計算結果とする。
（１１）経路計算装置１が、ノード１に、上記（１０）で求めた経路計算結果を含む経路計算応答メッセージを送信する。

「Path Computation Element (PCE〉 communication Protocol (PCEP)」、２００７年７月掲載、[２００７年８月検索]、インターネット＜http://www.ietf.org/internet-drafts/draft-ietf-ＰＣＥ-ＰＣＥp-08.txt＞ 「A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Path」、２００７年６月掲載、［２００７年８月検索］、インターネット＜http://www.ietf.org/internet-drafts/draft-ietf-ＰＣＥ-brpc-05.txt＞

しかしながら、従来手法では、経路計算装置の具体的な実現手段については記載はない。経路計算装置では、以下の機能が必要となるが、その実現方法について記載はない。

経路計算装置１において、上記（３）で経路計算装置２に経路計算要求メッセージを送信するための、プロトコル手段のセッション管理（同様に上記（５）で経路計算装置２におけるセッション管理）。

経由する経路計算装置の順序の管理。具体的には、経路計算装置１において、上記（１）でノード１から受信した経路計算要求メッセージと、上記（３）で経路計算装置２に送信した経路計算要求メッセージの関連付け。上記（３）で経路計算装置２に送信した経路計算要求メッセージと、上記（９）で経路計算装置２から受信した経路計算応答メッセージの関連付けは、経路計算装置１が付与するリクエストＩＤを経路計算要求メッセージと経路計算応答メッセージに含めることより可能であるが、上記（１）でノード１から受信した経路計算要求メッセージのリクエストＩＤと、上記（３）で経路計算装置２に送信した経路計算要求メッセージのリクエストＩＤは、独立であるため経路計算装置１で関連付けを保持する必要がある。この関連付けにより、経路計算装置１は、上記（１０）（１１）の処理が可能となる（同様に経路計算装置２におけるリクエストＩＤ関連付けが必要になる）。

一般的な経路計算装置の構成として、図２−１が考えられる。例えばプロトコル手段はプロセスとして実現され、プロセスごとにＰＣＥＰセッションを保持し、ノードもしくは他の経路計算装置とプロトコル通信を行う。図２-１の構成の場合、セッション管理やリクエストＩＤ関連付けを経路計算手段が実施することになり、経路計算手段とプロトコル手段の間の受け渡し情報が複雑になる。

このため、経路計算手段とプロトコル手段の独立性が悪くなり、例えば経路計算を高度化する際に、修正部分が大きくなったり、修正すべき部分が不明確になるなど、プログラム開発が非効率になる。

本発明の目的は、経路計算手段とプロトコル手段の独立性を高くした経路計算装置におけるセッション管理方法およびその経路計算装置を提供することにある。

本明細書において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明では、経路計算手段とプロトコル手段とは独立した、セッション管理手段を導入することにより、経路計算手段とプロトコル手段の独立性を高くし、プログラム開発の効率化を実現することを特徴とする。

請求項１によれば、経路計算装置は、プロトコル手段と経路計算手段とセッション管理
手段を備え、前記プロトコル手段が、経路計算要求装置もしくは他の経路計算装置とセッ
ションを確立することでプロトコルメッセージの送受信を実施するステップと、前記経路
計算手段が、経路計算を実施するステップと、前記セッション管理手段が、前記プロトコ
ル手段のセッションの検索・開始・終了を指示するステップと、を含む。また、複数のドメインにまたがる経路計算時に経由する経路計算装置の順序の管理を、セッション管理手段が行う。

これにより、経路計算手段とプロトコル手段の独立性が高くなり、プログラム開発の効
率化が可能となる。さらに、リクエストＩＤの関連付けをセッション管理手段により一括管理可能となる。

請求項２によれば、複数のドメインにまたがる経路計算時に経由する経路計算装置の順序の管理を、プロトコル手段が行う。

これにより、リクエストＩＤの関連付けを分散的に行いスケーラビリティが向上する。

請求項３によれば、セッション管理手段が、プロトコル手段のセッション数を管理し、セッション開始・終了を指示する。

これにより、セッション数を考慮したセッション管理が可能となり、セッション数が増大することによる経路計算装置の過負荷を防ぐことが可能となる。

請求項４によれば、セッション数が閾値以下の場合、処理中の経路計算要求が０になってもただちにセッション終了とせず、一定時間待ち、その間に新たな要求が発生しない場合に終了とする。

これにより、セッション数を考慮したセッション管理が可能となり、セッション数が増大することによる経路計算装置の過負荷を防ぐことが可能となる。

請求項５によれば、セッション管理手段が、プロトコル手段のセッションの利用履歴を管理し、セッション開始・終了を指示する。

これにより、各ノードおよび経路計算装置とのプロトコル通信の頻度の管理が可能となり、セッション数を考慮しながら、効率的なセッション管理が可能となる。

請求項６によれば、セッションの利用履歴を管理し、利用頻度が高いセッションについては、処理中の経路計算要求が０になってもただちにセッション終了とせず、利用頻度に応じた時間だけ待ち、その間に新たな要求が発生しない場合に終了とする。

これにより、各ノードおよび経路計算装置とのプロトコル通信の頻度の管理が可能となり、セッション数を考慮しながら、効率的なセッション管理が可能となる。

請求項３、４によれば、経路計算装置が、経路計算要求装置もしくは他の経路計算装置とセッションを確立することでプロトコルメッセージの送受信を実施するプロトコル手段と、経路計算を実施する経路計算手段と、プロトコル手段のもつＰＣＥＰセッションの検索・開始・終了を指示するセッション管理手段とを備える。また、複数のドメインにまたがる経路計算時に経由する経路計算装置の順序の管理を行う、セッション管理手段もしくはプロトコル管理手段を備える。

これにより、経路計算手段とプロトコル手段の独立性が高くなり、プログラム開発の効率化が可能となる。さらに、リクエストＩＤの関連付けを一括管理可能となる。

本発明では、経路計算手段とプロトコル手段とは独立した、セッション管理手段を導入することにより、経路計算手段とプロトコル手段の独立性を高くし、プログラム開発の効率化を実現することを特徴とする。

また、複数のドメインにまたがる経路計算時に経由する経路計算装置の順序の管理を、セッション管理手段が行うことで、リクエストＩＤの関連付けを分散的に行うことが可能となり、スケーラビリティが向上する。

また、セッション管理手段が、プロトコル手段のセッション数を管理し、セッション開始・終了を指示することで、セッション数を考慮したセッション管理が可能となり、経路計算装置の過負荷を防ぐことが可能となる。

さらに、セッション管理手段が、プロトコル手段のセッションの利用履歴を管理し、セッション開始・終了を指示することで、各ノードおよび経路計算装置とのプロトコル通信の頻度の管理が可能となり、セッション数を考慮しながら、効率的なセッション管理が可能となる。

次に、本発明の実施の形態について図面を参照して説明する。
図１は、本発明の実施の形態が前提とする網構成を示している。ドメインは１つ以上のノードおよびリンクから構成される。１つ以上のドメインに対応して１つ以上の経路計算装置が存在する。図１の例では、経路計算装置１がドメイン１、経路計算装置２がドメイン２、経路計算装置３がドメイン３のネットワーク情報を把握しており、ノード１と経路計算装置１、経路計算装置１と経路計算装置２、経路計算装置２と経路計算装置３、がＰＣＥＰによりプロトコル通信を行い、ノード１とノード１１の間の経路が計算される。

一般的には、経路計算装置は、ＰＣＥＰピア（ノードまたは他の経路計算装置）とＰＣＥＰセッションを確立し、プロトコル通信を行う。ある経路計算装置は、同じＰＣＥＰピアとは１つ以上のＰＣＥＰセッションは確立しない。経路計算装置が有するＰＣＥＰセッション数の合計は０または１以上であり、状況に応じてＰＣＥＰセッションを開始・終了し、ＰＣＥＰセッション数は状況に応じて変化する。

ノードは、例えば、伝送装置（ＳＯＮＥＴ／ＳＤＨクロスコネクト、波長クロスコネクト）ルータ、Ｌ２ＳＷが相当する。
リンクは、装置間に存在し、情報転送の媒体となる。例えば、光ファイバが相当する。

図２は、経路計算装置の各手段の関連を示している。
図２−１は、一般的な構成例である。２０１は経路計算手段、２０２−１はプロトコル手段セッション＃１、２０２−２はプロトコル手段セッション＃２、２０２−３はプロトコル手段セッション＃３である。プロトコル手段２０２と経路計算手段２０１が直接情報交換を行う形態である。このためプロトコル手段２０２と経路計算手段２０１の独立性が悪い。

図２−２は、本発明の実施の形態による構成例である。２１１は経路計算手段、２１２−１はプロトコル手段セッション＃１、２１２−２はプロトコル手段セッション＃２、２１２−３はプロトコル手段セッション＃３、２１３はセッション管理手段である。プロトコル手段２１２、経路計算手段２１１に加え、セッション管理手段２１３が存在する。セッション管理手段２１３により、プロトコル手段２１２のセッション管理を行うため、プロトコル手段２１２と経路計算手段２１１の独立性が高い。

図３は、本発明の実施の形態の経路計算装置の構成を示している。図３において、２１１は経路計算手段、２１２はプロトコル手段、２１３はセッション管理手段である（以上は図２−２と同じである）。３１０はプロトコル管理ＤＢ、３２０はセッション管理ＤＢ、３３０はリクエストＩＤ関連付けＤＢ、３４０はドメイン内ネットワークＤＢ、３５０はドメイン外ネットワークＤＢである。

プロトコル手段２１２は、ＰＣＥＰセッションを維持し、ＰＣＥＰピアとプロトコル通信を行う。また、プロトコル管理ＤＢ３１０を管理する。

プロトコル手段２１２は、例えばプロセスとして実現され、１つのプロセスが、１つのＰＣＥＰセッションを構成する。

経路計算手段２１１は、ドメイン内ネットワークＤＢ３４０およびドメイン外ネットワークＤＢ３５０を利用して経路計算を行う。具体的には以下の３つのパターンに対応する。

パターン１（ドメイン内経路計算）
経路計算要求の始点ノード、終点ノードともにドメイン内ネットワークＤＢ３４０に含まれている場合→経路計算を実施し、経路計算結果を返す（ドメイン内経路計算）。

パターン２（ドメイン外経路計算−次ＰＣＥに送信）
経路計算要求の終点ノードがドメイン外ネットワークＤＢ３５０に含まれている場合→次ＰＣＥＰピアアドレスを返す。「従来の技術」の（２）（４）が相当する。

パターン３（ドメイン外経路計算−経路計算）
経路計算要求の始点ノードがドメイン外ネットワークＤＢ３５０に含まれ、終点ノードがドメイン内ネットワークＤＢ３４０に含まれている場合→ドメイン内ネットワーク情報を用い、経路計算要求メッセージを送信してきた経路計算装置が属するドメインと接続されるリンクから、終点ノードヘの経路を計算し、経路計算結果を返す。「従来の技術」の（６）が相当する。

もしくは、パターン２の応答を受け取った場合→ドメイン内ネットワークＤＢ３４０とパターン２の応答として受信した経路計算結果をつなぎあわせたものを用い、経路計算を実施し、経路計算結果を返す。「従来の技術」の（８）（１０）が相当する。

セッション管理手段２１３は、セッション管理ＤＢ３２０とリクエストＩＤ関連付けＤＢ３３０を管理し、プロトコル手段２１２のセッション管理を行うとともに、経路計算要求メッセージにおけるリクエストＩＤの関連付けを行う。

プロトコル管理ＤＢ３１０は、セッションごとに存在する。セッション番号３１１とはＰＣＥＰセッションを該経路計算装置で一意に識別する情報、ＰＣＥＰピアアドレス３１２とはＰＣＥＰセッションを形成する対向のＰＣＥＰピア（経路計算要求装置もしくは経路計算装置）のアドレス（例:ＩＰアドレス）である。リクエストリスト３１３は、ＰＣＥＰピアとやりとりしている０もしくは１以上のメッセージのリクエスト内容を保持し、ＰＣＣアドレス３１４とは経路計算要求メッセージを送信した装置のアドレス（該経路計算装置のアドレスもしくはＰＣＥＰピアアドレス）、リクエストＩＤ３１５とは該経路計算装置のアドレスおよびＰＣＥＰピアアドレスとセットにすることによりメッセージを一意に識別する情報である。３１６はリクエストリスト３１３に含まれるその他の情報である。

セッション管理ＤＢ３２０は、プロトコル手段２１２が維持しているＰＣＥＰセッションの情報を保持する。セッション番号３２１とはＰＣＥＰセッションを該経路計算装置で一意に識別する情報、ＰＣＥＰピアアドレス３２２とはＰＣＥＰセッションを形成する対向のＰＣＥＰピアのアドレスである。

リクエストＩＤ関連付けＤＢ３３０は、ドメイン外経路計算を実施するときに、該経路計算装置が受信する経路計算要求メッセージと、該経路計算装置が送信する経路計算要求メッセージの関連付けを保持する。第一セッション番号３３１とは該経路計算装置が受信する経路計算要求メッセージが利用するセッション番号、第一ＰＣＥＰピアアドレス３３２とは該経路計算装置が受信する経路計算要求メッセージを送信するＰＣＥＰピアアドレス、第一リクエストＩＤ３３３とは該経路計算装置が受信する経路計算要求メッセージのリクエストＩＤである。第二セッション番号３３４とは該経路計算装置が送信する経路計算要求メッセージが利用するセッション番号、第二ＰＣＥＰピアアドレス３３５とは該経路計算装置が送信する経路計算要求メッセージを受信するＰＣＥＰピアアドレス、第二リクエストＩＤ３３６とは該経路計算装置が送信する経路計算要求メッセージのリクエストＩＤである。

ドメイン内ネットワークＤＢ３４０は、経路計算装置が管理するドメインのネットワーク情報を格納する。Ａ端装置ＩＤ３４１とは、リンクの一方の端となっている装置の装置ＩＤである。Ｚ端装置ＩＤ３４３とは、リンクのもう一方の端となっている装置の装置ＩＤである。Ａ端ＩＦ ＩＤ３４２とは、Ａ端装置で、該リンクを一意に示す識別子である。Ｚ端ＩＦ ＩＤ３４４とは、Ｚ端装置で、該リンクを一意に示す識別子である。帯域３４５とは、該リンクの最大利用可能帯域を示す情報である。残余帯域３４６とは、該リンクの残余帯域を示す情報である。ここで装置ＩＤ、ＩＦ ＩＤとして例えばＩＰアドレスが相当する。３４７はその他の情報である。

ドメイン外ネットワークＤＢ３５０は、経路計算装置が管理するドメイン外のネットワーク情報を格納する。アドレス３５１とはノードまたはリンクを一意に識別するアドレス、次ＰＣＥＰピアアドレス３５２とは、アドレスに到達するために経由すべきＰＣＥを一意に識別するＰＣＥＰピアアドレスである。

図４、５は、請求項１および請求項２に対応する実施の形態の経路計算装置の処理手順を示している。

図１のネットワーク構成を例として、経路計算装置１における処理手順は以下のようになる。なお、以下の前提条件である。

ノード１のアドレス＝１．１．１．１、ノード１１のアドレス＝１１．１１．１１．１１（図１参照）
経路計算装置１のアドレス＝１．１．１．１０１、経路計算装置２のアドレス＝２．２．２．１０１、経路計算装置３のアドレス＝３．３．３．１０１（図１参照）
ドメイン内ネットワークＤＢ３４０、ドメイン外ネットワークＤＢ３５０は事前に設定済み
初期状態として、経路計算装置１は、ノード１とＰＣＥＰセッションを確立済み（セッション番号＝１００１、ＰＣＥＰピアアドレス＝１．１．１．１として、プロトコル管理ＤＢ、セッション管理ＤＢが設定済み）
ノード１より経路計算要求メッセージを受け取った場合の経路計算装置１における処理手順は以下の通りである（「従来の技術」の（２）相当）。

（１）ステップ４０１ プロトコル手段２１２がメッセージ受信する（ノード１より始点＝１．１．１．１、終点＝１１．１１．１１．１１、リクエストＩＤ＝１００の経路計算要求メッセージを受信）。
（２）ステップ４０２ プロトコル手段２１２が、プロトコル管理ＤＢ３１０を更新する（セッション番号＝１００１、ＰＣＥＰピアアドレス＝１．１．１．１に対して、リクエストリスト:ＰＣＣアドレス＝１．１．１．１、リクエストリスト:リクエストＩＤ＝１００を追加）。
（３）ステップ４０３ プロトコル手段２１２がセッション管理手段２１３に情報を送信する（始点＝１．１．１．１、終点＝１１．１１．１１．１１、リクエストＩＤ＝１００の経路計算要求）。
（４）ステップ４０４ セッション終了判断処理（図５）を行う。
（ア）ステップ５０１ プロトコル手段２１２の特定セッションの処理中リクエストＩＤ数が０かを判断する（ＮＯであるのでセッション終了処理（図５）を終了し、図４の処理に戻る）。
（５）ステップ４０５ セッション管理手段２１３が経路計算手段２１１に情報を送信する（始点＝１．１．１．１、終点＝１１．１１．１１．１１の経路計算要求）。
（６）ステップ４０６〜４０７ 経路計算手段２１１が経路計算を行い、セッション管理手段２１３に情報を送信する（ドメイン外経路計算−次ＰＣＥに送信、として次ＰＣＥＰピアアドレスとして２．２．２．１０１を返す）。
（７）ステップ４０８ セッション管理手段２１３が計算結果を判断する（ドメイン外経路計算−次ＰＣＥに送信）。
（８）ステップ４０９ セッション管理手段２１３が、該当セッションが存在するか判断する（セッション管理ＤＢ３２０を検索し、ＰＣＥＰピアアドレス３２２が２．２．２．１０１となっているセッションがあるかどうか検索するが、存在しない）。
（９）ステップ４１０ セッション管理手段２１３が該当セッションを開始するように指示する（該当セッションのセッション番号＝１００２とする）。
（１０）ステップ４１１ セッション管理手段２１３がプロトコル手段２１２に情報を送信する（始点＝１．１．１．１、終点＝１１．１１．１１．１１、リクエストＩＤ＝２００の経路計算要求で、ＰＣＥＰピアアドレス＝２．２．２．１０１とする）。
（１１）ステップ４１２ セッション管理手段２１３がリクエストＩＤ関連付けＤＢ３３０を更新する（第一セッション番号＝１００１、第一ＰＣＥＰピアアドレス＝１．１．１．１、第一リクエストＩＤ＝１００、第二セッション番号＝１００２、第二ＰＣＥＰピアアドレス＝２．２．２．１０１、第二リクエストＩＤ＝２００）。
（１２）ステップ４１３ プロトコル手段２１２がメッセージを送信する（経路計算装置２に、始点＝１．１．１．１、終点＝１１．１１．１１．１１、リクエストＩＤ＝２００の経路計算要求メッセージを送信）。
（１３）ステップ４１４ プロトコル手段２１２がプロトコル管理ＤＢ３１０を更新する（セッション番号＝１００２、ＰＣＥＰピアアドレス＝２．２．２．１０１、リクエストリスト:ＰＣＣアドレス＝１．１．１．１０１、リクエストリスト:リクエストＩＤ＝２００）。
（１４）ステップ４１５ セッション終了判断処理（図５）を行う。
（ア）ステップ５０１ プロトコル手段２１２の特定セッションの処理中リクエストＩＤ数が０かを判断する（ＮＯであるのでセッション終了判断処理（図５）を終了し、図４の処理に戻り、図４の処理も終了する）。

経路計算装置２より経路計算応答メッセージを受け取った場合の経路計算装置１の処理手順は以下の通りである（「従来の技術」の（１０）相当）。
（１）ステップ４０１ プロトコル手段２１２がメッセージを受信する（ＰＣＥＰピアアドレス＝２．２．２．１０１より、リクエストＩＤ＝２００の経路計算応答メッセージを受信）。
（２）ステップ４０２ プロトコル手段２１２がプロトコル管理ＤＢ３１０を更新する（ＰＣＥＰピアアドレス＝２．２．２．１０１となっているものの中で、ＰＣＣアドレス＝１．１．１．１０１、リクエストＩＤ＝２００となっているエントリを検索し、このリクエストリストを削除）。
（３）ステップ４０３ プロトコル手段２１２がセッション管理手段２１３に情報を送信する（リクエストＩＤ＝２００の経路計算応答）。
（４）ステップ４０４ セッション終了判断処理（図５）を行う。

（ア）ステップ５０１ プロトコル手段２１２の特定セッションの処理中メッセージ数が０かを判断する（セッション番号＝１００２についてＹＥＳ）
（イ）ステップ５０２ プロトコル手段２１２のセッションを終了する（セッション番号＝１００２のセッション終了）。
（ウ）ステップ５０３ プロトコル手段２１２がセッション管理手段２１３に通知する。
（エ）ステップ５０４ セッション管理手段２１３がセッション管理ＤＢ３２０を更新する（セッション番号＝１００２のエントリを削除し、セッション終了判断処理（図５）を終了し、図４の処理に戻る）。

（５）ステップ４０５ セッション管理手段２１３が経路計算手段２１１に情報を送信する（経路計算応答）。
（６）ステップ４０６ 経路計算手段２１１が経路計算を行う（ノード１からノード１１の経路計算を実施）。
（７）ステップ４０７ 経路計算手段２１１がセッション管理手段２１３に情報を送信する。
（８）ステップ４０８ セッション管理手段２１３が計算結果を判断する（ドメイン外経路−経路計算）。
（９）ステップ４１６ セッション管理手段２１３がリクエストＩＤ関連付けＤＢ３３０を検索する（第二プロセス番号＝１００２、第二ＰＣＥＰピアアドレス＝２．２．２．１０１、リクエストＩＤ＝２００となっているエントリを検索することで、第一プロセス番号＝１００１、第一ＰＣＥＰピアアドレス＝１．１．１．１、リクエストＩＤ＝１００を発見）。
（１０）ステップ４１１ セッション管理手段２１３がプロトコル手段２１２に情報を送信する（プロセス番号＝１００１に対して、ＰＣＣアドレス＝１．１．１．１、リクエストＩＤ＝１００および、（７）ステップ４０７で受け取った経路計算結果）。
（１１）ステップ４１２ セッション管理手段２１３がリクエストＩＤ関連付けＤＢ３３０を更新（（９）ステップ４１６で検索したエントリを削除）
（１２）ステップ４１３ プロトコル手段２１２がメッセージを送信する（ノード１に、リクエストＩＤ＝１００の経路計算応答）。
（１３）ステップ４１４ プロトコル手段２１２がプロトコル管理ＤＢ３１０を更新する（セッション番号＝１００１、ＰＣＥＰピアアドレス＝１．１．１．１の、ＰＣＣアドレス＝１．１．１．１、リクエストＩＤ＝１００のエントリを削除）。
（１４）ステップ４１５ セッション終了判断処理（図５）を行う。

（ア）ステップ５０１ プロトコル手段２１２の特定セッションの処理中メッセージ数が０かを判断する（セッション番号＝１００１についてＹＥＳ）。
（イ）ステップ５０２ プロトコル手段２１２のセッションを終了する（セッション番号＝１００１のセッション終了）。
（ウ）ステップ５０３ プロトコル手段２１２がセッション管理手段２１３に通知する。
（エ）ステップ５０４ セッション管理手段２１３がセッション管理ＤＢ３２０を更新する（セッション番号＝１００１のエントリを削除し、セッション終了判断処理（図５）を終了し、図４の処理に戻り、図４の処理も終了する）。
（以上、請求項１、請求項２に対応する実施の形態）

請求項２では、複数のドメインにまたがる経路計算時に経由する経路計算装置の順序の管理を、セッション管理手段２１３が実施していた。すなわち、リクエストＩＤ関連付けＤＢ３３０はセッション管理手段２１３が管理していた。

しかしながら、リクエストＩＤ関連付けを、プロトコル手段２１２が実施しても構わない。これにより、リクエストＩＤ関連付けを分散的に処理でき、スケーラビリティが向上する。

この場合の経路計算装置の構成を図６に示す。
図３と比較して、以下が変更点となる。

リクエストＩＤ関連付けＤＢ３３０がなく、プロトコル管理ＤＢ３１０のリクエストリスト３１３に第一ＰＣＥＰピアアドレス３１７と第一リクエストＩＤ３１８が追加される。
セッション管理手段２１３は、セッション管理ＤＢ３２０を管理し、プロトコル手段２１２のセッション管理を行う。
プロトコル手段２１２は、ＰＣＥＰセッションを維持し、ＰＣＥＰピアとプロトコル通信を行う。また、プロトコル管理ＤＢ３１０を管理する。更に、リクエストＩＤ関連付けを行う。
その他の手段、ＤＢは図３と同じである。

処理手順として、図４、５と比較して、以下のように変更される。
ノード１より経路計算要求メッセージを受け取った場合の経路計算装置１の処理手順は以下のように変更される。
（１０）ステップ４１１ セッション管理手段２１３がプロトコル手段２１２に情報を送信する（始点＝１．１．１．１、終点＝１１．１１．１１．１１、第一ＰＣＥＰピアアドレス＝１．１．１．１、第一リクエストＩＤ＝１００の経路計算要求で、ＰＣＥＰピアアドレス＝２．２．２．１０１とする）。
（１１）ステップ４１２ 削除（スキップ）
（１２）ステップ４１３ プロトコル手段２１２がメッセージを送信する（リクエストＩＤ＝２００として、経路計算装置２に、始点＝１．１．１．１、終点＝１１．１１．１１．１１、リクエストＩＤ＝２００の経路計算要求メッセージを送信）。
（１３）ステップ４１４ プロトコル手段２１２がプロトコル管理ＤＢ３１０を更新する（セッション番号＝１００２、ＰＣＥＰピアアドレス＝２．２．２．１０１、リクエストリスト:ＰＣＣアドレス＝１．１．１．１０１、リクエストリスト:リクエストＩＤ＝２００、第一ＰＣＥＰピアアドレス＝１．１．１．１、第一リクエストＩＤ＝１００）。

経路計算装置２より経路計算応答メッセージを受け取った場合の経路計算装置１の処理手順は以下のように変更される。
（３）ステップ４０３ プロトコル手段２１２がセッション管理手段２１３に情報を送信する（プロトコルＤＢの検索により、第一ＰＣＥＰピアアドレス＝１．１．１．１、第一リクエストＩＤ＝１００の経路計算応答）。
（５）ステップ４０５ セッション管理手段２１３が経路計算手段２１１に情報を送信する（第一ＰＣＥＰピアアドレス＝１．１．１．１、第一リクエストＩＤ＝２００の経路計算応答）。
（９）ステップ４１６ 削除（スキップ）
その他のステップは同じである。
（以上、請求項３に対応する実施の形態）

また、図５では、セッション終了判断処理として、処理中のリクエストＩＤ数が０となると、ただちにセッション終了としているが、セッション管理手段２１３が、プロトコル手段２１２のセッション数を管理し、セッション開始・終了を指示しても構わない。

例えば、セッション数がある閾値以下である場合は、処理中のリクエストＩＤ数が０になってもただちにセッション終了とせず、一定時間待ち、その間に新たなリクエストが発生しない場合に終了とする方法が考えられる。

セッション開始についても同様に、セッション数がある閾値以上である場合、ただちにセッションを開始せず、一定時間待ち、その後再度セッション開始をリトライする方法が考えられる。

これにより、経路計算装置でのセッション開始・終了やセッション維持に伴う負荷を避けることが可能となる。
（以上、請求項４、５に対応する実施の形態）

更に、セッション管理手段２１３が、プロトコル手段２１２のセッションの利用履歴を管理し、セッション開始・終了を指示してもかまわない。

例えば、利用頻度の高いセッションについては、処理中のリクエストＩＤ数が０になってもただちにセッション終了とせず、利用頻度に応じた時間だけ待ち、その間に新たなリクエストが発生しない場合に終了とする方法が考えられる。

これにより、各ノードおよび経路計算装置とのプロトコル通信の頻度の管理が可能となり、セッション数を考慮しながら、効率的なセッション管理が可能となる。
（以上、請求項６、７に対応する実施の形態）

以上説明した各手段はコンピュータとプログラムで構成でき、そのプログラムの一部または全部をハードウェアで構成してもよい。また、各ＤＢはコンピュータの記憶装置に記憶させることができる。

以上、本発明者によってなされた発明を、前記実施の形態に基づき具体的に説明したが、本発明は、前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。

本発明の実施の形態が前提とする網構成を示している。 一般的な経路計算装置の各手段の関連を示している。 本発明の実施の形態の経路計算装置の各手段の関連を示している。 本発明の実施の形態の経路計算装置の構成を示している。 請求項１および請求項２に対応する実施の形態の経路計算装置の処理手順（その１）を示している。 請求項１および請求項２に対応する実施の形態の経路計算装置の処理手順（その２）を示している。 請求項３に対応する実施の形態の経路計算装置の構成を示している。

符号の説明

２０１…経路計算手段、２０２−１…プロトコル手段セッション＃１、２０２−２…プロトコル手段セッション＃２、２０２−３…プロトコル手段セッション＃３、２１１…経路計算手段、２１２…プロトコル手段、２１２−１…プロトコル手段セッション＃１、２１２−２…プロトコル手段セッション＃２、２１２−３…プロトコル手段セッション＃３、２１３…セッション管理手段、３１０…プロトコル管理ＤＢ、３２０…セッション管理ＤＢ、３３０…リクエストＩＤ関連付けＤＢ、３４０…ドメイン内ネットワークＤＢ、３５０…ドメイン外ネットワークＤＢ

Claims (8)

1. 複数のノードと複数のリンクから構成されるドメインが複数存在し、１つ以上のドメインに対応して１つ以上の経路計算装置が存在し、各経路計算装置は対応する１つ以上のドメインのネットワーク情報のみを把握し、経路計算要求装置と経路計算装置、および経路計算装置と経路計算装置が、プロトコル通信を行うことで、同じもしくは異なるドメインに存在する始点ノードと終点ノードの経路を計算する経路計算装置におけるセッショ管
   理方法であって、
   前記経路計算装置は、プロトコル手段と経路計算手段とセッション管理手段を備え、
   前記セッション管理手段が、複数のドメインにまたがる経路計算時に経由する経路計算装置の順序について、前記ノードから受信した経路計算要求のメッセージおよび前記経路計算装置間で送受信するメッセージを関連付けて管理を行うことを特徴とする経路計算装置におけるセッション管理方法であって、
   前記プロトコル手段が、経路計算要求装置もしくは他の経路計算装置とセッションを確立することでプロトコルメッセージの送受信を実施するステップと、
   前記経路計算手段が、経路計算を実施するステップと、
   前記セッション管理手段が、前記プロトコル手段のセッションの検索・開始・終了を指示するステップと、
   を含むことを特徴とする経路計算装置におけるセッション管理方法。
2. 複数のノードと複数のリンクから構成されるドメインが複数存在し、１つ以上のドメインに対応して１つ以上の経路計算装置が存在し、各経路計算装置は対応する１つ以上のドメインのネットワーク情報のみを把握し、経路計算要求装置と経路計算装置、および経路計算装置と経路計算装置が、プロトコル通信を行うことで、同じもしくは異なるドメインに存在する始点ノードと終点ノードの経路を計算する経路計算装置におけるセッショ管
   理方法であって、
   前記経路計算装置は、プロトコル手段と経路計算手段とセッション管理手段を備え、
   前記プロトコル手段が、複数のドメインにまたがる経路計算時に経由する経路計算装置の順序について、前記ノードから受信した経路計算要求のメッセージおよび前記経路計算装置間で送受信するメッセージを関連付けて管理を行うことを特徴とする経路計算装置におけるセッション管理方法であって、
   前記プロトコル手段が、経路計算要求装置もしくは他の経路計算装置とセッションを確立することでプロトコルメッセージの送受信を実施するステップと、
   前記経路計算手段が、経路計算を実施するステップと、
   前記セッション管理手段が、前記プロトコル手段のセッションの検索・開始・終了を指示するステップと、
   を含むことを特徴とする経路計算装置におけるセッション管理方法。
3. 前記セッション管理手段が、前記プロトコル手段のセッション数を管理し、セッション
   開始・終了を指示することを特徴とする請求項１または2に記載の経路計算装置におけるセッショ
   ン管理方法。
4. セッション数が閾値以下の場合、処理中の経路計算要求が０になってもただちにセッシ
   ョン終了とせず、一定時間待ち、その間に新たな要求が発生しない場合に終了とすること
   を特徴とする請求項３に記載の経路計算装置におけるセッション管理方法。
5. 前記セッション管理手段が、前記プロトコル手段のセッションの利用履歴を管理し、セ
   ッション開始・終了を指示することを特徴とする請求項１または2に記載の経路計算装置における
   セッション管理方法。
6. セッションの利用履歴を管理し、利用頻度が高いセッションについては、処理中の経路計算要求が０になってもただちにセッション終了とせず、利用頻度に応じた時間だけ待ち、その間に新たな要求が発生しない場合に終了とすることを特徴とする請求項５に記載の経路計算装置におけるセッション管理方法。
7. 複数のノードと複数のリンクから構成されるドメインが複数存在し、１つ以上のドメインに対応して１つ以上の経路計算装置が存在し、各経路計算装置は対応する１つ以上のドメインのネットワーク情報のみを把握し、経路計算要求装置と経路計算装置、および経路計算装置と経路計算装置が、プロトコル通信を行うことで、同じもしくは異なるドメインに存在する始点ノードと終点ノードの経路を計算する経路計算装置であって、
   経路計算要求装置もしくは他の経路計算装置とセッションを確立することでプロトコルメッセージの送受信を実施するプロトコル手段と、
   経路計算を実施する経路計算手段と、
   前記プロトコル手段のセッションの検索・開始・終了を指示するセッション管理手段と、を備えることを特徴とし、
   複数のドメインにまたがる経路計算時に経由する経路計算装置の順序について、前記セッション管理手段が前記ノードから受信した経路計算要求のメッセージおよび前記経路計算装置間で送受信するメッセージを関連付けて管理を行うことを特徴とする経路計算装置。
8. 複数のノードと複数のリンクから構成されるドメインが複数存在し、１つ以上のドメインに対応して１つ以上の経路計算装置が存在し、各経路計算装置は対応する１つ以上のドメインのネットワーク情報のみを把握し、経路計算要求装置と経路計算装置、および経路計算装置と経路計算装置が、プロトコル通信を行うことで、同じもしくは異なるドメインに存在する始点ノードと終点ノードの経路を計算する経路計算装置であって、
   経路計算要求装置もしくは他の経路計算装置とセッションを確立することでプロトコルメッセージの送受信を実施するプロトコル手段と、
   経路計算を実施する経路計算手段と、
   前記プロトコル手段のセッションの検索・開始・終了を指示するセッション管理手段と、を備えることを特徴とし、
   複数のドメインにまたがる経路計算時に経由する経路計算装置の順序について、前記プロトコル手段が前記ノードから受信した経路計算要求のメッセージおよび前記経路計算装置間で送受信するメッセージを関連付けて管理を行うことを特徴とする経路計算装置。

Images