[17] Nu P 11 1

© UNI Hannover, Institut für Allgemeine Nachrichtentechnik

Institut für Kommunikationstechnikwww.ikt.uni-hannover.de

Protokolle der OSI-Schicht 6 Presentation LayerKapitel 11.1

Netze und ProtokolleDr.-Ing. Jan Steuer

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

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


(2)

Government Health Warning

ThisThis discussiondiscussioncancan damagedamage youryour brainbrain

• PAIRMACRO ::= BEGINTYPE NOTATION ::=

”TYPEX””=”type (Local-type-1)ty-- Expects any ASN.1 type and assigns itty-- to the variable Local-type-1;”TYPEY””=”type (Local-type-2)ty-- Expects a second ASN.1 type and assignsty-- it to the variable Local-type-2;

• VALUE NOTATION ::=”(””X””=”value (Local-value-1 Local-type-1)va-- Expects a value for the type inva-- Local-type-1, and assigns itva-- to the variable Local-value-1;”,””Y””=”value (Local-value-2 Local-type-2)va-- Expects a value for the type inva-- Local-type-2 and assigns itva-- 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


(3)

Basic CallState Model

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

SDLSpecification and Description

Language

ASN.1/BER (s.XML)Abstract Syntax Notation

Basic Encoding Rules

Dynamische Be-schreibung der Vor-gänge in einem TK-System /Description of system dynamics

Beschreibung des Datenaus-Tausches/SpecificationDataexchange

Coding, e.g. C++, JAVA, ADA, CHILL

Programmiersprachen für Telekommunikationssysteme

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äufeBeschreibung 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 andlanguage-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-independentand language-independent) to represent values of these data-structures whenthey have to be transferred over a computer network, using encodings that are notunnecessarily verbose. · It is supported by tools available for most platforms and several programming languagesthat map the ASN.1 notation into data-structure definitions in a computer programminglanguage of choice, and which support the automatic conversion between values of thosedata-structures in memory and the defined bit-patterns for transfer over a communicationsline. (The tools are described in Chapter 6 of Section I).


(4)

System 1 System 2

ASN.1

Vorwärts-Message

Rückwärts-Message

ASN.1- Zweck

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

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.


(5)

Beispiele von Messages

73291576549812073871033386432211600126549876501+491774213675040774231

Wie interpretieren Sie diese Messages? Lösung


(6)

Wetterbericht im festen Format

Oktett Bezeichnung Codierung1-3 station number 5BCD-Oktetts, letztes Halboktett unbenutzt4 year 2BDC-Digits5 month 2BDC-Digits6 day 2BDC-Digits7 hour 2BDC-Digits8 minute 2BDC-Digits9 second 2BDC-Digits10-11 pressure 4BCD-Digits12 temperature sign 2BDC-Digits all 0 for plus, all 1 for minus13 temperature, magnitude 2BDC-Digits14-15 humidity 3BCD-Oktetts, letztes Halboktett unbenutzt16-17 wind velocity 3BCD-Oktetts, letztes Halboktett unbenutzt18 wind direction 2BDC-Digits

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.


(7)

Deklaration für den Wetterbericht

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

StationNumber = PositiveNumberDateAndTime = Year Month Day Hour Minute SecondPressure = PositiveNumberTemperature = NumberHumidity = PositiveNumberWindVelocity = PositiveNumberWindDirection = PositiveNumber

Year = TwoDigitsMonth = MonthDigitsDay = DayDigitsHour = HourDigitsMinute = MinuteSecondSecond = MinuteSecond

TwoDigits = Digit DigitMonthDigits = 01 .. 12DayDigits = 01 .. 31HourDigit = 00 .. 23MinuteSecond = 00 .. 60PositivNumber = NonZeroDigit DigitSequence | DigitDigitSequence = Digit DigitSequence | Digit (rekursiv)Number = PositivNumber | -PositivNumberDigit = 0 | NonZeroDigitNonZeroDigit = 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 sindDie 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 spezifiziertWo steckt hier noch eine Ungenauigkeit? (richtig: Die Tageszahl 30/31 ist vom Monat abhängig) Wie würden Sie diese Schwachstelle beseitigen?


(8)

Datendeklaration für Datentransportsysteme, historische Entwicklung

Physikalische „Link-Protokolle“ wie beim analogen TelefonFeste 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)

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.


(9)

Datendeklaration, hier: analoge Telefonleitung

„Link-Protokoll“ am Beispiel der analogen Telefonleitungphysikalische 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]

A

-60V

A

0V

Vermittlungsstelle

500

500

0..30mA Schleifenstrom

100

a

T

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


(10)

Datendeklaration, hier feste Datenzuordnung,PCM30-Über-Rahmen

2 msRahmen

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

125µs

0 0 0 0 Y O N Y

Kennzeichen-Rahmenken-nungswort

Kennzeichen-meldewort

Kennzeichen Sprachkanal 1






K16 K16 K16 K16

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.


(11)

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

Version IHL Type of Service

Identification

Time to live Protocol

Source Address

Destination Address

OptionsPadding

DATA

Header Checksum0

NF

MF Fragment Offset

Total length

max. 65535 8bit-Wörter

0

4

8

12

16

65532

3

7

11

15

19

65535

Version: gibt die Version des Protokolles an, IP-Implementierungen müssen alle gültigen Versionen enthaltenIHL: Internet Header Length, Zeiger auf den Beginn der Daten, min:5Type 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 Datagramsflags: Indizieren die Fragmentierung: Bit 0 reserviert; Bit1 0 may fragment /1 dont´t fragment; Bit2 0 last fragment / 1 more fragmentsfragment 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 Oktettstime 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 Datagramman 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 DatenfeldesIn 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


(12)

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

IdentifierOctets

LengthOctets Content octets (1)

IdentifierOctets


IdentifierOctets

LengthOctets

Contentoctets (3)

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

IdentifierOctets

LengthOctets

Contentoctets (4

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.


(13)

Datendeklaration, hier EDIFACT

Name

mandatory

repetition

conditional

This approach comes closest to ASN.1, with a clear (graphical) notation for abstract syntaxspecification, and a separate encoding rule specification. An example of the Electronic DataInterchance For Administration, Commerce and Transport (EDIFACT) graphical syntax is given inthe figure above: EDIFACT graphical syntax. As with ASN.1, the definition of the total messagecan bedone in conveniently sized chunks using reference names for the chunks, then those chunks arecombined to define the complete message. So in Figure 11 we have the message fragment(definedearlier or later) "UNH" which is mandatorily present once, similarly "AAA", then "BBB" which isconditional and is present zero to ten times, then "CCC" similarly, then up to 200 repetitions of acomposite structure consisting of one "DDD" followed by up to ten "EEE", etc.The actual encoding rules were, as with ASN.1, specified separately, but were based on characterencoding of all fields. The graphical notation is less powerful than the ASN.1 notation, and therange of primitive types much smaller. The encoding rules also rely on the application designer toensure that a type following a repeated sequence is distinct from the type in that repeatedsequence,otherwise ambiguity occurs. This is a problem avoided in ASN.1, where any legal piece of ASN.1produces unambiguous encodings.At the implementation level, it would be possible to map the EDIFACT definition into a data-structurefor the implementation language, but I am not aware of any tools that currently do this.


(14)

Datendeklaration, hier zeichenorientiert

John Larmouth:Where this character-based approach is employed, the precise set of lines of text permitted foreach message has to be clearly specified. This specification is akin to the definition of an abstractsyntax, but with more focus on the representation of the information on the line thanwould bepresent in an ASN.1 definition of an abstract syntax.The notation used to define this syntax is usually some variation of a notation frequentlyused todefine the syntax of programming languages (and indeed used to define the syntax of ASN.1itself), 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 itembeing anidentifier followed by a number (possibly preceded by a minus sign) in round brackets.


(15)

Datendeklaration, hier ASN.1/BER

Separation of

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


(16)

TYPEN und WERTE

Ein TYP ist ein nicht leerer Satz von WERTENBeispiel: 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 WerteDer 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


(17)

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 "oder"; ::= steht für "ist definiert als"


(18)

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


(19)

Typ-Deklarationen in ASN.1

EINFACH TYPEN (Simple Types)INTEGER, REAL, NULL, BOOLEANENUMERATED (Aufzählung)BITSTRING, OCTETTSTRINGOBJECT IDENTIFIERNumericStringPrintableStringTeletexStringVideotexStringVisibleString, GraphicString

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 Identifierswäre also 130.75


(20)

STRUKTURIERTE TYPEN

MSISDN ::= SEQUENCE {ausscheidungsziffer PRINTABLE STRING ("+"),landeskennzahl INTEGER (1..999),netzkennzahl INTEGER (171..179),tlnZiffer1 INTEGER (0..9),tlnZiffer2 INTEGER (0..9), tlnZiffer3 INTEGER (0..9),tlnZiffer4 INTEGER (0..9),tlnZiffer5 INTEGER (0..9),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?

Lösung


(21)

STRUKTURIERTE TYPEN

MSISDN ::= IA5String Size (14) FROM („0“|“1“|“2“|“3“|“4“|“5“|“6“|“7“|“8“|“9“|“+“)

oderdeutscheMSISDN ::= 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“)

}


(22)

Übung

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

Lösung


(23)

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


(24)

Wertzuweisung

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


(25)

Namen

Die Namen definierter Typen und Werte werden Referenzen genannt:

type reference MSISDN value reference meineMSISDNidentifier ausscheidungsziffer

In ASN.1 verwendete Namen bestehen aus folgenden Elementen:Großbuchstaben ABCDEFGHIJKLMNOPQRSTUVWXYZKleinbuchstaben abcdefghijklmnopqrstuvwxyzDezimalziffern 0123456789hyphen -

Das erste Zeichen im Namen muß ein Buchstabe seinNamen mit großen oder kleinen Buchstaben sind unterschiedliche Namen: Zahl ist ein anderer Name als zahlType und Module Referenzen müssen mit großen Buchstaben beginnenWertereferenzen und Identifier müssen mit kleinem Buchstaben beginnenEin hyphen muß allein stehen und darf nicht am Anfang oder Ende eines Namens auftauchenEs gibt keine Längenbeschränkung für Namen


(26)

BOOLEAN BEGININTEGER ENDBIT DEFINITIONSSTRING EXPLICITOCTET ENUMERATEDNULL EXPORTSSEQUENCE IMPORTSOF REALSET INCLUDESIMPLICIT MINCHOICE MAX

SIZEFROMWITHCOMPONENTPRESENTABSENTDEFINEDBYPLUS-INFINITYMINUS-INFINITYTAGS

ANYEXTERNALOBJECTIDENTIFIEROPTIONALDEFAULTCOMPONENTSUNIVERSALAPPLICATIONPRIVATETRUEFALSE

Reservierte Namen


(27)

Modules

Modules dienen der Gruppierung und dem Austausch von DefinitionenSie 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 ENDBeispiel:Rufnummern {objectidentifier} DEFINITIONS ::=BEGIN

MSISDN ::= SEQUENCE {...}meineMSISDN MSISDN ::= {...}

END


(28)

EXPORTS MSISDN, meineMSISDN;

IMPORTS ...MSISDN, meineMSISDN;

FROM Rufnummern {object identifier}..... ;

Library User

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.


(29)

Basic Encoding Rules (BER)

Creation of Runtime-Modules for the Encoding andDecoding 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.1BER is part of the Presentation-Layers in the OSI-Model

PER (packed ER), CER (canonical ER), DER (distinguished ER) are enhancements for better efficiency

Reference: ITU Rec. X.209, Open Systems Interconnection, Model and Notation, Specification of Basic encoding rules for abstract syntax notation oneRecommendation 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.


(30)

Übertragungssystem

Transit-system

Endsystem Endsystem

7654321

7654321

321

AnwendungDarstellungSitzungTransportNetzwerkSicherungBit-ÜT

ApplicationPresentationsessionTransportNetworkdata linkphysical

Vor Beginn einer Sitzung sind die zu verwendenden BER auszuhandeln

Allokation der BER

Die Systeme werden in Schichten eingeteilt, die Schichten numeriert. Den Schichten werden bestimmte Funktionsgruppen zugewiesen.Die Funktionsgruppen sind:bit Übertragungs-Schicht- physical layerSicherung-Schicht - data link layerNetzwerk-Schicht - network layerTransport-Schicht - transport layerSitzungs-Schicht - session layerDarstellungs-Schicht - presentation layerAnwendungs-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.


(31)

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

Schachtelungen sind in beliebiger Tiefe möglich:

I L C I L C I L C

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

IdentifierOctets


6 General rules for encoding6.1 Structure of an encoding6.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.


(32)

8 7 6 5 4 3 2 1C C F T T T T T

IdentifierOktett:

Bit Nr.Inhalt

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

IdentifierOctets


classFormc:constructedp:primitive

tag number

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-Nummernverwendet 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 encodingof the class and the tag number form together the unique number of the BER. Themeaning 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


(33)

Type- or Identifier-Octets (II)concatenated tags

IdentifierOctets


class Form 1 1 1 1 1 1 x x x x x x x 1 x x x x x x x 0 x x x x x x x

Indi

cato

rco

ncat

enat

ion

Indi

cato

rsu

cces

sion

Indi

cato

rsu

cces

sion

Indi

cato

rte

rmin

atio

n

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

For larger tag values, the first octet has all ones in bits 5 to 1, and the tag value is thenencoded inas 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"more"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 numbersbetween 128 and 16383 will produce three identifier octets. (Most ASN.1 specificationskeep tagnumbers below 128, so either 1 identifier octet - most common - or two identifier octets iswhatyou will normally see, but I have seen a tag number of 999!.


(34)

The Length Identifier (1)definite length

IdentifierOctets


8 7 6 5 4 3 2 1

0 Lengthinteger

Encoding definite Form up to a length of 127

Bit number

8 7 6 5 4 3 2 1

1numbersucceedingoctets

Encoding definite Form indefinite length

8 7 6 5 4 3 2 1Lengthinteger

Options to encode a length of 7 content octets:

00001011 oder10000001 00001011 oder10000010 00000000 00001011 oder10000011 00000000 00000000 00001011 oder........

There is an incredible number ofpossibilities!

Does that matter?

Self delimitingdefinite 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 3810001001102

b.) encode the number of content octets to 20110100000012 110010012


(35)

What is missing?

The Length Identifier (1)indefinite length

IdentifierOctets


1 0 0 0 0 0 0 0 TLV TLV 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

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 isconstructed, that isto say, consists of a series of TLVs. (The length octets of each of these TLVs in this containedseries canindependently be chosen as short, definite, or indefinite where such choices are available - theform 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 thevalue N is set to zero. Clearly a value of zero for N would not be useful in the long form, so thisserves 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 onethat can handle very large primitive encodings, and seems to many to be intuitively simpler thanthe indefinite form. The indefinite is the only one which allows very large OCTET STRINGvalues orSEQUENCE OF values to be transmitted without counting the number of octets in the value beforestarting.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 "use indefinite length form whenever possible“(and make statements about the size of fragment to use when fragmenting an octet string), or to say "use short form where possible, otherwise use long form with the minimum value of N neededfor the count". Both of these approaches are standardised! The distinguished/canonical encodingrules that take the former approach are called the Canonical Encoding Rules (CER), and thosethat take the latter approach are called the Distinguished Encoding Rules (DER). Applications withrequirements for canonical/distinguished encoding rules will mandate use of one of these in theapplication specification.


(36)

Decoding of content seeITU Rec. X.209


(37)

PER Packed Encoding Rules

BERs are bandwidth and processing power consumingPERs

save Type and Length tags of the TLV data encoding where everpossible (e.g. repeating data types)save padding octets, save leading but empty bytespack data which do not need entire bytes as dense as possibleWarning: don‘t do that without encoding tools


(38)

Ab hier nicht mehr drucken


(39)

Beispiele von Messages

73291576549812073871033386432211600126549876501+491774213675040774231Wie 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?

zurück


(40)

Lösung

MSISDN = {AccessCode; CountryCode; NetworkCode; SubscriberNumber}

AccessCode = Plus | null | null nullCountryCode = digit | digit digit | digit digit digitNetworkCode = eins sieben digitSubscriberNumber = NonZeroDigit digit digit digit digit digit

digitPlus = "+"null = 0eins = 1sieben = 7digit = 0 | NonZeroDigitNonZeroDigit = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

zurück


(41)

STRUKTURIERTE TYPEN

MSISDN ::= SEQUENCE {ausscheidungsziffer PRINTABLE STRING ("+"),landeskennzahl INTEGER (00..99),netzkennzahl INTEGER (171..179),tlnZiffer1 INTEGER (0..9),tlnZiffer2 INTEGER (0..9), tlnZiffer3 INTEGER (0..9),tlnZiffer4 INTEGER (0..9),tlnZiffer5 INTEGER (0..9),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.

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