Blog

Qualidade de Serviço em redes IP FEUP/DEEC/RBL – 2005/06 José Ruela Modelos de QOS em Redes IP » Historicamente as redes IP têm baseado o seu funcionamento num modelo de serviços best effort, caracterizado por não oferecer quaisquer garantias quanto à entrega ou ao atraso na entrega de pacotes Com o objectivo de suportar na mesma infra-estrutura IP aplicações de dados elásticas e aplicações com requisitos de tempo real tornou-se necessário criar extensões ao modelo tradicional best effort, que incluam o suporte de diferentes níveis (gar atribuição de recurso actualmente definido O modelo de Serviç ntServ), orientado p 29 S. p view nent page idade de gerir a e tráfego » Estão d Services — r fluxo (aplicações individuais) e que normalmente é associado ao protocolo RSVP (Resource ReSerVation Protocol) O modelo de Serviços Diferenciados (Differentiated Services — DiffServ), orientado para a provisão de QoS a classes de serviço ou fluxos de tráfego agregados Modelo de Serviços Integrados Serviços Integrados na Internet O IETF propôs inicialmente um modelo dito de Serviços Integrados — Integrated Services (IntServ) – descrito em vários ocumentos, de que se salientam » RFC 1633 – Integrated Seruices In the Internet Architecture: an Overview » RFC 2205 – Resource Reservation Protocol – Version 1 Functional Specification » RFC 2210 — The Use of RSVP with IETF of the ControlIed-Load Network Element Service » RFC 2212 Specification of Guaranteed Quality of Service » RFC 2215 General Characterization Parameters for Integrated Services Network Elements » RFC 2998 – A Framework for Integrated Services Operation over DiffServ Networks Serviços Integrados — Princípios » O modelo IntServ é orientado para o suporte de QoS extremo- -extremo a fluxos individuais de pacotes (flows) e baseia-se no pressuposto de que, para atingir este objectivo, é necessário que os routers no percurso de dados tenham capacidade de reservar recursos – Um fluxo é uma sequência de pacotes relacionados e que recebem idêntico tratamento em cada nó, sendo normalmente identificado pelo conjunto de endereços IP (origem e destino), portas (origem e destino) e tipo de protocolo » O modelo IntServ necessita de um protocolo de sinalização para reserva de recursos e requer que os routers mantenham informação de estado por fluxo O protocolo RSVP foi escolhido para o efeito, mas IntServ e RSVP sao separavels » No modelo IntServ são propostas duas classes de serviço, para além do serviço best effort Guaranteed Service — para aplicações que requerem que o atraso dos pacotes não exceda um valor pré-definido, que deve ser garantido – Controlled-l_oad Service – para aplicações que são tolerantes e se adaptam a perdas ocasionais de pacotes (incluindo as resultantes de atrasos superiores a um valor limite aceitável) Serviços Integrados – Funções » O modelo IntServ requer um conjunto de funções necessárias ara suportar QoS, controlar o con estionamento e partilhar largura de banda por vária necessárias para suportar QoS, controlar o congestionamento e partilhar largura de banda por várias classes de tráfego » As funções directamente relacionadas com a transferência (forwarding) de pacotes incluem a Classificação e o Escalonamento dos pacotes, de acordo com a classe e o fluxo a que pertencem; associada a estas funções deve existir uma política de Descarte, em caso de congestionamento, e um mecanismo de Policiamento que permita verificar a conformidade dos fluxos » As funções de controlo de tráfego Incluem anda o Controlo de Admissão de fluxos, que para além da disponibilidade de recursos e das garantias de QoS a providenciar, deve ter em conta pol[ticas administrativas no que se refere à reserva de recursos (Policy Control) » São ainda necessárias várias funções de suporte (e protocolos associados), nomeadamente Encaminhamento . com capacidade multicast), Reserva de Recursos e Gestão » Estas funções estão organizadas em componentes que constituem a base da arquitectura de routers IntServ Componentes de um Router IS Routing Agent Resentation Setup Agent Management Agent Admission Control

Routing Database Traffic Control Database Packets Packet Classifier & Forwarding Packet Scheduler RSVP – Resource ReSerVation Protocol » O RSVP foi proposto em do como protocolo de Agreement) – É usado, com extensões, na arquitectura MPLS para distribuição de etiquetas (labels) associadas a LSPs e para estabelecer rotas explícitas sujeitas a restrições » O RSVP é um protocolo de sinalização usado por emissores, receptores e routers para reseruar recursos na rede e para manter a informação de estado associada O RSVP permite a resenta de recursos em cada nó da rede mas não realiza funções e Encaminhamento, Controlo de Admissão ou Escalonamento de Pacotes, implementados por outros componentes da arquitectura – Os pedidos de resewa de recursos têm de ser validados face aos recursos disponíveis (Controlo de Admissão) e permissões de carácter administrativo (Policy Control) RSVP – Principais caracter[sticas » É um protocolo de sinalização Não é um protocolo de encaminhamento, mas interactua com protocolos de encaminhamento – Pode necessitar de um protocolo de encaminhamento que descubra rotas sujeitas a restrições de QoS h Foi concebido para aplicações multicast, sendo unicast um caso articular A reserva de recursos é da iniciativa dos receptores (receiver inltiated) » A reserva é realizada por fluxo (isto é, a rede não agrega os fluxos que lhe são submetidos para efeito de reserva e atribuição de recursos no seu interior) e tem um carácter temporário » A sinalização (reserva de recursos) é feita para fluxos unidireccionais (simplex) » Transporta parâmetros relativos a QoS e políticas (FlowSpec, FilterSpec) – Não impõe qualquer tipo de política administrativa ou de controlo de admissão – Permite configurar os classificadores de pacotes, mas não realiza escalonamento admissão – Permite configurar os classificadores de pacotes, mas não realiza escalonamento Modelo de reserva de recursos – Análise » A reserva de recursos é da iniciativa do(s) receptor(es) Esta opção foi determinada pela necessidade de suportar aplicações multicast e receptores heterogéneos, que podem ter capacidades e portanto requisitos diferentes – Nestas condições, a reserva de recursos iniciada pelo(s) receptor(es) é mais facilmente escalável do que reservas iniciadas pelo emissor » A reserva é unidireccional e por fluxo – Requer que cada router no percurso de dados mantenha nformação do estado das reservas por fluxo » O modelo de reserva é do tipo soft state – As reservas são mantidas temporariamente, sendo eliminadas se não forem refrescadas (actualizadas) regularmente pelos receptores (por exemplo, a intervalos de 30 s) — Este modelo (soft state) é mais robusto do que o modelo usado em ATM, que é do tipo hard state, uma vez que não é necessário remover explicitamente as reser,’as » A sinalização é realizada em dois passos Reserva de recursos – Descrição h Os emissores enviam periodicamente mensagens PATH, com endereços unicast ou multicast As mensagens PATH incluem um TSpec e um Sender Template (que contém o formato dos dados e o endereço e a porta de origem) para fornecer aos receptores informação sobre as características do tráfego e do(s) emissor(es), possibilitando assim reservas compatíveis com a natureza do emissor e os requisitos a satisfazer – São usadas para a descoberta de rotas e para instalação nos routers de informa ão de estado relativa a rotas (o que permite que de rotas e para instalação nos routers de informação de estado relativa a rotas (o que permite que as mensagens de reserva ejam enviadas pelo mesmo percurso, em sentido inverso) » Os receptores solicitam a resen,’a de recursos em mensagens RESV, enviadas pelo percurso inverso do das mensagens PATH – As mensagens RESV incluem um Flow Descriptor (FlowSpec e Alter Spec) – O FlowSpec é constituído por um TSpec, idêntico ao do emissor, e por um RSpec – O FilterSpec (idêntico ao Sender Template) inclui informação para configurar os classificadores de pacotes – As reservas sinalizadas por múltiplos receptores de uma mesma sessão pode ser agregada (consolidada) nos routers intermédios até ao emissor

RSVP – Sinalização em dois passos PATH RESV RESV PATH PATH PATH RESV PATH RESV RESV Exemplo de reserva de recursos • Os receptores associam-se previamente a uma sessão multicast (cujo endereço é divulgado) • As mensagens PATH propagam- se na árvore multicast mantida pelos routers • As reservas solicitadas pelos receptores são Independentes (podendo ser diferentes, de acordo com as características e os requisitos de cada um) e propagam-se em sentido inverso na árvore • Cada router deverá consolidar as resentas recebidas nos ramos, considerando o valor mais elevado para o troço seguinte no ercurso ate ao emissor PRP P R RI P- PATA R – RESV R2 R3 S- Sender Ri- Receivers R URPPPRSPR 6 OF2g tráfego a submeter à rede (TSpec) e o serviço pretendido com QoS associada (RSpec) e é usado para reser,’ar recursos e parameterizar os escalonadores » TSpec inclui os seguintes parâmetros • • • p – peak rate r – token bucket rate b – bucket size M maximum datagram size m – minimum policed unit » RSpec é apenas especificado para o serviço Garantido e inclui • R – service rate (deve ser superior ou igual a r) • S – delay slack; representa o atraso adicional aceitável, relativamente ao que eria obtido com reserva igual a R; S 0 significa que deve ser reservada largura de banda igual a R, enquanto S > O significa que pode ser reservada uma largura de banda inferior a R que cumpra o atraso tolerado Controlled-Load Service » Aplicações que se adaptam a perdas ou atrasos ocasionais têm um desempenho aceitável mesmo quando usam um serviço best effort, desde que não ocorra congestionamento » O objectivo do Serviço de Carga Controlada é emular o serviço best effort que se obteria numa rede pouco carregada, isto é, o desempenho deve ser praticamente independente da carga, não se deteriorando de orma perceptível com o aumento da carga » Esta caracterização é intencionalmente imprecisa e significa que este serviço não oferece garantias quantitativas firmes, mas apenas que uma percentagem muito elevada de pacotes é entregue com sucesso — o atraso sofrido pela maior parte dos pacotes submetidos em conformidade com o contrato (TSpec) não excede de forma significativa o atraso mínimo que se obteria com a rede pouco carregada » O emissor especifica um TSpec (não é necessário indicar o peak rate), não h O emissor especifica um TSpec (não é necessário indicar o eak rate), não sendo especificado um RSpec; a rede limita a quantidade máxima de tráfego deste tipo (Controlo de Admissão) e escalona-o numa classe separada » A rede verifica a conformidade do tráfego caracterizado pelo TSpec; tráfego não conforme é enviado como best effort Guaranteed Service h O Serviço Garantido oferece garantias estritas para aplicações com requisitos de tempo real: – Largura de banda garantida – Atraso extremo-a-extremo majorado (e controlado passo a passo); não é especificado pelo utilizador, mas pelo serviço no momento em que é invocado –

Ausência de perdas de pacotes conformes nas filas de espera dos routers h Os recursos são reservados por fluxo, com base num Flowspec (TSpec e RSpec); se o pedido for aceite, cada router ao longo do percurso reserva uma largura de banda R e um número de buffers B para o fluxo » O limite superior para o atraso extremo-a- extremo é dado por: Trnax – [(b – M) (P – R)] / [R (P – r)] + (M + Ctot)/R + otot Tmax = (M + Ctot) / R + Dtot se p > R > r se p > r Os valores Ctot e Dtot representam a soma de termos C e D que devem ser considerados em cada router ao longo do percurso e ue dependem, entre outros, do algoritmo de escalonamento, da largura de banda e do atraso de propagação da ligação física com o próximo router e do tamanho máximo dos pacotes do fluxo Análise do modelo » As principais vantagens apontadas ao modelo IntServ, por comparação com o modelo de os ATM, são a robustez (soft state) e a escalabilidade d de reserva de recursos ATM, são a robustez (soft state) e a escalabilidade do mecanismo de reserva de recursos (iniciada pelos receptores) » As reservas iniciadas pelo(s) receptor(es) têm algumas limitações – Requerem instalação e manutenção de informação sobre otas nos routers – As reservas são unidireccionais, o que obriga a duplicar os procedimentos no caso de serviços com tráfego bidireccional, e requrem dois passos » Para além disso, o modelo tem limitações de escalabilidade, que põem em causa a sua viabilidade em redes de grande dimensão, devido ao facto de a reserva de recursos ser temporária e orientada a fluxos individuais – É necessário processar um elevado número de mensagens de sinalização e manter em cada router informação de estado por fluxo e realizar o seu refrescamento periódico – É necessário Classificar, Policiar e Escalonar pacotes por fluxo e invocar

Controlo de Admissão de cada vez que é feito um pedido de reserva de recursos – O tráfego de sinalização pode consumir recursos de transmissão significativos » O modelo de Serviços Diferenciados (DiffServ), baseado em princípios diferentes dos adoptados no modelo IntServ, procura ultrapassar algumas destas limitações IntServ e outros modelos » O modelo IntServ (associado ao protocolo RSVP) foi desenvolvido para providenciar garantias de QoS extremo- a-extremo assumindo uma arquitectura homogénea de QoS (modelo single-tier) » A necessidade de suportar QoS através e múltiplas redes independentes, baseadas em diferentes tecnologias e modelos de QoS requer a distinção entre sinalização no mesmo domínio e entre dom[nios (modelo two-tier) – Um exemplo é o distinção entre sinalização no mesmo dominio e entre dominios (modelo two-tier) – Um exemplo é o suporte de IntServ sobre DiffServ (IntServ over Diffserv ) » Mais do que soluções alternativas, os modelos IntServ e DiffServ podem ser vistos como complementares, com âmbitos de aplicação específicos Foram propostas soluções alternativas ou extensões ao RSVP para ultrapassar algumas das limitações dentificadas – Protocolos baseados em reservas iniciadas pelo emissor — Agregação de reservas (Aggregate RSVP), com aplicação em IntServ over DiffServ h Actualmente está em discussão no IETF um novo modelo de sinalização designado por NSIS (Next Steps in Signaling) adequado para os novos cenários de redes de comunicação de 4a Geração Modelo de Serviços Diferenciados Serviços Diferenciados na Internet O modelo de Serviços Diferenciados – Differentiated Services (DiffServ) – desenvolvido pelo IETF está descrito em vários » RFC 2475 – An Architecture for Differentiated Services » RFC 474 — Definition of the Differentiated Services Field (DS Field) in the IPV4 and IPv6 Headers RFC 2597 – Assured porwarding PHB Group » RFC 2998 – A Framework for Integrated Services Operation over DiffServ Networks » RFC 3086 — Definition of Differentiated Services Per Domain Behaviors and Rules for their speciflcation » RFC 3246 – An Expedited porwarding PHB (substitui RFC 2598) » RFC 3260 – New Terminology and Clarification for DiffServ » RFC 3270 – Multi-protocol Label Switching (MPLS) Support of Differentiated Services » RFC 3564 — Requirements for Support of Differentiated 0 DF 29