Groupe de travail Réseau	K. Nichols, Packet Design	
Request for Comments : 3086	B. Carpenter, IBM	
Catégorie : Information	avril 2001	
Traduction Claude Brière de L’Isle		

Définition des services différenciés par comportement de domaine 
et règles pour leur spécification

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2001). Tous droits réservés.

Résumé
Le cadre de services différenciés permet le provisionnement de qualité de service (QS) au sein d’un domaine réseau en appliquant des règles aux bordures pour créer des agrégats de trafic et pour coupler chacun d’eux avec un traitement spécifique de chemin de transmission dans le domaine par l’utilisation d’un codet dans l’en-tête IP. Le groupe de travail diffserv a défini l’architecture générale pour les services différenciés et s’est concentré sur le comportement de chemin de transmission requis des routeurs, appelé "comportement de transmission bond par bond" (ou PHB, Per Hop Behavior). Le groupe de travail a aussi discuté des fonctionnalités requises aux bordures de domaine diffserv (DS) pour choisir (classeurs) et conditionner (par exemple, réguler et formater) le trafic conformément à ces règles. Les changements à court terme des buts de QS pour un domaine DS sont mis en œuvre en ne changeant que la configuration de ces comportements de bordure sans nécessairement reconfigurer le comportement des nœuds de réseau intérieurs.

L’étape suivante est de formuler des exemples de la façon dont les composants du chemin de transmission (les PHB, les classeurs, et les conditionneurs de trafic) peuvent être utilisés pour composer les agrégats de trafic dont les paquets rencontrent des caractéristiques de transmission spécifiques lorsque ils transitent par un domaine de services différenciés. Le groupe de travail a décidé d’utiliser le terme de comportement par domaine (PDB, per-domain behavior) pour décrire le comportement subi par un ensemble particulier de paquets lorsque ils traversent un domaine DS. Un PDB se caractérise par une métrique spécifique qui quantifie le traitement que va recevoir un ensemble de paquets ayant un DSCP particulier (ou un ensemble de DSCP) lorsque il traverse un domaine DS. Un PDB spécifie un traitement de chemin de transmission pour un agrégat de trafic et, du fait du rôle que les choix particuliers de bordure et de configuration de PHB jouent dans ses attributs résultants, c’est là que le chemin de transmission et le plan de contrôle interagissent. Les paramètres mesurables d’un PDB devraient convenir pour les spécifications de niveau de service à la bordure du réseau.

Le présent document définit et discute en détails des comportements par domaine et fixe le format et le contenu requis pour les contributions au groupe de travail Diffserv sur les PDB et la procédure qui sera appliquée aux spécifications individuelles de PDB pour les faire avancer comme produits du groupe de travail. Ce format est spécifié pour traiter les révisions des propositions de PDB par le groupe de travail.

Table des matières
1. Introduction	2
2. Définitions	3
3. Valeur de la définition du comportement de bord à bord	4
4. Comprendre les PDB	5
4.1 Définir les PDB	5
4.2. Construction des PDB	7
4.3 PDB en utilisant des groupes de PHB	7
4.4 Chemin de transmission contre plan de contrôle	8
5. Format pour la spécification des comportement Diffserv par domaine	8
5.1 Déclaration d’applicabilité	8
5.2 Spécification technique	8
5.3 Attributs	9
5.4 Paramètres	9
5.5 Hypothèses	9
5.6 Exemple d’utilisation	9
5.7 Problèmes d’environnement (support, topologie, etc.)	9
5.8 Considérations de sécurité pour chaque PDB	10
6. Attributs de PDB	10
6.1 Considérations sur la spécification d’attributs de PDB à long ou moyen terme	10
6.2 Considérations sur la spécification d’attributs de PDB à court terme ou saccadés	11
6.3 Remarques	11
7. Comportement par domaine de référence	11
7.1 PDB au mieux	12
8. Lignes directrices pour la rédaction des spécifications de PDB	13
9. Considérations sur la sécurité	13
10. Remerciements	13
Références	14
Déclaration complète de droits de reproduction	14

1.	Introduction

Les services différenciés permettent une approche de la qualité de service IP qui est modulaire, déployable par incréments, et adaptable lorsque on introduit une complexité minimale par nœud [RFC2475]. Du point de vue de l’utilisateur final, la QS devrait être prise en charge de bout en bout entre toute paire d’hôtes. Cependant, ce but n’est pas directement accessible. Il va exiger la prise en charge de la QS inter domaine, et de nombreuses étapes non franchies restent à parcourir avant de la réaliser. Une étape essentielle, l’évolution des modèles d’affaires pou la QS inter domaine, va nécessairement se développer en dehors de l’IETF. Un des buts du groupe de travail Diffserv est de fournir de fermes fondations techniques qui permettent le développement de ces modèles d’affaires. La première étape majeure sera la prise en charge de la QS de bordure à bordure ou intra domaine entre l’entrée et la sortie d’un seul réseau, c’est-à-dire, un domaine DS dans la terminologie de la RFC2474. L’intention est que cette QS de bordure à bordure soit transposable, dans un sens purement technique, en une QS quantifiable à travers une région DS composée de plusieurs domaines DS.

Le groupe de travail Diffserv a terminé la première phase de la normalisation des comportements requis dans le chemin de transmission de tous les nœuds de réseau, les comportements de transmission par bond (PHB). Les PHB définis dans les RFC2474, 2597 et 2598 donnent une riche boîte à outils pour le traitement des paquets différenciés par les boîtes individuelles. Le modèle architectural général pour Diffserv a été documenté dans la RFC2475. Un modèle informel de routeur [RFC3290] décrit un modèle de conditionnement de trafic et d’autres comportements de transmission. Cependant, des questions techniques subsistent pour passer "au delà de la boîte" aux modèles de QS intra domaine

Le but ultime de la création d’une QS de bout en bout adaptable dans l’Internet exige qu’on puisse identifier et quantifier le comportement pour un groupe de paquets qui soit préservé lorsque ils sont agrégés avec d’autres paquets quand ils traversent l’Internet. L’étape de spécification des attributs de chemin de transmission sur la base du domaine pour un ensemble de paquets distingués seulement par la marque dans le champ DS des paquets individuels est critique dans l’évolution de la QS Diffserv et devrait fournir l’apport technique qui va aider à la construction des modèles d’affaire.

Le présent document définit et spécifie le terme "Comportement par domaine" ou PDB pour décrire les attributs de qualité de service à travers un domaine DS.

La classification et le conditionnement de trafic Diffserv sont appliqués aux paquets qui arrivent à la frontière d’un domaine DS pour imposer des restrictions à la composition des agrégats de trafic résultants, tels que distingués par le marquage DSCP, à l’intérieur du domaine. Les classeurs et conditionneurs de trafic sont établis pour refléter la politique et les buts du trafic pour ce domaine et peuvent être spécifiés dans un accord de conditionnement de trafic (TCA, Traffic Conditioning Agreement). Une fois que les paquets ont traversé la frontière DS, l’adhésion aux principes Diffserv rend possible de grouper les paquets conformément au comportement qu’ils reçoivent à chaque bond (selon le DSCP). Cette approche a des avantages d’adaptabilité bien connus, à la fois dans le chemin de transmission et dans le plan de contrôle. Moins bien reconnu est que ces propriétés d’adaptabilité ne se font jour que si la définition du comportement par bond fait naître un type particulier d’invariance sous agrégation. Comme le comportement par bond doit être équivalent pour chaque nœud dans le domaine, alors que l’ensemble de paquets marqués pour ce PHB peut être différent à chaque nœud, les PHB devraient être définis de telle sorte que leurs caractéristiques ne dépendent pas du volume de trafic du BA associé sur la liaison d’entrée d’un routeur ni d’un chemin particulier à travers le domaine DS emprunté par les paquets. Précisément, des flux différents du trafic qui appartiennent au même agrégat de trafic fusionnent et se séparent lorsque ils traversent le réseau. Si les propriétés d’un PDB qui utilisé un PHB particulier tiennent sans considération de la façon dont les caractéristiques temporelles de l’agrégat de trafic marqué changent lorsque il traverse le domaine, alors, ce PDB s’adapte. (Cela suppose clairement que les paramètres numériques tels que la bande passante allouée au PDB particulier peuvent être différents à des points différents dans le réseau, et peuvent être ajustés de façon dynamique aux variations du volume de trafic.)  Si il y a des limites auxquelles tiennent les propriétés, cela se traduit en une limite sur la taille ou la topologie d’un domaine DS qui peut utiliser cette PDB. Bien qu’il puisse exister des domaines DS à une seule liaison utiles, les PDB qui sont invariants avec la taille du réseau ou qui ont des relations simples avec la taille du réseau, et dont les propriétés peuvent être récupérées en ré appliquant les règles (c’est-à-dire, en formant une autre frontière ou bordure Diffserv pour remettre en application les règles pour l’agrégat de trafic) sont nécessaires pour construire une qualité de service adaptable de bout en bout.

Il y a une distinction claire entre la définition d’un comportement par domaine dans un domaine DS et un service qui pourrait être spécifié dans un accord de niveau de service. La définition de PDB est un bloc de construction technique qui permet le couplage des classeurs, des conditionneurs de trafic, de PHB spécifiques, et de configurations particulières avec un ensemble résultant d’attributs observables spécifiques qui peuvent être caractérisés de diverses façons. Ces définitions sont destinées à être des outils utiles pour la configuration des domaines DS, mais le ou les PDB utilisés par un fournisseur de service ne sont pas supposés être visibles au consommateur pas plus que ne le seraient les PHB spécifiques employés dans le réseau du fournisseur. Les fournisseurs de réseau sont supposés choisir leurs propres mesures qu’ils rendent visibles au consommateurs dans les contrats et celles-ci peuvent être décrites de façon assez différente des attributs techniques spécifiés dans une définition de PDB, bien que la configuration d’un PDB puisse être tirée d’une spécification de niveau de service (SLS, Service Level Specification). De façon similaire, des PDB spécifiques sont destinés à être des outils pour que les FAI (fournisseur d’accès Internet) construisent des offres de services différenciés ; chacun peut choisir des ensembles d’outils différents, ou même développer les siens propres, afin de réaliser une métrique particulière observable en externe. Néanmoins, les paramètres mesurables d’un PDB sont supposés être parmi les paramètres cités directement ou indirectement dans le composant spécification de niveau de service d’un SLA correspondant.

Le présent document définit les comportements par domaine de services différenciés et spécifie le format qui doit être utilisé pour la soumissions de PDB particuliers au groupe de travail Diffserv.

2.	Définitions

Les définitions suivantes figurent dans les RFC 2474 et 2475 et sont répétées ici pour référence :

"Agrégat de comportement" :	collection de paquets portant le même codet qui traversent une liaison dans une direction particulière.

"Domaine de services différenciés" : portion contiguë de l’Internet sur laquelle un ensemble cohérent de politiques de services différenciés sont administrées de façon coordonnée. Un domaine de services différenciés peut représenter différents domaines administratifs ou systèmes autonomes, différentes régions de confiance, différentes technologies de réseau (par exemple, cellule/trame) d’hôtes et de routeurs, etc. Dit aussi domaine DS.

"Frontière de services différenciés" : bordure d’un domaine DS, où sont vraisemblablement déployés les classeurs et les conditionneurs de trafic. Une frontière de services différenciés peut être encore subdivisée en nœuds d’entrée et de sortie, où les nœuds d’entrée/sortie sont les nœuds aval/amont d’une liaison frontière dans une certaine direction de trafic. Une frontière de services différenciés se trouve normalement à l’entrée du routeur à capacité de services différenciés du premier bond (ou nœud de réseau) que traversent les paquets d’un hôte, ou à la sortie du routeur à capacité de services différenciés du dernier bond ou du nœud de réseau que traversent les paquets avant d’arriver à un hôte. On appelle parfois cela la frontière à un routeur d’extrémité. Une frontière de services différenciés peut être colocalisée avec un hôte, sous réserve de la politique locale. Dit aussi frontière DS.

À ces définitions, on ajoute les suivantes :

"Agrégat de trafic" : collection de paquets avec un codet qui se transpose en le même PHB, habituellement dans un domaine DS ou un sous-ensemble d’un domaine DS. On se réfèrera à un agrégat de trafic marqué pour le PHB "foo" comme "agrégat de trafic foo" ou "agrégat foo" de façon interchangeable. Cela généralise le concept d’agrégat de comportement d’une liaison à un réseau.

"Comportement par domaine" : traitement prévu que va recevoir un groupe de paquets identifiable ou cible de "bord à bord" d’un domaine DS. (Dit aussi PDB.) Un PHB particulier (ou, si applicable, une liste de PHB) et des exigences de conditionnement de trafic sont associés à chaque PDB.

"Spécification de niveau de service" : (Dit aussi SLS) est un ensemble de paramètres et leurs valeurs qui ensemble définissent le service offert à un flux de trafic par un domaine DS. Il est supposé inclure des valeurs ou limites spécifiques pour les paramètres de PDB.

3.	Valeur de la définition du comportement de bord à bord

Comme défini à la section 2, un PDB décrit le comportement de bord à bord à travers le "nuage" d’un domaine DS. La spécification des attentes de transit des paquets qui correspondent à une cible pour un comportement Diffserv particulier à travers un domaine DS va à la fois aider au déploiement de la QS d’un seul domaine et va aider à activer la composition des services de bout en bout à travers le domaine. Les réseaux des domaines DS peuvent être connectés pour créer des services de bout en bout à partir des caractéristiques du PDB sans considération des PHB particuliers utilisés. Ce niveau d’abstraction rend plus facile de composer les services à travers le domaine ainsi qu’il rend possible de cacher les détails internes d’un réseau tout en exposant des informations suffisantes pour permettre la qualité de service.

L'Internet d’aujourd’hui se compose de multiples domaines ou systèmes autonomes (AS, Autonomous System) administrés indépendamment, représentés par les "nuages" à la Figure 1. Pour déployer partout une qualité de service de bout en bout dans l’Internet, les modèles doivent évoluer pour inclure les questions de facturation et de rapport qui ne figurent pas dans le domaine d’application de l’IETF. Pendant ce temps là, il y a de nombreuses utilisations possibles de la qualité de service au sein d’un AS et l’IETF peut régler les questions techniques en créant une QS intra domaine au sein d’un cadre de services différenciés. En fait, cette approche est assez sensible à des stratégies de déploiement incrémentaires.

Lorsque les domaines DS sont administrés de façon indépendante, l’évolution des accords d’affaire nécessaires et les futurs arrangements pour la signalisation vont prendre un certain temps, donc, les déploiements précoces se feront au sein d’un seul domaine administratif. En mettant de côté les questions commerciales, ce sont les mêmes questions techniques que pour l’interconnexion des domaines DS avec administration homogène qui vont resurgir lors de l’interconnexion des systèmes autonomes (AS) de l’Internet.

                 ----------------------------------------
                 |                AS2                   |
                 |                                      |
    -------      |     ------------     ------------    |
    | AS1 |------|-----X           |    |          |    |
    -------      |     |           |    Y          |    |        -------
                 |     |           |   /|          X----|--------| AS3 |
                 |     |           |  / |          |    |        -------
                 |     |           | /  ------------    |
                 |     |           Y      |             |
                 |     |           | \  ------------    |
    -------      |     |           |  \ |          |    |
    | AS4 |------|-----X           |   \|          |    |
    -------      |     |           |    Y          X----|------
                 |     |           |    |          |    |
                 |     ------------     ------------    |
                 |                                      |
                 |                                      |
                 ----------------------------------------

Figure 1 : Interconnexion des AS et des domaines DS

Un seul AS (par exemple, AS2 à la Figure 1) peut être composé de sous-réseaux et, comme le permet la définition, ceux-ci peuvent être des domaines DS séparés. Un AS peut avoir plusieurs domaines DS pour un certain nombre de raisons, la plus notable étant de suivre les frontière topologiques et/ou technologiques et de séparer l’allocation des ressources. Si on se limite aux frontières DS entre les domaines DS "intérieurs", on évite les problèmes non techniques d’établissement d’un service et on peut traiter les questions de création de PDB caractérisables.

La structure stimulante pour les services différenciés se fonde sur le fait que les domaines amont s’assurent que leur trafic se conforme aux accords de conditionnement de trafic (TCA, Traffic Conditioning Agreement) avec les domaines aval et que les domaines aval mettent en application ce TCA, donc la métrique associée aux PDB peut être calculée intelligemment. Les lettres "X" et "Y" de la Figure 1 représentent les routeurs frontière DS qui contiennent les conditionneurs de trafic qui assurent et mettent en application la conformité (par exemple, formatage et régulation). Bien que les régulateurs et formateurs soient supposés être aux frontières DS des AS (les boîtes "X") ils peuvent apparaître n’importe où, ou nulle part, à l’intérieur de l’AS. Précisément, les boîtes aux frontières DS internes à l’AS (les boîtes "Y") peuvent ou non conditionner le trafic. Les lignes directrices techniques pour le placement et la configuration des frontières DS devraient découler des attributs d’un PDB particulier lors de l’agrégation et de bonds multiples.

Cette définition de PDB continue la séparation de chemin de transmission et de plan de contrôle décrite dans la RFC2474. Les caractéristiques de chemin de transmission sont réglées en considérant comment le comportement à chaque bond du chemin d’un paquet est affecté par la fusion et la séparation des agrégats de trafic à travers plusieurs bonds. Les comportements par bond dans les nœuds sont configurés de façon peu fréquente, représentant un changement de l’infrastructure du réseau. Des changements plus fréquents de la qualité de service proviennent de l’emploi des fonctions du plan de contrôle dans la configuration des frontières DS. Un PDB fournit une liaison entre le niveau de domaine DS auquel le contrôle est exercé pour former les agrégats de trafic avec des objectifs de qualité de service à travers le domaine et les traitements par bond et par liaison que les paquets reçoivent résultent en la satisfaction des objectifs de qualité de service.

4.	Comprendre les PDB
4.1	Définir les PDB

Les RFC 2474 et 2475 définissent un agrégat de comportement de services différenciés comme "une collection de paquets avec le même codet DS qui traversent une liaison dans une direction particulière" et elles déclarent de plus que les paquets avec le même DSCP obtiennent le même traitement de transmission par bond (ou PHB) partout à l’intérieur d’un seul domaine DS. Noter que même si plusieurs DSCP se transposent en le même PHB, cela doit tenir pour chaque DSCP individuellement. À la section 2 du présent document, on a introduit une définition plus générale d’un agrégat de trafic au sens Diffserv de sorte qu’on peut aisément se référer aux paquets qui sont transposés en le même PHB partout au sein d’un domaine DS. La Section 2 présentait aussi une courte définition des PDB qui sera étendue dans la présente section : le comportement par domaine est le traitement attendu qu’un groupe de paquets identifiable ou cible va recevoir de "bordure à bordure" d’un domaine DS. Un PHB particulier (ou, si applicable, une liste de PHB) et des exigences de conditionnement du trafic sont associées à chaque PDB.

Chaque PDB a des attributs mesurables et quantifiables qui peuvent être utilisés pour décrire ce qui arrive à ses paquets lorsque ils entrent et traversent le domaine DS. Cela découle des caractéristiques de l’agrégat de trafic qui résulte de l’application de la classification et du conditionnement du trafic durant l’entrée des paquets dans le domaine DS et du traitement de transmission (PHB) que les paquets reçoivent à l’intérieur du domaine, mais peut aussi dépendre des charges du trafic entrant et de la topologie du domaine. Les attributs de PDB peuvent être absolus ou statistiques et ils peuvent être paramétrés par les propriétés du réseau. Par exemple, un attribut de perte peut être exprimé par "pas plus de 0,1 % de paquets seront éliminés lorsque mesurés sur toute durée supérieure à T", un attribut de délai pourrait être exprimé par "50 % de paquets livrés subiront un retard de moins de d millisecondes, 30 % subiront un retard de moins de 2d ms, 20 % subiront un retard de moins de 3d ms". Une large gamme de métriques est possible. En général, elles seront exprimées comme des limites ou des pourcentages plutôt que des valeurs absolues.

Un PDB est appliqué à un groupe cible de paquets arrivant à la bordure du domaine DS. Le groupe cible se distingue de tous les paquets arrivants par l’utilisation de classeurs de paquet [RFC2475] (où le classeur peut être "nul"). L’action du PDB sur le groupe cible a deux parties. La première partie est l’utilisation d’un conditionnement de trafic pour créer un agrégat de trafic. Durant le conditionnement de trafic, les paquets conformes sont marqués avec un DSCP pour le PHB associé au PDB (voir la Figure 2). La seconde partie est le traitement subi par les paquets provenant du même agrégat de trafic qui transitent à l’intérieur d’un domaine DS, entre et à l’intérieur des frontières du domaine DS. Les paragraphes qui suivent exposent plus en détails ces deux effets sur le groupe cible qui arrive à la frontière du domaine DS.

           -----------   ------------   ---------------------------   agrégat
paquets  _| classeurs |_|groupe cible|_| conditionnement de trafic |_ de trafic
arrivants |           | |de paquets  | |      & marquage (pour foo)|   foo
           -----------   ------------   ---------------------------

Figure 2 : Relations des agrégats de trafic associés à un PDB avec des paquets arrivants

4.1.1	Franchissement de la bordure DS : les effets du conditionnement du trafic sur le groupe cible
Cet effet est quantifié par la relation de l’agrégat de trafic émergeant avec le groupe cible entrant. Cette relation peut dépendre du schéma du trafic arrivant ainsi que de la configuration des conditionneurs de trafic. Par exemple, si le PHB EF [RFC2598] et un régulateur strict du taux R sont associés au PDB foo, alors la première partie de la caractérisation du PDB foo est d’écrire la relation entre les paquets cible arrivants et l’agrégat de trafic foo sortant. Dans ce cas, "le taux de l’agrégat de trafic foo émergeant est inférieur ou égal au plus petit de R et du taux d’arrivée du groupe de paquets cible" et des caractéristiques temporelles supplémentaires des paquets (par exemple, salve) peuvent être spécifiées si désiré. Donc, il y a un "taux de perte" sur le groupe cible arrivant qui résulte de l’envoi de trop de trafic ou de trafic avec les mauvaises caractéristiques temporelles. Ce taux de perte devrait être entièrement contrôlable par l’envoyeur amont conformément au conditionnement de trafic associé à la spécification de PDB.

La question de savoir "qui a le contrôle" du taux de perte (ou rétrogradation) aide à délimiter clairement ce composant de performances de PDB de celles associées au transit dans le domaine. Ce dernier est complètement sous le contrôle de l’opérateur du domaine DS et le premier est utilisé pour s’assurer que l’agrégat de trafic entrant se conforme au profil de trafic auquel l’opérateur a provisionné le réseau. De plus, les effets du conditionnement de trafic sur le groupe cible peuvent normalement être exprimés plus simplement que les effets du transit par le domaine DS sur le profil de trafic de l’agrégat de trafic.

Un PDB peut aussi appliquer le conditionnement de trafic à la sortie du domaine DS. L’effet de ce conditionnement sur les attributs globaux du PDB serait traité de façon similaire aux caractéristiques d’entrée (les auteurs pourront développer ce sujet à l’avenir, mais cela n’affecte pas matériellement les idées présentées dans ce document).

4.1.2	Traversée du domaine DS : effets du transit
Le second composant des performances du PDB est la métrique qui caractérise le transit d’un paquet de l’agrégat de trafic du PDB entre deux bordures quelconques de la frontière du domaine DS montrés à la Figure 3. Noter que la frontière du domaine DS passe à travers les routeurs frontière DS car l’agrégat de trafic est généralement formé dans le routeur frontière avant que les paquets soient mis en file d’attente et programmés pour la sortie. (Dans la plupart des cas, cette distinction est supposée être importante.)

Les DSCP ne devraient pas changer à l’intérieur d’un domaine DS car il n’y a pas d’application de conditionnement de trafic. Si il est nécessaire de réappliquer la sorte de conditionnement de trafic qui pourrait résulter en un nouveau marquage, il devrait y avoir une frontière de domaine DS à ce point, bien qu’une telle frontière "intérieure" puisse avoir des règles de "moindre poids" dans son TCA. Donc, lorsque on mesure des attributs entre des localisations comme indiqué à la Figure 3, le DSCP du côté sortie peut être supposé avoir tenu tout le long du domaine.

                               -------------
                               |           |
                          -----X           |
                               |           |
                               |  domaine  |
                               |   DS      X----
                               |           |
                          -----X           |
                               |           |
                               -------------

Figure 3 : Gamme d’applicabilité des attributs d’un agrégat de trafic associé à un PDB (entre les points marqués "X")

Bien qu’un domaine DS puisse ne pas être plus grand qu’un seul nœud, on s’attend à ce que la norme soit des topologies plus complexes, donc la définition de PDB doit tenir lorsque son agrégat de trafic est partagé et fusionné sur les liaisons intérieures d’un domaine DS. Le flux de paquet dans un réseau ne fait pas partie de la définition de PDB ; l’application du conditionnement de trafic lorsque les paquets entrent dans le domaine DS et le PHB cohérent à travers le domaine DS doivent suffire. Une définition de PDB n’a pas à tenir pour toutes les topologies de réseau, mais les limites de la gamme d’applicabilité d’un PDB spécifique doivent être clairement spécifiées.

En général, un PDB fonctionne entre N points d’entrée et M points de sortie à la frontière du domaine DS. Même dans le cas limite où N=M=1, les attributs de PDB sont plus complexes que la définition des attributs de PHB car l’enchaînement du comportement des nœuds intermédiaires affecte le premier. Un cas complexe avec N et M tous deux supérieurs à un implique des partages et des fusions dans le chemin du trafic et n’est pas trivial à analyser. Des travaux d’analyse, de simulation, et des expériences seront nécessaires pour comprendre même les PDB les plus simples.

4.2.	Construction des PDB

Un domaine DS est configuré pour satisfaire les objectifs d’ingénierie du trafic de l’opérateur du réseau pour le domaine indépendamment des objectifs de performances pour un flux particulier d’un agrégat de trafic. Une fois que les routeurs intérieurs sont configurés pour le nombre d’agrégats de trafic distincts que le réseau va traiter, l'allocation de chaque PDB à la bordure vient de la satisfaction des objectifs de performances désirés pour l'agrégat de trafic du PDB sous réserve de la configuration des programmeurs de paquet et de la capacité en bande passante. La configuration des conditionneurs de trafic à la bordure peut être altérée par le provisionnement ou le contrôle d’admission mais la décision sur quel PDB utiliser et comment appliquer la classification et conditionnement de trafic vient de la confrontation des performances et des buts.

Par exemple, considérons le domaine DS de la Figure 3. Un PDB avec une limite explicite de perte doit appliquer le conditionnement de trafic à la frontière pour assurer qu’en moyenne il ne soit pas admis plus de paquets qu’il n’en peut émerger. Bien que la mise en file d’attente en interne au réseau puisse résulter en une différence entre le trafic d’entrée et de sortie sur une certaine période de temps, le temps moyen ne devrait pas excéder ce qui peut être attendu d’une mémoire tampon de taille raisonnable à l’intérieur du réseau. Donc, si les salves sont admises à l’arrivée dans l’intérieur du réseau, il doit y avoir assez de capacité pour assurer que les pertes n’excèdent pas la limite. Noter que des limites explicites sur le niveau de pertes peuvent être particulièrement difficiles à fixer car la façon exacte dont fusionnent les paquets à l’intérieur du réseau affecte la sporadicité de l’agrégat de trafic du PDB et donc, les pertes.

Les PHB donnent des expressions explicites du traitement qu’un agrégat de trafic peut attendre à chaque bond. Pour un PDB, ce comportement doit s’appliquer à la fusion et à la séparation des agrégats de trafic, donc, la caractérisation d’un PDB requiert la compréhension de ce qui arrive à en PHB pendant une agrégation. C’est-à-dire que l’application récurrente des PHB doit résulter en un comportement connu. Par exemple, comme les tailles maximales de salves croissent avec le nombre de microflux ou de flux d’agrégat de trafic fusionnés, une spécification de PDB doit régler cela. Un clair avantage de la construction de comportements qui agrègent est la facilité d’enchaîner des PDB afin que l’agrégat de trafic associé ait des attributs connus qui couvrent les domaines DS intérieurs et, éventuellement plus loin. Par exemple, à la Figure 1, supposons que le PDB foo a été configuré sur les domaines DS intérieurs de AS2. Les agrégats de trafic associés au PDB foo dans chaque domaine DS intérieur de AS2 peuvent alors être fusionnés aux routeurs frontières intérieurs ombrés. Si les mêmes conditionneurs de trafic (ou moins) qu’appliqués à l’entrée de AS2 sont appliqués à ces frontières intérieures, les attributs du PDB foo devraient continuer d’être utilisés pour quantifier le comportement attendu. Des expressions explicites de ce qui arrive au comportement lors d’une agrégation, éventuellement paramétrées par nœud en degrés ou diamètres de réseau, sont nécessaires pour déterminer que faire aux points d’agrégation internes. Une approche pourrait être de réappliquer complètement le conditionnement de trafic à ces points ; une autre serait d’employer seulement un nouveau marquage à taux limité.

Plusieurs PDB peuvent utiliser le même PHB. La spécification d’un PDB peut contenir une liste de PHB et leur configuration exigée, dont tous vont résulter en le même PDB. En fonctionnement, on suppose qu’un seul domaine va utiliser un seul PHB pour mettre en œuvre un PDB particulier, bien que différents domaines puissent choisir des PHB différents. On se rappelle que dans la définition de Diffserv [RFC2474], un seul PHB peut être choisi au sein d’un domaine par une liste de DSCP. Plusieurs PDB peuvent utiliser le même PHB auquel cas, les performances de transit des agrégats de trafic de ces PDB vont, par nécessité, être les mêmes. Donc, les caractéristiques particulières que le concepteur de PDB souhaite proposer comme attributs peuvent varier, de sorte que deux PDB qui utilisent le même PHB peuvent ne pas être spécifiés avec la même liste d’attributs.

La spécification des attentes de transit des PDB à travers les domaines aide au déploiement de la QS au sein d’un domaine DS et aide à permettre la composition de services de bout en bout, à travers le domaine pour contribuer à rendre possible de cacher les détails de l’intérieur d’un domaine tout en exposant les caractéristiques nécessaires pour la QS.

4.3	PDB en utilisant des groupes de PHB

L’utilisation de groupes de PHB pour construire des PDB peut être faite de plusieurs façons. Un seul membre PHB d’un groupe de PHB peut être utilisé pour construire un seul PDB. Par exemple, un PDB pourrait être défini en utilisant juste un des PHB conformes au sélecteur de classe de la [RFC2474]. Le conditionnement de trafic pour ce PDB et la configuration requise du PHB particulier seraient définis de telle façon qu’il n’y ait pas de dépendance ou de relation avec la manière dont les autres PHB du groupe sont utilisés, ou bien sûr si ils sont utilisés dans ce domaine DS. Dans ce cas, l’approche raisonnable serait de spécifier ce PDB seul dans un document qui fixerait expressément les conditions et configuration du PHB de sélecteur de classe requis.

Un seul PDB peut être construit en utilisant plus d’un PHB du même groupe de PHB. Par exemple, le conditionneur de trafic décrit dans la RFC2698 pourrait être utilisé pour marquer un agrégat de trafic entrant particulier pour un des trois PHB AF1x [RFC2597] alors que les performances de transit du PHB résultant sont spécifiées, statistiquement, à travers tous les paquets marqués avec un de ces PHB.

Un ensemble de PDB en rapports pourrait être défini en utilisant un groupe de PHB. Dans ce cas, les PDB concernés devraient être définis dans le même document. Ceci est approprié lorsque les conditionneurs de trafic qui ont créé les agrégats de trafic associés à chaque PDB ont des relations et des interdépendances telles que les agrégats de trafic pour ces PDB devraient être décrits et caractérisés ensemble. Les attributs de transit vont dépendre du PHB associé au PDB et ne vont pas être les mêmes pour tous les PHB du groupe, bien qu’il puisse y avoir certaines relations paramétrées entre les attributs de chacun de ces PDB. Dans ce cas, chaque PDB devrait avoir une description clairement distincte de ses attributs de transit (délimités dans un sous paragraphe séparé) au sein du document. Par exemple, le conditionneur de trafic décrit dans la RFC2698 pourrait être utilisé pour marquer les paquets arrivants pour trois PHB AF1x différents, dont chacun est à traiter comme un agrégat de trafic distinct en termes de propriétés de transit. Un seul document pourrait alors être utilisé pour définir et quantifier les relations entre les paquets arrivants et les agrégats de trafic émergeants lorsque ils se rapportent les uns aux autres. Les caractéristiques de transit des paquets de chaque agrégat de trafic AF1x devraient être décrites séparément au sein du document.

Une autre façon dont pourrait être utilisé un groupe de PHB pour créer un PDB par PHB serait d’avoir découplé les conditionneurs de trafic, sauf certaines relations entre les PHB du groupe. Par exemple, un ensemble de PDB pourrait être défini comme utilisant des PHB conformes au sélecteur de classe [RFC2474] de telle façon que les conditionneurs de trafic qui créent les agrégats de trafic ne soient pas en relation, mais que les performances de transit de chaque agrégat de trafic aient une relation paramétrée avec celles des autres. Si cela a un sens de les spécifier dans le même document, le ou les auteurs devraient le faire.

4.4	Chemin de transmission contre plan de contrôle

Le PHB associé à un PDB, les classeurs, et les conditionneurs de trafic sont tous dans le chemin de transmission du paquet et fonctionnent au débit de la ligne. Les PHB, les classeurs, et les conditionneurs de trafic sont configurés en réponse à l’activité du plan de contrôle qui a lieu à travers une gamme d’échelles de temps, mais, même à la plus courte échelle de temps, les actions du plan de contrôle ne sont pas supposées se produire par paquet. Les classeurs et les conditionneurs de trafic aux frontières du domaine DS sont utilisés pour mettre en application qui utilise le PDB et comment le PDB devrait se comporter dans le temps. La reconfiguration des PHB peut survenir tous les mois, tous les trimestres, ou seulement lorsque le réseau est mis à niveau. Les classeurs et conditionneurs de trafic peuvent être reconfigurés à des intervalles réguliers durant le jour ou cela peut arriver en réponse à des décisions de signalisation des milliers de fois par jour. Beaucoup du travail du plan de contrôle est encore en évolution et sort de la charte du groupe de travail Diffserv. On note que cela est assez approprié car la manière dont la configuration est faite et le rythme auquel cela est fait ne devrait pas affecter les attributs de PDB.

5.	Format pour la spécification des comportement Diffserv par domaine

Les PDB proviennent d’une relation particulière entre la bordure et l’intérieur (qui peut être paramétrée). Les caractéristiques quantifiables d’un PDB doivent être indépendantes de la configuration statique ou dynamique de la bordure du réseau. La configuration particulière des conditionneurs de trafic à la bordure du domaine DS est critique pour les performances d’un PDB, mais le ou les actes de configuration de la bordure sont une action du plan de contrôle qui peut être séparée de la spécification du PDB.

Les paragraphes qui suivent doivent être présents dans toute spécification d’un PDB de services différenciés. Par nécessité, leur longueur et leur contenu va beaucoup varier.

5.1	Déclaration d’applicabilité

Toutes les spécifications de PDB doivent avoir une déclaration d’applicabilité qui précise l’utilisation prévue de ce PDB et les limites de son utilisation.

5.2	Spécification technique

Cette section spécifie les règles ou lignes directrices pour créer ce PDB, chacune distinguée par "peut", "doit" et "devrait." La spécification technique doit énumérer la classification et le conditionnement de trafic requis (s’il en est) et le (ou les) PHB à utiliser avec toutes exigences supplémentaires sur leur configuration au delà de celles contenues dans les RFC. La classification peut refléter le résultat d’un procès de contrôle d’admission. Le conditionnement de trafic peut inclure du marquage, du formatage de trafic et de la régulation. Une politique de provisionnement de service peut être utilisée pour décrire la spécification technique d’un PDB particulier.

5.3	Attributs

Les attributs d’un PDB disent comment il se comporte dans des conditions idéales si il est configuré de la façon spécifiée (où la spécification peut être paramétrée). Cela peut inclure le taux d’abandon, le débit, les limites de délai mesurées sur une certaine période de temps. Il peut y avoir des limites, des limites statistiques, ou en pourcentages (par exemple, "90 % de tous les paquets mesurés sur des intervalles d’au moins 5 minutes vont traverser le domaine DS en moins de 5 millisecondes").  Une grande variété de caractéristiques peut être utilisée mais elles doivent être explicites, quantifiables, et défendables. Lorsque des statistiques particulières sont utilisées, le document doit être précis quant à la façon de les mesurer et de déduire les caractéristiques.

Un conseil pour un opérateur de réseau serait d’utiliser ces élément comme lignes directrices pour la création d’une spécification de service plutôt que de les utiliser directement. Par exemple, un PDB "sans perte" ne sera probablement pas vendu comme tel, mais plutôt comme un service avec une très faible probabilité de perte de paquet.

5.4	Paramètres

La définition et les caractéristiques d’un PDB peuvent être paramétrées par caractéristiques spécifiques de réseau ; par exemple, le nombre maximum de bonds, la bande passante minimum, le nombre total de points d’entrée/sorties du PDB de/vers le réseau Diffserv, le délai maximum de transit des éléments de réseau, la taille minimum de mémoire tampon disponible pour le PDB à un nœud de réseau, etc.

5.5	Hypothèses

Dans la plupart des cas, les PDB seront spécifiés en supposant des liaisons sans perte, pas de défaillance de liaison, et un acheminement relativement stable. Cela est raisonnable car autrement, il serait très difficile de quantifier le comportement et c’est la condition de fonctionnement que recherchent la plupart des opérateurs. Cependant, ces hypothèses doivent être clairement établies. Comme les PDB avec des paramètres de bande passante spécifiques exigent que la bande passante soit disponible, les hypothèses à déclarer peuvent inclure des capacités en attente. Certains PDB peuvent être spécifiquement ciblés pour les cas où ces hypothèses ne tiennent pas, par exemple, pour des liaisons à fort taux de perte, et une telle cible doit aussi être déclarée explicitement. Si des restrictions supplémentaires, en particulier des mesures spécifiques d’ingénierie du trafic, sont requises, elles doivent être déclarées.

De plus, si des hypothèses sont faites sur l’allocation de ressources au sein d’un réseau Diffserv dans la création du PDB, elles doivent être faites explicitement.

5.6	Exemple d’utilisation

Une spécification de PDB doit donner des exemples d’utilisation pour illustrer la compréhension des moyens par lesquels un réseau Diffserv pourrait faire usage du PDB bien qu’on ne s’attende pas à ce qu’ils soient détaillés. Par exemple, "Un PDB de traitement en vrac peut être utilisé pour tous les paquets qui ne devraient prendre aucune ressources du réseau sauf si elles ne sont pas utilisées par ailleurs. Cela peut être utile pour du trafic Netnews ou pour du trafic rejeté d’autres PDB par les politiques de trafic".

5.7	Problèmes d’environnement (support, topologie, etc.)

Noter qu’il n’est pas nécessaire pour un fournisseur d’exposer quel PDB (si c’en est un couramment défini) est utilisé ni pour un fournisseur de spécifier un service par les attributs de PDB.  Par exemple, un fournisseur de service peut utiliser un PDB avec une caractéristique de "pas de perte de mise en file d’attente" afin de spécifier un service "à très faibles pertes".

Cette section est destinée à faire entrer un peu de réalisme dans les caractéristiques décrites ci-dessus. Le détail des hypothèses faites ici et des contraintes qu’elles font peser sur la topologie ou le type de support ou allocation physique.

5.8	Considérations de sécurité pour chaque PDB

Cette section devrait inclure toutes les considérations de sécurité qui sont spécifiques de ce PDB. Est-il sujet à des attaques inhabituelles de vol de service  ou de déni de service ?  Des précautions de sécurité inhabituelles sont elles nécessaires ?

Il n’est pas nécessaire de répéter l’exposé général de sécurité des [RFC2474] et [RFC2475], mais une référence devrait être incluse. Se référer aussi à toute considérations de sécurité particulière pour le PHB ou les PHB utilisés.

6.	Attributs de PDB

Comme exposé à la Section 4, des attributs mesurables et quantifiables associés à chaque PDB peuvent être utilisés pour décrire ce qui arrive aux paquets qui utilisent ce PDB lorsque ils traversent le domaine. Dans son rôle de pierre de taille de la construction de la qualité de service inter domaine, une spécification de PDB devrait fournir la réponse à la question : sous quelles conditions peut on joindre le résultat de ce domaine à un autre avec le même conditionnement de trafic et les mêmes attentes ? Bien qu’il y ait de nombreuses façons par lesquelles le trafic peut être réparti, créant des PHB quantifiables et réalisables qui peuvent être enchaînés dans des services multi domaines limite les scénarios réalistes. Une déclaration claire des conditions dans lesquelles tiennent les attributs d’un PDB est un élément critique de la composition de services multi domaines.

Il y a une claire corrélation entre le caractère strict du conditionnement de trafic et la qualité des attributs du PDB. Comme on l’a indiqué précédemment, les limites numériques ont des chances d’être statistiques ou exprimées comme un pourcentage. Les paramètres exprimés comme des limites strictes exigeront une analyse mathématique très précise, alors que celle exprimées statistiquement peuvent dans une certaine mesure s’appuyer sur l’expérience. La Section 7 donne l’exemple d’un PDB sans strict conditionnement de trafic et un travail concurrent sur un PDB avec strict conditionnement de trafic et attributs est aussi présenté au groupe de travail [VW]. Cette section donne des considérations générales sur la caractérisation des attributs de PDB.

Il y a deux façons de caractériser les PDB par rapport au temps. La première est avec les propriétés sur de "longues" périodes, ou comportements moyens. Une spécification de PDB devrait les rapporter comme des taux ou débits vus sur une période spécifiée. De plus, il y a des propriétés de comportement de temps "court", usuellement exprimées comme la sporadicité admissible dans un agrégat de trafic. Le comportement de court terme est important pour comprendre les exigences de mémoire tampon (et les caractéristiques de perte qui leur sont associées) et pour des considérations de métrique et de conditionnement aux frontières DS. Pour le comportement de temps court, on s’intéresse principalement à deux choses : 1) combien de paquets dos à dos de l’agrégat de trafic du PDB seront vus en tout point (ce serait mesuré comme une salve) et 2) quelle taille de salve de paquets d’agrégat de trafic de ce PDB peut apparaître en une fois dans une file d’attente (on donne le débordement de la file d’attente et le taux de pertes). Si d’autres PDB utilisent le même PHB au sein du domaine, cela doit être pris en compte.

6.1	Considérations sur la spécification d’attributs de PDB à long ou moyen terme

Pour caractériser le comportement moyen ou à long terme pour le PDB foo, on doit explorer un certain nombre de questions : par exemple, le domaine DS peut il traiter le flux moyen de trafic foo ? Cette réponse dépend-elle de la topologie ou y a t-il des hypothèses spécifiques sur l’acheminement qui doivent tenir pour que le PDB foo préserve sa capacité de "provisionnement adéquat" ? En d’autres termes, si la topologie de D change soudain, les attributs du PDB foo vont-ils changer ? Son taux de pertes va t-il augmenter brusquement ?

Soit le domaine D de la Figure 4 un FAI qui appelle les U.S.A avec des liaisons de bande passante B et avec N terminaisons sur diverses zones métropolitaines. À l’intérieur de D, si la liaison entre le nœud connecté à A et le nœud connecté à Z tombe en panne, tout l’agrégat de trafic foo entre les deux nœuds doit transiter par l’anneau entier ; le comportement limité du PDB foo va t-il changer ? Si cette panne a pour résultat qu’un nœud de l’anneau a maintenant un taux d’arrivage plus grand vers une de ses liaisons que la capacité de la liaison pour l'agrégat de trafic de foo, il est clair que le taux de perte va changer considérablement. Dans ce cas, des hypothèses topologiques ont été faites sur le chemin du trafic de A à Z qui ont affecté les caractéristiques du PDB foo. Si ces hypothèses topologiques ne tiennent plus, le taux de perte de paquets de l’agrégat de trafic foo qui transitent par le domaine pourraient changer ; par exemple, une caractéristique telle que "taux de perte pas supérieur à 1 % sur tout intervalle supérieur à 10 minutes". une spécification de PDB devrait invoquer les hypothèses faites sur la conservation des attributs.

                  ____X________X_________X___________          /
                 /                                   \    L   |
         A<---->X                                     X<----->|  E
                |                                     |       |
                |               D                     |        \
         Z<---->X                                     |
                |                                     |
                 \___________________________________/
                         X                 X

Figure 4 : FAI et domaine DS D connectés en anneau et connectés au domaine DS E

6.2	Considérations sur la spécification d’attributs de PDB à court terme ou saccadés

Considérons ensuite le comportement à court terme de l’agrégat de trafic associé à un PDB, et précisément si permettre d’ajouter les salves maximum de la même manière que les taux moyens conduit à des propriétés qui s’agrègent ou dans quelles conditions cela va conduire à des propriétés qui s’agrègent. Dans notre exemple, si le domaine D permet à chacune des liaisons amont d’envoyer en salve p paquets dans l’agrégat de trafic foo, les salves peuvent s’accumuler lorsque elles transitent par l’anneau. Les paquets destinés à la liaison L peuvent venir des deux directions de l’anneau et les paquets dos à dos provenant de l’agrégat de trafic foo peuvent arriver au même moment. Si la bande passante de la liaison L est la même que les liaisons de l’anneau, cela ne pose vraisemblablement pas de problème de mémoire tampon. Si il y a deux liaisons d’entrée qui peuvent envoyer des paquets en file d’attente pour L, au pire, deux paquets peuvent arriver simultanément pour L. Si la bande passante de la liaison L égale ou excède deux fois B, les paquets ne vont pas s’accumuler. De plus, si p est limité à un, et si la bande passante de L excède le taux d’arrivée (sur le plus long terme) de paquets foo (nécessaire pour la limite de perte) alors la file d’attente des paquets foo pour la liaison L va se vider avant que de nouveaux paquets arrivent. Si la bande passante de L est égale à B, un paquet foo doit faire la queue tandis que l’autre est transmis. Il en résultera que N x p paquets dos à dos de cet agrégat de trafic arrivent sur L durant la même période de temps que les salves de p étaient permises sur les liaisons montantes. Donc, configurer le PDB de façon que la liaison L puisse traiter la somme des taux qui sont entrés pour le PDB foo ne garantit pas que L puisse traiter la somme des N salves dans le PDB foo.

Si la bande passante de L est inférieure à B, la liaison doit alors mettre N x p x (B - L)/B paquets foo pour éviter des pertes. Si le PDB obtient moins que la pleine bande passante L, ce nombre est plus grand. Pour les limites probabilistes, une plus petite mémoire tampon pourrait aller si la probabilité de dépassement peut être limitée.

Plus généralement, pour un routeur de degré d, les salves de paquets foo peuvent arriver sur chaque entrée. Puis, en l’absence de tout conditionnement de trafic supplémentaire, il est possible que d x p x (nombre de liaisons montantes) paquets foo dos à dos puissent être envoyés à travers la liaison L au domaine E. Donc, le domaine DS E doit permettre ces beaucoup grosses salves dans le PDB foo que ne le permet le domaine D sur les N liaisons montantes ou autrement l’agrégat de trafic foo doit être rendu conforme au TCA pour entrer dans E (par exemple, par formatage).

Quelles conditions devraient être imposées à un PDB et au PHB associé afin d’assurer que les PDB peuvent être enchaînés, comme au travers des domaines DS intérieurs de la Figure 1 ? Le conditionnement de trafic pour construire un PDB qui ait certains attributs à travers un domaine DS devrait s’appliquer indépendamment de l’origine des paquets. En référence à l’exemple déjà utilisé, le TCA pour le PDB de l'agrégat de trafic entrant dans la liaison L dans le domaine E ne devrait pas dépendre du nombre de liaisons montantes dans le domaine D.

6.3	Remarques

Cette section a été fournie pour donner à réfléchir aux concepteurs de PDB. Elle n’est en aucun cas un catalogue exhaustif des attributs de PDB possibles ou du type d’analyse qui doit être faite. On s’attend à ce que ce soit une partie intéressante et évolutive du travail de compréhension et de déploiement des services différenciés dans l’Internet. Il y a un potentiel de très intéressants travaux de recherche. Cependant, en soumettant une spécification de PDB au groupe de travail Diffserv, un PDB doit aussi satisfaire à la vérification de son utilité et de sa pertinence par une expérience de déploiement, décrite à la section 8.

7.	Comportement par domaine de référence

L’intention de cette section est de définir une référence de PDB au mieux, un PDB qui a peu de règles et de faibles attentes.

7.1	PDB au mieux
7.1.1	Applicabilité
Un PDB au mieux (BE, Best Effort) est pour envoyer du "trafic Internet normal" à travers un réseau Diffserv. C’est à dire que la définition et l’utilisation de ce PDB est pour préserver, dans une mesure raisonnable, les attentes de livraison pré Diffserv pour les paquets qui dans un réseau Diffserv n’exigent aucune différenciation particulière. Bien que le PDB lui-même ne comporte pas de limites sur la disponibilité, la latence, et la perte de paquets, cela n’empêche par les fournisseurs de service de faire une ingénierie de leur réseau pour obtenir des limites commercialement viables sur les services qui utilisent le PDB BE. Cela serait analogue aux garanties de niveau de service qui sont fournies dans l’Internet à service unique d’aujourd’hui.

Dans l’Internet commercial à un seul service d’aujourd’hui, les garanties de niveau de service pour la disponibilité, la latence et la livraison de paquet se trouvent sur les sites de la Toile des FAI [WCG], [PSI], [UU]. Par exemple, une limite de latence aller-retour normale en Amérique du Nord est de 85 millisecondes, et les sites d’information de chaque fournisseur de services spécifient la méthode de mesure des limites et les termes associés contractuellement à ces limites.

7.1.2	TCS et configurations de PHB
Il ne pèse aucune restriction sur les taux et salves de paquets au delà des limites imposées par la liaison d’entrée. Le côté réseau s’assure que les paquets qui utilisent le PDB sont marqués pour le PHB par défaut (comme défini dans la [RFC2474]) mais aucun autre conditionnement de trafic n’est requis. Les nœuds intérieurs du réseau appliquent le PHB par défaut sur ces paquets.

7.1.3	Attributs de ce PDB
"Autant que possible aussitôt que possible".

Les paquets de ce PDB ne seront pas complètement affamés et lorsque des ressources sont disponibles (c’est-à-dire, non exigées par des paquets de tout autre agrégat de trafic) les éléments de réseau devraient être configurés à permettre aux paquets de ce PDB de les consommer.

Les opérateurs de réseau peuvent fixer des limites au délai et au taux de perte pour les services construits à partir de ce PDB en fonction des connaissances qu’ils ont sur leur réseau, mais de tels attributs ne font pas partie de la définition.

7.1.4	Paramètres
Aucun.

7.1.5	Hypothèses
Un réseau fonctionnant correctement, c’est-à-dire où les paquets peuvent être livrés de toute entrée à toute sortie.

7.1.6	Exemple d’utilisation
1.	Pour la connexion de trafic Internet normale d’une organisation.
2.	Pour le trafic Internet "non critique" d’une organisation.
3.	Pour les connexions standard d’usager domestique.

7.1.7	Problèmes d’environnement
Il n’y a pas de problème d’environnement spécifique de ce PDB.

7.1.8	Considérations de sécurité pour le PDB au mieux
Il n’y a pas d’exposition de la sécurité spécifique de ce PDB. Voir les considérations de sécurité générales des [RFC2474] et [RFC2475].

8.	Lignes directrices pour la rédaction des spécifications de PDB

G1.	Suivant le format donné dans ce document, écrire un projet et le soumettre comme projet Internet. Le document devrait porter "diffserv" quelque part dans son titre. Un appendice au projet, ou un document distinct, donne les détails de l’expérience de déploiement avec des résultats mesurés sur un réseau de taille non triviale et portant un trafic réaliste et/ou des résultats de simulation convaincants (la simulation d’une gamme de schémas de trafic modernes et de topologies de réseau selon le cas applicable). Le document devrait être porté à l’attention de la liste de diffusion du groupe de travail Diffserv, si il est toujours actif.

G2.	L’exposé initial devrait se concentrer principalement sur les mérites du PDB, bien qu’il soit raisonnable de l’assortir de commentaires et questions sur les attributs revendiqués. Ceci est en ligne avec le but des services différenciés de mettre la pertinence avant l’intérêt académique dans les spécifications de PDB. Les PDB intéressants du point de vue académique sont encouragés, mais seraient plus appropriés pour des publications et conférences techniques, et non pour une soumission à l’IETF. (Un PDB "académiquement intéressant" peut devenir un PDB intéressant  à déployer au fil du temps.)

La mise en œuvre des lignes directrices suivantes varie, selon qu’il y a ou non un groupe de travail Diffserv actif ou non.

Voie du groupe de travail Diffserv actif :

G3.	Une fois qu’un consensus a été réalisé sur une version d’un projet qui est un PDB utile et que ses caractéristiques "paraissent" correctes (c’est-à-dire, pas fausses de façon flagrante) cette version du projet passe devant un comité de relecture co-présidé par le groupe de travail chargé d’examiner et faire rapport sur ses caractéristiques. Le comité de relecture a une date limite pour la relecture. La fixation des dates exactes sera établie au cas par cas par les co-présidents pour refléter la complexité de la tâche et les autres contraintes (réunions de l’IETF, périodes de vacances) mais est supposé être dans une gamme de 4 à 8 semaines. Durant cette période, le comité peut correspondre directement avec les auteurs (en faisant copie aux co-présidents du groupe de travail) pour obtenir des éclaircissements. Ce processus devrait résulter en un projet révisé et/ou un rapport au groupe de travail de la part du comité appuyant ou réfutant les caractéristiques revendiquées.

G4.	Si/lorsque appuyé par le comité, ce projet passe en dernier appel du groupe de travail. Si il n’est pas appuyé, le ou les auteurs peuvent faire une réponse point par point au rapport du comité et demander un dernier appel au groupe de travail.

G5.	Si/lorsque il réussit le dernier appel, il passe en AD pour publication comme RFC d’information du groupe de travail dans la "série de PDB".

Si il n’existe pas de groupe de travail Diffserv actif :

G3.	Suivant la discussion sur les listes de diffusion pertinentes, les auteurs devraient réviser le projet Internet et contacter l’IESG pour une "révision par expert" comme défini à la Section 2 de la [RFC2434].

G4.	Suite à la révision, l’IESG peut recommander la publication du projet comme RFC, demander des révisions, ou refuser de publier comme RFC pour information dans la "série de PDB".

9.	Considérations sur la sécurité

Les considérations générale de sécurité des [RFC2474] et [RFC2475] s’appliquent à tous les PDB. Les définitions de PDB individuels peuvent exiger des considérations de sécurité supplémentaires.

10.	Remerciements

Les idées de ce document ont été largement influencées par le groupe de travail Diffserv et, en particulier, par des discussions avec Van Jacobson, Dave Clark, Lixia Zhang, Geoff Huston, Scott Bradner, Randy Bush, Frank Kastenholz, Aaron Falk, et une foule d’autres personnes qui devraient être remerciées de leur utile concours mais qui n’ont pas été énumérées ici. Grenville Armitage a forgé le terme de  comportement par domaine (PDB)" bien que certains aient suggéré des termes similaires avant lui. Dan Grossman, Bob Enger, Jung-Bong Suk, et John Dullaert on relu le document et leurs commentaires ont amélioré sa forme.

Références

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

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

[RFC2598]	V. Jacobson, K. Nichols, K. Poduri, "PHB Transmission expédiée", juin 1999. (Obsolète, voir RFC3246) (P.S.)

[RFC2698]	J. Heinanen, R. Guerin, "Marqueur de trafic à deux débits à trois couleurs", septembre 1999. (Information)

[RFC3289]	F. Baker, K. Chan, A. Smith, "Base de données d'informations de gestion pour l'architecture de services différenciés", mai 2002. (P.S.)

[RFC3290]	Y. Bernet et autres, "Modèle informel de gestion pour routeurs Diffserv", mai 2002. (Information)

[VW]	Jacobson, V., Nichols, K. et K. Poduri, "The 'Virtual Wire' Per-Domain Behavior", Non publiée comme RFC.

[WCG]	Worldcom, "Internet Service Level Guarantee", http://www.worldcom.com/terms/service_level_guarantee/t_sla_terms.phtml 

[PSI]	SINet, "Service Level Agreements", http://www.psinet.com/sla/ 

[UU]	UNET USA Web site, "Service Level Agreements", http://www.us.uu.net/support/sla/ 

Adresse des auteurs

Kathleen Nichols	Brian Carpenter	
Packet Design, LLC	IBM	
2465 Latham Street, Third Floor	c/o iCAIR	
Mountain View, CA 94040	Suite 150	
USA	1890 Maple Avenue	
mél : nichols@packetdesign.com	Evanston, IL 60201	
	USA	
	mél : brian@icair.org	

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2001). 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 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 c'est 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.

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