以下の記載は、複数の添付の図面を参照して、この出願の複数の技術的解決方法を説明する。
この出願の複数の実施形態における複数の技術的解決方法は、FlexO、FlexE、又は他のネットワークに適用されてもよいということを理解すべきである。このことは、この出願の複数の実施態様においては限定されない。
この出願の複数の実施形態における物理的接続リンクを、単に、"リンク"と称してもよく、FlexEにおけるリンクを、"PHYリンク"と称してもよいということを理解すべきである。この出願の複数の実施形態におけるリンクは、ソース端デバイスと受信端デバイスとの間のリンクであり、ソース端デバイスから受信端デバイスへのリンクには中間デバイスが存在してもよい。
以下の記載は、本明細書における複数の概念を簡潔に説明する。
FlexE技術:
現時点までのかなり長い期間にわたって、イーサネットは、幅広く適用され、且つ、著しく発展してきた。イーサネットインターフェイス速度は、10倍に増加し、そして、10[Mbps]から100[Mbps]、1000[Mbps](1[Gbps])、10[Gbps]、100[Gbps]へと継続的に発展してきている。イーサネットインターフェイス速度が増加の一途をたどるに伴い、イーサネットインターフェイス速度のさらなる改善は、徐々に、技術的なボトルネックに近づきつつある。加えて、実際のシナリオにおける多様化したイーサネットインターフェイス速度の要件を満たすために、例えば、200[Gbps]、40[Gbps]、200[Gbps]、及び400[Gbps]のイーサネットインターフェイスが開発されている。
新たな世代の高速度イーサネットインターフェイスの規格が出現する前に、ネットワークの帯域幅要件は、通常は、既存のイーサネットインターフェイス速度を超えている。新たなイーサネットインターフェイスの規格が出現し、そして、その新たなイーサネットインターフェイスのコストが比較的高い過渡的な段階においては、LAG技術は、複数の低速度イーサネットインターフェイスを束ねて、1つのLAGとし、仮想的な高速度イーサネットインターフェイスを実装することを可能とする。しかしながら、LAG技術では、サービスデータは、サービスに基づいて、ハッシュアルゴリズムを使用することによって、LAGの中の各々のインターフェイスに割り当てられる。サービスベースの負荷平衡方法と同様に、LAGは、また、インターフェイス帯域幅割当が不均衡であり、且つ、利用率が低いという問題を有している。その速度が単一インターフェイスの速度より大きいサービスが存在する場合には、そのサービスは、依然として、ハッシュアルゴリズムを使用することによって、1つのインターフェイスのみに割り当てられる必要があり、結果として、そのインターフェイスは、輻輳してしまい、且つ、サービス伝送レートは、そのインターフェイスの速度によって制限される。
転送デバイスの場合には、サービスが低速度インターフェイスから高速度インターフェイスに転送されるときに、転送前に、サービス全体のパケットをバッファリングして、パケット破損を避ける必要がある。このバッファリングは、サービスデータ伝送遅延を大幅に増加させる。異なるレートの複数のインターフェイスの間の転送の効率を改善するために、光インターネットワーキングフォーラム(Optical Internetworking Forum, OIF)は、マルチリンクギアボックス(Multi Link Gearbox, MLG)技術をリリースして、高速度イーサネットインターフェイスの逆多重化を実行し、高速度イーサネットインターフェイスをいくつかの低速度イーサネットインターフェイスに分割している。しかしながら、MLG技術は、例えば、40Gイーサネットインターフェイスを4つの10Gイーサネットインターフェイス又は2つの20Gイーサネットインターフェイスに分割するといった、いくつかの固定のインターフェイス分割方式のみをサポートし、MLG技術がサポートするサブインターフェイスタイプは、制限されているため、柔軟性は十分に高くはない。
FlexE技術は、上記の要件のために開発されているフレキシブルイーサネットインターフェイス技術である。図1は、100GFlexEインターフェイスにおける符号ブロックストリームの概略的な図である。FlexE 1.0規格において定義されているように、Flexは、周期として20個の符号ブロック(block)を使用することによって、100Gイーサネットインターフェイスのサービスに対して時分割多重化を実行して、(20個の符号ブロックの周期の中の1つの符号ブロックに対応する)5Gの粒度で、100Gイーサネットインターフェイスを20個のタイムスロットに分割する。具体的には、図1に示されているように、1023×20個のデータ符号ブロックの間隔で、1つのFlexEオーバーヘッド(Overhead, OH)符号ブロックを挿入する。FlexEは、Sイーサネットインターフェイスを束ねて、1つのリンクアグリゲーショングループとしてもよく、そして、そのリンクアグリゲーショングループの20*S個のタイムスロットからランダムに選択したアイドルタイムスロットの中で、サービスデータを送信してもよい。
図2は、FlexEにおける受信端デバイスの機能的な構成の概略的なブロック図である。図2に示されているように、FlexE技術によれば、イーサネットインターフェイスの物理的符号化サブレイヤ(Physical Coding Sublayer,
PCS)の上に、新たな層、すなわち、フレキシブルイーサネットシム(FlexE Shim)層を挿入する。FlexEシム層は、上のほうで複数のフレキシブルイーサネットサービス(FlexE Client)を搬送し、下のほうで複数の100Gイーサネットインターフェイスに接続されている。FlexE 1.0規格は、FlexEクライアントが、64b/66b符号化の符号ブロックストリーム(block stream)であり、アイドル符号ブロック挿入/削除(Idle Insert/Delete)によってレート適応を実行した後に、フレキシブルイーサネットサービスの符号ブロックストリームの中の符号ブロックが、フレキシブルイーサネットサービスに割り当てられているタイムスロットに順次配置されるということを規定している。
図3は、FlexEにおいて、受信端デバイスによって符号ブロックストリームを送信する概略的な図である。図3に示されているように、FlexEにおいては、S個の物理接続リンクを含むリンクアグリゲーショングループの場合に、すなわち、S個の物理リンク(Physical, PHY)を含むフレキシブルイーサネットグループ(FlexE Group)の場合に、合計で20*S個のタイムスロットが存在する。フレキシブルイーサネットシム(FlexE Shim)層においては、20*S長タイムスロット割り当てテーブル(Calendar)を使用することによって、66b符号ブロックの位置を割り当てる。例えば、ある周期の中の最初の20個の符号ブロックは、PHY1を使用することによって送信され、その後の20個の符号ブロックは、PHY2を使用することによって送信され、符号ブロックがPHYSを使用することによって送信されるまで同様の手順が行われる。本明細書においては、各々のPHYにおける20個の符号ブロックは、タイムスロット割当てサブテーブル(Sub-calendar)と称されてもよい。ある1つの特定の例においては、10Gフレキシブルイーサネットサービスは、20*S個のタイムスロットのうちの2つを占有する。この場合には、1つの周期の中で、2つの符号ブロックが、10Gフレキシブルイーサネットサービスの符号ブロックストリームから抽出され、(1つの符号ブロックが、1つの5Gタイムスロットに対応している)対応する位置に配置される。他の特定の例においては、25Gフレキシブルイーサネットサービスは、5つのタイムスロットを占有し、各々の周期において、5つの符号ブロックが、25Gフレキシブルイーサネットサービスの符号ブロックストリームから抽出され、calendarの中の対応する位置に配置される。FlexE Groupの中の各々のタイムスロットの中でいずれのフレキシブルイーサネットサービスが送信されるかを示す構成情報は、FlexE OH符号ブロックの中のある特定のフィールドの中で指定される。
図4は、FlexEオーバーヘッド符号ブロックのフレームフォーマットの概略的な図である。図4に示されているように、32個の連続的なFlexEフレームは、1つのFlexEマルチフレームを構成し、1つのFlexE OHフレームは、8つの連続的なFlexE OH符号ブロックを含む。FlexEフレームの中の最初の符号ブロックについては、マークフィールドとして"0x4b"又は"0x5"フィールドを使用して、OH符号ブロックとしてその符号ブロックを識別する。OH符号ブロックを識別した後に、受信端デバイスは、1023×20個の64b/66b符号ブロック(データ符号ブロック)を受信した後の次のOH符号ブロックを受信することが可能である。類推することによってその残りを推定することが可能であり、符号ブロックストリームからFlexEフレーム全体を抽出することが可能である。
図4に示されているように、各々のリンクにおいて送信されるFlexE OHフレームは、フレキシブルイーサネットグループ番号(FlexE Group Number)、物理リンクマップ(PHY Map)、物理リンク番号(PHY Number)、タイムスロット割り当てテーブル(Calendar)A、及びcalendar B等のフィールドを含む。FlexE Group Numberは、リンクが属しているフレキシブルイーサネットグループの番号を示すのに使用される。(1つのFlexEマルチフレームの中の合計で8×32=256ビットを使用することによって示される必要がある)PHY Mapは、リンクが属しているフレキシブルイーサネットグループに含まれるPHYの分布を示すのに使用される。物理リンク番号は、1乃至254のうちの1つである。Calendar A及びCalendar Bは、それぞれ、FlexE Groupの現在のCalendar構成及び代替的なCalendar構成を示すのに使用される。各々のFlexEフレームの中の第3の符号ブロックにおいては、16ビットが、タイムスロットの中で送信されるサービスデータの番号を示すのに使用される。各々のFlexEマルチフレームの中の最初のFlexEフレームは、対応するタイムスロット0(slot 0)の中で送信されるサービスデータの番号を搬送し、FlexEマルチフレームの中の20番目のFlexEフレームが、対応するslot19の中で送信されるサービスデータの番号を搬送するまで、同様である。FlexE Groupの中の複数のリンクのすべてにおけるFlexEフレームに関する情報を受信した後に、受信端デバイスは、FlexE Groupの中のサービスデータの各々のタイムスロット割り当て方式を取得することが可能である。
FlexEにおいては、複数のクロスリンクタイムスロットの中で、サービスデータを送信してもよい。したがって、受信端デバイスは、複数のタイムスロットからフレキシブルイーサネットサービスを復元する前に、FlexE Groupの中の各々のリンクに対して差動遅延補償を実行する必要がある。そうしない場合には、フレキシブルイーサネットサービスが差動遅延を伴うクロスリンクタイムスロットから復元されるときに、符号ブロックの無秩序状態を引き起こす場合がある。FlexE 1.0規格は、FlexE Groupにおいて、各々のリンクにおいて送信されるFlexEフレームの中の最初のオーバーヘッド符号ブロックをマークとして使用し、そして、受信端デバイスのバッファ(Buffer)を使用することによって、複数のリンクのうちのすべての送信遅延を整列させるということを規定している。通常は、各々のリンクについての差動遅延補償(deskew)能力は、FlexE Groupのシムからシムまでの(shim-to-shim)直接的な接続の伝送シナリオにおいて少なくとも300[ns]であり、各々のリンクについての差動遅延補償能力は、FlexE Groupの長距離の転送ネットワーク間の伝送の際に少なくとも10[μs]である。
FlexE Groupの中の複数のクロスリンクタイムスロットにおいて、サービスデータを送信してもよい。したがって、受信端デバイスにおいて、複数のリンクにおけるFlexEフレームを整列させて、サービスデータが対応するタイムスロットから正しいシーケンスで復元されるということを保証する必要がある。FlexE 1.0規格によれば、基準として、FlexEフレーム境界を使用して、複数のリンクの間の差動遅延を計算し、そして、バッファを使用することによって、それらの複数のリンクにおける符号ブロックストリームを整列させる。上記のように、FlexE規格によって規定されているFlexE Groupの中の複数のリンクの間の差動遅延は、FlexE Groupのシムからシムまでの(shim-to-shim)直接的な接続の伝送シナリオにおいては、300[ns]以下である必要があり、複数のリンクの間の差動遅延は、長距離の転送ネットワーク間の伝送のシナリオにおいては、10[μs]以下となっている必要がある。FlexE Groupの中のリンクにおける差動遅延が、受信端デバイスの差動遅延補償能力を超える場合には、そのFlexE Group全体が機能しなくなる。
FlexO技術:
FlexOにおいては、(例えば、m×100G等の)複数の標準レートのポートを束ねて、フレキシブル光転送ネットワークグループ(FlexO Group)を構成し、それにより、標準光トランスポートユニットCn(Optical Transport Unit-Cn, OTUCn)(n≧1)信号を搬送する。このことは、帯域幅が100Gより大きいポートが定義されていない従前のプロトコルの欠陥を構成する。FlexEにおける信号と同様に、OTUCn信号は、複数のリンクにおいてクロスリンク方式によって送信され、したがって、複数のリンクのうちのすべてにおいて送信されるサービスデータを整列させて、送信されるOTUCn信号の復元を確実にする必要がある。現時点では、FlexOにおいて、複数のリンクを使用することによって送信されるOTUCnフレームの中のフレーム整列信号(Frame Alignment Signal, FAS)フィールドを使用することによって、FlexO Groupの中の複数のリンクのうちのすべてにおけるサービスデータを整列させるということが規定されている。FlexO Groupの中のリンクの差動遅延が、受信端デバイスの差動遅延補償能力を超える場合には、FlexO Group全体が機能しない。
リンク層発見プロトコル(Link Layer Discovery Protocol, LLDP)技術:
この出願の複数の実施形態は、さらに、LLDP技術に関する。LLDPは、規格802.1ABによって定義されているリンク層発見プロトコルである。LLDPを使用することによって、転送ネットワークデバイスは、標準的なLLDPタイプ長値(Type Length Value, TLV)ユニットを使用することによって、他の隣接する転送ネットワークデバイスに、局所的な情報を搬送するマルチキャストパケットを周期的に送信することが可能である。LLDPは、転送ネットワークデバイスの各々のポートに、標準的な簡易ネットワーク管理プロトコル(Simple Network Management Protocol, SNMP)管理情報ベース(Management Information Base)MIBを配置して、他の隣接する転送ネットワークデバイスの局所的な状態情報及び状態情報を格納するということを規定している。複数の転送ネットワークデバイスの間で、SNMP MIBの中に格納されている状態情報は、LLDP TLVユニットを送信し及び受信することによって更新される。LLDPの使用は、転送ネットワークデバイスの状態情報の管理及び保守が容易にする。
TLVユニットは、LLDPにおける基本情報ユニットである。複数の異なるタイプのTLVは、異なる情報を搬送することが可能である。LLDPは、標準化団体が自己定義することが可能であるTLVユニットを予約する。表1は、自己定義することが可能であるLLDPフォーマットTLVユニットの各々のフィールドの定義を示している。本明細書における表2乃至表7に示されているTLVユニットのすべては、表1に示されているTLVユニットの特定の適用の形態であるということを理解すべきである。
以下の記載は、図2乃至図5を参照して、この出願の複数の実施形態におけるリンクグループ構成方法が適用されるある1つのシナリオを説明している。図2に示されているように、FlexEは、MAC層とPHY層との間で動作する。FlexEにおいては、元の調整サブレイヤ(Reconciliation Sublayer, RS)及びPCSを修正して、従来のイーサネットポートを複数の時分割多重化(Time Division Multiplexing, TDM)チャネルに分割し、そして、複数のイーサネットポートを束ねる機能を実装する。LLDP及びLAG技術は、MAC層において動作する。FlexE 1.0規格は、FlexEイーサネット伝送及び転送ネットワーク間の伝送の複数の適用シナリオを定義する。図5は、FlexE転送ネットワーク間の伝送のある1つの適用シナリオの概略的な図である。FlexE転送ネットワーク間の伝送は、FlexE認知の転送(FlexE Aware Transport)モードに基づいている。図5において、イーサネットルータにおけるフレキシブルイーサネットシム(FlexE Shim)は、そのフレキシブルイーサネットシムに接続されているFlexE Groupの中の2つのリンクに対して差動遅延補償を実行する必要がある。FlexOは、PHY層において動作する。FlexEにおける場合と同様に、差動遅延補償は、また、複数のリンクに対して実行される必要がある。
FlexEの中のFlexE Groupが故障する場合がある状況及びFlexOの中のFlexO Groupが故障する場合がある状況に基づいて、この出願の複数の実施形態は、リンクグループ構成方法を提供する。この出願の複数の実施形態によれば、複数の転送ネットワークデバイスの間の補償交渉は、関連するFlexE又はFlexOに関連する複数の機能的な部分の再構築によって実装される。この出願の複数の実施形態にしたがって再構成を実行した後に、リンクグループの確立の間に、転送ネットワークデバイスは、リンクグループが受信端デバイスの差動遅延補償能力を超えるリンクを含むことを可能にする。この出願の複数の実施形態における転送ネットワークデバイスは、ソース端デバイス、中間デバイス、及び受信端デバイスを含んでもよいということを理解すべきである。
図6は、この出願のある1つの実施形態にしたがったリンクグループ構成方法100の概略的なフローチャートである。図6に示されているように、リンクグループ構成方法100は、以下のステップを含んでもよい。
S110: 第1のデバイスは、ソース端デバイスと受信端デバイスとの間のM個のリンクの第1の状態情報を取得し、第1の状態情報は、M個のリンクのうちのいずれか2つの間の差動遅延の状態を示すのに使用され、M個のリンクのうちのいずれか1つは、フレキシブルイーサネットFlexE物理接続リンク又はフレキシブル光転送ネットワークFlexO物理接続リンクであり、Mは、2以上の整数である。
S120: 第1のデバイスは、受信端デバイスの第1の能力情報を取得し、第1の能力情報は、受信端デバイスがM個のリンクに対して差動遅延補償を実行する第1の能力を示すのに使用される。
S130: 第1のデバイスは、第1の状態情報及び第1の能力情報に基づいて、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとし、Nは、M以下であり且つ2以上の整数である。
S140: 第1のデバイスは、第2のデバイスに第1の構成情報を送信し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。
第1のデバイスは、リンクグループ分割方式を決定する決定デバイスであり、第2のデバイスは、その決定デバイスと共働して、リンクグループの構成を完了する関連するデバイスを含むということを理解すべきである。
さらに、この出願の複数の実施形態において、差動遅延補償は、遅延受信補償である、すなわち、受信方向の補償であり、通常、"deskew"と称され、遅延送信補償は、送信方向の補償であり、また、通常、"remote deskew"と称されるということを理解すべきである。
この出願のこの実施形態におけるリンクグループ構成方法によれば、第1のデバイスは、ソース端デバイスと受信端デバイスとの間のM個のリンクの間の差動遅延の状態及び受信端デバイスがM個のリンクに対して差動遅延補償を実行する能力に基づいて、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとする。このことは、M個のリンクの間の差動遅延が受信端デバイスの差動遅延補償の能力を超えるときに、M個のリンクのうちのすべてが利用可能ではない場合を回避する。したがって、転送ネットワークの中のリンクの利用可能性及び頑健性を改善することが可能である。
FlexEにおいて、FlexE Groupの中の各々のリンクにおけるデータストリームは、1 OH block+1023×20 Data Blocksの64b/66b符号ブロックストリームの形態になっており、受信端デバイスは、マークとして、各々のリンクにおいて送信されるFlexEフレームの中の最初のOH block
の中にある0x4b及び0x5識別情報フィールドを使用して、複数のリンクのうちのすべてにおけるデータ符号ブロックを整列させる。
同様に、FlexOフレームは、128*5440ビットのデータストリームであり、8個のフレームは、1つのマルチフレームとなっている。受信端デバイスは、マークとして、各々のFlexOフレームの中で搬送されるOTUCnフレームの中のFASフィールドを使用して、複数のリンクのすべてにおけるデータ符号ブロックを整列させる。
2つのタイプの転送ネットワークの双方のために、この出願の複数の実施形態におけるリンクグループ構成プロセス及びその後の補償プロセスを使用してもよい。それらの複数の実施形態においては、説明のためのある1つの例としてFlexEを使用する。もちろん、この出願の複数の実施形態におけるリンクグループ構成方法は、代替的に、FlexOに適用されてもよく、又は、FlexE及びFlexO技術の双方を使用する転送ネットワークに適用されてもよい。
図7は、この出願のある1つの実施形態にしたがった複数のリンクの間の差動遅延の状態の概略的な図である。図7に示されているように、ソース端デバイスと受信端デバイスとの間には、PHY1乃至PHY5の合計で5つのリンクが存在している。FlexEフレームは、独立して、複数のリンクにおいて、ソース端デバイスと受信端デバイスとの間で送信される。図7における水平方向の軸は、各々のリンクにおけるFlexEフレームの到着の時間遅延を表し、影付きのボックスの幅は、受信端デバイスの差動遅延補償能力を表す。図7に示されている5つのリンクのうちで、PHY1とPHY 2との間の差動遅延は、比較的小さく、PHY3、PHY4、及びPHY5の間の差動遅延は、比較的小さい。しかしながら、受信端デバイスの差動遅延補償能力は、PHY1乃至PHY5に対する差動遅延補償を完了するには十分ではない。
以下の記載は、いくつかの実施形態を参照して、この出願のリンクグループ構成方法を詳細に説明する。
[実施形態1]
この実施形態においては、第1のデバイス、すなわち、決定デバイスは、受信端デバイスであり、第2のデバイスは、ソース端デバイスである。受信端デバイスは、遅延受信補償能力を有する。
この実施形態では、ステップS110において、第1のデバイスによって、ソース端デバイスと受信端デバイスとの間のM個のリンクの第1の状態情報を取得するステップは、第1のデバイスによって、M個のリンクの間の差動遅延を測定して、第1の状態情報を取得するステップを含んでもよい。具体的には、受信端デバイスは、いくつかの既存の解決方法を使用することによって、M個のリンクの間の差動遅延を測定して、第1の状態情報を取得してもよい。
具体的には、この出願の複数の実施形態によれば、複数のリンクのうちのすべての送信遅延を測定し、そして、それらの送信遅延を比較することによって、いずれか2つのリンクの間の差動遅延を取得することが可能である。代替的に、受信端デバイスにカウンタが追加され、最も速いリンクにおける標識符号ブロックを受信した後に、カウンタは、0から計数を開始し、他のリンクにおける標識符号ブロックを受信したときに、カウンタ値xを記録する。この場合には、それらの2つのリンクの間の伝送遅延差は、x個の符号ブロックに対応する伝送時間となる。M個のリンクの間の差動遅延を測定する具体的な方式は、この出願のそれらの複数の実施形態には限定されない。
図7に示されているある1つの特定の例においては、第1の状態情報は、PHY1とPHY 2との間の差動遅延が比較的小さく、PHY3、PHY4、及びPHY5との間の差動遅延が比較的小さく、一方で、受信端デバイスの差動遅延補償能力は、PHY1〜PHY5に対して差動遅延補償を完了するには十分ではない、であってもよい。
受信端デバイスの差動遅延補償能力によって制限されるため、受信端デバイスは、PHY1乃至PHYのうちのすべてに対する差動遅延補償をサポートすることは不可能である。クロスリンクサービスをサポートするメンバーリンクの数を最大化するために、ソース端デバイスと受信端デバイスとの間のM個のリンクのうちのすべてからN個のリンクを選択し、"selected"と印を付してもよい。その他のM−N個のリンクは、"standby"と印を付される。この実施形態においては、N=3である。具体的にいうと、PHY3、PHY4、PHY5は、"selected"と印を付され、その他の2つのリンクPHY1とPHY2は、"standby"と印を付される。"selected"と印を付されたPHY3、PHY4、及びPHY5は、第1のリンクグループを構成し、第1のリンクグループの3つのリンクは、クロスリンクサービスを搬送することが可能である。"standby"と印を付されたPHY1とPHY2は、独立して、完全なサービスを送信するのに使用されてもよい。代替的に、"standby"と印を付されたPHY1及びPHY2は、待機状態にあり、待機状態においては、いかなるサービスも送信されない。並列的なサービスの送信は、"standby"と印を付されたリンクにおいては実行されず、それぞれ、"standby"及び"selected"と印を付された2つのリンクにおいても実行されない。
代替的に、2つのリンクグループが確立されてもよい。図8は、この実施形態にしたがったリンクグループ構成結果の概略的な図である。リンクPHY3、PHY4、及びPHY5は、"selected1"、すなわち、第1のリンクグループとして印を付されて、クロスリンクサービスを搬送する。リンクPHY1及びPHY2は、"selected2"、すなわち、第2のリンクグループとして印を付されて、クロスリンクサービスを搬送する。"selected1"と印を付された第1のリンクグループ及び"selected2"と印を付された第2のリンクグループを使用することによって、クロスリンクグループサービス伝送を実行することはできない。
この出願のこの実施形態においては、上記の2つのリンクグループ構成の解決方法にのほかに、複数のリンクの間の差動遅延の状態及び受信端デバイスがリンクに対して差動遅延補償を実行する能力に基づいて、リンクグループを決定する、より多くの異なる構成解決方法が存在してもよい。このことは、この出願のこの実施形態においては限定されない。
上記の説明は、M=5であるある1つの例を使用することによって、この出願のこの実施形態におけるリンクグループ構成方法を説明することを意図しているにすぎないが、この出願のこの実施形態におけるリンクグループ構成方法を制限することを意図してはいないということを理解すべきである。
選択的に、この実施形態におけるリンクグループ構成方法は、第1のデバイスによって、第1のリンクグループに基づいて、第2のデバイスとのサービスデータの伝送を実行するステップと、第1のデバイスによって、第1の構成情報に基づいて、第1のリンクグループの中のリンクに対して差動遅延補償を実行するステップと、をさらに含んでもよい。
図9は、この実施形態のリンクグループ構成及び補償のプロセス200の概略的な図である。プロセス200は、以下のステップを含んでもよい。
S210: ソース端デバイスと受信端デバイスとの間のリンクを開始する。
S220: ソース端デバイスは、独立してM個のリンクを使用することによって、受信端デバイスに複数のデータフレームを個別に送信する。それに対応して、受信端デバイスは、ソース端デバイスが送信するそれらの複数のデータフレームを受信する。それらの複数のデータフレームは、整列マークを含んでいてもよいということを理解すべきである。
S230: 受信端デバイスは、M個のリンクの間の差動遅延の状態を測定して、第1の状態情報を取得する。
S240: 受信端デバイスは、受信端デバイスがM個のリンクに対して差動遅延補償を実行する能力を表すことが可能である第1の能力情報及び第1の状態情報に基づいて、リンクグループ構成を決定する、すなわち、第1の構成情報を決定する。具体的には、その構成は、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとすることを含む。
S250: 受信端デバイスは、M個のリンクに対して差動遅延補償を実行する。具体的には、受信端デバイスは、第1の構成情報に基づいて、差動遅延補償を実行する、すなわち、差動遅延バッファサイズを設定する。言い換えると、受信端デバイスは、受信端デバイスが決定したリンクグループ構成に基づいて、第1のリンクグループの中のリンクに対して差動遅延補償を実行する。S250及びS260は、同時に実施されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。
S260: 受信端デバイスは、ソース端デバイスに第1の構成情報を送信し、その第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の構成情報を受信する。第1の構成情報は、複数の形態であってもよく、以下の記載は、それらの形態を詳細に説明する。
選択的に、
S270: ソース端デバイスは、第1の構成情報に基づいて、受信端デバイスにサービスデータを送信する。
この出願の複数の実施形態において、第1の構成情報は、リンクが第1のリンクグループに属しているということを示すのに使用されるマークを含んでいてもよいということを理解すべきである。以下の実施形態においては、詳細は繰り返しては説明されない。
例えば、第1の構成情報は、(リンクが第1のリンクグループに属しているということを示すのに使用される)"selected"マーク及び上記で説明されている"standby"マークを含んでいてもよい。
他の例として、第1の構成情報は、上記で説明されている(リンクが第1のリンクグループに属しているということを示すのに使用される)"selected1"マーク及び(リンクが第2のリンクグループに属しているということを示すのに使用される)"selected2"マークを含んでいてもよい。具体的には、第1のデバイスは、N個のリンクのうちの第1のリンクを使用することによって、第2のデバイスに第1の構成情報を送信し、その第1の構成情報は、第1のリンクが第1のリンクグループに属しているということを示すのに使用される。言い換えると、リンクグループ識別子(例えば、"Subgroup ID"、"Subgroup"は、既存の"Group"と区別するために使用される)を使用することによって、リンクグループ構成情報を示してもよい。M個のリンクに"Subgroup ID"を追加するときに、同じ"Subgroup ID"で印を付されたリンクに対して、差動遅延補償操作を実行して、クロスリンクサービス伝送を実行してもよく、1つのリンクのみが、特定の"Subgroup ID"で印を付されている場合に、そのリンクにおいてのみ独立してサービスを送信することが可能である。
他の例として、第1の構成情報は、M個のリンクの各々が属するリンクグループを示すのに使用される情報を含んでいてもよい。第1のデバイスは、各々のリンクを使用することによって、第2のデバイスに、M個のリンクの各々が属しているリンクグループを示すのに使用される情報を送信する。
この出願の複数の実施形態では、S140において、第1のデバイスによって第2のデバイスに、第1の構成情報を送信するステップは、第1のデバイスによって、データ符号ブロックに第1の構成情報を追加するステップと、第2のデバイスにそのデータ符号ブロックを送信するステップと、を含むか、或いは、第1のデバイスによって、リンク層発見プロトコル(Link Layer Discovery Protocol, LLDP)フォーマット、ハイレベルデータリンク制御(High-Level Data Link Control, HDLC)フォーマット、又はポイントトゥポイントプロトコル(Point to Point Protocol, PPP)フォーマットのパケットに第1の構成情報を追加するステップと、オーバーヘッド符号ブロックの管理チャネルによって、第2のデバイスにそのパケットを送信するステップと、を含むか、或いは、第1のデバイスによって、オーバーヘッド符号ブロックの予約されているフィールドに第1の構成情報を追加するステップと、第2のデバイスに、その予約されているフィールドを送信するステップと、を含んでいてもよいということを理解すべきである。以下の実施形態においては、詳細は繰り返しては説明されない。
ある1つの特定の例においては、(例えば、各々のリンクにおいて、リンクが属しているリンクグループのマークを送信する)第1の構成情報は、OH符号ブロックの管理チャネルによってLLDPフォーマットのパケットを送信することによって伝送される。具体的には、第1の構成情報は、FlexE OH符号ブロックの中のシムからシムまでの管理チャネル(management channel)によって伝送されるLLDPフォーマットのタイプ長値(Type-Length-Value, TLV)ユニットの中で搬送されてもよい。
第1の構成情報を搬送するのに使用されるLLDPフォーマットのTLVユニットの各々のフィールドの選択的な定義は、表2に示されている。TLVユニットにおいては、
バイト1乃至2のうちの最初の7ビットは、TLVのタイプ(TLV type)である。LLDPの規定によれば、各々の団体が自己定義するTLVユニットのタイプ値は、127である。
バイト1乃至2のうちの最後の9ビットは、TLVユニットの合計の長さの中のバイトの数を示すのに使用されるTLV長(TLV length)である。
バイト3乃至5は、LLDPによって規定されている各々の団体の団体固有の識別子(Organizationally Unique Identifier, OUI)である。OIFに対応するOUIは、00-0F-40である。
バイト6は、各々の団体が自己定義するTLVユニットのサブタイプ(subtype)であり、0x??(16進数)であってもよく、例えば、0x01(16進数)又は00000001(2進数)であってもよい。
バイト7は、リンクが属しているリンクグループのマークである。
0x00は、リンクの差動遅延が受信端デバイスの差動遅延補償能力を超えているということを示してもよい、すなわち、"standby"を示してもよい。
0x01乃至0xFFは、リンクの差動遅延が受信端デバイスの差動遅延補償能力の範囲内にあるということを示してもよい、すなわち、"selected"を示してもよい。ある特定の対応する値は、そのリンクが属しているリンクグループの番号を示してもよい。
表2に示されているとともに第1の構成情報を搬送するのに使用されるLLDPフォーマットのTLVユニットの各々のフィールドの定義は、ある1つの例であるにすぎず、それに対応して、要件に応じて変更することが可能であるということを理解すべきである。このことは、この出願の実施形態においては限定されない。
OH符号ブロックの管理チャンネルによってTLVユニットを受信した後に、ソース端デバイスは、"リンクが属しているリンクグループのマーク"の指標に基づいて、リンクグループ構成を完了してもよく、そして、サービスデータを送信してもよい。
他の特定の例において、(例えば、各々のリンクにおいて、リンクが属しているリンクグループのマークを送信する)第1の構成情報は、OH符号ブロックの予約されているフィールドを使用することによって伝送される。第1の構成情報のビットの第1の部分は、第1のリンク及び他のリンクが第1のリンクグループを構成するということを示すのに使用され、第1の構成情報の中のビットの第2の部分は、第1のリンクグループのマークである。図10は、この実施形態にしたがった予約されているフィールドのフォーマットの概略的な図である。具体的には、OH符号ブロックの予約されているフィールドから11ビットを選択して、第1の構成情報を搬送してもよい。最初の3ビットは、"selected"又は"standby"マークを含んでもよく、次の8ビットは、"selected"の状態にある"リンクが属しているリンクグループのマーク"を搬送するのに使用されてもよい。3ビットを含むビットの第1の部分及び8ビットを含むビットの第2の部分は、ある1つの例であるにすぎないということを理解すべきである。ビットの第1の部分及びビットの第2の部分は、より多くのビットを含んでいてもよく、又は、より少ないビットを含んでいてもよい。このことは、この出願のこの実施形態においては限定されない。
OH符号ブロックは、複数ビットからなる予約されているフィールドを含むということを理解すべきである。図10に示されているとともに第1の構成情報を搬送するのに使用される予約されているフィールドの位置は、ある1つの例であるにすぎず、この出願の複数の実施形態を限定することを意図してはいない。
FlexOの場合には、各々のリンクに対応する構成情報は、送信のためのOTUCnフレームのOH符号ブロックの管理チャネルに配置されていてもよく、一般通信チャネル(General Communication Channel, GCC)の0バイトに配置されてもよく、汎用フレーム化手順(Generic Framing Procedure, GFP)フォーマット、HDLCフォーマット、又は、PPPフォーマットで送信されてもよく、又は、自己定義されたフレームフォーマットで予約されている(Reserved, RES)フィールドを使用してもよく、或いは、例えば、光ペイロードユニット(Optical Payload Unit-Cn OPUCn)のペイロードの中といったように、OTUCnフレームペイロードの中に配置されてもよく、GFPフォーマットで又は他の自己定義されたフレームフォーマットで送信されてもよい。
この実施形態においては、受信端デバイスは、遅延受信補償能力を有し、受信端デバイスは、決定デバイスとして動作し、リンクグループ構成を決定する。このように、実行は、容易かつ単純であり、リンクグループ構成の間のシグナリングオーバーヘッドは小さい。
[実施形態2]
この実施形態においては、第1のデバイス、すなわち、決定デバイスは、ソース端デバイスであり、第2のデバイスは、受信端デバイスである。受信端デバイスは、遅延受信補償能力を有する。
この実施形態では、S110において、第1のデバイスによって、ソース端デバイスと受信端デバイスとの間のM個のリンクの第1の状態情報を取得するステップは、受信端デバイスが送信する第1の状態情報を第1のデバイスによって受信するステップを含んでいてもよい。S120において、第1のデバイスによって、受信端デバイスの第1の能力情報を取得するステップは、受信端デバイスが送信する第1の能力情報を第1のデバイスによって受信するステップを含んでいてもよい。
図11は、この実施形態にしたがったリンクグループ構成及び補償のプロセス300の概略的な図である。プロセス300は、以下のステップを含んでいてもよい。
S305: ソース端デバイスと受信端デバイスとの間のリンクを開始する。
S310: ソース端デバイスは、独立してM個のリンクを使用することによって、受信端デバイスに複数のデータフレームを個別に送信する。それに対応して、受信端デバイスは、ソース端デバイスが送信するそれらの複数のデータフレームを受信する。それらの複数のデータフレームは、整列マークを含んでいてもよいということを理解すべきである。
S315: 受信端デバイスは、M個のリンクの間の差動遅延の状態を測定する。
S320: 受信端デバイスは、ソース端デバイスに第1の状態情報を送信し、第1の状態情報は、M個のリンクの間の差動遅延の状態を示すのに使用される。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の状態情報を受信する。
S325: 受信端デバイスは、ソース端デバイスに第1の能力情報を送信し、第1の能力情報は、受信端デバイスがM個のリンクに対して差動遅延補償を実行する第1の能力を示すのに使用される。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の能力情報を受信する。
S330: ソース端デバイスは、第1の状態情報及び第1の能力情報に基づいて、リンクグループ構成を決定する。具体的には、その構成は、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとすることを含む。
S335: ソース端デバイスは、受信端デバイスに第1の構成情報を送信し、その第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、受信端デバイスは、ソース端デバイスが送信する第1の構成情報を受信する。
S340: 受信端デバイスは、M個のリンクに対して差動遅延補償を実行する。具体的には、受信端デバイスは、第1の構成情報に基づいて、差動遅延補償を実行する、すなわち、差動遅延バッファサイズを設定する。言い換えると、受信端デバイスは、ソース端デバイスが決定したリンクグループ構成に基づいて、第1のリンクグループの中のリンクに対して差動遅延補償を実行する。
S345: 受信端デバイスは、第1の構成情報を受信しているとともに、対応するリンクグループ構成を実行したということを示すために、ソース端デバイスに肯定応答情報を返送する。それに対応して、ソース端デバイスは、受信端デバイスが返送した肯定応答情報を受信する。S345は、選択的なステップであるということを理解すべきである。さらに、受信端デバイスは、さらに、ソース端デバイスに、複数のリンクの間の差動遅延の更新された状態を送信してもよい。
S350: ソース端デバイスは、第1の構成情報に基づいて、受信端デバイスにサービスデータを送信する。
第1の構成情報を送信する方式は、実施形態1において第1の構成情報を送信する方式と同様であってもよい。本明細書においては、詳細は繰り返しては説明されない。
選択的に、S335において、第1の構成情報は、受信端デバイスが実行する差動遅延補償のための各々のリンクのバッファ要件をさらに含んでいてもよい。受信端デバイスは、そのバッファ要件に基づいて、各々のリンクのバッファ量を直接的に設定してもよい。
選択的に、S330において、ソース端デバイスは、さらに、例えば、サービス量及び/又は帯域幅等の包括的な要因等の受信端デバイスに送信されるサービスデータの関連する情報を参照して、リンクグループ構成の解決方法を決定してもよい。
S345においては、受信端デバイスが返送する肯定応答情報は、LLDPフォーマットのパケットの形式で送信されてもよく、OH符号ブロックの中の予約されているフィールドを使用することによって送信されてもよいということを理解すべきである。例えば、肯定応答情報を送信するのに、実施形態1における第1の構成情報を搬送するOHの予約されているフィールドの後の2ビットの予約されているフィールドを使用してもよい。例えば、"00"は、受信端デバイスが、第1の構成情報を受信し、そして、各々のリンクのバッファ量の設定に成功しているということを示し、"01"は、各々のリンクのバッファ量の設定に成功していないということを示す。ソース端デバイスは、肯定応答情報"00"を受信した後にサービスデータを送信してもよい。"01"メッセージを受信した場合には、ソース端デバイスは、S330に戻り、リンクグループ構成の解決方法を再決定する。
S325においては、第1の能力情報は、データ符号ブロックを使用することによって送信されてもよく、LLDPフォーマット、HDLCフォーマット、又はPPPフォーマットのパケットを使用することによって、オーバーヘッド符号ブロックの管理チャネルによって送信されてもよく、又は、オーバーヘッド符号ブロックの中の予約されているフィールドを使用することによって送信されてもよい。このことは、この実施形態においては限定されない。
ある特定の例においては、第1の能力情報は、オーバーヘッド符号ブロックの管理チャネルのLLDPフォーマットTLVユニットの中で搬送されてもよい。第1の能力情報を搬送するのに使用されるLLDPフォーマットTLVユニットの各々のフィールドの定義は、表3に示されている。
表3の中のバイト1乃至6のフィールドの定義は、表2の中のバイト1乃至6のフィールドの定義と同じである。
バイト7は、そのリンクに対して差動遅延補償を実行する能力を定義する。バイト7の中の最初のビットは、受信方向においてそのリンクに対して差動遅延補償を実行する能力を表してもよい。その最初のビットの値が"0"であるときは、その値は、受信方向におけるバッファサイズが、例えば、FlexE 1.0において定義されている300[ns]の遅延補償能力に対応する469個の符号ブロック等のディフォルトの値であるということを示す。その最初のビットの値が"1"であるときは、その値は、受信方向におけるバッファサイズが、そのリンクによって自己定義されている値であるということを示し、特定の値は、バイト8乃至10において記述される。バイト7における他のビットは、予約されているフィールドであってもよい。
バイト8乃至10は、受信方向におけるリンクのバッファサイズを定義する。バイト7の最初のビットが"1"である(受信方向におけるバッファサイズが、自己定義された値である)場合には、バイト8乃至10の値xは、受信方向におけるバッファサイズが、x個の符号ブロックであるということを示し、xの値の範囲は、[1〜0xFFFFFE]である。バイト7の最初のビットが"0"である場合には、受信方向におけるバッファサイズは、ディフォルトの値となり、バイト8乃至10の値は、"0xFFFFFF"に設定されてもよい。
TLVユニットの中のバイト8乃至10が定義する受信方向における(例えば、local deskew buffer size等の)バッファサイズは、選択的なパラメータであるということを理解すべきである。受信方向におけるリンクのバッファサイズがディフォルトのサイズであるときは、受信方向におけるバッファサイズに関する情報を転送する必要はなく、受信方向におけるバッファサイズのパラメータを"0xFFFFFF"に設定してもよい。
本明細書においてある1つの例として説明している受信方向におけるバッファサイズは、単位として符号ブロック(block)を使用する。同様に、ns、10ns、又はバイト等の複数の異なる記述方式によって、或いは、複数の異なるサイズの基本バッファ単位によって、受信方向におけるバッファサイズを表してもよい。このことは、この出願の複数の実施形態においては限定されない。
FlexE認知の転送の伝送モード、すなわち、転送ネットワーク間の伝送シナリオにおいて、受信端デバイスは、TLVユニットを使用することによって、ソース端デバイスに第1の能力を通知し、そして、OH符号ブロックのシムからシムまでの管理チャネル(shim-to-shim management channel)によって伝送を実行する。他のシナリオにおいては、TLVユニットは、セクション管理チャネル(section management channel)によって伝送されてもよく、又は、シムからシムまでの管理チャネルによって伝送されてもよい。
ある1つの特定の例においては、第1の状態情報は、オーバーヘッド符号ブロックの管理チャネルのLLDPフォーマットTLVユニットの中で搬送されてもよい。第1の状態情報を搬送するのに使用されるLLDPフォーマットTLVユニットの各々のフィールドの定義は、表4に示されている。
表4の中のバイト1乃至6のフィールドの定義は、表2の中のバイト1乃至6のフィールドの定義と同じである。
バイト7は、そのリンクに対して実行される差動遅延補償の結果を定義する(例えば、その結果は、"FlexE group PHY deskew status"であってもよい)。バイト7の最初のビットは、受信方向においてリンクに対して実行される現在の差動遅延補償の結果を表す。"0"は、 受信端デバイスが、第1の構成情報に基づいてM個のリンクの各々に対して差動遅延補償を実行し、そして、差動遅延補償が成功しているということを示す。"1"は、受信端デバイスが、差動遅延補償を実行しないか、又は、差動遅延補償が失敗しているということを示す。バイト7の中の他のビットは、予約されているフィールドであってもよい。
バイト8乃至10は、リンクの差動遅延の遅延量を定義する。差動遅延の(例えば、"FlexE group PHY skew"等の)遅延量パラメータは、受信端デバイスが各々のリンクにおいてデータフレームを受信するときに、M個のリンクうちで伝送が最も速いリンクと比較したリンクの遅延量を表す。この場合には、例えば、リンクの"FlexE group PHY skew"が0であるときは、その値は、そのリンクが、M個のリンクうちで伝送が最も速いリンクであるということを示す。パラメータの値xは、伝送時間を表し、その伝送時間は、差動遅延の遅延量がx個の符号ブロックのデータである場合に対応する。
FlexE認知の転送の伝送モード、すなわち、転送ネットワーク間の伝送のシナリオにおいて、受信端デバイスは、TLVユニットを使用することによって、受信端デバイスの差動遅延状態をソース端デバイスに通知し、OH符号ブロックのシムからシムまでの管理チャネル(shim-to-shim management channel)によって伝送を実行する。他のシナリオにおいては、TLVユニットは、セクション管理チャネル(section management channel)によって伝送されてもよく、又は、シムからシムまでの管理チャネルによって送信されてもよい。
ソース端デバイスは、上記の2つのTLVユニットを使用することによって、受信端デバイスの第1の能力情報及びそれらの複数のリンクの第1の状態情報を取得した後に、リンクグループ構成を決定し、そして、実施形態1の方式と同様の方式によって、受信端デバイスに第1の構成情報を送信する。その受信端デバイスは、第1の構成情報に基づいて、それらの複数のリンクに対して差動遅延補償を実行する。本明細書においては、詳細は繰り返しては説明されない。
この実施形態においては、受信端デバイスは、遅延受信補償能力を有し、ソース端デバイスは、決定デバイスとして動作し、例えば、サービス量及び/又は帯域幅等の包括的な要因等のサービスデータの関連情報を参照して、リンクグループ構成を決定してもよい。
[実施形態3]
この実施形態においては、第1のデバイス、すなわち、決定デバイスは、管理デバイスであり、第2のデバイスは、受信端デバイス及び/又はソース端デバイスを含む。受信端デバイスは、遅延受信補償能力を有する。
この実施形態においては、S110において、第1のデバイスによって、ソース端デバイスと受信端デバイスとの間のM個のリンクの第1の状態情報を取得するステップは、受信端デバイスが送信する第1の状態情報を第1のデバイスによって受信するステップを含んでいてもよい。S120において、第1のデバイスによって、受信端デバイスの第1の能力情報を取得するステップは、受信端デバイスが送信する第1の能力情報を第1のデバイスによって受信するステップを含んでいてもよい。
管理デバイスによってリンクグループ構成を決定するプロセスは、以下のステップを含んでもよい。
A-1: ソース端デバイスと受信端デバイスとの間のリンクを開始する。
A-2: ソース端デバイスは、独立してM個のリンクを使用することによって、受信端デバイスに複数のデータフレームを個別に送信する。それに対応して、受信端デバイスは、ソース端デバイスが送信するそれらの複数のデータフレームを受信する。それらの複数のデータフレームは、整列マークを含んでいてもよいということを理解すべきである。
A-3: 受信端デバイスは、M個のリンクの間の差動遅延の状態を測定する。
A-4: 受信端デバイスは、管理デバイスに第1の状態情報を送信し、第1の状態情報は、M個のリンクの間の差動遅延の状態を示すのに使用される。それに対応して、管理デバイスは、受信端デバイスが送信する第1の状態情報を受信する。
A-5: 受信端デバイスは、管理デバイスに第1の能力情報を送信し、第1の能力情報は、受信端デバイスがM個のリンクに対して差動遅延補償を実行する第1の能力を示すのに使用される。それに対応して、管理デバイスは、受信端デバイスが送信する第1の能力情報を受信する。
A-6: 管理デバイスは、第1の状態情報及び第1の能力情報に基づいて、リンクグループ構成を決定する。具体的には、その構成は、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとすることを含む。
A-7: 管理デバイスは、ソース端デバイス及び受信端デバイスに第1の構成情報を送信し、その第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、ソース端デバイス及び受信端デバイスは、管理デバイスが送信する第1の構成情報を受信する。
A-8: ソース端デバイス及び/又は受信端デバイスは、第1の構成情報を受信しているとともに、対応するリンクグループ構成を実行したということを示すために、管理デバイスに肯定応答情報を返送してもよい。それに対応して、管理デバイスは、ソース端デバイス及び/又は受信端デバイスが返送した肯定応答情報を受信する。A-8は、選択的なステップであるということを理解すべきである。
A-9: 管理デバイスは、肯定応答情報を受信した後に、ソース端デバイスに、リンクグループ構成が完了したということを示す指標を配信する。A-9は、選択的なステップであるということを理解すべきである。
A-10: ソース端デバイスは、第1の構成情報に基づいて、受信端デバイスにサービスデータを送信する。
A-11: 受信端デバイスは、第1の構成情報に基づいて、第1のリンクグループのうちのサービスデータに対応するリンクに対して差動遅延補償を実行する。
A-12: 受信端デバイスは、バッファ要件に基づいて、各々のリンクのバッファ量を直接的に設定し、管理デバイスが受信端デバイスに送信する第1の構成情報は、受信端デバイスが実行する差動遅延補償のための各々のリンクのバッファ要件をさらに含んでもよい。A-12は、選択的なステップであるということを理解すべきである。
ソース端デバイス及び受信端デバイスと管理デバイスのOH符号ブロックの管理チャネルによって、ソース端デバイス、受信端デバイス、及び管理デバイスの間で、第1の状態情報、第1の能力情報、及び第1の構成情報についての通信を実行してもよいということを理解すべきである。選択的に、FlexOの場合には、GFPフォーマット、HDLCフォーマット、又はPPPフォーマットのOH符号ブロックのGCC0バイトを使用することによって、或いは、自己定義されたフレームフォーマットのRESフィールドを使用することによって、上記の情報を伝送してもよい。FlexEの場合には、OH符号ブロックの管理チャネルによって、インターネットプロトコル(Internet Protocol, IP)パケットの形態で、上記の情報を伝送してもよい。具体的な伝送方式は、この実施形態においては限定されない。
この実施形態においては、管理デバイスは、決定デバイスとして動作する。このようにして、管理デバイスは、ソース端デバイス及び受信端デバイスの関連する情報を受信することが可能であり、そして、サービス量及び/又は帯域幅等の複数の包括的な要因を考慮して、リンクグループ構成を決定することが可能である。加えて、このことは、ソース端デバイス又は受信端デバイスの意思決定に起因するであろう計算量を回避することを可能とし、ソース端デバイス及び受信端デバイスの負荷を低減することを可能とする。
リンクは、さらに、例えば、図5に示されているFlexE転送ネットワーク間の伝送の適用シナリオ、すなわち、FlexE認知の転送モードに基づいた伝送シナリオ等の実際のシナリオにおいて、ソース端デバイスから受信端デバイスへの経路において複数の中間デバイスを通過する場合があるということを理解すべきである。差動遅延補償を実行することが可能である受信端デバイスのほかに、中間デバイスの各々の送信ポートは、データ送信を遅延させる能力、すなわち、遅延送信補償能力をサポートしてもよい。したがって、受信端デバイス及び中間デバイスは、交渉を実行して、協調的な補償を実装する必要がある。
この出願の複数の実施形態のうちのいくつかにおいて、M個のリンクにおける受信端デバイスのK個のアップストリームデバイスは、遅延送信補償能力を有してもよく、Kは、正の整数である。K個のアップストリームデバイスは、ソース端デバイス及び/又は少なくとも1つの中間デバイスを含んでもよく、中間デバイスは、M個のリンクのソース端デバイスと受信端デバイスとの間に位置している。
受信端デバイスのK個のアップストリームデバイスが遅延送信補償能力を有しているときに、方法100は、第1のデバイスによって、K個のアップストリームデバイスの各々の第2の能力情報及び第2の状態情報を取得するステップをさらに含んでもよく、第2の能力情報は、各々のアップストリームデバイスがM個のリンクのうちの少なくとも1つに対して遅延送信補償を実行する第2の能力を示すのに使用され、第2の状態情報は、各々のアップストリームデバイスがM個のリンクのうちの少なくとも1つに対して実行する遅延送信補償の現在の状態を示すのに使用され、S130において、第1のデバイスによって、第1の状態情報及び第1の能力情報に基づいて、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとするステップは、第1のデバイスによって、第1の状態情報、第1の能力情報、第2の状態情報、及び第2の能力情報に基づいて、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとするステップを含んでもよく、方法100は、第1のデバイスによって、第1の状態情報、第1の能力情報、第2の状態情報、及び第2の能力情報に基づいて、各々のアップストリームデバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を決定するステップをさらに含んでもよい。
M個のリンクのうちのすべてが、すべてのアップストリームデバイスを通過するわけではないということに留意すべきである。K個のアップストリームデバイスのいずれか1つについて、M個のリンクのうちの一部(少なくとも1つ)のみが、アップストリームデバイスを通過することも可能である。
以下の記載は、複数の実施形態のうちのいくつかを参照して、受信端デバイスのK個のアップストリームデバイスが遅延送信補償能力を有しているときの、この出願の複数の実施形態におけるリンクグループ構成方法を説明する。
実施形態4、実施形態5、及び実施形態6において、第1のデバイス、すなわち、決定デバイスは、受信端デバイスであり、第2のデバイスは、ソース端デバイスである。受信端デバイスは、遅延受信補償能力を有している。K個のアップストリームデバイスは、ソース端デバイス及び/又は少なくとも1つの中間デバイスを含んでいてもよく、遅延送信補償能力を有していてもよい。
S110において、第1のデバイスによって、ソース端デバイスと受信端デバイスとの間のM個のリンクの第1の状態情報を取得するステップは、第1のデバイスによって、M個のリンクの間の差動遅延を測定して、第1の状態情報を取得するステップを含んでもよく、第1のデバイスによって、K個のアップストリームデバイスの各々の第2の能力情報及び第2の状態情報を取得するステップは、各々のアップストリームデバイスが送信する第2の能力情報及び第2の状態情報を第1のデバイスによって受信するステップを含んでもよく、方法100は、第1のデバイスによってK個のアップストリームデバイスのうちの少なくとも1つに、第2の構成情報を送信するステップをさらに含んでもよく、第2の構成情報は、少なくとも1つのアップストリームデバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される。
少なくとも1つのアップストリームデバイスが遅延送信補償の構成を完了した後に、方法100は、第1のデバイスによって、第1のリンクグループに基づいて、第2のデバイスとのサービスデータの伝送を実行するステップと、第1のデバイスによって、第1のリンクグループのうちで、少なくとも1つのアップストリームデバイスが第2の構成情報に基づいて遅延送信補償を実行しているリンクに対して、第1の構成情報に基づいて差動遅延補償を実行するステップと、をさらに含んでもよい。
受信端デバイスにおいてM個のリンクを整列させることが不可能であるときに、それらのM個のリンクは、リンクグループを構成することができない、具体的にいうと、FlexEグループ又はFlexOグループは、機能停止し、そして、動作することができない。この出願の複数の実施形態におけるソース端デバイス、受信端デバイス、及び中間デバイス等は、すべてが、差動遅延補償能力又は遅延送信補償能力を有してもよい。この出願の複数の実施形態におけるデバイスは、能力交渉によってリンクグループ補償を実装する。ソース端デバイスと受信端デバイスとの間のFlexEグループ又はFlexOグループの中の各々のデバイスの補償能力が、複数のリンクの間の差動遅延を補償するのに十分ではないときに、リンクグループを構成し、それによって、ソース端デバイスは、遅延整列リンクに対してのみクロスリンクサービスデータ伝送を実行する。代替的に、デバイスは、協調的な補償を実行し、それによって、最終的に受信端デバイスにおいてM個のリンクを整列させることが可能となる。このことは、FlexEグループ又はFlexOグループの動作を保証することを可能とし、リンクの利用を改善することが可能である。
[実施形態4]
この実施形態においては、第1のデバイス、すなわち、決定デバイスは、受信端デバイスであり、第2のデバイスは、ソース端デバイスである。受信端デバイスは、遅延受信補償能力を有する。受信端デバイスとソース端デバイスとの間には、遅延送信補償能力を有する中間デバイスが存在する。言い換えると、K個のアップストリームデバイスは、少なくとも1つの中間デバイスである。
受信端デバイス及び中間デバイスによる協調的な補償のプロセスは、以下のステップを含んでもよい。
B-1: ソース端デバイスと受信端デバイスとの間のリンクを開始する。
B-2: ソース端デバイスは、独立してM個のリンクを使用することによって、受信端デバイスに複数のデータフレームを個別に送信する。それに対応して、受信端デバイスは、ソース端デバイスが送信するそれらの複数のデータフレームを受信する。それらの複数のデータフレームは、整列マークを含んでいてもよいということを理解すべきである。
B-3: 受信端デバイスは、M個のリンクの間の差動遅延の状態を測定して、第1の状態情報を取得する。
B-4: 中間デバイスは、受信端デバイスに第2の能力情報を送信し、第2の能力情報は、各々の中間デバイスがM個のリンクのうちの少なくとも1つに対して遅延送信補償を実行する第2の能力を示すのに使用される。それに対応して、受信端デバイスは、中間デバイスが送信する第2の能力情報を受信する。第2の能力情報は、B-2におけるデータフレームの中で搬送されてもよく、又は、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。
B-5: 中間デバイスは、受信端デバイスに第2の状態情報を送信し、第2の状態情報は、各々の中間デバイスがM個のリンクのうちの少なくとも1つに対して実行する遅延送信補償の現在の状態を示すのに使用される。それに対応して、受信端デバイスは、中間デバイスが送信する第2の状態情報を受信する。第2の状態情報は、B-2におけるデータフレームの中で搬送されてもよく、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。
B-6: 受信端デバイスは、第1の状態情報、受信端デバイスがM個のリンクに対して差動遅延補償を実行する能力を表すことが可能である第1の能力情報、第2の能力情報、及び第2の状態情報に基づいて、リンクグループ構成及び遅延送信補償構成を決定する。具体的なリンクグループ構成は、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとすることを含む。
B-7: 受信端デバイスは、中間デバイスに第1の構成情報を送信し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、中間デバイスは、受信端デバイスが送信する第1の構成情報を受信する。B-7は、選択的なステップであり、B-7は、協調的な補償プロセスの代わりに、他のプロセスのために実行されてもよいということを理解すべきである。
B-8: 受信端デバイスは、中間デバイスに第2の構成情報を送信し、第2の構成情報は、中間デバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される情報を含む。それに対応して、中間デバイスは、受信端デバイスが送信する第2の構成情報を受信する。
B-9: 中間デバイスは、第2の構成情報に基づいて、リンクの送信遅延を調整する。
B-10: 中間デバイスは、受信端デバイスに、遅延送信補償の更新された現在の状態に関する情報を送信する。このように、次の協調的な補償のための準備を行うことが可能であり、遅延送信補償の構成が完了しているということを受信端デバイスに通知する。
B-11: 受信端デバイスは、中間デバイスが送信する情報を受信した後に、ソース端デバイスに第1の構成情報を送信し、その第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の構成情報を受信する。加えて、選択的に、第1の構成情報は、差動遅延補償の関連する構成を完了しているということを示すのに使用される情報をさらに含んでいてもよい。
B-12: 受信端デバイスは、M個のリンクに対して差動遅延補償を実行する。具体的には、受信端デバイスは、第1の構成情報に基づいて、差動遅延補償を実行する、すなわち、差動遅延バッファサイズを設定する。言い換えると、受信端デバイスは、受信端デバイスが決定したリンクグループ構成に基づいて、第1のリンクグループの中のリンクに対して差動遅延補償を実行する。
B-13: ソース端デバイスは、第1の構成情報に基づいて、受信端デバイスにサービスデータを送信する。
ソース端デバイス、中間デバイス、及び受信端デバイスの間での第1の状態情報、第1の能力情報、第1の構成情報、第2の状態情報、第2の能力情報、第2の構成情報、及び他の関連する情報についての通信は、データ符号ブロックを使用することによって実行されてもよく、LLDPフォーマット、HDLCフォーマット、又はPPPフォーマットのパケットを使用することによって、オーバーヘッド符号ブロックの管理チャネルによって実行されてもよく、又は、オーバーヘッド符号ブロックの中の予約されているフィールドを使用することによって実行されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。
第1の構成情報を送信する方式は、実施形態1における第1の構成情報を送信する方式と同様である。本明細書においては、詳細は繰り返しては説明されない。
この出願のこの実施形態及び他の実施形態においては、例えば、第1の能力情報及び第2の能力情報等のデバイスの能力情報を報告又は送信するために、そのような能力情報は、オーバーヘッド符号ブロックの管理チャネルのLLDPフォーマットTLVユニットの中で搬送されてもよい。能力情報を搬送するのに使用されるLLDPフォーマットTLVユニットの各々のフィールドの定義は、表5に示されている。
表5の中のバイト1乃至6のフィールドの定義は、表2の中のバイト1乃至6のフィールドの定義と同じである。
バイト7は、そのリンクに対して補償を実行する能力を定義する。バイト7の中の最初のビットは、受信方向においてそのリンクに対して差動遅延補償を実行する能力を表してもよい。その最初のビットの値が"0"であるときは、その値は、受信方向におけるバッファサイズが、例えば、FlexE 1.0において定義されている300[ns]の差動遅延補償能力に対応する469個の符号ブロック等のディフォルトの値であるということを示す。その最初のビットの値が"1"であるときは、その値は、受信方向におけるバッファサイズが、そのリンクによって自己定義されている値であるということを示し、具体的な値は、バイト8乃至10において記述される。バイト7における第2のビットは、受信方向においてリンクに対して遅延送信補償を実行する能力を表していてもよい。第2のビットの値が"0"であるときは、その値は、遅延送信補償能力がサポートされていないディフォルトのモードを示す。第2のビットの値が"1"であるときは、その値は、遅延送信補償能力がサポートされているということを示し、遅延送信バッファサイズの具体的な値は、バイト11乃至13の中で記述されている。バイト7における他のビットは、予約されているフィールドであってもよい。
バイト8乃至10は、受信方向におけるリンクのバッファサイズを定義する。バイト7の最初のビットが"1"である(受信方向におけるバッファサイズが、自己定義された値である)場合には、バイト8乃至10の値xは、受信方向におけるバッファサイズが、x個の符号ブロックであるということを示し、xの値の範囲は、[1〜0xFFFFFE]である。バイト7の最初のビットが"0"である場合には、受信方向におけるバッファサイズは、ディフォルトの値となり、バイト8乃至10の値は、"0xFFFFFF"に設定されてもよい。
バイト11乃至13は、送信方向におけるリンクのバッファサイズを定義する。バイト7の最初のビットが"1"である(遅延送信補償能力が、送信方向においてサポートされている)場合には、バイト8乃至10の値xは、送信方向におけるバッファサイズがx個の符号ブロックであるということを示し、xの値の範囲は、[1〜0xFFFFFE]である。バイト7の最初のビットが"0"である場合には、その値は、遅延送信補償能力が、送信方向においてサポートされていないということを示し、バイト8乃至10の値は、"0xFFFFFF"に設定されてもよい。
本明細書においてある1つの例として説明しているバッファサイズは、単位として符号ブロック(block)を使用する。同様に、ns、10ns、又はバイト等の複数の異なる記述方式によって、或いは、複数の異なるサイズの基本バッファ単位によって、バッファサイズを表してもよい。このことは、この出願の複数の実施形態においては限定されない。
FlexE認知の転送の伝送モード、すなわち、転送ネットワーク間の伝送シナリオにおいて、デバイスは、TLVユニットを使用することによって、それらの能力を互いに通知し、そして、OH符号ブロックのシムからシムまでの管理チャネル(shim-to-shim management channel)によって伝送を実行する。他のシナリオにおいては、TLVユニットは、セクション管理チャネル(section management channel)によって伝送されてもよく、又は、シムからシムまでの管理チャネルによって伝送されてもよい。
この出願の複数の実施形態のうちのすべてにおいて、表5に示されているTLVユニットを使用することによって、能力情報を搬送してもよいということに留意すべきである。リンクは、通常、双方向である。したがって、デバイスは、ある伝送方向においては受信端デバイスであり、そのデバイスは、他の伝送方向においてはソース端デバイス又はアップストリームデバイスである。この実施形態においては、能力情報を搬送するのに使用されるTLVユニットは、表5に示されている形態で設計され、それによって、デバイスが受信端デバイスとして動作するか、或いは、ソース端デバイス又はアップストリームデバイスとして動作するかにかかわらず、そのデバイスは、TLVユニットを使用して、能力情報を報告することが可能である。
言い換えると、表5に示されているオーバーヘッド符号ブロックの管理チャネルのリンク層発見プロトコルLLDPフォーマットのTLVユニットは、受信端デバイスがM個のリンクに対して差動遅延補償を実行する第1の能力を示すのに使用される第1の能力情報を搬送することが可能であるとともに、受信端デバイスがソース端デバイスにサービスデータを送信するときに、受信端デバイスがM個のリンクに対して遅延送信補償を実行する能力を示すのに使用される情報を搬送することが可能である。
この出願のこの実施形態及び他の実施形態においては、例えば、第1の状態情報及び第2の状態情報等のデバイスの状態情報を報告又は送信するために、そのような状態情報は、オーバーヘッド符号ブロックの管理チャネルのLLDPフォーマットTLVユニットの中で搬送されてもよい。状態情報を搬送するのに使用されるLLDPフォーマットTLVユニットの各々のフィールドの定義は、表6に示されている。
表6の中のバイト1乃至6のフィールドの定義は、表2の中のバイト1乃至6のフィールドの定義と同じである。
バイト7は、リンクに対して実行されている差動遅延補償の現在の状態及びリンクに対して実行されている遅延送信補償の現在の状態、すなわち、リンク補償状態を定義する。バイト7の中の最初のビットは、受信方向においてそのリンクに対して実行される差動遅延補償の現在の状態を表す。その最初のビットの値が"0"であるときは、その値は、受信方向においてそのリンクに対して実行されている差動遅延補償が成功しているということを示す。例えば、OH符号ブロックの予約されているフィールドにおいては、リンクは、"selected"と印を付され、"subgroup ID"は、"3"である。この場合には、その値は、subgroup 3の中の他のリンクに対して実行されている差動遅延補償と比較して、そのリンクに対して実行されている差動遅延補償が成功しているということを示す。最初のビットの値が"1"であるときは、その値は、受信方向においてそのリンクに対して実行されている差動遅延補償が失敗しているということを示す。例えば、OH符号ブロックの予約されているフィールドにおいて、リンクは、"selected"と印を付され、"subgroup ID"は、"3"である。この場合には、その値は、subgroup 3の中の他のリンクに対して実行されている差動遅延補償と比較して、そのリンクに対して実行されている差動遅延補償が失敗しており、そのリンクが、デバイスの差動遅延補償能力を超えているということを示す。差動遅延の量は、バイト8乃至10において記述されている。バイト7の中の2番目のビットは、送信方向においてそのリンクに対して実行されている遅延送信補償の現在の状態を表す。2番目のビットの値が"0"であるときは、その値は、送信方向においてそのリンクのための遅延送信能力が存在しないということを示す。2番目のビットの値が"1"であるときは、その値は、そのリンクのための遅延送信能力が、送信方向において使用されているということを示す。遅延送信の量は、バイト11乃至13において記述されている。バイト7の他のビットは、予約されているフィールドである。
バイト8乃至10は、受信方向においてリンクに対して実行されている差動遅延補償が失敗しているときに、そのリンクが受信方向における差動遅延補償能力を超えている差動遅延の量を定義する。差動遅延の量の値xは、超過した差動遅延の量が、x個の符号ブロックのバッファサイズに対応する伝送時間であるということを示す。受信方向において差動遅延補償に成功しているときは、xは0である。
バイト11乃至13は、リンクの遅延送信の量を定義する。遅延送信の量の値xは、現在使用されている遅延送信バッファサイズがx個の符号ブロックであるということを示す。バイト7の2番目のビットが"0"である(送信方向においてリンクのための遅延送信能力がない)ときは、xの値は"0xFFFFFF"である。
本明細書においてある1つの例として説明しているバッファサイズは、単位として符号ブロック(block)を使用する。同様に、ns、10ns、又はバイト等の複数の異なる記述方式によって、或いは、複数の異なるサイズの基本バッファ単位によって、バッファサイズを表してもよい。このことは、この出願の複数の実施形態においては限定されない。
FlexE認知の転送の伝送モード、すなわち、転送ネットワーク間の伝送シナリオにおいて、デバイスは、TLVユニットを使用することによって、それらの
複数の状態を互いに通知し、そして、OH符号ブロックのシムからシムまでの管理チャネル(shim-to-shim management channel)によって伝送を実行する。他のシナリオにおいては、TLVユニットは、セクション管理チャネル(section management channel)によって伝送されてもよく、又は、シムからシムまでの管理チャネルによって伝送されてもよい。
この出願の複数の実施形態のうちのすべてにおいて、表6に示されているTLVユニットを使用することによって、状態情報を搬送してもよいということに留意すべきである。リンクは、通常、双方向である。したがって、デバイスは、ある伝送方向においては受信端デバイスであり、そのデバイスは、他の伝送方向においてはソース端デバイス又はアップストリームデバイスである。この実施形態においては、状態情報を搬送するのに使用されるTLVユニットは、表6に示されている形態で設計され、それによって、デバイスが受信端デバイスとして動作するか、或いは、ソース端デバイス又はアップストリームデバイスとして動作するかにかかわらず、そのデバイスは、TLVユニットを使用して、状態情報を報告することが可能である。
言い換えると、表6に示されているオーバーヘッド符号ブロックの管理チャネルのリンク層発見プロトコルLLDPフォーマットのTLVユニットは、M個のリンクのうちのいずれか2つの間の差動遅延の状態を示すのに使用される第1の状態情報を搬送することが可能であるとともに、また、受信端デバイスがソース端デバイスにサービスデータを送信するときに、受信端デバイスがM個のリンクに対して実行する遅延送信補償の現在の状態示すのに使用される情報を搬送することが可能である。
加えて、決定デバイスが第2の構成情報を決定した後に、表6に示されているTLVユニットは、さらに、第2の構成情報を搬送するのに使用されてもよい。具体的にいうと、TLVユニットは、さらに、アップストリームデバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される情報を搬送することが可能である。
第1の構成情報を送信する方式は、実施形態1において第1の構成情報を送信する方式と同様であってもよい。本明細書においては、詳細は繰り返しては説明されない。加えて、この出願のこの実施形態及び他の実施形態においては、例えば、第1の状態情報、第2の状態情報、第1の構成情報、及び第2の構成情報等のデバイスの状態情報の報告又は送信、及び構成情報の配信のために、そのような情報は、オーバーヘッド符号ブロックの管理チャネルのLLDPフォーマットTLVユニットの中で共に搬送されてもよい。状態情報及び構成情報を搬送するのに使用されるLLDPフォーマットTLVユニットの各々のフィールドの定義は、表7に示されている。
表7の中のバイト1乃至6のフィールドの定義は、表2の中のバイト1乃至6のフィールドの定義と同じである。
バイト7及び8は、リンクの補償状態及びリンクグループ構成を定義する。バイト7の中の最初のビットは、受信方向においてそのリンクに対して実行されている差動遅延補償の現在の状態を表す。その最初のビットの値が"0"であるときは、その値は、受信方向においてそのリンクに対して実行されている差動遅延補償が成功しているということを示す。例えば、バイト7及び8に続くフィールドにおいては、リンクは、"selected"と印を付され、"subgroup ID"は、"3"である。この場合には、その値は、subgroup 3の中の他のリンクに対して実行されている差動遅延補償と比較して、そのリンクに対して実行されている差動遅延補償が成功しているということを示す。最初のビットの値が"1"であるときは、その値は、受信方向においてそのリンクに対して実行されている差動遅延補償が失敗しているということを示す。例えば、バイト7及び8に続くフィールドにおいて、リンクは、"selected"と印を付され、"subgroup ID"は、"3"である。この場合には、その値は、subgroup 3の中の他のリンクに対して実行されている差動遅延補償と比較して、そのリンクに対して実行されている差動遅延補償が失敗しており、そのリンクが、デバイスの差動遅延補償能力を超えているということを示す。差動遅延の量は、バイト9乃至11において記述されている。バイト7の中の2番目のビットは、送信方向においてそのリンクに対して実行されている遅延送信補償の現在の状態を表す。その2番目のビットの値が"0"であるときは、その値は、送信方向においてそのリンクのための遅延送信能力が存在しないということ又遅延送信能力が送信方向において使用されていないということを示す。その2番目のビットの値が"1"であるときは、その値は、そのリンクのための遅延送信能力が、送信方向において使用されているということを示す。遅延送信の量は、バイト12乃至14において記述されている。バイト7の他のビットは、予約されているフィールドである。
バイト7及び8の中の3番目乃至13番目のビットは、リンクが属しているリンクグループ、すなわち、そのリンクのマーク情報を表すのに使用される。2番目乃至4番目のビットは、"selected"又は"standby"を表すのに使用される。例えば、"001"は、"selected"を表し、"010"は、"standby"を表す。"selected"状態においては、後に続く8個のビットは、"subgroup ID"を表すのに使用されてもよい。バイト7及び8の中の他のビットは、予約されたフィールドである。
表7の中のバイト9乃至11が記述している差動遅延の量は、表6の中のバイト8乃至10が記述している差動遅延の量と同じであり、表7の中のバイト12乃至14が記述している遅延送信の量は、表6の中のバイト11乃至13が記述している遅延送信の量と同じである。本明細書においては、詳細は繰り返しては説明されない。
[実施形態5]
この実施形態においては、第1のデバイス、すなわち、決定デバイスは、受信端デバイスであり、第2のデバイスは、ソース端デバイスである。受信端デバイスは、遅延受信補償能力を有する。ソース端デバイスは、遅延送信補償能力を有する、すなわち、K個のアップストリームデバイスは、ソース端デバイスである。
受信端デバイスによって、リンクグループ構成を決定し、そして、受信端デバイス及びソース端デバイスによって、協調的な補償を実行するプロセスは、以下のステップを含んでもよい。
C-1: ソース端デバイスと受信端デバイスとの間のリンクを開始する。
C-2: ソース端デバイスは、独立してM個のリンクを使用することによって、受信端デバイスに複数のデータフレームを個別に送信する。それに対応して、受信端デバイスは、ソース端デバイスが送信するそれらの複数のデータフレームを受信する。それらの複数のデータフレームは、整列マークを含んでいてもよいということを理解すべきである。
C-3: ソース端デバイスは、受信端デバイスに第2の能力情報を送信し、第2の能力情報は、ソース端デバイスがM個のリンクのうちの少なくとも1つに対して遅延送信補償を実行する第2の能力を示すのに使用される。それに対応して、受信端デバイスは、ソース端デバイスが送信する第2の能力情報を受信する。第2の能力情報は、C-2におけるデータフレームの中で搬送されてもよく、又は、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。
C-4: ソース端デバイスは、受信端デバイスに第2の状態情報を送信し、第2の状態情報は、ソース端デバイスがM個のリンクのうちの少なくとも1つに対して実行する遅延送信補償の現在の状態を示すのに使用される。それに対応して、受信端デバイスは、ソース端デバイスが送信する第2の状態情報を受信する。第2の状態情報は、C-2におけるデータフレームの中で搬送されてもよく、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。
C-5: 受信端デバイスは、M個のリンクの間の差動遅延の状態を測定して、第1の状態情報を取得する。
C-6: 受信端デバイスは、第1の状態情報、受信端デバイスがM個のリンクに対して差動遅延補償を実行する能力を表すことが可能である第1の能力情報、第2の能力情報、及び第2の状態情報に基づいて、リンクグループ構成及び遅延送信補償構成を決定する。具体的なリンクグループ構成は、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとすることを含む。
C-7: 受信端デバイスは、ソース端デバイスに第1の構成情報を送信し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の構成情報を受信する。
C-8: 受信端デバイスは、ソース端デバイスに第2の構成情報を送信し、第2の構成情報は、ソース端デバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される情報を含む。それに対応して、ソース端デバイスは、受信端デバイスが送信する第2の構成情報を受信する。
C-9: ソース端デバイスは、第2の構成情報に基づいて、リンクの送信遅延を調整する。
C-10: ソース端デバイスは、受信端デバイスに、遅延送信補償の更新された現在の状態に関する情報を送信する。このように、次の協調的な補償のための準備を行うことが可能であり、遅延送信補償の構成が完了しているということを受信端デバイスに通知する。
C-11: ソース端デバイスが送信する情報を受信した後、受信端デバイスは、複数のリンクの間の差動遅延を再分析し、そして、M個のリンクに対して差動遅延補償を実行する。具体的には、受信端デバイスは、第1の構成情報に基づいて、差動遅延補償を実行する、すなわち、差動遅延バッファサイズを設定する。言い換えると、受信端デバイスは、受信端デバイスが決定したリンクグループ構成に基づいて、第1のリンクグループの中の複数のリンクに対して差動遅延補償を実行する。受信端デバイスは、ソース端デバイスに、それらの複数のリンクの間の差動遅延の状態及びリンクグループ構成をフィードバックする。
C-12: ソース端デバイスは、第1の構成情報に基づいて、受信端デバイスにサービスデータを送信する。
ソース端デバイスと受信端デバイスとの間では、第1の状態情報、第1の能力情報、第1の構成情報、第2の状態情報、第2の能力情報、又は第2の構成情報のうちの少なくとも1つの送信フォーマット及び送信チャネルは、実施形態4における送信フォーマット及び送信チャネルと同様であるということを理解すべきであり、本明細書においては、詳細は繰り返しては説明されない。
[実施形態6]
この実施形態においては、第1のデバイス、すなわち、決定デバイスは、受信端デバイスであり、第2のデバイスは、ソース端デバイスである。受信端デバイスは、遅延受信補償能力を有する。ソース端デバイス及び少なくとも1つの中間デバイスは、遅延送信補償能力を有する。言い換えると、K個のアップストリームデバイスは、ソース端デバイス及び少なくとも1つの中間デバイスを含む。
受信端デバイス、ソース端デバイス、及び少なくとも1つの中間デバイスによる協調的な補償のプロセスは、以下のステップを含んでもよい。
D-1: ソース端デバイスと受信端デバイスとの間のリンクを開始する。
D-2: ソース端デバイスは、独立してM個のリンクを使用することによって、受信端デバイスに複数のデータフレームを個別に送信する。それに対応して、受信端デバイスは、ソース端デバイスが送信するそれらの複数のデータフレームを受信する。それらの複数のデータフレームは、整列マークを含んでいてもよいということを理解すべきである。
D-3: 受信端デバイスは、M個のリンクの間の差動遅延の状態を測定して、第1の状態情報を取得する。
D-4: ソース端デバイス及び少なくとも1つの中間デバイスは、受信端デバイスに第2の能力情報を送信し、第2の能力情報は、各々のアップストリームデバイスがM個のリンクのうちの少なくとも1つに対して遅延送信補償を実行する第2の能力を示すのに使用される。それに対応して、受信端デバイスは、ソース端デバイスが送信する第2の能力情報を受信する。第2の能力情報は、D-2におけるデータフレームの中で搬送されてもよく、又は、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。
D-5: ソース端デバイス及び少なくとも1つの中間デバイスは、受信端デバイスに第2の状態情報を送信し、第2の状態情報は、各々のアップストリームデバイスがM個のリンクのうちの少なくとも1つに対して実行する遅延送信補償の現在の状態を示すのに使用される。それに対応して、受信端デバイスは、ソース端デバイスが送信する第2の状態情報を受信する。第2の状態情報は、D-2におけるデータフレームの中で搬送されてもよく、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。
D-6: 受信端デバイスは、第1の状態情報、受信端デバイスがM個のリンクに対して差動遅延補償を実行する能力を表すことが可能である第1の能力情報、第2の能力情報、及び第2の状態情報に基づいて、リンクグループ構成及び遅延送信補償構成を決定する。具体的なリンクグループ構成は、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとすることを含む。
D-7: 受信端デバイスは、ソース端デバイスに第1の構成情報を送信し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の構成情報を受信する。
D-8: 受信端デバイスは、中間デバイスに第1の構成情報を送信し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、中間デバイスは、受信端デバイスが送信する第1の構成情報を受信する。D-8は、選択的なステップであり、D-8は、協調的な補償プロセスの代わりに、他のプロセスのために実行されてもよいということを理解すべきである。
D-9: 受信端デバイスは、ソース端デバイス及び少なくとも1つの中間デバイスに第2の構成情報を送信し、第2の構成情報は、ソース端デバイス及び少なくとも1つの中間デバイスが対応するリンクに対して個別に実行する必要がある遅延送信補償の構成を示すのに使用される情報を含む。それに対応して、ソース端デバイス及び少なくとも1つの中間デバイスは、各々、受信端デバイスが送信する第2の構成情報を受信する。
D-10: ソース端デバイス及び少なくとも1つの中間デバイスは、第2の構成情報に基づいて、リンクの送信遅延を調整する、すなわち、遅延送信バッファサイズを設定する。
D-11: ソース端デバイス及び少なくとも1つの中間デバイスは、受信端デバイスに、遅延送信補償の更新された現在の状態に関する情報を送信する。このように、次の協調的な補償のための準備を行うことが可能であり、遅延送信補償の構成が完了しているということを受信端デバイスに通知する。
D-12: 受信端デバイスは、複数のリンクの間の差動遅延を再分析し、そして、M個のリンクに対して差動遅延補償を実行する。具体的には、受信端デバイスは、第1の構成情報に基づいて、差動遅延補償を実行する、すなわち、差動遅延バッファサイズを設定する。言い換えると、受信端デバイスは、受信端デバイスが決定したリンクグループ構成に基づいて、第1のリンクグループの中の複数のリンクに対して差動遅延補償を実行する。受信端デバイスは、ソース端デバイスに、それらの複数のリンクの間の差動遅延の状態及びリンクグループ構成をフィードバックする。
D-13: ソース端デバイスは、第1の構成情報に基づいて、受信端デバイスにサービスデータを送信する。
ソース端デバイスと受信端デバイスとの間では、第1の状態情報、第1の能力情報、第1の構成情報、第2の状態情報、第2の能力情報、又は第2の構成情報のうちの少なくとも1つの送信フォーマット及び送信チャネルは、実施形態4における送信フォーマット及び送信チャネルと同様であるということを理解すべきであり、本明細書においては、詳細は繰り返しては説明されない。
実施形態7、実施形態8、実施形態9においては、第1のデバイス、すなわち、決定デバイスは、ソース端デバイスであり、第2のデバイスは、受信端デバイスである。受信端デバイスは、遅延受信補償能力を有する。K個のアップストリームデバイスは、ソース端デバイス及び/又は少なくとも1つの中間デバイスを含み、遅延送信補償能力を有する。
S110において、第1のデバイスによって、ソース端デバイスと受信端デバイスとの間のM個のリンクの第1の状態情報を取得するステップは、受信端デバイスが送信する第1の状態情報を第1のデバイスによって受信するステップを含んでいてもよい。S120において、第1のデバイスによって、受信端デバイスの第1の能力情報を取得するステップは、受信端デバイスが送信する第1の能力情報を第1のデバイスによって受信するステップを含んでいてもよい。
少なくとも1つのアップストリームデバイスが遅延送信補償の構成を完了した後に、方法100は、第1のデバイスによって、第1のリンクグループに基づいて、第2のデバイスとのサービスデータの伝送を実行するステップと、第1のデバイスによって、第1のリンクグループのうちで、少なくとも1つのアップストリームデバイスが第2の構成情報に基づいて遅延送信補償を実行しているリンクに対して、第1の構成情報に基づいて差動遅延補償を実行するステップと、をさらに含んでもよい。
[実施形態7]
この実施形態においては、第1のデバイス、すなわち、決定デバイスは、ソース端デバイスであり、第2のデバイスは、受信端デバイスである。受信端デバイスは、遅延受信補償能力を有する。受信端デバイスとソース端デバイスとの間には、遅延送信補償能力を有する中間デバイスが存在する。言い換えると、K個のアップストリームデバイスは、少なくとも1つの中間デバイスである。
具体的には、第1のデバイスによって、K個のアップストリームデバイスの各々の第2の能力情報及び第2の状態情報を取得するステップは、少なくとも1つの中間デバイスの各々が送信する第2の能力情報及び第2の状態情報を第1のデバイスによって受信するステップを含んでもよく、方法100は、第1のデバイスによって少なくとも1つの中間デバイスのうちの少なくとも一部に、第2の構成情報を送信するステップをさらに含んでもよく、第2の構成情報は、少なくとも一部の中間デバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される。
第1のデバイスによって、少なくとも1つの中間デバイスのうちの少なくとも一部の中間デバイスに、第2の構成情報を送信するステップは、第1のデバイスによって中間デバイスに、第2の構成情報を直接的に送信するステップであってもよく、又は、第1のデバイスによって受信端デバイスに、第2の構成情報を送信し、それによって、受信端デバイスは、中間デバイスに第2の構成情報を転送する、ステップであってもよいということを理解すべきである。言い換えると、第1のデバイスは、中間デバイスに第2の構成情報を直接的に送信してもよく又は間接的に送信してもよい。このことは、この実施形態においては限定されない。
受信端デバイス及び中間デバイスによる協調的な補償のプロセスは、以下のステップを含んでもよい。
E-1: ソース端デバイスと受信端デバイスとの間のリンクを開始する。
E-2: ソース端デバイスは、独立してM個のリンクを使用することによって、受信端デバイスに複数のデータフレームを個別に送信する。それに対応して、受信端デバイスは、ソース端デバイスが送信するそれらの複数のデータフレームを受信する。それらの複数のデータフレームは、整列マークを含んでいてもよいということを理解すべきである。
E-3: 受信端デバイスは、M個のリンクの間の差動遅延の状態を測定する。
E-4: 受信端デバイスは、ソース端デバイスに第1の状態情報を送信し、第1の状態情報は、M個のリンクの間の差動遅延の状態を示すのに使用される。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の状態情報を受信する。選択的に、第1の状態情報は、FlexEの中のOH符号ブロックのshim-to-shim management channelによって伝送されてもよい。
E-5: 受信端デバイスは、ソース端デバイスに第1の能力情報を送信し、第1の能力情報は、受信端デバイスがM個のリンクに対して差動遅延補償を実行する第1の能力を示すのに使用される。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の能力情報を受信する。選択的に、第1の能力情報は、FlexEの中のOH符号ブロックのshim-to-shim management channelによって伝送されてもよい。
E-6: 中間デバイスは、ソース端デバイスに第2の能力情報を送信し、第2の能力情報は、各々の中間デバイスがM個のリンクのうちの少なくとも1つに対して遅延送信補償を実行する第2の能力を示すのに使用される。それに対応して、ソース端デバイスは、中間デバイスが送信する第2の能力情報を受信する。第2の能力情報は、E-2におけるデータフレームの中で搬送されてもよく、又は、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。選択的に、第2の能力情報は、FlexEの中のOH符号ブロックのshim-to-shim management channelによって伝送されてもよい。
E-7: 中間デバイスは、ソース端デバイスに第2の状態情報を送信し、第2の状態情報は、各々の中間デバイスがM個のリンクのうちの少なくとも1つに対して実行する遅延送信補償の現在の状態を示すのに使用される。それに対応して、ソース端デバイスは、中間デバイスが送信する第2の状態情報を受信する。第2の状態情報は、E-2におけるデータフレームの中で搬送されてもよく、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。選択的に、第2の状態情報は、FlexEの中のOH符号ブロックのsection management channelによって伝送されてもよい。
E-8: ソース端デバイスは、第1の状態情報、第1の能力情報、第2の能力情報、及び第2の状態情報に基づいて、リンクグループ構成及び遅延送信補償構成を決定する。具体的なリンクグループ構成は、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとすることを含む。
E-9: ソース端デバイスは、受信端デバイスに第1の構成情報及び第2の構成情報を送信し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、受信端デバイスは、ソース端デバイスが送信する第1の構成情報を受信する。
E-10: 受信端デバイスは、第1の構成情報に基づいて、例えば、差動遅延補償のために局所的なバッファを設定するといったように、差動遅延補償の構成を実行する。
E-11: 受信端デバイスは、中間デバイスに第2の構成情報を送信し、第2の構成情報は、中間デバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される情報を含む。それに対応して、中間デバイスは、受信端デバイスが送信する第2の構成情報を受信する。
E-12: 受信端デバイスは、中間デバイスに第1の構成情報を送信し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、中間デバイスは、ソース端デバイスが送信する第1の構成情報を受信する。E-12は、選択的なステップであり、E-12は、協調的な補償プロセスの代わりに、他のプロセスのために実行されてもよいということを理解すべきである。
E-13: 中間デバイスは、第2の構成情報に基づいて、例えば、遅延したデータ送信のためにバッファを設定するといったように、リンクの送信遅延を調整する。
E-14: 中間デバイスは、受信端デバイスに、遅延送信補償の更新された現在の状態に関する情報を送信する。このように、次の協調的な補償のための準備を行うことが可能であり、遅延送信補償の構成が完了しているということを受信端デバイスに通知する。
E-15: 中間デバイスが送信する情報を受信した後に、受信端デバイスは、複数のリンクの間の差動遅延を再分析し、そして、M個のリンクに対して差動遅延補償を実行する。具体的には、受信端デバイスは、第1の構成情報に基づいて、差動遅延補償を実行する、すなわち、差動遅延バッファサイズを設定する。受信端デバイスは、ソース端デバイスに、構成が完了しているということを示す情報をフィードバックする。
E-16: ソース端デバイスは、第1の構成情報に基づいて、受信端デバイスにサービスデータを送信する。
選択的に、E-8において、ソース端デバイスは、さらに、例えば、サービス量及び/又は帯域幅等の包括的な要因等の受信端デバイスに送信されるサービスデータの関連する情報を参照して、リンクグループ構成の解決方法を決定してもよい。
ソース端デバイス、中間デバイス、及び受信端デバイスの間では、第1の状態情報、第1の能力情報、第1の構成情報、第2の状態情報、第2の能力情報、又は第2の構成情報のうちの少なくとも1つの送信フォーマット及び送信チャネルは、実施形態4における送信フォーマット及び送信チャネルと同様であるということを理解すべきであり、本明細書においては、詳細は繰り返しては説明されない。
[実施形態8]
この実施形態においては、第1のデバイス、すなわち、決定デバイスは、ソース端デバイスであり、第2のデバイスは、受信端デバイスである。受信端デバイスは、遅延受信補償能力を有する。ソース端デバイスは、遅延送信補償能力を有する、すなわち、K個のアップストリームデバイスは、ソース端デバイスである。
具体的には、方法100は、第1のデバイスによって、第1のリンクグループに基づいて、第1のデバイスが対応するリンクに対して実行する必要がある遅延送信補償の決定された構成に基づいて、第2のデバイスにサービスデータを伝送するステップをさらに含んでもよい。
図12は、この実施形態にしたがったリンクグループ構成及び補償のプロセス400の概略的な図である。受信端デバイス及びソース端デバイスによる協調的な補償のプロセス400は、以下のステップを含んでいてもよい。
S405: ソース端デバイスと受信端デバイスとの間のリンクを開始する。
S410: ソース端デバイスは、独立してM個のリンクを使用することによって、受信端デバイスに複数のデータフレームを個別に送信する。それに対応して、受信端デバイスは、ソース端デバイスが送信するそれらの複数のデータフレームを受信する。それらの複数のデータフレームは、整列マークを含んでいてもよいということを理解すべきである。
S415: 受信端デバイスは、M個のリンクの間の差動遅延の状態を測定する。
S420: 受信端デバイスは、ソース端デバイスに第1の状態情報を送信し、第1の状態情報は、M個のリンクの間の差動遅延の状態を示すのに使用される。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の状態情報を受信する。選択的に、第1の状態情報は、FlexEの中のOH符号ブロックのshim-to-shim management channelによって伝送されてもよい。
S425: 受信端デバイスは、ソース端デバイスに第1の能力情報を送信し、第1の能力情報は、受信端デバイスがM個のリンクに対して差動遅延補償を実行する第1の能力を示すのに使用される。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の能力情報を受信する。選択的に、第1の能力情報は、FlexEの中のOH符号ブロックのshim-to-shim management channelによって伝送されてもよい。
S430: ソース端デバイスは、第1の状態情報、第1の能力情報、ソース端デバイスがM個のリンクのうちの少なくとも1つに対して遅延送信補償を実行する能力を示すのに使用される第2の能力情報、及び、ソース端デバイスがM個のリンクのうちの少なくとも1つに対して実行する遅延送信補償の状態を示すのに使用される第2の状態情報に基づいて、リンクグループ構成及び遅延送信補償構成を決定する。具体的なリンクグループ構成は、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとすることを含む。
S435: ソース端デバイスは、S430において決定した遅延送信補償構成に基づいて、対応するリンクの送信遅延を調整する。例えば、S430において、PHY2の遅延送信補償が実行されることが決定される。この場合には、PHY2の遅延送信補償のバッファサイズは、S435において調整される。
S440: ソース端デバイスは、受信端デバイスに第1の構成情報を送信し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、受信端デバイスは、ソース端デバイスが送信する第1の構成情報を受信する。
S445: 受信端デバイスは、第1の構成情報に基づいて、例えば、差動遅延補償のために局所的なバッファを設定するといったように、差動遅延補償の構成を実行する。
S450: 受信端デバイスは、ソース端デバイスに、構成を完了しているということを示す肯定応答情報を送信する。それに対応して、ソース端デバイスは、受信端デバイスが送信する肯定応答情報を受信する。肯定応答情報が、ソース端デバイスが遅延送信補償の構成に成功しているということを示すときは、S455が実行される。肯定応答情報が、ソース端デバイスが遅延送信補償の構成に失敗しているということを示すときは、再び、S430が実行される。
S455: ソース端デバイスは、第1の構成情報に基づいて、受信端デバイスにサービスデータを送信する。
ソース端デバイスと受信端デバイスとの間では、第1の状態情報、第1の能力情報、第1の構成情報、第2の状態情報、第2の能力情報、又は第2の構成情報のうちの少なくとも1つの送信フォーマット及び送信チャネルは、実施形態4における送信フォーマット及び送信チャネルと同様であるということを理解すべきであり、本明細書においては、詳細は繰り返しては説明されない。
[実施形態9]
この実施形態においては、第1のデバイス、すなわち、決定デバイスは、ソース端デバイスであり、第2のデバイスは、受信端デバイスである。受信端デバイスは、遅延受信補償能力を有する。ソース端デバイス及び少なくとも1つの中間デバイスは、遅延送信補償能力を有する。言い換えると、K個のアップストリームデバイスは、ソース端デバイス及び少なくとも1つの中間デバイスを含む。
具体的には、方法100は、第1のデバイスによって、第1のリンクグループに基づいて、第1のデバイスが対応するリンクに対して実行する必要がある遅延送信補償の決定された構成に基づいて、第2のデバイスにサービスデータを伝送するステップをさらに含んでもよい。
受信端デバイス、ソース端デバイス、及び少なくとも1つの中間デバイスによる協調的な補償のプロセスは、以下のステップを含んでもよい。
F-1: ソース端デバイスと受信端デバイスとの間のリンクを開始する。
F-2: ソース端デバイスは、独立してM個のリンクを使用することによって、受信端デバイスに複数のデータフレームを個別に送信する。それに対応して、受信端デバイスは、ソース端デバイスが送信するそれらの複数のデータフレームを受信する。それらの複数のデータフレームは、整列マークを含んでいてもよいということを理解すべきである。
F-3: 受信端デバイスは、M個のリンクの間の差動遅延の状態を測定する。
F-4: 受信端デバイスは、ソース端デバイスに第1の状態情報を送信し、第1の状態情報は、M個のリンクの間の差動遅延の状態を示すのに使用される。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の状態情報を受信する。選択的に、第1の状態情報は、FlexEの中のOH符号ブロックのshim-to-shim management channelによって伝送されてもよい。
F-5: 受信端デバイスは、ソース端デバイスに第1の能力情報を送信し、第1の能力情報は、受信端デバイスがM個のリンクに対して差動遅延補償を実行する第1の能力を示すのに使用される。それに対応して、ソース端デバイスは、受信端デバイスが送信する第1の能力情報を受信する。選択的に、第1の能力情報は、FlexEの中のOH符号ブロックのshim-to-shim management channelによって伝送されてもよい。
F-6: 中間デバイスは、ソース端デバイスに第2の能力情報を送信し、第2の能力情報は、各々の中間デバイスがM個のリンクのうちの少なくとも1つに対して遅延送信補償を実行する第2の能力を示すのに使用される。それに対応して、ソース端デバイスは、中間デバイスが送信する第2の能力情報を受信する。第2の能力情報は、F-2におけるデータフレームの中で搬送されてもよく、又は、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。選択的に、第2の能力情報は、FlexEの中のOH符号ブロックのshim-to-shim management channelによって伝送されてもよい。
F-7: 中間デバイスは、ソース端デバイスに第2の状態情報を送信し、第2の状態情報は、各々の中間デバイスがM個のリンクのうちの少なくとも1つに対して実行する遅延送信補償の現在の状態を示すのに使用される。それに対応して、ソース端デバイスは、中間デバイスが送信する第2の状態情報を受信する。第2の状態情報は、F-2におけるデータフレームの中で搬送されてもよく、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。選択的に、第2の状態情報は、FlexEの中のOH符号ブロックのsection management channelによって伝送されてもよい。
F-8: ソース端デバイスは、第1の状態情報、第1の能力情報、ソース端デバイスがM個のリンクのうちの少なくとも1つに対して遅延送信補償を実行する能力を示すのに使用される第2の能力情報、中間デバイスが送信する第2の状態情報、及びソース端デバイスがM個のリンクのうちの少なくとも1つに対して実行する遅延送信補償の状態を示すのに使用される第2の状態情報に基づいて、リンクグループ構成及び遅延送信補償構成を決定する。具体的なリンクグループ構成は、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとすることを含む。
F-9: ソース端デバイスは、F-8において決定した遅延送信補償構成に基づいて、対応するリンクの送信遅延を調整する。例えば、F-8において、PHY2の遅延送信補償が実行されることが決定される。この場合には、PHY2の遅延送信補償のバッファサイズは、F-9において調整される。
F-10: ソース端デバイスは、受信端デバイスに第1の構成情報及び第2の構成情報を送信し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、受信端デバイスは、ソース端デバイスが送信する第1の構成情報を受信する。
F-11: 受信端デバイスは、第1の構成情報に基づいて、例えば、差動遅延補償のために局所的なバッファを設定するといったように、差動遅延補償の構成を実行する。
F-12: 受信端デバイスは、中間デバイスに第2の構成情報を送信し、第2の構成情報は、中間デバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される情報を含む。それに対応して、中間デバイスは、受信端デバイスが送信する第2の構成情報を受信する。
F-13: 受信端デバイスは、中間デバイスに第1の構成情報を送信し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、中間デバイスは、ソース端デバイスが送信する第1の構成情報を受信する。F-13は、選択的なステップであり、F-13は、協調的な補償プロセスの代わりに、他のプロセスのために実行されてもよいということを理解すべきである。
F-14: 中間デバイスは、第2の構成情報に基づいて、例えば、遅延したデータ送信のためにバッファを設定するといったように、リンクの送信遅延を調整する。
F-15: 中間デバイスは、受信端デバイスに、遅延送信補償の更新された現在の状態に関する情報を送信する。このように、次の協調的な補償のための準備を行うことが可能であり、遅延送信補償の構成が完了しているということを受信端デバイスに通知する。
F-16: 受信端デバイスは、中間デバイスが送信する情報を受信した後に、M個のリンクに対して差動遅延補償を実行する。具体的には、受信端デバイスは、第1の構成情報に基づいて、差動遅延補償を実行する、すなわち、差動遅延バッファサイズを設定する。受信端デバイスは、ソース端デバイスに、構成が完了しているということを示す情報を送信する。
F-17: ソース端デバイスは、第1の構成情報に基づいて、受信端デバイスにサービスデータを送信する。
ソース端デバイス、中間デバイス、及び受信端デバイスの間では、第1の状態情報、第1の能力情報、第1の構成情報、第2の状態情報、第2の能力情報、又は第2の構成情報のうちの少なくとも1つの送信フォーマット及び送信チャネルは、実施形態4における送信フォーマット及び送信チャネルと同様であるということを理解すべきであり、本明細書においては、詳細は繰り返しては説明されない。
実施形態10においては、第1のデバイス、すなわち、決定デバイスは、管理デバイスであり、第2のデバイスは、受信端デバイス及び/又はソース端デバイスを含む。受信端デバイスは、遅延受信補償能力を有する。K個のアップストリームデバイスは、ソース端デバイス及び/又は少なくとも1つの中間デバイスを含んでもよく、遅延送信補償能力を有してもよい。
具体的には、S110において、第1のデバイスによって、ソース端デバイスと受信端デバイスとの間のM個のリンクの第1の状態情報を取得するステップは、受信端デバイスが送信する第1の状態情報を第1のデバイスによって受信するステップを含んでいてもよく、S120において、第1のデバイスによって、受信端デバイスの第1の能力情報を取得するステップは、受信端デバイスが送信する第1の能力情報を第1のデバイスによって受信するステップを含んでいてもよく、第1のデバイスによって、K個のアップストリームデバイスの各々の第2の能力情報及び第2の状態情報を取得するステップは、各々のアップストリームデバイスが送信する第2の能力情報及び第2の状態情報を第1のデバイスによって受信するステップを含んでもよく、方法100は、第1のデバイスによってK個のアップストリームデバイスのうち少なくとも1つに、第2の構成情報を送信するステップをさらに含んでもよく、第2の構成情報は、少なくとも1つのアップストリームデバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される。
管理デバイスによって、リンクグループ構成を決定し、そして、受信端デバイス及び他のデバイスによって、協調的な補償を実行するプロセスは、以下のステップを含んでもよい。
G-1: ソース端デバイスと受信端デバイスとの間のリンクを開始する。
G-2: ソース端デバイスは、独立してM個のリンクを使用することによって、受信端デバイスに複数のデータフレームを個別に送信する。それに対応して、受信端デバイスは、ソース端デバイスが送信するそれらの複数のデータフレームを受信する。それらの複数のデータフレームは、整列マークを含んでいてもよいということを理解すべきである。
G-3: 受信端デバイスは、M個のリンクの間の差動遅延の状態を測定する。
G-4: 受信端デバイスは、管理デバイスに第1の状態情報を送信し、第1の状態情報は、M個のリンクの間の差動遅延の状態を示すのに使用される。それに対応して、管理デバイスは、受信端デバイスが送信する第1の状態情報を受信する。
G-5: 受信端デバイスは、管理デバイスに第1の能力情報を送信し、第1の能力情報は、受信端デバイスがM個のリンクに対して差動遅延補償を実行する第1の能力を示すのに使用される。それに対応して、管理デバイスは、受信端デバイスが送信する第1の能力情報を受信する。
G-6: ソース端デバイス及び/又は少なくとも1つの中間デバイスは、管理デバイスに第2の能力情報を送信し、第2の能力情報は、各々のアップストリームデバイスがM個のリンクのうちの少なくとも1つに対して遅延送信補償を実行する第2の能力を示すのに使用される。それに対応して、管理デバイスは、ソース端デバイス及び/又は少なくとも1つの中間デバイスが送信する第2の能力情報を受信する。ソース端デバイスに対応する第2の能力情報は、G-2におけるデータフレームの中で搬送されてもよく、又は、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。選択的に、第2の能力情報は、FlexEの中のOH符号ブロックのshim-to-shim management channelによって伝送されてもよい。
G-7: ソース端デバイス及び/又は少なくとも1つの中間デバイスは、管理デバイスに第2の状態情報を送信し、第2の状態情報は、各々のアップストリームデバイスがM個のリンクのうちの少なくとも1つに対して実行する遅延送信補償の現在の状態を示すのに使用される。それに対応して、管理デバイスは、ソース端デバイス及び/又は少なくとも1つの中間デバイスが送信する第2の状態情報を受信する。ソース端デバイスに対応する第2の状態情報は、G-2におけるデータフレームの中で搬送されてもよく、他の方式によって送信されてもよいということを理解すべきである。このことは、この実施形態においては限定されない。選択的に、第2の状態情報は、FlexEの中のOH符号ブロックのsection management channelによって伝送されてもよい。
G-8: 管理デバイスは、第1の状態情報、第1の能力情報、第2の状態情報、及び第2の能力情報に基づいて、リンクグループ構成及び遅延送信補償構成を決定する。具体的には、その構成は、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとすることを含む。
G-9: 管理デバイスは、(ソース端デバイス及び/又は少なくとも1つの中間デバイスを含む)K個のアップストリームデバイスのうちで遅延送信補償の構成を実行する必要があるアップストリームデバイスに第2の構成情報を送信し、第2の構成情報は、遅延送信補償構成を示すのに使用される。
G-10: (ソース端デバイス及び/又は少なくとも1つの中間デバイスを含む)K個のアップストリームデバイスのうちで遅延送信補償の構成を実行する必要があるアップストリームデバイスは、第2の構成情報に基づいて、遅延送信補償バッファサイズを構成する。
G-11: (ソース端デバイス及び/又は少なくとも1つの中間デバイスを含む)K個のアップストリームデバイスのうちで遅延送信補償の構成を実行する必要があるアップストリームデバイスは、第2の構成情報を受信しているとともに、対応する構成を実行しているということを示すために、管理デバイスに肯定応答情報を返送する。それに対応して、管理デバイスは、ソース端デバイス及び/又は受信端デバイスが返送するその肯定応答情報を受信する。G-11は選択的なステップであるということを理解すべきである。
G-12: 管理デバイスは、肯定応答情報を受信した後に、受信端デバイスに第1の構成情報及び第2の構成情報を送信し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。それに対応して、受信端デバイスは、管理デバイスが送信する第1の構成情報及び第2の構成情報を受信する。選択的に、第1の構成情報は、受信端デバイスが実行する差動遅延補償のための各々のリンクのバッファ要件をさらに含んでいてもよい。受信端デバイスは、そのバッファ要件に基づいて、各々のリンクのバッファ量を直接的に設定してもよい。
G-13: 受信端デバイスは、第1の構成情報及び第2の構成情報に基づいて、対応する構成を実行する。
G-14: 受信端デバイスは、第1の構成情報及び第2の構成情報を受信しているとともに、対応する構成を実行しているということを示すために、管理デバイスに肯定応答情報を返送してもよい。それに対応して、管理デバイスは、受信端デバイスが返送するその肯定応答情報を受信する。G-13は選択的なステップであるということを理解すべきである。
G-15: 管理デバイスは、受信端デバイスが返送する肯定応答情報を受信した後に、ソース端デバイスに第1の構成情報を送信する。G-15は選択的なステップであるということを理解すべきである。
G-16: ソース端デバイスは、第1の構成情報に基づいて、受信端デバイスにサービスデータを送信する。
ソース端デバイス及び受信端デバイスと管理デバイスのOH符号ブロックの管理チャネルによって、ソース端デバイス、受信端デバイス、及び管理デバイスの間で、第1の状態情報、第1の能力情報、第1の構成情報、第2の状態情報、第2の能力情報、及び第2の構成情報についての通信を実行してもよいということを理解すべきである。選択的に、FlexOの場合には、GFPフォーマット、HDLCフォーマット、又はPPPフォーマットのOH符号ブロックのGCC0バイトを使用することによって、或いは、自己定義されたフレームフォーマットのRESフィールドを使用することによって、上記の情報を伝送してもよい。FlexEの場合には、OH符号ブロックの管理チャネルによって、インターネットプロトコル(Internet Protocol, IP)パケットの形態で、上記の情報を伝送してもよい。具体的な伝送方式は、この実施形態においては限定されない。
この出願の複数の実施形態において、ソース端デバイス及び受信端デバイス、又は中間デバイス等も含めて、すべてが、差動遅延補償能力又は遅延送信補償能力を有してもよい。この出願のそれらの複数の実施形態は、複数のデバイスに適用されて、能力交渉によってリンクグループ補償を実装する。ソース端デバイスと受信端デバイスとの間のFlexEグループ又はFlexOグループの中の各々のデバイスの補償能力が、複数のリンクの間の差動遅延を補償するのに十分ではないときに、リンクグループを構成し、それによって、ソース端デバイスは、遅延整列リンクに対してのみクロスリンクサービスデータ伝送を実行する。
この出願の複数の実施形態において、第1の状態情報、第1の能力情報、第2の状態情報、第2の能力情報、第1の構成情報、及び第2の構成情報のうちのいずれか1つの伝送については、各々のリンクに対応する状態情報、能力情報、又は構成情報をそのリンクによって伝送してもよい、言い換えると、関連する情報は、粒度としてリンクを使用することによって伝送されるということを理解すべきである。もちろん、この出願のそれらの複数の実施形態において、関連する情報は、代替的に、例えば、粒度としてデバイスを使用することによってといったように、他の粒度を使用することによって伝送されてもよい。このことは、本明細書においては限定されない。
上記の記載は、この出願の複数の実施形態によって提供されるリンクグループ構成方法を説明している。以下の記載は、この出願の複数の実施形態によって提供されるリンクグループ構成デバイスを説明する。
図13は、この出願のある1つの実施形態にしたがったリンクグループ構成デバイス500の概略的なブロック図である。リンクグループ構成デバイス500は、第1のデバイスである。図13に示されているように、リンクグループ構成デバイス500は、
ソース端デバイスと受信端デバイスとの間のM個のリンクの第1の状態情報を取得するように構成される取得モジュール510であって、第1の状態情報は、M個のリンクのうちのいずれか2つの間の差動遅延の状態を示すのに使用され、M個のリンクのうちのいずれか1つは、フレキシブルイーサネットFlexE物理接続リンク又はフレキシブル光転送ネットワークFlexO物理接続リンクであり、Mは、2以上の整数であり、
取得モジュール510は、さらに、受信端デバイスの第1の能力情報を取得するように構成され、第1の能力情報は、受信端デバイスがM個のリンクに対して差動遅延補償を実行する第1の能力を示すのに使用される、取得モジュール510と、
取得モジュール510が取得した第1の状態情報及び取得モジュール510が取得した第1の能力情報に基づいて、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとする処理モジュール520であって、Nは、M以下であり且つ2以上の整数である、処理モジュール520と、
第2のデバイスに第1の構成情報を送信するように構成される送信モジュール530と、を含んでもよく、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。
この出願のこの実施形態におけるリンクグループ構成デバイスは、ソース端デバイスと受信端デバイスとの間のM個のリンクの間の差動遅延の状態及び受信端デバイスがM個のリンクに対して差動遅延補償を実行する能力に基づいて、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとする。このことは、M個のリンクの間の差動遅延が受信端デバイスの差動遅延補償能力を超えるときに、M個のリンクのうちのすべてが利用可能ではない場合を回避する。したがって、転送ネットワークにおけるリンクの利用可能性及び頑健性を改善することが可能である。
選択的に、ある1つの選択的な実施形態において、第1のデバイスは、受信端デバイスであり、第2のデバイスは、ソース端デバイスであり、取得モジュール510は、特に、M個のリンクの間の差動遅延を測定して、第1の状態情報を取得するように構成され、当該デバイス500は、第1の構成情報に基づいて、第1のリンクグループの中のリンクに対して差動遅延補償を実行するように構成される補償モジュール540と、第1のリンクグループに基づいて、第2のデバイスとのサービスデータの伝送を実行するように構成される伝送モジュール550と、をさらに含む。
選択的に、ある1つの選択的な実施形態において、取得モジュール510は、特に、受信端デバイスが送信する第1の状態情報を受信し、そして、受信端デバイスが送信する第1の能力情報を受信する、ように構成される。
選択的に、ある1つの選択的な実施形態において、第1のデバイスは、ソース端デバイスであり、第2のデバイスは、受信端デバイスであり、又は、第1のデバイスは、管理デバイスであり、第2のデバイスは、受信端デバイス及び/又はソース端デバイスを含む。
選択的に、ある1つの選択的な実施形態において、M個のリンクにある受信端デバイスのK個のアップストリームデバイスは、遅延送信補償能力を有し、Kは、正の整数であり、K個のアップストリームデバイスは、ソース端デバイス及び/又は少なくとも1つの中間デバイスを含み、中間デバイスは、M個のリンクのソース端デバイスと受信端デバイスとの間に位置する。取得モジュール510は、さらに、K個のアップストリームデバイスの各々の第2の能力情報及び第2の状態情報を取得するように構成され、第2の能力情報は、各々のアップストリームデバイスがM個のリンクのうちの少なくとも1つに対して遅延送信補償を実行する第2の能力を示すのに使用され、第2の状態情報は、各々のアップストリームデバイスがM個のリンクのうちの少なくとも1つに対して実行する遅延送信補償の現在の状態を示すのに使用される。処理モジュール520は、特に、第1の状態情報、第1の能力情報、第2の状態情報、及び第2の能力情報に基づいて、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとするように構成される。処理モジュール520は、さらに、第1の状態情報、第1の能力情報、第2の状態情報、及び第2の能力情報に基づいて、各々のアップストリームデバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を決定するように構成される。
受信端デバイスにおいてM個のリンクを整列させることが不可能であるときに、それらのM個のリンクは、リンクグループを構成することができない、具体的にいうと、FlexEグループ又はFlexOグループは、機能停止し、そして、動作することができないということを理解すべきである。この出願の複数の実施形態におけるソース端デバイス、受信端デバイス、及び中間デバイス等は、すべてが、差動遅延補償能力又は遅延送信補償能力を有してもよい。この出願のそれらの複数の実施形態におけるデバイスは、能力交渉によってリンクグループ補償を実装する。ソース端デバイスと受信端デバイスとの間のFlexEグループ又はFlexOグループの中の各々のデバイスの補償能力が、複数のリンクの間の差動遅延を補償するのに十分ではないときに、リンクグループを構成し、それによって、ソース端デバイスは、遅延整列リンクに対してのみクロスリンクサービスデータ伝送を実行する。代替的に、デバイスは、協調的な補償を実行し、それによって、最終的に受信端デバイスにおいてM個のリンクを整列させることが可能となる。このことは、FlexEグループ又はFlexOグループの動作を保証することを可能とし、リンクの利用を改善することが可能である。
選択的に、ある1つの選択的な実施形態において、第1のデバイスは、受信端デバイスであり、第2のデバイスは、ソース端デバイスであり、取得モジュール510は、特に、M個のリンクの間の差動遅延を測定して、第1の状態情報を取得し、そして、各々のアップストリームデバイスが送信する第2の能力情報及び第2の状態情報を受信する、ように構成され、送信モジュール530は、さらに、K個のアップストリームデバイスのうちの少なくとも1つに、第2の構成情報を送信するように構成され、第2の構成情報は、少なくとも1つのアップストリームデバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される。
選択的に、ある1つの選択的な実施形態において、当該デバイス500は、第1のリンクグループのうちで、少なくとも1つのアップストリームデバイスが第2の構成情報に基づいて遅延送信補償を実行しているリンクに対して、第1の構成情報に基づいて差動遅延補償を実行するように構成される補償モジュール540と、第1のリンクグループに基づいて、第2のデバイスとのサービスデータの伝送を実行するように構成される伝送モジュール550と、をさらに含んでもよい。
選択的に、ある1つの選択的な実施形態において、第1のデバイスは、ソース端デバイスであり、第2のデバイスは、受信端デバイスであり、取得モジュール510は、特に、受信端デバイスが送信する第1の状態情報を受信し、そして、受信端デバイスが送信する第1の能力情報を受信する、ように構成される。
選択的に、ある1つの選択的な実施形態において、K個のアップストリームデバイスは、第1のデバイスを含み、当該デバイス500は、第1のリンクグループに基づいて、第1のデバイスが対応するリンクに対して実行する必要がある遅延送信補償の決定された構成に基づいて、第2のデバイスにサービスデータを伝送するように構成される伝送モジュール550をさらに含んでもよい。
選択的に、ある1つの選択的な実施形態において、K個のアップストリームデバイスは、少なくとも1つの中間デバイスを含み、取得モジュール510は、特に、少なくとも1つの中間デバイスの各々が送信する第2の能力情報及び第2の状態情報を受信するように構成され、送信モジュール530は、さらに、少なくとも1つの中間デバイスのうちの少なくとも複数の中間デバイスに第2の構成情報を送信するように構成され、第2の構成情報は、少なくとも複数の中間デバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される。
選択的に、ある1つの選択的な実施形態において、第1のデバイスは、管理デバイスであり、第2のデバイスは、受信端デバイス及び/又はソース端デバイスを含み、取得モジュール510は、特に、受信端デバイスが送信する第1の状態情報を受信し、受信端デバイスが送信する第1の能力情報を受信し、そして、各々のアップストリームデバイスが送信する第2の能力情報及び第2の状態情報を受信する、ように構成され、送信モジュール530は、さらに、K個のアップストリームデバイスのうちの少なくとも1つに第2の構成情報を送信するように構成され、第2の構成情報は、少なくとも1つのアップストリームデバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される。
選択的に、ある1つの選択的な実施形態において、第1の構成情報は、リンクが第1のリンクグループに属しているということを示すのに使用されるマークを含む。
選択的に、ある1つの選択的な実施形態において、送信モジュール530は、特に、オーバーヘッド符号ブロックの予約されているフィールドに第1の構成情報を追加し、そして、第2のデバイスに予約されているフィールドを送信する、ように構成されてもよい。
選択的に、ある1つの選択的な実施形態において、送信モジュール530は、特に、N個のリンクのうちの第1のリンクを使用することによって、第2のデバイスに第1の構成情報を送信するように構成されてもよく、第1の構成情報は、第1のリンクが第1のリンクグループに属しているということを示すのに使用される。
選択的に、ある1つの選択的な実施形態において、第1の構成情報の中のビットの第1の部分は、第1のリンク及び他のリンクが第1のリンクグループを構成するということを示すのに使用され、第1の構成情報の中のビットの第2の部分は、第1のリンクグループのマークである。
選択的に、ある1つの選択的な実施形態において、取得モジュール510は、特に、第1の状態情報を受信するように構成され、第1の状態情報は、受信端デバイスが送信するとともに、オーバーヘッド符号ブロックの管理チャネルのリンク層発見プロトコルLLDPフォーマットの中の第1のタイプ長値TLVユニットの中で搬送される。
選択的に、ある1つの選択的な実施形態において、第1のTLVユニットは、さらに、受信端デバイスがソース端デバイスにサービスデータを送信するときに、受信端デバイスがM個のリンクに対して実行する遅延送信補償の現在の状態を示すのに使用される情報を搬送することが可能である。
選択的に、ある1つの選択的な実施形態において、第1のTLVユニットは、さらに、アップストリームデバイスが対応するリンクに対して実行する必要がある遅延送信補償の構成を示すのに使用される情報を搬送することが可能である。
選択的に、ある1つの選択的な実施形態において、取得モジュール510は、特に、第1の能力情報を受信するように構成され、第1の能力情報は、受信端デバイスが送信するとともに、オーバーヘッド符号ブロックの管理チャネルのリンク層発見プロトコルLLDPフォーマットの第2のタイプ長値TLVユニットの中で搬送される。
選択的に、ある1つの選択的な実施形態において、第2のTLVユニットは、さらに、受信端デバイスがソース端デバイスにサービスデータを送信するときに、受信端デバイスがM個のリンクに対して遅延送信補償を実行する能力を示すのに使用される情報を搬送することが可能である。
プロセッサ又はプロセッサの関連する回路構成要素によって、この出願のこの実施形態における取得モジュール510の複数の機能のうちのいくつかを実装してもよく、ネットワークインターフェイス又はネットワークインターフェイスの関連する回路構成要素によって、取得モジュール510の複数の機能のうちのいくつかを実装してもよく、プロセッサ又はプロセッサの関連する回路構成要素によって、処理モジュール520を実装してもよく、ネットワークインターフェイス又はネットワークインターフェイスの関連する回路構成要素によって、送信モジュール530を実装してもよいということを理解すべきである。
図14に示されているように、この出願のある1つの実施形態は、さらに、リンクグループ構成デバイス600を提供する。リンクグループ構成デバイス600は、第1のデバイスである。リンクグループ構成デバイス600は、プロセッサ610、メモリ620、及びネットワークインターフェイス630を含む。メモリ620は、命令を格納するように構成される。プロセッサ610及びネットワークインターフェイス630は、メモリ620に格納されている命令を実行するように構成される。
リンクグループ構成デバイス600のプロセッサ610及びネットワークインターフェイス630が、メモリ620に格納されている命令を実行するときに、
第1のデバイスによって、ソース端デバイスと受信端デバイスとの間のM個のリンクの第1の状態情報を取得するステップであって、第1の状態情報は、M個のリンクのうちのいずれか2つの間の差動遅延の状態を示すのに使用され、M個のリンクのうちのいずれか1つは、フレキシブルイーサネットFlexE物理接続リンク又はフレキシブル光転送ネットワークFlexO物理接続リンクであり、Mは、2以上の整数である、ステップと、
第1のデバイスによって、受信端デバイスの第1の能力情報を取得するステップであって、第1の能力情報は、受信端デバイスがM個のリンクに対して差動遅延補償を実行する第1の能力を示すのに使用される、ステップと、
第1のデバイスによって、第1の状態情報及び第1の能力情報に基づいて、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとするステップであって、Nは、M以下であり且つ2以上の整数である、ステップと、
第1のデバイスによって第2のデバイスに、第1の構成情報を送信するステップと、を実装し、第1の構成情報は、第1のリンクグループを示すのに使用される情報を含む。
この出願のこの実施形態におけるリンクグループ構成デバイスは、ソース端デバイスと受信端デバイスとの間のM個のリンクの間の差動遅延の状態及び受信端デバイスがM個のリンクに対して差動遅延補償を実行する能力に基づいて、M個のリンクのうちのN個のリンクをグループ分けして、第1のリンクグループとする。このことは、M個のリンクの間の差動遅延が受信端デバイスの差動遅延補償能力を超えるときに、M個のリンクのうちのすべてが利用可能ではない場合を回避する。したがって、転送ネットワークにおけるリンクの利用可能性及び頑健性を改善することが可能である。
図13に示されているリンクグループ構成デバイス500又は図14に示されているリンクグループ構成デバイス600は、上記の方法の実施形態における端末デバイスに関連する動作又はプロセスを実行するように構成されてもよいということを理解すべきである。加えて、リンクグループ構成デバイス500又はリンクグループ構成デバイス600の中の各々のモジュールの動作及び/又は機能は、上記の方法の実施形態における対応するプロセスを実装するための動作及び/又は機能である。簡潔さのために、本明細書においては、詳細は繰り返しては説明されない。
本発明の複数の実施形態におけるプロセッサは、中央処理ユニット(Central Processing Unit, CPU)であってもよく、或いは、他の汎用プロセッサ、ディジタル信号プロセッサ(Digital Signal Processor, DSP)、特定用途向け集積回路(Application-Specific Integrated Circuit, ASIC)、フィールドプログラマブルゲートアレイ(Field Programmable Gate Array, FPGA)又は他のプログラム可能な論理デバイス、個別のゲート又はトランジスタ論理デバイス、又は、個別のハードウェア構成要素等であってもよいということを理解すべきである。汎用プロセッサは、マイクロプロセッサであってもよく、或いは、プロセッサは、いずれか従来のプロセッサ等であってもよい。
本発明の複数の実施形態におけるメモリは、揮発性メモリ又は不揮発性メモリであってもよく、或いは、揮発性メモリ及び不揮発性メモリの双方を含んでいてもよいということをさらに理解すべきである。不揮発性メモリは、読み取り専用メモリ(Read-Only Memory, ROM)、プログラム可能なROM(Programmable ROM, PROM)、消去可能且つプログラム可能な読み取り専用メモリ(Erasable PROM, EPROM)、電気的に消去可能且つプログラム可能な読み取り専用メモリ(Electrically EPROM, EEPROM)、又はフラッシュメモリであってもよい。揮発性メモリは、ランダムアクセスメモリ(Random Access Memory, RAM)であってもよく、外部キャッシュとして使用される。限定的ではなく例示的な説明によって、例えば、静的なランダムアクセスメモリ(Static RAM, SRAM)、動的なランダムアクセスメモリ(Dynamic RAM, DRAM)、同期的な且つ動的なランダムアクセスメモリ(Synchronous DRAM, SDRAM)、ダブルデータレートの同期的な且つ動的なランダムアクセスメモリ(Double Data Rate SDRAM, DDR SDRAM)、強化型の同期的な且つ動的なランダムアクセスメモリ(Enhanced SDRAM, ESDRAM)、同期リンクDRAM(Synchlink DRAM, SLDRAM)、及び直接的なメモリバスランダムアクセスメモリ(Direct Rambus RAM, DR RAM)等の複数の形態のRAMを使用することが可能である。
プロセッサが、汎用プロセッサ、DSP、ASIC、FPGA又は他のプログラム可能な論理デバイス、個別のゲート又はトランジスタ論理デバイス、又は、個別のハードウェア構成要素であるときは、メモリ(記憶モジュール)は、一体化されて、プロセッサとなるということを理解すべきである。
本明細書において説明されるメモリは、これらには限定されないが、これらのメモリ及びいずれか他の適切なタイプのメモリを含むべきであるということに留意すべきである。
本発明のある1つの実施形態は、さらに、コンピュータ読み取り可能な記憶媒体を提供する。コンピュータ読み取り可能な記憶媒体は、命令を格納する。その命令がコンピュータによって実行されるときに、そのコンピュータは、上記の方法の実施形態におけるリンクグループ構成方法を実行する。具体的には、コンピュータは、上記のリンクグループ構成デバイス、すなわち、第1のデバイスであってもよい。
本発明のある1つの実施形態は、さらに、命令を含むコンピュータプログラム製品を提供する。コンピュータがそのコンピュータプログラム製品の命令を実行するときに、そのコンピュータは、上記の方法の実施形態におけるリンクグループ構成方法を実行する。具体的には、コンピュータプログラム製品は、上記のリンクグループ構成デバイス、すなわち、第1のデバイスによって実行されてもよい。
ソフトウェア、ハードウェア、ファームウェア、又はそれらのいずれか組み合わせを使用することによって、上記の複数の実施形態のすべて又は一部を実装することが可能である。ソフトウェアを使用して、それらの複数の実施形態を実装するときに、それらの複数の実施形態は、完全に又は部分的に、コンピュータプログラム製品の形態で実装されてもよい。コンピュータプログラム製品は、1つ又は複数のコンピュータ命令を含む。コンピュータ命令が、コンピュータによってロードされ、そして、実行されるときに、この出願の複数の実施形態にしたがったプロセス又は機能のすべて又は一部が生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、又は他のプログラム可能な装置であってもよい。コンピュータ命令は、コンピュータ読み取り可能な記憶媒体の中に格納されていてもよく、又は、コンピュータ読み取り可能な記憶媒体から他のコンピュータ読み取り可能な記憶媒体に伝送されてもよい。例えば、(例えば、同軸ケーブル、光ファイバ、又はディジタル加入者線(Digital Subscriber Line, DSL)等の)有線方式によって又は(例えば、赤外線、無線、又はマイクロ波等の)無線方式によって、ウェブサイト、コンピュータ、サーバ、又はデータセンターから他のウェブサイト、他のコンピュータ、他のサーバ、又は他のデータセンターに、コンピュータ命令を伝送してもよい。コンピュータ読み取り可能な記憶媒体は、コンピュータによってアクセス可能ないずれかの使用可能な媒体であってもよく、或いは、1つ又は複数の使用可能な媒体を組み込んであるサーバ又はデータセンター等のデータ記憶デバイスであってもよい。使用可能な媒体は、(例えば、フロッピーディスク、ハードディスク、又は磁気テープ等の)磁気媒体、(例えば、高密度ディジタルビデオディスク(Digital Video Disc, DVD)等の)光媒体、(例えば、ソリッドステートディスク(Solid Status Disk, SSD)等の)半導体媒体等であってもよい。
本明細書の中の"第1の"、"第2の"、及びさまざまな番号は、説明を容易にするための判別を意図しているにすぎず、この出願の範囲を限定することを意図してはいないということを理解すべきである。
本明細書の中の"及び/又は"の語は、複数の関連する対象物を説明するための結合的な関係を示しているにすぎず、3つの関係が存在していてもよいということを示すということを理解すべきである。例えば、A及び/又はBは、Aのみが存在する、A及びBの双方が存在する、Bのみが存在する、の3つの場合を示してもよい。加えて、この明細書の中の記号"/"は、通常は、前者の関連する対象物と後者の関連する対象物との間に"又は"の関係が存在しているということを示す。
この出願の複数の実施形態において、上記の複数のプロセスの順序番号は、実行順序を示すものではないということを理解すべきである。それらの複数のプロセスの実行順序は、それらの複数のプロセスの複数の機能及び内部論理に基づいて決定されるべきであり、本発明の複数の実施形態の実装プロセスに対するいかなる制限も構成するべきではない。
当業者は、電子的なハードウェアによって、又は、コンピュータソフトウェア及び電子的なハードウェアの組み合わせによって、本明細書の中で開示されている複数の実施形態を参照して説明されている複数の例の中のユニット及びアルゴリズムのステップを実装することが可能であるということを認識することが可能である。それらの複数の機能が、ハードウェアによって実行されるか又はソフトウェアによって実行されるかは、技術的解決方法の特定の用途及び設計上の制約条件によって決まる。当業者は、複数の異なる方法を使用して、各々の特定の用途のために、説明されている複数の機能を実装してもよく、そのような実装は、この出願の範囲を超えると解釈されるべきではない。
当業者は、説明の容易さ及び簡潔さのために、上記のシステム、装置、及びユニットの詳細な動作プロセスについては、上記の方法の実施形態における対応するプロセスを参照してもよいということを明確に理解することが可能であり、本明細書においては、詳細は繰り返しては説明されない。
この出願によって提供される複数の実施形態のうちのいくつかにおいて、他の方式によって、開示されているシステム、装置、及び方法を、実装することが可能であるということを理解すべきである。例えば、説明されている装置の実施形態は、ある1つの例であるにすぎない。例えば、ユニットの分割は、論理的な機能の分割であるにすぎす、実際の実装においては他の分割であってもよい。例えば、複数のユニット又は構成要素を組み合わせ、又は、一体化して、他のシステムとしてもよく、又は、いくつかの特徴を無視してもよく、又は実行しなくてもよい。加えて、いくつかのインターフェイスを使用することによって、示され又は説明されている相互の結合、直接的な結合、又は通信接続を実装することが可能である。電気的な形態、機械的な形態、又は他の形態で、複数の装置又は複数のユニットの間の非直接的な結合又は通信接続を実装することが可能である。
複数の個別の部分として説明されている複数のユニットは、物理的に分離されていてもよく、又は、物理的に分離されていなくてもよく、複数のユニットとして示されている複数の部分は、複数の物理的なユニットであってもよく、又は、複数の物理的なユニットでなくてもよく、1つの場所に位置していてもよく、又は、複数のネットワークユニットに分散されていてもよい。実際の要件に応じて、複数のユニットのうちのいくつか又はすべてを選択して、複数の実施形態の複数の解決方法の複数の目的を達成してもよい。
加えて、この出願の複数の実施形態における複数の機能ユニットを一体化して、1つの処理ユニットとしてもよく、又は、複数のユニットのうちの各々のユニットは、物理的に単独で存在してもよく、又は、2つ又はそれ以上のユニットを一体化して、1つのユニットとしてもよい。
上記の説明は、この出願の具体的な実装であるにすぎず、この出願の保護の範囲を限定することを意図してはいない。この出願によって開示されている技術的範囲の中で、当業者が容易に理解することが可能であるいずれかの変更又は置換は、この出願の保護の範囲に含まれるものとする。したがって、この出願の保護の範囲は、特許請求の範囲の保護の範囲にしたがうものとする。