RFC 3031 - Kernbestandteile der MPLS-Architektur (Detailed MPLS Architecture)

3. Kernbestandteile der MPLS-Architektur (Detailed MPLS Architecture)

3.1 Weiterleitungs-Äquivalenzklasse (FEC)

Eine „Forwarding Equivalence Class“ ist eine Menge von Paketen, die auf dieselbe Weise über denselben Pfad weitergeleitet werden. Das Zuordnungskriterium kann ein Netzwerkschicht-Zielpräfix, ein expliziter Routenpfad, eine Service-Klasse (CoS), eine Quelladresse oder eine Anwendungskennung sein. Die Granularität der FEC ist lokal festgelegt.

3.2 Label

Ein Label ist ein kurzer, festlängiger Bezeichner mit rein lokaler Bedeutung. Es ist nur innerhalb des „Label-Raums“ eindeutig, in dem es verteilt wird. Ein Label kann im MPLS-spezifischen „Shim“-Header kodiert oder direkt in ATM VPI/VCI bzw. Frame-Relay DLCI geschrieben werden.

3.3 Label Switching Router (LSR)

Ein LSR führt aus: Suche der ILM anhand des Eingangs-Labels, Stack-Operationen (Ersetzen, Pushen, Poppen) gemäß Ergebnis, Weiterleitung an den nächsten Hop. Ein LER ist ein am Rand stehender LSR, der zwischen unmarkierten und markierten Paketen konvertiert.

3.4 Label-Bindung und Label-Verteilung

Eine „Label-Bindung“ entsteht, wenn ein Downstream-LSR (Rd) ein Label L an eine FEC F bindet und diese Bindung über das Label-Verteilungsprotokoll seinem Peer (Ru) bekannt gibt. Ru weiß danach: Um Pakete der FEC F an Rd zu senden, wird Label L verwendet.

3.5 Label-Verteilungsmodus (Label Distribution Mode)

• Downstream on Demand: Ru fordert das Label einer FEC explizit von Rd an.
• Downstream Unsolicited: Rd kündigt seine Bindungen ohne vorherige Anfrage aktiv an.

3.6 Label-Steuermodus (Label Control Mode)

• Independent: Jeder LSR bindet und verteilt ein Label, sobald er eine FEC erkennt (ähnlich der klassischen IP-Konvergenz).
• Ordered: Ein LSR bindet und verteilt ein Label für eine FEC nur, wenn er deren LSP-Ausgang ist oder bereits eine Bindung vom nächsten Hop erhalten hat. Ordered Control stellt sicher, dass der LSP vollständig ist, bevor Verkehr fließt — nützlich bei Pfaden mit bestimmten Eigenschaften (Ressourcenreservierung, explizites Routing, keine doppelten Knoten).

3.7 Label-Rückhalte-Modus (Label Retention Mode)

• Liberal: Ru behält Bindungen von Rd auch dann, wenn Rd nicht der nächste Hop ist, für schnelle Wiederverwendung nach Routenänderung (Kosten: mehr Labels).
• Conservative: Ru verwirft Bindungen von einem Nicht-Next-Hop Rd und holt sie bei Bedarf neu (Kosten: Neuaubau, aber weniger Label-Belegung).

3.8 Label-Stack

MPLS unterstützt einen Label-Stack (LIFO). Es können mehrere Labels gepusht werden. Die Weiterleitung basiert stets auf dem obersten Label, unabhängig von dessen Hierarchieebene. Bei Stack-Tiefe m spricht man von Level-1- bis Level-m-Labels. Der Stack ermöglicht „LSP-Tunnel“ und „MPLS-Hierarchie“ (§3.27).

3.9 NHLFE (Next-Hop-Label-Forwarding-Entry)

Die NHLFE dient der Weiterleitung markierter Pakete und enthält:

1. den nächsten Hop;
2. die Stack-Operation: oberstes Label ersetzen / poppen / ersetzen und ein oder mehrere neue Labels pushen;
3. ggf. Link-Kapselung, Stack-Kodierung und weitere nötige Informationen.

Ist der nächste Hop der LSR selbst, muss gepoppt und erneut (über restliches Label oder natives IP) entschieden werden.

3.10 ILM (Incoming Label Map)

Die ILM bildet jedes Eingangs-Label auf eine Menge von NHLFE ab. Bei mehreren muss vor der Weiterleitung eine ausgewählt werden (z. B. ECMP-Lastverteilung). Die Auswahl ist architekturextern.

3.11 FTN (FEC-to-NHLFE)

Die FTN dient Paketen, die unmarkiert eintreffen, aber vor dem Weiterleiten markiert werden sollen. Der LSR analysiert den Netzwerkschicht-Header, bestimmt die FEC und bildet über die FTN auf eine NHLFE ab. Bei Mehrfachabbildung erfolgt eine Auswahl.

3.12 Label-Swapping

Markiertes Paket: LSR sucht oberstes Label → ILM → NHLFE → nächster Hop und Stack-Operation → Kodierung und Weiterleitung. Unmarkiertes Paket: LSR analysiert Header → FEC → FTN → NHLFE → Label pushen und weiterleiten.

Wichtig: Beim Label-Switching stammt der nächste Hop immer aus der NHLFE und kann vom „Nicht-MPLS“-Next-Hop abweichen.

3.13 Geltungsbereich und Eindeutigkeit von Labels

Rd kann L1 an FEC F für Ru1 und L2 an dieselbe FEC F für Ru2 binden; L1==L2 ist lokal entschieden. Kann Rd unterscheiden, ob das empfangene oberste Label L von Ru1 oder Ru2 gepusht wurde, ist F1==F2 nicht erforderlich; Rd gilt dann als Nutzer unterschiedlicher „Label-Räume“.

Ein nur „interface-bezogener“ Label-Raum (per-interface) ist nur zulässig, wenn Ru1 und Ru2 die einzigen Verteiler-Peers sind und jeweils per Point-to-Point verbunden. Sonst muss das Label geräteweit eindeutig sein (per-platform). Bei zwei Point-to-Point-Verbindungen zu Ru kann Rd denselben Wert an unterschiedliche FEC binden, aber nur, wenn die Bindung nur für genau diese Schnittstelle gilt. Ansonsten darf Rd einen Wert nie an zwei verschiedene FEC binden (auch nicht auf unterschiedlichen Ebenen — MPLS kennt keinen „Label-Raum pro Ebene“).

3.14 Label-Switched Path (LSP), Eingang und Ausgang

Ein „LSP der Ebene m“ ist eine Folge <R1, ..., Rn>, wobei R1 (LSP-Eingang) ein Label pusht, sodass die Tiefe m ist; jedes Ri leitet anhand des Level-m-Labels (ILM) weiter; von R1 bis R[n-1] bleibt die Tiefe ≥ m; durchquerte L2-Switches S entscheiden nicht nach Level-m-Label oder Netzwerkschicht-Header.

Ein „LSP für eine FEC F“ ist für ein Paket P der Level-m-LSP, dessen Level-m-Label zu F gehört. Ein Baum, der mehrere Eingangs-LSP auf einen Ausgang vereint, heißt „LSP-Baum“ (Multipoint-to-Point) der FEC.

3.15 Penultimate Hop Popping

Nach §3.14 darf R[n-1] P an Rn mit Tiefe m-1 senden, also am vorletzten Hop poppen statt am Ausgang. Das ist architektonisch korrekt: Das Level-m-Label dient nur, P zu Rn zu bringen; sobald R[n-1] an Rn sendet, ist es nutzlos.

Vorteil: Der Ausgang macht nur eine Suche (statt zwei), ebenso der vorletzte Hop — vereinfacht den Hardware-Fast-Path. Der LSP-Ausgang muss dann kein LSR sein. Da aber manche Hardware nicht poppen kann, ist es nicht erzwungen: Der vorletzte Hop poppt nur, wenn der Ausgang es „explizit anfordert“ oder der LSP-Next-Hop kein MPLS unterstützt. Ein pop-fähiger LSR muss auf Anforderung des Downstream-Peers poppen. Die Initialverhandlung muss klären, ob der Nachbar poppen kann; wer es nicht kann, darf nicht darum gebeten werden.

3.16 LSP-Next-Hop

Der „LSP-Next-Hop“ eines markierten Pakets in einem LSR ist der von der verwendeten NHLFE angegebene nächste Hop. Für eine FEC ist es der von der zu ihr gehörenden NHLFE angegebene Hop. Er kann vom von der Netzwerkschicht-Routing gewählten Hop (L3-Next-Hop) abweichen.

3.17 Ungültige Eingangs-Labels

Erhält ein LSR ein markiertes Paket, dessen Eingangs-Label keine Bindung hat, darf es das Label nicht einfach entfernen und als unmarkiertes IP-Paket weiterleiten — das kann eine Schleife bilden (Upstream denkt explizites Routing, Downstream sieht keine Bindung, das unmarkierte Hop-by-Hop-Routing kann das Paket zum Upstream zurückschicken). Solche Pakete sind daher zu verwerfen, es sei denn, man kann sicherstellen, dass unmarkierte Weiterleitung unschädlich ist.

3.18 LSP-Steuerung: Ordered vs Independent

Siehe §3.6. Independent entscheidet lokal (wie klassische IP-Konvergenz). Ordered bindet nur am Ausgang oder nach Erhalt einer Bindung vom Next-Hop. Muss der Verkehr einem Pfad mit bestimmten Eigenschaften folgen (keine doppelten Knoten, Ressourcengarantie, expliziter Pfad), ist Ordered nötig. Ein Ordered LSP kann vom Eingang oder Ausgang gestartet werden. Beide Steuermodi sind voll interoperabel; ein nicht-geordneter Knoten im LSP lässt das Verhalten aber weitgehend wie Independent wirken. Die Architektur überlässt die Wahl als lokale Angelegenheit.

3.19 Aggregation

Eine FEC pro Routing-Tabellenpräfix kann im MPLS-Bereich viele FEC erzeugen, die denselben Pfad nehmen. Man kann dann die Vereinigung dieser FEC zu einer größeren FEC zusammenfassen und nur ein Label binden — „Aggregation“. Sie reduziert Label-Zahl und Verteilungs-Traffic.

Bei aggregierbaren FEC wählt man (a) eine FEC (gröbste Granularität), (b) mehrere FEC, oder (c) keine Aggregation (feinste). Bei Ordered muss jeder LSR seine Granularität an den Next-Hop anpassen. Bei Independent können benachbarte LSR unterschiedlich fein sein: Ist Ru feiner als Rd, mappt er einfach mehr Labels auf Rd's weniger; ist Ru gröber, bevorzugt er Rd's feinere Granularität (m zurückziehen, n verteilen) oder mappt seine m Labels auf eine Teilmenge von Rd's n (wenn das Routing-Ergebnis gleich ist). Jeder LSR muss (per Konfiguration) die Granularität seiner Labels kennen.

3.20 Routenauswahl (Route Selection)

MPLS unterstützt zwei LSP-Routenauswahlen: (1) hop-by-hop; (2) explizit. Hop-by-hop wählt jeder Knoten selbst (klassisches IP). Explizit spezifiziert ein einzelner LSR (meist Eingang/Ausgang) alle oder einige Knoten: alle = strikt, einige = lose. Die Sequenz kann konfiguriert oder dynamisch berechnet werden. Explizites Routing dient Policy-Routing und Traffic Engineering; MPLS gibt es bei der Label-Zuweisung an — viel effizienter als IP-Source-Routing. Details sind architekturextern.

3.21 Fehlendes Ausgangs-Label (Lack of Outgoing Label)

Ein markiertes Paket auf einem LSP kann einen LSR erreichen, dessen ILM das (gültige) Eingangs-Label auf keine NHLFE abbildet (transient oder falscher Next-Hop). Auch hier darf der Stack nicht einfach entfernt und nach Netzwerkschicht-Header weitergesendet werden — bei explizitem LSP droht Schleife, und der Header reicht evtl. nicht zur korrekten Entscheidung. Sofern nicht beides ausgeschlossen werden kann, ist das einzig Sichere, das Paket zu verwerfen.

3.22 Time To Live (TTL)

Klassisches IP dekrementiert TTL pro Hop und verwirft bei 0, was Schutz gegen Schleifen aus Konfigurationsfehlern oder langsamer Konvergenz bietet; TTL dient auch Multicast-Reichweite und traceroute. MPLS muss zwei Aspekte behandeln: (i) Schleifenunterdrückung; (ii) Reichweitenkontrolle u. a.

Nach Durchlaufen eines LSP muss die TTL eines Pakets der ohne Label-Switching gleichen Routerfolge entsprechen; bei LSP-Hierarchie muss die Gesamtzahl durchlaufener LSR-Hops in der TTL reflektiert sein.

Die Behandlung hängt von der Label-Kodierung ab — MPLS-Shim ([MPLS-SHIM]) oder L2-Header (ATM [MPLS-ATM], FR [MPLS-FRMRLY]):

• Shim-Header: Das TTL-Feld ist obligatorisch; es wird aus dem Netzwerkschicht-TTL geladen, pro LSR-Hop dekrementiert und am LSP-Austritt zurückkopiert.
• L2-Header (z. B. ATM VPI/VCI) ohne TTL: Hopweises Dekrement unmöglich. Ein solches „Non-TTL-LSP-Segment“ erfordert am Austritt eine TTL, die die Zahl der LSR-Hops widerspiegelt (bei Unicast kann die LSP-Länge zum Eingang propagiert und dort vordiziert werden). Lässt sich am Eintritt eines Non-TTL-Segments erkennen, dass die TTL vor Austritt erschöpft, darf der LSR nicht label-switchen (eigene Verfahren für traceroute bleiben zu entwickeln).

3.23 Schleifenkontrolle (Loop Control)

Auf einem Non-TTL-LSP-Segment schützt TTL nicht vor Schleifen. Die Bedeutung hängt von der Hardware ab. Beispiel: Kann ATM-Hardware TTL nicht dekrementieren, gibt es keinen Schutz; bietet sie fairen Pufferzugriff je VPI/VCI, bleibt eine transiente Schleife folgenlos; sonst verschlechtert sie die Gesamtleistung stark.

Selbst bei fairem Puffer lohnt es, Schleifen jenseits einer plausiblen Dauer zu erkennen. Und selbst überlebbar über TTL/faire Queues sollte man Schleifen-LSP wenn möglich vermeiden. Daher muss jeder LSR, der an ein Non-TTL-Segment angrenzen kann, eine gemeinsame Schleifenerkennung unterstützen — deren Nutzung ist optional (siehe [MPLS-ATM], [MPLS-LDP]).

3.24 Label-Kodierungen (Label Encodings)

Zum Transport des Label-Stacks mit dem Paket muss eine konkrete Kodierung definiert sein. Die Architektur unterstützt je nach Hardware mehrere.

3.24.1 Dedizierte MPLS-Hardware/Software

Am direktesten: Ein „Shim“-Protokoll zwischen Sicherungsschicht und Netzwerkschicht-Header als protokollunabhängige Kapselung (generic MPLS encapsulation), getragen von der Sicherungsschicht. Siehe [MPLS-SHIM].

3.24.2 ATM-Switch als LSR

Der MPLS-Transfer ähnelt dem ATM-Switching: Der Switch indexiert eine Cross-Connect-Tabelle per Port + VPI/VCI. Lässt sich das Label in diese Felder kodieren, genügt ein Software-Upgrade zum ATM-LSR. Drei Kodierungen im ATM-Zellheader (AAL5):

1. SVC: VPI/VCI kodiert das oberste Label. Jedes LSP ist ein ATM SVC; das Verteilungsprotokoll ist ATM-Signaling. Dieser Modus erlaubt keine Push/Pop-Operationen.
2. SVP: VPI kodiert das oberste Label, VCI das zweite (falls vorhanden). Realisiert ATM-VP-Switching (LSP = SVP). Falls ein ATM-Virtual-Path ein Nicht-MPLS-Netz durchquert, ist VPI evtl. nicht frei; am VP-Ausgang führt der ATM-LSR faktisch ein Pop aus.
3. SVP Multipoint: VPI kodiert das oberste Label, ein VCI-Teil das zweite, der Rest die LSP-Eingangskennung. Über VP-Switching wird ein Multipoint-to-Point-VP realisiert, bei dem Zellen verschiedener Quellen unterschiedliche VCI tragen — ermöglicht Label-Merging ohne Zellvermischung auf Switches ohne VC-Merge. Dies setzt die Vergabe von 16-Bit-VCI-Werten ohne Überlappung voraus.

Übersteigt die Zahl der Stack-Labels die ATM-Kapazität, kombiniert man ATM- mit Shim-Kodierung.

3.24.3 Interoperabilität der Kodierungen

Verschiedene Hops eines LSP dürfen unterschiedliche Kodierungen nutzen. Der LSR muss den aktuellen Stack dekodieren, operieren und für den Next-Hop kodieren. Ein ATM-Switch kann aber nicht zwischen zwei Kodierungen konvertieren; daher verlangt die Architektur, dass zwei ATM-Switches, die auf einem Level-m-LSP aufeinanderfolgen können, dieselbe Kodierung nutzen. Ein gemischter LSR (ATM + Shim) kann am Eingang ATM-Labels entfernen und am Ausgang Shim-Labels aufsetzen.

3.25 Label-Merging

Wenn ein LSR mehrere Eingangs-Labels an dieselbe FEC bindet und für diesen Verkehr nur ein Ausgangs-Label verwenden will — das ist „Label-Merging“.

Ein LSR „kann mergen“, wenn er Pakete von unterschiedlichen Interfaces/Labels empfangen und mit demselben Label über dasselbe Ausgangs-Interface senden kann (die Herkunftsinformation geht dann verloren). Er „kann nicht mergen“, wenn Pakete von unterschiedlichen Interfaces/Labels an unterschiedliche Interfaces/Labels müssen. ATM-LSR mit SVC/SVP können nicht mergen.

Ein nicht-mergender LSR muss Pakete derselben FEC mit unterschiedlichen Eingangs-Labels an unterschiedliche Ausgangs-Labels senden. Beim Mergen genügt 1 Ausgangs-Label pro FEC; sonst bis zu Netzwerk-Knotenzahl. Die Architektur umfasst beide LSR-Typen und deren Interoperabilität.

3.25.1 Nicht-mergende LSR

Der MPLS-Transfer ähnelt ATM/Frame Relay: Suche in einer Cross-Connect-Tabelle per Label (VPI/VCI oder DLCI), Portwahl, Label-Umschreibung; das Verteilungsprotokoll wirkt als Signalisierung. Diese Techniken unterstützen aber nicht immer Merging: Erzwungenes Merging auf ATM vermischt Zellen verschiedener Pakete irreparabel; manche Frame-Relay-Switches mit Zell-Backplane haben dasselbe Problem.

MPLS bietet zwei Lösungen: Verfahren, die nicht-mergende LSR zulassen, und Unterstützung einiger ATM-Switches als mergende LSR. MPLS enthält auch die korrekte Interoperabilität beider.

3.25.2 Labels für mergende / nicht-mergende LSR

Ein mergender Upstream-LSR braucht nur ein Label pro FEC; ein nicht-mergender Upstream-Peer braucht mehrere (Zahl a priori unbestimmt). Die Architektur bestimmt: An einen nicht-mergenden Upstream-Peer darf man kein Label senden, außer er fordert es explizit an; er darf mehrfach fordern und erhält jeweils ein neues; ist der Downstream-Peer selbst nicht-mergend, muss er seinerseits eines beim eigenen Downstream anfordern.

Ein Knoten, der nur wenige Eingangs-Labels mergen kann (z. B. max. 4 von 6), darf auf zwei Ausgangs-Labels mergen. Die Anwendbarkeit von Merging auf explizit geroutete LSP bleibt offen.

3.25.3 Merging auf ATM

Zellvermischung vermeiden:

1. VP-Merge (SVP Multipoint): Mehrere Virtual Paths werden zu einem gemergt, unterschieden durch verschiedene VCI im VP.
2. VC-Merge: Der Switch puffert alle Zellen eines Pakets bis zur vollständigen AAL5-Endemarke, dann Senden.

VP-Merge verträgt sich mit mehr ATM-Implementierungen und führt keine Latenz/Puffer am Merge-Punkt ein, erfordert aber Koordination des VCI-Raums im VP. Die Wahl bleibt offen. MPLS sollte beide unterstützen; jeder beteiligte ATM-Switch muss wissen, ob sein direkter Nachbar VP-Merge, VC-Merge oder kein Merge macht.

Interoperabilität (VC / VP / kein Merge): Am einfachsten VC-Merge und kein Merge, da beide auf VC-Forwarding (VPI/VCI) basieren. Macht der Upstream VC-Merge, genügt ein VPI/VCI; macht er kein Merge, braucht er eines für sich plus genug für seine Upstreams. Ein VP-Knoten fordert einen VP (VPI) plus mehrere VCI darin. Für alle drei gleichzeitig muss der Upstream eine Kombination aus „null oder mehr VC (VPI/VCI) + null oder mehr VP (VPI), je mit angegebener VCI-Zahl“ fordern dürfen.

3.26 Tunnel und Hierarchie (Tunnels and Hierarchy)

Ein Router Ru kann ein Paket explizit an einen anderen Router Rd liefern, obwohl beide nicht adjazent auf dem Hop-by-Hop-Pfad sind und Rd nicht das Ziel ist — etwa durch Kapselung in ein an Rd adressiertes Netzwerkschicht-Paket, was einen „Tunnel“ Ru→Rd bildet. Solch ein Paket heißt „tunnelgekapselt“.

• Hop-by-Hop-Routing-Tunnel: Das gekapselte Paket folgt dem Hop-by-Hop-Pfad Ru→Rd; „Sendepunkt“ Ru, „Empfangspunkt“ Rd.

• Explizit gerouteter Tunnel: Das gekapselte Paket folgt einem nicht-Hop-by-Hop-Pfad (z. B. Source-Routing).

• LSP-Tunnel: Ein Tunnel, realisiert durch ein LSP, das Paket durchquert per Label-Switching statt Netzwerkschicht-Kapselung. Der Tunnel ist das LSP <R1, ..., Rn>, R1 Sender, Rn Empfänger. Die hineinzusendenden Pakete bilden eine FEC; jeder LSR im Tunnel muss dieser FEC (dem Tunnel) ein Label zuweisen. Man sendet ein Paket in den Tunnel, indem der Sender das Tunnel-Label pusht und an den Tunnel-Next-Hop sendet. Braucht der Empfangspunkt keine Unterscheidung, poppt der vorletzte Hop.

  • „Hop-by-Hop-LSP-Tunnel“ = LSP zwischen Sender und Empfänger.
  • „Explizit gerouteter LSP-Tunnel“ = LSP-Tunnel, der zugleich explizit geroutetes LSP ist.

• Hierarchie: LSP-Tunnel in einem LSP: Betrachte <R1,R2,R3,R4>. R1 pusht für diesen Pfad, doch R2 und R3 sind nicht direkt verbunden, sondern als Endpunkte eines LSP-Tunnels adjazent. P verläuft dann <R1,R2,R21,R22,R23,R3,R4>. R1→R2 Tiefe 1; R2 ersetzt durch ein für R3 sinnvolles Label und pusht ein Level-2-Label für R21; R21/R22/R23 switchen auf Level-2; R23 (vorletzter Hop des Tunnels R2-R3) poppt zu R3; R3 sieht P nur mit Level-1-Label (aus dem Tunnel) und poppt als vorletzter Hop des Level-1-LSP; R4 erhält P unmarkiert. Der Stack erlaubt beliebig tiefe Verschachtelung.

• Verteilungs-Peers und Hierarchie: Auf dem Level-1-LSP <R1,R2,R3,R4> nutzt R2→R3 das Level-2-LSP <R2,R21,R22,R3>. Für Level 2 ist R21 der Peer von R2; für Level 1 sind R1 und R3 Peers. Jede Ebene hat ihre Peers. R2 und R21 müssen IGP-Nachbarn sein; R2 und R3 nicht zwingend.

  • IGP-Nachbarn = „lokaler Peer“; Nicht-IGP-Nachbarn, aber Peer-fähig = „ferner Peer“. Hier R2-R21 lokal, R2-R3 fern.
  • Die Architektur unterstützt zwei Verteilungsarten zwischen Ebenen: expliziter Peer (explizit adressierte Nachrichten, gut für wenige ferne Peers) und impliziter Peer (das obere Label wird als Attribut des unteren mitverteilt und vom lokalen Peer weitergegeben, gut für viele ferne Peers, zwingt Zwischenknoten aber zur Speicherung fremder Info).

3.27 Transport des Verteilungsprotokolls (Label Distribution Protocol Transport)

Das Verteilungsprotokoll etabliert und erhält Label-Bindungen zwischen MPLS-Knoten. Es verlangt zuverlässigen Transport, geordnete Nachrichten pro FEC, möglichst Flusskontrolle und mehrere Nachrichten pro Datagramm. Ein Weg ist TCP als Transport (so [MPLS-LDP] und [MPLS-BGP]).

3.28 Warum mehr als ein Verteilungsprotokoll?

Die Architektur schreibt keine feste Regel vor, weist aber hin:

• BGP und LDP: Oft ist das Binden an eine durch Adresspräfix identifizierbare FEC sinnvoll. Verteilt ein Standard-Routing-Algorithmus diese Routen, ist „Piggybacking“ der Label-Verteilung optimal. BGP verteilt solche Routen; nutzt ein BGP-Speaker BGP auch für Labels ([MPLS-BGP]), kann der BGP-Route-Reflector ebenfalls Labels verteilen — mit klarem Skalierungsvorteil gegenüber LDP zwischen BGP-Peers.
• Labels für RSVP Flowspec: Bei RSVP-Ressourcenreservierung für einen Flow macht es das effizienteste, wenn RSVP die Labels beim path/resv-Aufbau mitschickt.
• Labels für explizit geroutete LSP: Traffic Engineering braucht explizites Routing mit Reservierung. Zwei Ansätze: RSVP um Label-Verteilung/Explizit-Routing erweitern ([MPLS-RSVP-TUNNELS]) oder LDP um Explizit-Routing/Reservierung erweitern ([MPLS-CR-LDP]).

3.29 Multicast

Abschnitt bleibt weiterführenden Untersuchungen vorbehalten.

---