1
Qualidade de Serviço aplicado a redes IP
Marcelo S. Araujo
Resumo - Este trabalho consiste em demonstrar e explicar as
ténicas existentes no mercado para a criação de mecanismos que
possam prover algum tipo de grarantia de qualidade de serviço
para aplicações em redes de computadores que usam o protocolo
IP. O artigo foi elaborado visando únicamente as técnicas
usadas no protocolo IP, foram escolhidas apenas as tecnologias
já consolidadas no mercado e que tornaram-se padrões na
Internet.
Index Terms-- Cisco, CoS, DSCP, DiffServ, FreeBSD, IP,
IPFW, MPLS, QoS e ToS.
I. NOMENCLATURA
Uma lista com as principais nomenclaturas
alfabetica usadas no texto.
AF
BE
BSD
CS
DSCP
EF
IP
IPFW
PHB
QoS
RFC
ToS
E
-
em ordem
Assure Forwarding
Best Effort
Berkeley Software Distribution
Class Selector
Differentiated Services Field Codepoint
Expedite Forwarding
Internet Protocol
IP Firewall
Per-Hop Behavior
Quality of Service
Request For Comments
Type of Service
II. INTRODUÇÃO
ste artigo apresenta as principais técnicas usadas no
mercado para manipular e classificar pacotes de dados
transferidos como fluxo de informações usando o protocolo IP
em suas versões 4 e 6 mais comumente conhecidos como
Ipv4 e Ipv6. A aplicabilidade desta pesquisa consiste tanto
em mostrar os modelos em um ambiente experimental e
funcional, como na geração de código de máquina
desenvolvido usando a linguagem de programação C e
aplicado diretamente no sistema operacional FreeBSD,
permitindo que outras
pessoas ao redor
do mundo
beneficiem-se com este aprendizado.
As redes IP's suportam hoje diferentes aplicações
encontradas no mercado, o uso da tecnologia para a
transferência de voz, video e dados de aplicações críticas
requerem cada vez mais o uso de técnicas para classificar este
tipo de fluxo de informação e garantir a qualidade em seu
momento
de
uso.
A
escolha do FreeBSD como sistema operacional para
a implementação dos testes e geração de código
partiu em síntese por ser conhecido como um dos mais
robustos e seguros sistemas operacionais da computação
moderna. FreeBSD é usado no coração da Internet, toda a
infra-estrutura DNS F-ROOT, na raiz do sistema de resolução
de nomes é sustentado por FreeBSD, que também é a base dos
maiores backbones acadêmicos e governamentais, segundo
Paul Vixie do ISC(Internet Systems Consortium). FreeBSD
serve os sites de maior tráfego na Internet, em especial a rede
Yahoo! e as maiores empresas de hosting do mercado,
representando segundo a consultoria inglesa Netcraft 27% de
todos
os
sites
da
Internet.
Rank Position
Company Site
OS
1
DataPipe
FreeBSD
6
Aplus
FreeBSD
Tab1.
F
8
Pair Networks
FreeBSD
12
Swishmail
FreeBSD
23
WebAir
FreeBSD
Servidores
com
os
maiores
uptimes.
reeBSD
é conhecido também por ter uma das
melhores e mais famosas implementações TCP/IP
conhecidas no mercado. Em julho de 2005, Andre
Oppermann, desenvolvedor FreeBSD solicitou levantamento
de fundos para trabalhar de forma dedicada em melhorias do
protocolo TCP/IP no FreeBSD. Sistemas BSD tem, desde seus
primórdios, a reconhecida fama de ter uma das pilhas TCP/IP
mais robustas e com melhor performance, além de ter sido o
sistema onde o TCP/IP foi projetado, criado e popularizado. O
FreeBSD por volta da série 3 teve um grande número de
mudanças, e o sistema ficou conhecido na época como a
melhor implementação TCP/IP disponível, e manteve esse
título sem contestações até início da série 4. Hoje na atual
2
série 7 o FreeBSD destaca-se pela performance e inovações
inseridas novamente na pilha TCP/IP.
III. PREPARAÇÃO TÉCNICA DO TRABALHO
Rank Position
Company Site
OS
1
DataPipe
FreeBSD
10
Aplus
FreeBSD
13
Swishmail
FreeBSD
22
Pair Network
FreeBSD
25
WebAir
FreeBSD
T
ab2. Servidor com maior troughput
A
escolha do IPFW e suas API's para a implementação
do código experimental e para a execução dos testes e
comprovações de teorias consistem em que o mesmo é
robusto o bastante e possui uma grande comunidade de
desenvolvedores e especialistas nesta ferramenta que é o
FIREWALL padrão do FreeBSD , implementado inicialmente
em 1993 por Daniel Boulet e mantido hoje por uma
comunidade de desenvolvedores , destacando-se entre eles
Luigi Rizzo ao qual implementou muitas novas funções como
DUMMYNET e outros mecanismos para a implementação de
Traffic Shapping. Históricamente o FreeBSD é um dos
projetos mais bem organizados e possuí mais de 10 anos de
logs em seu repositório oficial de código. O IPFW em
particular possuí mais de 5 anos de histórico documentado .
“””
Revision 1.1 - Thu Jun 27 23:02:16 2002 UTC (5 years, 11 months ago)
by luigi.
“””
A
lém destas informações o IPFW possuí uma lista
especialisada
para
discussões
entre
os
desenvolvedores chamada de [email protected] e
os emails gerados por esta pesquisa podem ser vistos em:
http://lists.freebsd.org/pipermail/freebsd-ipfw/2008February/003282.html
http://lists.freebsd.org/pipermail/freebsd-ipfw/2008February/003291.html
http://lists.freebsd.org/pipermail/freebsd-ipfw/2008February/003294.html
http://lists.freebsd.org/pipermail/freebsd-ipfw/2008February/003296.html
http://lists.freebsd.org/pipermail/freebsd-ipfw/2008February/003297.html
http://lists.freebsd.org/pipermail/freebsd-ipfw/2008February/003295.html
http://lists.freebsd.org/pipermail/freebsd-ipfw/2008March/003387.html
http://lists.freebsd.org/pipermail/freebsd-ipfw/2008March/003422.html
http://lists.freebsd.org/pipermail/freebsd-ipfw/2008March/003421.html
Para interação com outros desenvolvedores ao redor do
mundo em especial com Roman Bogorodskiy(RUSSIA),
Stanislav Sedov(RUSSIA) e Ion-Mihai Itetcu(ROMENIA) ao
qual ajudaram-me em muitos tópicos desta pesquisa, desde
a implementação do código até a resolução dos testes, foi
usado alguns sistemas desenvolvidos pelo google como o
WIKI(http://code.google.com/p/exports/w/list)
e
o
GoogleCode
um
agregado
de ferramentas
para
desenvolvimento colaborativo.
Os principais
tópicos
pesquisados
foram as
implementações que modificam diretamente algum aspecto
do protocolo IP com foco direto em seu cabeçalho,
O protocolo IPv4 é dividido em seu cabeçalho por 14
campos contendo de 20 a 60 bytes com endereços de 32
bits .
O protocolo IPv6 é dividido em seu cabeçalho por 8
campos contendo 40 bytes fixos com endereços de 128bits.
IPv4 (32bits) 232 = 4 bilhões de endereços
IPv6 (128bits) 2128 = 340 decilhões de endereços
IPv4 = 200.18.53.60
IPv6 = 2001:12F0:502:206:212:F0FF:FEDA:BA61
Cada versão de protocolo implementa o conceito de
precedência de pacote e a interoperabilidade entre ambas as
versões existe de forma funcional.
Podemos classificar as técnicas de marcação IP
existentes no mercado como:
1.
2.
3.
ToS
CoS
DSCP
A. A arquitetura do IPv4 e IPv6
Para entendermos as técnicas utilizadas neste projeto é
necessário que tenhamos uma introdução básica sobre a
estrutura do protocolo IP em ambas as versões.
3
definem a precedência do pacote.
/*
* Definitions for IP precedence (also in ip_tos)
* unused).
*/
#define IPTOS_PREC_NETCONTROL
#define IPTOS_PREC_INTERNETCONTROL
#define IPTOS_PREC_CRITIC_ECP
#define IPTOS_PREC_FLASHOVERRIDE
#define IPTOS_PREC_FLASH
#define IPTOS_PREC_IMMEDIATE
#define IPTOS_PREC_PRIORITY
#define IPTOS_PREC_ROUTINE
(hopefully
0xe0
0xc0
0xa0
0x80
0x60
0x40
0x20
0x00
Tipo de serviço: Os próximos 4 bits definem o tipo de
serviço do pacote.
Neste diagrama de blocos podemos ver que existe uma
divisão significativa em todo o cabeçalho IP, usando a
estrutura de código escrita em C do próprio IP, rápidamente
apresentarei esta estrutura.
Código: sys/netinet/ip.h
Estrutura IPv4:
Version: Sempre deve ser definido com a versão corrente
do protocolo, neste caso 4.
IP Header Length: Normalmente é formado por um
tamanho de 32bits, o real tamanho do cabeçalho IP.
struct ip {
#if BYTE_ORDER == LITTLE_ENDIAN
u_int ip_hl:4,
/* header length */
ip_v:4;
/* version */
#endif
#if BYTE_ORDER == BIG_ENDIAN
u_int ip_v:4,
/* version */
ip_hl:4;
/* header length */
#endif
ToS: Campo de 8bits que indica o tipo de serviço ao qual
o pacote faz parte, desta forma é possivel classificar
determinado pacote e tomar uma decição em cima desta
classificação.
No campo ToS temos uma grande estrutura de código que
divide os 8 bits em 3 tipos de classificadores de pacotes.
Precedência IP: Os 3 primeiros bits do campo ToS
/*
* Definitions for IP type of service (ip_tos).
*/
#define IPTOS_LOWDELAY
0x10
#define IPTOS_THROUGHPUT
0x08
#define IPTOS_RELIABILITY
0x04
#define IPTOS_MINCOST
0x02
#if 1
/* ECN RFC3168 obsoletes RFC2481, and these will be
deprecated soon. */
#define IPTOS_CE
0x01
#define IPTOS_ECT
0x02
#endif
O sétimo bit: Comumente chamado de MBZ(must be
zero), é considerado desta forma após um UPDATE da
RFC1349.
Ná prática temos a seguinte divisão dos 8bits no header
ToS :
0
1
2
3
4
5
6
7
PRECEDENCE
TOS
MBZ
|------------------------------- Field ToS ---------------------------|
Size of Datagram: Combina o tamanho do cabeçalho com
o tamanho do dado enviado, este campo é definido em bytes.
O minímo é 20bytes e o máximo 65535 ou 64Kbytes de
tamanho de um datagrama.
/* maximum packet size */
#define IP_MAXPACKET
65535
Identification: Um nùmero de até 16bits que em
conjunto com o source address identifica este pacote, usado
4
durante o reassembly de fragmentos de datagrama para a
remontagem do pacote.
onde o pacote não está protegido por uma camada CRC no
link físico. Pacotes com checksum inválidos são descartados
por todos os nós em uma rede.
Flags: Uma sequência de 3 flags usada para controlar
quando um roteador pode estar apto a fragmentar um pacote
recebido..
u_short ip_off;
#define IP_RF 0x8000
#define IP_DF 0x4000
#define IP_MF 0x2000
/* fragment offset field */
/* reserved fragment flag */
/* dont fragment flag */
/* more fragments flag */
Fragmentation Offset: Um contador de 1byte que é setado
pelo roteador que esta fragmentando determinado pacote.
Time To Live: Nùmero máximo de saltos em que um
pacote pode ser encaminhado até o seu destino, é
decrementado por cada roteador que o mesmo passa. Existem
duas definições para o TTL ao qual ditam o nùmero máximo
de saltos que um pacote pode dar, na RFC 1340 esse nùmero
é de 64 saltos, este é o padrão usado no sistema FreeBSD.
/*
* Internet implementation parameters.
*/
/* maximum time to live (seconds) */
#define MAXTTL
255
/* default ttl, from RFC 1340 */
#define IPDEFTTL 64
/*
* This is the real IPv4 pseudo header, used for computing
* the TCP and UDP.
*/
struct ippseudo {
/* source internet address */
struct in_addr ippseudo_src;
/* destination internet address */
struct in_addr ippseudo_dst;
u_char
ippseudo_pad; /* pad, must be zero */
u_char
ippseudo_p;
/* protocol */
u_short
ippseudo_len; /* protocol length */
};
#endif
Source Address: O endereço original de quem enviou o
pacote.
Destination Address: O endereço final do destinatario do
pacote.
Estrutura IPv6:
Version: 4bits com o número da versão IP.
Traffic Class: 8bits valor de prioridade para tráfego
internet.
Protocol: Indica o tipo de protocolo usado para transportar
o pacote IP.
IDENTIFICADOR PROTOCOLO
1
ICMP
2
IGMP
6
TCP
17
UDP
Header Checksum: É insirido pelo remetente do pacote e
atualizado sempre que o cabeçalho é modificado por um
roteador, comumente usado para detectar erros de
transformação introduzida no pacote dentro de um roteador
Flow Label: 20bits utilizado para manipulação especial de
identificação sequêncial de pacotes entre origem e destino.
Payload length: 16bits unsigned, Especifica o
comprimento de dados incluso no pacote. Quando habilitado a
zero, a opção é um hop-by-hop jumbo frame.
Next Header: Especifica o próximo protocolo
encapsulado. Os valores são compatíveis com os especificados
para o protocolo IPv4.
Hop Limit: 8bits unsigned, é um substituto do campo TTL
no IPv4.
Source Address e Destination Address: Tem a mesma
função do protocolo IPv4.
NOTA: A estrutura IPV6 é muito simples tratando-se do
código implementado, por este motivo não introdusi trexos do
código neste documento, mas os mesmos podem ser vistos
em:
código: sys/netinet/ip6.h
5
B. ToS - Type of Service
Este tópico pretende clarificar alguns aspectos dentro dos
8bits usados por todo o campo ToS no cabeçalho IPv4. O
protocolo IPv6 foi projetado para manter interoperabilidade
com condicionadores de pacotes projetados para o IPv4, o
mesmo tipo de marcação usado no IPv4 pode ser usado em
conjunto
com
o
protocolo
IPv6.
Existe hoje algumas dúzias de RFC's que explicam o uso
correto dos 8bits do campo ToS, vários updates foram
lançados em torno destas RFC's gerando uma pequena
confusão e não conformidade entre diversos fabricantes de
equipamentos
de
rede.
Embora tudo isso pareça desorganizado, temos algumas
regras e práticas a serem adotadas para implementar o uso
correto do ToS. Na RFC 791 temos os 3 primeiros bits 0-2
identificados como PRECEDENCE e os próximos 3 bits 3-5
para classificar o tipo de serviço, o restante dos bits 6 e 7 são
reservados para uso futuro.
Bits 0-2: Precedence.
Bit 3: 0 = Normal Delay,
1 = Low Delay.
Bits 4: 0 = Normal Throughput, 1 = High Throughput.
Bits 5: 0 = Normal Relibility, 1 = High Relibility.
Bit 6-7: Reserved for Future Use.
0
1
2
3
PRECEDENCE
4
5
TOS
6
7
0
0
Em 1992 foi criada a RFC 1349 e consequentemente
parte da RFC 791 tornou-se obsoleta. Apartir desta nova
definição usamos um bit reservado para transmitir datagramas
dentro da rede com uma nova marcação.
0
------
1
minimize delay
maximize throughput
maximize reliability
minimize monetary cost
normal service
2
3
4
5
6
7
PRECEDENCE
TOS
MBZ
|------------------------------- Field ToS ---------------------------|
Para provar os conceitos aprendidos nesta pesquisa além
das RFC's consultadas foi verificado como o sistema FreeBSD
implementa essas ténicas em seu principal firewall
chamado de IPFW.
Código: sbin/ipfw/ipfw2.c
static struct _s_x f_iptos[] = {
{ "lowdelay", IPTOS_LOWDELAY},
{ "throughput", IPTOS_THROUGHPUT},
{ "reliability", IPTOS_RELIABILITY},
};
Podemos verificar que o IPFW esta de acordo com a
implementação proposta na RFC 1349.
C. ToS – IP Precedence
O campo PRECEDENCE é raramente usado e por default é
chamado com o offset 0xe0 no sistema FreeBSD com todos
os 3 primeiros bits setados como 111.
Código: sys/netinet/ip_fw2.c
case O_IPPRECEDENCE:
match = (is_ipv4 &&
(cmd->arg1 == (ip->ip_tos & 0xe0)) );
break;
O IPFW por padrão não suporta todas as combinações
propostas pela RFC 791..
|------------------------------- Field ToS ---------------------------|
1000
0100
0010
0001
0000
{ "mincost", IPTOS_MINCOST},
{ "congestion", IPTOS_CE},
{ "ecntransport", IPTOS_ECT},
{ "ip tos option", 0},
{ NULL, 0 }
111 - Network Control
110 - Internetwork Control
101 - CRITIC/ECP
100 - Flash Override
011 - Flash
010 - Immediate
001 - Priority
000 – Routine
A RFC 791 explica como podemos usar estes 3 primeiros
bits para controlar alguns aspectos em uma rede de
computadores.
Os offsets 0xe0(Network Control) e
0xc0(Internet Control) devem ser usados somentre e
unicamente entre GATEWAYS de rede, todos os outros
offsets podem ser usados para controles internos dentro da
rede.
Com base neste estudo
foi desenvolvido um
patch(remendo) que implementa todos os controles
PRECEDENCE propostos pela RFC 791. Este patch ainda
não foi incluído oficialmente no KERNEL do sistema, o
mesmo pode ser visto e acompanhado através do BUG
TRACKER GNATS.
PR Number: kern/121122
http://www.freebsd.org/cgi/query-pr.cgi?pr=121122
Este patch implementa uma nova função chamada de
iptospre na interface ipfw com o usuario.
ipfw add 10 iptospre immediate ip from 192.168.0.0/24 to any
ipfw add 11 count ip from 192.168.0.0/24 to any iptospre immediate
6
D. DSCP – Differentiated Services Code Point
Serviços Diferenciados(DiffServ) é um novo modelo no
qual o tráfego é tratado por sistemas intermediários com
prioridades relativas baseadas no campo ToS. Definido na
RFC 2474 e RFC 2475, o padrão DiffServ substitui a
especificação original de definir a prioridade do pacote
descrita na RFC 791. O DiffServ aumenta o número de níveis
de prioridade definíveis realocando os bits no campo ToS.
IP PRECEDENCE = INTERCONTROL
DSCP CODE = CS6
O CS(Class Selector) mantêm a interoperabilidade entre
redes que usam o IP PRECEDENCE e DSCP para manipular
e classificar alguns fluxos de dados.
DSCP
CS0
CS1
CS2
CS3
CS4
CS5
CS6
CS7
A RFC 2474 define a imiplementação DiffServ com o
seguinte texto:
“””
Differentiated services enhancements to the Internet
protocol are intended to enable scalable service
discrimination in the Internet without the need for per-flow
state and signaling at every hop. A variety of services may be
built from a small, well-defined set of building blocks which
are deployed in network nodes.
“””
O aumento da necessidade de permitir a discriminação de
serviços escaláveis usando o protocolo IP sem a necessidade
de definir o estado desta prioridade por fluxo de dados
transmitido e o beneficio de definir blocos de condicionadores
de tráfego para garantir a qualidade do serviço é um dos
principais motivadores para o DiffServ tornar-se o padrão
usado hoje pelo mercado.
O DSCP usa os seis primeiros bits mais significativos do
cabeçalho ToS. Os últimos bits atualmente não são usados.
IPTOSPRE
ROUTINE
PRIORITY
IMMEDIATE
FLASH
FLASHOVER
CRITICECP
INTERCONTROL
NETCONTROL
BITS
000000
001000
010000
011000
100000
101000
110000
111000
O padrão DiffServ usa os 6 primeiros bits mais
significativos no campo ToS chamado de DSCP ao qual
possibilita criar alguns mecanismos para condicionamento de
tráfego in redes de computadores.
0
1
2
3
4
5
6
7
0
0
0
0
0
0
X
X
|------------------------------- Field ToS ---------------------------|
A classificação dos pacotes estão disponíveis em 3 fases,
estas fases provêem uma nova forma de diferenciar serviços
dentro de uma rede.
As RFCs 2597 e 2598 propoem estes três níveis:
DSCP: Differentiated services codepoint
CU: Currently unused
Minha principal dúvida é em como o DSCP trabalha em
uma rede onde usa-se IP PRECEDENCE para marcar algum
tipo de pacote IP. A estrutura DSCP prove
plena
interoperabilidade entre redes que usam IP PRECEDENCE. O
padrão estipulado pelo IETF(Internet Engineering Task
Force) reusa todo os bits do campo ToS mas mantém total
compatibilidade entre as duas tecnologias.
Exemplo:
0
1
2
3
4
5
6
7
1
1
0
X
X
X
X
X
|------------------------------- Field ToS ---------------------------|
EF (expedite forwarding): Têm um atraso baixo e
concedem a largur a de banda necessária.
AF (assure forwarding): Diferenciar e classificar a largura
de banda.
BE (best-effort): Nenhuma classificação de largura de
banda.
EF – Expedite forwarding: Assim como é descrito na
RFC 2598, o EF deve ter uma baixa perda de pacote e uma
baixa latência o que lhe assegura uma rápida transmissão de
um extremo ao outro da rede, este serviço é conhecido
também como serviço Prêmio. Muitas situações onde a rede
têm um tráfego excedido e precisamos de alguma largura de
banda garantida para uma palicação, devemos usar o EF para
este.
O DSCP recomendado para o EF: 101110
AF – Assure forwarding: A RFC 2597 define um grupo
chamado de AF(Assure forwarding) dentro do domínio
7
DiffServ. Este grupo define quatro principais níveis para
classificar e manipular alguns fluxos dentro da rede. Assim
como é descrito na RFC 2597, o AF é um meio de classificar
diferentes garantias para um pacote IP dentro de um domínio
DiffServ, essas classificações tem como base duas situações,
prioridade de transmissão e probabilidade de descarte.
Class 1
Baixa Perda
Média Perda
Alta Perda
1010
1100
1110
AFxy
DSCP
AF11
AF12
AF13
AF21
AF22
AF23
AF31
AF32
AF33
AF41
AF42
AF43
Class 2
10010
10100
10110
Class 3
alguns componentes como classificadores de pacotes,
condicionadores de pacotes e algoritimos de descarte são
necessários para a implementação de QoS em redes de
computadores. Na figura abaixo podemos ver todos os prérequisitos para implementar QoS em uma rede IP.
Class 4
11010
11100
11110
100010
100100
100110
Onde x: Prioridade de transmissão.
Onde y: Probabilidade de discarte.
BITS
001010
001100
001110
010010
010100
010110
011010
011100
011110
100010
100100
100110
BE – Best effort: Quando não é necessário nenhum
mecanismo para diferenciar o tráfego, usamos o BE.
Um dos desenvolvedores
do FreeBSD Roman
Bogorodskiy(RUSSIA) desenvolveu um patch que ainda não
está incluído oficialmente no KERNEL do sistema, o mesmo
pode ser visto e acompanhado através do BUG TRACKER
GNATS.
O projeto FreeBSD provê todos os recursor necessários
para a implementação de QoS em redes de computadores,
sendo que o principal componente é chamado de
DUMMYNET(4).
O DUMMYNET é desenvolvido e mantido por Luigi
Rizzo([email protected])
inicialmente
para
efetuar
experimentos em redes de computadores. Hoje o sistema
DUMMYNET permite o controle do tráfego simultaneamente
em diversas interfaces de rede,
pode-se implementar
limitações de largura de banda, políticas de prioridade em filas
de condicionamento de tráfego e emulação de atraso e perda
de pacotes,
todos os recursos providos pelo sistema
DUMMYNET são implementados através do ipfw(8).
PR Number: kern/102471
http://www.freebsd.org/cgi/query-pr.cgi?pr=102471
Este patch implementa uma nova função chamada de dscp
na interface do ipfw com o usuario.
ipfw add 10 dscp AF33 ip from 192.168.0.0/24 to any
ipfw add 11 count ip from 192.168.0.0/24 to any dscp AF33
E. Ambiente de teste
Uma breve descrição do ambiente a ser testado e da
simulação prática.
Quando falamos em criar ou aplicar QoS em uma rede de
computadores usando o protocolo IP ou não, devemos estar
atento que QoS é um conjunto de componentes ao qual
permite garantir alguma qualidade no serviço prestado,
somente marcar e identificar pacotes não garante que
determinado fluxo de dados tenha prioridade dentro da rede,
O DUMMYNET implementa uma variante do algoritmo
de descarte de pacotes WFQ(Weighted Fair Queueing)
chamado de WF2Q+(Worst-case Weighted Fair Queueing) .
O algoritimo WF2Q+ foi desenvolvido por Jon Bennett e
8
Zhang Hui em 1997. Com o WF2Q+, cada fluxo está
associado a um peso, de tal forma que a soma de todos os
pesos de todos os fluxos não pode ser maior que um valor prédefinido W.
mesmos estão descritos e apresentados no diagrama de rede
abaixo.
peso[1] + peso[2] + ... + peso[N] <= W
Um determinado peso especifica o quanto de capacidade de
saída determinado fluxo tem o direito de receber, quanto
menor o peso, menos pacotes seram enfileirados.
O funcionamento do DUMMYNET consiste básicamente
em usar o IPFW para classificar os pacotes e devidi-los em
fluxos. Dependendo da política adotada, um fluxo de pacote
pode conter uma única conexão TCP, ou a partir da
identificação do src/dst, ou uma sub-rede inteira ou
simplesmente um determinado protocolo.
Pacotes que pertencem ao mesmo fluxo são então passados
para o interior de dois diferentes objetos que aplicam o
condicionamento de tráfego.
PIPE: O PIPE emula um link com determinada largura de
banda, delay e filas para a simulação de perda de pacotes. Os
pacotes são enfileirados a partir de um classificador e, em
seguida, transferido para o PIPE correspondente.
QUEUE: O QUEUE é uma abstração utilizada para
executar o algoritimo WF2Q+. O QUEUE associa um peso e
uma referência para cada PIPE, cada vez que o QUEUE
receber determinado fluxo o controle de banda é efetuado. O
descarte tem como base o droptail, onde os pacotes que
chegarem quando a fila estiver cheia, se ainda não for hora de
liberar o fluxo desta fila serão descartados.
Para que a QUEUE libere o fluxo é necessário preencher o
espaço de 50 slots , o preenchimento deste espaço gera um
delay como no exemplo a seguir.
Criando uma QUEUE de 50Kbit/s, o MTU da interface de
rede continua com 1500bytes multiplicando o MTU pela
quantidade de slots, precisamos de um fluxo de 600Kbit/s para
a liberação do fluxo de dados através da fila, esse mecanismo
geraria um delay de 12 segundos para a liberação do fluxo de
pacotes.
MTU * SLOT
1024
/
QUEUE
12000 * 50 / 1024 = 585.9375 Kb / 50 = 11.71875/seg
É necessário um cuidado extra na hora de criar os
condicionadores
de pacotes para não inserir delays
indesejados.
A disposição dos equipamentos e aconfiguração dos
MÁQUINA
LAPTOP
GATEWAY
MODEM ADSL2+
PROCESSADOR
AMD64 Turion
AMD32 Athlon XP
MIPS32
O ambiente proposto implementa através da máquina
GATEWAY o condicionamento do pacote em filas de
prioridade e faz a marcação dos pacotes usando DSCP, o
modem por sua vez prioriza os pacotes verificando a marcação
DSCP de cada um deles.
Númerando a sequência de passos podemos melhor
visualizar todo o processo.
SEQ.
MAQ.
PROCESSO
1
LAPTOP
Gera um fluxo de dados para determinado
serviço INTERNET(www, smtp, pop).
2
GATEWAY
Identifica este fluxo de dados e classifica.
3
GATEWAY
Condiciona esse fluxo de dados em uma
QUEUE.
4
GATEWAY
Marca os pacotes IP's com o código DSCP.
5
MODEM
Identifica o pacote através do código DSCP.
6
MODEM
Prioriza o envio pelo código DSCP.
Ná pratica teremos uma ADSL de 2Mbps de download e
512Kbps de upload, vamos priorizar alguns serviços conforme
a tabela abaixo.
Serviço
ssh, cvsup,
cvspserver
dns, www
imap, smtp, pop3
All
Peso
50
DiffServ
EF
20
10
5
AF11
AF12
BE
9
Configuramos então na máquina GATEWAY as seguintes
regras no IPFW:
1) Limitamos a nossa banda de upload para não saturar o link.
ipfw pipe 1 config bw 512Kbit/s
2) Configuramos 4 filas com pesos diferenciados para o pipe1.
ipfw queue 40 config weight 5 pipe 1
ipfw queue 30 config weight 50 pipe 1
ipfw queue 20 config weight 20 pipe 1
ipfw queue 10 config weight 10 pipe 1
3) Priorizamos os principais serviços.
ipfw add queue 30 ip from any to any ssh,cvsup,cvspserver
ipfw add dscp EF ip from any to any ssh,cvsup,cvspserver
F. Conclusão
Este trabalho além de apresentar as ténicas existentes no
mercado em aplicação de mecanismos de QoS para criar
ambientes e garantir a qualidade dos serviços prestados em
redes de computadores , mostra também os benefícios que o
software de código aberto proporciona para o
desenvolvimento de tecnologias para um mercado onde o
consumo de Internet demanda cada vez mais qualidade e
garantia de serviços proporcionando um crescimento no
desenvolvimento de novas aplicações, mudando a forma de
como as pessoas interagem usando estes mecanismos e como
as mesmas podem obter novas experiências de acesso.
G. Trabalhos futuros
Apartir deste trabalho, muitos desenvolvedores ao redor do
mundo solicitaram a criação de um evento de ação para o IP
FIREWALL IPFW ao qual deverá englobar
todas as
implementações mostradas neste artigo em um único módulo
chamado de MODIP. O MODIP permitirá que o usuário
através desta ação possa aplicar qualquer um dos mecanismos
citados neste artigo, conforme exemplo a seguir.
4) Diferenciamos alguns erviços.
ipfw add queue 20 ip from any to any 53,80
ipfw add dscp AF11 ip from any to any 53, 80
5) Diferenciamos alguns erviços.
ipfw add queue 10 ip from any to any imap,smtp,pop3
ipfw add dscp AF12 ip from any to any imap,smtp,pop3
6) Deixamos o resto com o melhor esforço.
ipfw add queue 40 ip from any to any
ipfw add dscp BE ip from any to an
ipfw add 10 modip tos:lowdelay ip from any to any
ipfw add 11 modip dscp:af14 ip from any to any
ipfw add 12 modip ippre:flash ip from any to any
Desta forma podemos representar a divisão e classificação
dos serviços acima da seguinte forma.
O patch pode ser acessado em:
http://people.freebsd.org/~araujo/logs/ipfwmodip20080324.diff
IV. REFERENCES
Periodicals:
[1]
[2]
[3]
[4]
Ferguson, Paul, and Huston, Geoff, "Quality of Service Delivering QoS
on the Internet and in Corporate Networks," New York, John Wiley&
Son, 1998
Lee, Donn, "Enhaced IP Services,"Indianapolis, Cisco Press, 1999.
Vegesna, Srinivas, “IP Quality of Service for the Internet and The
Intranets,” Indianapolis, Cisco Press, 2000.
Cisco System, “Implementing Quality of Service Policies with DSCP”,
Feb
15,
2008[Online],
Available:
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note0
9186a00800949f2.shtml
No modem ADSL usamos apenas a identificação do DSCP
para priorizar as classes de serviços conforme a tabela abaixo.
Technical Reports:
Serviço
ssh, cvsup,
cvspserver
dns, www
imap, smtp, pop3
All
Tipo
Prêmio
DiffServ
EF
Ouro
Prata
Bronze
AF11
AF12
BE
[5]
Postel, J., "INTERNET PROTOCOL,", RFC 0791, Darpa Internet
Program., Vriginia, September. 1981.
[6] IETF, "Requirements for Internet Hosts – Communication Layers,",
RFC 1122, Octoberr. 1989
[7] Almquist, P., "Type of Service in the Internet Protocol Suite,", RFC
1349, Consultant.,July. 1992.
[8] Xiao X., Crabbe E. AND Paxson V., "TCP Processing of the IP
Precedence Field,"ACIRI/ICSI.,January. 2000.
[9] Iana, "Differentiated Services Field Codepoints”, Mar.2002[Online],
Available: http://www.iana.org/assignments/dscp-registry
[10] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December.1998.
1
0
[11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W., "An
Architecture for Differentiated Services",RFC 2475, December.1998.
[12] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "Assure Forwarding
PHB Group", RFC 2597, June.1999.
[13] Jacobson, V., Nichols, K., Poduri, K., "An Expedited Forwarding PHB",
RFC 2598, June.1999.
[14] Davie, B., Charny, A., Bennett, J.C.R., Benson, K., Le Boudec, J.Y.,
Courtney, W., Davari, S., Firoiu, V., Stiliadis, D., "An Expedited
Forwarding PHB(Per-Hop Behavior)", RFC 3246, March.2002.
[15] Gorssman, D., "New Terminology and Clarifications for Diffserv", RFC
3260, April.2002.
Papers Presented at Conferences (Unpublished):
[16] Kenjiro Cho, "The Design and Implementation of the ALTQ Traffic
Management System," dissertation, Keio University, January
2001[Online], Available: http://www.sonycsl.co.jp/~kjc/papers.html
[17] Kenjiro Cho, "Managing Traffic with ALTQ," dissertation, USENIX
Annual Technical Conference,June 1999[Online], Available:
http://www.sonycsl.co.jp/~kjc/papers.html
[18] Luigi Rizzo, “Ipfw and dummynet: traffic shaping and network
emulation in FreeBSD”, dissertation , BSD Conference, November
2001[Online],
Available:
http://info.iet.unipi.it/~luigi/bsdcon01/dummynet/
[19] Opperman, A., "FreeBSD 5 Network Enhancements", dissertation,
SUCON04, September .2004.
[20] Opperman, A., "New Networking Features in FreeBSD 6.0",
dissertation, The FreeBSD Project, November .2006.
[21] Opperman, A., "Optimizing the FreeBSD IP and TCP Stack", The
FreeBSD Project, January.2005.
[22] Kennaway, K., "Introducing FreeBSD 7.0", The FreeBSD Project,
November.2007.
Standards:
[23] BSD
Community,
FAQ,
“OpenBSD
Packet
Filter”,
http://www.openbsd.org/faq/pf/
[24] BSD Community, FAQ, “DUMMYNET “, http://www.dummynet.com/