Merge branch 'master' into scramble-pishahang

doc/Adaptor/ScalabilityResearch/MANO Scalability document/MANO Scalability document/MANOScalability.tex → doc/MANO Scalability Document/MANOScalability.tex

@@ -66,4 +66,4 @@
 	% the appendices of your thesis go into file appendix.tex
 	%%%%%%%%%
 
-	\end{document}
+\end{document}

doc/Adaptor/ScalabilityResearch/MANO Scalability document/MANO Scalability document/body.tex → doc/MANO Scalability Document/body.tex

@@ -15,5 +15,10 @@
 \input{chapters/ScalingNetworkService}
 \input{CapacityofNFVOsandVNFMs}
 
+\input{chapters/scrambleArchitecture}
+\input{chapters/adaptorArchitecture}
+\input{chapters/splitterArchitecture}
+\input{chapters/TranslatorArchitecture}
+
 \input{chapters/conclusion}
 

doc/MANO Scalability Document/chapters/HierarchicalOrchestration.tex

@@ -0,0 +1,32 @@
+\chapter{Hierarchical orchestration}
+\label{ch:Hierarchical Orchestration}
+
+\paragraph{} The orchestration of a network service in a MANO is one of the responsibilities of NFVO. The VNFM along with NFVO are responsible for managing the VNF instances and its lifecyle. To achieve end-to-end provisioning, a single MANO platform is not feasible in most of the cases. 
+A multi-domain NFVI that allows interaction of multiple administrative domains at different levels is required.
+To satisfy the requirements of a multi-domain, multi-vendor, multi-technology interoperability environments, the orchestration of network services can be done in a hierarchical fashion or in a peer-to-peer fashion. \cite{munoz2018hierarchical}
+
+\paragraph{} In a peer-to-peer orchestrating model, the MANOs are interconnected to each other in an arbitrary fashion to provide end-to-end network services. This model is preferred when
+there is no cross-domain control or cross-domain visibility is required, thus limiting the scaling
+possibilities of a MANO. \cite{munoz2018hierarchical}
+
+
+\paragraph{}In a hierarchical orchestrating model, one of the MANO acts as a global orchestrator to the
+underlying MANO with a parent/child hierarchy. This architecture uses a common API between
+the parent MANO and child MANOs, hence maintaining a good overview of the global system. Each hierarchical level deals with a minimum of one orchestrator. The orchestrator at any given level is managed by the higher level orchestrator. Some of the factors influencing hierarchical orchestration are the geographical spread and placement of MANOs across regions, scalability constraints of peer-to-peer architectures, different administrative requirements from the operators with different layers of abstraction. This architecture is preferred because of its broader scope of network services from the lower MANOs and also for better abstraction. The number of levels of hierarchy in this type of orchestration is based on the geographical region and network domain. The hierarchical levels are also based on abstraction required for the provisioning of network services \cite{munoz2018hierarchical}.
+
+
+\paragraph{}The overall orchestration of the hierarchical model is split based on its geographical domains known as execution zones (EZ). The splitting of EZ further is based on the geographical area the domain covers. The grouping of few data centers which are geographically close for one execution zone. The number of data centers in a region is proportional to the number of execution zones required for the region. Supposedly, here, the whole world is split into 11 execution zones based on their geographical regions like, Western Europe (EUW), Eastern Europe (EUE), Central Asia (ASC), Southern Asia (ASS), Pacific Asia (ASP), Africa (AFR), Northern North America (NAN), Southern North America (NAS), Eastern South America (SAE), Western South America (SAW) and Oceania (OCE). Considering one of the regions, like Western Europe (EUW), it is further split into lower levels based on the resolution domains (RD). The lower levels can further be split based on the granularity of orchestration required\cite{maini2016hierarchical}.
+
+\paragraph{}Each RDs constitutes number of EZs located at a specific location for users. Here, as an example, the first level(level 0)  split is based on 3 resolution domains, RD1, RD2, RD3. With a limited visibility of EZs for the high level orchestrator makes a placement decision. The RDs are divided based on local-local requests of a EZ, remote-local requests of EZ, and local-remote requests of EZ. The next level of split is influenced by the scalable property of orchestrators in first level split \cite{maini2016hierarchical}.
+
+\begin{figure}
+	\centering
+	\includegraphics[width=0.7\linewidth]{figures/HO}
+	\caption{An example of the placement decision made by the high-level orchestrator \cite{maini2016hierarchical}}
+	\label{fig:ho}
+\end{figure}
+
+Thus, the above investigation of MANO scalability can infer the conclusions about optimal number of MANOs in such a system and also the optimal number of hierarchical levels. Considering the above example, the MANOs are initially placed in 3 RDs and that forms the first level of hierarchy. The number of MANOs and the level of hierarchy can increase further depending on the user requests in that location. When there is a demand for more number of MANOs to complete the service requests. The existing MANOs are designed to scale more MANOs using service replication/service migration techniques in a hierarchical fashion. 
+
+\paragraph{}In the further chapters, we discuss about the SCrAMbLE plug-in architecture. This plug-in could be installed in SONATA/OSM MANO to make use of the services that is developed by Translator, Splitter and Adaptor. For the ease of plug-in development, we choose the top most MANO to be a SONATA(phishahang) MANO. Considering the same example of EUW region, 3 of the SONATA MANOs could be placed in 3 different RDs intially. These MANOs depending on the service requests will call OSM MANOs using the Adaptor services. When there is a situation when all the 3 MANOs reach a threshold where in they can not serve any more requests, additional MANOs are installed with a load balancer to further scale MANO using service replication techniques. The scaled(child) MANOs are also installed with SCrAMbLE plug-in and the same services can be made use to serve more requests. 
+The scaling of any MANOs is handled by a component called scalability manager. This could be a part of MANO. We do not discuss the implementation details of the scalability manager at this point as it is still a work in progress.

doc/Adaptor/ScalabilityResearch/MANO Scalability document/MANO Scalability document/chapters/Introduction.tex → doc/MANO Scalability Document/chapters/Introduction.tex

@@ -40,7 +40,7 @@ \section{Metrics to assess a scalable system}
 \end{itemize}
 
 
-\paragraph{Lifecycle Management \& service provisioning:} To provision a network service, the NFVO of a MANO's functionality include instantiation, global resource management scaling in/out , event correlation and termination of services. These functionalities form the lifecycle of NS. With the increase in instantiation of NS over a distributed network, the lifecycle management of each service is a overhead, hence increasing the provision time. This can be better handled when the MANO can be scaled out. To manage services with a closer proximity of geographical region, MANOs could be scaled in. The provision time , also reducing provision time.
+\paragraph{Lifecycle Management \& service provisioning:} To provision a network service, the NFVO of a MANO's functionality include instantiation, global resource management scaling in/out , event correlation and termination of services. These functionalities form the lifecycle of NS. With the increase in instantiation of NS over a distributed network, the lifecycle management of each service is a overhead, hence increasing the provision time. This can be better handled when the MANO can be scaled out. To manage services with a closer proximity of geographical region, MANOs could be scaled in.
 
 
 

doc/MANO Scalability Document/chapters/TranslatorArchitecture.tex

@@ -0,0 +1,19 @@
+\chapter{Scramble translator architecture}
+\label{ch:Scramble wrapper architecture}
+
+\paragraph{}
+In a hierarchical architecture involving different MANOs, there is a need of conversion of network descriptors to schemas of respective MANO. Service Descriptor Translator (SDT) serves the purpose of translating network descriptors, namely NSDs and VNFDs from schema of SONATA Pishahang to that of OSM and vice versa.
+\paragraph{}
+In a scenario, where a parent MANO, say Pishahang decides to deploy one of the network services in its lower hierarchy MANO, say OSM, the NSD and VNFD(s) need to be converted to the descriptor schema of OSM. In such an event, the Scramble plugin calls the translator service and sends the descriptors to the SDT, where the translation of the descriptors takes place and the translated descriptors are sent to Adaptor utility for deployment in appropriate MANO. Figure \ref{fig:service-descriptor-translator} gives a high level view of Translator.
+\paragraph{}
+Scramble plug-in installed within the parent MANO forwards the network descriptors with service request to Scramble Main-Engine. Main-Engine checks the service request and sends the network descriptors to Translator along with the information of destination schema. On receiving the network descriptors, SDT translates the same to requested schema and calls the validator function to validate the translated network descriptors. Once validation is complete, the translated descriptors will be sent to Adaptor for deployment. 
+
+
+
+
+\begin{figure}
+	\centering
+	\includegraphics[width=1\linewidth]{"figures/Service Descriptor Translator"}
+	\caption{}
+	\label{fig:service-descriptor-translator}
+\end{figure}

doc/MANO Scalability Document/chapters/adaptorArchitecture.tex

@@ -0,0 +1,97 @@
+\chapter{Python MANO Wrappers (Adaptor)}
+\label{ch:PMW}
+
+Python MANO Wrappers (PMW) is a uniform python wrapper library for various implementations of NFV Management and Network Orchestration (MANO) REST APIs. PMW is intended to ease the communication between python and MANO by providing a unified, convenient and standards oriented access to MANO API.
+
+To achieve this, PMW follows the conventions from the ETSI GS NFV-SOL 005 (SOL005) RESTful protocols specification. This makes it easy to follow and the developers can use similar processes when communicating with a variety of MANO implementations.\\
+
+PMW is easy to use and well documented. Code usage examples are available along with the detailed documentation at the following link \url{https://python-mano-wrappers.readthedocs.io/en/adaptor/}. \\
+
+PMW in scramble helps in inter communication of different instances of MANO, thereby creating opportunity for more advanced feature set, for example, hierarchical scaling. Operations such as on-boarding of NSD and VNFD, instantiation and termination of NS can be performed with ease.
+
+
+\section{Architecture}
+
+Standards based approach is a fundamental design principle behind PMW's design. A Common interface template is defined in compliance with SOL005 which contains the blueprint for all the methods mentioned in the standards. These methods are divided into different sections as per SOL005 into the following:
+
+\begin{itemize}
+	\item \textbf{auth: }Authorization API
+	\item \textbf{nsd: }NSD Management API
+	\item \textbf{nsfm: }NS Fault Management API
+	\item \textbf{nslcm: }Lifecycle Management API
+	\item \textbf{nspm: }NS Performance Management API
+	\item \textbf{vnfpkgm: }VNF Package Management API
+\end{itemize} 
+
+In the figure \ref{fig:wrapperarch}, different sections of PMW are visualized. As part of the scramble project, support for Open Source MANO (OSM) and Sonata is developed. This is represented by the dotted lines to OSM and Sonata modules. These modules are based on the common interface and implement the methods it has defined.  
+
+\section{Usage}
+
+\subsection{Installation}
+
+PMW can be installed using pip:\\
+
+
+\texttt{pip install python-mano-wrappers} 
+
+\subsection{Basic examples}
+
+\begin{lstlisting}[language=python,caption=Fetching Auth token]
+import wrappers
+
+username = "admin"
+password = "admin"
+mano = "osm"
+# mano = "sonata"
+host = "vm-hadik3r-05.cs.uni-paderborn.de"
+
+if mano == "osm":
+	_client = wrappers.OSMClient.Auth(host)
+elif mano == "sonata":
+	_client = wrappers.SONATAClient.Auth(host)
+
+response = _client.auth(username=username, password=password)
+
+print(response)
+\end{lstlisting}
+
+\begin{lstlisting}[language=python,caption=Instantiating a NS in OSM]
+from wrappers import OSMClient
+
+USERNAME = "admin"
+PASSWORD = "admin"
+HOST_URL = "vm-hadik3r-05.cs.uni-paderborn.de"
+
+osm_nsd = OSMClient.Nsd(HOST_URL)
+osm_nslcm = OSMClient.Nslcm(HOST_URL) 
+osm_auth = OSMClient.Auth(HOST_URL)
+
+_token = json.loads(osm_auth.auth(username=USERNAME, password=PASSWORD))
+_token = json.loads(_token["data"])
+
+_nsd_list = json.loads(osm_nsd.get_ns_descriptors(token=_token["id"]))
+_nsd_list = json.loads(_nsd_list["data"])
+_nsd = None
+
+for _n in _nsd_list:
+	if "test_osm_cirros_2vnf_nsd" == _n['id']:            
+		_nsd = _n['_id']
+
+response = json.loads(osm_nslcm.post_ns_instances_nsinstanceid_instantiate(
+								token=_token["id"],
+								nsDescription=NSDESCRIPTION, 
+								nsName=NSNAME, 
+								nsdId=_nsd, 
+								vimAccountId=VIMACCOUNTID))
+
+response = json.loads(response["data"])
+
+print(response)
+\end{lstlisting}
+
+\begin{figure}
+	\centering
+	\includegraphics[width=1\linewidth]{figures/WrapperArch}
+	\caption{}
+	\label{fig:wrapperarch}
+\end{figure}

doc/Adaptor/ScalabilityResearch/MANO Scalability document/MANO Scalability document/chapters/conclusion.tex → doc/MANO Scalability Document/chapters/conclusion.tex

@@ -1,7 +1,7 @@
 \chapter{Conclusion}
 \label{ch:Conclusion}
 
-\paragraph{}The main goal of this paper is to aggregate the factors affecting the scalability of a MANO. Scalability is an important factor in cloud environments which accommodates the demanding needs and also not affecting the system’s performance. The report further states the system load in terms of the load on the NFVO of a MANO. The scaling in a distributed MANO system is affected by the availability of a service and its reliable quotient. The report further describes the effect of diverse administrative domains of a MANO framework and how it can be addressed by a coherence mean. Scalability approaches from various research papers are discussed.
+\paragraph{}The main goal of this paper is to aggregate the factors affecting the scalability of a MANO. Scalability is an important factor in cloud environments which accommodates the demanding needs and also not affecting the system’s performance. The report further states the system load in terms of the load on the NFVO of a MANO. The scaling in a distributed MANO system is affected by the availability of a service and its reliable quotient. The report further describes the effect of diverse administrative domains of a MANO framework and how it can be addressed by a coherence mean. Scalability approaches from various research papers are discussed. This paper also discusses the architecture design of Translator, Splitter and Adaptor.
 
 
 \paragraph{} The report further addresses the effects involved to scale a MANO, also briefing about scaling a network service. The further steps involved in the research is narrowing down to one of the scaling approaches to scale a MANO.

doc/MANO Scalability Document/chapters/scrambleArchitecture.tex

@@ -0,0 +1,29 @@
+\chapter{Scramble architecture}
+\label{ch:Scramble architecture}
+
+Scramble is a tool to realize scalability with hierarchical orchestration. While the higher level orchestrator (Parent MANO) still controls the life-cycle of the deployed network services, scramble acts as a bridge between parent MANO and lower level orchestrator (child MANO) thus allowing interconnection between different MANO's to provide end-to-end service.  
+
+\section{Architecture}
+\paragraph{}
+The services of scramble resides as a plugin within MANO frameworks such as SOTANA/Pishahang and Open Source MANO (OSM) and enables cross MANO communication. Service requests received by the higher level MANOs in the hierarchy can be routed to lower level MANOs using scramble plugin based on monitoring parameters.
+
+
+\paragraph{}
+Each child MANO's in-turn contains scramble plugin which allows multiple other MANO's to be added as a child hence achieving hierarchical orchestration (See Figure \ref{fig:scramblearch}).
+
+\paragraph{}
+
+Scramble is composed of three main services.
+\begin{itemize}
+	\item Translator
+	\item Splitter
+	\item Wrapper(adaptor)
+	\end{itemize} 
+Each of these services are further explained in-detail in Chapters \ref{ch:Scramble wrapper architecture}, \ref{ch:Scramble splitter architecture}, \ref{ch:PMW}.
+
+\begin{figure} [h]
+	\centering
+	\includegraphics[width=1\linewidth]{figures/scramblearch}
+	\caption{Scramble Architecture}
+	\label{fig:scramblearch}
+\end{figure}