PR

 ここまでは,パケットの送信間隔を調整することでトラフィック・シェーピングを実現するためのしくみを見てきました。ただし,パケットの送信間隔の情報だけでは目的とするトラフィック・シェーピングには不十分です。フレームの送信間隔を制御するということは,すなわち帯域を固定でガチガチに割り当てることです。これは当初の目的とはかけ離れた処理です。

“絞る”だけでは帯域利用の効率化につながらない

 目的とするトラフィック・シェーピングは,余っている帯域を有効に使うことです。例えば,ギガビット・イーサネットの回線で100ユーザーが平均4Mビット/秒で通信しているとしましょう。単純計算で400Mビット/秒の帯域を利用している状況になります。つまり,このギガビット・イーサネット回線では,約半分の帯域が未使用のままです。こうした状況でパケット(MACフレーム)の送信間隔を制御して,帯域を制限するのは意味がありません。余っている帯域があれば,より帯域を使いたいというユーザーにその余分な帯域を割り当て,逆に余っている帯域が減れば分配する帯域を減らす――。こうした処理が求められるのです。

 このような処理を実現するためには,ルーターの各インタフェース・ポートごとに,何人のユーザーが通信を行っていて,各ユーザーにどれだけの帯域を割り当てているのか,各ユーザーが実際にどれだけの帯域を利用しているのか,余っている帯域はどれだけなのか――といった情報を管理しなくてはなりません。ルーター内部では,これらの最新の情報を使って,個々のユーザーに対する最適な帯域の配分を計算し,その帯域から送信間隔を求めます。もちろん,「余った帯域は誰にも使わせない」というアルゴリズムであれば,設定された帯域から送信間隔を求めればよいので簡単ですが,回線帯域の有効利用という観点では優れてはいません。

「100万分の1秒間に1000ユーザーのパケットの送信順を決める」

 ここまで見てきたような方法で,各ユーザー/各アプリケーションの送信間隔は求められます。しかし,1回線に複数ユーザーのトラフィックを多重しているので,一人のユーザーがやりとりするパケットの送信間隔を監視しながら送信するだけではなく,ユーザー同士のパケットの送信順序も管理しなくてはなりません。例えば,ユーザー4のパケットを送信してから,ユーザー2のパケットを送信して,その次にユーザー1のパケットを送信する――といった具合に,回線帯域を有効に利用できるように複数のパケットを順番に送り出す必要があるわけです。

 複数のユーザーのパケットを順々に送り出さなければならないため,あるユーザーがサイズの大きいパケット(ロング・パケット)を送信したために,別のユーザーのパケットを送るのが遅れてしまうということも起こりえます。こうした場合,送信が遅れたユーザーについては,次回の送信は遅れた分だけ早めに送信してあげることも必要になります(図3)。

図3●余った帯域を分配することで回線を効率的に使う
図3●余った帯域を分配することで回線を効率的に使う
[画像のクリックで拡大表示]

 当初からトラフィック管理機能を盛り込んで規格化されたATMのように,固定長のパケットを使ってデータをやりとりするのであれば,設定した帯域に従ってあらかじめすべてのユーザーの送信間隔を計算することも可能です。そのため,送信順序についても早めに計算しておけます。

 しかし,イーサネットのように可変長のパケットをやりとりする通信技術では,パケットごとに送信間隔を計算しなければ,正確な帯域計算ができません。そのため,送信順序もパケットを一つ送り出すごとに更新しなくてはなりません。

 具体的に見ていきましょう。前述の計算では,ギガビット・イーサネット回線で64バイトのアプリケーション・データを格納したパケット(MACフレーム)を送信するのにかかる時間は,1.136μsでした。仮に1000ユーザーがそのギガビット・イーサネット回線を利用して通信しているとすると,その回線を収容するルーターは,一つのパケットを送り終える1.136μsの間に,1000ユーザーの通信のパケット送信間隔を比較して,どのユーザーのパケットを次のタイミングで送信するのが最適なのか決定しなくてはなりません。こうしたことを決めるアルゴリズムにはさまざまな種類があります。

 さらに言うと,ルーターが搭載するASIC一つでギガビット・イーサネット回線を8回線分サポートするとなると,8回線分同時に1000ユーザー分の比較を行い,最適なユーザーを決定することになります。100万分の1秒ちょっとの間にこうした処理を行うのは,想像するだけで大変だとわかるでしょう。

 どこまで厳密にトラフィック・シェーピングを処理するかによって,ASICおよびルーターの設計手法は変わってきます。ただ,ギガビット級の高速回線に対応した高精度のトラフィック・シェーピングを実現するには,ソフトウエアの処理では間に合いません。どうしてもハードウエア処理が必要となります。

“敏感”なシェーピングはトラブルの原因につながる

 ここまで見てきたような制御をハードウエア処理で実現すれば,ギガビット級の回線でもユーザーごとの帯域を適切にコントロールできるようになります。ただし,回線帯域の利用率によって各ユーザーが利用できる帯域を分配するということは,余っている帯域をもらえるばかりではなく,余分に使っている帯域を最低保証帯域まで抑え込まれることもあるということです。別の言い方をすれば,一人のユーザーの帯域が大きく変化すると,良くも悪くも他のユーザーの帯域に影響を与えると言うことです。

 こうした各ユーザーの帯域の変化に対して,逐一帯域を再配分することで,厳密なトラフィック・シェーピングが実現できます。ただし,急激な帯域の変化に敏感に反応しすぎると,他のユーザーに分配される帯域が急激に上がったり下がったりしてバタバタしてしまいます。逆に反応が鈍すぎると,帯域制御がうまく働いていないように見えるかもしれません(図4)。

図4●シェーピングの感度を“敏感”にした場合と“鈍感”にした場合の差
図4●シェーピングの感度を“敏感”にした場合と“鈍感”にした場合の差
[画像のクリックで拡大表示]

 回線の帯域を有効に使うという意味では,敏感に反応して帯域を変更するほうが良いのかもしれませんが,転送速度の急激な変化は通信に大きな影響を与えます。例えば,転送速度が急に速くなると,ネットワーク内でバースト現象が発生し,中継部分のルーターや受信側の装置に十分なパケット・バッファが実装されていないと,パケット・バッファがあふれてパケットが廃棄されてしまいます。必要最低限のパケット・バッファしか実装していない装置もあるため,帯域を急激に変化させることでパケットの廃棄や再送が頻発してしまい,結果的に帯域を無駄使いしてしまうケースもあるのです。

 では,どれぐらいの“感度”が適切なのでしょうか。実は,この感度には最適な解はありません。ですから,基幹ネットワーク向けのルーターには,ネットワークのトラフィック状況を合わせて帯域変化に対する感度を調整できるような細かいパラメータを用意しておくのが現実的な対策でしょう。パラメータの設定によって,ユーザーが体感するスループットのノレベルで差が出る可能性があります。

 「トラフィック・シェーピング」という技術は,「帯域を使い過ぎているユーザーを単に抑えつけるもの」と見られがちですが,使われていない帯域をユーザーに分配するという意外と複雑なこともやっているのです。ルーターや帯域制御装置など,各メーカーからいろいろなスペックのシェーピング機能を持つ装置が出ています。アルゴリズムが標準化されているわけではないので,トラフィック・シェーピング機能の実装は,メーカーにとって工夫のしがいがある部分といえるでしょう。こうした観点から細かくトラフィック・シェーピングのしくみを見てみると,アルゴリズムの違いが見えてきておもしろいかもしれません。

林 剛久(はやし たけひさ)
アラクサラネットワークスCTO
1980年に日立製作所入社。メインフレームやUNIXサーバーなどのコンピュータ関連開発に従事したのちに,1998年よりルーターおよびスイッチ開発チームの責任者となる。独自開発ASICのハードウエア転送によるハイエンド高速ルーター/スイッチ・シリーズを製品化。また,世界に先駆けてIPv6を実装し,実用化をリードする。現在,日立製作所とNECが合弁で立ち上げたルーター/スイッチ事業会社であるアラクサラネットワークスのCTOを勤める。(アラクサラネットワークスのホームページ

岡野 薫(おかの かおる)
アラクサラネットワークス 第一製品開発部
1999年に日立製作所に入社。海外向け回線インタフェース開発,ルーター検索エンジン開発に従事した後,トラフィック・シェーパ開発を担当。現在,アラクサラネットワークスでトラフィック・シェーパ開発に従事している。

<<【1】を読む