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

5. ユースケース

各エンドポイントは、特定のユースケースに必要なレートとパディングで HeartbeatRequest メッセージを送信します。エンドポイントは、ピアが HeartbeatRequests を送信することを期待すべきではありません。方向は独立しています。

5.1. パス MTU ディスカバリ

DTLS は、[RFC6347] のセクション 4.1.1.1 で説明されているように、パス MTU ディスカバリを実行します。パス MTU ディスカバリの実行方法の詳細な説明は [RFC4821] に記載されています。必要なプローブパケット (probe packets) は HeartbeatRequest メッセージです。

DTLS に HeartbeatRequest メッセージを使用するこの方法は、[RFC4820] で定義されているパディングチャンク (padding chunk, PAD-chunk) を使用するストリーム制御伝送プロトコル (Stream Control Transmission Protocol, SCTP) の方法と同様です。

5.2. 生存性チェック

HeartbeatRequest メッセージを送信することで、送信者はピアに到達でき、ピアが生きていることを確認できます。TLS/TCP の場合でも、これにより TCP キープアライブ機能が許可するよりもはるかに高いレートでチェックできます。

ピアがまだ到達可能であることを確認することに加えて、HeartbeatRequest メッセージを送信すると、関係するすべての NAT の NAT 状態が更新されます。

HeartbeatRequest メッセージは、少なくとも複数の往復時間の長さのアイドル期間の後にのみ送信すべきです (SHOULD)。このアイドル期間は、数分間までの期間および 1 秒間までの期間まで設定可能であるべきです (SHOULD)。アイドル期間のデフォルト値は設定可能であるべきですが (SHOULD)、ピアごとに調整可能であるべきです (SHOULD)。