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

Transcrição

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

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

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

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

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

6 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 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

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

8 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

9 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

10 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

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

12 Limites LBAP de um fluxo (p, r, b) (bits) r * t + b r * t MBS b p * t 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)

13 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 3 AR 2 CIR 1 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

14 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