Questa lezione e' in gran parte derivata dal libro:
M. T. Rose, "The Open Book, A practical perspective on OSI", Prentice-Hall, 1989.
Tutti i testi in inglese che compaiono in queste pagine, che siano o no virgolettati, sono tratti da questo libro.
Un ringraziamento anche alla vecchia SIP per avermi, inconsapevolmente, dedicato un nome OBJECT IDENTIFIER:
{ ccitt network-operator(3) sip(2222) sgsdh(0)
informationModel(0) sipItaltel(100) } Acknowledgements
Il problema:
The decoupling of the virtual data types exchanged by a protocol and the actual data structures that reside in a particular implementation.
La soluzione si basa su due nozioni:
Abstract representation: each data type is described without regard to machine-oriented structures and restrictions;
Concrete representation: a given instance of a data type may be transmitted on the network using an octet stream.
The representation used must result in an unambiguous understanding between the sender and receiver as to the value (valore tipizzato!) of the data type. DEFINIZIONE DEL PROBLEMA
"In the early days types were simple. Abstract representation focused on avoiding the pitfalls of byte and bit ordering of machine-oriented structures.
This tended to blur the distinction between the abstract and the concrete:
data types were defined using diagrams that described the packet formats of the protocol.
In the 80's, the data types exchanged by application layer protocols became arbitrarily complex.
Formal languages are now used for precise definitions.
In OSI, the Abstract Syntax Notation One (ASN.1) language is used to describe data types.
ASN.1 is distinct from the mechanisms used to produce concrete representations. However, the Basic Encoding Rules (BER) were defined for ASN.1 so that data could be unambiguously transmitted." [M.T. Rose, "The open book"] EVOLUZIONE DEL PROBLEMA
PERCHE' STRUTTURE DATI COMPLESSE ? perche' le informazioni accedute tramite rete sono piu' complesse e con un numero di tipi di dato molto piu' vasto,
perche' una applicazione puo' allargare il numero di tipi di dato gestiti
perche' il tipo di dato acceduto attraverso la rete non e' necessariamente noto a priori a chi lo accede
(ad esempio un browser attraverso un directory service).
L'approccio OSI 1 the specification of the protocol used by the distributed application defines each data type using an abstract representation (e.g. ASN.1)
The language used defines the conceptual aspects of a data type, but does not contain rules for how the data type might be realized on a real computer;
an implementor defines concrete local data types equivalent to the abstract data types using a programming language that is native to its machine (e.g. C).
These are concrete representations, defined by a particular processor, language, compiler, run-time system;
when it is time to transmit a value of a data type, 2 mappings must be performed:
m1. the concrete local data structure is mapped to the abstract syntax for the data type, and
m2. a transfer syntax is applied to the abstract syntax to obtain the transfer value corresponding to the value of the data type to be transmitted.
when it is time to receive a value of a data type, the inverse mappings, in the reverse order, are applied.
L'approccio OSI 2 Mapping m1 is conceptual.
In effetti questo mapping avviene a priori, in quanto e' il sistema di programmazione ASN.1 che indica quali sono le strutture dati locali che devono essere utilizzate per rappresentare i tipi definiti in una sintassi astratta.
Mapping m2 is where the real work occurs.
The encoding rules take the abstract data type definitions along with a given value as a local data structure and produce an unambiguous representation.
This is called serializing, and results in a string of octects being generated that encodes the value of the data type.
ABSTRACT SYNTAX NOTATION ONE - ASN.1 "ASN.1 defines a set of primitive data types and provides a facility to construct new data structures with their own typing inherent in the structure."
(cosi’ come in C
il nome-tag di una struct e’ inerente alla struttura, mentre
il nome-typedef e’ solo un identificatore della struttura stessa)
This allows new data types to be defined that are uniquely recognizable within an application.
(per tipo si intende struttura dati, come in C e Pascal)
ASN.1 definisce anche una sintassi per rappresentare valori tipizzati.
L'informazione di tipo e' inerente anche ai valori.
ASN.1: LESSICO "An ASN.1 description consists of a sequence of 5 kinds of tokens:
1. words (identificatori),
2. numbers (valori letterali numerici),
3. strings (di character, hex, bin. Valori letterali stringa),
4. punctuation (e operatori),
5. reserved words (keywords: solo lettere maiuscole).
Comments (che iniziano con "--" e finiscono con "--" o EOLN) may be placed wherever whitespace is valid."
Come esempi di testi ASN.1 vedi
il modulo Remote-Operations-APDUs riportato nel seguito di questa lezione e
il modulo SNMPv2-PDU riportato in Lez. 3-1
ASN.1: MODULI Module: a collection of ASN.1 descriptions specifying a protocol (detto anche sintassi astratta)
The <> term names the module. Consists of 2 parts:
a name, e.g. CMIP-1 (per esseri umani e moduli ASN.1)
an (optional) OBJECT IDENTIFIER, which provides an authoritative name (per altri moduli ASN.1 e per uso run-time)
<> relates the module with other modules, by IMPORTing and EXPORTing objects.
<> consente la compilazione separata di moduli ASN.1.
<> contains the actual ASN.1 definitions. <> DEFINITIONS <> ::=
BEGIN
<>
<>
END
ASN.1: scambio di informazioni tra moduli IMPORTS
<> FROM <>
...
<> FROM <> ;
Rende visibili nel modulo corrente le costanti e i tipi listati, definiti nel (e esportati dal) modulo indicato.
Un simbolo definito in un altro modulo puo' essere riferito anche se non e' IMPORTato, purche' sia riferito in modo qualificato:
<>.<>
Questo costrutto puo’ essere utilizzato anche per disambiguare riferimenti a simboli uguali importati da moduli diversi
ASN.1: scambio di informazioni tra moduli EXPORTS <>;
Rende visibili all'esterno del modulo i tipi e le costanti listati e definiti nel modulo.
Se la clausola EXPORTS non e' presente tutte le definizioni contenute nel modulo sono esportate.
ASN.1: tipi, valori, simboli 3 kinds of objects (identificatori, simboli) are defined:
tipi, identificati da una parola che inizia con lettera maiuscola;
valori, identificati da una parola che inizia con lettera minuscola;
macro, identificati da una parola tutta di lettere maiuscole.
Come in C e in Pascal
ogni simbolo che viene riferito in un modulo deve essere anche definito o dichiarato (importato) in quel modulo
A differenza che in C e in Pascal
un riferimento ad un simbolo non deve essere preceduto nel testo dalla definizione/dichiarazione del simbolo stesso
normali regole di stile ASN.1 (non applicate nel framework SNMP!)
le definizioni di valori precedono le definizioni di tipi, e
le definizioni sono in ordine alfabetico
ASN.1: definizione di tipi e valori (di simboli)
An ASN.1 type is defined as follows:
NameOfType ::= TYPE-DENOTATION
In realta’ questo statement non rappresenta la definizione di un nuovo tipo ma piuttosto, come lo statement typedef del C, l’associazione di un nuovo identificatore (NameOfType) ad un tipo (TYPE-DENOTATION)
An ASN.1 value (instance of a data type) is defined as follows:
nameOfValue NameOfType ::= VALUE
dove VALUE e' descritto secondo la ASN.1 value notation.
ASN.1: tipi semplici BOOLEANI
Read-only ::= BOOLEAN
modifiable Read-only ::= TRUE -- or FALSE
INTERI
ContentLength ::= INTEGER
length ContentLength ::= 100
Il tipo INTEGER ASN.1 rappresenta valori interi di dimensione illimitata.
E' possibile restringere esplicitamente l'insieme dei valori ammessi attraverso il subtyping (come fa il framework SNMP).
Forma alternativa, in cui si listano tutti e soli i valori legittimi:
OpCodeLen ::= INTEGER {
single-byte (1),
double-byte (2),
long-opcode (4) }
multLen OpCodeLen ::= long-opcode -- or 4
ASN.1: tipi semplici ENUMERATI
OpCodeLen ::= ENUMERATED {
single-byte (1),
double-byte (2),
long-opcode (4) }
multLen OpCodeLen ::= long-opcode -- or 4
I valori ENUMERATED non hanno significato come INTEGER e non possono essere utilizzati in operazioni tra e con interi.
A valori enumerati non si possono nemmeno applicare operatori interi, ad esempio operatori relazionali per il subtyping.
N.B.: tutti i diversi tipi enumerati hanno la stessa informazione inerente di tipo
come fare a distinguere tra diversi tipi enumerati?
REALI
Anche i valori REAL possono avere dimensione (e precisione) arbitraria.
ASN.1: tipi semplici STRINGHE DI BIT
A BIT STRING type is a data type taking zero or more bits as its values.
BIT STRING may describe objects that are not octet-aligned.
Una forma alternativa di BIT STRING permette di nominare i singoli bit della stringa in modo individuale.
In questo caso tutti i bit della stringa sono significativi
FacsimilePage ::= BIT STRING
Attribute-Groups ::= BIT STRING {
read (0), write (1), execute (2)
}
access-right Attribute-Groups ::=
{ read, write } -- or '110'B
ASN.1: tipi semplici STRINGHE DI BYTE
An OCTET STRING is a data type taking zero or more octets as its value.
UserName ::= OCTET STRING
initiator UserName ::= "anon" -- or '616E6F6E'H
le OCTET STRING sono basate sull'alfabeto ASCII (a 8 bit)
OCTET STRING speciali, predefinite (sub-typing) dal linguaggio:
NumericString: stringa di caratteri numerici (base 10)
PrintableString: stringa di caratteri stampabili
IA5String: stringhe di caratteri che appartengono all'alfabeto ITU No. 5
GraphicString: stringhe di caratteri stampabili che appartengono all'alfabeto ITU No. 5
continua alla pagina seguente
ASN.1: tipi semplici STRINGHE DI BYTE
OCTET STRING speciali, predefinite dal linguaggio (continua):
UTCTime: stringa di caratteri che rappresenta data-ora (Universal Time Coordinated) secondo un formato definito
il formato e' molto simile a quello di GeneralizedTime
ma non e' millennium compliant (manca l'indicazione di secolo)!
e' utilizzata nel framework di gestione Internet
GeneralizedTime: stringa di caratteri che rappresenta data-ora (UTC) secondo un formato definito
e' millennium compliant
consente di effettuare il confronto di istanti come confronto di stringhe
YYYYMMDDHHMMSS.dcm
e' utilizzata nel framework di gestione ITU/OSI
esiste in 3 varianti
ASN.1: tipi semplici GeneralizedTime
"YYYYMMDDHHMMSS.dcm" nel fuso locale
"YYYYMMDDHHMMSS.dcmz" tempo astronomico di Greenwich
"YYYYMMDDHHMMSS.dcmHHMM" nel fuso locale t tra fuso locale e tempo astronomico di Greenwich
Esempio: lo stesso istante nelle 3 rappresentazioni:
"20020107103142.8" nell'Europa centrale
"20020107093142.8z" del tempo astronomico di Greenwich
"20020107103142.8-01" in rappresentazione differenziale
E quando inizia/finisce l'ora legale si hanno discontinuita'/ duplicazioni temporali (e.g. problemi con misure periodiche di performance e con time stamping di eventi di rete)?
NO, quando inizia l'ora legale si sposta avanti di un'ora l'ora locale ma ci si sposta di fuso per evitare la discontinuita!
Durante il periodo dell'ora legale l'Italia e' in Europa orientale e il Regno Unito in Europa centrale
Comments