JP2023521027A - サイクルベースのロードバランシングのためのネットワークデバイス、システム、および方法 - Google Patents

サイクルベースのロードバランシングのためのネットワークデバイス、システム、および方法 Download PDF

Info

Publication number
JP2023521027A
JP2023521027A JP2022560133A JP2022560133A JP2023521027A JP 2023521027 A JP2023521027 A JP 2023521027A JP 2022560133 A JP2022560133 A JP 2022560133A JP 2022560133 A JP2022560133 A JP 2022560133A JP 2023521027 A JP2023521027 A JP 2023521027A
Authority
JP
Japan
Prior art keywords
output
identifier
network device
cycle
load balancing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2022560133A
Other languages
English (en)
Inventor
パオロ・メダグリアーニ
セバスティアン・マルティン
シュアン・チェン
ジェレミー・ルゲ
Original Assignee
ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ホアウェイ・テクノロジーズ・カンパニー・リミテッド filed Critical ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Publication of JP2023521027A publication Critical patent/JP2023521027A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/34—Source routing

Abstract

本開示は、トランスポートネットワーク、パケットベースのネットワークシステム、およびそのようなネットワークシステムにおけるロードバランシングの分野に関する。より具体的には、ロードバランシングは、ネットワークサイクルレベルで実行される。本開示は、入力サイクル識別子（102）および関連する出力識別子（103）を含むロードバランシングポリシー（101）を取得するように構成された、サイクルベースのロードバランシングのためネットワークデバイス（100）を提供する。ネットワークデバイス（100）は、ネットワークデバイス（100）の入力サイクル（105）においてネットワークパケット（104）を取得し、入力サイクル（105）、入力サイクル識別子（102）、および関連する出力識別子（103）に基づいてネットワークデバイス（100）の出力（106）を判定し、ネットワークパケット（104）をネットワークデバイス（100）の出力（106）に提供するようにさらに構成される。

Description

本開示は、トランスポートネットワーク、パケットベースのネットワークシステム、およびそのようなネットワークシステムにおけるロードバランシングの分野に関する。より具体的には、ロードバランシングは、ネットワークサイクルレベルで実行される。特に、サイクルベースのロードバランシングのためのネットワークデバイス、ならびに対応するシステムおよび方法が提供される。
従来のネットワークシステムでは、決定論的ネットワーキング（DetNet）および時間依存ネットワーキング（TSN）が、サービス品質（QoS）を保証し、タイムクリティカルアプリケーションのエンドツーエンドレイテンシおよびジッタを制限する。レイテンシは、送信元ノードにおけるパケットの送信と宛先ノードにおける同じパケットの受信との間の時間間隔として定義される。ジッタは、連続するパケット間のエンドツーエンド遅延の変動として定義される。
従来のネットワークシステムでは、プロバイダエッジ（PE）ノードとプロバイダ（P）ノードの2種類のノードが存在する。ネットワークノード（例えば、PEノードまたはPノード）におけるパケットの転送を制御するために、フローテーブルまたはセグメントルーティング（SR）ポリシーが使用され得る。フローテーブルにおいて、各入力ポートは、フローが転送される出力ポート（およびDetNet用の送信サイクル）に関連付けられている。この場合、転送規則は、フローを処理するすべての中間デバイスにインストールされなければならない。
SRの場合、SR ID（SIDとも呼ばれる）のリストがPEノードによってパケットに追加され、パケットが移動する各中間PまたはPEノードによって消費される。このリスト（ラベルスタックとも呼ばれる）は、各ホップにおけるルーティング（すなわち、発信ポート）およびスケジューリング（すなわち、出力送信キューまたは出力送信サイクル）を判定する。
しかしながら、同じフローからすべてのネットワークパケットをルーティングするための単一の経路の使用は、ネットワーク利用率の低下をもたらす。典型的には、従来のロードバランシングは、例えば、ハッシュベースの分割または加重コストマルチ経路（WCMP）を使用して、スイッチおよびルータなどのネットワーク要素内で実装される。どちらの場合も、フローに対して決定がなされると、フローからのすべてのパケットは、同じ決定（同じ経路）に従わなければならない。等コスト複数経路（ECMP）または等コストでない複数経路（UCMP）を用いて、複数の経路にわたってトラフィックを分割することも可能である。
しかしながら、従来のロードバランシングは経路ごとのレベルでしか実装することができないため、ジッタおよび遅延に関する厳密なエンドツーエンド要件を有する決定論的ネットワークトラフィックのロードバランシングのための解決策はない。さらに、ネットワーク障害またはネットワークパケットのバーストの発生の場合、従来のロードバランシングは、ジッタおよび遅延に関する厳密なエンドツーエンド要件は満たすことができない。
上述の問題を考慮して、本開示の実施形態の目的は、従来のロードバランシング解決策を改善することである。
この目的または他の目的は、添付の独立請求項に記載されている本開示の実施形態によって達成され得る。本開示の実施形態の有利な実装形態は、従属請求項でさらに定義される。
特に、本開示の実施形態は、ネットワークパケットが受信された入力サイクルに応じて、決定論的ネットワークにおいてパケットをどのようにルーティングおよびスケジューリングするかを決定することによって、従来のロードバランシングの問題を解決する。特に、ネットワークパケットの出力ポートまたは出力サイクルは、ネットワークパケットが受信された入力サイクルに基づいて判定され、それによってジッタおよび遅延に関する厳密なエンドツーエンド要件が満たされ得る。
本開示の第1の態様は、入力サイクル識別子および関連する出力識別子を含むロードバランシングポリシーを取得し、ネットワークデバイスの入力サイクルでネットワークパケットを取得し、入力サイクル、入力サイクル識別子、および関連する出力識別子に基づいてネットワークデバイスの出力を判定し、ネットワークパケットをネットワークデバイスの出力に提供するように構成された、サイクルベースのロードバランシングのためのネットワークデバイスを提供する。
これは、ネットワークリンクおよびネットワークサイクルを介した効率的なロードバランシングを可能にするので、有益である。さらに、ジッタおよび遅延に関する厳しい要件を伴う決定論的トラフィックのロードバランシングが可能になる。
特に、ロードバランシングポリシーはルーティングポリシーも含む。
特に、ネットワークパケットはネットワークフローによって構成される。
特に、ネットワークデバイスは、ネットワークフローの入口デバイスまたはネットワークフローの中間デバイスである。
特に、ネットワークフローは、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、およびトランスポートプロトコルを含む。
第1の態様の一実装形態では、出力は出力ポートを含み、出力識別子は入力サイクル識別子に関連付けられた出力ポート識別子を含み、ネットワークデバイスは、出力ポート識別子に基づいて出力ポートを判定するようにさらに構成される。
これは、ロードバランシング決定を行うときにネットワークデバイスのいくつかの出力ポートが考慮され得るため、有益である。
第1の態様のさらなる実装形態では、ロードバランシングポリシーは、入力サイクル識別子に関連付けられた負荷分散インジケータをさらに含み、ネットワークデバイスは、負荷分散インジケータに基づいて出力を判定するようにさらに構成される。
これは、ロードバランシングの決定を行うときに負荷分散インジケータがさらに考慮され得るため、有益である。
特に、負荷分散インジケータは、パケット数と出力との関係を示す。特に、負荷分散インジケータは、相対的な負荷量と出力との関係を示す。特に、負荷分散インジケータは、出力における出力負荷を示す。特に、負荷分散インジケータは、出力識別子にも関連付けられる。
第1の態様のさらなる実装形態では、ロードバランシングポリシーはフローテーブルをさらに含み、入力サイクル識別子はフローテーブル内の入力サイクルフィールドを含む。
これは、ロードバランシング決定を行うときにフローテーブル内の入力サイクルフィールドがさらに考慮され得るため、有益である。
第1の態様のさらなる実装形態では、出力ポート識別子は、フローテーブル内の出力ポートフィールドを含む。
これは、ロードバランシング決定を行うときにフローテーブル内の出力ポートフィールドがさらに考慮され得るため、有益である。
第1の態様のさらなる実装形態では、出力は出力キューを含み、出力識別子は入力サイクル識別子に関連付けられた出力キュー識別子を含み、ネットワークデバイスは、出力キュー識別子に基づいて出力キューを判定するようにさらに構成される。
これは、ロードバランシング決定を行うときにフローテーブル内の出力キューがさらに考慮され得るため、有益である。
特に、出力キュー識別子は、出力キューフィールドである。
第1の態様のさらなる実装形態では、負荷分散インジケータは、フローテーブル内の出力負荷フィールドを含み、ネットワークデバイスは、出力負荷フィールドに基づいて出力負荷を判定するようにさらに構成される。
これは、ロードバランシング決定を行うときにフローテーブル内の出力負荷フィールドがさらに考慮され得るため、有益である。
第1の態様のさらなる実装形態では、ロードバランシングポリシーはセグメントルーティング、SR、ポリシーをさらに含み、入力サイクル識別子はSRポリシー内の到着サイクルフィールドを含む。
これは、ロードバランシング決定を行うときにSRポリシー内の到着サイクルフィールドがさらに考慮され得るため、有益である。
第1の態様のさらなる実装形態では、出力識別子はSRポリシー内のセグメントIDリストを含む。
これは、ロードバランシング決定を行うときにSRポリシー内のセグメントIDリストがさらに考慮され得るため、有益である。
第1の態様のさらなる実装形態では、出力は出力サイクルをさらに含み、出力識別子は出力サイクル識別子をさらに含み、ネットワークデバイスは、出力サイクル識別子に基づいて出力サイクルを判定するようにさらに構成される。
これは、パケットが受信された入力サイクルとは異なる出力サイクルにパケットがシフトされ、それによってロードバランシングまたはバーストの緩和を可能にし得るため、有益である。
特に、出力サイクル識別子はサイクルシフト識別子である。特に、出力サイクルは、サイクルシフト識別子によって示されるように入力サイクルがシフトされるサイクル数だけ入力サイクルとは異なる。例えば、入力サイクルが「1」であり、サイクルシフト識別子が「1」である場合、出力サイクルは「2」である。例えば、入力サイクルが「1」であり、サイクルシフト識別子が「2」である場合、出力サイクルは「3」である。
第1の態様のさらなる実装形態では、負荷分散インジケータは、SRポリシー内の出力負荷フィールドを含み、ネットワークデバイスは、出力負荷フィールドに基づいて出力負荷を判定するようにさらに構成される。
これは、ロードバランシング決定を行うときにSRポリシー内の出力負荷フィールドがさらに考慮され得るため、有益である。
第1の態様のさらなる実装形態では、ロードバランシングポリシーは、入力サイクル識別子に関連付けられたバースト状態識別子をさらに含み、ネットワークデバイスは、ネットワークパケットのバーストが受信されるのに応答して、バースト状態識別子に基づいて出力を判定するようにさらに構成される。
これは、ロードバランシング決定を行うときにSRポリシー内の出力負荷フィールドがさらに考慮され得るため、有益である。
特に、バースト状態識別子は、バースト保護に適したロードバランシングポリシー内の規則を識別する。特に、同じフローに関連する受信されたネットワークパケットの所定の閾値を超えた場合、ネットワークパケットのバーストが受信される。
第1の態様のさらなる実装形態では、ロードバランシングポリシーは、入力サイクル識別子に関連付けられた障害状態識別子をさらに含み、ネットワークデバイスは、ネットワークデバイスによって判定されている障害状態に応答して、障害状態識別子に基づいて出力を判定するようにさらに構成される。
これは、ロードバランシング決定を行うときに障害状態識別子がさらに考慮され得るため、有益である。これにより、ネットワークデバイスは、判定された障害状態に効果的に対応することができる。
特に、障害状態識別子は、障害保護に適したロードバランシングポリシー内の規則を識別する。特に、ネットワークパケットの意図された経路に沿ったリンク障害が判定された場合、ネットワークデバイスによって障害状態が判定される。特に、ネットワークパケットの意図された経路に沿ったノードがネットワークデバイスによって到達できない場合、障害状態が判定される。
第1の態様のさらなる実装形態では、ロードバランシングポリシーは、入力サイクル識別子に関連付けられたロードバランシング状態識別子をさらに含み、ネットワークデバイスは、ロードバランシング状態識別子に基づいて出力を判定するようにさらに構成される。
これは、ロードバランシング決定を行うときにロードバランシング状態識別子がさらに考慮され得るため、有益である。これにより、ネットワークデバイスは、ロードバランシング状態識別子に依存してロードバランシング決定を行い、より効率的に動作することができる。
特に、ロードバランシング状態識別子は、一般的なロードバランシングに適したロードバランシングポリシー内の規則を識別する。特に、ロードバランシング状態識別子は、ネットワークデバイスによって処理されたネットワークパケットがネットワークデバイス内でロードバランシングを受けるべきである場合に適したロードバランシングポリシー内の規則を示す。
第1の態様のさらなる実装形態では、ネットワークデバイスは、ネットワークデバイス内のロードバランシングポリシーを判定し、および／またはネットワークコントローラからロードバランシングポリシーを取得するようにさらに構成される。
これは、ネットワークデバイスがネットワークコントローラから独立して動作し、それによって柔軟性を高め得るため、有益である。これはまた、代替として、ネットワークデバイスがネットワークコントローラと協働して動作し、それによって自身のリソースを節約し得るため、有益である。
特に、ロードバランシングポリシーは、例えば、分散プロトコル、例えば、OSPFから取得された情報に基づいて、ネットワークデバイス内で判定され得る。
本開示の第2の態様は、サイクルベースのロードバランシングのための方法を提供し、方法は、ネットワークデバイスによって、入力サイクル識別子および関連する出力識別子を含むロードバランシングポリシーを取得するステップと、ネットワークデバイスによって、ネットワークデバイスの入力サイクルでネットワークパケットを取得するステップと、ネットワークデバイスによって、入力サイクル、入力サイクル識別子、および関連する出力識別子に基づいてネットワークデバイスの出力を判定するステップと、ネットワークデバイスによって、ネットワークパケットをネットワークデバイスの出力に提供するステップとを含む。
第2の態様の一実装形態では、出力は出力ポートを含み、出力識別子は入力サイクル識別子に関連付けられた出力ポート識別子を含み、方法は、ネットワークデバイスによって、出力ポート識別子に基づいて出力ポートを判定することをさらに含む。
第2の態様のさらなる実装形態では、ロードバランシングポリシーは、入力サイクル識別子に関連付けられた負荷分散インジケータをさらに含み、方法は、ネットワークデバイスによって、負荷分散インジケータに基づいて出力を判定することをさらに含む。
第2の態様のさらなる実装形態では、ロードバランシングポリシーはフローテーブルをさらに含み、入力サイクル識別子はフローテーブル内の入力サイクルフィールドを含む。
第2の態様のさらなる実装形態では、出力ポート識別子は、フローテーブル内の出力ポートフィールドを含む。
第2の態様のさらなる実装形態では、出力は出力キューを含み、出力識別子は入力サイクル識別子に関連付けられた出力キュー識別子を含み、方法は、ネットワークデバイスによって、出力キュー識別子に基づいて出力キューを判定することをさらに含む。
第2の態様のさらなる実装形態では、負荷分散インジケータは、フローテーブル内の出力負荷フィールドを含み、方法は、ネットワークデバイスによって、出力負荷フィールドに基づいて出力負荷を判定することをさらに含む。
第2の態様のさらなる実装形態では、ロードバランシングポリシーはセグメントルーティング、SR、ポリシーをさらに含み、入力サイクル識別子はSRポリシー内の到着サイクルフィールドを含む。
第2の態様のさらなる実装形態では、出力識別子はSRポリシー内のセグメントIDリストを含む。
第2の態様のさらなる実装形態では、出力は出力サイクルをさらに含み、出力識別子は出力サイクル識別子をさらに含み、方法は、ネットワークデバイスによって、出力サイクル識別子に基づいて出力サイクルを判定することをさらに含む。
第2の態様のさらなる実装形態では、負荷分散インジケータは、SRポリシー内の出力負荷フィールドを含み、方法は、ネットワークデバイスによって、出力負荷フィールドに基づいて出力負荷を判定することをさらに含む。
第2の態様のさらなる実装形態では、ロードバランシングポリシーは、入力サイクル識別子に関連付けられたバースト状態識別子をさらに含み、方法は、ネットワークパケットのバーストが受信されたことに応答して、ネットワークデバイスによって、バースト状態識別子に基づいて出力を判定することをさらに含む。
第2の態様のさらなる実装形態では、ロードバランシングポリシーは、入力サイクル識別子に関連付けられた障害状態識別子をさらに含み、方法は、ネットワークデバイスによって判定された障害状態に応答して、ネットワークデバイスによって、障害状態識別子に基づいて出力を判定することをさらに含む。
第2の態様のさらなる実装形態では、ロードバランシングポリシーは、入力サイクル識別子に関連付けられたロードバランシング状態識別子をさらに含み、方法は、ネットワークデバイスによって、ロードバランシング状態識別子に基づいて出力を判定することをさらに含む。
第2の態様のさらなる実装形態では、方法は、ネットワークデバイスによって、ネットワークデバイス内のロードバランシングポリシーを判定すること、および／またはネットワークデバイスによって、ネットワークコントローラからロードバランシングポリシーを取得することをさらに含む。
第2の態様およびその実装形態は、第1の態様およびそのそれぞれの実装形態と同じ利点を含む。
本開示の第3の態様は、コンピュータによって実行されるとき、第2の態様またはその実装形態のいずれかの方法のステップをコンピュータに実行させる命令を含む非一時的コンピュータ可読記憶媒体を提供する。
第3の態様およびその実装形態は、第2の態様およびそのそれぞれの実装形態と同じ利点を含む。
本開示の第4の態様は、プログラムがコンピュータによって実行されるとき、第2の態様またはその実装形態のいずれかの方法のステップをコンピュータに実行させる命令を含むコンピュータプログラム製品を提供する。
第4の態様およびその実装形態は、第2の態様およびそのそれぞれの実装形態と同じ利点を含む。
本開示の第5の態様は、サイクルベースのロードバランシングのためのシステムを提供し、システムは、第1の態様またはその実装形態のいずれかによるネットワークデバイスと、ネットワークコントローラとを備え、ネットワークコントローラによって監視されるネットワークトラフィックに基づいてロードバランシングポリシーを生成し、ロードバランシングポリシーをネットワークデバイスに提供するように構成される。
特に、ネットワークコントローラは、決定論的ネットワーキング（DetNet）ネットワークコントローラまたは時間依存ネットワーキング（TSN）ネットワークコントローラである。
特に、ネットワークコントローラは、共通制御および測定プレーン（Common Control And Measurement Plane）（CCAMP）、Netflow、またはTelemetryなどのプロトコルによってネットワークトラフィックを監視するように構成される。
第5の態様およびその実装形態は、第1の態様およびそのそれぞれの実装形態と同じ利点を含む。
言い換えれば、本開示の実施形態は、複数のネットワーク経路および複数のネットワークサイクルにわたる決定論的ロードバランシング解決策を提供する。ネットワーク経路およびネットワークサイクルにわたってパケットレベルでフローを分割するために、ロードバランシング機構が提供される。フロー分割は、ネットワーク経路のヘッドエンドノードまたは中間ノードで実装され得る。したがって、本開示の実施形態は、リンクおよびサイクルにわたる効率的なロードバランシング、バーストに対する保護、ならびにネットワーク障害後の高速回復を可能にする。ロードバランシングの決定は、ローカルレベルまたはグローバルレベルのいずれかで行われ得る。決定論的ポリシーは、複数の経路／サイクルにわたってトラフィックの負荷を振り分けるために適用され得る。これらのポリシーは、集中レベルおよびローカルレベルにおいて例えば計算され得る。集中レベルでは、コントローラは新しいポリシーを計算し、それらを関連するノードに送信する。ローカルレベルのエントリまたは中間ノードは、（例えば、OSPFのような分散プロトコルから）受信した情報に基づいてポリシーを調整するために、独立して決定を行い得る。負荷分散ポリシーは、エントリノードに分散されたSRポリシーを使用することによって、またはパケットごとに転送経路および送信サイクルへのマッピングを指定するフローテーブルを使用することによって、実装され得る。
本出願において説明されるすべてのデバイス、要素、部および手段は、ソフトウェアまたはハードウェア要素またはそれらの任意の種類の組合せで実装され得ることに留意されたい。本出願において説明される様々なエンティティによって実行されるすべてのステップ、および様々なエンティティによって実行されると説明される機能は、それぞれのエンティティがそれぞれのステップおよび機能を実行するように適合または構成されることを意味することを意図されている。具体的な実装形態の以下の説明において、外部のエンティティによって実行される特定の機能またはステップが、その特定のステップまたは機能を実行するそのエンティティの特定の詳細要素の説明に反映されていない場合でも、それぞれのソフトウェア要素もしくはハードウェア要素またはそれらの任意の種類の組合せにおいてこれらの方法および機能が実装され得ることは、当業者には明確なはずである。
本開示の上で説明された態様および実装形態は、添付の図面に関連して、特定の実装形態の以下の説明において説明される。
図1は、本開示の一実施形態によるネットワークデバイスの概略図を示す。 図2は、本開示の一実施形態によるネットワークデバイスの概略図をより詳細に示す。 図3は、いくつかのネットワーク経路に沿ったロードバランシングの概略図を示す。 図4は、ネットワークデバイスによって使用されるフローテーブルの概略図を示す。 図5は、ネットワークデバイスによって可能にされる障害回復の概略図を示す。 図6は、ネットワークデバイスによって使用されるSRポリシーリストの概略図を示す。 図7は、LoadBalanceType TLVフォーマットの概略図を示す。 図8は、ArrivalCycle TLVフォーマットの概略図を示す。 図9は、CycleShift TLVフォーマットの概略図を示す。 図10は、ロードアウトTLVフォーマットの概略図を示す。 図11は、SRポリシーを用いたロードバランシングシナリオの概略図を示す。 図12は、SRポリシーを用いたバースト保護シナリオの概略図を示す。 図13は、SRポリシーを用いた障害回復シナリオの概略図を示す。 図14は、ロードバランシング経路計算アルゴリズムの概略図を示す。 図15は、バースト保護経路計算アルゴリズムの概略図を示す。 図16は、障害回復経路計算アルゴリズムの概略図を示す。 図17は、本開示の一実施形態による方法の概略図を示す。 図18は、本開示の一実施形態によるシステムの概略図を示す。 図19は、本開示の一実施形態によるシステムの概略図をより詳細に示す。 図20は、本開示の一実施形態によるシステムの動作シナリオの概略図を示す。
図1は、本開示の一実施形態によるネットワークデバイス100の概略図を示す。ネットワークデバイス100は、サイクルベースのロードバランシングのために構成され、したがって、入力サイクル識別子102および関連する出力識別子103を含むロードバランシングポリシー101を取得するように構成される。ネットワークデバイス100は、ネットワークデバイス100の入力サイクル105でネットワークパケット104を取得し、入力サイクル105、入力サイクル識別子102、および関連する出力識別子103に基づいてネットワークデバイス100の出力106を判定するようにさらに構成される。言い換えれば、ロードバランシングポリシー101内の入力サイクル識別子102は、ネットワークパケット104が受信された入力サイクル105に従って、受信されたネットワークパケット104を処理することを可能にする。特に、ネットワークパケット104のための出力106は、ロードバランシングポリシー101に基づいて、ネットワークパケットが受信された入力サイクル105に従って判定される。最後に、ネットワークデバイスは、ネットワークパケット104をネットワークデバイス100の出力106に提供するように構成される。
図2は、本開示の一実施形態によるネットワークデバイス100の概略図をより詳細に示す。図2に示すネットワークデバイス100は、図1のネットワークデバイス100のすべての特徴および機能、ならびに以下の任意選択の特徴を備える。
図2に例示されるように、出力106は出力ポート201を任意選択的に含み得て、出力識別子103は入力サイクル識別子102に関連付けられた出力ポート識別子202を任意選択的に含み得る。ネットワークデバイス100は、出力ポート識別子202に基づいて出力ポート201を判定するように、任意選択的にさらに構成され得る。言い換えれば、ネットワークパケット104が提供される出力106は、ネットワークパケット104が受信された入力サイクル105に従って、出力ポート201レベルにおいて判定され得る。出力ポート201は、ネットワークデバイスの物理ポートであり得る。出力ポート201は、ネットワークプロトコルで使用される出力ポートでもあり得る。
図2にさらに例示されるように、ロードバランシングポリシー101は、入力サイクル識別子102に関連付けられた負荷分散インジケータ203を任意選択的にさらに含み得る。ネットワークデバイス100は、負荷分散インジケータ203に基づいて出力106を判定するように任意選択的に構成され得る。言い換えれば、ロードバランシング中に出力に転送されるパケットの比率または絶対量は、負荷分散インジケータ203に基づいて判定され得る。
図2にさらに例示されるように、出力106は出力キュー204を任意選択的に含み得て、出力識別子103は入力サイクル識別子102に関連付けられた出力キュー識別子205を任意選択的に含み得て、ネットワークデバイス100は出力キュー識別子205に基づいて出力キュー204を判定するように、任意選択的にさらに構成され得る。言い換えれば、出力キュー識別子205は、ネットワークパケット104が受信された入力サイクル105に応じて、ネットワークパケット104を送信するために使用される出力キュー204を判定することを可能にする。
図2にさらに例示されるように、出力106は出力サイクル206を任意選択的に含み得て、出力識別子103は出力サイクル識別子207を任意選択的に含み得て、ネットワークデバイス100は出力サイクル識別子207に基づいて出力サイクル206を判定するように、任意選択的に構成され得る。言い換えれば、出力サイクル識別子207は、ネットワークパケット104が受信された入力サイクル105に応じて、ネットワークパケット104を送信するために使用される出力サイクル206を判定することを可能にする。
図2にさらに例示されるように、ロードバランシングポリシー101は、入力サイクル識別子102に関連付けられたバースト状態識別子208を任意選択的に含み得て、ネットワークデバイス100は、受信されているネットワークパケットのバーストに応答して、バースト状態識別子208に基づいて出力106を判定するように任意選択的に構成され得る。言い換えれば、バースト状態に応じて、ネットワークパケット104を送信するために所定の出力106が選択され得る。
図2にさらに例示されるように、ロードバランシングポリシー101は、入力サイクル識別子102に関連付けられた障害状態識別子209を任意選択的に含み得て、ネットワークデバイス100は、ネットワークデバイス100によって判定された障害状態に応答して、障害状態識別子209に基づいて出力106を判定するように任意選択的に構成され得る。言い換えれば、障害状態に応じて、ネットワークパケット104を送信するために所定の出力106が選択され得る。
図2にさらに例示されるように、ロードバランシングポリシー100は、入力サイクル識別子102に関連付けられたロードバランシング状態識別子210を任意選択的に含み得て、ネットワークデバイス100は、ロードバランシング状態識別子210に基づいて出力106を判定するように任意選択的に構成され得る。言い換えれば、ロードバランシング状態識別子210は、ロードバランシングが手元のネットワークパケット104に望まれるかどうか、またはロードバランシングを適用する必要がないかどうかを示すことを可能にする。
上述した特徴のすべては、例えば、以下の図4、図6のそれぞれを参照して説明されるように、ロードバランシングポリシー101がフローテーブルまたはSRポリシーである場合の両方に適用可能である。
図3は、ネットワークデバイス100によって可能にされるときの、いくつかの経路301、302、303およびいくつかのサイクル310、311、312にわたる（例えば、DetNetまたはTSNトラフィックの）ロードバランシングを例示する。同じネットワークフロー320のパケットは、異なる経路301、302、303を介してルーティングおよびスケジューリングされ得る。図3では、第1のサイクル320および第3のサイクル312におけるネットワークフロー320のパケットは、経路301を介してルーティングされ、第2のサイクル311におけるネットワークフロー320のパケットは、経路302を介してルーティングされる。
図4は、図2によるネットワークデバイス100で使用され得るフローテーブル400の概略図を示す。ロードバランシングポリシー101は、フローテーブル400を任意選択的に含み得て、入力サイクル識別子102は、フローテーブル400内の入力サイクルフィールド401を任意選択的に含み得る。言い換えれば、ロードバランシングポリシー101は、フローテーブル400によって実装され得て、その一方で、入力サイクル識別子102は、入力サイクルフィールド401によって実装され得る。フローテーブル400では、ただ1つの入力サイクルフィールド401に参照符号がラベル付けされているが、上記の教示は、図4において「Cycle_in」とラベル付けされた列に示されたサイクルのいずれにも当てはまる。
図4にさらに例示されるように、出力ポート識別子202は、フローテーブル400内の出力ポートフィールド402を任意選択的に含み得る。言い換えれば、出力ポート識別子は、出力ポートフィールド402によって実装され得る。フローテーブル400では、ただ1つの出力ポートフィールド402が参照符号でラベル付けされているが、上記の教示は、図4において「Port_out」とラベル付けされた列に示されたポートのいずれにも当てはまる。
図4にさらに例示されるように、出力キュー識別子205は、フローテーブル400内の出力キューフィールド403で任意選択的にあり得て、ネットワークデバイス100は、出力キューフィールド403に基づいて出力キュー204を判定するように任意選択的にさらに構成され得る。言い換えれば、出力キュー識別子205は、出力キューフィールド403によって実装され得る。フローテーブル400では、ただ1つの出力キューフィールド403に参照符号がラベル付けされているが、上記の教示は、図4において「Queue out」とラベル付けされた列に示されたキューのいずれにも当てはまる。
図4にさらに例示されるように、負荷分散インジケータ203は、フローテーブル400内の出力負荷フィールド404で任意選択的にあり得て、ネットワークデバイス100は、出力負荷フィールド404に基づいて出力負荷を判定するように任意選択的にさらに構成され得る。言い換えれば、負荷分散インジケータ203は、出力負荷フィールド404によって実装され得る。フローテーブル400では、ただ1つの出力負荷フィールド404に参照符号がラベル付けされているが、上記の教示は、図4において「Load out」とラベル付けされた列に示された項目のいずれにも当てはまる。
図4にさらに例示されるように、バースト状態識別子208は、任意選択的にフローテーブル400内のバースト保護フィールド405であってもよく、ネットワークデバイス100は、バースト保護フィールド405に基づいて出力106を判定するように任意選択的に構成され得る。言い換えれば、バースト状態識別子208は、バースト保護フィールド405によって実装され得る。フローテーブル400では、ただ1つのバースト保護フィールド405が参照符号でラベル付けされているが、上記の教示は、図4において「Burst protection」とラベル付けされた列に示された項目のいずれにも当てはまる。
図4にさらに例示されるように、障害状態識別子209は、フローテーブル400内の障害保護フィールド406で任意選択的にあり得て、ネットワークデバイス100は、障害保護フィールド406に基づいて出力106を判定するように任意選択的に構成され得る。言い換えれば、障害状態識別子208は、障害保護フィールド406によって実装され得る。フローテーブル400では、ただ1つの障害保護フィールド406に参照符号がラベル付けされているが、上記の教示は、図4において「Segment failure」とラベル付けされた列に示された項目のいずれにも当てはまる。
すなわち、サイクルレベルのロードバランシングをサポートするために、フローテーブル400が拡張される。図4では、入力サイクル（Cycle_in 401）、出力キュー（Queue_out 402）、および目標分割比（Load out 404）を識別することを可能にする特定のフィールドを追加することによって、サイクルレベルのロードバランシングをサポートすることがどのように可能であるかが示される。フローテーブル400は、出力負荷をパケット数で記述する。しかしながら、フィールド「Load out」は、サイクル容量のパーセンテージを表すロードバランシング重みによっても判定され得る。
図4に示す例410によれば、サイクルレベルのロードバランシングがどのように実装されるかが説明される。ポート3、サイクル1で受信されると予想されるフロー1は、2つの経路に分割され、ポート1、キュー4で1つのパケットを送信し、ポート2、キュー2で1つのパケットを送信する。
例411によれば、フロー2は2つのサイクルに分割され、ポート2、キュー1を介して1つのパケットを送信し、ポート2、キュー2を介して1つのパケットを送信する。
フロー3の例412によれば、ポート3、サイクル2から受信されたトラフィックは、ポート1、キュー1に完全に転送され、ポート3、サイクル3で受信されたトラフィックは、ポート2、キュー5に完全に転送される。
図4によれば、バースト保護が例413（「Y」でマークされたそれらの規則）で実装される。この場合、各フローの最大バーストサイズは事前に既知であると仮定される。フロー整形は、ネットワーク内の入口ノードで通常は実行されるため、この仮定は現実的である。加えて、フロー内のパケットの最大送信単位（MTU）は既知であると仮定される。この場合、トラフィックのバーストが検出されるたびに、バーストを有するフローは次のように分割される。2つのパケットがポート2、キュー1、および残りのパケット（最大で3つのパケット）がポート2、キュー2。同じことが重みベースのロードバランシングにも当てはまる。「Load out」行の内容を重みに置き換えるだけでよい（すなわち、パケット値が、例えばパーセントで示される相対値で置き換えられる）。バースト検出は、トラフィックが所与の閾値を超えるかどうかを測定することによって例えば実装され得る。このような場合、上述したようにバースト保護規則がアクティブ化される。
例えば、図5に例示されるように、ネットワーク障害は、リンクレベル（図5中の「f1」を参照）で、または共有リスクリンクグループ（Shared Risk Link Group, SRLG）、すなわち、予期しない事象に続いて共に障害が生じ得るリンクのグループのレベルにおいて識別され得る。図4において、フローテーブル400の行414の例は、規則がアクティブ化されなければならない場合に所与の障害f1について指定することを可能にする。すなわち、f1は、例えば、障害状態識別子209であり得る。これは、図5の図と一致しており、ノードBが障害を検出すると、ノードBはフローテーブル400の規則414をアクティブ化し、フロー2のトラフィック（ノードBのポート3において受信される）は、ポート1からポート2、キュー2にリダイレクトされる（それによって、ノードDを介してノードBからノードEにそれぞれのパケットをルーティングする）。同じことが、重みベースのロードバランシングにも当てはまる。
図6は、図2のネットワークデバイス100によって使用され得るSRポリシー600の概略図を示す。
図6に例示されるように、ロードバランシングポリシー101は、SRポリシー600を任意選択的に含み得て、入力サイクル識別子102は、SRポリシー600内の到着サイクルフィールド601を任意選択的に含み得る。言い換えれば、ロードバランシングポリシーは、SRポリシーによって実装され得て、入力サイクル識別子102は、到着サイクルフィールド601によって実装され得る。SRポリシー600では、ただ1つの到着サイクルフィールド601に参照符号がラベル付けされているが、上記の教示は、図6において「ArrivalCycle」とラベル付けされている、SRポリシーに示される到着サイクルのいずれにも当てはまる。
図6にさらに例示されるように、出力識別子103は、SRポリシー600内のセグメントIDリスト602を任意選択的に含み得る。言い換えれば、出力識別子103は、セグメントIDリスト602によって実装され得る。SRポリシー600では、ただ1つのセグメントIDリスト602に参照符号がラベル付けされているが、上記の教示は、図6において「SID List」とラベル付けされている、SRポリシーに示されるセグメントIDリストのいずれにも当てはまる。
図6にさらに例示されるように、負荷分散インジケータ203は、SRポリシー600内の出力負荷フィールド603を任意選択的に含み得て、ネットワークデバイス100は、出力負荷フィールド601に基づいて出力負荷を判定するように任意選択的に構成され得る。言い換えれば、負荷分散インジケータ203は、出力負荷フィールド603によって実装される。SRポリシー600では、ただ1つの出力負荷フィールド603に参照符号がラベル付けされているが、上記の教示は、図6において「Load out」とラベル付けされている、SRポリシーに示される出力負荷フィールドのいずれにも当てはまる。
図6にさらに例示されるように、出力サイクル識別子206は、任意選択的に、SRポリシー600内のサイクルシフト識別子604であり得る。言い換えれば、出力サイクル識別子206は、サイクルシフト識別子604によって実装され得る。SRポリシー600では、ただ1つのサイクルシフト識別子604が参照符号でラベル付けされているが、上記の教示は、図6において「CycleShift」とラベル付けされている、SRポリシーに示されるサイクルシフト識別子のいずれにも当てはまる。
図6にさらに例示されるように、バースト状態識別子208は、SRポリシー600内のロードバランス型識別子605で任意選択的にあり得て、ネットワークデバイス100は、ロードバランス型識別子605に基づいて出力106を判定するように任意選択的にさらに構成され得る。この場合のロードバランス型識別子605は、バースト状態を示す所定の値（例えば、「1」）であり得る。言い換えれば、バースト状態識別子208は、ロードバランス型識別子605によって実装され得る。SRポリシー600では、ただ1つのロードバランス型識別子605が参照符号でラベル付けされているが、上記の教示は、図6において「LoadBalanceType」とラベル付けされた、SRポリシー600に示される項目のいずれにも当てはまる。
図6にさらに例示されるように、障害状態識別子209は、SRポリシー600内のロードバランス型識別子605で任意選択的にあり得て、ネットワークデバイス100は、ロードバランス型識別子605に基づいて出力106を判定するように任意選択的に構成され得る。この場合のロードバランス型識別子605は、障害状態を示す所定の値（例えば、「2」）であり得る。言い換えれば、障害状態識別子209は、ロードバランス型識別子605によって実装され得る。
図6にさらに例示されるように、ロードバランシング状態識別子210は、SRポリシー600内のロードバランス型識別子605で任意選択的にあり得て、ネットワークデバイス100は、ロードバランス型識別子605に基づいて出力106を判定するように任意選択的に構成され得る。この場合のロードバランス型識別子605は、ロードバランシング状態を示す所定の値（例えば、「0」）であり得る。言い換えれば、ロードバランシング状態識別子210は、ロードバランス型識別子605によって実装され得る。
SRポリシー600に対する上述した拡張によれば、決定論的トラフィックのためのサイクルレベルベースのロードバランシングがサポートされる。SRポリシー600に導入された本開示の実施形態によるフィールドは、図6では黒色に着色されている。一般に、SRポリシー600は、パケットヘッダに挿入するラベルスタック（すなわち、SIDリスト）を判定するために、ネットワークの入口ノード（例えば、ネットワークデバイス100）に入る各ネットワークパケット104に適用される決定木である。各ネットワークパケット104について、取られるべきアクションのステータスおよびノード（すなわち、ネットワークデバイス100）内のその到着サイクル105に従って、SIDリストが選択される。これは、ネットワーク内のルーティングを実装することを可能にする。シフトおよび負荷分散に従って、ネットワークパケット104はその後、出力ポート201のうちの1つに影響を受け、利用可能な送信キュー204のうちの1つに挿入される。
次に、図7を参照して、ロードバランス型識別子605の一例が説明される。図7では、ロードバランス型識別子605は、SRポリシー600が（i）サイクルレベルのロードバランシング、（ii）バースト管理、または（iii）障害回復のために考案されたかどうかを識別するLoadBalanceType Type-Length-Value（TLV）として具現化され得る。サイクルレベルのロードバランシングの場合、関連する値は「0」であり、バースト管理の場合、関連する値は「1」であり、障害回復の場合、関連する値は「2」である。
次に、到着サイクルフィールド601の一例が、図8を参照して説明される。SRポリシー600は、到着サイクルフィールド601に従って、使用されるべきIDのリストおよび関連する分割（ロードアウトフィールド）を定義することを可能にする。フローが数サイクルにわたってパケットを送信し得る限り、サイクルごとのSRリストが定義される（例えば、図6のArrivalCycle11～ArrivalCycle1m）。この情報は、図8に示されるように、ArrivalCycle TLVに保持される。
次に、サイクルシフト識別子604の一例が、図9を参照して説明される。SRポリシーはまた、どのスケジューリングがネットワークノードの各ネットワークパケットに適用されるかを判定するために、（サイクルシフト識別子604である）CycleShift TLVを必要とし得る。サイクルシフト識別子604は、ネットワークパケットが受信された入力サイクル105に対して、ネットワークパケットがどの出力サイクルにスケジューリングされるかを特に示す。
次に、出力負荷フィールド603の一例が、図10を参照して説明される。出力負荷フィールド603は、同じ入力サイクル105内のフレームを複数の発信経路およびサイクルにわたって分割するためのロードアウトTLVとして実装され得る。SRポリシー600に含まれるロードアウトTLVは、パケット数やサイクル容量のパーセンテージで表され得る。
図11、図12、および図13を参照して、次に、ネットワークデバイス100によって実装されるサイクルレベルのロードバランシング機構によって対処され得る3つのユースケース、すなわち、パケットのロードバランシング（図11）、バースト保護（図12）、および高速障害回復（図13）が説明される。
図11は、SRポリシー600を使用してロードバランシング問題がどのように解決されるかを例示する。
図11のセクション1100は、異なるサイクルに関連するネットワークパケット104を記述するために使用される表を示す。各列1101、1102、1103は異なるサイクルに関連する。列1101はサイクル1に関連し、要求「2」に関連する2つのパケットと、要求「3」に関連する2つのパケットとを含む。列1102はサイクル2に関連し、要求「1」に関連する1つのパケットと、要求「3」に関連する1つのパケットと、要求「2」に関連する1つのパケットとを含む。列1103はサイクル3に関連し、要求「1」に関連する2つのパケットと、要求「2」に関連する2つのパケットとを含む。この表1100は、図11、図12、図13、図14、図15、および図16で説明したセグメントルーティングに一般に適用される。
セクション1104には、本開示によるロードバランシング・セグメント・ルーティングが例示される。本開示によるネットワークデバイス100は、例えば、セクション1104のノードdによってこれにより実装される。
セクション1104において、ノードbは、ネットワークパケット104をノードdに送信する。サイクル1では、要求「2」に関連する3つのネットワークパケット104が送信される。サイクル2では、要求「2」に関連する別の3つのネットワークパケット104が送信され、サイクル3では、要求「2」に関連する別の3つのネットワークパケット104が送信される。さらに、ノードaは、ネットワークパケット104をノードdに送信する。サイクル1では、要求「1」に関連する1つのネットワークパケット104が送信される。サイクル2では、要求「1」に関連する別のネットワークパケット104が送信され、サイクル3では、要求「1」に関連する別のネットワークパケット104が送信される。
すなわち、ノードd（すなわち、ネットワークデバイス100）は、サイクル1、2および3の各々において4つのネットワークパケット104を受信する。図11にも例示されるSRポリシー600内の情報は、これらのネットワークパケット104をノードhに送信するために使用され、ネットワークパケット104の負荷は、経路d、e、hにわたって、および経路d、f、hにわたって振り分けられる。例示を容易にするために、例示されるSRポリシー600は、図11の要求「2」にのみ適用される。しかしながら、同じ動作原理が、要求「1」のネットワークパケット104にも適用される。
セクション1104の表1101’（表1100の一般的な説明に準拠する）に例示されるように、サイクル1において、要求「2」に関連するネットワークパケット104がノードdからノードfに転送される。このネットワークパケット104をノードfに転送するためのノードdの出力106は、到着サイクルフィールド601およびセグメントIDリスト602（特にSID「20002」）に基づいて特に選択され得る。さらに、出力負荷は、出力負荷フィールド603に基づいて判定され得る。出力負荷フィールド603の値が「1」であるので、サイクル1に到着した、要求「2」に関連する3つのネットワークパケット104のうちの1つが、サイクル1においてノードfに転送される。図11においてサイクルシフト識別子604が「0」であることは、ネットワークパケット104を送信するための出力サイクル206がこのネットワークパケット104の入力サイクル105と同じであること、すなわちサイクル1であることを示す。
図11の表1101’にさらに例示されるように、サイクル2において、要求「2」に関連するネットワークパケット104がノードdからノードfに転送される。このネットワークパケット104をノードfに転送するためのノードdの出力106は、到着サイクルフィールド601’およびセグメントIDリスト602’（特にSID「20003」）に基づいて特に選択され得る。さらに、出力負荷は、出力負荷フィールド603’に基づいて判定され得る。出力負荷フィールド603’の値が「1」であるので、サイクル2に到着した、要求「2」に関連する3つのネットワークパケット104のうちの1つが、ノードfに転送される。図11においてサイクルシフト識別子604’が「0」であることは、ネットワークパケット104を送信するための出力サイクル206がこのネットワークパケット104の入力サイクル105と同じであること、すなわちサイクル2であることを示す。
図11の表1101’にさらに示されるように、サイクル3において、要求「3」に関連するネットワークパケット104がノードdからノードfに転送される。このネットワークパケット104をノードfに転送するためのノードdの出力106は、到着サイクルフィールド601’’およびセグメントIDリスト602’’（特にSID「20001」）に基づいて特に選択され得る。さらに、出力負荷は、出力負荷フィールド603’’に基づいて判定され得る。出力負荷フィールド603’’の値が「1」であるので、サイクル2に到着した、要求「2」に関連する3つのネットワークパケット104のうちの1つが、ノードfに転送される。図11においてサイクルシフト識別子604’’が「0」であることは、ネットワークパケット104を送信するための出力サイクル206がこのネットワークパケット104の入力サイクル105と同じであること、すなわちサイクル3であることを示す。
図11の表1101’にさらに例示されるように、サイクル1、2、および3の各々における要求「1」に関連するネットワークパケット104には、上述したのと同様のネットワークパケットの処理が適用される。要求「1」に属し、サイクル1においてノードdで受信されたネットワークパケット104は、サイクル1においてノードfに提供される。要求「1」に属し、サイクル2においてノードdで受信されたネットワークパケット104は、サイクル2においてノードfに提供される。要求「1」に属し、サイクル3においてノードdで受信されたネットワークパケット104は、サイクル3においてノードfに提供される。
すなわち、表1101’の表記によれば、ノードdで受信された負荷の半分は、経路d、f、hを介してノードhに提供される。ノードdで受信された負荷の後半部分は、経路d、e、hを介してノードhに提供される。図11では、これは表1101’’によって例示される。
セクション1104の表1101’’（表1100の一般的な説明に準拠する）に例示されるように、サイクル1において、要求「2」に関連する2つのネットワークパケット104が、ノードdからノードeに転送される。これらのネットワークパケット104をノードeに転送するためのノードdの出力106は、到着サイクルフィールド601およびセグメントIDリスト6012（特にSID「40002」）に基づいて特に選択され得る。さらに、出力負荷は、出力負荷フィールド6013に基づいて判定され得る。出力負荷フィールド6013の値が「2」であるので、サイクル1に到着した、要求「2」に関連する3つのネットワークパケット104のうちの2つが、ノードeに転送される。図11においてサイクルシフト識別子6014が「0」であることは、ネットワークパケット104を送信するための出力サイクル206がこのネットワークパケット104の入力サイクル105と同じであること、すなわちサイクル1であることを示す。
図11の表1101’’にさらに示されるように、サイクル2において、要求「2」に関連する2つのネットワークパケット104がノードdからノードeに転送される。これらのネットワークパケット104をノードeに転送するためのノードdの出力106は、到着サイクルフィールド601’およびセグメントIDリスト6012’（特にSID「40003」）に基づいて特に選択され得る。さらに、出力負荷は、出力負荷フィールド6013’に基づいて判定され得る。出力負荷フィールド6013の値が「2」であるので、サイクル2に到着した、要求「2」に関連する3つのネットワークパケット104のうちの2つが、ノードeに転送される。図11においてサイクルシフト識別子6014’が「0」であることは、ネットワークパケット104を送信するための出力サイクル206がこのネットワークパケット104の入力サイクル105と同じであること、すなわちサイクル2であることを示す。
図11の表1101’’にさらに例示されるように、サイクル3において、要求「3」に関連する2つのネットワークパケット104がノードdからノードeに転送される。これらのネットワークパケット104をノードeに転送するためのノードdの出力106は、到着サイクルフィールド601’’およびセグメントIDリスト6012’’（特にSID「40001」）に基づいて特に選択され得る。さらに、出力負荷は、出力負荷フィールド6013’’に基づいて判定され得る。出力負荷フィールド603’’の値が「2」であるので、サイクル3に到着した、要求「2」に関連する3つのネットワークパケット104のうちの2つが、ノードeに転送される。図11においてサイクルシフト識別子6014’’が「0」であることは、ネットワークパケット104を送信するための出力サイクル206がこのネットワークパケット104の入力サイクル105と同じであること、すなわちサイクル3であることを示す。
ノードfからノードhへの要求1および2の転送は、従来のセグメントルーティングによって実装され得る。ノードeからノードhへの要求2の転送は、従来のセグメントルーティングによって実装され得る。
言い換えれば、図11のSRポリシー600は、2つの異なる経路（すなわち、経路b、d、f、hおよび経路b、d、e、h）にわたって要求2のトラフィックの負荷を振り分けることを可能にする。各サイクルのパケットには、分割1-2が適用される。ノードdに正しいインターフェース上でトラフィックをルーティングさせるために、対応するSIDリストが各パケットに添付される。例えば、サイクル11の3つのパケット（参照符号601 ’ ’でラベル付けされている）は、次のように分割される。SID40001を使用することによってリンクd-eにわたって2つ、SID20001を使用することによってリンクd-fにわたって1つ。このロードバランシング決定の後、リンクの負荷はより良好に分散され、最大リンク利用率（MLU）が低減される。
図12は、SRポリシー600を使用してバースト保護がどのように提供されるかを例示する。図12では、SRポリシー600は、ネットワークパケット104を、それらが受信された入力サイクル105とは異なる出力サイクル206に移動させて、ネットワークパケット104のバーストを緩和するために、（ネットワークデバイス100を実装する）ノードbによって使用され得る。図12において、表1201は、ノードbにおけるネットワークパケット104の処理を説明するために使用される。図11の表1100の説明は、図12の表1201にも当てはまる。
表1201は、通常のトラフィックに関連するネットワークパケット104のセクション1202と、バースト状態中にノードbに（すなわち、ネットワークデバイス100に）到着するネットワークパケット104のセクション1203とを含む。
セクション1202に例示されるように、サイクル1の通常動作中、要求「2」に関連する3つのパケットがノードbに到着する。サイクル2において、要求「2」に関連する3つのパケットもノードbに到着する。最後に、サイクル3において再び、要求「2」に関連する3つのパケットがノードbに到着する。言い換えれば、通常の動作状態では、要求「2」のトラフィックは3|3|3である。
しかしながら、バースト状態が現れると（セクション1202およびセクション1203に一緒に例示されるように）、サイクル1では要求「2」に関連する6つのパケットがノードbに到着し、サイクル2では要求「2」に関連する3つのパケットが到着し、サイクル3では要求「2」に関連する3つのパケットが到着する。言い換えれば、着信バーストは、3|3|3である通常のトラフィックに加えて、0|0|3である。本開示によれば、バーストによって引き起こされる超過トラフィックが、ネットワークパケット104のバーストが受信されないこれらのサイクルに分散され得る。
セクション1203に例示されるように、要求「2」に関連し、バースト状態中に受信される3つのネットワークパケット104のうちの1つは、サイクル1からサイクル2に移動させられる。すなわち、このネットワークパケット104は、第1の入力サイクル105で受信され、第2の出力サイクル206で出力される。ノードb（すなわち、ネットワークデバイス100）は、この決定を、特に、到着サイクルフィールド601と、SRポリシー600のサイクルシフト識別子604とに基づかせ得る。サイクルシフト識別子604が「1」に設定されていることは、ネットワークパケット104が第1の入力サイクル105から第2の出力サイクル206に「1つ」だけシフトされていることを特に示す。
セクション1203に例示されるように、要求「2」に関連し、バースト状態中に受信される3つのネットワークパケット104のうちの別の1つは、サイクル1からサイクル3に移動させられる。すなわち、このネットワークパケット104は、第1の入力サイクル105で受信され、第3の出力サイクル206で出力される。ノードb（すなわち、ネットワークデバイス100）は、この決定を、特に、到着サイクルフィールド601と、図12に示されるSRポリシー600のサイクルシフト識別子604’とに基づかせ得る。サイクルシフト識別子604’が「2」に設定されていることは、ネットワークパケット104が第1の入力サイクル105から第3の出力サイクル206に「2つ」だけシフトされていることを特に示す。
これにより、それぞれの入力サイクル105に応じて、ネットワークパケット104を出力サイクル206にシフトすることが可能になる。
図12にさらに示されるように、ロードバランス型識別子605は「1」に設定され、図12のSRポリシー600がバースト保護のためであることを示す。例示を容易にするために、図12のSRポリシー600は、要求「2」のみをカバーする。
言い換えれば、バーストの超過トラフィックは、3つのサイクルにわたって分散され、1つのサイクルあたり1つのパケットを置く。SRポリシー600によれば、トラフィックはその後、d-eリンクとd-fリンクとの間で等しく分割される。これは、例えば、図11を参照して説明した動作方式に従って行われる。
ネットワークデバイス100によって提供される解決策がなければ、要求1が存在するために、バーストはリンクd-f上で受け入れることができなかった。複数のサイクルにわたってバーストを拡散する可能性は、より良好なリンク利用を可能にする。
図13は、サイクルレベルのロードバランシングを実装するSRポリシー600を使用して、障害保護がどのように提供されるかを例示する。SRポリシー600は、ノードdとノードeとの間で障害f1が検出された場合に、トラフィックをd-eリンクからd-gリンクに切り替えるために使用される。
図13に示されるように、ロードバランス型識別子605は「2」に設定され、図13のSRポリシー600が障害保護のためであることを示す。すなわち、ロードバランス型識別子605は、障害状態識別子209であり得る。言い換えれば、障害状態f1がネットワークデバイス100によって判定されたことに応答して、障害状態識別子209を含むSRポリシー600が使用される。
図13では、障害状態中のネットワークパケット104の転送が表1301によって例示される。図11の表1100の説明は、図13の表1301にも当てはまる。
障害状態f1がノードd（すなわち、ネットワークデバイス100）によって検出されると、SRポリシーのロードバランス型識別子605が「2」に設定されていることは、このSRポリシー600が障害状態を緩和するために使用されることを示す。
表1301に示されるように、サイクル1において、要求「2」に関連する2つのネットワークパケット104がノードdからノードgに転送される。ノードdは、この決定を、特に到着サイクルフィールド601およびSIDリスト602（特にSID「60002」）に基づかせ得る。出力負荷フィールド603が「2」であることは、サイクル1で2つのネットワークパケット104が送信されることを示す。
表1301にさらに示されるように、サイクル2において、要求「2」に関連する2つのネットワークパケット104がノードdからノードgに転送される。ノードdは、この決定を、特に到着サイクルフィールド601’およびSIDリスト602’（特にSID「60003」）に基づかせ得る。出力負荷フィールド603’が「2」であることは、サイクル2で2つのネットワークパケット104が送信されることを示す。
表1301にさらに示されるように、サイクル3において、要求「2」に関連する2つのネットワークパケット104がノードdからノードgに転送される。ノードdは、この決定を、特に到着サイクルフィールド601’’およびSIDリスト602’’（特にSID「60004」）に基づかせ得る。出力負荷フィールド603’’が「2」であることは、サイクル3で2つのネットワークパケット104が送信されることを示す。
言い換えれば、SRポリシー600は、障害状態f1の場合に、かつ入力サイクル105に応じて、どのSIDリスト602、602’、602’’を使用するかを指定し得る。
図14は、ロードバランシングに使用され得る経路計算アルゴリズムを示す。図14に示されるように、各要求dに対して、アルゴリズムは以下のステップを実行する。
－予め定義されたQoS／QoEを考慮して最大サイクル長で経路pを計算するステップ、
－経路p内のノードの各対について、これら2つのノード間の経路pによって考慮されるQoS／QoEを考慮するk個のサブ経路Pp（例えば、k個の最短経路またはk個の最大分離最短経路）を計算するステップであって、すべての計算された経路Ppは、再順序付けを保証するためにバッファを使用することによってジッタおよびパケット損失がないことを保証するために有効である、ステップ、
－すべてのリンクの最大サイクル利用率が最小であり、使用されるサブ経路の数が制限されるように、選択されたサブ経路上でトラフィックを割り当てるステップ、ならびに
－フローテーブル400、SRポリシー600をそれぞれ更新するために、結果として得られるロードバランシングポリシー101をネットワークデバイス100に送信するステップ。
インストールされるバーストのサイズは、例えば、サイクルxによる最大パケット数として計算される（サイクル長（プライマリ経路）－サイクル長（最小バックアップ経路）－（DetNetのためのキュー数－1））。
図15は、（セクション1501における）要求d1、d2、およびd3のセグメントルーティング、ならびに（セクション1502における）要求d2のバースト状態の緩和を示す。
セクション1501に示されるネットワークでは、要求d1は、ノードaからノードhにルーティングされ、サイクル1、2、および3の各々において、3つのネットワークパケット104のうちのいくつかを搬送する。同じネットワークにおいて、要求d2は、ノードbからノードhにルーティングされ、サイクル1、2、および3の各々において2つのネットワークパケット104のうちのいくつかを搬送する。さらに、要求d3は、ノードcからノードhにルーティングされ、サイクル1、2、および3の各々において3つのネットワークパケット104のうちのいくつかを搬送する。ルーティングは、図11、より具体的にはセクション1100の説明に沿って特に実行される。
セクション1502に例示されるように、（ネットワークデバイス100を実装する）ノードdでは、要求d2に対するネットワークパケット104のバーストが現れる。セクション1501では、2つのネットワークパケット104が要求d2のサイクル1に存在していたが、セクション1502では、6つのネットワークパケット104がノードdにおいてサイクル1で転送される必要がある。6つのネットワークパケット104のこのバーストは、図12の教示を要求d2に適用すること、すなわちノードdにおける第1の時間およびノードfにおける第2の時間に適用することによって緩和される。毎回、1つのネットワークパケットがサイクル1からサイクル2にシフトされ、別のネットワークパケットがサイクル1からサイクル3にシフトされる。これは、図15において参照符号1201、1202および1203によって例示される。これにより、バーストは緩和され、ノードhに影響を与えない。
以下のバースト保護経路計算アルゴリズムは、図12または図15の教示に沿って例えば適用され得る。経路計算のために以下のステップが実行され得る（ここで、Pdは、例えば、図14によるアルゴリズムにおいて計算された要求dの代替的なサブ経路のセットであり得る）。
－Pd中の各経路pについて、最大バースト吸収を計算するステップ、
－バーストが要求dに現れる場合、バースト吸収が依然として最小になるように、要求dのバーストの負荷を振り分けるステップ、および
－フローテーブル400、SRポリシー600をそれぞれ更新するために、結果として得られるロードバランシングポリシー101をネットワークデバイス100に送信するステップ。
図16は、（セクション1601における）要求d1、d2、およびd3のセグメントルーティング、ならびに（セクション1602における）要求d2のネットワーク障害の緩和を示す。
セクション1601に示されるネットワークでは、要求d1はノードaからノードhにルーティングされ、サイクル1では0個のネットワークパケット104、サイクル2では1つのネットワークパケット104、サイクル3では2つのネットワークパケット104を搬送する。同じネットワークでは、要求d2はノードbからノードhにルーティングされ、サイクル1では2つのネットワークパケット104、サイクル2では1つのネットワークパケット104、サイクル3では2つのネットワークパケット104を搬送する。さらに、要求d3はノードcからノードhにルーティングされ、サイクル1では2つのネットワークパケット104、サイクル2では1つのネットワークパケット104、サイクル3では0個のネットワークパケット104を搬送する。ルーティングは、図11、より具体的にはセクション1100の説明に沿って特に実行される。
セクション1602に例示されるように、（ネットワークデバイス100を実装する）ノードdから始まり、ノードfを介してノードhに到達する経路には、障害f1が現れる。この障害は、ノードd、eおよびhを介して要求d1およびd3を再ルーティングし、ノードd、gおよびhを介して要求d2を再ルーティングすることによって軽減される。どちらの場合も、再ルーティングは、図13の教示を適用することによって実装される。
以下の障害回復経路計算アルゴリズムは、図13または図16の教示に沿って適用され得る。以下のステップが実行され得る（ここで、Pdは、例えば、図14によるアルゴリズムで計算された要求dの代替経路のセットであり得る）。
－障害のあるリンクのセットを含むすべての経路に対して、再ルーティング手順を呼び出すステップ、
－障害のあるリンクのセットを回避するために、要求dの経路pのための再ルーティング手順を実行するステップ、
－障害のあるリンクのセットを回避するPd内のバックアップ経路p’を見つけるステップ、
－ネットワークパケットの順序を考慮して、バックアップ経路p’のセット上の障害のあるリンクのセットによって影響を受けるdのすべてのネットワークパケットを再ルーティングするステップ、および
－フローテーブル400、SRポリシー600をそれぞれ更新するために、結果として得られるロードバランシングポリシー101をネットワークデバイス100に送信するステップ。
ロードバランシングポリシー101は、上記のアルゴリズムのいずれか1つに従ってネットワークデバイス100内で例えば判定され得る。これらのアルゴリズムによれば、ロードバランシングポリシー101は、ネットワークデバイス100の外部、例えばネットワークコントローラ内でも取得され得る。次いで、ロードバランシングポリシー101は、ネットワークコントローラからネットワークデバイス100で受信され得る。
図17は、本開示の一実施形態によるサイクルベースのロードバランシングのための方法1700を示す。サイクルベースのロードバランシングのための方法1700は、ネットワークデバイス100によって、入力サイクル識別子102および関連する出力識別子103を含むロードバランシングポリシー101を取得する第1のステップ1701を含む。方法1700は、ネットワークデバイス100によって、ネットワークデバイス100の入力サイクル105でネットワークパケット104を取得する第2のステップ1702を含む。方法1700は、ネットワークデバイス100によって、入力サイクル105、入力サイクル識別子102、および関連する出力識別子103に基づいてネットワークデバイス100の出力を判定する第3のステップ1703を含む。方法1700は、ネットワークデバイス100によって、ネットワークパケット104をネットワークデバイス100の出力106に提供する最後のステップ1704で終了する。
図18は、サイクルベースのロードバランシングのためのシステム1800を示す。システム1800は、上記の図のいずれかに記載されたネットワークデバイス100を備える。システム1800は、ネットワークコントローラ1801によって監視されるネットワークトラフィック1802に基づいてロードバランシングポリシー101を生成し、ロードバランシングポリシー101をネットワークデバイス100に提供するように構成されたネットワークコントローラ1801をさらに備える。
システム1800のより詳細な方が図19に示されており、これについては以下で説明される。
図19は、サイクルベースのロードバランシングのためのシステム1800をより詳細に示す。図19では、コントローラ1801（例えば、DetNetまたはTSNネットワークコントローラであり得る）は、共通制御および測定プレーン（CCAMP）、NetFlow、またはTelemetryなどの標準プロトコルを使用してネットワークからトラフィックまたはトラフィック統計を収集する（例えば、周期的統計収集（periodic statistic collection, PSC）モジュール1901によって）。トラフィック統計は、新しい着信フローに関する情報、またはキューおよび帯域幅利用に関する情報を含み得る。ネットワークトラフィックおよび／またはトラフィック統計は、ネットワークデバイス100からも受信され得る。この目的のために、ネットワークデバイス100は、この情報をコントローラ1801に送信し得る、ネットワーク統計およびトラフィック収集モジュール1904を使用する。
トラフィックまたはトラフィック統計を使用することにより、コントローラ1801のロードバランシングポリシー計算モジュール1902は、新しい構成（すなわち、例えばフローテーブル400の更新またはSRポリシー600の更新のために使用されるロードバランシングポリシー101）を判定し得る。これらの構成の判定は、イベント（例えば、ノード、例えばネットワークデバイス100からのリクエスト）によって例えばトリガされ得る。次いで、例えばロードバランシングポリシー分配モジュール1903によって、新しい構成がネットワークデバイス100に展開され得る。ロードバランシングポリシー分配モジュール1903は、関連するネットワークデバイス100のロードバランシングポリシー101（例えば、フローテーブル400またはSRポリシー600を含む）を更新することを担当する。これらのロードバランシングポリシー101は、標準メッセージを介してネットワークデバイス100（例えば、DetNetまたはTSNデバイスに実装される）に送信され得る。
ネットワークデバイス100が新しいロードバランシングポリシー101を受信すると、それに応じてそのローカルロードバランシングポリシー101（例えば、そのフローテーブル400、またはSRポリシー600）を更新し得る。ネットワークデバイス100は、ネットワークトラフィックにおけるフローパターン、リンク状態、またはポート状態をチェックし得て、ネットワークコントローラ1801から受信したロードバランシングポリシー101を適用し、測定された環境ネットワーク状態に従ってそれを適用することを決定し得る。ロードバランシングポリシー101を適用することは、特に図19のセクション1905およびセクション1906に例示される。セクション1905および1906は、経路B、D、Fにわたってどのようにサイクル2のネットワークパケット104の負荷が振り分けられるかを具体的に示している。ネットワークデバイス100はまた、ポート利用率を監視し、収集された統計をコントローラ（例えば、ネットワーク統計およびトラフィック収集モジュール1904によって行われる）に報告する役割も担う。
ロードバランシングポリシー101が適用される必要があるかどうか、およびどのロードバランシングポリシーが適用される必要があるかを決定することに続く一般的なプロセスが図20に示される。ステップ2001において、ネットワークコントローラ1801は、新しいまたは更新されたロードバランシングポリシー101を事前対応的に計算し、PEノードに（すなわち、ネットワークノード100に）送信する。新しいロードバランシングポリシー101の計算は、ネットワーク統計に基づいており、ロードバランシング、バースト保護、または障害回復問題を解決するために使用され得る。ネットワークコントローラ1801は、完全なネットワークビューを有するので、ロードバランシングポリシー101がフロー間の干渉を導入しないことを保証しなければならない。ステップ2002において、新しいロードバランシングポリシー101は、将来の使用のためにネットワークノード（すなわち、ネットワークデバイス100）に格納される。現在観測されている統計に基づいて、ネットワークデバイス100は、ステップ2003でどのポリシーを適用するかを決定する。統計の収集する役割も担うノードは、ステップ2004で、監視されるトラフィックに関する更新された情報をネットワークコントローラ1801に送信する。これは、周期的に行われ得る、または新しい着信フローのロードバランシングポリシー101がないなどの特定のイベントによってトリガされ得る。
特定の実施形態では、ローカルノード（すなわち、ローカルネットワークデバイス100）は、それらのローカルロードバランシングポリシー101を計算し、それらのトラフィックルーティングを変更し得る。これは、ローカルノードがネットワークの決定論的性能を保証する決定を下すのに十分な情報（例えば、ネットワークコントローラ1801からの）を有するという仮定の下で行われ得る。フローテーブル400の場合、中間ノードは転送規則を修正し得て、SRポリシー600の場合、ノードはポップ操作を介してSRヘッダのリストを修正し得る。
本発明は、実装形態と同様に例として様々な実施形態に関連して説明された。しかし、図面、本開示および独立請求項の検討から、当業者および請求された発明を実施する者によって他の変形例が理解され、生み出されることが可能である。請求項および説明では、「含む、備える（comprising）」という語は他の要素またはステップを除外せず、不定冠詞「1つの（a）」または「1つの（an）」は複数を除外しない。単一の要素または他のユニットは、請求項に列挙された、いくつかのエンティティまたは項目の機能を果たし得る。特定の手段が互いに異なる従属請求項に記載されているというだけで、このことが、これらの手段の組合せが有利な実現例に用いられないことを示すものではない。
100 ネットワークデバイス、ネットワークノード
101 ロードバランシングポリシー
102 入力サイクル識別子
103 出力識別子
104 ネットワークパケット
105 入力サイクル、到着サイクル
106 出力
201 出力ポート
202 出力ポート識別子
203 負荷分散インジケータ
204 出力キュー
205 出力キュー識別子
206 出力サイクル
207 出力サイクル識別子
208 バースト状態識別子
209 障害状態識別子
210 ロードバランシング状態識別子
301 経路
302 経路
303 経路
310 サイクル
311 サイクル
312 サイクル
320 ネットワークフロー
400 フローテーブル
401 入力サイクルフィールド
402 出力ポートフィールド
403 出力キューフィールド
404 出力負荷フィールド
405 バースト保護フィールド
406 障害保護フィールド
600 SRポリシー
601 到着サイクルフィールド
601’ 到着サイクルフィールド
601’ ’ 到着サイクルフィールド
602 セグメントIDリスト
602’ セグメントIDリスト
602’ ’ セグメントIDリスト
603 出力負荷フィールド
603’ 出力負荷フィールド
603’ ’ 出力負荷フィールド
604 サイクルシフト識別子
604’ サイクルシフト識別子
604’ ’ サイクルシフト識別子
605 ロードバランス型識別子
1100 セクション、表
1101 列
1101’ 表
1101’ ’ 表
1102 列
1103 列
1104 セクション
1201 表
1202 セクション
1203 セクション
1301 表
1501 セクション
1502 セクション
1601 セクション
1602 セクション
1700 方法
1701 第1のステップ
1702 第2のステップ
1703 第3のステップ
1704 最後のステップ
1800 システム
1801 ネットワークコントローラ
1802 ネットワークトラフィック
1901 周期的統計収集（PSC）モジュール
1902 ロードバランシングポリシー計算モジュール
1903 ロードバランシングポリシー分配モジュール
1904 ネットワーク統計およびトラフィック収集モジュール
1905 セクション
1906 セクション
6012 セグメントIDリスト
6012’ セグメントIDリスト
6012’ ’ セグメントIDリスト
6013 出力負荷フィールド
6013’ 出力負荷フィールド
6013’ ’ 出力負荷フィールド
6014 サイクルシフト識別子
6014’ サイクルシフト識別子
6014’ ’ サイクルシフト識別子

Claims (18)

  1. サイクルベースのロードバランシングのためのネットワークデバイス（100）であって、
    入力サイクル識別子（102）および関連する出力識別子（103）を含むロードバランシングポリシー（101）を取得し、
    前記ネットワークデバイス（100）の入力サイクル（105）でネットワークパケット（104）を取得し、
    前記入力サイクル（105）、前記入力サイクル識別子（102）、および前記関連する出力識別子（103）に基づいて前記ネットワークデバイス（100）の出力（106）を判定し、
    前記ネットワークパケット（104）を前記ネットワークデバイス（100）の前記出力（106）に提供する
    ように構成された、ネットワークデバイス（100）。
  2. 前記出力（106）は出力ポート（201）を含み、前記出力識別子（103）は前記入力サイクル識別子（102）に関連付けられた出力ポート識別子（202）を含み、前記ネットワークデバイス（100）は、前記出力ポート識別子（202）に基づいて前記出力ポート（201）を判定するようにさらに構成された、請求項1に記載のネットワークデバイス（100）。
  3. 前記ロードバランシングポリシー（101）は、前記入力サイクル識別子（102）に関連付けられた負荷分散インジケータ（203）をさらに含み、前記ネットワークデバイス（100）は、前記負荷分散インジケータ（203）に基づいて前記出力（106）を判定するようにさらに構成された、請求項1または2に記載のネットワークデバイス（100）。
  4. 前記ロードバランシングポリシー（101）は、フローテーブル（400）をさらに含み、前記入力サイクル識別子（102）は、前記フローテーブル（400）内の入力サイクルフィールド（401）を含む、請求項1から3のいずれか一項に記載のネットワークデバイス（100）。
  5. 前記出力ポート識別子（202）は、前記フローテーブル（400）内の出力ポートフィールド（402）を含む、請求項2および4に記載のネットワークデバイス（100）。
  6. 前記出力（106）は出力キュー（204）を含み、前記出力識別子（103）は前記入力サイクル識別子（102）に関連付けられた出力キュー識別子（205）を含み、前記ネットワークデバイス（100）は前記出力キュー識別子（205）に基づいて前記出力キュー（204）を判定するようにさらに構成された、請求項4または5に記載のネットワークデバイス（100）。
  7. 前記負荷分散インジケータ（203）は前記フローテーブル（400）内の出力負荷フィールド（404）を含み、前記ネットワークデバイス（100）は前記出力負荷フィールド（404）に基づいて出力負荷を判定するようにさらに構成された、請求項3および請求項4、5、または6のいずれか一項に記載のネットワークデバイス（100）。
  8. 前記ロードバランシングポリシー（101）はセグメントルーティング、SR、ポリシー（600）をさらに含み、前記入力サイクル識別子（102）は前記SRポリシー（600）内の到着サイクルフィールド（601）を含む、請求項1、2、または3に記載のネットワークデバイス（100）。
  9. 前記出力識別子（103）は、前記SRポリシー（600）内のセグメントIDリスト（602）を含む、請求項8に記載のネットワークデバイス（100）。
  10. 前記出力（106）は出力サイクル（206）をさらに含み、前記出力識別子（103）は出力サイクル識別子（207）をさらに含み、前記ネットワークデバイス（100）は前記出力サイクル識別子（207）に基づいて前記出力サイクル（206）を判定するようにさらに構成された、請求項8または9に記載のネットワークデバイス（100）。
  11. 前記負荷分散インジケータ（203）は前記SRポリシー（600）内の出力負荷フィールド（603）を含み、前記ネットワークデバイス（100）は前記出力負荷フィールド（603）に基づいて出力負荷を判定するようにさらに構成された、請求項3および請求項7、8または9のいずれか一項に記載のネットワークデバイス（100）。
  12. 前記ロードバランシングポリシー（101）は前記入力サイクル識別子（102）に関連付けられたバースト状態識別子（208）をさらに含み、前記ネットワークデバイス（100）は、受信されるネットワークパケットのバーストに応答して、前記バースト状態識別子（208）に基づいて前記出力（106）を判定するようにさらに構成された、請求項1から11のいずれか一項に記載のネットワークデバイス（100）。
  13. 前記ロードバランシングポリシー（101）は前記入力サイクル識別子（102）に関連付けられた障害状態識別子（209）をさらに含み、前記ネットワークデバイス（100）は、前記ネットワークデバイス（100）によって判定された障害状態に応答して、前記障害状態識別子（209）に基づいて前記出力（106）を判定するようにさらに構成された、請求項1から12のいずれか一項に記載のネットワークデバイス（100）。
  14. 前記ロードバランシングポリシー（100）は、前記入力サイクル識別子（102）に関連付けられたロードバランシング状態識別子（210）をさらに含み、前記ネットワークデバイス（100）は前記ロードバランシング状態識別子（210）に基づいて前記出力（106）を判定するようにさらに構成された、請求項1から13のいずれか一項に記載のネットワークデバイス（100）。
  15. 前記ネットワークデバイス（100）内の前記ロードバランシングポリシー（101）を判定し、かつ／または前記ロードバランシングポリシー（101）をネットワークコントローラ（1701）から取得するようにさらに構成された、請求項1から14のいずれか一項に記載のネットワークデバイス（100）。
  16. サイクルベースのロードバランシングのための方法（1700）であって、
    ネットワークデバイス（100）によって、入力サイクル識別子（102）および関連する出力識別子（103）を含むロードバランシングポリシー（101）を取得するステップ（1701）と、
    前記ネットワークデバイス（100）によって、前記ネットワークデバイス（100）の入力サイクル（105）でネットワークパケット（104）を取得するステップ（1702）と、
    前記ネットワークデバイス（100）によって、前記入力サイクル（105）、前記入力サイクル識別子（102）、および前記関連する出力識別子（103）に基づいて前記ネットワークデバイス（100）の出力を判定するステップ（1703）と、
    前記ネットワークデバイス（100）によって、前記ネットワークパケット（104）を前記ネットワークデバイス（100）の前記出力（106）に提供するステップ（1704）と
    を含む、方法（1700）。
  17. コンピュータによって実行されるとき、請求項16に記載の方法（1700）のステップを前記コンピュータに実行させる命令を含む、非一時的なコンピュータ可読記憶媒体。
  18. 請求項1から15のいずれか一項に記載のネットワークデバイス（100）と、
    ネットワークコントローラ（1801）であって、前記ネットワークコントローラ（1801）によって監視されるネットワークトラフィック（1802）に基づいてロードバランシングポリシー（101）を生成し、前記ロードバランシングポリシー（101）を前記ネットワークデバイス（100）に提供するように構成された、ネットワークコントローラ（1801）と
    を備える、サイクルベースのロードバランシングのためのシステム（1800）。
JP2022560133A 2020-04-03 2020-04-03 サイクルベースのロードバランシングのためのネットワークデバイス、システム、および方法 Pending JP2023521027A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2020/059573 WO2021197617A1 (en) 2020-04-03 2020-04-03 Network device, system and method for cycle-based load balancing

Publications (1)

Publication Number Publication Date
JP2023521027A true JP2023521027A (ja) 2023-05-23

Family

ID=70285639

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022560133A Pending JP2023521027A (ja) 2020-04-03 2020-04-03 サイクルベースのロードバランシングのためのネットワークデバイス、システム、および方法

Country Status (5)

Country Link
US (1) US20230017561A1 (ja)
EP (1) EP4115565A1 (ja)
JP (1) JP2023521027A (ja)
CN (2) CN115865814A (ja)
WO (1) WO2021197617A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023147884A1 (en) * 2022-02-07 2023-08-10 Huawei Technologies Co., Ltd. Network device and network manager for a network and methods for load balancing in a network

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7339948B2 (en) * 2003-01-22 2008-03-04 Rockwell Automation Technologies, Inc. Industrial controller providing deterministic communication on ethernet
US20060155862A1 (en) * 2005-01-06 2006-07-13 Hari Kathi Data traffic load balancing based on application layer messages
CN102098094A (zh) * 2010-11-04 2011-06-15 董仕 信号周期伸缩及超快速行列变换的方法与器件
US8467294B2 (en) * 2011-02-11 2013-06-18 Cisco Technology, Inc. Dynamic load balancing for port groups
CN104702521A (zh) * 2013-12-06 2015-06-10 中兴通讯股份有限公司 负载均衡方法和装置
US20150326473A1 (en) * 2014-05-09 2015-11-12 Futurewei Technologies, Inc. Service Chain Path Route Reservations
US9705737B2 (en) * 2014-07-21 2017-07-11 Cisco Technology, Inc. Deterministic control loop scheduling
CN105959399B (zh) * 2016-06-17 2019-01-11 华为技术有限公司 一种负载分配的方法和装置
CN108243113B (zh) * 2016-12-26 2020-06-16 深圳市中兴微电子技术有限公司 随机负载均衡的方法及装置
CN109391556B (zh) * 2017-08-10 2022-02-18 深圳市中兴微电子技术有限公司 一种报文调度方法、装置及存储介质
CN110557340B (zh) * 2018-06-04 2023-04-07 中兴通讯股份有限公司 一种负载均衡方法、系统及输入设备
US20190253357A1 (en) * 2018-10-15 2019-08-15 Intel Corporation Load balancing based on packet processing loads

Also Published As

Publication number Publication date
EP4115565A1 (en) 2023-01-11
CN113767597B (zh) 2022-10-25
US20230017561A1 (en) 2023-01-19
CN115865814A (zh) 2023-03-28
WO2021197617A1 (en) 2021-10-07
CN113767597A (zh) 2021-12-07

Similar Documents

Publication Publication Date Title
CN114342331B (zh) 针对不同的服务类别计算和使用不同的路径质量度量
Li et al. OpenFlow based load balancing for fat-tree networks with multipath support
US11588733B2 (en) Slice-based routing
US8427958B2 (en) Dynamic latency-based rerouting
US10454806B2 (en) SDN controller, data center system, and routing connection method
US7902973B2 (en) Alarm reordering to handle alarm storms in large networks
US8170022B2 (en) Method and apparatus for actively discovering internet protocol equal cost multiple paths and associate metrics
US9154394B2 (en) Dynamic latency-based rerouting
US8897141B2 (en) Network system and routing method
CN103329490B (zh) 提高基于分组通信网络的数据传输质量的方法和通信网络
EP3208978A1 (en) Dynamic bandwidth adjustment in packet transport network
US9077479B2 (en) Method and system for adjusting network interface metrics
US20110078237A1 (en) Server, network device, client, and network system
US20170195203A1 (en) Method, apparatus, and system for implementing packet loss detection
CN109088822B (zh) 数据流量转发方法、装置、系统、计算机设备及存储介质
CN114070774A (zh) 数据转发方法及系统
WO2020259259A1 (zh) 一种发送流量的方法和装置
Barakabitze et al. Multipath protections and dynamic link recoveryin softwarized 5G networks using segment routing
US20230017561A1 (en) Network Device, System and Method For Cycle-Based Load Balancing
CN112825512A (zh) 负载均衡方法及装置
EP3338415B1 (en) Routing communications traffic packets across a communications network
Nepolo et al. A predictive ECMP routing protocol for fat-tree enabled data centre networks
WO2022166346A1 (zh) 路径确定方法、网元及计算机可读存储介质
Balakiruthiga et al. A simple congestion avoidance mechanism for opendaylight (odl)-multipath tcp (mptcp) network structure in software defined data center (sddc)
US20230269184A1 (en) Notification-based load balancing in a network

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221109

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221109

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20231228

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240115

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240410