500 likes | 665 Views
Technik der digitalen Netze Teil 6 – Protokolle und Datenmodelle. Stephan Rupp Nachrichtentechnik. www.dhbw-stuttgart.de. Inhalt. Protokolle und Datenmodelle IP basierende Netze Voice over IP SIP Happens Service Orientierte Architekturen Die Zukunft der Netze.
E N D
Technik der digitalen NetzeTeil6 – Protokolle und Datenmodelle Stephan Rupp Nachrichtentechnik www.dhbw-stuttgart.de
Inhalt Protokolle und Datenmodelle • IP basierende Netze • Voice over IP • SIP Happens • Service Orientierte Architekturen • Die Zukunft der Netze
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
Inhalt Protokolle und Datenmodelle • IP basierende Netze • Voice over IP • SIP Happens • Service Orientierte Architekturen • Die Zukunft der Netze
Digitalisieren • Kodieren • Paketieren • Auspacken • Dekodieren • Zusammensetzen • Übertragen Sprachpakete im Internet
Anwendungsebene Netzebene Modemebene WiFi DSL SDH DSL Ethernet Schichtenmodell A Terminal (Endgerät) Terminal (Endgerät) B SIP: Signalisierung RTP: Sprachkanal IP
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
Inhalt Protokolle und Datenmodelle • IP basierende Netze • Voice over IP • SIP Happens • Service Orientierte Architekturen • Die Zukunft der Netze
Telefonieren mit SIP – SIP User Agent 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
Location Server • Enthält Information über den Aufenthaltsort des Teilnehmers im Sinne einer Anrufweiterleitung • Location Servers können als Teil eines SIP Servers implementiert werden Registrar Location Service Proxy Server Redirect Server 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
Inhalt Protokolle und Datenmodelle • IP basierende Netze • Voice over IP • SIP Happens • Service Orientierte Architekturen • Die Zukunft der Netze
1. Linear 4. VerteilteObjekt-orientiert 3. Objekt-orientiert 2. Strukturiert Computer 1 Computer 2 Computer Computer Computer Program ... ... ... ... ... ... ... Main Program Main Program Main Program 1. Method 1. Method 1. Sub Program 2. Method 2. Sub Program 2. Method 3. Method 3. Method 3. Sub Program Funktionen, Prozeduren Objekte Im Netzwerk Die Evolution der Programmierung Quelle: HaraldOrlamünder
LAN and WAN Internet nichtobjekt- orientiert objektorientiert RMI Remote MethodInvocation JAVA-Way In Sun‘s NFS: CORBA Common ObjectRequest BrokerArchitecture Format: RPCRemoteProcedureCall Web- Service SOAPSimple ObjectAccess Protocol Format: IDLInterface Definition Language Based on: Format: Microsoft-Way XML eXtended Markup Language Transported via: XDR eXternal DataRepresentation HTTP,SMTP, ..... DCOMDistributed ComponentObject Model Unabhängig von Betriebssystem und Sprache Zeit VerteilteProgrammierung Quelle: HaraldOrlamünder
Client Server Client Application Server Objects IDL Stub IDL Skeleton Messages Interface and Implementation repositories CORBA Common Request Broker Architecture Client und Server mit unterschiedlichen Betriebssystemen und Sprachen
Client Server 1 KontextAnfrage System A 3 System B Service Anfrage 2 Rekonstruktion der Service Anfrage(Client-Stub) aus derKontext-Definition EinandererAnsatz Rekonstruktion des Clients ausformalerKontext-Definition Kontext-Definition
Client Server KontextAnfrage: get WSDL 1 Server Objektpublizieren Dynamic WSDL 0 Server- Object 2 3 Proxy- Objekt WS - Server Service Aufruf (Service Invocation) JRE xRE Rekonstruction des Client Proxy- ObjektsausWSDL (Kontext) durcheinWerkzeug (z.B. WSDL2Java) 2 Beispiel: Java Client ausKontext WSDL: Web Service Description Language JRE: Java Runtime Environment xRE: x-beliebige Laufzeitumgebung
Verzeichnis UDDI find publish InformationenübereinenDienstsuchen = „Broker“ Informationen (Meta-Daten) überDienstangebotpublizieren SOAP SOAP Dienstbeschreibung (Kontext)) Web ServiceUser Web Service Provider WSDL SOAP bind = „Provider“ = „Requester“ application of a service Web-Service Komponenten LiefertReferenzen (Zeiger) fürDienste (vgl. “GelbeSeiten” Quelle: HaraldOrlamünder
Dienst-beschreibung Format WSDL Web ServicesDescriptionLanguage Based on: XML eXtended Markup Language Dienst-verzeichnis transported over: HTTP,SMTP, ..... UDDIUniversal Description Discovery and Integration Dienstverzeichnis (UDDI) Dienst = Web-Service White PagesGeneral information about the organisation offering the service Yellow PagesInformation sorted by certain criteria UDDI lieferteinenZeiger (URL) auf die WSDL-Beschreibung des Dienstes Green PagesMethods and Parameters valid for the service Quelle: HaraldOrlamünder
Inhalt Protokolle und Datenmodelle • IP basierende Netze • Voice over IP • SIP Happens • Service Orientierte Architekturen • Die Zukunft der Netze
Gerät HW FW SW Benutzerprofile und Geräteprofile Beschreiben Anwendungen und Anwendungsgebiete Benutzerprofil • z.B. Mobilfunkkunde • Nutzer und beanspruchte Dienste Geräteprofil • dem Benutzerprofil assoziiert • beschreibt Gerät, Hersteller, Hardware und Softwarestand Außerdem: • Kennzeichnungssysteme • Semantische Daten • Metadaten: Ort, Zugriff, Dienstbeschreibung Nutzer Geräte
ErweitertesReferenzmodell Warum? Wozu? – Sinn, Zweck, Nutzen Layer 9 Philosophical Was? - Kennzeichnungssystem, Datenmodelle, Werkzeuge Semantics Layer 8 Application Telefonieren, VoIP, SMS, E-Mail, Web, … Layer 7 Presentation Session Layer 4 Ende-zu-EndeVerbindung, Socket, … Transport Adressraum, Paketzustellung, … Layer 3 Network Layer 2 Frames, Prüfsummen, … Link Layer 1 Hardware, Modulation, … Physical
Nutzer und Geräte Meta-Information (Dienstverzeichnis, Dienstzugriff) Semantisches Modell (Domain Model) Identitäts-Manager Geräte & Software (Hersteller, ASP) Service Verzeichnisdienste InfrastrukturfürneueDienstangebote NeueNetzinfrastruktur Neue Dienstangebote ASP: Application Service Provider (Cloud etc)
RollenfürDienstleistungen Verteilung der Rollen • Nutzer: verwendet Geräte und nimmt Dienstleistungen in Anspruch (Vertragspartner z.B. für Konfigurationsmanagement) • Identity Provider: überprüft Identitäten (Ist dieses Gerät bei diesem Kunden eingetragen?, Ist dieser Servicetechniker authorisiert?, Passt diese Software auf das Gerät?, ...) • Gerätehersteller bzw. ASP: Pflege von Softwareständen für Geräte und ggf. Remote Configuration bzw. Remote Updates • Service: vertragliche Betreuung des Kunden und ggf. Leistungen vor Ort Benötigt werden • ein gültiges Kennzeichnungssystem • neue Netzinfrastruktur (Inventories, Authentisierung, Sicherheit).
Meta-Information und Semantik Meta-Information: • Wo findet sich was? • Wie lassen sich Informationen abfragen? • z.B. Web-Services (UDDI/Inventory und WSDL) Semantische Modelle: Information wird sichtbar (vorher in Anwendungen eingeschlossen) • Wer benutzt Information? • Was wird benötigt? • Wie wird Information benutzt? • Welche Begriffe werden verwendet? Ermöglicht Design zusammen mit dem Kunden • Welche Datenbestände werden verwendet und wie kombiniert? • Wie werden Ergebnisse abgelegt und dargestellt?
NutzeneinesReferenz-Datenmodells Anwendung 1 Gerät1 Referenz- Datenmodell Editor Netzwerk nachIndustriestandardbzw. herstellerspezifisch Gerät 2 Anwendung 2 GerätemitDatennachReferenzmodell
Schematransformation Gerätespezifische Modelle werden auf das Referenzschema abgebildet Referenz- Datenmodell gerätespezifischesDatenmodell Design-Tool Schema für die Transformation
CORBA Protokolle Protokolldaten Beispiel Datenmodelle und Schema-Transformationen flexibel anpassen internesdynamisches Datanmodell RegelnzurKonvertierung der Datenmodelle Data Handler Data Base Servers Semantic Engine Design Tool Protocol Handler ReferenzDatenmodell WS, SOAP LDAP other … Video mail GUI OSS HLR MMS Administration Anwendungen
Technik der digitalen Netze • ENDE Teil6 – Protokolle und Datenmodelle