Speed-up mit MPLS

Von: Mark Schenkl

Die Aufgabe "Halte die Anzahl der nötigen Router-Hops auf einer Übertragungsstrecke so gering wie möglich!" ist heute noch nicht optimal gelöst. So wird beispielsweise in IP-Legacy-Netzen jedes einzelne Paket von einem Router zum nächsten weitergereicht. Diese müssen dazu die Header der Datenpakete analysieren und anhand der darin abgelegten Informationen eine Wegewahl treffen (Hop-by-Hop-Routing). Das Verfahren ist relativ aufwendig und erhöht insbesondere in IPoA-Netzwerken (IPoA = Internet Protocol over ATM), die Verzögerungszeiten; dort müssen die IP-Pakete obendrein aus den ATM-Zellen erzeugt und nach der Analyse wieder in solche eingekapselt werden.

Layer-3-Switches umgehen solche Einschränkungen, sind jedoch meist proprietär und an bestimmte Verbindungstechniken, beispielsweise Ethernet, gebunden. Deshalb hat sich die Internet Engineering Task Force (IETF) dazu entschlossen, einen Standard zu entwickeln, der die Unabhängigkeit von Herstellern und Protokollen gewährleisten soll. Leider steckt er noch in den Kinderschuhen, der Draft-Phase, so daß die im folgenden beschriebenen Details von "Multiprotocol Label Switching" (MPLS) noch als vorläufig zu betrachten sind.

Grundlagen

Die zentrale Komponente in MPLS-Netzwerken ist der sogenannte "Label Switching Router" (LSR). Er teilt die zu transportierenden IP-Pakete in sogenannte "Forwarding Equivalence Classes" (FECs) ein, wobei er sich an den Layer-3-Zieladressen oder anderen, noch nicht näher spezifizierten Merkmalen orientiert. Anschließend übermittelt er die FECs an den nächsten LSR.

MPLS sieht für jede FEC ein lokal eindeutiges Label fester Länge vor. Seine Funktion ähnelt den "Virtual Path Identifiers" (VPIs) und "Virtual Channel Identifiers" (VCIs) bei ATM oder dem "Tag" beim Tag Switching von Cisco. Anhand des Labels leiten nachgeschaltete Router die ankommenden Datenpakete weiter - ein Prozeß, der auch als "Label Switching" bezeichnet wird. Die LSRs müssen dabei weder Layer-3-Adreßfelder auswerten noch Routing-Tabellen durchforsten.

Der Netzwerk-Abschnitt, auf dem ein Datenpaket via Label Switching von LSR zu LSR weitergereicht wird, heißt "Label Switching Path" (LSP). Verläßt ein Datenpaket den LSP, muß das betreffende Label vom sogenannten "egress" LSR entfernt werden. Die Vergabe eines Labels für eine FEC liegt bei dem aus Sicht des Datenstroms "downstream" (d) gelegenen LSR (Bild 1a, "Solicited Downstream"); wahlweise kann auch ein "up-stream" (u) lokalisierter LSR ein Label anfordern (Bild 1b, "Downstream on Demand"). En Detail geschieht dies folgendermaßen (Bild 1):

l Unsolicited Downstream:

l LSR d erkennt eine FEC und weist LSR u an, allen dazugehörigen Datenpaketen das Label "L" anzuheften. LSR d trifft nun anhand von L sämtliche Wegewahlentscheidungen, die den FEC A betreffen. In diesem Szenario muß bereits ein Datentransfer zwischen LSR d und LSR u bestehen.

l Downstream on Demand:

l LSR u will Daten über LSR d verschicken. Er weist diesen Daten die FEC A zu und fordert LSR d auf, ihm dafür ein Label mitzuteilen (Label Request). Das tut LSR d und übermittelt LSR u das Label L. LSR u markiert daraufhin alle der FEC A entsprechenden Pakete mit L. Der Verbindungsaufbau entspricht dem in ATM-Netzwerken und wird daher auch dort empfohlen.

MPLS schreibt bei der Vergabe von Labels kein besonderes Protokoll vor; außer dem speziell entwickelten "Label Distribution Protocol" (LDP) kommen auch andere in Frage, beispielsweise "Border Gateway Protocol" (BGP) oder "Resource Reservation Protocol" (RSVP).

Auf einem Lifo-Stapel, (Lifo = last in, first out), dem sogenannten "Label Stack" (Bild 2), können die Labels abgelegt werden. Er wird als zusätzlicher Header zwischen den Layer-2- und den Layer-3-Header gestellt. Um MPLS-Pakete in Ethernet-Netzwer-ken identifizieren zu können, wurde ein neuer "Ethertype" definiert: "0x8847" für Unicast- und "0x8848" für Multicast-MPLS-Pakete. Alternativ kann das oberste Element des Label-Stacks direkt in die entsprechende Layer-2- beziehungsweise Layer-3-PDU (PDU = Protocol Data Unit) hineinkodiert werden - besonders bequem, wenn nur ein Label pro PDU zugelassen ist und auf den Stack verzichtet wird.

MPLS in ATM-Netzen

In ATM-Netzen ist LDP das für die Label-Reservierung bevorzugte Protokoll. Der Label-Wert wird dabei direkt in den VPI und VCI oder auch nur in den VCI hineinkodiert. Verwendet man einen Label-Stack, so muß dieser analog zur oben erklärten Verfahrensweise als zusätzlicher Header vor das IP-Paket gestellt werden.

Ein IPoA-Netzwerk (IPoA = Internet Protocol over ATM), das konsequent MPLS fährt, benötigt weder eine explizite ATM-Adressierung der End-systeme noch ATM-Routing; für den Verbindungsaufbau sind also keine Adreßauflösungsmechanismen wie bei "Classical IP over ATM" (CLIP) oder "LAN Emulation" (LANE) mehr nötig. Die LSRs müssen lediglich IP-Routing-Algorithmen ausführen, etwa "Open Shortest Path First" (OSPF), und anhand des Resultats eine Wegewahl treffen. Bild 3 zeigt einen möglichen Ablauf.

MPLS ermöglicht Source-Routing als Alternative zum Hop-by-Hop-Routing. Dabei durchlaufen die LDP-Nachrichten das Netzwerk auf dem vorgegebenen Pfad und nehmen in den betroffenen LSRs die Reservierungen (Label-Zuweisungen) vor. Vorteil: Die beteiligten LSRs benötigen keine Informationen über das verwendete Layer-3-Protokoll, müssen also weder IP-Routing beherrschen noch eine IP-Wegewahl treffen.

Die LDP-Pakete werden mittels LLC-SNAP-Einkapselung (LLC = Logical Link Control, SNAP = Subnetwork Attachement Point) über "ATM-Adaptation Layer" (AAL) 5 entsprechend "Request for Comment" (RFC) 1483 übertragen. Um die LDP-Nachrichten im Netz verteilen zu können, ist in jedem Fall mindestens eine Nicht-MPLS-Verbindung nötig. Wenn VPI und VCI von MPLS als Label verwendet werden, hat die Nicht-MPLS-Verbindung den VCI/VPI-Wert "0/32". Wird nur VCI als Label verwendet, so wird pro VPI der VCI-Wert "32" für den LDP-Verkehr reserviert.

Befinden sich zwischen zwei Peer-LSRs ein oder mehrere nicht-MPLS-fähige ATM-Switches, so kann das Label nicht zur Identifikation der Verbindung in den LDP-Nachrichten dienen. Denn die VPIs und VCIs werden von den nicht-MPLS-fähigen ATM-Switches verändert. Daher erhält eine solche Verbindung einen eindeutigen "Virtual Connection Identifier". Er wird von der upstream gelegenen LSR bestimmt und an den downstream gelegenen LSR übermittelt: entweder durch eine eigene VCID-Nachricht oder implizit während des Verbindungsaufbaus.

Ein Schwachpunkt, welcher in realen ATM-Umgebungen zu Tage tritt, ist die begrenzte Anzahl gleichzeitig nutzbarer VPIs und VCIs. MPLS bietet als Ausweg das sogenannte "Label Merging". Eine an ATM-Netzwerke angepaßte Variante ist "VC Merge".

Label Merge

Angenommen, ein LSR d vermittelt bereits eine FEC A und hat dieser das Label L1 zugewiesen (Bild 4). Erkennt er nun etwa anhand der identischen Zieladresse eine zweite FEC A oder wird er von einem LSR u2 aufgefordert, dieser zweiten FEC A ein weiteres Label zuzuordnen, so hat er die Möglichkeit, die beiden Datenströme unter einem einzigen Label "L1" zu vereinen (merge). Mit anderen Worten: Er fordert von LSR dd kein neues Label für diesen Datenstrom an, sondern verwendet für beide dasselbe Label L1. Unabhängig davon, ob LSR d den Merge durchführt oder nicht, muß er an LSR u2 ein neues Label vergeben, weil dieser VC Merge unter Umständen nicht unterstützt.

Das größte Problem bei der Implementierung von VC Merge ist die Einhaltung der zugesicherten Reihenfolge der ATM-Pakete. Zellen aus verschiedenen Datenströmen dürfen lediglich an den SAR-PDU-Grenzen (SAR = Segmentation and Reassem-bly Sublayer) vermischt werden (Bild 5). Ein VC-Merge-fähiger Switch muß also die Grenzen der SAR-PDUs erkennen.

MPLS zieht keine Hardwaremodifikationen der Endsysteme nach sich, vielmehr genügt ein Software-Update der Komponenten, um das Netzwerk MPLS-fähig zu machen. Der neue Standard macht unabhängig von der Verbindungstechnik. Gerade im WAN-Bereich dürfte das in Zukunft ein nicht zu unterschätzender Vorteil sein. (sk)

Web-Links:

IETF Working Group MPLS

http://www.ietf.org/html.charter/mpls-charter.html

Literatur:

[1] Rosen, E.C., Viswanathan, A. et.al.: Multiprotocol Label Switching Architecture, draft-ietf-mpls-arch-04.txt, IETF, Februar 1999.