1 LABORATORIO DI INFORMATICA Network Management 2. Applicazioni distribuite OSI e applicazione di System Management Claudio Salati Copyright © 2001 by Claudio Salati ALMA MATER STUDIORUM- UNIVERSITA' DI BOLOGNA FACOLTA' DI INGEGNERIA - SEDE DI CESENA

2 OSI Upper Layers Infrastructure Composta di 3 livelli (del modello di riferimento OSI): 5.Sessione 6.Presentazione 7.Applicazione 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

3 Livello di Presentazione Il servizio di presentazione fornisce gli strumenti per scambiare informazione tra due moduli di una applicazione distribuita in modo tale che il suo significato sia conservato inalterato indipendentemente 1.dalla codifica utilizzata per rappresentare l'informazione durante il trasferimento 2.dalla codifica utilizzata per rappresentare localmente l'informazione sui due moduli/End-System (per i quali possono essere diversi piattaforma HW, sistema operativo, linguaggio di programmazione, sistema di programmazione) Problemi elementari di rappresentazione: Elaboratori big-endian vs. elaboratori little-endian Diversi linguaggi di programmazione utilizzano diverse strutture dati per rappresentare lo stesso tipo di informazione (e.g. anche i numeri interi!) sizeof(int) puo' differire anche in diversi sistemi di programmazione per uno stesso linguaggio Regole di allineamento diverse in diversi sistemi di programmazione per uno stesso linguaggio

4 Sintassi Astratta Un dialogo applicativo coinvolge strutture dati arbitrariamente complesse (e che evolvono nel tempo: e.g. Mail) message { envelope { source address { sender id, mail address,... }, list of destination addresses {... }, cc {... }, bcc {... }, date of submissal {... }, message priority, acknowledge request } content { date of compilation {... }, subject {... }, text {... } } attachments {... }... } Insieme dei tipi di strutture dati coinvolti nel dialogo applicativo tra due moduli di una applicazione distribuita ::= sintassi astratta 1.Come definire in modo non ambiguo una sintassi astratta? 2.Come trasferire sulla rete una istanza di tipo di struttura dati di una sintassi astratta (un valore tipizzato) senza perdere informazione?

5 Risposta 1: Abstract Syntax Notation Un linguaggio capace di descrivere 1.Una sintassi astratta 2.Valori tipizzati appartenenti alla sintasi astratta Senza introdurre o considerare alcun vincolo machine-dependent e/o di rappresentazione. "A level of indirection is placed between the application protocol and how a particular (virtual) machine might represent the data exchanged by that protocol. A protocol specified using an abstract syntax notation is machine independent." (Rose ) In OSI e' definita un'unica abstract syntax notation: ASN.1 Nel mondo Internet esistono diversi linguaggi analoghi: XDR, Corba IDL N.B. Java si basa su un principio diverso: tutte le macchine virtuali Java utilizzano la stessa rappresentazione dei dati

6 Risposta 2: Transfer Syntax Notation Lo scopo di una transfer syntax notation e' di rappresentare in modo non ambiguo i valori dei tipi di strutture dati definiti in una sintassi astratta quando essi sono trasferiti sulla rete. Applicare una sintassi di trasferimento consiste in 1.Prendere una struttura dati locale che in qualche modo rappresenta il valore di una struttura dati definita nella sintassi astratta e 2.Serializzare l'informazione (tipo e valore) in una stringa contigua di ottetti (secondo una particolare regola di codifica, la sintassi di trasferimento) 3.Che puo' essere trasmessa in rete utilizzando i servizi del livello di Sessione. (e fare il percorso inverso in ricezione di una stringa contigua di otteti dal livello di Sessione)

7 Transfer Syntax Notation Il risultato dell'applicazione della sintassi di trasferimento e' una rappresentazione concreta, che implica convenzioni su; Bit e byte order Lunghezza dei campi Encodifica di quanti di informazione... In OSI sono definite diverse transfer syntax notation, ma una sola e' rilevante, BER (Basic Encoding Rules) BER utilizza un approccio TLV. Un valore tipizzato e' codificato come una tripla [Tag, Length, Value ] Dove il campo Tag identifica esplicitamente il tipo di struttura dati di cui si rappresenta una istanza N.B. XDR definisce sia una abstract syntax notation che una sintassi di trasferimento.

8 Servizi del Livello di Presentazione Il Livello di Presentazione combina La capacita' di convertire informazione in stringhe di ottetti (e viceversa) Con il servizio di tasferimento affidabile di byte offerto dal Livello di Sessione per offrire un servizio di trasferimento affidabile di informazione Il Livello di Presentazione si articola in due tipi di servizi: 1.Context Management 2.Syntax Matching

9 Livello di Presentazione: Context Management Nel colloquio tra due moduli di una applicazione distribuita possono essere utilizzate simultaneamente diverse sintassi astratte Ogni sintassi astratta descrive infatti i PDU di un particolare protocollo applicativo Ad ogni sintassi astratta possiamo poi appicare (in teoria) una diversa sintassi di trasferimento Lo scopo del Context Management e' di gestire: 1.Quali sintassi astratte sono usate in un colloquio applicativo 2.Quale sintassi di trasferimento e' associata a ciascuna sintassi astratta Ciascuna coppia [1 + 2] e' identificata nel Livello di Presentazione da un Presentation Context Ogni P-SDU e' associata ad un Presentation Context che identifica univocamento quale e' il protocollo applicativo cui essa e' relativa

10 Livello di Presentazione: Syntax Matching Lo scopo del servizio di Syntax Matching e' di mappare avanti/indietro tra la rappresentazione locale di un valore della sintassi astratta (potenzialmente diversa per ciascun modulo dell'applicazione distribuita) e la sua rappresentazione concreta sulla rete (comune per tutti i moduli)

11 Syntax Matching e Sistemi di Programmazione ASN.1 L'utilizzo di una abstract syntax notation formale consente di automatizzare i due processi di mapping impliciti nel servizio di syntax matching Fase 1, off line: ASN.1 compiler (definisce il mapping internal form abstract syntax) input:un modulo ASN.1 che definisce una sintassi astratta output: 1.La definizione dei tipi di strutture dati locali (e.g. tramite typedef del C) che devono essere usate per rappresentare i tipi di strutture dati definiti nella sintassi astratta 2.Una descrizione tabellare dei tipi di strutture dati della sintassi astratta e delle corrispondenti rappresentazioni locali (e.g. tramite variabili const del C)

12 Syntax Matching e Sistemi di Programmazione ASN.1 Fase 2, on line: ASN.1 run-time system (interprete) (realizza, valore per valore, il mapping internal form transfer syntax) input: 1.La descrizione tabellare dei tipi di strutture dati della sintassi astratta e delle corrispondenti rappresentazioni locali (output 2 della fase 1) 2.In caso di encodifica (il caso di decodifica e' simmetrico): 1.una struttura dati locale (e.g. una variabile C) che rappresenta un valore della sintassi astratta, e 2.l'identita' del relativo tipo di struttura dati ASN.1 output:In caso di encodifica (il caso di decodifica e' simmetrico): la stringa di ottetti che contiene il PDU applicativo (cioe' il P-SDU) encodificato secondo BER

13 Livello Applicativo e Applicazioni Distribuite OSIlayer7OSIlayer7

14 Livello Applicativo e Applicazioni Distribuite Una applicazione distribuita e' costituita da diversi Application Process (AP) che interagiscono tra loro. Tutti gli AP sono eseguiti nell'ambiente OSI, possibilmente su diversi nodi della rete Gli aspetti comunicazionali di un AP sono rappresentati dalla sua Application Entity (AE), che e' una istanza del Livello Applicativo Un AP puo' presentare diversi aspetti comunicazionali, e quindi includere diverse AE (noi consideriamo solo il caso di AP con una sola AE) Una AE e' composta da un insieme di Application Service Element (ASE) Un ASE e' un modulo che realizza una specifica funzionalita' del Livello Applicativo OSI, e.g. il supporto RPC Ogni ASE e' associato ad una sintassi astratta che definisce il protocollo con cui l'ASE interagisce con il suo pari remoto

15 AE, ASE, Application Context Ciascun ASE ha interazioni remote solo con il proprio ASE corrispondente Ogni ASE dell'AE e' associato ad un diverso Presentation Context, cosi' che ciascun A-PDU puo' essere de/codificato correttamente e consegnato all'ASE appropriato Due AE che interagiscono tra loro devono essere composte esattamente con gli stessi ASE In realta', per poter interagire tra loro due AE devono essere istanze di un medesimo Application Context (AC) Un AC identifica un insieme di ASE piu' l'insieme di regole che governano le loro interazioni: esso costituisce la ricetta con cui e' strutturato e funziona un AE che ne e' una istanza regola quindi anche il comportamento dello user element dell'AE, e le sue interazioni con gli ASE e, tramite loro, con lo user element remoto Ogni AC deve essere registrato presso ISO, che gli assegna un identificatore univoco

16 Application Context Quali ASE compongono l'AE (e quindi quali sintassi astratte vengono utilizzate) Significato dello user element Discipline di interazione degli ASE tra loro e con lo user element (e.g. un ASE puo' fare uso o meno dei servizi di un altro ASE) Discipline di comportamento degli ASE (e.g. quali RPC sono chiamabili dall'AE che apre l'associazione e quali dall'altra) Quale e' la sintassi di trasferimento associata a ciascuna sintassi astratta Due AE, per interoperare correttamente, devono avere identico AC, cioe' devono essere dello stesso tipo

17 Indirizzamento di un AE Ogni AE (e quindi ogni AP) puo' avere un nome (Application Entity Title, AET) Un AET non e' utilizzabile direttamente per indirizzare l'AE Per indirizzare una AE (e quindi un AP) si utilizza il suo PSAP: il PSAP di una AE e' univoco sulla rete OSI Un AET puo' essere tradotto nel corrispondente PSAP da un name server (e.g. X.500) Struttura di un PSAP NSAPT-SELS-SELP-SEL NSAP NET + N-SEL (nel mondo IP equivale sostanzialmente alla coppia IP address + transport protocol type)

18 ASE ASE generici: progettati per essere utilizzabili in diversi application context ACSE, Association Control Service Element ROSE, Remote Operations Service Elelment CCR, Commitment, Concurrency and Recovery … ASE specifici: progettati per essere utilizzati in uno specifico application context, anche se puo' capitare che siano utilizzabili in contesti diversi CMISE, Common Management Information Servce Element X.400, posta elettronica X.500, Name Service FTAM, File Transfer, Access and Management MMS, Manufacturing Message System …

19 ACSE, Association Control Service Element ACSE e' l'ASE responsabile della gestione dell'associazione tra due AE Percio' tutti gli application context OSI devono contenere ACSE Una associazione e' una connessione di livello applicativo tra due AP, che sono indicati come l'initiator e il responder Durante la creazione dell'associazione ACSE permette anche di Validare l'application context di initiator e responder Supportare l'autenticazione delle controparti Negoziare i profili utilizzati dagli ASE dell'application context

20 ACSE: servizi e protocollo servizioprimitivePDUP-service A-ASSOCIATEreq/ind resp/conf AARQ AARE P-CONNECT A-RELEASEreq/ind, resp/conf RCRQ RCRE P-RELEASE A-ABORTreq/indABRTP-U-ABORT A-P-ABORTind P-ABORT

21 Servizi OSI: descrizione Servizio Confermato

22 Servizi OSI: descrizione I parametri passati dal service user nella primitiva.req (.resp) vengono inseriti dal service provider nella corrispondente primitiva.ind (.conf, rispettivamente), e sono cosi' trasmessi al service user remoto Service provider Service User S.req(p1, …, pn) S.ind(p1, …, pn)

23 Servizi OSI: descrizione Servizio Non Confermato

24 Servizi OSI: descrizione Servizio Iniziato dal Provider

25 ROSE, Remote Operations Service Element ROSE fornisce i meccanismi di base per supportare RPC Fornisce l'equivalente delle istruzioni CALL (RO-INVOKE) e RETURN (RO-RESULT) in ambiente distribuito Le generalizza in modo analogo a quanto fa Unix per il supporto della programmazione concorrente con le system call fork() e exit()/wait() Consente quindi di avere Procedure non confermate Chiamate non bloccanti Esecuzione concorrente da parte di un chiamante di piu' procedure chiamate (nota che cio' rende necessario potere individuare quale e' la procedura chiamata che e' terminata: ogni chiamata e' battezzata con un invokeID univoco) Ritorni differenziati di successo e di errore

26 ROSE Semantica RPC supportata da ROSE: exactly-once Nei sistemi di programmazione distribuita name binding e type checking sono effettuati dinamicamente Non e' ROSE che e' responsabile di name binding e type checking, ma il cliente di ROSE, chi usa RO-notation per definire i prototipi delle RPC che vuole implementare RO-notation fornisce un linguaggio per scrivere lo header file di un modulo distribuito basato sui servizi di ROSE La definizione dell'interfaccia di una operazione remota tramite RO- notation e' puramente sintattica (signature) La semantica dell'operazione remota (il corpo della procedura che implementa l'operazione remota) e' de/scritta in linguaggio convenzionale (e.g. C)

27 ROSE: servizi e protocollo servizioprimitivePDUP-service RO-INVOKEreq / indROIVP-DATA RO-RESULTreq / indRORSP-DATA RO-ERRORreq / indROERP-DATA RO-REJECT-Ureq / indRORJP-DATA RO-REJECT-PindRORJP-DATA

28 ROSE: ritorni di errore RO-REJECT-P generato dal provider ROSE in caso di ricezione di un PDU malformato RO-REJECT-U generato dal cliente ROSE (e.g. CMISE) per indicare che ha riscontrato un errore di protocollo nella gestione della RPC e quindi, ad es. non ha potuto mettere in esecuzione la procedura richiesta. Ad es. fallimento nel name binding fallimento nel type checking RO-ERROR generato dall'applicazione finale che non e' riuscita a portare a termine con successo l'esecuzione dell'RPC (perche', ad es., non e' riuscita ad aprire un file indicato). La procedura e' pero' stata messa correttamente in esecuzione, ed ha eseguito fino al termine

29 Application Context per la gestione (TMN e OSI) L'applicazione distribuita di gestione e' considerata come una qualunque altra applicazione distribuita L'Application Context di gestione e' definito in X.701 ma solo in linguaggio naturale, senza distinguere tra i ruoli di manager e di agent, e senza precisare chi e' responsabile dell'apertura dell'associazione L'Application Context comprende i seguenti ASE ACSE ROSE CMISE + run-time system GDMO (parte dello user element) + SMASE (parte dello user element, definiti in X.721, X.73x)

30 Struttura AP Agent

31 CMISE, Common Management Information Service Element Definisce le RO OSI utilizzate come metodi delle managed object classes definite in GDMO I servizi CMISE si configurano come operazioni sugli oggetti della MIB che il manager invoca sull'agent o che l'agent invoca sul manager CMISE definisce 7 elementi di servizio che vengono implementati tramite operazioni remote (ovviamente definite in RO- notation) 7 operazioni confermate, una per servizio (confermato) 3 operazioni non confermate, una per ciascuno dei servizi che possono anche essere invocati in modo non confermato 1 operazione call-back per consentire ai servizi (confermati) CMISE di prevedere risposte multiple

32 CMISE: servizi M-GET confermato client = manager / server = agent consente la ricerca e il recupero di informazioni in un sistema gestito attraverso l'acquisizione del valore di uno o piu' attributi di uno o piu' oggetti M-SET confermato o non confermato client = manager / server = agent consente la modifica dello stato di un sistema gestito attraverso la modifica del valore di uno o piu' attributi di uno o piu' oggetti

33 CMISE: servizi M-CREATE confermato client = manager / server = agent consente la modifica dello stato di un sistema gestito attraverso la creazione di un nuovo oggetto nella MIB M-DELETE confermato client = manager / server = agent consente la modifica dello stato di un sistema gestito attraverso la cancellazione di uno o piu' oggetti dalla MIB

34 CMISE: servizi M-ACTION confermato o non confermato client = manager / server = agent consente di invocare su uno o piu' oggetti l'esecuzione di un metodo specifico definito nel modello informativo M-CANCEL-GET confermato client = manager / server = agent consente al manager di abortire una operazione di M-GET richiesta precedentemente

35 CMISE: servizi M-EVENT-REPORT confermato o non confermato client = agent / server = manager consente di invocare su un oggetto l'esecuzione di un metodo specifico definito nel modello informativo. Di norma viene utilizzato solo per consentire all'agent di informare il manager di una variazione (spontanea o richiesta dal manager) dello stato del sistema gestito. Per questo scopo i metodi specifici sono definiti in X.721, e gli eventi che possono essere notificati comprendono: creazione o cancellazione di un oggetto nella MIB variazione del valore di uno o piu' attributi di un oggetto allarme