Universidade de Aveiro

Transcrição

1 Universidade de Aveiro Departamento de Electrónica e Telecomunicações Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia Projecto Realizado por: Nuno Rafael Gomes da Silva, aluno nº e, Paulo Renato Tavares da Silva, aluno nº Orientadores: Professora Susana Sargento, Departamento de Electrónica e de Telecomunicações da Universidade de Aveiro; Professor Rui Pedro de Magalhães Claro Prior, Faculdade de Engenharia da Universidade do Porto.

2 Índice 1 - Introdução Objectivos do projecto Alguns conceitos O que é a Qualidade de Serviço QoS? O que é o DiffServ? O que é o IntServ? O Protocolo RSVP Mensagens RSVP Estilos de reserva Modelo de reserva Controlo de tráfego Escalonamento dos pacotes Controlo de admissão Classificador de pacotes A Arquitectura Scalable Reservation-Based QoS - SRBQ Classes de Serviço Reserva de recursos Label switching Expiração de reservas (Soft-states) O protocolo de sinalização Mensagens de sinalização Funcionamento do protocolo de sinalização Funcionamento do Deamon Funcionamento inicial e processador de pacotes Funcionamento do módulo de comunicação com a API Funcionamento da função manipuladora do SIGALRM Funcionamento dos blocos principais Instalação do signal de controlo do SIGALRM Receber pacote Criar reserva Criar reserva temporal Confirmar reserva Programar próxima reserva Label válido? IP destino pertence a esta máquina? Os Problemas Encontrados e as Soluções Propostas Acesso a zonas de memória não alocadas Método de expiração de reservas (implementação dos soft-states ) Envio de pacotes SResvRefresh Endereço de origem e identificação da reserva no router seguinte e anterior Comportamento hop by hop Sincronização dos relógios dos computadores Modificações feitas no pc para agir como um router Erros possíveis de acontecer na rede e a sua solução Recursos insuficientes no interface de rede...55 Página 2/113

3 Recursos insuficientes na alocação de memória Recursos insuficientes de processamento Mudanças de rota na rede Biblioteca de comunicação com o deamon (API) Modo de utilização da API Testes realizados Teste ao funcionamento do protocolo de sinalização Resultados obtidos Modelo de controlo de tráfego Protocolo de sinalização Soluções inacabadas Conclusões Modelo de controlo de tráfego Protocolo de sinalização Bibliografia Agradecimentos Anexos...77 Página 3/113

4 Índice de figuras Figura 1: Funcionamento do protocolo RSVP...10 Figura 2: Troca de mensagens RSVP...14 Figura 3: Exemplo de utilização da arquitectura RSVP...19 Figura 4: Modelo de controlo de tráfego...21 Figura 5: Modelo de controlo de tráfego com múltiplas classes AF...22 Figura 6: Formato do pacote SResvInit para um fluxo GS...29 Figura 7: Formato do pacote SResvInit para um fluxo AF...30 Figura 8: Formato do pacote SResvRefresh...31 Figura 9: Formato do pacote SResvStat...32 Figura 10: Formato do pacote SResvTear...33 Figura 11: Funcionamento normal do protocolo de sinalização SRBQ...35 Figura 12: Funcionamento do protocolo de sinalização SRBQ num caso de existência de erro...37 Figura 13: Fluxograma do funcionamento do Deamon...42 Figura 14: Fluxograma do funcionamento do módulo de comunicação com a API...44 Figura 15: Fluxograma do funcionamento da função manipuladora do SIGALRM...46 Figura 16: Configuração para modelo de teste do controlo de tráfego...61 Figura 17: Configuração do modelo de teste do protocolo...62 Índice de tabelas Tabela 1: Valores para os tipos de mensagens usados...34 Tabela 2: Valores para a classe e tipo dos objectos usados...34 Tabela 3: Resultados obtido com modelo de controlo de tráfego vs sem modelo de controlo de tráfego 1º teste...64 Tabela 4: Resultados obtido com modelo de controlo de tráfego vs sem modelo de controlo de tráfego 2º teste...66 Tabela 5: Resultados obtido com modelo de controlo de tráfego vs sem modelo de controlo de tráfego 3º teste...67 Tabela 6: Resultados obtido com modelo de controlo de tráfego vs sem modelo de controlo de tráfego 4º teste...69 Tabela 7: Resultados obtido com modelo de controlo de tráfego vs sem modelo de controlo de tráfego 5º teste...70 Tabela 8: Resultados obtidos para o desempenho do protocolo de sinalização em função do processamento...71 Página 4/113

5 1 - Introdução Na Internet actual, os recursos disponíveis são distribuídos por todos os utilizadores dum modo igual, segundo um modelo de melhor esforço (Best-effort). No entanto, face ao aparecimento de novos serviços e aplicações, os requisitos da Internet actual estão a mudar. Com efeito, as exigências das aplicações, dependendo de muitos factores, implicam que, cada fluxo de informação deva ser tratado com relação ao fim a qual se destina. Para tentar resolver este problema, o IETF (The Internet Engeneering Task Force) propôs duas arquitecturas: os servidos integrados (IntServ) e os serviços diferenciados (DiffServ). No modelo IntServ as reservas são criadas individualmente para cada fluxo através do protocolo Resource Reservation Protocol (RSVP) e propondo, para além do serviço de melhor esforço, duas classes de serviços: o Serviço Garantido, para fluxos que necessitam de limites fixos de atraso e, o Serviço de Carga Controlada, para fluxos que necessitam de um limite probabilístico de atraso. Por sua vez, no modelo DiffServ não existe qualquer reserva de recursos, uma vez que neste modelo os fluxos são agregados de acordo com as suas características. Para distinguir os diferentes tipos de fluxos é usado o campo DiffServ Code Point (DSCP) do cabeçalho Internet Protocol (IP) e a cada campo corresponde um tratamento diferente de encaminhamento, o qual se chama Per Hop Behaviour (PHB). Como é evidente, cada um destes modelos apresenta vantagens e inconvenientes, quer a nível de escalabilidade quer a nível da eficiência, pelo que foram propostos vários modelos, não garantindo, porém, nenhum a simultaneidade entre um QoS estrito e diferenciado e a maximização do uso dos recurso da rede sem problemas de escalabilidade. A arquitectura que propomos permite um QoS ponto a ponto, com base na reserva de recursos para fluxos agregados, quer em redes de trânsito (core), quer em redes de acesso. Este modelo é essencialmente baseado na arquitectura DiffServ, em que os fluxos Página 5/113

6 são agregados por classe de serviço, com base no campo DSCP do cabeçalho IP. O policiamento é feito nos routers de acesso (edge), conseguindo-se, assim, obter conformidade com os recursos agregados. Neste modelo a sinalização é efectuada previamente antes de se iniciar o fluxo de dados, de modo a melhorar a utilização dos recursos disponíveis. As reservas são unidireccionais, iniciadas pelo emissor e utiliza o conceito de soft-states, que permite uma eficiente gestão e controlo das expirações das reservas. O protocolo de sinalização é baseado em RSVP, pois assim podemos obter uma maior funcionalidade para o modelo. Com vista à diminuição do esforço computacional dos routers e aumento da própria escalabilidade do protocolo de sinalização, implementou-se um sistema de identificação de reservas por etiqueta (label). Nestas, cada label representa a posição de memória em que os dados relativos à própria reserva estão guardados em cada router ao longo do caminho, o que torna forçoso implementar um mecanismo de troca de labels. Todavia, através da oportunidade oferecida por este mecanismo (aceder ao dados da reserva directamente), é possível obter um aumento da escalabilidade do protocolo e, concomitantemente, uma diminuição do peso computacional no processamento de mensagens. Do mesmo modo, e com idêntico objectivo, foram usadas reservas soft. Neste caso cada reserva detém um tempo associado, através do qual ela será terminada, caso não seja refrescada. Este método, além de ser independente do número de reservas existentes em cada router, pode ser implementados com baixa complexidade computacional. Em suma, o modelo implementado garante QoS ponto a ponto com escalabilidade. Página 6/113

7 2 - Objectivos do projecto O presente projecto pretende desenvolver um protótipo laboratorial de uma arquitectura de QoS no sistema operativo Linux. Os blocos constituintes dos elementos de rede são compostos pelos seguintes módulos: Um módulo responsável pela implementação do escalonamento dos pacotes; Vários módulos de policiamento; Vários módulos de formatação do tráfego; Um módulo responsável pela implementação do protocolo de sinalização entre os elementos da rede. A implementação da arquitectura ora proposta permitirá a configuração de uma plataforma laboratorial de teste a ser usada para a validação e a avaliação do desempenho da arquitectura. As actividades a realizar no âmbito do projecto situam-se maioritariamente nas áreas da programação em C e das redes de telecomunicações. Página 7/113

8 3 - Alguns conceitos No âmbito deste projecto existe a necessidade da compreensão de alguns conceitos, por isso, temos de compreender o que pretendemos com o conceito de QoS e compreender a diferença entre o modelo de serviços diferenciados e o modelo de serviços integrados já que esta arquitectura aproveita as vantagens de cada uma delas O que é a Qualidade de Serviço QoS? A Qualidade de Serviço (QoS) consiste na capacidade de uma rede de telecomunicações controlar a sua largura de banda, controlar o jitter e tempos de latência (para o caso de tráfego em tempo real e interactivo) e melhorar as capacidades de perdas de pacotes, ou reduzir ao máximo este problema. Deve, ainda, ser capaz de priorizar certos fluxos evitando ao máximo a perda de informação noutros fluxos com menos prioridade. Duma maneira geral, a QoS permite melhorar o serviço para certos fluxos de informação, através do aumento da prioridade de fluxos mais importantes e limitando outros com menos prioridade. Em caso de congestionamento é possível aumentar a prioridade dos fluxos mais importantes (caso dos fluxos tempo-real e interactivos), pelo que se perdem pacotes de fluxos com menos prioridade, evitando-se, deste modo, a perda de pacotes nos fluxos importantes O que é o DiffServ? Os Serviços diferenciados (DiffServ) traduz uma arquitectura que permite trabalhar com diferentes tipos ou níveis de serviço para o tráfego da rede, tendo surgido a fim de possibilitar um melhor e máximo aproveitamento da largura de banda disponível numa rede IP. Página 8/113

9 Esta arquitectura consiste no uso do byte ToS (Type of Service) de cada pacote IP para marcar a prioridade ou nível de serviço que cada pacote necessita, com a vantagem de não afectar fluxos encriptados, já que o byte ToS de cada pacote não é encriptado O que é o IntServ? O IntServ (Serviços integrados) é um modelo que permite o tráfego de fluxos numa rede através de níveis de serviço. Permite que sejam criadas reservas para cada fluxo, reservas estas que podem ser quer a nível de largura de banda como outras características (tamanho dos pacotes máximo, taxas máximas, etc.). A desvantagem do IntServ é que os fluxos necessitam de ser reservados explicitamente e refrescadas posteriormente. Este processo adciona tráfego à rede o que pode causar problemas de escalabilidade. Página 9/113

10 4 - O Protocolo RSVP O protocolo Reservation Protocol (RSVP) foi desenvolvido para permitir que as aplicações possam requisitar diferentes QoS para os seus fluxos de dados. Esta potencialidade exige que estejam presentes dois requisitos: os elementos de rede (tais como routers, que devem adequar-se aos mecanismos de controlo da qualidade de serviço para garantir a entrega dos pacotes de dados) e a aplicação, que deve ser capaz de fornecer os parâmetro ideais de QoS. O protocolo RSVP é usado a partir duma aplicação, permitindo que esta possa requisitar qualidade de serviço específica da rede. Além disso, possibilita que a qualidade de serviço actue tanto em computadores de trabalho como em routers, cabendo ao protocolo estabelecer e manter as condições para o serviço requisitado. Figura 1: Funcionamento do protocolo RSVP Como podemos ver através da figura 1, o protocolo RSVP negoceia a reserva de recursos num único sentido de cada vez, ou seja, de forma simplex. Este protocolo não realiza o transporte de dados. Ele consiste simplesmente num protocolo de controlo, estando ao mesmo nível de outros protocolos, tais como o ICMP (Internet Control Página 10/113

11 Message Protocol), o IGMP (Internet Group Menagement Protocol) ou protocolos de roteamento. Ao receptor cabe a responsabilidade de requisitar uma qualidade de serviço específica, seguidamente reiniciada em intervalos de tempos específicos. Existem vários conceitos associados a este protocolo: Sessão O protocolo RSVP define como sessão todo o processo de troca de mensagens de sinalização e de dados, através do qual se relacionam as camadas de transporte de todos os participantes da comunicação, podendo esta ser unicast ou multicast. Cada sessão é tratada independentemente e pode ser considerada como um conceito genérico, dado que uma sessão pode ser estabelecida baseando-se em valores de QoS diferentes dos requisitados pelo receptor inicialmente. Tal facto deve-se à liberdade que o gestor possui em unir recursos ao longo do caminho de dados da aplicação, sendo que objectivo principal traduz-se no aproveitamento máximo dos recursos disponíveis. Ao efectuar esta política, os valores dos parâmetros de QoS requisitados poderão sofrer alterações, desde que estas não impliquem a perda de qualidade para uma comunicação já estabelecida. Soft-state O protocolo RSVP é baseado na noção de soft-state, como sendo o estado que um determinado elemento, pertencente ao percurso de dados de um determinado par fontedestino, se encontra quando uma reserva está estabelecida. O soft-state dá-se quando uma mensagem de reserva é recebida e realizada no elemento; este estado é periodicamente realimentado pelos receptores. Ao invés de entregar à rede a responsabilidade em detectar e responder a falhas, o RSVP delega aos receptores o trabalho de reenviar periodicamente as requisições do Página 11/113

12 serviço que esta a usar. Caso ocorra alguma falha, somente uma nova requisição do serviço irá restabelecer o soft-state nos routers Mensagens RSVP Uma série de mensagens devem ser trocadas entre as aplicações e os elementos da rede para requisitar correctamente a qualidade de serviço para uma determinada sessão. Após a definição da sessão, serão trocadas mensagens de controlo RSVP. As mensagens RSVP fundamentais são RESV e PATH. Cada uma deverá explicitamente requisitar o QoS através de objectos descritores do tráfego e filtros. Dependendo do serviço de QoS, esses objectos possuirão alterações a fim de comportar os diversos parâmetros de interesse. A mensagem PATH, enviada pelo transmissor, é propagada pelo caminho unicast ou multicast, seguindo a rota informada pelos mecanismos de encaminhamento até aos receptores. Um elemento no caminho de dados, ao receber uma mensagem PATH, criará um estado designado por PATH State. As mensagens deste tipo armazenam o estado de cada nó por onde ela transitou. A mensagem RESV, enviada pelo receptor, contém um descritor de fluxo, definindo o QoS aceite pelo receptor em função da pedida pela mensagem PATH. Mediante a troca destas mensagens, o protocolo toma uma série de decisões, como por exemplo, aceitar ou não o novo fluxo de dados, criando um ambiente para que os recursos sejam reservados. Cada parâmetro utilizado para requisitar o QoS está representado nas mensagens do RSVP. Através da análise dos parâmetros contidos nos objectos RSVP, algumas simplificações podem ser feitas, de forma a agrupar fluxos distintos de uma mesma Página 12/113

13 sessão que possuam características comuns. Tal tarefa, apesar da complexidade, proporciona, quando possível, uma economia de recursos utilizados, principalmente em termos de largura de banda. Para que isto possa ocorrer, é essencial a utilização dos estilos de reserva Estilos de reserva Uma série de mensagens devem ser trocadas entre as aplicações e os elementos da rede para requisitar correctamente a qualidade de serviço para uma determinada sessão. Após a definição da sessão, serão trocadas mensagens de controlo RSVP. As mensagens RSVP fundamentais são RESV e PATH. Cada uma deverá explicitamente requisitar o QoS através de objectos descritores do tráfego e filtros. Dependendo do serviço de QoS, esses objectos possuirão alterações a fim de comportar os diversos parâmetros de interesse. A mensagem PATH, enviada pelo transmissor, é propagada pelo caminho unicast ou multicast, seguindo a rota informada pelos mecanismos de encaminhamento até aos receptores. Um elemento no caminho de dados, ao receber uma mensagem PATH, criará um estado designado por PATH State. As mensagens deste tipo armazenam o estado de cada nó por onde ela transitou. A mensagem RESV, enviada pelo receptor, contém um descritor de fluxo, definindo o QoS aceite pelo receptor em função da pedida pela mensagem PATH. Mediante a troca destas mensagens, o protocolo toma uma série de decisões, como por exemplo, aceitar ou não o novo fluxo de dados, criando um ambiente para que os recursos sejam reservados. Cada parâmetro utilizado para requisitar o QoS está representado nas mensagens do RSVP. Página 13/113

14 Através da análise dos parâmetros contidos nos objectos RSVP, algumas simplificações podem ser feitas, de forma a agrupar fluxos distintos de uma mesma sessão que possuam características comuns. Tal tarefa, apesar da complexidade, proporciona, quando possível, uma economia de recursos utilizados, principalmente em termos de largura de banda. Para que isto possa ocorrer, é essencial a utilização dos estilos de reserva Modelo de reserva Considerando um cenário simples, ponto-a-ponto, em que todos os elementos compreendem o protocolo RSVP. Em cada nó, além do gerenciador de recursos, responsável pela reserva, existem módulos de controlo de tráfego e policiamento que auxiliam o RSVP na tarefa de reservar os recursos pretendidos. Consierando a figura 2 como o modelo de exemplo, T1 é uma máquina que contém uma aplicação com necessidades de QoS; R1, uma outra máquina, irá receber os dados dessa aplicação e G nós intermédios. A aplicação em T1, para iniciar a sua transmissão, envia uma mensagem de controlo, cujo nome é PATH. Esta seguirá o seu caminho, pelos diversos nós até chegar a R1. A mensagem PATH contém um cabeçalho RSVP e todas as informações sobre o tráfego que a aplicação em T1 espera gerar. Em cada nó G existente entre T1 e R1 e que pertença ao caminho da reserva, será criado um estado chamado de PATH State. Figura 2: Troca de mensagens RSVP Página 14/113

15 Ao chegar a R1, este analisa as informações contidas na mensagem PATH e selecciona os parâmetros de reserva desejados, criando desta forma uma outra mensagem de reserva, RESV. Esta será enviada no sentido contrário ao da mensagem PATH, e provocará a transição do estado dos nós intermédios G de PATH State para o estado SOFT State, e informa ao mesmo tempo todos os nós das condições dos parâmetros de QoS da reserva realizada por R1 e propriedades do caminho entre ambos Controlo de tráfego Além das propriedades específicas que os protocolos de encaminhamento devem fornecer para a realização da reserva na rede, outras funções devem ser utilizadas para que exista o QoS que as aplicações pretendem. O RSVP actua em conjunto com outros módulos, ditos de controlo de tráfego: escalonador de pacotes, classificador de pacotes e controlo de admissão. Estes actuam não só nos elementos finais (emissores e receptores) como também em todos os nós ao longo da Path Escalonamento dos pacotes A função básica do escalonamento traduz-se em implementar uma política para servir os pacotes na fila de saída. O esquema mais utilizado é o FIFO ( First-In First-Out). Nele, os pacotes são servidos estritamente na ordem de chegada. Entre os muitos esquemas propostos, talvez o mais simples seja um esquema de prioridades, onde o pacote que tenha maior prioridade seja servido em primeiro lugar. Um problema inerente a esta solução consiste em que na presença de pacotes de alta prioridade, aqueles que não possuem nenhum tipo de privilégio, pelo que podem ser bastante atrasados, ou até mesmo, provocar atraso indefinido. Página 15/113

16 É possível criar o esquema de Weigth Fair Queueing (WFQ) que tenta obter uma maior justiça no escalonamento através da atribuição de pesos aos diversos fluxos de saída. Outro mecanismo de escalonamento que se poderá criar é o Class Based Queue ( CBQ). Neste caso, os pacotes dos diversos fluxos são enquadrados em diversas classes, organizadas de forma a criar um esquema de prioridades entre os fluxos de dados da saída Controlo de admissão O controlo de admissão implementa um algoritmo de decisão que um router ou uma máquina utiliza com o fim de determinar se um novo fluxo de dados poderá ser ou não aceite. A decisão deverá ser tomada de forma a não comprometer os fluxos previamente aceites pela máquina ou nó. O controlo de admissão é evocado em cada ponto para fazer uma decisão simples: aceitar ou rejeitar, no momento que a requisição do fluxo chega a esse ponto Classificador de pacotes Em qualquer rede de dados, que se baseia em circuitos virtuais, o QoS do fluxo é conhecida no momento do estabelecimento da sessão. Todos os pacotes subsequentes deste fluxo serão identificados pelo número do circuito virtual, o que torna mais fácil a classificação dos pacotes. Outro método consiste em permitir ao módulo classificador identificar mais campos da área do cabeçalho dos pacotes, tais como o endereço da fonte, porta e número do protocolo. Uma determinada sequência de vídeo, por exemplo, poderia ser reconhecida por uma porta particular. Aprofundando tal busca, poderíamos obter um método onde Página 16/113

17 seria possível permitir a investigação mais rigorosa dos pacotes, talvez até à área de dados, a fim de identificar alguma característica da aplicação. Página 17/113

18 5 - A Arquitectura Scalable Reservation-Based QoS - SRBQ A arquitectura Scalable Reservation-Based QoS (S.R.B.Q.), assegura a qualidade de serviço (QoS) numa rede IPv4, através da pré-reserva de fluxos, com a finalidade de garantir atraso controlado, perdas mínimas e ao mesmo tempo máxima eficiência e escalabilidade. Neste modelo, baseado no modelo DiffServ (DS), é usado, de igual modo, o campo DiffServ code point (DSCP) para efectuar a classificação dos fluxos, os quais serão agregados e policiados se necessário, ou seja, de acordo com a classe de serviço. Esta agregação de fluxos permite criar os seguintes tipos de fluxos principais: Serviço Garantido (GS), que é uma classe que se baseia num forte QoS para que exista sempre garantia de entrega do pacote no destino e um atraso mínimo; Envio Assegurado (AF), ou Assured Forwarding que simula o comportamento de redes best-effort não muito saturadas; Sinalização (SIG), para que os pacotes de sinalização tenham garantia de entrega, para o correcto funcionamento do modelo; Melhor Esforço (BE), ou Best-effort, para o qual todos os outros pacotes são encaminhados. As reservas são unidireccionais, iniciadas pelo emissor e incluem o conceito de softstate. Esta aproximação permite uma maior simplicidade do protocolo de sinalização, e uma maior facilidade de implementação. Existem quatro tipos de pacotes no protocolo de sinalização: SResvInit, para criar uma reserva; SResvRefresh, para renovar a reserva; SResvStat para transmitir mensagens de erro ou de sucesso; SResvTear, para terminar uma reserva. Concomitantemente, a troca de mensagens de sinalização é hop-by-hop, ou seja, os pacotes de sinalização são sempre enviados para o router seguinte, criando um caminho Página 18/113

19 virtual por onde os pacotes pertencentes ao fluxo têm de passar, mesmo em routers core. Rede de transito C E C E Receptor Rede de acesso Emissor Rede de acesso E A A E C C C C Figura 3: Exemplo de utilização da arquitectura RSVP Ao longo deste caminho é efectuado controlo de admissão para cada fluxo individual. No entanto, através dum mecanismo de troca de labels, que representam cada reserva, em cada router, directamente no endereço físico de memória, possibilita-se existir escalabilidade, para além de se simplificar ao máximo o protocolo de sinalização e diminuir-se ao máximo o esforço computacional dos routers. Ou seja, cada router necessita de saber o seu endereço físico, onde tem a informação relativa à reserva, e o endereço físico onde o router anterior e o router seguinte têm as reservas correspondentes. Nestas posições de memória é guardada toda a informação relativa à própria reserva, onde se inclui também os endereços IP do router anterior e do router seguinte. Isto permite uma maior rapidez no acesso à informação relativa à reserva, pois o acesso é directo, ao inverso de ser necessário efectuar uma procura para descobrir onde se Página 19/113

20 encontra a reserva. Para além deste processo de troca de labels, o esforço computacional é diminuindo através do conceito de soft-timer, o qual é de baixa complexidade, mas com funcionalidade suficiente para um bom funcionamento da arquitectura. Podemos considerar vários tipos de redes importantes para esta arquitectura: redes de acesso (edge) e redes de trânsito (core). Um exemplo bastante simples pode ser encontrado na figura Classes de Serviço Além do serviço de melhor esforço (Best effort), este modelo está dotado de outras duas classes de serviço: - Serviço garantido (Guarenteed Service - GS), que permite a obtenção de QoS estrito em termos de garantia de entrega e atraso mínimo; - Envio garantido (Assured forwarding - AF), que simula o comportamento de redes com o serviço de melhor esforço, ligeiramente saturadas. As reservas para a classe GS são caracterizadas por um token bucket, no qual se define um tamanho e uma taxa de envio dos pacotes. As reservas para a classe AF são caracterizadas por três marcas: os pacotes que excedam as duas primeiras marcas recebem um aumento da probabilidade de perdas. Caso ultrapassem a terceira marca, é, então, perdido. Este modelo assenta na arquitectura de serviços diferenciados (DiffServ) para definir a classe de serviço no DSCP (DiffServ Code Point). A arquitectura em estudo baseia-se igualmente nesta estratégia, tendo um comportamento para os fluxos GS com os mesmos princípios que os fluxos EF (Expedicted Forwarding) no DiffServ: baixo atraso e uma garantia de entrega máxima. A classe AF tem como objectivo garantir um serviço melhor do que o serviço de melhor esforço (Best Effort) através do uso de marcas (cuja função é definir a probabilidade de perdas num fluxo AF através da sua largura de banda de ocupação). Todas estas marcas são definidas previamente através do protocolo de sinalização. Página 20/113

21 Neste caso, o modelo de filas (queuing model), figura 4, baseia-se em prioridades. Através deste conceito é possível atribuir máxima prioridade a fluxos de serviço garantido, logrando, desse modo, melhorar o comportamento de fluxos altamente sensíveis ao atraso, fluxo de serviço garantido. A disciplina de serviço desta classe é assenta num token bucket, que não é mais do que um FIFO (First-In First-Out), de tamanho e taxa de envio de pacotes definidos pelo protocolo de sinalização. O segundo nível de prioridade é associado à fila de pacotes de sinalização, para se garanta o correcto funcionamento da arquitectura. Por sua vez, a disciplina de serviço baseia-se igualmente num token bucket. Os fluxos de AF têm a prioridade seguinte: baseia-se num modelo mais complexo, pois possui 3 filas virtuais, uma para cada parâmetro do fluxo. A disciplina de serviço interna baseia-se num GRED (Generalized Random Early Detection). Finalmente, no que concerne à disciplina de melhor esforço (Best Effort), esta que simula o comportamento normal das redes actuais. O modelo agora em análise é caracterizado por deter a prioridade mais baixa de todo o modelo de filas e pela disciplina conseguida através dum simples FIFO. Note-se que tanto esta fila, como a fila de sinalização não estão de todo sujeitas a controlo de admissão. O escalonador principal alicerça-se num PRIO (Priority Qdisc) onde, a cada pacote recebido, é atribuída uma classe de serviço através do DSCP. Para obter o DSCP e se proceder à sua classificação é usado a disciplina de serviço DSMARK. Figura 4: Modelo de controlo de tráfego Página 21/113

22 No entanto, pode-se considerar um modelo um pouco mais completo, em que a classe AF é decomposta em várias classes AF, como representado na figura 5, através da disiplina DWRR (Deficit Weighted Round Robin). Figura 5: Modelo de controlo de tráfego com múltiplas classes AF Reserva de recursos O controlo de admissão é feito em todos os nós ao longo do caminho definido para o fluxo, dependendo o algoritmo do tipo de fluxo em questão. Para um fluxo GS temos de efectuar controlo de admissão, pois é imperativo garantir que existe largura de banda suficiente e espaço no buffer de cada router. Por outro lado, num fluxo AF, é premente efectuar controlo de admissão, mas dum modo mais leve, pois a admissão é feita através de policiamento que define quando um determinado fluxo deve sofrer um aumento da sua probabilidade de perdas e qual a taxa de perdas. Os fluxos GS baseiam-se num token bucket cujos parâmetros dependem dos fluxos existentes. Cada router faz a soma de todos os fluxos GS existentes, criando assim a partilha da mesma classe de serviço para todos os fluxos GS. Podemos dizer que r sum = ri e b sum = bi, em que r i e b i são respectivamente, a taxa do token bucket e i i o tamanho do mesmo para cada fluxo. Neste momento, é necessário verificar se o valor de rsum é compatível com a largura de banda disponível no interface em questão, pois se este valor não satisfizer a condição rsum Bmin bsum + MTU, onde R 0 é a largura de R 0 Página 22/113