IntServ

Em redes de computadores, o IntServ ou serviços integrados é um modelo que visa garantir a qualidade de serviço (QoS) em redes. IntServ pode por exemplo ser utilizado para possibilitar a transmissão de vídeo e som sem interrupções.

É um sistema de grande granularidade, muitas vezes contrastado com os serviços diferenciados, um modelo de pouca granularidade.

Basicamente, a ideia por detrás do IntServ é que qualquer router no sistema suporte IntServ, e que qualquer aplicação que exija um determinado nível de garantias seja responsável por fazer reservas individuais. A "Especificação do fluxo" (Flow Specs) descreve em que consistem as reservas, enquanto que "RSVP" é o mecanismo responsável por fazê-las.

Especificação do fluxo[editar | editar código-fonte]

Existem duas componentes na especificação do fluxo:

Como é o tráfego? Explicado pela Especificação de Tráfego (Traffic SPECification ou TSPEC).
Que garantias necessita? Explicado pelo serviço de Especificação da Requisição (Request SPECification ou RSPEC).

Para entender as TSPECs, deverá ser explicado em que consiste o filtro token bucket filter. Basicamente, existe um balde que vai sendo lentamente preenchido com tokens (tickets). Cada pacote enviado retira um token e, caso não existam tokens, o pacote não poderá ser enviado. A velocidade a que os tokens chegam regula a taxa média do fluxo de tráfego, enquanto o volume (profundidade) do balde dita a variação permitida no fluxo do tráfego.

Tipicamente, As TSPECs apenas especificam estes dois parâmetros: a taxa dos tokens e a profundidade do balde. Por exemplo, um vídeo com taxa de atualização de 75 frames por segundo, com cada frame a necessitar de 10 pacotes, pode especificar uma taxa de tokens de 750Hz, e uma profundidade de balde de apenas 10. A profundidade seria suficiente para acomodar o pico associado ao envio imediato de uma frame. Por outro lado, uma conversação iria necessitar uma taxa de tokens inferior, mas uma profundidade de balde muito superior, dado que existem muitas pausas durante uma conversação e, portanto, pode ser satisfeita com menos tokens não enviando as pausas entre palavras e frases. Contudo, isto implica que a profundidade do balde seja superior para compensar a quantidade de palavras enviadas.

As RSPECs especificam os requisitos do fluxo: pode ser o fluxo normal best effort da Internet, que não carece de reservas. Esta configuração é provavelmente usada para a web, transferência de ficheiros, e similares. O parâmetro 'Controlled Load' (Carga Controlada) espelha a performance de uma rede com pouca carga: podem verificar-se pequenas intermitências quando duas pessoas acedem ao mesmo recurso por acaso, embora geralmente as taxas de latência (delay) e descarte (drop) sejam praticamente constantes na taxa desejada. Este parâmetro é um bom candidato para aplicações QoS simples. O parâmetro 'Guaranteed' (Garantido) oferece um serviço absolutamente delimitado, em que um limite máximo de latência é assegurado, e os pacotes nunca são descartados desde que o tráfego se mantenha dentro das especificações.

RSVP[editar | editar código-fonte]

O Resource ReSerVation Protocol (RSVP) é descrito no RFC 2205. Todas as máquinas na rede capazes de enviar dados QoS enviam uma mensagem de PATH a cada 30 segundos, que será difundida a toda a rede. Aqueles que desejem aceitá-lo enviam uma mensagem de RESV (diminutivo de Reserve) que irá servir para resolver o caminho de volta para o emissor. A mensagem RESV irá incluir também as especificações de fluxo.

Os routers entre o emissor e receptor decidem então se podem suportar a reserva requerida e, em caso negativo, enviam uma mensagem de rejeição para notificar o interlocutor. Caso contrário, assim que aceitam a reserva serão responsáveis por suportar o tráfego.

Entretanto, os routers armazenam a natureza do fluxo e regulam-no. Isto é realizado sob um estado de volatilidade, o que significa que se não existir contacto durante um determinado período de tempo, o tempo de escuta irá expirar e a reserva será cancelada. Esta medida permite resolver situações em que o emissor ou o receptor bloqueiam ou são desligados incorrectamente sem previamente cancelar as reservas. Individualmente, os routers podem, como opção, sondar o tráfego para garantir a conformidade com as especificações de fluxo.

Problemas[editar | editar código-fonte]

O principal problema do modelo IntServ é a necessidade de armazenar os múltiplos estados em cada router. Como resultado, o IntServ torna-se praticável numa escala reduzida, embora com o escalonamento até um sistema das dimensões da Internet, torna difícil de gerir todas as reservas. Como consequência, o IntServ não é muito popular.^[1]