JP6982250B2

JP6982250B2 - パケット転送装置、方法、及びプログラム

Info

Publication number: JP6982250B2
Application number: JP2018143193A
Authority: JP
Inventors: 宏紀岩澤; 和宏徳永; 真也玉置; 健桑原
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2018-07-31
Filing date: 2018-07-31
Publication date: 2021-12-17
Anticipated expiration: 2038-07-31
Also published as: US20210314267A1; US11477121B2; JP2020022023A; WO2020026983A1

Description

本発明は、外部から受信したパケットを転送するパケット転送装置に関する。

パケット転送装置は、一般的に、受信したパケットを分類するパケット分類部と、分類されたパケットを分類ごとに保持するキューと、キューからパケットを取り出すパケット取り出し部とを備えている。

最も単純なキューイング方式として、到着したパケットから順に一つのキューに入れ、到着した順にパケットを送信するＦＩＦＯ（First In, First Out）がある。ＦＩＦＯのキューイング遅延増加を解決する方法として、キューイング遅延の増加に伴いパケット破棄確率を増加させるＣｏＤｅｌ（Controled delay）（非特許文献１参照）、ＰＩＥ（Proportional Integral Controller Enhanced）（非特許文献２参照）等の方式が提案されている。

また、通信フローを公平に扱うキューイング方式としてＦＱ（Fair Queuing）（非特許文献３参照）が知られている。ＦＱは通信フロー毎にキューを分け、各キューから均等にパケットを送信する。ＦＱの実装の一つにトークンバケットアルゴリズムがある。トークンバケットアルゴリズムでは各キューに一定時間おきにトークンが追加され、各キューのパケット送信タイミングに、トークンの分だけパケットを送信できる。トークンを用いることである程度バースト的なパケット送信を許容し、ネットワーク帯域を効率的に利用可能である。また、ＦＱとＣｏＤｅｌを組み合わせることでフロー間の公平性とキューイング遅延の低減が可能なＦＱ＿ＣｏＤｅｌ（Flow Queue - CoDel）（非特許文献４参照）という方式も提案されている。

また、インターネット通信においてＱｏＳ（Quality of Service）を保証する代表的な手法としてＤｉｆｆＳｅｒｖ（Differentiated Services）（非特許文献５参照）が知られている。ＤｉｆｆＳｅｒｖは、通信フローをいくつかのクラスに分類し、クラス毎に優先順位をつけて制御を行う手法である。優先制御手法としては、例えばＰＱ（Priority Queuing）、ＷＦＱ（Weighted Fair Queuing）、ＬＬＱ（Low Latency Queuing）などがある。これらは、優先度の高いクラスのパケットを優先的に処理、又は帯域保証を行うことでＱｏＳを保証しようとする。

ところで、近年ＶＲ／ＡＲ（Virtual Reality/Augmented Reality）の普及が本格化している。最近ではＨＭＤ（Head Mounted Display）自体にモバイル向けＳｏＣ（System on a Chip）を搭載したものや、ＨＭＤ型のゴーグルにスマートフォンを装着することで簡易にＶＲ体験ができるようになっているが、描写性能や体感品質は高価な最新のＧＰＵ（Graphics Processing Unit）を利用するハイエンドなＨＭＤ製品に劣る。そこで遠隔地のデータセンタ内のＧＰＵによりレンダリングした映像をスマートフォン等の軽量な端末に送ることで、簡易にハイエンドＶＲ体験ができる可能性がある。ＨＭＤを装着するタイプのＶＲでは、人の間隔と映像のずれによって体調が悪くなるＶＲ酔いという症状を引き起こすことが知られているが、ＶＲ酔いを回避する方法の一つに、人の動作がＨＭＤの映像に反映されるまでの時間（Motion to Photon latency）を最大でも２０ｍｓ以下に抑えることが有効と言われている（非特許文献６参照）。

K. Nichols et al., "Controlled Delay Active Queue Management", IETF RFC 8289, Jan 2018, [online], [平成30年7月6日検索], インターネット<URL:https://tools.ietf.org/html/rfc8289> R. Pan et al., "Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem", IETF RFC 8033, Feb 2017, [online], [平成30年7月6日検索], インターネット<URL:https://tools.ietf.org/html/rfc8033#ref-HPSR-PIE> A. Demers, S. Keshav, and S. Shenker, "Analysis and simulation of a fair queueing algorithm", in Proc.SIGCOMM’89, vol.19, no.4, pp.1-12, Sep 1989, [online], [平成30年7月6日検索], インターネット<URL:https://dl.acm.org/citation.cfm?id=75248> T. Hoeiland-Joergensen et al., "The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm", IETF RFC 8290, Jan 2018, [online], [平成30年7月6日検索], インターネット<URL:https://tools.ietf.org/html/rfc8290> cisco systems, "DIFFSERV-THE SCALABLE END-TO-END QUALITY OF SERVICE MODEL", 2005, [online], [平成30年7月6日検索], インターネット<URL:http://www.cisco.com/en/US/technologies/tk543/tk766/technologies_white_paper09186a00800a3e2f.pdf> Mohammed S. Elbamby, Cristina Perfecto, Mehdi Bennis, Klaus Doppler, "Towards Low-Latency and Ultra-Reliable Virtual Reality", IEEE Network, Vol. 32, pp.87-84, Apr 2018

遠隔地のデータセンタでレンダリングしたＶＲ映像をＭＴＵ（Maximum Transmission Unit）１５００ｂｙｔｅのＩＰ（Internet Protocol）パケットで伝送する場合、フルＨＤ（High Definition）以上の高精細映像では映像１フレームが数十〜数百パケットで構成されるため、１フレームを構成する数十〜数百パケット全ての転送が、２０ｍｓからレンダリング、エンコード、デコード等にかかる処理遅延を除いた時間内に完了する必要がある。

ＣｏＤｅｌやＰＩＥはパケット破棄によりキューイング遅延を低減するため、リアルタイム映像伝送ではパケットロスによりブロックノイズ等を招く原因となる。また１パケット当りのキューイング遅延低減は可能だが、連続するパケット全ての転送遅延低減を保証するものではない。

ＦＱ、ＦＱ＿Ｃｏｄｅｌのような公平なキューイングを行う場合、フロー毎のパケットを少量ずつ公平に送信する。そのため、回線帯域を圧迫するほどの輻輳が生じていなくても、映像１フレームのような数十パケットを転送している間に他のフローのパケットが到着すると、キューイング遅延が生じてしまう。例えば１０Ｇｂｐｓの回線であれば、１５００ｂｙｔｅのパケット伝送遅延は１．２ｕｓであるが、仮に１００フローを１パケットずつ順番に処理する場合、１パケット毎に１２０ｕｓの伝送遅延が発生するため、例えば５０パケット全ての伝送には６ｍｓの遅延が生じることになる。

ＰＱ等を用いて帯域確保を行うことも考えられるが、５０パケットを１ｍｓで伝送するには瞬間的に１０Ｇｂｐｓ回線の６％を占有する必要があり、優先通信が多数存在する場合に全てのユーザの帯域確保することは難しい。また、帯域確保、優先制御を行う場合も、同一優先度内で同時に複数の通信が行われている場合、ＦＱと同様のキューイング遅延が生じる可能性がある。

本発明は、上記事情に鑑みてなされたものであり、同一優先度の通信フロー間の公平性を保ちつつ、複数の連続したパケットを低遅延に転送するパケット交換処理を行うパケット転送装置及び方法、並びにプログラムを提供することにある。

上記目的を達成するために、本願発明は、受信したパケットを分類するパケット分類部と、前記分類されたパケットを分類ごとに保持するキューと、前記キューからパケットを取り出すデキュー処理部とを備え、受信したパケットを外部に送信するパケット転送装置において、前記デキュー処理部は、特定の通信フローが要求する連続してパケット送信したいデータ量の情報に基づき当該通信フローについて前記キューからのパケット取り出し量を制御するスケジューリング部を備えることを特徴とする。

また、本願発明は、さらに、前記スケジューリング部は、パケット取り出し量の前記制御によるパケットの連続送信の後に、連続送信したデータ量に基づき当該通信フローにおけるパケット取り出し量を制限する。

また、本願発明は、さらに、前記スケジューリング部は、パケット転送装置が外部に送信可能なデータ量とパケット転送装置を利用している通信フロー数に基づき連続送信可能なデータ量の最大値を算出し、当該最大値の範囲内で前記キューからのパケット取り出し量を制御する。

本発明によれば、スケジューリング部が、特定の通信フローが要求する連続してパケット送信したいデータ量の情報に基づき当該通信フローについてキューからのパケット取り出し量を制御するので、当該通信フローが有するパケットの送信タイミングや送信量等の特性に応じたパケット転送が可能となる。

また、本発明によれば、瞬間的なバースト送信を行った後にパケット送信を制限することで、リアルタイム映像の１フレームのような複数のパケットに跨るデータ全てを他の通信のパケット送信を妨害することなく、キューイング遅延を低減して転送が可能となる。

また、本発明によれば、送信可能なバースト量の最大値をパケット送信量とアクティブフロー数から算出することで、バースト送信による最大キューイング遅延、及びジッタを軽減することができる。

実施形態に係る通信システムの全体構成図パケット転送装置の機能ブロック図デキュー処理部の機能ブロック図キューイング処理手順のシーケンスチャートの一例スケジューラにおけるキューの状態管理例デキュー処理部におけるパケット処理アルゴリズムのフローチャートの一例パケットヘッダによりバースト要求を通知する例パケット転送によるネットワークの帯域占有率の経時的変化の一例

本発明の一実施の形態に係る通信システムについて図面を参照して説明する。図１に本実施の形態に係る通信システムの全体構成を示す。

本実施の形態に係る通信システムは、図１に示すように、サーバ１０と端末２０とは、複数のパケット転送装置１００を経由して通信を行う。通信システムは、図１の構成に限られず、サーバ１０及び端末２０等の通信端末間をパケット転送装置１００を介して通信接続される構成であればよい。

パケット転送装置１０は、主に半導体装置で構成され、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）等の揮発性記憶装置、ハードディスクやフラッシュメモリ等の不揮発性記憶装置、及び外部との通信のための接続を行う通信インタフェースを有する、いわゆる情報処理機器として構成することができる。また、パケット転送装置１００は、物理的なスイッチ、ルータ等のネットワーク機器に限らず、本発明のパケット転送プログラムが動作する物理コンピュータや仮想化されたコンピュータを含む。

本発明に係るパケット転送装置１００は、特定の通信フローが要求する連続してパケット送信したいデータ量の情報に基づき当該通信フローについてキューからのパケット取り出し量を制御するスケジューリングを行う。すなわち、特定の通信フローが要求する連続してパケット送信したいデータ量の情報に基づき、当該通信フローについて連続したパケット取り出しを可能とするようスケジューリング制御する。このような制御は、例えばキューイングアルゴリズムとしてトークンバケットアルゴリズムを用いる場合には、当該通信フローについてのトークン量を増加させることにより実現できる。

また、本発明に係るパケット転送装置１００は、前記パケット取り出し量の制御による連続送信の後に、連続送信したデータ量に基づき当該通信フローにおけるパケット取り出し量を制限する。これにより、他の通信フローのデータ送信機会を妨害しないようにしている。ここで、パケット取り出し量の制限とは、当該通信フローに係るキューからのパケットの取り出しを行わないようにすることや、当該通信フローに係るキューからのパケットの取り出し頻度を低減させることや、当該通信フローに係るキューから取り出したパケットについての優先度やクラス等を低減させることなどが挙げられる。例えばキューイングアルゴリズムとしてトークンバケットアルゴリズムを用いる場合には、当該通信フローについてのトークンを低減させることにより実現でき、特に負の値までトークンを低減させることにより実現できる。

また、本発明に係るパケット転送装置１００は、自身が外部に送信可能な自身を利用している通信フロー数に基づき算出する連続送信可能なデータ量の最大値を算出し、当該最大値の範囲内でキューからのパケット取り出し量を制御する。これにより、複数の通信フローがデータを連続送信してもデータ送信間隔（最大キューイング遅延）を一定値以内に抑えることができる。

以降、サーバ１０から端末２０へパケットを送信する例をもって本発明の説明を行う。なお、以下の説明では、本発明に係る上記のパケットの取り出し制御に基づきパケットを連続的に送信することを「バースト送信」と呼ぶ。また、バースト送信の実施を要求することを「バースト要求」と呼ぶ。このバースト要求をパケット転送装置１００に通知する方法については後述する。

本実施の形態におけるパケット転送装置の機能ブロック図を図２に示す。パケット転送装置１００は、外部のサーバ、端末、他のパケット転送装置等からパケットを受信するパケット受信部１１０と、受信したパケットをフロー毎あるいはクラス毎に分類するパケット分類部１２０と、パケット分類部１２０によって振り分けられたパケットを一時的に格納する複数のキュー１３０と、キュー１３０の先頭からパケットを取り出すデキュー処理部１４０と、取り出されたパケットを外部の装置へ送信するパケット送信部１５０と、パケット送信部１５０から送信されるパケットの流量を測定する送信レート計測部１６０と、パケット分類部１２０及びデキュー処理部１４０から情報を取得することでパケット転送装置１００を現在利用している通信フロー(アクティブフロー)数を計測するフロー数計測部１７０と、フロー数計測部１７０及び送信レート計測部１６０から情報を取得し、一度にパケットを送信可能な上限値（バースト量上限値）を計算するバースト量計算部１８０とを備える。

ここで通信フローとは、送受信ＩＰアドレス・送受信ポート・プロトコル番号からなる５ｔｕｐｌｅ、あるいは送受信ＩＰアドレス・送受信ポート・プロトコル番号の何れかの情報の組み合わせが同一のパケット群のことを指す。

デキュー処理部１４０の機能ブロック図を図３に示す。デキュー処理部１４０は、キュー１３０の状態管理を行い、どのキュー１３０からどれだけのパケットを送信するかを決定し、パケット取り出し部に指示するスケジューラ１４１と、スケジューラ１４１からの指示によりキュー１３０からパケットを取り出すパケット取り出し部１４２と、取り出したパケットのヘッダからバースト送信要求の有無を確認するヘッダチェック部１４３とを備える。

パケット取り出し部１４２はどのキュー１３０からどれだけパケットが取り出されたかをフロー数計測部１７０へ通知する。スケジューラ１４１はバースト量計算部１８０から取得したバースト量上限値をスケジューリングへ反映する。パケット取り出し部１４２は、スケジューラ１４１の指示によりキュー１３０から取り出したパケットをヘッダチェック部１４３又はパケット送信部１５０へ送る。またヘッダチェック部１４３でチェックされたパケットはパケット送信部１５０へ送られる。

以下では、パケット分類部１２０において、５ｔｕｐｌｅの値から算出したハッシュ値（５ｔｕｐｌｅハッシュ値）で分類することでフロー毎にキュー１３０を用意し、デキュー処理部１４０のスケジューラ１４１において、トークンバケットアルゴリズムを用いた不足ラウンドロビンに基づくスケジューリングを行う例について説明する。また、バースト送信の実施の要求は、サーバ１０においてパケットに連続して送信したいデータ量であるバースト値を格納することにより行うものとする。

なお、パケットの分類方法としては、５ｔｕｐｌｅで分類する他に優先度合の異なる複数のクラスに分類する方法、遅延、スループット、パケットロスなどネットワーク要件毎のクラスに分類する方法、何らかのクラス毎に分類した上で更にクラス内部でフローやクラス毎に分類する方法などにおいても、同一クラス内のパケット処理方法に本発明を利用することが可能である。

また、スケジューリングについても、不足ラウンドロビンの他、単純なＦＩＦＯ、特定のクラス、フローの帯域確保、優先制御を用いても良い。

次に図４を参照して本発明の実施手順例を説明する。図４に示すように、パケット受信部１１０に届いたパケットは、パケット分類部１２０において、５ｔｕｐｌｅハッシュ値によって各キュー１３０に振り分けを行う。

それぞれのキュー１３０からは、スケジューラ１４１のトークンバケットアルゴリズムを用いた不足ラウンドロビン制御に基づいてデキュー処理部１４０内のパケット取り出し部１４２によりパケットが取り出される。トークンバケットを用いた不足ラウンドロビンでは、一定時間おきに各キュー１３０にトークンを加算し、各キュー１３０は順番にパケットを送信する機会が与えられる。パケットを送信する機会が与えられると、パケット送信の際に、各キュー１３０は所有しているトークン分だけのパケットを一度に送信できる。キュー１３０に溜まっている全てのパケットを送信し、トークンが余った場合は次回の送信タイミングに繰り越される。

スケジューラ１４１は図５に示すように、キュー１３０を識別するＩＤ、通信フローを識別する５ｔｕｐｌｅハッシュ値、現在の所有トークン量、バースト送信を行っているかを識別するバーストフラグ、バースト送信を行っている量を示すバースト値をキュー１３０毎に管理する。

デキュー処理部１４０により取り出されたパケットはヘッダチェック部１４３によってバースト要求情報が取得される。パケットにバースト要求情報があり、かつトークン量が負でない場合、後述するバースト量上限値の範囲内で要求するバースト量分のトークンを該当キューのトークンに加算し、現在のパケット送信タイミングでトークン分だけのパケットを送信する。トークンが残っている間はヘッダチェック部１４３の処理は行わずパケットは直接パケット送信部１５０から外部へ送信される。バースト要求によりトークンを付与されたキュー１３０は、時間経過による通常のトークンは加算されず、全てのトークンを利用した後に後述するフロー数に基づいてトークン量を減算し、時間経過によるトークンの加算を再開する。

上記処理により、一時的なパケットのバースト送信を許可する代わりに一定期間パケット送信ができなくすることで、他の通信との公平性を保つことが可能となる。

図４の例では、サーバ１０が連続した多数のパケットを送信する場合に当該パケットにバースト要求を付加している（ステップＳ１０１）。この場合、ヘッダチェック部１４３でバースト要求の有無がチェックされ（ステップＳ１０２）、トークンがバースト要求に係るバースト値だけ加算される（ステップＳ１０３）。これにより、バースト送信が実現する（ステップＳ１０４）。そして、バースト送信後にはトークンがバースト送信量だけ減算する（ステップＳ１０５）。これにより、通常の経時的なトークン加算処理によりトークンが正になるまでパケット送信及びバースト要求が不可となる。

次にバースト量上限値の決定方法について説明する。フローが極端に大きいバースト送信を要求した場合、パケット転送装置１００全体のキューイング遅延、ジッタの悪化を招くため、バースト送信可能な最大量を以下の手順により決定する。

１．フロー数計測部１７０において、パケット分類部１２０とデキュー処理部１４０から取得したエンキュー、デキューの情報から、アクティブフロー数ｎ_ｆｌｏｗを計測する。具体的には、キュー１３０に振り分ける際にカウントを＋１、デキューする際にカウントを−１することでカウントが０でないフローの数がアクティブフロー数となる。

２．送信レート計測部１６０において、一定時間内にパケット送信部１５０から送信されるパケット量を測定することで、送信パケットレートＲ_ｏｕｔを算出する。なお、送信側のリンク帯域やＱｏＳクラス毎に設定した最大帯域をＲ_ｏｕｔに設定しても良い。

３．バースト量計算部１８０にてｎ_ｆｌｏｗ及びＲ_ｏｕｔを取得し、目標パケット送信間隔Ｔ_{ｔａｒｇｅｔ}を定数としてバースト量上限値Ｂ_ｍａｘを以下の式にて算出する。

これは、現在通信を行っているアクティブキュー全てがＢ_ｍａｘだけバースト送信を行ってもＴ_{ｔａｒｇｅｔ}時間経過後には次の送信タイミングがやってくることを意味する。例えば目標パケット送信間隔５ｍｓ、アクティブフロー数１００、パケット送信量１０Ｇｂｐｓの場合、６２．５ｋＢまでバースト送信を許可する。もしアクティブな１００フロー全てが順番に６２．５ｋＢのバースト送信を行っても５ｍｓ後に次のパケット送信タイミングが訪れる。

アクティブフロー数、送信パケットレートの変更に適応するため、バースト量上限値Ｂ_ｍａｘは定期的に更新する。

また、バースト要求により追加したトークン消費後は、要求したバースト量Ｂ_{ｄｅｍａｎｄ}に対して、ｍｉｎ｛Ｂ_ｍａｘ，Ｂ_{ｄｅｍａｎｄ}｝×（ｎ_ｆｌｏｗ−１）のトークンを減算する。トークンが負の間は、時間経過によるトークンの加算だけ行われるため、バースト要求は無視され、パケット送信も行われない。ただし何れのキュー１３０にもパケットが溜まっておらず、パケット送信が行われない場合、トークン加算値を増加し、短時間でパケット送信を再開させても良い。

デキュー処理部１４０の詳細アルゴリズムの一例を図６に示す。図６は１つのキュー毎に処理を行う。

図６に示すように、デキュー処理部１４０は、まず、対象キュー１３０のバーストフラグをチェックする（ステップＳ２０１）。バーストフラグが１の場合にはバースト送信処理を開始する。具体的には、対象キュー１３０の先頭にパケットがあり且つ対象キュー１３０の先頭パケットサイズがトークン以下の場合（ステップＳ２０２，Ｓ２０３）、トークンを先頭パケットサイズで減算するとともに、当該先頭パケットをパケット送信部１５０へ転送する（ステップＳ２０４〜Ｓ２０５）。このバースト送信処理は、対象キュー１３０からパケットがなくなる又は先頭パケットのサイズがトークンより大きくなるまで繰り返し実施する。

バースト送信処理が終了すると、トークンをバースト値×（ｎ_ｆｌｏｗ−１）だけ減算するとともに、バーストフラグ及びバースト値を０にして処理を終了する（ステップＳ２０６〜Ｓ２０７）。

一方、バーストフラグが０の場合には、通常のトークンバケットアルゴリズムに準じた処理を行う。具体的には、一定時間が経過しており且つトークンがＢ_ｍａｘ以下の場合は、経過時間に対応する分だけトークンを増加させる（ステップＳ２１１，Ｓ２１２）。そして、対象キュー１３０の先頭にパケットがあり且つ対象キュー１３０の先頭パケットサイズがトークン以下の場合（ステップＳ２１３〜Ｓ２１４）、トークンを先頭パケットサイズで減算するとともに、当該先頭パケットをパケット送信部１５０へ転送する（ステップＳ２１８〜Ｓ２１９）。この送信処理は、対象キュー１３０からパケットがなくなる又は先頭パケットのサイズがトークンより大きくなるまで繰り返し実施する。ただし、対象キュー１３０の先頭パケットにバースト要求が含まれている場合は、バーストフラグを１に設定し、バースト値としてｍｉｎ｛Ｂ_ｍａｘ，Ｂ_{ｄｅｍａｎｄ}｝を設定し、トークンをｍｉｎ｛Ｂ_ｍａｘ，トークン＋Ｂ_{ｄｅｍａｎｄ}｝に設定し、前述のバースト処理に移行する（ステップＳ２１５〜Ｓ２１７）。

次に、バースト要求をパケット転送装置１００に通知する方法について説明する。バースト要求の通知方法としてはパケットに付加する方法と、事前にパケット転送装置１００に登録する方法がある。

パケットに付与する方法としては、ＩＰまたはＴＣＰヘッダのオプション領域を活用する方法が考えられる。また閉じたネットワーク内でかつ、フラグメンテーションが起きない環境であれば、ＩＰｖ４ヘッダのＩＤフィールド、またはＤＦビットをセットすることでフラグ及びフラグメントオフセットの利用もできる。パケットに情報を直接付加することで要求バースト長を柔軟に変更可能であるが、パケット単位でアプリケーションにおいて情報を付加する必要がある。図７にＩＰまたはＴＣＰヘッダのオプションフィールド例を示す。

パケット転送装置１００に事前に登録する場合、サーバ１０又は端末２０からバースト送信量と５ｔｕｐｌｅハッシュ値を通信開始時にパケット転送装置１００へ通知することで実現できる。この場合、柔軟にバースト送信量を変更はできないが、パケット単位で情報を付加する必要がない。

図８にパケット転送によるネットワークの帯域占有率の経時的変化の一例を示す。図８に示すように、本実施の形態に係るパケット転送装置１００によれば、瞬間的なバースト送信を行った後にパケット送信を制限することで、リアルタイム映像の１フレームのような複数のパケットに跨るデータ全てを他の通信のパケット送信を妨害することなく、キューイング遅延を低減して転送が可能となる。また、パケット転送装置１００によれば、送信可能なバースト量の最大値をパケット送信量とアクティブフロー数から算出することで、バースト送信による最大キューイング遅延、及びジッタを軽減することができる。

以上本発明の一実施の形態について詳述したが本発明はこれに限定されるものではない。例えば上記実施の形態では、パケット分類部１２０においては、５ｔｕｐｌｅに基づき通信フローを分類していたが、優先度合の異なる複数のクラスに分類する方法、遅延、スループット、パケットロスなどネットワーク要件毎のクラスに分類する方法、何らかのクラス毎に分類した上で更にクラス内部でフローやクラス毎に分類する方法などにおいても、同一クラス内のパケット処理方法に本発明を利用することが可能である。

また、上記実施の形態では、スケジューラ１４１は、トークンバケットアルゴリズムを用いた不足ラウンドロビンに基づくスケジューリングを基礎としているが、単純なＦＩＦＯ、特定のクラス、フローの帯域確保、優先制御を用いたスケジューリングに本発明を適用してもよい。

１０…サーバ
２０…端末
１００…パケット転送装置
１１０…パケット受信部
１２０…パケット分類部
１３０…キュー
１４０…デキュー処理部
１４１…スケジューラ
１４２…パケット取り出し部
１４３…ヘッダチェック部
１５０…パケット送信部
１６０…送信レート計測部
１７０…フロー数計測部
１８０…バースト量計算部

Claims

受信したパケットを分類するパケット分類部と、前記分類されたパケットを分類ごとに保持するキューと、前記キューからパケットを取り出すデキュー処理部とを備え、受信したパケットを外部に送信するパケット転送装置において、
前記デキュー処理部は、特定の通信フローが要求する連続してパケット送信したいデータ量の情報に基づき当該通信フローについて前記キューからのパケット取り出し量を制御するスケジューリング部を備え、
前記スケジューリング部は、パケット取り出し量の前記制御によるパケットの連続送信の後に、連続送信したデータ量に基づき当該通信フローにおけるパケット取り出し量を制限する
ことを特徴とするパケット転送装置。
受信したパケットを分類するパケット分類部と、前記分類されたパケットを分類ごとに保持するキューと、前記キューからパケットを取り出すデキュー処理部とを備え、受信したパケットを外部に送信するパケット転送装置において、
前記デキュー処理部は、特定の通信フローが要求する連続してパケット送信したいデータ量の情報に基づき当該通信フローについて前記キューからのパケット取り出し量を制御するスケジューリング部を備え、
前記スケジューリング部は、パケット転送装置が外部に送信可能なデータ量とパケット転送装置を利用している通信フロー数に基づき連続送信可能なデータ量の最大値を算出し、当該最大値の範囲内で前記キューからのパケット取り出し量を制御する
ことを特徴とするパケット転送装置。
受信したパケットを分類するパケット分類部と、前記分類されたパケットを分類ごとに保持するキューと、前記キューからパケットを取り出すデキュー処理部とを備え、受信したパケットを外部に送信するパケット転送装置において、
前記デキュー処理部は、特定の通信フローが要求する連続してパケット送信したいデータ量の情報に基づき当該通信フローについて前記キューからのパケット取り出し量を制御するスケジューリング部を備え、
前記スケジューリング部は、トークンバケットアルゴリズムによりパケットの取り出しを制御するとともに、特定の通信フローが要求する連続して送信したいデータ量の情報に基づきトークンを増加させることにより当該通信フローについて前記キューからのパケット取り出し量を制御し、
前記スケジューリング部は、パケット取り出し量の前記制御による連続送信の後に、連続送信したデータ量に基づきトークンを減少することによりパケット取り出し量を制限する
ことを特徴とするパケット転送装置。
前記デキュー処理部は、特定の通信フローに係るパケットから当該通信フローが要求する連続して送信したいデータ量の情報を取得する要求情報取得部を備える
ことを特徴とする請求項１乃至３の何れか１項記載のパケット転送装置。
受信したパケットを分類するパケット分類部と、前記分類されたパケットを分類ごとに保持するキューと、前記キューからパケットを取り出すデキュー処理部とを備え、受信したパケットを外部に送信するパケット転送装置におけるパケット処理方法であって、
前記デキュー処理部のスケジューリング部が、特定の通信フローが要求する連続してパケット送信したいデータ量の情報に基づき当該通信フローについて前記キューからのパケット取り出し量を制御するステップを備え、
前記スケジューリング部は、パケット取り出し量の前記制御によるパケットの連続送信の後に、連続送信したデータ量に基づき当該通信フローにおけるパケット取り出し量を制限する
ことを特徴とするパケット転送装置におけるパケット処理方法。
コンピュータを、請求項１乃至４の何れか１項記載のパケット転送装置の各部として機能させるプログラム。