特許 6608545 サービストラヒック分配方法及び装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6608545

(24)【登録日】2019年11月1日

(45)【発行日】2019年11月20日

(54)【発明の名称】サービストラヒック分配方法及び装置

(51)【国際特許分類】

   H04L 12/803 20130101AFI20191111BHJP

   H04L 12/725 20130101ALI20191111BHJP

【ＦＩ】

   H04L12/803

   H04L12/725

【請求項の数】13

【全頁数】30

(21)【出願番号】特願2018-557175(P2018-557175)

(86)(22)【出願日】2017年1月9日

(65)【公表番号】特表2019-503153(P2019-503153A)

(43)【公表日】2019年1月31日

(86)【国際出願番号】CN2017070658

(87)【国際公開番号】WO2017128945

(87)【国際公開日】20170803

【審査請求日】2018年7月25日

(31)【優先権主張番号】201610051922.4

(32)【優先日】2016年1月26日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】ジュ ウェンビン

(72)【発明者】

【氏名】ヤオ シェジュン

【審査官】 羽岡 さやか

(56)【参考文献】

【文献】 特開２０１２−１２４７２０（ＪＰ，Ａ）

【文献】 特開２００５−０５７５１４（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１０／０１４９９７９（ＵＳ，Ａ１）

【文献】 特開２００１−２９８４８２（ＪＰ，Ａ）

【文献】 特開２０１４−１７０９８８（ＪＰ，Ａ）

【文献】 特開２０１２−８０３９４（ＪＰ，Ａ）

【文献】 渡辺 正徳，ロードバランス機能，東芝技術公開集，日本，株式会社東芝，２００２年 １月２１日，VOL.20-2，P65-73

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／００−１２／９５５

(57)【特許請求の範囲】

【請求項1】

第１のリーフノードにより、バックボーンノードに接続された前記第１のリーフノードの複数の物理リンクのそれぞれを通じてプローブパケットを繰り返し送信するステップと、
物理リンク毎に、前記第１のリーフノードにより、前記物理リンクを通じて返信された応答パケットを受信するステップであり、各応答パケットは、物理リンクを通じて送信されたプローブパケットが第２のリーフノードに到達した後に、前記第２のリーフノードにより返信されるステップと、
パス毎に、前記第１のリーフノードにより、各パスの伝送パラメータを取得するために、前記パス上で受信した複数の応答パケットに従って、前記パスの前記伝送パラメータを計算するステップであり、同じパス上で受信した応答パケットは、同じパス識別子を含み、各パスは、少なくとも２つの物理リンクを含み、前記複数の物理リンクは、異なるパスに属するステップと、
前記第１のリーフノードにより、各パスの前記伝送パラメータ及び伝送対象のサービストラヒックの伝送要件に従って、前記伝送対象のサービストラヒックを前記複数の物理リンクに分配するステップと
を含むサービストラヒック分配方法。

【請求項2】

前記第１のリーフノードにより、各パスの前記伝送パラメータに従って、伝送対象のサービストラヒックを前記複数の物理リンクに分配するステップは、
前記第１のリーフノードにより、各パスの前記伝送パラメータに従って、各パスのサービストラヒック分配比を決定するステップと、
前記第１のリーフノードにより、各パスの前記サービストラヒック分配比に従って、前記伝送対象のサービストラヒックを前記複数の物理リンクに分配するステップと
を含む、請求項１に記載の分配方法。

【請求項3】

前記パスの前記伝送パラメータは、前記パスの待ち時間、前記パスのジッタ又は前記パスのパケットロス率のうち少なくとも１つを含む、請求項１又は２に記載の分配方法。

【請求項4】

前記第１のリーフノードにより、前記パス上で受信した複数の応答パケットに従って、前記パスの伝送パラメータを計算する前に、前記方法は、
前記第１のリーフノードにより、受信した応答パケットに含まれるパス識別子に従って、前記パス上で受信した前記応答パケットを決定し、前記パス上で受信した前記複数の応答パケットを取得するステップを更に含み、
前記第１のリーフノードにより、前記パス上で受信した複数の応答パケットに従って、前記パスの伝送パラメータを計算するステップは、
前記第１のリーフノードにより、前記パス上で受信した前記複数の応答パケットのパケット特性に従って、前記パスの前記伝送パラメータを計算するステップを含む、請求項１乃至３のうちいずれか１項に記載の分配方法。

【請求項5】

前記パス上で受信した前記複数の応答パケットのそれぞれのパケット特性は、前記パスの識別子と、前記応答パケットのシーケンス番号と、前記応答パケットの送信元インターネットプロトコル（IP）アドレスと、前記応答パケットの宛先IPアドレスと、前記応答パケットのレイヤ４送信元ポート番号と、前記応答パケットのレイヤ４宛先ポート番号と、前記応答パケットが前記第１のリーフノードに到達した時間と、前記応答パケットに対応するプローブパケットが前記第１のリーフノードを出発した時間とを含む、請求項４に記載の分配方法。

【請求項6】

前記第１のリーフノードにより、各パスの前記伝送パラメータに従って、各パスのサービストラヒック分配比を決定するステップは、
前記第１のリーフノードにより、各パスの前記伝送パラメータを量子化するステップと、
前記第１のリーフノードにより、各パスの前記量子化された伝送パラメータに従って、各パスの前記サービストラヒック分配比を決定するステップと
を含む、請求項２に記載の分配方法。

【請求項7】

第１のリーフノードであるサービストラヒック分配装置であって、
バックボーンノードに接続された前記第１のリーフノードの複数の物理リンクのそれぞれを通じてプローブパケットを繰り返し送信するように構成された送信ユニットと、
物理リンク毎に、前記物理リンクを通じて返信された応答パケットを受信するように構成された受信ユニットであり、各応答パケットは、物理リンクを通じて送信されたプローブパケットが第２のリーフノードに到達した後に、前記第２のリーフノードにより返信される受信ユニットと、
パス毎に、各パスの伝送パラメータを取得するために、前記受信ユニットにより前記パス上で受信した複数の応答パケットに従って、前記パスの前記伝送パラメータを計算するように構成された計算ユニットであり、同じパス上で受信した応答パケットは、同じパス識別子を含み、各パスは、少なくとも２つの物理リンクを含み、前記複数の物理リンクは、異なるパスに属する計算ユニットと、
前記計算ユニットにより計算された各パスの前記伝送パラメータ及び伝送対象のサービストラヒックの伝送要件に従って、前記伝送対象のサービストラヒックを前記複数の物理リンクに分配するように構成された分配ユニットと
を含む分配装置。

【請求項8】

前記分配ユニットは、前記計算ユニットにより計算された各パスの前記伝送パラメータに従って、各パスのサービストラヒック分配比を決定し、各パスの前記サービストラヒック分配比に従って、前記伝送対象のサービストラヒックを前記複数の物理リンクに分配するように構成される、請求項７に記載の分配装置。

【請求項9】

前記パスの前記伝送パラメータは、前記パスの待ち時間、前記パスのジッタ又は前記パスのパケットロス率のうち少なくとも１つを含む、請求項７又は８に記載の分配装置。

【請求項10】

前記分配装置は、決定ユニットを更に含み、
前記決定ユニットは、前記計算ユニットが前記パス上で受信した前記複数の応答パケットに従って、前記パスの前記伝送パラメータを計算する前に、前記受信ユニットにより受信した応答パケットに含まれるパス識別子に従って、前記パス上で受信した前記応答パケットを決定し、前記パス上で受信した前記複数の応答パケットを取得するように構成され、
前記計算ユニットは、前記パス上で受信し且つ前記決定ユニットにより決定された前記複数の応答パケットのパケット特性に従って、前記パスの前記伝送パラメータを計算するように構成される、請求項７乃至９のうちいずれか１項に記載の分配装置。

【請求項11】

前記受信ユニットにより前記パス上で受信した前記複数の応答パケットのそれぞれのパケット特性は、前記パスの識別子と、前記応答パケットのシーケンス番号と、前記応答パケットの送信元インターネットプロトコル（IP）アドレスと、前記応答パケットの宛先IPアドレスと、前記応答パケットのレイヤ４送信元ポート番号と、前記応答パケットのレイヤ４宛先ポート番号と、前記応答パケットが前記第１のリーフノードに到達した時間と、前記応答パケットに対応するプローブパケットが前記第１のリーフノードを出発した時間とを含む、請求項１０に記載の分配装置。

【請求項12】

前記分配ユニットは、前記計算ユニットにより計算された各パスの前記伝送パラメータを量子化し、各パスの前記量子化された伝送パラメータに従って、各パスの前記サービストラヒック分配比を決定するように構成される、請求項８に記載の分配装置。

【請求項13】

第１のリーフノードであるサービストラヒック分配装置であり、前記第１のリーフノードは、スイッチであり、前記スイッチは、プロセッサと、メモリとを含むサービストラヒック分配装置であって、
前記メモリは、コンピュータプログラム命令を記憶するように構成され、前記スイッチが動作するときに、前記プロセッサは、前記メモリに記憶された前記コンピュータプログラム命令を実行し、それにより、前記スイッチは、請求項１乃至６のうちいずれか１項に記載の分配方法を実行するサービストラヒック分配装置。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願への相互参照］
この出願は、2016年1月26日に「SERVICE TRAFFIC ALLOCATION METHOD AND APPARATUS」という名称で中国特許庁に出願された中国特許出願第201610051922.4号の優先権を主張し、その全内容を参照により援用する。

【0002】

［技術分野］
本発明は、通信分野に関し、特にサービストラヒック分配方法及び装置に関する。

【背景技術】

【0003】

レイヤ２リーフ・スパイン（英語：leaf-spine）トポロジアーキテクチャを使用したデータセンタネットワークでは、データセンタネットワークの信頼性及びサービス品質を改善するために、通常では、複数の物理リンクがスイッチとサーバとの間に設定される。サービストラヒックが複数の物理リンク上で同時に伝送されることを可能にするために、通常では、複数の物理リンクは、１つの論理リンクに集約される。論理リンクは、リンクアグリゲーショングループ（英語：link aggregation group, 略称：LAG）と呼ばれることがある。

【0004】

データセンタネットワーク内のいくつかの物理リンク上の輻輳のため、パケットが破棄されるのを防止するために、通常では、サービストラヒックは、LAG内の各物理リンクに均等に分配される必要がある。具体的には、図１に示すように、サーバ1がリーフノード2とバックボーンノード3とリーフノード4とを使用することにより、パケットをサーバ5に送信する必要があると仮定する。リーフノード2がサーバ1により送信されたパケットを受信した後に、リーフノード2が、リーフノード2に記憶されたフローテーブル内に、パケットが属するサービスフローに対応するエントリ（サービスフローの識別子と、アウトバウンドと、サービスフローの第１のパケットがリーフノード2に到達したタイムスタンプとを含む）を見つけた場合、リーフノード2は、エントリ内のアウトバウンドインタフェースを使用することによりパケットを送信する。リーフノード2がフローテーブル内にエントリを見つけなかった場合、リーフノード2は、リーフノード2によりサポートされる物理リンクの帯域幅利用率及びキュー長に従って、パケットのための最適な物理リンク（例えば、最低の帯域幅利用率及び最低のキュー占有率を有する物理リンク）を選択し、物理リンクのアウトバウンドインタフェースを使用することによりパケットを送信し、パケットが属するサービスフローに対応するエントリを前述のフローテーブルに追加してもよい。

【0005】

しかし、前述のサービスフロー分配方法では、リーフノード2は、リーフノード2の物理リンクの帯域幅利用率及びキュー長のみに従って、転送される必要があるパケットのための最適な物理リンクを選択できる。すなわち、リーフノード2は、リーフノード2の物理リンク上のサービストラヒックのみが均衡していることを確保でき、さらに、パケットは、バックボーンノード3を通じてリーフノード4に送信される必要がある。したがって、バックボーンノード3とリーフノード4との間の物理リンクが輻輳しているときに、パケットは、バックボーンノード3とリーフノード4との間の物理リンク上で失われる可能性がある。

【発明の概要】

【0006】

本発明の実施例は、送信元ノードと宛先ノードとの間のパス上のサービストラヒックが均衡していることを確保し、それにより、パケットが失われないことを確保するためのサービストラヒック分配方法及び装置を提供する。

【0007】

前述の目的を達成するために、以下の技術的解決策が本発明の実施例において使用される。

【0008】

第１の態様によれば、本発明の実施例は、サービストラヒック分配方法を提供する。分配方法は、
第１のリーフノードにより、バックボーンノードに接続された第１のリーフノードの複数の物理リンクのそれぞれを通じてプローブパケットを周期的に送信するステップと、
物理リンク毎に、第１のリーフノードにより、物理リンクを通じて返信された応答パケットを受信するステップであり、各応答パケットは、物理リンクを通じて送信されたプローブパケットが第２のリーフノードに到達した後に、第２のリーフノードにより返信されるステップと、
パス毎に、第１のリーフノードにより、各パスの伝送パラメータを取得するために、パス上で受信した複数の応答パケットに従って、パスの伝送パラメータを計算するステップであり、同じパス上で受信した応答パケットは、同じパス識別子を含み、各パスは、少なくとも２つの物理リンクを含み、複数の物理リンクは、異なるパスに属するステップと、
第１のリーフノードにより、各パスの伝送パラメータに従って、伝送対象のサービストラヒックを複数の物理リンクに分配するステップと
を含む。

【0009】

本発明のこの実施例において提供されるサービストラヒック分配方法によれば、第１のリーフノードは、プローブパケットを送信することにより、第１のリーフノードと第２のリーフノードとの間の全てのパスの伝送パラメータを検出できる。したがって、第１のリーフノードは、次に、パスの伝送パラメータに従って、伝送対象のサービストラヒックを分配する。これは、第１のリーフノードの物理リンク上のサービストラヒックが均衡していることを確保できるだけでなく、パスのそれぞれの上の他の物理リンク上のサービストラヒックが均衡していることも確保でき、それにより、送信元ノード（例えば、第１のリーフノード）と宛先ノード（例えば、第２のリーフノード）との間のパス上のサービストラヒックが均衡していることを確保し、パケットが失われないことを更に確保する。

【0010】

任意選択で、本発明の実施例では、第１のリーフノードにより、各パスの伝送パラメータに従って、伝送対象のサービストラヒックを複数の物理リンクに分配するステップは、
第１のリーフノードにより、各パスの伝送パラメータに従って、各パスのサービストラヒック分配比を決定するステップと、
第１のリーフノードにより、各パスのサービストラヒック分配比に従って、伝送対象のサービストラヒックを複数の物理リンクに分配するステップと
を含む。

【0011】

第１のリーフノードにより決定されたサービストラヒック分配比は、第１のリーフノードと第２のリーフノードとの間の全てのパスのサービストラヒック分配比である（各パスは複数の物理リンクを含む）。したがって、伝送対象のサービストラヒックを伝送するときに、第１のリーフノードは、サービストラヒック分配比に従って、対応する伝送対象のサービストラヒックを第１のリーフノードの複数の物理リンクに分配してもよい。このように、第１のリーフノードの各物理リンク上のサービストラヒックが均衡していることが確保できるだけでなく、第１のリーフノードと第２のリーフノードとの間の全てのパスのそれぞれの上の他の物理リンク上のサービストラヒックも均衡していることを確保でき、第１のリーフノードから第２のリーフノードへの伝送中にパケットが失われないことを更に防止する。

【0012】

任意選択で、本発明の実施例では、パスの伝送パラメータは、パスの待ち時間、パスのジッタ又はパスのパケットロス率のうち少なくとも１つを含む。

【0013】

例えば、第１のリーフノードと第２のリーフノードとの間に複数のパスが存在すると仮定する。第１のリーフノードが複数のパスの伝送パラメータを計算したときに、第１のリーフノードにより計算された伝送パラメータはパス毎に同じである。例えば、第１のリーフノードは、複数のパスについて同じ種類の伝送パラメータを別々に計算する。

【0014】

任意選択で、本発明の実施例では、第１のリーフノードにより、パス上で受信した複数の応答パケットに従って、パスの伝送パラメータを計算する前に、方法は、
第１のリーフノードにより、受信した応答パケットに含まれるパス識別子に従って、パス上で受信した応答パケットを決定し、パス上で受信した複数の応答パケットを取得するステップを更に含み、
第１のリーフノードにより、パス上で受信した複数の応答パケットに従って、パスの伝送パラメータを計算するステップは、
第１のリーフノードにより、パス上で受信した複数の応答パケットのパケット特性に従って、パスの伝送パラメータを計算するステップを含む。

【0015】

任意選択で、本発明の実施例では、パス上で受信した複数の応答パケットのそれぞれのパケット特性は、パスの識別子と、応答パケットのシーケンス番号と、応答パケットの送信元インターネットプロトコルIPアドレスと、応答パケットの宛先IPアドレスと、応答パケットのレイヤ４送信元ポート番号と、応答パケットのレイヤ４宛先ポート番号と、応答パケットが第１のリーフノードに到達した時間と、応答パケットに対応するプローブパケットが第１のリーフノードを出発した時間とを含む。

【0016】

各応答パケットに含まれるパス識別子は、応答パケットが伝送されるパスを識別するために使用されてもよい。例えば、パス識別子は、応答パケットに対応するプローブパケットを送信したデバイス（例えば、本発明のこの実施例における第１のリーフノード）のインタフェース名又はデバイスのインタフェース識別子と、ハッシュ値とを含んでもよい。ハッシュ値は、パスにおいて第１のリーフノードとバックボーンノードとの間の物理リンク以外の他の物理リンクを表すために使用されてもよい。ハッシュ値は、ネットワーク配置が完了した後に、第１のリーフノードにより、ハッシュアルゴリズムを使用することにより、第１のリーフノードと第２のリーフノードとの間にあり且つ第１のリーフノードによりトラバース（traverse）される全てのパスに従って計算される。

【0017】

パス上で受信した応答パケットは、パスの伝送パラメータを決定するために使用されてもよい。したがって、第１のリーフノードは、各パス上で受信され且つ第１のリーフノードにより決定された複数の応答パケットのパケット特性に従って、パスの伝送パラメータを別々に計算してもよい。このように、パス毎の計算を実行した後に、第１のリーフノードは、各パスの伝送パラメータを取得してもよい。

【0018】

任意選択で、本発明の実施例では、第１のリーフノードにより、各パスの伝送パラメータに従って、各パスのサービストラヒック分配比を決定するステップは、
第１のリーフノードにより、各パスの伝送パラメータを量子化するステップと、
第１のリーフノードにより、各パスの量子化された伝送パラメータに従って、各パスのサービストラヒック分配比を決定するステップと
を含む。

【0019】

本発明のこの実施例では、第１のリーフノードは、各パスの伝送パラメータを量子化し、次に、第１のリーフノードは、各パスの量子化された伝送パラメータに従って、各パスのサービストラヒック分配比を決定し、それにより、サービストラヒック分配比を決定するプロセスを簡略化し、実現の複雑性を低減する。

【0020】

任意選択で、本発明の実施例では、第１のリーフノードにより、各パスの量子化された伝送パラメータに従って、各パスのサービストラヒック分配比を決定するための方法は、以下の方式のいずれかで実現されてもよい。

【0021】

(1)第１のリーフノードは、パスを単位として使用し、各パスの量子化された伝送パラメータを加算し、各パスの総伝送パラメータを取得する。次に、第１のリーフノードは、各パスの総伝送パラメータに従って、各パスのサービストラヒック分配比を決定する。

【0022】

(2)第１のリーフノードは、パスを単位として使用し、各パスのそれぞれの量子化された伝送パラメータの3ビットを１つの系列に接合し、系列の値は、各パスの総伝送パラメータを表してもよい。次に、第１のリーフノードは、各パスの総伝送パラメータに従って、各パスのサービストラヒック分配比を決定する。

【0023】

サービストラヒック分配比を決定するための方法の前述の２つの方式によれば、各パスのサービストラヒック分配比は、より柔軟且つより便利に決定でき、それにより、本発明のこの実施例において提供されるサービストラヒック分配方法を柔軟且つ便利に実現する。

【0024】

任意選択で、本発明の実施例では、第１のリーフノードは、前述のサービストラヒック分配方法を繰り返してもよい。このように、第１のリーフノードは、第１のリーフノードと第２のリーフノードとの間の全てのパスの伝送パラメータをリアルタイムに決定できる。したがって、第１のリーフノードにより、伝送パラメータに従って、伝送対象のサービストラヒックを第１のリーフノードの複数の物理リンクに分配する精度が改善できる。

【0025】

第２の態様によれば、本発明の実施例は、サービストラヒック分配装置を提供し、分配装置は、第１のリーフノードであり、分配装置は、
バックボーンノードに接続された第１のリーフノードの複数の物理リンクのそれぞれを通じてプローブパケットを周期的に送信するように構成された送信ユニットと、
物理リンク毎に、物理リンクを通じて返信された応答パケットを受信するように構成された受信ユニットであり、応答パケットは、物理リンクを通じて送信されたプローブパケットが第２のリーフノードに到達した後に、第２のリーフノードにより返信される受信ユニットと、
パス毎に、各パスの伝送パラメータを取得するために、受信ユニットによりパス上で受信した複数の応答パケットに従って、パスの伝送パラメータを計算するように構成された計算ユニットであり、同じパス上で受信した応答パケットは、同じパス識別子を含み、各パスは、少なくとも２つの物理リンクを含み、複数の物理リンクは、異なるパスに属する計算ユニットと、
計算ユニットにより計算された各パスの伝送パラメータに従って、伝送対象のサービストラヒックを複数の物理リンクに分配するように構成された分配ユニットと
を含む。

【0026】

本発明のこの実施例は、サービストラヒック分配装置を提供する。分配装置は、第１のリーフノードであり、第１のリーフノードは、プローブパケットを送信することにより、第１のリーフノードと第２のリーフノードとの間の全てのパスの伝送パラメータを検出してもよい。したがって、第１のリーフノードは、次に、パスの伝送パラメータに従って、伝送対象のサービストラヒックを分配する。これは、第１のリーフノードの物理リンク上のサービストラヒックが均衡していることを確保できるだけでなく、パスのそれぞれの上の他の物理リンク上のサービストラヒックが均衡していることも確保でき、それにより、送信元ノード（例えば、第１のリーフノード）と宛先ノード（例えば、第２のリーフノード）との間のパス上のサービストラヒックが均衡していることを確保し、パケットが失われないことを更に確保する。

【0027】

任意選択で、分配ユニットは、計算ユニットにより計算された各パスの伝送パラメータに従って、各パスのサービストラヒック分配比を決定し、各パスのサービストラヒック分配比に従って、伝送対象のサービストラヒックを複数の物理リンクに分配するように具体的に構成される。

【0028】

任意選択で、パスの伝送パラメータは、パスの待ち時間、パスのジッタ又はパスのパケットロス率のうち少なくとも１つを含む。

【0029】

任意選択で、分配装置は、決定ユニットを更に含み、
決定ユニットは、計算ユニットがパス上で受信した複数の応答パケットに従って、パスの伝送パラメータを計算する前に、受信ユニットにより受信した応答パケットに含まれるパス識別子に従って、パス上で受信した応答パケットを決定し、パス上で受信した複数の応答パケットを取得するように構成され、
計算ユニットは、パス上で受信し且つ決定ユニットにより決定された複数の応答パケットのパケット特性に従って、パスの伝送パラメータを計算するように具体的に構成される。

【0030】

任意選択で、受信ユニットによりパス上で受信した複数の応答パケットのそれぞれのパケット特性は、パスの識別子と、応答パケットのシーケンス番号と、応答パケットの送信元インターネットプロトコルIPアドレスと、応答パケットの宛先IPアドレスと、応答パケットのレイヤ４送信元ポート番号と、応答パケットのレイヤ４宛先ポート番号と、応答パケットが第１のリーフノードに到達した時間と、応答パケットに対応するプローブパケットが第１のリーフノードを出発した時間とを含む。

【0031】

任意選択で、分配ユニットは、計算ユニットにより計算された各パスの伝送パラメータを量子化し、各パスの量子化された伝送パラメータに従って、各パスのサービストラヒック分配比を決定するように具体的に構成される。

【0032】

前述の第２の態様の様々な任意選択の方式の技術的効果についての詳細な説明については、前述の第１の態様の対応する様々な任意選択の方式の技術的効果についての関係する説明を参照する。詳細はここでは再び説明しない。

【0033】

第３の態様によれば、本発明の実施例は、サービストラヒック分配装置を提供し、分配装置は、第１のリーフノードであり、第１のリーフノードは、スイッチであり、スイッチは、プロセッサと、インタフェース回路と、メモリと、システムバスとを含み、
メモリは、コンピュータプログラム命令を記憶するように構成され、プロセッサ、インタフェース回路及びメモリは、システムバスを使用することにより互いに接続され、スイッチが動作するときに、プロセッサは、メモリに記憶されたコンピュータプログラム命令を実行し、それにより、スイッチは、第１の態様又は前述の第１の態様の様々な任意選択の方式のうちいずれか１つによる分配方法を実行する。

【0034】

本発明の実施例は、サービストラヒック分配装置を提供する。分配装置は、第１のリーフノードであり、第１のリーフノードは、スイッチであり、スイッチは、プローブパケットを送信することにより、スイッチと他のスイッチとの間の全てのパスの伝送パラメータを検出してもよい。したがって、スイッチは、次に、パスの伝送パラメータに従って、伝送対象のサービストラヒックを分配する。これは、スイッチの物理リンク上のサービストラヒックが均衡していることを確保できるだけでなく、パスのそれぞれの上の他の物理リンク上のサービストラヒックが均衡していることも確保でき、それにより、スイッチと他のスイッチとの間のパス上のサービストラヒックが均衡していることを確保し、パケットが失われないことを更に確保する。

【図面の簡単な説明】

【0035】

本発明の実施例又は従来技術における技術的解決策をより明確に説明するために、以下に、実施例又は従来技術を説明するために必要な添付図面について簡単に説明する。

【図1】従来技術によるデータセンタネットワークの概略アーキテクチャ図である。

【図2】本発明の実施例によるデータセンタネットワークの概略アーキテクチャ図である。

【図3A】本発明の実施例によるサービストラヒック分配方法の概略図である。

【図3B】本発明の実施例によるサービストラヒック分配方法の概略図である。

【図4】本発明の実施例によるサービストラヒック分配装置の第１の概略構成図である。

【図5】本発明の実施例によるサービストラヒック分配装置の第２の概略構成図である。

【図6】本発明の実施例によるサービストラヒック分配装置の概略ハードウェア図である。

【発明を実施するための形態】

【0036】

この明細書における「／」という文字は、一般的に、関係する対象の間の「又は」の関係を示す。例えば、A／Bは、A又はBとして理解され得る。

【0037】

本発明の明細書及び特許請求の範囲において、「第１」及び「第２」という用語は、異なる対象の間を区別することを意図しており、対象の特定の順序を示すものではない。例えば、第１のリーフノード及び第２のリーフノードは、異なるリーフノードを区別するために使用され、リーフノードの特性の順序を記載するために使用されるものではない。

【0038】

本発明の説明において、「複数」は、特に指定のない限り、２つ以上を意味する。例えば、複数の物理リンクは、２つ以上の物理リンクを示す。

【0039】

さらに、本発明の説明において言及される「含む」、「有する」という用語又はこれらの他の変形は、非排他的包含をカバーすることを意図する。例えば、一連のステップ又はユニットを含むプロセス、方法、システム、プロダクト又はデバイスは、記載のステップ又はユニットに限定されず、任意選択で記載されていないステップ又はユニットを更に含むか、或いは任意選択でプロセス、方法、プロダクト又はデバイスの他の固有のステップ又はユニットを更に含む。

【0040】

さらに、本発明の実施例において、「例示的」又は「例えば」という言葉は、例、例示又は説明を与えることを表すために使用される。この出願において「例示的」又は「例えば」として記載される如何なる実施例又は設計方式も、他の実施例又は設計方式より好ましいこと又はより多くの利点を有することとして説明されるべきではない。正確には、「例示的」又は「例」等の言葉の使用は、具体的な方式の概念を提示することを意図する。

【0041】

本発明の以下の実施例で言及されるパスは、ネットワークパスである。例えば、第１のリーフノードと第２のリーフノードとの間のパスは、第１のリーフノードと第２のリーフノードとの間のネットワークパスである。

【0042】

以下に、本発明の実施例における添付図面を参照して、本発明の実施例における技術的解決策を明確且つ完全に説明する。明らかに、説明する実施例は、本発明の実施例の単なる一部であり、全部ではない。

【0043】

本発明の実施例において提供されるサービストラヒック分配方法は、データセンタネットワークに適用されてもよい。データセンタネットワークは、レイヤ２リーフ・スパイン・トポロジアーキテクチャを有するデータセンタネットワークでもよく、データセンタネットワークは、コアアグリゲーションアクセス（英語：core-aggregation-access）トポロジアーキテクチャを有するデータセンタネットワークでもよく、或いはより複雑なトポロジアーキテクチャを有する他のデータセンタネットワークでもよい。これは、本発明のこの実施例では具体的に限定されない。

【0044】

例えば、図２は、レイヤ２リーフ・スパイン・トポロジアーキテクチャを有するデータセンタネットワークを示す。説明を簡単にするために、図２には、データセンタネットワークが２つのサーバ（それぞれサーバ10及びサーバ11である）と、２つのリーフノード（それぞれリーフノード12及びリーフノード13である）と、２つのバックボーンノード（それぞれバックボーンノード14及びバックボーンノード15である）とを含む例が、単に例示的な説明のために使用される。

【0045】

図２に示すデータセンタネットワークにおいて、データセンタネットワークがサービストラヒックの均衡をサポートすることを可能にするために、通常では、ノードの間の複数の物理リンクは、１つの論理リンクに集約され、すなわち、LAGに集約されてもよい（例えば、図２に示すように、物理リンク(1)、物理リンク(2)、物理リンク(3)及び物理リンク(4)がLAGを形成し、物理リンク(5)、物理リンク(6)、物理リンク(7)及び物理リンク(8)がLAGを形成する）。本発明の実施例では、複数の物理リンクがLAGを形成する例が単に例示的な説明のために使用される点に留意すべきである。実際の用途では、複数の物理リンクは、等コストマルチパスルーティング（英語：equal cost multipath routing, 略称：ECMP）又は不等コストマルチパスルーティング（英語：unequal cost multipath routing, 略称：UCMP）を形成してもよい。これは、本発明の実施例では詳細に説明しない。

【0046】

図２に示すように、データセンタネットワークの信頼性及びサービス品質を改善するために、通常では、リーフノードは、複数のアクセススイッチを含むクラスタ（cluster）又はスタック（stack）でもよい。例えば、リーフノード12は、スイッチ120及びスイッチ121を含むクラスタ又はスタックであり、リーフノード13は、スイッチ130及びスイッチ131を含むクラスタ又はスタックである。この場合、サーバ10及びリーフノード12は、２つの物理リンクを使用することにより互いに接続されてもよい（一方の物理リンクがアクティブ物理リンクとして機能し、他方の物理リンクがスタンバイ物理リンクとして機能するか、或いはLAG負荷均衡方式が２つの物理リンクに使用される）。サーバ11及びリーフノード13もまた同様に、２つの物理リンクを使用することにより互いに接続される。サーバとリーフノードとの間のアクティブ物理リンクが故障したときに、伝送対象のサービスは、伝送のためにスタンバイ物理リンクに切り換えられてもよく、それにより、サービス伝送の連続性を確保する。リーフノード12は、複数の物理リンクを使用することにより、バックボーンノード14及びバックボーンノード15に接続される。リーフノード13もまた、複数の物理リンクを使用することにより、バックボーンノード14及びバックボーンノード15に接続される。サーバ10がサービストラヒックをサーバ11に送信する必要があるときに、サービストラヒックは、リーフノード12と、バックボーンノード14又はバックボーンノード15と、リーフノード13とにより転送及び共有される必要がある。例えば、リーフノード12がサーバ10により送信されたサービストラヒックを受信した後に、リーフノード12は、伝送のためにサービストラヒックを異なるパスに分配する必要があってもよい。各パスは、サービストラヒックがリーフノード12からリーフノード13に通過する必要がある複数の物理リンクを含む。

【0047】

例えば、図２において、サーバ10とリーフノード12内のスイッチ120との間の物理リンクはアクティブ物理リンクであると仮定する。サーバ10がアクティブ物理リンクを通じてサービストラヒックをリーフノード12に送信するときに、各リーフノードは複数の物理リンクを使用することにより２つのバックボーンノードに接続されているため、リーフノード12とリーフノード13との間に複数のパスが存在する。複数のパスは、それぞれ以下の通りである。
パス1：リーフノード12内のスイッチ120−バックボーンノード14−リーフノード13内のスイッチ130（すなわち、図２の物理リンク(1)+物理リンク(5)）、
パス2：リーフノード12内のスイッチ120−バックボーンノード14−リーフノード13内のスイッチ131（すなわち、図２の物理リンク(1)+物理リンク(6)）、
パス3：リーフノード12内のスイッチ120−バックボーンノード15−リーフノード13内のスイッチ130（すなわち、図２の物理リンク(2)+物理リンク(7)）、及び
パス4：リーフノード12内のスイッチ120−バックボーンノード15−リーフノード13内のスイッチ131（すなわち、図２の物理リンク(2)+物理リンク(8)）。

【0048】

当業者は、サーバ10とリーフノード12内のスイッチ121との間の物理リンクがアクティブ物理リンクであり、サーバ10がアクティブ物理リンクを通じてサービストラヒックをリーフノード12に送信するときに、リーフノード12とリーフノード13との間の複数のパスが、それぞれ以下の通りであることを理解し得る。
パス5：リーフノード12内のスイッチ121−バックボーンノード14−リーフノード13内のスイッチ130（すなわち、図２の物理リンク(3)+物理リンク(5)）、
パス6：リーフノード12内のスイッチ121−バックボーンノード14−リーフノード13内のスイッチ131（すなわち、図２の物理リンク(3)+物理リンク(6)）、
パス7：リーフノード12内のスイッチ121−バックボーンノード15−リーフノード13内のスイッチ130（すなわち、図２の物理リンク(4)+物理リンク(7)）、及び
パス8：リーフノード12内のスイッチ121−バックボーンノード15−リーフノード13内のスイッチ131（すなわち、図２の物理リンク(4)+物理リンク(8)）。

【0049】

図２において、リーフノード12とリーフノード13との間の各パスは、２つ（又は実際の用途では複数）の物理リンクを含み、従来技術では、リーフノード12は、リーフノード12の物理リンクの帯域幅利用率及びキュー長のみに従って、転送される必要があるサービストラヒック内のパケットのための最適な物理リンクを選択できる。したがって、リーフノード12は、リーフノード12の物理リンク上のサービストラヒックが均衡していることのみを確保できる。バックボーンノード14とリーフノード13との間、或いはバックボーンノード15とリーフノード13との間の物理リンクが輻輳しているときに、サービストラヒック内のパケットは、伝送中にリーフノード12からリーフノード13へのパス上で失われる可能性がある。

【0050】

この問題を解決するために、本発明の実施例は、サービストラヒック分配方法を提供する。分配方法では、第１のリーフノードは、プローブパケットを第２のリーフノードに送信する。プローブパケットを受信した第２のリーフノードは、次に、プローブパケットを送信した第１のリーフノードに応答パケットを返信する。第１のリーフノードは、各パスを通じて第１のリーフノードにより受信された応答パケットに従って、各パス（パスに含まれる複数の物理リンクを含む）の伝送パラメータを計算する。最後に、第１のリーフノードは、次に、各パスの計算された伝送パラメータに従って、伝送対象のサービストラヒックを第１のリーフノードの物理リンクに分配する。本発明のこの実施例において提供されるサービストラヒック分配方法によれば、リーフノードは、プローブパケットを送信することにより、リーフノードと他のリーフノードとの間の全てのパスの伝送パラメータを検出してもよい。したがって、リーフノードは、次に、パスの伝送パラメータに従って、伝送対象のサービストラヒックを分配する。これは、リーフノードの物理リンク上のサービストラヒックが均衡していることを確保できるだけでなく、パスのそれぞれの上の他の物理リンク上のサービストラヒックが均衡していることも確保でき、それにより、送信元ノード（例えば、第１のリーフノード）と宛先ノード（例えば、第２のリーフノード）との間のパス上のサービストラヒックが均衡していることを確保し、パケットが失われないことを更に確保する。

【0051】

図２に示すレイヤ２リーフ・スパイン・トポロジアーキテクチャを有するデータセンタネットワークに基づいて、本発明の実施例は、サービストラヒック分配方法を提供する。図３Ａ及び図３Ｂに示すように、サービストラヒック分配方法は以下のステップを含んでもよい。

【0052】

S101.第１のリーフノードは、バックボーンノードに接続された第１のリーフノードの複数の物理リンクのそれぞれを通じてプローブパケットを周期的に送信する。

【0053】

第１のリーフノードの複数の物理リンクは、第１のリーフノードと少なくとも１つのバックボーンノードのそれぞれとの間の物理リンクを含む。例えば、第１のリーフノードの複数の物理リンクは、図２に示す物理リンク(1)、物理リンク(2)、物理リンク(3)及び物理リンク(4)を具体的に含んでもよく、第１のリーフノードは、各送信周期において、物理リンク(1)、物理リンク(2)、物理リンク(3)及び物理リンク(4)を通じて別々にプローブパケットを送信し、すなわち、プローブパケットは４回送信される。

【0054】

例えば、本発明のこの実施例では、第１のリーフノードは、図２に示すデータセンタネットワーク内のリーフノード12でもよく、少なくとも１つのバックボーンノードは、図２に示すデータセンタネットワーク内のバックボーンノード14及びバックボーンノード15でもよい。

【0055】

本発明のこの実施例では、プローブパケットは、仮想拡張可能ローカルエリアネットワーク（英語：virtual extensible local area network, 略称：VXLAN）プロトコルをサポートするパケットでもよい。パケットの具体的なフォーマットは、従来技術におけるVXLANプロトコルパケットのフォーマットと同じであり、詳細は本発明のこの実施例では説明しない。

【0056】

任意選択で、本発明のこの実施例におけるプローブパケットを、通常では他の機能を有するプローブパケットと区別するために、本発明のこの実施例では、プローブパケットが送信元ノードと宛先ノードとの間のパスの伝送パラメータを検出するために使用されることを示すために、フラグがプローブパケット内に設定されてもよい。フラグは、実際の使用要件に従って設定されてもよい。これは、本発明では具体的に限定されない。

【0057】

S102.各バックボーンノードは、バックボーンノードに接続された各物理リンクを通じて第１のリーフノードにより送信されたプローブパケットを受信する。

【0058】

S103.各バックボーンノードは、第２のリーフノードに接続された物理リンクを通じて、バックボーンノードにより受信したプローブパケットを第２のリーフノードに別々に送信する。

【0059】

例えば、本発明のこの実施例では、第２のリーフノードは、図２に示すデータセンタネットワーク内のリーフノード13でもよい。

【0060】

本発明のこの実施例では、各バックボーンノードと第２のリーフノードとの間に複数の物理リンクが存在してもよい。したがって、複数の物理リンク上のサービストラヒックが均衡していることを可能にするために、バックボーンノードにより受信したプローブパケットを第２のリーフノードに送信するときに、バックボーンノードは、対称ハッシュサービストラヒック分配方法（ハッシュ負荷分散方法とも呼ばれる）を使用することにより、送信を実行してもよい。具体的には、第１のリーフノードは、ハッシュアルゴリズムを使用することにより、第１のリーフノードと第２のリーフノードとの間にあり且つ第１のリーフノードによりトラバースされる全てのパスに従って、各パスに対応するハッシュ値を計算してもよい。各ハッシュ値は、バックボーンノードと第２のリーフノードとの間の物理リンクを表すために使用されてもよい。バックボーンノードが第１のリーフノードにより送信されたプローブパケットを受信した後に、バックボーンノードは、バックボーンノードに記憶された転送テーブル（ハッシュ値と、バックボーンノードと第２のリーフノードとの間の物理リンクとの間の対応関係を含む）に従って、プローブパケットに含まれるハッシュ値に対応する物理リンクを決定し、物理リンクのアウトバウンドインタフェースからプローブパケットを送信してもよい。

【0061】

S104.第２のリーフノードは、第２のリーフノードの複数の物理リンクを通じて、各バックボーンノードにより送信されたプローブパケットを受信する。

【0062】

第２のリーフノードの複数の物理リンクは、第２のリーフノードと少なくとも１つのバックボーンノードのそれぞれとの間の物理リンクを含む。例えば、第２のリーフノードの複数の物理リンクは、図２に示す物理リンク(5)、物理リンク(6)、物理リンク(7)及び物理リンク(8)を具体的に含んでもよい。

【0063】

S105.第２のリーフノードは、各プローブパケットに対応する応答パケットを生成する。

【0064】

具体的には、第２のリーフノードにより、第２のリーフノードにより受信したプローブパケットに従って、プローブパケットに対応する応答パケットを生成するための方法は以下の通りでもよい。

【0065】

プローブパケットを受信した後に、第２のリーフノードは、プローブパケット内の送信元媒体アクセス制御（英語：media access control, 略称：MAC）アドレス及び宛先MACアドレスを入れ換え、プローブパケットに対応する応答パケットを生成してもよい。

【0066】

代替として、第２のリーフノードは、プローブパケット内の送信元MACアドレス及び宛先MACアドレスを入れ換え、プローブパケット内の送信元IPアドレス及び宛先IPアドレスを入れ換え、プローブパケット内のレイヤ４送信元ポート番号及びレイヤ４宛先ポート番号を入れ換え、プローブパケットに対応する応答パケットを生成してもよい。

【0067】

代替として、第２のリーフノードは、プローブパケット内の送信元MACアドレス及び宛先MACアドレスを入れ換え、プローブパケット内の送信元デバイス識別子及び宛先デバイス識別子を入れ換え、プローブパケットに対応する応答パケットを生成してもよい。

【0068】

当業者は、第２のリーフノードにより入れ換えられるプローブパケット内の前述のフィールドを除き、他のフィールド／他のフィールドの値は、変更なしに応答パケット内に保持されてもよいことを理解し得る。すなわち、第２のリーフノードにより入れ換えられる応答パケット内のフィールドを除き、他のフィールド／他のフィールドの値は、プローブパケットのものと同じである。

【0069】

任意選択で、本発明の実施例では、第１のリーフノード及び第２のリーフノードは、異なる仮想ローカルエリアネットワーク（英語：virtual local area network, 略称：VLAN）、ブロードキャストドメイン又はIPネットワークセグメントに属してもよい。したがって、リーフノード（第１のリーフノード及び第２のリーフノードを含む）と、リーフノードと相互作用するバックボーンノードとの間のネットワークは異なってもよい。その結果、第２のリーフノードにより、第２のリーフノードにより受信したプローブパケットに従って、プローブパケットに対応する応答パケットを生成するための方法は異なってもよい。具体的には、第１のリーフノード及び第２のリーフノードが同じVLAN、ブロードキャストドメイン又はIPネットワークセグメントに属する場合、リーフノードと、リーフノードと相互作用するバックボーンノードとの間のネットワークは、レイヤ２ネットワーク又は多リンクの透過的相互接続（英語：transparent interconnection of lots of links, 略称：TRILL）ネットワークである。第１のリーフノード及び第２のリーフノードが異なるVLAN、ブロードキャストドメイン又はIPネットワークセグメントに属する場合、リーフノードと、リーフノードと相互作用するバックボーンノードとの間のネットワークは、レイヤ３ネットワークである。以下に、第２のリーフノードにより、第２のリーフノードにより受信したプローブパケットに従って、プローブパケットに対応する応答パケットを生成するための方法を詳細に説明するために、リーフノードとバックボーンノードとの間のネットワークが別々にこれらの３つの種類のネットワークである例を使用する。

【0070】

(1)リーフノードとバックボーンノードとの間のネットワークがレイヤ２ネットワークである。

【0071】

リーフノードとバックボーンノードとの間のネットワークがレイヤ２ネットワークである場合、レイヤ２ネットワークはIPアドレスに関係しないため、第２のリーフノードが第２のリーフノードにより受信したプローブパケットに従って、プローブパケットに対応する応答パケットを生成するときに、第２のリーフノードは、プローブパケット内の送信元MACアドレス及び宛先MACアドレスを入れ換える。

【0072】

(2)リーフノードとバックボーンノードとの間のネットワークがレイヤ３ネットワークである。

【0073】

リーフノードとバックボーンノードとの間のネットワークがレイヤ３ネットワークである場合、第２のリーフノードが第２のリーフノードにより受信したプローブパケットに従って、プローブパケットに対応する応答パケットを生成するときに、第２のリーフノードは、プローブパケット内の送信元MACアドレス及び宛先MACアドレスを入れ換え、プローブパケット内の送信元IPアドレス及び宛先IPアドレスを入れ換え、プローブパケット内のレイヤ４送信元ポート番号及びレイヤ４宛先ポート番号を入れ換える。

【0074】

(3)リーフノードとバックボーンノードとの間のネットワークがTRILLネットワークである。

【0075】

リーフノードとバックボーンノードとの間のネットワークがTRILLネットワークである場合、第２のリーフノードが第２のリーフノードにより受信したプローブパケットに従って、プローブパケットに対応する応答パケットを生成するときに、第２のリーフノードは、プローブパケット内の送信元MACアドレス及び宛先MACアドレスを入れ換え、プローブパケット内の送信元デバイス識別子及び宛先デバイス識別子を入れ換える。

【0076】

任意選択で、本発明の実施例では、前述の上記３つの種類のネットワークに加えて、リーフノードとバックボーンノードとの間のネットワークは、クラスタシステムネットワーク、仮想プライベートLANサービス（英語：virtual private lan service, 略称：VPLS）ネットワーク、VXLAN、総称ルーティングカプセル化を用いたネットワーク仮想化（英語：network virtualization using generic routing encapsulation, 略称：NVGRE）ネットワーク、ステートレストランスポートトンネリング（英語：stateless transport tunneling, 略称：STT）ネットワーク等でもよい。詳細はこの実施例では１つずつ説明しない。

【0077】

本発明のこの実施例では、応答パケットは、VXLANプロトコルをサポートするパケットでもよい。パケットの具体的なフォーマットは、従来技術におけるVXLANプロトコルをサポートするパケットのものと同じである。

【0078】

さらに、以下に、プローブパケット及び応答パケットのアドレス、ポート番号等を詳細に説明する。図２が例として使用される。プローブパケットが物理リンク(1)を通じてリーフノード12からバックボーンノード14に伝送され、次に、物理リンク(5)又は物理リンク(6)を通じてリーフノード13に伝送され、応答パケットが元のパスに従って返信されると仮定する。リーフノード12からバックボーンノード14へのプローブパケットについて、プローブパケット内の送信元MACアドレスはリーフノード12のMACアドレスであり、宛先MACアドレスはバックボーンノード14のMACアドレスであり、送信元IPアドレスはリーフノード12のIPアドレスであり、宛先IPアドレスはリーフノード13のIPアドレスであり、レイヤ４送信元ポート番号はリーフノード12のレイヤ４送信元ポート番号であり、レイヤ４宛先ポート番号はリーフノード13のレイヤ４宛先ポート番号である。バックボーンノード14からリーフノード13へのプローブパケットについて、プローブパケット内の送信元MACアドレスはバックボーンノード14のMACアドレスであり、宛先MACアドレスはリーフノード13のMACアドレスであり、送信元IPアドレス、宛先IPアドレス、レイヤ４送信元ポート番号及びレイヤ４宛先ポート番号は、リーフノード12からバックボーンノード14へのプローブパケット内の送信元IPアドレス、宛先IPアドレス、レイヤ４送信元ポート番号及びレイヤ４宛先ポート番号と同じである。

【0079】

プローブパケットは、生存時間（英語：time to live, 略称：TTL）フィールドを更に含む点に留意すべきである。プローブパケットがレイヤ３ネットワークで転送されるときに、TTLフィールド内のTTL値は、プローブパケットが転送される毎に1だけ減少する。したがって、プローブパケット内のIPヘッダチェックサム（英語：checksum）フィールドの値及び巡回冗長検査（英語：CRC）の値は、同期して更新される。

【0080】

したがって、当業者は、プローブパケットに対応する応答パケットの送信元MACアドレス及び宛先MACアドレスが、プローブパケットの送信元MACアドレス及び宛先MACアドレスと反対であり、応答パケットの送信元IPアドレス及び宛先IPアドレスが、プローブパケットの送信元IPアドレス及び宛先IPアドレスと反対であり、応答パケットのレイヤ４送信元ポート番号及びレイヤ４宛先ポート番号が、プローブパケットのレイヤ４送信元ポート番号及びレイヤ４宛先ポート番号と反対であることを認識するべきである。

【0081】

S106.第２のリーフノードは、バックボーンノードに接続された第２のリーフノードの複数の物理リンクを通じて、応答パケットを別々に送信する。

【0082】

本発明のこの実施例では、第２のリーフノードが第２のリーフノードにより受信したプローブパケットに従って、プローブパケットに対応する応答パケットを生成した後に、第２のリーフノードは、プローブパケットを受信するためのレイヤ４ポートから応答パケットを送信してもよい。すなわち、応答パケットは、プローブパケットの伝送パスに従って第１のリーフノードに返信できることが確保される。このように、第１のリーフノードは、第１のリーフノードと第２のリーフノードとの間の各パスの伝送パラメータを正確に計算できることが確保できる。

【0083】

S107.各バックボーンノードは、バックボーンノードに接続された各物理リンクを通じて第２のリーフノードにより送信された応答パケットを受信する。

【0084】

S108.各バックボーンノードは、第１のリーフノードに接続された物理リンクを通じて、バックボーンノードにより受信した応答パケットを第１のリーフノードに別々に送信する。

【0085】

S108において、S103と同様に、各バックボーンノードにより受信した応答パケットを第１のリーフノードに送信するときに、少なくとも１つのバックボーンノードのそれぞれは、対称ハッシュサービストラヒック分配方法を使用することにより、送信を実行してもよい。すなわち、バックボーンノードが第１のリーフノードにより送信されたプローブパケットを受信するときに、バックボーンノードは、プローブパケットが受信された物理リンクを記録する。次に、バックボーンノードは、応答パケットに対応するプローブパケットを伝送するための物理リンクに従って、バックボーンノードにより受信した複数の応答パケットを第１のリーフノードに送信する（すなわち、各応答パケットは、応答パケットに対応するプローブパケットの元の伝送パスに従って第１のリーフノードに返信される）。このように、プローブパケット及びプローブパケットに対応する応答パケットが同じパス上で伝送されることが確保できる。したがって、第１のリーフノードにより、第１のリーフノードと第２のリーフノードとの間の各パスの伝送パラメータを計算する精度が改善できる。

【0086】

S109.第１のリーフノードは、第１のリーフノードの複数の物理リンクを通じて、各バックボーンノードにより送信された応答パケットを受信する。

【0087】

S110.パス毎に、第１のリーフノードは、各パスの伝送パラメータを取得するために、パス上で受信した複数の応答パケットに従って、パスの伝送パラメータを計算する。

【0088】

同じパス上で受信した応答パケットは、同じパス識別子を含む。第１のリーフノードの複数の物理リンクは、異なるパスに属し、第２のリーフノードの複数の物理リンクもまた、異なるパスに属する。第１のリーフノードの１つの物理リンク及び第２のリーフノードの１つの物理リンクは、同じパスに属する。例えば、図２に示すデータセンタネットワークに基づいて、第１のリーフノード（例えば、リーフノード12）の１つの物理リンク及び第２のリーフノード（例えば、リーフノード13）の１つの物理リンクは、１つのパスを形成する。

【0089】

任意選択で、本発明の実施例では、各パスの伝送パラメータは、パスの待ち時間、パスのジッタ又はパスのパケットロス率のうち少なくとも１つを含んでもよい。例えば、図２に示すリーフノード12とリーフノード13との間に合計で８個のパスが存在し、これらは、具体的には前述のパス1〜パス8である。第１のリーフノードは、８個のパスのそれぞれで受信した応答パケットに従って、各パスの伝送パラメータを計算してもよい。具体的には、第１のリーフノードは、第１のリーフノードによりパス1上で受信した応答パケットに従って、パス1の伝送パラメータを計算し、第１のリーフノードによりパス2上で受信した応答パケットに従って、パス2の伝送パラメータを計算し、...、第１のリーフノードによりパス8上で受信した応答パケットに従って、パス8の伝送パラメータを計算してもよい。このように、第１のリーフノードは、８個のパスの伝送パラメータを取得してもよい。

【0090】

S111.第１のリーフノードは、各パスの伝送パラメータに従って、伝送対象のサービストラヒックを第１のリーフノードの複数の物理リンクに分配する。

【0091】

第１のリーフノードが第１のリーフノードと第２のリーフノードとの間の各パスの伝送パラメータを計算した後に、第１のリーフノードは、パスの伝送パラメータに従って、伝送対象のサービストラヒックを第１のリーフノードの複数の物理リンクに適切に分配してもよい。

【0092】

例えば、各パスの伝送パラメータがパスの待ち時間、パスのジッタ及びパスのパケットロス率を含むと仮定する。第１のリーフノードがパスの待ち時間、パスのジッタ及びパスのパケットロス率を計算した後に、第１のリーフノードは、パスの待ち時間、パスのジッタ及びパスのパケットロス率と、伝送対象のサービストラヒックの実際の伝送要件とに従って、伝送対象のサービストラヒックを第１のリーフノードの複数の物理リンクに分配してもよい。

【0093】

例えば、第１のリーフノードと第２のリーフノードとの間に４つのパスが存在し、これらは、それぞれパス1、パス2、パス3及びパス4であると仮定する。パス1の伝送パラメータは、それぞれ待ち時間1、ジッタ1及びパケットロス率1である。パス2の伝送パラメータは、それぞれ待ち時間2、ジッタ2及びパケットロス率2である。パス3の伝送パラメータは、それぞれ待ち時間3、ジッタ3及びパケットロス率3である。パス4の伝送パラメータは、それぞれ待ち時間4、ジッタ4及びパケットロス率4である。待ち時間1及び待ち時間2は、予め設定された待ち時間閾値より大きく、待ち時間3及び待ち時間4は、待ち時間閾値より小さい。ジッタ1は、予め設定されたジッタ閾値より大きく、ジッタ2、ジッタ3及びジッタ4は、ジッタ閾値より小さい。パケットロス率1、パケットロス率2及びパケットロス率4は、予め設定されたパケットロス率閾値より小さく、パケットロス率3は、パケットロス率閾値より大きい。伝送対象のサービスがパケットロス率に対して比較的高い要件を有する（すなわち、パケットロス率が予め設定されたパケットロス率閾値より小さいことを要求する）ときに、第１のリーフノードは、伝送のために、伝送対象のサービストラヒックをパス1、パス2及びパス4に分配してもよい（具体的には、第１のリーフノードは、伝送のために、伝送対象のサービストラヒックを、第１のリーフノード上のパス1、パス2及びパス4にそれぞれ属する物理リンクに分配してもよい）。

【0094】

前述の待ち時間閾値、ジッタ閾値及びパケットロス率閾値は、実際のネットワークアーキテクチャ及びネットワーク伝送環境に従って決定され、実際の適用中に設定されてもよい。

【0095】

本発明のこの実施例において提供されるサービストラヒック分配方法によれば、第１のリーフノードは、バックボーンノードに接続された第１のリーフノードの複数の物理リンクのそれぞれを通じてプローブパケットを周期的に送信し、物理リンク毎に、第１のリーフノードは、物理リンクを通じて返信された応答パケットを受信し、各応答パケットは、物理リンクを通じて送信されたプローブパケットが第２のリーフノードに到達した後に、第２のリーフノードにより返信され、次に、パス毎に、第１のリーフノードは、各パスの伝送パラメータを取得するために、パス上で受信した複数の応答パケットに従って、パスの伝送パラメータを計算し、最後に、第１のリーフノードは、各パスの伝送パラメータに従って、伝送対象のサービストラヒックを複数の物理リンクに分配する。本発明のこの実施例において提供されるサービストラヒック分配方法によれば、第１のリーフノードは、プローブパケットを送信することにより、第１のリーフノードと第２のリーフノードとの間の全てのパスの伝送パラメータを検出してもよい。したがって、第１のリーフノードは、次に、パスの伝送パラメータに従って、伝送対象のサービストラヒックを分配する。これは、第１のリーフノードの物理リンク上のサービストラヒックが均衡していることを確保できるだけでなく、パスのそれぞれの上の他の物理リンク上のサービストラヒックが均衡していることも確保でき、それにより、送信元ノード（例えば、第１のリーフノード）と宛先ノード（例えば、第２のリーフノード）との間のパス上のサービストラヒックが均衡していることを確保し、パケットが失われないことを更に確保する。

【0096】

任意選択で、図３Ａ及び図３Ｂを参照すると、本発明のこの実施例において提供されるサービストラヒック分配方法において、S111は、
第１のリーフノードにより、各パスの伝送パラメータに従って、各パスのサービストラヒック分配比を決定し、第１のリーフノードにより、各パスのサービストラヒック分配比に従って、伝送対象のサービストラヒックを第１のリーフノードの複数の物理リンクに分配することを具体的に含んでもよい。

【0097】

本発明のこの実施例では、第１のリーフノードが第１のリーフノードと第２のリーフノードとの間の各パスの伝送パラメータを計算した後に、第１のリーフノードは、各パスの伝送パラメータに従って、各パスのサービストラヒック分配比を決定してもよい。

【0098】

例えば、例えば、各パスの伝送パラメータがパケットロス率であることを仮定する。第１のリーフノードが各パスのパケットロス率を計算した後に、第１のリーフノードは、パケットロス率が予め設定されたパケットロス率閾値以上であるパスが比較的輻輳しており、パケットロス率がパケットロス率閾値より小さいパスが比較的利用されてないと決定してもよい。この場合、第１のリーフノードは、パケットロス率がパケットロス率閾値以上であるパスのサービストラヒック分配比が比較的低く、パケットロス率がパケットロス率閾値より小さいパスのサービストラヒック分配比が比較的高いと決定してもよい。例えば、２つのパスが存在し、これらは、それぞれパス1及びパス2であることを仮定する。パス1のパケットロス率が1%であり、パス2のパケットロス率が5%であり、予め設定されたパケットロス率閾値が2%である場合、第１のリーフノードは、パス1のサービストラヒック分配比が90%であり、パス2のサービストラヒック分配比が10%であると決定してもよい。

【0099】

各パスの伝送パラメータ及び各パスのサービストラヒック分配比についての説明及び例は、単なる例示である点に留意すべきである。すなわち、本発明のこの実施例において提供されるサービストラヒック分配方法に従って、各パスの伝送パラメータ及び各パスのサービストラヒック分配比の選択及び決定は、実際の使用要件に従って具体的に設定されてもよい。これは、本発明では具体的に限定されない。

【0100】

さらに、第１のリーフノードが各パスのサービストラヒック分配比を決定した後に、第１のリーフノードは、各パスのサービストラヒック分配比に従って、伝送対象のサービストラヒックを複数の物理リンクに分配してもよい。第１のリーフノードにより決定されたサービストラヒック分配比は、第１のリーフノードと第２のリーフノードとの間の全てのパスのサービストラヒック分配比である（各パスは複数の物理リンクを含む）。したがって、伝送対象のサービストラヒックを伝送するときに、第１のリーフノードは、サービストラヒック分配比に従って、対応する伝送対象のサービストラヒックを第１のリーフノードの複数の物理リンクに分配してもよい。このように、第１のリーフノードの各物理リンク上のサービストラヒックが均衡していることが確保できるだけでなく、第１のリーフノードと第２のリーフノードとの間の全てのパスのそれぞれの上の他の物理リンク上のサービストラヒックも均衡していることを確保でき、第１のリーフノードから第２のリーフノードへの伝送中にパケットが失われないことを更に防止する。

【0101】

任意選択で、図３Ａ及び図３Ｂを参照すると、本発明のこの実施例において提供されるサービストラヒック分配方法に従って、S109の後且つS110の前に、サービストラヒック分配方法は、
パス毎に、受信した応答パケットに含まれるパス識別子に従って、パス上で受信した応答パケットを決定し、パス上で受信した複数の応答パケットを取得することを更に含んでもよい。

【0102】

本発明のこの実施例では、同じパス上で受信した応答パケットは、同じパス識別子を含む。したがって、第１のリーフノードは、第１のリーフノードにより受信した応答パケットに含まれるパス識別子に従って、各パス上で受信した複数の応答パケットを別々に決定してもよい。

【0103】

S110は、
第１のリーフノードにより、パス上で受信した複数の応答パケットのパケット特性に従って、パスの伝送パラメータを計算することを具体的に含んでもよい。

【0104】

任意選択で、本発明の実施例では、パス上で受信した複数の応答パケットのそれぞれのパケット特性は、パスの識別子と、応答パケットのシーケンス番号と、応答パケットの送信元IPアドレスと、応答パケットの宛先IPアドレスと、応答パケットのレイヤ４送信元ポート番号と、応答パケットのレイヤ４宛先ポート番号と、応答パケットが第１のリーフノードに到達した時間と、応答パケットに対応するプローブパケットが第１のリーフノードを出発した時間とを含む。

【0105】

各応答パケットに含まれるパス識別子は、応答パケットが伝送されるパスを識別するために使用されてもよい。パス識別子は、応答パケットに対応するプローブパケットを送信したデバイス（例えば、本発明のこの実施例における第１のリーフノード）のインタフェース名又はデバイスのインタフェース識別子と、ハッシュ値とを含んでもよい。

【0106】

例えば、デバイスのインタフェース名は、第１のリーフノード内のアクセススイッチの名前でもよく、デバイスのインタフェース識別子は、第１のリーフノード内のアクセススイッチの識別子でもよく、ハッシュ値は、第１のリーフノードとバックボーンノードとの間のパスの物理リンク以外の他の物理リンクを表すために使用されてもよい。ハッシュ値は、ネットワーク配置が完了した後に、第１のリーフノードにより、ハッシュアルゴリズムを使用することにより、第１のリーフノードと第２のリーフノードとの間にあり且つ第１のリーフノードによりトラバースされる全てのパスに従って計算される。詳細については、S103におけるハッシュ値についての関係する説明を参照し、詳細はここでは再び説明しない。

【0107】

パス識別子が１つのハッシュ値を含むことが、図２に示すレイヤ２トポロジアーキテクチャを有するデータセンタネットワークを例として使用することにより、例示的に記載される。レイヤ３又は３より大きいレイヤのトポロジアーキテクチャを有するデータセンタネットワークについて、パス識別子は、複数のハッシュ値を含んでもよい。各ハッシュ値は、パス上の第１の物理リンク（すなわち、プローブパケットが通過する第１の物理リンク）とは異なる他の物理リンクのうち１つの物理リンクに対応する。レイヤ３又は３より大きいレイヤのトポロジアーキテクチャを有するデータセンタネットワークの実現原理は、図２に示すレイヤ２トポロジアーキテクチャを有するデータセンタネットワークの実現原理と同様であり、詳細はここでは再び説明しない。

【0108】

パス上で受信した応答パケットは、パスの伝送パラメータを決定するために使用されてもよい。したがって、第１のリーフノードは、各パス上で受信され且つ第１のリーフノードにより決定された複数の応答パケットのパケット特性に従って、パスの伝送パラメータを別々に計算してもよい。このように、パス毎の計算を実行した後に、第１のリーフノードは、各パスの伝送パラメータを取得してもよい。

【0109】

本発明のこの実施例では、待ち時間は、プローブパケットが送信された時間と、プローブパケットに対応する応答パケットが受信された時間との間の差を計算することにより、第１のリーフノードにより取得されてもよい（具体的には、待ち時間は、前述の応答パケットが第１のリーフノードに到達した時間から、応答パケットに対応するプローブパケットが第１のリーフノードを出発した時間を減算することにより取得されてもよい）。ジッタは、２つの隣接するパケットの間の待ち時間の差を、２つのパケットの間のシーケンス番号の差で除算することにより、第１のリーフノードにより取得されてもよい。パケットロス率は、或る期間内に第１のリーフノードにより送信されたプローブパケットの数と、その期間内に第１のリーフノードにより受信した応答パケットの数との間の差を、第１のリーフノードにより送信されたプローブパケットの数で除算することにより、第１のリーフノードにより取得されてもよい。

【0110】

具体的には、計算精度を改善するために、前述の待ち時間は、代替として、或る期間内の待ち時間の平均値を計算することにより、第１のリーフノードにより取得されてもよい。ジッタは、代替として、或る期間内のジッタの平均値を計算することにより、第１のリーフノードにより取得されてもよい。

【0111】

当業者は、第１のリーフノードにより待ち時間を計算するために使用される、応答パケットが第１のリーフノードに到達する時間及び応答パケットに対応するプローブパケットが第１のリーフノードを出発する時間が、応答パケット内で搬送されてもよいことを理解し得る。例えば、プローブパケットを送信するときに、第１のリーフノードは、プローブパケットが第１のリーフノードを出発した時間を示すために、タイムスタンプをプローブパケットに追加してもよい。応答パケットを受信した後に、第１のリーフノードはまた、応答パケットが第１のリーフノードに到達した時間を示すために、タイムスタンプを応答パケットに追加してもよい。

【0112】

対応して、第１のリーフノードによりジッタを計算するために使用される２つの隣接するパケットの間の前述の待ち時間の差は、２つのパケットの待ち時間に対して減算を実行することにより取得されてもよい。２つのパケットのシーケンス番号は、第１のリーフノードがプローブパケットを送信するときに、第１のリーフノードによりプローブパケットに追加される。各パケットのシーケンス番号は、パケットを一意に識別するために使用され、各パケットのシーケンス番号は、パケット内で搬送されてもよい。

【0113】

対応して、第１のリーフノードによりパケットロス率を計算するために使用される、或る期間内に第１のリーフノードにより送信された前述のプローブパケットの数及びその期間内に第１のリーフノードにより受信した応答パケットの数は、第１のリーフノードによりカウントされてもよい。

【0114】

任意選択で、本発明のこの実施例において提供されるサービストラヒック分配方法において、第１のリーフノードにより、各パスの伝送パラメータに従って、各パスのサービストラヒック分配比を決定することは、
第１のリーフノードにより、各パスの伝送パラメータを量子化し、第１のリーフノードにより、各パスの量子化された伝送パラメータに従って、各パスのサービストラヒック分配比を決定することを具体的に含んでもよい。

【0115】

本発明のこの実施例では、実現及び計算を簡単にするために、第１のリーフノードが第１のリーフノードと第２のリーフノードとの間の各パスの伝送パラメータを計算した後に、第１のリーフノードは、各パスの伝送パラメータを量子化し、各パスの量子化された伝送パラメータに従って、各パスのサービストラヒック分配比を決定してもよい。

【0116】

任意選択で、本発明の実施例では、第１のリーフノードが各パスの伝送パラメータを量子化する複数の実現方式が存在してもよい。第１のリーフノードが各パスの伝送パラメータを量子化することが、例として可能な実現方式を使用することにより、以下に例示的に記載される。

【0117】

第１のリーフノードと第２のリーフノードとの間の各パスの伝送パラメータがパスの待ち時間、パスのジッタ及びパスのパケットロス率を含むと仮定する。待ち時間と量子化された待ち時間の値との間の対応関係、ジッタと量子化されたジッタの値との間の対応関係、及びパケットロス率と量子化されたパケットロス率の値との間の対応関係は予め設定されてもよい。第１のリーフノードが各パスの伝送パラメータを計算した後に、第１のリーフノードは、各パスの伝送パラメータ及び対応関係に従って、各パスの伝送パラメータの量子化された値を決定してもよい。

【0118】

本発明のこの実施例では、待ち時間と量子化された待ち時間の値との間の対応関係は、以下の表１を使用することにより表されてもよく、ジッタと量子化されたジッタの値との間の対応関係は、以下の表２を使用することにより表されてもよく、パケットロス率と量子化されたパケットロス率の値との間の対応関係は、以下の表３を使用することにより表されてもよい。

【表1】

【0119】

例えば、表１を参照すると、第１のリーフノードが計算を用いることにより、パスの待ち時間が7.0μsであることを取得した場合、第１のリーフノードは、待ち時間を3に量子化してもよい。

【表2】

【0120】

例えば、表２を参照すると、第１のリーフノードが計算を用いることにより、パスのジッタが7.0μsであることを取得した場合、第１のリーフノードは、ジッタを2に量子化してもよい。

【表3】

【0121】

例えば、表３を参照すると、第１のリーフノードが計算を用いることにより、パスのパケットロス率が10000×10^-6=0.01（すなわち、1%）であることを取得した場合、第１のリーフノードは、パケットロス率を4に量子化してもよい。

【0122】

実際の用途では、量子化された待ち時間の値、量子化されたジッタの値及び量子化されたパケットロス率の値のそれぞれは、3ビットにより表されてもよい。例えば、0は000により表されてもよく、1は001により表されてもよく、2は010により表されてもよく、3は011により表されてもよく、4は100により表されてもよく、5は101により表されてもよく、6は110により表されてもよく、7は111により表されてもよい。

【0123】

さらに、第１のリーフノードにより、各パスの量子化された伝送パラメータに従って、各パスのサービストラヒック分配比を決定するための方法は、以下のうち１つでもよい。

【0124】

(1)第１のリーフノードは、パスを単位として使用し、各パスの量子化された伝送パラメータを加算し、各パスの総伝送パラメータを取得する。次に、第１のリーフノードは、各パスの総伝送パラメータに従って、各パスのサービストラヒック分配比を決定する。

【0125】

例えば、３つのパスが存在し、これらは、それぞれパス1、パス2及びパス3であると仮定する。３つのパスのそれぞれの伝送パラメータは、待ち時間、ジッタ及びパケットロス率を含む。パス1の量子化された待ち時間の値は2であり、パス1の量子化されたジッタの値は5であり、パス1の量子化されたパケットロス率の値は3である。パス2の量子化された待ち時間の値は5であり、パス2の量子化されたジッタの値は2であり、パス2の量子化されたパケットロス率の値は0である。パス3の量子化された待ち時間の値は3であり、パス3の量子化されたジッタの値は0であり、パス3の量子化されたパケットロス率の値は2である。第１のリーフノードは、パス1の量子化された待ち時間の値、パス1の量子化されたジッタの値及びパス1の量子化されたパケットロス率の値を加算し、パス1の総伝送パラメータ（すなわち、2+5+3=10）を取得し、パス2の量子化された待ち時間の値、パス2の量子化されたジッタの値及びパス2の量子化されたパケットロス率の値を加算し、パス2の総伝送パラメータ（すなわち、5+2+0=7）を取得し、パス3の量子化された待ち時間の値、パス3の量子化されたジッタの値及びパス3の量子化されたパケットロス率の値を加算し、パス3の総伝送パラメータ（すなわち、3+0+2=5）を取得してもよい。次に、第１のリーフノードは、パス1の総伝送パラメータ、パス2の総伝送パラメータ及びパス3の総伝送パラメータに従って、パス1、パス2及びパス3のサービストラヒック分配比を決定する。このように、パス1、パス2及びパス3上のサービストラヒックが均衡できることが確保できる。

【0126】

(2)第１のリーフノードは、パスを単位として使用し、各パスのそれぞれの量子化された伝送パラメータの3ビットを１つの系列に接合し、系列の値は、各パスの総伝送パラメータを表してもよい。次に、第１のリーフノードは、各パスの総伝送パラメータに従って、各パスのサービストラヒック分配比を決定する。

【0127】

例えば、３つのパスが存在し、これらは、それぞれパス1、パス2及びパス3であると仮定する。３つのパスのそれぞれの伝送パラメータは、待ち時間、ジッタ及びパケットロス率を含む。パス1の量子化された待ち時間の値は2であり（010により表される）、パス1の量子化されたジッタの値は5であり（101により表される）、パス1の量子化されたパケットロス率の値は3である（011により表される）。パス2の量子化された待ち時間の値は5であり（101により表される）、パス2の量子化されたジッタの値は2であり（010により表される）、パス2の量子化されたパケットロス率の値は0である（000により表される）。パス3の量子化された待ち時間の値は3であり（011により表される）、パス3の量子化されたジッタの値は0であり（000により表される）、パス3の量子化されたパケットロス率の値は2である（010により表される）。第１のリーフノードは、パス1の量子化された待ち時間の値の3ビットと、パス1の量子化されたジッタの値の3ビットと、パス1の量子化されたパケットロス率の値の3ビットとを系列に接合し、パス1の総伝送パラメータ（すなわち、010101011=171）を取得し、パス2の量子化された待ち時間の値の3ビットと、パス2の量子化されたジッタの値の3ビットと、パス2の量子化されたパケットロス率の値の3ビットとを系列に接合し、パス2の総伝送パラメータ（すなわち、101010000=336）を取得し、パス3の量子化された待ち時間の値の3ビットと、パス3の量子化されたジッタの値の3ビットと、パス3の量子化されたパケットロス率の値の3ビットとを系列に接合し、パス3の総伝送パラメータ（すなわち、011000010=200）を取得してもよい。次に、第１のリーフノードは、パス1の総伝送パラメータ、パス2の総伝送パラメータ及びパス3の総伝送パラメータに従って、パス1、パス2及びパス3のサービストラヒック分配比を決定する。このように、パス1、パス2及びパス3上のサービストラヒックが均衡できることが確保できる。

【0128】

第１のリーフノードがパス1の総伝送パラメータ、パス2の総伝送パラメータ及びパス3の総伝送パラメータに従って、パス1、パス2及びパス3のサービストラヒック分配比を決定することは、第１のリーフノードにより、パス1の総伝送パラメータ、パス2の総伝送パラメータ及びパス3の総伝送パラメータに従って、パス1のサービストラヒック分配比を決定し、第１のリーフノードにより、パス1の総伝送パラメータ、パス2の総伝送パラメータ及びパス3の総伝送パラメータに従って、パス2のサービストラヒック分配比を決定し、第１のリーフノードにより、パス1の総伝送パラメータ、パス2の総伝送パラメータ及びパス3の総伝送パラメータに従ってパス3のサービストラヒック分配比を決定することを具体的に含む点に留意すべきである。

【0129】

具体的には、第１のリーフノードがパス1の総伝送パラメータ、パス2の総伝送パラメータ及びパス3の総伝送パラメータに従って、パス1、パス2及びパス3のサービストラヒック分配比を決定することは、実際の使用要件に従って選択された対応するアルゴリズムに従って具体的に実現されてもよい。これは、本発明のこの実施例では限定されない。例えば、(1)において、パス1の総伝送パラメータが10であり、パス2の総伝送パラメータが7であり、パス3の総伝送パラメータが5であると仮定する。第１のリーフノードは、10、7及び5が占める割合を計算し、次に、割合に従ってパス1、パス2及びパス3のサービストラヒック分配比を決定してもよい。パス1の総伝送パラメータが最大であり、パス2の総伝送パラメータが２番目に大きく、パス3の総伝送パラメータが最小である。したがって、第１のリーフノードは、パス1の伝送性能が最も悪く、パス2の伝送性能が２番目に悪く、パス3の伝送性能が最も良いと考えてもよい。このように、第１のリーフノードは、パス1のサービストラヒック分配比が最小であり、パス2のサービストラヒック分配比が２番目に小さく、パス3のサービストラヒック分配比が最大であると決定してもよい。このように、各パスの伝送性能は、各パスの伝送パラメータに従って取得されてもよい。したがって、各パスのサービストラヒック分配比は、各パスの伝送パラメータに従って決定される。各パス上のサービストラヒックが均衡していることが確保できる。

【0130】

任意選択で、本発明の実施例では、第１のリーフノードは、図３Ａ及び図３Ｂに示す前述のサービストラヒック分配方法を１回のみ実行してもよい。具体的には、第１のリーフノードが各パスの伝送パラメータを計算したときに、ユーザは、第１のリーフノード内に各パスの伝送パラメータを設定してもよい。第１のリーフノードがサービスを伝送する必要がある場合、第１のリーフノードは、各パスの予め設定された伝送パラメータに従って、伝送対象のサービストラヒックを第１のリーフノードの物理リンクに分配してもよい。代替として、第１のリーフノードが各パスの伝送パラメータに従って、各パスのサービストラヒック分配比を決定したときに、ユーザは、第１のリーフノード内に各パスのサービストラヒック分配比を設定してもよい。第１のリーフノードがサービスを伝送する必要がある場合、第１のリーフノードは、各パスの予め設定されたサービストラヒック分配比に従って、伝送対象のサービストラヒックを第１のリーフノードの物理リンクに分配してもよい。このように、第１のリーフノードと第２のリーフノードとの間の各パス上のサービストラヒックが均衡していることも確保でき、パケットが失われないことを更に確保する。

【0131】

第１のリーフノードが図３Ａ及び図３Ｂに示す前述のサービストラヒック分配方法を１回のみ実行することは、データセンタネットワークのアーキテクチャが基本的に固定されており、比較的大きな変更を有さない（すなわち、データセンタネットワークの配置が完了した後に、データセンタネットワークのアーキテクチャは比較的大きな変更を有さない）適用シナリオのみに適用可能である点に留意すべきである。

【0132】

任意選択で、データセンタネットワークのアーキテクチャが動的に変化する適用シナリオについて、第１のリーフノードは、図３Ａ及び図３Ｂに示す前述のサービストラヒック分配方法を繰り返してもよい。具体的には、第１のリーフノードは、図３Ａ及び図３Ｂに示す前述のサービストラヒック分配方法を継続的に繰り返してもよく、或いは第１のリーフノードは、図３Ａ及び図３Ｂに示す前述のサービストラヒック分配方法を固定の周期で繰り返してもよい。具体的には、これは、実際の使用要件に従って設定されてもよく、本発明では具体的に限定されない。

【0133】

本発明のこの実施例において提供されるサービストラヒック分配方法によれば、第１のリーフノードは、プローブパケットを送信することにより、第１のリーフノードと第２のリーフノードとの間の全てのパスの伝送パラメータを検出してもよい。したがって、第１のリーフノードは、パスの伝送パラメータに従って、伝送対象のサービストラヒックを分配する。これは、第１のリーフノードの物理リンク上のサービストラヒックが均衡していることを確保できるだけでなく、パスのそれぞれの上の他の物理リンク上のサービストラヒックが均衡していることも確保でき、それにより、送信元ノード（例えば、第１のリーフノード）と宛先ノード（例えば、第２のリーフノード）との間のパス上のサービストラヒックが均衡していることを確保し、パケットが失われないことを更に確保する。

【0134】

図４に示すように、本発明の実施例は、サービストラヒック分配装置を提供する。分配装置は、第１のリーフノードである。分配装置は、第１のリーフノードにより実行される前述の方法におけるステップを実行するように構成される。分配装置は、対応するステップに対応するモジュールを含んでもよい。例えば、分配装置は、
バックボーンノードに接続された第１のリーフノードの複数の物理リンクのそれぞれを通じてプローブパケットを周期的に送信するように構成された送信ユニット20と、物理リンク毎に、物理リンクを通じて返信された応答パケットを受信するように構成された受信ユニットであり、応答パケットは、物理リンクを通じて送信されたプローブパケットが第２のリーフノードに到達した後に、第２のリーフノードにより返信される受信ユニット21と、パス毎に、各パスの伝送パラメータを取得するために、受信ユニット21によりパス上で受信した複数の応答パケットに従って、パスの伝送パラメータを計算するように構成された計算ユニット22であり、同じパス上で受信した応答パケットは、同じパス識別子を含み、各パスは、少なくとも２つの物理リンクを含み、複数の物理リンクは、異なるパスに属する計算ユニット22と、計算ユニット22により計算された各パスの伝送パラメータに従って、伝送対象のサービストラヒックを複数の物理リンクに分配するように構成された分配ユニット23とを含んでもよい。

【0135】

任意選択で、分配ユニット23は、計算ユニット22により計算された各パスの伝送パラメータに従って、各パスのサービストラヒック分配比を決定し、各パスのサービストラヒック分配比に従って、伝送対象のサービストラヒックを複数の物理リンクに分配するように具体的に構成される。

【0136】

任意選択で、パスの伝送パラメータは、パスの待ち時間、パスのジッタ又はパスのパケットロス率のうち少なくとも１つを含む。

【0137】

任意選択で、図４を参照して、図５に示すように、分配装置は、決定ユニット24を更に含む。

【0138】

決定ユニット24は、計算ユニット22がパス上で受信した複数の応答パケットに従って、パスの伝送パラメータを計算する前に、受信ユニット21により受信した応答パケットに含まれるパス識別子に従って、パス上で受信した応答パケットを決定し、パス上で受信した複数の応答パケットを取得するように構成される。計算ユニット22は、パス上で受信し且つ決定ユニット24により決定された複数の応答パケットのパケット特性に従って、パスの伝送パラメータを計算するように具体的に構成される。

【0139】

任意選択で、受信ユニット21によりパス上で受信した複数の応答パケットのそれぞれのパケット特性は、パスの識別子と、応答パケットのシーケンス番号と、応答パケットの送信元インターネットプロトコルIPアドレスと、応答パケットの宛先IPアドレスと、応答パケットのレイヤ４送信元ポート番号と、応答パケットのレイヤ４宛先ポート番号と、応答パケットが第１のリーフノードに到達した時間と、応答パケットに対応するプローブパケットが第１のリーフノードを出発した時間とを含む。

【0140】

任意選択で、分配ユニット23は、計算ユニット22により計算された各パスの伝送パラメータを量子化し、各パスの量子化された伝送パラメータに従って、各パスのサービストラヒック分配比を決定するように具体的に構成される。

【0141】

本発明のこの実施例では、分配装置／第１のリーフノードはスイッチでもよく、第２のリーフノード及びバックボーンノードもまたスイッチでもよい。具体的には、第１のリーフノード及び第２のリーフノードは、レイヤ２リーフ・スパイン・トポロジアーキテクチャを有するデータセンタネットワーク内のリーフスイッチとして機能してもよく、バックボーンノードは、レイヤ２リーフ・スパイン・トポロジアーキテクチャを有するデータセンタネットワーク内のバックボーンスイッチでもよい。

【0142】

この実施例における分配装置は、図３Ａ及び図３Ｂに示す実施例におけるサービストラヒック分配方法の第１のリーフノードに対応してもよく、この実施例における分配装置のモジュールの分割及び／又は機能は、図３Ａ及び図３Ｂに示す方法の手順を実現するように設計されることが理解され得る。簡単にするために、詳細はここでは再び説明しない。

【0143】

本発明のこの実施例は、サービストラヒック分配装置を提供する。分配装置は、第１のリーフノードであり、第１のリーフノードは、プローブパケットを送信することにより、第１のリーフノードと第２のリーフノードとの間の全てのパスの伝送パラメータを検出してもよい。したがって、第１のリーフノードは、次に、パスの伝送パラメータに従って、伝送対象のサービストラヒックを分配する。これは、第１のリーフノードの物理リンク上のサービストラヒックが均衡していることを確保できるだけでなく、パスのそれぞれの上の他の物理リンク上のサービストラヒックが均衡していることも確保でき、それにより、送信元ノード（例えば、第１のリーフノード）と宛先ノード（例えば、第２のリーフノード）との間のパス上のサービストラヒックが均衡していることを確保し、パケットが失われないことを更に確保する。

【0144】

図６に示すように、本発明の実施例は、サービストラヒック分配装置を提供する。分配装置は、第１のリーフノードである。第１のリーフノードは、スイッチである（具体的には、スイッチは、レイヤ２リーフ・スパイン・トポロジアーキテクチャを有するデータセンタネットワーク内のリーフスイッチとして機能してもよい）。スイッチは、プロセッサ30と、インタフェース回路31と、メモリ32と、システムバス33とを含む。

【0145】

メモリ32は、コンピュータプログラム命令を記憶するように構成される。プロセッサ30、インタフェース回路31及びメモリ32は、システムバス33を使用することにより互いに接続される。スイッチが動作するときに、プロセッサ30は、メモリ32に記憶されたコンピュータプログラム命令を実行し、それにより、スイッチは、図３Ａ及び図３Ｂに示すサービストラヒック分配方法を実行する。具体的なサービストラヒック分配方法については、図３Ａ及び図３Ｂに示す方法における関係する説明を参照し、詳細はここでは再び説明しない。

【0146】

この実施例は、記憶媒体を更に提供する。記憶媒体は、メモリ32を含んでもよい。

【0147】

プロセッサ30は、中央処理装置（英語：central processing unit、略称：CPU）でもよい。代替として、プロセッサ30は、他の汎用プロセッサ、デジタルシグナルプロセッサ（英語：digital signal processor、略称：DSP）、特定用途向け集積回路（英語：application specific integrated circuit、略称：ASIC）、フィールドプログラマブルゲートアレイ（英語：field-programmable gate array、略称：FPGA）又は他のプログラム可能論理デバイス、ディスクリートゲート又はトランジスタ論理デバイス、ディスクリートハードウェアコンポーネント等でもよい。汎用プロセッサはマイクロプロセッサでもよく、或いはプロセッサはいずれかの従来のプロセッサ等でもよい。

【0148】

プロセッサ30は、専用プロセッサでもよい。専用プロセッサは、ベースバンド処理チップ、無線周波数処理チップ等のうち少なくとも１つを含んでもよい。さらに、専用プロセッサは、スイッチの他の専用の処理機能を有するチップを更に含んでもよい。

【0149】

メモリ32は、揮発性メモリ（英語：volatile memory）、例えば、ランダムアクセスメモリ（英語：random-access memory、略称：RAM）を含んでもよい。メモリ32は、不揮発性メモリ（英語：non-volatile memory）、例えば、読み取り専用メモリ（英語：read-only memory、略称：ROM）、フラッシュメモリ（英語：flash memory）、ハードディスクドライブ（英語：hard disk drive、略称：HDD）又はソリッドステートドライブ（英語：solid-state drive、略称：SSD）を含んでもよい。メモリ32は、前述の種類のメモリの組み合わせを更に含んでもよい。

【0150】

システムバス33は、データバス、電力バス、制御バス、状態信号バス等を含んでもよい。この実施例では、明確な説明のために、様々なバスは、図６においてシステムバス33として示されている。

【0151】

インタフェース回路31は、具体的には、スイッチ上のトランシーバでもよい。トランシーバは、無線トランシーバでもよい。プロセッサ30は、インタフェース回路31を使用することにより、他のデバイス、例えば、他のスイッチにパケットを送信するか、或いは他のデバイスからパケットを受信する。

【0152】

具体的な実現プロセスにおいて、図３Ａ及び図３Ｂに示す方法の手順におけるステップは、ハードウェア形式のプロセッサ30により、メモリ32に記憶されたソフトウェア形式のコンピュータプログラム命令を実行することにより実現されてもよい。繰り返しを避けるために、詳細はここでは再び説明しない。

【0153】

本発明のこの実施例では、第２のリーフノード及びバックボーンノードもまたスイッチでもよい。具体的には、第２のリーフノードは、レイヤ２リーフ・スパイン・トポロジアーキテクチャを有するデータセンタネットワーク内のリーフスイッチとして機能してもよく、バックボーンノードは、レイヤ２リーフ・スパイン・トポロジアーキテクチャを有するデータセンタネットワーク内のバックボーンスイッチでもよい。

【0154】

本発明のこの実施例は、サービストラヒック分配装置を提供する。分配装置は、第１のリーフノードであり、第１のリーフノードは、スイッチであり、スイッチは、プローブパケットを送信することにより、スイッチと他のスイッチとの間の全てのパスの伝送パラメータを検出してもよい。したがって、スイッチは、次に、パスの伝送パラメータに従って、伝送対象のサービストラヒックを分配する。これは、スイッチの物理リンク上のサービストラヒックが均衡していることを確保できるだけでなく、パスのそれぞれの上の他の物理リンク上のサービストラヒックが均衡していることも確保でき、それにより、スイッチと他のスイッチとの間のパス上のサービストラヒックが均衡していることを確保し、パケットが失われないことを更に確保する。

【0155】

便宜上且つ簡潔な説明の目的で、前述の装置において、前述の機能モジュールの分割は、例示のための例として挙げられていることが当業者により明確に理解され得る。実際の用途では、前述の機能は、異なるモジュールに分配されて要件に従って実現でき、すなわち、装置の内部構造は、前述の機能の全部又は一部を実現するために異なる機能モジュールに分割される。前述のシステム、装置及びユニットの詳細な動作プロセスについて、前述の方法の実施例における対応するプロセスに参照が行われてもよく、詳細はここでは再び説明しない。

【0156】

この出願において提供されるいくつかの実施例において、開示のシステム、装置及び方法は、他の方式で実現されてもよいことが理解されるべきである。例えば、記載の装置の実施例は、単なる例である。例えば、モジュール又はユニットの分割は、単に論理的な機能分割であり、実際の実現方式では他の分割でもよい。例えば、複数のユニット又はコンポーネントは結合されてもよく、或いは他のシステムに統合されてもよく、或いはいくつかの特徴が無視されてもよく或いは実行されなくてもよい。さらに、表示又は説明した相互結合若しくは直接結合又は通信接続は、いくつかのインタフェースを通じて実現されてもよい。装置又はユニットの間の間接結合又は通信接続は、電子的又は他の形式で実現されてもよい。

【0157】

別々の部分として記載したユニットは、物理的に別々でもよく或いは別々でなくてもよく、ユニットとして表示された部分は、物理的なユニットでもよく或いは物理的なユニットでなくてもよく、１つの場所に位置してもよく、或いは複数のネットワークユニットに分散されてもよい。ユニットの一部又は全部は、実施例の解決策の目的を達成するために、実際の要件に従って選択されてもよい。

【0158】

さらに、本発明の実施例における機能ユニットは、１つの処理ユニットに統合されてもよく、或いはユニットのそれぞれが物理的に単独で存在してもよく、或いは２つ以上のユニットが１つのユニットに統合されてもよい。前述の統合されたユニットは、ソフトウェア機能ユニットの形式で実現されてもよい。

【0159】

統合されたユニットがソフトウェア機能ユニットの形式で実現され、独立したプロダクトとして販売又は使用されるときに、統合されたユニットは、コンピュータ読み取り可能記憶媒体に記憶されてもよい。このような理解に基づいて、技術的解決策の一部又は全部は、ソフトウェアプロダクトの形式で実現されてもよい。ソフトウェアプロダクトは、記憶媒体に記憶され、コンピュータデバイス（パーソナルコンピュータ、サーバ又はネットワークデバイスでもよい）に対して本発明の実施例に記載の方法のステップの全部又は一部を実行するように命令するための命令を含む。記憶媒体は、フラッシュメモリ、取り外し可能ハードディスク、読み取り専用メモリ、ランダムアクセスメモリ、ディスケット又はコンパクトディスクのようなプログラムコードを記憶できる様々な媒体を含む非一時的な（英語：non-transitory）媒体である。

【0160】

前述の説明は、本発明の単に具体的な実現方式に過ぎず、本発明の保護範囲を限定することを意図するものではない。本発明に開示された技術範囲内で当業者により容易に理解される如何なる変更又は置換も本発明の保護範囲内に入るものとする。したがって、本発明の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

【図1】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】