Adocao de Quality of Service em Ambientes de Operadores de Redes
Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede
Nota sobre direitos autorais, termo de uso e isenção de responsabilidade
Autor: Leonardo Furtado
Introdução
Este artigo discute conceitos muito interessantes sobre os mecanismos de Qualidade de Serviço (Quality of Service) ou QoS para infraestruturas de redes baseadas na tecnologia de enlace Ethernet e em combinação com redes IP e, se sobrar espaço/tempo aqui neste artigo, o MPLS também. Recomendo a completa e minuciosa leitura de todo o documento por parte dos profissionais engajados nos projetos de infraestrutura de redes, sejam projetos de ISPs ou projetos de ambientes corporativos.
Antes de começarmos: o QoS no Provedor de Acesso à Internet (ISP)
Indo bem direto ao ponto aqui.
O Marco Civil da Internet (Lei n° 12.965/2014), que é a lei que regula o uso da Internet no Brasil por meio da previsão de princípios, garantias, direitos e deveres para quem usa a rede, bem como da determinação de diretrizes para a atuação do Estado, etc., enfim, determina que não pode haver qualquer diferenciação ou qualquer distinção entre os pacotes para o produto de "Internet" do ISP. E isto significa que muito do que será discutido neste artigo não é exatamente aplicável para a rede do ISP, pelo menos não no que diz respeito ao serviço de Internet.
Para as redes corporativas, no entanto, e dentro de seus respectivos ambientes, neste quesito, manda a empresa (ainda (ironicamente aqui...)), portanto fique a vontade para seguir com as ideias e ferramentas.
Mas, para o ISP, essa restrição imposta pelo ... Marco Civil ... não se aplica aos serviços de telecomunicações gerais, ou seja, os chamados Serviços de Valor Agregado (SVA). Basta o ISP não implementar QoS para a Internet (mesmo que seja para melhorar uma transmissão IPTV, por exemplo, um absurdo...) que o provedor não estará violando o Marco Civil para este controle (abusivo do Estado, essa é a MINHA opinião). Vou parar por aqui, porque falar de MC e de Estado autoritário me irrita profundamente.
Por que o QoS é necessário?
Não atreva-se a configurar um mix complexo de tecnologias, só porque você acha que precisa, sem ao menos compreender com clareza para que serve o QoS e quais problemas são resolvidos com estas estratégias.
É fato que as infraestruturas de redes estão cada vez mais convergentes, no sentido de que estas redes atualmente transportam uma magnitude de aplicações e serviços orientados a aplicações de Dados, Voz e Vídeo, sendo que estas aplicações operam e são transportadas sobre uma mesma infraestrutura em comum e baseada no mesmo (e único) protocolo IP. Este cenário de convergência (Dados, Voz, e Vídeo, todos sobre o protocolo IP) diminui custos muito significativamente, simplifica as infraestruturas e a complexidade dos ambientes dissimilares, viabilizando, portanto, novas aplicações, facilidades e oportunidades.
No entanto, cada tipo de tráfego - Vídeo (VoD, IPTV, vídeo-conferência...), Voz (VoIP, telefonia IP, colaboração...), Dados (Internet recreativa, aplicações corporativas diversas, aplicações de missão crítica, network control, etc.) - possui requerimentos distintos em termos de transporte e sensibilidades particulares. Sem contar também com adventos tais como o Fibre Channel over Ethernet (FCoE), cujos pacotes exigem um fabric completamente capaz de assegurar zero descartes de pacotes - no caso do FCoE, resolvemos isto com tecnologias Ethernet mais avançadas, tais como Data Center Bridging (DCBX, PFC, ETC, VoQ, etc., ou tecnologias similares.).
Para exemplificar as exigências em termos de transporte para cada uma das aplicações, posso citar:
| Tipo de Tráfego | Características |
|---|---|
| Voz | Uma chamada telefônica por VoIP consome pouca banda, e esta banda é fixa, ou seja, definida pelo codec (codificador/decodificador) empregado. O overhead (a razão cabeçalho/payload) é tida como alta, pois boa parte do payload total corresponde aos cabeçalhos necessários para viabilizar o transporte. Além disto, voz sobre IP é um tipo de tráfego que exige transmissão absolutamente em tempo real, e, portanto requer prioridades que assegurem baixa latência (pouquíssimo tempo de espera nas filas), baixo jitter (a variação de atraso entre os pacotes tem que ser bem baixa) e quase zero índice de perda de pacotes (não há retransmissão de pacotes VoIP/IPT perdidos, pois é transportado por RTP/UDP). |
| Vídeo | Dependendo da plataforma, uma chamada de videoconferência pode consumir banda bastante razoável, comportando-se neste sentido e aparentando ser uma transmissão de dados, mas com as mesmas exigências de transporte de uma chamada de VoIP, ou seja, baixa latência, baixo jitter, índice de perda de pacotes muito baixo, além baixa proporção de pacotes fora de ordem/reordering, etc. |
| Dados | Uma transmissão de dados pode ser considerada como “normal”, “razoável”, ou “greedy” (egoísta, e que consume muita banda e esgota as filas). No entanto, a referida transmissão não é muito sensível à latência (o janelamento do protocolo TCP se encarrega dos efeitos adversos), tampouco a jitter, e descartes são resolvidos automaticamente pelo próprio protocolo TCP (por meios de retransmissões dos segmentos eventualmente perdidos durante os congestionamentos). |
| Dados de Aplicações de Missão Crítica | Há aqui o conceito de dados “críticos”, que são aquelas aplicações críticas para o negócio da empresa e que precisam da devida prioridade e garantias de recursos de rede tais como a banda. Por exemplo, CRM, ERP e similares. Mesmo que haja outras transmissões não importantes e/ou recreativas (Internet “convencional”, por exemplo), é necessário para que haja também esta distinção entre estes casos. |
| Dados de Controle | Figura nesta categoria o tráfego produzido por protocolos de roteamento, que normalmente consome pouca banda, especialmente quando utilizamos protocolos mais inteligentes e através de um projeto técnico bem equilibrado (ajustes nos temporizadores, refinamento do throtlling, sumarização de prefixos, etc.). Todavia, os pacotes gerados pelos protocolos de roteamento em operação nos equipamentos da rede precisam ser processados pontualmente para garantir a estabilidade da infraestrutura e possibilitar a correta convergência desta em casos de falhas de equipamentos e/ou enlaces físicos. |
O QoS é necessário porque as tecnologias de camada de enlace (L2) e de camada de rede (L3) adotadas nos operadores de redes e ambientes corporativos atualmente – a saber, primariamente Ethernet e IP, respectivamente – possuem transmissão de natureza estatística e, por conta disto, a possibilidade de ocorrerem descartes devido à insuficiência de recursos em alguns momentos é elevada e até mesmo tida como normal, desde que em níveis sustentáveis. Em adição, em um ambiente de transmissão estatística - sem o emprego das ferramentas corretas - não há realmente como priorizar as aplicações mais sensíveis ao jitter, latência e descarte de pacotes. E este artigo buscará promover este entendimento.
Quais problemas são resolvidos com o QoS?
Antecipando aqui: QoS não é "um" recurso ou um procedimento apenas, mas sim uma coletânea de procedimentos e ferramentas. Isto será discutido posteriormente. As tecnologias que fomentam o QoS existem para resolver os seguintes problemas existentes em ambientes de redes de transmissão estatística. E não somente as ferramentas relacionadas ao QoS em si, mas a própria abordagem de projeto de infraestrutura ajudará muito no fornecimento da qualidade requerida pelas aplicações e serviços na rede..
Redução dos impactos da contenção e insuficiência de recursos de banda
Isto é notório em cenários onde há um excesso de banda ("oversubscription”) que precisa ser transportada através de uma ou mais partes da rede. Para exemplificar isto melhor, existe um conceito chamado “Fan-In Fan-Out”, onde o tráfego entrante registrado nas interfaces LAN, somados, por exemplo, é bem maior do que a capacidade nominal de saída das interfaces WAN (ex: 1 Gbps na LAN e 50 Mbps na WAN), como ocorre com o roteador CPE de clientes em muitos casos. Outro exemplo aqui seria dentro da própria LAN de clientes corporativos e isto é bastante comum: imagine cinco (05) switches de Acesso com 48 portas 1 Gbps usando dois (02) uplinks de 10 Gbps, sendo que o protocolo Spanning-Tree normalmente bloqueará uma destas duas portas uplinks para uma ou todas as VLANs do switch, dependendo do projeto, enfim... seriam 240 Gbps entrando na Distribuição e apenas 10 Gbps possíveis na saída para o Core, considerando que há dois (02) uplinks 10 Gbps mas que apenas um deles pode ser usado efetivamente. No entanto, geralmente nas LANs isto não é problema, pois na maior parte do tempo as estações/computadores não estão transmitindo, então este oversubscription dificilmente ofereceria problemas com relação à disponibilidade de banda para transmissão numa LAN. Em certos tipos de mercados (imagens, editoração eletrônica pesada, etc.), o oversubscription pode ser problema.
E, no que diz respeito à WAN, isto é frequentemente um problema, dependendo do dimensionamento do link de WAN ou do link de Internet, pois o volume de tráfego saindo da LAN através da WAN tende a apresentar picos que, em alguns momentos do dia, acarretam em insuficiência de recursos de transmissão (banda) pela interface WAN do roteador CPE. E isto leva frequentemente a congestionamentos e demais efeitos adversos associados tais como o global synchronization do protocolo TCP, decorrente de entupimento de filas e vários descartes, lentidões, etc.
Toda a vez que a banda real/efetiva de entrada for (bem) maior que a banda de saída, serão percebidos muitos problemas de contenção. Por estes motivos as capacidades dos enlaces e dos próprios equipamentos precisam ser bem dimensionadas para que evitemos estes gargalos e congestionamentos. Porém, o aumento da capacidade dos circuitos não elimina a necessidade de implementação de QoS, até mesmo porque muitas vezes os custos são proibitivos e estes tipos de upgrades não são viáveis em curto ou médio prazo.
A ilustração a seguir mostra um cenário de "oversubscription" deste "Fan-In Fan-Out", exemplificando como isto seria em um switch na sua rede.
Como você pode notar, a prática do dimensionamento do oversubscription é comum e perfeitamente natural em projetos de infraestrutura, pois sabemos que na maior parte do tempo integral e absoluto as estações de trabalho não estarão transmitindo, o que permite o dimensionamento estratégico dos uplinks para acomodar a vazão do tráfego "real" em horários ou situações de pico. Considerando a ilustração acima, você colocaria um uplink de 100 Gbps num switch de Acesso em uma rede corporativa? Claro que não, que loucura! Se você monitorasse essas portas de acesso (que conectam para os usuários) você descobriria que eles estão longe, mas muito longe mesmo, de consumir aquela banda de 1 Gbps cada uma destas estações. Mas, talvez, ou fatalmente em alguns casos, um uplink de 1 Gbps neste mesmo cenário/exemplo não fosse dar conta de transportar o tráfego real/efetivo de todas as estações em determinados horários do dia. Compreende?
Agora consideremos outra topologia aqui, a de uma rede corporativa como um todo. Como deveríamos dimensionar os enlaces antes de experimentarmos problemas de congestionamentos e ainda sem considerar aqui o emprego de quaisquer ferramentas específicas para Quality of Service (QoS):
Conforme citado anteriormente, numa LAN problemas de congestionamentos são bem raros, especialmente em segmentos tradicionais. Talvez em ambientes onde há o processamento de imagens de altíssima resolução ou fábricas de software e ambientes de pesquisas com alta demanda de canal de rede e processamento.
Isto significa, considerando a ilustração acima, que a rede LAN do ambiente demonstrado fluiria excepcionalmente bem na questão de disponibilidade e suficiência de banda para os usuários. Mas nem tudo é perfeito, e isto foi destacado propositalmente nesta topologia.
Com o advento da centralização de recursos computacionais em um data center, e os serviços nas nuvens privadas, públicas ou híbridas, há uma demanda natural por escoamento do tráfego originado no Acesso até o local onde encontram-se estes recursos, ou seja, a "nuvem", o "data center" e a "Internet". Isto promove um fluxo de tráfego bastante "Norte-Sul" nestes tipos de ambientes, e as camadas da rede - em especial a Distribuição/Agregação e Core - normalmente são dimensionadas para acomodar a agregação estatística deste tráfego. No ambiente LAN exemplificado pela topologia acima, vemos que quase tudo está OK neste sentido, exceto pelos links de Internet e de um dos links que transporta os usuários até o data center, os quais poderiam estar subdimensionados.
O problema da contenção é bem mais notório em três situações discutidas a seguir:
- Capacidade do link de Internet em uma empresa do segmento corporativo: o circuito contratado é insuficiente para acomodar a carga de tráfego e demanda de usuários, quantidade de acessos simultâneos, etc.
- Capacidade do link de WAN que conecta matriz, filiais, etc.: a capacidade dos circuitos de uma ou mais localidades está aquém da demanda real dos usuários, especialmente porque os recursos corporativos gerais (aplicações) estão centralizados na matriz ou em um data center.
- Capacidade nominal das interfaces uplinks de switches e roteadores dos provedores de acesso de Internet (ISP): a previsibilidade e dimensionamento da razão estatística das transmissões é muito mais complicada em ambientes de operadores de redes ou ISPs. A rede vai coletando e transportando os pacotes dos assinantes até os pontos de interesse da infraestrutura do provedor, tais como CDNs, peering e trânsito, e planejar a capacidade de uma rede metropolitana é algo sempre mais complexo do que numa LAN corporativa.
Estas são as três situações que mais se qualificam a problemas envolvendo a contenção e insuficiência de recursos de banda.
OBS: eu poderia ter ido diretamente ao ponto e informado estes três "bullets" acima, certo? Mas preferi fazer isto de forma mais ampla e didática, pois nem todos os usuários/visitantes da Wiki do BPF são profissionais experientes.
Redução da atraso (latência) fim-a-fim
Há diversos tipos de atrasos nas transmissões que fatoram para a latência fim a fim presente entre dois dispositivos que desejam se comunicar (um cliente e um servidor na Internet ou no data center, por exemplo). Entendamos estes tipos de atrasos.
- Atraso de Processamento: um índice de atraso ou delay variável que é alimentado pelas tecnologias de processamento de pacotes dos equipamentos presentes na rede. Há diferenças bem significativas entre arquiteturas de comutação baseadas em software (softrouters) e arquiteturas baseadas em silício especializado, seja de mercado ("merchant") ou customizado ("custom"). É um atraso variável porque tudo dependerá da demanda por processamento de tráfego naquele equipamento (sessões, acessos, taxa efetiva de pacotes por segundo, etc). E, como a rede opera por modelo de transmissão estatística, isto significa que, dependendo da arquitetura do equipamento, maior demanda por tráfego e sessões acarretará em aumento de processamento e, consequentemente, o aumento deste tipo de atraso sobre as transmissões. E isto tende a oscilar ao longo do dia.
- Atraso de Enfileiramento: um tipo de atraso de natureza também variável. Quando pacotes precisam ser transmitidos através de uma interface do equipamento, uma verificação é feita acerca da disponibilidade de recursos para a sua transmissão. Caso não haja recursos suficientes, o pacote é posicionado em uma fila aguardando a sua vez para ser transmitido. Como o controle de filas é igualmente estatístico, isto é, em dadas ocasiões poderá haver 05 pacotes numa fila e, em outros, 30 pacotes na mesma fila, haverá esta flutuação que provocará diferenças neste atraso. Para constar, um único pacote numa fila já significa que o meio físico correspondente encontra-se congestionado!
- Atraso de Serialização: um atraso de natureza fixa, medido em microsegundos, relacionado à codificação dos dados em bits para transmissão no meio físico associado à interface de saída para aquele pacote.
- Atraso de Propagação: um delay fixo, mas que varia de meio físico para meio físico. Por exemplo, 2 Mbps por transmissão sem fio propaga mais rapidamente do que os mesmos 2 Mbps sobre uma fibra óptica (sim!). Uma fibra óptica possui características de propagação melhores que um cabo elétrico, etc. Outro exemplo tem relação com a distância: um enlace 1 Gbps propaga mais rapidamente sobre uma fibra ótica a 10 km de distância do que sobre uma fibra a 70 km de distância, isto é, considerando as mesmas condições de qualidade da fibra e tudo mais. Acho que não preciso aqui exemplificar o caso de uma comunicação satelital... ou precisa?
Atenuação do jitter
Como os atrasos (delays) incluem o fixo (serialização e propagação) e o variável (processamento e enfileiramento), e são computados a cada salto, ou seja, a soma de todos os atrasos ao longo do caminho entre "A" e "B", especialmente no caso dos atrasos variáveis aqui, isto fará com que sempre ocorram diferenças nos tempos de atraso entre as transmissões de pacotes de um determinado fluxo ou sessão, resultando em variações no tempo de chegada até o destino entre pacotes deste mesmo fluxo. Isso é o que chamamos de jitter. O jitter é particularmente nocivo contra tipos de tráfego sensíveis a este fenômeno, tais como voz e vídeo, pois pode esgotar ou transbordar os buffers de jitter dos equipamentos e terminais telefônicos com suporte ao protocolo IP, e operar fora das especificações biológicas (auditivas e/ou visuais) do ser humano, quem está interagindo através da aplicação afetada pelo jitter.
Redução do descarte de pacotes
É considerado “mortal” para tipos de tráfego tais como voz e vídeo, pois aplicações interativas como VoIP e videoconferência são tipicamente transportadas pelo protocolo UDP, o qual não possui mecanismos para retransmitir segmentos perdidos. E nem deve! Já pensou, retransmissão de pacotes de conversações em tempo real? Você conseguiria entender a conversa? Transmissões de dados podem gerar também uma lentidão grande em transmissões de dados críticos perdidos devido ao “recuo em massa” da janelas das transmissões TCP afetadas.
Atenuação dos efeitos decorrentes da fragmentação de pacotes e e recebimento de pacotes fora de ordem
Caso roteadores estejam fragmentando pacotes em uma rede, uma prática abominável nos dias atuais, e em adição aos projetos naturalmente assimétricos de caminhos de rede, isto poderá provocar o aumento de processamento dos equipamentos de classes mais "low end", além da latência fim a fim e jitter.
O QoS é necessário também numa rede Wi-Fi (WLAN)?
Claro! E vou além: redes Wireless LAN (WLAN) também precisam de QoS, pois o meio “físico” da rede Wireless é completamente compartilhado, portanto sofisticados mecanismos de contenção e coordenação de transmissões são exigidos. Para citar aqui, todas as transmissões são half-duplex numa WLAN. O mecanismo de contenção do acesso ao meio físico nas redes WiFi é o CSMA/CA (Congestion Avoidance) para o chamado "airtime fairness”, e emprega uma infinidade de procedimentos e tecnologias, incluindo Distributed Coordination Function (DCF), Point Coordination Function (PCF), Short Inteframe Space (SIFS), Extended Interframe Space (EIFS), Distributed Interframe Space (DIFS), Reduced Interframe Space (RIFS), Clear Channel Assessment (CCA), Contention Window (aCWmin e aCWmax), Network Allocation Vector (NAV), etc. No caso das WLANs, implementamos os componentes de QoS conforme os padrões IEEE 802.11e / WMM e demais padrões mais recentes, onde mapeamos as transmissões da rede cabeada (as suas marcações) para marcações específicas na parte WLAN que possuem “melhor tempo sobre o ar” (ou tempo mais curto de contenção). As classes de tráfego da WLAN são mapeadas para as classes de tráfego da LAN cabeada, e vice-versa, durante a integração entre estas duas redes.
O QoS em ambiente WLAN está fora do escopo deste artigo. Talvez fique para outra oportunidade.
Se você queria apenas saber "para que serve o QoS?", você poderá encerrar a sua leitura por aqui mesmo! Está bem explicado acima. No entanto, querendo saber mais sobre o tema, continue a leitura do artigo!
Conheça os tipos de QoS
O QoS no geral pode ser categorizado em três tipos, apresentados na tabela a seguir:
| "Tipo" de QoS | Características |
|---|---|
| Best Effort | A primeira "pegadinha" aqui: o termo "best", que já vi enganar algumas pessoas (best = melhor). O best effort é nada mais, nada menos, que "melhor esforço" ou "faça o que puder". Ou seja, não há quaisquer prioridades, e os todos os pacotes são tratados por igual e utilizando-se mecanismos de contenção do tipo “First In First Out” (FIFO). |
| Integrated Services (IntServ) | Nesta modalidade, as próprias aplicações nos hosts e servidores sinalizam os requerimentos de prioridades na rede, e os roteadores se encarregam de garantir estes requerimentos sinalizados pela aplicação. Apesar de muito interessante no ponto de vista funcional, não é escalável, pois os equipamentos de rede precisam manter o estado de sessão de todos os fluxos de tráfego (termo “microflow management”)), o que é completamente inviável para a maioria das redes atuais. |
| Differentiated Services | As prioridades aqui são realizadas para agrupamentos de pacotes em classes de tráfego, e não para aplicações individuais, e também não são utilizados protocolos ou sinalizações. Ou seja, agrupamos as transmissões em classes de tráfego e definimos ações sobre cada uma destas classes de tráfego. A escalabilidade é ilimitada (sem protocolos, sem sinalização, e sem microflow management). O “problema” é que a configuração de QoS tem que ser feita em todos os elementos de rede do chamado domínio DiffServ, que possui comportamento Per-Hop Behavior (PHB; ou QoS em todos os saltos/hops). |
O Differentiated Services e o domínio DiffServ
Desprezaremos por completo o IntServ, e pelas razões apresentadas na tabela acima, assim como desprezaremos o Best Effort, porque, como sabemos, é regime de melhor esforço (ou seja, sem QoS). A estratégia de QoS que escala em qualquer ambiente de redes e de qualquer porte é o DiffServ, e é nele que o artigo focará.
Entenda de uma vez por todas:
O Quality of Service (QoS) tem que ser fim a fim (end-to-end). Todo elemento ativo no meio do caminho de uma transmissão tem que possuir configurações de ferramentas específicas para fins de implementação da qualidade de serviço ou, do contrário, você particionará ou "quebrará" o seu QoS e, nestas partes da rede, as transmissões ocorrerão por regime de melhor esforço (ou seja, Best Effort).
Você precisa realmente compreender o que representa o chamado Domínio DiffServ!
Em uma rede, todo o elemento de rede ativo precisa processar e transportar os pacotes referentes aos diversos fluxos de tráfego, correto? Como a rede deve gerenciar as prioridades neste caso? Como priorizar voz (que é sensível à latência, jittter e perda de pacotes) sobre as transmissões de dados comuns? Como devemos fazer para que os elementos de rede saibam administrar eventuais gargalos na infraestrutura?
O "x" da questão aqui é que o modelo DiffServ não emprega quaisquer protocolos ou sinalizações, e isto significa que cada pacote recebido por um switch ou um por roteador será encaminhado no regime de melhor esforço se você não implementar as configurações de QoS necessárias naquele equipamento. E é isto que chamamos de domínio DiffServ.
O DiffServ essencialmente implementa dois macro conceitos em uma rede:
- Condicionadores de Tráfego (Traffic Conditioning): categorias de ações são executadas sobre os pacotes para os objetivos desejados para a resolução dos problemas discutidos anteriormente, sobre as redes de transmissão estatística.
- Comportamento Salto-a-Salto (Per-Hop Behavior): estas ações devem ser executadas em cada elemento de rede ativo presente no meio do caminho. Daí o termo PHB.
Ambas as situações andam lado a lado, e as ações de cada caso são organizadas por conjuntos de ferramentas específicas, as quais serão discutidas logo a seguir.
Conjunto de Ferramentas empregadas para QoS
O QoS não é uma tecnologia só, tampouco pode ser resolvido com um único recurso ou comando no seu equipamento. O QoS pode ser melhor definido como um conjunto de estratégias e ferramentas dissimilares onde cada qual desempenha a sua função no intuito de minimizarmos os problemas (já discutidos) dos meios de transmissão estatística.
As ferramentas do QoS podem ser categorizadas conforme demonstrado a seguir, no que chamamos de “QoS Toolkit” ou qualquer que seja o nome que você queira usar aqui. Em primeiro momento, resumirei as categorias de ferramentas aqui, para, depois, dissertar sobre cada uma delas.
| Categoria | Descrição | Exemplos de Recursos Usados |
|---|---|---|
| Classificação | Para executar qualquer ação que se deseja sobre um pacote, o equipamento precisa primeiro saber que tipo de transmissão constitui este pacote, certo?
A proposta aqui da classificação é justamente esta: "ler" ou consultar uma característica do pacote (ex: cabeçalhos), identificar o que se trata, antes que qualquer ação possa ser tomada com relação ao pacote. É aqui que agrupamos os diversos tipos de pacotes em suas respectivas classes de tráfego. A classificação é executada obrigatoriamente por todos os equipamentos (PHB). |
Access Control Lists (ACL) ou similar para L3 (endereços IP) e L4 (portas TCP e UDP)
Input interface Endereços MAC e EtherType MPLS EXP bits 802.1Q/p para o CoS Cabeçalho IP (IP Precedence ou DSCP) Inspeção de aplicação (L7) QPPB (pelo BGP) |
| Marcação | Em muitos projetos as ações de classificação de pacotes são complexas e exigem o emprego de funcionalidades que fazem a inspeção
muito aprofundada ou por mecanismos complexos (ACL, L7, etc.), os quais, inclusive, podem não estar disponíveis em alguns ou na maioria dos equipamentos da rede. Além de poder aumentar o processamento de algumas classes de dispositivos. Por que você precisa sofrer? Saiba que a boa prática é manter a classificação complexa apenas o mais próximo possível da origem da transmissão, daí você deverá marcar ("colorir") o pacote, dando um significado de classe de tráfego para ele, para justamente padronizar e facilitar/simplificar o trabalho ou a ação de classificação dos demais equipamentos na rede ao longo do sentido desta transmissão. A marcação é exigida principalmente o mais próximo possível da origem do pacote, ou onde uma remarcação for exigida (ex: L2 para L3 ou vice-versa, IP para MPLS...). |
Cabeçalho Ethernet: 802.1Q/p
Cabeçalho IP: ToS byte (IP Precedence ou DSCP) MPLS Shim Header: MPLS EXP bits Internamente em alguns routers: QoS Group o similar QoS Preclassify (para túneis GRE, L2TP, IPsec) |
| Gerenciamento de Congestionamentos | A proposta principal desta categoria de ferramentas é fornecer os meios necessários para a distinção das prioridades das transmissões. Após
a classificação (com ou sem posterior (re)marcação), os pacotes são posicionados em filas de tráfego onde um regime de expedição com prioridades é definido para estas filas. É aqui que informamos que "Voz" possuirá maior prioridade, assim como "Vídeo", por exemplo, sobre os pacotes de dados comuns. |
FIFO
CBWFQ LLQ / Strict Priority Queueing MDRR/P2PMDRR |
| Controle de Congestionamentos | Entenda que filas não são infinitas e nem "saco sem fundo". Elas possuem limites ("depth") de profundidade e acomodam uma quantidade
definida de pacotes. Embora configuráveis, há prós e contras ao fazer isto, pois uma fila maior acarreta em aumento da latência fim-a-fim. Os mecanismos de controle de congestionamentos são usados para evitarmos que uma fila fique entupida, o que, consequentemente, provocará em descartes em série de pacotes na fila, culminando na sensação de "rede lenta" para o usuário final. |
Tail Drop
WRED ECN WTD |
| Policiamento | As ferramentas de policiamento podem ser usadas para limitarmos o uso de determinadas aplicações, o que é mais frequente em ambientes
corporativos, ou para policiar a taxa de transmissão para os índices contratados por um assinante residencial ou corporativo, o que é o caso dos ISPs. |
Rate Limiting
CAR CBP |
| Moldagem | Em alguns casos não desejamos descartar pacotes de um fluxo de uma determinada aplicação, mas apenas retardá-los até que haja recursos suficientes para transmissão. Isto é o que chamamos de traffic shaping, e deve ser usado com cautela para não acarretar em aumento de atraso fim a fim e jitter.
Pouco usado na rede do ISP, mas pode ser configurado na interface WAN do equipamento CPE. |
GTS
DTS CBS |
| Mecanismos de Eficiência de Links | Cada vez mais em desuso devido ao crescimento da capacidade dos circuitos WAN e de Internet. Mas enquadram-se aqui ferramentas que
promovem a compressão de cabeçalhos, fragmentação e intercalamento, compressão de voz, e outros casos. |
cRTP
Compressão de cabeçalhos FRF.12 LFI |
Não quero soar burocrático aqui, mas você provavelmente poderá estar se perguntando neste momento: "preciso mesmo saber todas estas categorias de ferramentas?". Para o seu desgosto, a resposta é sim!
Bom, pelo menos você não precisa conhecer o funcionamento e a configuração de todas as ferramentas e possibilidades. Apenas precisa compreender as categorias e os principais recursos de cada, especialmente aqueles que você for projetar e configurar em sua rede.
Enfim, continuemos aqui...
Classificação
Consideramos aqui somente a arquitetura DiffServ, pois o IntServ não possui boa escalabilidade e foi literalmente descontinuado em função disto. Sabemos que o QoS precisa ser feito obrigatoriamente em todos os saltos, no trajeto de A para B, e vice-versa. Ao invés de executarmos políticas de QoS por aplicação, fazemos um agrupamento de tipos de transmissão em suas respectivas classes de tráfego. Em outras palavras, você não terá 50 ou mais classes de tráfego (caso tenha 50 ou mais aplicações), isto serial surreal! Ao invés disto, você mapeará aplicações com requisitos comuns de transmissão, desempenho e disponibilidade para uma mesma classe de tráfego. E fazendo isto para as demais aplicações, mas mantendo uma pequena quantidade de classes de tráfego apenas.
A classificação é uma ação que precisa ser realizada em todos os equipamentos da rede, pois, como executar uma ação sobre um determinado pacote sem sabermos primeiro do que se trata este pacote? Há diversas formas de classificação de pacotes para o posterior agrupamento destes nas chamadas “Classes de Tráfego”, e as opções variam de acordo com o tipo de equipamento e a plataforma utilizada. Alguns exemplos de ferramentas usadas para estes procedimentos de classificação de pacotes:
- Access Control Lists (ACL) ou similar: classificar pacotes com base em instruções de cabeçalhos L3 e/ou L4. Em algumas plataformas VACLs (VLAN) podem ser usadas para incidência sobre endereços MAC (L2).
- Input interface: ou seja, com base na interface de "entrada", ou por onde o pacote foi recebido pelo roteador ou equipamento.
- Cabeçalho de Camada 2 (L2):
- BECN/FECN para Frame Relay (obviamente uma situação legada aqui...)
- 802.1Q/p para o CoS nos quadros tagged do Ethernet)
- Ou ainda nos endereços MAC de origem e destino
- MPLS Traffic Class (aka "EXP Bits"): para o MPLS shim header.
- Cabeçalho IP (L3): mais precisamente no byte ToS (IP Precedence ou DSCP) ou ainda nos endereços IP de origem e destino.
- QoS Group: ou recurso similar em alguns roteadores.
- Protocolos de Transporte (UDP/TCP): as portas de origem e destino para os protocolos de Camada 4
- Camada 7 (L7): algumas plataformas permitem a inspeção detalhada de todo o payload e com visibilidade completa da aplicação (L7) para, por exemplo, diferenciar uma aplicação/serviço de outra aplicação operando sobre um mesmo protocolo (ex: HTTP).
- QoS Policy Propagation via BGP (QPPB): o envio e propagação de policy e classificação pelo BGP.
Uma vez classificados os pacotes, saberemos exatamente a que tipo de transmissão cada um pertence ou se destina e com isto posicionaremos os pacotes classificados em suas classes de tráfego correspondentes, mas não antes sem nos certificarmos de que cada pacote já classificado pode ser facilmente (re)classificado pelos demais equipamentos da rede. Ou seja, o próximo passo seria procedermos com a marcação e/ou remarcação, caso isto fosse exigido.
Marcação
A classificação de pacotes em alguns casos só pode ser corretamente realizada através de um certo ou muito esforço de processamento por parte do roteador, o qual não gostaríamos de ter em todos os equipamentos da rede, principalmente no Core. Pensando nisto, devemos então simplificar e padronizar as marcações dos pacotes para facilitar ainda mais a posterior classificação destes pacotes nos demais elementos de rede ao longo do caminho.
Como um pacote pode ser marcado ou "colorido"?
- Cabeçalho Ethernet: 802.1Q/p (Class of Service ou CoS)
- Cabeçalho IP: ToS byte (IP Precedence ou DSCP)
- MPLS Shim Header: MPLS Traffic Class (EXP bits)
- Internamente em alguns routers: (não através dos enlaces na rede): QoS Group.
- Em VPNs ou Túneis tipo GRE ou L2TP, há também ferramentas tais como QoS Preclassify, além de recursos tais como CAR, CBP, e QPPB, com estes ou outros nomes, conforme suportado por cada equipamento e fabricante.
Exemplos de como estas marcações são executadas sobre os pacotes:
Gerenciamento de Congestionamentos
Filas de tráfego são necessárias para organizar o tráfego de entrada e saída (filas input (onde suportadas) e filas output), ou seja, pacotes chegando (entrando) por uma interface e pacotes saindo por uma interface. Os tipos de filas suportadas dependem da plataforma ou do equipamento em questão (router ou switch). Por padrão, todas as filas de um equipamento são FIFO (first in, first out), o que é péssimo em termos de assegurar prioridades, e, ainda por cima, pode promover o “starvation” de tráfego importante nas filas.
Realmente fica complicado elencar todas as tecnologias e procedimentos suportados, e por tantos os tipos de equipamentos disponíveis no mercado. Posso no entanto "generalizar" aqui e tentar fornecer o máximo de exemplos possíveis com os nomes e tecnologias de plataformas que eu domino. Fique a vontade para pesquisar na documentação do seu equipamento sobre o que é suportado ou não.
É importante salientar que alguns tipos de estratégias de filas aqui são do gênero "legadas" e que mecanismos mais recentes encontram-se disponíveis.
Em roteadores, o que é comum:
- First In First Out (FIFO): não há QoS ou prioridades aqui. O primeiro pacote que for recebido na fila será o primeiro pacote a ser transmitido. É o típico regime "best effort".
- Custom Queueing (CQ): modalidade legada de regime de filas que permite a configuração manual de uma determinada quantidade de filas (ex: até 16) com extração por bytes por fila numa fração alternada sequencialmente (round robin).
- Priority Queueing (PQ): modalidade legada de regime de 4 filas com prioridades pré-definidas (Alta, Média, Normal e Baixa prioridade). Possui o defeito de "matar" de fome as filas de menor prioridade em alguns casos.
- Fair Queueing (FQ): modalidade legada de regime de uma quantidade bem razoável de filas dinâmicas com o foco na prioridade e expedição de pacotes com menor payload e tempo de expedição (start time e finish time computados, etc.)
- Weighted Fair Queueing (WFQ): modalidade legada que herda os princípios da FQ, mas que acomoda um "peso" (fator de importância) que é condicionado às marcações presentes nos pacotes. Geralmente usada em classes de tráfego "default" no lugar do regime FIFO tradicional. É como se fosse "um QoS onde normalmente não haveria QoS" (para atender o tráfego padrão ou para "todo o resto").
- Class-Based Weighted Fair Queueing (CBWFQ): modalidade vigente que mescla os benefícios da CQ com os da WFQ. Alguns fabricantes tratam isto pelo nome de CBWFQ (Cisco, Juniper...).
- Strict Priority Queueing: modalidade vigente que incorpora os benefícios da PQ, enquanto eliminando seus defeitos, e mesclando isto em um regime CBWFQ em algumas plataformas. Ou seja, uma ou duas filas de baixa latência (alta prioridade) customizadas pelo administrador e operando em regime de maior prioridade, porém sem sacrificar o funcionamento das demais filas. Neste tipo de fila é que mapeamos Voz (P1) e Vídeo (P2) numa policy de QoS.
- Low Latency Queueing (LLQ): para os entendidos, é basicamente como a Cisco nomeia o SPQ em suas soluções.
- Modified Deficit Round Robin (MDRR/P2PMDRR): mecanismo vigente que implementa variáveis tais como valor quântico e contador de déficit para servir as transmissões com respeito às suas importâncias, condicionadas aos valores de marcação dos pacotes. Muito usado em arquiteturas high end.
Isto apenas para citar algumas destas estratégias de enfileiramentos. Há ainda algumas plataformas mais avançadas que fazem uso de arquiteturas do tipo Virtual Output Queues (VoQ), como é o caso de switches de missão data center e até mesmo roteadores de borda carrier-grade, onde, neste caso, há um gerenciamento diferenciado dos buffers de filas de saída nas interfaces egress, antes do pacote ser arbitrado no switch fabric pela interface de entrada (ingress).
Já em switches, os regimes de filas na maioria os casos são mais simplificados e até mesmo engessados no que diz respeito a customizações e afins. Mas não menos eficientes na maioria do casos. Normalmente são empregados um ou mais dos seguintes:
- 04 (quatro) ou 08 (oito) filas de QoS por porta física
- Weighted Round Robin (WRR)
- Shaped Round Robin (SRR)
- Modified Deficit Round Robin (MDRR)
Honestamente, as capacidades e mecanismos suportados variam muito de equipamento para equipamento. Por exemplo, em roteadores mais simples (low end), uma única fila de QoS em hardware é suportada, portanto um regime CBWFQ + LLQ seria essencialmente mantido por software para fornecer a dinâmica de prioridades desejadas para as transmissões (ou seja, qual pacote terá acesso à fila "física"?). Em switches, o interessante é que há garantidas 4 ou 8 filas de tráfego baseadas em hardware - mantidas no pipeline de processamento lá no silício (ASIC) - e todo este trabalho pode ser executado sem envolvimento de software. Em roteadores mais "high end", principalmente os roteadores carrier-grade, dependendo dos módulos de portas (line cards) instalados, milhares de filas de QoS totalmente baseadas em hardware. Enfim, tudo depende da arquitetura do equipamento em questão.
Controle de Congestionamentos
Uma coisa é gerenciar quais pacotes terão a sua vez de transmissão, algo que é de responsabilidade das filas. Outra é controlar o entupimento ou o preenchimento destas filas. Eis aí a diferença entre gerenciamento de congestionamentos e controle de congestionamentos.
Sim, uma fila pode “entupir”. Quando isto ocorre, os novos pacotes que chegarem à interface de entrada (ingress ou input interface) e, após determinadas a adjacência e interface de saída, encontrarem a fila associada à interface de saída (egress ou output interface) completamente cheia, serão sumariamente descartados. O mecanismo padrão de descarte de pacotes nas próprias filas é o que chamamos de Tail Drop. Isto é péssimo para determinadas transmissões, pois seriamos incapazes aqui de proteger aplicações mais críticas quando estas estiverem compartilhando a mesma fila com outras aplicações não tão importantes assim. Consequentemente, os usuários da rede experimentam e percebem problemas associados a lentidões.
No entanto, é possível mudar este comportamento através da seleção e configuração de um mecanismo de prevenção de congestionamento de filas para que os descartes de pacotes nestas filas obedeçam uma lógica de descartes seletivos baseada na importância destes pacotes (low, medium, high), evitando-se ao máximo possível o entupimento da fila. Estes mecanismos seriam:
- Tail Drop: não há diferenciação aqui, pois não há um controle efetivo de entupimento da fila. Se uma fila de saída ficar completamente cheia, o próximo (novo) pacote que chegar e precisar ser posicionado nesta fila será sumariamente descartado.
- Weighted Random Early Detection (WRED): é um destes mecanismos mais sofisticados, e que pode inclusive receber auxílio de outro mecanismo, o Explicit Congestion Notification (ECN). A proposta aqui é executar um descarte seletivo de pacotes antes que a fila de saída fique comprometida, ou seja, antes de ficar entupida. Os protocolos de camadas superiores (ex: TCP e algumas aplicações no topo deste) reagem relativamente bem ao descarte "aqui e acolá" ou "every now and then" de pacotes de seus fluxos, e o impacto disto é relativamente baixo. O que é completamente diferente de um descarte "full" na interface, o que reduz substancialmente as janelas de transmissão em função do "recuo" do protocolo TCP. O que o WRED propõe-se a fazer é monitorar o preenchimento da fila com valores mínimo, médio e máximo, e ter thresholds definidos para cada importância de pacote (condicionado ao valor de marcação), e fazendo isto com dois objetivos:
- Permitir que haja sempre (ou no melhor esforço possível) um "espaço" na fila para o recebimento de pacotes mais importantes ou críticos para a empresa.
- Evitar o descarte completo na fila (evitando-se o tail drop). Matar um pacote de vez em quando, antes que a fila comece a ficar cheia de verdade, é bem melhor do que ter a porta batendo na cara de vários pacotes ao mesmo tempo.
- O Explicit Congestion Notification (ECN) é um mecanismo adicional que pode ser usado em combinação com o WRED para "educar" a pilha de protocolos do hosts da rede, sinalizando-os para "maneirar" nas transmissões, ou, do contrário, eles terão pacotes descartados.
- Weighted Tail Drop (WTD): uma implementação de WRED mais frequentemente utilizada por switches.
Policiamento
Para manter o tráfego (uma classe ou um tipo específico de transmissão) operando sob uma taxa controlada/contratada, e com níveis de policiamento para taxa “no perfil”, “fora do perfil”, e “completamente fora do perfil”. Talvez seja a ferramenta de QoS mais conhecida entre os provedores de acesso à Internet (ISP) de pequeno e médio portes.
Dentre as possibilidades disto, o tráfego em conformidade terá transmissão assegurada, o tráfego excedente poderá ser descartado ou remarcado (prioridade mais baixa) e transmitido sem garantias, enquanto o tráfego de violação poderá ser sumariamente descartado. Exemplos de ferramentas para o policiamento de tráfego:
- Rate Limiting: um policiamento de taxa que, em alguns fabricantes, leva o nome de committed access rate (CAR).
- Class-Based Policing: uma versão bem mais sofisticada de policiamento, já que é embarcado e compatibilizado em regimes CBWFQ, além de suportar policiamento de uma ou duas taxas e em uma ou duas cores de policiamento.
- Per-session QoS Policing: o policiamento de taxa executado por assinante em um concentrador BNG (PPPoE/IPoE), cada qual em um plano específico compartilhando a mesma taxa ou taxas completamente distintas.
Como regra geral, os clientes de um ISP deverão ter seus circuitos físicos ou lógicos sempre policiados para garantir que estes estejam utilizando no máximo o que lhes foi contratado. O policiamento de tráfego deverá ser feito o mais próximo possível da origem das transmissões. Em uma arquitetura de rede de Acesso, a porta do equipamento switch ou roteador que receber o circuito físico do cliente deverá ser configurada para fazer esta limitação de taxa. Caso a porta física de entrada atenda múltiplos clientes e o dispositivo CPE não seja gerenciado pelo ISP, a configuração poderá ser feita em nível lógico (ex: VLAN do cliente no dispositivo de Acesso do ISP). A inobservância desta prática e a insistência em ativar o policiamento de tráfego a partir do ou somente no dispositivo PE, ao invés do dispositivo de Acesso, poderá desperdiçar muita banda uplink: o tráfego de todos os clientes desta rede de Acesso subiria e disputaria recursos de rede tais como banda e buffers, para ter o tráfego excedente descartado posteriormente lá adiante, pelo roteador PE. O que não seria uma medida muito inteligente. Procure fazer o policiamento da taxa contratada sempre o mais próximo possível do assinante.
Moldagem
Com esta técnica, as transmissões excedentes são mantidas em buffer e transmitidas posteriormente, isto é, quando houver a suficiência de "tokens". O objetivo é moldar o tráfego para que este consuma a banda máxima desejada, porém evitando-se na medida do possível a ocorrência de descartes e o recuo das transmissões (no caso do TCP). Esta estratégia poderá ser utilizada para moldar todo o tráfego de cliente diretamente a partir da porta de saída do dispositivo CPE, desde que este equipamento seja gerenciado pelo ISP. O shaping promoverá benefícios de conformidade de uso de Internet tanto na perspectiva do cliente quanto na do provedor. Não recomenda-se obviamente a moldagem de tráfego sensível a latência! E note que, ao contrário do policiamento da banda (que pode ser in e out), o shaping só é funcional e configurável no sentido out.
As ferramentas de shaping variam de nome conforme o fabricante e/ou equipamento, mas os nomes e esquemas mais comuns são:
- Generic Traffic Shaping (GTS)
- Distributed Traffic Shaping (DTS)
- Class-Based Shaping (CBS)
- Frame-Relay Traffic Shaping (FRTS)
- Etc.
Mecanismos de Eficiência de Links
Em grande parte é orientado para tecnologias de enlaces de WAN legadas, tais como Frame Relay, X.25, HDLC e PPP, pois são notoriamente de baixa capacidade e exigem cuidados mais rígidos para os problemas de contenção, latência e jitter. Principalmente para links de WAN lentos e em produtos contratados por clientes que incluírem comunicação entre dois ou mais sites (ex: L2VPN ou L3VPN). Exemplos aqui temos a Fragmentação e Intercalamento de Pacotes Fragmentados (FRF.12 e LFI), Multilink PPP (MLPPP), compressão de cabeçalhos TCP, compressão de RTP/UDP (cRTP), compressão de payload (Ex: Stac, Predictor, coisas velhas desse tipo), etc., muitas das quais não utilizaríamos nas arquiteturas vigentes (exceto, talvez, pelo cRTP).
Recomendações para projetos de QoS para o ISP
Uma boa estratégia para a adoção correta das tecnologias QoS para o ISP deve considerar as seguintes premissas. E é disto que trataremos a seguir neste artigo:
- Estruturação dos processos técnicos para a implementação das tecnologias que pavimentam o QoS.
- Desenho qualificado dos objetivos do QoS para o ISP, no melhor interesse de seus clientes, e conforme aplicabilidades e particulares de cada produto ou serviço fornecido a estes. Exceto a Internet (vide Marco Civil).
- Análise dos requerimentos de níveis de serviço para as aplicações referentes aos produtos de valor agregado (SVA) dos clientes.
- Projeto das políticas de QoS e em cumprimento aos requerimentos de transporte das aplicações dos clientes e dos níveis de serviços compreendidos.
- Implementação das políticas de QoS para o backbone e rede Metro Ethernet, e também para os dispositivos CPE de clientes.
- Monitoramento contínuo dos níveis de serviço para validação dos SLAs e para fins de planejamento de capacidades.
Requisitos padrão de indústria para tipos de tráfego
A primeira coisa que você precisa certificar-se é de que de fato compreende os requisitos de transporte das diversas aplicações sobre a sua infraestrutura. Sugiro que consulte toda e qualquer documentação confiável que encontrar e, no caso de aplicações "desenvolvidas em casa", converse com os (seus) desenvolvedores.
A tabela a seguir exemplifica os tipos de aplicações, seus requisitos gerais (bem simplificado aqui), e os padrões de marcação DSCP recomendados.
| Voz (Portadora) | Voz (Sinalização) | Videoconferência | Dados | |
| Marcação | EF | CS3 | AF41 | Best Effort (DF)
Bulk (AF11) Transactional (AF21) Scavenger (CS1) |
| Latência | <= 150 ms | - | <= 150 ms | Variável conforme a classe |
| Jitter | < 30 ms | - | < 30 ms | Variável conforme a classe |
| Perda de Pacotes | <= 1% | <= 1% | <= 1% | Variável conforme a classe |
| Prioridade | Banda de Priority por chamada | 150 b/s (+ Layer 2 overhead) por chamada | Garantia de banda minima por chamada com “gordura” de 20%
Por exemplo, uma chamada de 384 Kbps (varia conforme o codec) exigiria 460 Kbps de banda |
A prioridade é dada por “banda mínima garantida” para as classes importantes, e “best effort” para o tráfego restante.
O tráfego Scavenger possui zero prioridade e é geralmente policiado em ambientes corporativos. |
| Características dos Tipos de Tráfego | ||||
| - Tráfego “smooth”
- Tráfego benigno - Sensível a descartes - Sensível a latência - UDP Priority |
- Muito “lightweight”
- Consume muita pouca banda - Sensível a descartes - Sensível a latência |
- Tráfego “egoísta”
- Tráfego que consome boa a muita banda - Sensível a descartes - Sensível a latência - UDP Priority |
- Tráfego razoável ou "egoísta", dependendo da aplicação e frequência de transmisssão
- Geralmente bem intolerante quanto a latência, jitter e perda de pacotes - O protocolo TCP consegue lidar com a maioria das frustrações, desde que em níveis razoáveis | |
Tipos de aplicações de dados
Com o objetivo de compreensão das exigências de transporte para diversas das aplicações presentes na rede:
| Classe da Aplicação | Exemplos de Aplicações | Propriedades de Tráfego | Tamanho das Mensagens |
| Transacional | PeopleSoft (Vantive), Microsoft SQL Server | Tipicamente emprega um modelo client/server, onde o cliente inicia queries seguidas de respostas do servidor. As queries podem consistir de múltiplas mensagens entre o cliente e o servidor, e/ou múltiplas sessões TCP simultâneas | Depende da aplicação; poderá ser qualquer coisa entre 1 KB e 50 MB. |
| Bulk | Backup de rede, Microsoft Outlook | Amplas transferências de arquivos, sempre invocando o congestion management do TCP.
Repleto de protocolos lentos e tagarelas que rodam no topo do TCP (ex: CIFS e MAPI) |
Tamanho médio de 64 KB ou superior. |
| Best Effort | Todo o tráfego não crítico, tais como HTTP de Internet | Variável | Variável |
Tipos de aplicações de Control Plane (nos Roteadores)
Com o objetivo de compreensão das exigências de transporte para protocolos de roteamento.
Muitos roteadores possuem mecanismos internos visando assegurar a prioridade dos datagramas de controle importantes. O nome destes mecanismos varia de fabricante para fabricante, mas, em um fabricante conhecido, chamamos isto de PAK_PRIORITY. Este mecanismo não é configurável, mas é utilizado para a marcação automática do tráfego de protocolos de roteamento do tipo IGP (RIP, OSPF, EIGRP...) e BGP para o valor de marcação DSCP CS6. Em alguns ambientes pode ser recomendado uma fila de tráfego dedicada para lidar com a classe de tráfego Network Control, onde estão associados os pacotes produzidos pelos próprios protocolos de roteamento, além de não ser recomendado executar controles tipo o WRED para este tipo de tráfego.
Resumo de requisitos de QoS
Com o objetivo de reunirmos a compreensão acerca dos requisitos para QoS entre os diversos tipos de aplicações.
| Voz | Videoconferência | Bulk Data (FTP) | Missão Crítica | |
| Banda | Baixa a moderada | Moderada | Moderada a alta | Baixa a moderada |
| Sensibilidade a Descartes | Alta | Alta | Baixa | Moderada a alta |
| Sensibilidade a Latência | Alta | Alta | Baixa | Baixa a moderada |
| Sensibilidade a Jitter | Alta | Alta | Baixa | Baixa a moderada |
Referências de indústria quanto às Classes de Tráfego
Objetivo: compreender as classes de tráfego previstas para o domínio DiffServ, conforme recomendações-padrão de indústria. Os mais variados tipos de aplicações mostrados abaixo em conjunto com as suas respectivas classes de tráfego DiffServ, valores de marcação, e referências de indústria (IETF). Até mesmo porque você deverá padronizar toda a sua rede com relação aos padrões de marcação.
OBS: as figura e a tabela a seguir são meramente ilustrativas! Consulte os seguintes RFCs para informações atualizadas sobre as recomendações de indústria para marcação de pacotes:
- RFC 4594 - Configuration Guidelines for DiffServ Service Classes: rfc:4594
- RFC 5865 - A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic: rfc:5865
- RFC 8622 - A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services: rfc:8622
- RFC 5462 - Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field: rfc:5462
- E outros...
Resumo de marcações PHB, DSCP. IPP e MPLS
Apenas um "norte" aqui. Novamente, consulte os RFCs mais vigentes.
| Per Hop Behavior (PHB) | DSCP value | DSCP bits | IP precedence e Class of Service (COS) value (xyz000) | Comentários | MPLS EXP bits |
| Default | 0 | 000000 | 0=routine |
Best effort |
0 |
| 1 | 000001 | ||||
| 2 | 000010 | ||||
| 3 | 000011 | ||||
| 4 | 000100 | ||||
| 5 | 000101 | ||||
| 6 | 000110 | ||||
| 7 | 000111 | ||||
| CS1 | 8 | 001000 | 1=priority | 1 | |
| 9 | 001001 | ||||
| AF11 | 10 | 001010 |
Assured forwarding class 1 (001) Drop priority 010 (1) Último a ser descartado na classe AF1 |
||
| 11 | 001011 | ||||
| AF12 | 12 | 001100 |
Assured forwarding class 1 (001) Drop priority 100 (2) Penúltimo a ser descartado na classe AF1 |
||
| 13 | 001101 | ||||
| AF13 | 14 | 001110 |
Assured forwarding class 1 (001) Drop priority 110 (3) Primeiro a ser descartado na classe AF1 |
||
| 15 | 001111 | ||||
| CS2 | 16 | 010000 | 2=immediate | 2 | |
| 17 | 010001 | ||||
| AF21 | 18 | 010010 |
Assured forwarding class 2 (010) Drop priority 010 (1) Último a ser descartado na classe AF2 |
||
| 19 | 010011 | ||||
| AF22 | 20 | 010100 |
Assured forwarding class 2 (010) Drop priority 100 (2) Penúltimo a ser descartado na classe AF2 |
||
| 21 | 010101 | ||||
| AF23 | 22 | 010110 |
Assured forwarding class 2 (010) Drop priority 110 (3) Primeiro a ser descartado na classe AF2 |
||
| 23 | 010111 | ||||
| CS3 | 24 | 011000 | 3=Flash | 3 | |
| 25 | 011001 | ||||
| AF31 | 26 | 011010 |
Assured forwarding class 3 (011) Drop priority 1 (010) Último a ser descartado na classe AF3 |
||
| 27 | 011011 | ||||
| AF32 | 28 | 011100 |
Assured forwarding class 3 (011) Drop priority 2 (100) Penúltimo a ser descartado na classe AF3 |
||
| 29 | 011101 | ||||
| AF33 | 30 | 011110 |
Assured forwarding class 3 (011) Drop priority 3 (110) Primeiro a ser descartado na classe AF3 |
||
| 31 | 011111 | ||||
| CS4 | 32 | 100000 | 4=FlashOver | 4 | |
| 33 | 100001 | ||||
| AF41 | 34 | 100010 |
Assured forwarding class 4 (100) Drop priority 1 (010) Último a ser descartado na classe AF4 |
||
| 35 | 100011 | ||||
| AF42 | 36 | 100100 |
Assured forwarding class 4 (100) Drop priority 2 (100) Penúltimo a ser descartado na classe AF4 |
||
| 37 | 100101 | ||||
| AF43 | 38 | 100110 |
Assured forwarding class 4 (100) Drop priority 3 (110) Primeiro a ser descartado na AF4 |
||
| 39 | 100111 | ||||
| CS5 | 40 | 101000 | 5=critical | 5 | |
| 41 | 101001 | ||||
| 42 | 101010 | ||||
| 43 | 101011 | ||||
| 44 | 101100 | ||||
| 45 | 101101 | ||||
| EF | 46 | 101110 | Valor Expedited Forwarding (EF) recomendado (usado para tráfego de voz) | ||
| 47 | 101111 | ||||
| CS6 | 48 | 110000 | 6=internet | 6 | |
| 49 | 110001 | ||||
| 50 | 110010 | ||||
| 51 | 110011 | ||||
| 52 | 110100 | ||||
| 53 | 110101 | ||||
| 54 | 110110 | ||||
| 55 | 110111 | ||||
| CS7 | 56 | 111000 | 7=network | 7 | |
| 57 | 111001 | ||||
| 58 | 111010 | ||||
| 59 | 111011 | ||||
| 60 | 111100 | ||||
| 61 | 111101 | ||||
| 62 | 111110 | ||||
| 63 | 111111 |
Projeto de classes de tráfego do backbone
Quantas classes de tráfego você realmente precisará para a sua rede? O seu projeto poderá ficar substancialmente complexo dependendo desta granularidade. Devido a grande quantidade de classes de tráfego previstas, para muitos dos projetos em ISPs, em especial os provedores "menores", eu costumo partir para as recomendações padrão de indústria referenciadas pelo IETF, mas focando no modelo “4-Class SP Model”, que é relativamente simples e muito funcional. Vejamos primeiro os modelos conhecidos:
E, em seguida, os mapeamentos entre valores de marcações e suas respectivas classes de tráfego, além dos montantes de banda recomendados para cada uma destas classes, do modelo 4-Class SP Model:
O QoS em redes MPLS
Para manter a objetividade deste artigo - que está tornando-se um livro a esta altura do campeonato - não entrarei nesta seara. Apenas tecerei alguns comentários a respeito, até mesmo porque há a previsão de um artigo nesta Wiki para tratarmos somente do QoS em redes MPLS. Que tal partirmos para os "bullets", que fica mais simples e rápido de explicar?
- Numa rede de ISP "turbinada" com o MPLS, temos a parte da rede onde não há o MPLS (interfaces "customer-facing") e a parte da rede onde o MPLS está habilitado (interfaces "core-facing"). Certo?
- Isto significa que no sentido "cliente --> provedor", o pacote IP chega "puro". Ou seja, sem label, obviamente.
- Foi citado neste artigo que a classificação de pacotes deve ocorrer em todos os equipamentos na rede posicionados ao longo do caminho pretendido pela comunicação, certo?
- Neste caso a classificação poderá ocorrer normalmente por uma ou mais das ferramentas discutidas previamente neste artigo.
- Quando o primeiro dispositivo MPLS da rede do provedor tiver que impor um label sobre o pacote, antes de transmiti-lo para o próximo salto, uma das situações a seguir poderá ocorrer, dependendo de como você tiver configurado no seu projeto:
- Em primeiro momento, estamos discutindo aqui apenas a marcação DSCP realizada nos cabeçalhos IP. Mais precisamente, o pacote recebido do cliente que já contém um valor de marcação.
- O valor de marcação DSCP contido no cabeçalho IP deste pacote será "copiado" e "traduzido" para o seu valor equivalente no cabeçalho do MPLS (shim header). Isto deverá ocorrer automaticamente.
- Os roteadores do ISP ao longo do caminho (os P-routers) não realizarão quaisquer consultas no cabeçalho IP, portanto toda a classificação ocorrerá com base na marcação contida no MPLS shim header , e isto significa que as suas políticas de QoS na rede MPLS deverão saber o que executar para cada valor de marcação (ex: qual deverá ser a classe de tráfego para o pacote?).
- Quando o label for extraído (pop) do pacote, a marcação original contida no cabeçalho IP estará lá, ou seja, intacta, e havendo a preservação da marcação original fim-a-fim.
- Só que isto pode ser (e frequentemente é) indesejável para o operador de redes (ISP).
- Para a situação discutida no bullet acima, informo que as seguintes possibilidades existem, e isto é que chamamos de "DiffServ Tunneling" sobre a rede MPLS:
- Uniform Mode: há aqui apenas uma camada de preservação da marcação do QoS. Alguns backbones possuem políticas de QoS que podem remarcar o valor de um pacote de transmissão de um cliente caso haja uma violação de excesso de uso de uma das classes de tráfego contratadas entre o cliente e o ISP. Ou seja, a importância do pacote é "rebaixada" e o mesmo poderá ser transmitido (ou descartado lá na frente, caso haja um congestionamento). Quando na saída da rede MPLS for ocorrer o pop (retirada ou disposição) do label sobre o pacote, o valor (rebaixado ou não) que tiver citado no shim header do MPLS, no momento deste pop, será "copiado" e "traduzido" para o valor DSCP equivalente, ou seja, sobre-escrevendo o valor da marcação original. Ou seja, possa ser que no site "B" do cliente o pacote chegue com a marcação DSCP original, ou com a marcação DSCP modificada pelo ISP lá no momento do pop do label. Isto é válido e funcional para qualquer produto contratado pelo cliente junto ao operador de redes (L2VPN, L3VPN...).
- Pipe Mode: há aqui duas camadas relacionadas ao QoS. A primeira delas permanece intacta, que é a marcação original citada no cabeçalho IP do pacote do assinante. Já a segunda, é referente ao QoS do backbone do operador de redes. Em outras palavras, o provedor poderá modificar as marcações do "Traffic Class" (EXP bits) do header do MPLS em seu backbone caso necessário, mas não modificará o valor DSCP original do pacote no momento do pop do label. O MPLS PHB é usado para a classificação e regras de descarte no último salto da rede MPLS (PE de saída), mais precisamente quando for encaminhar o pacote através da interface que conecta o site B do cliente.
- Short-Pipe Mode: basicamente o mesmo comportamento do Pipe Mode, exceto que, na interface de saída em direção ao cliente, lá no último salto (PE de saída), a classificação ocorrerá pelo cabeçalho IP, e não pelo Traffic Class citado no label que foi retirado (pop) do pacote.
- Como alguns devem saber (ou não!), o MPLS Traffic Engineering (MPLS TE) não executa, não faz, hard QoS.
- Muitos acham que o MPLS TE faz QoS. A verdade é que não, não faz. Não policia a banda, não limita a banda, não gerencia filas, definitivamente não lida com estas questões.
- A banda sinalizada pelos túneis de TE é uma banda "efêmera", ou seja, uma banda de control plane apenas.
- Mas, Leo, nem mesmo com o Automatic Bandwidth (Auto-BW)? Nem mesmo com isto, pois uma coisa não tem nada a ver com a outra! Não perderei o tempo de vocês falando sobre esse recurso.
- A única interação entre MPLS TE e DiffServ ocorre através de um setup chamado DiffServ-Aware Trafic-Engineering (DS-TE).
- Isto será tema de outro artigo, não prolongarei essa dissertação aqui.
- O IETF estabeleceu alguns modelos de alocação, a saber:
- Maximum Allocation Model (MAM): um pool de banda é aplicado sobre uma classe. A soma dos pools de banda pode exceder o máximo de banda reservável (MRB), mas a soma da banda total reservada não pode exceder o MRB. Suportados aqui os modelos de implementação BC0 e BC1.
- Russian Dolls Model (RDM): um pool de banda pode ser aplicado sobre uma ou mais classes, e um pool de banda global (BC0) equivale ao MRB. BC0 a BCn são usados para computar a banda não reservada de uma determinada classe, sendo suportados aqui os modelos de implementação BC0 e BC1.
- Não se preocupe se não entendeu muito ou se entendeu bulhufas! Como tinha comentado, não é o foco deste artigo. Até mesmo porque o artigo tem que acabar, certo?
- O DS-TE por si só já exige amplo conhecimento tanto do DiffServ quanto do MPLS TE, por este motivo não foi e não será detalhado neste artigo. Fica para outro artigo, um belo dia...
Conclusões finais
Espero que este artigo tenha cumprido o seu principal objetivo, que foi explicar de forma bem didática o que é o QoS. Da mesma forma, exemplificar as categorias de ferramentas e elencar casos onde estas são implementadas na rede do ISP. Infelizmente um monte de coisas teve que ficar de fora, pois realmente não tem como abordar todo o tema num único artigo (sem a menor chance!). Gostaria de ter falado de ferramentas complementares (Call Admission Control e muitos outros), mas, quem sabe, isto não fica para futuros artigos na WIki?
A parte mais difícil de todo e qualquer conceito tecnológico é a teoria. Se você conseguiu entender esta carga teórica, mesmo que não consiga configurar qualquer coisa ainda, nem mesmo uma policy sequer, saiba que você agora já sabe a parte mais difícil. Com relação a "qual comando eu uso para fazer 'X'?", amigo, isto você encontrará facilmente no manual do seu equipamento! Segue a minha dica aqui: comando (CLI) não é conhecimento, é informação. O conhecimento de verdade está aqui, neste artigo.
Até o próximo!
Autor: Leonardo Furtado