Edson Adriano Maravalho Avelar - repositorio.ufpe.br§ao... · para as redes, e permitindo...

Pós-Graduação em Ciência da Computação

“PMIPFlow: Uma proposta para gerenciamento

de mobilidade em redes definidas por software”

Por

Edson Adriano Maravalho Avelar

Dissertação de Mestrado

Universidade Federal de Pernambuco

[email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, ABRIL/2013

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA

PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

EDSON ADRIANO MARAVALHO AVELAR

“PMIPFlow: Uma Proposta para Gerenciamento de Mobilidade em Redes Definidas por Software "

ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.

ORIENTADOR(A): Kelvin Lopes Dias

RECIFE, ABRIL/2013

Catalogação na fonte

Bibliotecária Jane Souto Maior, CRB4-571

Avelar, Edson Adriano Maravalho PMIPFlow: uma proposta para gerenciamento de mobilidade em redes definidas por software. / Edson Adriano Maravalho Avelar. - Recife: O Autor, 2013. xxvii, 139 p.: fig., tab. Orientador: Kelvin Lopes Dias.

Dissertação (mestrado) - Universidade Federal de Pernambuco. CIn, Ciência da Computação, 2013.

Inclui bibliografia e apêndice. 1. Redes de computadores. 2. Sistemas distribuídos. I. Dias, Kelvin Lopes (orientador). II. Título. 004.6 CDD (23. ed.) MEI2013 – 048

Dissertação de Mestrado apresentada por Edson Adriano Maravalho Avelar à Pós-

Graduação em Ciência da Computação do Centro de Informática da Universidade Federal

de Pernambuco, sob o título “PMIPFlow: Uma Proposta para Gerenciamento de

Mobilidade em Redes Definidas por Software” orientada pelo Prof. Kelvin Lopes

Dias e aprovada pela Banca Examinadora formada pelos professores:

______________________________________________

Prof. Paulo Roberto Freire Cunha

Centro de Informática / UFPE

______________________________________________

Prof. Marco Antonio de Oliveira Domingues

Depto. Acadêmico de Sistemas Eletro-Eletronicos / IFPE

_______________________________________________

Prof. Kelvin Lopes Dias

Centro de Informática / UFPE

Visto e permitida a impressão.

Recife, 1 de março de 2013

___________________________________________________

Profa. Edna Natividade da Silva Barros Coordenadora da Pós-Graduação em Ciência da Computação do

Centro de Informática da Universidade Federal de Pernambuco.

Dedico esta dissertação à toda minha família e em especial

minha esposa Lorena.

Agradecimentos

Gostaria de agradecer primeiramente a Deus, que me deu o dom da vida e saúde paraconcluir este trabalho.

Ao meu orientador, Kelvin Dias, que sempre me ajudou e me deu a oportunidade derealizar o sonho de concluir o mestrado. Sem ele, a realização deste trabalho não seriapossível.

Agradeço à minha família, meus pais Baltasar e Marinete e meus irmãos Umbelino eKarine, que sempre me deram apoio, com muito amor e carinho em tudo que fiz.

E, em especial, minha esposa Lorena que sempre foi minha companheira nos momen-tos bons e ruins de minha vida.

Muito obrigado pelos esforços de todos, pois sem esse apoio não seria capaz de chegaronde cheguei.

vii

"O único lugar onde sucesso vem antes de trabalho é no dicionário"

—ALBERT EINSTEIN

Resumo

Apesar do enorme sucesso da Internet, a comunidade científica tem apontado dificuldadesem promover inovação e buscar soluções para os novos desafios nas redes tradicionais,tais como a mobilidade, qualidade de serviço (QoS) e qualidade de experiência (QoE).Atualmente, os requisitos para usuários móveis e aplicações multimídia são incorporadosnas redes, mas com limitações, através de constantes incrementos/remendos na pilhaTCP/IP (Transmission Control Protocol/Internet Protocol). Assim, a pesquisa sobrearquitetura para Internet do Futuro (FI) chegou a um impasse, ao qual convencionou-sedenominar de engessamento da Internet.

Com a proliferação de smartphones, tablets e uma infinidade de dispositivos/sensoresconectados à Internet, embarcados em veículos (carros, ônibus etc.) ou robôs (porexemplo, para monitoramento ambiental, de tráfego e energia, além da segurança doscidadãos), há necessidade de um gerenciamento de mobilidade eficiente e escalável, afim de garantir tanto a obtenção das informações coletadas por objetos/sensores móveisconectados às redes sem fio nas futuras cidades inteligentes, quanto para permitir acontinuidade do serviço para usuários móveis.

Nas pesquisas sobre arquiteturas para Internet do Futuro, a academia e a indústriaestão apostando nas redes definidas por software (SDN/Software-Defined Networks) e,particularmente, na plataforma OpenFlow. Essas tecnologias surgem para auxiliar nassoluções dos problemas supracitados e são alvo de muitas pesquisas em arquiteturaspara Internet do Futuro. Na filosofia SDN, o plano de controle é separado do plano dedados dentro dos comutadores, fornecendo, desta forma, programabilidade e flexibilidadepara as redes, e permitindo extensão e inovação. No entanto, ainda não há uma soluçãoconsolidada para mobilidade do terminal em arquiteturas SDN.

Esta dissertação propõe e avalia uma nova arquitetura de gerenciamento de mobilidadebaseada em SDN para a Internet do Futuro. A proposta é implementada em um testbed

OpenFlow/802.11(Wi-Fi). Além disso, a fim de proporcionar mobilidade transparente(seamless), é desenvolvido um mecanismo de decisão de handover (mudança de ponto deacesso) baseado na lógica fuzzy. Os resultados de desempenho demonstram a eficáciada proposta no fornecimento de mobilidade transparente e continuidade de serviço aousuário, bem como o suporte adequado para os requisitos de tráfego de vídeo em termosde métricas de QoS/QoE.

Palavras-chave: OpenFlow, Redes Definidas por Software, Gerenciamento de Mobili-dade, PMIP, Virtualização de Redes, Redes Móveis Programáveis.

xi

Abstract

Despite the huge success of the Internet, the research community has pointed out diffi-culties in promoting innovation in the network and solutions to the new challenges suchas mobility support and quality of experience (QoE). Currently, those requirements formobile users and multimedia applications are incorporated, but with limitations, into thenetworks through patches to the TCP/IP stack. Thus, the research on Future Internet (FI)architectures has reached an impasse, commonly known as the Internet ossification.

Concomitantly, the proliferation of smartphones, tablets and plethora of devices orsensors connected to the Internet, embedded into vehicles or inside robots (e.g., forenvironmental, traffic, energy monitoring and citizen security), requires scalable andefficient mobility management in order to grant the service continuity for both the mobileusers as well as the decision makers of future smart cities which may benefit from mobilenetworks.

Toward the Future Internet, the academia and industry are betting on the so calledSoftware Defined Networks (SDNs) and, particularly, OpenFlow platform. They ariseto assist on solutions to the aforementioned issues and are the mainstream of manyresearches on Future Internet architectures. SDNs philosophy separates the control fromdata plane of network switches, thus permitting programmability and flexibility into thenetwork. However, there is still no consolidated solution to terminal mobility in SDNs.

This dissertation proposes and evaluates a novel SDN based mobility managementarchitecture for Future Internet. The proposal is implemented in an OpenFlow/802.11testbed. In order to provide seamless mobility, a handover (change of access point)decision mechanism based on a fuzzy system is developed. The performance resultsdemonstrated the effectiveness of the proposal in providing seamless mobility e servicecontinuity, as well as the adequate support to the video traffic requirements in terms ofQoS/QoE metrics.

Keywords: OpenFlow, Software-Defined Network, Mobility Management, PMIP,Network Virtualization, Programable Mobile Networks.

xiii

Conteúdo

Lista de Figuras xix

Lista de Tabelas xxi

Lista de Acrônimos xxiii

1 Introdução 11.1 Objetivos da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . 3

2 Trabalhos Relacionados 52.1 Mobilidade e PMIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Mobilidade em redes OpenFlow . . . . . . . . . . . . . . . . . . . . . 10

2.3 Antecipação de Handover em redes IP . . . . . . . . . . . . . . . . . . 11

2.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Redes Definidas por Software e OpenFlow 153.1 Necessidade de uma Nova Arquitetura . . . . . . . . . . . . . . . . . . 15

3.2 Redes Definidas por Software . . . . . . . . . . . . . . . . . . . . . . 17

3.3 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.1 NOX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.5 Virtualização e Criação de Fatias (Slices) . . . . . . . . . . . . . . . . . 21


4 Gerenciamento de Mobilidade 254.1 Localização e Handover . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Gerenciamento de Mobilidade com IPv6 . . . . . . . . . . . . . . . . . 27

4.2.1 Endereçamento IPv6 . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.2 Fluxo de Mensagens . . . . . . . . . . . . . . . . . . . . . . . 29

4.3.3 Detecção de Movimentos . . . . . . . . . . . . . . . . . . . . . 31

4.3.4 Estrutura de Dados . . . . . . . . . . . . . . . . . . . . . . . . 32

xv

4.3.5 Modificações ao IPv6 . . . . . . . . . . . . . . . . . . . . . . . 33

4.4 Proxy MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.4.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.4.2 Fluxo de Mensagem do PMIPv6 . . . . . . . . . . . . . . . . . 35

4.4.2.1 Conexão . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4.2.2 Handover . . . . . . . . . . . . . . . . . . . . . . . 37

4.4.3 Estruturas de Dados . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.4 Comparação entre MIPv6 e PMIPv6 . . . . . . . . . . . . . . . 40


5 Arquitetura PMIPFlow 435.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2 Sinalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.1 Conexão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.2 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3 Implementação do PMIPFlow . . . . . . . . . . . . . . . . . . . . . . 49

5.3.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3.3 Origem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3.4 Pré-Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3.5 Estrutura do Programa . . . . . . . . . . . . . . . . . . . . . . 51

5.3.5.1 Subsistema de Comunicação com o Kernel . . . . . . 51

5.3.5.2 Sequência de Execução . . . . . . . . . . . . . . . . 52

5.3.6 Configuração do PMIPFlow . . . . . . . . . . . . . . . . . . . 54

5.3.7 Modo de Operação OMAG . . . . . . . . . . . . . . . . . . . . 55

5.3.7.1 Detecção de Movimento . . . . . . . . . . . . . . . . 56

5.3.8 Modo de Operação PMIPFlow-LMA . . . . . . . . . . . . . . 57


6 Proposta de Antecipação de Handover 596.1 Sistema PMIPFlow(Fuzzy) . . . . . . . . . . . . . . . . . . . . . . . . 60

6.2 Variáveis de Entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.3 Conjuntos Fuzzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

xvi

7 Protótipo 697.1 Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.1.1 OMAG (OpenFlow MAG) . . . . . . . . . . . . . . . . . . . . 70

7.1.2 Gateway OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . 72

7.1.3 Switch OpenFlow (Indigo) . . . . . . . . . . . . . . . . . . . . 74

7.1.4 FlowVisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.1.5 LMA-NOX/PMIPFlow-LMA . . . . . . . . . . . . . . . . . . 75

7.1.6 CN/Servidor de Streamming de Video . . . . . . . . . . . . . . 76

7.1.7 Mobile Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7.1.8 Ambiente de Testes . . . . . . . . . . . . . . . . . . . . . . . . 78


8 Avaliação 798.1 Ambiente de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8.3 Teste de Capacidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8.4 Avaliação de Qualidade de Serviço . . . . . . . . . . . . . . . . . . . . 83

8.5 Avaliação da Qualidade de Experiência . . . . . . . . . . . . . . . . . 90

8.5.1 Avaliação do PSNR . . . . . . . . . . . . . . . . . . . . . . . . 90

8.5.2 Avaliação do SSIM . . . . . . . . . . . . . . . . . . . . . . . . 95


9 Conclusão 1019.1 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

9.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

9.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Referências Bibliográficas 105

Apêndices 111

A Scripts 113A.1 Hostapd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

A.2 NTP.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

A.3 PMIPFlowSetup.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

A.4 PMIPFlowInit.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

A.5 ofdatapathX.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

xvii

A.6 PMIPFlow-LMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

B Instalação 135B.1 FlowVisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135B.2 Recompilar o Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

B.2.1 Linux em AP mode . . . . . . . . . . . . . . . . . . . . . . . . 139

xviii

Lista de Figuras

3.1 Arquitetura SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Arquitetura OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Criação de fatias centradas no usuário . . . . . . . . . . . . . . . . . . 22

3.4 Cenário de funcionamento do FlowVisor . . . . . . . . . . . . . . . . . 22

4.1 Modos de Funcionamento do MIPv6 . . . . . . . . . . . . . . . . . . . 30

4.2 Fluxo de Mensagens do Protocolo MIP . . . . . . . . . . . . . . . . . . 31

4.3 Cabeçalho de Mobilidade . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4 Visão Geral do PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.5 Fluxo de Mensagens no início da conexão de um MN . . . . . . . . . . 36

4.6 Fluxo de Mensagens durante o handover . . . . . . . . . . . . . . . . . 38

5.1 Arquitetura PMIPFlow . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Sinalização de Conexão no Domínio PMIPFlow . . . . . . . . . . . . . 46

5.3 Sinalização de Handover dentro do Domínio PMIPFlow . . . . . . . . 48

6.1 Representação do Sistema Fuzzy . . . . . . . . . . . . . . . . . . . . . 61

6.2 Saída da ferramenta IPTraf . . . . . . . . . . . . . . . . . . . . . . . . 63

6.3 Saída da ferramenta ping6 destacando-se o RTT do pacote . . . . . . . 63

6.4 Saida da ferramenta iwconfig . . . . . . . . . . . . . . . . . . . . . . 64

6.5 Grau de pertinência para a entrada RTT . . . . . . . . . . . . . . . . . 65

6.6 Grau de pertinência para a entrada Vazão . . . . . . . . . . . . . . . . 65

6.7 Grau de pertinência para a entrada RSS . . . . . . . . . . . . . . . . . 66

6.8 Saída do Sistema Fuzzy . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.1 Entidades de prototipação da arquitetura PMIPFlow . . . . . . . . . . . 70

7.2 Placa Sem-Fio PCI TP-Link . . . . . . . . . . . . . . . . . . . . . . . 71

7.3 Máquina Física onde são instalados os OMAGs . . . . . . . . . . . . . 71

7.4 Rack do núcleo do testbed . . . . . . . . . . . . . . . . . . . . . . . . 73

7.5 Visão do Gateway OpenFlow no Hypervisor vSphere . . . . . . . . . . 74

7.6 Interface WEB de configuração do Indigo/PMIPFlow . . . . . . . . . . 74

7.7 PMIPFlow-LMA executando no NOX . . . . . . . . . . . . . . . . . . 76

7.8 Printscreen do Servidor de Vídeo (CN (Correspondent Node)) . . . . . 77

7.9 Criando um Servidor de Video no VLC . . . . . . . . . . . . . . . . . 77

7.10 Ambiente de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

xix

8.1 Planta baixa do ambiente de teste . . . . . . . . . . . . . . . . . . . . . 808.2 Mapeamento da intensidade do sinal no ambiente de teste para o OMAG1 808.3 Mapeamento da intensidade do sinal no ambiente de teste para o OMAG2 818.4 Movimentação do MN no ambiente de teste . . . . . . . . . . . . . . . 828.5 Teste de capacidade da rede sem fio . . . . . . . . . . . . . . . . . . . 828.6 Gráfico de atraso dos pacotes . . . . . . . . . . . . . . . . . . . . . . . 838.7 Intervalo dos dados de atraso de pacotes . . . . . . . . . . . . . . . . . 848.8 Vazão do tráfego UDP limitado à 10Mbps . . . . . . . . . . . . . . . . 858.9 Intervalo da Média da Vazão do tráfego UDP limitado à 10Mbps . . . . 868.10 Vazão do tráfego UDP limitado à 20Mbps . . . . . . . . . . . . . . . . 878.11 Intervalo da Média da Vazão do tráfego UDP limitado à 20Mbps . . . . 878.12 Gráfico em barra da porcentagem de Perdas de Pacotes . . . . . . . . . 888.13 Gráfico em linha dos dados da porcentagem de Perdas de Pacotes . . . . 898.14 Gráfico de intervalo de variação dos dados da porcentagem de Perdas de

Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898.15 Comparação entre o PSNR do vídeo 160x90 com e sem a proposta . . . 918.16 Intervalo do PSNR do vídeo 160x90 com e sem a proposta . . . . . . . 928.17 Comparação entre o PSNR do vídeo 320x180 com e sem a proposta . . 938.18 Intervalo do PSNR do vídeo 320x180 com e sem a proposta . . . . . . 938.19 Comparação entre o PSNR do vídeo 640x360 com e sem a proposta . . 948.20 Intervalo do PSNR do vídeo 640x360 com e sem a proposta . . . . . . 958.21 Comparação entre o SSIM do vídeo 160x90 com e sem a proposta . . . 968.22 Intervalo do dados de SSIM do vídeo 160x90 com e sem a proposta . . 968.23 Comparação entre o SSIM do vídeo 320x180 com e sem a proposta . . 978.24 Intervalo do dados de SSIM do vídeo 320x180 com e sem a proposta . . 978.25 Comparação entre o SSIM do vídeo 640x360 com e sem a proposta . . 988.26 Intervalo dos dados de SSIM do vídeo 640x360 com e sem a proposta . 988.27 Frame 598 no instante do handover com o PMIPFlow e com o PMIP-

Flow(Fuzzy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

xx

Lista de Tabelas

3.1 Controladores OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Comparação entre MIPv6 e PMIPv6 . . . . . . . . . . . . . . . . . . . 40

6.1 Resultados do Experimento PSNR/Distância . . . . . . . . . . . . . . . 666.2 Valores de Classificação do PSNR . . . . . . . . . . . . . . . . . . . . 666.3 Regras de Inferência . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8.1 Estatística descritiva para o atraso dos pacotes . . . . . . . . . . . . . . 858.2 Estatística descritiva para vazão de 10Mbps . . . . . . . . . . . . . . . 868.3 Estatística descritiva para vazão de 20Mbps . . . . . . . . . . . . . . . 888.4 Estatística descritiva para Porcentagem de Perdas de Pacotes . . . . . . 908.5 Valores de Classificação do PSNR . . . . . . . . . . . . . . . . . . . . 918.6 Vídeos utilizados nos testes . . . . . . . . . . . . . . . . . . . . . . . . 918.7 PSNR do vídeo com resolução 160x90 . . . . . . . . . . . . . . . . . . 928.8 PSNR do vídeo com resolução 320x180 . . . . . . . . . . . . . . . . . 938.9 PSNR do vídeo com resolução 640x360 . . . . . . . . . . . . . . . . . 958.10 Resumo dos dados de SSIM para todas as resoluções de vídeo. . . . . . 99

xxi

Lista de Acrônimos

3GPP 3rd Generation Partnership Project

AAA Authentication, Authorization and Accounting

AP Access Point

API Application Programming Interface

BA Binding Ack

BC Binding Cache

BCE Binding Cache Entry

BRR Binding Refresh Request

BU Binding Update

BUL Binding Update List

CDMA Code Division Multiple Access

cMAG current MAG

CN Correspondent Node

CoA Care of Address

CoT Care of Test

CoTI Care of Test Init

DHAAD Dynamic Home Agent Address Discovery

DHCP Dynamic Host Configuration Protocol

DoS Denial of Service

DSS Darwin Streaming Server

EDGE Enhanced Data for GSM Evolution

EPFMIPv6 Enhanced Fast Handover for PMIPv6

xxiii

FA Foreign Agent

FLPMIPv6 Fast Localized PMIPv6

FMIP Fast Handover MIP

FMIPv6 Fast Handover MIPv6

GPRS General Packet Radio Service

GPS Global Positioning System

GSM Global System for Mobile Communications

HA Home Agent

HI Handover Initiate

HMIP Hierarchical MIP

HNP Home Network Prefix

HoA Home-of Address

HoT Home Test

HoTI Home Test Init

HSDPA High-Speed Downlink Packet Access

ICMP Internet Control Message Protocol

ICMPv6 ICMP IPv6

IETF Internet Engineering Task Force

IODS Indigo Open Development System

IP Internet Protocol

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

ISP Internet Service Provider

xxiv

LAN Local Area Network

LMA Local Mobility Anchor

LTE Long Term Evolution

MAG Mobility Access Gateway

MIH Media-Independent Handover

MIP Mobile IP

MIPv6 Mobile IPv6

MLD Multicast Listener Discovery

MNid Mobile Node Identifier

MN Mobile Node

MNPP Mobile Node Policy Profile

MOS Mean Opinion Score

MSU Video Quality Measurement Tool

NA Neighbor Advertisement

NAT Network Address Translation

ND Neighbor Discovery

NetLMM Network-Based Localized Mobility Management

nMAG new MAG

NS-2 Network Simulator version 2

NS Neighbor Solicitation

NTP Network Time Protocol

OMAG Openflow Mobility Access Gateway

PBA Proxy Binding Ack

xxv

PBU Proxy Binding Update

PFMIPv6 Fast Handover for PMIPv6

PIS Proxy Information Server

pMAG previous MAG

PMIP Proxy Mobile IP

PMIPv6 Proxy Mobile IPv6

PSNR Peak Signal to Noise Ratio

QoE Quality of Experience

QoS Quality of Service

RADIUS Remote Authentication Dial In User Service

RA Router Advertisement

RO Route Optimization

RS Router Solicitation

RSS Received Signal Strength

RTP Real Time Protocol

RTSP Real Time Streaming Protocol

SDN Software Defined Network

SSIM Structural Similarity Index

SSL Secure Sockets Layer

UMTS Universal Mobile Telecommunication System

VLAN Virtual Local Area Network

VLC Video LAN

VQEG Video Quality Experts Group

xxvi

Wi-Fi Wireless Fidelity

WiMAX Worldwide Interoperability for Microwave Access

WLAN Wireless LAN

xxvii

1Introdução

"Seja a mudança que você quer ver no mundo."

—DALAI LAMA

Com o crescimento do número de smartphones e de iniciativas open-source, estamossaindo de um cenário onde o ecossistema de serviços e infraestrutura era fechado eproprietário e passa a ser aberto e livre (Yap et al., 2010b). Entretanto, no contextode infraestrutura e equipamentos de rede, as soluções, em geral, permanecem fechadase proprietárias em função das estratégias de mercado dos principais fabricantes, bemcomo, pela manutenção da operação ininterrupta das redes de produção e ISPs (Internet

Service Providers) que são relutantes a modificações. Dessa forma, novos requisitos sãoincorporados à pilha TCP/IP (Transmission Control Protocol/Internet Protocol) por meiode remendos. Isto cria um impasse, comumente chamado de engessamento da Internete torna as redes complexas, de difícil gerenciamento, não extensíveis e fechada parainovação (Chowdhury and Boutaba, 2009).

Neste contexto, as redes definidas por software, SDN (Software Defined Network)(McKeown et al., 2008), surgem como a tecnologia chave para promover a inovaçãodas redes cabeadas e sem fio. A ideia do conceito SDN é separar claramente o plano dedados do plano de controle. Desta forma, é possível usufruir de várias vantagens, comodispor de um controle maior da rede, de monitoramento eficiente e de um controladorcom gerenciamento local ou remoto de todos os elementos da rede através de aplicações,da mesma forma como é feito com softwares para desktop, daí a denominação conferidaa este novo conceito.

Outra tecnologia importante neste processo é a virtualização. No sentido amplo emcomputação, a virtualização é uma estratégia para resolver muitos problemas e criar

1

CAPÍTULO 1. INTRODUÇÃO

novos serviços. Por exemplo, para hosts individuais, a virtualização permite que umúnico computador realize o trabalho de muitos outros através do compartilhamento deseus recursos entre vários ambientes virtuais. Já servidores virtuais permitem hospedarmúltiplos sistemas operacionais e aplicações. No caso da virtualização de redes, recursospodem ser divididos em fatias, considerando cada roteador como um elemento que podeser virtualizado. Em suma, um roteador pode executar múltiplas instâncias e, desse modo,o substrato físico, a rede, pode executar múltiplas topologias virtuais (Sherwood et al.,2009).

A virtualização surge para revolver vários problemas; como escalabilidade, segurança,portabilidade, redução de custos, aumento da eficiência energética, confiabilidade, entreoutros. Isso porque ela desacopla a função executada por um sistema de sua partefísica. A virtualização de redes pode ser alcançada através de várias formas, utilizandomáquinas virtuais como roteadores ou por meio de redes programáveis, como é feito como OpenFlow (McKeown et al., 2008).

O OpenFlow é um padrão aberto que permite a criação de redes virtuais utilizando so-mente recursos de camada 2 (L2/Layer 2), normalmente implementadas por comutadores(switches) Ethernet, com tabelas de encaminhamento internas e uma interface padrão paraadicionar e remover entradas de fluxos. Assim, torna-se viável testes de novos protocolosem larga escala, usando os recursos das próprias redes de produção (McKeown et al.,2008).

A utilização das redes sem fio em cenário SDN ainda está em um estágio inicial.Com a proliferação de smartphones, tablets e uma infinidade de dispositivos/sensoresconectados à Internet, embarcados em veículos (carros, ônibus etc.) ou robôs (porexemplo, para monitoramento ambiental, de tráfego e energia, além da segurança doscidadãos), há necessidade de um gerenciamento de mobilidade eficiente e escalável, afim de garantir tanto a obtenção das informações coletadas por objetos/sensores móveisconectados às redes sem fio, quanto para permitir a continuidade do serviço para usuáriosmóveis.

Tendo em vista a falta de soluções para o gerenciamento de mobilidade em SDN,esta dissertação propõe a arquitetura PMIPFlow, inspirada nos protocolos NetLMM (Network-Based Localized Mobility Management), como o PMIPv6 (Proxy Mobile IPv6)(Gundavelli et al., 2008a), que liberam o dispositivo móvel das funções ligadas à mobi-lidade e delegam à rede a tarefa de mudar o ponto de acesso (handover) do dispositivodecorrente de sua movimentação e/ou devido à busca por melhores canais.

Este trabalho propõe e avalia uma nova arquitetura de gerenciamento de mobilidade

2

1.1. OBJETIVOS DA PESQUISA

baseada em SDN para a Internet do Futuro. A proposta é implementada em um testbed

OpenFlow/802.11(Wi-Fi). Além disso, a fim de proporcionar mobilidade transparente(seamless), é desenvolvido um mecanismo de decisão de handover (mudança de pontode acesso) baseado na lógica fuzzy (Klir and Yuan, 1995). Os resultados de desempenhodemonstram a eficácia da proposta no fornecimento de mobilidade transparente/continui-dade de serviço ao usuário, bem como o suporte adequado para os requisitos de tráfegode vídeo em termos de métricas de QoS (Quality of Service) (Firoiu et al., 2002) e QoE (Quality of Experience) (Winkler and Mohandas, 2008).

1.1 Objetivos da Pesquisa

A seguir, serão apresentados os objetivos geral e específicos da pesquisa desenvolvidanesta dissertação.

1.1.1 Objetivo Geral

O objetivo geral é desenvolver uma arquitetura para o gerenciamento de mobilidade emredes definidas por software. Com isso, os benefícios da programabilidade de redesserão também estendidos para redes sem fio. Além disso, para garantir transferênciatransparente de terminal, outro objetivo é desenvolver um sistema para auxiliar na tomadade decisão do handover.

1.1.2 Objetivos Específicos

• Realizar pesquisas em gerenciamento de mobilidade no contexto de redes definidaspor software.

• Estudar o processo de handover em redes OpenFlow.

• Realizar um levantamento bibliográfico sobre o estado da arte das soluções relacio-nadas com o tema em questão.

• Estudar todos os conceitos por trás da filosofia SDN, como protocolo OpenFlow,slices ou fatias, controlador entre outros.

• Caracterizar e desenvolver um sistema baseado em lógica fuzzy para auxiliar natomada de decisão de handover.

• Avaliar a proposta em um testbed OpenFlow/IEEE 802.11(Wi-Fi) usando métricasde QoS e QoE.

3

CAPÍTULO 1. INTRODUÇÃO

Esta dissertação está dividida da seguinte forma. No Capítulo 2, são apresentados ostrabalhos relacionados à esta pesquisa. O Capítulo 3 discute a necessidade de uma novaarquitetura para as redes tradicionais. A teoria e os conceitos por trás de gerenciamento demobilidade IP serão abordados no Capítulo 4. Em seguida, no Capítulo 5, será discutidaa arquitetura do PMIPFlow, abordando desde a sinalização, conexão e handover, até suaimplementação no ambiente Linux. O Capítulo 7 foi reservado para discussões sobreo desenvolvimento do protótipo do PMIPFlow, explicando a implementação de cadaentidade da arquitetura. Para melhorar ainda mais a solução PMIPFlow, e adequá-la paraserviços de tempo real, criou-se o PMIPFlow(Fuzzy), que é uma proposta de antecipaçãode handover utilizando lógica fuzzy, essa proposta está detalhada no Capítulo 6. Aavaliação da arquitetura e da proposta PMIPFlow(Fuzzy) será discutida no Capítulo8, utilizando tanto métricas de QoS (Quality of Service) quanto de QoE (Quality of

Experience) e os resultados mostram a eficácia da proposta. Por fim, o Capítulo 9 destacaas considerações finais e discute alguns direcionamentos para trabalhos futuros.

4

2Trabalhos Relacionados

"As oportunidades multiplicam-se

à medida que são agarradas"

—SUN TZU

Este capítulo apresenta os trabalhos relacionados ao PMIPFlow. Ele está divididoem três subseções. A seção 2.1 mostra alguns trabalhos relacionados ao protocoloPMIP, o qual serviu como inspiração para o PMIPFlow. A seção 2.2 aborda artigossobre gerenciamento de mobilidade em redes OpenFlow. Na seção 2.3 são discutidos ostrabalhos que abordam soluções para decisão e antecipação de handover e na seção 2.4,são apresentas as considerações finais deste Capítulo.

2.1 Mobilidade e PMIP

Esta seção abordará trabalhos relacionados ao gerenciamento de mobilidade que utilizamo PMIP como protocolo na execução do handover.

O Artigo (Obele and Kang, 2009) propõe um esquema proativo de handover sensívelao QoS. Esse esquema inclui um servidor de informações, denominado PIS (Proxy

Information Server), consultado pelas entidades da rede a fim de auxiliar na mobilidade doterminal. Quando o cMAG (current MAG) percebe que o nível de sinal do equipamento dousuário, MN (Mobile Node), está caindo, ele inicia de forma proativa o procedimento dehandover. Envia uma mensagem PBU (Proxy Binding Update) ao LMA (Local Mobility

Anchor) que consulta o servidor PIS e realiza o handover com base nas informaçõesobtidas. A ideia é trocar a sinalização de handover antes de o MN migrar efetivamentepara outro MAG (Mobility Access Gateway) a fim de reduzir o tempo da troca de MAGs.As informações sobre QoS são passadas do MAG para o LMA através da mensagem

5

CAPÍTULO 2. TRABALHOS RELACIONADOS

PBU.

A análise da proposta baseia-se nas trocas de mensagens durante o processo dehandover. A proposta é confrontada com o PMIPv6 padrão, a comparação é feitausando as métricas tempo de handover versus o atraso do enlace sem fio. Alguns pontosimportantes deixaram de ser explicados neste trabalho. Por exemplo, os autores nãoinformam como o PBU foi modificado para incluir informações referentes ao QoSrequerido pelo MN. O artigo menciona também a mensagem link going down do MIH (Media-Independent Handover) (Internet Engineering Task Force, 2007), porém nãodescrevem como framework foi inserido no trabalho. Talvez a avaliação de desempenhoesteja demasiadamente simples, por isso não fica muito clara a vantagem da proposta.

Em (Kim et al., 2009) é proposta uma extensão para o PMIPv6 com bicasting paraprover seamless handover, este esquema foi nomeado de B-PMIPv6. A ideia consisteno envio simultâneo de pacotes do LMA para o pMAG (previous MAG) e nMAG (new

MAG) (por isso o nome bicasting) no instante do handover. Com isso, a perda de pacotesé reduzida. A análise da proposta é feita no ns-2 em um cenário simples. O B-PMIv6 écomparado com o PMIPv6 e com o FLPMIPv6 (Fast Localized PMIPv6). O B-PMIPv6é superior pois utiliza o MIH e não usa buffer de pacotes. A latência do handover só éreduzida devida a utilização do MIH.

O trabalho (Lee and Min, 2009) apresenta um esquema utilizando o PMIPv6 paraprover seamless handover em redes IEEE 802.16e (WiMAX Móvel). O esquema propõe oacréscimo de duas mensagens da camada de enlace e 2 da camada de rede ao padrão PMIP.As mensagens são: HO-Initiate (HI), Link-Up, Fast PBU e Fast PBA (Proxy Binding

Ack). A ideia está na antecipação da mensagem PBU criando uma nova mensagem que osautores chamam de FPBU ou Fast PBU. O FBPU utiliza o endereço contido na mensagemHI (Handover Initiate) para antecipação. É utilizado um buffer no nMAG para evitar aperda de pacotes

A análise da proposta baseia-se nas trocas de mensagens durante o processo dehandover. A proposta é comparada com o PMIPv6 e com o PFMIPv6. A análise mostraque a proposta é melhor que as outras, em termos de latência do handover, isto porque amensagem FPBU é mais eficiente que a PBU.

Enquanto o PMIPv6 trabalha com o BU após o handover da camada de enlace, aproposta do artigo trabalho com o BU durante a troca nesta camada. Uma dos pontosnegativos dessa proposta é a profunda modificação necessária no padrão PMIP e autilização de buffers, que pode prejudicar tráfego sensíveis ao atraso.

Em (Choi et al., 2009) a otimização do percurso é feita somente depois do proce-

6

2.1. MOBILIDADE E PMIP

dimento do handover. Na proposta do artigo a otimização é feita em conjunto com oprocedimento de handover acelerando o processo. A análise da proposta baseia-se nastrocas de mensagens durante o processo de handover. A ideia é, quanto menor o númerode mensagens mais rápido é o processo de handover. A vantagem dessa abordagem é ainicialização do handover no LMA e não no MAG, como é feita em outras proprostas.Ao invés de o pMAG avisar o LMA sobre a otimização de rotas e fazer o processo com onMAG, o LMA inicia o procedimento diretamento com o nMAG

O trabalho (Ryu et al., 2009) apresenta o PFMIPv6 (Fast Handover for PMIPv6) epropõe uma melhora do protocolo nomeada de EPFMIPv6 (Enhanced Fast Handover

for PMIPv6). A ideia é antecipar a mensagem PBU enviada do nMAG para o LMA. NoPFMIPv6 o PBU é a ultima mensagem enviada no processo, no EPFMIPv6 o PBU éenviada assim que o a mensagem HI é recebida pelo nMAG. Este processo faz com queos pacotes sejam enviadas do nMAG diretamente para o LMA, e não do nMAG para opMAG como acontece com o PFMIPv6.

A avaliação da proposta foi baseada em cima de análise matemática utilizando ummodelo de rede celular hexagonal. Para a análise são considerados os custos da transmis-são, a perda de pacotes, a latência do handover e o custo do processo de roteamento. Érealizado um cálculo de custo total somando-se os custos individuais, ao final da análise,mostrou-se que o custo no EPFMIPv6 é melhor se comparada com o PFMIPv6.

A análise matemática é baseada em fórmulas e suposições, este artigo apresenta muitobem as fórmulas utilizadas para o cálculo de latência, perdas de pacotes e custos. Porém,apesar de importante, a análise matemática, neste caso, é muito superficial e não mostrade forma clara os benefícios da proposta apresentada.

O artigo (Magagula et al., 2009) propõe a utilização do padrão IEEE 802.21 (MIH)para prover seamless handover no PMIPv6. A ideia é utilizar as sinalizações do MIH paraauxiliar no processo de handover do PMIPv6. A avaliação foi feito no NS-2 (Network

Simulator version 2) a partir de um cenário padrão (2 MAGs, 1 LMA e 1 CN), onde oMN vai do MAG1 para o MAG2. Foram feitas duas simulações, com e sem MIH. Ohandoff durou 0.4 e 0.12 e foram perdidos 38 e 12 pacotes, sem e com a utilização doMIH, respectivamente.

O handover é heterogêneo entre as tecnologias WLAN (Wireless LAN) (MAG1) eWiMax (MAG2). Apesar de a utilização do MIH trazer vários benefícios, existe o riscode sobrecarga de mensagens causadas pelo MIH se for usado de forma inapropriada. Aanálise da proposta não apresenta dados estatísticos para confirmar os ganhos obtidos.

O trabalho (Wang et al., 2009) propõe um esquema de Fast Handover e otimização

7


de rota, RO (Route Optimization), para prover transferência transparente do usuário entredomínios PMIPv6. A ideia é emprestar o mecanismo utilizado no protocolo FMIPv6 (Fast Handover MIPv6) para tornar transparente o handover no PMIPv6. A chave daproposta está na utilização simultânea do RO com o envio da mensagem PBU.

Para avaliar o desempenho da proposta é utilizada análise numérica e simulação.São usados dois esquemas, um com os MAGs conectados ao mesmo LMA e outrocom MAGs conectados em diferentes LMAs. A simulação feita pelo artigo mostra obenefício da proposta em comparação com o PMIPv6 padrão, porém não é informado osimulador, nem um possível patch PMIPv6, tampouco, parâmetros que foram utilizadosna simulação.

Em (Hwang et al., 2010) é proposto um esquema de handover transparente baseadoem multicasting. A ideia do artigo é bufferizar os pacotes no momento do handover etransmiti-los para grupos multicast, onde dentre os participantes do grupo está o nMAG.Este nMAG guarda os pacotes recebidos via multicast e retransmite-os para o MN quandoeste termina o processo de handover.

Para a avaliação da proposta utilizou-se o NS-2, não foram fornecidos nenhum tipo dedados de desempenho das simulações, nem o patch utilizado. Não há perdas de pacotesutilizando este método, uma vez que todos os pacotes são guardados e transmitidosposteriormente. Por outro lado, a proposta pode gerar uma grande inundação de pacotesdesnecessários na rede além do atraso da retransmissão dos pacotes bufferizados.

o artigo (Gohar et al., 2010) propõe um esquema de encaminhamento de pacotespara minimizar a latência e as perdas do processo de handover, levando em consideraçãoaplicações multicast. Três esquemas de handover são avaliados, Dois intra-LMA e oum inter-LMA. O MLD (Multicast Listener Discovery) é utilizado para Descoberta deEndereços Multicast.

Na proposta, o encaminhamento de pacotes é feito de 3 formas: do pMAG para onMAG, do LMA para o nMAG. A terceira é entre domínios PMIPv6, o encaminhamentoé feito do LMA de um domínio para o LMA de outro. Sempre criando túneis fim-a-fim eutilizando buffer para armazenar os pacotes durante o processo de roteamento.

Para avaliar a proposta utilizaram-se métodos numéricos. Assim como é feito namaioria dos artigos de handover, a análise do custo de sinalização é calculada a partir donúmero de mensagens trocadas no processo de handover. Os resultados mostraram que oesquema proposto pMAG para nMAG possui um desempenho superior ao esquema tradi-cional do PMIPv6. Isto é reforçado pelos gráficos de custo de sinalização apresentadosno artigo.

8

2.1. MOBILIDADE E PMIP

Os autores em (Yi et al., 2010) propõem um novo esquema para o gerenciamento demobilidade usando o PMIPv6 baseado no redirecionamento de mensagens para minimizara carga de sinalização provocada pelos constantes handoffs nos domínios PMIPv6.

Ao invés de a sinalização passar primeiro para o LMA depois para o MAG, como nopadrão PMIPv6. Ela é passada diretamente entre os MAG‘s através de túneis bidirecionais.Para avaliar a proposta, os autores comparam o Forwarding PMIPv6 com o PMIPv6tradicional. É utilizado um modelo analítico de mobilidade baseado em cadeia de markovpara realizar a comparação entra as duas propostas. Os resultados mostram um ganhode desempenho quando se utiliza o Pointer Forwarding em comparação com esquematradicional do PMIPv6.

Em (Taghizadeh et al., 2011) os autores dizem que o PMIPv6 é muito eficiente parareduzir a latência do processo de handover, principalmente por separar a conexão de rádioda mobilidade IP. No entanto, o PMIPv6 é limitado à mobilidade intra domínio. Estetrabalho faz um estudo comparativo das várias propostas de PMIPv6 em cenários interdomínios.

(Taghizadeh et al., 2011) ainda, comparam quatro cenários para implementar oPMIPv6 em escala global: single domain, Hierarchical Multi-domain, Peer Multi-Domaine I-PMIP. A avaliação é feita utilizando-se modelos matemáticos. As propostas sãoavaliadas em termos de Latência de Handover. Os parâmetros variáveis são: probabilidadede falha no meio sem fio, distância entre o LMA e o MAG e distância entre os MAGse as redes vizinhas. A conclusão é que, baseado nos resultados da análise numérica, aproposta Peer Multi-domain se mostra mais vantajosa que as outras e tem um grandepotencial para ser implementada de modo distribuído.

Os autores em (Kim et al., 2011) afirmam que a maioria dos protocolos de mobilidadesão baseados em um cenário com uma unidade âncora centralizada, pelo qual todos otráfego é processado. No entanto, com o crescimento do número de aparelhos conecta-dos à internet é desejável uma arquitetura distribuída. Os autores então propõem trêsalternativas de protocolos de gerenciamento de mobilidade, são eles: PDMC (Partially

Distributed Mobility Control), DDMC (Data-driven Distributed Mobility Control) eSDMC (Signal-driven Distributed Mobility Control).

Esses protocolos são comparados com o PMIP em termos de binding update e custode entrega de pacotes, a fim de provar sua eficácia. A comparação é feita através deanálise numérica. Os resultados mostram que todos as propostas distribuídas são melhoresque o PMIP centralizado, e dentre as três, a que se se mostrou melhor foi a SDMC.

Comparação de protocolos em termos de análise numérica é interessante para termos

9


uma visão geral do custo das mensagens trocadas, porém, nem sempre, este tipo de análiseé adequada, pois existem outras questões como viabilidade e facilidade de implementação.

Esse artigo recai na antiga discussão entre centralizado e distribuído, em alguns casos,uma proposta centralizada é melhor e em outros não. O PMIP também possui extensõespara permitir uma abordagem distribuída (Taghizadeh et al., 2011), talvez nesse caso,fosse mais interessante a comparação com a versão distribuída do PMIP.

2.2 Mobilidade em redes OpenFlow

Alguns trabalhos abordam mobilidade em redes definidas por software. O trabalho (Yapet al., 2010a) discute como as redes sem fio ainda estão paradas no tempo, fechadas e seminovação. Porém, os autores não fornecem uma proposta para melhorar o processo dehandover do usuário, no próprio trabalho os autores admitem a existência de desconexãono handover e que fica a critério do desenvolvedor implementar aplicações NOX paragerenciamento de mobilidade da rede.

Os autores em (Nakauchi et al., 2011) propõem uma plataforma de virtualizaçãocognitiva, chamada AMPHIBIA. A qual possibilita a criação de slices fim-a-fim sobreredes virtuais cabeadas e sem fio. Porém Os autores afirmam que o foco da virtualizaçãoestá no ambiente cabeado e sua aplicação em ambientes sem fio ainda está engatinhando.Os autores destacam que os projetos GENI (Turner, 2006), ORBIT (Orbit-Lab, 2005) e4WARD (Niebert et al., 2008) também são projetos que tratam de redes virtuais sem fio.Porém eles afirmam que o foco está apenas no isolamento dos recursos das redes sem fio.

Os autores em (Li et al., 2012) abordam SDN em redes LTE (Long Term Evolution).Os autores inicialmente discutem que as redes celulares sofrem com a inflexibilidade,equipamentos caros, e protocolos complexos no plano de controle. Nos entanto para queesta nova arquitetura SDN seja utilizada alguns problemas precisam ser resolvidos como:suporte a vários assinantes, mobilidades frequentes, controle e medições mais apuradasda rede e adaptações em tempo real.

Os autores fornecem uma interessante explicação sobre o funcionamento das redesLTE, em seguida explicam que o plano de controle e o de dados destas redes se misturam,e desta forma, as redes SDN seriam uma boa alternativa para tornar as redes LTE flexíveise aberta a inovação.

Para concretizar redes SDN em LTE, os autores propõe 4 extensões. Os autores expli-cam a necessidade de se adaptar a aplicação dinamicamente na rede baseada em métricasmais profundas, como PSNR (Peak Signal to Noise Ratio) ou MOS (Mean Opinion Score)

10

2.3. ANTECIPAÇÃO DE HANDOVER EM REDES IP

ambas métricas de QoE de aplicações de vídeo. No entanto as redes celulares de hojenão possuem este controle fino dos fluxos de dados passantes. Com o SDN é possívelfazer uma análise profunda dos pacotes da rede e reduzir o congestionamento. O sistemaLTE é bastante semelhante à arquitetura PMIP, de modo que, o PMIPFlow poderia serimplementado também nesta arquitetura de rede celular.

Os autores em (Yamasaki et al., 2011) comentam que as redes sem fio de campus sãoimplementadas utilizando várias redes lógicas separadas por tags de VLAN (Virtual Local

Area Network)(IEEE 802.1Q) tradicionais, em princípio essa abordarem era suficiente,porém com o crescimento das redes de campus a complexidade das utilizações de VLANsaumentou tornando o seu uso quase impraticável. Os autores então propõem a utilizaçãode um sistema de VLANs baseado no OpenFlow, desta forma criando um sistemaescalável e de fácil configuração. Os autores, tranferem a ideia de VLAN para umaaplicação no NOX, criam GIDs (Group IDs), que seriam as tags do "802.1Q", além disso,definem o AMF (Access Management Function) que gerencia o acesso dos usuáriosbaseados no GIDs.

2.3 Antecipação de Handover em redes IP

Alguns estudos abordam diversas formas de melhorar o desempenho do processo dehandover. Nesta seção, serão descritos alguns trabalhos existente na literatura sobre essetema.

O algoritmo desenvolvido em (Atalah et al., 2008), foi baseado em medidas do indi-cador de força do sinal recebido RSS (Received Signal Strength) para prever o próximoestado do nó móvel. Uma nova técnica de predição chamada RGP (RSS Gradient Pre-

dictor) foi utilizado para detectar a mudança de estado dos valores de RSS. O preditormostrou-se eficiente para aplicações de vídeo em tempo real em uma rede sem fio com-posta por tecnologias Wi-Fi (Wireless Fidelity) e WiMAX (Worldwide Interoperability

for Microwave Access). Esse trabalho mostra que o RSS pode ser usado com sucessona antecipação de handover, porém, a proposta é limitada, pois um usuário próximo aoponto de acesso, ou seja, com valor alto de RSS, pode não ter qualidade de serviço devidocongestionamentos na rede, como abordado em (Tsukamoto et al., 2007).

O objetivo do artigo (Tsung-Nan and Po-Chiang, 2005) é reduzir a probabilidade dequebra durante o handover sobre condições de recursos limitados. Nele foi propostoum método de antecipação de handover para tráfego multimídia baseado na taxa desucesso das entregas de pacotes (PSR/Packet Success Rate). Os autores realizam a

11


predição do tempo restante para cada terminal móvel atingir o requisito mínimo de PSR.A prioridade do gatilho de handover é baseado nesse tempo restante. A proposta éavaliada em simulação, utilizando o cenário descrito em (Chang and Leu, 2004). Osresultados mostram que a proposta é mais eficiente em comparação com outras soluções.Por não utilizar apenas métricas físicas, como RSS, a proposta é mais interessante quea anterior, (Atalah et al., 2008). No entanto, acredita-se que a antecipação de handover

depende de vários fatores e não de uma única variável, como é sugerido no artigo.

Em (Nasser et al., 2006), são discutidos os diferentes aspectos do processo de hando-

ver. Neste trabalho foi implementado o VHDF (Vertical Handover Decision Function)que fornece mecanismos de decisão de handover em redes heterogêneas. o VHDF utilizacusto de serviço, segurança, consume de energia, condições e desempenho das redescomo parâmetros na decisão do handover. De acordo com a avaliação do VHDF, feitano simulador NS-21, a vazão é maior especialmente quando ocorrem grandes variaçõesno tráfego background da rede. Esse trabalho utiliza diversas variáveis de entrada paradecisão de handover, porém, a avaliação no simulador, não reflete cenários reais, e ogerenciamento de mobilidade é conduzido apenas em redes tradicionais.

O artigo (Itoh et al., 2002) apresenta um algoritmo de gatilho de handover baseadona distância do terminal móvel para estação base vizinha e na intensidade do sinalrecebido (RSS). O algoritmo executa o handover quando a medida de distância excedeum determinado limiar e quando o RSS excede um nível dado por uma heurística. Noentanto, o desempenho da proposta é menos eficiente no pior caso se comparada comoutras soluções. Para resolver esse problema, os autores sugerem o uso de sistema delocalização de alta fidelidade como GPS (Global Positioning System). Porém, o GPSconsome bastante energia e para auxiliar no processo de handover precisaria estar emconstante funcionamento, o que consumiria rapidamente a bateria de dispositivos compoucos recursos, como telefones celulares, notebooks ou tablets.

Em (Tsukamoto et al., 2007) é usado um mecanismo de decisão de handover baseadono RSS e no número de quadros retransmitidos. A proposta é avaliada em um testbed802.11 e os resultados mostram que apenas o RSS não é capaz de de detectar com precisãoa degradação da qualidade da comunicação. No entanto, o número de quadros foi capazde detectar a queda na qualidade do serviço. Com isso, os autores sugerem a utilizaçãoapenas do número de quadros retransmitidos como métrica de decisão de handover.Como foi dito anteriormente, acredita-se que apenas uma variável é insuficiente paradecisão de um processo tão complexo como o handover.

1Network Simulator: http://www.isi.edu/nsnam/ns/

12

2.4. CONSIDERAÇÕES FINAIS

A aplicação de lógica fuzzy para decisão de handover em redes heterogêneas foiapresentada em (Wu, 2011). Foram utilizados o RSS, velocidade e carga do sistemacomo entradas do sistema fuzzy. Na avaliação, o sistema, nomeado de FUN-HODs (Fuzzy

Normalization for Handover Decision Strategy), se mostrou vantajoso, embora o cálculode velocidade se mostra inviável em dispositivos com restrições de energia.

O trabalho em (Mun-Yee Lim and Chow, 2012) também implementa um sistema dedecisão de handover baseado em lógica fuzzy. São utilizados como entrada as métricas:RSS, velocidade e distância. A avaliação da proposta foi realizada usando a tecnologia802.11 com o protocolo de mobilidade MIPv6. As simulações foram conduzidas noframework OMNET++/xMIPv6 (Yousaf et al., 2008). A proposta foi comparada comoutras três. Nas simulações, a solução se mostrou vantajosa, porém, toda a propostabaseada em velocidade precisa de coletas com alto grau de consumo de energia, como porexemplo, usando o GPS, o que praticamente inviabiliza seu uso em dispositivos restritos.

Outro trabalho que se baseia em lógica fuzzy para o mecanismo de handover éapresentado em (Sharma and Khola, 2012). Este trabalho usa como entrada as métricas:largura de banda, predição do RSS e preferências do usuário. Ao contrário dos outros,esse artigo usa uma predição de RSS e não o próprio valor. Nessa proposta, o usuáriopossui um papel fundamental na decisão do handover, pois uma das entradas do sistemafuzzy é a preferência do usuário. Nela o usuário deixa predeterminado se quer que ohandover aconteça, se não quer ou se deixa a critério do sistema. A análise é feita atravésde simulação, porém, nenhuma avaliação é apresentada, deixando dúvidas sobre a eficáciada proposta.

2.4 Considerações Finais

Este capítulo discutiu os trabalhos relacionados ao PMIPFlow, os vários trabalhos relaci-onados mostram a relevância desta pesquisa. Primeiramente, foram abordados algunsartigos sobre o PMIPv6. Este protocolo está sendo bastante pesquisado e melhorado,o que justifica sua escolha como base para o PMIPFlow. Foram apresentados também,alguns trabalhos que abordam gerenciamento de mobilidade em redes definidas porsoftware, porém nenhuma delas propõem uma arquitetura com protocolo de mobilidadepadronizado, não apresentam nenhuma proposta de otimização de handover e não fazemavaliação de desempenho utilizando métricas de QoE.

Foram discutidos, ainda, alguns artigos com soluções de antecipação de handover.Desses trabalhos é possível concluir que o RSS é uma métrica importante no mecanismo

13


de decisão, mas não pode ser usado de forma isolada, é necessário alguma outra métricaque reflita a comunicação entre o terminal e a rede. Alguns trabalhos, usam quadrosretransmitidos, alguns usam largura de banda e outros velocidade. O certo é que a decisãode handover precisa ser tomada usando um conjunto de métricas centradas tanto na redequanto no usuário. O próximo capítulo mostra os conceitos por trás das redes definidaspor software, que é a tendência de pesquisa mundial para solucionar o problema doengessamento da Internet.

14

3Redes Definidas por Software e

OpenFlow

"Sábio é o homem que chega a ter consciência de sua ignorância"

—BARÃO DE ITARARÉ

O mundo das redes de computadores atravessa uma grande revolução. A programabi-lidade de redes oferecida pelo paradigma SDN trás varias inovações e transforma a ideiade redes engessadas e fechadas, para redes abertas, flexíveis e de rápida evolução. Issoporque através de uma interfaces padronizada e um sistema de controle externo, a filosofiaSDN fornece um gerenciamento mais eficiente dos elementos da rede, separando o planode dados do plano de controle. O OpenFlow é uma das tecnologias que implementa oconceito SDN.

Este capítulo está organizado da seguinte forma. A Seção 3.1 aborda a necessidadede uma nova arquitetura. A Seção 3.2 apresenta os princípios das redes definidas porsoftware. A Seção 3.3 detalha as características do OpenFlow. Nessa seção, serãodiscutidos os componentes, protocolo e controlador, da arquitetura OpenFlow. Na seçãoseguinte, será apresentado o NOX, o controlador OpenFlow que foi utilizado na soluçãoPMIPFlow. A seção 3.5 mostra como obter isolamento nas redes OpenFlow, utilizando-seo conceitos de fatias ou slices. A última seção finaliza o capítulo com as consideraçõesfinais.

3.1 Necessidade de uma Nova Arquitetura

O acelerado crescimento do número dispositivos móveis, da oferta de conteúdo e serviços,da virtualização de servidores e o advento de serviços em nuvem estão entre os motivos

15

CAPÍTULO 3. REDES DEFINIDAS POR SOFTWARE E OPENFLOW

que fizeram a indústria repensar as arquiteturas de redes tradicionais. Atualmente, asredes são hierárquicas, construídas com camadas de switches Ethernet dispostos emuma estrutura em forma de árvore. Essa arquitetura fazia sentido quando a computaçãocliente-servidor era dominante, mas uma arquitetura estática não é adequada para atenderàs novas demandas de serviços e de armazenamento que são necessárias nos centros deprocessamento de dados datacenters de empresas, campi, e em grandes centros urbanosque almejam o conceito de cidades inteligentes. Algumas das tendências chaves dacomputação que estão levando à necessidade de um novo paradigma de rede incluem(Feldmann, 2007):

• Mudança no padrão de tráfegos: dentro de empresas de processamento de dadose de tráfego, os padrões mudaram significativamente. Em contraste com aplicaçõescliente-servidor onde a maior parte da comunicação ocorre entre um cliente e umservidor, as aplicações atuais acessam diferentes bancos de dados e servidores.Ao mesmo tempo, os usuários necessitam de comunicação à qualquer hora, emqualquer lugar e com qualquer dispositivo. Além disso, o advento das redes sociaisaumentou ainda mais o número de serviços em smartphones. Essa mudança depadrão de tráfego gera um aumente considerável no tipo e na quantidade de pacotesque percorrem a rede.

• Necessidade de segurança das redes: os usuários estão cada vez mais empre-gando dispositivos móveis pessoais, como smartphones, tablets e notebooks emambiente corporativos. As tecnologias de rede precisam acomodar estes dispositi-vos pessoais e ao mesmo tempo proteger os dados corporativos e de propriedadeintelectual. Segurança também é algo que precisa ser efetivo e definitivo.

• O aumento de serviços em nuvem: usuários e empresas estão aumentando consi-deravelmente o uso de serviços em nuvem, tanto privada quanto pública, resultandoem um crescimento sem precedentes desses serviços. Unidades de negócio daempresa querem agora a agilidade para acessar aplicações, infraestrutura e ou-tros recursos de TI sob demanda. Para aumentar a complexidade, os serviços emnuvem devem ser oferecidos em um ambiente com maior segurança, estrutura ade-quada e robustez. Além disso, como o volume de dados nos datacenters aumentaexponencialmente, é necessário um maior controle desse tráfego.

Todas essas mudanças que ocorrem na forma como o usuário interage com a rederequer uma reformulação. As redes estáticas atuais não estão preparadas para essas mu-danças. O surgimento do SDN é uma tentativa de criar redes dinâmicas que possibilitam

16

3.2. REDES DEFINIDAS POR SOFTWARE

maior controle, maior segurança no tratamento dos dados e que não sejam estáticas, eque se adequam à demanda de novos serviços.

3.2 Redes Definidas por Software

O SDN (Software Defined Network) é um conceito de redes emergentes onde o controleda rede está desacoplado do encaminhamento de dados e esse controle é totalmenteprogramável (McKeown et al., 2008). A Figura 3.1 mostra a visão lógica da arquiteturaSDN. A inteligência da rede está centralizada na camada de controle, que possui a visãoglobal da rede. Com o SDN, as empresas e os operadores ganham controle sobre toda arede, independente do fornecedor, e em um único ponto lógico, o que melhora bastante ogerenciamento da rede.

Camada de Aplicação

Aplicação

Camada de Controle SDNSoftware de Controle

Serviços de Rede

Camada de Infraestrutura

Dispositivo de Rede

Dispositivo de Rede

Dispositivo de Rede

Dispositivo de Rede

Dispositivo de Rede

API API API

Interface para Plano de Controle(ex. Openflow)

Figura 3.1: Arquitetura SDN

Uma das grandes vantagens que a arquitetura SDN proporciona é a simplificação dosequipamentos de rede, uma vez que a inteligência do controle da rede é transferida parao controlador, cabendo ao dispositivo de rede apenas receber instruções enviadas pelocontrolador. Deste modo, switches de baixo custo podem controlar uma grande rede queantes só poderia ser controlada por equipamentos de custo bastante elevado.

Com o SDN, os operadores e administradores podem configurar a rede de formasimplificada e automatizada, ao invés de ter que analisar e modificar códigos com dezenasde linhas de configuração, espalhados entre vários dispositivos. Além disso, aproveitandoa inteligência centralizada do controlador SDN, que veremos adiante, os operadores

17


podem alterar o comportamento da rede em tempo real e implantar novas aplicações eserviços em questão de horas ou dias, em vez de as semanas ou meses necessários hoje.Além disso, os operadores podem escrever seus próprios protocolos, sem precisar esperarpor recursos a serem incorporados em ambientes de vendedores de software proprietário.

Além da abstração da rede, a arquitetura SDN suporta um conjunto de APIs que tornapossível a implementação de serviços comuns às redes, incluindo roteamento, multicast,segurança, controle de acesso, gerenciamento de largura de banda, engenharia de tráfego,qualidade de serviço, armazenamento, gerenciamento de energia, e todas as formas degerenciamento de políticas customizadas para atender os objetivos de negócio.

3.3 OpenFlow

O OpenFlow é um padrão aberto, desenvolvido pela universidade de Stanford (Stanford,2008), que implementa o conceito SDN e permite a criação de redes virtuais usandosomente recursos L2 (switches Ethernet) com tabelas de fluxo internas e uma interfacepadrão para adicionar e remover entradas de fluxos. Uma das ideias centrais do projetoOpenFlow é disponibilizar a plataforma abertamente para que seja adotada até mesmopor fabricantes de switches.

A Figura 3.2 mostra a arquitetura do OpenFlow. Ela é composta de três partes. Aprimeira consiste na tabela de fluxos, que possui ações bem definidas para cada fluxo.A segunda parte consiste no canal de comunicação seguro que faz a comunicação doswitch OpenFlow com o controlador. A terceira parte trata-se do protocolo utilizado nessacomunicação, chamado protocolo OpenFlow.

Uma das entidades mais importantes do OpenFlow é o controlador. Esse elementorealiza todo o controle da rede de forma remota e centralizada. Na arquitetura Open-Flow, toda a inteligência da rede é desempenhada por aplicações que executam dentrodo controlador. A próxima seção discutirá esse importante elemento da arquiteturaOpenFlow.

3.4 Controlador

O controlador OpenFlow como vimos na Figura 3.2, é um elemento que controla o switch

OpenFlow de forma remota através de um canal seguro. Dentro do switch é possívelencontrar uma implementação do OpenFlow que recebe os comando do controladorpara adicionar, modificar ou remover entradas na tabela de encaminhamento. Existem

18

3.4. CONTROLADOR

Switch Openflow

sw

hw

Canal Seguro

Flow TableFlow TableTabela de Fluxo

Especificação do switch Openflow

Controlador

Protocolo

OpenFlow

SSL

. . .

Figura 3.2: Arquitetura OpenFlow

vários controladores disponíveis. A Tabela 3.1 mostra os mais utilizados no mercado e naacademia.

Existem vários controladores OpenFlow, como mostrado na Tabela 3.1, porém, paradesenvolver o PMIPFlow optou-se por usar o NOX. Essa escolha foi pautada por váriosmotivos: o primeiro foi que a linguagem utilizada é a mesma da implementação doPMIPFlow (C/C++), e além do ganho de desempenho, a integração é mais natural. Outromotivo é o grande número de exemplos disponibilizados com o NOX, o que facilita oaprendizado e o desenvolvimento de novas propostas. Além do mais, o NOX é utilizadocomo controlador padrão do Mininet (Mininet, 2011), que é um simulador de redesOpenFlow bastante difundido.

3.4.1 NOX

O NOX (Nicira Networks, 2010) é um controlador OpenFlow cujo objetivo é forneceruma interface de programação de alto nível para aplicações de rede. As aplicações degerência e controle são implementadas em cima do NOX, essas aplicações determinamcomo cada fluxo se comporta dentro da rede OpenFlow. Diferente dos ambientes de redepadrão de desenvolvimento, o NOX permite um modelo de programação centralizado

1Baseado no controlador Beacon2Baseado na versão 0.4 do controlador NOX

19


Tabela 3.1: Controladores OpenFlow

Controladores Linguagem Documentação Open Source ReferênciaNOX C++/Python Rica Sim (Nicira Networks,

2010)Maestro Java Razoável Sim (Rice University,

2011)Trema C/Ruby Pobre Sim (NEC, 2011b)Beacon Java Boa Sim (Stanford Univer-

sity, 2011)Helios C - Não (NEC, 2011a)BigSwitch1 Java - Não (Big Switch

Networks, 2011)SNAC2 C++/Python - Não (Nicira Networks,

2010)Floodlight Java Muito Rica Sim (Nicira Networks,

2010)

para toda rede. Esse controlador foi projetado para suportar grandes redes empresariais decentenas de switches (suportando, milhares de hosts) e redes menores possuindo algunsservidores.

O núcleo do NOX (Nox Core) fornece aplicativos com uma visão abstrata dos recursosda rede, incluindo a topologia da rede e localização de todos os hosts detectados. Osprincipais objetivos do NOX são:

• Fornecer uma plataforma que permita aos desenvolvedores e pesquisadores ino-var dentro de suas casas, em universidades ou em redes empresariais, utilizandohardwares reais de rede, não apenas simuladores. As aplicações NOX podemcontrolar toda a conectividade da rede, incluindo o encaminhamento, roteamento,controle de acesso, permissão de usuários etc. Além disso, o NOX pode intervirem qualquer fluxo da rede dando prioridade aos que necessitam de mais qualidade.

• Fornecer um software de rede útil para os operadores. A versão atual incluigerenciamento central para todos os switches em uma rede, controle de admissãotanto de usuário quanto de host, e um mecanismo completo de políticas.

Os aplicativos no NOX clássico podem ser escritos em C/C++ e/ou Python. O NOXfornece uma API (Application Programming Interface) de alto nível para OpenFlow bemcomo controles de rede de outras funções. Como foi referido anteriormente, o NOXcontrola os switches da rede através do protocolo OpenFlow. Por isso, requer pelo menosum switch na rede com suporte ao OpenFlow.

20

3.5. VIRTUALIZAÇÃO E CRIAÇÃO DE FATIAS (SLICES)

O software de controle do NOX é executado em um PC e gerencia as tabelas deencaminhamento de vários switches. Ele exporta uma interface de programação atravésda qual vários programas de rede (chamados de aplicações) podem ser executados. Estasaplicações podem monitorar os eventos da rede, ter acesso ao tráfego, controlar decisõesde encaminhamento do switch, entre outras ações.

O NOX é capaz de realizar suas tarefas de maneira escalável, operando sobre fluxosde rede (ao invés de pacotes individuais). Para cada novo fluxo na rede, o primeiro pacoteé enviado para NOX que repassa para aplicações interessadas. Os aplicativos podemdeterminar se, e como, transmitir o fluxo na rede, coletar estatísticas, modificar os pacotesno fluxo (por exemplo, adicionando uma tag VLAN) ou decidir analisar outros pacotesdentro do mesmo fluxo. Há sempre duas versões do NOX:

Master (estável): versão estável e que a maioria das modificações são correções deerros.

Destiny (instável]): onde novas funcionalidades são experimentadas.

Atualmente, o NOX clássico (C++/Python) foi separado em NOX (Somente C++)e POX (NOX somente Python), o PMIPFlow foi desenvolvido utilizando-se o NOXclássico (em C++).

3.5 Virtualização e Criação de Fatias (Slices)

Um dos benefícios da utilização do OpenFlow é a possibilidade de criação de fatias ouslices, através do framework FlowVisor (R. Sherwood, G. Gibb, K. Yap, G. Appenzeller,N. McKeown, and G. Parulkar, 2009). Dividir a rede em slices traz grandes benefícioscomo isolamento da rede, priorização de serviços e facilidade de gerenciamento. Inicial-mente, a criação de slices foi pensada para redes cabeadas, porém, essa ideia tambémpode ser aplicada em ambientes sem fio. A Figura 3.3 mostra que um usuário utilizandoum serviço de vídeo conferência pode ser alocado em um slice com maior prioridade eum usuário navegando na web em outro, com menor prioridade. Desta forma, é possívelcriar slices e alocar usuários de acordo com as restrições de QoS das aplicações querodam em seu dispositivo móvel.

O FlowVisor é um controlador OpenFlow especial que atua como uma camadatransparente entre o comutador OpenFlow e múltiplos controladores. Atuando destaforma, o FlowVisor pode criar fatias de recursos na rede e delegar cada fatia para umcontrolador diferente. Esses slices podem ser definidos de várias formas: por portas, por

21


SLICE 2 (Prioridade Média)

SLICE 1 (Prioridade Alta)

SLICE 3 (Prioridade Baixa)

Usuário 1

(Videoconferência)

Usuário 2 (VoIP)

Usuário 3 (Web)

Usuário 1

Usuário 2 Usuário 3

Figura 3.3: Criação de fatias centradas no usuário

endereços IP de origem ou destino, por protocolos, por endereço físico, entre outros. OFlowVisor mantém o isolamento entre os slices, ou seja, nenhum slice pode controlar otráfego de outro slice.

A Figura 3.4 exibe um possível cenário de utilização do FlowVisor. Nele é possívelver uma rede OpenFlow composta por um switch, dois pontos de acesso, alguns clientesmóveis acessando conteúdo da Internet e um servidor de controle, onde o FlowVisor estásendo executado. O FlowVisor se comporta como um controlador OpenFlow, ficandototalmente transparente para o switch.

FlowVisor

Switch OpenflowOAP(Openflow Access Point)

OAP(Openflow Access Point)

Usuário Móvel

Pesquisador

Handover

Gerenciamento GUI

Controlador OF (NOX)

App App App App

Desenvolvimento

Controlador OF (NOX)

App de TesteNovo

Protocolo

Gerente de Rede

Usuário Móvel

Usuário Móvel

Internet/Cloud

Servidor de Controle

Usuário Móvel

Legenda:Tráfego de Produção Tráfego Experimental

Usuário Móvel

Figura 3.4: Cenário de funcionamento do FlowVisor

Com o FlowVisor é possível dividir a comunicação da rede em tráfego de produção e

22


experimental. Na Figura 3.4, o gerente realiza suas operações na rede de produção semse preocupar com o tráfego experimental. Por outro lado, um pesquisador interessado emtestar novos protocolos também pode ter seu próprio slice e fazer testes sem se importarcom o tráfego de produção presente na rede. A Figura 3.4 mostra também que a divisãoentre os tráfegos de produção e experimental pode ser feita em um mesmo dispositivo.


Este capítulo tratou vários conceitos que estarão presentes nas redes do futuro. Foidiscutido como o OpenFlow implementa o novo conceito de redes definidas por software,através de um protocolo padronizado que cria uma comunicação entre as entidades geren-ciadas e um controlador. Discutiu-se os diversos controladores existentes no mercado e,em especial, sobre o NOX, controlador utilizado na arquitetura PMIPFlow. Foi abordada,também, virtualização de redes e como criar isolamento através de fatias com o framework

FlowVisor, separando o tráfego de produção do tráfego da rede experimental.O OpenFlow, aos poucos, está substituindo a maioria das infraestruturas de redes de

pequenas e grandes corporações. Além de proporcionar vários benefícios, como inovação,isolamento etc., por ser de código aberto, ele é economicamente mais vantajoso queoutras soluções disponíveis no mercado. Com tantos benefícios, é natural surgir a ideiade utilizar o conceito SDN também em redes sem fio. Porém, quando se trata desse tipode rede, existem vários desafios associados, como instabilidade, interferência e perdasde pacotes. A seguir, o capítulo 4 discutirá os desafios do gerenciamento de mobilidadenas redes sem fio, onde serão apresentados alguns protocolos de gerenciamento, e emespecial, o PMIPv6, o qual inspirou a proposta PMIPFlow.

23

4Gerenciamento de Mobilidade

"Existem várias coisas boas no mundo,

mas tenho a impressão que a amizade

é a melhor de todas - saber que podemos

fazer algo grande por um amigo."

—JORGE AVELAR

O gerenciamento de mobilidade surgiu para resolver o problema de transferênciado usuário entre as diversas redes celulares, processo conhecido como handover ouhandoff. Com o advento das redes sem fio domésticas e a comutação por pacotes, todasas redes estão convergindo para o protocolo IP. Nesse novo cenário, o gerenciamentode mobilidade deixa de ser apenas necessidade apenas das redes celulares e torna-sepeça fundamental para as operações das redes móveis do futuro. Neste contexto, énecessário que esse processo seja realizado de forma rápida e eficiente, pois a interrupçãoda transmissão significa perda de qualidade e credibilidade do serviço.

O capítulo está organizado da seguinte forma. Na seção 4.1, serão discutidos osprincipais aspectos do gerenciamento de mobilidade. Na seção 4.2, será abordada amobilidade no mundo IPv6. Na seção 4.3 serão apresentados alguns aspectos do protocolode mobilidade MIPv6, o qual serviu como base para muitos outros protocolos, comoFMIP, HMIP, PMIP entre outros. Na Seção 4.4, é apresentado o PMIPv6, a evolução doMIPv6 que inspirou o PMIPFlow.

4.1 Localização e Handover

O gerenciamento de mobilidade é ponto crucial para o sucesso das redes do futuro. Nestecontexto, o handover é o processo de troca de um nó móvel de um ponto de acesso para

25

CAPÍTULO 4. GERENCIAMENTO DE MOBILIDADE

outro. O procedimento de handover está presente em todas as tecnologias sem fio, IEEE802.11 (Wi-Fi), IEEE 802.16 (WIMAx), 3G/UMTS e LTE, mas com o advento das redestotalmente IP, esse procedimento deixou de ser exclusivo de tecnologia, isto é, L2 e osprotocolos da pilha TCP/IP (L3 e das camadas superiores) também foram readequadospara realizar tal procedimento.

É desejável que o processo de handover seja o mais transparente possível (seamless

handover), de modo que o usuário não perceba a troca de rede, do contrário, ocorremperdas de pacotes, atrasos ou, no pior caso, a total desconexão do usuário. Vários proto-colos foram criados, ao longo do tempo, para fornecer um gerenciamento de mobilidadeeficiente. Nesse capítulo, serão discutidos, particularmente, os protocolos que atuam nacamada de rede, foco dessa dissertação. O leitor interessado em soluções para o geren-ciamento de mobilidade na Internet pode consultar (Internet Engineering Task Force,2011).

O gerenciamento de mobilidade é composto por gerenciamento de localização egerenciamento de handover (Akyildiz et al., 1999). O primeiro é responsável pelalocalização do nó móvel enquanto ele se movimenta entre as redes sem fio. Essasmudanças precisam ser monitoradas para que o nó móvel permaneça alcançável caso umanova chamada seja destinada a ele. O desafio da atualização de localização do nó móvelé manter a sobrecarga de sinalização em um nível aceitável pela rede e pelo nó móvel.Por outro lado, o gerenciamento de handover consiste em manter ativa a conexão dousuário mesmo após a mudança de pontos de acesso. Esse processo pode ser horizontalou vertical.

O handover é horizontal ou homogêneo, se esse processo é realizado entre duastecnologias semelhantes, nó móvel migrando do LTE para outra rede LTE, por exemplo.Já o handover vertical ou heterogêneo ocorre quando a transferência se dá entre duastecnologias distintas, por exemplo, nó móvel migrando de rede LTE para WiMAX.

Soluções para o gerenciamento de mobilidade estão disponíveis em diversas camadas.Soluções de camada dois (L2) são dependentes de tecnologia específica, portanto não é amelhor abordagem para cenários heterogêneos. Soluções de camada três (L3), geralmentesão baseadas no protocolo IP e não dependem de tecnologia. Essas soluções podem serclassificadas de duas formas: gerenciamento global e gerenciamento local.

Gerenciamento de mobilidade global é caracterizado pelo handover entre domíniosdistintos, ou seja, diferentes infraestrutura de tecnologia aos quais não são naturalmenteintercambiáveis, como transferência de tecnologia 3G para uma rede WLAN. Em so-luções de mobilidade global, o nó móvel é responsável pela detecção de movimento e

26

4.2. GERENCIAMENTO DE MOBILIDADE COM IPV6

atualização de sua localização na rede. O MIP (Mobile IP) é um exemplo de protocolode gerenciamento de mobilidade global.

Soluções para gerenciamento de mobilidade local são aplicadas dentro de um mesmodomínio e podem, também, ser usadas em redes com tecnologias diferentes, porém,dentro do mesmo domínio. Nesse tipo de solução, diferente das soluções globais, arede é a responsável pela movimentação do usuário e atualização de sua localização nasentidades internas da rede. O HMIP (Hierarchical MIP) é um exemplo de protocolode mobilidade local que foi criado a partir da extensão do MIP e do FMIP. Porém, oHMIP ainda requer que o nó móvel participe intensamente da sinalização de handover. OPMIP também faz parte desse grupo de protocolos, no entanto, na concepção do PMIPexistem agentes de mobilidade que executam a detecção de movimento e as atualizaçõesde localização do nó móvel, retirando toda a sinalização que antes era de responsabilidadedesse nó. O PMIP foi desenhado para permitir tanto handover horizontal quanto vertical.

4.2 Gerenciamento de Mobilidade com IPv6

A nova versão do protocolo de rede da Internet, o IPv6, apresenta diversas melhorias e éfundamental para dar suporte à nova geração de dispositivos conectados à rede, comocâmeras de segurança, sensores de cidades inteligentes, eletrodomésticos entre outros.Os dispositivos móveis, como celulares e computadores portáteis, difundidos atravésda gama de tecnologias sem fio existentes, impõem novos desafios à funcionalidade daInternet como expostos em (Forman and Zahorjan, 1994).

4.2.1 Endereçamento IPv6

Quando o protocolo IP entrou em vigor, a Internet era restrita a acadêmicos e pesquisado-res, consequentemente, um endereço de rede de 32 bits parecia ser suficiente para atenderessa demanda. Porém, o crescimento desenfreado no número de usuários da rede e a máutilização inicial do espaço de endereços culminaram no seu esgotamento, e foi um dosprincipais motivos da busca por um novo protocolo.

Para solucionar os problemas de endereçamento do IPv4, o IPv6 utiliza endereços de128 bits, um número consideravelmente elevado de endereços, improvável de se esgotar.Esse novo endereçamento ainda reserva um espaço para todos os endereços IPv4, parafacilitar o processo de transição de um protocolo para o outro, o que garante suporteaos novos equipamentos que surgirão com acesso à Internet, permitindo-os utilizar um

27


ou mais endereços globais únicos, acabando com os problemas relacionados ao uso detradução de endereços de rede ou NAT (Network Address Translation).

A apresentação de um endereço IPv6 é diferente do IPv4. Os 128 bits são agrupadosem oito grupos de 16 bits separados por dois pontos, e são exibidos em hexadecimal.Uma sequência de zeros pode ser abreviada com dois símbolos ":"apenas uma vez porendereço. Após o endereço, um número de 0 a 128 define o prefixo do mesmo, que podesignificar um grupo de endereços específico ou auxiliar na identificação da rede em queo nó se encontra. Um exemplo de endereço IPv6 é 2001:0:0:1:0:0:0:A/64 que tambémpode ser abreviado para 2001:0:0:1::A/64.

Os endereços podem ser classificados como Globais, que são armazenados nas tabelasde roteamento e podem ser encontrados globalmente, e Link-local, utilizados apenas emum enlace. Um endereço global deve possuir o prefixo 2000::/3 e um endereço link-localdeve possuir o prefixo FE80::/10.

4.3 MIPv6

O IPv6 Móvel (Johnson et al., 2004) ou MIPv6 (Mobile IPv6)1 foi desenvolvido pela IETF(Internet Engineering Task Force) sendo a entidade responsável pelo desenvolvimento daInternet. O MIPv6 é uma extensão do IPv6 para fornecer gerência de mobilidade e definiua base dos protocolos que surgiram posteriormente, entre eles o PMIPv6. A seguir, seráexplicado, em detalhes, como o gerenciamento de mobilidade é realizado no MIPv6.Essa introdução é necessária pois vários destes conceitos são úteis no entendimento doPMIPFlow.

4.3.1 Visão Geral

Um protocolo de gerenciamento de mobilidade na camada de rede deve permitir que umdispositivo móvel continue acessível mesmo que mude seu ponto de conexão à rede. Esteponto é normalmente conhecido como ponto de acesso ou AP (Access Point). No MIPv6,um novo endereço de rede é configurado em uma rede visitada mas o dispositivo continuaacessível pelo seu endereço antigo. Isto é obtido através de um registro de mobilidadeque associa seu endereço novo, rede visitada, ao endereço antigo, rede doméstica.

Em um cenário de funcionamento do protocolo MIP, como mostrado na Figura 4.1,existem quatro entidades com papeis específicos: o Nó Móvel ou MN, o Nó Correspon-

1Existe o MIPv4 que é uma extensão do IPv4 para mobilidade, mas não será abordado neste trabalho

28

4.3. MIPV6

dente ou CN, o Agente Doméstico ou HA (Home Agent) e o Agente Estrangeiro ou FA (Foreign Agent). O Agente Estrangeiro foi colocado aqui apenas para ilustrar, pois, elesurgiu no MIPv4, e no MIPv6 tornou-se obsoleto possuindo a mesma função do HA.

O MN utiliza o serviço do MIPv6 para manter sua comunicação enquanto se deslocaentre diferentes pontos de acesso, o CN é qualquer dispositivo que esteja se comunicandocom o MN, o HA é um roteador IPv6 na rede doméstica e o FA o roteador na rede alvoda migração do MN. Vale lembrar que no MIPv6 o FA nada mais é que um HA, e não énecessário a implementação de um novo agente, diferente do que era feito com o MIPv4.

Ao realizar o handover para uma rede visitada, o MN configura um novo endereçoIPv6, o qual recebe o nome de CoA (Care of Address). Temporariamente ele não está maisacessível aos pacotes destinados ao seu endereço doméstico, ou HoA (Home-of Address),pois estes são enviados para sua rede doméstica. Para restabelecer sua comunicaçãocom o CN, o MN envia uma mensagem ao HA para registrar o seu CoA. Ao receber amensagem, o HA inicia o repasse dos pacotes recebidos endereçados ao HoA do MNpara o CoA, criando um túnel. O MN também pode solicitar ao CN que envie os pacotesdiretamente ao CoA, se o mesmo tiver suporte ao MIPv6.

A Figura 4.1 representa os dois modos de comunicação de um MN após o handover:tunelamento bidirecional e otimização de rota. No primeiro modo, ilustrado na Figura 4.1pelas linhas com traço seguido de ponto, é criado um túnel bidirecional entra o FA e HA.Toda mensagem que chega no MN, dentro da rede estrangeira, é automaticamente enviadapelo túnel até a rede doméstica. Neste caso, ocorre uma triangulação desnecessária, sendoesse problema resolvido pelo método de otimização de rotas, que ao invés de criar umtúnel FA/HA o protocolo faz a ligação direta do FA com o CN.

4.3.2 Fluxo de Mensagens

Esta seção descreve as mensagens de sinalização enviadas no protocolo, assim comoilustrado na Figura 4.2.

A seguir, é exibido a descrição das mensagens da Figura 4.2.

• [1]: O MN se conecta inicialmente à uma rede de acesso que será sua rededoméstica, configura um endereço por um dos métodos de obtenção de endereços einicia comunicação com um CN.

• [2]: Em um determinado momento, o MN realiza handover e se conecta a umarede visitada. Ele detecta a conexão com a rede visitada através do recebimento de

29


INTERNET

Rede Visitada Rede Doméstica

CN

HAFA

Túnel MN-HASem Túnel } Tunelamento

BidirecionalOtimização de Rota

Nó Móvel (MN)

handover

Figura 4.1: Modos de Funcionamento do MIPv6

um RA (Router Advertisement) ou algum sinal da camada de enlace e configuraum endereço IPv6 na nova rede, seu CoA.

• [3]: Neste etapa, o MN envia uma mensagem denominada BU (Binding Update)para registrar sua nova localização com o HA.

• [4]: Ao receber a mensagem, se o HA aceitar o registro, ele envia uma mensagemde confirmação BA (Binding Ack) ao MN e configura rotas e túneis para o novoendereço do mesmo.

• [5]: O MN retoma a comunicação com o CN pelo modo de tunelamento bidireci-onal.

• [6]: O MN tenta registrar-se com o CN para otimização de rota iniciando umprocedimento de segurança chamado Return Routability.

30

4.3. MIPV6

HANDOVER

[1] Pacotes de dados

[2] Detecção de Conexão

[3] BU

[4] BA

[5] Pacotes de dados pelo túnel [5] Pacotes de dados

[6.1] HoTi [6.1] HoTi

[4] Configuração do túnel

[6.2] CoTi

[6.3] HoT [6.3] HoT

[6.4] CoT

[7] BU

[8] BA

[9] Pacotes de dados

MN HA FA CN

Figura 4.2: Fluxo de Mensagens do Protocolo MIP

• [7]: Se obtiver sucesso o MN envia um BU diretamente ao CN.

• [8]: O CN registra o MN e envia um BA como resposta diretamente ao seu CoA.

• [9]: A comunicação entre MN e CN passa a ocorrer de forma direta.

4.3.3 Detecção de Movimentos

A detecção de movimento consiste em identificar que o nó móvel realizou handover eencontra-se em uma nova rede de acesso. No MIPv6, ela é realizada pelo próprio MNatravés do envio de um RS (Router Solicitation) e do consequente recebimento de umRA com um prefixo de rede diferente da rede em que estava conectado. A partir daí, elesabe que deve enviar um BU ao seu HA para registrar sua nova localização.

31


No MIPv6 quem realiza a maior parte do trabalho de gerenciamento de mobilidade éo MN. Ele envia mensagens RS, monitora a transferência entre redes, além da criaçãode rotas. Para utilizar o MIPv6, é necessário modificar o sistema operacional do MNcom o objetivo de habilitar essas novas funções, além disso, o daemon do MIPv6 precisaestar rodando no dispositivo indefinidamente. Talvez, a sobrecarga gerada no MN pelasinalização do protocolo MIP seja o motivo da não utilização efetiva desse protocolo porparte do mercado.

4.3.4 Estrutura de Dados

Existem duas estruturas de dados fundamentais ao funcionamento do protocolo MIPv6.Os dados armazenados nelas podem variar em diferentes implementações, mas as infor-mações básicas que devem estar presentes são descritas a seguir.

O BC (Binding Cache) está presente nos agentes domésticos e nós correspondentes,sendo que em alguns casos um mesmo dispositivo pode realizar as duas funções. Cadaregistro armazena informações de um MN com o qual o dispositivo se comunica eencontra-se fora de sua rede doméstica. As informações necessárias são:

• O endereço doméstico do nó móvel (HoA);

• O endereço na rede visitada (CoA);

• O tempo de vida do registro;

• O número de sequência do último BU recebido;

• Um flag indicando se é um registro como HA ou de otimização de rota.

A BUL (Binding Update List) está presente nos MNs e armazena informações dosBUs enviados tanto aos nós correspondentes quanto aos agentes domésticos. E essasinformações estão descritas a seguir:

• O endereço do dispositivo remoto, HA ou CN;

• O endereço doméstico do nó móvel;

• O CoA enviado no último BU;

• Um flag indicando se é um registro com HA;

• O número de sequência do último BU enviado;

32

4.3. MIPV6

• Algumas informações para determinar a necessidade de reenvio do BU para odispositivo remoto e o momento a ser enviado.

Ambas as estruturas de dados também contêm informações relacionadas ao proce-dimento de Return Routability, que ajudam a determinar a validade de um registro eproduzir uma chave a ser utilizada nas comunicações entre CN e MN.

4.3.5 Modificações ao IPv6

Novos tipos de mensagens e mudanças em cabeçalhos de extensão foram adicionadasao protocolo IPv6 para suportar a gerenciamento de mobilidade. A Figura 4.3 mostra ocabeçalho de extensão IPv6 usado para transmitir as mensagens de sinalização do MIPv6.O tipo da mensagem de mobilidade é definido no campo "MH Type"deste cabeçalho e asmensagens são inclusas no campo de dados do cabeçalho.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Payload Proto | Header Len | MH Type | Reserved |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Checksum | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || |. .. Message Data .. .| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 4.3: Cabeçalho de Mobilidade

Dentre as várias mensagens do cabeçalho de mobilidade, além de HoTI (Home Test

Init), CoTI (Care of Test Init), HoT (Home Test) e CoT (Care of Test), destacam-se quatromais importantes para o gerenciamento de mobilidade.

Binding Refresh Request Message: A mensagem BRR (Binding Refresh Request) faza requisição para que o MN atualize sua conexão com o HA e CN. Esta mensagemé enviada com CN para o MN. Ela é utilizada para manter ativa a comunicaçãoentre MN e CN.

Binding Update Message: A mensagem BU é uma das mensagens mais importantesdo MIP, ela é enviada pelo MN ao HA e CN para registrar a sua nova localização.Ela contém o CoA, o tempo de vida do registro, e um flag para solicitar serviços doHA.

33


Binding Acknowledgement Message: A resposta ao BU é o BA. O BA confirma oregistro ou avisa que ele não pôde ser realizado pelo motivo especificado no campo"status".

Binding Error Message: A mensagem BE é utilizada pelo CN para sinalizar algumerro relacionado à mobilidade, que pode ser o recebimento de um pacote com HoAnão registrado no BC ou de um tipo de mensagem de mobilidade desconhecido.

As mensagens BU e BA foram reaproveitadas pelo PMIP. Porém, com o nome PBU ePBA como veremos na seção seguinte.

4.4 Proxy MIPv6

Os problemas decorrentes do MIPv6 e a demanda por um protocolo que permitisseo gerenciamento de mobilidade baseada na rede (Kempf, 2007), e não baseada nodispositivo móvel, motivou o desenvolvimento do protocolo PMIPv6 ou Proxy MIPv6(Gundavelli et al., 2008b).

No MIPv6 grande parte da sinalização de mobilidade passa pelo nó móvel. Conside-rando que normalmente este se trata de um dispositivo portátil conectado por um enlacesem fio, surgem alguns problemas. O enlace sem fio além de não ser confiável, normal-mente possui uma banda de transmissão bastante inferior ao das tecnologias de redevia cabo e é compartilhada por diversos dispositivos, o que pode ocasionar uma grandelatência de handover, além de aumentar o overhead sobre o canal sem fio prejudicando aescalabilidade do sistema. Além disso, uma sobrecarga ao enlace sem fio é gerado pelautilização do modo de tunelamento bidirecional, por encapsular os pacotes enviados peloCN dentro de outro cabeçalho IPv6.

Adicionalmente, quando o MIPv6 é usado, cria-se a necessidade de instalação defuncionalidade no nó móvel, o que aumenta o consumo de energia e de processamento dodispositivo, dois fatores limitadores em computação ubíqua. Os problemas apresentadospelo MIPv6 dificultaram o processo de implantação desse protocolo e contribuíram paraque ele não tivesse uma boa aceitação no mercado.

4.4.1 Visão Geral

O PMIPv6 (Gundavelli et al., 2008b) herda algumas das características trazidas peloprecursor MIPv6, como o cabeçalho de mobilidade, o formato de algumas mensagens e asestruturas de dados. A principal diferença ocorre pela retirada da função de gerenciamento

34

4.4. PROXY MIPV6

de mobilidade do dispositivo do usuário, ou seja, o gerenciamento de handover não émais tarefa do dispositivo móvel do usuário.

O serviço de mobilidade do PMIPv6 é disponibilizado no contexto de um domínioadministrativo denominado domínio PMIPv6, ilustrado na Figura 4.4. Ele é compostopor dois tipos de dispositivos o LMA e o MAG, os quais possuem funções específicasrelacionadas à mobilidade na arquitetura PMIP. Na Figura 4.4 existe, ainda, um elementodenominado "Nó Correspondente"que pode representar qualquer terminal com o qual oMN se comunique, como por exemplo, um outro usuário, um servidor de vídeo ou web.

InternetNó Correspondente

(ex. Servidor de Streaming)

MAG1

MAG2

Domínio

PMIPv6

Nó Móvel

t0

Nó Móvel

t0 + 1

Handover

Figura 4.4: Visão Geral do PMIPv6

O MAG tem a função de detectar a chegada de um MN e realizar os procedimentosnecessários para oferecer o serviço de mobilidade a ele. Por outro lado, o LMA tem umafunção similar a do HA no MIPv6, controlando a disponibilidade do serviço de mobi-lidade. Pelo LMA passam todos os pacotes da comunicação entre o MN e dispositivosexternos ao domínio PMIP.

4.4.2 Fluxo de Mensagem do PMIPv6

O protocolo PMIPv6 utiliza alguns conceitos do MIP, algumas funcionalidades forammodificadas e outras acrescentadas para corrigir todos os defeitos que o MIP apresentava.

35


A seguir, será explicado o fluxo de mensagens do protocolo PMIP em dois casos, naconexão do MN ao domínio PMIP e no handover entre dois domínios.

4.4.2.1 Conexão

Quando estiver no domínio PMIPv6, o MN manterá sempre o mesmo endereço IPv6,ainda que mude seu ponto de acesso, sem se preocupar com qualquer sinalização demobilidade, que diferente do MIPv6, é realizada pelo núcleo da rede. A Figura 4.5 ilustraas trocas de mensagens no protocolo PMIPv6 no inicio da conexão de um MN no domínioPMIPv6.

[2] PBU

[3] PBA

[5] Pacotes de dados pelo túnel

MN MAG1 LMA CN

[1] RS

[4] RA

{Conexão MN/MAG1}

(Opções: MN-Id, ATT, HI, LLID, HNP)

A Criação do BCE


Configuração de Endereço

B

(MN HNP)

Figura 4.5: Fluxo de Mensagens no início da conexão de um MN

• [1]: Inicialmente, o MN solicita conexão ao MAG para ingressar no domínioPMIP sendo esta solicitação feita utilizando-se a mensagem RS. Dentro do RSpossui um identificador do MN. O MAG utilizará este identificador para verificarno MNPP (Mobile Node Policy Profile), ou Perfil de Política do MN, se o serviçode mobilidade está disponível e autorizado para o MN.

• [2]: Se o MN não estiver autorizado, o MAG não envia nenhuma mensagempara o MN e ignora sua conexão. Se ele estiver autorizado, o MAG envia uma

36

4.4. PROXY MIPV6

mensagem PBU ao LMA solicitando o serviço de mobilidade para o MN.

• [Evento A]: Ao receber o PBU, o LMA cria um BCE (Binding Cache Entry)para registrar as informações do MN.

• [3]: Em seguida, o LMA envia um PBA ao MAG incluindo um ou mais prefixosde rede a serem utilizados pelo MN para configurar seu endereço. Então, o LMAconfigura um túnel para o MAG a qual o MN se conectou e adiciona uma rota parao prefixo dado ao MN.

• [4]: O MAG, por sua vez, envia para o MN uma mensagem RA com o HNP (Home Network Prefix), ou prefixo de rede doméstica, contido no PBA.

• [Evento B]: Percebe-se que nas trocas de mensagem do PMIPv6, o usuário éum agente passivo. Diferente do MIPv6, o MN no PMIP apenas mostra interesseem ingressar na rede e todas as outra trocas de mensagens são realizadas apenaspelo núcleo da rede, desonerando o dispositivo do usuário da sobrecarga das trocasde mensagens. No PMIPv6 o usuário se conecta à uma rede (MAG1) recebe umRA e configura seu endereço a partir do HNP.

• [5]: O MN configura um endereço com as informações obtidas na mensagem RArecebida do MAG e inicia a comunicação com o CN através do túnel bi-direcionalentre o MAG1 e o CN.

4.4.2.2 Handover

Os protocolos de gerenciamento de mobilidade tentam criar mecanismos para mantera comunicação transparente do usuário enquanto este migra de uma rede para outra. OPMIPv6 é um dos protocolos mais eficientes para o gerenciamento de mobilidade, poisalém de não serem necessárias modificações no MN, a duração, chamada de latência,do processo de handover do PMIPv6 é bastante reduzida em comparação com seusconcorrentes, como abordado em (Kong et al., 2008). A Figura 4.6 mostra as trocas demensagens do PMIPv6 durante o processo de transferência de pontos de acesso.

• [1]: No cenário de handover, inicialmente o usuário está conectado à um MAG.Neste caso, ao MAG1, trocando informações com o CN. O LMA possui uma tabelaBC com os dados do MN, criado no início da conexão, como foi apresentado naSeção 4.4.2.2. Além disso, existe um túnel configurado entre o MAG1 e o LMA,por onde passa todos os pacotes trocados entre o MN e o CN.

37


HANDOVER

[1] Pacotes de dados MN/CN


[3] PBU

[4.2] PBA

[5] Pacotes de dados pelo túnel

Deleta túnel antigo

MN MAG1 MAG2 LMA CN

{Conexão MN/MAG1}

[4] RA

[5] {Conexão MN/MAG2}

A



- Detecção de HANDOVER

- Atualização do BC

B

CCria novo túnel

(MN HNP)

[4.1] PBA (Tempo de Vida Expirado)

Figura 4.6: Fluxo de Mensagens durante o handover

• [2]: Ao entrar em uma nova rede, o MAG da nova rede, neste caso MAG2,detectará a presença do MN através de mensagens de camada de enlace, de acordocom a RFC do PMIP. Esta detecção é transparente ao usuário e não necessita denenhum intervenção do mesmo.

• [3]: Após detectar o novo usuário na rede, o MAG2 envia um PBU para o LMA.

• [Evento A]: Ao receber um PBU, o LMA identificará que se trata de um hando-

ver, pois apesar do MNid (Mobile Node Identifier), contido no PBU, ser o mesmo, oendereço do MAG de origem é diferente do endereço do MAG armazenado na basede dados para aquele MNid. O handover desencadeia uma série de atualizaçõesdentro do LMA e, subsequentemente, dentro dos MAGs, sendo uma das entidadesatualizadas o BC com informações novas sobre o MN em questão.

• [4.1]: O LMA enviará um PBA com tempo de vida esgotado ao MAG1 paraalertar que o dispositivo não se encontra mais conectado. Este também poderáidentificar a saída do MN através de sinalização da camada de enlace, que não édefinida na especificação do protocolo.

38

4.4. PROXY MIPV6

• [4.2]: O LMA envia um PBA ao novo MAG, com as informações necessáriaspara a configuração de novos túneis e endereços.

• [Evento B]: Ao receber um PBA com tempo de vida expirado o MAG anterior,MAG1, deleta tudo que estava armazenado sobre o MN, incluindo entradas paratabelas de roteamento e túneis.

• [Evento C]: Ao receber o PBA, o MAG2 cria entrada de tabelas de roteamentoe um túnel bidirecional entre ele e o MN, caso ele ainda não exista. O MAG2também registra o MN como usuário do túnel. Agora todo pacote endereçado aoMN será encaminhado para o túnel.

• [4]: Para completar a operação, o MAG2 envia um RA ao MN, para que esteconfigure o endereço IPv6 utilizando o HNP contido no RA.

• [5]: Neste momento, tudo está configurado e o usuário poderá continuar suacomunicação entre ele e o CN. Vale lembrar que para maior satisfação do usuário,ou seja, para manter a qualidade de serviço em um nível alto, todo esse processo dehandover descrito precisa ser executado de forma otimizada, objetivando a mínimaou ausência de percepção do usuário sobre o processo.

Os processos de conexão e handover em uma rede PMIPv6 não seriam possíveis sema ajuda das estruturas de dados que compõem o protocolo. A seguir, serão explicadas asestruturas mais importantes para o funcionamento deste protocolo de gerenciamento demobilidade.

4.4.3 Estruturas de Dados

O PMIPv6 mantém as principais estruturas de dados do MIPv6, o Binding Cache e aBinding Update List, porém neste elas são encontradas respectivamente no LMA e noMAG. Além das duas, outra estrutura tem grande importância, o MN Policy Profile quepode ser armazenado nos dois tipos de nós PMIPv6 ou em um servidor separado quefornece informações de autenticação a ambos os tipos de nós.

As informações contidas no BC são as mesmas do MIPv6 com a adição de um flagde um bit para identificar se é um registro PMIPv6 e campos para guardar as informaçõesrecebidas nas opções de mobilidade junto ao PBU como identificador do MN, timestampdo último PBU recebido, indicador de handover, tipo de enlace de acesso e prefixosenviados.

39


Além das informações contidas no protocolo MIPv6, a BUL armazena o identificadordo MN, o endereço de camada de enlace, os prefixos de rede designados a ele, o endereçolink-local a ser utilizado pelo MAG na comunicação com ele, o endereço global doLMA responsável pelo MN, o identificador da interface comunicando com o MN e oidentificador da interface comunicando com o LMA em favor do MN.

O MN Policy Profile armazena as informações relacionadas ao serviço de mobilidadeoferecido ao nó móvel como o identificador do mesmo, uma flag indicando se ele éautorizado ao serviço de mobilidade, o endereço do LMA servindo-o, os identificadoresdas interfaces habilitadas ao PMIPv6 e os prefixos a serem designados a ele.

Além das mudanças nas estruturas de dados, o PMIPv6 adicionou algumas modifi-cações às informações constantes nas mensagens trocadas pelo protocolo MIPv6. Umflag de um bit foi adicionado às mensagens BU e BA do MIPv6 transformando-as nasmensagens PBU e PBA do Proxy MIPv6.

4.4.4 Comparação entre MIPv6 e PMIPv6

A Tabela 4.1 mostra algumas das características que diferem nos protocolos MIPv6 ePMIPv6. Este último consegue reduzir significativamente a sobrecarga em comparaçãocom o MIPv6. Enquanto o MIPv6 necessita de 2 mensagens de sinalização, após ohandover, para reiniciar a comunicação com um CN no modo de tunelamento bidirecionale mais 6 para o modo otimização de rota, o PMIPv6 necessita apenas de 2 mensagens nototal.

Tabela 4.1: Comparação entre MIPv6 e PMIPv6

Categoria MIPv6 PMIPv6Tipo de Gerenciamento Beseada no MN Baseada na redeEscopo de Mobilidade Mobilidade Global Mobilidade LocalizadaNecessita de Modifica-

ção no MNSim Não

Túnel no canal sem fio Utilizado Não UtilizadoEndereçamento Prefixo Compartilhado Prefixo exclusivoOtimização de Rota Suportada Não Necessária

Detecção de Movi-mento

RS/RA Camada de Enlace

Mensagens de sinaliza-çao que atravessam o ca-nal sem fio

No mínimo 2 para tunelamento bidi-recional. No mínimo 8 para otimiza-çao de rota

Nenhuma

Ao contrário de seu precursor, no PMIPv6 nenhuma mensagem de sinalização de

40


handover é trocada no enlace entre o MAG (HA no MIPv6) e o MN, normalmenteconstituído de tecnologia sem fio com uma menor taxa de transmissão. O PMIPv6também não utiliza tunelamento bidirecional, deste modo, não adicionando nenhumasobrecarga na rede de acesso sem fio.


Neste capítulo, foram tratados diversos conceitos sobre gerenciamento de mobilidade.Foi explicado que esse gerenciamento surgiu da necessidade de handover entre as redescelulares e como esse conceito se estendeu para as redes IP sem fio. Alguns protocolosde gerenciamento de mobilidade foram discutidos, entre eles o MIPv6, que se tornoua base para outros protocolo como o PMIPv6 e que, por sua vez, serviu de inspiraçãopara a arquitetura PMIPFlow. No final do capítulo foi apresentado uma comparaçãosimplificada das características dos protocolos MIPv6 e PMIPv6.

O PMIPflow foi inspirado no PMIPv6 sendo ele um protocolo mais robusto e bastanteutilizado para mobilidade IP. Ele possui uma latência (atraso do processo) de handover

menor que o MIPv6, e suas operações são baseada na rede e não no nó móvel. Comisso, todos esses benefícios também são incorporados ao PMIPFlow. Na próxima seção,serão abordados os aspectos mais importantes da arquitetura do PMIPFlow, como asinalização de conexão e handover e como ele foi implementado dentro do conceito deredes definidas por software.

41

5Arquitetura PMIPFlow

"Eu espero que todo homem lute até o limite

para conseguir o prêmio de sua vida."

—SIR ERNEST SHACKLETON

A integração de redes sem fio com Openflow não é tarefa trivial, o que pode serratificado pela quantidade limitada de trabalhos correlatos existentes na literatura. Estecapítulo apresenta uma proposta para o gerenciamento de mobilidade em redes sem fiodefinidas por software, denominada PMIPFlow.

O PMIPFlow foi inspirado no gerenciamento de mobilidade baseado na rede NetLMM(Internet Engineering Task Force, 2010), implementado pelo protocolo PMIPv6. Assim,como no PMIPv6, na arquitetura PMIPFlow, o terminal fica isento de qualquer sinalizaçãoextra referente ao procedimento de handover, além de usufruir dos benefícios do núcleoSDN.

Este capítulo está organizado da seguinte forma. A Seção 5.1 apresenta os elementosque compõem a arquitetura da proposta PMIPFlow. A sinalização envolvida na solução édetalhada na Seção 5.2. Em seguida, na Seção 5.3 será detalhada a implementação doPMIPFlow. Por fim, a Seção 5.4 descreve as considerações finais do capítulo.

5.1 Arquitetura

A Figura 5.1 mostra o cenário, destacando as entidades da arquitetura PMIPFlow.O PMIPFlow está dividido em duas partes principais: O OMAG (Openflow Mobility

Access Gateway) e o componente PMIPFLow-LMA. Este último é uma aplicação execu-tada no LMA-NOX, controlador OpenFlow da arquitetura PMIPFlow. Nesta arquitetura,cada célula, servida por um OMAG, forma o chamado domínio PMIPFlow.

43

CAPÍTULO 5. ARQUITETURA PMIPFLOW

Comutador OpenFlow

(OMAG) OpenFlow

Mobility Access Gateway

(PMIPFlow Gateway)

Usuário Móvel

(OMAG) OpenFlow

Mobility Access

Gateway

Usuário Móvel

Usuário Móvel

Handover

Usuário Móvel

CN

(Nó Correspondente)

Controlador_Bob

Controlador_Alice

Slices/Fatias

Domínio

PMIPFlow

Domínio

PMIPFlow

(PMIPFlow Gateway)

LMA-NOX

(PMIPFlow-LMA em execução)

Figura 5.1: Arquitetura PMIPFlow

• O OMAG é um agente de mobilidade, que reside na borda da rede OpenFlowmonitorando os movimentos dos usuário sob o seu controle, se algum usuário sairde sua cobertura ele deve acionar o PMIPFlow-LMA informando o acontecimentodeste evento. O OMAG também pode iniciar o procedimento de handover para umusuário que esteja na iminência de sair da área de cobertura da rede.

• O LMA-NOX é um controlador especial no qual a aplicação PMIPFlow-LMAé executada. O PMIPFLow-LMA possui duas funções principais: criar regrasnos switches OpenFlow para atender às necessidades de mobilidade dos clientesdo OMAG, receber e tratar mensagens PBU, enviar mensagens PBA ao MN eservir como servidor de AAA (Authentication, Authorization and Accounting)barrando todo e qualquer usuário não autorizado na rede. O PMIPFlow-LMA foidesenvolvido a partir do conceito de LMA no PMIPv6, porém com modificaçõespara transformá-lo em um componente de controlador. Ao invés de criar túneis IP,como o LMA no PMIPv6, o PMIPFLow-LMA recebe o PBU, cria regras na tabelade encaminhamento do switch OpenFlow e envia o PBA de volta para os OMAGs.

Além do OMAG e do PMIPFlow-LMA, é possível verificar que existem gateways

PMIPFlow na arquitetura representado na Figura 5.1. Estes gateways servem como ponto

44

5.2. SINALIZAÇÃO

de saída OpenFlow do domínio PMIPFlow. A proposta pode ser estendida tanto emtermos de adição de novos usuário como em termos de expansão do núcleo da rede, poisse o núcleo da rede crescer, com a inclusão de elementos OpenFlow, a operação dosOMAGs e do PMIPFlow-LMA não serão afetadas por estarem na borda da rede.

O PMIPFlow pode ser executado concorrentemente com outras aplicações do con-trolador sem interferir na operação da rede. Pois, é possível criar fatias especializadaspara clientes móveis e separar as fatias de clientes móveis das fatias de clientes fixos. Porexemplo, é possível executar um Controlador_Alice e um Controlador_Bob

com várias aplicações sem interferir nas operações do LMA-NOX. Mais informaçõessobre a criação de fatias ou slices na Seção 3.5.

Pode-se observar ainda a presença, na Figura 5.1, de um comutador OpenFlow. Estecomutador ou (switch) OpenFlow forma o núcleo da rede SDN do PMIPFlow, é neleque serão instaladas regras de encaminhamento, criadas fatias de redes, priorização detráfego, enfim, todas as operações SDN. Ele é o elemento que o PMIPFlow-LMA irácontrolar, através do LMA-NOX, durante as operações do PMIPFlow.

5.2 Sinalização

O PMIPFlow possui dois tipos de sinalização: conexão e handover. Na sinalização deConexão o usuário apenas seleciona a rede e se conecta, por outro lado, no handover, ousuário, já conectado, migra de uma rede para outra dentro do domínio PMIPFlow.

5.2.1 Conexão

Quando estiver no domínio do PMIPFlow, o MN manterá sempre o mesmo endereçoIPv6, ainda que mude seu ponto de acesso, sem se preocupar com qualquer sinalizaçãode mobilidade, pois esta será realizada pelo núcleo da rede. A Figura 5.2 ilustra as trocasde mensagens entre as entidades da rede no início da conexão de um MN no domínioPMIPFlow.

A seguir o significado de cada mensagem trocada e os eventos importantes queocorrem.

• [1]: Inicialmente, o MN solicita conexão com o OMAG para ingressar no domínioPMIPFlow, essa solicitação feita utilizando-se a mensagem RS (Router Solicitation).Dentro do RS possui um identificador do MN chamado MNid (Mobile Node

Identifier). O PMIPFlow-LMA utilizará este identificador para verificar no MNPP,

45


NOX

[2] PBU

[4] PBA


MN OMAG1 PMIPFlow-LMA Switch Openflow

[1] RS

[5] RA

{Conexão MN/OMAG1}


A Criação do BCE


Configuração de EndereçoB

(MN HNP)

CN

[3] Criação de Regra na

Tabela de Encaminhamento

Figura 5.2: Sinalização de Conexão no Domínio PMIPFlow

ou Perfil de Política do MN, se o serviço de mobilidade está disponível e autorizadopara o MN. Essa autenticação também poderia ser feita através de um servidor deautenticação RADIUS (Remote Authentication Dial In User Service).

• [2]: Se o MN não estiver autorizado, o OMAG não envia nenhuma mensagempara o MN e ignora sua conexão. Do contrário, o OMAG envia uma mensagemPBUao PMIPFlow-LMA solicitando o serviço de mobilidade ao MN.

• [Evento A]: Ao receber o PBU, o PMIPFlow-LMA cria um BCE para registraras informações do MN. Até esse ponto, as operações de trocas de mensagens sãosemelhantes às do PMIPv6, a partir deste ponto o PMIPFlow-LMA deixa de serapenas um LMA para tomar decisões como componente NOX.

• [3]: Após criar o BCE, o PMIPFlow-LMA cria regras de encaminhamento dentrodo switch OpenFlow para definir o caminho que os próximos pacotes MN irãotomar em direção ao CN.

Percebe-se que a sinalização de conexão já é a sinalização inicial de criação deregra de encaminhamento. Em uma rede OpenFlow, todo primeiro pacote é enviadoprimeiramente ao controlador, para que este defina as regras necessárias para opróximo pacotes do mesmo fluxo. No caso do PMIPFlow, o primeiro pacote já

46

5.2. SINALIZAÇÃO

é a sinalização de mobilidade e a regra já é instalada na tabela, de modo que oprimeiro pacote de dados do usuário seja enviado diretamente para o CN e nãoprimeiramente ao controlador.

• [4]: Após criar o BCE e instalar regras de encaminhamento no switch OpenFlow,o PMIPFlow-LMA envia um PBA ao OMAG incluindo um ou mais prefixos derede a serem utilizados pelo MN para configurar seu endereço.

Nesta etapa, o PMIPFlow-LMA configuraria um túnel para o OMAG, porém, acriação de túneis já não faz mais sentido uma vez que as regras de encaminhamentono switch OpenFlow se encarregam de enviar os pacotes para o destino certo. Acriação de túneis IP do PMIP foi substituída pela criação de regras no swtich

OpenFlow.

• [5]: O OMAG, ao receber o PBA, envia para o MN uma mensagem RA com oHNP, ou prefixo de rede doméstica, contido no PBA.

• [Evento B]: Percebe-se que nas trocas de mensagem do PMIPFlow, o usuário éum agente passivo, todos as outra trocas de mensagens são realizadas apenas nonúcleo da rede, desonerando o dispositivo do usuário do overhead das trocas demensagens.

• [6]: Após receber o RA, o MN configura seu endereço com as informaçõesobtidas na mensagem RA recebida do OMAG e inicia a comunicação com o CNpassando pelo OMAG1 e switch OpenFlow.

5.2.2 Handover

Com o advento das redes definidas por software, é desejável que o procedimento dehandover seja o mais transparente possível também nessa nova arquitetura de rede.O PMIPFlow surge para tentar criar uma solução padronizada de gerenciamento demobilidade para este novo paradigma de redes definidas por software. A seguir, seráexplicada a troca de mensagens que ocorrem durante o handover dentro do domínioPMIPFlow. A Figura 5.3 detalha as trocas de mensagens durante o processo.

A seguir a explicação de cada mensagem e evento mostrando na Figura 4.6.

• [1]: No cenário de handover, inicialmente o usuário está se comunicando como CN conectado a um OMAG (Openflow Mobility Access Gateway) . Dentro doswitch OpenFlow existem tabelas de encaminhamento que ligam o MN ao CN

47


NOX

HANDOVER



[3] PBU

[5.2] PBA

MN OMAG1 OMAG2 PMIPFlow-LMA Switch OpenFlow

{Conexão MN/MAG1}

[6] RA

{Conexão MN/OMAG2 Estabelecida}

A



- Detecção de HANDOVER

- Atualização do BCE

(MN HNP)

[5.1] PBA (Tempo de Vida Expirado)

CN

[4] Modifica regras existentes

<<OpenFlow>>


Figura 5.3: Sinalização de Handover dentro do Domínio PMIPFlow

passando pelo OMAG1. No PMIPFlow-LMA existe uma entrada na tabela BCcom os dados do MN, criado no início da conexão. Neste momento, o MN iniciaum movimento para fora da área de cobertura do OMAG1 e para dentro da área doOMAG2.

• [2]: Ao entrar em uma nova rede, o OMAG da nova rede, neste caso OMAG2,detectará a presença do MN através de beacons de camada 2, de acordo com aRFC do PMIP. Esta detecção é transparente ao usuário e não necessita de nenhumintervenção do mesmo.

• [3]: Após detectar o novo usuário na rede, o OMAG2 envia um PBU para oPMIPFlow-LMA.

• [Evento A]: Ao receber um PBU, o PMIPFlow-LMA identificará que se tratade um handover, pois o endereço de origem deste PBU é diferente do endereçode origem do antigo, porém o MNid é o mesmo. O handover desencadeia duasatualizações importantes: a primeira é a atualização o BC dentro do PMIPFlow-LMA e a segunda é na tabela de encaminhamento do switch.

• [4]: Após verificar a ocorrência do handover, além de atualizar o BC, o PMIPFlow-LMA também faz uma modificação nas regras existentes para aquele MNid dentrodo switch OpenFlow.

48

5.3. IMPLEMENTAÇÃO DO PMIPFLOW

• [5.1]: O OMAG1 precisa ser informado, sobre a saída do MN de seus domínios.Após as configurações necessários do MN no OMAG2, este último envia ummensagem PBA com tempo de vida expirado para o OMAG1, este por sua vez,inicia o processo de remoção das informações do MN, para liberação de recursos.

• [5.2]: Após as atualizações necessárias, o PMIPFlow-LMA envia um PBAao novo OMAG, com as informações necessárias para a configuração de túneisinternos e endereços.

• [6]: Para completar a operação, o OMAG2 envia um RA ao MN, para que esteconfigure o endereço IPv6 utilizando o HNP contido no RA.

• [7]: Neste momento, tudo está configurado e o usuário poderá continuar suacomunicação com o CN. Vale lembrar que para maior satisfação do usuário, ouseja, para manter a qualidade de serviço em um nível alto, todo esse processode handover descrito precisa ser executado o mais rápido possível, objetivando amínima ou ausência de percepção do usuário sobre o processo.

5.3 Implementação do PMIPFlow

Esta Seção descreve a Implementação do PMIPFlow para Linux e foi reservada ao leitorque busca informações aprofundadas sobre a implementação da proposta.

A implementação foi nomeada de pmipflow6d, o "d"no final significa daemon ou"Disk and Execution Monitor"que se refere a um aplicativo que roda em plano de fundo.A Implementação do pmipflow6d foi dividida em duas, a implementação do OMAG e aimplementação do PMIPFlow-LMA. A primeiro é executada junto ao ponto de acessopara rastrear e gerenciar a mobilidade do usuário, a segunda roda dentro do controladorfuncionando como uma aplicação. Por conveniência, no PMIPFlow, utilizou-se osmesmos nomes de mensagens, como PBU, PBA, e de estruturas como BCE, BUL, MNPPadotados pelo PMIP.

A Seção começa evocando as motivações para que esse projeto fosse desenvolvido,seus objetivos e sua origem. Então, descreve a estrutura do programa, e logo após o passoa passo de sua execução. Uma seção detalha as opções de configuração disponíveis, efinaliza descrevendo os dois modos de operação do aplicativo e a diferença entre eles.

49


5.3.1 Visão Geral

O pmipflow6d é um aplicativo desenvolvido em C++ que utiliza a biblioteca ipv6 dispo-nível para Linux e algumas funções de comunicação entre userspace e kernelspace paramodificar tabelas de roteamento, adquirir informações de interfaces de rede e criar inter-faces virtuais chamadas túneis . Ele executa em plano de fundo monitorando os pacotesrecebidos pelo nó através da interface de sockets e executando funções em respostas aeventos específicos.

5.3.2 Objetivo

O primeiro objetivo é desenvolver uma implementação do protocolo com suporte àfuncionalidade descrita na especificação para permitir que dispositivos móveis mantenhamo mesmo endereço IPV6 ao mudar seu ponto de acesso dentro de uma rede PMIPFlow,mantendo a comunicação corrente do usuário.

O segundo é integrar o protocolo à uma arquitetura de redes definidas por software,neste caso, utilizando o OpenFlow com o objetivo de criar um gerenciamento de mobili-dade eficiente nesse novo tipo de arquitetura.

5.3.3 Origem

O PMIPFlow foi baseado no projeto MIPv6 for Linux ou MIPL (Nuorvala, V., Petander,H., and A. Tuominen, 2001), desenvolvido inicialmente na "Helsinki University of Tech-nology"em 2001, que se tornou a implementação mais conhecida do MIPv6 para Linux.Hoje ela é mantida pelo Usagi Project 1, principal grupo envolvido no desenvolvimentoe manutenção da pilha IPv6 para Linux, recebendo o nome de Usagi MIP ou UMIP. Ocódigo original encontra-se na versão 0.4 e suporta as versões mais recentes do kerneldo Linux, sendo testado até a versão 3.7. Ele suporta toda a funcionalidade definida naespecificação do MIPv6.

5.3.4 Pré-Requisitos

O pmipflow6d foi desenvolvido para plataforma GNU/Linux e testado nas distribuiçõesDebian e Ubuntu, porém, ele deve funcionar em todas as distribuições GNU/Linux sendonecessário apenas pequenos ajustes, como instalação de bibliotecas ou mudanças nasvariáveis de ambiente. Além disso, o sistema deve ter o IPv6 habilitado, ou seja, todas as

1http://www.umip.org/

50


funcionalidades relacionadas ao protocolo devem estar presentes, como a configuração deendereços, o envio e recebimento de pacotes, as tabelas de roteamento, e mais protocolosassociados como o protocolo Neighbor Discovery e o recebimento e envio de mensagensICMPv6 (ICMP IPv6). Isso é alcançado habilitando as opções do IPv6 na configuraçãodo kernel antes da compilação. Também devem ser habilitadas, as opções relativas àmobilidade e à configuração de túneis IPv6-IPv6.

Normalmente é necessário compilar novamente o código fonte do programa devido adiferenças de configuração entre sistemas. Para isso é necessário um compilador C/C++compatível com a versão do código fonte, foi testada a versão 4.7 do compilador gcc/g++.Existem mais outros programas também necessários para uma compilação bem sucedida.Mais informações podem ser encontradas no Apêndice B.

5.3.5 Estrutura do Programa

As principais mudanças não ocorreram na estrutura do UMIP, mas internamente aoscomponentes, nas funções executadas em resposta aos eventos, nos dados armazenadosnas estruturas de dados e no formato das mensagens de sinalização do protocolo. Osprincipais componentes do programa são descritos a seguir.

Existem três estruturas de dados que armazenam as informações de funcionamento doprotocolo PMIPFLow: o BC (Binding Cache), o BUL (Binding Update List) e o MNPP (Mobile Node Policy Profile). O BC é criado apenas no PMIPFlow-LMA, dentro doLMA-NOX, e o BUL apenas no modo OMAG, já o MNPP é criado em ambos os modos edeve armazenar as mesmas informações do mesmo nó móvel em todos os dispositivos dodomínio. O desenvolvimento de um protocolo de sincronização entre os dados dos MNPPou implementação de um servidor de autenticação para fornecer essas informações sãoplanos de trabalhos futuros. As interfaces desses componentes contêm um conjunto defunções utilizadas para manipulação dos dados armazenados e manutenção das estruturasde dados.

5.3.5.1 Subsistema de Comunicação com o Kernel

A comunicação com o kernel tem um papel fundamental no funcionamento do aplicativoe fornecimento do serviço de mobilidade. Três tipos de comunicação com o kernel sãorealizadas pelo pmipflow6d: sockets IPv6, interface NETLINK e controle de túnel. Aprimeira é utilizada para receber e enviar pacotes pelos dispositivos de rede. A interfaceISockSend contém as funções de envio de pacotes genéricos pelo socket, a interface

51


ISockRecv contém as funções de monitoramento para a chegada de pacotes de umdeterminado protocolo e conseqüente recebimento em um formato genérico, e a interfaceISockConf contém as funções de configuração dos sockets.

A interface NETLINK é utilizada para transferir informações entre processos rodandono espaço do usuário e processos no espaço do kernel. No pmipflow6d é realizadacomunicação com duas famílias de processos do kernel, a família Route que permite fazermodificações aos endereços de interfaces e tabelas de roteamento, e a família XFRMque permite gerenciar regras de segurança. Assim sendo, são definidas duas interfacespara esse componente: IROUTE e IXFRM. A primeira contém as funções de adição eremoção de endereços IPv6, adição e remoção de rotas, e adição e remoção de regras deroteamento. A segunda contém funções de adição e remoção de políticas de segurançaque permitem ou proíbem a entrada de pacotes com determinadas características.

O controle de túnel é utilizado para configurar dispositivos de rede virtuais chamadostúneis pelos quais a todos os pacotes enviados será acrescentado um novo cabeçalhoipv6 com um endereço de origem e destino específico configurados neles. A interfaceITunnelCtl define funções para criar e remover túneis, e mudar as configurações de umtúnel disponível.

O recebimento de pacotes com cabeçalho de mobilidade ocorre em um thread se-parado. A interface IMH fornece a função para iniciar o recebimento de pacotes MH.Paralelamente o recebimento de pacotes ICMPv6 ocorre em outro thread e a interfaceIICMPv6 fornece a função para iniciar o recebimento desses pacotes.

5.3.5.2 Sequência de Execução

A função principal inicia a execução do programa, ela inicializa variáveis e estrutu-ras de dados e registra os handlers que serão utilizados. Ela também cria três threads

que são os principais responsáveis pelo funcionamento do aplicativo através do rece-bimento de eventos e chamada de funções para tratá-los, são eles: mh_listener,icmp6_listener e tq_runner. Os dois primeiros iniciam executando as funçõesmh_listen eicmp6_listen respectivamente, que são notificados do recebimentode pacotes dos sockets do Linux e invocam funções através dos handlers. O terceiroinicia executando a função runner, que trata eventos temporais de tarefas na TQ e convocaas funções de callback dessas tarefas. A seguir será descrita a sequência principal deinicialização do programa.

• As variáveis de configuração são inicializadas com os valores indicados no arquivode configuração;

52


• O thread tq_runner é criado, sua sequência de execução é a seguinte:

– Obtém o tempo atual;

– Obtém o primeiro registro da Fila de Tarefas;

– Se o tempo de vencimento desta tarefa for menor que o tempo atual, ou seja,a tarefa já venceu, remove o registro da lista e executa a função de callbackrelacionada ao registro;

– Repete o processo;

• Um socket IPv6 é aberto para envio e recebimento de pacotes com cabeçalho demobilidade;

• O thread mh_listener é criado, sua sequência de execução é a seguinte:

– Aguarda a chegada de um pacote pelo socket aberto anteriormente;

– Verifica o tipo de cabeçalho de mobilidade;

– Obtêm um handler para a mensagem recebida através da interface de handlers;

– Executa a função contida no handler para processamento do pacote;

– Aguarda a chegada de outro pacote e reinicia o processo;

• Um socket ICMPv6 é aberto para envio e recebimento de pacotes ICMPv6;

• É definido um filtro para os pacotes recebidos por esse socket, permitindo apenasdeterminados pacotes em cada modo de operação;

• O thread icmp6_listener é criado, sua sequência de execução é a seguinte:

– Aguarda a chegada de um pacote pelo socket;

– Verifica o tipo da mensagem;

– Obtém um handler para o tipo específico;

– Executa a função contida no handler para processamento do pacote;

– Aguarda a chegada de outro pacote e reinicia o processo;

• São adicionadas políticas de segurança através da interface IXFRM para permitir aentrada e saída de pacotes de sinalização do protocolo;

• Cria um socket IPv6 para gerenciamento de túneis IPv6-IPv6;

53


• Inicializa um dos modos de operação: OMAG;

• Aguarda o recebimento de um sinal para finalizar o programa.

5.3.6 Configuração do PMIPFlow

O PMIPFlow obtêm algumas informações de configuração, como valores de variáveis emodo de operação, de um arquivo de configuração. A seguir são apresentadas as opçõesde configurações utilizadas pelo pmipflow6d.

• NodeConfig: define o modo de funcionamento do aplicativo. No pmipflow6d, seuúnico valor aceitável é "OMAG";

• DebugLevel: quanto maior o valor, mais mensagens de depuração são exibidas.Nenhuma mensagem é exibida se o valor dessa variável é zero. O valor típico, queexibe todas as mensagens, é 10;

• DebugLogFile: define o caminho de um arquivo para escrever as mensagens dedepuração. Por default escreve na saída padrão. Quando em modo de depuração(DebugLevel maior que zero) o aplicativo só executa em modo daemon se essavariável for definida;

• TimestampBasedApproachInUse: o protocolo cita dois modos de ordenação de pa-cotes, através de timestamps, que identificam o momento em que eles foram criadose exige sincronização do tempo entre os nós, e através de números de sequênciacujo mecanismo não foi especificado. A implementação permite ordenação apenaspor timestamps, portanto o valor dessa opção deve ser um, ela foi criada pensandona inclusão da outra funcionalidade no futuro. As opções a seguir são válidasapenas para o modo OMAG:

• OMAGInterfaceLMA-NOX: define a interface pela qual os pacotes destinados aoLMA-NOX devem ser enviados. Recebe como valor uma string com o nome dainterface, por exemplo, "eth0";

• OMAGEgressGlobalAddress: endereço global com que o OMAG se comunica como PMIPFlow-LMA, também chamado de Proxy CoA;

• FixedOMAGLinkLocalAddress: se definida, essa opção especifica o endereço queserá utilizado por todos os OMAGs no mesmo domínio. Isso é feito para que oMN não precise configurar rotas quando realizar handover. Se esta opção não for

54


especificada, o OMAG receberá o endereço linklocal que usará na comunicaçãocom o MN;

• InitialBindackTimeoutFirstReg e InitialBindackTimeoutReReg: o tempo de esperainicial de um PBA de registro e o tempo de espera inicial de um PBA de atualizaçãode registro. Por default recebem o valor 1 e 1.5 respectivamente. As opções aseguir são válidas apenas no modo PMIPFlow-LMA:

• TimestampValidityWindow: define a janela de validade do timestamp dos PBUsrecebidos, para que o pacote seja aceito seu timestamp deve ser no mínimo o tempoatual menos a janela;

• HaMaxBindingLife: opção herdada do HA define o tempo de vida máximo de umregistro no BC. As opções a seguir configuram o registro de um MN ao serviço demobilidade em um MNPP:

• MNIdentifier: o identificador do MN. Igual a um endereço MAC no formato"AA:AA:AA:AA:AA:AA"entre aspas. As próximas opções são inclusas entreaspas após esta para especificar informações do registro deste MN:

– PMIPFlowEnabled: uma variável boleana que define se o MN está habilitadoao serviço de mobilidade;

– LMA-NOXAddress: o endereço do LMA-NOX que o MN é registrado;

– SupportedConfigurationMode: especifica o tipo de configuração do endereçodo MN por um numero inteiro, por enquanto apenas zero (configuraçãoautomática) está disponível;

– HomeNetworkPrefix: prefixo que será utilizado pelo nó móvel, por enquantoé possível configurar apenas um prefixo por nó móvel;

– PMIPFlowInterface: interface pela qual o nó móvel se conecta a rede, porenquanto apenas uma disponível, mas esta opção será utilizada para múltiplasinterfaces com o mesmo IP.

– HomePrefixLifetime: o tempo de vida dos prefixos registrados pelo MN emsegundos.

5.3.7 Modo de Operação OMAG

O aplicativo pmipflow6d possui dois modos de operação, um para funcionamento comoOMAG e outro como PMIPFlow-LMA. A estrutura do programa e a sequência de

55


execução são as mesmas em ambos os modos, as diferenças estão presentes apenas noprocessamento das mensagens, nas informações das estruturas de dados e nas tarefas daFila de Tarefas (TQ).

Quando executando em modo OMAG, o aplicativo inicializa a BUL, registra handlers

para o recebimento das mensagens RS e ICMPv6 Parameter Problem no socket ICMPv6,libera a entrada dessas mensagens no filtro deste socket e registra um handler pararecebimento de mensagens PBA. A partir daí a chegada de uma dessas mensagensresultará na execução das funções de processamento.

Além disso, a adição de entradas na BUL causa a inclusão de tarefas na TQ pararenovação de registros, reenvio de solicitações de registro e remoção de registros. Aprimeira é tratada pela função de callback pbu_refresh, a segunda pela funçãopbu_resend e a terceira pela função bul_expire.

5.3.7.1 Detecção de Movimento

A detecção de movimento nesta implementação é feita pelo recebimento de uma men-sagem de solicitação de roteador enviada pelo MN para o MAG com o qual ele se liga.Quando a thread icmp6_listener receber uma mensagem tipo RS em um MAG, eleirá repassar para a função mag_recv_router_sol, que a processará e realizará asações necessárias para registro ou atualização de registro para o serviço de mobilidade.

56


5.3.8 Modo de Operação PMIPFlow-LMA

A descrição de implementação apresentada até aqui serve tanto para o OMAG quandopara o PMIPFlow-LMA, porém este último necessita além do descrito acima, de umcódigo especial para fazer dele um componente NOX.

O PMIPFlow-LMA é a entidade mais importante do PMIPFlow, nela reside todaa inteligência da arquitetura, tanto para o gerenciamento de mobilidade quanto parao gerenciamento dos switches OpenFlow. O PMIPFLow-LMA foi desenvolvido combase no código switch.cc que vem junto ao NOX/C++, este código implementa umsimples switch como componente do NOX. O trecho de código mostrado em 5.1 mostrao cabeçalho da classe PMIPFlow-LMA. Essa classe herda, como todo componente doNOX, da classe Component.

No trecho de código 5.1, são exibidas algumas funções importantes para implemen-tação do componente NOX PMIPFlow-LMA. A seguir a explicação dos aspectos maisimportantes do código 5.1. A versão completa do código está descrita no Apêndice B.

namespace pmipflow_lma

{ Vlog_module l g ( " PMIPFlow−lma " ) ;

c l a s s PMIPFlow : p u b l i c Component

{ LMA *lma ;

p u b l i c :

PMIPFlow ( c o n s t Componen t_con tex t * c )

: Component ( c ) { s e t u p _ f l o w s = t rue ; }

void pmipflow−l m a _ c a l l b a c k ( auto& dp , ofp_match f low ) ;

void c o n f i g u r e ( ) ;

void i n s t a l l ( ) { }

D i s p o s i t i o n h a n d l e _ d a t a p a t h _ j o i n ( c o n s t Event &);

D i s p o s i t i o n h a n d l e _ d a t a p a t h _ l e a v e ( c o n s t Event &);

D i s p o s i t i o n h a n d l e _ p a c k e t _ i n ( c o n s t Event &);

Exemplo de código 5.1: pmipflow-lma.cc

A Seguir a explicação das principais funções apresentadas em 5.1

• handler_packet_in (linha 16): Essa função é chamada toda vez queum pacote entra no switch, nela é executada a função que liga o componente àimplementação do lma, chamada pmipflow-lma_connect.

57


• handler_datapath_leave (linha 15): Essa função é chamada todavez que um novo datapath (switch) sai da rede ou deixa o controlador.

• handler_datapath_join (linha 14): Ao contrário da função anterior,esse é chamada quando um datapath (switch) se conecta ao componente.

• pmipflow-lma_callback (linha 11): Esta é uma função callback e éenviada junto com a função pmipflow-lma_connect para callback, ela instalafluxos e grava os MACs dos pacotes que chegam na rede. Esta função faz todo ogerenciamento de mobilidade, atualizando o BC e criando pacotes PBA de resposta.


Nesta seção foi tratada a teoria por trás do PMIPFlow, as entidades que compõem oframework e como elas trocam mensagens durante o processo de conexão e no handover,a implementação da proposta no Linux e as estruturas de dados utilizadas, a detecçãode movimento da proposta e os modos de operação. No Capítulo 7, será apresentadomais detalhes sobre a implementação da arquitetura PMIPFlow e como o protótipo daarquitetura foi desenvolvido.

58

6Proposta de Antecipação de Handover

"Ao lado de todo grande homem,

sempre existe uma grande mulher"

—DESCONHECIDO

As RFCs de protocolos de gerenciamento de mobilidade não padronizam o gatilhode início do procedimento de handover, ou seja, a inteligência desse gatilho fica porconta de alguma proposta a ser implementada junto com a arquitetura, o mesmo valepara o PMIPFlow. Melhorar latência, ou seja, reduzir o tempo do processo de handover

é crucial em serviços multimídia de tempo real, pois quebras de conexão e perdas depacotes podem gerar degradações.

Dessa forma, além da contribuição da arquitetura PMIPFlow, propõe-se, também, umasolução baseada em lógica fuzzy para antecipar o mecanismo de handover da arquiteturaPMIPFlow e reduzir de forma proativa o atraso desse processo, fazendo com que eleseja realizado de forma transparente ao usuário e ao serviço corrente, minimizando asperdas de pacotes devido possíveis quebras de conexão. Nesse e em todos os outrosCapítulos, "PMIPFlow(Fuzzy)"fará referência à arquitetura PMIPFlow com a propostade antecipação Fuzzy.

Este capítulo está organizado da seguinte forma. A seção 6.1 apresenta os conceitospor trás da proposta de antecipação de handover para arquitetura PMIPFlow, nesta seçãoé apresentada a representação esquemática do PMIPFlow(Fuzzy). Em seguida, na seção6.2, é apresentada as variáveis de entrada do sistema, nessa seção é descrito como cadavariável. A formação dos conjuntos fuzzy, os quais servirão como motor de inferência,são apresentado na seção 6.3, para cada variável de entrada existe um conjunto fuzzy eem todo sistema existe uma saída, ao todo são formados vinte e sete regras de inferência.

59

CAPÍTULO 6. PROPOSTA DE ANTECIPAÇÃO DE HANDOVER

A última seção conclui este Capítulo.

6.1 Sistema PMIPFlow(Fuzzy)

Diferentemente da lógica tradicional, que utiliza valores exatos, a lógica fuzzy é umsistema capaz de trabalhar com informações imprecisas e transformá-las em uma lingua-gem matemática de fácil implementação computacional. Ele é uma ferramenta bastanteutilizada em sistemas que precisam de uma tomada de decisão baseado em variáveisimprecisas. A seguir, algumas vantagens da utilização da lógica fuzzy (?).

• É bastante usado para tomadas de decisão;

• Reduz o tempo de desenvolvimento;

• Capacidade de operar com dados imprecisos;

• Pode ser utilizado para modelar funções não lineares e complexas.

• Sistemas avançados precisam de menos chips e sensores (menos estruturas decontrole);

• Implementável facilmente em microcontroladores, como sistemas de máquinasfotográficas, máquina de lavar roupas, freios ABS, ar condicionado e etc.

• É também usado em seleção de redes sem fio;

Um sistema fuzzy é constituído pela processo de fuzzificação, que traduz as variáveisde entrada em conjuntos fuzzy. Pela inferência, que realiza o raciocínio fuzzy com baseem um sistema de regras que relaciona as variáveis de entrada com as de saída. E peladefuzzificação, que é a tradução da saída num valor numérico.

A Figura 6.1 apresenta o esquema da proposta PMIPFlow(Fuzzy), a seguir cada blococonstrutor da arquitetura será explicado com mais detalhes.

• Sistema de Monitoramento: Este módulo de software é responsável por executaro monitoramento das variáveis utilizadas como entrada para o sistema fuzzy. Elelê as variáveis de arquivos de logs e separa as informações necessárias. Essasvariáveis fornecem dados numéricos que irão alimentar o sistema. Através dessesvalores, o sistema irá se basear para tomar as decisões. As entradas utilizadas paraproposta PMIPFlow(Fuzzy) são: Vazão, RTT (Round Trip Time) e RSS (Received

Signal Strength ou Intensidade do Sinal Recebido).

60

6.1. SISTEMA PMIPFLOW(FUZZY)

FuzificadorMotor de Inferência

Defuzzificador

Base de Connhecimento

Base de Regras

Funções de Pertinência

Vazão

RTT

Intensidade do Sinal

Saída

Sistema de Monitoramento

Sistema de Tomada de

Decisão

Ping6

Iptraf

iwconfig

Logs

Figura 6.1: Representação do Sistema Fuzzy

• Logs: As variáveis de interesse são colocadas em arquivos de logs para serem lidaspelo Sistema de Monitoramento. Várias ferramentas são utilizadas para recuperaras informações do dispositivo do usuário são elas ping6, iptraf e iwconfig.

• Fuzzificador: Nessa etapa as entradas não fuzzy ou precisas são apresentadasao sistema por intermédio de medições ou observações de dados, os quais sãoconsiderados como sendo o conjunto de dados de entrada do sistema. Deste modo,é necessário efetuar um mapeamento desses dados de entrada para o conjunto fuzzy,de tal forma, que o sistema possa identificar a quais variáveis linguísticas essesdados pertencem e o quanto os mesmos são pertinentes a essas variáveis. Nestafase também ocorre à ativação das regras fuzzy relevantes para um dado sistema;

• Base de Conhecimento: Formada por uma Base de Regras e de Dados (Funçõesde Pertinência). As regras podem ser fornecidas por especialistas, com base emseu conhecimento a respeito do processo que se deseja analisar, em forma desentenças linguísticas, e se constituem em um aspecto fundamental no desempenhode um sistema de inferência fuzzy. Desta forma, o sistema de inferência fuzzy

terá um desempenho confiável e satisfatório, somente se, as regras expressarem ocomportamento do sistema de forma fiel e consistente. Entretanto, a extração deum conjunto de regras advindas do conhecimento desses especialistas pode não seruma tarefa fácil, por mais que os mesmos conheçam profundamente o problemaque se deseja analisar. Portanto, existem alternativas ao uso do conhecimento dosespecialistas para a definição da base de regras, tais como os métodos de extraçãode regras a partir de dados numéricos. Esses métodos são particularmente úteis em

61


aplicações onde haja disponível um conjunto de dados numéricos que refletem ocomportamento entrada/saída do sistema;

• Motor de Inferência: No processo de inferência ocorrem as operações comos conjuntos fuzzy. Um aspecto importante é a definição dos conjuntos fuzzy

correspondentes às variáveis de entrada e às de saída, pois o desempenho do sistemade inferência dependerá do número de conjuntos e de sua forma adotada. É possívelefetuar uma sintonia manual das funções de pertinências dos conjuntos, mas émais comum empregarem-se métodos automáticos. A integração entre sistemasde inferências fuzzy e redes neurais artificiais tem se mostrado adequada para asintonização das funções de pertinências, assim como para a geração automáticade regras;

• Defuzzificador: Após o processo de Inferência, tem-se o processo de defuzzifi-cação que, de posse do conjunto fuzzy de saída adquirido através do processo deinferência, é responsável pela interpretação dessa informação para saídas preci-sas (dados não fuzzy). Isto se faz necessário, já que, em aplicações práticas sãorequeridos valores não fuzzy.

• Sistema de Tomada de Decisão: A saída do sistema fuzzy é usada como entradapara o Sistema de Decisão, esse sistema recebe os valores de saída para decidirse o usuário deve fazer handover ou não. Se o sistema decidir pelo handover, oprocesso de handover é imediatamente iniciado.

6.2 Variáveis de Entrada

Como foi dito anteriormente, as entradas utilizadas para o sistema fuzzy são: Vazão, RTT(Round Trip Time) e RSS.

A vazão do tráfego é coletada utilizando-se uma ferramenta chamada IPTraf, estaferramenta é bastante utilizada para monitorar as interfaces de rede de uma máquina, comela é possível saber quantos pacotes entraram em uma determinada interface, quantospacotes saíram e a vazão total das interfaces. Para coletar a vazão, utilizou-se o IPTrafno modo background armazenando o log de coleta em um arquivo, depois o sistema demonitoramento lê esse arquivo e separa as informações necessárias. A Figura 6.2 mostraa saída da ferramenta, dando destaque para o campo onde é apresentada a vazão atual dainterface.

62

6.2. VARIÁVEIS DE ENTRADA

Figura 6.2: Saída da ferramenta IPTraf

O RTT é obtido através de mensagens ICMPv6 enviadas periodicamente, o RTT éobtido através da diferença entre o tempo de envio da mensagem e o tempo de resposta darespectiva mensagem. A ferramenta utilizada para calcular o RTT foi o ping6 (versao ipv6do ping), disponível em todas as plataformas linux. A saída da ferramenta é mostrada naFigura 6.3, dando destaque para as informações de RTT dos pacotes. Assim como noIPTraf, as informações do ping6 são guardadas em um arquivo de log para que o sistemade monitoramento análise.

Figura 6.3: Saída da ferramenta ping6 destacando-se o RTT do pacote

Para se obter o RSS, assim como com o RTT e a vazão também utilizou-se uma

63


ferramente linux chamada iwconfig, essa ferramenta é empregada na configuração deinterfaces sem fio. E com ela é possível verificar o RSS do dispositivo do usuário, assimcomo foi feito com as outras ferramentas, a saída do iwconfig foi colocada em um logpara análise do sistema de monitoramento. A Figura 6.4 mostra a saída da ferramentadestacando o nível de sinal da interface "wlan0".

Figura 6.4: Saida da ferramenta iwconfig

6.3 Conjuntos Fuzzy

É empregado nesta proposta um sistema fuzzy do tipo Mamdani cuja intensidade dedisparo de uma regra de inferência será uma média aritmética dos graus de pertinênciaobtidos. Os conjuntos fuzzy são combinados pela escolha do valor máximo e o defuzzifi-cador utiliza o chamado método centróide sem sobreposição para fornecer a resposta dosistema fuzzy, sendo este o mais utilizado dentre todos os métodos de defuzzificação porconsiderar toda a distribuição de possibilidade do conjunto fuzzy de saída.

No formato dos conjuntos fuzzy sobre cada uma das variáveis de entrada, optou-se porusar funções de pertinência trapezoidais devido a sua fácil compreensão. Cada variávelde entrada possui três conjuntos fuzzy definidos sobre ela. A Figura 6.5 mostra o grau depertinência para a variável RTT, todos os valores mínimos e máximos do conjunto foramdefinidos por meio de métodos empíricos.

A Figura 6.6 mostra o grau de pertinência para a Vazão, os conjuntos estão definidospor meio de porcentagem em relação ao largura de banda da interface de rede. A bandatotal da interface é obtida através de um teste de capacidade explicado na Seção 8.3.Definiu-se que a partir de aproximadamente 60% da capacidade total da interface éconsiderada uma vazão alta, em 50% uma vazão média e abaixo de 40% uma vazão baixa.

O RSS indica que o terminal pode estar perto ou longe do ponto de acesso e, quantomais perto, teoricamente, melhor é a conexão. Porém, quando se trata de serviços

64

6.3. CONJUNTOS FUZZY

RTT (Round Trip Time)

Gra

u d

e P

ert

inê

ncia

1

0

0.5

2 ms 4 ms 6 ms

AltaMédiaBaixa

Figura 6.5: Grau de pertinência para a entrada RTT

Vazão

Gra

u d

e P

ert

inê

ncia 1

0

0.5

25% 50% 75%

AltaMédiaBaixa

Figura 6.6: Grau de pertinência para a entrada Vazão

multimídia, o RSS não é o suficiente para determinar a qualidade da aplicação. Poreste motivo, foram realizados experimentos com o objetivo de determinar os valorescorrespondentes de PSNR, de acordo com o RSS. Assim, considerando um ambienteespecífico, construiu-se a tabela que avalia o PSNR em relação à distância, mapeandoníveis de sinais em valores de PSNR para dar suporte à tomada de decisão de handover.Esse mapeamento é posteriormente utilizado para construção do grau de pertinência parao RSS.

Para criar o mapeamento "Nível de Sinal"versus "PSNR"realizou-se o seguinte experi-mento. Enviou-se o arquivo de vídeo do PMIPFlow-LMA para o MN, portanto no sentidodownlink. Essa transmissão foi realizada variando-se a distância do MN em relação aoOMAG. Cada variação na transmissão foi executada 10 vezes. Ao final das transmis-sões, o arquivo de vídeo foi avaliado em termos de PSNR para a montagem da tabelaPSNR/Distância. Em paralelo, o nível de sinal foi capturado durante toda a transmissão.A Tabela 6.1 mostra a média dos valores coletados durante esse tempo, considerando umintervalo de confiança de 95%. Vale ressaltar que o resultado destes experimentos refleteo ambiente e a configuração dos dispositivos utilizados, outros equipamentos ou outrosambientes podem fornecer resultados distintos dos apresentados na Tabela 6.1.

A partir dos resultados obtidos e da análise dos vídeos no receptor, percebe-se,segundo as Tabelas 6.1 e 6.2, que, para um nível de sinal de -79,98 dbm (15 Metros), ovídeo é avaliado como BOM (31.27dBm), porém com um nível de sinal em -88,20 dbm

65


Tabela 6.1: Resultados do Experimento PSNR/Distância

Distância OMAG/MN (m) < 1 5 10 15 20Média do Nível do Sinal (dbm) -66.76 -73.76 -78.61 -79.98 -88.20

PSNR(dB) 32.77 32.77 31.60 31.27 27.22

Perda (%) 0 0 0.05 2.45 8.35

(20 metros) o vídeo recebido torna-se ACEITÁVEL.Tabela 6.2: Valores de Classificação do PSNR

PSNR (dB) > 37 31 – 37 25 – 30 20 – 25 < 20

Qualidade Excelente Bom Aceitável Pobre Péssimo

A partir das informações obtidas no mapeamento PSNR/Distância construiu-se oconjunto fuzzy para a variável de entrada RSS, a Figura 6.7 mostra o grau de pertinênciapara este conjunto. Para manter a qualidade do vídeo em um nível "BOM", segundoa Tabela 6.2, é necessario que o PSNR esteja em torno de 31dB e portanto, segundo omapeamento, o RSS do dispositivo móvel precisa estar abaixo de "-80dBm".

Intensidade do Sinal

Gra

u d

e P

ert

inê

ncia 1

0

0.5

-65dBm -75 dBm-70dBm -80 dBm -85 dBm

BaixaMédiaAlta

Figura 6.7: Grau de pertinência para a entrada RSS

Após processar toda a entrada o sistema fuzzy gera uma saída. A Figura 6.8 mostra ograu de pertinência para a saída. A saída como mostrado na Figura é um número de 0 à 1,a saída do sistema é somente esse número, a partir desse número quem vai tomar a decisãoé o sistema de decisão da arquitetura PMIPFlow(Fuzzy), nele, se a saída for menor que0.3, o sistema não faz nada e entra em estado de espera até o próximo monitoramento,se a saída for entre 0.3 e 0.6, o sistema entra em estado de alerta e o monitoramentoé intensificado tentando prever uma possível handover, se a saída for acima de 0.6 ohandover o sistema inicia o processo de forma antecipada tentando previnir o usuário dequebras em seus conexões ativas.

Optou-se por utilizar apenas estas três variáveis (RTT, Vazão e RSS) porque quantomaior o número de variáveis mais complexo fica o sistema fuzzy. Se este sistema se tornarcomplexo, pode haver um grande sobrecarga na rede tornando o sistema inviável. Vale

66

6.4. CONCLUSÃO

Saída

Gra

u d

e P

ert

inê

ncia

1

0

0.5

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SIMNÃO ALERTA

Figura 6.8: Saída do Sistema Fuzzy

salientar que a quantidade de regras é diretamente proporcional a quantidade de variáveislinguísticas e termos linguísticos. Se um sistema possuir três variáveis linguísticas, comoé o caso deste trabalho, e três termos linguísticos, como baixa, média e alta, tem-seportanto 33 = 27 regras na base de conhecimento. A Tabela 6.3 mostra as regras deInferência criadas para o PMIPFlow(Fuzzy).

O sistema PMIPFlow(Fuzzy) foi desenvolvido em C++ e roda em segundo planono dispositivo do usuário, seguindo o conceito ABC (Always Best Connected), ondeo dispositivo do usuário é quem decide a qual rede ele deseja estar conectado. Otempo de monitoramento foi definido para cada 10 segundos de execução e no modoALERTA esse tempo cai para 1 segundo. Os sistema possui um arquivo de configuração,pmipflow_fuzzy.conf, onde o usuário pode modificar alguns parâmetros como otempo de execução do monitoramento e no modo ALERTA, porém os valores escolhidoscomo padrão (10s e 1s, monitoramento e alerta, respectivamente) se mostraram bastanteadequados nos testes empíricos. No Capítulo 8, a proposta PMIPFlow(Fuzzy) foi avaliadae os resultados mostraram sua eficácia.

6.4 Conclusão

Neste Capítulo foi apresentada a proposta PMIPFlow(Fuzzy) que usa a lógica fuzzy paraantecipar o processo de handover e melhorar a latência, com isso, criando uma arquiteturaque além de fornecer o gerenciamento de mobilidade em redes SDN, o faz de formarápida e eficiente. Nos sistema PMIPFlow(Fuzzy) para cada entrada de cada variável(RTT,Vazão e RSS) existe uma saída, que pode ser "não faz handover", "se mantém emalerta"e "faz handover". As avaliações do PMIPFlow(Fuzzy), apresentada no Capítulo 8,mostrarão os benefícios da proposta.

67


Tabela 6.3: Regras de Inferência

Regra Sinal RTT Vazão Saída

1 ALTA BAIXA BAIXA NÃO

2 ALTA BAIXA MÉDIA NÃO

3 ALTA BAIXA ALTA NÃO

4 ALTA MÉDIA BAIXA ALERTA

5 ALTA MÉDIA MÉDIA ALERTA

6 ALTA MÉDIA ALTA ALERTA

7 ALTA ALTA BAIXA SIM

8 ALTA ALTA MÉDIA SIM

9 ALTA ALTA ALTA SIM

10 MÉDIA BAIXA BAIXA NÃO

11 MÉDIA BAIXA MÉDIA NÃO

12 MÉDIA BAIXA ALTA ALERTA

13 MÉDIA MÉDIA BAIXA ALERTA

14 MÉDIA MÉDIA MÉDIA ALERTA

15 MÉDIA MÉDIA ALTA SIM

16 MÉDIA ALTA BAIXA SIM

17 MÉDIA ALTA MÉDIA SIM

18 MÉDIA ALTA ALTA SIM

19 BAIXA BAIXA BAIXA ALERTA

20 BAIXA BAIXA MÉDIA ALERTA

21 BAIXA BAIXA ALTA ALERTA

22 BAIXA MÉDIA BAIXA SIM

23 BAIXA MÉDIA MÉDIA SIM

24 BAIXA MÉDIA ALTA SIM

25 BAIXA ALTA BAIXA SIM

26 BAIXA ALTA MÉDIA SIM

27 BAIXA ALTA ALTA SIM

68

7Protótipo

A mente que se abre a uma nova ideia

jamais voltará ao seu tamanho original.

—ALBERT EINSTEIN

A arquitetura PMIPFlow foi avaliada em um testbed IEEE 802.11, utilizando umainfraestrutura que mistura equipamentos físicos e sistemas virtualizados. Para tal, várioscomponentes precisaram ser estudados e implementados. Este capítulo foi reservado paraexplicar com mais detalhes como foi montado o testbed da arquitetura PMIPFlow e comoalgumas das entidades mais importantes foram desenvolvidas.

O Capítulo mostra as entidade que compõem a arquitetura PMIPFlow. Nesta seção,serão explicadas em detalhes cada entidade, como elas estão posicionadas na arquiteturae como foram implementadas. Nesse capítulo serão mostradas várias imagens, comocapturas de telas dos componentes em execução, do rack utilizado no testbed e doambiente onde foram realizadas os testes.

7.1 Entidades

A maioria das entidades da arquitetura OpenFlow já foram discutidas anteriormente notexto. A Figura 7.1 mostra a arquitetura do PMIPFlow com destaque para as entidadesmais importantes que podem ser identificadas pela numeração correspondente.

1. OMAG (Openflow Mobility Access Gateway)

2. Gateway OpenFlow

3. Switch OpenFlow (Indigo)

69

CAPÍTULO 7. PROTÓTIPO

LMA-NOXSwitch Pronto 3290

(Indigo)

Virtual Switch

(Openflow Gateway)

Virtual Switch

(Openflow Gateway)

OMAG (Openflow

Mobility Access Gateway)

MN (Mobile Node)

Handover

Servidor de

Streaming

NOX_Bob

NOX_AliceFlowVisor

(PMIPFLow-LMA)

Domínio

PMIPFlowDomínio

PMIPFlow

OMAG (Openflow

Mobility Access Gateway)

1

2

3

4

5

6

7MN (Mobile Node)

Figura 7.1: Entidades de prototipação da arquitetura PMIPFlow

4. FlowVisor

5. LMA-NOX/PMIPFlow-LMA

6. CN/VideoStream Server

7. MN (Mobile Node) ou Usuário Móvel

As próximas subseções explicarão cada entidade em detalhe incluindo como foramdesenvolvidas, que tecnologias foram utilizadas e como se integraram na arquitetura.

7.1.1 OMAG (OpenFlow MAG)

O OMAG é uma implementação modificada do MAG criada pelo autor desta dissertação epublicada em (Avelar et al., 2011). Esta implementação foi adaptada para as distribuiçõesmais atuais do Ubuntu (12.04 e 12.10). Para tal, utilizou-se a linguagem C++ comcompilador gcc/g++ 4.6 e 4.7.

Para os OMAG foram utilizados PCs Intel Core i5 com 3.20Ghz de clock, 3GB deRAM rodando o sistema Ubuntu 12.10. utilizando-se placa de rede wireless PCI Tp-linkTl-wn350gd de 54Mbps. Esta placa, Figura 7.2, possui o chipset ATHEROS com potência

70

7.1. ENTIDADES

de transmissão de 18dBm/63mW que permite a modificação, no Ubuntu, da placa para omodo Master. Isto permite que a placa opere como um ponto de acesso.

Figura 7.2: Placa Sem-Fio PCI TP-Link

Para transformar a placa TP-Link,7.2, em modo AP no Ubuntu, utilizou-se um scriptdesenvolvido especialmente para o PMIPFlow. Este script executa um aplicativo chamado(Hostapd, 2013), descrito no Apêndice B e utilizado para inicializar a interface sem fiodo OMAG em modo AP.

Os OMAGs foram implementados em máquinas físicas. A Figura 7.3 mostra a partedianteira e traseira de uma delas. É possível visualizar as placas sem fio TP-LINKinstaladas em um slot PCI. Nas máquinas são utilizados o sistema operacional Ubuntu12.04, e além do HOSTAPD, é usado um cliente/servidor NTP (Network Time Protocol)para sincronização de relógio entre os MAGs e o LMA-NOX. No Apêndice A.2 podemser encontradas mais informações sobre o funcionamento do NTP.

Figura 7.3: Máquina Física onde são instalados os OMAGs

Os scripts mencionados anteriormente, apesar de importantes, são apenas de apoio.

71


O script que executa, de fato, o OMAG (PMIPFlow_Setup.sh) está descrito, emdetalhes, no Apêndice A.4. Esse script configura os endereços, levanta interfaces, chamaoutros scripts como o ntpdate.sh e após tudo configurado ele executa outro scriptchamado PMIPFlow_Init.sh. O PMIPFlow_Init.sh executa a implementaçãodo PMIPFlow em C++ (pmipflow6d discutido em 5.3). O pmipflow6d no modo OMAG,roda em background em uma instância do aplicativo SCREEN, que cria telas virtuais embackground para análises posteriores.

7.1.2 Gateway OpenFlow

Os gateways PMIPFlow, o servidor de vídeo, o FlowVisor e o LMA-NOX foram imple-mentados através de máquinas virtuais em um hypervisor para que o cenário pudesseser heterogêneo em termos de sistemas operacionais, quantidade de interfaces de redede um host, memória RAM e etc. Neste caso, foram instaladas as versões gratuitasdo VMware vSphere Hypervisor (ESXi), (VMware, 2012), em três servidores. Umservidor torre com duas interfaces Gigabit Ethernet usada para os controladores da redeOpenFlow (LMA-NOX/Flowvisor) e dois servidores do tipo blade para clientes, servidorde streaming e Gateways PMIPFlow. Cada um dos servidores blade possui quatro portasgigabit Ethernet mais duas placas Multigigabit Ethernet de quatro portas totalizando dozeinterfaces de rede cada um.

A Figura 7.4 mostra o Rack, onde foram montados os servidores, switches, nobreak,enfim, todos os equipamentos necessários para o núcleo SDN da arquitetura PMIPFlow.

Na proposta, optou-se por utilizar Gateways OpenFlow em cada rede do domínioOMAG, embora o PMIPFlow não exija os Gateways, a utilização deles adiciona um pontoextra de gerenciamento na rede, com a possibilidade de criação de slices dentro de cadadomínio, o que abre muitas possibilidades de extensão e de criação de serviços móveis naarquitetura. Os gateways PMIPFlow são formados por switches virtuais implementadosem máquinas virtuais rodando o Ubuntu 12.04 Server, foi utilizada a implementaçãode referência do OpenFlow para Ubuntu disponível em (Stanford, 2012), mais detalhessobre o script de execução dos gateways PMIPFlow no Apêndice A.5.

Existem algumas implementações do OpenFlow disponíveis. Para implementar osGateways Openflow optou-se por utilizar a implementação de referência da universidadede Stanford, (Stanford, 2012). Basicamente, existem dois tipos de implementações feitaspor Stanford. Uma no espaço do Kernel, que é a mais otimizada, possui maior desempe-nho, porém é mais difícil implementar/depurar, e outra no espaço do usuário que é maissimples, porém mais lenta e de menor desempenho. Optou-se por utilizar o OpenFlow no

72

7.1. ENTIDADES

Switch Pronto 3290

Switch Ethernet - 3COM

Servidor IBM Torre

Servidor IBM Blade 1

Servidor IBM Blade 2

NoBreak

(NOX/PMIPFlow-LMA,FlowVisor)

(Gateways OpenFlow)

(Clientes, CN e Servidor de Streaming )

(Indigo – OpenFlow para Switches )

Patch Panel

Figura 7.4: Rack do núcleo do testbed

espaço do usuário pelas facilidades supracitadas e também pela simplicidade na comuni-cação com outros programas que também residem no espaço do usuário, como o NOX eo FlowVisor. Para trabalhos futuros, pretende-se utilizar a implementação de referênciado OpenFlow no espaço do Kernel.

A Figura 7.5 mostra a interface do gateway PMIPFlow no hypervisor vSphere, nestaFigura é possível perceber que o gateway não possui interface gráfica (Ubuntu Server),isso para otimizar ainda mais seu desempenho. No lado esquerdo da Figura 7.5, é possívelver que existem várias outras máquinas virtuais, clientes multimídia, e um monitorpara realizar medições de dados do servidor. Nesta máquina, o Gateway OpenFlowdo domínio do OMAG1 esta instalado na máquina de nome OpenflowSwitch001 e dodomínio OMAG2 em OpenflowSwitch002.

73


Figura 7.5: Visão do Gateway OpenFlow no Hypervisor vSphere

7.1.3 Switch OpenFlow (Indigo)

Para o firmware do switch OpenFlow físico, ver Figura 7.4, optou-se por utilizar a extensãoIndigo (OpenFlowHub.org, 2012). O Indigo é um sistema operacional que implementa oOpenFlow em switches. Ele suporta altas taxas de dados e até 48 portas de 10-Gigabit. Eleé baseado na implementação de referência do OpenFlow feita por Stanford e atualmenteimplementa todas as características requeridas pelo padrão OpenFlow 1.0. O Indigo jáfoi utilizado com sucesso em vários switches, incluindo os da família Pronto 3290, 3780,3240/Quanta LB4G, da família Netgear GSM7328SO e GSM735SO e alguns da famíliaBroadcom. A Figura 7.6 mostra a interface web de configuração do Indigo/PMIPFlow.

Figura 7.6: Interface WEB de configuração do Indigo/PMIPFlow

O IODS (Indigo Open Development System) é uma máquina virtual que contém todo

74

7.1. ENTIDADES

o código fonte do Indigo, é possível modificar o código, adicionar outras funcionalidades,criar uma nova imagem e inserir esta nova imagem no switch, transformando-o em umswitch OpenFlow. O Indigo também possui uma interface web de configuração, para queo gerenciamento possa ser feito através de um navegador de internet. A Figura 7.6 mostraa interface web do Indigo PMIPFlow.

7.1.4 FlowVisor

Como foi discutido na Seção 3.5, este controlador especial cria várias redes virtuaisem cima de uma rede OpenFlow física. O comando abaixo é usado para inicializar oFlowVisor.

$flowvisor /usr/local/etc/flowvisor/flowvisor-config.xml

Após a inicialização é possível criar um slice de modo simples através do comando:

$fvctl createSlice <nome do slice> tcp:<IP do controlador>:

<porta do controlador> <seu e-mail>

Embora a fatia defina um controlador para uma partição de rede, ela não defineas regras correspondentes para a sua fatia. Assim, é preciso criar regras chamadas deFlowSpace (ou espaço de fluxo), o comando abaixo cria as regras para um determinadoslice.

$fvctl addFlowSpace <datapath id> <prioridade>

<flow> "Slice:<nome do slice>=<ações>"

Um exemplo de regra utilizada na arquitetura PMIPFlow.

fvctl addFlowSpace all 10 dl_src=00:00:00:00:00:01

"Slice:PMIPFlow_VIDEO=7"

Este comando cria uma regra aplicável à todos os datapaths ("all") com prioridade 10que diz que os fluxos com mac de origem 00:00:00:00:00:01 pertencem ao slicePMIPFlow_VIDEO, o 7 representa a soma de todas as permissões (1 = delegar, 2 = lere 4 = escrever) do slice em relação ao espaço de fluxo (FlowSpace).

7.1.5 LMA-NOX/PMIPFlow-LMA

O PMIPFlow-LMA roda dentro do LMA-NOX, que é o controlador do PMIPFlow. AImplementação desse módulo foi explicado na Seção 5.3.8, é possível ver uma parte docódigo fonte desse módulo no Apêndice A.6.

Dentro do controlador LMA-NOX, O código necessário para rodar o PMIPFlow-LMAesta descriminado abaixo:

75


$./nox_core -v -i ptcp:6633 pmipflow_lma

A Figura 7.7 mostra a execução do componente pmipflow_lma no LMA-NOX,nessa Figura é possível verificar o pmipflow_lma, na mensagem 56, registra os switch,exibindo a mensagem "Registrando novo switch", e instala fluxos no switch OpenFlow,na mensagem 67, "Instalando fluxo para ....".

Figura 7.7: PMIPFlow-LMA executando no NOX

7.1.6 CN/Servidor de Streamming de Video

No protótipo implentado o papel do nó correspondente (CN) é desempenhado por umservidor de vídeo streaming. Dessa forma, será possível avaliar o suporte do PMIPFlowaos requisitos de QoS e QoE para tráfego de vídeo.

Para implementar o servidor de vídeo foi utilizada uma máquina virtual dentro doServidor IBM Blade 2, ver Figura 7.4, essa máquina virtual possui 2GB de memóriaRAM dedicada, 30 GB de HD, com 15GB livres rodando o sistema operacional Xubuntu11.10. A Figura 7.8 mostra a tela do servidor de streaming rodando o video que estásendo disponibilizado aos usuários.

O vídeo é enviado ao usuário de modo unicast, e o servidor de streaming é imple-mentado utilizando o aplicativo VLC (Video LAN), em sua versão 2.0 A configuraçãodo servidor é feita através da interface gráfica do VLC, a Figura 7.9, mostra o úl-timo passo da configuração, depois de ter escolhido o vídeo o qual será transmitido.O protocolo utilizado na transmissão é o RTP (Real Time Protocol), o IP do MN é

76

7.1. ENTIDADES

Figura 7.8: Printscreen do Servidor de Vídeo (CN)

2001:1:1:1:4A6D:60FF:FEE7:D26B e o codec utilizado é o H.264.

Figura 7.9: Criando um Servidor de Video no VLC

Para executar o vídeo no cliente, MN na arquitetura PMIPFlow, basta digitar ocomando:

$vlc -vvv --ipv6 rtp://@

O comando acima, executa o vídeo recebido do servidor, se for necessário salvar ovídeo em um arquivo chamado avengers.mp4, o comando a ser usado é:

vlc --vvv --ipv6 rtp://@ --sout file/ts:avengers.mp4

7.1.7 Mobile Node

Para o dispositivo do usuário foi utilizado um notebook ASUS, Core i5 com 2GB dememória e 300 GB de HD rodando o Ubuntu 12.10. Como foi mencionado anteriormente,

77


para utilizar o protocolo PMIPFlow não é necessário nenhuma modificação no dispositivodo usuário, a única exigência é que o dispositivo esteja com o IPv6 habilitado.

7.1.8 Ambiente de Testes

O ambiente de testes da arquitetura PMIPFlow está localizado no Centro de Informática,no campus da UFPE (Universidade Federal de Pernambuco). Ele consiste basicamentede um laboratório dimensões 9mx6m. a Figura 7.10 mostra mais detalhes do laboratório.Todos os testes apresentados nesse trabalho foram feitos nesse ambiente e os resultadosrefletem as características físicas do mesmo, pois a disposição de móveis e obstáculospodem interferir diretamente na comunicação de tecnologias sem fio. Mais detalhes sobreo ambiente no Capítulo 8.

RackOMAG2Gerente

Figura 7.10: Ambiente de teste


Neste capítulo foi discutido a implementação do protótipo da arquitetura PMIPFlowonde foram destacadas as entidades mais importantes e como elas foram desenvolvidas.Várias ilustrações foram apresentadas mostrando o Rack onde foram implantadas asmáquinas virtuais, as máquinas que serviram como OMAG e algumas capturas de teladas ferramentas em execução. Serão fornecidas mais informações sobre o ambiente deteste no Capítulo 8. O próximo capítulo será reservado para apresentar a proposta deantecipação de handover para arquitetura PMIPFlow.

78

8Avaliação

O homem superior atribui a culpa a si próprio.

O homem comum aos outros.

—CONFÚCIO

A avaliação do PMIPFlow foi conduzida em um testbed IEEE 802.11 e foram reali-zadas comparações entre o esquema original PMIPFlow e a proposta de antecipação dehandover.

O capítulo esta organizado da seguinte forma. A seção 8.1, descreve o ambiente deteste. A seção 8.2, apresenta a metodologia utilizada nos testes. Antes da avaliação daproposta, é apresentado, na seção 8.3, um teste de capacidade para avaliar a quantidadede tráfego suportado pela rede. A proposta PMIPFlow(Fuzzy) foi avaliada em termosde qualidade de serviço e qualidade de experiência, na seção 8.4, são apresentados osresultados para QoS e na seção 8.5 para QoE.

8.1 Ambiente de Teste

O ambiente onde os testes da arquitetura PMIPFlow foram realizados será discutido nestaseção. Entender a organização do ambiente é crucial para compreender os resultadosdos testes, uma vez que a disposição dos móveis, das paredes e dos pontos de acessoinfluenciam diretamente na distribuição do sinal sem fio no ambiente. A Figura 8.1 exibea planta baixa laboratório no qual os testes foram executados.

Nessa Figura, é possível verificar que o ambiente de testes é de uma sala de seispor nove metros, contendo um conjunto de quinze baias. No canto inferior direito, estádisposto o Rack onde foram instalados os switches OpenFlow, Servidores Blade/Torre etc.,para mais detalhes ver Figura 7.4. O ambiente possui ainda um servidor de gerenciamento

79

CAPÍTULO 8. AVALIAÇÃO

OMAG1

Rack

Baias

9,00m

6,0

0m

Central de Gerenciamento

OMAG2

Figura 8.1: Planta baixa do ambiente de teste

físico para monitorar e gerenciar todas as máquinas virtuais. A Figura mostra também, adisposição dos pontos de acesso da rede sem fio, o OMAG1 disposto no canto superioresquerdo e o OMAG2 no canto inferior direito.

Outra informação importante sobre o ambiente de teste é a intensidade do sinalno cenário. A Figura 8.2 exibe essa informação para o OMAG1. Este mapeamento foirealizado a partir da coleta de nove pontos distribuídos pelo ambiente. Como o laboratórionão é um ambiente amplo, foi necessário diminuir a potência de transmissão das antenaspara diminuir o raio de ação de cada rede e poder testar a proposta.

Intensidade do Sinal (dBm)

- 60

- 79

- 85

- 90

Figura 8.2: Mapeamento da intensidade do sinal no ambiente de teste para o OMAG1

A Figura 8.3 ilustra o mapeamento do nível de sinal para o OMAG2. Tanto nessaFigura quando na anterior é possível ver que mais próximo dos OMAGs a força do sinalestá em torno de -60dBm e mais distante é maior que -90dBm.

80

8.2. METODOLOGIA



- 60

- 79

- 85

- 90

Figura 8.3: Mapeamento da intensidade do sinal no ambiente de teste para o OMAG2

8.2 Metodologia

Como não existe, na literatura, arquitetura similar à solução definida nesta dissertação, aproposta PMIPFlow(fuzzy) foi comparada com o PMIPFlow sem a proposta. Como aarquitetura gira em torno de gerenciamento de mobilidade, a avaliação foi feita focando-senos handovers.

Para avaliarmos desconexões de rede dentro do ambiente sem fio, foi necessáriomover-se pelo ambiente de teste à pé, com velocidade de aproximadamente um metro porsegundo (equivalente à uma pessoa caminhando), para forçar a desconexão de uma rede ereconexão em outra. O padrão de movimentação do usuário móvel, dentro do ambientede teste, é apresentado na Figura 8.4. Os pontos onde os testes começavam, o trafego éiniciado, são totalmente aleatórios, porém a partir do ponto de início, o usuário se moviade acordo com as setas apresentadas na nessa Figura 8.4. Desta forma, nenhuma daspropostas se beneficiaria de possíveis repetições acidentais da posição do usuário.

8.3 Teste de Capacidade

Para analisar a arquitetura PMIPFlow em termos de tráfego, foi realizado um testede capacidade. Este consiste em quantificar o volume de tráfego que a rede suporta.Basicamente é enviada uma quantidade de fluxo sintético pela rede variando-se a taxa deenvio. Foi utilizado a ferramenta IPERF,(NLANR/DAST, 2013), para gerar e enviar ofluxo de dados. Para estressar ao máximo a rede, foi gerado um fluxo UDP que variou de1Mbps a 30Mbps.

A Figura 8.5 mostra o resultado do teste de capacidade, nesta Figura é possívelverificar que apesar da tentativa de enviar um fluxo superior à 20 Mbps, a capacidade

81


OMAG1 Central de Gerenciamento

OMAG2Movimentação do MN

Figura 8.4: Movimentação do MN no ambiente de teste

máxima da rede gira em torno de 17 Mbps. Esse valor pode ser explicado de duasformas, a primeira é que, geralmente, a taxa de transmissão real dos equipamentoscomercializados são inferiores a especificada no padrão e a segunda é a interferênciacausada pelo número de redes sem fio ao redor do ambiente de teste, apesar da precauçãoem utilizar o canal mais livre.

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 300

3

6

9

12

15

1820

Teste de Vazão

Vazão testada (Mbits/s)

Vaz

ão R

eal (

Mbi

ts/s

)

Figura 8.5: Teste de capacidade da rede sem fio

82

8.4. AVALIAÇÃO DE QUALIDADE DE SERVIÇO

8.4 Avaliação de Qualidade de Serviço

A avaliação de desempenho de um sistema de rede é realizadas de duas formas, através deanálise de métricas de QoS (Quality of Service) retiradas da rede, como perdas de pacotes,vazão e jitter ou através de métricas objetivas de QoE (Quality of Experience), comoPSNR (Peak Signal to Noise Ratio) e SSIM (Structural Similarity Index). A propostaPMIPFlow(Fuzzy) será avaliada utilizando os dois conjuntos de métricas.

Uma das métricas importantes para avaliação de QoS é a variação do atraso (delay)na entrega dos pacotes, chamada de Jitter. Essa variação é bastante sensível às perdasde pacotes e, portanto, bastante utilizada para avaliação de handovers. Para computar ojitter, foi enviado um fluxo de 20Mbps pela rede, no sentido downlink(Servidor/Cliente),durante 60 segundos. Este teste foi repetido 10 vezes para dar mais credibilidade aosresultados. A Figura 8.6 mostra o gráfico de uma das coletas comparando-se o PMIPFlowcom a proposta de antecipação usando Fuzzy.

60544842363024181261

20

15

10

5

0

Tempo (s)

Atr

aso

(m

s)

PMIPFlow/Fuzzy

PMIPFlow

Atraso dos Pacotes

Figura 8.6: Gráfico de atraso dos pacotes

A Figura 8.6 mostra alguns picos de variação de atraso de pacotes quando não se usaa proposta fuzzy, cada pico acontece no momento do handover. Como alguns pacotes sãoperdidos, os mesmos precisam ser reenviados de modo que o atraso para entrega dessepacote aumenta de forma acentuada. As perdas de pacotes ocorrem porque o processode troca entre ponto de acesso não é instantâneo e, dessa forma, em algum momento ousuário perde a conexão antes de achar outra conexão para continuar o serviço. Por outrolado, com a proposta de antecipação de handover utilizando o sistema fuzzy as perdas depacotes são amenizadas, uma vez que antes de sair completamente da rede o dispositivo

83


do usuário muda para outra rede de forma antecipada.

É importante frisar que, como trata-se de um testbed os momentos em que acontecemos handovers são diferentes há cada novo teste, porém, mantendo-se o padrão mostradona Figura 8.4 sempre acontecerá o mesmo número de handover para cada teste. Porexemplo, a Figura 8.6 apresenta um teste com quatro handover para cada proposta, porémo atraso apresentado nos fluxos com a proposta fuzzy são menores dos que apresentadosem a proposta.

A Figura 8.7 resume a média dos dados com 95% de Intervalo de Confiança. Para oresultado obtido pelo PMIPFlow sem antecipação, a média e variação dos dados são bemmaiores que na médias dos dados utilizando a proposta de antecipação fuzzy.

PMIPFlowPMIPFlow/Fuzzy

2,75

2,50

2,25

2,00

1,75

1,50

1,25

1,00

0,75

0,50

Atr

aso

(m

s)

95% de Confiança

Média e Intervalo dos dados

Figura 8.7: Intervalo dos dados de atraso de pacotes

A Tabela 8.1 mostra as estatísticas descritivas para os dados de atraso de pacotesdurante todos os testes. Pode-se perceber que a média com a proposta fuzzy possuium atraso médio de 43.59% menor que os testes sem a proposta, 1.489ms em médiacontra 0,65ms em média. Outra métrica importante é o desvio padrão que mostra oespalhamento dos dados em torno da média, e outra vez o PMIPFlow(Fuzzy) é maisvantajoso, em média 0.48ms contra 3.764ms, com e sem a proposta, respectivamente. ATabela 8.1 mostra também o valor mínimo, primeiro quartil (25% dos dados), mediana(50% dos dados), segundo quartil (75% dos dados) e valor máximo.

Uma métrica importante é a vazão dos dados, ou seja, taxa de recepção de pacotesno nó móvel. Para esta métrica foram realizados dez testes com 10Mbps e dez testescom 20Mbps, os dois testes utilizando o protocolo UDP. A Figura 8.8 mostra a vazãoem relação ao tempo de dois testes pareados, nela é possível ver que sem a proposta de

84


Tabela 8.1: Estatística descritiva para o atraso dos pacotes

Proposta Média Desvio Mínimo Q1 Mediana Q3 Máximo

PMIPFlow 1,489 3,764 0,092 0,444 0,523 0,634 18,639

PMIPFlow(Fuzzy)

0,6506 0,4869 0,1900 0,4183 0,5510 0,7062 3,7100

antecipação de handover a vazão é degradada devido às perdas de pacotes. Já com aproposta, as perdas são minimizadas e a vazão permanece quase constante mesmo napresença de vários handovers durante a transmissão.

60544842363024181261

10

9

8

7

6

5

4

Tempo (s)

Vazã

o (

Mbps) PMIPFlow

PMIPFlow/Fuzzy

Vazão (Tráfego UDP de 10Mbps)

Figura 8.8: Vazão do tráfego UDP limitado à 10Mbps

A Figura 8.9 mostra a variação em torno da média das vazão durantes os dez testesrealizados. É possível perceber que além da média da vazão sem a proposta ser menor, avariação dos dados é maior, evidenciando a instabilidade na comunicação.

85


PMIPFlow/FuzzyPMIPFlow

10,01

9,95

9,89

9,83

9,77

9,71

9,65

Vazã

o (

Mbps)

Média e Intervalo dos dados95% de Confiança

Figura 8.9: Intervalo da Média da Vazão do tráfego UDP limitado à 10Mbps

Apesar da diferença entre as médias com e sem a proposta, ela não é tão expressiva,isso acontece porque a vazão (10Mbps) não estressa tanto a rede e dessa forma as perdasde pacotes não são evidentes. No teste com 20Mbps mostrado a seguir é possível ver queas perdas são bem mais expressivas. A Tabela 8.2 exibe a estatística descritiva dos dadosdurantes os testes. É possível perceber que a média com a proposta (9,97 Mbps) é maiorque sem a proposta (9,80 Mbps), mas a diferença não é tão grande, cerca de 1%.

Tabela 8.2: Estatística descritiva para vazão de 10Mbps


PMIPFlow 9,8028 0,7090 6,00 10,00 10,00 10,00 10,00

PMIPFlow(Fuzzy)

9,9765 0,0879 9,5246 10,00 10,00 10,00 10,00

Para estressar mais a rede foram feitos dez testes com 20Mbps de vazão UDP. Comovimos anteriormente, na Seção 8.3, a taxa máxima obtida pelas placas utilizadas nosexperimentos foi de 17Mbps, deste modo, haverá um estresse maior na rede e as perdasde pacotes serão mais evidentes.

86


A Figura 8.10 mostra a vazão obtida no teste de 20Mbps. É possível perceber quea vazão não é constante como era no teste de 10Mbps, mostrado na Figura 8.8, issoacontece porque nesse teste a rede é levada ao seu limite e a flutuação de pacotes reflete acaracterísticas instável das redes sem fio. Nesse teste, as perdas de handover que ocorremsão mais impactantes que no teste anterior, pois a vazão é consideravelmente maior.

60544842363024181261

19

18

17

16

15

14

13

12

11

10

Tempo (s)

Vazã

o (

Mbps)

PMIPFlow

PMIPFlow/Fuzzy

Vazão (Tráfego UDP de 20Mbps)

Figura 8.10: Vazão do tráfego UDP limitado à 20Mbps

A Figura 8.11 evidencia a disparidade entre as médias de vazão com e sem a propostafuzzy, tanto em termos de média como em termos de variação.

PMIPFlow/Fuzzy_1PMIPFlow_1

17,4

17,2

17,0

16,8

16,6

16,4

16,2

16,0

Vazã

o (

Mbps)


Figura 8.11: Intervalo da Média da Vazão do tráfego UDP limitado à 20Mbps

Comparando-se as duas proposta, o PMIPFlow(Fuzzy) continua tendo vantagem,porém agora a vantagem é ainda maior e mais evidente. A Tabela 8.3 mostra o resumos

87


dos testes. Observando-se a Tabela, na média da vazão, a proposta é 3,93% maior quesem a proposta, ou seja, 16,51Mbps contra 17,16Mbps, porém os valores podem sermaiores se o tráfego perdurar por mais tempo, pois teoricamente haveria mais handovers,chegando a 8% em 120s, e quase 12% em um tráfego de 180 segundos. Uma métricaimportantes nesse caso é o valor mínimo atingido pela vazão, de 10 Mbps com PMIPFlowe de 15,80Mbps com a proposta PMIPFlow(Fuzzy), mostrando que sem a proposta deantecipação a vazão degrada bastante.

Tabela 8.3: Estatística descritiva para vazão de 20Mbps


PMIPFlow 16,51 1,81 10,00 16,55 17,00 17,35 19,30

PMIPFlow(Fuzzy)

17,16 0,66 15,80 16,65 17,20 17,60 19,10

A Figura 8.12 mostra a porcentagem de perda de pacotes durantes 10 testes. A Figuramostra que sem a proposta o número de perdas de pacotes é consideravelmente maior,chegando até 6,20 % de perda.

2,52

3,19

0,92

2,76

4,79

3,703,16

1,15

4,50

6,20

0,98 1,10 0,82 0,761,10

0,70

1,30

0,16

1,320,96

0

1

2

3

4

5

6

7

1 2 3 4 5 6 7 8 9 10

Perd

as d

e P

acote

(%

)

Instância de Teste

PMIPFLow

PMIPFlow (Fuzzy)

Figura 8.12: Gráfico em barra da porcentagem de Perdas de Pacotes

A Figura 8.13 mostra a mesma informação que o gráfico anterior, porém, em termosde pontos e linhas, dessa forma é mais evidente a disparidade entre as propostas. No testenúmero 3, onde as duas propostas possuem perdas semelhantes, o número de handoversem a proposta durante o teste foi reduzindo e apenas por esse motivo as perdas forammenores.

88


10987654321

7

6

5

4

3

2

1

0

Instância de Teste

Perd

as

de P

aco

te (

%)

PMIPFlow

PMIPFlow (Fuzzy)

6,20

4,50

1,15

3,16

3,70

4,79

2,76

0,92

3,19

2,52

6,20

4,50

1,15

3,16

3,70

4,79

2,76

0,92

3,19

2,52

6,20

4,50

1,15

3,16

3,70

4,79

2,76

0,92

3,19

2,52

6,20

4,50

1,15

3,16

3,70

4,79

2,76

0,92

3,19

2,52

0,961,32

0,16

1,30

0,70

1,100,76

0,82

1,100,98 0,961,32

0,16

1,30

0,70

1,100,76

0,82

1,100,98 0,961,32

0,16

1,30

0,70

1,100,76

0,82

1,100,98 0,961,32

0,16

1,30

0,70

1,100,76

0,82

1,100,98

Perdas de Pacotes em 10 coletas

Figura 8.13: Gráfico em linha dos dados da porcentagem de Perdas de Pacotes

A Figura 8.14 exibe a média e variação da porcentagem de perda de pacotes, nessaimagem é possível perceber a diferença entre as duas propostas.

PMIPFlow (Fuzzy)PMIPFlow

5

4

3

2

1

Perd

as

de P

aco

te (

%)


Figura 8.14: Gráfico de intervalo de variação dos dados da porcentagem de Perdas dePacotes

A Tabela 8.4 resume os dados de percentagem de perdas de pacotes, com a propostahá uma melhora de cerca de 160% em relação aos dados dos testes sem a proposta fuzzy,com o PMIPFlow a média da porcentagem de perdas foi de 3,28% contra 0,91% doPMIPFlow(Fuzzy).

89


Tabela 8.4: Estatística descritiva para Porcentagem de Perdas de Pacotes


PMIPFlow 3,28 1,61 0,92 2,17 3,17 4,57 6,19

PMIPFlow(Fuzzy)

0,91 0,33 0,16 0,74 0,97 1,15 1,31

8.5 Avaliação da Qualidade de Experiência

É importante garantir QoS em qualquer que seja o tipo de rede, cabeada ou sem fio. Noentanto, métricas de QoS não são o bastante para avaliar as redes do futuro. Com o intuitode resolver as limitações das tradicionais técnicas de controle de qualidade e desempenhoda rede, no que diz respeito à percepção humana e aspectos subjetivos relacionados aconteúdos multimídia, uma nova abordagem vem sendo utilizada nas avaliações de novasarquiteturas. Os novos estudos de desempenho em sistemas multimídia têm como base asmétricas de QoE.

Operações referentes ao controle de recursos da rede e, inclusive, mobilidade baseadasem métricas de QoE podem ser usadas para configurar e medir elementos de rede deforma a otimizar os recursos e garantir uma melhor percepção do conteúdo por parte dosusuários finais. Vários pesquisadores e organizações, como por exemplo, VQEG (Video

Quality Experts Group), estão estudando formas de aplicar QoE em diferentes cenáriosfixos e móveis, porém essa metodologia continua sendo um desafio.

Assim, as novas arquiteturas não estão sendo mais avaliadas apenas em termos de QoS,mas também quanto ao suporte à QoE. As métricas de QoE servem como extensão aosparâmetros de QoS, permitindo avanços nas transmissões de aplicações de áudio e vídeoem redes IP e podem proporcionar melhorias nos protocolos. A seguir, apresentamosas métricas PSNR (Peak Signal to Noise Ratio) e SSIM (Structural Similarity Index),adotadas como métricas de avaliação da arquitetura PMIPFlow.

8.5.1 Avaliação do PSNR

O PSNR é uma métrica tradicional de QoE que estima a qualidade do vídeo em decibéis,comparando o vídeo original com o vídeo recebido pelo usuário. Para cada faixa devalores de PSNR, há uma qualificação para o vídeo que foi recebido pelo usuário. Veja aTabela 8.5.

Para avaliação do vídeo no cenário foi utilizado trailers do filme "Os Vingadores".Todos possuem a mesma duração, o mesmo codec e o mesmo número de quadros (frames),

90

8.5. AVALIAÇÃO DA QUALIDADE DE EXPERIÊNCIA

Tabela 8.5: Valores de Classificação do PSNR

PSNR (dB) > 37 31 – 37 25 – 31 20 – 25 < 20

Qualidade Excelente Bom Aceitável Pobre Péssimo

porém com resoluções diferentes conforme mostra a Tabela 8.6.

Tabela 8.6: Vídeos utilizados nos testes

Nome Resolução FPS Codec Bitrate Duração Frames

Vídeo 1 160x90 24 H.264/AVC 488 kbps 2m e 3s 2970



Os vídeos foram enviados um de cada vez. Durante a transmissão do vídeo, assimcomo no teste anterior, o usuário permanecia em constante movimento de um pontode acesso para outro. Após o recebimento do vídeo foi utilizado a versão gratuita daferramento MSU (Video Quality Measurement Tool), (MSU Video Group, 2013), paraavaliar e extrair as informações necessárias para avaliação do vídeo recebido. A Figura8.15 mostra o PSNR do vídeo recebido, com resolução 160x90. Podemos perceber quedurante o momento do handover, ocorrem algumas perdas de pacotes o que acarreta umaqueda no valor do PSNR.

0 500 1000 1500 2000 2500 30000

20

40

60

80PSNR Video 160x90

Frames

PS

NR

(dB

)

PMIPFlowPMIPFlow(Fuzzy)

Figura 8.15: Comparação entre o PSNR do vídeo 160x90 com e sem a proposta

A Figura 8.16 mostra o intervalo dos dados de PSNR para o vídeo de resolução160x90. O PSNR com a proposta fuzzy é maior que o PSNR sem a proposta. Porém,a disparidade não é tão grande, pois da mesma forma que no teste de fluxo sintético, ofluxo não foi o suficiente para estressar a rede. Com resoluções maiores de vídeo, maioré o tráfego na rede, como será visto mais adiante.

A Tabela 8.7 mostra os dados estatístico para o teste em questão, a média do PSNRcom o PMIPFlow foi de 18.09dB e da proposta fuzzy 18,57dB. Ambos os vídeos são

91


PMIPFlow_FuzzyPMIPFlow

19,0

18,8

18,6

18,4

18,2

18,0

17,8

17,6

PSN

R (

dB)

PSNR (Intervalo dos dados) Vídeo 160x9095% de Confiança

Figura 8.16: Intervalo do PSNR do vídeo 160x90 com e sem a proposta

classificados como péssimo segundo a Tabela 8.5. Os valores de PSNR levam emconsideração a resolução do vídeo, para vídeos pequenos como neste casos os valores dePSNR vão estar bem abaixo do ideal. Mais adiante avaliaremos vídeos com resoluçõesmaiores.

Tabela 8.7: PSNR do vídeo com resolução 160x90


PMIPFlow 18,09 10,14 0,00 12,00 16,03 21,70 78,25

PMIPFlow(Fuzzy)

18,57 9,92 3,16 12,33 16,48 22,00 78,25

A próxima resolução de vídeo avaliada foi a de 320x180, neste caso o vídeo começaa ter valores de PSNR um pouco melhores. Percebe-se na Figura 8.17, que o PSNRvaria bastante de frame para frame, isso ocorre devido a natureza estrutural do vídeo emquestão. Por se tratar de um trailer, existem muitas variações de cores, de texturas e deefeitos.

A Figura 8.18 exibe a média e intervalo dos dados de PSNR, nela é possível perceberque a variação dos dados é praticamente a mesma, porém com o PMIPFlow(Fuzzy), oPSNR se mantém maior que sem a proposta. Isso ocorre porque com a proposta perde-semenos pacotes e com isso o vídeo sobre menor queda no PSNR.

A Tabela 8.8 resume os dados para a resolução de video 320x180. A média de PSNRcom a proposta é de 25,58dB enquanto que sem a proposta é de 24,51dB. Agora, comuma resolução maior, os vídeos ficam classificados como pobre, segundo a Tabela 8.5.

92


0 500 1000 1500 2000 2500 30000

20

40

60

80PSNR Video 320x180

Frames

PS

NR

(dB

)




26,0

25,5

25,0

24,5

24,0

PSN

R (

dB)





PMIPFlow 24,51 13,14 0,00 17,49 22,47 26,82 85,82

PMIPFlow(Fuzzy)

25,58 12,68 8,18 18,03 22,89 27,77 85,82

93


O último teste de QoE para o PSNR foi com resolução de 640x360. Até agoraavaliou-se apenas resoluções de vídeos (160x90 e 320x180), que são utilizados mais paradispositivos restritos como smartphones, tablets de baixo custo e alguns netbooks. Nessenovo teste, a resolução fica mais perto do que um usuário de notebook e dispositivos maisavançados.

A Figura 8.19 mostra o PSNR do vídeo na resolução de 640x360. Neste caso, percebe-se que os valores de PSNR são relativamente maiores que nos testes anteriores. Porém,sem uma proposta que melhore a velocidade de handover, as perdas inerentes a esseprocesso podem degradar a qualidade do vídeo recebido pelo usuário, na Figura 8.19percebe-se que há várias quedas no valor do PSNR que não são verificadas com a propostade antecipação.

0 500 1000 1500 2000 2500 30000

20

40

60PSNR Video 640x360

Frames

PS

NR

(dB

)



A Figura 8.20 destaca mais ainda a diferença dos PSNRs obtidos com e sem a proposta.Essa Figura mostra visualmente como a média estimada, com 95% de confiança, daproposta é maior que a média estimada sem a proposta.

94



32

31,5

31

29,5

PSN

R (

dB)



Os valores estão resumidos na Tabela 8.9. Na média, o PSNR com a proposta éde 31.44dB, e sem a proposta, atinge 29.70dB. O ganho de 6% e poderia ser maior,dependendo da duração e da resolução do vídeo. Desta vez, o vídeo com a proposta estáclassificado como BOM e o vídeo sem a proposta está classificado como ACEITÁVEL,segundo a Tabela 8.5.



PMIPFlow 29,70 10,35 0,00 23,12 27,88 33,98 60,000

PMIPFlow(Fuzzy)

31,44 9,95 13,17 23,65 28,18 34,32 60,00

8.5.2 Avaliação do SSIM

A métrica SSIM (Structural Similarity Index), também bastante utilizada para avaliaçãode QoE, baseia-se na medição quadro a quadro do vídeo original com o vídeo recebidopelo usuário. O SSIM compara a similaridade entre os vídeos nos seguintes aspectos:contraste, luminosidade e estrutura. O SSIM é expresso como um valor decimal entre 0 e1. Quanto mais próximo de 1, melhor é a qualidade do vídeo.

A Figura 8.21 mostra o SSIM para o vídeo recebido com resolução 160x90, assimcomo nos testes de PSNR, a figura mostra os valores para para os testes com e sem aproposta. Na imagem, é possível ver que no momento dos handovers, o SSIM sem aproposta vai à quase zero, o que prejudica bastante a qualidade do vídeo.

95


0 500 1000 1500 2000 2500 30000

0.2

0.4

0.6

0.8

1

SSIM Video 160x90

Frames

SS

IM


Figura 8.21: Comparação entre o SSIM do vídeo 160x90 com e sem a proposta

A Figura 8.22 mostra a média em forma de intervalo evidenciando que com a propostafuzzy a média de SSIM é maior que sem a proposta, embora as duas estejam muito abaixodo ideal, porém esse valor inadequado do SSIM é reflexo da baixa resolução do vídeo,assim como ocorreu com o PSNR, pois, essas métricas dependem do valor máximo depixel dos quadros.


0,52

0,51

0,50

0,49

0,48

SSIM

SSIM (Intervalo dos dados) Vídeo 160x9095% de Confiança

Figura 8.22: Intervalo do dados de SSIM do vídeo 160x90 com e sem a proposta

96


A Figura 8.23 mostra o SSIM para resolução 320x180. As quedas apresentadasno gráfico são evidentes e ocorrem devido às perdas de pacotes quando a proposta deantecipação não é utilizada.

0 500 1000 1500 2000 2500 30000

0.5

1SSIM Video 320x180

Frames

SS

IM



A Figura 8.24 exibe a comparação visual da intervalo da média das duas propostascom 95% de confiança. Neste caso, como não existem pontos em comum no intervalo deconfiança das duas propostas e podemos afirmar com certeza que a média do SSIM daproposta é superior da média sem a proposta.


0,69

0,68

0,67

0,66

0,65

0,64

SSIM


Figura 8.24: Intervalo do dados de SSIM do vídeo 320x180 com e sem a proposta

Por fim, o último teste, com o vídeo de resolução 640x360. Neste caso, como a vazãoé maior, todas as perdas são potencializadas, de modo que é mais evidente a queda nosvalores de SSIM dos quadros do vídeo recebido.

Agora, o intervalo de confiança da média é nitidamente superior utilizando a proposta,na média é 0.694 contra 0.6537, o que representa uma superioridade de 6,16%. Esses

97


0 500 1000 1500 2000 2500 30000

0.5

1SSIM Video 640x360

Frames

SS

IM



valores, em comparação com os testes com resoluções inferiores mostram que a propostade antecipação se mostra mais atrativa quando maior é a resolução do vídeo utilizado econsequentemente maior é a vazão necessário para o envio do mesmo.


0,71

0,70

0,69

0,68

0,67

0,66

0,65

0,64

SSIM


Figura 8.26: Intervalo dos dados de SSIM do vídeo 640x360 com e sem a proposta

Para a métrica SSIM, resumiu-se todos os teste na Tabela 8.10, que mostra de formacomparativa os valores médios, desvio padrão, valor mínimo, primeiro quartil (25% dosdados), mediana (segundo quartil ou 50% dos dados), teceiro quartil (75% dos dados)e o valor máximo. Como dito anteriormente, a Tabela, mostra que quanto maior é aresolução do vídeo maior é o valor de SSIM, também de PSNR, do mesmo e maior sãoos benefícios de se utilizar uma proposta que preserve de forma inteligente os pacotes nomomento da troca de rede do usuário.

Para se visualizar de forma prática os benefícios da proposta, a Figura 8.27 mostra oframe 598 retirado do vídeo recebido durante o processo de handover. É possível perceber

98


Tabela 8.10: Resumo dos dados de SSIM para todas as resoluções de vídeo.


Resolução 190x90

PMIPFlow 0,493 0,27 0,00 0,25 0,44 0,70 1

PMIPFlow(Fuzzy)

0,501 0,26 0,001 0,279 0,465 0,716 1

Resolução 320x180

PMIPFlow 0,574 0,260 0,0 0,375 0,590 0,825 1

PMIPFlow(Fuzzy)

0,605 0,249 0,123 0,395 0,596 0,826 1

Resolução 640x360

PMIPFlow 0,653 0,246 0,0 0,469 0,684 0,855 1

PMIPFlow(Fuzzy)

0,704 0,216 0,0014 0,538 0,707 0,885 1

que as perdas de frames durante o processo de handover prejudicam a reconstrução edegradam a qualidade do vídeo. Quando o PMIPFlow(Fuzzy) é utilizado as perdas sãominimizadas e a reconstrução do vídeo é realizada de forma completa, com isso, o usuáriorecebe um vídeo com qualidade e não toma conhecimento da ocorrência do handover.

Original

PMIPFlow PMIPFlow (Fuzzy)

Figura 8.27: Frame 598 no instante do handover com o PMIPFlow e com o PMIP-Flow(Fuzzy)

99



Este Capítulo apresentou a avaliação da proposta de antecipação de handover para oPMIPFlow. Os resultados dos testes mostraram que a proposta é eficiente e evita a perdaexcessiva de pacote que normalmente ocorre durante o processo de handover. Em termosquantitativos, no teste de atraso de pacotes a proposta fuzzy foi 128,88 % melhor quesem a proposta. Em relação à vazão, no teste de 10Mbps a proposta foi 1,76% melhor.Por outro lado, para o teste de 20Mbps, a proposta foi cerca de 4% melhor. Em relação àporcentagem de perda de pacotes, o PMIPFlow(Fuzzy) é superior em 260%.

Levando-se em conta a avaliação da métrica QoE, na análise de vídeo, foram utilizadostrês resoluções diferentes, 160x90, 320x180 e 640x360. No teste da métrica PSNR, aproposta foi superior 2,65%, 4,36% e 5,85%, respectivamente. No caso da métrica SSIM,a superioridade foi de 1,6%, 5,40% e 7,8%.

Em todos os testes a utilização da proposta se mostrou vantajosa, e quanto maior aresolução dos vídeos maior sua vantagem, isso porque, um vídeo com uma resoluçãomaior requer mais pacotes para enviar um frame, o que significa um maior tráfego pelarede, e se mais pacotes trafegam maiores são as perdas devido às possíveis desconexão.No futuro, os dispositivos serão mais sofisticados, com mais memória, maior poder deprocessamento, de modo, que a resolução das aplicações de vídeo tendem a aumentar, oque antigamente era apenas voz e texto, no futuro, será vídeo de resolução ultra HD(4K).Por isso, garantir a continuidade de serviço é algo de suma importantes para as redesmóveis do futuro.

100

9Conclusão

"Quando olho para trás e vejo o quanto caminhei e os

obstáculos que tive que superar e, ao olhar para frente,

vislumbro mais desafios nesta estrada que não termina,

concluo: Vencerei novamente, porque vencer é meu desiderato."

—BALTASAR AVELAR (Filosofias de Vida)

Este Capítulo resume os principais pontos discutidos neste trabalho, as consideraçõesfinais desta dissertação é apresentada na Seção 9.1. Na Seção 9.2, são descritas algumascontribuições obtidas, e em seguida, na Seção 9.3, serão discutidos alguns pontos quepodem ser explorados em trabalhos futuros.


Este trabalho apresentou o PMIPFlow, uma arquitetura para o gerenciamento de mobi-lidade em redes SDN. Discutiu-se a necessidade de uma nova arquitetura para as redestradicionais, foram introduzidos novos conceitos como: redes definidas por software,OpenFlow, programabilidade, virtualização de redes e mobilidade em redes virtuais. Fo-ram apresentados os conceitos relacionados ao gerenciamento de mobilidade, introduçãosobre as redes sem fio e handover, após isso, alguns protocolos de mobilidade, foramdiscutidos, em especial o MIPv6 e PMIPv6, onde este último serviu como inspiraçãopara o PMIPFlow. Em seguida foi apresentada a arquitetura do PMIPFlow, abordandodesde a sinalização, conexão e handover, até sua implementação no ambiente Linux.

Nesta dissertação, também foram discutidos a implementação do protótipo do PMIP-Flow e das entidade que compõem a arquitetura. No PMIPFlow, tal como nos proto-colos de mobilidade em geral, não foi especificada uma inteligência para auxiliar no

101

CAPÍTULO 9. CONCLUSÃO

processo de handover, com isso, além da arquitetura PMIPFlow, foi desenvolvido oPMIPFlow(Fuzzy), que é uma proposta de antecipação de handover na arquitetura PMIP-Flow utilizando lógica fuzzy. A avaliação da arquitetura e da proposta PMIPFlow(Fuzzy)foi realizada utilizando-se tanto métricas de QoS quanto de QoE, os resultados mostraramque a proposta possui um bom desempenho, e que a antecipação ajuda a melhorar asmétricas a qualidade do vídeo recebida pelo usuário.

A programabilidade de redes oferecida pelo paradigma SDN trás a possibilidade deinovação e transforma a ideia de redes engessadas e fechadas, para redes abertas, flexíveise de rápida evolução. Isso porque através de uma interfaces padronizada e um sistema decontrole externo, o SDN oferece um gerenciamento mais eficiente dos elementos da rede,separando o plano de controle do plano de dados. O PMIPFlow é uma tentativa de criarum framework, que forneça às redes SDN a capacidade de gerenciamento de dispositivosmóveis.

9.2 Contribuições

Esta Seção apresenta as principais contribuições obtidas nesta dissertação.

A primeira contribuição deste trabalho foi a implementação preliminar do protocoloPMIPv6 para redes tradicionais. Esse trabalho serviu como ponto de partida para odesenvolvimento da arquitetura PMIPFlow.

A segunda contribuição foi o desenvolvimento da arquitetura de gerenciamento demobilidade em redes definidas por software. Este é o primeiro trabalho, que se temconhecimento, a utilizar os princípios de um protocolo padronizado de gerenciamentode mobilidade em conjunto com o OpenFlow, para fornecer handover transparente aosusuários móveis em redes virtualizadas.

A terceira contribuição foi propor uma solução inteligente para otimização de hando-

ver. Essa solução é baseado em lógica fuzzy e utiliza métricas de QoS para servir comogatilho de handover.

Outra contribuição relevante deste trabalho, foi a revisão sistemática sobre gerencia-mento de mobilidade na camada IP e em redes definidas por software, bem como sobretécnicas de antecipação de handover.

102

9.3. TRABALHOS FUTUROS

9.3 Trabalhos Futuros

Esta seção apresenta e discute possíveis extensões à pesquisa desenvolvida nesta disserta-ção.

• Testar outras tecnologias: o PMIPFlow foi avaliado utilizando redes IEEE 802.11(Wi-Fi), porém, assim como a maioria dos protocolos de gerenciamento de mobili-dade, o PMIPFlow não depende de tecnologia. Com isso, este trabalho pode serestendido para testes com outras tecnologias sem fio, como WiMAX e LTE.

• Gerenciamento de mobilidade energeticamente eficiente: o tráfego de aplica-ções de vídeo consome bastante banda e energia tanto dos dispositivos móveisquanto nos equipamentos da rede. Deste modo há a necessidade de estender otempo de vida das baterias, bem como, reduzir o consumo de energia no núcleo darede no contexto das então denominadas redes verdes (Green Networking), umatendência na pesquisa em TICs que visa, além do aspecto econômico, minimizar aemissão de CO2 na atmosfera. A extensão do PMIPFlow para contemplar variáveisrelacionadas ao consumo de energia tanto do dispositivo quanto da rede podem servislumbradas para um gerenciamento de mobilidade energeticamente eficiente.

• Mobilidade na computação em nuvem: uma nova tecnologia que se expande acada dia, é a computação na nuvem (Cloud Computing), nela os dados do usuário,que antes eram armazenados localmente, passam a ser guardados em data centers

virtualizados espalhados pela Internet (nuvem). Esta nuvem pode ser entendidacomo a própria Internet ou uma rede local, contanto que ela permita acesso externo.Deste modo, os dados dos usuário estão acessíveis onde quer que ele esteja. Umadas vantagens da computação em nuvem é a possibilidade de migração de máquinasvirtuais (Asghar et al., 2011), neste processo, o desafio é manter a conectividadedas máquinas nesse processo de transferência. O PMIPFlow poderia ser utilizadopara gerir essa mobilidade mantendo o IP da máquina virtual inalterada enquantoela é transferida para outra infraestrutura/servidor/máquina física.

• Mecanismo para seleção inteligente de canais: antes de conduzir os teste doPMIPFlow, foi necessário fazer uma varredura para descobrir quais canais sem fioestavam menos congestionados, com o objetivo de assegurar que as degradaçõesforam causadas exclusivamente pelo handover. Logo, percebeu-se que é de extrema

103

CAPÍTULO 9. CONCLUSÃO

importância que o usuário esteja conectado no melhor canal, além da melhor rede.Portanto, uma possibilidade de extensão do PMIPFlow é integrar à arquitetura umesquema de seleção inteligente de canais.

• Elaborar métricas objetivas de QoE para redes sem fio virtualizadas: atéagora, as métricas objetivas de QoE foram elaboradas para redes cabeadas e quandomuito para redes sem fio, mas sem os componentes de virtualização. Mesmo osmodelos existentes para redes cabeadas e sem fio, não são completos. Desta forma,é possível vislumbrar a criação de métricas objetivas que levem em consideraçãocaracterísticas das redes sem fio virtuais.

• Modelo para decisão de handover baseado em QoE: a arquitetura PMIPFlow foidesenvolvida de tal modo que outras propostas de otimização de handover podemser facilmente implementadas. O PMIPFlow(Fuzzy) baseia-se em métricas de QoS(Vazão,RTT e RSS) para tomada de decisão de handover. Outra possibilidade, écriar um modelo matemático para predição de QoE que leve em consideração todoo cenário de redes móveis virtuais. Este modelo seria utilizado para tomar decisõesimportantes, baseadas em QoE, dentro de redes SDN com o objetivo de melhoraros serviços fornecidos ao usuário final.

• Handover vertical: é unânime que as redes do futuro serão compostas pela integra-ção de diversas outras redes fornecendo ao usuário uma gama de tecnologias, taxasde dados e serviços diferenciados. Com isso, um dos trabalhos futuros é estender oPMIPFlow para fornecer, também, gerenciamento de mobilidade vertical, ou seja,handover entre tecnologias diferentes. Desta forma, o usuário estará conectadosempre na melhor rede, não importando a tecnologia empregada nelas.

104

Referências Bibliográficas

Akyildiz, I., McNair, J., Ho, J., Uzunalioglu, H., and Wang, W. (1999). Mobilitymanagement in next-generation wireless systems. Proceedings of the IEEE, 87(8),1347–1384.

Asghar, N., Frikha, M., and Tabbane, S. (2011). A virtual network solution for servicemobility. In Wireless and Mobile Networking Conference (WMNC), 2011 4th Joint

IFIP, pages 1 –6.

Atalah, K., Macías, E., and Suárez, A. (2008). A proactive horizontal handover algorithmbased on rssi supported by a new gradient predictor. Ubiquitous Computing and

Communication Journal, 3.

Avelar, E., Marques, L., Bemerguy, T., and Dias, K. (2011). Qoe provisioning andseamless mobility management based on pmipv6 protocol. Latin America Transactions,

IEEE (Revista IEEE America Latina), 9(2), 199 –205.

Big Switch Networks (2011). Big Switch Controller. http://www.bigswitch.

com/.

Chang, R.-S. and Leu, S.-J. (2004). Handoff ordering using signal strength for multimediacommunications in wireless networks. Wireless Communications, IEEE Transactions

on, 3(5), 1526–1532.

Choi, J., Jung, B., and il Kim, T. (2009). Lma initiated route optimization protocol forimproving pmip handover performance. Communications Letters, IEEE, 13(11), 871–873.

Chowdhury, N. M. K. and Boutaba, R. (2009). Network virtualization: state of the artand research challenges. Communications Magazine, IEEE, 47(7), 20–26.

Feldmann, A. (2007). Internet clean-slate design: what and why? ACM SIGCOMM

Computer Communication Review, 37(3), 59–64.

Firoiu, V., Le Boudec, J.-Y., Towsley, D., and Zhang, Z.-L. (2002). Theories and modelsfor internet quality of service. Proceedings of the IEEE, 90(9), 1565–1591.

Forman, G. and Zahorjan, J. (1994). The challenges of mobile computing. Computer,27(4), 38 –47.

105

http://www.bigswitch.com/

http://www.bigswitch.com/

REFERÊNCIAS BIBLIOGRÁFICAS

Gohar, M., Koh, S. J., Um, T.-W., and Lee, H.-W. (2010). Seamless multicast handover inpmipv6-based wireless networks. In Advanced Communication Technology (ICACT),

2010 The 12th International Conference on, volume 1, pages 502 –507.

Gundavelli, S., Chowdhury, K., Devarapalli, V., Patil, B., Leung, K., et al. (2008a). Proxymobile ipv6.

Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and Patil, B. (2008b). Rfc5213, proxy mobile ipv6.

Hostapd (2013). IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authentica-tor. http://hostap.epitest.fi/hostapd/.

Hwang, H., Kim, J.-H., Lee, J., and Lee, K.-G. (2010). Fast handoff scheme usingmulticast group for intra-domain in pmipv6 networks. In Consumer Communications

and Networking Conference (CCNC), 2010 7th IEEE, pages 1 –2.

Internet Engineering Task Force (2007). IEEE 802.21/Media Independent Handover.http://www.ieee802.org/21/.

Internet Engineering Task Force (2010). Network-based Localized Mobility Management.http://datatracker.ietf.org/doc/charter-ietf-netlmm/.

Internet Engineering Task Force (2011). A Survey of Mobility Support in the Internet.http://tools.ietf.org/html/rfc6301.

Itoh, K.-I., Watanabe, S., Shih, J.-S., and Sato, T. (2002). Performance of handoffalgorithm based on distance and rssi measurements. Vehicular Technology, IEEE

Transactions on, 51(6), 1460–1468.

Johnson, D., Perkins, C., and Arkko, J. (2004). Rfc 3775: Mobility support in ipv6. IETF,

June.

Kempf, J. (2007). Problem statement for network-based localized mobility management(netlmm).

Kim, J.-I., Koh, S.-J., and Ko, N.-S. (2009). B-pmipv6: Pmipv6 with bicasting forsoft handover. In Advanced Communication Technology, 2009. ICACT 2009. 11th

International Conference on, volume 01, pages 218 –221.

106

http://hostap.epitest.fi/hostapd/

http://www.ieee802.org/21/

http://datatracker.ietf.org/doc/charter-ietf-netlmm/

http://tools.ietf.org/html/rfc6301


Kim, J.-I., Jung, H., and Koh, S. J. (2011). Distributed mobility control for mobile-oriented future internet environments. In ICT Convergence (ICTC), 2011 International

Conference on, pages 342 –347.

Klir, G. J. and Yuan, B. (1995). Fuzzy sets and fuzzy logic. Prentice Hall New Jersey.

Kong, K.-S., Lee, W., Han, Y.-H., and Shin, M.-K. (2008). Handover latency analysis ofa network-based localized mobility management protocol. In Communications, 2008.

ICC’08. IEEE International Conference on, pages 5838–5843. IEEE.

Lee, H.-S. and Min, S.-W. (2009). A network-based fast handover scheme over ieee802.16e access networks. In Communications and Information Technology, 2009.

ISCIT 2009. 9th International Symposium on, pages 1084 –1089.

Li, L., Mao, Z., and Rexford, J. (2012). Toward software-defined cellular networks. InSoftware Defined Networking (EWSDN), 2012 European Workshop on, pages 7 –12.

Magagula, L., Falowo, O., and Chan, H. (2009). Pmipv6 and mih-enhanced pmipv6for mobility management in heterogeneous wireless networks. In AFRICON, 2009.

AFRICON ’09., pages 1 –5.

McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J.,Shenker, S., and Turner, J. (2008). Openflow: enabling innovation in campus networks.SIGCOMM Comput. Commun. Rev., 38(2), 69–74.

Mininet (2011). Rapid prototyping for software defined networks. http://yuba.

stanford.edu/foswiki/bin/view/OpenFlow/Mininet.

MSU Video Group (2013). Video Quality Measurement Tool. http://compression.ru/index_en.htm.

Mun-Yee Lim, J. and Chow, C.-O. (2012). Smart handover based on fuzzy logic trend inieee802. 11 mobile ipv6 networks.

Nakauchi, K., Ishizu, K., Murakami, H., Nakao, A., and Harada, H. (2011). Amphibia:A cognitive virtualization platform for end-to-end slicing. In Communications (ICC),

2011 IEEE International Conference on, pages 1–5. IEEE.

Nasser, N., Hasswa, A., and Hassanein, H. (2006). Handoffs in fourth generationheterogeneous networks. Communications Magazine, IEEE, 44(10), 96 –103.

107

http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Mininet

http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Mininet

http://compression.ru/index_en.htm

http://compression.ru/index_en.htm


NEC (2011a). Helios: An extensible C-based OpenFlow controller. http://www.

nec.com/.

NEC (2011b). Trema: Full-Stack OpenFlow Framework in Ruby and C. http://

trema.github.com/trema/.

Nicira Networks (2010). NOX: Network Operation System. http://noxrepo.org/wp.

Niebert, N., Baucke, S., El-Khayat, I., Johnsson, M., Ohlman, B., Abramowicz, H.,Wuenstel, K., Woesner, H., Quittek, J., and Correia, L. M. (2008). The way 4ward tothe creation of a future internet. In Personal, Indoor and Mobile Radio Communications,

2008. PIMRC 2008. IEEE 19th International Symposium on, pages 1–5. IEEE.

NLANR/DAST (2013). A modern Alternative for Measuring Maximum TCP and UDP .http://iperf.sourceforge.net/.

Nuorvala, V., Petander, H., and A. Tuominen (2001). Mobile IPv6 for Linux (MIPL).http://www.umip.org/.

Obele, B. and Kang, M. (2009). Mobility management: A proactive qos-aware proxymip with improved handover latency for end-to-end qos provisioning in a proxymip domain. In Advanced Communication Technology, 2009. ICACT 2009. 11th

International Conference on, volume 03, pages 1867 –1869.

OpenFlowHub.org (2012). Indigo Open Development System. http://www.

openflowhub.org/display/Indigo/.

Orbit-Lab (2005). Orbit: Open-Access Research Testbed for Next-Generation WirelessNetworks. http://www.orbit-lab.org/.

R. Sherwood, G. Gibb, K. Yap, G. Appenzeller, N. McKeown, and G. Parulkar(2009). Flowvisor: A network virtualization layer. https://github.com/

OPENNETWORKINGLAB/flowvisor/wiki.

Rice University (2011). Maestro: A System for Scalable OpenFlow Control. http://code.google.com/p/maestro-platform/.

Ryu, S., Kim, M., and Mun, Y. (2009). Enhanced fast handovers for proxy mobileipv6. In Computational Science and Its Applications, 2009. ICCSA ’09. International

Conference on, pages 39 –43.

108

http://www.nec.com/

http://www.nec.com/

http://trema.github.com/trema/

http://trema.github.com/trema/

http://noxrepo.org/wp

http://noxrepo.org/wp

http://iperf.sourceforge.net/

http://www.umip.org/

http://www.openflowhub.org/display/Indigo/

http://www.openflowhub.org/display/Indigo/

http://www.orbit-lab.org/

https://github.com/OPENNETWORKINGLAB/flowvisor/wiki

https://github.com/OPENNETWORKINGLAB/flowvisor/wiki

http://code.google.com/p/maestro-platform/

http://code.google.com/p/maestro-platform/


Sharma, M. and Khola, R. (2012). Fuzzy logic based handover decision system. Interna-

tional Journal, 3.

Sherwood, R., Gibb, G., Yap, K., Appenzeller, G., Casado, M., McKeown, N., andParulkar, G. (2009). Flowvisor: A network virtualization layer. OpenFlow Switch

Consortium, Tech. Rep.

Stanford (2008). OpenFlow: Innovate in Your Network . http://www.openflow.org/.

Stanford (2012). OpenFlow 1.0/Openflow for Ubuntu. http://openflow.org/downloads/openflow-1.0.0.tar.gz.

Stanford University (2011). Beacon: A Java-based OpenFlow Controller. https:

//openflow.stanford.edu/display/Beacon/Home.

Taghizadeh, A., Wan, T.-C., and Budiarto, R. (2011). A comparative performanceevaluation of inter-domain network-based ip mobility solutions. In Proceedings of the

7th Asian Internet Engineering Conference, AINTEC ’11, pages 136–139, New York,NY, USA. ACM.

Tsukamoto, K., Yamaguchi, T., and Kashihara, S. (2007). Experimental evaluation ofdecision criteria for wlan handover: Signal strength and frame retransmission. IEICE

transactions on communications, 90(12), 3579–3590.

Tsung-Nan, L. and Po-Chiang, L. (2005). Hndoff ordering using link quality estimatorfor multimedia communications in wireless networks. In Global Telecommunications

Conference, 2005. GLOBECOM’05. IEEE, volume 2, pages 6–pp. IEEE.

Turner, J. S. (2006). A proposed architecture for the geni backbone platform. In Archi-

tecture for Networking and Communications systems, 2006. ANCS 2006. ACM/IEEE

Symposium on, pages 1–10. IEEE.

VMware (2012). VMware vSphere Hypervisor (ESXi) 5.0. http://www.vmware.com/products/vsphere-hypervisor/overview.html.

Wang, Y., Feng, Y., and Zhang, L. (2009). Coordinating fast handover and route optimi-zation in proxy mobile ipv6. In Wireless Communications, Networking and Mobile

Computing, 2009. WiCom ’09. 5th International Conference on, pages 1 –4.

109

http://www.openflow.org/

http://www.openflow.org/

http://openflow.org/downloads/openflow-1.0.0.tar.gz

http://openflow.org/downloads/openflow-1.0.0.tar.gz

https://openflow.stanford.edu/display/Beacon/Home

https://openflow.stanford.edu/display/Beacon/Home

http://www.vmware.com/products/vsphere-hypervisor/overview.html

http://www.vmware.com/products/vsphere-hypervisor/overview.html


Winkler, S. and Mohandas, P. (2008). The evolution of video quality measurement: frompsnr to hybrid metrics. Broadcasting, IEEE Transactions on, 54(3), 660–668.

Wu, S.-J. (2011). Fuzzy-based handover decision scheme for next-generation heterogene-ous wireless networks. Journal of Convergence Information Technology, 6(4).

Yamasaki, Y., Miyamoto, Y., Yamato, J., Goto, H., and Sone, H. (2011). Flexible accessmanagement system for campus vlan based on openflow. In Applications and the

Internet (SAINT), 2011 IEEE/IPSJ 11th International Symposium on, pages 347–351.IEEE.

Yap, K., Sherwood, R., Kobayashi, M., Huang, T., Chan, M., Handigol, N., McKeown,N., and Parulkar, G. (2010a). Blueprint for introducing innovation into wireless mobilenetworks. In Proceedings of the second ACM SIGCOMM workshop on Virtualized

infrastructure systems and architectures, pages 25–32. ACM.

Yap, K.-K., Kobayashi, M., Sherwood, R., Huang, T.-Y., Chan, M., Handigol, N., andMcKeown, N. (2010b). Openroads: Empowering research in mobile networks. ACM

SIGCOMM Computer Communication Review, 40(1), 125–126.

Yi, M.-K., Choi, J.-Y., Choi, J.-W., Park, S.-C., and Yang, Y.-K. (2010). A pointerforwarding scheme for minimizing signaling costs in proxy mobile ipv6 networks.In Consumer Communications and Networking Conference (CCNC), 2010 7th IEEE,pages 1 –5.

Yousaf, F. Z., Bauer, C., and Wietfeld, C. (2008). An accurate and extensible mobile ipv6(xmipv6) simulation model for omnet++. In Proceedings of the 1st international confe-

rence on Simulation tools and techniques for communications, networks and systems

& workshops, page 88. ICST (Institute for Computer Sciences, Social-Informatics andTelecommunications Engineering).

110

Apêndices

111

AScripts

A.1 Hostapd

Este script configura os OMAGs em modo AP. Para isso utiliza um arquivo especial deconfiguração chamado hostapd_omagX.conf.

1 #!/bin/bash

2 set -e

3 NUM_ARG=$#

4 VERSION=’1.0’

5

6 HOSTAPD=’/usr/sbin/hostapd’

7 HOSTAPD_OMAG1_CONF=’/etc/hostapd/hostapd_omag1.conf’

8 HOSTAPD_OMAG2_CONF=’/etc/hostapd/hostapd_omag2.conf’

9

10 function omag1(){

11 $HOSTAPD $HOSTAPD_OMAG1_CONF

12


14 $HOSTAPD $HOSTAPD_OMAG2_CONF

15 }

16

17 function about(){

18 echo "******************************";

19 echo "$0 $VERSION"

20 echo "This program is used to configure";

113

APÊNDICE A. SCRIPTS

21 echo " and initialize the PMIPFlow"

22 echo "Created by Edson Adriano M. Avelar ([email protected])"

23 echo "******************************";

24 }

25

26 function usage(){

27 echo "PMIPFlow Init Script. v$VERSION"

28 echo "Created by Adriano Avelar([email protected])"

29 echo "usage: $0 [OPTIONS] "

30 echo " -om1, --omag1 : Configure and initialized as OMAG 1"


32 echo " -h, --help : Display this help and exit"

33 echo " -v, --version : Display version info and exit"

34

35 }

36

37 case $NUM_ARG in

38 0)

39 echo "No parameter, check usage out"

40 usage;;

41

42 1)

43 if [ "$1" == "--omag1" ] || [ "$1" == "-om1" ]; then

44 omag1

45 elif [ "$1" == "--omag2" ] || [ "$1" == "-om2" ]; then

46 omag2

47 elif [ "$1" == "--help" ] || [ "$1" == "-h" ]; then

48 usage

49 elif [ "$1" == "--version" ] || [ "$1" == "-v" ]; then

50 about

51 else

52 usage

53 fi

54 ;;

55 esac

114

A.2. NTP.SH

A.2 NTP.sh

Cliente/Servidor NTP (Network Time Protocol) Para a utilização correta dos sistemasé necessário sincronizar os relógios dos OMAGs com o do NOX. Isso é realizado com oScript abaixo, que usa o protocolo NTP para tal fim. Esse script é executado no OMAGe outro no NOX existem um servidor NTP aguardando requisição de sincronização declientes.

1 #!/bin/bash

2

3 watch -n 60 ntpdate 2001::1

Este script executa a cada 60 segundos uma requisição ntpdate para o IP do NOX queé 2001::1, o NOX responde com o NTP Reply informando o seu relógio atual, o OMAGrecebe a resposta e sincroniza seu relógio automaticamente.

115


A.3 PMIPFlowSetup.sh

Este script configura o necessário para execução da máquina como OMAG1 ou OMAG2.Após as configurações, ele chama na linha 174 e 201 o script PMIPFlow_Init.shpara, de fato, inicializar a implementação em C++ do PMIPFlow.

1 #!/bin/bash

2 set -e

3 NUM_ARG=$#

4 VERSION=’1.0’

5 #Set some variables

6 WIFI_INTERFACE=’wlan0’

7 SCRIPTS_DIR=’/usr/local/pmipflow/scripts’

8

9 #oMAG1

10 ETH0_OMAG1_ADDRESS=’2001::10/64’

11 WIFI_OMAG1_ADDRESS=’fe80::a:b:c:d/64’

12

13 #OMAG2

14 ETH0_OMAG2_ADDRESS=’2001::20/64’

15 WIFI_OMAG2_ADDRESS=’fe80::a:b:c:d/64’

16

17 function sincronization(){

18 screen -A -d -m -S ntp $SCRIPTS_DIR/ntp.sh

19 }

20

21 function init(){

22 ntp=$(echo "‘service network-manager status | grep running‘")

23

24 #Stop ntp server

25 if [[ "$ntp" == "" ]]; then

26 echo "1. NTP is not running, so continue.."

27 else

28 echo "NTP is running, so kill it .."

29 service ntp stop

116

A.3. PMIPFLOWSETUP.SH

30 sincronization

31 fi

32

33 net=$(echo "‘service network-manager status | grep running‘")

34 #Turns Network Manager down, to not brings troubles

35 if [[ "$net" == "" ]]; then

36 echo "1. Network Manager is not running, so continue.."

37 else

38 echo "Network Manager is running, so kill it .."

39 service network-manager stop

40 fi

41

42 $SCRIPTS_DIR/cons.sh set

43 }

44

45 function config_interface_omag1() {

46

47 ARP_PATH=’/usr/sbin’

48 ROUTE_PATH=’/sbin’

49

50 vconfig add eth0 20

51 vconfig set_ingress_map eth0.20 0 5

52 vconfig set_egress_map eth0.20 0 5


54

55 ifconfig eth0 up

56 ifconfig eth0.20 up


58

59 ifconfig eth0:1 192.168.254.99 netmask 255.255.255.0

60 ifconfig eth0.20 192.168.20.99 netmask 255.255.255.0


62

63 #Set ipv6 to eth0

64 ifconfig eth0 inet6 add $ETH0_OMAG1_ADDRESS

117


65

66 #Routes to adequate OMAG to REVIR network,

67 #this routes are not used in PMIPFlow

68 #operation since it’s IPv6 oriented.

69

70 $ROUTE_PATH/route add -net 192.168.1.0 gw 192.168.20.150






76

77 #Same of Routes, only for REVIR Network, not for PMIPFlow.

78 $ARP_PATH/arp -s 192.168.20.150 00:00:00:00:00:02

79 $ARP_PATH/arp -s 192.168.21.150 00:00:00:00:00:02

80 $ARP_PATH/arp -s 192.168.20.151 00:00:00:00:00:04

81 $ARP_PATH/arp -s 192.168.21.151 00:00:00:00:00:04

82 $ARP_PATH/arp -s 192.168.20.152 00:00:00:00:00:06

83 $ARP_PATH/arp -s 192.168.21.152 00:00:00:00:00:06

84

85 $ARP_PATH/arp -s 192.168.20.100 e0:69:95:19:aa:1b


87 $ARP_PATH/arp -s 192.168.20.98 f0:4d:a2:e4:67:8b


89

90 }

91

92 function config_interface_omag2() {

93 ARP_PATH=’/usr/sbin’

94 ROUTE_PATH=’/sbin’

95


97 vconfig set_ingress_map eth0.20 0 5

98 vconfig set_egress_map eth0.20 0 5


118


100

101 ifconfig eth0 up



104

105 ifconfig eth0:1 192.168.254.100 netmask 255.255.255.0



108

109 #Set ipv6 to eth0

110 ifconfig eth0 inet6 add $ETH0_OMAG2_ADDRESS

111

112 #Routes to adequate OMAG to REVIR network,

113 #this routes are not used in PMIPFlow

114 #operation since it’s IPv6 oriented.

115







122

123 #Same of Routes, only for REVIR Network, not for PMIPFlow.

124 $ARP_PATH/arp -s 192.168.20.150 00:00:00:00:00:02

125 $ARP_PATH/arp -s 192.168.21.150 00:00:00:00:00:02

126 $ARP_PATH/arp -s 192.168.20.151 00:00:00:00:00:04

127 $ARP_PATH/arp -s 192.168.21.151 00:00:00:00:00:04

128 $ARP_PATH/arp -s 192.168.20.152 00:00:00:00:00:06

129 $ARP_PATH/arp -s 192.168.21.152 00:00:00:00:00:06

130



133


119



136 }

137

138 function line(){

139 echo "___________________________";

140 }

141


143 echo "******************************";



146 echo " and initialize the PMIPFlow Framework"


148 echo "******************************";

149 }




153 echo -e "usage: $0 [OPTIONS] \n"




157 echo " -v, --version : Display verson info and exit"

158 }

159


161 screen -A -d -m -S hostapd $SCRIPTS_DIR/hostapd.sh --omag1

162

163 echo "3. Configuration Done, show interface info"

164 line

165 ifconfig eth0

166 line

167

168 echo "4. Initializing pmipflow"

169 screen -A -d -m -S pmipflow $SCRIPTS_DIR/PMIPFlow_Init.sh --omag1

120


170 #screen -ls

171

172 echo "5. Configuring $WIFI_INTERFACE"

173 ifconfig $WIFI_INTERFACE inet6 add $WIFI_OMAG1_ADDRESS

174 echo "ifconfig $WIFI_INTERFACE inet6 add $WIFI_OMAG1_ADDRESS"

175 line

176 ifconfig wlan0

177 line

178

179 echo "6. Show Screens"

180 screen -ls

181

182 echo -e "\n#-# OMAG Configured Successfully #-#\n"

183 }

184


186

187 screen -A -d -m -S hostapd $SCRIPTS_DIR/hostapd.sh --omag2

188

189 echo "3. Configuration Done, show interface info"

190 line

191 ifconfig eth0

192 line

193

194 echo "4. Initializing pmipflow"

195 screen -A -d -m -S pmipflow $SCRIPTS_DIR/PMIPFlow_Init.sh --omag2

196

197 echo "5. Configuring $WIFI_INTERFACE"

198 ifconfig $WIFI_INTERFACE inet6 add $WIFI_OMAG2_ADDRESS

199 echo "ifconfig $WIFI_INTERFACE inet6 add $WIFI_OMAG2_ADDRESS"

200

201 line

202 ifconfig wlan0

203 line

204

121


205 echo "6. Show Screens"

206 screen -ls

207

208 echo -e "\n#-# OMAG Configured Successfully #-#\n"

209

210 }

211 case $NUM_ARG in

212 0)

213 usage

214 ;;

215 1)

216 init;

217 if [ "$1" == "--omag1" ] || [ "$1" == "-om1" ]; then

218 config_interface_omag1

219 omag1

220 elif [ "$1" == "--omag2" ] || [ "$1" == "-om2" ]; then

221 config_interface_omag2

222 omag2

223 elif [ "$1" == "--help" ] || [ "$1" == "-h" ]; then

224 usage


226 about

227 fi

228 ;;

229 2)

230 ;;

231 esac

122

A.4. PMIPFLOWINIT.SH

A.4 PMIPFlowInit.sh

1 #!/bin/bash

2

3 NUM_ARG=$#

4 VERSION=’1.0’

5

6 PMIPFlow_PATH=’/usr/revir-mob/pmipflow_code/src’

7 OMAG1_CONF=’/usr/revir-mob/pmipflow_code/scripts/omag1.conf’

8 OMAG2_CONF=’/usr/revir-mob/pmipflow_code/scripts/omag2.conf’

9




13 echo -e "usage: $0 [OPTIONS] \n"




17 echo " -v, --version : Display version info and exit"

18 }

19


21 echo "Host is running as OMAG1"

22

23 $PMIP_PATH/pmipflow6d -c /usr/local/pmipflow/scripts/omag1.conf

24 }

25


27 echo "Host is running as OMAG2"

28 $PMIPFLow_PATH/pmipflow6d -c /usr/local/pmip/scripts/omag2.conf

29 }

30


32 echo "******************************";


123



35 echo " and initialize the PMIP-FLOW"


37 echo "******************************";

38 }

39

40 case $NUM_ARG in

41 0)

42 echo "No parameter, check usage out"

43 usage;;

44

45 1)

46 if [ "$1" == "--omag1" ] || [ "$1" == "-om1" ]; then

47 omag1

48 elif [ "$1" == "--omag2" ] || [ "$1" == "-om2" ]; then

49 omag2

50 elif [ "$1" == "--help" ] || [ "$1" == "-h" ]; then

51 usage


53 about

54 else

55 usage

56 fi

57 ;;

58 esac

124

A.5. OFDATAPATHX.SH

A.5 ofdatapathX.sh

Estes scripts(ofdatapath0.sh e ofdatapath1.sh) criam os switches no Gateway OpenFlow.Esse script roda o OpenFlow de referência disponível em (Stanford, 2012), ele usa asinterfaces "eth2.20"e "eth3.21"como portas do switch, além de criar interfaces virtuaisinternas chamadas tap0 e tap1. Outro detalhe é a alta prioridade que se dá ao processoque roda o OpenFlow, usa-se o comando $PRIO_PATH/nice -18 para fornecer talprioridade, fazendo com que está máquina se torne uma espécia de switch dedicado, destemodo, melhorando o desempenho de operações como entrada de pacotes, manipulaçaode tabelas e encaminhamento.

ofdatapath0.sh

1 #!/bin/bash

2

3 OPENFLOW_PATH=’/usr/local/bin’

4 PRIO_PATH=’/usr/bin’

5

6 $PRIO_PATH/nice -18 $OPENFLOW_PATH/ofdatapath -v |\

7 --detach punix:/var/run/dp1 ptcp:6363 -i eth2.20,eth3.21 |\

8 --local-port=tap:tap1 -d 000000000002 --no-slicing | \

9

10 $PRIO_PATH/nice -18 $OPENFLOW_PATH/ofprotocol |\

11 unix:/var/run/dp1 tcp:192.168.254.1:6635 --out-of-band

ofdatapath1.sh

1 #!/bin/bash

2

3 OPENFLOW_PATH=’/usr/local/bin’

4 PRIO_PATH=’/usr/bin’

5

6 $PRIO_PATH/nice -18 $OPENFLOW_PATH/ofdatapath -v |\

7 --detach punix:/var/run/dp1 ptcp:6363 -i eth2.20,eth3.21 |\

8 --local-port=tap:tap1 -d 000000000002 --no-slicing | \

9

125


10 $PRIO_PATH/nice -18 $OPENFLOW_PATH/ofprotocol |\

11 unix:/var/run/dp1 tcp:192.168.254.1:6635 --out-of-band

126

A.6. PMIPFLOW-LMA

A.6 PMIPFlow-LMA

Esta Seção do apêndice apresenta o código fonte do componenete NOX implementadopara a aquietetura PMIPFLow, nomeado de PMIPFlow-LMA.

1#include <cstring>

2#include <netinet/in.h>

3#include <stdexcept>

4#include <stdint.h>

5#include <string>

6

7#include <boost/bind.hpp>

8#include <boost/foreach.hpp>

9

10#include <tbb/concurrent_hash_map.h>

11

12#include "assert.hh"

13#include "component.hh"

14#include "vlog.hh"

15

16#include "netinet++/datapathid.hh"

17#include "netinet++/ethernetaddr.hh"

18#include "netinet++/ethernet.hh"

19

20#include "openflow/openflow-event.hh"

21#include "openflow/openflow-datapath-join-event.hh"

22#include "openflow/openflow-datapath-leave-event.hh"

23

24#include "pmipv6_lma.h"

25

26using namespace vigil;

27using namespace openflow;

28

29namespace pmipflow_lma

30{

127


31

32Vlog_module lg("PMIPFlow-lma");

33

34class PMIPFlow : public Component

35{

36public:

37 PMIPFlow(const Component_context* c)

38 : Component(c)

39 {

40 setup_flows = true; // default value

41 }

42

43 void pmipflow-lma_callback(auto& dp, v1::ofp_match flow);

44

45 void configure();

46

47 void install() {}

48

49 Disposition handle_datapath_join(const Event&);

50 Disposition handle_datapath_leave(const Event&);

51 Disposition handle_packet_in(const Event&);

52

53private:

54

55 LMA *lma;

56

57 struct datapath_hasher {

58 static size_t hash(const datapathid& o) {

59 return boost::hash_value(o.as_host());

60 }

61 static bool equal(const datapathid& o1, const datapathid& o2)

62 {

63 return o1 == o2;

64 }

65 };

128

A.6. PMIPFLOW-LMA

66typedef

67boost::unordered_map<ethernetaddr, int> mac_table;

68typedef

69tbb::concurrent_hash_map<datapathid, mac_table, datapath_hasher>

70 mac_table_map;

71

72 mac_table_map mac_tables;

73

74 bool setup_flows;

75};

76

77inline void

78PMIPFlow::configure()

79{

80

81 lma = new LMA(this);

82

83 if (ctxt->has("args")) {

84 BOOST_FOREACH (const std::string& arg,

85 ctxt->get_config_list("args"))

86 {

87 if (arg == "noflow")

88 {

89 setup_flows = false;

90 }

91 else

92 {

93 VLOG_WARN(lg,

94 "argument \"%s\" not supported", arg.c_str());

95 }

96 }

97 }

98 register_handler("Openflow_datapath_join_event",

99 (boost::bind(&Switch::handle_datapath_join, this, _1)));

100 register_handler("Openflow_datapath_leave_event",

129


101 (boost::bind(&Switch::handle_datapath_leave, this, _1)));

102 register_handler("ofp_packet_in",

103 (boost::bind(&Switch::handle_packet_in, this, _1)));

104}

105

106inline Disposition

107PMIPFlow::handle_datapath_join(const Event& e)

108{

109 auto& dpje = assert_cast<const Openflow_datapath_join_event&>(e);

110 mac_tables.insert(std::make_pair(dpje.dp->id(), mac_table()));

111 return CONTINUE;

112}

113


115PMIPFlow::handle_datapath_leave(const Event& e)

116{

117 auto& dple = assert_cast<const Openflow_datapath_leave_event&>(e);

118 mac_tables.erase(dple.dp->id());


120}

121

122void

123PMIPFlow::pmipflow-lma_callback(auto& dp, v1::ofp_match flow){

124

125 mac_table_map::accessor accessor;

126 mac_tables.find(accessor, dp.id());

127 auto& mac_table = accessor->second;

128

129 // Learn the source MAC

130 if (!flow.dl_src().is_multicast())

131 {

132 mac_table[flow.dl_src()] = pi.in_port();

133 }

134

135 if (!flow.dl_dst().is_multicast())

130

A.6. PMIPFLOW-LMA

136 {

137 auto it = mac_table.find(flow.dl_dst());

138 if (it != mac_table.end())

139 out_port = it->second;

140 }

141

142 // Set up a flow if the output port is known

143 if (setup_flows && out_port != -1)

144 {

145 auto& fm = v1::ofp_flow_mod()

146 .match(flow).buffer_id(pi.buffer_id())

147 .cookie(0).command(v1::ofp_flow_mod::OFPFC_ADD).idle_timeout(5)

148 .hard_timeout(v1::OFP_FLOW_PERMANENT)

149 .priority(v1::OFP_DEFAULT_PRIORITY);

150

151 auto& ao = v1::ofp_action_output().port(out_port);

152 fm.add_action(&ao);

153 dp.send(&fm);

154 }

155

156 // Send out packet if necessary

157 if (!setup_flows || out_port == -1 || pi.buffer_id() == UINT32_MAX)

158 {

159 if (out_port == -1)

160 out_port = v1::ofp_phy_port::OFPP_FLOOD;

161

162 auto& po = v1::ofp_packet_out().in_port(pi.in_port());

163 auto& ao = v1::ofp_action_output().port(out_port);

164 po.add_action(&ao);

165

166 if (pi.buffer_id() == UINT32_MAX)

167 {

168 if (pi.total_len() != boost::asio::buffer_size(pi.packet()))

169 {

170 pi.total_len(),

131


171 boost::asio::buffer_size(pi.packet()));


173 }

174 po.packet(pi.packet());

175 }

176 else

177 {

178 po.buffer_id(pi.buffer_id());

179 }

180 dp.send(&po);

181 }

182

183}

184


186PMIPFlow::handle_packet_in(const Event& e)

187{

188 auto ofe = assert_cast<const Openflow_event&>(e);

189 auto& dp = ofe.dp;

190 auto pi = *(assert_cast<const v1::ofp_packet_in*>(ofe.msg));

191 int out_port = -1; // Flood by default

192

193 v1::ofp_match flow;

194 flow.from_packet(pi.in_port(), pi.packet());

195

196 // Drop all LLDP packets

197 if (flow.dl_type() == ethernet::LLDP)

198 {


200 }

201

202 //This function made the connection of pmipflow-lma

203 function in "lma.cc"

204 lma.pmipflow-lma_connect( flow,dp, pmipflow-lma_callback);

205

132

A.6. PMIPFLOW-LMA


207}

208

209REGISTER_COMPONENT(Simple_component_factory<PMIPFlow>, PMIPFlow);

210

211} // pmipflow_lma namespace

133

BInstalação

Nesta seção, serão abordados alguns processos de instalação importantes para a arquite-tura PMIPFlow.

B.1 FlowVisor

Para a criação de Slices ou Fatias na rede OpenFlow utiliza-se um Controlador especialchamado FlowVisor, os pacotes que chegam no FlowVisor são encaminhados para ocontrolador correspondente de acordo com determinadas políticas previamente instaladasno FlowVisor.

1 $Add deb http://updates.flowvisor.org/openflow/downloads/GENI/DEB \

2 unstable/binary-$(ARCH)/ to your /etc/apt/sources.list

3 $sudo apt-get update

4 $sudo apt-get install flowvisor

B.2 Recompilar o Kernel

Para rodar os OMAGs no ubuntu é necessário recompilar o kernel com algumas informa-ções adicionais referentes à mobilidade. Primeiramente, é necessário baixar os códigosfontes do novo kernel, para isso é necessário instalar os pacotes básicos.

No Ubuntu 12.04:

1. Instalando os pacotes necessários para recompilar o kernel

135

APÊNDICE B. INSTALAÇÃO

1 $sudo apt-get update

2 $sudo apt-get install kernel-package \

3 libncurses5-dev fakeroot wget bzip2

2. Fazendo o download do código fonte do kernel

1 $cd /usr/src

2 $wget http://www.kernel.org/pub/linux/kernel/v3.0/ \

3 linux-3.0.43.tar.bz2

Verifique est baixamos uma versão estável do kernel 3.0, é possível baixar qualquerversão, porém apenas as estáveis são mais recomendadas pela certeza da ausência debugs graves.

Após o download descompacta-se e cria-se um link simbólico para facilitar a localiza-ção dos código fontes do kernel.

1 $tar xjf linux-3.3.7.tar.bz2

2 $ln -s linux-3.3.7 linux

3 $cd /usr/src/linux

O proximo passo é configura o novo kernel. Este é o ponto mais importante da pois énas configurações que vamos dizer ao kernel quais os parametros deverá habilitar parasuportar o PMIPv6.

3. Configurando o KernelPrimeiramente copia-se a configuração atual do kernel para termos um ponto de

partida.

1 $cp /boot/config-‘uname -r‘ ./.config

O código “uname -r” retorna a versão atual do kernel, mas na maioria das vezes sóexistirá um arquivo “config...” na pasta /boot.

Agora vamos a configuração do kernel.

1 $make menuconfig

136

B.2. RECOMPILAR O KERNEL

O comando acima cria um menu de configurações do kernel, a figura abaixo mostracomo é a cara do menu. Para o pmip será necessário habilitar algumas configurações.make menuconfig imagem Abaixo, as variáveis que preciam ser setadas, a maioria delasestão em :

Networking Support->Networking options

CONFIG_XFRM_USER

Transformation user configuration interface

CONFIG_IPV6_MIP6

->The Ipv6 protocol

Ipv6: Mobility (EXPERIMENTAL)

CONFIG_XFRM_SUB_POLICY

Transformation sub policy support (EXPERIMENTAL)

CONFIG_INET_XFRM_MODE_ROUTEOPTIMIZATION

IPv6: MIPv6 route optimization mod (EXPERIMENTAL)

CONFIG_IPV6_SUBTREES

IPv6: Source address based routing

CONFIG_IPV6_TUNNEL

IPv6: IP-in-ipv6 tunnel (RFC 2473)

CONFIG_NET_KEY

PF_KEY_SOCKETs

CONFIG_NET_KEY_MIGRATE

PF_KEY MIGRATE (EXPERIMENTAL)

CONFIG_INET6_ESP

IPv6: ESP transformation

Para checar se tudo está como deveria, existe um script dentro da pasta do pmip6dchamado chkconf_kernel.

Vai na pasta do pmip6d e execute:

1 $./chconf_kernel.sh /usr/src/linux

Ao executar este script antes da configuração do kernel a saída da janela será seme-lhante à esta:

Imagem antes da configuraçãoE depois da configuração:

137

APÊNDICE B. INSTALAÇÃO

Imagem depois da configuração4. Construindo o Kernel

1 $make kpkg clean

2 $fakeroot make-kpkg --initrd \

3 --append-to-version=-pmipflow kernel_image kernel_headers

“pmipflow” é o nome que será adicionado ao kernel para identificá-lo no grub.5. Instalando o novo KernelApós a compilação será possivel ver os dois arquivos DEBs criados.

1 $cd /usr/src

2 $ls -l

imagem dos DEBs criadosAgora é só instalar o debs como se fosse um pacote ubuntu convencional.

1 $dpkg -i linux-image-3.0.43-pmipflow_3.0.43-pmipflow- \

2 10.00.Custom_i386.deb

3 $dpkg -i linux-headers-3.0.43-pmipflow_3.0.43-pmipflow- \

4 10.00.Custom_i386.deb

Agora é reiniciar o sistema.

1 $shutdown -r now

Pronto, se tude der certo o poderar escolher, no grub, o novo kernel. Após a instalaçãodo novo Kernel alguns pacotes e aplicativos foram instalados

Software instaladosPrimeiramente atualizar as listas do repoditório

1 $apt-get update

1. Wireshark para o monitoramento de pacotes

1 $sudo apt-get install wireshark

138

B.2. RECOMPILAR O KERNEL

2. Screen para criar terminais remotos e facilitar a visualização dos outputs dosscripts

1 $sudo apt-get install screen

Para listar os terminais virtuais basta digitar:

1 $screen -ls

Para acessá-los basta digitar

1 $screen -r <nome ou pid do terminal>

Para matar o terminal basta acessá-lo e digitar Ctrl+CPara descontectar do terminal Crtl + A e depois Ctrl+D

B.2.1 Linux em AP mode

Dar detalhes da placa wireless utilizada imagem e configuração da placaPara colocar o linux em modo AP precisamos instalar o hostapd

1 $apt-get install hostapd

[hostapd reference] http://wireless.kernel.org/en/users/Documentation/hostapdApós instalar o hostapd, criei o aquivo em /etc/hostapd/hostapd_mag.conf

nele foi inserido alguns comandos de sinalização:

1 "hostapd_mag.conf"

2 #AP Mode Configuration

3 interface=wlan0

4 driver=nl80211

5 ssid=mag1

6 channel=1

139

Edson Adriano Maravalho Avelar - repositorio.ufpe.br§ao... · para as redes, e permitindo...

Documents

Transcript of Edson Adriano Maravalho Avelar - repositorio.ufpe.br§ao... · para as redes, e permitindo...