Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Conventions

Campos de Informações de Roteamento

Revisão da estrutura do endereço MAC

Numeração hexadecimal

Source-Route Transparent Bridging

Source-Route Bridging

Exploradores

Cisco Router com Três Interfaces de Token Ring

Reconhecimento local

Modelo de referência de LAN IEEE

Formato 802.2

Informações Relacionadas

Introduction

Este documento explica a decodificação de Token Ring Bridging and Routing Information Field (RIF).

Os quadros Token Ring têm uma estrutura semelhante aos quadros 802.3 Ethernet e Fiber Distributed Data Interface (FDDI). Esses quadros têm endereços de origem e de destino, bem como uma FCS (Frame Check Sequence) e uma seção para transportar dados. Delimitadores de início e fim também são comuns.

Quadros Token Ring, mas também têm funções extras incorporadas. Eles incluem:

- Campo de informações de roteamento (RIF) (opcional)

- Controle de acesso (AC)

- Campos de Controle de Quadro (FC - Frame Control) e Status de Quadro (FS - Frame Status)

Além disso, você pode usar o primeiro bit do endereço de origem para indicar a presença de um RIF. Mas, apenas um campo é relativo quando você estuda o Source-Route Bridging (SRB).

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Campos de Informações de Roteamento

O primeiro bit do endereço de origem deve ser definido como 1 para suportar um RIF.

O RIF é um campo bastante complicado. Ele armazena a combinação de números de anel e números de bridge que um quadro atravessa entre as estações finais. O RIF também tem um campo de controle de dois octetos que fornece várias características do próprio RIF. Duas estações que se comunicam através de uma rede SRB ou RSRB (Remote Source-Route Bridging, ponte de rota remota) sempre usam o mesmo RIF durante a sessão.

A parte do RIF entre o PC A e o PC B no diagrama anterior é 00AF.00B0.

Revisão da estrutura do endereço MAC

Os endereços administrados localmente (LAA) são mais comumente vistos nas estações Token Ring, embora seja possível atribuir LAAs às estações Ethernet e FDDI. Nos LAAs, o segundo bit do primeiro nibble é definido como 1.

Uma das habilidades necessárias quando você oferece suporte a redes Token Ring é a capacidade de converter esquemas de numeração hexadecimal em binários quando necessário. O Token Ring fornece quase todas as suas informações em hexadecimal, mas a estrutura subjacente é baseada em dígitos binários. A representação hexadecimal geralmente mascara parte da estrutura subjacente. Você precisa ser capaz de converter a representação hexadecimal em binário para interpretar corretamente os campos com os quais trabalha.

Este exemplo demonstra esta conversão.

1. Divida o número hexadecimal em dígitos individuais:

2. Converta os dígitos hexadecimais em quatro dígitos binários (nibbles) que cada dígito hexadecimal representa:

3. Altere os nibbles binários para octetos binários:

Numeração hexadecimal

Se o endereço anterior for um endereço de destino, o primeiro bit poderá ser definido como 1, o que indica que ele é destinado a um grupo ou endereço funcional nas estações receptoras. Curiosamente, o bit local/universal é definido como 1 como o bit de endereço funcional/de grupo. Como é viável ter um endereço funcional administrado localmente para Token Ring, bem como um endereço universalmente atribuído, isso parece uma supervisão por parte do Comitê IEEE 802.5. Os endereços funcionais e de grupo estão além do escopo deste documento, pois não são diretamente aplicáveis ao Token Ring Bridging. Consulte o documento Objetivos do Capítulo do Token Ring/IEEE 802.5 para obter mais informações.

Se o endereço anterior for um endereço de origem e o quadro Token Ring transportar um RIF, o primeiro bit será definido como 1. Se também for um LAA, o endereço começa com 0xC. Examine o dump hexadecimal do quadro para determinar isso.

Com exceção de algumas implementações especializadas, a WAN em questão não tem efeito no conceito de RSRB. O tráfego é transportado em IP na maioria das instâncias. Desde que o IP possa trafegar entre os roteadores, o RSRB opera com êxito.

A WAN pode ser Frame Relay como neste exemplo.

A WAN pode ser X.25, como neste exemplo.

A WAN pode ser um anel virtual, como neste exemplo.

O tipo de WAN não é relevante porque o quadro Token Ring é empacotado com segurança em TCP/IP, ou simplesmente IP, antes de chegar à interface de WAN. O encapsulamento Fast-Sequenced Transport (FST) é suportado em quase todos os tipos de LAN ou WAN.

Com o encapsulamento direto, você deve garantir que as Unidades Máximas de Transmissão (MTUs - Maximum Transmission Units) de todas as interfaces no caminho sejam capazes de lidar com todo o quadro 802.5, já que o encapsulamento direto não permite a fragmentação. Você precisa adicionar mais 73 bytes, que é para o cabeçalho RSRB da Cisco e outras despesas gerais de Token Ring, ao MTU máximo de Token Ring no caminho para obter o MTU correto para todas as interfaces não Token Ring no caminho. Os links seriais exigem que o MTU seja 1573 se o MTU de Token Ring for 1500. Somente um salto é permitido para o encapsulamento direto.

No diagrama anterior, o PC A não pode alcançar o PC B e o PC B não pode alcançar o PC A, a menos que o Roteador B tenha pares RSRB (não diretos) com o Roteador A. O Roteador A tem pares RSRB com o Roteador B. Os roteadores A e B também podem ter o encapsulamento direto configurado entre eles. O Roteador B pode ser direto para o Roteador A, mas não para o Roteador C. O Roteador C pode ser direto para o Roteador A, mas os Roteadores B e C precisam de pares reais para se comunicar.

Outra maneira de ver isso é demonstrada neste diagrama:

Source-Route Transparent Bridging

Source-Route Transparent Bridging (SRT) foi adicionado à especificação 802.5. Permite que quadros 802.5 sem RIF atravessem interfaces Token Ring configuradas para bridging transparente. O SRT também converte 802.3 para 802.5 para Ethernet Token Ring Bridging. Ele não resolve os problemas de bridging de protocolos roteáveis sobre meios diferentes.

As estações que usam SRT não podem se comunicar com estações que executam SRB quando estão em anéis separados. Os dois cenários são fundamentalmente incompatíveis. Um PC SRT precisa da solução proprietária da Cisco para se comunicar com um PC SRB.

Um PC SRB também exige a solução da Cisco para se comunicar com um PC Ethernet.

Nota: No diagrama anterior:

- 6 é o número de anel falso usado para o segmento Ethernet.

- 7 é o número de bridge falso que aponta para o segmento Ethernet.

- Os PCs Token Ring presumem que os PCs Ethernet estão em um Token Ring porque exigem um RIF válido.

- O roteador constitui a parte falsa do RIF e adiciona o RIF aos quadros destinados aos PCs A e B.

- Os PCs Ethernet não são informados de que os PCs A e B não estão na Ethernet. O roteador retira os RIFs dos quadros PC A e PC B.

O IEEE decidiu usar um esquema de transmissão de ordem de bits para Ethernet diferente do Token Ring. O esquema para a Ethernet FDDI é o LSB (Last Bit Menos Significante) primeiro, enquanto o da FDDI e o da Token Ring são os Bits Mais Significantes (MSB) primeiro.

Source-Route Bridging

Esse é um cenário simples que ilustra o SRB:

Os PCs usam o roteamento de origem e precisam se comunicar entre si de alguma forma. A palavra origem no roteamento de origem indica isso. Mas, com a ponte transparente, isso não é um problema, pois a ponte transparente é transparente para as estações finais. As estações finais simplesmente transmitem quadros como se pudessem se comunicar com qualquer estação. Os PCs enviam exploradores para ajudá-los a se alcançar.

Exploradores

Considere o RIF no quadro Token Ring para entender o conceito de exploradores. O RIF tem duas seções principais:

- os bytes de controle (2)

- os bytes de anel e ponte (menos de 30)

Esta é a divisão dos bytes de controle:

- três bits para o tipo de broadcast (representado por BBB neste diagrama)

- cinco bits para o comprimento de todo o RIF (LLL) (2*2*2*2*2=32 bytes disponíveis)

- um bit para a direção (D)

- três bits para a MTU da rede Token Ring conectada (FFF)

- os últimos quatro bits para IBM (reservado [RRRR])

Isso é comumente representado como BBBLLLLL.DFFRRRR. Além disso, BBBLNGTH.DMTURESV é outra representação útil dos bytes de controle.

Lembre-se de que a IBM trabalha em hexadecimal e que o caminho da rota de origem do PC A para o PC B é 00AF.00B0. Lembre-se de que você precisa converter a expressão binária dos bits do anel e da ponte para a expressão hexadecimal usada quando trabalha com SRB. Esse caminho em binário é 0000000.10101111.0000000.10110000. Dividido em nibbles binários, é 0000.0000.1010.1111.0000.0000.1011.0000. O último número de bridge é sempre 0000, pois os caminhos terminam em anéis, não em pontes. A regra é que três bolinhas fazem um anel, e um nibble faz uma ponte. Os intervalos são de 1 a 4095 para anéis e de 1 a 15 para bridges.

A parte do anel e da ponte do RIF é discutida anteriormente. Consulte a seção Campos de Informações de Roteamento para obter mais informações. Se você adicionar os dois bytes de controle ao RIF original, você terminará com 00AF.00B0. O RIF deve ter pelo menos dois bytes de comprimento porque requer os bytes de controle. Você tem dois anéis, portanto é necessário adicionar duas combinações de anel e ponte de dois bytes cada. Isso faz com que o RIF tenha 6 bytes de comprimento. Lembre-se, a estrutura binária dos bytes é BBXLLL.DFFXXXX.RRRRRRRR.RRBBBB.RRRRRR.RRRRRRBBBB.

Considere este exemplo, um explorador de rota única do PC A ao PC B.

O RIF é C670.00AF.00B0. O nibble C670 é sempre 0.

O RIF do explorador de rota única aparece no anel B como C610.00AF.00B0, que assume um MTU de 1500 e assume que é lido da esquerda para a direita. O RIF direto é 0610.00AF.00B0, que supõe um MTU de 1500 e assume que é lido da esquerda para a direita. Os bits de MTU são decrementados de 111 (0x7) para o MTU máximo que cada bridge pode manipular à medida que o explorador passa pela bridge em sua jornada. A bridge examina o valor atual dos bits de MTU e, se o valor for maior do que a bridge suporta, a bridge deve diminuir o valor para o maior MTU que pode suportar. Para bridging de tradução para Ethernet, o MTU máximo é 1500.

Quando uma bridge multiporta substitui a bridge de duas portas, mais RIFs são possíveis:

- PC A para PC C: 0610.00AF.00C0

- PC A para PC B: 0610.00AF.00B0

- PC B para PC C: 0610.00BF.00C0

Observação: esses três não são RIFs do explorador. São RIFs direcionados com MTU de 1500 e são lidos da esquerda para a direita.

- PC A para PC B: 0690,00AF.00B0

Observação: este é o mesmo RIF conforme discutido no diagrama anterior, mas com o bit D definido como 1 quando lido da direita para a esquerda.

Quando um roteador Cisco multiporta substitui a bridge de duas portas, o roteador atua como um anel virtual para interconectar os anéis reais. Ele adiciona bridges às interfaces Token Ring. Na maioria dos casos, todos os números de bridge podem ser 1. A exceção são as bridges paralelas que conectam dois anéis. O PC A para o PC C agora é 0810.00A1.00F1.00C0.

Cisco Router com Três Interfaces de Token Ring

É possível ter um roteador com apenas duas interfaces Token Ring, caso em que um anel virtual é desnecessário. Ele é configurado de forma semelhante a uma bridge de duas interfaces, mas não pode executar o RSRB.

Este diagrama demonstra um roteador Cisco com duas interfaces Token Ring. Este roteador não pode executar o RSRB.

O RIF é o aspecto mais difícil e fundamental do SRB Token Ring. O restante deste documento discute outras maneiras de alcançar quadros Token Ring em várias topologias de rede à medida que eles os fazem aparecer como Token Rings para o RIF. A menos que o RIF seja terminado, a tecnologia para mover os quadros de uma estação para outra deve, de alguma forma, manter um RIF preciso. DLSw (Data-Link Switching) é a implementação principal que encerra o RIF. Este documento aborda apenas implementações em que o RIF é transportado de ponta a ponta em toda a rede.

Estas são algumas regras gerais que devem ser lembradas:

- Os dispositivos de Arquitetura de Rede de Sistemas (SNA - Systems Network Architecture) tendem a enviar exploradores de todas as rotas em busca de seu dispositivo de destino escolhido. Eles são unicast para os endereços MAC de destino. Os dispositivos de destino geralmente invertem o bit de direção (D) e enviam o quadro de volta como um quadro direcionado, não um explorador. SNA não tem tráfego de broadcast de segundo plano. Por exemplo, os processadores front-end (FEPs) não enviam quadros que transmitem sua localização para que possam ser encontrados.

- Os Network Basic Input/Output Systems (NetBIOS) enviam exploradores de rota única e esperam que a estação de destino responda com uma resposta de exploração de todas as rotas. O NetBIOS também executa uma grande quantidade de transmissão em segundo plano. Os dispositivos enviam constantemente quadros que comunicam sua localização e outras mensagens importantes. O NetBIOS geralmente envia seus exploradores para o endereço funcional NetBIOS para o qual todas as estações NetBIOS escutam: C000.0000.0080.

- A maioria dos outros protocolos envia seus exploradores como broadcasts MAC, por exemplo, FFFF.FFFF.FFFF ou C000.FFFF.FFFF.

- O Novell pode ser configurado para enviar broadcasts de rota única ou de todas as rotas. As estações podem precisar de route.com. Os servidores podem precisar de route.nlm.

Quando você conecta dois anéis com pontes paralelas, os números das pontes devem ser exclusivos.

Reconhecimento local

Com o reconhecimento local (local-ack), o roteador se torna envolvido em uma sessão 802.2 Logical Link Control, tipo 2 (LLC2), que ocorre na camada de controle do enlace de dados entre duas estações finais. Você deve entender alguns dos fundamentos da camada de controle de enlace de dados 802.2 para entender o local-ack. O 802.2 é um padrão internacional IEEE e Open System Interconnection (OSI) para comunicação na camada de enlace de dados. O número da especificação ISO (International Organization for Standardization, Organização Internacional de Padronização) é 8802.2. Embora muitas pessoas se refiram ao modelo OSI de sete camadas durante as discussões de LANs, um modelo mais apropriado é o modelo de referência de LAN IEEE.

Com exceção dos protocolos OSI (Connection Mode Network Service [CMNS] e Connectionless Network Service [CLNS]) e dos protocolos International Telecommunication Unit (ITU), como X.25, a maioria dos protocolos acima da camada de enlace de dados são proprietários, como Internetwork Packet Exchange (IPX), AppleTalk e Digital Equipment Corporation Network (DECnet), ou são padronizados por outro corpo (TCP/IP e a IETF (Internet Engineering Task Force). Nem o IEEE nem o ITU controlam a especificação da maioria dos protocolos que são executados nas LANs atuais.

Modelo de referência de LAN IEEE

O IEEE optou por subdividir a camada de enlace de dados OSI em duas camadas. A camada 802.2 tem três tipos de serviço:

1. sem conexão

2. orientado a conexão

3. sem conexão reconhecida

O tipo 3 quase nunca é usado. O tipo 2 é usado por SNA e NetBIOS. Os protocolos roteáveis como IP, IPX e AppleTalk configurados para 802.2 usam o tipo 1.

Formato 802.2

Esta seção discute algumas das principais áreas da camada 802.2.

Os Pontos de Acesso a Serviços (SAPs - Service Access Points) são usados para multiplexar e demultiplex protocolos de camada superior através da camada 802.2. SAPs típicos são 04 (SNA), F0 (NetBIOS) e E0 (IPX). O campo de controle é de dois octetos em 802.2. É usado para inicialização e terminação de sessão, controle de fluxo e supervisão de sessão. O local-ack lida principalmente com controle de fluxo e supervisão de sessão. Aplica-se somente a sessões orientadas a conexão tipo 2.

Uma sessão orientada a conexão confirma os quadros que são recebidos e indica o número do quadro que é enviado. Por exemplo, o terceiro quadro de informações destinado a um parceiro de sessão que ainda não enviou um quadro I é enviado como I NR0 NS3. Isso comunica que o quadro de informações 3 deve ser enviado e que o próximo quadro I é esperado como número de sequência 0. Se o parceiro de sessão já enviou os quadros 0 a 4, o quadro I é enviado como I NR5 NS3. Isso confirma que os quadros 0 a 4 foram recebidos e informa ao parceiro que está OK enviar mais quadros. Se, por algum motivo, um parceiro de sessão não puder receber mais quadros por um período temporário, o parceiro pode enviar um quadro de supervisão para encerrar a sessão (por exemplo, S RNR NR NR5). O NR5 informa ao outro parceiro o que foi recebido e o RNR informa que o receptor não está pronto.

Os quadros de supervisão também são usados quando os temporizadores definidos nas estações finais expiram antes de receberem uma confirmação dos quadros I pendentes. As estações podem enviar um quadro de supervisão pronto para o receptor que solicita que o parceiro responda imediatamente. Por exemplo, as estações podem enviar S RR NR4 POLL, que supõe que o próximo quadro esperado seja 4. Nesta situação, o local-ack é útil.

Às vezes, o atraso de propagação na WAN pode exceder as configurações do temporizador nos sistemas finais. Isso faz com que as estações finais retransmitam os quadros I, mesmo que os quadros originais sejam entregues e os reconhecimentos sejam retornados. O local-ack envia quadros S RR para a estação final de onde ele se origina, enquanto o código RSRB entrega o quadro para o outro sistema final.

A decodificação automática do RIF pode ser executada com a Ferramenta decodificadora RIF.

Informações Relacionadas

- Compreendendo e Troubleshooting Problemas de Local Source-Route Bridging

- Passagem de RIF no suplemento de treinamento DLSw+

- Suporte Técnico e Documentação - Cisco Systems