plataforma piloto de ipv6 sobre atm para ambientes multicastin

Sumário
PLATAFORMA PILOTO DE IPV6 SOBRE ATM PARA AMBIENTES MULTICASTING
Nuno Veiga 1 , Jorge Sá Silva 2 , Sérgio Duarte 3 e Fernando Boavida 4
Grupo de Comunicações e Serviços Telemáticos
Departamento de Engenharia Informática, Universidade de Coimbra - Pólo II
3030 COIMBRA
Tel: +351-39-790000, Fax: +351-39-701266, E-mail: sasilva@dei.uc.pt
Este artigo apresenta a concepção e o desenvolvimento de uma
plataforma experimental para o estudo do Internet Protocol
version 6 (IPv6) sobre Asynchronous Transfer Mode (ATM)
no âmbito do projecto MEDIA – MARS Extensions Developed
for IPv6 over ATM. Neste trabalho é dada especial atenção à
criação de ambientes de multicasting.
1. INTRODUÇÃO
A Internet terá de conseguir satisfazer o elevado número de
requisitos impostos quer pelos serviços actuais, quer pelos
serviços futuros. O rápido crescimento verificado no número
de utilizadores e a necessidade de suportar serviços sensíveis
ao atraso e serviços multimedia evidenciaram a presente
inadaptação do Internet Protocol version 4 (IPv4). O IPv6 foi
desenhado para ultrapassar as limitações impostas pelo IPv4 e
acomodar as necessidades sentidas pelos actuais utilizadores.
Aliás, o maior objectivo que se apresenta ao IPv6 é estar
concluído antes da ruptura do IPv4.
O IPv6 teve por base o Simple Internet Protocol Plus
[DEE94], e não está definido numa simples especificação mas
num conjunto de RFCs [DEE95], [HIE95], [CON95],
[ATK95A] e [ATK95E].
Enquanto o IPv4 delegava para um outro módulo a resolução
de endereços da camada 3 para a camada 2, e assim
apareceram diferentes soluções como o Address Resolution
Protocol (ARP) ou o ATMARP, o IPv6 assume ele próprio
essa função. No entanto o IPv6 requer da camada inferior um
meio do tipo multicast connectionless. Ora, como o ATM não
oferece esta funcionalidade de forma directa, é necessário
introduzir uma subcamada entre a camada 3 e a camada 2 que
ofereça este ambiente ao IPv6 para assim poder executar o
Neighbor Discovery, o Router Discovery, e o Address
Configuration.
Não existia originalmente suporte multicast no Classical IP
[LAU98]. Posteriormente introduziu-se o Multicast Address
Resolution Server (MARS) [ARM96] que agrega um grupo de
nós (cluster). O MARS permite o mapeamento entre o
endereço multicast da camada 3 e os correspondentes
endereços ATM. Assim, quando o emissor pretender enviar
uma mensagem para um endereço IP multicast e desconhecer
quais os vários endereços ATM correspondentes terá de
solicitar ao servidor MARS a resolução.
A especificação do MARS oferece duas opções. Na primeira
opção, cada nó que pretende enviar uma mensagem multicast
estabelece uma ligação ponto-multiponto para todos os nós
terminais desse grupo ("VC-mesh"). Na segunda opção, o nó
estabelece ligação com um ou mais servidores multicast
(MCS) que por sua vez mantêm ligações com os nós
terminais.
Alguns sistemas poderão beneficiar do método MCS, e.g.
1 Instituto Politécnico de Leiria
2 Grupo de Comunicações e Multimedia – Universidade de
Trás-os-Montes e Alto Douro
3 Instituto Politécnico da Guarda
4 Departamento de Engenharia Informática - Universidade de
Coimbra
quando o grupo muda frequentemente e apresenta um elevado
número de elementos. Uma estrutura do tipo VC-mesh poderá
ser preferível quando o grupo é pequeno e estável ou o atraso
de re-assembly e retransmissão dos pacotes AAL5 é
inaceitável.
O domínio do MARS, denominado como Cluster MARS, é na
prática um conjunto de pontos terminais que escolhem usar o
mesmo MARS para registarem a sua participação em grupos e
receber daquele as suas actualizações.
Em geral, o Cluster MARS vai-se sobrepor totalmente a uma
Logical IP Subnet (LIS) a qual é definida pelo conjunto de nós
que usam o mesmo servidor ATMARP.
O IETF, nomeadamente o grupo ION, parece optar por utilizar
o MARS como a estrutura que possibilita oferecer à camada
IPv6, através da subcamada IPv6-ATM, o meio broadcast. No
entanto o MARS apresenta um conjunto significativo de
restrições.
Praticamente todos os estudos elaborados na integração do IP
sobre o ATM não tiram proveito das melhorias introduzidas
pelo IPv6, nomeadamente a introdução dos cabeçalhos
opcionais, e utilizam versões antigas do User Network
Interface (UNI). De facto, com o desenvolvimento do UNIv4
[ATM96] introduziram-se os endereços de grupo, geridos pelo
Interim Local Management Interface (ILMI), e o Leaf
Initiated Join (LIJ). Enquanto os endereços de grupo
oferecerão uma maior simplificação nas tabelas de
mapeamento dado possibilitarem relações de um-para-um, o
LIJ possibilita aos nós ATM poderem-se eles próprios ligar a
um grupo multicast.
Este artigo apresenta a construção de uma plataforma
experimental IPv6-ATM que permite o estudo de mecanismos
inovadores em IPv6 sobre ATM.
2. PLATAFORMA PRÁTICA
A plataforma prática descrita neste trabalho consiste numa
rede ATM ligada através de dois routers a redes IPv6-Ethernet
(Figura 1).
IPv6 ATM
IPv6
Figura 1 – Plataforma prática
A rede ATM é constituída por dois switches ATM e seis
computadores pessoais (PCs) equipados com placas ATM
Fore PCA-200EPC (Figura 2). Dois dos PCs funcionam como
IP routers, estando para tal equipados também com placas
Ethernet. Um dos PCs funciona como servidor MARS e dois
outros funcionam como servidores multicast (MCS).
1

IPv6
Host
IP Router Switch
MCS / Host
Figura 2 – Rede ATM
IP Router
Switch
MARS / Host
MCS / Host
Cada host utiliza o Sistema Operativo FreeBSD. Na Figura 3
está representada a pilha protocolar inicial de um router,
nomeadamente a componente ATM e a componente Ethernet.
O device driver para a placa ATM, no sistema operativo
FreeBSD, foi desenvolvido no âmbito de um projecto do
Grupo de Comunicações e Serviços Telemáticos [ARA96].
Foram estabelecidos contactos com o fabricante da placa que,
mediante a assinatura de um contrato, forneceu o código fonte
para o sistema operativo SunOS 4.1.x. A disponibilidade do
código possibilitou a sua reutilização já que muitos dos
mecanismos internos dos sistemas operativos em causa são
semelhantes.
IPv6
Aplicação
IPv4
ATMARP/CLIP ARP
SNAP-Encap LL-Encap
Driver ATM Driver Ethernet
Figura 3 - Pilha protocolar inicial de um router
Na camada CLIP [LAU98], a função arp_ifconnect() é usada
para estabelecer ligações ATM. Se o endereço IP destino é do
tipo unicast e ainda não foi traduzido para um endereço ATM
(não se encontra na tabela ATMARP) então o protocolo
ATMARP é utilizado para traduzir o endereço. Para tal, a
função atm_arpwhohas() estabelece uma ligação ao servidor
ATMARP e envia-lhe um pedido ATMARP_REQUEST. A
ligação ATM é estabelecida com o destino assim que o
endereço tenha sido traduzido.
A função do_output() é então chamada para transmitir a
mensagem através do VC estabelecido pela função anterior.
O tratamento de mensagens to tipo ATMARP processa-se da
seguinte forma. Ao receber uma mensagem deste tipo (Figura
5), o módulo SAR (Segmentation And Reassembly) da camada
AAL 5 do driver ATM (função sar_reassembly()), chama o
código de tratamento de mensagens ATMARP (função
arpinput()) fornecendo-lhe a mensagem e o VCI onde ela foi
recebida. As mensagens possíveis são [LAU98]:
ARPOP_REQUEST, ARPOP_REPLY, ARPOP_NAK para o
protocolo ATMARP (tratadas pela função
in_atmforum_arpinput()) e InARP_REQUEST,
InARP_REPLY para o protocolo InATMARP (tratadas pela
função in_atm_inarpinput()).
3. NOVOS MÓDULOS
Nesta secção descrevem-se os novos módulos em
desenvolvimento e as adaptações no ambiente de
implementação FreeBSD - Fore ATM necessárias à integração
dos novos módulos.
Aplicação
RSVP
IPv6
Driver IPv6-ATM
ATMARP /
LL-Encap
CLIP MARS
SNAP-Encap
Driver ATM Driv. Ethernet
Figura 4 - Pilha protocolar final de um router
Pretendendo-se disponibilizar uma plataforma com a nova
versão do IP (IPv6), a camada IPv4 na pilha protocolar inicial
terá de ser substituída. O IPv6 vai interagir com uma nova
subcamada IPv6-ATM. Esta subcamada oferece ao IPv6 o
meio multicast connectionless utilizando os serviços MARS.
Todos estes módulos permitirão, mais tarde, fornecer
ambientes multicasting à camada das aplicações.
No interface Ethernet, a camada ARP desaparece, uma vez
que a resolução de endereços passa a ser feita pelo próprio
IPv6.
Surge assim a nova pilha protocolar (Figura 4) que constitui o
objectivo deste trabalho.
Módulo SAR
FORE_sar_reassembly
(unit, au)
ARP m
m
FORE_arpinput
(m,vci,...)
m.ARPOeration
ARPOP_REQUEST
_REPLY
_NAK
in_atmforum_arpinput
(m, vci, ...);
MARS m
InARP_REQUEST
_REPLY
MARS_input
(m,vci,...)
Figura 5 - Tratamento de mensagens ARP e MARS
in_atm_inarpinput
(m, vci, ...);
Presentemente está-se a desenvolver o código dos módulos
MARS: módulo emissor, módulo receptor e módulo servidor
MARS.
Um cliente MARS situa-se entre a camada IP e a camada
ATM (Figura 4) e pode existir num host ou num router.
Inicialmente, o cliente MARS estabelece um VC ponto a
ponto bidireccional com o servidor que posteriormente vai
utilizar para enviar pedidos e receber respostas. O servidor
(MARS) estabelece um VC de controlo ponto-multiponto
(ClusterControlVC) ao qual vai adicionando como folhas os
vários clientes que o contactam.
O tratamento das mensagens utilizadas no protocolo, é
efectuado da seguinte forma. Ao receber uma mensagem to
tipo multicast (Figura 5), o módulo SAR do servidor da
camada AAL 5 do driver ATM, chama o código de tratamento
de mensagens MARS (função MARS_Input() ) fornecendo-lhe
a mensagem e o VCI onde ela foi recebida.
2

3.1. CLIENTE MARS
O cliente divide-se em duas subsecções: origem (a parte que
deseja enviar mensagens multicast) e destino (a parte que
deseja receber mensagens multicast).
S
IP
m.IP_dst
in ARPTAB
N
atm_arpresolve
(IP_dst,...)
do_output
(m,vci,...)
m
unicast
Figura 6 – Resolução de endereços
S
if_output
(m,IP_dst,...)
m.classe
multicast
m.IP_dst
in ARPTAB
N
MARS_resolve
(IP_dst,...)
Quando a entidade IP local fornece uma mensagem para
transmissão (função if_output() ) e a mensagem é destinada a
um grupo é chamada a função MARS_resolve() (Figura 6).
Esta função verifica se já existe uma ligação para o grupo
multicast destino. Esta verificação é efectuada na tabela
ATMARP modificada de modo a suportar relações de 1
endereço IP multicast para vários endereços ATM. Se não
existe a ligação, envia-se ao servidor uma mensagem
MARS_REQUEST com o endereço multicast através do VC
ponto a ponto preestabelecido. A resposta do MARS é uma
sequência de mensagens MARS_MULTI com os endereços
ATM dos elementos do grupo. O cliente estabelece então o
VC ponto–multiponto com os elementos do grupo (Figura 7,
passos 1 a 3). Quando o grupo não tem membros ou é
desconhecido pelo servidor, este envia uma mensagem
MARS_NAK ao cliente. Neste caso, o cliente ignora a
mensagem IP destinada ao grupo.
Estabelecido o VC ponto-multiponto para o grupo, o cliente
origem fica atento a futuras alterações no grupo, adicionando
ou eliminando nós folha. Essas alterações são anunciadas ao
cliente pelo servidor através do ClusterControlVC na forma de
mensagens MARS_JOIN e MARS_LEAVE (secção 3.2.) que
contêm o endereço ATM do membro que se junta ou sai do
grupo e o endereço IP multicast do(s) grupo(s) em causa.
Pode acontecer que um membro do cluster perca alguma das
mensagens de actualização da informação de grupo enviada
pelo MARS através do ClusterControlVC. O cliente detecta
estas falhas analisando o Cluster Sequence Number (CSN) que
é transportado nas mensagens MARS (campo mar$msn)
difundidas através do ClusterControlVC. O CSN é
incrementado pelo MARS de um a cada nova transmissão que
faz através do ClusterControlVC. Quando o membro do
cluster detecta um salto no CSN (perda de uma possível
actualização de informação de grupo), inicia um mecanismo
de revalidação da informação dos grupos para os quais o
cliente tem actualmente VCs multicast abertos.
Se ocorrer um erro num VC associado com um grupo, o
cliente origem inicia um processo de revalidação apenas para
o grupo desse VC.
Para revalidar um grupo, o cliente origem começa com o
reenvio ao servidor de uma mensagem MARS_REQUEST com
o grupo em causa. O conjunto de membros devolvido é
comparado com o conjunto já existente localmente (na tabela
ATMARP). L_MULTI_DROPs são efectuados no VC do grupo
para cada nó que deixou de pertencer ao grupo.
L_MULTI_ADDs são efectuados no VC do grupo para cada nó
que passou a pertencer ao grupo.
Um cliente (destino) pode querer adicionar-se (deixar de
pertencer) a um grupo em resposta a um pedido local da
camada IP.
Para se adicionar, o cliente envia uma mensagem MARS_JOIN
ao servidor MARS com o endereço IP multicast do grupo
através do VC ponto a ponto preestabelecido. Para abandonar
o grupo envia uma mensagem MARS_LEAVE.
Estas mensagens são propagadas pelo servidor através do
ClusterControlVC para informar outros clientes (origem) da
alteração da constituição do grupo.
Os IP multicast routers são anunciados pelo servidor como
membros de todos os grupos de modo a receberem mensagens
dirigidas a todo e qualquer grupo de uma forma promíscua
possibilitando o encaminhamento de uma mensagem multicast
para elementos do grupo que se encontrem noutra rede.
Host 4
MARS
Cluster
Host 3
Host 2
IP Router
6
MCS
IP
7
5 4
3
MARS
Cluster 2
MARS
1 2
Host 1
Figura 7 - Exemplo de transmissão multicast na presença de
um MCS (O host 1 envia para o grupo a cinza)
Cada cliente (origem ou destino) regista-se inicialmente no
servidor estabelecendo com ele um VC ponto a ponto por
onde envia uma mensagem MARS_JOIN de registo (diferente
de um MARS_JOIN de junção a um grupo) com o seu
endereço ATM. O servidor adiciona o cliente como nó folha
do ClusterControlVC e atribui-lhe um identificador de 16 bits
(CMI) que o identifica no cluster.
O cliente espera então por uma confirmação do servidor (uma
cópia da mensagem original) pelo mesmo VC. Se a resposta
não chegar num intervalo de tempo predefinido (cerca de 10
segundos), a mensagem é retransmitida.
Quando o cliente pretende abandonar o cluster, anula o
registo, enviando uma mensagem MARS_LEAVE ao
servidor. Isto leva a que o servidor elimine o cliente do
ClusterControlVC e liberte o seu CMI.
3.2. SERVIDOR MARS
Como foi já referido, o tratamento das mensagens MARS no
servidor (Figura 5) é efectuado pela função MARS_Input() que
recebe, além da mensagem, o VCI onde ela foi recebida.
Quando chega uma mensagem MARS_JOIN de registo, o
servidor MARS adiciona o nó ao ClusterControlVC e atribuilhe
um novo CMI que insere no campo mar$cmi da
mensagem. Esta é então retransmitida apenas ao cliente que a
enviou. Quando chega uma mensagem MARS_LEAVE de
anulação de registo, o servidor MARS retira o nó do
ClusterControlVC e liberta o respectivo CMI. A mensagem é
também retransmitida apenas ao cliente que a enviou. O
3

servidor ignora mensagens MARS_JOIN ou MARS_LEAVE
que não sejam de registo e que sejam provenientes de um nó
que não está registado como membro do cluster.
Se a mensagem MARS_JOIN não é de registo mas de junção a
um grupo, a mensagem é retransmitida pelo ClusterControlVC
para todos os membros do cluster. Se o nó já pertencia ao
grupo, a mensagem é retransmitida apenas ao nó em causa
através do VC ponto a ponto preestabelecido. O mesmo se
passa com as mensagens MARS_LEAVE que não são de
anulação de registo.
Se o servidor MARS recebe um MARS_LEAVE de anulação
de registo, o endereço ATM desse membro é removido de
todos os grupos, eliminado do ClusterControlVC, e o seu CMI
libertado. O mesmo acontece quando o MARS recebe um
ERR_L_RELEASE indicando que o membro do cluster foi
desligado.
Todas as mensagens MARS_JOIN ou MARS_LEAVE enviadas
pelo servidor MARS através do ClusterControlVC levam o
campo mar$msn com o valor corrente do CSN permitindo aos
clientes a detecção da perda de alguma destas mensagens.
Se existe algum MCS (Figura 7 - passos 3 a 6) registado no
MARS, o servidor MARS modifica a sua distribuição de
actualizações join/leave aos membros do cluster. O MARS
utiliza duas novas mensagens - MARS_SJOIN e
MARS_SLEAVE - para comunicação de alterações de grupo
aos MCSs através do ServerControlVC ( um VC de controlo
ponto-multiponto mantido pelo MARS para todos os MCSs
nele registados).
4. CONCLUSÃO E TRABALHO FUTURO
Neste trabalho é descrita a criação de um ambiente
experimental para o estudo do IPv6 sobre ATM.
Estão a ser desenvolvidos os módulos MARS, e a subcamada
IPv6-ATM, fornecendo à plataforma suporte para multicast.
O MCS (servidor multicast) não está ainda implementado.
Será esse o próximo passo no desenvolvimento da plataforma.
Assim, a implementação baseia-se numa estrutura do tipo
"VC-mesh". A implementação do MCS só obriga à alteração
da parte servidor do MARS, sendo transparente para o Cliente
MARS.
Em [ARM96] está prevista a existência de servidores MARS
de backup. No entanto a sua especificação é vaga, ficando
como um ponto em aberto.
Depois do ambiente experimental estar concluído espera-se
estudar extensões aos ambientes MARS e tirar proveito de
algumas funcionalidades introduzidas no IPv6. A plataforma
piloto apresentada neste artigo constitui um sistema para o
estudo de duas recentes tecnologias de elevado potencial.
Paralelamente, no projecto MEDIA, estão a ser desenvolvidos
estudos que tiram partido de um cabeçalho opcional do IPv6 e
possibilitam as relações de um para um entre o endereço IP
multicast e o endereço ATM multicast introduzido pelo
UNIv4 e suportado pelo ILMI.
5. REFERÊNCIAS
[ARA96] Araújo, F., “QoS – Qualidade de Serviço em
Redes de Alto Débito – Parte A”, Relatório da Cadeira
de Projecto e Dissertação, DEI, Universidade de Coimbra,
Novembro de 1996
[ARM96] Armitage, G., “Support for Multicast over UNI
3.0/3.1 based ATM networks”, RFC 2022, November
1996
[ATK95A] Atkinson, R., "IP Authentication Header", RFC
1826, August 1995
[ATK95E] Atkinson, R., "IPng Encapsulation Security
Payload", RFC 1827, August 1995
[ATM96] ATM Forum, "ATM User-Network Interface (UNI)
Specification version 4.0", ATM Forum Specification afsig-0061.000,
Jully 1996
[CON95] Conta, A. And Deering, S., "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
version 6 (IPv6) Specification", RFC 1885, Digital
Equipment Corporation, December 1995
[DEE94] Deering, S., "SIMPLE Internet Protocol Plus (SIPP)
Specification (128 address version)", Internet Draft, July
1994
[DEE95] S. Deering, S. And Hinden., "Internet Protocol,
Version 6 (IPv6) Specification.", RFC 1883, December
1995
[HIE95] Hinden, Robert M., "IP Version 6 Addressing
Architecture", RFC 1884, December 1995
[LAU98] Laubach, M. and Halpern J., "Classical IP and ARP
over ATM", RFC 2225, Com21, Inc., Newbridge
Networks, Inc., April 1998
4