知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2025-02-06
(54)【発明の名称】転送テーブルの生成方法及び装置、記憶媒体、電子装置
(51)【国際特許分類】
H04L 49/201 20220101AFI20250130BHJP
H04L 45/16 20220101ALI20250130BHJP
【ＦＩ】
H04L49/201
H04L45/16
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024546480
(86)(22)【出願日】2023-02-15
(85)【翻訳文提出日】2024-08-06
(86)【国際出願番号】 CN2023076262
(87)【国際公開番号】W WO2023173989
(87)【国際公開日】2023-09-21
(31)【優先権主張番号】202210259155.1
(32)【優先日】2022-03-16
(33)【優先権主張国・地域又は機関】CN
(81)【指定国・地域】
(71)【出願人】
【識別番号】511151662
【氏名又は名称】中興通訊股▲ふん▼有限公司
【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ
【住所又は居所原語表記】ＺＴＥ Ｐｌａｚａ，Ｋｅｊｉ Ｒｏａｄ Ｓｏｕｔｈ，Ｈｉ－Ｔｅｃｈ Ｉｎｄｕｓｔｒｉａｌ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７ Ｃｈｉｎａ
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】張 征
(72)【発明者】
【氏名】徐 本 崇
【テーマコード（参考）】
5K030
【Ｆターム（参考）】
5K030GA06
5K030KA05
5K030KX28
5K030LD04
(57)【要約】
本発明の実施例は、転送テーブルの生成方法及び装置、記憶媒体、電子装置を提供し、該方法は、受信された第１通知メッセージに基づいて目標転送テーブルを生成するとき、前記目標転送テーブルに既に存在したビット転送ルータ識別子ＢＦＲ－ＩＤに第１ＢＦＲ－ＩＤと同じ第２ＢＦＲ－ＩＤが存在するか否かを判定するステップであって、前記第１通知メッセージは、第１ＢＦＥＲの前記第１ＢＦＲ－ＩＤを通知するものであるステップと、存在すると決定した場合、前記第１ＢＦＲ－ＩＤに対応する第１ビット転送ルータプレフィックスＢＦＲ－Ｐｒｅｆｉｘ及び前記第２ＢＦＲ－ＩＤに対応する第２ＢＦＲ－Ｐｒｅｆｉｘから目標ＢＦＲ－Ｐｒｅｆｉｘを決定するステップと、前記目標ＢＦＲ－Ｐｒｅｆｉｘに基づいて前記目標転送テーブルを生成するステップと、を含む。本発明の実施例によれば、関連技術に存在する、通知量が大きすぎることによるネットワーク帯域幅の不必要な占有、デバイスの負荷過大及びパケットロスの課題を解決する。
【特許請求の範囲】
【請求項1】
受信された第１通知メッセージに基づいて目標転送テーブルを生成するとき、前記目標転送テーブルに既に存在したビット転送ルータ識別子ＢＦＲ－ＩＤに第１ＢＦＲ－ＩＤと同じ第２ＢＦＲ－ＩＤが存在するか否かを判定するステップであって、前記第１通知メッセージは、第１ＢＦＥＲの前記第１ＢＦＲ－ＩＤを通知するものであるステップと、存在すると決定した場合、前記第１ＢＦＲ－ＩＤに対応する第１ビット転送ルータプレフィックスＢＦＲ－Ｐｒｅｆｉｘ及び前記第２ＢＦＲ－ＩＤに対応する第２ＢＦＲ－Ｐｒｅｆｉｘから目標ＢＦＲ－Ｐｒｅｆｉｘを決定するステップと、
前記目標ＢＦＲ－Ｐｒｅｆｉｘに基づいて前記目標転送テーブルを生成するステップと、を含む、転送テーブルの生成方法。
【請求項2】
前記第１ＢＦＲ－ＩＤに対応する第１ビット転送ルータプレフィックスＢＦＲ－Ｐｒｅｆｉｘ及び前記第２ＢＦＲ－ＩＤに対応する第２ＢＦＲ－Ｐｒｅｆｉｘから目標ＢＦＲ－Ｐｒｅｆｉｘを決定するステップは、前記第１ＢＦＲ－Ｐｒｅｆｉｘに含まれる第１コンテンツと、前記第２ＢＦＲ－Ｐｒｅｆｉｘに含まれる第２コンテンツとを比較するステップと、
前記第１コンテンツが前記第２コンテンツよりも詳細であると決定した場合、前記第１ＢＦＲ－Ｐｒｅｆｉｘを前記目標ＢＦＲ－Ｐｒｅｆｉｘとして決定するステップと、
前記第２コンテンツが前記第１コンテンツよりも詳細であると決定した場合、前記第２ＢＦＲ－Ｐｒｅｆｉｘを前記目標ＢＦＲ－Ｐｒｅｆｉｘとして決定するステップと、を含む、請求項１に記載の方法。
【請求項3】
前記第１ＢＦＲ－ＩＤに対応する第１ビット転送ルータプレフィックスＢＦＲ－Ｐｒｅｆｉｘ及び前記第２ＢＦＲ－ＩＤに対応する第２ＢＦＲ－Ｐｒｅｆｉｘから目標ＢＦＲ－Ｐｒｅｆｉｘを決定するステップは、前記第１ＢＦＲ－Ｐｒｅｆｉｘの第１属性情報と、前記第２ＢＦＲ－Ｐｒｅｆｉｘの第２属性情報とを比較するステップと、
前記第１属性情報の属性値が前記第２属性情報の属性値よりも優れると決定した場合、前記第１ＢＦＲ－Ｐｒｅｆｉｘを前記目標ＢＦＲ－Ｐｒｅｆｉｘとして決定するステップと、
前記第２属性情報の属性値が前記第１属性情報の属性値よりも優れると決定した場合、前記第２ＢＦＲ－Ｐｒｅｆｉｘを前記目標ＢＦＲ－Ｐｒｅｆｉｘとして決定するステップと、を含む、請求項１に記載の方法。
【請求項4】
前記目標ＢＦＲ－Ｐｒｅｆｉｘに基づいて前記目標転送テーブルを生成するステップは、前記目標ＢＦＲ－Ｐｒｅｆｉｘが前記第１ＢＦＲ－Ｐｒｅｆｉｘである場合、前記目標転送テーブルに既に存在した前記第２ＢＦＲ－ＩＤに対応する前記第２ＢＦＲ－Ｐｒｅｆｉｘ及びネクストホップデバイスを前記第１ＢＦＲ－Ｐｒｅｆｉｘ及び前記第１ＢＦＲ－Ｐｒｅｆｉｘに対応するネクストホップデバイスに更新するステップと、
前記目標ＢＦＲ－Ｐｒｅｆｉｘが前記第２ＢＦＲ－Ｐｒｅｆｉｘである場合、前記転送テーブルに既に存在した前記第２ＢＦＲ－ＩＤ及び前記第２ＢＦＲ－ＩＤに対応する前記第２ＢＦＲ－Ｐｒｅｆｉｘ及びネクストホップデバイスをそのまま維持するステップと、を含む、請求項１に記載の方法。
【請求項5】
前記第１通知メッセージには、前記第１ＢＦＥＲが位置するドメインの第１ドメイン識別子ＤＯＭＡＩＮ－ＩＤ情報がさらに含まれる場合、前記目標転送テーブルに既に存在したＢＦＲ－ＩＤに、第１ＢＦＲ－ＩＤと同じ第２ＢＦＲ－ＩＤが存在すると決定した後、前記方法は、前記第１ＢＦＲ－ＩＤと前記第２ＢＦＲ－ＩＤにそれぞれ対応するＢＦＲ－Ｐｒｅｆｉｘに、ドメイン内からのものがあると決定した場合、エラー処理を実行するステップと、
前記第１ＢＦＲ－ＩＤ及び前記第２ＢＦＲ－ＩＤにそれぞれ対応するＢＦＲ－Ｐｒｅｆｉｘがいずれもドメイン外からのものであると決定した場合、前記第２ＢＦＲ－ＩＤを通知するための第２通知メッセージに含まれている第２ＢＦＥＲが位置するドメインの第２ＤＯＭＡＩＮ－ＩＤ情報を決定し、前記第１ＤＯＭＡＩＮ－ＩＤ情報が前記第２ＤＯＭＡＩＮ－ＩＤ情報と異なる場合、エラー処理を実行するステップと、を含む、請求項１に記載の方法。
【請求項6】
前記第２通知メッセージは、第２ドメイン外ＴＬＶを含み、前記第２ドメイン外ＴＬＶは、前記第２ＢＦＲ－ＩＤ情報を含み、或いは、
前記第２ドメイン外ＴＬＶは、前記第２ＢＦＲ－ＩＤ情報及び前記第２ＢＦＥＲが位置するドメインの第２ＤＯＭＡＩＮ－ＩＤ情報を含む、請求項５に記載の方法。
【請求項7】
前記第２通知メッセージは、前記第２ＢＦＲ－Ｐｒｅｆｉｘを含み、前記第２ドメイン外ＴＬＶは、前記第２ＢＦＲ－Ｐｒｅｆｉｘに従って送信され、前記第２ＢＦＲ－Ｐｒｅｆｉｘは、集約ルーティングプレフィックス、デフォルトルーティングプレフィックス、ボーダーデバイスのＢＦＲ－Ｐｒｅｆｉｘのうちの１つを含む、請求項６に記載の方法。
【請求項8】
前記第１通知メッセージは、第１ドメイン外ＴＬＶを含み、前記第１ドメイン外ＴＬＶは、前記第１ＢＦＲ－ＩＤ情報を含み、或いは、
前記第１ドメイン外ＴＬＶは、前記第１ＢＦＲ－ＩＤ情報及び前記第１ＢＦＥＲが位置するドメインの第１ＤＯＭＡＩＮ－ＩＤ情報を含む、請求項１に記載の方法。
【請求項9】
前記第１通知メッセージは、前記第１ＢＦＲ－Ｐｒｅｆｉｘを含み、前記第１ドメイン外ＴＬＶは、前記第１ＢＦＲ－Ｐｒｅｆｉｘに従って送信され、前記第１ＢＦＲ－Ｐｒｅｆｉｘは、集約ルーティングプレフィックス、デフォルトルーティングプレフィックス、ボーダーデバイスのＢＦＲ－Ｐｒｅｆｉｘのうちの１つを含む、請求項８に記載の方法。
【請求項10】
エラー処理を実行するステップは、アラーム提示を実行して、現在のネットワーク配置に不備があることを提示するステップと、
コントローラにアラーム情報を送信して、前記コントローラの現在のネットワーク配置に不備があることを指示するステップと、のうちの少なくとも１つを含む、請求項５に記載の方法。
【請求項11】
受信された第１通知メッセージに基づいて目標転送テーブルを生成するとき、前記目標転送テーブルに既に存在したビット転送ルータ識別子ＢＦＲ－ＩＤに第１ＢＦＲ－ＩＤと同じ第２ＢＦＲ－ＩＤが存在するか否かを判定する判定モジュールであって、前記第１通知メッセージは、第１ＢＦＥＲの前記第１ＢＦＲ－ＩＤを通知するものである判定モジュールと、存在すると決定した場合、前記第１ＢＦＲ－ＩＤに対応する第１ビット転送ルータプレフィックスＢＦＲ－Ｐｒｅｆｉｘ及び前記第２ＢＦＲ－ＩＤに対応する第２ＢＦＲ－Ｐｒｅｆｉｘから目標ＢＦＲ－Ｐｒｅｆｉｘを決定するように構成される決定モジュールと、
前記目標ＢＦＲ－Ｐｒｅｆｉｘに基づいて、前記目標転送テーブルを生成するように構成される生成モジュールと、を含む、転送テーブルの生成装置。
【請求項12】
コンピュータプログラムが記憶されているコンピュータ読み取り可能な記憶媒体であって、前記コンピュータプログラムは、プロセッサにより実行されると、前記請求項１～１０のいずれか一項に記載の方法のステップを実現する、コンピュータ読み取り可能な記憶媒体。
【請求項13】
メモリと、プロセッサと、前記メモリに記憶され、前記プロセッサ上で実行可能なコンピュータプログラムとを含み、前記プロセッサは、前記コンピュータプログラムを実行する場合に前記請求項１～１０のいずれか一項に記載の方法のステップを実現する、電子装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施例は、通信の分野に関し、具体的には、転送テーブルの生成方法及び装置、記憶媒体、電子装置に関する。
【背景技術】
【0002】
ＢＩＥＲ（Ｂｉｔ Ｉｎｄｅｘｅｄ Ｅｘｐｌｉｃｉｔ Ｒｅｐｌｉｃａｔｉｏｎ、ビットインデックス明示的複製）（ＲＦＣ８２７９）は、新型マルチキャストデータ転送技術であり、該技術は、ネットワークエッジのノードをいずれも１つのＢＩＴビットのみで示し、マルチキャストトラフィックが中間ネットワークで伝送され、１つの特定のＢＩＥＲヘッダを追加的にパッケージし、このパケットヘッダはＢＩＴビット列の形式で該マルチキャストトラフィックの全ての宛先ノードＢＦＥＲ（Ｂｉｔ－Ｆｏｒｗａｒｄｉｎｇ Ｅｇｒｅｓｓ Ｒｏｕｔｅｒ、ビット転送出口ルータ）をマークし、中間ネットワーク転送ノードは、ｂｉｔビットに基づいてルーティングし、トラフィックが全ての宛先ノードに送信できることを保証する。中間ノード転送デバイスは、ルーティングプロトコルによってＢＩＥＲ転送をガイドするためのテーブルを事前に形成し、ＢＩＥＲヘッダをパッケージするトラフィックを受信すると、ＢＩＦＴ（Ｂｉｔ Ｉｎｄｅｘ Ｆｏｒｗａｒｄｉｎｇ Ｔａｂｌｅ、ビットインデックス転送テーブル）に基づいて、宛先ノードへのパケットの転送を完了する。ＢＩＥＲドメインの入口ノードＢＦＩＲ（Ｂｉｔ－Ｆｏｒｗａｒｄｉｎｇ Ｉｎｇｒｅｓｓ Ｒｏｕｔｅｒ、ビット転送入口ルータ）は、ＢＩＥＲドメインに入るマルチキャストトラフィックをＢＩＥＲヘッダのｐａｙｌｏａｄ（ペイロード）としてパッケージし、中間ノードによる転送後、ＢＩＥＲドメインの出口ノードＢＦＥＲは、ＢＩＥＲパケットを受信し、ＢＩＥＲヘッダを除去した後、Ｐａｙｌｏａｄを対応する受信者に転送する。ＢＩＥＲのようなデータプレーン転送技術は、マルチキャストツリーの確立課題がないため、マルチキャストツリーの確立の遅延を解消し、ネットワークにリンク又はノード不備が発生した場合、収束速度がＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ、開放型最短経路優先）又はＩＳＩＳ（Ｉｎｔｅｒｍｅｄｉａｔｅ Ｓｙｓｔｅｍ－ｔｏ－Ｉｎｔｅｒｍｅｄｉａｔｅ Ｓｙｓｔｅｍ、中間システムから中間システムへ）プロトコルと同じであり、元のマルチキャストツリーの再確立に比べて巨大な遅延を低減する。
【0003】
ＢＩＥＲドメインの入口デバイスＢＦＩＲが、あるマルチキャストトラフィックを伝送しようとする場合、どのＢＩＥＲドメインの出口デバイスＢＦＥＲ（Ｂｉｔ－Ｆｏｒｗａｒｄｉｎｇ Ｉｎｇｒｅｓｓ Ｒｏｕｔｅｒ）がこのマルチキャストトラフィックを必要とするかを知る必要があるため、ＢＦＩＲとＢＦＥＲとの間にシグナリングインタラクションが存在する必要があり、これらのインタラクションのシグナリング技術はＢＩＥＲ Ｏｖｅｒｌａｙ技術と呼ばれる。単にＢＩＥＲ転送に用られるＢＦＲ（Ｂｉｔ－Ｆｏｒｗａｒｄｉｎｇ Ｒｏｕｔｅｒ、ビット転送ルータ）中間デバイスは、該マルチキャストトラフィック情報を知る必要がない。
【0004】
ＢＩＥＲ転送テーブルエントリを構築するために、ＯＳＰＦ又はＩＳＩＳなどのプロトコルは、シグナリング拡張によりＢＩＥＲ情報通知をサポートし、ＢＩＥＲドメイン内の全てのノードが他のノードのＢＩＥＲ情報を受信し、これによりＢＩＥＲ転送テーブルエントリを構築し、ＯＳＰＦ又はＩＳＩＳなどの拡張シグナリングがＢＩＥＲ情報インタラクションをサポートするプロトコルは、ＢＩＥＲＵｎｄｅｒｌａｙ技術と呼ばれる。
【0005】
ＢＩＥＲ ｕｎｄｅｒｌａｙ技術は、ＯＳＰＦ、ＩＳＩＳなどのプロトコルを用いて通知する以外に、ＢＧＰ（Ｂｏｒｄｅｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ、ボーダーゲートウェイプロトコル）、ＢＡＢＥＬなどのプロトコルを用いて通知することもできる。
【0006】
関連技術において、ＯＳＰＦ、ＩＳＩＳなどのプロトコルにおいて、拡張によってＢＩＥＲ情報を通知するとき、通知の主なコンテンツは、ルーティングプレフィックス及びＢＦＲ－ＩＤ（ＢＦＲ－Ｉｄｅｎｔｉｆｉｅｒ、ＢＦＲ－識別子）などを含み、例えば、ＯＳＰＦは、ＲＦＣ８４４４の定義に基づいて、ルーティングプレフィックスを通知するとき、ＢＩＥＲ ＳＵＢ－ＴＬＶを追加することにより、ＢＦＲ－ＩＤなどの情報を含む。プロトコルがプレフィックスに基づいてルーティング計算を行った後、ＢＩＥＲ転送テーブルエントリは、両者に基づいて正確に生成される。
【0007】
ＯＳＰＦプロトコルのフラッディングメカニズムにより、ネットワークにおけるデバイスは、他のデバイスからの通知を受信した後、受信されたプレフィックス情報に基づいてルーティング計算を行って、通常転送用のユニキャストルーティングテーブルを生成し、それによりＢＩＥＲ転送用のＢＩＥＲルーティングテーブルを生成する。
【0008】
なお、関連技術においてルーティングテーブルを生成する方式は、ルーティングの漏洩が発生する可能性があり、異なるドメインにおいて完全に相互に学習する必要がないルーティングも各ドメイン内のデバイスによって全て学習されることになるため、大きな通知量が発生し、ネットワーク帯域幅が不必要に占有され、デバイスの負荷も増大する。また、過大な通知量により、パケットロスの課題が発生しやすい。
【0009】
関連技術における上記課題に対して、現在、効果的な解決手段がまだ提案されていない。
【発明の概要】
【発明が解決しようとする課題】
【0010】
本発明の実施例は、少なくとも関連技術に存在する、通知量が大きすぎることによるネットワーク帯域幅の不必要な占有、デバイスの負荷過大及びパケットロスの課題を解決するために、転送テーブルの生成方法及び装置、記憶媒体、電子装置を提供する。
【課題を解決するための手段】
【0011】
本発明の一実施例によれば、受信された第１通知メッセージに基づいて目標転送テーブルを生成するとき、前記目標転送テーブルに既に存在したビット転送ルータ識別子ＢＦＲ－ＩＤに第１ＢＦＲ－ＩＤと同じ第２ＢＦＲ－ＩＤが存在するか否かを判定するステップであって、前記第１通知メッセージは、第１ＢＦＥＲの前記第１ＢＦＲ－ＩＤを通知するものであるステップと、存在すると決定した場合、前記第１ＢＦＲ－ＩＤに対応する第１ビット転送ルータプレフィックスＢＦＲ－Ｐｒｅｆｉｘ及び前記第２ＢＦＲ－ＩＤに対応する第２ＢＦＲ－Ｐｒｅｆｉｘから目標ＢＦＲ－Ｐｒｅｆｉｘを決定するステップと、前記目標ＢＦＲ－Ｐｒｅｆｉｘに基づいて前記目標転送テーブルを生成するステップと、を含む、転送テーブルの生成方法を提供する。
【0012】
本発明の別の実施例によれば、受信された第１通知メッセージに基づいて目標転送テーブルを生成するとき、前記目標転送テーブルに既に存在したビット転送ルータ識別子ＢＦＲ－ＩＤに第１ＢＦＲ－ＩＤと同じ第２ＢＦＲ－ＩＤが存在するか否かを判定する判定モジュールであって、前記第１通知メッセージは、第１ＢＦＥＲの前記第１ＢＦＲ－ＩＤを通知するものである判定モジュールと、存在すると決定した場合、前記第１ＢＦＲ－ＩＤに対応する第１ビット転送ルータプレフィックスＢＦＲ－Ｐｒｅｆｉｘ及び前記第２ＢＦＲ－ＩＤに対応する第２ＢＦＲ－Ｐｒｅｆｉｘから目標ＢＦＲ－Ｐｒｅｆｉｘを決定するように構成される決定モジュールと、前記目標ＢＦＲ－Ｐｒｅｆｉｘに基づいて、前記目標転送テーブルを生成するように構成される生成モジュールと、を含む、転送テーブルの生成装置を提供する。
【0013】
本発明のさらに別の実施例によれば、コンピュータプログラムが記憶されているコンピュータ読み取り可能な記憶媒体であって、前記コンピュータプログラムは、実行される場合に上記方法の実施例におけるステップを実現するように構成されるコンピュータ読み取り可能な記憶媒体をさらに提供する。
【0014】
本発明のさらに別の実施例によれば、コンピュータプログラムが記憶されているメモリと、前記コンピュータプログラムを実行して上記方法の実施例におけるステップを実現するように構成されるプロセッサとを含む、電子装置をさらに提供する。
【図面の簡単な説明】
【0015】
【図1】関連技術におけるネットワークアーキテクチャ図（その１）である。
【図2】関連技術におけるＢＦＲ１上のＢＩＥＲ転送テーブルの概略図である。
【図3】関連技術における一般的な転送テーブルの概略図である。
【図4】関連技術におけるネットワークアーキテクチャ図（その２）である。
【図5】関連技術におけるユニキャストルーティングテーブルの概略図である。
【図6】関連技術におけるＢＩＥＲ転送ルーティングテーブルの概略図（その１）である。
【図7】関連技術におけるｄｏｍａｉｎ２のＢＦＲｍ上のユニキャストルーティングテーブルの概略図である。
【図8】関連技術におけるＢＩＥＲ転送ルーティングテーブルの概略図（その２）である。
【図9】本発明の実施例に係る転送テーブルの生成方法のモバイル端末のハードウェア構成のブロック図である。
【図10】本発明の実施例に係る転送テーブルの生成方法のフローチャートである。
【図11】本発明の実施例に係るドメイン外ＳＵＢ－ＳＵＢ－ＴＬＶフォーマットの概略図（その１）である。
【図12】本発明の実施例に係るドメイン外ＳＵＢ－ＳＵＢ－ＴＬＶフォーマットの概略図（その２）である。
【図13】本発明の実施例に係るドメイン外ＳＵＢ－ＳＵＢ－ＴＬＶがＤＯＭＡＩＮ－ＩＤを単独に含む場合のフォーマットの概略図である。
【図14】本発明の実施例に係るドメイン外ＳＵＢ－ＳＵＢ－ＴＬＶがＤＯＭＡＩＮ－ＩＤを含む場合のフォーマットの概略図（その１）である。
【図15】本発明の実施例に係るドメイン外ＳＵＢ－ＳＵＢ－ＴＬＶがＤＯＭＡＩＮ－ＩＤを含む場合のフォーマットの概略図（その２）である。
【図16】本発明の実施例に係るデバイスがＢＩＥＲ転送テーブルを生成する全体フローチャートである。
【図17】本発明の具体的な実施例１に係るユニキャストルーティングテーブルの概略図である。
【図18】本発明の具体的な実施例１に係るＢＩＥＲ転送テーブルの概略図である。
【図19】本発明の具体的な実施例２に係るユニキャストルーティングテーブルの概略図である。
【図20】本発明の具体的な実施例２に係るＢＩＥＲ転送テーブルの概略図（その１）である。
【図21】本発明の具体的な実施例２に係るＢＩＥＲ転送テーブルの概略図（その２）である。
【図22】本発明の具体的な実施例３に係るユニキャストルーティングテーブルの概略図である。
【図23】本発明の具体的な実施例４に係るネットワークアーキテクチャ図である。
【図24】本発明の具体的な実施例４に係るユニキャストルーティングテーブルの概略図である。
【図25】本発明の具体的な実施例４に係るＢＩＥＲ転送テーブルの概略図である。
【図26】本発明の実施例に係る転送テーブルの生成装置のブロック構成図である。
【発明を実施するための形態】
【0016】
まず、本発明の実施例に係る関連技術について説明する。
従来のＯＳＰＦ、ＩＳＩＳなどのプロトコルにおいて、拡張によってＢＩＥＲ情報を通知するとき、通知の主なコンテンツは、ルーティングプレフィックス及びＢＦＲ－ＩＤなどを含み、例えば、ＯＳＰＦは、ＲＦＣ８４４４の定義に基づいて、ルーティングプレフィックスを通知するとき、ＢＩＥＲ ＳＵＢ－ＴＬＶを追加することにより、ＢＦＲ－ＩＤなどの情報を含む。プロトコルがプレフィックスに基づいてルーティング計算を行った後、ＢＩＥＲ転送テーブルエントリは、両者に基づいて正確に生成される。図１を例として、該ネットワークにおけるエッジデバイスは、ＢＦＩＲ、及びいくつかのＢＦＥＲであるＢＦＥＲ１～ＢＦＥＲｎを含み、エッジデバイスは、そのＢＦＲ－ＩＤ、及び対応するＳｕｂ－Ｄｏｍａｉｎ、ＢＦＲ－Ｐｒｅｆｉｘなどを一緒に通知し、プレフィックスＰｒｅｆｉｘは、通常、デバイスのＬｏｏｐｂａｃｋアドレスから取得され、ネットワークにおいて１台のデバイスを一意に識別するものであり、同一のドメインにおいて、ＢＦＲ－ＩＤとＢＦＲ－Ｐｒｅｆｉｘ（ＢＦＲ－Ｐｒｅｆｉｘは、デバイスのＬｏｏｐｂａｃｋプレフィックスアドレスである）は、１対１に対応する。ＯＳＰＦプロトコルがＲＦＣ８４４４に基づいて通知すると仮定すると、ＯＳＰＦのＥｘｔｅｎｄｅｄ Ｐｒｅｆｉｘ ＴＬＶによってＢＦＲ－Ｐｒｅｆｉｘを通知し、このプレフィックスにＢＩＥＲ ＳＵＢ－ＴＬＶを追加してＳｕｂ－Ｄｏｍａｉｎ－ＩＤ、ＢＦＲ－ＩＤなどの情報を含み、ネットワークの中間デバイスＢＦＲもこのプロトコル拡張に従って通知するが、中間デバイスＢＦＲがＢＦＲ－ＩＤを割り当てないため、通知されたＢＦＲ－ＩＤは、０である。図１の例では、ＢＦＩＲ１のＢＦＲ－ＩＤが１００であり、そのＢＦＲ－ＰｒｅｆｉｘがＰ１００であり、ＢＦＥＲ１のＢＦＲ－ＩＤが１であり、そのＢＦＲ－ＰｒｅｆｉｘがＰ１であり、ＢＦＥＲ２のＢＦＲ－ＩＤが２であり、そのＢＦＲ－ＰｒｅｆｉｘがＰ２であると仮定し、これによって類推し、これらのＢＦＲ－ＩＤは、いずれもＳｕｂ－Ｄｏｍａｉｎ ０にあると仮定する。
従来のＯＳＰＦ、ＩＳＩＳなどのプロトコルにおいて、拡張によってＢＩＥＲ情報を通知するとき、通知の主なコンテンツは、ルーティングプレフィックス及びＢＦＲ－ＩＤなどを含み、例えば、ＯＳＰＦは、ＲＦＣ８４４４の定義に基づいて、ルーティングプレフィックスを通知するとき、ＢＩＥＲ ＳＵＢ－ＴＬＶを追加することにより、ＢＦＲ－ＩＤなどの情報を含む。プロトコルがプレフィックスに基づいてルーティング計算を行った後、ＢＩＥＲ転送テーブルエントリは、両者に基づいて正確に生成される。図１を例として、該ネットワークにおけるエッジデバイスは、ＢＦＩＲ、及びいくつかのＢＦＥＲであるＢＦＥＲ１～ＢＦＥＲｎを含み、エッジデバイスは、そのＢＦＲ－ＩＤ、及び対応するＳｕｂ－Ｄｏｍａｉｎ、ＢＦＲ－Ｐｒｅｆｉｘなどを一緒に通知し、プレフィックスＰｒｅｆｉｘは、通常、デバイスのＬｏｏｐｂａｃｋアドレスから取得され、ネットワークにおいて１台のデバイスを一意に識別するものであり、同一のドメインにおいて、ＢＦＲ－ＩＤとＢＦＲ－Ｐｒｅｆｉｘ（ＢＦＲ－Ｐｒｅｆｉｘは、デバイスのＬｏｏｐｂａｃｋプレフィックスアドレスである）は、１対１に対応する。ＯＳＰＦプロトコルがＲＦＣ８４４４に基づいて通知すると仮定すると、ＯＳＰＦのＥｘｔｅｎｄｅｄ Ｐｒｅｆｉｘ ＴＬＶによってＢＦＲ－Ｐｒｅｆｉｘを通知し、このプレフィックスにＢＩＥＲ ＳＵＢ－ＴＬＶを追加してＳｕｂ－Ｄｏｍａｉｎ－ＩＤ、ＢＦＲ－ＩＤなどの情報を含み、ネットワークの中間デバイスＢＦＲもこのプロトコル拡張に従って通知するが、中間デバイスＢＦＲがＢＦＲ－ＩＤを割り当てないため、通知されたＢＦＲ－ＩＤは、０である。図１の例では、ＢＦＩＲ１のＢＦＲ－ＩＤが１００であり、そのＢＦＲ－ＰｒｅｆｉｘがＰ１００であり、ＢＦＥＲ１のＢＦＲ－ＩＤが１であり、そのＢＦＲ－ＰｒｅｆｉｘがＰ１であり、ＢＦＥＲ２のＢＦＲ－ＩＤが２であり、そのＢＦＲ－ＰｒｅｆｉｘがＰ２であると仮定し、これによって類推し、これらのＢＦＲ－ＩＤは、いずれもＳｕｂ－Ｄｏｍａｉｎ ０にあると仮定する。
【0017】
ＯＳＰＦプロトコルのフラッディングメカニズムにより、ネットワークにおけるデバイスは、他のデバイスからの通知を受信した後、受信されたプレフィックス情報に基づいてルーティング計算を行って、通常転送用のユニキャストルーティングテーブルを生成し、それによりＢＩＥＲ転送用のＢＩＥＲルーティングテーブルを生成し、例えば、ＲＦＣ８２７９に記載されているように、ＢＩＥＲ転送テーブルは、ＢＦＲ－ＩＤがインデックスであり、ＢＦＲ－ｐｒｅｆｉｘ及びネクストホップ近隣ＢＦＲ－ＮＢＲを含むテーブルエントリである。例えば、図２は、ＢＦＲ１におけるＢＩＥＲ転送テーブルであり、このテーブルを生成する前に、まず、ＢＦＲ１は、受信されたＯＳＰＦ通知に基づいて、図３に示すような通常の転送テーブルを生成する必要があり、このテーブルは、ユニキャストルーティング転送に用いられ、このテーブルは、プレフィックスをインデックスとして生成され、例えば、ＢＦＥＲ１によって通知されたプレフィックスＰ１に対して、該ルーティングに対応するネクストホップデバイスがＢＦＲ２であることを計算し、その後、該ルーティングに対応する通知ＴＬＶに含まれているＢＩＥＲ ＳＵＢ－ＴＬＶを取り出し、その中に含まれるＢＦＲ－ＩＤ値をインデックスとしてＢＩＥＲ転送テーブルに追加し、このように類推して図２の転送テーブルを生成する。
【0018】
１つのＢＩＥＲドメインが複数のＩＧＰドメイン又はＡＳドメイン（ここでのドメインｄｏｍａｉｎ、上記ＢＩＥＲ通知時のＳｕｂ－Ｄｏｍａｉｎと同じ意味ではない）からなる場合、図４に示すネットワークのように、このＢＩＥＲドメインは、３つのドメインからなり、単独の各ドメインにおいて、ＯＳＰＦ、ＩＳＩＳ、ＢＧＰなどのようなプロトコルが動作し、各ドメインで動作するプロトコルは、同じでも異なってもよい。例えば、ｄｏｍａｉｎ１において、ＢＧＰプロトコルが動作しているかもしれず、ｄｏｍａｉｎ２及びｄｏｍａｉｎ３において、ＯＳＰＦプロトコルが動作しているかもしれず、或いは、ｄｏｍａｉｎ１において、ＯＳＰＦプロトコルが動作しているかもしれず、ｄｏｍａｉｎ２においてＢＧＰプロトコルが動作しているかもしれず、ｄｏｍａｉｎ３において、ＩＳＩＳプロトコルなどが動作しているかもしれない。各ｄｏｍａｉｎ内のプロトコル通知範囲は、該ｄｏｍａｉｎのみにある。マルチキャストトラフィックがＢＦＩＲ１デバイスからＢＦＥＲ１～６に送信される必要があると仮定すると、デバイスは、自身のｄｏｍａｉｎ内の転送テーブルを作成する必要がある以外、他のｄｏｍａｉｎの受信者に到達できる転送テーブルを作成する必要がある。
【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】
以上は、本発明の好ましい実施例に過ぎず、本発明の実施例を限定するものではなく、当業者であれば、本発明の実施例に対する様々な変更と変化を行うことができる。本発明の実施例の原則内で行われるいかなる修正、均等置換及び改善などは、いずれも本発明の実施例の保護範囲内に含まれるべきである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【国際調査報告】