(57)【要約】  本発明は、自動近隣者発見を実行するための、光ネットワーク内のネットワーク管理方法に関する。デバイス１０は、イーサネット接続１２を介してイーサネットパケットを光データユニットに透過的にマッピングし、逆も同様である光トランスポートネットワーク（ＯＴＮ）デバイス１１に接続される。この方法は、複数のデバイス１０、１１のうちの第１のデバイスによって、ＯＴＮデバイス１１のポート１４がイーサネット接続１２を経由してデバイス１０のポート１３に接続されていることを決定するステップ２１と、第１のデバイスによって、イーサネット接続１２を介してリンク構成パターンを送信するステップ２３であって、リンク構成パターンが、ビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つであり、リンク構成パターンが、第１のデバイスを識別するＩＤと、第１のデバイスのポートを識別するポート番号とを含む、送信するステップ２３とを含む。
2013516822.tif 000002
【特許請求の範囲】
【請求項１】
トランスポートネットワーク内の隣接関係を発見する方法であって、クライアント層デバイス（１０）がイーサネット接続（１２）を介してトランスポートネットワークデバイス（１１）に接続され、トランスポートネットワークデバイス（１１）がイーサネットパケットを多重化ユニットに透過的にマッピングし、逆も同様であり、
複数のデバイス（１０、１１）のうちの第１のデバイスによって、トランスポートネットワークデバイス（１１）のポート（１４）がイーサネット接続（１２）を経由してクライアント層デバイス（１０）のポート（１３）に接続されていることを決定するステップ（２１）と、
第１のデバイスによって、イーサネット接続（１２）を介してリンク構成パターンを送信するステップ（２３）であって、リンク構成パターンが、所定のビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つであり、無効イーサネットパケットが、イーサネットプロトコルに従って通常処分されることになるパケットであり、リンク構成パターンが、第１のデバイスを識別するデバイス識別子と、第１のデバイスのポートを識別するポート識別子とを含む、送信するステップとを含む、方法。
【請求項２】
複数のデバイス（１０、１１）のうちの第２のデバイスによって、リンク構成パターンを受信するステップ（３１）と、
受信されたリンク構成パターンから、第１のデバイスを識別するデバイス識別子と、第１のデバイスのポートを識別するポート識別子とを決定するステップ（３２）と、
第２のデバイスによって、さらなるリンク構成パターンを第１のデバイスに送信するステップ（３３）であって、さらなるリンク構成パターンが、ビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つであり、リンク構成パターンが、第２のデバイスを識別するデバイス識別子と、第２のデバイスのポートを識別するポート識別子とを含む、送信するステップ（３３）と
をさらに含む、請求項１に記載の方法。
【請求項３】
第１のデバイスによって、第２のデバイスによって送信されたさらなるリンク構成パターンを受信するステップ（４１）と、
第１のデバイスによって、第２のデバイスを識別するデバイス識別子と、第２のデバイスのポートを識別するポート識別子とをさらなるリンク構成パターンから決定するステップ（４２）と
をさらに含む、請求項２に記載の方法。
【請求項４】
送信するステップ活動（２３）の前に、
ビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つのシリーズとなるリンク構成パターンを生成するステップであって、シリーズのすべての要素が、送信デバイスを識別するデバイス識別子と、送信デバイスのポートを識別するポート識別子とを含む、生成するステップをさらに含む、請求項１に記載の方法。
【請求項５】
送信するステップ活動（３３）の前に、
ビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つのシリーズとなるさらなるリンク構成パターンを生成するステップであって、シリーズのすべての要素が、送信デバイスを識別するデバイス識別子と、送信デバイスのポートを識別するポート識別子とを含む、生成するステップをさらに含む、請求項２に記載の方法。
【請求項６】
第１のデバイスがトランスポートネットワークデバイス（１１）であり、第２のデバイスがクライアント層デバイス（１０）である、請求項２に記載の方法。
【請求項７】
さらなるリンク構成パターンの要素が、リンク構成パターンを用いて第２のデバイスによって受信された、第１のデバイスを識別するデバイス識別子と、第１のデバイスのポートを識別するポート識別子とをさらに含む、請求項２に記載の方法。
【請求項８】
受信されたさらなるリンク構成パターンから、第１のデバイスを識別するデバイス識別子と、第１のデバイスのポートを識別するポート識別子とを記憶するステップであって、デバイス識別子が第２のデバイスを識別し、ポート識別子が第１のデバイスのレジスタ内の第２のデバイスのポートを識別する、記憶するステップ
をさらに含む、請求項７に記載の方法。
【請求項９】
トランスポートネットワークデバイス（１１）によって、トランスポートネットワークデバイス（１１）のどのポートも別のトランスポートネットワークデバイスに接続されていないことを決定するステップ（２２）
をさらに含む、請求項６に記載の方法。
【請求項１０】
第１のデバイスによって、さらなるリンク構成パターンを用いて第１のデバイスによって受信された、第１のデバイスを識別するデバイス識別子と、第１のデバイスのポートを識別するポート識別子とが、リンク構成パターンを用いて第１のデバイスによって送信された、第１のデバイスを識別するデバイス識別子と、第１のデバイスのポートを識別するポート識別子とに対応するかどうかを決定するステップと、第１のデバイスによって受信された第１のデバイスを識別するデバイス識別子、および第１のデバイスのポートを識別するポート識別子が、第１のデバイスによって送信された、第１のデバイスを識別するデバイス識別子、および第１のデバイスのポートを識別するポート識別子に対応する場合、データトラフィックに関してイーサネット接続を可能にするステップと
をさらに含む、請求項７に記載の方法。
【請求項１１】
イーサネット接続（１２）を介してクライアント層デバイス（１０）に接続され、イーサネットパケットを多重化ユニットに透過的にマッピングし、逆も同様である、光ネットワーク内のトランスポートネットワークデバイス（１１）であって、
第１の多数のポートのポート（１４）がイーサネット接続（１２）によってクライアント層デバイス（１０）に接続された第１の多数のポート（１６）と、
少なくとも１つの他のトランスポートネットワークデバイスに対して少なくとも１つの光リンクを確立するために提供された第２の多数のポートと、
第１の多数のポートと第２の多数のポートとに結合されたリンク構成パターン生成器であって、前記リンク構成パターン生成器が、信号が第１の多数のポート（１６）のポート（１４）において受信されたかどうかを決定するように構成されており、かつリンク構成パターンを送信するために第１の多数のポート（１６）のポート（１４）を制御するように構成されており、リンク構成パターンが、所定のビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つであり、無効イーサネットパケットがイーサネットプロトコルに従って通常処分されることになるパケットであり、リンク構成パターンが、トランスポートネットワークデバイス（１１）を識別するデバイス識別子と、トランスポートネットワークデバイス（１１）のポート（１４）を識別するポート識別子とを備えた、トランスポートネットワークデバイス（１１）。
【請求項１２】
リンク構成パターンがクライアント層デバイス（１０）からトランスポートネットワークデバイス（１１）のポート（１４）において受信されているかどうかを決定するように構成され、かつ受信されたリンク構成パターンから、クライアント層デバイス（１０）を識別するデバイス識別子と、クライアント層デバイス（１１）のポート（１３）を識別するポート識別子とを決定するように構成されたリンク構成パターンハンドラ
を備えた、請求項１１に記載のトランスポートネットワークデバイス（１１）。
【請求項１３】
トランスポートネットワークデバイス（１１）が、光トランスポートネットワーク（ＯＴＮ）デバイス、または同期デジタルハイアラキー（ＳＤＨ）ネットワークデバイスとして構成される、請求項１１または１２に記載のトランスポートネットワークデバイス（１１）。
【請求項１４】
イーサネット接続（１２）を介してトランスポートネットワークデバイス（１１）に結合されたクライアント層デバイス（１０）であって、
イーサネット接続（１２）を経由してトランスポートネットワークデバイス（１１）のポート（１４）に接続されたポート（１３）と、
リンク構成パターンを送信するためにクライアント層デバイス（１０）のポート（１３）を制御するように構成されたリンク構成パターン生成器であって、リンク構成パターンが、ビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つであり、リンク構成パターンが、クライアント層デバイス（１０）を識別するデバイス識別子と、クライアント層デバイス（１１）のポート（１３）を識別するポート識別子とを含む、リンク構成パターン生成器とを備えた、クライアント層デバイス（１０）。
【請求項１５】
クライアント層デバイス（１０）のポート（１３）に結合されたリンク構成パターンハンドラをさらに備え、前記リンク構成パターンハンドラが、リンク構成パターンがクライアント層デバイス（１０）のポート（１３）において受信されているかどうか決定するように構成されており、かつ受信されたリンク構成パターンから、トランスポートネットワークデバイス（１１）を識別するデバイス識別子と、トランスポートネットワークデバイス（１１）のポート（１４）を識別するポート識別子とを決定するように構成されている
請求項１４に記載のクライアント層デバイス（１０）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信の分野に関し、より詳細には、光トランスポートネットワーク（ＯＴＮ）に関する。さらにより詳細には、本発明は、イーサネット（登録商標）を経由して、ネットワークデバイス、例えば、ルータまたはスイッチをＯＴＮクロスコネクトなどのＯＴＮデバイスに接続するときの近隣者発見に関する。さらにより詳細には、本発明は、光ネットワーク内の近隣者の自動発見に関する方法、光ネットワーク内、ＯＴＮノード内、詳細には、ＯＴＮクロスコネクト内、およびイーサネット接続を経由してＯＴＮノードに接続されたノード内の近隣者の自動発見に関するシステムに関する。
【背景技術】
【０００２】
近隣者発見に関する手順は、いくつかの標準で定義されている。例えば、リンク管理プロトコル（ＬＭＰ）によるジェネラライズドマルチプロトコルラベルスイッチング（Ｇｅｎｅｒａｌｉｚｅｄ  Ｍｕｌｔｉ  Ｐｒｏｔｏｃｏｌ  Ｌａｂｅｌ  Ｓｗｉｔｃｈｉｎｇ）（ＧＭＰＬＳ）標準において、およびその自動発見手順による自動交換光ネットワーク（ＡＳＯＮ）標準に関するアーキテクチャにおいて。これらの標準は両方とも、同期デジタルハイアラキー（ＳＤＨ）ネットワーク、同期光ネットワーキング（ＳＯＮＥＴ）ネットワーク、またはＯＴＮネットワークを制御するために使用され得る。
【０００３】
イーサネット、ＬＭＰ、およびＡＳＯＮの自動発見に関するさらなる情報に関して、引用によりその内容が本明細書に組み込まれている、以下の文書が引用される。イーサネットに関しては、「ＩＥＥＥ  Ｓｔａｎｄａｒｄ  ｆｏｒ  Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ  ｗｉｔｈ  Ｃｏｌｌｉｓｉｏｎ  Ｄｅｔｅｃｔｉｏｎ（ＣＳＭＡ／ＣＤ）Ａｃｃｅｓｓ  Ｍｅｔｈｏｄ  ａｎｄ  Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ」という表題のＩＥＥＥ８０２．３−２０００を参照されたい。ＬＭＰに関しては、Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）の「Ｌｉｎｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ」（ＬＭＰ）という表題のＲＦＣ４２０４、および「Ｓｙｎｃｈｒｏｎｏｕｓ  Ｏｐｔｉｃａｌ  Ｎｅｔｗｏｒｋ（ＳＯＮＥＴ）／Ｓｙｎｃｈｒｏｎｏｕｓ  Ｄｉｇｉｔａｌ  Ｈｉｅｒａｒｃｈｙ（ＳＤＨ）Ｅｎｃｏｄｉｎｇ  ｆｏｒ  Ｌｉｎｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ（ＬＭＰ）Ｔｅｓｔ  Ｍｅｓｓａｇｅｓ」という表題のＲＦＣ４２０７を参照されたい。ＡＳＯＮ自動発見に関しては、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｏｎ（ＩＴＵ）の「Ｇｅｎｅｒａｌｉｚｅｄ  ａｕｔｏｍａｔｉｃ  ｄｉｓｃｏｖｅｒｙ  ｆｏｒ  Ｔｒａｎｓｐｏｒｔ  Ｅｎｔｉｔｉｅｓ」という表題のＩＴＵ−Ｔ  Ｇ．７７１４を参照されたい。
【０００４】
しかし、ＯＴＮクロスコネクトの現世代は、発見のためにイーサネットデータパケットを生成または解析することができないため、イーサネットを経由してネットワークデバイスをＯＴＮクロスコネクトなどのＯＴＮデバイスに接続するとき、近隣者発見手順は存在しない。これは、クロスコネクトのイーサネットインターフェースによって受信されるすべてのデータは、光ネットワーク内で転送された光データユニット（ＯＤＵ）内に透過的にマップされ、逆も同様であるためである。したがって、ＯＴＮクロスコネクトは、例えば、インターネットプロトコル（ＩＰ）アドレスと、ポート番号とを含むメッセージを復号または生成することができない。すなわち、今日のＯＴＮクロスコネクトは、例えば、ＧＭＰＬＳが可能にされた２つのＯＴＮクロスコネクト同士の間の発見が、ＯＴＮクロスコネクトとイーサネットデバイスとの間で成功裏に実行され得るように、イーサネットインターフェース内に何かを挿入するための手段を有さない。
【０００５】
例えば、ローカルデバイスがクロスコネクトを経由して遠隔デバイスに接続されているネットワークにおいてこれは不利である。そのようなネットワークでは、ローカルデバイスがそのローカルデバイスのポートがクロスコネクトのポートにどのように接続されているか、およびデータパケットがクロスコネクトを介して遠隔デバイスにどのように転送されるかを知り、それによって、ネットワーク診断およびネットワーク保守を強固にすることは現在不可能である。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】「ＩＥＥＥ  Ｓｔａｎｄａｒｄ  ｆｏｒ  Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ  ｗｉｔｈ  Ｃｏｌｌｉｓｉｏｎ  Ｄｅｔｅｃｔｉｏｎ（ＣＳＭＡ／ＣＤ）Ａｃｃｅｓｓ  Ｍｅｔｈｏｄ  ａｎｄ  Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ」という表題のＩＥＥＥ８０２．３−２０００
【非特許文献２】「Ｌｉｎｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ」（ＬＭＰ）という表題のＲＦＣ４２０４
【非特許文献３】「Ｓｙｎｃｈｒｏｎｏｕｓ  Ｏｐｔｉｃａｌ  Ｎｅｔｗｏｒｋ（ＳＯＮＥＴ）／Ｓｙｎｃｈｒｏｎｏｕｓ  Ｄｉｇｉｔａｌ  Ｈｉｅｒａｒｃｈｙ（ＳＤＨ）Ｅｎｃｏｄｉｎｇ  ｆｏｒ  Ｌｉｎｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ（ＬＭＰ）Ｔｅｓｔ  Ｍｅｓｓａｇｅ」という表題のＲＦＣ４２０７
【非特許文献４】「Ｇｅｎｅｒａｌｉｚｅｄ  ａｕｔｏｍａｔｉｃ  ｄｉｓｃｏｖｅｒｙ  ｆｏｒ  Ｔｒａｎｓｐｏｒｔ  Ｅｎｔｉｔｉｅｓ」という表題のＩＴＵ−Ｔ  Ｇ．７７１４
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、イーサネットを経由して接続されたネットワークデバイスとＯＴＮクロスコネクトとの間の自動近隣者発見を可能にする必要が存在する。
【課題を解決するための手段】
【０００８】
一態様では、デバイスが、イーサネット接続またはイーサネットリンクを介して、イーサネットパケットをＯＤＵに透過的にマッピングし、逆も同様であるＯＴＮデバイスに接続される、光ネットワーク内のネットワーク管理方法が提供される。この方法は、複数のデバイスのうちの第１のデバイス（すなわち、ＯＴＮデバイス、またはイーサネット接続を経由してＯＴＮデバイスに接続されたデバイス）によって、ＯＴＮデバイスのポートがイーサネット接続を経由してそのデバイスのポートに接続されていることを決定するステップと、第１のデバイスによって、イーサネット接続を介してリンク構成パターンを２つのデバイスのうちのもう片方のデバイス（すなわち、第２のデバイス）に送信するステップであって、リンク構成パターンが、ビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つであり、リンク構成パターンが、第１のデバイスを識別するＩＤと、第１のデバイスのポートを識別するポート番号とを含む、送信するステップとを含む。これにより、第２のデバイスは、第１のデバイスのＩＤおよびポート番号に関する情報を受信する。
【０００９】
この方法は、複数のデバイスのうちの第２のデバイスによって、リンク構成パターンを受信するステップと、第２のデバイスによって、リンク障害パターンから、第１のデバイスを識別するＩＤと、第１のデバイスのポートを識別するポート番号とを決定するステップと、第２のデバイスによって、さらなるリンク構成パターンを第１のデバイスに送信するステップであって、さらなるリンク構成パターンが、ビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つであり、リンク構成パターンが、第２のデバイスを識別するＩＤと、第２のデバイスのポートを識別するポート番号とを含む、送信するステップとによって継続することができる。これにより、第１のデバイスは、第２のデバイスのＩＤとポート番号とに関する情報を受信する。
【００１０】
第１のデバイスは、ＯＴＮデバイスであってよく、第２のデバイスは、イーサネット接続を経由してＯＴＮデバイスに接続されているデバイスであってよい。この場合、自動発見手順は、ＯＴＮデバイスによって開始される。しかし、自動発見手順は、イーサネット接続を経由してＯＴＮデバイスに接続されたデバイス（第１のデバイス）によって開始されることが当然可能であり、この場合、ＯＴＮデバイスは、第２のデバイスである。
【００１１】
以下の説明では、第１のデバイスはＯＴＮデバイスであると仮定される。しかし、これは、必須ではなく、両方のデバイスの役割は交換され得る。この方法は、次いで、ＯＴＮデバイスが、ＯＴＮデバイスのポートがイーサネット接続を経由してデバイスのポートに接続されているかどうかを決定するステップを開始する。ＯＴＮデバイスは、次いで、イーサネット接続を介してリンク構成パターンをそのデバイスが接続されているデバイスに送信する。リンク構成パターンは、所定のビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つであってよい。リンク構成パターンは、ＩＰアドレスなど、ＯＴＮデバイスを識別するＩＤと、ＯＴＮデバイスのポートを識別するポート番号とを含む。
【００１２】
このネットワーク管理方法は、別のデバイスにＯＴＮデバイスのポートとそのデバイスのポートとの間の接続に関する情報を提供できるように、ＯＴＮデバイスがイーサネットを介してそのＩＤとポート番号とをその別のデバイスに送信することを可能にする。すなわち、ＯＴＮクロスコネクト内の故障したＯＤＵと接続されていないイーサネットとの間を区別することが提案される。故障したＯＤＵの場合、リンク障害パターンとも呼ばれるリンク構成パターンが物理リンクイーサネットリンク内に挿入される。
【００１３】
受信機が受信されたリンク障害パターンを識別するために、リンク構成パターンは、マーキングされるか、または別の形で正規のデータパケットと区別可能であることが好ましい。例えば、所定のビットシーケンスは、リンク障害パターンとしてビットシーケンスを識別する定義されたビットパターンを含むことが可能である。無効イーサネットパケットは、通常、処分されるが、リンク構成の関連では、パケットを受信したときのデバイスの状態に応じて、受信されたパケットはリンク障害パターンとして解釈され得る。有効イーサネットパケットは、リンク障害パターンとしてそのパケットをマーキングするための事前に定義された識別子を含むことが好ましい。いずれの場合も、受信されたリンク構成パターンは、正規のデータパケットとは別に処理されるべきであり、リンク区分を超えて伝搬されるべきではない。
【００１４】
このリンク管理方法は、以下のように継続可能である。デバイスは、ＯＴＮデバイスのポートを介してＯＴＮデバイスによって送信されたリンク構成パターンを受信する。次いで、デバイスは、リンク障害パターンから、ＯＴＮデバイスを識別するＩＤと、ＯＴＮデバイスのポートを識別するポート番号とを決定する。リンク構成パターンを受信することに応答して、またはネットワーク管理によって構成されたとき、デバイス自体が、そのポートを介して、さらなるリンク構成パターンをＯＴＮデバイスに送信する。さらなるリンク構成パターンは、所定のビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つであってよい。さらなるリンク構成パターンは、ＩＰアドレスなど、デバイスを識別するＩＤと、デバイスのポートを識別するポート番号とを含む。
【００１５】
さらなるリンク障害パターンを送信することによって、ＯＴＮデバイスのリンク構成パターンに応答することによって、デバイスは、ＯＴＮデバイスがどのデバイスと、そのデバイスのどのポートとにＯＴＮデバイスのポートが接続されているかを見抜くことを可能にする。それに応じて、ＯＴＮデバイスは、イーサネット接続を介してデバイスによって送信されたさらなるリンク構成パターンをさらに受信して、デバイスを識別するＩＤと、デバイスのポートを識別するポート番号とを決定することが可能である。
【００１６】
実施形態では、リンク構成パターンおよび／またはさらなるリンク構成パターンは、所定のビットシーケンス、無効イーサネットパケットおよび有効イーサネットパケットのうちの１つのシリーズであってよく、当該シリーズのすべての要素は、必要とされる情報を含む。同じ情報を複数回送信することによって、当該シリーズの要素の損失は必ずしも発見手順の失敗につながるとは限らず、リンク障害パターン／さらなるリンク構成パターンの発見、ならびにリアルタイムのデータ処理機能に関する要件が削減され得る。
【００１７】
さらに、ネットワーク管理方法は、ＯＴＮデバイスがリンク障害パターンを生成することを含むことが可能である。すなわち、ネットワーク管理方法は、上で議論されたように、イーサネットパケットをＯＤＵコンテナに透過的にマッピングし、逆も同様であるＯＴＮデバイスが、ＯＴＮデバイスＩＤとポート番号とを含むリンク構成パターンを生成することを可能にする。
【００１８】
さらに、ネットワーク管理方法は、デバイスがさらなるリンク障害パターンを生成することを含むことが可能である。この場合、ルータなどのデバイスは、イーサネットパケットを単に転送するだけでなく、さらなるリンク障害パターンを生成することによって、受信されたリンク構成パターンに応答する。したがって、デバイスは、どの種類のさらなるリンク構成パターン、すなわち、ビットシーケンス、無効イーサネットパケット、または有効イーサネットパケットがＯＴＮデバイスによって復号され得るかを知る必要がある。
【００１９】
ネットワーク管理方法は、デバイスおよび／またはＯＴＮデバイスが、ＯＴＮデバイスを識別するＩＤ、ＯＴＮデバイスのポートを識別するポート番号、ならびに／またはデバイスを識別するＩＤ、およびデバイスのポートを識別するポート番号をレジスタ内に記憶するステップをさらに含むことが可能である。そのときまでに、デバイスは両方とも、ＯＴＮデバイスのどのポートがデバイスのどのポートに接続されているかを十分に知る。結果として、ネットワークトポロジーは、それらのデバイスに十分知られる。
【００２０】
実施形態では、ネットワーク管理方法は、ＯＴＮデバイスが構成されており、動作中でないことを決定した後に開始され得る。構成モードは、ＯＴＮデバイスのポートのいずれも別のＯＴＮデバイスに接続されていないことを検出することによって検出され得る。この理由は、通常の動作モードの間にリンク構成パターンの送受信を介したノードの発見が実行されることを回避する必要が存在するためである。この発見は、別のＯＴＮデバイスからイーサネットネットワークへのデータの送信をブロックすべきではない。
【００２１】
さらに、ネットワーク管理方法は、さらなるリンク構成パターンを用いてＯＴＮデバイスによって受信された、ＯＴＮデバイスを識別するＩＤと、にＯＴＮデバイスのポートとを識別するポート番号が、ＯＴＮデバイスによって送信された、ＯＴＮデバイスを識別するＩＤおよびＯＴＮデバイスのポートを識別するポート番号に対応するかどうかを決定することが可能である。これらが対応する場合、デバイスは、ＯＴＮデバイスのＩＤとポート番号とを正確に受信して、送信したと仮定することができる。この場合、ネットワーク管理方法は、データトラフィックに関してイーサネット接続を動作可能にすることができる。
【００２２】
別の態様では、両方ともイーサネット接続を介して接続されたデバイスとＯＴＮデバイスとを含むシステムが光ネットワーク内に提供される。ＯＴＮデバイスは、イーサネットパケットを光データユニットに透過的にマッピングし、逆も同様である。このシステム内で、ＯＴＮデバイスは、第１の多数のポートのポートがイーサネット接続によってデバイスに接続された第１の多数のポートと、少なくとも１つの他のＯＴＮデバイスに対して少なくとも１つの光リンクを確立するために提供された第２の多数のポートと、第１の多数のポートと第２の多数のポートとに結合されたリンク構成パターン生成器とを含む。リンク構成パターン生成器は、信号が第１の多数のポートのポートにおいて受信されたかどうかを決定するように構成され、かつリンク障害パターンを送信するために第１の多数のポートのポートを制御するように構成される。ネットワーク管理方法を参照して上で説明されたように、リンク構成パターンは、所定のビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つであってよい。リンク構成パターンは、ＯＴＮデバイスを識別するＩＤと、ＯＴＮデバイスのポートを識別するポート番号とを含む。
【００２３】
ＯＴＮデバイスは、イーサネットを介して別のデバイスに接続された少なくとも１つのポートを有し、イーサネット接続を介してそのＩＤとポート番号とを他のデバイスに送信し、それによって、他のデバイスにそれらのポート同士の間の接続に関する情報を提供する。
【００２４】
デバイスは、イーサネット接続によってＯＴＮデバイスの第１の多数のポートのポートに接続されたポートと、そのデバイスのそのポートに結合されたリンク構成パターンハンドラとをさらに備える。前記リンク構成パターンハンドラは、リンク構成パターンがそのデバイスのポートにおいて受信されているかどうかを決定するように構成され、そのポートにおいて受信されている場合、ＯＴＮデバイスを識別するＩＤと、ＯＴＮデバイスのポートを識別するポート番号とを決定するように構成される。さらなるリンク構成パターンを送信するためにデバイスのポートを制御するように構成されたさらなるリンク構成パターン生成器が提供され得る。このさらなるリンク構成パターンは、所定のビットシーケンス、無効イーサネットパケット、および有効イーサネットパケットのうちの１つであり、このさらなるリンク構成パターンは、デバイスを識別するＩＤと、デバイスのポートを識別するポート番号とを含む。
【００２５】
リンク構成パターンが受信されるとき、デバイスは、ＯＴＮデバイスのＩＤとポート番号とを抽出することが可能であり、デバイスのポートとＯＴＮデバイスのポートとがどのように接続されているかをＯＴＮデバイスに知らせるために、デバイスのＩＤとポート番号とを含むさらなるリンク構成パターンを用いて応答する。
【００２６】
さらに、ＯＴＮデバイスは、さらなるリンク構成パターンがＯＴＮデバイスのポートにおいて受信されているかどうかを決定するように構成され、そのポートにおいて受信されている場合、デバイスを識別するＩＤと、デバイスのポートを識別するポート番号とを決定するように構成されたさらなるリンク構成パターンハンドラを備えることが可能である。
【００２７】
さらなるリンク構成パターンがＯＴＮデバイスによって受信されたとき、ＯＴＮデバイスは、さらなるリンク構成パターンから、デバイスのポートとＯＴＮデバイスのポートとがどのように接続されているかの情報を抽出することが可能である。
【００２８】
実施形態では、デバイスは、イーサネットルータもしくはイーサネットスイッチであってよく、かつ／またはＯＴＮデバイスは、ＯＴＮクロスコネクトであってよい。
【００２９】
上の説明において、ＯＴＮデバイスによって自動発見プロセスが開始される。既に説明されたように、このプロセスは、他のデバイスによって開始されることも可能であり、その場合、リンク構成パターン生成器がその他のデバイス内に提供され、（存在する場合）さらなるリンク構成パターン生成器がＯＴＮデバイス内に提供される。本発明は、したがって、ＯＴＮデバイスと組み合わせて、またはＯＴＮデバイスと別個に、他のデバイスにも関係する。
【００３０】
提案される方法およびシステムは、デバイスと、イーサネットを経由して接続されたＯＴＮクロスコネクトなど、ＯＴＮデバイスとの間の近隣者発見を可能にし、それによって、ネットワーク診断およびネットワーク保守を円滑にする。
【００３１】
上述の態様は、様々な形で、互いと組み合わせることが可能であり、または互いから抽出されることが可能である点に留意されたい。詳細には、すべての考えられる請求項および特徴の組合せが本書によって開示されると見なされる。さらに、システムに関して概説されたこれらの態様および特徴は、対応する方法に関して等しく適用可能である。
【００３２】
本発明のさらなる利点は、添付の図面と共に、好ましい実施形態の以下の詳細な説明を考慮するとき、より明瞭になるであろう。
【図面の簡単な説明】
【００３３】
【図１】ＯＴＮクロスコネクトに対するデバイスの接続を概略的に例示する図である。
【図２】ＯＴＮクロスコネクトがＩＤとポート番号とを含むリンク構成パターンをどのように送信するかを概略的に例示する図である。
【図３】デバイスが、どのように、ＩＰアドレスとポート番号とを含むリンク構成パターンを受信して、少なくとも１つのＩＤと少なくとも１つのポート番号とを含むさらなるリンク構成パターンを送信することによって応答するかを概略的に例示する図である。
【図４】ＯＴＮクロスコネクトがさらなるリンク障害パターンをどのように受信するかを概略的に例示する図である。
【図５】ギガビットイーサネットフレームを概略的に例示する図である。
【発明を実施するための形態】
【００３４】
図１は、ローカルデバイス（１０）とローカルＯＴＮクロスコネクト（１１）とを含むネットワーク構成を示す。その中で、ルータまたはスイッチなどのローカルデバイス（１０）は、イーサネットを経由して、またはより正確には、イーサネットプロトコルを介して、ローカルＯＴＮクロスコネクト（１１）に接続され得る。より詳細には、ケーブル、例えば、光ファイバを介して、ローカルデバイスのポート（１３）をローカルＯＴＮクロスコネクト（１１）のポート（１４）に接続する物理リンク（１２）、例えば、光リンクが存在し得る。光リンクの場合、すべてのポートは、光パルスを送信または送受信するために、光源と、光検出器、例えば、発光ダイオード（ＬＥＤ）またはレーザダイオードとを備えることが可能である。例えば、物理リンク（１２）を介して信号、例えば、特定の波長の光を受信することによって決定され得る、ローカルデバイス（１０）とローカルＯＴＮクロスコネクト（１１）との間の接続が確立されるとき、近隣者発見手順が開始され得る。
【００３５】
図１では、ローカルデバイス（１０）およびＯＴＮクロスコネクト（１１）の接続だけが示される。しかし、ローカルデバイス（１０）は、他のデバイスに接続されることが可能であり、ＯＴＮクロスコネクト（１１）は、他のＯＴＮクロスコネクトおよび／または他のデバイスに対する接続のために提供される点は明らかである。図１に示されるネットワーク構成に基づき、ローカルＯＴＮクロスコネクト（１１）に接続された遠隔ＯＴＮクロスコネクトの追加要素を備えたネットワーク構成では、ローカルＯＴＮクロスコネクト（１１）は、イーサネットデータパケットをローカルデバイス（１０）から光データユニット（ＯＤＵ）内に透過的にマッピングして、ビットストリームとして、それらを遠隔ＯＴＮクロスコネクトに送信することが可能であり、逆も同様である。
【００３６】
例示的な実施形態は、光リンクを経由して接続されている２つのポートに関して説明されているが、デバイス（１０）の１つのポート（１３）がＯＴＮクロスコネクトの１つのポート（１４）に接続されることが可能であるだけでなく、デバイス（１０）の多数のポート（１５）がＯＴＮクロスコネクト（１１）の多数のポート（１６）に接続されることが当然可能である点は光ネットワークの当業者に明らかであろう。これらの実施形態はＯＴＮクロスコネクトに関して説明されているが、本発明は、イーサネットデータパケットをＯＤＵに透過的にマッピングし、逆も同様である、イーサネットインターフェースを有する任意のＯＴＮデバイスに適用可能であるため、これは本発明をＯＴＮクロスコネクトに限定すると理解されるべきでない点はさらに明らかであろう。
【００３７】
図２は、ローカルＯＴＮクロスコネクト（１１）によって開始される１つの例示的な近隣者発見手順の第１のステップを示す。図１を参照して説明されたように、ローカルＯＴＮクロスコネクト（１１）がローカルデバイス（１０）に接続されていることを決定するステップ（２１）の後で、ローカルＯＴＮクロスコネクト（１１）は、それが遠隔ＯＴＮクロスコネクトに接続されているかどうかを決定する（２２）。これは、例えば、遠隔ＯＴＮクロスコネクトとの接続のために提供されたローカルＯＴＮクロスコネクト（１１）のすべてのポートに関して、信号、例えば、特定の波長の光が光検出器によって検出されているかどうかを検査することによって達成され得る。ポートを能動的に検査するための代替案は、データ構造、例えば、ＯＴＮクロスコネクト（１１）のポートのどれが接続されているかの情報を含むリストをＯＴＮクロスコネクト（１１）内に維持して、ポートの接続状態が変化するときはいつでもそのリストを更新することである。
【００３８】
ローカルＯＴＮクロスコネクト（１１）が、それが遠隔ＯＴＮクロスコネクトに接続されていないことを決定したとき（２２）、ローカルＯＴＮクロスコネクトは、イーサネットを経由してローカルデバイス（１０）のポート（１３）に接続されたポート（１４）を介してリンク構成パターンまたはリンク障害パターンを送信することを（２３）開始する。リンク障害パターンは、ＩＰアドレスなどのデバイスＩＤと、ローカルＯＴＮクロスコネクト（１１）のポート番号とを含む。ポート番号は、イーサネットを経由してローカルデバイス（１０）のポート（１３）に接続され、それを介してリンク障害パターンが送信されるポート（１４）を識別する。
【００３９】
実施形態では、ＯＤＵに接続されていないイーサネットの場合、識別子を含むリンク構成パターン／リンク故障パターンが、物理リンクイーサネットリンク内に挿入される。これは、いくつかの形で行うことが可能である。
１．識別子を含む有効イーサネットパケットのシーケンスを送信する。これは、受信機が、通常のイーサネットパケット処理を実行することを可能にし、そのパケットがその受信機によって処理される必要があることを示す、定義された識別子を必要とする。
２．識別子を含む無効イーサネットパケットのシーケンスを送信する。通常、無効パケットは処分されるが、使用されるイーサネット受信機に応じて、パケットのコンテンツが解釈され得る。このように、通常の処理チェーンには「発見パケット」、すなわち、リンク障害パターンがロードされない。
３．ルータに送信された固定コード内に識別子を埋め込む。この識別子は、遠隔終端に送信されたビットストリーム内に挿入される。このビットストリームは、非機能性接続として解釈されるが、含まれる情報は、リンク障害パターンを送信するために使用され得る。
【００４０】
それぞれの可能性は個々の利点を有するが、これらは同じ目標、すなわち、構成可能であるが、固定されたパターンを遠隔終端に送信するという目標を共有する。遠隔終端は、このパターンを読み取り、それを解釈して、潜在的に異なる通信リンク（ＤＣＮ）を経由してそれを元の終端に送信し戻すことが可能であるべきである。例えば、リンク障害パターンは、ＲＦＣ４２０７におけるＳＤＨセクショントレースと同じ符号化フォーマットを使用することが可能である。
【００４１】
実施形態では、リンク障害パターンは、所定のビットシーケンスのうちの１つまたは所定のビットシーケンスのシリーズであってよく、当該シリーズのすべての要素は、ローカルＯＴＮクロスコネクト（１１）のデバイスＩＤとポート番号とを含む。従来、所定のビットシーケンスは、ＯＴＮクロスコネクトによって生成されて、ローカルＯＴＮクロスコネクト（１１）のバッファ内に記憶されることが可能である。この所定のビットストリームは、デバイスＩＤとポート番号とを含むリンク障害パターンになるビットストリームを識別するために、受信機によって知られている、定義されたビットパターンを含むことが好ましい。記憶した後で、ビットシーケンスは、デバイスＩＤとポート番号とを挿入することによって修正され得る。修正されたビットシーケンスは、次いで、ローカルＯＴＮクロスコネクト（１１）のイーサネットインターフェースのポート（１４）を介してローカルデバイス（１０）に繰り返し送信されること（２３）が可能である。
【００４２】
実施形態では、リンク障害パターンは、無効イーサネットデータパケットのうちの１つまたは無効イーサネットデータパケットのシリーズであってよく、当該シリーズのすべての要素は、ローカルＯＴＮクロスコネクト（１１）のデバイスＩＤとポート番号とを含む。従来、無効イーサネットパケットは、ＯＴＮクロスコネクトによって生成されて、ローカルＯＴＮクロスコネクト（１１）のバッファ内に記憶されて、イーサネットインターフェースのポート（１４）を介してローカルデバイス（１０）に繰り返し送信されること（２３）が可能である。
【００４３】
実施形態では、リンク障害パターンは、有効イーサネットデータパケットのうちの１つまたは有効イーサネットデータパケットのシリーズであってよく、当該シリーズのすべての要素は、ローカルＯＴＮクロスコネクト（１１）のデバイスＩＤとポート番号とを含む。従来、有効イーサネットパケットは、ＯＴＮクロスコネクトによって生成されて、ローカルＯＴＮクロスコネクト（１１）のバッファ内に記憶されて、イーサネットインターフェースのポート（１４）を介してローカルデバイス（１０）に繰り返し送信されること（３２）が可能である。
【００４４】
同一のビットシーケンス、無効イーサネットデータパケット、または有効イーサネットデータパケットのシリーズを送信することによって、遠隔終端における処理は簡素化される。というのは、ビットシーケンス、無効イーサネットデータパケット、または有効イーサネットデータパケットは、手順を中断せずとも、失わせることができ、ビットシーケンス内、無効イーサネットデータパケット内、または有効イーサネットデータパケット内に含まれた情報は、複数のビットシーケンス、無効イーサネットデータパケット、または有効イーサネットデータパケットを介して抽出されることが可能であり、これは、リアルタイム処理機能に関する要件を削減するからである。当該シリーズの要素は、一定の時間間隔で周期的に、または要素同士の間のランダム時間間隔に従って繰り返されることが可能である。
【００４５】
したがって、ローカルＯＴＮクロスコネクト（１１）は、ローカルＯＴＮクロスコネクト（１１）のポートを制御して、ポートが接続されているかどうかを決定することができ、かつ上で指定されたリンク障害パターンのうちの少なくとも１つを生成することができる追加の論理を備えることが可能である。そのようなリンク障害パターン生成器は、例えば、特定用途向け集積回路（ＡＳＩＣ）の形で、または任意のその他の形態の論理の形で構築可能である。
【００４６】
図３は、ローカルデバイス（１０）に関する近隣者発見手順のさらなるステップを示す。その中で、ローカルデバイス（１０）は、ポート（１３）上でローカルＯＴＮクロスコネクト（１１）からリンク障害パターンを受信する（３１）。リンク障害パターンを受信した後で、ローカルデバイス（１０）は、リンク障害パターンがローカルＯＴＮクロスコネクト（１１）のＩＰアドレスとポート番号とを含むかどうかを決定する（３２）。
【００４７】
実施形態では、リンク障害パターンは、ローカルＯＴＮクロスコネクト（１１）のデバイスＩＤとポート番号とを含む所定のビットシーケンスのうちの１つまたは所定のビットシーケンスのシリーズであってよい。次いで、有効イーサネットデータパケットを予想するローカルデバイス（１０）は、非機能的な接続としてリンク障害パターンを発見および解釈して、デバイスＩＤとポート番号とを抽出するために、追加の論理、例えば、リンク障害パターンハンドラを必要とする場合がある。ビットシーケンスは複数回受信されるため、リンク障害パターンハンドラは、ビットシーケンスが繰り返されること、ビットシーケンスが特定の長さを有すること、または当該シーケンスのうちの少なくとも１つが事前に定義されたビット方式に従うことから、リンク障害パターンが受信されていることを発見することができる。さらに、リンク障害パターンハンドラは、リンク障害パターン内のどこにＩＤとポート番号とが含まれているかを知ることが必要とされる。これは、例えば、ビットシーケンス内のＩＤおよびポート番号の位置を事前に指定することによって、達成され得る。
【００４８】
実施形態では、リンク障害パターンは、無効イーサネットデータパケットのうちの１つまたは無効イーサネットデータパケットのシリーズであってよい。したがって、ローカルデバイス（１０）は、イーサネットデータパケットは無効イーサネットデータパケットであるが、リンク障害パターンを用いて送信されたＯＴＮクロスコネクト（１１）のデバイスＩＤとポート番号とを決定する目的でそのコンテンツが解釈されなければならないことを決定するために、追加の論理、例えば、リンク障害パターンハンドラを備えることが可能である。無効イーサネットデータパケットがリンク障害パターンであり、解釈されなければならないことを発見するために、リンク障害パターンハンドラは、例えば、複数回受信された無効イーサネットデータパケットを聴取することができる。代替案として、リンク障害パターンは、無効イーサネットデータパケットの「欠陥」、例えば、どの点でそれが有効イーサネットデータパケットと異なるかを事前に知ることができる。さらに、ローカルデバイス（１０）は、無効イーサネットデータパケット内のどこにＩＤとポート番号とが記憶されているかを知ることが必要な場合がある。例えば、ローカルデバイス（１０）は、ＩＤとポート番号とがギガビットイーサネット「休止」フレームの予約されたバイトセクション内に記憶され得ることを知ることができ、これは、図５を参照してさらに詳細に議論される。
【００４９】
実施形態では、リンク障害パターンは、有効イーサネットデータパケットのうちの１つまたは有効イーサネットデータパケットのシリーズであってよい。この場合、ローカルデバイス（１０）は、デバイスＩＤとポート番号とを決定するために、特定の識別子を備えた有効イーサネットデータパケットがローカルデバイス（１０）によって検出および解釈され得るように修正されることが可能である。当該シリーズの要素は、一定の時間間隔で周期的に、または要素間のランダム時間間隔に従って、繰り返されることが可能である。
【００５０】
ローカルデバイス（１０）が、どのイーサネットデータパケットが解釈されなければならない可能性があるかを知るために、これらのパケットに割り当てられた識別子を事前に合意され得る。さらに、ローカルデバイス（１０）は、イーサネットデータパケット内のどこにＩＤとポート番号とが記憶され得るかを知ることが必要な場合がある。上述のように、１つの可能性は、ギガビットイーサネット休止フレームの予約されたバイトセクション内にＩＤとポート番号とを記憶することであり得る。
【００５１】
ローカルＯＴＮクロスコネクト（１１）の決定されたデバイスＩＤおよびポート番号は、次いで、ローカルデバイス（１０）のレジスタ内に記憶されることが可能である。これは、ローカルデバイス（１０）がローカルＯＴＮクロスコネクトのポートに対するそのポートの接続を知ることを可能にし、したがって、ネットワークの構成、保守、および診断を円滑にする。さらに、この情報は、誤接続を発見および警告するために使用され得る。さらに、この方法を用いて、サービス要員による手動インタラクションがあまり必要ではなくなり、コスト削減につながる可能性がある。
【００５２】
次のステップとして、ローカルデバイス（１０）は、さらなるリンク障害パターンを送信すること（３３）が可能である。このさらなるリンク障害パターンは、ポート（１３）を介したローカルＯＴＮクロスコネクト（１１）に対するビットシーケンス、無効イーサネットデータパケット、または有効イーサネットデータパケットのうちの１つのシリーズであってよい。当該シリーズのすべての要素は、ローカルデバイス（１０）のＩＰアドレスおよびポート番号と、ローカルＯＴＮクロスコネクト（１１）のＩＰアドレスおよびポート番号とを含む。従来、ビットシーケンス、無効イーサネットデータパケット、または有効イーサネットパケットは、ローカルデバイス（１０）のバッファ内に記憶されて、ローカルデバイス（１０）のＩＰアドレスとポート番号とを挿入することによって修正されて、イーサネットインターフェースのポート（１３）を介してローカルＯＴＮクロスコネクト（１１）に送信されること（２３）が可能である。
【００５３】
実施形態では、さらなるリンク障害パターンは、ローカルデバイス（１０）によって受信されたローカルＯＴＮクロスコネクト（１１）のＩＰアドレスとポート番号とを含むことも可能である。このさらなるリンク障害パターンは、識別子と、その情報がリンク障害パターンとして記憶された場所とに関して、上で説明されたリンク故障パターンと同じ構造を有する場合がある。
【００５４】
受信、記憶、および送信のために、ローカルデバイス（１０）は、ローカルデバイス（１０）のポートを制御して、ポート（１３）によって受信されたリンク障害パターンを読み取り、リンク障害パターン内に含まれたＩＰアドレスとポート番号とを決定して、ローカルデバイス（１０）のＩＰアドレスおよびポート番号、ならびに、場合によっては、ローカルＯＴＮクロスコネクト（１１）のＩＰアドレスおよびポート番号を含み得るさらなるリンク障害パターンを、ポート（１３）を介してローカルＯＴＮクロスコネクト（１１）に送信することができる追加の論理、例えば、ＡＳＩＣの形で構築されたリンク障害パターンハンドラ／生成器を備えることが可能である。
【００５５】
図４は、ローカルＯＴＮクロスコネクト（１１）に関する近隣者発見手順のさらなるステップを示す。そこで、ローカルＯＴＮクロスコネクト（１１）は、ポート（１４）を介してローカルデバイス（１０）から、さらなるリンク障害パターンを受信して（４１）、ローカルデバイス（１０）のＩＰアドレスおよびポート番号、ならびにさらなるリンク障害パターン内に含まれる場合、ローカルＯＴＮクロスコネクト（１１）のＩＰアドレスおよびポート番号を決定する（４２）。
【００５６】
従来、ローカルＯＴＮクロスコネクト（１１）は、例えば、ＡＳＩＣの形で構築され得るさらなるリンク障害パターンハンドラなど、追加の論理を備えることが可能である。より詳細には、ローカルＯＴＮクロスコネクト（１１）は、受信されたデータが上で指定されたさらなるリンク障害パターン、すなわち、繰り返された所定のビットシーケンス、繰り返された無効イーサネットデータパケット、または繰り返された有効イーサネットデータパケットのうちの１つに対応するかどうかを決定することができる、さらなるリンク障害パターンハンドラを備えることが可能である。受信されたデータがさらなるリンク障害パターンに対応することを決定するために、かつさらなるリンク障害パターンのどの部分が必要とされる情報を含むかを決定するために、さらなるリンク障害パターンハンドラは、上で説明されたリンク障害パターンハンドラによって使用される技法に対応する技法を使用することが可能である。
【００５７】
さらなるリンク障害パターンがローカルＯＴＮクロスコネクト（１１）によって受信されたとき、ＯＴＮクロスコネクト（１１）内のさらなるリンク障害パターンハンドラは、さらなるリンク障害パターンの一部のコンテンツをバッファ内に記憶することが可能である。さらに、さらなるリンク障害パターンハンドラは、ローカルデバイス（１０）のデバイスＩＤおよびポート番号、ならびにさらなるリンク障害パターン内に含まれている場合、ＯＴＮクロスコネクト（１１）のデバイスＩＤおよびポート番号を決定することが可能である。
【００５８】
あるいは、さらなるリンク障害パターンハンドラは、パターンに対して同期して、情報を含む部分だけを抽出することによって、ローカルデバイス（１０）のデバイスＩＤおよびポート番号、ならびにＯＴＮクロスコネクト（１１）のデバイスＩＤおよびポート番号を受信されたさらなるリンク障害パターンから直接的に決定することが可能である。この点で、さらなるリンク障害パターンが要素のシリーズであるとき、ローカルＯＴＮクロスコネクトは、１つの単一のビットシーケンス、無効イーサネットデータパケット、または有効イーサネットデータパケットから情報を決定することは必要とされないが、当該シリーズ内のいくつかのビットシーケンス、無効イーサネットデータパケット、または有効イーサネットデータパケットを介して情報を収集することが可能である点に留意されたい。すなわち、情報は、シリーズ全体を介してビットごとに完成され得る。既に上で述べたように、ローカルＯＴＮクロスコネクトは、ＯＴＮクロスコネクトがリンク障害パターンの要素全体を処理することを可能にすることになるリアルタイムデータ処理機能を有する必要がないため、これは特に有利である。さらに、同じデータが何度も繰り返されるため、ＯＴＮクロスコネクトは、さらなるリンク障害パターンに対して容易に同期され得る。
【００５９】
ローカルデバイス（１０）のデバイスＩＤとポート番号とを決定した後で、前記情報は、さらなるリンク障害パターンハンドラによってローカルＯＴＮクロスコネクト（１１）のレジスタ内に記憶可能である。しかし、ローカルＯＴＮクロスコネクト（１１）の決定されたデバイスＩＤおよびポート番号は、ローカルＯＴＮクロスコネクト（１１）の送信されたデバイスＩＤおよびポート番号と比較されることが可能であり、それによって、ローカルデバイス（１０）がその情報を正確に受信および送信したかを検査することを可能にする。前記検査が、その情報が正確に受信または送信されていないことを示す場合、その情報は、レジスタから削除され得る。前記検査が、その情報が正確に受信されていること、および／または送信されていることを示す場合、データトラフィックに関してイーサネット接続（１２）が動作可能にされる。
【００６０】
実施形態では、イーサネット接続（１２）は、ギガビットイーサネット接続であってよい。
【００６１】
図５では、ギガビットイーサネットフレームが示される。ギガビットイーサネットは、標準のイーサネットフレームフォーマットに従って設計されている。したがって、ギガビットイーサネットフレームは、宛先アドレスおよびソースアドレス、ならびにデータフィールドのバイト長を識別する長さフィールドを含むヘッダからなり、データフィールドは、ペイロードとチェックサムとを含む。
【００６２】
イーサネット標準に対する全二重モードの追加は、「休止」フレームとして知られているオプションのフロー制御動作を含む。休止フレームは、一方の終端局が（ＭＡＣ制御フレームを除いて）他方の終端局からのすべてのトラフィックを一時的に中断することを許可する。
【００６３】
例えば、「局Ａ」および「局Ｂ」と呼ばれる２つのデバイスを接続する全二重リンクを仮定する。局Ａは、局Ｂに輻輳状態に入らせる（すなわち、追加のフレームを受信するためのバッファ空間が残っていない）速度でフレームを送信すると想定する。局Ｂは、指定された期間の間フレームの送信を中止することを局Ａに要求する休止フレームを局Ａに送信することが可能である。休止フレームを受信するとすぐ、局Ａは、指定された期間が経過するまで、さらなるフレーム送信を中断することになる。これは、局Ｂに、輻輳状態から回復するための時間を与える。指定された期間の終わりに、局Ａは、通常のフレーム送信を再開することになる。
【００６４】
休止フレームのフォーマットは、標準のイーサネットフレームフォーマットに従うが、独自のタイプフィールドと、以下のようなその他のパラメータとを含む：
フレームの宛先アドレスは、休止されることになる局の独自のＤＡ、または大域的に割り当てられたマルチキャストアドレス０１−８０−Ｃ２−００−００−０１（１６進法）に設定されてよい。このマルチキャストアドレスは、ＭＡＣ制御休止フレーム内で使用するために、ＩＥＥＥ８０２．３標準によって予約されている。このマルチキャストアドレスは、ブリッジによって転送されないことになるアドレスとして、ＩＥＥＥ８０２．１Ｄブリッジング標準内にも予約される。これは、そのフレームがローカルリンク区分を超えて伝搬しないことを確実にする。
【００６５】
休止フレームの「タイプ」フィールドは、そのフレームがＭＡＣ制御フレームであることを示すために、８８−０８（１６進法）に設定される。
【００６６】
ＭＡＣ制御オペコードフィールドは、使用されているＭＡＣ制御フレームのタイプが休止フレームであることを示すために、００−０１（１６進法）に設定される。休止フレームは、この標準で現在定義されている唯一のＭＡＣ制御フレームタイプである。
【００６７】
ＭＡＣ制御パラメータフィールドは、休止事象の存続時間を５１２ビット時間の単位で指定する１６ビット値を含む。有効な値は００−００からＦＦ−Ｆ（１６進法）である。現在の休止時間が終了する前に追加の休止フレームが到着した場合、そのパラメータは、現在休止時間を置換し、したがって、ゼロのパラメータを有する休止フレームは、トラフィックが即時に再開するのを可能にする。
【００６８】
（すべてゼロとして送信される）４２バイトの予約フィールドは、休止フレームの長さをパディングして（ｐａｄ）、最小イーサネットフレームサイズにすることが必要とされる。
【００６９】
実施形態では、デバイスＩＤおよびポート番号は、４２バイト予約フィールド内に挿入され得る。例えば、ＩＰアドレスとポート番号とが予約フィールド内に含まれることが可能である。使用された符号化に関する一例として、Ｇ．７７１４が使用され得る。上述のように、リンク障害パターン生成器およびリンク障害パターンハンドラは、通常、クロスコネクト内で使用され、イーサネットとＳＤＨとの間で変換するＡＳＩＣの形で実施されることが可能である。リンク障害パターンを生成するために、要素「データコードグループ」と要素「特殊コードグループ」とが使用され得る。
【００７０】
実施形態では、ＡＳＩＣを実施するために以下が関連し得る：
・データコードグループは、符号化および復号されるが、ＰＣＳによって解釈されない。データコードグループの成功裏の復号は、Ｓｔａｒｔ＿ｏｆ＿Ｐａｃｋｅｔデリミタの適切な受信に依存する。
・１６ビットの構成レジスタ（Ｃｏｎｆｉｇ＿Ｒｅｇ）をリンクパートナーに伝達するために、順序付けられたセット／Ｃ１／および／Ｃ２／の連続的な反復として定義される、構成順序付きセットが使用される。
・データ（／Ｄ／）、すなわち、データコードグループは、定義されたｏｒｄｅｒｅｄ＿ｓｅｔに関する情報を区別または伝達するために使用されないとき、ＭＡＣとＰＣＳとの間の任意のデータの１オクテットを伝達する。
【００７１】
本書では、イーサネットを経由して接続されたデバイスとＯＴＮクロスコネクトとの間の近隣者発見を可能にするためのシステムおよび方法が説明されている。提案された方法およびシステムは、効率的なネットワーク診断およびネットワーク保守を可能にする。
【００７２】
この説明およびこれらの図面は、提案される方法およびシステムの原理を単に例示する点に留意されたい。したがって、当業者は、本明細書で明示的に説明または示されないが、本発明の原理を実施し、その趣旨および範囲内に含まれる様々な構成を考案することが可能になることを理解されよう。さらに、本明細書で列挙されたすべての実施例は、主に、当技術を促すために、提案された方法およびシステムの原理、ならびに本発明者らによって貢献された概念を理解する際に読者を援助する教育的な目的のみが明示的に意図され、そのような詳細に列挙される実施例および条件に対する限定がないとして解釈されるべきである。さらに、本発明の原理、態様、および実施形態、ならびにそれらの特定の実施例を列挙する本明細書のすべての記述は、その均等物を包含することが意図される。
【００７３】
さらに、様々な上述の方法のステップ、および説明されたシステムの構成要素は、プログラムされたコンピュータによって実行され得る点に留意されたい。本明細書で、いくつかの実施形態は、プログラム記憶装置、例えば、機械可読であるかまたはコンピュータ可読であるデジタルデータ記憶媒体をカバーし、命令の機械実行可能プログラムまたはコンピュータ実行可能プログラムを符号化することも意図され、前記命令は、前記上述の方法のステップのうちのいくつかまたはすべてを実行する。プログラム記憶装置は、例えば、デジタルメモリ、磁気ディスクおよび磁気テープなどの磁気記憶媒体、ハードドライブ、または光学的に読み取り可能なデジタルデータ記憶媒体であってよい。これらの実施形態は、上述の方法の前記ステップを実行するようにプログラムされたコンピュータをカバーすることも意図される。
【００７４】
加えて、本特許文書で説明された様々な要素の機能は、専用ハードウェア、ならび適切なソフトウェアに関連してソフトウェアを実行することが可能なハードウェアの使用により実現され得る点に留意されたい。プロセッサによって実現されるとき、これらの機能は、単一の専用プロセッサによって、単一の共有プロセッサによって、またはそれらのうちのいくつかが共有され得る複数の個々のプロセッサによって実現され得る。さらに、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行することが可能なハードウェアを排他的に指すと解釈されるべきでなく、限定せずに、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性記憶装置を暗示的に含むことが可能である。その他のハードウェア、従来のハードウェアおよび／または特別注文のハードウェアも含まれ得る。
【００７５】
最後に、本明細書の任意のブロック図は、本発明の原理を実施する例示的な回路の概念図を表す点に留意されたい。同様に、任意のフローチャート、流れ図、状態遷移図、疑似コードなどは、そのようなコンピュータまたはプロセッサが明示的に示されようと、示されまいと、コンピュータ可読媒体の形で本質的に表され、コンピュータまたはプロセッサによってそのように実行されることが可能な様々なプロセスを表す点を理解されよう。
【図１】
2013516822.tif 000003
【図２】
2013516822.tif 000004
【図３】
2013516822.tif 000005
【図４】
2013516822.tif 000006
【図５】
2013516822.tif 000007
【国際調査報告】
2013516822.tif 000008
2013516822.tif 000009
2013516822.tif 000010