Your SlideShare is downloading. ×
[17] Nu P 11 1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

[17] Nu P 11 1

348
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
348
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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
  • 2. 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
  • 3. 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). © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 4. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 5. Beispiele von Messages 732915765498120738710333864322116 00126549876501 +491774213675 040774231 Wie interpretieren Sie diese Messages? Lösung (5) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 6. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 7. 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? © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 8. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 9. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 10. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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 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 © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 12. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 13. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 14. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 15. Datendeklaration, hier ASN.1/BER Separation of Type deklaration (specification of information content) deklaration of Encoding rules (tools) and representation of values (15) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 16. 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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 quot;oderquot;; ::= steht für quot;ist definiert alsquot; (17) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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 (18) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 19. 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 © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 20. STRUKTURIERTE TYPEN MSISDN ::= SEQUENCE { ausscheidungsziffer PRINTABLE STRING (quot;+quot;), 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 (20) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 21. 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 22. Übung Definieren Sie eine MSISDN in BNF (Backus-Naur Format) Beziehen Sie die Ausscheidungskennziffer in die Definition ein. Lösung (22) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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 (23) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 24. 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 25. 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 © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 26. 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 27. 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 28. 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 29. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 30. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 31. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 32. 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 © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 33. 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!. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 34. 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 © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 35. 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 36. Decoding of content see ITU Rec. X.209 (36) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 37. 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 38. Ab hier nicht mehr drucken (38) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 39. 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 40. 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 41. STRUKTURIERTE TYPEN MSISDN ::= SEQUENCE { ausscheidungsziffer PRINTABLE STRING (quot;+quot;), 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. (41) Die Werte werden nicht als Integerwerte oder printable strings übertragen, sondern als Elemente des IA5 - Alphabets. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik