Qualidade de Serviço em redes IP

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 (garantias) de QoS e a capacidade de gerir a atribuição de recursos por fluxos ou classes de tráfego» Estão actualmente definidos dois modelos de QoS IP O modelo de Serviços Integrados (Integrated Services IntServ), orientado para a provisão de QoS por 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 documentos, de que se salientam» RFC 1633 Integrated Services in the Internet Architecture: an Overview» RFC 2205 Resource Reservation Protocol Version 1 Functional Specification» RFC 2210 The Use of RSVP with IETF Integrated Services» RFC 2211 Specification of the Controlled-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-a-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 são separáveis» 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-Load 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 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 ainda 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 Reservation 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 1993 e adoptado como protocolo de reserva de recursos na arquitectura de Serviços Integrados (RFC 2205) É também usado na arquitectura DiffServ, na negociação de contratos entre clientes e fornecedores de serviços (SLA Service Level 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 reservar recursos na rede e para manter a informação de estado associada» O RSVP permite a reserva de recursos em cada nó da rede mas não realiza funções de Encaminhamento, Controlo de Admissão ou Escalonamento de Pacotes, implementados por outros componentes da arquitectura Os pedidos de reserva 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» Foi concebido para aplicações multicast, sendo unicast um caso particular» A reserva de recursos é da iniciativa dos receptores (receiver initiated)» 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 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 informaçã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 reservas» A sinalização é realizada em dois passos

Reserva de recursos Descrição» 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 as mensagens de reserva sejam enviadas pelo mesmo percurso, em sentido inverso)» Os receptores solicitam a reserva de recursos em mensagens RESV, enviadas pelo percurso inverso do das mensagens PATH As mensagens RESV incluem um Flow Descriptor (FlowSpec e Filter 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 PATH PATH RESV RESV PATH RESV PATH RESV RESV

Exemplo de reserva de recursos Os receptores associam-se previamente a uma sessão multicast (cujo endereço é divulgado) P S R As mensagens PATH propagam-se na árvore multicast mantida pelos routers P R 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 reservas recebidas nos ramos, considerando o valor mais elevado para o troço seguinte no percurso até ao emissor P R P P R R R 1 R 2 R 3 R 4 P PATH R RESV P P R R P S Sender R i Receivers R Parâmetros de tráfego e de QoS FlowSpec» O FlowSpec contém informação que caracteriza o tráfego a submeter à rede (TSpec) e o serviço pretendido com QoS associada (RSpec) e é usado para reservar 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 seria obtido com reserva igual a R; S = 0 significa que deve ser reservada largura de banda igual a R, enquanto S > 0 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 forma 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 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» 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» 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: T max = [(b - M) (p - R)] / [R (p - r)] + (M + C tot ) / R + D tot T max = (M + C tot ) / R + D tot se p > R > r se R > p > r Os valores C tot e D tot representam a soma de termos C e D que devem ser considerados em cada router ao longo do percurso e que 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 QoS 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 rotas 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 de 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 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 identificadas Protocolos baseados em reservas iniciadas pelo emissor Agregação de reservas (Aggregate RSVP), com aplicação em IntServ over DiffServ» 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 4ª Geração (4G)

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 documentos, de que se salientam» RFC 2475 An Architecture for Differentiated Services» RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers» RFC 2597 Assured Forwarding 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 Specification» RFC 3246 An Expedited Forwarding 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 Services-aware MPLS Traffic Engineering

Serviços Diferenciados Objectivos» O modelo DiffServ tem como principal objectivo providenciar QoS diferenciada e de forma escalável, com base nos seguintes princípios Os serviços são oferecidos a fluxos agregados (ou classes) e não por fluxo As funções complexas são remetidas para a periferia da rede (edge), onde é feita a classificação, policiamento e agregação de tráfego Os nós internos (core) são simplificados, uma vez que não é necessário manter informação de estado e executar procedimentos de sinalização por fluxo» Um Serviço define características associadas à transmissão unidireccional de pacotes através da rede, podendo os atributos ser especificados em termos quantitativos por exemplo, valores de débito, atraso, variação do atraso e taxa de perdas, expressos de forma determinística ou probabilística em termos qualitativos por exemplo, valores de atraso ou de taxa de perdas expressos de forma imprecisa (atraso baixo ou moderado, probabilidade de entrega elevada ) em termos relativos, com base em prioridades no acesso a recursos por exemplo, uma classe de tráfego recebe melhor serviço do que outra, do ponto de vista de uma determinada medida de desempenho» A diferenciação permite satisfazer requisitos heterogéneos das aplicações e diferentes expectativas dos utilizadores, e aplicar tarifas por serviço Serviços Diferenciados Princípios Gerais» Num domínio DiffServ, os recursos são atribuídos, em cada nó, a fluxos agregados de tráfego, sem necessidade de qualquer mecanismo de sinalização entre nós para reserva de recursos por fluxo Em DiffServ o termo Behavior Aggregate (BA) é usado para referir um agregado de fluxos que são objecto dum mesmo tratamento (um BA corresponde ao que habitualmente se designa por classe de tráfego) Os nós deverão tratar de forma diferenciada pacotes de diferentes BAs» Cada pacote tem de ser marcado (identificado) de acordo com o BA a que pertence, o que permite que pacotes de um mesmo BA tenham o mesmo tratamento e que portanto evidenciem um comportamento idêntico Em DiffServ apenas são definidos comportamentos esperados (e externamente observáveis), designados por Per-Hop Behaviors (PHB) e não a forma como os nós operam de forma a produzir esses comportamentos (a descrição de um PHB deve ser feita com um elevado nível de abstracção e não deve usar termos referentes ao funcionamento interno do nó) Cada PHB define o comportamento individual de cada nó e não o comportamento extremo-a-extremo (os nós operam de forma independente)

Serviços Diferenciados Definições» Os Serviços Diferenciados são suportados com base num campo DS (Differentiated Services) presente no cabeçalho de pacotes IP; o campo DS foi definido de forma a ser compatível com os octetos Type of Service (ToS) em IPv4 e Traffic Class em IPv6 e é constituído por Differentiated services codepoint (DSCP) 6 bits Explicit Congestion Notification (ECN) 2 bits» Codepoint valor específico de DSCP, que deve ser mapeado num PHB» Behavior Aggregate (BA) colecção de pacotes, de um ou múltiplos fluxos de tráfego, com o mesmo codepoint» Per-Hop Behavior (PHB) descrição do comportamento externamente observável de um BA num nó DS a descrição deve ser suficientemente detalhada de modo a permitir à rede fornecer QoS de acordo com o previsto os PHBs devem ser definidos de forma a permitir diferenciar, com granularidade suficiente, diferentes modos de atribuir recursos (buffers e largura de banda) a fluxos de tráfego em competição» Per-Hop Behavior Group conjunto de um ou mais PHBs para os quais só faz sentido a especificação e implementação simultânea, devido a uma restrição comum que se aplica a todos os PHBs do conjunto (e.g., disciplina de serviço) Serviços Diferenciados Arquitectura» A Arquitectura DiffServ é composta por um conjunto de elementos funcionais implementados nos nós da rede, incluindo um conjunto reduzido de comportamentos adoptados nos nós para despacho (forwarding) de pacotes Per-Hop Behaviors (PHB) funções de classificação de pacotes funções de condicionamento de tráfego (traffic conditioning)» A escalabilidade consegue-se através de duas medidas implementação das funções complexas (classificação e condicionamento) nos nós periféricos da rede aplicação de PHBs a fluxos agregados de tráfego previamente marcados usando o campo DS no cabeçalho de pacotes IPv4 ou IPv6

Serviços Diferenciados Modelo de Operação» Ao entrar na rede, o tráfego é classificado, eventualmente modificado (alteração de características temporais) e associado a diferentes BAs» Cada BA é identificado por um único DS codepoint» No interior da rede os pacotes recebem um tratamento diferenciado de acordo com o PHB associado ao respectivo DS codepoint (vários DS codepoints podem, no entanto, ser mapeados no mesmo PHB) não é necessário manter na rede informação de estado por fluxo ou por grupo de fluxos de um mesmo cliente» O modelo separa claramente o serviço disponibilizado a um agregado de tráfego as funções de condicionamento e os PHBs usados para fornecer serviços os valores dos codepoints usados na marcação de pacotes para seleccionar um PHB os mecanismos específicos usados em cada nó para suportar um PHB (gestão de buffers e de filas de espera, algoritmos de escalonamento, etc.) Perfil de Tráfego TCA e SLA/SLS» Um perfil de tráfego especifica as propriedades temporais de um fluxo (por exemplo, débito, tamanho máximo dos bursts, etc.) tem associadas regras que permitem determinar se um determinado pacote está ou não em conformidade com o perfil (in-profile ou out-of-profile) um perfil pode indicar que todos os pacotes marcados com um certo DS codepoint devem ser verificados por um token bucket com parâmetros especificados» Traffic Conditioning Agreement (TCA) um acordo que especifica regras de classificação de pacotes e perfis de tráfego correspondentes regras de condicionamento de tráfego a aplicar aos fluxos de tráfego seleccionados pelo classificador (inclui as regras explicitamente indicadas num SLA e regras implícitas derivadas dos requisitos do serviço e/ou das políticas de provisão de serviços no domínio)» Service Level Agreement (SLA) contrato estabelecido entre um cliente e um fornecedor de serviço (na fronteira de um domínio DS) e que especifica o serviço que o cliente deve receber (pode incluir regras explícitas de condicionamento de tráfego, que fazem parte de um TCA) a componente técnica de um SLA designa-se por Service Level Specification (SLS)

Modelo de Classificação e Condicionamento Meter Packets Classifier Marker Shaper / Policer (Dropper) Classificação de Pacotes» Classificação de pacotes função que realiza a selecção de pacotes com base no conteúdo do respectivo cabeçalho, de acordo com regras definidas» Os Classificadores de pacotes seleccionam pacotes de um fluxo com base no conteúdo de partes do cabeçalho; são suportados dois tipos de classificadores Behavior Aggregate Classifier classifica pacotes com base apenas no DS codepoint Multi-Field Classifier classifica pacotes com base na combinação de um ou mais campos do cabeçalho (endereços de origem e destino, campo DS, tipo de protocolo, portas de origem e destino, etc.)

Condicionamento de Tráfego» Condicionamento de tráfego funções de controlo realizadas com o objectivo de garantir a observação das regras especificadas num TCA, isto é, garantir a conformidade de um fluxo de tráfego com o respectivo perfil; é usado para garantir que são respeitados acordos entre domínios permitir que tráfego receba serviço diferenciado, através da marcação do codepoint apropriado e monitoração e alteração das suas características temporais, se necessário (isto é, pode incluir re-marcação, descarte ou shaping)» Funções de Condicionamento de tráfego Medida (metering) Marcação (marking) Conformação (shaping) Policiamento / descarte (policing / dropping) Funções de Condicionamento de Tráfego» Medida (Metering) processo de medir as propriedades temporais de um fluxo de tráfego seleccionado pelo classificador; o seu estado afecta o funcionamento das restantes funções de condicionamento pacotes conformes (in-profile) podem ser aceites sem alterações ou re-marcados com outro DS codepoint (no caso de terem sido marcados pela primeira vez com um valor de codepoint diferente do recomendado por omissão ou quando no domínio é usado para o fluxo um PHB diferente ou um mapeamento diferente entre codepoints e PHBs) pacotes não conformes (out-of-profile) podem ser atrasados (shaping) até se tornarem conformes, descartados (policing / dropping) ou re-marcados (mapeados em um ou mais BAs inferiores, do ponto de vista de algum indicador de desempenho, ao BA em que são mapeados os pacotes conformes)» Marcação (Marking) processo de atribuição de um valor ao codepoint de um pacote com base em regras definidas; inclui pré-marcação (antes da entrada num domínio DS) e re-marcação (em resultado do próprio processo de condicionamento de tráfego)» Conformação (Shaping) processo de atrasar pacotes num fluxo de forma a torná-lo conforme com o respectivo perfil» Policiamento (Policing) processo de descarte (dropping) de pacotes de acordo com o estado de um elemento de medida (metering) que verifica a conformidade com um perfil de tráfego

Per-Hop Behaviors» Um PHB constitui o meio de um nó atribuir recursos a um BA pacotes de um mesmo BA recebem o mesmo tratamento (PHB) um ou mais BAs (codepoints) podem ser mapeados no mesmo PHB» Os PHBs são implementados nos nós por meio de mecanismos de gestão de buffers e de escalonamento de pacotes (disciplinas de serviço) diversos mecanismos podem ser adoptados e combinados, desde que o comportamento observável de cada PHB esteja de acordo com o especificado o comportamento observável de um PHB pode depender das características de tráfego do BA associado ou das de outros BAs» Um PHB pode ser especificado relativamente a outros PHBs, em termos de prioridades no acesso a recursos (buffers e largura de banda) ou da relação entre características de tráfego observáveis e mensuráveis (atrasos e perdas) estes PHBs podem ser usados como blocos básicos para atribuição de recursos e por razões de consistência devem ser especificados como um grupo de PHBs (normalmente estes PHBs partilham uma restrição, por exemplo, uma estratégia de gestão de buffers ou de escalonamento de pacotes) as relações entre PHBs dum grupo podem ser definidas em termos de prioridades absolutas ou relativas (por exemplo, prioridades de descarte baseadas em limiares determinísticos ou probabilísticos), embora tal não seja obrigatório Gestão de Recuros Bandwidth Broker» A gestão de recursos (num domínio e entre domínios DS), configuração de nós, realização de controlo de admissão de fluxos e negociação de SLAs entre domínios pode ser baseada em entidades designadas por Bandwidth Brokers» Um Bandwidth Broker é uma entidade lógica que reside num domínio DiffServ e que tem por objectivo gerir recursos de acordo com políticas (policies) especificadas pelo administrador do domínio» Funções típicas de um Bandwidth Broker Automatizar o processo de negociação de SLAs baseado em políticas configuradas de fornecimento de serviços (service provisioning) Realizar Controlo de Admissão Estabelecer e manter acordos (SLAs) com domínios vizinhos Tradução de SLSs em um ou mais TCAs para uso dos dispositivos periféricos (edge devices) Envio dos TCAs para configuração dos edge devices do domínio Configuração dos equipamentos da rede de forma a suportar os níveis de QoS negociados

Bandwidth Broker Assured Forwarding PHB Group» O RFC 2597 define um grupo de PHBs designado por Assured Forwarding PHB Group e constituído por quatro classes e três níveis de precedência para descarte em cada classe, a que correspondem doze DS codepoints, isto é, doze níveis diferentes de garantia de entrega de pacotes este serviço oferece garantias qualitativas e relativas (com base em prioridades) a implementação de quatro classes é recomendada (mas não obrigatória) e nalguns casos poderão bastar dois níveis de precedência de descarte por classe este grupo de PHBs pode ser usado para implementar um serviço que tem sido designado por Olímpico, com três classes (bronze, prata e ouro), enquanto a quarta classe poderá ser usada par suportar um serviço idêntico a best effort» A terminologia usada no RFC 2597 não é consistente com a definição de PHB Group (RFC 2475), uma vez que as quatro classes AF operam de forma independente (não existe qualquer restrição comum às classes, mas apenas entre os níveis de precedência de descarte em cada classe) será mais correcto afirmar que um AF PHB Group é constituído por três PHBs e que cada uma das quatro classes AF é uma instância de um AF PHB Group (AF éum tipo de PHB Group e uma classe AF é uma instância do tipo AF)

AF PHB Subscrição e operação» O transporte de tráfego em classes AF está sujeito à subscrição de um débito (perfil) por parte de cada assinante (SLA) e o operador deve providenciar recursos a cada classe de acordo com os valores subscritos e o comportamento (PHB) esperado» Os pacotes IP são atribuídos (pelo cliente ou pelo fornecedor) a uma ou mais classes AF, de acordo com os serviços contratados dentro de cada classe os pacotes são marcados (pelo cliente ou pelo fornecedor) com um nível de precedência de descarte» As classes AF são tratadas de forma independente um nó não agrega tráfego de diferentes classes o nível de precedência de descarte é considerado separadamente em cada classe» Um nó DS não deve reordenar pacotes de um micro-fluxo (uma instância de um fluxo entre aplicações) que pertençam à mesma classe AF, qualquer que seja o seu nível de precedência de descarte» O tráfego AF que entra num domínio AF pode ser controlado nos vários níveis de precedência de descarte as funções de condicionamento incluem shaping, descarte, aumento ou redução do nível de precedência de descarte dos pacotes e atribuição de pacotes a outra classe AF (no entanto, estas acções não devem causar reordenação de pacotes de um micro-fluxo) AF PHB Atribuição de recursos e desempenho» A cada uma das classes é atribuída em cada nó do domínio DS uma certa quantidade mínima de recursos (buffers e largura de banda) a atribuição de recursos às classes AF pode ser feita de modo a que pacotes de diferentes classes encontrem diferentes níveis de carga no nó, de acordo com a importância relativa de cada classe uma classe pode usar mais recursos que o mínimo se existirem recursos não utilizados por outras classes AF ou por outros PHBs» Este serviço caracteriza-se por uma elevada probabilidade de entrega (melhor que best effort), desde que o tráfego não exceda o débito subscrito em situação de congestionamento, tráfego conforme (in-profile) deve receber um serviço idêntico ao esperado numa rede moderadamente carregada, enquanto que o tráfego em excesso terá uma menor probabilidade de entrega» Em cada nó o nível de garantia de despacho de um pacote IP depende de recursos atribuídos à classe a que o pacote pertence tráfego actual na classe nível de precedência (no caso de congestionamento na classe)

Expedited Forwarding PHB» O PHB designado por Expedited Forwarding (EF PHB) tem como objectivo a construção de serviços caracterizados por pequena taxa de perda de pacotes, pequena latência e jitter reduzido» O EF PHB define apenas o comportamento de cada nó o comportamento de um conjunto de nós deverá ser especificado no âmbito de um Per-Domain Behavior (RFC 3086)» Este serviço, também designado por Premium, pode ser usado em aplicações que requerem a especificação dum peak bit rate, como videoconferência, voz sobre IP (VoIP), ou emulação de uma linha dedicada SLA estático (longa duração) leased line service SLA dinâmico (curta duração) guaranteed connection» Pacotes marcados para o EF PHB podem ser remarcados na entrada de um domínio DS com outros codepoints que satisfaçam o EF PHB os pacotes EF não podem ser promovidos ou despromovidos para outro PHB apenas os pacotes com codepoints que, ao entrar num domínio DS, correspondam ao EF PHB, podem ser marcados com um codepoint que corresponde ao EF PHB no interior do domínio EF PHB Especificação» Duma forma intuitiva, o tráfego EF deve encontrar filas de espera vazias ou pequenas ao atravessar um nó DS a redução do atraso em filas de espera permite reduzir o atraso e o jitter se as filas de espera se mantiverem pequenas relativamente ao espaço disponível em bufffers, a perda de pacotes é igualmente reduzida» A formação de filas de espera ocorre se o débito de chegada de tráfego (em intervalos de curta duração) exceder o débito de saída torna-se assim necessário, ao especificar o EF PHB, definir com rigor as condições que permitem assegurar que um agregado EF é servido com um determinado débito (service rate) configurado» A especificação inicial do EF PHB (RFC 2598) revelou inconsistências e limitações, referidas na especificação que a substituiu (RFC 3246) e analisadas com detalhe noutro documento (RFC 3247 Supplemental Information for the New Definition of the EF PHB)» Para melhor compreensão do formalismo adoptado no RFC 3246, é vantajoso começar por caracterizar os problemas levantados pelo RFC 2598

EF PHB RFC 2598» No RFC 2598 afirma-se que a garantia de que não se formam filas de espera para um agregado de tráfego EF é equivalente a limitar débitos, ou seja, num nó de trânsito o débito máximo de chegada do agregado deve ser inferior ao débito mínimo de saída desse agregado, o que requer configurar os nós de modo que o agregado tenha um débito mínimo de saída bem definido, independente do estado dinâmico do nó, ou seja, da intensidade de outro tráfego (esta parte do serviço deve ser garantida pelo EF PHB) condicionar o agregado (policiamento e shaping) de modo que o débito de chegada a cada nó seja sempre inferior ao débito mínimo de saída configurado (esta parte do serviço é da responsabilidade da função de condicionamento de tráfego na entrada do domínio DS, que deve policiar o tráfego EF de acordo com um débito negociado com cada domínio adjacente a montante, sendo este débito inferior ou igual ao débito EF PHB configurado)» O EF PHB é então descrito pelas seguintes afirmações os pacotes de um agregado são tratados de tal modo que o débito de saída desse agregado deve igualar ou exceder um débito configurável, que deve ser garantido independentemente da intensidade de outro tráfego em trânsito no nó o valor médio do débito de saída deve ser pelo menos igual ao débito configurado, quando a média é calculada em qualquer intervalo de tempo igual ou superior ao tempo que seria necessário para transmitir, com o débito configurado, um pacote de tamanho igual ao MTU» A última afirmação é inconsistente com o significado intuitivo de débito configurado, conforme referido no RFC 3246 e demonstrado no RFC 3247 EF PHB RFC 3246» No RFC 3246 é afirmado que para garantir que os pacotes EF encontram filas pequenas é necessário que o débito de serviço de pacotes EF em qualquer interface de saída exceda o débito de chegada a essa interface em intervalos de tempo longos e curtos, independentemente da carga de outro tráfego (não EF)» O RFC 3246 elimina as inconsistências presentes no RFC 2598 define um PHB que garante que os pacotes recebem serviço com um débito superior ou igual a um valor configurado e fornece um meio de quantificar a precisão com que o débito de serviço é oferecido em qualquer intervalo de tempo (ultrapassando as dificuldades associadas à definição da escala temporal usada no RFC 2598 para calcular débitos) fornece um meio para quantificar o atraso máximo e o jitter que um pacote pode sofrer em condições operacionais sujeitas a limites impostos (por exemplo, tráfego limitado por um token bucket)» A definição intuitiva de EF é simples o débito a que o tráfego EF é servido numa interface de saída deve ser pelo menos igual a um débito configurado R, num intervalo de tempo apropriadamente definido, e independente da carga oferecida na interface por tráfego não EF

EF PHB (RFC 3246) Formalização» A formalização da definição intuitiva de EF tem vários problemas é difícil definir a escala temporal para medir o débito (intervalos curtos introduzem erros de amostragem e intervalos longos podem permitir um jitter excessivo) o tráfego EF não pode ser servido com um débito R se não existirem pacotes à espera de ser servidos (mas pode não ser possível determinar externamente se existem de facto pacotes disponíveis para escalonamento) vários exemplos triviais (apresentados no RFC 3247) evidenciam contradições entre o significado intuitivo de débito configurado e a definição do RFC 2598» A definição formal adoptada no RFC 3246 tem em conta estes aspectos, pois assume que os pacotes EF deviam ser idealmente servidos com um débito igual ou superior a R e limita o desvio entre o instante real de partida de cada pacote e o instante ideal de partida desse pacote o instante ideal de partida dos pacotes é calculado iterativamente o desvio entre os instantes real e ideal de partida dos pacotes pode ter várias causas e depende do tipo de escalonador EF PHB Controlo de tráfego EF» Na entrada de um domínio DS o tráfego EF deve ser policiado de acordo com o débito negociado com o domínio adjacente a montante pacotes que excedam o débito negociado devem ser descartados» Embora o EF PHB tenha como objectivo construir serviços com uma reduzida taxa de perdas, pode acontecer que seja necessário descartar pacotes EF devido ao tamanho finito dos buffers e à ocorrência de bursts de pacotes recebidos simultaneamente em várias interfaces de entrada um nó pode então ser caracterizado pela região de operação em que não ocorre perda de pacotes EF devido a congestionamento isto pode ser especificado, usando um token bucket (com débito de geração de tokens r < R e profundidade B), como a soma do tráfego em todas as interfaces de entrada destinado a uma interface de saída que pode ser tolerado sem perdas» Se o EF PHB for implementado por um mecanismo de prioridade estrita, deve ser limitado o prejuízo causado a tráfego não EF, usando em cada nó um limitador baseado num token bucket (com parâmetros configurados pelo administrador da rede), sendo o tráfego em excesso descartado

EF PHB Definição formal» O RFC 3246 apresenta uma definição formal do EF PHB, através de dois conjuntos de equações, correspondentes a dois modelos em ambos os modelos consideram-se os pacotes recebidos em qualquer interface de entrada e destinados a uma dada interface de saída I» Num dos modelos, a identidade dos pacotes não é preservada no interior de um nó, isto é, os pacotes são identificados separadamente com um número de ordem de chegada e de saída um índice j refere, conforme se trate da entrada ou da saída, o número de ordem de chegada ao nó dos pacotes destinados à interface I (qualquer que seja a interface de entrada) ou o número de ordem de saída dos pacotes na interface I o mesmo número de ordem na entrada e na saída pode não corresponder ao mesmo pacote, devido à recepção de pacotes em várias interfaces de entrada destinados à mesma interface de saída e ao escalonamento complexo no nó» No outro modelo a identidade dos pacotes é preservada (packet aware) um índice j é usado para identificar um pacote pelo seu número de ordem de chegada ao nó um pacote é identificado pelo mesmo número de ordem na entrada e na saída EF PHB Parâmetros (modelo formal)» Parâmetros do primeiro modelo (identidade dos pacotes não preservada) d_j é o instante em que o último bit do pacote j (na saída) de facto abandona o nó f_j é o instante alvo de partida do pacote j (na saída), isto é, o instante ideal no qual ou antes do qual o último bit do pacote deveria abandonar o nó a_j é o instante real de chegada ao nó do último bit do pacote j (na entrada) destinado à interface I l_j é o tamanho (bits) do pacote j (na saída) a abandonar o nó R é o débito configurado (bit/s) na interface I E_a é um termo de erro para o tratamento de um agregado EF e representa um limite superior de (d_j - f_j), qualquer que seja j, isto é, do desvio entre os instantes real e ideal de partida do mesmo pacote» O significado dos parâmetros do segundo modelo é idêntico ao do primeiro, com a ressalva de que a identidade dos pacotes é preservada D_j, F_j e L_j referem-se ao pacote com ordem de chegada j, sendo A_j o instante real de chegada ao nó do último bit desse pacote E_p é um termo de erro para o tratamento de pacotes EF individuais e representa um limite superior para (D_j - F_j), qualquer que seja j, isto é, do desvio entre os instantes real e ideal de partida do mesmo pacote

EF PHB Equações (modelo formal)» O primeiro modelo é descrito pelas seguintes equações d_j < f_j + E_a, para qualquer j > 0 f_j é definido iterativamente por f_0 = 0, d_0 = 0 f_j = max (a_j, min (d_j-1, f_j-1)) + l_j / R, para j > 0 (eq_1) (eq_2) (os valores para j = 0 não se referem à partida efectiva de um pacote, sendo usados apenas pela necessidade de recursão; a origem dos tempos deve ser escolhida de modo a que não haja pacotes no sistema nesse instante)» O segundo modelo é descrito pelas seguintes equações D_j < F_j + E_p, para qualquer j > 0 (eq_3) F_j é definido iterativamente por F_0 = 0, D_0 = 0 F_j = max (A_j, min (D_j-1, F_j-1)) + L_j / R, para j > 0 (eq_4) (os valores para j = 0 são considerados apenas pela necessidade de recursão) EF PHB Figuras de mérito» E_a e E_p podem ser consideradas figuras de mérito de um nó um valor pequeno de E_a significa que o nó é capaz de servir um agregado EF com débito R em escalas temporais curtas, enquanto que um valor elevado significa que o escalonador tem um comportamento irregular (bursty) e que apenas consegue garantir o débito R em intervalos de tempo longos (o desvio em relação ao débito ideal é tanto maior quanto maior for o E_a do nó) um pequeno valor de E_p significa um controlo apertado do atraso sofrido por um pacote individual, enquanto que valores elevados de E_p podem dever-se à ocorrência de chegadas quase simultâneas de pacotes em várias interfaces ou ao mecanismo interno de escalonamento» E_a é uma medida do desvio em relação ao serviço ideal (débito R) de um agregado EF e E_p é uma medida de um serviço não ideal e de um tratamento diferente de FIFO dos pacotes de um agregado EF os factores que contribuem para o aumento de E_a igualmente provocam o aumento de E_p e normalmente E_p é superior ou igual a E_a no caso de um nó ideal com buffers na saída e serviço FIFO, E_a = E_p = E» Um nó EF deve poder ser caracterizado pela gama de valores possíveis de R em conformidade com as equações e pelos valores de E_a e E_p que é possível satisfazer (em cada interface)

EF PHB Atraso e jitter» Conhecido o valor de E_p e os limites impostos ao tráfego submetido a uma interface de saída, é possível determinar limites superiores do atraso e do jitter do tráfego EF que deixa o nó através dessa interface» O atraso é limitado por D_p = B / R + E_p sendo R o débito configurado na interface e admitindo que o tráfego total na interface de saída é limitado por um token bucket com parâmetros r < R e B» Uma vez que o atraso mínimo é pelo menos zero, D_p é também um limite superior para o jitter um limite mais apertado para o jitter pode ser obtido se conhecida a componente fixa de E_p» No caso em que E_a = E_p = E (buffers na saída e serviço FIFO), o valor de E pode ser determinado para vários escalonadores E = MTU / C no caso de fila com prioridade estrita (MTU é o tamanho máximo dos pacotes e C é a capacidade da ligação física) E = MTU / C + MTU / R, no caso de um escalonador WF2Q Conclusões» Para além do AF PHB e EF PHB, outros PHBs podem vir a ser especificados» Os aspectos funcionais do suporte de DiffServ em redes MPLS são discutidos no RFC 3270, mas a garantia de QoS requer a combinação de DiffServ com os mecanismos de Engenharia de Tráfego do MPLS o modelo DiffServ por si não garante QoS, visto que não controla as rotas seguidas pelos pacotes e em caso de congestionamento não garante largura de banda o MPLS permite encaminhar tráfego através de rotas específicas e, combinado com encaminhamento sujeito a restrições, pode garantir largura de banda a FECs, mas por si não especifica tratamento diferenciado de classes de fluxos os aspectos específicos de Engenharia de Tráfego aplicados a redes DiffServ são tratados no RFC 3564, existindo vários modelos em estudo» A operação de IntServ sobre redes DiffServ é tratada no RFC 2998