説明

PBTネットワークの中間ノードにおけるイーサネットOAM

【課題】PBTネットワークにおいてOAMを実現する。
【解決手段】OAMは、OAMフレームをPBTトランク106のエンドポイントにアドレス指定し、OAMフレームが中間ノードのOAM機能のために使用されるためのものであるという表示を搬送させることによって、イーサネット(登録商標)ネットワーク100のPBTトランク106上の中間ノードにおいて実現可能である。OAMフレームをPBTトランク106のエンドポイントにアドレス指定することは、OAMフレームがネットワーク100上のPBTトランク106に従うことを可能にする。OAM表示は、OAMフレームが中間ノードのOAM機能を実行するのに使用されるためのものであることを中間ノードに通知する。OAMフレームは、中間ノードがフォワードとリバースのトランクの間の相互関係を格納することを必要とすることを回避するためのリバーストランク情報を有してもよい。

【発明の詳細な説明】
【技術分野】
【0001】
[関連出願の相互参照]
本出願は、その内容が参照することによりここに援用される、2006年10月31日に出願された米国仮出願第60/855,550号“OAM For Differential Forwarding in Address Based Networks”に関連し、その利益を主張する。
[1.発明の分野]
本発明は、通信ネットワークに関し、より詳細には、PBT(Provider Bridged Transport)ネットワークの中間ノードにおけるイーサネット(登録商標)OAMを実現するための方法及び装置に関する。
【背景技術】
【0002】
[2.関連技術の説明]
データ通信ネットワークは、互いに接続され、データを交換し合うよう構成された各種ルータ、スイッチ、ブリッジ、ハブ及び他のネットワーク装置を含むかもしれない。これらの装置は、“ネットワーク要素”とここでは呼ばれる。データは、各装置の間の1以上の通信リンクを使用することによって、IP(Internet Protocol)パケット、イーサネットフレーム、データセル、セグメント又はデータビット/バイトの他の論理的関連などのプロトコルデータユニットをネットワーク要素の間で交換することによって、データ通信ネットワークを介し通信される。特定のPDU(Protocol Data Unit)が、複数のネットワーク要素により扱われ、それがネットワークを介し伝送されるとき、複数の通信リンクを横断するかもしれない。
【0003】
通信ネットワーク上の各種ネットワーク要素は、ここでプロトコルと呼ばれる所定のルールセットを用いて互いに通信する。ネットワーク要素間の送信についてどのように信号が生成されるべきか、プロトコルデータユニットが何れの各種態様に類似すべきか、ネットワーク要素によりパケットがネットワークを介しどのように処理又はルーティングされるべきか、ルーティング情報にかかる情報がネットワーク要素の間でどのように交換されるべきかなど、ネットワーク上の異なる通信態様を管理するため、異なるプロトコルが使用される。
【0004】
イーサネット(登録商標)は、IEEE(the Institute of Electrical and Electronics Engineers)によって規格802として定義された周知のネットワーキングプロトコルである。当初は、イーサネット(登録商標)は、会社や大学キャンパスの事業用ネットワークなどのローカルエリアネットワークにおいて利用された。イーサネット(登録商標)規格の変更は、メトロポリタンエリアやワイドエリアネットワークなどのより大規模なネットワークについてイーサネット(登録商標)が現在検討されている所までイーサネット(登録商標)が進化することを可能にしてきた。
【0005】
イーサネット(登録商標)がより大規模なキャリアネットワークにおいて使用されることを可能にした拡張の1つは、ネットワークプロバイダにより所望されるOAM(Operation,Administration and Maintenance)機能をイーサネット(登録商標)がサポートすることを可能にしたことである。接続性チェック、ループバック、トレースルート、アラーム通知信号などのOAM機能は、ネットワークが正常に動作しているか判断し、ネットワーク上に不具合が生じたときは不具合を診断/隔離することをネットワークプロバイダに可能にするよう実現される必要がある。
【0006】
従来、イーサネット(登録商標)は、ベストエフォート技術として開発された。しかしながら、イーサネット(登録商標)がキャリアネットワークに適応化されるとき、ネットワークを設計できることが所望されるようになった。具体的には、キャリアは、特定のパケットがネットワークを介し取得されるパスを知ることができるように、ネットワーク上のエンドポイント間にパスを生成することを所望するかもしれない。これに関連して開発されている技術の一例は、PBT(Provider Bridged Transport)と呼ばれる。PBTは、IEEE802.1ahに関連し、PBB−TE(Provider Backbone Bridges−Traffic Engineering)活動として説明されている。PBTは、より詳細には、その内容が参照することによりここに援用される、米国特許出願第10/818,685号“Traffic Engineering in Frame−Based Carrier Networks”に記載される。
【発明の概要】
【発明が解決しようとする課題】
【0007】
図1は、複数のイーサネット(登録商標)スイッチ102がリンク104を介し相互接続される一例となるネットワーク100を示す。プロバイダブリッジドトランク106は、特定のVLAN ID(VID)とデスティネーションMACアドレス(DA)を有するトラフィックフローとして定義されるかもしれない。PBTでは、ネットワークを介したパスは、トランク(trunk)又はトンネル(tunnel)と呼ばれ、MPLSトンネルと同様のものであると考えられてもよい。ここで用いられる“トランク”という用語は、PBTパスを記述するのに用いられる。典型的には、ネットワーク管理ステーションは、ネットワークを介し生成されるトランクを規定し、トランクは、ネットワーク管理ステーションからの直接的な設定によって、又はシグナリングプロトコルを用いて、ネットワーク要素上で確立される。ネットワーク管理ステーションは、当該技術に知られている方法で、ネットワーク上のデータフローを運営するようトランクを規定するかもしれない。さらに、トランクは、所望される場合、ネットワーク要素によって、ルーティング情報の交換を介し自動的に設定されてもよい。VLAN ID(VID)タグと特定のデスティネーションMACアドレス(DA)との組み合わせは、特定のトランクを一意的に特定し、これにより、ネットワーク上のネットワーク要素はVID/DAに基づきトラフィックを転送できる。トランクのシグナリングは、特定のVID/DAの組み合わせを有するフレームがソースからデスティネーションへのパスに沿って転送されるように、中間のネットワーク要素にVID/DAのためのそれらのFIBに転送エントリを組み込ませる。
【0008】
PBTトランクは、ネットワーク上の一方向のパスである。一般に、ノードのペアの間には、トラフィックがノード間で双方向に送信されることを可能にするため、各方向に1つずつの2つのトランクが設定される。様々な理由のため、これらのトランクは、典型的には、同じパス(中間ノードとリンクの同一のセット)に沿って設定されるが、このように設定されることが要求されるものでない。PBTが実現される方法に応じて、トランク上の中間ノードがネットワーク上のソースとデスティネーションの各ペア間で反対方向に延びるトランクのための情報を転送する相関関係を維持しないように、フォワード及びリバーストランクは互いに独立しているかもしれない。
【0009】
中間ノードは、特定のデスティネーションMACアドレス(DA)とVIDとを有し、特定のポートを介し到来するフレームが特定の方法により転送されるべきであることを示すためのエントリを各自の転送テーブルに組み込むことによって、トランクの転送状態を組み込む。例えば、図1において、ソースノードAからデスティネーションノードDに延びる第1トランク106aが存在すると仮定する。中間ノードBは、と規定されたDA/VIDを有するフレームがノードCに転送されるべきであることを示すため、それの転送情報ベース(FIB)に転送状態を組み込む。同様に、ノードCは、DA/VIDを有するフレームがノードDに転送されるように、それのFIBに転送状態を組み込む。
【0010】
リバースパスでは、トランクはノードAのデスティネーションアドレス(DA)により特定され、独立したVIDはまた、ノードDからノードAへのフレームのフローに全体に割り当てられる。FIBエントリが複雑化することを回避するため、2つのトランク106a,106bのFIBエントリは関連付けされない。説明されるようなネットワークにおける相互関係は比較的単純なものであるように見えるかもしれないが、ネットワークのサイズが増大し、このようなPBTトランクが数百万個も生成されると、トランク間の相互関係は取るに足らないものにならなくなる。さらに、マルチキャストが実現されるとき、リバースパストランクは複雑に相関するかもしれない。
【0011】
フォワードとリバースのPTBトランクの間の相互関係を維持しないことに加えて、PBTトランクに沿った中間ノードは、PBTトランクに沿った中間ポイントに関する情報を有しないかもしれず、このため、トランクがノードAとノードDとの間で取得するパス上の中間ポイントのアドレスを知らないかもしれない。さらに、中間ポイントは、DA/VIDに基づきフレームを転送することしかしないよう構成されるかもしれない。到来したがFIBのエントリに一致しないフレームは、ネットワーク要素により破棄されるかもしれない。従って、イーサネットOAMフレームがPBTトランク106aを介しネットワーク要素Cにアドレス指定される場合、上流の中間ネットワーク要素Bは、フレームの転送状態を有さず、フレームを破棄するかもしれない。このため、ネットワーク要素Cは、OAMフレームを受信できず、それに応答することができないことになる。
【0012】
フォワードとリバースのパスの間の相互関係の可能性のある欠落と、中間ノードにアドレス指定されるフレームがネットワーク上の他の中間ノードにより破棄されるという事実との組み合わせは、PBTネットワークにおける中間ノードOAMを複雑化する。特に、OAMはソースノードAとデスティネーションノードDのメッセージングエンドポイント(MPE)の間でエンド・ツー・エンドに規定されるかもしれないが、メッセージング中間ポイント(MIP)が中間ノードにおいて規定されていても、これらのノードはOAMフレームを処理せず、単にPBTトランクを介しOAMフレームを転送するだけである。さらに、中間ノードが直接アドレス指定される場合、それらは、転送情報ベースが中間ノードにかかるDAとVIDとのエントリを有しないかもしれないため、フレームを認識できず、PBTによると、中間ノードは転送状態を含まないフレームを破棄する。
【0013】
最終的には、中間ノードがOAMメッセージを認識し、OAMメッセージを処理しても、リバース方向におけるトランクにより使用されるVIDを有しないため、OAMメッセージに応答する仕方を知ることができない。このため、中間ノードにより生成されるOAMリプライメッセージは、認識されないため、他の中間ノードにより破棄されることになるであろう。すなわち、中間ノードはフォワードパスで使用されるVIDと、リバースパスで使用されるVIDとの間の相互関係を有しないかもしれないため、中間ノードはA)のMACアドレスなど、リバースパスで使用されるデスティネーションアドレスを抽出可能であるが、それは、その他の中間ノードがリバーストランク106b上のDAと共に使用するVIDを知ることはないかもしれない。このため、中間ノードは、リバーストランク上の通常のフレームとしてその他の中間ノードにより処理されるフレームを生成することができないかもしれない。従って、OAMメッセージが中間ノードにより受信及び処理されても、中間ノードは、リバーストランク106bを介し送信可能なリプライフレームを生成することができないかもしれない。このため、PBTネットワークにおいてOAMを実現できることが所望されるであろう。
【課題を解決するための手段】
【0014】
中間ノードは、PBTトランク上でOAMフレームを認識し、PBTトランクのエンドポイントにアドレス指定されるが、それらが中間ノードのOAM機能を実現するのに使用されるという通知を含むOAMフレームに応答するよう構成されてもよい。本発明の各実施例を実現する他の方法もまた利用可能であり、本発明はこれらの手段に限定されないが、3つの手段が提供される。第1実施例は、EtherType値が、PBTトランク上の中間ノードに当該OAMフレームが中間ノードにより処理されるべきであることを示すため、中間ノードのOAMフレームとしてフレームを特定するのに使用される。本発明の他の実施例によると、OpCode値が、当該OAMフレームが中間ノードにより処理されるべきであることを中間ノードに示すのに使用される。本発明の他の実施例によると、TLV(Type Length Value)値が、当該OAMフレームが中間ノードにより処理されるべきであることを中間ノードに示すのに使用される。
【0015】
中間ノードがフォワードトランクとリバーストランクとの間の相互関係を維持することを要求されることを回避するため、OAMフレームに応答して生成されるリプライメッセージがリバーストランクを介しわたされるように、リバーストランクのDA/VIDなどのリプライアドレス情報を有するよう構成されてもよい。
【発明の効果】
【0016】
本発明によると、PBTネットワークにおいてOAMを実現できる。
【図面の簡単な説明】
【0017】
【図1】図1は、PBTトランクが実現される一例となるイーサネット(登録商標)ネットワークの一部の機能ブロック図である。
【図2】図2は、本発明の実施例によるOAM Ether−typeを用いたPBTトランクの中間ノードにおけるOAMを実現するよう構成されるイーサネット(登録商標)フレームのブロック図である。
【図3A】図3Aは、本発明の実施例による新たなEther−typeを用いたPBTトランクの中間ノードにおけるOAMを実現するよう構成されるイーサネット(登録商標)フレームの他の実施例のブロック図である。
【図3B】図3Bは、本発明の実施例による図3Aのイーサネット(登録商標)フレームから生成され、PBTトランクの中間ノードによりOAMリプライメッセージを実現するよう構成されるイーサネット(登録商標)フレームのブロック図である。
【図3C】図3Cは、本発明の実施例による図3Aのイーサネット(登録商標)フレームから生成され、PBTトランクの中間ノードによりOAMリプライメッセージを実現するよう構成されるイーサネット(登録商標)フレームのブロック図である。
【図4A】図4Aは、本発明の実施例によるベンダー固有のOpCodeを用いたPBTトランクの中間ノードにおけるOAMを実現するよう構成されるイーサネット(登録商標)フレームのブロック図である。
【図5A】図5Aは、図4Aのイーサネット(登録商標)フレームの各フィールドの相対的な配置及びサイズをより詳細に示すブロック図である。
【図4B】図4Bは、本発明の実施例による標準化されたOpCodeを用いたPBTトランクの中間ノードにおけるOAMを実現するよう構成されるイーサネット(登録商標)フレームのブロック図である。
【図5B】図5Bは、図4Bのイーサネット(登録商標)フレームの各フィールドの相対的な配置及びサイズをより詳細に示すブロック図である。
【図6A】図6Aは、本発明の実施例によるベンダー固有のTLVを用いたPBTトランクの中間ノードにおけるOAMを実現するよう構成されるイーサネット(登録商標)フレームのブロック図である。
【図7A】図7Aは、図6Aのイーサネット(登録商標)フレームの各フィールドの相対的な配置及びサイズをより詳細に示すブロック図である。
【図6B】図6Bは、本発明の実施例による標準化されたTLVを用いたPBTトランクの中間ノードにおけるOAMを実現するよう構成されるイーサネット(登録商標)フレームのブロック図である。
【図7B】図7Bは、図6Bのイーサネット(登録商標)フレームの各フィールドの相対的な配置及びサイズをより詳細に示すブロック図である。
【図8】図8は、本発明の実施例を実現するのに利用可能なプロセスを示すフロー図である。
【図9】図9は、本発明の実施例を実現するのに利用可能なネットワーク湿地の機能ブロック図である。
【発明を実施するための形態】
【0018】
本発明の各態様は、特に添付した請求項において指摘される。本発明は、同様の参照が同様の要素を示す以下の図面により示される。以下の図面は、説明のためだけに本発明の各種実施例を開示し、本発明の範囲を限定するものでない。簡単化のため、必ずしもすべての構成要素がすべての図面にラベル付けされるとは限らない。
【0019】
本発明の完全な理解を提供するため、以下の詳細な説明は、多数の具体的詳細を与える。しかしながら、当業者は、本発明がこれら具体的詳細なしに実現可能であることを理解するであろう。また、本発明を不明りょうにしないように、周知の方法、処理、構成要素、プロトコル、アルゴリズム及び回路は詳細には説明されない。
【0020】
図1は、ネットワーク要素102がリンク104により相互接続される一例となるイーサネット(登録商標)ネットワーク100の一部を示す。PBTトランク106a,106bは、その内容が参照することによりここに援用される、米国特許出願第10/818,685号“Traffic Engineering in Frame−Based Carrier Networks”に詳細に説明されるように、イーサネット(登録商標)ネットワーク100を介し確立されるかもしれない。
【0021】
PBTトランク106は、中間ノードにトランクパスを介しトランクDA/VIDを有するトラフィックを転送される転送状態を中間ノードに組み込ませることによって、イーサネット(登録商標)ネットワーク100を介し一方向に延びるよう生成される。通常は、2つのトランクが、ネットワーク上の同一パスに沿って2つの異なる方向に形成され、これにより、パスのエンドにあるノード間でトラフィックが双方向に送信可能となる。ネットワーク管理システム108は、トランクを規定及び確立する他の方法がまた利用可能であるが、トランクを生成するのに利用されてもよい。
【0022】
PBTネットワークでは、トランク106が確立されるとき、ネットワーク要素は、トランク上のトラフィックが規定されたパスに沿って転送されるように、トランクの転送状態を組み込む。例えば、図示されたネットワークでは、PBTトランクのペア(106A,106B)が、ネットワーク要素Aとネットワーク要素Dとの間に延びる。中間ノード(ネットワーク要素B及びC)は、トランクを実現するため転送状態を組み込む。トランク上のトラフィックは、トランクエンドポイントのMACアドレス(デスティネーションMACアドレス又はDA)とVPN ID(VID)とを用いて特定される。DAとVIDの組み合わせは、DAを目的とする異なるトラフィックがネットワーク上の異なるパスに従うように、デスティネーションとフロートを一意的に特定する。さらに、DA/VIDの組み合わせは、一意となることが予想され、このため、さらなるラベルがトラフィックに付加されることを要することなく、トラフィックを特定し、トランクを介しトラフィックを転送するのに中間ノードのデータプレーンにより利用可能である。
【0023】
本発明の実施例によると、PBTトランクエンドポイントにアドレス指定されたイーサネット(登録商標)OAMフレームは、当該OAMフレームがPBTトランクの中間ノードの1以上において中間ノードのOAM機能を実現するのに利用されるべきであることを、PBTトランク上の中間ノードに通知するよう構成される。後述されるように、この通知は、EtherType、OpCode、TLV又はイーサネット(登録商標)フレームの形式により、他のフィールドにおいて実現されてもよい。
【0024】
イーサネット(登録商標)OAMは、ループバック、リンクトレース、アラーム通知信号(AIS)及び他の従来のOAMを実現するのに利用されてもよい。以下のいくつかの具体例はループバック及びリンクトレースを実現するため、特定のOAMフレームを使用することに着目しているが、本発明はこれに限定されるものでなく、OAMフレームはその他のOAM機能を実現するのにも利用されるかもしれない。
【0025】
図1B及び1Cは、以下で詳細に説明されるOAMフレームを用いて実現可能なOAM機能の異なる複数の形式を示す。特に、図1Bは、OAMフレームが中間ノードCにおいてループバックOAM機能を実現するのに使用される実施例を示す。本実施例では、中間ノードCがトランク106A上で中間ノードOAMメッセージを受信すると、リプライOAMメッセージ108を生成し、リプライリバーストランク106Bを介し当該リプライをソースノードAに送信する。周知なように、ループバックは、特定のノードにOAMメッセージに応答させ、ネットワークのパス上の特定のネットワーク要素をポーリングすることが可能である。
【0026】
図1Cは、実行されるOAM機能がリンクトレースである点を除いて図1Bと同様である。例えば、図1Cに示されるように、リンクトレースはノードAとノードCとの間で実行されると仮定される。OAMフレームがトランク106Aを介し送信されると、当該OAMフレームを受信した各中間ノードは、リプライ108を生成し、リバーストランク106Bを介し当該リプライをソースノードAに送信する。このため、本例では、中間ノードBとCは共に、リプライメッセージ108を生成することになるであろう。
【0027】
図2は、イーサネット(登録商標)フレーム200を示す。図2に示されるように、イーサネット(登録商標)フレームは、一般に、デスティネーションMACアドレス(B−DA)202と、ソースMACアドレス(B−SA)204とを含む。図1のイーサネット(登録商標)ネットワークにおけるソース及びデスティネーションMACアドレスは、一般には、プロバイダのアドレッシングスペースである、ネットワーク要素102のバックボーン(B)MACアドレスである。
【0028】
OAMフレームは、図示された具体例では、0x88A8であるEtherTypeフィールド206を有する。イーサネット(登録商標)フレームはまた、当該フレームが何れのタイプのVLANに関連するか特定するのに使用されるB−VLAN ID(VID)フィールド208を有する。このタグは、クライアントにより指定されたタグのためのフレームのその他の部分をチェックすることなく、イーサネット(登録商標)ネットワークのネットワーク要素102がフレームにかかるVLANを特定することを可能にする、Q−タグとしても知られるプロバイダにより実装されるタグである。OAMフレームは、PBTトランク上のトラフィックを転送するのに使用される予想されるDA/VIDを含むため、通常の方法によりPBTトランク上で転送される。
【0029】
イーサネット(登録商標)フレーム200はまた、当該フレームを処理するネットワーク要素のデータプレーンに、当該フレームのフレームタイプを示す第2Ether−type210を含む。例えば、EtherTypeフィールド210は、フレームがデータフレーム、制御フレーム、又は本発明の実施例によるトランク上でOAM機能を実現するためPBTトランクの中間ノードsにより使用されるイーサネット(登録商標)OAMフレームであることを示す値を含むかもしれない。他の既知の機能を実現するため、他の値がまたEtherTypeフィールド210に含まれてもよい。
【0030】
図3は、PBTトランク上の中間ノードにおいてイーサネット(登録商標)OAMを実現するのに利用可能なイーサネット(登録商標)フレームの他の実施例を示す。図3に示されるように、イーサネット(登録商標)フレーム300は、当該フレームがOAMフレームであることを示すものとして中間スイッチ102により認識可能な新たなEther−type値302を有する。
【0031】
Ether−type302は、中間ノードがそれらを対象としている可能性のあるOAMフレームを抽出することを可能にする。中間ノードが、当該フレームが中間ノードOAMフレームであることを示す値に設定されたEther−type値302を有するフレームを受信すると、当該中間ノードは、さらなるアクションがOAMフレームに関して要求されているか判断するため、OAMフレームの他のフィールドを確認する。
【0032】
図3に示される例では、OAMフレームは、当該OAMフレームが特定の中間ノードにアドレス指定されているかファーストパス(イーサネット(登録商標)スイッチのデータプレーン)が特定することを可能にするターゲットデスティネーションアドレス(DA)304を有する。ターゲットDAは、当該OAMフレームが特定の中間ノードにおいてループバック機能を実現するのに使用される個別MACアドレスであるか、又は当該OAMフレームがリンクトレース機能を実現するのに使用されるグループMACアドレスであるかもしれない。これについて、ループバックは特定のノードに特定のフレームの受信に応答させるるが、リンクトレースは特定のパス上のすべての中間ノードに特定のフレームの受信に応答させることに留意されたい。
【0033】
OAMフレームはまた、当該OAMフレームがPBTトランクエンドポイントにより生成されていないとき、OAMリプライフレームをOAMフレームのソースアドレスに導くことを可能にする意図されるソースアドレス(SA)306を有する。一般に、OAMフレームがPBTトランクのソースに送り返される場合、意図されるSA306は、バックボーンソースアドレス(B−SA)204と同じになる。しかしながら、OAMフレームが意図されるSAを含むフィールドを有することを可能にすることによって、OAMフレームは、PBTトランクのソースに送り返されることが自動的には要求されない。
【0034】
OAMフレームはまた、中間ネットワーク要素により実現されるOAM機能のタイプを特定するのに利用可能なEther−type値308を有してもよい。このフィールドは、中間ノードが受信したOAMフレームから図3Aのヘッダ322を取り除くことによって、リプライフレームを発行することを可能にし、結果として得られるフレームは有効なリプライフレームとなる。このフィールドは、EtherType値302が当該情報を伝えるのに十分具体的である場合、所望されるときちには排除されてもよい。例えば、異なるEther−type値が各OAM機能について指定される場合、第2Ether−typeフィールド308は冗長であるかもしれない。
【0035】
OAMフレームはまた、リバースVLANが搬送可能なリバースVLAN IDフィールド310を有する。リバースVLAN ID(VID)は、リプライフレームをアドレス指定するため、意図されるSA(又はOAMフレームがトランクエンドポイントにおいて発信されたB−SA)と共に使用される。例えば、図1に示されるように、AからDへのトランク106aのフレームは、ネットワーク要素DのDAと第1VIDとを用いて、ネットワーク要素Dにアドレス指定される。DAとVIDの組み合わせは、AからDへのトランク106a上のフレームを特定するのに使用される。ネットワーク要素Dからネットワーク要素Aへのリバーストランクでは、フレームは、B−SAであるか、又は図3に示されるフレームの意図されるSA306であるネットワーク要素AのデスティネーションMACアドレスにより特定される。中間ノードBとCは、トランク106aと106bとの間の相互関係を維持していないため、これらの中間ノードは、リバーストランク106bを介しリプライメッセージを送信するためのリバースVLAN ID(リバーストランク106bのVIDなど)を必要とする。中間ノードがリバーストランクのVIDを知ることを可能にするため、リバースVLAN IDフィールド310は、中間ノードがフォワードトランクとリバーストランクとの間の相互関係を維持する必要がないように、当該情報を搬送するのに利用可能である。
【0036】
図3B及び3Cは、本発明の実施例による中間ノードにより生成されるリプライフレームの実施例を示す。図3Bに示される実施例では、リプライフレームは、OAMフレームの意図されるSAフィールドに搬送される値を使用し、当該アドレス値をリプライB−DAとして使用することによって生成される。OAMフレームのターゲットDA304は、上述されるリプライB−SAとして使用される。Ether−type値は、OAMフレームのEther−typeフィールド308から取得され、リプライVIDは、OAMフレームのリバースVLAN IDフィールド310から取得される。OAMペイロードがまた、任意的に含まれてもよい。
【0037】
図3Cは、リプライOAMメッセージが、単にOAMフレームのヘッダの一部を削除し、これにより生成された新たなリプライフレームをリバースPBTトランクを介し送信することによって構成される他の実施例を示す。特に、図3Cに示されるように、ターゲットDAフィールド304と意図されるSAフィールド306とがわずかに変更される場合、中間ノードは単に、フィールド322(B−DA314,B−SA316,Ethertype318,B−VLAN ID320,新たなEther−typeフィールド302)を取り除き、リプライフレームを生成してもよい。本実施例では、ターゲットDAフィールド304は、リプライメッセージが送信されるOAMのソースのデスティネーションアドレスを搬送するのに使用される。リバースVLAN IDは、リプライフレームがリバーストランク上で搬送されることを可能にするリバーストランク106bのVIDである。本実施例の意図されるソースアドレスフィールド306は、OAM機能を実行しており、リプライメッセージB−SAフィールドとして使用される中間ノードのMACアドレスである。本実施例では、リプライOAMフレームがオリジナルのOAMフレームの初期的な複数のフィールドを削除する以外の何れの処理を中間ノードが実行することを要求することなく、Ethertypeフィールド308は、リプライOAMフレームが通常のイーサネット(登録商標)フレームとして現れることを可能にするため、オリジナルのOAMフレームに設けられる。このため、本例では、Ethertypeフィールド308は、リプライOAMフレームがこのEthertypeを有することを可能にするよう、0x88A8に設定されてもよい。他のEthertypeが、特定の実現形態に関して所望されるように使用されてもよい。
【0038】
図3Cに示される実施例では、OAMフレームのソースは、リプライOAMフレームを実質的に生成し、新たなEthertype値を有するイーサネット(登録商標)ヘッダによりリプライOAMフレームをカプセル化する。この新たなEthertype値は、PBTトランク上の中間ノードが中間ノードOAMフレームとして当該フレームを特定することを可能にする。OAMフレームに応答するため、ノードは単にカプセル化されたヘッダフィールド322を取り除き、結果として得られるカプセル解除されたリプライOAMフレームをリバースパス106bを介し送信してもよい。これは、中間ノードがノード制御プレーンによるフレームの処理を要することなく、リプライフレームをハードウェアにより生成することを可能にする。
【0039】
図3Cに示される実施例が、それに埋め込まれた意図されるリプライフレームを有するOAMフレームを送信することにより、OAM機能の実現形態に関して説明されたが、本発明の本実施例はまた、他の機能を実行するのに利用されてもよい。特に、イーサネット(登録商標)ネットワーク上のノードにより送信されるイーサネット(登録商標)メッセージにフレームを埋め込むという考えは、OAMに関連する機能以外の多数の機能を実現するのに利用されてもよい。実質的に、本実施例は、内部のMACヘッダと外部のMACヘッダがプロバイダ(B)MACアドレッシングスペースを用いて生成され、オリジナルフレームとリプライフレームの双方がプロバイダネットワークを介し伝送されるように、Mac−in−Macカプセル化リプライフレームを有する。これはOAM機能を実現するのに利用可能であるが、リプライフレームはしばしばOAM機能の実現と共に利用されるため、あるネットワーク要素が他のネットワーク要素に同一ネットワーク上でフレームを送信させることを可能にするのに、他のコンテクストにおいて利用可能であるとき、本発明はこの方法に限定されない。
【0040】
新たなEtherTypeを使用してOAM機能を可能にすることは効果的であるかもしれないが、本発明はこの実施例に限定されず、中間ノードにおいてOAM機能を実現する他の方法がまた利用可能である。さらなる2つの実施例が、図4〜5及び6〜7に関して説明される。
【0041】
図4〜5に示される実施例では、イーサネット(登録商標)フレームがイーサネット(登録商標)フレームのOpCodeフィールドを用いることによりPBTトランクの中間ノードの1以上を目的とするOAMフレームであることが、中間ノードに通知される。イーサネット(登録商標)規格は、イーサネット(登録商標)ネットワーク上のネットワーク要素によりフレームに対して実行される異なるタイプの処理を規定するのに利用可能な多数の異なるオペコード(OpCode)を規定する。本発明の実施例によると、1以上のOpCodeが、受信したフレームのOpCodeフィールドをチェックすることによって、ネットワーク要素が当該フレームがPBTトランク上の中間ノードを目的としたOAMフレームであるか判断し、そうである場合、OAMフレームがどのように処理されるべきか判断できるように、OAM機能を実現するよう定義されてもよい。
【0042】
OpCodeフィールド値は、ネットワーク要素が特定のOpCodeを有するフレームをどのように処理すべきかに関して同意ahsに達するとIEEEにより割り当てられる。OpCodeが割り当てられると、OpCodeにかかる機能が設定され、規格に準拠するすべてのベンダが規定されたOpCodeを有するフレームを同一の方法により処理する。現在、多数のOpCodeが特定の機能を実現するよう割り当てられており、任意的には、1以上のOpCodeが、PBTネットワークの中間ノードにおいてOAM機能を実現するよう割り当てられるかもしれない。同様に、IEEEはまた、EtherType値(図2〜3に関連して上述された)と、TLV値(図6〜7に関連して後述される)とを割り当てる。PBTトランクにおいて中間ノードのOAM機能を実現することに関連して使用するため、1以上の特定の値がIEEEにより割り当てられるかもしれない。
【0043】
すでに割り当てられたOpCodeの1つは、特定のベンダーに特有の特殊な方法によりフレームがフォーマット化されたことを、ネットワーク上の他のすべてのネットワーク要素にベンダーが指定することを可能にするベンダー固有のOpCodeである。現在バージョンの規格では、フレームが特定のベンダーのフォーマットに従ってフォーマット化されることを指定するため、OpCode51が使用される。OAMフレームのソースにOAMフレームのOpCodeを“51”に設定されることによって、OAM機能は、特定のネットワーク装置ベンダーにかかるネットワーク要素上で実現可能である。規格団体が1以上の中間ノードOAM値を採用する場合、すべてのネットワーク装置ベンダーは、OpCodeを同様にして実現することが要求され、このため、OAM機能は何れのベンダーがネットワーク要素を製造したかに関係なく機能する。
【0044】
標準化処理が完了しておらず、1以上のOpCode値がOAM機能を実現するため割り当てられていなかったため、51のベンダー固有のOpCodeがOAM機能を実現するのに使用される実施例が説明される。標準化処理が完了した場合、フィールドの一部は必要とされなくなるため、本発明はこの特定の実現形態に限定されない。図4に示されるように、当該フレームがOAMフレームであることをネットワーク要素に示すOAM Ether−typeフィールドの後に、イーサネット(登録商標)フレームは、メンテナンスレベルフィールド(MEL)402と、何れのバージョンの規格が実装されているか示すバージョンフィールド404とを含む。上述されるOpCodeフィールド406が次にあり、本実施例では、当該OAMフレームがベンダー固有の方法によりフォーマット化されたことをネットワーク上のネットワーク要素に示す“51”に設定された。規格団体が異なるOpCode値を採用する場合、当該フィールドは、“51”から規格団体により採用された値に変更されるかもしれない。さらに、これが実装される方法に依存して、後述される他の複数のフィールドは、使われなくなり、及び/又は再配置されるかもしれない。
【0045】
本実施例では、OpCode値の後に、1以上のベンダー固有の特徴を示すのに利用可能な1以上のフラグが続く。本発明は、フラグの使用方法又はフラグフィールド408を含めることに限定されるものでない。
【0046】
フラグフィールドの後に、ベンダー固有フィールドの開始を示すTLV(Type Length Value)オフセットフィールドが続く。
【0047】
上述されるように、OpCode値51は、OAMフレームがベンダー固有の方法によりフォーマット化されることを示す。ネットワーク要素が当該OAMフレームを理解可能か判断することを可能にするため、TLVオフセットフィールドの後に、フレームフォーマットを読み込み可能なベンダーを特定するOUI(Organizationally Unique Identifier)値が続く。従って、OpCode=51を有するOAMフレームが受信されると、ネットワーク要素は、当該OAMフレームがネットワーク要素と同じベンダーに係るものであるか判断するため、OUIフィールド412を確認する。そうである場合、ネットワーク要素は、当該OAMフレームに関して何れのOAM機能が実装されるか判断するため、サブOpCodeフィールド414を確認する。例えば、ノーテルネットワークにより製造されたネットワーク要素がOpCodeフィールド=51のOAMフレームを受信した場合、OUIフィールドがノーテルネットワークOUIを有しているか判断するため確認する。そうである場合、それは、何れのタイプのOAM機能が実行されるか判断するため、サブOpCodeフィールド414を確認する。OUIフィールドがノーテルネットワークOUIに一致しなかった場合、当該フレームは標準的な方法により扱われ、残りのベンダー固有フィールドは無視される。
【0048】
図4〜5に示されるOAMフレームはまた、図3に示される実施例に類似した複数のフィールドを含む。具体的には、サブOpCodeフィールド414の後に、OAMフレームは、PBTトランク上の中間ノードの1以上を特定するのに使用されるターゲットDAと、リプライが送信されるべきソースMACアドレスである意図されるSAと、リバーストランク106bにリプライを配置するのに使用されるリバースVLAN IDフィールドとを有する。これらのフィールドは、図2〜3に関して上述されたものと同じである。OAMフレームはまた、実現形態に応じて1以上のさらなるフィールドを有してもよく、任意的には、エンドTLVを有してもよい。フレームの特定の順序は、OAM機能を実現するのに使用される特定のハードウェアに従って最適化されてもよく、従って、本発明は、図4〜5に関して上述された特定の順序に限定されるものでない。同様に、上述されたフィールドの1以上は、OpCodeがOAM機能を実現するのに使用される方法に応じて、所望のフィールド又はフィールドのいくつかがマージされてもよい場合には、省略されてもよい。例えば、標準化されると、OUIフィールド412に対する必要性は低下することが予想される。
【0049】
図4B及び5Bは、標準化されたOpCode値がPBTトランク上の中間ノードにおいてOAM機能を実現するのに使用される本発明の実施例を示す。図4Bに示されるように、フィールドの一部は同一であるが、OpCode値406がベンダー固有の値51から他の値Xに変更されているという点で、図4Bに示されるOAMフレームは図4Aに示されるフレームと異なっている。規格団体により選択される特定の数字は関係ない。また、規格を実現するすべてのネットワーク要素が同じ方法によりフレームを処理するため、OAMフレームは、組織OUIフィールド412を有する必要はない。同様に、中間ノードにより実行されるOAM機能のタイプを指定するよう構成される場合には保持されるかもしれないが、OAMフレームはサブOpCodeフィールド414を有する必要はない。
【0050】
リプライフレームは、図3Cに関してより詳細に上述されたように、OAMフレームのターゲットDAフィールドまでのすべてのフィールドを削除し、リプライOAMフレームとしてターゲットDA、意図されるSA、リバースVLAN ID及び他のフィールドを使用することによって、生成されてもよい。あるいは、リプライフレームは、図3Bに関してより詳細に上述されたように、オリジナルのOAMフレームに含まれ、及び/又は中間ノードに知られている値から構成されてもよい。
【0051】
図6〜7は、TLV(Type Length Value)がPBTネットワークにおいて中間OAMを実現するのに使用される本発明の他の実施例を示す。図6〜7に示されるように、イーサネット(登録商標)OAMフレームは、当該フレームがOAMループバックメッセージであることを示すOpCodeなどの標準化されたOpCodeを用いてフォーマット化されるかもしれない。これらのOAMメッセージは通常のイーサネット(登録商標)ネットワークにおいて良好に機能するが、PBTが実装されているとき、中間ネットワーク要素は、詳細に上述されたように、これらのOAMメッセージに応答することができないかもしれない。本発明の実施例によると、イーサネット(登録商標)フレームのTLVフィールドは、組織に固有のTLV(図6A及び7A)又はPBTネットワークにおいて中間OAMを実装するのに利用可能な標準的なTLV(図6B及び7B)を指定するのに利用可能である。
【0052】
特定の機能を実現するため規格団体により割り当てられた多数のTLV値がある。本発明の実施例によると、1以上の新たなTLVが、PBTネットワークのPBTトランク上の中間ノードにおいてOAM機能を実現するため割り当てられるかもしれない。例えば、OAMフレームが1以上の中間ノードを目的としていることを示すため、TLV値が割り当てられてもよい。あるいは、TLV値はまた、同一のフレームフォーマットがPBTトランク全体においてOAMを実行するのに利用可能となるように、エンドポイントにおいてOAM機能を実現するのに利用されてもよい。本実施例のイーサネット(登録商標)フレーム内の1以上のフィールド(OpCodeフィールドなど)が、中間ノードにより実行されるOAM機能のタイプ(ループバック、トレースルート、リンクトレース、AISなど)を指定するのに利用されてもよい。あるいは、複数のTLV値が、中間ノードにより実行される特定タイプの中間OAM機能を示すため割り当てられてもよい。
【0053】
規格団体が、1以上の特定のTLVがPBTネットワークにおいて中間ノードのOAMを実現するのに割り当てられるべきであるか決定するまで、図6A及び7Aに示されるようなベンダー固有の31のTLVが使用されてもよい。TLVフィールド602が31に設定されると、フレームを受信するネットワーク要素は、フレームフォーマットが組織OUIフィールド606により特定される特定のベンダーに固有のものであると判断する。“31”に設定されたベンダー固有のTLVフィールド602を有するOAMフレームを受信すると、ネットワーク要素は、OUIフィールドの値がネットワーク要素の識別子に一致するか判断するため、組織OUIフィールド606を確認する。そうである場合、それは、ネットワーク装置のベンダーにより規定されたフォーマットに従ってフレームを処理する。そうでない場合、それは、TLVフィールドを無視し、標準的なOAMフレームとしてOAMフレームを処理する。
【0054】
ベンダー固有フォーマットの一実施例が、図6〜7に関して説明される。本発明は、この例に限定されず、他のベンダー固有の又はIEEEにより認められたフォーマットがまた利用可能である。図6に示される実施例では、TLVフィールドは、TLVフィールドの長さを示す長さフィールド604と、ベンダーOUIフィールド606と、実行されるOAM機能のタイプを示すサブタイプフィールド608とを含む。OAMフレームはまた、上述した実施例に関して説明されたものと同一の意図されるSA610と、ターゲットDA612と、リバースVLAN IDフィールド614とを含む。OAMフレームはまた、特定の実現形態に応じて、1以上の他のTLV、何れか所望のさらなるフィールド616、及びエンドTLVフィールドを有してもよい。
【0055】
図6B及び7Bに示されるように、規格団体が、1以上のTLV値がOAMに割り当てられるべきであると決定した場合、フィールド602のTLV値は、OUIフィールド606と、任意的にはサブタイプフィールド608とを有する必要性を軽減する規格により割り当てられた値に設定される。他のフォーマットがまた使用可能であり、本発明は図示される特定の例に限定されるものでない。
【0056】
図8は、本発明の実施例を実現するのに利用可能な処理のフローチャートを示す。図8に示されるように、中間ノードがPBTトランクのDA/VIDによりアドレス指定されたOAMフレームを受信したとき(800)、ネットワーク要素がフレームを処理するための2つの方法がある。具体的には、ネットワーク要素は、これが当該ネットワーク要素を目的としたOAMフレームであることをネットワーク要素に示す、フレームの特定位置における特定の値を確認するよう構成されるデータプレーンのハードウェアを有するかもしれない(802)。ネットワーク要素においてフレームを処理するハードウェアは、ネットワークプロセッサ、ASIC、FPGA及び他のプログラム可能なハードウェアを有してもよく、“ファーストパス(fastpath)”とここでは呼ばれるであろう。
【0057】
あるいは、ネットワーク要素は、ソフトウェアにより実現され、CPU904などのプロセッサにおいてインスタンス化されるイーサネット(登録商標)OAM処理920(図9に関して後述される)などの制御処理にOAMフレームを転送するかもしれない(804)。OAMフレームが制御処理に転送されると、当該制御処理はさらに、実現される機能のタイプに関して判断してもよい。
【0058】
OAMフレームは、中間ノードがOAMフレームなどのフレームを認識し、さらにOAMフレームが中間ノードの1以上により使用されるものであることを認識することを可能にするため、上述されたフォーマット又は他のフォーマットの1つを用いてフォーマット化されてもよい。具体的には、OAMフレームは、図2〜3に関して説明されたような特別なEtherType値、図4〜5に関して説明されたような特別な若しくはベンダー固有のOpCode、又は図6〜7に関して上述されたような特別な若しくはベンダー固有のTLVを有してもよい。EtherType、OpCode及びTLVの組み合わせがまた利用可能であり、本発明は、これらの技術の1つしか使用されない実現形態に限定されるものでない。
【0059】
OAMフレームの検出方法に関係なく、必要な場合、中間ノードがOAMフレームに応答する方法は複数ある。例えば、図3Cに関して説明されるように、ネットワーク要素は、外部のヘッダフィールドを取り除き、リプライフレームとして結果として得られるフレームを利用してもよい(806)。これは、ファーストパス又は制御処理により実現されてもよいが、リプライフレームを構成するのに中間ノードにより実行されるべき処理がほとんど必要でないため、ハードウェアによる実現に適している。
【0060】
あるいは、リプライフレームは、例えば、図3Bに関して上述されるように、生成されてもよい(808)。フレームの生成は、ソフトウェア処理により実行されてもよいし、又はファーストパスにOAMフレームの一部を抽出させ、リプライフレームを生成するようそれらを再構成させることによる他の方法により実行されてもよい。
【0061】
リプライフレームが生成されると、中間ノードは、リプライフレームを送信し(810)、それは、リバーストランクのDAとVIDとを用いてアドレス指定される。OAMフレームのタイプに応じて、中間ノードはまた、必要な場合にはトランクのOAMフレームをデスティネーションへのパスの他の中間ノードに転送してもよい。例えば、フレームがループバックフレームであり、それを受信した中間ノードにアドレス指定されていない場合、中間ノードによりリプライは必要でなく、ノードは単にPBTトランクを介しOAMフレームを転送する。OAMフレームが中間ノードにおいてループバックOAM機能を実行するのに使用されるためのものである場合、当該ネットワーク要素しかループバックフレームに応答することを求めず、このため、OAMフレームはPBTトランク上で転送される必要がない。リンクトレースなどの他の機能は、ネットワーク上のすべての又は多数の中間ノードがリプライフレームを生成すること要求するかもしれず、このため、OAMフレームがPBTトランクを介し転送されるべきかの判断は、実行されるOAM機能のタイプに依存するかもしれず、当該中間ノードはOAMフレーム又は他のファクタに応答することが要求される。
【0062】
ネットワーク上でOAMフレームを処理するため、中間ノードは、(1)フレームが中間ノードにアドレス指定されているか、及び(2)何れのタイプのOAM機能が実装されているかを決定する必要がある。これら2つの処理は、ファーストパスがイーサネット(登録商標)フレームの複数のフィールドを読み込むことが可能であるため、ファーストパスが使用される場合には同時に実行されてもよい。あるいは、これら2つの処理は、ファーストパスにさらなる評価のためすべてのOAMフレームを制御処理に転送させることによって、順次実行されてもよい。本発明は、特定の実現形態に限定されず、本発明の実施例を実現する他の方法がまた利用可能である。
【0063】
図9は、本発明の実施例を実現するのに使用可能なネットワーク要素の機能ブロック図を示す。一般に、ここに説明される方法は、イーサネット(登録商標)ネットワーク上でPBT機能を実現するよう構成されるイーサネット(登録商標)スイッチ、ブリッジ、ハブ及び他のネットワーク要素などのネットワーク要素において実現可能である。本発明は、図9に示される実施例又は特定のネットワーク要素に限定されず、ネットワーク要素のアーキテクチャに関係なく何れかのネットワーク要素において実現されてもよい。
【0064】
図9に示される実施例では、ネットワーク要素102は、例えば、上述されたファーストパスを実現するためなど、効率的な方法によりネットワーク上のデータを処理するよう処理されるデータプレーン900を有する。多数の異なるデータプレーンアーキテクチャが数年間にわたって開発されてきており、本発明は、何れか特定のデータプレーンアーキテクチャに限定されるものでない。このため、図9は特定のデータプレーンアーキテクチャを含むネットワーク要素の一例を示すが、本発明は、図示された実施例に限定されず、多数の異なる構成のイーサネット(登録商標)スイッチ、ブリッジ、ノードなどが、本発明の実施例を実現するのに利用可能である。
【0065】
図9に示される一例となるネットワーク要素のデータプレーン900は、複数の入出力カード902を有する。入出力カード902は、一般にネットワーク100上のリンク104を実現する光ファイバ、銅線、アンテナなどとインタフェースをとる物理ポートを含む。入出力カード902はまた、フレームを構成し、他の共通ライン処理機能を実行するよう構成される処理回路を含むかもしれない。
【0066】
データプレーン900はまた、図示された実施例では、1以上のCPU906と1以上のネットワーク処理ユニット(NPU)908とを含む複数のデータサービスカード904を有する。NPU908は、ファーストパス910を実現し、さらにPBTトランクの転送状態を含む転送情報ベース912を実現する。CPU906は、例えば、新たなPBTトランクが生成される際には新たな状態情報をFIBに挿入させ、PBTトランクが破棄される際には古い状態情報をFIBから削除させるのに利用可能な転送状態の変更をFIBにプログラムするよう構成されるFIBエージェント914を有してもよい。CPUはまた、多数の他のプログラムをインスタンス化するかもしれず、本発明は、CPUがネットワーク要素上で使用される方法により限定されるものでない。
【0067】
データプレーン900はまた、本実施例では、データサービスカードの間でフレーム又はデータパケットをスイッチするよう構成されるスイッチファブリック916を有する。データサービスカードは、スイッチファブリックへの送信前後にフレームを処理してもよい。
【0068】
ネットワーク要素12はさらに、データプレーンが動作する方法を規定するよう構成される制御プレーン920を有する。ネットワーク要素の制御プレーンは、通信ネットワークの制御プレーンとやりとりする。具体的には、ネットワーク要素の制御プレーンは、特定のアクションをネットワーク要素において発生させるようデータプレーンを構成し、ネットワークの制御プレーン自体は、ネットワーク要素がトラフィックを処理することを可能にする。
【0069】
図9に示される実施例では、制御プレーン920は、図1〜8に関して上述された各機能を実行するよう制御ロジックを設定することを可能にするデータ及び命令をメモリ926からロードするよう構成される制御ロジック924を含むプロセッサ922を有する。
【0070】
例えば、メモリ926は、他のネットワーク要素とルーティング情報をやりとりするため、リンク状態プロトコル又は他のタイプのルーティングプロトコルを実現するよう構成されるルーティングソフトウェア928を格納するかもしれない。
【0071】
PBTソフトウェア930は、ネットワーク上でPBTトランクが生成されるのを可能にするため、メモリ908に含まれる。PBTソフトウェアは、PBTトランクセットアップメッセージを受信し、最短パス計算に基づきトランクについて状態が設けられるべきか判断するため、ネットワークの制御プレーンとやりとりする。具体的には、ネットワーク要素がPBTトランクセットアップメッセージを受信すると、ネットワーク要素は、PBTトランクの転送状態を組み込むことが必要か判断し、そうである場合、FIBエージェント914に適切な状態をFIB912に組み込ませる。状態の設置が必要か否かの判断は、PBTトランクが生成され、ネットワーク上で通知される方法に依存するかもしれない。
【0072】
メモリ926はまた、CPU上で実行される処理が迅速に何れのタイプの情報がすでにFIB上に組み込まれているか判断できるように、FIB912に含まれる情報の複製932を含むかもしれない。
【0073】
ネットワーク要素はまた、ネットワーク要素がイーサネット(登録商標)プロトコル及び他のプロトコルをネットワーク上で実現することを可能にするよう構成されるプロトコルスタック934を実現してもよい。これは、ここに記載されるOAM機能を実現するよう構成されるイーサネット(登録商標)OAMソフトウェア936に接続される。例えば、イーサネット(登録商標)OAMソフトウェアは、受信したOAMフレームに応答して、リプライフレームがネットワーク要素により生成及び送信されることを可能にするよう構成されてもよい。動作について、データプレーンは、PBTトランク上の中間ノードのOAM機能を実行するのに使用されるためのものであるイーサネット(登録商標)OAMフレームを認識するよう構成される。OAMフレームが特定されると、データプレーン自体がリプライを生成するか、又は制御プレーン920のCPU906又はプロセッサ922の1以上のプロセスにOAMフレームを送信するようにしてもよい。例えば、OAMフレームは、処理のためイーサネット(登録商標)OAMソフトウェア936にわたされてもよい。OAMフレームがイーサネット(登録商標)OAMソフトウェア936にわたされる場合、関連する情報がOAMフレームから抽出され、リバースPBTトランクへの送信のためデータプレーンにわたされるリプライフレームが生成される(必要である場合)。
【0074】
ここに記載される機能は、ネットワーク要素内のコンピュータ可読メモリに格納され、ネットワーク要素内の1以上のプロセッサ上で実行されるプログラム命令セットとして実現されてもよい。しかしながら、ここに記載されるすべてのロジックは個別のコンポーネント、ASIC(Application Specific Integrated Circuit)などの集積回路、FPGA(Field Programmable Gate Array)又はマイクロプロセッサなどのプログラム可能なロジック装置と共に使用されるプログラムマブルロジック、状態マシーン又はこれらの何れかの組み合わせを含む他の何れかの装置を用いて実現可能であることが、当業者には明らかであろう。プログラマブルロジックは、ROM(Read−Only Memory)チップ、コンピュータメモリ、ディスク又は他の記憶媒体などの有形な媒体に一時的又は永久的に固定可能である。プログラマブルロジックはまた、コンピュータバスや通信ネットワークなどのインタフェースを介しプログラマブルロジックが送信されることを可能にする搬送波に実現されるコンピュータデータ信号に固定可能である。このようなすべての実施例は、本発明の範囲内に属するものである。
【0075】
図面に図示され、明細書に記載される各実施例の各種変更及び改良が本発明の趣旨及び範囲内で可能であることが理解されるべきである。従って、上記説明に含まれ、添付した図面に示されるすべての事項は例示的なものであり、限定的に解釈されるものでない。本発明は、以下の請求項とそれに均等なものに規定されるものによってのみ限定される。
【符号の説明】
【0076】
100 ネットワーク
102 ネットワーク要素
104 リンク
106 PBTトランク
108 ネットワーク管理システム
【図1A】

【図1B】

【図1C】


【特許請求の範囲】
【請求項1】
イーサネットネットワークを介し第1の一方向トラフィックエンジニアリング通信パス上の中間ノードにおいてイーサネットOAMを実現する方法であって、
前記イーサネットネットワークを介し前記第1の一方向トラフィックエンジニアリング通信パス上の中間ノードが、前記イーサネットネットワークを介した前記第1の一方向トラフィックエンジニアリング通信パスのエンドポイントアドレスを送信先アドレスとして含むOAMフレームを受信するステップであって、前記OAMフレームはさらに、前記OAMフレームが前記中間ノードにおいてOAM機能を実行するのに利用されることが意図されているという表示であって、Ethertype値とOpCode値との1つに含まれる前記表示を含む、前記受信するステップと、
前記中間ノードが、リプライメッセージを生成するステップと、
前記リプライメッセージの送信先アドレスとして、前記OAMフレーム内に含まれる第1情報を用いて前記リプライメッセージをアドレス指定するステップと、
前記中間ノードが、前記イーサネットネットワークを介し第2の一方向トラフィックエンジニアリング通信パスにより前記リプライメッセージを送信するステップであって、前記イーサネットネットワークを介した前記第2の一方向トラフィックエンジニアリング通信パスは、前記イーサネットネットワークを介した前記第1のトラフィックエンジニアリング通信パスのパスに続くが、逆方向に延びる、前記送信するステップと、
を有する方法。

【図2】
image rotate

【図3A】
image rotate

【図3B】
image rotate

【図3C】
image rotate

【図4A】
image rotate

【図5A】
image rotate

【図4B】
image rotate

【図5B】
image rotate

【図6A】
image rotate

【図7A】
image rotate

【図6B】
image rotate

【図7B】
image rotate

【図8】
image rotate

【図9】
image rotate


【公開番号】特開2013−70381(P2013−70381A)
【公開日】平成25年4月18日(2013.4.18)
【国際特許分類】
【出願番号】特願2012−236529(P2012−236529)
【出願日】平成24年10月26日(2012.10.26)
【分割の表示】特願2009−534716(P2009−534716)の分割
【原出願日】平成19年10月31日(2007.10.31)
【出願人】(390023157)ノーテル・ネットワークス・リミテッド (153)
【Fターム(参考)】