Universidade de Aveiro

(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º 15400 e, Paulo Renato Tavares da Silva, aluno nº 15366.

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)

Arquitectura de Qualidade de Serviço para Suporte de Serviços e Aplicações Multimédia

Página 2/113 Nuno Rafael Silva

Paulo Renato Silva

Índice

1 - Introdução...5

2 - Objectivos do projecto...7

3 - Alguns conceitos...8

3.1 - O que é a Qualidade de Serviço – QoS?...8

3.2 - O que é o DiffServ?...8 3.3 - O que é o IntServ? ...9 4 - O Protocolo RSVP ...10 4.1 - Mensagens RSVP ...12 4.2 - Estilos de reserva...13 4.3 - Modelo de reserva ...14 4.4 - Controlo de tráfego ...15

4.4.1 - Escalonamento dos pacotes ...15

4.4.2 - Controlo de admissão...16

4.4.3 - Classificador de pacotes ...16

5 - A Arquitectura Scalable Reservation-Based QoS - SRBQ ...18

5.1 - Classes de Serviço ...20

5.2 - Reserva de recursos...22

6 - “Label switching” ...25

7 - Expiração de reservas (Soft-states) ...26

8 - O protocolo de sinalização...27

8.1 - Mensagens de sinalização...27

8.2 - Funcionamento do protocolo de sinalização...35

9 – Funcionamento do Deamon ...39

9.1 - Funcionamento inicial e processador de pacotes...39

9.2 - Funcionamento do módulo de comunicação com a API ...43

9.3 - Funcionamento da função manipuladora do SIGALRM...45

9.4 - Funcionamento dos blocos principais...47

9.4.1 - Instalação do signal de controlo do SIGALRM ...47

9.4.2 - Receber pacote ...47

9.4.3 - Criar reserva ...47

9.4.4 - Criar reserva temporal ...48

9.4.5 - Confirmar reserva ...48

9.4.6 - Programar próxima reserva...48

9.4.7 - Label válido? ...49

9.4.8 - IP destino pertence a esta máquina? ...49

10 - Os Problemas Encontrados e as Soluções Propostas...50

10.1 - Acesso a zonas de memória não alocadas ...50

10.2 - Método de expiração de reservas (implementação dos “soft-states”) ...50

10.3 - Envio de pacotes SResvRefresh...51

10.4 - Endereço de origem e identificação da reserva no router seguinte e anterior ...52

10.5 - Comportamento “hop by hop”...53

10.6 - Sincronização dos relógios dos computadores...53

10.7 - Modificações feitas no “pc” para agir como um router ...54

10.8 - Erros possíveis de acontecer na rede e a sua solução ...54

(3)

Paulo Renato Silva

10.8.2 - Recursos insuficientes na alocação de memória ...55

10.8.3 - Recursos insuficientes de processamento ...55

10.8.4 - Mudanças de rota na rede...56

11 - Biblioteca de comunicação com o deamon (API)...58

11.1 - Modo de utilização da API...58

12 - Testes realizados ...61

12.1 – Teste ao funcionamento do protocolo de sinalização ...62

13 - Resultados obtidos...63

13.1 - Modelo de controlo de tráfego ...63

13.1 – Protocolo de sinalização...71

14 – Soluções inacabadas ...72

15 - Conclusões ...73

15.1 -Modelo de controlo de tráfego...73

15.2 - Protocolo de sinalização ...74

15 - Bibliografia...75

16 - Agradecimentos...76

(4)

Paulo Renato Silva

Í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 8: Resultados obtidos para o desempenho do protocolo de sinalização em função do processamento... 71

(5)

Paulo Renato Silva

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.

(6)

Paulo Renato Silva 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.

(7)

Paulo Renato Silva

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.

(8)

Paulo Renato Silva

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.

3.1 - 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.

3.2 - 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.

(9)

Paulo Renato Silva 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.

3.3 - 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.

(10)

Paulo Renato Silva

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

(11)

Paulo Renato Silva 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 fonte-destino, 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

(12)

Paulo Renato Silva 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.

4.1 - 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

(13)

Paulo Renato Silva

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.

4.2 - 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.

(14)

Paulo Renato Silva

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.

4.3 - 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.

(15)

Paulo Renato Silva 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.

4.4 - 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.

4.4.1 - 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.

(16)

Paulo Renato Silva É 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.

4.4.2 - 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.

4.4.3 - 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

(17)

Paulo Renato Silva 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.

(18)

Paulo Renato Silva

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 soft-state. 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

(19)

Paulo Renato Silva virtual por onde os pacotes pertencentes ao fluxo têm de passar, mesmo em routers core.

Emissor Receptor Rede de transito Rede de acesso Rede de acesso A C E E E E C C C A 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

(20)

Paulo Renato Silva 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 3.

5.1 - 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.

(21)

Paulo Renato Silva 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.

(22)

Paulo Renato Silva 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

5.2 - 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 ∑rsum =

∑

_{i i}r e bsum =

∑

_ibi, em que r e i b são respectivamente, a taxa do token bucket e i

o tamanho do mesmo para cada fluxo. Neste momento, é necessário verificar se o valor de r_sumé compatível com a largura de banda disponível no interface em questão, pois se este valor não satisfizer a condição ≥ MTU

R r b B sum sum + × ≥ 0

(23)

Paulo Renato Silva banda do interface, a reserva não pode ser efectuada.

Este método, devido à sua simplicidade, torna-se computacionalmente pouco exigente e garante escalabilidade ao sistema.

Os fluxos AF são caracterizados por três marcas: duas que vão ser usadas para a degradação do serviço e uma outra para definir taxa de perdas. As três marcas representam igualmente a soma das marcas de todos os fluxos AF em cada router. Neste caso, algumas perdas de pacotes são toleráveis e o controlo da admissão não é tão crítico como no caso dos fluxos GS. Contudo, atente-se que é necessário disponibilizar sempre alguma largura de banda para os fluxos de melhor esforço.

5.2.1 - Disciplina de serviço - “Traffic Shaping”

Como supra mencionado, o modelo de classe de serviço implementado, tem a sua maior prioridade para o serviço GS. Neste caso, é usado um token bucket com os parâmetros sendo a soma dos valores individuais de cada fluxo GS (rsum e bsum). Este

facto revela-se de extrema importância, pois neste caso a perdas de pacotes, no policiamento feito no interface de entrada do nó seguinte, não é tolerável.

No entanto, devido ao uso de um token bucket partilhado para todos os fluxos, alguns problemas podem surgir. Esses problemas podem ocorrer quando todos os fluxos GS param de transmitir por algum tempo. Isto provoca o enchimento do bucket de tokens. No entanto, se estiver a ser enviado algum pacote numa outra classe de serviço, tal facto vai fazer com que a classe GS não possa transmitir, apesar da prioridade que possui. Como o bucket já se encontra cheio de tokens, não vai acumular mais. Isto pode-se traduzir numa redução da taxa de serviço para a classe GS, e eventualmente, conduzir à perda de pacotes.

A classe reservada aos pacotes de sinalização, apesar de não necessitar de controlo de admissão, necessita de shaping para resguardar alguma largura de banda para os fluxos do serviço AF. Como esta classe não necessita de policiamento à entrada do router seguinte, a disciplina de serviço pode ser simplificada a uma disciplina cuja taxa seja conservativa, pois, de facto a disciplina usada foi um token bucket. De salientar que

(24)

Paulo Renato Silva nesta classe a existência de perdas, desde que poucas, não é grave.

A disciplina de serviço usada para a classe AF exige que seja empregue uma taxa conservativa para que os fluxos best-effort não sejam muito prejudicados com falta de largura de banda.

5.2.2 - Policiamento

Podemos considerar quatro diferentes tipos de nós nesta arquitectura: os nós finais, os nós de acesso, os nós edge e nós core. Todos tem de compreender a sinalização e respeitar o modelo de disciplina dos serviços.

Os nós de acesso garantem um policiamento por fluxo, garantindo assim que cada fluxo ao longo do caminho não exceda os seus limites.

Os nós edge apenas suportam policiamento dos fluxos agregados por interface, pois, nesta situação, não é necessário que operem o policiamento por fluxo individual, já que os nós de acesso já o fizeram. Além disso, podem, no caso de fluxos AF, remarcar para uma probabilidade de perdas maior. Todavia, é necessário garantir que este processo seja color-aware. Ou seja, temos de garantir que por causa dum fluxo “mal comportado” não se prejudiquem outros.

Por outro lado, os nós core, não necessitam de qualquer tipo de policiamento, pois pressupõe-se que os nós anteriores o fizeram, tornando-se desnecessário.

Ao contrário do shaping que é feito nos interfaces de saída para os fluxos agregados, o policiamento é efectuado no interface de entrada individualmente, fluxo a fluxo. Esta é uma operação forçosa dada a necessidade de garantir que todos os fluxos respeitam os seus parâmetros.

Para evitar que ocorram perdas de pacotes nos fluxos GS, temos de garantir que o bucket do policiamento sofra aumentos equivalentes aos do shaper do interface de saída do router anterior, ou seja, MTU

R r_GS

×

0

max _{, ou duma maneira simplificada}

(25)

Paulo Renato Silva

6 - “Label switching”

Com o intuito de diminuir o esforço computacional e aumentar a escalabilidade do protocolo de sinalização, principalmente nos routers core, este modelo está dotado dum mecanismo de identificação de reservas por labels.

Cada label representa, em cada router, a posição de memória alocada que contem a estrutura de dados com a informação relativa à reserva. Existem 3 campos relativos a este processo em cada estrutura de dados:

O campo “label”, que representa a reserva localmente;

O campo “b_label” que representa a reserva no router anterior (usado em mensagens enviadas para trás)

O campo “f_label” que representa a reserva no router seguinte.

Este processo cria uma ligação da reserva ao longo do caminho, em que o label num nó será o “b_label” no seguinte, e o “f_label” será o “label” no anterior.

Deste modo, podemos, em qualquer altura, obter a identificação da reserva para o nó onde necessitamos de enviar a mensagem.

Este mecanismo pode igualmente servir para detectar alterações da rota da reserva, a diferença entre o campo “RSVP_Hop” e o valor guardado na estrutura de dados relativa à reserva em questão indica que o caminho foi alterado, podendo assim proceder à respectiva alteração da rota.

(26)

Paulo Renato Silva

7 - Expiração de reservas (Soft-states)

O método usado para controlar os tempos de expiração tem com base os Soft reservations, visto que permite a possibilidade de adaptação da rede às constantes mudanças de condições. Para tal torna-se necessário o uso de tempos de expiração, tempo a partir do qual a reserva é eliminada.

Nesta situação usamos um conjunto de 8 filas do tipo First-In First-Out (FIFO), em que cada fila corresponde ao valor de REX, para guardar o tempo em que a reserva irá expirar. Uma vez criada a reserva, é colocada no final da fila correspondente, para garantir que no topo de cada fila temos a próxima reserva a expirar. O processo de programação do alarme para a expiração fica assim simplificado pois apenas tem de verificar o tempo no topo de cada fila.

Este processo implica o periódico envio de mensagens de refrescamento entre os nós pertencentes ao caminho da reserva. Este período de tempo corresponde a ¼ do tempo de expiração. Deste modo, garante-se a não expiração da reserva, designadamente no caso de não recebimento da mensagem de refrescamento ou de perda de pacotes ao longo do percurso. Esta garantia só é viável pois no final de outro ¼ de tempo é enviada uma nova mensagem de refrescamento.

Como quanto menor for o tempo de expiração duma reserva, maior irá ser o número de mensagens de refrescamento necessárias para manter a reserva activa ao longo dos vários nós, torna-se importante o uso dum valor de REX adequado.

Salientamos que o uso de valores de tempos de expiração baixos deve ser evitado, pois aumenta a carga de processamento do router e o número de mensagens de sinalização na rede, podendo mesmo chegar ao ponto de provocar perdas de pacotes de sinalização devido a congestionamentos nos nós.

Assinala-se vivamente que é de evitar o uso de tempos de expiração inferiores a 4 segundos, pois tal facto torna impossível o cumprimento do tempo de ¼ para os refrescamentos. Por outro lado, o uso de valores de tempos de expiração altos implica, em caso de erros, recursos alocados desnecessariamente, o que, em redes congestionadas, pode ser muito relevante.

(27)

Paulo Renato Silva

8 - O protocolo de sinalização

O protocolo de sinalização implementado baseia-se num modo hop-by-hop, ou seja, os pacotes são enviados router a router, para que em todos os routers pelos quais uma reserva necessite de cruzar até ao destino final possam processar e modificar os controlos de tráfego respectivo. Ao mesmo tempo cada reserva é unidireccional, e iniciadas pelo emissor. Tal facto serve para simplificar todo o processo de reserva e para ser mais eficiente.

Este protocolo baseia-se no protocolo RSVP, dado tratar-se de um protocolo muito conhecido e usado, bem como por disponibilizar algumas funcionalidades ao nosso protocolo.

Pretende-se, porém, que este protocolo seja mais escalável do que o próprio RSVP, através da simplicidade do processo de efectuar uma reserva, ao uso de reservas temporárias (soft-state) e ao uso dum processo de identificação da reserva simples e computacionalmente eficaz.

8.1 - Mensagens de sinalização

Ao protocolo RSVP criou-se uma extensão através da criação de 4 novos tipos de mensagens:

SResvInit (utilizada para iniciar uma reserva. É sempre iniciada pelo emissor e tem como destino o receptor do fluxo. Em mais nenhum momento da reserva é usada a não ser para alteração da rota (path);

SResvRefresh (refresca o processamento de reservas. São enviadas igualmente pelo emissor e têm como destino o receptor do fluxo. São enviadas regularmente durante toda a reserva);

SResvStat (envia mensagens de sucesso ou de erro);

(28)

Paulo Renato Silva este pretender o fim da respectiva reserva).

Existem várias classes de objectos para cada tipo de pacote: Session, Filter_spec, Label_setup, Label, RSVP_hop, SResv_parms, GSFlowspec, AFflowspec e Error_spec.

Os objectos usados neste protocolo estão segundo a RFC 2205. Houve, todavia, a necessidade de criar 4 novos objectos:

GSFlowspec (define o tamanho e a taxa do tocken bucket); AFFlowspec (define as taxas de degradação e a taxa de perdas);

Label/Label_setup (define o endereço de memória para a reserva, quer na própria máquina, quer na máquina seguinte, para uso no processo de confirmação de reserva),

SResv_parms (especifica, através do campo PHB, a classe de serviço, para além de ser usado para definir o “msgid”. Este último serve para associar mensagens a SResvStat e o valor do tempo de expiração da reserva, “rex”. Este valor tem 3 bits e está numa escala logarítmica de base 2, por isso tem de ser convertido através duma potencia: REX

tempo=2 . Tal operação permite tempos entre 1 segundo e 128 segundos, o que é ideal para uma implementação dos tempos de expiração com base num algoritmo soft-state).

(29)

Paulo Renato Silva

Figura 6: Formato do pacote SResvInit para um fluxo GS

A mensagem SResvInit, representada na figura 6, tem no seu cabeçalho IP a opção Router_alert, de acordo com o RFC 2113.

Com este pacote é possível dar toda a informação aos routers sobre os IP’s de origem e destino, bem como as portas (através dos objectos “Filter_spec” e “Session”), obter o label (identificação da reserva) no router anterior (“Label_setup”), o IP do router anterior pelo caminho usado (“RSVP Hop”), o intervalo de tempo usado para o refrescamento da reserva (“Sresv_parms”) e as especificações do fluxo.

(30)

Paulo Renato Silva

Figura 7: Formato do pacote SResvInit para um fluxo AF

A mensagem representada pela figura 7, pode igualmente ser usada para iniciar uma reserva do tipo AF, através da alteração do objecto “Flow_spec”, que, neste caso, inclui informação relativa às taxas de degradação e de perdas.

Todos os outros valores supra descritos são os mesmos usados para o caso duma reserva Garanted Service (GS).

(31)

Paulo Renato Silva

Figura 8: Formato do pacote SResvRefresh

As mensagens de refrescamento, figura 8, contêm informações relativas à reserva em questão.

Aquilata-se o uso do objecto “Setup” que torna possível o envio de mensagens de erro ao router anterior, quer em caso de mudanças de rota, quer em casos de reservas inexistentes. As mudanças de rotas são viáveis de detectar através do objecto “RSVP_Hop”, pois se este for diferente ao guardado em memória na máquina significa que houve uma alteração no caminho do fluxo e os procedimentos relativos à mudança de toda a informação guardada nos routers têm de ser invocados.

Todos os outros campos acima apresentados são os mesmos que para uma mensagem SResvInit.

(32)

Paulo Renato Silva

Figura 9: Formato do pacote SResvStat

No tipo de mensagem representado na igura 9, SResvStat, é de salientar que a opção Router_Alert não existe, pois este tipo de mensagem necessita de ser enviado dum modo hop-by-hop. Ou seja, a mensagem é enviada dum router para o seguinte, segundo o caminho guardado em memória da reserva.

Este sistema é necessário uma vez que se pretende assegurar a recepção da informação pretendida por todos os routers que estão a fazer o caminho da reserva, quer em caso de sucesso, quer em caso de erro.

Neste caso é de relevar o objecto “Error_spec”, usado para informar os outros routers no caminho da reserva do sucesso da reserva ou do erro. Tal operação pode ser feita através do campo “error code”.

Os valores usados nesta implementação foram do valor zero (0) para o caso de sucesso, um (1) no caso de mudança de rota e dois (2) no caso de reserva inexistente, não foram implementados mais tipos de erros. Neste objecto encontra-se também incluído o endereço IP do router em que ocorreu o erro/sucesso, e um “error value”, que pode ser usado para descrever ou detalhar o erro.

(33)

Paulo Renato Silva

Figura 10: Formato do pacote SResvTear

A mensagem SResvTear, figura 10, pode ser usada quer pelo router emissor quer por qualquer outro router ao longo do caminho.

No primeiro caso é usada para terminar uma reserva explicitamente, no caso de esta deixar de ser necessária.

Por sua vez, no segundo caso é usado em mudanças de rotas, para terminar a reserva em todos os routers que já não pertencem ao caminho.

Valores usados para definir as mensagens

Dado que foi necessário distinguir as mensagens utilizadas neste protocolo, das mensagens usadas pelo protocolo RSVP propriamente dito, foram empregues valores para o tipo de mensagem RSVP que estavam disponíveis, segundo o RFC2750.

Deste modo, para tipo de mensagem RSVP, campo “type” do cabeçalho RSVP, foram usados os valores contidos na tabela 1. Já para a classe e tipo de objectos RSVP foram usados os valores representados na tabela 2, campos “class” e “type” de cada objecto RSVP respectivamente.

(34)

Paulo Renato Silva

Tabela 1: Valores para os tipos de mensagens usados

(35)

Paulo Renato Silva

8.2 - Funcionamento do protocolo de sinalização

Ao contrário do protocolo RSVP standard, o protocolo ora proposto é sempre da iniciativa do emissor.

Figura 11: Funcionamento normal do protocolo de sinalização SRBQ

Por conseguinte, tendo como base a figura11, ao iniciarmos uma reserva com a mensagem SResvInit (1), esta é enviada tendo como destino o IP de destino do luxo. Ao longo do processamento, a mensagem é capturada por todos os nós ao longo da rota, onde é feito o processamento da reserva, alocação de recursos no sistema e instalação do algoritmo de admissão.

(36)

Paulo Renato Silva envia uma nova mensagem baseada na anterior (2), mas com a informação relativa à rota e identificação do fluxo alteradas. Esta operação repete-se sucessivamente até a informação chegar ao receptor.

Por sua vez, o nó final, destino da reserva, envia de volta para o nó de origem uma mensagem SResvStat (4) não só para determinar o sucesso da operação como também para confirmar a própria reserva.

Desta feita, a mensagem é já enviada explicitamente de nó em nó ao longo do caminho anteriormente definido pela mensagem SResvInit. Este procedimento garante que, quando um nó cria a reserva para um determinado fluxo, todos os nós no sentido do nó de destino tenham as suas reservas feitas.

Em cada nó, e para cada reserva, existe uma estrutura de dados relativa a cada reserva, que contém:

A identificação do nó seguinte;

A identificação da própria reserva (label);

A identificação do nó anterior (b_label e f_label); A informação do IP do nó anterior e do nó seguinte.

A estrutura supra descrita torna possível o envio de mensagens nó a nó (hop-by-hop).

É de salientar que cada reserva é identificada em cada nó por um label que representa a posição de memória em esta estrutura está, sendo assim possível aceder directamente à informação em questão e diminuir o custo de processamento em cada nó.

Esta implementação exige que a identificação da reserva seja trocada em cada nó, pois o valor de label muda de nó em nó. Para tal quando um nó envia uma mensagem a outro nó, este, ao receber a mensagem, identifica a reserva através do label na mensagem. De seguida, o nó receptor faz o processamento da mensagem e, se necessitar de fazer o reenvio da mensagem para o nó seguinte, terá de consultar a informação relativa ao fluxo em questão e trocar o label para o label no nó seguinte bem como o IP de destino.

Do mesmo modo, quando se tornar necessário enviar uma mensagem de erro/sucesso ao nó anterior, estes dois valores terão de ser enviados segundo o que está

(37)

Paulo Renato Silva guardado em memória para aquela reserva.

Sendo forçoso terminar uma reserva, o nó emissor envia uma mensagem SResvTear ao nó seguinte (10). Este terá de retirar a reserva de recursos relativa ao fluxo em questão, trocar o valor do IP de destino da mensagem e do valor de identificação da mensagem segundo os valores guardados em memória e enviar a nova mensagem para o nó seguinte (11). Este processo repete-se até a mensagem chegar ao nó de destino.

Figura 12: Funcionamento do protocolo de sinalização SRBQ num caso de existência de erro

No entanto, durante o processo de refrescamento das reservas, podem ocorrer erros. Um dos erros que podem ocorrer é a inexistência da reserva num determinado nó. Nesta altura torna-se necessário enviar uma mensagem SResvStat, como representado na figura 12, para o nó de origem a informar a ocorrência.

Sendo esta altura um momento de decisão, optamos por fazer o cancelamento da reserva. Porém, poderíamos iniciar de seguida uma outra reserva para colmatar a falha.

O processo de refrescamentos das reservas inicia-se com o envio de uma mensagem de refrescamento.

De seguida, todos os nós intermédios procedem ao refrescamento da reserva até a mensagem de refrescamento chegar ao nó em falha. Nesse momento, é enviado para a origem da reserva uma mensagem de “status” (3) para o nó anterior, no qual é feito o cancelamento da reserva.

(38)

Paulo Renato Silva A mensagem é depois reenviada sucessivamente (4) até chegar ao router de origem.

Outro tipo de erros podem ocorrer quando existam, por algum motivo, mudanças de rotas. Nessa altura é necessário modificar todo o caminho da reserva.

Neste processo, o emissor começa por enviar a mensagem de refrescamento, até esta chegar a um nó que não pertence ao caminho da reserva. Esta ocorrência pode facilmente ser detectada através da consulta do campo “RSVP_Hop” na mensagem e os dados em memória relativos à reserva.

Se a mensagem chegar a um nó não pertencente ao caminho da reserva pode ocorrer uma das duas coisas: o “label” existe mas não pertence aquela reserva, ou o “label” não existe de todo.

No primeiro caso, detecta-se no momento a mudança de rota porque o “previous hop” em memória é diferente.

No segundo caso, só após enviar a mensagem de erro ao nó anterior é que é possível efectuar a detecção, através do “next hop”. Neste momento é inevitável enviar novas mensagens de SResvInit para criar um novo caminho para a reserva e actualizar todos os dados relativos à reserva, tentando terminar as reservas nos nós antigos. Todavia, em certos casos, tal pode não ser possível.

O erro ora em análise deve ser evitado a todo o custo, visto que a detecção de mudanças de rota deve ser feita antes do envio da mensagem, através da consulta das tabelas de roteamento no próprio nó e a informação guardada na estrutura de dados da reserva.

No caso de ser detectada uma mudança de rota, ao invés de ser enviada uma mensagem de refrescamento, deve-se proceder ao envio de uma mensagem SResvInit. Deste modo, define-se uma nova rota para a reserva e tenta-se, igualmente, terminar a reserva nos nós não usados.

Ambos os métodos devem ser implementados, pois pode suceder que, dentro de certos circunstancialismos, no momento da consulta das tabelas de roteamento ainda não tenha ocorrido a mudança de rota.

Neste processo os soft-states são cruciais, pois permitem uma maior flexibilidade em todo este processo. Com efeito, caso não seja possível terminar uma reserva nos nós

(39)

Paulo Renato Silva que deixaram de pertencer ao caminho da reserva, sabemos, e temos mesmo garantia, que estas vão ser terminadas por tempo.

9 – Funcionamento do Deamon

Foi implementado, em linguagem C, um deamon, com a finalidade de proceder à troca de mensagem da arquitectura RSVP. É da responsabilidade deste deamon iniciar as reservas a pedido da sua API, API esta que necessita de ser integrada na aplicação que pretende efectuar as reservas.

Todo o processo de refrescamento é igualmente da competência deste deamon, bem como a detecção de erros na rede. O processo de terminação das reservas fica igualmente a cargo do deamon.

9.1 - Funcionamento inicial e processador de pacotes

A primeira tarefa a levar a cabo no âmbito deste o processo consiste em verificar que se o mesmo foi lançado como super-user, uma vez que certas funções implicam privilégios de root.

Seguidamente, deve-se modificar a prioridade do processo, pois assim verifica-se uma melhoria substancial no rápido funcionamento do processo e consequentemente uma diminuição das perdas de pacotes (por saturação dos buffers de entrada).

Para que seja possibilitar um correcto funcionamento do processador de pacotes, deve-se, primeiramente, identificar as interfaces disponíveis na máquina e correspondentes endereços IP e, posteriormente, configurar a rotina de serviço ao sinal SIGALRM. Neste momento, o processo fica num modo “adormecido” à espera de receber uma mensagem a fim de a processar.

O processamento de pacotes baseia-se na identificação do pacote, através do tipo de pacote RSVP, contido no cabeçalho RSVP (ver tabela x). Para tal, é necessário averiguar se o pacote possui a opção Router_Alert activa a fim de destrinçar os pacotes SResvInit e SResvRefresh dos pacotes SResvStat e SResvTear. Todo o processo

(40)

Paulo Renato Silva seguinte fica, obviamente, dependente do tipo de pacote recebido.

No caso de se tratar de um pacote SResvInit inicia-se uma nova reserva, e aloca-se memória para os dados da realoca-serva. Concomitantemente, é guardado o IP do router anterior, o label, bem como toda a informação relativa às necessidades de recursos da reserva.

Seguidamente é alterado o valor do label_setup e do RSVP_Hop e é feito o reenvio da mensagem para o router seguinte. Quando esta chegar ao seu destino final, é igualmente processada pelo router, como nos anteriores. No entanto, neste caso, não é feito o reenvio, mas antes o envio duma mensagem SResvStat para o router anterior.

Quando o processador de pacotes recebe uma mensagem de SresvRefresh, o trabalho de deamon consiste em verificar a existência do label como reserva, através da consulta do mapa de memória alocada. Posteriormente, este remove a reserva temporal do fifo respectivo e volta a coloca-la no final do fifo com o novo tempo de expiração.

Em caso de sucesso, é feito o reenvio do pacote para o router seguinte. Todavia, em caso de erro, é enviado para o router anterior uma mensagem SResvStat com o erro respectivo.

No caso de receber uma mensagem SResvStat o deamon verifica a validade do label através do mapa de memória alocada e identifica se se trata de uma mensagem de sucesso ou de erro, através do campo “error code”.

Em caso de sucesso o deamon procede à confirmação da reserva. Nesta situação, a reserva passa a ter disponíveis os recursos para o fluxo naquele router, sendo reenviada para o router seguinte, se necessário desde que anteriormente tenham sido alterados os valores do label, label_setup e RSVP_Hop.

No caso de ser uma mensagem de erro a reserva é eliminada, uma vez que não foi implementado o processamento de mudanças de rota. Se o label da mensagem não existir no mapa de memória alocada é enviada um SResvStat a reportar o respectivo erro.

Por último, no caso da mensagem recebida se tratar do tipo SResvTear é verificado a validade do label. Neste caso, a reserva temporal da memória é de igual modo removida

(41)

Paulo Renato Silva através do mapa de memória alocada. De seguida, toda a informação relativa à reserva é apagada, bem como alteradas as definições de controlo de tráfego. Se necessário, a este tipo de mensagem é reenviado para o router seguinte.

Por fim, procede-se a uma nova procura da próxima reserva a expirar e activa-se o alarme para a próxima reserva a expirar. De salientar, que o processador de pacotes desliga este alarme inicialmente para que a função de serviço ao SIGALRM nunca seja executada, evitar, assim, eventuais incongruências.

O socket usado para receber os pacotes é do tipo RAW, com filtro para mensagens RSVP e com a opção ROUTER_ALERT activa.

(42)

Paulo Renato Silva

(43)

Paulo Renato Silva

9.2 - Funcionamento do módulo de comunicação com a API

Este módulo, cujo fluxograma é representado pela figura 14, é lançado pelo programa principal como uma thread, o que, apesar do processamento paralelo, não afecta a performance do deamon, uma vez que, como supra referido, esta encontra-se maioritariamente num modo “adormecido”.

Este modelo usa sockets do tipo UNIX e fica à espera de informação vinda da API, e procedendo ao respectivo processamento da informação. Após receber essa informação, verifica o que fazer com ela: apagar a reserva, criar reserva GS ou criar reserva AF.

No caso de ser necessário criar uma reserva, é feito todo o procedimento de criação duma reserva, designadamente, reservar recursos o sistema, acrescentar à lista biligada toda a informação relativa à reserva, inserir o tempo de expiração na respectiva lista e enviar o pacote SResvInit. No final, o valor de label da reserva criada retorna à API.

O valor de label da reserva criada vai ser usado quando for necessário terminar a reserva. A API fica assim com a vantagem de informar o deamon que quer terminar, fornecendo, para tal, o label. Esta possibilidade beneficia o processamento do deamon dado que possibilita o acesso directo à memória alocada para a reserva.

O processo de apagar a reserva passa por retirar a reserva da tabela de tempo de expiração, apagar a informação sobre a reserva da lista biligada, alterar as definições de controlo de tráfego e enviar o pacote de SResvStat.

Se a operação for bem sucedida é retornado à API o valor 0. Deve-se, porém, antes de apagar a reserva, verificar, através do mapa de memória alocada, a validade do label pois este pode já não existir.

No final, a fim de evitar exclusão mútua, procede-se ao fecho do socket usado e programa-se a próxima reserva a expirar. Esta exclusão suceder visto que ambas as threads têm a possibilidade de aceder, em simultâneo, à memória global.

Este módulo tem de ser executado com o “mutex_lock”, para garantir exclusão mútua no acesso a regiões de memória críticas.

(44)

Paulo Renato Silva

(45)

Paulo Renato Silva

9.3 - Funcionamento da função manipuladora do SIGALRM

Esta rotina de serviço é executada sempre que o kernel active a interrupção SIGALARM.

Analisando o fluxograma da função, figura 15, podemos verificar que inicialmente, é levada a cabo uma procura em busca da próxima reserva a expirar. Caso a reserva tenha realmente expirado, este serviço cuida do seu tratamento. Caso não o efectue, o serviço programa o alarme para o seguinte tempo de expiração.

O processo de tratamento passa por verificar se a reserva é local, isto é, se a reserva teve como origem a máquina em questão. Neste caso, tem de verificar se a reserva já foi confirmada, visto que é infrutífero proceder ao refrescamento da reserva se esta não foi confirmada.

Em caso afirmativo, a reserva é removida da memória.

No caso da reserva ter sido confirmada efectua-se, então, o refrescamento da reserva, enviando-se, de seguida, o pacote SResvRefresh para o router seguinte, de acordo com a informação guardada e memória. Este processo repete-se até encontrar uma reserva que não tenha expirado.

É também exequível verificar a existência dum contador “número de vezes”.

No presente projecto, este contador foi implementado para evitar o congestionamento dos buffers de recepção com mensagens de refrescamento. De facto, tal pode ocorrer quando existem muitas reservas em memória com tempos de expiração num intervalo de 1 segundo. Conseguimos, assim, dividir as mensagens de refrescamento em grupos de 100 espaçadas de 10ms, o que solucionou o problema.

Contudo, entendemos que estes valores deveriam depender do número de reservas a refrescar e da capacidade de processamento dos próprios routers.

(46)

Paulo Renato Silva Procurar próxima reserva

Próxima reserva expirou? Numero vezes<100? A reserva não é local? A reserva foi confirmada?

Remover reserva não local Remover resrva local Refrescar reserva local

Enviar pacote SResvRefresh

Procurar próxima reserva

Incrementar número de vezes

Programar temporizador para próxima reserva Exit Não Não Não Não Sim Sim Sim Sim

Programar temporizador para 10ms

Start