7. Control Connection State Machines (Steuerverbindungs-Zustandsmaschinen)

Dieses Kapitel definiert die Zustandsmaschinen für den Aufbau, die Aufrechterhaltung und den Abbau von L2TP-Steuerverbindungen und -Sitzungen.

7.1 Control Connection Protocol Operation (Steuerverbindungs-Protokollbetrieb)

Die Zustandsmaschine der Steuerverbindung beschreibt die Zustandsübergänge beim Aufbau und Abbau von Tunneln. Jeder Zustand definiert die zulässigen Ereignisse, die entsprechenden Aktionen und den Folgezustand.

Ein LAC (L2TP Access Concentrator, L2TP-Zugriffskonzentrator) oder LNS (L2TP Network Server, L2TP-Netzwerkserver) MUSS die hier beschriebenen Zustandsmaschinen implementieren, um die korrekte Interoperabilität sicherzustellen.

7.2 Control Connection States (Steuerverbindungszustände)

Die Steuerverbindung durchläuft folgende Zustände:

idle: Ausgangszustand; es besteht keine aktive Verbindung.
wait-ctl-reply: Warten auf die Steuerverbindungsantwort des Gegenstellen-Peers.
wait-ctl-conn: Warten auf den Abschluss der Steuerverbindung.
established: Die Steuerverbindung ist vollständig aufgebaut.
closing: Die Steuerverbindung wird gerade abgebaut.

7.2.1 Control Connection Establishment (Steuerverbindungsaufbau)

Der Aufbau der Steuerverbindung erfolgt mittels eines Drei-Wege-Handshakes unter Verwendung der Nachrichten SCCRQ (Start-Control-Connection-Request), SCCRP (Start-Control-Connection-Reply) und SCCCN (Start-Control-Connection-Connected).

Die Zustandsübergänge verlaufen wie folgt:

idle → wait-ctl-reply: Der initiierende Peer sendet eine SCCRQ-Nachricht.
wait-ctl-reply → wait-ctl-conn: Der initiierende Peer empfängt eine SCCRP-Nachricht vom Gegenstellen-Peer.
wait-ctl-conn → established: Der initiierende Peer sendet eine SCCCN-Nachricht; der Gegenstellen-Peer wechselt nach Empfang von SCCCN ebenfalls in den Zustand established.

Empfängt ein Peer während des Aufbaus eine StopCCN-Nachricht oder tritt ein Fehler auf, MUSS die Verbindung in den Zustand idle zurückversetzt und alle zugehörigen Ressourcen freigegeben werden.

7.3 Timing Considerations (Zeitliche Überlegungen)

Für den zuverlässigen Betrieb der Steuerverbindung sind folgende Zeitparameter relevant:

Retransmission Timer (Wiederholungssendetimer): Steuerverbindungsnachrichten MÜSSEN bei ausbleibender Bestätigung erneut gesendet werden. Der Timer SOLLTE mit einem exponentiellen Backoff-Verfahren implementiert werden.
Hello-Intervall: In regelmäßigen Abständen SOLLTEN Hello-Nachrichten gesendet werden, um die Verfügbarkeit des Tunnels zu überprüfen.
Timeout-Erkennung: Bleibt eine Antwort auf Hello-Nachrichten oder Steuerverbindungsnachrichten innerhalb einer definierten Zeitspanne aus, MUSS der Tunnel als ausgefallen betrachtet und abgebaut werden.

Die genauen Zeitwerte sind implementierungsabhängig; es SOLLTEN jedoch angemessene Standardwerte gewählt werden, um sowohl Reaktionsfähigkeit als auch Netzwerkstabilität zu gewährleisten.

7.4 Incoming Calls (Eingehende Anrufe)

Der Aufbau eingehender Anrufe (Incoming Calls) erfordert koordinierte Zustandsübergänge sowohl auf der LAC- als auch auf der LNS-Seite. Der LAC erkennt einen eingehenden Anruf und benachrichtigt den LNS über die entsprechenden L2TP-Steuernachrichten.

7.4.1 LAC Incoming Call States (LAC-Zustände für eingehende Anrufe)

Die Zustandsmaschine des LAC für eingehende Anrufe umfasst folgende Zustände:

idle: Kein aktiver Anruf vorhanden.
wait-reply: Der LAC hat eine ICRQ (Incoming-Call-Request)-Nachricht an den LNS gesendet und wartet auf eine ICRP (Incoming-Call-Reply)-Antwort.
wait-connect: Der LAC wartet auf den Verbindungsabschluss durch den LNS mittels ICCN (Incoming-Call-Connected).
established: Die Sitzung ist vollständig aufgebaut.

Zustandsübergänge:

idle → wait-reply: LAC sendet ICRQ an den LNS.
wait-reply → wait-connect: LAC empfängt ICRP vom LNS.
wait-connect → established: LAC sendet ICCN; die Sitzung ist aufgebaut.

7.4.2 LNS Incoming Call States (LNS-Zustände für eingehende Anrufe)

Die Zustandsmaschine des LNS für eingehende Anrufe umfasst folgende Zustände:

idle: Kein aktiver Anruf vorhanden.
wait-connect: Der LNS hat eine ICRP-Nachricht gesendet und wartet auf die ICCN-Nachricht des LAC.
established: Die Sitzung ist vollständig aufgebaut.

Zustandsübergänge:

idle → wait-connect: LNS empfängt ICRQ und sendet ICRP.
wait-connect → established: LNS empfängt ICCN vom LAC.

7.5 Outgoing Calls (Ausgehende Anrufe)

Ausgehende Anrufe (Outgoing Calls) werden vom LNS initiiert; der LAC führt den eigentlichen Verbindungsaufbau zum Endgerät durch. Die verwendeten Steuernachrichten sind OCRQ (Outgoing-Call-Request), OCRP (Outgoing-Call-Reply) und OCCN (Outgoing-Call-Connected).

7.5.1 LAC Outgoing Call States (LAC-Zustände für ausgehende Anrufe)

Die Zustandsmaschine des LAC für ausgehende Anrufe umfasst folgende Zustände:

idle: Kein aktiver Anruf vorhanden.
wait-reply: Der LAC hat eine OCRP-Nachricht gesendet und wartet auf weitere Anweisungen.
wait-cs-answer: Der LAC wartet auf die Antwort des angerufenen Endgeräts.
established: Die Sitzung ist vollständig aufgebaut.

Zustandsübergänge:

idle → wait-reply: LAC empfängt OCRQ vom LNS und sendet OCRP.
wait-reply → wait-cs-answer: LAC initiiert den Anruf zum Endgerät.
wait-cs-answer → established: Das Endgerät antwortet; LAC sendet OCCN an den LNS.

7.5.2 LNS Outgoing Call States (LNS-Zustände für ausgehende Anrufe)

Die Zustandsmaschine des LNS für ausgehende Anrufe umfasst folgende Zustände:

idle: Kein aktiver Anruf vorhanden.
wait-reply: Der LNS hat eine OCRQ-Nachricht gesendet und wartet auf die OCRP-Antwort des LAC.
wait-connect: Der LNS wartet auf die OCCN-Nachricht des LAC.
established: Die Sitzung ist vollständig aufgebaut.

Zustandsübergänge:

idle → wait-reply: LNS sendet OCRQ an den LAC.
wait-reply → wait-connect: LNS empfängt OCRP vom LAC.
wait-connect → established: LNS empfängt OCCN vom LAC.

7.6 Tunnel Disconnection (Tunnelabbau)

Der Tunnelabbau KANN von LAC oder LNS durch Senden einer StopCCN (Stop-Control-Connection-Notification)-Nachricht eingeleitet werden. Die StopCCN-Nachricht enthält einen Result Code (Ergebniscode), der den Grund für den Abbau angibt.

Nach Empfang einer StopCCN-Nachricht MUSS der empfangende Peer:

Die StopCCN-Nachricht bestätigen (ZLB, Zero-Length Body).
Alle aktiven Sitzungen innerhalb des Tunnels beenden.
Alle zugehörigen Ressourcen freigeben.
Den Zustand der Steuerverbindung auf idle zurücksetzen.

Ein Peer DARF NICHT versuchen, neue Sitzungen über einen Tunnel aufzubauen, für den eine StopCCN-Nachricht empfangen oder gesendet wurde. Nach dem Abbau KANN ein neuer Tunnel zwischen denselben Endpunkten aufgebaut werden, sofern dies erforderlich ist.

Hinweis: Vollständige Zustandsübergangstabellen und detaillierte Zustandsmaschinendiagramme sind im Originaltext von RFC 2661 enthalten. Dieses Kapitel bietet eine Übersicht der Zustandsmaschinen und der wesentlichen Zustandsübergänge.