PRESSUPOSTOS E RELAÇÕES IMPORTANTES

O cenário que se considera é o de uma rede DiffServ com mecanismos de Engenharia de Tráfego idênticos aos que seriam disponibilizados por MPLS (pelo que se considera este caso como referência).

Assume-se que o tráfego de cada classe DiffServ (EF, AF e BE) é associado a LSPs distintos. Assume-se ainda que, com base nos mecanismos de Engenharia de Tráfego, é associada largura de banda a cada LSP estabelecido na rede (compatível com a repartição da largura de banda disponível para as várias classes de tráfego determinada, por exemplo, por políticas administrativas).

Isto tem duas consequências (vantagens) importantes, que são exploradas pelo algoritmo de escalonamento:

• em primeiro lugar, o mecanismo de Controlo de Admissão pode fazer uso da informação relativa à largura de banda total atribuída ao LSP que transportará o fluxo objecto de negociação, bem como do nível actual de tráfego aceite pelo LSP (com base nos parâmetros negociados pelos fluxos já admitidos ou em medidas efectivas do nível real de tráfego) e das características e requisitos do fluxo a admitir.

• em segundo lugar é possível em cada nó e em cada interface de saída associar largura de banda a cada classe DiffServ e que é simplesmente a soma das larguras de banda atribuídas a todos os LSPs que atravessam essa interface e que transportam tráfego dessa classe.

O algoritmo de escalonamento proposto e cujos princípios e fundamentos serão apresentados a seguir será discutido nesta perspectiva.

Consideram-se três classes de tráfego, que passaremos a designar por EF, AF e BE. Cada classe tem associada uma certa largura de banda (ou capacidade), que será designada, respectivamente, por CEF, CAF e CBE, sendo a respectiva soma igual à

C C C

C_EF + _AF + _BE =

Pressupõe-se desta forma que a classe BE tem, implicitamente, associada uma largura de banda mínima garantida que corresponde à largura de banda não atribuída a EF e AF.

Admitimos ainda que o tráfego EF e o tráfego AF são objecto de controlo de admissão, sendo definidos limiares de aceitação tipicamente inferiores às capacidades associadas aos respectivos LSPs (o que corresponde a um certo nível de overprovisioning). Acresce ainda que o nível de tráfego efectivamente negociado e aceite pode ser inferior a esses limiares e que o tráfego efectivamente gerado é tipicamente inferior ao contratado (no limite poderia ser igual, uma vez que a função de policiamento impede que seja superior).

Isto significa que em cada nó e em cada interface os níveis médios de tráfego EF e AF são, em princípio, inferiores às respectivas capacidades associadas. A capacidade nominalmente atribuída a cada classe pode, eventualmente, ser (muito) superior à necessária para escoar o tráfego real, o que em primeiro lugar permite oferecer a essa um desempenho (muito) superior ao esperado e, em segundo lugar, disponibilizar a outras classes os recursos não utilizados. O escalonador tem como referência a capacidade atribuída a cada classe e não (no caso de EF e AF) o nível de tráfego de facto aceite pelo processo de Controlo de Admissão.

A cada classe é associado um débito de serviço de referência que é nominalmente igual à respectiva capacidade, isto é, R_EF =C_EF, R_AF =C_AFe R_BE =C_BE, sendo portanto

C R R

REF + AF + BE =

Admitimos que no caso de tráfego AF o critério de Controlo de Admissão será baseado no débito médio dos fluxos, enquanto que no caso de EF poderá ser usado um

critério de débito médio ou de débito de pico. No último caso o nível efectivo de utilização de recursos será menor do que no primeiro caso (menor número de fluxos admitidos), pelo que o nível de reutilização por outras classes (em particular por BE) será superior.

Designamos por rAF o valor médio negociado dos fluxos AF aceites pelo processo de

Controlo de Admissão e assumimos que rAF ≤RAF.

No caso de tráfego EF, representamos por pEF o débito de pico (que será na pior das

hipóteses a soma dos débitos de pico dos fluxos aceites) e por rEF o valor do débito

médio total dos fluxos aceites. Dependendo do modelo de controlo de admissão, poderá eventualmente ser conhecido (negociado) apenas um dos valores. Conforme os casos será r_EF ≤R_EF ou p_EF ≤R_EF, mas uma vez que r_EF ≤ p_EF será sempre, em qualquer caso, AF EF AF EF r R R r + < +

No entanto, se for usado um critério de débito médio para a aceitação de tráfego EF, deveria ainda garantir-se

C r p_EF + _AF <

A não verificação desta condição (que é externa e portanto não controlada pelo escalonador) pode induzir uma penalização temporária para o tráfego AF. No entanto, conforme se verá, o escalonador está preparado para lidar com esta situação, tentando minimizar os problemas que lhe estão associados.

Nota: Os problemas de Engenharia de Tráfego e Controlo de Admissão não são obviamente tratados no âmbito deste trabalho. No entanto o algoritmo de escalonamento tem impacto no desempenho global do sistema, pelo que informação relacionada com o desempenho e os recursos utilizados pode ser usada para:

• alteração dinâmica de limiares do mecanismo de Controlo de Admissão (o que não tem qualquer impacto nos parâmetros do algoritmo de escalonamento, mas que pode afectar o volume de tráfego aceite por classe e portanto o respectivo desempenho);

• alteração da distribuição de largura de banda pelas classes, o que tem como consequência a alteração de parâmetros do escalonador (mas o mesmo aconteceria por exemplo em WFQ com a necessidade de alteração de pesos). Estas alterações são, em princípio pouco frequentes.