Qualidade de Serviço em Redes de Comutação de Pacotes. Qualidade de Serviço (QoS) conceito

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.)

• 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)

• É 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 – componentes funcionais

• 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)

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 – blocos básicos (exemplo)

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)

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

Tequila functional architecture

SLS – Service Level Specification

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

• 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

SLA – Service Level Agreement

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

• 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

• 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

Descritores de tráfego

• 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

• 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)

Average rate

• 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)

• 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)

• 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)

Controlo de janela deslizante (CIR, CBS, T)

(bits) T CBS t AR CIR 1 2 3

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