Aller au contenu principal

RFC 5880 - Détection de Transmission Bidirectionnelle (BFD)

  • Statut: Proposed Standard
  • Publié: juin 2010
  • Stream: IETF
  • Errata: Pas d'errata

Résumé​

Ce document décrit un protocole destiné à détecter les pannes dans le chemin bidirectionnel entre deux moteurs de transmission, incluant les interfaces, les liaisons de données et, dans la mesure du possible, les moteurs de transmission eux-mêmes, avec une latence potentiellement très faible. Il fonctionne indépendamment des médias, des protocoles de données et des protocoles de routage.

Statut de ce mémorandum​

Il s'agit d'un document de la piste des normes Internet (Internet Standards Track).

Ce document est le produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a reçu un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). De plus amples informations sur les normes Internet sont disponibles dans la section 2 du RFC 5741.

Les informations sur le statut actuel de ce document, les errata éventuels et les moyens de fournir des commentaires peuvent être obtenues à l'adresse http://www.rfc-editor.org/info/rfc5880.

Notice de droit d'auteur​

Copyright (c) 2010 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Ce document est soumis au BCP 78 et aux dispositions juridiques de l'IETF Trust relatives aux documents IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Veuillez examiner attentivement ces documents, car ils décrivent vos droits et restrictions concernant ce document. Les composants de code extraits de ce document doivent inclure le texte de la licence BSD simplifiée tel que décrit dans la section 4.e des dispositions juridiques du Trust et sont fournis sans garantie, comme décrit dans la licence BSD simplifiée.

Table des matières​

Une section d'authentification optionnelle PEUT être présente dans le paquet de contrôle BFD. Dans sa forme générique, le but de la section d'authentification est de transporter toutes les informations nécessaires, en fonction du type d'authentification utilisé, pour permettre au système récepteur de déterminer la validité du paquet reçu. Le mécanisme exact dépend du type d'authentification utilisé, mais en général, le système émetteur mettra des informations dans la section d'authentification qui garantit la validité du paquet, et le système récepteur examinera la section d'authentification et acceptera soit le paquet pour un traitement ultérieur, soit le rejettera.

Le même type d'authentification, ainsi que toutes les clés ou autres informations nécessaires, doivent évidemment être utilisés par les deux systèmes. La négociation du type d'authentification, l'échange de clés, etc., sont tous en dehors de la portée de cette spécification et sont censés être effectués par des moyens extérieurs au protocole.

Notez que dans les sous-sections ci-dessous, "accepter" un paquet signifie uniquement que le paquet a passé l'authentification ; il peut en fait être rejeté pour d'autres raisons comme décrit dans les règles générales de réception de paquets décrites dans la section 6.8.6.

Les implémentations supportant l'authentification DOIVENT supporter les deux types d'authentification SHA1. Les autres formes d'authentification sont optionnelles.

Il peut être souhaitable d'activer ou de désactiver l'authentification sur une session sans perturber l'état de la session. Le mécanisme exact pour ce faire se situe en dehors de la portée de cette spécification. Cependant, il est utile de souligner certains problèmes pour soutenir ce mécanisme.

Dans une implémentation simple, une session BFD échouera lorsque l'authentification sera activée ou désactivée, car les règles d'acceptation des paquets exigent essentiellement que les machines locales et distantes le fassent de manière plus ou moins synchronisée (dans le temps de détection) -- un paquet avec authentification ne sera accepté que si l'authentification est "en cours d'utilisation" (et de même pour les paquets sans authentification).

Une approche possible consiste à construire une implémentation de sorte que l'authentification soit configurée, mais non considérée comme "en cours d'utilisation" jusqu'à ce que le premier paquet contenant une section d'authentification correspondante soit reçu (fournissant la synchronisation nécessaire). De même, l'authentification pourrait être configurée comme désactivée, mais toujours considérée comme "en cours d'utilisation" jusqu'à la réception du premier paquet sans section d'authentification.

Afin d'éviter les risques de sécurité, les implémentations utilisant cette méthode NE DEVRAIENT permettre que l'état d'authentification soit modifié au plus une fois sans une forme d'intervention (de sorte que l'authentification ne puisse pas être activée et désactivée de manière répétée simplement sur la base de la réception de paquets de contrôle BFD provenant de systèmes distants). À moins qu'il ne soit souhaité d'activer ou de désactiver l'authentification, une implémentation NE DEVRAIT PAS permettre que l'état d'authentification change en fonction de la réception de paquets de contrôle BFD.

La forme d'authentification la plus simple (et la plus faible) est l'authentification par mot de passe simple. Dans cette méthode d'authentification, un ou plusieurs mots de passe (avec les ID de clé correspondants) sont configurés dans chaque système et l'une de ces paires Mot de passe/ID est transportée dans chaque paquet de contrôle BFD. Le système récepteur accepte le paquet si le mot de passe et l'ID de clé correspondent à l'une des paires Mot de passe/ID configurées dans ce système.

Transmission utilisant l'authentification par mot de passe simple​

Le mot de passe actuellement sélectionné et l'ID de clé pour la session DOIVENT être stockés dans la section d'authentification de chaque paquet de contrôle BFD sortant. Le champ Auth Type DOIT être défini sur 1 (mot de passe simple). Le champ Auth Len DOIT être défini sur la longueur appropriée (4 à 19 octets).

Le mot de passe est une chaîne binaire et DOIT avoir une longueur de 1 à 16 octets. Pour l'interopérabilité, l'interface de gestion par laquelle le mot de passe est configuré DOIT accepter les chaînes ASCII et DEVRAIT également permettre la configuration de toute chaîne binaire arbitraire sous forme hexadécimale. D'autres méthodes de configuration PEUVENT être supportées.

Réception utilisant l'authentification par mot de passe simple​

Si le paquet de contrôle BFD reçu ne contient pas de section d'authentification, ou si le Auth Type n'est pas 1 (mot de passe simple), alors le paquet reçu DOIT être rejeté.

Si le champ Auth Key ID ne correspond pas à l'ID d'un mot de passe configuré, le paquet reçu DOIT être rejeté.

Si le champ Auth Len n'est pas égal à la longueur du mot de passe sélectionné par l'ID de clé, plus trois, le paquet DOIT être rejeté.

Si le champ Password ne correspond pas au mot de passe sélectionné par l'ID de clé, le paquet DOIT être rejeté.

Sinon, le paquet DOIT être accepté.

Les mécanismes d'authentification MD5 à clé et MD5 à clé méticuleux sont très similaires à ceux utilisés dans d'autres protocoles. Dans ces méthodes d'authentification, une ou plusieurs clés secrètes (avec les ID de clé correspondants) sont configurées dans chaque système. L'une des clés est incluse dans un condensé MD5 [MD5] calculé sur le paquet de contrôle BFD sortant, mais la clé elle-même n'est pas transportée dans le paquet. Pour aider à éviter les attaques par rejeu, un numéro de séquence est également transporté dans chaque paquet. Pour MD5 à clé, le numéro de séquence est occasionnellement incrémenté. Pour MD5 à clé méticuleux, le numéro de séquence est incrémenté à chaque paquet.

Le système récepteur accepte le paquet si l'ID de clé correspond à l'une des clés configurées, un condensé MD5 incluant la clé sélectionnée correspond à celui transporté dans le paquet, et le numéro de séquence est supérieur ou égal au dernier numéro de séquence reçu (pour MD5 à clé), ou strictement supérieur au dernier numéro de séquence reçu (pour MD5 à clé méticuleux).

Transmission utilisant l'authentification MD5 à clé et MD5 à clé méticuleux​

Le champ Auth Type DOIT être défini sur 2 (MD5 à clé) ou 3 (MD5 à clé méticuleux). Le champ Auth Len DOIT être défini sur 24. Le champ Auth Key ID DOIT être défini sur l'ID de la clé d'authentification actuelle. Le champ Sequence Number DOIT être défini sur bfd.XmitAuthSeq.

La valeur de la clé d'authentification est une chaîne binaire pouvant aller jusqu'à 16 octets et DOIT être placée dans le champ Auth Key/Digest, complétée par des octets zéro de fin si nécessaire. Pour l'interopérabilité, l'interface de gestion par laquelle la clé est configurée DOIT accepter les chaînes ASCII et DEVRAIT également permettre la configuration de toute chaîne binaire arbitraire sous forme hexadécimale. D'autres méthodes de configuration PEUVENT être supportées.

Un condensé MD5 DOIT être calculé sur l'ensemble du paquet de contrôle BFD. Le condensé résultant DOIT être stocké dans le champ Auth Key/Digest avant la transmission (en remplacement de la clé secrète, qui NE DOIT PAS être transportée dans le paquet).

Pour MD5 à clé, bfd.XmitAuthSeq PEUT être incrémenté de manière circulaire (lorsqu'il est traité comme une valeur non signée de 32 bits). bfd.XmitAuthSeq DEVRAIT être incrémenté lorsque l'état de la session change, ou lorsque le paquet de contrôle BFD transmis transporte un contenu différent du paquet précédemment transmis. La décision quant au moment d'incrémenter bfd.XmitAuthSeq se situe en dehors de la portée de cette spécification. Voir la section intitulée "Considérations de sécurité" ci-dessous pour une discussion.

Pour MD5 à clé méticuleux, bfd.XmitAuthSeq DOIT être incrémenté de manière circulaire (lorsqu'il est traité comme une valeur non signée de 32 bits).

Réception utilisant l'authentification MD5 à clé et MD5 à clé méticuleux​

Si le paquet de contrôle BFD reçu ne contient pas de section d'authentification, ou si le Auth Type n'est pas correct (2 pour MD5 à clé ou 3 pour MD5 à clé méticuleux), alors le paquet reçu DOIT être rejeté.

Si le champ Auth Key ID ne correspond pas à l'ID d'une clé d'authentification configurée, le paquet reçu DOIT être rejeté.

Si le champ Auth Len n'est pas égal à 24, le paquet DOIT être rejeté.

Si bfd.AuthSeqKnown est 1, examinez le champ Sequence Number. Pour MD5 à clé, si le numéro de séquence se situe en dehors de la plage de bfd.RcvAuthSeq à bfd.RcvAuthSeq+(3Detect Mult) inclus (lorsqu'il est traité comme un espace de numéros circulaire non signé de 32 bits), le paquet reçu DOIT être rejeté. Pour MD5 à clé méticuleux, si le numéro de séquence se situe en dehors de la plage de bfd.RcvAuthSeq+1 à bfd.RcvAuthSeq+(3Detect Mult) inclus (lorsqu'il est traité comme un espace de numéros circulaire non signé de 32 bits), le paquet reçu DOIT être rejeté.

Sinon (bfd.AuthSeqKnown est 0), bfd.AuthSeqKnown DOIT être défini sur 1, et bfd.RcvAuthSeq DOIT être défini sur la valeur du champ Sequence Number reçu.

Remplacez le contenu du champ Auth Key/Digest par la clé d'authentification sélectionnée par le champ Auth Key ID reçu. Si le condensé MD5 de l'ensemble du paquet de contrôle BFD est égal à la valeur reçue du champ Auth Key/Digest, le paquet reçu DOIT être accepté. Sinon (le condensé ne correspond pas au champ Auth Key/Digest), le paquet reçu DOIT être rejeté.

Les mécanismes d'authentification SHA1 à clé et SHA1 à clé méticuleux sont très similaires à ceux utilisés dans d'autres protocoles. Dans ces méthodes d'authentification, une ou plusieurs clés secrètes (avec les ID de clé correspondants) sont configurées dans chaque système. L'une des clés est incluse dans un hachage SHA1 [SHA1] calculé sur le paquet de contrôle BFD sortant, mais la clé elle-même n'est pas transportée dans le paquet. Pour aider à éviter les attaques par rejeu, un numéro de séquence est également transporté dans chaque paquet. Pour SHA1 à clé, le numéro de séquence est occasionnellement incrémenté. Pour SHA1 à clé méticuleux, le numéro de séquence est incrémenté à chaque paquet.

Le système récepteur accepte le paquet si l'ID de clé correspond à l'une des clés configurées, un hachage SHA1 incluant la clé sélectionnée correspond à celui transporté dans le paquet, et si le numéro de séquence est supérieur ou égal au dernier numéro de séquence reçu (pour SHA1 à clé), ou strictement supérieur au dernier numéro de séquence reçu (pour SHA1 à clé méticuleux).

Transmission utilisant l'authentification SHA1 à clé et SHA1 à clé méticuleux​

Le champ Auth Type DOIT être défini sur 4 (SHA1 à clé) ou 5 (SHA1 à clé méticuleux). Le champ Auth Len DOIT être défini sur 28. Le champ Auth Key ID DOIT être défini sur l'ID de la clé d'authentification actuelle. Le champ Sequence Number DOIT être défini sur bfd.XmitAuthSeq.

La valeur de la clé d'authentification est une chaîne binaire pouvant aller jusqu'à 20 octets et DOIT être placée dans le champ Auth Key/Hash, complétée par des octets zéro de fin si nécessaire. Pour l'interopérabilité, l'interface de gestion par laquelle la clé est configurée DOIT accepter les chaînes ASCII et DEVRAIT également permettre la configuration de toute chaîne binaire arbitraire sous forme hexadécimale. D'autres méthodes de configuration PEUVENT être supportées.

Un hachage SHA1 DOIT être calculé sur l'ensemble du paquet de contrôle BFD. Le hachage résultant DOIT être stocké dans le champ Auth Key/Hash avant la transmission (en remplacement de la clé secrète, qui NE DOIT PAS être transportée dans le paquet).

Pour SHA1 à clé, bfd.XmitAuthSeq PEUT être incrémenté de manière circulaire (lorsqu'il est traité comme une valeur non signée de 32 bits). bfd.XmitAuthSeq DEVRAIT être incrémenté lorsque l'état de la session change, ou lorsque le paquet de contrôle BFD transmis transporte un contenu différent du paquet précédemment transmis. La décision quant au moment d'incrémenter bfd.XmitAuthSeq se situe en dehors de la portée de cette spécification. Voir la section intitulée "Considérations de sécurité" ci-dessous pour une discussion.

Pour SHA1 à clé méticuleux, bfd.XmitAuthSeq DOIT être incrémenté de manière circulaire (lorsqu'il est traité comme une valeur non signée de 32 bits).

Réception utilisant l'authentification SHA1 à clé et SHA1 à clé méticuleux​

Si le paquet de contrôle BFD reçu ne contient pas de section d'authentification, ou si le Auth Type n'est pas correct (4 pour SHA1 à clé ou 5 pour SHA1 à clé méticuleux), alors le paquet reçu DOIT être rejeté.

Si le champ Auth Key ID ne correspond pas à l'ID d'une clé d'authentification configurée, le paquet reçu DOIT être rejeté.

Si le champ Auth Len n'est pas égal à 28, le paquet DOIT être rejeté.

Si bfd.AuthSeqKnown est 1, examinez le champ Sequence Number. Pour SHA1 à clé, si le numéro de séquence se situe en dehors de la plage de bfd.RcvAuthSeq à bfd.RcvAuthSeq+(3Detect Mult) inclus (lorsqu'il est traité comme un espace de numéros circulaire non signé de 32 bits), le paquet reçu DOIT être rejeté. Pour SHA1 à clé méticuleux, si le numéro de séquence se situe en dehors de la plage de bfd.RcvAuthSeq+1 à bfd.RcvAuthSeq+(3Detect Mult) inclus (lorsqu'il est traité comme un espace de numéros circulaire non signé de 32 bits, le paquet reçu DOIT être rejeté.

Sinon (bfd.AuthSeqKnown est 0), bfd.AuthSeqKnown DOIT être défini sur 1, bfd.RcvAuthSeq DOIT être défini sur la valeur du champ Sequence Number reçu, et le paquet reçu DOIT être accepté.

Remplacez le contenu du champ Auth Key/Hash par la clé d'authentification sélectionnée par le champ Auth Key ID reçu. Si le hachage SHA1 de l'ensemble du paquet de contrôle BFD est égal à la valeur reçue du champ Auth Key/Hash, le paquet reçu DOIT être accepté. Sinon (le hachage ne correspond pas au champ Auth Key/Hash), le paquet reçu DOIT être rejeté.

La section suivante de cette spécification est normative. Les moyens par lesquels cette spécification est réalisée sont en dehors du champ d'application de cette spécification.

Lorsqu'un système est dit avoir "la fonction Echo active", cela signifie que le système envoie des paquets BFD Echo, impliquant que la session est Up et que l'autre système a signalé sa volonté de renvoyer les paquets Echo.

Lorsque le système local est dit avoir "le mode Demand actif", cela signifie que bfd.DemandMode est à 1 dans le système local (voir section 6.8.1), que la session est Up et que le système distant signale que la session est dans l'état Up.

Lorsque le système distant est dit avoir "le mode Demand actif", cela signifie que bfd.RemoteDemandMode est à 1 (le système distant a positionné le bit Demand (D) dans le dernier paquet de contrôle BFD reçu), que la session est Up et que le système distant signale que la session est dans l'état Up.

Les valeurs de temps utilisées pour déterminer les intervalles de transmission des paquets BFD et le temps de détection de session sont continuellement négociées, et peuvent donc être modifiées à tout moment. La négociation et les valeurs de temps sont indépendantes dans chaque direction pour chaque session.

Chaque système signale dans le paquet de contrôle BFD à quelle rapidité il aimerait transmettre des paquets BFD, ainsi qu'à quelle rapidité il est préparé à les recevoir. Cela permet à l'un ou l'autre système de déterminer unilatéralement le débit de paquets maximum (intervalle minimum) dans les deux directions.

Voir la section 6.8.7 pour les détails de la temporisation de transmission de paquets et de la négociation.

Les valeurs de temps utilisées pour déterminer les intervalles de transmission des paquets BFD et le temps de détection de session peuvent être modifiées à tout moment sans affecter l'état de la session. Lorsque les paramètres de minuteur sont modifiés pour quelque raison que ce soit, les exigences de cette section s'appliquent.

Si bfd.DesiredMinTxInterval est modifié ou si bfd.RequiredMinRxInterval est modifié, une séquence de sondage (Poll Sequence) DOIT être initiée (voir section 6.5). Si la temporisation est telle qu'un système recevant une séquence de sondage souhaite modifier les paramètres décrits dans ce paragraphe, les nouvelles valeurs de paramètres PEUVENT être transportées dans des paquets avec le bit Final (F) positionné, même si la séquence de sondage n'a pas encore été envoyée.

Si bfd.DesiredMinTxInterval est augmenté et que bfd.SessionState est Up, l'intervalle de transmission réel utilisé NE DOIT PAS changer jusqu'à ce que la séquence de sondage décrite ci-dessus soit terminée. Cela permet de s'assurer que le système distant met à jour son temps de détection avant que l'intervalle de transmission n'augmente.

Si bfd.RequiredMinRxInterval est réduit et que bfd.SessionState est Up, la valeur précédente de bfd.RequiredMinRxInterval DOIT être utilisée lors du calcul du temps de détection pour le système distant jusqu'à ce que la séquence de sondage décrite ci-dessus soit terminée. Cela permet de s'assurer que le système distant transmet des paquets au débit plus élevé (et que ces paquets sont reçus) avant que le temps de détection ne soit réduit.

Lorsque bfd.SessionState n'est pas Up, le système DOIT définir bfd.DesiredMinTxInterval à une valeur d'au moins une seconde (1,000,000 microsecondes). Cela est destiné à garantir que la bande passante consommée par les sessions BFD qui ne sont pas Up est négligeable, en particulier dans le cas où un voisin peut ne pas exécuter BFD.

Si le système local réduit son intervalle de transmission en raison de la réduction de bfd.RemoteMinRxInterval (le système distant a annoncé une valeur réduite dans Required Min RX Interval), et que le système distant n'est pas en mode Demand, le système local DOIT honorer le nouvel intervalle immédiatement. En d'autres termes, le système local ne peut pas attendre plus longtemps que le nouvel intervalle entre la transmission précédente de paquet et la suivante. Si cet intervalle s'est déjà écoulé depuis la dernière transmission (parce que le nouvel intervalle est significativement plus court), le système local DOIT envoyer le prochain paquet de contrôle BFD périodique dès que possible.

Lorsque la fonction Echo est active, un système DEVRAIT définir bfd.RequiredMinRxInterval à une valeur d'au moins une seconde (1,000,000 microsecondes). Cela est destiné à maintenir le trafic de contrôle BFD reçu à un niveau négligeable, puisque la fonction de détection réelle est effectuée en utilisant des paquets BFD Echo.

Dans tout autre cas que ceux explicitement mentionnés ci-dessus, les changements de paramètres de temporisation DOIVENT être effectués immédiatement (changeant le débit de transmission et/ou le temps de détection).

Notez que le mécanisme de séquence de sondage est ambigu si plus d'un changement de paramètre est effectué qui nécessiterait son utilisation, et que ces multiples changements sont répartis sur plusieurs paquets (puisque la sémantique du Final de retour n'est pas claire). Par conséquent, si plusieurs changements sont effectués qui nécessitent l'utilisation d'une séquence de sondage, il y a trois choix: 1) ils DOIVENT être communiqués dans un seul paquet de contrôle BFD (afin que la sémantique de la réponse Final soit claire), ou 2) un temps suffisant doit s'être écoulé depuis que la séquence de sondage a été complétée pour désambiguïser la situation (au moins un temps d'aller-retour depuis que le dernier sondage a été transmis) avant l'initiation d'une autre séquence de sondage, ou 3) un paquet de contrôle BFD supplémentaire avec le bit Final (F) effacé DOIT être reçu après que la séquence de sondage ait été complétée avant l'initiation d'une autre séquence de sondage (cette option n'est pas disponible lorsque le mode Demand est actif).

Le temps de détection (la période de temps sans recevoir de paquets BFD après laquelle la session est déterminée comme ayant échoué) n'est pas transporté explicitement dans le protocole. Au lieu de cela, il est calculé indépendamment dans chaque direction par le système récepteur en fonction de l'intervalle de transmission négocié et du multiplicateur de détection. Notez qu'il peut y avoir des temps de détection différents dans chaque direction.

Le calcul du temps de détection est légèrement différent en mode Demand par rapport au mode Asynchrone.

En mode Asynchrone, le temps de détection calculé dans le système local est égal à la valeur de Detect Mult reçue du système distant, multipliée par l'intervalle de transmission convenu du système distant (le plus grand de bfd.RequiredMinRxInterval et du dernier Desired Min TX Interval reçu). La valeur Detect Mult est (grosso modo, en raison de la gigue) le nombre de paquets qui doivent être manqués d'affilée pour déclarer la session comme étant down.

Si le mode Demand n'est pas actif, et qu'une période de temps égale au temps de détection s'écoule sans recevoir de paquet de contrôle BFD du système distant, et que bfd.SessionState est Init ou Up, la session est tombée -- le système local DOIT définir bfd.SessionState à Down et bfd.LocalDiag à 1 (Control Detection Time Expired).

En mode Demand, le temps de détection calculé dans le système local est égal à bfd.DetectMult, multiplié par l'intervalle de transmission convenu du système local (le plus grand de bfd.DesiredMinTxInterval et bfd.RemoteMinRxInterval). bfd.DetectMult est (grosso modo, en raison de la gigue) le nombre de paquets qui doivent être manqués d'affilée pour déclarer la session comme étant down.

Si le mode Demand est actif, et qu'une période de temps égale au temps de détection s'écoule après l'initiation d'une séquence de sondage (la transmission du premier paquet de contrôle BFD avec le bit Poll positionné), la session est tombée -- le système local DOIT définir bfd.SessionState à Down, et bfd.LocalDiag à 1 (Control Detection Time Expired).

(Notez qu'un paquet est considéré comme ayant été reçu, aux fins de l'expiration du temps de détection, seulement s'il n'a pas été "rejeté" selon les règles de la section 6.8.6).

Lorsque la fonction Echo est active et qu'un nombre suffisant de paquets Echo n'arrivent pas comme ils le devraient, la session est tombée -- le système local DOIT définir bfd.SessionState à Down et bfd.LocalDiag à 2 (Echo Function Failed).

Les moyens par lesquels les défaillances de la fonction Echo sont détectées sont en dehors du champ d'application de cette spécification. Tout moyen qui détectera une défaillance de communication est acceptable.

Lorsqu'un paquet de contrôle BFD est reçu, la procédure suivante DOIT être suivie, dans l'ordre spécifié. Si le paquet est rejeté selon ces règles, le traitement du paquet DOIT cesser à ce point.

Si le numéro de version n'est pas correct (1), le paquet DOIT être rejeté.

Si le champ Length est inférieur à la valeur correcte minimale (24 si le bit A est effacé, ou 26 si le bit A est positionné), le paquet DOIT être rejeté.

Si le champ Length est supérieur à la charge utile du protocole d'encapsulation, le paquet DOIT être rejeté.

Si le champ Detect Mult est zéro, le paquet DOIT être rejeté.

Si le bit Multipoint (M) est non nul, le paquet DOIT être rejeté.

Si le champ My Discriminator est zéro, le paquet DOIT être rejeté.

Si le champ Your Discriminator est non nul, il DOIT être utilisé pour sélectionner la session à laquelle ce paquet BFD est associé. Si aucune session n'est trouvée, le paquet DOIT être rejeté.

Si le champ Your Discriminator est zéro et que le champ State n'est pas Down ou AdminDown, le paquet DOIT être rejeté.

Si le champ Your Discriminator est zéro, la session DOIT être sélectionnée en fonction d'une combinaison d'autres champs, incluant éventuellement les informations d'adressage source, le champ My Discriminator, et l'interface sur laquelle le paquet a été reçu. La méthode exacte de sélection est spécifique à l'application et est donc en dehors du champ d'application de cette spécification. Si une session correspondante n'est pas trouvée, une nouvelle session PEUT être créée, ou le paquet PEUT être rejeté. Ce choix est en dehors du champ d'application de cette spécification.

Si le bit A est positionné et qu'aucune authentification n'est utilisée (bfd.AuthType est zéro), le paquet DOIT être rejeté.

Si le bit A est effacé et que l'authentification est utilisée (bfd.AuthType est non nul), le paquet DOIT être rejeté.

Si le bit A est positionné, le paquet DOIT être authentifié selon les règles de la section 6.7, en fonction du type d'authentification utilisé (bfd.AuthType). Cela peut entraîner le rejet du paquet.

Définir bfd.RemoteDiscr à la valeur de My Discriminator.

Définir bfd.RemoteState à la valeur du champ State (Sta).

Définir bfd.RemoteDemandMode à la valeur du bit Demand (D).

Définir bfd.RemoteMinRxInterval à la valeur de Required Min RX Interval.

Si le champ Required Min Echo RX Interval est zéro, la transmission des paquets Echo, le cas échéant, DOIT cesser.

Si une séquence de sondage est transmise par le système local et que le bit Final (F) dans le paquet reçu est positionné, la séquence de sondage DOIT être terminée.

Mettre à jour l'intervalle de transmission comme décrit dans la section 6.8.2.

Mettre à jour le temps de détection comme décrit dans la section 6.8.4.

Si bfd.SessionState est AdminDown

Rejeter le paquet

Si l'état reçu est AdminDown Si bfd.SessionState n'est pas Down Définir bfd.LocalDiag à 3 (Neighbor signaled session down) Définir bfd.SessionState à Down

Sinon

Si bfd.SessionState est Down
    Si l'état reçu est Down
        Définir bfd.SessionState à Init
    Sinon si l'état reçu est Init
        Définir bfd.SessionState à Up

Sinon si bfd.SessionState est Init
    Si l'état reçu est Init ou Up
        Définir bfd.SessionState à Up

Sinon (bfd.SessionState est Up)
    Si l'état reçu est Down
        Définir bfd.LocalDiag à 3 (Neighbor signaled
        session down)
        Définir bfd.SessionState à Down

Vérifier si le mode Demand doit devenir actif ou non (voir section 6.6).

Si bfd.RemoteDemandMode est 1, bfd.SessionState est Up, et bfd.RemoteSessionState est Up, le mode Demand est actif sur le système distant et le système local DOIT cesser la transmission périodique de paquets de contrôle BFD (voir section 6.8.7).

Si bfd.RemoteDemandMode est 0, ou bfd.SessionState n'est pas Up, ou bfd.RemoteSessionState n'est pas Up, le mode Demand n'est pas actif sur le système distant et le système local DOIT envoyer des paquets de contrôle BFD périodiques (voir section 6.8.7).

Si le bit Poll (P) est positionné, envoyer un paquet de contrôle BFD au système distant avec le bit Poll (P) effacé, et le bit Final (F) positionné (voir section 6.8.7).

Si le paquet n'a pas été rejeté, il a été reçu aux fins des règles d'expiration du temps de détection de la section 6.8.4.

À l'exception des cas listés dans le reste de cette section, un système NE DOIT PAS transmettre de paquets de contrôle BFD à un intervalle inférieur au plus grand de bfd.DesiredMinTxInterval et bfd.RemoteMinRxInterval, moins la gigue appliquée (voir ci-dessous). En d'autres termes, le système signalant le débit le plus lent détermine le débit de transmission.

La transmission périodique de paquets de contrôle BFD DOIT être giguée sur une base par paquet jusqu'à 25%, c'est-à-dire que l'intervalle DOIT être réduit d'une valeur aléatoire de 0 à 25%, afin d'éviter l'auto-synchronisation avec d'autres systèmes sur le même sous-réseau. Ainsi, l'intervalle moyen entre les paquets sera d'environ 12,5% inférieur à celui négocié.

Si bfd.DetectMult est égal à 1, l'intervalle entre les paquets de contrôle BFD transmis DOIT être au maximum 90% de l'intervalle de transmission négocié, et DOIT être au minimum 75% de l'intervalle de transmission négocié. Cela permet de s'assurer que, sur le système distant, le temps de détection calculé ne s'écoule pas avant la réception du prochain paquet de contrôle BFD.

L'intervalle de transmission DOIT être recalculé chaque fois que bfd.DesiredMinTxInterval change, ou chaque fois que bfd.RemoteMinRxInterval change, et est égal au plus grand de ces deux valeurs. Voir les sections 6.8.2 et 6.8.3 pour les détails sur les minuteurs de transmission.

Un système NE DOIT PAS transmettre de paquets de contrôle BFD si bfd.RemoteDiscr est zéro et que le système prend le rôle Passif.

Un système NE DOIT PAS transmettre périodiquement de paquets de contrôle BFD si bfd.RemoteMinRxInterval est zéro.

Un système NE DOIT PAS transmettre périodiquement de paquets de contrôle BFD si le mode Demand est actif sur le système distant (bfd.RemoteDemandMode est 1, bfd.SessionState est Up, et bfd.RemoteSessionState est Up) et qu'une séquence de sondage n'est pas en cours de transmission.

Si un paquet de contrôle BFD est reçu avec le bit Poll (P) positionné à 1, le système récepteur DOIT transmettre un paquet de contrôle BFD avec le bit Poll (P) effacé et le bit Final (F) positionné dès que possible, sans tenir compte du minuteur de transmission ou de toute autre limitation de transmission, sans tenir compte de l'état de la session, et sans tenir compte de si le mode Demand est actif sur l'un ou l'autre système. Un système PEUT limiter le débit auquel de tels paquets sont transmis. Si la limitation de débit est en vigueur, la valeur annoncée de Desired Min TX Interval DOIT être supérieure ou égale à l'intervalle entre les paquets transmis imposé par la fonction de limitation de débit.

Un système NE DOIT PAS positionner le bit Demand (D) sauf si bfd.DemandMode est 1, bfd.SessionState est Up, et bfd.RemoteSessionState est Up.

Un paquet de contrôle BFD DEVRAIT être transmis pendant l'intervalle entre les transmissions de paquets de contrôle périodiques lorsque le contenu de ce paquet différerait de celui du paquet transmis précédemment (autre que les bits Poll et Final) afin de communiquer plus rapidement un changement d'état.

Le contenu des paquets de contrôle BFD transmis DOIT être défini comme suit:

Version

Définie au numéro de version actuel (1).

Diagnostic (Diag)

Défini à bfd.LocalDiag.

State (Sta)

Défini à la valeur indiquée par bfd.SessionState.

Poll (P)

Défini à 1 si le système local envoie une séquence de sondage, ou 0 sinon.

Final (F)

Défini à 1 si le système local répond à un paquet de contrôle reçu avec le bit Poll (P) positionné, ou 0 sinon.

Control Plane Independent (C)

Défini à 1 si l'implémentation BFD du système local est indépendante du plan de contrôle (elle peut continuer à fonctionner malgré une perturbation du plan de contrôle).

Authentication Present (A)

Défini à 1 si l'authentification est utilisée sur cette session (bfd.AuthType est non nul), ou 0 sinon.

Demand (D)

Défini à bfd.DemandMode si bfd.SessionState est Up et bfd.RemoteSessionState est Up. Sinon, il est défini à 0.

Multipoint (M)

Défini à 0.

Detect Mult

Défini à bfd.DetectMult.

Length

Défini à la longueur appropriée, basée sur la longueur de l'en-tête fixe (24) plus toute section d'authentification.

My Discriminator

Défini à bfd.LocalDiscr.

Your Discriminator

Défini à bfd.RemoteDiscr.

Desired Min TX Interval

Défini à bfd.DesiredMinTxInterval.

Required Min RX Interval

Défini à bfd.RequiredMinRxInterval.

Required Min Echo RX Interval

Défini à l'intervalle minimum requis de réception de paquet Echo pour cette session. Si ce champ est défini à zéro, le système local n'est pas disposé ou incapable de renvoyer des paquets BFD Echo au système distant, et le système distant n'enverra pas de paquets Echo.

Authentication Section

Incluse et définie selon les règles de la section 6.7 si l'authentification est utilisée (bfd.AuthType est non nul). Sinon, cette section n'est pas présente.

Un paquet BFD Echo reçu DOIT être démultiplexé vers la session appropriée pour traitement. Un moyen de détecter les paquets Echo manquants DOIT être implémenté, ce qui implique très probablement le traitement des paquets Echo qui sont reçus. Le traitement des paquets Echo reçus est autrement en dehors du champ d'application de cette spécification.

Les paquets BFD Echo NE DOIVENT PAS être transmis lorsque bfd.SessionState n'est pas Up. Les paquets BFD Echo NE DOIVENT PAS être transmis sauf si le dernier paquet de contrôle BFD reçu du système distant contient une valeur non nulle dans Required Min Echo RX Interval.

Les paquets BFD Echo PEUVENT être transmis lorsque bfd.SessionState est Up. L'intervalle entre les paquets BFD Echo transmis NE DOIT PAS être inférieur à la valeur annoncée par le système distant dans Required Min Echo RX Interval, sauf comme suit:

Une gigue de 25% PEUT être appliquée au débit de transmission, de sorte que l'intervalle réel PEUT être entre 75% et 100% de la valeur annoncée. Un seul paquet BFD Echo PEUT être transmis entre les intervalles de transmission Echo normalement planifiés.

La transmission des paquets BFD Echo est autrement en dehors du champ d'application de cette spécification.