Spécification du type de service Null

Statut du présent mémoire

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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la 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 (2000). Tous droits réservés.

Résumé

Dans le modèle normal du protocole de réservation de ressource (RSVP, Resource Reservation Protocol)/Intserv, les applications demandent un type spécifique de service Intserv et quantifient les ressources exigées pour ce service. Pour certaines applications, la détermination des paramètres de service est plutôt laissée à la discrétion de l'administrateur du réseau. Par exemple, les applications ERP sont souvent critiques et exigent une certaine forme de priorité de service, mais ne peuvent pas directement spécifier leurs exigences de ressources. Pour servir de telles applications, on introduit la notion de "service Null". Le service Null permet aux applications de s'identifier auprès des agents de politique de qualité de service (QS) du réseau, en utilisant la signalisation RSVP. Cependant, il n'exige pas d'elles qu'elles spécifient des exigences de ressource. Les agents de politique de QS dans le réseau répondent en appliquant les politiques de QS appropriées pour l'application (comme déterminé par l'administrateur du réseau). Ce mode d'utilisation de RSVP est particulièrement applicable aux réseaux qui combinent les mécanismes de QS de services différenciés (diffserv) avec la signalisation RSVP [RFC2998]. Dans cet environnement, les agents de politique de QS peuvent diriger le trafic des applications signalées sur une classe de service diffserv particulière.

1. Motivation

En utilisant la signalisation RSVP/Intserv standard, les applications qui fonctionnent sur des hôtes envoient des demandes de ressources du réseau en communiquant les informations suivantes aux appareils du réseau :

1. Un certain niveau de service (garanti ou charge contrôlée).

2. La quantité de ressources requises à ce niveau de service.

3. Les informations de classement par lesquelles le réseau peut reconnaître le trafic spécifique (filterspec).

4. Les informations de politique/identité qui indiquent l'usager et/ou l'application pour qui des ressources sont demandées

En réponse, les nœuds de réseau standard à capacité RSVP choisissent d'admettre ou refuser une demande de ressource. La décision se fonde sur la disponibilité des ressources le long du chemin pertinent et sur les politiques. Les politiques définissent les ressources qui peuvent être accordées aux usagers et/ou applications spécifiques. Lorsque une demande de ressource est admise, les nœuds du réseau installent des classeurs qui sont utilisés pour reconnaître le trafic admis et des régulateurs qui sont utilisés pour s'assurer que le trafic reste dans les limites des ressources demandées.

Les services garanti et à charge contrôlée de Intserv ne conviennent pas pour certaines applications qui ne sont pas capables (ou choisissent de ne pas l'être) de spécifier les ressources qu'elles exigent du réseau. Les services Diffserv conviennent mieux à ce type d'application. Les nœuds d'un réseau Diffserv sont normalement provisionnés pour classer les paquets arrivants en un petit nombre d'agrégats de comportement (BA, Behaviour Aggregates) [RFC2475]. Le trafic est traité selon l'agrégat de comportement. Ce provisionnement tend à être "de haut en bas" par rapport aux flux de trafic de l'utilisateur final dans le sens qu'il n'y a pas de signalisation entre les hôtes et le réseau. L'administrateur de réseau utilise plutôt une combinaison d'heuristiques, de mesures et d'expérience pour provisionner les appareils du réseau pour traiter le trafic agrégé, sans connaissance déterministe du volume de trafic qui va arriver sur un nœud spécifique.

Les administrateurs de réseau font face à deux défis lors de l'application des mécanismes Diffserv pour gérer le trafic des applications :

1. Provisionnement – les administrateurs de réseau doivent anticiper le volume de trafic qui va vraisemblablement arriver à chaque nœud de réseau pour chaque BA Diffserv. Si le volume de trafic arrivant va vraisemblablement excéder la capacité disponible revendiquée pour le BA, l'administrateur de réseau a le choix d'augmenter la capacité pour le BA, de réduire le volume de trafic se réclamant du BA, ou de compromettre le service pour tout le trafic arrivant pour le BA.

2. Classement – les nœuds Diffserv classent le trafic pour l'usager et/ou l'application, sur la base du codet diff-serv(DSCP, Diff-serv Code Point) dans chaque en-tête IP de paquet ou sur la base d'autres champs dans l'en-tête IP du paquet (adresse de source/destination, adresse/accès et protocole). Cette dernière méthode de classement est appelée le classement MF. Cette méthode de classement peut n'être pas fiable et impose une charge pour la gestion.

En utilisant la signalisation RSVP, la gestion du trafic d'application dans les réseaux Diffserv peut être significativement facilitée. (Noter que l'interopérabilité RSVP/Diffserv a été précédemment discutée dans le contexte des services Intserv garanti et à charge contrôlée.) Le présent document se concentre sur l'interopérabilité RSVP/Diffserv dans le contexte du service Null.

2. Vue d'ensemble du fonctionnement

Dans le mécanisme proposé, l'envoyeur RSVP offre le nouveau type de service, "Type de service Null" dans la Adspec qui est incluse avec le message PATH. Une nouvelle Tspec correspondant au nouveau type de service est ajoutée à la SENDER_TSPEC. De plus, l'envoyeur RSVP va normalement inclure dans le message PATH les objets de politique qui identifient l'usager, l'identifiant d'application et de sous application [RFC2752], [RFC2872].

(Noter que cette fois, la nouvelle Tspec n'est définie que pour porter le paramètre Taille maximum de paquet (M), afin d'éviter la fragmentation. Aucun autre paramètre n'est défini.)

Les nœuds de réseau qui reçoivent ces messages PATH interprètent le type de service comme indiquant que l'application ne demande pas de type de service spécifique ou de ressources quantifiables. Les nœuds de réseau gèrent plutôt le flux de trafic sur la base de l'usager demandeur, de l'application demandeuse et du type de sous flux d'application.

Ce mécanisme offre des avantages significatifs sur un pur réseau Diffserv. Au minimum, il informe chaque nœud du réseau qui pourrait être affecté par le flux de trafic (et qui est intéressé à en intercepter la signalisation) de :

1. la demande de ressources en termes de nombre de flux d'un type particulier qui traversent le nœud,

2. la liaison entre informations de classement et usager, application et sous application.

Ces informations sont particulièrement utiles pour les points de mise en application de politique et les points de décision de politique (les PEP et les PDP). L'administrateur de réseau peut configurer ces éléments du système de gestion de politique pour applique la politique appropriée sur la base de l'identité de l'usager, de l'identifiant de l'application et de la sous application spécifique.

Les PEP et les PDP peuvent être configurés pour retourner un message RSVP RESV à l'envoyeur. Le message RESV retourné peut inclure un objet DCLASS [RFC2996]. L'objet DCLASS invite l'envoyeur à marquer les paquets sur le flux correspondant avec un DSCP spécifique (ou ensemble de DSCP). Ce mécanisme permet aux PEP/PDP d'affecter le volume de trafic arrivant à un nœud pour chaque BA. Il permet au PEP/PDP de faire cela sur la base de politiques sophistiquées.

3.1 Notes pour le fonctionnement

3.1.1 Questions d'adaptabilité

Dans tout réseau dans lequel est utilisée la signalisation par flux, il est raisonnable de prendre en compte les questions d'adaptabilité. Le service Null encourage à la signalisation pour un ensemble d'applications plus large que celui qui serait autrement pris en compte par la signalisation. Cependant, la signalisation RSVP ne génère en général pas de quantité de trafic significative par rapport au trafic de données réel associé à la session. De plus, le service Null n'encourage pas toutes les applications à signaler. Il devrait être utilisé par des applications dont la mission est considérée comme critique ou qui ont besoin d'une gestion de la qualité de service par les administrateurs de réseau.

Peut-être plus intéressant est l'impact sur le traitement des ressources aux nœuds de réseau qui traitent les messages de signalisation. Quand on examine ce problème, il est important de souligner qu'il n'est pas nécessaire de traiter les messages de signalisation à chaque nœud du réseau. En fait, la combinaison de la signalisation RSVP avec les réseaux Diffserv peut rapporter des bénéfices substantiels même lorsque les messages RSVP ne sont traités qu'à certains nœuds clés (comme aux frontières entre les domaines de réseau, aux routeurs de premier bond, aux PEP ou à tout sous-ensemble de cela). Les nœuds individuels devraient être activés ou désactivés pour le traitement RSVP à la discrétion de l'administrateur de réseau. Voir dans la [RFC2998] une discussion de l'impact de la signalisation RSVP sur les réseaux Diffserv.

En tous cas, l'état par flux n'est pas nécessairement requis, même dans les nœuds qui appliquent le traitement par flux.

2.1.2 Mise en application de politique dans les réseaux traditionnels

Les nœuds de réseau qui adhèrent à la spécification RSVP devraient passer de façon transparente les messages de signalisation pour le service Null. À ce titre, il est possible d'introduire un petit nombre de PEP qui sont activés pour le service Null dans un réseau traditionnel et de bénéficier des avantages décrits dans le présent document.

2.1.3 Combinaison des services Intserv existants avec le service Null

Le présent document n'empêche pas les applications d'offrir à la fois un service Intserv quantitatif (garanti ou à charge contrôlée) et le service Null, en même temps. Un exemple d'une telle application serait une application de téléphonie qui bénéficierait du service garanti mais serait capable de s'adapter à un service moins strict. En annonçant sa prise en charge des deux services, l'application rend la politique de réseau capable de décider quel type de service fournir.

3. Détails de signalisation

3.1 Génération des ADSPEC

L'envoyeur RSVP construit un objet initial RSVP Adspec qui spécifie le type de service Null. Comme il n'y a pas de paramètre spécifique du service associé à ce type de service, le fragment d'Adspec associé est vide et contient seulement le mot d'en-tête. Les nœuds de réseau peuvent fournir ou non des valeurs valides pour les paramètres généraux de bande passante et de latence. À ce titre, ils peuvent utiliser les valeurs inconnues définie dans la [RFC2216].

L'Adspec est ajoutée au message PATH RSVP créé chez l'envoyeur.

3.2 Objet RSVP SENDER_TSPEC

Une Tspec supplémentaire est définie pour correspondre au service Null. Si seulement le service Null est offert dans l'Adspec, c'est alors la seule Tspec incluse dans l'objet SENDER_TSPEC. Si les services garanti ou à charge contrôlée sont aussi offerts dans l'Adspec, la nouvelle Tspec est alors augmentée selon la Tspec de baquet de jetons Intserv standard de la [RFC2210].

3.3 Objet RSVP FLOWSPEC

Les receveurs peuvent répondre aux messages PATH en générant un message RSVP RESV qui comporte un objet FLOWSPEC. L'objet FLOWSPEC devrait spécifier qu'il demande le service Null. Il est possible que, à l'avenir, une Rspec spécifique puisse être définie pour correspondre au nouveau type de service.

4. Formats détaillés de message

4.1 Format d'Adspec standard

Un objet RSVP ADSPEC standard est décrit dans la [RFC2210]. Il comporte un en-tête de message et un fragment de paramètres généraux par défaut. À la suite du fragment de paramètres généraux par défaut se tiennent des fragments pour chaque type de service pris en charge.

4.2 Adspec pour le type de service Null

L'Adspec pour le service Null comporte l'en-tête de message et le fragment de paramètres généraux par défaut, suivi par un seul fragment notant le service Null. Le nouveau fragment introduit pour le service Null est formaté comme suit :

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

| 6 (a) |x| Réservé | 0 (b) |

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

a – indique le service Null (6).

x – est le bit de coupure.

b – indique zéro mot en plus de l'en-tête.

Une Adspec complète ne prenant en charge que le service Null est illustrée ci-dessous :

31 24 23 16 15 8 7 0

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

1 | 0 (a) | Réservé | Longueur de message -1 (b) |

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

2 | 1 (c) |x| Réservé | 8 (d) |

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

3 | 4 (e) | (f) | 1 (g) |

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

4 | Compte de bonds IS (entier de 32 bits non signé) |

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

5 | 6 (h) | (i) | 1 (j) |

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

6 | Bande pass. estim. du chemin (nbr IEEE de 32 bits à virg flot)|

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

7 | 8 (k) | (l) | 1 (m) |

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

8 | Latence minimum de chemin (entier de 32 bits) |

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

9 | 10 (n) | (o) | 1 (p) |

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

10 | MTU composée (entier non signé de 32 bits) |

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

11 | 6 (q) |x| Réservé | 0 (r) |

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

Mot 1 : En-tête du message :

(a) – En-tête du message et numéro de version

(b) – Longueur du message (10 mots en-tête non inclus)

Mots 2 à 10 : paramètre généraux de caractérisation par défaut

(c) – En-tête par service, service numéro 1 (paramètres généraux par défaut)

(x) – Bit de coupure global (paramètre général 2 NON_IS_HOP)

(d) – Longueur du bloc de données de paramètres généraux (8 mots)

(e) – Identifiant de paramètre, paramètre 4 (paramètre général NUMBER_OF_IS_HOPS)

(f) – Octet de fanion du paramètre 4

(g) – Longueur du paramètre 4, un mot en-tête non inclus

(h) – Identifiant du paramètre 6 (paramètre général AVAILABLE_PATH_BANDWIDTH)

(i) – Octet de fanion du paramètre 6

(j) – Longueur du paramètre 6, un mot en-tête non inclus

(k) – Identifiant du paramètre 8 (paramètre général MINIMUM_PATH_LATENCY)

(l) – Octet de fanion du paramètre 8

(m) – Longueur du paramètre 8, un mot en-tête non inclus

(n) – Identifiant du paramètre 10 (paramètre général PATH_MTU)

(o) – Octet de fanion du paramètre 10

(p) – Longueur du paramètre 10, un mot en-tête non inclus

Mot 11 : Paramètres du service Null

(q) – En-tête par service, numéro de service 6 (Null)

(x) – Bit de coupure pour le service Null

(r) – Longueur (0) de données par service, mot d'en-tête non inclus.

Noter que les règles standard pour l'analyse des fragments de service d'Adspec assurent que l'Adspec ne sera pas rejetée par les éléments de réseau traditionnels. Précisément, ces règles établissent qu'un élément de réseau qui rencontre un en-tête de données par service qu'il ne comprend pas devrait établir le bit 23 (le bit de coupure) pour indiquer que le service n'est pas pris en charge et devrait utiliser le champ Longueur de l'en-tête pour sauter le reste du fragment.

Noter aussi qu'il est vraisemblable qu'il ne sera pas possible aux hôtes ou nœuds de réseau de générer des valeurs significatives pour les mots 5 et/ou 7 (estimation de bande passante et latence du chemin) du fait de la nature du service. Dans ce cas, on devrait utiliser les valeurs inconnues tirées de la [RFC2216].

4.3 Format de l'objet SENDER_TSPEC

La Tspec suivante est définie pour correspondre au service Null :

31 24 23 16 15 8 7 0

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

1 | 6 (a) |0| Réservé | 2 (b) |

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

2 | 128 (c) | 0 (d) | 1 (e) |

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

3 | Taille maximum de paquet [M] (entier de 32 bits) |

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

Mot 1 : En-tête du service

(a) – Numéro de service 6 (service Null)

(b) – Longueur des données par service, deux mots, en-tête de service non inclus

Mots 2-3 : Paramètre

(c) – Identifiant de paramètre, paramètre 128 (TSpec du service Null)

(d) – Fanions du paramètre 128 (aucun n'est établi)

(e) – Longueur du paramètre 128, un mot, en-tête de paramètre non inclus.

Noter que la figure ci-dessus ne comporte pas l'en-tête standard d'objet RSVP SENDER_TSPEC, ni l'en-tête du sous objet (qui indique le numéro et la longueur de la version du format de message) définis respectivement dans les RFC2205 et RFC2210.

Au cas où seul le service Null est annoncé dans l'Adspec, la Tspec ci-dessus sera ajoutée immédiatement après l'en-tête de l'objet SENDER_TSPEC et l'en-tête de sous-objet. Au cas ou des types de service supplémentaires seraient annoncés, ce qui exigerait la Tspec spécifique du baquet de jetons définie dans la RFC2210, la Tspec ci-dessus serait ajoutée à la suite de la Tspec du baquet de jetons, qui à son tour suivrait l'en-tête d'objet et l'en-tête de sous-objet.

4.4 Format de l'objet FLOWSPEC

Le format d'un objet RSVP FLOWSPEC généré chez un receveur qui demande le service Null est donné ci-dessous. La valeur de 6 dans l'en-tête par service (champ (c), ci-dessous) indique que le service Null est demandé.

31 24 23 16 15 8 7 0

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

1 | 0 (a) | Réservé | 3 (b) |

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

2 | 6 (c) |0| Réservé | 2 (d) |

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

3 | 128 (e) | 0 (f) | 1 (g) |

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

4 | Taille maximum de paquet [M] (entier de 32 bits) |

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

(a) – Numéro de version du format de message (0)

(b) – Longueur globale (trois mots, en-tête non inclus)

(c) – En-tête de service, numéro de service 6 (Null)

(d) – Longueur des données, deux mots, en-tête par service non inclus

(e) – Identifiant du paramètre 128 (TSpec du service Null)

(f) – Fanions du paramètre 128 (aucun n'est établi)

(g) – Longueur du paramètre 128, un mot, en-tête de paramètre non inclus.

4.5 Format de l'objet DCLASS

Les objets DCLASS peuvent être inclus dans les messages RESV. Pour les détails en ce qui concerne le format de l'objet DCLASS, voir la [RFC2996].

5. Considérations pour la sécurité

Les règles de formatage et d'usage des message décrites dans la présente note ne soulèvent aucun nouveau problème de sécurité en plus de ceux du RSVP standard.

6. Références

[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.)

[RFC2210] J. Wroclawski, "Utilisation de RSVP avec les services intégrés de l'IETF", septembre 1997. (P.S.)

[RFC2216] S. Shenker, J. Wroclawski, "Modèle de spécification de services d'élément de réseau", septembre 1997. (Information)

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

[RFC2752] S. Yadav et autres, "Représentation d'identité pour RSVP", janvier 2000. (Obsolète, voir RFC3182) (P.S.)

[RFC2872] Y. Bernet, R. Pabbati, "Élément de politique d'identité d'application et de sous application à utiliser avec RSVP", juin 2000. (P.S.)

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

[RFC2998] Y. Bernet et autres, "Cadre de fonctionnement de services intégrés sur réseaux Diffserv", novembre 2000. (Information)

7. Remerciements

Merci à Fred Baker, Dinesh Dutt, Nitsan Elfassy, John Schnizlein, Ramesh Pabbati and Sanjay Kaniyar de leurs commentaires sur le présent mémoire.

8. Adresse des auteurs

9. Déclaration complète de droits de reproduction

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

Ce document et les traductions de celui-ci 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 copyright 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, 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.

Remerciement

Le financement de la fonction d'éditeur des RFC est actuellement assuré par la Internet Society.