Estrutura duma Rede com QoS

´E importante constatar que, na sua totalidade, a infra-estrutura que permite garan-tir servic¸os com qualidade ´e bastante complexa. Entre outras funcionalidades tem que garantir as seguintes:

armazenamento e propagac¸˜ao da informac¸˜ao relativa `as reservas efectuadas pe-las aplicac¸ ˜oes e ao estado das ligac¸ ˜oes f´ısicas;

estabelecimento de novas reservas;

determinac¸˜ao dos caminhos a seguir pelos pacotes, de acordo com os v´arios parˆametros de QoS;

gest˜ao das filas de espera `a entrada das ligac¸ ˜oes f´ısicas;

controlo de admiss˜ao de ligac¸ ˜oes/reservas (“Connection Admission Control — CAC).

Política de Controlo Classificador CAC dados dados Encaminha mento ^{Sinalização} Separador

Figura 2.10: Divis˜ao em m ´odulos dum encaminhador com QoS

Por este motivo conv´em que a infra-estrutura n˜ao seja monol´ıtica, mas sim modular, de forma a tamb´em aqui se reduzir a complexidade da tarefa `a custa da divis˜ao de um todo em partes bem delimitadas, com interacc¸ ˜oes claras.

Na figura 2.10 apresentamos uma divis˜ao poss´ıvel em m ´odulos para esta infra-estrutura, semelhante `a que ´e apresentada em (Braden et al., 1997). A utilidade de cada um destes m ´odulos ser´a estudada mais adiante. Interessa aqui compreender, que os princ´ıpios subjacentes a esta divis˜ao fazem sentido qualquer que seja o tipo de rede que consideremos. Neste caso, estamos a falar de redes IP, mas facilmente podemos aplicar o mesmo modelo `as redes “Asynchronous Transfer Mode” — ATM, por exemplo.

O problema de definir estes m ´odulos ´e mais complexo nas redes IP, que foram pen-sadas na sua g´enese, apenas para servic¸os melhor esforc¸o. Isto porque, em primeiro lugar, n˜ao ´e aceit´avel retirar ou alterar partes que j´a existam; em segundo lugar quais-quer novos elementos a introduzir ter˜ao que coexistir com toda a infra-estrutura actual durante um per´ıodo de tempo que poder´a vir a ser longo.

A soluc¸˜ao radical e diametralmente oposta de pura e simplesmente substituir o IP por outra tecnologia orientada de raiz para oferecer garantias de QoS n˜ao parece ser razo´avel, dada a forte implantac¸˜ao do IP8.

8Tˆem sido dedicados esforc¸os muito grandes ao desenvolvimento do ATM, que se prop ˆos a partir de certa altura ser uma tecnologia de suporte universal. Por´em, no momento em que ´e escrito este documento, o sucesso do ATM ´e algo incerto, sobretudo no que diz respeito `as redes locais (LANs).

Nas secc¸ ˜oes seguintes, vamos abordar o funcionamento de cada um dos m ´odulos da divis˜ao proposta.

2.3.5 Sinaliza¸c˜ao

O papel do m ´odulo de sinalizac¸˜ao pode variar um pouco com o tipo de soluc¸ ˜ao adoptada.

Tentando encontrar uma definic¸˜ao comum, podemos dizer que este m ´odulo ´e res-pons´avel por codificar e transmitir toda a informac¸˜ao relativa ao estabelecimento de reservas.

Se a rede for orientada `as ligac¸ ˜oes, como o ATM, por exemplo, o papel dum m ´odulo de sinalizac¸˜ao ser´a o de estabelecer novas ligac¸ ˜oes sempre que tal for solicitado. Esta-belecer uma nova ligac¸˜ao implicar´a escolher um caminho desde o ponto de origem at´e ao ponto de destino e encaminhar um pedido, para o efeito, entre esses dois pontos9. ´E importante referir que a selecc¸˜ao do caminho ´e uma tarefa que cabe ao m´odulo de encaminhamento e n˜ao ao m ´odulo de sinalizac¸˜ao. Ao longo do caminho selecciona-do tem que ser armazenada a informac¸ ˜ao relativa `a nova ligac¸˜ao j´a que, no ATM, as c´elulas seguem sempre o mesmo percurso, depois daquela ser estabelecida.

Nas redes IP, tradicionalmente, por n˜ao haver ligac¸ ˜oes, n˜ao est´a previsto qualquer m ´odulo de sinalizac¸˜ao. No entanto, para ser poss´ıvel garantir QoS, tem que exis-tir algum mecanismo de sinalizac¸˜ao, raz˜ao pela qual tˆem sido desenvolvidos alguns esforc¸os no sentido de criar protocolos capazes de desempenhar esse papel.

Um desses protocolos ´e o Protocolo de Reserva de Recursos (RSVP — Resource ReSerVation Protocol). Este protocolo ´e orientado de raiz para uma rede IP multicast e opera directamente sobre o protocolo IP. No RSVP h´a uma diferenc¸a expl´ıcita entre emissores e receptores, cabendo a estes ´ultimos efectuar as reservas. Esta situac¸˜ao, que se apresenta contra-intuitiva numa primeira an´alise, apresenta duas vantagens consider´aveis:

poupanc¸a de recursos, uma vez que cada receptor s ´o reserva as quantidades de que precisa, podendo haver v´arios receptores na mesma sess˜ao (i.e., com o mes-mo enderec¸o multicast, protocolo de transporte e porto de destino) a receber os dados com qualidades distintas;

escalabilidade, porque as reservas n˜ao s˜ao propagadas para montante (i.e., na direcc¸˜ao do emissor) mais do que aquilo que ´e estritamente necess´ario. Os enca-minhadores mais pr ´oximos do emissor poder˜ao nem sequer tomar conhecimento de que h´a reservas a ser efectuadas ou canceladas.

Aos emissores cabe fazer o aviso do tr´afego que v˜ao gerar. A propagac¸˜ao destes avisos ´e feita na direcc¸˜ao dos receptores e os percursos seleccionados tˆem que ter em considerac¸˜ao a QoS anunciada. Tal como seria de esperar num protocolo de sinalizac¸˜ao, tamb´em no RSVP, ´e este um dos pontos de interacc¸˜ao entre a sinalizac¸˜ao e o encaminhamento. Os avisos de tr´afego s˜ao feitos em mensagens designadas por PATH. A resposta dos receptores a estas mensagens ´e feita com mensagens RESV, que s˜ao enviadas na direcc¸˜ao dos emissores. `A medida que as mensagens RESV com as reservas efectuadas pelos receptores sobem para montante na ´arvore de distribuic¸ ˜ao multicast, podem ser fundidas em novas mensagens com requisitos iguais ou superio-res aos das mensagens que lhes deram origem. Esta constitui uma das ideias base na l ´ogica do RSVP.

Note-se que, neste protocolo, a decis˜ao de encaminhamento com QoS e a reserva propriamente dita ocorrem em momentos distintos, pelo que h´a a possibilidade de ser seleccionado um percurso sub ´optimo para as reservas. Este problema ´e um dos prec¸os a pagar pelo tipo de soluc¸˜ao adoptada, mas pode ser minorado, obrigando os emissores a renovarem periodicamente o envio de mensagens PATH, que resultem num eventual reajuste dos percursos10.

A especificac¸˜ao do RSVP pode ser encontrada em (Braden et al., 1997).

J´a vimos que uma das interacc¸ ˜oes do m ´odulo de sinalizac¸˜ao se faz com o m ´odulo de encaminhamento. Inclusivamente, o m ´odulo de sinalizac¸˜ao n˜ao precisa sequer de

10Embora isso possa n˜ao acontecer se o protocolo de encaminhamento fizer route pinning, que ´e um conceito que ser´a abordado mais adiante.

ter conhecimento dos parˆametros de QoS, podendo trat´a-los como objectos opacos compreendidos apenas pelas aplicac¸ ˜oes (ou por entidades que oferecem os servic¸os `as aplicac¸ ˜oes, pertencentes ao sistema operativo, por exemplo) e pelo m ´odulo de en-caminhamento. Neste caso, o m ´odulo de sinalizac¸˜ao limita-se a transferir esses ob-jectos duns locais para outros, mas sempre sem inspeccionar directamente o seu con-te ´udo. ´E assim que se passa no RSVP. Eventualmencon-te, se o RSVP precisar de manipular informac¸˜ao de QoS (flowspecs) para fundir duas reservas diferentes, por exemplo, ter´a de recorrer a uma funcionalidade oferecida por alguma entidade do sistema.

Outra das interacc¸ ˜oes do m ´odulo de sinalizac¸˜ao ser´a feita com o m ´odulo de CAC, que descreveremos adiante. No ATM, por exemplo, quando uma ligac¸˜ao est´a em fase de estabelecimento, em todos os n ´os que ela atravessa, o CAC tem que ser consultado, para determinar se ´e ou n˜ao poss´ıvel estabelecer a ligac¸˜ao. Se n˜ao for, a soluc¸˜ao a adoptar pode passar pela pura e simples desistˆencia ou pela tentativa de um caminho alternativo, dependendo da complexidade do mecanismo.

As interacc¸ ˜oes deste m ´odulo com os restantes est˜ao representados na figura 2.10, por interm´edio de setas.