Zum Hauptinhalt springen

1. Einleitung

In einer MPLS-Domäne [MPLS_ARCH] kann, wenn ein Datenstrom einen gemeinsamen Pfad durchquert, ein Label Switched Path (LSP) unter Verwendung von MPLS-Signalisierungsprotokollen eingerichtet werden. Am Ingress Label Switch Router (LSR) wird jedem Paket ein Label zugewiesen und es wird stromabwärts übertragen. An jedem LSR entlang des LSPs wird das Label verwendet, um das Paket zum nächsten Hop weiterzuleiten.

In einer Differentiated-Service-(Diff-Serv)-Domäne [DIFF_ARCH] bilden alle IP-Pakete, die eine Verbindung überqueren und dasselbe Diff-Serv-Verhalten erfordern, ein Behavior Aggregate (BA). Am Eingangsknoten der Diff-Serv-Domäne werden die Pakete klassifiziert und mit einem Diff-Serv Code Point (DSCP) markiert, der ihrem Behavior Aggregate entspricht. An jedem Transitknoten wird der DSCP verwendet, um das Per Hop Behavior (PHB) auszuwählen, das die Scheduling-Behandlung und in manchen Fällen die Verwerfungswahrscheinlichkeit für jedes Paket bestimmt.

Dieses Dokument spezifiziert eine Lösung zur Unterstützung der Diff-Serv Behavior Aggregates, deren entsprechende PHBs derzeit definiert sind (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]), über ein MPLS-Netzwerk. Diese Lösung bietet auch Flexibilität für die einfache Unterstützung von PHBs, die in Zukunft definiert werden könnten.

Diese Lösung stützt sich auf die kombinierte Verwendung von zwei Arten von LSPs:

  • LSPs, die mehrere Ordered Aggregates transportieren können, sodass das EXP-Feld des MPLS-Shim-Headers dem LSR das auf das Paket anzuwendende PHB übermittelt (einschließlich Informationen sowohl über die Scheduling-Behandlung des Pakets als auch über dessen Drop Precedence).

  • LSPs, die nur ein einzelnes Ordered Aggregate transportieren, sodass die Scheduling-Behandlung des Pakets vom LSR ausschließlich aus dem Labelwert des Pakets abgeleitet wird, während die Drop Precedence des Pakets im EXP-Feld des MPLS-Shim-Headers oder im einkapselnden verbindungsschichtspezifischen selektiven Verwerfungsmechanismus (ATM, Frame Relay, 802.1) übermittelt wird.

Wie in [DIFF_HEADER] erwähnt, „sind Dienstanbieter nicht verpflichtet, dieselben Knotenmechanismen oder -konfigurationen zu verwenden, um Dienstunterscheidung innerhalb ihrer Netzwerke zu ermöglichen, und sind frei, die Knotenparameter so zu konfigurieren, wie es für ihre Dienstangebote und Traffic-Engineering-Ziele angemessen ist“. Daher gibt die in diesem Dokument definierte Lösung Dienstanbietern Flexibilität bei der Auswahl, wie Diff-Serv-Dienstklassen innerhalb ihrer Domäne geroutet oder Traffic-Engineered werden (z. B. getrennte Dienstklassen über getrennte LSPs unterstützt und getrennt geroutet; alle Dienstklassen auf demselben LSP unterstützt und zusammen geroutet).

Weil MPLS pfadorientiert ist, kann es potenziell schnellere und vorhersagbarere Schutz- und Wiederherstellungsfähigkeiten bei Topologieänderungen bieten als herkömmliche hop-by-hop geroutete IP-Systeme. In diesem Dokument bezeichnen wir solche Fähigkeiten als „MPLS-Schutz“. Obwohl solche Fähigkeiten und zugehörigen Mechanismen außerhalb des Geltungsbereichs dieser Spezifikation liegen, stellen wir fest, dass sie verschiedenen LSPs unterschiedliche Schutzniveaus bieten können. Da die hier vorgestellte Lösung Dienstanbietern erlaubt zu wählen, wie Diff-Serv-Dienstklassen auf LSPs abgebildet werden, gibt die Lösung Dienstanbietern auch Flexibilität beim Schutzniveau, das verschiedenen Diff-Serv-Dienstklassen bereitgestellt wird (z. B. können einige Dienstklassen durch geschützte LSPs unterstützt werden, während andere Dienstklassen durch nicht geschützte LSPs unterstützt werden).

Darüber hinaus erreicht die in diesem Dokument spezifizierte Lösung Labelraum-Einsparung und verringert das Volumen der Label-Setup/Tear-down-Signalisierung, wo möglich, indem nur dann auf mehrere LSPs für eine gegebene Forwarding Equivalent Class (FEC) [MPLS_ARCH] zurückgegriffen wird, wenn dies nützlich oder erforderlich ist.

Diese Spezifikation erlaubt die Unterstützung von Differentiated Services sowohl für IPv4- als auch für IPv6-Verkehr, der über ein MPLS-Netzwerk transportiert wird. Dieses Dokument beschreibt nur den Betrieb für Unicast. Multicast-Unterstützung bleibt zukünftiger Untersuchung vorbehalten.

Die in diesem Dokument beschriebene Lösung schließt die signalisierte oder konfigurierte Verwendung der EXP-Bits zur Unterstützung von Explicit Congestion Notification [ECN] gleichzeitig mit Diff-Serv über MPLS nicht aus. Techniken zur Unterstützung von ECN in einer MPLS-Umgebung liegen jedoch außerhalb des Geltungsbereichs dieses Dokuments.

1.1. Terminologie​

Die Schlüsselwörter „MUST“, „MUST NOT“, „REQUIRED“, „SHALL“, „SHALL NOT“, „SHOULD“, „SHOULD NOT“, „RECOMMENDED“, „MAY“ und „OPTIONAL“ in diesem Dokument sind wie in RFC 2119 beschrieben zu interpretieren.

Vom Leser wird Vertrautheit mit der Terminologie von [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM], [MPLS_FR] vorausgesetzt, einschließlich der folgenden:

  • FEC: Forwarding Equivalency Class

  • FTN: FEC-To-NHLFE Map

  • ILM: Incoming Label Map

  • LC-ATM: Label Switching Controlled-ATM (interface)

  • LC-FR: Label Switching Controlled-Frame Relay (interface)

  • LSP: Label Switched Path

  • LSR: Label Switch Router

  • MPLS: Multi-Protocol Label Switching

  • NHLFE: Next Hop Label Forwarding Entry

Vom Leser wird Vertrautheit mit der Terminologie von [DIFF_ARCH], [DIFF_HEADER], [DIFF_AF], [DIFF_EF] vorausgesetzt, einschließlich der folgenden:

  • AF: Assured Forwarding

  • BA: Behavior Aggregate

  • CS: Class Selector

  • DF: Default Forwarding

  • DSCP: Differentiated Services Code Point

  • EF: Expedited Forwarding

  • PHB: Per Hop Behavior

Vom Leser wird Vertrautheit mit der Terminologie von [DIFF_NEW] vorausgesetzt, einschließlich der folgenden:

  • OA: Ordered Aggregate. Die Menge von Behavior Aggregates, die eine Ordnungsbeschränkung teilen.

  • PSC: PHB Scheduling Class. Die Menge von einem oder mehreren PHB(s), die auf die Behavior Aggregate(s) angewendet werden, die zu einem gegebenen OA gehören. Zum Beispiel ist AF1x eine PSC, die die PHBs AF11, AF12 und AF13 umfasst. EF ist ein Beispiel einer PSC, die ein einzelnes PHB umfasst, das EF-PHB.

Die folgenden Abkürzungen werden ebenfalls verwendet:

  • CLP: Cell Loss Priority

  • DE: Discard Eligibility

  • SNMP: Simple Network Management Protocol

Schließlich werden in dieser Spezifikation die folgenden Abkürzungen definiert:

  • E-LSP: EXP-Inferred-PSC LSP

  • L-LSP: Label-Only-Inferred-PSC LSP

1.2. EXP-Inferred-PSC LSPs (E-LSP)​

Ein einzelner LSP kann verwendet werden, um ein oder mehrere OAs zu unterstützen. Solche LSPs können bis zu acht BAs einer gegebenen FEC unterstützen, unabhängig davon, über wie viele OAs sich diese BAs erstrecken. Bei solchen LSPs wird das EXP-Feld des MPLS-Shim-Headers vom LSR verwendet, um das auf das Paket anzuwendende PHB zu bestimmen. Dies umfasst sowohl die PSC als auch die Drop Preference.

Wir bezeichnen solche LSPs als „EXP-inferred-PSC LSPs“ (E-LSP), da die PSC eines auf diesem LSP transportierten Pakets vom EXP-Feldwert für dieses Paket abhängt.

Die Abbildung vom EXP-Feld auf das PHB (d. h. auf PSC und Drop Precedence) für einen gegebenen solchen LSP wird entweder explizit beim Label-Setup signalisiert oder stützt sich auf eine vorkonfigurierte Abbildung.

Der detaillierte Betrieb von E-LSPs ist in Abschnitt 3 unten spezifiziert.

1.3. Label-Only-Inferred-PSC LSPs (L-LSP)​

Ein getrennter LSP kann für ein einzelnes <FEC, OA>-Paar eingerichtet werden. Bei solchen LSPs wird die PSC zum Zeitpunkt der Label-Einrichtung explizit signalisiert, sodass nach der Label-Einrichtung der LSR ausschließlich aus dem Labelwert die auf ein gelabeltes Paket anzuwendende PSC ableiten kann. Wenn der Shim-Header verwendet wird, wird die vom LSR auf das gelabelte Paket anzuwendende Drop Precedence innerhalb des MPLS-Shim-Headers des gelabelten Pakets unter Verwendung des EXP-Feldes übermittelt. Wenn der Shim-Header nicht verwendet wird (z. B. MPLS über ATM), wird die vom LSR auf das gelabelte Paket anzuwendende Drop Precedence innerhalb der Verbindungsschicht-Header-Einkapselung unter Verwendung verbindungsschichtspezifischer Drop-Precedence-Felder übermittelt (z. B. ATM CLP).

Wir bezeichnen solche LSPs als „Label-Only-Inferred-PSC LSPs“ (L-LSP), da die PSC vollständig aus dem Label abgeleitet werden kann, ohne weitere Informationen (z. B. unabhängig vom EXP-Feldwert). Der detaillierte Betrieb von L-LSPs ist in Abschnitt 4 unten spezifiziert.

1.4. Gesamtbetrieb​

Für eine gegebene FEC und sofern keine medienspezifischen Einschränkungen gelten, wie in den Abschnitten 7, 8 und 9 unten identifiziert, erlaubt diese Spezifikation innerhalb einer MPLS-Diff-Serv-Domäne eine der folgenden Kombinationen:

  • null oder eine beliebige Anzahl von E-LSPs, und

  • null oder eine beliebige Anzahl von L-LSPs.

Der Netzwerkadministrator wählt die tatsächliche Kombination von LSPs aus der Menge der erlaubten Kombinationen und wählt, wie die Behavior Aggregates tatsächlich über diese Kombination von LSPs transportiert werden, um seine/ihre Umgebung und Ziele hinsichtlich Diff-Serv-Unterstützung, Traffic Engineering und MPLS-Schutz bestmöglich zu erfüllen. Kriterien für die Auswahl einer solchen Kombination liegen außerhalb des Geltungsbereichs dieser Spezifikation.

Für eine gegebene FEC kann es mehr als einen LSP geben, der dasselbe OA trägt, beispielsweise zum Lastausgleich des OA; jedoch MUST alle Pakete eines gegebenen Mikroflusses, der möglicherweise mehrere BAs eines gegebenen Ordered Aggregate umspannt, über denselben LSP transportiert werden, um Ordnungsbeschränkungen einzuhalten. Umgekehrt MUST jeder LSP in der Lage sein, alle (aktiven) BAs eines gegebenen OA zu unterstützen.

Beispiele von Einsatzszenarien sind zur Information in ANHANG A bereitgestellt.

1.5. Beziehung zwischen Label und FEC​

  • [MPLS_ARCH] stellt in Abschnitt „2.1. Overview“ fest: „Einige Router analysieren den Netzschicht-Header eines Pakets nicht nur, um den nächsten Hop des Pakets zu wählen, sondern auch, um die ‚Precedence‘ oder ‚Class of Service‘ eines Pakets zu bestimmen. Sie können dann verschiedene Verwerfungsschwellen oder Scheduling-Disziplinen auf verschiedene Pakete anwenden. MPLS erlaubt (erfordert aber nicht), dass die Precedence oder Class of Service vollständig oder teilweise aus dem Label abgeleitet wird. In diesem Fall kann man sagen, dass das Label die Kombination aus einer FEC und einer Precedence oder Class of Service darstellt.“

In Übereinstimmung damit stellen wir fest:

  • Bei E-LSPs stellt das Label die Kombination aus einer FEC und der Menge der über den E-LSP transportierten BAs dar. Wo alle unterstützten BAs über einen E-LSP transportiert werden, stellt das Label dann die vollständige FEC dar.

  • Bei L-LSPs stellt das Label die Kombination aus einer FEC und einem OA dar.

1.6. Bandbreitenreservierung für E-LSPs und L-LSPs​

Unabhängig davon, welches Label-Binding-Protokoll verwendet wird, können E-LSPs und L-LSPs mit oder ohne Bandbreitenreservierung eingerichtet werden.

Die Einrichtung eines E-LSP oder L-LSP mit Bandbreitenreservierung bedeutet, dass Bandbreitenanforderungen für den LSP zur LSP-Einrichtungszeit signalisiert werden. Solche signalisierten Bandbreitenanforderungen können von LSRs zur Einrichtungszeit verwendet werden, um Zulassungskontrolle des signalisierten LSPs über die für die relevanten PSC(s) bereitgestellten Diff-Serv-Ressourcen durchzuführen (z. B. via Konfiguration, SNMP oder Policy-Protokolle). Solche signalisierten Bandbreitenanforderungen können von LSRs zur Einrichtungszeit auch verwendet werden, um Anpassungen der mit den relevanten PSC(s) verbundenen Diff-Serv-Ressourcen durchzuführen (z. B. Anpassung des PSC-Scheduling-Gewichts).

Man beachte, dass die Einrichtung eines E-LSP oder L-LSP mit Bandbreitenreservierung nicht bedeutet, dass pro-LSP-Scheduling erforderlich ist. Da E-LSPs und L-LSPs in diesem Dokument zur Unterstützung von Differentiated Services spezifiziert sind, wird die erforderliche Weiterleitungsbehandlung (Scheduling und Drop-Politik) durch das geeignete Diff-Serv-PHB definiert. Diese Weiterleitungsbehandlung MUST vom LSR mit der Granularität des BA angewendet werden und MUST mit der relevanten PHB-Spezifikation konform sein.

Wenn Bandbreitenanforderungen bei der Einrichtung eines L-LSP signalisiert werden, ist die signalisierte Bandbreite offensichtlich mit der PSC des L-LSPs verbunden. Daher können LSRs, die die signalisierte Bandbreite zur Zulassungskontrolle verwenden, Zulassungskontrolle über Diff-Serv-Ressourcen durchführen, die der PSC gewidmet sind (z. B. über die Bandbreite, die der PSC durch ihr Scheduling-Gewicht garantiert wird).

Wenn Bandbreitenanforderungen bei der Einrichtung eines E-LSP signalisiert werden, ist die signalisierte Bandbreite kollektiv mit dem gesamten LSP und daher mit der Menge der transportierten PSCs verbunden. Daher können LSRs, die die signalisierte Bandbreite zur Zulassungskontrolle verwenden, Zulassungskontrolle über globale Ressourcen durchführen, die von der Menge der PSCs geteilt werden (z. B. über die Gesamtbandbreite der Verbindung).

Beispiele von Szenarien, in denen Bandbreitenreservierung nicht verwendet wird, und Szenarien, in denen Bandbreitenreservierung verwendet wird, sind zur Information in ANHANG B bereitgestellt.