Kommunikationssysteme Teil 1.4 – Planung und Dimensionierung

KommunikationssystemeTeil1.4 – Planung und Dimensionierung Stephan Rupp InformatikMasterstudium www.dhbw-stuttgart.de

Inhalt Planung und Dimensionierung • IP-basierte Netze • Voice over IP • Verkehrsmodelle und Systemdimensionierung • Daten und Redundanz

IP basierende Netze - Subnetworks Subnetworks (Teilnetze) sind die kleinsten Netzbereiche im Internet. • Üblicherweise entsprechen sie einem LAN-Segment. • Sie bestehen aus Workstations und Servern - „Internet Hosts“. • Jeder „Internet Host“ hat (mindestens) eine IP-Adresse. • Router bilden den Übergang zwischen den Subnetworks. Host 4 Host 2 Host 6 Router LAN Sub- Net- Work Host 1 Host 3 Host 5 Quelle: HaraldOrlamünder

Verbinden von Teilnetzen (1) IP Subnetworks werden durch IP Router miteinander verbunden. Der IP Router besitzt eine IP-Adresse per Port. Internet Nutzer IP Subnetwork IP Subnetwork IP Router Internet Nutzer IP Subnetwork IP Subnetwork Quelle: HaraldOrlamünder

Verbinden von Teilnetzen (2) Um eine größere Strecke zu überwinden wird ein Router-Paar eingesetzt. Internet Nutzer IP Subnetwork IP Subnetwork IP Router IP Router Internet Nutzer IP Subnetwork IP Subnetwork Quelle: HaraldOrlamünder

IP-Netze: Autonomes System Ein Autonomes System (AS) besteht aus einer Menge Router und Netze (Sub-networks), die einer gemeinsamen technischen Verwaltung unterstehen. Das Autonomes System ist charakterisiert durch: • ein gemeinsames Routing-Protokoll (üblicherweise) • volle Erreichbarkeit im AS IP Subnetwork IP Subnetwork Autonomous System IP Subnetwork In der OSI-Welt wird das Autonome System “Routing Domain” genannt. Quelle: HaraldOrlamünder

VerbindenAutonomerSysteme Autonomous System 1 IP Subnetwork IP Subnetwork Interior Routing Protocols Exterior Routing Protocols IP Subnetwork IP Subnetwork IP Subnetwork IP Subnetwork IP Subnetwork Autonomous System 2 IP Subnetwork Autonomous System 3 IP Subnetwork Quelle: HaraldOrlamünder

Internet Service Provider (ISP) Logische Sicht des Netzes Kunde des ISP mit permanentem Zugang (Mietleitung) R = Router S = Server N = Network Access Server Kunde des ISP mit Wähl-Zugang bzw. DSL zu anderen ISPs oder zum Backbone R R N R S N S ISP Quelle: HaraldOrlamünder

Internet Service Provider (ISP) Physikalische Sicht des Netzes Übertragungs-technisches Netz PSTN/ISDN OVst zu anderen ISPs oderzum Backbone R R N R R = Router S = Server N = Network Access Server OVst = Orts-Vermittlungsstelle S N S ISP Standort B Standort A Quelle: HaraldOrlamünder

Das Internet alsNetz N = Network Access Server R = Router S = Server CIX = Commercial Internet Exchange R ISP = Internet Service Provider R ISP 2 ISP 1 N N S R S R R 1. N R N N ISP 3 R R S S CIX 2. N 3. R R Internet R Back- bone R ISP 4 N S R 1. Router-Paar 2. unabhängiger Router „CIX“ 3. unabhängiges IP-Backbone R N Quelle: HaraldOrlamünder

Digitalisieren • Kodieren • Paketieren • Auspacken • Dekodieren • Zusammensetzen • Übertragen Sprachpakete im Internet

Voice over IP Von Mund zu Ohr: Telefonieren verträgt wenig Verzögerungen

Öffentliche Netze Festnetz • Media Servers • announcements • customised tunes • conferences • voice mail • streaming media • trunking gateways Media Server PSTN Trunking GW/ Signalling Gateway Call Server/ Gateway Controller IP Network (Carrier) PLMN • Call Server • session states • SIP control • H.323 control • MGCP/Megaco Trunking GW Mobilnetz

SIP Happens SIP: Session Initiation Protocol (Signalisierungsprotokoll für Sessions) • User Agent: Anwendungssoftware auf Terminals (SIP End Points) • Terminals: PCs, Telefone, … • Sind User Agents Clients oder Server? • Client: Ich rufe an. • Server: Ich nehme einen Anruf an. • User Agent: Client + Server SIP User Agent Request SIP User Agent Response Quelle: GerdSiegmund

Erstregistrieren, danntelefonieren Registrar • nimmt “REGISTER requests” an und registriert Teilnehmer • Üblicherweise im SIP-Server implementiert • Verwendet SIP Location Service im Informationen über Teilnehmer zugänglich zu machen Register OK User Agent Registrar Quelle: GerdSiegmund

SIP Server Proxy Server • Server und Client zur Vermittlung von Sessions • Verwaltet Zustände (states) oder wird zustandslos betrieben Redirect Server • Nur Server • Vermittelt Server-Adressen 1 2 1 4 2 3 Quelle: GerdSiegmund

Verbindungsuafbau mit SIP SIP Transaktion • SIP funktioniert wie HTTP (Web) oder SMTP (Mail) • SIP ist ein textbasiertes Protocol wie HTTP • Client schickt Service Requests und empfängt Service Responses • Server empfängt Requests und verschickt Responses • Eine SIP Transaktion besteht aus SIP • Request (Anfrage) • Ggf. Responses über Zwischenstände • Response (Antwort) • Transaktionen sind durchnumeriert (commandsequencenumbers, Cseq) Quelle: GerdSiegmund

SIP Adressen Universal Resource Locators (URL) Sind Namen, wie E-Mail Adressen (SMTP) Beispielefür SIP Addressen: sip:hans.muster@musterbau.de sip:hans.muster@10.1.1.1 sip:8972312345@musterbau.de Um die SIP Adresse in eineNetzadresezuübersetzten, wirdDNS (Domain Name Service) verwendet, sowie der Location Server Quelle: GerdSiegmund

SIP Nachrichten (Messages) Define transaction Request-Line Status-Line generic message start line general-header Describe transaction message header request-header response-header entity-header Blank line CRLF CRLF message body message body SDP Exchange capabilities Quelle: GerdSiegmund

Beispiel für eine SIP Nachricht Request/Status Zeile INVITE sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3 To: T. Watson <sip:watson@bell-tel.com> Call-ID: 662606876@kton.bell-tel.com CSeq: 1 INVITE Contact: <sip:a.g.bell@kton.bell-tel.com> Subject: Mr. Watson, come here. Content-Type: application/sdp Content-Length: ... v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 s=Mr. Watson, come here. t=3149328600 0 c=IN IP4 kton.bell-tel.com m=audio 3456 RTP/AVP 0 3 4 5 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:4 G723/8000 a=rtpmap:5 DVI4/8000 Header Body Quelle: GerdSiegmund

SIP Requests Jeder Request löst eine Server-Methode aus SIP definiert 6 Methoden • REGISTER registerswithlocationservice • INVITE initiatescall • ACK confirms final response • CANCEL cancels a pendingrequest • BYE forterminatingsessions • OPTIONS queriesfeaturesupportby remote side Quelle: GerdSiegmund

SIP Status Codes Wie HTTP Response Codes 1xx Informational ( e.g. 100 Trying, 180 Ringing ) 2xx Successful ( e.g 200 OK) 3xx Redirection ( e.g. 302 MovedTemporarily ) 4xx Request Failure ( e.g 404 Not Found, 482 Loop Detected ) 5xx Server Failure ( e.g 501 Not Implemented ) 6xx Global Failure ( 603 Decline ) Quelle: GerdSiegmund

SIP mitRufumleitung (Redirect) berlin.de cologne.de munich.de INVITE 1 Redirect Server 302 Move temporarily 2 ACK 3 bob@munich.de alice@berlin.de munich.de INVITE 4 Proxy Server 100 Trying INVITE 5 6 180 Ringing 180 Ringing 8 7 200 OK 10 200 OK 9 ACK 11 Media Session 12 BYE 13 200 OK 14 Quelle: GerdSiegmund

CANCEL 5 200 OK 6 CANCEL 5 CANCEL 5 200 OK 4 ACK 7 Media Session 8 BYE 9 200 OK 10 SIP mit Verzweigung (Call Forking) berlin.de INVITE munich.de SIP enabled mobile phone INVITE 3 1 100 Trying 2 INVITE SIP enabled Organizer 3 alice@berlin.de Proxy Server INVITE 3 SIP Phone INVITE 3 SIP Client bob@munich.de Quelle: GerdSiegmund

Session Description Protocol (SDP) • SDP wird verwendet um die Medienformate zu spezifieren (Audio, Video, Codecs etc) • Format: Parameter = Value • SIP transportiert SDP im Message Body • SDP ist ebenfalls textbasierend • SDP ist specifiziert in RFC 2327 Quelle: GerdSiegmund

INVITE sip:bob@macrosoft.com SIP/2.0 To: sip:bob@macrosoft.com From: sip:alice@wonderland.com Call-ID: 1234@a.wonderland.com Cseq: 1 INVITE Contact: alice@a.wonderland.com INVITE sip:bob@macrosoft.com SIP/2.0 To: sip:bob@macrosoft.com c=IN IP4 128.59.19.38 m=audio 5100 RTP/AVP 0 c=IN IP4 128.59.19.38 m=audio 5100 RTP/AVP 0 SIP und SDP SIP macrosoft.com Internet IPv4 Zieladresse c=IN IP4 128.59.19.38 m=audio 5100 RTP/AVP 0 SDP Audio Port Transp.=RTP G.711 Quelle: GerdSiegmund

Ein Beispiel SDP im SIP Message Body INVITE sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3 To: T. Watson <sip:watson@bell-tel.com> Call-ID: 662606876@kton.bell-tel.com CSeq: 1 INVITE Contact: <sip:a.g.bell@kton.bell-tel.com> Subject: Mr. Watson, come here. Content-Type: application/sdp Content-Length: ... v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 s=Mr. Watson, come here. t=3149328600 0 c=IN IP4 kton.bell-tel.com m=audio 3456 RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 Protocol versionnumber Owner/creatorandsessionidentifier Session name Time sessionstartsandstops Connection information Media information Attributes Quelle: GerdSiegmund

Beispiel: Öffentliche Netze SIP Call Server Medien-Server Telefonnetz • Medien-Server • Ansagen • Konferenzen • Mailbox • … Gateway Call Server IP Netz (Netzbetreiber) • verarbeitet Transaktionen für Telefongespräche (SIP callcontrol) • steuert Medien-Server & Gateways Mobilfunk-netz Gateway

Bemessungsgrößenfür den Call Server Transaktionsrate: • Transaktionen für Anrufe (SIP Transaktionen) • Transaktion: Verbindung aufbauen, Verbindung auflösen, Ticket zur Abrechnung generieren, bzw. Ausnahmebehandlung Verkehrsmodell (Beispiel): • 1 Mio Teilnehmer (Subscribers) • 500 Bytes Daten pro Teilnehmer (Teilnehmerprofil in der Datenbank) • 4 Anrufe pro Teilnehmer in der Hauptverkehrsstunde • Bemerkung: Hauptverkehrsstunde = Bemessungsgrösse; Messwert BHCA = Busy Hour Call Attempts (Transaktionen in der Hauptverkehrsstunde) Transaktionsrate im Call Server: • ca. 1000 tps (Transaktionen pro Sekunde) • Bemerkung: Bei 1 Mio Teilnehmer: 4 Millionen BHCA, bei ca. 4000 Sekunden/Stunde ergeben sich ca. 1000 tps)

Bemessungsgrößen (2) Durchsatz (Througpout, Verkehr in bit/s) • Pro Transaktion: 3 Nachrichten mit 10 kBit Länge pro Nachricht • 1000 Transaktionen pro Sekunde (Ergebnis siehe letzte Seite) • 30 Mbit/s Durchsatz für Signalisierung (controltraffic) Datenbank: • 500 Bytes pro Teilnehmer für Call States und Teilnehmerprofil (location, presence, servicesettings, …) • 500 MByte Datenbank (Arbeitsspeicher & Disk) Systemmodell Eingangspuffer Ausgangspuffer Prozessor SIP-Nachrichten SIP-Nachrichten 1000 tps (bei 80% Systemauslastung)

Modell des Call Servers Nichtfunktionale Anforderungen: • Verfügbarkeit (Redundanz, Kapselung, …) • Sicherheit (Schutz des Systems und der Daten) • Konventionen bzgl. Bauweise (Umgebungsbedingungen: Temperatur, EMV, mechanische Beanspruchung, Schadstoffe, Brandverhalten, …) Systemmodell Eingangspuffer Ausgangspuffer Prozessor SIP-Nachrichten SIP-Nachrichten 30 MBit/s 1000 tps(bei 80% Systemauslastung) Daten 500 MB Arbeitsspeicher und Festplatten EMV,: elektromagnetische Verträglichkeit (Einstrahlung, Abstrahlung, Spannungsspitzen, ...)

Verfeinerung des Modells Dauer der Transaktion Wieviele gleichzeitig aktive Sessions gibt es? • Aktive Sessions = Transaktionen pro Sekunde x Dauer der Transaktion • Annahme: Telefonanruf dauert 100 Sekunden • 1000 tps x 100 s = 100.000 aktive Sessions • 500 Bytes per Session (Teilnehmerprofil) => 50 MB im Arbeitsspeicher Systemmodell Ausgangspuffer Eingangspuffer Prozessor Cache Daten: Datenbank, Dateisystem, Betriebssystem Arbeitsspeicher (flüchtig) Speichern, Laden, Paging Disks (persistent)

ZurVerweildauer der Transaktion Fast Food Restaurant Ausgang Eingang Selbstbedienung & Kasse Restaurant mit Platz für 200 Gäste Mittlere Aufenthaltsdauer pro Gast: 15 Minuten Frage: Wie viele Gäste pro Stunde (bzw. pro Minute) muss die Kasse bedienen können?

NichtfunktionaleAnforderungen Beispiel: 2x Redundanz als Designvorgabe bzgl. Verfügbarkeit • Speicher: Disks in RAID Konfiguration (z.B. RAID1) • Prozessor: • Cluster-Konfiguration mit 2x Prozessoren • Datenbank im Arbeitsspeicher • Synchronisation der Arbeitsspeicher im Cluster • Switch-over und Fail-over mit gleichen IP-Adressen RAID storage processor synch switch Network client

Call Server - Zusammenfassung Funktionale Anforderungen Verkehrsmodell (Erfahrungswerte): • 1 Mio Teilnehmer (subscribers) • 500 kBytes Daten pro Teilnehmer (Teilnehmerprofil in der Datenbank) • 4 Anrufe pro Teilnehmer in der Hauptverkehrsstunde • 100 Sekunden Dauer pro Anruf • 3 Nachrichten (in und out) pro SIP Transaktion • 10 kBits pro Nachricht Systemanforderungen (Ergebnis aus Vorgaben): • 1000 tps (Transaktionen pro Sekunde) • 30 Mbit/s Troughput für Call Control (SIP-Nachrichten) • 500 MBytes Datenbank für Teilnehmerprofile • 50 MBytes Arbeitsspeicher Nichtfunktionale Anforderungen: Verfügbarkeit, Umgebungsbedingungen

Beispiel: Medien-Server Video/Audio On Demand Life TV/ Local TV Medien-Server Node B/BTS GGSN/HA IP Netz RAN (3G//WiMax/4G) CMTS DSLAM CaTV RNC/AC DSL STB STB CMTS: Cable Modem Termination Server

Modell des Medien-Servers 12 Gbps (0.64 Gbps) 10 Gbps (0.64 Gbps) Processor Ausgangsverkehr Eingangsverkehr Arbeits- speicher 25 GB (10% der aktivenSessions) (8GB) 250 GB (5000 videos) (80 GB) Festplatte Gleiches Vorgehen wie beim Call Server, jedoch mehr Datenverkehr 200.000 Subscribers 30 tps 180 s per transaction 5000 parallel sessions Verkehrsmodell Wireless Networks 128 kbps per session 640 Mbps total traffic Wireline Networks 2 Mbps per session 10 Gbps total traffic

Systemarchitektur des Medien-Servers Main Controllers Session Processors InternesNetzwerk (10GbE) Media Processors (DSP, transcoding) Switches Uplinks (10GbE) IP Netz DSP: DigitalerSignalprozessor (spezialisiert auf Bildverarbeitungbzw. Audioverarbeitung, beispielsweisezumumkodieren von Formaten)

Gymnastik - Medienserver … … im Mobilfunk Verkehrsmodell 36 Mio Teilnehmer 1 Transaktion (Video) pro Teilnehmerin der Haupt-verkehrsstunde 400 Teilnehmer pro Funkzelle AG1: 10 Zellen AG2: 20 AG1 Video Streams: 128 kbit/s 3 MinutenDauer Media Server (Video Server)

Medienserver im Mobilfunk (2) Fragen • Wie gross ist der Verkehr für Video-Streaming pro Funkzelle? • Wieviele Transaktionen pro Sekunde (für Anfragen und Abspielen von Videos) muss der Media-Server bedienen? • Welchen Verkehr (bit/s) muss der Media-Server bewältigen (gleichzeitig abgespielte Videos)? Bonus-Stretch (Einschätzung): • Funkzelle: Wie passt dieser Verkehr (Frage 1) zur Kapazität gängiger Mobilfunkstandards? • Media-Server: Würde man diese Menge an Verkehr (Frage 3) mit einem einzigen System bedienen wollen? • Media-Server: Kann man diese Art Server parallelisieren?

Daten und Redundanz Anwendungsfall: • Laufende Transaktionen werden im Arbeitsspeicher vorgehalten. • Beispiele: Call Server, Home Location Register, Medien-Server • Wegen der hohen Anzahl Teilnehmer fallen große Datenmengen an. Aufgabe: • Schutz dieser Daten gegen Ausfälle einzelner Server. • Abspeichern auf Festplatte kommt wegen der diesbezüglichen Wartezeiten nicht in Frage.

F1 F2 F3 F4 Lösung: RedundanteDatenbank Datenbank Datenbank-Knoten (Data Nodes) Primäreund Sekundäre Fragmente Fragmente F1 F2 F3 F4 (F2) (F1) (F4) (F3) N1 N2 N3 N4 • Verteilte Datenbank: • Definiere Fragmente (F1, F2, …) • Ordne Fragmente den Datenbank-Knoten inkl. Spiegel-Fragmenten zu (logische Organisation) • Fragmente werden zwischen den Datenbank- Knoten auf pro Transaktion synchronisiert • Ordne Datenbank-Knoten Gruppen von Knoten (Servern) zu (phys. Organisation) • Datenbank verbleibt im Arbeitsspeicher mit Sicherung in definierten Zeitintervallen (Checkpoints) auf Festplatte Zuordung der Knoten zu Gruppen Gruppen von Knoten N1 N2 F1 F3 (F2) (F4) F2 F4 (F1) (F3) N3 N4 Gruppe 1 Gruppe 2

Beispiel: MySQL Cluster MinimaleredundanteKonfiguration (F1) Commit Transactions Disk Checkpoints Disk Checkpoints

Systemarchitektur Server mit redundanter Datenbank Management Knoten(gedoppelt) Datenbank-Knoten (DataNodes) Main Controllers Back-End Processors A SB = CPU InternesNetzwerk(GbE) MySQL Server (Load Sharing) Front-End Processors InternesNetzwerk(GbE) Switch Switch Uplinks IP Netz A: Aktiv SB: Standby (in Bereitschaft) GbE: Gigabit Ethernet

Aufgaben der Systemkomponenten Management Knoten: • StartenalleProzesse im Cluster • StellenBenutzerschnittstellezurVerfügung MySQL Server: • StartenLeseanfragen und Schreibanfragen in den Datenbank-Knoten • Arbeiten in Lastverteilung (load sharing) Datenbank-Knoten: • führen die redundanteDatenbank,

Time to recover Data Node 1 Data Node 1 F1 F1 F1 (F2) (F2) (F2) F2 F2 (F1) (F1) Data Node 2 Data Node 2 KritischerPfad Verlust und Wiederherstellung (Recovery) einesDatenbank-Knoten: • beiVerlusteinesKnotenswird das Spiegel-Fragment im anderenKnotenaktiv • jedochist das System jetztnichtmehr redundant und dahergefährdetbiszur … • … Wiederherstellung des verlorenenDatenbank-Knotens Data Node 1 Fällt Data Node 1 Einsatzbereit Data Node 1 Data Node 1 F2 F1 (F1) Data Node 2 Data Node 2 kompensiert Einzelkämpfer (Single Point ofFailure) bis …

Fail-Over Konzept Management Knoten: • KonsequenzeinesVerlustes: KeineBenutzerschnittstellemehr, das Cluster arbeitetohne Management weiter. • Redundanz: Active/Standby MySQL Server: • KonsequenzeinesVerlustes: WenigerLeistung, jedochkeinDatenverlust, daAnwendungen (= MySQL Server) und Daten (= Datenbank-Knoten) getrenntsind. • Redundanz: N+1 mitLastverteilung (Load Sharing) Datenbank-Knoten: • KonsequenzeinesVerlustes: KeinDatenverlust, jedochkeineAbsicherungmehr (Einzelkämpferposition des verbleibendenSpiegels), bis der Knotenwiedereinsatzbereitist. • Redundanz: biszu 3 Kopien der Daten (biszu 3 Spiegel-Fragmente im Arbeitsspeicher)

Kommunikationssysteme Teil 1.4 – Planung und Dimensionierung