Nesse capítulo serão detalhados os conceitos de Virtualização de Redes e os principais detalhes do funcionamento da plataforma Xen, que são fundamentais para o entendimento do mecanismo proposto XTC.

\section{Virtualização de Redes}
\label{sec:virtualizacaoRedes}
A virtualização de redes permite que diferentes redes operem em paralelo sobre uma única infraestrutura física. Assim, ela possibilita o desenvolvimento de novas arquiteturas
pois permite a implementação de novos mecanismos em uma rede sem afetar o funcionamento de uma rede operacional. Chowdhury~e~Boutaba~\cite{chowdhury2009network} fornecem uma visão
geral sobre a virtualização de redes, apresentando sua definição e  seus principais requisitos, bem como um ambiente de virtualização de redes genérico. 
As definições apresentadas nesse trabalho serão utilizadas ao longo deste projeto. Primeiramente, Chowdhury~e~Boutaba definem a virtualização de redes como o desacoplamento
dos papéis de Provedores de Internet (\textit{Internet Service Providers} - ISPs) convencionais em duas entidades independentes: Provedores de Infraestrutura
(\textit{Infrastructure Providers} - InPs), responsáveis por administrar a infraestrutura física, e os Provedores de Serviço (\textit{Service Providers} - SPs), que contratam recursos dos
InPs de forma a criar suas redes virtuais e oferecer seus serviços. Uma rede virtual pode ser constituída de recursos de diferentes InPs.
Essas entidades apresentadas compõe o ambiente de redes virtuais definido por Chowdhury~e~Boutaba, mostrado na Figura~\ref{fig:ambienteRedesVirtuais}, 
que será detalhado mais adiante.

\begin{figure}
  \begin{minipage}{\textwidth}
  \centering
  \includegraphics[width=0.8\textwidth]{./figuras/ambienteRedesVirtuais.eps}
  \caption[Ambiente de redes virtuais.]%
	      {Ambiente de redes virtuais\footnotemark}
  \label{fig:ambienteRedesVirtuais}
  \end{minipage}
\end{figure}

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

A divisão de uma rede física em diferentes redes lógicas é um conceito bastante antigo. A virtualização de redes, porém, possui algumas diferenças fundamentais na abordagem
de como são construídas as redes lógicas. Para melhor entendimento das diferenças da virtualização de rede, Chowdhury~e~Boutaba apresentam os conceitos das diferentes formas
já consolidadas de separação de uma rede física em redes lógicas, são elas:
\begin{itemize}
\item \textbf{VLAN (\textit{Virtual Local Area Network} - Rede Local Virtual)}: Uma VLAN é um grupo de estações dentro de um mesmo domínio de \textit{broadcast}. Assim,
uma rede local pode ser dividida em várias VLANs. Uma estação de uma determinada VLAN só receberá quadros destinados a essa VLAN. Para isso, os quadros de uma VLAN são rotulados. Assim, ao receber um quadro com um rótulo de uma VLAN, o comutador envia esse quadro apenas em suas portas associadas a essa VLAN. A tecnologia de VLAN é definida no padrão IEEE~802.1q~\cite{ieee80211q}.
\item \textbf{VPN (\textit{Virtual Private Network} - Rede Privada Virtual)}: Uma VPN é uma rede dedicada entre estações de uma determinada instituição. Essas estações não
necessitam estar na mesma rede local podendo utilizar, por exemplo, a infraestrutura da Internet para o estabelecimento da rede. As VPNs podem ser implementadas
de diferentes formas~\cite{costa2000introduction}. Uma delas é a criação de túneis seguros entre as estações de uma VPN.
Assim, o tunelamento seguro permite o encapsulamento de pacotes de forma que somente as estações da VPN possam desencapsular e ter acesso aos quadros da rede.
\item \textbf{Rede Programável e Ativa}: Esse tipo de redes possui como objetivo a modificação da rede em tempo de execução para atender a demanda de novos serviços.
Além disso, essas redes possuem o conceito de um ambiente isolado, no qual um determinado usuário da rede pode mudar um determinado comportamento da rede
sem interferir no funcionamento dos outros usuários. Assim, é fornecida uma separação lógica de uma rede física. As redes ativas foram bastante estudadas no passado~\cite{tennenhouse1997survey}.
\item \textbf{Rede Sobreposta (\textit{Overlay Network})}: As redes sobrepostas são redes lógicas construídas em cima da rede física,
geralmente construídas no nível de aplicação. Assim, uma determinada aplicação da rede pode construir uma rede lógica com as diferentes estações envolvidas.
Nesse tipo de redes não é necessária a modificação da rede física. Um exemplo de redes sobrepostas são as redes criadas por aplicações P2P (\textit{Peer-To-Peer} - Par-a-Par)
na Internet, nas quais os usuários dessas aplicações formam redes lógicas para trocar informações entre si~\cite{surveyP2P}.
As redes sobrepostas são uma alternativa para driblar a falta de flexibilidade da Internet. Porém, cada uma dessas redes é construída para atender o objetivo específico de uma determinada
aplicação. Além disso, essas redes são geralmente construídas em cima das camadas já existentes da Internet, não permitindo inovação nas camadas inferiores~\cite{chowdhury2009network}.
Por exemplo, a Internet atual utiliza o endereçamento de rede IPv4 (\textit{Internet Protocol version 4}). Esse 
tipo de endereçamento possui limitações como o número de nós suportados~\cite{moreira.sbrc09}. Uma alternativa que surgiu para superar algumas das limitações
do IPv4 é o IPv6 (\textit{Internet Protocol version 6}) que, por exemplo, consegue endereçar um maior número de nós. Como a transição do IPV4 para o IPv6 demandaria a modificação da
camada de rede, as redes sobrepostas não seriam úteis para a adoção dessa nova forma de endereçamento visto que essas são construídas na camada de aplicação.
A adoção em larga escala do IPv6 dependeria da modificação da camada de rede de todos os nós da Internet, tornando difícil sua implementação na Internet atual.

\end{itemize}
\vspace{10mm}
Diferente das tecnologias apresentadas, um ambiente de rede virtualizado é o conjunto de diversas arquiteturas de rede de diferentes Provedores
de Infraestrutura. Assim, um Provedor de Serviço contrata recursos de Provedores de Infraestrutura diferentes de forma a construir sua rede virtual.
Uma rede virtual é um conjunto de nós virtuais que são conectados por enlaces virtuais para formar uma topologia virtual. Cada nó virtual está 
instanciado em um nó físico na rede e o enlace virtual é um conjunto de recursos definidos na infraestrutura física necessários para prover comunicação entre
dois nós virtuais.
A rede virtual deve ser flexível o suficiente para permitir que cada Provedor de Serviço implemente em sua rede virtual seu próprio formato de pacotes,
protocolo de roteamento, mecanismo de roteamento e planos de controle e de gerenciamento~\cite{chowdhury2009network}.  
O ambiente de redes virtuais proposto por Chowdhury~e~Boutaba, apresentado na Figura~\ref{fig:ambienteRedesVirtuais}, possui os seguintes componentes:
\begin{itemize}
\item \textbf{InP}: O InP (\textit{Infrastructure Provider} - Provedor de Infraestrutura) é responsável pela instalação de recursos de rede físicos, como comutadores e cabeamento de rede. Essa entidade deve fornecer uma interface programável, de forma que os SPs (\textit{Service Providers} - Provedores de Serviço) possam
acessar os recursos alocados para eles. O InP deve gerenciar o acesso dos diferentes SPs à infraestrutura física de forma a garantir o isolamento entre eles. Além disso,
podem existir diferentes níveis de serviço oferecidos para cada SP, que são dependentes de políticas definidas pelo InP. Por exemplo, o InP pode
permitir que um SP possa utilizar mais banda do que o outro.
\item \textbf{SP}: Como explicitado anteriormente, o Provedor de Serviço (SP) é cliente do Provedor de Infraestrutura (InP). Essa entidade pode contratar recursos de diferentes InPs para construir sua rede virtual, como
mostrado na Figura~\ref{fig:ambienteRedesVirtuais}. O SP é então responsável por gerenciar e operar a rede virtual, fornecendo serviços fim a fim aos Usuários Finais (\textit{End Users} - EUs).
Além disso, o SP pode oferecer serviços de um InP através da propriedade de recursividade do ambiente de rede virtualizado. A recursividade significa que redes virtuais possam ser 
criadas em cima de outras redes virtuais. Assim, um SP pode criar outras redes virtuais sobre sua própria rede virtual, oferecendo esse serviço a outros SPs.
Em outro trabalho no qual é definido um ambiente de rede virtualizado~\cite{schaffrath2009network}, o SP definido por Chowdhury~e~Boutaba engloba três entidades mais específicas:

\begin{itemize}
\item \textbf{\textit{Virtual Network Provider} (Provedor de Rede Virtual)}: Responsável pela construção da  topologia da 
rede virtual a partir dos recursos contratados de diferentes InPs.
\item \textbf{\textit{Virtual Network Operator} (Operador de Rede Virtual)}: Responsável pela instalação e operação de uma rede virtual a partir da topologia
oferecida por um Provedor de Rede Virtual.
\item \textbf{\textit{Service Provider} (Provedor de Serviço)}: Diferente da definição de Chowdhury~e~Boutaba, o Provedor de Serviço nesse caso é a entidade que utiliza
uma rede virtual para prover um determinado serviço. Esse serviço pode ser do tipo fim a fim ou até um serviço de transporte, no qual o Provedor de Serviço atuará
como um provedor de rede, como os atuais ISPs. 
\end{itemize}

Apesar de existir essa outra definição das entidades da rede virtual, ao longo do texto será utilizada a nomenclatura mais geral proposta por Chowdhury~e~Boutaba.
\item \textbf{EU}: O EU (\textit{End User} - Usuário Final) possui o mesmo papel dos clientes dos ISPs atuais. A diferença, porém, é que a virtualização de redes
permite que exista um maior número de Provedores de Serviço, possibilitando que usuários possam escolher SPs que atendam mais especificamente seus requisitos.
\end{itemize}

Chowdhury~e~Boutaba também definem os seguintes critérios para o projeto de um ambiente de redes virtuais: 
\begin{itemize}
\item \textbf{Flexibilidade}: Uma rede virtual deve ser flexível, permitindo que cada SP possa implementar sua própria topologia de rede, seus próprios
protocolos de roteamento e mecanismo de encaminhamento, bem como outros protocolos que sejam independentes da rede física e das outras redes existentes.
Por exemplo, como visto anteriormente, o SP pode implementar em sua rede uma outra forma de endereçamento diferente do IPv4, como o IPv6, sem a necessidade de configurar a rede física para tal.
\item \textbf{Gerenciabilidade}: O ambiente de rede virtualizado deve ser gerenciável tanto na camada do InP, como do SP. Assim, o SP 
deve possuir completo controle sobre sua rede virtual.
\item \textbf{Escalabilidade}: A rede física deve permitir a coexistência de múltiplas redes virtuais, possibilitando que o número de redes virtuais cresça sem afetar o seu desempenho.
\item \textbf{Isolamento}: O funcionamento de uma rede virtual não deve interferir no funcionamento de outras redes virtuais.
\item \textbf{Estabilidade e Convergência}: A camada de virtualização adicionada à infraestrutura física deve ser estável de forma a não interferir no funcionamento
correto das redes virtuais. Porém, caso haja algum evento de instabilidade, a rede deverá convergir rapidamente para seu estado normal.
\item \textbf{Programabilidade}: Os elementos da rede devem ser programáveis de forma que seja fácil a implementação de novos mecanismos pelos SPs.
\item \textbf{Heterogeneidade}: O ambiente de virtualização deve permitir que a rede física possua diferentes tecnologias de rede como redes ópticas,
redes sem-fio etc. Além disso, as redes virtuais devem herdar a mesma heterogeneidade da rede física.
\item \textbf{Suporte a Redes Legadas}: O ambiente de redes virtuais deve suportar as redes já existentes. Por exemplo, a Internet atual pode ser uma das redes virtuais.
\end{itemize}

Para que possam ser construídas redes virtuais sobre uma infraestrutura física, é necessária uma plataforma de virtualização que controle o acesso aos recursos físicos
pelas redes virtuais. Como visto no Capítulo~\ref{sec:introducao}, o Xen é uma plataforma de virtualização de máquina que permite que diversas máquinas virtuais
com sistema operacional completo coexistam em uma mesma máquina física. Com essa plataforma as máquinas virtuais podem realizar o papel de roteadores, possibilitando a
criação de redes virtuais.

O Flowvisor~\cite{sherwood2009flowvisor} é outro exemplo de plataforma de virtualização, utilizado para virtualizar redes que utilizam a tecnologia OpenFlow~\cite{mckeown08}.
A tecnologia OpenFlow é uma proposta que tinha como objetivo inicial possibilitar que um pesquisador executasse experimentos com novos protocolos na rede de sua própria universidade. 
Apesar de parecer uma ideia de simples concretização, devido ao fato de a rede já estar dentro da universidade, existe o problema 
de os experimentos atrapalharem o funcionamento da rede. Como a infraestrutura de rede é um ponto crítico na 
universidade, o tráfego experimental não pode influenciar no tráfego real da rede. Para isso, no OpenFlow é proposto um mecanismo que é 
executado em todos os comutadores da universidade de forma que possa haver isolamento entre esses dois tipos de tráfego. 
Assim, o OpenFlow possibilita que os pesquisadores reprogramem os comutadores para executar seus experimentos sem interferência 
no funcionamento da rede de produção. Os pesquisadores podem reprogramar os comutadores da rede através de um controlador centralizado. 
O Flowvisor adiciona a virtualização no OpenFlow permitindo que diversos controladores possam configurar uma única rede OpenFlow.
Esse mecanismo atua como um \textit{proxy} entre os controladores e a rede Openflow, impedindo que esses controladores interfiram entre si.
Diferente de plataformas de virtualização de máquina como o Xen, o Flowvisor virtualiza recursos da rede, como banda e número de entradas na tabela de encaminhamento,
ao invés de virtualizar diretamente o \textit{hardware} da máquina.
Para este projeto foi escolhida a plataforma de virtualização Xen devido à sua alta programabilidade. Esta característica se deve ao fato de o Xen
ser uma plataforma de virtualização de máquina, oferecendo
um sistema operacional completo em suas máquinas virtuais. Com isso, o Xen possibilita uma maior liberdade na implementação de novos protocolos e mecanismos.
A próxima seção aborda os principais conceitos da plataforma Xen.

\section{Plataforma Xen}
Para permitir a execução de diferentes máquinas virtuais em paralelo em uma máquina física, o Xen implementa uma camada de software chamada hipervisor que se situa entre
o \textit{hardware} da máquina física e as máquinas virtuais, chamadas de \textit{domínios} no contexto do Xen, como mostrado na Figura~\ref{fig:arquiteturaXen}. O hipervisor 
controla o acesso ao \textit{hardware} de cada máquina virtual e ainda realiza alocação dos recursos destinados a cada domínio.
Na arquitetura do Xen existe uma máquina privilegiada, chamada de Domínio~0, que é responsável pelo gerenciamento do ambiente virtualizado.
O Domínio~0 possui um sistema operacional Linux modificado para a utilização do Xen.
A partir desse domínio podem ser executadas tarefas administrativas como criação e configuração de máquinas virtuais,
desligamento dessas máquinas, definição da quantidade de recursos oferecida a cada domínio etc. O Domínio~0 é também responsável por gerenciar as operações de 
Entrada e Saída (E/S), visto que esses recursos também podem ser compartilhados. Para isso, o Xen utiliza o conceito de domínio de \textit{drivers}, no qual
o Domínio~0 possui todos os \textit{drivers} e interfaces do dispositivo de E/S utilizados pelas máquinas virtuais. As máquinas virtuais, por sua vez,
possuem interfaces e \textit{drivers} virtuais que se comunicam com essas interfaces implementadas pelo Domínio~0.  Assim, o Domínio~0 possui acesso total aos
dispositivos de E/S, intermediando a troca de dados entre esses dispositivos e as máquinas virtuais. As operações de E/S do Domínio~0 serão detalhadas
a seguir para o caso específico de tarefas de rede.
\begin{figure}
\centering
\includegraphics[width=0.8\textwidth]{./figuras/arquiteturaXen.eps}
\caption{Arquitetura da plataforma Xen.}
\label{fig:arquiteturaXen}
\end{figure}

\subsection{Tarefas de Rede}
\label{sec:tarefasRedeXen}
Para a execução das tarefas de rede no Xen, o Domínio~0 demultiplexa os quadros destinados às máquinas virtuais que são recebidos nas interfaces de rede físicas, enviando-os
a cada domínio correspondente.
Da mesma forma, os quadros enviados pelas máquinas virtuais são multiplexados pelo Domínio~0 na interface física correspondente.
Para o Domínio~0 poder enviar e receber quadros das máquinas virtuais, o Xen implementa a arquitetura da Figura~\ref{fig:redeXen}.
Nessa arquitetura, cada máquina virtual possui suas interfaces de rede virtuais chamadas de \textit{front-ends}. Associado a cada
\textit{front-end} de cada domínio, existem no Domínio~0 interfaces lógicas de rede chamadas de \textit{back-end}. Quando o Domínio~0
recebe um quadro destinado a uma determinada interface de um domínio, ele envia esse quadro ao \textit{back-end} correspondente.
Para multiplexar ou demultiplexar os quadros dos domínios, o Xen por padrão utiliza pontes (\textit{bridges}) de software. Assim, existe uma 
ponte para cada interface física de rede, e cada \textit{back-end} é conectado à ponte da interface física correspondente.
Como cada \textit{back-end} possui um endereço MAC (\textit{Medium Access Control}) associado, a ponte encaminhará o quadro
para o \textit{back-end} correspondente através do endereço MAC de destino do quadro. O \textit{back-end}, por sua vez, irá encaminhar 
o quadro para o seu o \textit{front-end} e então a máquina virtual correta irá recebê-lo. Quando uma máquina virtual deseja enviar algum quadro, 
ela o coloca em seu \textit{front-end} e então
esse quadro será recebido pelo \textit{back-end} no Domínio~0 e encaminhado para a interface física correspondente pela ponte. A comunicação
entre o \textit{front-end} e o \textit{back-end} é realizada através de uma área de memória compartilhada, ou seja, sempre quando um \textit{back-end}
envia um quadro ele o escreve na memória compartilhada e posteriormente o \textit{front-end} o lê. O envio de quadros do \textit{front-end} para
o \textit{back-end} também realiza as mesmas operações~\cite{fernandes2010virtual}. A Figura~\ref{fig:redeXen} apresenta de forma
simplificada os passos necessários para o encaminhamento de um pacote por um roteador virtual:
\begin{itemize}
\item \textbf{1} - O quadro é recebido pela Interface 1 física e encaminhado pela Ponte 1 ao \textit{back-end} da Interface 1, que corresponde ao roteador virtual de destino;
\item \textbf{2} - O \textit{back-end} da Interface 1 envia esse quadro ao seu \textit{front-end} correspondente através da memória compartilhada e chamadas ao hipervisor;
\item \textbf{3} - O roteador virtual recebe o quadro pela Interface 1 virtual (\textit{front-end}) e consulta sua tabela de roteamento, que indica que o quadro deve
ser enviado para a Interface 2 virtual. Esse encaminhamento é realizado da forma padrão do Linux, não sendo específico da plataforma Xen.  Após essa etapa, a rotina de encaminhamento envia o quadro para a Interface 2 virtual;
\item \textbf{4} - O \textit{front-end} da Interface 2 envia o quadro ao seu \textit{back-end} correspondente através de memória compartilhada e chamadas ao hipervisor;
\item \textbf{5} - O \textit{back-end} envia para a Interface 2 física o quadro enviado pelo roteador virtual, utilizando o encaminhamento da Ponte 2.
\end{itemize}
\begin{figure}
\centering
\includegraphics[width=0.712\textwidth]{./figuras/redeXen.eps}
\caption{Encaminhamento de pacotes no Xen.}
\label{fig:redeXen}
\end{figure}
A comunicação entre o \textit{front-end} e \textit{back-end} de uma máquina virtual é bastante custosa em termos de processamento, como mostrado por
Fernandes \textit{et. al}~\cite{fernandes2010virtual}. Como precisa realizar essas tarefas para cada máquina virtual, o Domínio~0 representa
um gargalo na utilização das máquinas virtuais como roteadores devido ao intenso uso de tarefas de rede realizado por essas máquinas. Assim, uma máquina
que possui uma alta taxa de encaminhamento de pacotes pode saturar o uso de CPU do Domínio~0, levando ao descarte dos pacotes destinados
às outras máquinas virtuais. Como o Xen nativo não limita a quantidade de processamento do Domínio~0 que cada máquina virtual pode utilizar no encaminhamento,
isso representa um problema de isolamento pois o tráfego de um roteador virtual poderá influenciar no de outro roteador. Uma proposta
que melhora o desempenho de encaminhamento de um roteador virtual é a separação de planos~\cite{pisa2010migration}. Os roteadores possuem
um plano de controle responsável pela execução do protocolo de roteamento, definindo as melhores rotas para os destinos na rede, e um plano
de dados que possui a função de consultar a tabela de roteamento e encaminhar pacotes de uma interface de rede para a outra dependendo do destino a ser alcançado.
Na implementação padrão de roteadores no Xen esses dois planos são implementados na máquina virtual. Com a separação de planos, porém,
o plano de controle é implementado no roteador virtual e o plano de dados no Domínio~0. O roteador virtual constrói a tabela de roteamento
a partir do protocolo de roteamento de seu plano de controle e atualiza no Domínio~0 a sua tabela de roteamento. O Domínio~0 então
possui uma tabela de roteamento para cada roteador virtual podendo então encaminhar os pacotes sem a necessidade de enviá-los
para as máquinas virtuais. Assim, a comunicação custosa entre \textit{front-end} o \textit{back-end} não é necessária para o encaminhamento de pacotes,
aumentando o desempenho da rede. A separação de planos, porém, reduz a flexibilidade na implementação de um roteador virtual, pois assume um plano de dados
igual para todas as máquinas, impedindo que o administrador do roteador virtual implemente o plano de dados que desejar, uma desvantagem considerando-se a arquitetura pluralista da Internet do futuro. Por exemplo, um roteador
não poderá adotar um esquema de endereçamento diferente do IP. Assim, como um dos requisitos fundamentais de um ambiente de redes virtualizadas é a flexibilidade
(Seção~\ref{sec:virtualizacaoRedes}), esse trabalho irá adotar a arquitetura apresentada anteriormente na qual os planos de dados e de controle são
implementados juntos no roteador virtual.

\subsection{Alocação de Recursos}
\label{sec:creditScheduler}

Como explicitado anteriormente, o hipervisor do Xen gerencia a quantidade de recursos de máquina física que cada máquina virtual pode utilizar.
A quantidade de memória RAM reservada para cada máquina virtual é um valor fixo especificado na instanciação da máquina virtual e nativamente não pode
ser alterada em tempo de execução.
Para alocação de recursos de CPU, o Xen utiliza por padrão o escalonador
\textit{Xen Credit Scheduler}~\cite{ongaro2008scheduling}, que controla a fatia de tempo
de processamento em CPU alocado para cada máquina virtual. Esse tempo de CPU
é ajustado
baseado em dois parâmetros: \textit{weight} e \textit{cap}. O primeiro define um peso para cada máquina virtual, permitindo que o escalonador ofereça mais tempo de CPU para 
máquinas virtuais com maiores pesos em situações de disputa de CPU.  Por exemplo,
uma máquina virtual com peso 10 poderá utilizar o dobro de recursos de CPU do que uma máquina com peso 5. Esse valor de peso é relativo, ou seja, se uma máquina possuir peso 200 e a outra um peso 100, a primeira irá também possuir o dobro de recursos do que a outra. Por outro lado, o \textit{cap} impõe um limite rígido na utilização de CPU, indicando a 
porcentagem máxima do tempo da CPU dada para cada máquina virtual. Por exemplo, um domínio com um \textit{cap} de valor 50 poderá utilizar
50\% da capacidade de CPU física. Em máquinas com mais de um núcleo de CPU, o valor do \textit{cap} pode chegar até $n*100\%$, onde $n$ é o número de núcleos disponíveis
para um determinado domínio.
Os dois parâmetros do escalonador podem ser configurados em tempo de execução a partir do Domínio~0.

Como o Xen especifica explicitamente a quantidade de memória e CPU alocada para cada domínio, o hipervisor consegue isolar a utilização desses recursos por cada máquina
virtual. Entretanto, como visto na Seção~\ref{sec:tarefasRedeXen}, o Xen não consegue limitar a quantidade de recursos do Domínio~0 utilizada pelas tarefas de rede
de cada máquina virtual. Assim, existe a necessidade de uma forma indireta de alocar esses recursos. A solução adotada pelo XTC, apresentada no Capítulo~\ref{sec:xtc},
é utilizar a limitação da quantidade de CPU alocada para cada domínio.
Limitar a fatia de CPU oferecida para cada máquina virtual é útil para controlar o tempo de execução das tarefas de cada uma. Assim, tarefas como escrita em disco, 
processamento, envio de pacotes etc. podem ter o tempo de execução controlado. 

Neste trabalho, o conceito de máquinas virtuais é utilizado para criar roteadores virtuais 
cuja tarefa principal é encaminhar pacotes. Logo, ao controlar a CPU oferecida para cada roteador virtual, pode-se limitar a vazão máxima que cada um pode atingir 
no encaminhamento de pacotes. Neste trabalho, a quantidade de CPU é limitada utilizando o parâmetro \textit{cap} do escalonador por proporcionar um maior controle para o mecanismo 
proposto graças ao seu limite rígido. O \textit{weight}, por outro lado, atua apenas em situações de saturação de CPU.



