応用科学
ジャンボフレーム
コンピュータネットワーキングでは、 ジャンボフレームは、IEEE 802.3規格で設定された1500バイトを超えるペイロードを持つイーサネットフレームです。従来、ジャンボフレームは最大9000バイトのペイロードを搬送できますが、バリエーションが存在するため、この用語を使用する場合は注意が必要です。多くのギガビットイーサネットスイッチおよびギガビットイーサネットネットワークインターフェイスカードは、ジャンボフレームをサポートできます。一部のファストイーサネットスイッチおよびファストイーサネットネットワークインターフェイスカードは、ジャンボフレームもサポートできます。
インセプション
各イーサネットフレームは、ネットワークを通過するときに処理する必要があります。単一の大きなフレームのコンテンツを処理することは、同じコンテンツを小さなフレームに分割するよりも、割り込みを減らすことで利用可能なCPU時間をより有効に活用できるため、望ましいです。これにより、オーバーヘッドバイトカウントも最小限に抑えられ、処理が必要なフレームの数が削減されます。これは、それぞれが1枚の複数の封筒ではなく、紙のパケットを物理的に郵送することに似ており、封筒を節約してソート時間を短縮します。
Alteon WebSystemsがACEnicギガビットイーサネットアダプターにジャンボフレームを導入したことで、ジャンボフレームが最初に顕著になりました。他の多くのベンダーもこのサイズを採用しています。ただし、ジャンボフレームは公式のIEEE 802.3イーサネット標準の一部ではありません。
可決
ジャンボフレームは、オーバーヘッドとCPUサイクルを削減する可能性があり、エンドツーエンドのTCPパフォーマンスにプラスの効果があります。ジャンボフレームの存在は、特に低帯域幅のリンクで、ネットワーク遅延に悪影響を与える可能性があります。エンドツーエンド接続で使用されるフレームサイズは、通常、中間リンクの最低フレームサイズによって制限されます。 802.5トークンリングは4464バイトMTUのフレームをサポートでき、FDDIは4352バイト、ATM 9180バイトを転送でき、802.11は7935バイトMTUを転送できます。 IEEE 802.3イーサネット標準では、1500バイトのMTUフレーム、合計1518バイトのフレームサイズ(オプションのIEEE 802.1Q VLAN / QoSタグを含む1522バイト)のサポートのみが義務付けられています。
ジャンボフレームの優先ペイロードサイズとしての9000バイトの使用は、Internet2と米国連邦政府ネットワークの共同エンジニアリングチーム内での議論から生じました。彼らの勧告は、他のすべての国家研究および教育ネットワークで採用されています。この必須の購買基準を満たすために、製造業者は、従来のMTUサイズとして9000バイトを採用し、ジャンボフレームサイズは少なくとも9018/9022バイト(IEEE 802.1Qフィールドなし/あり)です。ほとんどのイーサネット機器は、最大9216バイトのジャンボフレームをサポートできます。
IEEE 802.1AB-2009およびIEEE 802.3bc-2009は、最大フレーム長(TLVサブタイプ4)の標準イーサネットにLLDPディスカバリーを追加しました。 2オクテットフィールドにより、ポートでフレーム長を検出できます。 IEEE 802.3-2015では、許可される値は1518 (基本フレームのみ)、 1522 (802.1Qタグ付きフレーム)、および2000 (マルチタグ付きエンベロープフレーム)です。
エラー検出
イーサネットフレームで使用される単純なCRC32エラー検出では、フレームサイズが大きくなると、いくつかのエラーが互いに相殺される可能性が高くなるため、フレームが大きくなると検出されないエラーが発生しやすくなります。その結果、より高いネットワーク層でのエラー検出を改善するための追加のメカニズムが開発されました。
ジャンボフレームを採用するための1つのIETFソリューションは、SCTPトランスポート(RFC 4960)およびiSCSI(iSCSI内に実装されているCastagnoli CRC多項式を使用して、イーサネット上の次のネットワークプロトコル層で追加のCRCを実行することにより、サービスデータユニットのデータ整合性の低下を回避しますRFC 7143)。この多項式の選択は、「インターネットアプリケーション用の32ビット巡回冗長コード」という論文に記載されている作業に基づいています。 Castagnoli多項式0x1EDC6F41は、1つのイーサネットMTUを超えるハミング距離HD = 6(16,360ビットのデータワード長まで)およびHD = 4〜114,663ビットを実現します。これは、イーサネットMTUの9倍以上です。これにより、イーサネットCRC標準多項式と比較して、MTUサイズのデータワードで2ビットのエラー検出機能が追加されますが、72 kビット以上のデータワードサイズのHD = 4機能は犠牲になりません。
UDPおよびTCPトランスポート内に含まれる単純な追加チェックサムではなくCRCチェックサムを使用することにより、NIC内部で生成されたエラーも検出できます。 TCPとUDPの両方は、バス固有のビットエラーを検出するのに効果的でないことが証明されています。これらの単純な合計のエラーは、自己キャンセルされる傾向があるためです。 RFC 3309の採用につながったテストでは、実際のデータに対するエラー挿入のシミュレーションに基づいて、これらのエラーの2%が検出されなかったことを示す証拠をまとめました。
ジャンボフレームの採用に対する主要な障害の1つは、エラーを検出する機能の低下を回避するために必要な既存のイーサネットインフラストラクチャをアップグレードできないことです。ソフトウェアで行われるCRC計算は、TCPおよびUDPで見られるような単純な加算チェックサムを使用する場合に達成されるパフォーマンスよりも常にパフォーマンスが遅くなります。このパフォーマンスの低下を克服するために、SCTPチェックサム計算の負荷を軽減するNICが利用可能であり、SSE4.2をサポートするCPUは、拡張機能のベクトル演算命令セットにあるCRC32c命令を利用できます。
データチャンクを処理するように設計された汎用トランスポート内およびSCSIデータを伝送するように設計されたTCPトランスポート内でのCastagnoli CRC多項式のサポートにより、イーサネットMTUの増加が結果として生じるジャンボフレームの使用にもかかわらず、エラー検出率が向上しますエラー検出の大幅な削減。
設定
ベンダーによっては、サイズ設定にヘッダーが含まれていますが、他のベンダーは含まれていません。つまり、 最大フレームサイズ (フレームヘッダー、最大レイヤー2パケットサイズを含む)または最大転送ユニット(MTU) (フレームヘッダーを除く最大レイヤー3パケットサイズ)です。 。したがって、設定を一致させるには、さまざまなベンダーの機器でさまざまな値を設定する必要がある場合があります。ネットワーク上でジャンボフレーム用に構成されたデバイスとジャンボフレーム用に構成されていないデバイスが混在すると、ネットワークパフォーマンスの問題が発生する可能性があります。
帯域幅効率
TCP over IPv4での次の例に示すように、ジャンボフレームは、プロトコルのオーバーヘッドを削減することにより、ホストでのイーサネットおよびネットワーク処理の効率を向上させることができます。ホストの処理オーバーヘッドは、ペイロードサイズの比率によって減少する可能性があります(この例では約6倍の改善)。これが重要かどうかは、ホストでのパケットの処理方法によって異なります。 TCPオフロードエンジンを使用するホストは、CPUでフレームを処理するホストよりもメリットが少なくなります。
フレームタイプ | MTU | レイヤー1オーバーヘッド | レイヤー2オーバーヘッド | レイヤー3オーバーヘッド | レイヤー4オーバーヘッド | ペイロードサイズ | 合計送信 | 効率 | |||
---|---|---|---|---|---|---|---|---|---|---|---|
標準 | 1500 | 前文 8バイト | IPG 12バイト | フレームヘッダー 14バイト | FCS 4バイト | IPv4ヘッダー 20バイト | TCPヘッダー 20バイト | 1460バイト | 1538バイト | 94.93% | |
ジャンボ | 9000 | 前文 8バイト | IPG 12バイト | フレームヘッダー 14バイト | FCS 4バイト | IPv4ヘッダー 20バイト | TCPヘッダー 20バイト | 8960バイト | 9038バイト | 99.14% | |
参考のための他のフレームサイズ | |||||||||||
IEEE 802.11 | 7935 | PLCPプリアンブルとヘッダー 24バイト | IPG 不定 | フレームヘッダーとセキュリティovhd 52バイト | FCS 4バイト | IPv4ヘッダー 20バイト | TCPヘッダー 20バイト | 7895バイト | 8015 + IPGサイズバイト | 98.5% | |
イーサネットにブリッジされたIEEE 802.11 | 1500 | PLCPプリアンブルとヘッダー 24バイト | IPG 不定 | フレームヘッダーとセキュリティovhd 52バイト | FCS 4バイト | IPv4ヘッダー 20バイト | TCPヘッダー 20バイト | 1460バイト | 1580 + IPGサイズバイト | 92.4% |
- ^合計送信サイズは、ペイロードサイズとすべてのオーバーヘッドサイズの合計です。
- ^効率は、ペイロードサイズを合計送信サイズで除算することによって計算されます。
ベビージャイアントフレーム
ベビージャイアントまたはベビージャンボフレームは、IEEEイーサネット標準で許可されているよりもわずかに大きいイーサネットフレームです。ベビージャイアントフレームは、たとえば、イーサネットサービスを提供するためにIP / MPLS over Ethernetを有効にするために必要です。ほとんどの実装では、非ジャンボユーザーフレームをMPLSフレーム形式にカプセル化する必要があります。MPLSフレーム形式は、EtherType値が0x8847および0x8848の適切なイーサネットフレーム形式にカプセル化できます。追加のMPLSおよびイーサネットヘッダーのオーバーヘッドの増加は、1600バイトフレームのサポートがキャリアイーサネットネットワークの必須要件であることを意味します。
スーパージャンボフレーム
スーパージャンボフレーム (SJF)は一般に、9000バイトを超えるペイロードサイズを持つフレームと見なされます。パケット転送速度の関数としてのネットワークデータスループットの相対的なスケーラビリティは、複雑な方法でパケットあたりのペイロードサイズに関連しています。一般に、ラインビットレートが増加すると、同等のタイミングパラメータを維持するために、パケットペイロードサイズが正比例して増加するはずです。ただし、これは、必要な最大フレームサイズに対応するために、ネットワークパスに沿って多数の中間論理回路をスケーリングすることを意味します。高性能の国家研究教育ネットワークのパスMTUを1500バイトから9000バイト程度に増やすのは比較的困難で、やや長いプロセスであったため、その後の増加(おそらく64,000バイトなど)には時間がかかる場合があります。
最大セグメントサイズ(MSS)の増加に関連する主な要因は、パスに沿って介在するすべての永続化メカニズムで利用可能なメモリバッファーサイズの増加です。これの主な利点は、エンドノードと中間中継ノードの両方でパケットレートが低下することです。一般にノードは往復ロジックを使用してパケットを処理するため、送信されるデータの総量が一定の場合、パケットの平均MSSが増加すると、パケットヘッダーの処理に費やされるマシンサイクルの総数が減少します。この関係は、平均ネットワークラインビットレートが毎秒10ギガビット以上に増加するにつれて、ますます重要になります。
代替アプローチ
CPUの負荷をフレームサイズに依存しないようにすることで、大送信オフロード(LSO)は、ジャンボフレームが削減するように設計されたパケットごとのオーバーヘッドを排除するアプローチです。 CPUが負担するパケットごとのオーバーヘッドを完全に排除するため、ジャンボフレームはインバウンドトラフィックにとって有益なままです。ジャンボフレームは、データ以外のオーバーヘッドに使用される帯域幅の量を削減するため、帯域幅の観点からも有用です。