DiffServ

A primeira definição do DiffServ surgiu no âmbito do IETF no final de 1998 [Carl98]. O grande objectivo do DiffServ é conseguir um método simples e básico de fornecer a capacidade de diferenciar tráfego, através do agrupamento dos fluxos num conjunto limitado e bem definido de classes de serviço (CoS), para suportar diferentes tipos de aplicação e tráfego. Este agrupamento é apenas realizado nos nós exteriores das redes (nós fronteira ou edge). Desta forma, não é necessário armazenar informação sobre qual o tratamento a dar a cada fluxo, mas apenas sobre cada uma das N classes de agregação.

O modelo DiffServ baseia-se num conjunto pequeno e bem definido de blocos a partir dos quais uma grande variedade de comportamentos agregados se podem obter.

De modo a obter QoS extremo-a-extremo, a arquitectura DiffServ apresenta dois componentes fundamentais: a marcação de pacotes e os “comportamentos por salto” (Per

Hop Behaviours – PHBs).

Numa rede DiffServ, os nós fronteira têm responsabilidades diferentes das dos nós do núcleo. Os nós fronteira têm as tarefas de classificação dos pacotes e de

Serviços Multimédia Sobre Redes Heterogéneas

88

condicionamento do tráfego. Os nós do núcleo necessitam apenas de classificar os pacotes com base nas classes de serviço mapeadas no cabeçalho dos pacotes. Os nós fronteira são os responsáveis pela verificação do cumprimento dos limites dos contratos, procedendo a remarcações, formatação e descarte, caso exista violação dos valores contratados.

A desvantagem deste modelo reside no facto de não estar orientado ao fluxo e, portanto, só por si, não garantir que cada aplicação recebe os recursos de que necessita. Para colmatar esta deficiência, conjuntamente com este mecanismos poderão ser usados agentes de gestão e controlo de admissão (Brokers), como veremos mais adiante.

4.3.3.1 Marcação de pacotes

Existe no cabeçalho de cada pacote IP um campo de 8 bits, TOS no IPv4 e Classe de Tráfego no IPv6, que é utilizado para marcar um pacote de forma a que este receba um tratamento particular no encaminhamento e em cada um dos saltos nos nós de rede. Para obter uma operação consistente e comportamentos previsíveis em ambientes inter domínio e multi-vendedor, é necessário que exista um entendimento comum acerca da interpretação e utilização destes campos. Assim, o grupo de trabalho do DiffServ normalizou um formato comum para os 6 primeiros bits de ambos os octetos (TOS e Classe de Tráfego), chamados de campo DS (Differentiated Services field) (Figura 14) na arquitectura DiffServ. A cada valor possível de obter com esses 6 bits chama-se DSCP (Differentiated

Services Codepoint). Os RFCs 2474 [Nich98] e 2475 [Carl98] definem a arquitectura e a

utilização geral dos bits do campo DS (sobrepondo-se às definições do RFC 1349 acerca do TOS).

Utilizando a marcação por DSCP, em qualquer nó da rede é possível definir 64 classes ou agregados de serviços distintos (2^6). No modelo DiffServ, a classificação e a QoS é controlada pelo campo DSCP.

DS CP 3 4 5 6 7 2 1 0 NU Differentiated Services CodePoint (DSCP) RFC 2474 Código Selector de Classe Não Usado Figura 14: Campo DSCP

Qualidade de Serviço em Redes IP

89

4.3.3.2 Per Hop Behaviours (PHBs)

A marcação dos DSCPs dos pacotes só por si não resolve a questão de atribuir tratamento diferenciado a determinado pacote IP. Definiu-se que os pacotes marcados com o mesmo código DSCP, que atravessem determinado nó de rede em determinada direcção, teriam um comportamento semelhante, denominado de Comportamento do Agregado (Behaviour Aggregate – BA). Desta forma, pacotes relativos a diferentes aplicações, e provenientes de terminais distintos podem pertencer ao mesmo BA. O RFC 2475 define um PHB como sendo o comportamento observável a partir do exterior, aplicado por um nó DiffServ a um agregado DiffServ. Em termos mais específicos, um PHB refere-se ao escalonamento, formatação, policiamento e queuing que um nó DiffServ aplica a um qualquer pacote pertencente a um BA, de acordo com as políticas e SLAs do gestor.

Até à data existem quatro PHBs normalizados, que permitem implementar redes DiffServ, de modo a conseguir definir classes de QoS que possibilitem garantir QoS extremo-a-extremo.

4.3.3.2.1 Default PHB (Definido no RFC-2474)

O default PHB [Nich98] especifica que um pacote marcado com um valor DSCP ‘000000’ (valor recomendado) terá nos nós DiffServ o tratamento do serviço tradicional de melhor esforço (Best Effort). De igual forma, se um pacote chega a um nó DiffServ com um valor de DSCP que não pertence a nenhum outro PHB, será mapeado para o default PHB.

4.3.3.2.2 Class-Selector PHBs (Definido no RFC-2474)

De modo a preservar compatibilidade com o esquema de precedências IP, os valores dos DSCPs foram definidos segundo a forma ‘xxx000’, onde cada x pode ser 0 ou 1. Estes DSCPs são designados DSCP Selectores de Classe (Class-Selector Codepoints) [Nich98]. É de salientar que o DSCP do default PHB é também um DSCP Selector de Classe. Estes PHBs têm um comportamento semelhante àquele que é obtido utilizando um esquema baseado em precedências IP. Como exemplo, os pacotes marcados com um DSCP de ‘110000’ (Precedência IP de 110) têm um tratamento (escalonamento e queuing) preferencial em relação a pacotes marcados com um DSCP de ‘100000’ (Precedência IP de 100).

Serviços Multimédia Sobre Redes Heterogéneas

90

Estes PHBs asseguram desta forma que um nó DiffServ seja compatível e possa coexistir com nós que implementem um esquema de Precedência IP (com excepção dos bits DTR – estes não são compatíveis).

4.3.3.2.3 Expedited Forwarding (EF) PHB (Definido no RFC-2598)

Tal como o RSVP no modelo IntServ oferece um serviço de largura de banda garantida, o PHB EF [Jaco99] é o PHB chave na arquitectura DiffServ para oferecer serviços de perdas baixas, atraso baixo, variação de atraso baixa e largura de banda garantida, vulgarmente designados de serviços “premium”.

O PHB EF pode ser implementado utilizando filas de espera de prioridade estrita, juntamente com limitação de taxa de transmissão. Apesar do EF fornecer um serviço

premium, deve ser utilizado preferencialmente apenas pelas aplicações mais críticas (e.g.,

voz), uma vez que tem prioridade sobre todo o restante tráfego. Isto deve-se ao facto de, em caso de congestionamento, se todas as aplicações estiverem a utilizar prioridade elevada, não será possível dar um tratamento de prioridade elevada a todo o tráfego. O valor do DSCP recomendado pelo RFC 2474 para o EF é o ‘101110’.

4.3.3.2.4 Assured Forwarding (AFxy) PHB Group (Definido no RFC-2597)

O PHB AF [Hein99] permite implementar em ambientes DiffServ um serviço equivalente ao serviço de carga controlada da arquitectura IntServ. Este PHB define um método segundo o qual se podem dar garantias de encaminhamento distintas aos BAs. O tráfego pode, por exemplo, ser dividido em três classes, “ouro”, “prata” e “bronze”, sendo atribuída 50% da largura de banda à classe ‘ouro’, 30% à ‘prata’ e os restantes 20% à ‘bronze’. O PHB AFxy define quatro classes, a AF1, AF2, AF3 e a AF4. A cada uma destas classes é atribuído determinado espaço de buffer e de largura de banda na interface, dependendo do SLA com o fornecedor de serviço. Em cada uma destas classes é possível especificar 3 valores de precedência de descarte. Assim, em caso de congestionamento num nó DiffServ numa ligação específica, se for necessário descartar pacotes pertencentes a uma classe AFx, os pacotes da AFxy serão descartados de forma a que a probabilidade de descarte de pacotes da AFx1 será menor que a probabilidade de descarte da AFx2 que por sua vez também será menor que a da AFx3. Isto quer dizer que, em média, os pacotes da AF13 serão descartados antes dos da AF12 e estes antes da AF11. A aplicação deste conceito permite que os pacotes pertencentes a fluxos de um BA que tenham excedido a

Qualidade de Serviço em Redes IP

91

largura de banda contratada, possam ser penalizados em relação a fluxos que estão dentro do contrato. Esses pacotes podem ser remarcados para terem uma precedência de descarte maior, e desta forma, em caso de congestionamento, serão os primeiros a ser descartados.

A Tabela 6 apresenta os valores dos DSCPs para cada uma das classes e respectivas precedências de descarte. Os três primeiros bits representam a classe (001, 010, 011 e 100) enquanto que os dois seguintes representam a precedência de descarte (01, 10, 11). O último bit tem sempre o valor ‘0’.

Precedência de descarte Classe #1 Classe #2 Classe #3 Classe #4

Baixa (AF11) 001010 (AF21) 010010 (AF31) 011010 (AF41) 100010 Média (AF12) 001100 (AF22) 010100 (AF32) 011100 (AF42) 100100 Alta (AF13) 001110 (AF23) 010110 (AF33) 011110 (AF43) 100110

Tabela 6: Tabela dos DSCPs do PHB AF

4.3.3.3 Relação do DiffServ com os SLAs e SLSs

A arquitectura DiffServ define que o SLA pode incluir regras para condicionar o tráfego que em parte constituem o acordo de condicionamento de tráfego, TCA (Traffic

Conditioning Agreement). O TCA é “um acordo que especifica regras de classificação e

quaisquer padrões correspondentes de tráfego, contadores, regras de marcação, descarte e/ou formatação, que são para aplicar a fluxos de tráfego seleccionados pelo classificador” [QoSF][QoSF98]. Um TCA envolve todas as regras de condicionamento do tráfego explicitamente especificadas no SLA bem como as regras implícitas dos requisitos de serviço relevantes e/ou de uma política de aprovisionamento num domínio DiffServ.

Uma especificação de condicionamento de tráfego, TCS (Traffic Conditioning

Specification) é um conjunto de parâmetros e os seus valores, que associados especificam

um conjunto de regras de classificação e um padrão de tráfego. Um TCS é um elemento integral de um SLS.