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 MestradoUniversidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
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
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.
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 para concluir este trabalho.
Ao meu orientador, Kelvin Dias, que sempre me ajudou e me deu a oportunidade de realizar o sonho de concluir o mestrado. Sem ele, a realização deste trabalho não seria possível.
Agradeço à minha família, meus pais Baltasar e Marinete e meus irmãos Umbelino e Karine, 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 chegar onde cheguei.
"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 dificuldades em 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 incorporados nas redes, mas com limitações, através de constantes incrementos/remendos na pilha TCP/IP (Transmission Control Protocol/Internet Protocol). Assim, a pesquisa sobre arquitetura para Internet do Futuro (FI) chegou a um impasse, ao qual convencionou-se denominar de engessamento da Internet.
Com a proliferação de smartphones, tablets e uma infinidade de dispositivos/sensores conectados à Internet, embarcados em veículos (carros, ônibus etc.) ou robôs (por exemplo, para monitoramento ambiental, de tráfego e energia, além da segurança dos cidadãos), há necessidade de um gerenciamento de mobilidade eficiente e escalável, a fim de garantir tanto a obtenção das informações coletadas por objetos/sensores móveis conectados às redes sem fio nas futuras cidades inteligentes, quanto para permitir a continuidade do serviço para usuários móveis.
Nas pesquisas sobre arquiteturas para Internet do Futuro, a academia e a indústria estão apostando nas redes definidas por software (SDN/Software-Defined Networks) e, particularmente, na plataforma OpenFlow. Essas tecnologias surgem para auxiliar nas soluções dos problemas supracitados e são alvo de muitas pesquisas em arquiteturas para Internet do Futuro. Na filosofia SDN, o plano de controle é separado do plano de dados dentro dos comutadores, fornecendo, desta forma, programabilidade e flexibilidade para as redes, e permitindo extensão e inovação. No entanto, ainda não há uma solução consolidada para mobilidade do terminal em arquiteturas SDN.
Esta dissertação propõe e avalia uma nova arquitetura de gerenciamento de mobilidade 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 ponto de acesso) baseado na lógica fuzzy. Os resultados de desempenho demonstram a eficácia da proposta no fornecimento de mobilidade transparente e continuidade de serviço ao usuário, bem como o suporte adequado para os requisitos de tráfego de vídeo em termos de 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.
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 such as mobility support and quality of experience (QoE). Currently, those requirements for mobile users and multimedia applications are incorporated, but with limitations, into the networks 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 or sensors connected to the Internet, embedded into vehicles or inside robots (e.g., for environmental, traffic, energy monitoring and citizen security), requires scalable and efficient mobility management in order to grant the service continuity for both the mobile users as well as the decision makers of future smart cities which may benefit from mobile networks.
Toward the Future Internet, the academia and industry are betting on the so called Software Defined Networks (SDNs) and, particularly, OpenFlow platform. They arise to assist on solutions to the aforementioned issues and are the mainstream of many researches on Future Internet architectures. SDNs philosophy separates the control from data plane of network switches, thus permitting programmability and flexibility into the network. However, there is still no consolidated solution to terminal mobility in SDNs.
This dissertation proposes and evaluates a novel SDN based mobility management architecture for Future Internet. The proposal is implemented in an OpenFlow/802.11 testbed. In order to provide seamless mobility, a handover (change of access point) decision mechanism based on a fuzzy system is developed. The performance results demonstrated the effectiveness of the proposal in providing seamless mobility e service continuity, as well as the adequate support to the video traffic requirements in terms of QoS/QoE metrics.
Keywords: OpenFlow, Software-Defined Network, Mobility Management, PMIP, Network Virtualization, Programable Mobile Networks.
Conteúdo
Lista de Figuras xix
Lista de Tabelas xxi
Lista de Acrônimos xxiii
1 Introdução 1 1.1 Objetivos da Pesquisa . . . 3 1.1.1 Objetivo Geral . . . 3 1.1.2 Objetivos Específicos . . . 3 2 Trabalhos Relacionados 5 2.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 15 3.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
3.6 Considerações Finais . . . 23
4 Gerenciamento de Mobilidade 25 4.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
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
4.5 Considerações Finais . . . 41 5 Arquitetura PMIPFlow 43 5.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
5.4 Considerações Finais . . . 58
6 Proposta de Antecipação de Handover 59 6.1 Sistema PMIPFlow(Fuzzy) . . . 60
6.2 Variáveis de Entrada . . . 62
6.3 Conjuntos Fuzzy . . . 64
7 Protótipo 69
7.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 7.2 Considerações Finais . . . 78 8 Avaliação 79 8.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 8.6 Considerações Finais . . . 100 9 Conclusão 101 9.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 113 A.1 Hostapd . . . 113 A.2 NTP.sh . . . 115 A.3 PMIPFlowSetup.sh . . . 116 A.4 PMIPFlowInit.sh . . . 123 A.5 ofdatapathX.sh . . . 125
A.6 PMIPFlow-LMA . . . 127
B Instalação 135
B.1 FlowVisor . . . 135 B.2 Recompilar o Kernel . . . 135 B.2.1 Linux em AP mode . . . 139
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
8.1 Planta baixa do ambiente de teste . . . 80
8.2 Mapeamento da intensidade do sinal no ambiente de teste para o OMAG1 80 8.3 Mapeamento da intensidade do sinal no ambiente de teste para o OMAG2 81 8.4 Movimentação do MN no ambiente de teste . . . 82
8.5 Teste de capacidade da rede sem fio . . . 82
8.6 Gráfico de atraso dos pacotes . . . 83
8.7 Intervalo dos dados de atraso de pacotes . . . 84
8.8 Vazão do tráfego UDP limitado à 10Mbps . . . 85
8.9 Intervalo da Média da Vazão do tráfego UDP limitado à 10Mbps . . . . 86
8.10 Vazão do tráfego UDP limitado à 20Mbps . . . 87
8.11 Intervalo da Média da Vazão do tráfego UDP limitado à 20Mbps . . . . 87
8.12 Gráfico em barra da porcentagem de Perdas de Pacotes . . . 88
8.13 Gráfico em linha dos dados da porcentagem de Perdas de Pacotes . . . . 89
8.14 Gráfico de intervalo de variação dos dados da porcentagem de Perdas de Pacotes . . . 89
8.15 Comparação entre o PSNR do vídeo 160x90 com e sem a proposta . . . 91
8.16 Intervalo do PSNR do vídeo 160x90 com e sem a proposta . . . 92
8.17 Comparação entre o PSNR do vídeo 320x180 com e sem a proposta . . 93
8.18 Intervalo do PSNR do vídeo 320x180 com e sem a proposta . . . 93
8.19 Comparação entre o PSNR do vídeo 640x360 com e sem a proposta . . 94
8.20 Intervalo do PSNR do vídeo 640x360 com e sem a proposta . . . 95
8.21 Comparação entre o SSIM do vídeo 160x90 com e sem a proposta . . . 96
8.22 Intervalo do dados de SSIM do vídeo 160x90 com e sem a proposta . . 96
8.23 Comparação entre o SSIM do vídeo 320x180 com e sem a proposta . . 97
8.24 Intervalo do dados de SSIM do vídeo 320x180 com e sem a proposta . . 97
8.25 Comparação entre o SSIM do vídeo 640x360 com e sem a proposta . . 98
8.26 Intervalo dos dados de SSIM do vídeo 640x360 com e sem a proposta . 98 8.27 Frame 598 no instante do handover com o PMIPFlow e com o PMIP-Flow(Fuzzy) . . . 99
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 . . . 66
6.2 Valores de Classificação do PSNR . . . 66
6.3 Regras de Inferência . . . 68
8.1 Estatística descritiva para o atraso dos pacotes . . . 85
8.2 Estatística descritiva para vazão de 10Mbps . . . 86
8.3 Estatística descritiva para vazão de 20Mbps . . . 88
8.4 Estatística descritiva para Porcentagem de Perdas de Pacotes . . . 90
8.5 Valores de Classificação do PSNR . . . 91
8.6 Vídeos utilizados nos testes . . . 91
8.7 PSNR do vídeo com resolução 160x90 . . . 92
8.8 PSNR do vídeo com resolução 320x180 . . . 93
8.9 PSNR do vídeo com resolução 640x360 . . . 95
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
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
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
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
Wi-Fi Wireless Fidelity
WiMAX Worldwide Interoperability for Microwave Access WLAN Wireless LAN
1
Introduçã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, estamos saindo de um cenário onde o ecossistema de serviços e infraestrutura era fechado e proprietário e passa a ser aberto e livre (Yap et al., 2010b). Entretanto, no contexto de infraestrutura e equipamentos de rede, as soluções, em geral, permanecem fechadas e proprietárias em função das estratégias de mercado dos principais fabricantes, bem como, 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ão incorporados à pilha TCP/IP (Transmission Control Protocol/Internet Protocol) por meio de remendos. Isto cria um impasse, comumente chamado de engessamento da Internet e torna as redes complexas, de difícil gerenciamento, não extensíveis e fechada para inovaçã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ção das redes cabeadas e sem fio. A ideia do conceito SDN é separar claramente o plano de dados do plano de controle. Desta forma, é possível usufruir de várias vantagens, como dispor de um controle maior da rede, de monitoramento eficiente e de um controlador com 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 conferida a este novo conceito.
Outra tecnologia importante neste processo é a virtualização. No sentido amplo em computação, a virtualização é uma estratégia para resolver muitos problemas e criar
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 de seus recursos entre vários ambientes virtuais. Já servidores virtuais permitem hospedar múltiplos sistemas operacionais e aplicações. No caso da virtualização de redes, recursos podem ser divididos em fatias, considerando cada roteador como um elemento que pode ser 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, entre outros. Isso porque ela desacopla a função executada por um sistema de sua parte física. A virtualização de redes pode ser alcançada através de várias formas, utilizando máquinas virtuais como roteadores ou por meio de redes programáveis, como é feito com o 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), normalso-mente implementadas por comutadores (switches) Ethernet, com tabelas de encaminhamento internas e uma interface padrão para adicionar e remover entradas de fluxos. Assim, torna-se viável testes de novos protocolos em 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/sensores conectados à Internet, embarcados em veículos (carros, ônibus etc.) ou robôs (por exemplo, para monitoramento ambiental, de tráfego e energia, além da segurança dos cidadãos), há necessidade de um gerenciamento de mobilidade eficiente e escalável, a fim de garantir tanto a obtenção das informações coletadas por objetos/sensores móveis conectados às redes sem fio, quanto para permitir a continuidade do serviço para usuários mó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 dispositivo decorrente de sua movimentação e/ou devido à busca por melhores canais.
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 ponto de acesso) baseado na lógica fuzzy (Klir and Yuan, 1995). Os resultados de desempenho demonstram 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áfego de 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 desenvolvida nesta dissertação.
1.1.1
Objetivo Geral
O objetivo geral é desenvolver uma arquitetura para o gerenciamento de mobilidade em redes definidas por software. Com isso, os benefícios da programabilidade de redes serão também estendidos para redes sem fio. Além disso, para garantir transferência transparente de terminal, outro objetivo é desenvolver um sistema para auxiliar na tomada de decisão do handover.
1.1.2
Objetivos Específicos
• Realizar pesquisas em gerenciamento de mobilidade no contexto de redes definidas por 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, slicesou fatias, controlador entre outros.
• Caracterizar e desenvolver um sistema baseado em lógica fuzzy para auxiliar na tomada de decisão de handover.
• Avaliar a proposta em um testbed OpenFlow/IEEE 802.11(Wi-Fi) usando métricas de QoS e QoE.
CAPÍTULO 1. INTRODUÇÃO
Esta dissertação está dividida da seguinte forma. No Capítulo 2, são apresentados os trabalhos relacionados à esta pesquisa. O Capítulo 3 discute a necessidade de uma nova arquitetura para as redes tradicionais. A teoria e os conceitos por trás de gerenciamento de mobilidade IP serão abordados no Capítulo 4. Em seguida, no Capítulo 5, será discutida a arquitetura do PMIPFlow, abordando desde a sinalização, conexão e handover, até sua implementação no ambiente Linux. O Capítulo 7 foi reservado para discussões sobre o desenvolvimento do protótipo do PMIPFlow, explicando a implementação de cada entidade da arquitetura. Para melhorar ainda mais a solução PMIPFlow, e adequá-la para serviços de tempo real, criou-se o PMIPFlow(Fuzzy), que é uma proposta de antecipação de handover utilizando lógica fuzzy, essa proposta está detalhada no Capítulo 6. A avaliação da arquitetura e da proposta PMIPFlow(Fuzzy) será discutida no Capítulo 8, 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 destaca as considerações finais e discute alguns direcionamentos para trabalhos futuros.
2
Trabalhos Relacionados
"As oportunidades multiplicam-se à medida que são agarradas" —SUN TZU
Este capítulo apresenta os trabalhos relacionados ao PMIPFlow. Ele está dividido em três subseções. A seção 2.1 mostra alguns trabalhos relacionados ao protocolo PMIP, o qual serviu como inspiração para o PMIPFlow. A seção 2.2 aborda artigos sobre gerenciamento de mobilidade em redes OpenFlow. Na seção 2.3 são discutidos os trabalhos 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 utilizam o PMIP como protocolo na execução do handover.
O Artigo (Obele and Kang, 2009) propõe um esquema proativo de handover sensível ao 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 do terminal. Quando o cMAG (current MAG) percebe que o nível de sinal do equipamento do usuário, MN (Mobile Node), está caindo, ele inicia de forma proativa o procedimento de handover. 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ções obtidas. A ideia é trocar a sinalização de handover antes de o MN migrar efetivamente para 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
CAPÍTULO 2. TRABALHOS RELACIONADOS
PBU.
A análise da proposta baseia-se nas trocas de mensagens durante o processo de handover. A proposta é confrontada com o PMIPv6 padrão, a comparação é feita usando as métricas tempo de handover versus o atraso do enlace sem fio. Alguns pontos importantes deixaram de ser explicados neste trabalho. Por exemplo, os autores não informam como o PBU foi modificado para incluir informações referentes ao QoS requerido 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ão descrevem como framework foi inserido no trabalho. Talvez a avaliação de desempenho esteja 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 para prover seamless handover, este esquema foi nomeado de B-PMIPv6. A ideia consiste no 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 para prover seamless handover em redes IEEE 802.16e (WiMAX Móvel). O esquema propõe o acré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 os autores chamam de FPBU ou Fast PBU. O FBPU utiliza o endereço contido na mensagem HI (Handover Initiate) para antecipação. É utilizado um buffer no nMAG para evitar a perda de pacotes
A análise da proposta baseia-se nas trocas de mensagens durante o processo de handover. A proposta é comparada com o PMIPv6 e com o PFMIPv6. A análise mostra que a proposta é melhor que as outras, em termos de latência do handover, isto porque a mensagem FPBU é mais eficiente que a PBU.
Enquanto o PMIPv6 trabalha com o BU após o handover da camada de enlace, a proposta do artigo trabalho com o BU durante a troca nesta camada. Uma dos pontos negativos dessa proposta é a profunda modificação necessária no padrão PMIP e a utilização de buffers, que pode prejudicar tráfego sensíveis ao atraso.
proce-2.1. MOBILIDADE E PMIP
dimento do handover. Na proposta do artigo a otimização é feita em conjunto com o procedimento de handover acelerando o processo. A análise da proposta baseia-se nas trocas de mensagens durante o processo de handover. A ideia é, quanto menor o número de mensagens mais rápido é o processo de handover. A vantagem dessa abordagem é a inicializaçã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 o nMAG, o LMA inicia o procedimento diretamento com o nMAG
O trabalho (Ryu et al., 2009) apresenta o PFMIPv6 (Fast Handover for PMIPv6) e propõ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. No PFMIPv6 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 que os pacotes sejam enviadas do nMAG diretamente para o LMA, e não do nMAG para o pMAG como acontece com o PFMIPv6.
A avaliação da proposta foi baseada em cima de análise matemática utilizando um modelo 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 muito bem 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 mostra de 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 para auxiliar 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 o MN vai do MAG1 para o MAG2. Foram feitas duas simulações, com e sem MIH. O handoff durou 0.4 e 0.12 e foram perdidos 38 e 12 pacotes, sem e com a utilização do MIH, respectivamente.
O handover é heterogêneo entre as tecnologias WLAN (Wireless LAN) (MAG1) e WiMax (MAG2). Apesar de a utilização do MIH trazer vários benefícios, existe o risco de sobrecarga de mensagens causadas pelo MIH se for usado de forma inapropriada. A análise da proposta não apresenta dados estatísticos para confirmar os ganhos obtidos.
CAPÍTULO 2. TRABALHOS RELACIONADOS
de rota, RO (Route Optimization), para prover transferência transparente do usuário entre domínios PMIPv6. A ideia é emprestar o mecanismo utilizado no protocolo FMIPv6 ( Fast Handover MIPv6) para tornar transparente o handover no PMIPv6. A chave da proposta 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 outro com MAGs conectados em diferentes LMAs. A simulação feita pelo artigo mostra o benefício da proposta em comparação com o PMIPv6 padrão, porém não é informado o simulador, nem um possível patch PMIPv6, tampouco, parâmetros que foram utilizados na simulação.
Em (Hwang et al., 2010) é proposto um esquema de handover transparente baseado em multicasting. A ideia do artigo é bufferizar os pacotes no momento do handover e transmiti-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 quando este termina o processo de handover.
Para a avaliação da proposta utilizou-se o NS-2, não foram fornecidos nenhum tipo de dados de desempenho das simulações, nem o patch utilizado. Não há perdas de pacotes utilizando este método, uma vez que todos os pacotes são guardados e transmitidos posteriormente. Por outro lado, a proposta pode gerar uma grande inundação de pacotes desnecessá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 pacotes para minimizar a latência e as perdas do processo de handover, levando em consideração aplicações multicast. Três esquemas de handover são avaliados, Dois intra-LMA e o um inter-LMA. O MLD (Multicast Listener Discovery) é utilizado para Descoberta de Endereços Multicast.
Na proposta, o encaminhamento de pacotes é feito de 3 formas: do pMAG para o nMAG, 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 e utilizando buffer para armazenar os pacotes durante o processo de roteamento.
Para avaliar a proposta utilizaram-se métodos numéricos. Assim como é feito na maioria dos artigos de handover, a análise do custo de sinalização é calculada a partir do número de mensagens trocadas no processo de handover. Os resultados mostraram que o esquema 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 apresentados no artigo.
2.1. MOBILIDADE E PMIP
Os autores em (Yi et al., 2010) propõem um novo esquema para o gerenciamento de mobilidade usando o PMIPv6 baseado no redirecionamento de mensagens para minimizar a 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 no padrã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 PMIPv6 tradicional. É utilizado um modelo analítico de mobilidade baseado em cadeia de markov para realizar a comparação entra as duas propostas. Os resultados mostram um ganho de desempenho quando se utiliza o Pointer Forwarding em comparação com esquema tradicional do PMIPv6.
Em (Taghizadeh et al., 2011) os autores dizem que o PMIPv6 é muito eficiente para reduzir a latência do processo de handover, principalmente por separar a conexão de rádio da mobilidade IP. No entanto, o PMIPv6 é limitado à mobilidade intra domínio. Este trabalho faz um estudo comparativo das várias propostas de PMIPv6 em cenários inter domínios.
(Taghizadeh et al., 2011) ainda, comparam quatro cenários para implementar o PMIPv6 em escala global: single domain, Hierarchical Multi-domain, Peer Multi-Domain e I-PMIP. A avaliação é feita utilizando-se modelos matemáticos. As propostas são avaliadas em termos de Latência de Handover. Os parâmetros variáveis são: probabilidade de falha no meio sem fio, distância entre o LMA e o MAG e distância entre os MAGs e as redes vizinhas. A conclusão é que, baseado nos resultados da análise numérica, a proposta Peer Multi-domain se mostra mais vantajosa que as outras e tem um grande potencial para ser implementada de modo distribuído.
Os autores em (Kim et al., 2011) afirmam que a maioria dos protocolos de mobilidade são baseados em um cenário com uma unidade âncora centralizada, pelo qual todos o trá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ês alternativas de protocolos de gerenciamento de mobilidade, são eles: PDMC (Partially Distributed Mobility Control), DDMC (Data-driven Distributed Mobility Control) e SDMC (Signal-driven Distributed Mobility Control).
Esses protocolos são comparados com o PMIP em termos de binding update e custo de entrega de pacotes, a fim de provar sua eficácia. A comparação é feita através de análise numérica. Os resultados mostram que todos as propostas distribuídas são melhores que o PMIP centralizado, e dentre as três, a que se se mostrou melhor foi a SDMC.
CAPÍTULO 2. TRABALHOS RELACIONADOS
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ões para 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 (Yap et al., 2010a) discute como as redes sem fio ainda estão paradas no tempo, fechadas e sem inovação. Porém, os autores não fornecem uma proposta para melhorar o processo de handover do usuário, no próprio trabalho os autores admitem a existência de desconexão no handover e que fica a critério do desenvolvedor implementar aplicações NOX para gerenciamento de mobilidade da rede.
Os autores em (Nakauchi et al., 2011) propõem uma plataforma de virtualização cognitiva, chamada AMPHIBIA. A qual possibilita a criação de slices fim-a-fim sobre redes virtuais cabeadas e sem fio. Porém Os autores afirmam que o foco da virtualização está 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) e 4WARD (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 que esta nova arquitetura SDN seja utilizada alguns problemas precisam ser resolvidos como: suporte a vários assinantes, mobilidades frequentes, controle e medições mais apuradas da rede e adaptações em tempo real.
Os autores fornecem uma interessante explicação sobre o funcionamento das redes LTE, 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íveis e 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 dinamiexpli-camente na rede baseada em métricas mais profundas, como PSNR (Peak Signal to Noise Ratio) ou MOS (Mean Opinion Score)
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 hoje não possuem este controle fino dos fluxos de dados passantes. Com o SDN é possível fazer uma análise profunda dos pacotes da rede e reduzir o congestionamento. O sistema LTE é bastante semelhante à arquitetura PMIP, de modo que, o PMIPFlow poderia ser implementado também nesta arquitetura de rede celular.
Os autores em (Yamasaki et al., 2011) comentam que as redes sem fio de campus são implementadas 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 VLANs aumentou tornando o seu uso quase impraticável. Os autores então propõem a utilização de um sistema de VLANs baseado no OpenFlow, desta forma criando um sistema escalável e de fácil configuração. Os autores, tranferem a ideia de VLAN para uma aplicaçã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ários baseados no GIDs.
2.3
Antecipação de Handover em redes IP
Alguns estudos abordam diversas formas de melhorar o desempenho do processo de handover. Nesta seção, serão descritos alguns trabalhos existente na literatura sobre esse tema.
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óximo estado 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 preditor mostrou-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 sucesso na antecipação de handover, porém, a proposta é limitada, pois um usuário próximo ao ponto de acesso, ou seja, com valor alto de RSS, pode não ter qualidade de serviço devido congestionamentos na rede, como abordado em (Tsukamoto et al., 2007).
O objetivo do artigo (Tsung-Nan and Po-Chiang, 2005) é reduzir a probabilidade de quebra durante o handover sobre condições de recursos limitados. Nele foi proposto um método de antecipação de handover para tráfego multimídia baseado na taxa de sucesso das entregas de pacotes (PSR/Packet Success Rate). Os autores realizam a
CAPÍTULO 2. TRABALHOS RELACIONADOS
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). Os resultados 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 que a 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 utiliza custo de serviço, segurança, consume de energia, condições e desempenho das redes como parâmetros na decisão do handover. De acordo com a avaliação do VHDF, feita no simulador NS-21, a vazão é maior especialmente quando ocorrem grandes variações no tráfego background da rede. Esse trabalho utiliza diversas variáveis de entrada para decisão de handover, porém, a avaliação no simulador, não reflete cenários reais, e o gerenciamento de mobilidade é conduzido apenas em redes tradicionais.
O artigo (Itoh et al., 2002) apresenta um algoritmo de gatilho de handover baseado na distância do terminal móvel para estação base vizinha e na intensidade do sinal recebido (RSS). O algoritmo executa o handover quando a medida de distância excede um determinado limiar e quando o RSS excede um nível dado por uma heurística. No entanto, o desempenho da proposta é menos eficiente no pior caso se comparada com outras soluções. Para resolver esse problema, os autores sugerem o uso de sistema de localização de alta fidelidade como GPS (Global Positioning System). Porém, o GPS consome bastante energia e para auxiliar no processo de handover precisaria estar em constante funcionamento, o que consumiria rapidamente a bateria de dispositivos com poucos recursos, como telefones celulares, notebooks ou tablets.
Em (Tsukamoto et al., 2007) é usado um mecanismo de decisão de handover baseado no RSS e no número de quadros retransmitidos. A proposta é avaliada em um testbed 802.11 e os resultados mostram que apenas o RSS não é capaz de de detectar com precisão a degradação da qualidade da comunicação. No entanto, o número de quadros foi capaz de detectar a queda na qualidade do serviço. Com isso, os autores sugerem a utilização apenas 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 para decisão de um processo tão complexo como o handover.
2.4. CONSIDERAÇÕES FINAIS
A aplicação de lógica fuzzy para decisão de handover em redes heterogêneas foi apresentada em (Wu, 2011). Foram utilizados o RSS, velocidade e carga do sistema como 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álculo de 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 de decisã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 tecnologia 802.11 com o protocolo de mobilidade MIPv6. As simulações foram conduzidas no frameworkOMNET++/xMIPv6 (Yousaf et al., 2008). A proposta foi comparada com outras três. Nas simulações, a solução se mostrou vantajosa, porém, toda a proposta baseada em velocidade precisa de coletas com alto grau de consumo de energia, como por exemplo, 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ário possui um papel fundamental na decisão do handover, pois uma das entradas do sistema fuzzyé a preferência do usuário. Nela o usuário deixa predeterminado se quer que o handover aconteça, se não quer ou se deixa a critério do sistema. A análise é feita através de simulação, porém, nenhuma avaliação é apresentada, deixando dúvidas sobre a eficácia da 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 alguns artigos 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 por software, porém nenhuma delas propõem uma arquitetura com protocolo de mobilidade padronizado, não apresentam nenhuma proposta de otimização de handover e não fazem avaliaçã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
CAPÍTULO 2. TRABALHOS RELACIONADOS
de decisão, mas não pode ser usado de forma isolada, é necessário alguma outra métrica que reflita a comunicação entre o terminal e a rede. Alguns trabalhos, usam quadros retransmitidos, alguns usam largura de banda e outros velocidade. O certo é que a decisão de handover precisa ser tomada usando um conjunto de métricas centradas tanto na rede quanto no usuário. O próximo capítulo mostra os conceitos por trás das redes definidas por software, que é a tendência de pesquisa mundial para solucionar o problema do engessamento da Internet.
3
Redes 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 ideia de redes engessadas e fechadas, para redes abertas, flexíveis e de rápida evolução. Isso porque através de uma interfaces padronizada e um sistema de controle externo, a filosofia SDN fornece um gerenciamento mais eficiente dos elementos da rede, separando o plano de dados do plano de controle. O OpenFlow é uma das tecnologias que implementa o conceito SDN.
Este capítulo está organizado da seguinte forma. A Seção 3.1 aborda a necessidade de uma nova arquitetura. A Seção 3.2 apresenta os princípios das redes definidas por software. A Seção 3.3 detalha as características do OpenFlow. Nessa seção, serão discutidos os componentes, protocolo e controlador, da arquitetura OpenFlow. Na seção seguinte, será apresentado o NOX, o controlador OpenFlow que foi utilizado na solução PMIPFlow. A seção 3.5 mostra como obter isolamento nas redes OpenFlow, utilizando-se o conceitos de fatias ou slices. A última seção finaliza o capítulo com as considerações finais.
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
CAPÍTULO 3. REDES DEFINIDAS POR SOFTWARE E OPENFLOW
que fizeram a indústria repensar as arquiteturas de redes tradicionais. Atualmente, as redes são hierárquicas, construídas com camadas de switches Ethernet dispostos em uma estrutura em forma de árvore. Essa arquitetura fazia sentido quando a computação cliente-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 de processamento de dados datacenters de empresas, campi, e em grandes centros urbanos que almejam o conceito de cidades inteligentes. Algumas das tendências chaves da computaçã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 dados e de tráfego, os padrões mudaram significativamente. Em contraste com aplicações cliente-servidor onde a maior parte da comunicação ocorre entre um cliente e um servidor, as aplicações atuais acessam diferentes bancos de dados e servidores. Ao mesmo tempo, os usuários necessitam de comunicação à qualquer hora, em qualquer lugar e com qualquer dispositivo. Além disso, o advento das redes sociais aumentou ainda mais o número de serviços em smartphones. Essa mudança de padrão de tráfego gera um aumente considerável no tipo e na quantidade de pacotes que 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 em ambiente corporativos. As tecnologias de rede precisam acomodar estes dispositi-vos pessoais e ao mesmo tempo proteger os dados corporatidispositi-vos e de propriedade intelectual. 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, resultando em um crescimento sem precedentes desses serviços. Unidades de negócio da empresa querem agora a agilidade para acessar aplicações, infraestrutura e ou-tros recursos de TI sob demanda. Para aumentar a complexidade, os serviços em nuvem 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 aumenta exponencialmente, é necessário um maior controle desse tráfego.
Todas essas mudanças que ocorrem na forma como o usuário interage com a rede requer 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
3.2. REDES DEFINIDAS POR SOFTWARE
maior controle, maior segurança no tratamento dos dados e que não sejam estáticas, e que 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 controle da rede está desacoplado do encaminhamento de dados e esse controle é totalmente programável (McKeown et al., 2008). A Figura 3.1 mostra a visão lógica da arquitetura SDN. A inteligência da rede está centralizada na camada de controle, que possui a visão global da rede. Com o SDN, as empresas e os operadores ganham controle sobre toda a rede, independente do fornecedor, e em um único ponto lógico, o que melhora bastante o gerenciamento da rede.
Camada de Aplicação
Aplicação
Camada de Controle SDN Software
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 dos equipamentos de rede, uma vez que a inteligência do controle da rede é transferida para o controlador, cabendo ao dispositivo de rede apenas receber instruções enviadas pelo controlador. Deste modo, switches de baixo custo podem controlar uma grande rede que antes só poderia ser controlada por equipamentos de custo bastante elevado.
Com o SDN, os operadores e administradores podem configurar a rede de forma simplificada e automatizada, ao invés de ter que analisar e modificar códigos com dezenas de linhas de configuração, espalhados entre vários dispositivos. Além disso, aproveitando a inteligência centralizada do controlador SDN, que veremos adiante, os operadores
CAPÍTULO 3. REDES DEFINIDAS POR SOFTWARE E OPENFLOW
podem alterar o comportamento da rede em tempo real e implantar novas aplicações e serviç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 esperar por 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 torna possí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 de gerenciamento 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 usando somente recursos L2 (switches Ethernet) com tabelas de fluxo internas e uma interface padrão para adicionar e remover entradas de fluxos. Uma das ideias centrais do projeto OpenFlow é disponibilizar a plataforma abertamente para que seja adotada até mesmo por fabricantes de switches.
A Figura 3.2 mostra a arquitetura do OpenFlow. Ela é composta de três partes. A primeira 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 do switchOpenFlow com o controlador. A terceira parte trata-se do protocolo utilizado nessa comunicação, chamado protocolo OpenFlow.
Uma das entidades mais importantes do OpenFlow é o controlador. Esse elemento realiza 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 dentro do controlador. A próxima seção discutirá esse importante elemento da arquitetura OpenFlow.
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ível encontrar uma implementação do OpenFlow que recebe os comando do controlador para adicionar, modificar ou remover entradas na tabela de encaminhamento. Existem
3.4. CONTROLADOR
Switch Openflow
sw
hw
Canal Seguro
Flow TableFlow Table Tabela de Fluxo Especificação do switch Openflow
Controlador Protoco lo OpenFlo w SSL
. . .
Figura 3.2: Arquitetura OpenFlow
vários controladores disponíveis. A Tabela 3.1 mostra os mais utilizados no mercado e na academia.
Existem vários controladores OpenFlow, como mostrado na Tabela 3.1, porém, para desenvolver o PMIPFlow optou-se por usar o NOX. Essa escolha foi pautada por vários motivos: o primeiro foi que a linguagem utilizada é a mesma da implementação do PMIPFlow (C/C++), e além do ganho de desempenho, a integração é mais natural. Outro motivo é o grande número de exemplos disponibilizados com o NOX, o que facilita o aprendizado e o desenvolvimento de novas propostas. Além do mais, o NOX é utilizado como controlador padrão do Mininet (Mininet, 2011), que é um simulador de redes OpenFlow bastante difundido.
3.4.1
NOX
O NOX (Nicira Networks, 2010) é um controlador OpenFlow cujo objetivo é fornecer uma interface de programação de alto nível para aplicações de rede. As aplicações de gerência e controle são implementadas em cima do NOX, essas aplicações determinam como cada fluxo se comporta dentro da rede OpenFlow. Diferente dos ambientes de rede padrão de desenvolvimento, o NOX permite um modelo de programação centralizado
1Baseado no controlador Beacon
CAPÍTULO 3. REDES DEFINIDAS POR SOFTWARE E OPENFLOW Tabela 3.1: Controladores OpenFlow
Controladores Linguagem Documentação Open Source Referência
NOX 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 de centenas de switches (suportando, milhares de hosts) e redes menores possuindo alguns servidores.
O núcleo do NOX (Nox Core) fornece aplicativos com uma visão abstrata dos recursos da rede, incluindo a topologia da rede e localização de todos os hosts detectados. Os principais 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, utilizando hardwares reais de rede, não apenas simuladores. As aplicações NOX podem controlar toda a conectividade da rede, incluindo o encaminhamento, roteamento, controle de acesso, permissão de usuários etc. Além disso, o NOX pode intervir em 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 inclui
gerenciamento central para todos os switches em uma rede, controle de admissão tanto 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 NOX fornece uma API (Application Programming Interface) de alto nível para OpenFlow bem como controles de rede de outras funções. Como foi referido anteriormente, o NOX controla os switches da rede através do protocolo OpenFlow. Por isso, requer pelo menos um switch na rede com suporte ao OpenFlow.
3.5. VIRTUALIZAÇÃO E CRIAÇÃO DE FATIAS (SLICES)
O software de controle do NOX é executado em um PC e gerencia as tabelas de encaminhamento de vários switches. Ele exporta uma interface de programação através da qual vários programas de rede (chamados de aplicações) podem ser executados. Estas aplicações podem monitorar os eventos da rede, ter acesso ao tráfego, controlar decisões de encaminhamento do switch, entre outras ações.
O NOX é capaz de realizar suas tarefas de maneira escalável, operando sobre fluxos de 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 podem determinar se, e como, transmitir o fluxo na rede, coletar estatísticas, modificar os pacotes no fluxo (por exemplo, adicionando uma tag VLAN) ou decidir analisar outros pacotes dentro 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 de erros.
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 NOX clá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 ou slices, 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ícios como 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ém pode ser aplicada em ambientes sem fio. A Figura 3.3 mostra que um usuário utilizando um serviço de vídeo conferência pode ser alocado em um slice com maior prioridade e um usuário navegando na web em outro, com menor prioridade. Desta forma, é possível criar slices e alocar usuários de acordo com as restrições de QoS das aplicações que rodam em seu dispositivo móvel.
O FlowVisor é um controlador OpenFlow especial que atua como uma camada transparente entre o comutador OpenFlow e múltiplos controladores. Atuando desta forma, o FlowVisor pode criar fatias de recursos na rede e delegar cada fatia para um controlador diferente. Esses slices podem ser definidos de várias formas: por portas, por
CAPÍTULO 3. REDES DEFINIDAS POR SOFTWARE E OPENFLOW
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. O FlowVisor mantém o isolamento entre os slices, ou seja, nenhum slice pode controlar o tráfego de outro slice.
A Figura 3.4 exibe um possível cenário de utilização do FlowVisor. Nele é possível ver uma rede OpenFlow composta por um switch, dois pontos de acesso, alguns clientes mó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, ficando totalmente transparente para o switch.
FlowVisor
Switch Openflow OAP
(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 Teste ProtocoloNovo
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
3.6. CONSIDERAÇÕES FINAIS
experimental. Na Figura 3.4, o gerente realiza suas operações na rede de produção sem se preocupar com o tráfego experimental. Por outro lado, um pesquisador interessado em testar novos protocolos também pode ter seu próprio slice e fazer testes sem se importar com o tráfego de produção presente na rede. A Figura 3.4 mostra também que a divisão entre os tráfegos de produção e experimental pode ser feita em um mesmo dispositivo.
3.6
Considerações Finais
Este capítulo tratou vários conceitos que estarão presentes nas redes do futuro. Foi discutido 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 que outras soluções disponíveis no mercado. Com tantos benefícios, é natural surgir a ideia de utilizar o conceito SDN também em redes sem fio. Porém, quando se trata desse tipo de rede, existem vários desafios associados, como instabilidade, interferência e perdas de pacotes. A seguir, o capítulo 4 discutirá os desafios do gerenciamento de mobilidade nas redes sem fio, onde serão apresentados alguns protocolos de gerenciamento, e em especial, o PMIPv6, o qual inspirou a proposta PMIPFlow.
4
Gerenciamento 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ência do usuário entre as diversas redes celulares, processo conhecido como handover ou handoff. Com o advento das redes sem fio domésticas e a comutação por pacotes, todas as redes estão convergindo para o protocolo IP. Nesse novo cenário, o gerenciamento de mobilidade deixa de ser apenas necessidade apenas das redes celulares e torna-se peç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ção da 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 os principais aspectos do gerenciamento de mobilidade. Na seção 4.2, será abordada a mobilidade no mundo IPv6. Na seção 4.3 serão apresentados alguns aspectos do protocolo de mobilidade MIPv6, o qual serviu como base para muitos outros protocolos, como FMIP, HMIP, PMIP entre outros. Na Seção 4.4, é apresentado o PMIPv6, a evolução do MIPv6 que inspirou o PMIPFlow.
4.1
Localização e Handover
O gerenciamento de mobilidade é ponto crucial para o sucesso das redes do futuro. Neste contexto, o handover é o processo de troca de um nó móvel de um ponto de acesso para
