dette er en test

advertisement
Outline for today
• Standard Formal Notations for data structures and
messages
• Motivation
• Abstract Syntax Notation One (ASN.1)
IHA præsentation
1
Standard Formal Notations
for
Data Structures and Messages
IHA præsentation
2
Protocol Definition
A well-defined set of messages (bit-patterns or - increasingly today octet strings) each of which carries a defined meaning (semantics),
together with the rules governing when a particular message can be
sent.
IHA præsentation
3
Motivation
Example – 4 layered protocol stack
System A
Linux, ARM11,
Protocol
implemented in C
Application
Layer 4
Layer 3-4 interface
Layer 3
Layer 2-3 interface
Layer 2
Layer 1-2 interface
Layer 1
Windows CE, Intel,
Protocol
implemented in C#
Layer 4 protocol between peer layers
Layer 3 protocol between peer layers
Layer 2 protocol between peer layers
Layer 1 protocol between peer layers
System B
Application
Layer 4
Layer 3
Layer 2
Layer 1
Physical media
IHA præsentation
4
The problem
Q: Why not just specify the data in a C/C++ structure as
below”?
struct {
char code;
int x;
} test;
test.x = 256;
test.code=‘a’
test.code
test.x
a
00000001
00000011
host 1 format
test.code
test.x
a
00000011
00000001
host 2 format
problem: different data format, storage conventions (endianess)
IHA præsentation
5
Solutions
1. Sender learns receiver’s format. Sender translates into
receiver’s format. Sender sends.
– real-world analogy?
– pros and cons?
2. Sender sends. Receiver learns sender’s format.
Receiver translate into receiver-local format
– real-world-analogy
– pros and cons?
3. Sender translates host-independent format. Sends.
Receiver translates to receiver-local format.
– real-world analogy?
– pros and cons?
IHA præsentation
6
Protocol Specification
Goal/Motivation for specifying messages
• To have a platform-independent Notation
• To have language-independent Notation
• Vendor-independent
• Internationally-standardised
IHA præsentation
7
Protocol Specification
•Protocols can be specified in many ways
•One fundamental distinction is between text-based specifications and binarybased specification.
•Text-based specification:
• The "protocol" is defined as a series of lines of ASCII encoded text
• Binary-based specification:
•The “protocol” is defined as a string of octets or of bits
IHA præsentation
8
Abstract Syntax Notation One
(ASN.1)
IHA præsentation
9
Abstract Syntax Notation One (ASN.1)
•It is an internationally-standardized (ISO standard X.680), vendorindependent, platform-independent and language-independent notation for
specifying data-structures at a high level of abstraction
•It is supported by rules which determine the precise bit-patterns (again
platform independent and language-independent) to represent values of
these data-structures when they have to be transferred over a computer
network, using encodings that are not unnecessarily verbose
•It is supported by tools available for most platforms and several
programming languages that map the ASN.1 notation into data-structure
definitions in a computer programming language of choice, and which
support the automatic conversion between values of those data-structures in
memory and the defined bit-patterns for transfer over a communications line.
IHA præsentation
10
Abstract Syntax Notation One (ASN.1)
•The design of some form of data-structure (at about the level of generality
of a high-level programming language, and using a defined notation) which
is capable of carrying the required semantics. The set of values of this datastructure are called the abstract syntax of the messages or application. We
call the notation we use to define this data structure or set of values we the
abstract syntax notation for our messages. ASN.1 is just one of many
possible abstract syntax notations, but is probably the one most commonly
used.
IHA præsentation
11
Abstract Syntax Notation One (ASN.1)
•The crafting of a set of rules for encoding messages such that, given any
message defined using the abstract syntax notation, the actual bits on the
line to carry the semantics of that message are determined by an algorithm
specified once and once only (independent of the application). We call such
rules encoding rules, and we say that the result of applying them to the set
of (abstract syntax) messages for a given application defines a transfer
syntax for that application. A transfer syntax is the set of bit-patterns to be
used to represent the abstract values in the abstract syntax, with each bitpattern representing just one abstract value. (In ASN.1, the bit-patterns in a
transfer syntax are always a multiple of 8 bits, for easy carriage in a wide
range of carrier protocols)
IHA præsentation
12
Abstract Syntax Notation One (ASN.1)
Abstract syntax in ASN.1
Record :: = SEQUENCE
{
name
PrintableString (SIZE(1..38)),
age
INTEGER,
gender
ENUMERATED { unknown(0),
male(1),
female(2) }
}
Machine A
Concrete syntax in C
typedef struct Record
{
char name[31];
int
age;
enum { unknown = 0;
male = 1;
female = 2 } gender;
} Record;
Machine B
Concrete syntax in Objective Caml
transfer syntax
(bytes or bits)
IHA præsentation
Type record
{
name
: string;
age
: num;
gender : t_gender }
and t_gender = Unknown
| Male
| Female
13
Abstract Syntax Notation One (ASN.1)
ASN.1 Specification
Machine A
Machine B
(C#)
(C++)
Step 1. We need a ASN.1 compiler ASN.1 -> C# + ASN.1 -> C++
Step 2. Agree on encoding rules (BER or PER?)
ASN.1 TOOLS ARE AVAILABLE
IHA præsentation
14
Abstract Syntax Notation One (ASN.1)
ASN.1 Specification
A top-level type
definition, supported
by other type and
value definitions
The Abstract Syntax
Apply a specific
ASN.1 Encoding
Rule
Abstract values
ASN.1 Encoding Rules
All possible values
of this top-level type
ASN.1 Encoding Rules
Values
Bit pattern
Bit pattern
Transfer
Syntaxes
IHA præsentation
15
Abstract Syntax Notation One (ASN.1)
• ASN.1 is for:
• Representing data types and structures (abstract syntax)
• Encoding rules (transfer syntax)
• ASN.1 is not
• another programming language
– No control flow (if-else, while etc.)
– No pointers
– Bitwise operators
Let us look at ASN.1 in more details!
IHA præsentation
16
ASN.1 - Modules
•
-- ASN1START
Fundamental unit of ASN.1
•
Module
EUTRA-RRC-Def DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
….
….
….
….
•
Sole purpose to name a
collection of type definitions
and/or value definitions
(assignments)
•
The module constitutes a data
specification
Type & value definitions
(assignments)
END
--ASN!STOP
IHA præsentation
17
ASN.1 - Basics
• How do we define types and assign values to them ?
•The main concept of ASN.1 is that of type
•Two main ASN.1 build-in types:
• Basic types
• Constructed types
IHA præsentation
18
ASN.1 – Basic Types
Simple Types
Tag
Typical use
BOOLEAN
1
Logical values TRUE and FALSE
NULL
5
Includes the single value NULL, used for delivery report or some
alternatives of the CHOICE type
INTEGER
2
Whole numbers (positive or negative), possibly named
REAL
9
Real numbers represented as floats
ENUMERATED
10
Enumeration of identifiers
BIT STRING
3
Bit strings
OCTET STRING
4
Byte strings
OBJECT
IDENTIFIERS
6
Unambigous identification of an entity registered in a worldwide tree
CHARACTER
STRING
*
Allows negotiation of a specific alphabet for character strings
IHA præsentation
19
ASN.1 – Constructed Types
Structured Types
CHOICE
Tag
*
Typical use
Choice between types
SEQUENCE
16
Ordered structure of values (generally) different types
SET
17
Non-ordered structure of values of (generally) different types
SEQUENCE OF
16
Ordered structure of values of the same type
SET OF
17
Non-ordered structure of values of the same type
IHA præsentation
20
ASN.1 – Type & Value Assignment
All ASN.1 assignments use the symbol ”::=”; so do the type assignment:
Married ::= BOOLEAN
Cancel ::= BOOLEAN DEFAULT FALSE
myMarried Married ::= TRUE
myAge Age
Age
::= 25
::= INTEGER
myColor ColorType ::= red
ColorType ::= INTEGER
{
red
(0)
white (1)
blue (2)
}
myColor ColorType ::= 35
myPicture Picture ::= ’0101011011110’B
myWork Occupation ::= { clerk, editor }
Picture ::= BIT STRING
Occupation ::= BIT STRING
{
clerk
(1)
editor
(2)
}
Positions in string
IHA præsentation
21
ASN.1 – Type & Value Assignment
Form
::= SEQUENCE
{
name
age
married
}
PrintableString,
Age,
Married
Coordinates ::= SET
{
x [1] INTEGER,
y [2] INTEGER,
z [3] INTEGER OPTIONAL
}
f FORM ::= {
name
age
married
”Peter”,
25,
TRUE }
c Coordinates ::= {
z
10,
x
5,
y
30 }
c Coordinates ::= {
x
5,
y
30 }
Maybe present
IHA præsentation
22
ASN.1 – Type & Value Assignment
RAT-Type ::= ENUMERATED {
eutra, utra, geran-cs,
geran-ps, cdma2000-1XRTT,
spare3, spare2, spare1, ...}
rat RAT-Type ::= geran-cs
car CarType ::= audi
myAfter Afters ::= dessert ”ice”
CarType ::= ENUMERATED {
audi (0), bmw (1)
scoda (2), citroen(3), ...}
Afters ::= CHOICE{
cheese IA5String,
dessert IA5String
}
How can the received decode this?
Cheese or dessert string received?
SOLUTION:
TAGGING
IHA præsentation
23
ASN.1 – Type Assignment
MeasIdToAddModList ::= SEQUENCE OF MeasIdToAddMod
MeasIdToAddMod ::= SEQUENCE {
measId
MeasId,
measObjectId
MeasObjectId,
reportConfigId
ReportConfigId
}
IHA præsentation
24
ASN.1 – Subtyping
Allows us to customise our types to just the precise values we need –
it can reduce the number of bits-on-the-line and gives clear guidance to
implementors for memory allocation decisions
Usage:
• reduce the range of an integer
• specify a minimum and/or maximum length of a string
• specify a min and/or max number of iterations in a SEQUENCE OF or SET OF
HOW?
IHA præsentation
25
ASN.1 – Subtyping
Reducing the range of an integer:
RRC-TransactionIdentifier ::=
INTEGER (0..3)
restricting the range of the integer field to the values 0 to 3
Length of a string:
My-string ::= PrintableString (SIZE (1..10)) FROM (”A”..”Z”))
restict the size of the string between 1 and 10 characters
string can only contain the characters ”A” to ”Z”
IHA præsentation
26
ASN.1 – Subtyping
Number of iterations in a SEQUENCE OF or SET OF:
UE-CapabilityRAT-ContainerList ::=SEQUENCE (SIZE (0..2)) OF UE-CapRAT-Container
UE-CapRAT-Container ::= SEQUENCE {
rat-Type
RAT-Type,
ueCapabilityRAT-Container OCTET STRING
}
Minimum number of iterations is 0 – maximum is 2
IHA præsentation
27
ASN.1 – Extensions Versioning
ASN.1 Specification Ver.1
Type ::= SEQUENCE
{
comp1 INTEGER,
comp2 BOOLEAN,
}
ASN.1 Specification Ver.2
???
IHA præsentation
Type ::= SEQUENCE
{
comp1 INTEGER,
comp2 BOOLEAN,
comp3 REAL
}
28
ASN.1 – Extensions & Versioning
ASN.1 Specification Ver.1
ASN.1 Specification Ver.2
Type ::= SEQUENCE
{
comp1 INTEGER,
comp2 BOOLEAN
…
}
Type ::= SEQUENCE
{
comp1 INTEGER,
comp2 BOOLEAN,
[[ comp3 REAL]],
…
}
extension marker
(ellipsis)
IHA præsentation
version brackets
29
Abstract Syntax Notation One (ASN.1)
ASN.1 Encoding Rules
1.
Basic Encoding Rule (BER)
2.
Packet Encoding Rules (PER)
3.
XML Encoding Rules (XER)
IHA præsentation
30
ASN.1 – Basic Encoding Rules
The BER transfer syntax always has the format of a triplet TLV
T
L
V
Tag
octets
Length
octets
Content
octets
Triplet TLV
T
L
T
L
T
L
V
T
L
V
Recursive principle
IHA præsentation
31
ASN.1 – Basic Encoding Rules
Two formats of the Tag Octets (Primitive or Constructed)
class
P/C
ttttt
bit 7
bit 6
class
bit 5
form
0
0
UNIVERSAL
0
Primitive
0
1
APPLICATION
2
Constructed
1
0
context-specific
1
1
PRIVATE
IHA præsentation
32
Abstract Syntax Notation One (ASN.1)
Example: age INTEGER ::= 5
class
0
0
UNIVERSAL
+
P/C
1
ttttt
+
Primitive
0
0
1
0
1
INTEGER
IHA præsentation
33
ASN.1 – Basic Encoding Rules
The length octet represents the length of the value (V)
T
L
V
Tag
octets
Length
octets
Content
octets
Triplet TLV
The three formats of the length octets
•
•
•
Short definite length
Long definite length
Indefinite length
IHA præsentation
34
ASN.1 Basic Encoding Rules
Short definite length
8
0
7
6
5
4
3
2
1
Length
• can be used if V part is less than 127 octets
• V part can be primitive or constructed type
• short form is identified by encoding bit 8 as zero
IHA præsentation
35
ASN.1 Basic Encoding Rules
Bit 8 set to one
Long definite length
8
1
7
6
5
4
3
2
Length of length (N)
1
Following N octets is
Length fields
First octet (1) of length
Last octet (N) of length
IHA præsentation
36
ASN.1 – Basic Encoding Rules
Short form
8
7
6
5
4
3
2
1
0
0
0
0
0
1
0
1
8
7
6
5
4
3
2
1
8
7
6
5
4
3
2
1
8
7
6
5
4
3
2
1
1
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
etc.
Long form
Length of length N = 2
Options for encoding a length of 5 (1 0 1)
IHA præsentation
37
ASN.1 – Basic Encoding Rules
Encoding of the V part of the main types
Encoding a BOOLEAN value
Encoding an INTEGER value
The values of
The values of
b1 BOOLEAN ::= TRUE
b2 BOOLEAN ::= FALSE
i1 INTEGER ::= 72
i2 INTEGER ::= 127
i3 INTEGER ::= 128
are encoded as
T
L
i1:
02
01
i2:
02
01
i3:
02
02
are encoded as
T
L
b1:
01
01
b2:
01
01
V
FF
00
IHA præsentation
V
4B
80
0080
38
ASN.1 – Basic Encoding Rules
seq SEQUENCE { age
single
INTEGER,
BOOLEAN } ::= {age
single
24,
TRUE }
is encodes as:
T
0 0 1
L
1610
V
610
T
0 0 0
210
T
0 0 0
110
IHA præsentation
L
V = 24
110
2410
L
V = TRUE
110
510
39
ASN.1 Tagging
• Why do we need tagging?
• All ASN.1 types are assigned a default ”tag” (for the ”T” part of
encoding)
• Sometimes use of the default tag would produce ambiguous
encoding, for example:
IA5String in both cases
Identification ::= CHOICE {
security_no INTEGER,
work_no
INTEGER
}
Afters ::= CHOICE {
cheese IA5String,
dessert IA5String
}
IHA præsentation
40
ASN.1 Tagging
• A tag is a number between square brackets before a type
Coordinates ::= SET {
Afters ::= CHOICE {
x
y
z
[1] INTEGER,
[2] INTEGER,
[3] INTEGER OPTIONAL
cheese [0]
dessert [1]
}
IA5String,
IA5String }
IHA præsentation
41
ASN.1 Tagging
• When we tag, we can
• Override the current tag (called IMPLICIT tagging)
• Add a new tag on the front (called EXPLICIT tagging)
giving a ”TL TLV” encoding
• Sometimes explicit tagging is needed to avoid
ambiguity, but implicit tagging is more common
IHA præsentation
42
ASN.1 Tagging
• We can add as many new tags as we like t a type!
• We say that each value of that type (any type) has
associated with it a tag-list
• Usually the tag-list contains only one or two tags, but
… there is no limit
• In almost all cases, every value in a type has the
same tag list
IHA præsentation
43
ASN.1 Tagging
Research-division ::= [1] CHOICE {
product-based [0] NULL,
basic
[1] NULL }
”product-based” value
”Research-division” type
[1][0][null] O
”basic” value
[1][1][null] O
IHA præsentation
44
ASN.1 Tagging
• Tag classes
• UNIVERSAL (not for users)
• APPLICATION e.g. [APPLICATION 6]
• PRIVATE e.g. [PRIVATE 3]
• Context specific e.g. [2]
IHA præsentation
45
ASN.1 Tagging
• Tag rules
• Numbers are non-negative
• Context specific most common
• APPLICATION normally used for global types or for toplevel messages
• PRIVATE rarely used
• UNIVERSAL assigned only by ASN.1
IHA præsentation
46
ASN.1 Tagging
Syntax:
tag type definition
tag IMPLICIT type definition
tag EXPLICIT type definition
Examples:
SpecialEncoding ::= [PRIVATE 8] EXPLICIT BIT STRING
BinaryFile ::= [APPLICATION 3] IMPLICIT OCTET STRING
IHA præsentation
47
ASN.1 – Packet Encoding Rules (PER)
•
”Obtain the most compact encoding using encoding rules as simple as possible”
•
40% - 60% gain compared to BER
•
Appropriate for protocols that need to transfer data at a high rate
• VoIP
• Videophone
• Multimedia
HOW?
IHA præsentation
48
ASN.1 – Packet Encoding Rules
Motivation
Encoding a BOOLEAN value in BER
The values of
3 octets to send a BOOLEAN
b1 BOOLEAN ::= TRUE
b2 BOOLEAN ::= FALSE
are encoded as
T
L
b1:
01
01
b2:
01
01
ONLY 1 bit needed
V
FF
00
IHA præsentation
49
ASN.1 – Packet Encoding Rules
• PER-visible constraints
• Used by PER to produce less verbose encodings
Example: INTEGER (0..7) encodes into just three bits because the (0..7)
constraint is PER-visible
• No ”T”, no ”L” => efficient coding
• Same ASN.1 type definition used, same specification
IHA præsentation
50
ASN.1 – Developing Applications
• Stage 1 – Specification development
• Stage 2 – Syntax check and compile
• Stage 3 – Writing your Application
• Stage 4 – Putting your Application to use
IHA præsentation
51
ASN.1 – Developing Applications
• Stage 1 – Specification development
• Decide on types of messages the application will need
• Draft a new ASN.1 specification or use an existing one
• When drafting a new, decide on encoding rules
• To take advantage subtyping constraindts
• Have extensibility in mind for future requirements
IHA præsentation
52
ASN.1 – Developing Applications
• Stage 2 – Syntax check & compile
• Use an available ASN.1 Compile
• Compile to your preferred target language
C,C++, C#, Java, Cobol, Pascal…
• ASN.1 compiler produces data structures and related
code for inclusion into the Application
IHA præsentation
53
ASN.1 – Developing Applications
• Stage 3 – Write your Application
• Use the compiled structures in your code
• Use the vendor (tool) provided runtime library
functions/methods like eg. oosEncode() and
ossDecode()
IHA præsentation
54
ASN.1 – Developing Applications
• Stage 4 – Putting your Application to use
• Test it and use it
FINISHED – Questions?
IHA præsentation
55
Download