QoS sobre Redes TCP/IP Edgard Jamhour

Conceitos de QoS QoS pode ser definido como qualquer mecanismos capaz de prover um serviço melhor para um dado fluxo. Um fluxo pode ser determinado de várias formas: Combinação dos endereços de origem e destino Numero dos sockets de origem e destino Identificador de sessão Pacotes enviados ou recebidos de uma certa aplicação em uma certa interface URL ou tipo MIME dentro de um pacote HTTP

Objetivos do QoS Controle sobre recursos Exemplo: limitar a banda utilizada por aplicações de FTP em um determinado link. Uso mais eficiente de recursos de rede Privilegiar o uso das aplicações mais importantes (rentáveis) na rede. Serviços Customizáveis QoS permite diferenciar usuários e serviços oferecidos na rede. Coexistência de aplicações de missão críticas Permitir que as aplicações menos importantes não degradem as aplicações críticas na rede (exemplo, FTP introduzir atraso para aplicações de VOIP). Base para construção de uma rede única e integrada Permitir que uma única tecnologia de rede possa ser utilizada para prover todos os tipos de serviços (redes convergentes).

Qualidade de Serviço - QoS A qualidade de Serviço pode ser definida como sendo garantias oferecidas pela rede que certos parâmetros serão mantidos entre níveis pré-acordados. Os principais parâmetros de QoS são: Atraso Jitter: Variação no Atraso Taxa de transmissão Taxa de Perda de Pacotes QoS na Camada de APlicação QoS na Camada de Transporte QoS na Camada de Rede Internet QoS em Enlace QoS refere-se a capacidade de criar um caminho com banda e tempo de atraso garantidos entre dois pontos da rede.

QoS pode ser implementada em vários níveis: Na camada de Enlace: Redes Síncronas: SDH (combinação de canais de banda constante) Redes Assíncronas: ATM: Permite Reservar Recursos Frame-Relay: Apenas Limita a Banda Na camada de rede: IP: Permite implementar a qualidade de serviço fim a fim independente da tecnologia de enlace.

Atraso O Atraso é o principal fator de QoS. Em aplicações tempo-real o atraso provoca perda de QoS. Por exemplo, surgem dois problemas para o tráfego de voz quando o atraso é alto: Eco e Sobreposição de conversação. Os principais fatores que influenciam na latência de uma rede são os seguintes: Atraso de propagação (Propagation Delay); Velocidade de transmissão e Processamento nos equipamentos

Fatores que Influenciam o Atraso Congestionamento nos links Capacidade do Terminal Congestionamento na rede local Tempo de propagação Bufferização nos Roteadores

Trecho (Round Trip Delay) Tempo de Propagação   Atrasos de Propagação - Fibras Ópticas – Exemplos Trecho (Round Trip Delay) Atraso de Propagação Miami a São Paulo 100 mseg New York a Los Angeles 50 mseg Los Angeles a Hong Kong 170 mseg

Fontes de Atraso Atraso introduzido por equipamentos: Roteadores (comutação de pacotes) LAN Switches (comutação de quadros) Servidores de Acesso Remoto (RAS) (comutação de pacotes, ...) Firewalls (processamento no nível de pacotes ou no nível de aplicação, ...) Considerando que a latência é um parâmetro fim-a-fim: Capacidade de processamento do processador Disponibilidade de memória Mecanismos de cache Processamento nas camadas de nível superior da rede (Programa de aplicação, camadas acima da camada IP, ...);

Medida do Atraso Existem 3 maneiras de se medir o atraso: One-Way Tempo para o pacote ir da origem ao destino Paired One-Way Tempo para informação ir de A para B Tempo para informação ir de B para A Necessita de mecanismos de medição nas duas extremidades. Round-Trip (Round Trip Time – RTT) Tempo para informação ir de A para B e voltar para A O Atraso é medido dividindo-se o tempo de round-trip por 2. A medição pode ser feita a partir de uma única extremidade.

Perda de Pacotes Pacotes são perdidos devido a dois fatores: Erros no pacote: Cabeçalho do pacote: Descartados pelos roteadores Campo de dados: Descartados pelo computador Falta de Banda Estouro de buffer dos roteadores . Priorização de tráfego Pacotes menos prioritários são descartados.

Curva de QoS em Função do Atraso

Classificação das Aplicações A QoS solicitada ao provedor de serviços depende dos requisitos específicos das aplicações. Aplicações tempo-real Aplicações sensíveis ao atraso Tolerantes a perda de pacotes Intolerantes a perda de pacotes Aplicações elásticas Aplicações que não são afetadas pelo atraso.

Requisitos de QoS Requisitos de QoS Voz FTP E-mail Vídeo Broadcast   Requisitos de QoS Voz FTP E-mail Vídeo Broadcast Vídeo Interativo Exigência de largura de banda Baixa a Média Baixa Alta Sensibilidade ao descarte aleatório de pacotes Média Sensibilidade ao atraso Sensibilidade ao jitter

Arquitetura para QoS As arquiteturas de QoS envolvem 3 elementos: Técnicas para implementar QoS em um nó da rede. Técnicas de sinalização de QoS, para informar aos vários nós da rede como proceder na passagem de um fluxo. Funções para gerenciamento, política e contabilização do QoS de uma rede como um todo.

Estratégias para Implantação de QoS Duas estratégias possíveis: Priorização (serviços diferenciados): O tráfego da rede é classificado e os recursos da rede são distribuídos de acordo com critérios da política de gerenciamento de banda. Reserva de Recursos (serviços integrados): recursos da rede são reservados de acordo com a requisição de QoS da aplicação e sujeitos a uma política de gerenciamento de banda. Exemplo: RSVP

Níveis de Serviço QoS Três níveis básicos de QoS podem ser providos através de redes heterogêneas: 1) Melhor Esforço (Best-effort Service): É a implementação default da Internet (sem QoS). 2) Serviço Diferenciado (soft QoS): Algum tráfego é tratado melhor que o resto. Exemplos: PQ, CQ, WFQ, e WRED (definidos na seqüência). 3) Serviço Garantido (hard QoS) Reserva absoluta de recursos de rede para tráfego específico. Exemplos: RSVP e CBWFQ

Níveis de QoS Reserva de Recursos Prioridade GARANTIDO DIFERENCIADO Sem QoS MELHOR ESFORÇO

Técnicas de QoS Diferenciado Controle de Congestionamento Estabelece mecanismo para diferenciar o tráfego em caso de congestionamento da rede. Permite tratar o tráfego de tempo real de maneira diferente do tráfego elástico. Antecipação de Congestionamento Introduz técnicas que tomam ações preventivas para evitar o congestionamento. Adequação do Perfil de Tráfego Forçam um perfil de tráfego específico na saída, de maneira independente do fluxo de tráfego na entrada.

Controle de Congestionamento Os roteadores devem suportar mecanismos de filas com priorização para permitir a implementação de mecanismos de QoS. As principais técnicas de priorização são: First-in, first-out (FIFO) queuing Priority queuing (PQ) Custom queuing (CQ) Weighted fair queuing (WFQ)

FILA INTERNA NO ROTEADOR FIFO – First In Firt Out Trata as variações de tráfego através de uma fila, mas não utiliza nenhum tipo de prioridade. É a opção default dos dispositivos de rede. LINK B (rede WAN: 1 Mbps) LINK A (rede local: 100 Mbps) LINK A > LINK B FILA INTERNA NO ROTEADOR

PQ: Prioritizing Traffic Utiliza várias filas FIFO de prioridades diferentes: high, medium, normal ou low O tráfego é classificado e colocado em filas diferentes, dependendo da sua prioridade. Os critérios de classificação podem ser diversos: Tipo de protocolo Interface de entrada Tamanho do pacote Endereço de origem e/ou destino A estratégia consiste em transmitir primeiro o tráfego das filas de maior prioridade.

PQ: Prioritizing Traffic

CQ: Guaranteeing Bandwidth Esta técnica utiliza até 16 filas em escalonamento round robin. O tamanho das filas é proporcional a prioridade do tráfego. A classificação para entrada nas filas é feita por protocolo ou interface de entrada. 2/10 3/10 4/10 Fila de baixa prioridade (1 pacotes de cada vez) 1/10 Fila de alta prioridade 4 pacotes de cada vez (a medição pode também ser feita em bytes).

CQ: Guaranteeing Bandwidth

Weighted fair queuing (WFQ) Efetua classificação do tráfego por fluxo: Endereço IP de origem e destino Portas de origem e destino Prioridade e Tipo de protocolo Os fluxos são armazenados num número configurável de filas. Fluxos de baixo volume, que são a grande maioria do tráfego, recebem um serviço preferencial. Fluxos de alto volume, dividem o restante da banda de maneira proporcional entre eles.

Weighted fair queuing (WFQ)

Weighted fair queuing (WFQ) Dando prioridade para os fluxos mais curtos, o WFQ reduz significativamente o atraso médio de entrega dos pacotes.

Prioridades no IP O protocolo IPv4 possui um campo denominado tipo de serviço, com informações que podem ser utilizadas para definir a prioridade dos pacotes.   CABEÇALHO PACOTE IP TOS Bit Prioridade 000 Muito Baixa 001 Baixa .. Maximizar confiabilidade 111 Muito Alta Bit Requisição 1 Minimizar retardo 2 Maximizar vazão 3 Maximizar confiabilidade 4 Minimizar custo

1 byte, 3 bits de prioridade Precedência de IP A ponderação das filas leva em conta as informações do campo “Tipo de Serviço” do protocolo IP (3 bits): Prioridades de 0 (menos prioritário) a 7 (mais prioritário). É feito uma média ponderada para determinar a quantidade de banda que cada fluxo recebe. Por exemplo, se estão chegando 3 fluxos de prioridade 2 e 4 fluxos de prioridade 1, cada fluxo recebe: 3*2 + 4*1 = 10: banda total disponível 2/10, 2/10, 1/10, 1/10, 1/10, 1/10: banda alocada por fluxo Cabeçalho IP TOS 1 byte, 3 bits de prioridade

CBWFQ – Class Based WFQ Class Based WFQ é uma variante do WFQ. O problema que este método quer resolver, é permitir que vários fluxos do tipo tempo real que tenha prioridade idêntica tenham que dividir banda entre si. Por exemplo, no método WFQ pode alocar uma certa banda para um fluxo de vídeo. Todavia, quando vários fluxos de vídeo atravessarem o nó, a banda será dividida. No método CBWFQ cria-se uma classe para representar todos os fluxos de vídeo. Todos os demais fluxos podem ser agrupados em uma ou mais classes menos especializadas gerenciados por WFQ.

Técnicas para Evitar Congestionamento As técnicas para evitar congestionamento antecipam a tendência de congestionamento na rede e agem antes que o congestionamento ocorra. RED: RED: Randon Early Detection Os roteadores iniciam um processo de descarte randômico de pacotes assim que percebem um congestionamento nas suas interfaces. WRED: RED ponderado A operação de descarte acontece levando em conta as informações de prioridade do campo TOS dos pacotes IP.

RED

Ferramentas de Monitoramento de Controle de Tráfego GTS Generic Traffic Shaping Baseado no Token Bucket Approach Reduz o tráfego de saída de uma interface para um taxa constante

Ferramentas de Monitoramento de Controle de Tráfego FRTS Frame Relay Traffic Shaping As informações fornecidas pelo Frame Relay são usadas para controlar as funcionalidades de QoS implementadas pelo roteador. CIR: Committed Information Rate (CIR) FECN, BECN DE O flag DE indica quais pacotes devem ser descartados em caso de congestionamento. Taxa definida pelo CIR Circuito virtual Indicações do BECN faz com que os pacotes aguardem na fila.

Reserva de Recursos Ao contrário das técnicas de priorização, permite reservar banda para as aplicações. Frame-Relay Trabalha apenas com priorização ATM Trabalha com priorização e reserva de recursos IP Trabalha apenas com o melhor esforço Novos protocolos foram criados para o IP para permitir a reserva de recursos. Entre eles, o mais importante: RSVP Resource Reservation Protocol

RSVP RSVP: Resource Reservation Protocol Protocolo de controle de rede que permite as aplicações solicitarem Qos (Qualidade de Serviço) especiais para seus fluxos de dados.

RSVP O RSVP foi concebido no “Information Sciences Institute (ISI)” da “University of Southern California (USC)”, MIT e no “Xerox Palo Alto Research Center”. Atualmente ele está publicado na RFC2205. O IETF define que o uso do RSVP é para implementar redes com serviços integrados. RSVP não é um protocolo de transporte de dados, mas sim um protocolo de controle, como ICMP ou IGMP. Sua função é permitir que os nós da rede recebem informações que permitam caracterizar fluxos de dados, definir caminhos e características de QoS para esses fluxos ao longo desses caminhos. RSVP não é um protocolo de roteamento. Ele depende de outros protocolos para execução dessas funções.

Arquitetura do RSVP As funções de implementação do QoS pelos nós não são de responsabilidade do RSVP. Outros módulos são especificados na arquitetura: Módulos de Decisão: Controle de Admissão: verifica se existem recursos para o pedido. Controle de Política: verifica se o usuário pode pedir os recursos. Módulos de Controle de Tráfego: Classificador: determina a classe do pacote Escalonador: implementa o QoS

Arquitetura do RSVP Host Controle de Admissão Roteador Controle de Processo RSVP Processo RSVP aplicação Processo de Roteamento Controle de Políticas Controle de Políticas dados dados Classificador Escalonador Classificador Escalonador Dados

2. Especifica os requisitos RSVP é Unidirecional As reservas em RSVP são sempre unidirecionais. As reservas podem ser em unicast ou multicast. Para uma mesma aplicação transmitir e receber dados com QoS são necessárias duas reservas: Uma para receber dados (feita pela própria aplicação). Uma para enviar dados (feito pelo receptor). No RSVP o pedido de uma reserva sempre é iniciado pelo receptor. 1. Solicita serviço 2. Especifica os requisitos Servidor Cliente REDE 3. Faz reserva

Sessões RSVP Em RSVP, a política de QoS não é aplicada individualmente sobre cada pacote, mas sim em sessões. Uma sessão é um fluxo de dados enviado a um mesmo destino e com o mesmo protocolo de transporte: Uma sessão é definida por três parâmetros: Endereço de destino Identificador de Protocolo (TCP ou UDP) Porta de destino (Opcional).

Sessões RSVP Podem ser de dois tipos: Endereço Classe D multicast Os receptores precisam formar um grupo multicast para poder receber as mensagens. IGMP Transmissor Receptor unicast Transmissor Receptor

Sessões Unicast e Multicast Sessão RSVP Fluxo de dados S1 Comunicação Unicast S2 R1 S3 S1 Comunicação Multicast R1 S2 R2 S3

O RSVP suporta três tipos de tráfego Best Effort IP tradicional. Exemplo: email Rate-sensitive: Garante uma taxa média de transferência. Exemplo transmissão de vídeo não interativo. Se em certos momentos a taxa de dados superar a taxa média reservada, o roteador pode bufferizar os dados. Delay-sensitive: Garante o atraso máximo dos dado, mesmo com taxa de transmissão variável. Exemplo transmissão de video interativo. O número de quadro pode variar, mas não pode haver perda de sincronia.

RSVP: Visão Geral RSVP é formado por um conjunto de mensagens trocadas entre os elementos de rede. As principais mensagens são: PATH e RESV

Tipos de Mensagem RSVP PATH: Enviada do Transmissor para o Receptor. Objetivo: Definir uma rota entre o transmissor e o receptor. Todos os roteadores que recebem a mensagem PATH armazenam um estado definido PATH state. 3 cliente servidor 1) PATH de S 2) PATH de 1 3) PATH de 2 S 1 2 C Estado: S Estado: 1 Estado: 2

Tipos de Mensagem RSVP Reservation Request: Enviada pelo receptor ao longo do PATH pré-estabelecido. Objetivo: solicitar a reserva de acordo com a especificação feita em PATH. 3 servidor cliente 3) RESV para C 2) RESV para C 1) RESV para C S 1 2 C Estado: S Estado: 1 Estado: 2

Tipos de Mensagem RSVP Reservation Request Acknowlegment: Enviada do transmissor até o receptor através do PATH. Cada nó RSVP decide se pode cumprir os requisitos de QoS antes de passar a mensagem adiante. Esta mensagem cria efetivamente a reserva nos roteadores e no servidor. servidor cliente 3) RACK de S 2) RACK de 1 1) RACK de 2 S 1 2 C Estado: S Estado: 1 Estado: 2

Tipos de Mensagem RSVP Mensagens de Erro: Podem ser de dois tipos: Erros de Caminho (Path error) Erros de Reserva (Reservation Request error). Os erros são gerados de acordo com os seguintes casos: Falha de admissão (o solicitante não tem permissão para fazer a reserva). Banda indisponível. Serviço não suportado. Má especificação de fluxo. Caminho ambíguo.

Tipos de Mensagem RSVP Mensagens Teardown: Enviada pelo cliente, servidor ou roteadores para abortar a reserva RSVP. Limpa todas as reservas e informações de PATH.

Descritor de Fluxo de Dados Especificação de Filtro (endereço e porta de origem do emissor) Especificação de Fluxo Especificação de Tráfego Tspec Especificação de Requisição Rspec

Especificação de fluxo Um reserva em RSVP é caracterizada por uma estrutura de dados denominada Flowspec. Flowspec é composta por dois elementos: Rspec (Reserve Spec): indica a classe de serviço desejada. Tspec (Traffic Spec): indica o que será Transmitido.

Serviço Garantido se r <= R O Token Bucket Model Rspec e Tspec são definidas na RFC 2210 e são opacos para o RSVP. Geralmente, esses parâmetros são definidos assumindo que o modelo utilizado para garantia de QoS é o Token Bucket Model. Este modelo é um método realiza para definir uma taxa de transmissão variável com atraso limitado. Fluxo de saída do enlace: R Buffer de Recepção: Serviço Garantido se r <= R

Tspec Assumindo o Token Bucket Model, Tspec é definido da seguinte forma: r - taxa média em bytes/s Taxa de longo prazo: 1 a 40 terabytes/s b - tamanho do bucket (em bytes) Taxa momentânea: 1 a 250 gigabytes p - taxa de pico m - tamanho mínimo da unidade policiada (pacotes menores que esse valor são contados como m bytes) M - MTU (máximo tamanho de pacote que pode ser enviado pelo flow) Regra: seja T o tráfego total pelo fluxo num período T: T < rT + b

Rspec Assumindo o Token Bucket Model, Rspec é definido da seguinte forma: R - taxa desejável Taxa média solicitada s - Saldo (slack) de retardo Valor excedente de atraso que pode ser utilizado pelos nós intermediários. Ele corresponde a diferença entre o atraso garantido se a banda R for reservada e o atraso realmente necessário, especificado pela aplicação.

Funcionamento 1. A aplicação servidora identifica sua necessidade de QoS através de uma mensagem PATH A mensagem PATH contém dois parâmetros básicos: Tspec: estrutura de dados que especifica o que será transmitido. Adspec (opcional): estrutura que especifica os recursos disponíveis. Cada roteador com o RSVP habilitado através da rota percorrida pela mensagem PATH estabelece um “path-state” que inclui o último endereço da mensagem PATH.

Mensagem PATH Opcionalmente, a mensagem PATH pode conter uma estrutura de dados ADSPEC informando aos nós subseqüentes os recursos disponíveis para implementar o QoS: Os parâmetros passados são os seguintes: hopCount: número de elementos intermediários pathBW: estimativa da largura de banda minLatency: estimativa do retardo de propagação composedMTU: MTU composta do referido caminho

Funcionamento 2. A aplicação cliente solicita à rede a garantia de QoS que lhe é conveniente (Reserva) através do protocolo RSVP; Os receptores enviam uma mensagem RESV (Reservation Request) de volta. Flow Spec Service Class Tspec: requisitos do transmissor Rspec: taxa de transmissão solicitada Filter Spec: identifica os pacotes que devem de beneficiar da reserva Protocolo de transporte e número de porta.

A Mensagem RESV Filterspec O receptor define um subset de pacotes da sessão (especificado pelo destino) que deverão receber os privilégios de QoS. No IPv4 o Filterspec é especificado pelo IP e porta de origem (do transmissor) e no IPv6 pelo Flow Label. Pacotes que não são enquadrados no Filterspec são tratados como “Best Effort”.

Funcionamento 3. A rede (Equipamentos roteadores e switch routers) aceita eventualmente a solicitação e "tenta garantir" a reserva solicitada. Quando um roteador recebe a mensagem RESV: autentica a requisição alocar os recursos necessários. Se a requisição não pode ser satisfeita (devido a falta de recursos ou falha na autorização), o roteador retorna um erro para o receptor. Se aceito, o roteador envia a mensagem RESV para o próximo roteador.

Funcionamento 4. Confirmação 5. Operação Quando o último roteador recebe a mensagem RESV e aceita sua solicitação, envia uma mensagem de confirmação de volta para o receptor (note que o último roteador é o mais perto do transmissor ou o ponto de agregação de reserva para fluxos multicast). 5. Operação Uma vez aceita a reserva, os fluxos de dados (streams) correspondentes à aplicação são identificados e roteados segundo a reserva feita para os mesmos.

Fluxo de mensagens PATH e RESV

Service Class Classes de Serviço: Serviço de Carga Controlada (RFC 2211) O mecanismo de QoS é feito pelos roteadores da rede através do controle de admissão (carga controlada) que limitam a carga da rede. Não é necessário especificar o parâmetro Rspec. A banda necessária é deduzida a partir de Tspec. Os aplicativos devem manter a transferência de dados através do fluxo numa taxa < rT +b. Serviço Garantido (RFC 2212) Utiliza Tspec e Rspec para definir uma reserva ao longo do caminho entre o transmissor e o receptor, de maneira a garantir o atraso solicitado.

Implementação do RSVP Quando cofirmam mensagens RSVP: Servidores: Reservam memória. Reservam CPU. Reserva banda de suas placas de rede. Roteadores: Configurar os recursos de controle de filas de acordo com os critérios do RSVP. Negociam com outros dispositivos de rede a reserva de QoS, caso esta seja implementada a nível de enlace (por exemplo, ATM).

Implementação do RSVP

RSVP na Internet Para que o RSVP possa ser implementado na Internet, utiliza-se técnicas de tunelamento para saltar os roteadores que não suportam RSVP. O endereço de destino das mensagens PATH é do próximo roteador que suporta RSVP. Nuvem não RSVP cliente servidor

Problemas do RSVP A classificação de pacotes feita pelos roteadores a fim de implementar o QoS necessita que este tenham acesso as informações de porta de origem e destino. Quando ocorre a fragmentação estas informações só estão contidas no primeiro fragmento de um pacote. Solução: As aplicações transmitem as informações com o mínimo MTU do caminho. IPsec ou outras técnicas de tunelamento podem criptografar os pacotes: Uma extensão do IPsec foi proposta para suportar RSVP.

Aglutinação de Reservas As reservas RSVP precisam ser aglutinadas a fim de não desperdiçar recursos quando a reserva está vinculada a uma transmissão em Multicast. aglutinação S R1 R2 RESERVA R S1 S2 RESERVA desaglutinação

Estilos de Reserva As reservas em RSVP podem ser feitas de formas diferentes (estilos): Seleção do Emissor Reserva Distinta Reserva Compartilhada Explícita Filtro Fixo (FF) Explícito Compartilhado (SE) Curinga Não Definido Filtro com Curinga (WF)

Exemplo de WildCard Filter WildCard-Filter (WF) Estabelece uma única reserva para todos os emissores de uma sessão (tipicamente multicast, onde só um transmite de cada vez). Só a maior requisição de reserva chega aos emissores. Sintaxe: WF (* {Q})

Exemplo de Fixed Filter Fixed-Filter (FF): Pacotes de emissores diferentes numa mesma sessão não compartilham reservas. Mas as reservas são compartilhadas pelos receptores. Sintaxe: FF (S{Q}) ou FF(S1{Q1},S2{Q2},...}

Exemplo de Shared Explicit Shared-Explicit (SE): A reserva é propagada para todas as fontes no valor máximo feito por cada receptor. Sintaxe: SE ((S1,S2,...){Q})

Objetos de tamanho variável Mensagens RSVP Msg Type: 8 bits 1 = Path 2 = Resv 3 = PathErr 4 = ResvErr 5 = PathTear 6 = ResvTear 7 = ResvConf ... Objetos de tamanho variável

Objetos RSVP NULL SESSION RSVP_HOP TIME_VALUES STYLE FLOWSPEC FILTER_SPEC SENDER_TEMPLATE SENDER_TSPEC ADSPEC ERROR_SPEC POLICY_DATA INTEGRITY SCOPE RESV_CONFIRM

Serviços Diferenciados O IETF está definindo uma série de RFC que regulamentam a implementação de redes IP de grande porte segundo a arquitetura de Serviços Diferenciados. Serviços Diferenciados são uma alternativa para Serviços Integrados, que supostamente são pouco escaláveis devido ao custo de manutenção das sessões RSVP. O conceito básico dos serviços diferenciados (Diff-Serv) é o SLA: Service Level Agreement

SLA O SLA é um acordo de QoS entre um cliente e um provedor de serviço (Domínio DS). O cliente pode ser um cliente final (e.g. uma empresa) ou outro domínio de DS. Os fundamentos do Diff-Serv são: Os pacotes IP precisam ser marcados nas fronteiras de entrada na rede administrada em DS. A marcação é feita utilizando os bits TOS do IPv4. Os roteadores utilizam esses bits para identificar como os pacotes são tratados na rede. Os pacotes são tratados pelos roteadores de acordo como o SLA associado a eles.

Marcação para DiffServ O IETF definiu uma reutilização do campo TOS do IPv4 a fim de suportar serviços diferenciados. O campo TOS (8bits) foi renomeado para byte DS. Este campo é formado da seguinte maneira: DSCP (Differentiated Services CodePoint) 6 bits (classe de tráfego para o pacote) CU: currently unused 2 bits (reservado)

Uso do DS O DS é utilizado como critério (ou um dos critérios) de classificação em um roteador com capacidade de policiamento e condicionamento tráfego de saída. Por exemplo, pode-se ter uma regra: Se DSCP=X, use token-bucket r, b token bucket meter with rate r and burst size b. Cada roteador de uma rede Diff-Serv deve ser capaz de intepretar o DS a uma regra de QoS específica. A configuração do roteador é denominada PHB (Per-Hop Behavior)

Arquitetura de um Nó Diff-Serv Traffic Shapping Medidor Formador/ Descartador DS DS Classificador Remarcador DS DS

Arquitetura de um Nó Diff-Serv Classificador: (2 tipos) Multicampos (MF): Utiliza o Byte DS e outros campos do cabeçalho IP (IP, Porta, etc.) Comportamento Agregado (BA): Utiliza apenas o Byte DS. Medidor: Responsável por medir o tráfego de entrada (r e b, por exemplo) e disparar trigger para os outros elementos do nó. Marcador: Responsável por marcar ou remarcar o byte DS dos pacotes. A marcação acontece para pacotes sem marcação emitidos pelo cliente. A remarcação pode acontecer também porque o nó subseqüente tem uma outra interpretação para o valor de DS. Formador/Descartador: Policia (por descarte) e adequa o tráfego de saída de acordo com o PHB atribuídos aos pacotes.

PHB – Per Hop Behavior O IETF tem um Working Group para serviços diferenciados: http://www.ietf.org/html.charters/diffserv-charter.html Entre outras especificações, o IETF define uma RFC para auxiliar na padronização do PHB: RFC 3140: Per Hop Behavior Identification Codes . PHP são definidos em grupos, formados por um ou mais PHB. Exemplos: O PHB padrão (best effort): DSCP: 00000. O PHB EF (Expedited Forwarding): DSCP: 101100

Domínios de Serviços Diferenciados A arquitetura Diff-Serv define que a Internet é formada por uma coleção de domínios de serviços diferenciados (suportamente contíguos). Um domínio é uma porção da rede Internet controlada por uma única entidade. Nó Interno I I Nó de Fronteira de DS B I B I B I I Domínio Domínio

Remarcação (Exemplo) Cada domínio pode ter sua própria interpretação para o valor do DS, por isso os roteadores de fronteira fazer remarcação. Roteador Fronteira Roteador Interno 7 Roteador Interno classificado remarcado 3 7 3

Marcação e Domínios de Origem Na arquitetura Diff-Serv, os serviços diferenciados podem ser transparente para os clientes. Normalmente, os hosts emissores (clientes) tem um contrato SLA (Service Level Agreement) com um provedor. Para associar os pacotes ao SLA, o byte DS precisa ser marcado. Se o cliente suportar Diff-Serv, ele mesmo marca os pacotes. Se o cliente não suporta Diff-Serv, os pacotes podem ser marcados pelo roteador do provedor (eventualmente, por uma regra que identifica os aplicativos por IP´s e portas). O provedor pode ter um contrato SLA com um outro domínio DIff-Serv (por exemplo, um backbone), e assim por diante.

Conclusão Serviços Integrados: Serviços Diferenciados: Garantia das características de QoS para os fluxos numa comunicação fim-a-fim. A rede nunca “admite” mais tráfego do que é capaz. Pouco escalável devido ao alto custo de manter o estado nos roteadores. Serviços Diferenciados: Policiamento e priorização de tráfego em domínios de serviço diferenciado. A rede pode eventualmente ficar sobre-carregada e não cumprir as características de QoS solicitadas. Escalável, pois não precisa manter rígidas condições de estado nos roteadores.