JP2014090468A - Ｐｂｔネットワークの中間ノードにおけるイーサネットｏａｍ - Google Patents

Abstract

【課題】ＰＢＴネットワークの中間ノードにおいてＯＡＭ機能を実現する通信装置および方法を提供する。
【解決手段】ＯＡＭフレームはＰＢＴトランク１０６ａまたは１０６ｂのエンドポイントＡまたはＢにアドレス指定され、ＯＡＭフレームに中間ノードＢおよび／またはＣのＯＡＭ機能に使用されるという表示を含ませることによって、イーサネット（登録商標）ネットワークのＰＢＴトランク上の中間ノードにおいてＯＡＭ機能を実現する。ＯＡＭ機能に使用されるという表示は、ＥｔｈｅｒＴｙｐｅ、ＯｐＣｏｄｅ、ＴＬＶ値又はこれらと他のフィールドとの組み合わせであってもよく、ＥｔｈｅｒＴｙｐｅ、ＯｐＣｏｄｅ、ＴＬＶ値は標準化された値又はベンダー固有の値が使用されてもよい。
【選択図】図１Ａ

Description

［関連出願の相互参照］
本出願は、その内容が参照することによりここに援用される、２００６年１０月３１日に出願された米国仮出願第６０／８５５，５５０号“ＯＡＭ Ｆｏｒ Ｄｉｆｆｅｒｅｎｔｉａｌ Ｆｏｒｗａｒｄｉｎｇ ｉｎ Ａｄｄｒｅｓｓ Ｂａｓｅｄ Ｎｅｔｗｏｒｋｓ”に関連し、その利益を主張する。
［１．発明の分野］
本発明は、通信ネットワークに関し、より詳細には、ＰＢＴ（Ｐｒｏｖｉｄｅｒ Ｂｒｉｄｇｅｄ Ｔｒａｎｓｐｏｒｔ）ネットワークの中間ノードにおけるイーサネット（登録商標）ＯＡＭを実現するための方法及び装置に関する。

［２．関連技術の説明］
データ通信ネットワークは、互いに接続され、データを交換し合うよう構成された各種ルータ、スイッチ、ブリッジ、ハブ及び他のネットワーク装置を含むかもしれない。これらの装置は、“ネットワーク要素”とここでは呼ばれる。データは、各装置の間の１以上の通信リンクを使用することによって、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケット、イーサネットフレーム、データセル、セグメント又はデータビット／バイトの他の論理的関連などのプロトコルデータユニットをネットワーク要素の間で交換することによって、データ通信ネットワークを介し通信される。特定のＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）が、複数のネットワーク要素により扱われ、それがネットワークを介し伝送されるとき、複数の通信リンクを横断するかもしれない。

通信ネットワーク上の各種ネットワーク要素は、ここでプロトコルと呼ばれる所定のルールセットを用いて互いに通信する。ネットワーク要素間の送信についてどのように信号が生成されるべきか、プロトコルデータユニットが何れの各種態様に類似すべきか、ネットワーク要素によりパケットがネットワークを介しどのように処理又はルーティングされるべきか、ルーティング情報にかかる情報がネットワーク要素の間でどのように交換されるべきかなど、ネットワーク上の異なる通信態様を管理するため、異なるプロトコルが使用される。

イーサネット（登録商標）は、ＩＥＥＥ（ｔｈｅ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）によって規格８０２として定義された周知のネットワーキングプロトコルである。当初は、イーサネット（登録商標）は、会社や大学キャンパスの事業用ネットワークなどのローカルエリアネットワークにおいて利用された。イーサネット（登録商標）規格の変更は、メトロポリタンエリアやワイドエリアネットワークなどのより大規模なネットワークについてイーサネット（登録商標）が現在検討されている所までイーサネット（登録商標）が進化することを可能にしてきた。

イーサネット（登録商標）がより大規模なキャリアネットワークにおいて使用されることを可能にした拡張の１つは、ネットワークプロバイダにより所望されるＯＡＭ（Ｏｐｅｒａｔｉｏｎ，Ａｄｍｉｎｉｓｔｒａｔｉｏｎ ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ）機能をイーサネット（登録商標）がサポートすることを可能にしたことである。接続性チェック、ループバック、トレースルート、アラーム通知信号などのＯＡＭ機能は、ネットワークが正常に動作しているか判断し、ネットワーク上に不具合が生じたときは不具合を診断／隔離することをネットワークプロバイダに可能にするよう実現される必要がある。

従来、イーサネット（登録商標）は、ベストエフォート技術として開発された。しかしながら、イーサネット（登録商標）がキャリアネットワークに適応化されるとき、ネットワークを設計できることが所望されるようになった。具体的には、キャリアは、特定のパケットがネットワークを介し取得されるパスを知ることができるように、ネットワーク上のエンドポイント間にパスを生成することを所望するかもしれない。これに関連して開発されている技術の一例は、ＰＢＴ（Ｐｒｏｖｉｄｅｒ Ｂｒｉｄｇｅｄ Ｔｒａｎｓｐｏｒｔ）と呼ばれる。ＰＢＴは、ＩＥＥＥ８０２．１ａｈに関連し、ＰＢＢ−ＴＥ（Ｐｒｏｖｉｄｅｒ Ｂａｃｋｂｏｎｅ Ｂｒｉｄｇｅｓ−Ｔｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇ）活動として説明されている。ＰＢＴは、より詳細には、その内容が参照することによりここに援用される、米国特許出願第１０／８１８，６８５号“Ｔｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇ ｉｎ Ｆｒａｍｅ−Ｂａｓｅｄ Ｃａｒｒｉｅｒ Ｎｅｔｗｏｒｋｓ”に記載される。

図１は、複数のイーサネット（登録商標）スイッチ１０２がリンク１０４を介し相互接続される一例となるネットワーク１００を示す。プロバイダブリッジドトランク１０６は、特定のＶＬＡＮ ＩＤ（ＶＩＤ）とデスティネーションＭＡＣアドレス（ＤＡ）を有するトラフィックフローとして定義されるかもしれない。ＰＢＴでは、ネットワークを介したパスは、トランク（ｔｒｕｎｋ）又はトンネル（ｔｕｎｎｅｌ）と呼ばれ、ＭＰＬＳトンネルと同様のものであると考えられてもよい。ここで用いられる“トランク”という用語は、ＰＢＴパスを記述するのに用いられる。典型的には、ネットワーク管理ステーションは、ネットワークを介し生成されるトランクを規定し、トランクは、ネットワーク管理ステーションからの直接的な設定によって、又はシグナリングプロトコルを用いて、ネットワーク要素上で確立される。ネットワーク管理ステーションは、当該技術に知られている方法で、ネットワーク上のデータフローを運営するようトランクを規定するかもしれない。さらに、トランクは、所望される場合、ネットワーク要素によって、ルーティング情報の交換を介し自動的に設定されてもよい。ＶＬＡＮ ＩＤ（ＶＩＤ）タグと特定のデスティネーションＭＡＣアドレス（ＤＡ）との組み合わせは、特定のトランクを一意的に特定し、これにより、ネットワーク上のネットワーク要素はＶＩＤ／ＤＡに基づきトラフィックを転送できる。トランクのシグナリングは、特定のＶＩＤ／ＤＡの組み合わせを有するフレームがソースからデスティネーションへのパスに沿って転送されるように、中間のネットワーク要素にＶＩＤ／ＤＡのためのそれらのＦＩＢに転送エントリを組み込ませる。

ＰＢＴトランクは、ネットワーク上の一方向のパスである。一般に、ノードのペアの間には、トラフィックがノード間で双方向に送信されることを可能にするため、各方向に１つずつの２つのトランクが設定される。様々な理由のため、これらのトランクは、典型的には、同じパス（中間ノードとリンクの同一のセット）に沿って設定されるが、このように設定されることが要求されるものでない。ＰＢＴが実現される方法に応じて、トランク上の中間ノードがネットワーク上のソースとデスティネーションの各ペア間で反対方向に延びるトランクのための情報を転送する相関関係を維持しないように、フォワード及びリバーストランクは互いに独立しているかもしれない。

中間ノードは、特定のデスティネーションＭＡＣアドレス（ＤＡ）とＶＩＤとを有し、特定のポートを介し到来するフレームが特定の方法により転送されるべきであることを示すためのエントリを各自の転送テーブルに組み込むことによって、トランクの転送状態を組み込む。例えば、図１において、ソースノードＡからデスティネーションノードＤに延びる第１トランク１０６ａが存在すると仮定する。中間ノードＢは、と規定されたＤＡ／ＶＩＤを有するフレームがノードＣに転送されるべきであることを示すため、それの転送情報ベース（ＦＩＢ）に転送状態を組み込む。同様に、ノードＣは、ＤＡ／ＶＩＤを有するフレームがノードＤに転送されるように、それのＦＩＢに転送状態を組み込む。

リバースパスでは、トランクはノードＡのデスティネーションアドレス（ＤＡ）により特定され、独立したＶＩＤはまた、ノードＤからノードＡへのフレームのフローに全体に割り当てられる。ＦＩＢエントリが複雑化することを回避するため、２つのトランク１０６ａ，１０６ｂのＦＩＢエントリは関連付けされない。説明されるようなネットワークにおける相互関係は比較的単純なものであるように見えるかもしれないが、ネットワークのサイズが増大し、このようなＰＢＴトランクが数百万個も生成されると、トランク間の相互関係は取るに足らないものにならなくなる。さらに、マルチキャストが実現されるとき、リバースパストランクは複雑に相関するかもしれない。

フォワードとリバースのＰＴＢトランクの間の相互関係を維持しないことに加えて、ＰＢＴトランクに沿った中間ノードは、ＰＢＴトランクに沿った中間ポイントに関する情報を有しないかもしれず、このため、トランクがノードＡとノードＤとの間で取得するパス上の中間ポイントのアドレスを知らないかもしれない。さらに、中間ポイントは、ＤＡ／ＶＩＤに基づきフレームを転送することしかしないよう構成されるかもしれない。到来したがＦＩＢのエントリに一致しないフレームは、ネットワーク要素により破棄されるかもしれない。従って、イーサネットＯＡＭフレームがＰＢＴトランク１０６ａを介しネットワーク要素Ｃにアドレス指定される場合、上流の中間ネットワーク要素Ｂは、フレームの転送状態を有さず、フレームを破棄するかもしれない。このため、ネットワーク要素Ｃは、ＯＡＭフレームを受信できず、それに応答することができないことになる。

フォワードとリバースのパスの間の相互関係の可能性のある欠落と、中間ノードにアドレス指定されるフレームがネットワーク上の他の中間ノードにより破棄されるという事実との組み合わせは、ＰＢＴネットワークにおける中間ノードＯＡＭを複雑化する。特に、ＯＡＭはソースノードＡとデスティネーションノードＤのメッセージングエンドポイント（ＭＰＥ）の間でエンド・ツー・エンドに規定されるかもしれないが、メッセージング中間ポイント（ＭＩＰ）が中間ノードにおいて規定されていても、これらのノードはＯＡＭフレームを処理せず、単にＰＢＴトランクを介しＯＡＭフレームを転送するだけである。さらに、中間ノードが直接アドレス指定される場合、それらは、転送情報ベースが中間ノードにかかるＤＡとＶＩＤとのエントリを有しないかもしれないため、フレームを認識できず、ＰＢＴによると、中間ノードは転送状態を含まないフレームを破棄する。

最終的には、中間ノードがＯＡＭメッセージを認識し、ＯＡＭメッセージを処理しても、リバース方向におけるトランクにより使用されるＶＩＤを有しないため、ＯＡＭメッセージに応答する仕方を知ることができない。このため、中間ノードにより生成されるＯＡＭリプライメッセージは、認識されないため、他の中間ノードにより破棄されることになるであろう。すなわち、中間ノードはフォワードパスで使用されるＶＩＤと、リバースパスで使用されるＶＩＤとの間の相互関係を有しないかもしれないため、中間ノードはＡ）のＭＡＣアドレスなど、リバースパスで使用されるデスティネーションアドレスを抽出可能であるが、それは、その他の中間ノードがリバーストランク１０６ｂ上のＤＡと共に使用するＶＩＤを知ることはないかもしれない。このため、中間ノードは、リバーストランク上の通常のフレームとしてその他の中間ノードにより処理されるフレームを生成することができないかもしれない。従って、ＯＡＭメッセージが中間ノードにより受信及び処理されても、中間ノードは、リバーストランク１０６ｂを介し送信可能なリプライフレームを生成することができないかもしれない。このため、ＰＢＴネットワークにおいてＯＡＭを実現できることが所望されるであろう。

中間ノードは、ＰＢＴトランク上でＯＡＭフレームを認識し、ＰＢＴトランクのエンドポイントにアドレス指定されるが、それらが中間ノードのＯＡＭ機能を実現するのに使用されるという通知を含むＯＡＭフレームに応答するよう構成されてもよい。本発明の各実施例を実現する他の方法もまた利用可能であり、本発明はこれらの手段に限定されないが、３つの手段が提供される。第１実施例は、ＥｔｈｅｒＴｙｐｅ値が、ＰＢＴトランク上の中間ノードに当該ＯＡＭフレームが中間ノードにより処理されるべきであることを示すため、中間ノードのＯＡＭフレームとしてフレームを特定するのに使用される。本発明の他の実施例によると、ＯｐＣｏｄｅ値が、当該ＯＡＭフレームが中間ノードにより処理されるべきであることを中間ノードに示すのに使用される。本発明の他の実施例によると、ＴＬＶ（Ｔｙｐｅ Ｌｅｎｇｔｈ Ｖａｌｕｅ）値が、当該ＯＡＭフレームが中間ノードにより処理されるべきであることを中間ノードに示すのに使用される。

中間ノードがフォワードトランクとリバーストランクとの間の相互関係を維持することを要求されることを回避するため、ＯＡＭフレームに応答して生成されるリプライメッセージがリバーストランクを介しわたされるように、リバーストランクのＤＡ／ＶＩＤなどのリプライアドレス情報を有するよう構成されてもよい。

本発明によると、ＰＢＴネットワークにおいてＯＡＭを実現できる。

図１は、ＰＢＴトランクが実現される一例となるイーサネット（登録商標）ネットワークの一部の機能ブロック図である。 図２は、本発明の実施例によるＯＡＭ Ｅｔｈｅｒ−ｔｙｐｅを用いたＰＢＴトランクの中間ノードにおけるＯＡＭを実現するよう構成されるイーサネット（登録商標）フレームのブロック図である。 図３Ａは、本発明の実施例による新たなＥｔｈｅｒ−ｔｙｐｅを用いたＰＢＴトランクの中間ノードにおけるＯＡＭを実現するよう構成されるイーサネット（登録商標）フレームの他の実施例のブロック図である。 図３Ｂは、本発明の実施例による図３Ａのイーサネット（登録商標）フレームから生成され、ＰＢＴトランクの中間ノードによりＯＡＭリプライメッセージを実現するよう構成されるイーサネット（登録商標）フレームのブロック図である。 図３Ｃは、本発明の実施例による図３Ａのイーサネット（登録商標）フレームから生成され、ＰＢＴトランクの中間ノードによりＯＡＭリプライメッセージを実現するよう構成されるイーサネット（登録商標）フレームのブロック図である。 図４Ａは、本発明の実施例によるベンダー固有のＯｐＣｏｄｅを用いたＰＢＴトランクの中間ノードにおけるＯＡＭを実現するよう構成されるイーサネット（登録商標）フレームのブロック図である。 図５Ａは、図４Ａのイーサネット（登録商標）フレームの各フィールドの相対的な配置及びサイズをより詳細に示すブロック図である。 図４Ｂは、本発明の実施例による標準化されたＯｐＣｏｄｅを用いたＰＢＴトランクの中間ノードにおけるＯＡＭを実現するよう構成されるイーサネット（登録商標）フレームのブロック図である。 図５Ｂは、図４Ｂのイーサネット（登録商標）フレームの各フィールドの相対的な配置及びサイズをより詳細に示すブロック図である。 図６Ａは、本発明の実施例によるベンダー固有のＴＬＶを用いたＰＢＴトランクの中間ノードにおけるＯＡＭを実現するよう構成されるイーサネット（登録商標）フレームのブロック図である。 図７Ａは、図６Ａのイーサネット（登録商標）フレームの各フィールドの相対的な配置及びサイズをより詳細に示すブロック図である。 図６Ｂは、本発明の実施例による標準化されたＴＬＶを用いたＰＢＴトランクの中間ノードにおけるＯＡＭを実現するよう構成されるイーサネット（登録商標）フレームのブロック図である。 図７Ｂは、図６Ｂのイーサネット（登録商標）フレームの各フィールドの相対的な配置及びサイズをより詳細に示すブロック図である。 図８は、本発明の実施例を実現するのに利用可能なプロセスを示すフロー図である。 図９は、本発明の実施例を実現するのに利用可能なネットワーク湿地の機能ブロック図である。

本発明の各態様は、特に添付した請求項において指摘される。本発明は、同様の参照が同様の要素を示す以下の図面により示される。以下の図面は、説明のためだけに本発明の各種実施例を開示し、本発明の範囲を限定するものでない。簡単化のため、必ずしもすべての構成要素がすべての図面にラベル付けされるとは限らない。

本発明の完全な理解を提供するため、以下の詳細な説明は、多数の具体的詳細を与える。しかしながら、当業者は、本発明がこれら具体的詳細なしに実現可能であることを理解するであろう。また、本発明を不明りょうにしないように、周知の方法、処理、構成要素、プロトコル、アルゴリズム及び回路は詳細には説明されない。

図１は、ネットワーク要素１０２がリンク１０４により相互接続される一例となるイーサネット（登録商標）ネットワーク１００の一部を示す。ＰＢＴトランク１０６ａ，１０６ｂは、その内容が参照することによりここに援用される、米国特許出願第１０／８１８，６８５号“Ｔｒａｆｆｉｃ Ｅｎｇｉｎｅｅｒｉｎｇ ｉｎ Ｆｒａｍｅ−Ｂａｓｅｄ Ｃａｒｒｉｅｒ Ｎｅｔｗｏｒｋｓ”に詳細に説明されるように、イーサネット（登録商標）ネットワーク１００を介し確立されるかもしれない。

ＰＢＴトランク１０６は、中間ノードにトランクパスを介しトランクＤＡ／ＶＩＤを有するトラフィックを転送される転送状態を中間ノードに組み込ませることによって、イーサネット（登録商標）ネットワーク１００を介し一方向に延びるよう生成される。通常は、２つのトランクが、ネットワーク上の同一パスに沿って２つの異なる方向に形成され、これにより、パスのエンドにあるノード間でトラフィックが双方向に送信可能となる。ネットワーク管理システム１０８は、トランクを規定及び確立する他の方法がまた利用可能であるが、トランクを生成するのに利用されてもよい。

ＰＢＴネットワークでは、トランク１０６が確立されるとき、ネットワーク要素は、トランク上のトラフィックが規定されたパスに沿って転送されるように、トランクの転送状態を組み込む。例えば、図示されたネットワークでは、ＰＢＴトランクのペア（１０６Ａ，１０６Ｂ）が、ネットワーク要素Ａとネットワーク要素Ｄとの間に延びる。中間ノード（ネットワーク要素Ｂ及びＣ）は、トランクを実現するため転送状態を組み込む。トランク上のトラフィックは、トランクエンドポイントのＭＡＣアドレス（デスティネーションＭＡＣアドレス又はＤＡ）とＶＰＮ ＩＤ（ＶＩＤ）とを用いて特定される。ＤＡとＶＩＤの組み合わせは、ＤＡを目的とする異なるトラフィックがネットワーク上の異なるパスに従うように、デスティネーションとフロートを一意的に特定する。さらに、ＤＡ／ＶＩＤの組み合わせは、一意となることが予想され、このため、さらなるラベルがトラフィックに付加されることを要することなく、トラフィックを特定し、トランクを介しトラフィックを転送するのに中間ノードのデータプレーンにより利用可能である。

本発明の実施例によると、ＰＢＴトランクエンドポイントにアドレス指定されたイーサネット（登録商標）ＯＡＭフレームは、当該ＯＡＭフレームがＰＢＴトランクの中間ノードの１以上において中間ノードのＯＡＭ機能を実現するのに利用されるべきであることを、ＰＢＴトランク上の中間ノードに通知するよう構成される。後述されるように、この通知は、ＥｔｈｅｒＴｙｐｅ、ＯｐＣｏｄｅ、ＴＬＶ又はイーサネット（登録商標）フレームの形式により、他のフィールドにおいて実現されてもよい。

イーサネット（登録商標）ＯＡＭは、ループバック、リンクトレース、アラーム通知信号（ＡＩＳ）及び他の従来のＯＡＭを実現するのに利用されてもよい。以下のいくつかの具体例はループバック及びリンクトレースを実現するため、特定のＯＡＭフレームを使用することに着目しているが、本発明はこれに限定されるものでなく、ＯＡＭフレームはその他のＯＡＭ機能を実現するのにも利用されるかもしれない。

図１Ｂ及び１Ｃは、以下で詳細に説明されるＯＡＭフレームを用いて実現可能なＯＡＭ機能の異なる複数の形式を示す。特に、図１Ｂは、ＯＡＭフレームが中間ノードＣにおいてループバックＯＡＭ機能を実現するのに使用される実施例を示す。本実施例では、中間ノードＣがトランク１０６Ａ上で中間ノードＯＡＭメッセージを受信すると、リプライＯＡＭメッセージ１０８を生成し、リプライリバーストランク１０６Ｂを介し当該リプライをソースノードＡに送信する。周知なように、ループバックは、特定のノードにＯＡＭメッセージに応答させ、ネットワークのパス上の特定のネットワーク要素をポーリングすることが可能である。

図１Ｃは、実行されるＯＡＭ機能がリンクトレースである点を除いて図１Ｂと同様である。例えば、図１Ｃに示されるように、リンクトレースはノードＡとノードＣとの間で実行されると仮定される。ＯＡＭフレームがトランク１０６Ａを介し送信されると、当該ＯＡＭフレームを受信した各中間ノードは、リプライ１０８を生成し、リバーストランク１０６Ｂを介し当該リプライをソースノードＡに送信する。このため、本例では、中間ノードＢとＣは共に、リプライメッセージ１０８を生成することになるであろう。

図２は、イーサネット（登録商標）フレーム２００を示す。図２に示されるように、イーサネット（登録商標）フレームは、一般に、デスティネーションＭＡＣアドレス（Ｂ−ＤＡ）２０２と、ソースＭＡＣアドレス（Ｂ−ＳＡ）２０４とを含む。図１のイーサネット（登録商標）ネットワークにおけるソース及びデスティネーションＭＡＣアドレスは、一般には、プロバイダのアドレッシングスペースである、ネットワーク要素１０２のバックボーン（Ｂ）ＭＡＣアドレスである。

ＯＡＭフレームは、図示された具体例では、０ｘ８８Ａ８であるＥｔｈｅｒＴｙｐｅフィールド２０６を有する。イーサネット（登録商標）フレームはまた、当該フレームが何れのタイプのＶＬＡＮに関連するか特定するのに使用されるＢ−ＶＬＡＮ ＩＤ（ＶＩＤ）フィールド２０８を有する。このタグは、クライアントにより指定されたタグのためのフレームのその他の部分をチェックすることなく、イーサネット（登録商標）ネットワークのネットワーク要素１０２がフレームにかかるＶＬＡＮを特定することを可能にする、Ｑ−タグとしても知られるプロバイダにより実装されるタグである。ＯＡＭフレームは、ＰＢＴトランク上のトラフィックを転送するのに使用される予想されるＤＡ／ＶＩＤを含むため、通常の方法によりＰＢＴトランク上で転送される。

イーサネット（登録商標）フレーム２００はまた、当該フレームを処理するネットワーク要素のデータプレーンに、当該フレームのフレームタイプを示す第２Ｅｔｈｅｒ−ｔｙｐｅ２１０を含む。例えば、ＥｔｈｅｒＴｙｐｅフィールド２１０は、フレームがデータフレーム、制御フレーム、又は本発明の実施例によるトランク上でＯＡＭ機能を実現するためＰＢＴトランクの中間ノードｓにより使用されるイーサネット（登録商標）ＯＡＭフレームであることを示す値を含むかもしれない。他の既知の機能を実現するため、他の値がまたＥｔｈｅｒＴｙｐｅフィールド２１０に含まれてもよい。

図３は、ＰＢＴトランク上の中間ノードにおいてイーサネット（登録商標）ＯＡＭを実現するのに利用可能なイーサネット（登録商標）フレームの他の実施例を示す。図３に示されるように、イーサネット（登録商標）フレーム３００は、当該フレームがＯＡＭフレームであることを示すものとして中間スイッチ１０２により認識可能な新たなＥｔｈｅｒ−ｔｙｐｅ値３０２を有する。

Ｅｔｈｅｒ−ｔｙｐｅ３０２は、中間ノードがそれらを対象としている可能性のあるＯＡＭフレームを抽出することを可能にする。中間ノードが、当該フレームが中間ノードＯＡＭフレームであることを示す値に設定されたＥｔｈｅｒ−ｔｙｐｅ値３０２を有するフレームを受信すると、当該中間ノードは、さらなるアクションがＯＡＭフレームに関して要求されているか判断するため、ＯＡＭフレームの他のフィールドを確認する。

図３に示される例では、ＯＡＭフレームは、当該ＯＡＭフレームが特定の中間ノードにアドレス指定されているかファーストパス（イーサネット（登録商標）スイッチのデータプレーン）が特定することを可能にするターゲットデスティネーションアドレス（ＤＡ）３０４を有する。ターゲットＤＡは、当該ＯＡＭフレームが特定の中間ノードにおいてループバック機能を実現するのに使用される個別ＭＡＣアドレスであるか、又は当該ＯＡＭフレームがリンクトレース機能を実現するのに使用されるグループＭＡＣアドレスであるかもしれない。これについて、ループバックは特定のノードに特定のフレームの受信に応答させるるが、リンクトレースは特定のパス上のすべての中間ノードに特定のフレームの受信に応答させることに留意されたい。

ＯＡＭフレームはまた、当該ＯＡＭフレームがＰＢＴトランクエンドポイントにより生成されていないとき、ＯＡＭリプライフレームをＯＡＭフレームのソースアドレスに導くことを可能にする意図されるソースアドレス（ＳＡ）３０６を有する。一般に、ＯＡＭフレームがＰＢＴトランクのソースに送り返される場合、意図されるＳＡ３０６は、バックボーンソースアドレス（Ｂ−ＳＡ）２０４と同じになる。しかしながら、ＯＡＭフレームが意図されるＳＡを含むフィールドを有することを可能にすることによって、ＯＡＭフレームは、ＰＢＴトランクのソースに送り返されることが自動的には要求されない。

ＯＡＭフレームはまた、中間ネットワーク要素により実現されるＯＡＭ機能のタイプを特定するのに利用可能なＥｔｈｅｒ−ｔｙｐｅ値３０８を有してもよい。このフィールドは、中間ノードが受信したＯＡＭフレームから図３Ａのヘッダ３２２を取り除くことによって、リプライフレームを発行することを可能にし、結果として得られるフレームは有効なリプライフレームとなる。このフィールドは、ＥｔｈｅｒＴｙｐｅ値３０２が当該情報を伝えるのに十分具体的である場合、所望されるときちには排除されてもよい。例えば、異なるＥｔｈｅｒ−ｔｙｐｅ値が各ＯＡＭ機能について指定される場合、第２Ｅｔｈｅｒ−ｔｙｐｅフィールド３０８は冗長であるかもしれない。

ＯＡＭフレームはまた、リバースＶＬＡＮが搬送可能なリバースＶＬＡＮ ＩＤフィールド３１０を有する。リバースＶＬＡＮ ＩＤ（ＶＩＤ）は、リプライフレームをアドレス指定するため、意図されるＳＡ（又はＯＡＭフレームがトランクエンドポイントにおいて発信されたＢ−ＳＡ）と共に使用される。例えば、図１に示されるように、ＡからＤへのトランク１０６ａのフレームは、ネットワーク要素ＤのＤＡと第１ＶＩＤとを用いて、ネットワーク要素Ｄにアドレス指定される。ＤＡとＶＩＤの組み合わせは、ＡからＤへのトランク１０６ａ上のフレームを特定するのに使用される。ネットワーク要素Ｄからネットワーク要素Ａへのリバーストランクでは、フレームは、Ｂ−ＳＡであるか、又は図３に示されるフレームの意図されるＳＡ３０６であるネットワーク要素ＡのデスティネーションＭＡＣアドレスにより特定される。中間ノードＢとＣは、トランク１０６ａと１０６ｂとの間の相互関係を維持していないため、これらの中間ノードは、リバーストランク１０６ｂを介しリプライメッセージを送信するためのリバースＶＬＡＮ ＩＤ（リバーストランク１０６ｂのＶＩＤなど）を必要とする。中間ノードがリバーストランクのＶＩＤを知ることを可能にするため、リバースＶＬＡＮ ＩＤフィールド３１０は、中間ノードがフォワードトランクとリバーストランクとの間の相互関係を維持する必要がないように、当該情報を搬送するのに利用可能である。

図３Ｂ及び３Ｃは、本発明の実施例による中間ノードにより生成されるリプライフレームの実施例を示す。図３Ｂに示される実施例では、リプライフレームは、ＯＡＭフレームの意図されるＳＡフィールドに搬送される値を使用し、当該アドレス値をリプライＢ−ＤＡとして使用することによって生成される。ＯＡＭフレームのターゲットＤＡ３０４は、上述されるリプライＢ−ＳＡとして使用される。Ｅｔｈｅｒ−ｔｙｐｅ値は、ＯＡＭフレームのＥｔｈｅｒ−ｔｙｐｅフィールド３０８から取得され、リプライＶＩＤは、ＯＡＭフレームのリバースＶＬＡＮ ＩＤフィールド３１０から取得される。ＯＡＭペイロードがまた、任意的に含まれてもよい。

図３Ｃは、リプライＯＡＭメッセージが、単にＯＡＭフレームのヘッダの一部を削除し、これにより生成された新たなリプライフレームをリバースＰＢＴトランクを介し送信することによって構成される他の実施例を示す。特に、図３Ｃに示されるように、ターゲットＤＡフィールド３０４と意図されるＳＡフィールド３０６とがわずかに変更される場合、中間ノードは単に、フィールド３２２（Ｂ−ＤＡ３１４，Ｂ−ＳＡ３１６，Ｅｔｈｅｒｔｙｐｅ３１８，Ｂ−ＶＬＡＮ ＩＤ３２０，新たなＥｔｈｅｒ−ｔｙｐｅフィールド３０２）を取り除き、リプライフレームを生成してもよい。本実施例では、ターゲットＤＡフィールド３０４は、リプライメッセージが送信されるＯＡＭのソースのデスティネーションアドレスを搬送するのに使用される。リバースＶＬＡＮ ＩＤは、リプライフレームがリバーストランク上で搬送されることを可能にするリバーストランク１０６ｂのＶＩＤである。本実施例の意図されるソースアドレスフィールド３０６は、ＯＡＭ機能を実行しており、リプライメッセージＢ−ＳＡフィールドとして使用される中間ノードのＭＡＣアドレスである。本実施例では、リプライＯＡＭフレームがオリジナルのＯＡＭフレームの初期的な複数のフィールドを削除する以外の何れの処理を中間ノードが実行することを要求することなく、Ｅｔｈｅｒｔｙｐｅフィールド３０８は、リプライＯＡＭフレームが通常のイーサネット（登録商標）フレームとして現れることを可能にするため、オリジナルのＯＡＭフレームに設けられる。このため、本例では、Ｅｔｈｅｒｔｙｐｅフィールド３０８は、リプライＯＡＭフレームがこのＥｔｈｅｒｔｙｐｅを有することを可能にするよう、０ｘ８８Ａ８に設定されてもよい。他のＥｔｈｅｒｔｙｐｅが、特定の実現形態に関して所望されるように使用されてもよい。

図３Ｃに示される実施例では、ＯＡＭフレームのソースは、リプライＯＡＭフレームを実質的に生成し、新たなＥｔｈｅｒｔｙｐｅ値を有するイーサネット（登録商標）ヘッダによりリプライＯＡＭフレームをカプセル化する。この新たなＥｔｈｅｒｔｙｐｅ値は、ＰＢＴトランク上の中間ノードが中間ノードＯＡＭフレームとして当該フレームを特定することを可能にする。ＯＡＭフレームに応答するため、ノードは単にカプセル化されたヘッダフィールド３２２を取り除き、結果として得られるカプセル解除されたリプライＯＡＭフレームをリバースパス１０６ｂを介し送信してもよい。これは、中間ノードがノード制御プレーンによるフレームの処理を要することなく、リプライフレームをハードウェアにより生成することを可能にする。

図３Ｃに示される実施例が、それに埋め込まれた意図されるリプライフレームを有するＯＡＭフレームを送信することにより、ＯＡＭ機能の実現形態に関して説明されたが、本発明の本実施例はまた、他の機能を実行するのに利用されてもよい。特に、イーサネット（登録商標）ネットワーク上のノードにより送信されるイーサネット（登録商標）メッセージにフレームを埋め込むという考えは、ＯＡＭに関連する機能以外の多数の機能を実現するのに利用されてもよい。実質的に、本実施例は、内部のＭＡＣヘッダと外部のＭＡＣヘッダがプロバイダ（Ｂ）ＭＡＣアドレッシングスペースを用いて生成され、オリジナルフレームとリプライフレームの双方がプロバイダネットワークを介し伝送されるように、Ｍａｃ−ｉｎ−Ｍａｃカプセル化リプライフレームを有する。これはＯＡＭ機能を実現するのに利用可能であるが、リプライフレームはしばしばＯＡＭ機能の実現と共に利用されるため、あるネットワーク要素が他のネットワーク要素に同一ネットワーク上でフレームを送信させることを可能にするのに、他のコンテクストにおいて利用可能であるとき、本発明はこの方法に限定されない。

新たなＥｔｈｅｒＴｙｐｅを使用してＯＡＭ機能を可能にすることは効果的であるかもしれないが、本発明はこの実施例に限定されず、中間ノードにおいてＯＡＭ機能を実現する他の方法がまた利用可能である。さらなる２つの実施例が、図４〜５及び６〜７に関して説明される。

図４〜５に示される実施例では、イーサネット（登録商標）フレームがイーサネット（登録商標）フレームのＯｐＣｏｄｅフィールドを用いることによりＰＢＴトランクの中間ノードの１以上を目的とするＯＡＭフレームであることが、中間ノードに通知される。イーサネット（登録商標）規格は、イーサネット（登録商標）ネットワーク上のネットワーク要素によりフレームに対して実行される異なるタイプの処理を規定するのに利用可能な多数の異なるオペコード（ＯｐＣｏｄｅ）を規定する。本発明の実施例によると、１以上のＯｐＣｏｄｅが、受信したフレームのＯｐＣｏｄｅフィールドをチェックすることによって、ネットワーク要素が当該フレームがＰＢＴトランク上の中間ノードを目的としたＯＡＭフレームであるか判断し、そうである場合、ＯＡＭフレームがどのように処理されるべきか判断できるように、ＯＡＭ機能を実現するよう定義されてもよい。

ＯｐＣｏｄｅフィールド値は、ネットワーク要素が特定のＯｐＣｏｄｅを有するフレームをどのように処理すべきかに関して同意ａｈｓに達するとＩＥＥＥにより割り当てられる。ＯｐＣｏｄｅが割り当てられると、ＯｐＣｏｄｅにかかる機能が設定され、規格に準拠するすべてのベンダが規定されたＯｐＣｏｄｅを有するフレームを同一の方法により処理する。現在、多数のＯｐＣｏｄｅが特定の機能を実現するよう割り当てられており、任意的には、１以上のＯｐＣｏｄｅが、ＰＢＴネットワークの中間ノードにおいてＯＡＭ機能を実現するよう割り当てられるかもしれない。同様に、ＩＥＥＥはまた、ＥｔｈｅｒＴｙｐｅ値（図２〜３に関連して上述された）と、ＴＬＶ値（図６〜７に関連して後述される）とを割り当てる。ＰＢＴトランクにおいて中間ノードのＯＡＭ機能を実現することに関連して使用するため、１以上の特定の値がＩＥＥＥにより割り当てられるかもしれない。

すでに割り当てられたＯｐＣｏｄｅの１つは、特定のベンダーに特有の特殊な方法によりフレームがフォーマット化されたことを、ネットワーク上の他のすべてのネットワーク要素にベンダーが指定することを可能にするベンダー固有のＯｐＣｏｄｅである。現在バージョンの規格では、フレームが特定のベンダーのフォーマットに従ってフォーマット化されることを指定するため、ＯｐＣｏｄｅ５１が使用される。ＯＡＭフレームのソースにＯＡＭフレームのＯｐＣｏｄｅを“５１”に設定されることによって、ＯＡＭ機能は、特定のネットワーク装置ベンダーにかかるネットワーク要素上で実現可能である。規格団体が１以上の中間ノードＯＡＭ値を採用する場合、すべてのネットワーク装置ベンダーは、ＯｐＣｏｄｅを同様にして実現することが要求され、このため、ＯＡＭ機能は何れのベンダーがネットワーク要素を製造したかに関係なく機能する。

標準化処理が完了しておらず、１以上のＯｐＣｏｄｅ値がＯＡＭ機能を実現するため割り当てられていなかったため、５１のベンダー固有のＯｐＣｏｄｅがＯＡＭ機能を実現するのに使用される実施例が説明される。標準化処理が完了した場合、フィールドの一部は必要とされなくなるため、本発明はこの特定の実現形態に限定されない。図４に示されるように、当該フレームがＯＡＭフレームであることをネットワーク要素に示すＯＡＭ Ｅｔｈｅｒ−ｔｙｐｅフィールドの後に、イーサネット（登録商標）フレームは、メンテナンスレベルフィールド（ＭＥＬ）４０２と、何れのバージョンの規格が実装されているか示すバージョンフィールド４０４とを含む。上述されるＯｐＣｏｄｅフィールド４０６が次にあり、本実施例では、当該ＯＡＭフレームがベンダー固有の方法によりフォーマット化されたことをネットワーク上のネットワーク要素に示す“５１”に設定された。規格団体が異なるＯｐＣｏｄｅ値を採用する場合、当該フィールドは、“５１”から規格団体により採用された値に変更されるかもしれない。さらに、これが実装される方法に依存して、後述される他の複数のフィールドは、使われなくなり、及び／又は再配置されるかもしれない。

本実施例では、ＯｐＣｏｄｅ値の後に、１以上のベンダー固有の特徴を示すのに利用可能な１以上のフラグが続く。本発明は、フラグの使用方法又はフラグフィールド４０８を含めることに限定されるものでない。

フラグフィールドの後に、ベンダー固有フィールドの開始を示すＴＬＶ（Ｔｙｐｅ Ｌｅｎｇｔｈ Ｖａｌｕｅ）オフセットフィールドが続く。

上述されるように、ＯｐＣｏｄｅ値５１は、ＯＡＭフレームがベンダー固有の方法によりフォーマット化されることを示す。ネットワーク要素が当該ＯＡＭフレームを理解可能か判断することを可能にするため、ＴＬＶオフセットフィールドの後に、フレームフォーマットを読み込み可能なベンダーを特定するＯＵＩ（Ｏｒｇａｎｉｚａｔｉｏｎａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）値が続く。従って、ＯｐＣｏｄｅ＝５１を有するＯＡＭフレームが受信されると、ネットワーク要素は、当該ＯＡＭフレームがネットワーク要素と同じベンダーに係るものであるか判断するため、ＯＵＩフィールド４１２を確認する。そうである場合、ネットワーク要素は、当該ＯＡＭフレームに関して何れのＯＡＭ機能が実装されるか判断するため、サブＯｐＣｏｄｅフィールド４１４を確認する。例えば、ノーテルネットワークにより製造されたネットワーク要素がＯｐＣｏｄｅフィールド＝５１のＯＡＭフレームを受信した場合、ＯＵＩフィールドがノーテルネットワークＯＵＩを有しているか判断するため確認する。そうである場合、それは、何れのタイプのＯＡＭ機能が実行されるか判断するため、サブＯｐＣｏｄｅフィールド４１４を確認する。ＯＵＩフィールドがノーテルネットワークＯＵＩに一致しなかった場合、当該フレームは標準的な方法により扱われ、残りのベンダー固有フィールドは無視される。

図４〜５に示されるＯＡＭフレームはまた、図３に示される実施例に類似した複数のフィールドを含む。具体的には、サブＯｐＣｏｄｅフィールド４１４の後に、ＯＡＭフレームは、ＰＢＴトランク上の中間ノードの１以上を特定するのに使用されるターゲットＤＡと、リプライが送信されるべきソースＭＡＣアドレスである意図されるＳＡと、リバーストランク１０６ｂにリプライを配置するのに使用されるリバースＶＬＡＮ ＩＤフィールドとを有する。これらのフィールドは、図２〜３に関して上述されたものと同じである。ＯＡＭフレームはまた、実現形態に応じて１以上のさらなるフィールドを有してもよく、任意的には、エンドＴＬＶを有してもよい。フレームの特定の順序は、ＯＡＭ機能を実現するのに使用される特定のハードウェアに従って最適化されてもよく、従って、本発明は、図４〜５に関して上述された特定の順序に限定されるものでない。同様に、上述されたフィールドの１以上は、ＯｐＣｏｄｅがＯＡＭ機能を実現するのに使用される方法に応じて、所望のフィールド又はフィールドのいくつかがマージされてもよい場合には、省略されてもよい。例えば、標準化されると、ＯＵＩフィールド４１２に対する必要性は低下することが予想される。

図４Ｂ及び５Ｂは、標準化されたＯｐＣｏｄｅ値がＰＢＴトランク上の中間ノードにおいてＯＡＭ機能を実現するのに使用される本発明の実施例を示す。図４Ｂに示されるように、フィールドの一部は同一であるが、ＯｐＣｏｄｅ値４０６がベンダー固有の値５１から他の値Ｘに変更されているという点で、図４Ｂに示されるＯＡＭフレームは図４Ａに示されるフレームと異なっている。規格団体により選択される特定の数字は関係ない。また、規格を実現するすべてのネットワーク要素が同じ方法によりフレームを処理するため、ＯＡＭフレームは、組織ＯＵＩフィールド４１２を有する必要はない。同様に、中間ノードにより実行されるＯＡＭ機能のタイプを指定するよう構成される場合には保持されるかもしれないが、ＯＡＭフレームはサブＯｐＣｏｄｅフィールド４１４を有する必要はない。

リプライフレームは、図３Ｃに関してより詳細に上述されたように、ＯＡＭフレームのターゲットＤＡフィールドまでのすべてのフィールドを削除し、リプライＯＡＭフレームとしてターゲットＤＡ、意図されるＳＡ、リバースＶＬＡＮ ＩＤ及び他のフィールドを使用することによって、生成されてもよい。あるいは、リプライフレームは、図３Ｂに関してより詳細に上述されたように、オリジナルのＯＡＭフレームに含まれ、及び／又は中間ノードに知られている値から構成されてもよい。

図６〜７は、ＴＬＶ（Ｔｙｐｅ Ｌｅｎｇｔｈ Ｖａｌｕｅ）がＰＢＴネットワークにおいて中間ＯＡＭを実現するのに使用される本発明の他の実施例を示す。図６〜７に示されるように、イーサネット（登録商標）ＯＡＭフレームは、当該フレームがＯＡＭループバックメッセージであることを示すＯｐＣｏｄｅなどの標準化されたＯｐＣｏｄｅを用いてフォーマット化されるかもしれない。これらのＯＡＭメッセージは通常のイーサネット（登録商標）ネットワークにおいて良好に機能するが、ＰＢＴが実装されているとき、中間ネットワーク要素は、詳細に上述されたように、これらのＯＡＭメッセージに応答することができないかもしれない。本発明の実施例によると、イーサネット（登録商標）フレームのＴＬＶフィールドは、組織に固有のＴＬＶ（図６Ａ及び７Ａ）又はＰＢＴネットワークにおいて中間ＯＡＭを実装するのに利用可能な標準的なＴＬＶ（図６Ｂ及び７Ｂ）を指定するのに利用可能である。

特定の機能を実現するため規格団体により割り当てられた多数のＴＬＶ値がある。本発明の実施例によると、１以上の新たなＴＬＶが、ＰＢＴネットワークのＰＢＴトランク上の中間ノードにおいてＯＡＭ機能を実現するため割り当てられるかもしれない。例えば、ＯＡＭフレームが１以上の中間ノードを目的としていることを示すため、ＴＬＶ値が割り当てられてもよい。あるいは、ＴＬＶ値はまた、同一のフレームフォーマットがＰＢＴトランク全体においてＯＡＭを実行するのに利用可能となるように、エンドポイントにおいてＯＡＭ機能を実現するのに利用されてもよい。本実施例のイーサネット（登録商標）フレーム内の１以上のフィールド（ＯｐＣｏｄｅフィールドなど）が、中間ノードにより実行されるＯＡＭ機能のタイプ（ループバック、トレースルート、リンクトレース、ＡＩＳなど）を指定するのに利用されてもよい。あるいは、複数のＴＬＶ値が、中間ノードにより実行される特定タイプの中間ＯＡＭ機能を示すため割り当てられてもよい。

規格団体が、１以上の特定のＴＬＶがＰＢＴネットワークにおいて中間ノードのＯＡＭを実現するのに割り当てられるべきであるか決定するまで、図６Ａ及び７Ａに示されるようなベンダー固有の３１のＴＬＶが使用されてもよい。ＴＬＶフィールド６０２が３１に設定されると、フレームを受信するネットワーク要素は、フレームフォーマットが組織ＯＵＩフィールド６０６により特定される特定のベンダーに固有のものであると判断する。“３１”に設定されたベンダー固有のＴＬＶフィールド６０２を有するＯＡＭフレームを受信すると、ネットワーク要素は、ＯＵＩフィールドの値がネットワーク要素の識別子に一致するか判断するため、組織ＯＵＩフィールド６０６を確認する。そうである場合、それは、ネットワーク装置のベンダーにより規定されたフォーマットに従ってフレームを処理する。そうでない場合、それは、ＴＬＶフィールドを無視し、標準的なＯＡＭフレームとしてＯＡＭフレームを処理する。

ベンダー固有フォーマットの一実施例が、図６〜７に関して説明される。本発明は、この例に限定されず、他のベンダー固有の又はＩＥＥＥにより認められたフォーマットがまた利用可能である。図６に示される実施例では、ＴＬＶフィールドは、ＴＬＶフィールドの長さを示す長さフィールド６０４と、ベンダーＯＵＩフィールド６０６と、実行されるＯＡＭ機能のタイプを示すサブタイプフィールド６０８とを含む。ＯＡＭフレームはまた、上述した実施例に関して説明されたものと同一の意図されるＳＡ６１０と、ターゲットＤＡ６１２と、リバースＶＬＡＮ ＩＤフィールド６１４とを含む。ＯＡＭフレームはまた、特定の実現形態に応じて、１以上の他のＴＬＶ、何れか所望のさらなるフィールド６１６、及びエンドＴＬＶフィールドを有してもよい。

図６Ｂ及び７Ｂに示されるように、規格団体が、１以上のＴＬＶ値がＯＡＭに割り当てられるべきであると決定した場合、フィールド６０２のＴＬＶ値は、ＯＵＩフィールド６０６と、任意的にはサブタイプフィールド６０８とを有する必要性を軽減する規格により割り当てられた値に設定される。他のフォーマットがまた使用可能であり、本発明は図示される特定の例に限定されるものでない。

図８は、本発明の実施例を実現するのに利用可能な処理のフローチャートを示す。図８に示されるように、中間ノードがＰＢＴトランクのＤＡ／ＶＩＤによりアドレス指定されたＯＡＭフレームを受信したとき（８００）、ネットワーク要素がフレームを処理するための２つの方法がある。具体的には、ネットワーク要素は、これが当該ネットワーク要素を目的としたＯＡＭフレームであることをネットワーク要素に示す、フレームの特定位置における特定の値を確認するよう構成されるデータプレーンのハードウェアを有するかもしれない（８０２）。ネットワーク要素においてフレームを処理するハードウェアは、ネットワークプロセッサ、ＡＳＩＣ、ＦＰＧＡ及び他のプログラム可能なハードウェアを有してもよく、“ファーストパス（ｆａｓｔｐａｔｈ）”とここでは呼ばれるであろう。

あるいは、ネットワーク要素は、ソフトウェアにより実現され、ＣＰＵ９０４などのプロセッサにおいてインスタンス化されるイーサネット（登録商標）ＯＡＭ処理９２０（図９に関して後述される）などの制御処理にＯＡＭフレームを転送するかもしれない（８０４）。ＯＡＭフレームが制御処理に転送されると、当該制御処理はさらに、実現される機能のタイプに関して判断してもよい。

ＯＡＭフレームは、中間ノードがＯＡＭフレームなどのフレームを認識し、さらにＯＡＭフレームが中間ノードの１以上により使用されるものであることを認識することを可能にするため、上述されたフォーマット又は他のフォーマットの１つを用いてフォーマット化されてもよい。具体的には、ＯＡＭフレームは、図２〜３に関して説明されたような特別なＥｔｈｅｒＴｙｐｅ値、図４〜５に関して説明されたような特別な若しくはベンダー固有のＯｐＣｏｄｅ、又は図６〜７に関して上述されたような特別な若しくはベンダー固有のＴＬＶを有してもよい。ＥｔｈｅｒＴｙｐｅ、ＯｐＣｏｄｅ及びＴＬＶの組み合わせがまた利用可能であり、本発明は、これらの技術の１つしか使用されない実現形態に限定されるものでない。

ＯＡＭフレームの検出方法に関係なく、必要な場合、中間ノードがＯＡＭフレームに応答する方法は複数ある。例えば、図３Ｃに関して説明されるように、ネットワーク要素は、外部のヘッダフィールドを取り除き、リプライフレームとして結果として得られるフレームを利用してもよい（８０６）。これは、ファーストパス又は制御処理により実現されてもよいが、リプライフレームを構成するのに中間ノードにより実行されるべき処理がほとんど必要でないため、ハードウェアによる実現に適している。

あるいは、リプライフレームは、例えば、図３Ｂに関して上述されるように、生成されてもよい（８０８）。フレームの生成は、ソフトウェア処理により実行されてもよいし、又はファーストパスにＯＡＭフレームの一部を抽出させ、リプライフレームを生成するようそれらを再構成させることによる他の方法により実行されてもよい。

リプライフレームが生成されると、中間ノードは、リプライフレームを送信し（８１０）、それは、リバーストランクのＤＡとＶＩＤとを用いてアドレス指定される。ＯＡＭフレームのタイプに応じて、中間ノードはまた、必要な場合にはトランクのＯＡＭフレームをデスティネーションへのパスの他の中間ノードに転送してもよい。例えば、フレームがループバックフレームであり、それを受信した中間ノードにアドレス指定されていない場合、中間ノードによりリプライは必要でなく、ノードは単にＰＢＴトランクを介しＯＡＭフレームを転送する。ＯＡＭフレームが中間ノードにおいてループバックＯＡＭ機能を実行するのに使用されるためのものである場合、当該ネットワーク要素しかループバックフレームに応答することを求めず、このため、ＯＡＭフレームはＰＢＴトランク上で転送される必要がない。リンクトレースなどの他の機能は、ネットワーク上のすべての又は多数の中間ノードがリプライフレームを生成すること要求するかもしれず、このため、ＯＡＭフレームがＰＢＴトランクを介し転送されるべきかの判断は、実行されるＯＡＭ機能のタイプに依存するかもしれず、当該中間ノードはＯＡＭフレーム又は他のファクタに応答することが要求される。

ネットワーク上でＯＡＭフレームを処理するため、中間ノードは、（１）フレームが中間ノードにアドレス指定されているか、及び（２）何れのタイプのＯＡＭ機能が実装されているかを決定する必要がある。これら２つの処理は、ファーストパスがイーサネット（登録商標）フレームの複数のフィールドを読み込むことが可能であるため、ファーストパスが使用される場合には同時に実行されてもよい。あるいは、これら２つの処理は、ファーストパスにさらなる評価のためすべてのＯＡＭフレームを制御処理に転送させることによって、順次実行されてもよい。本発明は、特定の実現形態に限定されず、本発明の実施例を実現する他の方法がまた利用可能である。

図９は、本発明の実施例を実現するのに使用可能なネットワーク要素の機能ブロック図を示す。一般に、ここに説明される方法は、イーサネット（登録商標）ネットワーク上でＰＢＴ機能を実現するよう構成されるイーサネット（登録商標）スイッチ、ブリッジ、ハブ及び他のネットワーク要素などのネットワーク要素において実現可能である。本発明は、図９に示される実施例又は特定のネットワーク要素に限定されず、ネットワーク要素のアーキテクチャに関係なく何れかのネットワーク要素において実現されてもよい。

図９に示される実施例では、ネットワーク要素１０２は、例えば、上述されたファーストパスを実現するためなど、効率的な方法によりネットワーク上のデータを処理するよう処理されるデータプレーン９００を有する。多数の異なるデータプレーンアーキテクチャが数年間にわたって開発されてきており、本発明は、何れか特定のデータプレーンアーキテクチャに限定されるものでない。このため、図９は特定のデータプレーンアーキテクチャを含むネットワーク要素の一例を示すが、本発明は、図示された実施例に限定されず、多数の異なる構成のイーサネット（登録商標）スイッチ、ブリッジ、ノードなどが、本発明の実施例を実現するのに利用可能である。

図９に示される一例となるネットワーク要素のデータプレーン９００は、複数の入出力カード９０２を有する。入出力カード９０２は、一般にネットワーク１００上のリンク１０４を実現する光ファイバ、銅線、アンテナなどとインタフェースをとる物理ポートを含む。入出力カード９０２はまた、フレームを構成し、他の共通ライン処理機能を実行するよう構成される処理回路を含むかもしれない。

データプレーン９００はまた、図示された実施例では、１以上のＣＰＵ９０６と１以上のネットワーク処理ユニット（ＮＰＵ）９０８とを含む複数のデータサービスカード９０４を有する。ＮＰＵ９０８は、ファーストパス９１０を実現し、さらにＰＢＴトランクの転送状態を含む転送情報ベース９１２を実現する。ＣＰＵ９０６は、例えば、新たなＰＢＴトランクが生成される際には新たな状態情報をＦＩＢに挿入させ、ＰＢＴトランクが破棄される際には古い状態情報をＦＩＢから削除させるのに利用可能な転送状態の変更をＦＩＢにプログラムするよう構成されるＦＩＢエージェント９１４を有してもよい。ＣＰＵはまた、多数の他のプログラムをインスタンス化するかもしれず、本発明は、ＣＰＵがネットワーク要素上で使用される方法により限定されるものでない。

データプレーン９００はまた、本実施例では、データサービスカードの間でフレーム又はデータパケットをスイッチするよう構成されるスイッチファブリック９１６を有する。データサービスカードは、スイッチファブリックへの送信前後にフレームを処理してもよい。

ネットワーク要素１２はさらに、データプレーンが動作する方法を規定するよう構成される制御プレーン９２０を有する。ネットワーク要素の制御プレーンは、通信ネットワークの制御プレーンとやりとりする。具体的には、ネットワーク要素の制御プレーンは、特定のアクションをネットワーク要素において発生させるようデータプレーンを構成し、ネットワークの制御プレーン自体は、ネットワーク要素がトラフィックを処理することを可能にする。

図９に示される実施例では、制御プレーン９２０は、図１〜８に関して上述された各機能を実行するよう制御ロジックを設定することを可能にするデータ及び命令をメモリ９２６からロードするよう構成される制御ロジック９２４を含むプロセッサ９２２を有する。

例えば、メモリ９２６は、他のネットワーク要素とルーティング情報をやりとりするため、リンク状態プロトコル又は他のタイプのルーティングプロトコルを実現するよう構成されるルーティングソフトウェア９２８を格納するかもしれない。

ＰＢＴソフトウェア９３０は、ネットワーク上でＰＢＴトランクが生成されるのを可能にするため、メモリ９０８に含まれる。ＰＢＴソフトウェアは、ＰＢＴトランクセットアップメッセージを受信し、最短パス計算に基づきトランクについて状態が設けられるべきか判断するため、ネットワークの制御プレーンとやりとりする。具体的には、ネットワーク要素がＰＢＴトランクセットアップメッセージを受信すると、ネットワーク要素は、ＰＢＴトランクの転送状態を組み込むことが必要か判断し、そうである場合、ＦＩＢエージェント９１４に適切な状態をＦＩＢ９１２に組み込ませる。状態の設置が必要か否かの判断は、ＰＢＴトランクが生成され、ネットワーク上で通知される方法に依存するかもしれない。

メモリ９２６はまた、ＣＰＵ上で実行される処理が迅速に何れのタイプの情報がすでにＦＩＢ上に組み込まれているか判断できるように、ＦＩＢ９１２に含まれる情報の複製９３２を含むかもしれない。

ネットワーク要素はまた、ネットワーク要素がイーサネット（登録商標）プロトコル及び他のプロトコルをネットワーク上で実現することを可能にするよう構成されるプロトコルスタック９３４を実現してもよい。これは、ここに記載されるＯＡＭ機能を実現するよう構成されるイーサネット（登録商標）ＯＡＭソフトウェア９３６に接続される。例えば、イーサネット（登録商標）ＯＡＭソフトウェアは、受信したＯＡＭフレームに応答して、リプライフレームがネットワーク要素により生成及び送信されることを可能にするよう構成されてもよい。動作について、データプレーンは、ＰＢＴトランク上の中間ノードのＯＡＭ機能を実行するのに使用されるためのものであるイーサネット（登録商標）ＯＡＭフレームを認識するよう構成される。ＯＡＭフレームが特定されると、データプレーン自体がリプライを生成するか、又は制御プレーン９２０のＣＰＵ９０６又はプロセッサ９２２の１以上のプロセスにＯＡＭフレームを送信するようにしてもよい。例えば、ＯＡＭフレームは、処理のためイーサネット（登録商標）ＯＡＭソフトウェア９３６にわたされてもよい。ＯＡＭフレームがイーサネット（登録商標）ＯＡＭソフトウェア９３６にわたされる場合、関連する情報がＯＡＭフレームから抽出され、リバースＰＢＴトランクへの送信のためデータプレーンにわたされるリプライフレームが生成される（必要である場合）。

ここに記載される機能は、ネットワーク要素内のコンピュータ可読メモリに格納され、ネットワーク要素内の１以上のプロセッサ上で実行されるプログラム命令セットとして実現されてもよい。しかしながら、ここに記載されるすべてのロジックは個別のコンポーネント、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などの集積回路、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）又はマイクロプロセッサなどのプログラム可能なロジック装置と共に使用されるプログラムマブルロジック、状態マシーン又はこれらの何れかの組み合わせを含む他の何れかの装置を用いて実現可能であることが、当業者には明らかであろう。プログラマブルロジックは、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）チップ、コンピュータメモリ、ディスク又は他の記憶媒体などの有形な媒体に一時的又は永久的に固定可能である。プログラマブルロジックはまた、コンピュータバスや通信ネットワークなどのインタフェースを介しプログラマブルロジックが送信されることを可能にする搬送波に実現されるコンピュータデータ信号に固定可能である。このようなすべての実施例は、本発明の範囲内に属するものである。

図面に図示され、明細書に記載される各実施例の各種変更及び改良が本発明の趣旨及び範囲内で可能であることが理解されるべきである。従って、上記説明に含まれ、添付した図面に示されるすべての事項は例示的なものであり、限定的に解釈されるものでない。本発明は、以下の請求項とそれに均等なものに規定されるものによってのみ限定される。

１００ ネットワーク
１０２ ネットワーク要素
１０４ リンク
１０６ ＰＢＴトランク
１０８ ネットワーク管理システム

Claims (13)

1. イーサネットネットワークを介し第１の一方向トラフィックエンジニアリング通信パス上でイーサネットＯＡＭを実現するための中間ノードであって、
   当該中間ノードは、
   前記イーサネットネットワークを介した前記第１の一方向トラフィックエンジニアリング通信パスのエンドポイントアドレスを送信先アドレスとして含むＯＡＭフレームであって、前記ＯＡＭフレームが当該中間ノードにおいてＯＡＭ機能を実行するのに利用されることが意図されているという表示をさらに含む前記ＯＡＭフレームを、前記イーサネットネットワークを介し前記第１の一方向トラフィックエンジニアリング通信パス上で受信し、
   リプライメッセージの送信先アドレスとして前記ＯＡＭフレーム内に含まれる意図される送信元アドレスを利用して前記リプライメッセージを生成し、
   前記イーサネットネットワークを介した前記第１の一方向トラフィックエンジニアリング通信パスに続くが、逆方向に延びる前記イーサネットネットワークを介した第２の一方向トラフィックエンジニアリング通信パス上に前記リプライメッセージを送信する、
   よう構成される中間ノード。
2. 前記ＯＡＭフレームはさらに、実行されるＯＡＭ機能のタイプの表示を有する、請求項１記載の中間ノード。
3. 前記ＯＡＭフレームは、該ＯＡＭフレームが前記イーサネットネットワークを介した前記第１の一方向トラフィックエンジニアリング通信パス上の当該中間ノード宛てであるか当該中間ノードが判断することを可能にするための情報を搬送するよう構成されるターゲットＭＡＣアドレスフィールドを有する、請求項１記載の中間ノード。
4. 当該中間ノードはさらに、前記ＯＡＭフレームに対するレスポンスが要求されているか判断するよう構成され、
   当該中間ノードは、レスポンスが要求される場合、前記リプライメッセージを生成する、請求項１記載の中間ノード。
5. 前記ＯＡＭフレームに対するレスポンスが要求されているか判断する際、当該中間ノードは、前記ＯＡＭフレームがターゲット送信先アドレスフィールドに当該中間ノードのＭＡＣアドレスフィールドアドレスを含むか判断するため、前記ＯＡＭフレームのターゲット送信先アドレスフィールドを評価する、請求項４記載の中間ノード。
6. 前記イーサネットネットワークを介した前記第１の一方向トラフィックエンジニアリング通信パスと、前記イーサネットネットワークを介した前記第２の一方向トラフィックエンジニアリング通信パスとの間の相互関係情報は、当該中間ノードにより維持されず、
   前記ＯＡＭフレームは、当該中間ノードが前記イーサネットネットワークを介した前記第２の一方向トラフィックエンジニアリング通信パスを介した送信用に前記リプライメッセージを生成することを可能にする第２の表示を含む、請求項１記載の中間ノード。
7. 前記第２の表示は、前記イーサネットネットワークを介した前記第２の一方向トラフィックエンジニアリング通信パスのＶＬＡＮ ＩＤを有する、請求項６記載の中間ノード。
8. 当該中間ノードはさらに、前記イーサネットネットワークを介した前記第１の一方向トラフィックエンジニアリング通信パスと、前記イーサネットネットワークを介した前記第２の一方向トラフィックエンジニアリング通信パスとの間の相互関係情報を維持するよう構成される、請求項１記載の中間ノード。
9. 前記ＯＡＭフレームは、埋め込みリプライフレームを有し、
   前記リプライメッセージを生成する際、当該中間ノードは、前記埋め込みリプライフレームを抽出する、請求項１記載の中間ノード。
10. 前記ＯＡＭフレームは、前記イーサネットネットワークを介した前記第１の一方向トラフィックエンジニアリング通信パスのためのイーサネットヘッダと、前記リプライメッセージとして利用される埋め込みイーサネットフレームとを有し、
    前記リプライメッセージの生成は、前記イーサネットネットワークを介した前記第１の一方向トラフィックエンジニアリング通信パスのためのイーサネットヘッダのストリップ化を含む、請求項１記載の中間ノード。
11. 前記ＯＡＭフレームに含まれる表示は、Ｅｔｈｅｒｔｙｐｅ値、ＯｐＣｏｄｅ値及びＴｙｐｅ Ｌｅｎｇｔｈ Ｖａｌｕｅ（ＴＬＶ）の１つを含む、請求項１記載の中間ノード。
12. 当該中間ノードはさらに、リプライメッセージの生成前、前記ＯＡＭフレームに対するレスポンスが必要であるか判断するよう構成され、
    当該中間ノードが前記レスポンスが必要であると判断した場合に限って、前記リプライメッセージが生成及び送信される、請求項１記載の中間ノード。
13. イーサネットネットワークを介し第１の一方向トラフィックエンジニアリング通信パス上の中間ノードにおいてイーサネットＯＡＭを実現する方法であって、
    前記イーサネットネットワークを介し前記第１の一方向トラフィックエンジニアリング通信パス上の中間ノードが、前記イーサネットネットワークを介した前記第１の一方向トラフィックエンジニアリング通信パスのエンドポイントアドレスを送信先アドレスとして含むＯＡＭフレームを受信するステップであって、前記ＯＡＭフレームはさらに、前記ＯＡＭフレームが前記中間ノードにおいてＯＡＭ機能を実行するのに利用されることが意図されているという表示であって、Ｅｔｈｅｒｔｙｐｅ値とＯｐＣｏｄｅ値との１つに含まれる前記表示を含む、前記受信するステップと、
    前記中間ノードが、リプライメッセージを生成するステップと、
    前記リプライメッセージの送信先アドレスとして、前記ＯＡＭフレーム内に含まれる第１情報を用いて前記リプライメッセージをアドレス指定するステップと、
    前記中間ノードが、前記イーサネットネットワークを介し第２の一方向トラフィックエンジニアリング通信パスにより前記リプライメッセージを送信するステップであって、前記イーサネットネットワークを介した前記第２の一方向トラフィックエンジニアリング通信パスは、前記イーサネットネットワークを介した前記第１のトラフィックエンジニアリング通信パスのパスに続くが、逆方向に延びる、前記送信するステップと、
    を有する方法。
    

Images