Alma Mater Studiorum - Universita' di Bologna Sede di Cesena

Alma Mater Studiorum - Universita' di Bologna Sede di Cesena
Reti di Calcolatori Il Modello di Riferimento OSI Vedi: A.S. Tanenbaum, Computer Networks, 4th ed., Prentice Hall, sez. 1.3 e 1.4, pagg M.T. Rose, The open book, Prentice Hall, sez. 2, pagg ISO, IS OSI Transport Service Definition. Copyright © by Claudio Salati. Lez. 1

Rete: rete reale PC di Alice File server Alice

Rete: modello astratto .1
un insieme di sottoreti, interconnesse da sistemi intermedi, detti intermediate system (IS) o router (nel passato, anche gateway), che interconnette (serve a interconnettere) un insieme di sistemi finali detti end system (ES) o host Scopo della rete Interconnettere tra loro gli ES Gli IS sono presenti solo per consentire l’interconnessione degli ES Su ogni nodo della rete (ES o IS) e’ presente una istanza del protocollo di (inter-) rete: IP (Internet Protocol)

Rete: modello astratto .2’
Sottorete Una infrastruttura di comunicazione connessa e omogenea. Puo' offrire una interfaccia con servizio di livello (layer) Data Link o con servizio di livello di Rete. Il layer di Data Link si occupa del trasferimento di (pacchetti di) dati tra sistemi fisicamente (direttamente) connessi. Il layer di Rete si occupa del trasferimento di (pacchetti di) dati tra due sistemi qualunque di una rete connessa. In ogni caso tutti i nodi di una stessa sottorete (in particolare, ES e IS delle nostra rete che si affacciano alla sottorete) possono comunicare tra loro tramite il servizio offerto dalla sottorete. Dal punto di vista di IP due nodi di rete, ES e/o IS, che si affacciano ad una stessa sottorete possono comunicare tra loro tramite i servizi della sottorete, che e’ quindi vista da IP come un servizio di livello Data Link. Esempio di sottorete: IP over avian carriers, RFC 1149 (RFC, Wikipedia).

Rete: modello astratto .2”
Sottorete IP assume che tutte le sottoreti siano in grado di offrire un servizio di comunicazione connectionless. Si assume quindi che sia supportata una funzione del tipo Send_IPDatagram(IPDstAddr, IPSrcAddr, Dgram) N.B. se la sottorete non offre un servizio di comunicazione connectionless (e.g. reti ATM, SDH, OTN) e’ necessario introdurre uno stub di adattamento! Lo stub di adattamento e’ necessario anche per mappare gli indirizzi di livello IP nei corrispondenti indirizzi di sottorete. Internet = Interconnection of Networks

Rete: modello astratto
IS sottorete sottorete IS sottorete IS sottorete ES Sottorete ES ES Sottorete IS

Nodi della rete (da: Rose)
INTERMEDIATE-SYSTEM (IS) An IS is simply a single node, connected to more than one subnetwork, which is capable and is allowed to forward data from one subnetwork to another (non basta essere dual-homed!). An IS performs 2 tasks: it forwards data from one subnetwork to another (switching); in order to make the forwarding decision (where to send data next), it usually participates in a distributed routing algorithm. END-SYSTEM (ES) An ES is a node in the network containing the end-to-end services necessary for data transfer, the application services necessary for information transfer, le applicazioni finali (nel nostro caso, applicazioni di rete / distribuite). An ES is where the applications live. A node in the network may function both as an IS and as an ES.

Applicazioni finali e architettura layerizzata
Chi e’ che realizza un’applicazione? Un programma in esecuzione, cioe’ un processo. Nel nostro caso il programma e’ distribuito su diversi nodi della rete, quindi e’ costituito di diversi processi che devono interagire tra loro. Quindi tra chi deve consentire il colloquio (scambio di informazioni) la rete? Tra processi utente distribuiti su macchine diverse (i moduli del programma distribuito). Perche’ due processi su macchine diverse riescano a parlarsi tra loro e’ necessario che prima ci riescano le macchine su cui essi sono allocati.  2 “conseguenze”: Organizzazione layerizzata delle funzionalita’ di rete : Colloquio all’interno di una sottorete vs. colloquio a livello di rete. Colloquio a livello di rete tra macchine vs. colloquio tra processi allocati su queste macchine. Necessita’ di indirizzare gli interlocutori a diversi livelli: Indirizzo di una macchina a livello di sottorete. Indirizzo della macchina a livello di rete. Indirizzo di un processo.

Applicazioni di Rete: Esempi
VNC (consolle remota ), costituita da 2 tipi di moduli: viewer server telnet (terminale remoto), costituita da 2 tipi di moduli: client FTP / TFTP (file transfer), costituita da 2 tipi di moduli: NFS (network file system), costituita da 2 tipi di moduli: WWW (web), costituita da 2 tipi di moduli: browser . . . N.B.: appare sempre il paradigma client-server (anche se questo non significa che tutte le applicazioni distribuite siano client-server)!

Modello astratto alternativo (client-server) .1
IS sottorete sottorete IS sottorete IS sottorete Sottorete Server Client Server Sottorete IS 10

Modello astratto alternativo .2
ES ES ES ES ES 11

Modello astratto alternativo .3
Client Server Server Server Client 12

Modello astratto alternativo: cloud-computing
Client Client Client Client Client Client Client Client Client Client 13

Modelli Il modello Internet e’ intrinsecamente peer-to-peer: qualunque ES puo interagire con qualunque ES. Il modello client-server estremizzato, in cui alcune macchine sono destinate ad ospitare solo il lato server delle applicazioni ed altre solo il lato client, non e’ peer-to-peer: due macchine client non possono interagire tra loro. Nel modello cloud-computing le macchine server sono addirittura annegate dentro la rete: quando richiedo un servizio non so nemmeno chi me lo stia fornendo! L’avere distinto tra macchine client e macchine server e’ quello che ha poi consentito di utilizzare all’interno della rete (delle sue intranet) indirizzi IP privati. Ma e’ anche una delle ragioni che hanno reso problematico le comunicazioni tra due ES qualunque. Una intranet è un insieme di sottoreti di internet che sono gestite da una unica organizzazione (amministrazione) e che può essere ad accesso ristretto da/verso il resto della rete.

Modello “non piatto” di rete
IS sottorete sottorete intranet IS sottorete IS sottorete ES Sottorete ES ES Sottorete intranet IS 15

Dati (stringhe di bit/byte) vs. informazioni
Vedi: Beau Lotto: Optical illusions show how we see, TED Talks, July 2009; 4min & 30sec iniziali. Terminologia: Corso Reti di Calcolatori Beau Lotto dati information informazioni meaning

Un dato (cioe’ una stringa di bit o di byte) e' una rappresentazione concreta (cioe’ una encodifica) di una informazione (un valore di un certo tipo). Non esiste una associazione biunivoca intrinseca dato  informazione. In quanti modi possiamo pensare di rappresentare l’informazione “valore booleano true”? Dato un testo, con quanti alfabeti diversi puo’ essere scritto? Alfabeto ANSI ASCII Alfabeto ISO Alfabeto Unicode Anche fissando l’alfabeto, in quante maniere diverse posso pensare di codificare i caratteri di quell’alfabeto? Esempio Unicode: UTF-8 UTF-16 big-endian UTF-16 little-endian

Tabella ASCII (7 bit per char)

Cosa rappresenta il dato (la stringa di bit) ? N.B.: assumiamo: most significant bit first (piu' a sinistra)! il numero +118 (con segno) in rappresentazione complemento-a-2 il numero 118 (senza segno) in rappresentazione binaria il numero 76 (senza segno) in rappresentazione BCD il valore booleano TRUE (come in C: stringa con almeno un bit 0; se tutti i bit sono 0 allora il valore rappresentato e' FALSE) Il carattere 'v' secondo l'alfabeto ASCII (esteso?) +118, 118, 76, TRUE, 'v' rappresentano informazioni Quando voglio usare un'informazione su un calcolatore (o trasferirla in rete) la devo codificare (rappresentare concretamente) tramite una stringa di bit o di byte (un dato) Se voglio risalire da un dato all'informazione da esso rappresentata devo sapere: di quale tipo di informazione si tratta quale e' la regola di encodifica utilizzata per quel tipo di informazione (nel contesto specifico)

Value notation Quando diciamo che +118, 118, 76, TRUE, 'v' rappresentano informazioni, intendiamo che la notazione che usiamo ci consente (obbliga) a indicare dei valori tipizzati. Quando in C scriviamo 5 intendiamo “valore di tipo int, 5”. Se volessimo il “valore di tipo unsigned, 5”, dovremmo scrivere 5U o 5u. Se volessimo il “valore di tipo long, 5”, dovremmo scrivere 5L o 5l. Analogamente, quando in C scriviamo intendiamo “valore di tipo double, 123.4”. Se volessimo il “valore di tipo float, 123.4”, dovremmo scrivere 123.4F o 123.4f. Nei linguaggi di programmazione ogni valore e’ sempre tipizzato (appartiene ad uno ed un solo tipo). I linguaggi di programmazione prevedono una notazione che consente di esprimere valori tipizzati.

Quando ricevo dei dati (e.g. un file) attraverso il web, come faccio a capire quale tipo di informazioni essi rappresentano, e quindi quale e’ il programma adatto per trattarli? Testo HTML  il Browser si occupa direttamente del rendering sullo schermo. Programma eseguibile  il sistema operativo lo prende in carico per eseguirlo o per salvarlo in un file. Testo PDF  viene aperto con Acrobat Reader. Testo semplice (plain text)  viene aperto Wordpad o Notepad. . . . Il PDU HTTP (qualunque cosa questo significhi) riporta il tipo dell’informazione da esso trasportata, e.g.: Content-Type: text/html; charset=ISO Content-Type: text/plain; charset=us-ascii Content-Type: image/gif

Dati vs. informazioni e architettura layerizzata
Due moduli di una applicazione distribuita, tra loro, vogliono scambiarsi informazioni. Ma le informazioni “in astratto” non esistono, esistono solo in quanto incarnate in una rappresentazione concreta, in dati. Quindi, se due moduli di una applicazione distribuita vogliono scambiarsi delle informazioni devono prima riuscire a scambiarsi tra loro dei dati e poi essere in grado di associare quei dati in modo corretto all’informazione che si vuole scambiare. Due funzionalita’ diverse, due layer diversi: Scambio di dati tra due moduli di una applicazione distribuita. Scambio di informazioni tra due moduli di una applicazione distribuita.

Una architettura layerizzata
Scambiare dati tra due moduli del programma distribuito e’ condizione necessaria (ma non sufficiente) per potere scambiare informazione tra i due moduli. Scambiare dati tra due ES e’ condizione necessaria (ma non sufficiente) per potere scambiare dati tra i due moduli di un programma distribuito residenti su di essi. Scambiare dati tra due nodi di una sottorete e’ condizione necessaria (ma non sufficiente) per potere scambiare dati tra i due nodi della rete. Devo poter indirizzare Processi in esecuzione su un ES ES sulla rete Nodi sulle sottoreti

Una architettura gerarchica a livelli
La costruzione di una rete di calcolatori e' un problema complesso. La strategia normale per risolvere un problema complesso e' di scomporlo in sotto-problemi piu' semplici. Una maniera per organizzare tra loro i sotto-problemi e' quella di definire una architettura gerarchica a livelli (layer) in cui ciascun livello e' realizzato sfruttando le funzionalita' offerte dal livello (in generale, dai livelli) inferiore della gerarchia. Ogni livello offre un insieme ben definito di servizi, che il livello superiore puo' utilizzare senza doversi preoccupare di come questi servizi sono implementati. ogni livello rappresenta una macchina virtuale. ogni livello rappresenta un dato astratto (ADT, classe).

Una architettura gerarchica e distribuita
Layer 5 Layer 4 Layer 3 Layer 2 Layer 1

Una architettura distribuita
Una rete di calcolatori e' realizzata tramite l'interconnessione fisica di diversi nodi che interagiscono tra loro. Ciascun layer dell'architettura di rete, per poter realizzare la propria funzionalita', deve essere presente (istanziato) su piu' (alcuni o tutti i) nodi della rete (a seconda del layer e del tipo di nodo). Ciascun layer e' cioe' realizzato in modo distribuito. Per poter realizzare la propria funzionalita' il layer n su un nodo deve poter interagire con il layer n di uno o piu' altri nodi. Le regole dell'interazione tra le diverse istanze del layer n (in particolare, la sintassi dell’informazione scambiata) e la logica di evoluzione dello stato di ciascuna istanza a seconda degli eventi che la coinvolgono sono complessivamente indicate come protocollo del layer n. Una istanza del layer n e' chiamata protocol entity del layer n. Due protocol entity che dialogano tra loro si riferiscono come peer entity (pari).

Protocollo Le strutture informative scambiate tra due istanze del layer n per dialogare tra loro sono dette nPDU (Protocol Data Unit di livello n). "Dialogare tra loro" significa "sviluppare il loro protocollo di dialogo“, fare evolvere il proprio stato e il proprio comportamento in base allo stato del pari ( scambio di informazioni con il pari) e alle richieste del cliente. Perche' il dialogo sia efficace il protocollo (e in particolare la struttura dell'informazione scambiata) deve essere condiviso, e quindi standardizzato. La definizione di cosa fa azioni (e.g. inviare un certo PDU al pari) e transizioni di stato (protocol entity implementate come MSF) una protocol entity di un layer che si trova in un certo stato a fronte degli eventi che possono intervenire e' indicata come insieme delle procedure del protocollo.

Layer e loro interazioni: colloquio tra pari
I layer di un’architettura di rete sono normalmente numerati da 1 a N, dove N dipende dalla particolare architettura di rete (N=7 nel caso del modello di riferimento OSI, Open Systems Interconnection, ma in realta’ al di sopra del Layer 7 c’e’ l’applicazione utente vera e propria, l’applicazione finale). Nel modello di riferimento OSI ad ogni layer sono associati anche un nome ed un acronimo. Il layer 1 e' normalmente indicato come layer Fisico (Ph). In realta', eccetto che per il livello Fisico, non e' possibile un colloquio diretto tra pari su nodi diversi. Per parlare con il proprio pari sul nodo B, l'istanza del layer n+1 (n1) presente sul nodo A deve (non ha altro strumento per farlo!) utilizzare i servizi forniti dal layer n residente sul proprio nodo. 29

Accesso ai servizi del layer n
L'accesso ai servizi del layer n da parte di un cliente (protocol entity del layer n+1) avviene attraverso un nSAP (Service Access Point del layer n) Ogni cliente del layer n utilizza un proprio nSAP per accedere ai servizi di questo layer Lo nSAP di un cliente (di una entita’ di livello n+1) e’ distinguibile da tutti gli altri nSAP non solo da quelli allocati sullo stesso nodo, ma da tutti gli altri nSAP della rete! Un nSAP individua univocamente nella rete una entita’ di livello n+1 Un nSAP consente alle altre entita’ di livello n+1 di indirizzare una entita’ di livello n+1 Un nSAP e’ formato dalla concatenazione dell’indirizzo della entita’ di protocollo di livello n che fornisce il servizio (n-1SAP) con un nSEL (selettore di livello n): l’nSEL identifica univocamente (a livello locale) un particolare cliente dell’entita’ rispetto a tutti i suoi altri clienti N.B. di conseguenza gli indirizzi delle diverse entita’ dei diversi layer sono strutturati ad albero. 30

OSI Reference Model info Layer end-to-end, presenti solo sugli ES dati

L’Architettura OSI “in soldoni”
Funzioni dei diversi layer dell’architettura di rete OSI: Layer 1, Physical, Ph: scambio di bit tra nodi adiacenti della rete. Layer 2, Data Link, Dl: scambio di pacchetti di dati (frame) tra nodi adiacenti della rete. Layer 3, Network, N: scambio di pacchetti di dati (datagram) tra nodi qualunque della rete, anche se non adiacenti. Layer 4, Transport, T: scambio di dati tra i moduli di una applicazione distribuita. Layer 5, Session, S: ???. Layer 6, Presentation, P: scambio di informazioni tra i moduli di una applicazione distribuita. Layer 7, Application, A: protocolli applicativi specifici (e.g. HTTP) e supporti per la costruzione di applicazioni distribuite. E sopra il livello 7 ci sta la nostra applicazione, il programma utente (e.g. il browser o il web server)! 32

Dati vs. Info: definizione di un nPDU, n = 2..6
Non c’e’ distinzione tra informazione e sua encodifica. Occorre indicare non solo quali sono le informazioni scambiate, ma anche come esse sono encodificate nell’nPDU. Esempio (PDU IP):

Dati vs. Info: definizione di un 7PDU (APDU)
E’ sufficiente descrivere quale e’ l’informazione che viene scambiata, senza preoccuparsi di come essa viene encodificata da un pari, dall’altro o sulla rete. Esempio (PDU RPC): struct rpc_msg { unsigned int xid; // transaction identifier union switch (msg_type mtype) { case CALL: call_body cbody; case REPLY: reply_body rbody; } body; }; enum msg_type { CALL = 0, REPLY = 1 struct call_body { unsigned int rpcvers; // must be ==2 unsigned int prog; // binding info unsigned int vers; // binding info unsigned int proc; // binding info opaque_auth cred; // authen. info opaque_auth verf; // authen. info // procedure specific parameters start here . . . 34

Definizione OSI di un layer
Ogni layer puo' definire diversi insiemi di servizi Ad esempio i livelli 2, 3, 4 del modello di riferimento OSI (rispettivamente, Data Link o Dl, Network o N, Transport o T layer) definiscono ciascuno due insiemi di servizi: Connection Oriented (CO) n-layer Service ConnectionLess (CL) n-layer Service Ogni insieme di servizi e' implementato da uno o piu' protocolli. Nell'architettura di rete OSI ogni layer e' definito tramite: La definizione degli insiemi di servizi offerti dal layer. La definizione dei protocolli utilizzati per realizzare quegli insiemi di servizi. Non e’ prevista (neanche nel mondo TCP/IP!) la definizione di un’API standard per l’accesso ai servizi offerti da un layer.

Definizione OSI dei servizi di un layer
La definizione OSI dei servizi di un layer non avviene tramite la definizione di una API (Application Programming Interface o interfaccia programmatica) standard. Del resto nemmeno nel mondo Internet le API sono soggette a definizione standard. Per il layer di Trasporto: Non esiste nessun RFC che definisce l'API socket. Non esiste alcun RFC che definisce l'API TLI: TLI (XTI) e' uno standard Unix System V/Posix, non Internet. Internet standardizza solo i protocolli! La standardizzazione dei protocolli garantisce la interoperabilita' di diverse implementazioni dell'architettura di rete. La definizione di API standard consentirebbe la portabilita' del SW da un ambiente operativo all'altro.

API standard? Piu’ facile da dire che da fare.
I diversi ambienti operativi incoraggiano stili di programmazione diversi : Sincrono (il programma invoca le system call quando vuole lui): e’ lo stile tradizionale Unix. Asincrono (o event driven, basato su call-back): e’ lo stile tradizionale Windows, derivato dall’organizzazione dei SW per GUI. Sequenziale: e’ lo stile tradizionale C. Concorrente: e’ lo stile tradizionale Java e Windows. Anche quando delle API sono state standardizzate (e.g. TLI) e’ capitato che nessuno le ha prese sul serio! 37

Definizione di un layer: parole chiave .1
Si applicano a diversi layer servizi Connection-Oriented (CO) vs. servizi ConnectionLess (CL) Servizio di trasmissione dei pacchetti che richiede che le entita' di comunicazione stabiliscano una connessione (circuito virtuale) prima di inviare i dati (CO) vs. servizio di trasmissione dei pacchetti che tratta ciascun pacchetto dati come un'entita' a se stante (CL). Servizio telefonico (CO) vs. servizio postale (CL). indirizzamento Metodo che consente l'identificazione e la localizzazione di una entita' della rete. Per quanto detto: basato sull’utilizzo degli nSAP. Identificazione (e.g. codice fiscale o alias piu’ povero, come nome+cognome) vs. localizzazione (e.g. numero di telefono).

Si applicano a diversi layer controllo degli errori Capacita' di riconoscere che e' avvenuto un errore nella trasmissione o nella ricezione di un pacchetto dati, eventualmente con lo scopo di recuperarlo. Error detecting codes (e.g. checksum, CRC) vs. error correcting codes (e.g. Reed-Solomon) . controllo di flusso Controllo della velocita' con cui gli host e/o i router si inviano i pacchetti dati. Per evitare che il lato ricevente sia sommerso di dati che non riesce a gestire. Nel Layer 3: troppi datagram, in genere relativi a diversi flussi di comunicazione, attraversano il router. Nel Layer 4: un modulo dell’applicazione distribuita non riesce a smaltire i dati inviatigli da un altro modulo della stessa applicazione. E.g.: “prof, sta parlando troppo in fretta!” 39

Si applicano a diversi layer multiplexing / de-multiplexing Creazione di un unico segnale complesso a partire da piu' segnali indipendenti / separazione di un unico segnale complesso nei suoi segnali componenti e loro gestione indipendente. Esempi TLC: segnale multiplato nel tempo TDM/PCM (PDH, SDH), o nelle frequenze (FDM), o nelle  (rete ottica). Quality of Service (QoS) Qualita' del servizio che una rete garantisce, in termini di bit-rate, jitter, ritardo, errori residui. Esempio Ethernet/IEEE 802.1q: priorita’ dei frame Esempio IP: diffServ e campo ToS (Type of Service) end-to-end Che si applica agli estremi di una comunicazione, senza interessare i punti (nodi/layer) intermedi. Quindi, in particolare, che e’ allocato solo sugli ES.

Parole chiave e datagram IP
Quality of Service Controllo degli errori De/multiplexing Indirizzamento

Si applicano a diversi layer affidabilita’ (reliability) Una comunicazione si definisce affidabile se non perde non duplica non desequenzializza garantisce l’integrita’ dei dati (delle informazioni) trasmessi (trasmesse). Un servizio affidabile deve necessariamente essere CO? No, ma TCP e’ CO e affidabile mentre UDP e’ CL e non affidabile. Un servizio affidabile deve essere confermato (a livello utente)? No, non e’ la conferma del cliente che garantisce l’affidabilita’, ma il fornitore del servizio. Come si fa a sapere che un dato e’ stato ricevuto dal pari? Perche’ lo garantisce il servizio! Quello che eventualmente non si sa e’ “quando” avviene la ricezione. Esempio: .

OSI Reference Model: layer end-to-end

Layer OSI - Layer 4, Trasporto (da: Rose)
The Transport Layer is responsible for reliability and multiplexing of data transfer across the network (over and above that provided by the Network Layer) to the level required by the application. The Transport Layer is a true end-to-end layer, all the way from the source to the destination (e’ allocato solo sugli ES!). A program on the source machine carries on a conversation with a similar program on the destination machine. In the lower layers the protocols are between each machine and its adjacent neighbors, and not between the ultimate source and destination machines. The Transport Layer determines what type of service to provide to the users of the network: reliable point-to-point channel (no errors, losses, duplication); unreliable transfer of isolated messages. In ogni caso, il servizio di Trasporto si occupa di trasferimento di dati (bit, byte).

Layer OSI - Layer 5, Sessione
Responsible for adding control mechanisms to the data exchange. (Rose) Consente di strutturare il dialogo applicativo: controllo del dialogo (half-duplex vs. full duplex) assegnazione di token creazione di checkpoint per un eventuale backtrack parziale Per quanto ci riguarda il livello di Sessione fornisce un servizio sostanzialmente equivalente a quello fornito da TCP di Internet: Trasferimento affidabile e trasparente di byte end-to-end tra due processi ovunque localizzati sulla rete. Gestione "ben educata" della connessione, ed in particolare della fase di disconnessione. Gestione di richieste contemporanee incrociate di apertura di una connessione.

Layer OSI - Layer 6, Presentazione
Il livello di Sessione (Trasporto) ci consente di effettuare uno scambio affidabile di bit/byte (dati) tra due moduli di una applicazione distribuita. Ma le applicazioni non vogliono scambiare dei bit, vogliono scambiare delle informazioni ! Il servizio di presentazione fornisce gli strumenti per scambiare informazione (e.g. “il numero intero con segno +5”) tra due moduli di una applicazione distribuita in modo tale che il significato dell'informazione sia conservato inalterato indipendentemente: dalla codifica utilizzata per rappresentare l'informazione durante il trasferimento. dalla codifica utilizzata per rappresentare localmente l'informazione su ciascuno dei due moduli/End-System. (per i quali possono essere diversi piattaforma HW, sistema operativo, linguaggio di programmazione, sistema di programmazione: vogliamo essere liberi!)

Layer OSI - Layer 7, Applicazione
The Application Layer is the ultimate responsible for managing the communications between applications. (Rose) Il Layer Applicativo non rappresenta le applicazioni finali nel loro complesso (il livello utente, che si trova sopra il Livello 7) ma il loro aspetto di interazione con la rete: Layer 7 = insieme dei protocolli applicativi utilizzati per offrire i servizi di comunicazione in rete ai programmi utente. Protocol entity HTTP vs. applicazione finale web browser Il Layer 7 e' quindi costituito da un insieme di servizi applicativi, che in termini OSI sono chiamati ASE (Application Service Element). Ad esempio la classe URL di Java che consente ad un modulo client di interagire con un web server tramite il protocollo HTTP. Ci sono ASE progettati per supportare applicazioni specifiche (e.g. file transfer), anche se possono essere utilizzati anche in contesti diversi (e.g. file transfer come parte di una applicazione di system management), e ASE che nascono per essere di uso generale (e.g. RPC).

Layer OSI - Layer 7, RPC RPC sta per Remote Procedure Call.
Le RPC rappresentano il metodo di elezione per costruire applicazioni distribuite utilizzando i servizi del Layer 7. L’interazione tra due moduli del programma distribuito avviene tramite chiamata di procedura, cosi’ come succede nella programmazione concentrata. Come nella costruzione di un programma concentrato: Sara’ necessario bind-are l’interfaccia del modulo server. (nella programmazione concentrata lo fa di norma il linker) Sara’ necessario indirizzare la singola procedura all’interno del modulo server. (nella programmazione concentrata lo fa di norma il linker) Sara’ necessario scambiare in modo coerente parametri di ingresso/uscita tra procedura chiamante e procedura chiamata. E controllare che questo scambio sia corretto! (nella programmazione concentrata lo fa di norma il compilatore)

Layer OSI Tutti i layer dal 4 compreso in su rappresentano interazioni e funzionalita' end-to-end. Tanenbaum: Two of the OSI 7 layers are nearly empty (Session and Presentation). The TCP/IP model does not have Session and Presentation Layers. No need for them was perceived, so they were not included. Experience with the OSI model has proven this view correct: they are of little use to most applications. Salati: Falso: il Presentation Layer e' (concettualmente, e spesso anche praticamente) essenziale. Il Session Layer e' meno rilevante, ma solo perche' le sue funzionalita' possono essere meglio fornite da protocolli di Layer 7 (Application), e.g. RPC. Le funzioni del Layer 7 (Application), che non coincide con le applicazioni finali ma che fornisce ad esse i servizi di comunicazione (e.g. RPC), sono anch’esse essenziali.

Definizione OSI dei servizi di un layer
La definizione OSI di un insieme di servizi di un layer avviene listandone i singoli servizi componenti. Ogni servizio componente e' a sua volta definito in termini di primitive (interazioni logiche) scambiate tra il layer stesso (il provider del servizio) e il suo cliente. Sono previste 4 primitive (direzionali), che possono essere composte secondo diverse ricette (3 ricette principali). Le 4 primitive sono: request (layer cliente  layer servitore) indication (layer servitore  layer cliente) response (layer cliente  layer servitore) confirm (layer servitore  layer cliente ) Ogni primitiva ha associati una direzione (fissa, dal layer servitore a quello cliente o viceversa) e un insieme di parametri (dipendente dal particolare servizio in cui la primitiva e’ utilizzata). Il protocollo di un layer e’ descritto in termini di scambio di PDU con il pari, di transizioni di stato e di scambio di primitive con i layer adiacenti.

Servizi OSI: descrizione (ricetta 1)
Servizio Non Confermato

Servizi OSI: descrizione
I parametri passati dal service user nella primitiva .req (.resp) sono (possono essere) inseriti dal service provider nella corrispondente primitiva .ind (.conf, rispettivamente), e sono (possono essere) cosi' trasmessi al service user remoto. Un parametro puo' anche avere un significato “locale”, che coinvolge la protocol entity server, e quindi venire modificato da questa e/o non essere trasmesso al pari. Nella descrizione di un servizio sono indicati i parametri associati alle primitive che lo implementano. Service provider Service User S.req(p1, …, pn) S.ind(p1, …, pn)

Servizi e Protocolli User Service Provider Protocol Entity
Service User Service Provider Protocol Entity Service User Protocol API S.req S.conf S.resp S.ind Provider Protocol Service Provider

Servizi e Protocolli kSAP kSAP k-1SAP k-1SAP

Servizio Confermato

Servizio Iniziato dal Provider

COTS, Connection Oriented Transport Service (ISO 8072)
Servizi componenti: T-CONNECT, confermato T-DATA, non confermato T-EXPEDITED-DATA, non confermato T-DISCONNECT, non confermato o provider-initiated I servizi sono definiti in modo astratto: l'implementazione dell'interfaccia deve solo essere funzionalmente "equivalente“. Quali sono le differenze tra il COTS OSI e il servizio offerto da TCP? Basta fare l’analisi di questa specifica! Diverse API implementative possono essere associate ad una stessa definizione di servizio/i. Nel caso del TS (in C): socket TLI

COTS: servizio T-CONNECT (ISO 8072)
The Transport Connection (TC) establishment TS primitives can be used to establish a TC, provided the TS users exist and are known to the TS provider. Simultaneous T-CONNECT requests at the two TSAPs are handled independently by the TS provider (N.B.: a differenza che in TCP, vedi anche slide “TCP Connection State Diagram”). NOTE – Simultaneous T-CONNECT requests typically result in a corresponding number of TCs. Nella descrizione del servizio sono descritti/e: i parametri di ciascuna primitiva che implementa il servizio. le sequenze, legittime e non, di utilizzo dei diversi servizi. La specifica del servizio e’ puramente funzionale: le primitive non definiscono un’API. Come si implementa una indication? Request e confirm coincidono con chiamata e ritorno di una stessa funzione o no? Response e’ una funzione? Non ha parametri di ritorno?

Scenari di Connessione successful TC establishment
TS provider T-CONNECT.request T-CONNECT.indication T-CONNECT.response T-CONNECT.confirm

Scenari di Connessione rejection of TC establishment request by its user
TS provider T-CONNECT.request T-CONNECT.indication T-DISCONNECT.request T-DISCONNECT.indication N.B.: si tratta di una variante obsoleta della ricetta 2

Scenari di Connessione rejection of TC establishment request by TS provider
T-CONNECT.request T-DISCONNECT.indication N.B.: si tratta di una variante obsoleta della ricetta 2

T-CONNECT: primitive e parametri (ISO 8072)
TS primitive Parameter T-CONNECT request T-CONNECT indication T-CONNECT response T-CONNECT confirm Called Address X X(=) Calling Address Responding Address Expedited data option Quality of Service TS user-data X(U) X Mandatory parameter. (=) The value of that parameter is identical to the value of the corresponding parameter of the preceding TS primitive. (U) Use of this parameter is a TS user option.

Esempio: parametro “Expedited data option” The Expedited Data option parameter indicates whether the expedited (out-of-band in terminologia TCP) data option is to be available on the TC. If this service is declared not available, it cannot be used on the TC. The value of the parameter is either “Expedited Data Service selected” or “Expedited Data Service not selected”. The values of the various primitives are related such that: in the T-CONNECT request primitive, either of the defined values may occur; in the T-CONNECT indication primitive, the value is equal to the value in the T-CONNECT request primitive; in the T-CONNECT response primitive, the value is either “Expedited Data Service not selected” or is equal to the value in the T-CONNECT indication primitive; in the T-CONNECT confirm primitive, the value is equal to the value in the T-CONNECT response primitive.

Esempio: negoziazione dell’opzione “Expedited data transfer” The expedited TSDU transfer is only made available when specifically requested and agreed to by both TS users when the TC is established. When available this service is always bidirectional. The procedure for negotiating the use of the expedited TSDU transfer is as follows: The calling TS user may request or not request the use of the expedited TSDU transfer feature. If the calling TS user does not request the use of the expedited TSDU transfer feature, the called TS user is not allowed to request its use. If the calling TS user does request the use of the expedited TSDU transfer feature, the called TS user may agree to the use of expedited TSDU transfer on the TC, in which case the TS provider is required to provide it. The called TS user may refuse the use of expedited TSDU transfer in which case the service will not be used on that TC.

Esercizio: Come mai il parametro Expedited data option e’ uguale nelle primitive .req e .ind del servizio T-CONNECT mentre il parametro Quality of Service puo’ essere diverso? E come mai, invece, entrambi i parametri sono uguali nella coppia di primitive .resp / .conf del servizio T-CONNECT? Come puo’ essere utilizzato il parametro TS user-data presente (in forma opzionale) nelle primitive che implementano il servizio T-CONNECT?

COTS: servizio T-DATA (ISO 8072)
The TS provider provides for an exchange of TSDUs, in both directions simultaneously. The TS provider preserves the integrity, the sequence and boundaries of the TSDUs. N.B.: TCP non preserva l’identita’ dei singoli SDU (i Ioro boundary, quali byte fanno parte di un SDU e quali di un altro). TCP e’ stream-oriented, non message-oriented. Primitive Parameter T-DATA request T-DATA indication TS user-data X X(=) X Mandatory parameter. (=) The value of that parameter is identical to the value of the corresponding parameter of the preceding TS primitive.

COTS: servizio T-DATA (ISO 8072)
Notare che i parametri del servizio non consentono di specificare su quale connessione si vogliono trasmettere i dati: Nella definizione di una interfaccia funzionale astratta non e’ un problema. (ricordiamoci che i servizi sono acceduti tramite un TSAP quindi: Le primitive sono scambiate tramite un TSAP. La connessione sulla quale si vogliono inviare i dati e’ quella associata al TSAP a cui e’ stata inviata la primitiva T-DATA.req. Domanda: come e’ implementato un TSAP?) Nella definizione di un’API questa informazione e’ essenziale. La specifica OSI del servizio e’ puramente funzionale, non implementativa. Il servizio T-DATA e’ non confermato. Il servizio T-DATA e’ affidabile. 67

Scenari di Data Transfer normal data transfer
N.B.: il servizio T-DATA e' non confermato. Cio' non significa che non sia affidabile! TS provider T-DATA.request T-DATA.indication

COTS: servizio T-EXPEDITED-DATA (ISO 8072)
The expedited data transfer service provides a further means of information exchange on a TC in both directions simultaneously. The transfer of expedited TSDUs is subject to different QOS and separate flow control from that applying to TS user-data of the data transfer service . The TS provider guarantees that an expedited TSDU will not be delivered after any subsequently submitted normal TSDU or expedited TSDU on that TC . The relationship between normal and expedited data flow is modelled by the operation of reordering within queues ... In particular expedited data will be delivered when the receiving TS user is not accepting normal data. However, the amount of normal data bypassed by such reordering cannot be predicted. Primitive Parameter T-EXPEDITED-DATA request T-EXPEDITED-DATA indication TS user-data X X(=) X Mandatory parameter. (=) The value of that parameter is identical to the value of the corresponding parameter of the preceding TS primitive.

Scenari di Data Transfer expedited data transfer
TS provider T-EXPEDITED- DATA.request T-EXPEDITED-DATA.indication

COTS: servizio T-DISCONNECT (ISO 8072)
The TC release TS primitives are used to release a TC. The release may be performed: by either or both of the TS users to release an established TC; by the TS provider to release an established TC; all failures to maintain a TC are indicated in this way; by either or both the TS users to abandon TC establishment; by the TS provider, to indicate its inability to establish a requested TC. TC release is permitted at any time regardless of the current TC phase. A request for release cannot be rejected (sarebbe anche impossibile rigettarla visto che il servizio T-DISCONNECT e’ non confermato!). The Transport Service does not guarantee delivery of any TS user-data once the release phase is entered. N.B.: a differenza del Trasporto OSI TCP garantisce invece la chiusura morbida della connessione.

T-DISCONNECT: primitive e parametri (ISO 8072)
Primitive Parameter T-DISCONNECT request T-DISCONNECT indication Reason X TS user-data X(U) X(=) X Mandatory parameter. (=) The value of the parameter is identical to the value of the corresponding parameter of the preceding TS primitive. (U) Use of this parameter is a TS user option. The Reason parameter gives information indicating the cause of the TC release. Remote TS user invoked. TS provider invoked. This reason may be of transient or permanent nature. lack of local or remote resources of the TS provider; called TS user unknown; called TS user unavailable; . . .

Scenari di Disconnessione TC release initiated by its user
TS provider T-DISCONNECT.request T- DISCONNECT.indication

Scenari di Disconnessione TC release initiated by its provider
T-DISCONNECT.indication T- DISCONNECT.indication

Dati scambiati sull'interfaccia e PDU .1
Consideriamo la fase di data transfer: Il layer n (server) e' richiesto di trasferire dati forniti dal suo layer cliente, il layer n+1. I dati da trasmettere sono passati dal layer n+1 come parametro in una primitiva inviata al layer n tramite lo nSAP da lui utilizzato. E.g. il parametro TS user-data della primitiva T-DATA.request. Questi dati rappresentano lo n+1PDU, ma dal punto di vista del layer n sono opachi (payload): il layer n non li capisce, li deve solo trasportare al pari di livello n+1 dall'altra parte della rete. Dal punto di vista del layer n questi dati sono indicati da OSI come nSDU (Service Data Unit di Layer n). Per offrire il suo servizio il layer n deve parlare con il suo pari, cioe' deve produrre un nPDU, e questo nPDU deve contenere lo nSDU, cioe' lo n+1PDU.

Lo nSDU (user-data) rappresenta il campo informativo (payload) dello nPDU, ma questo deve contenere anche uno header (o overhead) per supportare il protocollo: e.g. per indicare che lo nPDU trasporta degli user-data. questo header e' chiamato da OSI PCI (Protocol Control Information). Per richiedere la trasmissione del proprio PDU un cliente puo' dover fornire al layer servitore informazioni aggiuntive (e.g. QoS, Quality of Service), oltre che indicare il servizio/primitiva richiesti: l'insieme di queste informazioni e' chiamato ICI (Interface Control Information).

ICI +PDU nel loro complesso sono indicati da OSI come IDU (Interface Data Unit). Analogamente il PDU e' composto della coppia PCI+SDU. Un IDU rappresenta una interazione tra due layer di livello diverso, entrambi residenti su uno stesso nodo di rete. Un PDU rappresenta una interazione tra due diverse protocol entity dello stesso livello, residenti (in generale) su diversi nodi della rete. ICI n+1 PDU Layer n+1 IDU Layer n ICI n SDU n Protocol Machine PCI n SDU = n PDU

Comunicazioni virtuali vs. Comunicazioni reali
Segmentazione e riassemblaggio di uno SDU 4PDU = 3SDU

Segmentazione e riassemblaggio
Segmentazione e riassemblaggio, nel mondo OSI, sono funzioni tipiche sia del layer 3 che del layer 4. In un mondo message based se c’e’ segmentazione deve esserci anche riassemblaggio. IP, che e’ message based e supporta la segmentazione, deve di conseguenza supportare anche il riassemblaggio TCP pero’ e’ stream based, non message based: quindi il servizio TCP non e’ costretto a mantenere l’identita’ dei TSDU. Non ha senso parlare di riassemblaggio. La nozione di segmentazione assume un significato completamente diverso come possibilita’ da parte della protocol entity TCP mittente di segmentare e assemblare TSDU come e’ piu’ conveniente per ottimizzare l’utilizzo della rete. Esercizio: disegnare una serie di scenari che evidenzino come TCP puo’ gestire liberamente la trasmissione in rete e il prolungamento al cliente lato RX dei TSDU.

Servizi e Protocolli Un servizio rappresenta un insieme di operazioni che un layer servitore mette a disposizione di un layer cliente. Un servizio e' correlato all'interfaccia tra due layer su uno stesso nodo. Un protocollo e' un insieme di regole che governano il formato e il significato (l'effetto) dei PDU che sono scambiati fra due entita' di pari livello (in generale, su due nodi diversi). Le entita' di un layer utilizzano il protocollo per dialogare tra loro e realizzare i servizi offerti dal layer. Le diverse protocol entity di un layer sono distribuite su piu’ nodi, e per riuscire a fornire il servizio devono poter interagire tra loro. Dal punto di vista del cliente del layer, il protocollo puo' anche cambiare, purche' non cambi il servizio offerto: se cambia il protocollo ma non il servizio offerto da un layer, il ruolo del layer nell'architettura di rete rimane invariato.

Servizi e Protocolli Tanenbaum:
"The specification of a network architecture must contain enough information to allow to implement each layer so that it will correctly obey the appropriate protocol (e quindi sara’ capace di interoperare con i suoi pari). Neither the details of the implementation nor the specification of the interfaces (le API locali di ciascun layer che definiscono implementativamente i servizi forniti o utilizzati dai diversi layer) is part of the architecture because these are hidden inside the machine and not visible from the outside. It is not even necessary that the interfaces on all machines in a network be the same, provided that each machine can correctly use all the protocols.”

Servizi e Protocolli In effetti molte interfacce di rete sono "difficilmente" accessibili al normale programmatore (e.g. interfacce dei Layer 2 e 3). In realta’ sui sistemi operativi piu’ diffusi anche l’accesso ai servizi di questi Layer avviene tramite l’API socket, ma questa consente modalita’ di utilizzo del servizio molto piu’ complesse di quelle utilizzate per il Layer di Trasporto Pero‘: ci sono interfacce (e.g. quella del Layer di Trasporto) che e' essenziale siano standardizzate se si vuole ottenere la portabilita' delle applicazioni di rete.

Domande e risposte Possono interagire correttamente tra di loro due clienti del Servizio di Trasporto se Il primo usa l’API Socket di Java per accedere al Servizio di Trasporto TCP mentre il secondo usa l’API socket in C? Si’. Il primo usa l’API TLI in C per accedere al Servizio di Trasporto TCP mentre il secondo usa l’API socket in C? Si’. Entrambi usano l’API socket in C per accedere al Servizio di Trasporto, ma uno utilizza quello TCP e l’altro quello UDP? No. Entrambi usano l’API socket in C per accedere al Servizio di Trasporto, ma uno utilizza quello TCP e l’altro quello OSI COTS? No. Perche’ il nome Open Systems Interconnection (OSI) e’ fuorviante? Perche’ in realta’ stiamo parlando di una interconnessione aperta (protocolli condivisi) di sistemi chiusi (le API dei layer sono definite privatamente dai singoli sistemi)!

Alma Mater Studiorum - Universita' di Bologna Sede di Cesena

Presentazioni simili

Presentazione sul tema: "Alma Mater Studiorum - Universita' di Bologna Sede di Cesena"— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back

Entrare

Autorizzarsi attraverso i social network:

Alma Mater Studiorum - Universita' di Bologna Sede di Cesena

Presentazioni simili

Presentazione sul tema: "Alma Mater Studiorum - Universita' di Bologna Sede di Cesena"— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back