Conexión en puente de Token Ring y decodificación RIF

Introducción

Este documento explica la descodificación de los campos de información de routing (RIF) y de conexión en puente Token Ring.

Las tramas Token Ring tienen una estructura similar a las tramas 802.3 Ethernet y de la Interfaz de datos distribuidos de fibra (FDDI). Estas tramas tienen direcciones de destino y de origen, así como una secuencia de verificación de tramas (FCS) y una sección para llevar datos. Los delimitadores inicial y final también son comunes.

Las tramas Token Ring, pero también tienen funciones adicionales integradas. Estos incluyen:

• Campo de información de routing (RIF) (opcional)

• Control de acceso (AC)

• Campos Control de tramas (FC) y Estado de tramas (FS)

Además, puede utilizar el primer bit de la dirección de origen para indicar la presencia de un RIF. Sin embargo, sólo un campo es relativo cuando se estudia el puente de ruta de origen (SRB).

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Campos de información de ruteo

El primer bit de la dirección de origen debe configurarse en 1 para soportar un RIF.

El RIF es un campo bastante complicado. Almacena la combinación de números de anillo y números de puente que una trama atraviesa entre estaciones finales. El RIF también tiene un campo de control de dos octetos que proporciona varias características del RIF mismo. Dos estaciones que se comunican a través de una red SRB o de puente de ruta de origen remoto (RSRB) siempre utilizan el mismo RIF durante la sesión.

La parte de anillo a puente del RIF entre PC A y PC B en el diagrama anterior es 00AF.00B0.

Repaso de la estructura de la dirección MAC

Las direcciones administradas localmente (LAA) se ven con mayor frecuencia en las estaciones Token Ring, aunque es posible asignar LAA a las estaciones Ethernet y FDDI. En los LAA, el segundo bit del primer bloque se establece en 1.

Una de las habilidades que se requieren cuando se soportan las redes Token Ring es la capacidad de convertir esquemas de numeración hexadecimal en binarios cuando sea necesario. Token Ring proporciona casi toda su información en hexadecimal, pero la estructura subyacente se basa en dígitos binarios. La representación hexadecimal suele ocultar parte de la estructura subyacente. Debe poder convertir la representación hexadecimal en binaria para interpretar correctamente los campos con los que trabaja.

Este ejemplo muestra esta conversión.

1. Dividir el número hexadecimal en dígitos individuales:

   

2. Convierta los dígitos hexadecimales en los cuatro dígitos binarios (nibbles) que cada dígito hexadecimal representa:

   

3. Cambie los nibbles binarios a octetos binarios:

   

Numeración hexadecimal

Si la dirección anterior es una dirección de destino, el primer bit podría configurarse en 1, lo que indica que está destinado a un grupo o dirección funcional en las estaciones receptoras. Curiosamente, el bit local/universal se configura en 1, al igual que el bit de dirección funcional/de grupo. Como es factible tener una dirección funcional administrada localmente para Token Ring así como una dirección asignada universalmente, esto parece una supervisión por parte del Comité IEEE 802.5. Las direcciones funcionales y de grupo están fuera del alcance de este documento ya que no son directamente aplicables al puente Token Ring. Refiérase al documento Objetivos del Capítulo Token Ring/IEEE 802.5 para obtener más información.

Si la dirección anterior es una dirección de origen y la trama Token Ring transporta un RIF, el primer bit se establece en 1. Si esto también es un LAA, la dirección comienza con 0xC. Vea el volcado hexadecimal de la trama para determinar esto.

A excepción de algunas implementaciones especializadas, la WAN en cuestión no afecta al concepto de RSRB. El tráfico se transporta en IP en la mayoría de los casos. Mientras IP pueda viajar entre los routers, RSRB funciona correctamente.

La WAN puede ser Frame Relay como en este ejemplo.

La WAN puede ser X.25, como en este ejemplo.

La WAN puede ser un anillo virtual, como en este ejemplo.

El tipo de WAN no es relevante porque la trama Token Ring se empaqueta de forma segura en TCP/IP, o simplemente en IP, antes de que llegue a la interfaz WAN. La encapsulación Fast-Sequencing Transport (FST) se admite en casi todos los tipos de LAN o WAN.

Con la encapsulación directa, debe asegurarse de que las unidades máximas de transmisión (MTU) de todas las interfaces de la ruta sean capaces de manejar toda la trama 802.5, ya que la encapsulación directa no permite la fragmentación. Debe agregar 73 bytes adicionales, que corresponde al encabezado RSRB de Cisco y a otras sobrecargas Token Ring, a la MTU máxima Token Ring en la trayectoria para obtener la MTU correcta para todas las interfaces que no sean Token Ring en la trayectoria. Los links seriales requieren que la MTU sea 1573 si la MTU Token Ring es 1500. Sólo se permite un salto para la encapsulación directa.

En el diagrama anterior, el PC A no puede alcanzar el PC B y el PC B no puede alcanzar el PC A, a menos que el router B tenga pares RSRB (no directos) con el router A. El Router A tiene pares RSRB con el Router B. Los routers A y B también pueden tener la encapsulación directa configurada entre ellos. El Router B puede ser directo al Router A, pero no al Router C. El Router C puede ser directo al Router A, pero los Routers B y C necesitan pares reales para comunicarse.

En este diagrama se muestra otra forma de verlo:

Puente transparente de ruta de origen

El puente transparente de ruta de origen (SRT) se agregó a la especificación 802.5. Permite que las tramas 802.5 sin un RIF atraviesen las interfaces Token Ring configuradas para el bridging transparente. SRT también traduce 802.3 a 802.5 para el bridging Token Ring Ethernet. No resuelve los problemas de bridging routable protocols sobre medios diferentes.

Las estaciones que utilizan SRT no pueden comunicarse con las estaciones que ejecutan SRB cuando están en anillos separados. Los dos escenarios son fundamentalmente incompatibles. Un PC SRT necesita la solución propietaria de Cisco para comunicarse con un PC SRB.

Un PC SRB también requiere la solución de Cisco para comunicarse con un PC Ethernet.

Nota: En el diagrama anterior:

• 6 es el número de anillo falso utilizado para el segmento Ethernet.

• 7 es el número de puente falso que apunta al segmento Ethernet.

• Los PC Token Ring asumen que los PC Ethernet están en un Token Ring porque requieren un RIF válido.

• El router constituye la parte falsa del RIF y agrega el RIF a las tramas destinadas a los PC A y B.

• No se informa a los PC Ethernet de que los PC A y B no están en Ethernet. El router elimina los RIF de las tramas PC A y PC B.

El IEEE ha decidido utilizar un esquema de transmisión de orden de bits para Ethernet que difiera del de Token Ring. El esquema para Ethernet FDDI es Bit menos significativo (LSB) primero, mientras que el de FDDI y Token Ring son Bit más significativo (MSB) primero.

Source-Route Bridging

Este es un escenario simple que ilustra SRB:

Los PC utilizan el ruteo de origen y necesitan comunicarse entre sí de alguna manera. La palabra origen en el ruteo de origen lo indica. Pero, con un puente transparente, esto no es un problema, ya que el puente transparente es transparente para las estaciones finales. Las estaciones finales simplemente transmiten tramas como si pudieran comunicarse con cualquier estación en absoluto. Los PC envían exploradores para ayudarlos a comunicarse entre sí.

Exploradores

Considere el RIF en la trama Token Ring para entender el concepto de exploradores. El RIF tiene dos secciones principales:

• bytes de control (2)

• los bytes de anillo y puente (menos de 30)

Este es el desglose de los bytes de control:

• tres bits para tipo de broadcast (representado por BBB en este diagrama)

• cinco bits para la longitud de todo el RIF (LLLLL) (2*2*2*2*2=32 bytes disponibles)

• un bit para la dirección (D)

• tres bits para la MTU de la red Token Ring conectada (FFF)

• los últimos cuatro bits para IBM (reservado [RRRR])

Esto se representa comúnmente como BBBLLLLL.DFFFRRRR. Además, BBBLNGTH.DMTURESV es otra representación útil de los bytes de control.

Tenga en cuenta que IBM funciona en formato hexadecimal y que la ruta de origen de PC A a PC B es 00AF.00B0. Recuerde que debe convertir la expresión binaria de los bits de anillo y puente a la expresión hexadecimal que se utiliza cuando trabaja con SRB. Esta trayectoria en binario es 0000000.1010111.00000000.10110000. Si se divide en bloques binarios, es 0000.000.1010.1111.0000.0000.1011.0000. El último número de puente es siempre 0000, a medida que las trayectorias terminan en anillos, no en bridges. La regla es que tres pedradas hacen un anillo, y un pezón hace un puente. Los rangos son 1-4095 para anillos y 1-15 para puentes.

La porción de anillo y puente del RIF se discute previamente. Vea la sección Campos de Información de Ruteo para obtener más información. Si agrega los dos bytes de control al RIF original, termina con 00AF.00B0. El RIF debe tener al menos dos bytes de longitud porque requiere los bytes de control. Tiene dos anillos, por lo que debe agregar dos combinaciones de anillo y puente de dos bytes cada uno. Esto hace que el RIF tenga seis bytes. Recuerde que la estructura binaria de los bytes es BBXLLLLL.DFFFXXXX.RRRRRRR.RRRRRRBBBB.RRRRRRRR.RRRRRBBBB.

Considere este ejemplo, un explorador de ruta única desde el PC A al PC B.

El RIF es C670.00AF.00B0. El negro C670 es siempre 0.

El RIF del explorador de ruta única aparece en el anillo B como C610.00AF.00B0, que supone una MTU de 1500 y asume que se lee de izquierda a derecha. El RIF directo es 0610.00AF.00B0, que asume una MTU de 1500 y asume que se lee de izquierda a derecha. Los bits de MTU se reducen de 111 (0x7) a la MTU máxima que cada puente puede manejar a medida que el explorador pasa a través del puente en su viaje. El bridge examina el valor actual de los bits de MTU y, si el valor es mayor que el que soporta el bridge, el bridge debe disminuir el valor hasta la MTU más grande que pueda soportar. Para la conexión en puente de traducción a Ethernet, la MTU máxima es 1500.

Cuando un puente de varios puertos reemplaza al puente de dos puertos, es posible que haya más RIF:

• PC A a PC C: 0610.00AF.00C0

• PC A a PC B: 0610.00AF.00B0

• PC B a PC C: 0610.00BF.00C0

  Nota: Estos tres no son RIF del explorador. Se dirigen a los RIF con una MTU de 1500 y se leen de izquierda a derecha.

• PC A a PC B: 0690.00AF.00B0

  Nota: Éste es el mismo RIF que se examinó en el diagrama anterior, pero con el bit D configurado en 1 cuando se lee de derecha a izquierda.

Cuando un router Cisco de varios puertos reemplaza el puente de dos puertos, el router actúa como un anillo virtual para interconectar los anillos reales. Agrega puentes a las interfaces Token Ring. En la mayoría de los casos, todos los números de puente pueden ser 1. La excepción son los puentes paralelos que conectan dos anillos. La PC A al PC C es ahora 0810.00A1.00F1.00C0.

Router Cisco con tres interfaces Token Ring

Es posible tener un router con sólo dos interfaces Token Ring, en cuyo caso un anillo virtual es innecesario. Se configura de manera similar a un puente de dos interfaces, pero no puede realizar RSRB.

Este diagrama muestra un router Cisco con dos interfaces Token Ring. Este router no puede realizar RSRB.

El RIF es el aspecto más difícil y fundamental del SRB Token Ring. El resto de este documento trata otras maneras de lograr tramas Token Ring a través de varias topologías de red, ya que hacen que aparezcan como Token Rings en el RIF. A menos que se termine el RIF, la tecnología para mover las tramas de estación a estación debe mantener de alguna manera un RIF preciso. Data-Link Switching (DLSw) es la implementación principal que finaliza el RIF. Este documento sólo aborda las implementaciones en las que el RIF se transporta de extremo a extremo a través de toda la red.

Estas son algunas de las reglas generales a tener en cuenta:

• Los dispositivos de la arquitectura de red de sistemas (SNA) tienden a enviar exploradores de todas las rutas en busca del dispositivo de destino elegido. Éstos son unidifusión a las direcciones MAC de destino. Los dispositivos de destino normalmente invierten el bit de dirección (D) y envían la trama de vuelta como una trama dirigida, no como un explorador. SNA no tiene tráfico de broadcast en segundo plano. Por ejemplo, los procesadores de extremo frontal (FEP) no envían tramas que transmitan su ubicación para que se puedan encontrar.

• Network Basic Input/Output Systems (NetBIOS) envía exploradores de ruta única y espera que la estación de destino responda con una respuesta del explorador de todas las rutas. NetBIOS también realiza una gran cantidad de transmisión en segundo plano. Los dispositivos envían constantemente tramas que comunican su ubicación y otros mensajes importantes. NetBIOS normalmente envía sus exploradores a la dirección funcional NetBIOS para la que todas las estaciones NetBIOS escuchan: C000.0000.0080.

• La mayoría de los demás protocolos envían sus exploradores como transmisiones MAC, por ejemplo, FFFF.FFFF.FFFF o C000.FFFF.FFFF.

• Novell se puede configurar para enviar broadcasts de ruta única o de todas las rutas. Es posible que las estaciones necesiten route.com. Es posible que los servidores necesiten route.nlm.

Cuando conecta dos anillos con bridges paralelos, los números de puente deben ser únicos.

Reconocimiento local:

Con reconocimiento local (Local-ack), el router se involucra en una sesión de Control de link lógico 802.2, tipo 2 (LLC2) que se produce en la capa de control de link de datos entre dos estaciones finales. Debe comprender algunos de los fundamentos de la capa de control de link de datos 802.2 para comprender el retorno local. El estándar 802.2 es un estándar internacional IEEE y Open System Interconnection (OSI) para la comunicación en la capa de enlace de datos. El número de especificación de la Organización Internacional de Normalización (ISO) es 8802.2. Aunque muchas personas se refieren al modelo de siete capas OSI durante las conversaciones sobre las LAN, un modelo más apropiado es el modelo de referencia LAN IEEE.

Con la excepción de los protocolos OSI (servicio de red en modo de conexión [CMNS] y servicio de red sin conexión [CLNS]) y los protocolos de la Unidad de telecomunicaciones internacional (ITU) como X.25, la mayoría de los protocolos sobre la capa de enlace de datos son exclusivos, como Internetwork Packet Exchange (IPX), AppleTalk y Digital Equipment Corporation Network (DECnet), o están estandarizados por un organismo diferente (TCP/IP) Internet Engineering Task Force [IETF]). Ni el IEEE ni la ITU controlan la especificación de la mayoría de los protocolos que se ejecutan sobre las LAN en la actualidad.

Modelo de referencia LAN IEEE

El IEEE decidió subdividir la capa de link de datos OSI en dos capas. La capa 802.2 tiene tres tipos de servicio:

1. sin conexión

2. orientado a la conexión

3. sin conexión reconocida

El tipo 3 apenas se utiliza. SNA y NetBIOS utilizan el tipo 2. Los protocolos enrutables como IP, IPX y AppleTalk configurados para 802.2 utilizan el tipo 1.

Formato 802.2

Esta sección trata algunas de las áreas clave de la capa 802.2.

Los puntos de acceso a servicios (SAP) se utilizan para multiplexar y desmultiplexar protocolos de capa superior a través de la capa 802.2. Los SAP típicos son 04 (SNA), F0 (NetBIOS) y E0 (IPX). El campo de control es de dos octetos en 802.2. Se utiliza para la inicialización y terminación de sesiones, el control de flujo y la supervisión de sesiones. Local-ack se encarga principalmente del control de flujo y la supervisión de sesiones. Sólo se aplica a las sesiones orientadas a la conexión de tipo 2.

Una sesión orientada a la conexión reconoce las tramas que se reciben e indica el número de trama que se envía. Por ejemplo, la tercera trama de información destinada a un socio de sesión que aún no ha enviado una trama I se envía como NR0 NS3 de I. Esto comunica que se enviará la trama de información 3 y que se espera que la siguiente trama I sea el número de secuencia 0. Si el partner de sesión ya ha enviado tramas 0-4, la trama I se envía como I NR5 NS3. Esto reconoce que se han recibido las tramas 0-4 y le indica al partner que está bien enviar más tramas. Si, por cualquier motivo, un partner de sesión no puede recibir más tramas durante un período temporal, el partner puede enviar una trama de supervisión para cerrar la sesión (por ejemplo, S RNR NR5). El NR5 indica al otro partner lo que se ha recibido y el RNR comunica que el receptor no está listo.

Las tramas de supervisión también se utilizan cuando los temporizadores establecidos en las estaciones finales caducan antes de que reciban un reconocimiento de las tramas I pendientes. Las estaciones pueden enviar una trama preparada para el receptor de supervisión que solicita al partner que responda inmediatamente. Por ejemplo, las estaciones pueden enviar la PUNTA S RR NR4, que supone que la siguiente trama esperada es 4. En esta situación, el retorno local es útil.

A veces, el retardo de propagación a través de la WAN puede exceder la configuración del temporizador en los sistemas finales. Esto hace que las estaciones finales retransmitan las tramas I, aunque se entregan las tramas originales y se devuelven las confirmaciones. Local-ack envía tramas S RR a la estación final de donde se origina, mientras que el código RSRB entrega la trama al otro sistema extremo.

La descodificación automática del RIF se puede realizar con la herramienta de descodificación RIF.

Información Relacionada

• Introducción al establecimiento del puente del router fuente local y resolución de problemas.
• Suplemento de formación RIF Passthru en DLSw+
• Soporte Técnico y Documentación - Cisco Systems