RFC 2637 - Protocollo di tunneling punto a punto (PPTP)
- Stato: Informational
- Pubblicato: July 1999
- Stream: IETF
- Errata: Nessun errata
Sommario (Abstract)
Questo documento specifica un protocollo che consente al protocollo punto a punto (Point-to-Point Protocol, PPP) di essere veicolato attraverso un tunnel su una rete IP. PPTP non specifica alcuna modifica al protocollo PPP stesso, ma descrive piuttosto un nuovo mezzo per trasportare PPP. Un'architettura client-server è definita al fine di disaccoppiare le funzioni che esistono negli attuali server di accesso alla rete (Network Access Server, NAS) e supportare le reti private virtuali (Virtual Private Network, VPN). Il server di rete PPTP (PNS) è progettato per funzionare su un sistema operativo generico, mentre il client, denominato concentratore di accesso PPTP (PAC), opera su una piattaforma di accesso remoto. PPTP specifica un protocollo di controllo delle chiamate e di gestione che consente al server di controllare l'accesso per le chiamate a commutazione di circuito in ingresso provenienti da PSTN o ISDN o di avviare connessioni a commutazione di circuito in uscita. PPTP utilizza un meccanismo GRE (Generic Routing Encapsulation) migliorato per fornire un servizio di datagramma incapsulato con controllo di flusso e congestione per il trasporto di pacchetti PPP.
Indice (Contents)
- 1. Introduction (Introduzione)
- 1.1 Protocol Goals and Assumptions (Obiettivi e ipotesi del protocollo)
- 1.2 Terminology (Terminologia)
- 1.3 Protocol Overview (Panoramica del protocollo)
- 1.4 Message Format and Protocol Extensibility (Formato dei messaggi ed estensibilità del protocollo)
- 2. Control Connection Protocol Specification (Specifica del protocollo di connessione di controllo)
- 2.1-2.16 Definizioni dei tipi di messaggi
- 3. Control Connection Protocol Operation (Operazione del protocollo di connessione di controllo)
- 3.1 Control Connection States (Stati di connessione di controllo)
- 3.2 Call States (Stati di chiamata)
- 4. Tunnel Protocol Operation (Operazione del protocollo tunnel)
- 4.1 Enhanced GRE Header (Intestazione GRE migliorata)
- 4.2 Sliding Window Protocol (Protocollo a finestra scorrevole)
- 4.3 Out-of-sequence Packets (Pacchetti fuori sequenza)
- 4.4 Acknowledgment Time-Outs (Timeout di acknowledgment)
- 5. Security Considerations (Considerazioni sulla sicurezza)
- 6. Authors' Addresses (Indirizzi degli autori)
- 7. References (Riferimenti)
- 8. Full Copyright Statement (Dichiarazione completa sul copyright)
Risorse correlate
- Testo originale ufficiale: RFC 2637
- Pagina ufficiale: RFC 2637 DataTracker
- Errata: RFC Editor Errata
1. Introduzione (Introduction)
PPTP consente di separare le funzioni esistenti del server di accesso alla rete (Network Access Server, NAS) utilizzando un'architettura client-server. Tradizionalmente, le seguenti funzioni sono implementate da un NAS:
-
Interfaccia fisica nativa con PSTN o ISDN e controllo di modem esterni o adattatori terminali
Un NAS può interfacciarsi direttamente con un circuito analogico o digitale di telecomunicazione o connettersi tramite un modem esterno o un adattatore terminale. Il controllo di una connessione a commutazione di circuito viene realizzato tramite il controllo del modem o i protocolli di controllo delle chiamate DSS1 ISDN.
Il NAS, in combinazione con il modem o gli adattatori terminali, può eseguire l'adattamento della velocità, la conversione da analogico a digitale, la conversione da sincrono ad asincrono o numerose altre modifiche ai flussi di dati.
-
Terminazione logica di una sessione Link Control Protocol (LCP) del Point-to-Point Protocol (PPP)
-
Partecipazione ai protocolli di autenticazione PPP [3,9,10]
-
Aggregazione dei canali e gestione dei bundle per il PPP Multilink Protocol
-
Terminazione logica di vari protocolli di controllo di rete (Network Control Protocol, NCP) PPP
-
Routing multiprotocollo e bridging tra le interfacce NAS
PPTP divide queste funzioni tra PAC e PNS. Il PAC è responsabile delle funzioni 1, 2 e possibilmente 3. Il PNS può essere responsabile della funzione 3 ed è responsabile delle funzioni 4, 5 e 6. Il protocollo utilizzato per trasportare le unità dati del protocollo (Protocol Data Units, PDU) PPP tra PAC e PNS, nonché il controllo e la gestione delle chiamate, è gestito da PPTP.
Il disaccoppiamento delle funzioni NAS offre questi vantaggi:
Gestione flessibile degli indirizzi IP. Gli utenti dial-in possono mantenere un singolo indirizzo IP quando si connettono a diversi PAC, purché siano serviti da un PNS comune. Se una rete aziendale utilizza indirizzi non registrati, un PNS associato all'azienda assegna indirizzi significativi per la rete privata.
Supporto di protocolli non-IP per reti dial-up dietro reti IP. Questo consente, ad esempio, di creare tunnel per AppleTalk e IPX attraverso un provider solo IP. Il PAC non deve essere in grado di elaborare questi protocolli.
Soluzione al problema dello "splitting del gruppo di caccia multilink". Il PPP multilink (Multilink PPP), tipicamente utilizzato per aggregare i canali B ISDN, richiede che tutti i canali che compongono un bundle multilink siano raggruppati su un singolo NAS. Poiché un bundle PPP multilink può essere gestito da un singolo PNS, i canali che compongono il bundle possono essere distribuiti su più PAC.
1.1. Obiettivi e ipotesi del protocollo (Protocol Goals and Assumptions)
Il protocollo PPTP è implementato solo dal PAC e dal PNS. Nessun altro sistema deve essere a conoscenza di PPTP. Le reti dial-up possono essere connesse a un PAC senza essere a conoscenza di PPTP. Il software client PPP standard dovrebbe (SHOULD) continuare a funzionare su collegamenti PPP veicolati tramite tunnel.
PPTP può anche essere utilizzato per veicolare una sessione PPP attraverso una rete IP. In questa configurazione, il tunnel PPTP e la sessione PPP vengono eseguiti tra le stesse due macchine, con il chiamante che agisce come PNS.
Si prevede che ci sarà una relazione molti-a-molti tra PAC e PNS. Un PAC può fornire servizi a molti PNS. Ad esempio, un provider di servizi Internet può scegliere di supportare PPTP per un numero di client di rete privata e creare VPN per loro. Ogni rete privata può gestire uno o più PNS. Un singolo PNS può associarsi a molti PAC per concentrare il traffico proveniente da un gran numero di siti geograficamente dispersi.
PPTP utilizza una versione estesa di GRE per trasportare i pacchetti PPP degli utenti. Questi miglioramenti consentono di fornire un controllo di flusso e congestione a basso livello sui tunnel utilizzati per trasportare i dati utente tra PAC e PNS. Questo meccanismo consente un uso efficiente della larghezza di banda disponibile per i tunnel ed evita ritrasmissioni non necessarie e overflow del buffer. PPTP non detta gli algoritmi particolari da utilizzare per questo controllo a basso livello, ma definisce i parametri che devono essere comunicati per consentire il funzionamento di tali algoritmi. Gli algoritmi suggeriti sono inclusi nella sezione 4.
1.2. Terminologia (Terminology)
Canale analogico (Analog Channel)
Un percorso di comunicazione a commutazione di circuito destinato a trasportare audio a 3,1 kHz in ciascuna direzione.
Canale digitale (Digital Channel)
Un percorso di comunicazione a commutazione di circuito destinato a trasportare informazioni digitali in ciascuna direzione.
Chiamata (Call)
Una connessione o tentativo di connessione tra due endpoint terminali su una PSTN o ISDN, ad esempio una chiamata telefonica tra due modem.
Connessione di controllo (Control Connection)
Viene creata una connessione di controllo per ogni coppia PAC-PNS e opera su TCP. La connessione di controllo gestisce gli aspetti del tunnel e delle sessioni assegnate al tunnel.
Utente dial-up (Dial User)
Un sistema terminale o router collegato a una PSTN o ISDN su richiesta, che è l'iniziatore o il destinatario di una chiamata.
Server di accesso alla rete (Network Access Server, NAS)
Un dispositivo che fornisce accesso di rete temporaneo e su richiesta agli utenti. Questo accesso è punto a punto utilizzando linee PSTN o ISDN.
Concentratore di accesso PPTP (PPTP Access Concentrator, PAC)
Un dispositivo collegato a una o più linee PSTN o ISDN capace di operazioni PPP e di gestione del protocollo PPTP. Il PAC deve implementare solo TCP/IP per passare il traffico a uno o più PNS. Può anche creare tunnel per protocolli non-IP.
Server di rete PPTP (PPTP Network Server, PNS)
Un PNS è progettato per funzionare su piattaforme di calcolo/server generiche. Il PNS gestisce il lato server del protocollo PPTP. Poiché PPTP si basa completamente su TCP/IP ed è indipendente dall'hardware di interfaccia, il PNS può utilizzare qualsiasi combinazione di hardware di interfaccia IP, inclusi dispositivi LAN e WAN.
Sessione (Session)
PPTP è orientato alla connessione. Il PNS e il PAC mantengono lo stato per ogni utente connesso a un PAC. Una sessione viene creata quando viene tentata una connessione PPP end-to-end tra un utente dial-up e il PNS. I datagrammi relativi a una sessione vengono inviati attraverso il tunnel tra il PAC e il PNS.
Tunnel
Un tunnel è definito da una coppia PNS-PAC. Il protocollo tunnel è definito da una versione modificata di GRE. Il tunnel trasporta i datagrammi PPP tra il PAC e il PNS. Più sessioni sono multiplexate su un singolo tunnel. Una connessione di controllo operante su TCP controlla l'instaurazione, il rilascio e la manutenzione delle sessioni e del tunnel stesso.
1.3. Panoramica del protocollo (Protocol Overview)
PPTP ha due componenti paralleli: 1) una connessione di controllo tra ogni coppia PAC-PNS che opera su TCP e 2) un tunnel IP che opera tra la stessa coppia PAC-PNS, utilizzato per trasportare pacchetti PPP incapsulati in GRE per le sessioni utente tra la coppia.
1.3.1. Panoramica della connessione di controllo (Control Connection Overview)
Prima che possa avvenire il tunneling PPP tra un PAC e un PNS, deve essere stabilita una connessione di controllo tra di loro. La connessione di controllo è una sessione TCP standard attraverso la quale vengono trasmesse le informazioni di controllo e gestione delle chiamate PPTP. La sessione di controllo è logicamente associata, ma separata, dalle sessioni che vengono veicolate attraverso un tunnel PPTP. Per ogni coppia PAC-PNS esistono sia un tunnel che una connessione di controllo. La connessione di controllo è responsabile dell'instaurazione, gestione e rilascio delle sessioni trasportate attraverso il tunnel. È il mezzo attraverso cui un PNS viene notificato di una chiamata in arrivo presso un PAC associato, nonché il mezzo attraverso cui un PAC riceve istruzioni per effettuare una chiamata in uscita.
Una connessione di controllo può essere stabilita sia dal PNS che dal PAC. Dopo l'instaurazione della connessione TCP richiesta, il PNS e il PAC stabiliscono la connessione di controllo utilizzando i messaggi Start-Control-Connection-Request e -Reply. Questi messaggi vengono utilizzati anche per scambiare informazioni sulle capacità operative di base del PAC e del PNS. Una volta stabilita la connessione di controllo, il PAC o il PNS può avviare sessioni richiedendo chiamate in uscita o rispondendo a richieste in arrivo. La connessione di controllo può comunicare cambiamenti nelle caratteristiche operative di una sessione utente individuale con un messaggio Set-Link-Info. Le sessioni individuali possono essere rilasciate sia dal PAC che dal PNS, anche tramite messaggi di connessione di controllo.
La connessione di controllo stessa viene mantenuta tramite messaggi echo keep-alive. Ciò garantisce che un guasto di connettività tra il PNS e il PAC possa essere rilevato in modo tempestivo. Altri guasti possono essere segnalati tramite il messaggio Wan-Error-Notify, anch'esso sulla connessione di controllo.
È previsto che la connessione di controllo trasporterà anche messaggi relativi alla gestione in futuro, come un messaggio che consente al PNS di richiedere lo stato di un determinato PAC; questi tipi di messaggi non sono ancora stati definiti.
1.3.2. Panoramica del protocollo tunnel (Tunnel Protocol Overview)
PPTP richiede l'instaurazione di un tunnel per ogni coppia PNS-PAC comunicante. Questo tunnel viene utilizzato per trasportare tutti i pacchetti PPP di sessione utente per le sessioni che coinvolgono una determinata coppia PNS-PAC. Una chiave presente nell'intestazione GRE indica a quale sessione appartiene un particolare pacchetto PPP.
In questo modo, i pacchetti PPP vengono multiplexati e demultiplexati su un singolo tunnel tra una determinata coppia PNS-PAC. Il valore da utilizzare nel campo chiave viene stabilito dalla procedura di instaurazione della chiamata che avviene sulla connessione di controllo.
L'intestazione GRE contiene anche informazioni di acknowledgment e sequenziamento utilizzate per eseguire un certo livello di controllo della congestione e rilevamento degli errori sul tunnel. Ancora una volta, la connessione di controllo viene utilizzata per determinare i parametri di velocità e buffering che vengono utilizzati per regolare il flusso di pacchetti PPP per una particolare sessione sul tunnel. PPTP non specifica gli algoritmi particolari da utilizzare per il controllo della congestione e il controllo del flusso. Gli algoritmi suggeriti per la determinazione dei timeout adattativi per recuperare da dati persi o acknowledgment sul tunnel sono inclusi nella sezione 4.4 di questo documento.
1.4. Formato dei messaggi ed estensibilità del protocollo (Message Format and Protocol Extensibility)
PPTP definisce un insieme di messaggi inviati come dati TCP sulla connessione di controllo tra un PNS e un dato PAC. La sessione TCP per la connessione di controllo viene stabilita avviando una connessione TCP alla porta 1723. La porta di origine è assegnata a qualsiasi numero di porta non utilizzato.
Ogni messaggio di connessione di controllo PPTP inizia con una porzione di intestazione fissa di 8 ottetti. Questa intestazione fissa contiene quanto segue: la lunghezza totale del messaggio, l'indicatore del tipo di messaggio PPTP e un "Magic Cookie".
Due tipi di messaggi di connessione di controllo sono indicati dal campo Tipo di messaggio PPTP:
- 1 - Messaggio di controllo (Control Message)
- 2 - Messaggio di gestione (Management Message)
I messaggi di gestione non sono attualmente definiti.
Il Magic Cookie viene sempre inviato come la costante 0x1A2B3C4D. Il suo scopo fondamentale è consentire al ricevitore di assicurarsi di essere correttamente sincronizzato con il flusso di dati TCP. Non dovrebbe (SHOULD NOT) essere utilizzato come mezzo per risincronizzare il flusso di dati TCP nel caso in cui un trasmettitore emetta un messaggio formattato in modo errato. La perdita di sincronizzazione deve (MUST) comportare la chiusura immediata della sessione TCP della connessione di controllo.
Per chiarezza, tutti i modelli di messaggi di connessione di controllo nella sezione successiva includono l'intestazione completa del messaggio di connessione di controllo PPTP. I numeri preceduti da 0x sono valori esadecimali.
I messaggi di controllo attualmente definiti, raggruppati per funzione, sono:
Gestione della connessione di controllo (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)
Gestione delle chiamate (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)
Segnalazione errori (Error Reporting)
- WAN-Error-Notify (14)
Controllo di sessione PPP (PPP Session Control)
- Set-Link-Info (15)
I messaggi Start-Control-Connection-Request e -Reply determinano quale versione del protocollo di connessione di controllo verrà utilizzata. Il campo del numero di versione trasportato in questi messaggi è costituito da un numero di versione nell'ottetto superiore e un numero di revisione nell'ottetto inferiore. La gestione delle versioni è descritta nella sezione 2. Il valore corrente del campo del numero di versione è 0x0100 per la versione 1, revisione 0.
L'uso dell'intestazione di tipo GRE per l'incapsulamento dei pacchetti utente PPP è specificato nella sezione 4.1.
L'MTU per i pacchetti dati utente incapsulati in GRE è di 1532 ottetti, senza includere le intestazioni IP e GRE.
2. Specifica del protocollo di connessione di controllo (Control Connection Protocol Specification)
I messaggi di connessione di controllo vengono utilizzati per stabilire e cancellare le sessioni utente. Il primo insieme di messaggi di connessione di controllo viene utilizzato per mantenere la connessione di controllo stessa. La connessione di controllo viene avviata dal PNS o dal PAC dopo aver stabilito la connessione TCP sottostante. La procedura e le informazioni di configurazione necessarie per determinare quali connessioni TCP vengono stabilite non sono coperte da questo protocollo.
I seguenti messaggi di connessione di controllo vengono tutti inviati come dati utente sulla connessione TCP stabilita tra una determinata coppia PNS-PAC. Si noti che è stata prestata attenzione per garantire che tutti i valori di parola (2 ottetti) e parola lunga (4 ottetti) inizino su confini appropriati. Tutti i dati vengono inviati in ordine di rete (ottetti di ordine superiore per primi). Tutti i campi "riservati" devono (MUST) essere inviati come valori 0 per consentire l'estensibilità del protocollo.
2.1. Start-Control-Connection-Request (Richiesta di avvio connessione di controllo)
Lo Start-Control-Connection-Request è un messaggio di controllo PPTP utilizzato per stabilire la connessione di controllo tra un PNS e un PAC. Ogni coppia PNS-PAC richiede che venga stabilita una connessione di controllo dedicata. Una connessione di controllo deve (MUST) essere stabilita prima che possano essere emessi altri messaggi PPTP. L'instaurazione della connessione di controllo può essere avviata dal PNS o dal PAC. Una procedura che gestisce l'occorrenza di una collisione tra le Start-Control-Connection-Request di PNS e PAC è descritta nella sezione 3.1.3.
Formato del messaggio
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descrizione dei campi
Length (Lunghezza)
Lunghezza totale in ottetti di questo messaggio PPTP, inclusa l'intera intestazione PPTP.
PPTP Message Type (Tipo di messaggio PPTP)
1 per messaggio di controllo.
Magic Cookie
0x1A2B3C4D. Questo valore costante viene utilizzato come controllo di sanità sui messaggi ricevuti (vedere sezione 1.4).
Control Message Type (Tipo di messaggio di controllo)
1 per Start-Control-Connection-Request.
Reserved0 (Riservato 0)
Questo campo deve (MUST) essere 0.
Protocol Version (Versione del protocollo)
La versione del protocollo PPTP che il mittente desidera utilizzare.
Reserved1 (Riservato 1)
Questo campo deve (MUST) essere 0.
Framing Capabilities (Capacità di frame)
Un insieme di bit che indica il tipo di framing che il mittente di questo messaggio può fornire. Le impostazioni dei bit attualmente definite sono:
- 1 - Framing asincrono supportato (Asynchronous Framing supported)
- 2 - Framing sincrono supportato (Synchronous Framing supported)
Bearer Capabilities (Capacità bearer)
Un insieme di bit che indica le capacità bearer che il mittente di questo messaggio può fornire. Le impostazioni dei bit attualmente definite sono:
- 1 - Accesso analogico supportato (Analog access supported)
- 2 - Accesso digitale supportato (Digital access supported)
Maximum Channels (Canali massimi)
Il numero totale di sessioni PPP individuali che questo PAC può supportare. Nelle Start-Control-Connection-Request emesse dal PNS, questo valore dovrebbe (SHOULD) essere impostato a 0. Deve (MUST) essere ignorato dal PAC.
Firmware Revision (Revisione firmware)
Quando emesso dal PAC, questo campo contiene il numero di revisione del firmware del PAC emittente. Quando emesso dal PNS, contiene la versione del driver PPTP del PNS.
Host Name (Nome host)
Un campo di 64 ottetti contenente il nome DNS del PAC o PNS emittente. Se la lunghezza è inferiore a 64 ottetti, il resto di questo campo dovrebbe (SHOULD) essere riempito con ottetti di valore 0.
Vendor Name (Nome fornitore)
Un campo di 64 ottetti contenente una stringa specifica del fornitore che descrive il tipo di PAC utilizzato, o il tipo di software PNS utilizzato se questa richiesta viene emessa dal PNS. Se la lunghezza è inferiore a 64 ottetti, il resto di questo campo dovrebbe (SHOULD) essere riempito con ottetti di valore 0.
2.2. Start-Control-Connection-Reply (Risposta di avvio connessione di controllo)
Lo Start-Control-Connection-Reply è un messaggio di controllo PPTP inviato in risposta a un messaggio Start-Control-Connection-Request ricevuto. Questo messaggio contiene un codice di risultato che indica il risultato del tentativo di instaurazione della connessione di controllo.
Formato del messaggio
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descrizione dei campi
Length (Lunghezza)
Lunghezza totale in ottetti di questo messaggio PPTP, inclusa l'intera intestazione PPTP.
PPTP Message Type (Tipo di messaggio PPTP)
1 per messaggio di controllo.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Tipo di messaggio di controllo)
2 per Start-Control-Connection-Reply.
Reserved0 (Riservato 0)
Questo campo deve (MUST) essere 0.
Protocol Version (Versione del protocollo)
La versione del protocollo PPTP che il mittente desidera utilizzare.
Result Code (Codice di risultato)
Indica il risultato del tentativo di stabilire il canale di comando. I valori del codice di risultato attualmente validi sono:
- 1 - Stabilimento del canale riuscito
- 2 - Errore generale -- Il codice di errore indica il problema
- 3 - Il canale di comando esiste già
- 4 - Il richiedente non è autorizzato a stabilire un canale di comando
- 5 - La versione del protocollo del richiedente non è supportata
Error Code (Codice di errore)
Questo campo è impostato a 0 a meno che non esista un "Errore generale", nel qual caso il codice di risultato è impostato a 2 e questo campo è impostato al valore corrispondente alla condizione di errore generale come specificato nella sezione 2.2.
Framing Capabilities (Capacità di frame)
Un insieme di bit che indica il tipo di framing che il mittente di questo messaggio può fornire. Le impostazioni dei bit attualmente definite sono:
- 1 - Framing asincrono supportato
- 2 - Framing sincrono supportato
Bearer Capabilities (Capacità bearer)
Un insieme di bit che indica le capacità bearer che il mittente di questo messaggio può fornire. Le impostazioni dei bit attualmente definite sono:
- 1 - Accesso analogico supportato
- 2 - Accesso digitale supportato
Maximum Channels (Canali massimi)
Il numero totale di sessioni PPP individuali che questo PAC può supportare. Nelle Start-Control-Connection-Reply emesse dal PNS, questo valore dovrebbe (SHOULD) essere impostato a 0 e deve (MUST) essere ignorato dal PAC. Il PNS non deve (MUST NOT) utilizzare questo valore per tentare di tracciare il numero rimanente di sessioni PPP che il PAC consentirà.
Firmware Revision (Revisione firmware)
Questo campo contiene il numero di revisione del firmware del PAC emittente, o la versione del driver PPTP del PNS se emesso dal PNS.
Host Name (Nome host)
Un campo di 64 ottetti contenente il nome DNS del PAC o PNS emittente.
Vendor String (Stringa fornitore)
Un campo di 64 ottetti contenente una stringa specifica del fornitore.
2.3. Stop-Control-Connection-Request (Richiesta di arresto connessione di controllo)
Lo Stop-Control-Connection-Request è un messaggio di controllo PPTP inviato da un peer di una connessione di controllo PAC-PNS per informare l'altro peer che la connessione di controllo dovrebbe essere chiusa. Oltre alla chiusura della connessione di controllo, tutte le chiamate utente attive vengono implicitamente cancellate. Il motivo dell'emissione di questa richiesta è indicato nel campo Reason.
Formato del messaggio
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descrizione dei campi
Length (Lunghezza)
Lunghezza totale in ottetti di questo messaggio PPTP, inclusa l'intera intestazione PPTP.
PPTP Message Type (Tipo di messaggio PPTP)
1 per messaggio di controllo.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Tipo di messaggio di controllo)
3 per Stop-Control-Connection-Request.
Reserved0 (Riservato 0)
Questo campo deve (MUST) essere 0.
Reason (Motivo)
Indica il motivo della chiusura della connessione di controllo. I valori di motivo attualmente validi sono:
- 1 (None) - Richiesta generale di cancellazione della connessione di controllo
- 2 (Stop-Protocol) - Impossibile supportare la versione del protocollo del peer
- 3 (Stop-Local-Shutdown) - Il richiedente è in fase di arresto
Reserved1, Reserved2 (Riservato 1, 2)
Questi campi devono (MUST) essere 0.
2.4. Stop-Control-Connection-Reply (Risposta di arresto connessione di controllo)
Lo Stop-Control-Connection-Reply è un messaggio di controllo PPTP inviato da un peer di una connessione di controllo PAC-PNS alla ricezione di uno Stop-Control-Connection-Request dall'altro peer.
Formato del messaggio
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descrizione dei campi
Length (Lunghezza)
Lunghezza totale in ottetti di questo messaggio PPTP, inclusa l'intera intestazione PPTP.
PPTP Message Type (Tipo di messaggio PPTP)
1 per messaggio di controllo.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Tipo di messaggio di controllo)
4 per Stop-Control-Connection-Reply.
Reserved0 (Riservato 0)
Questo campo deve (MUST) essere 0.
Result Code (Codice di risultato)
Indica il risultato del tentativo di chiudere la connessione di controllo. I valori del codice di risultato attualmente validi sono:
- 1 (OK) - Connessione di controllo chiusa
- 2 (General Error) - Connessione di controllo non chiusa per il motivo indicato nel codice di errore
Error Code (Codice di errore)
Questo campo è impostato a 0 a meno che non esista un "Errore generale", nel qual caso il codice di risultato è impostato a 2 e questo campo è impostato al valore corrispondente alla condizione di errore generale come specificato nella sezione 2.2.
Reserved1 (Riservato 1)
Questo campo deve (MUST) essere 0.
2.5. Echo-Request (Richiesta di echo)
L'Echo-Request è un messaggio di controllo PPTP inviato da uno dei peer di una connessione di controllo PAC-PNS. Questo messaggio di controllo viene utilizzato come "mantenimento in vita" per la connessione di controllo. Il peer ricevente emette un Echo-Reply per ogni Echo-Request ricevuto. Come specificato nella sezione 3.1.4, se il mittente non riceve un Echo-Reply in risposta a un Echo-Request, alla fine cancellerà la connessione di controllo.
Formato del messaggio
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descrizione dei campi
Length (Lunghezza)
Lunghezza totale in ottetti di questo messaggio PPTP, inclusa l'intera intestazione PPTP.
PPTP Message Type (Tipo di messaggio PPTP)
1 per messaggio di controllo.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Tipo di messaggio di controllo)
5 per Echo-Request.
Reserved0 (Riservato 0)
Questo campo deve (MUST) essere 0.
Identifier (Identificatore)
Valore a 32 bit restituito nell'Echo-Reply corrispondente.
2.6. Echo-Reply (Risposta di echo)
L'Echo-Reply è un messaggio di controllo PPTP inviato da uno dei peer di una connessione di controllo PAC-PNS in risposta alla ricezione di un Echo-Request.
Formato del messaggio
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descrizione dei campi
Length (Lunghezza)
Lunghezza totale in ottetti di questo messaggio PPTP, inclusa l'intera intestazione PPTP.
PPTP Message Type (Tipo di messaggio PPTP)
1 per messaggio di controllo.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Tipo di messaggio di controllo)
6 per Echo-Reply.
Reserved0 (Riservato 0)
Questo campo deve (MUST) essere 0.
Identifier (Identificatore)
Il contenuto del campo identificatore dell'Echo-Request ricevuto viene copiato in questo campo.
Result Code (Codice di risultato)
Indica il risultato della ricezione dell'Echo-Request. I valori del codice di risultato attualmente validi sono:
- 1 (OK) - L'Echo-Reply è valido
- 2 (General Error) - Echo-Request non accettato per il motivo indicato nel codice di errore
Error Code (Codice di errore)
Questo campo è impostato a 0 a meno che non esista una condizione di "Errore generale", nel qual caso il codice di risultato è impostato a 2 e questo campo è impostato al valore corrispondente alla condizione di errore generale come specificato nella sezione 2.2.
Reserved1 (Riservato 1)
Questo campo deve (MUST) essere 0.
2.7. Outgoing-Call-Request (Richiesta di chiamata in uscita)
L'Outgoing-Call-Request è un messaggio di controllo PPTP inviato dal PNS al PAC per indicare che deve essere stabilita una chiamata in uscita dal PAC. Questa richiesta fornisce al PAC le informazioni necessarie per effettuare la chiamata. Fornisce inoltre al PAC informazioni utilizzate per regolare la trasmissione dei dati al PNS per questa sessione una volta stabilita.
Formato del messaggio
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descrizione dei campi
Length (Lunghezza)
Lunghezza totale in ottetti di questo messaggio PPTP, inclusa l'intera intestazione PPTP.
PPTP Message Type (Tipo di messaggio PPTP)
1 per messaggio di controllo.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Tipo di messaggio di controllo)
7 per Outgoing-Call-Request.
Reserved0 (Riservato 0)
Questo campo deve (MUST) essere 0.
Call ID (ID chiamata)
Un identificatore univoco, unico per una particolare coppia PAC-PNS, assegnato dal PNS a questa sessione. Viene utilizzato per multiplexare e demultiplexare i dati inviati attraverso il tunnel tra il PNS e il PAC coinvolti in questa sessione.
Call Serial Number (Numero seriale chiamata)
Un identificatore assegnato dal PNS a questa sessione allo scopo di identificare questa particolare sessione nelle informazioni di sessione registrate. A differenza dell'ID chiamata, sia il PNS che il PAC associano lo stesso numero seriale di chiamata a una determinata sessione. La combinazione di indirizzo IP e numero seriale di chiamata dovrebbe (SHOULD) essere univoca.
Minimum BPS (BPS minimo)
La velocità di linea più bassa accettabile (in bit/secondo) per questa sessione.
Maximum BPS (BPS massimo)
La velocità di linea più alta accettabile (in bit/secondo) per questa sessione.
Bearer Type (Tipo bearer)
Un valore che indica la capacità bearer richiesta per questa chiamata in uscita. I valori attualmente definiti sono:
- 1 - Chiamata da effettuare su un canale analogico
- 2 - Chiamata da effettuare su un canale digitale
- 3 - La chiamata può essere effettuata su qualsiasi tipo di canale
Framing Type (Tipo di frame)
Un valore che indica il tipo di framing PPP da utilizzare per questa chiamata in uscita.
- 1 - Chiamata che utilizza framing asincrono
- 2 - Chiamata che utilizza framing sincrono
- 3 - La chiamata può utilizzare entrambi i tipi di framing
Packet Recv. Window Size (Dimensione finestra ricezione pacchetti)
Il numero di pacchetti di dati ricevuti che il PNS memorizzerà nel buffer per questa sessione.
Packet Processing Delay (Ritardo elaborazione pacchetti)
Una misura del ritardo di elaborazione dei pacchetti che potrebbe essere imposto ai dati inviati al PNS dal PAC. Questo valore è specificato in unità di 1/10 secondi. Per il PNS, questo numero dovrebbe essere molto piccolo.
Phone Number Length (Lunghezza numero telefonico)
Il numero effettivo di cifre valide nel campo Phone Number.
Reserved1 (Riservato 1)
Questo campo deve (MUST) essere 0.
Phone Number (Numero telefonico)
Il numero da comporre per stabilire la sessione in uscita. Se la lunghezza è inferiore a 64 ottetti, il resto di questo campo viene riempito con ottetti di valore 0.
Subaddress (Sottoindirizzo)
Un campo di 64 ottetti utilizzato per specificare una stringa di composizione aggiuntiva di informazioni di composizione. Se la lunghezza è inferiore a 64 ottetti, il resto di questo campo viene riempito con ottetti di valore 0.
2.8. Outgoing-Call-Reply (Risposta di chiamata in uscita)
L'Outgoing-Call-Reply è un messaggio di controllo PPTP inviato dal PAC al PNS in risposta a un messaggio Outgoing-Call-Request ricevuto. La risposta indica il risultato del tentativo di chiamata in uscita. Fornisce inoltre al PNS informazioni sui parametri particolari utilizzati per la chiamata e consente al PNS di regolare la trasmissione dei dati al PAC per questa sessione.
Formato del messaggio
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descrizione dei campi
Length (Lunghezza)
Lunghezza totale in ottetti di questo messaggio PPTP, inclusa l'intera intestazione PPTP.
PPTP Message Type (Tipo di messaggio PPTP)
1 per messaggio di controllo.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Tipo di messaggio di controllo)
8 per Outgoing-Call-Reply.
Reserved0 (Riservato 0)
Questo campo deve (MUST) essere 0.
Call ID (ID chiamata)
Identificatore univoco del peer (PAC) per questa sessione. Questo valore viene utilizzato come chiave di multiplexing in tutti i messaggi di controllo della chiamata successivi ricevuti dal peer.
Peer's Call ID (ID chiamata del peer)
Questo valore viene copiato dal campo Call ID dell'Outgoing-Call-Request corrispondente e viene utilizzato per associare questa risposta all'Outgoing-Call-Request inviato.
Result Code (Codice di risultato)
Indica il risultato del tentativo di chiamata in uscita. I valori del codice di risultato attualmente validi includono:
- 1 (Connected) - La chiamata è connessa
- 2 (General Error) - La chiamata in uscita non è stata completata a causa di un errore indicato nel codice di errore
- 3 (No Carrier) - La chiamata in uscita è fallita perché non è stata rilevata alcuna portante
- 4 (Busy) - La chiamata in uscita è fallita a causa di un segnale di occupato
- 5 (No Dial Tone) - La chiamata in uscita è fallita perché non è stato rilevato alcun tono di composizione
- 6 (Time-out) - La chiamata in uscita non è stata completata nel tempo assegnato
- 7 (Do Not Accept) - La chiamata in uscita non è accettata amministrativamente a livello locale
Error Code (Codice di errore)
Questo campo è impostato a 0 a meno che non esista una condizione di errore generale (come indicato dal codice di risultato 2).
Cause Code (Codice di causa)
Questo campo fornisce informazioni aggiuntive sul guasto riguardanti la disconnessione della chiamata. Il valore è generalmente fornito dalle strutture della rete telefonica.
Connect Speed (Velocità di connessione)
Indica la velocità effettiva (in bit/secondo) alla quale la chiamata è stata connessa.
Packet Recv. Window Size (Dimensione finestra ricezione pacchetti)
Il numero di pacchetti di dati ricevuti che il PAC memorizzerà nel buffer per questa sessione.
Packet Processing Delay (Ritardo elaborazione pacchetti)
Una misura del ritardo di elaborazione dei pacchetti che potrebbe essere imposto ai dati inviati dal PNS al PAC. Questo valore è specificato in unità di 1/10 secondi.
Physical Channel ID (ID canale fisico)
Questo campo è impostato dal PAC come identificatore univoco del canale fisico utilizzato per questa chiamata. Il suo valore viene utilizzato per scopi di registrazione e debug.
2.9. Incoming-Call-Request (Richiesta di chiamata in entrata)
L'Incoming-Call-Request è un messaggio di controllo PPTP inviato dal PAC al PNS per indicare che una chiamata in entrata è stata ricevuta dal PSTN ed è stata accettata localmente. Questa richiesta fornisce al PNS informazioni sul tipo di chiamata in entrata. Fornisce inoltre informazioni utilizzate per regolare la trasmissione dei dati dal PAC al PNS per questa sessione.
Formato del messaggio
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) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descrizione dei campi
Length (Lunghezza)
Lunghezza totale in ottetti di questo messaggio PPTP, inclusa l'intera intestazione PPTP.
PPTP Message Type (Tipo di messaggio PPTP)
1 per messaggio di controllo.
Magic Cookie
0x1A2B3C4D.
Control Message Type (Tipo di messaggio di controllo)
9 per Incoming-Call-Request.
Reserved0 (Riservato 0)
Questo campo deve (MUST) essere 0.
Call ID (ID chiamata)
Identificatore univoco assegnato dal PAC a questa sessione. Questo valore viene utilizzato come chiave di multiplexing in tutti i messaggi di controllo della chiamata successivi.
Call Serial Number (Numero seriale chiamata)
Identificatore assegnato dal PAC a questa sessione per identificare questa particolare sessione nelle informazioni di sessione registrate.
Bearer Type (Tipo bearer)
Valore che indica la capacità bearer della chiamata in entrata:
- 1 - Chiamata su canale analogico
- 2 - Chiamata su canale digitale
Physical Channel ID (ID canale fisico)
Identificatore univoco del canale fisico utilizzato dal PAC per questa chiamata.
Dialed Number Length (Lunghezza numero composto)
Numero effettivo di cifre valide nel campo Dialed Number.
Dialing Number Length (Lunghezza numero chiamante)
Numero effettivo di cifre valide nel campo Dialing Number.
Dialed Number (Numero composto)
Il numero chiamato. Campo di 64 ottetti, completato con zeri se necessario.
Dialing Number (Numero chiamante)
Il numero del chiamante. Campo di 64 ottetti, completato con zeri se necessario.
Subaddress (Sottoindirizzo)
Informazioni di composizione aggiuntive. Campo di 64 ottetti, completato con zeri se necessario.
2.10. Incoming-Call-Reply (Risposta di chiamata in entrata)
L'Incoming-Call-Reply è un messaggio di controllo PPTP inviato dal PNS al PAC in risposta a un Incoming-Call-Request ricevuto. La risposta indica se il PNS accetta la chiamata in entrata. Fornisce inoltre informazioni utilizzate per regolare la trasmissione dei dati dal PNS al PAC per questa sessione.
Formato del messaggio
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descrizione dei campi
Control Message Type (Tipo di messaggio di controllo)
10 per Incoming-Call-Reply.
Result Code (Codice di risultato)
Indica se il PNS accetta la chiamata in entrata:
- 1 (Connect) - Accetta la chiamata in entrata
- 2 (General Error) - La chiamata in entrata non è accettata a causa di un errore
- 3 (Do Not Accept) - La chiamata in entrata non è accettata amministrativamente
2.11. Incoming-Call-Connected (Chiamata in entrata connessa)
L'Incoming-Call-Connected è un messaggio di controllo PPTP inviato dal PAC al PNS che funge da conferma finale per una chiamata in entrata. Fornisce informazioni sui parametri della sessione stabilita.
Formato del messaggio
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descrizione dei campi
Control Message Type (Tipo di messaggio di controllo)
11 per Incoming-Call-Connected.
Framing Type (Tipo di frame)
Tipo di framing utilizzato per la chiamata in entrata:
- 1 - Framing asincrono
- 2 - Framing sincrono
2.12. Call-Clear-Request (Richiesta di cancellazione chiamata)
Il Call-Clear-Request è un messaggio di controllo PPTP inviato dal PNS al PAC per indicare che una chiamata specifica deve essere disconnessa.
Formato del messaggio
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 (Tipo di messaggio di controllo)
12 per Call-Clear-Request.
2.13. Call-Disconnect-Notify (Notifica di disconnessione chiamata)
Il Call-Disconnect-Notify è un messaggio di controllo PPTP inviato dal PAC al PNS per indicare che una chiamata è stata disconnessa.
Formato del messaggio
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 (Tipo di messaggio di controllo)
13 per Call-Disconnect-Notify.
2.14. WAN-Error-Notify (Notifica di errore WAN)
Il WAN-Error-Notify è un messaggio di controllo PPTP inviato dal PAC al PNS per indicare che si è verificata una condizione di errore WAN.
Formato del messaggio
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 (Tipo di messaggio di controllo)
14 per WAN-Error-Notify.
2.15. Set-Link-Info (Imposta informazioni collegamento)
Il Set-Link-Info è un messaggio di controllo PPTP inviato dal PNS al PAC per impostare i parametri di negoziazione PPP.
Formato del messaggio
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 (Tipo di messaggio di controllo)
15 per Set-Link-Info.
2.16. General Error Codes (Codici di errore generali)
I seguenti sono i valori dei codici di errore generali utilizzati nel campo Error Code di vari messaggi di controllo PPTP:
- 0 - None (Nessun errore)
- 1 - Not-Connected (Non connesso) - Non esiste alcuna connessione di controllo tra PAC e PNS
- 2 - Bad-Format (Formato errato) - Lunghezza del messaggio errata o formato del messaggio non corretto
- 3 - Bad-Value (Valore errato) - Il valore in un campo del messaggio è fuori intervallo o non valido
- 4 - No-Resource (Nessuna risorsa) - Risorse insufficienti per elaborare questo comando
- 5 - Bad-Call ID (ID chiamata errato) - Questo peer non conosce l'ID chiamata riferito
- 6 - PAC-Error (Errore PAC) - Errore generale riscontrato dal PAC
Istruzioni per l'uso dei codici di errore
Quando il campo Result Code di un messaggio di controllo è impostato per indicare un errore generale (solitamente valore 2), il campo Error Code deve essere utilizzato per fornire maggiori dettagli sulla natura di tale errore. Se il Result Code non indica un errore generale, il campo Error Code deve (MUST) essere impostato a 0.
Questi codici di errore sono destinati a fornire informazioni diagnostiche utili per scopi di debug e registrazione, aiutando a identificare e risolvere i problemi durante l'instaurazione e la manutenzione delle sessioni PPTP.
Sezione 2 completata - Questa sezione ha definito in dettaglio tutti i tipi di messaggio utilizzati nel protocollo di connessione di controllo PPTP, inclusi i messaggi di gestione della connessione di controllo (2.1-2.6), i messaggi di controllo delle chiamate (2.7-2.15) e i codici di errore generali (2.16).
3. Funzionamento del protocollo (Protocol Operation)
Questa sezione descrive i dettagli operativi del protocollo PPTP, inclusi gli stati di connessione di controllo, gli stati delle chiamate e i flussi di elaborazione per vari scenari operativi.
3.1. Stati di connessione di controllo (Control Connection States)
La connessione di controllo è una connessione TCP stabilita tra PAC e PNS per scambiare messaggi di controllo PPTP. L'instaurazione della connessione di controllo può essere avviata dal PAC o dal PNS.
Transizioni di stato di base
La connessione di controllo attraversa i seguenti stati di base:
- Idle (Inattivo) - Non esiste alcuna connessione di controllo
- Wait-Connect (Attesa connessione) - Richiesta di connessione inviata, in attesa di risposta
- Established (Stabilita) - Connessione di controllo stabilita con successo
- Wait-Disconnect (Attesa disconnessione) - Richiesta di disconnessione inviata, in attesa di conferma
3.1.1. Iniziatore della connessione di controllo (Control Connection Originator)
L'iniziatore della connessione di controllo (PAC o PNS) esegue le seguenti operazioni:
Stato: Idle (Inattivo)
- Azione: Stabilire una connessione TCP verso il peer
- Inviare: Start-Control-Connection-Request
- Transizione a: Stato Wait-Reply
Stato: Wait-Reply (Attesa risposta)
- Ricevere: Start-Control-Connection-Reply (Result = successo)
- Transizione a: Stato Established
- Ricevere: Start-Control-Connection-Reply (Result = errore)
- Chiudere la connessione TCP
- Transizione a: Stato Idle
- Timeout:
- Chiudere la connessione TCP
- Transizione a: Stato Idle
Stato: Established (Stabilita)
- Può inviare e ricevere: tutti i messaggi di controllo PPTP
- Inviare: Echo-Request (mantenimento in vita periodico)
- Ricevere: Echo-Reply (risposta al mantenimento in vita)
- Inviare: Stop-Control-Connection-Request (chiusura attiva)
- Transizione a: Stato Wait-Stop-Reply
Stato: Wait-Stop-Reply (Attesa risposta di arresto)
- Ricevere: Stop-Control-Connection-Reply
- Chiudere la connessione TCP
- Transizione a: Stato Idle
- Timeout:
- Chiudere la connessione TCP
- Transizione a: Stato Idle
3.1.2. Ricevitore della connessione di controllo (Control Connection Receiver)
Il ricevitore della connessione di controllo (PAC o PNS) esegue le seguenti operazioni:
Stato: Idle (Inattivo)
- Ascoltare: Porta TCP 1723
- Ricevere: Richiesta di connessione TCP
- Accettare la connessione TCP
- Transizione a: Stato Wait-Request
Stato: Wait-Request (Attesa richiesta)
- Ricevere: Start-Control-Connection-Request
- Validare: Versione del protocollo, parametri
- Se accettato:
- Inviare: Start-Control-Connection-Reply (Result = successo)
- Transizione a: Stato Established
- Se rifiutato:
- Inviare: Start-Control-Connection-Reply (Result = errore)
- Chiudere la connessione TCP
- Transizione a: Stato Idle
Stato: Established (Stabilita)
- Può inviare e ricevere: tutti i messaggi di controllo PPTP
- Ricevere: Echo-Request
- Inviare: Echo-Reply
- Ricevere: Stop-Control-Connection-Request
- Inviare: Stop-Control-Connection-Reply
- Chiudere la connessione TCP
- Transizione a: Stato Idle
3.1.3. Collisione di richiesta di inizializzazione Start Control Connection (Initiation Request Collision)
Quando PAC e PNS tentano simultaneamente di stabilire una connessione di controllo, può verificarsi una collisione. La gestione è la seguente:
- Rilevamento collisione: Quando una parte riceve un Start-Control-Connection-Request nello stato Wait-Reply
- Risoluzione collisione:
- Confrontare gli indirizzi IP (valore numerico)
- Parte con indirizzo IP inferiore: chiudere la propria connessione iniziata, accettare quella del peer
- Parte con indirizzo IP superiore: continuare la propria connessione iniziata, rifiutare quella del peer
- Risultato finale: Viene stabilita una sola connessione di controllo
3.1.4. Mantenimento in vita e timer (Keep Alives and Timers)
Per mantenere lo stato attivo della connessione di controllo, vengono implementati i seguenti meccanismi:
Meccanismo Echo-Request/Reply
- Frequenza di invio: Si raccomanda di inviare un Echo-Request ogni 60 secondi
- Gestione timeout: Se non si riceve un Echo-Reply entro 60 secondi, la connessione è considerata fallita
- Strategia di riprova: Può riprovare fino a 3 volte, con un intervallo di 60 secondi tra ogni tentativo
- Fallimento connessione: Dopo diversi timeout consecutivi, chiudere la connessione di controllo
Mantenimento in vita TCP
- Il meccanismo di mantenimento in vita del livello TCP può essere utilizzato come complemento
- Il meccanismo Echo del livello PPTP è richiesto (MUST)
Parametri timer
- Timeout instaurazione connessione di controllo: 60 secondi
- Intervallo mantenimento in vita: 60 secondi
- Timeout Echo-Reply: 60 secondi
- Timeout chiusura connessione di controllo: 60 secondi
Questi valori di timer sono raccomandazioni. Le implementazioni possono regolarli secondo necessità, ma devono assicurarsi che:
- L'intervallo di mantenimento in vita sia sufficientemente breve per rilevare tempestivamente i fallimenti di connessione
- I valori di timeout siano sufficientemente lunghi per evitare falsi positivi dovuti alla latenza di rete
3.2. Stati delle chiamate (Call States)
3.2.1. Considerazioni temporali (Timing Considerations)
A causa della natura in tempo reale della segnalazione telefonica, sia il PNS che il PAC dovrebbero essere implementati con architetture multi-thread in modo che i messaggi relativi a più chiamate non siano serializzati e bloccati. Il ritardo di transito tra PAC e PNS non dovrebbe superare 1 secondo (SHOULD NOT). I diagrammi di stato delle chiamate e delle connessioni non specificano esplicitamente le eccezioni causate dai timer. L'assunzione implicita è che poiché la connessione di controllo basata su TCP viene verificata con messaggi di mantenimento in vita, c'è meno necessità di mantenere timer rigorosi per i messaggi di controllo delle chiamate.
L'instaurazione di chiamate internazionali in uscita, incluse le sequenze di addestramento e negoziazione del modem, può richiedere più di 1 minuto, quindi l'uso di timer brevi è sconsigliato.
Se una transizione di stato non si verifica entro 1 minuto (tranne per le connessioni in stato inattivo o stabilito), l'integrità dell'elaborazione del protocollo tra i peer è sospetta e l'INTERA CONNESSIONE DI CONTROLLO (ENTIRE CONTROL CONNECTION) dovrebbe essere chiusa e riavviata. Tutti gli ID chiamata vengono logicamente rilasciati ogni volta che viene avviata una connessione di controllo. Questo aiuta presumibilmente anche a prevenire che le chiamate a pagamento vengano "perse" e mai cancellate.
3.2.2. Valori ID chiamata (Call ID Values)
Ogni peer assegna un valore ID chiamata a ogni sessione utente che richiede o accetta. Questo valore ID chiamata deve (MUST) essere univoco per il tunnel tra il PNS e il PAC a cui appartiene. I tunnel verso altri peer possono utilizzare lo stesso numero ID chiamata, quindi il ricevitore di un pacchetto su un tunnel deve associare una sessione utente a un particolare tunnel e ID chiamata. Si suggerisce che il numero di valori ID chiamata potenziali per ogni tunnel sia almeno il doppio del numero massimo di chiamate previste su un dato tunnel.
Una sessione è definita dalla tripla (PAC, PNS, Call ID).
3.2.3. Chiamate in entrata (Incoming Calls)
Un messaggio Incoming-Call-Request viene generato dal PAC quando una linea telefonica associata squilla. Il PAC seleziona un ID chiamata e un numero seriale e indica il tipo di portante della chiamata. I modem dovrebbero sempre indicare il tipo di chiamata analogica (SHOULD). Le chiamate ISDN dovrebbero indicare digitale quando viene utilizzato il servizio digitale senza restrizioni o l'adattamento di velocità e analogico se sono coinvolti modem digitali (SHOULD). Il numero chiamante, il numero chiamato e il sottoindirizzo possono essere inclusi nel messaggio se disponibili dalla rete telefonica.
Una volta che il PAC invia l'Incoming-Call-Request, attende una risposta dal PNS ma non risponde alla chiamata dalla rete telefonica. Il PNS può scegliere di non accettare la chiamata se:
- Non sono disponibili risorse per gestire più sessioni
- I campi del numero chiamato, chiamante o sottoindirizzo non indicano un utente autorizzato
- Il servizio portante non è autorizzato o non è supportato
Se il PNS sceglie di accettare la chiamata, risponde con un Incoming-Call-Reply che indica anche le dimensioni delle finestre (vedere sezione 4.2). Quando il PAC riceve l'Outgoing-Call-Reply, tenta di connettere la chiamata, supponendo che la parte chiamante non abbia riagganciato. Un messaggio finale di chiamata connessa dal PAC al PNS indica che gli stati di chiamata sia per il PAC che per il PNS dovrebbero entrare nello stato stabilito.
Quando il client in ingresso riattacca, la chiamata viene cancellata normalmente e il PAC invia un messaggio Call-Disconnect-Notify. Se il PNS desidera cancellare una chiamata, invia un messaggio Call-Clear-Request e quindi attende un Call-Disconnect-Notify.
3.2.3.1. Stati chiamata in entrata PAC (PAC Incoming Call States)
Gli stati associati al PAC per le chiamate in entrata sono:
idle (inattivo)
- Il PAC rileva una chiamata in entrata su una delle sue interfacce telefoniche. Tipicamente questo significa che una linea analogica sta squillando o un TE ISDN ha rilevato un messaggio SETUP Q.931 in entrata. Il PAC invia un messaggio Incoming-Call-Request e si sposta nello stato wait_reply.
wait_reply (attesa risposta)
- Il PAC riceve un messaggio Incoming-Call-Reply che indica non disponibilità ad accettare la chiamata (errore generale o non accettare) e ritorna allo stato inattivo. Se il messaggio di risposta indica che la chiamata è accettata, il PAC invia un messaggio Incoming-Call-Connected e entra nello stato stabilito.
established (stabilita)
- I dati vengono scambiati attraverso il tunnel. La chiamata può essere cancellata dopo:
- Un evento sulla connessione telefonica. Il PAC invia un messaggio Call-Disconnect-Notify
- Ricezione di un Call-Clear-Request. Il PAC invia un messaggio Call-Disconnect-Notify
- Un motivo locale. Il PAC invia un messaggio Call-Disconnect-Notify
3.2.3.2. Stati chiamata in entrata PNS (PNS Incoming Call States)
Gli stati associati al PNS per le chiamate in entrata sono:
idle (inattivo)
- Viene ricevuto un messaggio Incoming-Call-Request. Se la richiesta non è accettabile, viene inviato un Incoming-Call-Reply al PAC e il PNS rimane nello stato inattivo. Se il messaggio Incoming-Call-Request è accettabile, viene inviato un Incoming-Call-Reply che indica accettazione nel codice risultato. La sessione si sposta nello stato wait_connect.
wait_connect (attesa connessione)
- Se la sessione viene connessa sul PAC, il PAC invia un messaggio di connessione chiamata in entrata al PNS che quindi si sposta nello stato stabilito. Il PAC può inviare un Call-Disconnect-Notify per indicare che il chiamante in entrata non ha potuto essere connesso. Ciò potrebbe verificarsi, ad esempio, se un utente telefonico effettua accidentalmente una chiamata vocale standard a un PAC, causando un fallimento della negoziazione sul modem chiamato.
established (stabilita)
- La sessione viene terminata sia ricevendo un messaggio Call-Disconnect-Notify dal PAC, sia inviando un Call-Clear-Request. Una volta inviato un Call-Clear-Request, la sessione entra nello stato wait_disconnect.
wait_disconnect (attesa disconnessione)
- Una volta ricevuto un Call-Disconnect-Notify, la sessione ritorna allo stato inattivo.
3.2.4. Chiamate in uscita (Outgoing Calls)
I messaggi in uscita sono iniziati da un PNS e istruiscono un PAC a effettuare una chiamata su un'interfaccia telefonica. Ci sono solo due messaggi per le chiamate in uscita: Outgoing-Call-Request e Outgoing-Call-Reply. Il PNS invia un Outgoing-Call-Request specificando il numero di telefono della parte chiamata e il sottoindirizzo nonché i parametri di velocità e finestra. Il PAC deve (MUST) rispondere al messaggio Outgoing-Call-Request con un messaggio Outgoing-Call-Reply una volta che il PAC determina che:
- La chiamata è stata connessa con successo
- Si è verificato un fallimento della chiamata per motivi quali: nessuna interfaccia è disponibile per la chiamata in uscita, la parte chiamata è occupata o non risponde, o non viene rilevato alcun tono di selezione sull'interfaccia scelta per la composizione
3.2.4.1. Stati chiamata in uscita PAC (PAC Outgoing Call States)
Gli stati associati al PAC per le chiamate in uscita sono:
idle (inattivo)
- Outgoing-Call-Request ricevuto. Se ricevuto in errore, rispondere con un Outgoing-Call-Reply con condizione di errore impostata. Altrimenti, allocare il canale fisico per comporre. Effettuare la chiamata in uscita, attendere una connessione e spostarsi nello stato wait_cs_ans.
wait_cs_ans (attesa risposta commutazione circuito)
- Se la chiamata è incompleta, inviare un Outgoing-Call-Reply con un codice di errore diverso da zero. Se un timer scade su una chiamata in uscita, reinviare un Outgoing-Call-Reply con un codice di errore diverso da zero. Se viene stabilita una connessione a commutazione di circuito, inviare un Outgoing-Call-Reply che indica successo.
established (stabilita)
- Se viene ricevuto un Call-Clear-Request, la chiamata telefonica dovrebbe essere rilasciata (SHOULD) tramite meccanismi appropriati e un messaggio Call-Disconnect-Notify dovrebbe essere inviato (SHOULD) al PNS. Se la chiamata viene disconnessa dal client o dall'interfaccia telefonica, un messaggio Call-Disconnect-Notify dovrebbe essere inviato (SHOULD) al PNS.
3.2.4.2. Stati chiamata in uscita PNS (PNS Outgoing Call States)
Gli stati associati al PNS per le chiamate in uscita sono:
idle (inattivo)
- L'indicazione di apertura dell'applicazione di livello superiore causa l'invio di un Outgoing-Call-Request e lo spostamento allo stato wait_reply.
wait_reply (attesa risposta)
- Se viene ricevuto un Outgoing-Call-Reply con errore, tornare allo stato inattivo. Se viene ricevuto un Outgoing-Call-Reply riuscito, spostarsi allo stato stabilito. Se si verifica un'interruzione mentre si attende l'Outgoing-Call-Reply, inviare un Call-Clear-Request e spostarsi allo stato wait_disconnect.
established (stabilita)
- Se viene ricevuto un Call-Disconnect-Notify, spostarsi allo stato inattivo. Se si verifica una terminazione locale, inviare un Call-Clear-Request e spostarsi allo stato wait_disconnect.
wait_disconnect (attesa disconnessione)
- Se viene ricevuto un Call-Disconnect-Notify, spostarsi allo stato inattivo.
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.
5. Considerazioni sulla sicurezza (Security Considerations)
La sicurezza dei dati utente trasmessi sulla connessione PPP tunnelizzata è gestita da PPP, così come l'autenticazione dei peer PPP.
Poiché i messaggi del canale di controllo PPTP non sono né autenticati né protetti in integrità, potrebbe essere possibile per un attaccante dirottare la connessione TCP sottostante. È anche possibile fabbricare falsi messaggi del canale di controllo e alterare messaggi genuini in transito senza rilevamento.
I pacchetti GRE che formano il tunnel stesso non sono protetti crittograficamente. Poiché le negoziazioni PPP vengono effettuate sul tunnel, potrebbe essere possibile per un attaccante intercettare e modificare tali negoziazioni.
A meno che i dati del payload PPP non siano protetti crittograficamente, possono essere catturati e letti o modificati.
6. Indirizzi degli autori (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. Riferimenti (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. Dichiarazione completa di copyright (Full Copyright Statement)
Copyright (C) The Internet Society (1999). All Rights Reserved.
Questo documento e le sue traduzioni possono essere copiati e forniti ad altri, e opere derivate che commentano o spiegano altrimenti o assistono nella sua implementazione possono essere preparate, copiate, pubblicate e distribuite, in tutto o in parte, senza restrizioni di alcun tipo, purché l'avviso di copyright sopra riportato e questo paragrafo siano inclusi in tutte tali copie e opere derivate. Tuttavia, questo documento stesso non può essere modificato in alcun modo, come rimuovendo l'avviso di copyright o i riferimenti all'Internet Society o ad altre organizzazioni Internet, tranne quando necessario per lo scopo di sviluppare standard Internet, nel qual caso devono essere seguite le procedure di copyright definite nel processo degli standard Internet, o come richiesto per tradurlo in lingue diverse dall'inglese.
I permessi limitati concessi sopra sono perpetui e non saranno revocati dall'Internet Society o dai suoi successori o cessionari.
Questo documento e le informazioni in esso contenute sono fornite "COSÌ COME SONO" e l'Internet Society e l'Internet Engineering Task Force DECLINANO TUTTE LE GARANZIE, ESPRESSE O IMPLICITE, INCLUSE MA NON LIMITATE A QUALSIASI GARANZIA CHE L'USO DELLE INFORMAZIONI QUI CONTENUTE NON VIOLI ALCUN DIRITTO O QUALSIASI GARANZIA IMPLICITA DI COMMERCIABILITÀ O IDONEITÀ PER UN PARTICOLARE SCOPO.