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:

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

  • 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

(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 P represents the LSP penultimate node E represents the LSP egress node

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.