Passa al contenuto principale

4. Funzionamento del protocollo tunnel (Tunnel Protocol Operation)

I dati utente trasportati dal protocollo PPTP sono pacchetti di dati PPP. I pacchetti PPP vengono trasportati tra PAC e PNS, incapsulati in pacchetti GRE che a loro volta vengono trasportati su IP. I pacchetti PPP incapsulati sono essenzialmente pacchetti di dati PPP meno gli elementi di inquadramento specifici del media. Nessun flag HDLC, inserimento di bit, caratteri di controllo o escape di caratteri di controllo sono inclusi. Nessun CRC viene inviato attraverso il tunnel. I pacchetti IP trasmessi sui tunnel tra un PAC e un PNS hanno la seguente struttura generale:

+--------------------------------+
|          Media Header          |
|      (Intestazione media)      |
+--------------------------------+
|           IP Header            |
|       (Intestazione IP)        |
+--------------------------------+
|           GRE Header           |
|      (Intestazione GRE)        |
+--------------------------------+
|           PPP Packet           |
|        (Pacchetto PPP)         |
+--------------------------------+

4.1. Intestazione GRE migliorata (Enhanced GRE Header)​

L'intestazione GRE utilizzata in PPTP è leggermente migliorata rispetto a quella specificata nell'attuale specifica del protocollo GRE [1,2]. La principale differenza riguarda la definizione di un nuovo campo Acknowledgment Number, utilizzato per determinare se un particolare pacchetto GRE o un insieme di pacchetti è arrivato all'estremità remota del tunnel. Questa capacità di riconoscimento non viene utilizzata insieme ad alcuna ritrasmissione di pacchetti di dati utente. Viene invece utilizzata per determinare la velocità con cui i pacchetti di dati utente devono essere trasmessi attraverso il tunnel per una determinata sessione utente. Il formato dell'intestazione GRE migliorata è il seguente:

 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)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Descrizione campi​

C (Bit 0) - Checksum Present (Checksum presente)

  • Impostare a 0.

R (Bit 1) - Routing Present (Routing presente)

  • Impostare a 0.

K (Bit 2) - Key Present (Chiave presente)

  • Impostare a 1.

S (Bit 3) - Sequence Number Present (Numero di sequenza presente)

  • Impostare a 1 se è presente un pacchetto di payload (dati). Impostare a 0 se il payload non è presente (il pacchetto GRE è solo un riconoscimento).

s (Bit 4) - Strict Source Route Present (Percorso sorgente rigoroso presente)

  • Impostare a 0.

Recur (Bits 5-7) - Recursion Control (Controllo ricorsione)

  • Impostare a 0.

A (Bit 8) - Acknowledgment Sequence Number Present (Numero di sequenza riconoscimento presente)

  • Impostare a 1 se il pacchetto contiene un numero di riconoscimento da utilizzare per riconoscere i dati precedentemente trasmessi.

Flags (Bits 9-12)

  • Deve essere impostato a 0 (MUST).

Ver (Bits 13-15) - Version (Versione)

  • Deve contenere 1 (GRE migliorato) (MUST).

Protocol Type (Tipo di protocollo)

  • Impostare a esadecimale 880B [8].

Key (Chiave)

  • L'uso del campo Chiave dipende dall'implementazione. PPTP lo utilizza come segue:
    • Payload Length (Lunghezza payload) (2 ottetti superiori della chiave): Dimensione del payload, senza includere l'intestazione GRE
    • Call ID (ID chiamata) (2 ottetti inferiori): Contiene l'ID chiamata del peer per la sessione a cui appartiene questo pacchetto

Sequence Number (Numero di sequenza)

  • Contiene il numero di sequenza del payload. Presente se il bit S (Bit 3) è 1.

Acknowledgment Number (Numero di riconoscimento)

  • Contiene il numero di sequenza del pacchetto GRE con il numero più alto ricevuto dal peer mittente per questa sessione utente. Presente se il bit A (Bit 8) è 1.

La sezione payload contiene un pacchetto di dati PPP senza alcun elemento di inquadramento specifico del media.

I numeri di sequenza coinvolti sono numeri di sequenza per pacchetto. Il numero di sequenza per ogni sessione utente viene impostato a zero all'avvio della sessione. Ogni pacchetto inviato per una determinata sessione utente che contiene un payload (e ha il bit S (Bit 3) impostato a 1) viene assegnato il successivo numero di sequenza consecutivo per quella sessione.

Questo protocollo consente di trasportare i riconoscimenti insieme ai dati e rende il protocollo complessivo più efficiente, il che a sua volta richiede meno buffering dei pacchetti.

4.2. Protocollo a finestra scorrevole (Sliding Window Protocol)​

Il protocollo a finestra scorrevole utilizzato sul percorso dati PPTP viene utilizzato per il controllo di flusso da ciascun lato dello scambio di dati. Il protocollo GRE migliorato consente di agganciare i riconoscimenti dei pacchetti sui pacchetti di dati. I riconoscimenti possono anche essere inviati separatamente dai pacchetti di dati. Ancora una volta, lo scopo principale del protocollo a finestra scorrevole è il controllo di flusso - le ritrasmissioni non vengono eseguite dai peer del tunnel.

4.2.1. Dimensione finestra iniziale (Initial Window Size)​

Sebbene ciascun lato abbia indicato la dimensione massima della sua finestra di ricezione, si raccomanda di adottare un approccio conservativo all'inizio della trasmissione dei dati. La dimensione della finestra iniziale sul trasmettitore è impostata a metà della dimensione massima richiesta dal ricevitore, con una dimensione minima di un pacchetto. Il trasmettitore smette di inviare pacchetti quando il numero di pacchetti in attesa di riconoscimento è uguale alla dimensione della finestra corrente. Man mano che il ricevitore digerisce con successo ciascuna finestra, la dimensione della finestra sul trasmettitore viene aumentata di un pacchetto fino al raggiungimento del massimo. Questo metodo impedisce a un sistema di inondare una rete già congestionata perché non è stata stabilita alcuna cronologia.

4.2.2. Chiusura della finestra (Closing the Window)​

Quando si verifica un timeout su un pacchetto, il mittente regola la dimensione della finestra di trasmissione a metà del suo valore al momento del fallimento. Le frazioni vengono arrotondate per eccesso e la dimensione minima della finestra è 1.

4.2.3. Apertura della finestra (Opening the Window)​

Con ogni trasmissione riuscita di una finestra di pacchetti senza timeout, la dimensione della finestra di trasmissione viene aumentata di un pacchetto fino a raggiungere la dimensione massima della finestra inviata dall'altro lato quando è stata connessa la chiamata. Come affermato in precedenza, non viene eseguita alcuna ritrasmissione su un timeout. Dopo un timeout, la trasmissione riprende con la finestra che inizia a metà della dimensione della finestra di trasmissione quando si è verificato il timeout e si regola verso l'alto di uno ogni volta che la finestra di trasmissione è riempita con pacchetti che sono tutti riconosciuti senza timeout.

4.2.4. Overflow della finestra (Window Overflow)​

Quando la finestra di un ricevitore trabocca con troppi pacchetti in arrivo, i pacchetti in eccesso vengono scartati. Questa situazione non dovrebbe verificarsi se le procedure della finestra scorrevole vengono seguite correttamente dal trasmettitore e dal ricevitore. Si presume che, sul lato di trasmissione, i pacchetti vengano bufferizzati per la trasmissione e non vengano più accettati dalla sorgente di pacchetti quando il buffer di trasmissione si riempie.

4.2.5. Riconoscimento multi-pacchetto (Multi-packet Acknowledgment)​

Una caratteristica del protocollo a finestra scorrevole PPTP è che consente il riconoscimento di più pacchetti con un singolo riconoscimento. Tutti i pacchetti in sospeso con un numero di sequenza inferiore o uguale al numero di riconoscimento sono considerati riconosciuti. I calcoli di timeout vengono eseguiti utilizzando il tempo in cui è stato trasmesso il pacchetto corrispondente al numero di sequenza più alto riconosciuto.

I calcoli di timeout adattivi vengono eseguiti solo quando viene ricevuto un riconoscimento. Quando vengono utilizzati riconoscimenti multi-pacchetto, l'overhead dell'algoritmo di timeout adattivo viene ridotto. Il PAC non è tenuto (not required) a trasmettere riconoscimenti multi-pacchetto; può invece riconoscere ciascun pacchetto individualmente quando viene consegnato al client PPP.

4.3. Pacchetti fuori sequenza (Out-of-sequence Packets)​

Occasionalmente i pacchetti perdono la loro sequenza attraverso un internetwork complicato. Supponiamo, ad esempio, che un PNS invii i pacchetti da 0 a 5 a un PAC. A causa del re-routing nell'internetwork, il pacchetto 4 arriva al PAC prima del pacchetto 3. Il PAC riconosce il pacchetto 4 e può presumere che il pacchetto 3 sia perso. Questo riconoscimento concede credito di finestra oltre il pacchetto 4.

Quando il PAC riceve effettivamente il pacchetto 3, non deve (MUST NOT) tentare di trasmetterlo al client PPP corrispondente. Farlo potrebbe causare problemi, poiché il corretto funzionamento del protocollo PPP si basa sulla ricezione di pacchetti in sequenza. PPP gestisce correttamente la perdita di pacchetti, ma non il riordino, quindi i pacchetti fuori sequenza tra PNS e PAC devono essere silenziosamente scartati (MUST), oppure possono essere riordinati dal ricevitore. Quando arriva il pacchetto 5, viene riconosciuto dal PAC poiché ha un numero di sequenza superiore a 4, che era l'ultimo pacchetto più alto riconosciuto dal PAC. Pacchetti con numeri di sequenza duplicati non dovrebbero mai verificarsi poiché PAC e PNS non ritrasmettono mai pacchetti GRE. Un'implementazione robusta scarterà silenziosamente i pacchetti GRE duplicati, se ne riceve.

4.4. Timeout di riconoscimento (Acknowledgment Time-Outs)​

PPTP utilizza finestre scorrevoli e timeout per fornire sia il controllo di flusso della sessione utente attraverso l'internetwork sia per eseguire un buffering efficiente dei dati per mantenere i canali dati PAC-PNS pieni senza causare overflow del buffer di ricezione. PPTP richiede che venga utilizzato un timeout per recuperare da pacchetti di dati o di riconoscimento persi. L'implementazione esatta del timeout è specifica del fornitore. Si suggerisce che venga implementato un timeout adattivo con backoff per il controllo della congestione. Il meccanismo di timeout proposto qui ha le seguenti proprietà:

  • Timeout indipendenti per ciascuna sessione: Un dispositivo (PAC o PNS) dovrà mantenere e calcolare i timeout per ogni sessione attiva.
  • Un timeout massimo regolabile dall'amministratore (MaxTimeOut): Unico per ciascun dispositivo.
  • Un meccanismo di timeout adattivo: Che compensa il throughput variabile. Per ridurre l'overhead di elaborazione dei pacchetti, i fornitori possono scegliere di non ricalcolare il timeout adattivo per ogni riconoscimento ricevuto. Il risultato di questa riduzione dell'overhead è che il timeout non risponderà così rapidamente ai rapidi cambiamenti della rete.
  • Backoff del timer al timeout: Per ridurre la congestione. Il valore del timer backoff è limitato dal valore di timeout massimo configurabile. Il backoff del timer viene eseguito ogni volta che si verifica un timeout di riconoscimento.

In generale, questo meccanismo ha il comportamento desiderabile di retrocedere rapidamente al verificarsi di un timeout e di diminuire lentamente il valore del timeout quando i pacchetti vengono consegnati senza timeout.

Definizioni​

Packet Processing Delay (PPD) - Ritardo elaborazione pacchetti

  • La quantità di tempo richiesta da ciascun lato per elaborare la quantità massima di dati bufferizzata nella loro finestra scorrevole di ricezione pacchetti. Il PPD è il valore scambiato tra PAC e PNS quando viene stabilita una chiamata. Per il PNS, questo numero dovrebbe essere piccolo. Per un PAC che effettua connessioni modem, questo numero potrebbe essere significativo.

Sample (Campione)

  • La quantità effettiva di tempo impiegata per ricevere un riconoscimento per un pacchetto. Il campione viene misurato, non calcolato.

Round-Trip Time (RTT) - Tempo di andata e ritorno

  • Il tempo di andata e ritorno stimato per ricevere un riconoscimento per un dato pacchetto trasmesso. Quando il collegamento di rete è una rete locale, questo ritardo sarà minimo (se non zero). Quando il collegamento di rete è Internet, questo ritardo potrebbe essere sostanziale e variare ampiamente. RTT è adattivo: si regolerà per includere il PPD e qualsiasi ritardo di rete variabile che contribuisce al tempo tra la trasmissione di un pacchetto e la ricezione del suo riconoscimento.

Adaptive Time-Out (ATO) - Timeout adattivo

  • Il tempo che deve trascorrere prima che un riconoscimento sia considerato perso. Dopo un timeout, la finestra scorrevole viene parzialmente chiusa e l'ATO viene fatto retrocedere.

Il parametro Packet Processing Delay (PPD) è una parola a 16 bit scambiata durante la fase di controllo chiamata che rappresenta decimi di secondo (64 significa 6,4 secondi). Il protocollo specifica solo che il parametro viene scambiato, non specifica come viene calcolato. Il modo in cui vengono calcolati i valori per PPD dipende dall'implementazione e non deve essere variabile (sono consentiti timeout statici). Il PPD deve essere scambiato (MUST) nelle sequenze di connessione chiamata, anche se rimane costante in un'implementazione. Un possibile modo per calcolare il PPD è:

PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate
PPD = PPD' + PACFudge

Dove:

  • Header è la dimensione totale delle intestazioni IP e GRE, che è 36
  • MTU è l'MTU complessivo per il collegamento internetwork tra PAC e PNS
  • WindowSize rappresenta il numero di pacchetti nella finestra scorrevole ed è dipendente dall'implementazione
  • La costante 8 converte ottetti in bit (supponendo che ConnectRate sia in bit al secondo)
  • PACFudge non è richiesto ma può essere utilizzato per tenere conto dell'overhead di elaborazione complessivo del PAC

Il valore di PPD viene utilizzato per inizializzare l'algoritmo adattivo con il valore RTT[n-1] iniziale.

4.4.1. Calcolo del timeout di riconoscimento adattivo (Calculating Adaptive Acknowledgment Time-Out)​

Dobbiamo ancora decidere quanto tempo concedere per il ritorno dei riconoscimenti. Se il timeout è impostato troppo alto, potremmo attendere inutilmente a lungo per i pacchetti persi. Se il timeout è troppo breve, potremmo andare in timeout appena prima dell'arrivo del riconoscimento. Il timeout di riconoscimento dovrebbe anche essere ragionevole e reattivo alle condizioni di rete variabili.

L'algoritmo adattivo suggerito dettagliato di seguito si basa sull'implementazione TCP 1989 ed è spiegato in [11]. 'n' significa il pacchetto corrente e 'n-1' significa il pacchetto precedente:

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])

Dove:

  • g è il fattore di guadagno (valore raccomandato 0.125)
  • h è il fattore di guadagno della deviazione (valore raccomandato 0.25)
  • f è il fattore moltiplicatore della deviazione (valore raccomandato 4)

4.4.2. Controllo congestione: Regolazione per timeout (Congestion Control: Adjusting for Time-Out)​

Questa sezione descrive come viene modificato il calcolo di ATO nel caso in cui si verifichi un timeout. Quando si verifica un timeout, il valore del timeout dovrebbe essere regolato rapidamente verso l'alto. Sebbene i pacchetti GRE non vengano ritrasmessi quando si verifica un timeout, il timeout dovrebbe essere regolato verso un limite massimo. Per compensare i ritardi temporali internetwork variabili, deve essere impiegata una strategia per aumentare il timeout quando scade (si noti che oltre ad aumentare il timeout, stiamo anche restringendo la dimensione della finestra come descritto nella sezione successiva).

Per un intervallo in cui si verifica un timeout:

ATO[n] = MIN(2 * ATO[n-1], MaxTimeOut)

Dove MaxTimeOut è il valore di timeout massimo configurato dall'amministratore.

Ultimo aggiornamento il