Arquitetura de rede ethernet robusta e de baixo custo

Arquitetura de rede Ethernet robusta e de baixocusto

Giovanni Curiel dos Santos*, Vinicius Garcia de Oliveira, Marcos Rogério Salvador, AlbertoParadisi, Tania Regina Tronco, János Farkas, Csaba Antal

Este artigo descreve uma arquitetura de rede Ethernet robusta, simples e de baixo custo capaz deproteger elementos e enlaces de rede em tempos inferiores a 50 milissegundos. A arquitetura propostafunciona com comutadores Ethernet comerciais de baixo custo e com qualquer topologia física.Resultados experimentais obtidos em um protótipo de rede laboratorial comprovam que a arquitetura éeficaz em tempos inferiores ao tempo-padrão de 50 milissegundos exigido por operadoras detelecomunicações e corporações.

Palavras-chave: Proteção. Ethernet. PBB. PBT. Engenharia de tráfego.

Introdução

A convergência das telecomunicações na Internet e a crescente pressão pela redução dos custos de aquisição e, principalmente, de operação das suas redes têm levado as operadoras e as grandes corporações a reavaliarem suas redes. Muitas já iniciaram a substituição gradual das tecnologias que permeiam essas redes por novas que sejam mais adequadas ao novo cenário das telecomunicações.Entre as novas tecnologias em análise, destaca-se o “bom e velho” Ethernet, tecnologia de pacotes concebida por Robert Metcalf em 1972 e padronizada pelo IEEE em 1983. O Ethernet evoluiu consideravelmente ao longo dos seus 35 anos de existência, partindo de uma tecnologia criada para redes locais operando a 10 Mbit/s sobre um cabo metálico compartilhado para uma tecnologia de comutação de múltiplas aplicações operando a 10 Gbit/s sobre fibra óptica.O potencial de oferta de alta capacidade a baixos custos proporcionado pelo Ethernet tem elevado o interesse no uso dessa tecnologia também em aplicações metropolitanas, corporativas e de longa distância, que hoje utilizam tecnologias mais complexas e custosas como ATM, SDH e Frame Relay. No entanto, para substituir essas tecnologias faltam ao Ethernet mecanismos mais sofisticados e robustos de operação, administração, gerência e provisão de serviços. Em particular, falta ao Ethernet um mecanismo de proteção rápida, mais especificamente um mecanismo capaz de recuperar a rede de uma falha em tempos inferiores aos 50 milissegundos do SDH, tido como um padrão de fato exigido pelas operadoras.Este artigo apresenta uma solução de baixo

custo para esta limitação do Ethernet. Essa solução se baseia em uma arquitetura de rede e em um protocolo que implementam um mecanismo simples, robusto e escalável de proteção distribuída, independente da topologia. Resultados de experimentos realizados em um protótipo da arquitetura, implementado em uma rede laboratorial, que comprovam o desempenho do protocolo de proteção também são apresentados e analisados.Apesar do foco em redes metropolitanas, a arquitetura e o protocolo não limitam a aplicação da solução a essas redes; pelo contrário, permitem a aplicação da solução também em redes locais, corporativas e até de longa distância. O restante deste artigo está organizado da seguinte forma: a Seção 1 apresenta um resumo dos mecanismos de proteção padronizados ou propostos na literatura. A Seção 2 descreve a nova proposta de arquitetura de proteção. A Seção 3 apresenta os métodos usados para o cálculo de árvores a serem utilizadas na arquitetura. A Seção 4 apresenta os aspectos de projeto e de implementação do protocolo de proteção rápida. A Seção 5 apresenta alguns resultados de desempenho obtidos em experimentos realizados em protótipo laboratorial da arquitetura. Finalmente, a última seção encerra o artigo com algumas conclusões.

1 Mecanismos de proteção em Ethernet

O mecanismo de proteção padrão do Ethernet, conforme a especificação 802.1d (IEEE, 2004) do IEEE, é o Spanning Tree Protocol (STP). O STP baseia-se na troca de mensagens especiais entre os switches, denominadas Bridge Protocol Data Units (BPDUs), para determinar a topologia

*Autor a quem a correspondência deve ser dirigida: [email protected]

Uma versão similar deste artigo foi publicada no Journal of Optical Networking, vol. 5, issue 5, p. 398-409.

O resultado contido neste artigo é fruto do trabalho envolvendo o CPqD e a Ericsson Research de Budapeste e da Hungria, na figura dos pesquisadores János Farkas e Csaba Antal.

Cad. CPqD Tecnologia, Campinas, v. 4, n. 1, p. 61-70, jan./jun. 2008

Arquitetura de rede Ethernet robusta e de baixo custo

física da rede, e no algoritmo de caminho mínimo, proposto por Radja Perlman, cuja finalidade é construir uma árvore de Spanning Tree (ST) para encaminhar os quadros Ethernet. No evento de uma falha em um dos enlaces dessa árvore, o STP constrói uma nova árvore livre de falhas. Em geral, o tempo de detecção e recuperação de uma falha é da ordem de dezenas de segundos, o que é inaceitável em redes metropolitanas, corporativas e de longa distância.Uma versão otimizada desse protocolo, denominada Rapid Spanning Tree Protocol (RSTP), foi desenvolvida e padronizada pelo IEEE na especificação 802.1w (IEEE, 2001). No entanto, ainda são necessários inaceitáveis segundos para a detecção e recuperação de uma falha.Uma nova versão dessa família de protocolos foi proposta pelo IEEE na especificação 802.1s (IEEE, 2002). Este novo protocolo, denominado Multiple Spanning Tree Protocol (MSTP), combina STs com redes locais virtuais (VLANs) (IEEE, 2005), porém não reduz os tempos obtidos pelo RSTP, já que o MSTP o tem como base.O Ethernet Automatic Protection Switching (EAPS) (SHAH, 2003) é outra proposta de proteção para Ethernet, porém não funciona com topologias arbitrárias, somente em anéis. Proteção em tempos inferiores a segundos são obtidas na arquitetura Viking (SHARMA et al., 2004), que opera com múltiplas STs assim como MSTP. No entanto, Viking requer um servidor central para o tratamento da falha, o que compromete a robustez do mecanismo e da rede, além de aumentar a complexidade desta.O protocolo Bidirectional Forwarding Detection (BFD) (AGGARWAL, 2003; CISCO SYSTEM, 2005) pode ser usado para acelerar o tempo de detecção de falhas, contudo não existe versão para Ethernet atualmente. Além disso, a exigência da instância desse protocolo para cada par de elementos de borda comunicantes limita a sua escalabilidade em função das mensagens que troca periodicamente.Mais recentemente, o IEEE começou a trabalhar na especificação 802.1ag (IEEE, 2007), que visa a definir um arcabouço de gestão de falha de conectividade denominado Connectivity Fault Management (CFM). O CFM determina ferramentas de operação, administração e gestão (OAM) e resolução de falhas em redes Ethernet, porém até o momento não definiu nenhum mecanismo que reduza os tempos obtidos por RSTP ou MSTP. Todas as propostas descritas nesta seção oferecem algum nível de proteção em redes Ethernet, porém nenhuma delas combina rapidez, escalabilidade, independência topológica e baixo custo.

2 Proposta de arquitetura

A arquitetura provê um mecanismo simples e distribuído de sobrevivência, garantindo robustez e rapidez na recuperação de falhas. Ela consiste em roteadores IP na borda e em switches Ethernet comerciais de baixo custo no núcleo – foi excluída qualquer solução que dependa de novas funcionalidades nesses switches. Assim, manteve-se a vantagem do preço dos produtos Ethernet. As funcionalidades necessárias para prover tratamento de falhas, as quais vão além das especificações-padrão das tecnologias Ethernet e IP, são implementadas por um protocolo nos roteadores de borda da rede. A Figura 1 mostra um exemplo dessa arquitetura.Nessa arquitetura, múltiplas STs são utilizadas como caminhos primários ou alternativos para o roteamento de tráfego na rede, possibilitando o tratamento de possíveis falhas. Na versão atual, as STs são calculadas e configuradas antes do início do funcionamento da rede e não podem ser alteradas durante sua operação. Uma nova versão, que permite a atualização da topologia física e conseqüentemente das Sts, foi desenvolvida e está em testes. A Seção 3 descreve como as STs são calculadas.Para conseguir a proteção de um enlace ou nó, a topologia formada pelas STs deve ser tal que, depois de uma falha em qualquer elemento da rede, reste, no mínimo, uma árvore completa e funcional. Caso uma falha venha a ocorrer, cada nó de borda deve parar de encaminhar quadros para as árvores afetadas e redirecionar o tráfego destas para as árvores intactas. Portanto, um protocolo é necessário para detecção da falha e envio de notificação para todos os nós de borda, avisando-os de que há árvores não-funcionais. O tempo de recuperação de uma falha depende principalmente do tempo despendido entre o evento de falha e sua detecção por roteadores de borda, já que a troca de uma árvore por outra é feita sem reconfiguração alguma dos switches Ethernet do núcleo. Esse protocolo é descrito em detalhes na Seção 4. Propõe-se a implementação das STs calculadas usando VLANs, isto é, associando um identificador de VLAN a cada ST. Dessa forma, o tráfego encaminhado por uma árvore pode ser controlado por meio desses identificadores nos roteadores de borda. Assim, as VLANs formam árvores sem laços, já que estas foram construídas pelo STP. O STP pode ser desabilitado após a construção das árvores e a associação entre elas e os identificadores de VLAN, já que não há possibilidade de criação de novos laços na topologia. Como conseqüência do uso de topologias baseadas em árvores de VLANs, a comutação de árvores para proteção de enlaces ou nós se torna tão simples quanto trocar a VLAN utilizada para envio de dados nessa rede.

62 Cad. CPqD Tecnologia, Campinas, v. 4, n. 1, p. 61-70, jan./jun. 2008


Assim, elimina-se a possibilidade de reconfiguração da topologia de rede em funcionamento pelo STP.Na topologia de exemplo, conforme Figura 1, três STs, isto é, três VLANs, são necessárias para lidar com qualquer falha que ocorra isoladamente.Em redes Ethernet, VPNs podem ser utilizadas também com VLANs. Como apenas um subconjunto dos nós faz parte de uma VPN, a redundância de conexões deve ser fornecida somente para os enlaces e os nós que participam das ligações da VPN. Isto é, o número de STs necessárias para uma dada VPN pode ser menor do que o necessário para a proteção da rede inteira. Entretanto, vários identificadores de VLANs e STs devem ser usados para cada VPN, como se fossem múltiplas topologias em árvore construídas para proteção de falhas na arquitetura de rede proposta.VPNs não são discutidas nas seções seguintes porque constituem uma extensão da abordagem definida aqui, que inclui todos os nós. Como resultado dessa simplificação, VLANs e STs são usadas como sinônimos, referindo-se à árvore que interconecta todos os nós de borda. Uma vez que as árvores estejam configuradas, elas podem ser usadas em dois modos: reserva primária ou balanceamento de carga. No primeiro modo, uma única ST é usada como árvore primária e todo o tráfego é enviado pela VLAN associada a ela. Se um de seus enlaces ou nós falha, então uma das árvores que restaram é utilizada para encaminhamento do tráfego. Note-se que identificadores de VLANs devem ser associados também à STs de reserva, mesmo que essas STs não sejam utilizadas, possibilitando a comutação rápida de proteção. As VLANs são listadas na mesma ordem de prioridade em todos os nós de borda, sendo que a que possuir maior ordem, denominada

primária, será selecionada para o encaminhamento de tráfego. Assim, cada nó de borda envia o tráfego do usuário na mesma VLAN tanto depois de um evento de falha quanto após o seu reparo.Já no modo de balanceamento de carga, o tráfego é distribuído igualmente por todas as árvores operacionais, sendo que, caso ocorra uma falha, o tráfego é redistribuído pelas árvores restantes.O modo de reserva primária é mais simples do que o de balanceamento de carga, já que nesse último os roteadores de borda devem distribuir as mensagens recebidas entre as VLANs. Entretanto, no modo de reserva primária, alguns enlaces não são usados e a distribuição de tráfego na rede torna-se desbalanceada. Uma vantagem do modo de balanceamento de carga é que quantidades menores de tráfego são redirecionadas depois de uma falha, sendo necessário que um número menor de novos endereços MAC seja aprendido pelas VLANs intactas. No modo de reserva primária, ao contrário, cada endereço MAC é novo na VLAN de reserva depois de uma falha, o que pode gerar uma rajada de tráfego significativo enquanto os novos endereços MAC são aprendidos.

3 Cálculo de árvores de encaminhamento

A arquitetura proposta é baseada em múltiplas topologias de STs que devem ser eficientemente elaboradas. O objetivo mais importante no seu projeto é a criação de uma arquitetura tolerante a falhas, usando uma pequena quantidade de VLANs, já que a gerência de rede é simples e há um número limitado de identificadores de VLANs (4.096).Os algoritmos de cálculo de STs disponíveis na literatura não se concentram na diminuição de número de STs. Esses algoritmos foram desenvolvidos para grafos com pesos, sendo

R4

S1 S2

S3 S4

R3

R1

R2

R4

S1 S2

S3 S4

R3

R1

R2

Switch Ethernet

Notificadorprimário

Nó de bordaRoteador Linux

EmissorVLAN 1

VLAN 2

VLAN 3Tester

Switch

Tráfego

Figura 1 Protótipo de rede Ethernet: enlaces físicos e lógicos

Cad. CPqD Tecnologia, Campinas, v. 4, n. 1, p. 61-70, jan./jun. 2008 63


estes uma representação do custo dos enlaces. Gabow desenvolveu um algoritmo de complexidade polinomial para encontrar as k-ésimas STs disjuntas na aresta (isto é, Edge-Disjoint Spanning Trees – EDSTs) com o menor peso cumulativo em um grafo direcionado (GABOW, 1995). O algoritmo descrito em Roskind & Tarjan (1985) pode ser usado para o mesmo propósito em um grafo não-direcionado. Apesar disso, EDSTs são necessárias somente se cada elemento de uma árvore puder falhar ao mesmo tempo. Neste caso, caminhos de reserva completamente independentes são necessários. Assumindo que somente uma parte da rede pode cair em um momento, as árvores necessárias podem não ser disjuntas na aresta, sendo necessário determinar requisitos um pouco mais flexíveis.Foi desenvolvido um algoritmo que determina as STs necessárias para que seja possível lidar com falhas em elementos da rede. O algoritmo, que deve ser invocado enquanto a rede estiver sendo configurada, é descrito detalhadamente em Farkas et al. (2005). Esse algoritmo constrói STs de tal forma que ainda reste uma árvore completa provendo conectividade, mesmo que haja falha em qualquer elemento da rede. Esse algoritmo é dividido em duas partes de acordo com os dois tipos de falha: a primeira parte determina quais árvores são necessárias para o tratamento de falhas de enlace; a segunda parte produz as árvores adicionais necessárias para se lidar com as falhas de nós. Se é necessário ter uma rede preparada para tratamento de falhas de enlace, então é suficiente configurar as árvores resultantes da primeira parte do algoritmo. O requisito para as STs, para que seja possível manipular falhas de enlace, é que um enlace não esteja presente em todas as árvores. Similarmente, deve haver uma árvore para cada nó, na qual esse nó é uma folha, para que se possa tratar falhas de nó. Se essas necessidades forem satisfeitas, então há pelo menos uma árvore restante que não é afetada pela falha de um nó da rede. O principal resultado do algoritmo de cálculo de árvores, comparado com as soluções existentes (GABOW, 1995; ROSKIND & TARJAN, 1985; SHARMA et al., 2004), é a resolução do problema com menos árvores do que estas últimas. Esta característica, como foi dito anteriormente, é importante já que, na arquitetura, deve-se diminuir a utilização de identificadores de VLAN e minimizar a sobrecarga da manipulação de falhas.

4 Protocolo de proteção rápidaOs objetivos mais importantes de um protocolo de proteção são recuperação rápida da falha, robustez e simplicidade. Um objetivo além do

proposto é a construção de um protocolo com mecanismos intrínsecos de sincronização, não sendo necessária nenhuma outra comunicação externa para essa tarefa.O protocolo de tratamento de falhas proposto – Failure Handling Protocol (FHP) – é um protocolo distribuído, simples e leve, implementado nos roteadores de borda. Ele depende apenas de algumas mensagens em broadcast para prover rápida proteção decorrente da falha de um enlace ou nó ocorrido na rede. O protocolo define três tipos de mensagens broadcast:• KEEP-ALIVE (KA): mensagem enviada

periodicamente por um ou mais roteadores de borda, denominados emissores, por uma VLAN em um intervalo de tempo TKA

predefinido;• FAILURE: mensagem enviada por um roteador

de borda, denominado notificador, quando uma mensagem KA não chega por uma VLAN dentro de um intervalo de detecção TDI

predefinido. Essa mensagem informa todos os outros roteadores de borda sobre uma falha naquela VLAN;

• REPAIRED: mensagem enviada pelo mesmo notificador que detectou uma falha quando uma mensagem KA foi recebida de uma VLAN com falha. Essa mensagem informa todos os outros roteadores de borda sobre o reparo dessa VLAN.

Dois tipos de notificadores são definidos, tomando por base suas configurações de intervalos de tempo: primário e secundário. Poucos notificadores são configurados como primários; todos os outros que não são emissores nem notificadores primários são denominados notificadores secundários. A razão para a diferenciação de notificadores primários e secundários é reduzir o número de mensagens de notificação concomitantes durante uma falha, como descrito abaixo. A Figura 2 mostra uma seqüência de mensagens e papéis desempenhados pelos nós.

4.1 Funcionamento

Mensagens KA são enviadas em broadcast periodicamente pelo roteador de borda emissor, por meio de cada VLAN, no início do intervalo de tempo TKA. É necessário que as mensagens KA sejam recebidas em todas as VLANs em cada um dos roteadores de borda (notificadores), dentro de um intervalo de tempo TDI. Como o atraso na comunicação é, em geral, diferente para cada notificador e os intervalos de tempo do protocolo são curtos, a sincronização dos notificadores em relação ao emissor tem grande importância. Para sincronizá-los, cada notificador inicia um temporizador assim que a primeira mensagem KA é recebida, a fim de que se identifique quando o tempo TDI foi ultrapassado. Mensagens KA posteriores têm um atraso um



pouco diferente por causa dos diferentes caminhos pelos quais são transmitidas, o que deve ser levado em conta na configuração de TDI. A chegada de todas as mensagens KA é registrada em cada nó notificador. Se há mensagens KA que não foram recebidas dentro de TDI, então as VLANs correspondentes são consideradas com falha. Entretanto, para evitar falsos alarmes decorrentes do descarte de quadros KA, os notificadores podem ser configurados para esperar dois ou três períodos de KA. Apenas depois disso eles podem considerar que uma VLAN não está operacional, caso haja falha de recepção desse tipo em cada período.Todos os nós de borda, exceto os emissores, recebem mensagens KA. Entretanto, para evitar a carga excessiva do protocolo, há apenas alguns poucos notificadores primários, cuja função é avisar sobre uma falha aos outros nós de borda. Seu intervalo de detecção é menor que o dos notificadores secundários e pode ser ajustado dependendo do tamanho da rede e de outros parâmetros. Quando um nó de borda notificador detecta uma falha, ele envia em broadcast uma mensagem FAILURE sobre cada uma das VLANs operacionais, contendo os identificadores das VLANs fora de operação. Conforme as mensagens FAILURE vão sendo recebidas, os nós passam a saber que uma VLAN está com falha.Como o número de notificadores primários é intencionalmente limitado, algumas falhas podem não ser detectadas, o que depende da topologia da rede. Assim, se um notificador secundário detectar uma falha baseada no atraso de uma mensagem KA, então esse nó envia uma mensagem FAILURE para informar todos os outros nós sobre a falha, da mesma forma como descrito acima. O procedimento de restauração depois de eliminada uma falha é muito simples. A percepção da restauração de uma VLAN com falha é uma tarefa fácil, já que o emissor continua enviando mensagens KA por meio de todas as VLANs, mesmo se uma falha foi detectada anteriormente. Se a falha é eliminada, então o notificador que percebeu essa falha é capaz de detectar seu reparo, já que volta a receber mensagens KA por intermédio daquela VLAN. Portanto, esse notificador pode avisar os outros nós, por meio do envio de uma mensagem REPAIRED contendo o identificador da VLAN restaurada. A Figura 3 mostra a operação do protocolo de tratamento de falhas em um fluxograma.

4.2 Manipulação de falhas

O protocolo descrito acima manipula falhas e sua restauração em várias topologias de STs, garantindo uma rápida recuperação. Assim, o tráfego do usuário permanece interrompido por

pouco tempo, dependendo da configuração dos intervalos de tempo do protocolo. Entretanto, o protocolo de tratamento de falhas deve ser também protegido contra as quedas dos nós de borda. Como há vários nós notificadores, seus papéis são como os explicados anteriormente: qualquer notificador que reconheça uma falha informa aos outros se essa falha já não foi reportada. Apesar de tudo, a interrupção de um nó emissor é um caso especial, que pode ser facilmente reconhecido. Se o nó emissor cai, nenhuma mensagem KA chega a qualquer VLAN partindo do emissor. Portanto, se nenhuma mensagem KA chega dentro do tempo TKA, então o nó emissor é considerado não-operacional (assumindo que ocorra apenas uma única falha por vez). Assim, o nó emissor de reserva toma o lugar do emissor. Se este volta à sua operação normal, ele receberá novamente mensagens KA em cada VLAN, sabendo, portanto, que já existe um nó emissor em operação. Dessa forma, ele executa o papel de um emissor de reserva. Ao contrário da arquitetura Viking, esse protocolo não possui uma entidade central que seja a única responsável por uma tarefa; cada nó está localizado em uma parte diferente da rede, o que provê robustez à arquitetura.Uma descrição detalhada para um evento de falha no pior caso pode ilustrar a operação do FHP. Para essa falha será levada em consideração a rede representada pela Figura 1, operando no modo de reserva primária, onde a VLAN 1 é o caminho de tráfego primário, R1 é o nó emissor e R4 é o notificador primário. Como R2 e R3 não são nem emissores nem notificadores primários, eles passam a ser notificadores secundários. VLAN 1 tem a maior prioridade e VLAN 3 possui a menor, na lista de prioridades de VLANs em cada nó de borda. R1 envia mensagens de KA para R4, passando através dos switches S1 e S4 na VLAN 3 e na VLAN 2, e as mensagens KA da VLAN 1 alcançam R4 através de S2 e S3. Se S2 cai, R4 não recebe mais mensagens KA pela VLAN 1. Portanto, ele envia uma mensagem FAILURE pela VLAN 3 e VLAN 2 dizendo que VLAN 1 não está operacional. Então cada nó deve redirecionar o tráfego para a VLAN 2 porque ela é a próxima na lista de prioridades de VLANs. Entretanto, Rr2 não recebeu nenhuma mensagem KA nem pela VLAN 2 nem pela VLAN 1. Assim, ele envia uma mensagem FAILURE pela VLAN 3 dizendo que a VLAN 2 e VLAN 1 não estão operacionais. Portanto, todo o tráfego é redirecionado pela VLAN 3 em cada nó de borda.O tempo de recuperação é um indicador importante de qualquer solução que provê resiliência. O mecanismo de tratamento de falhas proposto é rápido porque apenas depende de tempo de transmissão fim a fim das mensagens e de TKA, o qual é determinado por meio do tempo de transmissão.



Figura 2 Seqüência de mensagens no tempo

Figura 3 Operação do FHP

O tempo máximo teórico de recuperação, considerando os atrasos de processamento de pacote e transmissão da rede, é dado por:Tempo de recuperação ≤ TKA + TDI + Ttransmissão + Tprocessamento (1)A razão para isso é que a falha acontece no início de um período KA, no pior caso. Ela é detectada apenas no próximo período antes do fim do intervalo de detecção. No pior caso, um notificador secundário detecta a falha, portanto seu TDI deve ser levado em consideração. As configurações de tempo realístico permitem uma recuperação de transmissão em menos de 50

milissegundos. Isso é analisado em detalhes na Seção 5.

4.3 Seleção dos emissores e notificadores primários

Tendo as topologias em árvore necessárias, os nós emissores e notificadores primários devem ser selecionados entre os nós de borda. A configuração-padrão proposta é que cada nó de borda deve ser configurado como nós notificadores secundários. Então um deles deve ser configurado como emissor e outro como emissor de reserva. Dependendo do tamanho da


Mensagens KA

VLA

N 1

VLA

N 2

VLA

N 3

Período KA

Atraso de comunicação V

LAN

1

VLA

N 3

Notificação de falha

Intervalo dedetecção V

LAN

1

VLA

N 3

Notificação de reparo

VLA

N 2

Em

isso

r en

via

Not

ifica

dor

rece

beN

otifi

cado

r en

via

Tempo

Tempo

Tempo

Notificador verifica a chegada de mensagens Keep-Alive

Chegaram nointervalo de detecção?

Mensagem Failurerecebida?

Notificador espalhamensagem Failure

Notificador verifica a chegadade mensagens Keep-Alive

Chegaram no intervalo de detecção?

Notificador espalhamensagem Repaired

S

N

NS

N S


rede, um ou mais nós de borda são configurados como notificadores primários dentre o resto deles.Para se conseguir o menor tempo de recuperação e minimizar o número de mensagens em broadcast, são propostos os seguintes métodos para seleção de nós:• Emissor: o nó de borda que estiver mais perto

de todos os outros nós de borda em cada árvore. Dessa forma, o atraso na comunicação entre os nós emissor e notificadores é minimizado. Se uma regra simples for necessária por alguma razão, aquele mais perto de cada nó de borda na topologia física deve ser escolhido. Este critério pode ser facilmente implementado fazendo-se uma busca exaustiva.

• Emissor de reserva: o nó de borda que estiver mais perto do emissor, uma vez que ele deve fazer o papel de emissor em caso de falha deste. Esta escolha garante a menor mudança no atraso de comunicação, comparando-se com as configurações iniciais.

• Notificador primário: nós de borda cujo caminho para o emissor passa por cada enlace da árvore. Esta definição também determina o número necessário de emissores. Se os enlaces forem categorizados como “de risco” ou “sem risco”, então é suficiente a detecção da queda de enlaces com risco pelos notificadores primários; falhas em enlaces “sem risco” podem ser percebidas por notificadores secundários. Portanto, é suficiente configurar como notificadores primários o conjunto mínimo de nós de borda, cujo caminho para o emissor passe por cada enlace de risco de cada árvore. Esta configuração garante que as falhas, em sua maioria, sejam detectadas pelo notificador primário, o que diminui o tempo de recuperação.

• Notificador secundário: todos os outros nós de borda.

4.4 Configuração dos temporizadores

Os temporizadores do protocolo devem ser configurados apropriadamente, principalmente dependendo do tempo de recuperação (Tf) a ser alcançado e do atraso de comunicação da rede. Como mensagens KA em VLANs diferentes seguem caminhos diferentes, elas sofrem diferentes atrasos na comunicação, o que deve ser considerado na escolha do intervalo de detecção (TDI). Portanto, o round-trip time (RTT) deve ser medido (ou estimado) em cada VLAN entre o emissor e o notificador primário mais distante, pois eles são os nós de borda mais distantes entre si que possuem papéis importantes no protocolo. O maior RTT existente entre as VLANs é selecionado como o RTT entre o emissor e o notificador primário. O atraso na

comunicação é aproximadamente metade do RTT, o que inclui atrasos decorrentes do processamento do pacote de nós intermediários. Como conseqüência, é proposta a configuração de TDI como sendo sempre maior que RTT, para se evitar os efeitos de sua variação. O aumento do TDI resulta em uma configuração ainda mais robusta: TKA dá um limite superior e TDI não pode ser maior do que TKA para se evitar a sobreposição de períodos de KA. Assumindo TDI

de notificadores primários igual ao RTT, então TKA pode ser facilmente calculado baseado na eq(1): TKA ≈ TF – TDI – RTT / 2 = TF – 3 x RTT / 2. O limite superior de um TDI em um notificador secundário é também TKA. Entretanto, é melhor configurar um intervalo menor, para que se obtenha uma melhor recuperação quando um notificador secundário deve reagir a uma falha. Como notificadores secundários são diferenciados para evitar broadcasting storms, seus TDI devem ser configurados como sendo maiores do que os notificadores primários.

4.5 Classes de prioridades

Quadros no protocolo de tratamento de falhas devem ser configurados com a máxima prioridade em relação a todo o resto do tráfego. Deve ser garantido que os quadros de maior prioridade sejam processados por meio das filas de maior prioridade nos switches (IEEE, 2005). Dessa forma, o efeito de tráfego em rajadas, que pode eventualmente ocupar alguns enlaces por um período curto de tempo, é evitado, já que poderia gerar alarmes falsos. O RTT para pacotes de alta prioridade inclui atrasos de fila desprezíveis em cenários típicos de desenvolvimento, o que permite configurações de tempo menores no FHP e menor tempo de recuperação.

4.6 Implementação do protocolo

O protocolo FHP foi implementado em PCs com Linux atuando como roteadores de borda em uma rede laboratorial. Embora tenha sido usado o núcleo 2.6.10 do Linux, sem qualquer suporte especial a tempo real, foram alcançados baixos tempos de recuperação em testes repetitivos e extensivos. Esses resultados poderiam ser melhores se o protocolo fosse integrado em um roteador de alta performance. A implementação está descrita com detalhes em Farkas et al. (2006). Os nós do núcleo são switches comuns de camada 2 com suporte a VLAN; nenhuma característica adicional é necessária para suportar o FHP ou para executar a comutação de proteção. Combinações de switches de dois fabricantes diferentes foram testadas: D-Link e Extreme Network.



Em nossa rede de testes, conforme Figura 1, um emissor, um notificador primário e dois notificadores secundários foram configurados; o tráfego foi mapeado para as VLANs no modo de balanceamento de carga e o FHP foi prototipado usando quadros Ethernet de 514 bytes, espaço suficiente para acomodar todas as mensagens de protocolo necessárias e os parâmetros adicionais.

5 Resultados de desempenho

A avaliação de desempenho foi feita seguindo a implementação descrita na Seção 4.6, com o objetivo principal de demonstrar rápida recuperação sob a alta estabilidade do protocolo. Um PC transmite e recebe o tráfego de teste, enquanto controla o switch óptico no meio do enlace entre S1 e S2 para gerar as falhas.A Tabela 1 mostra os tempos de recuperação coletados em mais de 1.000 eventos de proteção para várias configurações de um nó emissor/notificador primário na topologia de rede mostrada na Figura 1. O período de transmissão dos KAs utilizados foi fixado em 15 ms; o intervalo de detecção TDI foi de 5 ms no notificador primário e de 10 ms nos notificadores secundários. O tráfego de teste entra na rede por meio do roteador R1 e deixa a rede por meio do roteador R3, conforme Figura 1.Os resultados são consistentes com predições teóricas, uma vez que o tempo mínimo de recuperação (melhor caso) é limitado por TDI. O tempo médio é igual a 0,5 x TKA + TDI, e o tempo máximo (pior caso) é limitado por TKA + TDI. Um intervalo de tempo deve ser adicionado em todos os casos para que sejam considerados os atrasos da rede, processamento local dos pacotes, notificações em broadcast, etc.Esses resultados mostram que o terceiro cenário tem o menor tempo de recuperação. Isso se deve ao fato de que o notificador primário, cujo TDI é o menor, é capaz de detectar a falha e iniciar o processo de notificação. No primeiro, segundo e quarto cenários, um dos notificadores secundários, configurados com TDI maior, pode somente detectar a falha da rede e iniciar o processo de tratamento desta.A Figura 4 mostra os resultados medidos em mais de 1.000 comutações de proteção, com o

período de envio de KAs aumentado de 6 ms para 50 ms, o tempo TDI do notificador primário configurado para TKA/3, dos notificadores secundários para 2/3 TKA, R2 como nó emissor, R4 como notificador primário e R1 e R3 como notificadores secundários. Nessa configuração, uma falha é sempre detectada por um notificador secundário (especificamente R3). Pode ser observado que essa medida de tempo de recuperação, no pior caso, é consistente com o esperado da equação 1, que mostra que a diferença entre eles se deve à transmissão de dados na rede, e, principalmente, a atrasos decorrentes do processamento de pacotes (por volta de 5 ms, independente de TKA). O uso de máquinas mais poderosas nas bordas da rede deve fazer com que essa diferença de tempos seja diminuída.Os resultados indicam que o desempenho de recuperação pode ser mantido abaixo dos 50 ms, mantendo-se o período de KA abaixo dos 25 ms. Mesmo em roteadores de baixo desempenho, como os PCs com Linux usados na rede de testes (cujos processadores eram Pentium II e Pentium III), pode-se executar o protocolo de tratamento de falhas operando com intervalos de transmissão de KAs em 6 ms. Nesse caso, o tempo máximo de recuperação é de 15 ms.A sobrecarga de tráfego gerada pelo protocolo é um parâmetro relevante e varia em função do período de transmissão de mensagens KA, sendo calculado como:LFHP = 514 x 8 x NVLAN / TKA (2),no qual 514 é o tamanho de um quadro Ethernet com rótulo usado em nossa implementação. NVLAN é o número de VLANs na rede e a unidade de medida de LFHP é em kbit/s.A Figura 5 mostra a carga do protocolo normalizada para Ethernet a 1 Gbit/s como função de TKA, com NVLAN como parâmetro. Como as curvas mostram, a sobrecarga do protocolo pode ser mantida baixa (menos do que 1% da capacidade do enlace), mesmo em redes de tamanho médio (com várias dezenas de nós de borda), onde um número de VLANs entre 10 e 20 seria suficiente (SHARMA et al., 2004). Além disso, a recuperação pode ser alcançada dentro de 20 ms, configurando o período de KA em 10 ms.

Tabela 1 Tempo de recuperação do FHP

Tempo de

recuperação [ms]

Cenários

Emissor: R1Primário: R2




Média 19.62 21.83 15.38 20.47

Máximo 29 29 24 28

Mínimo 12 11 7 12

Desvio-padrão 4.69 5.15 4.87 4.31



0

10

20

3040

50

60

70

80

90100

6 10 15 20 25 30 35 40 45 50KA period [ms]

Failo

ver t

ime

[ms]

]

A verageMaximumMinimum

Figura 4 Tempo de recuperação

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25KA period [ms]

Norm

aliz

ed F

HP lo

ad [%

]

5 VLANs

10 VLANs

15 VLANs

20 VLANs

Figura 5 Carga do protocolo

Com respeito aos testes de falha de nós, os resultados estavam de acordo com a Tabela 1, e o tempo de recuperação ficou entre o valor mínimo e máximo em todos os casos.Além da topologia mostrada na Figura 1, também foram repetidos os testes de falha de enlace em uma topologia em grade de 12 nós, nos quais os resultados estiveram de acordo com a Tabela 1.Uma funcionalidade adicional do FHP que foi experimentalmente verificada é que nenhum pacote é perdido nos roteadores de borda durante a fase de restauração, seja de reparos de enlace ou nó. Isso acontece pois todos os roteadores de borda são notificados, depois da restauração da rede, por meio de mensagens REPAIRED enviadas em broadcast. Conseqüentemente, pacotes de entrada em cada roteador de borda são encaminhados pela VLAN original (isto é, aquela usada antes da comutação de proteção), sem qualquer necessidade de sincronização entre roteadores de borda.Resumindo o exposto acima, o tempo de

recuperação pode ser reduzido para dezenas de milissegundos em nossa aproximação. Portanto, é mais rápido do que a aproximação Viking (SHARMA et al., 2004), cujo tempo de recuperação é algo menor do que um segundo.

Conclusão

Foi apresentada e validada experimentalmente uma solução de proteção leve e eficiente para uma arquitetura Ethernet robusta e de baixo custo por meio de redes de fibra, construída sobre switches Ethernet comerciais. A solução de alta disponibilidade foi implementada em uma rede de protótipo. Resultados experimentais mostraram que o tempo de recuperação do pior caso de falha pôde ser mantido abaixo dos 50 milissegundos com 0,5% de sobrecarga do protocolo na capacidade do enlace em uma rede gigabit Ethernet. Uma vantagem dessa arquitetura é que nenhum pacote é perdido durante a recuperação



da falha.Trabalhos futuros incluem o desenvolvimento de métodos de engenharia de tráfego para otimizar a utilização das STs, estendendo o protótipo com um sistema de gerenciamento de redes para se obter uma rede plug-and-play.

Referências

AGGARWAL, R. Application of Bidirectional Forwarding Detection. Juniper Networks, 2003. Disponível em: <http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-eof-bfd.pdf>. Acesso em: 27 nov. 2007.

CISCO SYSTEM. Bidirectional Forwarding Detection for OSPF. 2005. Disponível em: <http://www.cisco.com/application/pdf/en/us/guest/tech/tk480/c1550/cdccont_0900aecd80244005.pdf>. Acesso em: 27 nov. 2007.

FARKAS, J. et al. Distributed resilient architecture for Ethernet networks. In: Proceedings of 5th

International Workshop on Design of Reliable Communication Networks (DRCN 2005), Budapeste, Hungria: 2005. p. 515-522.

FARKAS, J. et al. Fast failure handling in Ethernet networks. In: Proceedings of the IEEE International Conference on Communications. Istambul, Turquia: 2006. p. 11-15.

GABOW, H. N. A matroid approach to finding edge connectivity and packing arborescences. Computer & System Sciences, v. 50, abr./1995. p. 259-273.

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE). 802.1w: Standard for local and metropolitan area networks – Rapid reconfiguration of spanning tree, 2001. Disponível em: <http://www.ieee802.org/1/pages/802.1w.html>. Acesso em: 27 nov. 2007.

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE). 802.1s:

Standard for local and metropolitan area networks – Multiple spanning trees, 2002. Disponível em: <http://www.ieee802.org/1/pages/802.1s.html>. Acesso em: 27 nov. 2007.

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE). 802.1d: Standard for local and metropolitan area networks – Media Access Control (MAC) bridges, 2004. Disponível em: <http://www.ieee802.org/1/pages/802.1D.html>. Acesso em: 27 nov. 2007.

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE). 802.1q: Standard for local and metropolitan area networks – Virtual bridged local area networks, 2005. Disponível em: <http://www.ieee802.org/1/pages/802.1Q.html>. Acesso em: 27 nov. 2007.

INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS (IEEE). 802.1ag: Connectivity Fault Management, dez/2007. Disponível em: <http://www.ieee802.org/1/pages/802.1ag.html>. Acesso em: 27 nov. 2007.

ROSKIND, J.; TARJAN, E. A note on finding minimum-cost edge-disjoint spanning trees. Mathematics of Operations Research, v. 10, n. 4, 1985. p. 701-708.

SHAH, E. Ethernet automatic protection switching. IETF RFC 3619, out/2003. Disponível em: <http://www.apps.ietf.org/rfc/rfc3619.html>. Acesso em: 27 nov. 2007.

SHARMA, S. et al. Viking: A multi-spanning-tree Ethernet architecture for metropolitan area and cluster networks. In: Proceedings of 23rd Conference of the IEEE Communications Society (INFOCOM 2004), Nova York, v. 4, mar/2004. p. 2.283-2.294. Disponível em: <http://www.ieee- nfocom.org/2004/Papers/47_3.PDF>. Acesso em: 27 nov. 2007.

Abstract

In this paper we propose and demonstrate a low-cost robust Ethernet over fiber network architecture thatcan recover from both node and link failures in less than 50 milliseconds and, thus, ensure that packetloss is avoided during fault restoration. The architecture was implemented and tested in a prototypenetwork. The proposed scalable architecture works with commodity off-the-shelf Ethernet switches andhandles network failures in arbitrary Ethernet level topologies by the edge-nodes of the network. Theexperimental results of the protection protocol implementation are presented, showing that the 50milliseconds carrier-grade recovery time is achieved.

Key words: Protection. Ethernet. PBB. PBT. Traffic engineering.


http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-eof-bfd.pdf


http://www.apps.ietf.org/rfc/rfc3619.html



http://www.ieee802.org/1/pages/802.1ag.html



http://www.ieee802.org/1/pages/802.1Q.html



http://www.ieee802.org/1/pages/802.1D.html



http://www.ieee802.org/1/pages/802.1s.html



http://www.ieee802.org/1/pages/802.1w.html



http://www.cisco.com/application/pdf/en/us/guest/tech/tk480/c1550/cdccont_0900aecd80244005.pdf













Documents

Arquitetura de rede ethernet robusta e de baixo custo