Aller au contenu principal

2. Modèle de transfert d'étiquettes pour les LSR Diff-Serv et modèles de tunnelisation

2.1. Modèle de transfert d'étiquettes pour les LSR Diff-Serv​

Étant donné que différents agrégats ordonnés d'une FEC donnée peuvent être transportés sur différents LSP, la décision de permutation d'étiquette d'un LSR Diff-Serv dépend clairement de l'agrégat de comportement du paquet transféré. De plus, étant donné que le champ DS IP d'un paquet transféré peut ne pas être directement visible pour un LSR, la manière de déterminer le PHB à appliquer à un paquet reçu et de coder le PHB dans un paquet transmis est différente de celle d'un routeur Diff-Serv non MPLS.

Ainsi, afin de décrire le transfert d'étiquettes par les LSR Diff-Serv, nous modélisons le comportement de commutation d'étiquettes Diff-Serv du LSR, composé de quatre étapes :

  • Détermination du PHB entrant (A)

  • Détermination du PHB sortant avec conditionnement de trafic optionnel (B)

  • Transfert d'étiquettes (C)

  • Codage des informations Diff-Serv dans la couche d'encapsulation (EXP, CLP, DE, User_Priority) (D)

Chaque étape est décrite plus en détail dans les sections suivantes.

De toute évidence, pour faire respecter la différenciation de service Diff-Serv, le LSR MUST également appliquer le traitement de transfert correspondant au PHB sortant.

Ce modèle est illustré ci-dessous :

--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 » désigne les informations liées à Diff-Serv codées dans la couche d'encapsulation MPLS (par exemple, champ EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority)

(*) lorsque le LSR se comporte comme un nœud d'entrée MPLS, le paquet entrant peut être reçu non étiqueté.

(&) lorsque le LSR se comporte comme un nœud de sortie MPLS, le paquet sortant peut être transmis non étiqueté.

Ce modèle est présenté ici pour décrire les opérations fonctionnelles des LSR Diff-Serv et ne contraint pas l'implémentation réelle.

2.2. Détermination du PHB entrant​

Cette étape détermine à quel agrégat de comportement appartient le paquet reçu.

2.2.1. Détermination du PHB entrant en considérant une entrée de pile d'étiquettes​

Les sections 3.3 et 4.3 fournissent les détails sur la manière d'effectuer la détermination du PHB entrant en considérant une entrée de pile d'étiquettes reçue donnée et/ou les informations d'encapsulation MPLS entrantes reçues selon le type de LSP entrant et selon l'encapsulation MPLS entrante.

La section 2.6 fournit les détails sur l'entrée de pile d'étiquettes à considérer pour la détermination du PHB entrant selon le mode de tunnelisation Diff-Serv pris en charge.

2.2.2. Détermination du PHB entrant en considérant l'en-tête IP​

La section 2.6 fournit les détails sur le moment où l'en-tête IP doit être considéré pour la détermination du PHB entrant, selon le modèle de tunnelisation Diff-Serv pris en charge. Dans les cas où l'en-tête IP doit être utilisé, cette étape fonctionne exactement comme avec un routeur Diff-Serv IP non MPLS et utilise le champ DS pour déterminer le PHB entrant.

2.3. Détermination du PHB sortant avec conditionnement de trafic optionnel​

L'étape de conditionnement de trafic est optionnelle et peut être utilisée sur un LSR pour effectuer un conditionnement de trafic incluant la rétrogradation ou la promotion d'agrégat de comportement. Elle est hors du champ d'application de cette spécification. Aux fins de spécifier le transfert Diff-Serv sur MPLS, nous notons simplement que le PHB à effectivement appliquer et transmettre aux LSR en aval par un LSR (appelé « PHB sortant »), peut être différent du PHB qui avait été associé au paquet par le LSR précédent (appelé « PHB entrant »).

Lorsque l'étape de conditionnement de trafic n'est pas présente, le « PHB sortant » est simplement identique au « PHB entrant ».

2.4. Transfert d'étiquettes​

[MPLS_ARCH] décrit comment la permutation d'étiquette est effectuée par les LSR sur les paquets étiquetés entrants en utilisant un Incoming Label Map (ILM), où chaque étiquette entrante est mappée vers une ou plusieurs NHLFE. [MPLS_ARCH] décrit également comment l'imposition d'étiquette est effectuée par les LSR sur les paquets non étiquetés entrants en utilisant un FEC-to-NHLFEs Map (FTN), où chaque FEC entrante est mappée vers une ou plusieurs NHLFE.

Un contexte Diff-Serv pour une étiquette est composé de :

  • `type de LSP (c'est-à-dire E-LSP ou L-LSP)'

  • `PHB pris en charge'

  • `mappage Encaps-->PHB' pour une étiquette entrante

  • `ensemble de mappages PHB-->Encaps' pour une étiquette sortante

La présente spécification définit qu'un contexte Diff-Serv est stocké dans l'ILM pour chaque étiquette entrante.

[MPLS_ARCH] indique que la « NHLFE peut également contenir toute autre information nécessaire afin de disposer correctement du paquet ». Conformément à cela, la présente spécification définit qu'un contexte Diff-Serv est stocké dans la NHLFE pour chaque étiquette sortante qui est permutée ou poussée.

Ces informations de contexte Diff-Serv sont peuplées dans l'ILM et le FTN au moment de l'établissement de l'étiquette.

Si l'étiquette correspond à un E-LSP pour lequel aucun mappage EXP<-->PHB' n'a été explicitement signalé lors de l'établissement du LSP, les PHB pris en charge' sont peuplés avec l'ensemble des PHB du mappage `EXP<-->PHB' préconfiguré, qui est discuté ci-dessous à la section 3.2.1.

Si l'étiquette correspond à un E-LSP pour lequel un mappage EXP<-->PHB' a été explicitement signalé lors de l'établissement du LSP, les PHB pris en charge' sont peuplés avec l'ensemble des PHB du mappage `EXP<-->PHB' signalé.

Si l'étiquette correspond à un L-LSP, les `PHB pris en charge' sont peuplés avec l'ensemble des PHB formant le PSC qui est signalé lors de l'établissement du LSP.

Les détails de la manière dont le mappage Encaps-->PHB' ou l'ensemble de mappages PHB-->Encaps' sont peuplés sont définis ci-dessous aux sections 3 et 4.

[MPLS_ARCH] indique également que :

« Si l'ILM [respectivement, le FTN] mappe une étiquette particulière vers un ensemble de NHLFE qui contiennent plus d'un élément, exactement un élément de l'ensemble doit être choisi avant que le paquet ne soit transféré. Les procédures pour choisir un élément de l'ensemble sont hors du champ d'application de ce document. Faire en sorte que l'ILM [respectivement, le FTN] mappe une étiquette [respectivement, une FEC] vers un ensemble contenant plus d'une NHLFE peut être utile si, par exemple, on souhaite effectuer un équilibrage de charge sur plusieurs chemins de coût égal. »

Conformément à cela, la présente spécification permet qu'une étiquette entrante [respectivement une FEC] puisse être mappée, à des fins Diff-Serv, vers plusieurs NHLFE (par exemple lorsque différentes NHLFE correspondent à des étiquettes de sortie prenant en charge différents ensembles de PHB). Lorsqu'une étiquette [respectivement une FEC] mappe vers plusieurs NHLFE, le LSR Diff-Serv MUST choisir l'une des NHLFE dont le contexte Diff-Serv indique qu'elle prend en charge le PHB sortant du paquet transféré.

Lorsqu'une étiquette [respectivement une FEC] mappe vers plusieurs NHLFE qui prennent en charge le PHB sortant, la procédure pour en choisir une parmi celles-ci est hors du champ d'application de ce document. Cette situation peut être rencontrée lorsqu'il est souhaité d'effectuer un équilibrage de charge d'un agrégat de comportement sur plusieurs LSP. Dans de telles situations, afin de respecter les contraintes d'ordonnancement, tous les paquets d'un microflux donné MUST être transportés sur le même LSP.

2.5. Codage des informations Diff-Serv dans la couche d'encapsulation​

Cette étape détermine comment coder les champs qui transportent les informations Diff-Serv dans le paquet transmis (par exemple, MPLS Shim EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority).

2.5.1. Codage des informations Diff-Serv dans l'entrée d'étiquette transmise​

Les sections 3.5 et 4.5 fournissent les détails sur la manière d'effectuer le codage des informations Diff-Serv dans une entrée de pile d'étiquettes transmise donnée et/ou les informations d'encapsulation MPLS transmises selon le type de LSP sortant correspondant et selon l'encapsulation MPLS.

La section 2.6 fournit les détails sur l'entrée de pile d'étiquettes dans laquelle effectuer le codage des informations Diff-Serv selon le mode de tunnelisation Diff-Serv pris en charge.

2.5.2. Codage des informations Diff-Serv dans l'en-tête IP transmis​

Pour effectuer le codage des informations Diff-Serv dans l'en-tête IP du paquet transmis, cette étape fonctionne exactement comme avec un routeur Diff-Serv IP non MPLS et code le DSCP du PHB sortant dans le champ DS.

La section 2.6 fournit les détails sur le moment où le codage des informations Diff-Serv doit être effectué dans l'en-tête IP transmis selon le mode de tunnelisation Diff-Serv pris en charge.

2.6. Modèles de tunnelisation Diff-Serv sur MPLS​

2.6.1. Modèles de tunnelisation Diff-Serv​

[DIFF_TUNNEL] examine l'interaction des services différenciés avec les tunnels IP de diverses formes. Les LSP MPLS ne sont pas une forme de « tunnels IP » car l'en-tête d'encapsulation MPLS ne contient pas d'en-tête IP et donc les LSP MPLS ne sont pas considérés dans [DIFF_TUNNEL]. Cependant, bien qu'ils ne constituent pas une forme de « tunnel IP », les LSP MPLS sont une forme de « tunnel ».

Du point de vue Diff-Serv, les LSP partagent un certain nombre de caractéristiques communes avec les tunnels IP :

  • Les nœuds intermédiaires (c'est-à-dire les nœuds situés quelque part le long de l'étendue du LSP) ne voient et n'opèrent que sur les informations Diff-Serv « externes ».

  • Les LSP sont unidirectionnels.

  • Les informations Diff-Serv « externes » peuvent être modifiées à n'importe lequel des nœuds intermédiaires.

Cependant, du point de vue Diff-Serv, les LSP ont également une propriété distinctive par rapport aux tunnels IP :

  • Il n'y a généralement pas de comportement analogue au Penultimate Hop Popping (PHP) utilisé avec les tunnels IP. En outre, le PHP a pour résultat que les informations Diff-Serv « externes » associées au LSP ne sont pas visibles pour la sortie du LSP. Dans les situations où ces informations ne sont pas significatives à la sortie du LSP, ce n'est manifestement pas un problème du tout. Dans les situations où ces informations sont significatives à la sortie du LSP, alors elles doivent d'une manière ou d'une autre être transportées par d'autres moyens.

Les deux modèles conceptuels pour la tunnelisation Diff-Serv sur les tunnels IP définis dans [DIFF_TUNNEL] sont applicables et utiles à Diff-Serv sur MPLS, mais leur fonctionnement détaillé respectif est quelque peu différent sur MPLS. Ces deux modèles sont le modèle Pipe (modèle Tuyau) et le modèle Uniform (modèle Uniforme). Leur fonctionnement sur MPLS est spécifié dans les sections suivantes. La discussion et la définition de modèles de tunnelisation alternatifs sont hors du champ d'application de cette spécification.

2.6.2. Modèle Pipe (modèle Tuyau)​

Avec le modèle Pipe (modèle Tuyau), les tunnels MPLS (alias LSP) sont utilisés pour masquer les nœuds MPLS intermédiaires entre l'entrée et la sortie du LSP du point de vue Diff-Serv.

Dans ce modèle, les paquets tunnelisés doivent transporter deux éléments d'information Diff-Serv significatifs :

  • les informations Diff-Serv qui sont significatives pour les nœuds intermédiaires le long de l'étendue du LSP y compris la sortie du LSP (que nous appelons les « informations Diff-Serv du LSP »). Ces informations Diff-Serv du LSP ne sont pas significatives au-delà de la sortie du LSP : que le conditionnement de trafic aux nœuds intermédiaires sur l'étendue du LSP affecte ou non les informations Diff-Serv du LSP, ces informations Diff-Serv mises à jour ne sont pas considérées comme significatives au-delà de la sortie du LSP et sont ignorées.

  • les informations Diff-Serv qui sont significatives au-delà de la sortie du LSP (que nous appelons les « informations Diff-Serv tunnelisées »). Ces informations doivent être transportées par l'entrée du LSP vers la sortie du LSP. Ces informations Diff-Serv ne sont pas significatives pour les nœuds intermédiaires sur l'étendue du LSP.

Le fonctionnement du modèle Pipe sans PHP est illustré ci-dessous :

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

             ---Swap--(M)--...--Swap--(M)--Swap----
            /        (outer header)                \
          (M)                                      (M)
          /                                          \
>--(m)-Push.................(m).....................Pop--(m)-->
         I             (inner header)                E   (M*)

(M) représente les « informations Diff-Serv du LSP » (m) représente les « informations Diff-Serv tunnelisées » (*) La sortie du LSP considère les informations Diff-Serv du LSP reçues dans l'en-tête externe (c'est-à-dire avant le pop) afin d'appliquer son traitement de transfert Diff-Serv (c'est-à-dire le PHB réel) I représente le nœud d'entrée du LSP E représente le nœud de sortie du LSP

Avec le modèle Pipe, les « informations Diff-Serv du LSP » doivent être transportées jusqu'à la sortie du LSP afin qu'elle applique son traitement de transfert sur leur base. Les « informations Diff-Serv tunnelisées » doivent également être transportées jusqu'à la sortie du LSP afin qu'elles puissent être transportées plus loin en aval.

Étant donné que les deux exigent que les informations Diff-Serv soient transportées jusqu'à la sortie du LSP, le modèle Pipe ne fonctionne qu'sans PHP.

Le modèle Pipe est particulièrement approprié pour les environnements dans lesquels :

  • le nuage en amont de l'interface entrante de l'entrée du LSP et le nuage en aval de l'interface sortante de la sortie du LSP sont dans des domaines Diff-Serv qui utilisent un ensemble commun de politiques de provisionnement de service Diff-Serv et de définitions de PHB, tandis que le LSP s'étend sur un (ou plusieurs) domaine(s) Diff-Serv qui utilise(nt) un ensemble différent de politiques de provisionnement de service Diff-Serv et de définitions de PHB

  • l'interface sortante de la sortie du LSP est dans le (dernier) domaine Diff-Serv traversé par le LSP.

À titre d'exemple, considérez le cas où un fournisseur de services offre un service VPN MPLS (voir [MPLS_VPN] pour un exemple d'architecture VPN MPLS) incluant une différenciation Diff-Serv. Supposons qu'un ensemble de sites soit interconnecté via un tel service VPN MPLS. Maintenant, supposez que cet ensemble de sites soit géré sous une administration commune et prenne également en charge la différenciation de service Diff-Serv. Si l'administration du site VPN et le fournisseur de services ne partagent pas exactement la même politique Diff-Serv (par exemple, ne prenant pas en charge le même nombre de PHB), alors le fonctionnement de Diff-Serv dans le modèle Pipe sur le service VPN MPLS permettrait à la politique Diff-Serv des sites VPN de fonctionner de manière cohérente à travers le site VPN d'entrée et le site VPN de sortie et de manière transparente sur le domaine Diff-Serv du fournisseur de services. Il peut être utile de considérer de tels LSP comme liant les domaines Diff-Serv à leurs extrémités en une seule région Diff-Serv en rendant ces extrémités virtuellement contiguës même si elles peuvent être physiquement séparées par des nœuds de réseau intermédiaires.

Le modèle Pipe MUST être pris en charge.

Pour la prise en charge du modèle Pipe sur un LSP donné sans PHP, un LSR effectue la détermination du PHB entrant et le codage des informations Diff-Serv de la manière suivante :

  • lors de la réception d'un paquet non étiqueté, le LSR effectue la détermination du PHB entrant en considérant l'en-tête IP reçu.

  • lors de la réception d'un paquet étiqueté, le LSR effectue la détermination du PHB entrant en considérant l'entrée d'étiquette externe dans la pile d'étiquettes reçue. En particulier, lorsqu'une opération de pop doit être effectuée pour le LSP considéré, le LSR effectue la détermination du PHB entrant AVANT le pop.

  • lors de l'exécution d'une opération de push pour le LSP considéré, le LSR :

  • code les informations Diff-Serv correspondant au PHB SORTANT dans l'entrée d'étiquette transmise correspondant à l'étiquette poussée.

  • code les informations Diff-Serv correspondant au PHB ENTRANT dans l'en-tête encapsulé (entrée d'étiquette permutée ou en-tête IP).

  • lors de l'exécution d'une opération de swap uniquement pour le LSP considéré, le LSR code les informations Diff-Serv dans l'entrée d'étiquette transmise qui contient l'étiquette permutée

  • lors de l'exécution d'une opération de pop pour le LSP considéré, le LSR n'effectue pas le codage des informations Diff-Serv dans l'en-tête exposé par l'opération de pop (c'est-à-dire que le LSR laisse l'en-tête exposé « tel quel »).

2.6.2.1. Modèle Short Pipe (modèle Tuyau court)​

Le modèle Short Pipe (modèle Tuyau court) est une variation optionnelle du modèle Pipe décrit ci-dessus. La seule différence est qu'avec le modèle Short Pipe, le traitement de transfert Diff-Serv à la sortie du LSP est appliqué sur la base des « informations Diff-Serv tunnelisées » (c'est-à-dire les informations Diff-Serv transportées dans l'en-tête encapsulé) plutôt que sur les « informations Diff-Serv du LSP » (c'est-à-dire les informations Diff-Serv transportées dans l'en-tête d'encapsulation).

Le fonctionnement du modèle Short Pipe sans PHP est illustré ci-dessous :

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

             ---Swap--(M)--...--Swap--(M)--Swap----
            /        (outer header)                \
          (M)                                      (M)
          /                                          \
>--(m)-Push.................(m).....................Pop--(m)-->
         I             (inner header)                E

(M) représente les « informations Diff-Serv du LSP » (m) représente les « informations Diff-Serv tunnelisées » I représente le nœud d'entrée du LSP E représente le nœud de sortie du LSP

Étant donné que la sortie du LSP applique son traitement de transfert sur la base des « informations Diff-Serv tunnelisées », les « informations Diff-Serv du LSP » n'ont pas besoin d'être transportées par le nœud penultième vers la sortie du LSP. Ainsi, le modèle Short Pipe peut également fonctionner avec PHP.

Le fonctionnement du modèle Short Pipe avec PHP est illustré ci-dessous :

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

             ---Swap--(M)--...--Swap------
            /       (outer header)        \
          (M)                             (M)
          /                                 \
>--(m)-Push.................(m).............Pop-(m)--E--(m)-->
        I           (inner header)           P (M*)

(M) représente les « informations Diff-Serv du LSP » (m) représente les « informations Diff-Serv tunnelisées » (*) Le LSR penultième considère les informations Diff-Serv du LSP reçues dans l'en-tête externe (c'est-à-dire avant le pop) afin d'appliquer son traitement de transfert Diff-Serv (c'est-à-dire le PHB réel) I représente le nœud d'entrée du LSP P représente le nœud penultième du LSP E représente le nœud de sortie du LSP

Le modèle Short Pipe est particulièrement approprié pour les environnements dans lesquels :

  • le nuage en amont de l'interface entrante de l'entrée du LSP et le nuage en aval de l'interface sortante de la sortie du LSP sont dans des domaines Diff-Serv qui utilisent un ensemble commun de politiques de provisionnement de service Diff-Serv et de définitions de PHB, tandis que le LSP s'étend sur un (ou plusieurs) domaine(s) Diff-Serv qui utilise(nt) un ensemble différent de politiques de provisionnement de service Diff-Serv et de définitions de PHB

  • l'interface sortante de la sortie du LSP est dans le même domaine Diff-Serv que le nuage en aval de celle-ci.

Étant donné que chaque interface sortante de la sortie du LSP est dans le même domaine Diff-Serv que le nuage en aval de celle-ci, chaque interface sortante peut potentiellement être dans un domaine Diff-Serv différent, et la sortie du LSP doit être configurée avec la connaissance de chaque politique Diff-Serv correspondante. Cette surcharge opérationnelle est justifiée dans certaines situations où les politiques Diff-Serv en aval respectives sont mieux adaptées pour offrir une différenciation de service sur chaque interface de sortie que la politique Diff-Serv commune utilisée sur l'étendue du LSP. Un exemple d'une telle situation est celui où un fournisseur de services offre un service VPN MPLS et où certains utilisateurs VPN demandent que leur propre politique Diff-Serv VPN soit appliquée pour contrôler la différenciation de service sur le lien dédié de la sortie du LSP vers le site VPN de destination, plutôt que la politique Diff-Serv du fournisseur de services.

Le modèle Short Pipe MAY être pris en charge.

Pour la prise en charge du modèle Short Pipe sur un LSP donné sans PHP, un LSR effectue la détermination du PHB entrant et le codage des informations Diff-Serv de la même manière qu'avec le modèle Pipe avec l'exception suivante :

  • lors de la réception d'un paquet étiqueté, le LSR effectue la détermination du PHB entrant en considérant l'en-tête (entrée d'étiquette ou en-tête IP) qui est utilisé pour effectuer le transfert réel. En particulier, lorsqu'une opération de pop doit être effectuée pour le LSP considéré, le LSR effectue la détermination du PHB entrant APRÈS le pop.

Pour la prise en charge du modèle Short Pipe sur un LSP donné avec PHP, un LSR effectue la détermination du PHB entrant et le codage des informations Diff-Serv de la même manière que sans PHP avec les exceptions suivantes :

  • le LSR penultième effectue la détermination du PHB entrant en considérant l'entrée d'étiquette externe dans la pile d'étiquettes reçue. En d'autres termes, lorsqu'une opération de pop doit être effectuée pour le LSP considéré, le LSR penultième effectue la détermination du PHB entrant AVANT le pop.

Notez que le comportement du LSR penultième dans le mode Short Pipe avec PHP est identique au comportement de la sortie du LSP dans le mode Pipe (nécessairement sans PHP).

2.6.3. Modèle Uniform (modèle Uniforme)​

Avec le modèle Uniform (modèle Uniforme), les tunnels MPLS (alias LSP) sont considérés comme des artefacts du chemin de bout en bout du point de vue Diff-Serv. Les tunnels MPLS peuvent être utilisés à des fins de transfert mais n'ont pas d'impact significatif sur Diff-Serv. Dans ce modèle, tout paquet contient exactement un élément d'information Diff-Serv qui est significatif et est toujours codé dans l'entrée d'étiquette la plus externe (ou dans le DSCP IP lorsque le paquet IP est transmis non étiqueté, par exemple à la sortie du LSP). Toute information Diff-Serv codée ailleurs (par exemple, dans des entrées d'étiquette plus profondes) n'a aucune signification pour les nœuds intermédiaires ou pour la sortie du tunnel et est ignorée. Si le conditionnement de trafic aux nœuds intermédiaires sur l'étendue du LSP affecte les informations Diff-Serv « externes », les informations Diff-Serv mises à jour sont celles considérées comme significatives à la sortie du LSP.

Le fonctionnement du modèle Uniform sans PHP est illustré ci-dessous :

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

              ---Swap--(M)--...-Swap--(M)--Swap----
             /         (outer header)              \
           (M)                                     (M)
           /                                         \
>--(M)--Push...............(x).......................Pop--(M)->
         I            (inner header)                  E

(M) représente les informations Diff-Serv significatives codées dans l'en-tête correspondant. (x) représente des informations Diff-Serv non significatives. I représente le nœud d'entrée du LSP E représente le nœud de sortie du LSP

Le fonctionnement du modèle Uniform avec PHP est illustré ci-dessous :

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

              ---Swap-(M)-...-Swap------
             /        (outer header)    \
           (M)                          (M)
           /                              \
>--(M)--Push..............(x)............Pop-(M)--E--(M)->
          I          (inner header)       P

(M) représente les informations Diff-Serv significatives codées dans l'en-tête correspondant. (x) représente des informations Diff-Serv non significatives. I représente le nœud d'entrée du LSP P représente le nœud penultième du LSP E représente le nœud de sortie du LSP

Le modèle Uniform pour Diff-Serv sur MPLS est tel que, du point de vue Diff-Serv, les opérations sont exactement identiques aux opérations si MPLS n'était pas utilisé. En d'autres termes, MPLS est entièrement transparent pour les opérations Diff-Serv.

L'utilisation du modèle Uniform permet aux LSP de traverser les frontières de domaines Diff-Serv sans aucune autre mesure en place qu'un accord de conditionnement de trafic inter-domaines à la frontière physique entre les domaines Diff-Serv et opérant exclusivement sur l'en-tête « externe », car les informations Diff-Serv significatives sont toujours visibles et modifiables dans l'entrée d'étiquette la plus externe.

Le modèle Uniform MAY être pris en charge.

Pour la prise en charge du modèle Uniform sur un LSP donné, un LSR effectue la détermination du PHB entrant et le codage des informations Diff-Serv de la manière suivante :

  • lors de la réception d'un paquet non étiqueté, le LSR effectue la détermination du PHB entrant en considérant l'en-tête IP reçu.

  • lors de la réception d'un paquet étiqueté, le LSR effectue la détermination du PHB entrant en considérant l'entrée d'étiquette externe dans la pile d'étiquettes reçue. En particulier, lorsqu'une opération de pop doit être effectuée pour le LSP considéré, le LSR effectue la détermination du PHB entrant AVANT le pop.

  • lors de l'exécution d'une opération de push pour le LSP considéré, le LSR code les informations Diff-Serv dans l'entrée d'étiquette transmise correspondant à l'étiquette poussée. Les informations Diff-Serv codées dans l'en-tête encapsulé (entrée d'étiquette permutée ou en-tête IP) n'ont aucune importance.

  • lors de l'exécution d'une opération de swap uniquement pour le LSP considéré, le LSR code les informations Diff-Serv dans l'entrée d'étiquette transmise qui contient l'étiquette permutée.

  • lorsque le PHP est utilisé, le LSR penultième doit être conscient de l'« ensemble de mappages PHB-->Encaps » pour l'étiquette correspondant à l'en-tête exposé (ou du mappage `PHB-->DSCP') afin d'effectuer le codage des informations Diff-Serv. Les méthodes pour fournir cette conscience de mappage sont hors du champ d'application de cette spécification. À titre d'exemple, le mappage « PHB-->DSCP » peut être configuré localement. À titre d'autre exemple, dans certains environnements, il peut être approprié pour le LSR penultième d'assumer que l'« ensemble de mappages PHB-->Encaps » à utiliser pour l'étiquette sortante dans l'en-tête exposé est l'« ensemble de mappages PHB-->Encaps » qui serait utilisé par le LSR si le LSR ne faisait pas de PHP. Notez également que cette spécification suppose que le LSR penultième n'effectue pas de permutation d'étiquette sur l'entrée d'étiquette exposée par l'opération de pop (et en fait qu'il ne regarde même pas l'étiquette exposée). Par conséquent, des restrictions peuvent s'appliquer au codage des informations Diff-Serv qui peut être effectué par le LSR penultième. Par exemple, cette spécification n'autorise pas les situations où le LSR penultième fait un pop d'une étiquette correspondant à un E-LSP prenant en charge deux PSC, tandis que l'en-tête exposé par le pop contient des valeurs d'étiquette pour deux L-LSP prenant chacun en charge un PSC, car le codage des informations Diff-Serv nécessiterait de sélectionner une étiquette ou l'autre.

Notez que les comportements de LSR pour les modèles Pipe, Short Pipe et Uniform ne diffèrent que lors d'un push ou d'un pop. Ainsi, les LSR intermédiaires qui n'effectuent que des opérations de swap pour un LSP se comportent exactement de la même manière, qu'ils se comportent dans le modèle Pipe, Short Pipe ou Uniform. Avec une implémentation Diff-Serv prenant en charge plusieurs modèles de tunnelisation, seuls les LSR se comportant comme entrée de LSP, LSR penultième ou sortie de LSP doivent être configurés pour fonctionner dans un modèle particulier. La signalisation pour associer un modèle de tunnelisation Diff-Serv sur une base par LSP n'est pas dans le champ d'application de cette spécification.

2.6.4. Hiérarchie​

Grâce au mécanisme de pile d'étiquettes, MPLS permet à la tunnelisation LSP de s'imbriquer à n'importe quelle profondeur. Nous observons qu'avec une telle imbrication, le push de niveau N+1 a lieu sur un LSR subséquent (ou le même) au LSR effectuant le push pour le niveau N, tandis que le pop de niveau N+1 a lieu sur un LSR précédent (ou le même) au LSR effectuant le pop de niveau N. Pour un LSP de niveau N donné, le LSR d'entrée effectuant le push et le LSR effectuant le pop (LSR penultième ou sortie de LSP) doivent fonctionner dans le même modèle de tunnelisation (c'est-à-dire Pipe, Short Pipe ou Uniform). Cependant, il n'y a pas d'exigence de modèles de tunnelisation cohérents entre les niveaux de sorte que les LSP à différents niveaux peuvent fonctionner dans différents modèles de tunnelisation.

Les opérations hiérarchiques sont illustrées ci-dessous dans le cas de deux niveaux de tunnels :

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

(1) Modèle de tunnelisation 1 (2) Modèle de tunnelisation 2

Le modèle de tunnelisation 2 peut être le même que ou peut être différent du modèle de tunnelisation 1.

Pour un LSP de niveau N donné, le LSR doit effectuer la détermination du PHB entrant et le codage des informations Diff-Serv comme spécifié aux sections 2.6.2, 2.6.2.1 et 2.6.3 selon le modèle de tunnelisation de ce LSP de niveau N et indépendamment du modèle de tunnelisation des LSP d'autres niveaux.