Funktion und Eigenschaften MPLS

Die Internet Engineering Task Force versucht unter dem Begriff "Multi Protocol Label Switching" (MPLS) die Reihe der proprietären Protokolle des IP Switching, wie Cisco’s TAG-Switching, IBM’s Aggregate Route-based IP-Switching oder Toshiba’s Cell Switching Router unter einem allgemeinen Standard zu vereinen. Das heute in der Definitionsphase befindliche MPLS umfasst bereits über hundert verschiedene Internet Drafts zu Encapsulation, Routing, Traffic Engineering etc. RFCs zum Thema MPLS wurden bislang sieben Dokumente verabschiedet. Dies über die Themen Architektur, LDP, VPN und Traffic Engineering [M1-M6, M16].

MPLS adressiert eine flexible Lösung, um die heute in grossen Netzen vorhandenen Einschränkungen, wie Skalierbarkeit, fehlende Quality-of-Service Eigenschaften und Möglichkeiten des Traffic Engineerings zu lösen. Den Herstellern von MPLS zufolge verbindet die Technik die Vorteile des IP-Routings mit den Vorteilen der Layer 2 Switching Technik und bietet dem Netzbetreiber uneingeschränkt Möglichkeiten, sein Netz einfach und effizient zu betreiben. MPLS lässt sich im Wide Area Network wie in grösseren Local Area Networks einsetzen.

Mit MPLS werden dem Netzbetreiber folgende Services geboten:

Spezifiziert Mechanismen, um Verkehrsflüsse beliebiger Anwendungen zu steuern und zu managen (Traffic Engineering).
Vereinfachtes und dadurch schnelles Weiterleiten von Layer 3 (IP) Paketen anhand fixer Labels (Performance).
Die Unabhängigkeit zwischen Layer 2 und 3 bleibt gewährleistet. Integration und Unterstützung etablierter Techniken, wie ATM, Frame-Relay, PoS, etc.
Trennung der Datenströme von der Signalisierung (Routing).
Schnittstellen zu existierenden Routing Protokollen wie OSPF, IS-IS, RIP etc.
Möglichkeiten zur Implementierung neuer Routing Protokolle, ohne dass der Datenfluss beeinträchtig wird.
Verbesserte Skalierbarkeit des Routings durch Stapeln von Labels (Labelstack).
Möglichkeiten von Virtual Private Networks, VPN.

Die MPLS Architektur [M1] gliedert sich in verschiedene Funktionen. Die einzelnen Funktionen werden jedoch nicht als eigenständige Komponenten realisiert, sondern mehr als Gruppierung verschiedener im Netz enthaltener Aufgaben oder Protokolle betrachtet. Die Funktionen sind:

Einschachtelung in den Data Link Layer (Encapsulation).
Label Mapping am Edge
Network Layer (IP) Routing Protokolle
Label Verteilung (LDP) und Signalisierung
Label-based Switching Core Netz (Forwarding)
Traffic Engineering

Im weiteren kann die MPLS Architektur als Protokollstack dargestellt werden. Auch hier gilt zu beachten, dass MPLS nicht als eine alleinige Technik verstanden wird, sondern als Ergänzung zu bestehenden Techniken definiert wurde. Durch die Kompatibilität zu bestehenden Techniken, zeigt sich der Protokollstack deshalb auch recht umfangreich.

Abbildung 1 MPLS Protokollstack

Wie aus der Abbildung ersichtlich, wurde das MPLS Forwarding (Switching) zwischen dem Internet und dem Network Layer eingefügt. Dies ermöglicht die optimale Verbindung von schnellen Switching Techniken mit dem Layer 3 (IP) Protokoll. Das MPLS Forwarding beinhaltet aber nur einen Teilaspekt des Protokollstacks. Während die Verteilung der Labels bereits im Application Layer oder im Transport Layer definiert wurde, erstreckt sich die Technik des Forwarding bis zum Network Layer, bei dem anhand der Labels die Pakete durch die Netzknoten geschalten werden. In den weiteren Kapiteln werden die einzelnen Funktionen und Protokolle detaillierter beschrieben.

Die Label Switching Router LSR und die Label Edge Router LER bilden die Hauptkomponenten in einem MPLS basierten Netz. Die LSR werden im Corebereich eingesetzt, während die LER die Grenze (Edge) zum MPLS Netz bilden. Der Customer Edge Router bildet den Netzzugang auf Teilnehmerseite.

Abbildung 2 LSR, LER und CER

Ein Label Switching Router ermöglicht das schnelle Durchschalten von IP Paketen anhand von fixen Labels. Die Funktionsweise des Weiterschalten (Forwarding) von Paketen ist derjenigen von ATM oder Frame-Relay Switches ziemlich ähnlich. Die Pakete werden beim Eintreffen am Eingangsport auf deren Labels untersucht und entsprechend der Forwarding Table durch den Router an das Ausgangsport weitergereicht. Bevor die Pakete auf den neuen Leitungsabschnitt übertragen werden, werden die Labels mit den neuen, für diesen Abschnitt gültigen Werten ersetzt. Die Labels werden pro Leitungsabschnitt durch ein Label Signaling Protocol von LSR zu LSR, von LER zu LSR oder von LSR zu LER gegenseitig ausgehandelt. Ein LSR findet seine Anwendung im Corebereich und wird oft auch als P-Router (P = Provider) bezeichnet.

Die LER werden an der Schnittstelle eines herkömmlichen IP Netzes zu einem MPLS basierten Netz eingesetzt. Die Router unterstützen dazu für den Accessbereich sowohl Schnittstellen der xDSL Anschlusstechniken als auch im Corebereich MPLS erweiterte WAN- bzw. Backbone Schnittstellen. Die LER bilden die Endpunkte eines Label Switched Paths innerhalb des MPLS Netzes. Die LER beinhalten eine der wichtigsten Aufgaben im Zuweisen und Entfernen von Labels. Sie bestimmen über die verschiedenen Service Aspekte, indem sie jedem Paket ein entsprechendes Label und damit einen Übertragungskanal zuweisen. In vielen Dokumentationen werden die LER als Provider Edge (PE) oder vereinfacht als LSR benannt.

Die CER werden in den Lokalitäten der Kunden installiert und bilden den Zugang zum Netz. Die CER sind herkömmliche Router, welche dem Kunden die LAN Schnittstellen (Ethernet) zur Verfügung stellen, sowie eine Schnittstelle (xDSL) zum WAN haben. Zwischen den CER und den LER werden die Pakete konventionell, d.h. ohne MPLS Mechanismen, übertragen. Als Übertragungsstrecke zwischen CER und LER eignen sich xDSL Techniken.

Der MPLS Header [M3], auch kurz als Label oder Shim-Header benannt, umfasst die fixe Länge von 32 Bit (4 Oktett) und ist zwischen dem Data Link Layer (Layer 2 Header) und dem Network Layer Header (IP Header) eingepackt. Je nach Layer 2 Protokoll wird der MPLS Header in einem separaten Header (Shim-Header) oder in bestehenden Layer 2 Protokollfeldern untergebracht.

Abbildung 3 MPLS Header

Label

Das Labelfeld umfasst 20 Bits. Sein Wert identifiziert einen unidirektionalen Pfad eindeutig. In Verbindung mit ATM werden die Labelwerte in den Feldern des VPI und VCI und in Verbindung mit Frame-Relay im DLCI Feld übertragen. Dabei sind verschiedene Optionen möglich (siehe Encapsulation). Bei Übertragungstechniken, wie Ethernet oder PPP kennzeichnen die Labelwerte neue virtuelle Pfade, während bei ATM und Frame-Relay auf dem bestehenden Konzept der virtuellen Verbindung aufgebaut wird.

Experimental Field (Exp) oder Class of Service (CoS)

Das Feld CoS wurde durch Cisco’s TAG Switching definiert. Die definitive Benutzung dieses Feldes wurde jedoch noch nicht in einem Standard festgelegt, weshalb das Feld von der MPLS Arbeitsgruppe in Experimental umbenannt wurde. Der Verwendungszweck des Experimental Feldes dient jedoch zur Kennzeichnung des Übertragungsverhaltens von Paketen durch die Label Switch Router (Policing, Buffer, etc).

Stack

MPLS unterstützt ein hierarchisches System von Labeln, genannt Labelstack. Das Verfahren funktioniert nach dem last-in-first-out, LIFO-Prinzip. D.h. es wird bei einem Stapel von Labels jeweils nur das oberste Label im Stack berücksichtigt. Das Stack Feld, mit seiner Grösse von einem Bit, kennzeichnet mit dem Wert 1 das Ende (Bottom) eines Labelstacks. Alle weiteren Labels beinhalten im Stack Feld den Wert 0. Mit dem Labelstack lassen sich gezielt hierarchische Routing Domains bilden (Tunneling Mode).

Time To Live, TTL

Das Time To Live Feld beinhaltet 8 Bits und entspricht weitgehend dem TTL Feld des IP Headers. Mit jedem Durchlaufen eines LSR wird der Wert im Feld um mindestens eins reduziert. Enthält das Feld den Wert 0, wird das Paket verworfen. Am Zugang zum MPLS Netz wird der Wert des IP TTL Feldes in das MPLS TTL Feld kopiert. Verlässt ein Paket das MPLS Netz wird sein aktueller Wert zurück in das IP TTL Feld kopiert.

MPLS unterstützt eine Reihe von Layer 2 Techniken (Data Link Layer). Dies sind im LAN Bereich sowohl Ethernet, FDDI wie auch Token Ring. Bei den Techniken im WAN Bereich sind es vorwiegend ATM, Frame-Relay und PPP. Einige davon werden zwar in den Spezifikationen behandelt, eine Realisierung deren dürfte sich aber durch die geringe Ausbreitung der Übertragungstechnik oder technischer Limitationen kaum breit durchsetzen. Ähnlich verhält es sich mit den Layer 3 Protokollen. Während IPv4 bereits über die MPLS Technik implementiert wurde, dürften weitere Layer 3 Protokolle kaum einmal mit MPLS in Berührung kommen. Auch werden in den Internet Drafts beinahe unmögliche Verbindungen, wie Sonet over MPLS erwähnt, welche seinerseits jedoch bereits an die Grenzen des physikalisch Machbaren und Sinnvollen stossen.

Zwischenlayer (Shim-Header)

Netzwerktechniken und Protokolle wie Ethernet, FDDI, Token Ring oder PPP beinhalten keinen paketorientierten Data Link Layer, welcher seinerseits bereits Labels zur Verwaltung virtueller Pfade unterstützt. Bei diesen Netzwerktechniken oder Protokollen wird der MPLS Rahmen zwischen dem Data Link Layer und dem Network (IP) Layer als Zwischenrahmen (Shim-Header) [M4] eingefügt. Wird MPLS als hierarchisches System verwendet, folgen sich die MPLS Header unmittelbar. Folgende Abbildung zeigt den Shim-Header in Verbindung mit LAN Techniken bzw. Protokollen und PPP.

Abbildung 4 MPLS Shim Header

ATM

Bei der ATM Technik gestaltet sich das Mapping des MPLS Header in die ATM Zellen [M5] komplexer. Die Labels werden durch drei mögliche Optionen in die VPI und VCI Felder eingepasst. Die erste Option ermöglicht im VPI und im VCI Feld unabhängige Labels, wobei die Länge der Labels nur noch 8 Bit bzw. 16 Bit beträgt. Die zweite Option nutzt das VPI und das VCI Feld als ein einziges Feld (combined Label) und ermöglicht so die Übertragung des vollständigen Labels. Die dritte Option belässt das VPI Feld unverändert unter der Kontrolle der ATM Steuerung und nutzt nur das VCI Feld zur Übertragung eines 16 Bit langen Labels.

Die Felder Experimental, Stack und Time to Live werden zu Beginn der Service Data Unit, SDU im ATM Adaption Layer 5 übertragen. Ebenfalls in der Service Data Unit werden die weiteren Labels, bzw. MPLS Header bei hierarchischen Netzen übertragen.

Sämtliche Zellen, welche zur Übertragung eines AAL5 Rahmens benötigt werden, tragen die selben Label im VPI und VCI Feld. D.h. die VPI und VCI Werte der ersten Zelle werden in die folgenden Zellen kopiert.

 

Abbildung 5 Mapping MPLS in ATM Zellen

Frame-Relay

Im Gegensatz zu ATM unterstützt Frame-Relay Rahmen (Frames) mit unterschiedlicher Länge. Die Länge der Frames wird vom Network Layer bestimmt. Die Frame-Relay Technik fügt dazu nur die Flags, den Header und die Frame Check Sequence dazu. Trotzdem wurde bei der Frame-Relay Technik nicht einfach der Shim Header dazwischen geschaltet. Die Labels werden ins DLCI Feld gemappt und Experimental-, Stack- und TTL-Feld werden vor den Layer 3 Header eingefügt. Der Frame-Relay Header unterstützt Labels mit der Länge von 10 Bits. Je nach Gebrauch des Extended Header können die Labellängen 17 oder 20 Bit betragen. Folgende Skizze zeigt das Mapping.

Abbildung 6 Mapping MPLS in Frame-Relay

Allgemein gibt es zu bemerken, dass für sämtliche Techniken, die MPLS Hardware nicht mit den konventionellen Schnittstellen verglichen werden kann. Ein konventionelles ATM Interface wird beispielsweise vollständig von den Kontrollmechanismen der ATM Technik gesteuert, während ein MPLS-ATM Interface die Steuerungsmechanismen der MPLS Technik (Bsp. Label Distribution Protocol) verwendet. MPLS basierte Schnittstellen werden als LC-ATM (Label Switching Controlled ATM) oder LC-FR (Label Switching Controlled FR) bezeichnet.

Die Erzeugung von Labels (Label Creation) kann in einem MPLS Netz vereinfacht auch als Trigger zwischen LSR betrachtet werden, um Labels auszutauschen. Da die Labels nur lokale Gültigkeit zwischen zwei LSR haben, stellt MPLS Mechanismen zur Verfügung, welche die Labels gegenseitig zwischen den Routern aushandeln. Wie erwähnt sind die Labels an eine Forward Equivalence Class (FEC) gebunden, welche seinerseits wiederum einen Übertragungskanal mit unterschiedlichen Übertragungseigenschaften repräsentiert. Die Anbindung von Labels an eine FEC wird nach den MPLS Drafts als Label Binding benannt.

Der Aufbau eines Übertragungskanals erfolgt entweder durch Steuerungs- bzw. Kontroll-Mechanismen (Control Driven Bindings) oder durch die Erkennung eines Network Layer Datenstromes (Data Driven Bindings).

Control Driven Binding Steuerungs- bzw. Kontroll-Mechanismen
Data Driven Binding Erkennung eines Datenstromes

Die Control Driven Bindings werden weiter unterschieden in:

Topology-based Method

Die Topologie basierte Methode benutzt zum Erzeugen von Labels die normal in IP Netzen vorhandenen Routingprotokolle, wie OSPF, BGP, etc. [M7, M8].

Request based Method

Das Erzeugen von Labels erfolgt bei der Request based Method mit dem Resourcen Reservation Protocol oder mit dem Label Distribution Protocol [M2, M9]

Im weiteren wird das Data Driven Binding auch als Traffic based Method benannt:

Traffic based Method

Nutzt die Bestätigung von Paketen als Impuls zur Zuweisung und Verteilung von Labels.

Wenn ein Label Switched Router einer Forward Equivalence Class ein Label zuweist um einen Label Switched Path (LSP) [M1] aufzubauen, muss der Router am anderen Ende des Links (Peer) diesen Labelwert erkennen können, damit die Pakete eindeutig dieser FEC zugeordnet und auf den nächsten Abschnitt des Pfades weitergeleitet werden können. Beide Router halten in ihren Tabellen den selben Labelwert, welcher auf dem Link zwischen den beiden Anschlussports einen eindeutig virtuellen Pfadabschnitt identifiziert. Der sendende Router kennzeichnet somit alle Pakete zu einer spezifischen FEC gehörend mit den selben Labels und schickt diese auf das Ausgangsport, während der empfangende Router am Eingangsport alle Pakete mit dem selben Labelwert zur spezifischen FEC identifiziert und entsprechend seiner Tabelle weiter zum Ziel schickt. Die Verkettung der Labels und die damit verknüpften virtuellen Pfadabschnitte bilden den Label Switched Path (LSP). Jeder LSP ist unidirektional. Nachfolgendes Bild zeigt den Zusammenhang der Verkettung von virtuellen Pfadabschnitten.

Abbildung 7 Label Switched Path

Der LSP erfährt durch die Router unterschiedliche Durchlaufzeiten und Paketverluste. Die Gesamtheit der Übertragungscharakteristiken, wie Bitrate, Verzögerung, Verzögerungsvariation, Paketverlust, etc. entscheidet über die Möglichkeit, ob den verschiedenen Anwendungen das nötige Übertragungsprofil zur Verfügung gestellt werden kann. Ist dies der Fall, werden die Quality of Service Anforderungen erfüllt, ansonsten wird die Anwendung durch die Übertragung beeinträchtigt.

Eine der grössten Vorteile von MPLS sind Explicit Routet LSP, d.h. nach bestimmten Kriterien gesteuerte Pfade [M11, M12] durch das Netz (siehe dazu auch MPLS Traffic Engineering). Dazu wird durch das Routingprotokoll eine Liste von Loopback-Adressen der Router, die das Datagramm durchlaufen soll, ermittelt. Die Ermittlung des Pfades erfolgt aufgrund eines erweiterten Shortest Path First Algorithmus, dem Constraint Shortest Path First Algorithmus (CSPF), welcher in der bisherigen einfachen Form in OSPF oder IS-IS Verwendung findet. Die Erweiterung besteht darin, dass neue Attribute der Leitung oder der Router, welche zur Erbringung von QoS notwendig sind, mitberücksichtigt werden. Die Liste der IP-Adressen wird bei der Anfrage von Labels mit der Label Request Message oder der RSVP Path Message mit auf den Weg geschickt. Jeder Router (Hop) extrahiert daraus seinen nächsten Peer und schickt die Labelanfrage nach dem spezifizierten Pfad durch das Netz.

Explicit Routed LSP, kurz ER-LSP ermöglicht zwei Arten von spezifizierten Pfaden durch das Netz:

strict ER-LSP

Strict ER-LSP definiert den exakten Pfad zwischen zwei Endpunkten (LER). Alle LSR (Hops) sind demnach in der Liste enthalten, die das Datagramm von der Quelle zum Ziel durchlaufen soll. Strict ER-LSP {LER 5; LSR 1; LSR 2; LSR 3; LER 8}

Abbildung 8 Strict ER-LSP

loose ER-LSP

Loose ER-LSP erlaubt nur Teile des Pfades zwischen zwei Endpunkten (LER) zu spezifizieren. Der LSP kann somit über Teile des Netzes frei und über einen Teil des Netzes nach vorgegebener Route erfolgen.
Loose ER-LSP {LSR 2;LSR 3;LER 8}

Abbildung 9 loose ER-LSP

Die MPLS Architektur erlaubt den LSR zwei Arten der Labelwert Vergabe [M2]. Einerseits erfolgt die Vergabe pro Router (per platform) oder für jedes im Router enthaltene Interface oder Port (per interface).

per platform

Jeder Wert eines Labels wird im ganzen LSR nur einmal vergeben. Zwei verschiedene Schnittstellen beinhalten so nie einen identischen Labelwert. Die Labels werden von einer einzigen Administration im LSR verwaltet. Diese Form wird hauptsächlich in LSR verwendet, welche Schnittstellen mit Shim Header enthalten. Der Vorteil liegt in der einfachen Label Administration.

per interface

Jedes Interface oder Port beinhaltet seine eigene Label Administration. Die Labelwerte sind deshalb nur für jedes einzelne Interface einmalig und können pro LSR mehrmals vergeben werden. Diese Form wird in LSR verwendet, welche Frame-Relay und ATM Schnittstellen enthalten. Der Vorteil dieser Form liegt in der grösseren Gesamtanzahl von Labels, welche dem LSR zur Verfügung steht. Frame-Relay und ATM Schnittstellen unterstützen nur einen kleinen Bereich von Labels. Bei einer zentralen Vergabe der Labels könnte der untere Labelbereich bei mehreren Schnittstellen schnell einmal ausgeschöpft sein.

Die Label Verteilung oder auch Label Verbreitung ist eine der aufwändigsten Funktionen im MPLS. Etliche Implementierungen der Label-Verteilung wurden bereits in den verschiedenen proprietären IP Switching Techniken realisiert. Die Verteilung der Labels erfolgt jedoch immer zwischen den LSR mit einer Anfrage- und Antwort Sequenz.

Abbildung 10 Label Distribution

Die MPLS Architektur unterstützt den auch nicht nur eine Möglichkeit der Label Verteilung, sondern bislang deren vier.

Label Distribution Protocol, LDP

Das Label Distribution Protocol, LDP wird benutzt, um Unicast IP Destinationen den Labels zuzuweisen [M2].

RSVP-TE, CR-LDP

Die beiden Protokolle Resource Reservation Protocol - Traffic Engineering (RSVP-TE) und Constraint-based Routing - Label Distribution Protocol (CR-LDP) erweitern die Labelzuordnung mit der Möglichkeit, Ressourcen zu reservieren und Datenströme zu beeinflussen (Traffic Engineering) [M9, M10].

Protocol-Independent Multicast, PIM

Protocol-Independent Multicast ermöglicht Datenströme mit mehreren Zieladressen Labeln zuzuweisen [M13].

Border Gateway Protocol, BGP

Erweiterungen des Border Gateway Protocols, BGP [M8] ermöglichen die Verteilung der Labels über Netzdomains hinaus und erlauben so die Realisierung von Virtual Private Networks.

MPLS ermöglicht verschiedene Moden des Routings, der Label Verteilung und der Label Zuordnung:

Hop-by-hop Routing und Explicit Routing
Independent Label Control und Ordered Label Control
Downstream on Demand Label Advertisement und Downstream Unsolicited Label Advertisement
Conservative Label Retention und Liberal Label Retention

Hop-by-hop Routing

Jeder LSR wählt beim Hop-by-Hop Routing [M1] seinen unmittelbaren nächsten Router für jede FEC nach eigenständigen Kriterien aus. Diese Methode ist analog des heute in Gebrach befindlichen IP-Routings. Die Label Switch Router benutzen dazu auch die konventionellen Routing Protokolle wie OSPF, IS-IS, RIP, etc.

Explicit Routing

Das Explicite Routing [M1] gleicht der Methode des Source Routings. Die Quelle, bzw. der Ingress Router spezifiziert eine Liste von Router (Nodes), durch welche der LSP aufgebaut und unterhalten wird. Je nach Fähigkeiten der Signalisierung wird der Pfad, bzw. der Datenverkehr optimal durchs Netz geleitet. Der Vorteil dieser Option liegt darin, dass die Resourcen entlang des Pfades besser differentiert und reserviert werden können. Das Explicit Routing ermöglicht so ein einfacheres Traffic Engineering und erlaubt die Überwachung von QoS Aspekten.

Independent Label Control

Der Independent Label Control Modus [M1] wird hauptsächlich beim Destination Based Routing angewendet. Jeder LSR entscheidet unabhängig darüber, welcher FEC er ein Label zuweist und ob er den Peer Router über diese Zuweisung informiert. Mit dem „Independent Label Control" Mode wird angenommen, dass der LSP nahezu dem Routing des Layer 3 Paketes folgt. Der Vorteil dieser Methode liegt beim schnellen Austausch von Labels, während der Nachteil bei einer möglichen unterschiedlichen Behandlung über die FEC liegt.

Ordered Label Control

Die Alternative zum Independent Label Control Mode bietet der Ordered Label Control Mode [M1]. In diesem Mode erfolgt die Zuweisung der Labels geordnet vom Ende des Pfades bis zum Beginn dessen. Der einzige LSR, welcher eine Zuweisung von Labels initiieren kann, bildet der Egress Label Edge Router. Dieser erkennt eine FEC und weiss anhand seines Ausgangsports, dass in Richtung Ziel kein LSR mehr folgen kann. Darauf informiert er über die weiteren Ports sämtliche an ihn angeschlossenen Peer-LSR. Jeder Peer-LSR, welcher glaubt der Egress LSR sei der nächste Hop für die genannte FEC weist in seiner Tabelle das Label zu und informiert darauf seine weiteren an ihn angeschlossenen LSR, usw.

Die beide Moden Independent Label Control und Ordered Label Control sind gegenseitig unabhängig und kompatibel zueinander.

Abbildung 11 Ordered Label Control

Downstream on Demand Label Advertisement

Downstream on Demand Label Advertisment [M1] spezifiziert die Zuordnung eines Labels zur FEC nach einer Label Anfrage (Label Request) des im Datenstrom der Quelle näherliegenden LSR.

Abbildung 12 Downstream on Demand Label Distribution

Downstream Unsolicited Label Advertisement

Downstream Unsolicated Label Advertisment [M1] erlaubt einem LSR die Zuordnung von Labels zu einer FEC auch ohne Label Anfrage des im Datenstrom der Quelle näher liegenden LSR.

Abbildung 13 Downstream unsolicited Label Distribution

Conservative Label Retention

Der Conservative Label Retention Modus [M1] erlaubt dem LSR nur diejenigen Labels einer FEC zuzuweisen, welche er gerade für die aktuellen Datenströme benötigt. Alle weiteren Zuordnungen von Labels zu FECs werden gelöscht. Durch die sparsame Nutzung der Labels wird dieser Modus in Verbindung mit der Frame-Relay und ATM Technik vorgeschlagen.

Liberal Label Retention

Alle Zuordnungen von Labels zu FECs, welche von den Peer-LSR angefragt wurden, werden im Liberal Label Retention Modus [M1] vom LSR unterhalten, auch wenn deren momentane Existenz nicht sinnvoll erscheint. Falls ein LSR eine Zuordnung eines Labels zu einer spezifischen FEC unterhält, adressiert er diese Zuordnung an seine Nachbarn (nachfolgend benannt als N). Die Nachbarn entscheiden aufgrund ihrer Routingeinträge, ob sie als unmittelbarer, der Route folgender Nachbar, in Frage kommen (next hop for a given FEC). Falls nun LSR N bemerkt, dass dies nicht zutrifft und der Datenverkehr nicht über ihn geleitet werden kann, behält er die Zuweisung des Labels zur FEC trotzdem aufrecht. Bei Änderungen des Routings und der Möglichkeit, dass LSR N neu als next Hop erscheint, braucht dieser nur seine Labeltabelle zu aktualisieren, ohne dass ein Aushandlung von Labels neu erfolgen muss. Der Vorteil dieser Methode liegt in der schnellen Reaktion eines LSR auf Routingänderungen.

Das Label Distribution Protocol (LDP) [M2] ist ein neues, mit MPLS definiertes Protokoll, das die Verteilung und Aushandlung von Labels mittels Meldungen und Prozeduren zwischen zwei Label Switch Router (LSR) oder einem Label Edge Router (LER) und einem Label Switch Router erlaubt (LSR). Das Label Distribution Protocol automatisiert die Verteilung der Labels vom Ingress LER bis zum Egress LER (oder umgekehrt) und ermöglicht das Mapping der Labels vom Network Layer Routing zum Data Link Switched Path. D.h. das Label Distribution Protocol ermöglicht den gesamten Aufbau des LSP entlang der LSR. Das Protokoll beinhaltet folgende Eigenschaften:

Erkennung und Unterhalt der Anwesenheit von LSR in einem MPLS Netz
Beinhaltet vier Kategorien von Meldungen zum Unterhalt eines MPLS Netzes
Benutzt den Transportlayer, TCP und UDP zur Übertragung der Meldungen
Wurde skalierbar und somit zur einfachen Erweiterung der Meldungen entwickelt.

Zwei Label Switched Router, welche zum Austausch der Labels das Label Distribution Protocol benutzen werden in der MPLS Architektur als LDP Peer oder Nachbarn gekennzeichnet. Die beiden LSR unterhalten dazu gegenseitig eine LDP Session. Bei diesem Meldungsaustausch lernt ein LSR die Zuweisungen von Labels zu einer FEC des jeweilig anderen LSR. Das Protokoll ist bidirektional aufgebaut. Jede LDP Session entspricht (mit einer Ausnahme) einer zuverlässigen TCP Session im Transport Layer.

Das Label Distribution Protocol definiert vier Typen von Meldungen, bzw. Prozeduren.

Discovery Messages
Session Messages, Session Establishment
Advertisement Messages
Notification Messages

Der Meldungsaufbau einer LDP-Meldung erfolgt nach folgender Abbildung:

Abbildung 14 LDP Message

Die einzelnen Felder bedeuten:

Version

Identifiziert die Protokollversion, aktuell LDP Version 1.

PDU Length

Enthält die gesamte Länge der Meldung ohne die Versionsnummer und die PDU Länge.

LDP Identifier

Dieses Feld identifiziert den Label Bereich und die eigene IP Adresse, des sendenden LSR. Die ersten vier Oktett enthalten die IP Adresse. Die restlichen zwei Oktetts sind zur Übertragung des Labelbereichs bestimmt.

LDP Message

Der Rest der PDU ist für die einzelnen Message Typen, wie Label Request, Label Mapping, etc. reserviert. Alle Meldungen werden nach der selben Struktur, der Type-Length-Value (TLV), übertragen.

 

Der Aufbau einer LDP Session und die Aushandlung der Labels erfolgt stets nach dem selben Prinzip. Die Router kündigen im Netz ihre Präsenz durch Hello Messages an eine definierte UDP Portnummer an. Erkennt ein LSR einen weiteren LSR und entschliesst sich mit diesem eine Kommunikation aufzubauen, wird eine TCP-Session aufgebaut und Parameter zur gegenseitigen Information ausgetauscht. Nach der Initialisierung und der Erkennung oder Änderung einer spezifischen FEC werden Labels angefragt und ausgetauscht bzw. zugeordnet. Nachfolgende Abbildung zeigt grob den Ablauf, während die folgenden Kapitel detaillierter die Meldungstypen und den Ablauf beschreiben.

Abbildung 15 LDP Session

Discovery Messages

Mit den Discovery Messages kündigt ein neuer LSR seine Präsenz im Netz an. Dies erfolgt durch regelmässige Hello Messages. Die Discovery Messages werden entgegen den anderen Meldungen als UDP Messages an eine bestimmte Portnummer übertragen. Die Meldungen werden zur Erkennung der LSR gegenseitig übertragen. LDP unterscheidet zwei verschiedene Typen von Discovery Mechanismen.

Basic Discovery Mechanism, zur Erkennung von LSR, welche direkt über den Link Layer verbunden sind. Die Hello Message wird als Broadcast Meldung über das entsprechende Interface geschickt.

Extended Discovery Mechanism, zur Erkennung von LSR, welche nicht direkt über den Link Layer verbunden sind. Die Hello Message wird dabei an eine spezifische, durch konventionelle Routingalgorithmen (IS-IS, OSPF) verteilte Adresse verschickt.

Session Messages, Session Establishment

Nach der Discovery Hello Message erfolgt der Verbindungsaufbau (Session Establishment) zum Austausch der Labels. Der Prozess erfolgt in zwei Schritten.

Transport Connection Establishment
Session Initialization

Der Aufbau der Transport Verbindung erfolgt nach folgender Prozedur:

Falls nicht bereits eine TCP Session eröffnet wurde, erfolgt als erstes der Aufbau einer neuen TCP Verbindung für eine neue LDP Session. Der Source LSR (A) bestimmt dazu die Transport Adresse, welche optional in der Hello Message des gegenüber liegenden LSR (B) übertragen wurde oder als Source Address der von B empfangenen Hello Message diente. Bei der Bestimmung der Transport Adresse verhält sich B symmetrisch.

In der nächsten Phase bestimmt LSR A ob er die Rolle des aktiven oder des passiven LSR übernehmen will. Dazu wertet er die beiden Transportadressen aus und entscheidet anhand des höheren Wertes. Beinhaltet seine Transportadresse den höheren Wert gegenüber seinem Nachbarn, übernimmt er die aktive Rolle, ansonsten die passive Rolle.

Sind die Rollen ausgehandelt kann der aktive LSR eine TCP-LDP Session aufbauen.

Nach dem Verbindungsaufbau werden in der Session Initalization Phase durch LDP Initialization Messages verschiedenste Parameter ausgehandelt. Diese sind:

LDP Protokoll Version
Label Verteilungsmethode
Timer Werte
VPI und VCI Bereiche bei Übertragung über ATM Zellen
DLCI Bereiche für den Data Link Layer in Frame-Relay Technik
etc.

Advertisement Messages

Label Advertisement Messages ermöglichen den eigentlichen Austausch und Unterhalt der Label Informationen. Labels werden zwischen den LSR angefragt, ausgetauscht und auch wieder gelöscht. Folgende Meldungstypen sind definiert:

Label Request Message
Label Abort Request Message
Label Mapping Message
Label Withdraw Message
Label Release Message

Label Request Message

Die Label Request Message wird benötigt, um dem in Richtung Zieladresse folgenden LSR eine Anfrage über eine Zuordnung eines Labels zur spezifischen FEC zu machen. Die Meldung wird initiiert, wenn der LSR eine neue FEC entdeckt oder der unmittelbare folgende LSR einer FEC ändert.

Abbildung 16 Label Request Message

Die einzelnen Felder bedeuten:

Label Request

Identifiziert den LDP-Meldungstyp als Label Anfrage.

Message Length

Gibt die gesamte Länge der Meldung ab der Message ID an.

Message ID

32 Bit Identifikator, welcher die Meldung eindeutig identifiziert.

FEC TLV

Spezifiziert die FEC, für welche ein Label angefragt wird.

Opt. Parameter

Die optionalen Parameter enthalten einen Hop Counter und einen Path Vektor.

Label Abort Message

Die Meldung Label Abort Message informiert den Peer LSR über den Abbruch einer Label Request Message. Dies aus Gründen, weil beispielsweise die FEC im LSR ändert, dieser aber bereits eine Anfrage an seinen Peer LSR initiierte.

Label Mapping Message

Mit der Label Mapping Message antwortet ein LSR auf die Anfrage einer Label Request Message. Die Meldung enthält Informationen über die Zuweisung einer FEC zum Label. Die Meldung ist wie folgt aufgebaut:

Abbildung 17 Label Mapping Header

Die einzelnen Felder bedeuten:

Label Mapping

Identifiziert den LDP-Meldungstyp als Label Mapping.

Message Length

Gibt die gesamte Länge der Meldung ab der Message ID an.

Message ID

32 Bit Identifikator, welcher die Meldung eindeutig identifiziert.

FEC TLV

Spezifiziert die FEC, an welche das Label gebunden wird.

Label TLV

Spezifiziert den Wert des Labels.

Opt. Parameter

Die optionalen Parameter beinhalten die Label Request Message ID, damit die Mapping Message eindeutig als Antwort auf die Request Message identifiziert werden kann. Weiter sind optional enthalten, einen Hop Counter und einen Path Vector.

Label Withdraw Message

Mit der Meldung Label Withdraw Message werden die Zuordnungen von FEC zu Labels annulliert. Dies geschieht, falls der LSR eine bekannte FEC verliert oder durch manuelle Konfiguration eine FEC nicht mehr behandelt. Die Informationsfelder der Label Withdraw Message entsprechen der Label Mapping Message.

Label Release Message

Ein LSR überträgt eine Label Release Message zu seinem Peer LSR, wenn er eine Label Zuordnung nicht mehr länger benötigt. Der Meldungsaufbau erfolgt dabei identisch der Label Mapping Message. Folgende Zustände initiieren eine Label Release Message:

Ein LSR ist nicht mehr der unmittelbar folgende LSR einer FEC und der LSR ist in „Conservative Operation Mode" konfiguriert.
Ein LSR erhält eine Label Zuweisung, für welche er jedoch nicht der unmittelbar folgende LSR der FEC ist.
Der LSR empfängt ein Label Withdraw Message.

Notification Messages

Notification Messages werden initiiert, um eine Peer-LSR über bestimmte Ereignisse zu informieren. Dies sind bespielsweise Fehlerereignisse, Hinweise (advisory information) oder Statusmeldungen. Notification Messages werden in folgendem Format übertragen:

Abbildung 18 Notification Message Typ

Die einzelnen Felder bedeuten:

Notification

Identifiziert den LDP-Meldungstyp als Notification Message.

Message Length

Gibt die gesamte Länge der Meldung ab der Message ID an.

Message ID

32 Bit Identifikator welcher die Meldung eindeutig identifiziert.

Status TLV

Spezifiziert das Ereignis, welches dem Peer-LSR übertragen wird.

Opt. Parameter

Die optionalen Parameter beinhalten einen Extended Status, eine Returned PDU oder die Returned Message.

 

MPLS ermöglicht die Zuweisung von Labels mittels Border Gateway Protocol (BGP-4) [M8]. Die Zuweisung erfolgt im Huckepack Verfahren in der BGP Update Message zusammen mit der Verteilung von Routinginformation. Die BGP Update Messages erfolgen zwischen zwei Peers aufgrund einer Topologieänderung oder durch gegenseitiges periodisches Update.

Abbildung 19 BGP Update Message mit Label Distribution

Marker:

Der 16 Oktett grosse Marker gehört zum festen Meldungskopf von BGP-4. Er dient zur Synchronisation zwischen zwei BGP-Peers (BGP Speakers) und zur Echtheitsüberprüfung von BGP Nachrichten.

BGP Length:

Das 2 Oktett grosse Längenfeld der BGP Nachricht enthält die Grösse der gesamten BGP Meldung. Die Länge einer Nachricht muss dabei mindestens 19 Oktett und kleiner 4096 Oktett betragen.

Type:

Das 1 Oktett grosse Feld identifiziert die eigentliche BGP Meldungen, wie Open, Update, Notification und Keepalive. Zur Verteilung von Labels wird die Update Message mit dem Wert 2 benutzt.

BGP Update Message:

Der Meldungstyp BGP Update Message enthält die Routingeinträge zwischen den BGP Peers. Die darin enthaltenen Attribute dienen zum Aufbau einer Datenbasis mit Beziehungen zwischen den verschiedenen Autonomous Systems oder zwischen den BGP Speakers innerhalb eines Autonomous System. In der BGP Update Message sind Multiprotocol Erweiterungen wie die Network Layer Reachability Information enthalten, welche seinerseits wiederum die Zuweisung der Labels enthält.

Length:

Das Längenfeld enthält die Länge der Adressenpräfixe und der zugewiesenen Labels. Das Oktett grosse Feld identifiziert die Länge in Bits.

Label:

Das Labelfeld enthält eines oder mehrere Labels. Jedes darin enthaltene Label mit der Grösse von 20 Bit wird in drei ganzen Oktetts (24 Bit) übertragen. Ein Bit wird zur Benutzung des Labelstacks verwendet und die verbleibenden Bits werden ungenutzt belassen.

Labelstack:

Der Labelstack wird mit einem Bit Länge (S-Bit) zur Unterstützung des hierarchischen Systems von Labeln identifiziert. Die Funktion entspricht derjenigen, der Labelstack Funktion des Shim-Headers.

Prefix:

Das Präfixfeld enthält die FEC, bzw. das IP-Adressenpräfix. Die maximale Länge des Feldes beträgt 4 Oktett, bzw. die gesamte Länge einer IPv4-Adresse. Beträgt die Länge des Feldes weniger als vier Oktett, wird das Präfix mit Füllbits zu einem ganzen Oktett ergänzt.

Constraint-based Routing LDP [M11] berücksichtigt im Gegensatz zum einfachen LDP Link-Charakteristiken wie Bitrate, Laufzeiten etc. Das vorher beschriebene LDP wird dabei um die Verkehrslenkung und um QoS Eigenschaften erweitert.

Als erstes wird mittels erweitertem Routing Algorithmus, dem Constrained Shortest Path First, CSPF ein Pfad durchs Netz berechnet. CSPF berücksichtigt zusätzlich zum konventionellen Shortest Path First Algorithmus - wie er in OSPF oder IS-IS verwendet wird - weitere Link Charakteristiken. Die daraus erzeugte Tabelle mit Loopback- oder Interface-IP-Adressen der im Pfad liegenden Router wird als Explicite Route Object, ERO bezeichnet.

Als zweiter Schritt wird die Label Request Message mit zwei neuen Type-Length-Value Feldern, dem Explicite_route_TLV und dem Traffic_parameter_TLV erweitert und vom LER an den ersten LSR geschickt. Der LER reserviert sich dabei die angeforderten Ressourcen, wie Peak Data Rate (PDR), Committed Data Rate (CDR), Committed Burst Size (CBS), etc. für den entsprechenden LSP. Der LSR analysiert die eintreffende Label Request Message anhand des ERO, um die Meldung weiter durchs Netz zu leiten und reserviert ebenfalls die im Traffic_parameter_TLV spezifizierten Ressourcen. Die Prozedur wiederholt sich solange, bis die ERO-Liste der Router abgearbeitet wurde und die Label Request Message den letzten LSR, den Egress Label Edge Router erreicht hat.

Als letzter Schritt ordnet der Egress LER ein Label der angefragten FEC zu und antwortet dem „fragenden" LSR mit einer Label Mapping Message, in welcher er das Label zur FEC und eine für den Pfad eindeutige Identifikationsnummer mitschickt. Die Label Mapping Messages werden nun entlang der LSR, dem umgekehrten Weg der Label Request Message, bis zum Ingress LER geschickt.

Folgende Abbildung zeigt den Meldungsverlauf der Label Request Message und der Label Mapping Message mit den darin enthaltenen TLV.

Abbildung 20 CR-LDP Message Flow

Zusammengefasst sind die Charakteristiken von CR-LDP:

Transport der Meldungen über TCP
Austausch von Traffic Parameter über Traffic Parameter TLV in der Label Request Msg.
LDP reserviert Ressourcen in Richtung Ziel
Reservierungszustand des LSP in hard state
Strict Explicit Routing und Loose Explict Routing
Möglichkeiten von Pfadumleitung und Wiederherstellung (LSP Protection und Preemption)
Security integriert über MD5

Die Funktionsweise von RSVP wird unter dem Kapitel „Funktionsübersicht IP" bzw. im Anhang 13.4 erklärt. RSVP wird in der RSVP-TE Technik [M12, M15] mit der Möglichkeit der Verkehrslenkung und der Labelzuordnung ergänzt. Die Verkehrslenkung geschieht dabei analog dem CR-LDP mit dem Constraint Shortest Path First, CSPF und die Labelzuordnung mittels neuer Objekte in den RSVP Meldungen.

RSVP-TE definiert zur Zuordnung von Labels im Meldungsformat zwei neue Objekte, die als Anfrage und Zuweisung von Labels dienen.

LABEL_request_object in der RSVP PATH Message
LABEL_object in der RSVP RESV Message

Das Objekt LABEL_request_object definiert dazu drei verschiedene Formate, ein Format für den ATM VPI/VCI Bereich, eines für den Frame-Relay DLCI Bereich und eines ohne speziellen Labelbereich.

Die Reservierung der Ressourcen erfolgt einer normalen Resource Reservation Session mit Ausnahme, dass zusätzlich die Objekte in den Meldungen übertragen werden. Folgend Abbildung zeigt die Prozedur.

Abbildung 21 RSVP-TE Message Flow

Wie beim CR-LDP wird als erstes mittels erweitertem Routing Algorithmus, dem Constraint Shortest Path First, CSPF ein Pfad durchs Netz berechnet. CSPF kann in dieser Prozedur auch weitere Link Charakteristiken, wie Bitrate oder Delay berücksichtigen. Das Ergebnis ist die Tabelle mit Loopback- oder Interface-IP-Adressen der im Pfad liegenden Router (Explicite Route Object, ERO). Das Vorgehen, ausser der Berücksichtigung neuer Link Charakteristiken, wird im Resource Reservation Protocol bereits definiert und entspricht einer normalen RSVP Prozedur.

Im zweiten Schritt wird eine RSVP PATH Message erzeugt und an den ersten LER geschickt. Dieser ergänzt die Meldung mit einem neuen Objekt, dem LABEL_request_object und schickt sie an die nächste im Explicite_route_object definierte IP Adresse. Dieser Vorgang wiederholt sich bis zum Zielhost.

Der Zielhost leitet den dritten Schritt, die Reservierung der Ressourcen ein. Mit einer RSVP RESV Message wird die Reservierung der Ressourcen initiiert. Der am Zielhost nächstliegende LER analysiert die Meldung, reserviert die Ressourcen wie Bitrate, Buffer, etc, schaltet den LSP und ergänzt die Meldung mit einem LABEL-object, das die angefragte FEC und das zugewiesene Label enthält. Falls die Meldung den Quellhost erreicht, wurde der LSP zwischen den LER aufgebaut. Ansonsten werden RESV ERR Messages in Richtung Empfänger initiiert.

Weitere Charakteristiken von RSVP-TE sind:

Transport der Meldungen direkt über IP
Austausch von Traffic Parametern über Objekt in Path Message
RSVP reserviert Ressourcen in Richtung Quelle
Reservierungszustand des LSP in soft state. Ein Refreshing des Pfades wird dadurch notwendig
Strict Explicit Routing und Loose Explict Routing
Möglichkeiten von Pfadumleitung und Wiederherstellung
Security integriert über MD5

Derzeit sind für MPLS Netze verschiedene Prinzipien Gegenstand einer Untersuchung zur Realisierung von privaten Netzen (Virtual Private Networks VPN). Am weitesten fortgeschritten und von den Herstellern favorisiert, dürfte der Ansatz nach BGP/MPLS VPN [M16, M17] sein. Auch unter dem Namen Peer Model oder verbindungsloses VPN bekannt, verspricht das Prinzip eine skalierbare und einfache Lösung für den Netzbetreiber. Im Gegensatz zum Overlay Model, das IP über Layer 2 Techniken wie Frame-Relay oder ATM definiert, werden durch das Peer Model die VPNs auf Layer 3 definiert. Das Peer Model weist folgende Eigenschaften auf:

Jedes VPN isoliert Routing und Forwarding der Daten zu anderen Netzen (VPNs)
Skalierbarkeit, bis 2³² virtuelle Netze möglich
Geeignet für private Netzadressierung
Für den Benutzer sind keine Kenntnisse über die VPN Technik notwendig
Flexibel und leichte Erweiterungsmöglichkeiten
Verbindungsloses VPN da keine fest geschalteten Pfade im Netz

Die Realisierung von BGP/MPLS VPNs basiert auf vier verschiedenen Funktionen bzw. Techniken.

Verteilung der Routinginformation nach vorgegebener Route
Unterhaltung von je einer Forwarding Table pro VPN
Eindeutige Identifikation der Teilnehmer durch eine neue VPN-IP Adresse
Schaltung der LSPs durch MPLS

Als Illustration der Funktionsweise soll nachfolgende Netzkonfiguration dienen. VPN A beinhaltet dabei vier verschiedene Lokalitäten mit je einem Customer Edge Router (CER). VPN B enthält nur drei Standorte. Zwei der vier Router in VPN B sind dabei redundant an das MPLS Netz angeschlossen. Zur einfacheren Unterscheidung in den nachfolgenden Kapitel wird jeder Router eindeutig identifiziert. Dies hat aber keinerlei Einfluss auf die Funktionsweise des VPNs und muss vom Netzbetreiber auch nicht so gehandhabt werden. Die Kommunikation erfolgt vom Customer Edge Router CER 2 zum CER 7.

Abbildung 22 Beispiel zweier VPNs

 

Zur Verteilung der Routinginformationen sind zwei Begriffe von zentraler Bedeutung. Dies ist einerseits das BGP Community Attribute [M17, M18] und die VPN-IP Address [M17]. Die Routinginformationen werden in der Forwarding Table gespeichert. Beide Begriffe und die Forwarding Table seien nachfolgend erklärt:

BGP Community Attribute

Ein Netzbetreiber hat die Möglichkeit in seinem MPLS Netz bis zu 4.29 Milliarden (2³²) verschiedene VPNs zu adressieren. Die Identifikation erfolgt durch eine 32 Bit lange VPN Nummer. Diese wird vom Netzbetreiber jedem VPN einzeln zugeteilt und in jedem LER, welcher zu diesem VPN gehört, manuell konfiguriert. Bei der Verteilung von Routinginformationen innerhalb des VPN wird die Identifikationsnummer in der BGP Message ins Community Attribute übertragen und mit der BGP Message verschickt.

Ein LER, welcher die BGP Message empfängt, kann nun anhand des Community Attributes erkennen, ob die Routinginformation für eines seiner VPNs zutrifft. Ist dies der Fall, trägt er die Routinginformationen in die für das VPN vorgesehene Forwarding Table (Forwarding Information Base FIB) ein.

VPN-IP Address

Innerhalb einer BGP Domain wird angenommen, dass jede IP Adresse einzigartig ist. MPLS unterstützt jedoch in jedem VPN private und demnach nicht einmalige IP-Adressen. Um die Einzigartigkeit einer Adresse zu erreichen wird deshalb der IPv4 Adresse ein Route Destinguisher von 64 Bit vorgestellt. Nachfolgende Skizze zeigt das erweiterte Adressenformat.

Abbildung 23 VPN-IP Address

Die Autonomous System Number identifiziert den Netzbetreiber, während die Assigned Number vom Netzbetreiber selber eingeteilt werden kann. Eine IPv4 Adresse wird mit dem Route Destinguisher in einem MPLS Netz einzigartig.

Die VPN-IP Adresse wird nur in den Routinginformationen verwendet. D.h. die VPN-IP Adressen werden nur in den BGP Meldungen zwischen den LER ausgetauscht. Setzt ein CER eine Routingmeldung ab, werden die darin enthaltenen IPv4 Adressen im LER in VPN-IP Adressen umgesetzt und mittels BGP Meldung ins MPLS Netz geschickt.

Forwarding Table

Zur vollständigen Trennung der Datenströme wird in jedem der LER für jedes von ihm unterhaltenen VPN eine eigene Forwarding Table [M17] unterhalten. Je nach angeschlossenen Lokalitäten bzw. CER und den Zugehörigkeiten zu den VPN kann dies für den LER von einer einzige Forwarding Table bis für jedes Port eine eigene Forwarding Tabelle bedeuten. Beim Eintreffen von IP Paketen am LER Eingangsport muss demnach der LER entscheiden, welche der eingerichteten Forwarding Table für das VPN zuständig ist.

Die Routinginformationen zu den Forwarding Tables erfolgen über zwei verschiedene Quellen. Dies sind einerseits die Informationen der CER und andererseits die Informationen der im Netz weiter enthaltenen LER.

Die eigentliche Verteilung der Routinginformation teilt sich in fünf verschiedene Schritte auf.

1. Bei Änderungen von Routingtabellen im CER propagiert dieser über sein im Netz definiertes, beliebiges Routingprotokoll wie IS-IS, OSPF, RIP oder BGP die Routinginformationen zum MPLS Netz (LER). In der Beispielkonfiguration erfolgt dies von CER 2 zum LER 1.

2. Der Ingress Label Edge Router LER 1 wandelt die eintreffenden Informationen in BGP Messages um. Dazu werden die IPv4 Adressen in VPN-IP Adressen umgewandelt und das BGP Community Attribute mit der VPN Identifikation ergänzt.

3. Die BGP Information wird anhand der normalen Prozedur durchs MPLS Netz zum Egress LER 4 übertragen. Dies erfolgt über die bereits bestehenden LSPs, welcher jeder LSR für den Austausch von BGP Messages zum unmittelbaren Nachbarn unterhält.

4. LER 4 wertet die eintreffende BGP Meldung aus und erkennt anhand des Community Attribute, dass es sich um eines in ihm konfigurierten VPN handelt. Die Routingeinträge werden in die Forwarding Table geschrieben und die BGP Meldung wird umgekehrt in eine konventionelle Routingmessage umgewandelt. Die VPN-IP Adressen werden ebenfalls zurück in konventionelle IPv4 Adressen umgewandelt und der konventionellen Routingmessage zugefügt.

5. Als letzter Schritt wird die konventionellen Routingmessage von LER 4 an den CER 7 übertragen.

Folgende Abbildung zeigt den Meldefluss, wobei die IGP Meldungen konventionellen Routinginformationen und die BGP Meldungen den erweiterten BGP Messages mit VPN-IP Adressen und Community Attributes entsprechen. Die jeweiligen Tabellen enthalten die VPN-IP Adressen, den Ziel-LER, das innere und das äussere Label.

Abbildung 24 Verteilung der Routinginformation

Wie erwähnt werden die VPN-IP Adressen nur beim Austausch der BGP Routinginformation verwendet. Der eigentliche IP-Datenstrom zwischen den Lokalitäten beinhaltet keinerlei Erweiterung in den IP-Adressen, so dass die Pakete auf dem Weg durch das MPLS Netz nicht unterschieden und dem VPN eindeutig zugeordnet werden können. Die Trennung der Daten zwischen den verschiedenen VPNs erfolgt denn auch mittels Label Switched Path. In der Forwarding Table bzw. in der Forwarding Information Base (FIB) sind jeder VPN-IP Adresse zwei Labels zugeordnet. Die zwei Labels ermöglichen eine hierarchische Struktur der LSPs. Dies ermöglicht die Routing Informationen im Core LSR wesentlich zu reduzieren und den Router anstelle mit der Verwaltung grosser Forwarding Tabellen zu belasten, zum Schalten von LSP frei zu halten.

Sendet nun der CER 2 seine Daten an den LER 1, bestimmt dieser anhand des Eingangports die zugehörige VPN und entsprechend die FIB. Anhand der FIB erkennt LER 1 die im Netz eindeutige Ziel VPN-IP Adresse (FEC) und deren assoziierten Labels. Die Labels fügt er dem IP Paket zu und schickt es über den entsprechenden LSP zum LSR 1. LSR 1 leitet das Paket weiter an LSR 2 und dieser wiederum an LSR 3. LSR 3 als letzter Core Router entfernt das äussere Label und schickt es entsprechend dem inneren Label an den LER 4. LER 4 als letzter Label Switched Router entfernt nun das innere Label und leitet das Paket als IP Paket an den Customer Edge Router CER 7. Folgende Abbildung zeigt den Verlauf der Pakete.

Abbildung 25 VPN Traffic Flow

Die MPLS Architektur spezifiziert verschiedene Ansätze von QoS. Zwei davon beziehen sich hauptsächlich auf die Art der Verbindung im MPLS Netz, während ein dritter Ansatz die Zuordnung von MPLS-Verkehrsparameter in Verbindung mit ATM-Verkehrsparameter beschreibt. Möglichkeiten zur Unterstützung von Diff-serv und zur Verhinderung von Verkehrsstauungen sind in der MPLS Architektur ebenfalls gegeben.

Pipe Model

Das Pipe Model [M12] beschreibt Möglichkeiten von QoS Aspekten, ähnlich eines festen Pfades durch das MPLS Netz. Das Pipe Model kann sowohl für CR-LDP, wie auch für RSVP-TE verwendet werden. Im Gegensatz zu Frame Relay PVCs oder ATM PVCs definiert das Pipe Model den Pfad im Netz als unidirektionalen Pfad. Jedem Pfad können entsprechende Verkehrsparameter wie Peak Data Rate (PDR), Peak Burst Size (PBS) etc. zugeordnet werden. An die jeweiligen LSR übertragen werden die Verkehrsparameter im Traffic Parameter TLV der Path Request Message von CR-LDP oder im SENDER_TSPEC Object der Path Message in RSVP-TE.

Abbildung 26 Pipe Model

Das Pipe Model spezifiziert für CR-LDP folgende Traffic Parameter:

Committed Data Rate (CDR), spezifiziert die garantierte Datenrate
Committed Burst Size (CBS), spezifiziert den garantierten Burst
Peak Data Rate (PDR), spezifiziert die kurzzeitig höchstmögliche Datenrate
Peak Burst Size (PBS), spezifiziert den kurzzeitigen höchstmöglichen Burst
Frequency, spezifiziert und begrenzt die maximale Verzögerung der CDR

Das Pipe Model spezifziert für RSVP-TE folgende Traffic Parameter:

Token Bucket Rate, spezifiziert die garantierte Datenrate
Token Bucket Size, spezifiziert den garantierten Burst
Peak Data Rate, spezifiziert die kurzzeitig höchstmögliche Datenrate
Minimum Policed Unit, spezifiziert die kleinste zu übertragende Paketgrösse
Maximum Packet Size, spezifiziert die grösste zu übertragende Paketgrösse
Minimum path latency, spezifiziert die kleinst mögliche Durchlaufzeit von Paketen

Hose Model

Im Hose Model [M14] wird lediglich der Eintrittspunkt bzw. der Austrittspunkt des Datenverkehrs ins MPLS Netz spezifiziert. Die einzelnen Datenströme zwischen zwei CER sind im Netz nicht mehr explizit erkennbar. Die Priorisierung der Datenströme erfolgt vielmehr nach dem Prinzip von Diffserv, indem IP-Pakete anhand des Type-of-Service Feldes unterschieden werden. Definiert werden im Hose Model lediglich zwei Verkehrsparameter, die Ingress Committed Rate und die Egress Committed Rate. Diese beiden Bitratenbeschränkungen können einerseits durch die Accessrate oder mittels eines Layer 2 Pfades festgelegt werden. Eine Charakterisierung und Priorisierung von Pfaden durch das Netz ist aber im Hose Model nicht möglich.

Abbildung 27 Hose Model

Mapping MPLS Traffic Parameter in ATM Traffic Parameter

Die Zuordnung von MPLS Traffic Parameter in ATM Traffic Parameter erfolgt nach folgender Tabelle. Die MPLS Traffic Parameter (PDR, PBS, etc.) werden dabei den einzelnen ATM Traffic Parameter (PCR, CDVT, etc.) zugeordnet, welche wiederum die ATM Service Kategorien (CBR, VBR-RT, etc) bilden. Beim Wechsel von einem MPLS Netz in ein ATM Netz werden die MPLS Traffic Parameter den ATM Traffic Parameter zugeordnet. Beim Übertritt der Pfade vom ATM Netz ins MPLS Netz verhält sich das Mapping umgekehrt.

Tabelle 1 Mapping MPLS Traffic Parameter in ATM Traffic Parameter

Diffserv in MPLS

Diffserv ermöglicht mittels im IP-Header enthaltenen Type-of-Service Felder eine Unterscheidung des Datenverkehrs von bis zu 64 verschiedenen Serviceklassen. Bit 0-2 enthalten dabei die Priorität (Precedence), während die Bit 3-5 Prioritäten speziell für Delay, Throughput und Reliability definieren. Die Markierung bzw. Festlegung des Type-of-Service Feldes in den IP-Paketen wird auch als Differentiated Service Code Point (DSCP) gekennzeichnet. Der DSCP informiert somit den Router darüber, wie er das entsprechende Paket behandeln sollte. Aus Sicht Router impliziert Diffserv ein Per-Hop-Behavior (PHB), d.h. jeder Router im Netz bestimmt unabhängig zu anderen Routern das Forwarding der IP-Pakete. Die QoS Behandlung besitzt somit keine End-zu-End Signifikanz, sondern setzt sich aus den einzelnen Verhalten der im Pfad liegenden Routern zusammen.

Auch MPLS [M14] definiert im Shim-Header ein Experimential Field, welches zur Unterstützung von verschiedenen Serviceklassen vorgesehen ist. Das Feld beinhaltet jedoch nur eine Grösse von drei Bits, was bis zu acht verschiedene Klassen oder PHB ermöglicht. Eine genaue Zuordnung der Type-of-Service Werte zum Experimential Field ist derzeit nicht vorhanden. Die MPLS Drafts erwähnen jedoch zwei Möglichkeiten zur Behandlung von PHB.

E-LSP

Bei der ersten Methode, der E-LSP, geht man davon aus, dass im Type-of-Service Feld nur bis zu acht verschiedene Serviceklassen definiert sind. Diese Serviceklassen können direkt dem Exp Feld des MPLS Shim-Headers oder umgekehrt vom Exp Feld dem Type-of-Service Feld zugeordnet werden. Zur Übertragung der Daten wird nur ein LSP benötigt. Die Methode eignet sich in einem MPLS Netz, welches über wenig Serviceklassen verfügt und über Techniken wie Ethernet und PPP führt. Für E-LSP wird keine Erweiterung der Signalisierung der LSP benötigt. Der Aufbau der Pfade erfolgt mittels BGP oder LDP. E-LSP funktioniert aber nicht in Zusammenhang mit Techniken wie Frame-Relay und ATM (siehe folgender Abschnitt).

Abbildung 28 E-LSP

L-LSP

Da Frame-Relay und ATM über keinen Shim-Header (Exp Feld) verfügen, musste zur Unterstützung der PHB eine weitere Methode gefunden werden. Auch bei einer Anzahl von Serviceklassen (PHB) grösser als acht, stellt sich das Problem, dass das Exp Feld nicht mehr ausreichend ist, um alle PHB im Netz zu unterscheiden. L-LSP bedient sich deshalb der Zuordnung von PHB zu verschiedenen LSPs. Der Aufbau der LSP erfolgt mittels einer erweiterten Signalisierung, welche nebst dem Adressenpräfix in der Forward Equivalence Class auch die verschiedenen PHB berücksichtigt.

Abbildung 29 L-LSP

Signalisierung von Verkehrsstauungen

Auch zur Signalisierung von Verkehrsstauungen in einem MPLS-Netz werden in den Drafts verschiedene Szenarien skizziert. Während die erste Möglichkeit, ähnlich der Frame-Relay Technik ein Flag (Forward Explicit Congestion Notification) im Experimential Field zur Anzeige von Verkehrsstauungen benutzt, geht der zweite Ansatz von einer expliziten Signalisierung mittels RSVP Tunnel Congestion Message aus. Bei beiden Methoden ist zu vermerken, dass die Flusskontrolle von den höheren Schichten (IP) übernommen werden muss. Die Signalisierung dient lediglich dazu, den Sender bzw. die Quelle über den Verkehrsstau im Netz zu informieren.

Explicit Congestion Notification

Die Methode Explicit Congestion Notification [M19] benutzt im MPLS Shim-Header eines der drei Experimential Bits zur Anzeige von Verkehrsstauungen. Dabei werden die im Type-of-Service des IP-Headers verbleibenden restlichen zwei Bits [I1], Fähigkeit zur Verkehrsstauerkennung (Explicit Congestion Notification capable Transport, ECT) und Verkehrsstauanzeige (Congestion Experienced, CE), wie folgt zugeordnet:

Tabelle 2 ECN Zuweisung

Die Benachrichtigung der Verkehrsstauung erfolgt in Richtung Empfänger. Der Vorteil zeigt sich bei dieser Methode in der einfachen Implementierung, während der Nachteil in der begrenzten Anzahl von PHB liegt.

RSVP Tunnel Congestion Message

Mittels einer explizit generierten RSVP Tunnel Congestion Message [M19] wird dem Sender mitgeteilt, dass sich im Netz Verkehrsstau ereignet. Die Meldung wird dabei von den zwischen Stau und Sender liegenden LSR ignoriert, da diese keinerlei Flusskontrolle übernehmen.

Bei der Head End Reroute Capability stellen die Ingress LER durch die Benachrichtigung von Routingprotokollen (IGP) oder von Path Messages beim RSVP-TE eine Topologieveränderung fest. Der Ingress LER aktualisiert seine Routingtabelle und berechnet aufgrund dieser Information einen neuen Weg durch das Netz (SPF). Anschliessend wird der neue Pfad durch das Netz signalisiert und aufgebaut LSP {LER 5; LSR 1; LSR 10; LSR 4; LSR 9}. Im Falle von RSVP-TE erfolgt die Reservierung des Pfades mittels des Shared Explicit Reservation Style. Dies hat den Vorteil, dass der neue LSP Teile des unterbrochenen LSP benutzen kann und auf diesen Strecken keine zusätzliche Leitungskapazität benötigt wird. Nachdem der neue LSP aufgebaut wurde, modifiziert der Ingress LER seine Forwarding Table und leitet den Verkehr über den neuen Pfad. Als letzter Schritt wird der Originalpfad LSP {LER 5; LSR 1; LSR 4; LSR 9) aus der Forwarding Table gelöscht und die Ressourcen dem Netz zurück gegeben. Folgende Abbildung zeigt das Prinzip des Head End Reroute Capability.

Abbildung 30 Head End Rerouting Capability

In einem MPLS Netz kennt jeder Router die Topologie des Netzes, indem er durch das Routingprotokoll (BGP) Meldungspfade zu jedem im Netz verfügbaren Router unterhält. Neben den optimalsten Pfaden für die Forward Equivalence Class (FEC) kann sich ein LSR ebenso alternative Pfade im Falle für Netzunterbrüchen merken. Das Prinzip des Fast Reroute with Constraint-Based Routing beruht auf dieser Überlegung. Dazu benutzt Fast Reroute with Constraint-Based Routing die Eigenschaften des Labelstacks. Folgende Abbildung zeigt ein Beispiel, wie eine Umschaltung im Falle eines Linkfehlers funktioniert.

Abbildung 31 Fast Reroute

Der LSP von LER 5 zu LER 9 wird nach dem LSR 1 unterbrochen. LSR 1 erkennt diesen Fehler durch das Transportprotokoll wie beispielsweise Loss of Signal beim SDH. LSR 1 durchsucht darauf seine Tabellen nach einem alternativen Pfad und baut via RSVP Path Message oder Label Request Message einen neuen LSP zu LSR 4 via LSR 2 und LSR 3 auf. Nach dem Aufbau des neuen LSP addiert LSR 1 ein neues Label (87) zum Labelstack und leitet den Verkehr anhand dessen zu LSR 2. LSR 2 vollzieht ein normales Labelswapping (87 → 49) und leitet den Verkehr zu LSR 3 weiter. LSR 3, als letzter in der Umleitung entfernt als erstes das oberste Label (49) im Labelstack. In einem zweiten Schritt leitet er nun anhand des aktuellen Output Labels (14) den Verkehr nach LSR 4. LSR 4 erkennt das Label 14 und leitet es anhand seiner Forwarding Table mit dem Label 57 zu LER 9.

Der Vorteil dieser Methode liegt darin, dass nach einem Unterbruch keine Pfadberechnungen erfolgen. Ein neuer LSP kann direkt von einem einzigen LSR neu initiiert und kontrolliert werden. Ein Umleiten des Verkehrs kann deshalb sehr schnell erfolgen. Ein weiterer Vorteil besteht darin, dass sich die Methode nicht nur auf Link, sondern auch auf Router oder Kombinationen von Router mit Links anwenden lässt.

Auch MPLS stellt seit jüngstem einen ersten Draft zur Unterstützung von Operation, Administration and Maintenance (OAM) [M24] Funktionen bereit. Das Prinzip beruht ähnlich der ATM Technik auf eigenständigen OAM-Meldungen, welche mit einem bestimmten Labelwert (Labelwert = 4) gekennzeichnet werden. Unterstützt werden im ersten Draft Verbindungsverifikation, Erkennung von Pfadfehlern oder Performance Messungen. Die OAM Funktionalitäten sind Layer unabhängig und funktionieren deshalb mit MPLS unterliegenden Data Link- oder Transport Layer entsprechend Hersteller abhängig. Folgende OAM Function Types wurden bisher definiert:

Connectivity Verification (CV)

Wird benötigt, um alle Typen von LSP Verbindungsfehlern zu erkennen bzw. zu diagnostizieren.

Performance (P)

Die Performance Meldung kann benutzt werden um Paketverluste zu messen.

Forward Defect Indicator (FDI)

Die Meldung wird benutzt, um bei der Erkennung von Fehlern, die Fehlerursache an betroffene "Client"- Layers zu signalisieren.

Backward Defect Indicator (BDI)

Die Meldung wird in entgegen gesetzter Richtung des FDI initiiert, um Fehlerursache an betroffene "Client"- Layers zu signalisieren.

Die auf Router basierte Architektur ist momentan die in der Literatur am meisten verbreitete Variante. Oft wird dabei auch von BGP/MPLS VPN gesprochen, da hauptsächlich das Border Gateway Protokoll zur Verteilung der Labels benutzt wird. Die Architektur kann einfach in einen Core (LSR), Access (LER) und CPE (CER) Bereich eingeteilt werden, was in grösseren Netzen auch zur Anwendung kommt. Wie im weiter vorne beschrieben, stellt jede der Ausrüstungen unterschiedliche Funktionen bereit, welche in der fester Reihenfolge CER, LER, LSR zueinander stehen.

Weil MPLS als Technik zwischen Layer 2 und 3 funktioniert, ist MPLS auf einen Data Link Layer angewiesen. Das bedeutet wiederum, dass die Funktionen der Übertragung vollständig im Router oder teilweise im Router und zusätzlichen Übertragungsausrüstungen bereit gestellt werden müssen. Durch den geringen Protokolloverhead eignet sich zwischen zwei LSR oder zwischen LER und LSR das Packet over Sonet (POS) bzw. das Dynamic Packet Transport (DPT), welche Bitraten von 155 Mbit/s bis 2.5 Gbit/s ermöglichen.

Packet over Sonet und DPT eignen sich jedoch durch die kleinste physikalische Übertragungsrate von 155 Mbit/s nicht für den Anschlussbereich. Zur Anbindung von Kunden an den LER dienen deshalb weitere Techniken wie xDSL in Verbindung mit ATM oder mit PPP. Folgende Skizze zeigt die Architektur mit zugehörigem Protokollstack für das Forwarding von IP Paketen.

Abbildung 32 Protokollstack der Router basierten Architektur

Die ATM - MPLS Architektur geht davon aus, dass der Netzbetreiber bereits über eine ATM bzw. Frame-Relay Infrastruktur verfügt oder sich diese im Aufbau befindet. Dazu werden lediglich MPLS Schnittstellen an der ATM Netzgrenze zur Verfügung gestellt. Grundsätzlich handelt es sich bei dieser Architektur auch vielmehr um ein ATM Netz mit Unterstützung von MPLS fähigen Local Area Networks. Folgende Skizze zeigt die Architektur mit zugehörigem Protokollstack.

Abbildung 33 ATM - MPLS Architektur mit CER/LER Funktion am Kundenstandort

 

Abbildung 34 ATM - MPLS Architektur mit CER/LER Funktion über den Anschlussbereich verteilt

Die Schnittstellen an der Grenze zum ATM Netz sind dabei als Label Controlled ATM Schnittstellen (LC-ATM) ausgelegt. DSLAM- oder SDH- Ausrüstungen sind notwendig, falls die Switches die Funktionen bzw. Techniken nicht bereits selber integriert haben oder die zu überbrückenden Distanzen nicht abgedeckt werden können. Im Corebereich findet denn ausschliesslich die SDH Technik als Übertragungstechnik Anwendung, während dies im Accessbereich die xDSL Techniken sind.

MPLambdaS oder IP over optical Networks [M25] definiert Erweiterungen zur Übertragung von IP/MPLS direkt über optische Wave Length Division Multiplex (WDM) Systeme. Das Netzwerkmodell besteht lediglich aus Routern, angeschlossen an ein optisches Core-Netzwerk. Der heutige Protokollstack von WDM, SDH, ATM und IP wird dabei auf IP/MPLS und WDM reduziert.

Abbildung 35 MPLambdaS Protokollstack

Das Core-Netzwerk besteht dabei aus optischen Crossconnects (OXCs) zur Bereitstellung von optischen Pfaden, während die Router die MPLS und IP Protokolle verarbeiten.

Abbildung 36 MPLambdaS Network

Der optische Crossconnect (Optical Crossconnect OXC oder Optical Layer Crossconnect OLXC) besteht aus drei verschiedenen Layern. Dem Optical Channel Layer Network, dem Optical Multiplex Section Layer Network und dem Optical Transmission Section Layer Network.

Optical Channel Layer Network (OCh)

Eine optischer Channel unterstützt den End-zu-End Pfad (Optical Channel Trails) durch das optische Netzwerk. Er besitzt Charakteristiken, wie Bandbreite, Wellenlänge, etc. Im OXC unterstützt, sind gewisse Funktionen für Routing, Monitoring und Pflege des Pfades. Schutzmechanismen wie Umschaltung und Wiederherstellung von Pfaden sind ebenfalls Inhalt der Internet Drafts.

Optical Multiplex Section Layer Network (OMS)

Das Optical Multiplex Section Layer Network beinhaltet die Aufgabe des Transportes der Optical Channels. Eine bestimmte Anzahl optischer Pfade werden als Stream oder Bündel zusammengefasst.

Optical Transmission Section Layer Network (OTS)

Das Optical Transmission Section Layer Network beinhaltet die verschiedenen Funktionen, welche zur Übertragung der optischen Signale auf den verschiedenen Übertragungsmedien notwendig sind.

MPLambdaS definiert aber nicht nur die Anforderungen des optischen Crossconnects, sondern zeigt auch die notwendigen Erweiterungen zu MPLS. Dies ist beispielsweise die MPLS Control Plane zur Kommunikation (Primitives) zwischen MPLS und dem Optical Layer Crossconnect. Auch verschiedene Aspekte des Traffic Engineering mit CR-LDP und RSVP werden skizziert. Resource Discovery, Path Selection, Path Management sind dazu einige Stichworte.

MPLS differiert zum OXC jedoch in einer bestimmten Charakteristik. Während MPLS die Möglichkeit zum Schalten von Paketen (Packet Level Processing) definiert, stellt der OXC an seiner Schnittstelle lediglich einen wellenlängen abhängigen, optischen und transparenten Kanal zur Verfügung. Funktionen des Transport- und Data Link Layers fehlen dabei. D.h. mit anderen Worten zur Überbrückung dieser beiden Charakteristiken fehlen dem MPLambdaS mindestens die Bitsynchronisation, die Taktverteilung und die Paketgrenzerkennung. Oder wiederum mit anderen Worten, genau diejenigen Funktionen, welche eine SDH Technik mit PoS oder ein ATM Technik als Transport- und Data Link Layer definieren, um überhaupt ein MPLS oder IP Paket zu übertragen.

Wie sich der OXC genau entwickelt, kann momentan kaum vorausgesagt werden. Tatsache bleibt lediglich, das Funktionen wie Bitsynchronisation und Paketgrenzerkennung kaum weggelassen werden können. Ob sie jedoch im OXC, im Router oder als eigenständige Box realisiert werden, wird heute jedenfalls nirgends definiert. Einen ersten Ansatz dafür, dürfte ein Protokoll namens Simplified Data Link (SDL) versprechen.