Fault Recovery Performance in Multicast Networks for Smart Grid M. F. Minicz and A. Anzaloni Abstract— Electrical systems and Smart Grid are using the International Electrotechnical Commission (IEC) 61850 standard for the exchange of messages. In particular Sample Value and Generic Object Oriented System Event messages, which are transmitted in multicast and directly on the layer 2, has very strict performance requirements. The IEC 61850 suggested the use of Rapid Spanning Tree Protocol as the protocol for recovery, after a failure. This paper presents a comparison between Rapid Spanning Tree Protocol and OpenFlow with Fast Failover recovery performance in order to verify if the recovery delay requested is met. The latency of a typical topology is analyzed, before and after a failure, and compared with IEC 61850 definition. Keywords— Smart Grid, IEC 61850, Multicast, Rapid Spanning Tree Protocol, Fast Failover, OpenFlow

I. INTRODUÇÃO

A

S REDES elétricas inicialmente não tinham quase nenhuma automação. Com o passar dos anos vários recursos de automação foram implementados de forma a prover disponibilidade e segurança a toda rede elétrica. Nas últimas décadas muito esforço tem sido feito para padronizar como toda essa automação deve ocorrer, levando ao surgimento do conjunto de normas IEC 61850 [1]. O escopo original foi padronizar o funcionamento e a comunicação dentro de uma subestação elétrica, mas depois foi ampliado também para o funcionamento e comunicação entre subestações elétricas, podendo, inclusive, ser aplicado em Smart Grid. Esse conjunto de normas define como toda a comunicação entre os dispositivos elétricos inteligentes (IED – Intelligent Electronic Device) deve ocorrer, desde o formato das mensagens, seus objetivos e as características da infraestrutura necessária. Para a infraestrutura básica de comunicação foram adotados os padrões de redes de computadores existentes, sugerindo quais tecnologias devem ser utilizadas em que situações. Também são definidos quais requisitos de comunicação devem ser atendidos, de forma a nortear os projetos. Em particular, [2] trata do projeto de redes locais (LAN – Local Area Network), isto é, dentro de uma subestação elétrica, e [3] de projeto de redes de longa distância (WAN – Wide Area Network), isto é, entre subestações elétricas. Três parâmetros devem ser avaliados em todo projeto de M. F. Minicz, Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, [email protected] A. Anzaloni, Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, [email protected] Corresponding Author: M. F. Minicz

rede para suportar o IEC 61850 [3]: (i) latência, (ii) indisponibilidade e (iii) atraso de recuperação. Vários tipos de tráfegos estão previstos, tanto na comunicação dentro de uma subestação, bem como entre as subestações. Desses tráfegos, dois chamam a atenção pela sua criticidade[1]: as informações de medições (mensagens SV – Sample Value) e as informações de estado dos sinais e de trip (mensagens GOOSE – Generic Object Oriented System Event). Esses tráfegos têm a característica comum de serem enviados em Multicast, tolerando baixíssima latência e pequeno atraso de recuperação. Este artigo utiliza a emulação para construir dois cenários de infraestrutura de comunicação entre subestações, nos quais é avaliado o atraso de recuperação, após uma falha de enlace ou equipamento de rede, além da latência antes e depois. Como mecanismo de recuperação de falha é utilizado o Rapid Spanning Tree Protocol (RSTP) [8], principal solução aplicada nos projetos de rede para Smart Grid [2] e [3], e o Fast Failover do OpenFlow [10]. A composição deste artigo apresenta-se da seguinte forma: na seção 2 é feita uma pequena introdução ao IEC 61850 e os seus parâmetros de desempenho; uma breve discussão do funcionamento e mecanismos de recuperação de falha do RSTP e das redes definidas por software (SDN – Software Defined Network) com OpenFlow estão nas seções 3 e 4, respectivamente; já a seção 5 descreve os cenários construídos e a seção 6 traz os resultados, fechando com as conclusões na seção 7. II. IEC 61850 É um conjunto de padrões que definem como deve ocorrer a comunicação, por meio de redes, para a automação de sistemas de energia. Além das normas e especificações definirem como cada parâmetro elétrico deve ser codificado e transportado pela rede, também são definidos os formatos das mensagens e o comportamento dos IEDs. Também fazem parte desse conjunto alguns relatórios técnicos com as considerações para projeto das redes. A situação mais crítica ocorre no transporte de informações de medições e no envio de informação do estado dos sinais e de trip de sistema. As informações de medições são medidas de tensão, corrente ou fase, para sistemas, monofásico ou multifásico, e, devido à grande quantidade de amostras necessárias, o volume de mensagens é muito grande. Já as informações de estado dos sinais e de trip de sistema são importantes porque podem isolar falhas elétricas, evitando a propagação dessas ou a sobrecarga de sistemas. As informações de medições são transportadas em mensagens SV e as informações de estado dos sinais e de trip em mensagens GOOSE. Um IED que gera a mensagem é chamado de Produtor e um IED que recebe a mensagem é

chamado de Consumidor. Essas duas mensagens são transmitidas diretamente dentro de um quadro Ethernet, que é enviado para um endereço de Multicast. A opção de colocar o SV/GOOSE diretamente no Ethernet é para reduzir a carga na rede e permitir que ela seja configurada de forma a atender aos requisitos de comunicações, sem a sobrecarga dos protocolos de camada 3 ou 4. Já o Multicast é porque, tipicamente, uma mesma mensagem é de interesse de vários IEDs Consumidores; dessa forma não é necessário enviar uma cópia da mensagem para cada receptor, evitando sobrecarregar o processador do IED Produtor que tem um poder de processamento pequeno.

identificando-se e dizendo o custo dos enlaces. Essas mensagens são trocas em um quadro especial chamado Bridge Protocol Data Unit (BPDU). (ii) É eleito um switch como Raiz, tornando-se o centro da rede. (iii) Os demais switches calculam a direção e o custo do caminho mais curto até a Raiz, usando as mensagens recebidas dos switches mais próximos da Raiz. Cada switch terá somente um melhor caminho para enviar pacotes até a Raiz. (iv) Se dois switches estão servindo a mesma LAN, o de menor custo até a Raiz servirá a LAN. O outro switch descartará todos os quadros recebidos pela LAN, abrindo o enlace e bloqueando laços de tráfego.

A. Parâmetros de Desempenho O padrão [3] define três requisitos para as redes: (i) latência – tempo entre a transmissão e a recepção de uma mensagem. (ii) indisponibilidade – tempo que o sistema não está disponível durante certo intervalo, tipicamente anual. (iii) atraso de recuperação – tempo para recuperação da rede após uma falha.

A diferença entre as versões está nos valores dos temporizadores e como o algoritmo reage (passivamente ou ativamente) quando ocorre uma falha de enlace. B. Recuperação de Falha

Os valores desses três requisitos variam conforme o tipo de informação que está sendo transmitida. Para o SV/GOOSE, entre subestações, tem-se a latência máxima de 10 ms, mas essa latência é dividida em três partes: (i) a latência de processamento no IED Produtor, (ii) a latência de rede e (iii) a latência de processamento no IED Consumidor. A norma [3] sugere 40% para a primeira parte, 20% para a segunda parte e 40% para a terceira parte, com isso a latência de rede deve ter como limite superior 2 ou 3 ms. Já a indisponibilidade do sistema deve ficar entre 10-5 e 10-4 e o atraso de recuperação máximo aceito é de 50 ms.

Podem ocorrer falhas de um switch ou nos enlaces entre switches. Do ponto de vista do switch vizinho não existe diferença entre essas duas falhas, pois a detecção ocorrerá no nível de camada física, por uma indicação de hardware, que pode levar de poucas dezenas até centenas de milissegundos [6]. Somente depois dessa indicação de hardware é que o processo de RSTP entrará em ação. Como o protocolo foi construído para funcionar de forma distribuída, a observação dos temporizadores e da máquina de estado deve ser muito rigorosa, para, então, ocorrer a escolha de um novo caminho. A recuperação de falha do RSTP é reativa, isto é, quando ocorre uma falha ele entrará em ação para procurar um novo caminho e, se houver, usá-lo.

III. RAPID SPANNING TREE PROTOCOL

IV. SDN E OpenFlow

A primeira versão, chamada Spanning Tree Protocol (STP), foi publicada no padrão IEEE 802.1D-1990 [7]. Originalmente o protocolo não foi construído com o objetivo de ter um tempo de convergência pequeno, sendo de no mínimo 30 segundos. Após isso, foi feita uma extensão no padrão, a IEEE 802.1w, também conhecido como Rapid STP (RSTP). A principal diferença entre o STP de 1990 e o RSTP é que enquanto o STP aguarda, passivamente, os temporizadores expirarem toda vez que ocorre uma alteração de topologia, o RSTP age imediatamente. Com isso o tempo de recuperação da rede passou para poucos segundos. O padrão IEEE 802.1D-2004 [8] tornou obsoleto o RSTP (IEEE 802.1w), melhorando o tempo de convergência para menos de um segundo, sendo que conforme a topologia, a convergência pode ocorrer em algumas dezenas de milissegundos.

Tradicionalmente os equipamentos de rede executam duas funções: (i) o encaminhamento dos dados e (ii) o controle de qual caminho deve ser utilizado. Cada função caracteriza um plano. Vários esforços têm sido feitos de forma a otimizar os recursos existentes e permitir redes de maior desempenho e mais simples. Dentro desses esforços foi criado o conceito SDN. Nele o switch se preocupa em encaminhar os dados e toda a parte de controle é movida para um ponto central – a Controladora SDN – que tem o papel de gerenciar e administrar toda a rede. A comunicação entre a controladora SDN e os switches é feito via protocolo OpenFlow. Em [9] os autores definem SDN como uma rede que é caracterizada por cinco traços fundamentais: (i) separação dos planos de dados e controle; (ii) dispositivos simplificados; (iii) controle centralizado; (iv) automação da rede e virtualização; (v) aberto (no sentido de que as especificações dos protocolos são conhecidas e podem ser implementados por qualquer um, sem custo de royalties).

A. Funcionamento O funcionamento básico é igual para qualquer uma das versões: (i) Todos os switches enviam mensagens para os outros,

Vários autores já discutiram o uso de SDN [11][12][13], demonstrando que essa é uma tecnologia que ajudará no desenvolvimento dos Smart Grids. Uma rede SDN não tem restrição quanto ao tipo de tráfego (Unicast ou Multicast), podendo ser aplicada tanto para LAN, bem como para a WAN. Também, devido à centralização das informações, permite a otimização dos caminhos escolhidos, por meio do uso de engenharia de tráfego e qualidade de serviço (QoS – Quality of Service) [12][13]. A. RSTP com OpenFlow O RSTP pode ser implementado de duas formas diferentes em uma controladora SDN: considerando ou não a existência de switches tradicionais. Para o primeiro caso, considerando a existência de switches tradicionais, como não, necessariamente, pode-se saber onde esses equipamentos estão conectados, deve ser feita uma implementação completa do protocolo RSTP na Controladora, respeitando-se todo o seu funcionamento. Com isso é necessário que a Controladora saiba receber e enviar os BPDUs, que carregam as informações trocadas entre os switches, e, depois de executar uma instância do algoritmo de STP para cada switch OpenFlow, é necessário enviar as devidas mensagens OpenFlow para configurá-los. No segundo caso, sem a existência de switches tradicionais, poderão ser feitas otimizações, pois, uma vez que a Controladora conheça toda a topologia de rede, poderá calcular e configurar os switches OpenFlow imediatamente. Um problema importante a ser considerado é que serão adicionados atrasos de propagação em todas as mensagens BPDU, pois o switch OpenFlow depende da Controladora, portanto o BPDU deverá ser enviado para a controladora, onde é feito o cálculo e gerado novas mensagens BPDU que deverão ser enviadas para o switch OpenFlow, para então enviar para o seu vizinho. Também é a controladora que preparará as novas regras para que o switch OpenFlow faça ou não o encaminhamento dos tráfegos. Independente da forma de implementação, o RSTP no OpenFlow também é reativo, isto é, somente procurará um caminho alternativo quando ocorrer uma falha (de enlace ou de switch).

C. Recuperação de Falha A recuperação de falha no SDN depende de como foi escolhida a configuração do sistema. Se for utilizada o RSTP com OpenFlow, a recuperação será reativa, isto é, dependerá que um switch OpenFlow detecte e reporte a falha de um enlace para a Controladora, que então calculará um novo caminho e reconfigurará a rede. Toda essa operação tem um alto custo, aumentando o atraso de recuperação do sistema. Já no caso da utilização do Fast Failover, tão logo o switch OpenFlow detecte a falha de um enlace, ele passará a encaminhar os pacotes pela próxima interface ativa, então avisará a Controladora. Com isso a recuperação do sistema é praticamente instantânea. V. CENÁRIOS Para a construção dos cenários de testes, várias topologias poderiam ser escolhidas, considerando-se que a rede interna a uma subestação pode ter uma topologia diferente da rede entre subestações. Em [2] são mostradas várias topologias que podem ser utilizadas para a rede interna a uma subestação, mas sempre devem ser considerados o custo e a facilidade de montagem e manutenção. Algumas topologias implicam em soluções proprietárias ou de alto custo, por isso, a principal topologia para uma subestação é em anel simples. Normalmente cada baia de equipamentos elétricas, ou conjunto de baias subjacentes, teria um switch, sendo que os switches da subestação estariam ligados em anel (Fig. 1).

Figura 1. Barramento de estação em anel com switches RSTP ([2] Fig. 27).

B. Fast Failover O Fast Failover é um recurso que foi adicionado ao OpenFlow na versão 1.1 [10]. Por meio dele é possível determinar um grupo de portas a ser utilizadas, e a primeira ativa será utilizada para o envio dos pacotes. A Controladora deve calcular o caminho principal, os pontos em que o Fast Failover atuará, calcular os caminhos de backup, para então fazer as configurações dos switches OpenFlow. A partir daí os switches OpenFlow podem encaminhar os pacotes com os tráfegos e, caso ocorra uma falha de enlace ou de um equipamento, o switch OpenFlow que perceber já saberá por qual caminho de backup deverá enviar os pacotes. Como o Fast Failover já é pré-configurado no switch OpenFlow, ele é pró-ativo, isto é, não depende de ações externas para prover uma alternativa de caminho.

Em [3] são mostradas várias topologias que podem ser utilizadas para a rede entre as subestações. Novamente, a principal topologia é em anel. Na Fig. 2 pode-se ver um exemplo de uma rede. Essa é uma visão parcial da rede da distribuidora de energia de Andalusia, no sul da Espanha, sendo é uma rede com mais de 100 km de diâmetro e mais de 30 subestações. A escolha de topologia em anel é de certa forma natural, pois dentro de um custo aceitável é possível prover redundância de caminho, sem a necessidade de aumentar a quantidade de equipamentos. Para os testes foram montados dois cenários de forma a emular uma rede com quatro ou nove subestações.

[18] e tem como importante característica ser executado no espaço de usuário do sistema operacional. Como é um processo no espaço de usuário, é necessário que um pacote seja reescrito várias vezes em memória, conforme atravessa uma rede emulada, com isso se a topologia for grande, poderá ocorrer problema de degradação de desempenho, conforme a capacidade de processamento do computador. Por outro lado, a quantidade de switches não interfere no desempenho do Fast Failover. Para emular os cenários com RSTP foi utilizado o Open vSwitch e o Mininet. Para os cenários com OpenFlow e Fast Failover foram utilizados o Open vSwitch, o ofsoftswitch13 e o Mininet, sendo que o ofsoftswitch13 foi utilizado no switch em que o Fast Failover foi configurado, já os demais switches utilizaram o Open vSwitch. B. Configuração Básica dos Cenários

Figura 2. Topologia da rede de Andalusia ([3] Fig. 3).

A. Ambiente de Emulação Para simular os IEDs foram utilizados dois programas. O primeiro emula um IED Produtor, que gera mensagens SV/GOOSE dummy de 160 bytes, em intervalo de tempo configurável. Não são enviados dados reais, mas em vez disso toda mensagem carrega um número de sequência e um carimbo de tempo, indicando quando ele foi transmitido. O segundo programa emula um IED Consumidor, que recebe as mensagens SV/GOOSE dummy geradas pelo primeiro programa e registra o número de sequência, o carimbo de transmissão e um carimbo de recepção, de forma a permitir uma análise posterior. Para construir a rede emulada foi utilizado o Mininet [4], sendo que em [16] e [17] é mostrado que ele oferece grande fidelidade, ao ser comparado com medidas reais, quanto à capacidade de reprodução de experimentos, tornando-se uma valiosa ferramenta para pesquisa e educação. Para a construção de uma topologia é necessário um software switch. Existem várias opções disponíveis, mas as duas principais são o Open vSwitch [5] e o ofsoftswitch13 [14]. O Open vSwitch é largamente utilizado, tanto em pesquisa como em ambientes de produção, oferecendo vários recursos avançados, incluindo o RSTP e OpenFlow, tendo como uma importante característica ser executado no espaço de kernel do sistema operacional, trabalhando em um único processo. Ele oferece um bom desempenho, pois evita que o mesmo pacote seja reescrito várias vezes na memória, enquanto ele atravessa a rede emulada. Por outro lado, quando a quantidade de switches aumenta, o tempo de resposta para certas funções aumenta, pois, todos os switches compartilham o mesmo processo. O ofsoftswitch13 é uma atualização de uma das primeiras opções de software switch para suportar o OpenFlow 1.3. Esse software switch foi originalmente desenvolvido pela Ericsson

No IEC 61850, o menor intervalo entre mensagens é quando ocorre um trip de uma parte do sistema elétrico. Nesse momento são enviadas mensagens GOOSE com um intervalo de transmissão de no mínimo 1 ms, em rajada, depois retornando, gradativamente, para o intervalo de funcionamento normal. Para as emulações o tempo entre mensagens foi configurado para 0,5 ms. Para cada emulação foi configurado um IED Produtor em uma única subestação e um IED Consumidor por subestação. Após a construção da topologia sempre é dado um intervalo de tempo para garantir a estabilidade da rede (por exemplo, garantir que ocorreu a convergência do RSTP). Em seguida, são ativados os IED Consumidores e por último o IED Produtor. Na sequência, após 5 segundos, uma falha é provocada, pelo rompimento de um enlace. O enlace a ser rompido é sempre o que provoca o maior tempo de convergência no RSTP, isto é, junto ao switch Raiz, pois esse é o caso mais crítico. C. Cenário – 4 Subestações Neste cenário temos quatro subestações, cada uma composta por 5 switches, interligados em anel. Essas quatro subestações estão interligadas por outro anel, conforme Fig. 3. Por exemplo, os switches S11, S12 e S13, em termos de subestação elétrica, seriam equivalentes a três baias de equipamentos elétricos, que podem ter vários IEDs (tanto Produtores como Consumidores). Já os switches S01 e S02 fazem parte do anel entre as subestações. Os enlaces entre os IEDs e os switches são de 100 Mb/s, com atraso de propagação de 0,001 ms. Os enlaces entre os switches dentro de uma subestação são de 1 000 Mb/s, com atraso de propagação de 0,001 ms. Já os enlaces entre subestações são de 1 000 Mb/s, com atraso de propagação de 0,375 ms. O tempo de comutação dos switches é de aproximadamente 0,03 ms. O enlace rompido foi entre o S01 e o S08, pois para o RSTP, o switch S01 foi configurado como Raiz.

O atraso de recuperação é medido em função da quantidade de mensagens perdidas, após o rompimento do enlace. Já a latência é a média entre o instante de transmissão e o instante de recepção das mensagens, antes e depois do rompimento do enlace. Como todo o ambiente é emulado em um único computador, foram feitas 100 emulações para cada um dos cenários, para cada um dos protocolos. Com relação à quantidade de mensagens perdidas, foram calculados os valores: (i) mínimo; (ii) máximo; (iii) intervalo – a diferença entre o máximo e o mínimo; (iv) média; (v) desvio padrão;

Figura 3. Topologia – Anel com 4 subestações.

D. Cenário – 9 Subestações Este cenário é semelhante ao Cenário anterior, mas agora temos nove subestações, conforme Fig. 4. As diferenças que temos é que para o RSTP é configurado o S001 como switch Raiz e que o enlace rompido é entre os switches S001 e S018.

As Tabelas I e II mostram a quantidade de mensagens perdidas. A Fig. 5 mostra o gráfico de violino para o RSTP e a Fig. 6 para o OpenFlow. Optou-se em usar gráficos de violino, porque, além de mostrar o mínimo, o máximo e a média para cada um dos cenários, também mostra a distribuição das medidas no intervalo, o que seria o equivalente a fazer um histograma para cada cenário, mas de uma forma mais compacta. A análise das Tabelas I e II mostra que o OpenFlow é uma solução mais estável, isto é, menores intervalo e desvio padrão. Também mostra que a quantidade de mensagens perdidas é, significativamente, menor, isto é, tem um menor atraso de recuperação. Esse resultado era esperado, pois como o caminho alternativo foi configurado de forma proativa o tempo de reestabelecimento do rompimento é mínimo, isto é, somente o tempo necessário para o switch observar que houve o rompimento. Já o RSTP precisa trocar mensagens antes de desbloquear as portas que permitiriam o novo caminho. TABELA I QUANTIDADE DE MENSAGENS PERDIDAS DO CENÁRIO – 4 SUBESTAÇÕES PARÂMETRO

RSTP

OPENFLOW

MÍNIMO

22

0

MÁXIMO

4 843

15

INTERVALO

4 821

15

MÉDIA

812,12

2,88

DESVIO PADRÃO

850,20

2,44

TABELA II QUANTIDADE DE MENSAGENS PERDIDAS DO CENÁRIO – 9 SUBESTAÇÕES PARÂMETRO Figura 4. Topologia – Anel com 9 subestações.

VI. RESULTADOS Dois parâmetros de desempenho foram considerados: o atraso de recuperação e a latência.

RSTP

OPENFLOW

MÍNIMO

191

0

MÁXIMO

15 657

23

INTERVALO

15 466

23

MÉDIA

7 177,92

3,56

DESVIO PADRÃO

2 953,91

4,15

Como é enviada uma mensagem a cada 0,5 ms, pode-se considerar que o atraso de recuperação para o RSTP está entre 11 e 2 421 ms para quatro Subestações e entre 95 e 7 828 ms para nove Subestações, o que é bem acima dos 50 ms aceitos em norma. Já o OpenFlow levou 11 ms no pior caso para a recuperação, bem abaixo do limite da norma.

necessário a inclusão de um novo enlace, por exemplo, entre S001 e S011. TABELA IV LATÊNCIA MÉDIA DAS MENSAGENS ANTES E DEPOIS DA FALHA PARA O CENÁRIO – 9 SUBESTAÇÕES PROTOCOLO

RSTP

OPENFLOW

IED RECEPTOR

ANTES [ms]

DEPOIS [ms]

H61

1,74

2,10

H71

1,32

2,49

H81

0,90

2,89

H91

0,50

3,30

H61

1,78

2,17

H71

1,39

2,56

H81

1,00

2,95

H91

0,62

3,33

VII. CONCLUSÃO Figura 5. Quantidade de falhas para o RSTP.

As Tabelas III e IV mostram a latência média antes e depois da falha. Os valores sempre aumentaram, o que era esperado, pois o novo caminho é mais longo que o original.

Figura 6. Quantidade de falhas para o Fast Failover. TABELA III LATÊNCIA MÉDIA DAS MENSAGENS ANTES E DEPOIS DA FALHA PARA O CENÁRIO – 4 SUBESTAÇÕES PROTOCOLO RSTP

OPENFLOW

IED RECEPTOR

ANTES [ms]

DEPOIS [ms]

H31

0,91

0,96

H41

0,52

1,33

H31

1,02

1,04

H41

0,63

1,42

Para o Cenário com quatro Subestações, a latência, antes e depois da falha, está dentro do limite aceitável, isto é, menos de 3 ms. Já para o Cenário com nove Subestações, as mensagens recebidas pelo IED Consumidor H91, após a falha, ultrapassam o limite aceitável. Isso demonstra que é

Os novos sistemas elétricos e Smart Grids baseados no padrão IEC 61850 tem requisitos bem específicos para as infraestruturas de rede que precisam ser construídas para dar suporte às trocas de mensagens. Em particular, as mensagens SV e GOOSE, que utilizam Multicast, tem o atraso de recuperação máximo de 50 ms e a latência máxima de 3 ms, quando utilizados na comunicação entre subestações. Essa norma considera várias possíveis tecnologias de rede para a construção das topologias de rede. O RSTP é indicado. Este trabalho mostra que os cenários construídos com RSTP podem atender ao requisito de latência, mas não ao requisito de atraso de recuperação. Quando de uma falha, o RSTP poderá precisar trocar muitas mensagens para a construção da nova Spanning Tree, e como a topologia aplicada é um anel entre as subestações, e internamente às subestações também são anéis, isso fará com que o tempo de convergência seja acima do atraso de recuperação aceitável pela norma. Também mostra que a utilização do OpenFlow com o Fast Failover atende aos requisitos de atraso de recuperação para a comunicação entre subestação, permitindo, inclusive, a utilização dentro de subestações, onde o requisito é de 10 ms [2]. Outro ponto importante é que o RSTP não permite que seja construída a melhor árvore de Multicast para cada comunicação entre um IED Produtor aos IEDs Consumidores, pois se forem construídas uma árvore para cada comunicação os switches podem não ter capacidade de processamento. Isso ocorre porque, facilmente, uma instalação média pode ter mais de 100 árvores de Multicast. Já com o OpenFlow, como a escolha dos caminhos é feito na Controladora, podem ser aplicadas técnicas de engenharia de tráfego, com análise de qualidade de serviço, de forma a obter-se a melhor árvore de Multicast para cada comunicação. O OpenFlow com Fast Failover é superior ao RSTP como método de recuperação para redes de comunicação com aplicações críticas, como é o caso do IEC 61850. Este trabalho fez uso de emulação para a construção dos cenários. Como um trabalho futuro poderia ser feita a

avaliação utilizando-se switches físicos. Outra possibilidade é verificar as otimizações possíveis que o uso de técnicas como o OpenState [15] poderiam oferecer. REFERÊNCIAS [1] IEC – International Electrotechnical Commission, IEC/TR 61850-1 Communication network and systems for power utility automation – Part 1: Introduction and overview, Edition 2.0, March, 2013. [2] IEC – International Electrotechnical Commission, IEC/TR 61850-90-4 Communication network and systems for power utility automation – Part 904: Network engineering guidelines, Edition 1.0, August, 2013. [3] IEC – International Electrotechnical Commission, IEC/TR 61850-90-12 Communication network and systems for power utility automation – Part 9012: Wide area network engineering guidelines, Edition 1.0, September, 2015. [4] Mininet, Disponível em: . Acessado em ago. 2016. [5] Open vSwitch: An open virtual switch, Disponível em: , Acesso em: ago. 2016. [6] M. Pustylnik, M. Zafirovic-Vikotic, R. Moore, Performance of the Rapid Spanning Tree Protocol in Ring Network Topology. White Paper, Siemens, 2007. [7] IEEE – Institute of Electrical and Electronics Engineers, IEEE Std 802.1D Information Technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Common specifications – Part 3: Media Access Control (MAC) Bridges, December, 1998. [8] IEEE – Institute of Electrical and Electronics Engineers, IEEE Std 802.1D IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges, June, 2004. [9] P. Göransson, C. Black, Software Defined Networks – A Comprehensive Approach, Morgan Kaufmann, USA, 2014. [10] ONF – Open Networking Foundation, OpenFlow Switch Specification – Version 1.1.0 Implemented (Wire Protocol 0x02), February, 2011. [11] F. Tüllenburg, T. Pfeiffenberger, Layer-2 Failure Recovery Methods in Critical Communication Networks, International Conference on Network and Services, June, 2016. [12] J. Zhang, B.C. Seet, T.T Lie, Opportunities for Sofware-Defined Networking in Smart Grid, IEEE Information, Communications and Signal Processing, December, 2013. [13] X. Dong, H. Lin, R. Tan, R. K. Iyer, Z. Kalbarczyk, Software-Defined Networking for Smart Grid Resilience: Opportunities and Challenges, ACM Workshop on Cyber-Physical System Security, April, 2015. [14] OpenFlow 1.3 Software Switch, Disponível em: . Acessado em ago. 2016. [15] OpenState SDN, Disponível em: . Acesso em: ago. 2016. [16] B. Heller, Reproducible network research with high-fidelity emulation, PhD Thesis, Stanford University, 2013. [17] N. Handigol, B. Heller, V. Jeyakumar, B. Lantz, N. McKeown, Mininet Performance Fidelity Benchmarks, Technical Report. Disponível em: . Acesso em: out. 2016. [18] OpenFlow 1.1 Software Switch. Disponível em: . Acesso em: out. 2016. Márcio de Freitas Minicz é graduado em Engenharia Elétrica pela UNIVAP – Universidade do Vale do Paraíba/SP. Em 2005 concluiu seu mestrado em Ciências no Programa de PósGraduação em Engenharia Eletrônica e Computação, Área de Telecomunicações pelo ITA – Instituto Tecnológico da Aeronáutica em São José dos Campos/SP. Atualmente, é Engenheiro de Telecomunicações na Petrobras e doutorando no ITA. Alessandro Anzaloni recebeu seu bacharelado em Engenharia Elétrica da Escola de Engenharia de Mauá, São Paulo, em 1974. Ele é mestre (1978) e doutor (1982) em Engenharia Eletrônica e Computação pelo Instituo Tecnológico de Aeronáutica (ITA). Recebeu o pós-doutorado pela IBM (1985). Ele é professor Titular do ITA, possuindo experiência em telecomunicações.