Home About us Products Services Contact us Bookmark
:: wikimiki.org ::
SIGTRAN

SIGTRAN

Das Stream Control Transmission Protocol (SCTP) wurde von der Internet engineering task force (IETF) als neues Transportprotokoll vorgeschlagen und im Oktober 2000 in RFC 2960 veröffentlicht. Eine Einführung findet sich auch in RFC 3286. Das zuständige Gremium bei der IETF ist die Arbeitsgruppe Signaling Transport, kurz SIGTRAN[http://www.ietf.org/html.charters/sigtran-charter.html]. Als Transportprotokoll steht SCTP auf der selben Stufe des OSI-Referenzmodell wie TCP und UDP (Layer 4). SCTP realisiert das Konzept einer Association: Hier wird eine Verbindung aufgebaut, in der mehrere Byte-Streams in sich reihenfolgenerhaltend (untereinander aber potentiell nicht-reihenfolgenerhaltend) transportiert werden. Zusätzlich können einzelne, z.B. dringende, Datagramme separat und out-of-order verschickt werden, die dadurch eventuell die in-order Datenströme "überholen". SCTP kennt außerdem Multistreaming und Multihoming (ein Host mit mehreren gültigen IP Adressen). Es werden Heartbeats verwendet, um aktiv auf Verbindungsabriss zu testen. Anders als TCP zeigt sich SCTP resistent gegen SYN-Flooding, eine Denial of Service-Attacke bei der durch halboffene Verbindungen die Resourcen des Servers aufgebraucht werden. Dazu verwendet es einen sogenannten Vier-Wege-Handshake. Hierbei speichert der Server bei einer Verbindungsanfrage (INIT-Paket) keine Zustandsinformationen, sondern schickt diese in Form eines Cookies (INIT-ACK-Paket) an den Client. Der Client muss dieses Cookie in seine Antwort (COOKIE-ECHO-Paket) einfügen und wird damit vom Server als zum Verbindungsaufbau berechtigt erkannt, was dieser ihm bestätigt (COOKIE-ACK-Paket). Ursprünglich wurde SCTP als Transportprotokoll definiert, um Zeichengabenachrichten (SS7) aus Telefonnetzen auch über IP-Netzwerke übertragen zu können. Bei der Entwicklung stand insbesondere die Zuverlässigkeit des Protokolls im Vordergrund. SCTP scheint sich aber auch für andere Anwendungen zu eignen, da es Vorteile von TCP und UDP vereint. SCTP verwendet für Fluss- und Überlastkontrolle ähnliche Algorithmen wie TCP, verhält sich also in einem gemischten Netz (SCTP und TCP) neutral [http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/atm2000.pdf].

Weblinks


- http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb, "SCTP for Beginners"
- RFC 2960
- RFC 3286
- http://www.sctp.de
- http://www.sctp.be
- http://www.openss7.org Kategorie:Netzwerkprotokoll

IETF

Die Internet Engineering Task Force (IETF) ist neben der Internet Research Task Force (IRTF) eine von zwei Arbeitsgruppen des Internet Architecture Board (IAB). Ihr Auftrag ist die Entwicklung und Förderung von Internetstandards, insbesondere die der TCP/IP-Familie. Im Gegensatz zur IRTF kümmert sie sich mehr um die kurzfristige Entwicklung des Internets. Sie ist eine offene, internationale Freiwilligenvereinigung von Netzwerktechnikern, Herstellern und Anwendern, die für Vorschläge zur Standardisierung des Internets zuständig ist. Es existiert keine förmliche Mitgliedschaft oder Mitgliedsvoraussetzung. Die IETF besteht aus einer großen Zahl Arbeitsgruppen, von denen sich jede mit einem spezifischen Thema befasst und beabsichtigt, die Arbeit an diesem Thema zu beenden und sich dann aufzulösen. Jede Arbeitsgruppe hat einen ernannten Vorsitzenden (oder manchmal mehrere Co-Vorsitzende), sowie eine Charta die das Ziel formuliert und was wann produziert wird. Die Arbeitsgruppen sind nach Themengebiet in Bereiche (Areas) gegliedert; jeder Bereich wird von einem Area Director (AD) (die meisten Bereiche haben zwei Co-ADs) betreut; die ADs ernennen die Vorsitzenden der Arbeitsgruppen. Die Area Directors bilden zusammen mit dem IETF-Vorsitzenden die Internet Engineering Steering Group (IESG), die für den Gesamtbetrieb der IETF verantwortlich ist. Die IETF ist formell unter dem Schirm der Internet Society tätig. Das Internet Architecture Board (IAB) betreut die externen Beziehungen des IETF sowie die zum RFC Editor. Die IAB ist gemeinschaftlich verantwortlich für das IETF Administrative Oversight Committee (IAOC), welches die IETF Administrative Support Activity (IASA) betreut, welches die Logistik des IETF unterstützt. Das IAB managt auch die Internet Research Task Force (IRTF) mit dem die IETF einige gruppenübergreifende Beziehungen hat.

Bereiche

Zurzeit gliedert sich die IETF in 7 Bereiche: # Anwendungen (APP) # Allgemein # Internet-Dienste (INT) # Betrieb (OPS) # Routing (RTG) # Sicherheit # Transportdienste (TSV)

Geschichte

Die IETF begann im Januar 1986 mit einem vierteljährlichen Treffen von der US-Regierung bezahlter Forscher. Beginnend mit dem vierten IETF-Meetings im Oktober dieses Jahres wurden auch Vertreter Nicht-Regierungszulieferer eingeladen. Seit dieser Zeit waren alle IETF-Meetings für jeden offen. Der Großteil der Arbeit der IETF erfolgt jedoch über Mailinglisten und die Teilnahme an den Meetings ist für die Mitwirkenden deshalb nicht nötig. Die anfänglichen Meetings waren sehr klein, mit weniger je als 35 Anwesenden bei den ersten fünf und einem Maximum von 120 Anwesenden, beim 12. Meeting im Januar 1989, bei den ersten 13 Meetings. Seit Anfang der 1990er wuchsen die Meetings sowohl in Teilnahme als auch Geltungsbereich stark; die Spitzenbesucheranzahl lag bei 3000 im Juli 2000 IETF in San Diego. Mit den Restrukturierungen in der Industrie in den frühen 2000ern nahm die Besucherzahl wieder ab und liegt momentan bei um die 1500. Während der frühen 1990er wechselte die institutionelle Form von einer Aktivität der US-Regierung zu einer unabhängigen, internationalen mit der Internet Society verbundenen. Der IETF wurden von der Fachpresse hin- und wieder schon nahezu magische Fähigkeiten zugeschrieben, da sie annahmen sie sei durch ihre Arbeit an den Kernprotokollen für den Erfolg des Internet verantwortlich. Die Wahrheit, dass die sie eine Gruppe von Technikern ist die Spezifikationen erarbeiten damit die Produkte verschiedener Hersteller über Netzwerke zusammenarbeiten können, ist wesentlich nüchterner. Im Detail haben sich die Tätigkeiten während des Wachstums der IETF um einiges verändert, aber der grundsätzliche Mechanismus bleibt die Veröffentlichung von Spezifikationsentwürfen, Review und unabhängiges Testen durch die Beteiligten und Wiederveröffentlichung. Interoperabilität ist der Haupttest für IETF-Spezifikationen die Standards werden wollen. Die meisten Spezifikationen konzentrieren sich eher auf einzelne Protokolle als auf eng ineinander greifende Systeme. Dies hat es erlaubt, dass ihre Protokolle in vielen verschiedenen Systemen verwendet werden und ihre Standards routinemäßig von Institutionen wiederverwendet werden wenn es um die Entwicklung vollständiger Architekturen geht (z.B. 3GPP IMS). Da die IETF sich auf Freiwillige verlässt und „Konsens sowie lauffähigen Code“ als Prüfstein verwendet, kann sie jedoch auch langsam sein wenn die Anzahl Freiwilliger entweder zu niedrig ist um einen Fortschritt zu machen oder so groß dass ein Konsens schwierig ist. Für Protokolle wie SMTP, das für den Transport von e-Mail für eine Gemeinschaft die nach Millionen zählt zuständig ist, gibt es auch beträchtlichen Widerstand bei jeder Änderung die nicht hundertprozentig abwärtskompatibel sind. An Wegen die Arbeitsgeschwindigkeit zu erhöhen wird innerhalb der IETF gearbeitet – da es jedoch ob der großen Anzahl Freiwilliger viele Meinungen darüber gibt, bremsen die Konsensmechanismen diese Bestrebungen selbst. Eine Einführung in die IETF findet sich im RFC The Tao of IETF – A Novice's Guide to the Internet Engineering Task Force RFC 3160.

Weblinks


- http://www.ietf.org/ Kategorie:Netzwerkprotokoll Kategorie:Internet-Organisation Kategorie:Normungsorganisation Kategorie:Standard ja:Internet Engineering Task Force ko:IETF

TCP/IP-Referenzmodell

Zur Gliederung der Kommunikationsaufgaben werden in Netzwerken funktionale Ebenen, so genannte Schichten, unterschieden. Für die Internet-Protokoll-Familie ist dabei das TCP/IP-Referenzmodell maßgebend. Es beschreibt den Aufbau und das Zusammenwirken der Netzwerkprotokolle aus der Internet-Protokoll-Familie und gliedert sie in vier aufeinander aufbauende Schichten. Man spricht daher auch von einem Protokollstapel (protocol stack). Das TCP/IP-Referenzmodell ist auf die Internet-Protokolle zugeschnitten, die den Datenaustausch über die Grenzen lokaler Netzwerke hinaus ermöglichen („Internetworking“). Es wird weder der Zugriff auf ein Übertragungsmedium noch die Datenübertragungstechnik definiert. Die Internet-Protokolle sind vielmehr dafür zuständig, Datenpakete über mehrere Punkt-zu-Punkt-Verbindungen (Hops) weiterzuvermitteln und auf dieser Basis Verbindungen zwischen Netzwerkteilnehmern über mehrere Hops herzustellen. Um Probleme der Netzwerkkommunikation im Allgemeinen zu betrachten, greift man stattdessen auf das ISO/OSI-Referenzmodell zurück.
Die einzelnen Schichten erfüllen folgende Funktionen:
- Anwendungsschicht: Die Anwendungsschicht umfasst alle Protokolle, die mit Anwendungsprogrammen zusammenarbeiten und die Netzwerkinfrastruktur für den Austausch anwendungsspezifischer Daten nutzen.
- Transportschicht: Die Transportschicht stellt eine Ende-zu-Ende Verbindung her. Das wichtigste Protokoll dieser Schicht ist das Transmission Control Protocol (TCP), das Verbindungen zwischen jeweils zwei Netzwerkteilnehmern zum gesicherten Versenden von Datenströmen herstellt.
- Internetschicht: Die Internetschicht ist für die Weitervermittlung von Paketen und die Wegewahl (Routing) zuständig. Auf dieser Schicht und den darunterliegenden Schichten werden Punkt-zu-Punkt-Verbindungen betrachtet. Die Aufgabe dieser Schicht ist es, zu einem empfangenen Paket das nächste Zwischenziel zu ermitteln und das Paket dorthin weiterzuleiten. Kern dieser Schicht ist das Internet Protocol (IP), das einen unzuverlässigen, verbindungslosen Paketauslieferungsdienst bereitstellt. Die Internetschicht entspricht im ISO/OSI-Referenzmodell der Vermittlungsschicht.
- Netzzugangsschicht: Die Netzwerkschicht ist im TCP/IP-Referenzmodell spezifiziert, enthält jedoch keine Protokolle der TCP/IP-Familie. Sie ist vielmehr als Platzhalter für verschiedene Techniken zur Datenübertragung von Punkt zu Punkt zu verstehen. Die Internet-Protokolle wurden mit dem Ziel entwickelt, verschiedene Subnetze zusammenzuschließen. Daher kann die Host-an-Netz-Schicht durch Protokolle wie Ethernet, FDDI oder PPP übers Telefonnetz ausgefüllt werden. Die Netzzugangsschicht entspricht im ISO/OSI-Referenzmodell der Sicherungs- und Bitübertragungsschicht.

Weblinks


- RFC 1122 - Requirements for Internet Hosts – Communication Layers Kategorie:Netzwerkprotokoll

Transmission Control Protocol

Das Transmission Control Protocol (TCP) ist eine Vereinbarung (Protokoll) darüber, auf welche Art und Weise Daten zwischen Computern ausgetauscht werden sollen. Alle am Datenaustausch beteiligten Computer kennen diese Vereinbarungen und befolgen sie. Es ist damit ein zuverlässiges, verbindungsorientiertes Transportprotokoll in Computernetzwerken. Es ist Teil der TCP/IP-Protokollfamilie. Entwickelt wurde TCP von Robert E. Kahn und Vinton G. Cerf. Ihre Forschungsarbeit, die sie im Jahre 1973 begannen, dauerte mehrere Jahre. Die erste Standardisierung von TCP erfolgte deshalb erst im Jahre 1981 als RFC 793. TCP stellt einen virtuellen Kanal zwischen zwei Endpunkten einer Netzwerkverbindung (Sockets) her. Auf diesem Kanal können in beide Richtungen Daten übertragen werden. TCP setzt in den meisten Fällen auf das IP (Internet-Protokoll) auf. Es ist in Schicht 4 des OSI-Referenzmodells angesiedelt.

Verbindungsaufbau und Abbau

OSI-Referenzmodell OSI-Referenzmodell OSI-Referenzmodell OSI-Referenzmodell TCP ist im Prinzip eine Punkt-zu-Punkt-Verbindung in Vollduplex. Diese Verbindung kann in zwei Halbduplex-Verbindungen eingeteilt werden, wobei die Daten in Gegenrichtung zusätzliche Steuerungsinformationen enthalten. Das Management dieser Verbindung sowie die Datenübertragung wird von der TCP-Software übernommen, siehe Abb. 1. Die TCP-Software ist eine Funktionssammlung, zum Beispiel bei Windows in der Winsock.dll beziehungsweise wsock32.dll oder bei Linux im Kernel (je nach Betriebssystem unterschiedlich). Die Anwendung ist zum Beispiel ein Webbrowser oder ein Webserver (zum Beispiel Apache). Jeder Endpunkt stellt ein Tupel bestehend aus IP-Adresse und Port dar. Ports sind 16-Bit-Zahlen und reichen von 0 bis 65535. Ports von 0 bis 1023 sind reserviert (englisch: well known ports [http://www.iana.org/assignments/port-numbers]) und werden von der IANA vergeben, z. B. ist Port 80 für das HTTP-Protokoll reserviert. Allerdings ist das Benutzen der vordefinierten Ports trotzdem nicht bindend. So kann jeder Administrator einen FTP-Server (normalerweise Port 21) auch auf einem anderen Port laufen lassen. Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte definiert. So ist es beispielsweise möglich, dass ein Webserver auf einem Port mehr als eine Verbindung zu einem anderen Rechner geöffnet haben kann. Ein Webserver, der seinen Dienst anbietet, generiert einen Endpunkt mit dem Port und seiner Adresse (er kann auch beliebige Adressen zulassen). Dies wird als passive open bezeichnet. Will ein Client eine Verbindung aufbauen, generiert er einen eigenen Endpunkt aus seiner Rechneradresse und einer noch freien Portnummer. Mit Hilfe eines ihm bekannten Ports und der Adresse des Servers kann dann eine Verbindung aufgebaut werden. Während der Datenübertragungsphase (active open) sind die Rollen von Client und Server (aus TCP-Sicht) vollkommen symmetrisch. Insbesondere kann jeder der beiden beteiligten Rechner einen Verbindungsabbau einleiten. Während des Abbaus kann die Gegenseite noch Daten übertragen, die Verbindung kann also halb-offen sein.

Der Drei-Wege-Handshake

Beim Aufbau einer TCP-Verbindung kommt der so genannte Drei-Wege-Handshake zum Einsatz. Der Rechner, der die Verbindung initiieren will, sendet dem anderen ein SYN-Paket mit einer Sequenznummer x. Es handelt sich also um ein Paket, dessen SYN-Bit im Paketkopf gesetzt ist (siehe TCP-Header). Die initiale Sequenznummer ist beliebig und wird vom jeweiligen Betriebssystem festgelegt. Die Gegenstelle (siehe Skizze) empfängt das Paket und sendet in einem eigenen syn-Paket im Gegenzug seine initiale Sequenznummer y, zugleich bestätigt sie den Erhalt des ersten SYN-Pakets, indem sie die Sequenznummer inkrementiert und x+1 im ACK-Teil des Headers zurückschickt. Der Client bestätigt zuletzt den Erhalt des SYN/ACK-Pakets durch das Senden eines eigenen ACK-Pakets mit der Sequenznummer x+1 und dem ACK-Wert y+1. Die Verbindung ist damit aufgebaut.    1.    SYN-SENT        -->                                -->  SYN-RECEIVED
   2.    ESTABLISHED  <--      <--  SYN-RECEIVED
   3.    ESTABLISHED  -->                -->  ESTABLISHED
Der geregelte Verbindungsabbau erfolgt ähnlich. Statt des SYN-Bits kommt das FIN-Bit zum Einsatz. Der Erhalt des Pakets wird wiederum mittels ACK bestätigt. Der Empfänger des FIN-Pakets sendet zuletzt seinerseits ein FIN-Paket, das ihm ebenfalls bestätigt wird. Obwohl eigentlich vier Wege genutzt werden, handelt es sich beim Verbindungsabbau auch um einen Drei-Wege-Handshake, da die ACK- und FIN-Operationen vom Server zum Client als ein Weg gewertet werden. Zudem ist ein verkürztes Verfahren möglich, bei dem FIN und ACK genau wie beim Verbindungsaufbau im selben Paket untergebracht werden.

Aufbau des TCP-Headers

Betriebssystem Das TCP-Segment besteht immer aus zwei Teilen â€“ dem Header und der Nutzlast (Payload). Die Nutzlast enthält die zu übertragenden Daten, die wiederum Protokollinformationen der Anwendungsschicht wie HTTP oder FTP entsprechen können. Den schematischen Aufbau des TCP-Headers kann man im Bild rechts sehen. Die Werte werden in network byte order (big endian) angegeben.

Erläuterung

Source Port:
Gibt die Portnummer auf der Senderseite an. Destination Port:
Gibt die Portnummer auf der Empfängerseite an. Sequence Number:
Sequenznummer des ersten Daten-Oktetts (Byte) dieses TCP-Paketes oder die Initialisierungs-Sequenznummer falls das SYN-Flag gesetzt ist. Nach der Datenübertragung dient sie zur Sortierung der TCP-Segmente, da diese in unterschiedlicher Reihenfolge beim Empfänger ankommen können. Acknowledgment Number (Quittierungsnummer):
Sie gibt die Sequenznummer an, die der Sender dieses TCP-Segmentes als nächstes erwartet. Nur gültig, falls das ACK-Flag gesetzt ist. Data Offset:
Länge des TCP-Headers in 32-Bit-Blöcken - ohne die Nutzdaten (Payload). Indiziert die Startadresse der Nutzdaten. Reserved:
Das Reserved-Feld wird nicht verwendet und muss null sein. Flags: URG: Ist das Urgent-Flag gesetzt, so werden die Daten auf die das Urgent Pointer-Feld zeigt sofort von der Anwendung bearbeitet. Dabei unterbricht die Anwendung alle anderen Aufgaben. Dieses Verfahren ist fern verwandt mit einem Softwareinterrupt. Dieses Flag kann zum Beispiel verwendet werden, um eine Anwendung auf dem Empfänger abzubrechen. ACK: Das Acknowledgment-Flag hat in Verbindung mit dem Acknowledgment-Feld folgende Aufgaben. Einmal dient es in Verbindung mit dem ACK- und SYN-Flag zur Bestätigung beim 3 Way-Handshake und zur Bestätigung von TCP-Segmenten beim Datentransfer. Das Acknowledgment-Feld ist nicht gültig, wenn das Flag nicht gesetzt ist. PSH: Das Push-Flag hat die Aufgabe die Daten unter Umgehung des Buffers sofort an die Anwendung weiterzuleiten. Hilfreich ist dies, wenn man zum Beispiel bei einer Telnet-Sitzung einen Befehl an den Empfänger senden will. Würde dieser Befehl ersteinmal im Buffer zwischengespeichert, so würde dieser erst (stark) verzögert abgearbeitet. RST: Das Reset-Flag wird verwendet, wenn eine Verbindung abgebrochen werden soll. Dies geschieht zum Beispiel bei technischen Problemen oder zur Abweisung von unerwünschten Verbindungen. SYN: Pakete mit gesetztem SYN-Flag initiieren eine Verbindung, d.h. beginnen den 3-Wege-Handshake. Der Server antwortet normalerweise entweder mit SYN+ACK, wenn er bereit ist, die Verbindung anzunehmen, andernfalls mit RST. Dient der Synchronisation von Sequenznummern beim Verbindungsaufbau (daher die Bezeichnung SYN). FIN: Dieses Finish-Flag dient zur Freigabe der Verbindung und zeigt an, dass keine Daten mehr vom Sender kommen. Die FIN- und SYN-Flags haben Sequenznummern, damit diese in der richtigen Reihenfolge abgearbeitet werden. Window:
Ist die Anzahl der Daten-Oktetts (Bytes), beginnend bei dem durch das Acknowledgmentfeld indizierten Daten-Oktett, die der Sender dieses TCP-Paketes bereit ist zu empfangen. Checksum:
Die Prüfsumme dient zur Erkennung von Übertragungsfehlern und wird über den Header und die Daten berechnet. Urgent Pointer:
Ist ein Zeiger auf das Ende einer Sequenz mit dringenden Daten. Den Anfang der Sequenz muss die Anwendung selbst ermitteln. Der Pointer ist nur gültig, falls das URG-Bit gesetzt ist. Options:
Das Options-Feld ist unterschiedlich groß und enthält Zusatzinformationen. Die Optionen müssen ein Vielfaches von 32 Bit lang sein. Sind sie das nicht, muss mit Null-Bits aufgefüllt werden (Padding). Dieses Feld gibt die Möglichkeit Verbindungsdaten auszuhandeln, die nicht im TCP-Header enthalten sind. Wie zum Beispiel die Maximalgröße des Nutzdatenfeldes.

Datenübertragung

Prüfsumme Über ein TCP-Segment können maximal 65495 Byte Nutzdaten bei darunterliegendem IPv4 und 65515 Byte bei IPv6 versandt werden. Dies errechnet sich so: In das IPv4-Paket passen maximal 65515 Byte Nutzdaten (65535 Byte abzüglich 20 Byte IP-Header). In ein IPv6-Paket passen maximal 65535 Byte Nutzdaten. Von diesem Wert müssen noch 20 Byte für den TCP-Header abgezogen werden. In der Praxis ist das Nutzdatenfeld kleiner. Bei Ethernet darf das Nutzdatenfeld zum Beispiel nur maximal 1500 Byte groß sein, deshalb kann ein TCP-Segment nur maximal 1460 Byte (Maximum Segment Size MSS) transportieren (1500 Byte - 20 Byte - 20 Byte). Empfänger und Sender einigen sich vor dem Datenaustausch über das Options-Feld auf die Größe der MSS. Die Anwendung, die Daten versenden möchte, beispielsweise ein Webserver, legt zum Beispiel einen 10 Kilobyte großen Datenblock im Buffer ab. Wie kann man mit einem 1460 Byte großen Nutzdatenfeld 10 Kilobyte Daten versenden? Ganz einfach, man teilt die Daten auf (Segmentierung), fügt einen TCP-Header hinzu und versendet die TCP-Segmente. Im Buffer ist der Datenblock, dieser wird in 5 Segmente aufgeteilt (siehe Abb. 6). Jedes Segment erhält durch die TCP-Software einen TCP-Header. 3 TCP-Segmente wurden aktuell abgeschickt. Diese sind nicht geordnet, da im Internet jedes TCP-Segment einen anderen Weg nehmen und es dadurch zu Verzögerungen kommen kann. Damit die TCP-Software im Empfänger die Segmente wieder ordnen kann, ist jedes Byte "nummeriert" (die Bytes werden sozusagen gezählt). Bei der Zuordnung der Segmente wird die Sequenznummer herangezogen. Der Empfänger muss TCP-Segmente, die einwandfrei (Checksumme ist in Ordnung) angekommen sind, bestätigen. Maximum Segment Size Der Sender schickt sein erstes TCP-Segment mit einer Sequenznummer SEQ=1 (variiert) und einer Nutzdatenlänge von 1460 Byte an den Empfänger. Der Empfänger bestätigt es mit einem TCP-Header ohne Daten mit ACK=1461 und fordert damit das zweite TCP-Segment ab dem Byte Nummer 1461 beim Sender an. Dieser schickt es dann mit einem TCP-Segment und SEQ=1461 an den Empfänger. Dieser bestätigt es wieder mit einem ACK=2921 und so weiter. Der Empfänger braucht nicht jedes TCP-Segment zu bestätigen, wenn diese zusammenhängend sind. Empfängt er die TCP-Segmente 1,2,3,4,5 so braucht er nur das letzte TCP-Segment zu bestätigen. Fehlt zum Beispiel das TCP-Segment 3 weil es verloren gegangen ist, so kann er nur die 1 und die 2 bestätigen 4 und 5 jedoch noch nicht. Da der Sender keine Bestätigung für die 3 bekommt läuft sein Timer ab und er verschickt die 3 noch einmal. Kommt die 3 beim Empfänger an, so bestätigt er alle 5 TCP-Segmente. Der Sender startet für jedes TCP-Segment, welches er auf die Reise schickt einen Timer (RTT).

Flusssteuerung

RTT Da die Anwendung Daten aus dem Buffer liest, ändert sich der Füllstand des Buffers ständig. Deshalb ist es notwendig den Datenfluss entsprechend dem Füllstand zu steuern. Dies geschieht mit dem Sliding Window und dessen Größe. Den Buffer des Senders erweitern wir, wie in Abb. 8 zu sehen, auf 10 Segmente. In der Abb. 8a werden gerade die Segmente 1-5 übertragen. Die Übertragung ist vergleichbar mit Abb. 7. Obwohl der Buffer des Empfängers in Abb. 7 am Ende voll ist, fordert er mit ACK=7301 die nächsten Daten ab dem Byte 7301 beim Sender an. Dies hat zur Folge, dass das nächste TCP-Segment vom Empfänger nicht mehr verarbeitet werden kann. Ausnahme sind jedoch TCP-Segmente mit gesetztem URG-Flag. Mit dem Window-Feld kann er dem Sender mitteilen, dass er keine Daten mehr verschicken soll. Dies geschieht indem er im Window-Feld den Wert Null einträgt (Zero Window). Der Wert Null entspricht dem freien Speicherplatz im Buffer. Die Anwendung des Empfängers liest nun die Segmente 1-5 aus dem Buffer, womit wieder ein Speicherplatz von 7300 Byte frei ist. Damit kann er die restlichen Segmente 6-10 mit einem TCP-Header, der die Werte SEQ=1, ACK=7301 und Window=7300 enthält, beim Sender anfordern. Der Sender weiß nun, dass er maximal 5 TCP-Segmente an den Empfänger schicken kann und verschiebt das Window um 5 Segmente nach rechts (siehe Abb. 8b). Die Segmente 6-10 werden nun alle zusammen als Burst verschickt. Kommen alle TCP-Segmente beim Empfänger an, so quittiert er sie mit SEQ=1 und ACK=14301 und fordert die nächsten Daten an. Silly Window Syndrome: Der Empfänger sendet ein Zero Window an den Sender, da sein Buffer voll ist. Die Anwendung beim Empfänger liest allerdings nur zwei Byte aus dem Buffer. Der Empfänger schickt ein TCP-Header mit Window=2 (Window Update) an den Sender und fordert gleichzeitig die zwei Byte an. Der Sender kommt der Aufforderung nach und schickt die zwei Byte in einem 42 Byte großem Paket (mit IP-Header und TCP-Header) an den Empfänger. Damit ist der Buffer des Empfängers wieder voll und er schickt wieder ein Zero Window an den Sender. Die Anwendung liest jetzt zum Beispiel hundert Byte aus dem Buffer. Der Empfänger schickt wieder ein TCP-Header mit einem kleinem Window-Wert an den Sender. Dieses Spiel setzt sich immer wieder fort und verschwendet Bandbreite, da nur sehr kleine Pakete versandt werden. Clarks Lösung ist, dass der Empfänger ein Zero Window senden und solange mit dem Window Update warten soll bis die Anwendung mindestens die Maximum Segmentsize (in unserem bisherigen Beispielen 1460 Byte) aus dem Buffer gelesen hat oder der Buffer halbleer ist. Je nachdem was zuerst eintritt (Dave Clark, 1982). Auch der Sender kann zu kleine Pakete abschicken und dadurch Bandbreite verschwenden. Dieser Umstand wird mit dem Nagle-Algorithmus beseitigt. Deswegen ergänzt er sich mit Clarks Lösung.

Aufbau und Funktion des TCP Pseudo-Headers

Der Pseudo-Header wird zur Checksummenberechnung verwendet und dient daher zur Erhöhung der Zuverlässigkeit. Es ist dadurch auch möglich fehlgeleitete Pakete zu erkennen. In die Berechnung fließen außerdem noch der TCP-Header und seine Nutzdaten (TCP-Segment) ein. Bevor die TCP-Software ein TCP-Segment abschickt bildet sie einen Pseudo-Header aus der IP-Adresse des Senders und des Empfängers, sowie der TCP-Segment-Länge. Vor Berechnung der Checksumme wird das Checksummen-Feld im TCP-Header auf Null gesetzt und es wird dem Nutzdatenfeld ein Null-Byte angehängt, wenn die Länge eine ungerade Zahl ist. Die Berechnung der Checksumme erfolgt durch Addition von 16 Bit-Werten im Einerkomplement. Aus der Summe wird nocheinmal das Einerkomplement gebildet. Nach der Berechnung wird das 16 Bit-Ergebnis im TCP-Header abgelegt und das TCP-Segment abgeschickt. Der Empfänger führt diese Berechnung nocheinmal unter Einbezug der Checksumme aus, wodurch das Ergebnis Null sein sollte. Ist die Checksumme beim Empfang des TCP-Segmentes nicht Null, so wird es ohne Nachricht verworfen. Dies hat zur Folge, dass der RTT-Timer beim Absender abläuft und das TCP-Segment nochmal abgeschickt wird. Einerkomplement Source IP Address: IP-Adresse des Absenders. Destination IP Address: IP-Adresse des Empfängers. 000000: Füllbits. Protocol: Hat immer den Wert Sechs für das TCP-Protokoll (siehe auch IP-Header). TCP Length: Länge des TCP-Segments in Bytes.

Datenintegrität und Zuverlässigkeit

Im Gegensatz zum verbindungslosen UDP implementiert TCP einen bidirektionalen, byte-orientierten, zuverlässigen Datenstrom zwischen zwei Endpunkten. Das darunterliegende Protokoll (IP) ist paketorientiert, wobei Datenpakete verlorengehen können, in verkehrter Reihenfolge ankommen dürfen und sogar doppelt empfangen werden können. TCP wurde entwickelt, um mit der Unsicherheit der darunter liegenden Schichten umzugehen. Es prüft daher die Integrität der Daten mittels der Prüfsumme im Paketkopf und stellt die Reihenfolge durch Sequenznummern sicher. Der Sender wiederholt das Senden von Paketen, falls keine Bestätigung innerhalb einer bestimmten Zeitspanne (Timeout) eintrifft. Die Daten der Pakete werden beim Empfänger in einem Puffer in der richtigen Reihenfolge zu einem Datenstrom zusammengefügt und doppelte Pakete verworfen. Zu beachten ist, dass der Sender mittels TCP lediglich zuverlässig erfahren kann, ob der Empfang von Daten vom Empfänger korrekt quittiert wurde oder nicht. Der Datentransfer kann selbstverständlich jederzeit nach dem "Aufbau einer Verbindung" gestört, verzögert oder ganz unterbrochen werden. Das Übertragungssystem läuft dann in einen Timeout. Der vorab getätigte "Verbindungsaufbau" stellt also keinerlei Gewähr für eine nachfolgende sichere Übertragung dar.

Bestätigungen

Die jeweilige Länge des Puffers, bis zu der keine Lücke im Datenstrom existiert, wird bestätigt (Windowing). Dadurch ist die Ausnutzung der Netzwerk-Bandbreite auch bei großen Strecken möglich. Bei einer Übersee- oder Satellitenverbindung dauert das Eintreffen des ersten Acknowledges (ACK) aus technischen Gründen bisweilen mehrere 100 ms, in dieser Zeit können unter Umständen mehrere hundert Pakete gesendet werden. Der Sender kann den Empfängerpuffer füllen, bevor die erste Bestätigung eintrifft. Alle Pakete im Puffer können gemeinsam bestätigt werden. Bestätigungen können zusätzlich zu den Daten in den TCP-Header des entgegengesetzten Datenstroms eingefügt werden (Piggybacking), falls der Empfänger ebenfalls Daten für den Sender bereithält.

Weitere Protokolleigenschaften

Über ein Dringlichkeitsbit (Urgent) können Daten als vorrangig gekennzeichnet werden. Dadurch ist beispielsweise die bevorzugte Behandlung von CTRL-C (Abbruch) bei einer Terminalverbindung (TELNET) möglich. Um Bandbreite zu sparen, wird auf der TCP Ebene meistens der Nagle-Algorithmus eingesetzt.

Problematik der Datenwiederholung

Die Wiederholung von Daten, für die noch keine Bestätigung empfangen wurde, ist nicht unproblematisch. Im Internet, in dem viele Netzwerke mit unterschiedlichen Eigenschaften verbunden werden, ist Datenverlust einzelner Pakete durchaus normal. Wird eine Verbindung stark belastet, werden immer mehr Pakete verworfen, die entsprechend wiederholt werden müssen. Durch die Wiederholung steigt wiederum die Belastung, ohne geeignete Maßnahmen kommt es zu einem Datenstau. Die Verlustrate wird von einem IP-Netzwerk ständig beobachtet. Abhängig von der Verlustrate wird die Senderrate durch geeignete Algorithmen beeinflusst: Normalerweise wird eine TCP/IP-Verbindung langsam gestartet (Slow Start) und die Senderate schrittweise erhöht, bis es zum Datenverlust kommt. Ein Datenverlust verringert die Senderate, ohne Verlust wird sie wiederum erhöht. Insgesamt nähert sich die Datenrate so zunächst dem jeweiligen zur Verfügung stehenden Maximum und bleibt im Wesentlichen dann dort. Eine Überbelastung wird vermieden.

Literatur


- Craig Hunt: TCP/IP Netzwerk-Administration. O'Reilly, 2003, ISBN 3-89721-179-3
- Richard Stevens: TCP/IP Illustrated. Volume 1: The Protocols. Addison-Wesley, 1994, ISBN 0-2016-3346-9
- Richard Stevens: TCP/IP Illustrated. Volume 2: The Implementation. Addison-Wesley, 1994, ISBN 0-2016-3354-X
- Andrew S. Tanenbaum: Computernetzwerke. 4. Auflage. Pearson Studium, München 2003, ISBN 3-8273-7046-9 (Der relevante Teil ist ab S. 580ff)
- James F. Kurose, Keith W. Ross: Computernetze. Ein Top-Down-Ansatz mit Schwerpunkt Internet. Bafög-Ausgabe, Pearson Studium, München 2004, ISBN 3-8273-7150-3
- Michael Tischer, Bruno Jennrich: Internet Intern. Technik & Programmierung. Data-Becker, Düsseldorf 1997, ISBN 3-8158-1160-0

Weblinks


- RFC 793 - Transmission Control Protocol
- RFC 1122 - Fehlerbehebungen bei TCP
- RFC 1323 - Erweiterungen bei TCP
- RFC 2001 - TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery - Algorithmen der Flusskontrolle
- [http://citeseer.ist.psu.edu/593307.html Congestion Avoidance and Control] - TCP-Meilenstein 1988
- [http://www.multi-online.com/netzwerk/tcpip.php Netzwerk TCP/IP] - Die TCP/IP-Protokollfamilie
- [http://citeseer.ist.psu.edu/367499.html TCP Vegas] - TCP Meilenstein 1994 Kategorie:Netzwerkprotokoll ja:Transmission Control Protocol ko:TCP

User Datagram Protocol

Das User Datagram Protocol (UDP) ist ein minimales, verbindungsloses Netzprotokoll. Es gehört zur Transportschicht der TCP/IP-Protokollfamilie und ist im Gegensatz zu TCP nicht auf Zuverlässigkeit ausgelegt. UDP erfüllt im Wesentlichen den Zweck, die durch die IP-Schicht hergestellte Endsystemverbindung um eine Anwendungsschnittstelle (Ports) zu erweitern. Diese Erweiterung der Host-zu-Host- auf eine Prozess-zu-Prozess-Übertragung wird als Anwendungsmultiplexen und -demultiplexen bezeichnet. UDP bietet auch eine Integritätsüberprüfung, indem Fehlererkennungsfelder in die Header einbezogen werden.

UDP-Datagramm

Das UDP-Paket wird zur Ãœbertragung in ein IP-Paket gekapselt. Neben dem eigentlichen UDP-Header besitzt das UDP-Datagramm noch einen sog. Pseudo-Header. Dieser Pseudo-Header ist virtuell er wird berechnet und ist nich Teil des Datagramms. gekapselt

Header

Der UDP-Header besteht aus vier Headerfeldern, von denen zwei optional sind. Die Quell- und Ziel-Port Felder sind 16 Bit groß und identifizieren den sendenden und den empfangenden Prozess. Da UDP verbindungslos ist, ist der Quell-Port optional. Er wird dann auf 0 gesetzt. Den Portfeldern folgt das verbindliche Längenfeld, das die Größe der Daten und des Headers des UDP-Datagramms in Oktetten enthält. Der kleinstmögliche Wert sind 8 Oktette. Das letzte Headerfeld ist eine 16 Bit große Prüfsumme über den Header, den so genannten Pseudo-Header und den Daten. Die Prüfsumme ist auch optional, wird aber in der Praxis fast immer benutzt (falls nicht, wird sie ebenfalls auf 0 gesetzt). Dem Header folgen anschließend die Nutzdaten.

Pseudo- Header

Prüfsumme
Für die Erzeugung der UDP-Prüfsumme gibt es den Pseudo-Header. Damit werden Teile des IP-Headers in die UDP-Prüfsumme übernommen. Er dient nur zur Erzeugung der Prüfsumme und wird nicht übertragen. Er hat eine Länge von 12 Byte und setzt sich zusammen aus IP-Quelladresse (32 Bit), IP-Ziel-Adresse (ebenfalls 32 Bit), 8 Bit Leerfeld, 8 Bit Protokoll-ID (UDP hat die ID 17) und der Länge des UDP-Datagramms (16 Bit).

Eigenschaften

Verbindungslos bedeutet, dass nicht erst eine Verbindung zum Gegenüber aufgebaut wird (mittels Handshaking wie bei TCP), sondern dass sofort die Daten zu der Gegenstelle geschickt werden. Es wird nicht garantiert, dass ein einmal gesendetes Paket ankommt oder dass Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden; eine Quittierung ist nicht vorgesehen. Die Kommunikationspartner können also nicht feststellen, ob Pakete verloren gingen oder wie lange sie verzögert wurden (Delay). Auch eine Vervielfältigung von Paketen kann auftreten. Eine Anwendung, die UDP nutzt, muss daher gegenüber verloren gegangenen und umsortierten Paketen unempfindlich sein oder selbst entsprechende Korrekturmaßnahmen beinhalten. Da vor Übertragungsbeginn nicht erst eine Verbindung aufgebaut werden muss, können die Hosts schneller mit dem Datenaustausch beginnen. Dies fällt vor allem bei Anwendungen ins Gewicht, bei denen nur kleine Datenmengen ausgetauscht werden müssen. Ein Beispiel hierzu ist das Domain Name System, das auf UDP aufsetzt: hier werden üblicherweise nur zwei Pakete ausgetauscht, ein Paket mit der Anfrage und eines mit der Antwort. Hierzu erst noch per Drei-Wege-Handshake eine Verbindung aufzubauen würde lediglich Overhead erzeugen. Daneben bietet die ungesicherte Übertragung auch den Vorteil von geringen Übertragungsverzögerungsschwankungen: geht bei einer TCP-Verbindung ein Paket verloren, so muss es erneut angefordert werden. Dies braucht Zeit, die Übertragungsdauer kann daher schwanken, was für Multimediaanwendungen schlecht ist. Bei VoIP z.B. würde es zu plötzlichen Aussetzern kommen bzw die Wiedergabepuffer müssten größer angelegt werden. Solche Anwendungen setzen daher auf UDP, verlorengeganene Pakete bringen hier nicht die gesamte Übertragung ins Stocken.

Weblinks


- RFC 768 - User Datagram Protocol

Siehe auch

UDPsec, Vorschlag einer Modifikation von UDP für verbesserte Sicherheit Kategorie:Netzwerkprotokoll ja:User Datagram Protocol

Multihoming

Multihoming ist eine Technik, um die Zuverlässigkeit von Internet-Verbindungen eines IP-Netzwerkes zu verbessen. Hierzu erfolgt die Anbindung ans Internet über mindestens zwei Internetprovider. Fällt einer der Internetprovider (ISP) aus (nennen wir ihn mal A), so schaltet der Router automatisch alle Routen,die bisher über A liefen, auf die anderen Provider um.
Ein Multihoming wird meistens über einen BGP-Router realisiert (z.B. Cisco Router oder Linux Server mit Quagga). Aufgrund der unterschiedlichen AS-Pfadlängen entscheidet dieser, welche ISP-Verbindung für eine bestimmte Verbindung am besten geeignet ist. Durch den Einsatz verschiedener Tuning-Parameter (MET, Precedence) können bestimmte ISP's individuell bevorzugt werden. Multihoming setzt sinnvollerweise voraus, das im Netzwerk mit PI Adressen (Provider Indipendent) gearbeitet wird. Unter dieser Voraussetzung können auch weitere Traffic Shaping Mechanismen eingesetzt werden, um z.B. alle eingehenden Datenpakete über ISP1 (Internet Service Provider - Internetdienstanbieter) laufen lassen und die ausgehenden über ISP2. Eine andere Variante ist, die einzelnen Internetdienste wie WEB, FTP, Datenbank, usw. auf die zwei Internetleitungen aufzuteilen. Internetdienstanbieter Kategorie:Internet

SYN-Flood

Ein SYN-Flood ist eine Form von Denial of Service-Attacken auf Computersysteme. Wenn ein Client eine TCP-Verbindung zu einem Server aufbauen möchte, führen der Client und der Server einen so genannten Dreiwege-Handshake durch, um die Verbindung einzurichten. Der normale Ablauf dabei ist folgender:
- Der Client sendet ein Paket mit dem Flag SYN (synchronize) an den Server.
- Der Server bestätigt das Paket mit SYN, ACK (acknowledge).
- Der Client antwortet mit einem ACK; die Verbindung ist hergestellt. Ein böswilliger Client kann die letzte ACK-Nachricht unterschlagen. Der Server wartet einige Zeit auf ein entsprechendes Paket, da es ja auch auf Grund von Congestion (Stau) ausbleiben könnte. Wenn diese so genannte halboffene Verbindung Ressourcen auf dem Server belegt, wie es bei vielen Betriebssystemen der Fall ist, ist es möglich, alle diese Ressourcen aufzubrauchen, indem der Server mit SYN-Nachrichten geflutet wird. Sobald alle für halboffene Verbindungen verfügbaren Ressourcen verbraucht sind, können keine neuen Verbindungen zum Server aufgebaut werden (egal ob legitim oder nicht), was zum Denial of Service führt. Zu den Ressourcen, die in Frage kommen, gehören vor allem die maximal mögliche Anzahl an TCP-Verbindungen, sowie der Speicher des Servers. Wenn dem angegriffenen Opfer der Speicher ausgehen sollte, stürzt der Rechner in vielen Fällen ganz oder teilweise ab. Mögliche Gegenmaßnahmen gegen SYN-Floods sind der SYN-Cookies-Mechanismus oder eine Begrenzung der Anzahl neuer Verbindungen von einem Ursprungsort pro Zeiteinheit. Gegen Distributed Denial of Service-Angriffe schützen diese Maßnahmen jedoch unter Umständen nicht.

Weblinks


- http://www.grc.com/dos/drdos.htm - Analyse einer auf SYN-Flood basierenden Distributed Reflection Denial of Service-Attacke Kategorie:IT-Sicherheit

Cookie

Ein Cookie [] (am. englisch Plätzchen, Keks) ist ein kurzer Eintrag in einer meist kleinen Datenbank auf einem Computer und dient dem Austausch von Informationen zwischen Computerprogrammen oder der zeitlich beschränkten Archivierung von Informationen. Ein Cookie besteht aus mindestens zwei Bestandteilen, seinem Namen und dem Inhalt oder Wert des Cookie, zusätzlich können Angaben über den zweckmäßigen Gebrauch vorhanden sein. Die Datenbank kann oft vom Benutzer des Computers ohne besondere Hilfsmittel nicht eingesehen oder verändert werden, sie ist opak. Von Anwendungsprogrammen oder Teilen oder Erweiterungen des Betriebssystems eines Computers, die einen Dienst zur Verfügung stellen, kann ein Cookie zum Beispiel beim Start des Programms gesetzt werden. Anderen Programmen wird so bekannt, dass sie diesen Dienst in Anspruch nehmen können, wenn sie in der Datenbank den vorher vereinbarten Namen des Cookie finden. Der Wert des Cookie enthält dabei typischerweise eine Speicheradresse, über die Funktionen des Dienstes zugänglich sind. Datenbanken dieses Typs heißen Cookie Jar. Webbrowser stellen eine Cookie-Datenbank zur Verfügung, die Cookie Cache genannt wird; dort kann der Webserver einer besuchten Webseite Informationen in Form von HTTP-Cookies hinterlegen und bei einem Wiederbesuch der Seite auslesen. Siehe auch: Registry

Weblinks


- [http://www.mbernstein.de/atari/prog/tos/0302.htm Cookies im Atari TOS] Kategorie:Programmiertechnik als:Cookie

SS7

Signalling System #7 (SS7) (auch Signalling System Number 7, Zeichengabesystem Nr. 7, Zentrales Zeichengabesystem Nr. 7, ZZS7, CCITT-Zeichengabesystem Nr. 7, Central Signalling System #7, C7 usw.) ist eine Sammlung von Protokollen zur Signalisierung in Telekommunikations-Netzen, wie dem öffentlichen Telefonnetz (sowohl im Festnetz- als auch im Mobilfunknetz-Bereich). Die meisten SS7-Protokolle sind durch die ITU (früher CCITT) in der Serie Q.7xxx oder durch verwandte Standardisierungsgremien standardisiert. SS7 ist heutzutage das gängigste und häufig einzige Signalisierungssystem, sowohl in nationalen, als auch internationalen Telekommunikations-Netzen. Telekommunikationseinrichtungen enthalten entsprechende SS7-Protokollstacks. Diese unterscheiden sich je nach konkreter Anwendung (auf den höheren Schichten werden andere Protokolle aus der SS7-Protokollfamilie verwendet). Der genaue Aufbau eines Protokollstacks für eine bestimmte Anwendung ist dabei üblicherweise in entsprechenden Telekommunikations-Standards festgelegt. Es gibt also nicht "den" SS7-Protokoll-Stack, und es gibt schon gar nicht "das" SS7-Protokoll. Grundsätzlich ist das Zentrale Zeichengabesystem Nr. 7 ein sogenanntes Zentralkanalsystem (daher der Zusatz Zentral in einigen Schreibweisen). Dies bedeutet, die Signalisierungsinformation wird nicht innerhalb eines Übertragungskanals (in-band signalling), sondern außerhalb (out-band signalling) und für alle Übertragungskanäle zusammengefasst (zentral) und nicht an die einzelnen Übertragungskanäle gebunden, übertragen. Praktisch bedeutet dies, dass ein SS7-Netzwerk als ein eigenständiges Netzwerk realisiert wird, welches von den Nutzkanälen völlig getrennt ist.

Geschichtlicher Ablauf

SS7 wurde 1975 von AT&T entwickelt, um das zuvor in den USA verwendeten Signalling System #5 und Signalling System #6 zu ersetzen. Bei diesen Versionen fand die Signalisierung jedoch in-band statt, indem bestimmte Töne zur Kommunikation zwischen den Vermittlungsstellen benutzt wurden. Dies stellte jedoch eine Sicherheitslücke dar, die von sogenannten Phreakern ausgenutzt wurde, indem sie die Steuertöne selbst erzeugten und dadurch die Gebührenerfassung umgehen konnten. Die ITU-T standardisierte das SS7 im Jahre 1981, ebenso wie sie auch die Vorgänger SS6 und SS5 akzeptiert hatte. Danach verbreitete sich das SS7 schnell weltweit.

Schichtenmodell

SS7 ist grob nach dem OSI-Schichtenmodell modelliert. Die Schichten 1–3 werden dabei als MTP (message transport part, Nachrichtentransferteil) von SS7 bezeichnet: ;MTP Schicht 1 (Zeichengabekanal) :Physikalische Bitübertragung, Koppelnetz-Zugriff ;MTP Schicht 2 (Zeichengabestrecke) :Gesicherte Zeichenübermittlung ;MTP Schicht 3 (Zeichengabenetz) :Netzmanagement, Nachrichtenwegelenkung, Nachrichtenverteilung Mit diesen drei Schichten wird die Basis-Infrastruktur eines SS7-Netzes realisiert. Schicht 1 ist die Leitung. Schicht 2 ermöglicht den Austausch von Signalisierungsnachrichten zwischen zwei Punkten. Die Schicht 3 verbindet die einzelnen Punkte zu einem Signalisierungsnetz. Damit hat man dann ein Netz, in dem sich die einzelnen angeschlossenen Telekommunikationssysteme gegenseitig Signalisierungs-Nachrichten senden können. Der Inhalt dieser Nachrichten wird durch die höherliegenden Protokolle bestimmt, die anwendungsspezifisch sind. Ãœblich – aber nicht immer vorhanden oder nicht separat vorhanden – ist dabei zuerst eine weitere Protokoll-Schicht TF (transport function, Transportfunktionsteil): ;TF Schicht 4 (Ende-zu-Ende) :Gesicherte Ende-zu-Ende Verbindung Damit werden logische Verbindungen zu Endpunkten (an der Signalisierung beteiligte Systeme) realisiert. Der genaue dabei durch das Signalisierungsnetzwerk genommene Weg ist auf dieser Ebene nicht mehr sichtbar. In der Tat ermöglicht SS7 die automatische Nutzung alternativer Verbindungen, sollte im Betrieb eine Verbindung zwischen zwei Punkten ausfallen. Soll das SS7-Netz zum Beispiel zur Signalisierung in einem ISDN-Netz dienen, wird in Zusammenarbeit mit TF ein weiteres Protokoll verwendet: ISUP (ISDN user part, ISDN-Anwenderteil). Aufgrund seiner Funktion lässt sich dieses nicht genau einer Schicht des OSI-Schichtenmodells zuordnen. Es ergänzt die Schicht-4-Funktionen von TF, enthält aber auch Schicht-5-Funktionen: ;ISUP Schicht 4, 5 (ISDN-Zeichengabe) :Nachrichtenbehandlung, Steuerung des Vermittlungsprozesses Für andere Anwendungen, zum Beispiel Mobilfunk, werden statt ISUP andere Protokolle wie MAP, CAP, TCAP verwendet. Für die Steuerung zentraler Dienste in Telekommunikationsnetzwerken , sog. Mehrwertdiensten wie PremiumRate 0900 und Massenverkehr 0137, wird INAP (Intelligent Network Application Protocol) verwendet. Mit diesem Protokoll wird es möglich, die Steuerungsfunktionen für solche Dienste nicht mehr in allen Vermittlungsstellen des Netzes zu implementieren, sondern diese Funktionen nur an einer oder mehreren zentralen Stellen vorzuhalten. Diese zentralen Stellen, sog. IN-Plattformen, hosten Dienstlogiken, in denen die Verarbeitungsregeln der jeweiligen Dienste vorgegeben werden. Das Protokoll INAP verbindet dabei die Steuerungsfunktion der IN-Plattform (SCP Service Control Point) mit der Vermittlungsfunktion (SSP Service Switching Point) der vorgelagerten Vermittlungsstelle.

Siehe auch


- Signalisierung
- Signalling Transfer Point

Weblinks


- [http://www.ericsson.com/support/telecom/part-e/index.shtml The Signalling Network Ericsson (Englisch)]
- [http://www.pt.com/tutorials/ss7/ Tutorial PT (Englisch)] Kategorie:Netzwerkprotokoll Kategorie:Telekommunikation

Kategorie:Netzwerkprotokoll

Computer und andere digitale Geräte verwenden zur Kommunikation Netzwerkprotokolle, um Daten über Telegramme auszutauschen. Ein Datentelegramm enthält dazu verschiedene Felder für Nachrichten und Steuerinformationen. Kommunikationsdienste erfüllen dazu Aufgaben wie zum Beispiel Auf- und Abbau der Kommunikationsübertragung. Protokoll Kategorie:Automatisierungstechnik ja:Category:通信プロトコル

Sankt Georgen-Oberkirnach

Oberkirnach ist ein zu Sankt Georgen im Schwarzwald gehörender Stadtteil mit 262 Einwohnern. Oberkirnach wurde im Jahr 1084 erstmals besiedelt. Die Entwicklung von Oberkirnach hing stark mit der Entwicklung des Klosters zusammen. Im Jahre 1974 wurde Oberkirnach von der Stadt St.Georgen eingemeindet. Heute befinden sich alle Skilifte St.Georgens im Stadtteil Oberkirnach weswegen Oberkirnach das wichtigste Wintersportzentrum von St.Georgen ist. Neben den St.Georgenern besuchen auch viele Touristen die Skipisten. Kategorie:Ort in Baden-Württemberg Kategorie:Schwarzwald-Baar-Kreis

szko³y zawory metalowe madrid accommodation darmowe statystyki jastrzêbia góra pensjonat










































:: RELATED NEWS ::
Valerie Amos
The Right Honourable Valerie Ann Amos, The Baroness Amos of Brondesbury, PC (born 13 March 1954), is a British Labour Party politician and Jewish services, a Parsha or Parshah, פרשה, meaning "Portion" in Hebrew, is the weekly Torah reading text selection. It is also known as the Parshat HaShavuah ("Weekly Portion") or the Sidra. The plural is Parshiot. Each Parsha usually takes its name from the first unique word or words in the Hebrew text.

Table of Parshiot

The following are the 54 weekly Read More...
Michael Havers
The Right Honourable Robert Michael Oldfield Havers, Baron Havers, QC (10 March 1923–1 April 1992) was a British lawyer and politician. From his knighthood in 1972 until becoming a peer he was known as Sir Michael Havers. He was a son of High Court Judge Sir Cec
Elwyn Jones
:For the British television scriptwriter, see Elwyn Jones (writer). The Right Honourable Frederick Elwyn Elwyn-Jones, Baron Elwyn-Jones, PC (24 October 1909–4 December 1989) was a
ATC code D08
A section of the Anatomical Therapeutic Chemical Classification System. D Dermatologicals

D08A Antiseptics and disinfectants

D08AA Acridine derivatives

:D08AA01 Ethacridine lactate :D08AA02 Aminoacridine :D08AA03 Euflavine

D08AB

Gerald Gardiner
Gerald Austin Gardiner, Baron Gardiner of Kittisford in the County of Somerset, PC KC (30 May 1900-7 January 1990) was Lord Chancellor from 1964 to 1970 and during that time he introduced into British law as many reforms as any Lord C
Emergent structures
Emergence is the process of complex pattern formation from simpler rules. This can be a dynamic process (occurring over time), such as the evolution of the human brain over thousands of successive generations; or emergence can happen over disparate size scales, such as the interactions between a macros
Christopher Soames
The Right Honourable Arthur Christopher John, Baron Soames GCMG GCVO CBE PC (October 12, 1920-September 16, 1987) was the last
Red snapper
:For the electronic music group, see Red Snapper. Red snapper (Lutjanus campechanus) is a reef fish found off the Atlantic coast of The Americas and in the Gulf of Mexico. The Red snapper commonly inhabits waters from 30 to 200 ft (10 to 60 m), but can be caught as deep as 300 ft (100 m) or more on occasion. They keep
James Cousins
James Henry Sproul Cousins (1873-1956) was an Irish writer who was a playwright, critic and poet; ultimately he was known as a writer on theosophy. He used a pseudonym Mac Oisín and the Hindu name Jayaram. He was born in Belfast. His plays were produced in the first years of the t
All Rights Reserved 2005 wikimiki.org