Qualidade de Serviço em Redes IP

Transcrição

1 Qualidade de Serviço em Redes IP FEUP/DEEC Redes de Banda Larga MIEEC 2009/10 José Ruela Modelos de QoS em redes IP O princípio básico de funcionamento das redes IP assenta na adopção do modelo de serviços best effort, que se caracteriza por não oferecer quaisquer garantias quanto à entrega ou ao atraso na entrega de pacotes Com o objectivo de suportar na mesma infraestrutura IP não só as aplicações de dados elásticas tradicionais mas também aplicações com requisitos de tempo real, foi necessário criar extensões ao modelo best effort, que permitam oferecer diferentes níveis (garantias) de QoS e gerir a atribuição de recursos a fluxos (individuais ou agregados) ou a classes de tráfego Estão actualmente definidos pelo IETF dois modelos de QoS IP O modelo de Serviços Integrados (Integrated Services IntServ), orientado para a provisão de QoS a fluxos 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

2 Modelo de Serviços Integrados Serviços Integrados na Internet IntServ O modelo de Serviços Integrados Integrated Services (IntServ) foi o primeiro a ser proposto pelo IETF e está 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

3 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 (serviço garantido) para aplicações que requerem que o atraso dos pacotes não exceda um valor predefinido, que deve ser garantido Controlled-Load service (serviço de carga controlada) 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 de 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

4 Componentes de um router IntServ Routing Agent Reservation Setup Agent Management Agent Admission Control Routing Database Traffic Control Database Packets Packet Classifier & Forwarding Packet Scheduler Modelo de reserva de recursos IntServ 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 É necessário um protocolo de sinalização em dois passos (e.g., RSVP) Os recursos são reservados por fluxo Cada router no percurso de dados deve manter informação de estado por fluxo A rede não agrega fluxos submetidos na periferia para processamento interno A reserva de recursos é unidireccional (os fluxos são simplex) Para aplicações bidireccionais é necessário reservar recursos nos dois sentidos O modelo de reserva é do tipo soft state As reservas são mantidas temporariamente, pelo que são eliminadas se não forem refrescadas (actualizadas) regularmente pelos receptores (e.g., 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

5 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 1633) Foi especificado pelo IETF em 1997 (RFC 2205) e desde então foram considerados outros usos possíveis É 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 executado 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 (admission control) ou escalonamento de pacotes, que são 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 políticas administrativas (policy control) Reserva de recursos baseada em RSVP descrição Os emissores enviam periodicamente mensagens PATH, com endereço unicast ou multicast, que incluem informação gerada em cada emissor Sender TSpec descreve o tráfego gerado pelo emissor Sender Template contém o formato dos dados e o endereço e a porta de origem (constitui a especificação dum filtro que identifica o emissor) Esta informação enviada do emissor para o(s) receptor(es) não é modificada por elementos intermédios na rede Permite fornecer aos receptores informação sobre as características do tráfego do(s) emissor(es), possibilitando assim reservas compatíveis com a natureza do(s) emissor(es) e com os requisitos a satisfazer As mensagens PATH 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 enviar as mensagens de reserva pelo mesmo percurso, em sentido inverso)

6 Reserva de recursos baseada em RSVP descrição As mensagens PATH também transportam informação gerada ou modificada pela rede e que é usada pelos receptores para tomar decisões sobre reserva de recursos Esta informação é transportada num AdSpec e pode incluir serviços específicos de controlo de QoS e parâmetros operacionais associados, para além de parâmetros que descrevem as propriedades do percurso de dados (e.g., estimativas de atraso e de largura de banda) Esta informação é recolhida e sintetizada nos nós da rede e transportada para os receptores 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 Receiver TSpec, idêntico ao Sender TSpec, 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 podem ser agregadas (consolidadas) nos routers intermédios até ao emissor RSVP sinalização em dois passos PATH PATH PATH PATH PATH RESV RESV RESV RESV

7 Exemplo de reserva de recursos Os receptores associam-se previamente a uma sessão multicast (cujo endereço é divulgado por outros meios) P S R 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 reservas recebidas nos ramos, considerando o valor mais elevado para o troço seguinte no percurso até ao emissor P R P P P R R R 1 R 2 R 3 R 4 P PATH R RESV P P R R R P S Sender R i Receivers R RSVP sumário das 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 para descoberta de 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 (a rede não agrega os fluxos que lhe são submetidos, para efeito de reserva e atribuição de recursos) e tem um carácter temporário A reserva de recursos é feita para fluxos unidireccionais (simplex) Os pacotes de um fluxo seguem o mesmo percurso que as mensagens de sinalização que reservaram os recursos respectivos (path-coupled) 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

8 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 Serviço de Carga Controlada 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 na rede O objectivo do serviço de Carga Controlada (Controlled-Load service) é emular o serviço best effort numa rede pouco carregada, isto é, o desempenho deve ser praticamente independente da carga, não se degradando de forma perceptível com o aumento da carga na rede (originada por outros serviços) Esta caracterização é intencionalmente imprecisa e significa que este serviço não oferece garantias quantitativas firmes, mas apenas garantias qualitativas 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 observado pelos pacotes entregues com sucesso 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

9 Serviço Garantido O serviço Garantido (Guaranteed service) 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 perda 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 i e D i que devem ser considerados em cada router ao longo do percurso e que dependem, entre outros factores, 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 IntServ As principais vantagens do modelo IntServ, comparado com o modelo de QoS ATM, são a robustez (soft state) e a escalabilidade do mecanismo de reserva de recursos (iniciada pelos receptores) que tem, contudo, algumas limitações Requer 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, para além disso, requerem dois passos O modelo tem ainda limitações de escalabilidade, que põem em causa a sua viabilidade em redes de grande dimensão (número elevado de fluxos), devido à reserva de recursos ser temporária e orientada a fluxos individuais Introduz complexidade e overhead de processamento nos routers É 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 invocar controlo de admissão por cada pedido de reserva de recursos É necessário classificar, policiar e escalonar pacotes por fluxo O tráfego de sinalização consome recursos de transmissão, crescendo linearmente com o número de fluxos e a sua duração (devido à necessidade de refrescamento) O modelo de Serviços Diferenciados (DiffServ) é baseado em princípios diferentes com o objectivo de ultrapassar algumas destas limitações

10 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 (RFC 3175 e RFC 4860), com possível aplicação em IntServ over DiffServ O IETF especificou um novo modelo de sinalização designado NSIS (Next Steps in Signaling) adequado para os novos cenários de redes de comunicação pós 3ª Geração Modelo de Serviços Diferenciados

11 Serviços Diferenciados na Internet DiffServ O modelo de Serviços Diferenciados Differentiated Services (DiffServ) foi também desenvolvido pelo IETF, salientando-se os seguintes documentos relacionados com o modelo 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 3247 Supplemental Information for the New Definition of the EF PHB 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 princípios gerais O modelo DiffServ tem como principal objectivo providenciar QoS de forma diferenciada e 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 A diferenciação permite satisfazer requisitos heterogéneos das aplicações e diferentes expectativas dos utilizadores, e aplicar tarifas por serviço Num domínio DiffServ, os recursos são atribuídos, em cada nó, a fluxos agregados de tráfego, sem necessidade de realizar sinalização entre nós para reserva de recursos por fluxo O termo Behavior Aggregate (BA) é usado para referir um agregado de fluxos que são objecto dum mesmo tratamento e por isso recebem idêntico serviço (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

12 Suporte de DiffServ campo DS O suporte de Serviços Diferenciados (DiffServ) é baseado num campo DS (Differentiated Services) transportado no cabeçalho de pacotes IP O campo DS ocupa os seis bits mais significativos do campo Type of Service no cabeçalho IPv4 e do campo Traffic Class no cabeçalho IPv6 Os dois bits menos significativos daqueles campos não são usados por DiffServ No RFC 2474 eram designados currently unused No RFC 3260 é proposto alterar a designação para explicit congestion notification, que remete para o RFC 3168 The Addition of Explicit Congestion Notification (ECN) to IP Diferenciação de serviços Cada pacote tem de ser identificado e marcado 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 cada nó Os pacotes são marcados na entrada (edge) de um domínio DiffServ com um DiffServ Codepoint (DSCP) transportado no campo DS Pacotes com o mesmo DSCP constituem um Behavior Aggregate (BA) O DSCP é usado pelos nós DiffServ para dar tratamento diferenciado aos BAs, que assim evidenciam comportamentos diferentes (uma vez que recebem garantias de QoS diferentes) Os níveis de QoS são especificados por meio de valores negociados de parâmetros de QoS (com base em Service Level Agreements) Em DiffServ apenas são definidos comportamentos esperados (e externamente observáveis), designados 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 grau de abstracção e não deve usar termos referentes ao funcionamento interno do nó Cada PHB define o comportamento individual de cada nó (os nós operam de forma independente) e não o comportamento extremo-a-extremo com este propósito devem ser definidos Per-Domain Behaviors (PDB)

13 Serviços Diferenciados definições Differentiated Services Codepoint (DSCP) valor codificado no campo DS e que deve deve ser usado para seleccionar o PHB apropriado Behavior Aggregate (BA) colecção de pacotes, de um ou múltiplos fluxos de tráfego, com o mesmo DSCP Per-Hop Behavior (PHB) descrição do comportamento externamente observável de um BA num nó DiffServ A descrição deve ser suficientemente detalhada para 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., uma 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 (e.g., classificação e condicionamento) nos nós periféricos da rede Aplicação de PHBs a fluxos agregados de tráfego previamente marcados com o DSCP apropriado, no cabeçalho de pacotes IPv4 ou IPv6

14 Serviços Diferenciados modelo de operação Ao entrar num domínio DiffServ, o tráfego é classificado, eventualmente modificado (por alteração das suas características temporais) e associado a diferentes BAs Cada BA é identificado por um único DS Codepoint (DSCP) No interior da rede os pacotes recebem um tratamento diferenciado de acordo com o PHB associado ao respectivo DSCP (vários DSCPs 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 DSCPs 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) Como exemplo, um perfil pode indicar que os pacotes marcados com um certo DSCP devem ser verificados por um token bucket com parâmetros especificados Um Traffic Conditioning Agreement (TCA) especifica Regras de classificação de pacotes e perfis de tráfego correspondentes Regras de condicionamento a aplicar aos fluxos de tráfego seleccionados pelo classificador (inclui 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) Um Service Level Agreement (SLA) é um contrato estabelecido entre um cliente e um fornecedor de serviço (na fronteira de um domínio DS), 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 Service Level Specification (SLS)

15 Modelo de classificação e condicionamento Meter Packets Classifier Marker Shaper / Policer (Dropper) Os pacotes são classificados e marcados, e são medidas as suas características temporais (metering) para verificação de conformidade com o perfil de tráfego negociado Pacotes conformes são aceites, enquanto os não conformes podem ser remarcados, atrasados (reshaping) ou simplesmente descartados (policing / dropping), de acordo com as regras de condicionamento de tráfego aplicáveis Classificação de pacotes A classificação de pacotes é a 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 DSCP 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.)

16 Condicionamento de tráfego O condicionamento de tráfego é realizado por um conjunto de funções de controlo, 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 Permite garantir que são respeitados acordos entre domínios Permite que o tráfego receba serviço diferenciado, através da marcação do codepoint apropriado e monitorizaçã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

17 Per-Hop Behaviors Um PHB constitui o meio de um nó atribuir recursos a um BA Pacotes de um mesmo BA, marcados com o mesmo DSCP, recebem tratamento idêntico em cada nó (PHB) e por isso devem evidenciar o mesmo comportamento do ponto de vista das garantias de QoS associadas Um ou mais BAs / DSCPs 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 O volume total de tráfego admitido num domínio DiffServ e que é mapeado num dado PHB pode ser limitado por policiamento na periferia Per-Hop Behavior Group 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 (PHB Group) 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 Além do serviço básico best effort (a que corresponde um PHB), foram definidos dois outros PHBs Assured Forwarding (AF) Expedited Forwarding (EF)

18 Assured Forwarding PHB Group O RFC 2597 define um grupo de PHBs designado Assured Forwarding PHB Group e que é constituído por quatro classes e três níveis de precedência para descarte em cada classe (doze valores de DSCP), o que permite oferecer doze níveis diferentes de garantia de entrega de pacotes (AF ij sendo i a classe e j o nível de precedência na classe respectiva) 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 (ouro, prata e bronze), 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 esperado (PHB) Os pacotes IP são associados (pelo cliente ou pelo fornecedor) a uma ou mais classes AF, de acordo com os serviços contratados Em cada classe os pacotes são marcados (pelo cliente ou pelo fornecedor) com um nível de precedência de descarte que determina o seu grau de importância relativa na classe 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ó DiffServ 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)

19 AF PHB atribuição de recursos e desempenho A cada uma das classes AF é atribuída em cada nó do domínio DiffServ 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ó (tendo em atenção a quantidade de recursos reservados para cada classe), de acordo com a importância relativa de cada classe Uma classe pode usar mais recursos que o mínimo que lhe foi reservado 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 isto pode ser conseguido usando níveis de precedência de descarte (marcando alguns pacotes com maior prioridade de descarte, de modo a proteger pacotes considerados de maior importância) Em cada nó o nível de garantia de despacho de um pacote IP depende dos recursos atribuídos à classe a que o pacote pertence, do tráfego actual na classe e do nível de precedência de descarte (no caso de congestionamento na classe) Expedited Forwarding PHB O PHB Expedited Forwarding (EF PHB) tem como objectivo a construção de serviços (normalmente designados Premium) caracterizados por requerem pequena taxa de perda de pacotes, baixa latência e jitter reduzido, bem como um débito garantido (habitualmente especificado através dum peak bit rate) Serviços típicos são videoconferência, voz sobre IP (VoIP) ou emulação de um circuito dedicado Consideram-se normalmente dois tipos de SLAs SLA estático (de longa duração) leased line service SLA dinâmico (de curta duração) guaranteed connection 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) Pacotes marcados para o EF PHB podem ser remarcados na entrada de um domínio DS com outros codepoints mapeáveis no 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

20 EF PHB especificação Duma forma intuitiva pode afirmar-se que o tráfego EF deve encontrar filas de espera vazias ou pequenas ao atravessar um nó DiffServ A redução do atraso em filas de espera permite reduzir o atraso total 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 O crescimento 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 A especificação inicial do EF PHB (RFC 2598) revelou inconsistências e limitações, referidas e resolvidas na especificação que a substituiu (RFC 3246) e que são analisadas com detalhe no RFC 3247 A definição intuitiva de EF é simples (RFC 3246) o débito com que o tráfego EF é servido numa interface de saída (service rate) deve ser pelo menos igual a um débito configurado R, num intervalo de tempo apropriadamente definido, independente da carga oferecida na interface por tráfego não EF É necessário definir com rigor as condições que permitem assegurar esse objectivo Os aspectos formais da descrição do EF PHB são remetidos para o Anexo EF PHB controlo de tráfego EF Na entrada de um domínio DiffServ 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 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, usando um token bucket com débito de geração de tokens r < R e profundidade b 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

21 Gestão de recursos Bandwidth Broker A gestão de recursos (num domínio e entre domínios DiffServ), configuração de nós, realização de controlo de admissão e negociação de SLAs entre domínios pode ser baseada em entidades designadas 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 providenciar os níveis de QoS negociados Bandwidth Broker

22 Limitações do modelo básico DiffServ As especificações que suportam o modelo DiffServ não definem o modo como se realiza a provisão de recursos e a configuração de mecanismos de QoS Em muitos casos as redes DiffServ são configuradas estaticamente A provisão de recursos é feita com base em padrões de tráfego de longo prazo, sendo os valores expectáveis derivados de SLAs subscritos Os nós são configurados manualmente, o que significa que reconfigurações frequentes não são viáveis Pode ser necessário sobredimensionar recursos (overprovisoning) se não forem usados mecanismos de Engenharia de Tráfego O modelo DiffServ não especifica a forma como entidades externas podem reservar recursos dinamicamente ou receber indicações da disponibilidade de recursos Não há procedimentos normalizados para reserva dinâmica de recursos e controlo de admissão nem para reconfiguração dinâmica de recursos e de parâmetros de mecanismos de QoS nos nós MPLS e DiffServ Isoladamente, MPLS e DiffServ não providenciam garantias fortes de QoS DiffServ permite tratar de forma diferenciada o tráfego em cada nó (do ponto de vista do seu despacho), mas não pode oferecer garantias de QoS se os recursos necessários não estiverem disponíveis DiffServ não controla as rotas seguidas pelos pacotes e, no caso de ocorrer congestionamento, pode não garantir a largura de banda requerida por cada PHB MPLS pode oferecer largura de banda garantida a LSPs estabelecidos com recurso a técnicas de Engenharia de Tráfego (condição necessária para QoS), mas não permite gerir a atribuição de recursos a classes de tráfego MPLS não inclui policiamento e controlo de admissão nem mecanismos para dar tratamento diferenciado a fluxos (e.g, escalonameno e descarte de pacotes) Os aspectos funcionais do suporte de DiffServ em redes MPLS são descritos no RFC 3270, enquanto a oferta de garantias de QoS com base na combinação de DiffServ com mecanismos de Engenharia de Tráfego do MPLS está descrita no RFC 3574

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

24 EF PHB RFC 3246 De acordo com a formulação usada no RFC 3246, para garantir que os pacotes EF encontram filas pequenas é necessário que o débito de serviço (service rate) 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 O PHB é definido de um modo que garante que os pacotes recebem serviço com um débito (service rate) superior ou igual a um valor configurado R e fornece um meio de quantificar a precisão com que o débito de serviço é oferecido em qualquer intervalo de tempo (assim 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) 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 Estes aspectos são também abordados em: Jon Bennett et al., Delay Jitter Bounds and Packet Scale Rate Guarantee for Expedited Forwarding, IEEE/ACM Transactions on Networking, Vol. 10, No. 4, August 2002, pp A definição formal adoptada no RFC 3246 tem em conta estes aspectos, pois permite estabelecer limites para o desvio entre o instante real e o instante ideal de partida de cada pacote (assumindo que os pacotes EF deviam ser idealmente servidos com um débito igual ou superior a um débito configurado R) 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

25 EF PHB definição formal O RFC 3246 dá uma definição formal do EF PHB, considerando dois casos Ambos os casos se aplicam a pacotes EF recebidos em qualquer interface de entrada e destinados a uma dada interface de saída I No primeiro caso, 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 (a definição aplica-se ao agregado EF) Um índice j refere, respectivamente, o número de ordem de chegada ao nó dos pacotes destinados à interface I (qualquer que seja a interface de entrada) e 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 segundo caso 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 (mesmo que a ordem de saída não seja a mesma que a ordem de entrada) EF PHB parâmetros (modelo formal) No primeiro caso (packet unaware) são usados os seguintes parâmetros 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 relacionado com o tratamento dado a um agregado EF no nó e representa um limite superior de (d j -f j ), isto é, do desvio entre os instantes real e ideal de partida do mesmo pacote (pacote j na saída) No segundo caso (packet aware), o significado dos parâmetros é idêntico, com a ressalva de que a identidade dos pacotes é preservada A j, D j, F j e L j (que substituem a j, d j, f j e l j ) referem-se ao mesmo pacote (pacote com ordem de chegada j) E a é substituído por E p, que é um termo de erro relacionado com o tratamento dado a pacotes EF individuais no nó e representa um limite superior de (D j -F j )

26 EF PHB equações (modelo formal) Um nó que suporta EF numa interface configurada com um débito R deve satisfazer as equações seguintes, que caracterizam um serviço dito Packet Scale Rate Guarantee com débito R e latência E a d j < f j + E a, qualquer que seja j > 0 (eq_1) f j é definido recursivamente f 0 = 0, d 0 = 0 f j = max (a j, min (d j-1, f j-1 )) + l j / R, qualquer que seja j > 0 Para além disso, deve satisfazer D j < F j + E p, qualquer que seja j > 0 F j é definido recursivamente F 0 = 0, D 0 = 0 F j = max (A j, min (D j-1, F j-1 )) + L j / R, qualquer que seja j > 0 (eq_2) (eq_3) (eq_4) Os valores para j = 0 são usados apenas por razões de recursividade (a origem do tempo deve ser escolhida de modo que não haja pacotes no sistema nesse instante) EF PHB figuras de mérito Deve ser possível caracterizar um nó EF pela gama de valores de R que pode suportar (em conformidade com as equações) e pelos valores de E a e E p que é possível satisfazer (em cada interface) E a e E p podem ser considerados 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 um valor elevado pode 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 da precisão do débito de serviço oferecido a um agregado EF e E p é uma medida do desvio em relação a um servidor ideal (que serviria pacotes numa ordem FIFO, com um débito igual ou superior a R) 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

27 EF PHB atraso e jitter Se for 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 (r, b), sendo r < R 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 a componente fixa de E p for conhecida 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 não EF e C é a capacidade da ligação física) E = MTU / C + MTU / R, no caso de um escalonador WF 2 Q Suporte de DiffServ em redes MPLS O suporte de DiffServ em redes MPLS está definido no RFC 3270 São usados dois conceitos (definidos no RFC 3260) Ordered Aggregate (OA) conjunto de Behavior Aggregates (BA) que partilham uma restrição relativa à ordenação de pacotes (aplicável em particular a BAs AF) O conjunto de um ou mais PHBs aplicados ao(s) BA(s) que pertencem a um dado OA constitui uma PHB Scheduling Class PHB Scheduling Class (PSC) um PHB Group com uma restrição comum, que impõe que seja preservada a ordem de pacotes do mesmo micro-fluxo Exemplos: AF1x é um PSC que inclui os PHBs AF11, AF12 e AF13; EF é um PSC que inclui um único PHB (EF) Um BA é mapeado num PHB, que inclui escalonamento e descarte, enquanto que um OA é mapeado num PSC, que apenas se refere a escalonamento O RFC 3270 define duas maneiras de mapear valores de DSCP no cabeçalho MPLS (etiqueta e campo EXP) um LSR toma decisões de despacho (forwarding) com base apenas no cabeçalho MPLS, pelo que o PHB tem de ser inferido a partir do conteúdo do cabeçalho E-LSP (EXP-Inferred-PSC LSP) L-LSP (Label-Only-Inferred-PSC LSP)

28 EXP-Inferred-PSC LSP (E-LSP) O valor de DSCP (6 bits) é mapeado no campo EXP (3 bits) do cabeçalho MPLS, que é usado para determinar o PHB a aplicar ao pacote (inclui PSC e precedência de descarte) O PSC de um pacote transportado no LSP depende do campo EXP Um único LSP pode suportar até 8 BAs de um dado FEC (qualquer que seja o número de OAs a que esses BAs pertencem) O mapeamento entre EXP e PHB (PSC e precedência de descarte) para um dado LSP é sinalizado no estabelecimento do LSP ou pré-configurado Um E-LSP requer menos LSPs (etiquetas) que um L-LSP, mas a largura de banda reservada para o LSP é partilhada por todos os OAs (sem granularidade a nível de PSC) Label-Only-Inferred-PSC LSP (L-LSP) O valor de DSCP é mapeado no cabeçalho MPLS de modo que O PSC a aplicar a um pacote etiquetado pode ser inferido exclusivamente a partir do valor da etiqueta (independentemente do valor do campo EXP) A precedência de descarte a aplicar a um pacote etiquetado é transportada no campo EXP Um LSP é estabelecido para um único par (FEC, OA) O PSC é sinalizado explicitamente durante o estabelecimento da etiqueta Um L-LSP requer mais LSPs (etiquetas) que um E-LSP, mas a largura de banda reservada para o LSP é apenas partilhada pelos BAs de um único OA (isto permite granularidade a nível de PSC, uma vez que a informação de escalonamento é transportada na etiqueta)