banda passante no pw
TRANSCRIPT
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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-
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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]:
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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].
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
3.5 Resumo do Capítulo
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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].
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
4.5 Resumo do Capítulo
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
5.2 Resumo do Capítulo
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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).
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Camada de Negociação de QoS
Rede ATM
MIB QoSpara ATM
Agente QoS
Camada de Negociação de QoS
Rede ATM
MIB QoSpara ATM
Agente QoS
Camada de Negociação de QoS
Rede ATM
Rede ATM
GerenteQoS
Camada de Negociação de QoS
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
− Parâmetros: identificador da conexão e parâmetros de negociação de QoS
• 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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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]:
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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);
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
− Parâmetros: identificador da conexão e parâmetros de negociação de QoS
• 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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
− Parâmetros: identificador da conexão e parâmetros de negociação de QoS
• 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ó.
− Parâmetros: identificador da conexão
• 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.
− Parâmetros: identificador da conexão e parâmetros de negociação de QoS
• 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.
− Parâmetros: identificador da 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.
− Parâmetros: identificador da conexão
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Estabelecer_Conexao [Não há recursos locais]
Envia primitiva Cancelar_Recursos
Estabelecer_Conexao [Há recursos locais]
Reserva recursos locais Envia PDU Conexao_Estabelecida
Terminar_Conexao
Exclui conexão
ConexãoEstabelecida
Mais_Recursos [Há recursos locais]
Reserva mais recursos
Mais_Recursos [Não há recursos locais]
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
67
Início EstabelecendoConexão
ConexãoEstabelecida
Estabelecer_Conexao [Não há recursos locais]
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ó
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ó
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.
6.5 Resumo do Capítulo
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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).
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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);
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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:
− Alocar canal de controle para transmitir as primitivas de negociação;
− Tratar PDUs recebidas da rede (Estabelecer Conexão, Mais Recursos, Menos
Recursos, Terminar Conexão, Cancelar Recursos, Conexão Estabelecida e
Mais Recursos Resp);
− Transmitir e receber informação utilizando a rede ATM.
O módulo Servidor é a entidade do serviço localizada no nó servidor da rede,
tendo como principais funções:
− Alocar canal de controle para transmitir as primitivas de negociação;
− 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);
− Transmitir e receber informação utilizando a rede ATM.
7.1.2 Estruturas de Dados
As estruturas de dados necessárias para a execução do projeto são:
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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 */
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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].
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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);
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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;
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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;
Se o nó possuir recursos
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;
Senão Se PDU = Cancelar_Recursos
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;
Se o nó possuir recursos
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
77
Então Reserva recursos de acordo com parâmetros;
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;
Senão Se Estado = Conexao_Estabelecida
Então Se PDU = Mais_Recursos
Então Verifica se o nó possui recursos para atender o pedido;
Se o nó possuir 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
Então Subtrai os recursos p/ conexão, observando valor mínimo;
Envia PDU Menos_Recursos p/ próximo nó da rede;
Senão Se PDU = Cancelar_Recursos
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;
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
78
Se o nó possuir recursos
Então Reserva recursos de acordo com parâmetros;
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;
Senão Se Estado = Conexao_Estabelecida
Então Se Primitiva = Mais_Recursos
Então Verifica se o nó possui recursos para atender o pedido;
Se o nó possuir 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
Então Subtrai os recursos p/ conexão, observando valor mínimo;
Senão Se Primitiva = Terminar_Conexao
Então Retira entrada da tabela para a conexão.
Figura 7.6 - Algoritmo do Módulo Servidor
7.3 Resumo do Capítulo
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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)
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
ANALYSIS OF VARIANCE ON Rej_Ren%
SOURCE p LEVEL MEAN
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Rejeição de Pedidos de Renegociação
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
ANALYSIS OF VARIANCE ON Rej_Ren%
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
ANALYSIS OF VARIANCE ON Rej_Ren%
SOURCE p
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Rejeição de Pedidos de Renegociação
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
ANALYSIS OF VARIANCE ON Rej_Ren%
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
Rejeição de Pedidos de Renegociação
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
(%
)
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
ANALYSIS OF VARIANCE ON Rej_Ren%
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
Rejeição de Pedidos de Renegociação
A figura 8.6 mostra o gráfico do percentual de rejeição de pedidos 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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
91
A figura 8.8 mostra o gráfico do percentual de rejeição de pedidos de
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
8.5 Resumo do Capítulo
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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.
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira
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
Dissertação de Mestrado em Ciência da Computação - DCC/UFMG - 26/03/98
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.
Autor: Ana Luiza Bessa de Paula Barros Diniz Orientador: José Marcos Silva Nogueira