3. Protokollbetrieb (Protocol Operation)
Dieser Abschnitt beschreibt die operativen Details des PPTP-Protokolls, einschließlich Steuerverbindungszustände, Anrufzustände und Verarbeitungsabläufe für verschiedene Betriebsszenarien.
3.1. Steuerverbindungszustände (Control Connection States)
Die Steuerverbindung ist eine TCP-Verbindung, die zwischen PAC und PNS eingerichtet wird, um PPTP-Steuernachrichten auszutauschen. Die Einrichtung der Steuerverbindung kann entweder vom PAC oder vom PNS initiiert werden.
Grundlegende Zustandsübergänge
Die Steuerverbindung durchläuft die folgenden Grundzustände:
- Idle (Leerlauf) - Keine Steuerverbindung existiert
- Wait-Connect (Warte auf Verbindung) - Verbindungsanforderung gesendet, wartet auf Antwort
- Established (Hergestellt) - Steuerverbindung erfolgreich hergestellt
- Wait-Disconnect (Warte auf Trennung) - Trennungsanforderung gesendet, wartet auf Bestätigung
3.1.1. Steuerverbindungs-Initiator (Control Connection Originator)
Der Initiator der Steuerverbindung (PAC oder PNS) führt folgende Operationen aus:
Zustand: Idle (Leerlauf)
- Aktion: TCP-Verbindung zum Partner herstellen
- Senden: Start-Control-Connection-Request
- Übergang zu: Wait-Reply-Zustand
Zustand: Wait-Reply (Warte auf Antwort)
- Empfangen: Start-Control-Connection-Reply (Result = Erfolg)
- Übergang zu: Established-Zustand
- Empfangen: Start-Control-Connection-Reply (Result = Fehler)
- TCP-Verbindung schließen
- Übergang zu: Idle-Zustand
- Timeout:
- TCP-Verbindung schließen
- Übergang zu: Idle-Zustand
Zustand: Established (Hergestellt)
- Kann alle PPTP-Steuernachrichten senden und empfangen
- Senden: Echo-Request (periodisches Keep-Alive)
- Empfangen: Echo-Reply (Antwort auf Keep-Alive)
- Senden: Stop-Control-Connection-Request (aktives Schließen)
- Übergang zu: Wait-Stop-Reply-Zustand
Zustand: Wait-Stop-Reply (Warte auf Stopp-Antwort)
- Empfangen: Stop-Control-Connection-Reply
- TCP-Verbindung schließen
- Übergang zu: Idle-Zustand
- Timeout:
- TCP-Verbindung schließen
- Übergang zu: Idle-Zustand
3.1.2. Steuerverbindungs-Empfänger (Control Connection Receiver)
Der Empfänger der Steuerverbindung (PAC oder PNS) führt folgende Operationen aus:
Zustand: Idle (Leerlauf)
- Lauschen: TCP-Port 1723
- Empfangen: TCP-Verbindungsanforderung
- TCP-Verbindung akzeptieren
- Übergang zu: Wait-Request-Zustand
Zustand: Wait-Request (Warte auf Anforderung)
- Empfangen: Start-Control-Connection-Request
- Validieren: Protokollversion, Parameter
- Falls akzeptiert:
- Senden: Start-Control-Connection-Reply (Result = Erfolg)
- Übergang zu: Established-Zustand
- Falls abgelehnt:
- Senden: Start-Control-Connection-Reply (Result = Fehler)
- TCP-Verbindung schließen
- Übergang zu: Idle-Zustand
Zustand: Established (Hergestellt)
- Kann alle PPTP-Steuernachrichten senden und empfangen
- Empfangen: Echo-Request
- Senden: Echo-Reply
- Empfangen: Stop-Control-Connection-Request
- Senden: Stop-Control-Connection-Reply
- TCP-Verbindung schließen
- Übergang zu: Idle-Zustand
3.1.3. Start Control Connection Initialisierungsanforderungskollision (Initiation Request Collision)
Wenn PAC und PNS gleichzeitig versuchen, eine Steuerverbindung herzustellen, kann eine Kollision auftreten. Die Behandlung ist wie folgt:
- Kollisionserkennung: Wenn eine Seite im Wait-Reply-Zustand einen Start-Control-Connection-Request empfängt
- Kollisionsauflösung:
- IP-Adressen vergleichen (numerischer Wert)
- Seite mit kleinerer IP-Adresse: Eigene initiierte Verbindung schließen, Verbindung des Partners akzeptieren
- Seite mit größerer IP-Adresse: Eigene initiierte Verbindung fortsetzen, Verbindung des Partners ablehnen
- Endergebnis: Nur eine Steuerverbindung wird hergestellt
3.1.4. Keep-Alives und Timer (Keep Alives and Timers)
Um den aktiven Zustand der Steuerverbindung aufrechtzuerhalten, werden folgende Mechanismen implementiert:
Echo-Request/Reply-Mechanismus
- Sendefrequenz: Es wird empfohlen, alle 60 Sekunden einen Echo-Request zu senden
- Timeout-Behandlung: Wenn innerhalb von 60 Sekunden keine Echo-Reply empfangen wird, gilt die Verbindung als fehlgeschlagen
- Wiederholungsstrategie: Kann bis zu 3 Mal wiederholt werden, mit 60 Sekunden Abstand zwischen jedem Versuch
- Verbindungsfehler: Nach mehreren aufeinanderfolgenden Timeouts die Steuerverbindung schließen
TCP Keep-Alive
- Der Keep-Alive-Mechanismus der TCP-Schicht kann als Ergänzung verwendet werden
- Der Echo-Mechanismus der PPTP-Schicht ist erforderlich (MUST)
Timer-Parameter
- Timeout für Steuerverbindungsaufbau: 60 Sekunden
- Keep-Alive-Intervall: 60 Sekunden
- Echo-Reply-Timeout: 60 Sekunden
- Timeout für Steuerverbindungsschließung: 60 Sekunden
Diese Timer-Werte sind Empfehlungen. Implementierungen können sie bei Bedarf anpassen, sollten aber sicherstellen, dass:
- Das Keep-Alive-Intervall kurz genug ist, um Verbindungsfehler rechtzeitig zu erkennen
- Die Timeout-Werte lang genug sind, um Fehlalarme aufgrund von Netzwerkverzögerungen zu vermeiden
3.2. Anrufzustände (Call States)
3.2.1. Zeitliche Überlegungen (Timing Considerations)
Aufgrund der Echtzeitnatur der Telefonsignalisierung sollten sowohl PNS als auch PAC mit Multithread-Architekturen implementiert werden, sodass Nachrichten, die sich auf mehrere Anrufe beziehen, nicht serialisiert und blockiert werden. Die Übertragungsverzögerung zwischen PAC und PNS sollte 1 Sekunde nicht überschreiten (SHOULD NOT). Die Anruf- und Verbindungsstatusdiagramme spezifizieren keine Ausnahmen, die durch Timer verursacht werden. Die implizite Annahme ist, dass da die TCP-basierte Steuerverbindung mit Keep-Alive-Nachrichten überprüft wird, weniger Notwendigkeit besteht, strikte Timer für Anrufsteuerungsnachrichten beizubehalten.
Die Herstellung internationaler ausgehender Anrufe, einschließlich der Modem-Training- und Verhandlungssequenzen, kann mehr als 1 Minute dauern, daher wird die Verwendung kurzer Timer nicht empfohlen.
Wenn ein Zustandsübergang nicht innerhalb von 1 Minute erfolgt (außer bei Verbindungen im Leerlauf- oder hergestellten Zustand), ist die Integrität der Protokollverarbeitung zwischen den Partnern verdächtig und die GESAMTE STEUERVERBINDUNG (ENTIRE CONTROL CONNECTION) sollte geschlossen und neu gestartet werden. Alle Anruf-IDs werden logisch freigegeben, wenn eine Steuerverbindung gestartet wird. Dies hilft vermutlich auch dabei, zu verhindern, dass gebührenpflichtige Anrufe "verloren" gehen und niemals gelöscht werden.
3.2.2. Anruf-ID-Werte (Call ID Values)
Jeder Partner weist jeder Benutzersitzung, die er anfordert oder akzeptiert, einen Anruf-ID-Wert zu. Dieser Anruf-ID-Wert muss (MUST) für den Tunnel zwischen dem PNS und dem PAC, zu dem er gehört, eindeutig sein. Tunnel zu anderen Partnern können dieselbe Anruf-ID-Nummer verwenden, sodass der Empfänger eines Pakets auf einem Tunnel eine Benutzersitzung einem bestimmten Tunnel und einer Anruf-ID zuordnen muss. Es wird empfohlen, dass die Anzahl der potenziellen Anruf-ID-Werte für jeden Tunnel mindestens doppelt so groß ist wie die maximale Anzahl der erwarteten Anrufe auf einem bestimmten Tunnel.
Eine Sitzung wird durch das Tripel (PAC, PNS, Call ID) definiert.
3.2.3. Eingehende Anrufe (Incoming Calls)
Eine Incoming-Call-Request-Nachricht wird vom PAC generiert, wenn eine zugehörige Telefonleitung klingelt. Der PAC wählt eine Anruf-ID und eine Seriennummer aus und gibt den Anrufträgertyp an. Modems sollten immer den analogen Anruftyp angeben (SHOULD). ISDN-Anrufe sollten digital angeben, wenn uneingeschränkter digitaler Dienst oder Ratenadaption verwendet wird, und analog, wenn digitale Modems beteiligt sind (SHOULD). Wählnummer, gewählte Nummer und Subadresse können in der Nachricht enthalten sein, falls sie vom Telefonnetz verfügbar sind.
Sobald der PAC die Incoming-Call-Request sendet, wartet er auf eine Antwort vom PNS, beantwortet aber den Anruf vom Telefonnetz nicht. Der PNS kann sich entscheiden, den Anruf nicht anzunehmen, wenn:
- Keine Ressourcen verfügbar sind, um mehr Sitzungen zu verarbeiten
- Die Felder für gewählte, wählende oder Subadresse keinen autorisierten Benutzer anzeigen
- Der Trägerdienst nicht autorisiert oder nicht unterstützt wird
Wenn der PNS sich entscheidet, den Anruf anzunehmen, antwortet er mit einer Incoming-Call-Reply, die auch Fenstergrößen angibt (siehe Abschnitt 4.2). Wenn der PAC die Outgoing-Call-Reply empfängt, versucht er, den Anruf zu verbinden, vorausgesetzt, die anrufende Partei hat nicht aufgelegt. Eine finale Anrufverbindungsnachricht vom PAC zum PNS zeigt an, dass die Anrufzustände sowohl für den PAC als auch für den PNS in den hergestellten Zustand eintreten sollten.
Wenn der einwählende Client auflegt, wird der Anruf normal gelöscht und der PAC sendet eine Call-Disconnect-Notify-Nachricht. Wenn der PNS einen Anruf löschen möchte, sendet er eine Call-Clear-Request-Nachricht und wartet dann auf eine Call-Disconnect-Notify.
3.2.3.1. PAC-Eingangszustände (PAC Incoming Call States)
Die mit dem PAC für eingehende Anrufe verbundenen Zustände sind:
idle (Leerlauf)
- Der PAC erkennt einen eingehenden Anruf an einer seiner Telefonschnittstellen. Typischerweise bedeutet dies, dass eine analoge Leitung klingelt oder ein ISDN-TE eine eingehende Q.931-SETUP-Nachricht erkannt hat. Der PAC sendet eine Incoming-Call-Request-Nachricht und wechselt in den wait_reply-Zustand.
wait_reply (Warte auf Antwort)
- Der PAC empfängt eine Incoming-Call-Reply-Nachricht, die Unwilligkeit anzeigt, den Anruf anzunehmen (allgemeiner Fehler oder nicht annehmen), und kehrt in den Leerlaufzustand zurück. Wenn die Antwortnachricht anzeigt, dass der Anruf angenommen wird, sendet der PAC eine Incoming-Call-Connected-Nachricht und tritt in den hergestellten Zustand ein.
established (hergestellt)
- Daten werden über den Tunnel ausgetauscht. Der Anruf kann nach Folgendem gelöscht werden:
- Ein Ereignis auf der Telefonverbindung. Der PAC sendet eine Call-Disconnect-Notify-Nachricht
- Empfang eines Call-Clear-Request. Der PAC sendet eine Call-Disconnect-Notify-Nachricht
- Ein lokaler Grund. Der PAC sendet eine Call-Disconnect-Notify-Nachricht
3.2.3.2. PNS-Eingangszustände (PNS Incoming Call States)
Die mit dem PNS für eingehende Anrufe verbundenen Zustände sind:
idle (Leerlauf)
- Eine Incoming-Call-Request-Nachricht wird empfangen. Wenn die Anfrage nicht akzeptabel ist, wird eine Incoming-Call-Reply an den PAC zurückgesendet und der PNS bleibt im Leerlaufzustand. Wenn die Incoming-Call-Request-Nachricht akzeptabel ist, wird eine Incoming-Call-Reply gesendet, die im Ergebniscode Akzeptanz anzeigt. Die Sitzung wechselt in den wait_connect-Zustand.
wait_connect (Warte auf Verbindung)
- Wenn die Sitzung auf dem PAC verbunden ist, sendet der PAC eine Eingangsan rufverbindungsnachricht an den PNS, der dann in den hergestellten Zustand wechselt. Der PAC kann eine Call-Disconnect-Notify senden, um anzuzeigen, dass der eingehende Anrufer nicht verbunden werden konnte. Dies könnte beispielsweise geschehen, wenn ein Telefonbenutzer versehentlich einen standardmäßigen Sprachanruf an einen PAC tätigt, was zu einem Handshake-Fehler am angerufenen Modem führt.
established (hergestellt)
- Die Sitzung wird entweder durch Empfang einer Call-Disconnect-Notify-Nachricht vom PAC oder durch Senden eines Call-Clear-Request beendet. Sobald ein Call-Clear-Request gesendet wurde, tritt die Sitzung in den wait_disconnect-Zustand ein.
wait_disconnect (Warte auf Trennung)
- Sobald eine Call-Disconnect-Notify empfangen wird, kehrt die Sitzung in den Leerlaufzustand zurück.
3.2.4. Ausgehende Anrufe (Outgoing Calls)
Ausgehende Nachrichten werden von einem PNS initiiert und weisen einen PAC an, einen Anruf auf einer Telekommunikationsschnittstelle zu tätigen. Es gibt nur zwei Nachrichten für ausgehende Anrufe: Outgoing-Call-Request und Outgoing-Call-Reply. Der PNS sendet eine Outgoing-Call-Request, die die Telefonnummer der gewählten Partei und die Subadresse sowie Geschwindigkeits- und Fensterparameter angibt. Der PAC muss (MUST) auf die Outgoing-Call-Request-Nachricht mit einer Outgoing-Call-Reply-Nachricht antworten, sobald der PAC feststellt, dass:
- Der Anruf erfolgreich verbunden wurde
- Ein Anruffehler aus Gründen wie den folgenden aufgetreten ist: Keine Schnittstellen sind für Auswahlverbindung verfügbar, die angerufene Partei ist besetzt oder antwortet nicht, oder kein Wählton wird an der für das Wählen gewählten Schnittstelle erkannt
3.2.4.1. PAC-Ausgangszustände (PAC Outgoing Call States)
Die mit dem PAC für ausgehende Anrufe verbundenen Zustände sind:
idle (Leerlauf)
- Outgoing-Call-Request empfangen. Wenn dies fehlerhaft empfangen wird, mit einer Outgoing-Call-Reply mit gesetzter Fehlerbedingung antworten. Andernfalls physischen Kanal zum Wählen zuweisen. Ausgehenden Anruf tätigen, auf Verbindung warten und in den wait_cs_ans-Zustand wechseln.
wait_cs_ans (Warte auf Leitungsvermittlungsantwort)
- Wenn der Anruf unvollständig ist, eine Outgoing-Call-Reply mit einem von Null verschiedenen Fehlercode senden. Wenn ein Timer bei einem ausgehenden Anruf abläuft, eine Outgoing-Call-Reply mit einem von Null verschiedenen Fehlercode zurücksenden. Wenn eine Leitungsvermittlungsverbindung hergestellt ist, eine Outgoing-Call-Reply senden, die Erfolg anzeigt.
established (hergestellt)
- Wenn ein Call-Clear-Request empfangen wird, sollte der Telefonanruf über geeignete Mechanismen freigegeben werden (SHOULD) und eine Call-Disconnect-Notify-Nachricht sollte an den PNS gesendet werden (SHOULD). Wenn der Anruf vom Client oder von der Telefonschnittstelle getrennt wird, sollte eine Call-Disconnect-Notify-Nachricht an den PNS gesendet werden (SHOULD).
3.2.4.2. PNS-Ausgangszustände (PNS Outgoing Call States)
Die mit dem PNS für ausgehende Anrufe verbundenen Zustände sind:
idle (Leerlauf)
- Die Öffnungsanzeige der oberen Schichtanwendung führt dazu, dass eine Outgoing-Call-Request gesendet wird und in den wait_reply-Zustand gewechselt wird.
wait_reply (Warte auf Antwort)
- Wenn eine Outgoing-Call-Reply mit Fehler empfangen wird, zurück in den Leerlaufzustand wechseln. Wenn eine erfolgreiche Outgoing-Call-Reply empfangen wird, in den hergestellten Zustand wechseln. Wenn ein Abbruch auftritt, während auf die Outgoing-Call-Reply gewartet wird, eine Call-Clear-Request senden und in den wait_disconnect-Zustand wechseln.
established (hergestellt)
- Wenn eine Call-Disconnect-Notify empfangen wird, in den Leerlaufzustand wechseln. Wenn eine lokale Beendigung auftritt, eine Call-Clear-Request senden und in den wait_disconnect-Zustand wechseln.
wait_disconnect (Warte auf Trennung)
- Wenn eine Call-Disconnect-Notify empfangen wird, in den Leerlaufzustand wechseln.