Ce document explique le décodage RIF (Routing Information Field) et le pontage Token Ring.
Les trames Token Ring ont une structure similaire aux trames 802.3 Ethernet et FDDI (Fiber Distributed Data Interface). Ces trames ont des adresses source et de destination, ainsi qu’une séquence de contrôle de trame (FCS) et une section pour transporter les données. Les délimiteurs de début et de fin sont également courants.
Les trames Token Ring, mais ont également des fonctions supplémentaires. Ceux-ci incluent :
Champ RIF (Routing Information Field) (facultatif)
Contrôle d'accès (CA)
Champs Frame Control (FC) et Frame Status (FS)
Vous pouvez également utiliser le premier bit de l’adresse source afin d’indiquer la présence d’un RIF. Mais un seul champ est relatif lorsque vous étudiez le pontage SRB (Source-Route Bridging).
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Le premier bit de l’adresse source doit être défini sur 1 afin de prendre en charge un RIF.
Le FIF est un domaine assez compliqué. Il stocke la combinaison de numéros de sonnerie et de numéros de pont qu’une trame traverse entre les stations d’extrémité. Le RIF possède également un champ de contrôle à deux octets qui fournit diverses caractéristiques du RIF lui-même. Deux stations qui communiquent sur un réseau SRB ou RSRB (Remote Source-Route Bridging) utilisent toujours le même RIF pendant la durée de la session.
La partie anneau-pont du RIF entre PC A et PC B dans le schéma précédent est 00AF.00B0.
Les adresses LAA (Local Administered Addresses) sont généralement visibles sur les stations Token Ring, bien qu’il soit possible d’attribuer des LAA aux stations Ethernet et FDDI. Dans les LAA, le deuxième bit de la première quartet est défini sur 1.
L’une des compétences requises pour la prise en charge des réseaux Token Ring est la possibilité de convertir des schémas de numérotation hexadécimaux en schémas binaires si nécessaire. Token Ring fournit presque toutes ses informations en hexadécimal, mais la structure sous-jacente est basée sur des chiffres binaires. La représentation hexadécimale masque généralement une partie de la structure sous-jacente. Vous devez être capable de convertir la représentation hexadécimale en binaire afin d'interpréter correctement les champs avec lesquels vous travaillez.
Cet exemple illustre cette conversion.
Divisez le nombre hexadécimal en chiffres individuels :
Convertissez les chiffres hexadécimaux en quatre chiffres binaires (quarts) que chaque chiffre hexadécimal représente :
Remplacer les quarts binaires par des octets binaires :
Si l’adresse précédente est une adresse de destination, le premier bit peut être défini sur 1, ce qui indique qu’il est destiné à un groupe ou une adresse fonctionnelle aux stations de réception. Curieusement, le bit local/universel est réglé sur 1, tout comme le bit d’adresse fonctionnel/de groupe. Comme il est possible d'avoir une adresse fonctionnelle administrée localement pour Token Ring ainsi qu'une adresse attribuée universellement, cela semble être une supervision de la part du comité IEEE 802.5. Les adresses fonctionnelles et de groupe ne sont pas couvertes par ce document car elles ne sont pas directement applicables au pontage Token Ring. Reportez-vous au document Objectifs du chapitre Token Ring/IEEE 802.5 pour plus d'informations.
Si l’adresse précédente est une adresse source et que la trame Token Ring transporte un RIF, le premier bit est défini sur 1. S'il s'agit également d'une LAA, l'adresse commence par 0xC. Affichez le vidage hexadécimal de la trame afin de le déterminer.
À l’exception de certaines mises en oeuvre spécialisées, le WAN en question n’a aucun effet sur le concept de RSRB. Dans la plupart des cas, le trafic est acheminé sur IP. Tant que le protocole IP peut circuler entre les routeurs, RSRB fonctionne correctement.
Le WAN peut être Frame Relay comme dans cet exemple.
Le WAN peut être X.25, comme dans cet exemple.
Le WAN peut être un anneau virtuel, comme dans cet exemple.
Le type de réseau étendu n'est pas pertinent car la trame Token Ring est emballée en toute sécurité dans TCP/IP, ou simplement IP, avant d'atteindre l'interface WAN. L’encapsulation FST (Fast-Sequenced Transport) est prise en charge sur presque tous les types de LAN ou de WAN.
Avec l'encapsulation directe, vous devez vous assurer que les unités de transmission maximale (MTU) de toutes les interfaces du chemin sont capables de gérer la trame 802.5 entière, car l'encapsulation directe ne permet pas la fragmentation. Vous devez ajouter 73 octets supplémentaires, pour l'en-tête RSRB Cisco et d'autres frais généraux Token Ring, au MTU Token Ring maximum dans le chemin afin d'obtenir le MTU correct pour toutes les interfaces Token Ring non dans le chemin. Les liaisons série exigent que le MTU soit 1573 si le MTU Token Ring est 1500. Un seul saut est autorisé pour l’encapsulation directe.
Dans le schéma précédent, le PC A ne peut pas atteindre le PC B et le PC B ne peut pas atteindre le PC A, à moins que le routeur B ne dispose d'homologues RSRB (non directs) avec le routeur A. Le routeur A a des homologues RSRB avec le routeur B. Les routeurs A et B peuvent également avoir une encapsulation directe configurée entre eux. Le routeur B peut être direct au routeur A, mais pas au routeur C. Le routeur C peut être direct au routeur A, mais les routeurs B et C ont besoin de vrais homologues pour communiquer.
Une autre façon de voir cela est illustrée dans ce schéma :
Le pontage SRT (Source-Route Transparent Bridging) a été ajouté à la spécification 802.5. Il permet aux trames 802.5 sans RIF de traverser des interfaces Token Ring configurées pour un pontage transparent. SRT traduit également 802.3 en 802.5 pour le pontage Token Ring Ethernet. Il ne résout pas les problèmes de pontage des protocoles routables sur des supports différents.
Les stations qui utilisent SRT ne peuvent pas communiquer avec les stations qui exécutent SRB lorsqu'elles sont sur des anneaux séparés. Les deux scénarios sont fondamentalement incompatibles. Un PC SRT a besoin de la solution propriétaire Cisco pour communiquer avec un PC SRB.
Un PC SRB a également besoin de la solution Cisco pour communiquer avec un PC Ethernet.
Remarque : Dans le schéma précédent :
6 est le faux numéro de sonnerie utilisé pour le segment Ethernet.
7 est le faux numéro de pont qui pointe vers le segment Ethernet.
Les PC Token Ring supposent que les PC Ethernet sont sur un Token Ring car ils nécessitent un RIF valide.
Le routeur constitue la partie falsifiée du RIF et ajoute le RIF aux trames destinées aux PC A et B.
Les PC Ethernet ne sont pas informés que les PC A et B ne sont pas sur Ethernet. Le routeur retire les RIF des trames des PC A et B.
L’IEEE a décidé d’utiliser un schéma de transmission de l’ordre des bits pour Ethernet qui diffère de celui de Token Ring. Le schéma pour Ethernet FDDI est le bit le moins significatif (LSB) en premier, tandis que celui des réseaux FDDI et Token Ring est le bit le plus significatif (MSB) en premier.
Il s'agit d'un scénario simple qui illustre la fonction SRB :
Les PC utilisent le routage source et doivent communiquer entre eux d’une manière ou d’une autre. Le mot source dans le routage source indique ceci. Mais avec un pontage transparent, ce n'est pas un problème, car le pontage transparent est transparent pour les stations d'extrémité. Les stations d’extrémité transmettent simplement des trames comme si elles pouvaient communiquer avec n’importe quelle station. Les PC envoient des explorateurs pour les aider à se joindre.
Considérez le RIF dans la trame Token Ring afin de comprendre le concept des explorateurs. Le RIF comporte deux sections principales :
octets de contrôle (2)
les octets de l'anneau et du pont (moins de 30)
Voici la répartition des octets de contrôle :
trois bits pour le type de diffusion (représentés par BBB dans ce schéma)
cinq bits pour la longueur de l’intégralité du RIF (LLL) (2*2*2*2=32 octets disponibles)
un bit pour la direction (D)
trois bits pour le MTU du réseau Token Ring connecté (FFF)
les quatre derniers bits pour IBM (réservé [RRRR])
Ceci est généralement représenté par BBBLLL.DFFFRRRR. En outre, BBBBLNGTH.DMTURESV est une autre représentation utile des octets de contrôle.
N'oubliez pas qu'IBM fonctionne au format hexadécimal et que le chemin source-route entre PC A et PC B est 00AF.00B0. N'oubliez pas que vous devez convertir l'expression binaire des bits de pont et d'anneau en expression hexadécimale utilisée lorsque vous utilisez SRB. Ce chemin en binaire est 0000000.10101111.0000000.10110000. Fractionné en quarts binaires, il est 0000.000.1010.1111.000.0000.1011.0000. Le dernier numéro de pont est toujours 0000, car les chemins se terminent sur des anneaux, et non sur des ponts. La règle est que trois quarts font un anneau, et un quartet fait un pont. Les plages sont comprises entre 1 et 4 095 pour les anneaux et entre 1 et 15 pour les ponts.
La partie anneau-pont du RIF est discutée précédemment. Reportez-vous à la section Champs des informations de routage pour plus d'informations. Si vous ajoutez les deux octets de contrôle au RIF d'origine, vous obtenez 00AF.00B0. Le RIF doit comporter au moins deux octets, car il nécessite les octets de contrôle. Vous avez deux anneaux, vous devez donc ajouter deux combinaisons de deux octets chacune. Cela fait six octets de long au RIF. N'oubliez pas que la structure binaire des octets est BBXLLL.DFFXXXX.RRRRRRRRRRRR.RRBBB.RRRRRRRRRRRR.RRBBB.
Prenons cet exemple, un explorateur de route unique entre PC A et PC B.
Le RIF est C670.00AF.00B0. Le quartet C670 est toujours 0.
Le RIF de l'explorateur de route unique apparaît sur la sonnerie B sous la forme C610.00AF.00B0, qui suppose un MTU de 1500 et suppose qu'il est lu de gauche à droite. Le RIF direct est 0610.00AF.00B0, ce qui suppose un MTU de 1500 et suppose qu'il est lu de gauche à droite. Les bits MTU sont décrémentés de 111 (0x7) à la MTU maximale que chaque pont peut gérer au fur et à mesure que l'explorateur passe par le pont au cours de son trajet. Le pont examine la valeur actuelle des bits MTU et, si la valeur est supérieure à celle prise en charge par le pont, le pont doit réduire la valeur jusqu'au plus grand MTU qu'il peut prendre en charge. Pour le pontage translationnel vers Ethernet, la MTU maximale est de 1 500.
Lorsqu'un pont multiport remplace le pont à deux ports, il est possible d'ajouter des RIF :
PC A à PC C : 0610.00AF.00C0
PC A à PC B : 0610.00AF.00B0
PC B à PC C : 0610,00BF,00C0
Remarque : ces trois éléments ne sont pas des FIF d'exploration. Ils sont dirigés par des RIF avec un MTU de 1500 et sont lus de gauche à droite.
PC A à PC B : 0690.00AF.00B0
Remarque : Il s'agit du même RIF que celui présenté dans le schéma précédent, mais avec le bit D défini sur 1 lorsqu'il est lu de droite à gauche.
Lorsqu’un routeur Cisco multiport remplace le pont à deux ports, le routeur agit comme un anneau virtuel pour interconnecter les vrais anneaux. Il ajoute des ponts aux interfaces Token Ring. Dans la plupart des cas, tous les numéros de pont peuvent être 1. L'exception est les ponts parallèles qui relient deux anneaux. PC A vers PC C est maintenant 0810.00A1.00F1.00C0.
Il est possible d’avoir un routeur avec seulement deux interfaces Token Ring, auquel cas un anneau virtuel n’est pas nécessaire. Il est configuré de la même manière qu'un pont à deux interfaces, mais ne peut pas exécuter RSRB.
Ce schéma illustre un routeur Cisco avec deux interfaces Token Ring. Ce routeur ne peut pas exécuter RSRB.
Le RIF est l’aspect le plus difficile et le plus fondamental de la SRB Token Ring. Le reste de ce document traite d’autres façons d’obtenir des trames Token Ring sur différentes topologies de réseau lorsqu’elles apparaissent sous forme de Token Ring au RIF. À moins de terminer le RIF, la technologie permettant de déplacer les trames d’une station à l’autre doit maintenir un RIF précis. La commutation de liaison de données (DLSw) est la principale mise en oeuvre qui termine le RIF. Ce document traite uniquement des implémentations dans lesquelles le RIF est acheminé de bout en bout sur l'ensemble du réseau.
Voici quelques règles générales à retenir :
Les périphériques SNA (Systems Network Architecture) ont tendance à envoyer des explorateurs de toutes les routes à la recherche du périphérique de destination choisi. Il s’agit des adresses MAC de monodiffusion vers les adresses MAC de destination. Les périphériques de destination inversent généralement le bit de direction (D) et renvoient la trame en tant que trame dirigée, et non en tant qu’explorateur. Le SNA n’a pas de trafic de diffusion en arrière-plan. Par exemple, les processeurs frontaux (FEP) n'envoient pas de trames qui diffusent leur emplacement afin de pouvoir les trouver.
Les systèmes NetBIOS (Network Basic Input/Output Systems) envoient des explorateurs à route unique et attendent de la station de destination qu'elle réponde avec une réponse d'explorateur de routes. NetBIOS effectue également une grande quantité de diffusion en arrière-plan. Les périphériques envoient constamment des trames qui communiquent leur emplacement et d'autres messages importants. NetBIOS envoie généralement ses explorateurs à l'adresse fonctionnelle NetBIOS pour laquelle toutes les stations NetBIOS écoutent : C000.000.0080.
La plupart des autres protocoles envoient leurs explorateurs en tant que diffusions MAC, par exemple, FFFF.FFFF.FFFF ou C000.FFFF.FFFF.
Novell peut être configuré pour envoyer des diffusions à une ou plusieurs routes. Les stations peuvent avoir besoin de route.com. Les serveurs peuvent avoir besoin de route.nlm.
Lorsque vous connectez deux anneaux avec des ponts parallèles, les numéros de pont doivent être uniques.
Avec un accusé de réception local (local-ack), le routeur devient impliqué dans une session LLC2 (Logical Link Control) de type 2 (802.2) qui se produit au niveau de la couche de contrôle de liaison de données entre deux stations d’extrémité. Vous devez comprendre certains des principes fondamentaux de la couche de contrôle de liaison de données 802.2 afin de comprendre la liaison locale. La norme 802.2 est une norme internationale IEEE et OSI (Open System Interconnection) pour la communication au niveau de la couche liaison de données. Le numéro de spécification de l'Organisation internationale de normalisation (ISO) est 8802.2. Bien que de nombreuses personnes se réfèrent au modèle à sept couches OSI lors des discussions sur les réseaux locaux, le modèle de référence LAN IEEE est un modèle plus approprié.
À l'exception des protocoles OSI (CMNS [Connection Mode Network Service] et CLNS [Connectionless Network Service]) et des protocoles ITU (International Telecommunication Unit) tels que X.25, la plupart des protocoles situés au-dessus de la couche liaison de données sont propriétaires, tels que IPX (Internetwork Packet Exchange), AppleTalk et DECnet (Digital Equipment Corporation Network), ou sont standardisés par un autre organisme (TCP/IP et l'IETF (Internet Engineering Task Force). Ni l’IEEE ni l’UIT ne contrôlent la spécification de la majorité des protocoles qui s’exécutent sur les réseaux locaux aujourd’hui.
L’IEEE a choisi de subdiviser la couche liaison de données OSI en deux couches. La couche 802.2 comporte trois types de service :
non orienté connexion
orienté connexion
sans connexion reconnue
Le type 3 est rarement utilisé. Le type 2 est utilisé par SNA et NetBIOS. Les protocoles routables tels que IP, IPX et AppleTalk configurés pour 802.2 utilisent le type 1.
Cette section traite de certaines des zones clés de la couche 802.2.
Les points d’accès aux services (SAP) sont utilisés pour multiplexer et démultiplexer les protocoles de couche supérieure via la couche 802.2. Les SAP types sont 04 (SNA), F0 (NetBIOS) et E0 (IPX). Le champ de contrôle est constitué de deux octets dans 802.2. Il est utilisé pour l'initialisation et la fermeture de session, le contrôle de flux et la supervision de session. Le serveur local gère principalement le contrôle de flux et la supervision de session. Il s'applique uniquement aux sessions orientées connexion de type 2.
Une session orientée connexion accuse réception des trames reçues et indique le numéro de trame envoyé. Par exemple, la troisième trame d'information destinée à un partenaire de session qui n'a pas encore envoyé de trame I est envoyée sous la forme I NR0 NS3. Cela indique que la trame d'information 3 doit être envoyée et que la trame I suivante est attendue sous la forme du numéro de séquence 0. Si le partenaire de session a déjà envoyé les trames 0 à 4, la trame I est envoyée sous la forme I NR5 NS3. Ceci confirme que les trames 0 à 4 ont été reçues et indique au partenaire qu'il est possible d'envoyer davantage de trames. Si, pour une raison quelconque, un partenaire de session n'est pas en mesure de recevoir davantage de trames pendant une période temporaire, il peut envoyer une trame de supervision pour annuler la session (par exemple, S RNR NR5). Le NR5 indique à l’autre partenaire ce qui a été reçu et le NR indique que le récepteur n’est pas prêt.
Les trames de supervision sont également utilisées lorsque les temporisateurs définis dans les stations d’extrémité expirent avant qu’ils ne reçoivent un accusé de réception des trames I en attente. Les stations peuvent envoyer une trame prête pour le récepteur de supervision qui demande au partenaire de répondre immédiatement. Par exemple, les stations peuvent envoyer un POLL S RR NR4, ce qui suppose que la trame suivante attendue est 4. Dans cette situation, local-ack est utile.
Parfois, le délai de propagation sur le WAN peut dépasser les paramètres de temporisation des systèmes d'extrémité. Cela entraîne la retransmission des trames I par les stations d’extrémité, même si les trames d’origine sont livrées et que les accusés de réception sont renvoyés. Local-ack envoie les trames S RR à la station d'extrémité d'où elles proviennent, tandis que le code RSRB livre la trame à l'autre système d'extrémité.
Le décodage automatique du RIF peut être effectué à l'aide de l'outil de décodage RIF.