Zum Hauptinhalt springen

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.

Letztes Update am