Passa al contenuto principale

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:

  1. Idle (Inattivo) - Non esiste alcuna connessione di controllo
  2. Wait-Connect (Attesa connessione) - Richiesta di connessione inviata, in attesa di risposta
  3. Established (Stabilita) - Connessione di controllo stabilita con successo
  4. 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:

  1. Rilevamento collisione: Quando una parte riceve un Start-Control-Connection-Request nello stato Wait-Reply
  2. 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
  3. 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.
Ultimo aggiornamento il