LABORATORIO DI INFORMATICA 3.2 Descrizione del linguaggio

Presentazione sul tema: "LABORATORIO DI INFORMATICA 3.2 Descrizione del linguaggio"— Transcript della presentazione:

1 LABORATORIO DI INFORMATICA 3.2 Descrizione del linguaggio
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

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

3 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: 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.

4 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"]

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 multLen OpCodeLen ::= long-opcode -- or 4
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

16 ASN.1: tipi semplici ENUMERATI REALI 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 FacsimilePage ::= BIT STRING
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 ASN.1: tipi semplici STRINGHE DI BYTE UserName ::= OCTET STRING
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

19 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

20 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: " " nell'Europa centrale " z" del tempo astronomico di Greenwich " " 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 ASN.1: tipi semplici NULL TimeOfDay ::= CHOICE { UTCTime, 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 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 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!) 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.

25 ASN.1: SEQUENCE, esempio di valore
{ { givenName "John", initial "P", familyName "Smith" }, title "Director", age 51, dateOfHire " ", nameOfSpouse { givenName "Margaret", initial "T", children { { { givenName "Ralph", initial "T", dateOfBirth " " }, { { givenName "Susan", initial "B", dateOfBirth " " } } }

26 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" } 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 2
T1 ::= 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? 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).

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

39 ASN.1: TAG impliciti Int ::= [APPLICATION 1] IMPLICIT INTEGER
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 " Z" 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 ANY puo' essere abbreviata in: SET la notazione: SEQUENCE OF ANY puo' 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 IDENTIFIER OPTIONAL, -- documento che definisce la sintassi del tipo di dato indirect-reference INTEGER OPTIONAL, -- presentation context associato data-value-descriptor ObjectDescriptor OPTIONAL, -- 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 ( )) 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 ABSENT binding PRESENT (WITH COMPONENTS { value ABSENT }) }) GetResponse ::= PDU (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 ::= aseID(3) }

52 Esempio ASN.1: sintassi astratta di ROSE 2
ReturnErrorProblem ::= INTEGER { unrecognizedInvocation (0), errorResponseUnexpected (1), unrecognizedError (2), unexpectedError (3), mistypedParameter (4) } ReturnResultProblem ::= INTEGER { resultResponseUnexpected (1), mistypedResult (2) }

53 Esempio ASN.1: sintassi astratta di ROSE 3
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 Esempio ASN.1: sintassi astratta di ROSE 4
InvokeIdType ::= INTEGER Operation ::= CHOICE { localValue INTEGER, globalValue OBJECT IDENTIFIER } Error ::= CHOICE { 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 Esempio ASN.1: sintassi astratta di ROSE 5
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 Esempio ASN.1: sintassi astratta di ROSE 6
RORJapdu ::= [4] IMPLICIT SEQUENCE { invokeId CHOICE { invokeId InvokeIdType, null NULL }, 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 -- 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

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 § ERRORS { accessDenied, classInstanceConflict, complexityLimitation, getListError, invalidFilter, invalidScope, noSuchObjectClass, noSuchObjectInstance, operationCancelled, processingFailure, syncNotSupported } LINKED { m-Linked-Reply } ::= localValue 3

63 Esempio di RO-notation: CMIP-1
m-Set OPERATION ARGUMENT SetArgument ::= localValue 4 m-Set-Confirmed OPERATION RESULT SetResult -- this result is conditional; for conditions -- see Recommendation X.710 § ERRORS { accessDenied, classInstanceConflict, complexityLimitation, invalidFilter, invalidScope, noSuchObjectClass, noSuchObjectInstance, processingFailure, setListError, syncNotSupported } LINKED { m-Linked-Reply } ::= localValue 5

64 Esempio di RO-notation: CMIP-1
accessDenied ERROR ::= localValue 2 noSuchObjectInstance ERROR PARAMETER ObjectInstance ::= localValue 1 processingFailure ERROR PARAMETER ProcessingFailure -- optional ::= localValue 10