RFC 3270 - Unterstützung differenzierter Dienste durch MPLS

Network Working Group F. Le Faucheur, Editor Request for Comments: 3270 L. Wu Category: Standards Track B. Davie Cisco Systems S. Davari PMC-Sierra Inc. P. Vaananen Nokia R. Krishnan Axiowave Networks P. Cheval Alcatel J. Heinanen Song Networks May 2002

             Multi-Protocol Label Switching (MPLS)
        Unterstützung von Differentiated Services

Status dieses Memos

Dieses Dokument spezifiziert ein Internet-Standards-Track-Protokoll für die Internet-Community und fordert Diskussion und Vorschläge für Verbesserungen an. Bitte beziehen Sie sich auf die aktuelle Ausgabe der „Internet Official Protocol Standards“ (STD 1) für den Standardisierungsstand und den Status dieses Protokolls. Die Verteilung dieses Memos ist unbegrenzt.

Copyright-Hinweis

Zusammenfassung

Dieses Dokument definiert eine flexible Lösung zur Unterstützung von Differentiated Services (Diff-Serv) über Multi-Protocol Label Switching (MPLS)-Netzwerke.

Diese Lösung erlaubt dem MPLS-Netzwerkadministrator zu wählen, wie Diff-Serv Behavior Aggregates (BAs) auf Label Switched Paths (LSPs) abgebildet werden, sodass er/sie die Diff-Serv-, Traffic-Engineering- und Schutzziele innerhalb seines/ihres jeweiligen Netzwerks bestmöglich erfüllen kann. Beispielsweise erlaubt diese Lösung dem Netzwerkadministrator zu entscheiden, ob verschiedene Mengen von BAs auf denselben LSP oder auf getrennte LSPs abgebildet werden sollen.

Inhaltsverzeichnis

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 EXP-Inferred-PSC LSPs (E-LSP) . . . . . . . . . . . . . . . . . 6 1.3 Label-Only-Inferred-PSC LSPs (L-LSP). . . . . . . . . . . . . . 7 1.4 Gesamtbetrieb . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Beziehung zwischen Label und FEC. . . . . . . . . . . . . . . . 8 1.6 Bandbreitenreservierung für E-LSPs und L-LSPs . . . . . . . . . 8
Label-Weiterleitungsmodell für Diff-Serv-LSRs und Tunnelmodelle . 9 2.1 Label-Weiterleitungsmodell für Diff-Serv-LSRs . . . . . . . . . 9 2.2 Eingehende PHB-Bestimmung . . . . . . . . . . . . . . . . . . .10 2.3 Ausgehende PHB-Bestimmung mit optionaler Verkehrskonditionierung.11 2.4 Label-Weiterleitung . . . . . . . . . . . . . . . . . . . . . .11 2.5 Kodierung von Diff-Serv-Informationen in die Einkapselungsschicht.13 2.6 Diff-Serv-Tunnelmodelle über MPLS . . . . . . . . . . . . . . .13
Detaillierter Betrieb von E-LSPs. . . . . . . . . . . . . . . . .22 3.1 E-LSP-Definition. . . . . . . . . . . . . . . . . . . . . . . .22 3.2 Befüllen der Encaps-->PHB mapping' für einen eingehenden E-LSP .23 3.3 Eingehende PHB-Bestimmung auf eingehendem E-LSP. . . . . . . . .23 3.4 Befüllen der Set of PHB-->Encaps mappings' für einen ausgehenden E-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 3.5 Kodierung von Diff-Serv-Informationen in die Einkapselungsschicht auf ausgehendem E-LSP. . . . . . . . . . . . . . . . . . . . . .26 3.6 E-LSP-Zusammenführung . . . . . . . . . . . . . . . . . . . . .27
Detaillierter Betrieb von L-LSPs. . . . . . . . . . . . . . . .28 4.1 L-LSP-Definition. . . . . . . . . . . . . . . . . . . . . . . .28 4.2 Befüllen der Encaps-->PHB mapping' für einen eingehenden L-LSP .28 4.3 Eingehende PHB-Bestimmung auf eingehendem L-LSP. . . . . . . . .30 4.4 Befüllen der Set of PHB-->Encaps mappings' für einen ausgehenden L-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 4.5 Kodierung von Diff-Serv-Informationen in die Einkapselungsschicht auf ausgehendem L-LSP. . . . . . . . . . . . . . . . . . . . . .33 4.6 L-LSP-Zusammenführung . . . . . . . . . . . . . . . . . . . . .34
RSVP-Erweiterung zur Diff-Serv-Unterstützung . . . . . . . . . .34 5.1 Diff-Serv-bezogene RSVP-Nachrichtenformate. . . . . . . . . . .34 5.2 DIFFSERV-Objekt . . . . . . . . . . . . . . . . . . . . . . . .35 5.3 Behandlung des DIFFSERV-Objekts . . . . . . . . . . . . . . . .37 5.4 Nicht-Unterstützung des DIFFSERV-Objekts. . . . . . . . . . . .40 5.5 Fehlercodes für Diff-Serv . . . . . . . . . . . . . . . . . . .40 5.6 Intserv-Diensttyp . . . . . . . . . . . . . . . . . . . . . . .41
LDP-Erweiterungen zur Diff-Serv-Unterstützung. . . . . . . . . .41 6.1 Diff-Serv-TLV . . . . . . . . . . . . . . . . . . . . . . . . .42 6.2 Diff-Serv-Statuscodewerte . . . . . . . . . . . . . . . . . . .44 6.3 Diff-Serv-bezogene LDP-Nachrichten. . . . . . . . . . . . . . .44 6.4 Behandlung der Diff-Serv-TLV. . . . . . . . . . . . . . . . . .46 6.5 Nicht-Behandlung der Diff-Serv-TLV. . . . . . . . . . . . . . .49 6.6 Bandbreiteninformation. . . . . . . . . . . . . . . . . . . . .49
MPLS-Unterstützung von Diff-Serv über PPP-, LAN-, Non-LC-ATM- und Non-LC-FR-Schnittstellen . . . . . . . . . . . . . . . . . . . .49
MPLS-Unterstützung von Diff-Serv über LC-ATM-Schnittstellen. . .50 8.1 Verwendung von ATM-Verkehrsklassen und Traffic-Management- Mechanismen. . . . . . . . . . . . . . . . . . . . . . . . . . .50 8.2 LSR-Implementierung mit LC-ATM-Schnittstellen . . . . . . . . .50
MPLS-Unterstützung von Diff-Serv über LC-FR-Schnittstellen . . .51 9.1 Verwendung von Frame-Relay-Verkehrsparametern und Traffic- Management-Mechanismen. . . . . . . . . . . . . . . . . . . . .51 9.2 LSR-Implementierung mit LC-FR-Schnittstellen. . . . . . . . . .51
IANA-Erwägungen . . . . . . . . . . . . . . . . . . . . . . . .52
Sicherheitserwägungen . . . . . . . . . . . . . . . . . . . . .52
Danksagungen. . . . . . . . . . . . . . . . . . . . . . . . . .52 ANHANG A. Beispielhafte Einsatzszenarien. . . . . . . . . . . . . .53 ANHANG B. Beispielhafte Bandbreitenreservierungsszenarien . . . . .58 Literaturhinweise . . . . . . . . . . . . . . . . . . . . . . . . .60 Adressen der Autoren. . . . . . . . . . . . . . . . . . . . . . . .62 Vollständige Copyright-Erklärung. . . . . . . . . . . . . . . . . .64

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.

2. Label-Weiterleitungsmodell für Diff-Serv-LSRs und Tunnelmodelle

2.1 Label-Weiterleitungsmodell für Diff-Serv-LSRs

Da verschiedene Ordered Aggregates einer gegebenen FEC über verschiedene LSPs transportiert werden können, hängt die Label- Tausch-Entscheidung eines Diff-Serv-LSRs klar vom Behavior Aggregate des weitergeleiteten Pakets ab. Da außerdem das IP-DS-Feld eines weitergeleiteten Pakets für einen LSR möglicherweise nicht direkt sichtbar ist, unterscheidet sich die Art und Weise, das auf ein empfangenes Paket anzuwendende PHB zu bestimmen und das PHB in ein übertragendes Paket zu kodieren, von der eines nicht-MPLS-Diff-Serv- Routers.

Um daher die Label-Weiterleitung durch Diff-Serv-LSRs zu beschreiben, modellieren wir das Diff-Serv-Label-Switching-Verhalten des LSRs, bestehend aus vier Stufen:

Eingehende PHB-Bestimmung (A)
Ausgehende PHB-Bestimmung mit optionaler Verkehrskonditionierung (B)
Label-Weiterleitung (C)
Kodierung von Diff-Serv-Informationen in die Einkapselungsschicht (EXP, CLP, DE, User_Priority) (D)

Jede Stufe wird in den folgenden Abschnitten detaillierter beschrieben.

Offensichtlich MUST der LSR zur Durchsetzung der Diff-Serv- Dienstunterscheidung auch die dem ausgehenden PHB entsprechende Weiterleitungsbehandlung anwenden.

Dieses Modell ist unten veranschaulicht:

--Inc_label(s)()------------------------>I===I--Outg_label(s)(&)--> \ I I
---->I===I I C I -->I===I--Encaps-> I A I I===I--Outg_PHB->I===I I D I (&) -Encaps->I===I--Inc_PHB->I B I \ /->I===I () I===I --------+ ----Forwarding--> Treatment (PHB)

„Encaps“ bezeichnet die Diff-Serv-bezogenen Informationen, die in der MPLS-Einkapselungsschicht kodiert sind (z. B. EXP-Feld, ATM CLP, Frame Relay DE, 802.1 User_Priority)

(*) wenn der LSR als MPLS-Eingangsknoten agiert, kann das eingehende Paket ungelabelt empfangen werden.

(&) wenn der LSR als MPLS-Ausgangsknoten agiert, kann das ausgehende Paket ungelabelt übertragen werden.

Dieses Modell wird hier präsentiert, um die funktionalen Operationen von Diff-Serv-LSRs zu beschreiben, und schränkt die tatsächliche Implementierung nicht ein.

2.2 Eingehende PHB-Bestimmung

Diese Stufe bestimmt, zu welchem Behavior Aggregate das empfangene Paket gehört.

2.2.1 Eingehende PHB-Bestimmung unter Berücksichtigung eines Label-

  Stack-Eintrags

Die Abschnitte 3.3 und 4.3 liefern die Details, wie die eingehende PHB-Bestimmung unter Berücksichtigung eines gegebenen empfangenen Label-Stack-Eintrags und/oder empfangener eingehender MPLS- Einkapselungsinformationen in Abhängigkeit vom eingehenden LSP-Typ und von der eingehenden MPLS-Einkapselung durchzuführen ist.

Abschnitt 2.6 liefert die Details, welcher Label-Stack-Eintrag für die eingehende PHB-Bestimmung in Abhängigkeit vom unterstützten Diff-Serv- Tunnelmodus zu berücksichtigen ist.

2.2.2 Eingehende PHB-Bestimmung unter Berücksichtigung des IP-Headers

Abschnitt 2.6 liefert die Details, wann der IP-Header für die eingehende PHB-Bestimmung in Abhängigkeit vom unterstützten Diff- Serv-Tunnelmodell zu berücksichtigen ist. In den Fällen, in denen der IP-Header zu verwenden ist, arbeitet diese Stufe genau wie bei einem nicht-MPLS-IP-Diff-Serv-Router und verwendet das DS-Feld, um das eingehende PHB zu bestimmen.

2.3 Ausgehende PHB-Bestimmung mit optionaler Verkehrskonditionierung

Die Verkehrskonditionierungsstufe ist optional und kann auf einem LSR verwendet werden, um Verkehrskonditionierung einschließlich Behavior- Aggregate-Demotion oder -Promotion durchzuführen. Sie liegt außerhalb des Geltungsbereichs dieser Spezifikation. Zum Zweck der Spezifikation der Diff-Serv-über-MPLS-Weiterleitung stellen wir einfach fest, dass das PHB, das von einem LSR tatsächlich durchgesetzt und an nachgelagerte LSRs übermittelt werden soll (bezeichnet als „ausgehendes PHB“), sich von dem PHB unterscheiden kann, das dem Paket vom vorherigen LSR zugeordnet worden war (bezeichnet als „eingehendes PHB“).

Wenn die Verkehrskonditionierungsstufe nicht vorhanden ist, ist das „ausgehende PHB“ einfach identisch mit dem „eingehenden PHB“.

2.4 Label-Weiterleitung

[MPLS_ARCH] beschreibt, wie Label-Tausch von LSRs an eingehenden gelabelten Paketen unter Verwendung einer Incoming Label Map (ILM) durchgeführt wird, wobei jedes eingehende Label auf eine oder mehrere NHLFEs abgebildet wird. [MPLS_ARCH] beschreibt auch, wie Label-Imposition von LSRs an eingehenden ungelabelten Paketen unter Verwendung einer FEC-to-NHLFEs Map (FTN) durchgeführt wird, wobei jede eingehende FEC auf eine oder mehrere NHLFEs abgebildet wird.

Ein Diff-Serv-Kontext für ein Label umfasst:

`LSP type (i.e., E-LSP or L-LSP)'
`supported PHBs'
`Encaps-->PHB mapping' für ein eingehendes Label
`Set of PHB-->Encaps mappings' für ein ausgehendes Label

Die vorliegende Spezifikation definiert, dass ein Diff-Serv-Kontext in der ILM für jedes eingehende Label gespeichert wird.

[MPLS_ARCH] stellt fest, dass die `NHLFE may also contain any other information needed in order to properly dispose of the packet'. In Übereinstimmung damit definiert die vorliegende Spezifikation, dass ein Diff-Serv-Kontext in der NHLFE für jedes ausgehende Label gespeichert wird, das getauscht oder gepusht wird.

Diese Diff-Serv-Kontextinformationen werden zur Label- Einrichtungszeit in die ILM und die FTN eingetragen.

Wenn das Label einem E-LSP entspricht, für den beim LSP-Setup keine EXP<-->PHB mapping' explizit signalisiert wurde, wird supported PHBs' mit der Menge der PHBs der vorkonfigurierten `EXP<-->PHB mapping' befüllt, die unten in Abschnitt 3.2.1 erörtert wird.

Wenn das Label einem E-LSP entspricht, für den beim LSP-Setup eine EXP<-->PHB mapping' explizit signalisiert wurde, wird supported PHBs' mit der Menge der PHBs der signalisierten `EXP<-->PHB mapping' befüllt.

Wenn das Label einem L-LSP entspricht, wird `supported PHBs' mit der Menge der PHBs befüllt, die die PSC bilden, die beim LSP-Setup signalisiert wird.

Die Details, wie die Encaps-->PHB mapping' oder Set of PHB-->Encaps mappings' befüllt werden, sind unten in den Abschnitten 3 und 4 definiert.

[MPLS_ARCH] stellt auch fest:

„If the ILM [respectively, FTN] maps a particular label to a set of NHLFEs that contain more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the ILM [respectively, FTN] map a label [respectively, a FEC] to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths.“

In Übereinstimmung damit erlaubt die vorliegende Spezifikation, dass ein eingehendes Label [bzw. eine FEC] für Diff-Serv-Zwecke auf mehrere NHLFEs abgebildet werden kann (beispielsweise wo verschiedene NHLFEs Egress-Labels entsprechen, die verschiedene Mengen von PHBs unterstützen). Wenn ein Label [bzw. eine FEC] auf mehrere NHLFEs abbildet, MUST der Diff-Serv-LSR eine der NHLFEs wählen, deren Diff- Serv-Kontext anzeigt, dass sie das ausgehende PHB des weitergeleiteten Pakets unterstützt.

Wenn ein Label [bzw. eine FEC] auf mehrere NHLFEs abbildet, die das ausgehende PHB unterstützen, liegt das Verfahren zur Wahl einer davon außerhalb des Geltungsbereichs dieses Dokuments. Diese Situation kann angetroffen werden, wo es gewünscht ist, Lastausgleich eines Behavior Aggregate über mehrere LSPs durchzuführen. In solchen Situationen MUST alle Pakete eines gegebenen Mikroflusses über denselben LSP transportiert werden, um Ordnungsbeschränkungen einzuhalten.

2.5 Kodierung von Diff-Serv-Informationen in die Einkapselungsschicht

Diese Stufe bestimmt, wie die Felder zu kodieren sind, die Diff-Serv- Informationen im übertragenen Paket übermitteln (z. B. MPLS Shim EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority).

2.5.1 Kodierung von Diff-Serv-Informationen in den übertragenen Label-

  Eintrag

Die Abschnitte 3.5 und 4.5 liefern die Details, wie die Diff-Serv- Informationskodierung in einen gegebenen übertragenen Label-Stack- Eintrag und/oder übertragene MPLS-Einkapselungsinformationen in Abhängigkeit vom entsprechenden ausgehenden LSP-Typ und von der MPLS- Einkapselung durchzuführen ist.

Abschnitt 2.6 liefert die Details, in welchen Label-Stack-Eintrag die Diff-Serv-Informationskodierung in Abhängigkeit vom unterstützten Diff-Serv-Tunnelmodus durchzuführen ist.

2.5.2 Kodierung von Diff-Serv-Informationen in den übertragenen IP-

  Header

Um Diff-Serv-Informationskodierung in den IP-Header des übertragenen Pakets durchzuführen, arbeitet diese Stufe genau wie bei einem nicht- MPLS-IP-Diff-Serv-Router und kodiert den DSCP des ausgehenden PHB in das DS-Feld.

Abschnitt 2.6 liefert die Details, wann Diff-Serv- Informationskodierung in den übertragenen IP-Header in Abhängigkeit vom unterstützten Diff-Serv-Tunnelmodus durchzuführen ist.

2.6 Diff-Serv-Tunnelmodelle über MPLS

2.6.1 Diff-Serv-Tunnelmodelle

[DIFF_TUNNEL] betrachtet die Wechselwirkung von Differentiated Services mit IP-Tunneln verschiedener Formen. MPLS-LSPs sind keine Form von „IP-Tunneln“, da der MPLS-Einkapselungsheader keinen IP- Header enthält und daher MPLS-LSPs in [DIFF_TUNNEL] nicht betrachtet werden. Obwohl jedoch keine Form eines „IP-Tunnels“, sind MPLS-LSPs eine Form von „Tunnel“.

Aus Diff-Serv-Sicht teilen LSPs eine Reihe gemeinsamer Eigenschaften mit IP-Tunneln:

Zwischenknoten (d. h. Knoten irgendwo entlang der LSP-Spanne) sehen und operieren nur auf den „äußeren“ Diff-Serv-Informationen.
LSPs sind unidirektional.
Die „äußeren“ Diff-Serv-Informationen können an jedem der Zwischenknoten modifiziert werden.

Aus Diff-Serv-Sicht haben LSPs jedoch auch eine unterscheidende Eigenschaft im Vergleich zu IP-Tunneln:

Es gibt im Allgemeinen kein Verhalten analog zu Penultimate Hop Popping (PHP), das bei IP-Tunneln verwendet wird. Darüber hinaus führt PHP dazu, dass die mit dem LSP verbundenen „äußeren“ Diff- Serv-Informationen für den LSP-Egress nicht sichtbar sind. In Situationen, in denen diese Informationen am LSP-Egress nicht bedeutsam sind, ist dies offensichtlich überhaupt kein Problem. In Situationen, in denen diese Informationen am LSP-Egress bedeutsam sind, müssen sie irgendwie auf andere Weise getragen werden.

Die beiden konzeptionellen Modelle für Diff-Serv-Tunneling über IP- Tunnel, die in [DIFF_TUNNEL] definiert sind, sind auf Diff-Serv über MPLS anwendbar und nützlich, aber ihre jeweiligen detaillierten Operationen sind über MPLS etwas unterschiedlich. Diese beiden Modelle sind das Pipe-Modell und das Uniform-Modell. Ihre Operationen über MPLS sind in den folgenden Abschnitten spezifiziert. Diskussion und Definition alternativer Tunnelmodelle liegen außerhalb des Geltungsbereichs dieser Spezifikation.

2.6.2 Pipe-Modell

Mit dem Pipe-Modell werden MPLS-Tunnel (aka LSPs) verwendet, um die dazwischenliegenden MPLS-Knoten zwischen LSP-Ingress und -Egress aus Diff-Serv-Perspektive zu verbergen.

In diesem Modell müssen getunnelte Pakete zwei bedeutsame Teile von Diff-Serv-Informationen übermitteln:

die Diff-Serv-Informationen, die für Zwischenknoten entlang der LSP-Spanne einschließlich des LSP-Egress bedeutsam sind (die wir als die „LSP Diff-Serv Information“ bezeichnen). Diese LSP Diff- Serv Information ist jenseits des LSP-Egress nicht bedeutsam: Ob Verkehrskonditionierung an Zwischenknoten auf der LSP-Spanne die LSP Diff-Serv Information beeinflusst oder nicht, diese aktualisierten Diff-Serv-Informationen werden jenseits des LSP- Egress nicht als bedeutsam betrachtet und werden ignoriert.
die Diff-Serv-Informationen, die jenseits des LSP-Egress bedeutsam sind (die wir als die „Tunneled Diff-Serv Information“ bezeichnen). Diese Informationen sollen vom LSP-Ingress an den LSP-Egress übermittelt werden. Diese Diff-Serv-Informationen sind für die Zwischenknoten auf der LSP-Spanne nicht bedeutsam.

Der Betrieb des Pipe-Modells ohne PHP ist unten veranschaulicht:

        ========== LSP =============================>

            ---Swap--(M)--...--Swap--(M)--Swap----
           /        (outer header)                \
         (M)                                      (M)
         /                                          \

--(m)-Push.................(m).....................Pop--(m)--> I (inner header) E (M*)

(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" (*) The LSP Egress considers the LSP Diff-Serv information received in the outer header (i.e., before the pop) in order to apply its Diff-Serv forwarding treatment (i.e., actual PHB) I represents the LSP ingress node E represents the LSP egress node

Mit dem Pipe-Modell muss die „LSP Diff-Serv Information“ an den LSP- Egress übermittelt werden, sodass er seine Weiterleitungsbehandlung darauf basierend anwendet. Die „Tunneled Diff-Serv information“ muss ebenfalls an den LSP-Egress übermittelt werden, sodass sie weiter stromabwärts übermittelt werden kann.

Da beides erfordert, dass Diff-Serv-Informationen an den LSP-Egress übermittelt werden, arbeitet das Pipe-Modell nur ohne PHP.

Das Pipe-Modell ist besonders angemessen für Umgebungen, in denen:

die Cloud stromaufwärts der eingehenden Schnittstelle des LSP- Ingress und die Cloud stromabwärts der ausgehenden Schnittstelle des LSP-Egress in Diff-Serv-Domänen liegen, die eine gemeinsame Menge von Diff-Serv-Service-Provisioning-Politiken und PHB- Definitionen verwenden, während der LSP eine (oder mehrere) Diff- Serv-Domäne(n) überspannt, die eine andere Menge von Diff-Serv- Service-Provisioning-Politiken und PHB-Definitionen verwenden
die ausgehende Schnittstelle des LSP-Egress in der (letzten) Diff- Serv-Domäne liegt, die vom LSP überspannt wird.

Als Beispiel betrachte man den Fall, in dem ein Dienstanbieter einen MPLS-VPN-Dienst anbietet (siehe [MPLS_VPN] für ein Beispiel einer MPLS-VPN-Architektur) einschließlich Diff-Serv-Differenzierung. Man sage, dass eine Sammlung von Standorten über einen solchen MPLS-VPN- Dienst miteinander verbunden ist. Nun sage man, dass diese Sammlung von Standorten unter einer gemeinsamen Verwaltung verwaltet wird und ebenfalls Diff-Serv-Dienstunterscheidung unterstützt. Wenn die VPN- Standortverwaltung und der Dienstanbieter nicht genau dieselbe Diff- Serv-Politik teilen (beispielsweise nicht dieselbe Anzahl von PHBs unterstützen), dann würde der Betrieb von Diff-Serv im Pipe-Modell über den MPLS-VPN-Dienst erlauben, dass die Diff-Serv-Politik der VPN-Standorte konsistent durch den Ingress-VPN-Standort und den Egress-VPN-Standort und transparent über die Diff-Serv-Domäne des Dienstanbieters operiert. Es kann nützlich sein, solche LSPs so zu betrachten, als würden sie die Diff-Serv-Domänen an ihren Endpunkten zu einer einzelnen Diff-Serv-Region verbinden, indem sie diese Endpunkte virtuell angrenzend machen, obwohl sie physisch durch Zwischennetzwerkknoten getrennt sein können.

Das Pipe-Modell MUST unterstützt werden.

Zur Unterstützung des Pipe-Modells über einen gegebenen LSP ohne PHP führt ein LSR die eingehende PHB-Bestimmung und die Diff-Serv- Informationskodierung auf folgende Weise durch:

beim Empfang eines ungelabelten Pakets führt der LSR die eingehende PHB-Bestimmung unter Berücksichtigung des empfangenen IP-Headers durch.
beim Empfang eines gelabelten Pakets führt der LSR die eingehende PHB-Bestimmung unter Berücksichtigung des äußeren Label-Eintrags im empfangenen Label-Stack durch. Insbesondere wenn eine Pop- Operation für den betrachteten LSP durchzuführen ist, führt der LSR die eingehende PHB-Bestimmung VOR dem Pop durch.
beim Durchführen einer Push-Operation für den betrachteten LSP macht der LSR:

o kodiert Diff-Serv-Informationen, die dem AUSGEHENDEN PHB entsprechen, in den übertragenen Label-Eintrag, der dem gepushten Label entspricht.

o kodiert Diff-Serv-Informationen, die dem EINGEHENDEN PHB entsprechen, in den eingekapselten Header (getauschter Label- Eintrag oder IP-Header).
beim Durchführen einer reinen Swap-Operation für den betrachteten LSP kodiert der LSR Diff-Serv-Informationen in den übertragenen Label-Eintrag, der das getauschte Label enthält
beim Durchführen einer Pop-Operation für den betrachteten LSP führt der LSR keine Kodierung von Diff-Serv-Informationen in den durch die Pop-Operation freigelegten Header durch (d. h. der LSR lässt den freigelegten Header „as is“).

2.6.2.1 Short-Pipe-Modell

Das Short-Pipe-Modell ist eine optionale Variante des oben beschriebenen Pipe-Modells. Der einzige Unterschied ist, dass beim Short-Pipe-Modell die Diff-Serv-Weiterleitungsbehandlung am LSP- Egress basierend auf den „Tunneled Diff-Serv Information“ (d. h. Diff-Serv-Informationen, die im eingekapselten Header übermittelt werden) angewendet wird, anstatt auf den „LSP Diff-Serv information“ (d. h. Diff-Serv-Informationen, die im einkapselnden Header übermittelt werden).

Der Betrieb des Short-Pipe-Modells ohne PHP ist unten veranschaulicht:

        ========== LSP =============================>

            ---Swap--(M)--...--Swap--(M)--Swap----
           /        (outer header)                \
         (M)                                      (M)
         /                                          \

--(m)-Push.................(m).....................Pop--(m)--> I (inner header) E

(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" I represents the LSP ingress node E represents the LSP egress node

Da der LSP-Egress seine Weiterleitungsbehandlung basierend auf den „Tunneled Diff-Serv Information“ anwendet, müssen die „LSP Diff-Serv information“ vom vorletzten Knoten nicht an den LSP-Egress übermittelt werden. Daher kann das Short-Pipe-Modell auch mit PHP arbeiten.

Der Betrieb des Short-Pipe-Modells mit PHP ist unten veranschaulicht:

       =========== LSP ============================>

            ---Swap--(M)--...--Swap------
           /       (outer header)        \
         (M)                             (M)
         /                                 \

--(m)-Push.................(m).............Pop-(m)--E--(m)--> I (inner header) P (M*)

(M) represents the "LSP Diff-Serv information" (m) represents the "Tunneled Diff-Serv information" (*) The Penultimate LSR considers the LSP Diff-Serv information received in the outer header (i.e., before the pop) in order to apply its Diff-Serv forwarding treatment (i.e., actual PHB) I represents the LSP ingress node P represents the LSP penultimate node E represents the LSP egress node

Das Short-Pipe-Modell ist besonders angemessen für Umgebungen, in denen:

die Cloud stromaufwärts der eingehenden Schnittstelle des LSP- Ingress und die Cloud stromabwärts der ausgehenden Schnittstelle des LSP-Egress in Diff-Serv-Domänen liegen, die eine gemeinsame Menge von Diff-Serv-Service-Provisioning-Politiken und PHB- Definitionen verwenden, während der LSP eine (oder mehrere) Diff- Serv-Domäne(n) überspannt, die eine andere Menge von Diff-Serv- Service-Provisioning-Politiken und PHB-Definitionen verwenden
die ausgehende Schnittstelle des LSP-Egress in derselben Diff- Serv-Domäne liegt wie die Cloud stromabwärts davon.

Da jede ausgehende Schnittstelle des LSP-Egress in derselben Diff- Serv-Domäne liegt wie die Cloud stromabwärts davon, kann jede ausgehende Schnittstelle potenziell in einer anderen Diff-Serv-Domäne liegen, und der LSP-Egress muss mit Kenntnis jeder entsprechenden Diff-Serv-Politik konfiguriert werden. Dieser Betriebsaufwand ist in manchen Situationen gerechtfertigt, in denen die jeweiligen nachgelagerten Diff-Serv-Politiken besser geeignet sind, um Dienstunterscheidung über jede Egress-Schnittstelle anzubieten, als die gemeinsame Diff-Serv-Politik, die auf der LSP-Spanne verwendet wird. Ein Beispiel einer solchen Situation ist, wo ein Dienstanbieter einen MPLS-VPN-Dienst anbietet und wo einige VPN- Benutzer verlangen, dass ihre eigene VPN-Diff-Serv-Politik angewendet wird, um Dienstunterscheidung auf der dedizierten Verbindung vom LSP- Egress zum Ziel-VPN-Standort zu steuern, anstatt der Diff-Serv- Politik des Dienstanbieters.

Das Short-Pipe-Modell MAY unterstützt werden.

Zur Unterstützung des Short-Pipe-Modells über einen gegebenen LSP ohne PHP führt ein LSR die eingehende PHB-Bestimmung und die Diff- Serv-Informationskodierung auf dieselbe Weise wie beim Pipe-Modell durch, mit der folgenden Ausnahme:

beim Empfang eines gelabelten Pakets führt der LSR die eingehende PHB-Bestimmung unter Berücksichtigung des Headers (Label-Eintrag oder IP-Header) durch, der für die tatsächliche Weiterleitung verwendet wird. Insbesondere wenn eine Pop-Operation für den betrachteten LSP durchzuführen ist, führt der LSR die eingehende PHB-Bestimmung NACH dem Pop durch.

Zur Unterstützung des Short-Pipe-Modells über einen gegebenen LSP mit PHP führt ein LSR die eingehende PHB-Bestimmung und die Diff-Serv- Informationskodierung auf dieselbe Weise wie ohne PHP durch, mit den folgenden Ausnahmen:

der vorletzte LSR führt die eingehende PHB-Bestimmung unter Berücksichtigung des äußeren Label-Eintrags im empfangenen Label- Stack durch. Mit anderen Worten: Wenn eine Pop-Operation für den betrachteten LSP durchzuführen ist, führt der vorletzte LSR die eingehende PHB-Bestimmung VOR dem Pop durch.

Man beachte, dass das Verhalten des vorletzten LSRs im Short-Pipe- Modus mit PHP identisch mit dem Verhalten des LSP-Egress im Pipe- Modus ist (notwendigerweise ohne PHP).

2.6.3 Uniform-Modell

Mit dem Uniform-Modell werden MPLS-Tunnel (aka LSPs) aus Diff-Serv- Sicht als Artefakte des Ende-zu-Ende-Pfades betrachtet. MPLS-Tunnel können für Weiterleitungszwecke verwendet werden, haben aber keinen signifikanten Einfluss auf Diff-Serv. In diesem Modell enthält jedes Paket genau ein Stück Diff-Serv-Informationen, das bedeutsam ist und immer im äußersten Label-Eintrag kodiert ist (oder im IP-DSCP, wo das IP-Paket ungelabelt übertragen wird, beispielsweise am Egress des LSPs). Jegliche Diff-Serv-Informationen, die anderswo kodiert sind (z. B. in tieferen Label-Einträgen), sind für Zwischenknoten oder für den Tunnel-Egress ohne Bedeutung und werden ignoriert. Wenn Verkehrskonditionierung an Zwischenknoten auf der LSP-Spanne die „äußeren“ Diff-Serv-Informationen beeinflusst, sind die aktualisierten Diff-Serv-Informationen die, die am Egress des LSPs als bedeutsam betrachtet werden.

Der Betrieb des Uniform-Modells ohne PHP ist unten veranschaulicht:

         ========== LSP =============================>

             ---Swap--(M)--...-Swap--(M)--Swap----
            /         (outer header)              \
          (M)                                     (M)
          /                                         \

--(M)--Push...............(x).......................Pop--(M)-> I (inner header) E

(M) represents the Meaningful Diff-Serv information encoded in the corresponding header. (x) represents non-meaningful Diff-Serv information. I represents the LSP ingress node E represents the LSP egress node

Der Betrieb des Uniform-Modells mit PHP ist unten veranschaulicht:

         ========== LSP =========================>

             ---Swap-(M)-...-Swap------
            /        (outer header)    \
          (M)                          (M)
          /                              \

--(M)--Push..............(x)............Pop-(M)--E--(M)-> I (inner header) P

Das Uniform-Modell für Diff-Serv über MPLS ist so, dass aus Diff- Serv-Perspektive die Operationen genau identisch mit den Operationen sind, wenn MPLS nicht verwendet würde. Mit anderen Worten: MPLS ist für die Diff-Serv-Operationen völlig transparent.

Die Verwendung des Uniform-Modells erlaubt LSPs, Diff-Serv-Domänen- Grenzen zu überspannen, ohne dass andere Maßnahmen vorhanden sind als eine inter-domäne Verkehrskonditionierungsvereinbarung an der physischen Grenze zwischen den Diff-Serv-Domänen, die ausschließlich auf dem „äußeren“ Header operiert, da die bedeutsamen Diff-Serv- Informationen immer im äußersten Label-Eintrag sichtbar und modifizierbar sind.

Das Uniform-Modell MAY unterstützt werden.

Zur Unterstützung des Uniform-Modells über einen gegebenen LSP führt ein LSR die eingehende PHB-Bestimmung und die Diff-Serv- Informationskodierung auf folgende Weise durch:

beim Empfang eines ungelabelten Pakets führt der LSR die eingehende PHB-Bestimmung unter Berücksichtigung des empfangenen IP-Headers durch.
beim Empfang eines gelabelten Pakets führt der LSR die eingehende PHB-Bestimmung unter Berücksichtigung des äußeren Label-Eintrags im empfangenen Label-Stack durch. Insbesondere wenn eine Pop- Operation für den betrachteten LSP durchzuführen ist, führt der LSR die eingehende PHB-Bestimmung VOR dem Pop durch.
beim Durchführen einer Push-Operation für den betrachteten LSP kodiert der LSR Diff-Serv-Informationen in den übertragenen Label- Eintrag, der dem gepushten Label entspricht. Die Diff-Serv- Informationen, die im eingekapselten Header (getauschter Label- Eintrag oder IP-Header) kodiert sind, sind ohne Bedeutung.
beim Durchführen einer reinen Swap-Operation für den betrachteten LSP kodiert der LSR Diff-Serv-Informationen in den übertragenen Label-Eintrag, der das getauschte Label enthält.
wenn PHP verwendet wird, muss der vorletzte LSR Kenntnis der Set of PHB-->Encaps mappings' für das Label haben, das dem freigelegten Header entspricht (oder der PHB-->DSCP mapping'), um Diff-Serv- Informationskodierung durchzuführen. Methoden zur Bereitstellung dieser Abbildungskenntnis liegen außerhalb des Geltungsbereichs dieser Spezifikation. Als Beispiel kann die PHB-->DSCP mapping' lokal konfiguriert sein. Als weiteres Beispiel kann es in manchen Umgebungen angemessen sein, dass der vorletzte LSR annimmt, dass die Set of PHB-->Encaps mappings', die für das ausgehende Label im freigelegten Header zu verwenden sind, die `Set of PHB-->Encaps mappings' sind, die der LSR verwenden würde, wenn der LSR kein PHP durchführen würde. Man beachte auch, dass diese Spezifikation annimmt, dass der vorletzte LSR keinen Label-Tausch über den durch die Pop-Operation freigelegten Label-Eintrag durchführt (und tatsächlich nicht einmal auf das freigelegte Label schaut). Folglich können Einschränkungen für die Diff-Serv- Informationskodierung gelten, die vom vorletzten LSR durchgeführt werden kann. Beispielsweise erlaubt diese Spezifikation keine Situationen, in denen der vorletzte LSR ein Label poppt, das einem E-LSP entspricht, der zwei PSCs unterstützt, während der durch den Pop freigelegte Header Labelwerte für zwei L-LSPs enthält, die jeweils eine PSC unterstützen, da die Diff-Serv- Informationskodierung die Auswahl des einen oder des anderen Labels erfordern würde.

Man beachte, dass sich die LSR-Verhaltensweisen für das Pipe-, das Short-Pipe- und das Uniform-Modell nur beim Durchführen eines Push oder eines Pop unterscheiden. Daher verhalten sich Zwischen-LSRs, die nur Swap-Operationen für einen LSP durchführen, genau auf dieselbe Weise, unabhängig davon, ob sie im Pipe-, Short-Pipe- oder Uniform- Modell agieren. Bei einer Diff-Serv-Implementierung, die mehrere Tunnelmodelle unterstützt, müssen nur LSRs, die als LSP-Ingress, vorletzter LSR oder LSP-Egress agieren, konfiguriert werden, um in einem bestimmten Modell zu operieren. Signalisierung zur Assoziation eines Diff-Serv-Tunnelmodells auf pro-LSP-Basis liegt nicht im Geltungsbereich dieser Spezifikation.

2.6.4 Hierarchie

Durch den Label-Stack-Mechanismus erlaubt MPLS, dass LSP-Tunneling bis zu beliebiger Tiefe nestet. Wir beobachten, dass bei solchem Nesting der Push der Stufe N+1 auf einem nachfolgenden (oder demselben) LSR zum LSR stattfindet, der den Push für Stufe N durchführt, während der Pop der Stufe N+1 auf einem vorherigen (oder demselben) LSR zum LSR stattfindet, der den Pop der Stufe N durchführt. Für einen gegebenen LSP der Stufe N müssen der Ingress-LSR, der den Push durchführt, und der LSR, der den Pop durchführt (vorletzter LSR oder LSP-Egress), im selben Tunnelmodell operieren (d. h. Pipe, Short Pipe oder Uniform). Es gibt jedoch keine Anforderung für konsistente Tunnelmodelle über Stufen hinweg, sodass LSPs auf verschiedenen Stufen in verschiedenen Tunnelmodellen operieren können.

Hierarchische Operationen sind unten für den Fall von zwei Tunnel- Stufen veranschaulicht:

           +--------Swap--...---+
          /    (outmost header)  \
         /                        \
       Push(2).................(2)Pop
       / (outer header)             \
      /                              \

---Push(1)........................(1)Pop-->> (inner header)

(1) Tunneling Model 1 (2) Tunneling Model 2

Tunneling Model 2 may be the same as or may be different from Tunneling Model 1.

Für einen gegebenen LSP der Stufe N muss der LSR die eingehende PHB- Bestimmung und die Diff-Serv-Informationskodierung wie in den Abschnitten 2.6.2, 2.6.2.1 und 2.6.3 spezifiziert gemäß dem Tunnelmodell dieses LSPs der Stufe N und unabhängig vom Tunnelmodell anderer Stufen-LSPs durchführen.

3. Detaillierter Betrieb von E-LSPs

3.1 E-LSP-Definition

E-LSPs sind in Abschnitt 1.2 definiert.

Innerhalb einer gegebenen MPLS-Diff-Serv-Domäne sind alle E-LSPs, die sich auf die vorkonfigurierte Abbildung stützen, in der Lage, dieselbe gemeinsame Menge von 8 oder weniger BAs zu transportieren. Jeder dieser E-LSPs kann tatsächlich diese vollständige Menge von BAs oder eine beliebige Teilmenge davon transportieren.

Für eine gegebene FEC können zwei gegebene E-LSPs, die eine signalisierte `EXP<-->PHB mapping' verwenden, dieselbe oder verschiedene Mengen von Ordered Aggregates unterstützen.

3.2 Befüllen der `Encaps-->PHB mapping' für einen eingehenden E-LSP

Dieser Abschnitt definiert, wie die `Encaps-->PHB mapping' des Diff- Serv-Kontexts für einen eingehenden E-LSP befüllt wird, um die eingehende PHB-Bestimmung zu ermöglichen.

Die Encaps-->PHB mapping' für einen E-LSP hat immer die Form EXP-->PHB mapping'.

Wenn das Label einem E-LSP entspricht, für den beim LSP-Setup keine EXP<-->PHB mapping' explizit signalisiert wurde, wird die EXP-->PHB mapping' basierend auf der vorkonfigurierten `EXP<-->PHB mapping' befüllt, die unten in Abschnitt 3.2.1 erörtert wird.

Wenn das Label einem E-LSP entspricht, für den beim LSP-Setup eine EXP<-->PHB mapping' explizit signalisiert wurde, wird die EXP-->PHB mapping' gemäß der signalisierten `EXP<-->PHB mapping' befüllt.

3.2.1 Vorkonfigurierte `EXP<-->PHB mapping'

LSRs, die E-LSPs unterstützen, welche die vorkonfigurierte EXP<-->PHB mapping' verwenden, müssen die lokale Konfiguration dieser EXP<-->PHB mapping' erlauben. Diese Abbildung gilt für alle auf diesem LSR eingerichteten E-LSPs ohne beim Setup explizit signalisierte Abbildung.

Die vorkonfigurierte `EXP<-->PHB mapping' muss entweder an jedem E- LSP-Hop durch die vom LSP überspannte MPLS-Diff-Serv-Domäne konsistent sein, oder es muss eine geeignete Remarkierung des EXP-Feldes vom LSR durchgeführt werden, wann immer eine verschiedene vorkonfigurierte Abbildung auf den Ingress- und Egress-Schnittstellen verwendet wird.

Falls die vorkonfigurierte EXP<-->PHB mapping' vom Netzwerkadministrator tatsächlich nicht konfiguriert wurde, sollte der LSR eine standardmäßige vorkonfigurierte EXP<-->PHB mapping' verwenden, die alle EXP-Werte auf das Default-PHB abbildet.

3.3 Eingehende PHB-Bestimmung auf eingehendem E-LSP

Dieser Abschnitt definiert, wie die eingehende PHB-Bestimmung durchgeführt wird, wenn der betrachtete Label-Eintrag im empfangenen Label-Stack einem E-LSP entspricht. Dies erfordert, dass die `Encaps-->PHB mapping' wie in Abschnitt 3.2 definiert befüllt ist.

Bei der Berücksichtigung eines Label-Eintrags, der einem eingehenden E-LSP entspricht, für die eingehende PHB-Bestimmung:

bestimmt der LSR die EXP-->PHB mapping' durch Nachschlagen der Encaps-->PHB mapping' des Diff-Serv-Kontexts, der in der ILM mit dem betrachteten eingehenden E-LSP-Label assoziiert ist.
bestimmt der LSR das eingehende PHB durch Nachschlagen des EXP- Feldes des betrachteten Label-Eintrags in der `EXP-->PHB mapping'- Tabelle.

3.4 Befüllen der `Set of PHB-->Encaps mappings' für einen ausgehenden

E-LSP

Dieser Abschnitt definiert, wie die `Set of PHB-->Encaps mappings' des Diff-Serv-Kontexts beim Label-Setup für einen ausgehenden E-LSP befüllt wird, um die Kodierung von Diff-Serv-Informationen in die Einkapselungsschicht zu ermöglichen.

3.4.1 `PHB-->EXP mapping'

Ein ausgehender E-LSP muss immer eine PHB-->EXP mapping' als Teil der Set of PHB-->Encaps mappings' seines Diff-Serv-Kontexts haben.

Wenn das Label einem E-LSP entspricht, für den beim LSP-Setup keine EXP<-->PHB mapping' explizit signalisiert wurde, wird diese PHB-->EXP mapping' basierend auf der vorkonfigurierten `EXP<-->PHB mapping' befüllt, die oben in Abschnitt 3.2.1 erörtert wird.

Wenn das Label einem E-LSP entspricht, für den beim LSP-Setup eine EXP<-->PHB mapping' explizit signalisiert wurde, wird die PHB-->EXP mapping' gemäß der signalisierten `EXP<-->PHB mapping' befüllt.

3.4.2 `PHB-->CLP mapping'

Wenn der LSP über eine ATM-Schnittstelle austritt, die nicht label- switching-gesteuert ist, dann wird eine PHB-->CLP mapping' zur Set of PHB-->Encaps mappings' für diesen ausgehenden LSP hinzugefügt. Diese `PHB-->CLP mapping' wird auf folgende Weise befüllt:

sie ist eine Funktion der auf diesem LSP unterstützten PHBs und kann die relevanten Abbildungseinträge für diese PHBs aus der Default-`PHB-->CLP mapping' verwenden, die in Abschnitt 3.4.2.1 definiert ist. Andere Abbildungen als die in Abschnitt 3.4.2.1 definierte können verwendet werden. Insbesondere, wenn in Zukunft eine Abbildung von PHBs auf CLP für den Betrieb von Diff-Serv über ATM standardisiert wird, kann eine solche standardisierte Abbildung dann verwendet werden.

Wenn beispielsweise das ausgehende Label einem LSP entspricht, der die AF1-PSC unterstützt, dann kann die `PHB-->CLP mapping' befüllt werden mit:

     PHB                CLP Field

     AF11       ---->      0
     AF12       ---->      1
     AF13       ---->      1
     EF         ---->      0

Man beachte, dass in diesem Fall die Set of PHB-->Encaps mappings' sowohl eine PHB-->EXP mapping' als auch eine `PHB-->CLP mapping' enthält.

3.4.2.1 Default-`PHB-->CLP mapping'

     PHB                CLP Bit

     DF         ---->      0
     CSn        ---->      0
     AFn1       ---->      0
     AFn2       ---->      1
     AFn3       ---->      1
     EF         ---->      0

3.4.3 `PHB-->DE mapping'

Wenn der LSP über eine Frame-Relay-Schnittstelle austritt, die nicht label-switching-gesteuert ist, wird eine PHB-->DE mapping' zur Set of PHB-->Encaps mappings' für diesen ausgehenden LSP hinzugefügt und auf folgende Weise befüllt:

sie ist eine Funktion der auf diesem LSP unterstützten PHBs und kann die relevanten Abbildungseinträge für diese PHBs aus der Default-`PHB-->DE mapping' verwenden, die in Abschnitt 3.4.3.1 definiert ist. Andere Abbildungen als die in Abschnitt 3.4.3.1 definierte können verwendet werden. Insbesondere, wenn in Zukunft eine Abbildung von PHBs auf DE für den Betrieb von Diff-Serv über Frame Relay standardisiert wird, kann eine solche standardisierte Abbildung dann verwendet werden.

Man beachte, dass in diesem Fall die Set of PHB-->Encaps mappings' sowohl eine PHB-->EXP mapping' als auch eine `PHB-->DE mapping' enthält.

3.4.3.1 `Default PHB-->DE mapping'

     PHB                 DE Bit

      DF       ---->       0
      CSn      ---->       0
      AFn1     ---->       0
      AFn2     ---->       1
      AFn3     ---->       1
      EF       ---->       0

3.4.4 `PHB-->802.1 mapping'

Wenn der LSP über eine LAN-Schnittstelle austritt, auf der mehrere 802.1-Verkehrsklassen wie in [IEEE_802.1] unterstützt werden, dann wird eine PHB-->802.1 mapping' zur Set of PHB-->Encaps mappings' für diesen ausgehenden LSP hinzugefügt. Diese `PHB-->802.1 mapping' wird auf folgende Weise befüllt:

sie ist eine Funktion der auf diesem LSP unterstützten PHBs und verwendet die relevanten Abbildungseinträge für diese PHBs aus der vorkonfigurierten `PHB-->802.1 mapping', die in Abschnitt 3.4.4.1 definiert ist.

Man beachte, dass die Set of PHB-->Encaps mappings' dann sowohl eine PHB-->EXP mapping' als auch eine `PHB-->802.1 mapping' enthält.

3.4.4.1 Vorkonfigurierte `PHB-->802.1 Mapping'

Zum Zeitpunkt der Erstellung dieser Spezifikation gibt es keine standardisierte Abbildung von PHBs auf 802.1-Verkehrsklassen. Folglich muss ein LSR, der mehrere 802.1-Verkehrsklassen über LAN- Schnittstellen unterstützt, die lokale Konfiguration einer `PHB-->802.1 mapping' erlauben. Diese Abbildung gilt für alle ausgehenden LSPs, die vom LSR auf solchen LAN-Schnittstellen eingerichtet werden.

3.5 Kodierung von Diff-Serv-Informationen in die Einkapselungsschicht

auf ausgehendem E-LSP

Dieser Abschnitt definiert, wie Diff-Serv-Informationen in die MPLS- Einkapselungsschicht für einen gegebenen übertragenen Label-Eintrag zu kodieren sind, der einem ausgehenden E-LSP entspricht. Dies erfordert, dass die `Set of PHB-->Encaps mappings' wie in Abschnitt 3.4 definiert befüllt ist.

Der LSR bestimmt zuerst die `Set of PHB-->Encaps mappings' des Diff- Serv-Kontexts, der mit dem entsprechenden Label in der NHLFE assoziiert ist.

3.5.1 `PHB-->EXP mapping'

Wenn die Set of PHB-->Encaps mappings' eine Abbildung der Form PHB-->EXP mapping' enthält, dann:

bestimmt der LSR den Wert, der in das EXP-Feld des entsprechenden Level-Label-Eintrags zu schreiben ist, indem er das „ausgehende PHB“ in dieser `PHB-->EXP mapping'-Tabelle nachschlägt.

3.5.2 `PHB-->CLP mapping'

Wenn die Set of PHB-->Encaps mappings' eine Abbildung der Form PHB-->CLP mapping' enthält, dann:

bestimmt der LSR den Wert, der in das CLP-Feld des ATM- Einkapselungsheaders zu schreiben ist, indem er das „ausgehende PHB“ in dieser `PHB-->CLP mapping'-Tabelle nachschlägt.

3.5.3 `PHB-->DE mapping'

Wenn die Set of PHB-->Encaps mappings' eine Abbildung der Form PHB-->DE mapping' enthält, dann:

bestimmt der LSR den Wert, der in das DE-Feld des Frame-Relay- Einkapselungsheaders zu schreiben ist, indem er das „ausgehende PHB“ in dieser `PHB-->DE mapping'-Tabelle nachschlägt.

3.5.4 `PHB-->802.1 mapping'

Wenn die Set of PHB-->Encaps mappings' eine Abbildung der Form PHB-->802.1 mapping' enthält, dann:

bestimmt der LSR den Wert, der in das User_Priority-Feld der Tag Control Information des 802.1-Einkapselungsheaders [IEEE_802.1] zu schreiben ist, indem er das „ausgehende PHB“ in dieser 'PHB-->802.1 mapping'-Tabelle nachschlägt.

3.6 E-LSP-Zusammenführung

In einer MPLS-Domäne können zwei oder mehr LSPs an einem LSR zu einem LSP zusammengeführt werden. E-LSPs sind unter der folgenden Bedingung mit LSP-Merging kompatibel:

  E-LSPs können nur zu einem LSP zusammengeführt werden, wenn sie
  die exakt dieselbe Menge von BAs unterstützen.

Für E-LSPs, die eine signalisierte `EXP<-->PHB mapping' verwenden, MUST die obige Zusammenführungsbedingung von LSRs durch explizite Prüfung beim Label-Setup erzwungen werden, dass exakt dieselbe Menge von PHBs auf den zusammengeführten LSPs unterstützt wird.

Für E-LSPs, die die vorkonfigurierte EXP<-->PHB mapping' verwenden, kann sich ein LSR, da die über einen E-LSP unterstützten PHBs zur Einrichtungszeit nicht signalisiert werden, nicht auf Signalisierungsinformationen stützen, um die obige Zusammenführung zu erzwingen. Jedoch sind alle E-LSPs, die die vorkonfigurierte EXP<-->PHB mapping' verwenden, verpflichtet, innerhalb einer gegebenen MPLS-Diff-Serv-Domäne dieselbe Menge von Behavior Aggregates zu unterstützen. Daher ist das Zusammenführen von E-LSPs, die die vorkonfigurierte `EXP<-->PHB mapping' verwenden, innerhalb einer gegebenen MPLS-Diff-Serv-Domäne erlaubt.

4. Detaillierter Betrieb von L-LSPs

4.1 L-LSP-Definition

L-LSPs sind in Abschnitt 1.3 definiert.

4.2 Befüllen der `Encaps-->PHB mapping' für einen eingehenden L-LSP

Dieser Abschnitt definiert, wie die `Encaps-->PHB mapping' des Diff- Serv-Kontexts beim Label-Setup für einen eingehenden L-LSP befüllt wird, um die eingehende PHB-Bestimmung zu ermöglichen.

4.2.1 `EXP-->PHB mapping'

Wenn der LSR die MPLS-Shim-Schicht über diesem eingehenden L-LSP terminiert und der L-LSP auf einer Schnittstelle eintritt, die weder ATM noch Frame Relay ist, dann wird die `Encaps-->PHB mapping' auf folgende Weise befüllt:

sie ist tatsächlich eine `EXP-->PHB mapping'
diese Abbildung ist eine Funktion der PSC, die auf diesem LSP getragen wird, und muss die relevanten Abbildungseinträge für diese PSC aus der verpflichtenden `EXP/PSC-->PHB mapping' verwenden, die in Abschnitt 4.2.1.1 definiert ist.

Wenn beispielsweise das eingehende Label einem L-LSP entspricht, der die AF1-PSC unterstützt, dann wird die `Encaps-->PHB mapping' befüllt mit:

  EXP Field              PHB

      ---->    AF11
      ---->    AF12
      ---->    AF13

Ein LSR, der L-LSPs über PPP-Schnittstellen und LAN-Schnittstellen unterstützt, ist ein Beispiel eines LSRs, der die Shim-Schicht über Ingress-Schnittstellen terminiert, die weder ATM noch Frame Relay sind.

Wenn der LSR die MPLS-Shim-Schicht über diesem eingehenden L-LSP terminiert und der L-LSP auf einer ATM- oder Frame-Relay-Schnittstelle eintritt, dann wird die `Encaps-->PHB mapping' auf folgende Weise befüllt:

sie sollte tatsächlich eine EXP-->PHB mapping' sein. Alternative optionale Wege zum Befüllen der Encaps-->PHB mapping' könnten in Zukunft definiert werden (z. B. unter Verwendung einer 'CLP/EXP--> PHB mapping' oder einer 'DE/EXP-->PHB mapping'), liegen aber außerhalb des Geltungsbereichs dieses Dokuments.
wenn die Encaps-->PHB mapping' eine EXP-->PHB mapping' ist, ist diese EXP-->PHB mapping' eine Funktion der PSC, die auf dem L-LSP getragen wird, und muss die relevanten Abbildungseinträge für diese PSC aus der verpflichtenden EXP/PSC-->PHB mapping' verwenden, die in Abschnitt 4.2.1.1 definiert ist.

Ein Edge-LSR einer ATM-MPLS-Domäne oder einer FR-MPLS-Domäne ist ein Beispiel eines LSRs, der die Shim-Schicht über einer eingehenden ATM/FR-Schnittstelle terminiert.

4.2.1.1 Verpflichtende `EXP/PSC --> PHB mapping'

  EXP Field      PSC             PHB

        DF    ---->    DF
        CSn   ---->    CSn
        AFn   ---->    AFn1
        AFn   ---->    AFn2
        AFn   ---->    AFn3
        EF    ---->    EF

4.2.2 `CLP-->PHB mapping'

Wenn der LSR keine MPLS-Shim-Schicht über diesem eingehenden Label terminiert und ATM-Einkapselung verwendet (d. h. er ist ein ATM-LSR), dann wird die `Encaps-->PHB mapping' für diesen eingehenden L-LSP auf folgende Weise befüllt:

sie ist tatsächlich eine `CLP-->PHB mapping'
die Abbildung ist eine Funktion der PSC, die auf diesem LSP getragen wird, und sollte die relevanten Abbildungseinträge für diese PSC aus der Default-`CLP/PSC-->PHB mapping' verwenden, die in Abschnitt 4.2.2.1 definiert ist.

Wenn beispielsweise das eingehende Label einem L-LSP entspricht, der die AF1-PSC unterstützt, dann sollte die `Encaps-->PHB mapping' befüllt werden mit:

  CLP Field              PHB

    0          ---->    AF11
    1          ---->    AF12

4.2.2.1 Default-`CLP/PSC --> PHB mapping'

  CLP Bit      PSC             PHB

        DF    ---->    DF
        CSn   ---->    CSn
        AFn   ---->    AFn1
        AFn   ---->    AFn2
        EF    ---->    EF

4.2.3 `DE-->PHB mapping'

Wenn der LSR keine MPLS-Shim-Schicht über diesem eingehenden Label terminiert und Frame-Relay-Einkapselung verwendet (d. h. er ist ein FR-LSR), dann wird die `Encaps-->PHB mapping' für diesen eingehenden L-LSP auf folgende Weise befüllt:

sie ist tatsächlich eine `DE-->PHB mapping'
die Abbildung ist eine Funktion der PSC, die auf diesem LSP getragen wird, und sollte die relevanten Abbildungseinträge für diese PSC aus der Default-`DE/PSC-->PHB mapping' verwenden, die in Abschnitt 4.2.3.1 definiert ist.

4.2.3.1 Default-`DE/PSC --> PHB mapping'

  DE Bit      PSC             PHB

        DF    ---->    DF
        CSn   ---->    CSn
        AFn   ---->    AFn1
        AFn   ---->    AFn2
        EF    ---->    EF

4.3 Eingehende PHB-Bestimmung auf eingehendem L-LSP

Dieser Abschnitt definiert, wie die eingehende PHB-Bestimmung durchgeführt wird, wenn der betrachtete Label-Eintrag im empfangenen Label-Stack einem L-LSP entspricht. Dies erfordert, dass die `Encaps-->PHB mapping' wie in Abschnitt 4.2 definiert befüllt ist.

Bei der Berücksichtigung eines Label-Eintrags, der einem eingehenden L-LSP entspricht, für die eingehende PHB-Bestimmung bestimmt der LSR zuerst die mit dem entsprechenden Label assoziierte `Encaps-->PHB mapping'.

4.3.1 `EXP-->PHB mapping'

Wenn die Encaps-->PHB mapping' die Form EXP-->PHB mapping' hat, dann:

bestimmt der LSR das eingehende PHB durch Betrachten des EXP- Feldes des betrachteten Label-Eintrags und unter Verwendung der `EXP-->PHB mapping'.

4.3.2 `CLP-->PHB mapping'

Wenn die Encaps-->PHB mapping' die Form CLP-->PHB mapping' hat, dann:

bestimmt der LSR das eingehende PHB durch Betrachten des CLP- Feldes der ATM-Schicht-Einkapselung und unter Verwendung der `CLP-->PHB mapping'.

4.3.3 `DE-->PHB mapping'

Wenn die Encaps-->PHB mapping' die Form DE-->PHB mapping' hat, dann:

bestimmt der LSR das eingehende PHB durch Betrachten des DE-Feldes der Frame-Relay-Einkapselung und unter Verwendung der `DE-->PHB mapping'.

4.4 Befüllen der `Set of PHB-->Encaps mappings' für einen ausgehenden

L-LSP

Dieser Abschnitt definiert, wie die `Set of PHB-->Encaps mappings' des Diff-Serv-Kontexts beim Label-Setup für einen ausgehenden L-LSP befüllt wird, um die Kodierung von Diff-Serv-Informationen zu ermöglichen.

4.4.1 `PHB-->EXP mapping'

Wenn der LSR eine MPLS-Shim-Schicht über diesem ausgehenden L-LSP verwendet, dann wird eine PHB-->EXP mapping' zur Set of PHB-->Encaps mappings' für diesen ausgehenden L-LSP hinzugefügt. Diese `PHB-->EXP mapping' wird auf folgende Weise befüllt:

sie ist eine Funktion der auf diesem LSP unterstützten PSC und muss die für diese PSC relevanten Abbildungseinträge aus der verpflichtenden `PHB-->EXP mapping' verwenden, die in Abschnitt 4.4.1.1 definiert ist.

Wenn beispielsweise das ausgehende Label einem L-LSP entspricht, der die AF1-PSC unterstützt, dann wird die folgende PHB-->EXP mapping' in die Set of PHB-->Encaps mappings' hinzugefügt:

     PHB                EXP Field

     AF11       ---->      001
     AF12       ---->      010
     AF13       ---->      011

4.4.1.1 Verpflichtende `PHB-->EXP mapping'

     PHB                EXP Field

     DF         ---->      000
     CSn        ---->      000
     AFn1       ---->      001
     AFn2       ---->      010
     AFn3       ---->      011
     EF         ---->      000

4.4.2 `PHB-->CLP mapping'

Wenn der L-LSP auf einer ATM-Schnittstelle austritt (d. h. er ist ein ATM-LSR oder er ist ein frame-basierter LSR, der Pakete auf einer LC- ATM-Schnittstelle oder auf einer ATM-Schnittstelle sendet, die nicht label-switching-gesteuert ist), dann wird eine PHB-->CLP mapping' zur Set of PHB-->Encaps mappings' für diesen ausgehenden L-LSP hinzugefügt.

Wenn der L-LSP über eine ATM-Schnittstelle austritt, die nicht label- gesteuert ist, wird die `PHB-->CLP mapping' gemäß Abschnitt 3.4.2 befüllt.

Wenn der L-LSP über eine LC-ATM-Schnittstelle austritt, wird die `PHB-->CLP mapping' auf folgende Weise befüllt:

sie ist eine Funktion der auf diesem LSP unterstützten PSC und sollte die relevanten Abbildungseinträge für diese PSC aus der Default-`PHB-->CLP mapping' verwenden, die in Abschnitt 3.4.2.1 definiert ist.

Man beachte, dass wenn der LSR ein frame-basierter LSR ist, der einen über eine ATM-Schnittstelle austretenden L-LSP unterstützt, dann die Set of PHB-->Encaps mappings' sowohl eine PHB-->EXP mapping' als auch eine PHB-->CLP mapping' enthält. Wenn der LSR ein ATM-LSR ist, der einen L-LSP unterstützt, dann enthält die Set of PHB-->Encaps mappings' nur eine `PHB-->CLP mapping'.

4.4.3 `PHB-->DE mapping'

Wenn der L-LSP über eine Frame-Relay-Schnittstelle austritt (d. h. er ist ein LSR, der Pakete auf einer LC-FR-Schnittstelle oder auf einer Frame-Relay-Schnittstelle sendet, die nicht label-switching-gesteuert ist), wird eine PHB-->DE mapping' zur Set of PHB-->Encaps mappings' für diesen ausgehenden L-LSP hinzugefügt.

Wenn der L-LSP über eine FR-Schnittstelle austritt, die nicht label- switching-gesteuert ist, wird die `PHB-->DE mapping' gemäß Abschnitt 3.4.3 befüllt.

Wenn der L-LSP über eine LC-FR-Schnittstelle austritt, wird die `PHB-->DE mapping' auf folgende Weise befüllt:

sie ist eine Funktion der auf diesem LSP unterstützten PSC und sollte die relevanten Abbildungseinträge für diese PSC aus der Default-`PHB-->DE mapping' verwenden, die in Abschnitt 3.4.3.1 definiert ist.

Man beachte, dass wenn der LSR ein Edge-LSR ist, der einen über eine LC-FR-Schnittstelle austretenden L-LSP unterstützt, dann die Set of PHB-->Encaps mappings' sowohl eine PHB-->EXP mapping' als auch eine PHB-->DE mapping' enthält. Wenn der LSR ein FR-LSR ist, der einen L-LSP unterstützt, dann enthält die Set of PHB-->Encaps mappings' nur eine `PHB-->DE mapping'.

4.4.4 `PHB-->802.1 mapping'

Wenn der LSP über eine LAN-Schnittstelle austritt, auf der mehrere 802.1-Verkehrsklassen unterstützt werden, wie in [IEEE_802.1] definiert, dann wird eine `PHB-->802.1 mapping' gemäß Abschnitt 3.4.4 hinzugefügt.

4.5 Kodierung von Diff-Serv-Informationen in die Einkapselungsschicht

auf ausgehendem L-LSP

Dieser Abschnitt definiert, wie Diff-Serv-Informationen in die MPLS- Einkapselungsschicht für einen übertragenen Label-Eintrag zu kodieren sind, der einem ausgehenden L-LSP entspricht. Dies erfordert, dass die `Set of PHB-->Encaps mappings' wie in Abschnitt 4.4 definiert befüllt ist.

Der LSR bestimmt zuerst die `Set of PHB-->Encaps mappings' des Diff- Serv-Kontexts, der mit dem entsprechenden Label in der NHLFE assoziiert ist, und führt dann die entsprechende Kodierung wie in den Abschnitten 3.5.1, 3.5.2, 3.5.3 und 3.5.4 spezifiziert durch.

4.6 L-LSP-Zusammenführung

In einer MPLS-Domäne können zwei oder mehr LSPs an einem LSR zu einem LSP zusammengeführt werden. L-LSPs sind unter der folgenden Bedingung mit LSP-Merging kompatibel:

  L-LSPs können nur zu einem L-LSP zusammengeführt werden, wenn sie
  dieselbe PSC unterstützen.

Die obige Zusammenführungsbedingung MUST von LSRs durch explizite Prüfung beim Label-Setup erzwungen werden, dass dieselbe PSC auf den zusammengeführten LSPs unterstützt wird.

Man beachte, dass wenn L-LSPs zusammengeführt werden, die Bandbreite, die für die PSC stromabwärts des Zusammenführungspunkts verfügbar ist, ausreichen muss, um die Summe des zusammengeführten Verkehrs zu tragen. Dies ist besonders wichtig im Fall von EF-Verkehr. Dies kann auf mehrere Weisen sichergestellt werden (beispielsweise via Provisioning oder via Bandbreitensignalisierung und explizite Zulassungskontrolle).

5. RSVP-Erweiterung zur Diff-Serv-Unterstützung

Die MPLS-Architektur setzt kein einzelnes Label-Verteilungsprotokoll voraus. [RSVP_MPLS_TE] definiert die Erweiterung zu RSVP zur Einrichtung von LSPs in MPLS-Netzwerken. Dieser Abschnitt spezifiziert die Erweiterungen zu RSVP, über die in [RSVP_MPLS_TE] definierten hinaus, um LSPs einzurichten, die Differentiated Services in MPLS- Netzwerken unterstützen.

5.1 Diff-Serv-bezogene RSVP-Nachrichtenformate

In diesem Dokument wird ein neues RSVP-Objekt definiert: das DIFFSERV- Objekt. Eine detaillierte Beschreibung dieses Objekts wird unten bereitgestellt. Dieses neue Objekt ist auf Path-Nachrichten anwendbar. Diese Spezifikation definiert nur die Verwendung des DIFFSERV-Objekts in Path-Nachrichten, die verwendet werden, um LSP- Tunnel in Übereinstimmung mit [RSVP_MPLS_TE] einzurichten, und die somit ein Session-Objekt mit einem C-Type gleich LSP_TUNNEL_IPv4 und ein LABEL_REQUEST-Objekt enthalten.

In [RSVP_MPLS_TE] definierte Einschränkungen für die Unterstützung der Einrichtung von LSP-Tunneln via RSVP sind auch auf die Einrichtung von Diff-Serv unterstützenden LSP-Tunneln anwendbar: beispielsweise werden nur Unicast-LSPs unterstützt und Multicast-LSPs bleiben weiterer Untersuchung vorbehalten.

Dieses neue DIFFSERV-Objekt ist in Bezug auf RSVP optional, sodass allgemeine RSVP-Implementierungen, die sich nicht mit dem MPLS-LSP- Setup befassen, dieses Objekt nicht unterstützen müssen.

Das DIFFSERV-Objekt ist für die Unterstützung von LSP-Tunneln wie in [RSVP_MPLS_TE] definiert optional. Ein Diff-Serv-fähiger LSR, der E- LSPs mit der vorkonfigurierten EXP<-->PHB mapping' in Übereinstimmung mit dieser Spezifikation unterstützt, MAY das DIFFSERV-Objekt unterstützen. Ein Diff-Serv-fähiger LSR, der E-LSPs mit einer signalisierten EXP<-->PHB mapping' in Übereinstimmung mit dieser Spezifikation unterstützt, MUST das DIFFSERV-Objekt unterstützen. Ein Diff-Serv-fähiger LSR, der L-LSPs in Übereinstimmung mit dieser Spezifikation unterstützt, MUST das DIFFSERV-Objekt unterstützen.

5.1.1 Path-Nachrichtenformat

Das Format der Path-Nachricht ist wie folgt:

     <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
                              <SESSION> <RSVP_HOP>
                              <TIME_VALUES>
                              [ <EXPLICIT_ROUTE> ]
                              <LABEL_REQUEST>
                              [ <SESSION_ATTRIBUTE> ]
                              [ <DIFFSERV> ]
                              [ <POLICY_DATA> ... ]
                              [ <sender descriptor> ]

     <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                              [ <ADSPEC> ]
                              [ <RECORD_ROUTE> ]

5.2 DIFFSERV-Objekt

Die DIFFSERV-Objektformate sind unten gezeigt. Derzeit gibt es zwei mögliche C_Types. Typ 1 ist ein DIFFSERV-Objekt für einen E-LSP. Typ 2 ist ein DIFFSERV-Objekt für einen L-LSP.

5.2.1. DIFFSERV-Objekt für einen E-LSP:

class = 65, C_Type = 1

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Reserved                                       | MAPnb |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (1)                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  //                               ...                            //
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (MAPnb)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 28 bits
     Dieses Feld ist reserviert.  Es muss bei der Übertragung auf
     null gesetzt und beim Empfang ignoriert werden.

  MAPnb : 4 bits
     Zeigt die Anzahl der im DIFFSERV-Objekt enthaltenen MAP-
     Einträge an.  Dies kann auf jeden Wert von 0 bis 8 gesetzt
     werden.

  MAP : 32 bits
     Jeder MAP-Eintrag definiert die Abbildung zwischen einem EXP-
     Feldwert und einem PHB.  Der MAP-Eintrag hat das folgende
     Format:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Reserved     | EXP |             PHBID             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 13 bits
     Dieses Feld ist reserviert.  Es muss bei der Übertragung auf
     null gesetzt und beim Empfang ignoriert werden.

  EXP : 3 bits
     Dieses Feld enthält den Wert des EXP-Feldes für die in diesem
     MAP-Eintrag definierte `EXP<-->PHB mapping'.

  PHBID : 16 bits
     Dieses Feld enthält die PHBID des PHB für die in diesem MAP-
     Eintrag definierte `EXP<-->PHB mapping'.  Die PHBID wird wie
     in [PHBID] spezifiziert kodiert.

5.2.2 DIFFSERV-Objekt für einen L-LSP:

class = 65, C_Type = 2

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Reserved               |             PSC               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 16 bits
     Dieses Feld ist reserviert.  Es muss bei der Übertragung auf
     null gesetzt und beim Empfang ignoriert werden.

  PSC : 16 bits
     Die PSC zeigt eine PHB Scheduling Class an, die vom LSP
     unterstützt werden soll.  Die PSC wird wie in [PHBID]
     spezifiziert kodiert.

5.3 Behandlung des DIFFSERV-Objekts

Um einen LSP-Tunnel mit RSVP einzurichten, erstellt der Sender eine Path-Nachricht mit einem Session-Typ von LSP_Tunnel_IPv4 und mit einem LABEL_REQUEST-Objekt gemäß [RSVP_MPLS_TE].

Um einen E-LSP-Tunnel mit RSVP einzurichten, der die vorkonfigurierte `EXP<-->PHB mapping' verwendet, erstellt der Sender eine Path- Nachricht:

mit einem Session-Typ von LSP_Tunnel_IPv4,
mit dem LABEL_REQUEST-Objekt, und
ohne das DIFFSERV-Objekt.

Um einen E-LSP-Tunnel mit RSVP einzurichten, der die vorkonfigurierte `EXP<-->PHB mapping' verwendet, MAY der Sender alternativ eine Path- Nachricht erstellen:

mit einem Session-Typ von LSP_Tunnel_IPv4,
mit dem LABEL_REQUEST-Objekt, und
mit dem DIFFSERV-Objekt für einen E-LSP, das keine MAP-Einträge enthält.

Um einen E-LSP-Tunnel mit RSVP einzurichten, der eine signalisierte `EXP<-->PHB mapping' verwendet, erstellt der Sender eine Path- Nachricht:

mit einem Session-Typ von LSP_Tunnel_IPv4,
mit dem LABEL_REQUEST-Objekt,
mit dem DIFFSERV-Objekt für einen E-LSP, das einen MAP-Eintrag für jeden auf diesem E-LSP zu unterstützenden EXP-Wert enthält.

Um mit RSVP einen L-LSP-Tunnel einzurichten, erstellt der Sender eine Path-Nachricht:

mit einem Session-Typ von LSP_Tunnel_IPv4,
mit dem LABEL_REQUEST-Objekt,
mit dem DIFFSERV-Objekt für einen L-LSP, das die PHB Scheduling Class (PSC) enthält, die auf diesem L-LSP unterstützt wird.

Wenn eine Path-Nachricht mehrere DIFFSERV-Objekte enthält, ist nur das erste bedeutsam; nachfolgende DIFFSERV-Objekt(e) müssen ignoriert und nicht weitergeleitet werden.

Jeder LSR entlang des Pfades zeichnet das DIFFSERV-Objekt, wenn vorhanden, in seinem Path-State-Block auf.

Wenn in der Path-Nachricht kein DIFFSERV-Objekt vorhanden ist, SHOULD der LSR dies als Anforderung für einen E-LSP interpretieren, der die vorkonfigurierte `EXP<-->PHB mapping' verwendet. Aus Gründen der Rückwärtskompatibilität mit anderen nicht-Diff-Serv- Quality-of-Service-Optionen, die von [RSVP_MPLS_TE] erlaubt werden, wie Integrated Services Controlled Load oder Guaranteed Services, MAY der LSR jedoch eine konfigurierbare „Override-Option“ unterstützen. Wenn diese „Override-Option“ konfiguriert ist, interpretiert der LSR eine Path-Nachricht ohne Diff-Serv-Objekt als Anforderung für einen LSP mit solcher nicht-Diff-Serv Quality of Service.

Wenn ein DIFFSERV-Objekt für einen E-LSP, das keinen MAP-Eintrag enthält, in der Path-Nachricht vorhanden ist, MUST der LSR dies als Anforderung für einen E-LSP interpretieren, der die vorkonfigurierte EXP<-->PHB mapping' verwendet. Insbesondere erlaubt dies einem LSR mit konfigurierter „Override-Option“, E-LSPs mit vorkonfigurierter EXP<-->PHB mapping' gleichzeitig mit LSPs mit nicht-Diff-Serv Quality of Service zu unterstützen.

Wenn ein DIFFSERV-Objekt für einen E-LSP, das mindestens einen MAP- Eintrag enthält, in der Path-Nachricht vorhanden ist, MUST der LSR dies als Anforderung für einen E-LSP mit signalisierter `EXP<-->PHB mapping' interpretieren.

Wenn ein DIFFSERV-Objekt für einen L-LSP in der Path-Nachricht vorhanden ist, MUST der LSR dies als Anforderung für einen L-LSP interpretieren.

Der Ziel-LSR eines E-LSP oder L-LSP antwortet auf die Path-Nachricht, die das LABEL_REQUEST-Objekt enthält, indem er eine Resv-Nachricht sendet:

mit dem LABEL-Objekt
ohne ein DIFFSERV-Objekt.

Unter der Annahme, dass die Label-Anforderung akzeptiert und ein Label zugewiesen wird, müssen die Diff-Serv-LSRs (Sender, Ziel, Zwischenknoten):

den Diff-Serv-Kontext aktualisieren, der mit den eingerichteten LSPs in ihrer ILM/FTN assoziiert ist, wie in vorherigen Abschnitten spezifiziert (eingehendes und ausgehendes Label),
die erforderliche Diff-Serv-Weiterleitungsbehandlung (Scheduling- und Dropping-Verhalten) für diese NHLFE (ausgehendes Label) installieren.

Ein LSR, der das DIFFSERV-Objekt erkennt und der eine Path-Nachricht empfängt, die das DIFFSERV-Objekt enthält, aber kein LABEL_REQUEST- Objekt enthält oder die keinen Session-Typ von LSP_Tunnel_IPv4 hat, sendet ein PathErr zum Sender mit dem Fehlercode Diff-Serv Error' und einem Fehlerwert von Unexpected DIFFSERV object'. Diese sind unten in Abschnitt 5.5 definiert.

Ein LSR, der eine Path-Nachricht mit dem DIFFSERV-Objekt für E-LSP empfängt, der das DIFFSERV-Objekt erkennt, aber das besondere in einem oder mehreren der MAP-Einträge kodierte PHB nicht unterstützt, sendet ein PathErr zum Sender mit dem Fehlercode Diff-Serv Error' und einem Fehlerwert von Unsupported PHB'. Diese sind unten in Abschnitt 5.5 definiert.

Ein LSR, der eine Path-Nachricht mit dem DIFFSERV-Objekt für E-LSP empfängt, der das DIFFSERV-Objekt erkennt, aber bestimmt, dass die signalisierte EXP<-->PHB mapping' ungültig ist, sendet ein PathErr zum Sender mit dem Fehlercode Diff-Serv Error' und einem Fehlerwert von Invalid EXP<-->PHB mapping'. Diese sind unten in Abschnitt 5.5 definiert. Die im DIFFSERV-Objekt für einen E-LSP signalisierte EXP<-->PHB mapping' ist ungültig, wenn:

das MAPnb-Feld nicht im Bereich 0 bis 8 liegt, oder
ein gegebener EXP-Wert in mehr als einem MAP-Eintrag erscheint, oder
die PHBID-Kodierung ungültig ist.

Ein LSR, der eine Path-Nachricht mit dem DIFFSERV-Objekt für L-LSP empfängt, der das DIFFSERV-Objekt erkennt, aber die besondere im PSC- Feld kodierte PSC nicht unterstützt, sendet ein PathErr zum Sender mit dem Fehlercode Diff-Serv Error' und einem Fehlerwert von Unsupported PSC'. Diese sind unten in Abschnitt 5.5 definiert.

Ein LSR, der eine Path-Nachricht mit dem DIFFSERV-Objekt empfängt, der das DIFFSERV-Objekt erkennt, aber den erforderlichen pro-LSP- Diff-Serv-Kontext nicht zuweisen kann, sendet ein PathErr mit dem Fehlercode "Diff-Serv Error" und dem Fehlerwert "Per-LSP context allocation failure". Diese sind unten in Abschnitt 5.5 definiert.

Ein Diff-Serv-LSR MUST die Situationen behandeln, in denen die Label- Anforderung aus anderen als den in diesem Abschnitt bereits erörterten Gründen nicht akzeptiert werden kann, in Übereinstimmung mit [RSVP_MPLS_TE] (z. B. Reservierung durch Zulassungskontrolle abgelehnt, ein Label kann nicht assoziiert werden).

5.4 Nicht-Unterstützung des DIFFSERV-Objekts

Ein LSR, der die DIFFSERV-Objekt-Class-Num nicht erkennt, MUST sich in Übereinstimmung mit den in [RSVP] spezifizierten Verfahren für eine unbekannte Class-Num verhalten, deren Format 0bbbbbbb ist, d. h. er muss ein PathErr mit dem Fehlercode `Unknown object class' zum Sender senden.

Ein LSR, der die DIFFSERV-Objekt-Class-Num erkennt, aber den DIFFSERV- Objekt-C-Type nicht erkennt, muss sich in Übereinstimmung mit den in [RSVP] spezifizierten Verfahren für einen unbekannten C-Type verhalten, d. h. er muss ein PathErr mit dem Fehlercode `Unknown object C-Type' zum Sender senden.

In beiden Situationen führt dies dazu, dass der Pfad-Setup fehlschlägt. Der Sender sollte das Management benachrichtigen, dass ein L-LSP nicht eingerichtet werden kann, und sollte möglicherweise Maßnahmen ergreifen, um die LSP-Einrichtung ohne das DIFFSERV-Objekt erneut zu versuchen (z. B. Versuch, E-LSPs mit vorkonfigurierter `EXP<-->PHB mapping' als Fallback-Strategie zu verwenden).

5.5 Fehlercodes für Diff-Serv

In den oben beschriebenen Verfahren müssen bestimmte Fehler als Diff-Serv Error' gemeldet werden. Der Wert des Fehlercodes Diff-Serv Error' ist 27.

Das Folgende definiert Fehlerwerte für den Diff-Serv-Fehler:

  Value    Error

     Unexpected DIFFSERV object
     Unsupported PHB
     Invalid `EXP<-->PHB mapping'
     Unsupported PSC
     Per-LSP context allocation failure

5.6 Intserv-Diensttyp

Sowohl E-LSPs als auch L-LSPs können mit oder ohne Bandbreitenreservierung eingerichtet werden.

Wie in [RSVP_MPLS_TE] spezifiziert, wird zur Einrichtung eines E-LSP oder eines L-LSP mit Bandbreitenreservierung der Controlled-Load- Dienst von Int-Serv (oder möglicherweise Guaranteed Service) verwendet, und die Bandbreite wird im SENDER_TSPEC (bzw. FLOWSPEC) der Path- (bzw. Resv-)Nachricht signalisiert.

Wie in [RSVP_MPLS_TE] spezifiziert, wird zur Einrichtung eines E-LSP oder eines L-LSP ohne Bandbreitenreservierung der in [NULL] spezifizierte Null Service verwendet.

Man beachte, dass diese Spezifikation die Verwendung von E-LSPs und L-LSPs nur zur Unterstützung des Diff-Serv-Dienstes definiert. Unabhängig vom Intserv-Dienst (Controlled Load, Null Service, Guaranteed Service, ...) und unabhängig davon, ob die Reservierung mit oder ohne Bandbreitenreservierung erfolgt, sind E-LSPs und L-LSPs hier zur Unterstützung von Diff-Serv-Diensten definiert. Die Unterstützung von Int-Serv-Diensten über ein MPLS-Diff-Serv-Backbone liegt außerhalb des Geltungsbereichs dieser Spezifikation.

Man beachte auch, dass diese Spezifikation sich nicht mit dem in [DCLASS] definierten DCLASS-Objekt befasst, da dieses Objekt Informationen über DSCP-Werte übermittelt, die innerhalb des MPLS- Netzwerks nicht relevant sind.

6. LDP-Erweiterungen zur Diff-Serv-Unterstützung

Die MPLS-Architektur setzt kein einzelnes Label-Verteilungsprotokoll voraus. [LDP] definiert das Label Distribution Protocol und seine Verwendung zur Einrichtung von Label Switched Paths (LSPs) in MPLS- Netzwerken. Dieser Abschnitt spezifiziert die Erweiterungen zu LDP, um LSPs einzurichten, die Differentiated Services in MPLS-Netzwerken unterstützen.

In diesem Dokument wird ein neues LDP-TLV definiert:

das Diff-Serv-TLV

Eine detaillierte Beschreibung dieses TLV wird unten bereitgestellt.

Das neue Diff-Serv-TLV ist in Bezug auf LDP optional. Ein Diff-Serv- fähiger LSR, der E-LSPs unterstützt, die die vorkonfigurierte EXP<-->PHB mapping' in Übereinstimmung mit dieser Spezifikation verwenden, MAY das Diff-Serv-TLV unterstützen. Ein Diff-Serv- fähiger LSR, der E-LSPs unterstützt, die die signalisierte EXP<-->PHB mapping' in Übereinstimmung mit dieser Spezifikation verwenden, MUST das Diff-Serv-TLV unterstützen. Ein Diff-Serv- fähiger LSR, der L-LSPs in Übereinstimmung mit dieser Spezifikation unterstützt, MUST das Diff-Serv-TLV unterstützen.

6.1 Diff-Serv-TLV

Das Diff-Serv-TLV hat die folgenden Formate:

Diff-Serv TLV for an E-LSP:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |U|F|  Diff-Serv (0x0901)       |      Length                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |T|        Reserved                                     | MAPnb |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (1)                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (MAPnb)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  T:1 bit
     LSP Type.  Dies ist auf 0 für einen E-LSP gesetzt

  Reserved : 27 bits
     Dieses Feld ist reserviert.  Es muss bei der Übertragung auf
     null gesetzt und beim Empfang ignoriert werden.

  MAPnb : 4 bits
     Zeigt die Anzahl der im DIFFSERV-Objekt enthaltenen MAP-
     Einträge an.  Dies kann auf jeden Wert von 1 bis 8 gesetzt
     werden.








  MAP : 32 bits
     Jeder MAP-Eintrag definiert die Abbildung zwischen einem EXP-
     Feldwert und einem PHB.  Der MAP-Eintrag hat das folgende
     Format:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Reserved     | EXP |             PHBID             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 13 bits
     Dieses Feld ist reserviert.  Es muss bei der Übertragung auf
     null gesetzt und beim Empfang ignoriert werden.

  EXP : 3 bits
     Dieses Feld enthält den Wert des EXP-Feldes für die in diesem
     MAP-Eintrag definierte `EXP<-->PHB mapping'.

  PHBID : 16 bits
     Dieses Feld enthält die PHBID des PHB für die in diesem MAP-
     Eintrag definierte `EXP<-->PHB mapping'.  Die PHBID wird wie
     in [PHBID] spezifiziert kodiert.

Diff-Serv TLV for an L-LSP:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |U|F| Type = PSC (0x0901)       |      Length                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |T|        Reserved             |              PSC              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  T:1 bit
     LSP Type.  Dies ist auf 1 für einen L-LSP gesetzt

  Reserved : 15 bits
     Dieses Feld ist reserviert.  Es muss bei der Übertragung auf
     null gesetzt und beim Empfang ignoriert werden.

  PSC : 16 bits
     Die PSC zeigt eine PHB Scheduling Class an, die vom LSP
     unterstützt werden soll.  Die PSC wird wie in [PHBID]
     spezifiziert kodiert.

6.2 Diff-Serv-Statuscodewerte

Die folgenden Werte sind für das Status-Code-Feld des Status-TLV definiert:

     Status Code                             E   Status Data

     Unexpected Diff-Serv TLV                0   0x01000001
     Unsupported PHB                         0   0x01000002
     Invalid `EXP<-->PHB mapping'            0   0x01000003
     Unsupported PSC                         0   0x01000004
     Per-LSP context allocation failure      0   0x01000005

6.3 Diff-Serv-bezogene LDP-Nachrichten

6.3.1 Label Request Message

Das Format der Label-Request-Nachricht wird wie folgt erweitert, um optional das Diff-Serv-TLV einzuschließen:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.2 Label Mapping Message

Das Format der Label-Mapping-Nachricht wird wie folgt erweitert, um optional das Diff-Serv-TLV einzuschließen:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.3 Label Release Message

Das Format der Label-Release-Nachricht wird wie folgt erweitert, um optional das Status-TLV einzuschließen:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|   Label Release (0x0403)   |      Message Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Message ID                                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     FEC TLV                                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Label TLV (optional)                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Status TLV (optional)                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.4 Notification Message

Das Format der Notification-Nachricht wird wie folgt erweitert, um optional das Diff-Serv-TLV einzuschließen:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.4 Behandlung der Diff-Serv-TLV

6.4.1 Behandlung der Diff-Serv-TLV im Downstream-Unsolicited-Modus

Dieser Abschnitt beschreibt Operationen, wenn der Downstream- Unsolicited-Modus verwendet wird.

Bei der Zuweisung eines Labels für einen E-LSP, der die vorkonfigurierte `EXP<-->PHB mapping' verwenden soll, gibt ein nachgelagerter Diff-Serv-LSR eine Label-Mapping-Nachricht ohne das Diff-Serv-TLV aus.

Bei der Zuweisung eines Labels für einen E-LSP, der eine signalisierte `EXP<-->PHB mapping' verwenden soll, gibt ein nachgelagerter Diff-Serv-LSR eine Label-Mapping-Nachricht mit dem Diff-Serv-TLV für einen E-LSP aus, das einen MAP-Eintrag für jeden auf diesem E-LSP zu unterstützenden EXP-Wert enthält.

Bei der Zuweisung eines Labels für einen L-LSP gibt ein nachgelagerter Diff-Serv-LSR eine Label-Mapping-Nachricht mit dem Diff-Serv-TLV für einen L-LSP aus, das die PHB Scheduling Class (PSC) enthält, die auf diesem L-LSP unterstützt werden soll.

Unter der Annahme, dass der Label-Setup erfolgreich ist, müssen die nachgelagerten und vorgelagerten LSRs:

den Diff-Serv-Kontext aktualisieren, der mit den eingerichteten LSPs in ihrer ILM/FTN assoziiert ist, wie in vorherigen Abschnitten spezifiziert (eingehendes und ausgehendes Label),
die erforderliche Diff-Serv-Weiterleitungsbehandlung (Scheduling- und Dropping-Verhalten) für diese NHLFE (ausgehendes Label) installieren.

Ein vorgelagerter Diff-Serv-LSR, der eine Label-Mapping-Nachricht mit mehreren Diff-Serv-TLVs empfängt, betrachtet nur das erste als bedeutsam. Der LSR muss die nachfolgenden Diff-Serv-TLV(s) ignorieren und nicht weiterleiten.

Ein vorgelagerter Diff-Serv-LSR, der eine Label-Mapping-Nachricht mit dem Diff-Serv-TLV für einen E-LSP empfängt und das besondere in einem oder mehreren der MAP-Einträge kodierte PHB nicht unterstützt, muss die Abbildung ablehnen, indem er eine Label-Release-Nachricht sendet, die das Label-TLV und das Status-TLV mit einem Status Code von `Unsupported PHB' enthält.

Ein vorgelagerter Diff-Serv-LSR, der eine Label-Mapping-Nachricht mit dem Diff-Serv-TLV für einen E-LSP empfängt und bestimmt, dass die signalisierte EXP<-->PHB mapping' ungültig ist, muss die Abbildung ablehnen, indem er eine Label-Release-Nachricht sendet, die das Label-TLV und das Status-TLV mit einem Status Code von Invalid EXP<-->PHB mapping' enthält. Die im DIFFSERV-Objekt für einen E- LSP signalisierte `EXP<-->PHB mapping' ist ungültig, wenn:

das MAPnb-Feld nicht im Bereich 1 bis 8 liegt, oder
ein gegebener EXP-Wert in mehr als einem MAP-Eintrag erscheint, oder
die PHBID-Kodierung ungültig ist

Ein vorgelagerter Diff-Serv-LSR, der eine Label-Mapping-Nachricht mit dem Diff-Serv-TLV für einen L-LSP empfängt, die einen nicht unterstützten PSC-Wert enthält, muss die Abbildung ablehnen, indem er eine Label-Release-Nachricht sendet, die das Label-TLV und das Status-TLV mit einem Status Code von `Unsupported PSC' enthält.

6.4.2 Behandlung der Diff-Serv-TLV im Downstream-on-Demand-Modus

Dieser Abschnitt beschreibt Operationen, wenn der Downstream-on- Demand-Modus verwendet wird.

Bei der Anforderung eines Labels für einen E-LSP, der die vorkonfigurierte `EXP<-->PHB mapping' verwenden soll, sendet ein vorgelagerter Diff-Serv-LSR eine Label-Request-Nachricht ohne das Diff-Serv-TLV.

Bei der Anforderung eines Labels für einen E-LSP, der eine signalisierte `EXP<-->PHB mapping' verwenden soll, sendet ein vorgelagerter Diff-Serv-LSR eine Label-Request-Nachricht mit dem Diff-Serv-TLV für einen E-LSP, das einen MAP-Eintrag für jeden auf diesem E-LSP zu unterstützenden EXP-Wert enthält.

Bei der Anforderung eines Labels für einen L-LSP sendet ein vorgelagerter Diff-Serv-LSR eine Label-Request-Nachricht mit dem Diff-Serv-TLV für einen L-LSP, das die auf diesem L-LSP zu unterstützende PSC enthält.

Ein nachgelagerter Diff-Serv-LSR, der eine Label-Mapping-Nachricht als Antwort auf eine Label-Request-Nachricht für einen E-LSP oder einen L-LSP sendet, darf kein Diff-Serv-TLV in dieser Label-Mapping- Nachricht einschließen. Unter der Annahme, dass der Label-Setup erfolgreich ist, müssen die nachgelagerten und vorgelagerten LSRs:

den Diff-Serv-Kontext aktualisieren, der mit den eingerichteten LSPs in ihrer ILM/FTN assoziiert ist, wie in vorherigen Abschnitten spezifiziert (eingehendes und ausgehendes Label),
die erforderliche Diff-Serv-Weiterleitungsbehandlung (Scheduling- und Dropping-Verhalten) für diese NHLFE (ausgehendes Label) installieren.

Ein vorgelagerter Diff-Serv-LSR, der eine Label-Mapping-Nachricht empfängt, die ein Diff-Serv-TLV als Antwort auf seine Label-Request- Nachricht enthält, muss die Label-Abbildung ablehnen, indem er eine Label-Release-Nachricht sendet, die das Label-TLV und das Status-TLV mit einem Status Code von `Unexpected Diff-Serv TLV' enthält.

Ein nachgelagerter Diff-Serv-LSR, der eine Label-Request-Nachricht mit mehreren Diff-Serv-TLVs empfängt, betrachtet nur das erste als bedeutsam. Der LSR muss die nachfolgenden Diff-Serv-TLV(s) ignorieren und nicht weiterleiten.

Ein nachgelagerter Diff-Serv-LSR, der eine Label-Request-Nachricht mit dem Diff-Serv-TLV für einen E-LSP empfängt und das besondere in einem (oder mehreren) der MAP-Einträge kodierte PHB nicht unterstützt, muss die Anforderung ablehnen, indem er eine Notification-Nachricht sendet, die das Status-TLV mit einem Status Code von `Unsupported PHB' enthält.

Ein nachgelagerter Diff-Serv-LSR, der eine Label-Request-Nachricht mit dem Diff-Serv-TLV für einen E-LSP empfängt und bestimmt, dass die signalisierte EXP<-->PHB mapping' ungültig ist, muss die Anforderung ablehnen, indem er eine Notification-Nachricht sendet, die das Status-TLV mit einem Status Code von Invalid EXP<-->PHB mapping' enthält. Die im DIFFSERV-TLV für einen E-LSP signalisierte `EXP<-->PHB mapping' ist ungültig, wenn:

das MAPnb-Feld nicht im Bereich 1 bis 8 liegt, oder
ein gegebener EXP-Wert in mehr als einem MAP-Eintrag erscheint, oder
die PHBID-Kodierung ungültig ist

Ein nachgelagerter Diff-Serv-LSR, der eine Label-Request-Nachricht mit dem Diff-Serv-TLV für einen L-LSP empfängt, die einen nicht unterstützten PSC-Wert enthält, muss die Anforderung ablehnen, indem er eine Notification-Nachricht sendet, die das Status-TLV mit einem Status Code von `Unsupported PSC' enthält.

Ein nachgelagerter Diff-Serv-LSR, der den Diff-Serv-TLV-Typ in einer Label-Request-Nachricht erkennt, aber die erforderlichen pro-LSP- Kontextinformationen nicht zuweisen kann, muss die Anforderung ablehnen und eine Notification-Nachricht senden, die das Status-TLV mit einem Status Code von `Per-LSP context allocation failure' enthält.

Ein nachgelagerter Diff-Serv-LSR, der den Diff-Serv-TLV-Typ in einer Label-Request-Nachricht erkennt und die angeforderte PSC unterstützt, aber die Label-Anforderung aus anderen Gründen nicht erfüllen kann (z. B. kein Label verfügbar), muss eine Notification-Nachricht in Übereinstimmung mit bestehenden LDP-Verfahren [LDP] senden (z. B. mit einem `No Label Resource' Status Code). Diese Notification-Nachricht muss das angeforderte Diff-Serv-TLV einschließen.

6.5 Nicht-Behandlung der Diff-Serv-TLV

Ein LSR, der den Diff-Serv-TLV-Typ nicht erkennt, muss sich beim Empfang einer Label-Request-Nachricht oder einer Label-Mapping- Nachricht, die das Diff-Serv-TLV enthält, in Übereinstimmung mit den in [LDP] spezifizierten Verfahren für ein unbekanntes TLV verhalten, dessen U-Bit und F-Bit auf 0 gesetzt sind, d. h. er muss die Nachricht ignorieren und eine Notification-Nachricht mit `Unknown TLV' Status zurückgeben.

6.6 Bandbreiteninformation

Bandbreiteninformationen können auch zur Einrichtungszeit von E-LSP und L-LSP signalisiert werden, beispielsweise zum Zweck des Traffic Engineering, unter Verwendung des Traffic Parameters TLV wie in [MPLS CR LDP] beschrieben.

7. MPLS-Unterstützung von Diff-Serv über PPP-, LAN-, Non-LC-ATM- und

Non-LC-FR-Schnittstellen

Die allgemeinen Operationen für die MPLS-Unterstützung von Diff-Serv, einschließlich Label-Weiterleitung und LSP-Setup-Operationen, sind in den vorherigen Abschnitten spezifiziert. Dieser Abschnitt beschreibt die spezifischen Operationen, die für die MPLS- Unterstützung von Diff-Serv über PPP-Schnittstellen, LAN- Schnittstellen, ATM-Schnittstellen, die nicht label-gesteuert sind, und Frame-Relay-Schnittstellen, die nicht label-gesteuert sind, erforderlich sind.

Auf diesen Schnittstellen erlaubt diese Spezifikation eine der folgenden LSP-Kombinationen pro FEC:

Null oder eine beliebige Anzahl von E-LSP, und
Null oder eine beliebige Anzahl von L-LSPs.

Ein Diff-Serv-fähiger LSR MUST E-LSPs unterstützen, die die vorkonfigurierte `EXP<-->PHB mapping' über diese Schnittstellen verwenden.

Ein Diff-Serv-fähiger LSR MAY E-LSPs unterstützen, die die signalisierte `EXP<-->PHB mapping' und L-LSPs über diese Schnittstellen verwenden.

8. MPLS-Unterstützung von Diff-Serv über LC-ATM-Schnittstellen

Dieser Abschnitt beschreibt die spezifischen Operationen, die für die MPLS-Unterstützung von Diff-Serv über label-switching-gesteuerte ATM- (LC-ATM)-Schnittstellen erforderlich sind.

Dieses Dokument erlaubt eine beliebige Anzahl von L-LSPs pro FEC innerhalb einer MPLS-ATM-Diff-Serv-Domäne. E-LSPs werden über LC- ATM-Schnittstellen nicht unterstützt.

8.1 Verwendung von ATM-Verkehrsklassen und Traffic-Management-

Mechanismen

Die Verwendung der vom ATM Forum spezifizierten „ATM service categories“, der von der ITU-T spezifizierten „ATM Transfer Capabilities“ oder herstellerspezifischer ATM-Verkehrsklassen liegt außerhalb des Geltungsbereichs dieser Spezifikation. Die einzige Anforderung für eine konforme Implementierung ist, dass das Weiterleitungsverhalten, das ein über einen L-LSP von dem ATM-LSR weitergeleitetes Behavior Aggregate erfährt, MUST mit den entsprechenden Diff-Serv-PHB-Spezifikationen konform sein.

Da es nur ein Bit (CLP) zur Kodierung des PHB-Drop-Precedence-Wertes über ATM-Verbindungen gibt, werden in ATM-LSRs nur zwei verschiedene Drop-Precedence-Stufen unterstützt. Die Abschnitte 4.2.2 und 4.4.2 definieren, wie die drei Drop-Precedence-Stufen der AFn Ordered Aggregates auf diese zwei ATM-Drop-Precedence-Stufen abgebildet werden. Diese Abbildung steht in Übereinstimmung mit den in [DIFF_AF] spezifizierten Anforderungen für den Fall, dass nur zwei Drop-Precedence-Stufen unterstützt werden.

Um das Verwerfen von Paketteilen zu vermeiden, SHOULD Frame-Discard- Mechanismen wie Early Packet Discard (EPD) (siehe [ATMF_TM]) in den ATM-LSRs für alle in diesem Dokument beschriebenen PHBs aktiviert werden.

8.2 LSR-Implementierung mit LC-ATM-Schnittstellen

Ein Diff-Serv-fähiger LSR MUST L-LSPs über LC-ATM-Schnittstellen unterstützen. Diese Spezifikation nimmt an, dass Edge-LSRs der ATM- LSR-Domäne die in [MPLS_ATM] definierte „shim header“- Einkapselungsmethode verwenden. Operationen ohne die „shim header“- Einkapselung liegen außerhalb des Geltungsbereichs dieser Spezifikation.

9. MPLS-Unterstützung von Diff-Serv über LC-FR-Schnittstellen

Dieser Abschnitt beschreibt die spezifischen Operationen, die für die MPLS-Unterstützung von Diff-Serv über label-switching-gesteuerte Frame-Relay-(LC-FR)-Schnittstellen erforderlich sind.

Dieses Dokument erlaubt eine beliebige Anzahl von L-LSPs pro FEC innerhalb einer MPLS-Frame-Relay-Diff-Serv-Domäne. E-LSPs werden über LC-FR-Schnittstellen nicht unterstützt.

9.1 Verwendung von Frame-Relay-Verkehrsparametern und Traffic-

Management-Mechanismen

Die Verwendung der von ITU-T und Frame Relay-Forum spezifizierten Frame-Relay-Verkehrsparameter oder herstellerspezifischer Frame- Relay-Traffic-Management-Mechanismen liegt außerhalb des Geltungsbereichs dieser Spezifikation. Die einzige Anforderung für eine konforme Implementierung ist, dass das Weiterleitungsverhalten, das ein über einen L-LSP von dem Frame-Relay-LSR weitergeleitetes Behavior Aggregate erfährt, MUST mit den entsprechenden Diff-Serv- PHB-Spezifikationen konform sein.

Da es nur ein Bit (DE) zur Kodierung des PHB-Drop-Precedence-Wertes über Frame-Relay-Verbindungen gibt, werden in Frame-Relay-LSRs nur zwei verschiedene Drop-Precedence-Stufen unterstützt. Die Abschnitte 4.2.3 und 4.4.3 definieren, wie die drei Drop-Precedence-Stufen der AFn Ordered Aggregates auf diese zwei Frame-Relay-Drop-Precedence- Stufen abgebildet werden. Diese Abbildung steht in Übereinstimmung mit den in [DIFF_AF] spezifizierten Anforderungen für den Fall, dass nur zwei Drop-Precedence-Stufen unterstützt werden.

9.2 LSR-Implementierung mit LC-FR-Schnittstellen

Ein Diff-Serv-fähiger LSR MUST L-LSPs über LC-Frame-Relay- Schnittstellen unterstützen.

Diese Spezifikation nimmt an, dass Edge-LSRs der FR-LSR-Domäne die in [MPLS_FR] empfohlene „generic encapsulation“-Methode verwenden. Operationen ohne die „generic encapsulation“ liegen außerhalb des Geltungsbereichs dieser Spezifikation.

10. IANA-Erwägungen

Dieses Dokument definiert eine Reihe von Objekten mit Implikationen für IANA.

Dieses Dokument definiert in Abschnitt 5.2 ein neues RSVP-Objekt, das DIFFSERV-Objekt. Dieses Objekt erforderte eine Nummer aus dem in [RSVP] definierten Raum für jene Objekte, die, wenn sie nicht verstanden werden, dazu führen, dass die gesamte RSVP-Nachricht mit einem Fehlercode von „Unknown Object Class“ abgelehnt wird. Solche Objekte werden durch eine Null im höchstwertigen Bit der Class-Nummer identifiziert. Innerhalb dieses Raums erforderte dieses Objekt eine Nummer aus dem „IETF Consensus“-Raum. „65“ wurde von IANA für das DIFFSERV-Objekt zugewiesen.

Dieses Dokument definiert in Abschnitt 5.5 einen neuen RSVP- Fehlercode, „Diffserv Error“. Fehlercode „27“ wurde von IANA dem „Diffserv Error“ zugewiesen. Dieses Dokument definiert die Werte 1 bis 5 des Wertefeldes, das innerhalb des ERROR_SPEC-Objekts für diesen Fehlercode zu verwenden ist. Zukünftige Zuweisungen von Werten in diesem Raum sollten von IANA unter Verwendung der in [IANA] definierten First Come First Served-Politik behandelt werden.

Dieses Dokument definiert in Abschnitt 6.1 ein neues LDP-TLV, das Diffserv-TLV. Die Nummer für dieses TLV wurde durch Working-Group- Consensus gemäß den in [LDP] definierten Politiken zugewiesen.

Dieses Dokument definiert in Abschnitt 6.2 fünf neue LDP-Statuscode- Werte für Diffserv-bezogene Fehlerbedingungen. Die Werte für den Status Code wurden durch Working-Group-Consensus gemäß den in [LDP] definierten Politiken zugewiesen.

11. Sicherheitserwägungen

Dieses Dokument führt keine neuen Sicherheitsprobleme über die hinaus ein, die Diff-Serv, MPLS und RSVP inhärent sind, und kann dieselben Mechanismen verwenden, die für jene Technologien vorgeschlagen wurden.

12. Danksagungen

Dieses Dokument hat von Diskussionen mit Eric Rosen, Angela Chiu und Carol Iturralde profitiert. Es hat auch von der Arbeit von D. Black bezüglich der Wechselwirkung von Diff-Serv und IP-Tunneln übernommen.

ANHANG A. Beispielhafte Einsatzszenarien

Dieser Abschnitt liefert keine zusätzliche Spezifikation und dient nur dazu, Beispiele zu geben, wie dieser flexible Ansatz zur Diff- Serv-Unterstützung über MPLS eingesetzt werden kann. Vor- und Nachteile verschiedener Einsatzoptionen für besondere Umgebungen liegen außerhalb des Geltungsbereichs dieses Dokuments.

A.1 Szenario 1: 8 (oder weniger) BAs, kein Traffic Engineering, kein MPLS-Schutz

Ein Dienstanbieter, der 8 (oder weniger) BAs über MPLS betreibt, kein Traffic Engineering durchführt, keinen MPLS-Schutz verwendet und MPLS-Shim-Header-Einkapselung in seinem/ihrem Netzwerk verwendet, kann wählen, Diff-Serv über MPLS unter Verwendung eines einzelnen E- LSP pro FEC zu betreiben, der via LDP eingerichtet wird. Darüber hinaus kann der Dienstanbieter wählen, die vorkonfigurierte `EXP<-->PHB mapping' zu verwenden.