JP2023530347A

JP2023530347A - Ｂｉｅｒｏａｍ検出方法、デバイス及びシステム

Info

Publication number: JP2023530347A
Application number: JP2022577461A
Authority: JP
Inventors: フゥ，ジン; イ，ウエイ; シエ，ジンルゥオン; ワン，ジュ; ホア，ティン
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-06-18
Filing date: 2021-06-17
Publication date: 2023-07-14
Also published as: WO2021254454A1; KR20230022251A; US20230155933A1; CN113824608A; EP4160997A4; EP4160997A1

Abstract

本出願は、ＢＩＥＲＯＡＭ検出方法、デバイス及びシステムを提供する。本方法は、ビット転送入口ルータＢＦＩＲが、第１ＢＩＥＲＯＡＭパケットに基づいて検出要求パケットを取得し、検出要求パケットを少なくとも１つのＢＦＥＲに送信することを含み、ここで、検出要求パケットは、第１パケット及び第１パケットヘッダを含み、第１パケットは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、第１パケットヘッダはビット文字列を含み、ビット文字列は、測定されるべき少なくとも１つのビット転送出口ルータＢＦＥＲを示す。本出願において提供される技術的解決策によると、ＯＡＭをＢＩＥＲシナリオで実装することができる。

Description

本出願は、２０２０年６月１８日に中国国家知識産権局に出願された「ＯＡＭＤＥＴＥＣＴＩＯＮＭＥＴＨＯＤＡＮＤＡＰＰＡＲＡＴＵＳ」という名称の中国特許出願第２０２０１０５６４３０６．５号及び２０２０年８月２０日に中国国家知識産権局に出願された「ＢＩＥＲＯＡＭＤＥＴＥＣＴＩＯＮＭＥＴＨＯＤ，ＤＥＶＩＣＥ，ＡＮＤＳＹＳＴＥＭ」という名称の中国特許出願第２０２０１０８４５６６３．９号に対する優先権を主張しており、これらは参照によってその全体が本明細書に組み込まれる。

技術分野
本出願は、ネットワーク通信の分野に関し、より具体的には、ＢＩＥＲＯＡＭ検出方法、デバイス及びシステムに関する。

運用、管理及び保守（ｏｐｅｒａｔｉｏｎｓ，ａｄｍｉｎｉｓｔｒａｔｉｏｎ，ａｎｄｍａｉｎｔｅｎａｎｃｅ、ＯＡＭ）検出は、ネットワーク問題の検出を指す。ネットワーク上のデバイス間のリンクが正常であるかどうかを検出するために、検出要求パケットがネットワーク上に送信されてよく、フィードバックされた検出応答パケットを使用してネットワーク上のデバイス間のリンクが正常であるかどうかを検出する。

インターネットプロトコル（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ、ＩＰ）マルチキャスト技術は、ＩＰネットワーク内で効率的なポイントツーマルチポイントデータ伝送を実装し、その結果、ネットワーク帯域幅を効果的に節約することができ、ネットワーク負荷を軽減することができる。したがって、マルチキャストデータ転送パスを構築するための新たな技術が業界で提案されており、ビットインデックス明示複製（ｂｉｔｉｎｄｅｘｅｘｐｌｉｃｉｔｒｅｐｌｉｃａｔｉｏｎ、ＢＩＥＲ）技術と称される。本技術では、マルチキャスト配布ツリーを構築する必要がない新たなマルチキャスト技術アーキテクチャが提供される。ＢＩＥＲネットワーク内でＢＩＥＲＯＡＭ検出を実装する方法が、解決すべき問題となる。

本出願は、ＢＩＥＲシナリオにおけるＢＩＥＲＯＡＭ検出を実装するために、ＢＩＥＲＯＡＭ検出方法、ビット転送入口ルータ（ｂｉｔｆｏｒｗａｒｄｉｎｇｉｎｇｒｅｓｓｒｏｕｔｅｒ、ＢＦＩＲ）、ビット転送出口ルータ（ｂｉｔｆｏｒｗａｒｄｉｎｇｅｇｒｅｓｓｒｏｕｔｅｒ、ＢＦＥＲ）及びシステムを提供する。

第１の態様によると、ＢＩＥＲＯＡＭ検出方法が提供される。本方法は、ビット転送入口ルータＢＦＩＲが、第１ＢＩＥＲＯＡＭパケットに基づいて検出要求パケットを取得することを含み、ここで、検出要求パケットは、第１パケット及び第１パケットヘッダを含み、第１パケットは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、第１パケットヘッダはビット文字列を含み、ビット文字列は、測定されるべき少なくとも１つのビット転送出口ルータＢＦＥＲを示す。ＢＦＩＲは、検出要求パケットを少なくとも１つのＢＦＥＲに送信する。

第１ＢＩＥＲＯＡＭパケットは、カプセル化されていないＢＩＥＲＯＡＭパケットであり得ることを理解されたい。第１ＢＩＥＲＯＡＭパケットは、元のＢＩＥＲＯＡＭパケットと呼ばれることもある。

第１ＢＩＥＲＯＡＭパケットの要求／応答（ｒｅｑｕｅｓｔ／ｒｅｐｌｙ、ｒｅｑ／ｒｅｐ）フィールド内で担持（carry）される識別子は、ＢＩＥＲＯＡＭパケットが、ＯＡＭ要求パケットであるかＯＡＭ応答パケットであるかを示す。ｒｅｑフィールドは要求メッセージのタイプ（メッセージタイプ（ｍｅｓｓａｇｅｔｙｐｅ））を示し、ｒｅｐフィールドは応答メッセージのタイプ（メッセージタイプ（ｍｅｓｓａｇｅｔｙｐｅ））を示す。

前述の技術的解決策では、カプセル化されていないＢＩＥＲＯＡＭ又は元のＢＩＥＲＯＡＭがカプセル化され、その結果、本方法は、より多くのＢＩＥＲカプセル化シナリオに適用可能であり、ＢＩＥＲＯＡＭ検出はＢＩＥＲネットワーク内で実装される。

可能な実装では、第１パケットヘッダは、カプセル化がＩＰｖ６カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ６ヘッダ及び第１ＢＩＥＲＯＡＭパケットを含み、第１ＩＰｖ６ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

別の可能な実装では、第１パケットヘッダは、カプセル化がＩＰｖ４カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ４ヘッダ及び第１ＢＩＥＲＯＡＭパケットを含み、第１ＩＰｖ４ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

別の可能な実装では、第１パケットヘッダは、カプセル化がＩＰｖ６カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ６ヘッダ及びユーザデータグラムプロトコルＵＤＰカプセル化ＢＩＥＲＯＡＭパケットを含み、第１ＩＰｖ６ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、ＵＤＰカプセル化ＢＩＥＲＯＡＭパケットは、ＵＤＰヘッダ及び第１ＢＩＥＲＯＡＭパケットを含み、ＵＤＰヘッダに含まれる宛先ポートは、検出要求パケットを受信するＢＦＥＲのリスニングポートを示す。

別の可能な実装では、第１パケットヘッダは、カプセル化がＩＰｖ４カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ４ヘッダ及びユーザデータグラムプロトコルＵＤＰカプセル化ＢＩＥＲＯＡＭパケットを含み、第１ＩＰｖ４ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、ＵＤＰカプセル化ＢＩＥＲＯＡＭパケットは、ＵＤＰヘッダ及び第１ＢＩＥＲＯＡＭパケットを含み、ＵＤＰヘッダに含まれる宛先ポートは、検出要求パケットを受信するＢＦＥＲのリスニングポートを示す。

別の可能な実装では、第１パケットヘッダは、ＩＰｖ６カプセル化ＢＩＥＲヘッダを含み、ＩＰｖ６カプセル化ＢＩＥＲヘッダは、第２ＩＰｖ６ヘッダと、カプセル化がＩＰカプセル化であることを示す第１識別子とを含む。

ＩＰｖ６カプセル化ＢＩＥＲヘッダは、外部（outer）ＩＰｖ６ヘッダ及びＩＰｖ６拡張ヘッダを含み、ここで、ＩＰｖ６拡張ヘッダは、ＢＩＥＲヘッダ又はＢＩＥＲ転送を実装するために使用される情報を含む。

第２ＩＰｖ６ヘッダは、外部ＩＰｖ６ヘッダであってよい。

別の可能な実装では、第１パケットヘッダは、ＭＰＬＳカプセル化ＢＩＥＲヘッダを含み、ＭＰＬＳカプセル化ＢＩＥＲヘッダは、ＭＰＬＳラベルと、カプセル化がＩＰカプセル化であることを示す第１識別子とを含む。

ＭＰＬＳカプセル化ＢＩＥＲヘッダは複数の方式で実装され得る。可能な実装では、ＭＰＬＳカプセル化ＢＩＥＲヘッダはＢＩＥＲヘッダを含み、ここで、ＢＩＥＲヘッダの最初の４バイトは、ＭＰＬＳラベルを担持するために使用される。別の可能な実装では、ＭＰＬＳカプセル化ＢＩＥＲヘッダは、ＭＰＬＳラベル及びＢＩＥＲヘッダを含む。

別の可能な実装では、第１パケットヘッダは、イーサネット（登録商標）カプセル化ＢＩＥＲヘッダを含み、イーサネットカプセル化ＢＩＥＲヘッダは、カプセル化がＩＰカプセル化であることを示す第１識別子を含む。

別の可能な実装では、方法は、ＢＦＩＲが、少なくとも１つのＢＦＥＲから検出応答パケットを受信することを更に含み、検出応答パケットは第２パケットを含み、第２パケットは第２ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットである。

第２ＢＩＥＲＯＡＭパケット内の要求／応答（ｒｅｑｕｅｓｔ／ｒｅｐｌｙ、ｒｅｑ／ｒｅｐ）フィールド内で担持される識別子は、ＢＩＥＲＯＡＭパケットが、ＯＡＭ要求パケットであるかＯＡＭ応答パケットであるかを示す。ｒｅｑフィールドは要求メッセージのタイプ（メッセージタイプ）を示し、ｒｅｐフィールドは応答メッセージのタイプ（メッセージタイプ）を示す。

別の可能な実装では、第２パケットは、第３ＩＰｖ６ヘッダ及び第２ＢＩＥＲＡＯＭパケットを含み、第３ＩＰｖ６ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

別の可能な実装では、第２パケットは、第２ＩＰｖ４ヘッダ及び第２ＢＥＩＲＯＡＭパケットを含み、第２ＩＰｖ４ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

別の可能な実装では、第２パケットは、第３ＩＰｖ６ヘッダ及びＵＤＰカプセル化ＢＩＥＲＯＡＭパケットを含み、第３ＩＰｖ６ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、ＵＤＰカプセル化ＢＩＥＲＯＡＭパケットは、ＵＤＰヘッダ及び第２ＢＩＥＲＯＡＭパケットを含み、ＵＤＰヘッダに含まれるソースポート番号は、検出要求パケットを受信するＢＦＥＲのリスニングポートを示す。

別の可能な実装では、第２パケットは、第２ＩＰｖ４ヘッダ及びＵＤＰカプセル化ＢＩＥＲＯＡＭパケットを含み、第２ＩＰｖ４ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、ＵＤＰカプセル化ＢＩＥＲＯＡＭパケットは、ＵＤＰヘッダ及び第２ＢＩＥＲＯＡＭパケットを含み、ＵＤＰヘッダに含まれるソースポート番号は、検出要求パケットを受信するＢＦＥＲのリスニングポートを示す。

別の可能な実装では、検出応答パケットは、第２パケットヘッダを更に含み、第２パケットヘッダは、カプセル化がＩＰカプセル化であることを示す第２識別子を含む。

別の可能な実装では、第２パケットヘッダは、ＩＰｖ６カプセル化ＢＩＥＲヘッダを含み、ＩＰｖ６カプセル化ＢＩＥＲヘッダは、第２ＩＰｖ６ヘッダ及び第２識別子を含む。

別の可能な実装では、第２パケットヘッダは、ＭＰＬＳカプセル化ＢＩＥＲヘッダを含み、ＭＰＬＳカプセル化ＢＩＥＲヘッダは、ＭＰＬＳラベル及び第２識別子を含む。

別の可能な実装では、第２パケットヘッダは、イーサネット（登録商標）カプセル化ＢＩＥＲヘッダを含み、イーサネットカプセル化ＢＩＥＲヘッダは第２識別子を含む。

第２の態様によると、ＢＩＥＲＯＡＭ検出方法が提供される。本方法は、ビット転送出口ルータＢＦＥＲが、ビット転送入口ルータＢＦＩＲからの検出要求パケットを受信することを含み、ここで、検出要求パケットは、第１パケット及び第１パケットヘッダを含み、第１パケットは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、第１パケットヘッダはビット文字列を含み、ビット文字列は、測定されるべき少なくとも１つのＢＦＥＲを示す。第１ＢＦＥＲは、第１パケット及びビット文字列に基づいて検出応答パケットを取得し、ここで、検出応答パケットは第２パケットを含み、第２パケットは、第２ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットである。第１ＢＦＥＲは、検出応答パケットをＢＦＩＲに送信する。

第２ＢＩＥＲＯＡＭパケット内の要求／応答（ｒｅｑｕｅｓｔ／ｒｅｐｌｙ、ｒｅｑ／ｒｅｐ）フィールドで担持される識別子は、ＢＩＥＲＯＡＭパケットが、ＯＡＭ要求パケットであるかＯＡＭ応答パケットであるかを示す。ｒｅｑフィールドは、要求メッセージのタイプ（メッセージタイプ）を示し、ｒｅｐフィールドは、応答メッセージのタイプ（メッセージタイプ）を示す。

ＩＰｖ６カプセル化ＢＩＥＲヘッダは、外部ＩＰｖ６ヘッダ及びＩＰｖ６拡張ヘッダを含み、ここで、ＩＰｖ６拡張ヘッダは、ＢＩＥＲヘッダを含む。

別の可能な実装では、第１パケットヘッダは、イーサネットカプセル化ＢＩＥＲヘッダを含み、イーサネットカプセル化ＢＩＥＲヘッダは、カプセル化がＩＰカプセル化であることを示す第１識別子を含む。

別の可能な実装では、第２パケットヘッダは、イーサネットカプセル化ＢＩＥＲヘッダを含み、イーサネットカプセル化ＢＩＥＲヘッダは第２識別子を含む。

第２の態様又は第２の態様の可能な実装のうちのいずれか１つの有利な効果は、第１の態様又は第１の態様の可能な実装のいずれか１つの有利な効果に対応する。詳細はここでは再度説明しない。

第３の態様によると、ビット転送入口ルータＢＦＩＲが提供され、
第１ＢＩＥＲＯＡＭパケットに基づいて検出要求パケットを取得するよう構成される処理モジュールであって、ここで、検出要求パケットは、第１パケット及び第１パケットヘッダを含み、第１パケットは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、第１パケットヘッダはビット文字列を含み、ビット文字列は、測定されるべき少なくとも１つのビット転送出口ルータＢＦＥＲを示す、処理モジュールと、
検出要求パケットを少なくとも１つのＢＦＥＲに送信するよう構成される送信モジュールと、
を含む。

別の可能な実装では、ＢＦＩＲは、
少なくとも１つのＢＦＥＲから検出応答パケットを受信するよう構成される受信モジュールを更に含み、ここで、検出応答パケットは第２パケットを含み、第２パケットは、第２ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットである。

第４の態様によると、ビット転送出口ルータＢＦＥＲが提供され、
ビット転送入口ルータＢＦＩＲからの検出要求パケットを受信するよう構成される受信モジュールであって、ここで、検出要求パケットは、第１パケット及び第１パケットヘッダを含み、第１パケットは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、第１パケットヘッダはビット文字列を含み、ビット文字列は、測定されるべき少なくとも１つのＢＦＥＲを示す、受信モジュールと、
第１パケット及びビット文字列に基づいて検出応答パケットを取得するよう構成される処理モジュールであって、検出応答パケットは第２パケットを含み、第２パケットは第２ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットである、処理モジュールと、
検出応答パケットをＢＦＩＲに送信するよう構成される送信モジュールと、
を含む。

第５の態様によると、ＢＦＩＲが提供される。ＢＦＩＲは、前述の方法におけるＢＦＩＲの挙動を実装する機能を有する。その機能は、ハードウェアに基づいて実装され得るか又はハードウェアが対応するソフトウェアを実行することに基づいて実装され得る。ハードウェア又はソフトウェアは、前述の機能に対応する１つ以上のモジュールを含む。

可能な設計では、ＢＦＩＲの構造は、プロセッサ及びインタフェースを含む。プロセッサは、前述の方法における対応する機能を実行する際にＢＦＩＲをサポートするよう構成される。インタフェースは、検出要求パケットを少なくとも１つのビット転送出口ルータＢＦＥＲに送信する際にＢＦＩＲをサポートするよう構成される。

ＢＦＩＲはメモリを更に含み得る。メモリはプロセッサに結合されるよう構成され、ＢＦＩＲに必要なプログラム命令及びデータを記憶する。

別の可能な設計では、ＢＦＩＲは、プロセッサ、トランスミッタ、レシーバ、ランダムアクセスメモリ、読取専用メモリ及びバスを含む。プロセッサは、バスを通してトランスミッタ、レシーバ、ランダムアクセスメモリ及び読取専用メモリに結合される。ＢＦＩＲが実行する必要があるとき、ＢＦＩＲは、読取専用メモリに組み込まれた基本入出力システム又は組込みシステムのブートローダ起動システムを使用することによって開始され、ＢＦＩＲを起動して通常の実行状態に入る。通常の実行状態に入った後、ＢＦＩＲはランダムアクセスメモリ内のアプリケーションプログラム及びオペレーティングシステムを実行し、その結果、プロセッサは、第１の態様及び第１の態様の可能な実装のうちのいずれか１つの方法を実行する。

第６の態様によると、ＢＦＩＲが提供される。ＢＦＩＲは、主制御ボードとインタフェースボードを含み、スイッチングボードを更に含んでもよい。ＢＦＩＲは、第１の態様及び第１の態様の可能な実装のうちのいずれか１つの方法を実行するよう構成される。具体的には、ＢＦＩＲは、第１の態様及び第１の態様の可能な実装のうちのいずれか１つの方法を実行するよう構成されるモジュールを含む。

１つ以上の主制御ボードが存在してもよいことに留意されたい。複数の主制御ボードが存在するとき、主制御ボードは、アクティブ主制御ボードとスタンバイ主制御ボードを含み得る。１つ以上のインタフェースボードが存在してもよく、より強力なデータ処理能力を有するＢＦＥＲは、より多くのインタフェースボードを提供する。また、インタフェースボード上に１つ以上の物理インタフェースカードが存在してもよい。スイッチングボードがなくてもよく、１つ以上のスイッチングボードが存在してもよい。複数のスイッチングボードが存在するとき、負荷分散と冗長性バックアップが一緒に実装され得る。集中型転送アーキテクチャでは、ＢＦＥＲはスイッチングボードを必要としないことがあり、インタフェースボードはシステム全体のサービスデータを処理する機能を提供する。分散型転送アーキテクチャでは、ＢＦＥＲは、少なくとも１つのスイッチングボードを有し、スイッチングボードを介して複数のインタフェースボードの間でデータを交換することができ、大容量のデータ交換と処理能力を提供する。したがって、分散型アーキテクチャのＢＦＥＲのデータアクセス及び処理機能は、集中型アーキテクチャのデバイスのものよりも優れている。使用されるべき特定のアーキテクチャは、特定のネットワーク展開シナリオに依存する。これはここでは限定されない。

第７の態様によると、ＢＦＩＲが提供される。ＢＦＩＲは、制御モジュールと第１転送サブデバイスを含む。第１転送サブデバイスはインタフェースボードを含み、スイッチングボードを更に含んでもよい。第１転送サブデバイスは、第６の態様におけるインタフェースボードの機能を実行するよう構成され、第６の態様におけるスイッチングボードの機能を更に実行してもよい。制御モジュールは、レシーバ、プロセッサ、トランスミッタ、ランダムアクセスメモリ、読取専用メモリ及びバスを含む。プロセッサは、バスを通してレシーバ、トランスミッタ、ランダムアクセスメモリ及び読取専用メモリに結合される。制御モジュールが実行する必要があるとき、制御モジュールは、読取専用メモリに組み込まれた基本入出力システム又は組込みシステムのブートローダ起動システムを使用することによって開始され、制御モジュールを起動して通常の実行状態に入る。通常の実行状態に入った後、制御モジュールはランダムアクセスメモリ内のアプリケーションプログラム及びオペレーティングシステムを実行し、その結果、プロセッサは、第６の態様の主制御モジュールの機能を実行する。

実際の適用では、ＢＦＩＲは任意の量のインタフェース、プロセッサ又はメモリを含み得ることが理解され得る。

第８の態様によると、ＢＦＥＲが提供される。ＢＦＥＲは、前述の方法におけるＢＦＥＲの挙動を実装する機能を有する。その機能は、ハードウェアに基づいて実装され得るか又はハードウェアが対応するソフトウェアを実行することに基づいて実装され得る。ハードウェア又はソフトウェアは、前述の機能に対応する１つ以上のモジュールを含む。

可能な設計では、ＢＦＥＲの構造は、プロセッサ及びインタフェースを含む。プロセッサは、前述の方法における対応する機能を実行する際にＢＦＥＲをサポートするよう構成される。インタフェースは、検出要求パケットを少なくとも１つのビット転送入口ルータＢＦＩＲから受信することをサポートするよう構成されるか又は検出応答パケットをＢＦＩＲに送信するよう構成される。

ＢＦＥＲはメモリを更に含み得る。メモリはプロセッサに結合されるよう構成され、ＢＦＥＲに必要なプログラム命令及びデータを記憶する。

別の可能な設計では、ＢＦＥＲは、プロセッサ、トランスミッタ、レシーバ、ランダムアクセスメモリ、読取専用メモリ及びバスを含む。プロセッサは、バスを通してトランスミッタ、レシーバ、ランダムアクセスメモリ及び読取専用メモリに結合される。ＢＦＥＲが実行する必要があるとき、ＢＦＥＲは、読取専用メモリに組み込まれた基本入出力システム又は組込みシステムのブートローダ起動システムを使用することによって開始され、ＢＦＥＲを起動して通常の実行状態に入る。通常の実行状態に入った後、ＢＦＥＲはランダムアクセスメモリ内のアプリケーションプログラム及びオペレーティングシステムを実行し、その結果、プロセッサは、第２の態様及び第２の態様の可能な実装のうちのいずれか１つの方法を実行する。

第９の態様によると、ＢＦＥＲが提供される。ＢＦＥＲは、主制御ボードとインタフェースボードを含み、スイッチングボードを更に含んでもよい。ＢＦＥＲは、第２の態様及び第２の態様の可能な実装のうちのいずれか１つの方法を実行するよう構成される。具体的には、ＢＦＥＲは、第２の態様及び第２の態様の可能な実装のうちのいずれか１つの方法を実行するよう構成されるモジュールを含む。

第１０の態様によると、ＢＦＥＲが提供される。ＢＦＥＲは、制御モジュールと第１転送サブデバイスを含む。第１転送サブデバイスはインタフェースボードを含み、スイッチングボードを更に含んでもよい。第１転送サブデバイスは、第９の態様におけるインタフェースボードの機能を実行するよう構成され、第９の態様におけるスイッチングボードの機能を更に実行してもよい。制御モジュールは、レシーバ、プロセッサ、トランスミッタ、ランダムアクセスメモリ、読取専用メモリ及びバスを含む。プロセッサは、バスを通してレシーバ、トランスミッタ、ランダムアクセスメモリ及び読取専用メモリに結合される。制御モジュールが実行する必要があるとき、制御モジュールは、読取専用メモリに組み込まれた基本入出力システム又は組込みシステムのブートローダ起動システムを使用することによって開始され、制御モジュールを起動して通常の実行状態に入る。通常の実行状態に入った後、制御モジュールはランダムアクセスメモリ内のアプリケーションプログラム及びオペレーティングシステムを実行し、その結果、プロセッサは、第９の態様の主制御モジュールの機能を実行する。

実際の適用では、ＢＦＥＲは、任意の量のインタフェース、プロセッサ又はメモリを含み得ることが理解され得る。

第１１の態様によると、コンピュータプログラム製品が提供される。コンピュータプログラム製品は、コンピュータプログラムコードを含む。コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、第１の態様又は第１の態様の可能な実装のいずれか１つによる方法を実行することが可能になる。

第１２の態様によると、コンピュータプログラム製品が提供される。コンピュータプログラム製品は、コンピュータプログラムコードを含む。コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、第２の態様又は第２の態様の可能な実装のいずれか１つによる方法を実行することが可能になる。

第１３の態様によると、コンピュータ読取可能媒体が提供される。コンピュータ読取可能媒体はプログラムコードを記憶する。コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、第１の態様又は第１の態様の可能な実装のいずれか１つによる方法を実行することが可能になる。コンピュータ読取可能ストレージは、読取専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、プログラマブルＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅＲＯＭ、ＰＲＯＭ）、消去可能ＰＲＯＭ（ｅｒａｓａｂｌｅＰＲＯＭ、ＥＰＲＯＭ）、フラッシュメモリ、電気的ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙＥＰＲＯＭ、ＥＥＰＲＯＭ）及びハードドライブ（ｈａｒｄｄｒｉｖｅ）のうちの１つ以上を含むが、これらに限定されない。

第１４の態様によると、コンピュータ読取可能媒体が提供される。コンピュータ読取可能媒体はプログラムコードを記憶する。コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、第２の態様又は第２の態様の可能な実装のいずれか１つによる方法を実行することが可能になる。コンピュータ読取可能ストレージは、読取専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、プログラマブルＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅＲＯＭ、ＰＲＯＭ）、消去可能ＰＲＯＭ（ｅｒａｓａｂｌｅＰＲＯＭ、ＥＰＲＯＭ）、フラッシュメモリ、電気的ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙＥＰＲＯＭ、ＥＥＰＲＯＭ）及びハードドライブ（ｈａｒｄｄｒｉｖｅ）のうちの１つ以上を含むが、これらに限定されない。

第１５の態様によると、チップが提供される。チップはプロセッサとデータインタフェースを含み、プロセッサは、データインタフェースを通してメモリに記憶された命令を読み取って、第１の態様又は第１の態様の可能な実装のいずれか１つの方法を実行する。特定の実装プロセスでは、チップは、中央処理ユニット（ｃｅｎｔｒａｌｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＣＰＵ）、マイクロコントローラユニット（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒｕｎｉｔ、ＭＣＵ）、マイクロ処理ユニット（ｍｉｃｒｏｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＭＰＵ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌｓｉｇｎａｌｐｒｏｃｅｓｓｏｒ、ＤＳＰ）、システムオンアチップ（ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ、ＳｏＣ）、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃｉｎｔｅｇｒａｔｅｄｃｉｒｃｕｉｔ、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄｐｒｏｇｒａｍｍａｂｌｅｇａｔｅａｒｒａｙ、ＦＰＧＡ）又はプログラマブル論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅｌｏｇｉｃｄｅｖｉｃｅ、ＰＬＤ）の形態で実装され得る。

第１６の態様によると、チップが提供される。チップはプロセッサとデータインタフェースを含み、プロセッサは、データインタフェースを通してメモリに記憶された命令を読み取って、第２の態様又は第２の態様の可能な実装のいずれか１つの方法を実行する。特定の実装プロセスでは、チップは、中央処理ユニット（ｃｅｎｔｒａｌｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＣＰＵ）、マイクロコントローラユニット（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒｕｎｉｔ、ＭＣＵ）、マイクロ処理ユニット（ｍｉｃｒｏｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＭＰＵ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌｓｉｇｎａｌｐｒｏｃｅｓｓｏｒ、ＤＳＰ）、システムオンアチップ（ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ、ＳｏＣ）、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃｉｎｔｅｇｒａｔｅｄｃｉｒｃｕｉｔ、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄｐｒｏｇｒａｍｍａｂｌｅｇａｔｅａｒｒａｙ、ＦＰＧＡ）又はプログラマブル論理デバイス（ｐｒｏｇｒａｍｍａｂｌｅｌｏｇｉｃｄｅｖｉｃｅ、ＰＬＤ）の形態で実装され得る。

第１７の態様によると、システムが提供される。システムは、前述のＢＦＩＲとＢＦＥＲを含む。

本出願の一実施形態によるＢＩＥＲ技術の概略ネットワーク図である。

本出願の一実施形態によるＢＩＥＲヘッダの可能なフォーマットの概略図である。

本出願の一実施形態によるＢＩＥＲヘッダの別の可能なフォーマットの概略図である。

ＢＩＥＲ技術に基づいてＢＩＥＲ転送テーブルを確立し、ＢＩＥＲ技術に基づいてＢＩＥＲパケットを転送するプロセスを示す。

本出願の一実施形態によるＢＩＥＲｖ６カプセル化パケットの可能なフォーマットの概略図である。

本出願の一実施形態によるＢＩＥＲＯＡＭ検出方法の概略フローチャートである。

本出願の一実施形態によるＰｉｎｇ検出の概略フローチャートである。

本出願の一実施形態によるＢＩＥＲＯＡＭ検出要求パケットのフォーマットの概略図である。

本出願の一実施形態によるトレース検出の概略フローチャートである。

本出願の一実施形態によるＩＰｖ６ネットワークベースのＢＩＥＲ－ＭＰＬＳカプセル化ＢＩＥＲＯＡＭ検出要求パケットのフォーマットの概略図である。

本出願の一実施形態による別のＰｉｎｇ検出の概略フローチャートである。

本出願の一実施形態によるＭＰＬＳに基づいてＢＩＥＲＯＡＭ検出要求パケットを転送する概略図である。

本出願の一実施形態によるＢＦＩＲ９００の構造の概略図である。

本出願の一実施形態によるＢＦＥＲ１０００の構造の概略図である。

本出願の一実施形態によるＢＦＩＲ２０００のハードウェア構造の概略図である。

本出願の一実施形態による別のＢＦＩＲ２１００のハードウェア構造の概略図である。

本出願の一実施形態によるＢＦＥＲ２２００のハードウェア構造の概略図である。

本出願の一実施形態による別のＢＦＥＲ２４００のハードウェア構造の概略図である。

以下では、添付の図面を参照して本出願の技術的解決策を説明する。

すべての態様、実施形態又は特徴は、本出願において、複数のデバイス、構成要素及びモジュールを含むシステムに基づいて提示される。各システムが、別のデバイス、構成要素、モジュール等を含むことがあり、かつ／又は添付の図面を参照して議論されるすべてのデバイス、構成要素、モジュール等を含まないこともあることを理解されたい。加えて、これらの解決策の組合せが更に使用されてもよい。

加えて、本出願の実施形態では、「例えば」及び「のような」といった用語は、例、図又は説明を与えることを表すために使用される。本出願で「例」として説明される任意の実施形態又は設計スキームは、別の実施形態又は設計スキームよりも好ましいものとして又はより多くの利点を有するものとして説明されるべきではない。まさに、「例」という言葉は概念を特定の方法で提示するために使用される。

本出願の実施形態では、「対応する（ｃｏｒｒｅｓｐｏｎｄｉｎｇｏｒｒｅｌｅｖａｎｔ）」と「対応する（ｃｏｒｒｅｓｐｏｎｄｉｎｇ）」が同じ意味で使用されることがある。本用語によって表される意味は、違いが強調されないときは一貫していることに留意されたい。

本出願の実施形態で説明されているネットワークアーキテクチャ及びサービスシナリオは、本出願の実施形態における技術的解決策をより明確に説明するよう意図されており、本出願の実施形態で提供される技術的解決策に対する限定を構成しない。当業者には、ネットワークアーキテクチャの進化及び新しいサービスシナリオの出現とともに、本出願の実施形態で提供される技術的解決策が同様の技術的問題にも適用可能であることが分かり得る。

本明細書で記載される「一実施形態」、「いくつかの実施形態」等への言及は、本出願の１つ以上の実施形態が、実施形態を参照して説明される特定の特徴、構造又は特性を含むことを示す。したがって、本明細書の異なる箇所に現れる「一実施形態において」、「いくつかの実施形態において」、「いくつかの他の実施形態において」、「他の実施形態において」のような記述は、必ずしも同じ実施形態を指すことを意味しない。代わりに、別の方法で特に強調されていない限り、当該記述は「実施形態の１つ以上であるが、すべての実施形態ではない」ことを意味する。用語「含む」、「有する」及びその変形はすべて、別の方法で特に強調されていない限り、「を含むが、限定されない」を意味する。

本出願において、「少なくとも１つ」は１つ以上を意味し、「複数の」は２つ以上を意味する。用語「及び／又は」は、関連付けられるオブジェクトを説明するための関連関係を表し、３つの関係が存在する可能性があることを表す。例えばＡ及び／又はＢは、Ａのみが存在し、ＡとＢの両方が存在し、Ｂのみが存在するケースを示してよく、ここで、Ａ及びＢは単数であっても又は複数であってもよい。記号「／」は、一般に、関連付けられるオブジェクト間の「又は」の関係を示す。次のアイテム（ピース）のうちの少なくとも１つ又はその類似表現は、単数のアイテム（ピース）又は複数のアイテム（ピース）の任意の組合せを含む、これらのアイテムの任意の組合せを指す。例えばａ、ｂ又はｃのうちの少なくとも１つのアイテム（ピース）は、ａ、ｂ、ｃ、ａとｂ、ａとｃ、ｂとｃ又はａとｂとｃを示してよく、ａ、ｂ及びｃは単数であっても又は複数であってもよい。

マルチキャスト（ｍｕｌｔｉｃａｓｔ）は、１つのマルチキャストアドレスを使用することによって、データが伝送制御プロトコル（ｔｒａｎｓｍｉｓｓｉｏｎｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ、ＴＣＰ）／インターネットプロトコル（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ、ＩＰ）ネットワーク内の複数のレシーバに同時に効率的に送信されるデータ伝送モードである。マルチキャストソースは、ネットワーク内のリンクを通してマルチキャストグループ内のマルチキャストグループメンバにマルチキャストトラフィックを送信し、マルチキャストグループ内の各マルチキャストグループメンバは、マルチキャストトラフィックを受信することができる。マルチキャスト伝送モードでは、マルチキャストソースとマルチキャストグループメンバとの間にポイントツーマルチポイントのデータ接続が実装される。マルチキャストトラフィックは各ネットワークリンク上で１回だけ送信される必要があり、マルチキャスト複製はリンク上に分岐があるときにのみ実行される。したがって、マルチキャスト伝送モードではデータ伝送効率が改善され、バックボーンネットワークにおける輻輳の可能性は低減される。

インターネットプロトコル（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ、ＩＰ）マルチキャスト技術は、ＩＰネットワーク内で効率的なポイントツーマルチポイントデータ伝送を実装し、その結果、ネットワーク帯域幅を効果的に節約することができ、ネットワーク負荷を軽減することができる。したがって、インターネットプロトコルマルチキャスト技術は、リアルタイムデータ伝送、マルチメディア会議、データコピー、インターネットプロトコルテレビジョン（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌｔｅｌｅｖｉｓｉｏｎ、ＩＰＴＶ）、ゲーム、シミュレーションのような多くの側面で広く使用される。マルチキャスト技術では、マルチキャストプロトコルを使用することによって、マルチキャストツリーがコントロールプレーン上に構築され、次いで、マルチキャストツリーを使用することによってネットワークプレーン上のロジックがツリー形状にされて、マルチキャストポイントツーマルチポイントデータ転送を実装する。分配ツリーの構築をコアとして使用する各中間デバイスは、複雑なマルチキャスト転送情報ステータスを維持する必要がある。ネットワーク規模がますます大きくなり、マルチキャストデータトラフィックが時間の経過とともに増加するにつれて、このマルチキャスト技術は、コストと運用保守の面でますます大きな課題に直面する。

したがって、マルチキャストデータ転送パスを構築するための新たな技術が業界内で提案されており、ビットインデックス明示複製（ｂｉｔｉｎｄｅｘｅｘｐｌｉｃｉｔｒｅｐｌｉｃａｔｉｏｎ、ＢＩＥＲ）技術と称される。この技術では、マルチキャスト分配ツリーを構築する必要がないマルチキャスト技術アーキテクチャが提供される。

図１に示されるように、ＢＩＥＲ技術をサポートするルータは、ビット転送ルータ（Ｂｉｔｆｏｒｗａｒｄｉｎｇｒｏｕｔｅｒ、ＢＦＲ）と称され、ＢＦＲはＢＩＥＲパケットを受信して転送することができる。１つ以上のＢＦＲを含むマルチキャスト転送ドメインは、ＢＩＥＲドメイン（ＢＩＥＲｄｏｍａｉｎ）と称される。ＢＩＥＲドメインの入口において、元のマルチキャストデータパケットに対してＢＩＥＲカプセル化を実行するＢＦＲは、ビット転送入口ルータ（ｂｉｔｆｏｒｗａｒｄｉｎｇｉｎｇｒｅｓｓｒｏｕｔｅｒ、ＢＦＩＲ）と称される。ＢＩＥＲドメインの出口において、ＢＩＥＲパケットから元のマルチキャストデータパケットを取得するためにカプセル化解除を実行するＢＦＲは、ビット転送出口ルータ（ｂｉｔｆｏｒｗａｒｄｉｎｇｅｇｒｅｓｓｒｏｕｔｅｒ、ＢＦＥＲ）と称される。ＢＩＥＲドメイン内のＢＦＩＲ及びＢＦＥＲは、ＢＩＥＲドメインのエッジＢＦＲと称されることがあることを理解されたい。

ＢＩＥＲドメインでは、ＢＩＥＲサブドメイン（ｓｕｂ－ｄｏｍａｉｎ、ＳＤ）全体のグローバルに一意なビット位置（ｂｉｔｐｏｓｉｔｉｏｎ）識別子がエッジＢＦＲについて構成され得る。一例では、各エッジＢＦＲについて、ＢＦＲ識別子（ＢＦＲｉｄｅｎｔｉｆｉｅｒ、ＢＦＲＩＤ）として値が構成される。例えばＢＦＲＩＤは１から２５６の範囲の値であり得る。ＢＩＥＲドメイン内のすべてのＢＦＲＩＤは、ビット文字列（ｂｉｔｓｔｒｉｎｇ）を形成する。

本出願の実施形態では、元のマルチキャストデータパケットがＢＩＥＲドメインで伝送されるとき、ＢＩＥＲカプセル化を実行する必要がある。具体的には、元のマルチキャストデータパケットは、追加の特定のＢＩＥＲヘッダでカプセル化され得る。ＢＩＥＲヘッダは、ビット文字列を使用して、元のマルチキャストデータパケットのすべての宛先デバイスを識別する。ＢＩＥＲドメイン内のＢＦＲは、確実に元のマルチキャストデータパケットをすべての宛先アドレスに送信することができるように、ビットインデックス転送テーブル（ｂｉｔｉｎｄｅｘｆｏｒｗａｒｄｉｎｇｔａｂｌｅ、ＢＩＦＴ）とＢＩＥＲヘッダ内に担持されるビット文字列とに基づいて転送を実行し得る。

様々なタイプのＢＩＥＲカプセル化が存在し得る。これは、本出願で特に限定されない。一例では、マルチプロトコルラベルスイッチング（ｍｕｌｔｉ－ｐｒｏｔｏｃｏｌｌａｂｅｌｓｗｉｔｃｈｉｎｇ、ＭＰＬＳ）ベースのＢＩＥＲカプセル化が、ＢＩＥＲ－ＭＰＬＳカプセル化と称されることがある。イーサネット（Ｅｔｈｅｒｎｅｔ）ベースのＢＩＥＲカプセル化が、ＢＩＥＲ－ＥＴＨカプセル化と称されることもある。ＢＩＥＲ－ＭＰＬＳカプセル化とＢＩＥＲ－ＥＴＨカプセル化の両方が、ＩＰｖ４又はＩＰｖ６ネットワークに適用され得る。ＢＩＥＲにおけるコントロールプレーンプロトコルは、ＩＰｖ４又はＩＰｖ６に基づいて動作し、ＢＩＥＲにおけるデータパケットのカプセル化と転送は、ＢＩＥＲ－ＭＰＬＳ又はＢＩＥＲ－ＥＴＨに基づく。別の例では、ＢＩＥＲパケットは、インターネットプロトコルバージョン６（Ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌｖｅｒｓｉｏｎ６、ＩＰｖ６）に基づいてカプセル化され、そのようなカプセル化は、ＢＩＥＲｖ６カプセル化と称されることがある。ＢＩＥＲｖ６カプセル化は、一般にＩＰｖ６ネットワークに適用される。ＢＩＥＲにおけるコントロールプレーンプロトコルはＩＰｖ６に基づいて動作し、ＢＩＥＲにおけるデータパケットのカプセル化と転送もＩＰｖ６に基づく。

具体的には、一例では、ＭＰＬＳカプセル化ＢＩＥＲパケットのフォーマットは、ＭＰＬＳカプセル化ＢＩＥＲヘッダ＋元のマルチキャストデータパケットであり得る。ＢＩＥＲｖ６カプセル化ＢＩＥＲパケットのフォーマットは、ＩＰｖ６ヘッダ＋ＩＰｖ６拡張ヘッダ（ＢＩＥＲヘッダを含む）＋元のマルチキャストデータパケットであり得る。

ＭＰＬＳカプセル化ＢＩＥＲヘッダは、複数の方式で実装され得ることを理解されたい。可能な実装では、ＭＰＬＳカプセル化ＢＩＥＲヘッダはＢＩＥＲヘッダを含み、この場合、ＢＩＥＲヘッダの最初の４バイトはＭＰＬＳラベルを表す。別の可能な実装では、ＭＰＬＳカプセル化ＢＩＥＲヘッダは、ＭＰＬＳラベル及びＢＩＥＲヘッダを含む。

最初の４バイトがＭＰＬＳラベルを表すＢＩＥＲヘッダはまた、ＢＩＥＲ－ＭＰＬＳヘッダとも称される。

また、このようなカプセル化では、ＩＰｖ６ヘッダと、ＢＩＥＲヘッダを含むＩＰｖ６拡張ヘッダとが一緒にＢＩＥＲｖ６ヘッダを構成することも理解されたい。元のマルチキャストデータパケットを外部ＢＩＥＲｖ６ヘッダでカプセル化することによって形成されるパケットはまた、ＢＩＥＲｖ６パケットとも称されることがある、言い換えると、ＢＩＥＲｖ６パケットは、外部（outer）ＢＩＥＲｖ６ヘッダと内部（inner）マルチキャストデータパケットを含む。

ＢＩＥＲヘッダのフォーマットは、ＢＩＥＲヘッダがビット文字列（ｂｉｔｓｔｒｉｎｇ）フィールドを含むという条件で、本出願の実施形態では特に限定されない。理解の容易性のために、以下ではまず、図２及び図３を参照してＢＩＥＲヘッダのフォーマットを詳細に説明する。

図２は、ＢＩＥＲヘッダの可能なフォーマットの概略ブロック図である。図２に示されるように、ＢＩＥＲヘッダは、ビットインデックス転送テーブル識別子（ｂｉｔｉｎｄｅｘｆｏｒｗａｒｄｉｎｇｔａｂｌｅｉｄｅｎｔｉｆｉｅｒ、ＢＩＦＴＩＤ）、ビット文字列長（ｂｉｔｓｔｒｉｎｇｌｅｎｇｔｈ、ＢＳＬ）及び他のフィールドを含み得るが、これらに限定されない。他のフィールドは、ＢＩＥＲヘッダの後の元のマルチキャストデータパケットのトラフィッククラス（ｔｒａｆｆｉｃｃｌａｓｓ、ＴＣ）、スタック（ｓｔａｃｋ、Ｓ）、生存期間（ｔｉｍｅｔｏｌｉｖｅ、ＴＴＬ）フィールド、エントロピー（ｅｎｔｒｏｐｙ）フィールド、バージョン（ｖｅｒｓｉｏｎ、Ｖｅｒ）フィールド、ニブル（ｎｉｂｂｌｅ）フィールド、プロトコル（ｐｒｏｔｏｃｏｌ、ｐｒｏｔｏ）フィールド、運用、管理及び保守（ｏｐｅｒａｔｉｏｎｓ，ａｄｍｉｎｉｓｔｒａｔｉｏｎ，ａｎｄｍａｉｎｔｅｎａｎｃｅ、ＯＡＭ）フィールド、予約済み（ｒｅｓｅｒｖｅｄ、Ｒｓｖ）フィールド及びｄｉｆｆｅｒｅｎｔｉａｔｅｄＳｅｒｖｉｃｅｓＣｏｄｅＰｏｉｎｔ（ｄｉｆｆｅｒｅｎｔｉａｔｅｄｓｅｒｖｉｃｅｓｃｏｄｅｐｏｉｎｔ、ＤＳＣＰ）フィールドを含み得るが、これらに限定されない。

ＢＩＥＲヘッダ内のフィールドを以下で個別に詳述する。

（１）ＢＩＦＴＩＤフィールド

ＢＩＥＲマルチプロトコルラベルスイッチング（ｍｕｌｔｉ－ｐｒｏｔｏｃｏｌｌａｂｅｌｓｗｉｔｃｈｉｎｇ、ＭＰＬＳ）カプセル化では、ＢＩＦＴＩＤはＭＰＬＳラベル（ｌａｂｅｌ、Ｌ）である。ＭＰＬＳラベルは、ＢＩＥＲラベルと称されることがある。

ＢＩＦＴＩＤフィールドは、３つのフィールド、すなわち、サブドメイン（ｓｕｂ－ｄｏｍａｉｎ、ＳＤ）、ビット文字列長（ｂｉｔｓｔｒｉｎｇｌｅｎｇｔｈ、ＢＳＬ）、セット識別子（ｓｅｔｉｄｅｎｔｉｆｉｅｒ、ＳＩ）を使用することによってマッピングされる。異なるＢＩＦＴＩＤは、ＳＤ、ＢＳＬ及びＳＩの異なる組合せに対応し得る。

異なるＢＩＦＴＩＤは、ＳＤ、ＢＳＬ及びＳＩの異なる組合せをマッピングし得ることを理解されたい。図２に示されるＢＩＥＲヘッダフォーマットは、ＳＤ、ＢＳＬ及びＳＩという３つのフィールドを直接含んでおらず、ＳＤ、ＢＳＬ及びＳＩは３つの暗黙のフィールドである。ＳＤ、ＢＳＬ及びＳＩという３つのフィールドの値は、ＢＩＦＴＩＤフィールドに基づいてマッピングされる必要がある。説明の容易性のために、以下ではＳＤ、ＢＳＬ、ＳＩの３つのフィールドを個別に詳述する。

１．サブドメイン（ｓｕｂ－ｄｏｍａｉｎ、ＳＤ）

１つのＢＩＥＲドメインは、実際のサービスシナリオの要件に基づいて異なるサブドメインＳＤに分割されて構成されてよく、内部ゲートウェイプロトコル（ｉｎｔｅｒｉｏｒｇａｔｅｗａｙｐｒｏｔｏｃｏｌ、ＩＧＰ）のマルチトポロジ機能等をサポートし得る。各サブドメインＳＤは、サブドメイン識別子（ｓｕｂ－ｄｏｍａｉｎｉｄｅｎｔｉｆｉｅｒ、ＳＤ－ＩＤ）によって表され得る。例えばＳＤ－ＩＤの値は［０－２５５］であり、ＳＤ－ＩＤの長さは８ビットである。

２．ビット文字列長（ｂｉｔｓｔｒｉｎｇｌｅｎｇｔｈ、ＢＳＬ）

ＢＳＬは、ＢＩＥＲヘッダに含まれるビット文字列の長さである。様々なタイプのＢＳＬが存在し得る。これは、本出願の実施形態において特に限定されない。最も小さいＢＳＬは６４ビットであり、ＢＳＬは代わりに、１２８ビット、２５６ビット、５１２ビット、１０２４ビット又は２０４８ビットであってもよく、最も大きいＢＳＬは４０９６ビットである。具体的には、パケット内のＢＳＬは４ビットで識別される。例えばＢＳＬが６４ビットであるとき、パケット内のＢＳＬは０００１で識別され、ＢＳＬが１２８ビットであるとき、パケット内のＢＳＬは００１０で識別され、ＢＳＬが５１２ビットであるとき、パケット内のＢＳＬは０１００で識別され、ＢＳＬが１０２４ビットであるとき、パケット内のＢＳＬは０１０１で識別される等である。

３．セット識別子（ｓｅｔｉｄｅｎｔｉｆｉｅｒ、ＳＩ）

ネットワーク内のＢＦＥＲデバイスの量が２５６より多い場合、このケースに適応するために、ＢＩＥＲカプセル化は、ビット文字列だけでなく、セット識別子（ｓｅｔｉｄｅｎｔｉｆｉｅｒ、ＳＩ）も含む。ＳＩは、より大規模なネットワークアドレッシングをサポートするために、ＢＩＥＲデバイスの数を複数の異なる間隔に分割するために使用される。

ＳＩは、ネットワーク内の複数のエッジＢＦＲを含むか又は構成されたＢＦＲＩＤを含むセットとして理解され得る。一例では、ＢＳＬは２５６ビットであるが、ネットワーク内に２５６より多くのエッジＢＦＲが存在するか又は２５６より多くの構成されたＢＦＲＩＤが存在する。この場合、これらのエッジＢＦＲ又はＢＦＲＩＤは、異なるセットに分割される必要がある。例えばＢＦＲＩＤの範囲が１から２５６の２５６個のエッジＢＦＲは、セット０（セットインデックス０又はＳＩ＝０）であり、ＢＦＲＩＤの範囲が２５７から５１２の２５６個のエッジＢＦＲは、セット１（セットインデックス１又はＳＩ＝１）である。

ＢＩＥＲパケットを受信した後、ＢＩＥＲドメイン内のＢＦＲは、ＢＩＥＲヘッダ内のＢＩＦＴＩＤに基づいて、ＢＩＥＲパケットが属する特定のＳＤ及び使用されるＢＳＬを決定し、パケットが特定のＳＩ及びＢＳＬによって示されるセットに属することを決定し得る。

ＢＩＦＴＩＤフィールドの値は、トリプレット＜ＳＤ、ＢＳＬ、ＳＩ＞に対応していることに留意されたい。ＢＩＦＴ－ｉｄフィールドに基づいて、一意の＜ＳＤ、ＢＳＬ、ＳＩ＞情報を取得することができる。＜ＳＤ、ＢＳＬ、ＳＩ＞情報は、次の機能を有する：ＢＩＥＲパケットヘッダ内のビット文字列の長さをＢＳＬに基づいて取得し、ＢＩＥＲパケットヘッダ全体の長さを学習する。ビット文字列が、１から２５６の範囲のＢＦＲ－ＩＤを表すか又は２５７から５１２の範囲のＢＦＲ－ＩＤを表すかを、ＢＳＬとＳＩに関する情報とに基づいて学習することができる。ＳＤに関する情報に基づいて、対応する転送テーブルを見つけることができる。

（２）ビット文字列（ｂｉｔｓｔｒｉｎｇ）フィールド

ビット文字列内の各ビットは、エッジＢＦＲを識別するために使用され、例えばビット文字列内の下位ビット（右端）のビットは、ＢＦＲ－ＩＤが１に等しいＢＦＥＲを識別するために使用される。ビット文字列内の右から左への第２ビットは、ＢＦＲ－ＩＤが２に等しいＢＦＥＲを識別する。転送プレーンが転送を実行するのに基づく転送エントリについて、パケットが送信されるべきいくつかの特定のＢＦＥＲが、パケット内のビット文字列に基づいて決定される。ＢＩＥＲを含むパケットヘッダを受信すると、ＢＩＥＲドメイン内のＢＦＲは、ＢＩＥＲヘッダ内で担持されるビット文字列とＢＩＦＴＩＤに基づいて、ＢＩＥＲパケットを転送する。

ビットの値１は、ＢＦＲ－ＩＤによって表されるＢＦＥＲデバイスにパケットを送信する必要があることを示し、ビットの値０は、ＢＦＲ－ＩＤによって表されるＢＦＥＲデバイスにパケットを送信する必要がないことを示す。

例えばＢＩＦＴＩＤ＝２。ＢＩＥＲパケットを受信した後、ＢＦＲは、ＢＩＥＲヘッダ内のＢＩＦＴＩＤに基づいて、ＢＩＥＲパケットがＳＤ０に属し、ＢＩＥＲヘッダで使用されるＢＳＬが２５６ビットであり、ＢＩＥＲパケットがセット１（ＢＦＲＩＤが２５７から５１２の範囲の２５６個のエッジＢＦＲを含むセット）に対応することを取得し得る。

（３）プロトコル（ｐｒｏｔｏｃｏｌ、ｐｒｏｔｏ）フィールド

プロトコルフィールドは、ＢＩＥＲパケットヘッダの後にあるペイロード（ｐａｙｌｏａｄ）を識別するために使用される。一例では、ｐｒｏｔｏフィールドの値は、ＢＩＥＲパケットヘッダの後にあるペイロードに対応するプロトコル番号である。

図３は、ＢＩＥＲヘッダの別の可能なフォーマットの概略ブロック図である。図２に示されるＢＩＥＲヘッダフォーマットと比較して、図３に示されるＢＩＥＲヘッダフォーマットはＢＩＦＴ－ＩＤフィールドを含まないが、ＳＤ／ＢＳＬ／ＳＩという３つのフィールドを明示的に含む。言い換えると、図３に示されるＢＩＥＲヘッダフォーマットは、ＳＤ／ＢＳＬ／ＳＩの３つのフィールドを直接含み、ＳＤ／ＢＳＬ／ＳＩの値をＢＩＦＴＩＤフィールドに基づいてマッピングする必要はない。

図４を参照して、ＢＩＥＲｖ４カプセル化を一例として使用することにより、ＢＩＥＲ技術に基づいてＢＩＥＲ転送テーブルを確立してＢＩＥＲパケットを転送するプロセスを以下に詳述する。

図４に示されるＢＩＥＲドメインは、デバイスＡからデバイスＦを含み得る。デバイスＡ、デバイスＤ、デバイスＥ及びデバイスＦは、ＢＩＥＲドメイン内のエッジＢＦＲであり、デバイスＢ及びデバイスＣはＢＩＥＲ中間転送デバイスである。

具体的には、デバイスＡはＢＩＥＲドメインの入口に位置し、元のマルチキャストデータパケットに対してＢＩＥＲカプセル化を実行する役割を担い、図１のＢＦＩＲに対応する。デバイスＤ、デバイスＥ及びデバイスＦはＢＩＥＲドメインの出口に位置し、ＢＩＥＲパケットをカプセル化解除することによって元のマルチキャストデータパケットを取得する役割を担い、図１のＢＦＥＲに対応する。

本出願の実施形態では、一意のＢＦＲ－ＩＤが、ＢＩＥＲドメイン内の各エッジＢＦＲに割り当てられ得る。例えば図４では、デバイスＡ、デバイスＤ、デバイスＥ及びデバイスＦについて構成されるＢＦＲ－ＩＤは、それぞれ４、１、３及び２である。ＢＦＲ－ＩＤは、中間転送ＢＦＲ、例えばデバイスＢ及びデバイスＣには割り当てられない。

本出願の実施形態では、「ＩＤ」と「ｉｄ」が交換されることがあることに留意されたい。差異が強調されないとき、それらの用語によって表される意味は同じであることに留意されたい。本出願におけるＢＦＲ－ＩＤは、図３のｉｄを指すことがある。

データトラフィックのＢＩＥＲヘッダにカプセル化されたビット文字列は、トラフィックのすべての宛先デバイスを識別する。例えばＢＦＲ－ＩＤが１であるデバイスＤに対応するビット文字列は０００１であり、ＢＦＲ－ＩＤが２であるデバイスＦに対応するビット文字列は００１０であり、ＢＦＲ－ＩＤが３であるデバイスＥに対応するビット文字列は０１００であり、ＢＦＲ－ＩＤが４であるデバイスＡに対応するビット文字列は１０００である。

ＢＩＥＲドメイン内の各エッジＢＦＲに割り当てられるＢＦＲ－ＩＤ値は、ルーティングプロトコルに従ってＢＩＥＲドメイン内の別のＢＦＲにフラッディング（flood）されることがあることを理解されたい。フラッディングされたＢＩＥＲ情報は、エッジＢＦＲのＩＰアドレスとカプセル化情報を更に含む。例えばデバイスＡのフラッディングされたＢＩＥＲ情報は、デバイスＡのＩＰアドレスとＢＩＦＴ－ｉｄを担持する。ＢＩＥＲドメイン内のＢＦＲ（例えば図４のデバイスＦ）は、フラッディングされたＢＩＥＲ情報に基づいてＢＩＦＴエントリを確立することができ、その結果、ＢＩＥＲパケットを受信した後、図４のデバイスＦは、確立されたＢＩＦＴエントリに基づいてＢＩＥＲパケットを宛先デバイスに転送する。

デバイスＡが、ＢＩＥＲパケットを、ＢＦＲ－ＩＤがそれぞれ１、２及び３であるＢＦＥＲに送信する必要がある場合、デバイスＡは最初に、ＢＩＥＲパケットをデバイスＡの近傍（デバイスＢ）に送信する必要があり、ここで、ＢＦＲ－ＩＤが４であるエッジＢＦＲがデバイスＡである。したがって、デバイスＡによって確立されるＢＩＦＴエントリは次のとおりである：
転送エントリ１：近傍（ｎｅｉｇｈｂｏｒ、Ｎｂｒ）＝Ｂ、かつ転送ビットマスク（ｆｏｒｗａｒｄｉｎｇｂｉｔｍａｓｋ、ＦＢＭ）＝０１１１；及び
転送エントリ２：Ｎｂｒ*＝Ａ、かつＦＢＭ＝１０００。

転送エントリ１は、ＢＩＥＲパケット内のビット文字列の右から左への第１ビット、第２ビット又は第３ビットのいずれかが１であるとき、ＢＩＥＲパケットがデバイスＡの近傍（デバイスＢ）に送信されることを示し、ここで、Ｎｂｒ＝Ｂは、デバイスＡの近傍がデバイスＢであることを示す。

転送エントリ２は、ＢＩＥＲパケット内のビット文字列の右から左への第４ビットが１であるとき、ＢＩＥＲパケットがデバイスＡに送信されることを示す。この場合、デバイスＡが、デバイスＡの近傍デバイスであり、したがって、デバイスＡはＢＩＥＲヘッダを除去し、元のマルチキャストデータパケット内の情報に基づいて元のマルチキャストデータパケットを転送する。

転送エントリ２では、デバイスのＮｂｒが当該デバイスであることを識別するために*が使用されることに留意されたい。例えばデバイスＡについて、Ｎｂｒ*＝Ａは、デバイスＡの近傍デバイスがデバイスＡであることを示す。同様に、図３の別のデバイスも、当該別のデバイスの近傍デバイスに基づいてＢＩＦＴエントリを確立し得る。当該別のデバイスによって確立されたＢＩＦＴエントリについては、図４を参照されたい。詳細はここでは再度説明されない。

元のマルチキャストデータパケットを受信した後、ＢＩＥＲドメインの入口でＢＦＩＲとして機能するデバイスＡは、元のマルチキャストデータパケットの前にＢＩＥＲヘッダをカプセル化する。説明の容易性のために、デバイスＡは略して入口デバイスＡと称されることを理解されたい。一例では、元のマルチキャストデータパケットを受信した後、入口デバイスＡは、ボーダーゲートウェイプロトコルＢＧＰメッセージでフラッディングされたＢＦＲ－ＩＤに基づいて、元のマルチキャストデータパケットの宛先デバイスを学習し得る。例えば元のマルチキャストデータパケットのレシーバは、ＢＦＲ－ＩＤが３である宛先デバイスＥと、ＢＦＲ－ＩＤが２である宛先デバイスＦと、ＢＦＲ－ＩＤが１である宛先デバイスＤである。入口デバイスＡは、ＢＩＥＲヘッダ内のビット文字列を０１１１としてカプセル化し、カプセル化されたＢＩＥＲパケットを、転送エントリ１に基づいて近傍デバイスＢに転送する。ＢＩＥＲパケットを受信した後、デバイスＢは、ビット文字列０１１１及びＢＩＦＴエントリに基づいて、ＢＩＥＲパケットをデバイスＣ及びデバイスＥに送信する必要があると判断する。デバイスＣにＢＩＥＲパケットを送信するとき、デバイスＢは、ＢＩＥＲヘッダ内のビット文字列（０１１１）と、ＢＩＦＴエントリ内のＮｂｒ＝Ｃに対応するＦＢＭフィールドに対してＡＮＤ演算を実行し得る。本出願のこの実施形態では、ＡＮＤ演算の結果は００１１である。したがって、デバイスＢは、ＢＩＥＲヘッダ内のビット文字列を００１１に修正し、ＢＩＥＲパケットをデバイスＣに送信し得る。同様に、ＢＩＥＲパケットをデバイスＥに送信するとき、デバイスＢは、ＢＩＥＲヘッダ内のビット文字列を０１００に修正し得る。ＢＩＥＲパケットを受信した後、デバイスＥは、ビット文字列０１００に基づいて、ＢＩＥＲパケットを近傍デバイスＥに送信することを決定する。デバイスＥは、転送テーブル内の識別子*に基づいて、近傍デバイスＥがデバイスＥであると決定するので、ＢＩＥＲドメインの出口でＢＦＥＲとして機能するデバイスＥは、ＢＩＥＲパケットから元のマルチキャストデータパケットをカプセル化解除し、内部の元のマルチキャストデータパケット内の情報に基づいて元のマルチキャストデータパケットを転送し得る。

図５を参照して、以下は、ＢＩＥＲｖ６カプセル化を一例として使用することにより、ＢＩＥＲｖ６カプセル化フォーマットとＢＩＥＲパケット転送プロセスを詳述する。

図５は、可能なＢＩＥＲｖ６カプセル化の概略ブロック図である。図５を参照されたい。このようなカプセル化では、ＩＰｖ６ヘッダと、ＢＩＥＲヘッダを含むＩＰｖ６拡張ヘッダとが一緒にＢＩＥＲｖ６ヘッダを構成する。元のマルチキャストデータパケットを外部ＢＩＥＲｖ６ヘッダでカプセル化することによって形成されるパケットは、ＢＩＥＲｖ６パケットと称されることもある、言い換えると、ＢＩＥＲｖ６パケットは、外部ＢＩＥＲｖ６ヘッダと内部マルチキャストデータパケットを含む。

ＢＩＥＲヘッダを含むＩＰｖ６拡張ヘッダは、本出願の実施形態では特に限定されない。例えばＩＰｖ６拡張ヘッダは宛先オプションヘッダ（ｄｅｓｔｉｎａｔｉｏｎｏｐｔｉｏｎｓｈｅａｄｅｒ、ＤＯＨ）であり得る。

外部ＩＰｖ６ヘッダに含まれるフィールドを以下で詳述する。

バージョン（ｖｅｒｓｉｏｎ、Ｖｅｒ）フィールド：バージョンフィールドはＩＰバージョン番号であり、バージョンフィールドの値６はＩＰｖ６を表す。

トラフィッククラス（ｔｒａｆｆｉｃｃｌａｓｓ、ＴＣ）フィールド：トラフィッククラスフィールドはパケットの優先度を識別する。

フローラベル（ｆｌｏｗｌａｂｅｌ、ＦＬ）フィールド：同じフローラベルが、同じトラフィックに属する複数のパケットをラベル付けするために使用されてよく、別のフローラベル値が、異なるトラフィックに属する複数のパケットをラベル付けするために使用される。

ペイロード長（ｐａｙｌｏａｄｌｅｎｇｔｈ、ＰＬ）フィールド：ペイロード長フィールドは、パケットの長さを示す。

ネクストヘッダ（ＮｅｘｔＨｅａｄｅｒ、ＮＨ）フィールド：ネクストヘッダフィールドは、パケットの次のヘッダのタイプを示し、例えばＩＰｖ６拡張ヘッダを表してよい。ＮＨフィールドは、ＮｅｘｔＨｄｒフィールドとして表されてもよい。

ホップリミット（ＨｏｐＬｉｍｉｔ、ＨＬ）フィールド：ホップリミットフィールドは、パケットの量に対する制限を示す。ホップリミットフィールドの値がプリセットされた閾値未満であるとき、ＢＩＥＲパケットを受信したデバイスは、該パケットを転送せず、該パケットを処理のためにコントロールプレーンに送信し得る。

ソースアドレス（ｓｏｕｒｃｅａｄｄｒｅｓｓ、ＳＡ）フィールド：ソースアドレスフィールドは、パケットのソースアドレスを識別する。

宛先アドレス（ｄｅｓｔｉｎａｔｉｏｎａｄｄｒｅｓｓ、ＤＡ）フィールド：宛先アドレスフィールドは、パケットの宛先アドレスを識別する。

ＤＡフィールドは、ネクストホップのＩＰアドレスに継続的に更新される。図３に示されるＢＩＥＲドメインを例として使用する。デバイスＡは、ＩＰｖ６ネットワーク内のヘッドノード（入口デバイス）として使用される。ユーザマルチキャストデータパケットを受信した後、デバイスＡは、ＢＩＥＲｖ６ヘッダの後のパケット、具体的には、外部ＩＰｖ６ヘッダ及びＢＩＥＲヘッダを含むＩＰｖ６拡張ヘッダの後のパケットをカプセル化して、カプセル化されたＢＩＥＲｖ６パケットを取得する。

ＩＰｖ６拡張ヘッダに含まれるＢＩＥＲパケットヘッダは、宛先デバイスのセットを表すビット文字列を担持する。デバイスＡは、ＢＩＥＲパケットヘッダと、該ＢＩＥＲパケットヘッダのビット文字列に関する情報とに基づいて、カプセル化されたＢＩＥＲｖ６パケットをデバイスＢに送信する。送信中、ＩＰｖ６ヘッダ内の宛先アドレスフィールドは、デバイスＢのユニキャストアドレス（例えばＢ：：１００）であり得る。デバイスＢは、ＢＩＥＲパケットヘッダと、該ＢＩＥＲパケットヘッダのビット文字列に関する情報とに基づいて、パケットをデバイスＣ及びデバイスＥに送信する。送信中、ＩＰｖ６ヘッダの宛先アドレスフィールドは、デバイスＣのユニキャストアドレス（例えばＣ：：１００）及びデバイスＥのユニキャストアドレス（例えばＥ：：１００）であり得る。同様に、デバイスＣは、ＢＩＥＲパケットヘッダと、該ＢＩＥＲパケットヘッダのビット文字列に関する情報とに基づいて、パケットをデバイスＤ及びデバイスＦに送信する。送信中、ＩＰｖ６ヘッダの宛先アドレスフィールドは、デバイスＤのユニキャストアドレス（例えばＤ：：１００）及びデバイスＦのユニキャストアドレス（例えばＤ：：１００）であり得る。

運用、管理及び保守（ｏｐｅｒａｔｉｏｎｓ，ａｄｍｉｎｉｓｔｒａｔｉｏｎ，ａｎｄｍａｉｎｔｅｎａｎｃｅ、ＯＡＭ）検出：ネットワーク運用に関するオペレータの実際の要件に基づいて、ネットワーク管理業務は、運用（ｏｐｅｒａｔｉｏｎｓ）、管理（ａｄｍｉｎｉｓｔｒａｔｉｏｎ）及び保守（ｍａｉｎｔｅｎａｎｃｅ）という３つのタイプに分類される。運用は主に、分析、予測、計画及び構成のような、ネットワーク及びサービスにおいて実行される日常作業（daily work）を完了し、保守は主に、ネットワーク及びサービスにおいて実行されるテスト及び障害管理のような日常の運用活動（daily operation activity）である。

既存のＢＩＥＲＯＡＭ解決策は、次のように実装される：ＢＩＥＲヘッダの後に、追加でカプセル化されていないＢＩＥＲＯＡＭ要求パケットが続き、ＢＩＥＲヘッダのＰｒｏｔｏフィールドは、ＢＩＥＲヘッダの後に、追加でカプセル化されていないＢＩＥＲＯＡＭ要求パケットが続くことを示す。ＢＦＩＲは、この方式でＢＩＥＲヘッダの後のＢＩＥＲＯＡＭパケットをカプセル化する役割を担い、カプセル化されたパケットを送信し、ここで、パケットはＢＩＥＲヘッダに基づいて転送される。パケットがＢＦＥＲノードに到達した後、ＢＦＥＲノードは、ＢＩＥＲヘッダ内のＰｒｏｔｏフィールドに基づいてカプセル化されていないＢＩＥＲＯＡＭパケットを識別し、ＢＩＥＲＯＡＭ応答パケットをＢＦＩＥＲに返す。このようにして、ＢＩＥＲＯＡＭ検出が実装される。

しかしながら、前述の技術的解決策では、カプセル化されていないＢＩＥＲＯＡＭパケットは、一部のＢＩＥＲカプセル化シナリオには適用可能ではない。以下にいくつかの可能なシナリオを列挙する。

ＢＩＥＲｖ６カプセル化シナリオを例として使用する。ＢＩＥＲｖ６カプセル化では、ＩＰｖ６ネクストヘッダフィールドの値は、ＢＩＥＲｖ６ヘッダの後にあるパケットのフォーマットを示す。前述の技術的解決策が使用される場合、カプセル化されていないＢＩＥＲＯＡＭパケット又は元のＢＩＥＲＯＡＭパケットにネクストヘッダ値を割り当てる必要がある。しかしながら、利用可能なネクストヘッダ値の量は少なく、取得コストが高い。

ＢＩＥＲ－ＭＰＬＳカプセル化シナリオを例として使用する。ＢＩＥＲ－ＭＰＬＳカプセル化に基づいて、ＢＩＥＲヘッダは「ポップアップ」し得る。前述の技術的解決策の方式を使用する場合、ＢＩＥＲヘッダが「ポップアップ」した後に、ＢＩＥＲＯＡＭパケットが識別されたと判断することができず、したがって、ＢＩＥＲＯＡＭ検出を実装することができない。

したがって、ＢＩＥＲネットワークでＢＩＥＲＯＡＭ検出をどのように実装するかが、解決すべき緊急の問題となる。

この観点から、本出願の実施形態は、ＢＩＥＲＯＡＭ検出方法を提供する。カプセル化されていないＢＩＥＲＯＡＭ又は元のＢＩＥＲＯＡＭはカプセル化されるため、本方法はより多くのＢＩＥＲカプセル化シナリオに適用可能であり、ＢＩＥＲＯＡＭ検出はＢＩＥＲネットワークで実装される。

以下では、図６を参照して、本出願の実施形態で提供されるＢＩＥＲＯＡＭ検出方法を詳述する。

図６は、本出願の一実施形態によるＢＩＥＲＯＡＭ検出方法の概略フローチャートである。図６を参照されたい。本方法は、ステップ６１０及びステップ６２０を含んでよい。以下は、ステップ６１０及びステップ６２０を個別に詳しく説明する。

ステップ６１０：ＢＦＩＲは、第１ＢＩＥＲＯＡＭパケットに基づいて検出要求パケットを取得し、ここで、検出要求パケットは、第１パケットヘッダ及び第１パケットを含み、第１パケットヘッダは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、第１パケットヘッダはビット文字列を含み、ビット文字列は、測定されるべき少なくとも１つのビット転送出口ルータＢＦＥＲを示す。

第１ＢＩＥＲＯＡＭパケットは、カプセル化されていないＢＩＥＲＯＡＭパケット又は元のＢＩＥＲＯＡＭパケットであり得ることを理解されたい。第１ＢＩＥＲＯＡＭパケットは、元のＢＩＥＲＯＡＭパケットとも称されることがある。

検出要求パケットは、ＢＩＥＲトンネルの接続性の検出及びチェックのために使用され得る。具体的には、検出要求パケットに含まれる第１ＢＩＥＲＯＡＭパケットが、ＢＩＥＲトンネルの接続性の検出及びチェックに使用され得る。一例では、第１ＢＩＥＲＯＡＭパケットは、要求／応答（ｒｅｑｕｅｓｔ／ｒｅｐｌｙ、ｒｅｑ／ｒｅｐ）フィールドを含み、ここで、要求フィールドは、要求メッセージのタイプ（メッセージタイプ）を示し、要求フィールドの値１は、カプセル化されたＢＩＥＲパケットがエコー要求タイプ（Echo Request type）のＢＩＥＲＯＡＭパケットであることを示す。応答フィールドは、応答メッセージのタイプを示す。

本出願のこの実施形態では、ＢＦＩＲが第１ＢＩＥＲＯＡＭパケットに基づいて検出要求パケットを取得することは、次のように理解され得る。ＢＦＩＲは、第１ＢＩＥＲＯＡＭパケットをカプセル化して、検出要求パケットを取得する。一例では、カプセル化を通して取得される検出要求パケットは、第１パケットヘッダ及び第１パケットを含み得る。

以下に第１パケットのフォーマットを詳述する。

第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得される複数の第１パケットのフォーマットが存在する。可能な実装では、ユーザデータグラムプロトコル（ｕｓｅｒｄａｔａｇｒａｍｐｒｏｔｏｃｏｌ、ＵＤＰ）カプセル化を第１ＢＩＥＲＯＡＭパケットに対して実行して、第１パケットを取得し得る。別の可能な実装では、代替的にＩＰカプセル化を第１ＢＩＥＲＯＡＭパケットに対して実行して、第１パケットを取得し得る。

ＵＤＰカプセル化は、第１ＢＩＥＲＯＡＭパケットの外部層（outer layer）でＵＤＰヘッダをカプセル化している可能性があることを理解されたい。

さらに、ＩＰカプセル化は、第１ＢＩＥＲＯＡＭパケットの外部層でＩＰヘッダをカプセル化している可能性があり、あるいは第１ＢＩＥＲＯＡＭパケットの外部層でＩＰヘッダ及びＵＤＰヘッダをカプセル化している可能性があることを理解されたい。

以下は、ＩＰカプセル化が第１ＢＩＥＲＯＡＭパケットの外部層でＩＰヘッダのカプセル化である例を使用することにより、検出要求パケットのフォーマットを詳細に説明する。

例えば第１パケットヘッダは、カプセル化がＩＰｖ６カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ６ヘッダ及び第１ＢＩＥＲＯＡＭパケットを含む。

第１ＩＰｖ６ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。具体的には、少なくとも１つのＢＦＥＲによって識別することができる有効なＩＰｖ６アドレスは、０：０：０：０：０：ＦＦＦＦ：７Ｆ００：０／１０４の範囲内の任意のアドレスであり得る。

別の例では、第１パケットヘッダは、カプセル化がＩＰｖ４カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ４ヘッダ及び第１ＢＩＥＲＯＡＭパケットを含む。

第１ＩＰｖ４ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。具体的には、少なくとも１つのＢＦＥＲによって識別することができる有効なＩＰｖ４アドレスは、１２７.０.０.０／８の範囲内の任意のアドレスであり得る。

以下は、ＩＰカプセル化が、第１ＢＩＥＲＯＡＭパケットの外部層でのＩＰヘッダ及びＵＤＰヘッダのカプセル化である例を使用することにより、検出要求パケットのフォーマットを詳細に説明する。

例えば第１パケットヘッダは、カプセル化がＩＰｖ６カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ６ヘッダ、ＵＤＰヘッダ及び第１ＢＩＥＲＯＡＭパケットを含む。

第１ＩＰｖ６ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、ＵＤＰヘッダに含まれる宛先ポートは、検出要求パケットを受信するＢＦＥＲのリスニングポートを示す。

検出要求パケットを受信するＢＦＥＲは、第１パケット内の第１ＩＰｖ６ヘッダの宛先アドレスであって、少なくとも１つのＢＦＥＲ及び検出要求パケットを受信するためのリスニングポートによって識別することができる有効なアドレスである宛先アドレスに基づいて、ＢＩＥＲＯＡＭパケットが、検出要求パケットにカプセル化されたと判断し得ることを理解されたい。このように、ＢＦＥＲは、ＢＩＥＲＯＡＭパケットに基づいて検出応答パケットをＢＦＩＲにフィードバックし得る。

別の例として、第１パケットヘッダは、カプセル化がＩＰｖ４カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ４ヘッダ、ＵＤＰヘッダ及び第１ＢＩＥＲＯＡＭパケットを含む。

第１ＩＰｖ４ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、ＵＤＰヘッダに含まれる宛先ポートは、検出要求パケットを受信するＢＦＥＲのリスニングポートを示す。

検出要求パケットを受信するＢＦＥＲは、第１パケット内の第１ＩＰｖ４ヘッダの宛先アドレスであって、少なくとも１つのＢＦＥＲ及び検出要求パケットを受信するためのリスニングポートによって識別することができる有効なアドレスである宛先アドレスに基づいて、ＢＩＥＲＯＡＭパケットが、検出要求パケットにカプセル化されたと判断し得ることを理解されたい。

以下は第１パケットヘッダのフォーマットを詳しく説明する。

本出願の実施形態では、第１パケットヘッダの多くの実装が存在する。これは、本出願では特に限定されない。ＢＩＥＲｖ６カプセル化を例として使用する。第１パケットヘッダは、ＩＰｖ６カプセル化ＢＩＥＲヘッダ（これはＢＩＥＲｖ６ヘッダとも称されることがあり、外部ＩＰｖ６ヘッダとＩＰｖ６拡張ヘッダを含む）を含み得る。ＢＩＥＲ－ＭＰＬＳカプセル化を例として使用する。第１パケットヘッダは、ＭＰＬＳカプセル化ＢＩＥＲヘッダを含み得る。イーサネットカプセル化を例として使用する。第１パケットヘッダは、イーサネットカプセル化ＢＩＥＲヘッダを含み得る。ＭＰＬＳカプセル化ＢＩＥＲヘッダの具体的なフォーマットについては、前述の説明を参照されたい。詳細については、ここでは再度説明しない。

ステップ６２０：ＢＦＩＲが、検出要求パケットを少なくとも１つのＢＦＥＲに送信する。

ＢＦＩＲによって送信された検出要求パケットを受信した後、少なくとも１つのＢＦＥＲは、検出要求パケットが第１ＢＩＥＲＯＡＭパケットを担持していると判断し、第１ＢＩＥＲＯＡＭパケット内のｒｅｑフィールドに担持される識別子に基づいて、検出要求パケットで担持される第１ＢＩＥＲＯＡＭパケットがＯＡＭ要求パケットであると判断し得る。

少なくとも１つのＢＦＥＲは、ＢＩＥＲＯＡＭヘッダ内のビット文字列に関する情報を、少なくとも１つのＢＦＥＲ上で構成されるＢＦＲ－ｉｄ情報と比較して、ＯＡＭ要求パケットの検出対象が少なくとも１つのＢＦＥＲを含むかどうかを判断する。ビット文字列内の、ＢＦＥＲのＢＦＲ－ｉｄに対応するビットが１である場合、ＢＦＥＲは第２ＢＩＥＲＯＡＭパケットを取得し、第２ＢＩＥＲＯＡＭパケットをカプセル化して検出応答パケットを取得し、検出応答パケットをＢＦＩＲに送信する。

一例では、第２ＢＩＥＲＯＡＭパケットは、ｒｅｐフィールドに担持される識別子に基づいて、第２ＢＩＥＲＯＡＭパケットがＯＡＭ応答パケットであることを示し得る。

検出応答パケットのカプセル化フォーマットは、ＢＦＥＲが検出応答パケットをフィードバックする方式に関連しる。以下はいくつかの可能な実装について詳細に説明する。

可能な実装では、ＢＦＥＲは、ルーティングを通して検出応答パケットをフィードバックする。この実装では、検出応答パケットは第２パケットを含む。第２パケットの複数のフォーマットが存在する。例えばＵＤＰカプセル化を、第２ＢＩＥＲＯＡＭパケットに対して実行して、前述の第２パケットを取得し得る。別の例では、代替的にＩＰカプセル化を第２ＢＩＥＲＯＡＭパケットに対して実行して、第２パケットを取得し得る。具体的なＵＤＰカプセル化及びＩＰカプセル化については、第１パケットの前述の説明を参照されたい。詳細についてはここでは再度説明しない。

別の可能な実装では、ＢＦＥＲは、ＢＩＥＲを通して検出応答パケットをフィードバックする。この実装では、検出応答パケットは、第２パケット及び第２パケットヘッダを含む。ＢＩＥＲｖ６カプセル化を例として使用する。第２パケットヘッダは、ＩＰｖ６カプセル化ＢＩＥＲヘッダ（これはＢＩＥＲｖ６ヘッダとも称されることがあり、外部ＩＰｖ６ヘッダ及びＩＰｖ６拡張ヘッダを含む）を含み得る。ＭＰＬＳカプセル化を例として使用する。第２パケットヘッダは、ＭＰＬＳカプセル化ＢＩＥＲヘッダを含み得る。イーサネットカプセル化を例として使用する。第２パケットヘッダは、イーサネットカプセル化ＢＩＥＲヘッダを含み得る。

前述の技術的解決策では、ＢＩＥＲｖ６カプセル化シナリオでは、ＩＰカプセル化が元のＢＩＥＲＯＡＭに対して実行され、その結果、ＢＩＥＲｖ６ヘッダ内のＩＰｖ６ネクストヘッダフィールドの値は、ＢＩＥＲｖ６ヘッダの後のパケットがＩＰパケットであることを示す。このように、ネクストヘッダ値を、カプセル化されていないＢＩＥＲＯＡＭパケット又は元のＢＩＥＲＯＡＭパケットに割り当てる必要がなく、コストが低い。ＢＩＥＲ－ＭＰＬＳカプセル化シナリオでは、ＩＰカプセル化が元のＢＩＥＲＯＡＭに対して実行される。ＢＩＥＲヘッダが「ポップアップ」する場合であっても、ＢＩＥＲヘッダの後のＢＩＥＲＯＡＭパケットも識別することができる。

以下では、ＢＩＥＲｖ６カプセル化を例として使用して、図４に示されるＢＩＥＲドメインのシナリオを参照して、本出願のこの実施形態で提供される方法のＢＩＥＲＯＡＭ検出方法の具体的な実装プロセスを詳細に説明する。

以下の例は単に、本出願の実施形態を実施例に示される特定の数値又は特定のシナリオに限定するのではなく、当業者が本出願の実施形態を理解するのを助けるように意図されていることを理解されたい。明らかに、当業者は、以下で提供される以下の例に基づいて、様々な均等な修正又は変更を行うことができ、そのような修正及び変更も本出願の実施形態の範囲内にある。

図７は、本出願の実施形態によるＰｉｎｇ検出の概略フローチャートである。図７に示される方法は、ステップ７１０からステップ７６０を含み得る。以下では、ステップ７１０からステップ７６０を個別に説明する。

Ｐｉｎｇ検出は、イニシエータデバイスとレスポンダデバイスが接続されているかどうかを検出するために使用され、接続性検出とも呼ばれることがあることを理解されたい。

ステップ７１０：イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出要求パケットを取得して送信する。

ＢＩＥＲＯＡＭ検出要求パケットは上述の検出要求パケットに対応し得ることを理解されたい。

図４に示されるように、デバイスＡはイニシエータとして機能し、ＢＩＥＲＯＡＭ検出要求パケットを送信するよう構成される。デバイスＢ及びデバイスＣは転送デバイスとして機能し、ＢＩＥＲＯＡＭ検出要求パケットを送信する。デバイスＤ、デバイスＥ及びデバイスＦはレスポンダとして機能し、デバイスＡによって送信されたＢＩＥＲＯＡＭ検出要求パケットを受信し、ＢＩＥＲＯＡＭ検出応答パケットをデバイスＡに送信するよう構成される。

可能な実装では、ＢＩＥＲｖ６カプセル化を例として使用し、ＢＩＥＲＯＡＭ検出要求パケットのフォーマットを図８に示す。図８を参照されたい。ＢＩＥＲＯＡＭ検出要求パケットは、ＩＰｖ６カプセル化ＢＩＥＲヘッダ＋ＩＰｖ６ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭパケットを含み得る。

ＩＰｖ６カプセル化ＢＩＥＲヘッダはＢＩＥＲｖ６ヘッダと称されることがあり、外部ＩＰｖ６ヘッダ及びＩＰｖ６拡張ヘッダを含むことを理解されたい。ＩＰｖ６拡張ヘッダはＢＩＥＲヘッダを含む。ＩＰｖ６カプセル化ＢＩＥＲヘッダの後のＩＰｖ６ヘッダは、内部ＩＰｖ６ヘッダと称されることがある。

ＵＤＰヘッダ＋ＢＩＥＲＯＡＭパケットが、ＵＤＰカプセル化ＢＩＥＲＯＡＭと称されることもあることを更に理解されたい。ＩＰｖ６ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭパケットが、ＩＰカプセル化ＢＩＥＲＯＡＭと称されることもある。

ＵＤＰヘッダはチェックサム（ｃｈｅｃｋｓｕｍ）フィールドを含み、攻撃者がＢＩＥＲパケットを攻撃することを防ぐために、このフィールドが、ＢＩＥＲパケットをチェックするために使用されることに留意されたい。ＵＤＰヘッダ内のチェックサム（ｃｈｅｃｋｓｕｍ）フィールドは、外部ＩＰｖ６ヘッダ内のソースアドレスＳＡと宛先アドレスＤＡに基づいて決定される。ＢＩＥＲｖ６カプセル化では、ＤＡフィールドは、ネクストホップのＩＰアドレスに継続的に更新される。そのため、固定のチェックサム値を、外部ＩＰｖ６ヘッダ内のソースアドレスＳＡと宛先アドレスＤＡに基づいて決定することができない。

したがって、本出願の実施形態におけるＢＩＥＲＯＡＭ検出要求パケットは、２つのＩＰｖ６ヘッダを含み得る。１つは外部ＩＰｖ６ヘッダである。外部ＩＰｖ６ヘッダ内の宛先アドレスＤＡは、ＢＩＥＲ転送のためにネクストホップのＩＰアドレスに継続的に更新される。もう１つは内部ＩＰｖ６ヘッダである。内部ＩＰｖ６ヘッダ内の宛先アドレスＤＡは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

以下では上述の部分について個別に詳述する。

（１）外部ＩＰｖ６ヘッダ

デバイスＡのローカルアドレスは、ソースアドレスＳＡフィールドにカプセル化される。レスポンダに送信される、ネクストホップのＩＰアドレスは、宛先アドレスＤＡフィールドにカプセル化される。ＩＰｖ６拡張ヘッダのプロトコル番号は、ネクストヘッダ（ＮｅｘｔＨｅａｄｅｒ、ＮＨ）フィールドにカプセル化される。例えばＮＨフィールドの値は６０である。

ＤＡフィールドは、ＢＩＥＲ転送プロセスでネクストホップのＩＰアドレスに継続的に更新されることを理解されたい。一例では、デバイスの転送プレーンは、パケットを複製し、ＢＩＥＲヘッダ内のビット文字列、ＳＩ、サブドメインＩＤのような情報に基づいてＢＩＥＲ近傍テーブルをクエリして、ネクストホップのＥｎｄＢｉｅｒＩＰを取得し得る。ＥｎｄＢｉｅｒＩＰは、ネクストホップのＩＰアドレスとして使用されてよく、ＢＩＥＲパケットを解析することができるデバイスのＩＰアドレスを示す。宛先アドレスＤＡフィールドにカプセル化される特定のＩＰアドレスについては、図４の前述の説明を参照されたい。詳細については、ここでは再度説明しない。

Ｐｉｎｇ検出は、イニシエータデバイスとレスポンダデバイスが接続されているかどうかを検出するために使用されることに留意されたい。したがって、ＢＩＥＲＯＡＭ検出要求パケットが、イニシエータからレスポンダに送信される必要がある。外部ＩＰｖ６ヘッダ内のホップリミット（ｈｏｐｌｉｍｉｔ、ＨＬ）フィールドの値が小さい場合、転送デバイスで時間超過が発生する可能性がある。この場合、転送デバイスは、ＢＩＥＲＯＡＭ検出要求パケットをレスポンダに送信しない。したがって、本出願の実施形態では、Ｐｉｎｇ検出中に、ホップリミットホップリミットフィールドの値が大きい値に設定されてよく、その結果、ホップリミット（ｈｏｐｌｉｍｉｔ、ＨＬ）フィールドの値によって引き起こされる転送デバイスの時間超過は発生しない。一例では、ホップリミットフィールドの値は２５５である。

（２）ＩＰｖ６拡張ヘッダ（ＢＩＥＲヘッダを含む）

ネクストヘッダ（ｎｅｘｔｈｅａｄｅｒ、ＮＨ）フィールドの値は、ＩＰｖ６拡張ヘッダの後の異なるタイプのユーザマルチキャストパケットを識別する。例えばネクストヘッダフィールドの値が４である場合、これは、ＩＰｖ６拡張ヘッダの後のパケットがＩＰｖ４パケットであることを示し得る。別の例では、ネクストヘッダフィールドの値が４１である場合、これは、ＩＰｖ６拡張ヘッダの後のパケットがＩＰｖ６パケットであることを示し得る。別の例として、ネクストヘッダフィールドの値が１４３である場合、これは、ＩＰｖ６拡張ヘッダの後のパケットがイーサネット（Ｅｔｈｅｒｎｅｔ）パケットであることを示し得る。

（３）内部ＩＰｖ６ヘッダ

デバイスＡのローカルアドレスは、ソースアドレスＳＡフィールドにカプセル化される。少なくとも１つのＢＦＥＲによって識別することができる有効なＩＰｖ６アドレスは、宛先アドレスＤＡフィールドにカプセル化される。ＩＰｖ６アドレスは、パケットを受信してパケットを転送しないデバイスを示し得る。デバイスは、ルーティングテーブルを検索することによって、パケットをデバイスのコントロールプレーンに送信する必要があることを判断することができ、コントロールプレーンは応答パケットをカプセル化し、デバイスはイニシエータ（デバイスＡ）に応答パケットを送信する。

一例では、宛先アドレスＤＡフィールドにカプセル化されたＩＰｖ６アドレスは、ＩＰｖ６ループバック（ｌｏｏｐｂａｃｋ）アドレス範囲０：０：０：０：０：ＦＦＦＦ：７Ｆ００：０／１０４から選択され得る。

（４）ＵＤＰヘッダ及びＢＩＥＲＯＡＭ

ＵＤＰヘッダは、宛先ポート（ｄｅｓｔｉｎａｔｉｏｎｐｏｒｔ）フィールド、ソースポート（ｓｏｕｒｃｅｐｏｒｔ）フィールド、長さ（ｌｅｎｇｔｈ、Ｌｅｎ）フィールド及びチェックサム（ｃｈｅｃｋｓｕｍ）フィールドを含む。

ＢＩＥＲＯＡＭ検出要求パケットを送信するためにローカルデバイスによって使用されるポート番号は、ソースポート（ｓｏｕｒｃｅｐｏｒｔ）フィールドにカプセル化され、ポート番号はランダムに生成され得る。受信側のＵＤＰリスニングポート番号は、宛先ポート（ｄｅｓｔｉｎａｔｉｏｎｐｏｒｔ）フィールドにカプセル化される。チェックサム（ｃｈｅｃｋｓｕｍ）フィールドの値は、内部ＩＰｖ６ヘッダ内のソースアドレスＳＡフィールド及び宛先アドレスＤＡフィールドの値に基づいて決定される。

チェックサム（ｃｈｅｃｋｓｕｍ）フィールドの値は、受信したＢＩＥＲＯＡＭ検出要求パケットがイニシエータ（デバイスＡ）によって送信され、攻撃又は改ざんされていないことを判断するように、受信したＢＩＥＲＯＡＭ検出要求パケットをチェックするためにレスポンダによって使用されることを理解されたい。具体的には、レスポンダは、受信したＢＩＥＲＯＡＭ検出要求パケットの内部ＩＰｖ６ヘッダ内のソースアドレスＳＡフィールドの値と宛先アドレスＤＡフィールドの値に基づいて、チェックサム値を決定し、チェックサム値をチェックサム（ｃｈｅｃｋｓｕｍ）フィールド内の値と比較し得る。決定されたチェックサム値がチェックサム（ｃｈｅｃｋｓｕｍ）フィールドの値と同じである場合、これはパケットが攻撃又は改ざんされていないと理解され得る。

ＢＩＥＲＯＡＭは、要求／応答（ｒｅｑｕｅｓｔ／ｒｅｐｌｙ、ｒｅｑ／ｒｅｐ）フィールド、プロトコル（ｐｒｏｔｏｃｏｌ、ｐｒｏｔｏ）フィールド、リターンコード（ｒｅｔｕｒｎｃｏｄｅ）フィールド、リターンモード（ｒｅｔｕｒｎｍｏｄｅ）フィールド、送信者のハンドル（ｓｅｎｄｅｒ’ｓｈａｎｄｌｅ）フィールド、シーケンス番号（ｓｅｑｕｅｎｃｅｎｕｍｂｅｒ）フィールド及びＯＡＭデータエリアを含む。

要求フィールドは、要求メッセージのタイプ（メッセージタイプ）を示し、要求フィールドの値１は、カプセル化されたＢＩＥＲパケットがエコー要求タイプのＢＩＥＲＯＡＭパケットであることを示す。応答フィールドは、応答メッセージのタイプを示す。ｐｒｏｔｏフィールドの値は０である。

リターンモード（ｒｅｔｕｒｎｍｏｄｅ）フィールドは、ＢＩＥＲＯＡＭ検出応答パケットを返す方式を示す。一例では、リターンモードフィールドの値が２である場合、レスポンダがルーティングを通してＢＩＥＲＯＡＭ検出応答パケットを返すことを示し、リターンモードフィールドの値が３又は４である場合、レスポンダがＢＩＥＲを通してＢＩＥＲＯＡＭ検出応答パケットを返すことを示す。異なるモードで返される応答パケットのフォーマットは異なる。パケットフォーマットに関する詳細については、以下の説明を参照されたい。詳細はここでは説明されない。

リターンコードフィールドは、レスポンダがフィードバックした検出結果を示す。

送信者のハンドルフィールドは、イニシエータ（デバイスＡ）の識別子を示し、該識別子は、返されたＢＩＥＲＯＡＭ検出応答パケットをイニシエータが受信した後に、イニシエータ（デバイスＡ）によってＢＩＥＲＯＡＭ検出応答パケットをチェックするために使用される。具体的なチェック方法については、以下の説明を参照されたい。詳細はここでは説明しない。

シーケンス番号フィールドの初期値は０であり、シーケンス番号フィールドの値は、要求パケットを送信するたびに１ずつ増加される。シーケンス番号フィールドは、返されたＢＩＥＲＯＡＭ検出応答パケットをイニシエータが受信した後に、イニシエータ（デバイスＡ）によってＢＩＥＲＯＡＭ検出応答パケットをチェックするために使用される。具体的なチェック方法については、以下の説明を参照されたい。詳細はここでは説明しない。

タイプ／長さ／値（ｔｙｐｅ／ｌｅｎｇｔｈ／ｖａｌｕｅ、ＴＬＶ）は、ＯＡＭデータエリアにカプセル化されてよく、ＴＬＶは、イニシエータに関する情報を含み得る。イニシエータに関する情報は、ビット文字列、ＢＳＬ、ＳＩ及びサブドメインＩＤを含み得る。一例では、ＴＬＶは元のＳＩ－ビット文字列（ＯｒｉｇｉｎａｌＳＩ－ＢｉｔＳｔｒｉｎｇ）ＴＬＶであり得る。

ステップ７２０：転送デバイス（デバイスＢ及びデバイスＣ）は、イニシエータ（デバイスＡ）によって送信されたＢＩＥＲＯＡＭ検出要求パケットを受信し、ＢＩＥＲＯＡＭ検出要求パケットをレスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）に転送する。

ＢＩＥＲＯＡＭ検出要求パケットを受信した後、転送デバイス（デバイスＢ及びデバイスＣ）は、ＢＩＥＲＯＡＭ検出要求パケット内のビット文字列に関する情報に基づいて、ＢＩＥＲＯＡＭ検出要求パケットをレスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）に送信し得る。ＢＩＥＲｖ６転送の具体的な実装プロセスについては、図５の説明を参照されたい。詳細はここでは再度説明しない。

ステップ７３０：レスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）は、ＢＩＥＲＯＡＭ検出要求パケットを受信し、ＢＩＥＲＯＡＭ検出応答パケットを取得する。

ＢＩＥＲＯＡＭ検出応答パケットは、上述の検出応答パケットに対応し得る。

可能な実装では、ＢＩＥＲＯＡＭ検出要求パケットを受信した後、レスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）は、ＢＩＥＲＯＡＭ検出要求パケットをデバイスのコントロールプレーンに送信し、コントロールプレーンはＢＩＥＲＯＡＭ検出応答パケットを取得する。

いくつかの実装では、ＢＩＥＲＯＡＭ検出要求パケットを受信する前に、レスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）は各々、ＵＤＰリスニングポートを有効にする必要があり、各々がＵＤＰリスニングポートを通してＢＩＥＲＯＡＭ検出要求パケットを受信する。

説明の容易性のために、以下では、説明のために、デバイスＦがコントロールプレーン上にＢＩＥＲＯＡＭ検出応答パケットを構築する例を使用する。

ＢＩＥＲＯＡＭ検出要求パケットを受信した後、デバイスＦは、転送プレーンにおいて、ＢＩＥＲＯＡＭ検出要求パケット内のビット文字列がデバイスＦにヒット（hit）したかどうかを識別し得る。ビット文字列がデバイスＦにヒットした場合、デバイスＦは内部ＩＰｖ６ヘッダ内の宛先アドレスに基づいて、処理のためにＢＩＥＲＯＡＭ検出要求パケットをコントロールプレーンに送信することを決定し、ＢＩＥＲ転送を実行しない。

具体的には、ＢＩＥＲＯＡＭ検出応答パケットは、コントロールプレーンにおいてカプセル化され得る。コントロールプレーンは、ＢＩＥＲＯＡＭ検出要求パケット内のリターンコードフィールドに基づいて、ＢＩＥＲＯＡＭ検出応答パケットを返すモードを決定し得る。異なるモードで返されるＢＩＥＲＯＡＭ検出応答パケットのフォーマットは異なる。以下では、ＢＩＥＲＯＡＭ検出応答パケットのフォーマットを詳しく説明する。

可能な実装では、コントロールプレーンは、リターンモードフィールドの値３又は４に基づいて、レスポンダが、ＢＩＥＲを通してＢＩＥＲＯＡＭ検出応答パケットを返すことを決定する。この実装では、ＢＩＥＲＯＡＭ検出応答パケットのフォーマットは、ＩＰｖ６カプセル化ＢＩＥＲヘッダ＋ＩＰｖ６ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭパケットである。

外部ＩＰｖ６ヘッダでは、デバイスＦのローカルアドレスが、ソースアドレスＳＡフィールドにカプセル化され、イニシエータ（デバイスＡ）に送信されるネクストホップのＩＰアドレスが宛先アドレスＤＡフィールドにカプセル化される。

内部ＩＰｖ６ヘッダでは、デバイスＦのローカルアドレスが、ソースアドレスＳＡフィールドにカプセル化され、ＢＩＥＲＯＡＭ検出要求パケットの内部ＩＰｖ６ヘッダ内のソースアドレスＳＡフィールド内のアドレスが、宛先アドレスＤＡフィールドにカプセル化される。

ＵＤＰヘッダでは、ローカルＵＤＰリスニングポート番号が、ソースポート（ｓｏｕｒｃｅｐｏｒｔ）フィールドにカプセル化され、ＢＩＥＲＯＡＭ検出要求パケットのソースポート（ｓｏｕｒｃｅｐｏｒｔ）フィールドにカプセル化されたポート番号が、宛先ポート（ｄｅｓｔｉｎａｔｉｏｎｐｏｒｔ）フィールドにカプセル化される。

ＢＩＥＲＯＡＭでは、応答フィールドは応答メッセージのタイプを示す。例えばカプセル化されたＢＩＥＲパケットは、エコー応答タイプのＢＩＥＲＯＡＭパケットである。ハンドルフィールドの値は、ＢＩＥＲＯＡＭ検出要求パケットのハンドルフィールドの値と同じである。シーケンス番号フィールドの値は、ＢＩＥＲＯＡＭ検出要求パケットのシーケンス番号フィールドの値と同じである。リターンコードフィールドは、レスポンダによってフィードバックされた検出結果を示す。

具体的には、デバイスＦは、受信したＢＩＥＲＯＡＭ検出要求パケットをチェックし、チェック結果をリターンコードフィールドにカプセル化し得る。

一例では、デバイスＦは、受信したＢＩＥＲＯＡＭ検出要求パケット内の内部ＩＰｖ６ヘッダ及びＵＤＰヘッダに基づいてチェックサム値を計算し、チェックサム値をＢＩＥＲＯＡＭ検出要求パケットのチェックサムフィールドの値と比較し得る。値が同じである場合、これは、パケットが攻撃又は改ざんされていないと理解され得る。

別の例では、デバイスＦは、ＢＩＥＲＯＡＭ検出要求パケットのビット文字列がノードＦを含むかどうかを更にチェックし得る。例えばビット文字列がノードＦのみを含む場合、リターンコードフィールドの値は３に設定され得る。別の例では、ノードＦがビット文字列内のターゲットＢＦＲのみである場合、リターンコードフィールドの値は４に設定され得る。

別の可能な実装では、コントロールプレーンは、リターンモードフィールドの値２に基づいて、レスポンダが、ＩＰｖ６ルーティングを通してＢＩＥＲＯＡＭ検出応答パケットを返すと判断する。この実装では、ＢＩＥＲＯＡＭ検出応答パケットのフォーマットは、ＩＰｖ６ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭである。

ＩＰｖ６ヘッダでは、デバイスＦのローカルアドレスは、ソースアドレスＳＡフィールドにカプセル化され、イニシエータ（デバイスＡ）のＩＰアドレスは、宛先アドレスＤＡフィールドにカプセル化される。イニシエータ（デバイスＡ）のＩＰアドレスは、ＢＩＥＲＯＡＭ検出要求パケットの内部ＩＰｖ６ヘッダ内のソースＩＰアドレスから取得されてよく、ソースＩＰアドレスはＢＩＥＲＯＡＭ検出応答パケットの宛先ＩＰアドレスとして使用される。他のフィールドのカプセル化については、前述の説明を参照されたい。詳細はここでは再度説明しない。

ステップ７４０：レスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）は、ＢＩＥＲＯＡＭ検出応答パケットを転送デバイス（デバイスＢ及びデバイスＣ）に送信する。

ステップ７５０：転送デバイス（デバイスＢとデバイスＣ）は、ＢＩＥＲＯＡＭ検出応答パケットをイニシエータ（デバイスＡ）に送信する。

ステップ７６０：イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出応答パケットに基づいて、Ｐｉｎｇ検出が成功したかどうかを個別に判断する。

ＢＩＥＲＯＡＭ検出応答パケットを受信した後、イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出応答パケットが有効なパケットであるかどうかを識別し得る。言い換えると、イニシエータ（デバイスＡ）は、受信したＢＩＥＲＯＡＭ検出応答パケットが、送信されたＢＩＥＲＯＡＭ検出要求パケットに対応する応答パケットであるかどうかを判断する必要がある。

一実装では、イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出応答パケット内の宛先ポート（ｄｅｓｔｉｎａｔｉｏｎｐｏｒｔ）フィールドにカプセル化されたポート番号が、ＢＩＥＲＯＡＭ検出要求パケットのソースポート（ｓｏｕｒｃｅｐｏｒｔ）フィールドにカプセル化されたポート番号と一致するかどうかをチェックし得る。ポート番号が一致しない場合、これは、ＢＩＥＲＯＡＭ検出応答パケットが無効なパケットであると理解され得る。

別の実装では、イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出応答パケット内のハンドルフィールドの値が、ＢＩＥＲＯＡＭ検出要求パケット内のハンドルフィールドの値と同じであるかどうかを更にチェックし得る。値が同じである場合、これは、ＢＩＥＲＯＡＭ検出応答パケットが有効なパケットであると理解され得る。

別の実装では、イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出応答パケット内のシーケンス番号フィールドの値が、ＢＩＥＲＯＡＭ検出要求パケット内のシーケンス番号フィールドの値と同じであるかどうかを更にチェックし得る。値が同じである場合、これは、ＢＩＥＲＯＡＭ検出応答パケットが有効なパケットであると理解され得る。

ＢＩＥＲＯＡＭ検出要求パケットを送信した後、イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出応答パケットを受信した後にチェックを実行するように、ソースポート番号、ハンドルフィールドの値、シーケンス番号フィールドの値等を、送信されるＢＩＥＲＯＡＭ検出要求パケットに記録し得る。

ＢＩＥＲＯＡＭ検出応答パケットが有効なパケットであると判断した後、イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出応答パケットに基づいて、Ｐｉｎｇ検出が成功したかどうかを判断し得る。一例として、イニシエータデバイスとレスポンダデバイスとの間の接続性検出は、ＢＩＥＲＯＡＭ検出応答パケット内のリターンコードフィールドに基づいて実装され得る。

具体的には、ＢＩＥＲＯＡＭ検出応答パケット内のリターンコードフィールドの値が３又は４である場合、イニシエータ（デバイスＡ）とレスポンダが接続されていると判断され得る。

任意に、いくつかの実施形態では、イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出応答パケットのリターンコードフィールドに基づいて、受信したＢＩＥＲＯＡＭ検出要求パケットをレスポンダがチェックした結果を更に判断し得る。チェック結果は、例えばパケットが攻撃されたか又は改ざんされたどうかであり得る。

図９は、本出願の一実施形態によるトレース検出の概略フローチャートである。図９に示されるように、本方法はステップ９１０からステップ９３０を含み得る。以下は、ステップ９１０からステップ９３０を個別に詳述する。

トレース検出は、ネットワーク内のデバイスにおいてホップバイホップ（hop-by-hop）検出を実行するために使用されることを理解されたい。

ステップ９１０：イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出要求パケットを取得して送信する。

イニシエータ（デバイスＡ）は、Ｐｉｎｇ検出と同じ方法でＢＩＥＲＯＡＭ検出要求パケットをカプセル化する。図８に示されるように、ＢＩＥＲＯＡＭ検出要求パケットは、ＩＰｖ６カプセル化ＢＩＥＲヘッダ＋ＩＰｖ６ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭパケットを含む。

トレース検出はホップバイホップで行われるため、トレース検出では、ＢＩＥＲＯＡＭ検出要求パケットにおけるホップリミット（ｈｏｐｌｉｍｉｔ、ＨＬ）フィールドの値は１から始まり、送信された要求パケットの量とともに増加することに留意されたい。加えて、トレース検出では、ネクストホップに関するカプセル化された情報、例えばネクストホップのＩＰアドレスに関する情報を取得するために、ダウンストリームマッピング（ｄｏｗｎｓｔｒｅａｍｍａｐｐｉｎｇ）ＴＬＶが、ＢＩＥＲＯＡＭ検出要求パケットのＢＩＥＲＯＡＭの部分に追加される必要がある。

ステップ９２０：転送デバイス（デバイスＢ及びデバイスＣ）又はレスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）は、イニシエータ（デバイスＡ）によって送信されたＢＩＥＲＯＡＭ検出要求パケットを受信して、ＢＩＥＲＯＡＭ検出応答パケットを取得する。

可能な実装では、ＢＩＥＲＯＡＭ検出要求パケットを受信した後、転送デバイス（デバイスＢ及びデバイスＣ）又はレスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）は、ＢＩＥＲＯＡＭ検出要求パケットをデバイスのコントロールプレーンに送信し、コントロールプレーンはＢＩＥＲＯＡＭ検出応答パケットを取得する。説明の簡潔性のために、コントロールプレーンがＢＩＥＲＯＡＭ検出応答パケットを取得する例を以下で説明のために使用する。

トレース検出はホップバイホップで実行され、ＢＩＥＲＯＡＭ検出要求パケットのホップリミット（ｈｏｐｌｉｍｉｔ、ＨＬ）フィールドの値は１から始まり、送信された要求パケットの量とともに増加することを理解されたい。

例えば転送デバイス（デバイスＢ及びデバイスＣ）がＢＩＥＲＯＡＭ検出要求パケットを受信した後、ホップリミット（ｈｏｐｌｉｍｉｔ、ＨＬ）が時間超過を引き起こした場合、転送デバイスは、ＢＩＥＲＯＡＭ検出要求パケットを処理のためにコントロールプレーンに送信し得る。

具体的には、転送デバイス（デバイスＢ及びデバイスＣ）は、コントロールプレーンにおいてＢＩＥＲＯＡＭ検出応答パケットをカプセル化し得る。コントロールプレーンは、ＢＩＥＲＯＡＭ検出要求パケット内のリターンコードフィールドに基づいて、ＢＩＥＲＯＡＭ検出応答パケットを返すモードを決定し得る。異なるモードで返されるＢＩＥＲＯＡＭ検出応答パケットのフォーマットは異なる。詳細については、前述のＰｉｎｇ検出プロセスでカプセル化されたＢＩＥＲＯＡＭ検出応答パケットのフォーマットを参照し、詳細はここでは再度説明しない。

トレース検出では、ＢＩＥＲＯＡＭにおいて、リターンコードフィールドの値が５である場合、ＢＩＥＲＯＡＭ検出要求パケットが成功裏に転送されたことを示すことに留意されたい。イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出応答パケット内のリターンコードフィールドの値５に基づいて、イニシエータ（デバイスＡ）と転送デバイス（デバイスＢ及びデバイスＣ）が接続されていると判断してよく、それによりホップバイホップ検出を実装する。

デバイスＢが例として使用され、トレース検出では、ネクストホップ（例えばデバイスＣ）のＩＰアドレスが、デバイスＢによってイニシエータ（デバイスＡ）に送信されるＢＩＥＲＯＡＭ検出応答パケット内のダウンストリームマッピングＴＬＶにカプセル化され得ることに更に留意されたい。したがって、イニシエータ（デバイスＡ）は、ダウンストリームマッピングＴＬＶに基づいて、デバイスＢのネクストホップ（例えばデバイスＣ）に関する情報を取得し、ＢＩＥＲＯＡＭ検出要求パケットをデバイスＢのネクストホップ（例えばデバイスＣ）に送信し、それにより、イニシエータ（デバイスＡ）とデバイスＣとの間の検出を実装する。

別の例では、レスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）がＢＩＥＲＯＡＭ検出要求パケットを受信した後、ホップリミット（ｈｏｐｌｉｍｉｔ、ＨＬ）が時間超過が引き起こした場合、レスポンダは、ＢＩＥＲＯＡＭ検出要求パケットを処理のためにコントロールプレーンに送信し得る。

具体的には、レスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）は、コントロールプレーンにおいてＢＩＥＲＯＡＭ検出応答パケットをカプセル化し得る。コントロールプレーンは、ＢＩＥＲＯＡＭ検出要求パケット内のリターンコードフィールドに基づいて、ＢＩＥＲＯＡＭ検出応答パケットを返すモードを決定し得る。異なるモードで返されるＢＩＥＲＯＡＭ検出応答パケットのフォーマットは異なる。詳細については、前述のＰｉｎｇ検出プロセスでカプセル化されたＢＩＥＲＯＡＭ検出応答パケットのフォーマットを参照し、詳細はここでは再度説明しない。

レスポンダ（デバイスＤ、デバイスＥ又はデバイスＦ）は、ＢＩＥＲＯＡＭ検出要求パケット内のビット文字列がノードを含むかどうかをチェックし得ることに留意されたい。例えばビット文字列がノードのみを含む場合、リターンコードフィールドの値は３に設定され得る。別の例では、ノードがビット文字列内のターゲットＢＦＲのみである場合、リターンコードフィールドの値は４に設定され得る。

トレース検出では、レスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）は、ＢＩＥＲＯＡＭ検出応答パケット内のダウンストリームマッピングＴＬＶを更新する必要がないことを更に留意されたい。

ステップ９３０：イニシエータ（デバイスＡ）はＢＩＥＲＯＡＭ検出応答パケットを受信し、ＢＩＥＲＯＡＭ検出応答パケットに基づいてトレース検出が成功したかどうかを判断する。

ＢＩＥＲＯＡＭ検出応答パケット内のリターンコードフィールドの値が３又は４である場合、イニシエータ（デバイスＡ）は、すべてのデバイス（例えば転送デバイスとレスポンダ）においてホップバイホップ検出を実行し得る。

具体的には、リターンコードフィールドの値が４である場合、イニシエータ（デバイスＡ）は、ビット文字列内の対応するビットをクリアし、ビット文字列を更新し、ＢＩＥＲＯＡＭ検出応答パケット内のダウンストリームマップ（Downstream Map）ＴＬＶを新しいＢＩＥＲＯＡＭ検出要求パケットにコピーし、ホップリミットに１を追加して、イニシエータが、レスポンダからフィードバックされたすべての応答パケットを受信するまで又はホップリミットが２５５に増加するまで検出を続行し得る。

任意に、本出願の実施形態で提供される方法は、ＩＰｖ４ネットワークベースのＢＩＥＲ－ＭＰＬＳカプセル化又はＢＩＥＲ－ＥＴＨカプセル化のシナリオに更に適用可能であり、ＩＰｖ６ネットワークベースのＢＩＥＲ－ＭＰＬＳカプセル化又はＢＩＥＲ－ＥＴＨカプセル化のシナリオに適用可能であり、あるいはＢＩＥＲｖ６とＢＩＥＲ－ＭＰＬＳ／ＢＩＥＲ－ＥＴＨが一緒に使用されるネットワークに適用可能である。

ＩＰｖ４ネットワークベースのＢＩＥＲ－ＭＰＬＳカプセル化を例として使用し、イニシエータ（デバイスＡ）によって取得される検出要求パケットのフォーマットは、ＭＰＬＳカプセル化ＢＩＥＲヘッダ＋ＩＰｖ４ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭである。ＩＰｖ４ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なＩＰｖ４アドレスである。

ＩＰｖ６ネットワークベースのＢＩＥＲ－ＭＰＬＳカプセル化が例として使用され、イニシエータ（デバイスＡ）によって取得される検出要求パケットのフォーマットは、ＭＰＬＳカプセル化ＢＩＥＲヘッダ＋ＩＰｖ６ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭである。ＩＰｖ６ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なＩＰｖ６アドレスである。

図１０は、本出願の一実施形態による、ＩＰｖ６ネットワークベースのＢＩＥＲ－ＭＰＬＳカプセル化ＢＩＥＲＯＡＭ検出要求パケットのフォーマットの概略図である。図１０に示されるように、ＢＩＥＲＯＡＭ検出要求パケットは、ＭＰＬＳカプセル化ＢＩＥＲヘッダ＋ＩＰカプセル化ＢＩＥＲＯＡＭを含む。

ＩＰｖ６ネットワークベースのＢＩＥＲ－ＭＰＬＳカプセル化が例として使用され、ＩＰカプセル化ＢＩＥＲＯＡＭは、ＩＰｖ６ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭを含む。

ＭＰＬＳカプセル化ＢＩＥＲヘッダは、複数の方式で実装され得る。可能な実装では、ＭＰＬＳカプセル化ＢＩＥＲヘッダはＢＩＥＲヘッダを含み、ここで、ＢＩＥＲヘッダの最初の４バイトが、ＭＰＬＳラベルを担持又は表すために使用される。別の可能な実装では、ＭＰＬＳカプセル化ＢＩＥＲヘッダはＭＰＬＳラベル及びＢＩＥＲヘッダを含む。

ＢＩＥＲヘッダの最初の４バイトは、ＭＰＬＳラベルを担持又は表すために使用される。このＢＩＥＲヘッダは、ＢＩＥＲ－ＭＰＬＳヘッダとも称され得る。

図１０は、ＢＩＥＲヘッダの最初の４バイトがＭＰＬＳラベルを担持又は表すために使用されるケースのみを示している。

以下は、図１０に示されるフォーマットを例として使用して、図１１を参照して、本出願の実施形態で提供される方法の別のＢＩＥＲＯＡＭ検出方法の具体的な実装プロセスを詳細に説明する。

以下の例は、本出願の実施形態を実施例に示される特定の数値又は特定のシナリオに限定するのではなく、当業者が本出願の実施形態を理解するのを助けるように意図されていることを理解されたい。明らかに、当業者は、以下で提供される以下の例に基づいて、様々な均等な修正又は変更を行うことができ、そのような修正及び変更も本出願の実施形態の範囲内にある。

図１１は、本出願の実施形態による別のＰｉｎｇ検出の概略フローチャートである。図１１に示されるように、本方法はステップ１１０からステップ１５０を含み得る。以下は、ステップ１１０からステップ１５０を個別に詳述する。

ステップ１１１０：デバイスＡが、ＢＩＥＲＯＡＭ検出要求パケットをデバイスＢに送信する。

デバイスＡは、ＢＩＥＲＯＡＭパケットをＩＰヘッダにカプセル化してＩＰカプセル化ＢＩＥＲＯＡＭパケットを形成し、ＩＰカプセル化ＢＩＥＲＯＡＭパケットをＢＩＥＲ－ＭＰＬＳヘッダにカプセル化して、形成されたパケットをデバイスＢに送信することができる。図１２は、デバイスＡからデバイスＢに送信されるパケットを示す。

ステップ１１２０：ＢＩＥＲＯＡＭ検出要求パケットを受信した後、デバイスＢが、ＢＩＥＲヘッダに基づいてパケットを転送し、パケットをデバイスＣ及びデバイスＤに送信する。

デバイスＣはＢＩＥＲヘッダを識別することができないデバイスであるので、デバイスＢは、パケットをデバイスＣに送信するときにＢＩＥＲ－ＭＰＬＳヘッダを表示する。ＢＩＥＲ－ＭＰＬＳヘッダがポップアップした後、デバイスＢはＭＰＬＳラベルスタックでカプセル化を実行し、例えばノードＣに到達するためのラベルでカプセル化を実行する。

デバイスＤはＢＩＥＲ－ＭＰＬＳヘッダを識別することができるデバイスであるため、デバイスＢはデバイスＤにパケットを送信するときにＢＩＥＲ－ＭＰＬＳヘッダを表示せず、パケットは引き続きＢＩＥＲ－ＭＰＬＳヘッダを担持する。図１２は、デバイスＢからデバイスＣ及びＤに送信されるパケットを示す。

図１２に示されるデバイスＡ、デバイスＢ、デバイスＣ及びデバイスＤの間でＢＩＥＲマルチキャスト転送エントリを確立するプロセスでは、デバイスＣ及びデバイスＤは別個に、デバイスＢに対して、デバイスＣ又はデバイスＤがＢＩＥＲヘッダを識別することができるかどうかを示すことに留意されたい。デバイスＢのネクストホップデバイスがＢＩＥＲヘッダを識別することができない場合、デバイスＢはパケットをネクストホップデバイスに送信するときにＢＩＥＲ－ＭＰＬＳヘッダを表示する必要がある。デバイスＢのネクストホップデバイスがＢＩＥＲヘッダを識別することができる場合、デバイスＢは、パケットをネクストホップデバイスに送信するときにＢＩＥＲ－ＭＰＬＳヘッダを表示する必要がない。

ステップ１１３０：デバイスＣが、ＢＩＥＲＯＡＭ検出応答パケットをデバイスＡに送信する。

パケットを受信した後、デバイスＣは、ＢＩＥＲＯＡＭ内のビット文字列に関する情報を、デバイスＣにおいて構成されたＢＦＲ－ｉｄ情報と比較して、ＯＡＭパケットの検出対象がデバイスＣを含むかどうかを判断する。ビット文字列内の、デバイスＣのＢＦＲ－ｉｄに対応するビットが１である場合、デバイスＣは、ＢＩＥＲＯＡＭ検出応答パケットをデバイスＡに送信する。

例えばデバイスＣは、ルーティングを通してＢＩＥＲＯＡＭ検出応答パケットをデバイスＡに送信する。ＢＩＥＲＯＡＭ検出応答パケットは、ＢＩＥＲＯＡＭ応答パケットに対してＩＰカプセル化を実行することで取得され得る。ＩＰカプセル化の具体的な説明については、前述の説明を参照されたい。詳細については、ここでは再度説明しない。

ステップ１１４０：デバイスＤが、ＢＩＥＲＯＡＭ検出応答パケットをデバイスＡに送信する。

パケットを受信した後、デバイスＤは、ＢＩＥＲＯＡＭ内のビット文字列に関する情報を、デバイスＤにおいて構成されたＢＦＲ－ｉｄ情報と比較して、ＯＡＭパケットの検出対象がデバイスＤを含むかどうかを判断する。ビット文字列内の、デバイスＤのＢＦＲ－ｉｄに対応するビットが１である場合、デバイスＤは、ＢＩＥＲＯＡＭ検出応答パケットをデバイスＡに送信する。

例えばデバイスＤは、ルーティングを通してＢＩＥＲＯＡＭ検出応答パケットをデバイスＡに送信する。ＢＩＥＲＯＡＭ検出応答パケットは、ＢＩＥＲＯＡＭ応答パケットに対してＩＰカプセル化を実行することによって取得され得る。ＩＰカプセル化の具体的な説明については、前述の説明を参照されたい。詳細については、ここでは再度説明しない。

ステップ１１５０：デバイスＡが、デバイスＣ又はデバイスＤによって送信されたＢＩＥＲＯＡＭ検出応答パケットを受信し、デバイスＣ又はデバイスＤへの接続性を判断し、対応する情報をプリント（print）する。

上述のプロセスのシーケンス番号は、本出願の実施形態における実行シーケンスを意味するものではないことを理解されたい。プロセスの実行シーケンスは、プロセスの機能と内部ロジックに基づいて決定されるべきであり、本出願の実施形態の実装プロセスに対するいかなる限定も構成すべきではない。

上記では、本出願の実施形態で提供されるＢＩＥＲＯＡＭ検出方法を、図１から図１２を参照して詳細に説明している。以下では、本出願の装置の実施形態を、図１３から図１８を参照して詳細に説明する。方法の実施形態の説明は、装置の実施形態の説明と対応することを理解されたい。したがって、詳細に説明されていない部分については、前述の方法の実施形態の説明を参照されたい。

図１３は、本出願の実施形態によるＢＦＩＲ１３００の構造の概略図である。図１３に示されるＢＦＩＲ９００は、前述の実施形態の方法においてＢＦＩＲによって実行される対応するステップを実行し得る。図１３に示されるように、ＢＦＩＲ９００は、処理モジュール９１０及び送信モジュール９２０を含む。

処理モジュール９１０は、第１ＢＩＥＲＯＡＭパケットに基づいて検出要求パケットを取得するように構成され、ここで、検出要求パケットは第１パケット及び第１パケットヘッダを含み、第１パケットは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、第１パケットヘッダは、ビット文字列を含み、ビット文字列は、測定されるべき少なくとも１つのビット転送出口ルータＢＦＥＲを示す。

送信モジュール９２０は、検出要求パケットを少なくとも１つのＢＦＥＲに送信するよう構成される。

任意に、第１パケットヘッダは、カプセル化がＩＰｖ６カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ６ヘッダ及び第１ＢＩＥＲＯＡＭパケットを含み、第１ＩＰｖ６ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

任意に、第１パケットヘッダは、カプセル化がＩＰｖ４カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ４ヘッダ及び第１ＢＩＥＲＯＡＭパケットを含み、第１ＩＰｖ４ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

任意に、第１パケットヘッダは、カプセル化がＩＰｖ６カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ６ヘッダ及びユーザデータグラムプロトコルＵＤＰカプセル化ＢＩＥＲＯＡＭパケットを含み、第１ＩＰｖ６ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、ＵＤＰカプセル化ＢＩＥＲＯＡＭパケットは、ＵＤＰヘッダ及び第１ＢＩＥＲＯＡＭパケットを含み、ＵＤＰヘッダに含まれる宛先ポートは、検出要求パケットを受信するＢＦＥＲのリスニングポートを示す。

任意に、第１パケットヘッダは、カプセル化がＩＰｖ４カプセル化であることを示す第１識別子を含み、第１パケットは、第１ＩＰｖ４ヘッダ及びユーザデータグラムプロトコルＵＤＰカプセル化ＢＩＥＲＯＡＭパケットを含み、第１ＩＰｖ４ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、ＵＤＰカプセル化ＢＩＥＲＯＡＭパケットは、ＵＤＰヘッダ及び第１ＢＩＥＲＯＡＭパケットを含み、ＵＤＰヘッダに含まれる宛先ポートは、検出要求パケットを受信するＢＦＥＲのリスニングポートを示す。

任意に、第１パケットヘッダは、ＩＰｖ６カプセル化ＢＩＥＲヘッダを含み、ＩＰｖ６カプセル化ＢＩＥＲヘッダは、第２ＩＰｖ６ヘッダと、カプセル化がＩＰカプセル化であることを示す第１識別子とを含む。

任意に、第１パケットヘッダは、ＭＰＬＳカプセル化ＢＩＥＲヘッダを含み、ＭＰＬＳカプセル化ＢＩＥＲヘッダは、ＭＰＬＳラベルと、カプセル化がＩＰカプセル化であることを示す第１識別子とを含む。

任意に、第１パケットヘッダは、イーサネットカプセル化ＢＩＥＲヘッダを含み、イーサネットカプセル化ＢＩＥＲヘッダは、カプセル化がＩＰカプセル化であることを示す第１識別子を含む。

任意に、ＢＦＩＲ９００は更に：
少なくとも１つのＢＦＥＲからの検出応答パケットを受信するよう構成される受信モジュール９３０を含み、検出応答パケットは第２パケットを含み、第２パケットは第２ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットである。

任意に、第２パケットは、第３ＩＰｖ６ヘッダ及び第２ＢＩＥＲＡＯＭパケットを含み、第３ＩＰｖ６ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

任意に、第２パケットは、第２ＩＰｖ４ヘッダ及び第２ＢＥＩＲＯＡＭパケットを含み、第２ＩＰｖ４ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

任意に、第２パケットは、第３ＩＰｖ６ヘッダ及びＵＤＰカプセル化ＢＩＥＲＯＡＭパケットを含み、第３ＩＰｖ６ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、ＵＤＰカプセル化ＢＩＥＲＯＡＭパケットは、ＵＤＰヘッダ及び第２ＢＩＥＲＯＡＭパケットを含み、ＵＤＰヘッダに含まれるソースポート番号は、検出要求パケットを受信するＢＦＥＲのリスニングポートを示す。

任意に、第２パケットは、第２ＩＰｖ４ヘッダ及びＵＤＰカプセル化ＢＩＥＲＯＡＭパケットを含み、第２ＩＰｖ４ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、ＵＤＰカプセル化ＢＩＥＲＯＡＭパケットは、ＵＤＰヘッダ及び第２ＢＩＥＲＯＡＭパケットを含み、ＵＤＰヘッダに含まれるソースポート番号は、検出要求パケットを受信するＢＦＥＲのリスニングポートを示す。

任意に、検出応答パケットは、第２パケットヘッダを更に含み、第２パケットヘッダは、カプセル化がＩＰカプセル化であることを示す第２識別子を含む。

任意に、第２パケットヘッダは、ＩＰｖ６カプセル化ＢＩＥＲヘッダを含み、ＩＰｖ６カプセル化ＢＩＥＲヘッダは、第２ＩＰｖ６ヘッダ及び第２識別子を含む。

任意に、第２パケットヘッダは、ＭＰＬＳカプセル化ＢＩＥＲヘッダを含み、ＭＰＬＳカプセル化ＢＩＥＲヘッダは、ＭＰＬＳラベル及び第２識別子を含む。

任意に、第２パケットヘッダは、イーサネットカプセル化ＢＩＥＲヘッダを含み、イーサネットカプセル化ＢＩＥＲヘッダは、第２識別子を含む。

図１４は、本出願の実施形態によるＢＦＥＲ１０００の構造の概略図である。図１４に示されるＢＦＥＲ１０００は、前述の実施形態の方法においてＢＦＥＲによって実行される対応するステップを実行し得る。図１４に示されるように、ＢＦＥＲ１０００は、受信モジュール１０１０、処理モジュール１０２０及び送信モジュール１０３０を含む。

受信モジュール１０１０は、ビット転送入口ルータＢＦＩＲから検出要求パケットを受信するよう構成され、ここで、検出要求パケットは、第１パケット及び第１パケットヘッダを含み、第１パケットは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、第１パケットヘッダは、ビット文字列を含み、ビット文字列は、測定されるべき少なくとも１つのＢＦＥＲを示す。

処理モジュール１０２０は、第１パケット及びビット文字列に基づいて検出応答パケットを取得するよう構成され、ここで、検出応答パケットは第２パケットを含み、第２パケットは、第２ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットである。

送信モジュール１０３０は、検出応答パケットをＢＦＩＲに送信するよう構成される。

任意に、第１パケットヘッダは、ＩＰｖ６カプセル化ＢＩＥＲヘッダを含み、ＩＰｖ６カプセル化ＢＩＥＲヘッダは、第２ＩＰｖ６ヘッダと、カプセル化がＩＰカプセル化であることを示す第１識別子を含む。

任意に、第１パケットヘッダは、ＭＰＬＳカプセル化ＢＩＥＲヘッダを含み、ＭＰＬＳカプセル化ＢＩＥＲヘッダは、ＭＰＬＳラベルと、カプセル化がＩＰカプセル化であることを示す第１識別子を含む。

任意に、検出応答パケットは第２パケットヘッダを更に含み、第２パケットヘッダは、カプセル化がＩＰカプセル化であることを示す第２識別子を含む。

任意に、第２パケットヘッダは、イーサネットカプセル化ＢＩＥＲヘッダを含み、イーサネットカプセル化ＢＩＥＲヘッダは第２識別子を含む。

図１５は、本出願の一実施形態によるＢＦＩＲ２０００のハードウェア構造の概略図である。図１５に示されるＢＦＩＲ２０００は、前述の実施形態の方法においてＢＦＩＲによって実行される対応するステップを実行し得る。

図１５に示されるように、ＢＦＩＲ２０００は、プロセッサ２００１、メモリ２００２、インタフェース２００３及びバス２００４を含む。インタフェース２００３は、無線又は有線で実装されてよく、具体的にはネットワークアダプタであり得る。プロセッサ２００１、メモリ２００２及びインタフェース２００３は、バス２００４を通して接続される。

インタフェース２００３は、特に、トランスミッタ及びレシーバを含んでよく、ＢＦＩＲによって、前述の受信及び送信を実装するために使用される。例えばインタフェース２００３は、少なくとも１つのビット転送出口ルータＢＦＥＲに検出要求パケットを送信する際にＢＦＩＲをサポートするよう構成される。

プロセッサ２００１は、前述の実施形態においてＢＦＩＲによって実行される処理を実行するよう構成される。例えばプロセッサ２００１は、第１ＢＩＥＲＯＡＭパケットに基づいて検出要求パケットを取得するよう構成されるか、かつ／又は本明細書で説明される技術の別のプロセスを実行するよう構成される。メモリ２００２は、オペレーティングシステム２００２１及びアプリケーションプログラム２００２２を含み、プログラム、コード又は命令を記憶するよう構成される。プログラム、コード又は命令を実行するとき、プロセッサ又はハードウェアデバイスは、前述の方法の実施形態におけるＢＦＩＲの処理プロセスを完了し得る。任意に、メモリ２００２は、読取専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）及びランダムアクセスメモリ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ、ＲＡＭ）を含み得る。ＲＯＭは基本入出力システム（ｂａｓｉｃｉｎｐｕｔ／ｏｕｔｐｕｔｓｙｓｔｅｍ、ＢＩＯＳ）又は組込みシステムを含み、ＲＡＭはアプリケーションプログラム及びオペレーティングシステムを含む。ＢＦＩＲ２０００を実行する必要があるとき、ＲＯＭへ組み込まれるＢＩＯＳ又は組込みシステム内のブートローダ起動システムを使用することによって開始され、ＢＦＩＲ２０００を起動して通常の実行状態に入る。通常実行状態に入った後、ＢＦＩＲ２０００はＲＡＭ内のアプリケーションプログラム及びオペレーティングシステムを実行して、方法の実施形態におけるＢＦＩＲ２０００の処理プロセスを完了する。

図１５は単にＢＦＩＲ２０００の単純化された設計を示すものにすぎないことを理解することができる。実際の適用では、ＢＦＩＲは任意の量のインタフェース、プロセッサ又はメモリを含み得る。

図１６は、本出願の実施形態による別のＢＦＩＲ２１００のハードウェア構造の概略図である。図１６に示されるＢＦＩＲ２１００は、前述の実施形態の方法においてＢＦＩＲによって実行される、対応するステップを実行し得る。

図１６に示されるように、ＢＦＩＲ２１００は、主制御ボード２１１０、インタフェースボード２１３０、スイッチングボード２１２０及びインタフェースボード２１４０を含む。主制御ボード２１１０、インタフェースボード２１３０、インタフェースボード２１４０及びスイッチングボード２１２０は、インターワーキングのためにシステムバスを通してプラットフォームバックボードに接続される。主制御ボード２１１０は、システム管理、デバイス保守及びプロトコル処理のような機能を完了するよう構成される。スイッチングボード２１２０は、インタフェースボード間でデータを交換するよう構成される（ここで、インタフェースボードはラインカード又はサービスボードとも称される）。インタフェースボード２１３０及び２１４０は、様々なサービスインタフェース（ＰＯＳインタフェース、ＧＥインタフェース、ＡＴＭインタフェース等）を提供し、かつデータパケットを転送するよう構成される。

インタフェースボード２１３０は、中央処理ユニット２１３１、転送エントリメモリ２１３４、物理インタフェースカード２１３３及びネットワークプロセッサ２１３２を含み得る。中央処理ユニット２１３１は、インタフェースボードを制御及び管理し、かつ主制御ボード上の中央処理ユニットと通信するよう構成される。転送エントリメモリ２１３４は、エントリ、例えば前述のＢＩＦＴを記憶するよう構成される。物理インタフェースカード２１３３は、トラフィックを受信及び送信するよう構成される。

インタフェースボード２１４０における動作は、本出願の本実施形態におけるインタフェースボード２１３０における動作と一致することを理解されたい。簡潔性のために、詳細については再度説明しない。

本実施形態におけるＢＦＩＲ２１００は、上述の方法の実施形態における機能及び／又は様々に実装されるステップに対応し得ることを理解されたい。詳細はここでは再度説明しない。

加えて、１つ以上の主制御ボードが存在してもよいことに留意されたい。複数の主制御ボードがあるとき、主制御ボードはアクティブ主制御ボードとスタンバイ主制御ボードを含み得る。１つ以上のインタフェースボードが存在してもよく、より強力なデータ処理能力を有するＢＦＩＲはより多くのインタフェースボードを有する。また、インタフェースボードに１つ以上の物理インタフェースカードが存在してもよい。スイッチングボードが存在しないこともあり、あるいは１つ以上のスイッチングボードが存在することもある。複数のスイッチングボードが存在するとき、負荷分散と冗長性バックアップが一緒に実装され得る。集中型転送アーキテクチャでは、ＢＦＩＲはスイッチングボードを必要としないことがあり、インタフェースボードが、システム全体のサービスデータを処理する機能を提供する。分散型転送アーキテクチャでは、ＢＦＩＲは、少なくとも１つのスイッチングボードを有し、該スイッチングボードを介して複数のインタフェースボード間でデータを交換することができ、大容量のデータ交換及び処理能力を提供する。したがって、分散型アーキテクチャのＢＦＩＲのデータアクセス及び処理能力は、集中型アーキテクチャのデバイスのものよりも優れている。使用される特定のアーキテクチャは、特定のネットワーク展開シナリオに依存する。これは本明細書では限定されない。

図１７は、本出願の実施形態によるＢＦＥＲ２２００のハードウェア構造の概略図である。図１７に示されるＢＦＥＲ２２００は、前述の実施形態における方法のＢＦＥＲによって実行される対応するステップを実行し得る。

図１７に示されるように、ＢＦＥＲ２２００は、プロセッサ２２０１、メモリ２２０２、インタフェース２２０３及びバス２２０４を含む。インタフェース２２０３は、無線又は有線方式で実装されてよく、具体的にはネットワークアダプタであり得る。プロセッサ２２０１、メモリ２２０２及びインタフェース２２０３は、バス２２０４を通して接続される。

インタフェース２２０３は、特にトランスミッタとレシーバを含んでよく、前述の受信と送信を実装するためにＢＦＥＲによって使用される。例えばインタフェースは、ビット転送入口ルータＢＦＩＲからの検出要求パケットの受信をサポートするよう構成される。別の例として、インタフェース２２０３は、ＢＦＩＲへの検出応答パケットの送信をサポートするよう構成される。

プロセッサ２２０１は、前述の実施形態においてＢＦＥＲによって実行される処理を実行するよう構成される。例えばプロセッサ２２０１は、第１ＢＩＥＲＯＡＭパケットに基づいて検出応答パケットを取得するよう構成され；及び／又は本明細書で説明される技術の別のプロセスを実行するよう構成される。メモリ２２０２は、オペレーティングシステム２２０２１及びアプリケーションプログラム２２０２２を含み、プログラム、コード又は命令を記憶するよう構成される。プログラム、コード又は命令を実行するとき、プロセッサ又はハードウェアデバイスは、前述の方法の実施形態におけるＢＦＥＲの処理プロセスを完了し得る。任意に、メモリ２２０２は、読取専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）及びランダムアクセスメモリ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ、ＲＡＭ）を含み得る。ＲＯＭは基本入出力システム（ｂａｓｉｃｉｎｐｕｔ／ｏｕｔｐｕｔｓｙｓｔｅｍ、ＢＩＯＳ）又は組込みシステムを含み、ＲＡＭはアプリケーションプログラム及びオペレーティングシステムを含む。ＢＦＥＲ２２００が実行する必要があるとき、ＢＦＥＲ２２００は、ＲＯＭへ組み込まれるＢＩＯＳ又は組込みシステム内のブートローダ起動システムを使用することによって開始され、ＢＦＥＲ２２００を起動して通常の実行状態に入る。通常実行状態に入った後、ＢＦＥＲ２２００はＲＡＭ内のアプリケーションプログラム及びオペレーティングシステムを実行して、方法の実施形態におけるＢＦＥＲ２２００の処理プロセスを完了する。

図１７は単にＢＦＥＲ２２００の単純化された設計を示すものにすぎないことを理解することができる。実際の適用では、ＢＦＥＲは任意の量のインタフェース、プロセッサ又はメモリを含み得る。

図１８は、本出願の実施形態による別のＢＦＥＲ２４００のハードウェア構造の概略図である。図１８に示されるＢＦＥＲ２４００は、前述の実施形態の方法においてＢＦＥＲによって実行される、対応するステップを実行し得る。

図１８に示されるように、ＢＦＥＲ２４００は、主制御ボード２４１０、インタフェースボード２４３０、スイッチングボード２４２０及びインタフェースボード２４４０を含む。主制御ボード２４１０、インタフェースボード２４３０、インタフェースボード２４４０及びスイッチングボード２４２０は、インターワーキングのためにシステムバスを通してプラットフォームバックボードに接続される。主制御ボード２４１０は、システム管理、デバイス保守及びプロトコル処理のような機能を完了するよう構成される。スイッチングボード２４２０は、インタフェースボード間でデータを交換するよう構成される（ここで、インタフェースボードはラインカード又はサービスボードとも称される）。インタフェースボード２４３０及び２４４０は、様々なサービスインタフェース（ＰＯＳインタフェース、ＧＥインタフェース、ＡＴＭインタフェース等）を提供し、かつデータパケットを転送するよう構成される。

インタフェースボード２４３０は、中央処理ユニット２４３１、転送エントリメモリ２４３４、物理インタフェースカード２４３３及びネットワークプロセッサ２４３２を含み得る。中央処理ユニット２４３１は、インタフェースボードを制御及び管理し、かつ主制御ボード上の中央処理ユニットと通信するよう構成される。転送エントリメモリ２４３４は、エントリ、例えば前述のＢＩＦＴを記憶するよう構成される。物理インタフェースカード２４３３は、トラフィックを受信及び送信するよう構成される。

インタフェースボード２４４０における動作は、本出願の本実施形態におけるインタフェースボード２４３０における動作と一致することを理解されたい。簡潔性のために、詳細については再度説明しない。本実施形態におけるＢＦＥＲ２４００は、上述の方法の実施形態における機能及び／又は様々に実装されるステップに対応し得ることを理解されたい。詳細はここでは再度説明しない。

加えて、１つ以上の主制御ボードが存在してもよいことに留意されたい。複数の主制御ボードがあるとき、主制御ボードはアクティブ主制御ボードとスタンバイ主制御ボードを含み得る。１つ以上のインタフェースボードが存在してもよく、より強力なデータ処理能力を有するＢＦＥＲはより多くのインタフェースボードを有する。また、インタフェースボードに１つ以上の物理インタフェースカードが存在してもよい。スイッチングボードが存在しないこともあり、あるいは１つ以上のスイッチングボードが存在することもある。複数のスイッチングボードが存在するとき、負荷分散と冗長性バックアップが一緒に実装され得る。集中型転送アーキテクチャでは、ＢＦＥＲはスイッチングボードを必要としないことがあり、インタフェースボードが、システム全体のサービスデータを処理する機能を提供する。分散型転送アーキテクチャでは、ＢＦＥＲは、少なくとも１つのスイッチングボードを有し、該スイッチングボードを介して複数のインタフェースボード間でデータを交換することができ、大容量のデータ交換及び処理能力を提供する。したがって、分散型アーキテクチャのＢＦＥＲのデータアクセス及び処理能力は、集中型アーキテクチャのデバイスのものよりも優れている。使用される特定のアーキテクチャは、特定のネットワーク展開シナリオに依存する。これは本明細書では限定されない。

本出願の一実施形態は、コンピュータ読取可能媒体を更に提供する。コンピュータ読取可能媒体はプログラムコードを記憶する。コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、ＢＦＩＲによって実行される上述の方法を実行できるようになる。コンピュータ読取可能ストレージは、下記のうちの１つ以上：すなわち、読取専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、プログラマブルＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅＲＯＭ、ＰＲＯＭ）、消去可能ＰＲＯＭ（ｅｒａｓａｂｌｅＰＲＯＭ、ＥＰＲＯＭ）、フラッシュメモリ、電気的ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙＥＰＲＯＭ、ＥＥＰＲＯＭ）及びハードドライブ（ｈａｒｄｄｒｉｖｅ）のうちの１つ以上を含むが、これらに限定されない。

本出願の一実施形態は、コンピュータ読取可能媒体を更に提供する。コンピュータ読取可能媒体は、プログラムコードを記憶する。コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、ＢＦＥＲによって実行される上述の方法を実行できるようになる。コンピュータ読取可能ストレージは、下記のうちの１つ以上：すなわち、読取専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、プログラマブルＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅＲＯＭ、ＰＲＯＭ）、消去可能ＰＲＯＭ（ｅｒａｓａｂｌｅＰＲＯＭ、ＥＰＲＯＭ）、フラッシュメモリ、電気的ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙＥＰＲＯＭ、ＥＥＰＲＯＭ）及びハードドライブ（ｈａｒｄｄｒｉｖｅ）のうちの１つ以上を含むが、これらに限定されない。

本出願の一実施形態は、ＢＦＩＲで使用されるチップシステムを更に提供する。チップシステムは、少なくとも１つのプロセッサ、少なくとも１つのメモリ及びインタフェース回路を含む。インタフェース回路は、チップシステムと外部との間の情報交換を担う。少なくとも１つのメモリ、インタフェース回路及び少なくとも１つのプロセッサはラインを通して相互接続される。少なくとも１つのメモリは命令を記憶する。命令は、少なくとも１つのプロセッサによって実行されて、前述の態様の方法におけるＢＦＩＲの動作を実行する。

特定の実装プロセスでは、チップは、中央処理ユニット（ｃｅｎｔｒａｌｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＣＰＵ）、マイクロコントローラユニット（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒｕｎｉｔ、ＭＣＵ）、マイクロ処理ユニット（ｍｉｃｒｏｐｒｏｃｅｓｓｉｎｇｕｎｉｔ、ＭＰＵ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌｓｉｇｎａｌｐｒｏｃｅｓｓｏｒ、ＤＳＰ）、システムオンアチップ（ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ、ＳｏＣ）、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃｉｎｔｅｇｒａｔｅｄｃｉｒｃｕｉｔ、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄｐｒｏｇｒａｍｍａｂｌｅｇａｔｅａｒｒａｙ、ＦＰＧＡ）又はプログラマブルロジックデバイス（ｐｒｏｇｒａｍｍａｂｌｅｌｏｇｉｃｄｅｖｉｃｅ、ＰＬＤ）の形態で実装され得る。

本出願の一実施形態は、ＢＦＥＲで使用される別のチップシステムを更に提供する。チップシステムは、少なくとも１つのプロセッサ、少なくとも１つのメモリ及びインタフェース回路を含む。インタフェース回路は、チップシステムと外部との間の情報交換を担う。少なくとも１つのメモリ、インタフェース回路及び少なくとも１つのプロセッサはラインを通して相互接続される。少なくとも１つのメモリは命令を記憶する。命令は、少なくとも１つのプロセッサによって実行されて、前述の側面の方法におけるＢＦＥＲの動作を実行する。

本出願の一実施形態は、ＢＦＩＲで使用されるコンピュータプログラム製品を更に提供する。コンピュータプログラム製品は一連の命令を含む。命令が実行されると、前述の側面の方法におけるＢＦＩＲの動作が実行される。

本出願の一実施形態は、ＢＦＥＲで使用されるコンピュータプログラム製品を更に提供する。コンピュータプログラム製品は一連の命令を含む。命令が実行されると、前述の側面の方法におけるＢＦＥＲの動作が実行される。

本出願の一実施形態は、前述のＢＦＩＲ及びＢＦＥＲを含むシステムを更に提供する。

当業者は、本明細書において開示される実施形態で説明された実施例を参照して、ユニット及びアルゴリズムステップが、電子ハードウェアによって又はコンピュータソフトウェアと電子ハードウェアの組合せによって実装され得ることを認識し得る。機能がハードウェアによって実行されるかソフトウェアによって実行されるかは、技術的解決策の特定の適用及び設計制約に依存する。当業者は、特定の適用ごとに異なる方法を使用して、説明された機能を実装し得るが、その実装が本出願の範囲を超えるものと解釈されるべきではない。

当業者には、便宜的かつ簡潔な説明の目的のために、前述のシステム、装置及びユニットの詳細な作業プロセスについては、前述の方法の実施形態における対応するプロセスを参照することが明確に理解され得、詳細は本明細書では再度説明されない。

本出願で提供されるいくつかの実施形態では、開示されるシステム、装置及び方法が他の方式で実装されてもよいことを理解されたい。例えば説明される装置の実施形態は単なる例である。例えばユニットへの分割は単なる論理機能分割であり、実際の実装では他の分割であってもよい。例えば複数のユニット又は構成要素が組み合わされるか又は別のシステムに統合されてもよく、あるいは一部の機能が無視されるか又は実行されなくてもよい。加えて、表示又は議論される相互結合又は直接結合又は通信接続は、いくつかのインタフェースを介して実装されてもよい。装置又はユニット間の間接結合又は通信接続は、電子的、機械的又は他の形態で実装されてもよい。

別個の部分として説明されるユニットは、物理的に分離されていても、そうでなくてもよく、ユニットとして表示される部分は、物理的なユニットであっても、そうでなくてもよい、すなわち、１つの場所に配置されてもよく又は複数のネットワークユニットに分散されてもよい。ユニットの一部又はすべては、実施形態における解決策の目的を達成するために、実際の要件に基づいて選択されてよい。

加えて、本出願の実施形態における機能ユニットは、１つの処理ユニットに統合されてもよく、あるいはユニットの各々が物理的に単独で存在してもよく、２つ以上のユニットが１つのユニットに統合されてもよい。

機能がソフトウェア機能ユニットの形態で実装され、独立した製品として販売又は使用されるとき、当該機能は、コンピュータ読取可能記憶媒体に記憶され得る。このような理解に基づき、本質的に本出願の技術的解決策又は従来技術に寄与する部分又は技術的解決策の一部は、ソフトウェア製品の形態で実装され得る。コンピュータソフトウェア製品は記憶媒体に記憶され、コンピュータデバイス（これは、パーソナルコンピュータ、サーバネットワークデバイス等であり得る）に、本出願の実施形態で説明される方法のすべて又は一部のステップを実行するよう指示するためのいくつかの命令を含む。前述の記憶媒体は、プログラムコードを記憶することができる任意の媒体、例えばＵＳＢフラッシュドライブ、取外可能ハードディスク、読取専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、ランダムアクセスメモリ（ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ、ＲＡＭ）、磁気ディスク又は光ディスクを含む。

前述の説明は、単に本出願の特定の実装であるが、本出願の保護範囲はこれに限定されない。本出願において開示される技術的範囲内で当業者によって容易に考え出されるすべての変形及び置換は、本出願の保護範囲に含まれるものとする。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

別の可能な実装では、第２パケットは、第３ＩＰｖ６ヘッダ及び第２ＢＩＥＲＯＡＭパケットを含み、第３ＩＰｖ６ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

別の可能な実装では、第２パケットは、第２ＩＰｖ４ヘッダ及び第２ＢＩＥＲＯＡＭパケットを含み、第２ＩＰｖ４ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

第２の態様によると、ＢＩＥＲＯＡＭ検出方法が提供される。本方法は、ビット転送出口ルータＢＦＥＲが、ビット転送入口ルータＢＦＩＲからの検出要求パケットを受信することを含み、ここで、検出要求パケットは、第１パケット及び第１パケットヘッダを含み、第１パケットは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、第１パケットヘッダはビット文字列を含み、ビット文字列は、測定されるべき少なくとも１つのＢＦＥＲを示す。ＢＦＥＲは、第１パケット及びビット文字列に基づいて検出応答パケットを取得し、ここで、検出応答パケットは第２パケットを含み、第２パケットは、第２ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットである。ＢＦＥＲは、検出応答パケットをＢＦＩＲに送信する。

１つ以上の主制御ボードが存在してもよいことに留意されたい。複数の主制御ボードが存在するとき、主制御ボードは、アクティブ主制御ボードとスタンバイ主制御ボードを含み得る。１つ以上のインタフェースボードが存在してもよく、より強力なデータ処理能力を有するＢＦＩＲは、より多くのインタフェースボードを提供する。また、インタフェースボード上に１つ以上の物理インタフェースカードが存在してもよい。スイッチングボードがなくてもよく、１つ以上のスイッチングボードが存在してもよい。複数のスイッチングボードが存在するとき、負荷分散と冗長性バックアップが一緒に実装され得る。集中型転送アーキテクチャでは、ＢＦＩＲはスイッチングボードを必要としないことがあり、インタフェースボードはシステム全体のサービスデータを処理する機能を提供する。分散型転送アーキテクチャでは、ＢＦＩＲは、少なくとも１つのスイッチングボードを有し、スイッチングボードを介して複数のインタフェースボードの間でデータを交換することができ、大容量のデータ交換と処理能力を提供する。したがって、分散型アーキテクチャのＢＦＩＲのデータアクセス及び処理機能は、集中型アーキテクチャのデバイスのものよりも優れている。使用されるべき特定のアーキテクチャは、特定のネットワーク展開シナリオに依存する。これはここでは限定されない。

第１３の態様によると、コンピュータ読取可能媒体が提供される。コンピュータ読取可能媒体はプログラムコードを記憶する。コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、第１の態様又は第１の態様の可能な実装のいずれか１つによる方法を実行することが可能になる。コンピュータ読取可能媒体は、読取専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、プログラマブルＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅＲＯＭ、ＰＲＯＭ）、消去可能ＰＲＯＭ（ｅｒａｓａｂｌｅＰＲＯＭ、ＥＰＲＯＭ）、フラッシュメモリ、電気的ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙＥＰＲＯＭ、ＥＥＰＲＯＭ）及びハードドライブ（ｈａｒｄｄｒｉｖｅ）のうちの１つ以上を含むが、これらに限定されない。

第１４の態様によると、コンピュータ読取可能媒体が提供される。コンピュータ読取可能媒体はプログラムコードを記憶する。コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、第２の態様又は第２の態様の可能な実装のいずれか１つによる方法を実行することが可能になる。コンピュータ読取可能媒体は、読取専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、プログラマブルＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅＲＯＭ、ＰＲＯＭ）、消去可能ＰＲＯＭ（ｅｒａｓａｂｌｅＰＲＯＭ、ＥＰＲＯＭ）、フラッシュメモリ、電気的ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙＥＰＲＯＭ、ＥＥＰＲＯＭ）及びハードドライブ（ｈａｒｄｄｒｉｖｅ）のうちの１つ以上を含むが、これらに限定されない。

様々なタイプのＢＩＥＲカプセル化が存在し得る。これは、本出願で特に限定されない。一例では、マルチプロトコルラベルスイッチング（ｍｕｌｔｉ－ｐｒｏｔｏｃｏｌｌａｂｅｌｓｗｉｔｃｈｉｎｇ、ＭＰＬＳ）ベースのＢＩＥＲカプセル化が、ＢＩＥＲ－ＭＰＬＳカプセル化と称されることがある。イーサネット（Ｅｔｈｅｒｎｅｔ）ベースのＢＩＥＲカプセル化が、ＢＩＥＲ－ＥＴＨカプセル化と称されることもある。ＢＩＥＲ－ＭＰＬＳカプセル化とＢＩＥＲ－ＥＴＨカプセル化の両方が、ＩＰｖ４又はＩＰｖ６ネットワークに適用され得る。ＢＩＥＲにおけるコントロールプレーンプロトコルは、ＩＰｖ４又はＩＰｖ６に基づいて動作し、ＢＩＥＲにおけるデータパケットのカプセル化と転送は、ＢＩＥＲ－ＭＰＬＳカプセル化又はＢＩＥＲ－ＥＴＨカプセル化に基づく。別の例では、ＢＩＥＲパケットは、インターネットプロトコルバージョン６（Ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌｖｅｒｓｉｏｎ６、ＩＰｖ６）に基づいてカプセル化され、そのようなカプセル化は、ＢＩＥＲｖ６カプセル化と称されることがある。ＢＩＥＲｖ６カプセル化は、一般にＩＰｖ６ネットワークに適用される。ＢＩＥＲにおけるコントロールプレーンプロトコルはＩＰｖ６に基づいて動作し、ＢＩＥＲにおけるデータパケットのカプセル化と転送もＩＰｖ６に基づく。

ＢＩＥＲヘッダ内のフィールドを以下で個別に詳述する。

（１）ＢＩＦＴＩＤフィールド

１．サブドメイン（ｓｕｂ－ｄｏｍａｉｎ、ＳＤ）

３．セット識別子（ｓｅｔｉｄｅｎｔｉｆｉｅｒ、ＳＩ）

（２）ビット文字列（ｂｉｔｓｔｒｉｎｇ）フィールド

本出願の実施形態では、「ＩＤ」と「ｉｄ」が交換されることがあることに留意されたい。差異が強調されないとき、それらの用語によって表される意味は同じであることに留意されたい。本出願におけるＢＦＲ－ＩＤは、図４のｉｄを指すことがある。

ＤＡフィールドは、ネクストホップのＩＰアドレスに継続的に更新される。図３に示されるＢＩＥＲドメインを例として使用する。デバイスＡは、ＩＰｖ６ネットワーク内のヘッドノード（入口デバイス）として使用される。元のマルチキャストデータパケットを受信した後、デバイスＡは、ＢＩＥＲｖ６ヘッダの後のパケット、具体的には、外部ＩＰｖ６ヘッダ及びＢＩＥＲヘッダを含むＩＰｖ６拡張ヘッダの後のパケットをカプセル化して、カプセル化されたＢＩＥＲｖ６パケットを取得する。

ＩＰｖ６拡張ヘッダに含まれるＢＩＥＲパケットヘッダは、宛先デバイスのセットを表すビット文字列を担持する。デバイスＡは、ＢＩＥＲパケットヘッダと、該ＢＩＥＲパケットヘッダのビット文字列に関する情報とに基づいて、カプセル化されたＢＩＥＲｖ６パケットをデバイスＢに送信する。送信中、ＩＰｖ６ヘッダ内の宛先アドレスフィールドは、デバイスＢのユニキャストアドレス（例えばＢ：：１００）であり得る。デバイスＢは、ＢＩＥＲパケットヘッダと、該ＢＩＥＲパケットヘッダのビット文字列に関する情報とに基づいて、パケットをデバイスＣ及びデバイスＥに送信する。送信中、ＩＰｖ６ヘッダの宛先アドレスフィールドは、デバイスＣのユニキャストアドレス（例えばＣ：：１００）及びデバイスＥのユニキャストアドレス（例えばＥ：：１００）であり得る。同様に、デバイスＣは、ＢＩＥＲパケットヘッダと、該ＢＩＥＲパケットヘッダのビット文字列に関する情報とに基づいて、パケットをデバイスＤ及びデバイスＦに送信する。送信中、ＩＰｖ６ヘッダの宛先アドレスフィールドは、デバイスＤのユニキャストアドレス（例えばＤ：：１００）及びデバイスＦのユニキャストアドレス（例えばＦ：：１００）であり得る。

既存のＢＩＥＲＯＡＭ解決策は、次のように実装される：ＢＩＥＲヘッダの後に、追加でカプセル化されていないＢＩＥＲＯＡＭ要求パケットが続き、ＢＩＥＲヘッダのＰｒｏｔｏフィールドは、ＢＩＥＲヘッダの後に、追加でカプセル化されていないＢＩＥＲＯＡＭ要求パケットが続くことを示す。ＢＦＩＲは、この方式でＢＩＥＲヘッダの後のＢＩＥＲＯＡＭパケットをカプセル化する役割を担い、カプセル化されたパケットを送信し、ここで、パケットはＢＩＥＲヘッダに基づいて転送される。パケットがＢＦＥＲノードに到達した後、ＢＦＥＲノードは、ＢＩＥＲヘッダ内のＰｒｏｔｏフィールドに基づいてカプセル化されていないＢＩＥＲＯＡＭパケットを識別し、ＢＩＥＲＯＡＭ応答パケットをＢＦＩＲに返す。このようにして、ＢＩＥＲＯＡＭ検出が実装される。

この観点から、本出願の実施形態は、ＢＩＥＲＯＡＭ検出方法を提供する。カプセル化されていないＢＩＥＲＯＡＭパケット又は元のＢＩＥＲＯＡＭパケットがカプセル化されるため、本方法はより多くのＢＩＥＲカプセル化シナリオに適用可能であり、ＢＩＥＲＯＡＭ検出はＢＩＥＲネットワークで実装される。

ステップ６１０：ＢＦＩＲは、第１ＢＩＥＲＯＡＭパケットに基づいて検出要求パケットを取得し、ここで、検出要求パケットは、第１パケットヘッダ及び第１パケットを含み、第１パケットは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、第１パケットヘッダはビット文字列を含み、ビット文字列は、測定されるべき少なくとも１つのビット転送出口ルータＢＦＥＲを示す。

以下に第１パケットのフォーマットを詳述する。

前述の技術的解決策では、ＢＩＥＲｖ６カプセル化シナリオでは、ＩＰカプセル化が元のＢＩＥＲＯＡＭパケットに対して実行され、その結果、ＢＩＥＲｖ６ヘッダ内のＩＰｖ６ネクストヘッダフィールドの値は、ＢＩＥＲｖ６ヘッダの後のパケットがＩＰパケットであることを示す。このように、ネクストヘッダ値を、カプセル化されていないＢＩＥＲＯＡＭパケット又は元のＢＩＥＲＯＡＭパケットに割り当てる必要がなく、コストが低い。ＢＩＥＲ－ＭＰＬＳカプセル化シナリオでは、ＩＰカプセル化が元のＢＩＥＲＯＡＭパケットに対して実行される。ＢＩＥＲヘッダが「ポップアップ」する場合であっても、ＢＩＥＲヘッダの後のＢＩＥＲＯＡＭパケットも識別することができる。

以下では、ＢＩＥＲｖ６カプセル化を例として使用して、図４に示されるＢＩＥＲドメインのシナリオを参照して、本出願のこの実施形態で提供されるＢＩＥＲＯＡＭ検出方法の具体的な実装プロセスを詳細に説明する。

ＵＤＰヘッダ＋ＢＩＥＲＯＡＭパケットが、ＵＤＰカプセル化ＢＩＥＲＯＡＭパケットと称されることもあることを更に理解されたい。ＩＰｖ６ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭパケットが、ＩＰカプセル化ＢＩＥＲＯＡＭパケットと称されることもある。

以下では上述の部分について個別に詳述する。

（１）外部ＩＰｖ６ヘッダ

Ｐｉｎｇ検出は、イニシエータデバイスとレスポンダデバイスが接続されているかどうかを検出するために使用されることに留意されたい。したがって、ＢＩＥＲＯＡＭ検出要求パケットが、イニシエータからレスポンダに送信される必要がある。外部ＩＰｖ６ヘッダ内のホップリミット（ｈｏｐｌｉｍｉｔ、ＨＬ）フィールドの値が小さい場合、転送デバイスで時間超過が発生する可能性がある。この場合、転送デバイスは、ＢＩＥＲＯＡＭ検出要求パケットをレスポンダに送信しない。したがって、本出願の実施形態では、Ｐｉｎｇ検出中に、ホップリミットフィールドの値が大きい値に設定されてよく、その結果、時間超過はパケット転送中に発生しない。一例では、ホップリミットフィールドの値は２５５である。

（２）ＩＰｖ６拡張ヘッダ（ＢＩＥＲヘッダを含む）

（３）内部ＩＰｖ６ヘッダ

（４）ＵＤＰヘッダ及びＢＩＥＲＯＡＭパケット

ＢＩＥＲＯＡＭパケットは、要求／応答（ｒｅｑｕｅｓｔ／ｒｅｐｌｙ、ｒｅｑ／ｒｅｐ）フィールド、プロトコル（ｐｒｏｔｏｃｏｌ、ｐｒｏｔｏ）フィールド、リターンコード（ｒｅｔｕｒｎｃｏｄｅ）フィールド、リターンモード（ｒｅｔｕｒｎｍｏｄｅ）フィールド、送信者のハンドル（ｓｅｎｄｅｒ’ｓｈａｎｄｌｅ）フィールド、シーケンス番号（ｓｅｑｕｅｎｃｅｎｕｍｂｅｒ）フィールド及びＯＡＭデータエリアを含む。

具体的には、ＢＩＥＲＯＡＭ検出応答パケットは、コントロールプレーンにおいてカプセル化され得る。コントロールプレーンは、ＢＩＥＲＯＡＭ検出要求パケット内のリターンモードフィールドに基づいて、ＢＩＥＲＯＡＭ検出応答パケットを返すモードを決定し得る。異なるモードで返されるＢＩＥＲＯＡＭ検出応答パケットのフォーマットは異なる。以下では、ＢＩＥＲＯＡＭ検出応答パケットのフォーマットを詳しく説明する。

ＢＩＥＲＯＡＭパケットでは、応答フィールドは応答メッセージのタイプを示す。例えばカプセル化されたＢＩＥＲパケットは、エコー応答タイプのＢＩＥＲＯＡＭパケットである。ハンドルフィールドの値は、ＢＩＥＲＯＡＭ検出要求パケットのハンドルフィールドの値と同じである。シーケンス番号フィールドの値は、ＢＩＥＲＯＡＭ検出要求パケットのシーケンス番号フィールドの値と同じである。リターンコードフィールドは、レスポンダによってフィードバックされた検出結果を示す。

別の例では、デバイスＦは、ＢＩＥＲＯＡＭ検出要求パケットのビット文字列に対応するデバイスが、ノードＦを含むかどうかを更にチェックし得る。例えばビット文字列に対応するデバイスがノードＦのみを含む場合、リターンコードフィールドの値は３に設定され得る。別の例では、ノードＦがビット文字列に対応するデバイスのターゲットＢＦＲのみである場合、リターンコードフィールドの値は４に設定され得る。

別の可能な実装では、コントロールプレーンは、リターンモードフィールドの値２に基づいて、レスポンダが、ＩＰｖ６ルーティングを通してＢＩＥＲＯＡＭ検出応答パケットを返すと判断する。この実装では、ＢＩＥＲＯＡＭ検出応答パケットのフォーマットは、ＩＰｖ６ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭパケットである。

例えば転送デバイス（デバイスＢ及びデバイスＣ）がＢＩＥＲＯＡＭ検出要求パケットを受信した後、時間超過はパケット転送中に発生せず、転送デバイスは、ＢＩＥＲＯＡＭ検出要求パケットを処理のためにコントロールプレーンに送信し得る。

具体的には、転送デバイス（デバイスＢ及びデバイスＣ）は、コントロールプレーンにおいてＢＩＥＲＯＡＭ検出応答パケットをカプセル化し得る。コントロールプレーンは、ＢＩＥＲＯＡＭ検出要求パケット内のリターンモードフィールドに基づいて、ＢＩＥＲＯＡＭ検出応答パケットを返すモードを決定し得る。異なるモードで返されるＢＩＥＲＯＡＭ検出応答パケットのフォーマットは異なる。詳細については、前述のＰｉｎｇ検出プロセスでカプセル化されたＢＩＥＲＯＡＭ検出応答パケットのフォーマットを参照し、詳細はここでは再度説明しない。

トレース検出では、ＢＩＥＲＯＡＭパケットにおいて、リターンコードフィールドの値が５である場合、ＢＩＥＲＯＡＭ検出要求パケットが成功裏に転送されたことを示すことに留意されたい。イニシエータ（デバイスＡ）は、ＢＩＥＲＯＡＭ検出応答パケット内のリターンコードフィールドの値５に基づいて、イニシエータ（デバイスＡ）と転送デバイス（デバイスＢ及びデバイスＣ）が接続されていると判断してよく、それによりホップバイホップ検出を実装する。

別の例では、レスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）がＢＩＥＲＯＡＭ検出要求パケットを受信した後、時間超過はパケット転送中に発生せず、レスポンダは、ＢＩＥＲＯＡＭ検出要求パケットを処理のためにコントロールプレーンに送信し得る。

具体的には、レスポンダ（デバイスＤ、デバイスＥ及びデバイスＦ）は、コントロールプレーンにおいてＢＩＥＲＯＡＭ検出応答パケットをカプセル化し得る。コントロールプレーンは、ＢＩＥＲＯＡＭ検出要求パケット内のリターンモードフィールドに基づいて、ＢＩＥＲＯＡＭ検出応答パケットを返すモードを決定し得る。異なるモードで返されるＢＩＥＲＯＡＭ検出応答パケットのフォーマットは異なる。詳細については、前述のＰｉｎｇ検出プロセスでカプセル化されたＢＩＥＲＯＡＭ検出応答パケットのフォーマットを参照し、詳細はここでは再度説明しない。

ＩＰｖ４ネットワークベースのＢＩＥＲ－ＭＰＬＳカプセル化を例として使用し、イニシエータ（デバイスＡ）によって取得される検出要求パケットのフォーマットは、ＭＰＬＳカプセル化ＢＩＥＲヘッダ＋ＩＰｖ４ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭパケットである。ＩＰｖ４ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なＩＰｖ４アドレスである。

ＩＰｖ６ネットワークベースのＢＩＥＲ－ＭＰＬＳカプセル化が例として使用され、イニシエータ（デバイスＡ）によって取得される検出要求パケットのフォーマットは、ＭＰＬＳカプセル化ＢＩＥＲヘッダ＋ＩＰｖ６ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭパケットである。ＩＰｖ６ヘッダの宛先アドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なＩＰｖ６アドレスである。

ＩＰｖ６ネットワークベースのＢＩＥＲ－ＭＰＬＳカプセル化が例として使用され、ＩＰカプセル化ＢＩＥＲＯＡＭパケットは、ＩＰｖ６ヘッダ＋ＵＤＰヘッダ＋ＢＩＥＲＯＡＭパケットを含む。

図１１は、本出願の実施形態による別のＰｉｎｇ検出の概略フローチャートである。図１１に示されるように、本方法はステップ１１１０からステップ１１５０を含み得る。以下は、ステップ１１１０からステップ１１５０を個別に詳述する。

デバイスＡは、ＢＩＥＲＯＡＭパケットをＩＰパケットにカプセル化してＩＰカプセル化ＢＩＥＲＯＡＭパケットを形成し、ＩＰカプセル化ＢＩＥＲＯＡＭパケットをＢＩＥＲ－ＭＰＬＳパケットにカプセル化して、形成されたパケットをデバイスＢに送信することができる。図１２は、デバイスＡからデバイスＢに送信されるパケットを示す。

パケットを受信した後、デバイスＣは、ＢＩＥＲＯＡＭパケット内のビット文字列に関する情報を、デバイスＣにおいて構成されたＢＦＲ－ｉｄ情報と比較して、ＯＡＭパケットの検出対象がデバイスＣを含むかどうかを判断する。ビット文字列内の、デバイスＣのＢＦＲ－ｉｄに対応するビットが１である場合、デバイスＣは、ＢＩＥＲＯＡＭ検出応答パケットをデバイスＡに送信する。

パケットを受信した後、デバイスＤは、ＢＩＥＲＯＡＭパケット内のビット文字列に関する情報を、デバイスＤにおいて構成されたＢＦＲ－ｉｄ情報と比較して、ＯＡＭパケットの検出対象がデバイスＤを含むかどうかを判断する。ビット文字列内の、デバイスＤのＢＦＲ－ｉｄに対応するビットが１である場合、デバイスＤは、ＢＩＥＲＯＡＭ検出応答パケットをデバイスＡに送信する。

図１３は、本出願の実施形態によるＢＦＩＲ９００の構造の概略図である。図１３に示されるＢＦＩＲ９００は、前述の実施形態の方法においてＢＦＩＲによって実行される対応するステップを実行し得る。図１３に示されるように、ＢＦＩＲ９００は、処理モジュール９１０及び送信モジュール９２０を含む。

任意に、第２パケットは、第３ＩＰｖ６ヘッダ及び第２ＢＩＥＲＯＡＭパケットを含み、第３ＩＰｖ６ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

任意に、第２パケットは、第２ＩＰｖ４ヘッダ及び第２ＢＩＥＲＯＡＭパケットを含み、第２ＩＰｖ４ヘッダのソースアドレスは、少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである。

インタフェースボード２１３０は、中央処理ユニット２１３１、転送エントリメモリ２１３４、物理インタフェースカード２１３３及びネットワークプロセッサ２１３２を含み得る。中央処理ユニット２１３１は、インタフェースボードを制御及び管理し、かつ主制御ボード上の中央処理ユニットと通信するよう構成される。転送エントリメモリ２１３４は、エントリ、例えば前述のＢＩＦＴエントリを記憶するよう構成される。物理インタフェースカード２１３３は、トラフィックを受信及び送信するよう構成される。

本出願の一実施形態は、コンピュータ読取可能媒体を更に提供する。コンピュータ読取可能媒体はプログラムコードを記憶する。コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、ＢＦＩＲによって実行される上述の方法を実行できるようになる。コンピュータ読取可能媒体は、下記のうちの１つ以上：すなわち、読取専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、プログラマブルＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅＲＯＭ、ＰＲＯＭ）、消去可能ＰＲＯＭ（ｅｒａｓａｂｌｅＰＲＯＭ、ＥＰＲＯＭ）、フラッシュメモリ、電気的ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙＥＰＲＯＭ、ＥＥＰＲＯＭ）及びハードドライブ（ｈａｒｄｄｒｉｖｅ）のうちの１つ以上を含むが、これらに限定されない。

本出願の一実施形態は、コンピュータ読取可能媒体を更に提供する。コンピュータ読取可能媒体は、プログラムコードを記憶する。コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、ＢＦＥＲによって実行される上述の方法を実行できるようになる。コンピュータ読取可能媒体は、下記のうちの１つ以上：すなわち、読取専用メモリ（ｒｅａｄ－ｏｎｌｙｍｅｍｏｒｙ、ＲＯＭ）、プログラマブルＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅＲＯＭ、ＰＲＯＭ）、消去可能ＰＲＯＭ（ｅｒａｓａｂｌｅＰＲＯＭ、ＥＰＲＯＭ）、フラッシュメモリ、電気的ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙＥＰＲＯＭ、ＥＥＰＲＯＭ）及びハードドライブ（ｈａｒｄｄｒｉｖｅ）のうちの１つ以上を含むが、これらに限定されない。

Claims

ビットインデックス明示複製の運用、管理及び保守ＢＩＥＲＯＡＭ検出方法であって、当該方法は、
ビット転送入口ルータＢＦＩＲによって、第１ＢＩＥＲＯＡＭパケットに基づいて検出要求パケットを取得するステップであって、前記検出要求パケットは、第１パケット及び第１パケットヘッダを含み、前記第１パケットは、前記第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、前記第１パケットヘッダはビット文字列を含み、前記ビット文字列は、測定されるべき少なくとも１つのビット転送出口ルータＢＦＥＲを示す、ステップと、
前記ＢＦＩＲによって、前記少なくとも１つのＢＦＥＲに前記検出要求パケットを送信するステップと、
を含む、方法。
前記第１パケットヘッダは、前記カプセル化がインターネットプロトコルＩＰカプセル化であることを示す第１識別子を含み、前記第１パケットは、第１ＩＰヘッダ及び前記第１ＢＩＥＲＯＡＭパケットを含み、前記第１ＩＰヘッダの宛先アドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである、
請求項１に記載の方法。
前記第１パケットヘッダは、前記カプセル化がＩＰカプセル化であることを示す第１識別子を含み、前記第１パケットは、第１ＩＰヘッダ、第１ユーザデータグラムプロトコルＵＤＰヘッダ及び前記第１ＢＩＥＲＯＡＭパケットを含み、前記第１ＩＰヘッダの宛先アドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、前記第１ＵＤＰヘッダに含まれる宛先ポートは、前記検出要求パケットを受信する前記ＢＦＥＲのリスニングポートを示す、
請求項１に記載の方法。
前記第１パケットヘッダが、インターネットプロトコルバージョン６ＩＰｖ６カプセル化ＢＩＥＲヘッダを含み、該ＩＰｖ６カプセル化ＢＩＥＲヘッダが、ＩＰｖ６ヘッダと、前記カプセル化がＩＰカプセル化であることを示す第１識別子とを含むか、
前記第１パケットヘッダが、マルチプロトコルラベルスイッチングＭＰＬＳカプセル化ＢＩＥＲヘッダを含み、該ＭＰＬＳカプセル化ＢＩＥＲヘッダが、ＭＰＬＳラベルと、前記カプセル化がＩＰカプセル化であることを示す第１識別子とを含むか、又は
前記第１パケットヘッダが、イーサネット（登録商標）カプセル化ＢＩＥＲヘッダを含み、該イーサネットカプセル化ＢＩＥＲヘッダが、前記カプセル化がＩＰカプセル化であることを示す第１識別子を含む、
請求項１乃至３のいずれか一項に記載の方法。
前記ＩＰカプセル化がＩＰｖ６カプセル化であり、第１ＩＰヘッダがＩＰｖ６ヘッダであるか、又は
前記ＩＰカプセル化がインターネットプロトコルバージョン４ＩＰｖ４カプセル化であり、第１ＩＰヘッダがＩＰｖ４ヘッダである、
請求項２乃至４のいずれか一項に記載の方法。
当該方法は、
前記ＢＦＩＲによって、前記少なくとも１つのＢＦＥＲから検出応答パケットを受信するステップを更に含み、前記検出応答パケットは第２パケットを含み、前記第２パケットは、第２ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットである、
請求項１乃至５のいずれか一項に記載の方法。
前記第２パケットは、第２ＩＰヘッダ及び前記第２ＢＩＥＲＡＯＭパケットを含み、前記第２ＩＰヘッダのソースアドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである、
請求項６に記載の方法。
前記第２パケットは、第２ＩＰヘッダ、第２ＵＤＰヘッダ及び前記第２ＢＩＥＲＯＡＭパケットを含み、前記第２ＩＰヘッダのソースアドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、前記第２ＵＤＰヘッダに含まれるソースポート番号は、前記検出要求パケットを受信する前記ＢＦＥＲのリスニングポートを示す、
請求項６に記載の方法。
ビットインデックス明示複製の運用、管理及び保守ＢＩＥＲＯＡＭ検出方法であって、当該方法は、
ビット転送出口ルータＢＦＥＲによって、ビット転送入口ルータＢＦＩＲから検出要求パケットを受信するステップであって、前記検出要求パケットは、第１パケット及び第１パケットヘッダを含み、前記第１パケットは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、前記第１パケットヘッダはビット文字列を含み、前記ビット文字列は、測定されるべき少なくとも１つのＢＦＥＲを示す、ステップと、
第１ＢＦＥＲによって、前記第１パケット及び前記ビット文字列に基づいて検出応答パケットを取得するステップであって、前記検出応答パケットは第２パケットを含み、前記第２パケットは第２ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットである、ステップと、
前記第１ＢＦＥＲによって、前記検出応答パケットを前記ＢＦＩＲに送信するステップと、
を含む、方法。
前記第１パケットヘッダは、前記カプセル化がインターネットプロトコルＩＰカプセル化であることを示す第１識別子を含み、前記第１パケットは、第１ＩＰヘッダ及び前記第１ＢＩＥＲＯＡＭパケットを含み、前記第１ＩＰヘッダの宛先アドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである、
請求項９に記載の方法。
前記第１パケットヘッダは、前記カプセル化がＩＰカプセル化であることを示す第１識別子を含み、前記第１パケットは、第１ＩＰヘッダ、第１ユーザデータグラムプロトコルＵＤＰヘッダ及び前記第１ＢＩＥＲＯＡＭパケットを含み、前記第１ＩＰヘッダの宛先アドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、前記第１ＵＤＰヘッダに含まれる宛先ポートは、前記検出要求パケットを受信する前記ＢＦＥＲのリスニングポートを示す、
請求項９に記載の方法。
前記第１パケットヘッダが、インターネットプロトコルバージョン６ＩＰｖ６カプセル化ＢＩＥＲヘッダを含み、該ＩＰｖ６カプセル化ＢＩＥＲヘッダが、ＩＰｖ６ヘッダと、前記カプセル化がＩＰカプセル化であることを示す第１識別子とを含むか、
前記第１パケットヘッダが、マルチプロトコルラベルスイッチングＭＰＬＳカプセル化ＢＩＥＲヘッダを含み、該ＭＰＬＳカプセル化ＢＩＥＲヘッダが、ＭＰＬＳラベルと、前記カプセル化がＩＰカプセル化であることを示す第１識別子とを含むか、又は
前記第１パケットヘッダが、イーサネットカプセル化ＢＩＥＲヘッダを含み、該イーサネットカプセル化ＢＩＥＲヘッダが、前記カプセル化がＩＰカプセル化であることを示す第１識別子を含む、
請求項９乃至１１のいずれか一項に記載の方法。
前記ＩＰカプセル化がＩＰｖ６カプセル化であり、第１ＩＰヘッダがＩＰｖ６ヘッダであるか、又は
前記ＩＰカプセル化がインターネットプロトコルバージョン４ＩＰｖ４カプセル化であり、第１ＩＰヘッダがＩＰｖ４ヘッダである、
請求項１０乃至１２のいずれか一項に記載の方法。
前記第２パケットは、第２ＩＰヘッダ及び前記第２ＢＩＥＲＡＯＭパケットを含み、前記第２ＩＰヘッダのソースアドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである、
請求項９乃至１３のいずれか一項に記載の方法。
前記第２パケットは、第２ＩＰヘッダ、第２ＵＤＰヘッダ及び前記第２ＢＩＥＲＯＡＭパケットを含み、前記第２ＩＰヘッダのソースアドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、前記第２ＵＤＰヘッダに含まれるソースポート番号は、前記検出要求パケットを受信する前記ＢＦＥＲのリスニングポートを示す、
請求項９乃至１３のいずれか一項に記載の方法。
ビット転送入口ルータＢＦＩＲであって、
第１ＢＩＥＲＯＡＭパケットに基づいて検出要求パケットを取得するよう構成される処理モジュールであって、前記検出要求パケットは、第１パケット及び第１パケットヘッダを含み、前記第１パケットは、前記第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、前記第１パケットヘッダはビット文字列を含み、前記ビット文字列は、測定されるべき少なくとも１つのビット転送出口ルータＢＦＥＲを示す、処理モジュールと、
前記検出要求パケットを前記少なくとも１つのＢＦＥＲに送信するよう構成される送信モジュールと、
を含む、ＢＦＩＲ。
前記第１パケットヘッダは、前記カプセル化がインターネットプロトコルＩＰカプセル化であることを示す第１識別子を含み、前記第１パケットは、第１ＩＰヘッダ及び前記第１ＢＩＥＲＯＡＭパケットを含み、前記第１ＩＰヘッダの宛先アドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである、
請求項１６に記載のＢＦＩＲ。
前記第１パケットヘッダは、前記カプセル化がＩＰカプセル化であることを示す第１識別子を含み、前記第１パケットは、第１ＩＰヘッダ、第１ユーザデータグラムプロトコルＵＤＰヘッダ及び前記第１ＢＩＥＲＯＡＭパケットを含み、前記第１ＩＰヘッダの宛先アドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、前記第１ＵＤＰヘッダに含まれる宛先ポートは、前記検出要求パケットを受信する前記ＢＦＥＲのリスニングポートを示す、
請求項１６に記載のＢＦＩＲ。
前記第１パケットヘッダが、インターネットプロトコルバージョン６ＩＰｖ６カプセル化ＢＩＥＲヘッダを含み、該ＩＰｖ６カプセル化ＢＩＥＲヘッダが、ＩＰｖ６ヘッダと、前記カプセル化がＩＰカプセル化であることを示す第１識別子とを含むか、
前記第１パケットヘッダが、マルチプロトコルラベルスイッチングＭＰＬＳカプセル化ＢＩＥＲヘッダを含み、該ＭＰＬＳカプセル化ＢＩＥＲヘッダが、ＭＰＬＳラベルと、前記カプセル化がＩＰカプセル化であることを示す第１識別子とを含むか、又は
前記第１パケットヘッダが、イーサネットカプセル化ＢＩＥＲヘッダを含み、該イーサネットカプセル化ＢＩＥＲヘッダが、前記カプセル化がＩＰカプセル化であることを示す第１識別子を含む、
請求項１６乃至１８のいずれか一項に記載のＢＦＩＲ。
前記ＩＰカプセル化がＩＰｖ６カプセル化であり、第１ＩＰヘッダがＩＰｖ６ヘッダであるか、又は
前記ＩＰカプセル化がインターネットプロトコルバージョン４ＩＰｖ４カプセル化であり、第１ＩＰヘッダがＩＰｖ４ヘッダである、
請求項１７乃至１９のいずれか一項に記載のＢＦＩＲ。
当該ＢＦＩＲは、
前記少なくとも１つのＢＦＥＲから検出応答パケットを受信するよう構成される受信モジュールを更に含み、前記検出応答パケットは第２パケットを含み、前記第２パケットは、第２ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットである、
請求項１６乃至２０のいずれか一項に記載のＢＦＩＲ。
前記第２パケットは、第２ＩＰヘッダ及び前記第２ＢＩＥＲＡＯＭパケットを含み、前記第２ＩＰヘッダのソースアドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである、
請求項２１に記載のＢＦＩＲ。
前記第２パケットは、第２ＩＰヘッダ、第２ＵＤＰヘッダ及び前記第２ＢＩＥＲＯＡＭパケットを含み、前記第２ＩＰヘッダのソースアドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、前記第２ＵＤＰヘッダに含まれるソースポート番号は、前記検出要求パケットを受信する前記ＢＦＥＲのリスニングポートを示す、
請求項１２に記載のＢＦＩＲ。
ビット転送出口ルータＢＦＥＲであって、
ビット転送入口ルータＢＦＩＲからの検出要求パケットを受信するよう構成される受信モジュールであって、前記検出要求パケットは、第１パケット及び第１パケットヘッダを含み、前記第１パケットは、第１ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットであり、前記第１パケットヘッダはビット文字列を含み、前記ビット文字列は、測定されるべき少なくとも１つのＢＦＥＲを示す、受信モジュールと、
前記第１パケット及び前記ビット文字列に基づいて検出応答パケットを取得するよう構成される処理モジュールであって、前記検出応答パケットは第２パケットを含み、前記第２パケットは第２ＢＩＥＲＯＡＭパケットをカプセル化することによって取得されたパケットである、処理モジュールと、
前記検出応答パケットを前記ＢＦＩＲに送信するよう構成される送信モジュールと、
を含む、ＢＦＥＲ。
前記第１パケットヘッダは、前記カプセル化がインターネットプロトコルＩＰカプセル化であることを示す第１識別子を含み、前記第１パケットは、第１ＩＰヘッダ及び前記第１ＢＩＥＲＯＡＭパケットを含み、前記第１ＩＰヘッダの宛先アドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである、
請求項２４に記載のＢＦＥＲ。
前記第１パケットヘッダは、前記カプセル化がＩＰカプセル化であることを示す第１識別子を含み、前記第１パケットは、第１ＩＰヘッダ、第１ユーザデータグラムプロトコルＵＤＰヘッダ及び前記第１ＢＩＥＲＯＡＭパケットを含み、前記第１ＩＰヘッダの宛先アドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、前記第１ＵＤＰヘッダに含まれる宛先ポートは、前記検出要求パケットを受信する前記ＢＦＥＲのリスニングポートを示す、
請求項２４に記載のＢＦＥＲ。
前記第１パケットヘッダが、インターネットプロトコルバージョン６ＩＰｖ６カプセル化ＢＩＥＲヘッダを含み、該ＩＰｖ６カプセル化ＢＩＥＲヘッダが、ＩＰｖ６ヘッダと、前記カプセル化がＩＰカプセル化であることを示す第１識別子とを含むか、
前記第１パケットヘッダが、マルチプロトコルラベルスイッチングＭＰＬＳカプセル化ＢＩＥＲヘッダを含み、該ＭＰＬＳカプセル化ＢＩＥＲヘッダが、ＭＰＬＳラベルと、前記カプセル化がＩＰカプセル化であることを示す第１識別子とを含むか、又は
前記第１パケットヘッダが、イーサネットカプセル化ＢＩＥＲヘッダを含み、該イーサネットカプセル化ＢＩＥＲヘッダが、前記カプセル化がＩＰカプセル化であることを示す第１識別子を含む、
請求項２４乃至２６のいずれか一項に記載のＢＦＥＲ。
前記ＩＰカプセル化がＩＰｖ６カプセル化であり、第１ＩＰヘッダがＩＰｖ６ヘッダであるか、又は
前記ＩＰカプセル化がインターネットプロトコルバージョン４ＩＰｖ４カプセル化であり、第１ＩＰヘッダがＩＰｖ４ヘッダである、
請求項２５乃至２７のいずれか一項に記載のＢＦＥＲ。
前記第２パケットは、第２ＩＰヘッダ及び前記第２ＢＩＥＲＡＯＭパケットを含み、前記第２ＩＰヘッダのソースアドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスである、
請求項２４乃至２８のいずれか一項に記載のＢＦＥＲ。
前記第２パケットは、第２ＩＰヘッダ、第２ＵＤＰヘッダ及び前記第２ＢＩＥＲＯＡＭパケットを含み、前記第２ＩＰヘッダのソースアドレスは、前記少なくとも１つのＢＦＥＲによって識別することができる有効なアドレスであり、前記第２ＵＤＰヘッダに含まれるソースポート番号は、前記検出要求パケットを受信する前記ＢＦＥＲのリスニングポートを示す、
請求項２４乃至２８のいずれか一項に記載のＢＦＥＲ。