ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA
FACOLTA' DI INGEGNERIA - SEDE DI CESENA
LABORATORIO DI INFORMATICA
Network Management
3. Il linguaggio ASN.1
3.2 Descrizione del linguaggio
Claudio Salati
Copyright © 2001 by Claudio Salati
1
Acknowledgements
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) }
2
DEFINIZIONE DEL PROBLEMA
•
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:
1. Abstract representation: each data type is described without
regard to machine-oriented structures and restrictions;
2. 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.
3
EVOLUZIONE 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"]
4
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).
5
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.
6
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.
7
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.
8
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
9
ASN.1: MODULI
• Module: a collection of ASN.1 descriptions specifying a protocol
(detto anche sintassi astratta)
<<module>> DEFINITIONS <<implicit>> ::=
BEGIN
<<linkage>>
<<declarations>>
END
• The <<module>> 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)
• <<linkage>> relates the module with other modules, by
IMPORTing and EXPORTing objects.
<<linkage>> consente la compilazione separata di moduli ASN.1.
• <<declarations>> contains the actual ASN.1 definitions.
10
ASN.1: scambio di informazioni tra moduli
• IMPORTS
<<lista di tipi e/o costanti>> FROM <<nome del modulo>>
...
<<lista di tipi e/o costanti>> FROM <<nome del modulo>> ;
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:
<<identificatore modulo>>.<<identificatore simbolo>>
• Questo costrutto puo’ essere utilizzato anche per disambiguare
riferimenti a simboli uguali importati da moduli diversi
11
ASN.1: scambio di informazioni tra moduli
•
EXPORTS
<<lista di tipi e/o costanti esportati dal modulo>>;
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.
12
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
13
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.
14
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 415
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.
16
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
17
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
18
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 dataora (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
19
• esiste in 3 varianti
ASN.1: tipi semplici
• GeneralizedTime
• "YYYYMMDDHHMMSS.dcm" nel fuso locale
• "YYYYMMDDHHMMSS.dcmz" tempo astronomico di Greenwich
• "YYYYMMDDHHMMSS.dcmHHMM" 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
20
ASN.1: tipi semplici
• NULL
• A NULL type is a data type that is simply a place-holder.
• The only information conveyed is whether the data type is present
(un po’ come il tipo void del C)
• Suppose a data type normally has a value associated with it, but
under some circumstances the value is undefined.
• The NULL type allows to extend with the "undefined value" the
domain of a data type.
(NULL rappresenta quindi un place-holder anche per un valore, il
che non accade in C. In questo senso la parentela e’ piuttosto con
il valore C NULL di tipo void*)
TimeOfDay ::= CHOICE { UTCTime, NULL }
unknownTime TimeOfDay
::= NULL
21
ASN.1: tipi semplici
• OBJECT IDENTIFIER
• OBJECT IDENTIFIER is a data type denoting an authoritatively
named object.
• Qualsiasi cosa puo' essere identificata con un OBJECT
IDENTIFIER.
• Un OBJECT IDENTIFIER e' una sequenza di numeri interi non
negativi che attraversa un albero
• ogni intero e' il nome relativo univoco di un figlio rispetto al
padre
• ogni nodo dell'albero ha autorita' di denominazione sui suoi
discendenti
• in particolare, sotto la radice dell'albero, sono riconosciute 3
autorita' di denominazione
• ccitt
(0)
• iso
(1)
• joint-iso-ccitt (2)
• concatenando un intero (una sequenza di interi) ad un OBJECT
22
IDENTIFIER si ottiene un nuovo OBJECT IDENTIFIER
ASN.1: costruttori di tipo e tipi costruiti
• Symple types can be combined to build complex data types.
• The constructor types are used for this purpose.
• The process is recursive:
 constructor types combine both simple and other constructor
types, of arbitrarily deep nesting.
23
ASN.1: costruttori e tipi costruiti, SEQUENCE
• A SEQUENCE type is a data type denoting an ordered list of zero or
more (ma in numero de/finito) elements, each of which are ASN.1
types.
• E' "equivalente" ad un RECORD Pascal o una struct C.
VarBind ::= SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
• I nomi (labels) degli elementi della SEQUENCE
• non fanno parte strutturale del tipo, tanto che potrebbero essere
assenti (e non sono trasmessi sulla rete!)
• servono
a. per aumentare la leggibilita' (potrebbero essere assenti),
b. ma anche per disambiguare la descrizione di valori nella
value notation ASN.1 nel caso di campi OPTIONAL o
DEFAULT.
24
ASN.1: SEQUENCE, esempio di valore
{ { givenName
"John",
initial
"P",
familyName
"Smith" },
title
"Director",
age
51,
dateOfHire"19710917",
nameOfSpouse { givenName
"Margaret",
initial
"T",
familyName
"Smith" },
children {
{ { givenName "Ralph",
initial
"T",
familyName"Smith" },
dateOfBirth "19571111" },
{ { givenName "Susan",
initial
"B",
familyName"Smith" },
dateOfBirth "19590717" } }
}
25
ASN.1: SEQUENCE, campi opzionali e default
1
Interrupt-Request ::= SEQUENCE {
fatal-error
BOOLEAN
DEFAULT TRUE,
message
PrintableString OPTIONAL
}
fatal1 Interrupt-Request :: = {}
-- equivale a { fatal-error TRUE }, message assente
fatal2 Interrupt-Request :: = {
message
"this is a fatal request" }
-- equivale a { fatal-error TRUE,
-message "this is a fatal request" }
fatal2bis Interrupt-Request :: = { "fatal request" }
-- equivale a { fatal-error TRUE,
-message
"fatal request" }
nonFatal Interrupt-Request :: = { FALSE }
-- equivale a { fatal-error FALSE }, message assente
-- fin qui le label migliorano solo la leggibilita'
26
ASN.1: SEQUENCE, campi opzionali e default
T1 ::= SEQUENCE {
BOOLEAN,
BOOLEAN
}
2
v1 T1 ::= {
FALSE,
TRUE
}
-- f1 ha valore FALSE ed f2 ha valore TRUE
T2 ::= SEQUENCE {
BOOLEAN DEFAULT TRUE,
BOOLEAN DEFAULT TRUE
}
v2 T2 ::= {
FALSE
}
-- quale e' il campo con valore TRUE
-- e quale quello con valore FALSE?
T2 ::= SEQUENCE {
v2 T2 ::= {
f1 BOOLEAN DEFAULT TRUE,
f2 FALSE
f2 BOOLEAN DEFAULT TRUE
}
}
27
ASN.1: SEQUENCE, campi opzionali e default
3
-- continua
-- f1 ha valore TRUE ed f2 ha valore FALSE: ma cosi'
-- ho disambiguato solo la comunicazione con
-- l'essere umano:
-- i nomi dei campi non viaggiano in rete!
-- Questa soluzione non basta a disambiguare il
-- significato di un valore sulla rete!
• Il problema di ambiguita' che abbiamo visto e' interno allo scope
della SEQUENCE
• In realta' esiste un problema di ambiguita' ancora piu' significativo tra
SEQUENCEdiverse:
 tutti i diversi tipi SEQUENCE hanno la stessa informazione
inerente di tipo
 come fare a distinguere tra diversi tipi SEQUENCE?
28
ASN.1: SEQUENCE
 La sintassi astratta non deve essere tale da creare possibilita' di
ambiguita' alla sintassi di trasferimento,
come nel caso di due campi
 opzionali o default
 adiacenti
 dello stesso tipo!
(Vedi tags)
 I campi di una SEQUENCE sono riconosciuti, nell'ordine,
 dalla posizione
 dal tipo
 una situazione e' considerata ambigua se non puo' essere risolta da
un processamento in linea
29
ASN.1: costruttori e tipi costruiti, SEQUENCE OF
 A SEQUENCE OF type is a data type denoting an ordered list of
zero or more (in numero indefinito) elements of the same type.
 This is analogous to a dynamic array in many programming
languages: the number of elements is unbounded, but each element
has identical syntax.
RoutingTable ::= SEQUENCE OF RoutingEntry
 notare che anche per il riconoscimento di diverse SEQUENCE OF
esiste un problema intrinseco di ambiguita’:
 tutte le SEQUENCE OF hanno intrinsecamente la stessa
informazione inerente di tipo,
 che tra l’altro e’ uguale a quella associata al costruttore
SEQUENCE!
30
ASN.1: costruttori e tipi costruiti, SET e SET OF
 A SET type is a data type denoting an unordered list of zero or more
(ma di numero definito) members.
 In una SEQUENCE gli elementi possono essere disambiguati
dall'ordine, mentre cio' non e' possibile in un SET, dove ogni
elemento deve essere distinguibile per il suo tipo. (Vedi tags)
 Ma cosa succede se due elementi sono dello stesso tipo?
 Ambiguita’!
 Unordered list di zero o piu' (in numero indefinito) elementi tutti
dello stesso tipo sono specificabili attraverso il costruttore SET OF!
 notare che per il riconoscimento di diversi SET (e SET OF) esiste un
problema intrinseco di ambiguita’:
 tutti i SET (e SET OF) hanno intrinsecamente lo stessa
informazione inerente di tipo!
31
ASN.1: costruttori e tipi costruiti: tagged types
• Come fare a distinguere diverse occorrenze dello stesso tipo di dato
all'interno di un tipo costruito?
• E in generale, come fare a identificare univocamente un tipo di dato
(quando un valore e' inviato in rete)?
• e.g.: come distinguere una SEQUENCE dall'altra?
 ASN.1 associa ad ogni tipo di dato un tag che lo identifica
univocamente
• Poiche' l'identificazione univoca puo' essere a diversi livelli
• (e.g. campi di record in Pascal univoci nello scope definito dal
record stesso),
ci sono 4 tipi (classi) di tag.
• Ogni tag consiste di una coppia di valori che ne specificano
• classe (scope entro cui esso e' univoco) e
• numero univoco nella classe (e nello scope).
32
ASN.1: costruttori e tipi costruiti: tagged types
• Una SEQUENCE puo' essere distinta da un'altra SEQUENCE se la
si tagga esplicitamente, cioe' se si costruisce un nuovo tipo che
• "e' fatto come il il tipo SEQUENCE base" ma che
• ha tag diverso
• Tagging a data type results in "wrapping" the existing data type, tag
and all, inside a new data type.
• The tag associated with a data type is an integral part of the
structure of the data type.
33
ASN.1: TAG di tipo
• identificazione unica per tutte le sintassi astratte descrivibili in
ASN.1:
 UNIVERSAL tags
• identificano univocamente (secondo valori fissati da OSI/ITU al
momento della definizione del linguaggio ASN.1) tipi semplici e
costruttori di tipo (identificazione strutturale anonima).
tipo ASN.1
BOOLEAN
INTEGER
BIT STRING
OCTET STRING
NULL
OBJECT IDENTIFIER
ObjectDescriptor
EXTERNAL
...
ENUMERATED
...
tag universale
1
2
3
4
5
6
7
8
...
10
...
34
ASN.1: TAG di tipo
• identificazione univoca all'interno di una specifica sintassi astratta
(un modulo ASN.1), cioe' di una applicazione descritta in ASN.1:
 APPLICATION-wide tags
• tutti i tipi definiti dalla applicazione e che devono essere
differenziabili tra loro in ricezione dalla rete e che non sono
intrinsecamente di tipo (universale) diverso, devono avere un tag
di questo tipo differente.
• identificazione univoca all'interno di un tipo costruito (e.g.
SEQUENCE), al di fuori del quale questi tag sono privi di significato:
 context-specific tags
• identificazione univoca in un contesto organizzativo:
 PRIVATE-use tags
• non sono in realta' utilizzati
35
ASN.1: TAG di tipo, esempi
IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING
-- IA5String e' fatto come un'OCTET STRING ma e' di
-- tipo UNIVERSAL 22
Priority ::= [APPLICATION 7] ENUMERATED {
normal (0),
non-urgent (1),
urgent (2) }
-- Priority e' fatto come un enumerato ma e' di
-- tipo APPLICATION 7
Severity ::= [8] ENUMERATED {
high (0),
middle (1),
low (2) }
-- Severity e' fatto come un enumerato ma e' di
-- tipo APPLICATION 8 (il default in questa
-- posizione dello statement)
36
ASN.1: TAG di tipo, esempi
ObjectClass ::= CHOICE {
globalForm [0] IMPLICIT OBJECT IDENTIFIER,
localForm
[1] IMPLICIT INTEGER }
-----
globalForm e' fatto come un OBJECT IDENTIFIER ma
e' di tipo contestuale-0
localForm e' fatto come un INTEGER ma
e' di tipo contestuale-1
-- i tag contestuali sono identificati come tali
-- dalla loro posizione nello statement
-- in questo caso non sarebbero stati necessari
-- perche' le deu opzioni sono gia' di tipo
-- (universale) diverso
37
ASN.1: TAG impliciti
• When a data type is wrapped, additional information must be
encoded on the network whenever an instance of that data type is
transmitted.
• If the loss of this information will not prevent interoperation, the
IMPLICIT keyword may be used when defining a tagged type so
that only the explicit tag will be transmitted and not the tag of the
wrapped type.
• E' possibile generalizzare l'uso di IMPLICIT in tutte le definizioni di
un modulo definendo come IMPLICIT TAGS la clausola
<<implicit>> che compare nella testata del modulo
(E' possibile anche utilizzare la clausola (default) EXPLICIT TAGS)
• Esempio: quando viene trasmesso un valore di tipo
IA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRING
viene trasmesso
 solo lo universal tag 22 di IA5String
 e non lo universal tag 4 di OCTET STRING.
• La keyword IMPLICIT e' in effetti una direttiva per la transfer syntax!
38
ASN.1: TAG impliciti
• Perche' e' possibile perdere informazione?
• Consideriamo la seguente sintassi astratta:
Int ::= [APPLICATION 1] IMPLICIT INTEGER
Bool ::= [APPLICATION 2] IMPLICIT BOOLEAN
intVal Int ::= 1
boolVal Bool ::= TRUE
• IntVal e boolVal sono interpretabili, e distinguibili, solo per chi
conosce la semantica dei due tipi "privati dell'applicazione" Int e
Bool.
• Se fosse mancato l'attributo IMPLICIT chiunque, anche senza
questa conoscenza, avrebbe potuto dare la interpretazione corretta.
(e.g. browser attraverso data base)
39
ASN.1: Metatipi, CHOICE
• A CHOICE type is a data type that is defined as the union of one ore
more data types
•  a una union C o alla parte variante di un record in Pascal
• come in quest'ultimo caso, il campo non ha un suo tipo ma
assume di volta in volta il tipo della variante attiva
• in C invece una union e' di per se' un tipo che contiene una di
tante possibili varianti
• Any given instance of this data type takes the value of only one of
the member data types of the union.
Time ::= CHOICE {
actualTime
UTCTime,
notAvailable
NULL }
unixEpoch Time ::= actualTime "700101000000Z"
unknownTime Time ::= notAvailable NULL
• Each member of a CHOICE must be uniquely distinguishable based
on their data types (inclusi i tag ovviamente).
• Cio' e' vero anche quando membro di una CHOICE e' una CHOICE
40
ASN.1: Metatipi, ANY
• An ANY type is a data type that is the union of all possible data types
defined using ASN.1.
• An instance of this data type takes any legal ASN.1 value.
• ANY is used whenever the data type being used is not specified by
the module:
ad esempio, nello specificare un protocollo applicativo, la SDU di
quel protocollo e' specificata come di tipo ANY (come la specifica del
tipo dei parametri di una operazione).
• All'interno di una SEQUENCE o di un SET, ANY puo' comparire
come tipo di un campo nella forma:
ANY DEFINED BY identifier
dove identifier puo' essere il nome di un altro campo della
struttura o uno dei tipi INTEGER o OBJECT IDENTIFIER.
• Ha lo stesso significato di un RECORD variante del Pascal, e
identifier svolge lo stesso ruolo del tag (tipo o campo) della parte
variante del RECORD Pascal.
41
ASN.1: Metatipi
• Metatipi e tag impliciti:
• e' ovvio che un "tipo" ANY non puo' essere taggato come
IMPLICIT
 altrimenti come sarebbe possibile capire quale delle
alternative possibile e' quella attuale?
• e' ovvio che questo vale anche per il "tipo" CHOICE
• il pragma IMPLICIT non ha alcun effetto quando applicato ad un
metatipo
• notare che il pragma IMPLICIT puo' venire applicato anche
implicitamente, quando l'intero modulo e' definito come IMPLICIT
TAGS
• Abbreviazioni (non di uso comune):
• la notazione: SET OF ANY
puo' essere abbreviata in: SET
• la notazione: SEQUENCE OF ANY
puo' essere abbreviata in: SEQUENCE
42
ASN.1: il tipo pre-definito EXTERNAL
• EXTERNAL rappresenta un tipo di dato definito altrove
• ma non importato!
• EXTERNAL e' un tipo di dato definito da ASN.1
• tag = [UNIVERSAL 8]),
anche se non e' un tipo primitivo
• mentre il metatipo ANY deve essere sostituito da un tipo ASN.1, la
definizione del tipo effettivo che e' effettivamente usato come
EXTERNAL non necessariamente e' in ASN.1
• potrebbe essere un programma Java
• la definizione di EXTERNAL consente di indicare i riferimenti che
consentono di interpretare la "cosa" rappresentata dal valore
EXTERNAL
43
ASN.1: il tipo pre-definito EXTERNAL
EXTERNAL ::= [UNIVERSAL 8] IMPLICIT SEQUENCE
direct-reference
OBJECT IDENTIFIER OPTIONAL,
-- documento che definisce la sintassi del tipo di dato
indirect-reference
INTEGER
-- presentation context associato
OPTIONAL,
data-value-descriptor ObjectDescriptor
-- altre info sul data type
OPTIONAL,
encoding
CHOICE {
single-ASN1-type [0]
ANY,
-- se effettivamente il tipo e' definito in ASN.1
octet-aligned
[1]
IMPLICIT OCTET STRING,
-- tipo non definito in ASN.1 ma allineato a ottetto
arbitrary
[2]
IMPLICIT BIT STRING
-- tipo non definito in ASN.1 e non allineato a
-- ottetto
}
}
44
ASN.1: sotto-tipi
• Sono raffinamenti di altri data type ASN.1
• Sono definibili attraverso 3 meccanismi fondamentali:
1. come subrange di interi, reali, caratteri, enumerati, specificabili
tramite
• enumerazione esplicita
• espressioni relazionali,
2. o come dimensione minima o massima (numero di elementi)
che puo' avere un SET, una SEQUENCE o una stringa,
3. o come struttura che puo' assumere un data type costruito con
campi opzionali quando altri campi assumono precisi valori
(inner sub-typing).
• Intrinsecamente un sotto-tipo ha la stessa informazione inerente di
tipo del suo tipo base
45
ASN.1: esempi: sottotipi come sub-range
ProtoType ::= ENUMERATED {
first-class (0),
business-class (1),
coach-class (2),
economy-class (3)
}
SubType ::= ProtoType (coach-class |
economy-class)
TenDigitString ::= PrintableString
(FROM ("1" | "2" | "3" |
"4" | "5" | "6" |
"7" | "8" | "9" |
"0"))
46
ASN.1: esempi: sottotipi come sub-range
ProtoType ::= INTEGER
NonNegativeNumber ::= Prototype (0 .. MAX)
OSIlayers ::= INTEGER
(1 | 2 | 3 | 4 | 5 | 6 | 7)
UpperLayers ::= OSIlayers (4< .. MAX)
47
ASN.1: esempi: sottotipizzazione per dimensionamento
NANplan ::= TenDigitString (SIZE (7 .. 10))
LocNumber ::= NANplan (SIZE (7 .. 7))
LongDistanceNumber ::= NANplan (SIZE (10))
VarBindList ::= SEQUENCE
(SIZE (1..5)) OF VarBind
48
ASN.1: sotto-tipi: inner sub-typing
1
• The inner subtype is used to refine constructor types.
• Inner subtype allows new constructor types to be defined that
indicate
• which portions (opzionali) of other constructor types (di un tipo
base costruito) are present (o assenti),
• possibly with which value (questo, per qualunque campo).
• Esempio: dati i tipi base (che definiscono l'interazione di un cliente
con un name-service)
PDU ::= SEQUENCE {
requestID
operation
error-occurring
binding
RequestID,
ENUMERATED {get
put
Error-Occurring
Binding
(0),
(1)},
OPTIONAL,
OPTIONAL}
Binding ::= SEQUENCE {
name
ObjectName,
value
ObjectSyntax OPTIONAL }
49
ASN.1: sotto-tipi: inner sub-typing
2
• Le singole interazioni di lettura e scrittura possono essere definite
tramite inner sub-typing specializzando il tipo PDU.
• L'operazione di lettura (invocazione e risposta) e' descritta dai due
PDU:
GetRequest ::= PDU (WITH COMPONENTS {
operation
(get),
error-occurring ABSENT
binding
PRESENT (WITH COMPONENTS {
value ABSENT })
})
GetResponse ::= PDU (WITH COMPONENTS {
operation
(get),
binding
PRESENT (WITH COMPONENTS {
value PRESENT })
})
• L'operazione di scrittura (invocazione e risposta) e' lasciata per
esercizio
50
Esempio ASN.1: sintassi astratta di ROSE
1
Remote-Operations-APDUs
{ joint-iso-ccitt remote-operations(4) apdus(1) }
DEFINITIONS ::=
BEGIN
EXPORTS rOSE, InvokeIDType;
IMPORTS
OPERATION, ERROR
FROM Remote-Operation-Notation
{ joint-iso-ccitt remote-operations(4)
notation(0) }
APPLICATION-SERVICE-ELEMENT
FROM Remote-Operations-Notation-extension
{ joint-iso-ccitt remote-operations(4)
notation-extension(2) };
rOSE APPLICATION-SERVICE-ELEMENT ::=
{ joint-iso-ccitt remote-operations(4)
aseID(3) }
51
Esempio ASN.1: sintassi astratta di ROSE
ReturnErrorProblem ::= INTEGER {
unrecognizedInvocation
errorResponseUnexpected
unrecognizedError
unexpectedError
mistypedParameter
2
(0),
(1),
(2),
(3),
(4) }
ReturnResultProblem ::= INTEGER {
unrecognizedInvocation
(0),
resultResponseUnexpected (1),
mistypedResult
(2) }
52
Esempio ASN.1: sintassi astratta di ROSE
3
InvokeProblem ::= INTEGER {
duplicateInvocation
unrecognizedOperation
mistypedArgument
resourceLimitation
initiatorReleasing
unrecognizedLinkedId
linkedResponseUnexpected
unexpectedChildOperation
(0),
(1),
(2),
(3),
(4),
(5),
(6),
(7) }
GeneralProblem ::= INTEGER {
unrecognizedAPDU
mistypedAPDU
badlyStructuredAPDU
(0),
(1),
(2) }
53
Esempio ASN.1: sintassi astratta di ROSE
4
InvokeIdType ::= INTEGER
Operation ::= CHOICE {
localValue
globalValue
INTEGER,
OBJECT IDENTIFIER }
Error ::= CHOICE {
localValue
globalValue
INTEGER,
OBJECT IDENTIFIER}
ROIVapdu ::= [1] IMPLICIT SEQUENCE {
invokeId
InvokeIdType,
linkedId
[0] IMPLICIT InvokeIdType OPTIONAL,
operation-value Operation,
argument
ANY DEFINED BY
operation-value OPTIONAL }
54
Esempio ASN.1: sintassi astratta di ROSE
5
RORSapdu ::= [2] IMPLICIT SEQUENCE {
invokeId
InvokeIdType,
SEQUENCE {
operation-value
result
Operation,
ANY DEFINED BY
operation-value
} OPTIONAL
}
ROERapdu ::= [3] IMPLICIT SEQUENCE {
invokeId
error-value
parameter
InvokeIdType,
Error,
ANY DEFINED BY error-value OPTIONAL }
55
Esempio ASN.1: sintassi astratta di ROSE
6
RORJapdu ::= [4] IMPLICIT SEQUENCE {
invokeId
CHOICE {
invokeId InvokeIdType,
nullNULL },
problem
CHOICE {
gen-prob[0] IMPLICIT GeneralProblem,
inv-prob[1] IMPLICIT InvokeProblem,
res-prob[2] IMPLICIT ReturnResultProblem,
err-prob[3] IMPLICIT ReturnErrorProblem }
}
ROSEapdus ::= CHOICE {
roiv-apdu
rors-apdu
roer-apdu
rorj-apdu
END
-- module
ROIVapdu,
RORSapdu,
ROERapdu,
RORJapdu }
56
ASN.1: value notation
• La sintassi dei valori di ASN.1 fornisce una notazione
leggibile/scrivibile per scambiare valori di data types tra un utente
umano e le implementazioni di protocolli e applicazioni di rete:
• Ad esempio consente di scrivere un programma che effettui il log dei
PDU scambiati in modo leggibile.
• Facilita quindi la realizzazione di
•
analizzatori di protocolli (applicativi)
•
emulatori di protocolli (applicativi)
57
ASN.1: macro
• The ASN.1 macro facility allows the ASN.1 grammar to be extended
to meet the requirements of the abstract syntax designer.
The ASN.1 macro notation literally rewrites the grammar rules of the
ASN.1 language.
• Ma soprattutto: le macro ASN.1 possono avere un contenuto
semantico che non si esaurisce nella loro ritrascrizione
(a differenza di quanto accade con le macro C, troff, assembler, ...).
• Cio' rende complesso trattare le macro come parte dei processori
ASN.1: solo macro il cui significato e' noto a priori possono essere
trattate in modo automatico.
58
ASN.1: macro
• La specifica di ROSE comprende anche la specifica di macro che
definiscono una notazione (RO-notation) con cui utenti ROSE
possono descrivere le loro operazioni:
 esistono pre-processori dedicati capaci di capire la RO-notation
• espandendo le macro ASN.1
• ma trattandone anche gli aspetti semantici.
• realizzando cosi' un sistema di programmazione per il
supporto di RPC (Remote Procedure Call)
• Il linguaggio SMI che e' alla base del Framework di gestione
standard Internet e' anch'esso formalmente definito come un insieme
di macro ASN.1
 anche in questo caso esistono processori dedicati capaci di
trattare la semantica degli statement SMI e non solo di
espanderli come macro ASN.1.
59
RO-notation
operationName OPERATION
ARGUMENT TypeOfArgument
-- if the operation may have an input parameter
RESULT
-- if the operation is confirmed in case of
-- success
TypeOfResult
-- if the confirmed operation may have an output
-- parameter
ERRORS
{ <list-of-errorNames> }
-- if the operation is confirmed in case of error
LINKED
{ <list-of-linked-operationNames> }
-- if the operation allows callbacks
::= <operation-id>
-- localForm INTEGER
-- globalForm OBJECT IDENTIFIER
60
RO-notation
errorName ERROR
PARAMETER TypeOfErrArgument
-- if the error may have a parameter to convey
-- additional information
::= <error-id>
-- localForm INTEGER
-- globalForm OBJECT IDENTIFIER
61
Esempio di RO-notation: CMIP-1
m-Get
OPERATION
ARGUMENT
GetArgument
RESULT
GetResult
-- this result is conditional; for conditions
-- see Recommendation X.710 § 8.3.1.2.8
ERRORS {
accessDenied, classInstanceConflict,
complexityLimitation, getListError,
invalidFilter, invalidScope,
noSuchObjectClass, noSuchObjectInstance,
operationCancelled, processingFailure,
syncNotSupported
}
LINKED {
m-Linked-Reply }
::= localValue 3
62
Esempio di RO-notation: CMIP-1
m-Set OPERATION
ARGUMENT SetArgument
::= localValue 4
m-Set-Confirmed OPERATION
ARGUMENT SetArgument
RESULT
SetResult
-- this result is conditional; for conditions
-- see Recommendation X.710 § 8.3.2.2.9
ERRORS {
accessDenied, classInstanceConflict,
complexityLimitation, invalidFilter,
invalidScope, noSuchObjectClass,
noSuchObjectInstance, processingFailure,
setListError, syncNotSupported
}
LINKED { m-Linked-Reply }
::= localValue 5
63
Esempio di RO-notation: CMIP-1
accessDenied ERROR
::= localValue 2
noSuchObjectInstance ERROR
PARAMETER ObjectInstance
::= localValue 1
processingFailure ERROR
PARAMETER ProcessingFailure -- optional
::= localValue 10
64