1 LABORATORIO DI INFORMATICA Network Management 3. Il linguaggio ASN.1 3.2 Descrizione del...

1

LABORATORIO DI INFORMATICANetwork Management

3. Il linguaggio ASN.1

3.2 Descrizione del linguaggio

Claudio Salati

Copyright © 2001 by Claudio Salati

ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA

FACOLTA' DI INGEGNERIA - SEDE DI CESENA

2

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

3

• 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.

DEFINIZIONE DEL PROBLEMA

4

• "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

5

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).

6

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.

7

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.

8

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.

9

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

10

ASN.1: MODULI

• Module: a collection of ASN.1 descriptions specifying a protocol (detto anche sintassi astratta)

• 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.

<<module>> DEFINITIONS <<implicit>> ::=

BEGIN <<linkage>>

<<declarations>>

END

11

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

12

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.

13

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

14

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.

15

ASN.1: tipi semplici• BOOLEANI

Read-only ::= BOOLEANmodifiable Read-only ::= TRUE -- or FALSE

• INTERI

ContentLength ::= INTEGERlength 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

16

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.

17

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

18


• STRINGHE DI BYTE

An OCTET STRING is a data type taking zero or more octets as its value.

UserName ::= OCTET STRINGinitiator 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

19


• 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

20

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

21


• 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

22


• 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 IDENTIFIER si ottiene un nuovo OBJECT IDENTIFIER

23

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.

24

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!)

• servonoa. 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.

25

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" } }

}

26

ASN.1: SEQUENCE, campi opzionali e default 1Interrupt-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'

27

ASN.1: SEQUENCE, campi opzionali e default 2T1 ::= SEQUENCE { v1 T1 ::= { BOOLEAN, FALSE, BOOLEAN TRUE } }

-- f1 ha valore FALSE ed f2 ha valore TRUE

T2 ::= SEQUENCE { v2 T2 ::= { BOOLEAN DEFAULT TRUE, FALSE BOOLEAN DEFAULT TRUE } }

-- 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 } }

28

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?

29

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

30

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!

31

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!

32

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).

33

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.

34

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 tag universaleBOOLEAN 1INTEGER 2BIT STRING 3OCTET STRING 4NULL 5OBJECT IDENTIFIER 6ObjectDescriptor 7EXTERNAL 8... ...ENUMERATED 10... ...

35

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

36

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)

37

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

38

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 tipoIA5String ::= [UNIVERSAL 22] IMPLICIT OCTET STRINGviene 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!

39

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)

40

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

41

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.

42

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 ANYpuo' essere abbreviata in: SET

• la notazione: SEQUENCE OF ANYpuo' essere abbreviata in: SEQUENCE

43

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

44

ASN.1: il tipo pre-definito EXTERNAL

EXTERNAL ::= [UNIVERSAL 8] IMPLICIT SEQUENCE

direct-reference OBJECT IDENTIFIEROPTIONAL,-- documento che definisce la sintassi del tipo di dato

indirect-reference INTEGEROPTIONAL,-- presentation context associato

data-value-descriptor ObjectDescriptorOPTIONAL,-- altre info sul data type

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}

}

45

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

46

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"))

47

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)

48

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

49

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 RequestID, operation ENUMERATED {get (0), put (1)}, error-occurring Error-Occurring OPTIONAL, binding Binding OPTIONAL}

Binding ::= SEQUENCE { name ObjectName, value ObjectSyntax OPTIONAL }

50

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 ABSENTbinding 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

51

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) }

52


ReturnErrorProblem ::= INTEGER {unrecognizedInvocation (0),errorResponseUnexpected (1),unrecognizedError (2),unexpectedError (3),mistypedParameter (4) }

ReturnResultProblem ::= INTEGER {unrecognizedInvocation (0),resultResponseUnexpected (1),mistypedResult (2) }

53


InvokeProblem ::= INTEGER {duplicateInvocation (0),unrecognizedOperation (1),mistypedArgument (2),resourceLimitation (3),initiatorReleasing (4),unrecognizedLinkedId (5),linkedResponseUnexpected (6),unexpectedChildOperation (7) }

GeneralProblem ::= INTEGER {unrecognizedAPDU (0),mistypedAPDU (1),badlyStructuredAPDU (2) }

54


InvokeIdType ::= INTEGER

Operation ::= CHOICE {localValue INTEGER,globalValue OBJECT IDENTIFIER }

Error ::= CHOICE {localValue INTEGER,globalValue OBJECT IDENTIFIER}

ROIVapdu ::= [1] IMPLICIT SEQUENCE { invokeId InvokeIdType, linkedId [0] IMPLICIT InvokeIdType OPTIONAL, operation-value Operation, argument ANY DEFINED BY operation-value OPTIONAL }

55


RORSapdu ::= [2] IMPLICIT SEQUENCE { invokeId InvokeIdType,

SEQUENCE { operation-value Operation, result ANY DEFINED BY

operation-value} OPTIONAL

}

ROERapdu ::= [3] IMPLICIT SEQUENCE { invokeId InvokeIdType, error-value Error, parameter ANY DEFINED BY error-value OPTIONAL }

56


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 ROIVapdu,rors-apdu RORSapdu,roer-apdu ROERapdu,rorj-apdu RORJapdu }

END -- module

57

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)

58

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.

59

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.

60

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 -- parameterERRORS { <list-of-errorNames> }-- if the operation is confirmed in case of errorLINKED { <list-of-linked-operationNames> }-- if the operation allows callbacks::= <operation-id> -- localForm INTEGER -- globalForm OBJECT IDENTIFIER

61

RO-notation

errorName ERROR

PARAMETER TypeOfErrArgument

-- if the error may have a parameter to convey-- additional information::= <error-id> -- localForm INTEGER -- globalForm OBJECT IDENTIFIER

62

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

63


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

64


accessDenied ERROR

::= localValue 2

noSuchObjectInstance ERROR

PARAMETER ObjectInstance

::= localValue 1

processingFailure ERROR

PARAMETER ProcessingFailure -- optional

::= localValue 10

1 LABORATORIO DI INFORMATICA Network Management 3. Il linguaggio ASN.1 3.2 Descrizione del...

Documents

Transcript of 1 LABORATORIO DI INFORMATICA Network Management 3. Il linguaggio ASN.1 3.2 Descrizione del...