João Brandão Reis e Nuno José Morais Felicio
O mundo das comunicações roda em torno do protocolo IP, e cada vez mais existe um conjunto de aplicações emergentes a atrasos e exigindo grande largura de banda, tais como voz e vídeo sobre IP e redes privadas virtuais, que estão a obrigar a novos níveis de QoS em IP.
Resumindo, a QoS é uma forma de consignar recursos em computadores e encaminhadores de trânsito (routers) para que os dados cheguem ao destino de forma consistente e segura, de acordo com as necessidades de cada aplicação.
Existem duas medidas básicas de proporcionar qualidade de serviço em redes:
Esta solução é a forma mais eficaz e simples de garantir QoS em LAN a curto prazo.
Isto é possível devido ao aumento de preço, ou á velocidade dos comutadores LAN sem aumento de preço, ou a evolução do fabrico de chips que permitem integrar um maior número de funções.
A QoS baseada em política permite ao administrador da rede consignar larguras de banda e priortarizar tráfego na rede em função de um conjunto de políticas administrativas e padrões de utilização. Isto é impossivel devido ao aumento constante de tráfego das redes e das transmissões de vídeo que atravessam os nós de trânsito da central de uma empresa.
Os sistemas de prioridades de dados podem classificar-se em ímplicitos ou explicitos.
Na QoS ímplicita o router ou comutador atribui automáticamente os níveis de serviço em função do critério especificado pelo administrador, tal como tipo de aplicação, protocolo ou direcção de origem. Todos os routers suportam a QoS implícita, no entanto os comutadores fornecem este tipo de serviço de uma forma muito limitada pois os comutadores apenas dão prioridades em função do tipo de LAN virtual e a direcção de origem ou destino.
A QoS explicita permite ao utilizador ou á aplicação solicitar um determinado nível de serviço que os comutadores e routers vão ter de respeitar. Ora é neste ponto que o protocolo RSVP (Resource Reservation Protocol) entra, pois este especifica o seu próprio mecanismo de sinalização para comunicar ao router as necessidades de qualidade de uma aplicação.
O grande problema deste protocolo é que ainda não foi adoptado em grande escala devido a problemas de estabilidae, embora alguns routers já o suportem.
Num futuro próximo é provável que a QoS ímplicita venha a crescer, uma vez que permite dispensar uma grande quantidade de processamento no router.
A QoS explicita não deverá ir muito longe uma vez que se trata de uma técnica que traz muitos problemas a nível de gestão. Imaginemos que cada estação final pede para si uma determinado largura de banda, então corre-se o risco de se esgotar toda a banda, quando existem aplicações eventualmente mais criticas sem qualquer recurso.
Nota: é de referir que o protocolo IP versão 4, IP TOS reserva um campo no pacote IP na qual se podem especificar os atributos de fiabilidade, capacidade e atrasos de serviço.
As filas são meras áreas de meória dentro de um router ou comutador em que se armazenam pacotes de diferentes prioridades e que são transmitidos segundo um algoritmo de alinhamento.
Este algoritmo especifica que os pacotes de maior prioridade são enviados em primeiro lugar, embora não consigam ëscaparä problemas de congestionamento, e por conseguinte não chegam a tempo ao destino.
Para resolver este problema existem sistemas de qualidade mais complexos com técnicas de reserva de banda larga para pacotes prioritários.
Esta técnica assegura a disponibilidade da largura de banda, a menos que os dados de uma fila excedam a quantidade de largura de banda reservada. Caso isto aconteça a única solução é colocar ao serviço largura de banda de filas de menor prioridade em filas de maior prioridade.
Como a QoS baseada em política desenvolve-se mediante filas virtuais no comutador, pode-se obter QoS na rede sem alterar as estações finais, mas com uma grande desvantagem associada, é que isto implica um aumento de capacidade de gestão e controlo da cresecente diversidade de tráfego que cruza as redes LAN de hoje.
Uma outra forma de qualidade de serviço consiste em evitar que exista congestionamento. Em TCP/IP é feito o controlo de congestionamento aumentando a velocidadde de transmissão e sofrear o tráfego. No entanto deverá também existir métodos que não só controlam o congestionamento mas também o evitem.
Existe uma série de técnicas que estão a aparecer no mundo TCP/IP que evitam este congestionamento. Uma destas técnicas tem como nome de RED (Random Early Detection), e consiste em perder pacotes aleatóriamente conforme as filas se vão preenchendo, de modo que as estações finais diminuam as suas velocidades de transmissão.
Uma outra técnica consiste na manipulação dos dados, tal como a segmentação de pacotes. É por isso que ATM oferece qualidade de serviço de raíz, pois deve-se ao uso de pacotes pequenos chamados de células, em que o seu máximo tempo de atraso é o tempo em que se demora a transmiti-la.
A QoS é utilizada hoje em dia por routers e comutadores, no entanto num futuro próximo poderão residir em servidores dedicados especificamente para QoS, ou então em software dependente das plataformas de gestão de rede.
Estes servidores poderão utilizar os futuros protocolos LDAP (Light WeighDirectory Acess Protocol) ou o COPS (Common Open Police Service) para comunicar.
Os futuros sistemas vão reunir todas as capacidades de qualidade de serviço apresentados atrás, de modo a assegurar uma QoS de um extremo ao outro.
A actual arquitectura da Internet suporta uma política de best effort , ou seja o que interessa é que os dados cheguem ao destino com um mínimo de erros, mas não interessa quando. Isto implica que para a transmissão de dados de vídeo e de som esta arquitectura não é muito efeciente.
Para podermos transmitir este tipo de dados (que são utilizados em videoconferência ou realidade virtual), a rede tem de suportar uma Qualidade de Serviço tal que os atrasos introduzidos pela rede sejam diminuidos de tal forma que os utilizadores não os notem. Foi neste momento que o IETF ( Internet Engineering Task Force ) apresentou em 1990 um protocolo que permite fazer a reserva de recursos, o RSVP.
O RSVP [1] é um protocolo que permite ás aplicações solicitarem uma qualidade de serviço especifica para a rede, ou seja o RSVP é um protocolo de serviço.
O que acontece basicamente é que o receptor vai alojar um determinado nível de reserva de recursos, e mantém-na activa durante o tempo necessário para a transferência dos dados. Esta reserva de recursos numa árvore, é estabelecida pelo receptor ao longo do caminho até ao emissor.
O RSVP interage com as entidades denominadas packet classifier (classificadores de pacotes) e packet scheduler (programador de pacotes) instaladas no servidor para tomar decisões relativas á qualidade de serviço.
O packet classifier determina a rota do pacote, e o packet scheduler toma as decisões de envio para atingir a QoS desejada. Quando o link do hospodeiro tem uma capacidade própria de gestão de QoS, o packet scheduler negoceiacom ele para obter a qualidade de serviço solicitada pelo RSVP. Caso contrário o scheduler consigna por ele a capacidade de transmissão de pacotes, entre outros recursos, como o tempo de CPU e os buffers.
Para que o packet scheduler conheça qual o nível de QoS desejada existe uma componente que interaje com as aplicações e descreve os requesitos necessários de QoS. Esta componente é chamada de flowspec e descreve tanto a corrente de tráfego enviada pela fonte , como os requisitos de serviço de aplicação.
Junto com o flowspec estão os filterspecs que definem os pacotes de dados que irão receber a QoS definida pelos flowspecs. Este sub-conjunto de pacotes é identificado por um conjunto de filtros que estão alojados no cabeçalho do protocolo, ou de aplicações.
Nota: É de referir que os restantes pacotes serão tratados segundo uma política de best-effort.
Existem dois tipos principais de sinais que percorrem o router, e que comandam todo o processo de reserva de recursos para a transferência de dados com os níveis de QoS desejados. A estes sinais chamamos mensagens e são caracterizados da seguinte maneira:
O modelo de RSVP do router é apresentado na seguinte figura:
Existe além do RESV e do PATH outro tipo de mensagens, tais como o TEARDOWN e ERROR que irão ser levemente referenciadas neste documento, mas sem muita profundidade. No entanto estas mensagens podem ser consultadas para uma melhor apreciação no RFC2205.
Sabendo agora o que estas mensagens significam vamos descrever de forma resumida e básica como interagem os dados e as mensagens com cada um dos intervenientes (emissor, receptor e nós intermédios).
Em RSVP cada emissor envia periodicamente para a rede mensagens PATH que são tratadas pelos comutadores e routers utilzando tabelas de encaminhamento.
Estas mensagens ao chegar aos receptores estes enviam aos emissores as suas solicitações de reservas RSVP com as mensagens RESV, o que permite que cada comutador ao longo do caminho inverso (definido pelo PATH) armazene informação de reserva.
Estas mensagens (PATH e RESV) vão criar e manter periódicamente um estado de gestão de reserva nos routers e hosts, que é chamado de soft state. Este estado é mantido mediante um refrescamento periódico de valores dos temporizadores intermédios (timers).
O soft state é apagado se não chegarem mensagens de refrescamento antes do fim do intervalo de cleanup timeout ou então se houver uma mensagem explicita de teardown.
Nota: A mensagem de bloqueio teardow remove imediatamente os estados de caminho (PATH) e de reserva (RESV), o que evita que hajam bloqueios de recursos. A mensagem teardown é dividida em dois tipos PATHTEAR e RESVTEAR, que anulam nomeadamente a PATH e o RESV.
Um requisito de reserva é feito pelo receptor através dos filterspecs pois são eles quem realmente controlam os recursos, e pode ter várias opções tais como estabelecer uma reserva distinta para cada emissor, ou então uma única reserva que é partilhada por todos os pacotes dos emissores seleccionados.
Tipos de Reserva:
Representação Geométrica:
WF( Q) * - todos; Q - flowspec
Representação Geométrica:
FF(SQ) S - emissor seleccionado
ou
FF(S1Q1,S2Q2,..) para vários emissores
Representação Geométrica:
SE((S1,S2,S3,..)Q) Si - emissor i
Os tipos de reserva WF e SE são mais apropriados para aplicações multicast em que múltiplas fontes de dados não vão transmitir simultâneamente, tais como pacotes de áudio em que um número limitado de pessoas falam simultâneamente.
Por outro lado o FF é apropriado para sinais de vídeo pois cria distintas reservas para cada um dos emissores.
| Valor |
| 000 |
| 001 |
| 010 |
| 011 |
| 100 |
| 101 |
| 110 |
| 111 |
| Valor |
| 1000 |
| 0100 |
| 0010 |
| 0001 |
| 0000 |
O header do IPv6 também tem um campo de 8 bits semelhante chamado "Class". Inicialmente o campo de classe só tinha quatro bit's longos e eram utilizados para codificar a importância relativa do pacote conjuntamente com o fluxo a que lhe estava associado. Mas com o evoluir de serviços heterogénios na rede apareceu a ideia de marcar os diferentes serviços com prioridades diferentes. Apesar desta consciência , a semântica do campo de classe continua livre para pesquisas futuras. Em conclusão, ambas as versões do IPv4 e IPv6 tem um campo de oito bit's que continua a não ser utilizado completamente no presente, mas poderá ser utilizado assim que algo apropriado surja.
A capacidade de atribuir melhores ou piores QoS's está nas mãos dos operadores da rede. Actualmente existem algumas aplicações que beneficiam de algo melhor que o servio Best-Effort (melhor esforço) tais como voz sobre IP e videoconferência. Logicamente os operadores vão aplicar diferentes taxas a diferentes níveis de QoS, pelo menos aos clientes empresariais. Diferenciados QoS's são desejados especialmente para conecções internacionais bastante caras. Os clientes vão optar por QoS's diferentes para os vários tipos de tráfego (nacional, internacional, p/empregados em geral, p/dirigentes...), o que torna hoje em dia difícil a operação dos operadores, pois a QoS é atribuida ao pipe de acesso.
Para além do IP , tráfego simples com atrasos e prioridades de queda são também usados noutras tecnologias de rede; por isso existe alguma utilidade neste conceito.
ATM tem uma célula de prioridade de queda (CLP), que indica a preferência de queda. As células com CLP 1 são mais susceptíveis de serem "descartados" nos switches durante uma congestão.
Também no Frame Relay existe o mesmo conceito, chamado CIR (Committede Information Rate), que é medido em bit's por segundo. O cabeçalho do Frame Relay contém um bit chamado DE (Discard Eligible). Cada utilizador adquire um certo CIR, e quando o seu tráfego excede temporariamento o seu CIR, o bit DE passa a 1. No núcleo da rede, os pacotes com DE a 1 são mais susceptiveis de serem abandonados.
O IEEE 8002.1p é um novo standard que vem introduzir QoS nas LAN's, que são na prática a Ethernet e o Token Ring. O standard especifíca três novos bit's no campo de prioridade nos cabeçalhos dos frames das LAN's. O valor destes três bit's indicam a prioridade de atraso de cada frame em particular.
O crescimento de problemas com os IIS's e a necessidade de encontrar soluções para QoS do IP, para além de soluções extremo-a-extremo, levou a comunidade de pesquisa da Internet a dar uma olhadela em soluções simples. Durante 1997 apareceram várias propostas com caracteristícas semelhantes. No inicio do ano seguinte, em 1998 apareceu um grupo de trabalho em "Serviços Diferenciados" na IETF.
A finalidade deste grupo de trabalho é definir métodos simples e vulgares de atribuir diferentes classes de serviço para o tráfego da Internet. A ideia não é criar uma nova arquitectura, mas sim criar uma série de pequenos blocos, bem defenidos, a partir dos quais se podem defenir uma variedade de serviços.
O mecanismo consiste em criar um pequeno padrão de bit's em cada pacote, quer seja no octeto TOS do IPv4 ou no octeto de Classe de Trafego do IPv6, que é usado para marcar o pacote por forma a que este possa recever um tratamento particular adequado em cada nó da rede.
A intenção do grupo é criar e standardizar um plano comum que seja utilizado em ambos octetos (IPv4 e IPv6), agora chamado byte "DS" (Differentiated Services). Esta definção irá sobrepôr-se á que é apresentada no RFC791 e RFC1349. A primeira proposta é constituir um octeto, onde serão usados os seis bits mais significativos , enquanto os outros dois continuam livres para usar mais tarde.
Os sockets raw [3] sao usados para gerar/receber pacotes de um tipo, cujo o kernel não precisa propriamente de suportar.
Um exemplo que nos é familiar ,é o PING. O ping envia para fora pacotes de eco ICMP (Internet Control Message Protocol - outro protocolo IP distinto do TCP e UDP) sobre um socket raw e espera pela resposta.
A finalidade deste teste é ver até que ponto a rede reserva mais recuros e encaminha mais depressa pacotes com um peso prioritário. O caso prático será observar o Router a modificar a sequência dos pacotes em função da sua prioridade.Para o efeito desenvolvêmos um software que cria pacotes com prioridades diferentes.
No nosso programa [4] [5], cria-se um socket_raw por processos muito semelhantes aos já conhecidos sock_stream , diferindo na linha de código : s=socket (AF_INET,SOCK_RAW,5); . O valor 5 refere-se ao protocolo usado, UDP, visto que vamos estabelecer uma comunicação conecttion less.
A novidade vem também no uso duma estrutura IP usada para constituir o cabeçalho da trama IP.Na estrutura define-se a versão do IP,o comprimento do cabeçalho ,o Tipo de Serviço,o comprimento dos dados, a Identificação, o Offset , o "Tempo para viver",o Protocolo , o teste de erros do cabeçalho e ainda os endereços da fonte e do destino. Destes parâmetros todos o que tem especial interesse para o nosso caso é o TOS (Tipo de Serviço). É aqui que vamos modificar por forma a obter pacotes com ToS's diferentes.
Agora só nos resta enviar pacotes com a função "sendto".Optá-mos por
enviar em primeiro lugar 100 pacotes sem qualquer tipo de prioridade e por
final mais 1 pacotes com uma prioridade apreciável : Instantânio com o
Minimo de Atraso que corresponde em binário a "011 1000 0".
Código implementado:
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <strings.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
u_short portbase = 0;
long time(); /* ? */
#define LOCAL_PORTO 6000
#define qlen 6
#define protocol "raw"
#ifdef REALLY_RAW
#define FIX(x) htons(x)
#else
#define FIX(x) (x)
#endif
main(int argc, char** argv)
{
int msock, ssock;
int alen;
char send_buffer[]= "Teste de ligaçao via qualquer coisa do genero\n";
char recv_buffer[200];
struct servent *pse;
struct protoent *ppe;
struct sockaddr_in dst;
struct hostent *hp;
struct ip *ip = (struct ip *)send_buffer;
struct icmp *icmp = (struct icmp *)(ip +1);
int s, type, dstL, i;
int q, bind1, lis;
int sockopt;
int on = 1, address;
int offset;
int send,recv;
int n;
bzero((char *)&dst, sizeof(dst));
dst.sin_family = AF_INET;
dst.sin_addr.s_addr=htonl(INADDR_ANY);
dst.sin_port = 6000;
ppe = getprotobyname("raw");
setbuf(stdout,NULL);
s = socket(AF_INET, SOCK_RAW, 5);
printf("\n1º) %d value of s in servsock",s);
if (s < 0)
printf("\n2º) Cann't creat socket");
setbuf(stdout,NULL);
sockopt = setsockopt(s, 0, IP_HDRINCL, &on, sizeof(on));
/* sockopt = setsockopt(s, 0, IPTOS_PREC_FLASH|IPTOS_LOWDELAY, &on, sizeof(on));*/
printf("\n3º) %d value of sockopt", sockopt);
if (sockopt < 0)
exit(0);
if(( hp = gethostbyname(argv[1])) == NULL)
{
if(ip->ip_dst.s_addr = inet_addr(argv[1]) == -1)
printf("\n4º) ERRO: HOST Desconhecido");
}
else
bcopy(hp->h_addr_list[0], &ip->ip_dst.s_addr,hp->h_length);
printf("\n5º) Sending to %s\n", inet_ntoa(ip->ip_dst));
ip->ip_v = 4;
fflush(stdin);
ip->ip_hl = sizeof *ip >> 2;
ip->ip_tos = 2 ; /* Precedencia = Flash (000) + Type oS = Best (1111) =[000 1111 0] = 126 */
ip->ip_len = sizeof send_buffer;
ip->ip_id = htons(4321);
ip->ip_off = 0;
ip->ip_ttl = 255;
ip->ip_p = 5;
ip->ip_sum = 0;
ip->ip_src.s_addr = 0;
dst.sin_addr = ip->ip_dst;
dst.sin_family = AF_INET;
icmp->icmp_type = ICMP_ECHO;
icmp->icmp_code = 0;
for (i=0;i<500;i++)
{
send = sendto(s, send_buffer, sizeof send_buffer, 0, (struct
sockaddr*) &dst, sizeof dst); if(send < 0)
printf("7º) ERROR sending ");
if ( send != sizeof send_buffer)
printf("8º) ERROR packet size");
printf("\nTrama %d : buf is %s value of send is %d ", i,send_buffer,
send);
}
ip->ip_tos = 226;
for (i=0;i<500;i++)
{
send = sendto(s, send_buffer, sizeof send_buffer, 0, (struct
sockaddr*) &dst, sizeof dst); if(send < 0)
printf("7º) ERROR sending ");
if ( send != sizeof send_buffer)
printf("8º) ERROR packet size");
printf("\nTrama Prioritaria %d : buf is %s value of send is %d ", i,send_buffer,
send);
}
dstL = sizeof dst;
// recv = recvfrom(s, recv_buffer, sizeof(recv_buffer), 0,
// (struct sockaddr *) &dst,&dstL);
// printf("10º) recv buffer is%s value of n is %d\n", recv_buffer,n);
close(s);
exit(0);
}
Configurámos o programa "Ethereal" para monitorar 1000 pacotes na rede. Foi posto a monitorar e ao mesmo tempo colocá-mos o nosso programa a correr.
Após analizar o que capturámos na rede, verificou-se que os pacotes não mudaram de posição, vindo por ultimo o de maior prioridade.Tal facto não é de admirar, pois enquanto os PC's possuem interfaces de rede a 10Mbit/s, cada porta do Router tem a capacidade de encaminhar 100Mbit/s. Para alem deste infortunio verificou-se um má formação do octeto de ToS, o qual foi facilmente resolvido.Agora so faltava tentar outro processo para ver em "ação" o ToS.
Para podermos observar algo seria necessário congestionar o Router. Foi então que se decidiu aumentar os pacotes normais para 500 e os pacotes prioritários para 500 também. Colocou-se o "Ethereal" a "correr" e voltou-se a analizar os resultados: continua a não haver troca de pacotes.
Face a estes resultados colocou-se duas máqinas a fazer Ping c/ Broadcast (enviar ping para todas as máquinas da rede interna) .Mas mesmo assim continuou a não satisfazer as nossas espectativas.
Perante estes factos vamos passar á "massa bruta" : fazer vários FTP's simultâneos com ficheiros enormes (da ordem dos Mbytes), que sejam obrigados a passar pelo nosso Router. Vai ser neste momento que esperamos ver resultados práticos da nossa primeira experiência.
Muitas aplicações que correm na Internet necessitam que uma determinada qualidade de serviço esteja disponivel de modo a poderem chegar ao utilizador final sem ocorreência de erros perceptiveis.
As soluções apresentadas pelo IETF e pelo ATM FORUM ainda não estão totalmente implementadas na Internet, de modo que a existência de QoS ainda está para chegar.
Hoje em dia a maior parte das aplicações de redes existentes são baseadas em TCP/IP pelo que não fornecem QoS, não conseguem beneficiar das capacidades do ATM e muito dificilmente são convertidas para aplicações nativas ATM.
Como é sabido já de si o ATM tem mecanismos de reserva de recursos pelo que as aplicações de rede escritas para ATM oferecem QoS de raíz.
A AREQUIPA apresenta uma forma simples de fornecer os serviços de QoS para os utilizadores que estão ligados em ATM.
A AREQUIPA fornece mecanismos que permitem que as aplicações estabeleçam uma ligação directa ponto-a-ponto em ATM permitindo a existência de ligações com QoS.
Após estabelecer uma ligação ATM, indicando o SVC que é utilizado, as aplicações podem utilizar o protocolo TCP/IP para a troca de dados.
Estas ligações são usadas exclusivamente pelas aplicações que as requesitam.
AREQUIPA [6] [7] [8] é um mecanismo que permite ás aplicações estabelecer um ligação ATM ponto-a-ponto sob seu controlo, e utilizar estas ligações a um nível mais baixo de modo a transportar o tráfego IP dos sockets específicos.
Ao contrário das ligações normais de IP sobre ATM ou LANE as ligações AREQUIPA são utilizadas exclusivamente pelas aplicações que as requerem. Por isso estas aplicações podem determinar exactamente qual a QoS disponivel para elas.
No modo geral podemos dizer que a AREQUIPA utiliza a tecnologia da rede que é utilizada para transportar outra tecnologia de rede, sem termos de modificar a arquitectura da rede, ou implementar mecanismos ou prótocolos sofisticados.
A AREQUIPA só é aplicável se as seguintes condições forem stisfeitas:
As duas condições seguintes não necessitam de ser satisfeitas, embora sem elas o uso da AREQUIPA pode ser questionável:
Para sistemas que não utilizam a AREQUIPA as estruturas do kernel estão normalmente associadas aos sockets TCP.
Os dados que chegam ao socket são desmultiplexados pelo protocolo da stack e colocados em filas de espera. Para os dados que são enviados, estes são multiplexados e enviados através da interface da rede.
Quando um sistema utiliza a AREQUIPA, aos pacotes que chegam é-lhes aplicado ou não um processamento ATM ( como em IP sobre ATM ), e são depois desmultiplexados pelo protocolo da stack. A diferença reside que os pacotes têm um identificador que indica que estes são originados na AREQUIPA e em qual VC.
Se por acaso o socket não está a utilizar a AREQUIPA para o envio dos dados , e está á espera de tráfego AREQUIPA, o VC onde foi recebido o pacote vai-se ligar ao socket.
No entanto á que ter o cuidado e assegurar que o VC continua a existir no momento em que os dados são entregues ao socket. É portanto necessário verificar a validade do VC AREQUIPA antes de o ligar com o socket.
Isto é conseguido da seguinte maneira:
Portanto um VC só é válido se o pacote que chega ao socket tem referência a esse VC, e está na lista dos VCs.
Quando é pretendido o envio de dados de um socket AREQUIPA os pacotes enviados têm de ser associados ao VC AREQUIPA correspondente. Os apcotes são enviados por uma pseudo interface que tem um apontador para o socket de origem, que por sua vez este tem um apontador para o VC AREUIPA de onde os dados têm de ser enviados.
Para se conseguir o envio ou recepção de pacotes AREQUIPA, é necessário que os pontos seguintes sejam possiveis:
Para se utilizar a AREQUIPA na Web é necessário conhecer o endereço ATM da máquina destino, estabelecer os parametros de QoS para a ligação e saber o porto da máquina destino de modo a estabelecer uma ligação TCP/IP.
O servidor também estabelece uma ligação TCP/IP na qual o documento é transferido. Para isso o cliente necessita de indicar qual o porto em que está á espera dos dados.
Para cada documento podemos especificar o tipo de ligação utilizada ( se tem QoS ou não).
A especificação QoS é feita através do Web Server uma vez que este guarda a informação de QoS no cabeçalho de cada documento, ou num ficheiro á parte.
Muitas vezes os clientes pretendem saber os atributos de QoS do documento que pretendem fazer o dowload (pois querem saber se têm recursos locais para o obter, ou então querem seleccionar só alguns documentos com QoS), de modo que pedem que lhes seja enviada apenas o cabeçalho dos documentos. Isto é conseguido fazendo um request sem enviar o número do porto de rececção dos dados. Se o utilizador da máquina destino decidir fazer o dowload então envia outro request, mas desta vez com o número do porto de rececção dos dados.
O comprotamento do Web Server é mostostrado com o seguinte pseudo código:
if (request_tem_ATM_address && document_has_QoS_metainfo)
if (request_has_port_number) send_document_using_arequipa();
else send_headers_only();
else /* non-QoS document or non-Arequipa client */
send_document_standard_way();
Quando um cliente envai informação requerida por AREQUIPA, ele utiliza os seguintes campos:
Pragma: ATM_address= pub_address.prv_address
pub_address é o endereço público do cliente. Se o cliente não tem endereço este campo permanece vazio.
prv_address é o endereço privado ATM NSAP do cliente. Se ele não tem este endereço então este campo também permanece vazio.
A presença do ATM-address indica que o cliente suporta AREQUIPA, e que quer que o servidor saiba disso.
Pragma: socket= protocol.port_number
protocol é tipicamente TCP ou UDP e port_number é o número do porto para onde o documento requerido é enviado.
A presença deste pragma indica que o cliente quer fazer o dowload de um determinado documento.
A informação de QoS é enviada pelo servidor adicionando os seguintes campos ao header do documento.
ATM-service: service
ATM-QoS-PCR : peak_cell_rate
Este campo pode ser omitido ao utilizar UBR.
A elaboração do nosso projecto até a este ponto mostrou ser muito trabalhosa, uma vez que tivemos de aprender um sistema completamente novo. Alem disso durante este semestre tivemos um trabalho mais informativo sobre o tema do projecto, ou seja foi feita a pesquisa de documentos relativos a Qualidade de Servico em IP sobre ATM.
A pesquisa deste tema mostrou-se ser mais permonorizada do que previsto inicialmente, pois foram também pesquisados outros temas que nos ajudaram a compreender o tema central referido anteriormente. Estes temas foram os temas apresentados neste relatorio.
Depois de uma fase de pesquisa passou-se para uma fase mais de implementação, dividindo-se o nosso grupo em duas áreas: implementaçao de um código para teste de QoS da rede, e instalação e teste de um programa de envio de documentos com QoS entre duas máquinas. Estes trabalhos em conjunto mostraram-se ser bastante ricos e interessantes do ponto de vista de um funcionamento de uma rede com QoS.
A ``luta continua''.... Até para o próximo semestre...
This document was generated using the LaTeX2HTML translator Version 98.2 beta6 (August 14th, 1998)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 relatorio_final.tex
The translation was initiated by Joao Reis on 1999-12-17