5. Anwendungsfälle

Jeder Endpunkt sendet HeartbeatRequest-Nachrichten mit der Rate und dem Padding, die für den jeweiligen Anwendungsfall erforderlich sind. Der Endpunkt sollte nicht erwarten, dass sein Peer HeartbeatRequests sendet. Die Richtungen sind unabhängig.

5.1. Pfad-MTU-Erkennung

DTLS führt eine Pfad-MTU-Erkennung durch, wie in Abschnitt 4.1.1.1 von [RFC6347] beschrieben. Eine detaillierte Beschreibung der Durchführung der Pfad-MTU-Erkennung wird in [RFC4821] gegeben. Die erforderlichen Probe-Pakete sind die HeartbeatRequest-Nachrichten.

Diese Methode der Verwendung von HeartbeatRequest-Nachrichten für DTLS ist ähnlich der für das Stream Control Transmission Protocol (SCTP) unter Verwendung des Padding-Chunks (PAD-Chunk), der in [RFC4820] definiert ist.

5.2. Lebenszeichen-Prüfung

Das Senden von HeartbeatRequest-Nachrichten ermöglicht es dem Sender sicherzustellen, dass er den Peer erreichen kann und der Peer am Leben ist. Selbst im Fall von TLS/TCP ermöglicht dies eine Überprüfung mit einer viel höheren Rate, als es die TCP-Keep-Alive-Funktion erlauben würde.

Neben der Sicherstellung, dass der Peer noch erreichbar ist, aktualisiert das Senden von HeartbeatRequest-Nachrichten den NAT-Status aller beteiligten NATs.

HeartbeatRequest-Nachrichten SOLLTEN (SHOULD) nur nach einer Leerlaufzeit gesendet werden, die mindestens mehrere Rundlaufzeiten lang ist. Diese Leerlaufzeit SOLLTE (SHOULD) bis zu einem Zeitraum von mehreren Minuten und bis zu einem Zeitraum von einer Sekunde konfigurierbar sein. Ein Standardwert für die Leerlaufzeit SOLLTE (SHOULD) konfigurierbar sein, aber er SOLLTE (SHOULD) auch auf Peer-Basis anpassbar sein.