Qualidade de Serviço em Redes de

Comutação de Pacotes

FEUP/DEEC
Redes de Banda Larga
MIEEC – 2008/09
José Ruela

Qualidade de Serviço (QoS) – conceito

• Do ponto de vista do utilizador de uma aplicação ou serviço que requer a
cooperação de uma ou mais redes para o transporte de dados, a Qualidade de
Serviço (QoS – Quality of Service) recebida está relacionada com o grau de
satisfação experimentado e depende de vários factores
– A avaliação subjectiva (perceptiva) do utilizador
– As expectativas do utilizador (relacionadas com custo e tipo de serviço, tipo de
terminal, etc.)
– As capacidades do terminal no processamento de fluxos multimédia
– O comportamento e desempenho das redes envolvidas

• Do ponto de vista da rede, o conceito de QoS é usado para caracterizar a

capacidade de dar tratamento diferenciado a fluxos ou classes de tráfego com
características e requisitos diferentes e providenciar diferentes níveis de
garantia de entrega (largura de banda, atraso, perdas) de forma consistente e
previsível
– Deve ser possível medir e quantificar o comportamento de uma rede, de forma
objectiva, com base num conjunto limitado de parâmetros de desempenho (QoS)
Qualidade de Serviço (QoS) – princípios
• Uma rede suporta Qualidade de Serviço quando dispõe de um conjunto
de mecanismos que lhe permitem satisfazer diferentes requisitos de
tráfego e de serviço colocados por elementos de rede (e.g., um host, um
router ou uma aplicação)
• A oferta de QoS requer a cooperação de várias camadas protocolares e
dos equipamentos terminais e elementos de rede envolvidos no processo
de comunicação extremo-a-extremo
• Os requisitos de QoS de utilizadores e aplicações devem ser mapeados
em valores de atributos de serviços de rede
• Os atributos de um serviço de rede são descritos por um conjunto de
parâmetros de desempenho (parâmetros de QoS), que devem ser
observáveis, mensuráveis e controláveis
• A rede e os utilizadores negoceiam contratos que são descritos por meio
de parâmetros de tráfego e de QoS e estabelecem níveis de garantia de
QoS diferenciados por tipo de serviço

Garantias de QoS
• Absolutas vs. Relativas
– Absolutas – as garantias dadas a um classe são expressas de uma maneira que é
independente das garantias oferecidas a outras classes
– Relativas – as garantias dadas a um classe são expressas em termos relativos,
por exemplo: uma classe recebe melhor serviço que outra(s) classe(s) do ponto
de vista de um ou mais parâmetros de QoS

• Quantitativas vs. Qualitativas

– Quantitativas – as garantias quantitativas são expressas em termos numéricos,
de forma determinística ou estatística
– Qualitativas – as garantias qualitativas são expressas de forma imprecisa
(garantias vagas – loose guarantees), por exemplo: atraso pequeno, taxa de
perdas reduzida, melhor que best effort

• Determinísticas vs. Estatísticas

– Determinísticas – garantias quantitativas expressas sob a forma de limites
precisos (garantias fortes – hard guarantees)
– Estatísticas – garantias quantitativas expressas em termos estatísticos (garantias
brandas – soft guarantees)
Comutação de Pacotes e QoS
• As redes de comutação de pacotes foram originalmente concebidas e
projectadas para suportar serviços de dados que não requeriam
garantias quanto à largura de banda e ao atraso
– Exploravam multiplexagem estatística para partilha eficiente de recursos
– As redes IP, que operam no modo de comutação de datagramas
(connectionless), nem sequer garantem a entrega de pacotes (serviço best
effort)

• As técnicas de comutação de pacotes evoluíram com o objectivo de

suportar integração de serviços na mesma rede, com diferentes níveis
de garantia de entrega de pacotes
– A tecnologia ATM (Asynchronous Transfer Mode) foi desenvolvida com
estes objectivos
– As redes ATM suportam nativamente QoS, o que é facilitado pelo facto
de operarem no modo de comutação de circuitos virtuais (connection
oriented)

Necessidade de QoS em redes IP

• Apesar de as redes IP convencionais se basearem no paradigma best
effort, tal não impediu a sua utilização para o transporte de tráfego
com requisitos de tempo real, mas a qualidade oferecida depende do
nível de tráfego na rede e dos mecanismos de adaptação (débito,
atraso, perdas) implementados pelos equipamentos terminais

• O suporte de QoS em redes IP torna-se inevitável por várias razões

– Redes IP convencionais já transportam tráfego com requisitos de tempo
real e tráfego multimédia sem garantia de entrega (tipicamente sobre
RTP/UDP/IP)
– O IP é o único protocolo de internetworking aceite universalmente
– A tendência actual para comunicações totalmente baseadas em IP (all-IP
networks) acentuar-se-á com a emergência de redes de nova geração
(pós 3G), caracterizadas por uma grande diversidade de tecnologias de
acesso (nomeadamente wireless)
QoS em redes IP – contexto e desafios
• O suporte de QoS em redes IP requer extensões ao modelo best effort e a
resolução de problemas complexos que colocam novos desafios e que devem
ter em conta aspectos de natureza muito diferente
– Aumento continuado de tráfego gerado por aplicações de tempo real e aplicações
multimédia extremamente exigentes (VoIP, vídeo conferência, streaming de
áudio e vídeo, etc.) e por novas aplicações (e.g., grid computing)
– Convergência de terminais fixos e móveis
– Integração de infra-estruturas com e sem fios
• Limitações de redes de acesso sem fios – recursos limitados (potência, largura de
banda), alterações das condições do canal, handovers frequentes, etc.
• Necessidade de combinar mecanismos ao nível de rede (pacote) com mecanismos de
QoS de nível mais baixo
– Ambiente dinâmico e heterogéneo – utilizadores móveis, redes ad-hoc e redes
móveis, tráfego altamente variável
– Necessidade de soluções escaláveis
– Necessidade de actualizar (upgrade) o elevado número de routers instalados
– Necessidade de mecanismos de QoS dinâmicos e automáticos (provisão de
recursos, negociação de serviços, reserva e atribuição de recursos, etc.)

QoS em redes IP – dimensões do problema

• Os problemas a resolver têm um carácter multi-dimensional
– Diferentes camadas protocolares e planos envolvidos (dados, controlo, gestão)
– Diferentes escalas temporais – curta (pacotes, bursts), média (fluxos ou sessões),
longa (planeamento e ciclos de provisão de recursos)
– Diferentes âmbitos de controlo – acções locais ou globais
– Diferentes tipos de sistemas e diferentes modelos de organização e cooperação,
baseados em diferentes papéis e diferentes relações de negócio e confiança entre
as partes envolvidas
– Diferente granularidade – fina (aplicações individuais ou fluxos simples) ou
grossa (classes de tráfego ou fluxos agregados)
– Diferentes mecanismos e respectiva integração
• Diferentes paradigmas – mecanismos centralizados ou distribuídos, centrados nos
sistemas terminais (hosts) ou na rede, acções iniciadas pelo emissor ou pelo receptor,
controlo em ciclo aberto ou fechado, etc.
– Diferentes tecnologias que têm de interfuncionar

• São possíveis diferentes arquitecturas (modelos) de QoS (por exemplo,

IntServ e DiffServ em redes IP)
QoS – componentes funcionais
• É necessário suportar um conjunto muito diversificado de funções em
dispositivos de rede e equipamentos terminais – estas funções podem ser
organizadas num conjunto de componentes genéricos
– Gestão de Recursos (Resource Management) – os recursos da rede devem ser
geridos tendo em conta objectivos de optimização (de acordo com um ou mais
critérios)
– Gestão de Serviços (Service Management) – a rede deve disponibilizar serviços
de acordo com um contrato negociado com os utilizadores (clientes)
– Gestão de Políticas (Policy Management) – a operação da rede deve ser
governada por um conjunto de regras bem definidas, que têm ser impostas
– Gestão de Tráfego (Traffic Management) – é necessário controlar o tráfego
gerado pelos utilizadores
• Para verificar e forçar a conformidade com os serviços contratados e as políticas
aplicáveis
• Para usar recursos de forma tão eficiente quanto possível
• Para cumprir os objectivos de QoS negociados e contratados
• Estas funções são implementadas por diferentes mecanismos que podem ser
vistos como blocos básicos constitutivos duma arquitectura de QoS

QoS – blocos básicos

• Plano de dados (fluxos de tráfego / pacotes)
– Conformação (shaping) e policiamento (policing) traffic
– Classificação e marcação (marking) conditioning
– Disciplinas de serviço (queuing / service disciplines) / escalonamento
(scheduling)
– Controlo de congestionamento e gestão de filas de espera / buffers
(queue / buffer management)
• Plano de controlo
– Mapeamento de QoS
– Controlo de admissão
– Reserva e atribuição de recursos
– Encaminhamento com restrições (QoS routing)
• Plano de gestão
– Provisão de recursos (resource provisioning)
– Gestão de políticas (policy management)
– Subscrição e negociação de acordos (service level agreements)
QoS – blocos básicos (exemplo)

J. Soldatos et al., On the Building Blocks of Quality of Service in Heterogeneous IP Networks, IEEE
Communications Surveys and Tutorials, First Quarter 2005, pp. 70-89

QoS – modelo genérico (exemplo)

Hui-Lan Lu et al., An Architectural Framework for Support of Quality of Service in Packet Networks,
IEEE Communications Magazine, June 2003, pp. 98-105
QoS – arquitectura funcional (exemplo)
Tequila functional architecture

SLS – Service Level Specification

P. Trimintzios et al., A management and control architecture for providing IP differentiated services in
MPLS-based networks, IEEE Communications Magazine, May 2001, pp. 80-88

Sinalização e provisão de recursos

• Os routers e os comutadores têm de ser configurados com informação que
permita controlar as suas acções de despacho (por exemplo, regras de
classificação, tabelas de comutação e encaminhamento, parâmetros de
escalonamento e de gestão de filas de espera / buffers, etc.)
• As acções de (re)configuração podem ser realizadas de diferentes modos e em
escalas temporais muito diferentes
– Reconfigurações de longo prazo realizam-se tipicamente por procedimentos de
gestão e estão associadas à provisão de recursos (resource provisioning)
– Reconfigurações de curto prazo são necessárias como resultado de pedidos de
utilizadores e realizam-se por meio de procedimentos de sinalização
• Os protocolos de sinalização (novos ou como extensões de protocolos existentes) têm
de transportar informação relativa a QoS (para reserva de recursos, suporte de
encaminhamento com QoS, etc.)
– A natureza das aplicações presentes e futuras (e do tráfego que geram) introduz o
requisito de negociação de contratos com carácter dinâmico entre utilizadores e
fonecedores de serviços (e entre estes) e também de configuração de recursos da
rede de forma dinâmica e automática
SLA – Service Level Agreement
• Os serviços com QoS são oferecidos com base no estabelecimento de
acordos bilaterais – Service Level Agreements (SLA)

• Um SLA é estabelecido entre um cliente (customer) e um fornecedor

(provider) do serviço, e especifica as características do serviço a
receber pelo cliente e as responsabilidades das partes envolvidas
– Em SLAs estabelecidos entre operadores de rede, uma das partes
desempenha o papel de cliente e a outra o de fornecedor (os papéis
podem inverter-se noutros SLAs)

• Os aspectos técnicos de um SLA são descritos num Service Level

Specification (SLS)

• O conceito de SLA/SLS foi introduzido no contexto do modelo

DiffServ mas o seu âmbito de aplicação é geral

Subscrição de um serviço
• A subscrição de um serviço requer um processo de negociação de um
SLA, que inclui um acordo relativo às políticas de QoS a observar
– O cliente descreve os requisitos de QoS por meio dum descritor de
tráfego e valores alvo de parâmetros de QoS
– O fornecedor pode aceitar ou rejeitar as condições ou propor garantias de
QoS alternativas para o descritor de tráfego indicado pelo cliente

• A subcrição de um serviço pode incluir um acordo relativo a funções

de condicionamento de tráfego – Traffic Conditioning Agreement
(TCA) – que especifica
– Regras de classificação de pacotes e perfis de tráfego correspondentes
– Regras de condicionamento (marking / shaping / policing / dropping) a
aplicar aos fluxos de tráfego seleccionados pelo classificador
• Podem ser explicitamente indicadas no SLA
• Podem ser implicitamente derivadas dos requisitos do serviço ou de
políticas de provisão de recursos
Invocação de um serviço
• Uma vez subscrito, um serviço pode ser invocado, sendo verificada a
respectiva conformidade em relação ao perfil do serviço acordado
durante a subscrição
• A invocação pode ser implícita, não requerendo sinalização
– É o caso de um SLA estático – conforme os casos, o serviço pode ficar
imediata e permanentemente disponível após a subscrição (até ao termo
do contrato) ou apenas durante períodos predefinidos

• A invocação pode ser explícita e um protocolo de sinalização / reserva

de recursos deve ser usado para solicitar o nível de QoS requerido
– É o caso de um SLA dinâmico, que está sujeito a um processo de
Controlo de Admissão

• Tráfego em conformidade com o contrato (isto é, com o respectivo

descritor de tráfego) deve ser transportado pelo fornecedor de serviço
com as garantias de QoS acordadas (atraso, jitter, taxa de perda de
pacotes, etc.), que caracterizam o nível de QoS a providenciar

Caracterização de tráfego – objectivos

• A caracterização de tráfego gerado por uma fonte, por meio dum número limitado de
parâmetros (descritor de tráfego), é essencial para a negociação de um contrato com a
rede e desempenha um papel importante em várias funções que têm de ser suportadas
pela rede e pelas fontes de tráfego
• Em primeiro lugar, a descrição do tráfego pela fonte constitui a base para a negociação
– A rede impõe um conjunto de parâmetros e a fonte selecciona o conjunto de valores que
melhor caracteriza as características do seu tráfego
– A rede decide se o contrato pode ser aceite (Controlo de Admissão), com base na estimativa
dos recursos necessários para cumprir os objectivos de desempenho
• No caso de o contrato poder ser aceite, a rede deve reservar (comprometer) os recursos requeridos
• Os nós da rede devem implementar mecanimos de escalonamento e de gestão de buffers (filas) com
o objectivo de dar tratamento diferenciado aos fluxos de tráfego, de acordo com os contratos

• Uma fonte de tráfego deve conformar o tráfego de acordo com o contrato (shaping)
– Os valores acordados são usados como entradas para um regulador (shaper) na fonte, de
modo que o tráfego enviado para a rede esteja em conformidade com o contrato (traffic
shaping), aumentando a probabilidade que a rede trate o tráfego de acordo com o esperado

• A rede deve monitorizar o tráfego para verificar conformidade com o contrato

– Os mesmos valores são usados como entradas para um policiador (policer) na entrada da
rede, que deve aceitar pacotes conformes e descartar (ou atrasar) pacotes não conformes
(traffic policing), de modo a evitar congestionamento ou que fontes mal comportadas
possam degradar a QoS fornecida às fontes bem comportadas
Descritores de tráfego
• Os descritores de tráfego devem possuir algumas propriedades úteis
– Devem ser representativos, isto é, devem descrever os fluxos de forma
tão rigorosa quanto possível, de modo que os recursos reservados pela
rede sejam os adequados para satisfazer os requisitos
– Devem ser facilmente verificáveis (e.g., para shaping ou policiamento)
– Devem ser utilizáveis – a fonte deve ser capaz de descrever o tráfego e a
rede de realizar Controlo de Admissão de forma simples e rápida
– Devem ser preserváveis – a rede deve poder preservar as características
do tráfego ao longo da rota (mantendo assim correspondência com os
recursos reservados) ou recalcular os recursos necessários, no caso de ter
de modificar as características do tráfego
• Diferentes descritores de tráfego foram propostos para uso em redes
reais (em particular, redes ATM e redes IP)
– Consideram-se normalmente três parâmetros básicos – débito de pico
(peak rate), débito médio (average rate) e burst máximo (maximum
burst size) – que podem ser combinados de modos diferentes para formar
um descritor de tráfego

Peak rate
• Informalmente, o débito de pico (peak rate) é o débito instantâneo
máximo de uma conexão (ou fluxo)
• Em redes com pacotes de tamanho constante o peak rate é definido
como o inverso do intervalo mínimo entre pacotes consecutivos (e.g.,
peak cell rate em ATM)
• Em redes com pacotes de tamanho variável, o peak rate deve ser
especificado relativamente a uma janela temporal, sendo o maior valor
médio medido em todos os intervalos com a duração especificada
– A escolha da janela temporal deve ser tal que confira significado prático
ao débito de pico e permita distingui-lo do débito médio
• O peak rate é muito sensível a pequenos desvios dos padrões de tráfego
(quer na própria fonte quer devido ao processo de multiplexagem
temporal assíncrona ao longo da cadeia de comunicação)
– Este aspecto é especialmente evidente em redes ATM, o que justifica que
à sua definição seja associada uma tolerância temporal
Average rate
• A definição do débito médio (average rate) de uma fonte requer que seja
especificado o intervalo de tempo durante qual a média é calculada
– Para um dado intervalo definido, o débito médio é igual ao número de bits
gerados pela fonte dividido pela duração do intervalo
• Um mecanismo de controlo do débito médio requer dois parâmetros – uma
janela temporal e o número de bits que é possível transmitir nessa janela
– Dois mecanismos típicos são jumping window e moving / sliding window
• Em jumping window a média é calculada em janelas temporais consecutivas
(não sobrepostas) e o processo é reiniciado em cada intervalo (janela)
– O débito médio é muito sensível à escolha do instante de início do processo de
medida (e.g., de acordo com a definição seria possível um burst que ocorresse no
final de uma janela e no início da seguinte, ainda que o mesmo burst não fosse
permitido se ocorresse integralmente numa mesma janela com idêntica duração)
• Em sliding window a média é obtida (continuamente) em todos os intervalos
de tempo com a duração da janela definida, e portanto o controlo é apertado e
independente de qualquer instante inicial (por exemplo, em Frame Relay o
Committed Information Rate é definido desta maneira)

Maximum burst size

• Para controlar o débito médio de um fluxo de um modo que faça sentido (do ponto de
vista da reserva e atribuição de recursos), o intervalo de medida não deve ser muito
curto, pois na prática não permitiria distinguir o débito médio do débito de pico
(perdendo-se eventuais vantagens dessa distinção), nem demasiado longo (e.g., da
ordem da duração do fluxo), uma vez que neste caso o controlo não seria efectivo
(não seria possível controlar a duração dos bursts)
– O débito médio de longo prazo é sempre limitado pelo débito médio controlado em
intervalos de menor duração (mas o inverso não é verdade)
• Uma forma de conseguir um controlo mais apertado sobre o débito médio consiste em
controlar a duração (tamanho) dos bursts que podem ser enviados com o peak rate
• Num processo de chegada limitado por uma função linear – linear bounded arrival
process (LBAP) – o número de bits enviados em qualquer intervalo t é limitado por
r*t + b
em que r é o débito médio a controlar e b está relacionado com o maximum burst size
(MBS), mas é diferente deste
• Assumindo que p é o peak rate, então
MBS = b * p / (p - r) > b
b = MBS (1 - r / p)
• Estes parâmetros de tráfego são normalmente regulados por um Leaky Bucket (p) e
por um Token Bucket (r, b)
Limites LBAP de um fluxo (p, r, b)

(bits) r*t+b

r*t

MBS

p*t

Exemplo de janela deslizante – Frame Relay

• Um utilizador do serviço Frame Relay pode negociar um Committed
Information Rate (CIR) e um Committed Burst Size (CBS)
– CIR é o débito médio que a rede garante em condições normais
– CBS é a máxima quantidade de informação que a rede aceita de um
utilizador, em condições normais, durante um intervalo T = CBS / CIR
• O utilizador transmite tramas com um débito igual ao Access Rate (AR)
na interface de acesso ao serviço e são permitidos bursts até ao máximo
permitido por CBS
– CIR (e CBS) não podem ser excedidos em qualquer janela de duração T
(janela móvel ou deslizante)
• De facto é possível negociar também um Excess Burst Size (EBS)
– Quando a quantidade de informação em qualquer janela de duração T
exceder CBS, as tramas correspondentes são marcadas como elegíveis
para descarte (bit DE = 1), desde que CBS + EBS não seja excedido (caso
contrário, as tramas não conformes são simplesmente descartadas)
Controlo de janela deslizante (CIR, CBS, T)
• A figura mostra três tramas “conformes”, transmitidas com o débito de acesso (AR),
uma vez que os valores CBS e CIR não são excedidos durante T = CBS / CIR
– Outros padrões seriam possíveis (e.g., as mesmas três tramas enviadas contiguamente)

(bits)

CBS

AR

2
CIR

T t

Engenharia de Tráfego / Gestão de Recursos

• As funções de Engenharia de Tráfego têm como objectivo a gestão de
recursos de rede de modo que o tráfego submetido seja mapeado de forma
óptima na topologia da rede (optimização de recursos e de desempenho)
– A utilização eficiente de recursos e a minimização de custos, face aos requisitos
de tráfego previstos, consegue-se distribuindo o tráfego em rotas seleccionadas,
de forma a equilibrar a carga nas ligações e a evitar congestionamento
• As técnicas de Engenharia de Tráfego têm sido principalmente usadas no
cálculo de percursos que permitam acomodar padrões de tráfego altamente
previsíveis (em termos médios) e com variação lenta ao longo do tempo
– Neste caso, o processo de alteração de rotas é desencadeado por variações de
padrões de tráfego de longo prazo
• Os cenários emergentes caracterizam-se por padrões de tráfego imprevisíveis
e variáveis, bem como por alterações topológicas frequentes, em escalas
temporais curtas – tráfego de tempo real e multimédia, terminais móveis e
com ligação a várias redes (multi-homed), redes móveis, redes ad-hoc, etc.
– As funções de Engenharia de Tráfego são necessárias para estabelecer e manter
de forma dinâmica as configurações da rede, de modo a acomodar os requisitos
variáveis dos utilizadores, de acordo com informação de QoS dinâmica
Gestão de Serviços
• As funções de Gestão de Serviços processam os pedidos de serviço,
tentando maximizar o tráfego admitido (e portanto a transportar pela
rede) ao mesmo tempo que devem respeitar os compromissos (isto é,
as garantias de QoS) relativos aos SLAs/SLSs negociados
• Estas funções devem evitar sobrecarregar a rede para além de uma
carga crítica, por meio de mecanismos de Controlo de Admissão, de
modo que seja possível respeitar os acordos estabelecidos
– Subscrição de um novo SLA/SLS
– Invocação dinâmica de um SLA/SLS previamente subscrito
• As funções de Engenharia de Tráfego e de Gestão de Serviços estão
estreitamente relacionadas
– A Gestão de Serviços permite fazer uma previsão de tráfego com base
nos acordos estabelecidos e assim fixar objectivos de tráfego a ter em
conta pelas funções de Engenharia de Tráfego
– O Controlo de Admissão é baseado na disponibilidade de recursos
determinada pelas políticas de Engenharia de Tráfego

Ciclo de provisão de recursos

E. Mykoniati et al., Admission Control for Providing QoS in DiffServ IP Networks: The Tequila Approach,
IEEE Communications Surveys and Tutorials, January 2003, pp. 38-44