RFC 3270 - Prise en charge des services différenciés par 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)
               Support of Differentiated Services

Statut de ce mémo

Ce document spécifie un protocole de normalisation Internet pour la communauté Internet et sollicite des discussions et des suggestions en vue de son amélioration. Veuillez vous référer à l'édition courante des « Internet Official Protocol Standards » (STD 1) pour connaître l'état de normalisation et le statut de ce protocole. La distribution de ce mémo est illimitée.

Avis de droit d'auteur

Résumé

Ce document définit une solution flexible pour la prise en charge des services différenciés (Differentiated Services, Diff-Serv) sur les réseaux Multi-Protocol Label Switching (MPLS).

Cette solution permet à l'administrateur du réseau MPLS de choisir comment les agrégats de comportement Diff-Serv (Behavior Aggregates, BA) sont mappés sur les chemins à commutation d'étiquettes (Label Switched Paths, LSP) afin qu'il puisse répondre au mieux aux objectifs de Diff-Serv, d'ingénierie de trafic et de protection au sein de son réseau particulier. Par exemple, cette solution permet à l'administrateur réseau de décider si différents ensembles de BA doivent être mappés sur le même LSP ou mappés sur des LSP distincts.

Table des matières

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 LSP à PSC déduit du champ EXP (E-LSP) . . . . . . . . . . . . . 6 1.3 LSP à PSC déduit uniquement de l'étiquette (L-LSP) . . . . . . 7 1.4 Fonctionnement global . . . . . . . . . . . . . . . . . . . . . 7 1.5 Relation entre étiquette et FEC . . . . . . . . . . . . . . . . 8 1.6 Réservation de bande passante pour les E-LSP et L-LSP . . . . . 8
Modèle de transfert d'étiquettes pour les LSR Diff-Serv et modèles de tunnelisation . . . . . . . . . . . . . . . . . . . . 9 2.1 Modèle de transfert d'étiquettes pour les LSR Diff-Serv . . . . 9 2.2 Détermination du PHB entrant . . . . . . . . . . . . . . . . .10 2.3 Détermination du PHB sortant avec conditionnement de trafic optionnel . . . . . . . . . . . . . . . . . . . . . . . . . . .11 2.4 Transfert d'étiquettes . . . . . . . . . . . . . . . . . . . .11 2.5 Codage des informations Diff-Serv dans la couche d'encapsulation . . . . . . . . . . . . . . . . . . . . . . . .13 2.6 Modèles de tunnelisation Diff-Serv sur MPLS . . . . . . . . . .13
Fonctionnement détaillé des E-LSP . . . . . . . . . . . . . . .22 3.1 Définition des E-LSP . . . . . . . . . . . . . . . . . . . . .22 3.2 Remplissage du mappage Encaps-->PHB' pour un E-LSP entrant . .23 3.3 Détermination du PHB entrant sur un E-LSP entrant . . . . . . .23 3.4 Remplissage de l'ensemble de mappages PHB-->Encaps' pour un E-LSP sortant . . . . . . . . . . . . . . . . . . . . . . . . .24 3.5 Codage des informations Diff-Serv dans la couche d'encapsulation sur un E-LSP sortant . . . . . . . . . . . . .26 3.6 Fusion d'E-LSP . . . . . . . . . . . . . . . . . . . . . . . .27
Fonctionnement détaillé des L-LSP . . . . . . . . . . . . . . .28 4.1 Définition des L-LSP . . . . . . . . . . . . . . . . . . . . .28 4.2 Remplissage du mappage Encaps-->PHB' pour un L-LSP entrant . .28 4.3 Détermination du PHB entrant sur un L-LSP entrant . . . . . . .30 4.4 Remplissage de l'ensemble de mappages PHB-->Encaps' pour un L-LSP sortant . . . . . . . . . . . . . . . . . . . . . . . . .31 4.5 Codage des informations Diff-Serv dans la couche d'encapsulation sur un L-LSP sortant . . . . . . . . . . . . .33 4.6 Fusion de L-LSP . . . . . . . . . . . . . . . . . . . . . . . .34
Extension RSVP pour la prise en charge de Diff-Serv . . . . . .34 5.1 Format des messages RSVP liés à Diff-Serv . . . . . . . . . . .34 5.2 Objet DIFFSERV . . . . . . . . . . . . . . . . . . . . . . . .35 5.3 Traitement de l'objet DIFFSERV . . . . . . . . . . . . . . . .37 5.4 Non-prise en charge de l'objet DIFFSERV . . . . . . . . . . . .40 5.5 Codes d'erreur pour Diff-Serv . . . . . . . . . . . . . . . . .40 5.6 Type de service Intserv . . . . . . . . . . . . . . . . . . . .41
Extensions LDP pour la prise en charge de Diff-Serv . . . . . .41 6.1 TLV Diff-Serv . . . . . . . . . . . . . . . . . . . . . . . . .42 6.2 Valeurs de code d'état Diff-Serv . . . . . . . . . . . . . . .44 6.3 Messages LDP liés à Diff-Serv . . . . . . . . . . . . . . . . .44 6.4 Traitement de la TLV Diff-Serv . . . . . . . . . . . . . . . .46 6.5 Non-traitement de la TLV Diff-Serv . . . . . . . . . . . . . .49 6.6 Informations de bande passante . . . . . . . . . . . . . . . .49
Prise en charge MPLS de Diff-Serv sur les interfaces PPP, LAN, Non-LC-ATM et Non-LC-FR . . . . . . . . . . . . . . . . . . . .49
Prise en charge MPLS de Diff-Serv sur les interfaces LC-ATM . .50 8.1 Utilisation des classes de trafic ATM et des mécanismes de gestion de trafic . . . . . . . . . . . . . . . . . . . . . . .50 8.2 Mise en œuvre de LSR avec interfaces LC-ATM . . . . . . . . . .50
Prise en charge MPLS de Diff-Serv sur les interfaces LC-FR . . .51 9.1 Utilisation des paramètres de trafic Frame Relay et des mécanismes de gestion de trafic . . . . . . . . . . . . . . . .51 9.2 Mise en œuvre de LSR avec interfaces LC-FR . . . . . . . . . .51
Considérations IANA . . . . . . . . . . . . . . . . . . . . . .52
Considérations de sécurité . . . . . . . . . . . . . . . . . .52
Remerciements . . . . . . . . . . . . . . . . . . . . . . . . .52 ANNEXE A. Exemples de scénarios de déploiement . . . . . . . . . .53 ANNEXE B. Exemples de scénarios de réservation de bande passante .58 Références . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 Adresses des auteurs . . . . . . . . . . . . . . . . . . . . . . .62 Déclaration complète de droit d'auteur . . . . . . . . . . . . . .64

1. Introduction

Dans un domaine MPLS [MPLS_ARCH], lorsqu'un flux de données traverse un chemin commun, un chemin à commutation d'étiquettes (Label Switched Path, LSP) peut être établi à l'aide de protocoles de signalisation MPLS. Au niveau du routeur de commutation d'étiquettes d'entrée (ingress Label Switch Router, LSR), chaque paquet se voit attribuer une étiquette et est transmis en aval. À chaque LSR le long du LSP, l'étiquette est utilisée pour transférer le paquet vers le saut suivant.

Dans un domaine de services différenciés (Differentiated Service, Diff-Serv) [DIFF_ARCH], tous les paquets IP traversant un lien et nécessitant le même comportement Diff-Serv sont dits constituer un agrégat de comportement (Behavior Aggregate, BA). Au nœud d'entrée du domaine Diff-Serv, les paquets sont classés et marqués avec un point de code Diff-Serv (Diff-Serv Code Point, DSCP) qui correspond à leur agrégat de comportement. À chaque nœud de transit, le DSCP est utilisé pour sélectionner le comportement par saut (Per Hop Behavior, PHB) qui détermine le traitement d'ordonnancement et, dans certains cas, la probabilité de rejet pour chaque paquet.

Ce document spécifie une solution pour prendre en charge les agrégats de comportement Diff-Serv dont les PHB correspondants sont actuellement définis (dans [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) sur un réseau MPLS. Cette solution offre également une flexibilité pour une prise en charge aisée des PHB qui pourraient être définis à l'avenir.

Cette solution repose sur l'utilisation combinée de deux types de LSP :

des LSP qui peuvent transporter plusieurs agrégats ordonnés (Ordered Aggregates), de sorte que le champ EXP de l'en-tête MPLS Shim transmet au LSR le PHB à appliquer au paquet (couvrant à la fois les informations sur le traitement d'ordonnancement du paquet et sa priorité de rejet) ;
des LSP qui ne transportent qu'un seul agrégat ordonné, de sorte que le traitement d'ordonnancement du paquet est déduit par le LSR exclusivement à partir de la valeur de l'étiquette du paquet, tandis que la priorité de rejet du paquet est transmise dans le champ EXP de l'en-tête MPLS Shim ou dans le mécanisme de rejet sélectif spécifique à la couche de liaison d'encapsulation (ATM, Frame Relay, 802.1).

Comme mentionné dans [DIFF_HEADER], « les fournisseurs de services ne sont pas tenus d'utiliser les mêmes mécanismes ou configurations de nœuds pour permettre la différenciation de service au sein de leurs réseaux, et sont libres de configurer les paramètres des nœuds de la manière qui convient à leurs offres de service et à leurs objectifs d'ingénierie de trafic ». Ainsi, la solution définie dans ce document donne aux fournisseurs de services la flexibilité de choisir comment les classes de service Diff-Serv sont routées ou soumises à l'ingénierie de trafic au sein de leur domaine (par exemple, des classes de service distinctes prises en charge via des LSP distincts et routées séparément, toutes les classes de service prises en charge sur le même LSP et routées ensemble).

Parce que MPLS est orienté chemin, il peut potentiellement fournir des capacités de protection et de restauration plus rapides et plus prévisibles face aux changements de topologie que les systèmes IP routés conventionnels saut par saut. Dans ce document, nous désignons de telles capacités sous le nom de « protection MPLS ». Bien que de telles capacités et les mécanismes associés soient hors du champ d'application de cette spécification, nous notons qu'elles peuvent offrir différents niveaux de protection à différents LSP. Étant donné que la solution présentée ici permet aux fournisseurs de services de choisir comment les classes de service Diff-Serv sont mappées sur les LSP, la solution donne également aux fournisseurs de services de la flexibilité quant au niveau de protection fourni aux différentes classes de service Diff-Serv (par exemple, certaines classes de service peuvent être prises en charge par des LSP qui sont protégés tandis que d'autres classes de service sont prises en charge par des LSP qui ne sont pas protégés).

En outre, la solution spécifiée dans ce document réalise une conservation de l'espace d'étiquettes et réduit le volume de signalisation d'établissement/suppression d'étiquettes lorsque cela est possible en ne recourant à plusieurs LSP pour une Forwarding Equivalent Class (FEC) [MPLS_ARCH] donnée que lorsque cela est utile ou requis.

Cette spécification permet la prise en charge des services différenciés pour le trafic IPv4 et IPv6 transporté sur un réseau MPLS. Ce document ne décrit les opérations que pour l'unicast. La prise en charge du multicast est réservée à une étude future.

La solution décrite dans ce document n'empêche pas l'utilisation signalée ou configurée des bits EXP pour prendre en charge la Notification explicite de congestion [ECN] simultanément avec Diff-Serv sur MPLS. Cependant, les techniques pour prendre en charge l'ECN dans un environnement MPLS sont hors du champ d'application de ce document.

1.1 Terminologie

Les mots clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans le RFC 2119.

Le lecteur est supposé être familier avec la terminologie de [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM], [MPLS_FR], y compris ce qui suit :

FEC Forwarding Equivalency Class (classe d'équivalence de transfert)

FTN FEC-To-NHLFE Map (mappage FEC vers NHLFE)

ILM Incoming Label Map (mappage d'étiquette entrante)

LC-ATM Label Switching Controlled-ATM (interface) (interface ATM contrôlée par commutation d'étiquettes)

LC-FR Label Switching Controlled-Frame Relay (interface) (interface Frame Relay contrôlée par commutation d'étiquettes)

LSP Label Switched Path (chemin à commutation d'étiquettes)

LSR Label Switch Router (routeur de commutation d'étiquettes)

MPLS Multi-Protocol Label Switching (commutation multiprotocole par étiquettes)

NHLFE Next Hop Label Forwarding Entry (entrée de transfert d'étiquette vers le saut suivant)

Le lecteur est supposé être familier avec la terminologie de [DIFF_ARCH], [DIFF_HEADER], [DIFF_AF], [DIFF_EF], y compris ce qui suit :

AF Assured Forwarding (transfert assuré)

BA Behavior Aggregate (agrégat de comportement)

CS Class Selector (sélecteur de classe)

DF Default Forwarding (transfert par défaut)

DSCP Differentiated Services Code Point (point de code des services différenciés)

EF Expedited Forwarding (transfert accéléré)

PHB Per Hop Behavior (comportement par saut)

Le lecteur est supposé être familier avec la terminologie de [DIFF_NEW], y compris ce qui suit :

OA Ordered Aggregate (agrégat ordonné). L'ensemble des agrégats de comportement qui partagent une contrainte d'ordonnancement.

PSC PHB Scheduling Class (classe d'ordonnancement PHB). L'ensemble d'un ou plusieurs PHB appliqués aux agrégats de comportement appartenant à un OA donné. Par exemple, AF1x est un PSC comprenant les PHB AF11, AF12 et AF13. EF est un exemple de PSC comprenant un seul PHB, le PHB EF.

Les acronymes suivants sont également utilisés :

CLP Cell Loss Priority (priorité de perte de cellule)

DE Discard Eligibility (éligibilité au rejet)

SNMP Simple Network Management Protocol

Enfin, les acronymes suivants sont définis dans cette spécification :

E-LSP EXP-Inferred-PSC LSP (LSP à PSC déduit du champ EXP)

L-LSP Label-Only-Inferred-PSC LSP (LSP à PSC déduit uniquement de l'étiquette)

1.2 LSP à PSC déduit du champ EXP (E-LSP)

Un seul LSP peut être utilisé pour prendre en charge un ou plusieurs OA. De tels LSP peuvent prendre en charge jusqu'à huit BA d'une FEC donnée, quel que soit le nombre d'OA que ces BA couvrent. Avec de tels LSP, le champ EXP de l'en-tête MPLS Shim est utilisé par le LSR pour déterminer le PHB à appliquer au paquet. Cela inclut à la fois le PSC et la préférence de rejet.

Nous appelons ces LSP « LSP à PSC déduit du champ EXP » (EXP-inferred- PSC LSPs, E-LSP), car le PSC d'un paquet transporté sur ce LSP dépend de la valeur du champ EXP pour ce paquet.

Le mappage du champ EXP vers le PHB (c'est-à-dire vers le PSC et la priorité de rejet) pour un tel LSP donné est soit explicitement signalé lors de l'établissement de l'étiquette, soit s'appuie sur un mappage préconfiguré.

Le fonctionnement détaillé des E-LSP est spécifié à la section 3 ci-dessous.

1.3 LSP à PSC déduit uniquement de l'étiquette (L-LSP)

Un LSP distinct peut être établi pour une paire unique <FEC, OA>. Avec de tels LSP, le PSC est explicitement signalé au moment de l'établissement de l'étiquette, de sorte qu'après l'établissement de l'étiquette, le LSR peut déduire exclusivement de la valeur de l'étiquette le PSC à appliquer à un paquet étiqueté. Lorsque l'en-tête Shim est utilisé, la priorité de rejet (Drop Precedence) à appliquer par le LSR au paquet étiqueté est transmise à l'intérieur de l'en-tête MPLS Shim du paquet étiqueté en utilisant le champ EXP. Lorsque l'en-tête Shim n'est pas utilisé (par exemple, MPLS over ATM), la priorité de rejet à appliquer par le LSR au paquet étiqueté est transmise à l'intérieur de l'encapsulation d'en-tête de la couche de liaison en utilisant des champs de priorité de rejet spécifiques à la couche de liaison (par exemple, ATM CLP).

Nous appelons ces LSP « LSP à PSC déduit uniquement de l'étiquette » (Label-Only-Inferred-PSC LSPs, L-LSP) car le PSC peut être entièrement déduit de l'étiquette sans aucune autre information (par exemple, indépendamment de la valeur du champ EXP). Le fonctionnement détaillé des L-LSP est spécifié à la section 4 ci-dessous.

1.4 Fonctionnement global

Pour une FEC donnée, et sauf si des restrictions spécifiques au média s'appliquent comme identifié aux sections 7, 8 et 9 ci-dessous, cette spécification permet n'importe laquelle des combinaisons suivantes au sein d'un domaine MPLS Diff-Serv :

zéro ou un nombre quelconque d'E-LSP, et
zéro ou un nombre quelconque de L-LSP.

L'administrateur réseau sélectionne la combinaison réelle de LSP parmi l'ensemble des combinaisons autorisées et sélectionne comment les agrégats de comportement sont effectivement transportés sur cette combinaison de LSP, afin de mieux correspondre à son environnement et à ses objectifs en termes de prise en charge Diff-Serv, d'ingénierie de trafic et de protection MPLS. Les critères pour sélectionner une telle combinaison sont hors du champ d'application de cette spécification.

Pour une FEC donnée, il peut y avoir plus d'un LSP transportant le même OA, par exemple à des fins d'équilibrage de charge de l'OA ; cependant, afin de respecter les contraintes d'ordonnancement, tous les paquets d'un microflux donné, s'étendant éventuellement sur plusieurs BA d'un agrégat ordonné donné, MUST être transportés sur le même LSP. Inversement, chaque LSP MUST être capable de prendre en charge tous les BA (actifs) d'un OA donné.

Des exemples de scénarios de déploiement sont fournis à titre d'information dans l'ANNEXE A.

1.5 Relation entre étiquette et FEC

[MPLS_ARCH] indique à la section « 2.1. Overview » que : « Certains routeurs analysent l'en-tête de la couche réseau d'un paquet non seulement pour choisir le saut suivant du paquet, mais aussi pour déterminer la « precedence » ou la « class of service » d'un paquet. Ils peuvent alors appliquer différents seuils de rejet ou disciplines d'ordonnancement à différents paquets. MPLS permet (mais n'exige pas) que la precedence ou la class of service soit entièrement ou partiellement déduite de l'étiquette. Dans ce cas, on peut dire que l'étiquette représente la combinaison d'une FEC et d'une precedence ou class of service. »

Conformément à cela, nous observons que :

Avec les E-LSP, l'étiquette représente la combinaison d'une FEC et de l'ensemble des BA transportés sur l'E-LSP. Lorsque tous les BA pris en charge sont transportés sur un E-LSP, l'étiquette représente alors la FEC complète.
Avec les L-LSP, l'étiquette représente la combinaison d'une FEC et d'un OA.

1.6 Réservation de bande passante pour les E-LSP et L-LSP

Indépendamment du protocole de liaison d'étiquette utilisé, les E-LSP et L-LSP peuvent être établis avec ou sans réservation de bande passante.

Établir un E-LSP ou un L-LSP avec réservation de bande passante signifie que les exigences de bande passante pour le LSP sont signalées au moment de l'établissement du LSP. De telles exigences de bande passante signalées peuvent être utilisées par les LSR au moment de l'établissement pour effectuer un contrôle d'admission du LSP signalé sur les ressources Diff-Serv provisionnées (par exemple, via la configuration, SNMP ou des protocoles de politique) pour le(s) PSC pertinent(s). De telles exigences de bande passante signalées peuvent également être utilisées par les LSR au moment de l'établissement pour effectuer un ajustement des ressources Diff-Serv associées au(x) PSC pertinent(s) (par exemple, ajuster le poids d'ordonnancement du PSC).

Notez qu'établir un E-LSP ou un L-LSP avec réservation de bande passante ne signifie pas qu'un ordonnancement par LSP est requis. Étant donné que les E-LSP et L-LSP sont spécifiés dans ce document pour la prise en charge des services différenciés, le traitement de transfert requis (ordonnancement et politique de rejet) est défini par le PHB Diff-Serv approprié. Ce traitement de transfert MUST être appliqué par le LSR à la granularité du BA et MUST être conforme à la spécification PHB pertinente.

Lorsque des exigences de bande passante sont signalées à l'établissement d'un L-LSP, la bande passante signalée est manifestement associée au PSC du L-LSP. Ainsi, les LSR qui utilisent la bande passante signalée pour effectuer un contrôle d'admission peuvent effectuer un contrôle d'admission sur des ressources Diff-Serv qui sont dédiées au PSC (par exemple, sur la bande passante garantie au PSC par son poids d'ordonnancement).

Lorsque des exigences de bande passante sont signalées à l'établissement d'un E-LSP, la bande passante signalée est associée collectivement à l'ensemble du LSP et donc à l'ensemble des PSC transportés. Ainsi, les LSR qui utilisent la bande passante signalée pour effectuer un contrôle d'admission peuvent effectuer un contrôle d'admission sur des ressources globales, qui sont partagées par l'ensemble des PSC (par exemple, sur la bande passante totale du lien).

Des exemples de scénarios où la réservation de bande passante n'est pas utilisée et de scénarios où la réservation de bande passante est utilisée sont fournis à titre d'information dans l'ANNEXE B.

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 :

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

o 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.

3. Fonctionnement détaillé des E-LSP

3.1 Définition des E-LSP

Les E-LSP sont définis à la section 1.2.

Au sein d'un domaine MPLS Diff-Serv donné, tous les E-LSP s'appuyant sur le mappage préconfiguré sont capables de transporter le même ensemble commun de 8 BA, ou moins. Chacun de ces E-LSP peut effectivement transporter cet ensemble complet de BA ou n'importe quel sous-ensemble arbitraire de celui-ci.

Pour une FEC donnée, deux E-LSP donnés utilisant un mappage `EXP<-->PHB' signalé peuvent prendre en charge les mêmes ensembles d'agrégats ordonnés ou des ensembles différents.

3.2 Remplissage du mappage `Encaps-->PHB' pour un E-LSP entrant

Cette section définit comment le mappage `Encaps-->PHB' du contexte Diff-Serv est peuplé pour un E-LSP entrant afin de permettre la détermination du PHB entrant.

Le mappage Encaps-->PHB' pour un E-LSP est toujours de la forme EXP-->PHB mapping'.

Si l'étiquette correspond à un E-LSP pour lequel aucun mappage EXP<-->PHB' n'a été explicitement signalé lors de l'établissement du LSP, le mappage EXP-->PHB' est peuplé sur la base 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, le mappage EXP-->PHB' est peuplé conformément au mappage `EXP<-->PHB' signalé.

3.2.1 Mappage `EXP<-->PHB' préconfiguré

Les LSR prenant en charge les E-LSP qui utilisent le mappage EXP<-->PHB' préconfiguré doivent permettre la configuration locale de ce mappage EXP<-->PHB'. Ce mappage s'applique à tous les E-LSP établis sur ce LSR sans mappage explicitement signalé au moment de l'établissement.

Le mappage `EXP<-->PHB' préconfiguré doit soit être cohérent à chaque saut d'E-LSP à travers le domaine MPLS Diff-Serv traversé par le LSP, soit un remarque approprié du champ EXP doit être effectué par le LSR chaque fois qu'un mappage préconfiguré différent est utilisé sur les interfaces d'entrée et de sortie.

Dans le cas où le mappage EXP<-->PHB' préconfiguré n'a pas effectivement été configuré par l'administrateur réseau, le LSR devrait utiliser un mappage EXP<-->PHB' préconfiguré par défaut qui mappe toutes les valeurs EXP vers le PHB Default.

3.3 Détermination du PHB entrant sur un E-LSP entrant

Cette section définit comment la détermination du PHB entrant est effectuée lorsque l'entrée d'étiquette considérée dans la pile d'étiquettes reçue correspond à un E-LSP. Cela exige que le mappage `Encaps-->PHB' soit peuplé comme défini à la section 3.2.

Lorsqu'il considère une entrée d'étiquette correspondant à un E-LSP entrant pour la détermination du PHB entrant, le LSR :

détermine le mappage EXP-->PHB' en consultant le mappage Encaps-->PHB' du contexte Diff-Serv associé dans l'ILM avec l'étiquette E-LSP entrante considérée.
détermine le PHB entrant en consultant le champ EXP de l'entrée d'étiquette considérée dans la table de mappage `EXP-->PHB'.

3.4 Remplissage de l'ensemble de mappages `PHB-->Encaps' pour un E-LSP sortant

Cette section définit comment l'ensemble de mappages `PHB-->Encaps' du contexte Diff-Serv est peuplé lors de l'établissement de l'étiquette pour un E-LSP sortant afin de permettre le codage des informations Diff-Serv dans la couche d'encapsulation.

3.4.1 Mappage `PHB-->EXP'

Un E-LSP sortant doit toujours avoir un mappage PHB-->EXP' comme partie de l'ensemble de mappages PHB-->Encaps' de son contexte Diff-Serv.

Si l'étiquette correspond à un E-LSP pour lequel aucun mappage EXP<-->PHB' n'a été explicitement signalé lors de l'établissement du LSP, ce mappage PHB-->EXP' est peuplé sur la base du mappage `EXP<-->PHB' préconfiguré qui est discuté ci-dessus à 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, le mappage PHB-->EXP' est peuplé conformément au mappage `EXP<-->PHB' signalé.

3.4.2 Mappage `PHB-->CLP'

Si le LSP sort sur une interface ATM qui n'est pas contrôlée par commutation d'étiquettes, alors un mappage PHB-->CLP' est ajouté à l'ensemble de mappages PHB-->Encaps' pour ce LSP sortant. Ce mappage `PHB-->CLP' est peuplé de la manière suivante :

il est fonction des PHB pris en charge sur ce LSP, et peut utiliser les entrées de mappage pertinentes pour ces PHB à partir du mappage `PHB-->CLP' par défaut défini à la section 3.4.2.1. Des mappages autres que celui défini à la section 3.4.2.1 peuvent être utilisés. En particulier, si un mappage des PHB vers CLP est normalisé à l'avenir pour le fonctionnement de Diff-Serv sur ATM, un tel mappage normalisé peut alors être utilisé.

Par exemple, si l'étiquette sortante correspond à un LSP prenant en charge le PSC AF1, alors le mappage `PHB-->CLP' peut être peuplé avec :

      PHB                CLP Field

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

Notez que dans ce cas l'ensemble de mappages PHB-->Encaps' contient à la fois un mappage PHB-->EXP' et un mappage `PHB-->CLP'.

3.4.2.1 Mappage `PHB-->CLP' par défaut

      PHB                CLP Bit

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

3.4.3 Mappage `PHB-->DE'

Si le LSP sort sur une interface Frame Relay qui n'est pas contrôlée par commutation d'étiquettes, un mappage PHB-->DE' est ajouté à l'ensemble de mappages PHB-->Encaps' pour ce LSP sortant et est peuplé de la manière suivante :

il est fonction des PHB pris en charge sur ce LSP, et peut utiliser les entrées de mappage pertinentes pour ces PHB à partir du mappage `PHB-->DE' par défaut défini à la section 3.4.3.1. Des mappages autres que celui défini à la section 3.4.3.1 peuvent être utilisés. En particulier, si un mappage des PHB vers DE est normalisé à l'avenir pour le fonctionnement de Diff-Serv sur Frame Relay, un tel mappage normalisé peut alors être utilisé.

Notez que dans ce cas l'ensemble de mappages PHB-->Encaps' contient à la fois un mappage PHB-->EXP' et un mappage `PHB-->DE'.

3.4.3.1 Mappage `PHB-->DE' par défaut

      PHB                 DE Bit

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

3.4.4 Mappage `PHB-->802.1'

Si le LSP sort sur une interface LAN sur laquelle plusieurs classes de trafic 802.1 sont prises en charge conformément à [IEEE_802.1], alors un mappage PHB-->802.1' est ajouté à l'ensemble de mappages PHB-->Encaps' pour ce LSP sortant. Ce mappage `PHB-->802.1' est peuplé de la manière suivante :

il est fonction des PHB pris en charge sur ce LSP, et utilise les entrées de mappage pertinentes pour ces PHB à partir du mappage `PHB-->802.1' préconfiguré défini à la section 3.4.4.1.

Notez que l'ensemble de mappages PHB-->Encaps' contient alors à la fois un mappage PHB-->EXP' et un mappage `PHB-->802.1'.

3.4.4.1 Mappage `PHB-->802.1' préconfiguré

Au moment de la production de cette spécification, il n'existe pas de mappage normalisé des PHB vers les classes de trafic 802.1. Par conséquent, un LSR prenant en charge plusieurs classes de trafic 802.1 sur des interfaces LAN doit permettre la configuration locale d'un mappage `PHB-->802.1'. Ce mappage s'applique à tous les LSP sortants établis par le LSR sur de telles interfaces LAN.

3.5 Codage des informations Diff-Serv dans la couche d'encapsulation sur un E-LSP sortant

Cette section définit comment coder les informations Diff-Serv dans la couche d'encapsulation MPLS pour une entrée d'étiquette transmise donnée correspondant à un E-LSP sortant. Cela exige que l'ensemble de mappages `PHB-->Encaps' soit peuplé comme défini à la section 3.4.

Le LSR détermine d'abord l'ensemble de mappages `PHB-->Encaps' du contexte Diff-Serv associé à l'étiquette correspondante dans la NHLFE.

3.5.1 Mappage `PHB-->EXP'

Si l'ensemble de mappages PHB-->Encaps' contient un mappage de la forme PHB-->EXP mapping', alors le LSR :

détermine la valeur à écrire dans le champ EXP de l'entrée d'étiquette de niveau correspondant en consultant le « PHB sortant » dans cette table de mappage `PHB-->EXP'.

3.5.2 Mappage `PHB-->CLP'

Si l'ensemble de mappages PHB-->Encaps' contient un mappage de la forme PHB-->CLP mapping', alors le LSR :

détermine la valeur à écrire dans le champ CLP de l'en-tête d'encapsulation ATM, en consultant le « PHB sortant » dans cette table de mappage `PHB-->CLP'.

3.5.3 Mappage `PHB-->DE'

Si l'ensemble de mappages PHB-->Encaps' contient un mappage de la forme PHB-->DE mapping', alors le LSR :

détermine la valeur à écrire dans le champ DE de l'en-tête d'encapsulation Frame Relay, en consultant le « PHB sortant » dans cette table de mappage `PHB-->DE'.

3.5.4 Mappage `PHB-->802.1'

Si l'ensemble de mappages PHB-->Encaps' contient un mappage de la forme PHB-->802.1 mapping', alors le LSR :

détermine la valeur à écrire dans le champ User_Priority des informations de contrôle de balise (Tag Control Information) de l'en-tête d'encapsulation 802.1 [IEEE_802.1], en consultant le « PHB sortant » dans cette table de mappage `PHB-->802.1'.

3.6 Fusion d'E-LSP

Dans un domaine MPLS, deux ou plusieurs LSP peuvent être fusionnés en un LSP au niveau d'un LSR. Les E-LSP sont compatibles avec la fusion de LSP sous la condition suivante :

Les E-LSP ne peuvent être fusionnés en un seul LSP que s'ils prennent en charge exactement le même ensemble de BA.

Pour les E-LSP utilisant un mappage `EXP<-->PHB' signalé, la condition de fusion ci-dessus MUST être appliquée par les LSR par une vérification explicite lors de l'établissement de l'étiquette que exactement le même ensemble de PHB est pris en charge sur les LSP fusionnés.

Pour les E-LSP utilisant le mappage EXP<-->PHB' préconfiguré, étant donné que les PHB pris en charge sur un E-LSP ne sont pas signalés au moment de l'établissement, un LSR ne peut pas s'appuyer sur les informations de signalisation pour appliquer la fusion ci-dessus. Cependant, tous les E-LSP utilisant le mappage EXP<-->PHB' préconfiguré sont tenus de prendre en charge le même ensemble d'agrégats de comportement au sein d'un domaine MPLS Diff-Serv donné. Ainsi, la fusion d'E-LSP utilisant le mappage `EXP<-->PHB' préconfiguré est autorisée au sein d'un domaine MPLS Diff-Serv donné.

4. Fonctionnement détaillé des L-LSP

4.1 Définition des L-LSP

Les L-LSP sont définis à la section 1.3.

4.2 Remplissage du mappage `Encaps-->PHB' pour un L-LSP entrant

Cette section définit comment le mappage `Encaps-->PHB' du contexte Diff-Serv est peuplé lors de l'établissement de l'étiquette pour un L-LSP entrant afin de permettre la détermination du PHB entrant.

4.2.1 Mappage `EXP-->PHB'

Si le LSR termine la couche MPLS Shim sur ce L-LSP entrant et que le L-LSP entre sur une interface qui n'est ni ATM ni Frame Relay, alors le mappage `Encaps-->PHB' est peuplé de la manière suivante :

il s'agit en fait d'un mappage `EXP-->PHB'
ce mappage est fonction du PSC qui est transporté sur ce LSP, et doit utiliser les entrées de mappage pertinentes pour ce PSC à partir du mappage `EXP/PSC-->PHB' obligatoire défini à la section 4.2.1.1.

Par exemple, si l'étiquette entrante correspond à un L-LSP prenant en charge le PSC AF1, alors le mappage `Encaps-->PHB' sera peuplé avec :

   EXP Field              PHB

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

Un LSR prenant en charge les L-LSP sur des interfaces PPP et des interfaces LAN est un exemple de LSR terminant la couche Shim sur des interfaces d'entrée qui ne sont ni ATM ni Frame Relay.

Si le LSR termine la couche MPLS Shim sur ce L-LSP entrant et que le L-LSP entre sur une interface ATM ou Frame Relay, alors le mappage `Encaps-->PHB' est peuplé de la manière suivante :

il devrait en fait s'agir d'un mappage EXP-->PHB'. Des manières optionnelles alternatives de peupler le mappage Encaps-->PHB' pourraient être définies à l'avenir (par exemple, en utilisant un mappage 'CLP/EXP--> PHB' ou un mappage 'DE/EXP-->PHB') mais sont hors du champ d'application de ce document.
lorsque le mappage Encaps-->PHB' est un mappage EXP-->PHB', ce mappage EXP-->PHB' est fonction du PSC qui est transporté sur le L-LSP, et doit utiliser les entrées de mappage pertinentes pour ce PSC à partir du mappage EXP/PSC-->PHB' obligatoire défini à la section 4.2.1.1.

Un Edge-LSR d'un domaine ATM-MPLS ou d'un domaine FR-MPLS est un exemple de LSR terminant la couche shim sur une interface ATM/FR d'entrée.

4.2.1.1 Mappage `EXP/PSC --> PHB' obligatoire

   EXP Field      PSC             PHB

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

4.2.2 Mappage `CLP-->PHB'

Si le LSR ne termine pas une couche MPLS Shim sur cette étiquette entrante et utilise l'encapsulation ATM (c'est-à-dire qu'il s'agit d'un ATM-LSR), alors le mappage `Encaps-->PHB' pour ce L-LSP entrant est peuplé de la manière suivante :

il s'agit en fait d'un mappage `CLP-->PHB'
le mappage est fonction du PSC, qui est transporté sur ce LSP, et devrait utiliser les entrées de mappage pertinentes pour ce PSC à partir du mappage `CLP/PSC-->PHB' par défaut défini à la section 4.2.2.1.

Par exemple, si l'étiquette entrante correspond à un L-LSP prenant en charge le PSC AF1, alors le mappage `Encaps-->PHB' devrait être peuplé avec :

   CLP Field              PHB

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

4.2.2.1 Mappage `CLP/PSC --> PHB' par défaut

   CLP Bit      PSC             PHB

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

4.2.3 Mappage `DE-->PHB'

Si le LSR ne termine pas une couche MPLS Shim sur cette étiquette entrante et utilise l'encapsulation Frame Relay (c'est-à-dire qu'il s'agit d'un FR-LSR), alors le mappage `Encaps-->PHB' pour ce L-LSP entrant est peuplé de la manière suivante :

il s'agit en fait d'un mappage `DE-->PHB'
le mappage est fonction du PSC qui est transporté sur ce LSP, et devrait utiliser les entrées de mappage pertinentes pour ce PSC à partir du mappage `DE/PSC-->PHB' par défaut défini à la section 4.2.3.1.

4.2.3.1 Mappage `DE/PSC --> PHB' par défaut

   DE Bit      PSC             PHB

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

4.3 Détermination du PHB entrant sur un L-LSP entrant

Cette section définit comment la détermination du PHB entrant est effectuée lorsque l'entrée d'étiquette considérée dans la pile d'étiquettes reçue correspond à un L-LSP. Cela exige que le mappage `Encaps-->PHB' soit peuplé comme défini à la section 4.2.

Lorsqu'il considère une entrée d'étiquette correspondant à un L-LSP entrant pour la détermination du PHB entrant, le LSR détermine d'abord le mappage `Encaps-->PHB' associé à l'étiquette correspondante.

4.3.1 Mappage `EXP-->PHB'

Si le mappage Encaps-->PHB' est de la forme EXP-->PHB mapping', alors le LSR :

détermine le PHB entrant en regardant le champ EXP de l'entrée d'étiquette considérée et en utilisant le mappage `EXP-->PHB'.

4.3.2 Mappage `CLP-->PHB'

Si le mappage Encaps-->PHB' est de la forme CLP-->PHB mapping', alors le LSR :

détermine le PHB entrant en regardant le champ CLP de l'encapsulation de la couche ATM et en utilisant le mappage `CLP-->PHB'.

4.3.3 Mappage `DE-->PHB'

Si le mappage Encaps-->PHB' est de la forme DE-->PHB mapping', alors le LSR :

détermine le PHB entrant en regardant le champ DE de l'encapsulation Frame Relay et en utilisant le mappage `DE-->PHB'.

4.4 Remplissage de l'ensemble de mappages `PHB-->Encaps' pour un L-LSP sortant

Cette section définit comment l'ensemble de mappages `PHB-->Encaps' du contexte Diff-Serv est peuplé lors de l'établissement de l'étiquette pour un L-LSP sortant afin de permettre le codage des informations Diff-Serv.

4.4.1 Mappage `PHB-->EXP'

Si le LSR utilise une couche MPLS Shim sur ce L-LSP sortant, alors un mappage PHB-->EXP' est ajouté à l'ensemble de mappages PHB-->Encaps' pour ce L-LSP sortant. Ce mappage `PHB-->EXP' est peuplé de la manière suivante :

il est fonction du PSC pris en charge sur ce LSP, et doit utiliser les entrées de mappage pertinentes pour ce PSC à partir du mappage `PHB-->EXP' obligatoire défini à la section 4.4.1.1.

Par exemple, si l'étiquette sortante correspond à un L-LSP prenant en charge le PSC AF1, alors le mappage PHB-->EXP' suivant est ajouté dans l'ensemble de mappages PHB-->Encaps' :

      PHB                EXP Field

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

4.4.1.1 Mappage `PHB-->EXP' obligatoire

      PHB                EXP Field

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

4.4.2 Mappage `PHB-->CLP'

Si le L-LSP sort sur une interface ATM (c'est-à-dire qu'il s'agit d'un ATM-LSR ou d'un LSR basé trame envoyant des paquets sur une interface LC-ATM ou sur une interface ATM qui n'est pas contrôlée par commutation d'étiquettes), alors un mappage PHB-->CLP' est ajouté à l'ensemble de mappages PHB-->Encaps' pour ce L-LSP sortant.

Si le L-LSP sort sur une interface ATM qui n'est pas contrôlée par étiquettes, le mappage `PHB-->CLP' est peuplé conformément à la section 3.4.2.

Si le L-LSP sort sur une interface LC-ATM, le mappage `PHB-->CLP' est peuplé de la manière suivante :

il est fonction du PSC pris en charge sur ce LSP, et devrait utiliser les entrées de mappage pertinentes pour ce PSC à partir du mappage `PHB-->CLP' par défaut défini à la section 3.4.2.1.

Notez que si le LSR est un LSR basé trame prenant en charge un L-LSP sortant sur une interface ATM, alors l'ensemble de mappages PHB-->Encaps' contient à la fois un mappage PHB-->EXP' et un mappage PHB-->CLP'. Si le LSR est un ATM-LSR prenant en charge un L-LSP, alors l'ensemble de mappages PHB-->Encaps' ne contient qu'un mappage `PHB-->CLP'.

4.4.3 Mappage `PHB-->DE'

Si le L-LSP sort sur une interface Frame Relay (c'est-à-dire qu'il s'agit d'un LSR envoyant des paquets sur une interface LC-FR ou sur une interface Frame Relay qui n'est pas contrôlée par commutation d'étiquettes), un mappage PHB-->DE' est ajouté à l'ensemble de mappages PHB-->Encaps' pour ce L-LSP sortant.

Si le L-LSP sort sur une interface FR qui n'est pas contrôlée par commutation d'étiquettes, le mappage `PHB-->DE' est peuplé conformément à la section 3.4.3.

Si le L-LSP sort sur une interface LC-FR, le mappage `PHB-->DE' est peuplé de la manière suivante :

il est fonction du PSC pris en charge sur ce LSP, et devrait utiliser les entrées de mappage pertinentes pour ce PSC à partir du mappage `PHB-->DE' par défaut défini à la section 3.4.3.1.

Notez que si le LSR est un Edge-LSR prenant en charge un L-LSP sortant sur une interface LC-FR, alors l'ensemble de mappages PHB-->Encaps' contient à la fois un mappage PHB-->EXP' et un mappage PHB-->DE'. Si le LSR est un FR-LSR prenant en charge un L-LSP, alors l'ensemble de mappages PHB-->Encaps' ne contient qu'un mappage `PHB-->DE'.

4.4.4 Mappage `PHB-->802.1'

Si le LSP sort sur une interface LAN sur laquelle plusieurs classes de trafic 802.1 sont prises en charge, comme défini dans [IEEE_802.1], alors un mappage `PHB-->802.1' est ajouté conformément à la section 3.4.4.

4.5 Codage des informations Diff-Serv dans la couche d'encapsulation sur un L-LSP sortant

Cette section définit comment coder les informations Diff-Serv dans la couche d'encapsulation MPLS pour une entrée d'étiquette transmise correspondant à un L-LSP sortant. Cela exige que l'ensemble de mappages `PHB-->Encaps' soit peuplé comme défini à la section 4.4.

Le LSR détermine d'abord l'ensemble de mappages `PHB-->Encaps' du contexte Diff-Serv associé à l'étiquette correspondante dans la NHLFE et effectue ensuite le codage correspondant comme spécifié aux sections 3.5.1, 3.5.2, 3.5.3 et 3.5.4.

4.6 Fusion de L-LSP

Dans un domaine MPLS, deux ou plusieurs LSP peuvent être fusionnés en un LSP au niveau d'un LSR. Les L-LSP sont compatibles avec la fusion de LSP sous la condition suivante :

Les L-LSP ne peuvent être fusionnés en un seul L-LSP que s'ils prennent en charge le même PSC.

La condition de fusion ci-dessus MUST être appliquée par les LSR, par une vérification explicite lors de l'établissement de l'étiquette, que le même PSC est pris en charge sur les LSP fusionnés.

Notez que lorsque des L-LSP fusionnent, la bande passante qui est disponible pour le PSC en aval du point de fusion doit être suffisante pour transporter la somme du trafic fusionné. Cela est particulièrement important dans le cas du trafic EF. Cela peut être assuré de multiples manières (par exemple via le provisionnement, ou via la signalisation de bande passante et le contrôle d'admission explicite).

5. Extension RSVP pour la prise en charge de Diff-Serv

L'architecture MPLS n'assume pas un protocole unique de distribution d'étiquettes. [RSVP_MPLS_TE] définit l'extension à RSVP pour établir des LSP dans les réseaux MPLS. Cette section spécifie les extensions à RSVP, au-delà de celles définies dans [RSVP_MPLS_TE], pour établir des LSP prenant en charge les services différenciés dans les réseaux MPLS.

5.1 Format des messages RSVP liés à Diff-Serv

Un nouvel objet RSVP est défini dans ce document : l'objet DIFFSERV. Une description détaillée de cet objet est fournie ci-dessous. Ce nouvel objet est applicable aux messages Path. Cette spécification ne définit l'utilisation de l'objet DIFFSERV que dans les messages Path utilisés pour établir des tunnels LSP conformément à [RSVP_MPLS_TE] et contenant donc un objet Session avec un C-Type égal à LSP_TUNNEL_IPv4 et contenant un objet LABEL_REQUEST.

Les restrictions définies dans [RSVP_MPLS_TE] pour la prise en charge de l'établissement de tunnels LSP via RSVP sont également applicables à l'établissement de tunnels LSP prenant en charge Diff-Serv : par exemple, seuls les LSP unicast sont pris en charge et les LSP multicast sont réservés à une étude future.

Ce nouvel objet DIFFSERV est optionnel par rapport à RSVP de sorte que les implémentations RSVP générales non concernées par l'établissement de LSP MPLS n'ont pas à prendre en charge cet objet.

L'objet DIFFSERV est optionnel pour la prise en charge des tunnels LSP tels que définis dans [RSVP_MPLS_TE]. Un LSR capable Diff-Serv prenant en charge les E-LSP utilisant le mappage EXP<-->PHB' préconfiguré en conformité avec cette spécification MAY prendre en charge l'objet DIFFSERV. Un LSR capable Diff-Serv prenant en charge les E-LSP utilisant un mappage EXP<-->PHB' signalé en conformité avec cette spécification MUST prendre en charge l'objet DIFFSERV. Un LSR capable Diff-Serv prenant en charge les L-LSP en conformité avec cette spécification MUST prendre en charge l'objet DIFFSERV.

5.1.1 Format du message Path

Le format du message Path est le suivant :

      <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 Objet DIFFSERV

Les formats de l'objet DIFFSERV sont présentés ci-dessous. Il existe actuellement deux C_Types possibles. Le type 1 est un objet DIFFSERV pour un E-LSP. Le type 2 est un objet DIFFSERV pour un L-LSP.

5.2.1. Objet DIFFSERV pour un 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 Ce champ est réservé. Il doit être mis à zéro à la transmission et doit être ignoré à la réception.

MAPnb : 4 bits Indique le nombre d'entrées MAP incluses dans l'objet DIFFSERV. Cela peut être mis à n'importe quelle valeur de 0 à 8.

MAP : 32 bits Chaque entrée MAP définit le mappage entre une valeur de champ EXP et un PHB. L'entrée MAP a le format suivant :

    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 Ce champ est réservé. Il doit être mis à zéro à la transmission et doit être ignoré à la réception.

EXP : 3 bits Ce champ contient la valeur du champ EXP pour le mappage `EXP<-->PHB' défini dans cette entrée MAP.

PHBID : 16 bits Ce champ contient le PHBID du PHB pour le mappage `EXP<-->PHB' défini dans cette entrée MAP. Le PHBID est codé comme spécifié dans [PHBID].

5.2.2 Objet DIFFSERV pour un 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 Ce champ est réservé. Il doit être mis à zéro à la transmission et doit être ignoré à la réception.

PSC : 16 bits Le PSC indique une classe d'ordonnancement PHB (PHB Scheduling Class) à prendre en charge par le LSP. Le PSC est codé comme spécifié dans [PHBID].

5.3 Traitement de l'objet DIFFSERV

Pour établir un tunnel LSP avec RSVP, l'expéditeur crée un message Path avec un type de session de LSP_Tunnel_IPv4 et avec un objet LABEL_REQUEST conformément à [RSVP_MPLS_TE].

Pour établir un tunnel E-LSP avec RSVP, qui utilise le mappage `EXP<-->PHB' préconfiguré, l'expéditeur crée un message Path :

avec un type de session de LSP_Tunnel_IPv4,
avec l'objet LABEL_REQUEST, et
sans l'objet DIFFSERV.

Pour établir un tunnel E-LSP avec RSVP, qui utilise le mappage `EXP<-->PHB' préconfiguré, l'expéditeur MAY alternativement créer un message Path :

avec un type de session de LSP_Tunnel_IPv4,
avec l'objet LABEL_REQUEST, et
avec l'objet DIFFSERV pour un E-LSP ne contenant aucune entrée MAP.

Pour établir un tunnel E-LSP avec RSVP, qui utilise un mappage `EXP<-->PHB' signalé, l'expéditeur crée un message Path :

avec un type de session de LSP_Tunnel_IPv4,
avec l'objet LABEL_REQUEST,
avec l'objet DIFFSERV pour un E-LSP contenant une entrée MAP pour chaque valeur EXP à prendre en charge sur cet E-LSP.

Pour établir avec RSVP un tunnel L-LSP, l'expéditeur crée un message Path :

avec un type de session de LSP_Tunnel_IPv4,
avec l'objet LABEL_REQUEST,
avec l'objet DIFFSERV pour un L-LSP contenant la classe d'ordonnancement PHB (PSC) prise en charge sur ce L-LSP.

Si un message path contient plusieurs objets DIFFSERV, seul le premier est significatif ; le(s) objet(s) DIFFSERV suivant(s) doit/doivent être ignoré(s) et non transmis(s).

Chaque LSR le long du chemin enregistre l'objet DIFFSERV, lorsqu'il est présent, dans son bloc d'état de chemin (path state block).

Si un objet DIFFSERV n'est pas présent dans le message Path, le LSR SHOULD interpréter cela comme une demande pour un E-LSP utilisant le mappage `EXP<-->PHB' préconfiguré. Cependant, à des fins de compatibilité ascendante, avec d'autres options de qualité de service non Diff-Serv autorisées par [RSVP_MPLS_TE] telles que Integrated Services Controlled Load ou Guaranteed Services, le LSR MAY prendre en charge une « option de contournement » configurable. Lorsque cette « option de contournement » est configurée, le LSR interprète un message path sans objet Diff-Serv comme une demande pour un LSP avec une telle qualité de service non Diff-Serv.

Si un objet DIFFSERV pour un E-LSP ne contenant aucune entrée MAP est présent dans le message Path, le LSR MUST interpréter cela comme une demande pour un E-LSP utilisant le mappage EXP<-->PHB' préconfiguré. En particulier, cela permet à un LSR avec l'« option de contournement » configurée de prendre en charge des E-LSP avec mappage EXP<-->PHB' préconfiguré, simultanément avec des LSP avec qualité de service non Diff-Serv.

Si un objet DIFFSERV pour un E-LSP contenant au moins une entrée MAP est présent dans le message Path, le LSR MUST interpréter cela comme une demande pour un E-LSP avec mappage `EXP<-->PHB' signalé.

Si un objet DIFFSERV pour un L-LSP est présent dans le message Path, le LSR MUST interpréter cela comme une demande pour un L-LSP.

Le LSR de destination d'un E-LSP ou L-LSP répond au message Path contenant l'objet LABEL_REQUEST en envoyant un message Resv :

avec l'objet LABEL
sans objet DIFFSERV.

En supposant que la demande d'étiquette est acceptée et qu'une étiquette est allouée, les LSR Diff-Serv (expéditeur, destination, nœuds intermédiaires) doivent :

mettre à jour le contexte Diff-Serv associé aux LSP établis dans leur ILM/FTN comme spécifié dans les sections précédentes (étiquette entrante et sortante),
installer le traitement de transfert Diff-Serv requis (comportement d'ordonnancement et de rejet) pour cette NHLFE (étiquette sortante).

Un LSR qui reconnaît l'objet DIFFSERV et qui reçoit un message path qui contient l'objet DIFFSERV mais qui ne contient pas d'objet LABEL_REQUEST ou qui n'a pas un type de session de LSP_Tunnel_IPv4, envoie un PathErr vers l'expéditeur avec le code d'erreur Diff-Serv Error' et une valeur d'erreur de Unexpected DIFFSERV object'. Ceux-ci sont définis ci-dessous à la section 5.5.

Un LSR recevant un message Path avec l'objet DIFFSERV pour E-LSP, qui reconnaît l'objet DIFFSERV mais ne prend pas en charge le PHB particulier codé dans une ou plusieurs des entrées MAP, envoie un PathErr vers l'expéditeur avec le code d'erreur Diff-Serv Error' et une valeur d'erreur de Unsupported PHB'. Ceux-ci sont définis ci-dessous à la section 5.5.

Un LSR recevant un message Path avec l'objet DIFFSERV pour E-LSP, qui reconnaît l'objet DIFFSERV mais détermine que le mappage EXP<-->PHB' signalé est invalide, envoie un PathErr vers l'expéditeur avec le code d'erreur Diff-Serv Error' et une valeur d'erreur de Invalid EXP<-->PHB mapping'. Ceux-ci sont définis ci-dessous à la section 5.5. Le mappage EXP<-->PHB' signalé dans l'objet DIFFSERV pour un E-LSP est invalide lorsque :

le champ MAPnb n'est pas dans la plage 0 à 8 ou
une valeur EXP donnée apparaît dans plus d'une entrée MAP, ou
le codage PHBID est invalide.

Un LSR recevant un message Path avec l'objet DIFFSERV pour L-LSP, qui reconnaît l'objet DIFFSERV mais ne prend pas en charge le PSC particulier codé dans le champ PSC, envoie un PathErr vers l'expéditeur avec le code d'erreur Diff-Serv Error' et une valeur d'erreur de Unsupported PSC'. Ceux-ci sont définis ci-dessous à la section 5.5.

Un LSR recevant un message Path avec l'objet DIFFSERV, qui reconnaît l'objet DIFFSERV mais qui est incapable d'allouer le contexte Diff-Serv par LSP requis envoie un PathErr avec le code d'erreur "Diff-Serv Error" et la valeur d'erreur "Per-LSP context allocation failure". Ceux-ci sont définis ci-dessous à la section 5.5.

Un LSR Diff-Serv MUST gérer les situations où la demande d'étiquette ne peut pas être acceptée pour des raisons autres que celles déjà discutées dans cette section, conformément à [RSVP_MPLS_TE] (par exemple, réservation rejetée par le contrôle d'admission, une étiquette ne peut pas être associée).

5.4 Non-prise en charge de l'objet DIFFSERV

Un LSR qui ne reconnaît pas le Class-Num de l'objet DIFFSERV MUST se comporter conformément aux procédures spécifiées dans [RSVP] pour un Class-Num inconnu dont le format est 0bbbbbbb c'est-à-dire qu'il doit envoyer un PathErr avec le code d'erreur `Unknown object class' vers l'expéditeur.

Un LSR qui reconnaît le Class-Num de l'objet DIFFSERV mais ne reconnaît pas le C-Type de l'objet DIFFSERV, doit se comporter conformément aux procédures spécifiées dans [RSVP] pour un C-type inconnu c'est-à-dire qu'il doit envoyer un PathErr avec le code d'erreur `Unknown object C-Type' vers l'expéditeur.

Dans les deux situations, cela provoque l'échec de l'établissement du chemin. L'expéditeur devrait notifier la gestion qu'un L-LSP ne peut pas être établi et devrait éventuellement prendre des mesures pour réessayer l'établissement du LSP sans l'objet DIFFSERV (par exemple, tenter d'utiliser des E-LSP avec mappage `EXP<-->PHB' préconfiguré comme stratégie de repli).

5.5 Codes d'erreur pour Diff-Serv

Dans les procédures décrites ci-dessus, certaines erreurs doivent être signalées comme une Diff-Serv Error'. La valeur du code d'erreur Diff-Serv Error' est 27.

Ce qui suit définit les valeurs d'erreur pour la Diff-Serv Error :

   Value    Error

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

5.6 Type de service Intserv

Les E-LSP et les L-LSP peuvent tous deux être établis avec ou sans réservation de bande passante.

Comme spécifié dans [RSVP_MPLS_TE], pour établir un E-LSP ou un L-LSP avec réservation de bande passante, le service Controlled Load d'Int-Serv (ou éventuellement Guaranteed Service) est utilisé et la bande passante est signalée dans le SENDER_TSPEC (respectivement FLOWSPEC) du message path (respectivement Resv).

Comme spécifié dans [RSVP_MPLS_TE], pour établir un E-LSP ou un L-LSP sans réservation de bande passante, le Null Service spécifié dans [NULL] est utilisé.

Notez que cette spécification définit l'utilisation des E-LSP et L-LSP pour la prise en charge du service Diff-Serv uniquement. Indépendamment du service Intserv (Controlled Load, Null Service, Guaranteed Service,...) et indépendamment du fait que la réservation soit avec ou sans réservation de bande passante, les E-LSP et L-LSP sont définis ici pour la prise en charge des services Diff-Serv. La prise en charge des services Int-Serv sur un backbone MPLS Diff-Serv est hors du champ d'application de cette spécification.

Notez également que cette spécification ne s'intéresse pas à l'objet DCLASS défini dans [DCLASS], car cet objet transporte des informations sur les valeurs DSCP, qui ne sont pas pertinentes à l'intérieur du réseau MPLS.

6. Extensions LDP pour la prise en charge de Diff-Serv

L'architecture MPLS n'assume pas un protocole unique de distribution d'étiquettes. [LDP] définit le Label Distribution Protocol et son utilisation pour l'établissement de chemins à commutation d'étiquettes (LSP) dans les réseaux MPLS. Cette section spécifie les extensions à LDP pour établir des LSP prenant en charge les services différenciés dans les réseaux MPLS.

Une nouvelle TLV LDP est définie dans ce document :

la TLV Diff-Serv

Une description détaillée de cette TLV est fournie ci-dessous.

La nouvelle TLV Diff-Serv est optionnelle par rapport à LDP. Un LSR capable Diff-Serv prenant en charge les E-LSP qui utilisent le mappage EXP<-->PHB' préconfiguré en conformité avec cette spécification MAY prendre en charge la TLV Diff-Serv. Un LSR capable Diff-Serv prenant en charge les E-LSP qui utilisent le mappage EXP<-->PHB' signalé en conformité avec cette spécification MUST prendre en charge la TLV Diff-Serv. Un LSR capable Diff-Serv prenant en charge les L-LSP en conformité avec cette spécification MUST prendre en charge la TLV Diff-Serv.

6.1 TLV Diff-Serv

La TLV Diff-Serv a les formats suivants :

TLV Diff-Serv pour un 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 Type de LSP. Ceci est mis à 0 pour un E-LSP

Reserved : 27 bits Ce champ est réservé. Il doit être mis à zéro à la transmission et doit être ignoré à la réception.

MAPnb : 4 bits Indique le nombre d'entrées MAP incluses dans l'objet DIFFSERV. Cela peut être mis à n'importe quelle valeur de 1 à 8.

MAP : 32 bits Chaque entrée MAP définit le mappage entre une valeur de champ EXP et un PHB. L'entrée MAP a le format suivant :

    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 Ce champ est réservé. Il doit être mis à zéro à la transmission et doit être ignoré à la réception.

EXP : 3 bits Ce champ contient la valeur du champ EXP pour le mappage `EXP<-->PHB' défini dans cette entrée MAP.

PHBID : 16 bits Ce champ contient le PHBID du PHB pour le mappage `EXP<-->PHB' défini dans cette entrée MAP. Le PHBID est codé comme spécifié dans [PHBID].

TLV Diff-Serv pour un 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 Type de LSP. Ceci est mis à 1 pour un L-LSP

Reserved : 15 bits Ce champ est réservé. Il doit être mis à zéro à la transmission et doit être ignoré à la réception.

PSC : 16 bits Le PSC indique une classe d'ordonnancement PHB (PHB Scheduling Class) à prendre en charge par le LSP. Le PSC est codé comme spécifié dans [PHBID].

6.2 Valeurs de code d'état Diff-Serv

Les valeurs suivantes sont définies pour le champ Status Code de la Status TLV :

      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 Messages LDP liés à Diff-Serv

6.3.1 Message Label Request

Le format du message Label Request est étendu comme suit, pour inclure optionnellement la TLV Diff-Serv :

 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 Message Label Mapping

Le format du message Label Mapping est étendu comme suit, pour inclure optionnellement la TLV Diff-Serv :

 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 Message Label Release

Le format du message Label Release est étendu comme suit, pour inclure optionnellement la Status TLV :

    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 Message Notification

Le format du message Notification est étendu comme suit, pour inclure optionnellement la TLV Diff-Serv :

 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 Traitement de la TLV Diff-Serv

6.4.1 Traitement de la TLV Diff-Serv en mode Downstream Unsolicited

Cette section décrit les opérations lorsque le mode Downstream Unsolicited est utilisé.

Lors de l'allocation d'une étiquette pour un E-LSP qui doit utiliser le mappage `EXP<-->PHB' préconfiguré, un LSR Diff-Serv aval émet un message Label Mapping sans la TLV Diff-Serv.

Lors de l'allocation d'une étiquette pour un E-LSP qui doit utiliser un mappage `EXP<-->PHB' signalé, un LSR Diff-Serv aval émet un message Label Mapping avec la TLV Diff-Serv pour un E-LSP qui contient une entrée MAP pour chaque valeur EXP à prendre en charge sur cet E-LSP.

Lors de l'allocation d'une étiquette pour un L-LSP, un LSR Diff-Serv aval émet un message Label Mapping avec la TLV Diff-Serv pour un L-LSP qui contient la classe d'ordonnancement PHB (PSC) à prendre en charge sur ce L-LSP.

En supposant que l'établissement de l'étiquette est réussi, les LSR aval et amont doivent :

mettre à jour le contexte Diff-Serv associé aux LSP établis dans leur ILM/FTN comme spécifié dans les sections précédentes (étiquette entrante et sortante),
installer le traitement de transfert Diff-Serv requis (comportement d'ordonnancement et de rejet) pour cette NHLFE (étiquette sortante).

Un LSR Diff-Serv amont recevant un message Label Mapping avec plusieurs TLV Diff-Serv ne considère que la première comme significative. Le LSR doit ignorer et ne pas transmettre la(les) TLV Diff-Serv suivante(s).

Un LSR Diff-Serv amont qui reçoit un message Label Mapping, avec la TLV Diff-Serv pour un E-LSP et ne prend pas en charge le PHB particulier codé dans une ou plusieurs des entrées MAP, doit rejeter le mappage en envoyant un message Label Release qui inclut la Label TLV et la Status TLV avec un Status Code de `Unsupported PHB'.

Un LSR Diff-Serv amont recevant un message Label Mapping avec la TLV Diff-Serv pour un E-LSP et déterminant que le mappage EXP<-->PHB' signalé est invalide, doit rejeter le mappage en envoyant un message Label Release qui inclut la Label TLV et la Status TLV avec un Status Code de Invalid EXP<-->PHB mapping'. Le mappage `EXP<-->PHB' signalé dans l'objet DIFFSERV pour un E-LSP est invalide lorsque :

le champ MAPnb n'est pas dans la plage 1 à 8, ou
une valeur EXP donnée apparaît dans plus d'une entrée MAP, ou
le codage PHBID est invalide

Un LSR Diff-Serv amont recevant un message Label Mapping avec la TLV Diff-Serv pour un L-LSP contenant une valeur PSC qui n'est pas prise en charge, doit rejeter le mappage en envoyant un message Label Release qui inclut la Label TLV et la Status TLV avec un Status Code de `Unsupported PSC'.

6.4.2 Traitement de la TLV Diff-Serv en mode Downstream on Demand

Cette section décrit les opérations lorsque le mode Downstream on Demand est utilisé.

Lors de la demande d'une étiquette pour un E-LSP qui doit utiliser le mappage `EXP<-->PHB' préconfiguré, un LSR Diff-Serv amont envoie un message Label Request sans la TLV Diff-Serv.

Lors de la demande d'une étiquette pour un E-LSP qui doit utiliser un mappage `EXP<-->PHB' signalé, un LSR Diff-Serv amont envoie un message Label Request avec la TLV Diff-Serv pour un E-LSP qui contient une entrée MAP pour chaque valeur EXP à prendre en charge sur cet E-LSP.

Lors de la demande d'une étiquette pour un L-LSP, un LSR Diff-Serv amont envoie un message Label Request avec la TLV Diff-Serv pour un L-LSP qui contient le PSC à prendre en charge sur ce L-LSP.

Un LSR Diff-Serv aval envoyant un message Label Mapping en réponse à un message Label Request pour un E-LSP ou un L-LSP ne doit pas inclure une TLV Diff-Serv dans ce message Label Mapping. En supposant que l'établissement de l'étiquette est réussi, les LSR aval et amont doivent :

mettre à jour le contexte Diff-Serv associé aux LSP établis dans leur ILM/FTN comme spécifié dans les sections précédentes (étiquette entrante et sortante),
installer le traitement de transfert Diff-Serv requis (comportement d'ordonnancement et de rejet) pour cette NHLFE (étiquette sortante).

Un LSR Diff-Serv amont recevant un message Label Mapping contenant une TLV Diff-Serv en réponse à son message Label Request, doit rejeter le mappage d'étiquette en envoyant un message Label Release qui inclut la Label TLV et la Status TLV avec un Status Code de `Unexpected Diff-Serv TLV'.

Un LSR Diff-Serv aval recevant un message Label Request avec plusieurs TLV Diff-Serv ne considère que la première comme significative. Le LSR doit ignorer et ne pas transmettre la(les) TLV Diff-Serv suivante(s).

Un LSR Diff-Serv aval qui reçoit un message Label Request avec la TLV Diff-Serv pour un E-LSP et ne prend pas en charge le PHB particulier codé dans une (ou plusieurs) des entrées MAP, doit rejeter la demande en envoyant un message Notification qui inclut la Status TLV avec un Status Code de `Unsupported PHB'.

Un LSR Diff-Serv aval recevant un message Label Request avec la TLV Diff-Serv pour un E-LSP et déterminant que le mappage EXP<-->PHB' signalé est invalide, doit rejeter la demande en envoyant un message Notification qui inclut la Status TLV avec un Status Code de Invalid EXP<-->PHB mapping'. Le mappage `EXP<-->PHB' signalé dans la TLV DIFFSERV pour un E-LSP est invalide lorsque :

le champ MAPnb n'est pas dans la plage 1 à 8, ou
une valeur EXP donnée apparaît dans plus d'une entrée MAP, ou
le codage PHBID est invalide

Un LSR Diff-Serv aval recevant un message Label Request avec la TLV Diff-Serv pour un L-LSP contenant une valeur PSC qui n'est pas prise en charge, doit rejeter la demande en envoyant un message Notification qui inclut la Status TLV avec un Status Code de `Unsupported PSC'.

Un LSR Diff-Serv aval qui reconnaît le type de TLV Diff-Serv dans un message Label Request mais est incapable d'allouer les informations de contexte par LSP requises, doit rejeter la demande en envoyant un message Notification qui inclut la Status TLV avec un Status Code de `Per-LSP context allocation failure'.

Un LSR Diff-Serv aval qui reconnaît le type de TLV Diff-Serv dans un message Label Request et prend en charge le PSC demandé mais n'est pas capable de satisfaire la demande d'étiquette pour d'autres raisons (par exemple, aucune étiquette disponible), doit envoyer un message Notification conformément aux procédures LDP existantes [LDP] (par exemple, avec un Status Code `No Label Resource'). Ce message Notification doit inclure la TLV Diff-Serv demandée.

6.5 Non-traitement de la TLV Diff-Serv

Un LSR qui ne reconnaît pas le type de TLV Diff-Serv, à la réception d'un message Label Request ou d'un message Label Mapping contenant la TLV Diff-Serv, doit se comporter conformément aux procédures spécifiées dans [LDP] pour une TLV inconnue dont les bits U et F sont mis à 0 c'est-à-dire qu'il doit ignorer le message, renvoyer un message Notification avec le Status `Unknown TLV'.

6.6 Informations de bande passante

Les informations de bande passante peuvent également être signalées au moment de l'établissement des E-LSP et L-LSP, par exemple à des fins d'ingénierie de trafic, en utilisant la Traffic Parameters TLV comme décrit dans [MPLS CR LDP].

7. Prise en charge MPLS de Diff-Serv sur les interfaces PPP, LAN, Non-LC-ATM et Non-LC-FR

Les opérations générales pour la prise en charge MPLS de Diff-Serv, y compris le transfert d'étiquettes et les opérations d'établissement de LSP, sont spécifiées dans les sections précédentes. Cette section décrit les opérations spécifiques requises pour la prise en charge MPLS de Diff-Serv sur les interfaces PPP, les interfaces LAN, les interfaces ATM qui ne sont pas contrôlées par étiquettes et les interfaces Frame Relay qui ne sont pas contrôlées par étiquettes.

Sur ces interfaces, cette spécification permet n'importe laquelle des combinaisons de LSP suivantes par FEC :

Zéro ou un nombre quelconque d'E-LSP, et
Zéro ou un nombre quelconque de L-LSP.

Un LSR capable Diff-Serv MUST prendre en charge les E-LSP qui utilisent le mappage `EXP<-->PHB' préconfiguré sur ces interfaces.

Un LSR capable Diff-Serv MAY prendre en charge les E-LSP qui utilisent le mappage `EXP<-->PHB' signalé et les L-LSP sur ces interfaces.

8. Prise en charge MPLS de Diff-Serv sur les interfaces LC-ATM

Cette section décrit les opérations spécifiques requises pour la prise en charge MPLS de Diff-Serv sur les interfaces ATM contrôlées par commutation d'étiquettes (Label Switching Controlled-ATM, LC-ATM).

Ce document permet un nombre quelconque de L-LSP par FEC au sein d'un domaine MPLS ATM Diff-Serv. Les E-LSP ne sont pas pris en charge sur les interfaces LC-ATM.

8.1 Utilisation des classes de trafic ATM et des mécanismes de gestion de trafic

L'utilisation des « catégories de service ATM » spécifiées par l'ATM Forum, des « capacités de transfert ATM » spécifiées par l'ITU-T ou de classes de trafic ATM spécifiques au fournisseur est hors du champ d'application de cette spécification. La seule exigence pour une implémentation conforme est que le comportement de transfert vécu par un agrégat de comportement transféré sur un L-LSP par le LSR ATM MUST être conforme aux spécifications PHB Diff-Serv correspondantes.

Étant donné qu'il n'y a qu'un seul bit (CLP) pour coder la valeur de priorité de rejet PHB sur les liens ATM, seuls deux niveaux de priorité de rejet différents sont pris en charge dans les LSR ATM. Les sections 4.2.2 et 4.4.2 définissent comment les trois niveaux de priorité de rejet des agrégats ordonnés AFn sont mappés vers ces deux niveaux de priorité de rejet ATM. Ce mappage est conforme aux exigences spécifiées dans [DIFF_AF] pour le cas où seuls deux niveaux de priorité de rejet sont pris en charge.

Pour éviter de rejeter des parties des paquets, des mécanismes de rejet de trame, tels que Early Packet Discard (EPD) (voir [ATMF_TM]) SHOULD être activés dans les ATM-LSR pour tous les PHB décrits dans ce document.

8.2 Mise en œuvre de LSR avec interfaces LC-ATM

Un LSR capable Diff-Serv MUST prendre en charge les L-LSP sur les interfaces LC-ATM. Cette spécification suppose que les Edge-LSR du domaine ATM-LSR utilisent la méthode d'encapsulation « shim header » définie dans [MPLS_ATM]. Les opérations sans l'encapsulation « shim header » sont hors du champ d'application de cette spécification.

9. Prise en charge MPLS de Diff-Serv sur les interfaces LC-FR

Cette section décrit les opérations spécifiques requises pour la prise en charge MPLS de Diff-Serv sur les interfaces Frame Relay contrôlées par commutation d'étiquettes (Label Switching Controlled-Frame Relay, LC-FR).

Ce document permet un nombre quelconque de L-LSP par FEC au sein d'un domaine MPLS Frame Relay Diff-Serv. Les E-LSP ne sont pas pris en charge sur les interfaces LC-FR.

9.1 Utilisation des paramètres de trafic Frame Relay et des mécanismes de gestion de trafic

L'utilisation des paramètres de trafic Frame Relay tels que spécifiés par l'ITU-T et le Frame Relay Forum ou de mécanismes de gestion de trafic Frame Relay spécifiques au fournisseur est hors du champ d'application de cette spécification. La seule exigence pour une implémentation conforme est que le comportement de transfert vécu par un agrégat de comportement transféré sur un L-LSP par le LSR Frame Relay MUST être conforme aux spécifications PHB Diff-Serv correspondantes.

Étant donné qu'il n'y a qu'un seul bit (DE) pour coder la valeur de priorité de rejet PHB sur les liens Frame Relay, seuls deux niveaux de priorité de rejet différents sont pris en charge dans les LSR Frame Relay. Les sections 4.2.3 et 4.4.3 définissent comment les trois niveaux de priorité de rejet des agrégats ordonnés AFn sont mappés vers ces deux niveaux de priorité de rejet Frame Relay. Ce mappage est conforme aux exigences spécifiées dans [DIFF_AF] pour le cas où seuls deux niveaux de priorité de rejet sont pris en charge.

9.2 Mise en œuvre de LSR avec interfaces LC-FR

Un LSR capable Diff-Serv MUST prendre en charge les L-LSP sur les interfaces LC-Frame Relay.

Cette spécification suppose que les Edge-LSR du domaine FR-LSR utilisent la méthode d'« encapsulation générique » telle que recommandée dans [MPLS_FR]. Les opérations sans l'« encapsulation générique » sont hors du champ d'application de cette spécification.

10. Considérations IANA

Ce document définit un certain nombre d'objets ayant des implications pour l'IANA.

Ce document définit à la section 5.2 un nouvel objet RSVP, l'objet DIFFSERV. Cet objet a nécessité un numéro de l'espace défini dans [RSVP] pour ces objets qui, s'ils ne sont pas compris, provoquent le rejet du message RSVP entier avec un code d'erreur de « Unknown Object Class ». De tels objets sont identifiés par un zéro dans le bit le plus significatif du numéro de classe. Au sein de cet espace, cet objet a nécessité un numéro de l'espace « IETF Consensus ». « 65 » a été alloué par l'IANA pour l'objet DIFFSERV.

Ce document définit à la section 5.5 un nouveau code d'erreur RSVP, « Diffserv Error ». Le code d'erreur « 27 » a été assigné par l'IANA au « Diffserv Error ». Ce document définit les valeurs 1 à 5 du champ de valeur à utiliser au sein de l'objet ERROR_SPEC pour ce code d'erreur. Les allocations futures de valeurs dans cet espace devraient être gérées par l'IANA en utilisant la politique First Come First Served définie dans [IANA].

Ce document définit à la section 6.1 une nouvelle TLV LDP, la TLV Diffserv. Le numéro pour cette TLV a été assigné par consensus du groupe de travail selon les politiques définies dans [LDP].

Ce document définit à la section 6.2 cinq nouvelles valeurs de Status Code LDP pour des conditions d'erreur liées à Diffserv. Les valeurs pour le Status Code ont été assignées par consensus du groupe de travail selon les politiques définies dans [LDP].

11. Considérations de sécurité

Ce document n'introduit aucune nouvelle question de sécurité au-delà de celles inhérentes à Diff-Serv, MPLS et RSVP, et peut utiliser les mêmes mécanismes proposés pour ces technologies.

12. Remerciements

Ce document a bénéficié de discussions avec Eric Rosen, Angela Chiu et Carol Iturralde. Il a également emprunté aux travaux effectués par D. Black concernant l'interaction entre Diff-Serv et les tunnels IP.

ANNEXE A. Exemples de scénarios de déploiement

Cette section ne fournit pas de spécification supplémentaire et n'est ici que pour fournir des exemples de la manière dont cette approche flexible pour la prise en charge de Diff-Serv sur MPLS peut être déployée. Les avantages et inconvénients de diverses options de déploiement pour des environnements particuliers sont hors du champ d'application de ce document.

A.1 Scénario 1 : 8 BA (ou moins), pas d'ingénierie de trafic, pas de protection MPLS

Un fournisseur de services exploitant 8 BA (ou moins) sur MPLS, n'effectuant pas d'ingénierie de trafic, n'utilisant pas la protection MPLS et utilisant l'encapsulation MPLS Shim Header dans son réseau, peut choisir d'exécuter Diff-Serv sur MPLS en utilisant un seul E-LSP par FEC établi via LDP. En outre, le fournisseur de services peut choisir d'utiliser le mappage `EXP<-->PHB' préconfiguré.