RFC3270 page - 35 - Le Faucheur & autres

Groupe de travail Réseau

F. Le Faucheur, éditeur

Request for Comments : 3270

L. Wu et B. Davie, Cisco Systems

Catégorie : En cours de normalisation

S. Davari, PMC-Sierra Inc.

mai 2002

P. Vaananen, Nokia


R. Krishnan, Axiowave Networks


P. Cheval, Alcatel

Traduction Claude Brière de L’Isle

J. Heinanen, Song Networks



Prise en charge des services différenciés par la commutation d'étiquettes multi-protocoles (MPLS)



Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.


Notice de copyright

Copyright (C) The Internet Society (2002). Tous droits réservés.


Résumé

Le présent document définit une solution souple pour la prise en charge des services différenciés (Diff-Serv, Differentiated Services) sur les réseaux de commutation d’étiquettes multi protocole (MPLS, Multi-Protocol Label Switching).


Cette solution permet à l’administrateur de réseau MPLS de choisir comment les agrégats de comportement (BA, Behavior Aggregate) Diff-Serv sont transposés sur les chemins de commutation d’étiquette (LSP, Label Switched Paths) afin qu’ils puissent le mieux correspondre aux objectifs de Diff-Serv, d’ingénierie du trafic et de protection au sein de son réseau particulier. Par exemple, cette solution permet à l’administrateur de réseau de décider si différents ensembles de BA sont à transposer sur le même LSP ou à transposer sur des LSP distincts.


Table des matières

1. Introduction 2

1.1 Terminologie 3

1.2 LSP à PSC déduite par EXP (E-LSP) 4

1.3 LSP à PSC déduite seulement par l’étiquette (L-LSP) 4

1.4 Fonctionnement global 4

1.5 Relations entre étiquettes et FEC 5

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

2. Modèle de transmission d’étiquette pour les LSR Diff-Serv et modèles de tunnelage 6

2.1 Modèle de transmission d’étiquettes pour les LSR Diff-Serv 6

2.2 Détermination du PHB entrant 6

2.3 Détermination du PHB sortant avec conditionnement facultatif du trafic 7

2.4 Transmission d’étiquette 7

2.5 Codage des informations Diff-Serv dans la couche d’encapsulation 8

2.6 Modèles de tunnelage Diff-Serv sur MPLS 8

3. Fonctionnement détaillé des E-LSP 13

3.1 Définition de l’E-LSP 13

3.2 Remplissage de la transposition de Encaps en PHB pour un E-LSP entrant 13

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

3.4 Remplissage des transpositions d’ensemble de PHB <-->Encaps pour un E-LSP sortant 14

3.5 Codage des informations Diff-Serv dans la couche Encapsulation sur le E-LSP sortant 15

3.6 Fusion de E-LSP 16

4. Fonctionnement détaillé des L-LSP 16

4.1 Définition de L-LSP 16

4.2 Remplissage de transposition de Encaps en PHB pour un L-LSP entrant 16

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

4.4 Remplissage des transpositions d’ensemble de PHB en Encaps pour un L-LSP sortant 18

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

4.6 Fusion de L-LSP 19

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

5.1 Format des messages RSVP qui se rapportent à Diff-Serv 19

5.2 Objet DIFFSERV 20

5.3 Traitement de l’objet DIFFSERV 21

5.4 Non prise en charge de l’objet DIFFSERV 23

5.5 Codes d’erreur pour Diff-Serv 23

5.6 Type de service Intserv 23

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

6.1 TLV Diff-Serv 24

6.2 Valeurs de code d’état Diff-Serv 25

6.3 Messages Diff-Serv en rapport avec LDP 25

6.4 Traitement du TLV Diff-Serv 26

6.5 Non traitement du TLV Diff-Serv 28

6.6 Informations de bande passante 28

7. Prise en charge par MPLS de Diff-Serv sur interfaces PPP, LAN, non LC-ATM et non LC-FR 28

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

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

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

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

9.1 Utilisation des paramètres de trafic de relais de trame et mécanismes de gestion du trafic 29

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

10. Considérations relatives à l’IANA 30

11. Considérations pour la sécurité 30

12. Remerciements 30

Appendice A Exemples de scénarios de déploiement 30

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

A.2 Scénario 2 : Plus de 8 BA, pas d’ingénierie du trafic, pas de protection MPLS 31

A.3 Scénario 3 : 8 BA (ou moins), ingénierie du trafic agrégée , protection MPLS agrégée 31

A.4 Scénario 4 : Ingénierie du trafic/Protection MPLS par OA 31

A.5 Scénario 5 : 8 BA (ou moins), ingénierie du trafic/protection MPLS par OA 32

A.6 Scénario 6 : pas d’ingénierie du trafic/protection MPLS sur 8 BA, ingénierie du trafic/protection MPLS sur les autres BA 32

A.7 Scénario 7 : plus de 8 BA, pas d’ingénierie du trafic, pas de protection MPLS 33

Appendice B Exemples de scénarios de réservation de bande passante 33

B.1 Scénario 1 : Pas de réservation de bande passante 33

B.2 Scénario 2 :Réservation de bande passante pour contrôle d’admission par PSC 33

B.3 Scénario 3 : Réservation de bande passante pour contrôle d’admission par PSC et ajustement de ressource par PSC 33

Références 34

Déclaration complète de droits de reproduction 35



1. Introduction


Dans un domaine MPLS [RFC3031], lorsque un flux de données traverse un chemin commun, un chemin de commutation d’étiquettes (LSP, Label Switched Path) peut être établi en utilisant les protocoles de signalisation MPLS. Au routeur de commutation d’étiquettes (LSR, Label Switch Router) d’entrée, chaque paquet est muni d’une étiquette et est transmis vers l’aval. À chaque LSR le long du LSP, l’étiquette est utilisée pour transmettre le paquet au prochain bond.


Dans un domaine de service différencié (Diff-Serv, Differentiated Service) [RFC2475] tous les paquets IP qui franchissent une liaison et exigent le même comportement Diff-Serv sont dits constituer un agrégat de comportement (BA, Behavior Aggregate). Au nœud d’entrée du domaine Diff-Serv, les paquets sont classés et marqués avec un codet Diff-Serv (DSCP, Diff-ServCode Point) qui correspond à leur agrégat de comportement. À chaque nœud de transit, le DSCP est utilisé pour choisir le comportement par bond (PHB, Per Hop Behavior) qui détermine le traitement de programmation et, dans certains cas, la probabilité d’abandon pour chaque paquet.


Le présent document spécifie une solution pour la prise en charge des agrégats de comportement Diff-Serv dont les PBH correspondants sont actuellement définis dans les [RFC2474], [RFC2597], [RFC3246] sur un réseau MPLS. Cette solution offre aussi de la souplesse pour une prise en charge facile des PHB qui pourraient être définis à l’avenir.


Cette solution s’appuie sur l’utilisation combinée de deux types de LSP :


- Les LSP qui peuvent transporter plusieurs agrégats ordonnés, de sorte que le champ EXP de l’en-tête Shim MPLS convoie au LSR le PHB à appliquer au paquet (couvrant à la fois les informations sur le traitement de programmation du paquet et sa préséance d’abandon).


- Les LSP qui ne transportent qu’un seul agrégat ordonné, de sorte que le traitement de programmation du paquet est déduit par le LSR exclusivement de la valeur de l’étiquette du paquet tandis que la préséance d’abandon du paquet est portée par le champ EXP de l’en-tête Shim MPLS ou dans le mécanisme de choix d’abandon spécifique de la couche de liaison encapsulante (ATM, relais de trame, 802.1).


Comme mentionné dans la [RFC2474], "les fournisseurs de service ne sont pas obligés d’utiliser les mêmes mécanismes ou configurations de nœuds pour activer la différentiation de service au sein de leur réseau, et ils sont libres de configurer les paramètres de nœud de la façon qui est appropriée à leur offre de service et à leurs objectifs d’ingénierie du trafic". Donc, la solution définie dans le présent document donne aux fournisseurs de services de la souplesse pour choisir comment les classes Diff-Serv sont acheminées ou comment est géré le trafic au sein de leur domaine (par exemple, des classes de services distinctes sont prises en charge via des LSP distincts et acheminées séparément, ou toutes les classes de service sont prises en charge sur le même LSP et acheminées ensemble).


Comme MPLS est en mode chemin, il a la possibilité de fournir plus vite et de façon plus prévisible des capacités de protection et de restauration face à des changements de topologie que les systèmes conventionnels IP acheminés bond par bond. Dans le présent document, on se réfère à de telles capacités par l’expression "protection MPLS". Bien que de telles capacités et les mécanismes associés sortent du domaine d’application de la présente spécification, on note qu’elles peuvent offrir différents niveaux de protection aux différents LSP. Comme la solution présentée ici permet aux fournisseurs de service de choisir comment les classes de service Diff-Serv sont transposées en LSP, la solution donne aussi au fournisseur de services de la souplesse dans le 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 alors que certaines autres classes de service sont prises en charge par des LSP qui ne sont pas protégés).


De plus, la solution spécifiée dans le présent document réalise la conservation de l’espace d’étiquettes et réduit le volume de signalisation d’établissement/suppression d’étiquettes lorsque possible en n’ayant seulement recours à plusieurs LSP pour une certaine classe d’équivalence de transmission (FEC, Forwarding Equivalent Class) [RFC3031] que lorsque c’est utile ou exigé.


La présente spécification permet la prise en charge de services différenciés pour le trafic transporté sur un réseau MPLS aussi bien IPv4 que IPv6. Le document ne décrit les opérations que pour l’envoi individuel. La prise en charge de la diffusion groupée fera l’objet de travaux ultérieurs.


La solution décrite dans le présent document n’empêche pas l’utilisation signalée ou configurée des bits EXP pour la prise en charge simultanée de la notification explicite d’encombrement (ECN, Explicit Congestion Notification) [RFC3168] et de Diff-Serv sur MPLS. Cependant, les techniques pour la prise en charge de ECN dans un environnement MPLS sortent du domaine d’application du présent document.


1.1 Terminologie


Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGÉ", "DEVRAIT" NE DEVRAIT PAS", "RECOMMANDÉ", "NON RECOMMANDÉ", "PEUT", et "FACULTATIF" doivent être interprétés comme décrit dans le BCP 14, [RFC2119].


Le lecteur est supposé être familiarisé avec la terminologie des [RFC3031], [RFC3032], [RFC3034], [RFC3035], ainsi qu’avec les termes suivants :

FEC : (Forwarding Equivalency Class) classe d’équivalence de transmission

FTN : (FEC-To-NHLFE Map) transposition de FEC à NHLFE

ILM : (Incoming Label Map) transposition d’étiquette entrante

LC-ATM : (Label Switching Controlled-ATM) (interface) de commutation d’étiquette contrôlée par ATM

LC-FR : (Label Switching Controlled-Frame Relay) (interface) de commutation d’étiquette contrôlée par relais de trame

LSP : (Label Switched Path) chemin de commutation d’étiquette

LSR : (Label Switch Router) routeur de commutation d’étiquette

MPLS : (Multi-Protocol Label Switching) commutation d’étiquette multi protocole

NHLFE : (Next Hop Label Forwarding Entry) Entrée de transmission d’étiquette de prochain bond


Le lecteur est supposé familier de la terminologie des [RFC2475], [RFC2474], [RFC2597], [RFC3246], y compris des termes suivants :

AF : (Assured Forwarding) transmission assurée

BA : (Behavior Aggregate) agrégat de comportements

CS : (Class Selector) sélecteur de classe

DF : (Default Forwarding) transmission par défaut

DSCP : (Differentiated Services Code Point) codet de services différenciés

EF : (Expedited Forwarding) transmission expédiée

PHB : (Per Hop Behavior) comportement par bond


Le lecteur est supposé familier de la terminologie de la [RFC3260], y compris les termes suivants :

OA : (Ordered Aggregate) agrégat ordonné, c’est l’ensemble d’agrégats de comportements qui partagent une contrainte d’ordre.

PSC : (PHB Scheduling Class) classe de programmation de comportements par bonds ; ensemble d’un ou plusieurs PHB qui sont appliqués aux agrégats de comportement appartenant à un certain OA. 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 aussi utilisés :

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

DE : (Discard Eligibility) vocation à l’élimination

SNMP : (Simple Network Management Protocol) protocole simple de gestion de réseau


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

E-LSP : (EXP-Inferred-PSC LSP) LSP à PSC déduite par EXP

L-LSP : (Label-Only-Inferred-PSC LSP) LSP à PSC déduite seulement par l’étiquette


1.2 LSP à PSC déduite par 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 certaine FEC, sans considération du nombre d’OA sur lesquels s’étendent ces BA. Avec de tels LSP, le champ EXP de l’en-tête Shim MPLS est utilisé par le LSR pour déterminer le PHB à appliquer au paquet. Cela inclut aussi bien le PSC que la préférence d’abandon.


On appelle de tels LSP des "LSP à PSC déduite par EXP" (E-LSP) car la PSC d’un paquet transporté sur ce LSP dépend de la valeur du champ EXP pour ce paquet.


La transposition du champ EXP en PHB (c’est-à-dire, en PSC et préséance d’abandon) pour un tel LSP, est signalée explicitement à l’établissement de l’étiquette ou s’appuie sur une transposition préconfigurée.


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


1.3 LSP à PSC déduite seulement par l’étiquette (L-LSP)

Un LSP séparé peut être établi pour une seule paire <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 la PSC à appliquer à un paquet étiqueté. Lorsque l’en-tête Shim est utilisé, la préséance d’abandon à appliquer par le LSR au paquet étiqueté est convoyée à l’intérieur de l’en-tête Shim MPLS du paquet étiqueté en utilisant le champ EXP. Lorsque l’en-tête Shim n’est pas utilisé (par exemple, MPLS sur ATM) la préséance d’abandon à appliquer par le LSR au paquet étiqueté est convoyée à l’intérieur de l’encapsulation d’en-tête de couche de liaison en utilisant les champs de préséance d’abandon spécifiques de la couche de liaison (par exemple, ATM CLP).


On appelle de tels LSP des "LSP à PSC déduite seulement par l’étiquette" (L-LSP) car la PSC peut être pleinement déduite de l’étiquette sans aucune autre information (par exemple, sans considération de la valeur du champ EXP). Le fonctionnement détaillé des L-LSP est spécifié à la section 4.


1.4 Fonctionnement global

Pour une certaine FEC, et sauf si des restrictions spécifiques du support s’appliquent comme indiqué aux sections 7, 8 et 9, la présente spécification permet toutes les combinaisons suivantes au sein d’un domaine Diff-Serv MPLS :

- zéro, un ou tout nombre de E-LSP, et

- zéro, un ou tout nombre de L-LSP.


L’administrateur de réseau choisit la combinaison réelle de LSP dans l’ensemble des combinaisons admises et choisit comment les agrégats de comportement sont en fait transportés sur cette combinaison de LSP, afin de correspondre au mieux à son environnement et ses objectifs en termes de prise en charge de Diff-Serv, d’ingénierie du trafic et de protection MPLS. Les critères de choix d’une telle combinaison sortent du domaine d’application de la présente spécification.


Pour une certaine FEC, il peut y avoir plus d’un LSP qui porte le même OA, par exemple pour les besoins de l’équilibrage de charge de l’OA; Cependant, afin de respecter les contraintes d’ordre, tous les paquets d’un certain microflux, éventuellement s’étendant sur plusieurs BA d’un certain agrégat ordonné, DOIVENT être transportés sur le même LSP. À l’inverse, chaque LSP DOIT être capable de prendre en charge tous les BA (actifs) d’un certain OA.


Des exemples de scénarios de développement sont donnés pour information à l’Appendice A.


1.5 Relations entre étiquettes et FEC

La [RFC3031] déclare à son paragraphe 2.1. "Généralités” que "Certains routeurs analysent l’en-tête de couche réseau d’un paquet non seulement pour choisir le prochain bond du paquet, mais aussi pour déterminer la "préséance" ou la "classe de service" d’un paquet. Ils peuvent alors appliquer des seuils d’élimination différents ou des disciplines de programmation différentes aux différents paquets. MPLS permet (mais n’exige pas) que la préséance ou la classe de service soit pleinement 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 préséance ou classe de service."


En accord avec cela, on observe que :

- Avec les E-LSP, l’étiquette représente la combinaison d’une FEC et de l’ensemble des BA transportés sur le 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 E-LSP et L-LSP

Sans considération du protocole de liaison d’étiquettes qui est utilisé, les E-LSP et les L-LSP peuvent être établis avec ou sans réservation de bande passante.


Établir un E-LSP ou un L-LSP avec une 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. La signalisation de telles exigences de bande passante peut être utilisée par les LSR au moment de l’établissement pour effectuer le 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 ou les PSC pertinents. La signalisation de telles exigences de bande passante peut aussi être utilisée par les LSR au moment de l’établissement pour effectuer un ajustement aux ressources Diff-Serv associées au ou aux PSC pertinents (par exemple, ajuster la pondération de programmation du PSC).


Noter qu’établir un E-LSP ou un L-LSP avec réservation de bande passante ne signifie pas que la programmation par LSP soit obligatoire. Comme dans le présent document, les E-LSP et les L-LSP sont spécifiés pour la prise en charge des services différenciés, le traitement de transmission requis (programmation et politique d’abandon) est défini par le PHB Diff-Serv approprié. Ce traitement de transmission DOIT être appliqué par le LSR à la granularité du BA et DOIT être conforme à la spécification de PHB pertinente.


Lorsque des exigences de bande passante sont signalées à l’établissement d’un L-LSP, la bande passante signalée est évidemment associée à la PSC du L-LSP. Donc, les LSR qui utilisent la bande passante signalée pour effectuer le contrôle d’admission peuvent le faire sur les ressources Diff-Serv qui sont dédiées à la PSC (par exemple, sur de la bande passante garantie à la PSC par sa pondération de programmation).


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


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 pour information à l’Appendice B.


2. Modèle de transmission d’étiquette pour les LSR Diff-Serv et modèles de tunnelage

2.1 Modèle de transmission d’étiquettes pour les LSR Diff-Serv

Comme différents agrégats ordonnés d’une certaine FEC peuvent être transportés sur différents LSP, la décision de changement d’étiquette d’un LSR Diff-Serv dépend clairement de l’agrégat de comportement du paquet transmis. Aussi, comme le champ DS IP d’un paquet transmis peut n’être pas directement visible pour un LSR, la façon 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.


Donc, afin de décrire la transmission d’étiquettes par les LSR Diff-Serv, on modélise le comportement de commutation d’étiquettes Diff-Serv d’un LSR selon quatre étapes :

- Détermination du PHB entrant (A)

- Détermination du PHB sortant avec conditionnement facultatif du trafic (B)

- Transmission d’étiquette (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étails dans les paragraphes suivants.


Évidemment, pour mettre en application la différenciation de service Diff-Serv, le LSR DOIT aussi appliquer le traitement de transmission correspondant au PHB sortant.


Ce modèle est illustré ci-dessous :


--Étiq_entrante(*)------------------------>I===I--Étiq_sortante(&)-->

\ I I \

\---->I===I I C I \-->I===I--Encaps->

I A I I===I—PHB_sort->I===I I D I (&)

-Encaps->I===I--PHB_ent->I B I \ /->I===I

(*) I===I \--------+

\----Traitement-->

de transmission (PHB)


"Encaps" désigne les informations qui se rapportent à Diff-Serv codées dans la couche d’encapsulation MPLS (par exemple, champ EXP, CLP ATM, DE de relais de trame, priorité d’utilisateur 802.1).


(*) 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 n’est pas une contrainte pour les mises en œuvre réelles.


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 considérant une entrée de pile d’étiquette

Les paragraphes 3.3 et 4.3 donnent les détails de la façon d’effectuer la détermination du PHB entrant en considérant une certaine entrée de pile d’étiquettes reçue et/ou certaines informations d’encapsulation MPLS entrantes reçues selon le type de LSP entrant et selon l’encapsulation MPLS entrante.


Le paragraphe 2.6 donne les détails sur l’entrée de la pile d’étiquettes à considérer pour la détermination du PHB entrant selon le mode de tunnelage Diff-Serv pris en charge.


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

Le paragraphe 2.6 précise quand l’en-tête IP est à prendre en compte pour la détermination du PHB entrant, selon le modèle de tunnelage Diff-Serv pris en charge. Dans les cas où l’en-tête IP est à utiliser, cette étape fonctionne exactement comme avec un routeur IP Diff-Serv non MPLS et utilise le champ DS pour déterminer le PHB entrant.


2.3 Détermination du PHB sortant avec conditionnement facultatif du trafic

L’étape de conditionnement du trafic est facultative et peut être utilisée sur un LSR pour effectuer le conditionnement du trafic y compris la rétrogradation ou la promotion de l’agrégat de comportement. Ceci est en dehors du domaine d’application de la présente spécification. Pour les besoins de la spécification de Diff-Serv sur transmission MPLS, on note simplement que le PHB à mettre en application et à convoyer aux LSR aval par un LSR (qu’on appelle le "PHB sortant") peut être différent du PHB qui a été associé au paquet par le LSR précédent (et qu’on appelle le "PHB entrant").


Lorsque l’étape de conditionnement du trafic n’est pas présente, le "PHB sortant" est simplement identique au "PHB entrant".


2.4 Transmission d’étiquette

La [RFC3031] décrit comment l’échange d’étiquettes est effectué par les LSR sur les paquets étiquetés entrants en utilisant une transposition d’étiquette entrante (ILM, Incoming Label Map) où chaque étiquette entrante est transposée en une ou plusieurs NHLFE. La [RFC3031] décrit aussi comment l’imposition d’étiquette est effectuée par les LSR sur les paquets entrants non étiquetés en utilisant une transposition de FEC à NHLFE (FTN) où chaque FEC entrante est transposée en une ou plusieurs NHLFE.


Un contexte Diff-Serv pour une étiquette se compose :

- du type de LSP (c’est-à-dire, E-LSP ou L-LSP)

- des PHB pris en charge,

- de la transposition de Encaps en PHB pour une étiquette entrante,

- de l’ensemble de transpositions de PHB en Encaps pour une étiquette sortante.


La présente spécification définit qu’un contexte Diff-Serv est mémorisé dans la ILM pour chaque étiquette entrante.


La [RFC3031] déclare que la NHLFE peut aussi contenir toutes les autres informations nécessaires afin de se défaire correctement du paquet. Conformément à cela, la présente spécification définit qu’un contexte Diff-Serv est mémorisé dans la NHLFE pour chaque étiquette sortante qui est échangée ou poussée.


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


Si l’étiquette correspond à un E-LSP pour lequel aucune transposition EXP<-->PHB n’a été explicitement signalée à l’établissement du LSP, les PHB pris en charge sont remplis avec l’ensemble des PHB de la transposition EXP<-->PHB préconfigurée qui est exposée plus loin au paragraphe 3.2.1.


Si l’étiquette correspond à un E-LSP pour lequel une transposition EXP<-->PHB a été explicitement signalée à l’établissement du LSP, les PHB pris en charge sont remplis avec l’ensemble des PHB de la transposition EXP<-->PHB signalée.


Si l’étiquette correspond à un L-LSP, les PHB pris en charge sont remplis avec l’ensemble de PHB qui forment le PSC qui est signalé à l’établissement du LSP.


Les détails de la façon dont la transposition d’Encaps en PHB ou d’ensemble de PHB en Encaps est remplie sont définis aux sections 3 et 4.


La [RFC3031] déclare aussi que :

"Si la ILM [respectivement, FTN] transpose une étiquette particulière en un ensemble de NHLFE qui contiennent plus d’un élément, exactement un élément de l’ensemble doit être choisi avant de transmettre le paquet. Les procédures pour choisir un élément dans l’ensemble sortent du domaine d’application du présent document. Avoir l’ILM [respectivement, FTN] qui transpose une étiquette [respectivement, une FEC] en un ensemble contenant plus d’une NHLFE peut être utile si, par exemple, on souhaite faire un équilibrage de charge sur plusieurs chemins de coût égal."


En accord avec ceci, la présente spécification permet qu’une étiquette entrante [respectivement, une FEC] puisse être transposée, pour les besoins de Diff-Serv, en plusieurs NHLFE (par exemple où différentes NHLFE correspondent aux étiquettes de sortie qui prennent en charge différents ensembles de PHB). Lorsque une étiquette [respectivement, une FEC] se transpose en plusieurs NHLFE, le LSR Diff-Serv DOIT choisir une des NHLFE dont le contexte Diff-Serv indique qu’elle prend en charge le PHB sortant du paquet transmis.


Lorsque une étiquette [respectivement, une FEC] se transpose en plusieurs NHLFE qui prennent en charge le PHB sortant, la procédure pour choisir entre elles sort du domaine d’application du présent document. Cette situation peut se rencontrer lorsque on désire équilibrer la charge d’un agrégat de comportement sur plusieurs LSP. Dans de telles situations, afin de respecter les contraintes d’ordre, tous les paquets d’un certain microflux DOIVENT ê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 portent les informations Diff-Serv dans le paquet transmis (par exemple, EXP de Shim MPLS, CLP d’ATM, DE de relais de trame, Priorité d’utilisateur de 802.1).


2.5.1 Codage des informations Diff-Serv dans une entrée d’étiquette transmise

Les paragraphes 3.5 et 4.5 donnent les détails de la façon d’effectuer le codage des informations Diff-Serv dans une certaine entrée de pile d'étiquettes transmise et/ou informations d’encapsulation MPLS transmises selon le type de LSP sortant correspondant et selon l’encapsulation MPLS.


Le paragraphe 2.6 donne les détails de sur quelle entrée de la pile d’étiquettes effectuer le codage d’informations Diff-Serv selon le mode de tunnelage Diff-Serv pris en charge.


2.5.2 Codage des informations Diff-Serv dans un en-tête IP transmis

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


Le paragraphe 2.6 précise quand est à effectuer le codage des informations Diff-Serv dans l’en-tête IP transmis selon le mode de tunnelage Diff-Serv pris en charge.


2.6 Modèles de tunnelage Diff-Serv sur MPLS

2.6.1 Modèles de tunnelage Diff-Serv

La [RFC2983] considère l’interaction des services différenciés avec des 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 pris en compte dans la [RFC2983]. Cependant, bien qu’ils ne soient pas une forme de "tunnel IP", les LSP MPLS sont une forme de "tunnel".


Du point de vue de 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 qui sont quelque part le long de la portée du LSP) ne voient et ne fonctionnent que sur les informations Diff-Serv "externes" ;

- les LSP sont unidirectionnels ;

- les informations Diff-Serv "externes"  peuvent être modifiées sur tout nœud intermédiaire.


Cependant, du point de vue de Diff-Serv, les LSP ont aussi une propriété qui les distingue des tunnels IP :

- il n’y a généralement pas de comportement analogue à la suppression à l’avant dernier saut (PHP, Penultimate Hop Popping) utilisée avec les tunnels IP. De plus, la PHP a pour résultat que les informations Diff-Serv "externes" associées au LSP ne sont pas visibles au LSP de sortie. Dans les situations où ces informations ne sont pas significatives pour le LSP de sortie, ceci ne pose aucun problème. Dans les situations où ces informations sont significatives pour le LSP de sortie, elles doivent alors être portées par d’autres moyens.


Les deux modes conceptuels du tunnelage Diff-Serv sur les tunnels IP définis dans la [RFC2983] sont applicables et utiles pour Diff-Serv sur MPLS mais leur fonctionnement détaillé respectif est assez différent sur MPLS. Ces deux modèles sont le modèle du tuyau et le modèle uniforme. Leur fonctionnement sur MPLS est spécifié dans les paragraphes qui suivent. La discussion et la définition de modèles de remplacement du tunnelage sont en dehors du domaine d’application de la présente spécification.


2.6.2 Modèle de tuyau

Avec le modèle du tuyau, les tunnels MPLS (autrement dit, les LSP) sont utilisés pour cacher les nœuds MPLS intermédiaires entre le LSP d’entrée et le LSP de sortie du point de vue Diff-Serv.


Dans ce modèle, les paquets tunnelés doivent convoyer deux ensembles d’informations Diff-Serv significatifs :

- les informations Diff-Serv qui sont significatives pour les nœuds intermédiaires le long de la portée du LSP incluant la sortie du LSP (qu’on appelle les "informations Diff-Serv de LSP"). Ces informations Diff-Serv de LSP n’ont pas de signification au delà de la sortie du LSP: Que le conditionnement du trafic au nœuds intermédiaires sur la portée du LSP affecte ou non les informations Diff-Serv du LSP, ces informations Diff-Serv mises à jour ne sont pas considérées comme ayant une signification 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 (qu’on appelle les "informations Diff-Serv tunnelées"). Ces informations sont à transporter par l’entrée du LSP à la sortie du LSP. Ces informations Diff-Serv n’ont pas de signification pour les nœuds intermédiaires sur la portée du LSP.


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


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

---Troc--(M)--...--Troc--(M)--Troc----

/ (en-tête externe) \

(M) (M)

/ \

>--(m)-Pousse...............(m)...................Saute--(m)-->

I (en-tête interne) E (M*)


(M) représente les "informations Diff-Serv de LSP"

(m) représente les "informations Diff-Serv tunnelées"

(*) La sortie de LSP considère les informations Diff-Serv de LSP reçues dans l’en-tête externe (c’est-à-dire, avant le saut) afin d’appliquer son traitement de transmission 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 du tuyau, les "informations Diff-Serv du LSP" doivent être convoyées à la sortie du LSP afin qu’il applique son traitement de transmission fondé sur elles. Les "informations Diff-Serv tunnelées" ont aussi besoin d’être convoyées à la sortie du LSP afin qu’elles puissent être convoyées plus loin vers l’aval.


Comme les deux exigent que les informations Diff-Serv soient convoyées à la sortie du LSP, le modèle du tuyau ne fonctionne que sans PHP.


Le modèle du tuyau est particulièrement approprié pour des environnements dans lesquels :

- le nuage amont de l’interface entrante de l’entrée du LSP et le nuage aval de l’interface sortante de l’entrée du LSP sont dans des domaines Diff-Serv qui utilisent un ensemble commun de politiques d’approvisionnement de service Diff-Serv et de définitions de PHB, alors que le LSP s’étend sur un (ou plusieurs) domaines Diff-Serv qui utilisent un ensemble différent de politiques d’approvisionnement 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 couvert par le LSP.


Par exemple, considérons le cas d’un fournisseur de service qui offre un service VPN MPLS (voir dans la [RFC4364] un exemple d’architecture de VPN MPLS) incluant la différenciation Diff-Serv. Disons qu’une collection de sites est interconnectée via un tel service de VPN MPLS. Disons maintenant que cette collection de sites est gérée sous une administration commune et prend aussi en charge la différenciation de services Diff-Serv. Si l’administration de site VPN et le fournisseur de service ne partagent pas exactement la même politique Diff-Serv (par exemple, ils ne prennent pas en charge le même nombre de PHB) le fonctionnement de Diff-Serv dans le modèle de tuyau sur le service de VPN MPLS va permettre à la politique Diff-Serv de sites de VPN de fonctionner de façon cohérente à travers le site VPN d’entrée et le site VPN de sortie et de façon transparente sur le domaine Diff-Serv du fournisseur de service. Il peut être utile de voir de tels LSP comme reliant les domaines Diff-Serv à leurs points d’extrémité dans une seule région Diff-Serv en rendant des points d’extrémité virtuellement contigus même si ils peuvent être physiquement séparés par des nœuds de réseau intermédiaires.


Le modèle du tuyau DOIT être pris en charge.


Pour la prise en charge du modèle du tuyau sur un certain LSP sans PHP, un LSR effectue la détermination du PHB entrant et le codage d’informations Diff-Serv de la façon suivante :

- lorsque il reçoit un paquet non étiqueté, le LSR effectue la détermination du PHB entrant en examinant l’en-tête IP reçu,

- lorsque il reçoit un paquet étiqueté, le LSR effectue la détermination du PHB entrant en examinant l’entrée d’étiquette sortante dans la pile d’étiquettes reçue. En particulier, lorsque une opération de saut est à effectuer pour le LSP considéré, le LSR effectue la détermination du PHB entrant AVANT le saut,

- lorsque il effectue une opération de poussée 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 échangée ou en-tête IP),

- lorsque il effectue une opération seulement d’échange pour le LSP considéré, le LSR code les informations Diff-Serv dans l’entrée d’étiquette transmise qui contient l’étiquette échangée,

- lorsque il effectue une opération de saut 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 saut (c’est-à-dire que le LSR laisse l’en-tête exposé "tel quel").


2.6.2.1 Modèle du tuyau court

Le modèle du tuyau court est une variante facultative du modèle du tuyau décrit ci-dessus. La seule différence est que, avec le modèle du tuyau court, le traitement de transmission Diff-Serv à la sortie du LSP est appliqué sur la base des "informations Diff-Serv tunnelées" (c’est-à-dire, des informations Diff-Serv convoyées dans l’en-tête encapsulé) plutôt que des "informations Diff-Serv de LSP" (c’est-à-dire, des informations Diff-Serv convoyées dans l’en-tête encapsulant).


Le fonctionnement du modèle de tuyau court sans PHP est illustré ci-dessous :


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

---Troc--(M)--...--Troc--(M)--Troc----

/ (en-tête externe) \

(M) (M)

/ \

>--(m)-Pousse...............(m)..................Saute--(m)-->

I (en-tête interne) E


(M) représente les "informations Diff-Serv de LSP"

(m) représente les "informations Diff-Serv tunnelées"

I représente le nœud d’entrée du LSP

E représente le nœud de sortie du LSP


Comme la sortie du LSP applique son traitement de transmission sur la base des "informations Diff-Serv tunnelées", les "informations Diff-Serv de LSP" n’ont pas besoin d’être convoyées par l’avant dernier nœud à la sortie du LSP. Donc, le modèle du tuyau court peut aussi fonctionner avec PHP.


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


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

---Troc--(M)--...--Troc------

/ (en-tête externe) \

(M) (M)

/ \

>--(m)-Pousse..............(m)...........Saute-(m)--E--(m)-->

I (en-tête interne) P (M*)


(M) représente les "informations Diff-Serv de LSP"

(m) représente les "informations Diff-Serv tunnelées"

(*) L’avant dernier LSR examine les informations Diff-Serv de LSP reçues dans l’en-tête externe (c’est-à-dire, avant le saut) afin d’appliquer son traitement de transmission Diff-Serv (c’est-à-dire, le PHB réel)

I représente le nœud d’entrée du LSP

P représente l’avant dernier nœud du LSP

E représente le nœud de sortie du LSP


Le modèle du tuyau court est particulièrement approprié pour les environnements dans lesquels :

- le nuage amont de l’interface entrante de l’entrée de LSP et le nuage aval de l’interface sortante de sortie du LSP sont dans des domaines Diff-Serv qui utilisent un ensemble commun de politiques d’approvisionnement de services Diff-Serv et de définitions de PHB, tandis que le LSP couvre un (ou plusieurs) domaines Diff-Serv qui utilisent un ensemble différent de politiques d’approvisionnement de services Diff-Serv et de définitions de PHB ;

- l’interface sortante de la sortie de LSP est dans le même domaine Diff-Serv que son nuage aval.


Comme chaque interface sortante de la sortie du LSP est dans le même domaine Diff-Serv que son nuage aval, chaque interface sortante peut éventuellement être dans un domaine Diff-Serv différent, et la sortie du LSP doit être configurée avec la connaissance de toutes les politiques Diff-Serv correspondantes. Cette redondance opérationnelle est justifiée dans certaines situations où les politiques Diff-Serv aval respectives sont mieux adaptées à l’offre de différenciation de service sur chaque interface de sortie que la politique Diff-Serv commune utilisée sur la portée du LSP. Un exemple d’une telle situation est lorsque le fournisseur de service offre un service de VPN MPLS et où certains utilisateurs de VPN demandent que soit appliquée leur propre politique de VPN Diff-Serv pour contrôler la différenciation de service sur les liaisons dédiées à partir de la sortie de LSP vers le site VPN de destination, plutôt que la politique Diff-Serv du fournisseur de service.


Le modèle du tuyau court PEUT être pris en charge.


Pour la prise en charge du modèle du tuyau court sur un certain LSP 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 du tuyau avec l’exception suivante :

- lors de la réception d’un paquet étiqueté, le LSR effectue la détermination du PHB entrant en examinant l’en-tête (entrée d’étiquette ou en-tête IP) qui est utilisé pour faire la transmission réelle. En particulier, lorsque une opération de saut est à effectuer pour le LSP considéré, le LSR effectue la détermination du PHB entrant APRÈS le saut.


Pour la prise en charge du modèle du tuyau court sur un certain LSP 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 l’exception suivante :

- l’avant dernier LSR effectue la détermination du PHB entrant en examinant l’entrée d’étiquette externe dans la pile d’étiquette reçue. En d’autres termes, lorsque une opération de saut est à effectuer pour le LSP considéré, l’avant dernier LSR effectue la détermination du PHB entrant AVANT le saut.


Noter que le comportement de l’avant dernier LSR dans le modèle du tuyau court avec PHP est identique au comportement de la sortie du LSP dans le modèle du tuyau (nécessairement sans PHP).


2.6.3 Modèle uniforme

Avec le modèle uniforme, les tunnels MPLS (autrement dit, les LSP) sont vus comme des produits du chemin de bout en bout du point de vue Diff-Serv. Les tunnels MPLS peuvent être utilisés pour les besoins de la transmission mais n’ont pas d’impact significatif sur Diff-Serv. Dans ce modèle, tout paquet contient exactement une unité d’informations Diff-Serv qui est significative et est toujours codée 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). Toutes les informations Diff-Serv codées quelque part ailleurs (par exemple, dans des entrées d’étiquettes plus bas dans la pile) n’ont pas de signification pour les nœuds intermédiaires ou pour la sortie du tunnel et sont ignorées. Si le conditionnement du trafic aux nœuds intermédiaires sur la portée du LSP affecte les informations Diff-Serv "externes", les informations Diff-Serv mises à jour sont celles qui sont considérées comme significatives à la sortie du LSP.


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


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

---Troc--(M)--...-Troc--(M)--Troc----

/ (en-tête externe) \

(M) (M)

/ \

>--(M)--Pousse..............(x)...................Saute--(M)->

I (en-tête interne) E


(M) représente les informations Diff-Serv significatives codées dans l’en-tête correspondant.

(x) représente les 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 uniforme avec PHP est illustré ci-dessous :


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

---Troc-(M)-...-Troc------

/ en-tête externe) \

(M) (M)

/ \

>--(M)--Pousse............(x)..........Saute-(M)--E--(M)->

I (en-tête interne) P


(M) représente les informations Diff-Serv significatives codées dans l’en-tête correspondant.

(x) représente les informations Diff-Serv non significatives.

I représente le nœud d’entrée du LSP.

P représente l’avant dernier nœud du LSP.

E représente le nœud de sortie du LSP.


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

L’utilisation du modèle uniforme permet aux LSP d’étendre les frontières du domaine Diff-Serv sans autre mesure qu’un accord de conditionnement du trafic inter-domaine aux frontières physiques entre les domaines Diff-Serv et fonctionnant 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 uniforme PEUT être pris en charge.


Pour la prise en charge du modèle uniforme sur un certain LSP, un LSR effectue la détermination du PHB entrant et le codage des informations Diff-Serv de la façon suivante :

- à réception d’un paquet non étiqueté, le LSR effectue la détermination du PHB entrant en examinant l’en-tête IP reçu ;

- à réception d’un paquet étiqueté, le LSR effectue la détermination du PHB entrant en examinant l’entrée d’étiquette externe dans la pile d’étiquettes reçue. En particulier, lorsque une opération de saut est à effectuer pour le LSP considéré, le LSR effectue la détermination du PHB entrant AVANT le saut ;

- lorsque il effectue une opération de poussée 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 échangée ou en-tête IP) n’ont pas d’importance ;

- lorsque il effectue une opération seulement d’échange pour le LSP considéré, le LSR code les informations Diff-Serv dans l’entrée d’étiquette transmise qui contient l’étiquette échangée ;

- lorsque PHP est utilisé, l’avant dernier LSR a besoin d’être au courant des transpositions d’ensemble de PHB en Encaps pour l’étiquette qui correspond à l’en-tête exposé (ou la transposition de PHB en DSCP) afin d’effectuer le codage des informations Diff-Serv. Les méthodes pour fournir cette transposition sont en dehors du domaine d’application de la présente spécification. Par exemple, la transposition de PHB en DSCP peut être configurée en local. Autre exemple, dans certains environnements, il peut être approprié que l’avant dernier LSR suppose que les transpositions d’ensemble de PHB en Encaps à utiliser pour l’étiquette sortante dans l’en-tête exposé sont les transpositions d’ensemble de PHB en Encaps qui auraient été utilisées par le LSR si celui-ci ne faisait pas la PHP. Noter aussi que la présente spécification suppose que l’avant dernier LSR n’effectue pas l’échange d’étiquette sur l’entrée d’étiquette exposée par l’opération de suppression (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 peuvent être effectuées par l’avant dernier LSR. Par exemple, la présente spécification ne permet pas les situations où l’avant dernier LSR supprime une étiquette correspondant à un E-LSP qui prend en charge deux PSC, alors que l’en-tête exposé par le saut contient des valeurs d’étiquette pour deux L-LSP prenant chacun en charge un PSC, car le codage des informations Diff-Serv exigerait de choisir l’une ou l’autre des étiquettes.

Noter que les comportements de LSR pour les modèles de tuyau, de tuyau court, et uniforme, ne différent que lorsque on effectue une poussée ou un saut. Donc, les LSR intermédiaires qui effectuent des opérations seulement d’échange pour un LSP, se comportent exactement de la même façon, sans considérer si ils se comportent selon le modèle de tuyau, de tuyau court ou uniforme. Avec une mise en œuvre Diff-Serv qui prend en charge plusieurs modèles de tunnelage, seuls les LSR qui se comportent comme des entrées de LSP, des avant derniers LSR ou des sorties de LSP ont besoin d’être configurés pour fonctionner dans un modèle particulier. La signalisation pour associer un modèle de tunnelage Diff-Serv LSP par LSP sort du domaine d’application de la présente spécification.


2.6.4 Hiérarchie

Par le mécanisme de pile d’étiquette, MPLS permet au tunnelage de LSP de se nicher à n’importe quelle profondeur. On observe qu’avec une situation, la poussée de niveau N+1 prend place sur un LSR suivant (ou le même LSR) de celui qui fait la poussée pour le niveau N, tandis que le saut de niveau N+1 a lieu sur un LSR précédent (ou sur le même LSR) du LSR qui fait le saut du niveau N. Pour un LSP de niveau N, l’entrée du LSR qui fait la poussée et le LSR qui fait le saut (l’avant dernier LSR ou la sortie du LSP) doit fonctionner dans le même modèle de tunnelage (c’est-à-dire, tuyau, tuyau court ou uniforme). Cependant, il n’y a pas d’exigence de modèles de tunnelage cohérents à travers les niveaux de sorte que des LSP à des niveaux différents peuvent fonctionner dans différents modèles de tunnelage.

La hiérarchie des opérations est illustrée ci-dessous dans le cas de deux niveaux de tunnels :


+------Troc-----...---+

/ (en-tête externe) \

/ \

Pousse(2)................(2)Saute

/ (en-tête externe) \

/ \

>>---Pousse(1)...................(1)Saute-->>

(en-tête interne)


(1) Modèle de tunnelage 1

(2) Modèle de tunnelage 2


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


Pour un certain LSP de niveau N, le LSR doit effectuer la détermination du PHB entrant et le codage des informations Diff-Serv comme spécifié aux paragraphes 2.6.2, 2.6.2.1 et 2.6.3 conformément au modèle de tunnelage de ce LSP de niveau N et indépendamment du modèle de tunnelage des LSP d’autre niveau.


3. Fonctionnement détaillé des E-LSP

3.1 Définition de l’E-LSP

Les E-LSP sont définis au paragraphe 1.2.


Au sein d’un certain domaine Diff-Serv MPLS, tous les E-LSP qui s’appuient sur la transposition préconfigurée sont capables de transporter le même ensemble commun de 8, ou moins, BA. Chacun de ces E-LSP peut en fait transporter tout cet ensemble de BA ou tout sous-ensemble.


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


3.2 Remplissage de la transposition de Encaps en PHB pour un E-LSP entrant

Ce paragraphe définit comment la transposition d’Encaps en PHB du contexte Diff-Serv est remplie pour un E-LSP entrant afin de permettre la détermination du PHB entrant.


La transposition de Encaps en PHB pour un E-LSP est toujours de la forme transposition de EXP en PHB.


Si l’étiquette correspond à un E-LSP pour lequel aucune transposition 'EXP<-->PHB' n’a été explicitement signalée à l’établissement du LSP, la transposition de EXP en PHB est remplie sur la base de la transposition 'EXP<-->PHB' préconfigurée qui est exposée au paragraphe 3.2.1.


Si l’étiquette correspond à un E-LSP pour lequel une transposition 'EXP<-->PHB' a été explicitement signalée à l’établissement du LSP, la transposition de 'EXP en PHB' est remplie selon la transposition 'EXP<-->PHB' signalée.


3.2.1 Transposition EXP <--> PHB préconfigurée

Les LSR qui prennent en charge les E-LSP qui utilisent la transposition 'EXP<-->PHB' préconfigurée doivent permettre la configuration locale de cette transposition 'EXP<-->PHB'. Cette transposition s’applique à tous les E-LSP établis sur ce LSR sans une transposition explicitement signalée au moment de l’établissement.


La transposition 'EXP<-->PHB' préconfigurée doit être cohérente à chaque bond E-LSP tout au long du domaine Diff-Serv MPLS couvert par le LSP ou bien un nouveau marquage approprié du champ EXP doit être effectué par le LSR chaque fois qu’une transposition préconfigurée différente est utilisée sur les interfaces d’entrée ou de sortie.


Au cas où la transposition 'EXP<-->PHB' préconfigurée n’a en fait pas été configurée par l’administrateur du réseau, le LSR devrait utiliser une transposition 'EXP<-->PHB' préconfigurée par défaut qui transpose toutes les valeurs de EXP en PHB par défaut.


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

Ce paragraphe définit comment est mise en pratique la détermination du PHB entrant lorsque l’entrée d’étiquette considérée dans la pile d’étiquettes reçue correspond à un E-LSP. Cela exige que la transposition d’Encaps en PHB soit remplie comme défini au paragraphe 3.2.


Lorsque il examine une entrée d’étiquette correspondant à un E-LSP entrant pour la détermination du PHB entrant, le LSR :

- détermine la transposition de EXP en PHB en examinant la transposition de Encaps en PHB du contexte Diff-Serv associé dans le ILM à l’étiquette E-LSP entrante considérée ;.

- détermine le PHB entrant en examinant le champ EXP de l’entrée d’étiquette considérée dans le tableau de transposition de EXP en PHB.


3.4 Remplissage des transpositions d’ensemble de PHB <-->Encaps pour un E-LSP sortant

Ce paragraphe définit comment les transpositions d’ensemble de PHB en Encaps du contexte Diff-Serv sont remplies à l’établissement de l’étiquette pour un E-LSP afin de permettre le codage des informations Diff-Serv dans la couche Encapsulation.


3.4.1 Transposition de PHB en EXP

Un E-LSP sortant doit toujours avoir une transposition de PHB en EXP au titre des transpositions d’ensemble de PHB en Encaps de son contexte Diff-Serv.


Si l’étiquette correspond à un E-LSP pour lequel aucune transposition 'EXP<-->PHB' n’a été explicitement signalée à l’établissement du LSP, cette transposition de PHB en EXP est remplie sur la base de la transposition 'EXP<-->PHB' préconfigurée qui est exposée au paragraphe 3.2.1.


Si l’étiquette correspond à un E-LSP pour lequel une transposition 'EXP<-->PHB' a été explicitement signalée à l’établissement du LSP, la transposition de PHB en EXP est remplie comme avec la transposition 'EXP<-->PHB' signalée.


3.4.2 Transposition de PHB en CLP

Si le LSP a sa sortie sur une interface ATM qui n’est pas sous le contrôle de la commutation d’étiquettes, une transposition de PHB en CLP est alors ajoutée aux transpositions d’ensemble de PHB en Encaps pour ce LSP sortant. Cette transposition de PHB en CLP est remplie de la façon suivante :

- c’est une fonction des PHB pris en charge sur ce LSP, et elle peut utiliser les entrées de transposition pertinentes pour ces PHB à partir de la transposition de PHB en CLP par défaut définie au paragraphe 3.4.2.1. Des transpositions autres que celle définie au paragraphe 3.4.2.1 peuvent être utilisées. En particulier, si une transposition des PHB en CLP est normalisée à l’avenir pour le fonctionnement de Diff-Serv sur ATM, une telle transposition normalisée pourra alors être utilisée.


Par exemple, si l’étiquette sortante correspond à un LSP qui prend en charge la PSC AF1, alors, la transposition de PHB en CLP peut être remplie avec :

PHB Champ CLP

AF11 ----> 0

AF12 ----> 1

AF13 ----> 1

EF ----> 0


Remarquer que dans ce cas, les transpositions d’ensemble de PHB en Encaps contiennent les deux transpositions de PHB en EXP et de PHB en CLP.


3.4.2.1 Transposition par défaut de PHB en CLP

PHB bit CLP

DF ----> 0

CSn ----> 0

AFn1 ----> 0

AFn2 ----> 1

AFn3 ----> 1

EF ----> 0


3.4.3 Transposition de PHB en DE

Si la sortie du LSP est sur une interface de relais de trame qui n’est pas sous le contrôle de la commutation d’étiquette, une transposition de PHB en DE est ajoutée aux transpositions d’ensemble de PHB en Encaps pour ce LSP sortant et elle est remplie de la façon suivante :

- c’est une fonction des PHB pris en charge sur ce LSP, et elle peut utiliser les entrées de transposition pertinentes pour ces PHB à partir de la transposition de PHB en DE par défaut définie au paragraphe 3.4.3.1. Des transpositions autres que celle définie au paragraphe 3.4.3.1 peuvent être utilisées. En particulier, si une transposition des PHB en DE est normalisée à l’avenir pour le fonctionnement de Diff-Serv sur relais de trame, une telle transposition normalisée pourra alors être utilisée.


Remarquer que dans ce cas, les transpositions d’ensemble de PHB en Encaps contiennent les deux transpositions de PHB en EXP et de PHB en DE.


3.4.3.1 Transposition par défaut de PHB en DE

PHB bit DE

DF ----> 0

CSn ----> 0

AFn1 ----> 0

AFn2 ----> 1

AFn3 ----> 1

EF ----> 0


3.4.4 Transposition de PHB en 802.1

Si la sortie du LSP est sur une interface de LAN sur laquelle plusieurs classes de trafic 802.1 sont prises en charge comme prévu par [IEEE_802.1], une transposition de PHB en 802.1 est alors ajoutée aux transpositions d’ensemble de PHB en Encaps pour ce LSP sortant. Cette transposition de PHB en 802.1 est remplie de la façon suivante :

- c’est une fonction des PHB pris en charge sur ce LSP, et elle utilise les entrées de transposition pertinentes pour ces PHB à partir de la transposition préconfigurée de PHB en 802.1 définie au paragraphe 3.4.4.1.


Remarquer que les transpositions d’ensemble de PHB en Encaps contiennent alors les deux transpositions de PHB en EXP et de PHB en 802.1.


3.4.4.1 Transposition préconfigurée de PHB en 802.1

Au moment de la publication de la présente spécification, il n’existe pas de transposition normalisée de PHB en classes de trafic 802.1. Par conséquent, un LSR qui prend en charge plusieurs classes de trafic 802.1 sur des interfaces de LAN doit permettre la configuration locale de transposition de PHB en 802.1. Cette transposition s’applique à tous les LSP sortants établis par le LSR sur de telles interfaces de LAN.


3.5 Codage des informations Diff-Serv dans la couche Encapsulation sur le E-LSP sortant

Ce paragraphe définit comment coder les informations Diff-Serv dans la couche d’encapsulation MPLS pour une certaine entrée d’étiquette transmise correspondant à un E-LSP sortant. Cela exige que les transpositions d’ensemble de PHB en Encaps soient remplies comme défini au paragraphe 3.4.


Le LSR détermine d’abord les transpositions d’ensemble de PHB en Encaps du contexte Diff-Serv associé à l’étiquette correspondante dans la NHLFE.


3.5.1 Transposition de PHB en EXP

Si les transpositions d’ensemble de PHB en Encaps contiennent une transposition de la forme transposition de PHB en EXP, alors, le LSR détermine la valeur à écrire dans le champ EXP de l’entrée d’étiquette de niveau correspondante en cherchant le "PHB sortant" dans ce tableau de transposition de PHB en EXP.


3.5.2 Transposition de PHB en CLP

Si les transpositions d’ensemble de PHB en Encaps contiennent une transposition de la forme transposition de PHB en CLP, alors le LSR détermine la valeur à écrire dans le champ CLP de l’en-tête d’encapsulation ATM en recherchant le "PHB sortant" dans ce tableau de transposition de PHB en CLP.


3.5.3 Transposition de PHB en DE

Si les transpositions d’ensemble de PHB en Encaps contiennent une transposition de la forme transposition de PHB en DE, alors le LSR détermine la valeur à écrire dans le champ DE de l’en-tête d’encapsulation de relais de trame en recherchant le "PHB sortant" dans ce tableau de transposition de PHB en DE.


3.5.4 Transposition de PHB en 802.1

Si les transpositions d’ensemble de PHB en Encaps contiennent une transposition de la forme transposition de PHB en 802.1, alors le LSR détermine la valeur à écrire dans le champ Priorité_d’utilisateur des informations de contrôle d’étiquette de l’en-tête d’encapsulation 802.1 [IEEE_802.1], en recherchant le "PHB sortant" dans ce tableau de transposition de PHB en 802.1.


3.6 Fusion de E-LSP

Dans un domaine MPLS, deux LSP ou plus peuvent être fusionnés en un LSP à un LSR. Les E-LSP sont compatibles à la fusion de LSP à la condition suivante :

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


Pour les E-LSP qui utilisent une transposition 'EXP<-->PHB' signalée, la condition de fusion ci-dessus DOIT être mise en application par les LSR par une vérification explicite à 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 qui utilisent la transposition préconfigurée 'EXP<-->PHB', comme les PHB pris en charge sur un E-LSP ne sont pas signalés au moment de l’établissement, un LSR ne peut pas se fier aux informations de signalisation pour mettre en application la fusion. Cependant tous les E-LSP qui utilisent la transposition préconfigurée 'EXP<-->PHB' sont obligés de prendre en charge le même ensemble d’agrégats de comportement au sein d’un certain domaine Diff-Serv MPLS. Donc, la fusion des E-LSP en utilisant la transposition préconfigurée 'EXP<-->PHB' est permise au sein d’un domaine Diff-Serv MPLS.


4. Fonctionnement détaillé des L-LSP

4.1 Définition de L-LSP

Les L-LSP sont définis au paragraphe 1.3.


4.2 Remplissage de transposition de Encaps en PHB pour un L-LSP entrant

Cette section définit comment la transposition de Encaps en PHB du contexte Diff-Serv est remplie à l’établissement de l’étiquette pour un L-LSP entrant afin de permettre la détermination du PHB entrant.


4.2.1 Transposition de EXP en PHB

Si le LSR termine la couche Shim MPLS sur ce L-LSP entrant et si l’entrée du L-LSP est sur une interface qui n’est ni ATM ni relais de trame, la transposition de Encaps en PHB est remplie de la façon suivante :

- c’est réellement une transposition de EXP en PHB,

- cette transposition est une fonction de la PSC qui est portée sur ce LSP, et doit utiliser les entrées de transposition pertinentes pour cette PSC à partir de la transposition de 'EXP/PSC en PHB' obligatoire définie au paragraphe 4.2.1.1.


Par exemple, si l’étiquette entrante correspond à un L-LSP qui prend en charge la PSC AF1, la transposition de Encaps en PHB sera alors remplie avec :

Champ EXP PHB

001 ----> AF11

010 ----> AF12

011 ----> AF13


Un LSR, qui prend en charge les L-LSP sur des interfaces PPP et des interfaces de LAN, est un exemple de LSR terminant la couche Shim sur des interfaces d’entrée qui ne sont ni ATM ni en relais de trame.


Si le LSR termine la couche Shim MPLS sur ce L-LSP entrant et si le L-LSP entre sur une interface ATM ou de relais de trame, la transposition 'Encaps en PHB' est alors remplie de la façon suivante :

- elle devrait en fait être une transposition de 'EXP en PHB'. D’autres façons facultatives de remplir la transposition de 'Encaps en PHB' pourraient être définies à l’avenir (par exemple, en utilisant une transposition de 'CLP/EXP en PHB' ou une transposition de 'DE/EXP en PHB') mais cela sort du domaine d’application du présent document.

- lorsque la 'transposition de Encaps en PHB' est une 'transposition de EXP en PHB', cette 'transposition de EXP en PHB' est une fonction de la PSC qui est portée sur le L-LSP, et doit utiliser les entrées de transposition pertinentes pour cette PSC à partir de la 'transposition de EXP/PSC en PHB' obligatoire définie au paragraphe 4.2.1.1.


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


4.2.1.1 Transposition obligatoire de EXP/PSC en PHB

Champ EXP PSC PHB

000 DF ----> DF

000 CSn ----> CSn

001 AFn ----> AFn1

010 AFn ----> AFn2

011 AFn ----> AFn3

000 EF ----> EF


4.2.2 Transposition de CLP en PHB

Si le LSR ne termine pas une couche Shim MPLS sur cette étiquette entrante et utilise l’encapsulation ATM (c’est-à-dire qu’il est un ATM-LSR) alors la 'transposition de Encaps en PHB' pour ce L-LSP entrant est remplie de la façon suivante :

- c’est en fait une 'transposition de CLP en PHB'

- la transposition est une fonction de la PSC, qui est portée sur ce LSP, et devrait utiliser les entrées de transposition pertinentes pour cette PSC à partir de la 'transposition de CLP/PSC en PHB' par défaut définie au paragraphe 4.2.2.1.


Par exemple, si l’étiquette entrante correspond à un L-LSP qui prend en charge AF1 PSC, alors la 'transposition de Encaps en PHB' devrait être remplie avec :

Champ CLP PHB

0 ----> AF11

1 ----> AF12


4.2.2.1 Transposition par défaut de CLP/PSC en PHB

Bit CLP PSC PHB

0 DF ----> DF

0 CSn ----> CSn

0 AFn ----> AFn1

1 AFn ----> AFn2

0 EF ----> EF


4.2.3 Transposition par défaut de DE en PHB

Si le LSR ne termine pas une couche Shim MPLS sur cette étiquette entrante et utilise l’encapsulation de relais de trame (c’est-à-dire, si c’est un FR-LSR) alors la 'transposition de Encaps en PHB' pour ce L-LSP entrant est remplie de la façon suivante :

- c’est en fait une 'transposition de DE en PHB'

- la transposition est une fonction de la PSC qui est portée sur ce LSP, et devrait utiliser les entrées de transposition pertinentes pour cette PSC à partir de la 'transposition de DE/PSC en PHB' par défaut définie au paragraphe 4.2.3.1.


4.2.3.1 Transposition par défaut de DE/PSC en PHB

bit DE PSC PHB

0 DF ----> DF

0 CSn ----> CSn

0 AFn ----> AFn1

1 AFn ----> AFn2

0 EF ----> EF


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

Ce paragraphe définit comment la détermination du PHB entrant est menée à bien lorsque l’entrée d’étiquette considérée dans la pile d’étiquettes reçue correspond à un L-LSP. Cela exige que la 'transposition de Encaps en PHB' soit remplie comme défini au paragraphe 4.2.


Lorsque on examine une entrée d’étiquette correspondant à un L-LSP entrant pour la détermination du PHB entrant, le LSR détermine d’abord la 'transposition de Encaps en PHB' associée à l’étiquette correspondante.


4.3.1 Transposition de EXP en PHB

Si la 'transposition de Encaps en PHB' est de la forme 'transposition de EXP en PHB', 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 la 'transposition de EXP en PHB'.


4.3.2 Transposition de CLP en PHB

Si la 'transposition de Encaps en PHB' est de la forme 'transposition de CLP en PHB', alors, le LSR détermine le PHB entrant en regardant le champ CLP de l’encapsulation de couche ATM et en utilisant la 'transposition de CLP en PHB'.


4.3.3 Transposition de DE en PHB

Si la 'transposition de Encaps en PHB' est de la forme 'transposition de DE en PHB', alors le LSR détermine le PHB entrant en regardant le champ DE de l’encapsulation de relais de trame et en utilisant la 'transposition de DE en PHB'.


4.4 Remplissage des transpositions d’ensemble de PHB en Encaps pour un L-LSP sortant

Ce paragraphe définit comment la 'transpositions d’ensemble de PHB en Encaps' du contexte Diff-Serv est remplie à l’établissement de l’étiquette pour un L-LSP sortant afin de permettre le codage des informations Diff-Serv.


4.4.1 Transposition de PHB en EXP

Si le LSR utilise une couche Shim MPLS sur ce L-LSP sortant, alors une 'transposition de PHB en EXP' est ajoutée à la 'transpositions d’ensemble de PHB en Encaps' pour ce L-LSP sortant. Cette transposition de 'PHB en EXP' est remplie de la façon suivante :

- c’est une fonction de la PSC prise en charge sur ce LSP, et elle doit utiliser les entrées de transposition pertinentes pour cette PSC à partir de la transposition obligatoire de 'PHB en EXP' définie au paragraphe 4.4.1.1.


Par exemple, si l’étiquette sortante correspond à un L-LSP qui prend en charge la PSC AF1, la transposition de 'PHB en EXP' suivante est alors ajoutée dans les transpositions d’ensemble de PHB en Encaps :

PHB Champ EXP

AF11 ----> 001

AF12 ----> 010

AF13 ----> 011


4.4.1.1 Transpositions obligatoires de PHB en EXP

PHB Champ EXP

DF ----> 000

CSn ----> 000

AFn1 ----> 001

AFn2 ----> 010

AFn3 ----> 011

EF ----> 000


4.4.2 Transposition de PHB en CLP

Si la sortie du L-LSP est sur une interface ATM (c’est-à-dire, si c’est un ATM-LSR ou si c’est un LSR à base de trame qui envoie des paquets sur une interface LC-ATM ou sur une interface ATM qui n’est pas contrôlée par la commutation d’étiquettes) une transposition de 'PHB en CLP' est alors ajoutée aux 'transpositions d’ensemble de PHB en Encaps' pour ce L-LSP sortant.


Si la sortie du L-LSP est sur une interface ATM qui n’est pas contrôlée par étiquette, la transposition de 'PHB en CLP' est remplie selon le paragraphe 3.4.2.


Si la sortie du L-LSP est sur une interface LC-ATM, la transposition de 'PHB en CLP' est remplie de la façon suivante :

- c’est une fonction de la PSC prise en charge sur ce LSP, et elle devrait utiliser les entrées de transposition pertinentes pour cette PSC à partir de la transposition de 'PHB en CLP' par défaut définie au paragraphe 3.4.2.1.


Remarquer que si le LSR est fondé sur la trame et prend en charge un L-LSP qui sort sur une interface ATM, alors les 'transpositions d’ensemble de PHB en Encaps' contiennent les deux transpositions de 'PHB en EXP' et de 'PHB en CLP'. Si le LSR est un LSR ATM qui prend en charge un L-LSP, alors les 'transpositions d’ensemble de PHB en Encaps' ne contiennent qu’une transposition de 'PHB en CLP'.


4.4.3 Transposition de PHB en DE

Si la sortie du L-LSP est sur une interface de relais de trame (c’est-à-dire, si c’est un LSR qui envoie des paquets sur une interface LC-FR ou une interface de relais de trame qui n’est pas sous contrôle de la commutation d’étiquette) une transposition de 'PHB en DE' est ajoutée aux 'transpositions d’ensemble de PHB en Encaps' pour ce L-LSP sortant.


Si le L-LSP sort sur une interface FR qui n’est pas sous le contrôle de la commutation d’étiquette, la transposition de 'PHB en DE' est remplie selon le paragraphe 3.4.3.


Si le L-LSP sort sur une interface LC-FR, la transposition de 'PHB en DE' est remplie de la façon suivante :

- c’est une fonction de la PSC prise en charge sur ce LSP, et elle devrait utiliser les entrées de transposition pertinentes pour cette PSC à partir de la transposition de 'PHB en DE' par défaut définie au paragraphe 3.4.3.1.


Remarquer que si le LSR est un LSR bordure qui prend en charge un L-LSP qui sort sur une interface LC-FR, les 'transpositions d’ensemble de PHB en Encaps' contiennent alors les deux transpositions de 'PHB en EXP' et de 'PHB en DE'. Si le LSR est un FR-LSR qui prend en charge un L-LSP, alors, les 'transpositions d’ensemble de PHB en Encaps' ne contiennent qu’une transposition de 'PHB en DE'.


4.4.4 Transposition de PHB en 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 une transposition de 'PHB en 802.1' est ajouté comme indiqué au paragraphe 3.4.4.


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

Ce paragraphe 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 les 'transpositions d’ensemble de PHB en Encaps' soient remplies comme défini au paragraphe 4.4.


Le LSR détermine d’abord les 'transpositions d’ensemble de PHB en Encaps' du contexte Diff-Serv associé à l’étiquette correspondante dans la NHLFE, puis effectue le codage correspondant comme spécifié aux paragraphes 3.5.1, 3.5.2, 3.5.3 et 3.5.4.


4.6 Fusion de L-LSP

Dans un domaine MPLS, deux LSP ou plus peuvent être fusionnés en un seul LSP à un LSR. Les L-LSP sont compatibles avec la fusion de LSP à la condition suivante :


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


La condition de fusion ci-dessus DOIT être mise en application par les LSR par une vérification explicite, à l’établissement de l’étiquette, que la même PSC est prise en charge sur les LSP fusionnés.


Noter que lors de la fusion des L-LSP, la bande passante qui est disponible pour la PSC à l’aval du point de fusion doit être suffisante pour porter la somme des trafics fusionnés. Ceci est particulièrement important dans le cas de trafic EF. On peut s’en assurer de multiples façons (par exemple, via l’approvisionnement, ou via la signalisation de la bande passante et le contrôle d’admission explicite).


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


L’architecture MPLS ne postule pas un seul protocole de distribution d’étiquettes. La [RFC3209] définit une extension à RSVP pour l’établissement des LSP dans les réseaux MPLS. La présente section spécifie les extensions à RSVP, au delà de celles définies dans la [RFC3209], pour établir des LSP qui prennent en charge les services différenciés dans les réseaux MPLS.


5.1 Format des messages RSVP qui se rapportent à Diff-Serv

Un nouvel objet RSVP est défini dans le présent document : l’objet DIFFSERV. Une description détaillée de cet objet est donnée ci-dessous. Ce nouvel objet est applicable aux messages Path. La présente spécification définit seulement l’utilisation de l’objet DIFFSERV dans les messages Path utilisés pour établir des tunnels LSP conformément à la [RFC3209] et contient donc un objet Session avec un C-Type égal à LSP_TUNNEL_IPv4 et un objet Demande d’étiquette.


Les restrictions définies dans la [RFC3209] pour la prise en charge de l’établissement de tunnels LSP via RSVP sont aussi applicables à l’établissement des tunnels LSP qui prennent en charge Diff-Serv : par exemple, seuls les LSP en envoi individuel sont pris en charge et les LSP en diffusion groupée seront étudiés ultérieurement.


Ce nouvel objet DIFFSERV est facultatif par rapport à RSVP de sorte que les mises en œuvre générales de RSVP qui ne sont pas concernées par l’établissement de LSP MPLS n’ont pas à prendre cet objet en charge.


L’objet DIFFSERV est facultatif pour la prise en charge de tunnels LSP comme défini dans la [RFC3209]. Un LSR à capacité Diff-Serv qui prend en charge des E-LSP en utilisant la transposition préconfigurée 'EXP<-->PHB' en conformité avec la présente spécification PEUT prendre en charge l’objet DIFFSERV. Un LSR à capacité Diff-Serv qui prend en charge les E-LSP en utilisant une transposition signalée 'EXP<-->PHB' conformément à la présente spécification DOIT prendre en charge l’objet DIFFSERV. Un LSR à capacité Diff-Serv qui prend en charge les L-LSP conformément à la présente spécification DOIT prendre en charge l’objet DIFFSERV.


5.1.1 Format du message Path

Le format du message Path est le suivant :


<Message Path> ::= <En-tête commun> [ <INTÉGRITÉ> ]

<SESSION> <RSVP_SAUT>

<VALEURS_HORAIRES>

[ <CHEMIN_EXPLICITE> ]

<DEMANDE_D’ÉTIQUETTE>

[ <ATTRIBUT_DE_SESSION> ]

[ <DIFFSERV> ]

[ <DONNÉES_DE_POLITIQUE> ... ]

[ <descripteur d’envoyeur> ]


<descripteur d’envoyeur> ::= <GABRIT_D’ENVOYEUR> <TSPEC_D’ENVOYEUR>

[ <ADSPEC> ]

[ <RECORD_ROUTE> ]


5.2 Objet DIFFSERV

Les formats de l’objet DIFFSERV sont donnés ci-dessous. Il y a 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

classe = 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Réservé | MAPnb |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MAP (1) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

// ... //

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MAP (MAPnb) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Réservé : 28 bits

Ce champ est réservé. Il doit être réglé à zéro à l’émission et doit être ignoré à réception.


MAPnb : 4 bits

Indique le nombre d’entrées de MAP incluses dans l’objet DIFFSERV. Il peut être réglé à toute valeur de 0 à 8.


MAP : 32 bits

Chaque entité MAP définit la transposition 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Réservé | EXP | PHBID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Réservé : 13 bits

Ce champ est réservé. Il doit être réglé à zéro à l’émission et doit être ignoré à réception.


EXP : 3 bits

Ce champ contient la valeur du champ EXP pour la transposition 'EXP<-->PHB' définie dans cette entrée MAP.


PHBID : 16 bits

Ce champ contient le PHBID du PHB pour la transposition 'EXP<-->PHB' définie dans cette entrée MAP. Le PHBID est codé comme spécifié dans la [RFC3140].


5.2.2 Objet DIFFSERV pour un L-LSP

classe = 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Réservé | PSC |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Réservé : 16 bits

Ce champ est réservé. Il doit être réglé à zéro à l’émission et doit être ignoré à réception.


PSC : 16 bits

La PSC indique une classe de programmation de PHB à prendre en charge par le LSP. La PSC est codée comme spécifié dans la [RFC3140].


5.3 Traitement de l’objet DIFFSERV

Pour établir un LSP tunnel avec RSVP, l’envoyeur crée un message Path avec un type de session de LSP_Tunnel_IPv4 et avec un objet DEMANDE_D’ÉTIQUETTE comme défini dans la [RFC3209].


Pour établir un E-LSP tunnel avec RSVP, qui utilise la transposition préconfigurée 'EXP<-->PHB', l’envoyeur crée un message Path :

- avec un type de session de LSP_Tunnel_IPv4,

- avec l’objet DEMANDE_D’ÉTIQUETTE, et

- sans l’objet DIFFSERV.


Pour établir un E-LSP tunnel avec RSVP, qui utilise la transposition préconfigurée 'EXP<-->PHB', l’envoyeur PEUT autrement créer un message Path :

- avec un type de session de LSP_Tunnel_IPv4,

- avec l’objet DEMANDE_D’ÉTIQUETTE, et

- avec l’objet DIFFSERV pour un E-LSP ne contenant pas d’entrée MAP.


Pour établir un E-LSP tunnel avec RSVP, qui utilise une transposition signalée 'EXP<-->PHB', l’envoyeur crée un message Path :

- avec un type de session de LSP_Tunnel_IPv4,

- avec l’objet DEMANDE_D’ÉTIQUETTE,

- avec l’objet DIFFSERV pour un E-LSP contenant une entrée MAP pour chaque valeur d’EXP à prendre en charge sur cet E-LSP.


Pour établir avec RSVP un L-LSP, l’envoyeur crée un message Path :

- avec un type de session de LSP_Tunnel_IPv4,

- avec l’objet DEMANDE_D’ÉTIQUETTE,

- avec l’objet DIFFSERV pour un L-LSP contenant la classe de programmation de PHB (PSC, PHB Scheduling Class) prise en charge sur ce L-LSP.


Si un message Path contient plusieurs objets DIFFSERV, seul le premier est significatif ; les objets DIFFSERV suivants doivent être ignoré et ne pas être transmis.


Chaque LSR le long du chemin enregistre l’objet DIFFSERV, lorsqu’il est présent, dans son bloc d’état de chemin.


Si un objet DIFFSERV n’est pas présent dans le message Path, le LSR DEVRAIT interpréter cela comme une demande pour un E-LSP utilisant la transposition préconfigurée 'EXP<-->PHB'. Cependant, pour les besoins de rétro compatibilité avec les autres options de qualité de service non Diff-Serv permises par la [RFC3209] comme les services intégrés de charge contrôlée ou de service garanti, le LSR PEUT prendre en charge une "option d’outrepassement" configurable. Lorsque l’option "d’outrepassement" 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 pas d’entrée de MAP est présent dans le message Path, le LSR DOIT interpréter cela comme une demande d’un E-LSP utilisant la transposition préconfigurée 'EXP<-->PHB'. En particulier, cela permet à un LSR avec l’option "outrepasser" configurée de prendre en charge les E-LSP avec la transposition préconfigurée de 'EXP<-->PHB', simultanément avec les LSP avec la qualité de service non Diff-Serv.


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


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


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

- avec l’objet ÉTIQUETTE

- sans l’objet DIFFSERV.


En supposant que la demande d’étiquette est acceptée et qu’une étiquette est allouée, les LSR Diff-Serv (de nœud d’envoi, de destination, et intermédiaires) doivent :

- mettre à jour le contexte Diff-Serv associé aux LSP établis dans leur ILM/FTN comme spécifié dans les paragraphes précédents (étiquette entrante et sortante),

- installer le traitement de transmission Diff-Serv exigé (comportement de programmation et d’abandon) 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 l’objet DEMANDE_D’ÉTIQUETTE ou qui n’a pas un type de session de LSP_Tunnel_IPv4, envoie un PathErr vers l’envoyeur avec le code d’erreur 'Erreur Diff-Serv' et une valeur d’erreur de 'Objet DIFFSERV inattendu'. Ceux-ci sont définis au paragraphe 5.5.


Un LSR qui reçoit un message Path avec l’objet DIFFSERV pour un 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 de MAP, envoie une PathErr vers l’envoyeur avec le code d’erreur 'Erreur Diff-Serv' et une valeur d’erreur de 'PHB non pris en charge'. Ceux-ci sont définis au paragraphe 5.5.


Un LSR qui reçoit un message Path avec l’objet DIFFSERV pour un E-LSP qui reconnaît l’objet DIFFSERV mais détermine que la transposition signalée de 'EXP<-->PHB' est invalide, envoie une PathErr à l’envoyeur avec le code d’erreur 'Erreur Diff-Serv' et une valeur d’erreur de transposition 'EXP<-->PHB' invalide. Ceux-ci sont définis au paragraphe 5.5. La transposition 'EXP<-->PHB' signalée dans l’objet DIFFSERV pour un E-LSP est invalide lorsque :

- le champ MAPnb n’est pas dans la gamme de 0 à 8 ou

- une certaine valeur d’EXP apparaît dans plus d’une entrée de MAP, ou

- le codage du PHBID est invalide.


Un LSR qui reçoit un message Path avec l’objet DIFFSERV pour un L-LSP qui reconnaît l’objet DIFFSERV mais ne prend pas en charge la PSC particulière codée dans le champ PSC envoie une PathErr à l’envoyeur avec le code d’erreur 'Erreur Diff-Serv' et une valeur d’erreur de 'PSC non prise en charge'. Ceux-ci sont définis au paragraphe 5.5.


Un LSR qui reçoit un message Path avec l’objet DIFFSERV, qui reconnaît l’objet DIFFSERV mais est incapable d’allouer le contexte Diff-Serv par LSP exigé envoie une PathErr avec le code d’erreur "Erreur Diff-Serv" et la valeur d’erreur "Échec d’allocation de contexte par LSP". Ceux-ci sont définis au paragraphe 5.5.


Un LSR Diff-Serv DOIT traiter les situations om la demande d’étiquette ne peut pas être acceptée pour des raisons autres que celles déjà exposées dans cette section, conformément à la [RFC3209] (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 l’objet DIFFSERV Class-Num DOIT se comporter conformément aux procédures spécifiées dans la [RFC2205] pour un Class-Num inconnu dont le format est 0bbbbbbb, c’est-à-dire qu’il doit envoyer une PathErr avec le code d’erreur 'Classe d’objet inconnue' à l’envoyeur.


Un LSR qui reconnaît l’objet DIFFSERV Class-Num mais ne reconnaît pas l’objet DIFFSERV C-Type, doit se comporter conformément aux procédures spécifiées dans la [RFC2205] pour un C-type inconnu, c’est-à-dire qu’il doit envoyer une PathErr avec le code d’erreur 'Objet C-Type inconnu' à l’envoyeur.


Dans les deux situations, cela cause l’échec de l’établissement du chemin. L’envoyeur devrait notifier au gestionnaire 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 la transposition préconfigurée 'EXP<-->PHB' 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 rapportées comme des 'Erreur Diff-Serv'. La valeur du code de 'Erreur Diff-Serv' est 27.


Les valeurs d’erreur suivantes sont définies pour 'Erreur Diff-Serv' :


Valeur Erreur

1 Objet DIFFSERV inattendu

2 PHB non accepté

3 Transposition 'EXP<-->PHB' invalide

4 PSC non acceptée

5 Échec d’allocation de contexte par LSP


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 la [RFC3209], pour établir un E-LSP ou un L-LSP avec réservation de bande passante, le service à charge contrôlée de Int-Serv (ou éventuellement le service garanti) est utilisé et la bande passante est signalée dans le SENDER_TSPEC (respectivement la FLOWSPEC) du message Path (respectivement, le message Resv).


Comme spécifié dans la [RFC3209], pour établir un E-LSP ou un L-LSP sans réservation de bande passante, le service Null spécifié dans la [RFC2997] est utilisé.


Noter que la présente spécification définit l’usage des E-LSP et des L-LSP seulement pour la prise en charge du service Diff-Serv. Sans considération du service Intserv (Charge contrôlée, Service Null, Service garanti,...) et sans considération de ce que la réservation est avec ou sans réservation de bande passante, les E-LSP et les 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 cœur de réseau Diff-Serv MPLS est en dehors du domaine d’application de la présente spécification.


Noter aussi que la présente spécification ne s’occupe pas de l’objet DCLASS défini dans la [RFC2996], car cet objet porte des informations sur les valeurs des DSCP, ce qui n’est pas pertinent au sein du réseau MPLS.


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


L’architecture MPLS ne postule pas un seul protocole de distribution d’étiquettes. La [RFC3036] définit le protocole de distribution d’étiquettes et son usage pour l’établissement de chemins à commutation d’étiquettes (LSP, Label Switching Path) dans les réseaux MPLS. La présente section spécifie les extensions à LDP pour établir des LSP qui prennent en charge les services différenciés dans les réseaux MPLS.


Un nouveau TLV LDP est défini dans le présent document : le TLV Diff-Serv.


Une description détaillée de ce TLV est donnée ci-dessous.


Le nouveau TLV Diff-Serv est facultatif par rapport à LDP. Un LSR à capacité Diff-Serv qui prend en charge les E-LSP et qui utilise la transposition préconfigurée 'EXP<-- >PHB' en conformité avec la présente spécification PEUT prendre en charge le TLV Diff-Serv. Un LSR à capacité Diff-Serv qui prend en charge les E-LSP et qui utilise la transposition signalée 'EXP<-->PHB' en conformité avec la présente spécification DOIT prendre en charge le TLV Diff-Serv. Un LSR à capacité Diff-Serv qui prend en charge les L-LSP en conformité avec la présente spécification DOIT prendre en charge le TLV Diff-Serv.


6.1 TLV Diff-Serv

Le 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) | Longueur |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|T| Réservé | MAPnb |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MAP (1) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| MAP (MAPnb) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


T : 1 bit

Type de LSP . Il est réglé à 0 pour un E-LSP.


Réservé : 27 bits

Ce champ est réservé. Il doit être réglé à zéro à l’émission et doit être ignoré à réception.


MAPnb : 4 bits

Indique le nombre d’entrées de MAP incluses dans l’objet DIFFSERV. Il peut être réglé à toute valeur de 1 à 8.


MAP : 32 bits

Chaque entrée de MAP définit les transpositions entre une valeur de champ EXP et un PHB. L’entrée de 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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Réservé | EXP | PHBID |

+---------------+---------------+---------------+---------------+


Réservé : 13 bits

Ce champ est réservé. Il doit être réglé à zéro à l’émission et doit être ignoré à réception.


EXP : 3 bits

Ce champ contient la valeur du champ EXP pour la transposition 'EXP<-->PHB' définie dans cette entrée de MAP.


PHBID : 16 bits

Ce champ contient le PHBID du PHB pour la transposition 'EXP<-->PHB' définie dans cette entrée de MAP. Le PHBID est codé comme spécifié dans la [RFC3140].


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) | Longueur |

+---------------+---------------+---------------+---------------+

|T| Réservé | PSC |

+---------------+---------------+---------------+---------------+


T : 1 bit

Type de LSP . Il est réglé à 1 pour un L-LSP.


Réservé : 15 bits

Ce champ est réservé. Il doit être réglé à zéro à l’émission et doit être ignoré à réception.


PSC : 16 bits

La PSC indique une classe de programmation de PHB à prendre en charge par le LSP. La PSC est codée comme spécifié dans la [RFC3140].


6.2 Valeurs de code d’état Diff-Serv

Les valeurs suivantes sont définies pour le champ Code d’état du TLV État :


Code d’état

E

Données d’état

TLV Diff-Serv inattendu

0

0x01000001

PHB non accepté

0

0x01000002

Transposition 'EXP<-->PHB' invalide

0

0x01000003

PSC non acceptée

0

0x01000004

Échec d’allocation de contexte par LSP

0

0x01000005


6.3 Messages Diff-Serv en rapport avec LDP

6.3.1 Message Demande d’étiquette

Le format du message Demande d’étiquette est étendu comme suit, pour inclusion facultative du 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| Demande d’étiquette (0x0401)| Longueur du message |

+---------------+---------------+---------------+---------------+

| Identifiant de message |

+---------------+---------------+---------------+---------------+

| TLV FEC |

+---------------+---------------+---------------+---------------+

| TLV Diff-Serv (facultatif) |

+---------------+---------------+---------------+---------------+


6.3.2 Message Transposition d’étiquette

Le format du message Transposition d’étiquette est étendu comme suit pour inclusion facultative du 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| Traspo. d’étiquette (0x0400)| Longueur du message |

+---------------+---------------+---------------+---------------+

| Identifiant de message |

+---------------+---------------+---------------+---------------+

| TLV FEC |

+---------------+---------------+---------------+---------------+

| TLV d’étiquette |

+---------------+---------------+---------------+---------------+

| TLV Diff-Serv (facultatif) |

+---------------+---------------+---------------+---------------+


6.3.3 Message Libération d’étiquette

Le format du message Libération d’étiquette est étendu comme suit, pour inclusion facultative du TLV État :


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| Libé. d’étiquette (0x0403) | Longueur de message |

+---------------+---------------+---------------+---------------+

| Identifiant de message |

+---------------+---------------+---------------+---------------+

| TLV FEC |

+---------------+---------------+---------------+---------------+

| TLV Étiquette (facultatif) |

+---------------+---------------+---------------+---------------+

| TLV État (facultatif) |

+---------------+---------------+---------------+---------------+


6.3.4 Message Notification

Le format du message Notification est étendu comme suit, pour inclusion facultative du 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) | Longueur du message |

+---------------+---------------+---------------+---------------+

| Identifiant de message |

+---------------+---------------+---------------+---------------+

| TLV État |

+---------------+---------------+---------------+---------------+

| Paramètres facultatifs |

+---------------+---------------+---------------+---------------+

| TLV Diff-Serv (facultatif) |

+---------------+---------------+---------------+---------------+


6.4 Traitement du TLV Diff-Serv

6.4.1 Traitement du TLV Diff-Serv en mode non sollicité vers l’aval

La présente section décrit les opérations lorsque le mode vers l’aval non sollicité est utilisé.


Lors de l’allocation d’une étiquette pour un E-LSP qui va utiliser la transposition préconfigurée 'EXP<-->PHB', un LSR Diff-Serv aval produit un message Transposition d’étiquette sans le TLV Diff-Serv.


Lors de l’allocation d’une étiquette pour un E-LSP qui va utiliser une transposition signalée 'EXP<-->PHB', un LSR Diff-Serv aval produit un message Transposition d’étiquette avec le TLV Diff-Serv pour un E-LSP qui contient une entrée de MAP pour chaque valeur EXP à prendre en charge sur ce E-LSP.


Lors de l’allocation d’une étiquette pour un L-LSP, un LSR Diff-Serv aval produit un message Transposition d’étiquette avec le TLV Diff-Serv pour un L-LSP qui contient la classe de programmation de PHB (PSC) à prendre en charge sur ce L-LSP.


En supposant que l’établissement de l’étiquette a réussi, les LSR d’aval et d’amont doivent :

- mettre à jour le contexte Diff-Serv associé aux LSP établis dans leurs ILM/FTN comme spécifié dans les paragraphes précédents (étiquette entrante et sortante) :

- installer le traitement de transmission Diff-Serv exigé (comportement de programmation et d’abandon) pour cette NHLFE (étiquette sortante).


Un LSR Diff-Serv amont qui reçoit un message Transposition d’étiquette avec plusieurs TLV Diff-Serv ne prend en compte comme significatif que le premier. Le LSR doit ignorer et ne pas transmettre les TLV Diff-Serv suivants.


Un LSR Diff-Serv amont qui reçoit un message Transposition d’étiquette, avec le TLV Diff-Serv pour un E-LSP et qui ne prend pas en charge le PHB particulier codé dans une ou plusieurs des entrées de MAP, doit rejeter la transposition en envoyant un message Libération d’étiquette qui inclut le TLV Étiquette et le TLV État avec un code d’état de 'PHB non accepté'.


Un LSR Diff-Serv amont qui reçoit un message Transposition d’étiquette avec le TLV Diff-Serv pour un E-LSP et qui détermine que la transposition 'EXP<-->PHB' signalée est invalide, doit rejeter la transposition en envoyant un message Libération d’étiquette qui inclut le TLV Étiquette et le TLV État avec un code d’état de transposition 'EXP<-->PHB' invalide. La transposition 'EXP<-->PHB' signalée dans l’objet DIFFSERV pour un E-LSP est invalide lorsque :

- le champ MAPnb n’est pas dans la gamme de 1 à 8, ou

- qu’une certaine valeur EXP apparaît dans plus d’une entrée de MAP, ou

- que le codage du PHBID est invalide.


Un LSR Diff-Serv amont qui reçoit un message Transposition d’étiquette avec le TLV Diff-Serv pour un L-LSP qui contient une valeur de PSC qui n’est pas acceptée doit rejeter la transposition en envoyant un message Libération d’étiquette qui inclut le TLV Étiquette et le TLV État avec un code d’état de 'PSC non acceptée'.


6.4.2 Traitement du TLV Diff-Serv en mode vers l’aval à la demande

Ce paragraphe décrit les opérations lorsque le mode vers l’aval à la demande est utilisé.


Lorsque il demande une étiquette pour un E-LSP qui va utiliser la transposition préconfigurée 'EXP<-->PHB', un LSR Diff-Serv amont envoie un message Demande d’étiquette sans le TLV Diff-Serv.


Lorsque il demande une étiquette pour un E-LSP qui va utiliser la transposition signalée 'EXP<-->PHB', un LSR Diff-Serv amont envoie un message Demande d’étiquette avec le TLV Diff-Serv pour un E-LSP qui contient une entrée de MAP pour chaque valeur EXP à prendre en charge sur ce E-LSP.


Lorsque il demande une étiquette pour un L-LSP, un LSR Diff-Serv amont envoie un message Demande d’étiquette avec le TLV Diff-Serv pour un L-LSP qui contient la PSC à prendre en charge sur ce L-LSP.


Un LSR amont Diff-Serv qui envoie un message Transposition d’étiquette en réponse à un message Demande d’étiquette pour un E-LSP ou un L-LSP ne doit pas inclure de TLV Diff-Serv dans son message Transposition d’étiquette. En supposant que l’établissement de l’étiquette a réussi, les LSR amont et aval doivent :

- mettre à jour le contexte Diff-Serv associé aux LSP établis dans leurs ILM/FTN comme spécifié aux paragraphes précédents (étiquette entrante et sortante) ;

- installer le traitement de transmission Diff-Serv requis (comportement de programmation et d’abandon) pour cette NHLFE (étiquette sortante).


Un LSR Diff-Serv amont qui reçoit un message Transposition d’étiquette qui contient un TLV Diff-Serv en réponse à son message Demande d’étiquette, doit rejeter la transposition d’étiquette en envoyant un message Libération d’étiquette qui inclut le TLV Étiquette et le TLV État avec un code d’état de 'TLV Diff-Serv inattendu'.


Un LSR Diff-Serv aval qui reçoit un message Demande d’étiquette avec plusieurs TLV Diff-Serv ne considère comme significatif que le premier d’entre eux. Le LSR doit ignorer et ne pas transmettre les TLV Diff-Serv suivants.


Un LSR Diff-Serv aval qui reçoit un message Demande d’étiquette avec le TLV Diff-Serv pour un E-LSP et qui n’accepte pas le PHB particulier codé dans une (ou plusieurs) des entrées de MAP, doit rejeter la demande en envoyant un message Notification qui inclut le TLV État avec un code d’état de 'PHB non accepté'.


Un LSR Diff-Serv aval qui reçoit un message Demande d’étiquette avec le TLV Diff-Serv pour un E-LSP et détermine que la transposition signalée 'EXP<-->PHB' est invalide doit rejeter la demande en envoyant un message Notification qui inclut le TLV État avec un code d’état de 'Transposition EXP<-->PHB invalide'. La transposition 'EXP<-->PHB' signalée dans le TLV DIFFSERV pour un E-LSP est invalide lorsque :

- le champ MAPnb n’est pas dans la gamme de 1 à 8, ou

- une certaine valeur de EXP apparaît dans plus d’une entrée de MAP, ou

- le codage du PHBID est invalide.


Un LSR Diff-Serv aval qui reçoit un message Demande d’étiquette avec le TLV Diff-Serv pour un L-LSP contenant une valeur de PSC qui n’est pas acceptée doit rejeter la demande en envoyant un message Notification qui inclut le TLV État avec un code d’état de 'PSC non acceptée'.


Un LSR Diff-Serv aval qui reconnaît le type de TLV Diff-Serv dans un message Demande d’étiquette mais est incapable d’allouer les informations de contexte par LSP requises, doit rejeter la demande en envoyant un message Notification qui inclut le TLV État avec un code d’état de 'Échec d’allocation de contexte par LSP '.


Un LSR Diff-Serv aval qui reconnaît le type de TLV Diff-Serv dans un message Demande d’étiquette et prend en charge la PSC demandée mais n’est pas capable de satisfaire la demande d’étiquette pour d’autres raisons (par exemple, pas d’étiquette disponible) doit envoyer un message Notification en conformité avec les procédures existantes de LDP de la [RFC3036] (par exemple, avec un code d’état 'Pas de ressource d’étiquette' ). Ce message Notification doit inclure le TLV Diff-Serv demandé.


6.5 Non traitement du TLV Diff-Serv

Un LSR qui ne reconnaît pas le type de TLV Diff-Serv, à réception d’un message Demande d’étiquette ou d’un message Transposition d’étiquette contenant le TLV Diff-Serv doit se comporter conformément aux procédures spécifiées dans la [RFC3036] pour un TLV inconnu dont le bit U et le bit F sont réglés à 0, c’est-à-dire qu’il doit ignorer le message, retourner un message Notification avec le code d’état 'TLV inconnu'.


6.6 Informations de bande passante

Les informations de bande passante peuvent aussi être signalées au moment de l’établissement du E-LSP et du L-LSP, par exemple pour les besoins de l’ingénierie du trafic, en utilisant le TLV Paramètres de trafic, comme décrit au paragraphe 4.3 de la [RFC3212].


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


Les opérations générales pour la prise en charge de Diff-Serv par MPLS, y compris la transmission d’étiquettes et l’établissement de LSP sont spécifiées dans les sections précédentes. La présente section décrit les opérations spécifiques exigées pour la prise en charge par MPLS de Diff-Serv sur les interfaces PPP, les interfaces de LAN, les interfaces ATM qui ne sont pas contrôlées par étiquettes et les interfaces de relais de trame qui ne sont pas contrôlées par étiquettes.


Sur ces interfaces, la présente spécification permet toutes les combinaisons de MSP par FEC suivantes :

- zéro ou un nombre quelconque de E-LSP, et

- zéro ou tout nombre de L-LSP.


Un LSR à capacité Diff-Serv DOIT prendre en charge les E-LSP qui utilisent la transposition 'EXP<-->PHB' préconfigurée sur ces interfaces.


Un LSR à capacité Diff-Serv PEUT prendre en charge les E-LSP qui utilisent la transposition 'EXP<-->PHB' signalée et les L-LSP sur ces interfaces.


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


La présente section décrit les opérations spécifiques requises pour la prise en charge par MPLS de Diff-Serv sur les interfaces ATM contrôlées par commutation d’étiquettes (LC-ATM).


Le présent document permet tout nombre de L-LSP par FEC au sein d’un domaine Diff-Serv ATM MPLS. Les E-LSP ne sont pas acceptés sur les interfaces LC-ATM.


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

L’utilisation des "catégories de service ATM" spécifiées par le Forum ATM, des "capacités de transfert ATM" spécifiées par l’UIT-T ou de classes de trafic ATM spécifiques de fabricants sortent du domaine d’application de la présente spécification. La seule exigence de conformité pour une mise en œuvre est que le comportement de transmission subi par un agrégat de comportement transmis sur un L-LSP par le LSR ATM DOIT être conforme aux spécifications correspondantes de PHB Diff-Serv.


Comme il n’y a qu’un seul bit (CLP) pour coder la valeur de préséance d’abandon d’un PHB sur les liaisons ATM, seuls deux niveaux différents de préséance d’abandon sont acceptés par les LSR ATM. Les paragraphes 4.2.2 et 4.4.2 définissent comment les trois niveaux de préséance d’abandon des agrégats ordonnés AFn sont transposés en ces deux niveaux de préséance d’abandon ATM. Cette transposition est en accord avec les exigences spécifiées dans la [RFC2597] pour le cas où seuls deux niveaux de préséance d’abandon sont acceptés.


Pour éviter d’éliminer des parties des paquets, des mécanismes d’élimination de trame, comme l’élimination précoce de paquet (EPD, Early Packet Discard) (voir [ATMF_TM]) DEVRAIENT être activés dans les LSR ATM pour tous les PHB décrits dans le présent document.


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

Un LSR à capacité Diff-Serv DOIT prendre en charge les L-LSP sur les interfaces LC-ATM. La présente spécification suppose que les LSR bordures du domaine ATM-LSR utilisent la méthode d’encapsulation "d’en-tête Shim" définie dans la [RFC3035]. Le fonctionnement sans encapsulation de "l’en-tête Shim" sort du domaine d’application de la présente spécification.


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


La présente section décrit les opérations spécifiques exigées pour la prise en charge par MPLS de Diff-Serv sur des interfaces en relais de trame contrôlées par commutation d’étiquettes (LC-FR).


Le présent document permet tout nombre de L-LSP par FEC au sein d’un domaine Diff-Serv MPLS en relais de trame. Les E-LSP ne sont pas acceptés sur les interfaces LC-FR.


9.1 Utilisation des paramètres de trafic de relais de trame et mécanismes de gestion du trafic

L’utilisation des paramètres de trafic en relais de trame comme spécifiée par l’UIT-T et le Forum Relais de trame ou de mécanismes de gestion du trafic de relais de trame spécifiques du fabricant sort du domaine d’application de la présente spécification. La seule exigence pour la conformité des mises en œuvre est que le comportement de transmission subi par un agrégat de comportement transmis sur un L-LSP par le LSR de relais de trame DOIT être conforme à la spécification du PHB Diff-Serv correspondant.


Comme il n’y a qu’un seul bit (DE) pour coder la valeur de préséance d’abandon du PHB sur les liaisons en relais de trame, seuls deux niveaux différents de préséance d’abandon sont pris en charge dans les LSR en relais de trame. Les paragraphes 4.2.3 et 4.4.3 définissent comment les trois niveaux de préséance d’abandon des agrégats ordonnés AFn sont transposés en ces deux niveaux de préséance d’abandon du relais de trame. Cette transposition est conforme aux exigences spécifiées dans la [RFC2597] pour le cas où seuls deux niveaux de préséance d’abandon sont pris en charge.


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

Un LSR à capacité Diff-Serv DOIT prendre en charge les L-LSP sur les interfaces LC en relais de trame.


La présente spécification suppose que les LSR bordures du domaine FR-LSR utilisent la méthode "d’encapsulation générique" recommandée dans la [RFC3034]. Le fonctionnement sans "encapsulation générique" sort du domaine d’application de la présente spécification.


10. Considérations relatives à l’IANA


Le présent document définit un certain nombre d’objets qui ont des implications pour l’IANA.


Le présent document définit au paragraphe 5.2 un nouvel objet RSVP, l’objet DIFFSERV. Cet objet exige une certaine partie de l’espace défini dans la [RFC2205] pour ces objets qui, si il ne sont pas compris, cause le rejet du message RSVP entier avec un code d’erreur de "Classe d’objet inconnue". De tels objets sont identifiés par un zéro dans le bit de plus fort poids du numéro de classe. Au sein de cet espace, cet objet exige un numéro tiré de l’espace "Consensus de l’IETF". "65" a été alloué par l’IANA à l’objet DIFFSERV.


Le présent document définit au paragraphe 5.5 un nouveau code d’erreur RSVP, "Erreur Diffserv". Le code d’erreur "27" a été alloué par l’IANA à "Erreur Diffserv". Le présent document définit les valeurs de 1 à 5 du champ Valeur pour être utilisées au sein de l’objet ERROR_SPEC pour ce code d’erreur. Les futures allocations de valeurs dans cet espace devraient être traitées par l’IANA selon la politique du premier qui demande, premier servi définie dans la [RFC2434].


Le présent document définit au paragraphe 6.1 un nouveau TLV LDP, le TLV Diffserv. Le numéro pour ce TLV a été alloué par consensus du groupe de travail, conformément aux politiques définies dans la [RFC3036].


Le présent document définit au paragraphe 6.2 cinq nouvelles valeurs de code d’état de LDP pour les conditions d’erreur en rapport avec Diff-Serv. Les valeurs pour le code État ont été allouées par consensus du groupe de travail en accord avec les politiques définies dans la [RFC3036].


11. Considérations pour la sécurité


Le présent document n’introduit aucun nouveau problème de sécurité au delà de ceux inhérents à Diff-Serv, MPLS et RSVP, et peut utiliser les mêmes mécanismes que proposés pour ces technologies.


12. Remerciements


Le présent document a bénéficié des discussions avec Eric Rosen, Angela Chiu et Carol Iturralde. Il a aussi emprunté aux travaux effectués par D. Black concernant les interactions entre Diff-Serv et les tunnels IP.


Appendice A Exemples de scénarios de déploiement


La présente section ne formule pas de spécification supplémentaire et ne figure ici que pour donner des exemples de la façon dont peut être déployée cette approche souple de la prise en charge de Diff-Serv sur MPLS. Les avantages et les inconvénients des diverses options de déploiement pour les environnements particulier sortent du domaine d’application du présent document.


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

Un fournisseur de service qui fait fonctionner 8 BA (ou moins) sur MPLS, qui n’effectue pas d’ingénierie du trafic, qui n’utilise pas la protection MPLS et qui utilise l’encapsulation d’en-tête Shim MPLS dans son réseau peut choisir de faire fonctionner Diff-Serv sur MPLS en utilisant un seul E-LSP par FEC établie via LDP. De plus, le fournisseur de service peut choisir d’utiliser la transposition 'EXP<-->PHB' préconfigurée.


Le fonctionnement peut être résumé comme suit :

- le fournisseur de service configure à chaque LSR la transposition bidirectionnelle entre chaque PHB et une valeur du champ EXP (par exemple, 000<-->AF11, 001<-->AF12, 010<-->AF13) ;

- le fournisseur de service configure à chaque LSR, et pour chaque interface, le comportement de programmation pour chaque PSC (par exemple, bande passante allouée à AF1) et le comportement d’abandon pour chaque PHB (par exemple, le profil d’abandon pour AF11, AF12, AF13) ;

- les LSR signalent l’établissement d’un seul E-LSP par FEC en utilisant LDP en accord avec la spécification ci-dessus (c’est-à-dire, pas de TLV Diff-Serv dans les messages LDP Demande d’étiquette/Transposition d’étiquette pour indiquer implicitement que le LSP est un E-LSP et qu’il utilise la transposition préconfigurée).


A.2 Scénario 2 : Plus de 8 BA, pas d’ingénierie du trafic, pas de protection MPLS

Un fournisseur de service qui fait fonctionner plus de 8 BA sur MPLS, qui n’effectue pas d’ingénierie du trafic, qui n’utilise pas la protection MPLS et utilise l’encapsulation Shim MPLS dans son réseau peut choisir de faire fonctionner Diff-Serv sur MPLS en utilisant pour chaque FEC :

- un E-LSP établi via LDP et utilisant la transposition préconfigurée pour prendre en charge un ensemble de 8 BA (ou moins), ET

- un L-LSP par <FEC,OA> établi via LDP pour la prise en charge des autres BA.


Le fonctionnement peut être résumé comme suit :

- le fournisseur de service configure à chaque LSR la transposition bidirectionnelle entre chaque PHB et une valeur du champ EXP pour les BA transportés sur le E-LSP ;

- le fournisseur de service configure à chaque LSR, et pour chaque interface, le comportement de programmation pour chaque PSC acceptée sur le E-LSP et le comportement d’abandon pour chaque PHB correspondant ;

- le fournisseur de service configure à chaque LSR, et pour chaque interface, le comportement de programmation pour chaque PSC acceptée sur les L-LSP et le comportement d’abandon pour chaque PHB correspondant ;

- les LSR signalent l’établissement d’un seul E-LSP par FEC pour l’ensemble de BA transportés sur le E-LSP en utilisant LDP comme spécifié ci-dessus (c’est-à-dire, pas de TLV Diff-Serv dans les messages LDP Demande d’étiquette/Transposition d’étiquette pour indiquer implicitement que le LSP est un E-LSP et qu’il utilise la transposition préconfigurée ) ;

- les LSR signalent l’établissement de un L-LSP par <FEC,OA> pour les autres BA en utilisant LDP comme spécifié ci-dessus (c’est-à-dire, TLV Diff-Serv dans les messages LDP Demande d’étiquette/Transposition d’étiquette pour indiquer la PSC du L-LSP).


A.3 Scénario 3 : 8 BA (ou moins), ingénierie du trafic agrégée , protection MPLS agrégée

Un fournisseur de service qui fait fonctionner 8 BA (ou moins) sur MPLS, qui effectue de l’ingénierie de trafic agrégé (c’est-à-dire, qui effectue une seule sélection de chemin commune pour tous les BA) qui utilise la protection MPLS agrégée (c’est-à-dire, qui restaure le service conjointement à toutes les PSC) et qui utilise l’encapsulation d’en-tête Shim MPLS dans son réseau, peut choisir de faire fonctionner Diff-Serv sur MPLS en utilisant un seul E-LSP par FEC établie via RSVP [RFC3209] ou un CR-LDP [RFC3212] et en utilisant la transposition préconfigurée.


Les opérations peuvent être résumées de la façon suivante :

- le fournisseur de service configure à chaque LSR la transposition bidirectionnelle entre chaque PHB et une valeur du champ EXP (par exemple, 000<-->AF11, 001<-->AF12, 010<-->AF13) ;

- le fournisseur de service configure à chaque LSR, et pour chaque interface, le comportement de programmation pour chaque PSC (par exemple, la bande passante allouée à l’AF1) et le comportement d’abandon pour chaque PHB (par exemple, le profil d’abandon pour AF11, AF12, AF13) ;

- les LSR signalent l’établissement d’un seul E-LSP par FEC qui va utiliser la transposition préconfigurée :

* en utilisant le protocole RSVP comme spécifié ci-dessus (c’est-à-dire, pas d’objet DIFFSERV RSVP dans le message Path qui contient l’objet Demande_d’étiquette), OU

* en utilisant le protocole CR-LDP comme spécifié ci-dessus (c’est-à-dire, pas de TLV Diff-Serv dans les messages LDP Demande d’étiquette/Transposition d’étiquette).

- la protection est activée sur tous les E-LSP afin de réaliser la protection MPLS via des mécanismes qui sortent du domaine d’application du présent document.


A.4 Scénario 4 : Ingénierie du trafic/Protection MPLS par OA

Un fournisseur de service qui fait fonctionner un nombre quelconque de BA sur MPLS, qui effectue l’ingénierie du trafic par OA (c’est-à-dire qui effectue un choix de chemin distinct pour chaque OA) et effectue la protection MPLS par OA (c’est-à-dire qui effectue la protection avec éventuellement des niveaux de protection différents pour les différents OA) dans son réseau, peut choisir de faire fonctionner Diff-Serv sur MPLS en utilisant un L-LSP par paire <FEC,OA> établie via RSVP ou CR-LDP.


Les opérations peuvent être résumées de la façon suivante :

- le fournisseur de service configure à chaque LSR, et pour chaque interface, le comportement de programmation pour chaque PSC (par exemple, la bande passante allouée à l’AF1) et le comportement d’abandon pour chaque PHB (par exemple, le profil d’abandon pour AF11, AF12, AF13) ;

- les LSR signalent l’établissement d’un L-LSP par <FEC,OA> :

* en utilisant le RSVP comme spécifié ci-dessus pour signaler la PSC du L-LSP (c’est-à-dire, l’objet DIFFSERV RSVP dans le message Path contenant la Demande d’étiquette) OU

* en utilisant le protocole CR-LDP comme spécifié ci-dessus pour signaler la PSC du L-LSP (c’est-à-dire, le TLV Diff-Serv dans les messages LDP Demande d’étiquette/Transposition d’étiquette).

- le niveau de protection approprié est activé sur les différents L-LSP (éventuellement avec un niveau de protection différent pour chaque PSC) via des mécanismes qui sortent du domaine d’application du présent document.


A.5 Scénario 5 : 8 BA (ou moins), ingénierie du trafic/protection MPLS par OA

Un fournisseur de service qui fait fonctionner 8 BA (ou moins) sur MPLS, en effectuant l’ingénierie du trafic par OA (c’est-à-dire, en effectuant un choix de chemin distinct pour chaque OA) et en effectuant la protection MPLS par OA (c’est-à-dire, en effectuant une protection avec des niveaux de protection éventuellement différents pour les différents OA) dans son réseau, peut choisir de faire fonctionner Diff-Serv sur MPLS en utilisant un E-LSP par paire <FEC,OA> établie via RSVP ou CR-LDP. De plus, le fournisseur de service peut choisir d’utiliser la transposition préconfigurée sur tous les E-LSP.


Les opérations peuvent être résumées de la façon suivante :

- le fournisseur de service configure à chaque LSR la transposition bidirectionnelle entre chaque PHB et une valeur du champ EXP (par exemple, 000<-->AF11, 001<-->AF12, 010<-->AF13) ;

- le fournisseur de service configure à chaque LSR, et pour chaque interface, le comportement de programmation pour chaque PSC (par exemple, la bande passante allouée à l’AF1) et le comportement d’abandon pour chaque PHB (par exemple, le profil d’abandon pour AF11, AF12, AF13) ;

- les LSR signalent l’établissement d’un E-LSP par <FEC,OA> :

* en utilisant le protocole RSVP comme spécifié ci-dessus pour signaler que le LSP est un E-LSP qui utilise la transposition préconfigurée (c’est-à-dire, pas d’objet DIFFSERV RSVP dans le message Path contenant la Demande d’étiquette), OU

* en utilisant le protocole CR-LDP comme spécifié ci-dessus pour signaler que le LSP est un E-LSP qui utilise la transposition préconfigurée (c’est-à-dire, pas de TLV Diff-Serv dans les messages LDP Demande d’étiquette/Transposition d’étiquette) ;

- le fournisseur de service configure, pour chaque E-LSP, à l’extrémité de tête de cet E-LSP, un critère de filtrage/transmission de telle sorte que seuls les paquets appartenant à un certain OA soient transmis sur le E-LSP établi pour la FEC correspondante et l’OA correspondant ;

- le niveau de protection approprié est activé sur les différents E-LSP (éventuellement avec un niveau de protection différent selon la PSC réellement transportée sur chaque E-LSP) via des mécanismes qui sortent du domaine d’application du présent document.


A.6 Scénario 6 : pas d’ingénierie du trafic/protection MPLS sur 8 BA, ingénierie du trafic/protection MPLS sur les autres BA

Un fournisseur de service qui n’effectue pas d’ingénierie du trafic/protection MPLS sur 8 BA (ou moins), qui effectue l’ingénierie du trafic/protection MPLS par OA sur les autres BA (c’est-à-dire, qui effectue un choix de chemin distinct pour chaque OA correspondant aux autres BA et qui effectue la protection MPLS avec une politique éventuellement différente pour chacun de ces OA) et qui utilise l’encapsulation Shim MPLS dans son réseau peut choisir de faire fonctionner Diff-Serv sur MPLS, en utilisant pour chaque FEC :

- un E-LSP en utilisant la transposition préconfigurée établie via LDP pour prendre en charge l’ensemble des 8 BA (ou moins) sans ingénierie du trafic/sans protection, ET

- un L-LSP par paire <FEC,OA> établie via RSVP ou CR-LDP pour la prise en charge des autres BA.


Les opérations peuvent être résumées de la façon suivante :

- le fournisseur de service configure à chaque LSR la transposition bidirectionnelle entre chaque PHB et une valeur du champ EXP pour les BA pris en charge sur le E-LSP ;

- le fournisseur de service configure à chaque LSR, et pour chaque interface, le comportement de programmation pour chaque PSC acceptée sur le E-LSP et le comportement d’abandon pour chaque PHB correspondant ;

- le fournisseur de service configure à chaque LSR, et pour chaque interface, le comportement de programmation pour chaque PSC acceptée sur les L-LSP et le comportement d’abandon pour chaque PHB correspondant ;

- les LSR signalent l’établissement d’un seul E-LSP par FEC pour les BA sans ingénierie du trafic en utilisant LDP comme spécifié ci-dessus (c’est-à-dire, pas de TLV Diff-Serv dans les messages LDP Demande d’étiquette/Transposition d’étiquette) ;

- les LSR signalent l’établissement d’un L-LSP par <FEC,OA> pour les autres BA :

* en utilisant le protocole RSVP comme spécifié ci-dessus pour signaler la PSC du L-LSP (c’est-à-dire, l’objet DIFFSERV RSVP dans le message Path contenant l’objet Demande_d’étiquette), OU

* en utilisant le protocole CR-LDP comme spécifié ci dessus pour signaler la PSC du L-LSP (c’est-à-dire, le TLV Diff-Serv dans les messages LDP Demande d’étiquette/Transposition d’étiquette) ;

- la protection n’est pas activée sur les E-LSP ;

- le niveau de protection approprié est activé sur les différents L-LSP (éventuellement avec un niveau de protection différent selon la PSC du L-LSP) via des mécanismes qui sortent du domaine d’application du présent document.


A.7 Scénario 7 : plus de 8 BA, pas d’ingénierie du trafic, pas de protection MPLS

Un fournisseur de service qui fait fonctionner plus de 8 BA sur MPLS, qui n’effectue pas d’ingénierie du trafic, qui n’effectue pas la protection MPLS et qui utilise l’encapsulation d’en-tête Shim MPLS dans son réseau peut choisir de faire fonctionner Diff-Serv sur MPLS en utilisant deux E-LSP par FEC établie via LDP et en utilisant la transposition 'EXP<-->PHB' signalée.


Les opérations peuvent être résumées de la façon suivante :

- le fournisseur de service configure à chaque LSR, et pour chaque interface, le comportement de programmation pour chaque PSC (par exemple, la bande passante allouée à l’AF1) et le comportement d’abandon pour chaque PHB (par exemple, le profil d’abandon pour AF11, AF12, AF13) ;

- les LSR signalent l’établissement de deux E-LSP par FEC en utilisant LDP en accord avec la spécification ci-dessus (c’est-à-dire, le TLV Diff-Serv dans les messages Demande d’étiquette/Transposition d’étiquette pour indiquer explicitement que le LSP est un E-LSP et sa transposition 'EXP<-->PHB'). La transposition signalée va indiquer le sous-ensemble de 8 BA (ou moins) à transporter sur chaque E-LSP et quelles valeurs de EXP sont transposées sur chaque BA sur chaque E-LSP.


Appendice B Exemples de scénarios de réservation de bande passante

B.1 Scénario 1 : Pas de réservation de bande passante

Considérons le cas où un administrateur de réseau choisit :

- d’avoir des ressources Diff-Serv entièrement provisionnées hors ligne (par exemple, via une interface de ligne de commande, via SNMP, via COPS,...) ;

- d’avoir l’acheminement par le plus court chemin pour tout le trafic Diff-Serv.


C’est le modèle le plus proche de Diff-Serv approvisionné sur IP non MPLS. Dans ce cas, les E-LSP et/ou les L-LSP seront établis sans signalisation de bande passante.


B.2 Scénario 2 :Réservation de bande passante pour contrôle d’admission par PSC

Considérons le cas où un administrateur de réseau choisit :

- d’avoir les ressources Diff-Serv entièrement provisionnées hors ligne (par exemple, via une interface de ligne de commande, via SNMP, via COPS,...)

- d’utiliser des L-LSP ;

- d’avoir l’acheminement fondé sur la contrainte effectué séparément pour chaque PSC, où une des contraintes est la disponibilité de la bande passante à partir de celle allouée à la PSC pertinente.


Dans ce cas, les L-LSP vont être établis avec la bande passante signalée. La bande passante signalée à l’établissement du L-LSP sera utilisée par les LSR pour effectuer le contrôle d’admission à chaque bond pour s’assurer que la contrainte de disponibilité de la bande passante est satisfaite pour la PSC en question.


B.3 Scénario 3 : Réservation de bande passante pour contrôle d’admission par PSC et ajustement de ressource par PSC

Considérons le cas où un administrateur de réseau choisit :

- d’utiliser des L-LSP ;

- d’avoir l’acheminement fondé sur la contrainte effectué séparément pour chaque PSC, où une des contraintes est la disponibilité de la bande passante à partir de celle allouée à la PSC en question ;

- d’avoir un ajustement dynamique des ressources Diff-Serv.


Dans ce cas, les L-LSP seraient établis avec la bande passante signalée. La bande passante signalée à l’établissement du L-LSP serait utilisée par les LSR pour tenter d’ajuster les ressources allouées à la PSC pertinente (par exemple, la pondération de programmation) et ensuite effectuer le contrôle d’admission pour s’assurer que la contrainte sur la disponibilité de la bande passante pour la PSC pertinente est satisfaite après l’ajustement.


Références


[ANSI/IEEE] ANSI/IEEE Std 802.1D, édition 1993, incorporant les suppléments IEEEP 802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, et P802.12e).


[ATMF_TM] ATM Forum, "Traffic Management Specification Version 4.1", mars 1999.


[IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, édition 1998 (Révision et nouvelle présentation de ISO/IEC 10038:98)


[RFC2205] R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ par RFC2750, RFC3936, RFC4495) (P.S.)


[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)


[RFC2474] K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ par RFC3168, RFC3260) (P.S.)


[RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang et W. Weiss, "Architecture pour services différenciés", décembre 1998. (MàJ par RFC3260)


[RFC2597] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Groupe PHB Transmission assurée", juin 1999. (MàJ par RFC3260) P.S.


[RFC2983] D. Black, "Services différenciés et tunnels", octobre 2000. (Information)


[RFC2996] Y. Bernet, "Format de l'objet DCLASS RSVP", novembre 2000. (P.S.)


[RFC2997] Y. Bernet, A. Smith, B. Davie, "Spécification du type de service Null", novembre 2000. (P.S.)


[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Architecture de commutation d'étiquettes multi protocoles", janvier 2001. (P.S., MàJ par RFC6178)


[RFC3032] E. Rosen et autres, "Codage de pile d'étiquettes MPLS", janvier 2001. (P.S., MàJ par les RFC 3443, 4182, 5332, 3270, 5129, 5462, 5586)


[RFC3034] A. Conta, P. Doolan, A. Malis, "Spécification de l'utilisation de la commutation d'étiquettes sur les réseaux en relais de trame", janvier 2001. (P.S.)


[RFC3035] B. Davie et autres, "Utilisation de MPLS dans la commutation de circuit virtuel LDP et ATM", janvier 2001. (P.S.)


[RFC3036] L. Andersson et autres, "Spécification de LDP", janvier 2001. (Rendue obsolète par la RFC5036)


[RFC3140] D. Black et autres, "Codes d'identification de comportement par bond", juin 2001. (P.S.)


[RFC3168] K. Ramakrishnan et autres, "Ajout de la notification explicite d'encombrement (ECN) à IP", septembre 2001. (P.S.)


[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan et G. Swallow, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (Mise à jour par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420 )


[RFC3212] B. Jamoussi et autres, "Établissement de LSP fondé sur la contrainte avec LDP", janvier 2002. (MàJ par RFC3468) (P.S.)


[RFC3246] B. Davie et autres, "Comportement par bond de transmission accélérée", mars 2002. (P.S.)


[RFC3260] D. Grossman, "Nouvelle terminologie et précisions pour Diffserv", avril 2002. (Information)


[RFC4364] E. Rosen et Y. Rekhter, "Réseaux privés virtuels IP BGP/MPLS", février 2006. (P.S., MàJ par RFC4577, RFC4684)


Adresse des auteurs


Francois Le Faucheur

Liwen Wu

Bruce Davie

Cisco Systems

Cisco Systems

Cisco Systems

Village d'Entreprise Green Side – Batiment T3

3550 Cisco Way

250 Apollo Drive,

400, Avenue de Roumanille

San Jose, CA 95134

Chelmsford, MA 01824

06410 Biot-Sophia Antipolis

USA

USA

France

téléphone : +1 (408) 853-4065

téléphone : +1 (978) 244-8000

téléphone : +33 4 97 23 26 19

mél : liwwu@cisco.com

mél : bsd@cisco.com

mél : flefauch@cisco.com




Shahram Davari

Pasi Vaananen

Ram Krishnan

PMC-Sierra Inc.

Nokia

Axiowave Networks

411 Legget Drive

3 Burlington Woods Drive, Suit 250

200 Nickerson Road

Kanata, Ontario K2K 3C9

Burlington, MA 01803

Marlboro, MA 01752

Canada

USA

USA

téléphone : +1 (613) 271-4018

téléphone +1 (781) 993-4900

mél : ram@axiowave.com

mél : davari@ieee.org

mél : pasi.vaananen@nokia.com



Pierrick Cheval

Juha Heinanen

Alcatel

Song Networks, Inc.

5 rue Noel-Pons

Hallituskatu 16

92737 Nanterre Cedex

33200 Tampere

France

Finland

mél : pierrick.cheval@space.alcatel.fr

mél : jh@song.fi


Déclaration complète de droits de reproduction


Copyright (c) The Internet Society (2002). Tous droits réservés.


Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society, ses successeurs ou ayant droits.


Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.


Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.