特許 7327767 ブリッジネットワーク情報アドバタイズ方法、デバイス、およびパブリック属性管理コンポーネント

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

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

(11)【特許番号】

(24)【登録日】2023-08-07

(45)【発行日】2023-08-16

(54)【発明の名称】ブリッジネットワーク情報アドバタイズ方法、デバイス、およびパブリック属性管理コンポーネント

(51)【国際特許分類】

   H04L 47/2475 20220101AFI20230808BHJP

   H04L 47/72 20220101ALI20230808BHJP

【ＦＩ】

H04L47/2475

H04L47/72

【請求項の数】 14

(21)【出願番号】P 2021569506

(86)(22)【出願日】2020-05-28

(65)【公表番号】

(43)【公表日】2022-09-27

(86)【国際出願番号】 CN2020093031

(87)【国際公開番号】W WO2021012782

(87)【国際公開日】2021-01-28

【審査請求日】2021-11-26

(31)【優先権主張番号】201910662470.7

(32)【優先日】2019-07-22

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】ＺＴＥ Ｐｌａｚａ，Ｋｅｊｉ Ｒｏａｄ Ｓｏｕｔｈ，Ｈｉ－Ｔｅｃｈ Ｉｎｄｕｓｔｒｉａｌ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７ Ｃｈｉｎａ

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(74)【代理人】

【識別番号】110001519

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

(74)【代理人】

【識別番号】100199819

【弁理士】

【氏名又は名称】大行 尚哉

(74)【代理人】

【識別番号】100087859

【弁理士】

【氏名又は名称】渡辺 秀治

(72)【発明者】

【氏名】朱向陽

(72)【発明者】

【氏名】韓玉芳

【審査官】大石 博見

(56)【参考文献】

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

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

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

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

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

Ｈ０４Ｌ ４７／２４７５

Ｈ０４Ｌ ４７／７２

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

【請求項1】

ブリッジネットワーク情報のアドバタイズ方法であって、ブリッジネットワークの各ノードの各ポートにパブリック属性管理コンポーネントＣＡＭＣが設置され、前記ＣＡＭＣはリンクローカル登録プロトコルＬＲＰアプリケーションとＬＲＰとの間に設置され、前記方法は、
ＣＡＭＣは、ＬＲＰアプリケーションによってアドバタイズされた第１パブリック属性情報を受信し、前記第１パブリック属性情報をＬＲＰのデータベースに書き込むこと、および、
前記ＣＡＭＣは、ＬＲＰのデータベースによって報告された第２パブリック属性情報を受信し、前記第２パブリック属性情報をＬＲＰアプリケーションに報告することを含み、
ここで、前記第１パブリック属性情報は、前記ＬＲＰアプリケーションがアドバタイズする必要があるパブリック属性情報であり、前記第２パブリック属性情報は、前記ＬＲＰのデータベースが変更されたときに同期する必要があるパブリック属性情報であることを特徴とするブリッジネットワーク情報のアドバタイズ方法。

【請求項2】

前記ＣＡＭＣが、ＬＲＰアプリケーションによってアドバタイズされた第１パブリック属性情報を受信し、前記第１パブリック属性情報をＬＲＰのデータベースに書き込むことは、
前記ＣＡＭＣは、ＬＲＰアプリケーションがＣＡＭＣ情報アドバタイズサービスプリミティブを介してアドバタイズされた第１パブリック属性情報を受信することと、
前記ＣＡＭＣは、前記第１パブリック属性情報をタイプ長さ値ＴＬＶフォーマットにカプセル化し、ＬＲＰ書き込み記録要求プリミティブを呼び出して、前記第１パブリック属性情報をＬＲＰのＡｐｐｌｉｃａｎｔデータベースに書き込むこととを含むことを特徴とする請求項１に記載の方法。

【請求項3】

前記ＣＡＭＣは、ＬＲＰのデータベースによって報告された第２パブリック属性情報を受信し、前記第２パブリック属性情報をＬＲＰアプリケーションに報告することは、
前記ＣＡＭＣは、ＬＲＰのＲｅｇｉｓｔｒａｒデータベースがＬＲＰ記録書き込み表示プリミティブを介して報告されたＴＬＶカプセル化フォーマットの第２パブリック属性情報を受信することと、
前記ＣＡＭＣは、前記ＴＬＶカプセル化フォーマットの第２パブリック属性情報をカプセル化解除し、前記第２パブリック属性情報を、ＣＡＭＣ情報報告プリミティブを介して、本ポートのすべてのＬＲＰアプリケーションに報告することとを含むことを特徴とする請求項１に記載の方法。

【請求項4】

前記ＣＡＭＣは、ＬＲＰのデータベースによって報告された第２パブリック属性情報を受信し、前記第２パブリック属性情報をＬＲＰアプリケーションに報告する後、前記方法は、
前記ＣＡＭＣは、前記第２パブリック属性情報を拡散する必要があると確定し、前記第２パブリック属性情報を本ノードの他のポートのＣＡＭＣに拡散することをさらに含むことを特徴とする請求項１に記載の方法。

【請求項5】

前記第２パブリック属性情報を拡散する必要があると確定することは、
属性拡散フラグテーブルＣＰＦＴをクエリすることにより、前記第２パブリック属性情報を拡散する必要があると確定することを含むことを特徴とする請求項４に記載の方法。

【請求項6】

前記方法は、
前記ＣＡＭＣは、本ノードの他のポートのＣＡＭＣによって拡散された第３パブリック属性情報を受信し、前記第３パブリック属性情報は、拡散する必要があるパブリック属性情報であることと、
前記ＣＡＭＣは、前記第３パブリック属性情報をＬＲＰのデータベースに書き込むこととをさらに含むことを特徴とする請求項１に記載の方法。

【請求項7】

前記方法は、
前記ＣＡＭＣは、ＬＲＰアプリケーションによって送信されたクエリ要求を受信し、前記クエリ要求は、指定された属性情報をクエリするために使用されることと、
前記ＣＡＭＣはＬＲＰデータベースをクエリし、クエリ結果を前記ＬＲＰアプリケーションに返すこととを含むことを特徴とする請求項１に記載の方法。

【請求項8】

前記ＣＡＭＣが、ＬＲＰアプリケーションによって送信されたクエリ要求を受信することは、前記ＣＡＭＣが、前記ＬＲＰアプリケーションのＣＡＭＣクエリサービスプリミティブを介して送信されたクエリ要求を受信することを含み、
前記ＣＡＭＣが、ＬＲＰデータベースをクエリし、クエリ結果を前記ＬＲＰアプリケーションに返すことは、前記ＣＡＭＣが、ＬＲＰデータベースクエリプリミティブを呼び出して、ＬＲＰデータベースをクエリし、前記属性情報を取得し、前記ＣＡＭＣは、前記属性情報とスクリーニングポリシーに従ってクエリ結果を決定し、前記クエリ結果を前記ＬＲＰアプリケーションに返すことを含む、ことを特徴とする請求項７に記載の方法。

【請求項9】

ＣＡＭＣであって、前記ＣＡＭＣはブリッジネットワークの各ノードの各ポートのＬＲＰアプリケーションとＬＲＰとの間に設置され、属性宣言コンポーネントＣＡＤＥ、エンコーディングとデコーディングコンポーネントＣＣＤＥ、および属性登録コンポーネントＣＡＲＥを含み、ここで、
前記ＣＡＤＥは、ＬＲＰアプリケーションによってアドバタイズされた第１パブリック属性情報を受信して、前記ＣＣＤＥに送信するように設置され、
前記ＣＣＤＥは、前記第１パブリック属性情報をＴＬＶフォーマットにカプセル化し、前記ＴＬＶフォーマットにカプセル化された第１パブリック属性情報をＬＲＰのデータベースに書き込み、および、ＬＲＰのデータベースによって報告されたＴＬＶカプセル化フォーマットの第２パブリック属性情報を受信し、前記ＴＬＶカプセル化フォーマットの第２パブリック属性情報をカプセル化解除して、前記ＣＡＲＥに送信するように設置され、
前記ＣＡＲＥは、前記第２パブリック属性情報をＬＲＰアプリケーションに報告するように設置され、
ここで、前記第１パブリック属性情報は、前記ＬＲＰアプリケーションがアドバタイズする必要があるパブリック属性情報であり、前記第２パブリック属性情報は、前記ＬＲＰのデータベースが変更されたときに同期する必要があるパブリック属性情報であることを特徴とするＣＡＭＣ。

【請求項10】

前記ＣＡＭＣは、属性拡散フラグテーブルＣＰＦＴと属性伝播コンポーネントＣＰＰＥとをさらに含み、各ノードのすべてのポートは一つのＣＰＰＥを共有し、
前記ＣＡＲＥは、ＣＰＦＴをクエリすることによって前記第２パブリック属性情報を拡散する必要があることを決定すると、前記第２パブリック属性情報を前記ＣＰＰＥに送信するようにさらに設置され、
前記ＣＰＰＥは、前記第２パブリック属性情報を本ノードの他のポートのＣＡＭＣにおけるＣＡＤＥに拡散することを特徴とする請求項９に記載のＣＡＭＣ。

【請求項11】

前記ＣＡＤＥは、前記ＣＰＰＥによって拡散された第３パブリック属性情報を受信し、前記第３パブリック属性情報を前記ＣＣＤＥに送信するようにさらに設置され、前記第３パブリック属性情報は、拡散する必要があるパブリック属性情報であり、
前記ＣＣＤＥは、前記第３パブリック属性情報をＴＬＶフォーマットにカプセル化し、前記ＴＬＶフォーマットにカプセル化された第３パブリック属性情報をＬＲＰのデータベースに書き込むように設置されることを特徴とする請求項１０に記載のＣＡＭＣ。

【請求項12】

前記ＣＡＤＥは、ＬＲＰアプリケーションによって送信されたクエリ要求を受信し、前記クエリ要求をＣＣＤＥに送信するようにさらに設置され、前記クエリ要求は、指定された属性情報をクエリするために使用され、
前記ＣＣＤＥは、前記クエリ要求をＴＬＶフォーマットにカプセル化し、ＬＲＰデータベースをクエリし、前記属性情報を取得して、前記ＣＡＲＥに送信するようにさらに設置され、
前記ＣＡＲＥは、前記属性情報およびスクリーニングポリシーに従ってクエリ結果を決定し、前記クエリ結果を前記ＬＲＰアプリケーションに返すようにさらに設置されることを特徴とする請求項９に記載のＣＡＭＣ。

【請求項13】

ブリッジネットワーク情報アドバタイズデバイスであって、メモリ、プロセッサ、およびメモリに格納され、且つプロセッサ上で実行することができるコンピュータプログラムを含み、前記プロセッサは、前記プログラムを実行するときに、請求項１～８のいずれかの1項に記載の前記ブリッジネットワーク情報のアドバタイズ方法を実現することを特徴とするブリッジネットワーク情報アドバタイズデバイス。

【請求項14】

コンピュータ可読記憶媒体であって、コンピュータ実行可能命令を格納し、前記コンピュータ実行可能命令は、請求項１～８のいずれかの1項に記載の前記ブリッジネットワーク情報のアドバタイズ方法を実行するために使用されることを特徴とするコンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はブリッジネットワーク情報のアドバタイズ方法、デバイス、パブリック属性管理コンポーネント、およびコンピュータ可読記憶媒体に関するが、これらに限定されない。

【背景技術】

【0002】

ＬＲＰ（Ｌｉｎｋ－ｌｏｃａｌ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、リンクローカル登録プロトコル）は、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ、電気電子技術者協会）ＴＳＮ（Ｔｉｍｅ Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋ、Ｔｉｍｅ Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋ、時間敏感ネットワーク）ワーキンググループによって提案された、ネットワーク内で高速且つ高い信頼性でホップごとに情報を配信するプロトコルであり、優れたスケーラビリティと１ＭＢｙｔｅレベルのデータ伝送にサポートするという利点を有する。ＬＲＰプロトコルにおいて、さまざまなアプリケーションプロトコルまたはコンポーネントを定義でき、これらのアプリケーションはＬＲＰと緩く結合され、それぞれが属性値とセマンティクスを定義し、ＬＲＰがデータ送信チャネルのみとして使用され、ＬＲＰより提供されたサービスプリミティブを呼び出すことにより、属性を宣言および伝播する。

【0003】

ＬＲＰに基づくさまざまなアプリケーションは、ブリッジネットワーク内で一部のパブリック情報をアドバタイズする必要があり、たとえば、ＲＡＰ（Ｒｅｓｏｕｒｃｅ Ａｌｌｏｃａｔｅ Ｐｒｏｔｏｃｏｌ、リソース割り当てプロトコル）は、ネットワークにおける各ノード間でＳＲ（Ｓｔｒｅａｍ Ｒｅｓｅｒｖａｔｉｏｎ、ストリーム予約）Ｃｌａｓｓ（クラス）、キュー伝送選択アルゴリズム、キューＣｌａｓｓＭｅａｓｕｒｅＩｎｔｅｒｖａｌなどの情報をアドバタイズすることによってＳＲフィールドを確立し、そして、ＳＲフィールドに基づいてリソースを割り当て、また、他のプロトコルもＳＲフィールドに基づいて動作する必要がある場合もある。ただし、現在、ＳＲフィールド情報アドバタイズはＲＡＰと連動し、他のプロトコルがＳＲフィールド情報を使用する場合は、これらの情報を個別に定義してアドバタイズする必要があり、仕様の不整合やネットワークリソースの浪費を引き起こす可能性がある。

【発明の概要】

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

【0004】

以下は、本発明を詳しく説明されているトピックの概要であり、 この概要は、クレームの保護範囲を制限することを意図したものではない。

【0005】

本発明の実施形態は、ブリッジネットワーク情報のアドバタイズ方法、デバイス、パブリック属性管理コンポーネント、およびコンピュータ可読記憶媒体を提供する。

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

【0006】

本発明の実施形態は、ブリッジネットワーク情報のアドバタイズ方法を提供し、ブリッジネットワークの各ノードの各ポートにパブリック属性管理コンポーネントＣＡＭＣが設置され、前記ＣＡＭＣはリンクローカル登録プロトコルＬＲＰアプリケーションとＬＲＰとの間に設置され、前記方法は、ＣＡＭＣは、ＬＲＰアプリケーションによってアドバタイズされた第１パブリック属性情報を受信し、前記第１パブリック属性情報をＬＲＰのデータベースに書き込むこと、および、前記ＣＡＭＣは、ＬＲＰのデータベースによって報告された第２パブリック属性情報を受信し、前記第２パブリック属性情報をＬＲＰアプリケーションに報告することを含み、ここで、前記第１パブリック属性情報は、前記ＬＲＰアプリケーションがアドバタイズする必要があるパブリック属性情報であり、前記第２パブリック属性情報は、前記ＬＲＰのデータベースが変更されたときに同期する必要があるパブリック属性情報である。

【0007】

本発明の実施形態はＣＡＭＣをさらに提供し、前記ＣＡＭＣはブリッジネットワークの各ノードの各ポートのＬＲＰアプリケーションとＬＲＰとの間に設置され、属性宣言コンポーネントＣＡＤＥ、エンコーディングとデコーディングコンポーネントＣＣＤＥ、および属性登録コンポーネントＣＡＲＥを含み、ここで、前記ＣＡＤＥは、ＬＲＰアプリケーションによってアドバタイズされた第１パブリック属性情報を受信して、前記ＣＣＤＥに送信するように設置され、前記ＣＣＤＥは、前記第１パブリック属性情報をＴＬＶフォーマットにカプセル化し、前記ＴＬＶフォーマットにカプセル化された第１パブリック属性情報をＬＲＰのデータベースに書き込み、および、ＬＲＰのデータベースによって報告されたＴＬＶカプセル化フォーマットの第２パブリック属性情報を受信し、前記ＴＬＶカプセル化フォーマットの第２パブリック属性情報をカプセル化解除して、前記ＣＡＲＥに送信するように設置され、前記ＣＡＲＥは、前記第２パブリック属性情報をＬＲＰアプリケーションに報告するように設置され、ここで、前記第１パブリック属性情報は、前記ＬＲＰアプリケーションがアドバタイズする必要があるパブリック属性情報であり、前記第２パブリック属性情報は、前記ＬＲＰのデータベースが変更されたときに同期する必要があるパブリック属性情報である。

【0008】

本発明の実施形態はブリッジネットワーク情報アドバタイズデバイスをさらに提供し、メモリ、プロセッサ、およびメモリに格納され、且つプロセッサ上で実行することができるコンピュータプログラムを含み、前記プロセッサは、前記プログラムを実行するときに、前記ブリッジネットワーク情報のアドバタイズ方法を実現する。

【0009】

本発明の実施形態はコンピュータ可読記憶媒体をさらに提供し、コンピュータ実行可能命令を格納し、前記コンピュータ実行可能命令は、前記ブリッジネットワーク情報のアドバタイズ方法を実行するために使用される。

【発明の効果】

【0010】

本発明の実施形態において、ブリッジネットワークの各ノードの各ポートにＣＡＭＣが設置され、前記ＣＡＭＣは、ＬＲＰアプリケーションとＬＲＰとの間に設置され、ＣＡＭＣは、ＬＲＰアプリケーションによってアドバタイズされた第１パブリック属性情報を受信し、前記第１パブリック属性情報をＬＲＰのデータベースに書き込み、および前記ＣＡＭＣはＬＲＰのデータベースによって報告された第２パブリック属性情報を受信し、前記第２パブリック属性情報をＬＲＰアプリケーションに報告する。ここで、前記第１パブリック属性情報は、前記ＬＲＰアプリケーションがアドバタイズする必要があるパブリック属性情報であり、前記第２パブリック属性情報は、前記ＬＲＰのデータベースが変更されたときに同期する必要があるパブリック属性情報である。本発明の実施形態によって、パブリック属性情報は、ＣＡＭＣを介して均一に伝送および拡散し、一方で、複数のＬＲＰアプリケーションは、追加の定義なしにパブリック属性情報を共有することができ、他方で、同じポート上の複数のＬＲＰアプリケーションは、同じパブリック属性情報をアドバタイズする必要がある場合、アドバタイズする必要があるのは１回だけなので、リソースの浪費を回避できる。

【0011】

図面と詳細な説明を読んで理解した後、他の側面も理解することができる。

【図面の簡単な説明】

【0012】

【図1】図１は、本発明の実施形態に係るＲｅｃｏｒｄ ＬＲＰＤＵのカプセル化フォーマットの概略図である。

【図2】図２は、本発明の実施形態に係る各Ｒｅｃｏｒｄのエンコードフォーマットの概略図である。

【図3】図３は、本発明の実施形態に係るＣＡＭＣ、ＬＲＰおよびＬＲＰアプリケーションの間の関係概略図である。

【図4】図４は、本発明の実施形態に係るブリッジネットワーク情報のアドバタイズ方法のフローチャートである。

【図5】図５は、本発明の実施形態におけるステップ１０１のフローチャートである。

【図6】図６は、本発明の実施形態におけるステップ２０１のフローチャートである。

【図7】図７は、本発明の別の実施形態に係るブリッジネットワーク情報のアドバタイズ方法のフローチャートである。

【図8】図８は、本発明の実施形態に係るブリッジネットワーク情報のアドバタイズ方法において拡散を実現するフローチャートである。

【図9】図９は、本発明の実施形態に係るブリッジネットワーク情報のアドバタイズ方法においてクエリを実現するフローチャートである。

【図10】図１０は、本発明の実施形態のクエリシーケンス図である。

【図11】図１１は、本発明の実施形態のＣＡＭＣ構成の概略図である。

【図12】図１２は、本発明の実施形態に係るＬＲＰアプリケーションがＣＡＭＣを介して属性情報をアドバタイズするフローチャートである。

【図13】図１３は、本発明の第１応用例のフローチャートである。

【図14】図１４は、本発明の第２応用例のフローチャートである。

【図15】図１５は、本発明の実施形態の（ａ）および（ｂ）がＴＬＶコーディングフォーマットとする概略図である。

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

【0013】

以下、本発明の実施形態について、添付図面を参照して詳細に説明する。

【0014】

図面のフローチャートに示されたステップは、一つのセットのコンピュータ実行可能命令であるコンピュータシステムで実行することができる。また、フローチャートには論理的な順序が示されているが、場合によっては、ここで示されているまたは説明されている順序と異なる順序で実行されることができる。

【0015】

ＬＲＰアプリケーションに様々なアプリケーションに依存しないパブリック情報アドバタイズサービスを提供するために、本発明の実施形態は、ＬＲＰに基づいて、ＣＡＭＣ（Ｃｏｍｍｏｎ Ａｔｔｒｉｂｕｔｅｓ Ｍａｎａｇｅｍｅｎｔ Ｃｏｍｐｏｎｅｎｔ、パブリック属性管理コンポーネント）と呼ばれるコンポーネントを提案する。当該コンポーネントはパブリックコンポーネントとして、ブリッジネットワークにおいて、Ｒｅｃｏｒｄ ＬＲＰＤＵ（Ｌｉｎｋ－ｌｏｃａｌ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ、リンクローカル登録プロトコルデータユニット）に基づいて、ＴＬＶ（Ｔｙｐｅ、Ｌｅｎｇｔｈ、Ｖａｌｕｅ、タイプ、長さ、および値）のエンコードフォーマットでさまざまなパブリック情報をアドバタイズし、ＣＡＭＣコンポーネントは他のプロトコル又はコンポーネントに情報アドバタイズサービスを提供する。

【0016】

ブリッジネットワークの各ノードの各ポートにＣＡＭＣが設置され、前記ＣＡＭＣはＬＲＰアプリケーションとＬＲＰとの間に設置される。

【0017】

ブリッジネットワークにおいて、アドバタイズする必要があるパブリック情報が多くて、たとえば、ポート帯域幅の残りの使用可能なリソースは、ＲＡＰより使用され、ＰＣＥ（Ｐａｔｈ Ｃｏｍｐｕｔａｔｉｏｎ Ｅｌｅｍｅｎｔ、パス計算要素）よりパス計算の基礎として使用される。本発明の実施形態は、ＣＡＭＣによってアドバタイズできる様々な情報を示し、以下の表１に示された内容を含むが、これらに限定されない。

【0018】

表1 ＣＡＭＣによってアドバタイズできるパブリック情報のリスト

【0019】

アドバタイズが必要な情報について、ＴＬＶフォーマットでエンコードされ、ＬＲＰＤＵによってキャリーする。ＬＲＰによって定義されたさまざまなＬＲＰＤＵにおいて、Ｒｅｃｏｒｄ ＬＲＰＤＵを利用してＤａｔａ（データ）をキャリーする。Ｒｅｃｏｒｄ ＬＲＰＤＵのカプセル化フォーマットを図１に示し、各Ｒｅｃｏｒｄ ＬＲＰＤＵは０個または複数のＲｅｃｏｒｄをキャリーでき、各Ｒｅｃｏｒｄのエンコードフォーマットを図２に示し、ここで、各Ａｐｐｌｉｃａｔｉｏｎ Ｄａｔａ（アプリケーションデータ）フィールドは、複数のアドバタイズが必要な情報ＴＬＶをキャリーすることに用いられる。各タイプの情報のＴＬＶエンコードフォーマットは、実際のニーズまたは既存の技術に従って選択することができ、これは、本発明の実施形態では繰り返されない。

【0020】

ＣＡＭＣは、複数のＬＲＰアプリケーションにパブリック情報のアドバタイズサービスを提供することができ、これらのＬＲＰアプリケーションは、ぞれぞれ特定の属性情報をアドバタイズすることもできる。ＣＡＭＣ、ＬＲＰ、およびその他の各ＬＲＰアプリケーションプロトコルまたはコンポーネントとの関係概略図を図３に示し、各ＬＲＰアプリケーションのパブリック属性は、ＣＡＭＣによってアドバタイズし（矢印の破線）、ＬＲＰアプリケーションの各自らの特定の属性は、自らによってアドバタイズすることができ（矢印の実線）、たとえば、ＲＡＰのＳＲフィールドの属性はＣＡＭＣプロトコルを使用してアドバタイズすることができるが、ＲＡＰリソース割り当てに関連する属性は自らで定義され、且つＬＲＰプリミティブを呼び出すことによってアドバタイズする。

【0021】

ＣＡＭＣによって定義された内容には次のものが含まれる。
１．各パブリック属性のタイプと値、および関連するセマンティクスは、アドバタイズが必要なさまざまな情報を意味する。たとえば、属性タイプは「キュー伝送選択アルゴリズム」であり、属性値は１であり、これは、クレジットベースシェイパー（Ｃｒｅｄｉｔ－Ｂａｓｅｄ Ｓｈａｐｅｒ、ＣＢＳ）に基づくアルゴリズムを意味し、
２．Ｒｅｃｏｒｄ ＬＲＰＤＵでさまざまな属性タイプと値をキャリーするために使用されるエンコードフォーマットであり、
３．ＣＡＭＣコンポーネント固有のａｐｐＩＤであり、
４．ＣＡＭＣに加えて、ＲＡＰ、ＰＣＥなどの他のＬＲＰアプリケーションまたはコンポーネントに３つのプリミティブを提供し、これらは、情報アドバタイズサービスプリミティブ、情報クエリサービスプリミティブ、および情報報告プリミティブである。ＲＡＰなどのアプリケーションは、情報クエリサービスプリミティブを呼び出して、本ポートの特定の情報がアドバタイズされているかどうか、および他のポートによってアドバタイズされる情報をクエリできる。同じポート上の複数のアプリケーションが表１にリストされている同じ情報をアドバタイズする必要がある場合、一回のみでアドバタイズすれば結構であり、リソースの浪費を避ける。

【0022】

図４に示すように、本発明の実施形態に係るブリッジネットワーク情報のアドバタイズ方法は、以下のステップを含む。

【0023】

ステップ１０１：ＣＡＭＣは、ＬＲＰアプリケーションによってアドバタイズされた第１パブリック属性情報を受信し、前記第１パブリック属性情報をＬＲＰのデータベースに書き込む。

【0024】

ここで、前記第１パブリック属性情報は、前記ＬＲＰアプリケーションがアドバタイズする必要があるパブリック属性情報である。

【0025】

図５に示すように、一つの実施形態において、前記ステップ１０１は、以下のステップを含む。

【0026】

ステップ２０１：前記ＣＡＭＣは、ＬＲＰアプリケーションがＣＡＭＣ情報アドバタイズサービスプリミティブを介してアドバタイズされた第１パブリック属性情報を受信する。

【0027】

ステップ２０２：前記ＣＡＭＣは、前記第１パブリック属性情報をＴＬＶフォーマットにカプセル化し、ＬＲＰ Ｗｒｉｔｅ Ｒｅｃｏｒｄ Ｒｅｑｕｅｓｔ（書き込み記録要求）プリミティブを呼び出して、前記第１パブリック属性情報をＬＲＰのＡｐｐｌｉｃａｎｔ（申請）データベースに書き込む。

【0028】

ここで、カプセル化するとき、前記第１パブリック属性情報と本ポートの情報とを一緒にカプセル化し、ＬＲＰのＡｐｐｌｉｃａｎｔデータベースに送信する。

【0029】

ステップ１０２：前記ＣＡＭＣは、ＬＲＰのデータベースによって報告された第２パブリック属性情報を受信し、前記第２パブリック属性情報をＬＲＰアプリケーションに報告する。

【0030】

ここで、前記第２パブリック属性情報は、ＬＲＰのデータベースが変更されたときに同期する必要があるパブリック属性情報である。

【0031】

図６に示すように、一つの実施形態において、ステップ１０２は、以下のステップを含む。

【0032】

ステップ３０１：前記ＣＡＭＣは、ＬＲＰのＲｅｇｉｓｔｒａｒデータベースがＬＲＰ Ｒｅｃｏｒｄ Ｗｒｉｔｅ Ｉｎｄｉｃａｔｉｏｎ（記録書き込み表示）プリミティブを介して報告されたＴＬＶカプセル化フォーマットの第２パブリック属性情報を受信する。

【0033】

ステップ３０２：前記ＣＡＭＣは、ＴＬＶカプセル化フォーマットの第２パブリック属性情報をカプセル化解除し、前記第２パブリック属性情報を、ＣＡＭＣ情報報告プリミティブを介して、本ポートのすべてのＬＲＰアプリケーションに報告する。

【0034】

なお、前記ステップ１０１と１０２の実行は順序がないことに留意されたい。本実施形態は、一つのポートのＣＡＭＣに対して説明する。実際の応用において、ＬＲＰアプリケーションが本ポートのＣＡＭＣを介してパブリック属性情報をＬＲＰのＡｐｐｌｉｃａｎｔデータベースに書き込むとき、ＬＲＰは、Ａｐｐｌｉｃａｎｔデータベースが変更されたＲｅｃｏｒｄを隣接のＲｅｇｉｓｔｒａｒデータベースに同期させる。当該隣接Ｒｅｇｉｓｔｒａｒデータベースが対応するＣＡＭＣは、当該パブリック属性情報を当該ＣＡＭＣが対応するすべてのＬＲＰアプリケーションに報告する。

【0035】

図７に示すように、一つの実施形態において、ステップ１０２の後、前記方法は以下のステップをさらに含む。

【0036】

ステップ１０３：前記ＣＡＭＣは、前記第２パブリック属性情報を拡散する必要があると確定し、前記第２パブリック属性情報を本ノードの他のポートのＣＡＭＣに拡散する。

【0037】

ここで、ＣＰＦＴ（ＣＡＭＣ ａｔｔｒｉｂｕｔｅ Ｐｒｏｐａｇａｔｉｏｎ Ｆｌａｇ Ｔａｂｌｅ、属性拡散フラグテーブル）をクエリすることにより、前記第２パブリック属性情報を拡散する必要があると確定できる。

【0038】

前記ＣＰＦＴは前記ＣＡＭＣに位置され、ＬＲＰアプリケーションで配置を担当し、又はユーザーより静的に配置することもできる。

【0039】

図８に示すように、一つの実施形態において、前記方法は以下のステップをさらに含む。

【0040】

ステップ４０１：前記ＣＡＭＣは、本ノードの他のポートのＣＡＭＣによって拡散された第３パブリック属性情報を受信し、前記第３パブリック属性情報は、拡散する必要があるパブリック属性情報である。

【0041】

ここで、このステップは、ステップ１０３に対応し、他のポートから本ポートに拡散されたパブリック属性情報である。

【0042】

ステップ４０２：前記ＣＡＭＣは、前記第３パブリック属性情報をＬＲＰのデータベースに書き込む。

【0043】

ここで、ステップ４０２の後、ローカルのＬＲＰのデータベースが更新されると、前記ＣＡＭＣは、前記ＬＲＰデータベースより送信した第３パブリック属性情報を受信し、前記ＣＡＭＣは、本ポートのすべてのＬＲＰアプリケーションに前記第３パブリック属性情報を送信する。

【0044】

図９に示すように、一つの実施形態において、前記方法は以下のステップをさらに含む。

【0045】

ステップ５０１：前記ＣＡＭＣは、ＬＲＰアプリケーションによって送信されたクエリ要求を受信し、前記クエリ要求は、指定された属性情報をクエリするために使用される。

【0046】

ここで、一つの実施形態において、前記ＣＡＭＣは、前記ＬＲＰアプリケーションのＣＡＭＣクエリサービスプリミティブを介して送信されたクエリ要求を受信する。

【0047】

ステップ５０２：前記ＣＡＭＣはＬＲＰデータベースをクエリし、クエリ結果を前記ＬＲＰアプリケーションに返す。

【0048】

一つの実施形態において、前記ステップ５０２は、以下のステップを含む。

【0049】

前記ＣＡＭＣは、ＬＲＰ Ｄａｔａｂａｓｅ Ｒｅｑｕｅｓｔクエリプリミティブを呼び出して、ＬＲＰデータベースをクエリし、前記属性情報を取得し、前記ＣＡＭＣは、前記属性情報とスクリーニングポリシーに従ってクエリ結果を決定し、前記クエリ結果を前記ＬＲＰアプリケーションに返す。

【0050】

ＬＲＰアプリケーションにクエリサービスを提供する場合、ＣＡＭＣはクッションとして、ＬＲＰはＬＲＰ Ｄａｔａｂａｓｅ Ｒｅｑｕｅｓｔプリミティブを提供する必要があり、このプリミティブは、Ｒｅｃｏｒｄ ＩＤ、ｃｈｅｃｋｓｕｍ、ｓｅｑｕｅｎｃｅＮｕｍなどの内容を取り除き、データベースＲｅｃｏｒｄのＤａｔａ内容を返し、全体的なクエリシーケンス図を図１０に示し、プロセスは次のとおりである。

【0051】

ステップ６０１：ＬＲＰアプリケーションは、ＣＡＭＣクエリサービスプリミティブを呼び出して、ある属性情報をクエリし、本ポートが当該属性をアドバタイズしたかどうか、および他のポートから本ポートにアドバタイズした当該属性情報を含む。

【0052】

ステップ６０２：ＣＡＭＣは、ＬＲＰ Ｄａｔａｂａｓｅ Ｒｅｑｕｅｓｔクエリプリミティブを呼び出して、ＬＲＰデータベースをクエリする。

【0053】

ステップ６０３：ＬＲＰデータベースは、データベースクエリ結果、すなわち、当該属性情報をキャリーするＲｅｃｏｒｄ Ａｐｐｌｉｃａｔｉｏｎ Ｄａｔａ情報を返す。

【0054】

ステップ６０４：ＣＡＭＣは、当該属性情報を抽出し、特定のポリシーに従って属性情報をスクリーニングおよび統合する（例えば、上位層ＬＲＰアプリケーション要件に従って特定のノードまたはポートの属性、またはフィールド全体内のすべてのノードの属性、または本ポートが当該属性をアドバタイズされたかどうかをマークすることなどをスクリーニングする）。

【0055】

ステップ６０５：ＣＡＭＣはクエリ結果を上位層のＬＲＰアプリケーションに返す。

【0056】

図１１に示すように、本発明の実施形態のＣＡＭＣは、以下のコンポーネントを含み、各コンポーネントの機能および相互協力プロセスは以下のとおりである。

【0057】

ｐｅｒ－ＰｏｒｔａｌコンポーネントであるＣＡＤＥ（ＣＡＭＣ Ａｔｔｒｉｂｕｔｅ Ｄｅｃｌａｒａｔｉｏｎ Ｅｎｔｉｔｙ、属性宣言コンポーネント）７１は、当該Ｐｏｒｔａｌでのパブリック属性宣言イベントを処理し、ｂｒｉｄｇｅ（橋）にＣＰＰＥ７４を介して他のポートから登録された属性によってトリガーされ（図の丸７）、またはＲＡＰなどのアプリケーションによって発行されたＣＡＭＣサービス要求プリミティブによってトリガーされ（図の丸１）、ＣＡＤＥの出力はＣＣＤＥ（図の丸２）７３に渡される。

【0058】

ｐｅｒ－ＰｏｒｔａｌコンポーネントであるＣＡＲＥ（ＣＡＭＣ Ａｔｔｒｉｂｕｔｅ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｅｎｔｉｔｙ、属性登録コンポーネント）７２は、当該Ｐｏｒｔａｌで発生するパブリック属性登録イベントを処理し、ＣＣＤＥ７３からの属性を受信することによってトリガーされる（図の丸５）。ＣＡＲＥ７２の出力はＲＡＰなどのアプリケーションに送信され（図の丸８）、ＣＰＦＴをクエリして（図の丸９）、ＣＰＰＥ７４を介して拡散する必要があるかどうかが判断する（図の丸６）。

【0059】

ｐｅｒ－ＰｏｒｔａｌコンポーネントであるＣＣＤＥ（ＣＡＭＣ Ｃｏｄｉｎｇ ａｎｄ Ｄｅｃｏｄｉｎｇ Ｅｎｔｉｔｙ、エンコーディングとデコーディングコンポーネント）７３は、ＣＡＭＣ属性を相応的にＴＬＶフォーマットでエンコードしてＬＲＰに送信するか（図の丸３）、ＬＲＰから情報を受信してＴＬＶデコーディングを実行する（図の丸４）。

【0060】

ｐｅｒ－ＢｒｉｄｇｅコンポーネントであるＣＰＰＥ（ＣＡＭＣ ａｔｔｒｉｂｕｔｅ Ｐｒｏｐａｇａｔｉｏｎ ａｎｄ Ｐｒｏｃｅｓｓｉｎｇ Ｅｎｔｉｔｙ、属性伝播コンポーネント）７４は、ｐｅｒ－Ｐｏｒａｌ ＣＡＭＣコンポーネントの間で属性宣言を伝播し、各ノードのすべてのポートは一つのＣＰＰＥ７４を共有する。

【0061】

ＣＰＦＴ（ＣＡＭＣ ａｔｔｒｉｂｕｔｅ Ｐｒｏｐａｇａｔｉｏｎ Ｆｌａｇ Ｔａｂｌｅ、属性拡散フラグテーブル）７５は、ポートより受信した属性登録宣言がＣＰＰＥ７４を介して他のポートに拡散する必要があるかどうかを示し、テーブルは、ＬＲＰアプリケーションによって配置を担当するか、ユーザーによって静的に配置するかの２つの方法で生成できる。

【0062】

本発明の実施形態において、前記ＣＡＤＥ７１は、ＬＲＰアプリケーションによってアドバタイズされた第１パブリック属性情報を受信することに用いられ、それを前記ＣＣＤＥ７３に送信する。

【0063】

前記ＣＣＤＥ７３は、前記第１パブリック属性情報をＴＬＶフォーマットにカプセル化し、前記ＴＬＶフォーマットにカプセル化された第１パブリック属性情報をＬＲＰデータベースに書き込み、および、ＬＲＰのデータベースによって報告されたＴＬＶカプセル化フォーマットの第２パブリック属性情報を受信し、前記ＴＬＶカプセル化フォーマットの第２パブリック属性情報をカプセル化解除して、前記ＣＡＲＥ７２に送信するように設置される。

【0064】

前記ＣＡＲＥ７２は、前記第２パブリック属性情報をＬＲＰアプリケーションに報告するように設置される。

【0065】

ここで、前記第１パブリック属性情報は、前記ＬＲＰアプリケーションがアドバタイズする必要があるパブリック属性情報であり、前記第２パブリック属性情報は、前記ＬＲＰのデータベースが変更されたときに同期する必要があるパブリック属性情報である。

【0066】

一つの実施形態において、前記ＣＡＲＥ７２は、ＣＰＦＴ７５をクエリすることによって前記第２パブリック属性情報を拡散する必要があることを決定すると、前記第２パブリック属性情報を前記ＣＰＰＥ７４に送信するようにさらに設置される。

【0067】

前記ＣＰＰＥ７４は、前記第２パブリック属性情報を本ノードの他のポートのＣＡＭＣにおけるＣＡＤＥに拡散するように設置される。

【0068】

一つの実施形態において、前記ＣＡＤＥ７１は、前記ＣＰＰＥ７４によって拡散された第３パブリック属性情報を受信し、前記第３パブリック属性情報を前記ＣＣＤＥ７３に送信するようにさらに設置され、前記第３パブリック属性情報は、拡散する必要があるパブリック属性情報である。

【0069】

前記ＣＣＤＥ７３は、前記第３パブリック属性情報をＴＬＶフォーマットにカプセル化し、前記ＴＬＶフォーマットにカプセル化された第３パブリック属性情報をＬＲＰのデータベースに書き込むように設置される。

【0070】

一つの実施形態において、前記ＣＡＤＥ７１は、ＬＲＰアプリケーションによって送信されたクエリ要求を受信し、前記クエリ要求をＣＣＤＥ７３に送信するようにさらに設置され、前記クエリ要求は、指定された属性情報をクエリするために使用される。

【0071】

前記ＣＣＤＥ７３は、前記クエリ要求をＴＬＶフォーマットにカプセル化し、ＬＲＰデータベースをクエリし、前記属性情報を取得して、前記ＣＡＲＥ７２に送信するようにさらに設置される。

【0072】

前記ＣＡＲＥ７２は、前記属性情報およびスクリーニングポリシーに従ってクエリ結果を決定し、前記クエリ結果を前記ＬＲＰアプリケーションに返すように設置される。

【0073】

図１２に示すように、ＬＲＰアプリケーションがＣＡＭＣを介した属性情報をアドバタイズするプロセスは以下のステップを含む。

【0074】

ステップ８０１、ＬＲＰアプリケーションは、ＣＡＭＣ情報アドバタイズサービスプリミティブを呼び出すことによって属性情報をアドバタイズする。

【0075】

ステップ８０２、ＣＡＭＣ内部における情報アドバタイズを担当するコンポーネントであるＣＡＤＥは、要求情報を本ポート情報と一緒にＣＣＤＥコンポーネントに送信する。

【0076】

ステップ８０３、ＣＣＤＥコンポーネントは、情報をＴＬＶフォーマットにカプセル化し、ＬＲＰ Ｗｒｉｔｅ Ｒｅｃｏｒｄ Ｒｅｑｕｅｓｔプリミティブを呼び出して、属性をＡｐｐｌｉｃａｎｔデータベースに書き込む。

【0077】

ステップ８０４、ＬＲＰは、Ａｐｐｌｉｃａｎｔデータベースが変更されたＲｅｃｏｒｄを隣接するＲｅｇｉｓｔｒａｒデータベースに同期させる。

【0078】

ステップ８０５、隣接するＲｅｇｉｓｔｒａｒデータベースの変更は、ＬＲＰ Ｒｅｃｏｒｄ Ｗｒｉｔｅ Ｉｎｄｉｃａｔｉｏｎプリミティブを介して隣接するＣＣＤＥコンポーネントに報告する。

【0079】

ステップ８０６、隣接するＣＣＤＥコンポーネントは、受信された情報をＴＬＶカプセル化解除し、属性情報を取得し、それをＣＡＲＥコンポーネントに提出し、ＣＡＲＥコンポーネントは、ＣＡＭＣ情報報告プリミティブを介して、属性情報をすべてのＬＲＰアプリケーションに報告する。

【0080】

ステップ８０７、他のポートがあるかどうかを判断し、ない場合はプロセスを終了し、ある場合はステップ８０８に進む。

【0081】

ステップ８０８、ＣＡＲＥコンポーネントは、当該属性を拡散する必要があるかどうかをクエリするためにＣＰＦＴテーブルにクエリする。それを拡散する必要がある場合、属性報告要求をＣＰＰＥコンポーネントに送信し、ＣＰＰＥコンポーネントは、他のポートＣＡＭＣのＣＡＤＥコンポーネントに当該属性をアドバタイズすると要求し、ステップ８０１に戻って実行する。

【0082】

本発明の実施形態により、パブリック属性情報は、ＣＡＭＣを介して均一に送信および拡散される。一方で、複数のＬＲＰアプリケーションは、追加の定義なしにパブリック属性情報を共有することができる。他方で、同じポート上の複数のＬＲＰアプリケーションが、同じパブリック属性情報をアドバタイズする場合、アドバタイズする必要があるのは1回だけなので、リソースの浪費を回避できる。

【0083】

以下、いくつの応用例を通じて説明する。

【0084】

応用例１
この応用例は、図１３に示すように、ＣＡＭＣを使用して情報をアドバタイズするプロセスを示す。ＳｙｓｔｅｍＡとＳｙｓｔｅｍＢの２つのデバイスがあると仮定し、ＡのＰｏｒｔ１とＢのＰｏｒｔ１は、コンポーネントＣＡＭＣに対してＰｏｒｔａｌ関連を設立し、ＳｙｓｔｅｍＢには２つのＰｏｒｔがあり、もう１つのＰｏｒｔはＰｏｒｔ２であり、ＲＡＰは、ＣＡＭＣに「ＳｙｓｔｅｍＡのポートＰｏｒｔ１の残りの利用可能な帯域幅」情報をアドバタイズするように要求し、ＳｙｓｔｅｍＢ Ｐｏｒｔ１のＣＰＦＴテーブルは、この情報を拡散する必要があるように配置されると、アドバタイズプロセスは次のとおりである。

【0085】

ステップ９０１、ＳｙｓｔｅｍＡ Ｐｏｒｔ１上のアプリケーションは、ＣＡＭＣプリミティブを呼び出して、「残りの利用可能な帯域幅」をアドバタイズする。

【0086】

ステップ９０２、ＳｙｓｔｅｍＡ Ｐｏｒｔ１上のＣＡＤＥコンポーネントは、「残りの利用可能な帯域幅」アドバタイズ要求プリミティブを受信し、アドバタイズ属性は、残りの利用可能な帯域幅の値である。

【0087】

ステップ９０３、ＣＡＤＥコンポーネントは、要求をＣＣＤＥコンポーネントに送信し、要求の内容は、＜ＳｙｓｔｅｍＡ、Ｐｏｒｔ１、アドバタイズタイプ（タイプ００１が残りの利用可能な帯域幅を表すと仮定する）、値＞であり、ＣＣＤＥは、要求をＴＬＶフォーマットにカプセル化し、ＬＲＰ Ｗｒｉｔｅ Ｒｅｃｏｒｄ Ｒｅｑｕｅｓｔプリミティブを呼び出して、ＴＬＶをＳｙｓｔｅｍＡ Ｐｏｒｔ１が対応するＰｏｒｔａｌのＡｐｐｌｉｃａｎｔデータベースのＲｅｃｏｒｄに書き込む。

【0088】

ステップ９０４、ＬＲＰは、ＳｙｓｔｅｍＡ Ｐｏｒｔ１データベースＲｅｃｏｒｄの変更がＲｅｃｏｒｄ ＬＲＰＤＵを介してＳｙｓｔｅｍＢ ｐｏｒｔ１ Ｒｅｇｉｓｔｒａｒデータベースに同期させ、次いで、ＬＲＰ Ｒｅｃｏｒｄ Ｗｒｉｔｅ Ｉｎｄｉｃａｔｉｏｎプリミティブを介してＳｙｓｔｅｍＢ Ｐｏｒｔ１ ＣＣＤＥコンポーネントにアドバタイズする。

【0089】

ステップ９０５、ＳｙｓｔｅｍＢ ｐｏｒｔ１のＣＣＤＥコンポーネントは、受信されたＲｅｃｏｒｄに含まれるＴＬＶをカプセル化解除し、それをＣＡＲＥコンポーネントに提出する。

【0090】

ステップ９０６、ＳｙｓｔｅｍＢ Ｐｏｒｔ１のＣＡＲＥコンポーネントは、解析されて取得したＳｙｓｔｅｍＡ Ｐｏｒｔ１の残りの帯域幅の利用可能な値を、情報報告プリミティブを介してＳｙｓｔｅｍＢ上のＲＡＰアプリケーションおよび他のＬＲＰアプリケーションにアドバタイズする。

【0091】

ステップ９０７、ＳｙｓｔｅｍＢ Ｐｏｒｔ１のＣＡＲＥコンポーネントは、「ＳｙｓｔｅｍＡ ｐｏｒｔ１の残りの利用可能な帯域幅」を受信し、他のポートがあるかどうかを判断し、ない場合、プロセスを終了し、ある場合、ステップ９０８に進む。

【0092】

ステップ９０８、ＣＡＲＥコンポーネントは、ＣＰＦＴテーブルをクエリし、拡散する必要があることを発見し、ＣＰＰＥコンポーネントを介してＳｙｓｔｅｍＢ Ｐｏｒｔ２のＣＡＤＥコンポーネントにアドバタイズし、ＳｙｓｔｅｍＢ Ｐｏｒｔ２ ＣＡＤＥのさらなるアドバタイズプロセスは、ステップ９０２から９０７と同じである。

【0093】

応用例２
この応用例は、図１４に示すように、複数のアプリケーションがＣＡＭＣを介して同じ情報をアドバタイズする場合のワークフローを示す。ＲＡＰとＰＣＥが共にＣＡＭＣを介してポートＳＲ ｃｌａｓｓ情報をアドバタイズする必要があると仮定すると、この属性がこの前にアドバタイズされていないと仮定すると、ワークフローは次のようになる。

【0094】

ステップ１００１、ＲＡＰは、ＣＡＭＣによって提供されたクエリサービスプリミティブを呼び出すことによって、本ポートのＳＲ ｃｌａｓｓ情報がアドバタイズされたかどうかをクエリする（アドバタイズされた属性は、ＰｏｒｔａｌのＡｐｐｌｉｃａｎｔベースに記録される）。

【0095】

ステップ１００２、ＣＡＭＣクエリサービスプリミティブは、当該ＳＲ ｃｌａｓｓ情報が他のアプリケーションによってアドバタイズされたかどうかを判断し、ＮＯであると、ステップ１００３に進み、ＹＥＳであると、ステップ１００４に進む。

【0096】

ステップ１００３：ＣＡＭＣは、本ポートの情報がアドバタイズされていないことを返すと、ＲＡＰは、応用例１のプロセスを採用して、本ポートのＳＲ ｃｌａｓｓ情報をアドバタイズし、他のデバイスのポートも同じ方法を採用して、各ポートのＳＲ ｃｌａｓｓ情報を本ポートにアドバタイズする。

【0097】

ステップ１００４、ＲＡＰは、ＣＡＭＣによって提供されたクエリサービスプリミティブを使用して、関連するＰｏｒｔａｌに記録されたＳＲ ｃｌａｓｓ情報（全部または一部のポートのＳＲ ｃｌａｓｓ情報であることができる）をクエリし、ＳＲフィールドを設立する（次に、ＳＲフィールドに基づいて、リソースを割り当てることができる）。

【0098】

ＰＣＥは、本ポートのＳＲ ｃｌａｓｓ情報をアドバタイズするために、まず、ＣＡＭＣクエリサービスプリミティブを呼び出して、返されたデータには、本ポート属性がアドバタイズされたことを示すと、本ポートのＳＲ ｃｌａｓｓ情報を繰り返しアドバタイズする必要がなく、返された出力には、ネットワークでアドバタイズされた各ポートのＳＲ ｃｌａｓｓ情報が含まれるので、ＳＲフィールドも設立できる（後続のルート計算はＳＲフィールド情報に基づいて実行できる）。

【0099】

以下、図１５（ａ）に示すように、ＳＲフィールド情報を例としてＴＬＶエンコードフォーマットを説明する。

【0100】

Ｔｙｐｅフィールド自体は２バイトを占め、Ｌｅｎｇｔｈ自体は２バイトを占め、Ｌｅｎｇｔｈフィールドの値は、Ｄａｔａ Ｖａｌｕｅフィールドが占めるバイト数を指定する。アドバタイズする必要があるＳＲフィールド情報、Ｔｙｐｅ値、および占めるバイト数は以下のとおりであり、各ＴＬＶフォーマットを図１５（ｂ）に示す。

【0101】

ＳＲｃｌａｓｓＩｄ：Ｔｙｐｅ＝１、Ｌｅｎｇｔｈ＝１バイト
ＳＲｃｌａｓｓＰｒｉｏｒｉｔｙ：Ｔｙｐｅ＝２、Ｌｅｎｇｔｈ＝１バイト
ＴｒａｎｓｍｉｓｓｉｏｎＳｅｌｅｃｔｉｏｉｎ：Ｔｙｐｅ＝３、Ｌｅｎｇｔｈ＝１バイト
ＣｌａｓｓＭｅａｓｕｒｅＩｎｔｅｒｖａｌ：Ｔｙｐｅ＝４、Ｌｅｎｇｔｈ＝１バイト
ＳＲＣｌａｓｓＭａｘＦｒａｍｅＳｉｚｅ：Ｔｙｐｅ＝５、Ｌｅｎｇｔｈ＝２バイト
ＳＲＣｌａｓｓＴａｒｇｅｔＭａｘＬａｔｅｎｃｙ：Ｔｙｐｅ＝６、Ｌｅｎｇｔｈ＝４バイト

【0102】

図２に示すように、Ａｐｐｌｉｃａｔｉｏｎ Ｄａｔａフィールドよりキャリーできるデータの最大サイズは６５５２０バイトであるため、１つのＲｅｃｏｒｄが複数のＴＬＶをキャリーすることができ、たとえば、ＳＲフィールド情報をアドバタイズするＴＬＶはすべて１つのＲｅｃｏｒｄでキャリーすることができる。本発明の実施形態におけるＣＡＭＣのＣＣＤＥコンポーネントは、各パブリック属性ＴＬＶのエンコードおよびデコーディングを担当する。

【0103】

本発明の実施形態は、メモリ、プロセッサ、およびメモリに格納され、且つプロセッサ上で実行することができるコンピュータプログラムを含むブリッジネットワーク情報アドバタイズデバイスをさらに提供し、前記プロセッサは、前記プログラムを実行するときに、前記ブリッジネットワーク情報のアドバタイズ方法を実現する。

【0104】

本発明の実施形態は、コンピュータ実行可能命令を格納するコンピュータ可読記憶媒体を提供し、前記コンピュータ実行可能命令は、前記ブリッジネットワーク情報のアドバタイズ方法を実行するために使用される。

【0105】

本実施形態において、前述記憶媒体は、Ｕディスク、読み取り専用メモリ（ＲＯＭ、Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、モバイルハードディスク、磁気ディスク、または光ディスクなどプログラムコードを保存できるさまざまなメディアを含むが、これらに限定されない。

【0106】

当業者は、上記に開示された方法におけるすべてまたは一部のステップ、システム、装置における機能モジュール／ユニットが、ソフトウェア、ファームウェア、ハードウェア、およびそれらの適切な組み合わせによって実施することができることを理解することができる。ハードウェアの実施形態において、上記の説明で述べた機能モジュール／ユニットの間の分割は、必ずしも物理コンポーネントの分割に対応するわけではない。たとえば、一つの物理コンポーネントが複数の機能を持っている場合や、一つの機能またはステップが複数の物理コンポーネントより協力して実行する場合がある。一部またはすべてのコンポーネントは、デジタルシグナルプロセッサまたはマイクロプロセッサなどのプロセッサによって実行されるソフトウェアによって、またはハードウェアによって、または特定用途向け集積回路などの集積回路によって実行されることができる。このようなソフトウェアは、コンピュータ可読媒体上で配布することができ、コンピュータ可読媒体は、コンピュータ記憶媒体（または非一時的媒体）および通信媒体（または一時的媒体）を含むことができる。当業者によく知られているように、コンピュータ記憶媒体という用語は、情報（コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなど）を格納するための任意の方法または技術で実施される揮発性および不揮発性、取り外し可能、および取り外し不可能なメディアを含む。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、希望の情報を保存するために用いられ、コンピューターからアクセスできる任意の媒体を含むが、これらに限定されない。さらに、当業者によく知られているように、通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波、または他の伝送メカニズムなどの変調データ信号における他のデータを含み、かつあらゆる情報配信媒体を含むことができる。

【0107】

産業上の利用可能性
本発明の実施形態において、ブリッジネットワークの各ノードの各ポートにＣＡＭＣが設置され、前記ＣＡＭＣは、ＬＲＰアプリケーションとＬＲＰとの間に設置され、ＣＡＭＣは、ＬＲＰアプリケーションによってアドバタイズされた第１パブリック属性情報を受信し、前記第１パブリック属性情報をＬＲＰのデータベースに書き込み、および前記ＣＡＭＣはＬＲＰのデータベースによって報告された第２パブリック属性情報を受信し、前記第２パブリック属性情報をＬＲＰアプリケーションに報告する。ここで、前記第１パブリック属性情報は、前記ＬＲＰアプリケーションがアドバタイズする必要があるパブリック属性情報であり、前記第２パブリック属性情報は、前記ＬＲＰのデータベースが変更されたときに同期する必要があるパブリック属性情報である。本発明の実施形態によって、パブリック属性情報は、ＣＡＭＣを介して均一に伝送および拡散し、一方で、複数のＬＲＰアプリケーションは、追加の定義なしにパブリック属性情報を共有することができ、他方で、同じポート上の複数のＬＲＰアプリケーションは、同じパブリック属性情報をアドバタイズする必要がある場合、アドバタイズする必要があるのは１回だけなので、リソースの浪費を回避できる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】