JP2016526850A - Ｒｓｖｐ−ｔｅシグナリングを処理するための方法及びシステム - Google Patents

Abstract

ＲＳＶＰ−ＴＥシグナリングを処理するための方法及びシステムであって、ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張し、シグナリングにおけるリンクリソースをエリア番号、ルータ番号及びポートからなる３要素グループで表示することと、ネットワークリソース設定の場合、それぞれのエリア番号が異なり、エリア内でルータ番号が唯一であるように設定することと、クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソースを前記３要素グループで表示することと、を含む。【選択図】図２

Description

本発明はネットワーク通信分野に関し、特にトラフィックエンジニアリングのリソース予約プロトコル（Resource Reservation Protocol - Traffic Engineer、ＲＳＶＰ−ＴＥと略称する）シグナリングを処理するための方法及びシステムに関する。

ＭＰＬＳ−ＴＥ（Multi-Protocol Label Switching - Traffic Engineer、マルチプロトコルラベルスイッチングトラフィックエンジニアリング）は、マルチプロトコルラベルスイッチ技術及びトラフィックエンジニアリング技術の長所を結合し、パケットスイッチングとレイヤ２スイッチングにおいてネットワーク帯域幅リソースの動的調整及び最適化配置を実現し、ネットワーク輻輳の問題を解決する。ＧＭＰＬＳ（Generalized Multi-Protocol Label Switching、汎用マルチプロトコルラベルスイッチング）はＭＰＬＳ−ＴＥを更に拡張したものであり、ＩＰ（Internet Protocol、ネットワークプロトコル）パケットスイッチングをサポートするとともに、タイムスロットスイッチング、波長スイッチング及び空間スイッチング（例えば光ファイバースイッチング及びポートスイッチング）をサポートすることができる。ＭＰＬＳ−ＴＥ及びＧＭＰＬＳはいずれもルータプロトコルにより、リンクリソースをフラッディングし、サービス作成を行う前に、明示ルータを計算し、シグナリングプロトコルによりサービスを作成する。ＭＰＬＳ−ＴＥ及びＧＭＰＬＳはいずれもアンナンバード方式でリンクリソースを表示することを提案しており、アンナンバードリンク（unnumbered links）はリンクポートがＩＰアドレスを有していないリンクを指し、該ネットワークエレメントではアンナンバードインターフェイス（Unnumbered Interface ID）で示す。

ＲＳＶＰ−ＴＥ（Resource Reservation Protocol - Traffic Engineer、トラフィックエンジニアリングのリソース予約プロトコル）は、従来もっとも幅広く使用されているシグナリングプロトコルであり、ＲＦＣ３４７７にはＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリンクリソースを使用する方法を提案した。図１に示すように、アンナンバードリンクは明示ルータオブジェクト（Explicit Route Object、ＥＲＯと略称する）での表示方法は、１つのアンナンバードインターフェイスサブオブジェクトを拡張し、他のオブジェクトでの表示方法はそれと類似し、ルータ番号とポートの２要素グループでアンナンバードリンクリソースを表示する。シグナリングにおいてアンナンバードリンクリソースがエリア番号情報を有していないため、ルータ番号がすべてのエリアで唯一であることを要求しなければならない。対応するルータプロトコルＯＳＰＦ−ＴＥ（Open Shortest Path First - Traffic Engineer、開放型最短経路優先のトラフィックエンジニアリング）では、フラッディングリソースに対していずれもルータエリア情報で表示し、したがって、ルータプロトコルの面から、ルータ番号はエリア内に限定され、エリア内で唯一であるだけでよく、異なるエリアに対して、そのルータ番号は同じ値を取ることができる。

ＲＦＣ３２０９はＥＲＯで１つの自律エリア（Autonomous system number、ＡＳと略称する）サブオブジェクトを定義し、次のルータホップがあるエリアである状況を示すことに用い、それとアンナンバードインターフェイスサブオブジェクトとが分離したサブオブジェクトであるため、アンナンバードインターフェイスサブオブジェクトの内容への制約能力を有しておらず、アンナンバードインターフェイスサブオブジェクトと連合して、ルータＩＤをエリア内のみで唯一にすることができない。また、該オブジェクトは記録ルータオブジェクト（Record Route Object、ＲＲＯと略称する）において定義されておらず、且つその定義されたＡＳ番号は２つのバイトのみを有し、ＯＳＰＦ−ＴＥにおいて定義されたエリア番号は、一般的に４つのバイトであり、従ってＡＳサブオブジェクトは更にフィールドの長さを拡張する必要がある。

ＲＳＶＰ−ＴＥシグナリングプロトコルでは、アンナンバードインターフェイスにおいてエリア番号を有しておらず、それによる別の問題は、それぞれのエリアのトップノードがエリア内のサービス作成を行う時、ＲＳＶＰ−ＴＥプロトコル処理モジュールが該エリアの境界ノードを確定できず、すべての後続のルータ情報をルータ処理モジュールに知らせて、ルータ処理モジュールで該エリアの境界を確定しなければならないことであり、このようにメッセージ処理のオーバーヘッドを追加し、サービス作成の速度を下げる。

本発明はルータ番号リソースの消費を減少させるように、ＲＳＶＰ−ＴＥシグナリングを処理するための方法及びシステムを提供する。

本発明はトラフィックエンジニアリングのリソース予約プロトコル（ＲＳＶＰ−ＴＥ）シグナリングを処理するための方法を提供しており、当該方法は、
ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張し、シグナリングにおけるリンクリソースをエリア番号、ルータ番号及びポートからなる３要素グループで表示することと、
ネットワークリソース設定の場合、それぞれのエリア番号が異なり、エリア内でルータ番号が唯一であるように設定することと、
クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソースを前記３要素グループで表示することと、を含む。

選択的に、前記方法は更に、前記拡張された、アンナンバードリソースを使用するオブジェクトは、
明示ルータオブジェクトのサブオブジェクト、
リソース予約ホップオブジェクト、
エラー情報オブジェクト、及び
ラベルスイッチパストンネルインターフェース番号オブジェクトを含む、という特徴を有する。

選択的に、前記方法は更に、前記ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張することは、
ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトに対してエリア番号フィールドを拡張し、ルータ番号をエリア内で唯一であるように拡張することを含む、という特徴を有する。

選択的に、前記方法は更に、前記ネットワークリソース設定は、
開放型最短経路優先のトラフィックエンジニアリングプロトコルにおける不透明リンク状態通知でエリア内リソース及びエリア間リソースを表示することを更に含む、という特徴を有する。

選択的に、前記方法は更に、前記クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソースを前記３要素グループで表示することは、
クロスエリアサービスの作成及び状態更新の場合、シグナリングメッセージにおいてリソースを前記３要素グループで表示すること、
クロスエリアサービスネットワークエレメントの間に情報を通知する場合、シグナリングメッセージにおいて故障位置を前記３要素グループで表示すること、及び
クロスエリアサービスはシグナリング方式でアンナンバードのフォワード隣接リンクを作成する場合、前記３要素グループで表示することの１種又は複数種を含む、という特徴を有する。

本発明はトラフィックエンジニアリングのリソース予約プロトコル（ＲＳＶＰ−ＴＥ）シグナリングを処理するためのシステムを更に提供しており、当該システムは、
ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張し、シグナリングにおけるリンクリソースをエリア番号、ルータ番号及びポートからなる３要素グループで表示するように設定される拡張モジュール、
ネットワークリソース設定の場合、それぞれのエリア番号が異なり、エリア内でルータ番号が唯一であるように設定するように設定される設定モジュール、
クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソース表示が前記３要素グループで表示するように設定される処理モジュール、を備える。

選択的に、前記システムは更に、前記拡張モジュールが拡張した、アンナンバードリソースを使用するオブジェクトは、
明示ルータオブジェクトのサブオブジェクト、
リソース予約ホップオブジェクト、
エラー情報オブジェクト、及び
ラベルスイッチパストンネルインターフェース番号オブジェクトを含む、という特徴を有する。

選択的に、前記システムは更に、
前記拡張モジュールは、ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトに対してエリア番号フィールドを拡張し、ルータ番号をエリア内で唯一であるように拡張するという方式により、ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張する、という特徴を有する。

選択的に、前記システムは更に、
前記設定モジュールは更に、開放型最短経路優先のトラフィックエンジニアリングプロトコルにおける不透明リンク状態通知でエリア内リソース及びエリア間リソースを表示するという方式により、ネットワークリソースの設定を行う、という特徴を有する。

選択的に、前記システムは更に、
前記処理モジュールは、クロスエリアサービスの作成及び状態更新の場合、シグナリングメッセージにおいてリソースを前記３要素グループで表示すること、クロスエリアサービスネットワークエレメントの間に情報を通知する場合、シグナリングメッセージにおいて故障位置を前記３要素グループで表示すること、及びクロスエリアサービスはシグナリング方式でアンナンバードのフォワード隣接リンクを作成する場合、前記３要素グループで表示することという方式の１種又は複数種により、クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソースを前記３要素グループで表示する、という特徴を有する。

本発明の実施例に係るＲＳＶＰ−ＴＥシグナリングを処理するための方法及びシステムは、ＲＳＶＰ−ＴＥアンナンバードインターフェイスにおいてエリア番号を含み、エリア番号及びルータ番号を連携して作用させ、一方では、ルータ番号がエリア内で唯一であるようにシグナリングが要求するという制限を除去し、異なるエリアのルータ番号が繰り返して使用することができることを保証し、ルータ番号のエリア内での値の範囲を拡げ、ルータ番号リソースの消費を遅くし、他方では、シグナリングのルータ情報においてエリアの境界ノードを直接に確定し、サービスシグナリング処理速度を速くすることができる。

図１は、ＲＦＣ３４７７で定義されたアンナンバードリンクのＥＲＯでの模式図である。 図２は、本発明の実施例に係るＲＳＶＰ−ＴＥシグナリングを処理するための方法のフローチャートである。 図３は、本発明の実施例に係るアンナンバードインターフェイスのＥＲＯサブオブジェクトでの拡大図である。 図４は、本発明の実施例に係るアンナンバードインターフェイスのＲＲＯサブオブジェクトでの拡大図である。 図５は、本発明の実施例に係るＲＦＣ３４７７で定義されたＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤオブジェクトでのアンナンバードインターフェイスの拡大図である。 図６は、本発明の実施例に係るＲＦＣ６１０７で定義されたＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤオブジェクトでのアンナンバードインターフェイスの拡大図である。 図７は、本発明の実施例に係る２つのエリア、８つのネットワークエレメントのトポロジー模式図である。 図８は、本発明の実施例に係るＲＳＶＰ−ＴＥシグナリングを処理するためのシステムの模式図である。

以下、図面を参照しながら本発明の実施例を詳細に説明する。なお、矛盾が生じない限り、本願における実施例及び実施例における特徴は互いに組み合せることができる。

図２は、本発明の実施例に係るＲＳＶＰ−ＴＥシグナリングを処理するための方法のフローチャートであり、図２に示すように、本実施例の方法は下記のステップ１１〜ステップ１３を含む。

ステップ１１：ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張し、シグナリングにおけるリンクリソースをエリア番号、ルータ番号及びポートからなる３要素グループで表示する。
本実施例では、シグナリングにおけるリンクリソースをルータ番号、ポートの２要素グループで表示する方法を、エリア番号、ルータ番号、ポートの３要素グループで表示する方法に変更する。
拡張部分はＥＲＯ、ＲＲＯ、ＸＲＯ（Exclude Route Object、、除外ルータオブジェクト）のうちのアンナンバードインターフェイスサブオブジェクト、ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤ（ラベルスイッチパストンネルインターフェース番号）オブジェクト、ＲＳＶＰ＿ＨＯＰ（リソース予約ホップ）オブジェクト及びＥＲＲＯＲ＿ＳＰＥＣ（エラー情報）オブジェクトを含んでよく、ＲＳＶＰ＿ＨＯＰオブジェクト及びＥＲＲＯＲ＿ＳＰＥＣオブジェクトの中のＴＬＶ（Type length value、タイプ長さ値）における追加ポート（ＩＦ＿ＩＤ）ＴＬＶとエリアＴＬＶを結合して使用することで、リンクリソースをエリア番号、ルータ番号及びポートの３要素グループ情報で表示することができる。

１１．１、ＥＲＯサブオブジェクトの拡張
図３に示すように、Ｌが０であると、ストリクトなルータホップを表し、１であると、ルーズなルータホップを表し、ここでは拡張していない。
Ｔｙｐｅ（タイプ）フィールドは、ＲＦＣ３４７７においてアンナンバードインターフェイスに対して値４を取り、新しく拡張されたものの値に対して、新たに定義して、ＩＡＮＡ（Internet Assigned Numbers Authority、インターネット数字割り当て機構）に申し込む必要がある。
Ｌｅｎｇｔｈ（長さ）フィールドは、ＲＦＣ３４７７においてアンナンバードインターフェイスに対して値１２を取り、新しく拡張されたものに対して値１６を取る。

Ａｒｅａ ＩＤ（エリア識別子）フィールドは、新しく拡張されたエリア番号フィールドである。
Ｒｏｕｔｅｒ ＩＤフィールドは、ルータＩＤを示し、新しく拡張された表示においてエリア内で唯一であるだけでよい。
Ｉｎｔｅｒｆａｃｅ ＩＤ（商品識別子）フィールドは、ルータ内部ポートアドレスを示し、ルータ内部に割り当てられる。

１１．２、ＲＲＯサブオブジェクトの拡張
図４に示すように、Ｔｙｐｅフィールドは、ＲＦＣ３４７７においてアンナンバードインターフェイスに対して値４を取り、新しく拡張されたものの値に対して、新たに定義して、ＩＡＮＡに申し込む必要がある。
Ｌｅｎｇｔｈフィールドは、ＲＦＣ３４７７においてアンナンバードインターフェイスに対して値１２を取り、新しく拡張されたものに対して値１６を取る。
Ｆｌａｇ（フラグ）フィールドは、ＲＦＣ３４７７においてアンナンバードインターフェイスサブオブジェクトに対して同一の値を取り、ここでは拡張していない。
Ａｒｅａ ＩＤ（エリア番号）フィールドは、新しく拡張されたエリア番号フィールドである。
Ｒｏｕｔｅｒ ＩＤフィールドは、ルータＩＤを示し、新しく拡張された表示においてエリア内で唯一であるだけでよい。
Ｉｎｔｅｒｆａｃｅ ＩＤ（インタフェース番号）フィールドは、ルータ内部ポートアドレスを示し、ルータ内部に割り当てられる。

１１．３、ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤ（ラベルスイッチパストンネルインターフェース番号）オブジェクトの拡張
ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤオブジェクトは、アンナンバードインターフェイスに対して２種の表示方式を有し、
ＲＦＣ３４７７の第３．１章節で定義されたＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤオブジェクトを拡張し、図５に示すようになる。
Ｌｅｎｇｔｈフィールドは、ＲＦＣ３４７７においてアンナンバードインターフェイスに対して値１２を取り、新しく拡張されたものに対して値１６を取る。
Ｃｌａｓｓ−Ｎｕｍ（分類番号）フィールドは、ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤオブジェクト値で、１９３であり、変更できない。
Ｃ−Ｔｙｐｅ（タイプ番号）フィールドは、ＲＦＣ３４７７において値１を取り、新しく拡張されたものの値に対して、新たに定義して、ＩＡＮＡに申し込む必要がある。
Ａｒｅａ ＩＤフィールドは、新しく拡張されたエリア番号フィールドである。

ＬＳＲ’ｓ Ｒｏｕｔｅｒ ＩＤフィールドは、ルータＩＤを示し、新しく拡張された表示においてエリア内で唯一であるだけでよい。

Ｉｎｔｅｒｆａｃｅ ＩＤフィールドは、ルータ内部ポートアドレスを示し、ルータ内部に割り当てられる。

ＲＦＣ６１０７の第３．１．２章節でＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤオブジェクトを修正し、ここでＲＦＣ６１０７におけるアンナンバードインターフェイス表示方法を新しく拡張し、図６に示すようになる。
Ｌｅｎｇｔｈフィールドは、ＲＦＣ６１０７での意味と同じであり、オブジェクト全体の長さを示す。
Ｃｌａｓｓ−Ｎｕｍフィールドは、ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤオブジェクト値で、１９３であり、変化できない。
Ｃ−Ｔｙｐｅフィールドは、ＲＦＣ６１０７において値４を取り、新しく拡張されたものの値に対して、新たに定義して、ＩＡＮＡに申し込む必要がある。
Ａｒｅａ ＩＤフィールドは、新しく拡張されたエリア番号フィールドである。

ＬＳＲ’ｓ Ｒｏｕｔｅｒ ＩＤ（ラベルスイッチルータ識別子）フィールドは、ルータＩＤを示し、新しく拡張された表示においてエリア内で唯一であるだけでよい。

Ｉｎｔｅｒｆａｃｅ ＩＤフィールドは、ルータ内部ポートアドレスを示し、ルータ内部に割り当てられる。
Ａｃｔｉｏｎｓ（モーション）フィールドは、ＲＦＣ６１０７におけるフィールドと一致する。
ＴＬＶｓは拡張されない。

ステップ１２：ネットワークリソース設定の場合、それぞれのエリア番号が異なり、エリア内でルータ番号が唯一であるように設定する。
ルータ番号の割り当てに対して、エリア内で唯一であるように割り当てるだけでよく、ルータプロトコルによりエリア内とエリア間のフラッディングを行い、エリア内ノードがエリア内リソース情報を取得し、エリア間ノードが各エリア間のリソース情報を取得し、異なるエリアのノードはエリア番号及びルータ番号の結合によって異なるノードに分けられる。
ルータプロトコルエリアの区画は、プロトコルヘッダにおけるエリアを直接に使用する表示方式を採用してもよく、ｄｒａｆｔ−ｉｅｔｆ−ｃｃａｍｐ−ｒｆｃ５７８７ｂｉｓにおける第２章に記述された方式を採用してもよく、異なるレベルのエリアはプロトコル処理の実例で区別され、アンナンバードリソースが異なるエリアに存在することを区別するだけでよく、各エリアのルータ番号が同一であってもよく、エリア間リンクはＯＳＰＦ−ＴＥルータフラッディングにおいてＲＦＣ５３９２で定義された遠端自律エリア番号（Remote AS Number）サブＴＬＶの表示方法を使用する。

ルータプロトコルＯＳＰＦ−ＴＥエリアの区画設定は以下のとおりである。

それぞれのエリア番号が異なり、エリア内ルータＩＤは他のエリアルータＩＤと一致してもよい。

ＯＳＰＦ−ＴＥプロトコルにおける不透明（Opaque）リンク状態通知（Link State Advertisements、ＬＳＡと略称する）でエリア内リソースとエリア間リソースを表示する。ルータ情報はＯｐａｑｕｅ ＬＳＡにおけるタイプが１であるルータアドレス（Router Address）トップレベル（Top Level）ＴＬＶで表示され、ＲＦＣ３６３０を参照する。リンクリソースはＯｐａｑｕｅ ＬＳＡにおけるタイプが２であるリンク（Link）トップレベル（Top Level）ＴＬＶで表示され、ＲＦＣ３６３０を参照する。

アンナンバードリンクのローカルポート及び遠端ポートは、Ｌｉｎｋ ＴＬＶでＲＦＣ４２０３に定義されたタイプが１１であるリンクローカル遠端識別子（Link Local / Remote Identifiers）ｓｕｂ−ＴＬＶで表示され、ローカル及び遠端ルータＩＤは、Ｌｉｎｋ ＴＬＶでｄｒａｆｔ−ｉｅｔｆ−ｃｃａｍｐ−ｒｆｃ５７８７ｂｉｓに定義されたローカル遠端ルータ識別子（Local and Remote TE Router ID）ｓｕｂ−ＴＬＶで表示され、遠端エリアＩＤはＬｉｎｋ ＴＬＶでＲＦＣ５３９２に定義されたローカル遠端ルータ識別子（Remote AS Number sub-TLV）ｓｕｂ−ＴＬＶで表示される。

ＯＳＰＦ−ＴＥメッセージヘッダにおけるエリア（Area）ＩＤフィールドで該エリアＩＤを表示してもよく、ｄｒａｆｔ−ｉｅｔｆ−ｃｃａｍｐ−ｒｆｃ５７８７ｂｉｓにおける第２章で記述された方式のように、異なるレベルのエリアをプロトコル処理実例で区別してもよい。

それに対応して、図７に示すように、エリア１とエリア２はそれぞれ４つのルータを有し、番号がそれぞれルータ１、ルータ２、ルータ３、ルータ４に設定されている。エリア１におけるルータ１とルータ３との間のエリア内のアンナンバードリンクはルータ１のＯＳＰＦ−ＴＥメッセージにあり、ローカルポートが２であり、遠端ポートが１であり、ローカルルータＩＤが１であり、遠端ルータＩＤが３であり、遠端エリアＩＤが１である。エリア１におけるルータ４とエリア２におけるルータ１との間のエリア間アンナンバードリンクはエリア１のルータ４におけるＯＳＰＦ−ＴＥメッセージにあり、ローカルポートが３であり、遠端ポートが１であり、ローカルルータＩＤが４であり、遠端ルータＩＤが１であり、遠端エリアＩＤが２である。

ステップ１３：クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソースを前記３要素グループで表示する。

クロスエリアサービスの作成及び状態更新の場合、シグナリングメッセージにおけるリソース表示方法は拡張後のアンナンバードインターフェイス方式を採用する。
エリア内のトップノードはＲＳＶＰシグナリングのＰＡＴＨ（パス）メッセージを受信し、そのうちのＥＲＯオブジェクトを解析し、サービスの該エリアパス情報及びエリア内テールノードを確定し、エリア番号を直接比較することで完成することができ、該ノードの所在するエリアと同一のすべてのアンナンバードインターフェイスサブオブジェクトセットは、該エリアパス情報であり、最後の該ノードの所在するエリアと同一のアンナンバードインターフェイスサブオブジェクトは、該エリアの境界ノードを指摘し、ＥＲＯをルータ処理モジュールで処理する必要がない。
エリア内テールノードは受信されたＰＡＴＨメッセージにおけるＲＲＯオブジェクトにより、該エリアサービスが通過したパスを確定することができ、該ノードの所在するエリアと同一のすべてのアンナンバードインターフェイスサブオブジェクトセットは、該エリアパス情報である。
エリア内のトップノードは受信されたＲＥＳＶメッセージにおけるＲＲＯオブジェクトにより、該エリアサービスが本当に通過したパスを確定することができ、該ノードの所在するエリアと同一のすべてのアンナンバードインターフェイスサブオブジェクトセットは、該エリアの実在パス情報である。
ＰＡＴＨメッセージにおいて、ＲＳＶＰ＿ＨＯＰオブジェクトはメッセージノードを送信する出力ポートリソース位置を示し、ＲＥＳＶメッセージにおいて、ＲＳＶＰ＿ＨＯＰオブジェクトはメッセージノードを送信する逆方向出力ポートリソース位置を示し、ＲＳＶＰ＿ＨＯＰオブジェクトにＩＦ＿ＩＤ ＴＬＶを添加することによりアンナンバードリンク位置を表示し、ＲＦＣ４９２０の第６．２章節には一連のＴＬＶを拡張し、そのうちのＯＳＰＦエリア（ＲＥＰＯＲＴＩＮＧ＿ＯＳＰＦ＿ＡＲＥＡ（報告ＯＳＰＦエリア））ＴＬＶでＩＦ＿ＩＤにおけるアンナンバードリンクの所在するエリアを表示し、ＲＳＶＰ＿ＨＯＰオブジェクトにおいてＩＦ＿ＩＤ ＴＬＶとＲＥＰＯＲＴＩＮＧ＿ＯＳＰＦ＿ＡＲＥＡ ＴＬＶを併用し、アンナンバードインターフェイスリソースを共同で示す。

拡張後、ＲＳＶＰ−ＴＥメッセージ処理は以下のとおりである。

図７に示すように、太線は１つのクロスエリアの、トラフィックエンジニアリングに基づくラベルスイッチパス（Traffic Engineer - Label Switched Path、ＴＥ−ＬＳＰと略称する）を作成することを示し、アンナンバードリンクリソースを使用して、パス上のそれぞれのホップをエリア番号、ルータ番号、ポートの３要素グループとして示し、ストリクトな表示パスを使用することを配慮すると、図におけるパスは＜エリア１、ルータ１、ポート１＞、＜エリア１、ルータ１、ポート２＞、＜エリア１、ルータ３、ポート１＞、＜エリア１、ルータ３、ポート２＞、＜エリア１、ルータ４、ポート２＞、＜エリア１、ルータ４、ポート３＞、＜エリア２、ルータ１、ポート１＞、＜エリア２、ルータ１、ポート３＞、＜エリア２、ルータ３、ポート１＞、＜エリア２、ルータ３、ポート２＞、＜エリア２、ルータ４、ポート１＞、＜エリア２、ルータ４、ポート３＞である。正方向はＰＡＴＨメッセージを送信処理する方向を指し、逆方向はＲＥＳＶメッセージを送信処理する方向を指す。後のＥＲＯ、ＲＲＯ等のオブジェクトは１１において拡張されたエリア番号、ルータ番号、ポートの３要素グループの記述方式を採用する。

１３．１、ＰＡＴＨメッセージ処理
ＲＦＣ３２０９における４．３、４．４章節のＥＲＯとＲＲＯを処理する処理方式に従って、各ノードがＰＡＴＨメッセージを処理した後、下流に送信されるＰＡＴＨメッセージにおいて、該ノードの関連するポートをＥＲＯから除去し、且つ該ノードの出力ポートをプッシュ方式でＲＲＯのオブジェクトに添加する。ＲＳＶＰ＿ＨＯＰオブジェクトにおけるＴＬＶはＰＡＴＨメッセージを送信するノードの出力ポートを示す。

エリア１のルータ１はクロスエリアパスを取得した後、エリア番号を比較することにより、そのエリア番号と一致するルータホップ、＜エリア１、ルータ１、ポート１＞、＜エリア１、ルータ１、ポート２＞、＜エリア１、ルータ３、ポート１＞、＜エリア１、ルータ３、ポート２＞、＜エリア１、ルータ４、ポート２＞、＜エリア１、ルータ４、ポート３＞は、ＴＥ−ＬＳＰがエリア１にサービスを作成することに使用する必要があるリンクポートリソースである。＜エリア１、ルータ４、ポート３＞は、最後のエリア番号が一致するルータホップとして、それがＴＥ−ＬＳＰのエリア１での境界リンクであることを示し、エリア１のルータ４はエリア１の最後のノードである。エリア１のルータ１から送信したＰＡＴＨメッセージにおいて、ＥＲＯは前記１１．１に拡張されたアンナンバードインターフェイスサブオブジェクトを採用し、ＥＲＯにそれぞれのノードの出力ポートのみが含まればよく、そうすると＜エリア１、ルータ３、ポート２＞、＜エリア１、ルータ４、ポート３＞、＜エリア２、ルータ１、ポート３＞、＜エリア２、ルータ３、ポート２＞、＜エリア２、ルータ４、ポート３＞として示し、そのＲＳＶＰ＿ＨＯＰオブジェクトにおいて、ＩＦ＿ＩＤ ＴＬＶは＜ルータ１、ポート２＞として示し、ＲＥＰＯＲＴＩＮＧ＿ＯＳＰＦ＿ＡＲＥＡ ＴＬＶはエリア１である。

エリア１のルータ４が受信したＰＡＴＨメッセージにおいて、ＲＲＯは＜エリア１、ルータ１、ポート２＞、＜エリア１、ルータ３、ポート２＞であり、ＥＲＯは＜エリア１、ルータ４、ポート３＞、＜エリア２、ルータ１、ポート３＞、＜エリア２、ルータ３、ポート２＞、＜エリア２、ルータ４、ポート３＞であり、エリア１のルータ４は、処理後、該ノードの出力ポートがポート３であることを知るようになり、それにより、エリア１におけるパス全体が＜エリア１、ルータ１、ポート２＞、＜エリア１、ルータ３、ポート２＞、＜エリア１、ルータ４、ポート３＞であることを知るようになる。エリア１のルータ４が送信したＰＡＴＨメッセージにおいて、ＥＲＯは＜エリア２、ルータ１、ポート３＞、＜エリア２、ルータ３、ポート２＞、＜エリア２、ルータ４、ポート３＞として示し、ＲＳＶＰ＿ＨＯＰオブジェクトにおいて、ＩＦ＿ＩＤ ＴＬＶは＜ルータ４、ポート３＞として示し、ＲＥＰＯＲＴＩＮＧ＿ＯＳＰＦ＿ＡＲＥＡ ＴＬＶはエリア１の番号である。

エリア２のルータ１はＰＡＴＨメッセージを受信した後、ＲＳＶＰ−ＴＥ処理モジュールはＥＲＯからＴＥ−ＬＳＰのエリア２でのパスを直接に確定することができ、すべてのＥＲＯをルータ処理モジュールで処理してから確定する必要がなく、エリア２におけるパスは＜エリア２、ルータ１、ポート３＞、＜エリア２、ルータ３、ポート２＞、＜エリア２、ルータ４、ポート３＞である。

エリア２のルータ４が受信したＰＡＴＨメッセージにおいて、ＲＲＯは＜エリア１、ルータ１、ポート２＞、＜エリア１、ルータ３、ポート２＞、＜エリア１、ルータ４、ポート３＞、＜エリア２、ルータ１、ポート３＞、＜エリア２、ルータ３、ポート２＞として示し、ＥＲＯは＜エリア２、ルータ４、ポート３＞として示し、ＥＲＯとＲＲＯにエリア番号が一致する部分を結合し、エリア２ルータ４は、該エリアのパスが＜エリア２、ルータ１、ポート３＞、＜エリア２、ルータ３、ポート２＞、＜エリア２、ルータ４、ポート３＞であることを知ることができ、ルータ処理モジュールから情報を取得する必要がない。

１３．２、ＲＥＳＶメッセージ処理
テールノードはＰＡＴＨメッセージに応答して、上流にＲＥＳＶメッセージを送信し、その中にＲＲＯ情報が含まれ、それぞれのノードは自分の逆方向出力ポートをプッシュ方式の情報としてＲＲＯに加え、ＲＲＯに含まれるのはＴＥ−ＬＳＰの実在パスである。ＲＳＶＰ＿ＨＯＰオブジェクトにおけるＴＬＶは、ＲＥＳＶメッセージを送信するノードの逆方向出力ポートを示す。

エリア２のルータ４はＴＥ−ＬＳＰのテールノードであると確認された後、上流にＲＥＳＶメッセージを送信し、ＲＲＯは＜エリア２、ルータ４、ポート１＞であり、ＲＳＶＰ＿ＨＯＰオブジェクトにおいて、ＩＦ＿ＩＤ ＴＬＶは＜ルータ４、ポート１＞として示し、ＲＥＰＯＲＴＩＮＧ＿ＯＳＰＦ＿ＡＲＥＡ ＴＬＶはエリア２である。

エリア２のルータ３は上流にＲＥＳＶメッセージを送信し続け、自分の逆方向出力ポートをＲＲＯに＜エリア２、ルータ３、ポート１＞、＜エリア２、ルータ４、ポート１＞として加え、ＲＳＶＰ＿ＨＯＰオブジェクトにおいて、ＩＦ＿ＩＤ ＴＬＶは＜ルータ３、ポート１＞として示し、ＲＥＰＯＲＴＩＮＧ＿ＯＳＰＦ＿ＡＲＥＡ ＴＬＶはエリア２である。

エリア２のルータ１はＲＥＳＶを受信した後、該エリアのトップノードとし、ＲＥＳＶメッセージからＴＥ−ＬＳＰの該エリアでの実在パスを取得することができ、逆方向出力ポートを結合し、エリア２における実在パスは＜エリア２、ルータ１、ポート１＞、＜エリア２、ルータ３、ポート１＞、＜エリア２、ルータ４、ポート１＞である。送信されたＲＥＳＶメッセージにおいて、ＲＲＯは＜エリア２、ルータ１、ポート１＞、＜エリア２、ルータ３、ポート１＞、＜エリア２、ルータ４、ポート１＞であり、ＲＳＶＰ＿ＨＯＰオブジェクトにおいてＩＦ＿ＩＤ ＴＬＶは＜ルータ１、ポート１＞として示し、ＲＥＰＯＲＴＩＮＧ＿ＯＳＰＦ＿ＡＲＥＡ ＴＬＶはエリア２である。

エリア１のルータ４、ルータ３は、それぞれＲＥＳＶメッセージを受信した後、自分の逆方向出力ポートをＲＲＯに加えた後、上流にＲＥＳＶメッセージを転送する。

エリア１のルータ１はＲＥＳＶメッセージを受信した後、ＴＥ−ＬＳＰのトップノードとし、ＲＲＯからすべての実在パス、即ち＜エリア１、ルータ３、ポート１＞、＜エリア１、ルータ４、ポート２＞、＜エリア２、ルータ１、ポート１＞、＜エリア２、ルータ３、ポート１＞、＜エリア２、ルータ４、ポート１＞を取得し、該エリアの実在パスを識別する。

１３．３、クロスエリアサービスネットワークエレメントの間に情報を通知する場合、シグナリングメッセージにおいて故障位置を拡張後のアンナンバードインターフェイス方式で表示する。
クロスエリアサービスについて、各ネットワークエレメントはＮＯＴＩＦＹ（通知）又はＰＡＴＨＥＲＲ（パスエラー）シグナリングメッセージにより他のネットワークエレメントに相関情報を通知することができ、そのうち故障相関情報はＥＲＲＯＲ＿ＳＰＥＣオブジェクトにおけるＩＦ＿ＩＤ ＴＬＶにより故障が発生した具体的なアンナンバードリンク位置を含み、ＥＲＲＯＲ＿ＳＰＥＣオブジェクトにＲＥＰＯＲＴＩＮＧ＿ＯＳＰＦ＿ＡＲＥＡ ＴＬＶを新しく添加してＩＦ＿ＩＤにおけるアンナンバードリンクの所在するエリアを示す。

ＮＯＴＩＦＹ及びＰＡＴＨＥＲＲメッセージ処理は以下のとおりである。

図７に示すように、ＴＥ−ＬＳＰにおいて、エリア１のルータ３はポート２が故障したことを検出すると、ＮＯＴＩＦＹメッセージ又はＰＡＴＨＥＲＲを利用して故障情報を上流に伝達し、メッセージＥＲＲＯＲ＿ＳＰＥＣオブジェクトにおいてＩＦ＿ＩＤ ＴＬＶは＜ルータ３、ポート２＞として示し、ＲＥＰＯＲＴＩＮＧ＿ＯＳＰＦ＿ＡＲＥＡ ＴＬＶはエリア１である。

１３．４、クロスエリアサービスはシグナリング方式でアンナンバードのフォワード隣接リンク（Forwarding Adjacencies、ＦＡと略称する）を作成する場合、拡張後のアンナンバードインターフェイス方式を採用する。
シグナリング方式でアンナンバードのフォワード隣接リンクを作成し、トンネルインターフェースオブジェクト（ＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤ）にエリア番号を追加した後、エリア内の異なるネットワークエレメント間のＦＡリンクの作成をサポートし、且つクロスエリアの異なるネットワークエレメント間のＦＡリンクの作成をサポートすることもできる。

ＦＡ作成のメッセージ処理は以下のとおりである。

図７に示すように、ＴＥ−ＬＳＰは最終的にクロスエリアＦＡの作成をもたらし、エリア１のルータ１はＰＡＴＨメッセージにおいて１１．３で拡張されたＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤオブジェクトを使用し、エリアＩＤは値１を取り、ルータＩＤは１であり、ポートは自動に割り当てられ、割り当てられたポートが４であると仮定する。

エリア２のルータ４は応答したＲＥＳＶメッセージにおいて１１．３で拡張されたＬＳＰ＿ＴＵＮＮＥＬ＿ＩＮＴＥＲＦＡＣＥ＿ＩＤオブジェクトを使用し、エリアＩＤは値２を取り、ルータＩＤは４であり、ポートは自動に割り当てられ、割り当てられたポートが４であると仮定する。

このように、図において、エリア１のルータ１のポート１からエリア２のルータ４のポート３までの間に作成されたＴＥ−ＬＳＰは、最終的にエリア１のルータ１のポート４とエリア２のルータ４のポート４のトラフィックエンジニアリングリンクを作成するようになった。

本発明の実施例では、ＲＳＶＰ−ＴＥシグナリングにアンナンバードリンクリソースの表現方法を拡張し、関連技術に比べて、エリア番号を添加することにより、ルータ番号がエリア内で唯一であるようにシグナリングが要求するという制限を除去し、ルータ番号のエリア内での値の範囲を拡げ、ルータ番号リソースの消費を遅くする。すべてのパス情報がエリア番号、ルータ番号及びポートの３要素グループ方式を採用し、且つ順に置くため、同一のエリア下でのルータホップを集めて置き、且つエリア番号が同一であり、エリア番号が同一である１番目のルータホップ及び最後のルータホップはこのエリアの境界ノードを表し、従って、シグナリング処理モジュールはＲＳＶＰメッセージからエリアの境界ノードを直接に確定し、ルータ処理モジュールとのインタラクションを減少させ、境界ネットワークエレメントのシグナリング処理の速度を速くすることができる。

図８は本発明の実施例に係るＲＳＶＰ−ＴＥシグナリングを処理するためのシステム８０の模式図であり、図８に示すように、本実施例のシステムは、
ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張し、シグナリングにおけるリンクリソースをエリア番号、ルータ番号及びポートからなる３要素グループで表示するように設定される拡張モジュール８１、
ネットワークリソース設定の場合、それぞれのエリア番号が異なり、エリア内でルータ番号が唯一であるように設定するように設定される設定モジュール８２、
クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソースを前記３要素グループで表示するように設定される処理モジュール８３、を備える。

そのうち、前記拡張モジュールが拡張した、アンナンバードリソースを使用するオブジェクトは、
明示ルータオブジェクトのサブオブジェクト、
ＲＳＶＰ＿ＨＯＰオブジェクト、
ＥＲＲＯＲ＿ＳＰＥＣオブジェクト、
ラベルスイッチパストンネルインターフェース番号オブジェクト、を含んでよい。

もちろん、拡張された、アンナンバードリソースを使用するオブジェクトは、他のオブジェクトを含んでもよい。

そのうち、前記拡張モジュールがＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張することは、ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトに対してエリア番号フィールドを拡張し、ルータ番号をエリア内のみで唯一であるように拡張することを含む。

好適な実施例では、前記設定モジュールは、ネットワークリソース設定の過程において、開放型最短経路優先のトラフィックエンジニアリングプロトコルにおける不透明リンク状態通知でエリア内リソース及びエリア間リソースを表示することに更に用いられる。

そのうち、前記処理モジュールが、クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソースを前記３要素グループで表示することは、クロスエリアサービスの作成及び状態更新の場合、シグナリングメッセージにおいてリソースを前記３要素グループで表示すること、クロスエリアサービスネットワークエレメントの間に情報を通知する場合、シグナリングメッセージにおいて故障位置を前記３要素グループで表示すること、クロスエリアサービスはシグナリング方式でアンナンバードのフォワード隣接リンクを作成する場合、前記３要素グループで表示すること、という方式の１種又は複数種を含む。

当業者は、上記方法における全部又は一部のステップをプログラムによって関連ハードウェアに命令を出して完成させることができ、前記プログラムがコンピュータ読み取り可能な記憶媒体、例えば読取り専用メモリ、ディスク又は光ディスク等に記憶されていてもよいことを理解することができる。選択的に、上記実施例の全部又は一部のステップは１つ又は複数のＩＣにより実現されてもよい。それに対応して、上記実施例における各モジュール／ユニットはハードウェアの形式で実現されてもよく、ソフトウェア機能モジュールの形式で実現されてもよい。本発明の実施例はいかなる特定形式のハードウェアとソフトウェアの組合せに限らない。

以上は本発明の好適な実施形態に過ぎず、もちろん、本発明は他の複数種の実施例を有しうる。本発明の趣旨及びその実質から逸脱しない場合に、当業者は本発明に基づいて各種の対応する変更及び修正を行うことができるが、これらの対応する変更及び修正はいずれも本発明の請求の範囲に属する。

本発明の実施例はＲＳＶＰ−ＴＥシグナリングを処理するための方法及びシステムを提供し、ＲＳＶＰ−ＴＥアンナンバードインターフェイスにエリア番号が含まれ、エリア番号及びルータ番号を連携して作用させ、一方では、ルータ番号がエリア内で唯一であるようにシグナリングが要求するという制限を除去し、異なるエリアのルータ番号が繰り返して使用することができることを保証し、ルータ番号のエリア内での値の範囲を拡げ、ルータ番号リソースの消費を遅くし、他方では、シグナリングのルータ情報においてエリアの境界ノードを直接に確定し、サービスシグナリング処理速度を速くすることができる。

Claims (10)

1. ＲＳＶＰ−ＴＥ（リソース予約プロトコル）シグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張し、シグナリングにおけるリンクリソースをエリア番号、ルータ番号及びポートからなる３要素グループで表示することと、
   ネットワークリソース設定の場合、それぞれのエリア番号が異なり、エリア内でルータ番号が唯一であるように設定することと、
   クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソースを前記３要素グループで表示することと、を含むトラフィックエンジニアリングのＲＳＶＰ−ＴＥシグナリングを処理するための方法。
2. 前記拡張された、アンナンバードリソースを使用するオブジェクトは、
   明示ルータオブジェクトのサブオブジェクト、
   リソース予約ホップオブジェクト、
   エラー情報オブジェクト、及び
   ラベルスイッチパストンネルインターフェース番号オブジェクトを含む請求項１に記載の方法。
3. 前記ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張することは、
   ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトに対してエリア番号フィールドを拡張し、ルータ番号をエリア内で唯一であるように拡張することを含む請求項１又は２に記載の方法。
4. 前記ネットワークリソース設定は、
   開放型最短経路優先のトラフィックエンジニアリングプロトコルにおける不透明リンク状態通知でエリア内リソース及びエリア間リソースを表示することを更に含む請求項１に記載の方法。
5. 前記クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソースを前記３要素グループで表示することは、
   クロスエリアサービスの作成及び状態更新の場合、シグナリングメッセージにおいてリソースを前記３要素グループで表示すること、
   クロスエリアサービスネットワークエレメントの間に情報を通知する場合、シグナリングメッセージにおいて故障位置を前記３要素グループで表示すること、
   クロスエリアサービスはシグナリング方式でアンナンバードのフォワード隣接リンクを作成する場合、前記３要素グループで表示すること、の１種又は複数種を含む請求項１に記載の方法。
6. ＲＳＶＰ−ＴＥ（リソース予約プロトコル）シグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張し、シグナリングにおけるリンクリソースをエリア番号、ルータ番号及びポートからなる３要素グループで表示するように設定される拡張モジュール、
   ネットワークリソース設定の場合、それぞれのエリア番号が異なり、エリア内でルータ番号が唯一であるように設定するように設定される設定モジュール、
   クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソースを前記３要素グループで表示するように設定される処理モジュール、を備えるトラフィックエンジニアリングのＲＳＶＰ−ＴＥシグナリングを処理するためのシステム。
7. 前記拡張モジュールが拡張した、アンナンバードリソースを使用するオブジェクトは、
   明示ルータオブジェクトのサブオブジェクト、
   リソース予約ホップオブジェクト、
   エラー情報オブジェクト、及び
   ラベルスイッチパストンネルインターフェース番号オブジェクトを含む請求項６に記載のシステム。
8. 前記拡張モジュールは、ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトに対してエリア番号フィールドを拡張し、ルータ番号をエリア内で唯一であるように拡張するという方式により、ＲＳＶＰ−ＴＥシグナリングにおいてアンナンバードリソースを使用するオブジェクトを拡張する請求項６又は７に記載のシステム。
9. 前記設定モジュールは更に、開放型最短経路優先のトラフィックエンジニアリングプロトコルにおける不透明リンク状態通知でエリア内リソース及びエリア間リソースを表示するという方式により、ネットワークリソースの設定を行う請求項６に記載のシステム。
10. 前記処理モジュールは、クロスエリアサービスの作成及び状態更新の場合、シグナリングメッセージにおいてリソースを前記３要素グループで表示すること、クロスエリアサービスネットワークエレメントの間に情報を通知する場合、シグナリングメッセージにおいて故障位置を前記３要素グループで表示すること、クロスエリアサービスがシグナリング方式でアンナンバードのフォワード隣接リンクを作成する場合、前記３要素グループで表示すること、という方式の１種又は複数種により、クロスエリアサービス適用の場合、シグナリングメッセージにおけるリソースを前記３要素グループで表示する請求項６に記載のシステム。
    

Images