第5回 イーサネットを高速化するジャンボ・フレーム技術：PCハードウェア強化ラボ（1/3 ページ）
イーサネットのフレームを拡張して、数Kbytesのデータを1回で送信できるようにするジャンボフレーム。その仕組みや注意点について解説。
ジャンボ・フレームで、ネットワークのパフォーマンスを向上させる
ルータやネットワーク・インターフェイス・カード（NIC）など、最近のネットワーク機器の仕様を見ると、「ジャンボ・フレームをサポート」したという記述がよく見受けられる。これを使うと、多くのデータを一度に転送でき、パフォーマンスが向上する、例えばファイル・サーバやWebブラウザの速度が向上し、快適に使えるようになる、といったことを連想する。だがその一方で、「ジャンボ・フレームを活用するには、すべての機器がジャンボ・フレームに対応している必要がある」とも書かれているが、これは具体的にはどのような状態を指すのだろうか？ ファイル・サーバにアクセスする場合はなんとなく分かるが、ではインターネットにアクセスする場合はどうなるのか？ 今回は、イーサネットのジャンボ・フレーム技術とは何か、導入に当たって注意するべき点などについてまとめておく。
イーサネットのジャンボ・フレームとは？
イーサネットでは、データ（ペイロード）を送信するためのデータ構造のことを「フレーム」というが、標準的なフレームの規格を拡張して、より大きなデータを送信できるようにしたものを「ジャンボ・フレーム」（もしくはジャンボ・パケット）という。
イーサネットの標準規格では、1フレームで送信できるデータのサイズ（MTU：Maximum Transmission Unit、最大送信単位という。関連記事参照）は最小46bytes、最大1500bytesであるが（1byte単位で可変長）、ジャンボ・フレームではこれを最小サイズは46bytesのまま、最大データ・サイズの方をだいたい9Kbytesとかそれ以上のサイズまで拡大している。「だいたい」と表現しているのは、製品によってサポートされている最大サイズに違いがあるからだ。大きいものでは16Kbytesのものもあるが、ほとんどの場合は約9Kbytesのサイズまでサポートしている。だが製品によっては最大4Kbytesしかサポートしていないものもあるなど、特定の決まったサイズがあるわけではない。
このようにさまざまに異なるサイズがあるのは、「ジャンボ・フレームの仕様には標準規格がない」からである（※1）。ジャンボ・フレームは、もともとはネットワーク機器ベンダであるAlteon Networks社（後にNortel Networksに買収されるが、Nortelもその後破産）が提唱したイーサネットの拡張規格である。送信するデータ部分のサイズを拡張するだけという単純な仕組みのため、システム的な対応は容易であり、それでいてネットワークのパフォーマンスを数十％向上させ、さらにCPUの処理負荷を半減できるなど、メリットは大きいとされている。ただしこれは今から10年ほど前のシステムにおける例であり、CPUやI/Oインターフェイスなどが高速化した現在のシステムでは少し事情は異なる。エントリ・システムですらギガビット・イーサネットの帯域をほぼ使い切ることはそう難しくない。詳細については、「Extended Frame Sizes for Next Generation Ethernets」という論文をインターネットで検索するか、ethernet allianceサイトの「White Papers」にある「Ethernet Jumbo Frames」などの文書を参照していただきたい。
※1 ジャンボ・フレームの標準規格化について
ジャンボ・フレームの標準規格化案は、草案として標準化団体（IETF）に提出されたことがあるが、主に互換性の問題のため、規格としては承認されていない（提出された草案は「Extended Ethernet Frame Size Support［英語］」）。草案の内容としては、単にイーサネットのフレーム・サイズを標準の1500bytesから、それよりも大きくする、というふうに記述しているだけである。だが通常のイーサネット機器やソフトウェアはフレーム・サイズの最大値が1500bytesであることを前提にしているものがほとんどのため、フレーム・サイズを拡大すると、ハブやルータ、ネットワーク・インターフェイス、デバイス・ドライバなどでジャンボ・フレームが破棄され、通信できなくなる可能性が非常に高い（詳細は後述）。にもかかわらず、草案にはそれを解決するような仕組みなどが含まれていない。イーサネットは互換性を最大限重視して新技術が導入されてきたが、（現状では）ジャンボ・フレームはその理念にそぐわない技術のため、標準規格としては承認されていない。
なおジャンボ・フレームのサイズはベンダごとにさまざまだが、これは標準規格が決まっていないからではない。1500bytesよりも大きくするならば、たとえ何bytesであっても事情はそう違わないので、各ベンダごとの判断に任されている。
ジャンボ・フレームで利用可能な最大データ・サイズがベンダごとに異なるのは、主にシステム的な仕様や制限に起因していると思われるが（例えばネットワーク・コントローラ内部にあるバッファや制御回路に起因する制約など）、それを統一するには各ベンダの負担が大きいし、簡便な方法もないためか、結局統一されずに今日まで来ている。イーサネットでは最大1500bytesとなっているが、FDDI（光ファイバ）では4352bytes、TokenRingでは4464bytes、ATM AAL5では9180bytesなど、もともと媒体によってMTUは異なるし、ほかのプロトコルをカプセル化して送信する用途を考えると、今後もMTUの拡大に対する要求は増える一方である。現在検討されているいくつかのネットワーク関連規格では、もっと大きなMTUや、システムごとに異なるMTUが混在しても動作するように検討されており、将来的にはそのような規格の制定によってこの混乱の解決が図られるだろう。だが現在のところは、さまざまなMTUが混在していることを前提にして、ジャンボ・フレームを使うネットワークを設計・導入する必要がある。
なお9KbytesのMTUをサポートしたジャンボ・フレームのシステムが多いのは、主にUNIX系OSでよく使われているNFS（ネットワーク・ファイル・システム）などを考慮しているからとされている。一般的なNFSの実装では、ファイルは8Kbytesのブロックに区切られてUDPプロトコルを使って転送しているが（現在ではTCPを使う方法も広く普及している）、このUDPパケットを分割することなく一度に送信できるようにするため、8Kbytesのデータといくらかのヘッダ情報などをすべて格納できるように9KbytesのMTUサイズが選ばれた。9Kbytesよりもさらに大きなジャンボ・フレームも理論的には可能であるが、フレーム内に用意されている32bitのチェック・コード（CRCコード）の特性により、11Kbytesを超えるとエラーの検出率が下がるので（データ長にして376bytesから約11Kbytesまでは同じ程度のエラー検出率だが、それを超えると信頼性が下がる）、この9Kbytes程度にしている。
【コラム】ジャンボ・フレームのそのほかの呼び方
標準のサイズよりも大きなデータを送信できるようにしたイーサネットをジャンボ・フレームと呼んでいるが、ほかにもいくつか呼び方／分類がある。
- ジャイアント・フレーム ― ジャンボ・フレームとほぼ同義語
- ベビー・ジャイント ― 802.1Q規格などで付加される、タグなどを追加したフレーム。標準フレームよりも数〜数十bytes大きい
- ミニジャンボ ― Fibre Channel over Ethernet（FCoE）をサポートするための、2500bytes程度の送信をサポートしたジャンボ・フレーム
MTUを大きくするメリット
ジャンボ・フレームでは、MTUサイズ（データを一度に送信できる最大サイズ）が大きくなっているが、それによるメリットとしては次のようなものがある。
- 処理オーバーヘッドの削減
大きなファイルやデータを送信する場合、小さいパケットをたくさん送信するよりも、大きなパケットを1つ送信する方がパケットの総数が少なくて済む。パケットを1つ処理するたびに、例えばIPやTCPなどのヘッダを付けたり、外したりする必要があるが、これらは本来のデータ転送とは関係のない無用なものである。パケット数が少なくなるなら、無駄な処理、つまりオーバーヘッドが削減でき、結局は高速化できる。 - フラグメント化（断片化）の減少
MTUが大きなネットワーク媒体からMTUの小さなネットワークへパケットを転送しなければならない場合（これはルータの処理）、パケットを分割する処理（フラグメント化）が必要になるが、MTUが大きければ分割の必要性が少なくなる。 - 割り込み処理回数の削減
送受信するパケットの数が減少すれば、割り込み処理に必要なCPUサイクルも減少し、CPUの負担が減少する。
このようなメリットがある一方、パケットが巨大化することにより、例えば送信時の帯域占有時間が長くなるといったデメリットもある。だが実際には100BASE-TXやギガビット・イーサネットなどの普及により、送信時の占有時間は抑制可能である。高速なネットワークほど、大きなMTUを使えば、さらに効率よく送信できるようになる可能性がある。
ジャンボ・フレームの構造
通常のイーサネット・フレームとジャンボ・フレームの構造を以下に示しておく。イーサネットの動作原理については、以下の記事などを参照していただきたい。
イーサネットのフレーム構造
イーサネットで送信するデータには、送信する先と送信元のアドレス情報を付け、さらにデータのタイプ（プロトコルなど）を表す情報を付けてケーブル上へ送り出す。プリアンブルやFCSはイーサネットのコントローラによって自動的に付加される。受信側ではプリアンブルの直後からデータを取り込み始め、最後にFCSのデータが揃ったところで受信を停止する。FCSは上位レイヤへは渡されない。データ部分のサイズが1501bytes以上のものをジャンボ・フレームと呼ぶ。
それぞれのフィールドの詳しい説明は次の通りである。
| 項目 | サイズ | 用途 |
|---|---|---|
| （プリアンブル） | 最大7bytes | フレームの開始を知らせるための同期情報。最大7bytes分の決まったパターンからなる。イーサネットの受信回路は、この信号を受信するとデータを取り込む準備を始める。なお、スイッチやハブを通過すると、同期信号の一部が削られて（受信回路がすぐに同期しないため）短くなることがあるが、この部分にはデータは含まれていないので問題ない |
| （SFD） | 1byte | フレームの開始を知らせるための同期情報。SFD（Start Frame Delimiter）。この直後からフレーム・データが開始するということを知らせる1byteの同期信号。受信回路は、このSFDの次のbitからデータの取り込みを開始する |
| あて先アドレス | 6bytes | フレームのあて先のMACアドレス |
| 送信元アドレス | 6bytes | フレームの送信元のMACアドレス |
| VLANタグ | 4bytes（オプション） | 802.1Q VLANタグ（オプション） |
| タイプ／サイズ | 2bytes | 0x0800未満ならフレームのサイズを表し（ただしこの用途で使うプロトコルは少ない）、0x0800以上なら、データ部分に格納されているプロトコルの種別。例えば0x0800ならIP、0x8191ならNetBEUIなど |
| データ | 標準では46〜1500bytes、ジャンボ・フレームでは最大9Kbytes程度 | ここに上位プロトコル（IPなど）のデータが入る。このデータ部分の最大長をMTUといい、標準のイーサネットでは1500、ジャンボ・フレーム対応なら9200程度の値になる |
| （FCS） | 4bytes | フレーム・データの正当性を証明するためのチェック・コード。あて先アドレスからデータ部分までのデータを基に、32bitのCRCコード値が計算される。受信したパケット内の値と、計算したCRCコードが一致していれば、エラーなしと判断され、システムにパケットが取り込まれる。コードが一致しなければこのフレームは破棄される |
| （IFG） | 12bytes（96bit）分以上 | 1つのノードがずっと帯域を占有しないように、パケットを送受信した場合は、最低でもこのIFG（Inter Frame Gap）の時間だけ待ってから、次の送信を開始する。これにより、ほかのノードにも平等に送信のチャンスが与えられる |
| イーサネット・フレームの項目 括弧に囲まれている項目は、一般的にはイーサネットのコントローラ・チップが自動的に付加するフィールドであり、ユーザー（OSなど、イーサネットに送信を指示する側）では関知しない／できない領域である。 | ||
まず一番上の標準のイーサネットのフレームについてみてみよう。
■標準フレームの場合
先頭にあて先のMACアドレスや送信元MACアドレス、タイプ・フィールドなどが並び、その次から送信するべきデータが最大1500bytes置かれている。このデータ部分の長さをイーサネットのMTUという。送信するデータが何もない場合でもいくらかの埋め合わせ用のデータを置き（どういうデータを埋めるかは関知しない。通常はセキュリティのことを考えて、オール・ゼロ・データなどで埋める）、データ部分の長さは最低でも46bytes分を確保する。データ部に続き、最後に4bytesのエラー・チェック用コード（CRCコード）のフィールドが続く。ヘッダ、データ、FCSの3つを合わせると、最低でも64bytes、最長だと1518bytesとなり、これをイーサネットのフレーム長と呼ぶ。ただし場合によっては最後のFCS部分を除外し、フレーム長を64〜1514bytesと計算することもあるが、実質的には同じことである。
VLANタグが利用される場合は送信元MACアドレスとタイプ・フィールドの間に置くので、この場合はフレーム長は4bytes分増加して68〜1522bytesとなる。1500bytesを超えるため、非常に古いイーサネット機器では問題になることがあるが、現在市販されている製品では問題ないだろう（VLANは標準規格のため、現在の製品はすべて対応している）。
■ジャンボ・フレームの場合
ジャンボ・フレームとは、単にデータ部に1500bytesよりも多くのデータを格納したパケットのことである。構造的には標準フレームとの違いはなく、タイプ・フィールドやFCSもまったく同じである。データ部が1500bytes以下なら通常のイーサネット・フレームそのものである。
ジャンボ・フレームで通信するには？
このように通常のフレームとジャンボ・フレームでは、データ部の長さ以外には違いがないので、通常のイーサネットとほぼ同じシステム、アルゴリズムなどが利用できる。
とはいえ、イーサネットの最大MTUサイズは1500bytesであることを前提としたシステムやアプリケーション、OSなどが存在するので、どのコンピュータからでも勝手にジャンボ・フレームを送信するわけにはいかない。ジャンボ・フレームに非対応のシステムや機器では、ジャンボ・フレームのパケットを受信しても、それは単なるエラーのあるデータ（1500bytes目に正常なFCSが存在しないフレーム）とみなして破棄してしまうだけだからだ。途中まで（1500bytesまで）受信するのではなく、フレーム全体を破棄してしまう。さらにイーサネットの通信アルゴリズムでは、フレームが不完全／過大なので再送しろと要求することもないし、大きいからといって、イーサネット・レベルで（L2レベルで）誰かが分割して再送信することもない。だからジャンボ・フレームで通信したいコンピュータやネットワーク機器は、あらかじめお互いにジャンボ・フレームで通信するということを同意して準備している必要がある。
なお、通常のネットワーク・プロトコルではこのような場合、通信開始時にお互いにネゴシエーションなどを行ってジャンボ・フレームで通信できるかどうかを確認するところだろう。そして、相手がジャンボ・フレームを受信可能な場合のみジャンボ・フレームを送信し、そうでなければ通常のフレームを送信する、というふうに動作させるに違いない。だがすでに述べたようにジャンボ・フレームには正式な規格がない。なので、ネゴシエーションの方法も決まってないし、事前にお互いのMTUサイズを調べたり、調査する標準的な方法もない。例えば、ジャンボ・フレームを有効にしたシステムをジャンボ・フレーム非対応のスイッチ／ハブに接続したり、通信経路の途中にジャンボ・フレーム非対応のスイッチ／ハブがあっても何も警告されないし、MTUが1500に再設定されることもない。
これはとても不便ではあるが、何も決まっていない分、既存のシステムやプロトコルに対する変更は何もいらないというメリットもある。代わりにユーザー（管理者、人間）が、相互にジャンボ・フレームで通信可能な環境を整え、あらかじめセットアップしておくという必要性が生まれたが。
【更新履歴】
【2011/08/29】「ジャンボ・フレームの標準規格化について」の補足を追加しました。
Copyright© Digital Advantage Corp. All Rights Reserved.