WirelessBR

Série de artigos sobre VoIP
Terceiro artigo - Parte 02

Roteadores e QoS  (continuação)

IntServ e DiffServ:

Quando começou a discussão sobre a viabilidade de implementação de mecanismos globais de garantia de QoS em redes TCP/IP, as primeiras propostas convergiram para uma tentativa de fazer call admission (headiness index –5), chamada integrated services (IntServ).

Na proposta IntServ, para que um novo flow pudesse ser inserido na rede, deveria haver previamente uma negociação para reserva explícita de recursos (na prática, banda de passagem - bandwidth) em quantidade adequada à categoria de serviço exigida para aquele flow.

Para viabilizar esta negociação, foi proposto um novo protocolo de aplicação, chamado resource reservation protocol (RSVP). Através das primitivas RSVP, um host pode informar as características do novo flow (traffic specifications – TSPEC) e solicitar as características de serviço necessárias (service request specifications – RSPEC). Conforme o tipo de serviço solicitado, todos os gateways na rota fazem a reserva de banda necessária (via token buckets). Embora este tipo de mecanismo soe como música para os bellheads, ele apresenta alguns problemas, que limitam a sua aplicabilidade em grandes redes:

a)  Como todos os hosts na rota tem de confirmar explicitamente a reserva de banda para aplicações críticas, a negociação para admissão do novo flow fica complexa e demorada;

b)  À medida que o número de flows que passam por um gateway cresce, o esforço computacional para manter todos eles dentro das características de serviço negociadas cresce de forma não-linear, o que é indesejável;

c)  Se o tráfego tem de cruzar a fronteira administrativa entre AS diferentes, é muito difícil garantir que os critérios de reserva de recursos serão aplicados de forma homogênea fim a fim.

Assim, a não ser em pequena escala, o modelo IntServ não é muito popular. A alternativa que foi adotada em grande escala na Internet é chamada DiffServ (differentiated services), descrita nas RFCs 2474 e 2475.

No DiffServ, o btye TOS tem a sua função detalhada, com a preocupação de manter compatibilidade com as definições anteriores (afinal, ainda existem por aí equipamentos que implementam apenas a definição original do TOS), e passa a ser denominado DiffServ field (DS). Um domínio DiffServ (DiffServ domain) é um conjunto de roteadores que seguem as mesmas definições de encaminhamento de tráfego, com base no conteúdo do DS dos pacotes.

Os pacotes tem o conteúdo do DS marcado no seu ponto de ingresso no DiffServ domain. Logicamente, a definição de onde fica a fronteira do domínio é de responsabilidade dos administradores da rede. A depender da situação, esta fronteira pode estar no próprio host do usuário, no equipamento de acesso à rede (tipicamente LAN switches), ou no roteador de acesso à rede do provedor. A figura 3 mostra a configuração dos bits do DS.

Figura 3 - bits do DiffServ field (DS)

Os bits ECN (explicit congestion notification) não fazem parte da definição do DiffServ, e são reservados. Os bits DS5 a DS0 definem o DiffServ code point (DSCP). Cada roteador do DiffServ domain adota um comportamento local, chamado PHB (per-hop behavior) associado aos DSCPs.

As RFCs 2597 e 2598 definem três tipos de PHB: expedite forwarding (EF), assured forwarding (AF) e best-effort (BE). Só existe um PHB EF, que define um serviço de emulação de circuito (virtual leased line – VLL) fim a fim, com baixa perda, baixo delay, jitter controlado e garantia de banda (cacilda!! Meu headiness index meter bateu fora de escala no lado negativo!). Os PHBs AF (são doze no total, combinando características de prioridade de transmissão e probabilidade de perda) servem para criar serviços diferenciados em relação ao serviço provido pelo PHB default BE (que significa nenhuma diferenciação do tráfego).

Se vocês estão percebendo alguma ligação entre o que falamos antes (WRED e CBWFQ) e os PHBs do DiffServ, isto não é mera coincidência. Aqueles algoritmos são a forma de implementação dos PHBs em cada roteador. A figura 4 mostra as diversas configurações dos DSCPs com os tipos de PHB definidos.

 

 Figura 4 - PHBs e DSCPs

As classes do PHB AF são designadas na forma AFxy, onde x indica a prioridade de transmissão (4 = alta, 1 = baixa) e y indica a probabilidade de descarte em caso de congestionamento (1 = baixa, 2 = média, 3 = alta).

O comportamento típico de um roteador que implementa DiffServ é: fora de congestionamento os pacotes marcados como EF tem serviço VLL garantido, podendo exceder a banda mínima garantida, se necessário, e os demais pacotes são encaminhados em modo FCFS; em congestionamento, entram em vigor os limites de banda mínima definidos para cada classe (EF e AF), sem que a classe EF possa exceder o limite estabelecido, e os pacotes marcados como BE terão a “sobra” da capacidade de transmissão (se houver).

Voltando ao que falamos antes na descrição do algoritmo CBWFQ, o fato de definir uma classe de prioridade absoluta (que normalmente estará associada ao PHB EF) garante apenas o menor delay possível. À medida que o tráfego EF que tem de ser encaminhado através de uma interface cresce, a disputa pela banda reservada aumenta, e isto vai refletir no aumento do jitter. Para controlar isto, a única maneira é ajustar a banda reservada para o PHB EF naquela interface de acordo com o volume esperado de tráfego nesta classe de serviço. E, se o congestionamento for severo, mesmo com WRED ocorre tail drop, e, neste caso, o tráfego EF também vai sofrer.

Multi-Protocol Label Switching (MPLS):

O Segundo maior fator que afeta a latência de um roteador é o tempo necessário para que o protocolo IP decida para qual interface física o pacote deve ser encaminhado, através da inspeção da sua tabela de rotas (buscando o largest prefix match do CIDR).

É evidente que, quanto maior for a tabela de rotas, maior será o tempo necessário para a tomada desta decisão, e, conseqüentemente, maior será a latência.

Os protocolos de dynamic routing, tanto para exterior routing quanto para interior routing, preocupam-se com isto, tentando minimizar o número de entradas na tabela de rotas pelo uso de rotas-sumário (summary routes). Mesmo assim, na Internet é comum encontrarmos roteadores cujas tabelas de rotas tem alguns milhares de entradas.

É desejável, então, algum mecanismo que permita simplificar o processo de roteamento de pacotes através de grandes redes, evitando o custo computacional de pesquisa em grandes tabelas de rotas. O método predileto, hoje em dia, para conseguir isto é o MPLS (multi-protocol label switching).

O MPLS surgiu como uma proposta proprietária da Cisco Systems, chamada tag switching. Posteriormente foi padronizada pelo IETF na RFC 3031. A idéia básica é acelerar o encaminhamento (forwarding) dos pacotes, através do uso de rotas pré-definidas (chamadas label paths).

Ao ingressar na rede MPLS, o pacote recebe um header MPLS, que pode conter um ou mais labels. A identificação no label permite que os roteadores MPLS associem o pacote a uma forwarding equivalence class (FEC), e cada FEC está associada a um label path na rede. Os protocolos para troca de informações de associação de FECs aos label paths, e configuração (o termo bellhead para isto é provisionamento) dos label paths entre os roteadores MPLS são o LDP (label distribution protocol) e o RSVP-TE (resource reservation protocol – traffic engineering extension).

Hum... meu headiness index meter está descendo... descendo... estabilizou no –4. Um fato sobre o MPLS precisa ser bem compreendido: ele não foi desenvolvido com o objetivo principal de acelerar o roteamento em redes IP. O objetivo real era posicionar uma rede de roteadores como alternativa viável ao frame-relay e ao ATM para a construção de redes multi-serviço (leia-se: capazes de transportar voz e dados como entidades separadas). E, especialmente com os acréscimos do PWE3[3] (pseudo-wire emulation edge-to-edge, também conhecido como martini drafts), esta vocação fica mais que evidente.

Tenho minhas dúvidas se o desempenho de roteamento no core de uma rede TCP/IP de grande porte será significativamente melhor com o uso do MPLS do que, por exemplo, uma política agressiva de sumarização de rotas via dynamic routing associada ao uso de roteadores que armazenem a routing table em CAM (content-addressable memory). Querendo ou não, o processo de adicionar e remover labels aos pacotes IP vai exigir algum aumento de latência nos pontos onde isto ocorra. Se o aumento da latência for maior que a diminuição no delay para atravessar a rede MPLS (comparado com o delay do roteamento IP convencional) então não há ganho.

O que o MPLS tem de realmente bom, especialmente para os provedores de serviço, são duas coisas: a possibilidade de configurar VPNs (virtual private networks), que neste caso atendem pelo acrônimo VRF (virtual routing/forwarding facility); e mecanismos de reconvergência em caso de falha tão rápidos quanto nas redes SDH/Sonet – FRR (fast reroute).

Enfim... Uma vez que o MPLS está aí para ficar, vamos ver como ele funciona. Os roteadores na borda da rede MPLS, chamados LER (label edge router) ou PE (provider edge), são os responsáveis pela inserção e remoção[4] dos labels associados aos pacotes IP. Os roteadores PE são os que “carregam o piano” em uma rede MPLS, porque precisam inspecionar a tabela de rotas local e definir a FEC que será inserida no label.

O core de uma rede MPLS é formada por roteadores LSR (label switching routers), também conhecidos como roteadores P (provider), cuja única função é fazer o forwarding dos pacotes, com base na FEC informada no label e em uma tabela simples de associação entre FECs e label paths.

Outro conceito errado sobre MPLS é que ele é de grande ajuda (ou até indispensável) para a garantia de QoS em redes TCP/IP. Então vamos à próxima seção, para vermos como o QoS é tratado em redes MPLS.

MPLS e QoS:

No label MPLS existem três bits EXP (experimental), que são utilizados para associar informação de prioridade de forwarding aos pacotes. O fato de serem chamados “experimental” dá uma boa idéia do que a proposta original do MPLS dizia sobre QoS.

A forma mais comum para trasladar a informação dos DSCPs DiffServ dos pacotes para o MPLS é repetir, nos bits EXP do label, os bits DS5, DS4 e DS3 do byte DS no header IP.

Não tenho nenhuma informação objetiva sobre isso, mas não vejo porque um algoritmo como o WFQ não pudesse ser utilizado no tratamento da fila de pacotes associada a cada label path. De qualquer forma, assim podem ser criadas até oito classes de prioridade para forwarding MPLS, compatíveis com as classes de prioridade do DiffServ.

Uma confusão comum é achar que, configurando VRFs MPLS, é possível fazer redes virtuais “mais prioritárias” do que outras (isto é especialmente comum em operadoras de telecom). Só que não é verdade. O conceito de VRF serve apenas para que as VPNs configuradas compartilhem a mesma infra-estrutura de transmissão de forma logicamente independente, mas todos os pacotes, de todas as VRFs, que tenham a mesma configuração nos bits EXP serão encaminhados com a mesma prioridade.

Vamos a um exemplo prático (e comum na praça). A operadora XYZ telecom quer implementar um core multi-serviço MPLS para poder implementar duas VRFs TCP/IP separadas: uma para o tráfego de serviços aos assinantes, e outra para a sua rede corporativa (tráfego administrativo interno). Suponhamos que na VRF de serviços existam hosts que implementam serviços VoIP para os assinantes, e que na VRF corporativa existam hosts que implementam um PABX (private automatic branch exchange) VoIP.

O mais provável é que ocorra o seguinte: tanto na VRF de serviços quanto na VRF corporativa, os pacotes de voz e de sinalização recebam os mesmos DSCPs (EF e AF43, respectivamente). Enquanto os tráfegos fiquem segregados, tudo bem. Mas, no momento que eles passam a trafegar pelo core MPLS, eles receberão as mesmas configurações de bits EXP, portanto o tráfego VoIP dos assinantes irá competir diretamente com o tráfego VoIP corporativo.

Conclusões:

Do que vimos nesta parte da série, chegamos às seguintes conclusões:

a)  É possível garantir QoS em redes TCP/IP, mas o traffic engineering é mais complicado, e as características específicas de como cada fabricante de roteadores implementa os PHBs DiffServ é um dos fatores que deve ser levado em conta (em redes multi-vendor, isto pode originar problemas muito interessantes);

b)  MPLS não é panacéia. Existem casos onde ele será útil, e outros onde ele só vai atrapalhar.

c)  Uma rede de roteadores IP (com ou sem um core MPLS) não é, nem vai ser, uma rede de comutação de circuitos. Podemos configurar a rede para minimizar a probabilidade de ocorrência de perdas de pacotes, manter o menor delay possível, e controlar o jitter, mas o comportamento destas variáveis é estatístico, e não determinístico.

A seguir:

Estamos quase no ponto onde podemos mergulhar mais fundo nas características das aplicações VoIP. Só falta um ponto de base a cobrir, que é o dimensionamento dos links e roteadores da rede TCP/IP que irá transportar tráfego VoIP. De passagem, veremos como transladar os conceitos da teoria do tráfego telefônico para o ambiente TCP/IP.

Inté o próximo artigo...