Aller au contenu principal

7. Protocol Version Negotiation (Négociation de version du protocole)

7. Protocol Version Negotiation (Négociation de version du protocole)

Un routeur DOIT démarrer chaque connexion de transport en émettant soit une Reset Query soit une Serial Query. Cette requête indiquera au cache quelle version de ce protocole le routeur implémente.

Si un cache qui prend en charge la version 1 reçoit une requête d'un routeur qui spécifie la version 0, le cache DOIT rétrograder vers la version 0 du protocole [RFC6810] ou envoyer un PDU Error Report de version 1 avec le code d'erreur 4 ("Version de protocole non prise en charge") et terminer la connexion.

Si un routeur qui prend en charge la version 1 envoie une requête à un cache qui ne prend en charge que la version 0, l'une des deux choses suivantes se produira:

  1. Le cache peut terminer la connexion, peut-être avec un PDU Error Report de version 0. Dans ce cas, le routeur PEUT réessayer la connexion en utilisant la version 0 du protocole.

  2. Le cache peut répondre avec une réponse de version 0. Dans ce cas, le routeur DOIT soit rétrograder vers la version 0 soit terminer la connexion.

Dans toutes les combinaisons rétrogradées ci-dessus, les nouvelles fonctionnalités de la version 1 ne seront pas disponibles, et tous les PDU auront 0 dans leurs champs de version.

Si l'une des parties reçoit un PDU contenant une version de protocole non reconnue (ni 0 ni 1) pendant cette négociation, elle DOIT soit rétrograder vers une version connue soit terminer la connexion, avec un PDU Error Report à moins que le PDU reçu ne soit lui-même un PDU Error Report.

Le routeur DOIT ignorer tous les PDU Serial Notify qu'il pourrait recevoir du cache pendant cette période de démarrage initiale, quel que soit le champ Version de protocole dans le PDU Serial Notify. Étant donné que les valeurs de Session ID et Serial Number sont spécifiques à une version de protocole particulière, les valeurs de la notification ne sont pas utiles au routeur. Même si ces valeurs étaient significatives, le seul effet du traitement de la notification serait de déclencher exactement la même Reset Query ou Serial Query que le routeur a déjà envoyée dans le cadre du processus de négociation de version pas encore terminé, il n'y a donc rien à gagner à traiter les notifications jusqu'à ce que la négociation de version soit terminée.

Les caches NE DEVRAIENT PAS envoyer de PDU Serial Notify avant la fin de la négociation de version. Les routeurs, cependant, DOIVENT gérer de telles notifications (en les ignorant) pour la rétrocompatibilité avec les caches servant la version 0 du protocole.

Une fois que le cache et le routeur se sont mis d'accord sur une version de protocole via le processus de négociation ci-dessus, cette version est stable pour la durée de vie de la session. Voir la Section 5.1 pour une discussion sur l'interaction entre la version de protocole et le Session ID.

Si l'une des parties reçoit un PDU pour une version de protocole différente une fois la négociation ci-dessus terminée, cette partie DOIT abandonner la session; à moins que le PDU contenant la version de protocole inattendue ne soit lui-même un PDU Error Report, la partie abandonnant la session DEVRAIT envoyer un Error Report avec un code d'erreur de 8 ("Version de protocole inattendue").