LAN Emulation over ATM

Guilherme Paulo Teixeira dos Santos

1. Introdução
2. Conceitos Básicos
3. Componentes e Conexões
4. Formato dos Quadros de Dados
5. Operação de uma ELAN
6. Implementação
7. MPOA
8. Conclusão
9. Links
Apêndice: Perguntas

1. Introdução

O ATM (Asynchronous Transfer Mode) foi o protocolo criado para atender aos requisitos do B-ISDN (ISDN faixa larga), que seria um serviço público (ou seja, oferecido pelas operadoras de telefonia) para transmissão de voz, dados e vídeo. O objetivo final do B-ISDN é a substituição das diversas redes de telecomunicações atuais (telefonia, dados, TV a cabo) por uma rede única, que integrará todas estas mídias numa mesma rede. Obviamente, este é um objetivo que somente poderá ser alcançado a longo prazo, pois as redes atuais já estão consolidadas e será necessário um investimento maciço para implementar uma nova infra-estrutura global de comunicações.

Por outro lado, o ATM apresenta uma série de atrativos com relação ao seu aproveitamento nas redes de comunicações de dados atuais (altas taxas de transmissão, baixa latência, qualidade de serviço etc.). Este aproveitamento está condicionado à capacidade do ATM de interoperar com as redes disponíveis atualmente, porque dificilmente um usuário irá investir em uma rede que não seja capaz de se comunicar com a sua base instalada. Preservar o investimento já feito em suas redes é de grande importância para o usuário, portanto a substituição tem que ser gradual.

Dentro deste contexto, foi criado o LAN Emulation, ou LANE. Este serviço foi concebido para permitir que o maior número possível de aplicações usadas atualmente possa usar o ATM sem necessitar de modificações e ao mesmo tempo, que as estações ligadas nas redes antigas se comuniquem com as ligadas em ATM de forma transparente.

A grande maioria da base instalada de comunicação de dados é baseada em redes locais (LANs) IEEE 802.x, tais como Ethernet e Token Ring. Os serviços oferecidos pelo ATM são bastante diferentes dos oferecidos pelas LANs. As principais diferenças são as seguintes:

As redes locais enviam quadros sem estabelecer conexões, enquanto que o ATM é orientado a conexão;
As redes locais se caracterizam por ter o meio compartilhado, o que facilita muito o broadcast e o multicast. O ATM possui multicast, mas não oferece broadcast;
O endereçamento ATM é hierárquico, ou seja, reflete a topologia da rede. As redes locais se baseiam nos endereços MAC, que são endereços físicos independentes da topologia.

O LAN Emulation, ou LANE, é um serviço implementado por meio de uma camada de software em qualquer estação que possua uma interface ATM, seja ela um host, switch ou roteador. Sua função básica é oferecer ao protocolo camada rede uma interface idêntica à oferecida por uma rede local tradicional. Isto é feito no sentido de que não seja necessário modificar os protocolos de rede para se operar uma rede local ATM. Além disso, o LANE define o bridging entre o ATM e os protocolos LAN, permitindo que as estações ligadas às duas redes se comuniquem de forma transparente.

2. Conceitos Básicos

O LANE permite a implementação de LANs emuladas (ELANs) sobre uma rede ATM. Uma ELAN provê a transmissão de frames de dados entre seus usuários, de maneira semelhante a uma LAN física. Pode-se ter várias ELANs em uma mesma rede ATM, mas estas ELANs são logicamente independentes. Para que estações em ELANs diferentes se comuniquem, é necessário o uso de um roteador. Para otimizar esta comunicação inter-ELAN foi definido pelo ATM Forum um outro serviço, chamado Multiprotocol over ATM (MPOA), que será visto mais adiante.

A especificação do LANE define a operação de uma ELAN. Existem dois tipos de ELAN: Ethernet e Token Ring. Uma ELAN é composta por um conjunto de LECs (LAN Emulation Clients) e pelo serviço, que consiste de três servidores distintos: o LECS (LANE Configuration Server), o LES (LANE Server) e o BUS (Broadcast and Unknown Server). A interface entre os clientes e o serviço é definida pelo protocolo LUNI (LAN Emulation User to Network Interface), que é o objeto da norma de LAN Emulation. A interface entre os elementos do serviço será definida na norma LNNI (LANE Network Node Interface), que está em fase final de aprovação no ATM Forum e está prevista para ser concluída em fevereiro de 1999.

A comunicação dentro de uma ELAN é feita através de circuitos virtuais (VCCs - Virtual Channel Connections). Há VCCs de controle e de transmissão de dados. A interface LUNI usa circuitos virtuais comutados (SVCs) ponto a ponto e ponto a multiponto. O LANE não especifica o suporte a circuitos virtuais permanentes (PVCs).

A interface do LEC com os outros níveis de protocolo dentro de uma estação está ilustrada na figura abaixo:

O LEC oferece ao protocolo acima dele um serviço de transmissão e recepção de quadros semelhante ao de uma rede local, de modo a mascarar do protocolo de rede as complexidades da rede ATM subjacente. Abaixo do LEC está a AAL5. O serviço de LAN Emulation usa somente a AAL5, visto que esta é a mais adequada para a transmissão de dados. O LEC passa à AAL5 um frame semelhante ao Ethernet (ou Token Ring), excluindo apenas o campo FCS (Checksum), já que a AAL5 faz um código de correção de erros semelhante.

É importante notar que o LANE é definido acima da camada ATM, o que o torna transparente para a rede ATM, ou seja, para os switches. O LANE utiliza os protocolos de sinalização padrões do ATM (UNI 3.0 ou superior).

3. Componentes e Conexões

3.1 Componentes

O Lan Emulation define a operação de uma Emulated LAN (ELAN). Várias ELANs podem ser estabelecidas em uma rede ATM. A comunicação entre ELANs será tratada mais adiante. Uma ELAN é composta pelas seguintes entidades:

LAN Emulation Client (LEC) - O LEC é a entidade em uma estação ATM que desempenha as funções de transferência de dados, resolução de endereços, provê a emulação do serviço de rede local para o protocolo camada rede. Um LEC somente pode ser membro de uma ELAN. Uma estação ATM pode participar de mais de uma ELAN, desde que suporte vários LECs, um para cada ELAN. Cada LEC é identificado por um endereço ATM único, associado a um ou mais endereços MAC. No caso de um host ATM, o seu endereço ATM estará associado ao seu endereço MAC unicast e aos endereços multicast que ele desejar receber. Já no caso de um módulo ATM em um switch Ethernet, o endereço ATM do seu LEC estará associado a cada um dos endereços MAC das estações acessíveis através dele.
LAN Emulation Server (LES) - O LES implementa a função de controle e coordenação de uma ELAN. O LES provê serviços de registro e resolução de endereços MAC para endereços ATM. Cada LEC registra os endereços MAC que deseja receber (unicast ou multicast) junto ao LES. Os LECs também contatam o LES para resolver endereços MAC em endereços ATM para que possam estabelecer uma conexão virtual.
Broadcast and Unknown Server (BUS) - O BUS centraliza o envio de quadros em broadcast, multicast e também envia dados em unicast enquanto a resolução de endereços não foi completada, e portanto o transmissor ainda não possui o endereço ATM destino desejado. No LANE versão 1.0, cada LEC só veria um BUS, embora pudesse haver mais de um BUS por ELAN. Na versão 2.0, cada BUS pode ter mais de uma interface (ou seja, mais de um endereço ATM), sendo uma para cumprir as funções básicas do BUS e as outras específicas para determinados endereços multicast (multicast seletivo).
LAN Emulation Configuration Server (LECS) - O LECS é a entidade que associa um LEC a uma determinada ELAN. Um LEC sempre tem que contatar o LECS para entrar em uma ELAN. Feito este contato, se no pedido não houver qualquer violação das políticas do LECS, ele retorna ao LEC o endereço ATM do LES da ELAN desejada, permitindo ao LEC se registrar na ELAN. Somente um LECS pode ser configurado por domínio, e ele serve todas as ELANs dentro deste domínio.

Os três últimos componentes formam o que se denomina LAN Emulation Service. Até hoje não foi definida uma forma de redundância entre os servidores, para melhorar a confiabilidade do serviço. Esta redundância tem de obedecer à seguinte restrição: pode haver mais de um servidor de cada tipo, mas cada LEC só pode enxergar um servidor em um dado momento. Se o servidor principal cair, o secundário passa a exercer suas funções. Uma ELAN não pode ter dois LES ativos ao mesmo tempo. Como esta redundância será implementada deverá ser especificado mais detalhadamente na norma da LNNI, a ser publicada.

3.2 Conexões

As entidades definidas pelo LANE se comunicam através VCCs (Virtual Channel Connections). A versão 2.0 introduz o conceito de fluxo de dados, que está relacionado à multiplexação no nível LLC. Um VCC multiplexado pode transportar um ou mais fluxos, enquanto que um VCC não-multiplexado só carrega um fluxo. A versão 1.0 não suporta multiplexação.

Se um LEC deseja transmitir dados para um determinado endereço ATM, ele tem que estabelecer um VCC para aquele endereço. Se este VCC será multiplexado ou não depende se a outra parte suporta esta característica. Se for desejado estabelecer um novo fluxo de dados, ele pode ser alocado no mesmo VCC, se este for multiplexado.

Analogamente, ao encerrar um fluxo de dados, o VCC é mantido, a não ser que ele seja o único fluxo de dados presente naquele VCC. Isto causa um problema: um LEC pode encerrar um fluxo e a outra parte não tem como saber que ele foi encerrado, pois o VCC ainda existe. Assim, a especificação afirma que um LEC tem de ser capaz de receber pacotes por um fluxo mesmo já o tendo encerrado, se o VCC ainda existir.

Pode-se dividir as conexões do LANE basicamente em dois tipos: VCCs de dados e VCCs de controle. Eles podem ser ponto a ponto ou ponto a multiponto, unidirecionais ou bidirecionais. Os tipos de conexão definidos na LUNI estão listados abaixo.

VCCs de Controle:

Configuration Direct - é estabelecido entre um LEC e o LECS, na fase de inicialização, para obter informações de configuração, como o endereço ATM do LES. É bidirecional. Em geral, este VCC é encerrado após a obtenção destas informações, mas isto não é obrigatório.
Control Direct - é estabelecido entre o LEC e o LES, na fase de inicialização, para troca de frames com informações de controle. É bidirecional.
Control Distribute - é um VCC ponto a multiponto estabelecido pelo LES para todos os clientes de uma ELAN, na fase de inicialização. É usado para distribuição de informações de controle, se o LES preferir não usar o Control Direct para este fim.

VCCs de Dados:

Data Direct - é estabelecido entre LECs para troca de dados unicast. É bidirecional e ponto a ponto. A versão 2.0 implementa mecanismos que permitem às camadas superiores estabelecer parâmetros de qualidade de serviço (QoS) para este tipo de conexão. Também na versão 2.0, pode ser multiplexado.
Multicast Send - é estabelecido entre um LEC e o BUS, para envio de dados em broadcast ou multicast, além de transmissão unicast para um destino cujo endereço ATM ainda não foi encontrado. A versão 2.0 define o Default Multicast Send, que é associado com o endereço de broadcast (todos os bits '1'). Podem ser estabelecidos para o mesmo BUS VCCs para endereços de grupo específicos, chamados Selective Multicast Send. O BUS pode optar por usar o Multicast Send para envio de dados para o LEC, portanto ele deve ser bidirecional.
Multicast Forward - é um VCC multiponto estabelecido pelo BUS para os LECs. O BUS pode estabelecer mais de uma conexão deste tipo para um dado LEC, com a finalidade de enviar multicasts seletivos.

4. Formato dos Quadros de Dados

Como foi dito anteriormente, o LEC passa à AAL5 um quadro de formato semelhante ao dos quadros Ethernet e Token Ring. Para simplificar, este trabalho abordará somente ELANs Ethernet.

O desenho a seguir descreve a trajetória de um pacote de dados desde a camada rede até a camada ATM:

É fácil perceber que o frame usado pelo LANE é semelhante ao Ethernet, para facilitar a comunicação com a LAN tradicional. As diferenças são:

Não existe preâmbulo nem delimitador de início de quadro, pois a rede ATM tem seus próprios mecanismos de sincronização
Acrescenta-se o campo LEC ID, cuja utilização será vista mais adiante
Não há o 'trailer' com o FCS, pois a camada AAL5 já inclui um código de deteção de erros

Uma bridge (switch LAN) ao passar um frame da rede ATM à LAN tem de refazer o frame, incluindo o preâmbulo e o FCS e retirando o LEC ID (que não terá mais utilidade, já que o frame estará saindo da rede ATM). Para passar da LAN à rede ATM realiza as operações inversas.

Há também outros tipos de frame usados no LAN Emulation. Na versão 2, introduziu-se a multiplexação no nível LLC. Os frames usados para este tipo de transmissão são iguais aos quadros de dados normais, acrescidos de um cabeçalho específico do multiplexador LLC.

5. Operação

A operação de uma ELAN pode ser descrita pelos seguintes passos:

5.1 Inicialização e Configuração

O primeiro passo da inicialização de um LEC é a obtenção do seu próprio endereço ATM (que pode ser através de auto-configuração através do protocolo ILMI ). Para prosseguir, o LEC tem que estabelecer uma conexão do tipo Configuration Direct com o LECS. Para fazer isto, o LEC tem três opções, que devem ser tentadas nesta ordem:

Usar um endereço de LECS pré-configurado manualmente pelo administrador;
Obter um endereço de LECS através do ILMI, que é o protocolo de autoconfiguração do ATM;
Usar um endereço conhecido ('well-known address'). Este é um endereço ATM default para o LECS.

Após encontrar o LECS e estabelecer o VCC, o LEC envia um frame LE_CONFIGURE_REQUEST. Se a configuração estiver de acordo com as políticas implementadas no LECS, este envia um LE_CONFIGURE_RESPONSE, com as informações de que o LEC precisa para se juntar a uma ELAN, a saber:

O endereço ATM do LES;
O tipo de LAN sendo emulada (Ethernet ou Token Ring);
O tamanho máximo de quadro na ELAN;
O identificador da ELAN (ELAN_ID).

O LECS é configurado pelos administradores da rede com esta informação. Ele também pode implementar políticas de gerência de rede, como informar a um LEC de qual(is) ELAN(s) ele pode participar, e até, no caso de LECs em um switch LAN com placa ATM, dizer quais endereços MAC representados pelo switch podem participar de quais ELANs.

5.2 Ingresso

Uma vez que já tenha obtido o endereço ATM do LES, o LEC pode ou não encerrar a conexão com o LECS. Em geral, a conexão é fechada. Então, ele estabelece uma conexão Control Direct com o LES e começa a fase de ingresso (join) na ELAN. O cliente envia um LE_JOIN_REQUEST ao LES, que responde criando um VCC Control Distribute para o LEC e enviando-lhe um LE_JOIN_RESPONSE, informando o seu LECID, que será usado na fase de transferência de dados. Embora o registro de endereços deva ser feito numa fase posterior, o LEC pode efetuar um registro inicial de alguns endereços. Porém, o registro de endereços nesta fase possui uma série de limitações em termos de funcionalidade. Este registro inicial serve principalmente para que o LEC verifique se os seus endereços não possuem duplicatas na rede. Um switch LAN que se junte a uma ELAN pode setar um flag no frame de pedido de ingresso que o registra como um cliente Proxy. Isto terá importância no tratamento pelo LES de pedidos de resolução de endereços.

A fase de ingresso na ELAN se conclui com a conexão ao BUS. Para fazer isto, o LEC manda pelo seu Control Direct um LE_ARP_REQUEST para o endereço MAC de broadcast (todos os bits '1'). O LES responde com um LE_ARP_RESPONSE que informa o endereço ATM do BUS. O cliente então estabelece o Default Multicast Send com o BUS, que cria um ou mais Multicast Forward para o cliente.

Exceto pela conexão ao BUS, se qualquer dos procedimentos acima não tiver sucesso, o LEC deve voltar ao início da fase de configuração. Em caso de falha no estabelecimento das conexões com o BUS, pode-se tentar novamente até um limite de tempo determinado.

5.3 Registro

A função de registro é o mecanismo pelo qual os LECs fornecem ao LES informações relativas aos endereços MAC e LANs de destino que eles representam. Este registro alimenta uma tabela que possibilita ao LES responder a pedidos de resolução de endereços de outros clientes. Um switch LAN deve registrar todos os endereços MAC pelos quais ele é responsável, a menos que tenha ingressado na ELAN como um proxy. Se o cliente quiser receber endereços multicast se aproveitando do serviço de multicast seletivo, ele deve registrar todos os endereços de grupo desejados.

Esta função é importante para o anunciar características do LEC que irão afetar o serviço prestado, tais como: qual a versão da sua implementação de LANE, se ele suporta ou não frames multiplexados em LLC e quais as categorias de serviço que ele suporta.

O registro é feito através de frames LE_REGISTER_REQUEST, onde o cliente informa o endereço MAC que quer registrar, o seu endereço ATM e os parâmetros de classe de serviço e de suporte a multiplexação LLC que deseja associar ao endereço. O LES responde com um LE_REGISTER_RESPONSE, apenas confirmando ou negando o pedido.

Um cliente também pode requerer que um endereço seja apagado da tabela do LES. Para isto, ele usa o frame LE_UNREGISTER_REQUEST, informando o endereço que deseja excluir. Novamente, o LES responde com um LE_UNREGISTER_RESPONSE, apenas confirmando ou negando.

5.4 Resolução de Endereços

Este é o procedimento pelo qual um LEC associa um destino de LAN (unicast ou multicast) a um endereço ATM, seja este de outro LEC ou do BUS. Tendo o endereço ATM, o LEC pode estabelecer conexões com o destino desejado e transferir dados.

Quando um LEC depara com um frame cujo endereço MAC destino é desconhecido para ele, ele deve enviar um frame LE_ARP_REQUEST ao LES pelo Control Direct. Ao receber este frame, se ele reconhecer o endereço MAC pedido, o LES pode escolher uma das seguintes linhas de ação:

Repassar o frame ao cliente que representa este endereço MAC para que ele emita um LE_ARP_RESPONSE informando o seu endereço ATM. Este frame de resposta é enviado ao cliente que pediu o LE_ARP através do LES, pelos VCCs de controle;
Ao invés de repassar o frame, o LES pode responder diretamente em nome do cliente que tem o endereço MAC desejado. O LES sempre responde em caso de um endereço MAC multicast.

Por outro lado, o LES pode não conhecer o endereço MAC em questão. Isto ocorre porque um switch LAN pode simplesmente ingressar na LAN como um Proxy, ao invés de registrar todos os seus endereços MAC. Isto é feito para poupar ao switch o overhead de registrar e apagar endereços MAC freqüentemente, porque a configuração de uma LAN muda o tempo todo. Para resolver os endereços que estejam atrás de uma bridge, o LES pode fazer um broadcast do LE_ARP_REQUEST, através do Control Distribute, ou fazer multicast seletivo apenas para os LECs registrados como Proxy. O procedimento adotado pelo LES pode variar com a implementação.

O LE_ARP, além de resolver endereços, também é usado pelo cliente para anunciar características que ele deseja que outros clientes conheçam, como classes de serviço que ele suporta. Para isso, o cliente inclui os TLVs desejados nos frames LE_ARP_REQUEST e LE_ARP_RESPONSE.

Cada LEC mantém um cache com as respostas de LE_ARP, e vai eliminando estes registros através de um mecanismo de time-out. Este mecanismo depende do flag Remote Address, presente nos frames LE_ARP_RESPONSE. Este flag, se é igual a zero, indica que o endereço MAC é registrado junto ao LES, e o parâmetro usado é o 'Aging Time' (valor recomendado: mínimo 10s, default 300s, máximo 300s). Se o Remote Address for igual a um, indica um endereço obtido junto a um Proxy. O tempo de vida destes últimos depende do estado do flag Topology Change no cliente. Se o flag estiver em zero, usa-se o 'Aging time'; se tiver valor um, usa-se o 'Forward Delay Time' (valor recomendado: mínimo 4s, default 15s, máximo 30s).

Também são definidos dois tipos de frame que indicam mudanças na topologia, para que os clientes mantenham suas tabelas corretamente. O LE_NARP_REQUEST indica uma mudança em associações de endereços remotos, ou seja, nos endereços que estão atrás de uma bridge LAN. Um cliente o envia para avisar aos outros clientes que uma associação um destino LAN remoto e um enderço ATM não é mais válida. Tipicamente, quando uma LAN muda de um LEC para outro, o novo LEC ao qual a LAN está associada emite o LE_NARP_REQUEST, e os outros clientes reagem alterando em suas tabelas o endereço ATM correspondente àquela LAN para o endereço do LEC que transmitiu o NARP. O LE_TOPOLOGY_REQUEST indica que uma mudança de topologia está ocorrendo na rede. Sua conseqüência é mudar o estado do flag Topology Change no cliente. Se este flag estiver em '1', o cliente não deve usar nenhuma associação a um destino remoto de seu cache ARP, pois estas podem estar erradas. O flag Topology Change volta a '0' se o cliente recebe do LES um LE_TOPOLOGY_REQUST com este flag em zero.

5.5 Transferência de Dados

Na fase de transferência de dados, o LEC recebe um pacote que a camada rede quer que seja transmitido (no caso de um host ATM), ou um frame Ethernet (no caso de o LEC estar em um switch LAN). Depois de determinar o endereço ATM destino através do LE_ARP, o cliente verifica se já possui um VCC do tipo Data Direct com as características de QoS requeridas conectando-o àquele destino. Se já houver e suportar multiplexação, ele pode criar um novo fluxo de dados naquele VCC e iniciar a transmissão. Se isso não for possível, ele cria um novo VCC Data Direct para aquele destino. Se dois clientes tentam criar VCCs Data Direct um com o outro simultaneamente, é possível que sejam criados dois VCCs, o que ocasiona redundância e conseqüentemente desperdício de banda (pois a banda estará alocada). Em vez de um VCC duplex, teremos dois VCCs simplex. A especificação não recomenda qualquer providência a esse respeito, supondo que este será um fato muito raro para causar problemas.

Deve-se notar que o LE_ARP é independente do protocolo ARP do IP. Quando a camada rede tem um pacote para transmitir para um determinado endereço IP, ela faz um ARP em broadcast para descobrir o endereço MAC de destino. Este pacote ARP é enviado pela ELAN como um pacote de dados qualquer. Tendo descoberto o endereço MAC, ela passa ao LEC um pedido de envio, tendo como parâmetros os dados, o endereço MAC destino e outros opcionais. Por sua vez, o LEC faz um LE_ARP para descobrir o endereço ATM do LEC que representa aquele endereço MAC. Somente com este endereço ATM, o LEC passa o frame à AAL5 para que seja segmentado em células e posteriormente à camada ATM para envio.

Enquanto o cliente está resolvendo o endereço de destino ou criando o VCC de transmissão de dados, ele pode enviar seus frames ao BUS, pelo VCC Default Multicast Send, para que o BUS o repasse ao destino. É importante notar que este repasse é feito a no mínimo o cliente desejado, podendo ser enviado a diversos clientes e até a todos os clientes. No caso de um endereço LAN não registrado, o frame é enviado a pelo menos todos os LECs proxy. Isto não é eficiente em termos de consumo de banda. Além disso, os frames enviados pelo BUS não apresentam garantia de QoS.

Outro problema que isto pode ocasionar é o envio de frames fora de ordem. Por exemplo: um LEC inicialmente envia dados a um destino LAN através do BUS. Quando ele consegue estabelecer um VCC para o destino desejado, ele deixa de mandar para o BUS e manda pelo Data Direct. Tendo caminhos diferentes, os frames podem chegar desordenados. Para evitar este problema, existe o protocolo de Flush. O cliente que está transmitindo, ao mudar o caminho, envia ao caminho antigo um frame LE_FLUSH_REQUEST, que é um frame de dados onde o campo LECID tem o valor 'FF00' e não transmite pelo caminho novo. Sendo um frame de dados, ele é transmitido pelo Data Direct ou por um Multicast Send. O LE_FLUSH_RESPONSE, que é o retorno desta mensagem, é recebido por um VCC de controle. Quando o LEC recebe o retorno, isto quer dizer que o caminho antigo já transmitiu todos os frames que tinha para aquele destino, e só então ele pode começar a transmitir pelo caminho novo. Ao invés de usar o Flush, o LEC pode simplesmente esperar por um tempo determinado (parâmetro 'Path Switching Delay', valores recomendados: mínimo 1s, default 6s e máximo 8s) antes de mandar pelo novo caminho. No caso de mudança de trajeto em frames multicast, não se usa o Flush, e sim este último procedimento.

Em caso de frames multicast, o cliente deve sempre tentar o envio por um VCC Selective Multicast Send, se houver um associado ao endereço de grupo desejado. Se não houver, ele deve enviar pelo Default Multicast Send. O BUS possui diversos VCCs do tipo Multicast Forward (ponto a multiponto), além de poder transmitir pelos Multicast Send (que são bidirecionais). Como o BUS irá distribuir o tráfego multicast e broadcast é determinado na implementação, com a única restrição de não enviar mais de uma vez o mesmo frame a um cliente. O cliente, ao receber frames do BUS, confere o endereço MAC destino do frame. Se não for um endereço multicast que ele deseje receber, ele simplesmente descarta o frame. O cliente também deve descartar frames cujo LECID seja o seu próprio, pois isso indica que foi ele mesmo que enviou o quadro. Este é o mecanismo de cancelamento de eco de multicast definido no LANE. Na versão 1.0, todos os frames multicast eram enviados a todos os LECs em uma ELAN, e eles descartavam os indesejados. É um dos principais avanços da versão 2.0 o suporte a multicast seletivo, para evitar o desperdício de banda acarretado pelo esquema anterior.

5.6 Qualidade de Serviço

Um dos avanços mais importantes do LANE 2.0 é a possibilidade de as camadas mais altas se utilizarem das características de qualidade de serviço inerentes à rede ATM.

O LEC disponibiliza à camada rede uma primitiva para a criação de conjuntos de características de QoS (QoS Sets), que são identificados por um 'qos_handle'. A primitiva de pedido de envio de dados tem como um de seus parâmetros um qos_handle. Os parâmetros configuráveis de QoS e as classes de serviço são os padrões definidos na norma ATM Traffic Management.

O VCC para transmissão é criado pelo LEC. De acordo com o qos_handle especificado, o LEC automaticamente cria uma associação (QoS Binding) deste VCC com um QoS Set. Este QoS Binding só é perdido quando o VCC é encerrado ou se o QoS Set for destruído pelas camadas mais altas. Quando nenhum qos_handle é especificado no pedido de envio, o LEC faz o Binding com o Default QoS Set, que corresponde à classe de serviço UBR. Um LEC não pode criar mais de um VCC para um determinado destino com o mesmo QoS Binding, e sim criar um novo fluxo de dados no VCC existente. Essa restrição visa a limitar de alguma forma o número de VCCs, e o overhead decorrente.

É importante notar que a garantia de QoS vale de LEC para LEC. Uma estação ligada a uma LAN atrás de um LEC está sujeita a perda de qualidade pela natureza do serviço da LAN, que é do tipo "melhor esforço".

6. Implementação

Abaixo vemos um exemplo de como as ELANs são implementadas na prática:

Tem-se um backbone composto por switches ATM. Nestes switches são ligados hosts com placas ATM (que em geral serão servidores ou estações com grande necessidade de banda) além de switches LAN com placas de interface ATM, que conectam as LANs tradicionais ao backbone. É importante notar que uma mesma interface ATM pode suportar vários LECs. Um switch LAN com um módulo ATM em geral pode ser configurado com tantos LECs quantas VLANs ele suporta. Como uma VLAN é logicamente idêntica a um segmento de rede, cada LEC será a ponte entre a rede ATM e o segmento LAN associado a ele.

Dentro desta rede ATM podem ser configuradas várias ELANs. O tráfego entre estações em ELANs diferentes tem de ser comutado na camada rede através de um roteador, pela seguinte razão: um host na rede ATM só consegue criar um VCC para outro host se possuir o endereço ATM de destino. A ELAN define um domínio de broadcast, através do BUS. Quando a camada rede tem um pacote para enviar em uma LAN tradicional (em uma ELAN ocorre o mesmo), ela descobre o endereço MAC de destino através de um ARP (no caso do IP). O ARP é um pacote enviado em broadcast com o endereço IP destino, para que o host que possuir aquele endereço responda com seu endereço MAC. Se o host está em uma ELAN diferente, os pacotes ARP não chegarão até ele, e portanto não será possível descobrir o endereço. Deste modo, o host terá que enviar todos os pacotes ao seu Default Gateway para que este calcule a rota e envie o pacote ao roteador da rede onde o host destino estiver. Assim, é necessário que haja roteadores ligados à rede ATM. Como um LEC só pode estar ligado a uma ELAN, o roteador terá de suportar tantos LECs quantas ELANs ele estiver servindo. Os LECs podem estar na mesma interface.

Há algumas particularidades do LANE que impõem restrições ao equipamento usado. Os switches ATM, por exemplo, têm de ser capazes de manipular VCCs muito rapidamente, pois o LANE cria e destrói conexões de forma muito dinâmica. O número de VCCs em uma ELAN é proporcional ao quadrado do número de clientes, portanto conforme a rede cresce, as conexões aumentam em progressão geométrica. Como não há ainda uma norma estabelecendo redundância entre os servidores LANE, estes se tornam pontos críticos de falha, portanto têm de ser implementados em equipamentos muito confiáveis. Além disso, os servidores exigem muito processamento e grande capacidade de comutação, especialmente o BUS, que manipula muito tráfego. Em geral os servidores são implementados nos switches do backbone, mas há quem defenda que isto sobrecarrega a rede, que já tem que lidar com a parte de sinalização e transferência de células. Os partidários desta tese são a favor de implementar o LANE Service em um switch de borda muito robusto.

7. MPOA

Como já foi dito, o tráfego entre ELANs tem que ser comutado na camada rede, o que geralmente é feito através de roteadores. O problema que isto apresenta é que os protocolos de nível 3 em geral oferecem serviços datagrama e calculam a rota para cada pacote enviado. Isto acarreta um atraso inaceitável para uma rede ATM. Se os dois hosts estão na mesma "nuvem" ATM, deve ser possível aproveitar esta rede para transferir dados entre eles.

O MPOA é um serviço definido pelo ATM Forum para complementar o LANE e que visa a otimizar a transferência do tráfego entre ELANs. Ele faz uso do protocolo de roteamento NHRP (Next Hop Resolution Protocol) para criar atalhos entre as ELANs, evitando o processo de cálculo de rotas no roteador. Cada ELAN é configurada como uma LIS (Logical IP Subnet), ou seja, uma sub-rede IP.

O MPOA possui dois componentes: o MPOA Client (MPC) e o MPOA Server (MPS). O MPC é implementado nas estações e switches de borda, enquanto que o MPS é implementado nos roteadores. Ele funciona da seguinte forma:

Inicialmente, um pacote para outra ELAN é enviado ao roteador
O MPC monitora o tráfego através do LEC, tentando identificar fluxos; como identificar os fluxos é deixado a critério do implementador
Quando se configura um fluxo, o MPC envia um query ao seu MPS, pedindo que se crie um atalho
O MPS vai propagando o query pelos MPSs (roteadores), até chegar ao que serve ao MPC destino
O MPC responde com o endereço ATM do LEC destino, que vai sendo propagado de volta pelos MPSs
De posse do endereço ATM destino, o MPC inicial cria um atalho, que nada mais é que um VCC através da rede ATM até o destino
A partir daí, os dados são enviados pelo atalho, que fica estabelecido até que passe muito tempo sem atividade

Deve-se notar que as entidades do MPOA (MPC e MPS) trocam informações através do serviço LAN Emulation. Cada MPC e MPS tem de ter um LEC associado, e a troca de dados do MPOA ocorre como qualquer outra troca de dados. Para que uma estação suporte o MPOA, ela tem de possuir um LEC versão 2.0.

8. Conclusão

O LANE foi desenvolvido para levar até as redes corporativas de dados (baseadas em LANs) os benefícios do ATM, que é em sua essência uma tecnologia de WAN. As diferenças fundamentais entre os serviços de uma LAN e do ATM fazem com que a sua interconexão seja muito complexa. Além disso, o LANE deverá ser usado juntamente com o MPOA para aumentar sua escalabilidade, permitindo que se construam backbones corporativos maiores usando a rede ATM. Isso agrega ainda mais complexidade à rede. Aliás, a complexidade não é uma característica somente do LANE e do MPOA, ela pode se estende para o ATM e seus serviços de forma geral.

Apesar desta complexidade, os preços dos equipamentos ATM vêm caindo de forma considerável nos últimos anos. Mesmo assim, ainda são maiores que os dos competidores. No caso de backbones corporativos, o principal destes é o Gigabit Ethernet. Este apresenta como sua maior vantagem a simplicidade na migração, já que é uma extensão do Ethernet. Deste modo, ele se integra facilmente à base instalada.

Por outro lado, o ATM deverá ter mais facilidade de se integrar às MANs e WANs, à medida que as operadoras e provedores de serviço forem oferecendo redes públicas ATM a preços cada vez mais competitivos. Além disso, já está sendo desenvolvida (esperada para junho/99) a interface que permitirá que se use como nível físico do ATM o OC-48, que roda a 2.5 Gbps, superando a banda oferecida pelo Gigabit Ethernet.

O grande argumento em favor do ATM, no entanto, é a garantia de QoS. Foi um grande avanço da versão 2.0 disponibilizar esta característica. Entretanto, os protocolos e aplicações existentes ainda têm de ser modificados para poderem usar esse serviço. O desenvolvimento de APIs que usam ATM em modo nativo também é promissor, pois assim poderão ser criados aplicativos que usem diretamente os benefícios do ATM.

9. Links

Normas publicadas pelo ATM Forum (disponíveis para download no formato PDF)

Normas em andamento no ATM Forum

Artigos sobre ATM:

Anthony Alles (Cisco): ATM Internetworking
Este é um paper muito interessante em que o autor discute diversos aspectos da utilização do ATM. É um pouco antigo (1995), e portanto está desatualizado. Entretanto, aborda muitos conceitos importantes e vale a pena ser lido para quem já possui noções básicas e deseja estender-se sobre o assunto. O capítulo 5 é o que trata de LAN Emulation.

Bob Klessig (3Com): LAN Emulation
Este paper é específico sobre LAN Emulation, descrevendo sua operação e seus benefícios. Fala sobre a versão 1.0.

Apêndice: Perguntas

1. Quais as funções realizadas pelo LAN Emulation?
Oferece à camada rede uma interface semelhante à de uma LAN, o que possibilita a preservação dos aplicativos atuais sem necessidade de mudança de drivers; define o ‘bridging’ entre o ATM e as LANs 802.3, permitindo a comunicação entre as duas redes.

2. Numa estação rodando LANE, o que acontece com um pacote de dados desde a camada rede até a transmissão?
Na camada LANE, recebe um cabeçalho semelhante ao Ethernet mas sem o preâmbulo, o delimitador de início de quadro e o FCS (código corretor de erros). Então é passado à camada AAL5, onde recebe um ‘trailer’ que inclui o comprimento do quadro, um ‘padding’ e um CRC. A AAL5 fragmenta o frame em células de 48 bytes e passa-o à camada ATM, que acrescenta a cada célula um cabeçalho ATM de 5 bytes, passando as células à camada física para transmissão.

3. Qual é a principal função do LES (LAN Emulation Server)?
Mapeamento de endereços MAC em endereços ATM. O LES mantém uma tabela relacionando os endereços MAC (inclusive os multicast) aos endereços ATM dos LECs (LAN Emulation Clients) que as representam. Quando um LEC deseja transmitir um pacote a um determinado endereço MAC, ele faz um pedido de resolução de endereços ao LES, que responde fornecendo o endereço ATM do destino.

4. Em que situações um LEC envia um frame ao BUS (Broadcast and Unknown Server)?
Nos seguintes casos: no envio de frames multicast e quando o endereço ATM de destino ainda não é conhecido. O frame é enviado ao BUS para que ele o repasse ao destino ou destinos (se for multicast).

5. O que acontece com o tráfego entre ELANs diferentes e qual o papel do MPOA (Multiprotocol over ATM)?
Como um host não consegue descobrir o endereço de outro que não esteja na mesma ELAN, o tráfego entre estações em ELANs diferentes tem de ser comutado na camada rede, ou seja, transmitido através de um roteador. O MPOA permite otimizar esta transmissão através da criação de atalhos na rede ATM, contornando assim os roteadores.