(57)【特許請求の範囲】
【請求項１】
光学的に相互接続されている複数のノード（Node A, Node B, Node C, Node D）との間において通信バスが共有されており、それら複数のノードのうちから、あるノードに対する通信バスのアクセス（使用）をアービトレーション（調停）する方法であって、
あるノード（Node B）が、送信側（または、所定の初期化ノード）として、所定のタイミングのクロックが埋め込まれヘッダのフィールドを含んでいるデータフレームを、バス上に提示するステップと、
あるノード（Node B）が、受信側として、バス上に提示されているデータフレームに埋め込まれているクロックと同期するステップと、
あるノード（Node B）が、送信側として、同期されたデータフレームの範囲内において、自分のノードに前もって割り当てられているところのノードＩＤにより決定されるアイドルパターン（ｉｐ）を、バス上に連続的に提示しておくステップと、
あるノード（Node B）が、バスのアクセス（使用）に関する送信側のリクエストとして、ヘッダのフィールドの範囲内において、自分のノードに前もって割り当てられている所定のタイミングをもって、バス上において発光するステップと、
あるノード（Node B）が、受信側として、複数のノードのうちの何れかに属している（あるノード（Node B）を除いた）別のノード（Node A, Node C, Node D）から、バスへのアクセス（使用）に関するリクエストが示されているところの、バス上に発光されてきている状況（リクエストビットの存在）を、ヘッダのフィールドの範囲内において、モニタするステップと、
を含む、
方法。
【請求項２】
もし、あるノード（Node B）のみがバス上に発行している状況を示していたら、あるノード（Node B）が、送信側として、アイドルパターン（ｉｐ）の提示に代えて、次に続くデータフレームにおいて、データを提示するステップを含む、
請求項１に記載の方法。
【請求項３】
もし、あるノード（Node B）以外にも、別のノードからバス上に発光している状況を示していたら、あるノード（Node B）が、送信側として、アイドルパターン（ｉｐ）の提示を続けて、あるノード（Node B）が、バス上における発光を打ち切る、
請求項１に記載の方法。
【請求項４】
アイドルパターン（ｉｐ）が、同期されたデータフレームの範囲内において、複数のノード（Node A, Node B, Node C, Node D）にわたるラウンドロビンのやり方で、前もって割り当てられている、
請求項１に記載の方法。
【請求項５】
光学的に相互接続されている複数のノード（Node A, Node B, Node C, Node D）との間において通信バスが共有されており、それら複数のノードのうちから、あるノードに対する通信バスのアクセス（使用）をアービトレーション（調停）するバスコントローラであって、
あるノード（Node B）が、送信側（または、所定の初期化ノード）としてバス上に提示しており、所定のタイミングのクロックが埋め込まれヘッダのフィールドを含んでいるデータフレームを、同期させる機能と、
あるノード（Node B）が、送信側としてバス上に連続的に提示しており、同期されたデータフレームの範囲内において、自分のノードに前もって割り当てられているところのノードＩＤにより決定されるアイドルパターン（ｉｐ）を、発生させる機能と、
あるノード（Node B）が、バスのアクセス（使用）に関する送信側のリクエストとして、ヘッダのフィールドの範囲内において、自分のノードに前もって割り当てられている所定のタイミングをもって、バス上において発光する機能と、
あるノード（Node B）が、受信側として、複数のノードのうちの何れかに属している（あるノード（Node B）を除いた）別のノード（Node A, Node C, Node D）から、バスへのアクセス（使用）に関するリクエストが示されているところの、バス上に発光されてきている状況（リクエストビットの存在）を、ヘッダのフィールドの範囲内において、モニタする機能と、
を含む、
バスコントローラ。
【請求項６】
もし、あるノード（Node B）のみがバス上に発行している状況を示していたら、あるノード（Node B）が、送信側として、アイドルパターン（ｉｐ）の提示に代えて、次に続くデータフレームにおいて、データを提示する機能を含む、
請求項５に記載のバスコントローラ。
【請求項７】
さらに、送信データバッファ（Tx Data Buf）を備える、
請求項６に記載のバスコントローラ。
【請求項８】
もし、あるノード（Node B）以外にも、別のノードからバス上に発光している状況を示していたら、あるノード（Node B）が、送信側として、アイドルパターン（ｉｐ）の提示を続けて、あるノード（Node B）が、バス上における発光を打ち切る、機能を含む、
請求項５に記載のバスコントローラ。
【請求項９】
アイドルパターン（ｉｐ）が、同期されたデータフレームの範囲内において、複数のノード（Node A, Node B, Node C, Node D）にわたるラウンドロビンのやり方で、前もって割り当てられている、
請求項５に記載のバスコントローラ。
【請求項１０】
光学的に相互接続されている複数のノード（Node A, Node B, Node C, Node D）との間において通信バスが共有されており、それら複数のノードのうちから、あるノードに対する通信バスのアクセス（使用）をアービトレーション（調停）するコンピュータプログラムであって、
あるノード（Node B）が、送信側（または、所定の初期化ノード）として、所定のタイミングのクロックが埋め込まれヘッダのフィールドを含んでいるデータフレームを、バス上に提示するステップと、
あるノード（Node B）が、受信側として、バス上に提示されているデータフレームに埋め込まれているクロックと同期するステップと、
あるノード（Node B）が、送信側として、同期されたデータフレームの範囲内において、自分のノードに前もって割り当てられているところのノードＩＤにより決定されるアイドルパターン（ｉｐ）を、バス上に連続的に提示しておくステップと、
あるノード（Node B）が、バスのアクセス（使用）に関する送信側のリクエストとして、ヘッダのフィールドの範囲内において、自分のノードに前もって割り当てられている所定のタイミングをもって、バス上において発光するステップと、
あるノード（Node B）が、受信側として、複数のノードのうちの何れかに属している（あるノード（Node B）を除いた）別のノード（Node A, Node C, Node D）から、バスへのアクセス（使用）に関するリクエストが示されているところの、バス上に発光されてきている状況（リクエストビットの存在）を、ヘッダのフィールドの範囲内において、モニタするステップと、
を含み、これらのステップをコンピュータに実行させる、
コンピュータプログラム。
【請求項１１】
光学的に相互接続されている複数のノード（Node A, Node B, Node C, Node D）との間において各ノード（各ブレードサーバ）間の通信距離が等しく設定されているバックプレーン用通信バスが共有されており、それら複数のノードのうちから、あるノードに対する通信バスのアクセス（使用）をアービトレーション（調停）する方法であって、
あるノード（Node B）が、送信側（または、所定の初期化ノード）として、所定のタイミングのクロックが埋め込まれヘッダのフィールドを含んでいるデータフレームを、バス上に提示するステップと、
あるノード（Node B）が、受信側として、バス上に提示されているデータフレームに埋め込まれているクロックと同期するステップと、
あるノード（Node B）が、送信側として、同期されたデータフレームの範囲内において、自分のノードに前もって割り当てられているところのノードＩＤにより決定されるアイドルパターン（ｉｐ）を、バスのＤＣバランスを保つためにバス上に連続的に提示しておくステップと、
あるノード（Node B）が、バスのアクセス（使用）に関する送信側のリクエストとして、ヘッダのフィールドの範囲内において、自分のノードに前もって割り当てられている所定のタイミングをもって、バス上において発光するステップと、
あるノード（Node B）が、受信側として、複数のノードのうちの何れかに属している（あるノード（Node B）を除いた）別のノード（Node A, Node C, Node D）から、バスへのアクセス（使用）に関するリクエストが示されているところの、バス上に発光されてきている状況（リクエストビットの存在）を、ヘッダのフィールドの範囲内において、モニタするステップと、
を含む、
方法。
【請求項１２】
もし、あるノード（Node B）のみがバス上に発行している状況を示していたら、あるノード（Node B）が、送信側として、アイドルパターン（ｉｐ）の提示に代えて、次に続くデータフレームにおいて、データを提示するステップを含む、
請求項１１に記載の方法。
【請求項１３】
もし、あるノード（Node B）以外にも、別のノードからバス上に発光している状況を示していたら、あるノード（Node B）が、送信側として、アイドルパターン（ｉｐ）の提示を続けて、あるノード（Node B）が、バス上における発光を打ち切る、
請求項１１に記載の方法。
【請求項１４】
アイドルパターン（ｉｐ）が、同期されたデータフレームの範囲内において、複数のノード（Node A, Node B, Node C, Node D）にわたるラウンドロビンのやり方で、前もって割り当てられている、
請求項１１に記載の方法。
【請求項１５】
光学的に相互接続されている複数のノード（Node A, Node B, Node C, Node D）との間において各ノード（各ブレードサーバ）間の通信距離が等しく設定されているバックプレーン用通信バスが共有されており、それら複数のノードのうちから、あるノードに対する通信バスのアクセス（使用）をアービトレーション（調停）するバスコントローラであって、
あるノード（Node B）が、送信側（または、所定の初期化ノード）としてバス上に提示しており、所定のタイミングのクロックが埋め込まれヘッダのフィールドを含んでいるデータフレームを、同期させる機能と、
あるノード（Node B）が、送信側としてバス上に連続的に提示しており、同期されたデータフレームの範囲内において、自分のノードに前もって割り当てられているところのノードＩＤにより決定されるアイドルパターン（ｉｐ）を、バスのＤＣバランスを保つために発生させる機能と、
あるノード（Node B）が、バスのアクセス（使用）に関する送信側のリクエストとして、ヘッダのフィールドの範囲内において、自分のノードに前もって割り当てられている所定のタイミングをもって、バス上において発光する機能と、
あるノード（Node B）が、受信側として、複数のノードのうちの何れかに属している（あるノード（Node B）を除いた）別のノード（Node A, Node C, Node D）から、バスへのアクセス（使用）に関するリクエストが示されているところの、バス上に発光されてきている状況（リクエストビットの存在）を、ヘッダのフィールドの範囲内において、モニタする機能と、
を含む、
バスコントローラ。
【請求項１６】
もし、あるノード（Node B）のみがバス上に発行している状況を示していたら、あるノード（Node B）が、送信側として、アイドルパターン（ｉｐ）の提示に代えて、次に続くデータフレームにおいて、データを提示する機能を含む、
請求項１５に記載のバスコントローラ。
【請求項１７】
さらに、送信データバッファ（Tx Data Buf）を備える、
請求項１６に記載のバスコントローラ。
【請求項１８】
もし、あるノード（Node B）以外にも、別のノードからバス上に発光している状況を示していたら、あるノード（Node B）が、送信側として、アイドルパターン（ｉｐ）の提示を続けて、あるノード（Node B）が、バス上における発光を打ち切る、機能を含む、
請求項１５に記載のバスコントローラ。
【請求項１９】
アイドルパターン（ｉｐ）が、同期されたデータフレームの範囲内において、複数のノード（Node A, Node B, Node C, Node D）にわたるラウンドロビンのやり方で、前もって割り当てられている、
請求項１５に記載のバスコントローラ。
【請求項２０】
光学的に相互接続されている複数のノード（Node A, Node B, Node C, Node D）との間において各ノード（各ブレードサーバ）間の通信距離が等しく設定されているバックプレーン用通信バスが共有されており、それら複数のノードのうちから、あるノードに対する通信バスのアクセス（使用）をアービトレーション（調停）するコンピュータプログラムであって、
あるノード（Node B）が、送信側（または、所定の初期化ノード）として、所定のタイミングのクロックが埋め込まれヘッダのフィールドを含んでいるデータフレームを、バス上に提示するステップと、
あるノード（Node B）が、受信側として、バス上に提示されているデータフレームに埋め込まれているクロックと同期するステップと、
あるノード（Node B）が、送信側として、同期されたデータフレームの範囲内において、自分のノードに前もって割り当てられているところのノードＩＤにより決定されるアイドルパターン（ｉｐ）を、バスのＤＣバランスを保つためにバス上に連続的に提示しておくステップと、
あるノード（Node B）が、バスのアクセス（使用）に関する送信側のリクエストとして、ヘッダのフィールドの範囲内において、自分のノードに前もって割り当てられている所定のタイミングをもって、バス上において発光するステップと、
あるノード（Node B）が、受信側として、複数のノードのうちの何れかに属している（あるノード（Node B）を除いた）別のノード（Node A, Node C, Node D）から、バスへのアクセス（使用）に関するリクエストが示されているところの、バス上に発光されてきている状況（リクエストビットの存在）を、ヘッダのフィールドの範囲内において、モニタするステップと、
を含み、これらのステップをコンピュータに実行させる、
コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、光通信バスのアクセス（使用）をアービトレーション（調停）することに関する。
【背景技術】
【０００２】
図１は、複数のブレードサーバ（複数のノード）が光学的に相互接続された、光通信バスの構成例を示す図である。
【０００３】
ブレードサーバ(Blade servers)のバックプレーン(Backplane)用光通信バスについては、日本国における先の出願である特願２０１０−１４９３７３号（出願人整理番号：ＪＰ９２０１０００２１）において説明されている。図１は、この出願で説明されているものである。
【０００４】
この出願においては、バックプレーンに対して任意に（この図では、最大６枚まで）差し込まれることになる任意のブレード・サーバ間の通信距離が何れにおいても等しく設定される。
【０００５】
図１の(a)で模式的に示しているが、光学的に相互接続されている複数のブレードサーバ（複数のノード）の間において、通信バスとなる部分が共有されている。具体的には、Ｍで示される部分において、通信バスのアクセス（使用）が共有されている。Ｌ１〜ＬｎまたはＮ０〜Ｎｎのように放射状に分岐していることから、スタートポロジー(star topology)と呼ばれている。
【０００６】
図１の(a)で模式的に示しているが、Ｌ０〜Ｍ〜Ｎ０という通信経路、Ｌ１〜Ｍ〜Ｎ１という通信経路、Ｌ２〜Ｍ〜Ｎ２という通信経路における、３つの通信経路の距離は、どれも等しい距離に設定されている。(b)から(c)のように模式的に変形されたものが、バックプレーンにファイバーシート(fiber sheet)または光導波路(optical waveguide)として形成されている。
【０００７】
このように設定された、通信距離が等しい複数のブレードサーバ（複数のノード）の間においては、データの送り出し元と送り先を選択するために、複数の波長を使ったWave Division Multiplex （ＷＤＭ） 技術が用いられる。しかしながら、ＷＤＭデバイスは高価であることが知られている。
【０００８】
ＷＤＭに代わる方法として、同じ波長を使いながらも、時分割で送るTime Division Multiplex （ＴＤＭ）技術がある。
【０００９】
図２は、ＴＤＭ光リンクを使った従来技術としての、Passive Optical Network（ＰＯＮ）を示す図である。
【００１０】
ＰＯＮでは、各ノードが送信できるタイミングを、あらかじめタイムスロットとして各ノードへ割り当てている。複数の Subscriber Optical Network Unit (ONU) が Central Office Line Terminal (LT) を使用するにあたり、Guard Time が確保された時分割が用いられる。
【００１１】
しかし、ブレードサーバでは、Bandwidthon demand という観点から、各ブレードからの要求に応じてバスを取り合いながら使う方式が望ましい。
【００１２】
また、光バックプレーンではデータ中にクロックタイミングを埋め込むため、受信側でClock Data Recovery （ＣＤＲ）を行う。バスを有効に使うためには、送信開始からなるべく早く、受信側のＣＤＲデバイスがロックして、クロックを取り出す必要がある。
【００１３】
ロック時間は、ＣＤＲの方式、入力データの変化の仕方、周波数ずれ具合など様々なパラメータに依存するが、通常は、数十nsecから数百nsec程度である。
【００１４】
通常、１対１もしくは１対多をむすぶ光リンクでは、データを送っていないときでも、アイドル信号を流し、常時ロックをかけておく。しかし、光バスでは、発光源が複数あるので、それぞれが勝手にアイドルデータを流すわけにはいかず、この手は使えない。
【００１５】
図３は、ＤＣバランスがとれた状態の波形と、ＤＣバランスがとれていない状態の波形とを示す模式図である。
【００１６】
光リンクは、ＡＣカップリングで使われるため、ＤＣバランスをとる必要があると同時に、すばやく動作するためには、一定時間内に定期的に刺激を与えなければならない（信号を入出力しなければならない）。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】日本国特許出願  特願２０１０−１４９３７３号  （出願日２０１０年６月３０日）  （出願人整理番号：ＪＰ９２０１０００２１）
【発明の概要】
【発明が解決しようとする課題】
【００１８】
本発明の目的は、高価なＷＤＭデバイスを必要とすることなく、あるノードに対する通信バスのアクセス（使用）をアービトレーション（調停）することにある。
【課題を解決するための手段】
【００１９】
常にバス上に信号を流し、各ノードはその信号に同期する。これによってＣＤＲのロック状態を保つ。
【００２０】
バスを使いたいノードはバス上を流れるフレームヘッダの前もって割り当てられている時間スロットに発光することで、バスのアービトレーション（調停）を行う。
【００２１】
各ノードはアイドル信号スロットを検出する。検出したとき、自分に割り当てられたタイミングでアイドルパターンをバス上に流す。すべてのノードが、前もって割り当てられている期間中、一度は送信し、ＡＣカップリングデバイスのＤＣバランスを保つ。
【発明の効果】
【００２２】
高価なＷＤＭデバイスを必要とすることなく、あるノードに対する通信バスのアクセス（使用）をアービトレーション（調停）することができる。
【図面の簡単な説明】
【００２３】
【図１】図１は、複数のブレードサーバ（複数のノード）が光学的に相互接続された、光通信バスの構成例を示す図である。
【図２】図２は、ＴＤＭ光リンクを使った従来技術としての、Passive Optical Network（ＰＯＮ）を示す図である。
【図３】図３は、ＤＣバランスがとれた状態の波形と、ＤＣバランスがとれていない状態の波形とを示す模式図である。
【図４】図４は、本発明を実施するバスコントローラ回路の構成例を示す図である。
【図５】図５は、通信データフレームの構造とそれを複数のノード間のバスアービトレーションに利用する方法を示す図である。
【図６】図６は、アービトレーション（調停）の動作例を示す図である。
【図７】図７は、動作の状態遷移図である。
【発明を実施するための形態】
【００２４】
図４は、本発明を実施するバスコントローラ回路の構成例を示す図である。
【００２５】
Node ID （ノードＩＤ）は、複数のノードが差し込まれるバックプレーン側に用意されたマネージメントモジュールなどにより、複数のブレードがバックプレーンに差し込まれている状況に応じて、電源投入時などに予め割り当てられる。
差し込まれたブレードは、光コネクタ(Opticalconnector)（図１参照）を通じて、通信バスに対してＴＸ（送信）、ＲＸ（受信）を行う。
【００２６】
送信データは、ホストインタフェース(HostInterface)から送信データバッファ(Tx Data Buf)に入力され、フレームコントローラ(Frame Controller)によって、送信データフレームが生成され、後述するバスアービトレーション機構により、バス権限を得たタイミングスロットで送信される。
【００２７】
また、フレームコントローラは、後述するアイドルパターンを出す必要があるタイミングスロットでは、アイドルパターン発生器(Idle Pattern)からアイドルパターン（ｉｐ）を取り出し送信する。
【００２８】
送信データはクロックを埋め込んで送信されるが(EmbeddedClocking)、その送信クロックの周波数とフェーズは、受信部のClock Data Recovery (ＣＤＲ) で再生されたクロックをフェーズシフターを通してリファレンスクロックとして利用する。これにより、バックプレーンの通信バス（特許文献１）に接続された全ての複数のノードで送信クロックを同期することができ、ＰＯＮの様に送信ノードが切り替わるたびに ＣＤＲ の再ロックをする必要がなくなり、帯域を効率的に使える。
【００２９】
受信したデータは ＣＤＲで再生されたクロックでラッチされデシリアライザー(Des)を通した後、受信バッファ(Rx Buf.)にストアされる。受信データフレームのうちヘッダ部分は、バスアービトレーションやアイドルパターン（ｉｐ）の送信制御などフレームコントローラ(Frame Controller) にも使われる。受信データ部分はホストインタフェースから出力される。
【００３０】
このバスコントローラは、これらの機能を含むシステムとしても構成できる。また、これらの機能を複数のステップをもって実現する方法として、さらには、これらのステップをコンピュータに実行させるコンピュータプログラムとして実現することができる。
【００３１】
図５は、通信データフレームの構造とそれを複数のノード間のバスアービトレーションに利用する方法を示す図である。
【００３２】
バスを使いたい複数のノード（Node A,Node B, Node C, Node D）は、ヘッダ(Header)中の自分のノードに前もって割り当てられている所定のタイミングで、発光する。この図においては、リクエストビットによって、発光している。
【００３３】
複数のノードの全員がこのリクエストビット（の存在）をモニタすることで、アイドルスロット（どのノードもリクエストをだしていなかった）、自分だけがリクエストを出している（次のスロットではバスを使用可）、自分のノード以外のノードからもリクエストを出している（バックオフによる衝突回避）、といった状況を把握することができ、それに応じて自分のノードが次にとるべき動作を判断することができる。
【００３４】
このような態様は、複数のノードを互いに区別できることに本質があるので、当業者であれば、様々なリクエストの出し方を設計することができる。
【００３５】
ペイロード(Payload)と呼ばれる部分にはデータ(data)を含めて送信することができ、情報の内容にスクランブルをかけて送信することができる。
【００３６】
図６は、アービトレーション（調停）の動作例を示す図である。
【００３７】
図６の上にある処理例１(Transactionexample 1:)は、ノードＢだけがバスをリクエストし、他のノードがバスをリクエストしていないため、ノードＢがバスへのアクセス（使用）権限を獲得し(Granted)、次に続くデータフレームにおいて、ノードＢがデータ(data)をバス上に流した（提示した）例である。
【００３８】
図６の下にある処理例２(Transactionexample 2:)は、ノードＢとノードＣが同時にバスをリクエストしたため、コンテンション(Contention)が生じており、双方ともバックオフを行う。その際、ノードＢとノードＣが、発光を打ち切っている。ランダム時間の待ち(Random Wait)の後、ノードＢが再びバスをリクエストし、バスへのアクセス（使用）権限を獲得した例である。
【００３９】
アイドルパターン（ｉｐ）の提示
どのノードもリクエストを出していなかったバススロットをアイドルスロットと呼ぶことにする。各ノードはバス上に流れるヘッダをモニタし、アイドルスロットを検出する。
【００４０】
自分のノードに前もって割り当てられている所定のタイミング（ノードＩＤより決定される）でアイドルパターン(ip)を流すことにより、定期的に、送信機を刺激する。ここでは、ラウンドロビンのやり方(round robin manner)で割り当てられているが、広い意味において「連続的」に提示されていればよく、この他にも当業者であれば様々なやり方を設計することができる。
【００４１】
誰もバスを使わないときはアイドルパターン（ｉｐ）が流れる。また、バスが連続的に使用され、どうしても期限内にアイドルパターンを発行できないときは、能動的にバスをリクエストし、アイドルパターンを発行する。
【００４２】
図７は、動作の状態遷移図である。
【００４３】
この動作の状態遷移は一例にすぎず、この他にも当業者であれば様々なやり方を設計することができる。
【図１】
0005623258.tif 000002
【図２】
0005623258.tif 000003
【図３】
0005623258.tif 000004
【図４】
0005623258.tif 000005
【図５】
0005623258.tif 000006
【図６】
0005623258.tif 000007
【図７】
0005623258.tif 000008