Appendix A: OSPF Data Formats (Formats de données OSPF)
A. Formats de données OSPF (OSPF data formats)
Le présent appendice décrit le format des paquets de protocole OSPF et des LSA OSPF. Le protocole OSPF s'exécute directement au-dessus de la couche réseau IP. Avant de décrire tout format de données, les détails de l'encapsulation OSPF sont expliqués.
Ensuite, le champ Options OSPF est décrit. Ce champ décrit diverses capacités qui peuvent ou non être prises en charge par des parties du domaine de routage OSPF. Le champ Options OSPF est contenu dans les paquets Hello OSPF, les paquets Database Description et les LSA OSPF.
Les formats de paquets OSPF sont détaillés dans la section A.3. Une description des LSA OSPF apparaît dans la section A.4.
A.1 Encapsulation des paquets OSPF (Encapsulation of OSPF packets)
OSPF s'exécute directement au-dessus de la couche réseau du protocole Internet. Les paquets OSPF sont donc encapsulés uniquement par IP et par les en-têtes de liaison de données locaux.
OSPF ne définit pas de moyen de fragmenter ses paquets de protocole et dépend du fragmentage IP lors de la transmission de paquets plus grands que le MTU du réseau. Si nécessaire, la longueur des paquets OSPF peut aller jusqu'à 65 535 octets (en-tête IP inclus). Les types de paquets OSPF susceptibles d'être volumineux (paquets Database Description, Link State Request, Link State Update et Link State Acknowledgment) peuvent généralement être divisés en plusieurs paquets de protocole séparés, sans perte de fonctionnalité. Ceci est recommandé ; le fragmentage IP doit être évité autant que possible. En suivant ce raisonnement, on doit tenter de limiter la taille des paquets OSPF envoyés sur les liens virtuels à 576 octets, à moins d'effectuer une découverte de MTU du chemin (Path MTU Discovery) (voir [Ref22]).
Les autres caractéristiques importantes de l'encapsulation IP d'OSPF sont :
o Utilisation du multicast IP. Certains messages OSPF sont diffusés en multicast lorsqu'ils sont envoyés sur des réseaux diffus (broadcast). Deux adresses IP multicast distinctes sont utilisées. Les paquets envoyés à ces adresses multicast ne doivent jamais être forwarded ; ils sont destinés à parcourir un seul saut uniquement. Pour garantir que ces paquets ne parcourront pas plusieurs sauts, leur TTL IP doit être fixé à 1.
AllSPFRouters
Cette adresse multicast se voit attribuer la valeur 224.0.0.5. Tous les routeurs exécutant OSPF doivent être prêts à recevoir les paquets envoyés à cette adresse. Les paquets Hello sont toujours envoyés à cette destination. Certains paquets de protocole OSPF sont également envoyés à cette adresse pendant la procédure de flooding.
AllDRouters
Cette adresse multicast se voit attribuer la valeur 224.0.0.6. Le Designated Router (routeur désigné) et le Backup Designated Router (routeur désigné de secours) doivent tous deux être prêts à recevoir les paquets destinés à cette adresse. Certains paquets de protocole OSPF sont envoyés à cette adresse pendant la procédure de flooding.
o OSPF est le numéro de protocole IP 89. Ce numéro a été enregistré auprès du Network Information Center. Les attributions de numéros de protocole IP sont documentées dans [Ref11].
o Tous les paquets de protocole de routage OSPF sont envoyés en utilisant la valeur TOS de service normal binaire 0000 définie dans [Ref12].
o Les paquets de protocole de routage sont envoyés avec la précédence IP fixée à Internetwork Control. Les paquets de protocole OSPF doivent avoir la priorité sur le trafic de données IP normal, tant à l'émission qu'à la réception. Fixer le champ de précédence IP dans l'en-tête IP à Internetwork Control [Ref5] peut aider à atteindre cet objectif.
A.2 Le champ Options (The Options field)
Le champ Options OSPF est présent dans les paquets Hello OSPF, les paquets Database Description et tous les LSA. Le champ Options permet aux routeurs OSPF de prendre en charge (ou non) des capacités optionnelles et de communiquer leur niveau de capacité aux autres routeurs OSPF. Grâce à ce mécanisme, des routeurs de capacités différentes peuvent être mélangés au sein d'un domaine de routage OSPF.
Lorsqu'il est utilisé dans les paquets Hello, le champ Options permet à un routeur de rejeter un voisin en raison d'une incompatibilité de capacités. Alternativement, lorsque les capacités sont échangées dans les paquets Database Description, un routeur peut choisir de ne pas transférer certains LSA à un voisin en raison de sa fonctionnalité réduite. Enfin, l'énumération des capacités dans les LSA permet aux routeurs de faire circuler le trafic en contournant les routeurs à fonctionnalité réduite, en les excluant de certaines parties du calcul de la table de routage.
Cinq bits du champ Options OSPF ont été assignés, bien qu'un seul (le bit E) soit décrit complètement par ce mémo. Chaque bit est décrit brièvement ci-dessous. Les routeurs doivent réinitialiser (c'est-à-dire effacer) les bits non reconnus dans le champ Options lors de l'envoi de paquets Hello ou Database Description et lors de l'émission (originating) de LSA. Inversement, les routeurs rencontrant des bits Option non reconnus dans les paquets Hello, Database Description ou LSA reçus doivent ignorer la capacité et traiter le paquet/LSA normalement.
+------------------------------------+
| * | * | DC | EA | N/P | MC | E | * |
+------------------------------------+
The Options field (Le champ Options)
E-bit
Ce bit décrit la façon dont les AS-external-LSAs sont diffusés (flooded), comme décrit dans les sections 3.6, 9.5, 10.8 et 12.1.2 de ce mémo.
MC-bit
Ce bit décrit si les datagrammes multicast IP sont transférés selon les spécifications de [Ref18].
N/P-bit
Ce bit décrit le traitement des LSA de type 7, tel que spécifié dans [Ref19].
EA-bit
Ce bit décrit la volonté du routeur de recevoir et de transférer les External-Attributes-LSAs, tel que spécifié dans [Ref20].
DC-bit
Ce bit décrit le traitement des circuits à la demande (demand circuits) par le routeur, tel que spécifié dans [Ref21].
A.3 Formats de paquets OSPF (OSPF Packet Formats)
Il existe cinq types de paquets OSPF distincts. Tous les types de paquets OSPF commencent par un en-tête standard de 24 octets. Cet en-tête est décrit en premier. Chaque type de paquet est ensuite décrit dans une section suivante. Dans ces sections, la division de chaque paquet en champs est affichée, puis les définitions des champs sont énumérées.
Tous les types de paquets OSPF (autres que les paquets Hello OSPF) traitent de listes de LSA. Par exemple, les paquets Link State Update implémentent l'inondation (flooding) des LSA dans tout le domaine de routage OSPF. Pour cette raison, les paquets de protocole OSPF ne peuvent pas être analysés à moins que le format des LSA ne soit également compris. Le format des LSA est décrit dans la section A.4.
Le traitement de réception des paquets OSPF est détaillé dans la section 8.2. L'envoi des paquets OSPF est expliqué dans la section 8.1.
A.3.1 L'en-tête de paquet OSPF (The OSPF packet header)
Chaque paquet OSPF commence par un en-tête standard de 24 octets. Cet en-tête contient toutes les informations nécessaires pour déterminer si le paquet doit être accepté pour un traitement ultérieur. Cette détermination est décrite dans la section 8.2 de la spécification.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version #
Le numéro de version d'OSPF. Cette spécification documente la version 2 du protocole.
Type
Les types de paquets OSPF sont les suivants. Voir les sections A.3.2 à A.3.6 pour les détails.
Type Description
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
Packet length
La longueur du paquet de protocole OSPF en octets. Cette longueur inclut l'en-tête OSPF standard.
Router ID
Le Router ID de la source du paquet.
Area ID
Un nombre de 32 bits identifiant la zone (Area) à laquelle ce paquet appartient. Tous les paquets OSPF sont associés à une seule zone. La plupart ne parcourent qu'un seul saut. Les paquets voyageant sur un lien virtuel sont étiquetés avec l'Area ID du backbone 0.0.0.0.
Checksum
La somme de contrôle IP standard de tout le contenu du paquet, en commençant par l'en-tête du paquet OSPF mais en excluant le champ d'authentification de 64 bits. Cette somme de contrôle est calculée comme le complément à un sur 16 bits de la somme des compléments à un de tous les mots de 16 bits du paquet, à l'exclusion du champ d'authentification. Si la longueur du paquet n'est pas un nombre entier de mots de 16 bits, le paquet est complété par un octet de zéro avant le calcul de la somme de contrôle. La somme de contrôle est considérée comme faisant partie de la procédure d'authentification du paquet ; pour certains types d'authentification, le calcul de la somme de contrôle est omis.
AuType
Identifie la procédure d'authentification à utiliser pour le paquet. L'authentification est discutée dans l'appendice D de la spécification. Consultez l'appendice D pour une liste des types d'authentification actuellement définis.
Authentication
Un champ de 64 bits destiné à être utilisé par le schéma d'authentification. Voir l'appendice D pour les détails.
A.3.2 Le paquet Hello (The Hello packet)
Les paquets Hello sont le type de paquet OSPF 1. Ces paquets sont envoyés périodiquement sur toutes les interfaces (y compris les liens virtuels) afin d'établir et de maintenir les relations de voisinage. De plus, les paquets Hello sont diffusés en multicast sur les réseaux physiques possédant une capacité multicast ou broadcast, permettant la découverte dynamique des routeurs voisins.
Tous les routeurs connectés à un réseau commun doivent se mettre d'accord sur certains paramètres (Network mask, HelloInterval et RouterDeadInterval). Ces paramètres sont inclus dans les paquets Hello, de sorte que des différences peuvent empêcher la formation de relations de voisinage. Une explication détaillée du traitement de réception des paquets Hello est présentée dans la section 10.5. L'envoi des paquets Hello est traité dans la section 9.5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network mask
Le masque de réseau associé à cette interface. Par exemple, si l'interface est connectée à un réseau de classe B dont le troisième octet est utilisé pour le sous-réseau, le masque de réseau est 0xffffff00.
Options
Les capacités optionnelles prises en charge par le routeur, telles que documentées dans la section A.2.
HelloInterval
Le nombre de secondes entre les paquets Hello de ce routeur.
Rtr Pri
La priorité de routeur (Router Priority) de ce routeur. Utilisée lors de l'élection du (Backup) Designated Router. Si elle est fixée à 0, le routeur ne sera pas éligible pour devenir (Backup) Designated Router.
RouterDeadInterval
Le nombre de secondes avant de déclarer un routeur silencieux hors service (down).
Designated Router
L'identité du Designated Router pour ce réseau, du point de vue du routeur émetteur. Le Designated Router est identifié ici par son adresse d'interface IP sur le réseau. Fixé à 0.0.0.0 s'il n'y a pas de Designated Router.
Backup Designated Router
L'identité du Backup Designated Router pour ce réseau, du point de vue du routeur émetteur. Le Backup Designated Router est identifié ici par son adresse d'interface IP sur le réseau. Fixé à 0.0.0.0 s'il n'y a pas de Backup Designated Router.
Neighbor
Les Router ID de chaque routeur dont des paquets Hello valides ont été récemment vus sur le réseau. Récemment signifie dans les dernières RouterDeadInterval secondes.
A.3.3 Le paquet Database Description (The Database Description packet)
Les paquets Database Description sont le type de paquet OSPF 2. Ces paquets sont échangés lorsqu'une adjacence (adjacency) est initialisée. Ils décrivent le contenu de la base de données link-state. Plusieurs paquets peuvent être utilisés pour décrire la base de données. À cette fin, une procédure de sondage-réponse (poll-response) est utilisée. L'un des routeurs est désigné comme maître (master), l'autre comme esclave (slave). Le maître envoie des paquets Database Description (sondages) qui sont acquittés par les paquets Database Description envoyés par l'esclave (réponses). Les réponses sont liées aux sondages via les numéros de séquence DD des paquets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Le format du paquet Database Description est très similaire à la fois au paquet Link State Request et au paquet Link State Acknowledgment. La partie principale des trois est une liste d'éléments, chaque élément décrivant une partie de la base de données link-state. L'envoi des paquets Database Description est documenté dans la section 10.8. La réception des paquets Database Description est documentée dans la section 10.6.
Interface MTU
La taille en octets du plus grand datagramme IP qui peut être envoyé sur l'interface associée, sans fragmentation. Les MTU des types de liaison Internet courants se trouvent dans la Table 7-1 de [Ref22]. Interface MTU doit être fixé à 0 dans les paquets Database Description envoyés sur des liens virtuels.
Options
Les capacités optionnelles prises en charge par le routeur, telles que documentées dans la section A.2.
I-bit
Le bit Init. Lorsqu'il est fixé à 1, ce paquet est le premier de la séquence de paquets Database Description.
M-bit
Le bit More. Lorsqu'il est fixé à 1, il indique que d'autres paquets Database Description suivront.
MS-bit
Le bit Master/Slave. Lorsqu'il est fixé à 1, il indique que le routeur est le maître pendant le processus d'échange de base de données (Database Exchange). Sinon, le routeur est l'esclave.
DD sequence number
Utilisé pour séquencer l'ensemble des paquets Database Description. La valeur initiale (indiquée par le bit Init fixé) doit être unique. Le numéro de séquence DD s'incrémente ensuite jusqu'à ce que la description complète de la base de données ait été envoyée.
Le reste du paquet consiste en une liste (éventuellement partielle) des éléments de la base de données link-state. Chaque LSA de la base de données est décrit par son en-tête LSA. L'en-tête LSA est documenté dans la section A.4.1. Il contient toutes les informations requises pour identifier de manière unique à la fois le LSA et l'instance actuelle du LSA.
A.3.4 Le paquet Link State Request (The Link State Request packet)
Les paquets Link State Request sont le type de paquet OSPF 3. Après avoir échangé des paquets Database Description avec un routeur voisin, un routeur peut constater que des parties de sa base de données link-state ne sont pas à jour. Le paquet Link State Request est utilisé pour demander les éléments de la base de données du voisin qui sont plus récents. Plusieurs paquets Link State Request peuvent devoir être utilisés.
Un routeur qui envoie un paquet Link State Request a à l'esprit l'instance précise des éléments de la base de données qu'il demande. Chaque instance est définie par son numéro de séquence LS, sa somme de contrôle LS et son âge LS, bien que ces champs ne soient pas spécifiés dans le paquet Link State Request lui-même. Le routeur peut recevoir en réponse des instances encore plus récentes.
L'envoi des paquets Link State Request est documenté dans la section 10.9. La réception des paquets Link State Request est documentée dans la section 10.7.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Chaque LSA demandé est spécifié par son LS type, son Link State ID et son Advertising Router. Cela identifie de manière unique le LSA, mais pas son instance. Les paquets Link State Request sont compris comme des demandes de l'instance la plus récente (quelle qu'elle soit).
A.3.5 Le paquet Link State Update (The Link State Update packet)
Les paquets Link State Update sont le type de paquet OSPF 4. Ces paquets implémentent l'inondation (flooding) des LSA. Chaque paquet Link State Update transporte un ensemble de LSA un saut plus loin à partir de leur origine. Plusieurs LSA peuvent être inclus dans un seul paquet.
Les paquets Link State Update sont diffusés en multicast sur les réseaux physiques qui prennent en charge le multicast/broadcast. Pour rendre la procédure de flooding fiable, les LSA inondés sont acquittés dans des paquets Link State Acknowledgment. Si la retransmission de certains LSA est nécessaire, les LSA retransmis sont toujours envoyés directement au voisin. Pour plus d'informations sur l'inondation fiable des LSA, consultez la section 13.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
# LSAs
Le nombre de LSA inclus dans cette mise à jour.
Le corps du paquet Link State Update consiste en une liste de LSA. Chaque LSA commence par un en-tête commun de 20 octets, décrit dans la section A.4.1. Les formats détaillés des différents types de LSA sont décrits dans la section A.4.
A.3.6 Le paquet Link State Acknowledgment (The Link State Acknowledgment packet)
Les paquets Link State Acknowledgment sont le type de paquet OSPF 5. Pour rendre l'inondation des LSA fiable, les LSA inondés sont explicitement acquittés. Cet accusé de réception est accompli via l'envoi et la réception de paquets Link State Acknowledgment. Plusieurs LSA peuvent être acquittés dans un seul paquet Link State Acknowledgment.
Selon l'état de l'interface d'envoi et l'émetteur du paquet Link State Update correspondant, un paquet Link State Acknowledgment est envoyé soit à l'adresse multicast AllSPFRouters, soit à l'adresse multicast AllDRouters, soit en unicast. L'envoi des paquets Link State Acknowledgment est documenté dans la section 13.5. La réception des paquets Link State Acknowledgment est documentée dans la section 13.7.
Le format de ce paquet est similaire à celui du paquet Data Description. Le corps des deux paquets est simplement une liste d'en-têtes LSA.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 5 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Chaque LSA acquitté est décrit par son en-tête LSA. L'en-tête LSA est documenté dans la section A.4.1. Il contient toutes les informations requises pour identifier de manière unique à la fois le LSA et l'instance actuelle du LSA.