A cura di: Pettisani Diego e Ullo Antonio
Coordinamento: Prof. Alfredo De Santis
Sistemi di elaborazione dell'informazione (Sicurezza su Reti)
Università di Salerno - Anno Acc.1999-2000

Il livello Transaction è posizionato tra il livello superiore Session (WSP) e il livello Datagram (WDP). Opzionalmente tra WDP e WTP è interposto il livello Security (WTLS). Il livello WTP è responsabile dell’aspetto transazionale della comunicazione ovvero della destinazione di messaggi costituiti da pacchetti di informazione provenienti da livelli superiori. Il livello gestisce le seguenti quattro fasi che caratterizzano l’intero processo transazionale della comunicazione tra entità di pari livello:

1. Fase relativa all’invio e alla ricezione dei pacchetti provenienti da entità di livello superiore.
2. Fase relativa alla eventuale ri-trasmissione di pacchetti non correttamente ricevuti a destinazione.
3. Fase relativa alla gestione delle conferme (acknowledgements).
4. Opzionalmente fase relativa alla segmentazione ed al ri-assemblaggio (SAR) di un blocco di informazioni.

Stack protocol WAP

Classi di servizio

Il WTP offre tre distinte classi di servizio di transazione:

• Classe 0: invocazione di messaggi in modo instabile (senza nessuna conferma che il messaggio sia giunto a destinazione) e senza messaggi di ritorno.
• Classe 1: invocazione di messaggi in modo stabile (con conferma che il messaggio è giunto a destinazione) e senza messaggi di ritorno.
• Classe 2: invocazione di messaggi in modo stabile e con esattamente un messaggio di ritorno.

Faremo degli esempi per ogni classe facendo riferimento a due elementi:

• Initiator: l'entità di pari livello che origina la transazione.
• Responder: l'entità di destinazione della stessa transazione.

In generale, per ogni livello n di un qualsiasi stack protocol, il messaggio passato dal livello n al livello (n-1), si dice PDU (Protocol Data Unit) di livello n, o n-PDU. Essa, entrando nel livello (n-1), diventa una SDU (Service Data Unit) di livello (n-1), o (n-1)-SDU. Entro il livello (n-1) viene aggiunta alla (n-1)-SDU una PCI (Protocol Control Information) di livello (n-1). Il tutto diventa una (n-1)-PDU, che verrà passata al livello (n-2). Le PDU assumono nomi diversi in funzione del livello e dello stack protocol di appartenenza. Occorre evidenziare che il livello WTP è message oriented ovvero l’unità base informativa è un messaggio piuttosto che una stringa di byte intendendo dire con ciò che la transazione trasferisce blocchi omogenei di informazione e che è prevista eventualmente anche la concatenazione di PDU all’interno di una stessa SDU qualora il contesto lo richieda e le dimensioni del messaggio siano tali da permetterlo.

Le PDU appartenenti al WTP sono:

• Invoke: è la PDU che inizializza la transazione.
• Result: è la PDU che ritorna un messaggio invocato con la PDU Invoke se la classe di transazione scelta è la classe 2.
• Ack: è la PDU utilizzata per l'invio di ack (acknowledgement) previsti sia in classe 1 che in classe 2.
• Abort: è la PDU cui è demandato il compito di arrestare una transazione in corso.
• Segmented Invoke: è la PDU utilizzata per le invocazioni di messaggi in modalità SAR (descritta in seguito).
• Segmented Result: è la PDU utilizzata per la restituzione di messaggi previsti in classe 2 in modalità SAR.
• Negative Ack: è la PDU utilizzata per la gestione della modalità trasmissione di gruppo prevista dalla opzione SAR.

Un parametro importante per ogni PDU è il TID (transaction identifier), esso ha lo scopo di identificare la transazione e viene incrementato per ogni transazione inizializzata. Così si può ad esempio decidere che le transazioni 1, 2, 3 sono dirette al server A, le transazioni 4, 5, 6 verso il server B ecc.

Transazione di base di classe 0

L’Initiator della transazione invia il messaggio Invoke (fase 1) e il ricevitore non invia nessun Ack in segno di conferma. Per l’Initiator la transazione termina nel momento in cui effettua la trasmissione; per il Responder la transazione termina quando il messaggio Invoke è ricevuto. La transazione dunque non può essere interrotta. Con riferimento al livello WSP la classe 0 è la classe che offre il servizio di destinazione della informazione in modalità Push non confermato.

Transazione di base di classe 1

L’Initiator della transazione invia il messaggio Invoke (fase 1) e il Responder se riceve correttamente il messaggio destinatogli invia un Ack (fase 2) in segno di conferma. La transazione termina lato Initiator alla ricezione dell’Ack del Responder in assenza del quale ritrasmette il messaggio Invoke verso il Responder. La transazione può essere interrotta in qualsiasi momento con la PDU Abort. Con riferimento al livello WSP la classe 1 è la classe che offre il servizio di destinazione della informazione in modalità Push confermato.

Transazione di base di classe 2

L’Initiator della transazione invia il messaggio Invoke (fase 1) e il Responder se riceve correttamente il messaggio destinatogli ritorna l’atteso messaggio Result (fase 2) in segno di implicita conferma. L’Initiator manda, a seguito del messaggio Result ricevuto, un Ack al Responder (fase 3). La mancanza di messaggio Result lato Initiator invita quest’ultimo alla ritrasmissione del messaggio di Invoke fino a quando non riceverà un messaggio Result. Stessa cosa avviene lato Responder se non riceve l’Ack relativo al messaggio Result inviato all’Initiator. La transazione può essere interrotta in qualsiasi momento con la PDU Abort. Con riferimento al WSP, la classe 2 è utilizzata durante qualsiasi interazione che non adotti modalità di tipo Push ovvero durante la gestione client-server dell’informazione Pull. Esempio caratteristico è la richiesta di un deck WML residente ad un certo URL. La classe 2 è la classe maggiormente sfruttata.

Transazione di classe 2 con Ack intermedio

Nelle transazioni di classe 2 può capitare che una volta che il Responder riceve il messaggio di Invoke (fase 1), inviatogli dall'Initiator, non abbia immediatamente a disposizione il messaggio di Result chiestogli dall'Initiator. Quindi, al fine di evitare che l'Initiator ri-trasmetta il messaggio di Invoke, il Responder invia un Ack (fase 2) all'Initiator. Una volta che il messaggio di Result è disponibile, il Responder lo invia all'Initiator (fase 3). A questo punto il Responder rimane in attesa e l'Initiator, se riceve correttamente il messaggio di Result, genera l'Ack di conferma (fase 4).

La funzione SAR (Segmentation And Reassembly)

Opzionalmente, il livello WTP dispone della funzionalità SAR (Segmentation And Reassembly) permettendo la segmentazione del messaggio in trasmissione e il riassemblaggio dello stesso a destinazione, qualora l'informazione da trasmettere ecceda il cosiddetto MTU (Maximum Transport Unit) ovvero la massima capacità di trasporto contestuale del Bearer cui ci si interfaccia. La segmentazione avviene segmentando l'informazione ed instaurando un controllo sul flusso trasmesso tenendo memoria di: numero complessivo, numero d'ordine e dimensioni dei segmenti originati in sede di segmentazione. Se il SAR non è implementato dal WTP lo deve comunque implementare il livello di trasporto sottostante: il vantaggio di implementarlo al livello WTP sta proprio nella possibilità di usare la ritrasmissione selettiva migliorando così l’efficienza del protocollo. Come già detto per la funzione SAR sono previste specifiche strutture di PDU: Segmented Invoke, Segmented Result e Negative Ack.

Illustriamo le fasi che caratterizzano il processo di segmentazione del messaggio Invoke; il processo di segmentazione concettualmente non cambia al variare della tipologia di messaggio.

1. L'Initiator, in funzione dell'MTU disponibile segmenta la originaria PDU Invoke in n PDU di dimensioni ridotte (detti anche segmenti), di cui la prima è una PDU Invoke e le altre n-1 sono invece delle PDU Segmented Invoke che differiscono dalle normali PDU Invoke per la presenza del parametro PSN (Packet Sequence Number) previsto al fine di identificare il numero d'ordine assegnato allo specifico segmento.
2. L'Initiator invia al Responder la prima PDU Invoke ottenuta dalla segmentazione, segnalando con il flag TTR (Transmission Trailer) presente nella struttura dell'header della PDU Invoke, impostandolo a zero, che seguirà una segmentazione di cui essa stessa rappresenta il segmento numero 0 ovvero il primo segmento.
3. L'Initiator avvia la trasmissione delle PDU Segmented Invoke dove la prima ha il valore PSN uno, il segmento contiguo avrà valore due, e cosi via fino alla trasmissione dell'ultima PDU Segmented Invoke che avra il valore PSN impostato ad n-1. Poichè il PSN è largo 8 bit il massimo numero di segmenti che possono essere trasmessi come afferenti ad una segmentazione è 256.
4. Il Responder riceve dunque una PDU Invoke ed n-1 Segmented Invoke PDU ciascuna con un proprio identificativo costituito dal PSN. Una volta ricevuti tutti i segmenti il Responder può riassemblare il messaggio originale.

Initiator e Responder possono decidere a priori se:

• Attivare la trasmissione di ogni singolo segmento solo quando per il precedente si è ricevuta conferma di avvenuta ricezione.
• Avviare la trasmissione dei segmenti in modo sequenziale svincolandosi dalla ricezione dei relativi singoli Ack attivando così una cosiddetta trasmissione di gruppo ovvero la trasmissione di n segmenti a gruppi di m.

In entrambi i casi è necessario sapere chi è l'ultimo segmento al fine di terminare il processo di segmentazione lato Responder.
Nel primo caso la segnalazione dell'ultimo segmento trasmesso avviene tramite il flag TTR impostato ad uno della associata Segmented Invoke PDU dunque il Responder dal TTR trae informazioni circa la fine del processo di segmentazione. Nel secondo caso la strategia di controllo del flusso informativo composto da n segmenti inviati a gruppi di m è del tipo Selective Re-Transmission ossia un meccanismo che grazie alla PDU Nack (Negative Ack) ritornata dal Responder essa stessa è in grado di dare indicazioni all'Initiator circa la ritrasmissione (selettiva) dei soli segmenti non correttamente ricevuti identificati con i PSN che il Responder verifica esser mancanti. Tale verifica avviene tenendo conto che l’ultimo segmento del gruppo è segnalato con il flag GTR (Group Trailer), previsto nella struttura dell'header Segmented Invoke, impostato ad uno e prendendone come riferimento il suo PSN si rilevano i segmenti mancanti effettuandone la differenza con i PSN dei segmenti presenti. Ad esempio se il numero di segmenti da trasmettere è 7 e la destinazione ha ricevuto i primi 6 segmenti, la mancanza di segmenti con GTR = 1 e la presenza dei primi 6 PSN induce la rilevazione della mancanza di almeno un ulteriore segmento ovvero il settimo mancante e dunque la destinazione ritorna un Nack con il numero 7; se invece si rileva la presenza dei segmenti numero 2, 3, 5 e 7, esso ritorna una Nack PDU con i numeri 4 e 6 visto che il settimo segmento è stato rilevato come ultimo segmento trasmesso (flag GTR della relativa Segmented PDU settato ad 1).

Il grafico nella figura seguente esprime la successione delle operazioni che caratterizzano un processo di segmentazione gestito in modalità Selective Re-Trasmission in cui si suppone la segmentazione di un messaggio Invoke in tre segmenti dove il Segmented Invoke con PSN = 1 non è ricevuto a destinazione e la classe di transazione è la classe 1.

Handshake di Classe 1 in modalità trasmissione di gruppo

L'Initiator invia la PDU Invoke al Responder (fase 1), il flag TTR della Invoke sarà settato a zero, in questo modo il Responder capisce che la Invoke che ha ricevuto è solo il primo segmento della Invoke originale. Quindi l'Initiator invia al Responder il segmento successivo con una PDU Segmented Invoke (fase 2) il cui valore PSN sarà ovviamente uguale a 1, il segmento però non riesce a raggiungere il Responder. L'Initiator invia quindi l'ultimo segmento della Invoke originale con un'altra PDU Segmented Invoke (fase 3) il cui valore PSN sarà ovviamente uguale a 2 e il flag TTR (insieme a quello GTR) settato ad 1 per indicare al Responder che è l'ultimo segmento della PDU Invoke originale e che quindi può costruire il messaggio originale. A questo punto però il Responder verifica la mancanza del segmento con PSN uguale ad 1 e manda una PDU Nack all'Initiator (fase 4) per indicargli della mancata ricezione del segmento con valore PSN uguale ad 1. Quindi l'Initiator invia un'altra PDU Segmented Invoke (fase 5) rappresentante il segmento con valore PSN uguale ad 1 identica alla prima che aveva trasmesso precedentemente (nella fase 2), tranne per il valore del campo RID (Re-transmission Indicator) che avvalora appunto il numero di volte in cui la Segmented Invoke è stata già trasmessa e che quindi avrà il valore incrementato ad 1 rispetto alla prima Segmented Invoke. Questa volta la Segmented Invoke è giunta al Responder con successo che a questo punto può ricostruire il messaggio originale ed invia all'Initiator un Ack (fase 6) in segno di conferma.