ALMA MATER STUDIORUM- UNIVERSITA' DI BOLOGNA
FACOLTA' DI INGEGNERIA - SEDE DI CESENA
LABORATORIO DI INFORMATICA
Network Management
2. Applicazioni distribuite OSI e
applicazione di System Management
Claudio Salati
Copyright © 2001 by Claudio Salati
1
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
2
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
3
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?
4
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
5
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)
6
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.
7
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
8
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
9
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)
internal form
this mapping is strictly a local matter
abstract syntax
this mapping consists of consulting
the presentation context
for the data type and
applying the associated
transfer syntax
transfer syntax
10
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)
11
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
12
Livello Applicativo e Applicazioni Distribuite
AP a
AP b
user protocol
user application
O
S
I
l
a
y
e
r
7
user application
application
service
user element
user element
application
ASE #1 ... ASE #n
AE
ASE #1 ... ASE #n
protocol
AE
presentation service
PSAP
PSAP
presentation provider
13
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
14
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
15
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
16
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
NSAP
T-SEL
S-SEL
P-SEL
 NSAP  NET + N-SEL
(nel mondo IP equivale sostanzialmente alla coppia IP address
+ transport protocol type)
17
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
…
18
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
19
ACSE: servizi e protocollo
servizio
primitive
PDU
P-service
A-ASSOCIATE
req/ind
resp/conf
AARQ
AARE
P-CONNECT
A-RELEASE
req/ind,
resp/conf
RCRQ
RCRE
P-RELEASE
A-ABORT
req/ind
ABRT
P-U-ABORT
A-P-ABORT
ind
P-ABORT
20
Servizi OSI: descrizione
Servizio Confermato
service user
service
provider
service user
CS.req
CS.ind
CS.resp
CS.conf
21
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 User
S.req(p1, …, pn)
Service
provider
Service User
S.ind(p1, …, pn)
22
Servizi OSI: descrizione
Servizio Non Confermato
service user
service
provider
service user
NCS.req
NCS.ind
23
Servizi OSI: descrizione
Servizio Iniziato dal Provider
service user
service
provider
service user
PS.ind
24
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
25
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 ROnotation 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)
26
ROSE: servizi e protocollo
servizio
primitive
PDU
P-service
RO-INVOKE
req / ind
ROIV
P-DATA
RO-RESULT
req / ind
RORS
P-DATA
RO-ERROR
req / ind
ROER
P-DATA
RO-REJECT-U
req / ind
RORJ
P-DATA
RO-REJECT-P
ind
RORJ
P-DATA
27
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
28
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)
29
Struttura AP Agent
attributes behaviours
behaviours M
attributes
attributes
behaviours M M O
operationsnotifications
notifications
O O k
operations
operations
notifications 1 2
selector
event detection
event forwarding
discr. processing
SET/GET/ACTION
CREATE/DELETE
L
O
G
MIB e
risorse reali
SMASE e
User Element
EVENTREPORT
CMISE
ROSE
ACSE
PSAP
presentation service provider
30
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 7+3+1 operazioni remote (ovviamente definite in ROnotation)
• 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
31
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
32
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
33
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
34
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
35