Banda passante no pw

Ana Luiza Bessa de Paula Barros Diniz

Um Serviço de Alocação Dinâmica de BandaPassante em Redes ATM para Suporte a

Aplicações Multimídia

Dissertação apresentada ao Departamento deCiência da Computação do Instituto de CiênciasExatas da Universidade Federal de Minas Gerais,como requisito parcial para obtenção do grau demestre em Ciência da Computação

Belo Horizonte

26 de Março de 1998

i

AoMarcio, meu marido,

Barros e Laura, meus pais,Barros Neto e Ana Carolina, meus irmãos.

ii

AgradecimentosAgradeço a Deus, em Quem sempre tive fé, e onde sempre busquei força e

perseverança. Agradeço, principalmente, por Sua presença constante.

Agradeço esta vitória aos meus pais, que sempre foram exemplo de coragem e

dedicação. Nunca teria conseguido chegar aqui, se não fosse o apoio, carinho e amor a

mim dispensados. Com certeza, esta alegria que vivencio agora é deles também.

Agradeço ao Marcio, meu marido e amigo, pelos momentos em que me

compreendeu e incentivou. Sua presença, sua força, seu apoio e seu amor, foram

fundamentais para que eu conseguisse alcançar este objetivo. Sua participação, nos

momentos mais difíceis, e sua alegria, nos momentos mais felizes, foram muito

importantes.

Agradeço ao meu irmão, Barros Neto, e a minha irmã, Carol, pelo pensamento

positivo e torcida, em todos os momentos. Agradeço também a Andrea, pela força.

Agradeço ao professor, amigo e orientador, José Marcos, pelo apoio, orientação,

incentivo e conhecimentos transmitidos.

Agradeço ao professor Mauro Oliveira pelo apoio, motivação e incentivo, mesmo

antes do início deste trabalho e do curso de mestrado. Sua ajuda foi de extrema

importância.

Agradeço ao Carlos, pela paciência e disponibilidade para explicar e tirar dúvidas.

Agradeço ao professores e funcionários do DCC/UFMG.

Agradeço ao Flávio, por sua grande ajuda e pelas ótimas discussões a cerca do

trabalho, que foram muito importantes.

Agradeço ao Bráulio, pela amizade e ajuda fundamental na discussão de

problemas estatísticos.

Agradeço aos amigos do laboratório, Patrícia, Patty, Fernando e Daniel, pelos

ótimos momentos que vivemos, em um ambiente alegre e descontraído. Agradeço pelo

companheirismo sempre presente entre nós.

Agradeço aos amigos do mestrado, pelos dias de estudo e desespero que passamos

juntos e também pela nossa união. Sem esse apoio tudo teria sido muito mais difícil.

Agradeço aos amigos da Quinta Feliz, por tantos bons momentos.

Agradeço a Marisa, pelo apoio, incentivo e amizade.

Agradeço a CAPES, agência financiadora deste trabalho.

iii

Resumo

Com o surgimento das aplicações multimídia, apareceram novos conceitos de

critérios de qualidade e requisitos de comunicação. Estas aplicações possuem mais de um

tipo de mídia integradas, como voz, dados, imagem e vídeo. Cada tipo de mídia possui

características e requisitos diferentes. Para que informações de uma aplicação multimídia

distribuída possam ser transmitidas através de uma rede, esta última deve prover garantias

que atendam aos requisitos de todas as mídias. Uma outra característica das aplicações

multimídia é que, algumas destas aplicações, como vídeo, por exemplo, possuem muitas

informações a serem transmitidas na rede e requerem uma grande capacidade de banda

passante. Para que uma rede suporte aplicações multimídia, ela deve oferecer garantias de

Qualidade de Serviço (QoS) e alta velocidade.

A tecnologia de rede ATM (Asynchronous Transfer Mode) mostra-se uma forte

candidata para dar suporte a este tipo de aplicação. Esta tecnologia fornece garantias de

qualidade de serviço, através da implementação de classes de serviço e de um algoritmo

de controle de admissão de conexão (CAC). Com ATM, também é possível conseguir

velocidades de acesso da ordem de megabits por segundo.

Para transmitir informações através de uma rede, com garantias de qualidade de

serviço, é necessário que, na fase de estabelecimento da conexão, a aplicação faça uma

negociação, com a rede, da qualidade de serviço desejada. Esta negociação pode ser

estática ou dinâmica. Na negociação estática, os valores dos parâmetros de qualidade são

definidos no início da transmissão e não podem ser alterados. Na negociação dinâmica,

estes parâmetros podem ser alterados durante a fase ativa da conexão.

Este trabalho apresenta um serviço de negociação dinâmica de qualidade de

serviço para redes ATM. O serviço foi desenvolvido para dar suporte a transmissão de

dados de aplicações multimídia. O objetivo é prover um nível de qualidade de serviço ao

usuário, ao mesmo tempo que é atingido um bom desempenho da rede. Neste trabalho

estão envolvidos os conceitos básicos de aplicações multimídia, qualidade de serviço e

redes ATM. Estes conceitos são discutidos inicialmente. Depois é definido o serviço da

camada de negociação de QoS e é mostrado também o protocolo de negociação. A

estrutura do serviço de negociação dinâmica e alguns aspectos de implementação

também são abordados. Por fim, são apresentados a execução dos testes e os resultados

obtidos.

iv

Abstract

With the emergence of multimedia applications, new concepts of quality standards

and communications requirements appeared. These applications have more than one type

of media integrated, like voice, data, image and video. Each type of media has different

features and requirements. In order to transmit information of a distributed multimedia

application through a network, the last one must provide warranties to support the

requirements of all medias. Another feature of multimedia applications is that, some of

media, like video for example, has too much information to be transmitted through a

network and require a high bandwidth capacity. To support multimedia applications, a

network must offer quality of service (QoS) warranties and high speed.

ATM (Asynchronous Transfer Mode) network technology is one of the strongest

candidates to provide support for this kind of application. This technology provides

quality of service guarantees through the implementation of service classes and of a

Connection Admission Control (CAC) algorithm. It’s also possible to achieve high-speed

access (megabits per second) using ATM.

In order to transmit information in the network with quality of service guarantees,

it’s necessary that, in the connection establishment phase, the application negotiate the

quality of service desired with the network. This negotiation can be either static or

dynamic. In the static negotiation, the values of the parameters of quality are defined in

the beginning of the transmission and can not be modified. In the dynamic negotiation,

these parameters can be modified during the active phase of the connection.

This work presents a dynamic negotiation service of Quality of Service (QoS),

based on ATM networks. The service was developed to support data transmission of

multimedia applications. The goal is to guarantee a quality of service level to the user and

at the same time a better network performance. This work envolves the basic concepts of

multimedia applications, quality of service and ATM networks, which are discussed first.

After that, the QoS negotiation layer service is defined and the negotiation protocol is

also showed. The dynamic negotiation service structure and some implementation aspects

are discussed. Finally, the performance of the tests are shown and the results obtained are

presented.

v

Sumário

CAPÍTULO 1

INTRODUÇÃO .............................................................................................................................................1

1.1 MOTIVAÇÃO..........................................................................................................................................2

CAPÍTULO 2

APLICAÇÕES MULTIMÍDIA E REQUISITOS DE COMUNICAÇÃO................................................6

2.1 INTRODUÇÃO.........................................................................................................................................62.2 CARACTERÍSTICAS DAS MÍDIAS..............................................................................................................72.3 APLICAÇÕES MULTIMÍDIA ...................................................................................................................10

2.3.1 Exemplos de Aplicações Multimídia ...........................................................................................112.4 REQUISITOS DE COMUNICAÇÃO...........................................................................................................142.5 SISTEMAS MULTIMÍDIA........................................................................................................................172.6 RESUMO DO CAPÍTULO........................................................................................................................19

CAPÍTULO 3

QUALIDADE DE SERVIÇO .....................................................................................................................20

3.1 INTRODUÇÃO.......................................................................................................................................213.2 FUNÇÕES DE GERENCIAMENTO DE QOS ..............................................................................................243.3 NEGOCIAÇÃO DE QOS .........................................................................................................................27

3.3.1 Passos da negociação .................................................................................................................283.3.2 Componentes do sistema envolvidos na negociação de QoS ......................................................29

3.4 RENEGOCIAÇÃO...................................................................................................................................303.5 RESUMO DO CAPÍTULO........................................................................................................................32

CAPÍTULO 4

REDES ATM PARA TRANSMISSÃO DE APLICAÇÕES MULTIMÍDIA COM GARANTIAS DEQOS ..............................................................................................................................................................33

4.1 INTRODUÇÃO.......................................................................................................................................334.2 TECNOLOGIA ATM..............................................................................................................................364.3 QUALIDADE DE SERVIÇO EM REDES ATM...........................................................................................41

4.3.1 Reserva, Alocação e Dedicação de Recursos .............................................................................414.3.2 Classes de Serviço ATM..............................................................................................................42

4.4 CONTROLE DE ADMISSÃO DE CONEXÕES EM REDES ATM..................................................................434.5 RESUMO DO CAPÍTULO........................................................................................................................46

CAPÍTULO 5

UM ESQUEMA DE NEGOCIAÇÃO DINÂMICA DE QOS ..................................................................48

5.1 INTRODUÇÃO.......................................................................................................................................485.2 RESUMO DO CAPÍTULO........................................................................................................................50

CAPÍTULO 6

UM SERVIÇO DE NEGOCIAÇÃO DE QOS PARA UMA REDE ATM .............................................51

6.1 INTRODUÇÃO.......................................................................................................................................51

vi

6.2 SERVIÇO ..............................................................................................................................................526.2.1 Diagramas de Tempo das Primitivas de Serviço ........................................................................54

6.3 O SERVIÇO DA CAMADA ATM............................................................................................................576.4 O PROTOCOLO DE NEGOCIAÇÃO..........................................................................................................59

6.4.1 Descrição do Protocolo ..............................................................................................................596.5 RESUMO DO CAPÍTULO........................................................................................................................67

CAPÍTULO 7

PROJETO E IMPLEMENTAÇÃO DO SERVIÇO DE NEGOCIAÇÃO DINÂMICA EM UMAREDE ATM..................................................................................................................................................69

7.1 PROJETO ..............................................................................................................................................697.1.1 Módulos ......................................................................................................................................697.1.2 Estruturas de Dados ...................................................................................................................70

7.2 IMPLEMENTAÇÃO ................................................................................................................................727.2.1 Estrutura de Execução Real do Esquema de Negociação ..........................................................727.2.2 Estrutura de Execução do Protótipo do Esquema de Negociação .............................................727.2.3 Dificuldades Encontradas na Implementação ............................................................................737.2.4 Algoritmos...................................................................................................................................74

7.3 RESUMO DO CAPÍTULO........................................................................................................................78

CAPÍTULO 8

TESTES E ANÁLISE DOS RESULTADOS.............................................................................................79

8.1 INTRODUÇÃO.......................................................................................................................................798.2 ELABORAÇÃO DOS TESTES ..................................................................................................................828.3 ANÁLISE DOS RESULTADOS .................................................................................................................83

8.3.1 Análise de Variância ...................................................................................................................838.3.2 Análise de Regressão ..................................................................................................................92

8.4 ANÁLISE DE VIABILIDADE DO ESQUEMA..............................................................................................948.5 RESUMO DO CAPÍTULO........................................................................................................................96

CAPÍTULO 9

CONCLUSÕES E TRABALHOS FUTUROS ..........................................................................................97

9.1 INTRODUÇÃO.......................................................................................................................................979.2 TRABALHOS FUTUROS.........................................................................................................................99

vii

Índice de Figuras

FIGURA 1.1 - VARIAÇÃO NA CODIFICAÇÃO DE BANDA PASSANTE PARA VÍDEO ...............................................4FIGURA 3.1 - NEGOCIAÇÃO TRIANGULAR.......................................................................................................28FIGURA 4.1 - CLASSES DE SERVIÇO ATM, SUAS CARACTERÍSTICAS E RESPECTIVAS APLICAÇÕES...................43FIGURA 4.2 - ESTABELECIMENTO DE UMA CONEXÃO ATRAVÉS DE UMA REDE ATM ......................................46FIGURA 5.1 - ARQUITETURA DA NEGOCIAÇÃO DE QOS...................................................................................49FIGURA 5.2: BANDA ALOCADA X BANDA REAL .............................................................................................49FIGURA 6.1 - ARQUITETURA DE NEGOCIAÇÃO DE QOS PARA UMA REDE ATM ..............................................52FIGURA 6.2 - POSIÇÃO DA CAMADA DE NEGOCIAÇÃO DE QOS DENTRO DE UM ESQUEMA DE CAMADAS .......53FIGURA 6.3 - ESTRUTURA INTERNA DA CAMADA DE NEGOCIAÇÃO DE QOS...................................................53FIGURA 6.4 - DIAGRAMA DE TEMPO PARA A PRIMITIVA ESTABELECER_CONEXAO........................................55FIGURA 6.5 - DIAGRAMA DE TEMPO PARA A PRIMITIVA TERMINAR_CONEXAO .............................................55FIGURA 6.6 - DIAGRAMA DE TEMPO PARA A PRIMITIVA MENOS_RECURSOS..................................................56FIGURA 6.7 - DIAGRAMA DE TEMPO PARA A PRIMITIVA MAIS_RECURSOS .....................................................56FIGURA 6.8 - DIAGRAMA DE TEMPO MOSTRANDO A ORDEM DE EXECUÇÃO DAS PRIMITIVAS E PDUS ...........57FIGURA 6.9 - ORDEM DE EXECUÇÃO PARA TRANSMISSÃO .............................................................................59FIGURA 6.10 - ORDEM DE EXECUÇÃO PARA RECEPÇÃO.................................................................................59FIGURA 6.11 - ESQUEMA DOS CANAIS DE COMUNICAÇÃO ENTRE AS MÁQUINAS - 1 CANAL DE CONTROLE E

VÁRIOS DE DADOS.................................................................................................................................61FIGURA 6.12 - ESTRUTURA DO BUFFER DE DADOS DA FUNÇÃO PUTMSG ONDE SÃO TRANSMITIDAS AS

PRIMITIVAS DE NEGOCIAÇÃO.................................................................................................................63FIGURA 6.13 - MÁQUINA DE ESTADOS FINITOS DO NÓ CLIENTE ....................................................................66FIGURA 6.14 - MÁQUINA DE ESTADOS FINITOS DO NÓ SERVIDOR..................................................................66FIGURA 6.15 - MÁQUINA DE ESTADOS FINITOS DO NÓ INTERMEDIÁRIO.........................................................67FIGURA 7.1 - ESTRUTURA DE EXECUÇÃO DO ESQUEMA DE NEGOCIAÇÃO......................................................72FIGURA 7.2 - ESTRUTURA DE EXECUÇÃO DO PROTÓTIPO...............................................................................73FIGURA 7.3 - ALGORITMOS DE APOIO.............................................................................................................75FIGURA 7.4 - ALGORITMO DO MÓDULO CLIENTE ...........................................................................................76FIGURA 7.5 - ALGORITMO DO MÓDULO INTERMEDIÁRIO ...............................................................................77FIGURA 7.6 - ALGORITMO DO MÓDULO SERVIDOR.........................................................................................78FIGURA 8.1 - PERCENTUAL DE REJEIÇÃO DE RENEGOCIAÇÃO X QUANTIDADE DE NÓS ..................................84FIGURA 8.2 - PERCENTUAL DE REJEIÇÃO DE RENEGOCIAÇÃO X CAPACIDADE DOS NÓS.................................85FIGURA 8.3 - PERCENTUAL DE REJEIÇÃO DE RENEGOCIAÇÃO X QUANTIDADE DE PEDIDOS DE CONEXÃO......87FIGURA 8.4 - PERCENTUAL DE REJEIÇÃO DE RENEGOCIAÇÃO X TEMPO DE SIMULAÇÃO................................88FIGURA 8.5 - PERCENTUAL DE REJEIÇÃO DE RENEGOCIAÇÃO X RESERVA MÍNIMA ........................................90FIGURA 8.6 - PERCENTUAL DE REJEIÇÃO DE RENEGOCIAÇÃO X RESERVA MÁXIMA ......................................91FIGURA 8.7 - PERCENTUAL DE REJEIÇÃO DE RENEGOCIAÇÃO EM RELAÇÃO A RESERVA MÍNIMA..................92FIGURA 8.8 - PERCENTUAL DE REJEIÇÃO DE RENEGOCIAÇÃO EM RELAÇÃO A RESERVA MÍNIMA E MÁXIMA.92

viii

Índice de Tabelas

TABELA 2.1 - TAXAS DE BITS DE APLICAÇÕES DE ÁUDIO E VÍDEO ................................................................16TABELA 3.1 - FASES DE UMA APLICAÇÃO E SUAS RESPECTIVAS FUNÇÕES DE GERENCIAMENTO DE QOS ........26TABELA 4.1 - PARÂMETROS MULTIMÍDIA PARA TECNOLOGIAS DE REDES DE PACOTE DE LONGA DISTÂNCIA...40TABELA 8.1 - MATRIZ COM VALORES UTILIZADOS NOS TESTES (QUADRADO LATINO)..................................82TABELA 8.2 - ANÁLISE DE VARIÂNCIA DA QUANTIDADE DE NÓS EM RELAÇÃO AO PERCENTUAL DE REJEIÇÃO

DE PEDIDOS DE RENEGOCIAÇÃO ...............................................................................................84TABELA 8.3 - ANÁLISE DE VARIÂNCIA DA CAPACIDADE DO NÓS EM RELAÇÃO AO PERCENTUAL DE REJEIÇÃO

DE PEDIDOS DE RENEGOCIAÇÃO ...............................................................................................85TABELA 8.4 - ANÁLISE DE VARIÂNCIA DA QUANTIDADE DE PEDIDOS DE CONEXÃO EM RELAÇÃO AO

PERCENTUAL DE REJEIÇÃO DE PEDIDOS DE RENEGOCIAÇÃO ....................................................86TABELA 8.5 - ANÁLISE DE VARIÂNCIA DO TEMPO DE SIMULAÇÃO EM RELAÇÃO AO PERCENTUAL DE

REJEIÇÃO DE PEDIDOS DE RENEGOCIAÇÃO...............................................................................88TABELA 8.6 - ANÁLISE DE VARIÂNCIA DA RESERVA MÍNIMA EM RELAÇÃO AO PERCENTUAL DE REJEIÇÃO DE

PEDIDOS DE RENEGOCIAÇÃO ....................................................................................................89TABELA 8.7 - ANÁLISE DE VARIÂNCIA DA RESERVA MÁXIMA EM RELAÇÃO AO PERCENTUAL DE REJEIÇÃO DE

PEDIDOS DE RENEGOCIAÇÃO ....................................................................................................90TABELA 8.8 - EQUAÇÃO DE REGRESSÃO DO PERCENTUAL DE REJEIÇÃO EM RELAÇÃO AOS PARÂMETROS:

QUANTIDADE DE PEDIDOS DE CONEXÃO, TEMPO DE SIMULAÇÃO, RESERVA MÁXIMA, RESERVA

MÍNIMA E CAPACIDADE DOS NÓS .............................................................................................94

1

Capítulo 1

Introdução

O desenvolvimento das tecnologias de transmissão de dados possibilitou o surgimento

das redes de alta velocidade com capacidade de transportar informações na ordem de

milhões de bits por segundo. A existência dessas redes tornou possível a implementação

de aplicações que requisitassem grande capacidade de transmissão. Dentre estas

aplicações, podem ser citadas, como das mais importantes, as aplicações multimídia.

A maioria das aplicações utilizadas nas redes de dados atuais são pouco sensíveis

a variações de banda e retardo. Os serviços de rede como correio eletrônico e

transferência de arquivo podem executar com a quantidade de banda que é fornecida a

eles. Serviços interativos, tais como login remoto, beneficiam-se pouco de valores de

banda maiores. Esta aplicação envia apenas pequenos pacotes de dados e o maior

benefício de ter muita banda disponível é reduzir a interferência de grandes pacotes sobre

pequenos pacotes de dados, pois os pequenos levam menos tempo para serem

transmitidos. A aplicação de sistema de arquivos distribuído (NFS - Network File System)

se beneficia de um maior valor de banda. Ter uma rede com muita banda passante reduz o

tempo para transmissão de dados do servidor para o cliente. No entanto, o aumento de

banda passante para as aplicações citadas, faz apenas com que elas sejam executas mais

rapidamente, mas não influencia no resultado ou na correção de suas execuções [Partr94].

As aplicações multimídia geram vários tipos de informação, como texto, dados,

voz, vídeo e imagem. Em uma transmissão multimídia, todas essas informações devem

ser enviadas em um mesmo meio de comunicação. Por esse motivo, e pelo fato de alguns

tipos de informação, como vídeo, por exemplo, possuírem muitos dados, a transmissão

destas aplicações, requer uma grande capacidade de banda passante.

Cada um desses tipos de informação possui requisitos diferentes, no que diz

respeito a retardo de transmissão, taxa de erros, perda de dados e largura de banda.

Assim, uma rede para transmitir uma aplicação multimídia deve oferecer garantias de

Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira

2

qualidade de serviço (QoS - Quality of Service), para que todas as informações

transmitidas tenham seus requisitos atendidos.

A negociação da qualidade de serviço consiste em fazer, no início de cada

conexão, uma negociação dos parâmetros de transmissão necessários a cada tipo de

aplicação e, a partir daí, tanto as aplicações como a rede devem obedecer aos requisitos

de qualidade estabelecidos. Esse tipo de negociação, feito apenas no início da

transmissão, pode ser chamado de negociação estática, pois os parâmetros acordados no

estabelecimento da conexão continuam até que ela finalize.

A negociação dinâmica da qualidade de serviço permite que os parâmetros de

qualidade sejam alterados durante a fase ativa da conexão. Essa negociação pode ser feita

para requisitar mais ou menos recursos. Dessa maneira, se uma aplicação estiver

subutilizando recursos, ela pode liberá-los. Estes recursos podem ser reaproveitados por

conexões que, em um determinado momento, exijam mais recursos ou até mesmo por

aplicações que desejem iniciar uma transmissão. A utilização da negociação dinâmica

possibilita uma melhor utilização do meio de transmissão.

Uma rede, para transportar dados de aplicações multimídia, deve oferecer,

portanto, alta velocidade de transmissão e garantias de qualidade de serviço. Nesse

sentido, a tecnologia de rede ATM (Asynchronous Transfer Mode) tem-se mostrado como

uma das mais promissoras.

1.1 Motivação

As redes ATM oferecem garantias de qualidade de serviço. Isto possibilita a transmissão

de informações de aplicações multimídia, de forma que sejam atendidos todos os

requisitos de qualidade de cada mídia (texto, voz, dados, imagem). A definição desses

parâmetros é possível devido a existência do conceito de classes de serviço nas redes

ATM.

Para atender às classes de serviços, foi definida, no modelo de referência ATM,

uma camada de adaptação (AAL - ATM Adaptation Layer), cuja função é justamente

adaptar as características de cada aplicação ao funcionamento de outra camada, chamada

ATM.

As redes ATM atendem a um compromisso entre dois objetivos conflitantes.

Garantir o desempenho para cada classe de serviço enquanto permite que a rede seja

usada eficientemente, através da utilização de multiplexação estatística. Para tanto, é

necessário desenvolver uma arquitetura de gerenciamento de banda passante sob a qual a

Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98

3

rede possa ser eficientemente utilizada e, enquanto isso, possa ser obtida uma QoS

aceitável para todas as classes de serviço [LPF+97].

Atualmente já existem esquemas de negociação de QoS em redes ATM, baseados

na utilização das classes de serviços e da AAL. Nesses esquemas, antes de se iniciar a

transmissão, informa-se à rede a qual classe de serviço pertencerá a aplicação sendo

transmitida.

O processo de negociação, no entanto, é estático, e muitas vezes não possibilita

uma boa utilização da rede. Para tanto, foi idealizado o esquema de negociação dinâmica,

no qual os parâmetros de QoS podem ser alterados no decorrer da sessão estabelecida.

A alocação dinâmica de recursos, que possibilita a execução da renegociação

dinâmica de QoS, foi proposta para superar dificuldades da alocação estática. A alocação

dinâmica de banda passante, adapta-se à situação real e modifica dinamicamente a banda

passante alocada. Este tipo de alocação necessita de funções avançadas para monitorar a

situação da rede, alocar a banda passante e modificar seu valor [Saito97].

De acordo com [Saito97], a alocação dinâmica de banda passante (controle de

taxa de células da fonte), para taxas de pico de 150Mbps e 6Mbps, tem 60% e 35%,

respectivamente, melhor utilização da banda passante que a alocação estática.

A transmissão de informações de aplicações multimídia, como vídeo, requer

muita banda passante. Geralmente são utilizados algoritmos de compressão nos arquivos

de vídeo para que seus dados sejam transmitidos pela rede. Devido a compactação, a

quantidade de dados que deve ser enviada para cada quadro de vídeo pode variar bastante.

Essa variação apresenta um problema [Partr94], conforme mostrado a seguir.

Este problema é exemplificado na figura 1.1 para uma sequência de cinco

quadros. A linha mais forte mostra a quantidade de banda que um quadro necessita em

um determinado momento e a linha pontilhada mostra a quantidade de banda que cada

quadro tem disponível. Os quadros 2 e 4 necessitam de mais banda do que a alocada e os

quadros 1, 3 e 5 não precisam de toda a banda que está alocada.


4

Tempo

Ban

da P

assa

nte

Figura 1.1 - Variação na Codificação de Banda Passante para Vídeo

Os codificadores de vídeo solucionam este problema da seguinte maneira: eles

selecionam um valor de banda na qual as informações devem ser transmitidas (tendo

como base a banda passante disponível dos circuitos virtuais e a qualidade desejada do

sinal de vídeo). O vídeo então, é codificado tal que, quando a quantidade de dados de um

quadro excede o valor de banda selecionada, são transmitidas informações o suficiente,

para que se tenha uma imagem com qualidade razoável. Depois, quando existir um

quadro que não necessite de toda a banda passante, são enviados, utilizando-se a banda

restante destes quadros, dados para retocar a imagem e torná-la o mais próximo possível

da imagem correta.

Este problema ocorre quando as informações de um vídeo são transmitidas através

de um canal que possui uma quantidade de banda alocada fixa. Uma solução para este

problema é transmitir dados em um canal que permita a alocação dinâmica de banda

passante. Isto proporciona uma melhor utilização do canal e uma melhor garantia de

qualidade à aplicação de vídeo.

O principal objetivo da negociação dinâmica (ou renegociação) é explorar o

comportamento dinâmico de conexões multimídia para maximizar a utilização dos

recursos e, como consequência, acomodar um maior número de conexões [GNN97].

Não existem modelos de negociação dinâmica para redes ATM, padronizados

pelo ATM Forum. A motivação deste trabalho foi o esquema desenvolvido como parte de

um trabalho de pesquisa de tese de doutorado, conforme apresentado em [Goula98] e

[GNN97]. Nestas referências, é proposto um esquema de negociação dinâmica de


5

qualidade de serviço para aplicações multimídia. A partir daí então, surgiu a idéia de

adaptá-lo para redes ATM e fazer uma implementação do esquema.

Com um modelo de negociação dinâmica desenvolvido para redes ATM, é

possível utilizar estas redes com uma melhor eficiência, possibilitando que as aplicações

transmitidas através delas utilizem os recursos de acordo com suas necessidades e sejam

atendidas o maior número possível de aplicações.

Neste trabalho é mostrado, além do esquema de negociação dinâmica, uma

pequena descrição sobre aplicações multimídia, qualidade de serviço e redes ATM. Isto é

feito porque o esquema de negociação desenvolvido é destinado a aplicações multimídia.

Estas aplicações, necessitam de uma determinada qualidade de serviço. Para transmitir

dados destas aplicações, a rede deve oferecer garantias de qualidade de serviço e uma alta

capacidade de banda passante, características encontradas na tecnologia ATM.

O objetivo deste trabalho é implementar um esquema de negociação dinâmica em

redes ATM para aplicações multimídia distribuídas. Para tanto, é definida uma

arquitetura de negociação de QoS para uma rede ATM, que possui uma camada de

negociação de QoS. A partir daí, é especificado, projetado e implementado o serviço

prestado por esta camada às camadas superiores, que no caso, são as aplicações

multimídia distribuídas. Por enquanto, o único parâmetro de QoS tratado pelo esquema é

o de banda passante. A negociação de banda passante em uma rede ATM se dá através da

reserva e alocação de recursos - no caso, a própria banda passante. Para executar o

esquema em cada nó da rede ATM, é desenvolvido um conjunto de programas que

funcionam como um CAC (Connection Admission Control).

Nos capítulos 2, 3 e 4 é feita uma breve revisão sobre aplicações multimídia,

qualidade de serviço e redes ATM, respectivamente. No capítulo 5 é mostrado o esquema

de negociação que motivou a execução deste trabalho. No capítulo 6 é mostrada a

arquitetura de negociação de QoS para uma rede ATM e a especificação do serviço e do

protocolo da camada de negociação dinâmica de QoS. O capítulo 7 apresenta o projeto e

aspectos de implementação do trabalho. No capítulo 8 é feita uma análise sobre o projeto

e são mostrados os resultados obtidos. Neste capítulo, é apresentada também uma análise

de viabilidade do sistema. No capítulo 9 encontram-se as conclusões e os possíveis

trabalhos futuros.


6

Capítulo 2

Aplicações Multimídia e Requisitos deComunicação

Neste capítulo é feita uma revisão sobre aplicações multimídia e suas características e

sobre as diversas mídias que estão presentes nestas aplicações. São analisados os recursos

computacionais requeridos pelas aplicações multimídia e os requisitos de comunicação

necessários de uma rede para que possa transmitir informações de aplicações deste tipo.

2.1 Introdução

As aplicações multimídia atuais integram vários tipos de mídia: texto, gráficos, imagens,

vídeo e áudio [Fluck95]. Cada tipo de mídia possui características e requisitos de

comunicação diferentes.

Algumas das características de uma aplicação multimídia são [SLC95]: natureza

do tráfego gerado, retardo máximo de transferência, variação estatística do retardo, vazão

média e taxas aceitáveis de erro em bits ou em pacotes de dados.

Uma das principais características é a natureza do tráfego gerado. Podem existir

três tipos de classes de tráfego: tráfego com taxa de bits constante, onde a taxa média é

igual a taxa de pico; tráfego em rajadas, que possui períodos onde as informações são

geradas próximas à taxa de pico, intercalados com períodos nos quais a fonte não produz

tráfego algum; tráfego contínuo com taxa variável, no qual existem variações na taxa de

bits, durante todo o período de transmissão [SLC95].

De acordo com o tipo de informação presente em uma mídia, esta pode ser

definida como discreta ou contínua. Texto, gráfico e imagem são exemplos de mídias

discretas, enquanto que áudio e vídeo são exemplos de mídias contínuas. O termo

multimídia geralmente implica que pelo menos um tipo de mídia discreta esteja associado

com informação de mídias contínuas [Fluck95].

Este capítulo diz respeito não apenas às aplicações multimídia, propriamente

ditas. Ele refere-se a estas aplicações, tendo como base os requisitos de comunicação que

elas necessitam, ao terem suas informações transmitidas através de uma rede. Grande


7

parte da literatura, que fala sobre multimídia, não aborda o aspecto da rede de

transmissão, nem o ambiente distribuído. Devido a isso, este capítulo está baseado,

basicamente, em três referências. Estas referências abordam o assunto multimídia,

principalmente em relação ao aspecto dos requisitos de comunicação. Estas referências

são: [Fluck95], [Lu96] e [SLC95]

2.2 Características das mídias

Cada mídia possui características e necessidades de desempenho distintas. Nesta seção

são mostrados os principais tipos de mídia, suas características e seus requisitos.

Texto

O texto tem sido, historicamente, a principal forma de interação entre

computadores e seres humanos. É também, juntamente com difusões armazenadas e

filmes, a principal forma de comunicação assíncrona (comunicação adiada no tempo)

entre humanos, através de livros, jornais, cartas e mais recentemente correio eletrônico.

A mídia de texto pode ser representada de duas maneiras. Uma como texto não

formatado, onde o número de caracteres disponíveis é limitado e em geral, o tamanho dos

caracteres é fixo e estão disponíveis apenas uma forma e um estilo. A outra forma de

representação é como texto formatado, onde o conjunto de caracteres é mais rico, com

múltiplas fontes, tamanhos e capacidades de formatação [Fluck95].

Na maior parte das aplicações, a mídia de texto caracteriza-se por tráfego em

rajada. Não é tolerante a erros e o retardo máximo de transferência e a variação estatística

do retardo não são características muito relevantes [SLC95].

Gráficos

O formato dos documentos de gráficos possui informações estruturais. Os objetos

podem ser apagados, redesenhados, movidos ou terem seu tamanho alterado. São

formados por objetos tais como linhas, curvas ou círculos. Estes objetos podem ser

removidos, adicionados, movidos, diminuídos ou aumentados. Eles possuem atributos do

tipo espessura, escala de cinza, cor ou padrões de preenchimento [Fluck95].

A mídia gráfica é caracterizada pelo tráfego em rajadas com vazões médias

chegando a algumas dezenas de megabits por segundo. Como em texto, o retardo máximo


8

e a variação estatística do retardo não são muito importantes. A taxa de erros de bits e de

pacote depende do tipo de gráfico e também se foram utilizadas ou não técnicas de

compressão ou compactação. Para gráficos no formato matricial e sem compressão, a taxa

de erros de bits pode ser bem maior que a taxa de erros de pacotes. Para gráficos no

formato vetorial, onde forem utilizadas técnicas de compressão, o erro em um único bit é

intolerável. Um fato importante a ser considerado, em relação a taxa de erros, é saber se o

gráfico será processado apenas pelo olho humano ou também pelo computador [SLC95].

Imagens

São conhecidas também como figuras e não contêm informação estrutural. As

imagens de computador são representadas por mapas de bit (bitmaps). Um mapa de bit

simples é uma matriz espacial de duas dimensões feita de elementos individuais

chamados pixels. Gráficos ou textos podem ser representados ou armazenados como

imagens, sendo convertidos para formato bitmap [Fluck95].

Os requisitos de comunicação da mídia imagem são bem semelhantes daqueles

para mídia gráfica. A mídia imagem também é caracterizada pelo tráfego em rajadas com

vazões médias chegando a algumas dezenas de megabits por segundo. O retardo máximo

e a variação estatística do retardo não são muito importantes. A taxa de erros de bits e de

pacotes depende do tipo de imagem, se foram utilizadas ou não técnicas de compressão

ou compactação, e se a imagem será processada apenas pelo olho humano ou também

pelo computador [SLC95].

Vídeo

Tanto as imagens quanto os gráficos podem ser mostrados em uma tela de

computador como uma sucessão de visões que criam uma impressão de movimento.

Assim, podem ser chamados de imagens em movimento ou também figuras em

movimento e gráficos em movimento ou também animação de computador [Fluck95].

A característica de imagens ou gráficos em movimento é que todas as visões não

são independentes. Elas são correlatas e em geral cada quadro é uma variante do quadro

anterior. Pode-se entender por quadro como sendo uma visão completa e individual da

tela do computador em um determinado instante, parte de uma sucessão de visões

apresentadas. O retardo entre a aparição de dois quadros sucessivos é geralmente

constante e o número de quadros mostrados por segundo é chamado de taxa de quadro.


9

Para que se tenha uma real impressão de movimento, a taxa de quadros deve ser

acima de 16 quadros por segundo (qps). Filmes são mostrados a uma taxa de 24qps.

Padrões da TV americana e japonesa atuais utilizam 30qps, enquanto o padrão europeu

utiliza 25qps. Um dos muitos padrões de TV de alta definição (High-Definition

Television - HDTV), opera a 60qps [Fluck95].

A mídia de vídeo caracteriza-se por gerar um tráfego contínuo com taxa constante.

Mesmo quando for executada alguma técnica de compactação ou compressão e o tráfego

gerado ficar caracterizado como um tráfego com taxas variáveis, o sinal deve ser

reproduzido no destino em uma taxa constante. O retardo de transferência máximo tem

grande importância e a variação estatística do retardo deve ser compensada.

A taxa de erros de bits pode ser maior que a taxa de erros de pacotes. Mesmo a

taxa de erros de pacotes não é tão crítica, pois como a imagem não é estática, devem ser

gerados vários quadros por segundo. A tolerância a taxa de erros é dependente da

utilização de técnicas de compressão ou não, pois quando estas técnicas são utilizadas,

um erro pode se propagar. Em quadros que contenham uma propagação de erro, o erro em

um único bit pode ser intolerável enquanto quadros que não possuam propagação de erro

podem tolerar erros de bits e de pacotes [SLC95].

Existem cinco classes de qualidade para vídeo, são elas: televisão de alta

definição (HDTV), televisão digital com qualidade de estúdio, televisão com qualidade

de difusão, televisão com qualidade VCR (Videocassette Recorder) e qualidade de

videoconferência de baixa velocidade.

Áudio

A mídia de áudio, assim como a mídia de vídeo, caracteriza-se por gerar um

tráfego contínuo com taxa de bit constante. O tráfego gerado, caso não seja utilizada

nenhuma técnica de compactação ou compressão, é do tipo CBR (Constant Bit Rate).

Caso contrário, o tráfego pode ser caracterizado como VBR (Variable Bit Rate) ou até

mesmo como em rajadas, no caso da voz com detecção de silêncio. Mesmo no caso do

tráfego em rajadas, o sinal deve ser reproduzido no destino a uma taxa constante.

A variação estatística do retardo deve ser compensada. A estratégia utilizada pelos

algoritmos de compensação baseia-se fundamentalmente em assegurar uma reserva de

pacotes antes de dar início ao processo de reprodução, introduzindo um retardo inicial a

cada surto de voz [SLC95]. O retardo de transferência máximo é crítico, principalmente


10

no caso de conversações. Os problemas de retardo tornam-se críticos apenas para

aplicações que exigem comunicação interativa em tempo real.

A mídia de áudio tolera uma taxa de erros de bits ou de pacotes relativamente alta,

pois os sinais de áudio possuem um alto grau de redundância. É importante, no entanto,

que os pacotes não sejam muito grandes para não se perder muito tempo no

empacotamento e consequentemente aumentar o retardo de transferência [SLC95].

2.3 Aplicações Multimídia

As aplicações multimídia possuem muitas características em comum com outros tipos de

aplicações, mas também possuem características particulares. Dentre as principais

características específicas podem ser citadas as seguintes [Fluck95]: podem necessitar de

transmissão em tempo real de informação de mídia contínua (áudio e vídeo); o volume de

dados trocados é substancial e muitas vezes considerável, devido a codificação de

informação de mídia contínua; muitas aplicações são inerentemente distribuídas.

As aplicações multimídia podem ser executadas em um sistema multimídia

individual, no modo stand-alone, ou através de uma rede de computadores. Uma

aplicação multimídia local utiliza apenas os recursos presentes no sistema local para

oferecer os serviços multimídia e não faz uso da capacidade de armazenamento remoto.

Exemplos desse tipo de sistema multimídia são: Treinamento individual baseado em

computador (Individual computer-based training - CBT) e Educação individual baseada

em computador (Individual computer-based education - CBE) [Fluck95]. Aplicações

executadas através de uma rede de comunicação são ditas distribuídas. Duas razões

principais para se ter aplicações multimídia distribuídas são:

• Suporte a aplicações naturalmente distribuídas. Aplicações que oferecem serviços

de comunicação à distância, como videoconferência, correio eletrônico multimídia

e transmissão de pacotes de áudio e vídeo para vários nós de uma rede.

• Implementação do modelo cliente-servidor. Para alguns sistemas multimídia, pode

ser mais vantajoso utilizar recursos dos vários sistemas espalhados pela rede.

Como exemplo destes recursos, pode ser citada a capacidade de armazenamento

oferecida por um servidor para que os vários sistemas possam acessá-lo

remotamente.


11

As aplicações multimídia distribuídas podem ser apresentacionais ou

conversacionais. As aplicações apresentacionais fornecem acesso remoto a documentos

multimídia. Estes documentos podem estar armazenados digitalmente em um ou mais

dispositivos de armazenamento de alta capacidade (computadores servidores) e os

usuários podem recuperar a informação multimídia em tempo real de servidores

multimídia através de uma rede de banda larga para os seus dispositivos de apresentação

[HBD96]. As aplicações conversacionais envolvem tipicamente comunicação multimídia

em tempo real. Podem ainda ser classificadas em serviços sob demanda ou de difusão

[VKBG94]. Muitas aplicações possuem aspectos apresentacionais e conversacionais.

2.3.1 Exemplos de Aplicações Multimídia

Alguns exemplos de aplicações multimídia são videoconferência, correio eletrônico

multimídia, vídeo-sob-demanda e filme-sob-demanda. Estas aplicações são mostradas a

seguir.

Videoconferência

A videoconferência tem como principal objetivo proporcionar uma comunicação

de alta velocidade entre parceiros remotos, através da transmissão de áudio e vídeo, para

melhorar o trabalho colaborativo [Lu96]. A videoconferência pode se dar entre duas

partes, como na videofonia, ou entre muitas partes, como na distribuição de vídeo, mas

nas duas formas implica em comunicação bidirecional. As principais características da

videoconferência são as seguintes [Fluck95]:

• Grupos. Envolve pelo menos um grupo de pessoas em uma das localizações. Os

participantes podem tanto estar em um escritório utilizando sistemas desktop

quanto em salas de reuniões, mas em ambos os casos existirão muitas pessoas que

devem aparecer.

• Documentos. Geralmente é necessário que ocorra troca de documentos entre os

participantes. Documentos podem estar na forma de papel, visível em um lugar

tipo quadro-negro ou no formato eletrônico.


12

• Comunicação de grupo. A quantidade de sistemas que podem participar depende

se a conferência é simétrica ou assimétrica. Em uma conferência simétrica, as

contribuições são balanceadas entre todos os participantes. Em conferências

assimétricas, alguns participantes são menos ativos que outros, e pode ser

suportada uma dúzia de participantes.

• Compromisso entre resolução e movimento. Exceto no caso de existirem

documentos, a resolução pode ser de média qualidade.

• Qualidade de som. Este requisito é muito importante em videoconferência, pois a

identificação de quem está falando em um dado momento ajuda os participantes a

identificarem a parte ativa. Uma outra razão desta importância é que o som deve

ter qualidade suficiente para ser amplificado por alto-falantes.

Correio eletrônico multimídia

O correio eletrônico é uma aplicação que permite aos usuários fazer a

composição, troca, leitura, armazenamento, recuperação e manipulação de mensagens de

computador. Estas mensagens são representadas em uma forma digital e manipuladas por

computadores. Uma mensagem multimídia possui uma parte de áudio ou vídeo misturada

com qualquer outro tipo de informação. O correio multimídia apareceu em 1992 com a

adoção do padrão correio multimídia da Internet, chamado MIME (Multipurpose Internet

Mail Extensions).

Em relação ao armazenamento, cada minuto de áudio, com o mais comum e

menos eficiente esquema de codificação, requer 500Kbytes. Sequências de vídeo para

correio multimídia são geralmente de qualidade VCR e, no melhor caso de compressão,

um minuto de vídeo requer 10Mbytes [Fluck95]. Portanto, o tamanho do correio

multimídia deve ser limitado. Sequências de vídeo devem ser extremamente pequenas e

as sequências de áudio devem ser limitadas a poucas dúzias de segundos.

Telemedicina

Aplicação multimídia importante, especialmente em casos de emergência e

localizações remotas. Em telemedicina, todos os dados de pacientes são registrados e


13

armazenados eletronicamente. Instituições e equipamentos médicos são conectados

através de uma rede multimídia. A telemedicina provê as seguintes funções [Lu96]:

• Consulta instantânea com médicos experientes através do uso de áudio e vídeo de

alta qualidade.

• Acesso a registros de pacientes em qualquer lugar e a qualquer momento por

pessoal médico em caso de emergência.

• Acesso a informações em todo o mundo tal como disponibilidade e necessidade

de um tipo especial de sangue ou órgãos.

Vídeo-sob-demanda

O termo vídeo-sob-demanda, abreviado como VOD (Video-on-demand), engloba

uma grande quantidade de aplicações onde os usuários podem requisitar o acesso a

servidores de vídeo de imagens estáticas ou em movimento. Algumas características deste

tipo de aplicação são citadas a seguir [Fluck95].

• Vídeo-sob-demanda não diz respeito apenas a vídeo em movimento, também

engloba a demanda a imagens estáticas.

• A definição não especifica onde o servidor está localizado nem quem o opera.

VOD pode ser um serviço corporativo provido em um site dentro de uma

organização, bem como pode ser um serviço público.

• A definição não especifica o nível de interação que o usuário pode se beneficiar,

uma vez que a sessão esteja estabelecida.

• VOD não implica em qualquer tipo específico de vídeo em movimento. Apesar do

principal campo de aplicação ser a distribuição de filmes, aplicações de VOD

cobrem todo tipo de sequências de vídeo.


14

• A definição diz que o usuário pode requisitar uma imagem ou figura em

movimento a qualquer tempo, mas ela não diz que o usuário pode vê-la a qualquer

tempo.

Filme-sob-demanda

Filme-sob-demanda, abreviado como MOD (Movie-on-demand), é um serviço

público de vídeo-sob-demanda oferecido a usuários residenciais ou clientes de hotéis,

onde o objeto acessado é um filme armazenado [Fluck95]. O objetivo do MOD é

substituir dois serviços convencionais com um produto melhorado.

• O serviço pay-per-view (PPV). A melhoria seria o fato de se oferecer uma maior

quantidade de filmes que possam ser escolhidos e que o usuário possa requisitar e

assistir a qualquer momento.

• O serviço de aluguel de fita de vídeo. A idéia é eliminar a busca e retorno da fita a

locadora, eliminando a manipulação física da fita.

Para filme-sob-demanda, uma qualidade equivalente a de videocassete VHS,

requer uma taxa de transmissão de apenas 1,5Mbps, o que é compatível com a velocidade

T1. Implementações existentes do padrão de compressão de vídeo MPEG-2 (Motion

Picture Expert Group) operam a 6Mbps com uma qualidade ligeiramente superior a

qualidade de TV de difusão. É esperado que se consiga uma taxa na ordem de 4Mbps

para este tipo de qualidade. Muitos operadores estão planejando canais de 6 ou 7Mbps

para suas infra-estruturas. Várias técnicas de compressão podem ser usadas para TV

digital com qualidade de difusão, mas o padrão MPEG-2 tem surgido como uma

tecnologia geral, multi-vendedor [Fluck95].

As aplicações multimídia distribuídas constituem o enfoque deste trabalho.

Dentro deste tipo de aplicação, o sistema desenvolvido no trabalho tem como objetivo

atender aplicações do tipo vídeo-sob-demanda.

2.4 Requisitos de Comunicação


15

Aplicações multimídia são caracterizadas por manipular mídia contínua e suportar uma

variedade de mídias e seus relacionamentos temporais. Isto impõe novos requisitos aos

sistemas de comunicação e sistemas-fim [HBD96].

As informações das aplicações distribuídas devem ser transmitidas através de uma

rede. Para cada tipo de mídia existem requisitos de comunicação específicos. Para que

uma sub-rede de comunicação possa transmitir dados de aplicações multimídia em tempo

real e mídia contínua, ela deve disponibilizar alguns características de desempenho. As

principais destes características são [Fluck95] [Lu96]:

• Vazão. Quantidade de bits que a rede é capaz de transmitir em um determinado

período de tempo. Algumas aplicações necessitam de uma capacidade de

armazenamento e de banda passante muito grande, como mostra a tabela 2.1.

• Retardo. Tempo gasto para a emissão do primeiro bit de um bloco de dados pelo

transmissor e sua recepção pelo receptor. Um valor aceitável de retardo é

dependente da aplicação. Áudio e vídeo digital são mídias contínuas dependentes

do tempo, conhecidas como dinâmicas ou isócronas. Para que a apresentação

destas mídias tenha uma qualidade razoável, as amostras de áudio e vídeo devem

ser recebidas e apresentadas em intervalos regulares.

• Variação do retardo. Variação no tempo do retardo de transmissão da rede. É um

dos principais parâmetros para suportar mídias dependentes do tempo. Para uma

boa apresentação de mídias contínuas, a variação do retardo deve ser muito

pequena. Os requisitos de retardo e variação do retardo devem ser garantidos

durante toda a sessão de comunicação. Grande parte das redes, protocolos de

transporte, sistemas operacionais e escalonamento de discos atuais não fornecem

tal garantia. Portanto, os hospedeiros e organização das redes atuais não são

apropriados para aplicações multimídia.

• Taxa de erros. Parâmetro que mede a capacidade da rede em termos de alteração,

perda, duplicação ou entrega fora de ordem, dos dados. Em dados de áudio e

vídeo pode-se tolerar algum erro ou perda, pois estes podem passar despercebidos

pelo usuário. Quando são utilizadas técnicas de compressão, a taxa de erros

permitida é menor, pois um erro em um bit pode causar erro de descompressão de

muitos bits. Um outro parâmetro de medida de erro é a taxa de perda de pacote. O


16

requisito para taxa de erros de pacote é mais rigoroso que para taxa de erros de bit,

pois a perda de pacotes pode afetar a decodificação de uma imagem.

Aplicações Taxa de Dados (kbits/s)

Telefone digital 64

Rádio digital 1.024

Áudio-CD 1.411,2

DAT 1.536

Vídeo qualidade VHS 54.000

Vídeo qualidade TV 216.000

HDTV 864.000

Tabela 2.1 - Taxas de Bits de Aplicações de Áudio e Vídeo

Para suporte a aplicações de recuperação e de distribuição, os principais critérios

exigidos de uma rede são: capacidade para comunicação de grupo e capacidade para fazer

cache de documentos [Fluck95].

• Capacidade de comunicação de grupo. Capacidade da rede para replicar, em certos

pontos internos, os dados emitidos por uma fonte. Dados replicados devem ser

passados a frente para os receptores-fim, que são parte do grupo. Esta capacidade

é desenvolvida para evitar ou minimizar que segmentos das redes sejam

atravessados por múltiplas cópias dos mesmos dados.

• Capacidade para fazer cache de documentos. Consiste, para o sistema local

envolvido, em aguardar solicitações do usuário, atendê-las e manter uma cópia de

parte específica da informação solicitada. Algoritmos apropriados mantêm apenas

o sub-conjunto das partes que possuem a maior probabilidade de serem solicitadas

pelos sistemas locais.

Em relação às redes de comunicação, existem ainda duas características

importantes no transporte de dados de aplicações multimídia. Estas características são:

isocronismo e qualidade de serviço (QoS).

Para o suporte a aplicações multimídia utilizando transmissão em tempo real, uma

característica particularmente importante é a de isocronismo. O termo isocronismo refere-


17

se ao processo onde os dados devem ser entregues dentro de certos limites de tempo. Por

exemplo, streams multimídia requerem um mecanismo de transporte isócrono para

assegurar que os dados sejam entregues tão rápido quanto eles são apresentados e

assegurar que o áudio seja sincronizado com o vídeo.

Aplicações isócronas, ou sensíveis ao tempo, tais como vídeo, requerem muita

banda passante e baixo retardo fim-a-fim [Miller94]. Uma conexão de rede fim-a-fim é

dita isócrona se a taxa de bits da conexão é garantida e se o valor da variação do retardo é

também garantido e pequeno. Aplicações multimídia distribuídas são isócronas por

natureza e portanto, possuem limitações de tempo.

A outra característica de rede importante, é a de Qualidade de Serviço (QoS).

Dados multimídia requerem diversos requisitos de qualidade dos sistemas multimídia.

Estes requisitos, dependendo da aplicação, muitas vezes são ditos rigorosos. O conceito

de QoS é baseado no fato de que, nem todas as aplicações, necessitam do mesmo

desempenho da rede pela qual estão trafegando. As aplicações podem indicar os seus

requisitos específicos para a rede, antes de realmente ser iniciada a transmissão dos

dados. QoS é uma medida de quão bom é um serviço, como apresentado para o usuário. É

expressa em uma linguagem compreensível pelo usuário e manifesta, através de uma

quantidade de parâmetros, valores subjetivos e objetivos.

Portanto, para que informações de aplicações multimídia possam ser transmitidas

através de uma rede, com uma qualidade aceitável para o usuário, a rede deve atender, de

maneira satisfatória, e de acordo com cada mídia, os seguintes requisitos: vazão, retardo,

variação do retardo, taxa de erros, capacidade de comunicação de grupo, capacidade para

fazer cache de documentos, isocronismo e garantias de QoS.

2.5 Sistemas Multimídia

Um sistema multimídia oferece uma função ou um conjunto de funções particulares a

uma aplicação multimídia. Uma aplicação multimídia é o uso específico, por um usuário

ou grupo de usuários, de um dado sistema multimídia. Um exemplo de sistema

multimídia é uma estação de trabalho equipada com dispositivos de áudio e vídeo. Um

exemplo de função, ou aplicação multimídia, é uma videoconferência [Fluck95].

Os sistemas multimídia distribuídos podem ser classificados em um número de

classes. O ITU (International Telecommunications Union) identifica quatro classes

básicas de serviços ou aplicações distribuídas. Estas quatro classes são [Lu96]:


18

• Serviços coversacionais. Implicam a interação entre um usuário humano e outro

usuário humano ou sistema. Esta classe inclui serviços interpessoais, como

videoconferência e videofonia. Inclui também serviços como televigilância e

telecompras.

• Serviços de mensagens. Cobrem a troca de dados multimídia que não são de

tempo real ou assíncronos, através de caixas de correio eletrônico.

• Serviços de recuperação. Cobre todos os tipo de acesso a servidores de

informação multimídia. Tipicamente, o usuário envia um pedido para o servidor e

a informação solicitada é entregue ao usuário em tempo real. Vídeo-sob-demanda

é um exemplo deste serviço.

• Serviços de distribuição. Cobrem serviços onde a informação é distribuída por

iniciativa de um servidor. Um exemplo deste serviço é uma difusão de programa

de TV.

Existem alguns objetivos que um sistema multimídia deve atender. Estes

objetivos são [Lu96]:

• O sistema deve ter recursos suficientes para suportar aplicações multimídia. Cada

subsistema deve ter tipos e quantidade de recursos para suportar múltiplas

aplicações simultaneamente. Um sistema-fim deve estar apto a processar múltiplas

aplicações. Redes, servidores e dispositivos de armazenamento devem estar aptos

a suportar um número de sessões ou fluxos simultaneamente.

• O sistema deve estar apto a utilizar os recursos disponíveis de maneira eficiente.

Os recursos de uma sistema são compartilhados por várias aplicações. Estes

recursos devem ser compartilhados de uma maneira eficiente, tal que um número

máximo de aplicações possa ser suportado com uma determinada quantidade de

recursos.


19

• O sistema deve estar apto a garantir os requisitos de QoS das aplicações. Os

recursos devem ser compartilhados eficientemente pelas diversas aplicações, e

estas aplicações devem conseguir a qualidade de serviço requisitada. Portanto, um

importante desafio para os sistemas multimídia é usar os recursos de uma maneira

eficiente e ao mesmo tempo garantir a QoS para cada aplicação.

• O sistema deve ser escalável. Uma arquitetura de comunicação deve ser escalável

e extensível para conseguir fornecer aumento nos requisitos dos usuários e atender

novas demandas. A escalabilidade refere-se a habilidade do sistema em adaptar-se

a mudanças no número de usuários a serem suportados e a quantidade de

informação a ser armazenada e processada.

A partir desta análise, pode-se concluir portanto que, os sistemas de computação e

comunicação multimídia devem suportar e prover o seguinte: compressão de dados para

reduzir a demanda por espaço de armazenamento e banda de transmissão; um sistema

operacional, protocolo de transporte e escalonador de disco direcionados para multimídia,

que forneçam as garantias de retardo e variação de retardo apropriadas; estações de

trabalho de alto desempenho e redes de alta velocidade para manipular altas taxas de bits

sob limitações de tempo; e mecanismos globais de especificação e garantia de QoS

[Lu96].

2.6 Resumo do Capítulo

Neste capítulo foram analisados os diversos tipos de mídia existentes em um sistema

multimídia. Dentre as mídias apresentadas podemos citar texto, gráficos, imagens, vídeo

e áudio. Para cada tipo de mídia foram mostradas suas características principais e os

requisitos de comunicação exigidos por cada uma.

Foram apresentados também os sistemas multimídia e as aplicações multimídia,

descrevendo o que são e mostrando suas principais características. As aplicações

multimídia podem ser executadas de forma individual ou através de uma rede de

computadores, as quais são chamadas aplicações distribuídas. Como exemplos de

aplicações multimídia foram mostrados videoconferência, correio eletrônico multimídia,

vídeo-sob-demanda e filme-sob-demanda. O enfoque deste trabalho são as aplicações

multimídia distribuídas, dentre as quais a aplicação tomada como base foi a de vídeo-sob-

demanda.


20

Depois foram discutidos os requisitos de comunicação, necessários a uma rede,

para transmitir informações de aplicações multimídia. Os principais destes requisitos são

vazão, retardo, variação do retardo e taxa de erros. Para suporte a aplicações de

recuperação e de distribuição, é necessário que uma rede possua capacidade de

comunicação de grupo e de fazer cache de documentos. Outras duas funções de rede

importantes são isocronismo, principalmente para transmissão de tempo real, e garantia

de qualidade de serviço.

Capítulo 3

Qualidade de Serviço


21

Neste capítulo são mostrados alguns conceitos que estão envolvidos na definição de

qualidade de serviço (QoS). São descritas as funções de gerenciamento de QoS e, dentre

estas funções, são destacadas as de negociação e renegociação de QoS.

3.1 Introdução

O conceito de qualidade de serviço, no que tange as redes de comunicação, deriva do fato

de que, nem todas as aplicações transmitidas em uma rede, possuem os mesmos

requisitos de desempenho. Assim, cada aplicação, antes de iniciar uma transmissão, pode

indicar quais os parâmetros de qualidade que atendem às suas necessidades.

A qualidade de serviço (QoS) pode ser descrita sob vários pontos de vista. Para

pesquisadores trabalhando com codificação de vídeo, QoS é uma medida subjetiva da

qualidade do canal. Outros podem ver QoS como uma necessidade das redes fornecerem

limites de desempenho e ainda outros podem ver QoS em termos de disponibilidade da

rede na presença de falha [Jung96].

Para o usuário da aplicação, QoS é vista como um conjunto de características,

como por exemplo, a qualidade da imagem em termos de nitidez ou a qualidade do áudio.

Para a rede, essas características são traduzidas para um conjunto de parâmetros, como

banda passante necessária para transmissão das informações, retardo máximo permitido e

taxa de erros aceitável pelo tipo de informação sendo transmitida.

De acordo com [VKBG94], qualidade de serviço, para um sistema distribuído,

pode ser definida como: “O conjunto das características qualitativas e quantitativas de um

sistema multimídia distribuído, necessárias para alcançar a funcionalidade necessária de

uma aplicação”.

Uma definição que considera o ponto de vista tanto da aplicação quanto do

sistema é dada em [Lu96], na qual “QoS é uma especificação qualitativa e quantitativa de

uma necessidade da aplicação, que um sistema multimídia deve satisfazer para obter a

qualidade desejada para a aplicação”. Tendo como base esta definição, existem dois

aspectos de QoS: as aplicações especificam os requisitos de QoS e os sistemas fornecem

garantias de QoS.

A noção de QoS foi utilizada inicialmente em comunicações de dados para

caracterizar o desempenho de transmissão de dados em relação a confiabilidade, retardo e

vazão [Lu96]. Os parâmetros de QoS dos sistemas atuais, como OSI (Open Systems

Interconnection) e ITU (International Telecommunication Union), permitem a


22

especificação de alguns requisitos de usuário. Estes requisitos, no entanto, quase nunca

são suportados pelas redes.

No modelo de referência OSI os parâmetros de QoS são classificados em dois

grupos principais: o grupo de parâmetros orientados a desempenho e o grupo de

parâmetros não orientados a desempenho [CCG+93]. Este modelo tem um número de

parâmetros que descrevem a velocidade e confiabilidade de uma transmissão. Alguns

destes parâmetros são vazão, retardo de transmissão, taxa de erros e probabilidade de

falha no estabelecimento de conexão. Estes parâmetros não atendem a todas os requisitos

de qualidade de uma comunicação multimídia e são utilizados apenas no nível de

transporte. Para comunicações multimídia, a QoS deve ser especificada e garantida fim-a-

fim, em todos os níveis. Portanto, as aplicações multimídia necessitam de um novo

modelo de QoS [Lu96].

O ITU-T define QoS como “O efeito coletivo do desempenho de um serviço, o

qual determina o grau de satisfação de um usuário do serviço” [ISO92]. O próprio ITU

reconheceu a necessidade de permitir a configuração de QoS em redes ATM

(Asynchronous Transfer Mode) e, para tanto, definiu um conjunto de parâmetros. O

conceito de QoS em redes ATM é aplicado a três níveis de controle: nível de controle de

camada, nível de conexão e nível de controle de célula.

Para que uma arquitetura forneça garantias de QoS é necessário que ela possua os

seguintes elementos [Lu96]:

• Um mecanismo de especificação de QoS para que as aplicações definam seus

requisitos;

• Controle de admissão para determinar se uma nova aplicação deve ser admitida

sem afetar a QoS de outras aplicações já existentes;

• Um processo de negociação de QoS tal que possa ser atendido o maior número

possível de aplicações;

• Alocação e escalonamento de recursos para alcançar o requisito de QoS das

aplicações aceitas;

• Policiamento de tráfego para garantir que as aplicações gerem dados de acordo

com a quantidade especificada na negociação.


23

Os elementos citados acima são fundamentais para que seja oferecida uma

garantia de QoS. Juntamente com estes elementos, podem ser citados outros três

elementos necessários para alcançar requisitos de qualidade de aplicações multimídia.

Estes outros elementos são: um mecanismo de renegociação de QoS, para que as

aplicações possam mudar os valores acordados na especificação inicial; a QoS fornecida

às conexões existentes deve ser monitorada para que seja tomada alguma atitude no caso

de violação da QoS garantida; e finalmente, devem ser utilizadas técnicas de

escalabilidade e de degradação graciosa da QoS para prover serviços satisfatórios às

aplicações multimídia.

A qualidade de serviço conseguida por um usuário depende de todos os

componentes envolvidos em um sistema: o sistema operacional, o sistema de transporte

(por exemplo, uma ligação lenta diminui a vazão) ou a aplicação (por exemplo, o banco

de dados possui apenas imagens de baixa qualidade) [VKBG94].

Para a transmissão de informações de aplicações multimídia, em particular mídia

contínua, é essencial que a qualidade de serviço seja garantida em todo o sistema,

incluindo a plataforma de sistema distribuído, o sistema operacional, os dispositivos dos

sistemas-fim, o sub-sistema de comunicação, o protocolo de transporte e a rede. É

necessário também que o protocolo tenha suporte a negociação de QoS fim-a-fim,

renegociação, indicação de degradações de QoS e coordenação sobre as múltiplas

conexões relacionadas [CCG+93] [ACH98].

As garantias de QoS fim-a-fim só podem ser alcançadas quando todos os

subsistemas do sistema de comunicação fornecerem garantias de QoS em seus níveis

locais. Estes subsistemas incluem redes, protocolos de transporte, arquitetura do sistema-

fim e um servidor multimídia [Lu96].

As diversas aplicações multimídia possuem diferentes características e cada

aplicação necessita de qualidades de serviço diferentes. Como exemplo, podem ser

citadas algumas aplicações em conjunto com suas necessidades [DG94]:

• Vídeo Compactado. Aplicação com taxa de bits variável, que requer um baixo

retardo para um serviço interativo. Existe um requisito para sincronização de

fluxos de áudio e vídeo relacionados ou objetos de texto. A tolerância de erro e

perda depende da aplicação.


24

• Áudio não compactado de alta fidelidade. Aplicação com taxa de bits constante,

sensível a perda de dados.

• Transmissão de voz digital. Serviço interativo que requer baixo retardo. Se não

houver compressão da voz digital, a transmissão terá uma taxa de bits constante

com a presença de pausas (o serviço pára em alguns instantes e depois continua).

Erro ou perda de dados são aceitáveis, mas podem causar problemas.

3.2 Funções de Gerenciamento de QoS

Existem três níveis de garantia de qualidade de serviço. Estes níveis são: garantia

determinística, estatística e best-effort [HBD96] [Lu96]. Algumas características destes

tipos de garantia são discutidas a seguir.

• Garantia determinística. Também conhecida como garantia forte. Neste tipo de

garantia, a qualidade especificada pelo usuário deve ser atendida sempre. É

fornecido um limite para cada parâmetro e este limite deve ser atendido em 100%

dos casos. Os recursos normalmente são reservados para a aplicação com base no

pior caso e mesmo que os recursos não estejam sendo usados em um determinado

momento, eles não podem ser alocados para outras conexões. Por esta razão, este

tipo de garantia é mais cara em termos de recursos dos sistemas.

• Garantia estatística. Também conhecida como garantia fraca. Neste tipo de

garantia, a qualidade especificada pelo usuário deve ser atendida apenas para uma

certa percentagem especificada. É dado um valor para cada parâmetro e é então

garantido que apenas uma parte das conexões será atendida tendo como limite o

valor determinado. Este tipo de garantia utiliza os recursos dos sistemas de uma

maneira mais eficiente, pois a utilização dos recursos é baseada em multiplexação

estatística, onde os recursos não utilizados por uma aplicação podem ser utilizados

por outras aplicações. É difícil de implementar devido à natureza dinâmica do

tráfego e da utilização de recursos das aplicações.

• Best Effort. É baseada na não garantia ou em garantia parcial. Não provê nenhuma

garantia e a aplicação é executada com a quantidade de recursos que estiver


25

disponível. A maioria dos sistemas de computação atuais operam desta maneira,

sobretudo os que utilizam a Internet.

São utilizados diferentes tipos de garantia para diferentes tipos de tráfego. Em

alguns casos, uma conexão pode usar diferentes níveis de garantia para diferentes

parâmetros de QoS [Lu96].

Quando uma conexão é solicitada, o provedor do serviço deve estabelecer uma

sessão com a QoS desejada, controlar essa sessão durante sua fase ativa e terminar a

sessão quando for solicitado por um dos usuários ou devido a problemas no provedor do

serviço, como por exemplo, congestionamento da rede. Para que os requisitos de QoS das

aplicações multimídia sejam atendidos, as fases de estabelecimento, manutenção e

finalização de uma sessão devem possuir funções de gerenciamento [HBK+95].

As funções de gerenciamento de QoS normalmente são distribuídas através dos

diversos componentes do sistema e envolvem a reserva de recursos nesses componentes

[HBK+95]. As funções de gerenciamento mostradas na tabela 3.1 são descritas em

seguida.

Fases Funções de gerenciamento de QoS

Especificação da QoS

Mapeamento da QoS

Estabelecimento Negociação da QoS

Reserva de Recurso

Contabilização da QoS

Monitoração da QoS

Renegociação da QoS

Alocação Dinâmica de Recurso

Manutenção Policiamento da Fonte

Adaptação da QoS


26

Contabilização da QoS

Mapeamento da QoS

Finalização Finalização da QoS

Tabela 3.1 - Fases de uma aplicação e suas respectivas funções de gerenciamento de

QoS

1. Especificação e mapeamento de QoS. Funções de mapeamento são necessárias para

fazer a tradução entre os parâmetros de QoS externos, vistos pelo usuário, e os

parâmetros internos, vistos pelo sistema (vazão, retardo, variação do retardo).

2. Negociação de QoS e reserva de recurso. Permite encontrar uma configuração de

sistema que atenda aos requisitos de QoS do usuário. No caso da negociação ser aceita,

e os componentes suportarem um nível de QoS específico, cada componente deve

dedicar recursos para suportar a QoS desejada.

3. Monitoração de QoS e policiamento da fonte. Permite fazer uma análise constante da

QoS fornecida por todo o sistema e/ou por cada componente do sistema. Essa

atividade envolve as funções de detectar e notificar qualquer violação da QoS e

armazenar informação.

4. Adaptação da QoS. Oferece alternativas de configuração para os casos em que os

parâmetros de usuário não são aceitos no processo de negociação. No caso de haver

mudanças no ambiente, o processo de adaptação deve fornecer uma degradação suave

ao serviço. Em muitas situações pode ser preferível degradar um pouco a qualidade do

serviço, violando os parâmetros de QoS negociados, a finalizá-lo.

5. Renegociação da QoS. O processo de renegociação pode ser iniciado pelo usuário ou

pelo sistema de comunicação. A renegociação iniciada pelo usuário, permite que este

solicite uma melhor qualidade para o seu serviço, ou a degradação do mesmo com o

objetivo de baixar o custo. Por outro lado, a renegociação iniciada pelo sistema de

comunicação, ocorre geralmente devido a falta de recursos (como, por exemplo,

congestionamento na rede) e tem o objetivo de reduzir a qualidade oferecida, para que

os serviços não sejam interrompidos. Esse processo será iniciado quando o processo de

adaptação automática não tiver sucesso.


27

6. Contabilização da QoS. A contabilização determina o custo efetivo de um serviço

requisitado por um usuário. A contabilização de QoS é uma atividade complexa,

devido a grande variedade de QoS requisitada pelas aplicações multimídia

distribuídas. A contabilização de QoS deve ser baseada pelo menos no valor de QoS

requisitado pelo usuário, senão todos os usuários exigirão a melhor QoS para todas as

aplicações.

7. Finalização da QoS. Quando uma aplicação finaliza, todos os componentes que lhe

fornecem QoS, devem liberar seus recursos reservados e, para tanto, estes

componentes devem receber notificações quando as aplicações são finalizadas.

Dentre as funções de gerenciamento de qualidade de serviço descritas acima, as de

maior importância para este trabalho são as funções de negociação e renegociação.

3.3 Negociação de QoS

Em um sistema de computação, a qualidade de serviço pode ser negociada entre os

diversos participantes de uma comunicação. Em um serviço orientado a conexão com

ligação ponto-a-ponto, os participantes da negociação são o usuário que inicia a conexão,

o usuário destino daquela conexão e o serviço provedor da comunicação. Todas as

negociações são baseadas nas primitivas request, indication, response e confirm [DG94].

Quando um serviço multimídia é oferecido em um sistema distribuído, a

negociação com o usuário é feita através da execução de um protocolo de negociação

envolvendo os diferentes componentes do sistema. De acordo com o número de usuários

participantes, existem três tipos de negociação: unilateral, bilateral e triangular [DG94].

Na negociação triangular (figura 3.1) o usuário solicitante do serviço sugere um

valor para o parâmetro de QoS na primitiva request (valor sugerido). O valor sugerido

pode ser diminuído pelo provedor do serviço antes de ser passado ao usuário destino na

primitiva indication. O usuário destino pode também diminuir o valor do parâmetro e

retorná-lo na primitiva response. O provedor do serviço passa então esse valor, sem

alterá-lo, para o usuário de origem na primitiva confirm. Esse valor é considerado o valor

do parâmetro de QoS selecionado [DG94].


28

Request Indication Response Confirm

QoS_req

QoS_ind

QoS_resp QoS_conf

Usuário Chamador Usuário Chamado

Val

or d

o pa

râm

etro

de

QoS

Figura 3.1 - Negociação Triangular

A negociação bilateral é executada apenas entre os dois usuários do serviço e o

provedor do serviço não pode modificar os valores dos parâmetros propostos.

Na negociação unilateral nem o provedor do serviço nem o usuário destino podem

modificar o valor do parâmetro de QoS requisitado pelo usuário solicitante.

3.3.1 Passos da negociação

Em um processo de negociação de qualidade de serviço podem ser destacados três passos

principais [HBK+95]:

1. Definição dos requisitos do usuário. O usuário é o principal agente no processo de

negociação da qualidade de serviço, que acontece no estabelecimento de uma conexão

ou no processo de renegociação. Os requisitos de QoS são primeiramente definidos em

parâmetros a nível de usuário, os quais devem posteriormente ser traduzidos para

parâmetros internos correspondentes.

2. Seleção de uma configuração funcional. Nesse passo deve ser feita a escolha de uma

configuração funcional apropriada, dentre as possíveis configurações que podem ser

consideradas, com base no serviço requisitado e nos parâmetros QoS especificados.

3. Seleção de uma configuração física. As principais fases desse processo de seleção são:

alocação funcional para componentes do sistema físico, refinamento da configuração

funcional, otimização das alocações de recursos e comprometimento de recursos.


29

3.3.2 Componentes do sistema envolvidos na negociação deQoS

Para que um sistema de computação ofereça o serviço de negociação de QoS, é

necessário que vários componentes do sistema estejam envolvidos no processo. Alguns

destes componentes são a rede de alta velocidade, o protocolo de transporte, o dispositivo

de apresentação e o servidor multimídia. Estes componentes são descritos a seguir.

1. Rede de alta velocidade. Para suportar a transferência de aplicações multimídia, as

redes de comunicação devem ser capazes de transferir vários tipos de mídias com

diferentes QoS. Essa rede deve ser capaz de suportar taxas de transferência constantes

e variáveis, transportar informações com diferentes taxas de transmissão (variando de

dezenas de bits por segundo a milhões de bits por segundo), suportar serviços de

comunicação de grupo e de difusão, transmitir informações de mídias diferentes da

mesma maneira (sem fazer distinção em relação a natureza da informação) e suportar

mecanismos de gerenciamento de banda passante.

Alguns parâmetros de QoS, básicos para a transmissão de aplicações

multimídia, devem ser oferecidos na interface de rede. Esses parâmetros são:

− Retardo. Retardo introduzido pelo componente de rede para transportar uma

unidade de dados da informação a ser transmitida. É contabilizado a partir da

interface fonte de transmissão até a interface destino.

− Confiabilidade. Indica se o serviço é confiável ou não. Em caso de um serviço não

confiável, deve ser indicado um valor para a taxa de perda.

− Variação do retardo. Diferença entre o retardo mínimo e o retardo máximo.

− Vazão. Quantidade de unidades de dados transferidas em um determinado período

de tempo.

− Tipo de garantia. Permite especificar se parâmetros como vazão, retardo e

variação do retardo são suportados com alguma garantia ou pelo melhor esforço.

− Custo. Custo que a rede cobra de seus clientes. Pode ser expresso em termos de

tempo de utilização ou unidades de dados transferidas, ou ainda uma combinação

dos dois.

2. Protocolo de transporte. A execução dos protocolos de comunicação podem introduzir

retardo e variação do retardo na transmissão. Para suportar a QoS requerida por uma


30

aplicação, é necessária uma garantia da velocidade de execução do protocolo de

transporte. Portanto, os parâmetros de vazão, retardo e variação do retardo devem ser

limitados no nível de transporte. Os parâmetros de QoS para a interface do protocolo

de transporte são os mesmos para a interface de rede.

3. Dispositivo de apresentação. A atividade de passar os dados de uma aplicação

multimídia para o dispositivo de apresentação pode introduzir diferentes valores de

retardo e variação do retardo. Dessa maneira, o dispositivo utilizado deve fornecer

garantias para suportar o retardo e a variação do retardo solicitados.

4. Servidor multimídia. Fornece armazenamento confiável e coerente de documentos

multimídia, bem como acesso concorrente a esses documentos e seus componentes. O

servidor de banco de dados está presente no processo de negociação de QoS para

fornecer informação sobre sua condição de satisfazer o nível de QoS requisitado.

3.4 Renegociação

As comunicações multimídia normalmente não possuem um comportamento estático e,

durante uma sessão ativa, necessitam alterar os parâmetros de QoS que foram negociados

no início da transmissão, no processo de admissão da conexão. A mudança nos

parâmetros de QoS pode se dar por várias razões. Algumas destas razões são [Lu96]: o

usuário inicialmente requisitou uma sessão com uma alta qualidade e durante esta sessão

ele deseja diminuir a qualidade devido ao custo; o usuário requisitou inicialmente uma

baixa qualidade para um canal de vídeo e, durante a transmissão, decide aumentar a

qualidade; o usuário solicitou no início da transmissão uma sessão com um canal de

vídeo e um canal de áudio e durante o processo de comunicação é necessário um canal

extra para acessar um banco de dados multimídia.

Portanto, é necessário prover mecanismos de renegociação de QoS para atender a

mudanças nos parâmetros de qualidade acordados no início da transmissão. Algumas

vezes pode não ser possível aumentar a qualidade atual, pois em um determinado

momento o sistema pode não possuir recursos disponíveis.

A função de renegociação permite alterar os parâmetros de QoS estabelecidos na

fase de negociação. Essa alteração possibilita que aplicações que não possuam uma QoS

constante durante seu tempo de execução possam alterar seus requisitos, liberando


31

recursos no momento em que estejam excedentes ou alocando mais recursos quando

necessário.

A alocação de recursos na fase de estabelecimento de conexão pode resultar em

um uso ineficiente da rede e/ou degradar a QoS das conexões. Para tráfego CBR, a

alocação estática é apropriada, mas para tráfego com taxa de bits variável, a alocação

estática de banda pode causar desperdício da banda passante. Em um esquema de

alocação dinâmica de recursos, a aplicação pode informar a rede quando necessitar de

mais recursos ou quando puder liberar recursos. A rede pode então aceitar ou rejeitar (no

caso de mais recursos) o pedido de renegociação. Com um esquema de renegociação

pode-se previnir congestionamento na rede e também permitir que a rede otimize a

utilização de recursos e alcance os requisitos de QoS necessários [Kidam96].

A maior motivação para negociação dinâmica de QoS é explorar o

comportamento dinâmico de conexões multimídia, para melhorar a utilização de recursos

e consequentemente, aumentar o número de conexões suportadas por um nó [GNN97].

Uma desvantagem do esquema de renegociação é a complexidade de

implementação. Este esquema requer a utilização de primitivas extras para sinalização. A

inserção de um retardo de renegociação por rajada (alteração nos requisitos de banda

passante) aumenta o retardo fim-a-fim [Kidam96].

O objetivo deste trabalho é fornecer um serviço de negociação dinâmica de QoS a

aplicações multimídia. Este serviço está baseado no esquema apresentado em [GNN97] e

é direcionado para transmissão de informações através de uma rede ATM (Asynchronous

Transfer Mode). A princípio, o esquema foi desenvolvido para a negociação de apenas

um parâmetro de qualidade de serviço, o de banda passante.

O serviço de alocação dinâmica de banda passante permite que aplicações

multimídia possam requisitar e liberar banda dinamicamente. Para oferecer este serviço,

foi especificada e implementada uma camada de negociação de QoS. Se uma aplicação

precisar de mais banda para transmitir suas informações através da rede, esta aplicação

solicita a camada de negociação dinâmica o valor de banda necessário. A camada, através

do seu protocolo, verifica se o pedido pode ser aceito ou não. Se a aplicação tiver

recursos a mais e puder liberá-los em um dado momento, ela solicita a camada que libere

seus recursos excedentes. Esses recursos liberados podem ser utilizados para aceitar

novos pedidos de renegociação de outras aplicações ou até novos pedidos de conexão.

O protocolo de negociação garante a alocação de um valor mínimo de banda

passante para cada conexão. Este valor é especificado no estabelecimento da conexão. Os

pedidos de renegociação têm prioridade sobre os pedidos de estabelecimento de novas


32

conexões, o que garante qualidade às conexões aceitas. A camada de negociação de QoS,

juntamente com seu serviço e protocolo, é detalhada no capítulo 5.


Neste capítulo foram mostrados alguns conceitos de Qualidade de Serviço (QoS),

sob o ponto de vista do usuário e da rede de comunicação de dados. Foram mostrados

também os elementos que uma arquitetura deve possuir para fornecer garantias de QoS.

Foram descritos os três níveis de garantias de QoS (determinístico, estatístico e

best effort) e as funções de gerenciamento de QoS. Dentre estas funções foram destacadas

as funções de negociação e renegociação. No contexto da definição de negociação de QoS

foram mostrados os passos da negociação e os componentes do sistema envolvidos nesta

negociação.

O objetivo do trabalho é fornecer um esquema de negociação dinâmica de banda

passante, para aplicações multimídia, em uma rede ATM. Este esquema foi desenvolvido

através da implementação de uma camada de negociação de QoS, que oferece um serviço

de alocação dinâmica de banda passante. A especificação da camada de QoS é mostrada

no capítulo 6.


33

Capítulo 4

Redes ATM para Transmissão de Aplicações

Multimídia com Garantias de QoS

Neste capítulo são analisadas algumas tecnologias de redes existentes atualmente. A

análise é feita em relação a adequação destas tecnologias para transmissão de dados de

aplicações multimídia. Após esta análise, é mostrada a tecnologia de rede ATM

(Asynchronous Transfer Mode) e são discutidas suas principais características e sua

capacidade de oferecer garantias de qualidade de serviço (QoS) para transmissão de

dados.

4.1 Introdução


34

Existem atualmente várias tecnologias de rede de longa distância disponíveis para

transmissão de informações. Muitas delas são adequadas para transmissão de apenas um

tipo de mídia, como por exemplo, texto ou voz. Muitas possuem baixa velocidade de

transmissão e não fornecem suporte a transmissão em tempo real, nem garantias de

qualidade de serviço. A tecnologia ATM possui todas estas características e aparece como

forte candidata para dar suporte a transmissão de dados de aplicações multimídia com

garantias de qualidade de serviço.

Redes multimídia devem ter uma grande capacidade de banda, prover garantias de

QoS, usar eficientemente seus recursos, ser escalável e ter capacidade de fazer

comunicação de grupo [Lu96]. Alguns destes requisitos foram discutidos na seção 2.4.

Nesta seção são analisados alguns tipos de rede de longa distância em relação a

adequação para transmissão de informação multimídia. Os tipo de rede analisados são:

X.25, Frame Relay e SMDS (Switched Multimegabit Data Service).

• X.25. O protocolo X.25 foi desenvolvido para trabalhar com sistemas de

transmissão lentos e de baixa qualidade. Ela implementa mecanismos pesados de

detecção e recuperação de erro. Comutadores de uma rede X.25 implementam

controle de fluxo e detecção de erro, bem como preservam o sequenciamento e a

integridade dos pacotes de dados [HF98]. X.25 é orientado a conexão e como tal,

possui um alto potencial para suportar, ou abordar, isocronismo, pois pode

reservar ou alocar recursos no estabelecimento da conexão. Na prática, muitos

comutadores X.25 existentes realmente reservam recursos, mas não os alocam

para circuitos virtuais e geralmente fazem reserva em excesso. Assim, grande

parte da tecnologia X.25 implementada não pode prover garantia determinística

nem estatística da taxa de bits. Em relação a taxa de bits, os comutadores atuais

usualmente estão limitados a 2Mbps por linha de acesso. No que diz respeito a

reserva de banda passante, algumas redes X.25 fazem a previsão da declaração de

uma classe de vazão no momento do estabelecimento da conexão. Muitos

comutadores reservam banda passante logicamente, através do decréscimo de um

contador, o que pode levar a um excesso na reserva. As redes X.25 não suportam a

facilidade de comunicação de grupo. Pode-se concluir que X.25 é uma tecnologia

respeitável, apesar de antiga, que pode suportar aplicações multimídia de baixa

velocidade ou assíncronas. A tecnologia X.25 sofre devido a seus princípios e

objetivos de projeto. Ela não escala facilmente e não é adaptada para aplicações

que demandam isocronismo [Fluck95].


35

• Frame Relay. O protocolo Frame Relay foi definido como um serviço de

transporte de pacote para RDSI (Rede Digital de Serviços Integrados). Quando as

redes Frame Relay foram introduzidas, o único serviço de longa distância similar

existente era o X.25. Portanto, estes dois serviços são muito comparados

[Miller94]. O formato dos blocos de Frame Relay é um dos formatos usados por

X.25 e assim, Frame Relay transporta quadros X.25. No protocolo Frame Relay,

foram excluídos o controle de fluxo, a checagem de sequência, e a detecção e

correção de erro, presentes no X.25 [HF98]. Frame Relay foi desenvolvido como

um serviço para substituir a multiplexação síncrona por multiplexação estatística

em comunicações de dados convencionais. Não foi definido para suportar

transmissões isócronas em tempo real. Não foi desenvolvido para suportar

aplicações multimídia de tempo real ou que demandem banda passante. No

entanto, por ser orientado a conexão há uma facilidade de fazer alocação de

recursos. Possui um serviço de comunicação de grupo definido, mas que

raramente é implementado [Fluck95].

• SMDS. Foi desenvolvido para suportar interconexão, em alta velocidade, de

LANs (Local Area Networks) não orientadas a conexão. Não provê suporte

explícito para transmissão em tempo real de áudio ou vídeo. A velocidade de

acesso - atualmente 45Mbps e possivelmente 155Mbps - é apropriada para a

maioria das aplicações multimídia, exceto para canais HDTV (High-Definition

Television) simultâneos. Mais de seis canais de TV com qualidade de difusão

podem ser suportados em uma interface de 45Mbps. Uma característica

importante da tecnologia SMDS é ter um baixo retardo de transmissão, em torno

de 10 ms. A variação deste retardo depende da escolha de implementação feita

para a rede. SMDS possui a facilidade para fazer comunicação de grupo, o que

fornece uma solução para fazer difusão de vídeo ou suportar serviços perto de

vídeo-sob-demanda [Fluck95].

De acordo com o que foi mostrado, X.25, Frame Relay e SMDS não são

adaptados para transmissão de informações de aplicações que requerem isocronismo.

X.25 e Frame Relay também não são adaptados para transmissão de informações que

demandem uma grande capacidade de banda passante.


36

Os três protocolos não podem prover garantias de desempenho e foram definidos

para transportar dados que não tenham características de tempo real. Estes exemplos de

rede não devem ser considerados como bons candidatos para comunicações multimídia

[Lu96].

4.2 Tecnologia ATM

As tecnologias mostradas na seção anterior possuem várias limitações para transmissão

de dados em alta velocidade e de tráfego multimídia. Em relação a alta velocidade, os

pacotes possuem tamanhos e campos variados, controle de fluxo baseado em mecanismos

de janela torna a transmissão ineficiente e a correção de erros pode causar um

congestionamento na rede. Em relação ao tráfego multimídia, algumas tecnologias não

possuem suporte a comunicação de grupo, não possuem capacidade de estabelecer

conexões rápidas e também não possuem suporte para a definição de qualidade de

serviço.

Em contraste a estas tecnologias surge a tecnologia ATM, que possui um tamanho

de pacote (célula) fixo, não realiza controle de erros nos nós intermediários e permite a

definição de parâmetros de QoS.

ATM promete alcançar os cinco requisitos de rede, citados na seção anterior, para

comunicações multimídia, e é potencialmente mais apropriado para este tipo de

comunicação. ATM está sendo adotado pelo ITU-TS (International Telecommunication

Union-Telecommunication Sector) como o mecanismo de multiplexação e comutação

para B-ISDN (Broadband - Integrated Service Digital Network) e B-ISDN promete

suportar tipos diferentes de aplicações [Lu96].

A transmissão em uma rede ATM é orientada à conexão. Para estabelecer uma

sessão fim-a-fim, deve ser executado o procedimento de estabelecimento de conexão e ao

final, o procedimento de desconexão. No procedimento de conexão, o usuário deve

informar à rede os endereços de origem e destino, bem como a QoS necessária para

aquela conexão.

Existem várias razões pelas quais ATM é uma tecnologia apropriada para

comunicações multimídia. As principais destas razões são [Lu96]:

1. Largura de Banda. ATM promete alta velocidade de acesso aos sistemas-fim.

Estas velocidades de acesso são suficientes para qualquer tipo de aplicação

multimídia com a tecnologia de compressão atual.


37

2. Flexibilidade e garantias de QoS. As redes ATM podem suportar aplicações com

diferentes características de tráfego e requisitos de comunicação. Estes requisitos

incluem largura de banda, limites de retardo e sensibilidade a erros. ATM é um

esquema de multiplexação por divisão de tempo. As fatias de tempo não são

assinaladas para uma conexão particular, o que permite fazer alocação dinâmica

de banda para cada aplicação. O serviço orientado a conexão, provido pelo ATM,

pode reservar recursos para garantir a QoS de cada aplicação.

3. Escalabilidade. ATM é um protocolo não dependente de banda passante e permite

que qualquer aplicação, com diferentes requisitos de comunicação (especialmente

banda), compartilhem a mesma UNI (User Network Interface). A banda passante

para cada ponto de acesso não é afetada pelo número de usuários ativos

conectados a rede.

4. Integração. O protocolo ATM pode suportar, simultaneamente, através da mesma

UNI, múltiplas aplicações com diferentes características e requisitos. Isto implica

em grande simplificação e economia sobre as soluções de rede atuais, específicas

para cada tipo de aplicação.

5. Arquitetura. A topologia física de malha ponto-a-ponto utilizada na B-ISDN,

provê mais banda passante dedicada para cada usuário, comparada com redes que

utilizam meio compartilhado, como FDDI (Fiber Distributed Digital Interface) e

DQDB (Dual Queue Dual Bus). Também permite que a mesma arquitetura seja

desenvolvida como solução de rede tanto pública quanto privada, ambas

executando essencialmente o mesmo protocolo.

6. Eficiência. ATM utiliza multiplexação estatística de banda passante para

transmissão compartilhada. O ganho estatístico é significante quando as

aplicações com tráfego em rajada são multiplexadas. Como uma grande

quantidade das aplicações multimídia tende a ter o tráfego em rajada, o ganho

resultante da multiplexação estatística implica em um compartilhamento muito

eficiente do custo de transmissão.


38

7. Comunicação de grupo. ATM permite que a técnica de comunicação de grupo seja

implementada facilmente através da mudança de VCI (Virtual Channel Identifier)

e VPI (Virtual Path Identifier) nos comutadores.

8. Versatilidade. ATM utiliza um mecanismo de multiplexação e comutação

independente da taxa de bit, do tamanho da rede e do meio de transmissão. ATM

está caminhando para uma tecnologia padrão para serviços locais, de espinha

dorsal e de longa distância, público e privado. Esta uniformidade tem como

objetivo simplificar o gerenciamento da rede, através da utilização da mesma

tecnologia para todos os níveis de rede.

9. Padronização. ATM originou-se da necessidade por um padrão universal para

permitir interoperabilidade de informação, independente do sistema-fim ou do

tipo de informação. Com ATM, o objetivo é obter um padrão internacional. ATM

é uma tecnologia que está emergindo direcionada por um consenso internacional e

não pela visão ou estratégia de um único fabricante. Isso assegura o crescimento e

compatibilidade do ATM.

Algumas diferenças existentes entre ATM e as tecnologia citadas na seção

anterior são: cada conexão virtual ATM é estabelecida com uma classe de serviço

particular, escolhida de um conjunto bem definido de classes possíveis; no momento que

a conexão é estabelecida em ATM, várias características são definidas, como tipo de

tráfego, retardo de transmissão, tolerância a variação de retardo de célula e qualidade de

serviço; os mecanismos para estabelecimento de conexões virtuais, internamente, são

definidos por um padrão, o que facilita a interconexão entre comutadores de fabricantes

diferentes; não existe recuperação de erro de célula em conexões virtuais ATM. Células

erradas, quando detectadas, são simplesmente descartadas.

ATM suporta uma quantidade de serviços que podem competir com serviços

oferecidos por operadores de telecomunicações, tais como [Fluck95]:

• Serviços ATM que competem com serviços de dados convencionais. Conexões

virtuais ATM comutadas, de baixa velocidade, a uma taxa de bit constante,

competem com N-ISDN (Narrowband - Integrated Service Digital Network) e

outros serviços baseados em circuitos e de velocidade média. Circuitos


39

comutados, com taxa de bits variável competem com circuitos X.25. Circuitos

ATM permanentes competem diretamente com circuitos alugados.

• Serviços ATM que competem com novos serviços de comunicação. Circuitos

permanentes com taxa de bits variável, a uma velocidade média, são similares a

serviços Frame Relay públicos. O serviço ATM sem conexão corresponde na

prática a serviços SMDS.

A tecnologia ATM, quando disponível fim-a-fim, como uma tecnologia

desenvolvida para suportar várias classes de serviços, é a solução para suporte de

aplicações multimídia digitais para longas distâncias [Fluck95].

A possibilidade de estabelecer conexões a altas velocidades, com uma variedade

de níveis de garantia para taxa de bits e variação do retardo, deve satisfazer a maioria das

aplicações. O retardo de transmissão típico de dois a uma dezena de milisegundos -

excluído o retardo de propagação - é compatível com a maioria das aplicações descritas

no capítulo 2. A taxa de perda de célula de 10-8 a 10-10 é apropriada para todos os tipos de

transmissão de tempo real de fluxos de áudio e vídeo.

A tecnologia ATM deve suportar uma grande variedade de serviços e aplicações e

satisfazer uma série de necessidades de qualidade do usuário e objetivos de desempenho

da rede. Esta tecnologia permite flexibilidade na escolha de taxas de conexão e permite a

multiplexação estatística de fluxos de tráfego VBR (Variable Bit Rate). ATM fornece um

serviço de transporte universal para redes digitais de serviços integrados de banda larga

(B-ISDNs), que podem transportar voz, dados e vídeo [GMÖ97].

Em relação a comunicação de grupo, esta característica não fez parte da versão

inicial do padrão ATM. No entanto, muitos comutadores ATM da primeira geração

implementavam mecanismos locais de replicação de célula. O ATM Forum propõe uma

solução na qual são considerados os seguintes modos de comunicação de grupo

[Fluck95]:

• Conexões unidirecionais multi-parte. Conhecido como modo ponto-a-multiponto.

É um modo de distribuição de uma via que pode ser usado para suportar

distribuição de vídeo digital ou serviços perto de vídeo-sob-demanda.

• Conexões bidirecionais multi-parte. Conhecido como modo multiponto-a-ponto,

onde as partes receptoras possuem um canal de retorno, apenas com a fonte


40

principal. Conexões assimétricas, onde cada direção de transmissão pode ter uma

taxa garantida de bits diferente, estão previstas.

Na tabela 4.1 são mostrados os parâmetros multimídia para as tecnologias de rede

apresentadas nesta seção. É feita uma comparação entre os parâmetros das redes X.25,

Frame Relay, SMDS e ATM.

Tecnologias de Pacote

de Longa Distância

Velocidade

de Acesso

(Mbps)

Isocronismo Garantias de

Banda Passante

Comunicação

de Grupo

X.25 0.001-2 Não Não (1) Não

Frame Relay 0.064-2 (3) Não (3) Reservada (2) Não (4)

SMDS 1-34 Taxa média de

bits

Sim

ATM

− Serviço de emulação

de circuito

0.064-45 (3,5) Sim Dedicada Não

− Serviço Classe B 0.064-45 (3,5) Sim Sim Não (6)

− Serviço Classe C 0.064-45 (3,5) Não Sob demanda Não (6)

− Serviço sem conexão 1-34 (3,5) Não Taxa média de

bits (7)

Sim (7)

(1) No entanto uma classe de vazão pode ser implementada

(2) Depende da implementação

(3) Depende da implementação e dos serviços reais oferecidos pelos PONs (Optical Networks)

(4) Definido por um consórcio. Poucas implementações

(5) Velocidade de acesso sobre conexões virtuais individuais

(6) Inicialmente possível apenas no nível de comutação

(7) Quando provido pelo SMDS

Tabela 4.1 - Parâmetros multimídia para tecnologias de redes de pacote de longa

distância


41

4.3 Qualidade de Serviço em Redes ATM

As redes ATM têm a capacidade de fornecer garantias de qualidade de serviço a

aplicações que transmitam suas informações através desta rede. As aplicações podem ter

características e requisitos de comunicação diferentes. A garantia de qualidade de serviço

em ATM está baseada na reserva e alocação de recursos e no conceito de classes de

serviço.

4.3.1 Reserva, Alocação e Dedicação de Recursos

As redes compartilham recursos entre várias comunicações simultâneas. A maneira como

é feito este compartilhamento, varia dependendo do tipo de rede. Os recursos em uma

rede podem ser reservados, alocados ou dedicados [Fluck95].

A rede que utiliza a reserva de recursos, permite que recursos sejam reservados

quando uma comunicação particular é identificada. A reserva consiste da subtração de um

valor do total de créditos do recurso. Dependendo do tipo de rede, um tipo de recurso que

pode ser reservado é banda passante, onde uma fatia lógica da banda passante da rede é

reservada para o tempo de duração de uma comunicação. Outro exemplo de recurso que

pode ser reservado, é buffer em um nó de comutação, onde a reserva é feita através da

subtração de uma certa quantidade do valor total. Em muitos casos, o principal objetivo

da reserva lógica de recursos, é a capacidade de determinar se uma nova conexão pode ser

aceita ou não. Este procedimento é chamado de algoritmo de controle de admissão

(Connection Admission Control - CAC). Muitos comutadores, incluindo os de tecnologia

ATM, reservam buffers desta maneira.

Quando a rede permite que os recursos sejam alocados, não é feita apenas uma

reserva baseada no cálculo da taxa de bits requisitada, mas é feita uma alocação de

recursos reais. No entanto, quando é percebido que os recursos não estão sendo

totalmente usados ou quando ocorre uma situação de grande congestionamento, a rede

pode realocar, temporariamente, alguns dos recursos para outras comunicações. A

garantia de banda passante pode ser tanto estatística quanto determinística. Algumas

redes ATM suportam serviços isócronos através da alocação de recursos. Uma conexão

de rede fim-a-fim, é dita isócrona, se a taxa de bits da conexão é garantida e se a variação

do retardo possui um valor pequeno e garantido.

Quando uma rede permite dedicação de recursos, uma vez que uma conexão é

estabelecida nesta rede, recursos são dedicados para esta conexão. A rede não parece ser


42

compartilhada entre usuários, pois a banda passante é dedicada para cada comunicação

particular. Não existe reserva em excesso de recurso, nem realocação de recursos não

utilizados durante a comunicação. Exemplos de redes com banda passante dedicada são

linhas alugadas, tais como circuitos T-1 ou E-1 e conexões comutadas como circuitos

ISDN (Integrated Service Digital Network).

Quando a rede não permite que seja feita reserva, muito menos alocação e

dedicação, de recursos, o que esta rede pode garantir é apenas que ela fará o melhor para

facilitar o transporte de fluxos de comunicação. Estas redes são chamadas de best-effort.

Exemplos deste tipo de rede são a tecnologia Ethernet e o protocolo IP versão 4.

Garantias básicas de QoS são providas através da reserva de recursos no nível de

rede. Apenas redes que permitam a reserva de recursos, como as redes ATM, podem

garantir uma certa qualidade de serviço [HS96].

Neste trabalho é implementado um esquema de negociação dinâmica de banda

passante, através da reserva e alocação de banda em uma rede ATM.

4.3.2 Classes de Serviço ATM

A qualidade de serviço em ATM é fornecida através da definição de classes de serviço.

As classes de serviço existentes são: A, B, C e D. Cada uma possui características

distintas e é indicada para a transmissão de um tipo de informação específica. A

informação a ser transmitida, é codificada para requisitar uma QoS, de acordo com os

requisitos de desempenho das classes de serviço [Black95]. Cada classe de serviço é

definida a seguir.

• Classe A. As relações temporais entre fonte e destino devem ser preservadas. A

taxa de bits é constante. Esta classe emula o comportamento de circuitos. Ela é

chamada de classe de emulação de circuito e é definida para telefonia ou vídeo

com taxa de bits constante.

• Classe B. As relações temporais entre fonte e destino devem ser preservadas. A

taxa de bits é variável. Esta é realmente a inovação no ATM, pois as outras classes

existiam em tecnologias anteriores. Tem como objetivo o suporte a fluxos de

áudio e vídeo comprimidos.


43

• Classe C. As relações temporais entre fonte e destino não são necessárias. A taxa

de bits é variável. Esta é a classe padrão para tráfego de dados. A principal

característica desta classe é que podem ser fornecidos garantias as taxas de pico e

limites para a variação do retardo, de acordo com a especificação no momento do

estabelecimento da conexão.

• Classe D. Semelhante a classe C, mas emula um serviço sem conexão. O objetivo

desta classe é fornecer compatibilidade com LANs sem conexão, existentes, e

permitir que elas sejam interconectadas sem que seja necessário um complicado

esquema de estabelecimento de conexão. Esta interconexão deve se dar da mesma

maneira como é feita hoje, através de roteadores utilizando IP sem conexão.

A título de ilustração, a figura 4.1 mostra as classes de serviço, com suas

características e exemplos dos tipos de aplicações que podem ser executadas em cada

classe.

Classe A Classe B Classe C Classe D

Relações temporais entre fonte e destino

Taxa de bit

Modo de Conexão

Serviço de emulação de circuito para telefonia, voz,

vídeo não comprimido

Voz e Vídeocomprimido

Comunicaçõesde dados

Interconexãode LANs

Comunicaçõesde dados

Necessária Não Necessária

Constante Variável

Orientado a Conexão SemConexão

Figura 4.1 - Classes de serviço ATM, suas características e respectivas aplicações

4.4 Controle de Admissão de Conexões em RedesATM


44

Para fornecer as garantias de QoS, as redes ATM implementam a função conhecida como

Controle de Admissão de Conexão (CAC - Connection Admission Control). Quando um

pedido de conexão é recebido pela rede, ele é primeiramente analisado pelo CAC, que

baseado nos parâmetros de tráfego e de QoS, verifica se a conexão pode ser aceita, sem

violar a QoS já garantida para as outras conexões. Uma conexão é aceita pelo CAC

quando a mesma puder ser aceita por toda a rede, juntamente com seus níveis de QoS.

De acordo com [ATMF96], CAC é definido como: “Um conjunto de ações

tomadas pela rede durante a fase de estabelecimento de conexão para determinar se um

pedido de conexão pode ser aceito ou deve ser rejeitado (ou se um pedido para realocação

pode ser acomodado)”.

Em redes ATM, as medidas de QoS relacionadas ao tráfego, podem ser divididas

em duas categorias: nível de conexão e nível de célula. Algumas medidas de QoS para o

nível de conexão são: probabilidade de perda de conexão e retardo do estabelecimento da

conexão. Para o nível de células, algumas medidas de QoS são: taxa de perda de célula e

retardo de célula. Entre estas medidas, a taxa de perda de células, por exemplo, pode ser

satisfeita pelo CAC e o retardo de célula, pelo dimensionamento dos buffers dos

comutadores [Saito93].

A UNI (User-Network Interface), interface localizada entre o usuário e a rede

ATM, define procedimentos específicos para requisição, estabelecimento e finalização

de conexões, bem como o canal out-of-band usado para executar o controle.

A UNI define todas as características da interface, incluindo o nível físico e

elétrico, a maneira pela qual as células são delineadas e formatadas, o mecanismo para

identificação de várias conexões estabelecidas em uma interface e os mecanismos para os

sistemas de usuário especificarem os parâmetros de qualidade de serviço.

O contrato de tráfego analisado pelo CAC, deve conter informações suficientes,

que possibilitem à rede tomar decisões certas, no caso de aceitar ou rejeitar uma conexão.

As principais informações do contrato de tráfego são [Black95]:

• Descritor do tráfego na fonte. Alguns valores relacionados com a aplicação em si,

podem variar para cada conexão. Alguns desses valores são: taxa de pico, taxa

média e tolerância a rajada.

• QoS para ambas as direções. Parâmetros como taxa de erro de célula, taxa de

perda de célula e taxa de células inseridas erroneamente.


45

• Variação do retardo das células. Quantidade de variação fim-a-fim que pode

ocorrer com as células da conexão.

• Definição da conformidade requisitada. Valores como taxa de pico e taxa

sustentável de célula (Sustainable Cell Rate - SCR), que descrevem a

conformidade das células para a conexão.

A figura 4.2 ilustra o estabelecimento de uma conexão em uma rede ATM. No

esquema mostrado, as duas principais mensagens, em relação a garantia de QoS, são a

mensagem SETUP, enviada pelo usuário transmissor e a mensagem CONNECT, enviada

pelo usuário receptor. A mensagem SETUP contém várias informações, como

identificador da mensagem, especificação de parâmetros AAL (ATM Adaptation Layer),

endereços origem e destino e requisitos de QoS. A mensagem CONNECT contém os

parâmetros com os quais o receptor concorda [Black95].

Os procedimentos de controle de conexão ATM são baseados nas operações da

camada 3 do protocolo Q.931 [ITU93], da ISDN (Integrated Service Digital Network), e

em um subconjunto desse protocolo, o Q.2931 [ITU95], que está sendo desenvolvido

pelo ITU-T.

Neste trabalho é desenvolvido um conjunto de programas que funcionam como

um CAC. Com este CAC é possível transmitir informações de aplicações multimídia

através de uma rede ATM, utilizando negociação dinâmica de QoS.


46

usuário usuário

• Endereços• Características do Tráfego• QoS

• Endereços• Características do Tráfego• QoS• VPI/VCI

RedeATM

UNI UNI

SETUP

SETUP

CONNECT

CONN ACK

CONN ACK

• Completa a criação do VC

• Aloca recursos• Descobre caminho• Cria tabelas de VC

CALL PROCEEDING

CALL PROCEEDING

Figura 4.2 - Estabelecimento de uma conexão através de uma rede ATM


Neste capítulo foram apresentadas algumas tecnologias de redes de pacotes para longa

distância. Estas tecnologias foram rapidamente analisadas, em relação ao suporte que

podem dar a aplicações multimídia e garantias de QoS. Depois foi analisada a tecnologia

ATM, de acordo com os mesmos critérios. A tecnologia ATM foi apontada como solução

para transmissão de aplicações multimídia em longas distâncias com garantias de

qualidade de serviço.

Dentro da tecnologia ATM, foram discutidos os conceitos de qualidade de serviço

e controle de admissão de conexão (CAC). A discussão sobre QoS, envolveu a definição

de recursos reservados, alocados e dedicados e de classes de serviços. No que diz respeito

ao CAC, foram dadas definições do que é este procedimento e como ele funciona.

O trabalho aqui apresentado, baseia-se na implementação de um CAC, que

possibilite a negociação dinâmica de banda passante em uma rede ATM.


47Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira

48

Capítulo 5

Um Esquema de Negociação Dinâmica de QoS

Este capítulo mostra um esquema definido para executar negociação dinâmica de QoS.

Como citado no capítulo 1, este esquema serviu de motivação para o desenvolvimento do

trabalho aqui apresentado.

5.1 Introdução

Em [GNN97] é definido um esquema de negociação dinâmica de QoS para aplicações

multimídia. A Arquitetura de negociação de QoS deste esquema é mostrada na figura 5.1.

Esta arquitetura pode ser utilizada para negociação inicial e negociação dinâmica

de QoS. O gerente de QoS é responsável por obter os requisitos da aplicação do usuário e

traduzi-los para parâmetros de QoS reais. Depois, o gerente inicia uma negociação local

para reservar recursos locais para suportar a aplicação. Se existirem recursos locais

disponíveis, o gerente faz então uma requisição para obter recursos da rede. O gerente de

QoS também é responsável por tratar os pedidos de renegociação durante o tempo da

sessão.

A MIB (Management Information Base) de QoS tem o mesmo significado da

MIB já bastante conhecida por todos, da área de gerenciamento de redes. Esta MIB, no

entanto, lida com conexões que suportam aplicações de tempo real, o que faz com que

essa MIB tenha algumas características especiais.

Cada nó intermediário deve ter apenas alguns parâmetros na MIB de QoS, tais

como parâmetros de carga referentes ao próprio nó (largura de banda e retardo, por

exemplo). Pelo fato do processamento de QoS ter que ser realizado, tendo-se em mente

severas restrições de tempo, a MIB de QoS deve ser armazenada em memória principal.

Esta MIB deve representar apenas um pequeno conjunto da MIB real, armazenada em

disco. Os agentes de QoS devem estar presentes em cada nó da rede, para executar

procedimentos locais e decidir sobre a disponibilidade de recursos.


49

Processamento de QoS

Nó Intermediário

MIB

AgenteQoS

MIBQoS

Processamento de Comutação

Processamento de QoS

Nó Intermediário

AgenteQoS

MIBQoS

Processamento de Comutação

Protocolo de Comunicação

Aplicaçãodo usuário

GerenteQoS

Protocolo de Comunicação

Aplicaçãodo usuário

GerenteQoS

Figura 5.1 - Arquitetura da negociação de QoS

Cada conexão, ao ser estabelecida, define um valor mínimo de banda para ela.

Este valor fica alocado para a conexão durante toda sua fase ativa. O esquema garante

que, para as conexões aceitas, o percentual de rejeição dos pedidos de renegociação seja

pequeno. Para prover esta garantia, o esquema considera dois conceitos para os valores de

banda: o de banda alocada e o de banda real, como pode ser visto na figura 5.2.

Nível Mínimo

Lar

gura

de

band

a (b

ps)

Banda Alocada

Lar

gura

de

band

a (b

ps)

Banda Real

Figura 5.2: Banda Alocada x Banda Real

A banda alocada corresponde aos recursos alocados, logicamente, para as

conexões. O valor de banda alocada sempre respeita a alocação mínima de recursos.

Quando uma conexão libera recursos, ela nunca os libera abaixo do seu valor mínimo,

mesmo que estes não estejam sendo utilizados. A banda real corresponde aos recursos

alocados fisicamente, os recursos em uso. Considerando-se a banda real, ao liberar


50

recursos, uma conexão pode chegar a liberar todos os recursos alocados para ela,

independentemente do valor mínimo definido para a conexão. A banda real não considera

o valor mínimo. Portanto, a banda alocada sempre é maior ou igual a banda real, e ao

considerar uma solicitação por recursos, a probabilidade desta solicitação ser aceita pela

banda real é maior do que pela banda alocada.

Para admissão de novas conexões, é utilizada a banda alocada e para a admissão

de pedidos de renegociação, é utilizada a banda real. A diferença entre a banda alocada e

a banda real só pode ser utilizada para os pedidos de renegociação. Assim, os pedidos de

renegociação têm prioridade sobre os pedidos de novas conexões, o que significa uma

garantia de recursos para as conexões que foram aceitas.

A partir da idéia apresentada em [GNN97], o objetivo do trabalho foi especificar,

projetar e implementar um serviço de negociação dinâmica de QoS, para aplicações

multimídia, utilizando uma rede ATM.


Neste capítulo foi apresentado o esquema de negociação dinâmica de QoS que motivou o

desenvolvimento deste trabalho. Foi apresentada também a arquitetura de negociação de

QoS que foi definida para o esquema.


51

Capítulo 6

Um Serviço de Negociação de QoS para uma Rede ATM

A partir dos conceitos e esquema apresentados no capítulo 5, será definida neste capítulo,

uma arquitetura de negociação de QoS para uma rede ATM.

Para implementação desta arquitetura foi definida a camada de negociação de

QoS. Esta camada é mostrada aqui, juntamente com a especificação do serviço oferecido

por ela e suas primitivas. É mostrada também a especificação do protocolo de negociação

dinâmica de QoS, executado entre os diversos nós da rede.

6.1 Introdução

Foi definida uma arquitetura de negociação de QoS, que utiliza os serviços da camada

ATM e presta serviço à camada de aplicações multimídia, como mostra a figura 6.1.

A aplicação do usuário tem acesso às primitivas de serviço de negociação e pode

fazer pedidos para estabelecer uma conexão, para pedir mais recursos, para liberar

recursos excedentes ou para terminar uma conexão. Os pedidos são analisados pela

camada de negociação de QoS, que decide se o pedido pode ser aceito ou não. Cada nó

possui uma pequena base de dados representando a quantidade total de recursos e a

quantidade disponível em um determinado momento. Essa base de dados é a MIB de

QoS, citada no capítulo 5. As decisões tomadas pela camada de negociação dinâmica de

QoS são baseadas nos valores presentes na MIB.

Atualmente, a camada de negociação de QoS, executa a negociação dinâmica

apenas de banda passante, mas a idéia maior é estender sua funcionalidade, para que seja

executada também a negociação de outros parâmetros, como retardo e variação do

retardo.

Em [GNN97], o esquema é definido para os nós intermediários de uma rede.

Neste trabalho, no entanto, a arquitetura de negociação de QoS foi definida e

implementada, além dos nós intermediários, também para os nós cliente e servidor, de

uma aplicação. Estes nós também possuem uma MIB. O tipo de aplicação multimídia ao

qual este trabalho procura atender, é o de vídeo-sob-demanda (seção 2.3.1).


52

GerenteQoS

Camada de Negociação de QoS

MIB QoSpara ATM

Agente QoS

Nó Intermediário ATM Nó Intermediário ATM Nó Intermediário ATM

Nó Cliente ATM

Nó Servidor ATM

UNIUNI

Protocolo de Negociação

Protocolo de Negociação

Protocolo de Negociação Protocolo de Negociação

• Estabelecer conexão• Solicitar mais recursos• Solicitar menos recursos• Terminar conexão


Rede ATM

MIB QoSpara ATM

Agente QoS


Rede ATM

MIB QoSpara ATM

Agente QoS


Rede ATM

Rede ATM

GerenteQoS


Rede ATM

Primitivas de Serviçode Negociação

MIB QoSpara ATM

Aplicação do usuário

MIB QoSpara ATM

Figura 6.1 - Arquitetura de Negociação de QoS para uma rede ATM

6.2 Serviço

A camada de negociação de QoS foi definida para permitir a negociação dinâmica de

QoS, com o objetivo de atender as necessidades das aplicações multimídia. A localização

da camada de negociação é mostrada na figura 6.2. O principal objetivo desta camada, é

fornecer à camada de aplicação multimídia, primitivas de serviço que permitam a

utilização da alocação dinâmica de banda passante em uma rede ATM. Para definição e

implementação da camada de negociação dinâmica de QoS, foram utilizados os conceitos

de serviço e protocolo [Tanen96].

Serviço é o conjunto de funções que uma camada fornece, através de primitivas de

serviço, à camada superior. Protocolo é o conjunto de regras que controla o formato e o

significado dos quadros, pacotes ou mensagens que são trocados por entidades pares

dentro de uma camada. Entidades usam protocolos para implementar suas definições de

serviço. A especificação da camada de negociação é feita através da especificação do seu

serviço e do seu protocolo.

O modelo da especificação do serviço e do protocolo desta camada está baseada

nos modelos existentes em [Nog91] e [Holz91]. A estrutura interna da camada de

negociação é apresentada na figura 6.3. As primitivas de serviço oferecidas ao usuário


53

são: Estabelecer_Conexao(Parametros), Mais_Recursos(Id_Conexao, Parametros),

Menos_Recursos (Id_Conexao, Parametros) e Terminar_Conexao (Id_Conexao).

Nó Cliente

Nó Servidor

Nó Intermediário

Nó Intermediário

Protocolode

Negociação

Protocolode

Negociação

Protocolode

Negociação

Camadas Superiores

Aplicação Multimídia

Negociação QoS

ATM

Física

Negociação QoS

ATM

Física

Negociação QoS

ATM

Física

Negociação QoS

ATM

Física

Serv

iço

de

Neg

ocia

ção

de Q

oS

AAL5 AAL5 AAL5 AAL5

Figura 6.2 - Posição da Camada de Negociação de QoS dentro de um Esquema de

Camadas

EstabelecerConexão

Mais Recursos

MenosRecursos

TerminarConexão

Interface com Usuário

Interface com driver ATM

SAP Camada de QoS

SAP Camada ATM

Camada de Negociação QoS

Através desta interface, o usuário solicita o serviço necessário

De acordo com o serviço solicitado, é executada a primitiva correspondente. Todas as primitivas utilizam a interface ATM para passar suas informações

Através desta interface, são passados os dados das primitivasde serviço para a rede ATM

Figura 6.3 - Estrutura Interna da Camada de Negociação de QoS

Cada primitiva executa uma tarefa específica, dentro do serviço de negociação

dinâmica de QoS. A definição destas primitivas é a seguinte.

• Estabelecer Conexao. Uma aplicação de usuário solicita o estabelecimento de uma

conexão. O pedido é analisado pelo nó cliente. Se este nó possuir recursos disponíveis,

ele aceita o pedido, aloca os recursos necessários e envia o pedido para o próximo nó

da rede. Se o nó não possuir os recursos necessários, o pedido é recusado e

contabilizado como rejeitado. Um pedido de conexão só é considerado aceito, quando


54

for aceito por todos os nós da rede, e o nó cliente receber uma confirmação através de

uma PDU (Protocol Data Unit).

− Parâmetros: parâmetros de negociação de QoS

• Solicitar Mais Recursos. Uma aplicação solicita que sejam alocados mais recursos para

ela. Segue o mesmo raciocínio da primitiva Estabelecer_Conexao. Se o nó cliente

puder aceitar o pedido, ele aloca recursos e envia o pedido para o próximo nó. Senão,

o pedido é rejeitado e contabilizado como tal. Um pedido é considerado aceito quando

o nó cliente receber uma PDU confirmando a aceitação do pedido por todos os nós.

− Parâmetros: identificador da conexão e parâmetros de negociação de QoS

• Solicitar Menos Recursos. Uma aplicação informa que possui recursos a mais e que

pode liberar uma determinada quantidade. Assim, os parâmetros da MIB são

atualizados no nó cliente, subtraindo-se o valor dos recursos da conexão, até no

máximo o valor mínimo, considerando-se a banda alocada, e até o valor realmente

utilizado, considerando-se a banda real da conexão. O valor subtraído da banda

alocada, é adicionado ao total de banda alocada disponível do nó. O valor subtraído da

banda real, é adicionado ao total de banda real disponível do nó. Depois, o pedido é

passado para o próximo nó. Uma solicitação de menos recursos é sempre aceita.


• Terminar Conexao. Uma aplicação solicita o término de uma conexão. A MIB é

atualizada no nó cliente, liberando os recursos que estavam alocados para a conexão

que está sendo finalizada. Estes recursos são adicionados a banda disponível do nó

(real e alocada). O pedido é passado para o próximo nó.

− Parâmetros: identificador da conexão

6.2.1 Diagramas de Tempo das Primitivas de Serviço

O sequenciamento das primitivas do serviço de negociação dinâmica de QoS, pode ser

mostrado através de diagramas de tempo. A partir destes diagramas, pode-se observar as

diversas possibilidades de execução de uma determinada primitiva. As primitivas são

unidades de dados trocadas apenas entre a aplicação usuária e a camada de negociação.

As unidades de dados trocadas entre os nós da rede, fazem parte do protocolo de

negociação, e são chamadas PDUs (Protocol Data Units). A seguir, são mostrados os


55

diagramas de tempo das primitivas de serviço Estabelecer_Conexao, Terminar_Conexao,

Mais_Recursos e Menos_Recursos, juntamente com a ordem de execução destas

primitivas e as PDUs correspondentes, executadas em resposta a cada tarefa solicitada.

A figura 6.4 mostra o diagrama de tempo para a primitiva Estabelecer_Conexao.

A figura 6.5 mostra o diagrama de tempo para a primitiva Terminar_Conexao. A figura

6.6 mostra o diagrama de tempo para a primitiva Menos_Recursos. A figura 6.7 mostra o

diagrama de tempo para a primitiva Mais_Recursos. A figura 6.8 mostra o diagrama com

a ordem de execução de todas as primitivas e PDUs.

E stab _C on exa o

E stab_C on exao

E stab_ C o nex ao

E stab _ C o nexao

E stab _C onexao

E stab_C on exao

C on exao_ E stab

C on exao_ E stab

C onexao_E stab

C ancelar_R ec

C ancelar_ R ec

C ancelar_R ec

E stab _C on exa o

C ancelar_R ec

E stab _ C o nexao

C ancelar_R ec

E stab _C onexao

C ancelar_ R ec

N ó N ó N ó C liente In term ed iá rio S erv ido r

(* ) Ú nico caso em q ue a conexão é estabe lec ida

N ó N ó N ó C liente In term ed iário Se rvido r

N ó N ó N ó C liente In term ed iá rio S erv ido r

N ó N ó N ó C liente In term ediário S erv id or

Figura 6.4 - Diagrama de Tempo para a Primitiva Estabelecer_Conexao

Term_Conexao

Term_Conexao

Term_Conexao

(*) A primitiva Terminar_Conexao deve ser sempre aceita por todos os nós

Nó Nó Nó Cliente Intermediário Servidor

Figura 6.5 - Diagrama de Tempo para a Primitiva Terminar_Conexao


56

Menos_Recurso

Menos_Recurso

Menos_Recurso

(*) A primitiva Menos_Recurso deve ser sempre aceita por todos os nós

Nó Nó Nó Cliente Intermediário Servidor

Figura 6.6 - Diagrama de Tempo para a Primitiva Menos_Recursos

Mais_Recurso

Cancelar_Rec

Cancelar_Rec

Cancelar_Rec

A Intermediário B

Mais_Recurso

Mais_Recurso

Mais_Recurso

A Intermediário B

Mais_Recurso

Mais_Recurso

Cancelar_Rec Cancelar_Rec

Cancelar_Rec

A Intermediário B A Intermediário B

Mais_Recurso Mais_Recurso

Mais_Recurso

Figura 6.7 - Diagrama de Tempo para a Primitiva Mais_Recursos


57

Estab_Conexao

Estab_Conexao

Estab_Conexao

Conexao_Estab

Conexao_Estab

Conexao_Estab

A Intermediário B

Mais_Recursos

Mais_Recursos

Mais_Recursos

Mais_Recursos

Mais_Recursos

Mais_Recursos

Cancelar_Rec

Cancelar_Rec

Cancelar_Rec

Menos_Recursos

Menos_Recursos

Menos_Recursos

Term_Conexao

Term_Conexao

Term_Conexao

Figura 6.8 - Diagrama de Tempo mostrando a ordem de Execução das Primitivas e

PDUs

6.3 O Serviço da Camada ATM

A camada inferior à camada de negociação dinâmica de QoS é a camada do protocolo

ATM. Esta camada oferece o serviço de enviar e receber dados através do driver ATM de

uma estação, utilizando a API (Application Programmers’ Interface) disponível. As

placas ATM utilizadas neste projeto, são da Sun Microsystems, com padrão UNI 3.0.

Nesta seção são descritas as funções da API utilizadas. As funções para fazer transmissão

e recepção, através do driver das placas ATM da Sun, são [Sun95]:


58

• sa_open. Abre um fluxo para uma interface física (sa0, sa1, etc.).

• sa_attach. Associa um ponto físico de ligação, ppa (physical point of attachment), com

um dispositivo sa aberto, especificado pelo descritor de arquivo fd.

• sa_allocate_bw. Especifica a quantidade de banda passante, em megabits por segundo,

que será alocada para transmitir dados de um fluxo especificado pelo descritor de

arquivo fd. Necessário apenas para fluxos de transmissão de dados.

• sa_add_vpci. Adiciona o identificador de conexão de caminho virtual, vpci, para o

fluxo especificado (identificado por seu descritor de arquivo, fd).

• sa_setraw. Indica ao driver que o fluxo especificado pelo descritor de arquivo fd,

estará transmitindo e recebendo dados não processados, que serão interpretados

diretamente pela aplicação.

• sa_release_bw. Libera toda banda passante que foi previamente alocada para o fluxo

identificado por fd.

• sa_close. Fecha o fluxo especificado pelo descritor de arquivo fd.

Bibliotecas que possuem estas rotinas: atm/sa.h e atm/atmioctl.h.

As chamadas de sistema do sistema operacional UNIX, que fazem transmissão e

recepção através de fluxos, são:

• putmsg. Envia uma mensagem em um fluxo. Cria uma mensagem a partir do buffer

especificado pelo usuário e envia a mensagem para um arquivo STREAMS.

• getmsg. Tira a próxima mensagem de um fluxo. Recupera o conteúdo de uma

mensagem localizada no início de uma lista de leitura de fluxo, de um arquivo

STREAMS, e coloca o conteúdo em um buffer especificado pelo usuário.

Biblioteca que possui estas rotinas: stropts.h.

A ordem de execução da função de transmissão, é mostrada na figura 6.9 e da

função de recepção, na figura 6.10.

sa_open (register char *interface);


59

sa_attach (int fd, u_long ppa, int timeout);

sa_allocate_bw (int fd, int bw);

sa_add_vpci (int fd, vci_t vpci, int encap, int buf_type);

sa_setraw (int fd);

putmsg (int fildes, const struct strbuf *ctlptr, const struct strbuf *dataptr, int

flags);

sa_release_bw (int fd);

sa_close (int fd);

Figura 6.9 - Ordem de Execução para Transmissão

sa_open (register char *interface);

sa_attach (int fd, u_long ppa, int timeout);

sa_add_vpci (int fd, vci_t vpci, int encap, int buf_type);

sa_setraw (int fd);

getmsg (int fildes, struct strbuf *ctlptr, struct strbuf *dataptr, int flagsp);

sa_close (int fd);

Figura 6.10 - Ordem de Execução para Recepção

6.4 O Protocolo de Negociação

Como mostrado nas figuras 6.1 e 6.2, existem três tipos de nós, na arquitetura

desenvolvida neste trabalho. O nó que inicia o processo de negociação dinâmica e chama

as primitivas de serviço da camada de negociação de QoS, durante a existência de uma

conexão, é o nó cliente da aplicação (a aplicação multimídia é apresentada neste nó). A

negociação é iniciada a partir do cliente, da mesma maneira como ocorre no RSVP

(Resource ReSerVation Protocol). Existem dois pontos importantes para justificar o

início da negociação a partir do cliente. Um deles, é que uma mesma aplicação, situada

em um nó servidor, pode ser transmitida para vários receptores. Cada receptor pode ter

características e requisitos de qualidade diferentes. Assim, cada cliente deve indicar quais

seus requisitos de qualidade de serviço. O outro fato que justifica o início da negociação a

partir do cliente, é que quando o esquema é utilizado em comunicação de grupo, fica mais

fácil de ser gerenciado [ZDE+93] [RFC2205].

6.4.1 Descrição do Protocolo


60

O usuário, situado no nó cliente, ao desejar fazer a transmissão de uma aplicação

multimídia, solicita à camada de serviço de negociação de QoS, o estabelecimento de

uma conexão com o nó servidor. Esta solicitação é feita por meio de uma primitiva de

estabelecimento de conexão, da camada de QoS. A camada de QoS analisa a primitiva e

seus parâmetros e decide se existem recursos locais disponíveis para aceitar a conexão. Se

não existirem recursos locais, a transmissão é encerrada. Se existirem recursos locais, a

camada de QoS reserva os recursos necessários no nó local, e passa, através do SAP

(Service Access Point) ATM, o pedido de estabelecimento de conexão para os próximos

nós da rede, até chegar ao último nó, o servidor.

Cada nó da rede, intermediário ou servidor, possui também uma camada de

negociação de QoS e, através dela, deve analisar o pedido de conexão que chega. Este

pedido pode ser aceito ou rejeitado por qualquer nó. No caso de ser aceito, o nó deve

reservar recursos locais e passar o pedido adiante até o último nó. Se no entanto, o pedido

não puder ser aceito por um determinado nó, este deve informar que não pode aceitar a

conexão, retornando, aos nós anteriores, um pedido de cancelamento dos recursos

alocados anteriormente.

Com a conexão estabelecida, a aplicação usuária pode solicitar, através da camada

de QoS, mais ou menos recursos ou encerrar a conexão. A solicitação de mais recursos

pode ser aceita ou rejeitada por qualquer nó da rede. Se for aceita por todos os nós, o nó

servidor deve enviar uma PDU para confirmar a aceitação do pedido. Ao chegar esta

confirmação no nó cliente, o pedido de renegociação é contabilizado como aceito. Se, no

entanto, algum nó não puder aceitar o pedido, este é cancelado e contabilizado como

rejeitado.

As solicitações de menos recursos e de encerramento de conexão devem ser

aceitas por todos os nós da rede. O tratamento da solicitação de menos recursos deve

levar em consideração, os conceitos de banda alocada e banda real (seção 5.1).

A figura 6.11 mostra o esquema de alocação de canais entre os nós da rede. Os

nós são identificados da seguinte maneira: o nó cliente é onde será exibida a aplicação

multimídia. É este nó que utiliza as primitivas do serviço de negociação dinâmica de

QoS. O nó servidor é onde está armazenada a aplicação multimídia. Os nós

intermediários são os que encontram-se entre o nó cliente e o nó servidor. Os dados da

aplicação multimídia são transmitidos, através dos canais de dados, no sentido do nó

servidor para o nó cliente, passando pelos nós intermediários. As informações de controle

são transmitidas nos dois sentidos, através do canal de controle.


61

Nó Cliente(Exibe a aplicação/

Inicia os pedidos de negociação)

Nó Intermediário Nó Servidor(Armazena a aplicação)

Canal de Controle(Negociação)

Canal de Controle(Negociação)

Canais de Dados(Dados da Aplicação)

Canais de Dados(Dados da Aplicação)

Figura 6.11 - Esquema dos canais de comunicação entre as máquinas - 1 canal decontrole e vários de dados

6.4.1.1 Tipos e Formatos das PDUs

Para execução do protocolo de negociação, é necessário que sejam definidas as PDUs que

fazem parte do protocolo, bem como o formato destas PDUs. As PDUs que são utilizadas

através dos nós da rede, para fazer a negociação dinâmica de QoS são:

• Estabelecer Conexao. O nó deve analisar a disponibilidade de recursos locais. Se for

possível aceitar os parâmetros pedidos, reserva tais parâmetros em sua base de dados

local para aquela conexão e passa a PDU para frente até o nó destino. Se o pedido não

puder ser aceito, o nó deve enviar uma PDU Cancelar_Recursos para o nó anterior a

ele, e a conexão não é estabelecida. Se o pedido de conexão for aceito por todos os

nós, o nó que pediu a conexão deve abrir uma conexão de dados, com os parâmetros

de QoS especificados e informar ao usuário o identificador dessa conexão de dados.

− Parâmetros: parâmetros de negociação de QoS

• Mais Recursos. Essa PDU só pode ser enviada se a conexão indicada estiver

estabelecida. Cada nó deve analisar a disponibilidade de recursos locais. Se for

possível aceitar os parâmetros pedidos, reserva tais parâmetros em sua base de dados

local, para aquela conexão, e passa a PDU para frente até o nó destino. Se o pedido

não puder ser aceito, o nó deve enviar uma PDU Cancelar_Recursos para o nó anterior

a ele, cancelando o pedido de renegociação, bem como os recursos alocados a mais

referentes a este pedido.


• Menos Recursos. Essa PDU só pode ser enviada se a conexão indicada estiver

estabelecida. Cada nó que receber esta PDU, deve subtrair de sua base de dados local,

os valores dos parâmetros enviados, correspondentes à conexão indicada, e adicionar


62

este valor à banda disponível do nó. A PDU deve ser enviada para o próximo nó, até

chegar no último. A PDU e os parâmetros devem ser aceitos por todos os nós. Deve

ser respeitado, para a banda alocada, o valor mínimo de banda de cada conexão.


• Terminar Conexao. Essa PDU só pode ser enviada se a conexão indicada estiver

estabelecida. Cada nó que receber esta PDU deve liberar os recursos correspondentes à

conexão que está sendo terminada, adicionar estes recursos à banda disponível do nó,

tirar a conexão da base de dados e passar a PDU para frente, até o último nó.


• Cancelar Recursos. Esta PDU deve ser enviada em resposta a uma PDU

Estabelecer_Conexao ou Mais_Recursos. Se for em resposta a um pedido de conexão,

a conexão não é estabelecida e é considerada como rejeitada. Se for em resposta a um

pedido de mais recursos o pedido é cancelado e considerado como rejeitado. O nó que

recebê-la, deve cancelar os recursos relativos aos parâmetros da PDU, para a conexão

identificada, e deve passar a PDU para o nó anterior, até chegar ao nó que fez a

solicitação inicial (cliente). O nó que iniciou a solicitação também deve cancelar os

recursos previamente alocados.


• Conexao Estabelecida. Deve ser enviada pelo último nó (servidor) ao nó anterior, até

chegar ao nó origem (cliente), para confirmar o estabelecimento de uma conexão.


• Mais Recursos Resp. Deve ser enviada pelo último nó (servidor) ao nó anterior, até

chegar no nó origem (cliente), para confirmar um pedido de mais recursos.


6.4.1.2 Formato das PDUs

As PDUs que trafegam pela rede ATM, são transmitidas por meio da função putmsg (int

fildes, const struct strbuf *ctlptr, const struct strbuf *dataptr, int flags). Todos os dados de

negociação devem trafegar dentro do campo de dados dessa função (figura 6.12). Cada

função, ao querer transmitir uma PDU, chama a função de transmitir PDU através do


63

driver ATM. Esta função chama a função putmsg. São passados como argumentos os

seguintes campos: código da PDU, identificador da conexão e parâmetros de negociação.

As PDUs Terminar_Conexao, Conexao_Estabelecida e Mais_Recursos_Resp não

necessitam de parâmetros de negociação.

O formato das PDUs, portanto, é o da função putmsg, que é o mesmo formato

para transmissão de dados, utilizando o padrão de comunicação STREAMS.

C ó d i g oP D U

I d e n t i f i c .C o n e x ã o

P a r â m e t r o s

2 b y t e s 2 b y t e s 4 . . . n b y t e s

Figura 6.12 - Estrutura do buffer de dados da função putmsg onde são transmitidas as

primitivas de negociação

Os valores para os códigos das PDUs são: 1 - Estabelecer Conexão; 2 - Mais

Recursos; 3 - Menos Recursos; 4 - Terminar Conexão; 5 - Conexão Aceita; 6 - Cancelar

Recursos; 7 - Mais Recursos Resp. O campo de identificador da conexão pode variar de 1

a 1000, podendo-se ter até 1000 pedidos de conexão. O único parâmetro negociado no

esquema é o banda passante.

6.4.1.3 Comportamento: Máquinas de Estados Finitos

O serviço de negociação dinâmica de QoS requer a execução de módulos de programa

nos diversos nós da rede (cliente, intermediário e servidor). Nesta seção será descrito,

através de máquinas de estados finitos, o comportamento de cada tipo de nó.

Ações, Estados, Eventos e Predicados

As ações, estados, eventos e predicados utilizados nas máquinas de estados finitos são

descritos a seguir.

• Ações

− Reserva recursos locais. Reserva os recursos necessários na base de dados local para

um pedido de conexão ou de mais recursos.

− Envia PDU para próximo nó. Transmite a PDU que recebeu para o próximo nó da

rede.


64

− Envia PDU para nó anterior. Transmite a PDU que recebeu para o nó anterior da rede.

− Cancela recursos locais. Cancela os recursos previamente alocados para uma

determinada conexão. Podem ser cancelados recursos relativos a um pedido de

conexão ou de mais recursos.

− Reserva mais recursos. Reserva mais recursos na base de dados local para uma

conexão, de acordo com um pedido de mais recursos.

− Subtrai recursos. Subtrai recursos da base de dados local para uma conexão.

− Abre conexão para dados. Abre uma conexão para transmissão dos dados da aplicação

com os parâmetros de QoS especificados no pedido de conexão. Esta ação só será

tomada no caso de um pedido de conexão ter sido aceito por todos os nós.

− Atualiza Primitiva. Atualiza o valor de banda do parâmetro da próxima primitiva da

lista de primitivas, relativa à conexão. O trabalho foi executado sem uma aplicação

real e baseado em uma lista de primitivas geradas aleatoriamente. Quando um pedido

de mais recursos não é aceito, o valor da próxima primitiva de serviço deve ser

atualizado para corresponder ao valor que se teria caso o pedido tivesse sido aceito.

− Descarta PDU. Ignora uma PDU que tenha código inválido.

• Estados

Os estados são referentes a situação das conexões em um determinado nó. Um mesmo nó

pode estar em estados diferentes para cada conexão (uma conexão pode estar no estado

inicial e outra no estado conexao_estabelecida).

− Início. Estado de uma conexão antes de existir um pedido de estabelecimento de

conexão.

− Estabelecendo_Conexao. Estado de uma conexão em que já foi feito o pedido de

estabelecimento de conexão e está aguardando a resposta de confirmação dos nós da

rede.

− Conexao_Estabelecida. Estado em que uma conexão foi estabelecida (o nó cliente

solicitou o estabelecimento e todos os nós da rede, intermediários e final, aceitaram).

• Eventos


65

− Estabelecer_Conexao. O usuário, situado no nó cliente, deseja estabelecer uma

conexão com o nó servidor.

− Mais_Recursos. A aplicação, em um determinado momento, necessita de mais

recursos para atender aos requisitos de qualidade.

− Menos_Recursos. A aplicação, em um determinado momento, possui recursos a mais

do que o necessário e pode liberar a quantidade excedente.

− Cancelar_Recursos. Um pedido de estabelecimento de conexão ou de mais recursos

não pode ser aceito por um dos nós da rede e portanto, os recursos previamente

alocados pelos nós anteriores para este pedido devem ser cancelados.

− Terminar_Conexao. O usuário, situado no nó cliente, deseja terminar uma conexão

estabelecida com o nó servidor.

− PDU inválida. PDU que possua código inválido, não previsto.

• Predicados

− Não há recursos locais. O nó não possui recursos disponíveis para aceitar um pedido

de conexão ou um pedido de mais recursos.

− Há recursos locais. O nó possui recursos disponíveis para aceitar um pedido de

conexão ou um pedido de mais recursos.

Máquina de Estados Finitos do Nó Cliente

A máquina de estados finitos do nó cliente é mostrada na figura 6.13. A aplicação

multimídia é apresentada neste nó e é a partir dele que é iniciado o serviço de negociação

dinâmica de QoS.


66

Início EstabelecendoConexão

ConexãoEstabelecida

Estabelecer_Conexao [Não há recursos locais]

Informa à aplicação

Estabelecer_Conexao [Há recursos locais]

Reserva recursos locais Envia PDU p/ próximo nó

Cancelar_Recursos

Cancela recursos locais Informa à aplicação

Terminar_Conexao

Exclui conexão Envia PDU p/ próximo nó

Mais_Recursos [Há recursos locais]

Reserva mais recursos Envia PDU p/ próximo nó

Mais_Recursos [Não há recursos locais]

Menos_Recursos

Subtrai recursos Envia PDU p/ próximo nó

Encerra conexão de dados atual Abre nova conexão para dados

Informa à aplicação Id da nova conexão

Atualiza primitivaCancelar_Recursos

Cancela recursos locais Atualiza primititva

Conexao_Estabelecida

Abre conexão para dadosInforma à aplicação Id da conexão de dados

Primitiva inválida

Descarta primitiva

Figura 6.13 - Máquina de Estados Finitos do Nó Cliente

Nó Servidor

A máquina de estados finitos do nó servidor é apresentada na figura 6.14. A aplicação

multimídia está armazenada neste nó e ele aceita ou rejeita os pedidos de renegociação,

do serviço de negociação dinâmica de QoS.

Início


Envia primitiva Cancelar_Recursos

Estabelecer_Conexao [Há recursos locais]

Reserva recursos locais Envia PDU Conexao_Estabelecida

Terminar_Conexao

Exclui conexão



Reserva mais recursos


Menos_Recursos

Subtrai recursos

PDU inválida

Descarta PDU

Envia Cancelar_Recursos para nó anterior

Figura 6.14 - Máquina de Estados Finitos do Nó Servidor

Nós Intermediários


67

Início EstabelecendoConexão



Envia PDU Cancelar_Recursos p/ nó anteriorEstabelecer_Conexao [Há recursos locais]

Reserva recursos locais Envia PDU p/ próximo nó

Cancelar_Recursos

Cancela recursos locais Envia PDU p/ nó anterior

Conexao_Estabelecida

Envia PDU p/ nó anterior

Terminar_Conexao

Exclui conexão Envia PDU p/ próximo nó


Reserva mais recursos Envia PDU p/ próximo nó


Menos_Recursos

Subtrai recursos Envia PDU p/ próximo nó

Cancelar_Recursos

Cancela Recursos Envia PDU p/ nó anterior

Envia Cancelar_Recursos para nó anterior

PDU inválida

Descarta PDU

Figura 6.15 - Máquina de Estados Finitos do Nó Intermediário

Obs: Próximo nó: Nó seguinte no sentido Cliente → Servidor

Nó anterior: Nó seguinte no sentido Servidor → Cliente

A figura 6.15 mostra a máquina de estados finitos para os nós intermediários da

rede. Estes nós encontram-se entre os nós cliente e servidor e aceitam ou rejeitam os

pedidos de negociação do serviço de negociação dinâmica de QoS.


Neste capítulo foi especificada uma arquitetura de negociação de QoS para uma rede

ATM. O objetivo do trabalho foi definir e implementar a arquitetura mostrada. O

esquema citado na seção 5.1 motivou a criação desta arquitetura.

Foi definida a camada de negociação dinâmica de QoS, juntamente com a

descrição do seu serviço e do protocolo de negociação executado entre os diversos nós de

uma rede ATM. Foram mostradas também as primitivas de serviço, suas funções e


68

diagramas de tempo, as PDUs e as máquinas de estados finitos referentes aos módulos a

serem executados nos nós da rede (cliente, intermediário e servidor).


69

Capítulo 7

Projeto e Implementação do Serviço deNegociação Dinâmica em uma Rede ATM

Este capítulo apresenta o projeto do serviço de negociação dinâmica de QoS, mostrando

os módulos e as principais estruturas de dados. São abordados também aspectos de

implementação, como as estruturas de execução do esquema e os algoritmos

correspondentes aos módulos do projeto.

7.1 Projeto

Esta seção apresenta a estrutura do projeto, em termos de módulos de programa,

principais estruturas de dados e algoritmos.

7.1.1 Módulos

Os módulos de programas, pertencentes ao projeto, são: módulos cliente e simulador de

aplicação, que executam no nó cliente; módulo intermediário, que executa nos nós

intermediários e módulo servidor, que é executado no nó servidor. Uma descrição mais

detalhada de cada módulo, é dada a seguir. O módulo Cliente é a entidade do serviço que

faz interface com o usuário, tendo como principais funções:

− Alocar canal de controle para transmitir as primitivas de negociação;

− Alocar canais de dados com os requisitos necessários de QoS, para transmissão

de dados de aplicações multimídia;

− Disponibilizar primitivas de serviço (Estabelecer Conexão, Mais Recursos,

Menos Recursos e Terminar Conexão) para o usuário do serviço de negociação

dinâmica;

− Tratar PDUs recebidas da rede (Cancelar Recursos, Conexão Estabelecida e

Mais Recursos Resp);


70

− Transmitir e receber informação utilizando a rede ATM.

O módulo Simulador de aplicação, simula uma aplicação usuária do serviço de

negociação. Este módulo é necessário porque o esquema não foi executado com uma

aplicação real, já que não havia uma aplicação disponível. Não faz parte do serviço. Suas

principais funções são:

− Gerar, aleatoriamente, uma lista de primitivas de negociação que servem para

solicitar o serviço de negociação dinâmica;

− Ler a lista gerada e fazer as solicitações dos pedidos de negociação dinâmica.

O módulo Intermediário, é a entidade do serviço, presente nos nós

intermediários da rede, tendo como principais funções:


− Tratar PDUs recebidas da rede (Estabelecer Conexão, Mais Recursos, Menos

Recursos, Terminar Conexão, Cancelar Recursos, Conexão Estabelecida e

Mais Recursos Resp);


O módulo Servidor é a entidade do serviço localizada no nó servidor da rede,

tendo como principais funções:


− Tratar PDUs recebidas da rede (Estabelecer Conexão, Mais Recursos, Menos

Recursos e Terminar Conexão);

− Enviar PDUs de resposta (Conexão Estabelecida e Mais Recursos Resp);


7.1.2 Estruturas de Dados

As estruturas de dados necessárias para a execução do projeto são:


71

• Buffer de transmissão para dados. Espaço onde são colocados os dados das

PDUs a serem transmitidas através da função putmsg;

• Buffer de recepção para dados. Espaço onde são colocados os dados das PDUs

recebidas pela função getmsg;

• Tabela com nó anterior e próximo nó. Indica qual o nó anterior e qual o

próximo nó de cada nó da rede;

• Interface. Identifica por qual interface os dados são enviados e recebidos;

• Descritor de arquivo.

• Ponto físico de conexão (ppa).

• Quantidade de conexões. Indica a quantidade de conexões que podem ser

estabelecidas em um nó;

• Parâmetros de negociação. Parâmetros necessários para negociação dinâmica

(por exemplo, largura de banda);

7.1.2.1 Base de Informações de Gerenciamento

A Base de Informações de Gerenciamento (Management Information Base - MIB) é a

estrutura central do esquema e está presente em todos os nós da rede. Esta estrutura

permite fazer o controle dos recursos alocados, informando quanto há de recurso alocado

para cada conexão e, consequentemente, quanto há de recurso disponível em cada nó.

Esta estrutura de dados possui os seguintes campos:

• Banda passante total do nó; /* Capacidade total do nó */

• Banda real do nó utilizada pelas conexões; /* Banda real (física) utilizada pelas

conexões */

• Banda passante alocada pelas conexões; /* Banda alocada (lógica) pelas

conexões */

• Tabela de conexões /* Tabela c/ os dados de todas as conexões */

− Identificador; /* Identificador de uma conexão */

− Estado; /* Estado do nó em relação a uma conexão */

− Banda passante mínima; /* Banda passante mínima p/ uma conexão */

− Banda passante alocada (lógica); /* Banda alocada utilizada por uma

conexão */

− Banda passante real (física); /* Banda real utilizada por uma conexão */


72

7.2 Implementação

Nesta seção são apresentadas as estruturas de execução (real e do protótipo) do esquema

de negociação de QoS e os algoritmos correspondentes aos módulos descritos na seção

7.1.1. O trabalho foi desenvolvido no Laboratório de Redes de Alta Velocidade da

Universidade Federal de Minas Gerais - UFMG.

7.2.1 Estrutura de Execução Real do Esquema de Negociação

A estrutura física, real, de execução do esquema, corresponde à apresentada na figura 6.1.

Os módulos cliente e servidor executam em uma estação de trabalho e os módulos

intermediários, em comutadores ATM. No entanto, em uma primeira implementação, no

ambiente disponível do laboratório, o esquema foi um pouco modificado. Isto porque o

comutador existente no Laboratório ATM, possui uma arquitetura fechada, na qual não se

pode alterar o programa de controle de admissão de conexões (CAC). Portanto, a

estrutura de execução real do esquema desenvolvido, não corresponde à estrutura de

execução do protótipo.

Comutador ATM

Nó ClienteNó Intermediário

Nó Servidor

Comutador ATM

Nó Intermediário

Figura 7.1 - Estrutura de Execução do Esquema de Negociação

7.2.2 Estrutura de Execução do Protótipo do Esquema deNegociação

Os equipamentos utilizados na implementação do trabalho foram:

• Um comutador LightStream 100 ATM (A100 HyperSwitch) da Cisco, com

suporte para 16 linhas ATM, a 155Mbps. Segue as recomendações do padrão UNI

3.0 do ATM Forum [Cisco95].


73

• Uma estação de trabalho Sparc 5 com placa ATM do tipo Sbus, da Sun, de

155Mbps, que segue as recomendações do padrão UNI 3.0, do ATM Forum. A

placa ATM é ligada ao comutador ATM através de fibra ótica.

• Uma estação de trabalho Sparc 5 com placa ATM do tipo Sbus, da Sun, de

155Mbps, que segue as recomendações do padrão UNI 3.0, do ATM Forum. A

placa ATM é ligada ao comutador ATM através de cabo par trançado, categoria 5.

• Duas estações de trabalho Sun Ultra 1, com placas ATM do tipo Sbus, da Sun, de

155Mbps, que seguem as recomendações do padrão UNI 3.0 do ATM Forum. As

placas ATM são ligadas ao comutador ATM através de cabo par trançado,

categoria 5.

Comutador ATM A100 - 155Mbps

Nó Cliente Nós Intermediários Nó Servidor

Sun Sparc 5 Sun Ultra 1 Sun Ultra 1

SunATM-155 SBus SunATM-155 SBus SunATM-155 SBus

K2 Everest Elbrus

Figura 7.2 - Estrutura de Execução do Protótipo

Na estrutura de execução do protótipo, mostrada na figura 7.2, os módulos

intermediários, que deveriam ser executados no comutador ATM, são executados em

estações de trabalho

7.2.3 Dificuldades Encontradas na Implementação

Durante o desenvolvimento dos programas foram encontradas algumas dificuldades,

umas devido a complexidade do esquema e outras devido a aspectos de implementação.

Em relação a complexidade, a maior dificuldade encontrada foi a elaboração de um

programa para cada tipo de nó (cliente, intermediário e servidor). Os programas têm

muita coisa em comum, mas existem detalhes específicos em cada módulo.

O único nó que recebe e trata as primitivas de negociação, fazendo a interface

com a camada superior, é o nó cliente. Portanto, o nó cliente interpreta primitivas e PDUs

de negociação. O nó intermediário recebe e trata PDUs de dois nós adjacentes. Ele tem


74

dois canais de controle alocados. Este nó deve executar consulta nos dois fluxos

estabelecidos e saber interpretar de onde chegou cada PDU. O nó servidor é o mais

simples e deve apenas receber as PDUs e enviar respostas de acordo com o tipo de PDU

recebido e a disponibilidade do nó. As ações que devem ser tomadas quando chega uma

PDU dependem de cada tipo de nó.

Em relação às dificuldades de implementação podem ser citadas a utilização do

padrão STREAMS na execução e a execução de consulta na fila de mensagens recebidas

no driver da placa ATM. Estes problemas foram solucionados utilizando [Sun95]

[SunOS93] [Steve90].

Um aspecto interessante da implementação foi constatar que o driver utilizado não

permite que sejam alocados valores de banda menores que 1Mbps. Isso acarreta uma

perda de banda em relação ao valor real (seção 5.1). Quando uma conexão solicita um

valor de banda igual a 0Mbps ou 0,5Mbps, deve na verdade ser alocado, fisicamente no

driver, 1Mbps, o que gera uma perda de 1Mbps ou 0,5Mbps, respectivamente. Isso

contribui para diminuir a banda total do nó, o que influi no percentual de rejeição dos

pedidos de renegociação.

7.2.4 Algoritmos

A seguir, são apresentados os algoritmos dos módulos de execução Cliente, Intermediário

e Servidor. Existem algumas semelhanças entre os algoritmos. As PDUs enviadas e

recebidas por cada nó são as mesmas, alterando apenas o valor dos parâmetros e a

interpretação que é dada a cada PDU, de acordo com o módulo que está sendo executado.

O algoritmo do Cliente, além de receber e transmitir PDUs, recebe e trata as primitivas

vindas da camada superior, ou seja, da aplicação multimídia.

Os algoritmos foram implementados na linguagem de programação C, utilizando

a API (Application Programmers’ Interface) da Sun para as chamadas às funções ATM.

A figura 6.3 mostra os algoritmos para alocação do canal de controle, transmissão e

recepção através da rede ATM e de simulação da aplicação. Os algoritmos Cliente,

Servidor e Intermediário são apresentados nas figuras 7.4, 7.5 e 7.6, respectivamente.

Aloca canal de controle

Define largura de banda para canal de controle;

Preenche buffer de transmissão para controle;

Preenche buffer de transmissão para dados (não possui dados de negociação);


75

Cria ponto físico de conexão (ppa);

Chama funções da API ATM: open, attach, allocate_bw e add_vpci;

Chama função putmsg para transmitir através do fluxo do canal de controle.

Transmite_ATM

Preenche buffer de transmissão para controle;

Preenche buffer de transmissão para dados (código da PDU, identificador da conexão e

parâmetros);

Chama função putmsg para transmitir através do fluxo do canal de controle.

Recebe_ATM

Chama função getmsg para receber dados através do fluxo do canal de controle;

Preenche buffer de recepção para controle;

Preenche buffer de recepção para dados (código da PDU, identificador da conexão e

parâmetros).

Simulador de Aplicação

Gera lista aleatória de primitivas de negociação;

Enquanto não for fim da lista:

- Lê primitiva da lista;

- Chama serviço de negociação com uma determinada primitiva;

Figura 7.3 - Algoritmos de Apoio

Recebe primitiva ou PDU;

Se Estado = Inicio

Então Se Primitiva = Estabelecer_Conexao

Então Verifica se o nó possui recursos p/ atender pedido de conexão com

parâmetros;

Se o nó possuir recursos

Então Reserva recursos de acordo com parâmetros;

Envia primitiva Estabelecer_Conexao para o próximo nó da rede;

Estado = Estabelecendo_Conexao;

Senão Se Estado = Estabelecendo_Conexao

Então Se PDU = Conexao_Estabelecida

Então Estado = Conexao_Estabelecida;

Senão Se PDU = Cancelar_Recursos

Então Cancela recursos previamente alocados para aquela conexão;


76

Estado = Inicio;

Senão Se Estado = Conexao_Estabelecida

Então Se Primitiva = Mais_Recursos

Então Verifica se a conexão referenciada existe em sua tabela;

Se conexão existe

Então Verifica se o nó possui recursos para atender o pedido;


Então Reserva mais recursos p/ conexão de acordo com

parâmetros;

Envia primitiva Mais_Recursos para o próximo nó da rede;

Senão Cancela recursos alocados a mais nos nós anteriores;

Senão Se Primitiva = Menos_Recursos

Então Verifica se a conexão referenciada existe em sua tabela;

Se conexão existe

Então Subtrai os recursos p/ conexão, observando valor mínimo;

Envia primitiva Menos_Recursos p/ próximo nó da rede;


Então Verifica se a conexão referenciada existe em sua

tabela;

Se conexão existe

Então Cancela recursos previamente alocados;

Se Estado = Estabelecendo_Conexao

Então Estado = Início;

Senão Se Primitiva = Terminar_Conexao

Então Verifica se conexão referenciada existe na

tabela;

Se conexão existe

Então Retira entrada da tabela para conexão;

Envia Terminar_Conexão p/ próximo nó.

Figura 7.4 - Algoritmo do Módulo Cliente

Recebe PDU;

Se Estado = Inicio

Então Se PDU = Estabelecer_Conexao

Então Verifica se o nó possui recursos p/ atender pedido de conexão com

parâmetros;



77


Envia PDU Estabelecer_Conexao para o próximo nó da rede;

Estado = Estabelecendo_Conexao;

Senão Envia PDU Cancelar_Recursos para o nó anterior da rede;

Senão Se Estado = Estabelecendo_Conexao

Então Se PDU = Cancelar_Recursos

Então Cancela recursos previamente alocados para aquela conexão;

Envia PDU Cancelar_Recursos para o nó anterior da rede;

Estado = Inicio;

Senão Se PDU = Conexao_Estabelecida

Então Envia PDU Conexao_Estabelecida para o nó anterior da rede;

Estado = Conexao_Estabelecida;


Então Se PDU = Mais_Recursos



Então Reserva mais recursos p/ conexão de acordo com

parâmetros;

Envia PDU Mais_Recursos para o próximo nó da rede;

Senão Cancela recursos nos nós anteriores;

Senão Se PDU = Menos_Recursos


Envia PDU Menos_Recursos p/ próximo nó da rede;


Então Cancela recursos previamente alocados;

Envia PDU Cancelar_Recursos p/ nó anterior;

Se Estado = Estabelecendo_Conexao

Então Estado = Início;

Senão Se PDU = Terminar_Conexao

Então Retira entrada da tabela para conexão;

Envia Terminar_Conexao p/ próximo nó.

Figura 7.5 - Algoritmo do Módulo Intermediário

Recebe PDU;

Se Estado = Inicio

Então Se Primitiva = Estabelecer_Conexao

Então Verifica se nó possui recursos p/ atender pedido de conexão com

parâmetros;


78



Envia PDU Conexao_Estabelecida para o nó anterior da rede;

Estado = Conexao_Estabelecida;

Senão Envia PDU Cancelar_Recursos para o nó anterior da rede;


Então Se Primitiva = Mais_Recursos



Então Reserva mais recursos p/ conexão de acordo com parâmetros;

Senão Cancela recursos nos nós anteriores;

Senão Se Primitiva = Menos_Recursos


Senão Se Primitiva = Terminar_Conexao

Então Retira entrada da tabela para a conexão.

Figura 7.6 - Algoritmo do Módulo Servidor


Neste capítulo foi mostrado o projeto e a implementação do serviço de negociação

dinâmica de QoS. No projeto foram mostrados os módulos e as principais estruturas de

dados. Na implementação foram mostradas as estruturas de execução real e do protótipo,

do esquema de negociação, e os algoritmos.


79

Capítulo 8

Testes e Análise dos Resultados

Este capítulo apresenta uma análise da execução dos programas e seus resultados.

Primeiramente são mostrados o que significa cada parâmetro de execução e como foram

planejados os testes. Depois são analisados os resultados obtidos da execução.

8.1 Introdução

O principal objetivo da execução dos testes e análise de seus resultados foi observar o

percentual de rejeição dos pedidos de renegociação de banda passante. Este percentual


80

está relacionado com a garantia de QoS oferecida às conexões estabelecidas. Quanto

maior o percentual, menor o nível de garantia.

Para fazer uma análise detalhada e descobrir os principais fatores que influem no

percentual de rejeição, foram realizados vários experimentos. Em cada experimento

foram variados os valores dos parâmetros escolhidos. Os parâmetros definidos como

importantes, para a análise do percentual, foram: a capacidade de banda dos nós, a

quantidade de máquinas (nós) utilizada, a quantidade de pedidos de conexão, o tempo de

simulação, a reserva mínima e a reserva máxima de banda.

A capacidade de banda de um nó é a quantidade total de banda que um nó tem

disponível. Esta capacidade é utilizada para atender solicitações de pedidos de

estabelecimento de conexão ou de pedidos de renegociação.

A quantidade de pedidos de conexão diz respeito ao total de pedidos de

estabelecimento de conexões, que serão feitos. Estes pedidos podem ser aceitos ou

rejeitados.

Outro parâmetro analisado, foi a quantidade de máquinas a ser utilizada nos

experimentos. O objetivo disto, era saber se a quantidade de máquinas, ou melhor, a

quantidade de nós intermediários, influi no percentual de rejeição.

O tempo de simulação, é o tempo utilizado para gerar as primitivas de

estabelecimento de conexão e de pedidos de renegociação. Vale salientar que o esquema

de negociação dinâmica de QoS aqui implementado não é uma simulação. A única etapa

que é simulada é o comportamento de uma aplicação multimídia real, ou seja, o tráfego

gerado por essa aplicação. Através da simulação são criados os pedidos de

estabelecimento de conexão e de renegociação.

Para explicar como o tempo de simulação funciona, é bom que se faça uma breve

explicação de como o programa executa. Como o programa não foi testado com uma

aplicação real, é necessário que seja feita uma simulação, para gerar as primitivas de

serviço. O programa gera, inicialmente, todas as primitivas de estabelecimento de

conexão. Cada primitiva possui um timestamp, de valor maior que zero e menor que o

tempo de simulação. Após serem geradas, as primitivas são inseridas em uma lista

encadeada.

O programa lê esta lista e executa as operações correspondentes às primitivas

lidas. Ao encontrar uma primitiva de pedido de conexão, ele executa o processo de

estabelecimento de conexão e gera as primitivas de pedidos de renegociação, relativas a

esta conexão. Cada primitiva de renegociação também possui um valor de timestamp, que

deve estar dentro do mesmo intervalo utilizado para gerar a primitiva de pedido de


81

conexão. Depois que são gerados todos os pedidos de renegociação, é gerada uma

primitiva de terminar conexão (para aquela conexão), e todas as primitivas são inseridas

na lista, em ordem crescente de timestamp. O programa então, continua a executar, lendo

as primitivas da lista e realizando os procedimentos necessários para cada primitiva.

Os outros dois parâmetros considerados, para a análise do percentual de rejeição

dos pedidos de renegociação, foram os valores de reserva mínima e máxima de banda. Na

fase de estabelecimento de uma conexão, é indicado, pela conexão, um valor de banda

inicial, chamado também de valor mínimo ou valor de reserva. Este valor fica alocado

para a conexão enquanto ela durar, e garante um nível de garantia de qualidade para a

conexão. Quanto maior o valor de reserva, mais banda a conexão terá alocada para ela e

mais probabilidade de ter seus pedidos de renegociação aceitos.

O valor de reserva é um número gerado dentro do intervalo fechado [reserva

mínima, reserva máxima]. Os dois valores, limites do intervalo, foram variados, ao longo

do experimento, para se ter noção de sua influência e, consequentemente, do valor de

reserva inicial, no percentual de rejeição de renegociação.

Para analisar a capacidade de banda do nó, foram realizados experimentos

utilizando nós com capacidade de banda de 130Mbps, 100Mbps e 65 Mbps. Em relação a

quantidade de máquinas, foram realizados experimentos utilizando-se três máquinas (1

cliente, 1 nó intermediário e 1 servidor) e quatro máquinas (1 cliente, 2 nós

intermediários e 1 servidor). As máquinas referidas aqui são do tipo Workstation Sun

Ultra 1 e Sparc 5, como foi mostrado na figura 7.2. Para os pedidos de conexão, foram

definidos experimentos com 100, 200, 300, 400, 500, 600, 700 e 800 pedidos de conexão.

O tempo de simulação variou de 15 a 120 minutos. Os valores de tempo utilizados foram

15, 30, 45, 60, 75, 90, 105 e 120 minutos.

A reserva mínima assumiu valores variando de 1Mbps a 6Mbps. Estes valores

foram: 1.0, 1.5, 2.0, 2.5, 3.0, 3.5, 4.0, 4.5, 5.0, 5.5 e 6.0Mbps. A reserva máxima assumiu

valores variando de 2.5Mbps a 6Mbps, sendo estes valores iguais a: 2.5, 3.0, 3.5, 4.0, 4.5,

5.0, 5.5 e 6.0Mbps. O valor de reserva inicial, portanto, é um valor gerado dentro do

intervalo formado pelos dois valores extremos de reserva, a reserva mínima e a reserva

máxima. Considerando todas as possibilidades de combinação entre estes dois valores, o

valor de reserva inicial pode variar de 1Mbps a 6Mbps. A taxa de pico das conexões é de

6Mbps, o que razoável para transmissão de vídeo MPEG (Moving Picture Expert Group)

[Solari97]. Este tipo de aplicação é a que está sendo idealizada neste trabalho.


82

8.2 Elaboração dos Testes

De acordo com [Montg91], para executar os programas com todos os conjuntos de

valores e obter resultados relevantes, pode-se utilizar uma matriz de valores, conhecida

como quadrado latino. Este quadrado é mostrado na tabela 8.1. A primeira coluna

corresponde a quantidade de pedidos de conexão. Na primeira linha aparecem os valores

para reserva máxima e no corpo da tabela estão os tempos de simulação em minutos.

Para executar os programas deve-se utilizar os valores da tabela para cada

combinação de valores de reserva mínima, capacidade do nó e quantidade de máquinas

(nós). Para cada valor de reserva mínima (1.0, 1.5, 2.0, 2.5, 3.0, 3.5, 4.0, 4.5, 5.0, 5.5 e

6.0Mbps), em conjunto com os valores de capacidade dos nós (130, 100 e 65Mbps) e de

quantidade de máquinas (3 e 4), são executadas várias simulações, utilizando os

conjuntos de valores da tabela (quantidade de conexão, valor máximo de reserva e tempo

de simulação). Para cada combinação de valor mínimo e máximo de banda, quantidade de

pedidos de conexão, de tempo de simulação, capacidade dos nós e quantidade de

máquinas, foram feitas três execuções. Alguns valores de parâmetros foram baseados nos

valores de testes executados em [Goula98], pois um dos objetivos da análise aqui

apresentada é fazer uma comparação entre os resultados obtidos pelos dois trabalhos.

Os experimentos com 4 máquinas e com capacidades menores dos nós, foram

executados apenas para analisar a influência destas duas características no percentual de

rejeição dos pedidos de renegociação. Para analisar todos os aspectos da negociação

dinâmica foram utilizadas 3 máquinas com capacidade total (130Mbps).

Quantidade de Valor Máximo de Reserva

Conexões 2,5 3,0 3,5 4,0 4,5 5,0 5,5 6,0

100 15 30 45 60 75 90 105 120

200 30 45 60 75 90 105 120 15

300 45 60 75 90 105 120 15 30

400 60 75 90 105 120 15 30 45

500 75 90 105 120 15 30 45 60

600 90 105 120 15 30 45 60 75

700 105 120 15 30 45 60 75 90

800 120 15 30 45 60 75 90 105

Tabela 8.1 - Matriz com Valores Utilizados nos Testes (Quadrado Latino)


83

8.3 Análise dos Resultados

Os resultados dos testes foram analisados por um programa de estatística, o MINITAB

[Minitab95]. As discussões a seguir tratam dos resultados gerados por esta análise.

Foram realizadas análises de variância, para todos os parâmetros citados na seção

anterior, em relação ao percentual de rejeição de pedidos de renegociação. Depois foi

feita uma análise de regressão para comparar todas as variáveis em conjunto.

8.3.1 Análise de Variância

A análise de variância é uma técnica estatística usada para a comparação de médias e

identificação de fatores associados a uma determinada resposta [Montg91]. Ao fazer a

análise de variância do percentual de rejeição de pedidos de renegociação, em relação a

algumas variáveis, esta análise considera cada variável isoladamente. As tabelas 8.2, 8.3,

8.4, 8.5, 8.6 e 8.7 mostram os resultados da análise de variância. Dos valores mostrados

na análise, os principais a serem observados são o valor p e o valor médio para cada nível

de experimento. O valor p indica o quanto uma variável é significativa em relação à

resposta (percentual de rejeição de pedidos de renegociação). Uma variável é considerada

significativa quando p < 0,05. O valor médio indica a média calculada para o percentual

de rejeição em relação ao parâmetro observado. Em cada uma das 6 tabelas referidas, a

coluna “level”, indica o valor do parâmetro que foi analisado.

De acordo com a tabela 8.2, a quantidade de nós não é significativo para o

percentual de rejeição de pedidos de renegociação. Realmente, a quantidade de nós em

uma rede, não influi no percentual de rejeição de renegociação. Pela tabela verifica-se que

o percentual de rejeição médio para 3 nós é de igual a 16.59% e para 4 nós é igual a

17.43%. Estes valores podem ser considerados equivalentes. O gráfico referente a esta

análise encontra-se na figura 8.1.

Um maior número de nós na rede, considerando um caminho único, pode influir

em características como retardo e variação do retardo, oferecidos pela rede. Um grande

número de nós na rede, pode causar um maior atraso na transmissão das mensagens de

controle ou um tempo de resposta maior para os pedidos. No entanto, em relação ao

percentual de rejeição, o que importa é a capacidade dos nós e não a quantidade deles. Se


84

todos os nós envolvidos tiverem a mesma capacidade de banda passante, os pedidos de

renegociação serão analisados e tratados da mesma maneira, por todos os nós, não

importando quantos nós existam na rede.

ANALYSIS OF VARIANCE ON Rej_Ren%

SOURCE p LEVEL MEAN

Qtd_Nós 0.567 3 16.59

4 17.43

Tabela 8.2 - Análise de Variância da Quantidade de Nós em Relação ao Percentual de

Rejeição de Pedidos de Renegociação

Percentual de Rejeição x Quantidade Nós

0

5

10

15

20

25

30

3 4

Quantidade de Nós

Rej

eiçã

o d

o s

Ped

ido

s d

e re

neg

oci

ação

(%

)

Figura 8.1 - Percentual de Rejeição de Renegociação x Quantidade de Nós

A capacidade dos nós, de fato, é um parâmetro muito importante, no que diz

respeito ao percentual de rejeição de renegociação, devido a multiplexação estatística dos

recursos. Quanto mais banda passante um nó tiver, mais pedidos de renegociação ele

poderá acomodar. Um nó começa a rejeitar pedidos de renegociação quando ele não tem

mais banda disponível, fisicamente, para aumentar o valor de banda de uma conexão.

Analisando, na tabela 8.3, os valores médios do percentual de rejeição (29,82% para

65Mbps, 21.91% para 100Mbps e 11.75% para 130Mbps), verifica-se que há um aumento

significativo no percentual de rejeição quando a capacidade do nó diminui.


SOURCE p LEVEL MEAN


85

Capac_No 0.000 65 29.82

100 21.91

130 11.75

Tabela 8.3 - Análise de Variância da Capacidade do Nós em Relação ao Percentual de


O gráfico da figura 8.2 mostra o valor do percentual de rejeição em relação a

capacidade dos nós. Como analisado anteriormente, pode-se perceber que o valor do

percentual diminui bastante quando é a aumentada a capacidade dos nós.

Percentual de Rejeição x Capacidade dos Nós

0

5

10

15

20

25

30

65 100 130

Capacidade dos Nós (Mbps)

Rej

eiçã

o d

os

Ped

ido

s d

e R

eneg

oci

ação

(%

)

Figura 8.2 - Percentual de Rejeição de Renegociação x Capacidade dos Nós

O parâmetro quantidade de pedidos de conexão é interessante de ser observado.

Os experimentos mostram que quando este parâmetro é pequeno, como por exemplo,

100, o percentual de rejeição assume um valor menor. No entanto, a medida que a

quantidade de pedidos aumenta, esse percentual aumenta, e chega a um ponto em que

praticamente fica estável. Isto ocorre na faixa entre 400 e 500 pedidos. Este fato acontece

porque com poucas conexões, um nó não alcança seu ponto de saturação e ainda possui

banda suficiente para ser compartilhada entre as conexões estabelecidas.

Quando os pedidos de conexão aumentam, o nó fica mais sobrecarregado, até que

atinge um certo nível de saturação. A partir daí (aqui no caso para os valores entre 400 e

500 pedidos), o aumento na quantidade de pedidos de conexão não tem mais tanta

influência porque o nó atingiu um limite de carga que não pode ser ultrapassado. A partir

deste ponto, passa a aceitar apenas uma certa quantidade de pedidos de conexão e esta

quantidade pode ser considerada um valor mais ou menos fixo. Portanto, se a quantidade


86

de pedidos de conexões aceitos pode ser considerado um valor fixo, o percentual de

rejeição também pode, pois pode-se assumir que será feita uma quantidade semelhante de

pedidos de renegociação, para uma mesma quantidade de conexões aceitas. Os valores

médios para o percentual de rejeição, em relação a quantidade de pedidos de conexão,

está mostrado na tabela 8.4.


SOURCE p LEVEL MEAN

Pedidos_Conexao 0.000 100 5.33

200 9.02

300 11.03

400 12.54

500 13.45

600 13.63

700 14.33

800 14.68

Tabela 8.4 - Análise de Variância da Quantidade de Pedidos de Conexão em Relação ao

Percentual de Rejeição de Pedidos de Renegociação

A quantidade de pedidos de conexão interfere no percentual de rejeição. A maior

influência acontece para valores em torno de 100, 200 e 300 conexões. Com um número

menor de conexões existe menos concorrência pelos recursos (banda passante) e uma

menor probabilidade de ocorrer rejeições. A partir de uma certa quantidade de pedidos de

conexão, por volta de 500, no entanto, a rede atinge um ponto de saturação e o percentual

de rejeição passa a ter uma menor variação. Esta situação é mostrada na figura 8.3.


87

Percentual de Rejeição x Qunatidade de Pedidos de Conexão

0

5

10

15

20

100 200 300 400 500 600 700 800

Quantidade de Pedidos de Conexão

Rej

eiçã

o d

os

Ped

ido

s D

e R

eneg

oci

ação

(%

)

Figura 8.3 - Percentual de Rejeição de Renegociação x Quantidade de Pedidos deConexão

O parâmetro tempo de simulação não tem influência sobre o percentual de

rejeição dos pedidos de renegociação. Isto pode ser comprovado pela tabela 8.5, através

do valor p, que é maior que 0,005, e pelos valores de média do percentual em relação a

cada valor de tempo em minutos. Percebe-se que não há uma grande variação entre estes

valores.

A explicação para o tempo de simulação não influir no percentual de rejeição é

justamente porque se trata de um valor percentual. Quando o tempo aumenta, a

quantidade de pedidos aumenta, pois quanto mais tempo uma conexão durar, mais

pedidos de renegociação ela poderá fazer. Consequentemente, a quantidade de rejeições

destes pedidos também pode aumentar, pois os pedidos aumentam, mas a capacidade do

nó permanece inalterada. Como o que está sendo medido, no entanto, é o percentual da

quantidade de rejeições em relação a quantidade de pedidos de renegociação, o valor

deste percentual deve-se manter estável, pois as duas quantidades tendem a aumentar

proporcionalmente. Quando a quantidade de rejeições aumenta é porque a quantidade de

pedidos também aumentou. Portanto, o percentual de rejeição não deve sofrer alteração

significativa. A figura 8.4 mostra o gráfico da relação entre o percentual de rejeição de

renegociação e o tempo de simulação.


SOURCE p


88

Tempo(m) 0.886 LEVEL MEAN

15 15.92

30 16.12

45 15.67

60 15.86

75 16.91

90 16.73

105 18.08

120 18.67

Tabela 8.5 - Análise de Variância do Tempo de Simulação em Relação ao Percentual de


Percentual de Rejeição x Tempo de Simulação

0

5

10

15

20

25

30

15 30 45 60 75 90 105 120

Tempo de Simulação (min)

Rej

eiçã

o d

os

Ped

ido

s d

e R

eneg

oci

ação

(%

)

Figura 8.4 - Percentual de Rejeição de Renegociação x Tempo de Simulação

A tabela 8.6 mostra que a reserva mínima é significativa para a análise do

percentual de rejeição. Isto acontece porque quando a reserva mínima é pequena, algumas

conexões podem fazer suas reservas iniciais com valores pequenos. Quanto menor o valor

da reserva inicial, menor é o nível de garantia oferecido pelo esquema. A reserva inicial é

o valor de banda que a conexão tem reservado para si e, de acordo com os conceitos de

banda alocada e banda real (seção 5.1), a aceitação ou rejeição de pedidos de

renegociação de uma conexão depende deste valor inicial. Pela tabela 8.6, observa-se que

quanto maior o valor de reserva mínima, menor o valor do percentual de rejeição.

A figura 8.5 mostra o gráfico do percentual de rejeição de pedidos de

renegociação em relação a reserva mínima. O gráfico foi gerado através do valor médio

do percentual de rejeição, em relação a cada valor de reserva mínima. Pode-se observar


89

que quanto menor for a reserva mínima, maior é o percentual de rejeição. Quanto mais

banda passante uma conexão reserva inicialmente, maior é o nível de garantia para esta

conexão. A partir do valor de reserva mínima igual a 4.0Mbps, o percentual de rejeição

fica próximo de zero, chegando a zero nos valores de reserva iguais a 4.5, 5.0, 5.5, e

6.0Mbps. Quando o valor de reserva mínima é igual a 6.0Mbps, é feita a alocação de pico

e a garantia de qualidade é determinística.


SOURCE p LEVEL MEAN

Res_Min 0.000 1.0 27.33

1.5 23.05

2.0 13.75

2.5 13.94

3.0 4.84

3.5 1.69

4.0 0.31

4.5 0.03

5.0 0.00

5.5 0.00

6.0 0.00

Tabela 8.6 - Análise de Variância da Reserva Mínima em Relação ao Percentual de


Percentual de Rejeição x Reserva Mínima

0

5

10

15

20

25

1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6

Reserva Mínima

Rej

eiçã

o d

os

Ped

ido

s d

e R

eneg

oci

ação

(%

)


90

Figura 8.5 - Percentual de Rejeição de renegociação x Reserva Mínima

Pela tabela 8.7 pode-se ver que a reserva máxima tem influência sobre o

percentual de rejeição dos pedidos de renegociação. Pelo mesmo raciocínio aplicado para

a reserva mínima, pode-se dizer que o valor de reserva máxima afeta o percentual de

rejeição, porque quanto maior puder ser a reserva inicial de uma conexão, maior o nível

de garantia para esta conexão.

Quanto maiores os valores de reserva mínima e máxima, maiores os valores

contidos no intervalo [reserva mínima, reserva máxima] e maior a probabilidade das

conexões fazerem reservas iniciais com valores grandes de banda, comparados ao valor

de pico de 6Mbps.


SOURCE p LEVEL MEAN

Res_Max 0.000 2.5 50.45

3.0 35.27

3.5 24.62

4.0 17.13

4.5 10.84

5.0 6.74

5.5 4.00

6.0 2.01

Tabela 8.7 - Análise de Variância da Reserva Máxima em Relação ao Percentual de



renegociação em relação a reserva máxima. O gráfico foi gerado através do valor médio

do percentual de rejeição, em relação a cada valor de reserva máxima. Seguindo o mesmo

raciocínio da análise feita para a reserva mínima, pode-se concluir que quanto maior o

valor da reserva máxima, menor o percentual de rejeição. O valor de reserva inicial para

uma conexão é gerado a partir do intervalo [Reserva Mínima, Reserva Máxima]. Quanto

maior estes dois valores, maior a probabilidade de uma conexão ter um valor alto de

reserva inicial de banda.

Pela figura 8.7 pode-se ver que quando existem muitas conexões, um dos

parâmetros que tem grande influência no percentual de rejeição de renegociação é a

reserva mínima. Mesmo tendo muitas conexões, se o valor de reserva mínima for igual ou

maior que 4.0Mbps, o percentual de rejeição é zero ou perto de zero.


91


renegociação em relação a reserva mínima. As linhas do gráfico representam os valores

de reserva máxima. Algumas linhas do gráfico são descontínuas porque reserva máxima

não pode ser menor que reserva mínima. Estes valores são dependentes dos valores de

reserva mínima, pelo fato de que não se pode ter um intervalo [reserva mínima, reserva

máxima] com valores , por exemplo, maiores que 2.5Mbps e menores que 3.0Mbps.

Percentual de Rejeição x Reserva Máxima

0

5

10

15

20

25

30

35

40

45

50

2.5 3 3.5 4 4.5 5 5.5 6

Reserva Máxima

Rej

eiçã

o d

os

Ped

ido

s d

e R

eneg

oci

ação

(%

)

Figura 8.6 - Percentual de Rejeição de Renegociação x Reserva Máxima

Com os valores de reserva mínima igual a 3.5 e de reserva máxima igual a 4.5,

tem-se um percentual de rejeição muito próximo de zero. A partir daí, se for aumentado

um dos dois valores, o percentual passa a ser zero.


92

Conexões em Relação a Reserva e Percentual de Rejeição

0

5

10

15

20

25

30

1

1.5 2

2.5 3

3.5 4

4.5 5

5.5 6

Reserva Mínima

Rej

eiçã

o d

e P

edid

os

de

Ren

ego

ciaç

ão

(%)

100

200

300

400

500

600

700

800

Figura 8.7 - Percentual de Rejeição de Renegociação em Relação a Reserva Mínima

Percentual de Rejeição x Reserva Máxima

0

10

20

30

40

50

60

1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6Reserva Mínima

Rej

eiçã

o d

os

Ped

ido

s d

e R

eneg

oci

ação

(%

) 2.5

3

3.5

4

4.5

5

5.5

6

Figura 8.8 - Percentual de Rejeição de renegociação em Relação a Reserva Mínima eMáxima

8.3.2 Análise de Regressão


93

Análise de Regressão é uma técnica estatística utilizada para investigar e modelar o

relacionamento entre as variáveis. É um procedimento iterativo que determina a equação

que representa este relacionamento e estima os seus parâmetros. A seguir, testa a

qualidade do ajuste, quando então, avalia se o modelo sugerido se adapta bem aos dados

observados. Ao final desta segunda etapa, pode-se concluir pela adequação do modelo e

adotá-lo ou pode-se concluir que ele não é satisfatório e sugerir outro, voltando à etapa

inicial e repetindo todo o procedimento.

Ao fazer a análise de regressão do percentual de rejeição de pedidos de

renegociação em relação as variáveis capacidade do nó, reserva mínima, reserva máxima

e quantidade de conexões, chegou-se ao resultado mostrado na tabela 8.8 As variáveis

máquinas e tempo de simulação não entraram nesta análise porque foram avaliadas como

irrelevantes para o percentual de rejeição.

O valor R-sq = 90.8% mostra o quanto o modelo sugerido se adapta aos dados

observados. Este valor demonstra que o modelo explica 90,8% da variabilidade dos casos

que podem ocorrer na execução do esquema.

Ao elevar o cálculo dos fatores ao quadrado, garante-se que o valor do percentual

de rejeição calculado, será positivo. Ao aplicar a função seno neste resultado, garante-se

que o percentual assumirá um valor entre 0 e 1, ou seja, 0% e 100%.

Pela equação obtida pode-se observar que todos os fatores são significativos (p <

0,005) e que a variável que mais afeta o percentual de rejeição é capacidade do nó,

seguida pela reserva máxima, pela reserva mínima e pela quantidade de pedidos de

conexão.

The regression equation is

Rej_Ren% = sin(

2.34-0.293 Res_Min+0.000981 RMin2+0.000584 Conexoes

-0.440 Res_Max + 0.0320 RMax2 - 0.00635 Capac_No

-0.000056 RMin*Con+0.00719 RMin*RMx+0.00186 RMin*CN

-0.000057 Con*RMx )^2

Predictor p

Constant 0.000

Res_Min 0.000

RMin2 0.000

Conexoes 0.000

Res_Max 0.000

RMax2 0.000

Capac_No 0.000

RMin*Con 0.000

RMin*RMx 0.000


94

RMin*CN 0.000

Con*RMx 0.000

R-sq = 90.8%

Tabela 8.8 - Equação de Regressão do Percentual de Rejeição em Relação aos

Parâmetros: Quantidade de Pedidos de Conexão, Tempo de Simulação,

Reserva Máxima, Reserva Mínima e Capacidade dos Nós

Como citado no capítulo 1, o trabalho aqui apresentado, foi motivado e baseado

em [GNN97] e [Goula98] e, como citado anteriormente, neste capítulo 8, um dos

objetivos da análise realizada, era fazer uma comparação com os resultados obtidos neste

e naquele trabalho. Os resultados mostrados aqui, podem ser considerados equivalentes

aos resultados encontrados nas referências citadas. Existem variações nos valores obtidos

entre os dois trabalhos, porque as condições de realização dos experimentos foram

diferentes. Como exemplo, a capacidade do nó, em algumas situações, naquele trabalho,

foi assumida como sendo de até 450Mbps. Como a capacidade do nó foi mostrada aqui

como tendo grande influência no percentual de rejeição, não se pode esperar que o valor

dos percentuais encontrados nos dois trabalhos sejam iguais. Eles, no entanto, podem ser

considerados equivalentes, tendo-se em mente, o ambiente de experimentação de cada

trabalho. Abstraindo-se os valores absolutos, encontrados nos dois trabalhos, pode-se

considerar que os resultados foram bastante compatíveis.

8.4 Análise de Viabilidade do Esquema

Após a execução dos testes e análise dos resultados obtidos, pode ser feita uma análise de

viabilidade do esquema. Como dito anteriormente, o esquema foi implementado

utilizando estações de trabalho e um comutador ATM, em uma rede local. Os nós

intermediários, que representavam comutadores ATM em um ambiente real, foram

executados em estações de trabalho. Na execução, foram utilizados 1 e 2 nós

intermediários. No entanto, para utilização do esquema para transmissão de uma

aplicação multimídia distribuída, em uma situação real, seria necessário a utilização de

vários nós intermediários, em uma rede metropolitana ou de longa distância.

Considerando-se a utilização de uma rede metropolitana com uma única rota,

pode-se estimar a existência de no máximo 10 nós intermediários ao longo desta rota.

Para uma rede de longa distância, pode-se estimar que a quantidade máxima de nós

intermediários existentes é igual a 15.


95

Para executar o nó intermediário em um comutador ATM real, seria necessário

colocar o programa do nó intermediário para ser executado neste comutador. Essa

situação depende do acesso a um comutador com arquitetura aberta. Em relação a espaço

no comutador, o programa necessitaria de cerca de 27 Kbytes para armazenamento.

Se não for utilizado um comutador, o esquema tem que ser executado como foi

para os testes realizados aqui, o que insere no tempo de transmissão, o tempo consumido

para transmissão entre a workstation, que possui o programa do nó intermediário, e o

comutador. Os tempos calculados a seguir foram obtidos com a utilização do segundo

tipo de esquema, executando o nó intermediário em uma workstation.

O tempo de transmissão depende da banda passante na rede e da velocidade do

meio de transmissão utilizado. O canal de controle alocado nos experimentos era de

3Mbps. Para transmitir uma PDU com 256 bytes (tamanho da PDU que foi possível

alocar na API), em uma rede local, foram necessários 0,7ms. O tempo medido para

tratamento da PDU em um nó foi na faixa de 1ms. Assumindo que o meio de transmissão

utilizado em uma rede metropolitana e de longa distância, seja fibra ótica, a velocidade de

transmissão utilizada será a velocidade da luz (3x108 m/s).

Em uma rede metropolitana, com 10 comutadores, considerando-se a distância

média entre os comutadores de 20km, o tempo de transmissão de um bit de um

comutador a outro será, na média, de 0,07ms. Portanto, o tempo médio de transmissão

entre dois comutadores, será de 0,07ms + 0,7ms, ou seja, 0,77ms. O tempo total será

igual a 9 x 0,77ms + 10 x 1ms = 16,93ms, para transmissão e tratamento de uma PDU de

renegociação.

Considerando-se uma rede de longa distância, em um caso pessimista, onde a

distância média entre os comutadores é de 1000 km, o tempo de transmissão de um bit de

um comutador a outro será, na média, de 3,35ms. Portanto, o tempo médio de transmissão

será de 3,35ms + 0,7ms, ou seja, 4,05ms. Utilizando os 15 nós intermediários, o tempo

total será igual a 14 x 4,05ms + 15 x 1ms = 71,7ms, para transmissão e tratamento de

uma PDU de renegociação.

De acordo com os experimentos feitos em [Pereira98], a quantidade de

renegociações feitas para a transmissão de um vídeo MPEG, é dependente do tipo de

vídeo, se os quadros possuem mais ou menos variações. De acordo com os vídeo

utilizados nos experimentos, a quantidade de renegociações feitas foi de 1 renegociação a

cada 1s, 3s ou 4s. Assim, de acordo com o tipo de vídeo MPEG sendo transmitido, são

feitas em média 60, 20 ou 15 renegociações por minuto. Isso sugere que podem ser

transmitidas, por minuto, na faixa de 60, 20 ou 15 PDUs para um vídeo. Em uma rede


96

metropolitana, a transmissão das PDUs de renegociação levaria na faixa de 1,016s,

338,6ms e 253,95ms, por minuto, respectivamente. Para uma rede de longa distância, os

tempos seriam de 4,302s, 1,434s e 1,076s, por minuto, respectivamente.

Para que o esquema seja viável para utilização com uma determinada aplicação,

depende do tipo de aplicação multimídia sendo transmitida e dos requisitos de qualidade

desta aplicação. É necessário que os retardos de transmissão e de processamento não

afetem a execução da aplicação.

O esquema não é indicado para utilização por aplicações com requisitos de tempo

real, mas considerando os dados acima, pode-se concluir que o esquema pode ser

utilizado para alguns tipos de aplicação multimídia, como transmissão de vídeo MPEG,

por exemplo.


Este capítulo mostrou como foram planejados e executados os testes para análise do

esquema implementado. A análise foi feita, basicamente, em cima do percentual de

rejeição dos pedidos de renegociação. Os parâmetros analisados, em relação a influência

neste percentual, foram a capacidade dos nós, quantidade de pedidos de conexão, tempo

de simulação, valor de reserva mínima e valor de reserva máxima. Após a análise, pôde-

se concluir que os parâmetros que possuem maior influência sobre o percentual de

rejeição são, em ordem decrescente de influência, capacidade dos nós, valor de reserva

máxima, valor de reserva mínima e quantidade de pedidos de conexão. Foi feita também

uma análise de viabilidade do esquema, de onde pôde-se concluir que o mesmo pode ser

utilizado para transmissão de alguns tipos de aplicação multimídia, como um vídeo

MPEG, por exemplo. No entanto, o esquema não é indicado para utilização com

aplicações multimídia com requisitos de tempo real.


97

Capítulo 9

Conclusões e Trabalhos Futuros

Este capítulo apresenta as conclusões do trabalho desenvolvido e relaciona alguns

trabalhos que podem ser executados futuramente a partir deste trabalho inicial.

9.1 Introdução

Este trabalho apresentou a especificação, projeto, implementação e verificação de

desempenho de um serviço de alocação dinâmica de banda passante para dar suporte a

aplicações multimídia. Este serviço foi desenvolvido utilizando-se uma rede ATM. Foi

especificada uma camada de negociação de QoS e, a partir daí, foi definido o protocolo

de negociação, bem como as PDUs pertencentes a este protocolo. Foram definidas

também as primitivas disponíveis à camada usuária do serviço, no caso, a camada de

aplicações multimídia.

Para implementar o serviço de negociação dinâmica de QoS foram desenvolvidos

três módulos de execução (cliente, intermediário e servidor). O comportamento de uma


98

aplicação multimídia (os pedidos de negociação dinâmica) foi simulado através de uma

lista de primitivas gerada aleatoriamente.

As principais dificuldades encontradas no desenvolvimento deste trabalho foram:

a falta de um comutador ATM com arquitetura aberta, que permitisse a alteração de suas

rotinas de controle de admissão de conexão (CAC); a documentação encontrada sobre a

API do driver ATM da Sun, pois o manual é muito sucinto e não tira muitas dúvidas; e a

familiarização com a programação do driver ATM, que utiliza o padrão STREAMS.

A próxima fase do trabalho, no contexto de pesquisa em desenvolvimento no

laboratório, será a integração de uma aplicação multimídia real., o que substituirá a parte

de simulação, que gera primitivas de negociação, presente no esquema. A aplicação que

está sendo desenvolvida é a transmissão de um vídeo MPEG (Moving Picture Expert

Group).

Uma grande contribuição deste trabalho é a de colaborar na construção de uma

arquitetura de rede de alta velocidade, no caso, uma rede ATM, que garanta qualidade de

serviço para transmissão de informações de aplicações multimídia. Tendo como objetivo

o desenvolvimento desta arquitetura, juntam-se também ao esquema, os esforços de

outros trabalhos em desenvolvimento no laboratório de redes de alta velocidade.

Os resultados apresentados mostraram que o esquema garante um nível de

qualidade de serviço correspondente com a reserva inicial feita por uma conexão. Este

valor fica alocado para a conexão durante toda sua fase ativa e quanto maior a reserva

inicial, maior o nível de garantia. O esquema garante uma prioridade para pedidos de

renegociação sobre os pedidos de estabelecimento de novas conexões.

Os principais parâmetros que têm influência no percentual de rejeição de pedidos

de renegociação são a capacidade dos nós, o valor mínimo de reserva e o valor máximo

de reserva, e com menor significância, a quantidade de pedidos de conexão.

Os resultados obtidos neste trabalho correspondem aos resultados mostrados em

[GNN97] e [Goula98], o que comprova que o esquema simulado naqueles trabalhos,

realmente equivale ao esquema implementado e desenvolvido aqui. Os dois trabalhos

citados serviram de motivação e base para a implementação do serviço de negociação

dinâmica de QoS, em redes ATM, para suporte a aplicações multimídia, apresentado

neste texto.

Como resultado do esforço no desenvolvimento deste serviço, foram gerados dois

artigos referentes ao assunto deste trabalho. Um dos artigos foi aceito na “International

Conference on ATM (ICATM’98)”, a ser realizada em junho, na França. O outro artigo


99

foi aceito no Simpósio Brasileiro de Redes de Computadores (SBRC) para ser

apresentado em poster section, em maio, no Rio de Janeiro.

9.2 Trabalhos Futuros

Como trabalhos futuros podem ser dadas várias sugestões para dar continuidade a este

trabalhos inicial. Algumas destas sugestões são discutidas a seguir.

Utilizar um comutador com arquitetura aberta e tentar migrar o algoritmo de nó

intermediário para este comutador. Seria bastante interessante para aprender a programar

um comutador e testar o esquema com um nó intermediário real.

Inserir outros parâmetros de negociação, além da banda passante. Alguns destes

parâmetros podem ser retardo e variação do retardo [ATMF96]. A inserção de novos

parâmetros possibilita a utilização do esquema para aplicações com características de

tráfego CBR (Constant Bit Rate).

Adequar o esquema para transmissão de tráfego ABR (Available Bit Rate),

utilizando o padrão UNI (User-Network Interface) 4.0. Isto pode ser feito seguindo as

normas descritas em [ATMF96].

Adaptar o esquema para transmissão de aplicações com características de tempo

real, como voz, por exemplo. Uma aplicação deste tipo não possui uma baseline, que

indica previamente quais as necessidades da aplicação em determinados instantes de

tempo. Na fase atual, o esquema é indicado apenas para aplicações que tenham um

arquivo (baseline), que indique a quantidade de banda que aplicação precisa em cada

momento. Este arquivo é transmitido do servidor para o cliente antes de iniciar a

transmissão dos dados da aplicação. A partir deste arquivo é que o cliente saberá em que

momento solicitar as primitivas de serviço e quanto de banda passante será utilizado

como parâmetro.

Adaptar o esquema para trabalhar com SVC (Switched Virtual Channel) e com

comunicação de grupo. Para este tipo de comunicação o esquema deverá ter mais funções

de controle, pois cada caminho independente pode ter capacidades diferentes e cada

usuário também deve ter necessidades diferentes. Usuários com características iguais,

localizados em caminhos diferentes, podem ter garantias diferentes. O esquema pode ser

otimizado para trabalhar com estas situações.


100

Referência Bibliográficas

[ACH98] C. Aurrecoechea, A. Campbell, L. Hauw. A Survey of Quality of ServiceArchitectures. Special Issue on QoS Architecture, May 1998.

[ATMF96] ATM Forum Technical Committee. Traffic Management SpecificationVersion 4.0. April 1996.

[Black95] U. Black. ATM: Foundations for Broadband Networks. Prentice-Hall, 1995.426 p.

[CCG+93] A. Campbell, G. Coulson, F. Garcia, D. Hutchison, H. Leopold. IntegratedQuality of Service for Multimedia Communications. Proc. IEEEINFOCOM’93. San Francisco, USA, April 1993.

[Cisco95] Cisco Systems, Inc. Cisco LightStream 100 User Guide. 1994-1995.

[DG94] S. Damaskos, A. Gavras. A Simplified QoS Model for Multimedia Protocolsover ATM. 5th IFIP Conference on High Performance Networking,Grenoble, France. June 1994.

[Fluck95] F. Fluckiger. Understanding Networked Multimedia: Applications andTechnology. Prentice Hall. Inglaterra, 1995.

[GMÖ97] E. Gelenbe, X. Mang, R. Önvural. Bandwidth Allocation and CallAdmission Control in High-Speed Networks. IEEE CommunicationsMagazine, Vol. 35 N.5, May 1997. Pp. 122-129.

[GNN97] C. Goulart, J. M. Nogueira, G. Neufeld. Dynamic QoS Negotiation forMultimedia Applications at Intermediate Nodes. IEEE SingaporeInternational Conference on Networks, 1997. Pp. 323-338.


101

[Goula98] C. C. Goulart. Um Esquema de Alocação Dinâmica de Recursos paraGarantir QoS para Aplicações Multimídia em Redes. Tese de doutorado aser apresentada ao DCC/UFMG em Abril, 1998.

[HBD96] A. Hafid, G. Bochmann, R. Dssouli. Distributed Multimedia Applicationsand Quality of Service. Publication Départamental n. 982, Départment IRO,Université de Montréal. Jul 1995.

[HBK+95] A. Hafid, G. Bochmann, B. Kerhervé, R. Dissouli, J. Gecsei. On Quality ofService Negotiation for Distributed Multimedia Applications. PublicationDépartamental n. 977, Départment IRO, Université de Montréal. May 1995.

[Holz91] G. J. Holzmann. Design and Validation of Computer Protocols. Prentice-Hall, 1991. 500 p.

[HS96] M. Hofmann, C. Schmidt. A Flexible Protocol Architecture for MultimediaCommunication in ATM-Based Networks. 18th Biennial Symposium onCommunications, Kingston, ON, Canada, June 1996.

[ISO92] International Standards Organization. Quality of Service Framework -Outline. May 1992.

[ITU93] ITU-T Recomendation Q.931. User-Network Interface Layer 3 Specificationfor Basic Call Control. 1993.

[ITU95] ITU-T Recomendation Q.2931. Broadband Integrated Services DigitalNetwork (B-ISDN) - Digital Subscriber Signalling System no 2 (DSS2) -User-Network Interface (UNI) Layer 3 Specification for BasicCall/Connection Control. 1995.

[Jung96] J. Jung. Quality of Service in Telecommunications Part I: Proposition of aQoS Framework and Its Application to B-ISDN. IEEE CommunicationsMagazine, Vol. 34 N.8, August 1996. Pp. 108-111.

[Kidam96] K. R. Kidambi. Bandwidth Alocation Using QoS Mapping and aRenegotiation Scheme for Integrated Services in MAN-ATM Networks.Ph.D. Disseration. University of South Florida, Tamp, Florida, December1996. 195p.

[LPF+97] K. Liu, D. W. Petr, V. S. Frost, H. Zhu, C. Braun, W. L. Edwards. Designand Analysis of a Bandwidth Management Framework for ATM-BasedBroadband ISDN. IEEE Communications Magazine, Vol. 35 N.5, May1997. Pp. 138-145.

[Lu96] G. Lu. Communication and Computing for Distributed Multimedia Systems.


102

Artech House, 1996, 394p.

[Miller94] M. Miller. Analyzing Broadband Networks: Frame Relay, SMDS & ATM.M&T Books, 1994, 522p.

[Minitab95] Minittab Inc. Minitab Reference Manual. Release 9. State College,Pennsylvania, USA. 1995

[Montg91] D. C. Montgomery. Design and Analysis of Experiments. Third Edition.John Wiley E Sons, Inc. 1991. 649 p.

[Nog91] J. M. S. Nogueira. Protocolos de Comunicação: Conceitos, Serviços,Especificação e Teste. V Escola Brasileiro-Argentina de Informática. Rio deJaneiro, Janeiro 1991.

[Partr94] C. Partridge. Gigabit Networking. Addison Wesley. 1994. 396 p.

[Pereira98] F. F. N. Pereira. Transmissão de Vídeo MPEG com Negociação Dinâmicade Banda de Passagem em Redes ATM. Tese de mestrado a ser apresentadaao DCC/UFMG em Agosto, 1998.

[RFC2205] Network Working Group. Resource ReServartion Protocol (RSVP) -Version 1 - Functional Specification. September 1997.

[Saito93] H. Saito. Teletraffic Technologies in ATM Networks. Artech House. Boston-London, 1993. 174p.

[Saito97] H. Saito. Dynamic Resource Allocation in ATM Networks. IEEECommunications Magazine, vol. 35 n.5, May 1997. Pp. 146-153.

[SLC95] L.F.G. Soares, G. Lemos, S. Colcher. Redes de Computadores: Das LANs,MANs e WANs às Redes ATM. Editora Campus, 1995. 576p.

[Solari97] S. J. Solari. Digital Video and Audio Compression. McGraw-Hill, 1997.281p.

[Steve90] W. R. Stevens. UNIX Network Programming. Prentice-Hall, 1990. 772p.

[Sun95] Sun Microsystems, Inc. SunATM-155 Sbus Cards Manual. 1995.

[SunOS93] Sun Microsystems, Inc. SunOS 5.2 STREAMS Programmer’s Guide. 1993

[Tanen96] A. Tanenbaum. Computer Networks. Prentice Hall, 3rd.Ed. 1996. 396p.

[VKBG94] A. Vogel, B. Kerhervé, G. Bochmann, J. Gecsei. Distributed Multimedia


103

and QoS: A Survey. 5th IFIP Conference on High Performance Networking,Grenoble, France, June 1994.

[ZDE+93] L. Zhang, S. Deering, D. Estrin, S. Shenker, D. Zappala. RSVP: A NewResource ReSerVation Protocol. IEEE Network Magazine, vol. 7 n. 5,September, 1993. p.


Documents

Banda passante no pw