diff --git a/docs/udelartex/capitulos/chap02.tex b/docs/udelartex/capitulos/chap02.tex
index 25aa58aa6118aa4b28f32864edd78f616786b3d8..62a994d8843d94f72e548a86de88dba89aad957a 100644
--- a/docs/udelartex/capitulos/chap02.tex
+++ b/docs/udelartex/capitulos/chap02.tex
@@ -24,7 +24,7 @@ En cuanto a los modelos de cloud computing, existen tres clasificaciones que se
 \begin{itemize}
 \item \textbf{\gls{SAAS}}: refiere al servicio que provee aplicaciones a través de internet que se encuentran corriendo en la infraestructura de la nube (Datacenter). Los consumidores del servicio no manipulan la infraestructura subyacente ni las configuraciones de aplicación.
 
-\item \textbf{\gls{PAAS}}: consiste en proveer recursos a nivel de plataforma, como por ejemplo soporte de sistemas operativos, que permiten al cliente desplegar sus propias aplicaciones. El consumidor no puede manipular la infraestructura pero sí es capaz de manipular lo que se despliega sobre ella.
+\item \textbf{\gls{PAAS}}: consiste en proveer recursos a nivel de plataforma, como por ejemplo soporte de sistemas operativos, que permiten al cliente desplegar sus propias aplicaciones. El consumidor no puede manipular la infraestructura pero sí es capaz de administrar lo que se despliega sobre ella.
 
 \item \textbf{\gls{IAAS}}: se asocia al suministro de recursos de infraestructura a demanda. Se suele proveer al cliente de capacidad de procesamiento, almacenamiento y conectividad de red. Típicamente se ofrecen máquinas virtuales con la posibilidad de que el cliente manipule los sistemas operativos y las aplicaciones. Nuevamente el consumidor no es capaz de influir en la infraestructura que implementa la nube.
 \end{itemize}
@@ -50,7 +50,7 @@ Los hipervisores se suelen clasificar en dos tipos:
 \end{itemize}
 
 \subparagraph{KVM}
-\gls{KVM} \cite{redhat-kvm} se trata de una tecnología de virtualización open source sobre Linux. Se encuentra formada por un módulo del kernel denominado kvm.ko y permite transformar un sistema operativo Linux en un hipervisor. Como módulo del kernel se encuentra incluido en Linux a partir de la versión 2.6.20. Como hipervisor se clasifica como de tipo alojado, o hosted, utilizando los componentes del sistema Linux para implementar cada máquina virtual como un proceso de Linux.
+\gls{KVM} \cite{redhat-kvm} se trata de una tecnología de virtualización open source sobre Linux. Se encuentra formada por un módulo del kernel denominado KVM.ko y permite transformar un sistema operativo Linux en un hipervisor. Como módulo del kernel se encuentra incluido en Linux a partir de la versión 2.6.20. Como hipervisor se clasifica como de tipo alojado, o hosted, utilizando los componentes del sistema Linux para implementar cada máquina virtual como un proceso de Linux.
 
 \section{Contenerización}
 Un contenedor \cite{docker-containers} es una unidad de software liviana diseñada para ejecutar una aplicación. Está formado únicamente por el código de la aplicación y las dependencias necesarias para que esta ejecute, creando un paquete portable e independiente. De esta forma múltiples contenedores pueden correr como procesos diferentes en una misma máquina host compartiendo el kernel del sistema operativo.
@@ -68,7 +68,7 @@ La combinación de estas tecnologías provee gran flexibilidad al realizar el de
 Citando la ‘Application Container Security Guide’ (SP 800-190 de NIST \cite{sp800-190}): \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.
 
 \subparagraph{LXC}
-Un \gls{LXC} \cite{arch-lxc}\cite{redhat-lxc} es un contenedor formado por un conjunto de procesos que se encuentran aislados del resto del sistema host. Como tal, brinda un entorno virtual con su propia CPU, memoria, red, etc, implementado mediante el uso de los namespaces y cgroups del kernel linux corriendo en la máquina host. Este tipo de contenedores es utilizado por Openstack durante su despliegue para ejecutar los servicios en cuya configuración se haya indicado que utilicen contenedores en lugar de correr directo sobre el servidor.
+Un \gls{LXC} \cite{arch-lxc}\cite{redhat-lxc} es un contenedor formado por un conjunto de procesos que se encuentran aislados del resto del sistema host. Como tal, brinda un entorno virtual con su propia CPU, memoria, red, etc, implementado mediante el uso de los namespaces y cgroups del kernel Linux corriendo en la máquina host. Este tipo de contenedores es utilizado por Openstack durante su despliegue para ejecutar los servicios en cuya configuración se haya indicado que utilicen contenedores en lugar de correr directo sobre el servidor.
 
 \section{Datacenters}
 La infraestructura que se encuentra por debajo de la mencionada nube se conoce con el nombre de Datacenter. Un Datacenter \cite{cisco-datacenter} es un espacio físico que aloja múltiples componentes de hardware interconectados tales como servidores, racks, switches, routers, sistemas de almacenamiento, etc. Estos últimos proveen una red de recursos de red, cómputo y almacenamiento, necesaria para alojar diversas aplicaciones o grandes cantidades de datos. A su vez, los nuevos Datacenters escalan implementando infraestructuras virtualizadas, utilizando los mecanismos mencionados anteriormente, por encima de la física ya existente llegando a interconectar múltiples espacios físicos ubicados en diversas partes del mundo. Debido al gran potencial computacional existente en este tipo de infraestructuras, su mayor explotación se encuentra en la ejecución de tecnologías tales como big data, inteligencia artificial, aprendizaje automático, entre otras.
@@ -89,7 +89,7 @@ Por su gran importancia en la tecnología de la información actual, los Datacen
 En la etapa de configuración e instalación y posteriormente en la utilización de Openstack, se referencian diversos conceptos de red, por ejemplo, protocolos, tipos de redes y componentes virtualizados. A continuación se introducirán brevemente algunos de estos conceptos.
 
 \subparagraph{Flat}
-Una red Flat hace referencia a una red en la cual no se utiliza ningún tipo de tag. Las interfaces físicas o virtuales se asocian directamente al switch o bridge por lo tanto solamente una red flat puede existir por cada interfaz física.
+Una red flat hace referencia a una red en la cual no se utiliza ningún tipo de tag. Las interfaces físicas o virtuales se asocian directamente al switch o bridge por lo tanto solamente una red flat puede existir por cada interfaz física.
 
 \subparagraph{VLAN}
 Una \gls{VLAN} permite segmentar de manera virtual un dominio de difusión de capa 2 en múltiples dominios de difusión. Esto permite utilizar un switch como si fuera múltiples switches. A modo de ejemplo, dos host conectados a un mismo switch pero en distintas VLANs no podrán ver el tráfico generado por el otro. Para identificar a qué VLAN corresponde una trama se utiliza un nuevo campo en el cual se introduce el ID de la VLAN, estos cambios que se realizan a la trama Ethernet se establecen en el estándar IEEE 802.1Q \cite{802.1Q}. Openstack utiliza las VLANs con el fin de aislar el tráfico de datos de diferentes clientes, sin importar en qué servidor físico (nodo de cómputo) estén corriendo las máquinas de los mismos \cite{openstack-basic-networking}.
@@ -98,24 +98,24 @@ Una \gls{VLAN} permite segmentar de manera virtual un dominio de difusión de ca
 El protocolo \gls{VXLAN} se ubica dentro de los protocolos de superposición (overlay protocols) que utilizan el mecanismo de tunelización para el transporte de datos. VXLAN encapsula una trama Ethernet dentro de paquetes UDP los cuales pueden ser ruteados. Esto permite extender una red local sobre múltiples redes de capa 3 en forma transparente para los host finales. El funcionamiento del protocolo se encuentra en el RFC 7348 \cite{rfc7348}. Para diferenciar las distintas redes virtuales en lugar de utilizar un VLAN ID se utiliza un VXLAN Network Identifier (VNI), el cual puede tomar aproximadamente 16 millones de valores siendo una de las principales diferencias con las VLANs que pueden tomar 4096 valores únicos. Esta diferencia para Datacenters de gran porte es vital para poder aislar el tráfico de los clientes del mismo. Un componente necesario para encapsular y desencapsular son los VXLAN Tunnel Endpoint (VTEP) los cuales residen en los nodos físicos. Un listado con pros y contras de las redes de capa 2 y capa 3 se presenta en \cite{openstack-networking-concepts}.
 
 \subparagraph{Network namespaces}
-El concepto de namespace es utilizado para brindar aislamiento entre dos conjuntos de recursos. Precisamente en Linux los namespaces de red aislan diversos recursos de red permitiendo mantener disjuntos conjuntos de interfaces e incluso tablas de ruteo. Esto último es utilizado por el módulo de red de Openstack a la hora de instanciar servicios de red virtuales tales como routing y DHCP. De esta forma es posible que coexistan diferentes redes virtuales con el mismo direccionamiento IP en un mismo servidor de red sin solaparse \cite{openstack-network-namespaces}.
+El concepto de namespace es utilizado para brindar aislamiento entre dos conjuntos de recursos. Precisamente en Linux los namespaces de red aíslan diversos recursos de red permitiendo mantener disjuntos conjuntos de interfaces e incluso tablas de ruteo. Esto último es utilizado por el módulo de red de Openstack a la hora de instanciar servicios de red virtuales tales como routing y DHCP. De esta forma es posible que coexistan diferentes redes virtuales con el mismo direccionamiento IP en un mismo servidor de red sin solaparse \cite{openstack-network-namespaces}.
 
 \section{Interfaces y bridges}
 Desde el diseño de la arquitectura física hasta la implementación de instancias virtuales por parte de Openstack, se utilizan una serie de interfaces y bridges de diferentes tipos para proveer conectividad de red. Estos tipos son detallados brevemente a continuación.
 
 \subparagraph{Interfaces tap} 
-Estas interfaces son creadas y utilizadas por un hypervisor como QEMU/KVM para conectar una instancia de una VM con el host subyacente. Las interfaces en el host se corresponden a una interfaz de red dentro de la instancia.
+Estas interfaces son creadas y utilizadas por un hipervisor como QEMU/KVM para conectar una instancia de una VM con el host subyacente. Las interfaces en el host se corresponden a una interfaz de red dentro de la instancia.
 
 \subparagraph{Linux bridge} 
 Es una interfaz virtual que conecta múltiples interfaces de red. Se comporta como un switch virtual al cual se asocian uno o más segmentos de red. Particularmente, en Openstack se utilizan este tipo de bridges para bridar conexión a los servicios que se encuentran corriendo en contenedores. También son aplicados por el módulo de red a la hora de interconectar las instancias con las redes virtuales a nivel del host físico \cite{arch-network-bridge}. 
 
 \subparagraph{Veth cables} 
-Son interfaces virtuales que imitan el comportamiento de un cable de red. Una trama enviada en un extremo del veth cable será recibida por el otro extremo. El módulo de red utiliza estos dispositivos cuando realiza conexiones entre network namespaces y Linux bridges, así como cuando conecta Linux bridges con OpenvSwitch switches.
+Son interfaces virtuales que imitan el comportamiento de un cable de red. Una trama enviada en un extremo del veth cable será recibida por el otro. El módulo de red utiliza estos dispositivos cuando realiza conexiones entre network namespaces y Linux bridges, así como cuando conecta Linux bridges con OpenvSwitch switches.
 
 \section{Backends de almacenamiento}
 
 \subsection{LVM}
-\gls{LVM} es una herramienta para la administración de volúmenes lógicos en sistemas operativos Linux. A nivel del sistema es capaz de asignar discos, realizar copias y ajustar el tamaño de los mencionados volúmenes \cite{redhat-lvm}. A nivel de OpenStack es relevante debido a que se trata del backend de almacenamiento utilizado por defecto por el módulo Cinder.
+\gls{LVM} es una herramienta para la administración de volúmenes lógicos en sistemas operativos Linux. A nivel del sistema es capaz de asignar discos, realizar copias y ajustar el tamaño de los mencionados volúmenes \cite{redhat-lvm}. A nivel de Openstack es relevante debido a que se trata del backend de almacenamiento utilizado por defecto por el módulo Cinder.
 
 \subsection{Ceph}
 Ceph se trata de un sistema de almacenamiento de datos distribuido y libre. Unifica el almacenamiento de objetos, bloques y archivos en un sistema altamente confiable y escalable basado en el servicio RADOS \cite{rados}. Este utiliza el algoritmo CRUSH \cite{crush} para procesar la ubicación de los datos en forma eficiente dentro del cluster que puede alcanzar grandes cantidades de nodos. Cada uno de los nodos del cluster ejecuta un demonio que es capaz de comunicarse por si solo con los demás con el fin de replicar y redistribuir la información en forma dinámica. Estos demonios se clasifican en dos tipos:
diff --git a/docs/udelartex/resumen/resumen.tex b/docs/udelartex/resumen/resumen.tex
index 08528dad9a25aaea88a5fca2f8dd2d530da4a2a5..5d96ac53d4e9cff5c289c3a743ecf78faca3652b 100644
--- a/docs/udelartex/resumen/resumen.tex
+++ b/docs/udelartex/resumen/resumen.tex
@@ -1,6 +1,6 @@
 \begin{abstract}
 
-El presente documento estudia los aspectos fundamentales de la plataforma Openstack. A su vez, relata el proceso de diseño, instalación, y configuración básica de un datacenter mediante la utilización de dicha plataforma. Se especifican los pasos necesarios a seguir y se detallan puntos sumamente relevantes a tener en cuenta. Por otro lado, se realiza un análisis del módulo de red Neutron enfocado en resolver la comunicación entre máquinas virtuales instanciadas en el datacenter, particularmente buscando responder cómo realiza la comunicación entre las redes físicas de la infraestructura y las redes virtuales creadas por el usuario final.
+El presente documento estudia los aspectos fundamentales de la plataforma Openstack. A su vez, relata el proceso de diseño, instalación, y configuración básica de un Datacenter mediante la utilización de dicha plataforma. Se especifican los pasos necesarios a seguir y se detallan puntos sumamente relevantes a tener en cuenta. Por otro lado, se realiza un análisis del módulo de red Neutron enfocado en resolver la comunicación entre máquinas virtuales instanciadas en el Datacenter, particularmente buscando responder cómo realiza la comunicación entre las redes físicas de la infraestructura y las redes virtuales creadas por el usuario final.
 
 \end{abstract}
 
diff --git a/docs/udelartex/tesis.pdf b/docs/udelartex/tesis.pdf
index cb946a27f3489f766ef3711a1f2db99fea2dc450..6f6e0e4f1246d5926c6f33b1173dd3e2ad899cd7 100644
Binary files a/docs/udelartex/tesis.pdf and b/docs/udelartex/tesis.pdf differ
diff --git a/docs/udelartex/tesis.synctex.gz b/docs/udelartex/tesis.synctex.gz
index 8eea76202964c04f88584d1b450437105eed4cfb..1fd66c19aae230e7aa7d5504d66bd455d4497a5c 100644
Binary files a/docs/udelartex/tesis.synctex.gz and b/docs/udelartex/tesis.synctex.gz differ