[17] Nu P 11 1

Protokolle der OSI-Schicht 6 Presentation Layer
Kapitel 11.1

Netze und Protokolle
Dr.-Ing. Jan Steuer

Institut für Kommunikationstechnik
www.ikt.uni-hannover.de

Abstract Syntax Notation One (ASN.1)
Basic Encoding Rules (BER)

Literatur:
Steedman, Douglas, „ASN.1 The Tutorial and Reference“, Technology Appraisals,
Twickenham, 1993
Larmouth, John,“ASN.1 Complete“, Morgan Kaufmann Publishers, 1999, ISBN 0-12233-
435-3, 1999
Mitra, Nilotpal,“An Introduction to the ASN.1 Macro Replacement Notation“, AT& T
Technical Jounal, May June 1994, pp66 ff
Mitra, Nilotpal,“Efficient Encoding Rules for ASN.1 based Protocolls“, AT& T Technical
Jounal, May June 1994, pp80 ff
ITU Recommendation X.208, Geneva 1993

© UNI Hannover, Institut für Allgemeine
Nachrichtentechnik

Government Health Warning

This discussion
can damage your brain

(2)

• PAIR
MACRO ::= BEGIN
TYPE NOTATION ::=
”TYPEX”
”=”
type (Local-type-1)
ty-- Expects any ASN.1 type and assigns it
ty-- to the variable Local-type-1;
”TYPEY”
”=”
type (Local-type-2)
ty-- Expects a second ASN.1 type and assigns
ty-- it to the variable Local-type-2;
• VALUE NOTATION ::=
”(”
”X”
”=”
value (Local-value-1 Local-type-1)
va-- Expects a value for the type in
va-- Local-type-1, and assigns it
va-- to the variable Local-value-1;
”,”
”Y”
”=”
value (Local-value-2 Local-type-2)
va-- Expects a value for the type in
va-- Local-type-2 and assigns it
va-- to the variable Local-value-2;
<VALUE SEQUENCE {Local-type-1, Local-type-2}
<::= {Local-value-1, Local-value-2}>
-- This ”embedded definition” returns
© UNI Hannover, Institut für Allgemeine final value as the value
-- the
-- of a sequence of the two types.
Nachrichtentechnik
”)”
END

Programmiersprachen für
Telekommunikationssysteme

Funktionale Beschreibung der
Basic Call
Vorgänge in einem TK-System/
State Model Functional feature description for
telecommunication systems

Dynamische Be-
SDL ASN.1/BER (s.XML) Beschreibung
schreibung der Vor-
des Datenaus-
Specification and Description Abstract Syntax Notation
gänge in einem
Language Tausches/
Basic Encoding Rules
TK-System /
Specification
Description of system
Data
dynamics
exchange
Coding, e.g. C++, JAVA, ADA, CHILL

(3)

Funktionale Beschreibung:
Beschreibung der Leistungsmerkmale, z.B.Rufumleitung
Rufumleitung unconditional: ein ankommender Ruf am umgeleiteten Anschluß wird an
einen definierten Anschluß weitergeleitet. Die Verbindung wird nicht neu geroutet, sondern
weitergeschaltet. Die Kosten für das zweite Verbindungsstück werden dem Umleitenden in
Rechnung gestellt.
Dynamische Beschreibung:
Definition aller Variablen und Operationen auf den Variablen unter Berücksichtigung zeitlicher
Abläufe
Beschreibung des Datenaustausches:
hier ist der Datenaustausch mit externen Systemen gemeint

The things that make ASN.1 important, and unique, are:
· It is an internationally-standardised, vendor-independent, 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. (The tools are described in Chapter 6 of Section I).

Nachrichtentechnik

ASN.1- Zweck

Exakte Definition von Datenströmen über
Kommunikationsverbindungen mittels einer Hochsprache,
die einfach erlernbar sein soll
Erzeugung von Runtime-Modulen zur syntaktische
Prüfung von Datenströmen

Vorwärts-Message
System 1 System 2
Rückwärts-Message

ASN.1
(4)

Aus Hochsprachen wie Pascal, ADA oder ähnlichen, ist bereits bekannt, daß vor der
Erzeugung der Programmbefehle die Typ-Deklarationen erfolgen. Typen können sein:
Integer, Real, Array, String, Set of...
Mithilfe dieser Typ-Deklarationen wird an den Schnittstellen geprüft, ob die übergebenen
Daten den Vereinbarungen entsprechen.
Einerseits kann bereits zur Kompilationszeit geprüft werden, ob die übergebenen
Variablen den Typen entsprechen, andererseits kann auch zur Exekutionszeit geprüft
werden, ob die Daten, die übergeben werden vom richtigen Typ sind.
Wenn ein Datentyp zur Kompilationszeit richtig ist, sollte er eigentlich auch zur
Laufzeit richtig sein, oder?.
Im Prinzip ja, aber wenn bei einer Datenübertragung ein unerkannter Fehler
auftritt, dann kann zur Laufzeit die Unverträglichkeit zwischen Deklaration und
Realität auftreten.

Nachrichtentechnik

Beispiele von Messages

732915765498120738710333864322116
00126549876501
+491774213675
040774231

Wie interpretieren Sie diese Messages? Lösung

(5)

Nachrichtentechnik

Wetterbericht im festen Format

Oktett Bezeichnung Codierung
1-3 station number 5BCD-Oktetts, letztes Halboktett unbenutzt
4 year 2BDC-Digits
5 month 2BDC-Digits
6 day 2BDC-Digits
7 hour 2BDC-Digits
8 minute 2BDC-Digits
9 second 2BDC-Digits
10-11 pressure 4BCD-Digits
12 temperature sign 2BDC-Digits all 0 for plus, all 1 for minus
13 temperature, magnitude 2BDC-Digits
14-15 humidity 3BCD-Oktetts, letztes Halboktett unbenutzt
16-17 wind velocity 3BCD-Oktetts, letztes Halboktett unbenutzt
18 wind direction 2BDC-Digits

(6)

Die feste Formatierung liefert ein weiteres Prüfkriterium, bietet aber wenig Flexibilität bei
der formalen Prüfung der Datenvereinbarungen oder Datenwerte:
Nicht berücksichtigt werden können Werteeinschränkungen für Monate, Tage
u.s.w.
BCD steht für binary coded digit, ein Halbbyte wird den Ziffern 0 bis 9 zugewiesen. Dabei
bleiben 6 Werte ungenutzt.

Nachrichtentechnik

Deklaration für den Wetterbericht

Report = {StationNumber; DateAndTime; Pressure; Temperature;
Humidity; WindVelocity; WindDirection}

StationNumber = PositiveNumber
DateAndTime = Year Month Day Hour Minute Second
Pressure = PositiveNumber
Temperature = Number
Humidity = PositiveNumber
WindVelocity = PositiveNumber
WindDirection = PositiveNumber

Year = TwoDigits
Month = MonthDigits
Day = DayDigits
Hour = HourDigits
Minute = MinuteSecond
Second = MinuteSecond

(7)

TwoDigits = Digit Digit
MonthDigits = 01 .. 12
DayDigits = 01 .. 31
HourDigit = 00 .. 23
MinuteSecond = 00 .. 60
PositivNumber = NonZeroDigit DigitSequence | Digit
DigitSequence = Digit DigitSequence | Digit (rekursiv)
Number = PositivNumber | -PositivNumber
Digit = 0 | NonZeroDigit
NonZeroDigit =1|2|3|4|5|6|7|8|9

Diese Definition ist in Bacchus-Naur Form (BNF)
Elemente müssen durch Trennzeichen, hier „;“ getrennt werden, da keine festen Längen
vorgesehen sind
Die fett gedruckten Werte sind die, die tatsächlich auf dem Kanal übertragen werden.
Alle dünn gedruckten Werte dienen lediglich der Definition. Kusiv sind spezielle
Erklärungen.
ASN.1 ist in BNF spezifiziert
Wo steckt hier noch eine Ungenauigkeit? (richtig: Die Tageszahl 30/31 ist vom Monat
abhängig) Wie würden Sie diese Schwachstelle beseitigen?

Nachrichtentechnik

Datendeklaration für Datentransportsysteme,
historische Entwicklung
Physikalische „Link-Protokolle“ wie beim analogen
Telefon
Feste Zuordnung von Daten in einem festen Rahmen mit
fester Länge (PCM30-Rahmen, IP-Protokoll,..)
Die Entdeckung variabler Datenlängen und freier
Zuordnungen [TLV-Verfahren (Type, Length, Variable)]
Die Erfordernis zur Wiederholung gleicher Daten
(EDIFACT, Electronic Data Interchange for Administration,
Commerce and Transport)
Die Beschränkung auf zeichenorientierte Syntax (HTTP
definiert mittels Bacchus-Naur-Format, BNF)
Die formale Trennung von Spezifikation, Syntaxdefinition
und der Codiervorschriften (ASN.1)

(8)

Vereinbarungen über Bedeutungen von Daten wurden in der Zeit der Assemblerprogrammierung implizit in
den Programmen durchgeführt. Die Datendeklaration in Programmen ist seit der Einführung von höheren
Programmiersprachen eine Selbstverständlichkeit. Die Trennung der Datendeklaration von der Programmlogik
wurde mit der Programmiersprache PASCAL Allgemeingut.
In der Kommunikationstechnik wurde ein vergleichbarer Weg beschritten. Zu übermittelnde Daten wurden
zunächst implizit in der physikalischen Realisierung der Übermittlungseinrichtungen vereinbart. Als Beispiel
dient auf den nächsten Folien die Übermittlung der Nachricht vom Telefonteilnehmer, dass er telefonieren will,
mit wem er telefonieren will und dass er das Gespräch wieder beenden will. Andere Beispiele könnten sein:
Leitweglenkung und Verzonung im analogen Fernsprechsystem, X.21 Teilnehmeranschlussleitung mit dem
IA5-Alphabet an die öffentlichen Datenvermittlungssysteme der ersten Generationen.
Mit der Digitalisierung der Nachrichtennetze verschwand die starre Kopplung der übermittelten Nachrichten
von der physikalischen Realisierung, stattdessen wurden Datendeklariationen mit festen Rahmen entwickelt,
die nach einer Rahmensynchronisation die übermittelten Daten auf der Empfangsseite wieder die
eineindeutige Zuordnung erlaubte. Vertreter dieser Datendeklarationen finden wir in den IP-, den PDH-, den
SDH-Protokollen und vielen anderen.
Die feste Zuordnung ist inflexibel bezüglich der Länge der Informationen und der Möglichkeit nur optional zu
übermitteln. Zur Abhilfe schufen die TLV-Verfahren, die neben der eigentlichen Nutzinformation als Variable
oder Parameter noch den Typ der Information und die Länge übermittelten. Typ ist hier nicht als Klasse zu
verstehen, sondern als eineindeutiges Kennzeichen für eine Nachricht. Eine Setup-Nachricht im
Verbindungsaufbau auf der ISDN-Teilnehmeranschlussleitung ist beispielsweise ein Nachrichtentyp in diesem
Sinne. Die Angabe über die angeforderten B-Kanäle (einer exklusiv, einer wahlfrei oder beide) wird als
Parameter oder Variable übertragen.
Kompliziertere Anwendungen, wie die Dokumentenübertragung im EDIFACT-Standard erfordern darüber
hinaus die Festlegung von Datenwiederholungen auf der Ebene des Datentransportes.
Mit wachsender Bedeutung des Internets wurde hohe Flexibilität bei gleichzeitig minimaler
Standardisierungsanforderung bezüglich der Semantik der Nachrichten unumgänglich. Im HTTP-Protokoll
wurde deshalb wieder der Rückschritt auf die Zeichenweise Übermittlung der Nachrichten mit Zeichen aus
dem ASCII-Code gemacht. Ich sage Rückschritt, weil wir die Art der Datendeklaration bereits in den alten
Tagen der Textverarbeitung fanden, in der Steuerbefehle für das Layout des Druckers mit Sonderzeichen
beginnend und folgendem plain Text in den eigentlichen Text eingestreut wurden (Es soll heute noch Vertreter
dieser Spezies geben!). Die eineindeutige Definition dieser Zeichenketten zur Steuerung wird heute im
Bacchus-Naur-Format durchgeführt.

Nachrichtentechnik

Datendeklaration,
hier: analoge Telefonleitung
„Link-Protokoll“ am Beispiel der analogen Telefonleitung
physikalische Realisierung [Strom zwischen 0 und 30 mA] mit
logische Bedeutung [0..5 mA > 100ms: keine Schleife ;
5..30 mA > 100ms: Schleife] und
aktuelles Auftreten der Daten [am 2.9.99 um 14:22 fließt ein Strom von 22,3
mA]

-60V Vermittlungsstelle

a
A 500

0..30mA Schleifenstrom

A 500 T
100

0V

(9)

Das Link-Protokoll der analogen Telefonleitung stellt eine „unglückliche“ Vermengung von
physikalischer Realisierung mit
logischer Bedeutung und
aktuellem Auftreten der Daten
dar. Diese Verquickung unterschiedlicher Teilbereiche der Datendeklarationen macht das alte
analoge Telefonsystem außerordentlich inflexibel. Änderungen haben eine sehr tiefgreifende
Auswirkung, sie können oft nur durch komplettes Re-Design eingeführt werden. Die Auf- und
Abwärtskompatibilität neuer Entwicklungen ist oft nur mit großem Aufwand oder garnicht möglich.
Die Datendeklaration in diesem Beispiel soll sich auf die Signalisierung zum Zwecke des
Verbindungsaufbaues, der Verbindungsüberwachung und dem Verbindungsabbau beziehen. Eine
Verbindung wird angefordert, indem der Teilnehmer den Handapparat des Telefons abhebt und
damit einen Schleifenkontakt schließt. Als Folge davon fließt nominal ein Schleifenstrom von
30mA . In Abhängigkeit von der Länge der Teilnehmeranschlußleitung ändert sich dieser Strom im
Wert. Der Schleifenstrom läßt das A-Relais ansprechen, das mit seinen Kontakten eine Wahlstufe
und einen Wahlaufnahmesatz anfordert. Die Wahl wird durch zyklische Unterbrechung des
Schleifenstromes durch den Nummernschalter im Rhythmus 40/60ms. Diese
Stromunterbrechungen der Wahlimpulse dürfen von dem A-Relais als Schleifenunterbrechung für
die Verbindungskontrolle verstanden werden, nicht jedoch vom T-Relais. Erst wenn die
Unterbrechung deutlich größer als 40ms ist, darf die Verbindung vom T-Relais wieder ausgelöst
werden.
Die physikalische Realisierung wird über den Strom und seine Unterbrechungsdauer erreicht, der
(erschwerend) nicht einen festen Wert annimmt, sondern mit der
Teilnehmeranschlußleitungslänge variiert.Weitere Mehrdeutigkeiten liegen in den nicht ideal
rechteckigen Schaltflanken an den Impulskanten, stattdessen prellen die beteiligten Kontakte
mechanisch und Blindwiderstände sorgen für Verzögerungen im zeitlichen Ablauf.
Die logische Interpretation des Stromflusses wird direkt aus der physikalischen Realisierung
abgeleitet.T-Relais angezogen heißt: der Teilnehmer hat seinen Handapparat aufgehoben. A-
Relais pulsierend bedeutet, der Teilnehmer wählt, die Zahl der Unterbrechungen entspricht der
gerade gewählten Adressziffer. Elektromechanische Zähler und Speicher, die hier nicht dargestellt
sind machen die Schaltung komplett. Jedes Bauelement hat über die Physik seine zugeordnete
Bedeutung in der Logik der Schaltung. Eine Trennung und damit eine Veränderung ist nicht
möglich.

Nachrichtentechnik

Datendeklaration, hier feste Datenzuordnung,
PCM30-Über-Rahmen
2 ms
Rahmen 125µs
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

K16 K16 K16 K16

Kennzeichen Kennzeichen Kennzeichen Kennzeichen Kennzeichen Kennzeichen
Sprachkanal 1 Sprachkanal 16 Sprachkanal 6 Sprachkanal 21 Sprachkanal 11 Sprachkanal 26

0 0 0 0 Y O N Y
Kennzeichen- Kennzeichen-
Rahmenken- meldewort
nungswort

(10)

Zur Wiederholung:
Der PCM30-Über-Rahmen dient zur Übertragung der vermittlungstechnischen
Signalisierung über ein PCM30- System. Jeweils 32 Kanäle werden über einen PCM30-
Rahmen von 125µs Dauer übertragen. Der erste dieser 32 Kanäle dient der
Synchronisation und dem Management, der 16. Kanal dient der vermittlungstechnischen
Signalisierung. Im 16ten Kanal stehen 8bit zur Verfügung, damit können 256
unterschiedliche Zustände übertragen werden. Bei 30 Nutzkanälen könnten - ohne
Verwendung eines Über-Rahmens- nur 256/30=8,5 unterschiedliche Meldungen für
jeden Nutzkanal übertragen werden. Es ließen sich also schon nicht einmal die 10
Wahlziffern übertragen. Der gewählte Über-Rahmen ordnet nun jeden 16ten Kanal
genau zwei Nutzkanälen für die Signalisierung zu. Damit stehen 4 Bit /Kanal in
125µs*16=2ms zur Verfügung. Dies entspricht einer Datenrate von 4bit/2ms=2Kbit/s.

Zur Datendeklaration:
Die Zuordnung der Bits zu den einzelnen Kanälen ist fix. Die Interpretation der
Signalisierungsinformation ist einfach. Veränderungen des Systems können nur nach
langwieriger internationaler Standardisierungsprozedur vorgenommen werden. Der Preis
für eine weltweit eineindeutige Datendeklaration ist die Inflexibilität.
Die Deklaration ist Bit-orientiert.

Nachrichtentechnik

Datendeklaration,
hier feste Datenzuordnung

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Type of Service
0 Version IHL 3
Total length
NM
4 7
Identification Fragment Offset
FF
0
8 11
Protocol Header Checksum
Time to live
12 15
Source Address
16 19
Destination Address
Options
Padding
DATA
65532 65535
max. 65535 8bit-Wörter

(11)

Version: gibt die Version des Protokolles an, IP-Implementierungen müssen alle gültigen Versionen
enthalten
IHL: Internet Header Length, Zeiger auf den Beginn der Daten, min:5
Type of service: Angabe der Eigenschaften des Services, Vorrang e.t.c. (s.nächste Folie)
total length: mithilfe von 16 Bits können Datagramme mit eine Länge über alles von maximal 65535
Oktetts übertragen werden. Minimum ist 576 Oktetts. Ein Host darf nur mehr als 576
Oktetts in ein Datagramm einpacken, wenn er sicher ist, daß
die Gegenstelle die Länge auch empfangen kann.
identification: eindeutige Bezeichnung für alle Fragmente eines fragmentierten Datagrams
flags: Indizieren die Fragmentierung: Bit 0 reserviert; Bit1 0 may fragment /1 dont´t fragment; Bit2 0
last fragment / 1 more fragments
fragment offset:Indikation für die Reihenfolge der Fragmente, Zeiger auf die Fragmente Offset des ersten
Fragments ist 0,spätere Werte sind Vielfache von 8 Oktetts
time to live: Wenn dies Feld den Wert null hat, wird das Datagramm entfernt. Der eingetragene Wert
entspricht einer maximalen Lebensdauer in Sekunden. Jede
Verarbeitungseinheit im Internet dekrementiert dies Feld um mindestens eins,
auch wenn die Bearbeitung schneller als eine Sekunde ist. Ziel ist, nicht zustellbare
Datagramme automatisch zu entfernen.
protocol: spezifizeirt das Protokoll der nächsten Schicht im OSI-Modell, also z.B., ob das Datagramm
an TCP(6) oder UDP(17) geliefert werden soll.
HCS: Die header check sum sichert den Header, und nur den. Da der Header seinen Wert in jeder
Verarbeitungsstation ändert, muß HCS jedes mal neu berechnet werden.
Source/Destination Address: je 32 bit lang (s.Diskussion der Adressen)
Options: das Senden ist optional, nicht die Implementierung im Protokoll (s.gesonderte Folie)
Padding: Auffüllen der Daten auf 32 bit am Ende des Datenfeldes
In diesem Beispiel ist die Welt nicht mehr so heile wie beim PCM30-Über-Rahmen. Es sind bereits Längen
und Typ-Elemente vorhanden (Typ:=Version, Länge:=IHL). Und auch die optionale Länge ist bei den
Optionen vorhanden. Alle anderen Variablen sind aber ebenfalls fix. Außerdem ist das TLV-Prinzip nicht
rekursiv implementiert (s. Nächste Folien). Aus dieser Rekursion ergibt sich ein besonders hoher Freiheitsgrad
für den Implementierer.
Die Daten gehören zur Klasse der Bit- oder Oktett-orientierten Darstellungsweise.
Die Auswertung dieser Art der Datendeklaration ist sehr effizient. Die empfangenen Daten werden maskiert
und gegen die Erwartungswerte geprüft. Problematisch ist die gemeinsame Festlegung von Syntax und Inhalt
der Protokollnachricht. Dadurch wird die Änderungs- und Ergänzungsfähigkeit stark eingeschränkt. Für eine
Ergänzung muß möglicherweise der Rahmen erweitert werden, s.a. Umstieg von IP Version 4 auf IP Version

Nachrichtentechnik

Datendeklaration, hier ILC-Verfahren
(Identifier, Length, Content)

Identifier Length
Content octets (1)
Octets Octets

Length
Identifier
Content octets (2)
Octets
Octets

Length Length
Identifier Content Identifier Content
Octets Octets
Octets octets (3) Octets octets (4

Synonym: Type, Length, Variable (TLV);
die hier gewählte Nomenklatur entspricht der ITU Rec. X.209

(12)

Die Angabe des Typs erlaubt die Wahlfreiheit bezüglich der Zeit der
Nachrichtenübermittlung, während die Länge die Anpassung an Optionen
unterschiedlicher Länge zuläßt. Die Rekursion ermöglicht die Wiederverwendung bereits
deklarierter Daten. Erkauft wird die Flexibilität mit einem Overhead, der mit der
Rekursionstiefe steigt.
Allgemein können die Daten Bit-, Oktett- oder Zeichen-orientiert sein. In ASN.1 wird
diese TLV-Methode eingesetzt, allerdings Oktett-orientiert.
Bekannt ist diese rekursive Schachtelung bereits aus der Protokollschachtelung, z.B. IP
over IEEE802.3 (Ethernet) oder IP over ATM over IEEE802.3. Auch dort wird die
Flexibilität mit steigendem Overhead erkauft.
Eine weitere Anwendung dieses Typs der rekursiven Schachtelung finden wir in den
Schichten des OSI-Modelles. Jede folgende Schicht fügt der Protokollinformation der
vorangegangenen Schicht wieder Header und ggfs. Trailer bei.
In beiden Anwendungen wird jedoch nicht zwangsweise der Typ und die Länge definiert!
Die Beispiele sind also nur technologisch vergleichbar, sie entsprechen nicht exakt dem
TLV-Ansatz.

Nachrichtentechnik

Datendeklaration,
hier EDIFACT

repetition

mandatory

Name

conditional

(13)

This approach comes closest to ASN.1, with a clear (graphical) notation for abstract syntax
specification, and a separate encoding rule specification. An example of the Electronic Data
Interchance For Administration, Commerce and Transport (EDIFACT) graphical syntax is given in
the figure above: EDIFACT graphical syntax. As with ASN.1, the definition of the total message
can be
done in conveniently sized chunks using reference names for the chunks, then those chunks are
combined to define the complete message. So in Figure 11 we have the message fragment
(defined
earlier or later) quot;UNHquot; which is mandatorily present once, similarly quot;AAAquot;, then quot;BBBquot; which is
conditional and is present zero to ten times, then quot;CCCquot; similarly, then up to 200 repetitions of a
composite structure consisting of one quot;DDDquot; followed by up to ten quot;EEEquot;, etc.
The actual encoding rules were, as with ASN.1, specified separately, but were based on character
encoding of all fields. The graphical notation is less powerful than the ASN.1 notation, and the
range of primitive types much smaller. The encoding rules also rely on the application designer to
ensure that a type following a repeated sequence is distinct from the type in that repeated
sequence,
otherwise ambiguity occurs. This is a problem avoided in ASN.1, where any legal piece of ASN.1
produces unambiguous encodings.
At the implementation level, it would be possible to map the EDIFACT definition into a data-
structure
for the implementation language, but I am not aware of any tools that currently do this.

Nachrichtentechnik

Datendeklaration,
hier zeichenorientiert

(14)

John Larmouth:
Where this character-based approach is employed, the precise set of lines of text
permitted for
each message has to be clearly specified. This specification is akin to the definition of an
abstract
syntax, but with more focus on the representation of the information on the line than
would be
present in an ASN.1 definition of an abstract syntax.
The notation used to define this syntax is usually some variation of a notation frequently
used to
define the syntax of programming languages (and indeed used to define the syntax of
ASN.1
itself), something called Bacchus-Naur Form (BNF), named after its original inventors.
For example, in ASN.1, the BNF statements:

EnumeratedType ::= ENUMERATED { Enumeration }
Enumeration ::= NamedNumber | Enumeration , NamedNumber
NamedNumber ::= identifier(SignedNumber)
SignedNumber ::= number | - number

are used to specify that one of the constructs of the language consists of the word
“ENUMERATED”, followed, in curly brackets, by a comma-separated list with each item
being an
identifier followed by a number (possibly preceded by a minus sign) in round brackets.

Nachrichtentechnik

Datendeklaration,
hier ASN.1/BER
Separation of

Type deklaration (specification of information content)
deklaration of Encoding rules (tools) and
representation of values

(15)

Nachrichtentechnik

TYPEN und WERTE

Ein TYP ist ein nicht leerer Satz von WERTEN
Beispiel: wahlziffer INTEGER (0..9) oder
nstNr INTEGER (2000..8999)
Der Typ gibt den Bereich der möglichen Werte an, die als
Information übertragen werden können, übertragen werden nur
Werte
Der Wertebereich ist in den Klammern angegeben und reicht bei
der Wahlziffer von 0 bis 9 und bei der NstNr von 2000 bis 8999
Die Angabe des Typs erlaubt automatisierte Prüfungen, auf
Korrektheit empfangener und oder übergebener Werte

(16)

Nachrichtentechnik

SUBTYP und ELTERNTYP

Ein TYP ist ein SUBTYP, wenn er den Elementen eines
ELTERNTYPS entnommen ist

Beispiel: Amtsanlassung ::= Wahlziffer (0|9)

Wahlziffer ist ELTERNTYP, der SUBTYP kann die WERTE 0
oder 9 annehmen; | steht für quot;oderquot;; ::= steht für quot;ist definiert alsquot;

(17)

Nachrichtentechnik

EINFACH-TYPEN (simple types) und
STRUKTURIERTE TYPEN
EINFACH-TYPEN sind in ASN.1 definiert und müssen nicht
vom Nutzer definiert werden, der Nutzer kann darauf
zurückgreifen

STRUKTURIERTE TYPEN sind aus EINFACH-TYPEN oder
STRUKTURIERTEN TYPEN vom Anwender
zusammengesetzt

(18)

Nachrichtentechnik

Typ-Deklarationen in ASN.1

EINFACH TYPEN (Simple Types)
INTEGER, REAL, NULL, BOOLEAN
ENUMERATED (Aufzählung)
BITSTRING, OCTETTSTRING
OBJECT IDENTIFIER
NumericString
PrintableString
TeletexString
VideotexString
VisibleString, GraphicString

(19)

die meisten Deklarationen sind selbsterklärend.
Der ENUMERATED type deklariert eine Zahl von vordefinierten Werten, z.B. die
Wochentage:
DaysOfTheWeek::=ENUMERATED
{
sunday(0), moday(1), tuesday(2), wednesday(3), thursday(4),
friday(5), saturday(6)
}
Die Werte, die DaysOfTheWeek übertragen kann sind die Ziffern, nicht die Namen der
Wochentage. Die Semantik wird den Ziffern bei der Interpretation zugewiesen.
Object Identifier:
erlaubt die dezentrale Vergabe von globalen Werten mittels eines Baumes. Der Baum
mit den Ojectidentifiern wird zentral oder dezentral aber hierarchisch gepflegt. Die Blätter
des Baumes können dezentral bearbeitet werden. Als Beispiel können die im Internet
vergebenen Adressen genannt werden. Die 130.75 für das Uni-Netz Hannover wird von
der Uni Karlsruhe (als nationales NIC, Network Information Center) vergeben. Der Rest
der Nummer: 130.75.73.80 wird lokal gepflegt. Der aktuelle Wert des Object Identifiers
wäre also 130.75

Nachrichtentechnik

STRUKTURIERTE TYPEN

MSISDN ::= SEQUENCE
{
ausscheidungsziffer PRINTABLE STRING (quot;+quot;),
landeskennzahl INTEGER (1..999),
netzkennzahl INTEGER (171..179),
tlnZiffer1 INTEGER (0..9),
tlnZiffer7 INTEGER (0..9)
}
Formal ist diese Definition richtig, jedoch wird sie kaum
so angewendet werden. Was sollte geändert werden?

Lösung
(20)

Nachrichtentechnik

STRUKTURIERTE TYPEN

MSISDN ::= IA5String Size (14) FROM
(„0“|“1“|“2“|“3“|“4“|“5“|“6“|“7“|“8“|“9“|“+“)
oder
deutscheMSISDN ::= SEQUENCE
{
ausscheidungsziffer ::= IA5String („+“),
landeskennzahl ::= IA5String Size (1..3) FROM
(“1“|“2“|“3“|“4“|“5“|“6“|“7“|“8“|“9“),
erstenetzkennzahl ::= IA5String (“1“),
zweitenetzkennzahl ::= IA5String FROM (“6“|“7“|“8“),
drittenetzkennzahl ::= IA5String FROM
(„0“|“1“|“2“|“3“|“4“|“5“|“6“|“7“|“8“|“9“),

teilnehmernummer ::= IA5String SIZE (7) FROM
(“1“|“2“|“3“|“4“|“5“|“6“|“7“|“8“|“9“)
}

(21)

Nachrichtentechnik

Übung

Definieren Sie eine MSISDN in BNF (Backus-Naur Format)
Beziehen Sie die Ausscheidungskennziffer in die
Definition ein.
Lösung

(22)

Nachrichtentechnik

TYP - Zuweisung (type assingment)

aus dem vorigen Beispiel:
1.Teil: Name des zu definierenden Typs (hier MSISDN)
2.Teil: Zuweisungssymbol ::=
3.Teil: Tabelle der Elemente, einschließlich Typdeklaration

(23)

Nachrichtentechnik

Wertzuweisung

meineMSISDN MSISDN ::=
{
ausscheidungsziffer quot;+quot;,
landeskennzahl 49,
netzkennzahl 171,
tlnZiffer1 4,
tlnZiffer2 3,
tlnZiffer3 8,
tlnZiffer4 8,
tlnZiffer5 7,
tlnZiffer6 2,
tlnZiffer7 1
}

(24)

Nachrichtentechnik

Namen

Die Namen definierter Typen und Werte werden
Referenzen genannt:

type reference MSISDN
value reference meineMSISDN
identifier ausscheidungsziffer

In ASN.1 verwendete Namen bestehen aus folgenden
Elementen:
Großbuchstaben ABCDEFGHIJKLMNOPQRSTUVWXYZ
Kleinbuchstaben abcdefghijklmnopqrstuvwxyz
Dezimalziffern 0123456789
hyphen -

(25)

Das erste Zeichen im Namen muß ein Buchstabe sein
Namen mit großen oder kleinen Buchstaben sind unterschiedliche Namen: Zahl ist ein
anderer Name als zahl
Type und Module Referenzen müssen mit großen Buchstaben beginnen
Wertereferenzen und Identifier müssen mit kleinem Buchstaben beginnen
Ein hyphen muß allein stehen und darf nicht am Anfang oder Ende eines Namens
auftauchen
Es gibt keine Längenbeschränkung für Namen

Nachrichtentechnik

Reservierte Namen

BOOLEAN BEGIN ANY SIZE
INTEGER END EXTERNAL FROM
BIT DEFINITIONS OBJECT WITH
STRING EXPLICIT IDENTIFIER COMPONENT
OCTET ENUMERATED OPTIONAL PRESENT
NULL EXPORTS DEFAULT ABSENT
COMPONENTS DEFINED
SEQUENCE IMPORTS
UNIVERSAL
OF REAL BY
APPLICATION
SET INCLUDES PLUS-INFINITY
IMPLICIT MIN PRIVATE MINUS-INFINITY
CHOICE MAX TRUE TAGS
FALSE

(26)

Nachrichtentechnik

Modules

Modules dienen der Gruppierung und dem Austausch von
Definitionen
Sie haben einen Kopf mit einem Modulnamen, einem tag,
dem Schlüsselwort DEFINITIONS und dem
Definitionszeichen ::=
Module haben einen Body, bestehend aus den
Definitionen, eingeschlossen von BEGIN und END
Beispiel:
Rufnummern {objectidentifier} DEFINITIONS ::=
BEGIN
MSISDN ::= SEQUENCE {...}
meineMSISDN MSISDN ::= {...}
END

(27)

Nachrichtentechnik

Import und Export

Um Definitionen aus Modulen, z.B. Bibliotheksmodulen
anderen Benutzern zugänglich zu machen, müssen die
Bibliotheksmodule mit dem Statement EXPORTS versehen
sein. Die Einführung fremder Definitionen in die eigenen
Scripte erfolgen mit dem Wort IMPORTS.
EXPORTS und IMPORTS können mit einer Namenliste der
zu transportierenden Deklarationen versehen sein.

User
Library IMPORTS ...
MSISDN, meineMSISDN;
EXPORTS MSISDN, meineMSISDN; FROM Rufnummern {object identifier}
..... ;

(28)

Nachrichtentechnik

Basic Encoding Rules (BER)

Creation of Runtime-Modules for the Encoding and
Decoding of data streams
Names of data, Types of Data are specified using ASN.1
The BER defines exactly Encoding/Decoding of these data
specified with ASN.1
BER is part of the Presentation-Layers in the OSI-Model
PER (packed ER), CER (canonical ER), DER (distinguished
ER) are enhancements for better efficiency

(29)

Reference: ITU Rec. X.209, Open Systems Interconnection, Model and Notation,
Specification of Basic encoding rules for abstract syntax notation one
Recommendation X.208 (Specification of Abstract Syntax Notation One) specifies a
notation for the definition of abstract syntaxes, enabling application layer specifications to
define the types of information they need to transfer using the presentation service. It
also specifies a notation for the specification of value of a defined type.
This Recommendation defines a set of encoding rules that may be applied to
values of types defined using the notation specified in Recommendation X.208.
Application of these encoding rules produces a transfer syntax for such values. It is
implicit in the specification of these encoding rules that they are also to be used for
decoding.
There may be alternative encodings are permitted. by this Recommendation as a
sender's option. Conforming receivers shall support all alternatives.e more than one set
of encoding rules that can be applied to values of types that are defined using the
notation of Recommendation X.208. This Recommendation defines one set of encoding
rules, called basic encoding rules.
Intentionally the BER´s are defined for the interpretation the application layer (layer 7) of
protocols, hence they are implemented in layer 6 of the OSI-Protocol stack.
Alternative encodings are permitted. by ASN.1 and BER as a sender's option.
Conforming receivers shall support all alternatives.
The Enhancements are handled later. The Efficiency is suffering from the repeated
introduction of the Identifier- and Length Octetts in case of constructed Data.

Nachrichtentechnik

Allokation der BER

Vor Beginn einer Sitzung sind die
zu verwendenden BER auszuhandeln

Endsystem Endsystem

Application
Anwendung 7 7
Presentation
Darstellung 6 6
session
Transit-
Sitzung 5 5
system
Transport
Transport 4 4
Network
Netzwerk 3
3 3
data link
Sicherung 2
2 2
physical
Bit-ÜT 1
1 1

Übertragungssystem

(30)

Die Systeme werden in Schichten eingeteilt, die Schichten numeriert. Den Schichten
werden bestimmte Funktionsgruppen zugewiesen.
Die Funktionsgruppen sind:
bit Übertragungs-Schicht- physical layer
Sicherung-Schicht - data link layer
Netzwerk-Schicht - network layer
Transport-Schicht - transport layer
Sitzungs-Schicht - session layer
Darstellungs-Schicht - presentation layer
Anwendungs-Schicht - application layer

Das Transitsystem verfügt über maximal drei Schichten. Die Schichten 4 bis 7 sind nur in
den Endgeräten vorhanden. Es existieren auch Transitsysteme mit nur der Schicht 1
oder der Schicht 1 und 2.
Die übereinanderliegenden Schichten werden auch Stack genannt.

Nachrichtentechnik

Type - Length - Value (TLV)
Identifier, Length, Content

Daten, die gemäß der BER codiert sind, enthalten drei Felder:
Type, wird durch den Identifier gekennzeichnet (self identifying)
Length erlaubt die Synchronisation im Datenstrom (self delimiting)
Value ist das zu übertragende Datum, auch Content genannt

Identifier Length
Content octets (1)
Octets Octets

Schachtelungen sind in beliebiger Tiefe möglich:

I L C IL C
I L C

(31)

6 General rules for encoding
6.1 Structure of an encoding
6.1.1 The encoding of a data value shall consist of four components which shall appear
in the following order:
a) identifier octets (see § 6.2);
b) length octets (see § 6.3);
c) contents octets (see § 6.4);
d) end-of-contents octets (see § 6.5).
6.1.2 The end-of-contents octets shall not be present unless the value of the length
octets requires them to be present (see § 6.3). Strings of indefinite length are
Candidates for the end of content octets.

Nachrichtentechnik

Type- or Identifier-Octets (I)

der Identifier enthält drei Angaben:
die tag number (T) (eineindeutige Nummer der BER),
der Wert ist nach oben nicht beschränkt, aber für die Standardwerte wie
Integer, Real bereits festgelegt. Für Standardwerte wird das erste Oktett
verwendet. Die Concatenation ist möglich.
die tag class (C) definiert die Reichweite (universal, application wide,
context specific und private use)
die tag form (F) gibt Auskunft, ob es sich um ein einfaches Datum oder
ein konstruiertes handelt
Mithilfe des Identifiers werden die Datentypen eindeutig
numeriert und sind selbst-identifizierend

Identifier Length
Content octets (1)
Octets Octets

Form 87654321
Identifier Bit Nr.
class tag number
c:constructed
CCFTTTTT
Oktett: Inhalt
p:primitive

(32)

For tags(tag number) with a number ranging from zero to 30 (inclusive), the identifier
octets shall comprise a single.
Da fünf Bits für die BER zur Verfügung stehen, können 25 -1= 32 -1=31 BER-Nummern
verwendet werden. Die 32ste BER-Nummer wird zur Indikation der Concatenation
verwendet.
For tags (tag numbers) with a number greater than or equal to 31, the identifier shall
comprise a leading octet followed by one or more subsequent octets.

Using 2 Bits for the class allows for the differentiation of 4different classes. The encoding
of the class and the tag number form together the unique number of the BER. The
meaning of the 4 classes is given in the following table:
Class Bit 8 Bit 7

Universal 0 0
Application 0 1
Context-specific 1 0
Private 1 1

Nachrichtentechnik

Type- or Identifier-Octets (II)
concatenated tags

Identifier Length
Content octets (1)
Octets Octets

class Form 11111 1xxxxxxx 1xxxxxxx 0xxxxxxx

concatenation

termination
succession

succession
Indicator

Indicator
Indicator

Indicator
xxxxxxx : BER-number if higher than 30, positive Integer

(33)

For larger tag values, the first octet has all ones in bits 5 to 1, and the tag value is then
encoded in
as many following octets as are needed, using only the least significant seven bits of
each octet,
and using the minimum number of octets for the encoding. The most significant bit (the
quot;morequot;
bit) is set to 1 in the first following octet, and to zero in the last.
Thus tag numbers between 31 and 127 (inclusive) will produce two identifier octets, tag
numbers
between 128 and 16383 will produce three identifier octets. (Most ASN.1 specifications
keep tag
numbers below 128, so either 1 identifier octet - most common - or two identifier octets is
what
you will normally see, but I have seen a tag number of 999!.

Nachrichtentechnik

The Length Identifier (1)
definite length

Identifier Length
Content octets (1)
Octets Octets
Bit number 8 7 6 5 4 3 2 1
Length Encoding definite Form up to a length of 127
0
integer

87654321
87654321
number Length
1 Encoding definite Form indefinite length
succeeding
integer
octets

Options to encode a length of 7 content octets:

00001011 oder There is an incredible number of
10000001 00001011 oder possibilities!
10000010 00000000 00001011 oder
Does that matter?
10000011 00000000 00000000 00001011 oder
........

(34)

Self delimiting
definite form (for primitives or constructives if encoding is known during
specification)
• one to n octets
– one octet: bit 8=0, bit 7 to 1 integer value of number of content octets
(max=27-1=127)
– n octets:
• 1.octet:bit 8=1, bit 7 to 1 integer number of succeeding length
octets
• 2. to n`th octet: integer value of number of content octets 8
(no max)

Exercise: a.) encode the number of content octets to 3810
001001102
b.) encode the number of content octets to 20110
100000012 110010012

Nachrichtentechnik

The Length Identifier (1)
indefinite length

Identifier Length
Content octets (1)
Octets Octets

0 0 0 0 0 0 0is missing? 0 0
What 0 0 0 0 0 0 0
1 0000000 TLV TLV

(35)

indefinite form (for constructives especially if encoding is derived during run time)

With this form you do not need to count your octets before you start to send them - just ship a start
to send them - just ship a series of fragments and series of fragments and terminate with 0000.
The indefinite form of length can only be used (but does not have to be) if the V part is
constructed, that is
to say, consists of a series of TLVs. (The length octets of each of these TLVs in this contained
series can
independently be chosen as short, definite, or indefinite where such choices are available - the
form used at the outer level does not affect the inner encoding.)
In the indefinite form of length the first bit of the first octet is set to 1, as for the long form, but the
value N is set to zero. Clearly a value of zero for N would not be useful in the long form, so this
serves as a flag that the indefinite form is in use. Following this single octet, we get the series of
TLVs forming the V part, followed by a special delimiter that is a pair of zero octets.

Why do we need so many different variants of length? Clearly they all have some advantages and
disadvantages. The short form is the briefest when it can be used, the long form is the only one
that can handle very large primitive encodings, and seems to many to be intuitively simpler than
the indefinite form. The indefinite is the only one which allows very large OCTET STRINGvalues or
SEQUENCE OF values to be transmitted without counting the number of octets in the value before
starting.
The disadvantage of having three options is the extra implementation complexity in decoders, and
the presence of encoding options creating side-channels and extra debugging effort. If we want to
remove these options, then we have to either say quot;use indefinite length form whenever possible“
(and make statements about the size of fragment to use when fragmenting an octet string), or to
say quot;use short form where possible, otherwise use long form with the minimum value of N needed
for the countquot;. Both of these approaches are standardised! The distinguished/canonical encoding
rules that take the former approach are called the Canonical Encoding Rules (CER), and those
that take the latter approach are called the Distinguished Encoding Rules (DER). Applications with
requirements for canonical/distinguished encoding rules will mandate use of one of these in the
application specification.

Nachrichtentechnik

Decoding of content see
ITU Rec. X.209

(36)

Nachrichtentechnik

PER Packed Encoding Rules

BERs are bandwidth and processing power consuming
PERs
save Type and Length tags of the TLV data encoding where ever
possible (e.g. repeating data types)
save padding octets, save leading but empty bytes
pack data which do not need entire bytes as dense as possible
Warning: don‘t do that without encoding tools

(37)

Nachrichtentechnik

Ab hier nicht mehr drucken

(38)

Nachrichtentechnik

Beispiele von Messages
zurück
732915765498120738710333864322116
00126549876501
+491774213675
040774231
Wie interpretieren Sie diese Messages?
>Richtig, bei der ersten haben Sie keine
Chance, es ist ein Wetterbericht
>Die anderen scheinen Telefonnummern zu
sein
Was bitte wollen Sie mit scheinbaren Zuweisungen
anfangen?

(39)

Nachrichtentechnik

Lösung
zurück
MSISDN = {AccessCode; CountryCode; NetworkCode;
SubscriberNumber}
AccessCode = Plus | null | null null
CountryCode = digit | digit digit | digit digit digit
NetworkCode = eins sieben digit
SubscriberNumber = NonZeroDigit digit digit digit digit digit
digit
Plus = quot;+quot;
null =0
eins = 1
sieben = 7
digit = 0 | NonZeroDigit
NonZeroDigit = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

(40)

Nachrichtentechnik

STRUKTURIERTE TYPEN

MSISDN ::= SEQUENCE
{
ausscheidungsziffer PRINTABLE STRING (quot;+quot;),
landeskennzahl INTEGER (00..99),
netzkennzahl INTEGER (171..179),
tlnZiffer6 INTEGER (0..9,
tlnZiffer7 INTEGER (0..9)
}
Formal ist diese Definition richtig, jedoch wird sie kaum so angewendet
werden. Was sollte geändert werden?
Die Werte werden nicht als Integerwerte oder printable strings
übertragen, sondern als Elemente des IA5 - Alphabets.

(41)

Die Werte werden nicht als Integerwerte oder printable strings übertragen, sondern als
Elemente des IA5 - Alphabets.

Nachrichtentechnik

[17] Nu P 11 1

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (19)

Plus de Rafael Scudelari

Plus de Rafael Scudelari (20)

[17] Nu P 11 1