メインコンテンツまでスキップ

2. 概要

パケット化レイヤパスMTU探索(PLPMTUD)は、TCPまたは他のパケット化プロトコルが、段階的に大きくなるパケットでパスをプローブすることにより、パスのMTUを動的に発見する方法です。RFC 1191およびRFC 1981で指定されているICMPベースのパスMTU探索メカニズムと併用すると最も効率的ですが、ICMPメッセージの配信に依存しないため、古典的な技術の多くの堅牢性の問題を解決します。

この方法は、パケット境界(例：セグメントサイズ)を選択する責任があり、どのパケットが失われたかを送信者に正確かつタイムリーに示す確認応答構造を持つTCPおよび他のトランスポート層またはアプリケーション層プロトコルに適用できます。

一般的な戦略​

一般的な戦略は、パケット化レイヤが段階的に大きくなるパケットでパスをプローブすることにより、適切なパスMTUを見つけることです。プローブパケットが正常に配信された場合、有効なパスMTUはプローブサイズに引き上げられます。

プローブパケットの孤立した損失(ICMP Packet Too Bigメッセージの有無にかかわらず)は、MTU制限の指示として扱われ、輻輳指示としては扱われません。この場合のみ、パケット化プロトコルは輻輳ウィンドウを調整せずに欠落データを再送信することが許可されます。

プローブプロセス中にタイムアウトまたは追加のパケット損失がある場合、プローブは決定的でないと見なされます(例：失われたプローブは必ずしもプローブがパスMTUを超えたことを示しません)。さらに、損失は他の輻輳指示と同様に扱われます：関連する輻輳制御標準[RFC2914]に従って、ウィンドウまたはレート調整が必須です。検出された障害の性質によって決定される遅延の後、プローブを再開できます。

検索技術​

PLPMTUDは検索技術を使用してパスMTUを見つけます。各決定的なプローブは、成功したプローブで下限を上げるか、失敗したプローブで上限を下げることにより、MTU検索範囲を狭め、真のパスMTUに収束します。ほとんどのトランスポート層では、範囲が十分に狭くなり、より大きな有効パスMTUの利点がそれを見つける検索オーバーヘッドよりも小さくなったら、検索を停止する必要があります。

プローブ失敗の処理​

最も可能性が高い(そして最も深刻でない)プローブ失敗は、プローブ中にリンクが輻輳関連の損失を経験したことによるものです。この場合、パケット化レイヤが輻輳に完全に適応し、損失から回復するとすぐに、同じサイズのプローブを再試行することが適切です。他のケースでは、追加の損失またはタイムアウトがリンクまたはパケット化レイヤの問題を示します。これらの状況では、エラーの重大度に応じてより長い遅延を使用することが望ましいです。

MTU検証​

MTUを上げることがパケット損失率を上げる状況を検出するために、オプションの検証プロセスを使用できます。例えば、リンクが一貫性のないMTUを持つ複数の物理チャネルにストライプされている場合、一部の物理チャネルに対して大きすぎても、プローブが配信される可能性があります。このような場合、パスMTUをプローブサイズに上げると、深刻なパケット損失と悲惨なパフォーマンスを引き起こす可能性があります。MTUを上げた後、損失率を監視することで新しいMTUサイズを検証できます。

実装の柔軟性​

パケット化レイヤPMTUD(PLPMTUD)は、古典的なパスMTU探索の実装にいくつかの柔軟性を導入します。古典的なパスMTU探索の堅牢性を高めるためにICMPブラックホール回復のみを実行するように構成することも、他の極端な場合には、すべてのICMP処理を無効にしてPLPMTUDが古典的なパスMTU探索を完全に置き換えることもできます。

何らかの理由でICMP Packet Too Big(PTB)メッセージが配信または処理されない場合、古典的なパスMTU探索はプロトコル障害(接続ハング)の影響を受けます[RFC2923]。PLPMTUDを使用すると、追加チェックの偽の障害による接続ハングのリスクを増やすことなく、追加の一貫性チェックを含むように古典的なパスMTU探索を変更できます。古典的なパスMTU探索に対するこのような変更は、本ドキュメントの範囲外です。

極限的なケースでは、すべてのICMP PTBメッセージが無条件に無視される可能性があり、PLPMTUDをパスMTUを発見する唯一の方法として使用できます。この構成では、PLPMTUDは輻輳制御と並行します。エンドツーエンドトランスポートプロトコルは、データストリームのプロパティ(ウィンドウサイズまたはパケットサイズ)を調整しながら、パケット損失を使用して調整の適切性を推測します。この技術は、複数のプロトコル層の転写ヘッダーを含むICMPメッセージに依存するよりも、インターネットのエンドツーエンド原則と哲学的により一貫しているようです。

実装に関する考慮事項​

PLPMTUDの実装が困難である理由の大部分は、単一のノード内の複数の異なる場所に実装する必要があるためです。一般に、各パケット化プロトコルは独自のPLPMTUD実装を持つ必要があります。さらに、同時または後続の接続間でパスMTU情報を共有する自然なメカニズムは、IP層のパス情報キャッシュです。さまざまなパケット化プロトコルは、IP層の共有キャッシュにアクセスして更新する手段を持つ必要があります。このメモは、PLPMTUDをその主要なサブシステムの観点から説明していますが、それらが完全な実装にどのように組み立てられるかを完全には説明していません。

本ドキュメントで説明されている実装詳細の大部分は、以前のバージョンのパスMTU探索の経験に基づく推奨事項です。これらの推奨事項は、フィールドに存在する理想的でないネットワーク条件の存在下でPLPMTUDの堅牢性を最大化したいという願望によって動機付けられています。

本ドキュメントには、実装の完全な説明は含まれていません。他の実装との相互運用性に影響を与えず、外部から課される強力な最適性基準(例：MTU検索およびキャッシングヒューリスティック)を持つ詳細のみをスケッチします。明らかな代替実装が存在するが、いくつかの(おそらく微妙な)ケースでうまく機能しないため、他の詳細が明示的に含まれています。

ドキュメント構造​

  • セクション3は、用語の完全な用語集を提供します。
  • セクション4は、他の標準またはインターネットプロトコルとの相互運用性に影響を与えるPLPMTUDの詳細を説明します。
  • セクション5は、PLPMTUDをレイヤに分割する方法と、IP層のパス情報キャッシュを管理する方法を説明します。
  • セクション6は、PLPMTUDを実装するために必要な一般的なパケット化レイヤのプロパティと機能を説明します。
  • セクション7は、プローブを使用してパスMTUを検索する方法を説明します。
  • セクション8は、IPv6への移行時の将来の問題を最小限に抑えるために、IPv6機能を模倣する構成でIPv4断片化を使用することを推奨します。
  • セクション9は、独自のパケット境界を選択するアプリケーションでPLPMTUDを実装するためのプログラミングインターフェースと、パスMTU探索を妨げるパス問題を診断できるツールについて説明します。
  • セクション10は、TCPを含む特定のプロトコルの実装詳細について説明します。
に最終更新