JP2013179628A - リンク状態制御イーサネット・ネットワークにおける疎通性チェック管理 - Google Patents

Abstract

【課題】リンク状態プロトコル制御イーサネット（登録商標）・ネットワークにおけるネットワーク・トポロジーを検証する。
【解決手段】ソース・ノードからターゲット・ノードにＯＡＭリンク・トレース・メッセージが送られる。このメッセージは、宛先アドレスとして、ターゲット・ノードのユニキャスト・イーサネットＭＡＣノードＩＤ、或いはサービス・インスタンスマルチキャスト宛先アドレスを用いることを除いて、８０２．１ａｇフォーマットを用いる。ノードのリンク状態プロトコル・データベースをチェックしてネットワークの少なくとも一部の制御プレーン・トポロジー・ビューを確かめる。ノードからのイーサネットＯＡＭコマンドを実行してネットワークの同一部分のデータ・プレーン・ビューを確かめる。ネットワークの制御プレーン・トポロジー・ビューがデータ・プレーン・トポロジー・ビューと比較されてそれらが一致するかを見る。
【選択図】図８

Description

本発明はリンク状態プロトコル制御イーサネット・ネットワークに係り、そして、更に
詳しくは、リンク状態プロトコル制御イーサネット・ネットワークにおける運用、管理、
及び保守（ＯＡＭ）に関する。

＜関連出願への相互参照＞
本出願は、２００７年１０月１２日に出願されたＰＬＳＢ及びショートカットＯＡＭと
題する米国仮特許出願番号６０／９７９，４３８号の優先権を主張し、その内容はここに
参照される。

本出願は、ノーテル・ネットワークス社による、２００８年１０月１２日に出願された
ＩＰネットワーク及びイーサネットＯＡＭを用いる稼働状況監視と題する同時継続米国特
許出願番号１２／２４９，９４１、２００８年１０月１２日に出願されたリンク状態制御
イーサネット・ネットワークにおける自動ＭＥＰプロビジョニングと題する同時継続米国
特許出願番号１２／２４９，９４４、及び同じくノーテル・ネットワークス社による、２
００８年１０月１２日に出願されたリンク状態制御イーサネット・ネットワークにおける
疎通性チェック管理と題する同時継続米国特許出願番号１２／２４９，９４６、同じくノ
ーテル・ネットワークス社による２００８年５月５日出願のリンク状態プロトコル制御イ
ーサネット・ネットワークに亘るＩＰ転送と題する同時継続米国特許出願番号１２／１５
１，６８４に関連する。

データ通信ネットワークは互いに接続されてデータを互いに渡すように構成される種々
のコンピュータ、サーバー、ノード、ルーター、スイッチ、ブリッジ、ハブ、プロキシー
、及びその他のネットワーク・デバイスを含み得る。これらのデバイスをここでは「ネッ
トワーク・エレメント」と称する。データは、ネットワーク・エレメント間の１つ或いは
複数の通信リンクを利用してネットワーク・エレメント間を、インターネット・プロトコ
ル・パケット、イーサネット・フレーム、データ・セル、セグメント、或いはその他のデ
ータのビット或いはバイトの組合せのようなプロトコルを渡すことにより、交信される。
特定のプロトコル・データ・ユニットが多様なネットワーク・エレメントで処理され、特
定のプロトコル・データ・ユニットがネットワークを亘ってそのソースからその宛先まで
の間を進むに伴い多様な通信リンクを横切る。

通信ネットワーク上の種々のネットワーク・エレメントはここでプロトコルと呼ばれる
予め定義されたルールのセットを用いて互いに通信する。異なるプロトコルは通信の異な
る態様を制御し、例えば、データ通信ネットワーク・エレメント間の転送のためにどのよ
うに信号が形成されるべきか、何というプロトコル・データ・ユニットの種々の態様はど
のように見えるべきか、プロトコル・データ・ユニットはネットワーク・エレメントによ
りどのように処理され或いはネットワークを通じてどのような経路で伝送されるべきか、
及びルーティング情報のような情報がネットワーク・エレメント間でどのように交換され
るべきかを制御する。

イーサネットはイーサット・ネットワーク・アーキテクチャーにおける標準規格８０２
．１として電子電気技術学会（ＩＥＥＥ）により定義されたよく知られたプロトコルであ
り、ネットワークに接続されたデバイスは或る時間において同じ共通通信経路を利用する
能力について競合する。複数のブリッジ或いはノードがネットワーク・セグメントを相互
接続するために用いられる場合、同一宛先への複数の経路がしばしば存在し得る。このア
ーキテクチャーの利点はブリッジ間の経路の冗長性を有し追加のリンクの形態でネットワ
ークに付加される許容能力を有することである。しかしながらループが形成されるのを避
けるためネットワーク上でトラフィックがブロードキャストされ或いはフラッディングさ
れる状態を抑制するためにスパニング・ツリーが一般的に用いられた。スパニング・ツリ
ーの特徴はネットワーク内の宛先のどんなペア間にも唯一つの経路しか存在しないことで
あり、従ってパケットが何処から到来するかを観察することにより特定のスパニング・ツ
リーに関連する接続性を「学習」することが可能であった。しかしながらスパニング・ツ
リー自体に制約があり、スパニング・ツリー上のリンクに過使用をもたらし、スパニング
・ツリーの一部でないリンクに未使用をもたらした。

スパニング・ツリーを実装するイーサネット・ネットワークに内在する制約の幾つかを
解決するためリンク状態プロトコル制御イーサネット・ネットワークが２００６年１０月
２日出願の出願番号１１／５３７，７７５の「プロバイダー・リンク状態ブリッジ」と題
する出願に開示され、その内容はここに参照される。前記出願でより詳しく記述されるよ
うに、リンク状態プロトコル制御イーサネット・ネットワークでの透過ブリッジと組合わ
された各ノードにおける学習したネットワーク・ビューを利用するよりも、ネットワーク
・トポロジーの同期したビューを各ノードが持つことを可能にするメッシュ・ネットワー
ク交換リンク状態広告を形成するブリッジを利用する。これはリンク状態ルーティング・
システムのよく知られている仕組みにより達成される。ネットワーク内のブリッジはネッ
トワーク・トポロジーの同期されたビューを有し、必要なユニキャスト及びマルチキャス
トの接続性の知識を保有し、ネットワーク内のどのようなペアのブリッジ間の最短経路の
接続性を計算出来、そして計算されたネットワークのビューに従ったそれらの転送情報ベ
ース（ＦＩＢ）を個々に留めることが出来る。

全てのノードが同期されたビューにおけるそれらの計算された役割及び留まっているそ
れらのＦＩＢを計算した時は、ネットワークはピアー・ブリッジのセットから(如何なる
理由であれそのブリッジへの通信を要求する)如何なるブリッジへのループ・フリー・ユ
ニキャスト・ツリーを有することとなり、ブリッジにおいて提供されるサービス段階毎に
如何なるブリッジからピアー・ブリッジの同一セット或いはサブセットからの調和し且つ
ループ・フリーのポイント・ツー・マルチポイント（ｐ２ｍｐ）のマルチキャスト・ツリ
ーを有することとなる。もたらされる結果は、あるブリッジ間の経路がスパニング・ツリ
ーのルート・ブリッジの通過に制約されないことであり、そして、全体としてもたらされ
る結果はメッシュの接続性の幅をより良く利用出来ることである。要するに全てのブリッ
ジがそのブリッジへのユニキャストの接続性、及びそのブリッジからのマルチキャストの
接続性を特定する１つ或いは複数のツリーのルートとなる。

カスタマー・トラフィックがプロバイダー・ネットワークに入るとき、カスタマーＭＡ
Ｃアドレス（Ｃ−ＭＡＣ ＤＡ）はプロバイダーＭＡＣアドレス（Ｂ−ＭＡＣ ＤＡ）へ
と解決され、そうしてプロバイダーＭＡＣアドレス空間を用いてトラフィックをプロバイ
ダー・ネットワーク上に転送できる。更に、プロバイダー・ネットワーク上のネットワー
ク・エレメントはバーチャルＬＡＮ ＩＤ（ＶＩＤ）に基づいてトラフィックを転送する
よう構成されており同じ宛先アドレスであるが異なるＶＩＤを有する異なるフレームはネ
ットワークの異なる経路を亘って転送され得る。運用中、リンク状態プロトコル制御イー
サネット・ネットワークは１つのＶＩＤ範囲を最短経路転送に関連付ける事が出来、ユニ
キャスト及びマルチキャスト・トラフィックがその範囲からＶＩＤを用いて転送される事
が出来、そしてトラフィック形成経路が最短経路以外の経路上のネットワークを横切って
形成される事が出来、そして第２のＶＩＤ範囲を用いて転送される。

真のキャリア・クラス機能をリンク状態プロトコル制御イーサネットに加えるためには
、特定の運用、管理、及び維持（ＯＡＭ）機能が望ましい。ＩＥＥＥ標準８０２．１ａｇ
「到達性管理」として現在定義されている、イーサネットＯＡＭは、イーサネット・ネッ
トワーク内で用いられるための到達性管理プロトコルのセットを定義する。これらは到達
性監視、リンク追跡、及びループバックを含む。８０２．１ａｇ規格はメトリックス及び
メッセージの監視の遂行を含むように拡張された。この標準はＩＴＵ−Ｔ ＳＧ １３，
Ｙ．１７３１−「イーサネット・ネットワークにおけるＯＡＭに関する要件」に反映さ
れている。しかし、これらの標準に記述された仕組みはアドレッシング及びＶＬＡＮセマ
ンティクスの相違及び標準ネットワーク及びリンク状態プロトコル・イーサネット・ネッ
トワーク間の使用の相違によりリンク状態プロトコル・イーサネット・ネットワークに直
接的には適用出来ない。フォールト検出、隔離、トラブルシューティング、及び稼働状況
監視目的に関するＯＡＭ機能をリンク状態プロトコル・イーサネット・ネットワーク中に
取り入れることが望まれている。

本発明によればリンク状態プロトコル制御イーサネット・ネットワークにおいてＯＡＭ
メッセージを送る方法が提供される。本方法はリンク状態プロトコル制御イーサネット・
ネットワークにおいてソース・ノードからターゲット・ノードへＯＡＭリンク・トレース
・メッセージを送るステップを含み、このリンク・トレース・メッセージは、宛先アドレ
スとして、ターゲット・ノードのユニキャスト・イーサネットＭＡＣノードＩＤを用いる
ことは除いて８０２．１ａｇフォーマットを用いる。

本発明のもう１つの態様によればリンク状態プロトコル・イーサネット・ネットワークに
おけるＯＡＭメッセージを送るもう１つの方法はサービス・インスタンスを追跡するため
にリンク状態プロトコル・イーサネット・ネットワークのソース・ノードからＯＡＭリン
ク・トレース・メッセージを送るステップを含み、このリンク・トレース・メッセージは
、宛先アドレスとして、サービス・イスタンスのマルチキャスト宛先アドレスを用いるこ
とを除いて８０２．１ａｇを用いる。

本発明の第３の態様によれば、リンク状態プロトコル・イーサネット・ネットワークに
おけるネットワーク・トポロジー検証の方法は、少なくとも部分的なネットワークの制御
プレーンのトポロジーのビューを確かめるためにノードにおけるリンク状態プロトコル・
データベースをチェックするステップ、ネットワークの同一部分のデータ・プレーン・ト
ポロジーのビューを確かめるためにノードからの１つ或いは複数のイーサネットＯＡＭコ
マンドを実行するステップ、ネットワークの制御プレーン・トポロジーのビューをネット
ワークのデータ・プレーン・トポロジーのビューに比較してそれらが一致するかを見るス
テップ、及びそれらが一致しない時にはエラーをフラッディングするステップを含む。

リンク状態プロトコル・データベースをチェックするステップはリンク状態プロトコル
制御イーサネット・ネットワークでの第１ノードからネットワークを通じる全ての経路を
追跡するステップを含む事が出来、そして１つ或いは複数のイーサネットＯＡＭコマンド
を実行するステップはサービス・インスタンスを追跡するために第１ノードからの１つ或
いは複数のリンク・トレース・イーサネットＯＡＭリンク・トレース・コマンドを実行す
るステップを含むことが出来、リンク・トレース・コマンドは、宛先アドレスとして、サ
ービス・インスタンスのマルチキャスト宛先アドレスを用いることを除いて８０２．１ａ
ｇフォーマットを用いる。

或いは、リンク状態プロトコル・データベースを確認するステップはリンク状態プロト
コル制御イーサネット・ネットワークでの第１ノードから第２ノードへのネットワークを
通じる経路を追跡するステップを含む事が出来、そして１つ或いは複数のイーサネットＯ
ＡＭコマンドを実行するステップはサービス経路を追跡するために第１ノードからの１つ
或いは複数のリンク・トレース・イーサネットＯＡＭリンク・トレース・コマンドを実行
するステップを含む事が出来、リンク・トレース・コマンドは、宛先アドレスとして、イ
ーサネットＭＡＣノードＩＤのユニキャスト宛先アドレスを用いる点を除いて８０２．１
ａｇフォーマットを用いる。

本発明のもう１つの態様によれば、データをストアするためのコンピュータ・プログラ
ムが提供され、このコンピュータ・プログラムはリンク状態プロトコル・イーサネット・
ネットワークにおけるＯＡＭメッセージを送るためのロジックを備える。このロジックは
、リンク状態プロトコル・イーサネット・ネットワークにおけるソース・ノードからター
ゲット・ノードへＯＡＭリンク・トレース・メッセージを送るためのロジックを含み、こ
のリンク・トレース・メッセージは、宛先アドレスとして、ターゲット・ノードのユニキ
ャスト・イーサネットＭＡＣノートＩＤを用いる点を除いて、８０２．１ａｇフォーマッ
トを用いる。

本発明の更なる態様によれば、データをストアするためのコンピュータ・プログラムが
提供され、このコンピュータ・プログラムはサービス・インスタンスを追跡するためにリ
ンク状態プロトコル制御イーサネット・ネットワークでのソース・ノードからのＯＡＭリ
ンク・トレース・メッセージを送るためのロジックを備え、リンク・トレース・メッセー
ジは、宛先アドレスとして、サービス・インスタンスのマルチキャスト宛先アドレスを用
いる点を除いて８０２．１ａｇフォーマットを用いる。

本発明の更なる態様達によれば、データをストアするためのコンピュータ・プログラム
が提供される。このコンピュータ・プログラムはリンク状態プロトコル制御イーサネット
・ネットワークにおけるネットワーク・トポロジー検証を遂行する。このコンピュータ・
プログラムは、少なくとも部分的なネットワークの制御プレーン・トポロジーのビューを
確かなものにするためにノードにおけるリンク状態プロトコル・データベースをチェック
するためのロジック、ネットワークの同一部分のデータ・プレーン・トポロジーのビュー
を確かなものにするためにノードからの１つ或いは複数のイーサネットＯＡＭコマンドを
実行するためのロジック、ネットワークの制御プレーン・トポロジーのビューをネットワ
ークのデータ・プレーン・トポロジーのビューと比較してそれらが一致するかを見るため
のロジック、及びそれらが一致しない時にエラーを報せるためのロジックを含む。

一実施例によれば、リンク状態プロトコル・データベースをチェックするロジックはリ
ンク状態プロトコル制御イーサネット・ネットワークでの第１ノードからネットワークを
通じる全ての経路を追跡するためのロジックを含み、そして１つ或いは複数のイーサネッ
トＯＡＭコマンドを実行するためのロジックはサービス・インスタンスを追跡するために
第１ノードからの１つ或いは複数のリンク・トレース・イーサネットＯＡＭリンク・トレ
ース・コマンドを実行するロジックを含み、リンク・トレース・コマンドは、宛先アドレ
スとして、サービス・インスタンスのマルチキャスト宛先アドレスを用いることを除いて
８０２．１ａｇフォーマットを用いる。

別の実施例によれば、リンク状態プロトコル・データベースをチェックするためのロジ
ックはリンク状態プロトコル制御イーサネット・ネットワークでの第１ノードから第２ノ
ードへのネットワークを通じる経路を追跡するためのロジックを含み、そして１つ或いは
複数のイーサネットＯＡＭコマンドを実行するためのロジックはサービス経路を追跡する
ために第１ノードからの１つ或いは複数のリンク・トレース・イーサネットＯＡＭリンク
・トレース・コマンドを実行するためのロジックを含み、リンク・トレース・コマンドは
、宛先アドレスとして、イーサネットＭＡＣノードＩＤのユニキャスト宛先アドレスを用
いることを除いて８０２．１ａｇフォーマットを用いる。

本発明の特徴は特に付属の請求項により表される。本発明は例示として以下の図面に示
され、同様の参照符号は同様の要素を示す。以下の図面は本発明の種々の実施例を図示す
るだけのために示し、本発明の範囲を制限するためではない。分かり易くするために、全
ての図面の全ての部分に符号が付されてはいない。
図１はリンク状態プロトコル制御イーサネット・ネットワークを実装するために用いられていたメッシュ・ネットワークの機能的ブロック図である。 図２はリンク状態プロトコル制御イーサネット・ネットワークにおいて用いられるように構成されたネットワーク・エレメント１２の一実装例の模式図である。 図３はＩＳ−ＩＳのようなリンク状態プロトコルがディスカバリー・フェーズを実行して各ブリッジのＳｙｓ−ＩＤを用いてループ・フリー構成にブリッジを相互接続するようなリンク状態プロトコル制御イーサネット・ネットワーク構成の模式図である。 図４は複数のサービスがディスカバリー・フェーズ・ツリーから離れたリーフとして配置されて示されるところの図３に似たリンク状態プロトコル制御イーサネット・ネットワーク構成の模式図である。 図５は８０２．１ａｇ規格により定義されたイーサネットＯＡＭ保守ドメインのブロック図である。 図６は８０２．１ａｇＯＡＭパケットのブロック図である。 図７は本発明によるリンク状態プロトコル制御イーサネット・ネットワークのノードにおける基盤レベルＯＡＭパケットの処理の流れ図である。 図８は本発明によるリンク状態プロトコル制御イーサネット・ネットワークのノードにおいて遂行される基盤レベル到達性チェック・プロセスの流れ図である。 図９は本発明によるリンク状態プロトコル制御イーサネット・ネットワークのノードにおけるサービス・レベルＯＡＭパケットの処理の流れ図である。 図１０は本発明によるリンク状態プロトコル制御イーサネット・ネットワークのノードにおいて遂行されるサービス・レベル到達性チェック・プロセスの流れ図である。 図１１は本発明の一実施例によるリンク状態プロトコル制御イーサネット・ネットワークのノードによるＭＥＰ生成及び分配の流れ図である。 図１２は本発明の一実施例によるリンク状態プロトコル・イーサネット・ネットワークのノードにおけるＭＥＰ受信及び転送テーブル更新の流れ図である。 図１３は本発明の一実施例によるノードＡからノードＢへのＯＡＭコマンドを送るためＭＥＰルックアップを用いるプロセスのＭＥＰの流れ図である。 図１４はリンク状態プロトコル制御イーサネット・ネットワーク上の２つのＩＰノード間で実行されるＩＰ「Ｐｉｎｇ」コマンドの模式図である。 図１５は本発明によるリンク状態プロトコル制御イーサネット・ネットワークのノードにおけるＩＰレベル「Ｐｉｎｇ」コマンドの処理の流れ図である。 図１６はリンク状態プロトコル制御イーサネット・ネットワーク上の２つのＩＰノード間で実行されるＩＰ「Ｐｉｎｇ」コマンドの模式図である。 図１７はプロバイダーがＩＰフォンを有するカスタマー施設に接続され、全ての通信がリンク状態プロトコル制御イーサネット・ネットワークを通じて行われるようなネットワークのブロック図である。ＶＯＩＰネットワークの稼働状況の監視は本発明によるイーサネットＯＡＭコマンドを用いてＩＰにおいて行われる。 図１８は本発明の一実施例によるリンク状態プロトコル制御イーサネット・ネットワークのノードにおけるＩＰレベル稼働状況監視コマンドの処理の流れ図である。

リンク状態プロトコル制御イーサネット・ネットワークはイーサネットのブリッジされ
た接続性の等価物を提供するが、これをフラッディング及び学習ではなくネットワーク・
エレメント転送情報ベース（ＦＩＢ）の構成を通じて達成する。リンク状態プロトコル制
御イーサネット・ネットワークの利用はループ・フリー最短経路転送を用いたネットワー
ク能力のより効率的な利用を提供することによりイーサネット・ネットワークがＬＡＮ空
間からＷＡＮ或いはプロバイダー空間へと拡張される事を可能にする。透過ブリッジと組
合わされるスパニング・ツリー・プロトコル（ＳＴＰ）アルゴリズムを用いる各ノードに
おける学習されたネットワーク・ビューを用いるのではなく、リンク状態プロトコル制御
イーサネット・ネットワークにおいてメッシュ・ネットワークを形成するブリッジがリン
ク状態広告を交換して各ノードがネットワーク・トポロジーの同期したビューを持つ事が
出来るようにする。これはリンク状態ルーティング・システムの利用を通じて達成される
。

ネットワークのブリッジはネットワーク・トポロジーの同期されたビューを有し、必要
なユニキャスト及びマルチキャスト接続性の知識を有し、ネットワークのブリッジの如何
なるペア間の最短経路の接続性を計算出来、そして個々にネットワークの計算されたビュ
ーにより転送情報ベース（ＦＩＢ）を保持出来る。全てのノードが同期されたビューにお
ける役割を計算しＦＩＢを保持する時、ピアー・ブリッジのセットから如何なるブリッジ
へのループ・フリー・ユニキャスト・ツリーを有し、そしてピアー・ブリッジの同一のセ
ットへの如何なるブリッジからの調和したループ・フリー・ポイント・ツー・マルチポイ
ント（ｐ２ｍｐ）マルチキャスト・ツリーを有する。その結果は如何なるブリッジ・ペア
間の経路もスパニンク・ツリーのルート・ブリッジの通過に拘束されない事でありそして
全体としての結果はメッシュの接続性の幅をより良く活用する事が出来る事である。

リンク状態プロトコル制御イーサネット・ネットワークは如何なる２つのブリッジ間の
接続性が両方向について同一経路になるように同期経路メトリックスを用い、そしてマル
チキャストされるパケットとユニキャストされるパケットとの間の転送の一致があるよう
にユニキャスト及びマルチキャストの接続性についての共通メトリクスを用いる。

ＭＡＣ構成が透過ＬＡＮサービスを利用出来るＣ−ＭＡＣ（カスタマーＭＡＣ）レイヤ
ー或いは他のレイヤーのネットワークに透過ＬＡＮサービスを提供するためにブリッジ（
僅かに変更されたブリッジ）のセット間に最短経路のループ・フリー接続（ユニキャスト
目的及びマルチキャスト目的の両方について）を構築するために用いられてもよい。

これは関連するＶＬＡＮについてのスパニング・ツリー・プロトコルのネットワーク内
のリンク状態プロトコルの運用及びルーティング・システム広告のＭＡＣ情報のピギーバ
ッキングを必要とする。

図１はリンク状態プロトコル制御イーサネット・ネットワークの一部分の一例の模式表
現である。共用ネットワーク・トポロジーから各ノードは最短経路アルゴリズムを用いて
他のプロバイダー・バックボーン・ブリッジ（ＰＢＢ）或いはネットワーク内のノードへ
の最適最短経路を計算する。ネットワークに亘る最短経路アルゴリズムの適用の結果、そ
して対応するブリッジ内のＦＩＢの保持は、各ブリッジからネットワークの同胞ブリッジ
へのメッシュを通じての唯一のツリーを提供する。

（ユニキャスト及びマルチキャストの）ブリッジに関連するＭＡＣアドレスはリンク状態
プロトコル制御イーサネット・ネットワークの全域に亘り転送に基づく宛先のために用い
られる。これはそれらがルーティング・システム広告で単にフラッディングされるだけで
よくそして、ルーティング・システムのローカル集中の際には、ルーティング・システム
により指示されるようにローカル・ブリッジ転送データベースにすぐに準備される。こう
してレイヤー２の接続性の分散された計算はトポリジーの接続性に関連する特有の信号シ
ステムを要することなくイーサネット・ブリッジに適用出来る。この最も簡単なフォーム
では、ブリッジが２つの与えられたブリッジ・ノード間の最短経路上にブリッジがあると
計算した時、ブリッジはＦＩＢ内のこれらブリッジに関連するＭＡＣアドレス、対象の各
ブリッジを示すユニキャストＭＡＣアドレス及び対象のブリッジから示されるマルチキャ
ストＭＡＣアドレスを単にインストールする。

ブリッジ毎の単一のユニキャストＭＡＣアドレスが説明されたがより細かい微小体の利
用を排除するものではなく、そしてユニキャストＭＡＣアドレスはライン・カード、仮想
スイッチ・インスタンス（ＶＳＩ）或いはＵＮＩポートであってもよいことを理解された
い。これは宛先ブリッジでのフローの非多重化を簡略化するために望ましい。

不安定期間（トポロジー変化、トポロジー変化のルーティング・システムからネットワ
ーク内の全てのブリッジへの広告、及び新しいトポロジーの共通ビュー及び転送情報の対
応アップデートの再輻輳の間の期間）ループ抑制は（例え潜在的に低減される形態であっ
ても）接続性を維持するためにネットワークにおいて望ましい。分散システムにおける不
安定はしばしば、少なくとも一時的には、ネットワーク全体のビューが同期されないこと
を意味する。ネットワーク・エレメントがネットワークの同期されたビューを持たない場
合、一時的なループが形成可能である。親出願でより詳細に述べられているようにＰＬＳ
Ｂネットワークはループを最小化するように逆経路転送確認を用いてもよい。ＲＰＦＣ確
認はイーサネット・ブリッジのようなネットワーク・エレメントをしてパケットに含まれ
るソースＭＡＣアドレス及びパケットが到着するセグメントを転送データベース中に宛先
としての同一のＭＡＣアドレスとして構成される値と比較することによりパケットを確認
することにより遂行されてもよい。ソースＭＡＣアドレスについて学習されたセグメント
が静的エントリーを変更し、或いは静的エントリーがない場合、パケットは破棄される。
ＲＰＦＣ確認は望まれる特定のインスタンスでは選択的に無効化されてもよい。

リンク状態プロトコル制御イーサネット・ネットワークはサービス・インスタンスをサ
ポート出来、サービス・インスタンスはポートのサブセット従ってネットワークのブリッ
ジへの接続性を要するだけである。特定のサービス・インスタンスに関連するパケットを
識別するために用いられ得る識別子の一例はＩＥＥＥ８０２．１ａｈ中に定義される拡張
サービスＩＤフィールド（Ｉ−ＳＩＤ）である。自らが２つのブリッジ間の最短経路上に
あることを見つけたブリッジは各ブリッジに関連するユニキャストＭＡＣアドレス、及び
２つのブリッジに共通の全てのＩ−ＳＩＤについてのマルチキャストＭＡＣアドレスをイ
ンストールする。この結果は与えられたエッジ・ブリッジは全てのピアー・ブリッジへの
ユニキャスト接続性、及び各Ｉ−ＳＩＤにより識別される対象のコミュニティ特有のマル
チキャスト接続性を有することとなる。これは各ピアーへのマルチポイント・ツー・ポイ
ント（ｍｐ２ｐ）ユニキャスト・ツリー上のリーフ、及び対象の各コミュニティについて
のピアー・ノードのセットへの（Ｓ，Ｇ）ポイント・ツー・マルチポイント（ｐ２ｍｐ）
マルチキャスト・ツリーのルートの形態となり、ここで、ＳはソースのアドレスでありＧ
はマルチキャスト・グループ・アドレスである。

更に、２００８年５月５日に出願され、リンク状態プロトコル制御イーサネット・ネッ
トワークを横切るＩＰ転送と題する、同時継続米国特許出願番号１２／１５１，６８４に
て述べられ、その全体がここに参照されるように、リンク状態プロトコル制御イーサネッ
ト・ネットワークはネイティブＩＰをサポート出来る。従って、ノードがＩＰアドレスを
学習する時、それはＩＰアドレスをそのリンク状態広告に挿入してＩＰアドレスの到達性
をインターネット上の他のノードに広告する。各ノードはこのＩＰアドレスをリンク状態
データベースに加える。パケットが入口ノードに到着すれば、入口ノードはＩＰアドレス
を読み、リンク状態プロトコル制御イーサネット・ネットワーク上のどのノードがＩＰア
ドレスを認識しているかを判断し、そしてパケットを正しいノードに転送するためのＭＡ
Ｃヘッダーを構成する。ＭＡＣヘッダーのＤＡ／ＶＩＤはＩＰアドレスを広告したノード
の交点ＭＡＣである。ユニキャスト及びマルチキャストＩＰ転送が実装されてもよい。

図２はリンク状態プロトコル制御イーサネット・ネットワークにおいて用いられるよう
に構成されたネットワーク・エレメント１２の可能な実装例の模式的表現である。ネット
ワーク・エレメント１２はルーティング・システム・モジュール８０を含み、ルーティン
グ・システム・モジュール８０はリンク状態ルーティング・プロトコルを用いてネットワ
ーク・トポロジーに関するルーティング及びその他の情報を含む制御メッセージをピアー
１２と交換するよう構成されている。ルーティング・システム・モジュールにより受信さ
れた情報はリンク状態データベース９０にストアされ或いは他の方法でストアされ得る。

前述のように、情報交換はネットワーク上のノードにネットワーク・トポロジーの同期
したビューを生成させ、そして次にはルーティング・システム・モジュール８０にネット
ワーク上の他のノードへの最短の経路を計算させる。ルーティング・システム・モジュー
ル８０により計算された最短経路はＦＩＢ８２内にプログラムされ、計算された最短経路
、マルチキャスト・ツリー、トラフィック処理された経路、及び他のエントリーに基づい
てネットワークを通じてトラフィックを方向づけるためのエントリーと伴に保持される。

ルーティング・システム・モジュール８０はネットワーク・レイヤー到達性の情報を含
むルート・アップデートを交換する。ネットワーク上のノードにより知られたネットワー
ク・レイヤー・アドレスはネットワーク・エレメント１２上のリンク状態データベース９
０にストアされてネットワーク・レイヤー・パケットが到着したときに入口ノードをして
リンク状態プロトコル制御イーサネット・ネットワーク上の正しい出口ノードを選択する
。ネットワーク・レイヤー・アドレスの知識はまたマルチキャスト転送状態がネットワー
クで実行されることとしノードに同一ＩＰマルチキャスト内の関心あるノードのペア間の
転送状態をインストールさせることによりネットワーク・レイヤー・マルチキャストがノ
ードにより処理されるようにする。

ネットワーク・エレメント１２はまた逆経路転送確認（ＲＰＦＣ）モジュール８４のよ
うな１つまたは複数のその他のモジュールを含んでよく、ＲＰＦＣモジュール８４は到来
フレームを処理してＦＩＢ８２中のルックアップを遂行してフレームを受取ったポートと
特定のソースＭＡＣについてＦＩＢ８２内に特定されたポートとが一致するかどうかを判
断する。入力ポートがＦＩＢ内に特定された正しいポートと一致しない場合、ＲＰＦＣモ
ジュールはメッセージを破棄するようにする。

フレームがＲＰＦＣ８４を通過するとき、宛先ルークアップ８６モジュールはＦＩＢ８
２からフレームが転送されるべきポートを決定する。ＦＩＢがＤＡ／ＶＩＤについてのエ
ントリーを持たないとき、フレームは破棄される。

記述されたモジュールは図示の目的のみのためのものであり当業者により理解されるよ
うにノードのモジュール間で組合わされ或いは分散されてよいことを理解されるべきであ
る。

図３を参照すると、リンク状態プロトコル制御イーサネット・ネットワーク３００が示
され、ＩＳ−ＩＳのようなリンク状態制御プロトコルがディスカバリー・フェーズで実行
されて各ブリッジのＳｙｓ−ＩＤ、別名ノードＭＡＣアドレス３０４を用いてループ・フ
リー構成となるようにブリッジ３０２ａ−ｈを相互接続する。ＩＳ−ＩＳのアップデート
の異なるセットは送出されてＩＳＩＤ１０についてのマルチキャスト接続を形成する。Ｉ
ＳＩＤが一旦作成されるとリンク状態ディスカバリーの間にＳｙｓ−ＩＤを用いて作成さ
れた経路を通じてマルチキャスト接続を形成する。図４を更に参照すると全てのサービス
はこのベース・トポロジーのリーフである。２００８年５月５日出願のリンク状態プロト
コル制御イーサネット・ネットワークに亘るＩＰ転送と題する、同時継続米国特許出願番
号１２／１５１，６８４に述べられ参照されるようにＩＰサブネット３０６はＳｙｓ−Ｉ
Ｄに直接的にマップする。２００８年６月２６日出願のリンク状態プロトコル制御イーサ
ネット・ネットワークに亘るＶＰＮの実装と題する、同時継続米国特許出願番号１２／２
１５，３５０に述べられ参照されるようにＶＲＦ３０８はＩＳＩＤを通じてマップする。

ここで参照されるＩＥＥＥ８０２．１ａｇ「到達性管理」に現在定義されているイーサ
ネットＯＡＭはイーサネット・ネットワークで用いられる到達性管理プロトコルのセット
を定義している。これらは、疎通性確認、リンク追跡、及びループバック・プロトコルを
含む。８０２．１ａｇ規格はメトリクス及びメッセージの監視の遂行を含むように拡張さ
れた。この標準はＩＴＵ−ＴＳＧ１３，Ｙ．１７３１−「イーサネット・ネットワークに
おけるＡＯＭ要件」に反映され、ここに参照される。しかし、これらの標準に記載の仕組
みはリンク状態プロトコル制御イーサネット・ネットワークには直接的には適用できない
。本発明によれば、リンク状態プロトコル制御イーサネット・ネットワークは失敗識別、
隔離、トラブルシューティング、目的監視の実行についてのＯＡＭ機能を取り入れる事。

８０２．１ａｇＣＦＭメッセージは以下のものを含む。

疎通性チェック − これらは管理エンドポイントから周期的に発信される「心拍」メ
ッセージである。これらは管理エンドポインドをしてそれらの間のサービス無接続性のロ
スを検知させる。

リンク・トレース − これらはアドミニストレーターの要求に応じて管理エンドポイ
ントにより発信され宛先管理エンドポイントへのパス（ポップ・バイ・ポップ）を追跡す
る。これらは発信ノードをしてパスについての接続性データを発見させる。リンク・トレ
ースはＵＤＰとトレースルートの概念に類似する。

ループバック − アドミニストレーターの要求に応じて管理エンドポイントにより発
信され他の管理ポイントへの接続性を検証する。ルーフバックは宛先が到達可能であるか
否かを示し、パスのポップ・バイ・ポップの発見はさせない。これはＩＣＭＰエコー（Ｐ
ｉｎｇ）と概念において似ている。

管理ドメイン
どのようなサービス・プロバイダー・ネットワーク内であっても、図５に示されるよう
に、イーサネットＣＦＭは階層化管理ドメインから成る機能的モデルに依存する。ドメイ
ンはアドミニストレーターにより（８つの可能性の中から）特有の管理レベルが割当てら
れ、ドメインの階層の関連性を定義するのに有用である。２つのドメインがネストすると
き、外側ドメインは内側ドメインよりもより高い管理レベルを有さなければならない。図
５に示されるのはプロバイダー・ドメイン４０４を含むカスタマー・ドメイン４０２であ
り、プロバイダー・ドメイン４０４は２つのオペレータ・ドメイン４０６を含む。管理エ
ンドポイント（四角印）は管理ドメインの端に位置し、管理中継ポイント（丸印）はドメ
インの内部に位置する。従って、中継ポイントはＣＦＭパケットを転送するが（ループバ
ックでなく或いはその中継ポイントについての宛先リンク・トレースでないとき）、エン
ドポイントはＣＦＭパケットをドメイン内に保持しなければならないのでエンドポイント
はＣＦＭパケットを転送しない。これに対する唯一の例外はエンドポイントがより高いレ
ベルのドメインについての中間ポイントとして動作する時であり、この場合はより高いレ
ベルのドメインの部分である限りＣＦＭパケットを転送する。

図５はサービス・プロバイダーが２つのオペレータのネットワークを用いてサービスを
提供する場合の例を示す。サービス・プロバイダー管理レベルは３２２として示される。
オペレータＡ及びオペレータＢについての管理レベルは３２４に示される。２つの特別な
場合の管理レベルはカスタマー・レベル（３２０）と物理層レベル（３２６）である。カ
スタマー・レベルは（疎通性チェックを用いて）カスタマーをして接続性テストさせそし
て（ループバック及びリンク・トレースを用いて）問題を隔離させる。物理層レベルは、
他方、可能な最も狭い管理ドメイン、シングル・リンク・ドメインを定義する。

本発明の第１の態様によれば、一般的なスパニング・ツリーに基づくイーサネットとリン
ク状態プロトコル制御イーサネットとの間の相違を調整するためにイーサネットＯＡＭ標
準規格に対する変更がもたらされる。本発明の第２の態様によれば、新規なサービス・レ
ベルＯＡＭ機能がリンク状態プロトコル制御イーサネットを上手く活用する。本発明の第
３の態様によれば、イーサネットＡＯＭが稼働状況監視及び制御のためにリンク状態プロ
トコル制御イーサネット・ネットワークを通じてＩＰサービスにより用いられる。

インフラストラクチャーＯＡＭ
本発明によれば、第１のＩ−ＳＩＤのセットアップ前に、リンク状態プロトコル制御イ
ーサネットはインフラストラクチャー・レベルでＣＦＭメッセージを実行できる。このよ
うなＣＦＭメッセージは図３及び４中のリンク・レイヤー及び図５中のリンクＯＡＭレベ
ルにより用いられる。この時点で、サービスをノード間に展開する以前に、診断ＯＡＭが
ノード間の接続性のテストに役立ち得る。

８０２．１ａｇＣＭＦメッセージ・フォーマットが図６に示されている。８０２．１ａ
ｇ規格に従う或るＣＦＭメッセージ、即ち、ＬＢＭメッセージはユニキャスト宛先アドレ
スを採用する。これらＣＦＭメッセージをリンク状態プロトコル制御イーサネット・ネッ
トワークのトポロジーを検証するよう診断目的で利用できるようにすることは有用である
。そうするため、リンク状態トポロジー内のノードの適切な宛先アドレスが必要である。
こうして、本発明及び図６に示されるところによれば、ユニキャスト宛先アドレスを採用
するＣＦＭメッセージ、即ち、ＬＢＭ及びＬＢＲメッセージについて、宛先ノードのＳｙ
ｓ−ＩＤから導き出されるノードＭＡＣアドレスが用いられる（図７の４００、４０２、
４０４）。このノード・レベルＭＡＣアドレスはリンク状態プロトコル交換時にＦＩＢに
インストールされる。

或るＣＦＭメッセージは、ｍＬＢＭ及びＣＣＭのように、特有のブロードキャスト宛先
アドレスを採用する。これらアドレスはリンク状態イーサネット・プロトコルと非互換性
であり、ＲＰＦＣは壊れてループを結果と生じる。従って、インフラストラクチャー・レ
ベルでは、これらメッセージは使われない。

更に本発明によれば、インフラストラクチャー・レベルでＬＴＭ ＣＦＭメッセージが
アドレスされる方法に変化が生じる。標準規格によれば、ＬＴＭメッセージはよく知られ
たグループ・マルチキャストＭＡＣアドレスを採用する。しかしながら、リンク状態制御
イーサネット・ネットワークでは、第１のＩ−ＳＩＤが確立されるまで如何なるノードＦ
ＩＢ中にもマルチキャスト・エントリーは存在しない。従って、この段階でリンク状態制
御イーサネット・ネットワークにより受取られた標準ＬＴＭメッセージは破棄される。従
って、本発明は標準規格の実装に対する変更を提供する。本発明によるＬＴＭメッセージ
はターゲット宛先ノードについてのユニキャスト宛先アドレスを採用する（図７、４００
、４０６、４０８）。再び、採用される宛先アドレスはターゲット宛先ノードのＳｙｓ−
ＩＤから導き出されるノードのＭＡＣアドレスである。リンク状態制御イーサネット・ネ
ットワークは「フラッド及び学習」ではなく予め構築されているので、宛先への経路が分
かっており、従ってユニキャストＬＴＭメッセージはターゲット・ノードへの予め構築さ
れた経路に従うことが出来る。

ここで図８を参照すると、ＯＡＭを備えたリンク状態プロトコル制御イーサネット・ネ
ットワークはインフラストラクチャー・レベルで接続性を二重チェックする機会を提供す
る。リンク状態制御イーサネット・ネットワーク内の或るノードについて、オペレータは
リンク状態データベース自体をチェック出来てリンク状態プロトコルにより何の接続が形
成されたか分かる（４２０、４２２）。そして、オペレータはノードから或いはノードの
ペア間にリンク・トレースを走らせる事が出来て（４２４）ノード間に存在する実際の経
路がＦＩＢにより反映されるように初期にセットアップされたリンク状態プロトコルに一
致するかどうか分かるようにチェックする（４２６−４３０）。

サービス・レベルＯＡＭ
Ｉ−ＳＩＤがセットアップされた後、リンク状態プロトコル制御イーサネットはまたサ
ービス・レベルでＣＦＭを実行する。イーサネットＯＡＭはＩ−ＳＩＤレベルで働くよう
に設計されており、そして８０２．１ａｇ及びＹ．１７７３が用いられてリンク状態プロ
トコル制御イーサネットのサービス・レベルＯＡＭの機能を強化され得る。

ｍＬＴ
典型的なフラッド及び逆経路学習イーサネット・ネットワークでは、全Ｉ−ＳＩＤは１
つのマルチキャスト送信元アドレスにルートされた同一のマルチキャスト配信経路に従う
。しかし、リンク状態プロトコル制御イーサネット・ネットワークでは、各サービス・イ
ンスタンス、即ちＩＳＩＤ、がマルチキャスト配信経路をルートする。それで、もしリン
ク状態プロトコル制御イーサネット・ネットワークにおけるサービス・インスタンス経路
をトラブルシューティングしたいならユニキャストＬＴＭ或いは標準に準拠するＩＳＩＤ
と不調和のマルチキャストＬＴＭを用いるのではなく、新しい代替を用いる方が理に叶う
。本発明の一態様によれば、新しいＯＡＭリンク・トレース・メッセージが従ってサービ
ス・レベルで提供される。リンク追跡は、図６のマルチキャスト標準イーサネットＤＡを
用いる代わりに、そのＤＡとしてＩ−ＳＩＤマルチキャスト・アドレスを用いる（図９の
４５６）。ＩＳＩＤマルチキャストＤＡを用いることにより、リンク追跡は典型的なイー
サネット・マルチキャスト・ツリーからではなく、追跡が発進されるためのノードからル
ートされる最適マルチキャスト経路に従う。

ディスカバリー
サービス・レベルＯＡＭはリンク状態プロトコル制御イーサネット・ネットワークのト
ポロジーを有効化するためにディスカバリー目的で用いられ得る。例えば、図９を参照し
、「Ｓｈｏｗ ＩＳＩＤツリー」コマンドがＩＳＩＤの付けられたノードから発進され得
る（４５４）。１つの選択によれば、ｍＬＢＭコマンド（ワイルドカードｐｉｎｇ）が、
８０２．１ａｇ規格のＣＦＭ ｍＤＡではなく、ＩＳＩＤ ｍＤＡを用いて、ＩＳＩＤノ
ードから発進される（４５８）。或いは、各ＩＳＩＤエンドポイントについて、ユニキャ
ストＬＴＭ（トレースルート）がＩＳＩＤ内で発進される（４６０）。他の選択では、前
述のｍＬＴＭ（ワイルドカード・トレースルート）コマンドＩＳＩＤノードから発進され
得て、マルチキャストＩＳＩＤツリーの経路を追跡する（４５６）。

リンク状態プロトコルはネットワーク・トポロジーのビューとともにネットワーク内の
全てのノードに在ることに注目されたい。それで、例えば、リンク状態データベースがＩ
Ｓ−ＩＳデータベースであるところの、図１０のステップ５００−５０６に示されるよう
に、或るＩＳＩＤに付いた全てのエンドノードについてのＩＳ−ＩＳデータベースにクエ
リー出来る。そして、上述のサービス・レベルＯＡＭがデータプレーンを通じて走らされ
得てデータ・プレーン・トポロジーが、制御プレーンがそうあるべきと示すように実際に
構成されているかが分かる。

ディスカバリーはネットワーク内の経路を有効化するために用いられ得る。「Ｓｈｏｗ
ＩＳＩＤ経路」コマンド（図９の４６２）はエンドポイント間の経路を検証出来る。例
えば、ノードＡ及びＢ間のＩＳＩＤ上の経路を示すため、ＬＴＭ（トレースルート）をＩ
ＳＩＤ１０１上のノードＡからノードＢに発進する（４６４）。再び、ＬＴＭ ＤＡは宛
先ノードのｓｙｓ−ＩＤ（ノードＢ）のユニキャストＤＡであり、標準規格準拠ＣＦＭ
ＤＡではない。

接続性
再び、リンク状態プロトコルはネットワーク・トポロジーのそれぞれのビューとともに
ネットワーク内の全てのノードに在る。そうして、例えば、図１０のステップ５０８−５
１２に示されるように、リンク状態データベースがＩＳ−ＩＳデータベースである場合、
ＩＳ−ＩＳデータベース内のどのノードからもノードＡ及びノードＢ間のＩ−ＳＩＤ経路
につて照会出来る。或いは、他のエンドノードへの経路についてのＩ−ＳＩＤ上の如何な
るから照会出来、例えば、エンドノードＢへの経路を示すためにエンドノードＡから照会
出来る。そして、上述のサービス・レベルＯＡＭリンク・トレースがデータ・プレーンを
通じて走りデータ・プレーン・トポロジーは制御プレーンがそうあるべきであると示して
いるように実際に構成されているかが分かる。

サービスＯＡＭは、Ｉ−ＳＩＤエンドポイント間及びＩ−ＳＩＤ内で、接続性検証及び
失敗検出のためにも用いられ得る。ＣＦＭ ＣＣＭに等価のＯＡＭメッセージは接続性チ
ェックの仕組みとしてＩ−ＳＩＤに付いたエンドノードから発行され得る（図１０の５１
４）。再び、これらＣＣＭメッセージはＣＦＭ−ＤＡとは反対に、Ｉ−ＳＩＤ ｍＤＡ（
Ｓｙｓ−ＩＤに解かれる）に基づいてアドレスされる。更に、これらＣＣＭメッセージは
全てのサービス・レベルにて発行され得る。ＩＰ−ＶＰＮ、ＶＲＦ、その他はＩ−ＳＩＤ
を通じて解かれるが、ＩＰサブネット・レベルＣＣＭメッセージは直接的にＳｙｓ−ＩＤ
に解かれる。

ＭＥＰ／ＭＩＰ自動生成
本発明の態様によれば、リンク状態プロトコル制御イーサネット・ネットワークはＭＥ
Ｐ及びＭＩＰの自動生成を可能にする。

リンク・トレース・プロトコル・ディスカバリーの一部として、リンク状態プロトコル
制御イーサネット・ネットワーク内の各ノードはデフォルトＭＤレベル８０２．１ａｇロ
ジックを自動的に例示するが、ＭＡＣアドレスに翻訳されるＳｙｓ−ＩＤ名を用いてそう
する。本発明によれば、図１１に示されるように、インフラストラクチャー・レベルで、
各ノードはＳｙｓ−ＩＤをハッシュしてＭＥＰ及びまたはＭＩＰを誘導し（６００）、Ｔ
ＬＶにこの情報を保持させる（６０２）。ＴＬＶはリンク状態ＰＤＵ（ＬＳＰ）内をネッ
トワークに伝えられる（６０４）。図１２において、ノードがそのようなＬＳＰを受取る
とＴＬＶの受取ったＭＥＰ情報はそこからＬＳＡを受取ったエンドポイントに関連付けら
れる。受取りエンドポイントはエントリーをそのＦＩＢに付加してＭＥＰにそこからＬＳ
Ａを受取ったノードのノードＭＡＣに関連付けてＭＥＰおよびＳｙｓ−ＩＤの結合を生成
する。こうして各ノードはネットワーク内の他の全てのノードについて何のＭＩＰ及びＭ
ＥＰポイントかを知る。

こうして、オペレータは特定のノードの視点からインフラストラクチャー・レベルＯＡ
Ｍコマンドを実行できる。例えば、図１３のステップ６２０−６２６に示されるように、
オペレータはノードＡ及びＢ間の疎通性チェックの遂行を選択する。そうすると、ノード
Ａから、オペレータはイーサネットＯＡＭ ＬＢＭ 即ち「ｐｉｎｇ」コマンドを実行す
る。本発明によれば、ノードＡは、リンク状態構築最中に以前に保持された、ノードＢの
ＭＥＰについてそのリンク状態データベースをチェックする。一旦これが知れると、ノー
ドＢの宛先アドレスとＬＢＭメッセージが造られる。ノードＢのＦＩＢは、ノードＢへの
途中において、ＬＢＭメッセージが次のポップＭＩＰに送られるべき事を示す（もし実際
にＡ及びＢ間にノードが存在するなら）。

図５に示されるように、異なる維持ドメインが異なるＭＥＰ及びＭＩＰ ＭＤレベルに
関連付けられる。こうして、サービス・レベルにおいて、ＭＥＰ及びＭＩＰ ＭＤレベル
の異なるセットが特定される。リンク状態プロトコル制御イーサネット・ネットワークは
種々のサービス・レベルにおいて必要によりＭＥＰ及びＭＩＰのダイナミック自動構築を
可能にする。インフラストラクチャー・レベルにて、リンクを監視するためのポートＭＥ
Ｐが８０２．１ａｇ規格に述べられているように「デフォルト」ＭＡＩＤレベルにおいて
ＭＤレベル０とともに示され、そして常にオンである。種々のサービス・レベルはＣＣＭ
のようなメッセージを運ぶための常時オンＭＥＰをも有する事が出来る。これらＭＥＰは
サービス・レベル識別子Ｉ−ＳＩＤの機能としてＭＡＩＤ、そしてドメインに適したＭＤ
レベルとともに生成される。ＭＩＰはリンク状態プロトコル・ディスカバリーの最中は常
にオンとして、ドメインに適したＭＤレベルとともに生成される。

リンク状態プロトコル・イーサネット・ネットワークのＩＰ ＯＡＭ
前述のように、２００８年５月５日に出願されたリンク状態プロトコル制御イーサネッ
ト・ネットワークに亘るＩＰ転送と題する、ここで参照される、同時継続米国特許出願番
号１２／１５１，６８４に記載されるように、ＩＰアドレスはリンク状態プロトコル制御
イーサネット・ネットワークにおける転送に用いられるＭＡＣアドレスに直接的にマップ
できる。ここで説明されるように、リンク状態プロトコル制御イーサネット・ネットワー
クのノードがＩＰアドレスを学習するとき、ノードはＩＰアドレスをリンク状態広告に挿
入してＩＰアドレスの到達性をネットワークの他のノードに報せる。各ノードはこのＬＳ
Ｐにリンク状態データベースに報せるＩＰアドレスを加える。パケットが入口ノードに到
着すると入口ノードはＩＰアドレスを読み、リンク状態プロトコル制御イーサネット・ネ
ットワーク上のどのノードがＩＰアドレスに気付いているかを判断し、そしてパケットを
正しいノードに送るためＭＡＣヘッダーを構築する。ＭＡＣヘッダーのＤＡ／ＶＩＤはＩ
Ｐアドレスを広告したノードのノードＭＡＣであり、例えば、これはＳｙｓ−ＩＤでもよ
い。

ＩＰサブネットはリンク状態プロトコル制御イーサネット・ネットワークに調和的にマ
ップされ得るので、ＭＥＰ及びＭＩＰの自動生成及びリンク状態プロトコル制御イーサネ
ットの強化されたＯＡＭはＰｉｎｇ及びイーサネットＯＡＭに基づくトレースルート能力
のような、ＩＰについてのＯＡＭ機能を可能にする。

例えば、図１４を参照すると、リンク状態プロトコル制御イーサネット・ネットワーク
が再び示されており、ここではＭＥＰ及びＭＩＰが前述のように自動的に構築されている
。Ｓｙｓ−ＩＤサンノゼのノードはＩＰアドレス１０．２０．０．１６／２４を有するよ
う示される。Ｓｙｓ−ＩＤデンバーのノードはＩＰアドレス１０．２０．８．１２８／２
４を有するよう示される。図１５を参照すると、ノード・サンノゼのオペレータはＩＰコ
マンド「Ｐｉｎｇ１０．２０．８．１２８」を入力する（７２０）。（或いは、ＤＮＳを
通じて解決される等価ＩＰ名或いは名前変換される他のＩＰの手段であってもよい。）サ
ンノゼのノードは１０．２０．８．１２８が付いている事を報せるＬＳＡをデンバーから
従前に受取っているので、サンノゼのデータベースは宛先ＩＰアドレスをデンバーのＭＡ
Ｃに解決する（７２２）。ＩＰのｐｉｎｇコマンドは宛先デンバーを伴うイーサネットＯ
ＡＭ ＬＢＭとして解決される（７２４）。サンノゼ・ノードはそのＦＩＢをチェックし
てデンバーのＭＥＰを見つける。ＬＢＭがＤＡデンバーに送られ、ＶＩＤ ＭＩＰ（７２
６）。デンバー及びサンノゼ間のインフラストラクチャー疎通性を考えると、ＬＢＲがサ
ンノゼに返される。

同様に、図１６を参照すると、ノード・サンノゼのオペレータはＩＰコマンド「トレー
スルート１０．２０．８．１２８」を入力できる（７４０）。（ここでも、等価ＩＰネー
ム解決があってもよい。）サンノゼのノードは１０．２０．８．１２８が付いたことを報
せるデンバーからのＬＳＡを従前に受取っているので、サンノゼのデータベースは宛先Ｉ
ＰアドレスをデンバーのＭＡＣに解決する（７４２）。ＩＰのトレースルート・コマンド
は宛先デンバーでイーサネットＯＡＭ ＬＴコマンドとして解決される（７４４）。サン
ノゼ・ノードはそのＦＩＢをチェックしてデンバーのＭＥＰを見つける。ＬＴＭはＤＡデ
ンバー、ＶＩＤ ＭＩＰに送られる（７４６）。

稼働状況監視
８０２．１ａｇ規格はメトリクス及びメッセージの稼働状況の監視を含むように拡張さ
れた。この標準はＩＴＵ−Ｔ ＳＧ１３，Ｙ．１７３１、イーサネット・ネットワークの
ＯＡＭについての要件に反映されており、ここに参照される。以下の性能パラメータは適
切なＯＡＭメッセージにより測定される。

１）フレーム損失率（ＦＬＲ）− ＦＬＲは、パーセントで表示され、時間間隔Ｔの間
のサービス・フレームの総数で割った、届かなかったサービス・フレームの数であり、こ
こで届けられなかったサービス・フレームの数とは入口ＵＮＩに送られたサービス・フレ
ームの数と出口ＵＮＩで受取られたサービス・フレームの数との差である。２つタイプの
ＦＬＲ測定が可能であり、デュアル・エンデドＬＭ（損失測定）及びシングル・エンデド
ＬＭである。デュアル・エンデドＬＭは送り出されたフレーム及び受取ったフレームの適
切な計数を含むＣＣＭ ＯＡＭフレームの交換により実現される。これら計数はＭＥＰ
ＭＥレベルのＯＡＭフレームを含まない。デュアル・エンデドＬＭはＭＥＧ各エンドの近
いエンド及び遠いエンドの両方の先取り測定を可能にする。シングル・エンデドＬＭはＬ
ＭＭ及びＬＭＲフレームのオン・デマンドな交換により実現される。これらのフレームは
適切な計数の送り出されたフレーム及び受取られたフレームを含む。シングル・エンデド
ＬＭだけが近いエンド及び遠いエンドのＦＬＲをＬＭリクエストを開始したエンドにおい
て提供する。

２）フレーム遅延（ＦＤ）− ＦＤはフレームの周り道として特定され、ＦＤは、ルー
プバックがフレームの宛先で遂行されるときには、ソース・ノードによるフレームの最初
のビットの送出し開始から同一ソース・ノードによるループバックされたフレームの最後
のビットまでの時間経過として定義される。

３）フレーム遅延変化（ＦＤＶ）− ＦＤＶはサービス・フレームの対の間のＦＤの変
化の尺度であり、サービス・フレームはポイント・ツー・ポイント・イーサネット接続上
の同一ＣｏＳ（サービスのクラス）に属する。

多くの場合のＩＰサブネットはリンク状態プロトコル制御イーサネット・ネットワークに
調和的にマップすることに再び注目されたい。ここで、ＭＥＰ及びＭＩＰの自動生成とリ
ンク状態プロトコル制御イーサネットについての強化されたＯＡＭ及び稼働状況監視は今
まで成し得なかったイーサネットに亘るＩＰについての木目細かくされた、精細された「
ＳＯＮＥＴ型」ＯＡＭを可能にする。

図１７を参照すると、イーサネット稼働ＯＡＭがＩＰアプリケーションで有益な多数の
アプリケーションの１つが示されている。示されているのはプロバイダー８００ｓカスタ
マー施設８０２である。カトタマーはリンク状態プロトコル制御イーサネット・ネットワ
ーク８０８を通じてプロバイダー８００にアクセス・ボックス８０６を介して接続されて
いるＩＰフォン８０４を有している。プロバイダー８００内ではアクセス・ボックス８０
６に即ちＩＰフォン８０４にＶＯＩＰサービスを提供するサーバー８１２にネットワーク
８０８を接続する種々のブリッジ８１０があってよい。図１８の全てのデバイスはＩＰデ
バイスである。ＩＰフォン、サーバー、及びブリッジ、示されていない他のブリッジ及び
デバイスがリンク状態プロトコル制御イーサネット・ネットワークを造り上げる。そのよ
うにして、それら各々は関連するＳｙｓ−ＩＤを有する。ＩＳ−ＩＳのようなリンク状態
プロトコルはネットワーク内の全てのエレメント間にユニキャスト・ループ・フリー通信
経路を造る。ＩＰフォン及びサーバーは、２００８年５月５日に出願されたリンク状態プ
ロトコル制御イーサネット・ネットワークに亘るＩＰ転送と題し、参照される、同時継続
米国特許出願番号１２／１５１，６８４に記載される方法に従って確立される。要するに
、ＩＰフォンＩＰサブネットがＩＰフォン・ノードにより学習されてリンク状態広告中に
挿入されてＩＰサブネットの到達性をリンク状態プロトコル制御イーサネット・ネットワ
ーク上の他のノードに報らせる。同様に、サーバーのＩＰサブネットがサーバー・ノード
により学習されてリンク状態広告中に挿入されてそのＩＰサブネットの到達性をリンク状
態プロトコル制御イーサネット・ネットワーク上の他のノードに報らせる。パケットが入
口ノードに到着すると入口ノードはＩＰアドレスを読み、リンク状態プロトコル制御イー
サネット・ネットワーク上のどのノードがＩＰアドレスに気付いているかを判断し、そし
て正しいノードにパケットを転送するＭＡＣヘッダーを構築する。ＭＡＣヘッダーのＤＡ
／ＶＩＤはＩＰアドレスを広告したノードのノードＭＡＣである。この場合、ＩＰフォン
からサーバーへのＩＰフロー（即ちＶＯＩＰ）はＩＰフォンが取り付けられているノード
のＭＡＣを解決する。サーバーからＩＰフォンへのＩＰフローはサーバーが取り付けられ
たノードのＭＡＣを解決する。

ＣＦＭ ＯＡＭに関して既に述べたようにオペレータはリンク状態イーサネット・コマ
ンドに直接マップされ得る「ｐｉｎｇ」及び「トレースルート」のようなＩＰレベル・コ
マンドを遂行できる。更に本発明によれば、ＩＰレベル稼働状況監視機能がリンク状態イ
ーサネット・コマンド及びフィードバックに基づいて提供される。

例えば、図１８を参照し、サーバー８１２がＩＰフォンに関連する特定のＶＯＩＰスト
リームについての遅延及びジッターを監視する事は望ましい。本発明によれば、このタス
クはＶＯＩＰストリームがリンク状態プロトコル制御イーサネットをキャリーオーバーさ
れるという事実により可能となり、ここで述べられるＯＡＭ機能の利点となり得る。例え
ば、オペレータはサーバー・ノード８１２からコマンド「次の時間にわたって遅延、ジッ
ターを監視」を発進できる（８２０）。ＩＰレベルＯＡＭコマンドはサーバー８１２にお
いて解決されてサーバー８１２及びＩＰフォン８０４間の一連のイーサネット・レベル・
コマンドとなる。この例で用いられるようなＯＡＭレベル・コマンドはＦＤ及びＦＤＶで
ある。第１に、ＩＰフォンが取り付けられたノード或いはＩＰフォン自身のＭＡＣアドレ
スはＦＩＢを用いて解決される（８２２）。そしてＯＡＭ ＦＤ及びＦＤＶコマンドが、
サーバー８１２が取り付けられたノードからＩＰフォン８０４が取り付けられたノードへ
と特定の時間についてサーバー８１２のＦＩＢに特定されたＭＩＰブリッジ８１０転送経
路を通じて転送され得る（８２６）。ＩＰフローについての性能統計値はイーサネット・
ネットワーク上のＩＰフローについてかつては出来なかったような非常に詳細な方法で制
御され得る。必要なら、ＯＡＭコマンドからのフィードバックの結果に基づいて、ＶＯＩ
Ｐフローがそして調節可能となる（８２８）。

ＩＰ稼働状況監視は本発明により、ＩＰ電話、ＩＰ ＴＶ／ビデオ、移動ＩＰ、データ
センター、その他を含む多くのＩＰ技術について実装できる。リンク状態プロトコル制御
イーサネットは多くのまったく異なるタイプ及びレベルのＩＰドメイン及びデバイスを一
体化するためにＩＰ稼働状況監視及び制御を可能にする。本発明によるＩＰレベルでの直
接的なイーサネットＯＡＭ稼働状況監視を用いる能力は詳細なＬＳＡを容易に支える、音
声、データ、及びビデオについてのＩＰトラフィック制御レベルを可能にする。

本発明は１つ或いは複数の製品上或いは中の１つ或いは複数のコンピュータ読み取り可
能なソフトウェア・プログラムとして実装されてもよい。製品は、例えば、フロッピー・
ディスク、ハードディスク、ハードドライブ、ＣＤ−ＲＯＭ、フラッシュ・メモリー・カ
ード、ＥＥＰＲＯＭ、ＥＰＲＯＭ、ＰＲＯＭ、ＲＡＭ、ＲＯＭ、或いは磁気テープの１つ
或いは組合せでもり得る。一般に、どのような標準規格、ベンダー独自規格、プログラミ
ング或いはインタープリター言語がコンピュータ読み出し可能ソフトウェア・プログラム
の生成に用いられ得る。そのような言語はＣ、Ｃ＋＋、ＪＡＶＡ、ＶｉｓｕａｌＢａｓｉ
ｃ、ＶｉｓｕａｌＣ＋＋を含む。ソフトウェア・プログラムはソースコード、オブジェク
ト・コード、インタプリター・コード、或いは事項コードとして１つ或いは複数の製品に
ストアされてもよい。

本発明は特定の好ましい実施例を参照して示されそして述べられたが、以下の特許請求
の範囲により特定される発明の真意及び範囲から外れることなく形式及び詳細においては
種々の変更が可能であることが当業者には容易に理解できる。

Claims (6)

1. リンク状態プロトコル制御イーサネット・ネットワークにおけるネットワーク・トポロ
   ジー検証方法であって、
   ノードにおけるリンク状態プロトコル・データベースをチェックしてネットワークの少
   なくとも一部の制御プレーン・トポロジー・ビューを確かめるステップ、
   ノードからの１つ或いは複数のイーサネットＯＡＭコマンドを実行してネットワークの
   同一部分のデータ・プレーン・トポロジー・ビューを確かめるステップ、
   ネットワークの制御プレーン・トポロジー・ビューをネットワークのデータ・トポロジ
   ー・ビューに比較してそれらが一致するかを見るステップ、
   それらが一致しないときにエラーを示すステップ、
   を含む方法。
2. ノードにおけるリンク状態プロトコル・データベースをチェックするステップは、リン
   ク状態プロトコル制御イーサネット・ネットワーク内の第１のノードからネットワークを
   通じる全ての経路を追跡するステップを含み、そして、
   １つ或いは複数のイーサネットＯＡＭコマンドを実行するステップは、第１のノードか
   らの１つ或いは複数のリンク・トレース・イーサネットＯＡＭリンク・トレース・コマン
   ドを実行してサービス・インスタンスを実行するステップを含み、リンク・トレース・コ
   マンドは、宛先アドレスとして、サービス・インタンスのマルチキャスト宛先アドレスを
   用いることを除いて、８０２．１ａｇフォーマットを用いる、
   請求項１に記載の方法。
3. リンク状態プロトコル・データベースをチェックするステップは、リンク状態プロトコ
   ル制御イーサネット・ネットワーク内の第１のノードから第２のノードへのネットワーク
   を通じての全ての経路を追跡するステップを含み、そして、
   １つ或いは複数のイーサネットＯＡＭコマンドを実行するステップは、第１のノード１
   つ或いは複数のイーサネットＯＡＭコマンドを実行してサービス経路を追跡するステップ
   を含み、リンク・トレース・コマンドは、宛先アドレスとして、イーサネットＭＡＣノー
   ドＩＤのユニキャスト宛先アドレスを用いることを除いて、８０２．１ａｇフォーマット
   を用いる、
   請求項２に記載の方法。
4. リンク状態プロトコル制御イーサネット・ネットワークにおけるネットワーク・トポロ
   ジー検証を遂行するコンピュータ・プログラムであって、
   ノードにおけるリンク状態プロトコル・データベースをチェックしてネットワークの少
   なくとも一部の制御プレーン・トポロジー・ビューを確かめるためのロジック、
   ノードからの１つ或いは複数のイーサネットＯＡＭコマンドを実行してネットワークの
   同一部分のデータ・プレーン・トポロジー・ビューを確かめるためのロジック、
   ネットワークの制御プレーン・トポロジー・ビューをネットワークのデータ・トポロジ
   ー・ビューに比較してそれらが一致するかを見るためのロジック、
   それらが一致しないときにエラーを示すためのロジック、
   を含むコンピュータ・プログラム。
5. ノードにおけるリンク状態プロトコル・データベースをチェックするためのロジックは
   、リンク状態プロトコル制御イーサネット・ネットワーク内の第１のノードからネットワ
   ークを通じる全ての経路を追跡するためのロジックを含み、そして、
   １つ或いは複数のイーサネットＯＡＭコマンドを実行するためのロジックは、第１のノ
   ードからの１つ或いは複数のリンク・トレース・イーサネットＯＡＭリンク・トレース・
   コマンドを実行してサービス・インスタンスを実行するためのロジックを含み、リンク・
   トレース・コマンドは、宛先アドレスとして、サービス・インタンスのマルチキャスト宛
   先アドレスを用いることを除いて、８０２．１ａｇフォーマットを用いる。
   請求項４記載のコンピュータ・プログラム。
6. リンク状態プロトコル・データベースをチェックするためのロジックは、リンク状態プ
   ロトコル制御イーサネット・ネットワーク内の第１のノードから第２のノードへのネット
   ワークを通じての全ての経路を追跡するためのロジックを含み、そして、
   １つ或いは複数のイーサネットＯＡＭコマンドを実行するためのロジックは、第１のノ
   ード１つ或いは複数のイーサネットＯＡＭコマンドを実行してサービス経路を追跡するた
   めのロジックを含み、リンク・トレース・コマンドは、宛先アドレスとして、イーサネッ
   トＭＡＣノードＩＤのユニキャスト宛先アドレスを用いることを除いて、８０２．１ａｇ
   フォーマットを用いる、
   請求項５記載のコンピュータ・プログラム。