Second part needs improvement (encoding, Compilers)

What is ASN.1 Internationally standardised, vendor, platform & language independent notation for specifying data structures at a high level of abstraction It is supported by encoding rules that determine the precise bit patterns to represent values of these data-structures that will be transferred over computer network. It is supported by tools which map ASN.1 notation into data structure definition in a computer language of choice. Q: Why we need vendor, platform & language independent notation A: Telecommunication involves connection of many different IS produced by different vendors, running on different Oss and different microprocessors running SW developed using different languages. We still need to exchange date between all those Information Systems (IS s). Q: What are “data structures at high level of abstraction A:

ASN.1 - Outline ASN.1 Specification ASN.1 Basic Encoding Rules ASN.1 Compilers ASN.1 & SDL

Abstract Syntax Notation 1 (ASN.1) ASN.1 was defined by ISO, as generic means of allowing differing computer systems, with different internal data representations to interchange data. ASN.1 is now extensively used by the ITU & ISO to define protocol headers and formats. In OSI, ASN.1 is used to define presentation layer applications.

ASN.1 Standards X.680 (12/97) ASN.1: Specification of basic notation X.681 (12/97) ASN.1: Information object specification X.682 (12/97) ASN.1: Constraint specification X.683 (12/97) ASN.1: Parameterization of ASN.1 specifications X.690 (12/97) ASN.1 encoding rules - Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) X.691 (12/97) ASN.1 encoding rules - Specification of Packed Encoding Rules (PER)

ASN.1 Introduction Basic Data Types INTEGER, BOOLEAN, UFT8String and other Production Mechanisms for constructing more complex data types SEQUENCE, SEQUENCE OF SET, SET OF CHOICE and other Elements for Structuring the ASN.1 specification Modules, Module Headers Exports/Imports Statements

ASN.1 Character Set An ASN.1 item shall consist of a sequence of the characters: A to Z a to z 0 to 9 : = , { } < . @ ( ) [ ] - ' " | & ^ * ; ! ASN.1 is case sensitive ! Font type (bold, italic, size …) is not significant

Naming Rules Names of fields, elements & items can be arbitrarily long. Quite long names are common Names of Types must start with uppercase Names of Identifiers must start with lowercase Production Mechanism Type Name Person-type ::= SEQUENCE {name VisibleString age INTEGER, employed BOOLEAN} Identifier Built-in, Simple Type

Built-In Types BOOLEAN Type INTEGER Type ENUMERATED Type Has two values: TRUE and FALSE INTEGER Type Integer numbers … -2,-1, 0, 1, 2 … ENUMERATED Type - Enumeration is way to assign name (identifier) to integers Example: LeadTime-type ::= ENUMERATED { tomorrow (0), three-day (1), week (2)} Latest ASN.1 doesn’t require numbers

More Built-In Types REAL Type BIT STRING Type NULL Type values: {mantissa 3.14159, base 10, exponent -5} , 0 , PLUS-INIFINITY, MINUS-INFINITY BIT STRING Type value example: ‘101100110001’B or ‘B31’H (in Hex) NULL Type NULL Type has just one value: NULL It is most often used in CHOICE constructs E.G. Toys ::= CHOICE { cars Cars, dolls Dolls, none NULL}

ANY Type A type of type ANY can be set to any type e.g. MyThing ::= ANY This states that the definition of the type is beyond the scope of ASN.1 Sometimes is referring to items that are to be defined in future.

Object Identifier Type Object identifiers are defining a globally unique naming space Object identifier name space is defined by hierarchically allocated tree-structure Each arc of the tree is labeled by a numeric value. Global authorities are responsible for allocation of top level arcs More local authorities are responsible for the lower-level arcs

Example Object Identifier {iso standard 8571 pci (1)} or {1 0 8571 1} Would each identify an object, “pci”, defined in ISO 8571. With the following additional definition: ftam OBJECT IDENTIFIER ::= {iso standard 8571} Above defined pci object may be then also uniquely identified as {ftam pci(1)}

Built-In Character String Types PrintableString old “telex” character set (not very useful today) VisibleString all printiable ASCII characters plus “space” UTF8String any character (form Egyptian hieroglyphs to ASCII) Other like: NumericString, TeletexString, VideotexString, IA5String, GraphicString, GeneralString, UniversalString, BMPString Value Notation simple: “This is example of value notation” or more complex: {null,{0,0,4,29} cyrillicCapitalLetterIe, “ABC”} Q:Why we would use different String types A: Because different type are encoded in different length Visible sting 1 octet, while UTF8Sting 3-7 octets

Built-In Date/Time Types UTCTime two digits for year (+49, -50 from the current year) value example: yymmddhhmmZ : 0003221830Z (Z is for GMT) GeneralizedTime same as UTCTime but with four digits for year

Production Each production consists of the following parts, on one or several lines, in order: a name for the new collection of production sequences; the characters ::= one or more alternative collections of production sequences (defined later) Example: ClassMember ::= CHOICE { student Student, lecturer Lecturer }

SEQUENCE Production Mechanism A SEQUENCE is a sequence of elements of differing type where the order is important. Example Type notation: SEQUENCE {name IA5String, age INTEGER} Value Notation: {name “John”, age 26} A SEQUENCE OF is a sequence of elements of the same type where order is important. Example Type notation: SEQUENCE OF INTEGER Value Notation: {12,13,14}

SET Production Mechanism A SET is a sequence of elements of differing type where the order is not important. Example Type notation: SET { name IA5String, age INTEGER } Value Notation: {age 26, name “John”,age 23, age 6} A SET OF is a sequence of elements of the same type where the order is not important. Example Type Notation: SET OF INTEGER Example Value Notation: {12,13,14} SETs are more expensive for encoding so SEQUENCES are preferable

Default & Optional Keyword DEFAULT Keyword OPTIONAL Example: Identifies a default value for an element of a SEQUENCE or SET to be assumed if value for that element is not included Keyword OPTIONAL Identifies an element for which a value can be omitted Example: Person::= SEQUENCE { name UTF8String, number-of-parents INTEGER DEFAULT 2, spouse-name UTF8String OPTIONAL }

CHOICE Production Mechanism A CHOICE is an element that can be constructed as one of a finite set of types. Example of type notation: CHOICE {name IA5String, nickname IA5String , TFN INTEGER} value notation : {name:“Brad”} or {nickname:“Braddles” } or {TFN:123456}

Tagged types A tagged type is a new type which is decoded and encoded identically to the type it derives from, but has a different tag Tags are used to differentiate between items of the same base type Example: Flight ::= SEQUENCE { origin IA5String, stop1 [0] IA5String OPTIONAL, stop2 [1] IA5String OPTIONAL, destination IA5String }

Subtyping Simple Subtyping INTEGER (1..56) subset of integers in the range of 1 to 56 inclusive It is used to improve encoding efficiency (subtypes require less bytes for encoding then full length types) Complex Subtyping involves using construct like: SIZE, FROM INTERSECTION, UNION, EXCEPT, ALL Example of Complex Subtyping INTEGER (ALL EXCEPT (1..20)) (“yes” UNION “no” UNION “maybe”) PrintableString (SIZE (10)) limit to exactly 10 characters PrintableString (SIZE (1..10))

Soft Typing The value of ANY types can be constrained using the DEFINED BY syntax. Eg X.500 or CMIP; Attribute ::= SEQUENCE { type OBJECT IDENTIFIER, value ANY DEFINED BY type } This is sometimes called Soft Typing.

Soft typing When receiving a message containing these messages, a presentation entity should in theory look in an "attribute catalogue", using the specific value of the "type" as a key. The attribute catalogue will specify, among other things, contain the ASN.1 specification of the attribute values.

Soft Typing Example TextBook ::= SEQUENCE { author IA5String, CitationType INTEGER, reference ANY DEFINED BY CitationType }, Type TextBook requires a list of CitationTypes defined elsewhere that specifies the ASN.1 type for each permitted value of INTEGER Possible Values are: { author ”Milan Kundera", CitationType 0, reference IA5String "ISBN0571178170" } or { author "Milan Kundera", CitationType 1, reference INTEGER 1995 } or { author "Milan Kundera", CitationType 2, reference PrintableString ”Slowness" }

ASN.1 Macros Macros are a mechanism for the user to define a new notation with which they can then construct and reference ASN.1 types or specify values of types. Shorthand notation.

Example Macro Suppose it is desired to have a notation for type definition of the form PAIR TYPEX = . . . . TYPEY = . . . . with a corresponding value notation allowing (X = ----, Y = ----) Where the . . . . and the ---- refer to any ASN.1 type and corresponding value respectively. * Example from X.208

Production Rules A macro definition consists of a set of "production rules", described in "Bakus-Naur" like form. Several alternatives separated by "|" Each alternative described by a list of "tokens", which can be: place holders for ASN.1 types or values, keywords enclosed within quotes, like "TYPEX", "=" or "=" in our example, place holders for identifiers, or strings

Macro Definitions A macro definition must always contain at least two production rules, called "TYPE NOTATION" and "VALUE NOTATION". The "TYPE NOTATION", preceded by the MACRO name, can be used wherever a "type definition" is expected within the ASN.1 language, the syntax defined in the "VALUE NOTATION" can be used to define a value for a type defined by a macro

Macro Type Notation PAIR MACRO ::= BEGIN TYPE NOTATION ::= “TYPEX” “=” type (Local-type-1) -- Expects any ASN.1 type and assigns it -- to the variable Local-type-1; “TYPEY” type (Local-type-2) -- Expects a second ASN.1 type and assigns --it to the variable Local-type-2;

Macro Value Notation VALUE NOTATION ::= “(” “X” “=” value (Local-value-1 Local-type-1) -- Expects a value for the type in Local-type-1, and assigns it -- to the variable Local-value-1; “,” “Y” “=” value (Local-value-2 Local-type-2) -- Expects a value for the type in Local-type-2 and assigns it -- to the variable Local-value-2; <VALUE SEQUENCE {Local-type-1, Local-type-2} ::= {Local-value-1, Local-value-2}> -- This “embedded definition” returns -- the final value as the value -- of a sequence of the two types. “)” END

Example Macro T1 ::= PAIR TYPEX = INTEGER TYPEY = BOOLEAN T2 ::= PAIR TYPEX = VisibleString TYPEY = T1 Then a value of type T1 might be: (X = 3, Y = TRUE) and a value of type T2 might be: (X = “Name”, Y = (X = 4, Y = FALSE))

Use of Macros in Protocol Definition Its usually more important to know how to use a particular Macro than how to define new Macros. The following protocols use ASN.1 Macros. X.500 Directory Databases ROSE Remote operations TCAP IN protocol X.509 Security Protocol X.400 Messaging Q.932 USSD Supplementary Service Data for GSM ISDN Supplementary Services CMIP Network Management *This is list is by no way complete.

Structuring an ASN.1 Specification ASN.1 definitions are defined in modules. Modules contain a complete set of type definitions that are self contained. Modules can import definitions from other modules, and export definitions to other modules.

EXPORTS/IMPORTS Statements IMPORTS - specifies list of types defined in other modules EXPORTS - specifies list of types defined in this module that are available for use in other modules if EXPORTS statements is omitted all types are available EXPORTS ; (empty list of types) means that nothing is available IMPORTS/EXPORTS Statements are optional and if exist they should be located at the head of the module after BEGIN statement and before any type definition Semicolon is used to terminate EXPORT/IMPORT statements

Example ASN.1 Module ExampleASN.1 DEFINITIONS ::= -- This is a comment -- Start of module BEGIN EXPORTS Student; -- This can be re-used in other definitions Student ::= SEQUENCE { -- A sequence order is important age INTEGER, name IA5String } ClassRoom ::= SET OF Student -- order is not important in a SET END

Basic Encoding Rules An abstract syntax is converted into a transfer syntax using an encoding rule. ASN.1 has a set of basic encoding rules defined in ISO 8825/ X.209. X.209 is very inefficient, so Packed Encoding Rules are defined which are more compact

Basic Encoding Rules Each data item is encoded to contain: an identifier (tag or type) a length indicating the size of the data field a data, which contains the actual contents of the object. an optional end-of-content flag if data length is unknown Aligned on octet boundaries

Encoding Length - Definite Form If length < 128, use a single byte, with the high bit set to zero. if high bit is set to one, the low seven bits set to the length of length field. The length is then encoded in that many bytes. IDENTIFIER LENGTH CONTENTS OCTETS OCTETS OCTETS The number of octets in the contents octets.

Encoding length - Indefinite Form. If length field has a value of 0 - i.e. [1000|0000]. The object is ended by sending two zero bytes. IDENTIFIER LENGTH CONTENTS END OF OCTETS OCTETS OCTETS CONTENTS Indicates that the there are no more contents octets. Indicates that the end of contents, is used instead of length.

Basic Encoding Rules Constructor Types Types contained within types, are sent in the content portion of the message. Value B is a part of structure A. Identifier and length of B is carried in content part of A. IDENTIFIER-A LENGTH-A IDENTIFIER-B LENGTH-B CONTENTS

ASN.1 Example Types PersonnelRecord ::= SET { Name, title [0] VisibleString, children [1] IMPLICIT SEQUENCE OF ChildInformation DEFAULT {} } ChildInformation ::= SET { Name, dateOfBirth [0] Date} Name:: = SEQUENCE { givenName VisibleString, familyName VisibleString}

ASN.1 Example Value { {givenName "John",familyName "Smith"}, A set of records with one value (John Smiths might be as follows); { {givenName "John",familyName "Smith"}, title "Director", children {{{givenName "Ralph",familyName "Smith"}, dateOfBirth "19571111"}, {{givenName "Susan",familyName "Jones"}, dateOfBirth "19590717"}} }

ASN.1 Example Encoding Personnel Record Length Contents 60 8185 Set Length Contents 31 200 Name Length Contents 61 10 Visible- Length Contents String 1A 04 "John" Visible- Length Contents 1A 05 "Smith" Title Length Contents A0 0A Visible- Length Contents 1A 08 "Director' .... (removed for brevity) ...

ASN.1 Example Encoding (cont) [1] Length Contents A1 42 Set Length Contents 31 IF Name Length Contents 61 11 Visible- Length Contents String 1A 05 "Ralph" Visible- Length Contents 1A 01 "T" 1A 05 "Smith" .... (removed for brevity) ...

Packed Encoding Rules Specialised encoding based on the data type. Only generates tags when they are needed to prevent ambiguity. Only generates lengths when the size of an object can vary. lengths represented in compact form.

Packed Encoding Rules Encoding not always aligned on byte boundaries unless 'aligned' variant of the rules is used Optional elements in a sequence are indicated by a list of single bit flags placed at the start of a sequence .

To implement a protocol defined in ASN.1 Hand code or feed the ASN.1 specification in an "ASN.1 compiler", that will automatically generate the conversion routines.

ASN.1 Compilers Compiled Manual Develop an application Days Months Update a protocol Hours Weeks Achieve conformance Correct Test and Input fail Reliability of code Good Dubious Debugging tools Yes ??? Speed of decoding Good Excellent... ...or poor Respect of layering Natural Depends on discipline

Using ASN.1 for Protocol Specification & Implementation. ASN.1 compilers can be used to create C structures or C++ classes from ASN.1 specifications. Public domain ASN.1 compilers available unfortunately, very few implement MACROs or SoftTyping required for most applications that use ASN.1

Comparison Between SDL and ASN.1 Definition of types X X Notation for values X X Definition of operators X Expressions X Encoding of values X

SDL and ASN.1 (ITU-Z.105) Z.105 describes ways in which ASN.1 code can be directly included in SDL specifications. Subset of both SDL and ASN.1 is used. Describes how to use SDL combined with ASN.1 as follows: the System structure and behavior are defined using SDL concepts the parameters of signals are defined by ASN.1 types or SDL sorts data can be defined with ASN.1 type definitions or with SDL sort definitions encoding of ASN.1 data values can be defined by reference to the relevant encoding rules. Encoding is not in the scope of this Recommendation.

Other ways of using SDL and ASN.1 More common way is to describe structure and behavior using pure SDL Separately describe data using ASN.1, using the same names in both ASN.1 and SDL Encoding of ASN.1 data values using ASN.1 BER rules.

Use of ASN.1 From the approximately 1000 ETSI & ITU standards produced over the last 5 years roughly 10% make use of ASN.1 Extensively used in areas like ISDN supplementary services, IN protocols and GSM. Tendency to use ASN.1 in specification of conformance tests even when the protocol specification is not defined in ASN.1

ASN.1 - Summary Provides notation for specification of complex data types base on simple types and production rules Specifies also how data values shall be specified Defines Encoding rules which define how data will be represented between two systems (on the “line”) ASN.1 Tools are available which provide support for ASN.1 data manipulation and encoding/decoding for various OSs and programming languages ASN.1 can be used in conjunction with SDL

Summary: ASN.1Types, Values and BER Abstract: message as it appears in an ETSI standard (X.680) MSG::= SEQUENCE { item1 INTEGER, item2 STRING } Value MSG m1 { item1 123, item2 "XYZ" } Encoding Rules Concrete: message as it is transferred over a real network (X.690) Bitstream 11101001010011010010111… t