Wikipedia - Benutzerbeiträge [de]

Diskussion:Übersprechen

2012-11-21T07:59:02Z

Matthi2: Plädoyer für Nah-/Fern-"Nebensprechen" statt "Übersprechen"

== Übersprechen <--> Nebensprechen ==
Die Änderungen von anonymem Benutzer IP 84.191.106.139 (Ausgliederung des Inhalts von Nebensprechen in Übersprechen und Umkehrung der redirects) finde ich nicht so gut. "Nebensprechen" ist der gebräuchlichere Fachausdruck in der Nachrichtentechnik und sollte m. E. der führende Artikel bleiben. Wenn der unbekannte Änderer dazu mal Stellung nehmen könnte. --[[Benutzer:Uweschwoebel|Uweschwoebel]] 00:47, 6. Sep 2005 (CEST)

----

== Übersprechen <--> Nebensprechen ==
Das internationale Wort 'crosstalk' heißt übersetzt immer "Übersprechen".
Dieses Wort ist allgemein gebräuchlicher. In der deutschsprechenden Telefontechnik wird noch von Nebensprechen aus geschichtlicher Gewohnheit gesprochen, aber Übersprechen setzt sich immer mehr durch. Siehe Google: Übersprechen gewinnt mit 22400 Zitaten und das Nebensprechen kommt auf schlappe 7500. Das kann auch Uwe nicht ändern. "Übersprechen" hat glatt das Vorrecht!

Lumi 15:00, 7. Sep 2005 (CEST)

----

Ich finde das Wort Übersprechen moderner und besser. Das Wort Nebensprechen hat bei mir "Altdeutsches Post-Telefon" feeling. Überall bei Kabeln und Kapazitäten findet man das Wort Übersprechen. Das scheint auch die Google-Mehrheit so zu finden.

[ebs|ebs] 15:51, 7. Sep 2005 (CEST)

----

Der Ausdruck "Übersprechen" ist ein typischer Anglizismus (cross=über) und Bastlerjargon (wenn auch ein alter Anglizismus). Wer beruflich mit solchen Messungen zu tun hat, findet in den Anleitungen der Meßgeräte kein "Übersprechen", sondern nur "Nebensprechen", ebenso in den maßgeblichen Fachbüchern. Wer "Übersprechen" benutzt, gilt nicht als Fachmann. [[Benutzer:Fink|Fink]] 17:28, 7. Sep 2005 (CEST)

----

In der professionellen Telekommunikation (damit ist gemeint: Berufliches Umfeld, keine Bastler) sehe ich die Ausdrücke "Crosstalk", "NEXT" und "FEXT" und als deren deutsche Entsprechungen "Nahnebensprechen" und "Fernnebensprechen". Ich kann ebs nachfühlen, dass das für ihn nach "altdeutschem Post-Telefon" klingt. Kein Wunder, denn die Begriffe werden auch heute noch von Deutscher Telekom und Mitbewerbern verwendet. Das ändert aber nichts an den Begriffen an sich und dass die Fachleute eben diese verwenden. Ich finde, dass nicht die Google-Mehrheit (potentiell Ahnungslose) entscheiden sollte, sondern die tatsächlichen Profis.
--[[Benutzer:Matthi2|Matthi2]] ([[Benutzer Diskussion:Matthi2|Diskussion]]) 08:59, 21. Nov. 2012 (CET)

==HiFi==
Ich vermisse die Bedeutung in der Tontechnik. Bei analogen Geräten wie Plattenspielern, Tapedecks, Tunern, aber auch (geringer) Verstärkern gibt es immer ein Übersprechen vom einem Stereokanal auf den anderen. Dies ist sogar ein Standard-Messwert bei HiFi-Equipment (gemessen in dB). Sollte das nicht auch rein? [[Benutzer:Pittigrilli|Pittigrilli]] 21:38, 24. Jul. 2009 (CEST)

== Ursache für FEXT<NEXT ==

Die Begründung dafür, weshalb FEXT kleiner als NEXT sein soll, schien mir falsch. Ich habe das deshalb angepasst. Die Erklärung lässt sich sicher noch ausführlicher gestalten. Ich wollte das einfach nicht so (meiner Meinung nach eben falsch) stehen lassen. -- [[Spezial:Beiträge/178.197.232.71|178.197.232.71]] 16:28, 21. Jun. 2012 (CEST)

Diskussion:MOSPF

2009-01-14T14:49:24Z

Matthi2: Zusammenfassung: Problem mit Begriff "Standort" von Gruppenmitgliedern. Quelle: John T. Moy: "OSPF. Anatomy of an Internet Routing Protocol", Addison-Wesley, 1998. ISBN 0-201-63472-4

MOSPF - erster Absatz:

"Durch das Hinzufügen eines neuen link states records, - dem group-membership-LSA - ist es nun möglich, den Standort aller Multicast-Teilnehmer einer Gruppe in der Datenbank zu speichern."

Eigentlich sagt das Group-membership-LSA nichts aus über den Standort eines neuen Gruppenmitglieds, sondern nur darüber, daß überhaupt ein neues Ggruppenmitglied da ist. Bei LAN-Segmenten kann das irgendein Host auf dem LAN sein. Der Begriff "Standort" impliziert für mich, daß man den Host exakt identifizieren kann.
--[[Benutzer:Matthi2|Matthi2]] 15:49, 14. Jan. 2009 (CET)

Open Shortest Path First

2009-01-14T14:39:08Z

Matthi2: /* Weblinks */ Tippfehler

'''OSPF''' (Open Shortest Path First) ist ein Verfahren aus der [[Rechnernetz|EDV-Netztechnik]]. Es bezeichnet ein von der [[IETF]] entwickeltes [[Link-State]]-[[Routing-Protokoll]]. Es ist im RFC 2328 (obsolet: RFC 1247 von 1991) festgelegt und basiert auf dem von [[Edsger Wybe Dijkstra|Edsger W. Dijkstra]] entwickelten Algorithmus „[[Algorithmus von Dijkstra|Shortest Path First]]“.

== Überblick ==
OSPF ist ein dynamisches Routing-Protokoll innerhalb eines [[Autonomes System|autonomen Systems]]. Es hat das [[Routing Information Protocol]] (RIP) als Standard-[[Interior Gateway Protocol]] (IGP) abgelöst, insbesondere bei großen Netzen. OSPF verwendet die Kosten eines Pfades als [[Metrik (Netzwerk)|Metrik]] und kann bei gleichen Kosten lastverteilt arbeiten. Der Standard definiert nicht wie die Kosten zu berechnen sind, einige Implementierungen (z.B. Router des Herstellers Cisco Systems) greifen auf die Interface-Bandbreite zurück, wenn kein anderer Wert vorgegeben wird.

Neuere Trends bei Betreibern von [[Internet Protocol|IP]]-Netzen zeigen, dass dort vermehrt [[IS-IS]] im Zusammenhang mit [[MPLS]] eingesetzt wird, weil die IS-IS-Features ausreichen, das Protokoll weniger komplex als OSPF ist und im Vergleich besser skaliert. Trotzdem ist OSPF heute noch das vorwiegend verwendete Routing-Protokoll.

== Arbeitsweise ==

Kernstück von OSPF ist die Nachbarschafts-Datenbank ''(Adjazenz-Datenbank)''/''LSD (Link State Database)'', die eine Liste aller benachbarten Router, zu denen eine [[bidirektional]]e Verbindung besteht, enthält. Sie spiegelt die [[Topologie (Netzwerk)|Topologie]] des Netzes wider. Damit diese Datenbank aufgebaut oder bei Topologie-Änderungen aktualisiert wird, ist der Austausch von Routing-Informationen notwendig. Diese werden mittels [[Flooding_%28Informatik%29|Flooding]] übermittelt. Um den Umfang der auszutauschenden Informationen gering zu halten, wählen OSPF-Router einen designierten Router ''DR'' sowie einen Reserve-Router ''BDR (Backup Designated Router)'', die als Schnittstellen für den Austausch dienen. Der OSPF-Router, dessen Multi-Access-Schnittstelle die höchste ''Router-Priorität'' besitzt, wird ''DR''. Haben zwei Router die gleiche Priorität, wird der Router mit der höheren ''Router-ID'' gewählt. Als Router-ID wird die IP-Adresse eines Loopback-Interfaces oder - je nach Hersteller - des Interfaces mit der numerisch höchsten IP-Adresse/des ersten aktiven Interfaces automatisch gewählt.

OSPF-Router tauschen Informationen über die erreichbaren Netze mit sogenannten LSA-Nachrichten (Link State Advertisements) aus. Hierbei sind folgende LSA-Typen definiert:

* '''Router-LSA (Typ 1)''': Für jeden aktiven Link des Routers, der der zu betrachtenden Area angehört, wird ein Eintrag im Router-LSA erzeugt. In ihm wird neben der IP-Adresse des Links auch die Netzmaske des Links und der Netzwerktyp (Loopback, Point-to-Point, normales Netz) eingetragen.
* '''Network-LSA (Typ 2)''': Der designierte Router (DR) eines Netzsegments erzeugt ein Network-LSA für dieses Netz, das neben der Netzadresse und -maske auch eine Liste der anderen angrenzenden Router enthält.
* '''Summary-LSA (Typ 3/4)''': Informationen über Ziele außerhalb einer Area können von den ABR je nach Konfiguration als LSA-Typ 3 (wenn es sich um eine Netz-Information handelt) oder LSA-Typ 4 (bei einer weitergeleiteten Router-Erreichbarkeit) in eine andere Area weitergegeben werden. LSAs vom Typ 3 werden auch verwendet, um Default-Routen in (Stub-)Areas zu propagieren.
* '''AS-External LSA (Typ 5)''': Router, die aus Sicht des OSPF das eigene [[Autonomes System|autonome System]] abschließen, können für extern gelernte oder manuell konfigurierte Routen Typ-5-LSAs erzeugen. Diese enthalten Netzadresse und -maske des Zielnetzwerks sowie einen Verweis auf den ankündigenden Router. Eine gängige Anwendung von Typ-5-LSAs ist, Default-Routen in die Backbone-Area zu injizieren.
* '''NSSA-External-LSA (Typ 7)''': LSA-Typ7 wird am NSSA ASBR generiert. Type-5 LSAs sind in NSSA Areas nicht erlaubt, daher generiert der NSSA ASBR Type-7 LSAs dafür. Ein NSSA-External-LSA ist annähernd identisch mit einem AS-External-LSA. Im Gegensatz zu den AS-External-LSAs, die durch ein gesamtes OSPF-AS geflutet werden, werden NSSA-External-LSAs nur innerhalb der NSSA-Area geflutet, in der sie erzeugt wurden.
* '''Opaque-LSA (Typ 9)''': Dieser LSA-Typ wird Link lokal und somit nicht über Router hinweg verbreitet. Aktuell wird dieser LSA-Typ für eine Graceful Restart Funktion genutzt.
* '''Opaque-LSA (Typ 10)''': Dieser LSA-Typ wird Area lokal verbreitet. Aktuell wird dieser LSA-Typ für Traffic Engineering Funktionen genutzt.
* '''Opaque-LSA/Graceful Restart (Typ 11)''': Dieser LSA-Typ wird AS weit geflutet. RFC 5187 ersetzt den Opaque-LSA Typ durch Graceful Restart LSA. Diese Veränderung gilt allerdings nur für OSPFv3. Eine Nutzung dieses LSA Types ist derzeit nicht bekannt.

== Merkmale ==
* OSPF garantiert ein [[Schleife (Graphentheorie)|schleife]]nfreies [[Routing]] im Gegensatz zu [[Routing Information Protocol|RIP]] (= verhindert Kreisrouting)
* [[Hello-Protokoll]] für die Überwachung der Nachbarn
* Es unterstützt [[VLSM]] sowie [[CIDR]]
* OSPF ist für große skalierbare Netze gut geeignet
* Das Area-Konzept vereinfacht die Kommunikation und Wartung

==OSPF Open Shortest Path First header version 2==
{| class="prettytable"

! colspan="32" align="center" | OSPF Open Shortest Path First header
|-----
! width="3.125%" | 0
! width="3.125%" | 1
! width="3.125%" | 2
! width="3.125%" | 3
! width="3.125%" | 4
! width="3.125%" | 5
! width="3.125%" | 6
! width="3.125%" | 7
! width="3.125%" | 8
! width="3.125%" | 9
! width="3.125%" | 10
! width="3.125%" | 11
! width="3.125%" | 12
! width="3.125%" | 13
! width="3.125%" | 14
! width="3.125%" | 15
! width="3.125%" | 16
! width="3.125%" | 17
! width="3.125%" | 18
! width="3.125%" | 19
! width="3.125%" | 20
! width="3.125%" | 21
! width="3.125%" | 22
! width="3.125%" | 23
! width="3.125%" | 24
! width="3.125%" | 25
! width="3.125%" | 26
! width="3.125%" | 27
! width="3.125%" | 28
! width="3.125%" | 29
! width="3.125%" | 30
! width="3.125%" | 31
|-----
| colspan="8" align="center" bgcolor="#ffff99" | '''Version'''
| colspan="8" align="center" bgcolor="#ffff99" | '''Type'''
| colspan="16" align="center" bgcolor="#ffff99" | '''Length'''
|-----
| colspan="32" align="center" bgcolor="#ffff99" | '''Router ID'''
|-----
| colspan="32" align="center" bgcolor="#ffff99" | '''Area ID'''
|-----
| colspan="16" align="center" bgcolor="#ffff99" | '''Checksum'''
| colspan="16" align="center" bgcolor="#ffff99" | '''AuType '''
|-----
| colspan="32" align="center" bgcolor="#ffff99" | '''Authentication'''
|-----
| colspan="32" align="center" bgcolor="#ffff99" | '''Authentication (ctd.)'''
|-----
| colspan="32" align="center" bgcolor="#00EEEE" | '''Data'''
|-----
|}

* Die Größe des ''Version''-Felds beträgt 8 Bit.
* Die Größe des ''Typ''-Felds beträgt 8 Bit.

:{| class="prettytable" border="1"
! Typ
! Beschreibung
! Referenz
|-----
| 1 || Hello. || RFC 2328, RFC 2740
|-----
| 2 || Database description. || RFC 2328, RFC 2740
|-----
| 3 || Link state request. || RFC 2328, RFC 2740
|-----
| 4 || Link state update. || RFC 2328, RFC 2740
|-----
| 5 || Link state acknowledgment. || RFC 2328, RFC 2740
|}

* Die Größe des ''Length''-Feldes beträgt 16 Bit. Es enthält die Gesamtpaketlänge.
* Die Größe des Feldes ''Router ID'' beträgt 32 Bit.
* Die Größe des Feldes ''Area ID'' beträgt 32 Bit.
* Die Größe des ''Checksum''-Feldes beträgt 16 Bit. Es enthält die Standard [[Internet_Protocol|IP]]-Prüfsumme.
* Die Größe des Felds ''AuType'' (Authentifikations-Typ) beträgt 16 Bit.

:{| class="prettytable" border="1"
! Authentication type
! Beschreibung
! Referenz
|-----
| 0 || None. || RFC 2328
|-----
| 1 || Simple password authentication. || RFC 2328
|-----
| 2 || Cryptographic authentication. || RFC 2328
|-----
| 3 – 65535 || Reserved. ||
|-----
|}

* Die Größe des Felds ''Authentication'' beträgt 64 Bit.

==OSPF Open Shortest Path First header version 3==
{| class="prettytable"
|-----
! colspan="32" align="center" | OSPF Open Shortest Path First header version 3
|-----
!0
!1
!2
!3
!4
!5
!6
!7
!8
!9
!10
!11
!12
!13
!14
!15
!16
!17
!18
!19
!20
!21
!22
!23
!24
!25
!26
!27
!28
!29
!30
!31
|-----
| colspan="8" align="center" bgcolor="#ffcc99" | '''Version (Version) '''
| colspan="8" align="center" bgcolor="#ffff99" | '''Type (Typ)'''
| colspan="16" align="center" bgcolor="#ffff99" | '''Length (Länge)'''
|-----
| colspan="32" align="center" bgcolor="#ffff99" | '''Router ID (Routerbezeichner)'''
|-----
| colspan="32" align="center" bgcolor="#ffff99" | '''Area ID (Bereichsbezeichner)'''
|-----
| colspan="16" align="center" bgcolor="#ffff99" | '''Checksum (Prüfsumme)'''
| colspan="8" align="center" bgcolor="#ffff99" | '''Instance ID (Instanzbezeichner)'''
| colspan="8" align="center" bgcolor="#ffcc99" | '''Reserved (reserviert)'''
|-----
| colspan="32" align="center" bgcolor="#00EEEE" | '''Data (Daten)'''
|-----
|}

* Die Version 3 des OSPF ist für [[IPv6]] vorgesehen und in RFC 2740 definiert.
* Die Instance ID (Instanzbezeichner) beträgt 8 Bit.
* Reserved (reserviert) beträgt 8 Bit.

==OSPF Unterschiede zwischen v2 und v3==

Die Protokoll Definition von OSPFv3 führte, neben der Erweiterung um IPv6 Funktionalität, einige Unterschiede zu v2 ein. Die Unterschiede werden im folgenden aufgelistet :

* Die Bezeichnung "subnet" wurde ersetzt durch "link". Hintergrund ist die Definition eines Interfaces. In OSPFv2 wird ein Interface als ein Subnetz betrachtet, dies führt dazu das auf einem Interface nur eine Nachbarschaftsbeziehung in einem Subnetz erfolgen kann. Allerdings kann ein Interface auch mehrere Subnetze enthalten und sehr wohl über diese Nachbarschaftsbeziehung aufbauen wollen. Diese Umdefinition behebt den Umstand und erhöht die Möglichkeiten zur Nachbarschaftsbildung.
* Nachbarschaftserkennung anhand der Router ID. In OSPFv2 werden Nachbarn, auf NBMA Links, über die Interface Adressen erkannt. Bei Point-to-Point Links werden die Nachbarn über die Router ID identifiziert. Dieser Unterschied wird in OSPFv3 aufgehoben und sämtliche Nachbarn werden über die Router ID identifiziert.
* Authentifizierung entfernt. In OSPFv2 wird im Header eine Authentifizierung durchgeführt. Diese wurde in OSPFv3 vollständig entfernt. Die Funktion wird nun durch den IPv6 Authentication Header ersetzt(Funktion verschoben auf unteren Layer).
* Weiterleitung von unbekannten LSA Typen. In OSPFv2 werden unbekannte LSA Typen gelöscht und nicht weiter verbreitet. OSPFv3 Implementierungen sollen auch unbekannte LSA Typen weiterleiten.

== Weblinks ==
* RFC 5187 OSPF Version 3 Graceful Restart, Juni 2008
* RFC 2740 OSPF Version 3, Dezember 1999
* RFC 2370 OSPF Opaque LSA Option, Juli 1998
* RFC 2328 OSPF Version 2, April 1998
* RFC 1850 OSPF Version 2 MIB, November 1995
* RFC 1793 Extending OSPF to Support Demand Circuits, April 1995
* RFC 1587 OSPF NSSA Option, März 1994
* RFC 1253 OSPF Version 2 MIB, August 1991, ersetzt durch RFC 1850
* RFC 1247 OSPF Version 2, Juli 1991, ersetzt durch RFC 2370
* RFC 1131 OSPF Version 2, Juli 1991, ersetzt durch RFC 1247
* [http://www.welzl.at/research/tools/irvtool/ irvtool – Ein RIP/OSPF Visualisierungstool] (Java/GPL)
* [http://www.ospf.org/ OSPF-C++-Quellcode]
* [http://www.quagga.net/ Freie Implementation gängiger Routingprotokolle], u. a. auch OSPF
* [http://www.openbgpd.org/ BGP und OSPF sicher implementiert]
* [http://www.perihel.at/dcom/ Vorlesungsunterlagen zu OSPF und BGP]

[[Kategorie:Netzwerkprotokoll]]

[[an:Open Shortest Path First]]
[[cs:Open Shortest Path First]]
[[da:OSPF]]
[[el:Open Shortest Path First]]
[[en:Open Shortest Path First]]
[[es:Open Shortest Path First]]
[[fi:OSPF]]
[[fr:Open shortest path first]]
[[he:Open Shortest Path First]]
[[it:Open Shortest Path First]]
[[ja:オープン・ショーテスト・パス・ファースト]]
[[lv:Open Shortest Path First]]
[[nl:Open Shortest Path First]]
[[pl:OSPF]]
[[pt:Open Shortest Path First]]
[[ru:OSPF]]
[[sr:OSPF]]
[[sv:Open Shortest Path First]]
[[tr:OSPF]]
[[uk:OSPF]]
[[zh:开放式最短路径优先]]

Diskussion:Media Gateway Control Protocol (Protokoll)

2008-05-16T14:53:55Z

Matthi2:

Hier sollte noch einiges Übersetzt werden. --[[Benutzer:Thornard|Thornard]], [[Benutzer Diskussion:Thornard|Diskussion]], 02:30, 27. Feb. 2007 (CET)
: Hallo Thornard, dieser Artikel sollte '''MGCP''' und nicht der Oberbegriff Media-Gateway-Control-protocol sein. MeGaCo ist bekanntlich auch ein Media-Gateway-Control-protocol, sogar wie MGCP eine Abkürzung desselben. Ebenso sind H.248 und IGCP Media-Gateway-Control protocols. --[[Benutzer:Andys|Andys]] 14:20, 27. Feb. 2007 (CET)
: Wieso ist in der Tabelle vom *Cisco* CallManager die Rede?--[[Benutzer:Matthi2|Matthi2]] 16:53, 16. Mai 2008