| Summary: | Submitted by Milena Rubi (milenarubi@ufscar.br) on 2017-10-09T14:35:22Z
No. of bitstreams: 1
FRATE_Marcelo-2017.pdf: 8466810 bytes, checksum: 9438c26c84ebe90cd741672c8c04d726 (MD5) === Approved for entry into archive by Milena Rubi (milenarubi@ufscar.br) on 2017-10-09T14:35:33Z (GMT) No. of bitstreams: 1
FRATE_Marcelo-2017.pdf: 8466810 bytes, checksum: 9438c26c84ebe90cd741672c8c04d726 (MD5) === Approved for entry into archive by Milena Rubi (milenarubi@ufscar.br) on 2017-10-09T14:35:45Z (GMT) No. of bitstreams: 1
FRATE_Marcelo-2017.pdf: 8466810 bytes, checksum: 9438c26c84ebe90cd741672c8c04d726 (MD5) === Made available in DSpace on 2017-10-09T14:35:53Z (GMT). No. of bitstreams: 1
FRATE_Marcelo-2017.pdf: 8466810 bytes, checksum: 9438c26c84ebe90cd741672c8c04d726 (MD5)
Previous issue date: 2017-02-23 === Não recebi financiamento === Since the emergence of the Software-Defined Networking (SDN), and, more precisely, since the development of an open interface in 2008 called OpenFlow protocol, it is being observed that this new networking paradigm is deeply remodeling the IP-protocol- based networks. It means that new mechanisms of provision services are being possible, which ensures scalability and reduces costs. Although this new paradigm has been created to centralize the control logic, there is the possibility of decentralizing it through the parceling of control tasks between two or more controllers. In this scenario, the subdivision of administrative domain in smaller subdomains in order to have each of them being controlled by one single controller has been an alternative to ensure scalability in SDN. The OpenFlow protocol allows communication among switches and controllers to another controller. However, the protocol does not define how this communication between one controller to other should be done. It is mandatory, therefore, the development of protocol independent solutions able to distribute this logic inside the same administrative domain. New proposals have been arisen, but their applications either use equal controllers or demand the development of new controllers specifically designed. This master’s research aims to offer the fundamentals to the development of an architecture here so called Orch Flow, able to receive application demands and organize them in a way it provides requested services through an OpenFlow network designed with two or more different implementation controllers. The OrchFlow architecture that is being proposed accomplishes its task through handling multiple OpenFlow controllers hierarchically and providing network access through three distinct modes: Proactive, Reactive and Hybrid. === Desde o surgimento das Redes Definidas por Software e mais especificamente à partir de 2008 com o desenvolvimento de uma interface aberta, o protocolo OpenFlow, é possível observar que este novo paradigma de redes está revolucionando as redes baseadas no protocolo IP, possibilitando a criação de novos mecanismos de aprovisionamento de serviços, garantindo a escalabilidade e reduzindo custos. Embora este novo paradigma tenha sido criado para a centralização da lógica de controle, existe a possibilidade de descentralizá-la através da divisão das tarefas de controle entre dois ou mais controladores. Neste cenário, subdividir o domínio administrativo em subdomínios menores e fazer com que cada subdomínio seja controlado por um controlador tem sido uma alternativa para garantir escalabilidade em Software-Defined Networking (SDN). O protocolo OpenFlow permite a comunicação entre switches e controladores, entretanto ele não define como deve ser feita a comunicação de um controlador para outro controlador. Faz-se necessário, portanto, o desenvolvimento de soluções independentes do protocolo, capazes de distribuir essa lógica dentro de um mesmo domínio administrativo. Neste cenário, novas propostas vão surgindo, porém as aplicações desenvolvidas ou fazem uso de controladores iguais ou são criados novos controladores especificamente para essa finalidade. Esta pesquisa de mestrado tem como objetivo o desenvolvimento de uma arquitetura, aqui denominada de OrchFlow, capaz de receber solicitações de aplicações, orquestrando as requisições a fim de prover os serviços solicitados numa rede OpenFlow com dois ou mais controladores de implementações diferentes. A arquitetura OrchFlow, desenvolvida para esta pesquisa de mestrado, realiza essa tarefa através da orquestração de múltiplos controladores OpenFlow atuando de forma hierárquica, provendo o acesso à infraestrutura da rede através de três modos distintos: o Proativo, o Reativo e o Híbrido.
|
|---|
