RFC 2637 - Point-to-Point Tunneling Protocol (PPTP)
- Status: Informational
- Veröffentlicht: July 1999
- Stream: IETF
- Errata: Keine Errata
Zusammenfassung (Abstract)
Dieses Dokument spezifiziert ein Protokoll, das es dem Point-to-Point Protocol (PPP) ermöglicht, durch ein IP-Netzwerk getunnelt zu werden. PPTP spezifiziert keine Änderungen am PPP-Protokoll selbst, sondern beschreibt ein neues Transportmittel für PPP. Eine Client-Server-Architektur wird definiert, um Funktionen zu entkoppeln, die in aktuellen Network Access Servern (NAS) existieren, und um Virtual Private Networks (VPNs) zu unterstützen. Der PPTP Network Server (PNS) ist für den Betrieb auf einem Allzweck-Betriebssystem vorgesehen, während der Client, als PPTP Access Concentrator (PAC) bezeichnet, auf einer Einwahlzugangsplattform läuft. PPTP spezifiziert ein Anrufsteuerungs- und Verwaltungsprotokoll, das es dem Server ermöglicht, den Zugriff für eingehende leitungsvermittelte Anrufe von PSTN oder ISDN zu steuern oder ausgehende leitungsvermittelte Verbindungen zu initiieren. PPTP verwendet einen erweiterten GRE-Mechanismus (Generic Routing Encapsulation), um einen fluss- und staukontrollierten gekapselten Datagrammdienst zum Transport von PPP-Paketen bereitzustellen.
Inhaltsverzeichnis (Contents)
- 1. Introduction (Einführung)
- 1.1 Protocol Goals and Assumptions (Protokollziele und Annahmen)
- 1.2 Terminology (Terminologie)
- 1.3 Protocol Overview (Protokollübersicht)
- 1.4 Message Format and Protocol Extensibility (Nachrichtenformat und Protokollerweiterbarkeit)
- 2. Control Connection Protocol Specification (Spezifikation des Steuerverbindungsprotokolls)
- 2.1-2.16 Nachrichtentypendefinitionen
- 3. Control Connection Protocol Operation (Steuerverbindungsprotokollbetrieb)
- 3.1 Control Connection States (Steuerverbindungszustände)
- 3.2 Call States (Anrufzustände)
- 4. Tunnel Protocol Operation (Tunnelprotokollbetrieb)
- 4.1 Enhanced GRE Header (Erweiterter GRE-Header)
- 4.2 Sliding Window Protocol (Sliding-Window-Protokoll)
- 4.3 Out-of-sequence Packets (Pakete außerhalb der Reihenfolge)
- 4.4 Acknowledgment Time-Outs (Bestätigungszeitüberschreitungen)
- 5. Security Considerations (Sicherheitsüberlegungen)
- 6. Authors' Addresses (Autorenadressen)
- 7. References (Referenzen)
- 8. Full Copyright Statement (Vollständige Urheberrechtserklärung)
Verwandte Ressourcen
- Offizieller Originaltext: RFC 2637
- Offizielle Seite: RFC 2637 DataTracker
- Errata: RFC Editor Errata
1. Einführung (Introduction)
PPTP ermöglicht es, bestehende Funktionen eines Network Access Servers (NAS) mithilfe einer Client-Server-Architektur zu trennen. Traditionell werden die folgenden Funktionen von einem NAS implementiert:
-
Physische native Schnittstelle zu PSTN oder ISDN und Steuerung externer Modems oder Terminaladapter
Ein NAS kann direkt an einen analogen oder digitalen Telekommunikationskreis angeschlossen werden oder über ein externes Modem oder einen Terminaladapter verbunden sein. Die Steuerung einer leitungsvermittelten Verbindung erfolgt entweder durch Modemsteuerung oder DSS1-ISDN-Anrufsteuerungsprotokolle.
Der NAS kann in Verbindung mit dem Modem oder den Terminaladaptern Ratenanpassung, Analog-Digital-Wandlung, Synchron-Asynchron-Wandlung oder eine Reihe anderer Änderungen an Datenströmen durchführen.
-
Logische Terminierung einer Point-to-Point Protocol (PPP) Link Control Protocol (LCP) Sitzung
-
Teilnahme an PPP-Authentifizierungsprotokollen [3,9,10]
-
Kanalaggregation und Bundle-Verwaltung für das PPP Multilink Protocol
-
Logische Terminierung verschiedener PPP Network Control Protocols (NCP)
-
Multiprotokoll-Routing und Bridging zwischen NAS-Schnittstellen
PPTP teilt diese Funktionen zwischen PAC und PNS auf. Der PAC ist für die Funktionen 1, 2 und möglicherweise 3 verantwortlich. Der PNS kann für Funktion 3 verantwortlich sein und ist für die Funktionen 4, 5 und 6 verantwortlich. Das Protokoll, das zum Transport von PPP-Protokolldateneinheiten (Protocol Data Units, PDUs) zwischen PAC und PNS sowie zur Anrufsteuerung und -verwaltung verwendet wird, wird durch PPTP adressiert.
Die Entkopplung der NAS-Funktionen bietet folgende Vorteile:
Flexible IP-Adressverwaltung. Einwahlbenutzer können eine einzige IP-Adresse beibehalten, wenn sie sich bei verschiedenen PACs einwählen, solange sie von einem gemeinsamen PNS bedient werden. Wenn ein Unternehmensnetzwerk nicht registrierte Adressen verwendet, weist ein mit dem Unternehmen verbundener PNS für das private Netzwerk sinnvolle Adressen zu.
Unterstützung von Nicht-IP-Protokollen für Einwahlnetzwerke hinter IP-Netzwerken. Dies ermöglicht es beispielsweise, AppleTalk und IPX durch einen reinen IP-Anbieter zu tunneln. Der PAC muss diese Protokolle nicht verarbeiten können.
Eine Lösung für das "Multilink-Hunt-Group-Splitting"-Problem. Multilink PPP, das typischerweise zur Aggregation von ISDN-B-Kanälen verwendet wird, erfordert, dass alle Kanäle, die ein Multilink-Bundle bilden, auf einem einzigen NAS gruppiert werden. Da ein Multilink-PPP-Bundle von einem einzigen PNS verarbeitet werden kann, können die das Bundle bildenden Kanäle über mehrere PACs verteilt werden.
1.1. Protokollziele und Annahmen (Protocol Goals and Assumptions)
Das PPTP-Protokoll wird nur vom PAC und PNS implementiert. Keine anderen Systeme müssen PPTP kennen. Einwahlnetzwerke können mit einem PAC verbunden werden, ohne PPTP zu kennen. Standard-PPP-Client-Software sollte (SHOULD) weiterhin auf getunnelten PPP-Verbindungen funktionieren.
PPTP kann auch verwendet werden, um eine PPP-Sitzung über ein IP-Netzwerk zu tunneln. In dieser Konfiguration laufen der PPTP-Tunnel und die PPP-Sitzung zwischen denselben beiden Maschinen, wobei der Anrufer als PNS fungiert.
Es wird erwartet, dass es eine Viele-zu-Viele-Beziehung zwischen PACs und PNSs geben wird. Ein PAC kann mehreren PNSs Dienste bereitstellen. Beispielsweise kann ein Internetdienstanbieter wählen, PPTP für mehrere private Netzwerkkunden zu unterstützen und VPNs für sie zu erstellen. Jedes private Netzwerk kann einen oder mehrere PNSs betreiben. Ein einzelner PNS kann mit vielen PACs verbunden sein, um Datenverkehr von einer großen Anzahl geografisch verteilter Standorte zu konzentrieren.
PPTP verwendet eine erweiterte Version von GRE, um Benutzer-PPP-Pakete zu transportieren. Diese Verbesserungen ermöglichen die Bereitstellung einer Low-Level-Stau- und Flusssteuerung für die Tunnel, die zum Transport von Benutzerdaten zwischen PAC und PNS verwendet werden. Dieser Mechanismus ermöglicht eine effiziente Nutzung der für die Tunnel verfügbaren Bandbreite und vermeidet unnötige Wiederholungen und Pufferüberläufe. PPTP schreibt keine bestimmten Algorithmen für diese Low-Level-Steuerung vor, definiert jedoch die Parameter, die kommuniziert werden müssen, damit diese Algorithmen funktionieren können. Vorgeschlagene Algorithmen sind in Abschnitt 4 enthalten.
1.2. Terminologie (Terminology)
Analoger Kanal (Analog Channel)
Ein leitungsvermittelter Kommunikationspfad, der für die Übertragung von 3,1 kHz Audio in jede Richtung vorgesehen ist.
Digitaler Kanal (Digital Channel)
Ein leitungsvermittelter Kommunikationspfad, der für die Übertragung digitaler Informationen in jede Richtung vorgesehen ist.
Anruf (Call)
Eine Verbindung oder ein Verbindungsversuch zwischen zwei Endpunkten in einem PSTN oder ISDN, beispielsweise ein Telefonanruf zwischen zwei Modems.
Steuerverbindung (Control Connection)
Für jedes PAC-PNS-Paar wird eine Steuerverbindung erstellt, die über TCP läuft. Die Steuerverbindung regelt Aspekte des Tunnels und der dem Tunnel zugewiesenen Sitzungen.
Einwahlbenutzer (Dial User)
Ein Endsystem oder Router, das an ein bedarfsgesteuertes PSTN oder ISDN angeschlossen ist und entweder Initiator oder Empfänger eines Anrufs ist.
Network Access Server (NAS)
Ein Gerät, das Benutzern temporären, bedarfsgesteuerten Netzwerkzugang bietet. Dieser Zugang erfolgt punkt-zu-punkt über PSTN- oder ISDN-Leitungen.
PPTP Access Concentrator (PAC)
Ein Gerät, das an eine oder mehrere PSTN- oder ISDN-Leitungen angeschlossen ist, PPP-Operationen durchführen kann und das PPTP-Protokoll verarbeitet. Der PAC muss nur TCP/IP implementieren, um Datenverkehr an einen oder mehrere PNS weiterzuleiten. Er kann auch Nicht-IP-Protokolle tunneln.
PPTP Network Server (PNS)
Ein PNS ist für den Betrieb auf universellen Computing/Server-Plattformen vorgesehen. Der PNS behandelt die Serverseite des PPTP-Protokolls. Da PPTP vollständig auf TCP/IP basiert und unabhängig von der Schnittstellenhardware ist, kann der PNS jede Kombination von IP-Schnittstellenhardware verwenden, einschließlich LAN- und WAN-Geräten.
Sitzung (Session)
PPTP ist verbindungsorientiert. Der PNS und der PAC pflegen den Zustand für jeden Benutzer, der an einen PAC angeschlossen ist. Eine Sitzung wird erstellt, wenn eine Ende-zu-Ende-PPP-Verbindung zwischen einem Einwahlbenutzer und dem PNS versucht wird. Die zu einer Sitzung gehörenden Datagramme werden über den Tunnel zwischen PAC und PNS gesendet.
Tunnel
Ein Tunnel wird durch ein PNS-PAC-Paar definiert. Das Tunnelprotokoll wird durch eine modifizierte Version von GRE definiert. Der Tunnel überträgt PPP-Datagramme zwischen dem PAC und dem PNS. Mehrere Sitzungen werden auf einem einzigen Tunnel gemultiplext. Eine über TCP laufende Steuerverbindung steuert die Einrichtung, Freigabe und Wartung von Sitzungen und des Tunnels selbst.
1.3. Protokollübersicht (Protocol Overview)
PPTP besteht aus zwei parallelen Komponenten: 1) einer Steuerverbindung zwischen jedem PAC-PNS-Paar, die über TCP läuft, und 2) einem IP-Tunnel, der zwischen demselben PAC-PNS-Paar läuft und zum Transport von GRE-gekapselten PPP-Paketen für Benutzersitzungen zwischen dem Paar verwendet wird.
1.3.1. Übersicht über die Steuerverbindung (Control Connection Overview)
Bevor PPP-Tunneling zwischen einem PAC und PNS stattfinden kann, muss eine Steuerverbindung zwischen ihnen eingerichtet werden. Die Steuerverbindung ist eine Standard-TCP-Sitzung, über die PPTP-Anrufsteuerungs- und Verwaltungsinformationen übertragen werden. Die Steuerungssitzung ist logisch mit den Sitzungen verbunden, die durch einen PPTP-Tunnel getunnelt werden, aber davon getrennt. Für jedes PAC-PNS-Paar existieren sowohl ein Tunnel als auch eine Steuerverbindung. Die Steuerverbindung ist verantwortlich für die Einrichtung, Verwaltung und Freigabe von Sitzungen, die durch den Tunnel transportiert werden. Sie ist das Mittel, durch das ein PNS über einen eingehenden Anruf an einem zugehörigen PAC benachrichtigt wird, sowie das Mittel, durch das ein PAC angewiesen wird, einen ausgehenden Wählanruf zu tätigen.
Eine Steuerverbindung kann entweder vom PNS oder vom PAC eingerichtet werden. Nach der Einrichtung der erforderlichen TCP-Verbindung richten PNS und PAC die Steuerverbindung unter Verwendung der Start-Control-Connection-Request- und -Reply-Nachrichten ein. Diese Nachrichten werden auch verwendet, um Informationen über grundlegende Betriebsfähigkeiten des PAC und PNS auszutauschen. Sobald die Steuerverbindung eingerichtet ist, kann der PAC oder PNS Sitzungen initiieren, indem er ausgehende Anrufe anfordert oder auf eingehende Anfragen antwortet. Die Steuerverbindung kann Änderungen in den Betriebsmerkmalen einer einzelnen Benutzersitzung mit einer Set-Link-Info-Nachricht kommunizieren. Einzelne Sitzungen können entweder vom PAC oder PNS, ebenfalls über Steuerverbindungsnachrichten, freigegeben werden.
Die Steuerverbindung selbst wird durch Keep-Alive-Echo-Nachrichten aufrechterhalten. Dies stellt sicher, dass ein Konnektivitätsfehler zwischen dem PNS und dem PAC rechtzeitig erkannt werden kann. Andere Fehler können über die Wan-Error-Notify-Nachricht, ebenfalls auf der Steuerverbindung, gemeldet werden.
Es ist beabsichtigt, dass die Steuerverbindung in Zukunft auch verwaltungsbezogene Nachrichten trägt, wie z. B. eine Nachricht, die es dem PNS ermöglicht, den Status eines bestimmten PAC anzufordern; diese Nachrichtentypen wurden noch nicht definiert.
1.3.2. Übersicht über das Tunnelprotokoll (Tunnel Protocol Overview)
PPTP erfordert die Einrichtung eines Tunnels für jedes kommunizierende PNS-PAC-Paar. Dieser Tunnel wird verwendet, um alle Benutzersitzungs-PPP-Pakete für Sitzungen mit einem bestimmten PNS-PAC-Paar zu transportieren. Ein Schlüssel, der im GRE-Header vorhanden ist, gibt an, zu welcher Sitzung ein bestimmtes PPP-Paket gehört.
Auf diese Weise werden PPP-Pakete über einen einzigen Tunnel zwischen einem gegebenen PNS-PAC-Paar gemultiplext und demultiplext. Der im Schlüsselfeld zu verwendende Wert wird durch das Anrufeinrichtungsverfahren festgelegt, das auf der Steuerverbindung stattfindet.
Der GRE-Header enthält auch Bestätigungs- und Sequenzierungsinformationen, die verwendet werden, um ein gewisses Maß an Staukontrolle und Fehlererkennung über den Tunnel durchzuführen. Wiederum wird die Steuerverbindung verwendet, um Raten- und Pufferparameter zu bestimmen, die zur Regulierung des Flusses von PPP-Paketen für eine bestimmte Sitzung über den Tunnel verwendet werden. PPTP spezifiziert nicht die bestimmten Algorithmen, die für Staukontrolle und Flusskontrolle zu verwenden sind. Vorgeschlagene Algorithmen zur Bestimmung adaptiver Zeitüberschreitungen zur Wiederherstellung von verlorenen Daten oder Bestätigungen auf dem Tunnel sind in Abschnitt 4.4 dieses Dokuments enthalten.
1.4. Nachrichtenformat und Protokollerweiterbarkeit (Message Format and Protocol Extensibility)
PPTP definiert einen Satz von Nachrichten, die als TCP-Daten auf der Steuerverbindung zwischen einem PNS und einem gegebenen PAC gesendet werden. Die TCP-Sitzung für die Steuerverbindung wird durch Initiierung einer TCP-Verbindung zu Port 1723 eingerichtet. Der Quellport wird einem beliebigen ungenutzten Portnummer zugewiesen.
Jede PPTP-Steuerverbindungsnachricht beginnt mit einem 8-Oktett-Fixheader-Teil. Dieser Fixheader enthält folgendes: die Gesamtlänge der Nachricht, den PPTP-Nachrichtentypindikator und ein „Magic Cookie".
Zwei Steuerverbindungs-Nachrichtentypen werden durch das PPTP-Nachrichtentypfeld angegeben:
- 1 - Steuernachricht (Control Message)
- 2 - Verwaltungsnachricht (Management Message)
Verwaltungsnachrichten sind derzeit nicht definiert.
Das Magic Cookie wird immer als Konstante 0x1A2B3C4D gesendet. Sein grundlegender Zweck besteht darin, dem Empfänger zu ermöglichen, sicherzustellen, dass er ordnungsgemäß mit dem TCP-Datenstrom synchronisiert ist. Es sollte nicht (SHOULD NOT) als Mittel zur Resynchronisierung des TCP-Datenstroms verwendet werden, wenn ein Sender eine falsch formatierte Nachricht ausgibt. Der Verlust der Synchronisation muss (MUST) zur sofortigen Schließung der TCP-Sitzung der Steuerverbindung führen.
Zur Klarstellung enthalten alle Steuerverbindungs-Nachrichtenvorlagen im nächsten Abschnitt den vollständigen PPTP-Steuerverbindungs-Nachrichtenheader. Zahlen mit vorangestelltem 0x sind Hexadezimalwerte.
Die derzeit definierten Steuernachrichten, nach Funktion gruppiert, sind:
Steuerverbindungsverwaltung (Control Connection Management)
- Start-Control-Connection-Request (1)
- Start-Control-Connection-Reply (2)
- Stop-Control-Connection-Request (3)
- Stop-Control-Connection-Reply (4)
- Echo-Request (5)
- Echo-Reply (6)
Anrufverwaltung (Call Management)
- Outgoing-Call-Request (7)
- Outgoing-Call-Reply (8)
- Incoming-Call-Request (9)
- Incoming-Call-Reply (10)
- Incoming-Call-Connected (11)
- Call-Clear-Request (12)
- Call-Disconnect-Notify (13)
Fehlerberichterstattung (Error Reporting)
- WAN-Error-Notify (14)
PPP-Sitzungssteuerung (PPP Session Control)
- Set-Link-Info (15)
Die Start-Control-Connection-Request- und -Reply-Nachrichten bestimmen, welche Version des Steuerverbindungsprotokolls verwendet wird. Das in diesen Nachrichten übertragene Versionsnummernfeld besteht aus einer Versionsnummer im höherwertigen Oktett und einer Revisionsnummer im niederwertigen Oktett. Die Versionsbehandlung wird in Abschnitt 2 beschrieben. Der aktuelle Wert des Versionsnummernfeldes ist 0x0100 für Version 1, Revision 0.
Die Verwendung des GRE-ähnlichen Headers für die Kapselung von PPP-Benutzerpaketen ist in Abschnitt 4.1 spezifiziert.
Die MTU für die in GRE gekapselten Benutzerdatenpakete beträgt 1532 Oktetts, ohne die IP- und GRE-Header.
2. Spezifikation des Steuerverbindungsprotokolls (Control Connection Protocol Specification)
Steuerverbindungsnachrichten werden verwendet, um Benutzersitzungen einzurichten und zu beenden. Der erste Satz von Steuerverbindungsnachrichten wird verwendet, um die Steuerverbindung selbst aufrechtzuerhalten. Die Steuerverbindung wird entweder vom PNS oder vom PAC initiiert, nachdem sie die zugrunde liegende TCP-Verbindung hergestellt haben. Die Prozedur und die Konfigurationsinformationen, die erforderlich sind, um zu bestimmen, welche TCP-Verbindungen hergestellt werden, werden von diesem Protokoll nicht abgedeckt.
Die folgenden Steuerverbindungsnachrichten werden alle als Benutzerdaten auf der hergestellten TCP-Verbindung zwischen einem gegebenen PNS-PAC-Paar gesendet. Beachten Sie, dass darauf geachtet wurde, dass alle Wort- (2 Oktett) und Langwort- (4 Oktett) Werte an entsprechenden Grenzen beginnen. Alle Daten werden in Netzwerkreihenfolge (höherwertige Oktette zuerst) gesendet. Alle „reservierten" Felder müssen (MUST) als 0-Werte gesendet werden, um Protokollerweiterbarkeit zu ermöglichen.
2.1. Start-Control-Connection-Request (Anforderung zum Start der Steuerverbindung)
Die Start-Control-Connection-Request ist eine PPTP-Steuernachricht, die verwendet wird, um die Steuerverbindung zwischen einem PNS und einem PAC herzustellen. Jedes PNS-PAC-Paar erfordert, dass eine dedizierte Steuerverbindung hergestellt wird. Eine Steuerverbindung muss (MUST) hergestellt werden, bevor andere PPTP-Nachrichten ausgegeben werden können. Die Einrichtung der Steuerverbindung kann entweder vom PNS oder vom PAC initiiert werden. Eine Prozedur, die das Auftreten einer Kollision zwischen PNS- und PAC-Start-Control-Connection-Requests behandelt, wird in Abschnitt 3.1.3 beschrieben.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Channels | Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Name (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Vendor String (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibungen
Length (Länge)
Gesamtlänge in Oktetten dieser PPTP-Nachricht, einschließlich des gesamten PPTP-Headers.
PPTP Message Type (PPTP-Nachrichtentyp)
1 für Steuernachricht.
Magic Cookie
0x1A2B3C4D. Dieser konstante Wert wird als Plausibilitätsprüfung für empfangene Nachrichten verwendet (siehe Abschnitt 1.4).
Control Message Type (Steuernachrichtentyp)
1 für Start-Control-Connection-Request.
Reserved0 (Reserviert 0)
Dieses Feld muss (MUST) 0 sein.
Protocol Version (Protokollversion)
Die Version des PPTP-Protokolls, die der Sender verwenden möchte.
Reserved1 (Reserviert 1)
Dieses Feld muss (MUST) 0 sein.
Framing Capabilities (Framing-Fähigkeiten)
Ein Satz von Bits, der den Typ des Framings angibt, den der Sender dieser Nachricht bereitstellen kann. Die derzeit definierten Bit-Einstellungen sind:
- 1 - Asynchrones Framing unterstützt (Asynchronous Framing supported)
- 2 - Synchrones Framing unterstützt (Synchronous Framing supported)
Bearer Capabilities (Träger-Fähigkeiten)
Ein Satz von Bits, der die Trägerfähigkeiten angibt, die der Sender dieser Nachricht bereitstellen kann. Die derzeit definierten Bit-Einstellungen sind:
- 1 - Analoger Zugang unterstützt (Analog access supported)
- 2 - Digitaler Zugang unterstützt (Digital access supported)
Maximum Channels (Maximale Kanäle)
Die Gesamtzahl der einzelnen PPP-Sitzungen, die dieser PAC unterstützen kann. In Start-Control-Connection-Requests, die vom PNS ausgegeben werden, sollte (SHOULD) dieser Wert auf 0 gesetzt werden. Er muss (MUST) vom PAC ignoriert werden.
Firmware Revision (Firmware-Revision)
Wenn es vom PAC ausgegeben wird, enthält dieses Feld die Firmware-Revisionsnummer des ausstellenden PAC. Wenn es vom PNS ausgegeben wird, enthält es die Version des PNS-PPTP-Treibers.
Host Name (Hostname)
Ein 64-Oktett-Feld, das den DNS-Namen des ausstellenden PAC oder PNS enthält. Wenn die Länge weniger als 64 Oktette beträgt, sollte (SHOULD) der Rest dieses Feldes mit Oktetten des Wertes 0 gefüllt werden.
Vendor Name (Herstellername)
Ein 64-Oktett-Feld, das eine herstellerspezifische Zeichenfolge enthält, die den verwendeten PAC-Typ beschreibt, oder den verwendeten PNS-Softwaretyp, wenn diese Anforderung vom PNS ausgegeben wird. Wenn die Länge weniger als 64 Oktette beträgt, sollte (SHOULD) der Rest dieses Feldes mit Oktetten des Wertes 0 gefüllt werden.
2.2. Start-Control-Connection-Reply (Antwort auf Start der Steuerverbindung)
Die Start-Control-Connection-Reply ist eine PPTP-Steuernachricht, die als Antwort auf eine empfangene Start-Control-Connection-Request-Nachricht gesendet wird. Diese Nachricht enthält einen Ergebniscode, der das Ergebnis des Steuerverbindungsaufbauversuchs angibt.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Channels | Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Host Name (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Vendor String (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibungen
Length (Länge)
Gesamtlänge in Oktetten dieser PPTP-Nachricht, einschließlich des gesamten PPTP-Headers.
PPTP Message Type (PPTP-Nachrichtentyp)
1 für Steuernachricht.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Steuernachrichtentyp)
2 für Start-Control-Connection-Reply.
Reserved0 (Reserviert 0)
Dieses Feld muss (MUST) 0 sein.
Protocol Version (Protokollversion)
Die Version des PPTP-Protokolls, die der Sender verwenden möchte.
Result Code (Ergebniscode)
Gibt das Ergebnis des Befehlskanalaufbauversuchs an. Derzeit gültige Ergebniscodewerte sind:
- 1 - Erfolgreicher Kanalaufbau
- 2 - Allgemeiner Fehler -- Fehlercode gibt das Problem an
- 3 - Befehlskanal existiert bereits
- 4 - Anforderer ist nicht berechtigt, einen Befehlskanal einzurichten
- 5 - Die Protokollversion des Anforderers wird nicht unterstützt
Error Code (Fehlercode)
Dieses Feld ist auf 0 gesetzt, es sei denn, ein „Allgemeiner Fehler" liegt vor. In diesem Fall wird der Ergebniscode auf 2 gesetzt und dieses Feld wird auf den Wert gesetzt, der der allgemeinen Fehlerbedingung entspricht, wie in Abschnitt 2.2 angegeben.
Framing Capabilities (Framing-Fähigkeiten)
Ein Satz von Bits, der den Typ des Framings angibt, den der Sender dieser Nachricht bereitstellen kann. Die derzeit definierten Bit-Einstellungen sind:
- 1 - Asynchrones Framing unterstützt
- 2 - Synchrones Framing unterstützt
Bearer Capabilities (Träger-Fähigkeiten)
Ein Satz von Bits, der die Trägerfähigkeiten angibt, die der Sender dieser Nachricht bereitstellen kann. Die derzeit definierten Bit-Einstellungen sind:
- 1 - Analoger Zugang unterstützt
- 2 - Digitaler Zugang unterstützt
Maximum Channels (Maximale Kanäle)
Die Gesamtzahl der einzelnen PPP-Sitzungen, die dieser PAC unterstützen kann. In Start-Control-Connection-Replies, die vom PNS ausgegeben werden, sollte (SHOULD) dieser Wert auf 0 gesetzt werden und muss (MUST) vom PAC ignoriert werden. Der PNS darf (MUST NOT) diesen Wert nicht verwenden, um zu versuchen, die verbleibende Anzahl von PPP-Sitzungen zu verfolgen, die der PAC zulassen wird.
Firmware Revision (Firmware-Revision)
Dieses Feld enthält die Firmware-Revisionsnummer des ausstellenden PAC oder die Version des PNS-PPTP-Treibers, wenn es vom PNS ausgegeben wird.
Host Name (Hostname)
Ein 64-Oktett-Feld, das den DNS-Namen des ausstellenden PAC oder PNS enthält.
Vendor String (Herstellerzeichenfolge)
Ein 64-Oktett-Feld, das eine herstellerspezifische Zeichenfolge enthält.
2.3. Stop-Control-Connection-Request (Anforderung zum Stoppen der Steuerverbindung)
Die Stop-Control-Connection-Request ist eine PPTP-Steuernachricht, die von einem Partner einer PAC-PNS-Steuerverbindung gesendet wird, um den anderen Partner darüber zu informieren, dass die Steuerverbindung geschlossen werden sollte. Zusätzlich zum Schließen der Steuerverbindung werden alle aktiven Benutzeranrufe implizit gelöscht. Der Grund für die Ausgabe dieser Anforderung wird im Feld Reason angegeben.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Reserved1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibungen
Length (Länge)
Gesamtlänge in Oktetten dieser PPTP-Nachricht, einschließlich des gesamten PPTP-Headers.
PPTP Message Type (PPTP-Nachrichtentyp)
1 für Steuernachricht.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Steuernachrichtentyp)
3 für Stop-Control-Connection-Request.
Reserved0 (Reserviert 0)
Dieses Feld muss (MUST) 0 sein.
Reason (Grund)
Gibt den Grund für das Schließen der Steuerverbindung an. Derzeit gültige Grundwerte sind:
- 1 (None) - Allgemeine Anforderung zum Löschen der Steuerverbindung
- 2 (Stop-Protocol) - Kann die Protokollversion des Partners nicht unterstützen
- 3 (Stop-Local-Shutdown) - Anforderer wird heruntergefahren
Reserved1, Reserved2 (Reserviert 1, 2)
Diese Felder müssen (MUST) 0 sein.
2.4. Stop-Control-Connection-Reply (Antwort auf Stoppen der Steuerverbindung)
Die Stop-Control-Connection-Reply ist eine PPTP-Steuernachricht, die von einem Partner einer PAC-PNS-Steuerverbindung beim Empfang einer Stop-Control-Connection-Request vom anderen Partner gesendet wird.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibungen
Length (Länge)
Gesamtlänge in Oktetten dieser PPTP-Nachricht, einschließlich des gesamten PPTP-Headers.
PPTP Message Type (PPTP-Nachrichtentyp)
1 für Steuernachricht.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Steuernachrichtentyp)
4 für Stop-Control-Connection-Reply.
Reserved0 (Reserviert 0)
Dieses Feld muss (MUST) 0 sein.
Result Code (Ergebniscode)
Gibt das Ergebnis des Versuchs an, die Steuerverbindung zu schließen. Derzeit gültige Ergebniscodewerte sind:
- 1 (OK) - Steuerverbindung geschlossen
- 2 (General Error) - Steuerverbindung nicht geschlossen aus dem im Fehlercode angegebenen Grund
Error Code (Fehlercode)
Dieses Feld ist auf 0 gesetzt, es sei denn, ein „Allgemeiner Fehler" liegt vor. In diesem Fall wird der Ergebniscode auf 2 gesetzt und dieses Feld wird auf den Wert gesetzt, der der allgemeinen Fehlerbedingung entspricht, wie in Abschnitt 2.2 angegeben.
Reserved1 (Reserviert 1)
Dieses Feld muss (MUST) 0 sein.
2.5. Echo-Request (Echo-Anforderung)
Die Echo-Request ist eine PPTP-Steuernachricht, die von einem der Partner einer PAC-PNS-Steuerverbindung gesendet wird. Diese Steuernachricht wird als „Keep-Alive" für die Steuerverbindung verwendet. Der empfangende Partner gibt für jede empfangene Echo-Request eine Echo-Reply aus. Wie in Abschnitt 3.1.4 angegeben, wird der Sender die Steuerverbindung schließlich löschen, wenn er keine Echo-Reply als Antwort auf eine Echo-Request erhält.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibungen
Length (Länge)
Gesamtlänge in Oktetten dieser PPTP-Nachricht, einschließlich des gesamten PPTP-Headers.
PPTP Message Type (PPTP-Nachrichtentyp)
1 für Steuernachricht.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Steuernachrichtentyp)
5 für Echo-Request.
Reserved0 (Reserviert 0)
Dieses Feld muss (MUST) 0 sein.
Identifier (Identifikator)
32-Bit-Wert, der in der entsprechenden Echo-Reply zurückgesendet wird.
2.6. Echo-Reply (Echo-Antwort)
Die Echo-Reply ist eine PPTP-Steuernachricht, die von einem der Partner einer PAC-PNS-Steuerverbindung als Antwort auf den Empfang einer Echo-Request gesendet wird.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibungen
Length (Länge)
Gesamtlänge in Oktetten dieser PPTP-Nachricht, einschließlich des gesamten PPTP-Headers.
PPTP Message Type (PPTP-Nachrichtentyp)
1 für Steuernachricht.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Steuernachrichtentyp)
6 für Echo-Reply.
Reserved0 (Reserviert 0)
Dieses Feld muss (MUST) 0 sein.
Identifier (Identifikator)
Der Inhalt des Identifikationsfelds aus der empfangenen Echo-Request wird in dieses Feld kopiert.
Result Code (Ergebniscode)
Gibt das Ergebnis des Empfangs der Echo-Request an. Derzeit gültige Ergebniscodewerte sind:
- 1 (OK) - Die Echo-Reply ist gültig
- 2 (General Error) - Echo-Request nicht akzeptiert aus dem im Fehlercode angegebenen Grund
Error Code (Fehlercode)
Dieses Feld ist auf 0 gesetzt, es sei denn, eine „Allgemeine Fehler"-Bedingung liegt vor. In diesem Fall wird der Ergebniscode auf 2 gesetzt und dieses Feld wird auf den Wert gesetzt, der der allgemeinen Fehlerbedingung entspricht, wie in Abschnitt 2.2 angegeben.
Reserved1 (Reserviert 1)
Dieses Feld muss (MUST) 0 sein.
2.7. Outgoing-Call-Request (Ausgehende Anrufanforderung)
Die Outgoing-Call-Request ist eine PPTP-Steuernachricht, die vom PNS an den PAC gesendet wird, um anzuzeigen, dass ein ausgehender Anruf vom PAC aus hergestellt werden soll. Diese Anforderung stellt dem PAC die erforderlichen Informationen zur Verfügung, um den Anruf durchzuführen. Sie stellt dem PAC auch Informationen zur Verfügung, die verwendet werden, um die Übertragung von Daten an den PNS für diese Sitzung zu regulieren, sobald sie hergestellt ist.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Processing Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Phone Number Length | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Phone Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subaddress (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibungen
Length (Länge)
Gesamtlänge in Oktetten dieser PPTP-Nachricht, einschließlich des gesamten PPTP-Headers.
PPTP Message Type (PPTP-Nachrichtentyp)
1 für Steuernachricht.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Steuernachrichtentyp)
7 für Outgoing-Call-Request.
Reserved0 (Reserviert 0)
Dieses Feld muss (MUST) 0 sein.
Call ID (Anruf-ID)
Ein eindeutiger Identifikator, der für ein bestimmtes PAC-PNS-Paar eindeutig ist und vom PNS dieser Sitzung zugewiesen wird. Er wird verwendet, um über den Tunnel zwischen dem PNS und dem PAC gesendete Daten zu multiplexen und zu demultiplexen, die an dieser Sitzung beteiligt sind.
Call Serial Number (Anrufseriennummer)
Ein vom PNS dieser Sitzung zugewiesener Identifikator zum Zweck der Identifizierung dieser bestimmten Sitzung in protokollierten Sitzungsinformationen. Im Gegensatz zur Anruf-ID verknüpfen sowohl der PNS als auch der PAC dieselbe Anrufseriennummer mit einer bestimmten Sitzung. Die Kombination aus IP-Adresse und Anrufseriennummer sollte (SHOULD) eindeutig sein.
Minimum BPS (Minimum BPS)
Die niedrigste akzeptable Leitungsgeschwindigkeit (in Bits/Sekunde) für diese Sitzung.
Maximum BPS (Maximum BPS)
Die höchste akzeptable Leitungsgeschwindigkeit (in Bits/Sekunde) für diese Sitzung.
Bearer Type (Trägertyp)
Ein Wert, der die für diesen ausgehenden Anruf erforderliche Trägerfähigkeit angibt. Die derzeit definierten Werte sind:
- 1 - Anruf auf einem analogen Kanal durchzuführen
- 2 - Anruf auf einem digitalen Kanal durchzuführen
- 3 - Anruf kann auf jedem Kanaltyp durchgeführt werden
Framing Type (Framing-Typ)
Ein Wert, der den Typ des PPP-Framings angibt, der für diesen ausgehenden Anruf verwendet werden soll.
- 1 - Anruf verwendet asynchrones Framing
- 2 - Anruf verwendet synchrones Framing
- 3 - Anruf kann beide Framing-Typen verwenden
Packet Recv. Window Size (Paketempfangsfenstergröße)
Die Anzahl der empfangenen Datenpakete, die der PNS für diese Sitzung puffern wird.
Packet Processing Delay (Paketverarbeitungsverzögerung)
Ein Maß für die Paketverarbeitungsverzögerung, die auf Daten auferlegt werden könnte, die vom PAC an den PNS gesendet werden. Dieser Wert wird in Einheiten von 1/10 Sekunden angegeben. Für den PNS sollte diese Zahl sehr klein sein.
Phone Number Length (Telefonnummernlänge)
Die tatsächliche Anzahl gültiger Ziffern im Feld Phone Number.
Reserved1 (Reserviert 1)
Dieses Feld muss (MUST) 0 sein.
Phone Number (Telefonnummer)
Die zu wählende Nummer, um die ausgehende Sitzung herzustellen. Wenn sie weniger als 64 Oktette lang ist, wird der Rest dieses Feldes mit Oktetten des Wertes 0 gefüllt.
Subaddress (Unteradresse)
Ein 64-Oktett-Feld, das verwendet wird, um eine zusätzliche Wählzeichenfolge von Wahlinformationen anzugeben. Wenn sie weniger als 64 Oktette lang ist, wird der Rest dieses Feldes mit Oktetten des Wertes 0 gefüllt.
2.8. Outgoing-Call-Reply (Antwort auf ausgehenden Anruf)
Die Outgoing-Call-Reply ist eine PPTP-Steuernachricht, die vom PAC an den PNS als Antwort auf eine empfangene Outgoing-Call-Request-Nachricht gesendet wird. Die Antwort gibt das Ergebnis des ausgehenden Anrufversuchs an. Sie liefert dem PNS auch Informationen über bestimmte Parameter, die für den Anruf verwendet werden, und ermöglicht es dem PNS, die Datenübertragung zum PAC für diese Sitzung zu regulieren.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Peer's Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Cause Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Processing Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibungen
Length (Länge)
Gesamtlänge in Oktetten dieser PPTP-Nachricht, einschließlich des gesamten PPTP-Headers.
PPTP Message Type (PPTP-Nachrichtentyp)
1 für Steuernachricht.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Steuernachrichtentyp)
8 für Outgoing-Call-Reply.
Reserved0 (Reserviert 0)
Dieses Feld muss (MUST) 0 sein.
Call ID (Anruf-ID)
Eindeutiger Identifikator des Partners (PAC) für diese Sitzung. Dieser Wert wird als Multiplexschlüssel in allen nachfolgenden Anrufsteuerungsnachrichten verwendet, die vom Partner empfangen werden.
Peer's Call ID (Anruf-ID des Partners)
Dieser Wert wird aus dem Call ID-Feld der entsprechenden Outgoing-Call-Request kopiert und verwendet, um diese Antwort mit der gesendeten Outgoing-Call-Request zu verknüpfen.
Result Code (Ergebniscode)
Gibt das Ergebnis des ausgehenden Anrufversuchs an. Derzeit gültige Ergebniscodewerte umfassen:
- 1 (Connected) - Anruf ist verbunden
- 2 (General Error) - Ausgehender Anruf wurde aufgrund eines im Fehlercode angegebenen Fehlers nicht abgeschlossen
- 3 (No Carrier) - Ausgehender Anruf ist fehlgeschlagen, da kein Träger erkannt wurde
- 4 (Busy) - Ausgehender Anruf ist aufgrund eines Besetzt-Signals fehlgeschlagen
- 5 (No Dial Tone) - Ausgehender Anruf ist fehlgeschlagen, da kein Wählton erkannt wurde
- 6 (Time-out) - Ausgehender Anruf wurde nicht in der zugewiesenen Zeit abgeschlossen
- 7 (Do Not Accept) - Ausgehender Anruf wird administrativ lokal nicht akzeptiert
Error Code (Fehlercode)
Dieses Feld ist auf 0 gesetzt, es sei denn, eine allgemeine Fehlerbedingung liegt vor (wie durch Ergebniscode 2 angezeigt).
Cause Code (Ursachencode)
Dieses Feld liefert zusätzliche Fehlerinformationen bezüglich der Anruftrennung. Der Wert wird normalerweise von den Einrichtungen des Telefonnetzes bereitgestellt.
Connect Speed (Verbindungsgeschwindigkeit)
Gibt die tatsächliche Geschwindigkeit (in Bits/Sekunde) an, mit der der Anruf verbunden wurde.
Packet Recv. Window Size (Paketempfangsfenstergröße)
Die Anzahl der empfangenen Datenpakete, die der PAC für diese Sitzung puffern wird.
Packet Processing Delay (Paketverarbeitungsverzögerung)
Ein Maß für die Paketverarbeitungsverzögerung, die auf Daten auferlegt werden könnte, die vom PNS an den PAC gesendet werden. Dieser Wert wird in Einheiten von 1/10 Sekunden angegeben.
Physical Channel ID (Physikalische Kanal-ID)
Dieses Feld wird vom PAC als eindeutiger Identifikator des für diesen Anruf verwendeten physikalischen Kanals gesetzt. Sein Wert wird für Protokollierungs- und Debugging-Zwecke verwendet.
2.9. Incoming-Call-Request (Eingehende Anrufanforderung)
Die Incoming-Call-Request ist eine PPTP-Steuernachricht, die vom PAC an den PNS gesendet wird, um anzuzeigen, dass ein eingehender Anruf vom PSTN empfangen und lokal akzeptiert wurde. Diese Anforderung stellt dem PNS Informationen über den Typ des eingehenden Anrufs zur Verfügung. Sie liefert auch Informationen, die verwendet werden, um die Datenübertragung vom PAC zum PNS für diese Sitzung zu regulieren.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dialed Number Length | Dialing Number Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialed Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Dialing Number (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subaddress (64 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibungen
Length (Länge)
Gesamtlänge in Oktetten dieser PPTP-Nachricht, einschließlich des gesamten PPTP-Headers.
PPTP Message Type (PPTP-Nachrichtentyp)
1 für Steuernachricht.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Steuernachrichtentyp)
9 für Incoming-Call-Request.
Reserved0 (Reserviert 0)
Dieses Feld muss (MUST) 0 sein.
Call ID (Anruf-ID)
Eindeutiger Identifikator, der vom PAC dieser Sitzung zugewiesen wird. Dieser Wert wird als Multiplexschlüssel in allen nachfolgenden Anrufsteuerungsnachrichten verwendet.
Call Serial Number (Anrufseriennummer)
Identifikator, der vom PAC dieser Sitzung zugewiesen wird, um diese bestimmte Sitzung in protokollierten Sitzungsinformationen zu identifizieren.
Bearer Type (Trägertyp)
Wert, der die Trägerfähigkeit des eingehenden Anrufs angibt:
- 1 - Anruf auf analogem Kanal
- 2 - Anruf auf digitalem Kanal
Physical Channel ID (Physikalische Kanal-ID)
Eindeutiger Identifikator des physikalischen Kanals, den der PAC für diesen Anruf verwendet.
Dialed Number Length (Länge der gewählten Nummer)
Tatsächliche Anzahl gültiger Ziffern im Feld Dialed Number.
Dialing Number Length (Länge der wählenden Nummer)
Tatsächliche Anzahl gültiger Ziffern im Feld Dialing Number.
Dialed Number (Gewählte Nummer)
Die angerufene Nummer. 64-Oktett-Feld, bei Bedarf mit Nullen gefüllt.
Dialing Number (Wählende Nummer)
Die Nummer des Anrufers. 64-Oktett-Feld, bei Bedarf mit Nullen gefüllt.
Subaddress (Unteradresse)
Zusätzliche Wahlinformationen. 64-Oktett-Feld, bei Bedarf mit Nullen gefüllt.
2.10. Incoming-Call-Reply (Antwort auf eingehenden Anruf)
Die Incoming-Call-Reply ist eine PPTP-Steuernachricht, die vom PNS an den PAC als Antwort auf eine empfangene Incoming-Call-Request gesendet wird. Die Antwort gibt an, ob der PNS den eingehenden Anruf akzeptiert. Sie liefert auch Informationen, die verwendet werden, um die Datenübertragung vom PNS zum PAC für diese Sitzung zu regulieren.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Peer's Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code | Packet Recv. Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Processing Delay | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibungen
Control Message Type (Steuernachrichtentyp)
10 für Incoming-Call-Reply.
Result Code (Ergebniscode)
Gibt an, ob der PNS den eingehenden Anruf akzeptiert:
- 1 (Connect) - Akzeptiert den eingehenden Anruf
- 2 (General Error) - Eingehender Anruf wird aufgrund eines Fehlers nicht akzeptiert
- 3 (Do Not Accept) - Eingehender Anruf wird administrativ nicht akzeptiert
2.11. Incoming-Call-Connected (Eingehender Anruf verbunden)
Die Incoming-Call-Connected ist eine PPTP-Steuernachricht, die vom PAC an den PNS gesendet wird und als endgültige Bestätigung für einen eingehenden Anruf dient. Sie liefert Informationen über die Parameter der hergestellten Sitzung.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Recv. Window Size | Packet Processing Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibungen
Control Message Type (Steuernachrichtentyp)
11 für Incoming-Call-Connected.
Framing Type (Framing-Typ)
Für den eingehenden Anruf verwendeter Framing-Typ:
- 1 - Asynchrones Framing
- 2 - Synchrones Framing
2.12. Call-Clear-Request (Anruf-Lösch-Anforderung)
Die Call-Clear-Request ist eine PPTP-Steuernachricht, die vom PNS an den PAC gesendet wird, um anzuzeigen, dass ein bestimmter Anruf getrennt werden soll.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Control Message Type (Steuernachrichtentyp)
12 für Call-Clear-Request.
2.13. Call-Disconnect-Notify (Anruftrennungs-Benachrichtigung)
Die Call-Disconnect-Notify ist eine PPTP-Steuernachricht, die vom PAC an den PNS gesendet wird, um anzuzeigen, dass ein Anruf getrennt wurde.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call ID | Result Code | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Call Statistics (128 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Control Message Type (Steuernachrichtentyp)
13 für Call-Disconnect-Notify.
2.14. WAN-Error-Notify (WAN-Fehler-Benachrichtigung)
Die WAN-Error-Notify ist eine PPTP-Steuernachricht, die vom PAC an den PNS gesendet wird, um anzuzeigen, dass eine WAN-Fehlerbedingung aufgetreten ist.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-out Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Control Message Type (Steuernachrichtentyp)
14 für WAN-Error-Notify.
2.15. Set-Link-Info (Link-Informationen setzen)
Die Set-Link-Info ist eine PPTP-Steuernachricht, die vom PNS an den PAC gesendet wird, um PPP-Verhandlungsparameter festzulegen.
Nachrichtenformat
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | PPTP Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Message Type | Reserved0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer's Call ID | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Control Message Type (Steuernachrichtentyp)
15 für Set-Link-Info.
2.16. General Error Codes (Allgemeine Fehlercodes)
Folgende allgemeine Fehlercodewerte werden im Error Code-Feld verschiedener PPTP-Steuernachrichten verwendet:
- 0 - None (Kein Fehler)
- 1 - Not-Connected (Nicht verbunden) - Es existiert keine Steuerverbindung zwischen PAC und PNS
- 2 - Bad-Format (Schlechtes Format) - Nachrichtenlänge ist falsch oder Nachrichtenformat ist inkorrekt
- 3 - Bad-Value (Schlechter Wert) - Wert in einem Nachrichtenfeld liegt außerhalb des Bereichs oder ist ungültig
- 4 - No-Resource (Keine Ressource) - Unzureichende Ressourcen zur Verarbeitung dieses Befehls
- 5 - Bad-Call ID (Schlechte Anruf-ID) - Dieser Partner kennt die referenzierte Anruf-ID nicht
- 6 - PAC-Error (PAC-Fehler) - Allgemeiner Fehler beim PAC aufgetreten
Verwendungshinweise für Fehlercodes
Wenn das Result Code-Feld einer Steuernachricht so gesetzt ist, dass es einen allgemeinen Fehler anzeigt (normalerweise Wert 2), sollte das Error Code-Feld verwendet werden, um weitere Details über die Art dieses Fehlers bereitzustellen. Wenn der Result Code keinen allgemeinen Fehler anzeigt, muss (MUST) das Error Code-Feld auf 0 gesetzt werden.
Diese Fehlercodes sollen nützliche Diagnoseinformationen für Debugging- und Protokollierungszwecke bereitstellen und helfen, Probleme während der Einrichtung und Wartung von PPTP-Sitzungen zu identifizieren und zu lösen.
Abschnitt 2 abgeschlossen - Dieser Abschnitt hat alle Nachrichtentypen detailliert definiert, die im PPTP-Steuerverbindungsprotokoll verwendet werden, einschließlich Steuerverbindungsverwaltungsnachrichten (2.1-2.6), Anrufsteuerungsnachrichten (2.7-2.15) und allgemeine Fehlercodes (2.16).
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.
4. Tunnelprotokollbetrieb (Tunnel Protocol Operation)
Die vom PPTP-Protokoll übertragenen Benutzerdaten sind PPP-Datenpakete. PPP-Pakete werden zwischen PAC und PNS übertragen, eingekapselt in GRE-Pakete, die wiederum über IP übertragen werden. Die eingekapselten PPP-Pakete sind im Wesentlichen PPP-Datenpakete ohne medienspezifische Rahmenelemente. Keine HDLC-Flags, Bit-Einfügung, Steuerzeichen oder Steuerzeichenmaskierungen sind enthalten. Keine CRCs werden durch den Tunnel gesendet. Die IP-Pakete, die über die Tunnel zwischen einem PAC und PNS übertragen werden, haben die folgende allgemeine Struktur:
+--------------------------------+
| Media Header |
| (Medien-Header) |
+--------------------------------+
| IP Header |
| (IP-Header) |
+--------------------------------+
| GRE Header |
| (GRE-Header) |
+--------------------------------+
| PPP Packet |
| (PPP-Paket) |
+--------------------------------+
4.1. Erweiterter GRE-Header (Enhanced GRE Header)
Der in PPTP verwendete GRE-Header ist gegenüber dem in der aktuellen GRE-Protokollspezifikation [1,2] spezifizierten leicht erweitert. Der Hauptunterschied besteht in der Definition eines neuen Acknowledgment Number-Feldes, das verwendet wird, um zu bestimmen, ob ein bestimmtes GRE-Paket oder eine Gruppe von Paketen am entfernten Ende des Tunnels angekommen ist. Diese Acknowledgment-Fähigkeit wird nicht in Verbindung mit einer Neuübertragung von Benutzerdatenpaketen verwendet. Sie wird stattdessen verwendet, um die Rate zu bestimmen, mit der Benutzerdatenpakete über den Tunnel für eine gegebene Benutzersitzung übertragen werden sollen. Das Format des erweiterten GRE-Headers ist wie folgt:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (HW) Payload Length | Key (LW) Call ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feldbeschreibung
C (Bit 0) - Checksum Present (Prüfsumme vorhanden)
- Auf 0 setzen.
R (Bit 1) - Routing Present (Routing vorhanden)
- Auf 0 setzen.
K (Bit 2) - Key Present (Schlüssel vorhanden)
- Auf 1 setzen.
S (Bit 3) - Sequence Number Present (Sequenznummer vorhanden)
- Auf 1 setzen, wenn ein Payload (Daten)-Paket vorhanden ist. Auf 0 setzen, wenn keine Payload vorhanden ist (GRE-Paket ist nur ein Acknowledgment).
s (Bit 4) - Strict Source Route Present (Strikte Quellroute vorhanden)
- Auf 0 setzen.
Recur (Bits 5-7) - Recursion Control (Rekursionskontrolle)
- Auf 0 setzen.
A (Bit 8) - Acknowledgment Sequence Number Present (Acknowledgment-Sequenznummer vorhanden)
- Auf 1 setzen, wenn das Paket eine Acknowledgment-Nummer enthält, die zur Bestätigung zuvor übertragener Daten verwendet werden soll.
Flags (Bits 9-12)
- Muss auf 0 gesetzt werden (MUST).
Ver (Bits 13-15) - Version
- Muss 1 enthalten (erweitertes GRE) (MUST).
Protocol Type (Protokolltyp)
- Auf Hexadezimal 880B [8] setzen.
Key (Schlüssel)
- Die Verwendung des Schlüsselfeldes liegt bei der Implementierung. PPTP verwendet es wie folgt:
- Payload Length (Payload-Länge) (obere 2 Oktette des Schlüssels): Größe der Payload, ohne den GRE-Header
- Call ID (Anruf-ID) (untere 2 Oktette): Enthält die Peer's Call ID für die Sitzung, zu der dieses Paket gehört
Sequence Number (Sequenznummer)
- Enthält die Sequenznummer der Payload. Vorhanden, wenn S-Bit (Bit 3) 1 ist.
Acknowledgment Number (Acknowledgment-Nummer)
- Enthält die Sequenznummer des höchsten nummerierten GRE-Pakets, das vom sendenden Peer für diese Benutzersitzung empfangen wurde. Vorhanden, wenn A-Bit (Bit 8) 1 ist.
Der Payload-Abschnitt enthält ein PPP-Datenpaket ohne medienspezifische Rahmenelemente.
Die beteiligten Sequenznummern sind Sequenznummern pro Paket. Die Sequenznummer für jede Benutzersitzung wird beim Sitzungsstart auf Null gesetzt. Jedem Paket, das für eine gegebene Benutzersitzung gesendet wird und eine Payload enthält (und das S-Bit (Bit 3) auf 1 gesetzt hat), wird die nächste aufeinanderfolgende Sequenznummer für diese Sitzung zugewiesen.
Dieses Protokoll ermöglicht es, Acknowledgments mit den Daten zu übertragen, und macht das Gesamtprotokoll effizienter, was wiederum weniger Pufferung von Paketen erfordert.
4.2. Schiebefenster-Protokoll (Sliding Window Protocol)
Das auf dem PPTP-Datenpfad verwendete Schiebefenster-Protokoll wird für die Flusskontrolle durch jede Seite des Datenaustauschs verwendet. Das erweiterte GRE-Protokoll ermöglicht es, Paketbestätigungen auf Datenpakete aufzusetzen. Acknowledgments können auch getrennt von Datenpaketen gesendet werden. Wieder ist der Hauptzweck des Schiebefenster-Protokolls die Flusskontrolle - Neuübertragungen werden von den Tunnel-Peers nicht durchgeführt.
4.2.1. Anfängliche Fenstergröße (Initial Window Size)
Obwohl jede Seite die maximale Größe ihres Empfangsfensters angegeben hat, wird empfohlen, beim Beginn der Datenübertragung einen konservativen Ansatz zu verfolgen. Die anfängliche Fenstergröße am Sender wird auf die Hälfte der vom Empfänger angeforderten maximalen Größe gesetzt, mit einer Mindestgröße von einem Paket. Der Sender stoppt das Senden von Paketen, wenn die Anzahl der auf Bestätigung wartenden Pakete gleich der aktuellen Fenstergröße ist. Wenn der Empfänger jedes Fenster erfolgreich verarbeitet, wird die Fenstergröße am Sender um ein Paket erhöht, bis das Maximum erreicht ist. Diese Methode verhindert, dass ein System ein bereits überlastetes Netzwerk überflutet, da keine Historie aufgebaut wurde.
4.2.2. Schließen des Fensters (Closing the Window)
Wenn bei einem Paket ein Timeout auftritt, passt der Sender die Größe des Übertragungsfensters auf die Hälfte seines Wertes zum Zeitpunkt des Fehlers an. Brüche werden aufgerundet, und die Mindestfenstergröße beträgt 1.
4.2.3. Öffnen des Fensters (Opening the Window)
Mit jeder erfolgreichen Übertragung eines Fensters voller Pakete ohne Timeout wird die Größe des Übertragungsfensters um ein Paket erhöht, bis es die maximale Fenstergröße erreicht, die von der anderen Seite gesendet wurde, als der Anruf verbunden wurde. Wie bereits erwähnt, wird bei einem Timeout keine Neuübertragung durchgeführt. Nach einem Timeout wird die Übertragung mit dem Fenster fortgesetzt, das bei der Hälfte der Größe des Übertragungsfensters beginnt, als der Timeout auftrat, und sich um eins nach oben anpasst, jedes Mal wenn das Übertragungsfenster mit Paketen gefüllt ist, die alle ohne Timeouts bestätigt werden.
4.2.4. Fensterüberlauf (Window Overflow)
Wenn das Fenster eines Empfängers mit zu vielen eingehenden Paketen überläuft, werden überschüssige Pakete verworfen. Diese Situation sollte nicht auftreten, wenn die Schiebefenster-Verfahren vom Sender und Empfänger ordnungsgemäß befolgt werden. Es wird angenommen, dass auf der Sendeseite Pakete zur Übertragung gepuffert werden und nicht mehr von der Paketquelle akzeptiert werden, wenn der Sendepuffer voll ist.
4.2.5. Mehrfachpaket-Acknowledgment (Multi-packet Acknowledgment)
Ein Merkmal des PPTP-Schiebefenster-Protokolls ist, dass es die Bestätigung mehrerer Pakete mit einem einzigen Acknowledgment ermöglicht. Alle ausstehenden Pakete mit einer Sequenznummer kleiner oder gleich der Acknowledgment-Nummer werden als bestätigt betrachtet. Timeout-Berechnungen werden unter Verwendung der Zeit durchgeführt, zu der das Paket, das der höchsten bestätigten Sequenznummer entspricht, übertragen wurde.
Adaptive Timeout-Berechnungen werden nur durchgeführt, wenn ein Acknowledgment empfangen wird. Wenn Mehrfachpaket-Acknowledgments verwendet werden, wird der Overhead des adaptiven Timeout-Algorithmus reduziert. Der PAC ist nicht verpflichtet (not required), Mehrfachpaket-Acknowledgments zu übertragen; er kann stattdessen jedes Paket einzeln bestätigen, wenn es an den PPP-Client geliefert wird.
4.3. Pakete außer der Reihe (Out-of-sequence Packets)
Gelegentlich verlieren Pakete ihre Sequenzierung über ein kompliziertes Internetwork. Angenommen, ein PNS sendet die Pakete 0 bis 5 an einen PAC. Aufgrund von Umleitung im Internetwork kommt Paket 4 vor Paket 3 am PAC an. Der PAC bestätigt Paket 4 und kann annehmen, dass Paket 3 verloren gegangen ist. Diese Bestätigung gewährt Fensterguthaben über Paket 4 hinaus.
Wenn der PAC Paket 3 tatsächlich empfängt, darf er nicht (MUST NOT) versuchen, es an den entsprechenden PPP-Client zu übertragen. Dies könnte Probleme verursachen, da der ordnungsgemäße PPP-Protokollbetrieb auf dem sequentiellen Empfang von Paketen basiert. PPP behandelt den Verlust von Paketen ordnungsgemäß, aber nicht die Neuordnung, daher müssen Pakete außer der Reihe zwischen PNS und PAC stillschweigend verworfen werden (MUST), oder sie können vom Empfänger neu geordnet werden. Wenn Paket 5 ankommt, wird es vom PAC bestätigt, da es eine höhere Sequenznummer als 4 hat, was das letzte höchste vom PAC bestätigte Paket war. Pakete mit doppelten Sequenznummern sollten niemals auftreten, da PAC und PNS niemals GRE-Pakete neu übertragen. Eine robuste Implementierung wird doppelte GRE-Pakete stillschweigend verwerfen, sollte sie welche empfangen.
4.4. Acknowledgment-Timeouts (Acknowledgment Time-Outs)
PPTP verwendet Schiebefenster und Timeouts, um sowohl Benutzersitzungs-Flusskontrolle über das Internetwork bereitzustellen als auch um effizientes Datenpuffern durchzuführen, um die PAC-PNS-Datenkanäle voll zu halten, ohne Empfangspufferüberlauf zu verursachen. PPTP erfordert, dass ein Timeout verwendet wird, um von verlorenen Daten- oder Acknowledgment-Paketen zu erholen. Die genaue Implementierung des Timeouts ist herstellerspezifisch. Es wird vorgeschlagen, dass ein adaptiver Timeout mit Rückfall für Überlastkontrolle implementiert wird. Der hier vorgeschlagene Timeout-Mechanismus hat die folgenden Eigenschaften:
- Unabhängige Timeouts für jede Sitzung: Ein Gerät (PAC oder PNS) muss Timeouts für jede aktive Sitzung pflegen und berechnen.
- Ein vom Administrator einstellbarer maximaler Timeout (MaxTimeOut): Eindeutig für jedes Gerät.
- Ein adaptiver Timeout-Mechanismus: Der sich ändernden Durchsatz kompensiert. Um den Paketverarbeitungsaufwand zu reduzieren, können Anbieter wählen, den adaptiven Timeout nicht für jedes empfangene Acknowledgment neu zu berechnen. Das Ergebnis dieser Aufwandsreduzierung ist, dass der Timeout nicht so schnell auf schnelle Netzwerkänderungen reagiert.
- Timer-Rückfall bei Timeout: Um Überlastung zu reduzieren. Der zurückgefallene Timer-Wert wird durch den konfigurierbaren maximalen Timeout-Wert begrenzt. Timer-Rückfall wird jedes Mal durchgeführt, wenn ein Acknowledgment-Timeout auftritt.
Im Allgemeinen hat dieser Mechanismus das wünschenswerte Verhalten, bei einem Timeout schnell zurückzufallen und den Timeout-Wert langsam zu verringern, wenn Pakete ohne Timeouts geliefert werden.
Definitionen
Packet Processing Delay (PPD) - Paketverarbeitungsverzögerung
- Die Zeit, die jede Seite benötigt, um die maximale Datenmenge zu verarbeiten, die in ihrem Empfangspaket-Schiebefenster gepuffert ist. Der PPD ist der Wert, der zwischen PAC und PNS ausgetauscht wird, wenn ein Anruf aufgebaut wird. Für den PNS sollte diese Zahl klein sein. Für einen PAC, der Modemverbindungen herstellt, könnte diese Zahl signifikant sein.
Sample (Probe)
- Die tatsächlich aufgewendete Zeit für den Empfang eines Acknowledgments für ein Paket. Die Probe wird gemessen, nicht berechnet.
Round-Trip Time (RTT) - Rundreisezeit
- Die geschätzte Rundreisezeit für den Empfang eines Acknowledgments für ein gegebenes übertragenes Paket. Wenn die Netzwerkverbindung ein lokales Netzwerk ist, wird diese Verzögerung minimal sein (wenn nicht null). Wenn die Netzwerkverbindung das Internet ist, könnte diese Verzögerung erheblich sein und stark variieren. RTT ist adaptiv: es wird sich anpassen, um den PPD und alle sich ändernden Netzwerkverzögerungen einzubeziehen, die zur Zeit zwischen der Übertragung eines Pakets und dem Empfang seines Acknowledgments beitragen.
Adaptive Time-Out (ATO) - Adaptiver Timeout
- Die Zeit, die vergehen muss, bevor ein Acknowledgment als verloren betrachtet wird. Nach einem Timeout wird das Schiebefenster teilweise geschlossen und der ATO wird zurückgefallen.
Der Paketverarbeitungsverzögerung (PPD)-Parameter ist ein 16-Bit-Wort, das während der Anrufsteuerungsphase ausgetauscht wird und Zehntelsekunden darstellt (64 bedeutet 6,4 Sekunden). Das Protokoll spezifiziert nur, dass der Parameter ausgetauscht wird, es spezifiziert nicht, wie er berechnet wird. Die Art und Weise, wie Werte für PPD berechnet werden, ist implementierungsabhängig und muss nicht variabel sein (statische Timeouts sind erlaubt). Der PPD muss (MUST) in den Anrufverbindungssequenzen ausgetauscht werden, auch wenn er in einer Implementierung konstant bleibt. Eine mögliche Art, den PPD zu berechnen, ist:
PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
PPD = PPD' + PACFudge
Wobei:
- Header die Gesamtgröße der IP- und GRE-Header ist, die 36 beträgt
- MTU die Gesamt-MTU für die Internetwork-Verbindung zwischen PAC und PNS ist
- WindowSize die Anzahl der Pakete im Schiebefenster darstellt und implementierungsabhängig ist
- Die Konstante 8 Oktette in Bits umwandelt (unter der Annahme, dass ConnectRate in Bits pro Sekunde ist)
- PACFudge nicht erforderlich ist, aber verwendet werden kann, um den Gesamt-Verarbeitungsaufwand des PAC zu berücksichtigen
Der Wert von PPD wird verwendet, um den adaptiven Algorithmus mit dem anfänglichen RTT[n-1]-Wert zu initialisieren.
4.4.1. Berechnung des adaptiven Acknowledgment-Timeouts (Calculating Adaptive Acknowledgment Time-Out)
Wir müssen noch entscheiden, wie viel Zeit wir für die Rückkehr von Acknowledgments zulassen. Wenn der Timeout zu hoch eingestellt ist, warten wir möglicherweise unnötig lange auf verlorene Pakete. Wenn der Timeout zu kurz ist, könnten wir kurz vor der Ankunft des Acknowledgments einen Timeout erleben. Der Acknowledgment-Timeout sollte auch angemessen sein und auf sich ändernde Netzwerkbedingungen reagieren.
Der vorgeschlagene adaptive Algorithmus, der unten detailliert beschrieben wird, basiert auf der TCP 1989-Implementierung und wird in [11] erklärt. 'n' bedeutet das aktuelle Paket und 'n-1' bedeutet das vorherige Paket:
Err[n] = Sample[n] - RTT[n-1]
RTT[n] = RTT[n-1] + (g * Err[n])
Dev[n] = Dev[n-1] + h * (|Err[n]| - Dev[n-1])
ATO[n] = RTT[n] + (f * Dev[n])
Wobei:
- g der Verstärkungsfaktor ist (empfohlener Wert 0.125)
- h der Abweichungs-Verstärkungsfaktor ist (empfohlener Wert 0.25)
- f der Abweichungs-Multiplikationsfaktor ist (empfohlener Wert 4)
4.4.2. Überlastkontrolle: Anpassung für Timeout (Congestion Control: Adjusting for Time-Out)
Dieser Abschnitt beschreibt, wie die Berechnung von ATO im Fall eines Timeouts modifiziert wird. Wenn ein Timeout auftritt, sollte der Timeout-Wert schnell nach oben angepasst werden. Obwohl GRE-Pakete bei einem Timeout nicht neu übertragen werden, sollte der Timeout in Richtung eines Maximallimits angepasst werden. Um sich verschiebende Internetwork-Zeitverzögerungen zu kompensieren, muss eine Strategie eingesetzt werden, um den Timeout zu erhöhen, wenn er abläuft (beachten Sie, dass wir zusätzlich zur Erhöhung des Timeouts auch die Größe des Fensters verkleinern, wie im nächsten Abschnitt beschrieben).
Für ein Intervall, in dem ein Timeout auftritt:
ATO[n] = MIN(2 * ATO[n-1], MaxTimeOut)
Wobei MaxTimeOut der vom Administrator konfigurierte maximale Timeout-Wert ist.
5. Sicherheitsüberlegungen (Security Considerations)
Die Sicherheit von Benutzerdaten, die über die getunnelte PPP-Verbindung übertragen werden, wird von PPP behandelt, ebenso wie die Authentifizierung der PPP-Peers.
Da PPTP-Steuerkanalnachrichten weder authentifiziert noch integritätsgeschützt sind, könnte es einem Angreifer möglich sein, die zugrunde liegende TCP-Verbindung zu entführen. Es ist auch möglich, falsche Steuerkanalnachrichten herzustellen und echte Nachrichten während der Übertragung unentdeckt zu ändern.
Die GRE-Pakete, die den Tunnel selbst bilden, sind nicht kryptographisch geschützt. Da die PPP-Verhandlungen über den Tunnel durchgeführt werden, kann es einem Angreifer möglich sein, diese Verhandlungen abzuhören und zu modifizieren.
Sofern die PPP-Nutzdaten nicht kryptographisch geschützt sind, können sie erfasst und gelesen oder modifiziert werden.
6. Autorenadressen (Authors' Addresses)
Kory Hamzeh
Ascend Communications
1275 Harbor Bay Parkway
Alameda, CA 94502
Email: [email protected]
Gurdeep Singh Pall
Microsoft Corporation
Redmond, WA
Email: [email protected]
William Verthein
U.S. Robotics/3Com
Jeff Taarud
Copper Mountain Networks
W. Andrew Little
ECI Telematics
Glen Zorn
Microsoft Corporation
Redmond, WA
Email: [email protected]
7. Referenzen (References)
[1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994.
[3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.
[4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980.
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[8] Ethertype for PPP, Reserved with Xerox Corporation.
[9] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison-Wesley, 1994.
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
8. Vollständige Urheberrechtserklärung (Full Copyright Statement)
Copyright (C) The Internet Society (1999). All Rights Reserved.
Dieses Dokument und Übersetzungen davon dürfen kopiert und anderen zur Verfügung gestellt werden, und abgeleitete Werke, die es kommentieren oder anderweitig erklären oder bei seiner Implementierung helfen, dürfen ganz oder teilweise ohne Einschränkung jeglicher Art vorbereitet, kopiert, veröffentlicht und verteilt werden, vorausgesetzt, dass der obige Urheberrechtshinweis und dieser Absatz in allen solchen Kopien und abgeleiteten Werken enthalten sind. Dieses Dokument selbst darf jedoch in keiner Weise geändert werden, z. B. durch Entfernen des Urheberrechtshinweises oder Verweisen auf die Internet Society oder andere Internet-Organisationen, außer wenn dies für die Entwicklung von Internet-Standards erforderlich ist, in welchem Fall die im Internet Standards Process definierten Urheberrechtsverfahren befolgt werden müssen, oder wie erforderlich, um es in andere Sprachen als Englisch zu übersetzen.
Die oben gewährten eingeschränkten Berechtigungen sind unbefristet und werden von der Internet Society oder ihren Nachfolgern oder Rechtsnachfolgern nicht widerrufen.
Dieses Dokument und die hierin enthaltenen Informationen werden "WIE BESEHEN" bereitgestellt, und die Internet Society und die Internet Engineering Task Force LEHNEN ALLE GARANTIEN AB, AUSDRÜCKLICH ODER STILLSCHWEIGEND, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF JEGLICHE GARANTIE, DASS DIE VERWENDUNG DER HIERIN ENTHALTENEN INFORMATIONEN KEINE RECHTE VERLETZT ODER JEGLICHE STILLSCHWEIGENDE GARANTIEN DER MARKTGÄNGIGKEIT ODER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK.