Comparando os dois Modelos

Algumas vantagens do modelo Push são:

• Quando um domínio deseja estabelecer uma conexão, as VTs dos outros domínios já estão disponíveis uma vez que elas foram divulgadas previamente. Não é necessário obtê-las no momento em que a requisição para o estabelecimento é feita;

• O modelo Push é mais voltado para negócios permitindo a divulgação de VTs promocionais de forma rápida em uma tentativa de adquirir clientes;

• O modelo Push é mais dinâmico pois permite divulgar outras VTs caso algum evento local ao domínio ocorra, como por exemplo uma falha.

Algumas desvantagens do modelo Push são:

• É mais futurista. Ele exige que condomínios de ASes sejam estabelecidos de forma a criar um nível de confiança que permita a divulgação das VTs entre todos os membros do condomínio. Isto deveria ser feito de forma incremental num cenário real;

4.1 Como as VTs são Obtidas 49

• Gera mais tráfego na rede, muitas vezes de forma desnecessária. A divulgação das VTs ocorre sem saber se elas serão usadas pelos outros domínios;

• Pode causar problema de escalabilidade num cenário real. Não podemos considerar que todos os ASes estarão agrupados num único condomínio e que as VTs estejam sendo divulgadas entre todos. Para resolver isto, os condomínios poderiam ser definidos de forma incremental e então um modelo hierárquico entre os condomínios poderia ser definido. Algo semelhante ao apresentado em [Li and Mohapatra, 2004]. Nesta tese consideramos apenas um nível hierárquico, ou seja, apenas um condomínio.

Algumas vantagens do modelo Pull são:

• A principal vantagem é a sua simplicidade que permite a aplicação sem restrições a um cenário real. A integração com o BGP não exige nenhuma mudança na forma como o roteamento é feito atualmente. O modelo Pull leva em consideração a forma como a Internet é organizada hoje e por isso poderia ser usado dentro de um curto ou médio prazo;

• Não há problemas de escalabilidade. As VTs são obtidas por demanda considerando apenas algumas rotas BGP. Não há divulgação de VTs entre todos os pares de domínios;

• Não requer a definição de condomínios. Basta apenas a definição da camada de serviços para obtenção de VTs e negociação de contratos.

Algumas desvantagens do modelo Pull são:

• É necessário mais tempo para o estabelecimento de uma conexão uma vez que as VTs não estão disponíveis no momento da requisição. As rotas BGP precisam ser obtidas para então requisitar as VTs para o cálculo do caminho. Uma análise de tempo foi feita para esta tese a fim de verificar as diferenças entre os modelos;

• É menos orientado a negócios. Não há um mecanismo para divulgar as VTs levando-se em conta promoções e o estado atual da rede;

• É menos dinâmico. Um domínio não pode divulgar novas VTs caso algum evento interno ao domínio ocorra. Em casos específicos de falhas, o domínio pode enviar uma mensagem de notificação para os domínios que estejam usando as VTs a fim de que outra VT seja obtida de forma a contornar a falha.

Finalizações do capítulo

Nos próximos dois capítulos, apresentamos a instanciação do modelo discutido no Capítulo 3. No Capítulo 5 a seguir, detalhamos a instanciação do modelo em uma arquitetura para o provisionamento e gerência de serviços dentro de um domínio. A evolução da arquitetura como uma instância do modelo para o provisionamento de serviços entre domínios é apresentada no Capítulo 6.

Capítulo 5

Instanciação do Modelo para

Provisionamento e Gerência de Serviços

dentro de um Domínio

Este capítulo descreve a instanciação do modelo apresentado no capítulo anterior para o provisionamento e gerência de serviços em um domínio. A instanciação do modelo deu origem a uma arquitetura que, através da implementação de um protótipo, permitiu avaliar as funcionalidades definidas para o modelo. Este capítulo é resultado de trabalhos individuais que deram origem a três dissertações de mestrado e um conjunto de artigos. Dividimos este capítulo em duas seções. A primeira (Seção 5.1) apresenta a arquitetura e seus módulos para o provisionamento de serviços dentro de um domínio. Esta seção deu origem à dissertação de mestrado referenciada em [Duarte, 2006] assim como os artigos referenciados em [Verdi et al., 2005b, Verdi et al., 2006a]. A segunda seção (Seção 5.2) apresenta os outros dois trabalhos. Neste sentido, especial atenção foi dedicada para o uso de políticas para agregação de tráfego de redes clientes na rede de transporte. O trabalho desenvolvido com políticas de agregação teve como resultado uma dissertação de mestrado [Carvalho, 2006] e um conjunto de artigos citados em [Verdi et al., 2004, Verdi et al., 2005a, Carvalho et al., 2005, Carvalho et al., 2006]. Finalmente, a arquitetura incorporou funcionalidades para o provisionamento de VPNs em um domínio. O serviço de VPN originou a dissertação de mestrado referenciada em [Malheiros, 2006] e os artigos citados em [Malheiros et al., 2006a, Malheiros et al., 2006b]. Esta segunda seção apresenta um resumo e alguns resultados obtidos nestes dois últimos trabalhos.

5.1

Definição da Arquitetura

A definição da arquitetura para provisionamento e gerência de serviços dentro de um domínio tem como foco principal a definição dos módulos que fazem parte da camada de gerência de redes do modelo TMN. Para esta fase, a camada de serviços possui apenas um serviço denominado End-to-End Connection Service (E2ECS), que oferece acesso às funcionalidades para o provisionamento e gerência de SPCs e VPNs. Os outros módulos da arquitetura instanciam as funções locais do modelo apresentado no capítulo anterior e pertencem ao plano de gerência do modelo ASON [Verdi et al., 2005b]. A Figura 5.1 mostra a arquitetura desenvolvida para esta fase [Verdi et al., 2005b, Duarte, 2006].

OSPF UNI NNI Plano de Controle Rede Óptica dados HTTP SOAP/HTTP MIB PCE RM FM PM AC PIB E2ECS CC/NMI RSVP NEA Plano de Gerência Plano de Transporte Cliente IP ADM MM

Fig. 5.1: Arquitetura para Provisionamento e Gerência de Serviços dentro de um Domínio.

Note que os três planos do modelo (abstrato) ASON apresentados no capítulo anterior são instanciados pela arquitetura definida nesta tese. O plano de gerência é composto pelos módulos que realizam o controle de admissão, a gerência de falhas, a gerência de recursos, a aplicação de políticas, a configuração, a gerência de desempenho e gerência de contabilidade. Cada funcionalidade citada é implementada por um ou mais módulos do plano de gerência. Muitas vezes, algumas funcionalidades também precisam do plano de controle para serem realizadas, como por exemplo, o estabelecimento e remoção de conexões e a gerência de falhas.

O plano de controle, instanciado através dos protocolos da arquitetura GMPLS, é responsável pela sinalização de SPCs, roteamento e interfaceamento com a rede cliente para provisionamento

5.1 Definição da Arquitetura 53

das Switched Connections (SCs). O plano de transporte é instanciado através de uma rede óptica de comunicação. Abaixo, definimos as funcionalidades específicas de cada módulo em seus respectivos planos.