Résumé

  • RFC 2210 ne confondait pas les objets transportés par RSVP : le SENDER_TSPEC déclarait le trafic à l’aval, l’ADSPEC résumait le chemin à l’aval, et le FLOWSPEC formulait une demande vers l’amont.
  • Le bit de rupture général indiquait qu’au moins un élément ne prenait pas en charge RSVP et les services intégrés ; dans ce cas, tous les autres paramètres ADSPEC étaient non fiables comme synthèse de bout en bout.
  • Un bit de rupture propre à un service signalait un manque plus précis : un nœud conscient de RSVP ne savait pas fournir ce service particulier.
  • La valeur PATH_MTU était réduite le long du chemin et lors des fusions, sans modifier la taille maximale déclarée à l’origine par l’émetteur.
  • Une publicité propre, une réservation fusionnée ou une borne calculée ne prouvaient ni la stabilité de la route, ni l’admission partout, ni le traitement réellement observé, ni la réussite de l’application.

Un résumé peut échouer sans disparaître

L’ADSPEC n’était pas conçu comme une liste de routeurs.

Dans le modèle One Pass With Advertising, les éléments du réseau mettaient à jour des valeurs composées pendant que le message PATH avançait vers le récepteur. Le volume de l’objet restait ainsi à peu près constant. Le récepteur obtenait une synthèse exploitable sans recevoir l’historique complet de chaque saut.

Cette économie imposait une contrepartie. Si un élément intermédiaire ne pouvait pas contribuer au calcul RSVP/Integrated Services, le résumé ne pouvait plus prétendre représenter tout le chemin. RFC 2210 ne supprimait pas l’objet et ne remplaçait pas tous les champs par zéro. Il faisait porter l’information essentielle par un bit de rupture.

Lorsque ce bit général était positionné, les autres paramètres étaient qualifiés de non fiables. La règle concernait leur portée comme composition de bout en bout. Une valeur locale pouvait avoir été calculée correctement avant la rupture ; une autre pouvait être mise à jour correctement après. Ce qui manquait était la continuité nécessaire pour les lire comme un seul compte rendu du chemin.

Un routeur ultérieur ne pouvait pas effacer cette histoire. Sa propre prise en charge ne transformait pas rétroactivement le nœud absent en participant. Le bit conservait donc la trace d’une limite que le format compact aurait autrement dissimulée.

L’émetteur ne mesurait pas le chemin

Le SENDER_TSPEC appartenait à l’émetteur.

Il décrivait l’enveloppe du trafic susceptible d’être généré, notamment par des paramètres de seau à jetons et une taille maximale de paquet M. RSVP transportait cette déclaration dans le sens aval. Les nœuds ne réécrivaient pas le TSpec d’origine pour l’adapter à leur propre observation.

Ce détail empêche une confusion importante.

Le TSpec ne certifiait pas que tous les paquets resteraient conformes. Il ne mesurait pas la bande passante disponible. Il ne disait pas ce que les récepteurs accepteraient. Il annonçait la forme du trafic pour permettre aux éléments de service d’évaluer une demande.

Une implémentation pouvait ensuite contrôler la conformité. Des paquets hors profil pouvaient subir un autre traitement. Mais cette réalité d’exécution appartenait à une étape ultérieure. La déclaration gardait son sens propre.

Le réseau résumait sans promettre

L’ADSPEC était écrit par le chemin participant.

Le fragment général pouvait contenir le nombre de sauts Integrated Services, une bande passante de chemin, une latence minimale et un MTU composé. Un fragment de service garanti pouvait contenir les termes d’erreur cumulés utilisés par le calcul de borne de délai.

Ces données aidaient le récepteur à prendre une décision. Elles ne constituaient pas encore une réservation.

La publicité correspondait au parcours suivi par le message PATH au moment de son traitement. Une modification de routage pouvait rendre cette représentation ancienne. Une évolution des ressources locales pouvait changer la décision d’admission. Une politique pouvait refuser une demande pourtant cohérente avec la publicité.

Un ADSPEC sans rupture était donc un élément de preuve positif mais borné : le mécanisme n’avait pas enregistré le type de discontinuité que le bit devait signaler. Il ne garantissait pas l’avenir.

Le récepteur demandait, puis le réseau décidait

Le FLOWSPEC venait du récepteur et remontait vers l’émetteur dans l’état RESV.

Le récepteur pouvait combiner ses besoins, le TSpec, l’ADSPEC et sa politique. Pour le service garanti, il pouvait utiliser les paramètres composés afin de choisir une réservation compatible avec une borne recherchée. Pour Controlled-Load, il formulait une demande selon la définition distincte de ce service.

Cette construction était une demande, pas une constatation.

Chaque élément RSVP concerné présentait le TSpec et le FLOWSPEC au module de contrôle de trafic approprié. La politique locale et le contrôle d’admission intervenaient encore. Plusieurs réservations pouvaient être fusionnées. L’objet qui continuait vers l’amont pouvait donc différer de la demande initiale d’un récepteur particulier.

Le mot « fusion » peut donner l’impression d’une vérité consolidée. Il désignait une opération de protocole et de contrôle. Une valeur fusionnée expliquait l’état de réservation produit à ce point, pas le comportement déjà observé de tous les paquets.

Deux ruptures pour deux questions différentes

Le bit général et les bits spécifiques n’avaient pas le même domaine.

Le premier demandait si le chemin pouvait participer à l’interprétation générale RSVP/Integrated Services. Un élément non participant suffisait à rompre la chaîne et à rendre la synthèse globale non fiable.

Le second demandait si un service déterminé était disponible dans les éléments RSVP conscients du chemin. Un routeur pouvait comprendre RSVP, traiter les objets et pourtant ne pas mettre en œuvre le service garanti. Le bit associé à ce service devait alors signaler cette lacune.

Cette distinction évitait d’accorder à la signalisation des capacités qu’elle ne possède pas. Savoir transporter un objet de service n’équivalait pas à fournir le comportement défini par ce service.

Elle évitait aussi d’interpréter tout manque comme une panne générale. Un chemin pouvait rester cohérent pour les mécanismes Integrated Services tout en ne prenant pas en charge une option particulière.

Le MTU montrait trois réalités simultanées

La taille maximale des paquets circulait sous plusieurs formes.

Dans le TSpec, M exprimait le plus grand paquet que l’émetteur pouvait produire. Dans l’ADSPEC, PATH_MTU diminuait lorsqu’un élément rencontrait une limite locale plus basse. Lorsqu’un récepteur considérait plusieurs émetteurs ou qu’un point fusionnait plusieurs branches de réservation, la valeur la plus petite devenait déterminante pour la couverture commune.

L’émetteur ne corrigeait pas sa déclaration originale pour la rendre identique au résultat composé.

Cette coexistence n’était pas une anomalie de données. Elle préservait trois questions différentes : que peut générer la source ? que peut couvrir le chemin annoncé ? quelle taille maximale toutes les branches représentées peuvent-elles accepter ?

RFC 2210 associait une conséquence pratique à cette limite. Un paquet plus grand que le maximum couvert pouvait ne recevoir qu’un traitement best effort.

L’existence d’une réservation n’autorisait donc pas à classer indistinctement tous les paquets du flux comme réservés. La taille faisait partie du périmètre.

Les paramètres garantis restaient conditionnels

Le service garanti ajoutait des paramètres composés : Ctot, Dtot, Csum et Dsum. Les règles de RFC 2212 permettaient de les accumuler et de les utiliser avec le profil de trafic pour dériver une borne de délai.

La mathématique rendait la garantie vérifiable dans son modèle. Elle ne supprimait pas les hypothèses du modèle.

Il fallait un trafic conforme, un service pris en charge, une réservation admise et un chemin auquel les valeurs composées continuaient de s’appliquer. La borne concernait le comportement de file d’attente défini par le service. Elle n’attestait ni la livraison d’un paquet particulier, ni l’exécution d’une transaction applicative.

Controlled-Load suivait un autre contrat. Il cherchait à offrir au trafic conforme un service proche de celui d’un réseau best effort non chargé, sous contrôle d’admission, sans promettre une valeur numérique précise de délai ou de perte. Son fragment ADSPEC n’exigeait pas les mêmes termes composés, mais son bit spécifique restait nécessaire pour dire si le chemin participant savait fournir le service.

Traiter les deux services comme de simples étiquettes « QoS » aurait effacé leur contenu réel.

Le protocole de réservation n’était pas le service

RFC 2210 occupait une position de jonction.

RFC 2205 définissait RSVP et la circulation de l’état PATH/RESV. RFC 2211 et RFC 2212 définissaient les comportements Controlled-Load et Guaranteed. RFC 2215 expliquait les paramètres locaux et composés. RFC 2216 décrivait un service au niveau d’un élément réseau. RFC 2210 précisait comment ces mondes utilisaient les objets communs.

Cette architecture permettait à RSVP de transporter des contenus dont il ne possédait pas lui-même toute la sémantique. Un module de service pouvait interpréter les paramètres que le moteur de signalisation traitait comme opaques.

La séparation était volontaire : la signalisation indiquait un état de demande ; le service définissait le traitement ; l’observation du trafic appartenait encore à une autre couche.

La sécurité suivait la même limite. Les objets n’étaient pas auto-authentifiants. L’accès à une qualité de service améliorée nécessitait politique et authentification en dehors de la simple présence d’un FLOWSPEC bien formé.

Ce qu’un objet propre ne prouvait toujours pas

Supposons un ADSPEC sans bit de rupture, un FLOWSPEC valide et une réservation fusionnée qui atteint l’émetteur.

On peut dire que la signalisation représentée a franchi plusieurs étapes définies. On ne peut pas encore dire que la route restera identique, que toutes les admissions futures réussiront, que l’émetteur respectera toujours son TSpec, que chaque paquet recevra le traitement attendu, que la télémétrie confirmera la borne, ni que l’application atteindra son but.

Ces négations ne diminuent pas la valeur du protocole. Elles lui rendent sa précision.

Le rôle d’une spécification n’est pas de faire disparaître toutes les incertitudes. Il est de définir quelles assertions chaque objet peut légitimement porter. RFC 2210 est remarquable parce qu’il encode aussi le moment où cette légitimité se rompt.