2.3. Rede SNA com Pontes entre WANs

Em um projeto de rede de grande área (WAN) com pontes (bridges), o tráfego circula restrititivamente em cada estrutura, otimizando significativamente o numero de conexões. Esta solução, contudo, tem limitações. A mais seria é a subutilização dos enlaces. Grande parte do tráfego entre redes SNA e LANs é superfluo. Todos os protocolos de redes locais geram algum tráfego de broadcast para localizar estações conectadas. Pontes não filtram estes frames, causando fluxo desnecessário nos enlaces entre WANs. Este defeito das bridges é estratégico para o sucesso do roteamento remoto.

Em uma topologia com pontes, o protocolo SDLC conecta periféricos utilizando a largura de banda da WAN. Para manter a conexão com FEPs, Controladores de Grupo transmitem mensagens e esperam aviso de recebimento (ack) imediato. Estas mensagens não só consomem largura de banda, como também incrementam a sobrecarga de uma rede congestionada, em que respostas demoram para chegar até que a sessão encerre por time out.

Além disso, pontes sob forte sobrecarga descartam frames, criando outro conjunto de problemas. Enquanto alguns protocolos de redes locais, como TCP/IP e OSI, são robustos o suficiente para recuperar eventuais frames perdidos, tráfego do tipo 3270 não o possui. Tal descontinuidade leva a queda da conexão, devendo a mesma ser restabelecida desde seu início, um processo oneroso que adiciona ainda mais tráfego a uma rede já sobrecarregada.

Redes já consolidadas podem sofrer as limitações impostas pelas restrições das redes token-ring. Em primeiro lugar, somente protocolos de redes locais implementam roteamento de origem; a Novell, por exemplo, possui (pelo menos até o dia da elaboração deste documento) uma grande base instalada do Netware sem a implementação de roteamento de origem. Em segundo, devido à própria limitação da rede token- ring ao máximo de sete pulinhos (hops), a expansão da rede não pode ultrapassar este limite. (Dois anéis ligados por uma ponte compreendem dois hops na rede. O limite de sete hops significa que não mais de seis pontes podem separar quaisquer duas estações.) Para muitas redes locais, o limite de sete hops não é uma limitação severa. Contudo, para redes de mainframes, que tem expansão frequente, sete hops é uma restrição séria.

Por outro lado, outra abordagem para interconectar SNA com LANs são as redes com tunneling (canalização). Nestas redes, frames SDLC são encapsulados em um pacote de Protocolo Internet (IP), circulando como qualquer outro tráfego IP, caracterizando o chamado tunneling. Com efeito, o problema da falta de filtragem de broadcasts permanece, além de manter vivas as mensagens cruzando a WAN. Além disso, o tunneling falha no processo de conversão do controle de enlace. Um periférico SDLC remoto (tipo Controle de Grupo) não pode se comunicar com FEPs intermediados por rede token-ring, porque no tunneling não pode ser convertido o tráfego SDLC para LLC (Controle de Enlace Lógico, presente na LAN token-ring). A ponte/roteador remoto desencapsula o frame SDLC de dentro do frame IP e o envia para um enlace SDLC ligado a um FEP qualquer. Portanto, com esta abordagem, Controle de Grupo (Cluster Control) ligado a SDLC não pode comunicar-se com FEPs ligados intermediariamente a rede token-ring.

Apesar de certa consolidação do tunneling, ele falha em muitas questões relevantes ao tráfego SNA e NetBIOS. A IBM percebeu as limitações das pontes em relação a solução tunneling e buscou uma abordagem chamada Comutação de Enlace de Dados (DLS). Em março de 1993, a IBM lançou na Internet um RFC (Request for Comments, descrevendo o DLS no RFC 1434.