Groupe de travail Réseau

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document décrit un élément de politique Priorité de préemption à utiliser par les protocoles d’admission fondée sur une politique signalée (comme le protocole de réservation de ressources (RSVP) et le service commun de politique ouverte (COPS)).

La priorité de préemption définit une importance relative (un rang) au sein de l’ensemble des flux qui sont en compétition pour l’admission dans le réseau. Plutôt que d’admettre les flux par ordre d’arrivée (premier entré, premier admis) les nœuds du réseau peuvent considérer des priorités pour préempter certains flux à faible priorité admis précédemment afin de faire de la place pour un nouveau flux à forte priorité.

Le présent mémoire corrige une erreur d’allocation du codet de P-Type RSVP POLICY_DATA dans la [RFC2751].

Table des matières

1. Introduction 1

2. Portée et applicabilité 2

3. Politique sans état 2

4. Format de l’élément de politique 2

5. Questions de fusion de priorités 3

5.1 Stratégies de fusion de priorités 4

5.2 Modification des éléments de priorité 4

6. Traitement des erreurs 5

7. Considérations relatives à l’IANA 5

8. Considérations pour la sécurité 5

9. Références 5

10. Adresse de l’auteur 6

Appendice A. Exemple 6

A.1 Calcul de priorités fusionnées 6

A.2 Traduction (Compression) des éléments Priorité 6

Déclaration de droits de reproduction 7

Le présent document décrit un élément de politique Priorité de préemption à utiliser par les protocoles d’admission fondés sur une politique signalée (tels que la [RFC2205] et la [RFC2748]).

Les contrôles d’admission fondés sur la capacité (CAC, Capacity based Admission Control) traditionnels admettent sans discrimination de nouveaux flux jusqu’à épuisement de la capacité (premier arrivé, premier admis). Le contrôle d’admission fondé sur la politique (PAC, Policy based Admission Control) tente de son côté de minimiser la signification de l’ordre d’arrivée et utilise plutôt le critère d’admission fondée sur la politique.

Un des critères de politique les plus populaires est le rang d’importance d’un flux par rapport aux autres qui sont en compétition pour l’admission dans un nœud de réseau. La priorité de préemption ne prend effet que lorsque un ensemble de flux tentant l’admission à travers un nœud représente une surcapacité de ressources telle que sur la base de CAC certaines devraient être rejetées. Les critères de priorité de préemption aident le nœud à choisir les flux les plus importants (qui ont la plus forte priorité) pour l’admission, alors que ceux de faible priorité seront rejetés.

Les nœuds de réseau qui prennent en charge la préemption devraient tenir compte des priorités pour préempter certains des flux à faible priorité précédemment admis afin de faire de la place pour un flux à forte priorité plus récent.

Le présent document décrit le format et l’applicabilité de la priorité de préemption représentée comme un élément de politique dans la [RFC2750].

Le document cadre pour le contrôle d’admission fondé sur la politique [RFC2753] décrit les divers composants qui participent à la prise de décision de politique (c’est-à-dire, PDP, PEP et LDP). La mission des éléments PREEMPTION_PRI est d’être simples, sans état, et légers de sorte qu’ils puissent être mis en œuvre en interne au sein du point de décision local (LDP, Local Decision Point) d’un nœud.

Certaines hypothèses de base sont faites dans le modèle d’usage des éléments PREEMPTION_PRI :

Dans un modèle où les PDP contrôlent les PEP à la périphérie du domaine de politique (par exemple, dans les routeurs frontière) les PDP réduisent les ensembles de règles de politique pertinentes en un seul critère de priorité. Cette priorité telle qu’exprimée dans l’élément PREEMPTION_PRI peut alors être communiquée vers l’aval aux PEP du même domaine de politique, qui ont des LDPqui les contrôlent mais pas de PDP .

Les éléments PREEMPTION_PRI sont traités par les LDP de nœuds qui n’ont pas un PDP qui les contrôle. Les LDP peuvent interpréter ces objets, les transmettre tels qu’ils sont, ou effectuer une fusion locale pour transmettre un élément de politique PREEMPTION_PRI fusionné équivalent. Les LDP doivent suivre la stratégie de fusion qui a été codée par les PDP dans les objets PREEMPTION_PRI. (En clair, un PDP, étant un surensemble de LDP, peut agir aussi bien comme un LDP).

Les éléments PREEMPTION_PRI interagissent avec le module de contrôle de trafic d’un nœud (et de contrôle d’admission de capacité) pour mettre en application les priorités, et préempter les flux admis antérieurement lorsque le besoin s’en fait sentir.

La priorité de préemption signalée est sans état (elle n’exige pas de tenir d’historique ni d’interprêter des informations externes). Donc, lorsque ils sont portés dans des messages COPS pour l’externalisation des décisions de politique, ces objets sont inclus comme objets COPS de décision de données de politique sans état (voir les [RFC2748], [RFC2749]).

Le format des objets Données de politique est défini dans la [RFC2750]. Un seul objet Données de politique peut contenir un ou plusieurs éléments de politique, chacun représentant une politique différente (et peut-être diamétralement opposée).

Le format de l’élément de politique de priorité de préemption est le suivant :

Toujours 12. C’est la longueur globale de l’élément de politique, en octets.

C’est la priorité du nouveau flux comparée à la priorité de défense des flux admis précédemment. Les valeurs les plus fortes représentent une priorité supérieure.

Une fois qu’un flux a été admis, la priorité de préemption devient non pertinente. À la place, sa priorité de défense est utilisée pour la comparer à la priorité de préemption des nouveaux flux.

Pour un flux spécifique, sa priorité de préemption doit toujours être inférieure ou égale à la priorité de défense. Un gros écart entre priorité de préemption et priorité de défense donne une stabilité accrue : une priorité de préemption modérée rend plus difficile à un flux d’en préempter d’autres, mais une fois qu’il a réussi, la plus forte priorité de défense rend plus facile au flux d’éviter lui-même la préemption. Cela donne un mécanisme d’équilibrage entre la dépendance à l’ordre et la priorité.

La réservation fusionnée F3 devrait avoir QS = Haute, mais quelle priorité devrait être supposée ? Plusieurs effets colatéraux négatifs qui peuvent affecter une telle fusion ont été identifiés :

Si F3 assume une Priorité = Haute, alors F1 obtient un tour gratuit, en supposant que la priorité haute était seulement destinée à la faible QS de F2. Si on associe les coûts comme fonction de la QS et de la priorité, F1 reçoit une priorité "coûteuse" sans avoir à "payer" pour elle.

Si F3 assume une Priorité = Faible, le flux fusionné pourrait être préempté ou échouer bien que F2 ait présenté une haute priorité.

Le déni de service est virtuellement le problème inverse du tour gratuit. Lorsque les flux sont en compétition pour les ressources, si un flux reçoit une haute priorité imméritée, il peut être capable de préempter un autre flux méritant (donc, un tour gratuit est le déni de service d’un autre).

La combinaison de la priorité de préemption, de la réservation tueuse et de l’état de blocage [RFC2205] peut augmenter l’instabilité des flux admis où une réservation peut être préemptée, réinstalée, et préemptée à nouveau périodiquement.

Dans les situations de fusion, les LDP peuvent recevoir plusieurs éléments de préemption et doivent calculer la priorité du flux fusionné conformément aux règles suivantes :

a. La priorité de préemption et la priorité de défense sont fusionnées et calculées séparément, sans considération l’une de l’autre.

Tous les éléments de priorité sont examinés selon leur stratégie de fusion pour décider si ils devraient participer au résultat fusionné (comme spécifié ci-dessous).

c. La plus haute priorité de tous les éléments de priorité participants est calculée.

Le reste de cette section décrit les différentes stratégies de fusion qui peuvent être spécifiées dans l’élément PREEMPTION_PRI.

L’élément PREEMPTION_PRI ne va participer à la réservation fusionnée que si il appartient à un flux qui contribue au niveau de QS fusionnée (c’est-à-dire que ses exigences de QS ne constituent pas un sous-ensemble d’une autre réservation). Une façon simple pour déterminer si un flux a contribué à la QS fusionnée résultante est de calculer la QS fusionnée avec et sans lui et de comparer les résultats (bien que ce ne soit clairement pas la méthode la plus efficace).

Le raisonnement de cette approche est que le flux avec la plus forte QS est celui qui domine la réservation fusionnée et à ce titre, sa priorité devrait la dominer aussi. Cette approche est la plus favorable à la prévention de distortions de priorités telles que les tours gratuites et le déni de service.

Tous les éléments PREEMPTION_PRI participent à la réservation fusionnée. Cette stratégie dissocie le niveau de priorité et celui de la QS, et est donc très encline aux tours gratuits et à leur image inverse, le déni de service.

Ce n’est pas une méthode recommandée, mais elle peut être plus simple à mettre en œuvre.

Un élément PREEMPTION_PRI ne peut participer à une réservation fusionnée que si tous les autres flux de la réservation fusionnée ont le même niveau de QS (flux homogènes).

Le raisonnement de cette approche suppose que le cas hétérogène est relativement rare et trop compliqué pour le traiter, et donc, il est préférable de l’interdire.

Cette stratégie conduit à se faire à soi-même un déni de service : lorsque un seul receveur spécifie un niveau de QS non compatible cela peut causer un déni de service pour tous les autres receveurs de la réservation fusionnée.

Note : La détermination de flux hétérogènes s’applique seulement au niveau de QS (valeurs de FLOWSPEC) et est une question de définition locale (LDP). D’autres types de réservations hétérogènes (par exemple, styles de réservation incompatibles) sont traités par RSVP et sont sans relation avec cet élément PREEMPTION_PRI.

C’est une stratégie de fusion recommandée lorsque l’homogénéité de réservation est coordonnée et mise en application pour la totalité de l’arborescence de diffusion groupée. Elle est plus restrictive que le paragraphe 5.1.1, mais est plus facile à mettre en œuvre.

Lorsque les objets POLICY_DATA sont protégés en intégrité, les LDP ne devraient pas tenter de les modifier. Ils doivent être transmis tels quels, autrement, leur enveloppe de sécurité en serait invalidée. Dans d’autres cas, les LDP peuvent modifier et fusionner les éléments PREEMPTION_PRI entrants pour réduire leur taille et leur nombre, conformément à la règle suivante :

Il n’y a pas d’algorithme connu pour fusionner les éléments PREEMPTION_PRI de stratégies de fusion différentes sans perdre des informations précieuses qui peuvent affecter les AUTRES nœuds.

- Pour chaque stratégie de fusion, la plus haute QS de tous les éléments PREEMPTION_PRI participants est prise et est placée dans un élément PREEMPTION_PRI sortant de cette stratégie de fusion.

- Cette approche compresse effectivement le nombre d’éléments PREEMPTION_PRI transmis en au plus le nombre de stratégies de fusion différentes, sans considération du nombre de receveurs (voir l’exemple de l’Appendice A.2).

Un objet d’erreur PREEMPTION_PRI est renvoyé aux receveurs appropriés lorsque survient une erreur impliquant des éléments PREEMPTION_PRI.

Lorsque un flux précédemment admis est préempté, une copie de l’élément PREEMPTION_PRI du flux préempteur est renvoyée au PDP qui a généré l’objet PREEMPTION_PRI préempté. Ce PDP, ayant des informations sur les deux priorités préemptrice et préemptée peut construire un élément PREEMPTION_PRI de priorité supérieure dans un effort de réinstancier le flux préempté.

Lorsque un flux F1 avec une stratégie de fusion Erreur hétérogène établie dans son élément PREEMPTION_PRI rencontre une hétérogénéité, l’élément PREEMPTION_PRI est renvoyé aux receveurs avec le code Erreur hétérogénéité établi.

Suivant les politiques décrites dans la [RFC2434], les éléments de politique RSVP standard (valeurs de P-type) sont alloués par action de consensus de l’IETF comme décrit dans la [RFC2750].

L’intégrité de PREEMPTION_PRI est garantie, comme celle de tout autre élément de politique, par l’encapsulation dans un objet Données de politique [RFC2750].

Les autres mécanismes de sécurité ne sont pas garantis, en particulier en ce qui concerne les buts de la priorité de préemption pour fournir des directives simples et rapides aux routeurs au sein d’une zone de confiance ou au moins d’une seule zone (aucune frontière de zone n’étant franchie).

[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 RFC 5226)

[RFC2748] D. Durham et autres, "Protocole COPS (Service commun de politique ouverte)", janvier 2000. (MàJ par RFC4261) (P.S.)

[RFC2751] S. Herzog, "Élément de politique de priorité par préemption signalée", janvier 2000. (Obsolète, voir RFC3181) (P.S.)

Les exemples suivants décrivent le calcul des éléments de priorité fusionnée ainsi que la traduction (compression) des éléments PREEMPTION_PRI.

L’exemple 1 dérit un scénario de diffusion groupée avec un envoyeur et quatre receveurs, chacun avec sa propre définition d’élément PREEMPTION_PRI.

Raison : La PREEMPTION_PRI de r3 ne participe pas (car r3 ne contribue pas à la QS fusionnée) et la priorité est la plus haute des PREEMPTION_PRI entre r1 et r2.

r1, r2, r3 et r4 fusionnent en A. La priorité résultante est encore 4 : r4 ne participe pas parce que sa propre QS = Faible est incompatible avec celle des autres (r1) Q S = Haute. Une erreur de PREEMPTION_PRI devrait être renvoyée à r4 lui disant que son élément PREEMPTION_PRI a rencontré une hétérogénéité.

Étant donné cet ensemble d’éléments PREEMPTION_PRI participants, la compression suivante peut avoir lieu au nœud de fusion :

Ce document et ses traductions peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l’Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

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

Groupe de travail Réseau	S. Herzog, PolicyConsulting.Com
Request for Comments : 3181	octobre 2001
RFC rendue obsolète : 2751
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle