Grundlagen der Kommunikationstechnik (3) OSI-Sichtwin/vorlesungen/GrundlagenKT-OSI-Sicht.… · OSI - Open Systems Interconnection Ziel und Inhalt der Vorlesung Prof. Dr.-Ing. habil

2013-08 Kurzfassung

Grundlagen der

Kommunikationstechnik

3 OSI-Sicht

© Prof. Dr.-Ing. habil. Lutz Winkler

Fakultät Elektro- und Informationstechnik

https://www.telecom.hs-mittweida.de

[email protected]

GRKT

1 ÜberSicht

GRKT

1 ÜberSicht

GRKT

2 SystemSicht

GRKT

2 SystemSicht

GRKT

3 OSI-Sicht

GRKT

3 OSI-Sicht

GRKT

4 SignalSicht

GRKT

4 SignalSicht

OSI - Open Systems Interconnection

Ziel und Inhalt der Vorlesung

2 Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de

Ziel

Kennen lernen von OSI-Grundbegriffen und Modellierungsmethoden. Übersicht

über OSI-Schicht-Dienste und Protokolle.

Kennen lernen von Beschreibungsmitteln im Protokollumfeld.

Inhalt Historie und OSI-Standardisierung ……………………...……….... 3

Übersicht: OSI-Modell, Internet-Modell ……….....………………… 7

Protokollstapelbeispiele …………………..………………...………. 11

Beschreibungsmittel im Protokoll-Umfeld ……….………………… 16

X.200: OSI-Abgrenzung, Schichtung …………….………………… 28

X.200: Identifiers, Kommunikation zwischen Entities ……….…… 35

X.210: OSI-Dienstmodell, Primitives …………………………..…... 53

Zusammenhang Dienst, Primitiv, Protokoll …………….....………. 59

Zustandsdiagramme ……………………………...……….....………. 66

Hinweise zu Sockets, WireShark …………………………………… 69

Literatur ……………..…………………………………………………. 71

Anhang: Komplexbeispiel – ISDN ………………………………… 72


Historie


Situation: Viele TK-Systeme waren geschlossene Systeme.

Endgeräte, Netze, Anwendungen des Herstellers A

Endgeräte, Netze, Anwendungen des Herstellers B

Durch die Entwicklung der Computertechnik verschärfte sich

dieser Konflikt.

1978 wurden von der ISO (International Organization for Standardization) erstmals Standards für die Gestaltung „Offener Systeme“ herausgegeben:


Die ITU übernahm diese Standards und unterstütze deren Weiterentwicklung und Anwendung.

inkompatibel

http://www.itu.int/home/index.html


http://www.iso.org/


Historie


OSI-Ziel war es:

Begriffe, Methoden, Verfahren zu standardisieren,

um Interoperabilität zwischen Endsystemen und Anwendungen

verschiedener Hersteller, unabhängig von deren Hardware- und

Betriebssystemplattform, zu sichern.

Heute gibt es kaum verteilten Anwendungen, die einen vollständigen OSI-

Kommunikationsstapel nutzen. Die OSI-Schichtdienste, vor allem in den

höheren Schichten, sind zu komplex und damit auch deren Protokolle.

Aber, alle neuen Kommunikationsstapel wurden und werden OSI-basiert entwickelt, beispielsweise: – GSM (Global System for Mobile communication, standardisiert durch ETSI)

– LAN (IEEE 802.3,4,5,11,15, standardisiert durch IEEE)

– VoIP (standardisiert durch IETF)

– UMTS, LTE (standardisiert durch 3GPP)


OSI-Standardisierung bei ISO und ITU


Allgemeine Standards: Modelle, Begriffe, Methoden (X.200/ISO 7498, X.210, ISO 8509, …)

Schichtstandards: für Dienste und Protokolle (X.211-X.219, X.222-X.229, X.233-X237)

Ergänzende Standards: – Sicherheitsaspekte – Benennung und Adressierung – Schichtung in der Anwendung (X.207, ISO 9545 Application Layer Structure), – Transfersyntax (ASN.1: X.208, ISO 8824, X.209, ISO 8825),

Anwendung Anwendung

1 Physical

2 Data Link

3 Network

4 Transport

5 Session

6 Presentation

7 Application

Physical medium

Allg

em

ein

e S

tan

dard

s:

X.2

00

, IS

O 7

49

8

X.2

10

, IS

O 8

509

Service definitions

X.217 bis X.219

X.216, ISO 8822

X.215, ISO 8326

X.214, ISO 8072

X.213, ISO 8348

X.212, ISO 8886

X.211, ISO 10022

Connection mode protocol specifications

X.227 bis X.229

X.226

X.225

X.224

X.223

X.222

- -

-

Connectionless mode protocol specifications

X.237

X.236

X.235

X.234

X.233


OSI-Standardisierung: Beispiele für Standards


ISO7498 Information Processing Systems – Open Systems Interconnection – Basic Reference Model (BRM)

ISO7498-1 Addendum 1 für CLM (connectionless mode)

ISO7498-2 Addendum 2 zu Sicherheitsaspekten

ISO7498-3 Addendum 3 Benennung und Adressierung

ISO7498-4 Addendum 4 zu Schichtenmanagement

http://www.itu.int/itu-t/recommendations/index.aspx?ser=X

X.200 Information Technology – Open Systems Interconnection – Basic Reference Model:

The Basic Model

X.210 Information Technology – Open Systems Interconnection – Basic Reference Model:

Conventions for the Definition of OSI Services

X.211 Information Technology – Open Systems Interconnection - Physical Service Definition

X.212 Information Technology – Open Systems Interconnection - Data Link Service Definition

X.213 Information Technology – Open Systems Interconnection - Network Service Definition

…

X.222 Use of X.25 LAPB-compatible Data Link procedures to provide the OSI connection-mode Data Link service

X.223 Use of X.25 to provide the OSI connection-mode Network service for ITU-T applications

X.233 Information technology – Protocol for providing the connectionless-mode network service: Protocol specification

…







Übersicht: OSI-Modell


OSI standardisiert einen intelligenten Postboten, der verteilten Anwendungen

Kommunikation ermöglicht.

Das Modell basiert auf einer Schichtenhierarchie.

Jede Schicht realisiert festgelegte Schicht-Dienste.

Die Dienste einer Schicht werden realisiert durch Protokolle.

Netz (xPAN, xLAN, xWAN) Netz (xPAN, xLAN, xWAN)

Client-Anwendungs-

Prozess

Client-Anwendungs-

Prozess

Reales Systen Verteilte Anwendungen müssen kommunizieren,

z.B. ein Web-Client mit dem Webserver.

Data Link Data Link

Network Network

Physical Physical

Transport Layer Transport Layer

Data Link Layer Data Link Layer

Network Layer Network Layer

Physical Layer Physical Layer

Physical Medium

Transport-Schicht Transport-Schicht

Verbindungs-Schicht Verbindungs-Schicht

Netzwerk-Schicht Netzwerk-Schicht

Bitübertragungs-Schicht Bitübertragungs-Schicht

Data Link Data Link

Network Network

Physical Physical

Physical Medium

OSI-

Anwendungs-

Schichtdienste

OSI-Netz-

Schichtdienste

Session Layer Session Layer

Presentation Layer Presentation Layer

Application Layer Application Layer

Sitzungs-Schicht Sitzungs-Schicht

Darstellungs-Schicht Darstellungs-Schicht

Anwendung-Schicht Anwendung-Schicht

Server-Anwendungs-

Prozess

Server-Anwendungs-

Prozess

Routing Routing


Übersicht: OSI-Modell


Verteilte Anwendung Schicht-Dienste Protokollbeispiele

7 Application Anwendung

Stellt Kommunikationsdienste (assoziieren,

anfordern, liefern) für verteilten Anwendungen

bereit. Diese werden modelliert durch:

• CASE (Common Application Service Elements)

• SASE (Specific Application Service Elements)

CASE:

ACSE , Association Control SE

ROSE , Remote Operation SE, ….

SASE:

X.419, Message Handling System, Protocol

Specification, und weitere

6 Presentation Darstellung

Stellt Dienste zur Umsetzung einer lokaler Syntax

in eine Übertragungssyntax bereit oder legt eine

fixe Anwendungs- und Transportsyntax fest

X.226, Connection-oriented Presentation Protocol

X.236, Connectionless Presentation Protocol

X.680 , Abstract Syntax Notation One, Basic Notation,

XML, …

5 Session Sitzung

Stellt Dienste zur Steuerung des Kommunika-

tionsablaufes bereit. Wer beginnt? Merken des

Ablaufs und Wiederaufsetzen im Fehlerfall. …

X.225, Connection-oriented Session Protocol

X.235, Connectionless Session Protocol

…

4 Transport Ende-zu-Ende-Transport

Stellt Dienste für die Ende-zu-Ende-

Datenübertragung bereit

X.224, Connection-oriented Transport Protocol

X.235, Connectionless Transport Protocol

3 Network Netzwerk

Stellt Dienste zur WAN-, GAN-Kommunikation

bereit

Adressierungsmittel,

paket- oder kanalvermittelte Übertragungsdienste

X.223, Connection-oriented Network Protocol

X.233, Connectionless Network Protocol

Q.931, ISDN-Protokoll für kanalvermittelte Dienste

E.163/164 Adressierung in Fernsprech- u. Funknetzen

2 Data Link Daten-Verbindungsabschnitt

auch Datensicherung

Stellt Dienste zur PAN-, LAN-Kommunikation bereit

(Adressierungsmittel, Medienzugriff,

Datensicherung)

X.222,

Q.921

MAC, PPP, PPPoE,

1 Physical Bitübertragung

Stellt Dienste zur Datenübertragung über ein

physikalisches Medium bereit

802.3/4/5/11 …

ISDN-S0, DSL


Übersicht: Internet-Modell


Der Internetstapel ist einfacher.

Die Dienste der Schichten 5 und 6 sind nicht vorhanden oder minimal. L5-L6-

Funktionalität wird durch die Anwendungsprotokolle mit realisiert.

Netzwerk (LAN, WAN) Netzwerk (LAN, WAN)

Client-Anwendungs-

Prozess

Client-Anwendungs-

Prozess

Reales Systen Verteilte Anwendungen müssen kommunizieren,

z.B. ein Web-Client mit dem Webserver.

Data Link Data Link

Network Network

Physical Physical

Transport Transport

Data Link Data Link

Network Network

Physical Physical

Physical Medium

Transport Transport

Netzwerk Netzwerk

Data Link Data Link

Network Network

Physical Physical

Physical Medium

IETF-

Anwendungs-

Dienste

IETF-

Transportdienste

Application,

Presentation,

Session

Application,

Presentation,

Session

Anwendung,

Darstellung,

Sitzung

Anwendung,

Darstellung,

Sitzung

Daten-Verbindungs- Abschnitt Daten-Verbindungs- Abschnitt

Bitübertragung Bitübertragung

Server-Anwendungs-

Prozess

Server-Anwendungs-

Prozess

Routing Routing


Übersicht: Internet-Modell


Verteilte Anwendung Schicht-Dienste Protokollbeispiele

7 Applikation Anwendung

Stellt Kommunikationsdienste (assoziieren,

anfordern, liefern) für verteilten Anwendungen

bereit.

HTTP für den Dienst WWW

SMTP, POP, IMAP für den Dienst E-Mail:

SIP+SDP, RTP für den Dienst VoIP:

…

7 Presentation Darstellung

Dienste sind nicht oder nur rudimentär vorhanden.

Man legt eine fixe Anwendungs- und

Transportsyntax fest. Damit entfällt die sehr

aufwändige Syntaxumsetzung zur Laufzeit.

Beispielsweise wurden festgelegt:

E-Mail: ASCII, bzw. ASCII-kompatible Kodierungen

(quotet printable, base 64).

WWW: ASCII ISO-8859-x UTF-8

…

7 Session Sitzung

Stellt Dienste zur Steuerung des Kommunika-

tionsablaufes bereit. Verwalten einer Assoziation.

Merken des Ablaufs und Wiederaufsetzen im

Fehlerfall.

HTTP-Header "Connect:keep-alive" für temporäre

Session.

HTTP-Header "Set-Cookie" und "Cookie"

4 Transport Ende-zu-Ende-Transport

Stellt Dienste für die quittierte und unquittierte

Ende-zu-Ende-Datenübertragung bereit.

TCP, Transmission Control Protocol

UDP, User Datagram Protocol

3 Network Netzwerk

Stellt Dienste zur WAN-, GAN-Kommunikation

bereit:

Adressierungsmittel und einen verbindungslosen

paketvermittelten Übertragungsdienst

IP4/IP6-Adressen

IP, Internet Protocol

2 Data Link Daten-Verbindungsabschnitt

auch Datensicherung

Stellt Dienste zur PAN-, LAN-Kommunikation bereit

Adressierungsmittel,

Medienzugriff (eventuell multiple)

Manchmal auch Datensicherung

MAC-Adresse

MAC, Media Access Control

PPP, Point-to-Point Protocol

PPPoE, PPP over Ethernet

1 Physical Bitübertragung

Stellt Dienste zur Datenübertragung über ein

physikalisches Medium bereit

802.3/4/5/11 …

ISDN-S0, DSL-Modem, a/b-Modem, CATV-Modem


Protokollstapelbeispiel: Internet-Anwendungen


Host's

TCP (UDP) RFC 793

TCP (UDP) RFC 793

IP RFC 791

IP RFC 791

LAN

Bridge

Ph IEEE 802.3

Ph IEEE 802.3

MAC IEEE 802.3

MAC IEEE 802.3

IP RFC 791

IP RFC 791

Access Point

WLAN

Ph IEEE 802.11

Ph IEEE 802.11

WMAC IEEE 802.11

WMAC IEEE 802.11

TCP (UDP) RFC 793

IP RFC 791

IP RFC 791

DSLAM

ADSL

Ph ITU-T G.992.1/3/5

Ph ITU-T G.992.1/3/5

PPPoE RFC 2516 PPPoE RFC 2516

TCP (UDP) RFC 793

IP RFC 791

IP RFC 791

CMTS

Cable

Ph DOCSYS 3.0, ITU-T J.222

Ph DOCSYS 3.0, ITU-T J.222

LLC IEEE 802.2

LLC IEEE 802.2

TCP (UDP) RFC 793 internet-

einheitlicher Transport

netzwerk-abhängig

WWW

HTTP HTTP

FTP

FTP FTP

E-Mail

SMTP, POP SMTP, POP

VoIP

SIP/SDP, RTP SIP/SDP, RTP

Anwendungen

Anwendungs-protokolle


Protokollstapel-Beispiel: Telefonie im ISDN (cs)


Aufbau einer Nutzkanalverbindung mit den Protokollmitteln der Schicht 3. In den Netzknoten werden die Nutzkanäle auf Schicht-1-Niveau durchgeschaltet.

Nutzung des permanent verfügbaren Kanals.

Abbau mit den Protokollmitteln der Schicht 3.

Switch

Q.921

Q.931

B1

B1

B2

B2

Q.921

Q.931

Q.921

Q.931

B1

B1

B2

B2

Call Control Call Control

Q.921

Q.931

B1, B2 B1, B2

Applikation

Verbindungs-

auf- und -

abbau

Nutzung von

B1, B2

ISDN-

Satz

S0 NTBA

Cu-DA: IDSL (Uk0)

S0 NTBA

Cu-DA: IDSL (Uk0)

S0

Tastatur

Gabel

Anzeige

CCA

Tastatur

Gabel

Anzeige

CCA

Pro

toko

llsta

ck

Applikation

Verbindungs-

auf- und -

abbau

Nutzung von

B1, B2

Pro

toko

llsta

ck

Mikro/Hörer

Filter

Codec

Mikro/Hörer

Filter

Codec

Tastatur

Gabel

Anzeige

CCA

Tastatur

Gabel

Anzeige

CCA

Mikro/Hörer

Filter

Codec

Mikro/Hörer

Filter

Codec

1

2

3

Koppelnetz

I.430 Uk0 Uk0 I.430

Verbindungs-

auf- und -

abbau

Verbindungs-

auf- und -

abbau

Schalten von

B1, B2


LAN

Protokollstapelbeispiel: Filetransfer im Internet


Socket-API Socket-API

Client Server

Router

z.B. Ethernet-Karte

FTP

(1) Socket errichten

(2) assoziieren (3) Socket

nutzen

FTP FTP FTP

FTP FTP

Server: Socket errichten, warten und ankommende Verbindungen annehmen.

Client: Socket errichten, mit Serveradresse+Port adressieren.

Assoziation herstellen.

FTP-Anwendungs-Instanzen nutzen Socket zum Senden und Empfangen.

L3-Routing

MAC

IP

TCP

MAC

IP

TCP

MAC

IP

MAC

IP

Paket-Routing

LAN

z.B. Ethernet-Karte

(1) Socket errichten

(2) auf Assoziationen warten und akzeptieren

(3) Socket nutzen

LAN LAN


Protokollstapelbeispiel: WWW über PSTN und Internet


Voraussetzung:

Endgerät stellt cs-Verbindung zu einem Dial-Up-Server her. Über diesen Kanal werden IP-Pakete mittels PPP zum Dial-Up-Server übertragen

Rest wie Folie vorher

Fernsprechnetz

Socket-API Socket-API

Client Server

Dial-Up-Server

Fernsprechnetz

z.B. Ethernet-

Karte Modem oder

ISDN-Karte

L3-Routing

MAC

IP

TCP

PPP, SLIP

IP

TCP

MAC

IP

PPP, SLIP

IP

Paket-Routing

Internet

Internetz

WWW

(1) Socket errichten und adressieren

(2) assoziieren (3) Socket

nutzen

HTTP HTTP WWW

HTTP HTTP

(1) Socket errichten und adressieren

(2) auf Assoziationen warten und akzeptieren

(3) Socket nutzen


Protokollstapelbeispiel: Videotelefonie im B-ISDN (cell-relay)


Mittels der L3-Adresse werden die L2-Abschnitte ermittelt und in den Netzknoten die Kanalnummern gespeichert.

Die logische Kanalnummern in jeder ATM-Zelle sind Basis für das Routing.

53-Byte-Zellen

Kanal- nummern 48-Byte-Payload

ATM-Switch

LLC

Q.9031

LLC

Q.9031 Q.9031

Call Control

LLC

Q.9031

Applikation

Verbindungs-

auf- und -abbau

Satz Satz Karte

NTBBA z.B. Cu-DA: xDSL

NTBBA

Tastatur

Gabel

Anzeige

CCA

Karte

Applikation

Verbindungs-

auf- und -abbau

Mikro/Hörer

Kamera/Diplay

Filter

Codecs

Bedien-

ober-

fläche

CCA

1

2

3

Mikro/Hörer

Kamera/Diplay

Filter

Codecs

LLC Logische Kanäle

Video

Logische Kanäle

Audio Audio Video

1 1 1 1

Cell-Routing-Table

… kontinuierlicher Zellenstrom mit Leer-, Signalgabe- oder Nutzzellen

kontinuierlicher Zellenstrom mit Leer-, Signalgabe- oder Nutzzellen


Beschreibungsmittel im Protokollumfeld


Für die Spezifikation, die Beschreibung und den Test von Protokollen sind

formale Beschreibungsmittel erforderlich.

Genutzt werden:

– Formale Grammatiken zur Definition von Nachrichten (messages), die zwischen

peer-entities oder adjacent-entities ausgetauscht werden.

– Endliche Automaten zur Beschreibung der Zustände, die entities in CM-

Beziehungen einnehmen können

– MSC (message sequence chart) zur exemplarischen Verhaltensbeschreibung oder

zur Beschreibung von Testabläufen

– UML (Unified Modeling Language) zur Verhaltensbeschreibung:

• Zustandsdiagramm Automat

• Sequenzdiagramm ähnlich MSC


Beschreibungsmittel: Formale Grammatik


Grammatik: G=G(T,N,R,S) T, endliche Menge terminaler (endgültiger) Grundsymbole, die in G möglich sind:

– Für T gibt es keine Produktionsregeln

– T in Form von Literalen (feststehende Werte) werden besonders gekennzeichnet

N, Menge nichtterminaler Symbole

S, Startsymbol wobei gilt S ∈ N

R, Menge von Ableitungsregeln (Produktionsregeln) dargestellt in BNF|EBNF|ABNF

N ⋃ T ist das Vokabular der Grammatik

Metasymbole u. Notation BNF EBNF ISO 14977 ABNF RFC 5234

Definitionszeichen ::= = =

Entweder-oder-Symbol | | | oder /

Ende einer Regel ;

Kommentar (*kommentar*) ;kommentar

Wiederholung: 0- oder mehrmals {ausdruck}* * ausdruck

Wiederholung: 1- oder mehrmals {ausdruck }+ 1* ausdruck

Wiederholung: mindestens n, maximal m n*m ausdruck

Optionaler Ausdruck [ausdruck] [ausdruck]

Notation von Terminalen anders anders anders

Notation von Literalen " " " "|' ' " "

Notation von Nichtterminalen <name> <name> name

ABNF-Beispiele: http://www.tech-invite.com/Ti-abnf.html

http://tools.ietf.org/html/rfc5234

http://www.tech-invite.com/Ti-abnf.html








Beispiel einer exakten EBNF-Grammatik Terminale durch Fettschreibung gekennzeichnet

In der ITU-Programmiersprache CHILL gilt: einfache Bezeichner müssen mit einem Buchstaben beginnen. Danach

können weitere Buchstaben, Ziffern oder der Unterstrich kommen. /ITU-Z.200, S.7/

(1) Mengenangaben für T, N und Startsymbol aus N benennen:

T={A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z|

a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z|

0|1|2|3|4|5|6|7|8|9|_}

N={<digit>,<letter>,<underline>,<simple name string>}

S=<simple name string>

(2) Produktionsregeln R in EBNF:

<digit> = 0|1|2|3|4|5|6|7|8|9 ;

<letter> = A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z|

a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z| ;

<underline> =_ ;

<simple name string> = <letter> {<letter>|<digit>|<underline>}*;

(3) Semantik beschreiben The underline character (_) forms part of the simple name string; e.g. the simple name string life_time is different from the simple name

string lifetime. Lower case and upper case letters are different, e.g. Status and status are two different simple name strings.

The language has a number of special simple name strings with predetermined meanings (see Appendix III). Some of them are reserved,

i.e. they cannot be used for other purposes.

The special simple name strings in a piece must either all be in upper case representation or all be in lower case representation. The

reserved simple name strings are only reserved in the chosen representation (e.g. if the lower case fashion is chosen, row is reserved,

ROW is not).

static conditions: A simple name string may not be one of the reserved simple name strings (see Appendix III.1).




In einer realen Grammatikbeschreibung wird, um den Notationsaufwand zu minimieren, auf

Schritt (1) verzichtet. Man beginnt mit (2), den Regeln.

Die Mengen T und N sind dann die Symbole, die in den Regeln vorkommen.

Das Startsymbol ergibt sich aus dem Kontext.

Wie würde eine solche Beschreibung aussehen? Terminale durch Fettschreibung gekennzeichnet

(2) Produktionsregeln R in EBNF:

<simple name string> = <letter> {<letter>|<digit>|<underline>}*;

<digit> = 0|1|2|3|4|5|6|7|8|9 ;

<letter> = A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z|

a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z| ;

<underline> = _ ;

(3) Semantik beschreiben …




Beispiel: Grammatik einer ganzen Zahl in BNF Terminale durch Fettschreibung gekennzeichnet

(1) Mengenangaben für T, N und Startsymbol aus N benennen:

T={0|1|2|3|4|5|6|7|8|9|+|-}

N={<vorzeichen>,<zahl>,<ziffernfolge>}

S=<zahl>

<ziffer> = 0|1|2|3|4|5|6|7|8|9

<vorzeichen> = +|-

<ziffernfolge> = <ziffer><ziffernfolge>|<ziffer>

<zahl> = <vorzeichen> <ziffernfolge> | ziffernfolge

Beispiel: Grammatik einer ganzen Zahl in EBNF Terminale durch " " gekennzeichnet

<zahl> = [("+"|"-")] {<ziffer>}+;

<ziffer> = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9";




Beispiel: Grammatik einer HTTP-message in ABNF aus RFC1945

HTTP-message = Simple-Request ; HTTP/0.9 messages

| Simple-Response

| Full-Request ; HTTP/1.0 messages

| Full-Response

Full-Request = Request-Line ; Section 5.1

*( General-Header ; Section 4.3

| Request-Header ; Section 5.2

| Entity-Header ) ; Section 7.1

CRLF

[ Entity-Body ] ; Section 7.2

Full-Response = Status-Line ; Section 6.1

*( General-Header ; Section 4.3

| Response-Header ; Section 6.2

| Entity-Header ) ; Section 7.1

CRLF

[ Entity-Body ] ; Section 7.2

Simple-Request = "GET" SP Request-URI CRLF

Simple-Response = [ Entity-Body ]


Beschreibungsmittel: Syntaxdiagramm


Syntaxdiagramme sind bildhafte Darstellungen von Grammatiken und

bestehen aus:

Name der Regel name:

Startknoten der Regel Pfeil in das Diagramm

Zielknoten der Regel Pfeil aus dem Diagramm

Terminale verbunden durch gerichtete Kanten

Nonterminale

Beispiel "ganze Zahl" (siehe Folie 25)

zahl: vorzeichen ziffer ziffer

vorzeichen: -

ziffer: 0

1

9


Beschreibungsmittel: Syntaxdiagramm


Erstellen Sie das Syntaxdiagramm für die Grammatik eines "simple name

string", siehe Folie 18

underline: _

letter: a

b

z

simple name string:

letter

digit

underline

A

B

Z

letter

0

1

9

ziffer:


Beschreibungsmittel: Endliche Automaten (finite state machine, FSM)


A =A(X, Y, Z, δ, λ)

Zn+1=δ(Xn,Zn)

Yn =λ(Xn,Zn)

A =A(X, Y, Z, δ, λ)

Zn+1=δ(Xn,Zn)

Yn =λ(Xn,Zn)

A =A(X, Y, Z, δ, μ)

Zn+1=δ(Xn,Zn)

Yn =μ(Zn)

A =A(X, Y, Z, δ, μ)

Zn+1=δ(Xn,Zn)

Yn =μ(Zn)

Struktur Mealy-Automat Moore-Automat

Logische Zuordner δ, λ | μ

Logische Zuordner δ, λ | μ

Zustands-Speicher Zustands-Speicher

Xn Yn

Zn

Zn+1

Takt

Alternate Mark Inversion Coder

(AMI-coder)

{0,1} {+,-,Ø}

1

0

+

Ø

-

Beispiel Z0 Z0

Z1

0/Ø

0/Ø

1/+ 1/-

Z0/- Z0/-

Z2/+

0

1 1

Z1/Ø

0

1

Z3/Ø

1

0

0

Xn/Zn Z0 Z1

0 Z0 Z1

1 Z1 Z0

Xn/Zn Z0 Z1

0 Ø Ø

1 + -

Xn/Zn Z0 Z1 Z2 Z3

0 Z1 Z1 Z3 Z3

1 Z2 Z2 Z0 Z0

μ - Ø + Ø

δ-Tabelle λ-Tabelle δ/μ-Tabelle


Beschreibungsmittel: Erweiterte endliche Automaten (extendet FSM, EFSM)


Ein Automat ist eine Schaltung mit Gedächtnis, gespeichert in den Zuständen.

FSMs haben Abbildungsnachteile bei der Kommunikation zwischen Prozessen, bei Wiederholungen usw.

Deshalb wurden EFSMs eingeführt. Eine bedeutende Sprache ist SDL (specification and description language) /ITU-Z.100/.

Wichtige SDL-Sprachelemente zur Verhaltensbeschreibung sind:

SDL-Symbol

Zustand Warten auf Input

Input Relevanter Input leitet Zustandsübergang ein

Output Im Zustandsübergang kann Output erfolgen

Task Operationen auf Daten ausführen

Decision Vergleichsoperationen auf Daten u. Entscheidungen

Text In diesem Textsymbol kann man Operationsda-ten deklarieren. Z.B. DCL xyz integer;

Z0

1 0

- Ø

Z1 Z0

Z1

1 0

+ Ø

Z0 Z1

SDL-Darstellung des AMI-Coders


Eine HDLC-basierte L2-Instanz muss Daten der L3 an seine DL-peer-entity mod8-nummeriert

versenden. L3 übergibt L2 die Daten D mittels DL-DATA.Rq. DL-entity sendet die Daten

mittels der Protokoll-Message I(Ns= x, D). Beschreiben Sie mittels Mealy-Automat und SDL!

Beschreibungsmittel: Beispiel


Z0 Z0

Z1

DL-DATA.Rq(D)/I(Ns=0,D)

Z2


Z3


Mealy-Automat

Z7

Z6


Z5


Z4



DL-DATA.Rq(D)/I(Ns=7,D) Initialzustand

Z0

DL-DATA.Rq(D)

DCL z int;

I(Ns=z,D)

z:=z+1;

z >=7 else

Z0

z:=0;

Z0

SDL-Automat


Beschreibungsmittel: Message Sequence Chart /ITU-T Z.120/


MSC dient zur exemplarischen Verhaltensbeschreibung oder zur Beschreibung von

Testabläufen. Es werden nur Verhaltensausschnitte gezeigt.

Das Beispiel zeigt das Prinzip Der Name der MSC ist SimpleMSC In einem Textsymbol steht ein

Kommentar Wir sehen 4 Instanzen, deren

Betrachtungsdauer durch Instanzstart, Instanzstop bestimmt ist.

Bedingungen können Zustände oder andere Voraussetzungen modellieren.

Messages zeigen die Kommunikation zwischen Instanzen (vertikal, horizontal). Oben stehen Primitives bzw PDUs, unten die Parameter.

Timer Start , Timer Reset, Timeout modellieren Zeitbedingen

Aktionssymbol, ist ein Viereck, im Beispiel nicht enthalten


OSI – Abgrenzung /ITU-T X.200 (4)/


RSE Real System

Environment

OSIE Open Systems

Interconnection

Environment

Real Open System

Open Systems Interconnection

Network Environment

Data Link Data Link

Network Network

Physical Physical

Session Session

Presentation Presentation

Transport Transport

Data Link Data Link

Network Network

Physical Physical

Application Application

Physical Medium

Session Session

Presentation Presentation

Transport Transport

Data Link Data Link

Network Network

Physical Physical


Data Link Data Link

Network Network

Physical Physical

Physical Medium

R o u t i n g R o u t i n g

Real System

Network

Application Process

Application Process

Application Process

Application Process


Anwendung Anwendung

Schichtung: Notation /ITU-T X.200 (3)/


Um Beziehungen und Eigenschaften von Schichten allgemein beschreiben

zu können, wird folgendes festgelegt: – (N)-layer: ist die momentan betrachtete Schicht, – (N+1)-layer: ist die nächst höhere Schicht, – (N-1)-layer: ist die nächst niedere Schicht.

1 Physical

2 Data Link

3 Network

4 Transport

5 Session

6 Presentation

7 Application

Physical medium

(N)-layer

(N+1)-layer

(N-1)-layer

N-layer

(N)-layer

(N+1)-layer

(N-1)-layer

Diese Präfixe werden auch für andere Konzepte verwendet, z.B.: (N)-service,

(N+1)-entity,

(N-1)-protocol usw.

Beachte: N-layer ≠ (N)-layer N-layer bezeichnet die Schicht 3 (network)

(N)-layer bezeichnet eine beliebige Schicht zwischen 1 und 7.

Beachte: Schicht 7 hat kein (N+1)-layer, Schicht 1 kein (N-1)-layer.


Schichtung: Begriffe /ITU-T X.200 (5.2)/


Ein Basiskonzept des OSIRM ist die Schichtung (layering).

Open Systems bestehen aus geschichteten Subsystems.

(N)-Subsystems der gleichen Hierarchie (rank (N)) bilden die (N)-layer.

Vertikale Beziehungen zwischen Schichten werden durch (N+1)-(N)-(N-1)-

Relationen beschrieben.

(N-1)-subsystem

Lowest subsystem

Physical Medium

Lowest subsystem

(N-1)-subsystem

Lowest subsystem

(N-1)-subsystem

boundary

Highest subsystem

(N+1)-subsystem

Open Sytem A Open Sytem B Open Sytem Z

(N)-layer

Highest subsystem

(N+1)-subsystem

(N)-subsystem

Highest subsystem

(N+1)-subsystem

(N)-subsystem (N)-subsystem


The principles used to determine the seven layers in the RM /ITU-T X.200 (6.2)/


1. Schaffe nicht mehr Schichten, als unbedingt notwendig.

2. Lege zwischen den Schichten Grenzen so fest, das die Dienstbeschreibung an diesem Punkt minimal ist und damit auch die Interaktionen benachbarter Instanzen.

3. Bilde separate Schichten für wesensverschiedene Funktionen bzw. Technologien.

4. Ordne ähnliche Funktionen der gleichen Schicht zu.

5. Wähle solche Schichtgrenzen, die sich in der Vergangenheit als zweckmäßig erwiesen.

6. Bilde Schichten so, damit diese einfach redesigned bzw. geändert werden können ohne das sich die Dienste dieser Schicht ändern.

7. Bilde dort eine Grenze, wo es zweckmäßig sein kann ein Interface zu standardisieren.

8. Bilde dort eine Schicht, wo verschiedene Abstraktionsgrade in der Datenbehandlung erforderlich sind, z.B. syntaktische oder semantische Aspekte.

9. Erlaube die Änderung von Funktionen oder Protokollen innerhalb einer Schicht, ohne daß benachbarte Schichten davon betroffen werden.

10. Schaffe für jede Schicht nur Grenzen zur darüber und darunter liegenden Schicht.

Prinzipen für Subschichtung:

11. Erzeuge dort Subschichten innerhalb einer Schicht, wo deutlich verschiedene Kommunikationsdienste erforderlich sind

12. Erlaube die Umgehung von Subschichten.




Sind die Dienste einer Schicht sehr komplex, können innerhalb einer

Schicht Sublayers gebildet werden. (N)-Layer

(N)-Sublayer X

(N)-Sublayer Y

(N)-Sublayer Z

Physical

Data Link

PLCP-Sublayer

MAC-Sublayer

PMD-Sublayer

PMD-SAP

PHY-SAP

Air 1 Air 2 Air n

Logical Link Control

MAC-SAP

DL-SAP

Davon wird oft Gebrauch gemacht.

Beispiel: Schichtung beim IEEE-

802.11-WLAN-Standard.




Jede (N)-layer (außer L7) liefert (N+1)-entities einen (N)-service über (N)-SAPs.

(N)-services bestehen aus (N)-facilities und werden durch eine oder mehrere

(N)-entities erbracht.

(N)-entities kooperieren vermittels (N)-protocols.

(N)-entity

(N+1)-entitity ::= (N+1)-function1, ...

(N+1)-entitity ::= (N+1)-function1, ...

(N)-entity ::= (N)-function1, ...


(N)-SAP

(N+1)-SAP

(N-1)-SAP

(N)-SAP

(N+1)-SAP

(N-1)-SAP

(N+1)-protocol

(N)-protocol

(N-1)-protocol

(N+1)-Services ::= (N+1)-Facility1, (N+1)-Facility2, ...

(N)-Services ::= (N)-Facility1, (N)-Facility2, ...

(N-1)-Services ::= (N-1)-Facility1, (N-1)-Facility2, ...

(N-1)-Entitity ::= (N-1)-function1, ...


(N+1)-Eentitity ::= (N+1)-function1, ...

(N+1)-Eentitity ::= (N+1)-function1, ...



(N)-entity (N)-entity ::= (N)-function1, ...


Open Sytem A Open Sytem B

(N)

(N+1)

(N-1)


Schichtung: Eigenschaften von SAPs /ITU-T X.200 (5.5)/


SAP‘s sind virtuelle Dienstzugangspunkte zwischen Entities, ähnlich einem Schalter bei Behörden, Banken usw.

Die vertikale Kommunikation zwischen Entities über SAP‘s ist nicht standardisiert. Für die Beziehung von (N+1)-entities mit (N)-entities gilt: – sie kommunizieren über genau einen SAP,

– SAP‘s haben keine Funktionalität, sie können Primitives nicht „verteilen“.

(N+1)-Layer

(N)-Layer

(N+1)-Entities

(N)-Entities

(N)-SAP‘s

mögliche Beziehungen

zwischen (N+1) und (N)-Instanzen

unzulässige Beziehungen

zwischen (N+1) und (N)-Instanzen


Identifiers /ITU-T X.200 (5.4)/


(N+1)-entity

(N)-entity

(N)-entity

(N)-service-access-point

(N)-connection-endpoint-identifier

(N)-address

Nach Figure 7: Enties, service-access-points and identifiers /ITU-X.200/

Im Folgenden wird dieses SAP-Symbol verwendet

(N)-entity-title

Ein konkretes Beispiel, anhand des ISDN-L2-D-Kanal-Protokolls finden Sie in Anhang B


Kommunikation: Vertikal zwischen Entities /X.200 (5.3)/


Associations zwischen (N+1)-entities werden durch ein (N)-protocol einer

(N)-layer realisiert.

Eine (N)-entity kann ein oder mehrere grundlegende Protokolle unterstützen:

connection-mode | connectionless-mode | beide:

– connection-mode-(N)-entities stellen eine (N)-connection für (N+1)-entities über

entsprechende (N)-SAPs bereit Verbindung.

– connectionless-mode-(N)-entities, stellen eine Bindung zwischen (N+1)-entities

mittels verbindungsloser Datenübertragung her Beziehung.

(N+1)-Layer

(N)-Layer

(N+1)-Entities

Connection-mode: Kommunikation vermittels einer

Verbindung (1)Aufbau (2)Datenübertragung

(3)Abbau

Connectionless-mode: Kommunikation vermittels einer

Beziehung (1) Datenübertragung

association association


Kommunikation: vertikal zwischen Entities /X.200 (5.3)/


Kommunikation nicht kompatibler (N+1)-Instanzen, kann über relay-(N+1)-entities

ermöglicht werden.

(N+1)-layer

(N)-layer

(N+1)-Entities

BEISPIEL: Relaying im NTBA:

Physical

ISDN-S0

Physical Medium

ISDN-Uk0 ISDN-S0 ISDN-Uk0

4-Draht-Leitung 2-Draht-Leitung

Ph-SAP Ph-SAP

R e l a y

relay-(N+1)-entity


Kommunikation: vertikale u. horizontale K. /ITU-T X.200 (5.6)/


Bei diesen Betrachtungen sind zu unterscheiden (1) vertikale Kommunikation zwischen (N+1)-(N)- bzw. (N)-(N-1)-Entities (Adjacent Entities) :

nichtstandardisierte Diensterbringung standardisierter Dienste, gesteuert über Primitives.

(2) horizontale Kommunikation zwischen paaren Instanzen (Peer Entities):

standardisierte Dienstrealisierung durch Protokolle.

(N+1)-Layer

(N+1)-Entity

(N)-Layer

(N)-Entity

(N)-SAP

(N+1)-Entity

(N)-Entity

(N)-SAP

(1)

(2)

(N)-Diensterealisierung

(N)-Dienst-

erbringung

Peer-Entities

Adjacent

Entities

(N)-protocol

(N)-Dienst-

erbringung

primitives primitives


Kommunikation: Datenaustausch, -formate zwischen Entities


Entities nutzen bei Kommunikation (vertikal oder horizontal) drei Formattypen: – Steuerinformationen (Control), z.B. Errichtung, Beendigung, Rücksetzen von Verbindungen, …

– Daten (Data), die z.B. gesichert, ungesichert übertragen werden sollen

– Steuerinformationen+Daten (Combined)

Nachfolgende Tabelle zeigt den Zusammenhang:

ICI, ID, IDU sind betriebssystem- und implementationsabhängig und ev. über API ansprechbar, z.B:

– integer API-ENTRY DL-ESTABLISH.Rq(integer CES)

– integer API-ENTRY DL-DATA.Rq(integer CES, pointer SDU)

PCI, UD, PDU sind in den Schichtenprotokollen detailliert (Aufbau und Codierung) festgelegt.

Standardisiert

Nicht standardisiert aber in Literatur

oft verwendet

Control (Steuerung) Data (Daten) Combined (Strg+Daten)

(N+1)-(N)-communication

(N)-ICI (N)-interface control information

(N)-ID (N)-interface data

(N)-IDU (N)-interface data unit

(N)-(N)-communication

(N)-PCI (N)-protocol control information

(N)-UD (N)-user data

(N)-PDU (N)-protocol data unit




(N+1)-Layer

(N-1)-Layer

(N)-Layer

(N)-ICI

(N)-ICI (N)-SDU

(N)-PCI

(N)-PDU

(N-1)-ICI

(N-1)-SDU (N-1)-ICI

(N-1)-PCI

(N-1)-PDU

(N+1)-SDU

(N+1)-PCI

(N+1)-PDU

(N)-ICI (N)-SDU

(N)-PCI

(N)-PDU

(N-1)-ICI

(N-1)-SDU (N-1)-ICI

(N-1)-PCI

(N-1)-PDU

(N)-IDU

(N+1)-SDU

(N+1)-PCI

(N+1)-PDU

(N)-ICI

(N)-IDU

(N-1)-IDU (N-1)-IDU




Session

Presentation

Transport

Data Link

Network

Physical

Application

Physical

Medium

Session

Presentation

Transport

Data Link

Network

Physical

Application

Application Process

Application Process DATA

PCI DATA

PCI ASDU

PPDU

PCI SSDU

PCI TSDU

PCI NSDU

Encoded bit stream

PCI

PCI

DLSDU

PSDU

PCI PCI

Outgoing frame

construction Incoming frame

reduction


PCI - Protocol Control Information


Der PCI-Teil einer PDU enthält Informationen für die paare Instanz.

Umgangssprachlich wird er auch als Header betzeichnet.

Folgende Informationen sind für viele Schichten relevant: – Angaben zur Protokollversion – (N)-Absender- und (N)-Zieladresse – (N)-entity-title worüber eine (N+1)-entity adressiert wird – Typ der PDU

Vom Typ der PDU abhängige Informationen – Längenangabe der PDU – Angaben zur Nummerierung:

• Sendenummer • Quittungsnummer

– Integritätsschutz z.B. in Form von CRC-Zeichen


PCI: Protokollversionen /ITU-T X.200 (5.8)/


In einer (N)-layer können ein oder mehrere (N)-protocols standardisiert sein. Diese werden durch (N)-protocol-identifiers gekennzeichnet.

Eine sinnvolle Kommunikation zwischen (N)-entities ergibt sich aber nur durch eine Apriori-Festlegung eines Protokolls. Ansonsten müsste es wieder ein Protokoll zur Aushandlung eines Protokolls geben.

Protokollversion – Neue Versionen sollten nur eingeführt werden, wenn dadurch eine bedeutende

Funktionsänderung erfolgt.

– Ein (N)-protocol kann mehrere Versionen (z.B. eingeteilt in Version und Subversion) besitzen. Unterschiedliche Versionen werden durch einen (N)-protocol-version-identifier gekennzeichnet.

– Die Aushandlung einer Protokollversion kann nur bei einer connection-mode communication erfolgen und zwar beim Verbindungsaufbau

• die calling-(N)-entity übersendet die von ihr unterstützen Versionen

• die called-(N)-entity vergleicht mit eigenen Möglichkeiten, wählt und quittiert die bestmögliche.

– Bei connectionless-mode-protocols wird entweder die Version a priori festgelegt oder in jeder PDU übertragen.


PCI: Protokollauswahl und Protokollversionen


Beispiel: Protokoll-ID im ISDN-D-Kanal-Protokoll : Jede L3-PDU enthält im ersten Oktett den sogenannten Protokolldiskriminator (PD):

– (0000 1000): Protokoll nach ITU-Q.931

– (0100 0000) bis (0100 0111): für nationale Verwendung usw.

Im Standard heißt es dazu sinngemäß: – Der Empfänger einer PDU erkennt am PD, welches Schicht-3-Protokoll verwendet wird.

– Er verarbeitet nur die PDUs, für die die Instanz konstruiert wurde. PDUs mit einem anderen PD werden verworfen.

Beispiel: Protokoll-Versions-ID für IP:

die ersten 4 Bit jedes Rahmens enthalten die Version – (0100): IP-Version 4

– (0110): IP-Version 6

Beispiel: Protokoll-Versions-ID für HTTP: derzeit gibt es drei Versionen1): 0.9 , 1.0, 1.1, enthalten in jedem Request bzw. Response

– GET /hsm/index.htm CRLF Request in Version 0.9 – GET /hsm/index.htm HTTP/1.0 CRLF Request in Version 1.0 – HTTP 0.9 liefert keinen Response-Header

– HTTP/1.0 404 Not Found CRLF .... Response Version 1.0

1) Ein Webserver unterstützt in der Regel alle drei Versionen. Die Antwort-Version wird aus der Anforderungsversion abgeleitet.


Modes of Communication /X.200 (5.8)/

Dienste (services) Funktion Connection

mode Connection-less mode

Verbindungsaufbau und -abbau

Connection establishment and release x -

Connection suspend and resume x -

Datentransfer

Multiplexing and Splitting x x

Normal data transfer x x

Data transfer during connection establishment and release

x -

Flow control x x

Expedited transfer of data x -

Segmenting, blocking and concatenation x x

Sequencing x x

Fehlerfunktionen

Acknowledgement x x

Error detection and notification x x

Reset x -

Routing x x

Quality of service x x

Funktionen der Kommunikationsmodi CM, CLM.



Connection establishment, release, suspend, resume /X.200 (5.8)/


(N)-connections erfordern Prozeduren zur Errichtung u.Auslösung. Unterscheidung in: – in-band: Verbindungsaufbau u. Datenübertragung nutzen die gleiche (N)-connection

– out-of-band: Verbindungsaufbau und die nachfolgende Datenübertragung finden über verschiedene (N)-connections statt.

Connection (Verbindung herstellen): – Die Errichtung einer (N)-connection erfordern einen (N-1)-service und einen entsprechenden

Betriebszustand der (N)-entities.

– Falls der (N-1)-service nicht permanent zur Verfügung steht, muss er durch die (N)-layer angefordert werden. Dies gilt entsprechend für alle darunter liegenden Schichten.

Release (Auslösen, Beenden):

– Auslösen einer (N)-connection wird durch die assoziierte (N+1)-entity initiiert oder durch eine (N)-entity bei Fehlern in der (N)-layer oder unterlagerter Schichten.

– Durch die Auslösung kann es zu Datenverlust kommen. Auslöseprozeduren sollten so gestaltet werden, damit Datenverlust vermieden wird.

Suspend, Resume:

– Suspend ist eine OSI-Funktion einer (N)-layer, bei der eine (N-1)-connection terminiert wird, die (N)-connection aber beibehalten wird.

– Suspend kann durch eine Anforderung einer (N+1)-entity eingeleitet werden oder automatisch durch die (N)-entity selbst (wenn z.B. lange keine Datenübertragung stattfand).

– Normalbetrieb wird wieder aufgenommen (resumed) durch Wiederherstellung der (N-1)-connection, eingeleitet durch eine der beiden (N)-entities.


Transfer of data /ITU-T X.200 (5.8)/


Normal data transfer:

– Steuerinformationen und Nutzdaten werden zwischen (N)-entities in Form von (N)-PDUs ausgetauscht.

– (N)-PDUs haben eine endliche Größe, limitiert durch die Größe der (N-1)-PDUs und Festlegungen des (N)-protocols.

Data transfer during connection establishment and release:

– (N)-DUs können in der Auf- und Abbauphase einer (N)-connection übertragen werden.

– Der Verbindungsabbau kann mit einem Verbindungsaufbau kombiniert werden, damit eine (N)-DU, übertragen in der Aufbauphase, in der Abbauphase quittiert werden kann.

Expedited transfer of data (z.B. für Signalgabe- oder Interruptzwecke) :

– Eine expedited-SDU wird schneller bearbeitet und übertragen als eine normale SDU.

– Dieser Service wird nur bei connection-mode transmission unterstützt.


Transfer of data


Flow control: – (A) Vertikal zwischen (N+1)- und (N)-entities zur Regulierung der Rate von (N)-SDUs.

Anwendbar bei CM und CLM.

– (B) Horizontal zwischen (N)-entities zur Regulierung der Rate von (N)-PDUs. Nummerierung im (N)-PCI erforderlich und nur möglich bei CM.

Gibt es auch eine Flusssteuerung von (N) zu (N+1)?

(N+1)-Layer

(N)-Layer

(N+1)-Entity

(N)-Entity

(N)-SAP

(N+1)-Entity

(N)-Entity

(N)-SAP

(N)-protocol (N)-SDUn

(N)-SDU1

(N)-SDU2

(N+1)-PDUs

FIF

O

FIFO

(A) Vertikale

Flusssteuerung

(N)-SDUn

(N)-SDU1

(N)-SDU2 (N)-PDUs

(B) Horizontale

Flusssteuerung

Dargestellt ist nur die Richtung X zu Y. Von Y zu X sind die Mechanismen identisch.

Open system X Open system Y


Die Flußsteuerung ist erforderlich, damit sich Stationen und Netzknoten vor Überlastungen schützen können. Eine Flusssteuerung findet sowohl vertikal als auch horizontal statt. hier wird die horizontale Flusssteuerung betrachtet.

Transportinstanzen haben in der Regel begrenzte Sende- und Empfangsspeicher.

Grundlegende Flusssteuerungsmechanismen sind:

– In den Protokollspezifikationen (z.B. bei HDLC) ist festgelegt: • max. PDU-Größe,

• max. Anzahl nummerierter PDU's, die man senden darf ohne Quittung vom Partner zu erhalten,

• der Programmierer kann aus den Parametern den Speicherbedarf einer Instanz ermitteln.

– In den PDUs wird dem Partner der aktuelle Füllstand des Empfangsspeichers mitgeteilt, z.B. bei TCP im Feld "WindowsSize".

Flusssteuerung: Übersicht

Schicht (N+1)

Schicht (N)

Instanz A

Sende-

Speicher

Data.Rq

Empfangs-

Speicher

Data.In

Instanz B

Empfangs-

Speicher Sende-

Speicher Paketübertragung

horizontale Flusssteuerung

Paketübertragung

Data.Rq Data.In



Flusssteuerung: Modulo-Nummerierung

Alle Pakete werden in Rahmen mit feststehender maximaler Größe übertragen.

Jeder Rahmen hat im Steuerfeld Plätze für zwei Folgenummern:

– der Sendefolgenummer N(S), codiert mit n Bits

– der Empfangsfolgenummer N(R), codiert mit n Bits.

Für n wird üblicherweise 3 oder 7 festgelegt. Die Rahmen werden modulus 2n numeriert.

– Für n=2: 22 mod4= 0,1,2,3,0,1,2,3,0,1,2,3,0,1,2,3,0,1,2,3,...

– Für n=3: 23 mod8= 0,1,2,3,4,5,6,7,0,1,2,3,4,5,6,7,0,1,2,3,4,5,6,7,...

– Für n=7: 27 mod128= 0,1,2,3,4,5,6,7,8, .. ,126,127,0,1,2,3,4,...

Während N(S) zu Nummerierung der Senderahmen von z.B. A nach B dient, wird N(R) zur Quittierung richtig empfangener Rahmen von B nach A verwendet. Dabei gilt:

– N(S)=x wird durch N(R)=modk(x+1) quittiert,

– Interpretation der Quittung: “Ich habe x empfangen und erwarte als nächstes modk (x+1)“.



Die Anzahl der Sendepakete, die man ohne Quittung zum Partner senden

kann, hängt von der Paketgröße und der Größe des Empfangsspeichers

ab. Beide Größen werden i.d.R. festgelegt.

Die maximale Differenz zwischen N(S) und empfangenen N(R) bezeichnet

man als Fenster (window). Dieses kann statisch oder dynamisch festgelegt

werden.

Die maximale Fenstergröße W kann sein W = (1...(2n-1)).

Sliding-Window oder Schiebefensterverfahren bei n=3 W= 1…7

Beispiel mit W=5

Diese Methode kommt bei HDLC-basierten Protokollen zur Anwendung.



Nummerierung : 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 1 Quelle sendet: 0 1 2 3 4 2 Source quitt.: 2 3 Quelle sendet: 3 4 5 6 7 4 Source quitt.: 7 5 Quelle sendet: 0 1 2 3 4


Die Anzahl der Sendepakete, die man ohne Quittung zum Partner senden

kann, hängt von der Paketgröße und der Größe des Empfangsspeichers

ab. Beide Größen werden i.d.R. festgelegt.

Die maximale Differenz zwischen N(S) und empfangenen N(R) bezeichnet

man als Fenster (window). Dieses kann statisch oder dynamisch festgelegt

werden.

Die maximale Fenstergröße W kann sein W = (1...(2n-1)).

Sliding-Window oder Schiebefensterverfahren bei n=3 W= 1…7

Beispiel mit W=5

Diese Methode kommt bei HDLC-basierten Protokollen zur Anwendung.



Modulo8 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0

1 Sender sendet 0 1 2 3 4

2 Empfänger quittiert 0 1 2


4 Empfänger quittiert 2 3 4 5 6 7




Für dieses Beispiel gelten

folgende Parameter:

– n = 3

– W = 5 zwischen A und B

– W = 1 zwischen B und C

HDLC (high level data link

control): hat mehrere

Möglichkeiten zur

Quittierung:

– RR-Frame (receive ready):

Quittierung mit Angabe,

dass im Empfangspuffer

noch Platz ist.

– RNR-Frame (receive not

ready): Quittierung mit

Angabe, dass im

Empfangspuffer z.Zt. kein

Platz ist.

– Ist dann wieder Platz, wird

ein RR-Frame gesendet.

A B C

I [ DATA, N(S)=0 ]

I [ DATA, N(S)=1 ]

I [ DATA, N(S)=2 ]

I [ DATA, N(S)=3 ]

I [ DATA, N(S)=4 ]

I [ DATA, N(S)=5 ]

I [ DATA, N(S)=6 ]

I [ DATA, N(S)=7]

I [ DATA, N(S)=0 ]

I [ DATA, N(S)=1 ]

RR [ N(R)=5 ]

RR [ N(R)=1 ]

I [ DATA, N(S)=1 ]

RR [ N(R)=2 ]

I [ DATA, N(S)=0 ]

I [ DATA, N(S)=2 ]

RR [ N(R)=3 ]

I [ DATA, N(S)=3 ]

RR, [ N(R)=4 ]

I [ DATA, N(S)=4 ]

RR [ N(R)=5]

usw. usw.

RNR [ N(R)=1 ]



Flußsteuerung: bei TCP im Internet

Daten werden in Segmenten bis zur feststehenden MSS (Maximum Segment Size)

übertragen. MSS= MTU1)-L2_PCI-L3_PCI-L4_PCI

Beispiel Ethernet: MTU=1518 MSS=1518-18-20-20=1460 byte

Jedes Datensegment hat im Steuerfeld Plätze für folgende Informationen: – Sequence number (Nummer des 1. Sendebytes in dieser Sequenz) mod 232 =mod 4.294.967.296

beispielhafte Werte für sequence number: 0,1,2,3, …, 4294967294, 4294967295, 0,1, …

– Acknowledge number (nächste erwartete Nummer des nächsten 1. Sendebytes) mod 232

beispielhafte Werte für acknowledge number: 0,1,2,3, …, 4294967294, 4294967295, 0,1, …

– Windows size (wieviel Byte kann ich noch empfangenaktueller Platz im Empfangsspeicher).

Die Fenstergröße beträgt einige 1000 Byte, z.B. 8192. – Die Länge der aktuellen PDU kann nur mittels des IP-Headers übermittelt werden.

Beim Verbindungsaufbau (Dreiwege-Handshake) teilen die paaren Instanzen ihren

Sequence-number-Ist-Stand mit, der vom Partner quittiert wird. Dies geschieht

mittels SYN, SYN/ACK, ACK.

Daten werden transportiert mittels PSH/ACK-Segmenten. Quittiert wird mittels

PSH/ACK oder einem ACK-Segment.

Beispiel im Inet: http://www.eventhelix.com/RealtimeMantra/Networking/Tcp.pdf

1) MTU - Maximum Transfer Unit


http://www.eventhelix.com/RealtimeMantra/Networking/Tcp.pdf


Flußsteuerung: bei TCP im Internet

TCP-Instanz X TCP-Instanz Y TCP-Segmente (PDU‘s|Frames) Applikation Applikation

CLOSED CLOSED

listen on port (passiv open)

LISTEN (activ) open port

SYN_SENT SYN-ACK-Segment sequ= Y, ack=X+1, win=8760 mss=1460

SYN_RCVD ACK-Segment sequ= Y+1, win=1892

ESTABLISHED ESTABLISHED

connected

connected

PSH-ACK sequ=X+1, ack=Y+1, data(A) send data(A)

PSH-ACK sequ=Y+1, ack=X+A+1, data(a)

data ready (A)

ACK ack= X+A+1

send data(a)

ACK ack= Y+a+1

data ready(a)

PSH-ACK sequ=Y+a+1, ack=X+A+1, data(b)

send data(b)

ACK ack= Y+a+b+1

data ready(b)

PSH-ACK sequ=Y+a+1, ack=X+A+1, data(b)

data read(a)

data read(a)

data read(a)

Client Server

Ve

rbin

du

ng

sau

fbau

D

ate

nü

be

rtra

gu

ng

sph

ase

initiale Sequenznummer Instanz X

initiale Sequenznummer Instanz Y

SYN-Segment sequ= X , win= 1892, mss=1460



Das OSI-Dienstmodell /ITU-T X.210/


Beispiel zeigt: vier mögliche OSI-service-user, wovon momentan drei den OSI-service nutzen

OSI-

Service-

User B

OSI-

submit

OSI-

deliver

OSI-

Service-

User A

OSI-

submit

OSI-

deliver

OSI-

Service-

User C

OSI-

Service-

User D

OSI-

submit

OSI-

deliver

OSI-Service Provider


Structure of OSI-service primitives /ITU-T X.210/


Primitives (Dienstelemente) sind virtuelle Konzepte. Sie modellieren die vertikale

Kommunikation zwischen Schichten zur Nutzung von Diensten.

Syntax von OSI-service-primitives in EBNF basierend auf ITU-X.210:

<service-primitive>::=<name-of-service-primitive> "(" {<parameter>, }*")";

<parameter>::=<service control information> | <service user data>;

<name-of-service-primitive>::= <service-name>"-"<service-primitive-name> "."

<primitive-type>;

<service-name>::=<layer identifier> | <component identifier>;

<layer-identifier>::= P | S | T | N | DL | Ph;

<component-identifier>::= A | … | R | ; (*A-ACSE, R- ROSE, siehe X.210, A.1*)

<service-primitive-name>::= (CONNECT | RELEASE | DATA | ACTIVITY-START | …);

<primitive-type>::= <basic-primitive>|<primitive-sub-type>"."<basic-primitive>|

<abbreviated-primitive>;

<basic-primitive>::= SUBMIT | DELIVER ;

<primitive-sub-type>::= REQUESTOR | ACCEPTOR;

<abbreviated-primitive>::= Request | Indication | Response | Confirmation;


X.210: OSI-service primitives


<primitive-sub-type>.<basic-primitive> <abbreviated-primitive> Erläuterung

requestor.submit request rq, Rq req requ Anforderung eines Dienstes

acceptor.deliver indication in, In ind indi Anzeige eines Dienstes

acceptor.submit response rs, Rs res resp Dienstantwort, Reaktion auf indication

requestor.deliver confirmation cf, Cf cnf conf Dienstbestätigung, Reaktion auf request

Beispiele Erläuterung

Ph-ACTIVATE.rq Ph-ACTIVATE.requestor.submit

DL fordert von Ph die Aktivierung der Schicht

Ph-ACTIVATE.in Ph-ACTIVATE.acceptor.deliver

Ph zeigt DL an, das die Aktivierung erfolgte

DL-ESTABLISH.rq DL-ESTABLISH.requestor.submit

N fordert DL auf, einen Dienst zur gesicherten Datenübertragung zu errichten

DL-UNITDATA.in DL-UNITDATA.acceptor.deliver

DL zeigt N an, ungesichert übertragene Daten sind angekommen

N-CONNECT.rq N-CONNECT.requestor.submit

T fordert N auf, eine Verbindung zu einem anderen Endsystem herzustellen.

N-CONNECT.cf N-CONNECT.acceptor.deliver

N zeigt T an, die angeforderte Verbindung zu einem anderen Endsystem wurde hergestellt.

S-CONNECT.rs S-CONNECT.acceptor.submit

P erlaubt S, eine vom Partner angeforderte Verbindung zu errichten.

P-DISCONNECT.cf P-DISCONNECT.requestor.deliver

P zeigt einem Application Service Element (ASE) an, dass die Verbindung abgebaut ist.

DL-UNITDATA.rq ............................................

..........................

.................................... DL-ESTABLISH.requestor.deliver

..........................


Diensttypsequenzen /ITU-T X.210/


Diensttypsequenzen sind eine Folge von Rq, In, Rs, Cf. Eine solche Folge

wird immer durch einen Rq eingeleitet.

N-Service User

N-Service Provider N-Service User x_request

x_indication

y_request y_indication

t1 t2

t3 t4

x_request x_indication

x_response x_confirmation

t1 t2

t3 t4


x_confirmation

t1 t2

t3 t4

unbestätigter Dienst

unbestätigter Dienst

bestätigter Dienst

bestätigter Dienst


x_response x_confirmation

t1 t2 bestätigter Dienst

Kurve: es existiert kein zwingender

zeitlicher Zusammenhang

Gerade: es existiert ein zwingender zeitlicher

Zusammenhang x_request und x_indication


Zusammenhang: Dienst, Primitives, Protokoll /X.210/


d

a

a

b

b

b

b

(N)-Layer d

a

a

b

b

b

b

(N+1)-Layer

(N-1)-Layer

Upper

Boundary

Lower

Boundary

c

Legende:

a service b primitives c protocol d entity


Zusammenhang: Dienst, Primitives, Protokoll /X.210/


Dienste einer (N)-layer, werden durch (N)-entities realisiert. Mittels Primitives werden Dienste gefordert, angezeigt, erlaubt, bestätigt. Dienste realisieren (N)-entities durch ein (N)-protocol. (N)-protocol besteht aus Festlegungen:

– Aufbau und Verwendung von PDUs, – Reihenfolge der Verwendung und Zeitbedingungen.

Zwei Darstellungsarten des gleichen Sachverhalts

N-Service User

N-Service Provider N-Service User


PDUa

y_request y_indication

y_response y_confirmation

PDUn

PDUm

Primitives Protocol

Primitives

Service Service

N-Service User

N-Service User

N-Service Provider

(1) x_requ

(3) x_indi

PDUn (2)

(4) x_resp

(6) x_conf

PDUm (5)

Service Service Primitives

Protocol


Zusammenhang: Dienst, Primitives, Protokoll z.B. bei TCP


TCP realisiert die Dienste: Verbindungsaufbau, Datenübertragung,

Verbindungsabbau.

TCP-Entity

Clt-Application

Events

Actions

SAP Port

*

TCP-Entity

Srv-Application

Events

Actions

SAP Port

*

Service provider Service provider

Service user Service user

Anfordern und Anzeigen von Diensten über

Primitives

TCP-Protokoll

Entities kommunizieren mittels Segments (TCP-PDUs)

Actions listen on port passive open on the given port

open port active open to the given port

read data data is read from the connection

send data data is sent to the connection

close the connection is closed

Events connected open succeeded (either active or passive)

connect failed active open failed

data ready data can be read from the connection

errored connection has errored and is now closed

closed an orderly disconnection has started

Segments SYN synchronization Verbindungsaufbau

ACK acknowledge Quittung

PSH push Datensegment

FIN final Verbindungsabbau

RST restart Neustart

URG urgend Dringende out of band data

OSI - Open Systems Interconnection Prof. Dr.-Ing. habil. Lutz Winkler ::: https://www.telecom.hs-mittweida.de 63

Zusammenhang: Dienst, Primitives, Protokoll z.B. bei TCP

Server Server Client Client TCP-Entity

SYN

TCP-Entity TCP-Segmente (PDU's)


listen on port (passiv open) (activ) open port

SYN/ACK

ACK connected connected

Dienst Verbindungsaufbau 3-Wege-Handshake

PSH/ACK mit data (A) send data(A)

PSH/ACK mit data (a)

data ready (A) ACK

send data(a)

ACK data ready(a)

data read(a)

data read(a) Dienst Daten-

Kommunikation

ACK

FIN

FIN close closed

closed

close Dienst

Verbindungsabbau

Primitives Primitives Protokoll, bestehend aus PDUs und

Ablaufregeln


Zusammenhang: Dienst, Primitives, Protokoll z.B. bei HDLC

2

Data Link

3

Network

2

DL

3

N Network Protocol

1

Physical 2

Ph

DL-CONNECT.rq

DL-DATA.rq

DL-UDATA.rq

DL-DISCONNECT.rq

DL-RESET.rq

Physical Protocol

DL-CONNECT.in

DL-DATA.in

DL-UDATA.in

DL-DISCONNECT.in

DL-RESET.in

Ph-ACTIVATE.rq

Ph-DATA.rq

Ph-ACTIVATE.in

Ph-DATA.in

DL-CONNECT.rq

DL-DATA.rq

DL-UDATA.rq

DL-DISCONNECT.rq

DL-RESET.rq

DL-CONNECT.in

DL-DATA.in

DL-UDATA.in

DL-DISCONNECT.in

DL-RESET.in

Ph-ACTIVATE.rq

Ph-DATA.rq

Ph-ACTIVATE.in

Ph-DATA.in

PDUs:

SABME, SABM, SNRM,

SNRME, SARM, SARME,

UA, DISC, DM, FRMR, I,

RR, REJ, RNR



Phase Service Primitive verwendete PDU's

DLC establishment

DLC establishment

DL-CONNECT.request SABM – (set asynchronous balanced mode) Verbindungswunsch UA – (unnumbered acknowledge) Verbindungsannahme DM – (disconnect mode) Verbindungsabweisung

DL-CONNECT.indication

DL-CONNECT.response

DL-CONNECT.confirmation

Data Transfer

NormalData Transfer

DL-DATA.request I – (information) nummerierte Daten RR – (receive ready) Positivquittung und Empfangsbereit RNR – (receive not ready) Positivquittung und nicht Empfangsbereit REJ – (reject) Zurückweisung von nummerierten Daten UI – (unnumbered information) unnummerierte Daten

DL-DATA.indication

Reset

DL-RESET.request SABM – (set asynchronous balanced mode) Verbindungswunsch UA – (unnumbered acknowledge) Verbindungsannahme DM – (disconnect mode) Verbindungsabweisung

DL-RESET.indication

DL-RESET.response

DL-RESET.confirmation

DLC release DLC release DL-DISCONNECT.request DISC – (disconnect) Verbindungsabbau

UA – (unnumbered acknowledge) Verbindungsabbauannahme DM – (disconnect mode) Verbindungsabbauabweisung DL-DISCONNECT.indication




DL-DATA.in

(Daten)

DL-DATA.in

(Daten)

DL-CONNECT.in

(X)

DL-(P+S), X N-(P+S)

DL-CONNECT.rq

(X)

DL-CONNECT.cf

(X) DL-DATA.rq

(Daten)

N-(P+S) DL-(P+S), Y

Daten zu X

Aufbau zu X Flag SABM P=1 X CRC Flag

UA F=1 X CRC Flag Flag

I N(S)=0 N(R)=0 X Data CRC Flag Flag

RR N(R)=1 X CRC Flag Flag

DL-DATA.in

(Daten)

DL-DATA.rq

(Daten) I N(S)=1 N(R)=0 X Data CRC Flag Flag

RR N(R)=2 X CRC Flag Flag

DL-DISCONNECT.in

DL-DISCONNECT.rq

(X)

DL-DISCONNECT.cf

(X)

Flag DISC P=1 X CRC Flag

UA F=1 X CRC Flag Flag

Abbau zu X

DL-DATA.rq

(Daten) I N(S)=0 N(R)=2 Y Data CRC Flag Flag

RR N(R)=1 Y CRC Flag Flag

DL-DATA.in

(Daten)

DL-DATA.rq


RR N(R)=2 Y CRC Flag Flag

Daten zu X

Daten von Y

Daten von Y

DL-DATA.in

(Daten)

DL-DATA.rq


RR N(R)=3 Y CRC Flag Flag Daten von Y

1 1

2

4 4

1 1

DIE

NST

E

PRIMITIVES

PRIMITIVES

PROTOKOLL bestehend aus PDUs und Ablaufregeln


Zustandsübergangsdiagramm der L2 aus Sicht der L3


Service User müssen wissen, in welchem Zustand der Service Provider ist

Dieses State diagram ist die Sicht von Network auf die Data Link,

Es entsteht lediglich durch Beobachtung der Primitivabfolge.

Eine (N+1)-Schicht kann nicht in die (N)-Schicht hinein sehen.

Primitives

N-entity N-entity

DL-entity DL-entity

DL-SAP

L3

Was geht da

unten in DL vor?

Was geht da

unten in DL vor?


Zustandsübergangsdiagramm der L2 aus Sicht der L2


Beachte:

Dieses State diagram ist die Sicht

von Data Link auf sich selber.

Alle CM-Protokolle basieren auf Zustandsmaschinen.


Transportdienste nutzen über Socket-API


Alle aktuellen Betriebssysteme bieten Socket-APIs an.

Socket-API:

– Ist ein lokales, betriebssystemabhängiges Interface, über das man den

Transportstapel (L4- oder L3-Dienste) nutzen kann.

– Nutzung ist recht rustikal. Siehe Script "Socketprogrammierung"

Alle aktuellen Programmiersprachen unterstützen dieses API, in dem sie

entsprechende Klassen zur Verfügung stellen.

Es gibt Klassen, die einen vollständigen Client- oder Serverteil von

Anwendungen abbilden.

Beispiele die direkt das Socket-API nutzen: mehr …

Beispiele, basierend auf C++-Komponenten: mehr …

https://www.telecom.hs-mittweida.de/index.php?eID=tx_nawsecuredl&u=0&file=fileadmin/verzeichnisfreigaben/telecom/winkler/vorlesungen/sockets.pdf&t=1289235569&hash=901f3c71f553111632b22e1e5a37e88a

https://www.telecom.hs-mittweida.de/kommunikationstechnivorlesungen/socket-programmierung/socket-beispiele-winsock.html

https://www.telecom.hs-mittweida.de/kommunikationstechnivorlesungen/socket-programmierung/socket-beispiele-komponenten.html


Protokolle erleben mit WireShark


Ethereal/WireShark ist ein leistungsfähiges Netzwerkanalysetool. Damit

kann man folgende Aufgaben lösen:

– Mitlesen von Protokolldateneinheiten einer Netzwerk-Kollisionsdomäne und

deren Speicherung,

– Auswertung mitgelesenen Protokolldateneinheiten bei verschiedener

Detaillierung.

– Es werden viele Netzwerkprotokolle und auch Formate von anderen

Netzwerkanalysetools unterstützt.

WireShark ist eine Open Source Software.

– Die aktuellste Programmversion (V 1.10.1) sowie Dokumentationen unter

www.wireshark.org/download.html

– Sample Captures unter http://wiki.wireshark.org/SampleCaptures

Eine deutschsprachige Dokumentation mit vielen Beispielen unter: https://www.telecom.hs-

mittweida.de/index.php?eID=tx_nawsecuredl&u=0&file=fileadmin/verzeichnisfreigaben/telecom/winkler/teachware/Ethereal.pd

f&t=1291723400&hash=5c9e03f654db3369ced629bbb464f53e

http://www.wireshark.org/download.html

http://wiki.wireshark.org/SampleCaptures



https://www.telecom.hs-mittweida.de/index.php?eID=tx_nawsecuredl&u=0&file=fileadmin/verzeichnisfreigaben/telecom/winkler/teachware/Ethereal.pdf&t=1291723400&hash=5c9e03f654db3369ced629bbb464f53e





Literatur


ITU-T: INFORMATION TECHNOLOGY – OPEN SYSTEMS INTERCONNECTION –

BASIC REFERENCE MODEL: THE BASIC MODEL“, Recommendation X.200 (7/94)

ITU-T: INFORMATION TECHNOLOGY – OPEN SYSTEMS INTERCONNECTION –

BASIC REFERENCE MODEL: CONVENTIONS FOR THE DEFINITION OF OSI SERVICES“,

Recommendation X.210 (11/93)

Weitere Literatur

– A. S. Tanenbaum: Computernetzwerke, Pearson Studium 2003, ISBN 978-3-8273-7046-4

F. Halsall: Data Communications, Computer Networks and Open Systems, Addison-Wesley 1995, ISBN 0-201-42293-X

B. Hebrawi: OSI – Upper Layer Standards and Practices, McGraw-Hill, Inc. 1992, ISBN 0-07-033754-3

H. Kerner: Rechnernetze nach OSI, Addison-Wesley 1993, ISBN 3-89319-632-3


Anhang: Komplexbeispiel ISDN – Szenario


Vermittlung Vermittlung

Satz n

Speisung 40V

Vermittlungs- steuerung

Koppel-

Netz

D

D B1,

B2

1 2 3 4 5 6 7 8 9 * 0 #

Filter,

PCM-

Codec

D- und

S-Schalt-

kreis

Anzeige

Ton-

Ruf

µR mit

RAM

und

ROM

Speisung

5 V

Satz 1

So

S

S

So

1 2 3 4 5 6 7 8 9 * 0 #

Filter,

PCM-

Codec

D- und

S-Schalt-

kreis

Anzeige

Ton-

Ruf

µR mit

RAM

und

ROM

Speisung

5 V

IOM

IOM

Speisung 40 V (4 W / 400mW)

64 kbit/s Nutzkanäle (B1, B2 )

Echokanal für D-Kanal

16 kbit/s Signalgabe (D16 )

S0-Bus, 4-adrig

IOM

IOM


Anhang: Komplexbeispiel ISDN – Protokollsicht


Die Anwendung besteht aus den Teilen: Signalgabe (D16-Kanal) und Nutzung eines B-Kanals.

Das Anwendungsprotokoll der Signalgabe ist Q.931, also ein Schicht-3-Protokoll!

Call Control Call Control


Call Control Agent Call Control Agent

I.430 I.430

Q.920/921 Q.920/921

Q.930/931 Q.930/931

4-Draht

Q.920/921 Q.920/921

Q.930/931 Q.930/931

Q.920/921 Q.920/921

Q.930/931 Q.930/931

Koppelnetz Koppelnetz

2

3

4

5

6

7

1 I.430 I.430 4-Draht

I.430 I.430


Call Control Agent

Call Control Agent

I.430 I.430

Q.920/921 Q.920/921

Q.930/931 Q.930/931

D D D D B1,B2 B1,B2 B1 | B2 B1 | B2

PC

M-

Codec

Bit-, Rahmen- Takt

1 2 3 4 5 6 7 8 9 * 0 #

Display

Ruf

Vermittlung (Switch) Signalgabe Nutzung Signalgabe Nutzung

Bit-, Rahmen- Takt

PC

M-

Codec

1 2 3 4 5 6 7 8 9 * 0 #

Display

Ruf


Anhang: Komplexbeispiel ISDN – Mapping (N+1)-ICI auf (N)-PCI


CCA-N-CC CCA-ICI N-PCI CC-ICI Kommentar

Verbindungs-

Aufbauphase

setupRq SETUP setupIn CCA fordert mittels setupRq eine Verbindung, N nutzt die SETUP-Message zur Übertragung der Anforderung. Mit setupIn wird der Verbindungswunsch der CC angezeigt. Diese prüft Vollständigkeit der Verbindungsdaten und die Verbindungsmöglichkeit.

proceedingIn CALL_PROC proceedingRq Alles OK: Zwischenmeldung von CC: Call ist im Aufbau

alertingIn ALERT alertingRq Zwischenmeldung von CC: beim B-Teilnehmer klingelt es, A hört Freizeichen

setupCf CONNECT setupRs B-Teilnehmer hat abgenommen, Verbindung kann genutzt werden

Call wird suspendiert und wieder hergestellt

suspendRq SUSPEND suspendIn Callsuspendierung, Transaktionscode z.B.=34

suspendCf SUSP_ACK suspendRs Geht in Ordnung,

resumeRq RESUME resumeIn Callwiederherstellung, Transaktionscode=34

resumeCf RES_ACK resumeRs Call wieder hergestellt

Call beenden

disconnectRq DISC disconnectIn Aus meiner Sicht könnten wir beenden (ausgelöst). Geht das in Ordnung?

releaseIn REL releaseRq ja: Auslösung wird eingeleitet

releaseRs REL_COM releaseCf Call ist beendet

CCA CCA N-protocol

Q.931 N-protocol

Q.931 CC CC

N-S

AP

N

-SA

P

Die Tabelle enthält Primitives für die vertikale Kommunikation (CCA-N bzw. N-CC)

Das Mapping von ICIs auf N- PCIs

Grundlagen siehe Folie

N-S

AP

N

-SA

P




DL-Ph-DL DL-ICI Ph-PCI DL-ICI

Einleitung Verbindungs-

aufbau

phActRq INFO1 Aktivierung wird vom Endgerät erbeten mit INFO1

INFO2 Die Netzseite leitet mit INFO2 die Aktivierung ein (Transportrahmen mit allen Inhaltsbits =0, damit maximaler Takt)

Verbindung

hergestellt

INFO3 phActIn Das Endgerät sendet zum Netz INFO3 (Transportrahmen)

phActIn INFO4 Das Netz sendet zum Endgerät INFO4 (Transportrahmen)

N-DL-N N-ICI DL-PCI N-ICI

Schicht-2-Aufbau

dlEstRq SABME dlEstIn L3 muss gesicherte Daten austauschen. Sie fordert mittels dlEstRq den Aufbau einer L-2-connection für gesicherte DÜ. Mittels SABME wird der Aufbau zur peer-entity übertragen. Diese kann akzeptieren oder ablehnen. Wurde connection akzeptiert, wird dies der L3 mittels dlEstIn angezeigt und ein CES übergeben.

dlEstCf UA Akzeptiert mittels UA (unnumbered acknowledge)

dlReleaseIn DM Abgelehnt mittels DM (disconnect mode)

Nummerierte, gesicherte

Daten-übertragung

dlDataRq I dlDataIn Nummerierte und gesicherter Datentransport über I-Frames

RR Richtig empfangene I-Frames werden durch die DL-Instanz mit RR quittiert

dlDataIn I dlDataRq

RR

N N DL-protocol

Q.921 DL-protocol

Q.921 N N

DL-

SAP

D

L-SA

P

DL-

SAP

D

L-SA

P

DL DL Ph-protocol

Q.921 Ph-protocol

Q.921 DL DL

Ph

-SA

P

Ph

-SA

P

Ph

-SA

P

Ph

-SA

P




Eine solche Darstellung ist übersichtlich, wenn man sich bereits auskennt.

2

Data Link 2

Data Link

3

Network 3

Network

2

DL 2

DL

3

N 3

N Network protocol

1

Physical 1

Physical 2

Ph 2

Ph

DL-CONNECT.rq

DL-DATA.rq

DL-UDATA.rq

DL-DISCONNECT.rq

DL-RESET.rq

Physical protocol

DL-CONNECT.in

DL-DATA.in

DL-UDATA.in

DL-DISCONNECT.in

DL-RESET.in

Ph-ACTIVATE.rq

Ph-DATA.rq

Ph-ACTIVATE.in

Ph-DATA.in

DL-CONNECT.rq

DL-DATA.rq

DL-UDATA.rq

DL-DISCONNECT.rq

DL-RESET.rq

DL-CONNECT.in

DL-DATA.in

DL-UDATA.in

DL-DISCONNECT.in

DL-RESET.in

Ph-ACTIVATE.rq

Ph-DATA.rq

Ph-ACTIVATE.in

Ph-DATA.in

PDUs:

SABME, SABM, SNRM,

SNRME, SARM, SARME,

UA, DISC, DM, FRMR, I,

RR, REJ, RNR

Physical medium


Anhang: Komplexbeispiel ISDN –Verbindungsaufbau (in Form eines MSC, message sequence chart)


dlEstIn(CES=1)

phActIn

CCA N DL CC N DL Ph

ISDN-Telefon ISDN-Vermittlung

dlEstRq(SAPI=0) phActRq INFO 1

INFO 2

INFO 4

INFO 3

phActIn

DL beschafft sich eine Hardware-Adresse TEI und bekommt z.B.=65

SABME(SAPI=0,TEI=65)

UA(SAPI=0,TEI=65)

setupRq [CdPyNr,BC]

dlEstCf(CES=3)

dlDatRq(CES=3) [SETUP:CdPyNr,BC]

setupIn [CdPyNr,BC]

I-Frame(SAPI=0,TEI=65,N(S)=0,N(R)=0) [SETUP:CdPyNr,BC] dlDatIn(CES=1)

[SETUP:CdPyNr,BC] RR(SAPI=0,TEI=65,N(R)=1) proceedingRq

[CHI=2] dlDatRq(CES=1)

[CALL_PROC:CHI=2] proceedingIn

[CHI=2]

I-Frame(SAPI=0,TEI=65,N(S)=0,N(R)=1) [CALL_PROC:CHI=2] dlDatIn(CES=3)

[CALL_PROC:CHI=2] RR(SAPI=0,TEI=65,N(R)=1) alertingRq

dlDatRq(CES=1) [ALERT]

alertingIn

I-Frame(SAPI=0,TEI=65,N(S)=1,N(R)=1) [ALERT] dlDatIn(CES=3)

[ALERT] RR(SAPI=0,TEI=65,N(R)=2) setupRs

dlDatRq(CES=3) [CONNECT]

setupCf

I-Frame(SAPI=0,TEI=65,N(S)=2,N(R)=1) [CONNECT] dlDatIn(CES=3)

[CONNECT] RR(SAPI=0,TEI=65,N(R)=3)

Jetzt existiert eine 64-kbit/s-Duplexverbindung (B2-Kanal) über die z.B. PCM-codierte Sprache übertragen wird

Ph


Anhang: Komplexbeispiel ISDN – Suspend- und Resume


CCA N DL Ph CC N DL Ph

suspendRq [Call identity=34]

dlDatRq(CES=3) [SUSPEND:CID=34]

suspendIn [Call identity=34]

I-Frame(SAPI=0,TEI=65,N(S)=1,N(R)=3) [SUSPEND:CID=34] dlDatIn(CES=1)

[SUSPEND:CID=34] RR(SAPI=0,TEI=65,N(R)=2)

Die 64-kbit/s-Duplexverbindung existiert jetzt nicht mehr. In der Vermittlung gibt es eine CC-Instanz, die einen Call mit der Call Identity=34 zu einem B-Tln. aufrecht erhält.

Das ISDN-Telefon werde jetzt aus der Steckdose gezogen, damit hören alle ISDN-Telefon-Instanzen auf zu existieren

suspendRs dlDatRq(CES=1)

[SUSP_ACK] suspendCf

I-Frame(SAPI=0,TEI=65,N(S)=3,N(R)=3) [SUSP_ACK] dlDatIn(CES=3)

[SUSP_ACK] RR(SAPI=0,TEI=65,N(R)=4)

dlEstIn(CES=2)

CCA N DL Ph

dlEstRq(SAPI=0)

DL beschafft sich eine Adresse TEI und bekommt z.B.=66

SABME(SAPI=0,TEI=66) [

UA(SAPI=0,TEI=66)

resumeRq [Call identity=34]

ISDN-Telefon wird wieder angesteckt, Resume-Funktion mit Call Identity 34 benutzt

phActIn

phActRq INFO 1

INFO 2

INFO 4

INFO 3

phActIn

dlEstCf(CES=4)


Anhang: Komplexbeispiel ISDN – Resumevollendung, Abbau


CCA N DL Ph CC N DL Ph

dlDatRq(CES=4) [RESUME:CID=34]

resumeIn [Call identity=34]

I-Frame(SAPI=0,TEI=66,N(S)=0,N(R)=0) [RESUME:CID=34] dlDatIn(CES=2)

[RESUME:CID=34] RR(SAPI=0,TEI=66,N(R)=1)

resumeRs [CHI=1]

dlDatRq(CES=2) [RES_ACK:CHI=1]

I-Frame(SAPI=0,TEI=66,N(S)=0,N(R)=1) [RES_ACK:CHI=1] dlDatIn(CES=4)

[RES_ACK:CHI=1] RR(SAPI=0,TEI=65,N(R)=1) resumeCf

[CHI=1]

Jetzt existiert die 64-kbit/s-Duplexverbindung wieder (B1-Kanal), über die z.B. PCM-codierte Sprache übertragen wird

disconnectRq dlDatRq(CES=4)

[DISC:CAU=normal] disconnectIn [CAU=normal]

I-Frame(SAPI=0,TEI=66,N(S)=1,N(R)=1) [DISC:CAU=normal] dlDatIn(CES=2)

[DISC:CAU=normal] RR(SAPI=0,TEI=65,N(R)=2)

releaseRq dlDatRq(CES=2)

[REL] releaseIn

I-Frame(SAPI=0,TEI=66,N(S)=1,N(R)=2) [REL] dlDatIn(CES=4)

[REL] RR(SAPI=0,TEI=65,N(R)=2)

releaseRs dlDatRq(CES=4)

[REL_COM] releaseCf

I-Frame(SAPI=0,TEI=66,N(S)=2,N(R)=2) [REL_COM] dlDatIn(CES=2)

[REL_COM] RR(SAPI=0,TEI=65,N(R)=3)

Die 64-kbit/s-Duplexverbindung wieder (B1-Kanal) existiert jetzt nicht mehr.

Documents

Grundlagen der Kommunikationstechnik (3) OSI-Sichtwin/vorlesungen/GrundlagenKT-OSI-Sicht.… · OSI - Open Systems Interconnection Ziel und Inhalt der Vorlesung Prof. Dr.-Ing. habil