Nesta seção será apresentado um trabalho relacionado ao desempenho de encaminhamento no Xen e os trabalhos de controle em redes virtuais.

\section{Desempenho de encaminhamento}

O desempenho de encaminhamento do Xen é avaliado no trabalho~\cite{fernandes2010virtual}, realizado pelo autor deste projeto em conjunto com
outros integrantes do GTA (Grupo de Teleinformática e Automação). Nesse trabalho utiliza-se a mesma plataforma
de testes descrita no Capítulo~\ref{sec:testbed}, na qual um Encaminhador de Tráfego (ET) realiza o encaminhamento de pacotes entre um Gerador
de Tráfego (GT) e um Receptor de Tráfego (RT). Na máquina ET são testados três tipos de encaminhamento. O primeiro é o encaminhamento
padrão do Linux pela máquina física, sem a utilização da plataforma Xen. O segundo tipo é o encaminhamento pelo Domínio~0, no qual os
pacotes são encaminhados diretamente pelo Domínio~0, não sendo enviados para os roteadores virtuais como, por exemplo, na separação
de planos(Capítulo~\ref{sec:conceitos}). Por fim, o último
tipo de encaminhamento é o utilizado neste projeto e mostrado no Capítulo~\ref{sec:conceitos}, que consiste no encaminhamento pelos roteadores virtuais. Ou seja, nesse caso
o Domínio~0 necessita encaminhar os pacotes para os roteadores virtuais. No experimento varia-se a taxa de geração de tráfego, em kilopacotes por segundo (kp/s),
pela máquina GT e o valor recebido pela máquina RT é medido. Esse experimento é realizado para cada tipo de encaminhamento, com
o objetivo de medir o desempenho de cada um. A Figura~\ref{fig:desempenhoDom0} mostra os resultados do experimento para os três diferentes tipos de encaminhamento.
O encaminhamento pelo Domínio~0, chamado de Xen~Domínio~0 na figura, apresenta um desempenho inferior ao do Linux nativo devido a modificações
no tratamento de rede do Linux Nativo implementadas pelo Xen, como a existência da ponte de \textit{software}. Por outro lado,
é mostrada a diferença significativa entre o desempenho do encaminhamento pela máquina virtual, chamado de Xen~Máquina~Virtual, e o encaminhamento pelo
Domínio~0. Isso ocorre pois, como mostrado no Capítulo~\ref{sec:conceitos}, o encaminhamento pelas máquinas virtuais é bastante custoso para o Domínio~0 em
termos de processamento, assim o seu uso de CPU satura com um taxa de pacotes baixa em relação aos outros casos apresentados na Figura~\ref{fig:desempenhoDom0}.
Com isso, esses resultados mostram os problemas enfrentados pelo Xen no encaminhamento de pacotes pelas máquinas virtuais devido à saturação
do uso de CPU. Além disso, no trabalho~\cite{fernandes2010virtual} também é mostrado que
mesmo reservando mais núcleos de CPU para o Domínio 0, o desempenho das tarefas de rede não melhora, pois essas tarefas são pouco paralelizáveis.
Esses resultados apresentados neste projeto são apenas para ilustrar o problema de encaminhamento pelos roteadores virtuais,
mais detalhes sobre essa análise podem ser encontrados no texto do trabalho em questão~\cite{fernandes2010virtual}.

%\begin{figure}
%\centering
%\includegraphics[width=0.65\textwidth]{./graficos/forwardRate_22.eps}
%\caption{Desempenho de encaminhamento no Xen.}
%\label{fig:desempenhoDom0}
%\end{figure}
\begin{figure}
  \begin{minipage}{\textwidth}
  \centering
  \includegraphics[width=0.65\textwidth]{./graficos/forwardRate_22.eps}
  \caption[Desempenho de encaminhamento no Xen.]%
	      {Desempenho de encaminhamento no Xen.\footnotemark}
  \label{fig:desempenhoDom0}
  \end{minipage}
\end{figure}

\footnotetext{Adaptado de~\cite{fernandes2010virtual}.}

\section{Controle em Redes Virtuais}

O compartilhamento de recursos de máquina é um assunto bastante estudado no contexto de \textit{data centers}. Wang~\textit{et al.}~\cite{wang-utilization} propõem um arcabouço para projetar
um sistema de controle de recursos atribuídos às aplicações de um servidor. Para tal, a fatia de tempo de CPU do servidor atribuída para cada aplicação é ajustada
utilizando um controle realimentado para atingir requisitos, como o tempo de resposta a requisições.
Padala~\textit{et al.}~\cite{padala2007adaptive}
também propõem um controle realimentado para alocar recursos em \textit{data centers} virtualizados com o Xen. Apesar dos
diversos trabalhos da literatura sobre controle de recursos em \textit{data centers}, a abordagem em redes virtuais ainda é um tema de pesquisa bastante novo e pouco 
investigado.

O controle de recursos em redes virtuais pode ser do tipo global ou local~\cite{fernandes2011XnetMan}. O controle global define a criação de enlaces virtuais na rede, 
bem como a localização de cada roteador virtual na rede, oferecendo funções como o mapeamento da rede virtual em uma rede física 
e migração de roteadores virtuais entre diferentes roteadores físicos. O controle local, por sua vez, lida com o isolamento de 
recursos entre os roteadores virtuais de um determinado nó físico. Assim, o controle global realiza a alocação de recursos na rede 
assumindo que existe um controle local executando em um nó físico. O XTC é um controlador do tipo local, possibilitando o isolamento 
dos recursos de processamento do Domínio 0. Serão apresentados a seguir alguns trabalhos de controle global e local de redes virtuais.

\subsection{Controle Global}
Houidi~\textit{et al.}~\cite{houidi2010adaptive} identificam quatro passos na criação de uma rede virtual: (i) descrição e anúncio dos recursos,
no qual o InP informa seus recursos físicos disponíveis; (ii) descoberta de recursos e correspondência, no qual o SP recebe uma requisição de criação de
rede virtual , procura nas descrições do InP os recursos físicos disponíveis e propõe quais nós e enlaces podem ser usados na criação dessa rede;
(iii) mapeamento, no qual o InP define como as redes virtuais estarão alocadas na infraestrutura física tendo como objetivo 
maximizar o número de
redes virtuais em uma mesma infraestrutura, reduzindo o custo para os SPs e maximizando o lucro do InP. O mapeamento é um problema
NP-difícil, ou seja, possui complexidade alta o suficiente para não poder ser resolvido em tempo polinomial;
(iv) vinculação, que consiste na configuração
dos nós e enlaces virtuais para a rede requisitada, após a definição da alocação de recursos do passo anterior. 
Após a configuração da rede, mecanismos de controle são necessários para garantir o atendimento da demanda das redes virtuais a partir dos requisitos especificados
em seus SLAs (\textit{Service Level Agreement}). Para isso, os passos (ii) e (iii) precisam ser periodicamente executados, de forma a tornar a rede adaptativa
a mudanças de demanda ou a falhas na infraestrutura. Por exemplo, se um nó físico falhar, todos seus nós virtuais deverão ser migrados para outro nó.
Houidi~\textit{et al.}~\cite{houidi2010adaptive} propõem um mecanismo de mapeamento com uma arquitetura multi-agentes para lidar com o caso de falhas na rede física ou virtual.
A arquitetura multi-agentes permite que o controle seja realizado de forma descentralizada, pois cada nó físico possui um agente que troca informações com
seus agentes vizinhos. O algoritmo proposto
se baseia em estratégias para reagir a problemas como falha de um nó virtual, que pode ser resolvida
pela reinicialização desse nó, e falhas no nó físico ou no enlace físico, que podem ser resolvidas pela migração de nós virtuais entre nós físicos.
A migração dos nós é realizada de forma que o nó físico para o qual o nó virtual migra suporte seus requisitos. Para isso, os autores propõem métricas
para medir a capacidade de um nó físico ao receber um novo nó virtual.

Alkmim~\textit{et al.}~\cite{alkmim2011mapeamento} propõem dois algoritmos de mapeamento de uma rede virtual na infraestrutura física de forma a minimizar
a largura de banda alocada nos enlaces físicos para uma rede virtual. Por exemplo, o algoritmo deve garantir que a rede utilize o menor número possível de enlaces físicos, evitando o desperdício de recursos. O diferencial desses algoritmos em relação a outros algoritmos já propostos
são os parâmetros considerados no mapeamento da rede virtual. Os algoritmos consideram que na criação de um roteador virtual existam
servidores de imagens de disco espalhados pela rede, como na arquitetura proposta por~Alves~\textit{et al.}~\cite{alves2011servidor}. Esses servidores
fornecem imagens com as instalações necessárias para instanciar um roteador virtual. Assim, um determinado servidor transfere uma imagem a um nó físico
quando esse necessita instanciar um novo nó virtual. Os algoritmos de Alkmim~\textit{et al.} consideram que o mapeamento deve ser feito de forma que os enlaces
escolhidos para transferir a imagem façam o nó físico ter conectividade com algum servidor, mas minimizando o tempo dessa transferência. Além disso,
os algoritmos consideram outros requisitos como número de núcleos de CPU necessário para a instanciação dos roteadores virtuais e espaço em disco de um nó físico
para armazenar uma nova imagem. A diferença entre os dois algoritmos propostos é a forma de resolver o problema: um encontra a solução ótima
para o problema enquanto o outro é um algoritmo relaxado que emprega heurísticas para a resolução desses problemas. É demonstrado no trabalho que o algoritmo
relaxado consegue encontrar a solução em menor tempo e a quantidade banda alocada nesse algoritmo é bem próxima da alocada no algoritmo ótimo. Os algoritmos
de Alkmim~\textit{et al.} não propõem o mapeamento adaptativo como o de Houidi~\textit{et al.}, preocupando-se apenas com o estado
da infraestrutura no momento da instanciação da rede.

\subsection{Controle Local}
Anwer~\textit{et al.}~\cite{anwer2010network} tratam do problema do gargalo de processamento da máquina física na recepção de pacotes pelas máquinas virtuais, servindo tanto 
para ambiente de \textit{datacenters} como para redes virtuais. Para isso, utilizam um controle baseado em \textit{hardware} para prover justiça na distribuição de 
recursos da maquina física em tarefas de rede das máquinas virtuais. O controlador desse trabalho é implementado na plataforma NetFPGA~\cite{lockwood2007netfpga}, que é uma 
plataforma programável para o desenvolvimento de dispositivos de redes. O controle em \textit{hardware} permite a limitação de pacotes em cada interface virtual 
antes que os pacotes alcancem o hipervisor. Consequentemente, se uma máquina virtual está recebendo mais pacotes do que o permitido, o mecanismo de controle os 
bloqueia garantindo que pacotes que seriam descartados não cheguem ao hipervisor e desperdicem recursos. No controle por \textit{software} só é possível realizar a 
filtragem dos pacotes após esses serem recebidos na máquina física, causando sobrecarga desnecessária do hipervisor.
Apesar do controle de \textit{hardware} reduzir a quantidade de recursos desperdiçados, este exige dispositivos de rede 
específicos como a NetFPGA.  Assim, existe a necessidade da existência de um controle por \textit{software} para atuar na ausência de hardware específico ou em conjunto 
com o controle por \textit{hardware} de forma a melhorar a distribuição de recursos, visto que esse tipo de controle é menos flexível.
Além disso, como os autores evidenciam no artigo, no controlador utilizado existe a necessidade do aumento da implementação de filas no dispositivo de rede com o 
aumento de interfaces de redes virtuais, acarretando problemas de escalabilidade devido à limitação do \textit{hardware} de rede.

Fernandes~e~Duarte~\cite{fernandes2011XnetMan} propõem o sistema XNetMan (\textit{Xen Network Manager}) para prover QoS (\textit{ Quality of Service} - Qualidade de Serviço), isolar e gerenciar recursos de redes virtuais baseadas em Xen. 
Nesse trabalho é definida uma arquitetura de gerenciamento de redes virtuais, na qual o principal componente é um controlador de recursos físicos. Esse controlador é 
do tipo local, controlando a utilização dos recursos físicos de um determinado nó. Os recursos físicos controlados são a banda de saída de cada enlace físico, e a CPU e 
memória do Domínio 0. Esse controle considera tanto a utilização de virtualização com separação de planos ou com encaminhamento pelo próprio roteador virtual.
O controlador proposto permite um controle do tráfego tanto pelo  Provedor de Infraestrutura quanto pelo próprio Provedor de Serviço. O controle a partir desses últimos agentes, porém, é realizado de forma a garantir isolamento entre as redes, ou seja, um controle de um determinado provedor de rede virtual não pode interferir em outra rede virtual.
Para efetuar o controle de uma infraestrutura de redes virtualizada, o XNetMan monitora o tráfego de cada rede virtual e ajusta parâmetros da rede de forma a garantir 
recursos contratados por cada rede virtual e aplica punições às redes que excedem os valores contratados em seu Acordo de Nível de Serviço (\textit{Service Level Agreement} - SLA). O XNetMan foi avaliado em uma rede de testes real e os resultados mostraram que ele garante uma alta conformidade entre as características do tráfego encaminhado e 
aquelas definidas no SLA. Os resultados, porém, não apresentam a eficácia do mecanismo para limitar a vazão de cada roteador virtual quando existe um gargalo de 
processamento no Domínio 0.  Além disso, da mesma forma que o trabalho de Anwer~\textit{et al.}, a limitação do processamento no Domínio 0 é 
realizada pelo descarte de pacotes em cada interface de rede, não havendo uma 
limitação da capacidade agregada de encaminhamento do Domínio 0 para cada máquina virtual. No caso de alocação de recursos do Domínio~0 
não é desejável o controle em cada interface de rede para limitar esse tipo de recursos. 
Como o objetivo é apenas limitar o processamento do Domínio 0, não há necessidade de um limite rígido em cada interface de rede. 
Esse limite rígido pode tirar a liberdade do SP em alocar livremente a banda disponível em cada interface. 
Assim, é desejável que apenas seja alocada uma determinada capacidade de encaminhamento para o Domínio~0 (em bits por segundo) 
e permitir que o SP divida essa capacidade entre suas interfaces. Esse objetivo é o principal diferencial do XTC em relação aos mecanismos propostos na literatura.

A Figura~\ref{fig:diffAgregadoInterface} mostra a diferença entre o controle de tráfego por interface de rede e o controle agregado.
No controle de tráfego por interface de rede da Figura~\ref{fig:controleporInterface}, a limitação de vazão de uma interface por parte do SP deverá
sempre ser igual ou inferior àquela limitada pelo InP nessa interface. Já na Figura~\ref{fig:controleAgregado} o InP fornece uma capacidade agregada para o SP
e esse tem a liberdade de distribuir essa capacidade entre suas interfaces. Além disso, observa-se pela comparação entre as duas figuras que o controle agregado
é mais escalável pois não necessita de um controlador para cada interface do roteador.

\begin{figure}
%Gerado com o script generate_eXpErImEnTPaperDisturbance.gnu 
\centering
\subfigure[Controle por interface.]
{\label{fig:controleporInterface}
\includegraphics[width=0.48\textwidth]{./figuras/controleIndividual.eps}}
%Gerado com o script eXpErImEnTComparissonAdaptive.gnu
\subfigure[Controle agregado.]
{\label{fig:controleAgregado}
\includegraphics[width=0.48\textwidth]{./figuras/controleagregado.eps}}
\caption{Diferenças entre controle por interface e controle agregado.}
\label{fig:diffAgregadoInterface}
\end{figure}

Carvalho~\textit{et al.}~\cite{carvalho2011controlador} propõem um sistema de controle baseado em lógica nebulosa para alocar os recursos físicos, como processamento
e memória,
destinados às redes virtuais em cada nó físico utilizado. Esse controle é baseado na geração de perfis de uso de cada roteador virtual e, a partir desses
perfis, o controlador pune os roteadores que excederam os limites especificado em seus SLAs. A lógica nebulosa é utilizada para
calcular o grau de punição do roteador em função do perfil observado e da carga do sistema. Segundo os autores, a geração de perfis de uso além de permitir
aplicações mais precisas de punição aos roteadores virtuais, possibilita que o InP possua estatísticas sobre um determinado SP e as utilize
posteriormente para negociar novos SLAs com este. Por exemplo, pode ser proposto a um SP um aumento dos limites de seu SLA se este estiver com um número elevado de
punições. Esse aumento permite uma maior lucratividade para o InP, pois serviços mais caros seriam prestados, e um maior atendimento da demanda por parte do SP.
Carvalho~\textit{et al.} utilizam a plataforma Xen para avaliar experimentalmente o mecanismo proposto. Apesar disso, não é considerado no artigo a divisão de recursos do Domínio~0 necessários para o encaminhamento de pacotes. Por outro lado, o mecanismo do XTC pode ser incorporado a essa proposta de forma a permitir essa funcionalidade.
