diff --git a/docs/latex/report.pdf b/docs/latex/report.pdf
index 1fc0e9ca0c2114da47a4bc0553f8b6a26b2ea534..7fbfde228064e51bdfd34da23ffb187eed3c12c6 100644
Binary files a/docs/latex/report.pdf and b/docs/latex/report.pdf differ
diff --git a/docs/latex/report.tex b/docs/latex/report.tex
index 56970d6e6302292ef283a28758e0649f8623b64e..f3a353f7e7216ba75a5e08b39e13bb9fa3914839 100644
--- a/docs/latex/report.tex
+++ b/docs/latex/report.tex
@@ -1,4 +1,4 @@
-\documentclass[a4paper, 10pt]{report}
+\documentclass[a4paper, 11pt]{report}
 
 %% Language and font encodings
 \usepackage[spanish]{babel}
@@ -20,6 +20,7 @@
 \usepackage[colorinlistoftodos]{todonotes}
 \usepackage[colorlinks=true, allcolors=black]{hyperref}
 
+\setlength{\headheight}{25pt}
 
 \addto\captionsspanish{% Replace "english" with the language you use
 	%% Cambio el nombre del índice
@@ -28,14 +29,15 @@
   \renewcommand{\chaptername}{}
 }
 
+\font\titleFont=cmr12 at 30pt
 
-\renewcommand{\chaptername}{}
+\title{{\Huge Despliegue de un Datacenter con Openstack}}
 
-\title{Despliegue de un Datacenter con Openstack}
 \author{Matías Capucho, Santiago Elizondo \\
 			Universidad de la República, Montevideo, Uruguay. \\
 			Email: \href{mailto:matias.capucho@fing.edu.uy}{matias.capucho@fing.edu.uy}, \href{mailto:selizondo@fing.edu.uy}{selizondo@fing.edu.uy} }
 
+
 \date{4 de Junio de 2019}
 
 \pagestyle{fancy}
@@ -110,7 +112,6 @@ Si bien tanto contenedores como máquinas virtuales tienen como fin aislar y com
 \end{figure}
 
 La combinación de estas tecnologías provee gran flexibilidad al realizar el despliegue de aplicaciones sobre varios servidores, complementando lo ligero de los contenedores con el aislamiento de recursos físicos y la seguridad obtenidos mediante VMs.\\
-
 Citando la ‘Application Container Security Guide’ (SP 800-190 de NIST [14]): \textsl{“A pesar de que a veces se considera que los contenedores son la siguiente fase de virtualización, sobrepasando la virtualización de hardware, la realidad de la mayoría de las organizaciones apunta menos a la revolución que a la evolución. Los contenedores y la virtualización de hardware no solo pueden, sino que frecuentemente lo hacen, coexistir y heredar las capacidades del otro. Las VMs brindan muchos beneficios, tales como fuerte aislamiento, automatización de SO, y un amplio y profundo ecosistema de soluciones. Las organizaciones no necesitan tomar una decisión entre contenedores y máquinas virtuales. Por el contrario pueden continuar utilizando VMs para desplegar, particionar y administrar su hardware, mientras que utilizan contenedores para empaquetar sus aplicaciones, aprovechando cada VM más eficientemente.”}\\
 Es por esto que ambas tecnologías serán utilizadas más adelante en la puesta en marcha de un datacenter de prueba mediante Openstack.
 
@@ -150,16 +151,13 @@ Para diferenciar las distintas redes virtuales en lugar de utilizar un VLAN ID s
 \chapter{Openstack}
 
 \section{Origen y definición}
-Openstack fue creado en los primeros meses del 2010. En ese momento Rackspace quería reescribir el código de infraestructura que corría en sus servidores cloud y además estaban considerando hacer open source el código cloud existente. En ese entonces, Anso Labs, quienes trabajaban para la NASA, publicaron el código beta para Nova, un proyecto basado en Python descrito como “cloud computing fabric controller”. \\
-Dadas las semejanzas en las necesidades de ambas empresas, decidieron en unir fuerzas dando como resultado una base de Openstack. \\
+Openstack fue creado en los primeros meses del 2010. En ese momento Rackspace quería reescribir el código de infraestructura que corría en sus servidores cloud y además estaban considerando hacer open source el código cloud existente. En ese entonces, Anso Labs, quienes trabajaban para la NASA, publicaron el código beta para Nova, un proyecto basado en Python descrito como “cloud computing fabric controller”. Dadas las semejanzas en las necesidades de ambas empresas, decidieron en unir fuerzas dando como resultado una base de Openstack. \\
+
 El primer Summit de diseño tuvo lugar en Austin, TX del 13 al 14 de julio de 2010, en donde participaron aproximadamente 25 compañías: AMD, Autonomic Resources, Citrix, Cloud.com, Cloudkick, Cloudscaling, CloudSwitch, Dell, enStratus, FathomDB, Intel, iomart Group, Limelight, Nicira, NTT DATA, Opscode, PEER 1, Puppet Labs, RightScale, Riptano, Scalr, SoftLayer, Sonian, Spiceworks, Zenoss y Zuora. El proyecto fue oficialmente anunciado el 21 de julio de ese mismo año. \\
-Originalmente la misión de Openstack era “to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable”. Luego en 2016 se actualizó la misma incluyendo interoperabilidad y mejor servicio a los usuarios finales.\\
-En septiembre de 2012, fue lanzada la fundación de Openstack como una institución independiente proporcionando recursos para proteger, potenciar y promover el software Openstack y la comunidad que lo rodea. [5]\\
-\\
-Como es definido en el sitio de Openstack, \textsl{“es un sistema operativo en la nube que controla grandes grupos de recursos de computación, almacenamiento y redes a través de un centro de datos, administrados y provisionados a través de APIs”}[6].\\
-Openstack es un software open source gobernado por una fundación. Ser parte de la misma es gratis y está abierta a todo el mundo.\\
-El proyecto tiene una arquitectura modular, en donde cada instalación de Openstack tendrá instalados y configurados los módulos que se ajusten a las necesidades del caso. Dichos módulos están implementados en Python. Seis de estos proyectos se denominan como módulos core dado que se encargan de las funciones principales del cloud como son las conexiones de red, el almacenamiento, el servicio de identidad, servicios de imágenes y de cómputo.\\
-Permite construir nubes públicas y privadas ofreciendo principalmente servicios de infraestructura (IaaS) y en un grado menor, servicios de plataforma (PaaS).
+
+Originalmente la misión de Openstack era “to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable”. Luego en 2016 se actualizó la misma incluyendo interoperabilidad y mejor servicio a los usuarios finales. En septiembre de 2012, fue lanzada la fundación de Openstack como una institución independiente proporcionando recursos para proteger, potenciar y promover el software Openstack y la comunidad que lo rodea [5]. Como es definido en el sitio de Openstack, \textsl{“es un sistema operativo en la nube que controla grandes grupos de recursos de computación, almacenamiento y redes a través de un centro de datos, administrados y provisionados a través de APIs”}[6].\\
+
+Openstack es un software open source gobernado por una fundación. Ser parte de la misma es gratis y está abierta a todo el mundo. El proyecto tiene una arquitectura modular, en donde cada instalación de Openstack tendrá instalados y configurados los módulos que se ajusten a las necesidades del caso. Dichos módulos están implementados en Python. Seis de estos proyectos se denominan como módulos core dado que se encargan de las funciones principales del cloud como son las conexiones de red, el almacenamiento, el servicio de identidad, servicios de imágenes y de cómputo. Permite construir nubes públicas y privadas ofreciendo principalmente servicios de infraestructura (IaaS) y en un grado menor, servicios de plataforma (PaaS).
 
 \section{Módulos Core}
 En esta sección se describirán los módulos Nova, Neutron, Glance, Cinder, Keystone y Swift, llamados core, profundizando en los aspectos más importantes de cada uno. Conceptualmente los módulos se relacionan de la siguiente forma:
@@ -208,8 +206,8 @@ Las definiciones mencionadas fueron extraídas de [16] y [17].
 \subsection{Nova}
 Nova es el proyecto que se encarga de proveer una forma para provisionar instancias o servidores virtuales. El proyecto soporta la creacion de imagenes, servidores baremetal con la ayuda del proyecto ironic y un soporte limitado para el manejo de containers.\\
 Nova se compone por un conjunto de demonios que permiten ofrecer los servicios mencionados. Adicionalmente para poder desarrollar las funciones básicas, este módulo requiere de los siguientes servicios core de openstack: keystone, glance, neutron y placement.\\
-\\
-En la figura \href{nova} se puede apreciar un esquema conceptual de los principales componentes de una instalación de nova estándar. 
+
+En la figura \ref{nova} se puede apreciar un esquema conceptual de los principales componentes de una instalación de nova estándar. 
 Un dato relevante sobre los componentes de nova es que pueden ser escalados horizontalmente, siendo independiente el grado de escalado para cada servicio.
 
 \begin{figure}[H]
@@ -219,8 +217,7 @@ Un dato relevante sobre los componentes de nova es que pueden ser escalados hori
 	\label{nova}
 \end{figure}
 
-Internamente los componentes de nova se comunican mediante RPC mientras que la interfaz de cara al usuario es una API REST.\\
-
+Internamente los componentes de nova se comunican mediante RPC mientras que la interfaz de cara al usuario es una API REST.
 Los principales componentes de nova son:
 
 \subparagraph{API}
@@ -258,7 +255,7 @@ El servicio de red de Openstack permite crear desde redes y subredes hasta topol
 Las instalaciones del módulo de red deben tener al menos un red externa, la cual no es una SDN definida dentro de Openstack sino que es una red accesible por fuera de Openstack. Estas redes permiten que las redes virtuales construidas con neutron tengan conectividad con el mundo exterior.\\
 Por otro lado, neutron permite crear redes internas a las cuales se conectarán directamente las VMs. Para lograr que dichas VMs se conecten con las redes externas son necesarios routers que relacionen ambos tipos de redes.\\
 
-Una arquitectura simplificada de neutron se puede ver en siguiente figura \href{neutron2}:
+Una arquitectura simplificada de neutron se puede ver en siguiente figura \ref{neutron2}:
 
 \begin{figure}[H]
 	\centering
@@ -322,11 +319,11 @@ Cada imagen tiene asociada su metadata, que incluye conjunto mínimo de propieda
 
 \begin{itemize}
 	\item \textbf{arquitecture}: indica la arquitectura de CPU que debe ser soportada por el hipervisor.
-	\item \textbf{instance_uuid}: en caso de tratarse de una snapshot de una instancia, es utilizada para determinar con cual de ellas se encuentra asociada.
-	\item \textbf{kernel_id}: el identificador de la imagen que puede ser utilizada como kernel cuando se inicia una imagen AMI (Amazon Machine Image).
-	\item \textbf{ramdisk_id}: el identificador de la imagen que puede ser utilizada como ramdisk cuando se inicia una imagen AMI.
-	\item \textbf{os_distro}: el nombre común de la distribución del sistema operativo (en minúsculas).
-	\item \textbf{os_version}: la versión del sistema operativo, especificada por el distribuidor.
+	\item \textbf{instance\_uuid}: en caso de tratarse de una snapshot de una instancia, es utilizada para determinar con cual de ellas se encuentra asociada.
+	\item \textbf{kernel\_id}: el identificador de la imagen que puede ser utilizada como kernel cuando se inicia una imagen AMI (Amazon Machine Image).
+	\item \textbf{ramdisk\_id}: el identificador de la imagen que puede ser utilizada como ramdisk cuando se inicia una imagen AMI.
+	\item \textbf{os\_distro}: el nombre común de la distribución del sistema operativo (en minúsculas).
+	\item \textbf{os\_version}: la versión del sistema operativo, especificada por el distribuidor.
 \end{itemize}
 
 La lista completa de propiedades se encuentra en [38]. Una de las características principales a especificar es el formato de disco o contenedor. El formato de disco de imagen de VM no es más que el formato de la imagen de disco subyacente, este puede ser alguno de los siguientes: raw, vhd, vhdx, vmdk, vdi, iso, ploop, qcow2, aki, ari, ami. Por su parte, el formato de contenedor refiere a aquellos formatos de imágenes que incluyen metadata en sí mismos, pueden ser: bare, ovf, aki, ari, ami, ova, docker. 
@@ -395,6 +392,123 @@ La siguiente imagen ilustra la arquitectura del servicio Swift, en la cual se pu
 	\item \textbf{Partitions}: cada partición puede estar compuesta por un conjunto de bases de datos de cuentas, bases de datos contenedores y objetos propiamente dichos. Se trata de un agrupamiento de elementos para poder ser trasladados dentro del cluster, facilitando operaciones de replicación.
 \end{itemize}
 
+\section{Tipos de nodos}
+En general los sistemas de Openstack están construidos con servidores o nodos físicos, aunque también es posible utilizarlos virtualizados como es el caso de este trabajo, en donde se pueden agrupar en 4 categorías [27]:
+
+\subparagraph{Nodo de control}
+Estos nodos en general corren las APIs de todos los servicios de los componentes de Openstack. Además estos nodos alojan la base de datos de los módulos, los servidores de mensajes y los componentes de caché en memoria como Memcache. Para escalar horizontalmente las APIs pueden ser instaladas en varios nodos de control pudiendo adicionalmente balancear la carga. 
+
+\subparagraph{Nodo de red}
+Estos nodos en general corren los servicios de metadatos y DHCP. Además permiten crear routers virtuales cuando el agente de Neutron L3 es instalado. Al igual que los nodos de control, para mejorar el rendimiento y escalar horizontalmente se pueden separar los servicios de red entre los distintos nodos de red.
+
+\subparagraph{Nodo de cómputo}
+Estos nodos en general corren un hipervisor como puede ser KVM. Hyper-V o Xen; o por el lado de los contenedores LXC o Docker.
+
+\subparagraph{Nodo de almacenamiento}
+Estos nodos en general se limitan a correr software que esté relacionado con los proyectos como Cinder, Ceph o Swift. En estos nodos no es común alojar servicios de otro tipo como de red o cómputo. 
+
+\subparagraph{Nodo de balanceamiento de carga}
+Estos nodos son fundamentales para el funcionamiento óptimo de una instalación de Openstack, dado que se espera que los servicios que se ofrecen tengan una alta disponibilidad. Como la forma de mejorar el rendimiento es escalar horizontalmente, resulta vital tener nodos que se encarguen de distribuir la carga entre los mismos.
+
+\section{Servicios de infraestructura}
+Estos servicios son transversales a todos los módulos del sistema y son mandatorios para el funcionamiento de Openstack. En general estos servicios son instalados en los nodos de control como fue mencionado en la sección anterior.
+
+\subparagraph{Galera - MariaDB}
+La base de datos MariaDB se utiliza para almacenar el estado de todos los servicios de openstack, utilizando usualmente una base de datos MySQL. El servidor de base de datos en general se despliega con una configuración activo/pasivo en donde solamente el servidor principal (activo) podrá ser utilizado por los servicios. Para poder utilizar un esquema activo/activo se puede utilizar Galera, el cual se define como un software de clusterización para MySQL, el cual utiliza un mecanismo sincrónico de replicación para lograr una alta disponibilidad [30].
+
+\subparagraph{Message queue}
+Openstack utiliza una cola de mensajes para llevar a cabo la comunicación entre procesos. Los servicios de cola de mensaje que Openstack soporta son: RabbitMQ y Qpid. Ambos servicios son Advanced Message Queuing Protocol (AMQP) frameworks, los cuales proveen colas de mensajes para comunicaciones punto a punto. En general las colas de mensajes son desplegadas como pools de servidores centralizados o descentralizados. En la instalación realizada se utilizó RabbitMQ [29].
+
+\subparagraph{Memcached}
+Es un sistema de caché de objetos en memoria distribuido, apuntado a mejorar el rendimiento de los sistemas mediante la reducción de carga a la base de datos. En Openstack este software es utilizado por el mecanismo de autenticación de keystone para cachear los tokens del sistema [28].
+
+\section{Métodos de instalación}
+Realizar la instalación básica de openstack (módulos core) es una tarea sumamente compleja. Esto se debe a la gran cantidad de configuraciones y diversos tópicos en los cuales hay que tener un grado de entendimiento no menor, como en bases de datos, linux, redes y backends de almacenamiento. Las guías de instalación que se pueden encontrar en el sitio oficial de openstack consisten de cientos de configuración y comandos a ejecutar en donde es muy probable equivocarse y en consecuencia instalar incorrectamente los módulos de openstack. \\
+
+Debido a la relevancia que ha tomado en los últimos años openstack, la amplia comunidad formada por decenas de compañías y personas buscaron caminos alternativos a realizar la instalación “manualmente”. Estas formas se basan en la automatización de las tareas. Para esto existen varias tecnologías como puppet [45] o Ansible [46]. Además existen diversas distribuciones de Openstack, como DevStack que permite armar un ambiente rápidamente para realizar pruebas, Packstack-RDO o TripleO. Finalmente existe una gran oferta de distribuciones comerciales donde podemos encontrar grandes compañías como IBM, Debian, DELL, Red Hat, VMware, Huawei, etc. Un listado más extenso se puede ver en [47].\\
+
+Otra de las razones principales para utilizar herramientas de automatización además de facilitar la instalación es para poder mantener el sistema luego de su instalación. En el caso de realizar las tareas manualmente no se podrá escalar la nube a cientos o miles de servidores dado que sería prácticamente imposible de mantener o actualizar. \\
+
+En el presente trabajo se emplea la herramienta de automatización Ansible dentro del proyecto Openstack-Ansible (OSA). Dicho proyecto se encarga de proveer playbooks y roles para deployar y configurar un ambiente de Openstack. OSA no es un proyecto que funcione simplemente con los archivos y configuraciones por defecto sino que modificaciones por parte del administrador del cloud serán necesarias. El resultado final que se obtiene con OSA es un cloud de Openstack probada para ambientes de cualquier tamaño, desde datacenters de testing hasta producción. \\
+
+Antes de continuar profundizando en las particularidades de OSA se introducirá brevemente Ansible.
+
+\subsection{Ansible}
+Ansible es una herramienta para la automatización de tareas. Permite configurar sistemas, aplicaciones o dispositivos, desplegar o mantener software, entre otras tareas de IT. 
+Algunos puntos a destacar son: su diseño simple orientado a que sea fácil de utilizar, el uso de OpenSSH como transporte y el diseño del lenguaje el cual el legible por humano y no requiere de conocimientos de programación. Estas características junto a que el software no tiene muchas dependencias son lo que potencian a utilizar OSA. A continuación se describirán los principales conceptos, necesarios para la utilización de Ansible:
+
+\subparagraph{Nodo de control}
+El nodo de control será quien ejecute comandos o playbooks de Ansible. Los requisitos serán tener Python instalado y Ansible. En la arquitectura utilizada, como se menciona luego en el informe, el nodo de control es el de deploy, el cual contiene los diversos scripts de Ansible y es comunica con el resto de los nodos para instalar y configurar los módulos y componentes de Openstack. Este nodo puede ser uno de los utilizados como parte del datacenter o de uso exclusivo para la instalación.
+
+\subparagraph{Inventario}
+Mantiene una lista de los nodos administrados. El inventario es un archivo en el cual se puede especificar la IP de cada nodo administrado, se pueden organizar los nodos en grupos para una mejor escalabilidad. En la siguiente sección se profundiza en este punto.
+
+\subparagraph{Módulos}
+Todas las acciones que se pueden realizar con Ansible se llevan a cabo con un módulo. Estos son las unidades de código que se ejecutan. En cada tarea se puede ejecutar uno o más módulos. Una lista completa de los módulos se encuentra en [48].
+
+\subparagraph{Tarea}
+Es la unidad de acción en Ansible. 
+
+\subparagraph{Playbook}
+Contienen una lista ordenada de tareas. Las playbooks se escriben en YAML lo cual beneficia la lectura, escritura y la comprensión de las mismas. Son una forma de organizar las tareas bajo un criterio determinado. En el caso de OSA utiliza varias playbooks para setear el ambiente inicial, instalar los componentes de infraestructura, entre otros que se especificarán en las próximas secciones.
+
+\section{Arquitectura}
+El método de instalación OSA emplea LXC para desplegar los servicios de Openstack. Además utiliza Linux bridges entre los contenedores y las interfaces físicas o lógicas del host con el fin de proveer conectividad directa a nivel de capa 2. El aislamiento de cada contenedor se logra mediante la utilización de namespaces, esto genera que se deban utilizar pares de interfaces virtuales (veth pairs) para tener conectividad entre los mismos. Esta implementación se puede ver en la imagen \ref{network-components}.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{network-components}
+	\caption{Componentes de red en Openstack}
+	\label{network-components}
+\end{figure}
+
+\subsection{Arquitectura de red}
+OSA soporta múltiples arquitecturas de red, las cuales se diferencian según sea para un ambiente de producción o testing, cantidad de interfaces físicas de los servidores o módulos de openstack utilizados. Para los ambientes de producción es común utilizar interfaces bondeadas mejorando la disponibilidad de los servicios. En general para segmentar el tráfico, tanto en los casos donde se realiza bonding o en donde hay interfaces simples, se utilizan VLANs asignando un ID para cada subred utilizada dentro de Openstack. A continuación se describen las subredes empleadas por OSA para su funcionamiento:
+
+\subparagraph{Management Network}
+La red de administración o también container network se encarga de proveer la administración y comunicación entre la infraestructura y los servicios de Openstack en containers o en servidores físicos. Para que todas las instancias tengan acceso a esta red, es necesario que todos los nodos host del datacenter cuenten con el bridge br-mgmt. A este último se le asocian las interfaces virtuales de cada contenedor y la lógica o física del host en cuestión, asignadas a dicha red. Esta interfaz suele ser la primaria del nodo mediante la cual se accede por SSH.
+
+\subparagraph{Overlay Network}
+La red de superposición o también tunnel network, provee conectividad entre los hosts virtualizados dentro de Openstack encapsulando el tráfico con algún protocolo de tunelización como son VXLAN o GENEVE. La VLAN o interfaz utilizada para esta subred se asocia al bridge br-vxlan. Este bridge debe instanciarse en todos los nodos que manejen agentes del módulo Neutron, típicamente involucra los nodos de cómputo y/o red.
+
+\subparagraph{Storage Network}
+La red de almacenamiento provee acceso entre los backends de almacenamiento, tales como Block storage, y los servicios de Openstack, como Cinder o Glance. En este caso las interfaces o VLANs se asocian al bridge br-storage, que debe instanciarse en todos los nodos que alojan servicios de cómputo o almacenamiento.
+
+\subsubsection{Interfaces de red}
+Como se mencionó en OSA se pueden tener diversas configuraciones dependiendo de la cantidad de interfaces del host físico, algunas de ellas se muestran a continuación.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{interfaces}
+	\caption{Diagrama de múltiples interfaces de red}
+	\label{interfaces}
+\end{figure}
+
+En la figura \ref{interfaces} se utilizan dos interfaces simples, subdivididas mediante la implementación de VLANs que finalmente se asocian a los bridges mencionados anteriormente.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{bonded-interfaces}
+	\caption{Diagrama de bonds de múltiples interfaces de red}
+	\label{bonded-interfaces}
+\end{figure}
+
+En el segundo, se cuenta con cuatro interfaces (provenientes de dos tarjetas físicas) que son bondeadas en forma cruzada para mejorar la disponibilidad y subdivididas mediante la implementación de VLANs para finalmente asociarlas a los bridges.\\
+
+En ambos casos, se resalta la separación de las redes tenant con las redes internas para el funcionamiento de OSA y la ausencia de veth pairs asociadas a los bridges debido a que no se visualizan servicios desplegados en contenedores. \\
+
+A continuación se presenta un diseño que ilustra servicios desplegados en contenedores y cómo varían las interconexiones de red para proveer conectividad.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{containers-deploy}
+	\caption{Despliegue de servicios Openstack en contenedores}
+	\label{containers-deploy}
+\end{figure}
+
+Como se menciona anteriormente los contenedores que corren servicios de Openstack requieren de interfaces virtuales para conectarse con los bridges del nodo físico. Además se puede observar cómo varían las conexiones necesarias a los distintos tipos de red, en función del tipo de agente que corre en el contenedor. Al utilizar contenedores, OSA crea automáticamente una nueva red que se utilizará para la administración de los mismos (por ejemplo para descargar paquetes). Un punto a tener en cuenta es que Ansible para crear esta subred utiliza el rango 10.0.3.0/24.
+
+
 
 %Estos valores servirán de referencia para tomar las decisiones a la hora de bajar y subir de estado. Los estados consisten en los pares (power, rate) asociados a la transmisión entre las terminales y son ordenados de forma que un mayor estado implica menor power y mayor rate. El pseudocódigo asociado al orden entre estados puede verse en el algoritmo \ref{alg1}.
 %
diff --git a/docs/latex/report.toc b/docs/latex/report.toc
index 56e024310ece4b2a37cfeb587c742ca78c13ee08..6e7dbdca6ff3589a801854b48b77a1fccf86b69d 100644
--- a/docs/latex/report.toc
+++ b/docs/latex/report.toc
@@ -3,14 +3,53 @@
 \contentsline {chapter}{\numberline {2}Marco te\IeC {\'o}rico}{3}{chapter.2}
 \contentsline {section}{\numberline {2.1}Cloud computing}{3}{section.2.1}
 \contentsline {section}{\numberline {2.2}Virtualizaci\IeC {\'o}n}{4}{section.2.2}
-\contentsline {subparagraph}{KVM}{4}{section*.3}
-\contentsline {section}{\numberline {2.3}Contenerizaci\IeC {\'o}n}{4}{section.2.3}
-\contentsline {subparagraph}{LXC}{5}{section*.5}
-\contentsline {section}{\numberline {2.4}Datacenters}{5}{section.2.4}
+\contentsline {subparagraph}{KVM}{5}{section*.3}
+\contentsline {section}{\numberline {2.3}Contenerizaci\IeC {\'o}n}{5}{section.2.3}
+\contentsline {subparagraph}{LXC}{6}{section*.5}
+\contentsline {section}{\numberline {2.4}Datacenters}{6}{section.2.4}
 \contentsline {section}{\numberline {2.5}Redes}{6}{section.2.5}
-\contentsline {subparagraph}{Flat}{6}{section*.6}
-\contentsline {subparagraph}{VLAN}{6}{section*.7}
-\contentsline {subparagraph}{VXLAN}{6}{section*.8}
-\contentsline {chapter}{\numberline {3}Openstack}{7}{chapter.3}
-\contentsline {section}{\numberline {3.1}Origen y definici\IeC {\'o}n}{7}{section.3.1}
-\contentsline {section}{\numberline {3.2}M\IeC {\'o}dulos Core}{7}{section.3.2}
+\contentsline {subparagraph}{Flat}{7}{section*.6}
+\contentsline {subparagraph}{VLAN}{7}{section*.7}
+\contentsline {subparagraph}{VXLAN}{7}{section*.8}
+\contentsline {chapter}{\numberline {3}Openstack}{8}{chapter.3}
+\contentsline {section}{\numberline {3.1}Origen y definici\IeC {\'o}n}{8}{section.3.1}
+\contentsline {section}{\numberline {3.2}M\IeC {\'o}dulos Core}{9}{section.3.2}
+\contentsline {subsection}{\numberline {3.2.1}Keystone}{9}{subsection.3.2.1}
+\contentsline {subsection}{\numberline {3.2.2}Nova}{10}{subsection.3.2.2}
+\contentsline {subparagraph}{API}{11}{section*.12}
+\contentsline {subparagraph}{Scheduler}{11}{section*.13}
+\contentsline {subparagraph}{Compute}{11}{section*.14}
+\contentsline {subparagraph}{Conductor}{11}{section*.15}
+\contentsline {subparagraph}{Placement}{12}{section*.16}
+\contentsline {subsection}{\numberline {3.2.3}Neutron}{12}{subsection.3.2.3}
+\contentsline {subparagraph}{Neutron-server}{13}{section*.19}
+\contentsline {subparagraph}{Plugins y agentes}{13}{section*.20}
+\contentsline {subparagraph}{Cola de mensajes}{13}{section*.21}
+\contentsline {subsection}{\numberline {3.2.4}Glance}{13}{subsection.3.2.4}
+\contentsline {subparagraph}{Creaci\IeC {\'o}n de una VM}{14}{section*.23}
+\contentsline {subsection}{\numberline {3.2.5}Cinder}{16}{subsection.3.2.5}
+\contentsline {subsection}{\numberline {3.2.6}Swift}{17}{subsection.3.2.6}
+\contentsline {subparagraph}{Principales componentes}{18}{section*.27}
+\contentsline {section}{\numberline {3.3}Tipos de nodos}{19}{section.3.3}
+\contentsline {subparagraph}{Nodo de control}{19}{section*.28}
+\contentsline {subparagraph}{Nodo de red}{19}{section*.29}
+\contentsline {subparagraph}{Nodo de c\IeC {\'o}mputo}{19}{section*.30}
+\contentsline {subparagraph}{Nodo de almacenamiento}{19}{section*.31}
+\contentsline {subparagraph}{Nodo de balanceamiento de carga}{19}{section*.32}
+\contentsline {section}{\numberline {3.4}Servicios de infraestructura}{19}{section.3.4}
+\contentsline {subparagraph}{Galera - MariaDB}{19}{section*.33}
+\contentsline {subparagraph}{Message queue}{20}{section*.34}
+\contentsline {subparagraph}{Memcached}{20}{section*.35}
+\contentsline {section}{\numberline {3.5}M\IeC {\'e}todos de instalaci\IeC {\'o}n}{20}{section.3.5}
+\contentsline {subsection}{\numberline {3.5.1}Ansible}{21}{subsection.3.5.1}
+\contentsline {subparagraph}{Nodo de control}{21}{section*.36}
+\contentsline {subparagraph}{Inventario}{21}{section*.37}
+\contentsline {subparagraph}{M\IeC {\'o}dulos}{21}{section*.38}
+\contentsline {subparagraph}{Tarea}{21}{section*.39}
+\contentsline {subparagraph}{Playbook}{21}{section*.40}
+\contentsline {section}{\numberline {3.6}Arquitectura}{21}{section.3.6}
+\contentsline {subsection}{\numberline {3.6.1}Arquitectura de red}{22}{subsection.3.6.1}
+\contentsline {subparagraph}{Management Network}{22}{section*.42}
+\contentsline {subparagraph}{Overlay Network}{22}{section*.43}
+\contentsline {subparagraph}{Storage Network}{22}{section*.44}
+\contentsline {subsubsection}{Interfaces de red}{23}{section*.45}
diff --git a/docs/latex/resources/bonded-interfaces.png b/docs/latex/resources/bonded-interfaces.png
new file mode 100644
index 0000000000000000000000000000000000000000..ece72874bcbb4d6d01e14982cf9b57605383b423
Binary files /dev/null and b/docs/latex/resources/bonded-interfaces.png differ
diff --git a/docs/latex/resources/containers-deploy.png b/docs/latex/resources/containers-deploy.png
new file mode 100644
index 0000000000000000000000000000000000000000..1dccadb60029d9ad11a8c53d77b371e94ee6d121
Binary files /dev/null and b/docs/latex/resources/containers-deploy.png differ
diff --git a/docs/latex/resources/interfaces.png b/docs/latex/resources/interfaces.png
new file mode 100644
index 0000000000000000000000000000000000000000..c59607870e2a22cdee6159dc2b1ad19ab80b5b02
Binary files /dev/null and b/docs/latex/resources/interfaces.png differ
diff --git a/docs/latex/resources/network-components.png b/docs/latex/resources/network-components.png
new file mode 100644
index 0000000000000000000000000000000000000000..e389b36e606ad615e06b9847b6cc26d43c79be33
Binary files /dev/null and b/docs/latex/resources/network-components.png differ