Qualidade de Serviço aplicado a redes IP

Transcrição

1 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. em ordem AF - Assure Forwarding BE - Best Effort BSD - Berkeley Software Distribution CS - Class Selector DSCP - Differentiated Services Field Codepoint EF - Expedite Forwarding IP - Internet Protocol IPFW - IP Firewall PHB - Per-Hop Behavior QoS - Quality of Service RFC - Request For Comments ToS - Type of Service E 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 8 Pair Networks FreeBSD 12 Swishmail FreeBSD 23 WebAir FreeBSD T ab1. Servidores com os maiores uptimes. F 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 2 série 7 o FreeBSD destaca-se pela performance e inovações inseridas novamente na pilha TCP/IP. Rank Position Company Site OS T A 1 DataPipe FreeBSD 10 Aplus FreeBSD 13 Swishmail FreeBSD 22 Pair Network FreeBSD 25 WebAir FreeBSD ab2. Servidor com maior troughput 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 Thu Jun 27 23:02: 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 freebsd-ipfw@freebsd.org e os s gerados por esta pesquisa podem ser vistos em: February/ html February/ html February/ html February/ html February/ html February/ html March/ html March/ html March/ html III. PREPARAÇÃO TÉCNICA DO TRABALHO 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( 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) 2 32 = 4 bilhões de endereços IPv6 (128bits) = 340 decilhões de endereços IPv4 = 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. ToS 2. CoS 3. 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 3 definem a precedência do pacote. /* * Definitions for IP precedence (also in ip_tos) (hopefully * unused). */ #define IPTOS_PREC_NETCONTROL 0xe0 #define IPTOS_PREC_INTERNETCONTROL 0xc0 #define IPTOS_PREC_CRITIC_ECP 0xa0 #define IPTOS_PREC_FLASHOVERRIDE 0x80 #define IPTOS_PREC_FLASH 0x60 #define IPTOS_PREC_IMMEDIATE 0x40 #define IPTOS_PREC_PRIORITY 0x20 #define IPTOS_PREC_ROUTINE 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 : 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 ou 64Kbytes de tamanho de um datagrama. /* maximum packet size */ #define IP_MAXPACKET Identification: Um nùmero de até 16bits que em conjunto com o source address identifica este pacote, usado

4 4 durante o reassembly de fragmentos de datagrama para a remontagem do pacote. 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; /* fragment offset field */ #define IP_RF 0x8000 /* reserved fragment flag */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* 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 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 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. /* * 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. 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 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 PRECEDENCE TOS Field ToS 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 minimize delay maximize throughput maximize reliability minimize monetary cost normal service 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}, }; { "mincost", IPTOS_MINCOST}, { "congestion", IPTOS_CE}, { "ecntransport", IPTOS_ECT}, { "ip tos option", 0}, { NULL, 0 } Podemos verificar que o IPFW esta de acordo com a implementação proposta na RFC 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 Network Control Internetwork Control CRITIC/ECP Flash Override Flash Immediate 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/ Este patch implementa uma nova função chamada de iptospre na interface ipfw com o usuario. ipfw add 10 iptospre immediate ip from /24 to any ipfw add 11 count ip from /24 to any iptospre immediate

6 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. 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. 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 IPTOSPRE BITS CS0 ROUTINE CS1 PRIORITY CS2 IMMEDIATE CS3 FLASH CS4 FLASHOVER CS5 CRITICECP CS6 INTERCONTROL CS7 NETCONTROL 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 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: 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: AF Assure forwarding: A RFC 2597 define um grupo chamado de AF(Assure forwarding) dentro do domínio

7 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. 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 1 Class 2 Class 3 Class 4 Baixa Perda Média Perda Alta Perda AFxy Onde x: Prioridade de transmissão. Onde y: Probabilidade de discarte. DSCP BITS AF AF AF AF AF AF AF AF AF AF AF AF 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(luigi@FreeBSD.org) 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/ Este patch implementa uma nova função chamada de dscp na interface do ipfw com o usuario. ipfw add 10 dscp AF33 ip from /24 to any ipfw add 11 count ip from /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 8 Zhang Hui em 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 * 50 / 1024 = Kb / 50 = /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 Peso DiffServ 50 EF ssh, cvsup, cvspserver dns, www 20 AF11 imap, smtp, pop3 10 AF12 All 5 BE

9 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 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 Desta forma podemos representar a divisão e classificação dos serviços acima da seguinte forma. 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. 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 O patch pode ser acessado em: IV. REFERENCES No modem ADSL usamos apenas a identificação do DSCP para priorizar as classes de serviços conforme a tabela abaixo. Serviço Tipo DiffServ Prêmio EF ssh, cvsup, cvspserver dns, www Ouro AF11 imap, smtp, pop3 Prata AF12 All Bronze BE Periodicals: [1] Ferguson, Paul, and Huston, Geoff, "Quality of Service Delivering QoS on the Internet and in Corporate Networks," New York, John Wiley& Son, 1998 [2] Lee, Donn, "Enhaced IP Services,"Indianapolis, Cisco Press, [3] Vegesna, Srinivas, IP Quality of Service for the Internet and The Intranets, Indianapolis, Cisco Press, [4] Cisco System, Implementing Quality of Service Policies with DSCP, Feb 15, 2008[Online], Available: a f2.shtml Technical Reports: [5] Postel, J., "INTERNET PROTOCOL,", RFC 0791, Darpa Internet Program., Vriginia, September [6] IETF, "Requirements for Internet Hosts Communication Layers,", RFC 1122, Octoberr [7] Almquist, P., "Type of Service in the Internet Protocol Suite,", RFC 1349, Consultant.,July [8] Xiao X., Crabbe E. AND Paxson V., "TCP Processing of the IP Precedence Field,"ACIRI/ICSI.,January [9] Iana, "Differentiated Services Field Codepoints, Mar.2002[Online], Available: [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.

10 [11] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W., "An Architecture for Differentiated Services",RFC 2475, December [12] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "Assure Forwarding PHB Group", RFC 2597, June [13] Jacobson, V., Nichols, K., Poduri, K., "An Expedited Forwarding PHB", RFC 2598, June [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 [15] Gorssman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 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: [17] Kenjiro Cho, "Managing Traffic with ALTQ," dissertation, USENIX Annual Technical Conference,June 1999[Online], Available: [18] Luigi Rizzo, Ipfw and dummynet: traffic shaping and network emulation in FreeBSD, dissertation, BSD Conference, November 2001[Online], Available: [19] Opperman, A., "FreeBSD 5 Network Enhancements", dissertation, SUCON04, September [20] Opperman, A., "New Networking Features in FreeBSD 6.0", dissertation, The FreeBSD Project, November [21] Opperman, A., "Optimizing the FreeBSD IP and TCP Stack", The FreeBSD Project, January [22] Kennaway, K., "Introducing FreeBSD 7.0", The FreeBSD Project, November Standards: [23] BSD Community, FAQ, OpenBSD Packet Filter, [24] BSD Community, FAQ, DUMMYNET,