O Controlador de Banda

Ana Paula Silva dos Santos <anapaula@na-rc.rnp.br>

Rede Nacional de Ensino e Pesquisa (RNP)

Intrdução
Desvendando o controlador de banda
Admissão local de um controlador de banda
Gerenciamento de recursos entre domínios
Exemplo de operação de BB
O controlador de banda e RSVP
Conclusão
Referências bibliográficas
Sites relacionados

A Internet 2 é uma nova geração da maior rede de computadores do mundo. Um de seus princípios básicos é oferecer condições para que seus usuários possam ter serviços com mais qualidade

Neste artigo, abordaremos um assunto que está tendo uma atenção especial do órgão regulamentador da Qualidade de Serviços para Internet 2, o Qbone. Trata-se do Controlador de Banda ou Bandwidth Broker (BB) . Um componente dentro da arquitetura de serviços diferenciados (DiffServ) que surgiu com a necessidade de ter maior controle dos recursos disponíveis dentro de domínios que oferecem qualidade de serviços (QoS).

A idéia do Controlador de Banda ainda é bastante recente, e as poucas implementações existentes, ainda estão em fase de desenvolvimento, teste e aprimoramento. No entanto, os trabalhos a respeito do BB caminham com o firme propósito de padronizar este componente e lançá-lo como um potente mediador em domínios DiffServ.

Intrdução

Os roteadores da Internet atual estão providos para prestar uma classe de serviço para todos os usuários. Esta classe de serviço é denominada de "melhor esforço".

A necessidade de definir classes de serviços variadas, ou seja, diferenciar aplicações de forma que se pudesse definir quantidades de recursos para cada uma, desenvolveu várias tecnologias para implementação qualidade de serviço (QoS) na Internet. Serviços diferenciados (DiffServ) é uma dessas formas.

Na arquitetura DiffServ, as aplicações são distribuídas de acordo com os tipos de serviços e requisitos de recursos, como quantidade de banda, atraso, variação do atraso (denominada jitter) e latência que é tempo que leva o pacote para trafegar da fonte ao destino.

A possibilidade de se ter diferentes tipos de serviços é efetivada com a introdução de roteadores capazes de implementar diferenciação de pacotes. Estes roteadores permitem ao operador configurar uma variedade de comportamentos de repasse de pacotes de acordo com a definição de classes. Este comportamento de repasse é conhecido como PHB (Per Hop Behavior). Cada pacote de uma determinada classe de serviço é tratada de acordo com seu PHB dentro dos roteadores.

O Bandwidth Broker (BB) ou Controlador de Banda é um agente responsável por reservar os recursos para os tipos de serviços solicitados pelos usuários e configurar os roteadores da rede com o PHB correto.

Nas próximas seções, o BB é descrito com mais detalhes, com uma abordagem dos dois escopos em que o BB deve operar: intra-domínio e inter-domínio. Em seguida, o funcionamento do controlador de banda é mostrado através de um exemplo e, por fim, há uma pequena exposição de como pode ser utilizado o RSVP para ajudar a alocação de recursos pelo BB em domínios DiffServ.

Desvendando o controlador de banda

Um BB é um gerente de recursos que controla o tráfego baseado em políticas de uso específicas do domínio. As políticas dizem quais usuários podem usar o quanto e/ou quais recursos do seu domínio. Por isso, o gerenciamento dos recursos deve ser consistente e imediato para que, no momento em que uma aplicação iniciar, sejam providos qualidade e bom desempenho.

O BB deve ter conhecimento de recursos da rede, como a quantidade de recursos que pode ser alocada para fluxos QoS. Deve, ainda, ter uma regra para a alocação de recursos disponíveis, como, por exemplo, o primeiro que chegar será o primeiro que será atendido; ou alocar de acordo com regras de prioridades para serviços e usuários, podendo remover alocações em uso, dependendo das especificações das prioridades.

O Qbone sugere que cada BB seja capaz de executar as seguintes funções básicas:

Um meio pelo qual uma aplicação ou roteador possa notificar uma requisição de banda;Responder para a aplicação ou roteador depois de ter configurado os roteadores para uma requisição de QoS;Rejeitar o excesso de solicitações de banda;Reconfigurar roteadores;Manipular aplicações que finalizam o uso de uma faixa de banda e torná-la disponível.

A tecnologia DiffServ supõe que o BB possa gerenciar e controlar os recursos de seu domínio e realizar a comunicação com os BBs dos domínios adjacentes para controle e gerência entre eles.

Admissão local de um controlador de banda

Quando um BB recebe uma mensagem de gerenciamento de recursos do domínio, ele poderá:

Determinar se os recursos no roteador de entrada estão apropriadamente alocados para o fluxo de tráfego do transmissor;Calcular o ponto de saída baseado no domínio destino;Determinar se os recursos no roteador de saída estão apropriadamente alocados para o fluxo de tráfego especificado na mensagem;Se desejável, ou necessário, executar gerenciamento dentro do domínio.

Pode existir mais de um BB atuando em um mesmo domínio. No entanto, apenas um dentre eles pode ser responsável pela comunicação com os BBs de domínios adjacentes e o responsável pela configuração dos roteadores de borda para que entre e saia do domínio a quantidade de tráfego desejada para cada classe.

Internamente, o BB se comunica com os usuários ou BBs de suas sub-redes. A comunicação entre eles é basicamente para receber requisições e processá-las, sinalizar os recursos solicitados para o BB do domínio adjacente apropriado e indicar o resultado da alocação de recursos para o solicitante. Com os roteadores, os BBs precisam estabelecer comunicação para efeitos de configuração e gerenciamento.

A interação entre BBs do mesmo domínio pode ser diferente de entre BBs de domínios vizinhos. Dependendo da função de cada um do mesmo domínio, como, por exemplo, BBs backups, um protocolo de troca de mensagens diferente pode ser utilizado. No entanto, a comunicação entre BBs, ou entre este e qualquer outro componente da rede local, deve acontecer através de um canal seguro.

Gerenciamento de recursos entre domínios

Conforme já dito, o BB gerencia recursos entre dois domínios através de troca de mensagens com os BBs de domínios adjacentes. Ele se comunica com os BBs vizinhos através de um protocolo equivalente ao BGP. E deve ter rotas preestabelecidas quando tratar de aplicações QoS para evitar retardo na prestação dos serviços. Para isso, é necessário determinar rotas estáticas em cada BB, o que pode ser um retrocesso do ponto de vista evolutivo do roteamento da Internet atual.

Para comunicação entre domínios DiffServ, é necessário estabelecer os limites de recursos disponibilizados para os domínios adjacentes. Estes limites são determinados em forma de acordos entre os administradores dos mesmos. Estes acordos de utilização de recursos são denominados de Acordo em Nível de Serviço – Service Level Aggreement (SLA). Um SLA mantém-se válido por um bom período de tempo para evitar mudanças na configuração dos roteadores com muita freqüência. Os roteadores precisam ser configurados para policiar, formar e marcar pacotes de dados apropriadamente, de acordo com os SLAs.

Quando há uma requisição para um domínio diferente do BB que a recebe, todos os BBs ao longo do caminho precisam ser consultados para que o serviço seja liberado.

Existem duas propostas de sinalização entre os BBs para alocação de recursos. A sinalização fim-a-fim, a sinalização com resposta imediata ou, ainda, pode ser utilizada uma combinação das duas.

Na comunicação fim-a-fim (Figura 1a) os BB são consultados um a um ao longo do caminho antes que o usuário que solicitou os recursos ser informado do resultado. BB1 consulta BB2 que consulta BB3. BB3 responde para BB2 que responde para BB1. Se houver alguma "falha" no caminho uma resposta de erro é retornada do BB que "falhou" não sendo consultados os BBs subseqüentes.

Já na resposta imediata (Figura 1b), o BB1 consulta BB2 que responde imediatamente ao BB1 e depois é que sinaliza para o BB3. Enquanto isso, BB1 informa ao usuário que BB2 aceitou a requisição, passando o usuário a transmitir os dados, antes mesmo, que o BB3 retorne.

Estes modelos de sinalização, servem para se definir modelos de implementação para tipos de aplicações. Se para a aplicação só interessa se for garantida a comunicação, o modelo de resposta imediata não servirá. A sinalização fim-a-fim é mais confiável. No entanto, sinalização imediata permite o início de envio de dados, antecipando a comunicação.

Caso seja necessário, é possível a utilização das duas possibilidades, entretanto, é sugerido o uso de um flag, determinando qual tipo de sinalização está sendo utilizada.

Assim como na comunicação entre BBs dentro de um domínio, a segurança entre os pares de BBs é uma premissa que deve ser levada em consideração, pois os BBs estão tratando do que há de mais precioso na rede: a largura de banda.

Figura 1: Sinalização entre BBs

Exemplo de operação de BB

Nesta seção, será utilizado um exemplo como forma de mostrar uma operação básica de um controlador de banda.

Neste exemplo, foi adotada a sinalização fim-a-fim e considerado que o roteamento de pacotes é feito de forma estática, mesmo porque ainda não se chegou a avaliar como seria possível a utilização de alocação de recursos através de BB com roteamento dinâmico. É considerado, também, que cada domínio tem apenas um controlador de banda.

Supondo que os núcleos da RNP estejam conectados de acordo com a figura abaixo (Figura 2) e que um usuário do Núcleo de Apoio de Brasília (NA-DF) queira fazer uma videoconferência com outro usuário que está no Núcleo de Coordenação do Rio de Janeiro (NC-RJ).

Figura 2: Conexão entre Domínios

Cada controlador de banda possui uma tabela de políticas estabelecidas através dos SLAs que é é consultada a cada solicitação de QoS para o BB por parte dos BBs vizinhos ou de usuários do seu domínio. As tabelas podem ser da seguinte forma:

Parceiro	Regra	Total de Banda	Total em Uso
POP-MG	<50 ok	100	0
NA-DF	Ask	100	20

Caso esta tabela esteja no BB-POP-DF, qualquer solicitação para o POP-MG que exija menos de 50 Kbps é aceita sem a prévia necessidade de consulta ao BB-POP-MG. Enquanto, solicitações para NA-DF precisam sempre de uma consulta ao BB-NA-DF.

Para que "F" possa estabelecer a comunicação com "D", ele deve, inicialmente, solicitar os recursos desejados ao BB de seu domínio, passando para ele os parâmetros que são necessários para configuração dos roteadores, como usuário fonte e usuário destino, a quantidade banda e a aplicação será utilizada para que o BB possa determinar a classe da mesma. O BB-NA-DF verifica se o usuário que está solicitando o serviço tem autorização para realizar a comunicação e se há disponibilidade dos recursos requisitados. Caso esteja tudo de acordo com as políticas de utilização de recursos do domínio, o BB passa a solicitação para o BB-POP-DF que consulta a sua tabela de políticas inter-domínios e repassa para o próximo BB, de acordo com a regras de roteamento, a mesma requisição. Esta seqüência é feita até que se alcance o BB do domínio destino que, no exemplo, é o BB-NC-RJ. O BB-NC-RJ verifica as condições para o estabelecimento do serviço e, em caso positivo, configura o seu roteador de borda com os parâmetros recebidos e retorna ao BB-PoP-RJ a mensagem de aprovação do serviço. E, assim, esta mensagem é repassada até o usuário fonte "F".

Se em algum BB do caminho a requisição for recusada, imediatamente a resposta é retornada no sentido contrário passando por cada BB solicitante. O BB do domínio de onde partiu a requisição pode, inclusive, dar dicas de quando o banda pode ser liberada.

Estes passos devem ser realizados no sentido contrário, caso haja necessidade de interação entre os usuários. Ou seja, a comunicação é estabelecida de forma unidirecional

Tabela 1: Tabela de Políticas Inter-domínio

O controlador de banda e RSVP

Em redes finais pode ser utilizado o RSVP (Resource Reservation Protocol) ou a estrutura de DiffServ para fornecer QoS para usuários. O BB pode usar o RSVP para priorizar aplicações em casos de congestionamento.

No cabeçalho de um pacote IP, existe um campo chamado ToS (Type of Service) que com serviços diferenciados, passou a ser chamado de DS Field (Differentiated Service Field). No DS Field são codificadas as classes para serviços diferenciados.

O RSVP e DiffServ podem ser combinados para permitir que os pacotes sejam classificados na entrada do domínio, ou melhor, nos roteadores de borda, de acordo com o PHB representado pela marcação no DS Field e, a partir daí, fazer as reservas de recursos necessárias para o fluxo.

Porém, apesar de RSVP ser uma boa idéia para redes finais, implementá-lo em redes de trânsito não é uma opção viável por questões de escalabilidade. O grande volume de troca de mensagens de sinalização necessárias com o RSVP pode causar uma degradação da rede.

Conclusão

O Controlador de Banda foi incluído na arquitetura DiffServ como forma de prover um controle maior dos recursos de rede de um domínio.

Seu papel inicial era apenas particionar a banda, ou seja, controlar a banda disponível para que cada classe de serviço pudesse usar o que lhe fosse determinado. Com a evolução das redes DiffServ, ficou mais evidente a necessidade que o BB pudesse realizar, também, a gerencia de políticas para os recursos dentro do domínio e entre os mesmos.

Atualmente, o Controlador de Banda é um forte candidato a ser transformado no mediador de redes que implementem QoS, o que não se restringe somente a DiffServ.

Referências bibliográficas

"Internet QoS: A Big Picture" Xiao, X., & Ni, M. N., IEEE Network, March/April 1999

"Quality of Service in the Internet: Fact, Fiction, or Compromise?"P. Ferguson, G. Huston, INET'98, Julho 1998

"A Two-bit Differenciated Services Architecture for the Internet"K. Nichols, V. Jacobson, L. Zhang, , IETF , December 1997.

"A Two-Tier Resource Management Model for Differentiated Services Networks" Reichmeyer, F., et al., Internet Draft draft-rotzy-2-tier-management-00.txt, November, 1998.

Sites relacionados

Internet 2: http://www.internet2.edu/

Internet 2 QBone Bandwidth Broker Advisory Council: http://www.internet2.edu/qos/qbone/QBBAC.shtml