JP7101790B2

JP7101790B2 - サービス機能チェイニングの輻輳フィードバック

Info

Publication number: JP7101790B2
Application number: JP2020544429A
Authority: JP
Inventors: ドナルド・イー・イーストレイク・ザ・サード; アンドリュー・ジー・マリス
Original assignee: ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Priority date: 2018-02-23
Filing date: 2018-06-26
Publication date: 2022-07-15
Anticipated expiration: 2038-06-26
Also published as: KR20200121863A; US20190268268A1; CN111699711A; KR102455886B1; BR112020017130A2; CN111699711B; CN115460114A; EP3750343A4; US11750517B2; WO2019161628A1; US10924405B2; JP2021514594A; MX2020008804A; US20210243124A1; EP3750343A1

Description

関連出願への相互参照
この特許出願は、Donald E. Eastlake IIIらにより2018年2月23日に出願された、発明の名称を「Service Function Chaining Congestion Feedback」とする米国仮特許出願第62/634,584号の利益を主張する、2018年5月11日に出願された、発明の名称を「Service Function Chaining Congestion Feedback」とする米国特許出願第15/977,161号の利益を主張し、これらの教示および開示は参照によりその全体がここに組み込まれる。

サービス機能チェインは、様々なサービスノードグループ内に存在する一連のサービス機能インスタンスから構成される。サービス機能インスタンス（サービスノードまたはサービス機能としても知られる）とは、例えば、ハードウェア機器、または仮想マシン（virtual machine, VM）上で動作するソフトウェアモジュールであり得る。各サービス機能インスタンス（例えば、ファイアウォール、ネットワークアドレス変換（Network Address Translation, NAT）など）は、サービスノードに到着するパケットに処理を適用し、次いでそれらのパケットを処理のために次のサービスノードに転送する。

一実施形態では、この開示は、符号化デバイスによって実行される符号化の方法を含む。この方法は、下流側デバイスによって実行される、上流側デバイスに輻輳を報告する方法を含む。この方法は、下流側デバイスにより、サービス機能チェイニングアーキテクチャ内のパス上の輻輳を示すパケットを受信するステップと、下流側デバイスにより、パケットを受信したことに応答して輻輳報告メッセージを生成するステップであって、輻輳報告メッセージが、サービス機能チェイニングアーキテクチャ内の輻輳の存在を示すフィールドおよびサービス機能チェイニングアーキテクチャ内の輻輳の位置を示すサービスパス識別子を含む、ステップと、下流側デバイスにより、上流側デバイスが輻輳を緩和することを可能にするために上流側デバイスに輻輳報告メッセージを伝送するステップと、を含む。

任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、パケットが複数の未使用ビットフィールドを含み、未使用ビットフィールドのうちの少なくとも2つが、サービス機能チェイニングアーキテクチャ内の輻輳を示す値を含む、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、値が1つまたは複数の2進数によって表現される、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、上流側デバイスが、下流側デバイスから輻輳報告メッセージを受信したことに応答してパケットのフローを計量または方向付けるように構成された分類器を含む、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、下流側デバイスがサービス機能チェイニングアーキテクチャにおける出口ノードである、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、下流側デバイスがサービス機能チェイニングアーキテクチャにおけるサービス機能フォワーダ（service function forwarder, SFF）である、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、パケットがネットワークサービスヘッダ（network service header, NSH）を含み、輻輳報告メッセージがNSHの修正バージョンを含む、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、NSHの修正バージョンがメタデータ（meta data, MD）タイプを識別し、MDタイプに対応するメタデータが1つまたは複数のフィールドまたはタイプ・長さ・値（type length value, TLV）として構造化される、と規定する。

一実施形態では、この開示は、サービス機能チェイニングアーキテクチャにおいて下流側デバイスによって実行される、上流側デバイスに輻輳を報告する方法を含む。この方法は、下流側デバイスにより、ネットワークサービスヘッダ（NSH）内に設定されている2つの輻輳ビットを含むパケットを受信するステップと、下流側デバイスにより、パケットを受信したことに応答して輻輳報告メッセージを生成するステップであって、輻輳報告メッセージが、サービス機能チェイニングアーキテクチャ内のパス上の輻輳の存在およびサービス機能チェイニングアーキテクチャ内の輻輳の位置を示す、ステップと、下流側デバイスにより、サービス機能チェイニングアーキテクチャ内の上流側デバイスに輻輳報告メッセージを伝送するステップであって、輻輳報告メッセージが上流側デバイスに輻輳に対処するように命令する、ステップと、を含む。

任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、輻輳の存在が、パケットのNSH内の少なくとも1つのフィールドを操作し、生成されるときに輻輳報告メッセージ内に、その少なくとも1つのフィールドを含めることによって示される、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、輻輳の位置が、パケットのNSH内のサービスパス識別子を操作し、生成されるときに輻輳報告メッセージ内に、操作されたサービスパス識別子を含めることによって示される、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、下流側デバイスがサービス機能チェイニングアーキテクチャにおける出口ノードである、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、下流側デバイスがサービス機能チェイニングアーキテクチャにおけるサービス機能フォワーダ（SFF）である、と規定する。

一実施形態では、この開示は、サービス機能チェイニングアーキテクチャにおける上流側デバイスを含む。この上流側デバイスは、命令を含むメモリと、メモリと通信するプロセッサと、を含み、プロセッサが、下流側デバイスにパケットを伝送する命令であって、パケットがサービス機能チェイニングアーキテクチャ内のパス上の輻輳を示すように構成された、命令と、パケットの伝送に応答して下流側デバイスから輻輳報告メッセージを受信する命令であって、輻輳報告メッセージが、サービス機能チェイニングアーキテクチャ内の輻輳の存在を示すフィールドおよびサービス機能チェイニングアーキテクチャ内の輻輳の位置を示すサービスパス識別子を含む、命令と、輻輳報告メッセージにおいて識別された輻輳を緩和する命令と、を実行する。

任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、パケットが複数の未使用ビットフィールドを含み、未使用ビットフィールドのうちの少なくとも2つが、サービス機能チェイニングアーキテクチャ内の輻輳を示す値を含む、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、値が1つまたは複数の2進数によって表現される、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、プロセッサが、下流側デバイスから輻輳報告メッセージを受信したことに応答してパケットのフローを計量または方向付ける命令を実行する、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、下流側デバイスがサービス機能チェイニングアーキテクチャにおける出口ノードである、と規定する。任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、下流側デバイスがサービス機能チェイニングアーキテクチャにおけるサービス機能フォワーダ（SFF）である、と規定する。

任意選択で、前述の態様のいずれかにおいて、この態様の別の実装は、パケットがネットワークサービスヘッダ（NSH）を含み、輻輳報告メッセージがNSHの修正バージョンを含む、と規定する。

明確さの目的のために、上記の実施形態のいずれか1つが、本開示の範囲内で新しい実施形態を作り出すためにその他の上記の実施形態のいずれか1つまたは複数と組み合わされてもよい。

これらおよび他の特徴は、添付の図面および特許請求の範囲と併せて用いて以下の詳細な説明からより明確に理解されるであろう。

この開示のより十分な理解のために、ここで、添付の図面および詳細な説明と関連して用いられる以下の簡単な説明への参照が行われ、類似の参照番号は類似の部分を表現する。

サービス機能チェイニングアーキテクチャの概略図である。上流側デバイスから下流側デバイスに伝送されるパケットの一実施形態の概略図である。輻輳報告メッセージを利用するサービス機能チェイニングアーキテクチャの一実施形態の概略図である。下流側デバイスによって実行される、上流側デバイスに輻輳を報告する方法の一実施形態である。サービス機能チェイニングアーキテクチャにおいて下流側デバイスによって実行される、上流側デバイスに輻輳を報告する方法の一実施形態である。ネットワークデバイスの概略図である。

1つまたは複数の実施形態の例示的な実装が下記で提供されるが、開示されるシステムおよび／または方法は、現在知られているか、または存在するかにかかわらず、任意の数の技法を使用して実現され得ることがはじめに理解されるべきである。この開示は、ここで例示され、説明される例示的な設計および実装を含む、下記で例示される例示的な実装、図面、および技法に決して限定されるべきでなく、添付の特許請求の範囲内およびその等価な全ての範囲内で修正され得る。

図1は、サービス機能チェイニングアーキテクチャ100の概略図である。表されたように、サービス機能チェイニングアーキテクチャ100は、入口ノードとして機能し、分類器104を実装するネットワークデバイス102と、サービス機能フォワーダ（SFF）として機能する1つまたは複数のネットワークデバイス106と、様々な異なるサービスノード110を含むサービスノードグループ108と、出口ノードとして機能するネットワークデバイス112とを含む。一実施形態では、ネットワークデバイス102および112の一方または両方もSFFとして機能する。

ネットワークデバイス102、分類器104、ネットワークデバイス106、サービスノード110、およびネットワークデバイス112は、ここで一括してリンク105と呼ばれる、有線接続、無線接続、またはそれらのいくつかの組み合わせを通して通信し得る。この技術分野の当業者は、実際の適用ではサービス機能チェイニングアーキテクチャ100に他のデバイスおよび／または要素が含まれ得ることを理解するであろう。しかしながら、簡潔さの目的のために、これら追加のデバイスおよび／または要素は詳細に説明されない。

ネットワークデバイス102は、入口ノードと呼ばれてもよく、トラフィックソース（表されていない）からパケット（例えばデータパケットなど）を受信するように構成される。トラフィックソースは、例えば、画像、ビデオ、データファイルなどのようなメディアおよび／またはコンテンツを記憶するか、または取得するように構成され得る。トラフィックソースは、メディアおよび／またはコンテンツを、組み立てられるときそのメディアまたはコンテンツを表現する個々のパケットの形式で伝送し得る。トラフィックソースは、例えば、ネットワークデバイス102にパケットを提供または伝送するように構成されたサーバ、ルータ、ゲートウェイ、または他のネットワーク要素であり得る。

表されたように、ネットワークデバイス102は、そこに実装された分類器104を有し得る。他の状況では、分類器104は、ネットワークデバイス102から分離したデバイス上に配置され得る。加えて、いくつかの場合には、1つの分類器104がいくつかのネットワークデバイス102によって共用され得る。下記でより十分に説明されるように、ネットワークノード102の分類器104は、例えば、ネットワークサービスヘッダ（NSH）を付加するように構成され、ネットワークデバイス112はNSHを除去するように構成される。

分類器104は、例えば、ネットワークデバイス102上にインストールされたソフトウェアであり得る。いくつかの場合には、分類器104は、サービスチェインオーケストレータ（表されていない）によって、またはその指図でネットワークデバイス102上にインストールされたソフトウェアである。サービスチェインオーケストレータは、例えば、サービス機能チェイニングアーキテクチャ100を通してネットワークデバイス102からネットワークデバイス112に伝送されるネットワークトラフィックを管理するように構成されたソフトウェア定義ネットワーク（software-defined network, SDN）コントローラ、サーバ（例えば、ラックサーバ）、または他のネットワーク要素であり得る。

分類器104は、ネットワークデバイス102によって受信された各パケットにどの1つまたは複数のサービスノード110が適用されるべきかを決定するように構成される。言い換えると、分類器104は、サービスチェインによってサービスされるべきパケットフローを選択し、サービスノードグループ108間でパケットをどのように経路指定するかを決定する。分類器104はこれを、例えば、各々の入って来るパケットにサービスチェインヘッダを付加することによって行うことができる。サービスチェインヘッダ内の情報はネットワークデバイス106に、サービスノード110のうちのどれが各パケットに適用されるかを示し、ネットワークデバイス106はそれに応じてパケットを転送する。例えば、ネットワークデバイス106はパケットを、パケットヘッダ内の情報に基づいて、パケットに適用されるべき1つまたは複数のサービスノード110を有する特定のサービスノードグループ108に伝送し得る。

各サービスノードグループ108は、ネットワークデバイス106のうちの1つに動作可能に結合される。サービスノードグループ108は、例えば、ハードウェアアプリケーション、または仮想マシン（VM）上で動作するソフトウェアモジュールであり得る。加えて、サービスノードグループ108は、例えば、データセンタであり得る。表されたように、サービスノードグループ108は、異なるタイプの、または異なる機能を有する様々なサービスノード110（サービス機能インスタンスとしても知られる）を含む。サービスノードグループ108内の各サービスノード110は、サービス機能（service function, SF）を適用するように構成される。例えば、サービスノードグループ108のうちの1つは、侵入検出サービス（intrusion detection service, IDS）、侵入保護サービス（intrusion protection service, IPS）、ファイアウォール（firewall, FW）、ネットワークアドレス変換（network address translation, NAT）機能を含み得る。サービスノード108のうちの別のものは、キャッシュ、ロードバランサ（load balancer, LB）、サービス品質（Quality of Service, QoS）機能、広域ネットワーク（wide area network, WAN）最適化コントローラ（WAN optimizing controller, WOC）、および仮想プライベートネットワーク（virtual private network, VPN）機能を含み得る。この技術分野の当業者は、実際の適用では他のサービスノードグループ108に他のサービスノード110が見出され得ることを理解するであろう。

図1のサービス機能チェイニングアーキテクチャ100では、各サービスノードグループ108内のサービスノード110は順次に実行される。サービスノード110が順に実行されるので、サービスノード110はサービス機能チェインと呼ばれるものを形成する。最初のサービスノードグループ108内の各サービスノード110がその処理をパケットに適用する。パケットがサービスノードグループ108内のサービスノード110によって処理された後、パケットは次のサービスノードグループ108に転送されて、当該次のサービスノードグループ108内のサービスノード110からさらなる処理を得る。さらなるサービスノードグループ108が残っていないとき、パケットはネットワークデバイス112に向かって伝送される。

一例として、ネットワークデバイス102内の分類器104は、NSHを付加し、次いでパケットをSFF1とラベル付けされたネットワークデバイス106に伝送する。例示のNSHは、参照によりここに組み込まれる、2018年1月に発行された、P. Quinn., Ed.らによる、「Network Service Header（NSH）」と題する、インターネット技術標準化委員会（Internet Engineering Task Force, IETF）文書リクエストフォーコメンツ（Request for Comments, RFC）8300に説明されている。SFF1とラベル付けされたネットワークデバイス106は、SF1（例えば、IDS）がSF1とラベル付けされたサービスノード110で適用され得るように、サービスノードグループ108にパケットを送信する。次いで処理されたパケットが、SFF1とラベル付けされたネットワークデバイス106に戻される。次に、SFF1とラベル付けされたネットワークデバイス106は、SF2（例えば、IPS）が適用され得るように、次いでサービスグループ108にパケットを送り返し得る。次いで処理されたパケットが、SFF1とラベル付けされたネットワークデバイス106に戻される。このプロセスは、サービスノードグループ108内のサービスまたは処理がサービス機能チェインにおいて指定されたようにパケットに適用されるまで続く。その後、SFF1とラベル付けされたネットワークデバイス106はパケットをSFF2とラベル付けされたネットワークデバイス106に伝送する。

SFF2とラベル付けされたネットワークデバイス106は、SF3（例えば、FW）がSF3とラベル付けされたサービスノード110で適用され得るように、サービスノードグループ108にパケットを送信する。次いで処理されたパケットが、SFF2とラベル付けされたネットワークデバイス106に戻される。次に、SFF2とラベル付けされたネットワークデバイス106は、SF4（例えば、NAT）がサービスノード110で適用され得るように、次いでサービスグループ108にパケットを送り返し得る。次いで処理されたパケットが、SFF2とラベル付けされたネットワークデバイス106に戻される。次に、SFF2とラベル付けされたネットワークデバイス106は、SF5（例えば、LB）がサービスノード110で適用され得るように、次いでサービスグループ108にパケットを送り返し得る。次いで処理されたパケットが、SFF2とラベル付けされたネットワークデバイス106に戻される。このプロセスは、サービスノードグループ108内のサービスまたは処理がサービス機能チェインにおいて指定されたようにパケットに適用されるまで続く。その後、SFF2とラベル付けされたネットワークデバイス106はパケットをネットワークデバイス112に送信し、ネットワークデバイス112は、ネットワークデバイス102によって付加されたNSHを除去する。次いで全て処理されたパケットは、例えば、顧客または宛先に伝送され得る。

いくつかの場合には、ネットワークデバイス102からネットワークデバイス112に進むときにパケットが輻輳に遭遇し得る。下流側ノードに信号を送ってそれらに輻輳を知らせる手順が存在する。この手順は、参照によりここに組み込まれる、2001年9月に発行された、K. Ramakrishnanらによる、「The Addition of Explicit Congestion Notification（ECN）to IP」と題する、インターネット技術標準化委員会（IETF）文書リクエストフォーコメンツ（RFC）3168に説明されている。この手順は、参照によりここに組み込まれる、2017年3月に発行された、G. Fairhurstらによる、「The Benefits of Using Explicit Congestion Notification（ECN）」と題する、IETF文書RFC 8087に説明されている能動的な待ち行列管理において有用であり得る。しかしながら、現在、サービス機能チェイニングアーキテクチャにおいて下流側デバイス（例えば、ネットワークデバイス112またはネットワークデバイス106）が上流側デバイス（例えば、分類器104を実装するネットワークデバイス102）に信号を送るための手順はない。

ここで開示されるのは、下流側デバイスから上流側デバイスに輻輳報告メッセージを送信する方法である。下記でより十分に説明されるように、輻輳報告メッセージを受信すると、上流側デバイスは、例えば、パケットトラフィックを計量する、または将来のトラフィックを、同じサービスシーケンスを実行する異なるサービス機能インスタンスに方向付けるような、輻輳を緩和する措置を取り得る。一実施形態では、輻輳報告メッセージは、上流側デバイスに輻輳を緩和するように要求または命令し得る。

図2は、上流側デバイスから下流側デバイスに（例えば、分類器104を実装するネットワークデバイス102からネットワークデバイス112に、SFF2とラベル付けされたネットワークデバイス106からネットワークデバイス112に、など）伝送されるパケット200の一実施形態の概略図である。表されたように、パケット200は、データ部分202とNSH 204とを含む。実際の適用では、パケット200は、簡潔さの目的のためにここでは省かれている、トランスポートヘッダのような他のフィールドおよびヘッダも含み得る。パケット200のデータ部分202は、例えば、クライアントまたは顧客によって要求された情報またはデータを含む。よって、データ部分202は、画像、ビデオの部分、データファイルなどを含み得る。

一実施形態では、ネットワークサービスヘッダ204は、バージョンフィールド206、運用管理保守（operations, administration and management, OAM）フィールド208、未使用ビット（U）フィールド210、生存時間（time to live, TTL）フィールド212、長さフィールド214、メタデータ（MD）タイプフィールド216、次のプロトコルフィールド218、サービスパス識別子フィールド220、サービス・インデックス・フィールド222、およびメタデータフィールド224のような様々な異なるフィールドを含む。下記でより十分に説明されるように、これら様々なフィールドは1つまたは複数のビットを含むように構成される。特定のフィールドに含まれる1つまたは複数のビットの値に依存して、パケット200を受信するネットワークデバイス（例えば、ネットワークデバイス112）は、情報を提供され、システムパラメータを知らされる、等である。

バージョンフィールド206は、ネットワークサービスヘッダ204の現在のバージョンを示すために1つまたは複数のビットを含むように構成される。OAMフィールド208は、パケット200がOAMパケットであるか否かを示す1つまたは複数のビットを含むように構成される。未使用ビットフィールド210は、下流側デバイス（例えば、ネットワークデバイス112）に、サービス機能チェイニングアーキテクチャ100内で輻輳に遭遇していることを示すために1つまたは複数のビットを含むように構成される。一実施形態では、未使用ビットフィールド210のうちの2つが、下流側デバイスに輻輳指示を提供するために設定される。

TTLフィールド212は、進み得るホップの数を示すために1つまたは複数のビットを含むように構成される。TTLフィールド212の値は、パケット200が別のネットワークデバイスによって受信される毎に減算される。TTLフィールド212の値が0まで減算されたならば、パケット200は廃棄される。長さフィールド214は、ネットワークサービスヘッダ204の長さを示すために1つまたは複数のビットを含むように構成される。MDタイプフィールド216は、メタデータタイプを示すために1つまたは複数のビットを含むように構成される。次のプロトコルフィールド218は、次のプロトコルを示すために1つまたは複数のビットを含むように構成される。例えば、次のプロトコルは、伝送制御プロトコル（transmission control protocol, TCP）、ユーザ・データグラム・プロトコル（user datagram protocol, UDP）、インターネット・プロトコル（Internet Protocol, IP）、等であり得る。

サービスパス識別子フィールド220（チェインパス識別子フィールドとも呼ばれ得る）は、パケット200にどのサービス機能チェインが適用されるべきかを示すために1つまたは複数のビット（例えば、サービスパス識別子（service path identifier, SPI））を含むように構成される。例えば、サービスパス識別子フィールド220が数0010を含むとき、パケット200は、ファイアウォール、次いでネットワークアドレス変換によって順次に処理される。別の例として、サービスパス識別子フィールド220が数1011を含むとき、パケット200は、ファイアウォール、次いでロードバランサ、次いでサービス品質（QoS）機能によって順次に処理される。

サービス・インデックス・フィールド222は、サービスパス識別子フィールド220と共に、SFFによって取られるべき動作（例えば、パケットを別のSFに転送すべきかどうか、パケットを別のSFFに転送すべきかどうか、またはNSHを除去してパケットを送出するべきかどうかなど）を示すために1つまたは複数のビットを含むように構成される。サービス・インデックス・フィールド222は、パケット200にサービス機能のうちの1つが適用される毎に減算される。メタデータフィールド224は、パケット200のメタデータ部分224に何が含まれるかを指定するように構成される。

実際の適用では、パケット200は、他のフィールド（例えば、プロトコルタイプ、予約済み、等）を含んでもよく、この技術分野の当業者によって理解されるように、トランスポートヘッダが先行する。しかしながら、簡潔さの目的のために、これらの他のフィールドは、ここでは詳細に論じられない。

上記で注記されたように、パケット200内の未使用ビットフィールド210のうちの2つが、図1のネットワークデバイス112のような下流側デバイスに輻輳指示を提供するように設定され得る。例えば、未使用ビットフィールド210のうちの2つが2進数（例えば、0、1、またはそれらのいくつかの組み合わせ）のような値を含む。ネットワークデバイス112が設定された未使用ビットフィールド210のうちの2つを含むパケット200を受信するとき、下流側デバイス112は、サービス機能チェイニングアーキテクチャ100内に輻輳があることを知らされる。

サービス機能チェイニングアーキテクチャ100内でパケット200がたどるパスに沿って輻輳が存在するという通知に応答して、ネットワークデバイス112またはネットワークデバイス106のような下流側デバイスは、輻輳報告メッセージを生成して、分類器104を有するネットワークデバイス102のような上流側デバイスに伝送し得る。一実施形態では、輻輳報告メッセージは、パケット200に含まれる同じフィールドのうちの1つまたは複数を含む。しかしながら、それらのフィールドのうちの少なくとも1つが、分類器104を有するネットワークデバイス102のような上流側デバイスに、輻輳が発生していることを示すために操作される。例えば、バージョンフィールド206、OAMフィールド208、未使用ビット（U）フィールド210、TTLフィールド212、長さフィールド214、メタデータ（MD）タイプフィールド216、次のプロトコルフィールド218、等のうちの少なくとも1つが、設定されるか、ある値を含むか、またはそうでなければ上流側ノードに輻輳を知らせるために操作される。

一実施形態では、ネットワーク輻輳報告メッセージは、上流側ノードに輻輳がどこで発生しているかを示すためにサービスパス識別子フィールド220も含む。実際、ネットワーク輻輳報告メッセージ内にサービスパス識別子フィールド220を含めることによって、分類器104を有するネットワークデバイス102のような上流側デバイスは、輻輳が発生しているサービス機能チェイニングアーキテクチャ100内のパスを決定することができる。

図3は、輻輳報告メッセージを利用するサービス機能チェイニングアーキテクチャ300の概略図である。一実施形態では、サービス機能チェイニングアーキテクチャ300は、入口ノードとして機能し、分類器304を実装するネットワークデバイス302と、SFFとして機能する1つまたは複数のネットワークデバイス306と、様々な異なるサービスノード310を含むサービスノードグループ308と、出口ノードとして機能するネットワークデバイス312と、デバイス／ノードを互いに接続するリンク305とを含む。

図3に表されたように、一実施形態では、ネットワーク輻輳報告メッセージは、図3において破線によって表現されたパス314上で、ネットワークデバイス312のような下流側デバイスから、分類器304を有するネットワークデバイス302のような上流側デバイスに伝送され得る。一実施形態では、ネットワーク輻輳報告メッセージは、図3において破線によって表現された分類器304を有するパス314上で、（SFF1またはSFF2とラベル付けされた）ネットワークデバイス306のような下流側デバイスからネットワークデバイス302のような上流側デバイスに伝送され得る。一実施形態では、ネットワーク輻輳メッセージがSFノードから送信される。

ネットワークデバイス302は、（SFF1またはSFF2とラベル付けされた）ネットワークデバイス306およびネットワークデバイス312に対して上流側であることが理解されるべきである。加えて、（SFF1とラベル付けされた）ネットワークデバイス306は、ネットワークデバイス302の下流側であり、（SFF2とラベル付けされた）ネットワークデバイス306およびネットワークデバイス312の上流側である。（SFF2とラベル付けされた）ネットワークデバイス306は、ネットワークデバイス302および（SFF1とラベル付けされた）ネットワークデバイス306の下流側であり、ネットワークデバイス312の上流側である。一実施形態では、ネットワークデバイス302は、入口ノードと上流側ノードの両方として機能する。一実施形態では、ネットワークデバイス312は、出口ノードと下流側ノードの両方として機能する。一実施形態では、ネットワークデバイス306の各々は中間ノードまたは内部ノードと呼ばれ得る。

下流側デバイスからネットワーク輻輳報告メッセージを受信したことに応答して、ネットワークデバイス302の分類器304は、輻輳を緩和するために動作を行うことができる。例えば、分類器304は、特定のパス上を、またはサービス機能チェイニングアーキテクチャ300を通して送信されるパケットの数を低減するために計量をオンにすることができる。一実施形態では、分類器304は、トラフィック輻輳を低減、緩和、または防止しようと試み得る。例えば、分類器304は、パケットが、同じSFを同じ順序で、単に異なるSFFなどに接続されたそれらのSFの異なるインスタンスを通るように、おそらくは異なるSFFに接続された、SFの異なるインスタンスを通してパケットを方向付ける異なるSPIを使用し得る。

一実施形態では、ネットワーク輻輳報告メッセージは、パケット200と類似してもよく、ネットワークサービスヘッダ204の修正バージョンを含んでもよく、または全く新しいフォーマットを有するメッセージであってもよい。一実施形態では、ネットワーク輻輳報告メッセージのメタデータフィールド内のメタデータが、1つまたは複数のタイム・長さ・値（TLV）として構造化される。これらのTLVのうちの1つが、下流側デバイスから上流側デバイスに輻輳情報を伝達するように構成され得る。ネットワーク輻輳報告メッセージは、実際の適用では様々な他のやり方でエンコードされ得ることがこの技術分野の当業者によって理解されるべきである。

図4は、下流側デバイスによって実行される、上流側デバイスに輻輳を報告する方法400である。一実施形態では、上流側デバイスは図1におけるネットワークデバイス102と類似し、下流側デバイスは図1におけるネットワークデバイス106またはネットワークデバイス112と類似する。この方法は、ネットワークサービスアーキテクチャにおける輻輳が監視および報告されているときに実行され得る。

ブロック402で、下流側デバイスが、サービス機能チェイニングアーキテクチャ内のパス上の輻輳を示すパケットを受信する。パケットは、図2におけるパケット200と類似し得る。ブロック404で、パケットを受信したことに応答して下流側デバイスが輻輳報告メッセージを生成する。一実施形態では、輻輳報告メッセージは、サービス機能チェイニングアーキテクチャ内の輻輳の存在を示すフィールドおよびサービス機能チェイニングアーキテクチャ内の輻輳の位置を示すサービスパス識別子を含む。このフィールドは、例えば、図2のパケット200内のバージョンフィールド206、OAMフィールド208、未使用ビットフィールド210、TTLフィールド212、長さフィールド214、MDタイプフィールド216、または次のプロトコルフィールド218であり得る。ブロック406で、下流側デバイスが、上流側デバイスが輻輳に対処することを可能にするために、上流側デバイスに輻輳報告メッセージを伝送する。一実施形態では、上流側デバイスは分類器104を有するネットワークデバイス102である。輻輳報告メッセージの受信において、上流側デバイスは輻輳に対処することができる。一実施形態では、輻輳報告メッセージは、輻輳を緩和または軽減するための要求または命令を含む。

図5は、サービス機能チェイニングアーキテクチャにおいて下流側デバイスによって実行される、上流側デバイスに輻輳を報告する方法500である。一実施形態では、上流側デバイスは図1におけるネットワークデバイス102と類似し、下流側デバイスは図1におけるネットワークデバイス106またはネットワークデバイス112と類似する。この方法は、ネットワークサービスアーキテクチャにおける輻輳が監視および報告されているときに実行され得る。ブロック502で、下流側デバイスが、NSH内に設定されている2つの輻輳ビットを含むパケットを受信する。パケットは、図2におけるパケット200と類似し得る。ブロック504で、パケットを受信したことに応答して下流側デバイスが輻輳報告メッセージを生成する。一実施形態では、輻輳報告メッセージは、サービス機能チェイニングアーキテクチャ内の輻輳の存在およびサービス機能チェイニングアーキテクチャ内の輻輳の位置を示す。ブロック506で、下流側デバイスが、サービス機能チェイニングアーキテクチャ内の上流側デバイスに輻輳報告メッセージを伝送する。一実施形態では、輻輳報告は上流側デバイスに輻輳に対処するように命令する。

図6はこの開示の一実施形態によるネットワークデバイス600の概略図である。ネットワークデバイス600は、ここで説明された構成要素（例えば、図1の上流側デバイス102、SFF 106、または下流側デバイス112）を実現するために適する。ネットワークデバイス600は、データを受信するための入口ポート610および受信機ユニット（Rx）620と、データを処理するためのプロセッサ、論理ユニット、または中央処理ユニット（central processing unit, CPU）630と、データを送信するための送信機ユニット（Tx）640および出口ポート650と、データを記憶するためのメモリ660とを含む。ネットワークデバイス600はまた、光信号または電気信号の出入りのために入口ポート610、受信機ユニット620、送信機ユニット640、および出口ポート650に結合された光電気（optical-to-electrical, OE）構成要素および電気光（electrical-to-optical, EO）構成要素を含み得る。

プロセッサ630は、ハードウェアおよびソフトウェアによって実現される。プロセッサ630は、1つまたは複数のCPUチップ、コア（例えば、マルチコアプロセッサ）、フィールド・プログラマブル・ゲート・アレイ（field-programmable gate array, FPGA）、特定用途向け集積回路（application specific integrated circuit, ASIC）、およびデジタル信号プロセッサ（digital signal processor, DSP）として実現され得る。プロセッサ630は、入口ポート610、受信機ユニット620、送信機ユニット640、出口ポート650、およびメモリ660と通信する。プロセッサ630は、輻輳モジュール670を含む。輻輳モジュール670は、上記で説明された実施形態を実現する。例えば、輻輳モジュール670は、図5および図6の方法を実行する。したがって、輻輳モジュール670を含むことは、デバイス600の機能への実質的な改善を提供し、デバイス600の異なる状態への変換をもたらす。その代わりに、輻輳モジュール670は、メモリ660に記憶された命令として実現され、プロセッサ630によって実行される。

メモリ660は、1つまたは複数のディスク、テープドライブ、およびソリッド・ステート・ドライブを含み、そのようなプログラムが実行のために選択されるときプログラムを記憶し、プログラムの実行中に読み出される命令およびデータを記憶するために、オーバーフローデータ記憶装置として使用され得る。メモリ660は、揮発性および不揮発性であってもよく、リード・オンリ・メモリ（read-only memory, ROM）、ランダム・アクセス・メモリ（random-access memory, RAM）、三値連想メモリ（ternary content-addressable memory, TCAM）、およびスタティック・ランダム・アクセス・メモリ（static random-access memory, SRAM）であり得る。

本開示において説明された概念は多くの利点を提供する。例えば、現在、単方向サービス機能チェインドメインにおいてフィードバックを提供するための解決策はない。本開示は、輻輳情報を搬送できるサービス機能チェインアーキテクチャまたはドメインを用いてフィードバックメッセージを提供する。双方向サービス機能チェインドメインでは、フィードバック情報を実際のデータ（例えば、顧客またはクライアントによって要求されたデータ）とピギーバックすることは、帯域幅およびタイミングに関して制約され、複雑な符号化を要求し得る。比較すると、明示的なフィードバックメッセージ（例えば、ここで開示された輻輳報告メッセージ）は、簡単、柔軟であり、データがフィードバックされる余地を含む。

下流側デバイスによって実行される、上流側デバイスに輻輳を報告する方法。この方法は、サービス機能チェイニングアーキテクチャ内で輻輳を示すパケットを受信する手段と、パケットを受信したことに応答して輻輳報告メッセージを生成する手段であって、輻輳報告メッセージが、サービス機能チェイニングアーキテクチャ内の輻輳の存在を示すフィールドおよびサービス機能チェイニングアーキテクチャ内の輻輳の位置を示すサービスパス識別子を含む、手段と、上流側デバイスが輻輳を緩和することを可能にするために上流側デバイスに輻輳報告メッセージを伝送する手段とを含む。

サービス機能チェイニングアーキテクチャにおいて下流側デバイスによって実行される、上流側デバイスに輻輳を報告する方法。この方法は、NSH内に設定されている2つの輻輳ビットを含むパケットを受信する手段と、パケットを受信したことに応答して輻輳報告メッセージを生成する手段であって、輻輳報告メッセージが、サービス機能チェイニングアーキテクチャ内の輻輳の存在およびサービス機能チェイニングアーキテクチャ内の輻輳の位置を示す、手段と、サービス機能チェイニングアーキテクチャ内の上流側デバイスに輻輳報告メッセージを伝送する手段であって、輻輳報告が上流側デバイスに輻輳に対処するように命令する、手段とを含む。

サービス機能チェイニングアーキテクチャにおける上流側デバイス。この上流側デバイスは、命令を含むメモリ手段と、メモリ手段に結合されたプロセッサ手段と、を含み、プロセッサ手段が、下流側デバイスにパケットを伝送する命令であって、パケットがサービス機能チェイニングアーキテクチャ内のパス上の輻輳を示すように構成される、命令と、パケットの伝送に応答して下流側デバイスから輻輳報告メッセージを受信する命令であって、輻輳報告メッセージが、サービス機能チェイニングアーキテクチャ内の輻輳の存在を示すフィールドおよびサービス機能チェイニングアーキテクチャ内の輻輳の位置を示すサービスパス識別子を含む、命令と、輻輳報告メッセージにおいて識別された輻輳を緩和する命令とを実行する。

本開示においていくつかの実施形態が提供されているが、開示されたシステムおよび方法は、本開示の思想または範囲を逸脱することなく他の多くの具体的な形式で具体化され得ることが理解されるべきである。提示の例は、限定ではなく例示として考えられるべきであり、その意図は、ここで提供された詳細に限定されるべきではない。例えば、様々な要素または構成要素が、別のシステムにおいて組み合わされまたは統合されてもよく、ある特徴が省略され、または実装されなくてもよい。

加えて、様々な実施形態において別個または分離したものとして説明および例示された技法、システム、サブシステム、および方法が、本開示の範囲を逸脱することなく、他のシステム、モジュール、技法、または方法と組み合わされまたは統合されてもよい。互いに結合され、または直接結合され、または通信するとして表されまたは論じられた他の事項が、電気的にせよ、機械的にせよ、またはそれ以外にせよ、何らかのインターフェース、デバイス、または中間の構成要素を通して間接的に結合されるかまたは通信してもよい。変更、置換、および代替の他の例は、この技術分野の当業者によって確認可能であり、ここで開示された思想および範囲を逸脱することなく行うことができる。

100 サービス機能チェイニングアーキテクチャ
102 ネットワークデバイス
104 分類器
105 リンク
106 ネットワークデバイス
108 サービスノードグループ
110 サービスノード
112 ネットワークデバイス
200 パケット
202 データ部分
204 ネットワークサービスヘッダ（NSH）
206 バージョンフィールド
208 運用管理保守（OAM）フィールド
210 未使用ビット（U）フィールド
212 生存時間（TTL）フィールド
214 長さフィールド
216 メタデータ（MD）タイプフィールド
218 次のプロトコルフィールド
220 サービスパス識別子フィールド
222 サービス・インデックス・フィールド
224 メタデータフィールド
300 サービス機能チェイニングアーキテクチャ
302 ネットワークデバイス
304 分類器
305 リンク
308 ネットワークデバイス
308 サービスノードグループ
310 サービスノード
312 ネットワークデバイス
314 パス
400 方法
500 方法
600 ネットワークデバイス
610 入口ポート
620 受信機（Rx）
630 プロセッサ
640 送信機（Tx）
650 出口ポート
660 メモリ
670 輻輳モジュール

Claims

下流側デバイスによって実行される、上流側デバイスに輻輳を報告する方法であって、
前記下流側デバイスにより、サービス機能チェイニングアーキテクチャ内のパス上の輻輳を示すパケットを受信するステップと、
前記下流側デバイスにより、前記パケットを受信したことに応答して輻輳報告メッセージを生成するステップであって、前記輻輳報告メッセージが、前記サービス機能チェイニングアーキテクチャ内の輻輳の存在を示し、前記輻輳報告メッセージが、前記サービス機能チェイニングアーキテクチャ内の前記輻輳の前記パスを示すサービスパス識別子を含む、ステップと、
前記下流側デバイスにより、上流側デバイスが前記輻輳を緩和することを可能にするために前記上流側デバイスに前記輻輳報告メッセージを伝送するステップと、
を含む方法。
前記パケットが複数の未使用ビットフィールドを含み、前記未使用ビットフィールドのうちの少なくとも2つが、前記サービス機能チェイニングアーキテクチャ内の前記輻輳を示す値を含む、請求項1に記載の方法。
前記値が複数の2進数によって表現される、請求項2に記載の方法。
前記上流側デバイスが、前記下流側デバイスから前記輻輳報告メッセージを受信したことに応答してパケットのフローを計量または方向付けるように構成された分類器を含む、請求項1から3のいずれか一項に記載の方法。
前記下流側デバイスが前記サービス機能チェイニングアーキテクチャにおける出口ノードである、請求項1から4のいずれか一項に記載の方法。
前記下流側デバイスが前記サービス機能チェイニングアーキテクチャにおけるサービス機能フォワーダ（SFF）である、請求項1から5のいずれか一項に記載の方法。
前記パケットがネットワークサービスヘッダ（NSH）を含み、前記輻輳報告メッセージが前記NSHの修正バージョンを含む、請求項1から6のいずれか一項に記載の方法。
前記NSHの修正バージョンがメタデータ（MD）タイプを識別し、前記MDタイプに対応するメタデータが1つまたは複数のフィールドまたはタイプ・長さ・値（TLV）として構造化される、請求項7に記載の方法。
サービス機能チェイニングアーキテクチャにおいて下流側デバイスによって実行される、上流側デバイスに輻輳を報告する方法であって、
前記下流側デバイスにより、ネットワークサービスヘッダ（NSH）内に設定されている2つの輻輳ビットを含むパケットを受信するステップと、
前記下流側デバイスにより、前記パケットを受信したことに応答して輻輳報告メッセージを生成するステップであって、前記輻輳報告メッセージが、前記サービス機能チェイニングアーキテクチャ内のパス上の輻輳の存在を示し、前記輻輳報告メッセージが、前記サービス機能チェイニングアーキテクチャ内の前記輻輳の前記パスを示すサービスパス識別子を含む、ステップと、
前記下流側デバイスにより、前記サービス機能チェイニングアーキテクチャ内の上流側デバイスに前記輻輳報告メッセージを伝送するステップであって、前記輻輳報告メッセージが前記上流側デバイスに前記輻輳に対処するように命令する、ステップと、
を含む方法。
前記輻輳の存在が、前記パケットの前記NSH内の少なくとも1つのフィールドを操作し、生成されるときに前記輻輳報告メッセージ内に、前記少なくとも1つのフィールドを含めることによって示される、請求項9に記載の方法。
前記輻輳のパスが、前記パケットの前記NSH内のサービスパス識別子を操作し、生成されるときに前記輻輳報告メッセージ内に、前記操作されたサービスパス識別子を含めることによって示される、請求項9または10に記載の方法。
サービス機能チェイニングアーキテクチャにおける上流側デバイスであって、
命令を含むメモリと、
前記メモリと通信するプロセッサと、を含み、前記プロセッサが、
下流側デバイスにパケットを伝送する命令であって、前記パケットが前記サービス機能チェイニングアーキテクチャ内のパス上の輻輳を示すように構成された、命令と、
前記パケットの伝送に応答して前記下流側デバイスから輻輳報告メッセージを受信する命令であって、前記輻輳報告メッセージが、前記サービス機能チェイニングアーキテクチャ内の輻輳の存在を示し、前記輻輳報告メッセージが、前記サービス機能チェイニングアーキテクチャ内の前記輻輳の前記パスを示すサービスパス識別子を含む、命令と、
前記輻輳報告メッセージにおいて識別された輻輳を緩和する命令と、
を実行する、上流側デバイス。
前記パケットが複数の未使用ビットフィールドを含み、前記未使用ビットフィールドのうちの少なくとも2つが、前記サービス機能チェイニングアーキテクチャ内の前記輻輳を示すための値を含む、請求項12に記載の上流側デバイス。
前記プロセッサが、前記下流側デバイスから前記輻輳報告メッセージを受信したことに応答してパケットのフローを計量または方向付ける命令を実行する、請求項12または13に記載の上流側デバイス。
前記下流側デバイスが前記サービス機能チェイニングアーキテクチャにおける出口ノードである、請求項12から14のいずれか一項に記載の上流側デバイス。