Catégorisation des modes de transport

A inicialização do sistema (system bootstrapping) é realizada pelo Topology Controller após o completo carregamento dos demais componentes que compõem o sistema SDWiNeMO. Este procedimento consiste em descobrir os nós da rede adjacentes ao controlador SDWiNeMO de modo a sobre-aprovisionar recursos. Isto implica em configurar mecanismos embarcados nos nós para refletir as quantias de recursos pretendidas para auxiliar o Admission Controller em relação à acomodação de múltiplos fluxos com QoS garantido sem a necessidade de eventos de sinalização adicionais.

A Figura 5.1 apresenta um diagrama de sinalização com as principais operações e eventos relacionados ao processo de inicialização no sistema SDWiNeMO. Quando um nó de rede do sistema SDWiNeMO (switch ou PoA habilitados com OpenFlow) é conectado à rede, uma men- sagem OpenFlow OFPT_HELLO [OPENFLOW SWITCH, 2015] é enviada ao controlador SDWi-

NeMO a fim de estabelecer uma conexão e negociar a versão do protocolo OpenFlow a ser utilizado (passos 1.1 e 1.2 da Figura 5.1). Após isso, o Topology Controller faz uso de men- sagens OpenFlow FeatureReq [OPENFLOW SWITCH, 2015] para obter as informações sobre os

recursos e capacidades de cada nó da rede adjacente ao sistema SDWiNeMO (passos 1.3 e 1.4 da Figura 5.1), enviando mensagens OFPT_FEATURES_REQUEST ao longo de cada caminho que conecta os nós conhecidos na rede. Consequentemente, cada nó alcançado pela mensa- gem OFPT_FEATURES_REQUEST irá responder ao controlador SDWiNeMO através de uma

mensagem OFPT_FEATURES_REPLY, informando seus recursos e capacidades (e.g. DPID, lista de interfaces, configurações de fila etc.). Após este procedimento, o Topology Controller utiliza o Link Layer Discovery Protocol (LLDP) [OPENLLDP, 2015] para obter informações adi- cionais dos nós da rede, tais como endereço MAC/IP e tipo do dispositivo (e.g. switch, roteador ou PoA), de modo que seja capaz de construir uma estrutura lógica que represente a topologia física da rede disponível, armazenando esta informação em uma tabela de estados.

Figura 5.1: Diagrama de sinalização da inicialização do sistema SDWiNeMO

Durante a inicialização do sistema o Topology Controller configura sobre-reservas em todos os nós da rede no sentido de compor caminhos de dados concorrentes com QoS garantido. As informações dos caminhos de dados são armazenadas em uma tabela de estados e disponibiliza- das antecipadamente para processamento, o que permite decisões de encaminhamento de forma ágil e sem sinalização adicional. Para tal, o Topology Controller faz uso do conhecimento da to- pologia física da rede e calcula todas possibilidades de caminhos unicast de cada nó de entrada para todos os PoAs presentes no sistema. Em [NETO; MONTEIRO; CURADO; MENDES, 2008] é

apresentada uma descrição detalhada deste procedimento.

De toda a lista processada são descartados todos os caminhos que não respeitam (ou corres- pondam) aos critérios pré-definidos (e.g. sentido downstream do nó de entrada ao nó de saída, topologias sem loops e número máximo de nós no caminho), sendo os demais armazenados na tabela de estados. Como exemplo da explicação anterior, considera-se uma rede com apenas um nó de entrada A, que é conectado a um nó central B, que por sua vez conecta três nós de saída: C, D e E. Os caminhos unicast resultantes neste cenário são: [01: A-B-C], [02: A-B-D] e [03:

A-B-E].

Em seguida, o Topology Controller calcula os padrões de sobre-reserva iniciais para aplicar em cada uma das classes de serviço disponíveis (uma fila para cada classe, sendo no máximo 8 filas permitidas pelo OpenFlow) dos nós adjacentes, levando em consideração as capacidades de cada interface, limites máximo/mínimo de sobre-reserva por classe e índice inicial de sobre- reserva (e.g. 1/2, 1/3, 1/4 da capacidade máxima de reserva por classe). Mais detalhes sobre a forma de realização dos cálculos de sobre-reserva, limites e reajustes, podem ser encontrados em [NETO; CERQUEIRA; CURADO; MONTEIRO; MENDES, 2007].

As sobre-reservas por classe de serviço são aplicadas através da configuração de parâme- tros de filas (i.e. tipo e limites), viabilizados pelo padrão OpenFlow através do utilitário DPCTL [CPQD, 2015]. Para esse fim, o esquema de sinalização OpenFlow FlowMod [MCKEOWN et al., 2008] foi estendido para permitir ao Topology Controller a aplicação das funcionalidades descri- tas em todos os nós de rede selecionados para compor o melhor caminho de dados. Basicamente, o Topology Controller compõe uma mensagem OFPT_FLOW_MOD (passo 2.1 da Figura 5.1) contendo ambos, a modificação da tabela de fluxos (adicionando, removendo ou modificando uma determinada entrada de fluxos) e os novos padrões de sobre-reserva por classe (criando ou modificando os limites máximos para uma lista de filas pertencentes a uma interface), e envia para todos os nós pertencentes ao caminho de dados afetado. Consequentemente, cada um dos nós que receber a instrução contida na mensagem OFPT_FLOW_MOD realizará as modifica- ções requisitadas, modificando as configurações dos caminhos de dados relacionados.

Em adição ao serviço de entrega unicast, o Topology Controller também habilita o sistema SDWiNeMO para comunicações multiparte, pelo qual um mesmo fluxo é entregue para múlti- plos MOs sem a necessidade de duplicação de pacotes na rede, com exceção de nós especiais (branching nodes), como no multicast, para otimização da largura de banda. O Topology Con- trolleraplica as garantias de QoS (i.e. alocação de sobre-reservas) nos caminhos relacionados as comunicações multiparte através da funcionalidade OpenFlow GroupMod [OPENFLOW SWITCH,

2015] (etapa 3.1 da Figura 5.1), pelo qual os nós recebem mensagens OFPT_GROUP_MOD e são instruídos a modificar (adicionar ou remover) suas tabelas de grupos. Essencialmente, uma entrada na tabela de grupos faz um fluxo de entrada ser replicado em várias interfaces (ao passo que no unicast apenas uma é considerada), serviço este conhecido como agregação, no nó de entrada, e desagregação, no nó de saída.

Neste ponto a operação de inicialização do sistema é concluída, resultando na disponibiliza- ção de informações de QoS sobre toda a topologia do sistema SDWiNeMO de forma antecipada. Desta forma, o controlador SDWiNeMO permite o gerenciamento de conectividade de múlti-

plos fluxos de sessões em tempo real, sem a necessidade de consultas excessivas e propagação de sinalização adicional na rede.

Em casos de modificações na topologia, o Topology Controller é acionado através de novas mensagens OpenFlow OFPT_HELLO [OPENFLOW SWITCH, 2015], o que causa a ativação do

mecanismo de inicialização e descoberta de topologia. A partir disso, novos caminhos de dados são identificados (através das informações obtidas pelo protocolo LLDP) e as devidas configu- rações das tabelas de fluxos (com padrões iniciais de sobre-reservas) são realizadas para compor a nova estrutura.