Groupe de travail Réseau

D. Clark, Laboratoire d'informatique du M.I.T.

Request for Comments : 1102

mai 1989

Traduction Claude Brière de L'Isle

 

 

 

Politique d'acheminement dans les protocoles de l'Internet

 

 

1.   Statut de ce mémoire

 

L'objet de la présente RFC est de focaliser la discussion sur des problèmes particuliers de l'Internet et leurs méthodes possibles de solution. Aucune des solutions proposées dans le présent document n'est considérée comme une norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

 

2.   Introduction

 

La fonction d'acheminement est un composant à part entière des protocoles de l'Internet. Elle détermine la suite des réseaux et routeurs qu'un paquet va traverser en passant de la source à la destination. Bien que de nombreux protocoles d'acheminement aient été utilisés dans l'Internet, ils partagent tous l'idée qu'un chemin devrait être choisi parmi tous les chemins disponibles sur la base de la minimisation de certaines mesures du chemin, comme le délai. Récemment, il est devenu important de choisir les chemins afin de restreindre l'utilisation des ressources réseau à certaines classes de consommateurs. Ces considérations, qui sont généralement décrites comme des politiques de ressources, sont mal mises en application par les technologies existantes dans l'Internet. Le présent document propose une approche de l'intégration des contrôles de politique dans l'Internet.

 

On suppose que dans l'Internet, les ressources, réseaux, liaisons, et routeurs, sont répartis en régions administratives ou AR. Chaque AR est gouvernée par une administration plus ou moins autonome, avec des objectifs distincts quant à la classe de consommateurs qu'elle est destinée à servir, aux qualités de service qu'elle a l'intention de livrer, et à ses moyens de rémunération. Pour construire un chemin à travers l'Internet, elle doit choisir une séquence d'AR qui fournisse collectivement un chemin de la source à la destination. Cette séquence d'AR sera appelée un chemin de politique (PR, Policy Route). Chaque AR à travers laquelle passe un chemin de politique aura pour préoccupation que le PR ait été correctement construit. Pour cela, chaque AR peut vouloir s'assurer que l'utilisateur du PR est autorisé, que la qualité de service demandée est prise en charge, et que le prix du service peut être perçu.

 

Dans l'abstrait, un chemin de politique est une série d'AR, qui sont supposées être désignées par des identifiants uniques au monde. (L'exigence de noms valables mondialement pour les AR suggère que l'espace des noms des AR est plat. Cette hypothèse simplificatrice est faite dans la présente RFC, mais il devrait être possible d'étendre le schéma décrit ici pour permettre l'imbrication des AR afin de réduire la quantité globale d'informations. Le problème de l'ajout de structures à l'espace des AR est un exercice qu'on remettra à plus tard.) Avant qu'un PR ne puisse être utilisé, il doit cependant être traduit en termes plus concrets : une série de routeurs qui connectent la séquence des AR. Ces routeurs seront appelés des routeurs de politique (PG, Policy Gateway).

 

À présent, le mécanisme le plus proche de l'acheminement selon une politique dans l'Internet est EGP, le protocole de routeur extérieur. EGP a été construit pour permettre à des régions de l'Internet de communiquer les informations d'accessibilité, même si elles ne sont pas totalement de confiance. À cet égard, les régions reliées par EGP pourraient être vues chacune comme une région administrative. Cependant, les mécanismes de EGP imposent une restriction topologique à l'interconnexion des régions administratives. En pratique, cela s'est révélé insatisfaisant. Les questions de politique sont menées par des préoccupations humaines, et elles ne peuvent être réduites à des contraintes topologiques, ou même à quelque sorte de contrainte que ce soit.

 

Les propositions du présent mémoire sont conçues pour permettre la plus grande latitude possible dans la construction et la mise en application des politiques. En particulier, aucune restriction topologique n'est supposée. En général, l'approche suivie par ce mémoire est conduite par la conviction que comme les politiques reflètent les préoccupations humaines, le système devrait se préoccuper principalement de la mise en application des politiques plutôt que de la synthèse de la politique. Cette proposition permet aux points d'extrémité et aux services de transit d'exprimer et mettre en application les préoccupations de politique locale.

 

3.   Chemins de politique

 

Presque toutes les approches des contrôles de politique partagent, à un degré ou un autre, l'idée d'un chemin de politique. Le composant distinctif d'une approche de politique est la procédure par laquelle est synthétisé le chemin de politique. Une des approches pour la synthèse des chemins est d'associer à chaque politique distincte un sous-ensemble de tous les routeurs du système, et de faire tourner un algorithme de routage à travers le sous-ensemble de routeurs. Cette approche a plusieurs inconvénients. Elle exige un calcul d'acheminement distinct pour chaque politique, ce qui peut être prodigieusement coûteux. Elle exige l'accord global sur la nature et la portée de chaque politique, ce qui est à l'opposé du désir que les régions administratives établissent leurs propres hypothèses de politique de façon indépendante. Finalement, elle implique presque inévitablement une restriction topologique sur l'interconnexion des régions.

 

Une autre approche synthétique est que chaque routeur de politique examine les paquets entrants et détermine, sur la base des contraintes de politique locale, la prochaine AR la plus appropriée. Cette approche peut éventuellement fonctionner, mais elle a encore une fois plusieurs inconvénients. D'abord, elle implique une quantité de calcul substantielle de la part de chaque routeur de politique. Plus important, elle retire le choix du chemin aux endroits où il devrait le plus naturellement être exécuté, les points d'extrémité de la connexion.

 

Il est utile de considérer les AR interconnectées comme un marché dans lequel divers services sont offerts et où les utilisateurs font un choix parmi ces services pour obtenir le transport des paquets. Selon cette analogie, il semble approprié que le choix réel du chemin de politique soit fait par les AR d'extrémité qui désirent envoyer les paquets, plutôt que par les routeurs de politique. Si on compare avec le système téléphonique, c'est le consommateur du système téléphonique qui choisit les transporteurs longue distance à utiliser, et si il veut acheter un service à prix fixe ou payer en fonction de l'utilisation, et ainsi de suite. Dans cette proposition, les chemins de politique sont donc synthétisés au point d'extrémité d'où le paquet provient, et sont attachés aux paquets afin de les diriger à travers la série appropriée d'AR. En d'autres termes, les chemins de politique sont une forme d'acheminement de source. Le rôle de synthèse d'un chemin de politique est partagé entre l'AR de source et l'hôte de source particulier.

 

Dans cette architecture, la fonction du routeur de politique n'est donc pas de faire la synthèse du chemin de politique, mais de le vérifier. Dans les paragraphes suivants, nous allons traiter les deux questions de la façon dont le chemin de politique est vérifié, et de comment est synthétisé un chemin de politique.

 

En déterminant que les chemins de politique devraient être synthétisés au point d'extrémité, il est important de distinguer deux aspects de l'acheminement qui reflètent des soucis de politique légitimes, et les aspects de l'acheminement qui, en réalité, se rapportent au détail du fonctionnement des AR. Par exemple, si on représentait les chemins de politique qui utilisent le mécanisme existant de route de source de l'Internet, qui permet au point d'extrémité de spécifier une série de routeurs à travers lesquels le paquet devrait passer, le résultat serait que trop de fonctions ont été transférées de l'intérieur de l'Internet aux points d'extrémité. Le point d'extrémité devrait avoir une connaissance exacte des routeurs qui sont actifs et opérationnels à un moment donné, et ce degré de connaissance ne peut pas être justifié par les préoccupations de politique. De plus, il serait nécessaire de faire fonctionner un protocole d'accessibilité des routeurs à l'échelle du système.

 

Notre proposition tente de maintenir l'équilibre entre la spécification par le point d'extrémité des préoccupations qui se rapportent légitimement à la politique, et la détermination locale dans les routeurs de politique des détails plus spécifiques nécessaires à un fonctionnement fiable. Cela conduit à un modèle d'acheminement à deux niveaux, dans lequel le chemin de politique abstrait, une série de régions administratives, est spécifié par le point d'extrémité comme une forme de route de source, et chaque routeur de politique choisit le prochain routeur de politique réel qui va être utilisé pour transmettre ce paquet. En d'autres termes, le chemin de politique abstrait est rendu concret par incréments. Cette division des fonctions exige que l'AR de source sache si il y a des défauts qui ont provoqué des partitions de paires d'AR qui sont normalement connectées ensemble. Cela implique de faire fonctionner un protocole d'accessibilité globale pour les besoins de la fourniture d'informations à l'AR de source, mais il n'y a besoin de se préoccuper que du niveau des AR, et non du niveau des routeurs. Dans une section ultérieure sur la récupération des coûts, le sujet du choix du routeur sera exposé plus en détail.

 

Une objection à un schéma tel que l'acheminement de source est que le chemin de source qui peut être en vrac doit être dans chaque paquet, et doit être évalué pour chaque paquet. Une solution à ce problème de performances est d'employer une forme limitée d'établissement de chemin, dans laquelle le chemin de politique réel n'est transporté que dans le premier paquet d'une séquence, et un court identifiant ou "bretelle" est inclus dans les paquets suivants de la séquence. Chaque routeur de politique évalue le PR sur le premier rencontré, et place le résultat en antémémoire, qui est ensuite restitué pour les paquets ultérieurs en utilisant la bretelle dans le paquet. L'idée d'une bretelle et d'une mise en antémémoire, ainsi que le besoin d'une forme d'établissement de chemin, est exposée plus loin.

 

4.   Vérification des chemins de politique

 

Lorsque un paquet arrive à un routeur de politique, essayant de rentrer dans une AR, le routeur de politique doit décider si il est légitime de transmettre ce paquet, et s'il en est ainsi, sur quel prochain routeur de politique le paquet devrait sortir de l'AR (en supposant que la destination finale n'est pas à l'intérieur de l'AR). Les informations disponibles pour que le routeur de politique prenne sa décision déterminent la gamme des politiques qui peuvent être mises en application. Déterminer quelles informations doivent être disponibles est donc une disposition centrale de notre proposition.

 

4.1   Identification de l'utilisateur

 

Les décisions d'acheminement classiques, celles qui minimisent les coûts, sont normalement seulement fondées sur la destination du paquet. Au minimum, les décisions de politique doivent être fondées à la fois sur la source et la destination du paquet. En fait, les adresses de source et de destination peuvent n'être pas suffisantes pour déterminer la politique, car une AR peut prendre en charge des utilisateurs différents avec des droits différents, et de plus un seul usager peut souhaiter exercer des droits différents à des moments différents. On suggère que pour identifier l'usager qui propose d'utiliser ce chemin de politique particulier, il est suffisant que les paquets contiennent l'hôte de source et l'AR, l'hôte de destination et l'AR, et facultativement, un identifiant de classe d'utilisateur (UCI, User Class Identifier). Dans un paragraphe ultérieur est exposée la manière d'empêcher une mauvaise utilisation de l'identifiant de classe d'utilisateur.

 

En fait, les adresses d'hôte de source et de destination peuvent n'être pas nécessaires pour prendre en charge la gamme pratique des décisions de politique requises aux AR intermédiaires. Les informations de l'AR de source et de destination peuvent être seules nécessaires. Si des adresses d'hôte individuel sont à utiliser, cela implique que les AR intermédiaires voudront garder trace des droits des hôtes individuels. Il serait plus simple que l'AR de source soit de confiance pour permettre que seuls les hôtes appropriés utilisent certains PR. Cela sera examiné dans un paragraphe ultérieur lors de l'exposé sur le rôle du contrôleur de politique.

 

4.2   Vérification du chemin

 

Le paquet contient un chemin de politique abstrait : une série d'identifiants d'AR. Pour valider ce chemin, chaque routeur de politique pourrait mémoriser la sélection complète des chemins de politique acceptables, et exiger qu'un paquet entrant ait un chemin de politique qui corresponde exactement aux entrées mémorisées. Ce degré de contrainte surévalue probablement la situation, et cause une explosion d'informations. À l'autre bout de l'échelle, les routeurs de politique pourraient simplement être sensibles à l'AR de source et à l'AR de destination. Dans certains cas, en particulier en ce qui concerne la facturation, cela ne fournit pas des contraintes suffisantes. La présente proposition suggère que pour décider si un chemin de politique est valide, un routeur de politique devrait regarder les AR de source et de destination, et aussi les AR aboutissant immédiatement à l'AR en question, appelés les AR d'entrée et de sortie.

 

On peut penser les informations de vérification dans le routeur de politique comme un certain nombre de gabarits. Chaque gabarit est associé à un ensemble valide d'utilisateurs, comme décrit par l'adresse d'hôte de source et de destination et la classe d'utilisateur facultative, et contient les quatre AR décrits ci-dessus, source, destination, sortie, et entrée. Un paquet entrant devrait être transmis si, et seulement si, il y a un gabarit qui correspond aux informations contenues dans le paquet. Ces gabarits seront appelés les termes de politique.

 

4.3   Conditions

 

Les termes de politiques, tels qu'ils sont décrits jusqu'ici, ne permettent pas l'expression d'une gamme réaliste de politiques. Ce dont on a besoin est la capacité d'attacher un certain nombre de conditions à des termes de politique qui décrivent les circonstances dans lesquelles les termes sont valides. Cela peut inclure le type de service (TOS) disponible, les plages horaires de validité des termes, les options de comptabilité qui sont valides, et ainsi de suite. Une condition sur l'heure de la journée, par exemple, permettrait aux réseaux, comme les systèmes en temps partagé, d'offrir leurs capacités d'heures creuse à une plus large clientèle.

 

En général, ces conditions peuvent être assez arbitraires. La contrainte importante sur ces conditions est que toute condition imposée par le routeur de politique doit être comprise du point d'extrémité, de façon qu'il puisse générer des chemins de politique qui se conforment à la condition. Si ce n'est pas le cas, et si le routeur de politique attache des conditions fantaisistes à ses termes de politique, les points d'extrémité vont construire de bonne foi des chemins de politique qui seront rejetés, ce qui conduira à l'échec de l'obtention du service et à une sérieuse insatisfaction des usagers. Pour cette raison, il est nécessaire que la nature des conditions de politique soit négociée à l'avance.

 

Les conditions les plus intéressantes et les plus difficiles sont celles qui se rapportent à l'état dynamique du réseau. Un excellent exemple est un accord bilatéral d'assistance mutuelle entre deux AR de transit dans lequel chacune s'accorde pour porter la charge de l'autre en cas de défaillance. Pour formaliser cet accord, chacune peut souhaiter le mettre dans les termes de politique avec la condition qu'il n'est valide que si l'autre AR n'est pas en état de fonctionnement. Dans l'exposé précédent sur la synthèse du chemin de politique, il était nécessaire que les AR fassent fonctionner un protocole descendant global pour décrire l'état de connexité des AR. Ce protocole est suffisant pour permettre au routeur de politique de savoir que quelque autre AR n'est pas en état de fonctionnement, mais il faut faire attention dans la dynamique de ce système à s'assurer que le point d'extrémité du PR a une vision cohérente de l'état des choses vers l'aval. Autrement, il peut y avoir des interruptions de service transitoires, ce qui encore une fois conduit à l'insatisfaction de l'usager.

 

En général, la présente proposition fait valoir que les politiques ne devraient pas se fonder sur des phénomènes très dynamiques. Les régions administratives devraient être vues comme des entités stables qui ne changent pas rapidement d'état. Des caractéristiques hautement dynamiques comme la longueur d'une file d'attente devraient être traitées par des moyens d'ingénierie appropriés internes à l'AR. C'est précisément parce que les conditions doivent être diffusées de façon globale que tenter de fonder une condition sur un paramètre hautement dynamique est susceptible de mener à un système instable.

 

4.4   Propriété des routeurs de politique

 

À la Section 1, toutes les ressources du réseau ont été décrites comme étant partagées entre les AR. Cette assertion ne s'étend pas aux routeurs de politique qui se tiennent sur les frontières entre les AR. Soit le routeur de politique est composé de deux moitiés physiques, soit il y a un accord commun sur la propriété et le fonctionnement du routeur. Ceci fera l'objet d'études ultérieures.

 

5.   Exemples de termes de politique

 

Cette section présente des exemples de la façon dont des termes de politique seraient formulés pour exprimer une gamme de politiques pratiques. Afin de donner des exemples, il sera nécessaire de définir une notation des termes de politique. Ce qui suit n'est pas nécessairement la forme la plus compacte, mais ce sera suffisant pour quelques exemples simples.

 

Un terme de politique sera exprimé comme suit :

 

((Hs,ARs,ARent),(Hd,ARd,ARexit),UCI,Cg)

 

où : Hs est l'adresse de l'hôte de source, ARs est l'AR de source, ARent est l'AR d'entrée, et ces trois valeurs comprennent le premier "élément" du terme, qui décrit l'accès permis à l'égard de la source. De même pour la destination, il y a un élément qui décrit l'adresse de l'hôte, l'AR adjacente, et l'AR finale.

 

En plus des deux éléments directionnels du terme, il y a des informations globales : UCI est l'identifiant de classe d'utilisateur, et Cg est toute condition globale.

 

Dans de nombreux cas, un élément ne voudra pas mettre de contrainte sur une des valeurs, et il utilisera le symbole "*" pour indiquer une correspondance de caractère générique ("wild-card").

 

Pour construire quelques exemples simples, voici une topologie, où les éléments H sont des hôtes, les éléments G sont des routeurs de politique et les éléments numérotés sont des AR.

 

H1 --- AR1 --- G1 ----- AR2 ---- G2 ----- AR3 ----- H2

        |                                  |

        |                                  |

        |                                  |

        |---- G3 ----- AR4 ------ G4 ------|----- G5 --- AR5

                        |                                 |

                        |                                 |

                        |                                H4

                        H3

 

Dans cette figure, nous avons quatre hôtes, cinq routeurs, et cinq régions administratives.

 

Considérons d'abord l'AR 2. Elle n'a pas d'hôte rattaché, et représente un service de transit, comme le réseau NSF. Elle peut avoir une politique très simple : elle va porter tout trafic entre les universités, sans autre contrainte. Si nous disons que AR1 et AR3 sont les régions de deux universités particulières, son terme de politique pourrait être rédigé comme suit :

 

AR2: ((*,1,*),(*,3,*),*,*).

 

Cela dit que AR 2 est d'accord pour porter du trafic provenant de AR 1 pour AR 3, sans considération de l'AR d'entrée et de sortie, et pour tout hôte dans ces AR.

 

Cette notation fonctionne, mais est très rudimentaire, car un nouveau terme est nécessaire pour chaque paire d'universités. Il y a plusieurs façons de compacter la notation. D'abord, on peut utiliser le * et un nouveau symbole, "-", pour élargir un peu les termes. Par exemple :

 

AR2: ((*,1,*),(*,*,-),*,*)

 

affirmerait que AR1 peut utiliser AR2 pour s'adresser à toute AR directement rattachée, et on utilise le "-" pour signifier que l'AR de sortie doit être l'AR de destination. En d'autres termes, l'AR de destination doit être directement rattachée à AR2. Si AR2 ne se rattache qu'aux universités, cela fournira la contrainte appropriée.

 

Une autre approche est d'utiliser l'identifiant de classe d'utilisateur :

 

AR2:((*,*,*),(*,*,*),University,*)

 

dit que tout trafic quel qu'il soit qui a la classe d'utilisateur de University est acceptable.

 

Une autre notation, peut-être plus convenable, permet d'observer que la distinction entre source et destination est en fait artificielle. Bien qu'elle aide, dans ce mémoire, à avoir des noms pour les deux extrémités, chacune d'elles peut être une source, selon celui qui envoie le premier paquet. (Un paragraphe ultérieur explore la nature bidirectionnelle des PR). Une forme plus générale de PR est celle qui permet un nombre quelconque d'éléments. C'est-à-dire que les termes de politique peuvent avoir plus de deux éléments, et cela signifie qu'un PR est valide si il utilise deux quelconques d'entre eux.

 

Par exemple, si l'université 5 veut utiliser le service de AR2, AR2 peut écrire un terme de politique comme suit :

 

AR2:((*,1,*),(*,3,*),(*,5,*),*,*)

 

ce qui permettrait un chemin de politique entre des hôtes dans toute paire dans les AR 1, 3 et 5.

 

Tous les termes mentionnés jusqu'ici se rapportent aux politiques de AR2. Si l'université 1 veut souscrire à ce service, et l'utiliser pour atteindre un autre site, elle spécifiera des termes à elle. Par exemple :

 

AR1: ((*,1, -),(*,*,2),*,*).

 

Ces termes disent que tout hôte dans AR1 peut utiliser AR2 comme chemin vers tout hôte dans toute AR. On utilise encore une fois la notation "-" pour indiquer que l'AR d'entrée est la même que l'AR de source, qui dans ce cas est l'AR qui écrit les termes.

 

Les AR numérotées 3 et 5 sont plus intéressantes. Alors que AR3 est directement rattachée à AR2, AR5 ne l'est pas. Au lieu de cela, AR5 est rattachée à AR3. Si AR3 veut utiliser AR2 pour un service général de transit, elle doit fournir des termes similaires à ceux fournis par 1 :

 

AR3: ((*,3,-),(*,*,2),*,*).

 

Si AR5 veut utiliser AR2, des termes supplémentaires sont nécessaires. Comme AR2 n'est pas directement rattachée, elle ne peut pas être désignée comme AR de sortie dans des termes écrits par AR5. L'AR directement rattachée, AR3, est tout ce qui peut être désigné.

 

AR5: ((*,5,-),(*,*,3),*,*).

 

Alors AR3 doit accepter de porter le trafic de transit pour AR5.

 

AR3: ((*,5,-),(*,*,2),*,*)

 

AR3 peut ne pas vouloir porter toutes les formes de trafic de transit pour AR5, mais seulement pour certaines sortes ou pour certaines localisations. Cela pourrait être exprimé par des restrictions aux termes précédents. Par exemple,

 

AR3: ((*,5,-),(*,2,-),*,*)

 

permettrait au trafic provenant de AR5 de traverser AR3 pour atteindre AR2, mais seulement pour les hôtes qui sont directement dans ces AR.

 

Voici quelques autres exemples : considérons AR4, qui pourrait représenter l'AR d'un utilisateur commercial. Elle connecte les hôtes de cet utilisateur, par exemple, H3, et est connectée à l'autre environnement pour permettre l'intercommunication. Étant donné ce qui précède, aucun trafic ne va s'écouler dans cette AR.

 

Si AR1 veut permettre la communication avec AR4, elle pourrait ajouter :

 

AR1: ((*,1,-),(*,4,-),*,*)

 

Cela permettrait la communication directement entre les hôtes dans chaque AR, mais pas le trafic de transit. En particulier, H3 et H2 ne peuvent pas se parler. Il y a plusieurs termes différents qui leur permettraient de se parler.

 

Le chemin direct serait le suivant :

 

AR4: ((*,4,-),(H2,3,-),*,*)

AR3: ((*,3,-),(H3,4,-),*,*).

 

Cela permettrait la connexion directe à travers G4. Noter, en passant, que chaque terme a été établi de telle sorte que tout hôte dans l'AR locale puisse correspondre, mais seulement un hôte dans l'autre AR. Cette combinaison se trouve ne permettre qu'à H3 et H2 de communiquer.

 

Si G4 n'était pas là, un autre chemin serait via AR2, qui pourrait être permis par des termes convenables dans les AR1, 2, 3 et 4.

 

Même si G3 et G4 existent, aucun trafic de transit ne va s'écouler à travers AR4 de 1 à 3. Même si 1 et 3 le veulent :

 

AR1: ((*,1,-),(*,3,4),*,*) et

AR3: ((*,3,-),(*,1,4),*,*),

 

l'absence d'un terme pour AR4 empêchera un PR valide via ce chemin. Seulement si AR4 ajoutait :

 

AR4:((*,1,-),(*,3,-),*,*)

 

AR4 commencerait à fournir à l'AR un chemin de transit de 1 à 3.

 

Si AR4 ajoutait :

 

AR4: ((*,4,-),(*,*,*),*,*), tout hôte dans AR4 pourrait parler à tout hôte n'importe où ailleurs mais AR4 ne pourrait toujours pas devenir un service de transit.

 

Ces divers exemples démontrent comment les AR individuelles peuvent offrir des termes de politique qui peuvent être combinés pour former un chemin. La notation proposée ici n'est probablement pas adéquate pour exprimer la gamme des politiques nécessaires. Par exemple, il peut être souhaitable d'avoir des listes d'AR au titre d'un terme, ainsi que des valeurs seules et "*". Une autre notation pourrait être proposée pour permettre l'exclusion d'un ensemble limité d'AR. Il peut aussi être approprié d'écrire des éléments qui sont directionnels, de sorte que les connexions puissent être "ouvertes" dans une direction mais pas dans les autres. Cette idée est vague dans une architecture sans connexion, mais semble se rapporter à des exigences de politique réelles.

 

En général, le problème de l'expression des termes de politique en forme compacte est le même que celui de construire des listes de contrôle d'accès compactes. Il y a encore une discussion en cours pour savoir si les listes de contrôle d'accès devraient être ordonnées, et devraient permettre l'exclusion, et ainsi de suite. Il semblerait qu'exactement les mêmes questions vont se poser ici. Il faudra avoir un peu plus d'expérience de tentatives d'expressions de politiques réelles pour avoir des lignes directrices sur la puissance d'expression nécessaire.

 

6.   Recouvrement des coûts

 

Presque tout l'Internet existant a été payé comme un investissement en capital et fourni gratuitement aux utilisateurs. Il y a des exemples limités de couverture des coûts, mais ils sont fondés sur une cotisation annuelle plutôt que sur un prix en rapport avec l'utilisation. Il y a un courant d'opinion croissant pour dire que la comptabilité de l'utilisation, sinon sa facturation, est un composant important d'une gestion de ressource efficace. Pour cette raison, les outils de comptabilité et de facturation doivent être un élément central de tout mécanisme de politique. Cependant, précisément à cause de l'autonomie des régions administratives, on ne peut pas imposer une forme unique de politique de facturation à toutes les régions. Certaines d'entre elles peuvent continuer à fournir gratuitement le service, ou à le fournir sur la base d'un abonnement annuel. D'autres peuvent facturer sur la base des ressources consommées, mais même là, il peut y avoir des variations de détail, car certaines peuvent facturer le paquet et d'autres l'octet. Encore une fois, comme dans l'analogie avec le téléphone, on voit la diversité des politiques de facturation, avec des fournisseurs de service aussi bien locaux que longue distance qui vendent leur service soit sur la base d'un abonnement mensuel, soit pour une utilisation à la minute, avec des conditions différentes selon l'heure. Le problème de la facturation est donc très compliqué, car l'usager va vraisemblablement vouloir minimiser le coût, dans le contexte des diverses conditions disponibles.

 

S'il faut réellement payer pour l'utilisation des services, il y a aussi le problème du règlement. Si on utilise le système téléphonique actuel comme exemple, il y a deux stratégies pour percevoir les recettes. L'une est le mode de pré-déssaisissement, dans lequel l'AR source (ou l'AR de destination dans le cas d'un PCV) sert de point de collecte unique pour toutes les AR impliquées dans l'appel. Après le dessaisissement nous voyons un autre paradigme, dans lequel l'AR de transit facture séparément le consommateur.

 

Il y a de nombreuses raisons pour prendre en charge les deux formats de collecte. La principale raison pour une facturation séparée est que toutes les régions ne souhaitent pas facturer l'utilisateur dans les mêmes unités monétaires. Certaines régions peuvent souhaiter facturer en dollars, alors que d'autres peuvent souhaiter facturer en utilisant certaines formes d'unités d'allocation privées. D'un autre côté, avoir un seul point de collecte est très pratique, parce que cela élimine une certaine duplication d'efforts de collecte. Cela exige cependant un haut niveau de confiance et de coordination parmi les AR.

 

Le point de collecte unique simplifie aussi un autre problème connexe, celui des paquets perdus. Pour la plupart des types de service, l'usager serait vraisemblablement choqué qu'on lui demande de payer pour un nombre significatif de paquets non livrés parce qu'ils ont été perdus avant d'atteindre leur destination. Si chaque région facture séparément son trafic, pour éviter alors de facturer les paquets perdus entre cette AR et la destination, il est nécessaire d'avoir une forme de rapport sur les paquets perdus, qui voyage en sens inverse avec un système qui décrémente les compteurs de toutes les AR intervenant. Si on effectue le point de collecte unique, la métrique de l'usage peut être mise dans l'AR de destination, et diffusée périodiquement à l'AR de facturation, si elle est dans une région différente.

 

La discussion sur les paquets perdus fait une relation claire et importante entre facturation et politique. Si une politique d'acheminement fait passer des paquets à travers une région de non fiabilité connue, les régions qui la précèdent sur le chemin peuvent être assez réticentes à effacer les charges pour des paquets qui ont bien traversé leur région, pour être tout simplement perdus plus loin sur la route. Une politique de facturation est un moyen d'affirmer qu'une région souhaite se séparer elle-même de la fiabilité du comportement d'une autre région. Les conditions dans les termes de politique, et les chemins de politique correspondants, doivent donc être capables de saisir deux conditions distinctes. La première est s'il existe ou non un accord bilatéral entre deux AR, par lequel l'une accepte d'être l'agent collecteur pour l'autre. L'enchaînement d'un certain nombre de ces accords permet d'utiliser un point de collecte unique pour le chemin de politique tout entier. L'autre condition est de savoir si l'AR va accepter les comptes de paquets et d'octets de la prochaine AR en aval, comme base de la facturation, ou si l'AR insiste pour que la facturation soit fondée sur les comptes au point de sortie de cette AR. Cette condition permet à une AR de construire un mur entre elle et une AR suivante non fiable. On peut imaginer que certaines régions soient d'accord pour porter du trafic dans des régions non fiables, mais seulement avec parcimonie, sachant que le résultat va être la frustration de l'usager qui peut être dirigé sans discrimination sur toutes les AR. L'utilisation d'une condition de politique spécifique peut rendre clair à l'utilisateur final quelles AR ne se perçoivent pas elles-mêmes comme interfonctionnant harmonieusement.

 

Pour mettre ces mécanismes en application, le PR abstrait qui est inclus dans le paquet doit être augmenté d'un certain nombre de conditions. D'abord, pour chaque AR, il y a un fanion à trois positions qui décrit si la facturation devrait être collectée séparément pour la région, propagée en retour à la source (ce qui correspond au paradigme de la compagnie téléphonique normale), ou propagée vers la destination (ce qui correspond à un PCV). Ensuite, il y a un fanion qui indique si la région est supposée accepter de la prochaine région en aval les comptes de paquets et d'octets comme base de la facturation. Enfin, il doit y avoir un code de charge, un nombre unique ressemblant un peu à un numéro de carte de crédit auquel les factures peuvent être envoyées. Les termes de politique dans les routeurs doivent de même être augmentés pour permettre la vérification. La gestion du code de charge, s'assurer de son caractère univoque, et empêcher sa falsification sont exposés plus loin.

 

Ces conditions, qui se rapportent aux accords entre deux AR, sont assez différents des conditions exposées précédemment, telles que celles de l'heure d'utilisation. Les conditions qui se rapportent aux accords d'AR seront appelées "conditions bilatérales", alors que les autres sont appelées "conditions globales". Noter que quand bien même les conditions bilatérales se rapportent à l'accord entre deux AR, elles peuvent avoir des effets globaux.

 

7.   Choix de routeur

 

Dans la Section 2, le présent mémoire proposait que le point d'extrémité devrait spécifier un chemin de politique abstrait, comme une série d'AR, et que le routeur de politique à l'entrée de chaque AR devrait convertir le prochain bond en un chemin concret, en choisissant le routeur de politique pour sortir de cette région pour entrer dans la suivante. Il apparaît que ce choix n'est pas entièrement dépourvu de préoccupations de politique, et quelques conditions supplémentaires sont nécessaires dans les termes de politique pour faire fonctionner cela correctement.

 

Afin que chaque routeur de politique soit capable de choisir le prochain routeur de politique sur le chemin, il est nécessaire d'avoir un tableau qui fasse la liste de tous les routeurs de politique potentiels qui connectent ensemble les régions adjacentes. Vraisemblablement, ces informations vont changer très lentement, et il n'est pas difficile de les diffuser. Les informations les plus dynamiques qui sont nécessaires sont celles qui se rapportent à l'activité de chacun de ces routeurs. Il est donc nécessaire que tous les routeurs de politique rattachés à une AR donnée aient un algorithme local d'activité/non activité, qui puisse heureusement déterminer non seulement que chacun des autres routeurs est actif, mais que ses interfaces sont actives et qu'elles transmettent correctement le trafic. Il est assez compliqué de concevoir un tel essai. Cependant, nous n'avons pas à concevoir une stratégie pour la propagation mondiale de ces informations, parce qu'elles ne sont nécessaires que pour les autres routeurs de politique rattachés à chaque région.

 

Des problèmes de politiques en rapport avec les chemins concrets surviennent si il y a plusieurs routeurs qui connectent deux régions administratives. Comme décrit jusqu'à présent, le routeur de politique de sortie de toute région (qui est le routeur de politique d'entrée pour la région suivante) est choisi par le routeur de politique d'entrée pour cette région. En d'autres termes, chaque région peut choisir son routeur de sortie, mais n'a pas de contrôle sur son routeur d'entrée. Il y a certaines circonstances dans lesquelles une région particulière peut insister pour avoir le contrôle sur le routeur d'entrée utilisé. Imaginons deux régions de transit parallèles, une qui fait une tarification incrémentaire du service, et l'autre qui fournit son service gratuitement. Évidemment, du point de vue de l'utilisateur, il est préférable de minimiser l'utilisation de l'AR qui taxe, et de maximiser l'utilisation de l'AR gratuite. Mais cela peut conduire à une surcharge brute de l'AR gratuite, et une discrimination apparente à l'encontre de l'AR qui taxe. Le propriétaire de l'AR gratuite, pourrait donc choisir d'imposer une politique qui pourrait dire qu'elle peut seulement être utilisée pour atteindre certains points qui ne sont pas directement connectés à l'AR qui taxe pour ses services, et que le trafic doit entrer dans l'AR gratuite au point le plus proche de la destination. En d'autres termes, l'AR gratuite exige qu'il lui soit permis de choisir son routeur d'entrée de façon à minimiser ses coûts (qui ne sont, en fait, pas facturés), avec l'intention de faire glisser autant que possible les coûts sur l'autre réseau.

 

En ajoutant plus de conditions bilatérales des termes de politique et d'acheminement de politique dans le paquet, il est possible de contrôler les diverses options du choix de routeur de politique. À chaque frontière entre les AR, il y a seulement un nombre limité de façons de choisir le routeur de politique. Soit il est choisi par le côté d'entrée, soit par le côté de sortie, soit par quelque algorithme de collaboration spécifié par accord bilatéral. (Il peut y avoir plusieurs algorithmes de cette sorte, qui exigent la possibilité de plus de complexité dans la spécification. En particulier, si deux AR adjacentes se sont mises d'accord pour utiliser une métrique d'acheminement commune pour certains types de service, elles peuvent être d'accord pour faire un acheminement commun sur la base de cette métrique.)

 

Permettre que le routeur de politique soit choisi par l'AR qui est du côté éloigné du routeur représente un problème de mise en œuvre intéressant. Il serait possible d'envoyer un message en avant du paquet, ce qui demande que la prochaine AR choisisse son routeur d'entrée. Pour ce faire, elle devrait imaginer quel routeur de sortie ce serait, puis imaginer rétrospectivement ce qui minimise ses coûts (par exemple) pour choisir le routeur d'entrée potentiel de retour dans sa propre région. Ceci est compliqué à décrire, et serait probablement compliqué à mettre en œuvre. Une façon de focaliser le problème est d'observer que les chemins sont bidirectionnels, parce qu'un flux de paquets est bidirectionnel, et il est très souhaitable que les paquets provenant des deux directions suivent le même chemin. Une fois qu'un paquet est revenu sur le chemin inverse, le routeur duquel il est sorti est précisément le routeur qui devrait être utilisé pour le trafic futur dans l'autre direction. Mais chaque routeur dans la direction amont ou aval doit se souvenir de la décision prise par une autre AR.

 

Pour que cela fonctionne il est nécessaire que les routeur ne soient pas sans états. Si chaque routeur de politique maintient une mémoire cache (antémémoire) des chemins de politique récemment calculés, en se souvenant en particulier du résultat du calcul du routeur pour chaque chemin abstrait, en déterminant simplement si la direction vers l'aval ou si la direction inverse est autorisée pour obliger le routeur à travers cette frontière, les deux politiques peuvent être mises en application. Mais cela exige la construction de routeurs à états, ce qui n'a pas été culturellement acceptable dans l'Internet. On considère donc comme un sujet à part les vertus des états dans les routeurs de politique. Il est estimé qu'il existe des algorithmes très simples pour établir les liens exigés des routeurs de politique, mais ce problème fera l'objet d'études ultérieures.

 

8.   États des flux

 

La section précédente suggérait que le routeur a besoin de conserver son état afin de lier ensemble les moitiés vers l'amont et vers l'aval d'un flux. Cela résolvait le problème particulier de lier ensemble les décisions d'acheminement prises dans chaque direction, de façon que chacune puisse être utilisée dans l'autre. Il y a en fait un certain nombre de raisons pour lesquelles les deux moitiés du flux devraient être liées.

 

-   Il y a une redondance considérable pour la comptabilité et le recouvrement concernant l'usage. Il est clairement souhaitable que les deux moitiés du flux soient mesurées conjointement.

 

-   Si le chemin n'est pas bidirectionnel, une défaillance dans le nœud produit une liaison unidirectionnelle. Les liaisons unidirectionnelles sont réputées causer des comportements anormaux dans les protocoles.

 

-   Au titre de la gestion de ressource, il peut être souhaitable que les nœuds intermédiaires repassent les informations de contrôle de flux à la source du flux. Si des paquets identifiables de la direction inverse passent à travers le routeur, ces informations peuvent alors être portées sur ces paquets.

 

Un avantage supplémentaire de la conservation de l'état dans le routeur est qu'elle réduit considérablement la redondance du traitement des paquets entrants. Il y a un certain nombre de décisions que doit prendre le routeur de politique qui font partie de la transmission d'un paquet : il doit valider le chemin de politique par rapport à ses termes de politique, il doit créer ou modifier un enregistrement de comptabilité, et il doit choisir le prochain routeur de politique. Il serait déraisonnable d'imaginer d'effectuer ces tâches à partir de rien pour chaque paquet entrant. Une fois que ces décisions sont prises, les résultats devraient être placés en antémémoire, de façon qu'ils puissent être utilisés pour les paquets suivants.

 

Le routeur sans état a été proposé au titre de la conception de l'Internet afin d'assurer la robustesse de l'architecture. Si le routeur n'a pas d'état, une défaillance d'un routeur ne peut pas mettre en danger la connexion en cours. Si il y a un état dans un routeur, et si les informations d'état sont perdues à cause d'une défaillance, il est alors possible qu'un flux soit interrompu.

 

En passant d'un routeur sans état à un routeur qui met les informations en antémémoire, il est nécessaire de s'assurer que les informations en antémémoire peuvent être perdues et reconstruites. L'idée de ne garder dans les routeurs que les états qui peuvent être facilement reconstruits est appelée "état conditionnel" (soft state).

 

9.   Synthèse et choix des chemins de politique

 

Dans cette proposition, un paquet contient un chemin de politique, qui est vérifié par chaque routeur de politique le long de ce chemin. La présente section expose la façon dont est créé un chemin de politique pour la première fois.

 

La création de PR ne peut pas être faite de façon totalement automatique par le système, mais va en général exiger un jugement humain. Les politiques sont après tout, des affaires qui concernent les hommes. L'approche de la création de PR est donc une affaire conjointe, dans laquelle le système fournit le support aux personnes qui établissent la politique.

 

Le plus couramment, le PR désiré sera choisi parmi ceux disponibles en trouvant d'abord tous les PR valides, puis en en prenant un qui satisfait aux exigences de l'utilisateur et a le plus faible coût réel. Ces deux étapes seront appelées synthèse et sélection.

 

Pour synthétiser un PR à travers une séquence d'AR, on doit trouver un terme de politique dans chaque AR qui permette un tel PR. Les termes de politique dans chaque AR adjacente doivent être compatibles dans leurs conditions de facturation et leurs autres particularités. On peut imaginer de trouver une séquence de termes de politique qui corresponde, un peu comme aux dominos, et aller de la source à la destination.

 

Pour qu'un terme de politique sur une AR soit acceptable au titre d'un PR, ce qui suit doit être vrai :

-   l'adresse de source et de destination de l'hôte et l'UCI doivent satisfaire le terme,

-   l'AR de source et de destination doivent satisfaire le terme,

-   l'AR d'entrée et de sortie doivent satisfaire à l'AR adjacente sur le chemin,

-   les conditions dans le terme qui se rapportent à l'AR adjacente (par exemple, facturation) doivent satisfaire aux conditions du terme provenant de cette région.

Bien sûr, ces conditions sont exactement ce que le routeur de politique va tester en validant le PR lors de son utilisation.

 

Comme le chemin est synthétisé à partir des termes correspondants, les conditions globales de chaque terme sont notées, et leurs combinaisons deviennent la condition selon laquelle le PR est valide. Comme point de départ de la synthèse, l'usager peut avoir indiqué des contraintes sur les conditions acceptables afin de limiter les termes candidats dans la synthèse.

Le résultat de la synthèse de PR, qui est assez similaire au calcul d'un algorithme d'acheminement par état de liaison dans lequel chaque terme de politique représente une liaison abstraite, est une liste qui peut être longue des PR possibles pour chaque AR de destination, chacun avec des conditions rattachées. Le processus de sélection doit identifier une de celles qui doit en fait être utilisée. La sélection peut être fondée sur les conditions, et sur le coût de chaque PR.

 

Pour déterminer le coût, il doit être possible de demander à chaque AR d'identifier le coût d'utilisation de ce terme de politique dans le contexte de cet ensemble particulier d'AR d'entrée et de sortie. Il doit soit y avoir un protocole dont l'architecture permet de faire rapport de ces coûts, soit la tâche de détermination des coûts doit être laissée à des personnes qui l'effectuent en-dehors du système. Le problème avec le rapport des coûts intégré à l'architecture est qu'alors que certaines AR peuvent facturer à l'aide de dollars réels, d'autres peuvent facturer en termes d'autorisations d'utilisation abstraites qui n'ont aucune signification en dehors de cette AR. Même ainsi, on pense qu'on devrait essayer de définir une représentation pour faire rapport de la base de facturation associée à chaque AR. Ce sujet sera étudié ultérieurement.

 

Alors que la synthèse de PR peut être un processus automatisé, la sélection ne l'est probablement pas. Alors que la minimisation des coûts va aider à élaguer la liste, et que certains chemins peuvent être rejetés automatiquement sur la base des conditions, une partie de la sélection va en général requérir un jugement humain. Cette observation, avec l'observation que la synthèse de PR peut être coûteuse, suggère d'abord que synthèse et sélection ne peuvent pas être faites pour chaque paquet ou bien sûr chaque fois qu'une connexion de transport est établie, et ensuite qu'elles ne devraient pas être faîtes séparément pour chaque hôte dans l'AR.

 

Au lieu de cela, chaque AR devrait avoir un (ou plusieurs) serveurs de politique, à l'intérieur de l'AR qui prend en charge la gestion de ces PR. Le serveur de politique effectuerait un certain nombre de fonctions.

 

-   Il devrait mémoriser les termes de politique pour l'AR, et les rendre disponibles au routeur de politique et aux serveur des autres AR en tant que de besoin.

-   Il devrait synthétiser les PR potentiels pour atteindre les autres AR, et se souvenir de ceux dont l'utilisation a été choisie.

-   Il devrait répondre aux demandes de PR des hôtes de l'AR, et les leur retourner de sorte qu'ils puissent être inclus dans les paquets sortants.

-   Il va participer au nom de l'AR aux protocoles d'activation/désactivation d'AR, et aux autres algorithmes d'acheminement inter-AR.

-   Il va se souvenir de la localisation de tous les routeurs de politique rattachés à cette AR.

-   Il va fournir l'interface de gestion pour les personnes qui doivent établir la politique de l'AR : réglage des termes de politique locale, sélection des chemins de politique, et ainsi de suite.

 

Un hôte qui souhaite envoyer des paquets en dehors de l'AR locale doit d'abord obtenir un PR à mettre dans les paquets. Dans le cas normal, il le ferait en dirigeant une demande sur le serveur de politique local, fournissant la destination désirée et les autres conditions négociables. (Par exemple, le TOS est négociable, l'heure en cours ne l'est pas.) Le serveur, sur la base de cette entrée, doit choisir le PR le plus approprié et le retourner.

 

À ce moment du processus, l'intervention humaine n'est pas envisageable, car elle prendrait trop longtemps. Maintenant, une sélection suffisante doit avoir été faite de telle sorte que la sélection automatique du PR soit possible. La mise en œuvre la plus directe est que le processus de sélection manuelle devrait donner une liste ordonnée (ou partiellement ordonnée) de PR potentiels, et la liste est parcourue dans l'ordre jusqu'à trouver un PR qui corresponde à la destination et aux conditions. Ce PR est alors retourné.

 

10.   Sécurité

 

Il y a un certain nombre d'aspects de ce schéma qui présentent des opportunités d'agression. Dans presque tous les cas, l'agression possible est le vol de ressources réseau ou la facturation incorrecte. Elles ont donc une nature quelque peu différente des problèmes qui se rapportent à la corruption ou la divulgation de données. Les mécanismes pour assurer une utilisation et une facturation correcte des ressources tolèrent souvent des abus mineurs en échange de la facilité d'utilisation. Aussi, le contrôle est souvent fondé sur la détection et la récupération plutôt que sur la prévention. Des hypothèses de cette sorte sont probablement acceptable ici aussi. Un paquet isolé, qui ne fait pas partie d'une séquence de paquets, peut être un élément trop petit pour que le contrôle le prenne en compte. Mais si un flux de paquets significatif passe au travers de la facturation, ceci est moins acceptable.

 

Il y a trois options générales pour les abus. Une est de falsifier les informations d'identification de l'utilisateur dans le PR, l'hôte de source et de destination, l'identifiant de classe d'utilisateur et le code de facturation. Une autre est de prendre un PR valide et de l'utiliser intact à de mauvaises fins. Et la troisième est de lire un code de tarification valide sur un PR et de faire des facturations supplémentaires contre lui.

 

Pour se protéger contre le placement de fausses informations d'identification de l'utilisateur dans un PR, les PR devraient être scellés ou signés, en utilisant une technique de scellement chiffré. Comme les serveurs de politique sont la source des PR, le scellement peut être fait par le serveur. Cela exigerait que le sceau ou la signature numérique de chaque serveur soit connu mais éviterait d'avoir à connaître chaque hôte. Le serveur serait réputé ne sceller que les PR valides. Il ne doit mettre que les identifiants de classe d'utilisateur et les codes de tarification dans les PR, par exemple, à partir d'une source autorisée à les utiliser.

En supposant un système de clé publique, chaque serveur de politique pourrait avoir une paire de clés distincte, dont la moitié publique est publiée d'une façon ou d'une autre. Savoir exactement quelles parties du PR doivent être scellées sera étudié ultérieurement.

 

Si le serveur de politique viole cette confiance, et utilise un UCI ou code de tarification avec un hôte non autorisé, il y a deux sous-cas : l'hôte de la fausse source est dans la même AR, ou est en dehors. Si il est en dehors, cela peut être détecté par inspection du PR, car la relation entre l'AR et le numéro de réseau est (presque) statique. Une approche possible est que l'identifiant d'AR fasse partie du code de tarification de sorte que l'utilisation du code puisse être rejetée sauf si cette AR est l'AR de source du paquet. Cela fonctionne, mais empêche d'utiliser des codes de tarification à partir d'une localisation étrangère. D'autres techniques plus générales pourraient probablement être proposées.

 

Si le faux hôte de source est à l'intérieur de l'AR, d'autres étapes sont nécessaires pour prévenir le problème. Une solution générale est de noter qu'un PR n'est valide que si il est scellé par une serveur de politique. Toute AR tentant de percevoir pour une utilisation devrait être obligée de garder une copie du PR comme preuve de l'utilisation du chemin. Si il semble y avoir une utilisation non autorisée d'un code de facturation, le propriétaire peut demander à voir le PR qui a généré la facture, qui va montrer le serveur de politique qui a construit le chemin. Si c'est un usage non autorisé, une action peut être entreprise contre l'AR qui possède ce serveur, avec le PR scellé comme preuve. En d'autres termes, la détection et le redressement peuvent être plus efficace que la prévention.

 

Si on peut supposer que le serveur de politique pour une région particulière est autant de confiance que l'exige l'AR, il reste encore le problème d'un serveur d'une région qui essaye de voler dans une autre AR. Cela pourrait se faire, par exemple, en prenant un PR valide, et en envoyant des transmissions de données sur celui-ci à partir du "milieu" du chemin, de sorte que ce qui apparaît comme venant d'une source viendrait en réalité d'une source différente dans une AR différente.

 

Cela exigerait que les paquets qui reviennent le long du chemin vers la source d'origine soient réacheminés sur la fausse source, ce qui voudrait dire que toute la fonction d'acheminement au sein de l'AR est corrompue. Il est peu vraisemblable que cela dure longtemps sans détection, mais si un contrôle direct de cette classe de fraude est nécessaire, il pourrait être réalisé en exigeant que toute AR qui a l'intention de facturer un PR particulier obtienne de temps en temps une confirmation, scellée par le serveur de l'AR de source, que son routeur de politique a bien en fait transmis un certain nombre de paquets utilisant ce PR. Cette sorte de fonction est probablement superfétatoire, mais cette classe de fraude doit être prise en compte.

 

Évidemment, une étude plus détaillée du problème du vol de ressource sera nécessaire, mais on pense qu'un mécanisme pourrait fonctionner sur la base de :

-   La confiance locale du serveur de politique au sein de chaque AR.

-   Le scellement du PR par le serveur.

-   Une validation sélective du sceau au routeur de politique.

-   Une vérification de cohérence sélective du PR au routeur de politique.

-   L'utilisation du sceau du PR comme preuve de la source du PR.

 

11.   Un programme expérimental -- migration vers l'acheminement de politique

 

La proposition ci-dessus réclame plusieurs composants de l'Internet qui ne sont pas présents aujourd'hui : l'option IP de chemin de politique, les routeurs de politique, les serveurs de politique, et des protocoles de prise en charge tels que le protocole global d'activation/désactivation d'AR et le protocole d'activation/désactivation de routeur de politique local (à l'AR). Tout plan d'introduction d'acheminement de politique doit fournir une méthode d'expérimentation avec le concept sans changer tous les hôtes et les routeurs actuellement en place.

 

Comme le serveur de politique est un nouveau composant qui peut être ajouté à l'Internet sans changer aucun composant existant, il est très aisé de mettre en place cette facilité. Cela devient alors la partie centrale d'un plan expérimental. Plus tard, il sera possible d'imaginer d'ajouter les contrôles de politique à certains des routeurs. Il sera plus difficile de modifier tous les hôtes pour utiliser l'option IP PR. Sur la base de notre expérience d'ajout de caractéristiques mineures telles que les sous-réseaux IP, il ne sera jamais possible d'obtenir l'option PR dans tous les hôtes, et l'acheminement de politique devra devenir fonctionnel de toutes façons.

 

En tenant compte de ces difficultés, voici un plan expérimental concret, en trois phases.

 

Dans la phase I, on crée un logiciel pour un serveur de politique, et on le met à la disposition de toutes les AR potentielles. Au titre de ses fonctions, il aura deux caractéristiques "temporaires", pour imiter la fonction de l'hôte manquant et du routeur de support.

 

Pour imiter la fonction du routeur de politique, deux serveurs de politique sont placés "près" d'un routeur de fonction courante qui se trouve connecter les deux AR, un de chaque côté du routeur actuel, et représentant leur AR respective. Ces deux serveurs procèdent alors à duper le routeur actuelle de la façon suivante :

 

-   On donne au serveur actuel les deux serveurs comme voisins dans les échanges d'acheminement. De cette façon, les serveurs peuvent contrôler quels numéros de réseau sont annoncés. Ceci est similaire à la façon dont "gated" est utilisé aujourd'hui pour contrôler les chemins.

 

-   Un paquet entrant dans l'AR est dirigé vers le serveur "proche" à l'intérieur de l'AR, qui effectue les fonctions du routeur de politique et renvoie ensuite le paquet. Cela peut exiger l'utilisation d'une route de source régulière dans certains cas, mais peut probablement être fait simplement en récrivant l'adresse IP de destination dans le paquet. (Noter que l'option IP PR proposée a des champs pour la source et la destination IP d'origine, de sorte que ces champs peuvent être réutilisés pour la transmission du paquet de routeur à routeur.)

Pour traiter l'absence de prise en charge de l'option PR, nous utiliserons encore une fois le serveur. Comme le serveur est le récepteur de toutes les informations d'acheminement arrivant dans l'AR (car il a été réglé comme voisin du routeur actuel à la frontière réelle de l'AR) il est seul à connaître les chemins de sortie appropriés. En interne, il s'annonce lui-même comme le routeur par défaut à tous les réseaux en dehors de l'AR, de sorte qu'il reçoit tous les paquets destinés à quitter la région. C'est lui, plutôt que l'hôte, qui ajoute l'option PR puis envoie le paquet sur le routeur de politique (ou le serveur correspondant dans la prochaine AR qui joue ce rôle) pour le relayer.

 

En contrôlant comment les chemins sont diffusés par les routeurs réguliers, il est possible d'empêcher les hôtes de régler manuellement les chemins en court-circuitant les serveurs. Dans tous les cas, la mise en application n'est pas le principal sujet de préoccupation de la phase I de l'expérience.

 

Dans la phase II, certains des routeurs actuels sont enrichis des fonctions de routeur de politique. Cela rendra la mise en application plus facile, et éliminera le bond supplémentaire que fait le paquet dans la phase I, car il passait d'un serveur à un autre à travers le routeur actuel. En même temps, certains des hôtes seront modifiés pour insérer l'option IP PR dans le paquet à la source. Cela éclaircira les problèmes de la sélection du PR.

 

Dans la phase III, la mise en œuvre généralisée du concept de PR est proposée.

 

12.   Établissement de chemin de politique

 

Une objection à ce schéma est la grande taille de l'option IP PR. Avec toutes les informations proposées dans le présent mémoire, il est plus grand que l'en-tête IP lui-même. Cependant, ce problème peut être évité facilement car l'option PR a rarement besoin d'être envoyée.

 

Comme le routeur de politique va mettre en antémémoire le résultat du traitement du PR, l'antémémoire détient l'équivalent du PR. Tout ce qui est nécessaire est une très courte option dans le paquet qui serve de bretelle pôur permettre au routeur de trouver l'entrée d'antémémoire correcte. Cette bretelle serait incluse dans l'option IP PR d'origine, puis répétée dans chaque paquet. Le serveur de politique qui a généré le PR pourrait choisir la bretelle, de sorte qu'elle soit unique pour chaque AR. Peut-être que l'identifiant d'AR et un UID de 16 bits seraient suffisant.

 

L'option PR complète ne doit être dans le paquet que si les informations en antémémoire dans le routeur sont perdues. Si un routeur a une défaillance ou si le chemin change, le point d'extrémité doit reconstruire les antémémoires dans la série des routeurs qui forment le chemin. Le point d'extrémité pourrait déterminer que c'est nécessaire soit quand un routeur rapporte explicitement qu'il n'a pas d'entrée correspondant à une bretelle, soit lorsque l'hôte détermine qu'il ne reçoit pas le service désiré.

 

Cette sorte d'action peut être vue comme une extension de l'idée de retransmission. Dans les protocoles de transport tels que TCP, l'hôte garde trace du comportement du réseau, et si il estime que quelque chose ne va pas (par exemple, qu'il y a une absence d'un accusé de réception), il prend des mesures pour restaurer le service désiré. D'autres exemples sont de commuter sur un autre routeur si le routeur adjacent actuellement actif semble avoir une défaillance. L'envoi de l'option PR complète dans le paquet est un autre exemple où on permet au nœud d'extrémité de restaurer l'état de la connexion si elle semble interrompue.

 

En utilisant ce modèle, la plupart des paquets auraient seulement une option courte (peut-être 12 octets).

 

Cette idée de restaurer l'état du routeur en tant que de besoin réalise l'idée d'un "état conditionnel" mentionné plus haut et permet aux routeurs à états d'atteindre à la même robustesse associée aux réseaux à datagrammes.

 

Adresse de l'auteur

 

David D. Clark

Massachusetts Institute of Technology

Laboratory for Computer Science

545 Main Street

Cambridge, MA 02139

téléphone : (617) 253-6003

mél : ddc@LCS.MIT.EDU