Serviços unidireccionais vs bidireccionais, simétricos vs assimétricos

Existem serviços que são de carácter claramente bidireccionais e simétricos, tais como a comunicação de voz, havendo outros que embora bidireccionais têm um caracter essencialmente assimétrico, e outros cuja essência é unidireccional. A arquitectura aqui proposta está preparada para lidar com todos estes tipos de serviço.

Nova Arquitectura de QoS Orientada ao Fornecimento de Serviço

147

O modo como os serviços são sinalizados nesta arquitectura é através da marcação dos pacotes IP com um valor de DSCP que identifica univocamente um serviço. Existem várias estratégias possíveis para permitir a definição de serviços bidireccionais, mas aquela que aqui é apresentada é inteiramente baseada num conceito semelhante ao da identificação de serviços unidireccionais. Assim, um utilizador que inicie um fluxo marcando os seus pacotes com o DSCP=5, por exemplo, poderá estar a identificar um serviço com características bem definidas em termos de prioridade, largura de banda, direccionalidade e simetria. Como regra geral (com eventuais excepções), podemos assumir que num serviço unidireccional, cada um dos intervenientes na ligação será responsável pelo pagamento do tráfego que gerar ou tempo da ligação. No caso de um serviço bidireccional, uma vez que a autorização de serviço será desencadeada por apenas um dos intervenientes, o chamador, é natural que este seja o responsável pelos encargos da ligação. Todos estes aspectos serão função das políticas do operador.

5.5.4.1 Serviço unidireccional (emissão apenas)

Por exemplo, suponhamos que um DSCP=x representa um serviço unidireccional, de sentido ascendente (com possibilidade de enviar tráfego apenas do terminal para a rede). Neste caso, o procedimento é aquele que foi indicado nas secções anteriores, ou seja, o utilizador sinaliza o serviço enviando pacotes com o DSCP=x e o QoS Broker configurará o router de acesso de modo a permitir que todos os pacotes originados no terminal do utilizador, marcados com o DSCP=x e dentro da largura de banda prevista para o serviço em causa, possam fluir para o core da rede. Todo o restante tráfego estará dependente da existência de outros serviços activos, quer iniciados pelo utilizador, quer iniciados por outro utilizador, mas com destino a este terminal.

5.5.4.2 Serviço unidireccional (recepção apenas)

No caso de um serviço unidireccional de sentido descendente, o terminal do utilizador, ao enviar um pacote marcado com o DSCP=y, irá despoletar no RA um pedido ao QoS Broker que, de acordo com o perfil do utilizador, configurará no RA uma regra permitindo que o terminal possa receber tráfego vindo do core da rede, marcado com um DSCP que poderá não ser o “y” (o DSCP com que o tráfego vem marcado será aquele que constará no perfil do utilizador, associado ao serviço sinalizado com o DSCP=y).

Serviços Multimédia Sobre Redes Heterogéneas

148

5.5.4.3 Serviço bidireccional simétrico

No caso de um serviço bidireccional, há a necessidade de garantir que os recursos são reservados em ambas as direcções no RA do terminal que inicia o processo, mas também no RA do terminal destino. Para o caso de um serviço simétrico, o procedimento é relativamente simples. O terminal ao enviar pacotes com o DSCP=w despoleta no RA e no QoS Broker locais um processo de configuração de uma política de envio e outra de recepção de pacotes, que podem ser encaminhados com uma prioridade e até uma taxa de transferência pré-definidas no perfil do serviço, desde que marcados com o DSCP=w. No lado da recepção, o mesmo pacote irá despoletar uma acção semelhante por parte do conjunto RA e QoS Broker, mas neste caso não é importante saber se o terminal destino subscreveu ou não este serviço (se existe no seu perfil), pois o processo está a ser suportado pelo perfil e contrato do chamador.

5.5.4.4 Serviço bidireccional assimétrico

Um serviço assimétrico poderá também ser sinalizado apenas por um único DSCP, mas, por uma questão de simplicidade de implementação, é conveniente que a comunicação entre os dois extremos se faça utilizando dois DSCPs distintos, um para cada sentido. Assim, o terminal origem, ao marcar o tráfego como DSCP=z, irá despoletar no RA e QoS Broker um processo de configuração de duas políticas distintas, uma para envio e outra para recepção, de acordo com a especificação do serviço identificado pelo DSCP=z. No lado da recepção, o QoS Broker, ao verificar que a proveniência do pacote é o core da rede, sabe também que deve configurar duas políticas para o utilizador destino, de acordo com o perfil do serviço. Também neste caso, o perfil do utilizador destino não é importante, pois o chamador será o responsável pela ligação. Após isto, no sentido do chamador para o chamado os pacotes deverão ser marcados com o DSCP=z, enquanto que no sentido inverso (chamado – chamador) deverá ser utilizado um outro valor de DSCP (z’), também associado ao serviço sinalizado com o DSCP=z.

Uma questão importante a ter em consideração no caso de serviços bidireccionais é o pagamento do serviço. Atendendo que o iniciador do serviço poderá na maioria dos casos ser o responsável pelo pagamento, que o serviço é sinalizado por um DSCP e que o serviço por omissão só será terminado após um timeout na transmissão de pacotes relativos a esse serviço, terá que haver um processo de impedir que o terminal destino aproveite o facto de

Nova Arquitectura de QoS Orientada ao Fornecimento de Serviço

149

alguém lhe ter ligado para utilizar essa ligação para se ligar a outros destinos, mesmo que o chamador tenha terminado a ligação. Uma forma de garantir isto, é as políticas instaladas nos routers de acesso no destino incluírem o endereço origem, endereço de destino e código DSCP. Assim, se o terminal destino decidir enviar pacotes para outro endereço que não o do chamado, mesmo que utilizando o mesmo DSCP, terá que ser realizada a função de controlo de admissão e autorização de serviço, havendo em caso de sucesso, a inclusão de mais uma política no router de acesso relativa a esse terminal.