Groupe de travail Réseau |
R. Callon, Digital Equipment Corporation |
Request for Comments : 1195 |
décembre 1990 |
Catégorie : En cours de normalisation |
Traduction Claude Brière de L'Isle |
Utilisation de l'IS-IS de l'OSI pour l'acheminement dans les environnements TCP/IP et duels
Statut de ce mémoire
La présente RFC spécifie un protocole en cours de normalisation auprès de l'IAB pour la communauté de l'Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l'édition actuelle des "Normes officielles de protocoles de l'IAB" pour voir l'état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.
Cette RFC est disponible en version postscript et text. Lorsque c'est possible, il est recommandé d'utiliser la version postscript. Par exemple, les figures de la version text contiennent moins d'information ou manquent.
Résumé
Le présente RFC spécifie un protocole d'acheminement intégré, fondé sur le protocole d'acheminement IS-IS intra domaine de l'OSI, qui peut être utilisé comme un protocole de routeur intérieur (IGP, interior gateway protocol) pour la prise en charge de TCP/IP aussi bien que d'OSI. Cela permet d'utiliser un seul protocole d'acheminement pour la prise en charge d'environnements IP purs, d'environnements OSI purs, et d'environnements duels. La présente spécification a été développée par le groupe de travail IS-IS de l'IETF.
Le protocole OSI IS-IS a atteint un état de maturité, et il est prêt pour la mise en œuvre et une utilisation opérationnelle. La plus récente version du protocole OSI IS-IS est contenue dans le DP 10589 [1] de l'ISO. La norme proposée à l'utilisation de IS-IS pour la prise en charge de TCP/IP utilisera donc cette version (avec quelques corrections de fautes mineures, comme exposé à l'Annexe B). On pense que de futures versions de cette proposition de norme sera mise à niveau avec la version finale de la norme internationale de IS-IS lorsqu'elle sera disponible.
Les commentaires sont à envoyer à "isis@merit.edu".
Table des Matières
1 Introduction : vue générale du protocole
1.2 Généralités sur le protocole ISO IS-IS
1.3 Généralités sur IS-IS intégré
1.4 Prise en charge des domaines d'acheminement mixtes
1.5 Avantages de l'utilisation de IS-IS intégré
3 Fonctions indépendantes du sous-réseau
3.1 Échange d'informations d'acheminement
3.2 Abréviation hiérarchisée des informations d'accessibilité IP
3.3 Adressage des routeurs dans les paquets IS-IS
3.5 Acheminement du type de service
3.10 Calcul de Dijkstra de l'ordre de préférence des routes
3.10.1 Ordre de préférence des chemins dans l'acheminement de niveau 1
3.10.2 Ordre de préférence des chemins dans l'acheminement de niveau 2
4 Fonctions dépendantes du sous-réseau
4.2 Adresses IP multiples par interface
4.3 LAN, routeurs désignés, et pseudo nœuds
4.4 Maintenance des adjacences de routeurs
4.5 Transmission à des routeurs incompatibles
5.1 Généralités sur les PDU IS-IS
5.2 Généralités sur les informations spécifiques d'IP pour IS-IS
5.3 Codage des champs spécifiques dans les PDU IS-IS
5.3.1 PDU Hello d'IS à IS de LAN de niveau 1
5.3.2 PDU Hello d'IS à IS de LAN de niveau 2
5.3.3 PDU de Hello IS à IS en point à point
5.3.4 PDU d'état de liaison de niveau 1
5.3.5 PDU d'état de liaison de niveau 2
5.3.6 PDU de numéros de séquence complète de niveau 1
5.3.7 PDU de numéros de séquence complète de niveau 2
5.3.8 PDU de numéros de séquence partielle de niveau 1
5.3.9 PDU de numéros de séquence partielle de niveau 2
6 Considérations pour la sécurité
Annexe A Informations de protocole d'acheminement inter-domaine
A.1 Type d'informations inter-domaine
Annexe B Codage des paquets de numéro de séquence
B.1 PDU de numéro de séquence complet de niveau 1
B.2 PDU de numéro de séquence complet de niveau 2
B.3 PDU de numéro de séquence partiel de niveau 1
B.4 PDU de numéro de séquence partiel de niveau 2
Annexe C Calcul de Dijkstra et transmission
C.1 Algorithme SPF pour IP et utilisation duelle
C.1.2 Utilisation des métriques dans l'algorithme SPF
C.1.3 Vue d'ensemble de l'algorithme
C.2 Transmission des paquets IP
C.2.1 Méthode de base de transmission des paquets IP
C.2.2 Réduction des bases de données de transmission IP
Annexe D Utilisation du champ d'authentification
D.1 Le champ d'authentification dans les paquets IS-IS
D.2 Authentification de type 1 - simple mot de passe
Annexe E Interaction de IS-IS intégré avec les brouteurs
E.2.1 Brouteur plus sophistiqués
1 Introduction : vue générale du protocole
La suite des protocoles TCP/IP a vu son importance croître comme architecture de communications multi fabricants. Avec l'anticipation de l'émergence de l'OSI, on espère que la coexistence de TCP/IP et d'OSI continuera pendant longtemps. Il y a un besoin urgent que les routeurs prennent en charge en parallèle à la fois le trafic et le trafic OSI.
Il y a deux principales méthodes disponibles pour que les protocoles d'acheminement prennent en charge les routeurs duels OSI et IP. Une méthode, connue sous le nom de "navires dans la nuit", fait usage de protocoles d'acheminement complètement indépendants pour chacune des deux suites de protocole. La présente spécification utilise une autre approche, qui fait usage d'un seul protocole intégré pour l'acheminement intérieur (c'est-à-dire, pour calculer les chemins au sein d'un domaine d'acheminement) pour les deux suites de protocole.
Ce concept de protocole intégré se fonde sur le protocole OSI d'acheminement intra-domaine IS-IS [1], avec l'ajout de fonctions spécifiques de IP. La présente RFC est considérée comme accompagnant la spécification de l'acheminement OSI IS-IS, et ne décrira donc que les caractéristiques additionnelles requises.
En prenant en charge à la fois le trafic IP et OSI, ce concept de protocole intégré prend en charge le trafic vers les hôtes IP, les systèmes d'extrémité OSI et les systèmes d'extrémité duels. Cette approche est "intégrée" au sens où le protocole IS-IS peut être utilisé pour prendre en charge de purs environnements IP, de purs environnements OSI, et des environnements duels. De plus, cette approche permet l'interconnexion de domaines d'acheminement duels (IP et OSI) avec d'autres domaines duels, avec des domaines IP seul, et avec des domaines OSI seul.
Le protocole spécifié ici se fonde sur les travaux du groupe IS-IS de l'IETF.
L'IS-IS intégré offre un seul protocole d'acheminement qui va fournir simultanément un protocole d'acheminement efficace pour TCP/IP, et pour OSI. Cette conception utilise le protocole d'acheminement OSI IS-IS, augmenté des informations spécifiques de IP. Elle fournit une prise en charge explicite du sous-réseautage IP, de gabarits variables de sous réseau, de l'acheminement fondé sur le TOS, et l'acheminement externe. Il y a des dispositions pour les informations d'authentification, y compris l'utilisation de mots de passe ou autres mécanismes. La forme précise des mécanismes d'authentification (autres que les mots de passe) sort du domaine d'application du présent document.
Les paquets aussi bien OSI que IP sont transmis "en l'état" – c'est-à-dire, ils sont transmis directement sur les services de couche de liaison sous-jacente sans qu'il soit besoin d'encapsulation mutuelle. L'IS-IS intégré est un protocole d'acheminement dynamique, fondé sur l'algorithme d'acheminement SPF (Dijkstra).
Le protocole décrit dans cette spécification permet le mélange de routeurs IP seuls, OSI seuls et duels (IP et OSI), comme défini ci-dessous.
Un routeur IS-IS IP seul (ou routeur "IP seul") est défini comme un routeur qui : (i) utilise IS-IS comme protocole d'acheminement pour IP, comme spécifié dans ces rapports ; et (ii) ne prend pas autrement en charge les protocoles OSI. Par exemple, de tels routeurs ne seront pas capables de transmettre de paquets CLNP OSI.
Un routeur OSI seul se définit comme un routeur qui utilise IS-IS comme protocole d'acheminement pour OSI, comme spécifié dans [1]. Généralement, les routeurs OSI seul peuvent être supposés se conformer aux normes OSI, et peuvent être mis en œuvre indépendamment de la présente spécification.
Un routeur IS-IS duel (ou routeur "duel") se définit comme un routeur qui utilise IS-IS comme seul protocole d'acheminement intégré à la fois pour IP et OSI, comme spécifié dans le présent rapport.
Cette approche ne change pas la façon dont les paquets IP sont traités. Les routeurs IP seul et duels sont obligés de se conformer aux exigences pour les routeurs Internet [4]. Le protocole IS-IS intégré décrit dans ce rapport se réfère à un protocole de routeur intérieur (IGP, Interior Gateway Protocol) qui fournira l'acheminement au sein d'un domaine d'acheminement TCP/IP (c'est-à-dire, un système autonome). Les autres aspects des fonctionnalités de routeur (par exemple, le fonctionnement d'ICMP, ARP, EGP, etc.) ne sont pas affectés par cette proposition.
De même, cette approche ne change pas la façon dont les paquets OSI sont traités. Il n'y aura aucun changement des contenus ni du traitement des paquets de données ISO 8473 et des rapports d'erreur, ni des Redirect ISO 9542 et des Hello ES. Les Hello IS d'ISO 9542 transmis sur des LAN sont aussi inchangés. Les Hello IS de ISO 9542 transmis sur des liaisons point à point sont inchangés sauf par l'ajout d'informations en rapport avec IP. De même, les autres paquets OSI (précisément ceux qui sont impliqués dans le protocole d'acheminement IS-IS intra-domaine) restent inchangés sauf par l'ajout d'informations se rapportant à IP.
Cette approche utilise les paquets IS-IS existants, avec l'ajout de champs spécifiques de IP. Précisément : (i) des informations d'authentification peuvent être ajoutées à tous les paquets IS-IS ; (ii) les protocoles pris en charge par chaque routeur, ainsi que les adresses IP de chaque routeur, sont spécifiées dans le Hello IS ISO 9542, le Hello IS-IS et les paquets d'état de liaison ; (iii) les adresses IP joignables en interne sont spécifiées dans tous les paquets d'état de liaison ; et (iv) les adresses IP joignables en externe, et les informations de protocole d'acheminement externe, peuvent être spécifiées dans les paquets d'état de liaison de niveau 2. Le codage et l'interprétation détaillée de ces informations sont spécifiés aux sections 3, 4, et 5 de la présente RFC.
Le protocole décrit dans ce rapport peut être utilisé pour fournir l'acheminement dans un domaine d'acheminement IP seul, dans lequel tous les routeurs sont IP seul. De même, ce protocole peut être utilisé pour fournir l'acheminement dans un domaine duel pur, dans lequel tous les routeurs sont duels. Finalement, ce protocole peut être utilisé pour fournir l'acheminement dans un domaine mixte dans lequel certains routeurs sont IP seul, certains routeurs sont OSI seul, et certains routeurs sont duels. Les restrictions topologiques spécifiques qui s'appliquent dans ce dernier cas sont décrites en détail au paragraphe 1.4 ("Prise en charge de domaines d'acheminement mixtes"). L'utilisation de IS-IS pour la prise en charge de domaines OSI purs est spécifiée dans [1].
Cette spécification de protocole ne constitue pas une contrainte pour les protocoles de gestion de réseau qui peuvent être utilisés pour gérer les routeurs fondés sur IS-IS. Les bases de données d'informations de gestion (MIB) pour la gestion des routeurs IP seul, OSI seul, et duels, compatibles avec CMIP, CMOT, et/ou SNMP, font l'objet d'un document séparé [8].
1.2 Généralités sur le protocole ISO IS-IS
Le protocole d'acheminement IS-IS a été développé dans l'ISO pour fournir l'acheminement dans des environnements OSI purs. En particulier, IS-IS est conçu pour travailler en conjonction avec ISO 8473 (le protocole ISO de couche réseau sans connexion [2]), et avec ISO 9542 (le protocole ISO de système d'extrémité à système intermédiaire [3]). Cette section décrit brièvement la manière dont IS-IS est utilisé pour prendre en charge des environnements OSI purs. Les améliorations pour prendre en charge des environnements IP et duels sont spécifiées ailleurs dans ce rapport.
Dans IS-IS, le réseau est partagé en "domaines d'acheminement". Les frontières des domaines d'acheminement sont définies par la gestion de réseau, en établissant certaines liaisons comme étant des "liaisons extérieures". Si une liaison est marquée comme "extérieure", aucun message d'acheminement IS-IS n'est envoyé sur cette liaison.
Actuellement, ISO n'a pas une norme similaire pour l'acheminement inter-domaine (c'est à dire, pour l'acheminement entre des domaines d'acheminement autonomes séparés).
À la place, on utilise une configuration manuelle. La liaison est configurée de façon statique avec l'ensemble des préfixes d'adresse joignables via cette liaison, et avec la méthode par laquelle ils peuvent être atteints (comme l'adresse du DTE à numéroter pour atteindre cette adresse, ou le fait que l'adresse du DTE devrait être extraite de la portion IDP de l'adresse ISO).
L'acheminement IS-IS OSI utilise un acheminement hiérarchique à deux niveaux. Un domaine d'acheminement est partagé en zones. Les routeurs de niveau 1 connaissent la topologie de leur zone, y compris tous les routeurs et systèmes d'extrémité de leur zone. Cependant, les routeurs de niveau 1 ne connaissent pas l'identité des routeurs ou destinations en dehors de leur zone. Les routeurs de niveau 1 transmettent tout le trafic pour les destinations en dehors de leur zone à un routeur de niveau 2 de leur zone. De même, les routeurs de niveau 2 connaissent la topologie de niveau 2, et connaissent les adresses qui sont joignables via chaque routeur de niveau 2. Cependant, les routeurs de niveau 2 n'ont pas besoin de connaître la topologie au sein d'une zone de niveau 1, sauf dans la mesure où un routeur de niveau 2 peut aussi être un routeur de niveau 1 au sein d'une seule zone. Seuls les routeurs de niveau 2 peuvent échanger des paquets de données ou des informations d'acheminement directement avec des routeurs externes localisés en dehors du domaine d'acheminement.
+----------------------+-------------------------------+
| IDP | DSP | ≤20 octets
+----------------------+-------------------------------+
. . .
. . .
. . .
+-----+----------------+----------+--------------+-----+
| AFI | IDI | HO-DSP | ID | SEL |
+-----+----------------+----------+--------------+-----+
1 ≤ 10 6 1
Figure 1 – Structure ISO d'adresse hiérarchique
Comme l'illustre la figure 1, les adresses ISO sont subdivisées en partie de domaine initiale (IDP, Initial Domain Part), et partie spécifique du domaine (DSP, Domain Specific Part). IDP est la partie qui est normalisée par l'ISO, et elle spécifie le format et l'autorité responsable de l'allocation du reste de l'adresse. La DSP est allouée par l'autorité d'adressage quelle qu'elle soit qui est spécifiée par l'IDP. La DSP est encore subdivisée en une "Partie d'ordre élevé de DSP" (HO-DSP), un identifiant de système (ID), et un sélecteur NSAP (SEL). La HO-DSP peut utiliser tout format désiré par l'autorité qui est identifiée par l'IDP. Ensemble, la combinaison de [IDP, HO-DSP] identifie à la fois le domaine d'acheminement et la zone au sein du domaine d'acheminement. La combinaison de [IDP,HO-DSP] peut donc être appelée "Adresse de zone".
Habituellement, tous les nœuds dans une zone ont la même adresse de zone. Cependant, une zone peut parfois avoir plusieurs adresses. Les motifs pour permettre cela sont que :
- Il peut être souhaitable de changer l'adresse d'une zone. La façon la plus douce de faire passer une zone de l'adresse A à l'adresse B est d'abord de lui permettre d'avoir les deux adresses A et B, et ensuite, une fois que tous les nœuds de la zone ont été modifiés pour reconnaître les deux adresses, les nœuds peuvent être modifiés un par un pour "oublier" l'adresse A.
- Il peut être souhaitable de fusionner les zones A et B en une seule zone. La méthode pour le faire est d'ajouter la connaissance de l'adresse B dans la partie A, nœud par nœud, et de même d'ajouter la connaissance de l'adresse A dans la partie B.
- Il peut être souhaitable de partager une zone C en deux zones, A et B (où "A" peut être égal à "C", auquel cas cet exemple devient celui du retrait d'une portion d'une zone). Cela serait réalisé en introduisant d'abord la connaissance de l'adresse A dans les nœuds appropriés (ceux qui sont destinés à devenir la zone A), et la connaissance de l'adresse B dans les nœuds appropriés, et puis de retirer alors nœud par nœud la connaissance de l'adresse C.
Comme l'adressage OSI identifie explicitement la zone, il est très facile aux routeurs de niveau 1 d'identifier les paquets qui vont à des destinations en dehors de leur zone, et qui ont besoin d'être transmis aux routeurs de niveau 2.
Dans IS-IS, il y a deux types de routeurs :
- Systèmes intermédiaires de niveau 1 -- ces nœuds acheminent sur la base de la portion ID de l'adresse ISO. Ils acheminent au sein d'une zone. Ils reconnaissent, sur la base de l'adresse de destination dans un paquet, si la destination est dans la zone. Si elle l'est, ils acheminent vers la destination. Sinon, ils acheminent sur le routeur de niveau 2 le plus proche.
- Systèmes intermédiaires de niveau 2 -- ces nœuds acheminent sur la base de l'adresse de zone (c'est-à-dire, sur la combinaison de [IDP, HO-DSP]). Ils acheminent vers des zones, sans considération de la structure interne d'une zone. Un IS de niveau 2 peut aussi être un IS de niveau 1 dans une zone.
Un routeur de niveau 1 aura la portion zone de son adresse configurée manuellement. Il refusera de devenir voisin avec les nœuds dont les adresses de zone ne se recouvrent pas avec les siennes. Cependant, si un routeur de niveau 1 a les adresses de zone A, B, et C, et si un voisin a les adresses de zone B et D, le routeur de niveau 1 acceptera alors l'autre nœud comme voisin.
Un routeur de niveau 2 acceptera un autre routeur de niveau 2 comme voisin, sans considération de l'adresse de zone. Cependant, si les adresses de zone ne se recouvrent pas, la liaison serait considérée par les deux routeurs comme étant de "niveau 2 seul", et seuls les LSP de niveau 2 s'écouleraient sur la liaison. Les liaisons externes (vers les autres domaines d'acheminement) doivent être à partir de routeurs de niveau 2.
IS-IS fournit une fonction facultative de réparation de partage. Dans le cas peu vraisemblable où une zone de niveau 1 serait partagée, cette fonction, si elle est mise en œuvre, permet que le partage soit réparé via l'utilisation de chemins de niveau 2.
IS-IS exige que l'ensemble des routeurs de niveau 2 soient connectés. Si le réseau dorsal de niveau 2 devait être partagé, il n'y a aucune disposition qui permette l'utilisation de liaisons de niveau 1 pour réparer une partition de niveau 2.
Dans des cas exceptionnels, un seul routeur de niveau 2 peut perdre la connexité au réseau dorsal de niveau 2. Dans ce cas, le routeur de niveau 2 indiquera dans son LSP de niveau 1 qu'il n'est pas "rattaché", permettant ainsi aux routeurs de niveau 1 dans la zone d'acheminer du trafic pour l'extérieur du domaine vers un routeur de niveau 2 différent. Les routeurs de niveau 1 acheminent donc le trafic pour des destinations en dehors de leur zone seulement aux routeurs de niveau 2 qui indiquent dans leurs LSP de niveau 1 qu'ils sont "rattachés".
Un système d'extrémité peut auto configurer la portion zone de son adresse en extrayant la portion zone de l'adresse d'un routeur voisin. Si c'est le cas, un nœud d'extrémité va toujours accepter un routeur comme voisin. Comme la norme ne spécifie pas que le système d'extrémité DOIT auto configurer son adresse de zone, un système d'extrémité peut être configuré avec une adresse de zone. Dans ce cas, le système d'extrémité va ignorer les routeurs voisins avec des adresses de zone qui ne correspondent pas.
Un traitement particulier est nécessaire pour les sous-réseaux de diffusion, tels que les LAN. Cela règle deux ensembles de questions : (i) En l'absence de traitement particulier, chaque routeur sur le sous-réseau va annoncer une liaison avec chaque autre routeur du sous-réseau, ce qui va donner le rapport d'un nombre de liaisons n au carré ; (ii) à nouveau, en l'absence de traitement particulier, chaque routeur sur le LAN rapporterait la même liste identique de systèmes d'extrémité sur le LAN, d'où résulterait une duplication substantielle.
On évite ces problèmes en utilisant un "pseudo-nœud", qui représente le LAN. Chaque routeur sur le LAN rapporte qu'il a une liaison avec le pseudo-nœud (plutôt que de rapporter une liaison avec chaque autre routeur sur le LAN). Un des routeurs sur le LAN est choisi comme "routeur désigné". Le routeur désigné envoie alors un LSP au nom du pseudo-nœud, faisant rapport des liaisons avec tous les routeurs sur le LAN. Cela réduit les n au carré liaisons potentielles à n liaisons. De plus, seul le LSP de pseudo-nœud inclut la liste des systèmes d'extrémité sur le LAN, éliminant ainsi la duplication potentielle (pour plus d'informations sur les routeurs désignés et les pseudo-nœuds, voir [1]).
IS-IS prend en compte la faculté de l'acheminement en fonction de la qualité de service (QS), sur la base du débit (la métrique par défaut), le délai, le coût, ou la probabilité d'erreur résiduelle. Ceci est décrit en plus grand détail au paragraphe 3.5, et dans [1].
1.3 Généralités sur IS-IS intégré
IS-IS intégré permet d'utiliser un seul protocole d'acheminement pour acheminer aussi bien les paquets IP que OSI. Cela implique que la même hiérarchie à deux niveaux sera utilisée pour les deux acheminements IP et OSI. Chaque zone sera spécifiée comme étant soit IP seul (seul le trafic IP peut être acheminé dans cette zone particulière), OSI seul (seul le trafic OSI peut être acheminé dans cette zone), ou duel (les deux trafics, IP et OSI, peuvent être acheminés dans la zone).
Cette proposition ne permet pas de recouvrement partiel de zone OSI et IP. Par exemple, si une zone est OSI seul, et si une autre zone est IP seul, il n'est alors pas permis d'avoir des routeurs qui soient dans les deux zones. De même, un seul réseau dorsal est utilisé pour le domaine d'acheminement. Il n'y a aucune disposition pour des réseaux dorsaux OSI et IP indépendants.
De même, au sein d'une zone IP seul ou duelle, la quantité de connaissances conservées par les routeurs sur les destinations IP spécifiques sera aussi similaire que possible à celles sur OSI. Par exemple, les routeurs de niveau 1 à capacité IP maintiendront la topologie au sein de la zone, et seront capables d'acheminer directement sur les destinations IP au sein de la zone. Cependant, les routeurs de niveau 1 à capacité IP ne conserveront pas les informations sur les destinations en dehors de la zone. Comme dans l'acheminement OSI normal, le trafic pour des destinations en dehors de la zone sera transmis au plus proche routeur de niveau 2. Comme IP achemine sur des sous-réseaux, plutôt que sur des systèmes d'extrémité spécifiques, les routeurs IP n'auront pas besoin de conserver ni de distribuer des listes d'identifiants d'hôtes IP (noter que les chemins pour les hôtes peuvent être annoncés en utilisant un gabarit de sous-réseau tout de uns).
La structure de l'adresse IP permet que les réseaux soient partagés en sous-réseaux, et aux sous-réseaux d'être à leur tour subdivisés en sous-réseaux plus petits. Cependant, il n'est pas désirable d'exiger de relations spécifiques entre les adresses de sous-réseau IP et les zones IS-IS. Par exemple, dans de nombreux cas, les routeurs duels peuvent être installés dans des environnements préexistants qui ont déjà des adresses IP et/ou OSI allouées. De plus, même si les adresses IP ne sont pas déjà pré allouées, les limitations d'adresse de IP constituent une contrainte sur les adresses qui peuvent être allouées. Nous n'exigerons donc aucune relation spécifique entre les adresses IP et la structure de zone. Les adresses IP peuvent être allouées de façon complètement indépendante des adresses OSI et de la structure de zone IS-IS. Comme ce sera décrit au paragraphe 3.2 ("Abréviation hiérarchique des informations d'accessibilité IP"), on peut atteindre une plus grande efficacité et une meilleure gestion de l'échelonnement de l'algorithme d'acheminement si il y a une certaine correspondance entre la structure d'allocation d'adresse IP et la structure des zones.
Au sein d'une zone, les routeurs de niveau 1 échangent des paquets d'état de liaison qui identifient les adresses IP accessibles par chaque routeur. Précisément, zéro, une ou plusieurs combinaisons de [adresse IP, gabarit de sous-réseau, métrique] peuvent être incluses dans chaque paquet d'état de liaison. Chaque routeur de niveau 1 est configuré manuellement avec les combinaisons de [adresse IP, gabarit de sous-réseau, métrique] qui sont accessibles sur chaque interface. Un routeur de niveau 1 achemine comme suit :
- Si une adresse de destination spécifiée correspond à une combinaison [adresse IP, gabarit de sous-réseau, métrique] accessible au sein de la zone, le paquet est acheminé via un acheminement de niveau 1.
- Si une adresse de destination spécifiée ne correspond à aucune des combinaisons [adresse IP, gabarit de sous-réseau, métrique] énumérées comme accessibles au sein de la zone, le paquet est acheminé vers le plus proche routeur de niveau 2.
Une utilisation souple de l'espace limité des adresses IP est importante afin de tenir compte de la croissance prévue des environnements IP. Et donc, une zone (et par conséquent un domaine d'acheminement) peut simultanément utiliser divers gabarits d'adresse différents pour différents sous-réseaux dans la zone (ou le domaine). Généralement, si une adresse de destination spécifiée correspond à plus d'une paire [adresse IP, gabarit de sous-réseau], l'adresse la plus spécifique est celle sur laquelle sera fait l'acheminement (celle avec le plus de bits "1" dans le gabarit – ceci est connu sous le nom d'acheminement "à la meilleure correspondance").
Les routeurs de niveau 2 comportent dans leurs LSP de niveau 2 une liste complète de [adresse IP, gabarit de sous-réseau, métrique] qui spécifie toutes les adresses IP accessibles dans leur zone. Comme décrit à la section 3, ces informations peuvent être obtenues à partir d'une combinaison de LSP de niveau 1 (obtenus des routeurs de niveau 1 de la même zone), et/ou par configuration manuelle. De plus, les routeurs de niveau 2 peuvent rapporter les informations d'accessibilité externe, correspondant aux adresses qui peuvent être jointes via des routeurs dans d'autres domaines d'acheminement (systèmes autonomes).
Les chemins par défaut peuvent être annoncés en utilisant un gabarit de sous-réseau contenant tous les bits à zéro. Les chemins par défaut devraient être utilisés avec de grandes précautions, car il peut en résulter des "trous noirs". Les chemins par défaut ne sont permis qu'au niveau 2 comme chemins externes (c'est-à-dire, inclus dans le champ "Informations IP d'accessibilité externe", comme expliqué aux sections 3 et 5). Les chemins par défaut ne sont pas permis au niveau 1.
IS-IS intégré permet un acheminement par type de service (TOS) facultatif, à travers l'utilisation du dispositif de qualité de service provenant de IS-IS.
1.4 Prise en charge des domaines d'acheminement mixtes
La proposition de IS-IS intégré permet spécifiquement trois types de domaines d'acheminement :
- IP pur
- OSI pur
- Duel
Dans un domaine d'acheminement IP pur, tous les routeurs doivent être à capacité IP. Les routeurs IP seul peuvent être librement mélangés avec des routeurs duels. Certains champs spécifiquement en rapport avec le fonctionnement OSI peuvent être inclus par les routeurs duels, et seront ignoré des routeurs IP seul. Seul le trafic IP sera acheminé dans un domaine IP pur. Tout trafic OSI peut être éliminé (sauf les paquets IS-IS nécessaires au fonctionnement du protocole d'acheminement).
Dans un domaine d'acheminement OSI pur, tous les routeurs doivent être à capacité OSI. Les routeurs OSI seul peuvent être librement mélangés aux routeurs duels. Certains champs spécifiquement en rapport avec le fonctionnement IP peuvent être inclus par les routeurs duels, et seront ignorés par les routeurs OSI seul. Le trafic OSI seul sera acheminé dans un domaine OSI pur. Tout trafic IP peut être éliminé.
Dans un domaine d'acheminement dual, les routeurs IP seul, OSI seul, et duels peuvent être mélangés zone par zone. Précisément, chaque zone peut elle-même être définie comme étant IP pur, OSI pur, ou duelle.
Dans une zone IP pur au sein d'un domaine duel, les routeurs IP seul et duels peuvent être librement mélangés. Le trafic IP seul peut être acheminé par l'acheminement de niveau 1 au sein d'une zone IP pur.
Dans une zone OSI pur au sein d'un domaine duel, les routeurs OSI seul et les routeurs duels peuvent être librement mélangés. Le trafic OSI seul peut être acheminé par l'acheminement de niveau 1 au sein d'une zone OSI pur.
Dans une zone duelle au sein d'un domaine d'acheminement duel, seuls des routeurs duels peuvent être utilisés. Les deux trafics IP et OSI peuvent être acheminés au sein d'une zone duelle.
Au sein d'un domaine duel, si les deux trafics IP et OSI sont à acheminer entre les zones, tous les routeurs de niveau 2 doivent alors être duels.
1.5 Avantages de l'utilisation de IS-IS intégré
L'utilisation du protocole IS-IS intégré, comme seul protocole pour l'acheminement des paquets aussi bien IP qu'OSI dans un environnement duel, a des avantages significatifs sur l'utilisation de protocoles distincts pour un acheminement indépendant des trafics IP et OSI.
Une autre approche est connue sous le nom de "Vaisseaux dans la nuit" (SIN, Ships In the Night). Avec l'approche S.I.N., on utilise des protocoles d'acheminement complètement distincts pour IP et pour OSI. Par exemple, OSPF [5] peut être utilisé pour acheminer le trafic IP, et IS-IS [1] pour acheminer le trafic OSI. Avec S.I.N., les deux protocoles d'acheminement fonctionnent de façon plus ou moins indépendante. Cependant, les routeurs duels auront besoin de mettre en œuvre les deux protocoles d'acheminement, et donc il y aura une certaine forme de compétition pour les ressources.
Noter que S.I.N. et l'approche IS-IS intégrée ne sont pas des options réellement complètement distinctes. En particulier, si l'IS-IS intégré est utilisé au sein d'un domaine d'acheminement pour acheminer du trafic IP et OSI, il est encore possible d'utiliser d'autres protocoles d'acheminement indépendants pour acheminer d'autres suites de protocoles.
À l'avenir, des extensions facultatives à IS-IS peuvent être définies pour l'acheminement d'autres suites de protocole courantes. Cependant, de telles options futures sortent du domaine d'application du présent document. Cette section va comparer IS-IS intégré et S.I.N. pour l'acheminement de trafic IP et OSI seuls.
Le principal avantage de IS-IS intégré se rapporte à l'effort de gestion de réseau requis. Comme IS-IS intégré fournit un seul protocole d'acheminement, au sein d'un seul domaine d'acheminement coordonné utilisant un seul cœur de réseau, cela implique qu'il y a moins d'informations à configurer. Cela, combiné dans une seule MIB coordonnée, simplifie la gestion de réseau.
Noter que le fonctionnement de deux protocoles d'acheminement avec l'approche S.I.N. n'est pas réellement indépendant, car ils doivent partager des ressources communes. Cependant, avec IS-IS intégré, les interactions sont explicites, tandis qu'avec S.I.N., les interactions sont implicites. Comme les interactions sont explicites, il peut être encore plus facile de gérer et déboguer les routeurs duels.
Un autre avantage de IS-IS intégré est que, dans la mesure où il n'exige qu'un seul protocole d'acheminement, il utilise moins de ressources. En particulier, moins de ressources de mise en œuvre sont nécessaires (car il n'est nécessaire de mettre en œuvre qu'un seul protocole), moins de CPU et de ressources mémoire sont utilisées dans le routeur (car un seul protocole doit fonctionner), et moins de ressources réseau sont utilisées (car un seul ensemble de paquets d'acheminement doit être transmis). Cela se traduit principalement par des économies financières, car chacun de ces trois types de ressources coûte de l'argent. Cela implique que les routeurs duels fondés sur IS-IS intégré devraient être moins coûteux à l'achat et en fonctionnement que les routeurs duels fondés sur S.I.N.
Noter que le fonctionnement de deux protocoles d'acheminement avec l'approche S.I.N. n'est pas réellement indépendant, car ils doivent partager des ressources communes. Par exemple, si un des protocoles d'acheminement devient instable et commence à utiliser des ressources excessives, l'autre protocole va vraisemblablement souffrir. Une erreur dans un des protocoles pourrait provoquer une défaillance de l'autre. Cependant, avec IS-IS intégré, les interactions sont explicites et sont définies dans les interactions de protocole et de logiciel. Avec S.I.N., les interactions sont implicites.
L'utilisation d'un seul protocole d'acheminement intégré réduit de façon similaire la fréquence probable de remises à niveau de logiciel. Précisément, si vous avez deux protocoles d'acheminement différents dans votre routeur, vous devez alors mettre à niveau le logiciel chaque fois que l'un ou l'autre des protocoles change. Si vous n'utilisez qu'un seul protocole d'acheminement intégré, les changements de logiciel seront alors encore nécessaires, mais vraisemblablement moins fréquemment.
Finalement, les protocoles d'acheminement ont des exigences de temps réel significatives. Dans IS-IS, ces exigences de temps réel ont été spécifiées explicitement. Dans d'autres protocoles d'acheminement, ces exigences sont implicites. Cependant, dans tous les protocoles d'acheminement, il y a des garanties de temps réel qui doivent être satisfaites afin de s'assurer d'un fonctionnement correct. En général, il est assez difficile d'assurer la conformité aux exigences de temps réel dans la mise en œuvre d'un seul système en temps réel. Avec S.I.N., la mise en œuvre de deux protocoles en temps réel semi indépendants dans un seul appareil rend cela encore plus difficile.
Noter que IS-IS intégré et S.I.N. permettent tous deux l'indépendance de chemins externes (pour le trafic de/vers l'extérieur du domaine d'acheminement), et permettent l'allocation indépendante d'adresses OSI et TCP/IP.
AA : autorité administrative (un champ de trois octets dans le format d'adresse NSAP GOSIP version 2.0)
AFI : identifiant d'autorité et de format (le premier octet de toutes les adresses NSAP OSI – identifie le format du reste de l'adresse)
CLNP : protocole de réseau sans connexion (Connection-Less Network Protocol) de la norme ISO 8473 (c'est le protocole OSI de couche réseau sans connexion -- très semblable à IP)
DFI : identifiant de format DSP (un champ d'un octet dans le format d'adresse NSAP de GOSIP version 2.0)
ES : système d'extrémité (End System) (Le terme OSI pour un hôte)
ES-IS : protocole d'échange d'informations d'acheminement de système d'extrémité à système intermédiaire (End System to Intermediate System) de la norme ISO 9542 – le protocole OSI entre routeurs et systèmes d'extrémité)
ICD : désignateur de code international (norme ISO pour identifier les organisations)
IP : protocole inter réseau (norme de protocole de couche réseau de l'Internet)
IS : système intermédiaire (terme OSI pour un routeur)
IS-IS : protocole d'échange d'informations d'acheminement de système intermédiaire à système intermédiaire (le protocole ISO pour l'acheminement au sein d'un seul domaine d'acheminement)
IS-IS Hello : paquet Hello défini par le protocole IS-IS (un type de paquet utilisé par le protocole IS-IS)
ISH : paquet Hello défini par la norme ISO 9542 (protocole ES-IS). (différent de IS-IS Hello)
ISO : Organisation internationale de normalisation (institution internationale qui a autorité pour créer des normes dans de nombreux domaines)
LSP : paquet d'état de liaison (Link State Packet) (type de paquet utilisé par le protocole IS-IS)
NLPID : identifiant de protocole de couche réseau (Network Layer Protocol ID) (champ d'un octet qui identifie un protocole de couche réseau)
NSAP : point d'accès de service réseau (Network Service Access Point) (point d'interface conceptuel auquel est disponible le service réseau)
SEL : sélecteur NSAP (le dernier octet des adresses NSAP, aussi appelé NSEL)
OSI : interconnexion des systèmes ouverts (Open Systems Interconnection) (norme internationale d'architecture de protocoles)
RD : domaine d'acheminement (Routing Domain) (ensemble des routeurs et des systèmes d'extrémité qui utilisent une seule instance d'un protocole d'acheminement tel que IS-IS)
SNPA : point de rattachement à un sous-réseau (Subnetwork Point of Attachment) (interface conceptuelle à laquelle est fourni un service de sous-réseau)
TCP : protocole de contrôle de transmission (Transmission Control Protocol) (norme Internet du protocole de couche Transport)
TCP/IP : suite de protocoles fondée sur TCP et IP, et les protocoles qui s'y rapportent (norme Internet d'architecture de protocoles)
3 Fonctions indépendantes du sous-réseau
3.1 Échange d'informations d'acheminement
L'échange des informations d'acheminement entre les routeurs utilise l'échange normal de paquet d'acheminement comme défini dans la spécification OSI d'acheminement IS-IS, avec des informations additionnelles spécifiques de IP ajoutées aux paquets d'acheminement IS-IS.
Le protocole IS-IS procure l'inclusion de champs de longueur variable dans tous les paquets IS-IS. Ces champs sont codés en utilisant un triplet "Code, Longueur, Valeur", où le code et la longueur sont codés sur un octet chacun, et la valeur a la longueur spécifiée (de 0 à 254 octets). IS-IS exige que : "Tous les codes dans une PDU reçue qui ne sont pas reconnus sont ignorés et passés inchangés". Cette exigence s'applique à tous les routeurs qui mettent en œuvre IS-IS, y compris OSI-seul, IP-seul, et les routeurs duels. Cela permet que les informations spécifiques de IP soient codées d'une manière que les routeurs OSI-seul vont ignorer, et permet aussi que les informations spécifiques de OSI soient codées d'une manière que les routeurs IP seul vont ignorer.
Les routeurs à capacité IP (c'est-à-dire, IP-seul et duels) ont besoin de savoir quels protocoles de couche réseau sont pris en charge par les autres routeurs dans leur zone. Ces informations sont rendues disponibles par l'inclusion d'un champ "protocoles pris en charge" dans tous les paquets IS-IS Hello et d'état de liaison. Ce champ fait usage du NLPID (Identifiant de protocole de couche réseau), qui est une valeur de un octet allouée par l'ISO pour identifier les protocoles de niveau réseau. Des valeurs de NLPID ont été allouées à ISO 8473 et à IP. Les routeurs à capacité IP ont besoin de savoir l'adresse IP de l'interface adjacente des routeurs voisins. Cela est exigé pour l'envoi des redirections ICMP (lorsque un routeur à capacité IP envoie une redirection ICMP à un hôte, il doit inclure l'adresse IP de l'interface appropriée du routeur de prochain bond correct). Ces informations sont rendues disponibles par l'inclusion de l'adresse IP de l'interface dans les paquets Hello IS-IS. Précisément, chaque paquet Hello IS-IS contient la ou les adresses IP de l'interface sur laquelle le Hello est transmis. IS-IS permet que plusieurs adresses IP soient allouées à chaque interface physique.
Dans certains cas, il sera utile que les routeurs à capacité IP soient capables de déterminer la ou les adresses IP de tous les autres routeurs à leur niveau (c'est-à-dire, pour les routeurs de niveau 1, tous les autres routeurs de leur zone ; pour les routeurs de niveau 2, tous les autres routeurs de niveau 2 dans le domaine d'acheminement). Ceci est utile chaque fois qu'un paquet IP est à envoyer à un routeur, soit pour encapsulation soit pour transmission de paquets de gestion de réseau. Ces informations sont rendues disponibles par l'inclusion de l'adresse IP dans les LSP. Précisément, chaque LSP IS-IS comporte une ou plusieurs adresses IP du routeur qui transmet le LSP. Un routeur à capacité IP est obligé d'inclure au moins une de ses adresses IP dans ses LSP, et peut facultativement inclure plusieurs de ses adresses IP ou toutes. Lorsque un seul routeur fonctionne à la fois comme routeur de niveau 1 et comme routeur de niveau 2, il est obligé d'inclure la ou les mêmes adresses IP dans ses LSP de niveau 1 et de niveau 2.
Les routeurs à capacité IP ont besoin de savoir, pour toute adresse IP de destination donnée, le chemin correct pour cette destination. Précisément, les routeurs de niveau 1 ont besoin de savoir quelles adresses IP sont joignables à partir de chaque routeur de niveau 1 dans leur zone. De plus, les routeurs de niveau 1 ont besoin de trouver des routeurs de niveau 2 (pour le trafic à des adresses IP en dehors de leur zone). Les routeurs de niveau 2 ont besoin de savoir quelles adresses IP sont joignables en interne (soit directement, soit via un acheminement de niveau 1) à partir des autres routeurs de niveau 2, et quelles adresses sont joignables en externe à partir des autres routeurs de niveau 2. Toutes ces informations sont rendues disponibles par l'inclusion des informations sur les adresses IP joignables dans les paquets d'état de liaison.
Les informations d'accessibilité interne (au sein du domaine d'acheminement) et externes (en dehors du domaine) sont annoncées séparément dans les LSP de niveau 2. Les adresses IP joignables incluent une métrique par défaut, et peuvent inclure plusieurs métriques spécifiques du type de service (TOS). En général, pour les chemins externes, les métriques peuvent être du type "interne" (c'est-à-dire, directement comparable aux métriques internes) ou du type "externe" (c'est-à-dire, non comparable à la métrique interne). Un chemin qui utilise des métriques internes (c'est-à-dire, soit annoncées comme "informations d'accessibilité internes IP", soit annoncées comme "informations d'accessibilité externes IP" avec une métrique interne) est toujours préféré à un chemin qui utilise des métriques externes (c'est-à-dire, annoncé comme "informations d'accessibilité externes IP", avec une métrique externe).
Le codage détaillé des informations spécifiques de IP incluses dans les paquets d'acheminement est fourni à la section 5 "Structure et codage des PDU".
3.2 Abréviation hiérarchisée des informations d'accessibilité IP
Les routeurs de niveau 2 comportent dans leurs LSP de niveau 2 une liste de toutes les combinaisons [adresse IP, gabarit de sous-réseau, métrique] joignables dans leur zone. En général, ces informations peuvent être déterminées à partir des LSP de niveau 1 provenant de tous les routeurs dans la zone. Si on ignore les contraintes de ressource, il serait alors permis à un routeur de niveau 2 de simplement dupliquer toutes les entrées [adresse IP, gabarit de sous-réseau, métrique] provenant de tous les routeurs de niveau 1 dans sa zone (avec l'ajustement de métrique approprié), pour les inclure dans son LSP de niveau 2. Cependant, pour que l'acheminement hiérarchique s'adapte aux tailles de grands domaines d'acheminement, il est très souhaitable d'abréger les informations d'adresses joignables.
Ceci est accompli par la configuration manuelle d'adresses résumées. Chaque routeur de niveau 2 peut être configuré avec une ou plusieurs entrées [adresse IP, gabarit de sous-réseau, métrique] pour les annoncer dans ses LSP de niveau 2.
L'ensemble des adresses joignables obtenues des LSP de niveau 1 est comparé aux adresses joignables configurées. Les informations redondantes obtenues des LSP de niveau 1 ne sont pas incluses dans les LSP de niveau 2. On s'attend généralement à ce que les informations configurées de niveau 2 spécifient des adresses plus inclusives (correspondant à un gabarit de sous-réseau avec moins de bits mis à 1). Cela va donc permettre à une paire adresse/gabarit configurée (ou un petit nombre de telles paires) de supplanter hiérarchiquement les informations correspondant à plusieurs entrées dans les LSP de niveau 1.
Les adresses configurées manuellement ne sont incluses dans les LSP de niveau 2 que si elles correspondent à au moins une adresse accessible dans la zone. Pour les adresses de niveau 2 configurées manuellement, les valeurs de métrique associées à annoncer dans les LSP de niveau 2 sont aussi configurées manuellement. Les adresses configurées ne vont supplanter que les entrées d'adresse accessible provenant des LSP de niveau 1 fondées sur les valeurs de métrique d'adresse IP et gabarit de sous-réseau qui ne sont pas prises en compte lors de la détermination qu'une adresse configurée donnée supplante une adresse obtenue d'un LSP de niveau 1.
Toute adresse obtenue d'un LSP de niveau 1 qui n'est pas supplantée par les informations configurées manuellement est incluse dans les LSP de niveau 2. Dans ce cas, la valeur de métrique annoncée dans les LSP de niveau 2 est calculée à partir de la somme de la valeur de métrique annoncée dans le LSP de niveau 1 correspondant, plus la distance du routeur de niveau 2 au routeur de niveau 1 approprié. Note : Si cette somme résulte en une valeur de métrique supérieure à 63 (valeur maximum qui puisse être rapportée dans les LSP de niveau 2), la valeur 63 doit alors être utilisée. Les métriques de délai, coût, et erreur (c'est-à-dire, les métriques de TOS autres que la métrique par défaut) ne seront incluses que si (i) le routeur de niveau 2 prend en charge le TOS spécifique ; (ii) le chemin du routeur de niveau 2 au routeur de niveau 1 approprié est constitué de liaisons qui acceptent le TOS spécifique ; et (iii) le routeur de niveau 1 qui peut atteindre directement l'adresse prend aussi en charge le TOS spécifique pour ce chemin, comme indiqué dans son LSP de niveau 1.
En général, la même paire [adresse IP, gabarit de sous-réseau] peut être annoncée dans les LSP de niveau 1 envoyés par plusieurs routeurs de niveau 1 dans la même zone. Dans ce cas (en supposant que l'entrée n'est pas supplantée par une entrée configurée manuellement), une seule de ces entrées peut alors être incluse dans le LSP de niveau 2. La ou les valeurs de métrique annoncées dans les LSP de niveau 2 correspondent au minimum de la ou des valeurs de métrique qui seraient calculées pour chacune des entrées de LSP de niveau 1.
Un routeur de niveau 2 aura des adresses IP qui sont directement joignables via ses propres interfaces. Pour les besoins de l'inclusion des informations d'adresses IP joignables dans les LSP de niveau 2, ces adresses "directement joignables" sont traitées exactement de la même façon que les adresses reçues dans les LSP de niveau 1.
Les adresses configurées manuellement peuvent supplanter hiérarchiquement plusieurs entrées d'adresse accessible de niveau 1. Cependant, il peut y avoir certaines adresses IP qui correspondent aux adresses configurées manuellement, mais qui sont non accessibles via l'acheminement de niveau 1. Si un routeur de niveau 2 reçoit un paquet IP dont l'adresse IP correspond à une adresse configurée manuellement qu'il inclut dans son LSP de niveau 2, mais qui est non accessible via l'acheminement de niveau 1 dans la zone, le paquet doit alors être éliminé. Dans ce cas, un rapport d'erreur peut être retourné (comme spécifié dans la RFC 1009), avec la raison de l'élimination spécifiant "destination injoignable".
Figure 2 - Un exemple de domaine d'acheminement
Un exemple est illustré à la figure 2. Supposons que le numéro de réseau pour le domaine d'acheminement entier soit 17 (un réseau de classe A). Supposons qu'à chaque zone soit alloué un numéro de sous-réseau composé des huit bits suivants. La zone peut encore être subdivisée en allouant les huit bits suivants à chacun des LAN de la zone, en donnant à chacun un gabarit de sous-réseau de 24 bits (en comptant les champs de réseau et de sous-réseau). Finalement, 8 bits sont laissés pour le champ d'hôte. Supposons que pour une zone particulière (soit le numéro de sous-réseau 17.133) il y ait un certain nombre de routeurs de niveau 1 à capacité IP qui annoncent (dans l'entrée spéciale IP de leurs LSP de niveau 1) les sous-réseaux 17.133.5, 17.133.43, et 17.133.57.
Supposons que dans cet exemple, afin d'économiser l'espace dans les LSP de niveau 2, les routeurs de niveau 2 dans cette zone soient configurés pour annoncer le sous-réseau 17.133. Seule cette adresse a besoin d'être annoncée dans les LSP de niveau 2. Et donc, si un paquet IP arrive pour une adresse dans les sous-réseaux 17.133.5, 17.133.43 ou 17.133.57, les autres routeurs de niveau 2, dans les autres zones, sauront alors passer le trafic à cette zone.
L'inclusion de 17.133 dans les LSP de niveau 2 signifie que les trois adresses de sous-réseau commençant par 17.133 n'ont pas à être énumérées séparément dans les LSP de niveau 2.
Si du trafic arrive pour une adresse injoignable telles que 17.133.124.7, les routeurs de niveau 2 dans les autres zones de ce domaine particulier vont alors penser que cette zone peut traiter ce trafic, et vont transmettre le trafic aux routeurs de niveau 2 de cette zone, qui devront éliminer ce trafic.
Supposons que le sous-réseau numéro 17.133.125 soit en fait accessible via quelque autre zone, telle que la zone en bas à droite. Dans ce cas, le routeur de niveau 2 dans la zone à gauche annoncerait (dans ses LSP de niveau 2 conformément aux informations configurées manuellement) l'accessibilité du sous-réseau 17.133. Cependant, le routeur de niveau 2 dans la zone en bas à droite annoncerait (dans ses LSP de niveau 2 conformément aux informations tirées des LSP de niveau 1 qu'il a reçus) l'accessibilité du sous-réseau 17.133.125. Du fait de l'utilisation de l'acheminement à la meilleure correspondance, cela fonctionne correctement. Tout le trafic provenant d'autres zones qui est destiné au sous-réseau 17.133.125 sera envoyé au routeur de niveau 2 dans la zone en bas à droite, et tout le trafic autre pour le sous-réseau 17.133 (c'est-à-dire, le trafic pour toute adresse IP commençant par 17.133, sauf celles commençant par 17.133.125) sera envoyé au routeur de niveau 2 dans la zone la plus à gauche.
3.3 Adressage des routeurs dans les paquets IS-IS
Le format de paquet IS-IS exige explicitement que les adresses de routeurs de style OSI apparaissent dans les paquets IS-IS. Par exemple, ces adresses sont utilisées pour déterminer l'appartenance des routeurs à une zone. Il est donc nécessaire que tous les routeurs utilisant le protocole IS-IS aient des adresses de style OSI allouées. Pour les routeurs IP seul, ces adresses ne seront utilisées que dans le fonctionnement du protocole IS-IS, et elles ne sont pas utilisées pour quelque autre propos (tels que le fonctionnement des protocoles EGP, ICMP, ou autres protocoles TCP/IP).
Pour les routeurs OSI-seul et les routeurs duels, l'allocation d'adresses NSAP est direct, mais sort du domaine d'application de la présente spécification. Les mécanismes d'allocation d'adresse sont établis par les organismes de normalisation qui permettent d'allouer des adresses NSAP OSI uniques au monde. Tous les routeurs OSI-seul et les routeurs duels peuvent donc utiliser les adresses OSI normales dans le fonctionnement du protocole IS-IS.
Pour les routeurs IP seul, il y a deux façons d'obtenir les adresses NSAP à utiliser avec le protocole IS-IS.
1) Pour les environnements dans lesquels OSI est utilisé, ou dans lesquels on prévoit qu'OSI sera utilisé à l'avenir, il est permis d'obtenir des allocations d'adresse NSAP de la manière normale, d'allouer des adresses NSAP normales aux routeurs IP seul, et d'utiliser ces adresses dans le fonctionnement d'IS-IS. Cette approche est recommandée même pour les domaines d'acheminement IP pur, car cela simplifiera la future migration de IP-seul au fonctionnement duel.
2) Dans certains cas, les routeurs peuvent avoir seulement des adresses TCP/IP, et il peut n'être pas souhaitable de passer par les mécanismes normaux d'allocation des adresses NSAP. Un mécanisme de remplacement est fourni ci-dessous pour générer à l'aide d'un algorithme une adresse de style OSI valide à partir de l'adresse IP existante et des allocations de numéro de système autonome.
Lorsque on le souhaite, pour les routeurs IP seul, pour utilisation dans les seuls formats de paquet IS-IS, les adresses de style OSI (compatibles avec le format d'adresse NSAP USA GOSIP version 2.0 [9]) peuvent être déduites comme suit :
AFI |
1 octet |
valeur "47" (spécifie le format ICD) |
ICD |
2 octet |
valeur "00 05" (spécifie Internet/Gosip) |
DFI |
1 octet |
valeur "xx" |
AA |
3 octets |
valeur "xx xx xx" (spécifie l'utilisation des NSAP IP-seul particuliers) |
Réservé |
2 octets |
doit être "00 00" |
RD |
2 octets |
contient le numéro de système autonome |
Zone |
2 octets |
doit être alloué comme décrit ci-dessous |
ID |
6 octets |
doit être alloué comme décrit ci-dessous |
SEL |
1 octet |
utilisé comme décrit ci-dessous |
La valeur AFI de "47" et la valeur ICD de "00 05" spécifient le format d'adressage Gosip Version 2.0. Le numéro DFI de "xx" et le AA de "xx xx xx" spécifient que ce format d'adresse NSAP particulier est utilisé, uniquement pour les formats de paquet IS-IS, dans un environnement IP-seul. Le champ réservé doit contenir "00 00", comme spécifié dans GOSIP version 2.0.
Le champ domaine d'acheminement (RD, Routing Domain) contient le numéro de système autonome. Strictement parlant, ce n'est pas nécessaire, car les paquets IS-IS sont échangés au sein d'un seul AS. Cependant, l'inclusion du numéro d'AS dans ce format d'adresse va assurer un fonctionnement correct dans l'éventualité où des routeurs provenant de domaines d'acheminement/AS séparés seraient placés de façon incorrecte sur la même liaison. Le numéro d'AS dans ce contexte est utilisé seulement pour la définition d'adresses NSAP univoques, et n'implique aucun couplage avec des protocoles d'acheminement extérieurs.
Le champ Zone (area) doit être alloué par l'autorité responsable du domaine d'acheminement de telle sorte que chaque zone du domaine d'acheminement doit avoir une valeur de zone univoque.
L'identifiant (ID) doit être alloué par l'autorité responsable du domaine d'acheminement. L'identifiant doit être alloué de telle sorte que chaque routeur dans le domaine d'acheminement ait une valeur univoque. Il est recommandé d'utiliser une des méthodes suivantes :
1) utiliser un identifiant de station univoque IEEE 802 de 48 bits
2) utiliser la valeur hexadécimale "02 00" ajoutée en tête d'une adresse IP du routeur.
Les adresses IEEE 802, si elles sont utilisées, doivent apparaître en format canonique IEEE.
Comme les identifiants de station IEEE 802 sont alloués de façon à être uniques au monde, l'utilisation de ces valeurs assure clairement l'unicité dans la zone. De plus, tous les identifiants de station IEEE 802 alloués ont le bit mondial/local mis à zéro. Ajouter le schéma indiqué en tête de l'adresse IP assure donc que le format (2) illustré ci-dessus ne peut pas produire des adresses qui puissent entrer en conflit avec le format (1). Finalement, dans la mesure où les adresses IP sont aussi uniques au monde, le format (2) produira des identifiants univoques pour les routeurs.
La valeur hexadécimale indiquée est spécifiée dans la forme canonique de IEEE 802 [10]. Dans les adresses IEEE 802, le bit de diffusion groupée est le bit de moindre poids du premier octet. Le bit mondial/local est le bit de moindre poids suivant du premier octet. Le préfixe indiqué règle donc le bit mondial/local à 1, et tous les autres bits des deux premiers octets à 0.
Noter qu'au sein d'une zone, que les adresses ISO soient configurées dans les routeurs par allocation d'adresse ISO, ou que l'adresse de style ISO soit générée directement à partir du numéro d'AS et de l'adresse IP, tous les routeurs au sein d'une zone doivent avoir la même partie d'ordre élevé de l'adresse (AFI, ICD, DFI, AA, RD, et Zone). Cette adresse de style ISO est utilisée dans les messages Hello IS-IS et elle est la base sur laquelle les routeurs reconnaissent si les nœuds voisins sont dans leur zone ou non.
La connexité externe (c'est-à-dire, les communications avec les routeurs en-dehors du domaine d'acheminement) est seulement assurée par les routeurs de niveau 2. La version ISO de IS-IS permet que les chemins OSI externes soient rapportés comme "préfixes d'adresses accessibles" dans les LSP de niveau 2. IS-IS intégré permet aussi de rapporter les adresses IP externes joignables (c'est-à-dire, les adresses IP joignables via l'acheminement inter domaine) dans les LSP de niveau 2 dans le champ "informations d'accessibilité externe à IP". Les chemins OSI externes et les chemins IP externes sont traités de façon indépendante.
Les chemins annoncés dans les entrées d'informations d'accessibilité externe à IP incluent tous les chemins vers l'extérieur du domaine d'acheminement. Cela inclut les routes apprises d'OSPF, EGP, RIP, ou tout autre protocole externe.
Les chemins externes peuvent faire usage de métriques "internes" ou "externes". Les métriques internes sont comparable aux métriques utilisées pour les chemins internes. Et donc en choisissant entre un chemin interne et un chemin externe en utilisant une métrique interne, les valeurs de la métrique peuvent être directement comparées. À l'opposé, les métriques externes ne peuvent pas être directement comparées aux métriques internes. Tout chemin défini en utilisant uniquement une métrique interne est toujours préféré à tout chemin défini en utilisant une métrique externe. Lorsque un chemin externe qui utilise une métrique externe doit être utilisé, la plus faible valeur de la métrique externe est préférée sans considération du coût interne pour atteindre le point de sortie approprié.
Il est utile, dans le fonctionnement des protocoles d'acheminement externes, de fournir un mécanisme pour les routeurs frontière (c'est-à-dire, les routeurs dans le même domaine d'acheminement, qui ont la capacité d'acheminer à l'extérieur sur les autres domaines) pour déterminer leur existence réciproque, et pour échanger les informations externes (sous une forme comprises par les seuls routeurs frontière eux-mêmes). Ceci est rendu possible par l'inclusion de champs "informations de protocole d'acheminement inter-domaine" dans les LSP de niveau 2. Le champ informations de protocole d'acheminement inter-domaine n'est pas inclus dans les LSP de pseudo-nœud.
En général, il peut y avoir plusieurs types d'informations de protocole d'acheminement inter-domaine échangées entre les routeurs frontière. IS-IS spécifie donc que chaque occurrence du champ informations de protocole d'acheminement inter-domaine inclut un champ "type", qui indique le type d'informations de protocole d'acheminement inter-domaine incluses. Les valeurs à utiliser dans le champ type seront spécifiées dans des versions futures de la RFC "Numéros alloués". Les valeurs initiales pour ce champ sont spécifiées dans l'Annexe A à la présente spécification.
Les informations contenues dans le champ informations de protocole d'acheminement inter-domaine seront portées dans les LSP de niveau 2, et devront donc être mémorisées par tous les routeurs de niveau 2 dans le domaine. Cependant, seuls les routeurs de niveau 2 qui sont directement impliqués dans l'acheminement externe vont utiliser ces informations. En concevant l'utilisation de ce champ, il est important de considérer attentivement les implications que cela peut avoir sur les exigences de mémorisation dans les routeurs de niveau 2 (y compris ces routeurs de niveau 2 qui ne sont pas directement impliqués dans l'acheminement externe).
Les protocoles qui échangent des informations d'acheminement directement entre les routeurs frontière et les routeurs externes (dans d'autres domaines d'acheminement /systèmes autonomes) sortent du domaine d'application de la présente spécification.
3.5 Acheminement du type de service
Le protocole IS-IS intégré fournit l'acheminement IP de type de service (TOS), par l'utilisation de la caractéristique de qualité de service (QOS) de IS-IS. Cela permet l'acheminement sur la base du débit (la métrique par défaut), le délai, le coût, ou la probabilité d'erreur résiduelle. Noter que tout paquet particulier peut être acheminé sur la base de l'une de ces quatre métriques. L'acheminement sur la base de combinaisons générales de métriques n'est pas prise en charge.
La prise en charge de TOS/QOS est facultative. Si un paquet particulier appelle un TOS spécifique, et si le chemin correct de la source à la destination est constitué de routeurs qui prennent tous en charge ce TOS particulier, le paquet sera alors acheminé sur le chemin optimal. Cependant, si il n'y a pas de chemin de la source à la destination qui soit constitué de routeurs qui prennent en charge ce type de service particulier, le paquet sera alors transmis en utilisant à la place la métrique par défaut. Cela permet le service TOS dans les environnements où il est nécessaire, tout en fournissant encore un service acceptable dans le cas où est demandé un TOS non pris en charge.
NOTE - IP n'a pas de TOS de coût. Il n'y a donc pas de transposition de la métrique de TOS IP qui corresponde à la métrique du coût minimum.
Le champ TOS IP est transposé dans une des quatre métriques disponibles comme suit :
Bits 0-2 (Préséance) : Ce champ n'affecte pas le chemin, mais peut plutôt affecter les autres aspects de la transmission de paquet.
Bits 3 (Délai), 4 (Débit) et 5 (Fiabilité) :
000 (tout normal) Utiliser la métrique par défaut
100 (faible délai) Utiliser la métrique par délai
010 (haut débit) Utiliser la métrique par défaut
001 (haute fiabilité) Utiliser la métrique par fiabilité
autre Utiliser la métrique par défaut
Dans certains cas, les paquets IS-IS (spécifiquement les paquets d'état de liaison et les paquets numéro de séquence complet) peuvent être trop gros pour tenir dans un seul paquet. L'IS-IS OSI [1] permet que les LSP et les CSNP soient partagés en plusieurs paquets. Ceci est indépendant de la segmentation ISO 8473, et est aussi indépendant de la fragmentation IP. L'utilisation de plusieurs paquets indépendants présente l'avantage (par rapport à la segmentation ou la fragmentation) que : (i) quand les informations dans IS-IS changent, seuls les paquets réalisés ont besoin d'être retransmis ; (ii) lorsque un seul paquet est reçu, il peut être traité sans qu'il soit besoin de recevoir tous les autres paquets du même type provenant du même routeur avant de commencer le traitement.
IS-IS intégré utilise la même fonction de paquet multiple que définie en [1]. Les champs spécifiques de IP dans les paquets IS-IS peuvent être partagés entre plusieurs paquets. Comme spécifié à la section 5 ("Structure et codage des PDU"), certains des champs spécifiques de IP (ceux qui peuvent être très longs) peuvent être partagés en plusieurs occurrences du même champ, permettant par là le partage des champs entre différents paquets.
Plusieurs LSP provenant du même routeur sont distingués par leur numéro de LSP. Généralement, des champs de longueur très variable peuvent survenir dans un LSP avec n'importe quel numéro de LSP. L'occurrence de certains champs de longueur variable spécifique peut être exigée dans un LSP numéro 0. Excepté sur mention contraire explicite, lorsque un routeur IS-IS produit plusieurs LSP, le champ spécifique IP peut survenir dans un LSP avec n'importe quel numéro de LSP.
Les paquets de numéro de séquence complet peuvent être partagés en plusieurs paquets, avec la gamme à laquelle chaque paquet s'applique rapportée explicitement dans le paquet. Les paquets de numéro de séquence partiel sont par nature partiels, et peuvent donc facilement être partagé en plusieurs paquets si nécessaire. Là encore, lorsque c'est applicable, les champs spécifiques de IP peuvent survenir dans tout SNP.
Pour les routeurs IP seul, le format des paquets IS-IS reste inchangé. Cependant, il y a quelques champs de longueur variable qui proviennent des paquets IS-IS qui peuvent être omis. Précisément :
Paquets Hello IS-IS :
- pas de changement
Paquets d'état de liaison IS-IS :
- les entrées "Voisins de systèmes d'extrémité" sont omises
- les entrées "Préfixes voisins" sont omises
Paquets de numéro de séquence IS-IS :
- pas de changement
De futures versions de IS-IS intégré pourraient spécifier des mécanismes facultatifs d'encapsulation pour les réparations de partition, et pour la transmission de paquets à travers des routeurs incompatibles (c'est-à-dire, pour transmettre des paquets OSI à travers des routeurs IP seul, et transmettre des paquets IP à travers des routeurs OSI-seul). Les détails de l'encapsulation et de la désencapsulation feront l'objet de compléments d'étude. Les routeurs conformes à IS-IS intégré ne sont pas obligés de mettre en œuvre l'encapsulation ni la désencapsulation.
Le champ authentification permet que chaque paquet IS-IS contienne les informations utilisées pour authentifier l'origine et/ou le contenu du paquet. Les informations d'authentification contenues dans chaque paquet sont utilisées pour authentifier le paquet entier, y compris les parties OSI et IP. Si un paquet reçu contient des informations d'authentification invalides, le paquet entier est alors éliminé. Si un LSP ou SNP est partagé en plusieurs paquets (comme décrit au paragraphe 3.6), chacun est alors authentifié de façon indépendante.
L'utilisation du champ authentification est facultative. Les routeurs ne sont pas obligés d'être capables d'interpréter les informations d'authentification. Comme avec les autres champs de IS-IS intégré, si un routeur ne met pas en œuvre l'authentification, il va alors ignorer tout champ d'authentification qui pourrait être présent dans un paquet IS-IS.
L'annexe D spécifie une proposition d'utilisation du champ d'authentification.
3.10 Calcul de Dijkstra de l'ordre de préférence des routes
On définit le terme "entrée d'accessibilité IP" comme signifiant la combinaison de [adresse IP, gabarit de sous-réseau]. Le calcul de Dijkstra doit calculer des routes pour chaque entrée d'accessibilité IP distincte. Pour le calcul de Dijkstra, chaque entrée d'accessibilité IP peut être traitée de la même manière que dans un système d'extrémité OSI. Naturellement, chaque entrée d'accessibilité IP est traitée comme distincte de tous les systèmes d'extrémité OSI qui pourraient aussi être accessibles dans la même zone ou domaine d'acheminement.
Pour toute entrée d'accessibilité IP particulière, elle est la même qu'une autre entrée si et seulement si : (i) les gabarits de sous-réseau sont identiques ; et (ii) pour chaque bit dans le gabarit de sous-réseau qui a la valeur "1", l'adresse IP est identique. Cela peut facilement être vérifié en mettant à zéro les bits qui dans l'adresse IP correspondent à un bit zéro dans le gabarit, puis en traitant l'entrée comme une quantité de 64 bits, et en recherchant l'égalité entre les différentes quantités de 64 bits. Le calcul réel de chemin pour les entrées d'accessibilité IP n'est donc pas plus complexe que le calcul des chemins pour les systèmes d'extrémité OSI (sauf pour le remplacement d'un test de 48 bits par un test de 64 bits).
Le calcul de Dijkstra ne prend pas en considération si un routeur est IP-seul, OSI-seul, ou duel. Les restrictions topologiques spécifiées au paragraphe 1.4 assurent que les paquets IP ne seront envoyés que via des routeurs à capacité IP, et que les paquets OSI ne seront envoyés que via des routeurs à capacité OSI.
IS-IS intégré préfère les chemins au sein de la zone (via l'acheminement de niveau 1) chaque fois que possible. Si des chemins de niveau 2 doivent être utilisés, les chemins au sein du domaine d'acheminement (spécifiquement, les chemins qui utilisent une métrique interne) sont préférés aux chemins en dehors du domaine d'acheminement (qui utilisent une métrique externe).
Le protocole IS-IS intégré fait usage de l'acheminement "à la meilleure correspondance" des paquets IP. Cela implique qu'une adresse de destination particulière peut mieux correspondre à une entrée dans la base de données de transmission. Si un paquet IP particulier a une adresse de destination qui correspond à deux entrées d'accessibilité IP différentes, l'entrée dont le gabarit contient le plus de bits "1" est préférée.
Les paquets IP dont la destination est un routeur sont acheminés de la même façon que tout autre paquet IP, en les transmettant d'abord au sous-réseau approprié, puis en transmettant sur ce sous-réseau à l'hôte de destination (qui se trouve dans ce cas être un routeur). En particulier, la base de données de transmission IP ne contient pas de chemins explicites pour les "adresses IP d'interface " individuelles énumérées par chaque routeur dans son LSP.
Cependant, les chemins d'hôte (les chemins avec un gabarit de sous-réseau tout de uns) peuvent bien sûr être inclus dans les entrées d'accessibilité IP, et seront traitées de la même manière que les autres entrées d'accessibilité IP.
Afin d'assurer une interopération correcte des différentes mises en œuvre de routeur, il est nécessaire de spécifier l'ordre de préférence des chemins possibles. Pour les destinations OSI, cela sort du domaine d'application du présent rapport. Pour les destinations IP, c'est spécifié aux paragraphes 3.10.1 et 3.10.2 ci-dessous. L'annexe C spécifie un calcul de Dijkstra détaillé et un algorithme de transmission qui est compatible avec l'ordre de préférence des chemins spécifié ici.
Avec IS-IS, si un chemin pour une destination données est annoncé, ou si une liaison entre des routeurs est annoncée, les valeurs de métrique associées à certains des (ou tous) types de métrique du TOS spécifié peuvent être associées à cette destination ou liaison. Cependant, la métrique par défaut doit toujours être disponible. Normalement cela assure que si un chemin qui utilise n'importe quelle métrique de TOS est disponible, un chemin utilisant la métrique par défaut sera alors aussi disponible. La seule exception à cela est lorsque le chemin correspondant qui utilise la métrique par défaut a un coût total (au sein de la zone, ou au sein du cœur de réseau de niveau 2) supérieur à MaxPathMetric.
Pour déterminer le chemin pour une destination particulière pour un TOS spécifié, seuls sont pris en compte les chemins qui utilisent la métrique du TOS demandé ou la métrique par défaut.
Si une destination donnée est accessible au sein d'une zone via un chemin qui utilise soit le TOS demandé soit le TOS par défaut, IS-IS utilisera alors toujours un chemin au sein de la zone (via un acheminement de niveau 1), sans considérer si un chemin de remplacement existe en-dehors de la zone (via un acheminement de niveau 2). Dans ce cas, les chemins au sein de la zone sont choisis comme suit :
1) Parmi les chemins au sein de la zone, si l'adresse de destination spécifiée correspond à plus d'une paire [adresse IP, gabarit de sous-réseau], l'adresse la plus spécifique correspondante (celle avec le plus de bits "1" dans le gabarit) est préférée.
2) Parmi les chemins dans la zone pour des correspondances d'adresse également spécifiques, les chemins sur lesquels le TOS demandé (s'il en est) est pris en charge sont toujours préférés aux chemins sur lesquels le TOS demandé n'est pas pris en charge.
3) Parmi les chemins dans la zone qui ont le même TOS pour des correspondances d'adresse également spécifiques, les chemins les plus courts sont préférés. Pour la détermination du plus court chemin, si un chemin sur lequel le TOS spécifié est pris en charge, la métrique du TOS spécifié est alors utilisée, autrement, on utilise la métrique par défaut. Parmi des chemins de coût égal, le partage de charge peut être effectué comme spécifié dans [1].
Pour un routeur de niveau 1 seul (c'est-à-dire, un routeur qui ne prend pas part à l'acheminement de niveau 2, ou un routeur de niveau 2 qui n'est pas "rattaché"), si une destination donnée n'est pas accessible au sein d'une zone, l'acheminement de niveau 1 va toujours acheminer vers un routeur de niveau 2 comme suit :
1) Parmi les chemins dans la zone vers des routeurs de niveau 2 rattachés, les chemins sur lesquels le TOS demandé (s'il en est) est pris en charge sont toujours préférés aux chemins sur lesquels le TOS demandé n'est pas pris en charge.
2) Parmi les chemins dans la zone de même TOS vers les routeurs rattachés de niveau 2, les chemins les plus courts sont préférés. Pour déterminer le chemin le plus court, si un chemin sur lequel le TOS spécifié est pris en charge est disponible, la métrique du TOS spécifié est alors utilisée, autrement, on utilise la métrique par défaut. Parmi les chemins de coût égal, le partage de charge peut être effectué comme spécifié dans [1].
Pour les routeurs de niveau 2 qui prennent aussi part à l'acheminement de niveau 1, les chemins appris via l'acheminement de niveau 1, qui utilisent soit le TOS demandé, soit le TOS par défaut, sont toujours préférés aux chemins appris à travers l'acheminement de niveau 2. Pour les destinations qui ne sont pas accessibles via l'acheminement de niveau 1, ou pour les routeurs de niveau 2 seul (routeurs qui ne prennent pas part à l'acheminement de niveau 1), les chemins de niveau 2 sont alors choisis comme suit :
1) Les chemins qui utilisent seulement des métriques internes sont toujours préférés aux chemins qui utilisent des métriques externes.
2) Si un chemin utilisant seulement des métriques internes est disponible :
a) Si l'adresse de destination spécifiée correspond à plus d'une paire [adresse IP, gabarit de sous-réseau], la correspondance d'adresse la plus spécifique (c'est-à-dire, le plus grand nombre de "1" présents dans le gabarit de sous-réseau) est préférée.
b) Parmi les chemins avec des correspondances d'adresse également spécifiques (c'est-à-dire, un nombre égal de "1" présents dans le gabarit de sous-réseau), les chemins sur lesquels le TOS demandé (s'il en est) est pris en charge sont toujours préférés aux chemins sur lesquels le TOS demandé n'est pas pris en charge.
c) Parmi les chemins de même TOS avec une correspondance d'adresse également spécifique, le chemin le plus court est préféré. Pour déterminer le plus court chemin, si une route sur laquelle le TOS spécifié est pris en charge est disponible, la métrique du TOS spécifié est alors utilisée, autrement, on utilise la métrique par défaut. Parmi les chemins de coût égal, le partage de charge peut être effectué comme spécifié dans [1].
NOTE : Les chemins internes (chemins pour des destinations annoncées dans le champ "Information d'accessibilité IP internes "), et les chemins externes qui utilisent des métriques internes (chemins pour des destinations annoncées dans le champ "Information d'accessibilité IP externes", avec une métrique du type "interne") sont traités de façon identique pour les besoins de l'ordre de préférence des chemins, et pour le calcul de Dijkstra.
3) Si aucun chemin utilisant seulement des métriques internes n'est disponible, mais qu'un chemin utilisant des métriques externes est disponible :
a) Si l'adresse de destination spécifiée correspond à plus d'une paire [adresse IP, gabarit de sous-réseau], la correspondance d'adresse la plus spécifique est préférée.
NOTE : Pour les chemins externes, le gabarit de sous-réseau va normalement correspondre précisément au numéro de réseau. Cela implique que cette vérification va toujours découvrir des chaînes de correspondance d'égale longueur. Cependant, cette vérification est incluse pour permettre une future migration vers un traitement plus général des adresses externes.
b) Parmi les chemins de correspondances également spécifiques, les chemins sur lesquels le TOS demandé (s'il en est) est pris en charge sont toujours préférés aux chemins sur lesquels le TOS demandé n'est pas pris en charge. NOTE : pour les chemins externes, le chemin n'est considéré prendre en charge le TOS demandé que si le chemin interne pour le routeur frontière approprié prend en charge le TOS demandé, et si le chemin externe rapporté par le routeur frontière prend aussi en charge le TOS demandé.
c) Parmi les chemins de même TOS avec une égale longueur de chaîne d'adresse correspondante, le plus court chemin est préféré. Pour la détermination du plus court chemin :
(i) Les chemins avec une plus faible valeur de métrique externe annoncée sont toujours préférés.
(ii) Parmi les chemins avec une métrique externe égale, les chemins avec une métrique interne plus courte sont préférés. Parmi les chemins de coût égal, le partage de charge peut être effectué comme spécifié dans [1].
Pour les routeurs de niveau 2 qui annoncent des résumés d'adresse configurés manuellement dans leurs LSP de niveau 2, il va dans certains cas exister des adresses IP qui correspondent aux adresses configurées manuellement, mais ne correspondent à aucune des adresses qui sont en fait joignables via l'acheminement de niveau 1 dans la zone. Généralement, les paquets pour de telles adresses sont traités conformément aux règles suivantes :
1) Si la destination spécifiée est joignable via l'acheminement de niveau 1, conformément à l'ordre de préférence des chemins spécifié ci-dessus, le paquet sera alors livré via l'acheminement de niveau 1.
2) Si la destination spécifiée est non accessible via l'acheminement de niveau 1, mais est accessible via l'acheminement de niveau 2, et si il y a d'autres routeurs de niveau 2 qui offrent des chemins plus désirables selon les règles spécifiées ci-dessus (par exemple, un chemin avec une correspondance plus spécifique, ou un chemin avec une correspondance également spécifique qui prend en charge le TOS correct) l'acheminement de niveau 2 transmettra alors le paquet selon le chemin le plus désirable.
3) Si la destination spécifiée est non accessible via l'acheminement de niveau 1, et si le résumé d'adresse configuré manuellement annoncé par ce routeur (le routeur qui a reçu le paquet et essaye de le transmettre) représente le chemin le plus désirable, la destination est alors injoignable et le paquet doit être éliminé.
4 Fonctions dépendantes du sous-réseau
Les routeurs duels peuvent recevoir une combinaison de paquets OSI et de paquets IP. Il est nécessaire que les routeurs duels soient capables de distinguer clairement et sans ambiguïté les deux suites de protocoles.
Ce problème n'est pas particulier au protocole d'acheminement IS-IS intégré. En fait, ce problème va survenir dans tout environnement multi-protocole. Ce problème fait l'objet de travaux indépendants, et il sort du domaine d'application de la présente spécification.
En général, le type de liaison est un paramètre de configuration. Par exemple, s'il faut utiliser PPP, HDLC serait configuré, ou quelque autre protocole point à point pour liaison point à point. Pour tout type de liaison particulier, une méthode doit être définie pour l'encapsulation des paquets OSI aussi bien qu'IP. La définition de telles méthodes pour les types de liaison courants sort du domaine d'application de la présente spécification.
Les paquets IP sont encapsulés directement sur le service de couche liaison sous-jacent, en utilisant la méthode normale de transmission des paquets IP sur chaque type de liaison. De même, les paquets OSI sont encapsulés directement sur le service sous-jacent de couche liaison, en utilisant la méthode normale de transmission des paquets OSI sur chaque type de liaison. Finalement, noter que les paquets IS-IS sont encapsulés en utilisant la méthode normale de transmission des paquets OSI sur tout type de liaison particulier. Cela implique que tous les routeurs IS-IS, y compris les routeurs IP seul, doivent être capables de recevoir des paquets IS-IS en utilisant l'encapsulation normale pour les paquets OSI.
4.2 Adresses IP multiples par interface
IS-IS intégré permet à chaque routeur d'avoir plusieurs adresses IP pour chaque interface physique, jusqu'au nombre maximum de celles qui peuvent être contenues dans un seul champ "Adresse d'interface IP" (c'est-à-dire, jusqu'à 63 adresses par interface). Par exemple, lorsque il y a deux sous-réseaux logiques sur le même LAN, l'interface peut avoir deux adresses IP, une correspondant à chaque sous-réseau logique. Chaque paquet Hello IS-IS contient une liste des adresses IP associées à l'interface physique sur laquelle Hello est transmis.
Il est permis de mettre en œuvre des routeurs qui se conforment à la spécification IS-IS intégré qui restreint le nombre des adresses IP par interface. Cependant, les routeurs à capacité IP doivent être capables d'interagir correctement avec les autres routeurs qui allouent plusieurs adresses IP par interface physique (jusqu'au maximum de 63 adresses par interface).
Lorsque c'est approprié (par exemple, dans certains cas de liaisons point à point), certaines interfaces peuvent n'avoir pas d'adresse IP allouée. Dans ce cas, le Hello IS-IS transmis sur cette interface peut omettre le champ Adresse IP d'interface, ou peut inclure le champ Adresse IP d'interface avec une entrée de zéros.
4.3 LAN, routeurs désignés, et pseudo nœuds
La maintenance des routeurs désignés et des pseudo nœuds est spécifiée dans [1], et n'est pas modifiée par la présente proposition. Dans le cas de mélange de routeurs IP-seul et de routeurs duels (ou de routeurs OSI-seul et de routeurs duels) sur le même LAN dans une pure zone IP (ou respectivement une pure zone OSI), tout routeur sur le LAN peut être choisi comme routeur désigné.
Cependant, il y a une différence fondamentale dans la façon dont OSI et TCP/IP traitent les LAN et les autres sous-réseaux de diffusion.
Avec OSI, l'utilisation du protocole ES-IS (ISO 9542) permet aux systèmes d'extrémité et routeurs de déterminer automatiquement leur connexité, permettant par là à tous les systèmes d'extrémité sur le LAN d'acheminer potentiellement via tous les routeurs sur le LAN.
À l'opposé, TCP/IP alloue explicitement des identifiants de sous-réseau à chaque réseau de zone locale. Dans certains cas, un seul LAN physique pourrait avoir plusieurs identifiants de sous-réseau alloués. Dans ce cas, les systèmes d'extrémité (hôtes) qui ont une adresse sur un sous-réseau logique sont explicitement empêchés d'envoyer directement des paquets IP à un routeur dont l'adresse le place sur un sous-réseau logique différent. Chaque routeur est configuré manuellement pour savoir quels sous-réseaux il peut atteindre sur chaque interface. Dans le cas où il y a plusieurs sous-réseaux logiques sur le même LAN, chaque routeur peut seulement échanger des paquets IP avec les systèmes d'extrémité qui sont sur le même sous-réseau logique. Cela implique qu'il n'est pas suffisant au LSP de pseudo nœud d'annoncer tous les sous-réseaux du LAN (c'est-à-dire, toutes les paires [adresse IP, gabarit de sous-réseau] joignables sur le LAN).
Il est donc nécessaire que chaque routeur annonce dans ses LSP les sous-réseaux qu'il peut atteindre sur chaque interface, y compris les interfaces avec des sous-réseaux de diffusion comme les LAN. Le LSP de pseudo nœud ne spécifie pas les adresses IP qui sont joignables sur le LAN (c'est-à-dire, qui ne contiennent pas le champ d'accessibilité IP).
Comme spécifié ailleurs (voir la mise à jour à venir de "Exigences pour les routeurs IP" [4]), les routeurs ne peuvent envoyer de redirections ICMP que si : (i) le paquet IP est transmis sur la même interface physique que celle sur laquelle il est arrivé ; et (ii) l'adresse de source du paquet IP transmis, l'adresse IP de cette interface de routeur (comme indiqué par l'adresse de source de la redirection ICMP), et l'adresse IP du routeur auquel le paquet est redirigé (encore comme indiqué dans la redirection ICMP) sont toutes sur le même sous-réseau IP.
4.4 Maintenance des adjacences de routeurs
IS-IS détermine si une adjacence est à établir entre deux routeurs utilisant des moyens qui sont indépendants des adresses IP d'interface des routeurs. Lorsque plusieurs sous-réseaux logiques surviennent sur le même LAN physique, cela permet potentiellement que les adjacences soient établies entre deux routeurs qui partagent entre eux la connexité physique, mais qui n'ont pas de sous-réseau logique en commun. Les routeurs IS-IS à capacité IP doivent donc être capables de transmettre les paquets IP sur les adjacences existantes aux routeurs avec lesquels ils partagent la connexité physique, même lorsque l'adresse IP de l'interface adjacente du routeur voisin est sur un sous-réseau IP logique différent.
Pour les liaisons point à point, IS-IS exige l'échange des ISH ISO 9542, comme première étape de l'établissement de liaison entre les routeurs. Tous les routeurs IS-IS sont donc obligés de transmettre et de recevoir les paquets ISO 9542 sur les liaisons point à point.
Le champ "protocoles pris en charge" (défini à la Section 5 ci-dessous) doit être présent dans tous les paquets Hello IS-IS envoyés par les routeurs duels et IP seul. Si ce champ manque, il est alors supposé que le paquet a été transmis par un routeur OSI-seul. De même, les ISH 9542 envoyés sur des liaisons point à point, où il y a (où il peut y avoir) un autre routeur IS-IS à l'autre extrémité de la liaison point à point, doivent aussi contenir le champ "protocoles pris en charge". Noter que si ce champ est par erreur envoyé dans un ISH 9542 où il y a un système d'extrémité OSI-seul ordinaire à l'autre extrémité de la liaison, alors (conformément à ISO 9542) le système d'extrémité est obligé d'ignorer le champ et d'interpréter correctement l'ISH. Il est donc sûr de toujours inclure ce champ dans les ISH envoyés sur des liaisons point à point.
Les routeurs duels doivent fonctionner de façon duelle sur chaque liaison du domaine d'acheminement sur laquelle ils utilisent IS-IS. Et donc, la valeur du champ "protocoles pris en charge" doit être identique sur chaque liaison (c'est-à-dire, pour tout routeur utilisant IS-IS, tous les Hello et les LSP qu'il transmet doivent contenir les mêmes valeurs de "protocoles pris en charge").
4.5 Transmission à des routeurs incompatibles
Il peut y avoir des cas où un routeur duel doit transmettre un paquet IP à un routeur OSI-seul, ou transmettre un paquet OSI à un routeur IP-seul. Dans ce cas, le paquet doit être éliminé. Un rapport d'erreur peut être transmis, conformément à, respectivement, la spécification IP ou ISO 8473. La raison de l'élimination spécifiée dans le rapport d'erreur devrait spécifier "hôte de destination inaccessible" (pour IP), ou "destination injoignable" (pour OSI).
De même, du fait des erreurs, dans certains cas un routeur IP-seul peut avoir à transmettre un paquet IP à un routeur OSI-seul. Cette fois encore, le paquet doit être éliminé, comme spécifié ci-dessus. Cela ne peut survenir que si les routeurs IP-seul et OSI-seuls surviennent dans la même zone, ce qui est une erreur de configuration.
La présente section décrit les champs supplémentaires de paquet à utiliser dans le protocole d'acheminement intra-domaine IS-IS ISO dans les environnements IP pur et duel. Précisément, les mêmes types de paquet que ceux d'IS-IS [1] sont utilisés, et tous les champs fixés restent les mêmes. Des champs supplémentaires de longueur variable sont définis dans cette section.
5.1 Généralités sur les PDU IS-IS
Les paquets utilisés dans le protocole d'acheminement IS-IS entrent dans trois classes principales : (i) paquets Hello ; (ii) paquets d'état de liaison (LSP) ; et (iii) paquets de numéro de séquence (SNP).
Les paquets Hello sont utilisés pour initialiser et maintenir les adjacences entre routeurs voisins. Il y a trois types de paquets Hello IS-IS :
(i) Les "PDU Hello d'IS à IS de LAN de niveau 1" sont utilisés par les routeurs de niveau 1 sur les LAN de diffusion.
(ii) Les "PDU Hello d'IS à IS de LAN de niveau 2" sont utilisés par les routeurs de niveau 2 sur les LAN de diffusion.
(iii) Les "PDU Hello d'IS à IS en point à point" sont utilisés sur des supports qui ne font pas de diffusion, tels que les liaisons en point à point, ou les sous-réseaux de topologie générale.
Sur les liaisons en point à point, les échanges de ISH ISO 9542 (Hello de système intermédiaire) sont utilisés pour initialiser la liaison, et pour permettre à chaque routeur de savoir si il y a un routeur à l'autre extrémité de la liaison, avant que les Hello IS-IS soient échangés. Tous les routeurs qui mettent en œuvre IS-IS (qu'ils soient IP-seul, OSI-seul, ou duels), si ils ont des interfaces sur des liaisons en point à point, doivent donc être capables de transmettre des ISH ISO 9542 sur leurs liaisons point à point.
Les paquets d'état de liaison (LSP, Link State Packet) sont utilisés pour échanger les informations sur l'état de la liaison. Il y a deux types de LSP :
(i) Les "PDU d'état de liaison de niveau 1" sont transmis par les routeurs de niveau 1.
(ii) Les "PDU d'état de liaison de niveau 2" sont transmis par les routeurs de niveau 2. Noter que les routeurs de niveau 2 vont, dans la plupart des cas, être aussi des routeurs de niveau 1, et vont donc transmettre les deux sortes de LSP.
Les PDU de numéro de séquence sont utilisés pour s'assurer que les routeurs voisins ont la même notion de ce qu'est le plus récent LSP provenant de chaque autre routeur. Les PDU de numéro de séquence servent donc une fonction similaire à celle des paquets d'accusé de réception, mais permettent un fonctionnement plus efficace. Il y a quatre types de paquets de numéro de séquence :
(i) Les "PDU de numéro de séquence complet de niveau 1" ;
(ii) Les "PDU de numéro de séquence complet de niveau 2" ;
(iii) Les "PDU de numéro de séquence partiel de niveau 1" ; et
(iv) Les "PDU de numéro de séquence partiel de niveau 2". Un paquet de numéro de séquence partiel fait la liste des numéros de séquence les plus récents dans un ou plusieurs LSP, et fonctionne à peu près comme un accusé de réception. Un paquet de numéro de séquence partiel diffère d'un accusé de réception conventionnel en ce sens qu'il peut accuser réception de plusieurs LSP à la fois, et dans le sens où il peut agir comme une demande d'informations. Un paquet de numéro de séquence complet contient le plus récent numéro de séquence de tous les LSP de la base de données. Un paquet de numéro de séquence complet peut donc être utilisé pour assurer la synchronisation de la base de données entre des routeurs adjacents de façon périodique, ou lors du premier établissement d'une liaison.
5.2 Généralités sur les informations spécifiques d'IP pour IS-IS
Six nouveaux champs sont définis pour IS-IS intégré :
(i) "Protocoles pris en charge" ;
(ii) "Adresse d'interface IP" ;
(iii) "Informations d'authentification" ;
(iv) "Informations d'accessibilité interne IP" ;
(v) "Informations d'accessibilité externe IP" ;
(vi) "Informations de protocole d'acheminement inter-domaine".
Le champ "Protocoles pris en charge" identifie les protocoles qui sont pris en charge par chaque routeur. Ce champ doit être inclus dans tous les paquets Hello IS-IS et dans tous les LSP avec le LSP numéro 0 transmis par les routeurs à capacité IP. Si ce champ n'est pas inclus dans un paquet Hello IS-IS ou dans un LSP avec le LSP numéro 0, il peut être supposé que ce paquet a été transmis par un routeur OSI-seul. Le champ "Protocoles pris en charge" doit aussi être inclus dans les ISH ISO 9542 envoyés par les routeurs à capacité IP sur des liaisons point à point à d'autres routeurs IS-IS.
Le champ "Adresse d'interface IP" est inclus dans tous les paquets Hello IS-IS et LSP transmis par les routeurs IP-seul et duels. Dans les paquets Hello, ce champ ne survient qu'une seule fois, et contient la ou les adresses IP de l'interface sur laquelle le paquet Hello est transmis (jusqu'à un maximum de 63 adresses IP sur chaque interface). Si un Hello IS-IS est transmis sur une interface qui n'a pas d'adresse IP allouée, ce champ peut alors être omis, ou peut être inclus avec une entrée de zéros. Dans les paquets d'état de liaison, ce champ contient une liste d'une ou plusieurs adresses IP correspondant à une ou plusieurs interfaces du routeur qui est à l'origine du LSP. Chaque routeur à capacité IP doit inclure ce champ dans ses LSP. Ce champ peut survenir plusieurs fois dans un LSP, et peut survenir dans un LSP avec tout numéro de LSP.
Le champ "Informations d'authentification" est facultatif dans toutes les PDU IS-IS. S'il est utilisé, il contient des informations qui servent à authentifier le paquet. Tous les paquets IS-IS (y compris les Hello d'IS 9542) peuvent être authentifiés en utilisant ce champ.
Le champ "Informations d'accessibilité interne IP" peut être présent dans tous les LSP transmis par un routeur à capacité IP. S'il est présent, il identifie une liste de zéro, un ou plusieurs triplets [adresse IP, gabarit de sous-réseau, métriques] joignables par le routeur qui a généré le LSP. Chaque entrée doit contenir une métrique par défaut, et peut contenir des métriques de délai, de coût et d'erreur. Si un routeur à capacité IP n'atteint pas directement d'adresses IP, il peut alors omettre ce champ, ou il peut inclure le champ avec des entrées [adresse IP, gabarit de sous-réseau, métriques] de zéros. S'il est inclus dans les LSP de niveau 1, ce champ n'inclut que les entrées directement joignables par le routeur qui a généré le LSP, via une de ses interfaces. S'il est inclus dans les LSP de niveau 2, ce champ n'inclut que les entrées joignables par le routeur qui a généré le LSP, soit via une de ses interfaces, soit indirectement via l'acheminement de niveau 1. Ce champ peut survenir plusieurs fois dans un LSP, et peut survenir dans un LSP avec tout numéro de LSP.
Le champ "Informations d'accessibilité externe IP" peut être présent dans les LSP de niveau 2 transmis par les routeurs à capacité IP de niveau 2. S'il est présent, il identifie une liste de zéro, une ou plusieurs entrées [adresse IP, gabarit de sous-réseau, métriques] joignables par le routeur qui a généré le LSP de niveau 2. Chaque entrée doit contenir une métrique par défaut, et peut contenir des métriques de délai, de coût, et d'erreur. Chaque entrée peut contenir des métriques de type "interne", ou de type "externe". Si un routeur de niveau 2 n'a aucun chemin externe (via les routeurs voisins dans d'autres domaines d'acheminement), il peut omettre ce champ, ou il peut inclure le champ avec des entrées à zéro. Ce champ ne comporte que des entrées joignables par le routeur qui a généré le LSP, via une liaison directe vers un routeur externe. Ce champ peut survenir plusieurs fois dans un LSP de niveau 2, et peut survenir dans un LSP avec tout numéro de LSP.
Le champ "Informations de protocole d'acheminement inter-domaine" peut être présent dans les LSP de niveau 2 transmis par les routeurs à capacité IP de niveau 2. Ce champ est transmis pour les besoins du protocole d'acheminement externe, et n'est pas utilisé par IS-IS. Par exemple, il peut être utilisé pour permettre aux routeurs frontière de se trouver les uns les autres. Ce champ peut survenir plusieurs fois dans un LSP de niveau 2, et peut survenir dans un LSP avec tout numéro de LSP.
La version DP 10589 de l'IS-IS OSI ne permet pas actuellement l'ajout de champs de longueur variable codés en TLV pour les paquets de numéro de séquence. Cependant, ceci sera corrigé dans les futures versions de 10589. De plus, il est prévu que ce soit la seule correction aux futures versions de 10589 qui ne soit pas rétro-compatible avec la version DP. IS-IS intégré utilise donc une version corrigée du DP 10589, qui corrige le codage des SNP. Le codage correct des paquets de numéro de séquence (comme il est prévu qu'il apparaisse dans les futures versions de ISO 10589) est donné à l'Annexe B de la présente spécification.
Toutes les informations spécifiques de IP sont codées dans les paquets IS-IS comme des champs de longueur variable. Tous les champs de longueur variable dans IS-IS sont codés comme suit :
Nombre d'octets
+---------------------------+
| Code | 1
+---------------------------+
| Longueur | 1
+---------------------------+
| Valeur | Longueur
+---------------------------+
Figure 3 – Codage des champs de longueur variable
Tout code qui n'est pas reconnu dans une PDU reçue doit être ignoré, et, pour les paquets qui sont transmis (particulièrement dans les paquets d'état de liaison), passés inchangés.
En général, une PDU IS-IS peut contenir plusieurs champs de longueur variable, dont certains contiennent des informations spécifiques d'OSI (spécifiée dans [1]) et dont certains contiennent des informations spécifiques de IP (spécifiées ci-dessous). Sauf mention explicite contraire, ces champs de longueur variable peuvent survenir dans n'importe quel ordre.
5.3 Codage des champs spécifiques dans les PDU IS-IS
Ce paragraphe spécifie le codage détaillé de tous les champs spécifiques de IP dans les PDU IS-IS. Lorsque un champ particulier peut être présent dans plus d'un type de PDU, le champ est répété pour chaque type de PDU auquel il s'applique.
Le numérotage des bits et des octets est le même que dans [1]. En particulier, les octets dans une PDU sont numérotés à partir de 1, en ordre croissant. Les bits dans un octet sont numérotés de 1 à 8, et le bit 1, de plus fort poids, est marqué sur la droite. Lorsque des octets consécutifs sont utilisés pour représenter un nombre, l'octet de plus faible numéro a la valeur de plus fort poids.
Les codes supplémentaires pour la prise en charge de IP sont :
- Protocoles pris en charge – ensemble des identifiants de protocoles de couche réseau pour les protocoles de couche réseau que ce système intermédiaire est capable de relayer.
Code - 129
Longueur – longueur totale du champ de valeur (un octet par protocole pris en charge).
Valeur - un octet NLPID (comme alloué par ISO/TR 9577) pour chaque protocole de données pris en charge.
Nombre d'octets
+---------------------------+
| NLPID | 1
+---------------------------+
: :
: :
|---------------------------|
| NLPID | 1
+---------------------------+
NLPID – identifiant de protocole de couche réseau enregistré par ISO/TR 9577.
- Adresse IP d'interface – la ou les adresses IP de l'interface correspondant au SNPA sur lequel cette PDU est à transmettre.
Code - 132
Longueur – longueur totale du champ de valeur (quatre octets par adresse).
Valeur –
Nombre d'octets
+----------------------------+
| ADRESSE IP | 4
+----------------------------+
: :
: :
+----------------------------+
| ADRESSE IP | 4
+----------------------------+
ADRESSE IP – Adresse IP à 4 octets de l'interface.
- Informations d'authentification -- Informations utilisées pour authentifier la PDU
Code - 133
Longueur – longueur totale du champ de valeur.
Valeur – à définir.
Les codes supplémentaires pour la prise en charge de IP sont :
- Protocoles pris en charge – l'ensemble des identifiants de protocole de couche réseau pour les protocoles de couche réseau que ce système intermédiaire est capable de relayer.
Code - 129
Longueur - longueur totale du champ de valeur (un octet par protocole pris en charge.
Valeur - un octet NLPID (comme alloué par ISO/TR 9577) pour chaque protocole de données pris en charge.
Nombre d'octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID – identifiant de protocole de couche réseau enregistré ISO/TR 9577.
- Adresse d'interface IP – la ou les adresses IP de l'interface correspondant au SNPA sur lequel cette PDU est à transmettre.
Code - 132
Longueur – longueur totale du champ de valeur (quatre octets par adresse).
Valeur -
Nombre d'octets
+----------------------------+
| ADRESSE IP | 4
+----------------------------+
: :
: :
+----------------------------+
| ADRESSE IP | 4
+----------------------------+
ADRESSE IP – Adresse IP de 4 octets de l'interface.
- Informations d'authentification -- Informations utilisées pour authentifier la PDU
Code - 133
Longueur – longueur totale du champ de valeur
Valeur – à définir
Les codes supplémentaires pour la prise en charge IP sont :
- Protocoles pris en charge -- l'ensemble des identifiants de protocole de couche réseau pour les protocoles de couche réseau que ce système intermédiaire est capable de relayer.
Code - 129
Longueur - longueur totale du champ de valeur (un octet par protocole pris en charge).
Valeur - un octet NLPID (comme alloué par ISO/TR 9577) pour chaque protocole de données pris en charge.
Nombre d'octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID – Identifiant de protocole de couche réseau enregistré par ISO/TR 9577.
- Adresse IP d'interface -- La ou les adresses IP de l'interface correspondant au SPNA sur lequel cette PDU va être transmise.
Code - 132
Longueur - longueur totale du champ de valeur (quatre octets par adresse).
Valeur –
Nombre d'octets
+----------------------------+
| Adresse IP | 4
+----------------------------+
: :
: :
+----------------------------+
| Adresse IP | 4
+----------------------------+
Adresse IP - Adresse IP de quatre octets de l'interface.
- Informations d'authentification -- Informations utilisées pour authentifier la PDU
Code - 133
Longueur - longueur totale du champ de valeur
Valeur - à définir.
Les codes supplémentaires pour la prise en charge IP sont :
- Protocoles pris en charge – ensemble des identifiants de protocole de couche réseau pour les protocoles de couche réseau que ce système intermédiaire est capable de relayer.
Cela doit apparaître une fois dans le LSP numéro 0.
Code - 129
Longueur - longueur totale du champ de valeur (un octet par protocole pris en charge).
Valeur - un octet NLPID (comme alloué par ISO/TR 9577) pour chaque protocole de données pris en charge.
Nombre d'octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - Identifiant de protocole de couche réseau enregistré par ISO/TR 9577.
- Adresses IP d'interface -- adresses IP d'une ou plusieurs interfaces correspondant aux SNPA activés sur ce système intermédiaire (c'est-à-dire, une ou plusieurs adresses IP de ce routeur).
Ceci peut apparaître plusieurs fois, et dans un LSP avec n'importe quel numéro de LSP.
Code - 132
Longueur - longueur totale du champ de valeur (quatre octets par adresse).
Valeur –
Nombre d'octets
+----------------------------+
| ADRESSE IP | 4
+----------------------------+
: :
: :
+----------------------------+
| ADRESSE IP | 4
+----------------------------+
ADRESSE IP – Adresse IP de quatre octets
- Informations d'authentification -- Informations utilisées pour authentifier la PDU.
Code - 133
Longueur - longueur totale du champ de valeur.
Valeur - à définir.
- Informations d'accessibilité interne IP -- adresses IP au sein du domaine d'acheminement joignables directement via une ou plusieurs interfaces sur ce système intermédiaire.
Ceci peut apparaître plusieurs fois, et dans un LSP avec n'importe quel numéro de LSP. Cependant, ce champ ne doit pas apparaître dans les LSP de pseudo nœuds.
Code - 128.
Longueur - un multiple de 12.
Valeur –
Nombre d'octets
+----------------------------+
| 0 |I/E| Métrique par défaut| 1
+----------------------------+
| S | R | Métrique de délai | 1
+----------------------------+
| S | R | Métrique de coût | 1
+----------------------------+
| S | R | Métrique d'erreur | 1
+----------------------------+
| Adresse IP | 4
+----------------------------+
| Gabarit de sous-réseau | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| Métrique par défaut| 1
+----------------------------+
| S | R | Métrique de délai | 1
+----------------------------+
| S | R | Métrique de coût | 1
+----------------------------+
| S | R | Métrique d'erreur | 1
+----------------------------+
| Adresse IP | 4
+----------------------------+
| Gabarit de sous-réseau | 4
+----------------------------+
Métrique par défaut est la valeur de la métrique par défaut pour la liaison avec le voisin figurant sur la liste. Le bit 8 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré en réception. Le bit 7 de ce champ (marqué I/E) indique le type de métrique (interne ou externe) pour les quatre métriques de TOS, et doit être mis à zéro, ce qui indique des métriques internes.
Métrique de délai est la valeur de la métrique de délai pour la liaison avec le voisin figurant sur la liste. Si ce système intermédiaire ne prend pas cette métrique en charge, il devra mettre le bit "S" à 1 pour indiquer que la métrique n'est pas prise en charge. Le bit 7 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré à réception.
Métrique de coût est la valeur de la métrique de coût pour la liaison avec le voisin figurant sur la liste. Si ce système intermédiaire ne prend pas cette métrique en charge, il devra mettre le bit "S" à 1 pour indiquer que la métrique n'est pas prise en charge. Le bit 7 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré à réception.
Métrique d'erreur est la valeur de la métrique d'erreur pour la liaison avec le voisin figurant sur la liste. Si ce système intermédiaire ne prend pas cette métrique en charge, il devra mettre le bit "S" à 1 pour indiquer que la métrique n'est pas prise en charge. Le bit 7 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré à réception.
Adresse IP est une adresse Internet de quatre octets
Gabarit de sous-réseau est un gabarit de sous-réseau IP de quatre octets.
Les codes supplémentaires pour la prise en charge IP sont :
- Protocoles pris en charge – ensemble des identifiants de protocole de couche réseau pour les protocoles de couche réseau que ce système intermédiaire est capable de relayer.
Ceci doit apparaître une fois dans le LSP numéro 0.
Code - 129
Longueur - longueur totale du champ de valeur (un octet par protocole pris en charge).
Valeur - un octet NLPID (comme alloué par ISO/TR 9577) pour chaque protocole de données pris en charge.
Nombre d'octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - Identifiant de protocole de couche réseau enregistré par ISO/TR 9577 .
- Adresses IP d'interface -- adresses IP d'une ou plusieurs interfaces correspondant aux SNPA activés sur ce système intermédiaire (c'est-à-dire, une ou plusieurs adresses IP de ce routeur).
Ceci peut apparaître plusieurs fois, et dans un LSP avec n'importe quel numéro de LSP. Lorsque un routeur est à la fois routeur de niveau 1 et routeur de niveau 2, il doit inclure les mêmes adresses IP dans ses LSP de niveau 1 et de niveau 2.
Code - 132
Longueur - longueur totale du champ de valeur (quatre octets par adresse).
Valeur-
Nombre d'octets
+----------------------------+
| Adresse IP | 4
+----------------------------+
: :
: :
+----------------------------+
| Adresse IP | 4
+----------------------------+
Adresse IP - Adresse IP de 4 octets
- Informations d'authentification -- Informations utilisées pour authentifier la PDU.
Code - 133
Longueur - longueur totale du champ de valeur.
Valeur - à définir.
- Informations d'accessibilité IP internes -- adresses IP accessibles directement au sein du domaine d'acheminement via une ou plusieurs interfaces sur ce système intermédiaire.
Ceci peut apparaître plusieurs fois, et dans un LSP avec n'importe quel numéro de LSP. Cependant, ce champ ne doit pas apparaître dans les LSP de pseudo nœuds.
Code - 128.
Longueur - multiple de 12.
Valeur –
Nombre d'octets
+----------------------------+
| 0 |I/E| Métrique par défaut| 1
+----------------------------+
| S | R | Métrique de délai | 1
+----------------------------+
| S | R | Métrique de coût | 1
+----------------------------+
| S | R | Métrique d'erreur | 1
+----------------------------+
| Adresse IP | 4
+----------------------------+
| Gabarit de sous-réseau | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| Métrique par défaut| 1
+----------------------------+
| S | R | Métrique de délai | 1
+----------------------------+
| S | R | Métrique de coût | 1
+----------------------------+
| S | R | Métrique d'erreur | 1
+----------------------------+
| Adresse IP | 4
+----------------------------+
| Gabarit de sous-réseau | 4
+----------------------------+
Métrique par défaut est la valeur de la métrique par défaut pour la liaison avec le voisin figurant sur la liste. Le bit 8 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré à réception. Le bit 7 de ce champ indique le type de métrique (interne ou externe) pour les quatre métriques de TOS, et doit être mis à zéro pour indiquer les métriques internes.
Métrique de délai est la valeur de la métrique de délai pour la liaison avec le voisin figurant sur la liste. Si cet IS ne prend pas en charge cette métrique, il doit mettre le bit "S" à 1 pour indiquer que cette métrique n'est pas prise en charge. Le bit 7 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré à réception.
Métrique de coût est la valeur de la métrique des coûts pour la liaison avec le voisin figurant sur la liste. Si cet IS ne prend pas en charge cette métrique, il doit mettre le bit "S" à 1 pour indiquer que cette métrique n'est pas prise en charge. Le bit 7 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré à réception.
Métrique d'erreur est la valeur de la métrique d'erreur pour la liaison avec le voisin figurant sur la liste. Si cet IS ne prend pas en charge cette métrique, il doit mettre le bit "S" à 1 pour indiquer que cette métrique n'est pas prise en charge. Le bit 7 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré à réception.
Adresse IP est une adresse Internet de 4 octets.
Gabarit de sous-réseau est le gabarit de sous-réseau IP de 4 octets.
- Informations d'accessibilité IP externe-- adresses IP en dehors du domaine d'acheminement joignables via les interfaces sur ce système intermédiaire.
Ceci peut apparaître plusieurs fois, et dans un LSP avec n'importe quel numéro de LSP. Cependant, ce champ ne doit pas apparaître dans les LSP de pseudo nœud.
Code - 130.
Longueur - un multiple de 12.
Valeur -
Nombre d'octets
+----------------------------+
| 0 |I/E| Métrique par défaut| 1
+----------------------------+
| S | R | Métrique de délai | 1
+----------------------------+
| S | R | Métrique de coût | 1
+----------------------------+
| S | R | Métrique d'erreur | 1
+----------------------------+
| Adresse IP | 4
+----------------------------+
| Gabarit de sous-réseau | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| Métrique par défaut| 1
+----------------------------+
| S | R | Métrique de délai | 1
+----------------------------+
| S | R | Métrique de coût | 1
+----------------------------+
| S | R | Métrique d'erreur | 1
+----------------------------+
| Adresse IP | 4
+----------------------------+
| Gabarit de sous-réseau | 4
+----------------------------+
Métrique par défaut est la valeur de la métrique par défaut pour le chemin des adresses IP qui figurent sur la liste. Le bit 8 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré à réception. Le bit 7 de ce champ indique le type de métrique (interne ou externe) pour les quatre métriques de TOS, et peut être mis à zéro pour indiquer des métriques internes, ou peut être mis à 1 pour indiquer des métriques externes.
Métrique de délai est la valeur de la métrique de délai pour le chemin des adresses IP qui figurent sur la liste. Si cet IS ne prend pas en charge cette métrique, il doit mettre le bit "S" à 1 pour indiquer que cette métrique n'est pas prise en charge. Le bit 7 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré à réception.
Métrique de coût est la valeur de la métrique de coûts pour la liaison vers les adresses IP qui figurent sur la liste. Si cet IS ne prend pas en charge cette métrique, il doit mettre le bit "S" à 1 pour indiquer que cette métrique n'est pas prise en charge. Le bit 7 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré à réception.
Métrique d'erreur est la valeur de la métrique d'erreur pour la liaison vers les adresses IP qui figurent sur la liste. Si cet IS ne prend pas en charge cette métrique, il doit mettre le bit "S" à 1 pour indiquer que cette métrique n'est pas prise en charge. Le bit 7 de ce champ est réservé, et doit être mis à zéro à l'émission et ignoré à réception.
Adresse IP est une adresse Internet de quatre octets.
Gabarit de sous-réseau est un gabarit de sous-réseau IP de 4 octets.
- Informations de protocole d'acheminement inter-domaine – Informations de protocole d'acheminement inter-domaine portées de façon transparente à travers le niveau 2 pour les besoins de tout protocole inter-domaine qui pourrait fonctionner sur les systèmes intermédiaires frontaliers.
Ceci peut apparaître plusieurs fois, et dans un LSP avec n'importe quel numéro de LSP.
Code - 131.
Longueur - longueur totale du champ de valeur
Valeur –
Nombre d'octets
+-------------------------------+
|Type d'info. inter-domaine | 1
+-------------------------------+
| Informations externes | Variable
+-------------------------------+
Type d'informations inter-domaine indique le type des informations externes qui sont codées dans le champ.
Informations externes contient des informations de protocole d'acheminement inter-domaine, qui sont passées de façon transparente par le protocole IS-IS.
Les codes supplémentaires pour la prise en charge IP sont :
- Informations d'authentification -- Informations utilisées pour authentifier la PDU
Code - 133
Longueur - longueur totale du champ de valeur
Valeur - à définir
Les codes supplémentaires pour la prise en charge IP sont :
- Informations d'authentification -- Informations utilisées pour authentifier la PDU
Code - 133
Longueur - longueur totale du champ de valeur
Valeur - à définir
Les codes supplémentaires pour la prise en charge IP sont :
- Informations d'authentification -- Informations utilisées pour authentifier la PDU
Code - 133
Longueur - longueur totale du champ de valeur
Valeur - à définir
Les codes supplémentaires pour la prise en charge IP sont :
- Informations d'authentification -- Informations utilisées pour authentifier la PDU
Code - 133
Longueur - longueur totale du champ de valeur
Valeur - à définir
- Les codes supplémentaires pour la prise en charge IP sont :
- Protocoles pris en charge – ensemble des identifiants de protocole de couche réseau pour les protocoles de couche réseau que ce système intermédiaire est capable de relayer.
Cela apparaît dans les PDU ISH ISO 9542 transmises sur des liaisons point à point.
Code - 129
Longueur - longueur totale du champ de valeur (un octet par protocole pris en charge).
Valeur - un octet NLPID (comme alloué par ISO/TR 9577) pour chaque protocole de données pris en charge.
Nombre d'octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - Identifiant de protocole de couche réseau enregistré par ISO/TR 9577 .
- Informations d'authentification -- Informations utilisées pour authentifier la PDU
Code - 133
Longueur - longueur totale du champ de valeur
Valeur - à définir
6 Considérations pour la sécurité
IS-IS intégré a une disposition qui fournit le portage des informations d'authentification dans tous les paquets IS-IS. Elle est extensible à plusieurs mécanismes d'authentification. Cependant, actuellement le seul mécanisme défini est un simple mot de passe, transmis en clair sans chiffrement (voir l'Annexe D). L'utilisation d'un simple mot de passe ne procure pas une protection utile contre un comportement nuisible intentionnel. Elle devrait être plutôt vue comme une faible protection contre des erreurs accidentelles telles qu'une mauvaise configuration accidentelle. La définition des autres mécanismes d'authentification sort du domaine d'application du présent document.
Les autres aspects de la sécurité ne sont pas abordés dans le présent document.
Ross Callon
Digital Equipment Corporation
550 King Street, LKG 1-2/A19
Littleton, MA 01460-1289
508-486-5009
[1] "Protocole d'échange d'informations d'acheminement intra domaine de système intermédiaire à système intermédiaire à utiliser en conjonction avec le protocole de fourniture du service réseau en mode sans connexion (ISO 8473)", ISO DP 10589, février 1990.
[2] "Protocole de fourniture du service réseau en mode sans connexion", ISO 8473, mars 1987.
[3] "Protocole d'échange d'informations d'acheminement de système d'extrémité à système intermédiaire à utiliser e n conjonction avec le protocole de fourniture du service réseau en mode sans connexion (ISO 8473)", ISO 9542, mars 1988.
[4] R. Braden et J. Postel, "Exigences pour les routeurs de l'Internet", RFC 1009, juin 1987. (Rendue obsolète par la RFC 1812, elle-même mise à jour par la RFC 2644) (Historique).
[5] J. Moy, "Spécification de OSPF", RFC 1131, octobre 1989. (Rendue obsolète par la RFC 1247,remplacée par la RFC 1583, remplacée par la RFC 2328 , STD 54)
[6] J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet DARPA", STD 5, RFC 791, USC/Information Sciences Institute, septembre 1981.
[7] J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", STD 5, RFC 792, USC/Information Sciences Institute, septembre 1981.
[8] R. Callon, "Utilisation de l'IS-IS OSI pour l'acheminement dans les environnements TCP/IP et duels", RFC1195, décembre 1990, (Mise à jour par les RFC 1349, 5302, 5304).
[9] GOSIP Advanced Requirements Group, "Government Open Systems Interconnection Profile (GOSIP) Version 2.0 [Final Text]", Federal Information Processing Standard, U.S. Department of Commerce, National Institute of Standards and Technology, Gaithersburg, MD, octobre 1990.
[10] "Standard for Local Area Networks and Metropolitan Area Networks: Overview and Architecture of Network Standards", IEEE Standard 802.1a-1990.
Annexe A Informations de protocole d'acheminement inter-domaine
La présente annexe spécifie le contenu et le codage du champ Informations de protocole d'acheminement inter-domaine IDRPI, Inter-Domain Routing Protocol Information). Cette annexe fait partie intégrante de la spécification d'IS-IS intégré. Cependant, il est prévu que cette annexe puisse être augmentée ou subrogée par des efforts futurs sortant du domaine d'application de la spécification IS-IS.
A.1 Type d'informations inter-domaine
Comme spécifié aux paragraphes 3.4 et 5.3, le champ IDRPI comporte un champ d'un octet de type d'informations inter-domaine, plus un champ variable d'informations externes. La présente section spécifie les valeurs initiales du champ de type d'informations inter-domaine. D'autres valeurs de type d'informations inter-domaine seront allouées et entretenues dans de futures versions de la RFC "Numéros alloués".
Les types suivants ont été alloués :
Type = 0 réservé
Type = 1 local (utilise un format spécifique du domaine d'acheminement)
Type = 2 Étiquette de numéro d'AS
Type = 1 indique que les informations de protocole d'acheminement inter-domaine utilisent un format qui est local pour le domaine d'acheminement.
Type = 2 indique que les informations de protocole d'acheminement inter-domaine incluent des informations de système autonome (AS) utilisées pour étiqueter les informations d'accessibilité externe IP. Dans ce cas, les entrées d'informations de protocole d'acheminement inter-domaine doivent inclure un seul numéro d'AS, qui est utilisé pour étiqueter toutes les entrées suivantes d'accessibilité IP externe jusqu'à la fin du LSP, ou jusqu'à la prochaine occurrence du champ Informations de protocole d'acheminement inter-domaine.
Comme spécifié au paragraphe 5.3.5, l'entrée IDPRI est codée comme un champ de longueur variable, comme suit :
Code - 131
Longueur - longueur totale du champ de valeur
Valeur -
Nombre d'octets
+-------------------------------+
| Type d'info. inter-domaine | 1
+-------------------------------+
| Informations externes | Variable
+-------------------------------+
Type d'informations inter-domaine indique le type des informations externes qui sont codées dans le champ.
Informations externes contient les informations de protocole d'acheminement inter-domaine, et il est passé de façon transparente par le protocole IS-IS.
Le champ Type d'informations inter-domaine indique le type des informations qui sont contenues dans le champ Informations externes, comme suit :
Type = 0 est réservé (ne doit pas être envoyée, et doit être ignoré à réception).
Type = 1 indique que le champ Informations externes contient des informations qui suivent un format spécifié en local.
Type = 2 indique que le champ Informations externes contient une étiquette de numéro de système autonome, à appliquer aux entrées suivantes d'informations d'accessibilité externe IP. Dans ce cas, cette entrée "d'informations de protocole d'acheminement inter-domaine" doit contenir précisément un numéro d'AS de 2 octets. L'étiquette d'AS est associée aux entrées suivantes d'accessibilité IP externe, jusqu'à la fin du LSP, ou jusqu'à la prochaine occurrence du champ Informations de protocole d'acheminement inter-domaine. Dans ce cas, la Valeur contient ce qui suit :
Valeur -
Nombre d'octets
+---------------------------------+
| Type d'info. inter-domaine = 2 | 1
+---------------------------------+
| Numéro de système autonome | 2
+---------------------------------+
Annexe B Codage des paquets de numéro de séquence
Le protocole IS-IS intégré défini dans la présente spécification utilise le projet de proposition de norme ISO pour l'acheminement intra-domaine (ISO DP 10589 [1]) comme protocole d'acheminement de base, sur laquelle la prise en charge de IP peut être ajoutée.
Cependant, le DP 10589 contient une erreur concernant le codage des champs à longueur variable dans les paquets de numéro de séquence (SNP). En particulier, le DP 10589 code les champs de longueur variable dans les SNP d'une manière qui n'est pas souple (aucun champ de longueur variable supplémentaire ne peut être défini pour les paquets de numéro de séquence), et qui n'est pas cohérente avec le codage des champs de longueur variable dans les autres paquets IS-IS et ES-IS.
Le codage des champs de longueur variable dans les SNP sera corrigé dans les futures versions de 10589. Aussi, cette erreur représente la seule modification attendue à la norme 10589 qui ne pourra être rendue rétro compatible avec les mises en œuvre existantes du DP 10589. Pour cette raisons, la version actuelle de IS-IS intégré utilisera par anticipation le futur codage de la partie à longueur variable des SNP. Cela devrait permettre aux versions futures de la présente spécification d'être compatibles avec les mises en œuvre qui s'appuient sur la présente spécification.
La présente annexe spécifie le codage des SNP, tel qu'amendé pour corriger le codage des champs de longueur variable. Cette annexe fait partie intégrante de la spécification de IS-IS intégré.
Le codage des SNP pour OSI-seul est donné dans le paragraphe qui suit. Pour IP-seul ou l'utilisation intégrée, les champs de longueur variable supplémentaires spécifiés du paragraphe 5.3.6 au paragraphe 5.3.9 sont aussi applicables aux SNP.
B.1 PDU de numéro de séquence complet de niveau 1
Nombre d'octets
+--------------------------------+
| Discriminateur de protocole | 1
| d'acheminement intra-domaine |
+--------------------------------+
| Indicateur de longueur | 1
+--------------------------------+
| Ext. d'ID de version/protocole | 1
+--------------------------------+
| Réservé | 1
+--------------------------------+
| R | R | R | Type | 1
+--------------------------------+
| Version | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| Longueur de PDU | 2
+--------------------------------+
| ID de source | 7
+--------------------------------+
| Début d'ID de LSP | 8
+--------------------------------+
| Fin d'ID de LSP | 8
+================================+====================
| Champs de longueur variable | Variable
+--------------------------------+
- Discriminateur de protocole intra-domaine – constante architecturale
- Indicateur de longueur – Longueur d'en-tête en octets (33.)
- Extension d'identifiant de version/protocole - 1
- Réservé – transmis comme 0, ignoré à réception
- Type (bits 1 à 5) - 24. Noter que les bits 6, 7 et 8 sont réservés, ce qui signifie qu'ils sont transmis à 0 et ignorés à réception.
- Version - 1
- ECO – transmis à 0, ignoré à réception
- USER ECO – transmis à zéro, ignoré à réception
- Longueur de PDU – Longueur totale de cette PDU, en octets, y compris l'en-tête
- ID de source – ID à 7 octets du système intermédiaire (avec zéro ID de circuit) qui génère cette PDU de numéros de séquence.
- Début d'ID de LSP – ID à 8 octets du premier LSP dans la gamme couverte par cette PDU de numéros de séquence complète.
- Fin d'ID de LSP – ID à 8 octets du dernier LSP dans la gamme couverte par cette PDU de numéros de séquence complète.
- Champs de longueur variable – champs de la forme :
Nombre d'octets
+--------------------------------+
| Code | 1
+--------------------------------+
| Longueur | 1
+--------------------------------+
| Valeur | Longueur
+--------------------------------+
Tout code qui n'est pas reconnu dans un CSNP reçu est ignoré.
Les codes actuellement définis sont :
- Entrées de LSP – Cela peut apparaître plusieurs fois. Les champs d'option, s'ils apparaissent plus d'une fois, doivent être triés par LSPID ascendant.
Code - 9
Longueur - longueur totale du champ de valeur.
Valeur - une liste d'entrées de LSP de la forme :
Nombre d'octets
+--------------------------------+
| Durée de vie restante | 2
+--------------------------------+
| ID de LSP | 8
+--------------------------------+
| N° de séquence de LSP | 4
+--------------------------------+
| Somme de contrôle | 2
+--------------------------------+
: :
: :
+--------------------------------+
| Durée de vie restante | 2
+--------------------------------+
| ID de LSP | 8
+--------------------------------+
| N° de séquence de LSP | 4
+--------------------------------+
| Somme de contrôle | 2
+--------------------------------+
- Durée de vie restante - Durée de vie restante du LSP.
- ID de LSP - Identifiant de 8 octets du LSP auquel cette entrée se réfère.
- N° de séquence de LSP - Numéro de séquence de LSP.
- Somme ce contrôle - Somme de contrôle rapportée dans le LSP.
Les entrées doivent être triées par LSPID croissant (l'octet de numéro de LSP du LSPID est l'octet de moindre poids ).
B.2 PDU de numéro de séquence complet de niveau 2
Nombre d'octets
+--------------------------------+
| Discriminateur de protocole | 1
| d'acheminement intra-domaine |
+--------------------------------+
| Indicateur de longueur | 1
+--------------------------------+
| Ext. d'ID de version/protocole | 1
+--------------------------------+
| Réservé | 1
+--------------------------------+
| R | R | R | Type | 1
+--------------------------------+
| Version | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| Longueur de la PDU | 2
+--------------------------------+
| ID de source | 7
+--------------------------------+
| Début d'ID de LSP | 8
+--------------------------------+
| Fin d'ID de LSP | 8
+================================+====================
| Champs de longueur variable | Variable
+--------------------------------+
- Discriminateur de protocole d'acheminement intra-domaine - constante architecturale
- Indicateur de longueur - Longueur de l'en-tête en octets (33.)
- Extension d'ID de version/protocole - 1
- Réservé - transmis à 0, ignoré à réception
- Type (bits 1 à 5) - 25. Noter que les bits 6, 7 et 8 sont réservés, ce qui signifie qu'ils sont transmis à 0 et ignorés à réception.
- Version - 1
- ECO - transmis à zéro, ignoré à réception
- USER ECO - transmis à zéro, ignoré à réception
- Longueur de PDU - Longueur totale de cette PDU, en octets, y compris l'en-tête
- ID de source – ID de 7 octets du système intermédiaire (avec zéro ID de circuit) qui génère cette PDU de numéros de séquence.
- Début d'ID de LSP – ID de 8 octets du premier LSP dans la gamme couverte par cette PDU de numéros de séquence complète.
- Fin d'ID de LSP – ID de 8 octets du dernier LSP dans la gamme couverte par cette PDU de numéros de séquence complète.
- Champs de longueur variable – Champs de la forme :
Nombre d'octets
+--------------------------------+
| Code | 1
+--------------------------------+
| Longueur | 1
+--------------------------------+
| Valeur | Longueur
+--------------------------------+
Tout code qui n'est pas reconnu dans un CSNP reçu est ignoré.
Les codes actuellement définis sont :
- Entrées de LSP -- ceci peut apparaître plusieurs fois. Les champs d'option, s'ils apparaissent plus d'une fois, doivent être triés par LSPID ascendant.
Code - 9
Longueur - longueur totale du champ de valeur.
Valeur - une liste d'entrées de LSP de la forme :
Nombre d'octets
+--------------------------------+
| Durée de vie restante | 2
+--------------------------------+
| ID de LSP | 8
+--------------------------------+
| N° de séquence de LSP | 4
+--------------------------------+
| Somme de contrôle | 2
+--------------------------------+
: :
: :
+--------------------------------+
| Durée de vie restante | 2
+--------------------------------+
| ID de LSP | 8
+--------------------------------+
| N° de séquence de LSP | 4
+--------------------------------+
| Somme de contrôle | 2
+--------------------------------+
- Durée de vie restante - Durée de vie restante du LSP.
- ID de LSP - Identifiant de 8 octets du LSP auquel cette entrée se réfère.
- N° de séquence de LSP - numéro de séquence du LSP.
- Somme de contrôle - somme de contrôle rapportée dans le LSP.
Les entrées doivent être triées par LSPID croissant (l'octet de numéro de LSP du LSPID est l'octet de moindre poids ).
B.3 PDU de numéro de séquence partiel de niveau 1
Nombre d'octets
+--------------------------------+
| Discriminateur de protocole | 1
| d'acheminement intra-domaine |
+--------------------------------+
| Indicateur de longueur | 1
+--------------------------------+
| Ext. d'ID de version/protocole | 1
+--------------------------------+
| Réservé | 1
+--------------------------------+
| R | R | R | Type | 1
+--------------------------------+
| Version | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| Longueur de PDU | 2
+--------------------------------+
| ID de source | 7
+================================+====================
| Champs de longueur variable | Variable
+--------------------------------+
- Discriminateur de protocole d'acheminement intra-domaine - constante architecturale
- Indicateur de longueur - Longueur de l'en-tête en octets (17.)
- Extension d'ID de version/protocole - 1
- Réservé - transmis à 0, ignoré à réception
- Type (bits 1 à 5) - 26. Noter que les bits 6, 7 et 8 sont réservés, ce qui signifie qu'ils sont transmis à 0 et ignorés à réception.
- Version - 1
- ECO - transmis à zéro, ignoré à réception
- USER ECO - transmis à zéro, ignoré à réception
- Longueur de PDU - Longueur totale de cette PDU, en octets, y compris l'en-tête
- ID de source – ID de 7 octets du système intermédiaire (avec zéro ID de circuit) qui génère cette PDU de numéros de séquence.
- Champs de longueur variable – Champs de la forme :
Nombre d'octets
+--------------------------------+
| Code | 1
+--------------------------------+
| Longueur | 1
+--------------------------------+
| Valeur | Longueur
+--------------------------------+
Tous les codes qui ne sont pas reconnus dans un PSNP reçu sont ignorés.
Les codes actuellement définis sont :
- Entrées de LSP - ceci peut apparaître plusieurs fois. Les champs d'option, s'ils apparaissent plus d'une fois, doivent être triés par LSPID ascendant.
Code - 9
Longueur - longueur totale du champ de valeur.
Valeur - une liste d'entrées de LSP de la forme :
Nombre d'octets
+--------------------------------+
| Durée de vie restante | 2
+--------------------------------+
| ID de LSP | 8
+--------------------------------+
| N° de séquence de LSP | 4
+--------------------------------+
| Somme de contrôle | 2
+--------------------------------+
: :
: :
+--------------------------------+
| Durée de vie restante | 2
+--------------------------------+
| ID de LSP | 8
+--------------------------------+
| N° de séquence de LSP | 4
+--------------------------------+
| Somme de contrôle | 2
+--------------------------------+
- Durée de vie restante - Durée de vie restante du LSP.
- ID de LSP - Identifiant de 8 octets du LSP auquel cette entrée se réfère.
- N° de séquence de LSP - numéro de séquence de LSP.
- Somme de contrôle - somme de contrôle rapportée dans le LSP.
Les entrées doivent être triées par LSPID croissant (l'octet de numéro de LSP du LSPID est l'octet de moindre poids ).
B.4 PDU de numéro de séquence partiel de niveau 2
Nombre d'octets
+--------------------------------+
| Discriminateur de protocole | 1
| d'acheminement intra-domaine |
+--------------------------------+
| Indicateur de longueur | 1
+--------------------------------+
| Ext. d'ID de version/protocole | 1
+--------------------------------+
| Réservé | 1
+--------------------------------+
| R | R | R | Type | 1
+--------------------------------+
| Version | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| Longueur de PDU | 2
+--------------------------------+
| ID de source | 7
+================================+====================
| Champs de longueur variable | variable
+--------------------------------+
- Discriminateur de protocole d'acheminement intra-domaine - constante architecturale
- Indicateur de longueur - Longueur de l'en-tête en octets (17.)
- Extension d'ID de version/protocole - 1
- Réservé - transmis à 0, ignoré à réception
- Type (bits 1 à 5) - 27. Noter que les bits 6, 7 et 8 sont réservés, ce qui signifie qu'ils sont transmis à 0 et ignorés à réception.
- Version - 1
- ECO - transmis à zéro, ignoré à réception
- USER ECO - transmis à zéro, ignoré à réception
- Longueur de PDU - Longueur totale de cette PDU, en octets, y compris l'en-tête
- ID de source – ID de 7 octets du système intermédiaire (avec zéro ID de circuit) qui génère cette PDU de numéros de séquence.
- Champs de longueur variable – Champs de la forme :
Nombre d'octets
+--------------------------------+
| Code | 1
+--------------------------------+
| Longueur | 1
+--------------------------------+
| Valeur | Longueur
+--------------------------------+
Tous les codes qui ne sont pas reconnus dans un PSNP reçu sont ignorés.
Les codes actuellement définis sont :
- Entrées de LSP -- ceci peut apparaître plusieurs fois. Les champs d'option, s'ils apparaissent plus d'une fois, doivent être triés par LSPID ascendant.
Code - 9
Longueur - longueur totale du champ de valeur.
Valeur - une liste d'entrées de LSP de la forme :
Nombre d'octets
+--------------------------------+
| Durée de vie restante | 2
+--------------------------------+
| ID de LSP | 8
+--------------------------------+
| N° de séquence de LSP | 4
+--------------------------------+
| Somme de contrôle | 2
+--------------------------------+
: :
: :
+--------------------------------+
| Durée de vie restante | 2
+--------------------------------+
| ID de LSP | 8
+--------------------------------+
| N° de séquence de LSP | 4
+--------------------------------+
| Somme de contrôle | 2
+--------------------------------+
- Durée de vie restante - Durée de vie restante du LSP.
- ID de LSP - Identifiant de 8 octets du LSP auquel cette entrée se réfère.
- N° de séquence de LSP -numéro de séquence de LSP.
- Somme de contrôle - somme de contrôle rapportée dans le LSP.
Les entrées doivent être triées par LSPID croissant (l'octet de numéro de LSP du LSPID est l'octet de moindre poids ).
Annexe C Calcul de Dijkstra et transmission
L'Annexe C.2 de ISO DP 10589 [1] spécifie l'algorithme SPF (Dijkstra) pour le calcul des chemins avec le protocole d'acheminement IS-IS. La présente annexe spécifie des modifications à l'algorithme SPF pour la prise en charge de l'acheminement IP et duel, et spécifie une méthode compatible pour la transmission de paquets IP. Il en résultera un ordre de préférence des chemins qui est compatible avec celui spécifié au paragraphe 3.10.
La présente annexe est incluse aux fins d'information.
C.1 Algorithme SPF pour IP et utilisation duelle
La présente section spécifie un algorithme SPF pour calculer les chemins avec le protocole d'acheminement IS-IS, pour la prise en charge de TCP/IP et d'OSI. Il se fonde sur une extension de l'algorithme spécifié à l'annexe C.2 du DP ISO 10589 [1].
Un algorithme inventé par Dijkstra sous le nom de plus court chemin en premier (SPF, shortest path first) est utilisé comme base du calcul du chemin. La complexité du calcul est du carré du nombre de nœuds, ce qui peut être diminué au nombre de liaisons dans le domaine multiplié par le logarithme du nombre de nœuds pour les réseaux épars (réseaux qui ne sont pas fortement connectés).
Un certain nombre d'optimisations supplémentaires sont possibles :
1) Si la métrique d'acheminement est définie sur un petit champ fini (comme dans la présente norme), le facteur de log n peut être retiré en utilisant des structures de données qui conservent une liste distincte des systèmes pour chaque valeur de la métrique plutôt que de trier les systèmes par la distance logique.
2) Les mises à jour peuvent être effectuées de façon incrémentaire sans exiger un nouveau calcul complet. Cependant, une mise à jour complète doit être faite périodiquement pour s'assurer de la récupération de la corruption des données, et des études suggèrent qu'avec un très petit nombre de changements de liaisons (peut-être 2) la complexité de calcul espérée de la mise à jour incrémentaire excède celle d'un recalcul complet. Et donc, la présente annexe ne spécifie l'algorithme que pour la mise à jour complète.
3) Si seules les informations de LSP de système d'extrémité ont changé, il n'est pas nécessaire de recalculer l'arborescence de Dijkstra entière. Si les structures de données appropriées sont utilisées, les entrées de systèmes d'extrémité (y compris les entrées d'accessibilité IP) peuvent être attachées et détachés comme les feuilles de l'arbre et leurs entrées de base de données d'informations de transmission altérées en tant que de besoin.
L'algorithme SPF original n'acceptait pas le partage de charge sur plusieurs chemins. L'algorithme de la présente annexe permet le partage de charge en identifiant un ensemble de chemins de coût égal vers chaque destination plutôt qu'un seul chemin de moindre coût.
PATHS – Cela représente un graphe dirigé acyclique des plus courts chemins à partir du système S qui effectue le calcul. Il est mémorisé comme un ensemble de triplets de la forme <N,d(N),{Adj(N)}>, où :
N est un identifiant de système. Dans l'algorithme de niveau 1, N est un identifiant de 6 octets pour les systèmes d'extrémité OSI, un identifiant de 7 octets pour les routeurs, ou une entrée de 8 octets d'informations d'accessibilité IP internes. Pour un routeur qui n'est pas un pseudo-nœud, c'est l'identifiant de système de 6 octets , avec un octet de 0 ajouté. Pour un pseudo-nœud, c'est une vrai quantité de 7 octets, comportant les 6 octets de l'identifiant de système intermédiaire désigné plus l'octet supplémentaire alloué par le routeur de destination. Les entrées d'informations d'accessibilité IP internes consistent en une adresse IP de quatre octets plus un gabarit de sous-réseau de quatre octets, et seront toujours des feuilles, c'est-à-dire, des "systèmes d'extrémité" dans PATHS.
Dans l'algorithme de niveau 2, N est soit un identifiant de 7 octets de routeur ou de pseudo-nœud (comme dans l'algorithme de niveau 1) ; un préfixe d'adresse OSI de longueur variable ; une entrée de 8 octets d'informations d'accessibilité IP internes, ou une entrée de 8 octets d'informations d'accessibilité IP externes. Les préfixes d'adresse OSI de longueur variable, et les entrées d'informations d'accessibilité IP de 8 octets seront toujours une feuille, c'est-à-dire, un "système d'extrémité" dans PATHS. Comme ci-dessus, les entrées d'informations d'accessibilité IP consistent en une combinaison [adresse IP, gabarit de sous-réseau].
d(N) est la distance de N à S (c'est-à-dire, la valeur métrique totale de N à S).
{Adj(N)} est un ensemble d'adjacences valides que S peut utiliser pour transmettre à N.
Lorsque un système est placé sur PATHS, le ou les chemins désignés par sa position dans le graphe sont garantis comme les plus courts chemins.
ENT – C'est une liste des triplets de la forme <N,d(N),{Adj(N)}>, où N, d(N), et {Adj(N)} sont comme défini ci-dessus pour PATHS.
TENT peut intuitivement être vu comme une tentative de placement d'un système dans PATHS. En d'autres termes, le triplet <N,x,{A}> dans TENT signifie que si N était placé dans PATHS, d(N) serait x, mais N ne peut pas être placé dans PATHS tant qu'il n'est pas garanti qu'aucun chemin plus court que x n'existe.
De même, le triplet <N,x,{A,B}> dans TENT signifie que si N était placé dans PATHS, alors d(N) serait x via l'adjacence A ou B.
Note : Il est suggéré que les mises en œuvre maintiennent la base de données TENT comme un ensemble de listes des triplets de la forme <*,Dist,*>, triés par distance Dist. De plus, il est nécessaire d'être capable de traiter les systèmes qui sont des pseudo-nœuds avant tout non pseudo-nœud à la même distance Dist.
Les identifiants de système de 8 octets qui spécifient les entrées d'accessibilité IP doivent toujours pouvoir être distingués des autres identifiants de système. Comme spécifié au paragraphe 3.10, deux entrées d'accessibilité IP qui ne diffèrent que par le gabarit de sous-réseau sont considérées comme distinctes, et auront donc des identifiants de système distincts N. L'algorithme SPF va donc calculer les routes pour chacune de ces entrées, et l'entrée correcte sera choisie dans le processus de transmission.
Les métriques internes ne sont pas comparables aux métriques externes. Pour les chemins externes (chemins pour des destinations en-dehors du domaine d'acheminement), le coût d(N) du chemin de N à S peut inclure des métriques à la fois internes et externes. d(N) peut donc être conservé comme un vecteur de quantité à deux dimensions (spécifiant des valeurs de métrique interne et externe).
d(N) est initialisé à [métrique interne = 0, métrique externe = 0].
En incrémentant d(N) de 1, si la valeur de métrique interne est inférieure à la valeur maximum MaxPathMetric, la valeur de métrique interne est alors incrémentée de un et la valeur de métrique externe est laissée inchangée ; si la valeur de métrique interne est égale à la valeur maximum MaxPathMetric, la valeur de métrique interne est alors réglée à 0 et la valeur de métrique externe est incrémentée de 1. Noter que ceci peut être mis en œuvre de façon directe en conservant la métrique externe comme les bits de poids fort de la distance.
Dans le code de l'algorithme ci-dessous, la longueur de chemin courante est détenue dans une variable "tentlength". Cette variable est une quantité tentlength=[métrique interne, métrique externe] à deux dimensions, et elle est utilisée pour comparer la longueur du chemin actuel à d(N) comme décrit ci-dessus. Tentlength est incrémenté de la même manière que d(N).
L'algorithme de base, qui construit PATHS à partir de rien, commence par mettre le système qui fait le calcul sur PATHS (aucun plus court chemin pour SELF ne peut exister). TENT est alors préchargé à partir de la base de données d'adjacences locale.
Noter qu'un système n'est pas placé sur PATHS tant qu'aucun plus court chemin n'existe pour ce système. Lorsque un système N est placé sur PATHS, le chemin pour chaque voisin M de N, à travers N, est examiné, ainsi que le chemin pour N plus la liaison de N à M. Si <M,*,*> est dans PATHS, ce nouveau chemin sera plus long, et donc ignoré.
Si <M,*,*> est dans TENT, et si le nouveau chemin est plus court, la vieille entrée est retirée de TENT et le nouveau chemin est placé dans TENT. Si le nouveau chemin est de même longueur que celui dans TENT, l'ensemble des adjacences potentielles{Adj(M)} est alors réglé à l'union du vieil ensemble (dans TENT) et du nouvel ensemble {Adj(N)}. Si M n'est pas dans TENT, le chemin est alors ajouté à TENT.
Ensuite, l'algorithme trouve le triplet <N,x,{Adj(N)}> dans TENT, avec le x minimal. Note : Ceci est fait avec efficacité à cause de l'optimisation décrite ci-dessus. Lorsque la liste des triplets pour la distance Dist est épuisée, l'algorithme incrémente alors Dist jusqu'à ce qu'il trouve une liste avec un triplet de la forme <*,Dist,*>.
N est placé dans PATHS. On sait qu'aucun chemin pour N ne peut être plus court que x à ce point parce que tous les chemins à travers les systèmes qui sont déjà dans PATHS ont été pris en considération, et que les chemins à travers les systèmes dans TENT doivent encore être supérieurs à x parce que x est minimal dans TENT.
Quand TENT est vide, PATHS est complet.
Noter que les métriques externes ne peuvent survenir que dans les entrées "Informations d'accessibilité IP externes", qui correspondent à une feuille (c'est-à-dire, les systèmes d'extrémité dans PATHS). Tout chemin qui utilise une entrée avec une métrique externe sera toujours considéré comme moins désirable que toute entrée qui utilise une métrique interne. Cela implique que dans l'addition de systèmes à PATHS, tous les systèmes joignables via des chemins internes sont toujours ajoutés avant tout système joignable via des chemins externes.
L'algorithme de traitement de décision doit fonctionner une fois pour chaque métrique d'acheminement prise en charge (c'est-à-dire, pour chaque type de service pris en charge). Un routeur de niveau 1 fait tourner l'algorithme en utilisant la base de données de LSP de niveau 1 pour calculer les chemins de niveau 1 (pour les routeurs de niveau 1 qui ne sont pas des routeurs de niveau 2, cela inclut le chemin vers le routeur rattaché de niveau 2 le plus proche). Les routeurs de niveau 2 font aussi fonctionner séparément l'algorithme en utilisant la base de données de LSP de niveau 2 pour calculer les chemins de niveau 2. Les routeurs de niveau 2 à capacité IP doivent garder les chemins IP internes de niveau 2 séparés des chemins IP externes de niveau 2.
Noter que cela implique que les routeurs qui sont à la fois des routeurs de niveau 1 et de niveau 2, et qui prennent en charge toutes les quatre métriques d'acheminement, doivent faire fonctionner huit fois l'algorithme SPF (en supposant que la réparation de partition n'est pas mise en œuvre).
Si ce système est un routeur de niveau 2 qui prend en charge la fonction facultative de réparation de partition, l'algorithme de traitement de décision doit fonctionner deux fois pour calculer les chemins de niveau 1 pour la métrique par défaut. Cette première exécution est faite pour déterminer quelles adresses de zone manuelle manualAreaAddresses de la zone sont joignables dans cette partition, et pour choisir un routeur désigné de niveau 2 de partition pour la partition. Le routeur désigné de niveau 2 de partition va déterminer si la zone est partitionnée et va créer des liaisons virtuelles de niveau 1 vers les autres routeurs désignés de niveau 2 de partition dans la zone afin de réparer la partition de niveau 1. Ceci est décrit plus en détails au paragraphe 7.2.10 de [1].
L'algorithme SPF spécifié ici va calculer les chemins pour OSI et pour IP. En particulier, les chemins sont calculés pour tous les identifiants N de système, où N peut spécifier un système d'extrémité OSI, l'adresse OSI d'un routeur, ou une entrée d'accessibilité IP. En calculant la base de données de transmission, c'est un problème spécifique de la mise en œuvre de savoir si la base de données de transmission IP est conservée séparée de la base de données de transmission OSI. Lorsque c'est approprié, la présente annexe se réfèrera séparément aux entrées dans ces deux bases de données de transmission. Ceci n'est pas destiné à empêcher une méthode de mise en œuvre spécifique.
OSI et IP utilisent des mécanismes distincts pour déterminer si un paquet est dans la zone (en particulier, OSI utilise les adresses de zone, et IP détermine si une destination n'est pas dans une zone en regardant dans la base de données de transmission de niveau 1 et en déterminant qu'aucune entrée n'existe pour cette destination au sein de la zone). Le chemin pour le plus proche routeur de niveau 2 va résulter en des entrées distinctes dans la base de données de transmission pour OSI et pour IP. Pour IP, le chemin vers le plus proche routeur de niveau 2 rattaché peut être entré dans la base de données de transmission comme chemin par défaut (c'est-à-dire, un chemin avec un gabarit de sous-réseau tout à 0).
Une approche serait de mettre les résultats de chaque algorithme de Dijkstra dans une base de données de transmission séparée. Pour un routeur qui prend en charge à la fois l'acheminement de niveau 1 et de niveau 2 (y compris les chemins internes et externes de niveau 2), et qui prend en charge les quatre types de service, il en résulterait douze bases de données de transmission séparées pour IP. Les mises en œuvre peuvent choisir de minimiser le nombre de bases de données de transmission en combinant les informations provenant de plusieurs calculs de Dijkstra en une seule base de données par type de service pris en charge. Ceci est discuté au paragraphe C.2 ci-dessous.
L'algorithme SPF spécifié au paragraphe C.2.3 de [1] est amendé pour apparaître comme suit :
Étape 0 : Initialiser TENT et PATHS à vide. Initialiser tentlength à [internalmetric=0, externalmetric=0].
(tentlength est la longueur de chemin pathlength des éléments dans TENT qu'on examine.)
1) Ajouter <SELF,0,W> à PATHS, où W est une valeur particulière qui indique que le trafic pour SELF est passé au traitement interne (plutôt que transmis).
2) Pré charger maintenant TENT avec la base de données des adjacences locales (chaque entrée faite dans TENT doit être marquée comme étant soit un système d'extrémité soit un routeur pour permettre que la vérification à la fin de l'étape 2 se fasse correctement - Noter que chaque entrée d'accessibilité IP locale est incluse comme une adjacence, et est marquée comme étant un système d'extrémité). Calculer, pour chaque adjacence Adj(N) (y compris les adjacences manuelles OSI de niveau 1, ou les adresses joignables à capacité OSI de niveau 2, et les entrées d'accessibilité IP) sur les circuits activés, pour le système N de SELF dans l'état "Up" :
d(N) = coût du circuit parent de l'adjacence (N), obtenue de la métrique.k , où k = un de {métrique par défaut, métrique par délai, métrique des coûts, métrique d'erreurs}
Adj(N) = le nombre d'adjacences des adjacences à N
3) Si un triplet <N,x,{Adj(M)}> est dans TENT, alors :
Si x = d(N), alors {Adj(M)} <--- {Adj(M)} U {Adj(N)}.
4) Si N est un routeur ou une entrée de système d'extrémité OSI, et s'il y a maintenant plus d'adjacences dans {Adj(M)} que le maximumPathSplits, retirer alors l'excès d'adjacences comme décrit au paragraphe 7.2.7 de [1]. Si N est une entrée d'accessibilité IP, les adjacences en excès peuvent alors être retirées si désiré. Cela n'affectera pas la rectitude de l'acheminement; mais peut éliminer le déterminisme des chemins IP (c'est-à-dire que les paquets IP suivent toujours les chemins optimaux au sein d'une zone, mais lorsque des chemins également bons existent, ils ne suivent pas nécessairement précisément le chemin qu'un routeur particulier aurait prévu).
5) Si x < d(N), ne rien faire.
6) Si x > d(N), retirer <N,x,{Adj(M)}> de TENT et ajouter le triplet <N,d(N),{Adj(N)}>.
7) Si il n'y a pas de triplet <N,x,{Adj(M)}> dans TENT, ajouter alors <N,d(N),{Adj(N)}> à TENT.
8) Ajouter maintenant les systèmes avec lesquels le routeur local n'a pas d'adjacences, mais qui sont mentionnés dans les LSP de pseudo-nœud voisins. L'adjacence pour de tels systèmes est réglée à celle du routeur désigné. Noter que ceci n'inclut pas les entrées d'accessibilité IP provenant des LSP de pseudo-nœuds voisins. En particulier, les LSP de pseudo-nœud n'incluent pas d'entrées d'accessibilité IP.
9) Pour tous les circuits de diffusion dans l'état "On", trouver le LSP de pseudo-nœud pour ce circuit (précisément, le LSP avec le numéro zéro et avec les 7 premiers octets de LSPID égaux à LnCircuitID pour ce circuit, où n est 1 (pour l'acheminement de niveau 1) ou 2 (acheminement de niveau 2)). Si il est présent, pour tous les voisins N rapportés dans tous les LSP de ce pseudo-nœud qui n'existent pas dans TENT, ajouter une entrée <N,d(N),{Adj(N)}> à TENT, où :
d(N) = métrique.k du circuit.
Adj(N) = le numéro d'adjacence de l'adjacence au DR.
10) Aller à l'étape 2.
Étape 1 : Examiner la PDU d'état de liaison zéroïsée de P, le système qui vient d'être placé sur PATHS (c'est-à-dire, le LSP avec les mêmes 7 premiers octets de LSPID comme P, et le LSP de numéro zéro).
1) Si ce LSP est présent, et si le bit "Infinite Hippity Cost" est à zéro, pour chaque LSP de P (c'est-à-dire, tous les LSP avec les mêmes 7 premiers octets de LSPID et de P, sans considération de la valeur du numéro de LSP ) calculer alors :
dist(P,N) = d(P) + métrique.k(P,N)
pour chaque voisin N (aussi bien système d'extrémité que routeur) du système P. Si le bit "Infinite Hippity Cost" est mis à 1, ne considérer que les systèmes d'extrémité voisins du système P. Noter que les systèmes d'extrémité voisins du système P incluent les entrées d'adresse IP joignables incluses dans les LSP provenant du système P. Ici, d(P) est le second élément du triplet <P,d(P),{Adj(P)}>, et métrique.k(P,N) est le coût de la liaison de P à N tel que rapporté dans la PDU d'état de liaison de P.
2) Si dist(P,N) > MaxPathMetric, ne rien faire alors.
3) Si <N,d(N),{Adj(N)}> est dans PATHS, ne rien faire alors.
Note : d(N) doit être inférieur à dist(P,N), ou autrement N n'aurait pas été mis dans PATHS. On peut faire ici une autre vérification de sûreté supplémentaire pour s'assurer que d(N) est en fait inférieur à dist(P,N)
4) Si un triplet <N,x,{Adj(N)}> est dans TENT, alors :
a) Si x = dist(P,N), alors {Adj(N)} <-- {Adj(N)} U {Adj(P)}.
b) Si N est un routeur ou un système d'extrémité OSI, et si il y a maintenant plus d'adjacences dans {Adj(N)} que maximumPath Splits, retirer alors les adjacences excédentaires, comme décrit au paragraphe 7.2.7 de [1]. Pour les entrées d'accessibilité IP, les adjacences excédentaires peuvent être retirées ad libitum. Cela n'affectera pas la correction de l'acheminement, mais peut éliminer le déterminisme des chemins IP (c'est-à-dire que les paquets IP suivront encore les chemins optimaux au sein d'une zone, mais lorsque plusieurs chemins également bons existent, ils ne suivront pas nécessairement précisément le chemin qu'un routeur particulier aurait prévu).
c) Si x < dist(P,N), ne rien faire.
d) Si x > dist(P,N), retirer <N,x,{Adj(N)}> de TENT, et ajouter <N,dist(P,N),{Adj(P)}>
5) Si aucun triplet <N,x,{Adj(N)}> n'est dans TENT, ajouter alors <N,dist(P,N),{Adj(P)}> à TENT.
Étape 2 : Si TENT est vide, arrêter. Autrement :
1) Trouver l'élément <P,x,{Adj(P)}>, avec x minimal comme suit :
a) Si un élément <*,tentlength,*> reste dans TENT dans la liste pour tentlength, choisir cet élément. Si il y a plus d'un élément dans la liste pour tentlength, choisir un des éléments (s'il en est) pour un système qui est un pseudo-nœud de préférence à un qui ne l'est pas. Si il n'y a plus d'élément dans la liste pour tentlength, incrémenter tentlength et répéter l'étape 2.
b) Retirer <P,tentlength,{Adj(P)}> de TENT.
c) Ajouter <P,d(P),{Adj(P)}> à PATHS.
d) Si c'est le processus de décision de niveau 2 qui fonctionne, et si le système qui vient d'être ajouté à PATHS se désigne lui-même dans la liste comme système intermédiaire de niveau 2 de partition désignée, ajouter alors en plus <AREA.P,d(P),{Adj(P)}> à PATHS, où AREA.P est le titre d'entité réseau de l'autre extrémité de la liaison virtuelle, obtenu en prenant le premier AREA figurant dans la liste du LSP de P et en ajoutant l'identifiant de P.
e) Si le système qui vient d'être ajouté à PATHS était un système d'extrémité,aller à l'étape 2. Autrement, passer à l'étape 1.
NOTE - Dans le contexte de niveau 2, les "systèmes d'extrémité" sont l'ensemble des préfixes d'adresse joignable (pour OSI), l'ensemble des adresses de zone à coût zéro (encore, pour OSI), plus l'ensemble des entrées d'accessibilité IP (internes et externes).
C.2 Transmission des paquets IP
L'algorithme SPF spécifié à la section C.1 peut être utilisé pour calculer (logiquement) des tableaux de transmission IP séparés pour chaque type de service, et pour les chemins des niveaux 1 et 2 internes, et de niveau 2 externes. Le paragraphe C.2.1 décrit comment transmettre les paquets IP, sur la base de ces bases de données de transmission multiples. Le paragraphe C.2.2 décrit comment plusieurs bases de données de transmission peuvent être combinées en une seule base de données de transmission par TOS pris en charge.
Pour les routeurs de niveau 1 seul :
- Déterminer si l'adresse IP de destination correspond à une entrée dans le tableau de transmission de niveau 1 pour le TOS spécifié.
- Déterminer si f l'adresse IP de destination correspond à une entrée dans le tableau de transmission de niveau 1 pour le TOS par défaut.
- Si le TOS par défaut résulte en une entrée plus spécifique, transmettre conformément au TOS par défaut.
- Si des entrées également spécifiques sont trouvées, ou si le TOS spécifié résulte en une entrée plus spécifique, transmettre conformément au TOS spécifié.
- Si aucune entrée n'a été trouvée (ce qui inclut pas d'entrée de chemin par défaut), la destination est alors injoignable.
Note : Pour les routeurs de niveau 1 seul, le chemin pour le plus proche routeur de niveau 2 rattaché sera entré dans la base de données de transmission comme un chemin par défaut (c'est-à-dire, un chemin avec un gabarit de sous-réseau qui est tout à 0). Et donc ce dernier événement (pas d'entrée trouvée) ne peut survenir que si il n'y a pas de routeur de niveau 2 rattaché joignable dans la zone.
Pour les routeurs qui sont à la fois des routeurs de niveau 1 et 2 :
- Déterminer si l'adresse IP de destination correspond à une entrée dans le tableau de transmission de niveau 1 pour le TOS spécifié.
- Déterminer si l'adresse IP de destination correspond à une entrée dans le tableau de transmission de niveau 1 pour le TOS par défaut.
- Si le TOS par défaut résulte en une entrée plus spécifique (c'est-à-dire, plus de bits dans le gabarit de sous-réseau prennent la valeur 1), transmettre conformément au TOS par défaut.
- Si on trouve des entrées également spécifiques, ou si le TOS spécifié résulte en une entrée plus spécifique, transmettre conformément au TOS spécifié.
- Si aucune entrée n'est trouvée :
- Déterminer si l'adresse IP de destination correspond à une entrée dans le tableau de transmission interne de niveau 2 pour le TOS spécifié.
- Déterminer si l'adresse IP de destination correspond à une entrée dans le tableau de transmission interne de niveau 2 pour le TOS par défaut.
- Si le TOS par défaut résulte en une entrée plus spécifique, transmettre conformément au TOS par défaut.
- Si des entrées également spécifiques sont trouvées, ou si le TOS spécifié résulte en une entrée plus spécifique, transmettre conformément au TOS spécifié.
- Si aucune entrée n'est trouvée :
- Déterminer si l'adresse IP de destination correspond à une entrée dans le tableau de transmission externe de niveau 2 pour le TOS spécifié.
- Déterminer si l'adresse IP de destination correspond à une entrée dans le tableau de transmission externe de niveau 2 pour le TOS par défaut
- Si le TOS par défaut résulte en une entrée plus spécifique, transmettre conformément au TOS par défaut.
- Si des entrées également spécifiques sont trouvées, ou si le TOS spécifié résulte en une entrée plus spécifique, transmettre conformément au TOS spécifié.
- Si aucune entrée n'est trouvé, la destination est alors injoignable
Pour les routeurs de niveau 2 seul, l'algorithme ci-dessus peut être utilisé, sauf dans la mesure où s'il n'y a pas de base de données de transmission de niveau 1, les étapes correspondantes peuvent être sautées.
Comme exposé au paragraphe 3.10.2, pour les routeurs de niveau 2 qui annoncent des adresses résumées configurées manuellement dans leurs LSP de niveau 2, il va exister dans certains cas des adresses IP qui correspondent à des adresses configurées manuellement, mais qui ne correspondent à aucune adresses joignable via l'acheminement de niveau 1 dans la zone. Les paquets pour de telles adresses sont traités conformément aux règles spécifiées au paragraphe 3.10.2. Cela peut se faire en ajoutant l'entrée configurée manuellement de [adresse IP, gabarit de sous-réseau] à la base de données de transmission de niveau 2 (pour le TOS approprié), avec une adresse particulière de "prochain bond" qui spécifie que les paquets pour lesquels cette entrée est choisie sont à éliminer. Cela va fonctionner correctement parce que les entrées les plus désirables (comme celles qui livrent le paquet via l'acheminement de niveau 1 à la destination correcte, ou un chemin de niveau 2 plus spécifique) vont automatiquement prendre le pas, conformément aux règles de transmission spécifiées ci-dessus. Les chemins moins désirables (tels que ceux qui utilisent un chemin externe de niveau 2 pour l'entrée "chemin par défaut") ne sont pas possibles parce que les autres routeurs de niveau 2 vont croire les résumés d'adresse annoncés par ce routeur.
Les multiples bases de données de transmission utilisées dans la méthode de base de transmission du paragraphe C.2.1 peuvent être réduites en combinant les multiples bases de données en une seule base de données pour chaque TOS pris en charge.
Pour réduire les bases de données de transmission IP, on suppose que pour deux entrées d'adresse quelconques qui se chevauchent, soit les entrées sont identiques, soit une gamme contient l'autre. En d'autres termes, pour deux entrées quelconques [adresse IP, gabarit de sous-réseau] A et B, si il y a au moins une adresse IP qui correspond aux deux entrées, alors soit : (i) les deux entrées sont identiques; soit (ii) l'entrée A contient l'entrée B (c'est-à-dire que toute adresse IP qui correspond à l'entrée B correspond aussi à l'entrée A) ; soit (iii) l'entrée B contient l'entrée A (toute adresse IP qui correspond à l'entrée A correspond aussi à l'entrée B).
Les gabarits de sous-réseau non contigus peuvent être configurés de façon à violer cette hypothèse. Par exemple, considérons les deux entrées :
- A=[address="01010101 00000101 00000000 00000000", mask="11111111 00001111 00000000 00000000"]
- B=[address="01010101 01010000 00000000 00000000", mask="11111111 11110000 00000000 00000000"]
Dans ce cas aucune des entrées ne contient l'autre. Précisément :
- il y a des adresses IP qui correspondent à la fois à A et à B (par exemple, "01010101 01010101 xxxxxxxx xxxxxxxx"),
- il y a des adresses IP qui correspondent à A mais pas à B (par exemple, "01010101 11110101 xxxxxxxx xxxxxxxx")
- il y a des adresses IP qui correspondent à B mais pas à A (par exemple, "01010101 01011111 xxxxxxxx xxxxxxxx").
La réduction des multiples bases de données de transmission pour chaque TOS à une seule base de données pour chaque TOS se fonde sur l'utilisation de l'acheminement "à la meilleure correspondance", combinée à la réduction des entrées placées dans la base de données de transmission afin d'éliminer les entrées qui ne seront pas choisies (sur la base de l'ordre de préférence des chemins spécifié au paragraphe 3.10). L'algorithme spécifique de la création de la base de données de transmission IP peut être décrite comme suit :
1) Utiliser l'algorithme de Dijkstra décrit au paragraphe C.1 pour créer des bases de données de transmission séparées pour chaque TOS pris en charge pour les chemins de niveau 1, les chemins internes de niveau 2, et les chemins externes de niveau 2. (Noter que chaque entrée de la base de données de transmission va spécifier une combinaison [adresse IP, gabarit de sous-réseau], ainsi que le routeur du prochain bond pour les paquets IP qui correspondent à cette entrée).
2) Pour chaque entrée de chemin de niveau 1 qui a été placée dans la base de données de transmission IP de niveau 1 pour un TOS spécifique, copier cette entrée dans la base de données de transmission IP globale pour ce TOS.
3) Pour chaque entrée de chemin X qui a été placé dans les bases de données de transmission IP internes de niveau 2 pour un TOS spécifique, chercher les entrées qui se chevauchent dans la base de données de transmission IP de niveau 1 pour le TOS spécifique, et aussi pour le TOS par défaut :
a) Si il y a une entrée Y en chevauchement dans la base de données de transmission de niveau 1 (pour le TOS spécifique, ou pour le TOS par défaut) telle que soit (i) Y contienne X ; soit (ii) Y est identiquement spécifique de X ; ignorer alors l'entrée X.
b) Autrement, copier l'entrée X dans la base de données de transmission IP globale pour le TOS spécifique.
4) Pour chaque entrée de chemin X qui a été placée dans la base de données de transmission IP externe de niveau 2 pour un TOS spécifique, chercher les entrées en chevauchement dans la base de données de transmission IP de niveau 1 pour le TOS spécifique, et pour le TOS par défaut, et dans la base de données de transmission IP interne de niveau 2 pour le TOS spécifique , et pour le TOS par défaut.
a) Si il y a une entrée Y en recouvrement telle que soit (i) Y contient X ; soit (ii) Y est identiquement spécifique à X ; ignorer alors l'entrée X.
b) Autrement, copier l'entrée X dans la base de données de transmission IP globale pour le TOS spécifique.
Cette méthode va résulter en une seule base de données de transmission pour chaque TOS pris en charge. La transmission des paquets peut alors être simplifiée pour être comme suit :
1) Pour les paquets IP qui se transposent dans la métrique du TOS par défaut (ou dans une métrique de TOS non prise en charge), chercher la base de données de transmission du TOS par défaut et choisir l'entrée qui a la correspondance la plus spécifique. Transmettre le paquet en conséquence.
2) Pour les paquets qui se transposent dans une métrique de TOS spécifique (autre que par défaut), chercher la base de données de transmission du TOS spécifique et choisir l'entrée j à la correspondance la plus spécifique. Chercher aussi la base de données de transmission du TOS par défaut et choisir l'entrée k qui a la correspondance la plus spécifique. Transmettre le paquet comme suit :
a) Si k est plus spécifique que j, transmettre conformément à l'entrée k ;
b) Si j et k sont également spécifiques, transmettre conformément à l'entrée j ;
c) Si j est plus spécifique que k, transmettre conformément à l'entrée j
Annexe D Utilisation du champ d'authentification
L'utilisation du champ d'authentification sort du domaine d'application de la présente spécification. Cependant, il y a un besoin urgent d'un mécanisme simple de détection d'erreur/authentification (comme un simple mot de passe) pour protéger de certains types d'erreurs. La présente annexe propose donc une utilisation possible de ce champ.
Cette annexe n'est incluse qu'à des fins d'information.
D.1 Le champ d'authentification dans les paquets IS-IS
Tous les paquets IS-IS peuvent facultativement inclure le champ d'authentification, tel que décrit aux paragraphes 3.9 et à la section 5 de la présente spécification. Comme décrit dans la section 5, le champ d'authentification est codé comme un triplet (Code, Longueur, Valeur). La présente annexe propose que le contenu du champ Valeur consiste en un champ "Type d'authentification" de un octet, plus un champ "Informations d'authentification" de longueur variable. Une valeur spécifique du "type d'authentification" est allouée aux mots de passe, transmis en clair sans chiffrement. Le champ d'authentification est codé comme suit :
- Informations d'authentification -- Informations utilisées pour authentifier la PDU
Code - 133
Longueur - longueur totale du champ de valeur
Valeur -
Nombre d'octets
+--------------------------------+
| Type d'authentification | 1
+--------------------------------+
| Informations d'authentification| variable
+--------------------------------+
Le type d'authentification est alloué comme suit :
Type = 0 réservé
Type = 1 simple mot de passe
Type > 1 réservé
D.2 Authentification de type 1 - simple mot de passe
Lorsqu'on utilise ce type d'authentification, un mot de passe de longueur variable est passé en clair (c'est-à-dire, non chiffré) dans le champ Informations d'authentification.
Avertissement : L'utilisation d'un simple mot de passe ne fournit pas une protection utile contre les mauvais comportements intentionnels. En particulier, dans la mesure où le mot de passe est transmis en clair sans chiffrement, il est facile à un système hostile d'intercepter les mots de passe, et de transmettre des paquets authentifiés. L'utilisation de simples mots de passe ne devrait être considérée que comme une faible protection contre les erreurs accidentelles telles qu'une mauvaise configuration accidentelle.
Le mot de passe doit être configuré sur la base de la liaison, de la zone, et du domaine. Précisément, lorsque cette forme d'authentification est utilisée :
- les paquets Hello IS-IS et Hello 9542 IS doivent contenir le mot de passe de liaison ;
- les paquets d'état de liaison de niveau 1 doivent contenir le mot de passe de zone ;
- les paquets d'état de liaison de niveau 2 doivent contenir le mot de passe de domaine ;
- les paquets de numéro de séquence de niveau 1 doivent contenir le mot de passe de zone ;
- les paquets de numéro de séquence de niveau 2 doivent contenir le mot de passe de domaine.
De même, chacun de ces trois mots de passe doit être configuré avec : (i) "Mot de passe transmis", dont la valeur est un seul mot de passe, et (ii) "Mots de passe reçus", dont la valeur est un ensemble de mots de passe. La valeur de Mot de passe transmis est toujours transmise. Cependant, tout mot de passe contenu dans l'ensemble de mots de passe reçus sera accepté à réception. Cette méthode permet un changement en douceur des mots de passe sans perte temporaire de connexité.
Par exemple, considérons le cas où une zone a un mot de passe de zone configuré "OLDAREAPASSWORD". Dans ce cas, la valeur du mot de passe de zone transmis est réglée à OLDAREAPASSWORD, et la valeur de mot de passe de zone reçu est réglée à {OLDAREAPASSWORD}. Supposons qu'on désire changer le mot de passe de zone en "NEWERPASSWORD". La première étape sera de configurer manuellement tous les routeurs de la zone pour régler la valeur du mot de passe de zone reçu à {OLDAREAPASSWORD, NEWERPASSWORD}. Lorsque cette étape est achevée, tous les routeurs de la zone vont alors encore utiliser le vieux mot de passe OLDAREAPASSWORD dans leurs LSP de niveau 1 et leurs SNP. Cependant, ils vont aussi accepter le mot de passe de remplacement NEWERPASSWORD. La seconde étape sera de configurer les routeurs de la zone pour régler le mot de passe de zone transmis à NEWERPASSWORD. Lorsque la seconde étape est achevée, tous les routeurs vont alors utiliser la nouvelle valeur du mot de passe de zone, mais vont accepter aussi la vieille valeur. Finalement, la troisième étape est de changer tous les routeurs de la zone pour qu'ils aient le mot de passe de zone réglé à {NEWERPASSWORD}.
En configurant les valeurs transmises et reçues du mot de passe de cette manière, il est possible de maintenir un fonctionnement correct continu. Par exemple, au milieu de la seconde étape de l'exemple ci-dessous, certains des routeurs de la zone vont transmettre les LSP de niveau 1 et les SNP en utilisant le vieux mot de passe OLDAREAPASSWORD, et certains vont transmettre les LSP de niveau 1 et les SNP en utilisant le nouveau mot de passe NEWERPASSWORD. Cependant, durant la seconde étape de la transition, tous les routeurs de la zone vont accepter les LSP de niveau 1 et les SNP utilisant l'un ou l'autre mot de passe.
Annexe E Interaction de IS-IS intégré avec les brouteurs
Un "brouteur" est un appareil qui fonctionne à la fois comme un pont et comme un routeur. Un type possible de brouteur agit comme routeur pour le trafic IP, et agit comme pont pour tous les autres types de trafic.
Selon la manière dont est mis en œuvre un brouteur, et selon la topologie du réseau, il peut résulter une obscure bogue de l'interaction du protocole IS-IS intégré et des brouteurs. Le présent appendice donne un exemple de la bogue, et propose une correction simple au fonctionnement des brouteurs pour régler le problème.
La présente annexe n'est incluse qu'aux fins d'information.
Supposons que nous ayons un brouteur qui traite les paquets IP comme si il était un routeur IP normal, et qu'il traite tous les autres paquets comme si il était un pont.
Supposons que deux routeurs "X" et "Y" (qui mettent en œuvre le protocole IS-IS intégré), deux Ethernets et un brouteur B soient tous connectés comme suit :
| |
+----+----+ +-----+---+
| Routeur | | Routeur |
| X | | Y |
+----+----+ +-----+---+
| |
-----+------------+- -+---------- --+----
| |
+-+-----+--+
| Brouteur |
| B |
+----------+
Supposons ici que X et Y utilisent le protocole IS-IS intégré, et sont tous deux des routeurs de niveau 1 dans la même zone. Donc X et Y envoient des paquets Hello IS-IS sur le LAN. Ces paquets Hello sont reçus et transmis par le brouteur (en utilisant les fonctions de pont normales). De même, X et Y reçoivent respectivement les paquets de LSP IS-IS l'un de l'autre. De cette façon, il apparaît au brouteur que X et Y échangent des paquets OSI, et ainsi ils sont transmis en utilisant les fonctions de pont normales. Il semble à X et Y qu'ils sont sur le même LAN, et donc ils apprennent leurs adresses Ethernet à 48 bits respectives et échangent les informations d'acheminement.
Maintenant, supposons que X reçoive un paquet IP, qu'il a besoin de transmettre via Y. Comme X pense que lui et Y sont sur le même Ethernet, il envoie directement le paquet IP, en utilisant l'encapsulation Ethernet normale et en utilisant l'adresse Ethernet à 48 bits de Y comme adresse de destination dans l'en-tête Ethernet. Le brouteur B, se voyant comme un pont dit : "ceci est un paquet IP, je ne transmet donc pas comme un pont". Le brouteur B, lorsqu'il se pense en routeur IP dit : "ceci est un paquet IP, et je sais transmettre les paquets IP. Cependant, ceci est envoyé à une adresse Ethernet qui n'est pas moi, et donc, je l'ignore". Le résultat est que le paquet IP n'est pas transmis.
Ce problème se rapporte directement au fait que X et Y échangent des paquets OSI pour déterminer la connexité du chemin entre eux, mais ensuite ils essayent d'envoyer des paquets IP sur le chemin. Aussi, il y a un appareil sur le chemin entre X et Y qui traite différemment les paquets OSI et les paquets IP.
Noter aussi que ce problème peut survenir dans des topologies plus complexes, chaque fois qu'un brouteur traite des paquets OSI et des paquets IP d'une manière fondamentalement différente.
Une solution est que le brouteur B soit un petit peu plus sophistiqué. En particulier, il faudrait qu'il utilise les règles suivantes :
- Pour les paquets qui ne sont pas des paquets IP, agir comme pont (c'est ce qu'il faisait avant).
- Pour les paquets IP envoyés à une adresse Ethernet de diffusion ou de diffusion groupée, agir comme un routeur IP (c'est aussi la même chose qu'avant).
- Pour les paquets IP envoyés à ma ou mes propres adresses Ethernet à 48 bits, agir comme un routeur IP (c'est aussi la même chose qu'avant).
- Pour les paquets IP envoyés à une seule adresse de station à 48 bits qui n'est pas une de mes adresses, agir comme pont (C'EST NOUVEAU).
Avec ce changement, le paquet IP transmis de X à Y est transmis par le brouteur, agissant comme un pont. Cela permet au brouteur et aux routeurs multi protocoles d'interopérer correctement.
Une solution de remplacement serait que le brouteur achemine également OSI et IP. Si le brouteur utilisait IS-IS intégré à cette fin, il pourrait faire partie du même domaine d'acheminement et interopérer comme tout autre routeur duel (sauf pour la capacité de ponter d'autres suites de protocoles). Si il utilise d'autres protocoles pour acheminer OSI et IP, il aura alors besoin de faire partie d'un autre domaine d'acheminement, et pourrait interopérer avec les routeurs IS-IS intégré comme tout autre routeur externe.