5. Funzionamento del Protocollo
La configurazione necessaria per il tunneling di una sessione PPP con L2TP consiste in due passaggi: (1) stabilire la connessione di controllo per un tunnel e (2) stabilire una sessione attivata da una richiesta di chiamata in entrata o in uscita. Il tunnel e la connessione di controllo corrispondente DEVONO essere stabiliti prima che venga avviata una chiamata in entrata o in uscita. Una sessione L2TP DEVE essere stabilita prima che L2TP possa iniziare a tunnelizzare frame PPP. Più sessioni possono esistere attraverso un singolo tunnel e più tunnel possono esistere tra lo stesso LAC e LNS.
5.1 Stabilimento della Connessione di Controllo
La connessione di controllo è la connessione iniziale che deve essere raggiunta tra un LAC e un LNS prima che le sessioni possano essere stabilite. Lo stabilimento della connessione di controllo include la protezione dell'identità del peer, nonché l'identificazione della versione L2TP del peer, delle capacità di framing e bearer, ecc.
Viene utilizzato uno scambio di tre messaggi per configurare la connessione di controllo. Di seguito è riportato un tipico scambio di messaggi:
LAC or LNS LAC or LNS
---------- ----------
SCCRQ ->
<- SCCRP
SCCCN ->
<- ZLB ACK
Lo ZLB ACK viene inviato se non ci sono altri messaggi in attesa nella coda per quel peer.
5.1.1 Autenticazione del Tunnel
L2TP incorpora un sistema di autenticazione del tunnel semplice, opzionale, simile a CHAP [RFC1994] durante lo stabilimento della connessione di controllo. Se un LAC o LNS desidera autenticare l'identità del peer che sta contattando o da cui è contattato, un AVP Challenge viene incluso nel messaggio SCCRQ o SCCRP. Se un AVP Challenge viene ricevuto in un SCCRQ o SCCRP, un AVP Challenge Response DEVE essere inviato nel successivo SCCRP o SCCCN, rispettivamente. Se la risposta attesa e la risposta ricevuta da un peer non corrispondono, lo stabilimento del tunnel DEVE essere negato.
Per partecipare all'autenticazione del tunnel, DEVE esistere un singolo segreto condiviso tra il LAC e il LNS. Questo è lo stesso segreto condiviso utilizzato per l'occultamento degli AVP (vedere sezione 4.3). Vedere la sezione 4.4.3 per i dettagli sulla costruzione degli AVP Challenge e Response.
5.2 Stabilimento della Sessione
Dopo il successo dello stabilimento della connessione di controllo, possono essere create sessioni individuali. Ogni sessione corrisponde a un singolo flusso PPP tra il LAC e il LNS. A differenza dello stabilimento della connessione di controllo, lo stabilimento della sessione è direzionale rispetto al LAC e al LNS. Il LAC richiede al LNS di accettare una sessione per una chiamata in entrata, e il LNS richiede al LAC di accettare una sessione per effettuare una chiamata in uscita.
5.2.1 Stabilimento della Chiamata in Entrata
Viene impiegato uno scambio di tre messaggi per configurare la sessione. Di seguito è riportata una tipica sequenza di eventi:
LAC LNS
--- ---
(Call
Detected)
ICRQ ->
<- ICRP
ICCN ->
<- ZLB ACK
Lo ZLB ACK viene inviato se non ci sono altri messaggi in attesa nella coda per quel peer.
5.2.2 Stabilimento della Chiamata in Uscita
Viene impiegato uno scambio di tre messaggi per configurare la sessione. Di seguito è riportata una tipica sequenza di eventi:
LAC LNS
--- ---
<- OCRQ
OCRP ->
(Perform
Call
Operation)
OCCN ->
<- ZLB ACK
Lo ZLB ACK viene inviato se non ci sono altri messaggi in attesa nella coda per quel peer.
5.3 Inoltro dei Frame PPP
Una volta completato lo stabilimento del tunnel, i frame PPP dal sistema remoto vengono ricevuti al LAC, privati del CRC, del framing di collegamento e dei byte di trasparenza, incapsulati in L2TP e inoltrati sul tunnel appropriato. Il LNS riceve il pacchetto L2TP e elabora il frame PPP incapsulato come se fosse ricevuto su un'interfaccia PPP locale.
Il mittente di un messaggio associato a una particolare sessione e tunnel posiziona il Session ID e il Tunnel ID (specificati dal suo peer) nell'intestazione Session ID e Tunnel ID per tutti i messaggi in uscita. In questo modo, i frame PPP vengono multiplexati e demultiplexati su un singolo tunnel tra una data coppia LNS-LAC. Più tunnel possono esistere tra una data coppia LNS-LAC, e più sessioni possono esistere all'interno di un tunnel.
Il valore 0 per Session ID e Tunnel ID è speciale e NON DEVE essere utilizzato come Assigned Session ID o Assigned Tunnel ID. Per i casi in cui un Session ID non è stato ancora assegnato dal peer (cioè durante lo stabilimento di una nuova sessione o tunnel), il campo Session ID DEVE essere inviato come 0, e l'AVP Assigned Session ID all'interno del messaggio DEVE essere utilizzato per identificare la sessione. Allo stesso modo, per i casi in cui il Tunnel ID non è stato ancora assegnato dal peer, il Tunnel ID DEVE essere inviato come 0 e l'AVP Assigned Tunnel ID utilizzato per identificare il tunnel.
5.4 Utilizzo dei Numeri di Sequenza sul Canale Dati
I numeri di sequenza sono definiti nell'intestazione L2TP per i messaggi di controllo e opzionalmente per i messaggi dati (vedere sezione 3.1). Questi vengono utilizzati per fornire un trasporto di messaggi di controllo affidabile (vedere sezione 5.8) e un sequenziamento opzionale dei messaggi dati. Ogni peer mantiene numeri di sequenza separati per la connessione di controllo e ciascuna sessione dati individuale all'interno di un tunnel.
A differenza del canale di controllo L2TP, il canale dati L2TP non utilizza numeri di sequenza per ritrasmettere messaggi dati persi. Piuttosto, i messaggi dati possono utilizzare numeri di sequenza per rilevare pacchetti persi e/o ripristinare la sequenza originale dei pacchetti che potrebbero essere stati riordinati durante il trasporto.
5.5 Keepalive (Hello)
Un meccanismo di keepalive viene impiegato da L2TP al fine di differenziare le interruzioni del tunnel da periodi prolungati di nessuna attività di controllo o dati su un tunnel. Questo viene realizzato iniettando messaggi di controllo Hello (vedere sezione 6.5) dopo che è trascorso un periodo di tempo specificato dall'ultimo messaggio dati o di controllo ricevuto su un tunnel.
5.6 Smantellamento della Sessione
Lo smantellamento della sessione può essere avviato dal LAC o dal LNS ed è realizzato inviando un messaggio di controllo CDN. Dopo che l'ultima sessione è stata cancellata, la connessione di controllo PUÒ essere smantellata anch'essa (e tipicamente lo è).
5.7 Smantellamento della Connessione di Controllo
Lo smantellamento della connessione di controllo può essere avviato dal LAC o dal LNS ed è realizzato inviando un singolo messaggio di controllo StopCCN. Il ricevitore di uno StopCCN DEVE inviare uno ZLB ACK per confermare la ricezione del messaggio e mantenere abbastanza stato della connessione di controllo per accettare correttamente le ritrasmissioni StopCCN su almeno un ciclo di ritrasmissione completo (nel caso in cui lo ZLB ACK vada perso). Il tempo raccomandato per un ciclo di ritrasmissione completo è di 31 secondi (vedere sezione 5.8).
Un'implementazione può arrestare un intero tunnel e tutte le sessioni sul tunnel inviando lo StopCCN. Pertanto, non è necessario cancellare ogni sessione individualmente quando si smantella l'intero tunnel.
5.8 Consegna Affidabile dei Messaggi di Controllo
L2TP fornisce un servizio di trasporto affidabile di livello inferiore per tutti i messaggi di controllo. I campi Nr e Ns dell'intestazione del messaggio di controllo (vedere sezione 3.1) appartengono a questo trasporto. Le funzioni di livello superiore di L2TP non sono interessate alla ritrasmissione o all'ordinamento dei messaggi di controllo.
Il numero di sequenza del messaggio, Ns, inizia da 0. Ogni messaggio successivo viene inviato con il successivo incremento del numero di sequenza. Il numero di sequenza è quindi un contatore in esecuzione libera rappresentato modulo 65536.
(Capitolo 5 completato)