Diskussion:Multiprotocol Label Switching

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Optisches Switchen?[Quelltext bearbeiten]

Die IP-Pakete werden zusätzlich mit einem physischen Label versehen und optisch durch das Netz geswitcht [...] - Was kann ich mir unter optischem switchen vorstellen? --Kdwnv 10:02, 11. Sep 2004 (CEST)

Durch anlegen eines elektrischen Feldes kann man die Übertragungseigenschaften von besonderen Lichtwellenleitern(z.B. mit Lithiumniobat) ändern(unterschiedliche Brechung des Lichtes) und ein überkoppeln des Lichtes auf die andere Leitung realisieren.

Als Label für MPLS dient die Wellenlänge des Lichtes. Weiterhin soll es möglich sein Steuerinformationen und Daten zu trennen. Die Steuerdaten elektronisch auszuwerten und die Daten derweil in Verzögerungsfasern zu schicken und das ganze wieder zusammenzusetzen. --15:43, 2. Dez 2004 (CET)

LSP nicht zwingend ein Tunnel[Quelltext bearbeiten]

LSP != LSP Tunnel (siehe RFC3031 und RFC3209), es gibt eine semantische Differnzierung.

Das PDF "From MPLS to GMPLS" würde ich als Werbung bezeichnen und als fraglich einstufen.

MPLS ohne optisches Medium[Quelltext bearbeiten]

Bedenkt bitte dass MPLS auch ohne optisches Transport-Medium eingesetzt werden kann.

MPLS ist zwischen OSI Schicht 2 und Schicht 3 angesiedelt und somit vollkommen unabhängig vom physischen Medium (Schicht 1).

Im Grunde verbindet MPLS die Intelligenz des IP-Routing mit der Geschwindigkeit des Label Switchings, so wie man es aus ATM oder Frame Relay kennt.

Dazu gibt es eine Control Unit die sich beliebiger bekannter (IP) Routing-Protokolle bedient und einer Forwarding Unit die basierend auf Labels entscheidet, was wohin weitergeleitet wird.

Der Geschwindigkeitsvorteil ist nicht so gewichtig, wie es oft dargestellt wird. Ob ein 20bit Label oder eine 32bit IP-Adresse analysiert wird, macht mit der heutigen Hardware (ASICs) kaum einen Unterschied.

MPLS und QoS[Quelltext bearbeiten]

MPLS hat nichts mit Quality of Service zu tun. Hierfür sind Protokolle wie RSVP zuständig. MPLS kann man nicht mit ATM vergleichen. MPLS ist ein Protokoll, ATM ist eher eine Übertragungstechnik. MPLS ersetzt Routing durch Switching und wird z.B. in Verbindung mit VPN´s eingesetzt.

MPLS ist KEIN Protokoll an sich!

MPLS ist genau genommen ein von der IETF entwickelter Satz an Standards, zu denen auch RSVP-TE und CR-LDP gehoeren. Beide Erweiterungen beschaeftigen sich mit dem Signalisieren von explizit gerouteten LSPs (uU mit TE Constraints versehen). Das QoS Routing ist eine Teilaspekt des Constraint-Based Routing (siehe RFC2702) und gehoert somit sehr wohl in den Kontext von MPLS. Es werden halt nur LSPs mit QoS Constraints versehen. RSVP-TE/CR-LDP sind nicht von MPLS zu trennen. RSVP hingegen schon. RSVP (RFC2210) ist eine konkrete Implementation des Integrated Service Modells (RFC1633) der IETF zur Realisierung eines Ende-zu-Ende QoS Verkehrsverhaltens.

Dennoch braucht dieser Artikel umbedingt Ueberarbeitung. Er ist teilweise inhaltlich ungenau und spiegelt viele aktuelle Entwicklungen nicht wider. Themen wie: GMPLS, Recovery Mechanismen, GELS, Point-to-Multipoint LSPs, VPNS (L3VPN, L2VPN (Pseudowires)).

Dazu möchte ich auch noch erwähnen, daß neben der Diskussion um QoS, auch die historische Darstellung nicht korrekt ist; z.B. ist GMPLS nicht erst eine Weiterentwicklung, sondern deutete sich schon in den ersten Produkten der Startup Firma Ipsilon mit GSMP (General Switching Management Protokol) für ATM Switche an. Außerdem existierten mit Toshibas CSR (Cell Switching Router), Ipsilons IP-Switching, IBMs ARIS (Aggregated Route-based IP Switching) und Ciscos TAG Switching gleich mehrere mehr oder weniger parallele Entwicklungen. Wobei Cisco und IBM hauptsächlich zur MPLS Standardisierung beigetragen haben. Die treibenden Kräfte hinter diesen Entwicklungen waren eine einfachere IPoATM Technik und Leistungsfähigere Vermittlung, d.h. schelleres routen durch switching Mechanismen. Dabei spielt VLSI eigentlich keine Rolle, viel wichtiger ist, daß der MPLS Forwarding Mechanismus stehts gleich bleibt und sich damit sogar für die Implementierung in Hardware anbietet. Denn was im Layer zweieinhalb passiert, ist die Trennung von Protokollen der höheren Layer vom Layer-2 Transport durch eine Abstraktionsschicht; eben Multiprotocol Label Switching.

TCP/IP Protokollstack[Quelltext bearbeiten]

In der Abbildung ist Ethernet als Schicht 1 angegeben. Dies entspricht jedoch nicht den Tatsachen. Schicht 1 nach ISO/OSI ist die physikalische Ebene, sprich Licht- oder Strom. Ethernet ist eindeutig Schicht 2. Bei MPLS scheiden sich noch die Geister, wohin es gehört. Rein logisch müsste es zwischen Schicht 2 (Ethernet, SDH, ATM, FR) und Schicht 3 (IP) liegen, da es immernoch auf Ethernet beruht aber IP nicht beachtet. --Bll0 15:22, 29. Jun 2006 (CEST)

BllO hat recht, allerdings auch wieder nicht. Problem ist eine Vermischung von TCP/IP-Referenzmodell und OSI-Modell bei der Einordnung von MPLS. Ueberschrift der Tabelle ist TCP/IP-Referenzmodell, davon kann man jedoch unten nichts sehen. Und dass Ethernet nicht OSI-Layer 1 ist, das ist wohl unbestritten. Dass es TCP/IP-Layer 1 ist, das stimmt, aber dann sollte das Layer auch Netzzugang genannt werden. Richtig ist auch seine Aussage, dass MPLS nicht TCP/IP-Layer 2 ist. --MarKuhs 16:44, 18. Aug 2006 (CEST)

MPLS liegt zwischen Schicht 3 und Schicht 2, wenn man sich die Schachtelung der Pakete anschaut. Da es sich aber um eine Vermittlungstechnik, genauer eine alternative, verbindungsorientierte Routingtechnik, handelt würde ich es Schicht 3 zuordnen. 134.245.17.9 09:58, 31. Jan. 2007 (CET)[Beantworten]

Warum kann man MPLS seinen Status zwischen Schicht 2 und 3 nicht einfach lassen?! Warum muss es unbedingt in das Referenzmodell gequetscht werden?

Header Format[Quelltext bearbeiten]

1. Was ist ein MPLS Header?

   ...whether the MPLS
   label values are carried in an MPLS-specific "shim" header [MPLS-
   SHIM], or if the MPLS labels are carried in an L2 header, such as an
   ATM header [MPLS-ATM] or a frame relay header [MPLS-FRMRLY].
  RFC3031
   The label stack entries appear AFTER the data link layer headers, but
   BEFORE any network layer headers.  The top of the label stack appears
   earliest in the packet, and the bottom appears latest.  The network
   layer packet immediately follows the label stack entry which has the
   S bit set.
  RFC3032

Einen Header gibt es nicht wirklich, das soll das Wort "shim" verdeutlichen. Es gibt hingegen "Label Stack Entries". Diese bestehen aus genau vier Feldern. Ein Label Stack setzt sich aus beliebig vielen Label Stack Entries zusammen. Einen wirklich Header gibt es jedoch nicht.

2. Wo ist der Datalink Layer Header im Bild? Das Bild dieser Einbettung ist in dieser Hinsicht nicht vollstaendig.

Gruss -- MarKuhs 16:43, 18. Aug 2006 (CEST)

Alcatel-PDF-Datei[Quelltext bearbeiten]

Dieser Link ist zu entfernen. Das ist kein Hersteller-Forum!

Danke vorab,

Uwe

Verfasse Artikel neu[Quelltext bearbeiten]

Hallo zusammen,

ich werde den Artikel neu aufsetzen.

Hoffe, daß niemand deshalb beleidigt ist. Es fehlen einfach zu viele Zusammenhänge und er ist zu ungenau.

Falls Ihr andere Meinung seid, dann halt copy & paste...

Cheers,

Uwe

Hallo Uwe, mit Sicherheit war ein gruendliches Ueberarbeiten des Artikels noetig. Die grundsaetzliche Struktur deiner Neufassung gefaellt mir besser als die alte Variante -- ich habe allerdings ein paar Anmerkungen, da mich -- leider -- doch noch an der jetzigen Fassung einige Dinge ziemlich stoeren:
  • Leider ist der Stil an vielen Stellen nicht richtig enzyklopädisch. Fragezeichen in Ueberschriften, "Licht am Ende des Tunnels", "wäre an dieser Stelle zu viel des Guten" -- solche Formulierungen wuerde man auch im Brockhaus nicht lesen.
  • Er ist leider auch zu weitschweifig. Der erste Absatz ist beispielsweise viel zu lang -- das soll ja kein Artikel ueber die Vor- und Nachteile von paket- bzw. verbindungsorientierter Datenuebertragung werden, sondern ueber MPLS. Und das tolle an der Wikipedia ist ja, dass man so einfach Links setzen kann. Wenn der Leser nicht weiss, was ein Begriff bedeutet, kann er einfach auf den Link klicken. Gut, ein ganz kurzer Abriss ueber den Unterschied zwischen verbindungslos und verbindungsorientiert ist vielleicht nicht verkehrt, aber in dieser Form zu allgemein und zu lang.
  • Du nennst leider keinerlei Wikipedia:Quellenangaben. Insbesondere bei gewagten Aussagen wie "Das Verhältnis zwischen Daten und Sprache in den bestehenden Netzwerken liegt bei ungefähr 30/70 (also 70% Sprache)" waere eine Quellenangabe sehr, sehr, sehr angebracht.
Bitte nimm meine Kritik nicht persoenlich. Ich werde mal schauen, dass ich auch ein bissel was ueberarbeite, hab aber im Moment nicht viel Zeit. --Wutzofant (✉✍) 20:56, 6. Mär. 2007 (CET)[Beantworten]

Artikel überarbeitet[Quelltext bearbeiten]

Hallo Nils,

schau noch einmal drüber. Habe den Text gestrafft. Bilderchen folgen noch.

Der Artikel deckt den Bereich MPLS-over-ATM und MPLS-over-FrameRelay nicht ab. Wird dann zu komplex.

Kommentar erwünscht.

Gruss,

Uwe

Hallo, erstmal danke für deine Mühe. Ich habe bei VL/VO immer unzuverlässige/zuverlässige Verbindungen im Hinterkopf. Das klingt im Moment noch so so, als hätte es etwas mit der Wegfindung zu tun. Habe noch ein paar Dinge verbessert, also nicht wundern.

Die alten Links kommen doch auch noch wieder? MfG Marco

VL/VO -> unzuverlässige/zuverlässige Verbindungen[Quelltext bearbeiten]

Hallo Marco,

das liegt vielleicht an dem Phänomen der "Eindeutschung" englischsprachiger Begriffe.

Verbindungslos = Connection-less

Verbindungsorientiert = Connection-oriented

Es geht hier also nicht um die Thematik Zuverlässigkeit (reliable transport).

Die Verbindungslosigkeit bezieht sich im netzwerktechnischer Hinsicht auf die Tatsache, daß die einzelnen Daten-Pakete unabhängig voneinander von den Vermittlungssystemen (Routern) weitergeleitet werden. Das zeigt auch die Problematik, daß der Hin- und Rückweg von (in diesem Fall IP-Paketen) zwischen Sender und Empfänger sehr oft unterschiedlich ist. Bedingt wird das durch das dynamische Routing-Verhalten mit autonomer Wegewahl durch die Router an sich.

Die Zuverlässigkeit des Datentransportes zwischen 2 Endgeräten (oder auch zwischen 2 Routern, z.B. mittels TCP als Basis für BGP-Sessions) wird durch übergeordnete Protokolle wie TCP gewährleistet. UDP-basierte Kommunikation gewährleistet zum Beispiel diese Zuverlässigkeit nicht.

Beantwortet das Deine Frage?

Beste Grüße,

Uwe

--- Hallo! Ja, das tut es. Habe mich da zu sehr von zwei zugehörigen (beispielhaften) Protokollen leiten lassen (TCP (rel.) /UDP (unrel.)). Jetzt weiß ich es genauer :) MfG Marco

verbindungslos/-orientiert vs. leitungs-/paketvermittelnd[Quelltext bearbeiten]

Hallo, ich denke, dass das Begriffspaar verbindungslos/-orientiert hier falsch verwendet wird. Es müsste leitungsvermittelnd, bzw. paketvermittelnd heißen.

Bespielsweise ist TCP ein verbindungsorientiertes Protokoll, UDP aber ein verbindungsloses Protokoll. Beide Protokolle werden jedoch in IP-Paketen übermittelt, wobei jedes Paket von einem Router prinzipiell unabhängig weiterversandt wird. Deswegen wird das IP-Protokol auch "paketvermittelnd" genannt.

Bei einem leitungsvermittelnden Verfahren wird vorab der Weg festgelegt. Dieser bleibt während der ganzen Kommunikation fest. Ein bekanntes System bei dem Leitungsvermittlung eingesetzt wird, ist z.B. die klassische Telefonie (sowohl analog als auch ISDN). Hier wird der Weg während des Verbindungsaufbau durch den Wählvorgang festgelegt. Das gleiche Prinzip findet bei MPLS statt.

Festzuhalten ist auch, dass wir hier über zwei verschiedene Schichten des OSI-Modells reden. Verbindungsrorientiert-/los ist eine Eigenschaft der Transportschicht (Schicht 4, engl. transport layer). Paket-/Leitungsvermittelnd ist eine Eigenschaft der Vermittlungsschicht (Schicht 3, engl. network layer).

Grüße, Matthias -- 15:40, 24. Nov. 2007 (CET)

Überarbeitung[Quelltext bearbeiten]

Hallo,

schön, dass sich an dem Artikel so viel Neues tut! Es sollte noch mehr darauf geachtet werden, den Text verständlicher zu schreiben. Oft fehlt auch die Motivation für einen bestimmten Sachverhalt. Worin besteht der Sachverhalt und warum wurde es genau so gelöst? Auch finden sich in der unteren Hälfte des Texts nur ein einziger Link. Die vielen Details sind teilweise verwirrend. --Gimbal 23:00, 15. Mär. 2007 (CET)[Beantworten]

Rechtschreibfehler[Quelltext bearbeiten]

kann es sein dass: MPLS Label Stack Entry (MPSL Shim Header), korrekterweise MPLS Label Stack Entry (MPLS Shim Header) Da ich nicht so firm in diesem Bereich bin wollte ich nicht in dem Artikel rumpfuschen SlayMan 10:06, 30. Jan. 2008 (CET)[Beantworten]

MPLS heute und in der Zukunft: Eigene Theorie?[Quelltext bearbeiten]

Grundsätzlich führt die MPLS-Technologie die unabhängige Paketvermittlung (verbindungslos) zurück
zur Leitungsvermittlung durch LSPs (verbindungsorientiert). Damit werden einige Vorteile der
IP-basierten Kommunikation von jedem zu jedem (Any-to-Any), mit all ihrer Flexibilität und guten
Skalierbarkeit, durch die Stärken verbindungsorientierter Kommunikation eingeschränkt (Komplexität,
n-square-Problematik, etc.).

Gibt es dafür vielleicht Nachweise/Quellen? Oder ist das eine private Meinung/Theorie? mfg, --80.136.108.252 17:52, 5. Apr. 2008 (CEST)[Beantworten]

Der Link zu MPLS-Linux ist einfach kommentarlos in den Weblinks. Es wird nirgends darauf Bezug genommen. Ausserdem kann man MPLS-linux dort nicht mehr herunterladen, der Link scheint etwas alt zu sein. --Chevarri 14:29, 25. Okt. 2010 (CEST)[Beantworten]

Das gleiche ist wahr für die OpenBSD-Links, die zudem noch auf "irgendwelche" veraltete Kopien von Source-files auf "irgendeinem" Server linken, anstatt auf das Original-Repository. Besserer es Ziel wäre z.B. mpe(4). Man kann es aber auch einfach entfernen. --2001:638:401:102:250:56FF:FEB2:39C6 14:50, 14. Aug. 2015 (CEST)[Beantworten]

Verbindungslos[Quelltext bearbeiten]

Was ist unter einem "verbindungslosen" Netz zu verstehen? Die Wortwahl macht eigentlich nur Sinn in einem Satz in dem es um Verbindungsaufbau geht bzw. eigentlich gar keinen wenn es im Satz über den Austausch von Paketen geht. <no-login> (nicht signierter Beitrag von 93.184.191.132 (Diskussion) 09:47, 5. Mai 2014 (CEST))[Beantworten]