Aplicadas correcciones finales a capítulos 1, 2, 3, 5 y 6. Falta el 4

capitulos/conclusiones.tex

@@ -14,7 +14,8 @@ \section{Fortalezas}
 
 Inicialmente, se pretendía desarrollar un conjunto de \acp{API} para poder diseñar un entorno heterogéneo donde las tecnologías \ac{SDN} y \ac{NFV} cumplieran un papel fundamental en él, mediante diferentes herramientas que siguen dichas tecnologías operando en total sintonía.
 
-Una vez acabado el proyecto, cabe decir que la principal fortaleza de este Trabajo de Fin de Máster es que los diferentes objetivos propuestos al inicio se han conseguido satisfactoriamente, cumpliendo las expectativas puestas al comiendo del mismo.
+Una vez acabado el proyecto, cabe decir que la principal fortaleza de este Trabajo de Fin de Máster es la creación de clientes \textit{open-source} que permiten tener interfaces de comunicación con distintos módulos \ac{SDN}-\ac{NFV} para proporcionar optimización a entornos de red heterogéneos, permitiendo reducir la latencia en el establecimiento de una \textit{Service Chain}, algo básico en el contexto de 5G.
+
 
 \section{Análisis de resultados}
 
@@ -24,10 +25,6 @@ \section{Análisis de resultados}
 
 Por ello, la creación de J-OSMClient proporciona una amplio abanico de trabajo, permitiendo que \ac{OSM} sea gestionado por una aplicación externa.
 
-Para finalizar el análisis de resultados, hay que mencionar los resultados obtenidos al realizar la prueba de concepto. Una vez instanciados los \acp{VNF} correspondientes a la \textit{Service Chain} y habiendo instalado las reglas de flujo correspondientes a la ruta óptima obtenida en los \textit{switches}, se realizan una prueba de conexión enviando un ping entre el origen y el destino. 
-
-En la figuras \ref{fig:nfvservicechain} y \ref{fig:topo_onos} se puede observar como la ruta es la misma en ambos casos (en el plugin de Net2Plan y en \ac{ONOS}), y en la figura \ref{fig:onosflowrules} como las reglas de flujo aplicadas indican que han procesado un paquete, que corresponde al ping realizado anteriormente para validad la conectividad.
-
 
 \section{Líneas de trabajo futuro y mejoras}
 

capitulos/desarrollo.tex

@@ -20,7 +20,7 @@ \section{J-OSM Client}
 \begin{itemize}
 	\item \textbf{OSMControllerRelease3:} Es la entidad que se encarga de realizar la comunicación con la \textit{release} 3 de \ac{OSM}. Mediante llamadas \ac{HTTP} (GET, POST, PUT, DELETE), dicha clase envía peticiones y procesa internamente las respuestas recibidas.
 
-	\item \textbf{OSMControllerSOL005:} Esta entidad se encarga de realizar la comunicación con la \textit{release} 4 en adelante, utilizando el estándar sol005. Al igual que el \textit{controller} de la \textit{release} 3, establece la comunicación con llamadas \ac{HTTP} enviando peticiones y procesando las diferentes respuestas recibidas.
+	\item \textbf{OSMControllerSOL005:} Esta entidad se encarga de realizar la comunicación con la \textit{release} 4 en adelante, utilizando el estándar sol005\cite{sol005item}. Al igual que el \textit{controller} de la \textit{release} 3, establece la comunicación con llamadas \ac{HTTP} enviando peticiones y procesando las diferentes respuestas recibidas.
 
 	\item \textbf{OSMClient:} Es la clase principal de la aplicación. Actúa como interfaz entre el usuario final y los \textit{controllers}, permitiendo que el usuario obtenga directamente en formato más amigable las respuestas dadas por el servidor de \ac{OSM}.
 \end{itemize}
@@ -63,7 +63,7 @@ \section{J-OSM Client}
 \section{J-ONOS Client}
 \label{sec:onosclient}
 
-J-ONOSClient\cite{onosjavadocbib} es una librería programada en Java cuya funcionalidad es la de proporcionar un cliente \ac{REST} para interactuar con \ac{ONOS} (ver \ref{sec:onos}). Esta librería está basada en la representación de objetos que proveé Swagger (ver \ref{subsec:openapi}). Gracias a Swagger, se puede generar automáticamente un cliente que interactúe con \ac{ONOS} en cualquier lenguaje de programación.
+J-ONOSClient\cite{onosjavadocbib} es una librería programada en Java cuya funcionalidad es la de proporcionar un cliente \ac{REST} para interactuar con \ac{ONOS} (ver \ref{sec:onos}). Esta librería está basada en la representación de objetos que proveé Swagger (ver \ref{subsec:openapi}). Gracias a Swagger, se puede generar de forma semi automática un cliente que interactúe con \ac{ONOS} en cualquier lenguaje de programación.
 
 Este cliente generado proveé una representación de diferentes componentes, cada uno de ellos con una clase asociada que actúa como interfaz con \ac{ONOS} para controlar las interacciones que involucran a dicho componente. A continuación se explica cada uno de los componentes mencionados anteriormente:
 

capitulos/estadodelarte.tex

@@ -37,16 +37,8 @@ \section{SDN}
 
 \subsection{Arquitectura SDN}
 
-Las redes definidas por \textit{software} constan de una arquitectura de red específica, compuesta por distintos componentes \textit{hardware} y \textit{software} que interactúan entre sí, como se puede ver en la figura \ref{fig:arquitecturasdn}.
-
-\begin{figure}[!ht]
-	\centering
-	\includegraphics[width=0.75\linewidth]{imagenes/arquitectura_sdn}
-	\caption{Arquitectura SDN. Fuente:\cite{sdnbib}}
-	\label{fig:arquitecturasdn}
-\end{figure}
+Las redes definidas por \textit{software} constan de una arquitectura de red específica, compuesta por distintos componentes \textit{hardware} y \textit{software} que interactúan entre sí. Dichos componentes se explican a continuación:
 
-Los diferentes elementos que componen la arquitectura \ac{SDN} son los siguientes:
 
 \begin{itemize}
 	\item \textbf{Controlador \ac{SDN}:} Es el cerebro de la red \ac{SDN}. Forma el núcleo de la arquitectura \ac{SDN} comunicándose con los \textit{switches} a través de la \textbf{Interfaz Sur} (\ac{SBI}) y con las distintas aplicaciones a través de la \textbf{Interfaz Norte} (\ac{NBI}).
@@ -55,11 +47,22 @@ \subsection{Arquitectura SDN}
 
 	\item \textbf{Interfaz Norte (\ac{NBI}):} Es la interfaz que conecta al controlador \ac{SDN} con el plano de control. Facilita el proceso de automatización de la red mediante la comunicación del controlador con las diferentes aplicaciones. Para permitir dicha comunicación con las aplicaciones, la interfaz norte exporta una \ac{API} del tipo \ac{REST}.
 
-	\item \textbf{Agentes y \textit{Drivers}:} Para establecer la comunicación entre el controlador y los dispositivos mediante la interfaz sur y para la comunicación entre el controlador y las aplicaciones mediante la interfaz norte,es necesario un par agente-\textit{driver}. El \textit{driver} se encuentra en el controlador, mientras que el agente se encuentra en el dispositivo. Se encargan de realizar la comunicación en el plano de datos, realizando la conversión del lenguaje del controlador al del dispositivo, y viceversa.
-
 	\item \textbf{Aplicaciones \ac{SDN}:} Son programas que se conectan al controlador \ac{SDN} mediante la interfaz norte. Gracias a su lógica de aplicaciones, desarrollan un próposito concreto y transfieren datos u órdenes al controlador \ac{SDN}.
+
+	\item \textbf{Agentes y \textit{Drivers}:} Para establecer la comunicación entre el controlador y los dispositivos mediante la interfaz sur y para la comunicación entre el controlador y las aplicaciones mediante la interfaz norte, es necesario un par agente-\textit{driver}. 
+
+	Mientras que en la \ac{NBI} el driver se encuentra en la aplicación y el agente en el controlador, en la \ac{SBI}, el driver se encuentra en el controlador y el agente en el dispositivo. Se encargan de realizar la comunicación entre la aplicación y el controlador en la \ac{NBI} y entre el controlador y los dispositivos de red en la \ac{SBI}, realizando las conversiones de lenguaje necesarias.
 \end{itemize}
 
+\begin{figure}[!ht]
+	\centering
+	\includegraphics[width=0.75\linewidth]{imagenes/arquitectura_sdn}
+	\caption{Arquitectura SDN. Fuente:\cite{sdnbib}}
+	\label{fig:arquitecturasdn}
+\end{figure}
+
+En la figura \ref{fig:arquitecturasdn} se pueden apreciar una visión general de la arquitectura \ac{SDN} mostrando la conectividad entre los diferentes componentes explicados anteriormente.
+
 
 \subsection{OpenFlow}
 \label{subsec:openflow}
@@ -119,7 +122,7 @@ \subsection{Arquitectura NFV}
 \begin{figure}[!ht]
 	\centering
 	\includegraphics[width=0.75\linewidth]{imagenes/arquitectura_nfv}
-	\caption{Arquitectura NFV}
+	\caption{Arquitectura NFV. Fuente:\cite{nfvbib}}
 	\label{fig:arquitecturanfv}
 \end{figure}
 
@@ -157,7 +160,7 @@ \section{Relación entre SDN y NFV}
 \begin{figure}[!ht]
 	\centering
 	\includegraphics[width=0.8\linewidth]{imagenes/servicechaining}
-	\caption{Ejemplo de \textit{Service Chaining}}
+	\caption{Ejemplo de \textit{Service Chaining}. Fuente:\cite{servicechainingbib}}
 	\label{fig:servicechaining}
 \end{figure}
 
@@ -187,15 +190,15 @@ \section{Herramientas Open-Source en redes de telecomunicación}
 Dichas herramientas forman un gran conjunto heterogéneo, siendo desarrollada cada una de ellas para uno o más propósitos:
 
 \begin{itemize}
-	\item Para sacar el máximo rendimiento a la infraestructura de una red, existen herramientas de virtualización como \textbf{OpenStack} (ver \ref{sec:openstack}) o \textbf{Docker}, para proveer a las aplicaciones de una abstracción e independencia. Este tipo de herramientas se enmarcan dentro de la tecnología \textbf{\ac{NFV}} (ver \ref{sec:nfv}).
+	\item Para sacar el máximo rendimiento a la infraestructura de una red, existen herramientas de virtualización como \textbf{OpenStack}\cite{openstackbib} o \textbf{Docker}\cite{dockerbib}, para proveer a las aplicaciones de una abstracción e independencia. Este tipo de herramientas se enmarcan dentro de la tecnología \textbf{\ac{NFV}} (ver \ref{sec:nfv}).
 
-	\item Para agilizar el envío y procesamiento del tráfico de una red, existen herramientas que permiten emular el comportamiento de diversos dispositivos hardware a través de la virtualización, como \textbf{OpenVSwitch} o \textbf{Mininet} (ver \ref{sec:mininet}). Gracias a este tipo de herramientas, se puede sustituir un \textit{Switch} clásico por un pequeño software que hace las funciones de un \textit{Switch} de una manera más eficiente.
+	\item Para agilizar el envío y procesamiento del tráfico de una red, existen herramientas que permiten emular el comportamiento de diversos dispositivos hardware a través de la virtualización, como \textbf{OpenVSwitch}\cite{openvswitchbib} o \textbf{Mininet}\cite{mininetbib}. Gracias a este tipo de herramientas, se puede sustituir un \textit{Switch} clásico por un pequeño software que hace las mismas funciones que uno tradicional.
 
-	\item La gestión de los dispositivos se ha realizado de forma manual, dispositivo a dispositivo. Gracias a herramientas software como \textbf{Cacti} o \textbf{Nagios}, la forma de gestionar las redes de telecomunicación ha dado un giro de 180 grados. Utilizando estas herramientas, el usuario puede gestionar la red desde un terminal de manera remota, gracias al protocolo \ac{SNMP}.
+	\item La gestión de los dispositivos se ha realizado de forma manual, dispositivo a dispositivo. Gracias a herramientas software como \textbf{Cacti}\cite{cactibib} o \textbf{Nagios}\cite{nagiosbib}, la forma de gestionar las redes de telecomunicación ha dado un giro de 180 grados. Utilizando estas herramientas, el usuario puede gestionar la red desde un terminal de manera remota, gracias al protocolo \ac{SNMP}.
 
 	\item Para acelerar y automatizar la configuración de los dispositivos de una red de telecomunicación, existen herramientas enmarcadas en la tecnología \textit{\ac{SDN}} (ver \ref{sec:sdn}). Un ejemplo de estas herramientas es el controlador \ac{SDN} \ac{ONOS} (ver \ref{sec:onos}).
 
-	\item Para reducir los costes de operación de una red, existen herramientas open-source que ayudan a planificar una red de telecomunicación de forma óptima. La más conocida de estas herramientas es \textbf{Net2Plan} (ver \ref{sec:net2plan}), una herramienta de planificación de redes programada en Java.
+	\item Para reducir los costes de operación de una red, existen herramientas open-source que ayudan a planificar una red de telecomunicación de forma óptima. La más conocida de estas herramientas es \textbf{Net2Plan}\cite{net2planbib}, una herramienta de planificación de redes programada en Java.
 \end{itemize}
 
 

capitulos/herramientas.tex

@@ -3,7 +3,7 @@ \chapter{Herramientas utilizadas}
 
 En este capítulo se va a hacer una descripción de cada una de las herramientas utilizadas en el proyecto, haciendo especial mención a Net2Plan, que es una herramienta cuya funcionalidad es la de emular y planificar una red de telecomunicación. Dicha herramienta constituye la base para el desarrollo de este proyecto, más concretamente de la prueba de concepto.
 
-Además de Net2Plan, se han utilizado otras herramientas para complementar la funcionalidad de Net2Plan y proveerle diferentes funcionalidad enmarcadas en las tecnologías \ac{SDN} y \ac{NFV}. Dichas herramientas son Mininet, para emular redes de telecomunicación; ONOS, un controlador \ac{SDN}; \ac{OSM}, un gestor y orquestador \ac{NFV}; y OpenStack, una herramienta para emular una infraestructura IT.
+Además de Net2Plan, se han utilizado otras herramientas para complementar la funcionalidad de Net2Plan y permitirle emular escenarios basados en las tecnologías \ac{SDN} y \ac{NFV}. Dichas herramientas son Mininet, para emular redes de telecomunicación; ONOS, un controlador \ac{SDN}; \ac{OSM}, un gestor y orquestador \ac{NFV}; y OpenStack, una herramienta para emular una infraestructura IT.
 
 Todas estas herramientas operan en sintonía para llevar a cabo una prueba de concepto exitosa.
 
@@ -109,7 +109,7 @@ \subsection{OpenAPI y Swagger}
 \section{OSM}
 \label{sec:osm}
 
-\ac{OSM}\cite{osmbib} es un software \textit{open-source} cuya función principal es la orquestación de servicios de red avanzados en infraestructuras \ac{NFV} heterogéneas. Surge como iniciativa del \ac{ETSI} para crear una arquitectura \ac{NFV} común para los operadores de red.
+\ac{OSM}\cite{osmbib} es un software \textit{open-source} cuya función principal es la orquestación de servicios de red avanzados en infraestructuras \ac{NFV} heterogéneas. Surge como iniciativa del \ac{ETSI}\cite{etsibib} para crear una arquitectura \ac{NFV} común para los operadores de red.
 
 \ac{OSM} trabaja con una serie de componentes/elementos que ayudan a definir su arquitectura:
 
@@ -178,14 +178,18 @@ \section{OpenStack}
 
 OpenStack\cite{openstackbib} es un proyecto basado en la nube que proporciona un \textit{datacenter} para controlar y gestionar grandes cantidades de recursos de computación, almacenamiento y red. Para facilitar la gestión de recursos, OpenStack provee al usuario una interfaz gráfica a la vez que también exporta una \ac{REST}-\ac{API} para permitir conectividad con aplicaciones externas.
 
+OpenStack está compuesto de diferentes servicios o bloques, encargándose cada uno de ellos de una funcionalidad concreta dentro de la arquitectura global. La principl característica de dichos servicios es que cada uno de ellos es accesible de forma indepdendiente.
+
+\clearpage
+
 \begin{figure}[!ht]
 	\centering
-	\includegraphics[width=0.9\linewidth]{imagenes/openstack_arch}
+	\includegraphics[width=1.1\linewidth]{imagenes/openstack_arch}
 	\caption{Arquitectura de OpenStack. Fuente:\cite{openstackbib}}
 	\label{fig:openstackarch}
 \end{figure}
 
-Está compuesto de diferentes servicios o bloques, encargándose cada uno de ellos de una funcionalidad concreta dentro de la arquitectura, como se puede apreciar en la figura \ref{fig:openstackarch}. La principal característica de estos servicios es que son accesibles de forma independiente. Los servicios principales de OpenStack son los siguientes:
+En la figura \ref{fig:openstackarch} se puede apreciar la arquitectura de OpenStack en la que operan los diferentes servicios. Dichos servicios se explican a continuación:
 
 \begin{itemize}
 	\item \textbf{Keystone:}  Este servicio controla la identificación de los diferentes usuarios que se conecten a la infraestructura de OpenStack, y el acceso a según que aplicaciones de los mismos.
@@ -194,13 +198,13 @@ \section{OpenStack}
 
 	\item \textbf{Nova:} Este servicio está considerado el motor de OpenStack. Es el encargado de desplegar y administrar las diferentes máquinas virtuales instanciadas y otros servicios que se necesiten.
 
-	\item \textbf{Neutron:} Este servicio es el encargado de que cada componente desplegado en OpenStack se comunique con los demas y estén interrelacionados.
+	\item \textbf{Neutron:} Este servicio es el encargado de proporcionar servicios de red entre los diferentes dispositivos. Permite crear y gestionar redes y subredes.
 
 	\item \textbf{Glance:} Este servicio se encarga de gestionar las diferentes imágenes que se usan en la infraestructura.
 
 	\item \textbf{Cinder:} Este servicio se centra en el almacenamiento. Facilita el acceso al contenido alojado en las unidades de disco que se encuentren en la infraestructura.
 
-	\item \textbf{Swift:} Este servicio es el encargado de almacenar los diferentes archivos del sistema, asegurar su integridad y replicarlos por los diferentes discos de la infraestructura, para hacer más dinámicas la accesibilidad y la disponibilidad.
+	\item \textbf{Swift:} Este servicio es el encargado de almacenar los diferentes archivos del sistema, asegurar su integridad y replicarlos por los diferentes volúmenes de la infraestructura, para hacer más dinámicas la accesibilidad y la disponibilidad.
 \end{itemize}
 
 \subsection{OpenStack4Java}