Implementação de IntServ e DiffServ no NS-2

Implementação de IntServ e DiffServ no NS-2 Eduardo Tavares, Lucas Coelho Lucas Coelho Gonçalves Universidade Federal Fluminense Escola de Engenharia edumt@midiacom.uff.br lucas_coelho@uol.com.br Resumo O serviço proporcionado hoje em dia pela Internet não é adequado para atender à demanda de aplicações avançadas. Estas aplicações somente poderão ser oferecidas com a introdução de Qualidade de Serviço (QoS). Porém, os mecanismos desenvolvidos para a implementação de QoS na Internet como o IntServ e o DiffServ não estão ainda largamente difundidos. Assim, pesquisas referentes ao uso do RSVP em grande escala dependem principalmente de resultados de simulações. Este artigo descreve módulos do software ns-2 [NS] que permitem simulações das arquiteturas IntServ e DiffServ. 1 - Introdução Mais do que interligação de diferentes redes, cada uma com sua arquitetura própria, pensar em Internet atualmente significa visualização de páginas WEB (sejam elas estáticas ou com algum recurso mais dinâmico), e-mail, transações comerciais, videoconferência, ensino à distância, entre outros. Por trás de tudo isso, está a transmissão de diversos tipos de mídia, cada qual com os seus respectivos requisitos para se obter um resultado (apresentação para o usuário final) com qualidade: baixo retardo e baixo jitter (variação desse atraso) para voz e vídeo (mídias contínuas) e perdas nulas para texto. Contudo, essa diversidade de tráfego não existia na concepção da Internet, o que fez com que o protocolo IP não se preocupasse em dar um tratamento diferenciado para os fluxos de tráfego, tratando todos da mesma maneira, transmitindo os dados sem qualquer garantia de sucesso na sua entrega. Tal comportamento apresentado pelo IP é denominado Serviço de Melhor Esforço (Best-Effort Service). Este serviço é aceitável em situações de baixa carga na rede. Todavia, em momentos de congestionamento podetornar-se inaceitável a degradação desse serviço (inserção de atraso, perdas e jitter) oferecido aos tráfegos. Surgiram algumas propostas de implementação de Qualidade de Serviço (QoS) na Internet. Termo este que surgiu com as Telecomunicações e é definido pela ISO como o efeito coletivo de desempenho que determina o grau de satisfação do usuário de um serviço específico [Kamienski,1999]. Ao se implementar QoS, muitos conceitos estão envolvidos, como algoritmos de escalonamento, congestionamento, arquitetura para o provimento de QoS, forma de roteamento, etc. Esse conjunto irá definir qual a melhor forma de se associar uma transmissão de qualidade a um preço acessível ao usuário. Existem várias soluções para fornecer QoS na Internet, dentre elas o IntServ e o DiffServ [Ferguson, 1998]. Essa trabalho, apresentará duas prpostas, no modelo IntServ (Integrated Service) ou Serviços Integrados e o modelo DiffServ (Differentiated

Service) ou Serviços Diferenciados, que se caracteriza pela existência de classes de serviços nos roteadores. O propósito da Arquitetura de Serviços Integrados (IntServ) é fornecer Qualidade de Serviço para aplicações que demandam mais recursos da rede do que o serviço IP de melhor esforço pode oferecer. O Protocolo de Reserva de Recursos (Resource ReSerVation Protocol RSVP [RFC2205]), utilizado na arquitetura IntServ, fornece às aplicações mecanismos de reserva de recursos. O objetivo principal deste trabalho é apresentar o suporte existente no software NS-2 para simulações que utiliza conceitos de QoS baseadps nos modelos IntServ e DiffServ. Apresentamos aqui a implementação do protocolo RSVP [RFC2205] no NS-2 segundo Marc Greis [Greis], denominado RSVP/ns. Descrevemos as características básicas do RSVP/ns bem como algumas diferenças entre o RSVP/ns e a especificação RFC2205 e algumas regras de processamento de mensagem. Em sequida, descrevemos o método de funcionamento do DiffServ com sua respectiva implementação no simulador de redes NS-2. Por fim, apresentamos um exemplo de simulação no NS-2 utilizando o suporte ao DiffServ. 2 IntServ Considerando o contexto atual da Internet, o IETF criou o grupo de trabalho IntServ para viabilizar o surgimento de uma rede de serviços integrados. Os objetivos inicias do grupo IntServ são a criação de um modelo de serviços integrados e de um modelo de referência para sua implementação. Este modelo de qualidade de serviço é caracterizado essencialmente pela reserva de recursos (largura de banda, atraso e jitter), antes do estabelecimento da comunicação. Este serviço utiliza o protocolo de sinalização RSVP. Na sinalização RSVP existe troca de mensagens de controle entre emissor e receptor de forma que num determinado período de tempo possamos alocar uma faixa da largura de banda para a transmissão dos dados. Neste modelo temos alocação para dois tipos de serviços, além do Best Effort : - Serviços Garantidos - aplicações que necessitam de um atraso constante. - Serviços de Carga Controlada aplicações que necessitam de segurança e um limite de variação de atraso (jitter), eliminando a idéia de best effort. 2.1 RSVP O protocolo RSVP é utilizado por um host para solicitar da rede qualidades de serviço específicas que atendam às necessidades de determinadas aplicações de fluxo de dados [RFC2205]. O RSVP também é utilizado por roteadores para atender a estas solicitações, de forma a fornecer qualidade de serviço para todos os nós ao longo do caminho do fluxo de dados, assim como estabelecer e manter informações de estado para o fornecimento adequado do serviço requerido. As solicitações RSVP resultarão na reserva de recursos em cada nó ao longo do caminho dos dados. Algumas características importantes do protocolo RSVP são:??o RSVP faz reservas para aplicações tanto de unidifusão como para multidifusão, se adaptando dinamicamente às alterações dos membros de um grupo ou de rotas; 2

??O RSVP é simplex, ou seja, faz reservas somente para fluxos unidirecionais. Para obter reservas duplex, deve-se solicitar duas reservas simplex distintas nos dois sentidos;??no RSVP quem inicia e mantém reservas para os fluxos é o receptor dos dados. O estado dos reservas no RSVP é leve (soft-state), ou seja, tem um tempo máximo de validade depois do qual ele expira. O receptor constantemente refresca o estado das reservas. Isso permite que ele se adapte automaticamente a alterações no roteamento;??o RSVP não é um protocolo de roteamento. Ele usa as rotas escolhidas por qualquer protocolo de roteamento em uso atualmente ou que venha a ser utilizado no futuro;??o RSVP transporta e mantém informações sobre o controle de tráfego e controle de políticas que são tratadas por outros módulos. O controle de tráfego, no caso, é exercido pelos outros módulos do IntServ;??O RSVP oferece vários estilos de reservas, para se adaptar a uma grande variedade de aplicações e usos;??roteadores que não implementam RSVP podem estar presentes no caminho, que suas mensagens são encaminhadas transparentemente;??o RSVP suporta tanto o IPv4 quanto o IPv6. A qualidade de serviço é implementada por mecanismos chamados controle de tráfego. Estes mecanismos incluem: 1 um classificador de pacotes; 2 controle de admissão; 3 escalonador de pacotes. 2.1.1 Classificador Com a introdução dos parâmetros de QoS [Alves00], foi necessária uma forma de classificação mais específica dos pacotes. Além de analisarmos o endereço do destino, levamos também em consideração a porta e número de protocolo. Poderemos tomar como exemplo uma seqüência de música que seria reconhecida por uma porta particular. Os pacotes são marcados de modo que possamos reservar banda para determinado fluxo. E este vai ser atendido de acordo com sua prioridade de fila dentro do roteador. Quem cuida das prioridades da fila é o escalonador, que implementa algoritmos que selecionam os pacotes que serão atendidos. Isto é claro, ocorre de acordo com a complexidade do algoritmo e marcação dos pacotes. 2.1.2 - Controle de admissão Implementa o algoritmo que um roteador usa para determinar se um novo fluxo pode ter seu pedido de QoS atendido sem interferir nas garantias feitas anteriormente. É algo semelhante ao que ocorre no sistema telefônico, onde nós ouvimos um sinal de ocupado quando o sistema não tem recursos disponíveis para atender a chamada que está sendo feita. Nesse caso, significa que alguns fluxos podem ter seus pedidos de recursos rejeitados por falta de recursos em algum dos roteadores. 2.1.3 Escalonador O papel do escalonador é estabelecer políticas de enfileiramento e prevenção de congestionamento nas interfaces dos roteadores e switches de nível 3 [Alves00], 3

aqueles que também roteiam, para atender as prioridades do fluxo. O escalonador trabalha com algoritmos que fazem tais implementações de acordo com a necessidade de QoS para determinados serviços. O mecanismo mais conhecido é o FIFO First In First Out, onde os pacotes são tratados de acordo com a ordem de chegada. Uma fila FIFO é um mecanismo de repasse, não implementando nenhum tipo de classificação. É fácil percebermos, então, que quando estamos utilizando qualidade de serviço, este tipo de mecanismo não é adequado. Outro algoritmo que também merece ser citado é o WFQ Weighted Fair Queueing, onde é possível ponderar os tipos de fluxo. Isto, é, são associados pesos para determinados tipos de fluxo, também de acordo com as prioridades de cada um. Ele trabalha da seguinte forma: O WFQ coloca para o início da fila o tráfego que tem maior prioridade, reduzindo o tempo de resposta desse fluxo. Ao mesmo tempo, o WFQ compartilha banda com outros fluxos de menores prioridades, porém alocando uma largura de banda menor, já que os de menor prioridade têm também menor peso junto ao WFQ. Este algoritmo se adapta automaticamente às mudanças das condições de tráfego. Podemos também citar o PQ Priority Queueing, onde o tráfego de entrada é classificado em quatro níveis de prioridade: alta, média, baixa e normal. Os pacotes que não são marcados levam configuração default, isto é, são tratados de acordo com a prioridade normal. Neste mecanismo o tráfego classificado e marcado como prioritário tem preferência absoluta em relação aos outros fluxos. Esta é uma das desvantagens do PQ, pois isso pode causar um aumento de jitter e atrasos consideráveis em aplicações de menor prioridade. Numa situação extrema pode acontecer até de um fluxo com menor prioridade nunca chegar a ser enviado, se o fluxo de maior prioridade ocupar toda largura de banda (starvation). Isso ocorre em conexões de baixa velocidade. Outra desvantagem do PQ é que se um fluxo não receber classificação ele pode também não ser enviado. Por isso a necessidade da habilitação de uma fila default, isto é, com prioridade normal. As classificações de um fila PQ podem ser por protocolo (IP, IPX, DecNet, SNA, etc), por interface de entrada ou por lista de acesso. 2.1.4 - Estilos de reserva A reserva no IntServ é orientada ao receptor, ou seja, a requisição de reserva é disparada pelo receptor. O tráfego é reservado somente em uma direção e os recursos são alocados para a entidade que fez a requisição. O RSVP implementa os seguintes estilos de reserva de recurso: - Wildcard Filter (WF) Remetentes não são identificados e compartilham a reserva. É usado, por exemplo, quando várias fontes se comunicarão com um mesmo receptor, mas não simultaneamente, como em uma conferência de áudio onde cada participante fala de uma vez; - Fixed filter (FF) Remetentes são identificados explicitamente com reserva efetuada para cada remetente. Exemplo: dois participantes observados simultaneamente em uma conferência; - Shared-explicit (SE) Remetentes são identificados explicitamente mas compartilham reserva. Exemplo: comutação de canal. 4

2.2 - Suporte do NS-2 ao IntServ O RSVP/ns é uma implementação do RSVP para o simulador de redes NS-2 [NS] desenvolvida por Marc Greis. Os cenários de simulação do RSVP/ns diferem das implementações reais por algumas razões, tais como, limitações impostas pelo ambiente de simulação, além de limitações impostas pelo hardware como memória e CPU. Além disso, certos mecanismos são mais fáceis de implementar em um ambiente de simulação. Um dos objetivos do RSVP/ns era mantê-lo independente do resto do NS tanto quanto possível e não alterar nenhum arquivo do NS a não ser que fosse estritamente necessário, de forma a manter a compatibilidade com as versões antigas do NS. Descrevemos a seguir as principais diferenças entre o RSVP/ns e o RSVP [RFC2205]. Atualmente, apenas os serviços de carga controlada são suportados pelo RSVP/ns. A garantia de largura de banda é implementada com o uso de WFQ (ou WF2Q) nos enlaces. O RSVP/ns inclui as seguintes características: - Garantia de largura de banda de Carga Controlada baseada no escalonador WFQ (ou WF2Q); - Estado de reservas leve com intervalos de refrescamento ajustáveis; - Estilo de reserva FF; - Recolhimento de estatísticas nos links e nós; - Interface para controle de admissão baseada em parâmetros e baseada em medidas; - Uma API simples com chamadas para eventos configuráveis; - A possibilidade de reserva de uma porção da largura de banda do link para as mensagens RSVP afim de evitar a perda de mensagens RSVP; A sinalização do RSVP é realizada através de troca de mensagens. Uma mensagem RSVP consiste em um cabeçalho e um corpo contendo vários objetos. Existem 8 tipos de mensagem RSVP: Path, Resv, PathErr, ResvErr, PathTear, ResvTear e ResvConf. O tipo de mensagem é definido em um campo do cabeçalho RSVP denominado Msg Type. Os objetos contidos no corpo das mensagens são agrupados em classes. Quatorze classes de objetos são definidas na especificação do protocolo, cada uma possuindo um número identificador. Vejamos um exemplo. A mensagem PATH, enviada pelo transmissor, é propagada pelo caminho fim-afim ou de modo multicast, seguindo a rota informada pelos mecanismos de encaminhamento até os receptores. Ela, portanto, descreve o caminho utilizado por um fluxo para atingir seu(s) destino(s), com base em três parâmetros: a identificação do fluxo, a identificação do emissor e descrição do tráfego. Um elemento de rede no caminho dos dados, ao receber um PATH, criará o estado PATH state. As mensagens deste tipo armazenam o estado de cada nó por onde ela transitou. Ela contém as seguintes classes de objeto, com os respectivos campos que os descrevem: Session (endereço e porta de destino), RSVP Hop (interface do enlace de rede anterior), Sender Template e Sender TSpec (emissor e características do fluxo), Time Values (intervalo de refresh do estado de reserva), AdSpec (tipo de serviço e recursos dos enlaces de rede anteriores) e opcionalmente Policy Data (políticas de segurança). 5

A tabala 1 mostra os objetos RSVP que foram implementados no RSVP/ns. Todos estes objetos são compatíveis tanto com Ipv4 quanto Ipv6. Objeto Num da Classe SESSION 1 RSVP HOP 3 TIME VALUES 5 ERROR SPEC 6 STYLE 8 FLOWSPEC 9 FILTER SPEC 10 SENDER 11 TEMPLATE SENDER TSPEC 12 RESV CONFIRM 15 Tabela 1: Objetos RSVP no RSVP/ns Todos os tipos de mensagens foram implementados no RSVP/ns exceto a mensagem PATH error. Esta mensagem notifica explicitamente erros ao longo da transmissão causados por estados que não foram instalados ou por reservas que não foram aceitas. Tais mensagens são transmitidas nó a nó por todos os elementos de rede até a fonte e o destino respectivamente, informando-os do acontecido. Esta menagem não é utilizada pois as notificações são apenas de problemas ocorridos por erros de porta, o que não acontece no NS. Existem algumas diferenças básicas entre os objetivos do RSVP/ns e o RSVP. Alguns campos de objetos, por exemplo, não estão definidos no RSVP/ns. O NS utiliza o conceito de agentes, que são componentes da arquitetura NS responsáveis pela simulação de protocolos, criando um canal de comunicação entre emissor e receptor. O RSVP/ns utiliza um agente RSVP que mantém o estado de reserva em todos os nós RSVP, gera mensagens RSVP e processam mensagens RSVP recebidas. Eles também fornecem a API para o RSVP utilizada nos nós finais. Os enlaces RSVP duplex são baseados em links IntServ duplex ao qual é adicionado um objeto chamado RSVP Checker e uma fila WFQ. O propósito do objeto RSVP Checker é interceptar pacotes RSVP no enlace e encaminhá-los ao agente RSVP no nó destino do enlace. A interação entre o agente RSVP e o objeto RSVP Checker é mostrado na figura 1. 6

2.3 - Como utilizar o RSVP/ns Damos aqui uma breve descrição do processo de instalação e o procedimento necessário para adicionar o RSVP/ns no ns Para instalar o RSVP/ns, o arquivo rsvpns.tar.gz deve ser copiado para o diretório do ns (o diretório que contém o código fonte e o executável do ns). Os arquivos fonte do RSVP/ns devem ser extraídos no diretório do ns. O arquivo nsrsvp.tcl é extraído no diretório tcl/lib. Diversos scripts de exemplo são extraídos no diretório tcl/ex/rsvp. Descrevemos a seguir alguns dos comandos utilzados nos scripts de simulação. Um enlace RSVP entre dois nós n1 e n2 são criados com o comando: ns duplex-rsvp-link <n1> <n2> <bw> <delay> <reservable> <rsvp> <queue> <adc> <est> onde ns é uma instância do simulador. Os outros argumentos são: _ bw : A largura de banda do enlace _ delay : O delay do enlace _ reservable : A porção de largura de banda do enlace que pode ser usada pelo RSVP _ rsvp : A largura de banda utilizada pelas mensagens RSVP _ queue : Tamanho da fila para a classe melhor esforço _ adc : Algoritmo de controle de admissão _ est : Estimativa utilizada pelos algoritmos de controle de admissão baseados em medição Um agente RSVP é adicionado a um nó pelo comando: <node> add-rsvp-agent O exemplo seguinte adiciona um agente RSVP ao nó no : set rsvpagent [$no add-rsvp-agent] Os seguintes commandos são definidos no RSVP/ns: _ Criar sessão: <rsvp-agent> session <destination> <flow-id> _ Liberar sessão: <rsvp-agent> release <session-id> _ Enviar mensagem de caminho <rsvp-agent> sender <session-id> <rate> <bucket> <ttl> _ Reservar largura de banda <rsvp-agent> reserve <session-id> <style> <flow descriptor list> _ Enviar um objeto RESV CONFIRM na próxima mensagem de reserva <rsvp-agent> confirm <session-id> 7

_ Obter a lista de todas as sessões em um agente <rsvp-agent> sessions _ Definir um valor de estado para uma sessão <rsvp-agent> set-status <session-id> <value> _ Obter um valor de estado de uma sessão <rsvp-agent> get-status <session-id> _ Definir um manipulador de objeto para uma sessão <rsvp-agent> set-handle <session-id> <object> _ Obter um manipulador de objeto de uma sessão <rsvp-agent> get-handle <session-id> 3 - DiffServ DiffServ [RFC2475], é um modelo de implementação de QoS em redes de computadores, criado pelo IETF, que trabalha com o conceito de classes de serviço e visa agrupar fluxos de tráfego semelhantes em uma mesma classe. Esse modelo possui boa escalabilidade, tornando possível o tratamento de uma grande quantidade de fluxos, por possuir uma baixa granularidade, em provedores backbone. Dessa forma, supre uma das principais deficiências do modelo IntServ (Integrated Services) que, ao tratar fluxos individuais, torna-se inviável em um backbone, devido a alta carga de sinalização. No Diffserv o tratamento passa a ser baseado em agrupamentos de fluxos, e não em fluxos individuais, o que gera menor carga de sinalização, pois os roteadores tratam grupos de fluxos em vez de fluxos individuais. No entanto, perde-se em eficiência na alocação de recursos, pois o fluxo mais exigente é quem determinará os recursos a serem reservados para toda a classe. Em uma solicitação de Serviço Diferenciado, um contrato deve ser estabelecido entre usuário e provedor. Nesse contrato, chamado de SLA (Service Level Agreement), o usuário compromete-se a gerar um fluxo com as características dispostas no contrato e o provedor compromete-se a encaminhá-lo com a QoS solicitada pelo usuário. Os SLAs são na sua grande maioria estáticos, ou seja, a configuração é feita manualmente, o que não acarreta em sérios problemas na sua administração, visto que, aqui, os contratos possuem um tempo de vida maior do que aqueles feitos no Intserv, onde para cada novo fluxo é criado um SLA. 3.1 Domínio Diffserv Um domínio diffserv consiste de um conjunto de nós de uma rede que possuem PHBs implementados em cada nó. Cada domínio possui dois tipos de nós: - nós de borda: possui as funções de classificação e marcação dos pacotes e condicionamento do trafego. Mais especificamente, o campo Differenciated Service (DS) do cabeçalho do pacote é estabelecido em um determinado valor. É através dele que um domínio diffserv se conecta a outros domínios diffserv ou a outros domínios quaisquer. 8

- nós de núcleo: conectam-se somente a outros nós de núcleo ou a um nó de borda dentro do mesmo domínio diffserv. Eles atuam sobre os pacotes de acordo com a classificação dada ao pacote pelos nós de borda. Figura1: Domínio Diffserv 3.2 Classificação e condicionamento de tráfego Na arquitetura de serviços diferenciados, a marca de um pacote é transportada dentro do campo DS do cabeçalho do pacote IPv4 ou IPv6. A definição do campo DS substitui as definições do campo ToS(Type of Service) do IPv4 e do campo classe de tráfego do IPv6. Um pacote é marcado pela determinação do valor de seu campo diffserv na borda da rede. Os pacotes que chegam ao roteador de borda são primeiramente classificados. O classificador seleciona os pacotes com base nos valores de um ou mais campos de cabeçalho (por exemplo, endereço da fonte, endereço de destino, porta da fonte, porta do destino e protocolo IP) e dirige o pacote à função de marcação apropriada. O valor do campo DS é, então, estabelecido no marcador, de acordo com a classificação. Assim que os pacotes estiverem marcados, eles são repassados ao longo de sua rota até o destino. Em cada roteador subseqüente habilitado à arquitetura diffserv, os pacotes marcados recebem o serviço associado às suas marcações. 3.3 Comportamento por salto (PHB - Per Hop Behavior) O que caracteriza a forma de encaminhamento dos pacotes é o chamado PHB (Per Hop Behavior). O PHB descreve como será realizado o encaminhamento dos pacotes pertencentes a uma mesma classe de serviço. Ele, diferentemente do IntServ, não padroniza serviços, apenas especifica comportamentos de encaminhamento. Essa não padronização permite que os usuários possam escolher entre provedores que lhe forneçam melhores vantagens. A combinação de PHBs com os parâmetros de caracterização do SLA é que define o serviço a ser fornecido pelo provedor Diffserv. Existem, atualmente, dois PHBs padronizados, o EF (Expedited Forwarding) ou encaminhamento expresso [RFC2598] e o AF (Assured Forwarding) ou encaminhamento assegurado [RFC2597]. O EF é caracterizado por baixos retardo e variação do mesmo, taxa de erros controlada e largura de banda assegurada. É ideal para aplicações que necessitam de rapidez, constância na sua transmissão, com pouco ou nenhum erro, como por exemplo, Telemedicina e telefonia na Internet. Este tipo de PHB especifica que a taxa de partida de uma classe de tráfego de um roteador deve ser igual ou maior que uma taxa configurada. Durante qualquer intervalo de tempo, fica garantido que a classe de tráfego receba largura de banda suficiente de modo que a taxa de saída do tráfego seja 9

igual ou maior do que essa taxa mínima configurada. A EF fornece uma abstração simples de um enlace com largura de banda mínima garantida. O AF possui, na realidade, níveis distintos de tráfego com níveis variáveis de probabilidade de perda. São quatro as classes AF definidas, com até três níveis de precedência de perda em cada uma. Nesse PHB, não há uma garantia estrita na entrega dos pacotes, o que há é uma garantia de que pacotes marcados como conformes são entregues com alta probabilidade, enquanto que os que excederem a taxa especificada no contrato recebem uma probabilidade de descarte maior, podendo assim, serem mais facilmente descartados em momentos de congestionamento. 3.4 Controle de tráfego Em uma tecnologia que implementa QoS, é necessário um amplo controle sobre os fluxos que circulam na rede. É preciso que, usuários que solicitam uma determinada garantia nos seus dados, possam ser atendidos sem um mínimo de comprometimento. Para isso, são necessários algoritmos que tanto controlem os congestionamentos como também diferenciem os tráfegos existentes. Um algoritmo muito conhecido e amplamente usado em implementações Diffserv é o CBQ (Class-Based Queuing). O CBQ é caracterizado por criar classes de uma forma hierárquica onde um certo percentual de banda é fornecido a cada uma. Ele dispõe de dois escalonadores com o objetivo de garantir aos fluxos de tempo real baixos valores de atraso nas filas de espera e ao mesmo tempo a não monopolização por parte deste enlace. O CBQ visa, ainda, para um maior aproveitamento do enlace, a possibilidade de classes utilizarem um percentual de largura de banda maior do que o fornecido a elas, desde que não prejudiquem o fluxo de outras classes. Outro modelo de controle de tráfego existente é o TBF (Token Bucket Filter). Ele implementa um duplo token bucket para o controle da vazão média e da vazão de pico. Seu principal objetivo é atrasar os pacotes que excedam uma determinada especificação e não simplesmente descartá-los. Dentre os diversos parâmetros que podem ser ajustados estão: O rate que especifica a vazão média, o burst que diz a profundidade do token bucket principal, o peakrate que ativa o outro token bucket (o de pico) e assim, especifica um valor médio, dentre outros. Uma terceira forma para controle de tráfego é a utilização do algoritmo RED (Random Early Detection) que se aproveita dos mecanismos de controle de congestionamento do protocolo de transporte TCP, o qual diminui a taxa de transmissão em vista de perdas de pacotes. O algoritmo RED tem como função a redução do tamanho médio das filas de espera nos roteadores. Esse comprimento é calculado freqüentemente. Se este exceder um valor mínimo determinado, é dada uma certa probabilidade de descarte aos pacotes que chegam ao nó. À medida que aumentar este excedente, a probabilidade de perda de pacotes também aumentará. Sempre que o comprimento médio ultrapassar um valor máximo todos os pacotes serão descartados. Esse mecanismo promove uma distribuição justa das perdas (tráfegos mais agressivos serão mais prejudicados) e procura evitar o efeito de sincronização global. No entanto, equidade na distribuição dessas perdas não é o propósito dos Serviços Diferenciados. Pelo contrário, algumas classes de tráfego devem ser penalizadas em função de outras. Por isso, um outro algoritmo pertencente ainda à família RED é usado na implementação do PHB AF, denominado GRED (Generalized RED). Sua principal diferença em relação ao RED é a existência de várias filas virtuais, cada uma associada ao mesmo conjunto de parâmetros que a fila RED, com a adição de 10

outro parâmetro: prioridade relativa das filas. Dessa forma, diferentes níveis de precedência de descarte podem ser configurados. 3.5 Implementação do diffserv no NS-2 Com o intuito de implementar a arquitetura diffserv no NS, cinco módulos foram adicionados na estrutura do simulador para implementar as funcionalidades de roteamento diffserv, tanto de borda quanto de núcleo e também um para o monitoramento das filas e um para o policiamento do tráfego. O módulo dsred define a classe dsredqueue, que por sua vez define duas subclasses: edgequeue, que trata das filas dos roteadores de borda, e corequeue, que trata das filas dos roteadores de núcleo. Essas duas subclasses implementam todas as funcionalidades e declaram todos os parâmetros que são comuns aos roteadores diffserv de borda e de núcleo. fila física 3 filas virtuais por fila física figura 2 dsredqueue A estrutura de fila dsred consiste de quatro filas físicas, cada uma contendo três filas filas virtuais (RED), referenciadas como níveis de precedência (vide figura 2). Cada fila virtual corresponde a uma classe de tráfego, e cada combinação de uma fila e um número de precedência é associado a um código (DiffServ Code Point - DSCP), que corresponde a uma preferência de descarte. Os pacotes são enfileirados de acordo com os parâmetros correspondentes a uma determinada fila e número de precedência, assim sendo, o DSCP especifica um certo nível de serviço. Nem todas as filas, físicas ou virtuais, precisam ser usadas. O usuário pode configurar, descrevendo no script Tcl, um número menor de filas. Os comandos de configuração a seguir aplicam-se às descrições das filas dos roteadores de borda e de núcleo. Abaixo se encontram algumas variáveis de configuração dos parâmetros da classe dsredqueue. A variável numqueues_ determina o número de filas físicas do nó. A variável setnumprec estabelece o número de filas virtuais dentro de cada fila física. Elas podem ser descritas como abaixo: $dsredq set numqueues_ 1 11

$dsredq setnumprec 2 Os números de filas físicas e virtuais são limitados por constantes dentro do arquivo de configuração dsred.h, e não devem ser ultrapassados. Nenhuma checagem de erro é feita sobre a variável numqueues_; seu valor padrão é 4 e assume-se que o usuário não ultrapassará esse valor. Cada fila física possui um valor padrão de 3 filas virtuais. $dsredq configq 0 1 10 20 0.10 O comando acima configura os parâmetros RED para uma fila virtual. O exemplo acima especifica que a fila física 0, fila virtual 1, possui um valor mínimo de threshold de 10, um valor máximo de threshold de 20 e um valor máximo de pb(parâmetro de configuração do algoritmo de implementação da fila, que representa uma probabilidade) igual a 0,10. Geralmente adota-se a linha acima como um padrão para a configuração das filas. A classe dsredqueue contém uma estrutura de dados conhecida como tabela PHB. Dispositivos de borda lidam com marcação dos pacotes e os dispositivos de núcleos simplesmente respondem de determinada maneira a cada um dos códigos. O mapeamento da tabela PHB é feito pela definição de um vetor com três campos: - Código - Classe (fila física) - Precedência (fila virtual) $dsredq addphbentry 11 0 1 O comando addphbentry adiciona uma entrada à tabela PHB. No exemplo acima, o código 11 é mapeado para a fila física 0 e fila virtual 1. No NS os pacotes são padronizados para o código 0. Portanto o usuário deve adicionar uma entrada PHB para o código 0. $dsredq meanpktsize 1500 Este comando especifica o tamanho médio do pacote(em bytes). Além disso, há comandos que permitem escolher o modo de escalonamento entre as filas físicas. $dsredq setschedularmode WRR $dsredq addqueueweights 1 5 O par de comandos acima estabelece o modo de escalonamento Weighted Round Robin e estabelece o peso 1 para a fila 5. Outros métodos de escalonamento suportados são Weighted Interleaved Round Robin (WIRR), Round Robin (RR), e por prioridade (Priority-PRI). O escalonamento padrão é o Round Robin. O arranjo do escalonamento por prioridade é feito de modo seqüencial, tendo 0 como a mais alta prioridade. Também podemos limitar a largura de banda que uma fila pode ocupar usando o comando addqueuerate. $dsredq setschedularmode PRI 12

$dsredq addqueuerate 0 5000000 Neste exemplo definimos o escalonamento por prioridade e limitamos a largura de banda da fila 0 para 5Mbps. 3.5.1 Políticas de tratamento O módulo de políticas lida com a criação, manipulação e aplicação das políticas dos roteadores de borda. A política determina que tratamento que um fluxo agregado receberá no dispositivo de borda. Os dispositivos de borda usam a informação das políticas para determinar com que código os pacotes serão marcados. O NS usa uma tabela de políticas para armazenar as políticas de cada fluxo agregado. Alguns dos campos da tabela de políticas são:??id da fonte??id do destino??tipo de policiador??tipo do medidor??código inicial??cir (committed information rate)??cbs (committed burst size)??ebs (excess burst size)??pir (peak information rate)??pbs (peak burst size)??taxa média de envio Uma política é estabelecida entre um nó fonte e um nó de destino. Todos os fluxos com códigos idênticos de cada par fonte-destino são tratados como um único fluxo agregado. Cada política define um classificador, uma taxa de envio e outros parâmetros específicos de cada classificador. O módulo de políticas do NS suporta seis tipos de classificadores: TSW2CM (TSW2CMPolicer): usa CIR e possui duas precedências de descarte. A precedência mais baixa é usada quando a CIR é excedida. TSW3CM (TSW3CMPolicer): usa CIR, PIR e possui três precedências de descarte. A precedência do meio é usada quando a CIR é excedida e a precedência mais baixa quando a PIR é excedida. Token Bucket (tokenbucketpolicer): usa CIR, CBS e duas precedências de descarte. Single Rate Three Color Marker (srtcmpolicer): usa CIR, CBS e uma EBS para escolher entre três precedências de descarte. Two Rate Three Color Marker (trtcmpolicer): usa CIR, CBS, PIR e uma PBS para escolher entre três precedências de descarte. Null: não há classificação dos fluxos em níveis de descarte. 13

O comando addpolicyentry é usado para adicionar uma entrada na tabela de políticas. Diferentes parâmetros podem ser referenciados dependendo do classificador usado. Os seguintes parâmetros estão relacionados aos classificadores:??tsw2cm código inicial CIR??TSW3CM código inicial CIR PIR??TokenBucket código inicial CIR CBS??srTCM código inicial CIR CBS EBS??trTCM código inicial CIR CBS PIR PBS A CIR e a PIR são especificadas em bits por segundo. CBS, EBS e PBS são especificadas em bytes. Considere um script Tcl onde $q é uma variável de uma fila de um roteador de borda, e $s e $d são nós fonte e destino. O seguinte comando adiciona um classificador TSW2CM para o tráfego da fonte para o destino: $q addpolicyentry [$s id] [$d id] TSW2CM 10 2000000 O seguinte comando adiciona uma entrada a tabela de classificadores, especificando que o código inicial do classificador trtcm é 10, seguido da precedência intermediária 11 e a precedência mais baixa 12. $dsredq addpolicerentry trtcm 10 11 12 Deve haver uma entrada na tabela de classificadores para cada par tipo de classificador/código inicial. 3.5.2 Exemplo de simulação A topologia desta simulação possui 13 nós. Temos um nó transmissor, o nó 0, qua atuará transmitindo dados para o nó 1, o nó 2 e o nó 3, que aturão como receptores. Este tráfego, que sai do nó 0, é o tráfego de mais alta prioridade na rede. O nó 4, é o nó que define a entrada na rede diffserv. Os nós 5, 6, e 7 são os nós de saída da rede para os receptores 1, 2 e 3 respectivamente. Os nós 8, 9 e 10 fazem parte do núcleo da rede diffserv. Por ele também circularão pacotes e mais baixa prioridade vindo de diversos pontos da rede. Nesses nós podemos observar a priorização dos pacotes originados no nó 1 e marcados na entrada da rede com alta prioridade. Os nós 11, 12 e 13 geram tráfego de baixa prioridade para os receptores 1, 2 e 3 respectivamente. No tempo inicial apenas os tráfego de baixa prioridade circula na rede. Neste primeiro momento nós temos, no nó 11, uma aplicação CBR utilizando um agente UDP para transmitir dados para o receptor 1. Temos ainda o nó 12, um aplicação CBR utilizando um agente UDP para transmitir dados ao receptor 3 e temos também uma aplicação exponencial utilizando um agente UDP para transmitir dados ao receptor 3. No nó 13 temos uma aplicação exponencial utilizando um agente UDP para transmitir dados ao receptor3 e uma aplicação NewReno utilizando um agente TCP para transmitir dados ao receptor 3. 14

Figura 3 Tráfego de baixa prioridade circulando pela rede No tempo t=2,0s o transmissor começa a enviar dados para os receptores 1, 2 e 3. A partir daí podemos verificar. A partir daí nós verificamos a formação de filas nos roteadores de núcleo(nós 8, 9 e 10). É possível também observar algumas perdas de pacotes de baixa prioridade chega tráfego de altra prioridade nos roteadores. Figura 4 aparecimento de filas e perdas de pacotes devido ao tráfego de maior prioridade 15

4 Conclusão Este trabalho tem por objetivo o suporte à simulações que usam qualidade de serviço por meio dos modelos Intserv e Diffserv no simulador NS-2. Uma variedade de serviços e cenários podem ser obtidos através das simulações, mas para a geração de cenários mais específicos e detalhados é preciso um conhecimento mais profundo de cada módulo de simulação e das variáveis de cada módulo, sendo necessário às vezes uma alteração no código fonte para que a simulação atenda aos resultados desejados. Com o que já existe implementado atualmente, é possível obtermos resultados confiáveis para análise do comportamento das redes Intserv e Diffserv. O NS-2 oferece uma liberdade muito grande no que diz respeito à simulação dos ambientes de rede, porém a simulação se torna mais difícil quando é necessária a criação de um módulo adicional ao NS-2. As especificações estabelecinas IETF não estão integralmente implementadas. Muitas contribuições são feitas e ajudam na melhoria e dos ambientes de simulações. É sempre necessário a validação dos dados obtidos dos resultados das simulações pois o simulado ainda possui diversas limitações. 16

5 - Bibliografia [Alves00] Júnior, Nilton Alves, Kelly Soyan Pires Dominguez MODELOS DE QUALIDADE DESERVIÇO - APLICAÇÕES EM IP, dezembro de 2000 [Greis] Greis, Marc, RSVP/ns: An Implementation of RSVP for the Network Simulator ns-2 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., Resource ReSerVation Protocol (RSVP) { Version 1 Functional Specication", RFC 2205, September 1997 [RFC2209] Braden, R., Zhang, L., Resource ReSerVation Protocol (RSVP) { Version 1 Message Processing Rules", RFC 2209, September 1997 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W. Architecture for Differentiated Services, 1998. [RFC2597] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., Assured Forwarding PHB Group, RFC 2597, June 1999. [RFC2598] Jacobson, V., Poduri, K., An Expedited Forwarding PHB, RFC 2598, June 1999 [Kamienski,1999] Kamienski, C. A. Qualidade de Serviço na Internet. Centro Federal de Educação Tecnológica da Bahia. Disponível em <http://www.cin.ufpe.br/~cak/publications/ kamienski-qos-eine- 99.pdf> [Ferguson, 1998] Ferguson, P., Huston, G. Quality of Service: Delivering QoS on the Internet and in Corporate Networks, 1998. Wiley Computer Publishing. [NS] http://www.isi.edu/nsnam/ns/ Kurose, James F.; Ross, Keith W., Redes de computadores e a internet. Addisonwesley Publi 17

ANEXO A # Topologia # 10Mbps 10Mbps 100Mbps # +---------------Nucleo1------------------BordaSaida1----------Receptor1 # # Trafegobackgroung1 # 100Mbps 10Mbps 10Mbps 100Mbps # Transmissor-----------BordaEntrada---------Nucleo2------------------BordaSaida2----------Receptor2 # (5ms) # Trafegobackgroung2 # 10Mbps 10Mbps 100Mbps # +---------------Nucleo3------------------BordaSaida3----------Receptor3 # # Trafegobackgorund3 set ns [new Simulator] set cir0 1000000 set rate0 8000000 set testtime 20.0 set packetsize 1000 # >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> #Definicao das cores para identificar os fluxos de dados $ns color 1 Blue $ns color 2 Red $ns color 3 yellow $ns color 4 green $ns color 5 black $ns color 6 pink $ns color 7 white #Arquivo de Trace set f [open CTCQoS.tr w] $ns trace-all $f #Arquivo de Trace do NAM set nf [open out.nam w] $ns namtrace-all $nf # >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> # ------------ Criacao da topologia da rede (inicio) set receptor1 [$ns node] set receptor2 [$ns node] set receptor3 [$ns node] set bordain [$ns node] set bordaout1 [$ns node] set bordaout2 [$ns node] set bordaout3 [$ns node] set nucleo1 [$ns node] set nucleo2 [$ns node] set nucleo3 [$ns node] # Nos criados para enviar trafego de background set trafbg1 [$ns node] set trafbg2 [$ns node] set trafbg3 [$ns node] #Links $ns duplex-link $transmissor $bordain 100Mb 5ms DropTail $ns duplex-link $bordaout1 $receptor1 100Mb 5ms DropTail $ns duplex-link $bordaout2 $receptor2 100Mb 5ms DropTail $ns duplex-link $bordaout3 $receptor3 100Mb 5ms DropTail $ns simplex-link $bordain $nucleo1 10Mb 5ms dsred/edge $ns simplex-link $nucleo1 $bordain 10Mb 5ms dsred/core $ns simplex-link $bordain $nucleo2 10Mb 5ms dsred/edge $ns simplex-link $nucleo2 $bordain 10Mb 5ms dsred/core 18

$ns simplex-link $bordain $nucleo3 10Mb 5ms dsred/edge $ns simplex-link $nucleo3 $bordain 10Mb 5ms dsred/core $ns simplex-link $nucleo1 $bordaout1 10Mb 5ms dsred/core $ns simplex-link $bordaout1 $nucleo1 10Mb 5ms dsred/edge $ns simplex-link $nucleo2 $bordaout2 10Mb 5ms dsred/core $ns simplex-link $bordaout2 $nucleo2 10Mb 5ms dsred/edge $ns simplex-link $nucleo3 $bordaout3 10Mb 5ms dsred/core $ns simplex-link $bordaout3 $nucleo3 10Mb 5ms dsred/edge $ns simplex-link $trafbg1 $nucleo1 10Mb 5ms dsred/edge $ns simplex-link $nucleo1 $trafbg1 10Mb 5ms dsred/core $ns simplex-link $trafbg2 $nucleo2 10Mb 5ms dsred/edge $ns simplex-link $nucleo2 $trafbg2 10Mb 5ms dsred/core $ns simplex-link $trafbg3 $nucleo3 10Mb 5ms dsred/edge $ns simplex-link $nucleo3 $trafbg3 10Mb 5ms dsred/core # Obs.Os links de QoS precisam ser simplex por isso vao e voltam #Orientacao para o desenho da topologia no NAM (opcional) #$ns duplex-link-op $transmissor $bordain orient up-right #$ns simplex-link-op $bordain $nucleo1 orient up -right #$ns simplex-link-op $bordain $nucleo2 orient right #$ns simplex-link-op $bordain $nucleo3 orient down-right #$ns simplex-link-op $nucleo1 $bordaout1 orient right #$ns simplex-link-op $nucleo2 $bordaout2 orient right #$ns simplex-link-op $nucleo3 $bordaout3 orient right #$ns simplex-link-op $trafbg1 $nucleo1 orient up-left #$ns simplex-link-op $trafbg2 $nucleo2 orient up-left #$ns simplex-link-op $trafbg3 $nucleo3 orient down-left #$ns simplex-link-op $bordaout1 $receptor1 orient right #$ns simplex-link-op $bordaout2 $receptor2 orient right #$ns simplex-link-op $bordaout3 $receptor3 orient right #Identificacao das filas a serem monitoradas pelo NAM $ns simplex-link-op $nucleo1 $bordaout1 queuepos 0.5 $ns simplex-link-op $nucleo2 $bordaout2 queuepos 0.5 $ns simplex-link-op $nucleo3 $bordaout3 queuepos 0.5 # ------------ Criacao da topologia da rede (fim) # Criacao das Filas set qbinn1 [[$ns link $bordain $nucleo1] queue] set qbinn2 [[$ns link $bordain $nucleo2] queue] set qbinn3 [[$ns link $bordain $nucleo3] queue] # set qn1bin [[$ns link $nucleo1 $bordain] queue] set qn2bin [[$ns link $nucleo2 $bordain] queue] set qn3bin [[$ns link $nucleo3 $bordain] queue] # set qn1bout1 [[$ns link $nucleo1 $bordaout1] queue] set qn2bout2 [[$ns link $nucleo2 $bordaout2] queue] set qn3bout3 [[$ns link $nucleo3 $bordaout3] queue] # set qbout1n1 [[$ns link $bordaout1 $nucleo1] queue] set qbout2n2 [[$ns link $bordaout2 $nucleo2] queue] set qbout3n3 [[$ns link $bordaout3 $nucleo3] queue] set qbout3bn3 [[$ns link $bordaout3 $nucleo3] queue] # set qtb1n1 [[$ns link $trafbg1 $nucleo1] queue] set qtb2n2 [[$ns link $trafbg2 $nucleo2] queue] set qtb3n3 [[$ns link $trafbg3 $nucleo3] queue] set qn1tb1 [[$ns link $nucleo1 $trafbg1] queue] set qn2tb2 [[$ns link $nucleo2 $trafbg2] queue] set qn3tb3 [[$ns link $nucleo3 $trafbg3] queue] # P O L I T I C A S & P H B 's ============= $qbinn1 meanpktsize $packetsize $qbinn1 set numqueues_ 2 $qbinn1 setnumprec 1 $qbinn1 addpolicyentry [$transmissor id] [$receptor1 id] TSW2CM 10 $cir0 $qbinn1 addpolicerentry TSW 2CM 10 10 $qbinn1 configq 0 0 20 40 0.02 19

$qbinn1 configq 1 0 10 20 0.10 $qbinn1 addphbentry 10 0 0 $qbinn1 addphbentry 0 1 0 $qbout1n1 meanpktsize $packetsize $qbout1n1 set numqueues_ 2 $qbout1n1 setnumprec 1 $qbout1n1 addpolicyentry [$receptor1 id] [$transmissor id] TSW2CM 0 $cir0 $qbout1n1 addpolicerentry TSW2CM 0 0 $qbout1n1 configq 0 0 20 40 0.02 $qbout1n1 configq 1 0 10 20 0.10 $qbout1n1 addphbentry 10 0 0 $qbout1n1 addphbentry 0 1 0 $qbinn2 meanpktsize $packetsize $qbinn2 set numqueues_ 2 $qbinn2 setnumprec 1 $qbinn2 addpolicyentry [$transmissor id] [$receptor2 id] TSW2CM 10 $cir0 $qbinn2 addpolicerentry TSW2CM 10 10 $qbinn2 configq 0 0 20 40 0.02 $qbinn2 configq 1 0 10 20 0.10 $qbinn2 addphbentry 10 0 0 $qbinn2 addphbentry 0 1 0 $qbout2n2 meanpktsize $packetsize $qbout2n2 set numqueues_ 2 $qbout2n2 setnumprec 1 $qbout2n2 addpolicyentry [$receptor2 id] [$transmissor id] TSW2CM 0 $cir0 $qbout2n2 addpolicerentry TSW2CM 0 0 $qbout2n2 configq 0 0 20 40 0.02 $qbout2n2 configq 1 0 10 20 0.10 $qbout2n2 addphbentry 10 0 0 $qbout2n2 addphbentry 0 1 0 $qbinn3 meanpktsize $packetsize $qbinn3 set numqueues_ 2 $qbinn3 setnumprec 1 $qbinn3 addpolicyentry [$transmissor id] [$receptor3 id] TSW2CM 10 $cir0 $qbinn3 addpolicerentry TSW2CM 10 10 $qbinn3 configq 0 0 20 40 0.02 $qbinn3 configq 1 0 10 20 0.10 $qbinn3 addphbentry 10 0 0 $qbinn3 addphbentry 0 1 0 $qbout3n3 meanpktsize $packetsize $qbout3n3 set numqueues_ 2 $qbout3n3 setnumprec 1 $qbout3n3 addpolicyentry [$receptor3 id] [$transmissor id] TSW2CM 0 $cir0 $qbout 3N3 addpolicerentry TSW2CM 0 0 $qbout3n3 configq 0 0 20 40 0.02 $qbout3n3 configq 1 0 10 20 0.10 $qbout3n3 addphbentry 10 0 0 $qbout3n3 addphbentry 0 1 0 $qbout3bn3 meanpktsize $packetsize $qbout3bn3 set numqueues_ 2 $qbout3bn3 setnumprec 1 $qbout3bn3 addpolicyentry [$receptor3 id] [$trafbg3 id] TSW2CM 0 $cir0 $qbout3bn3 addpolicerentry TSW2CM 0 0 $qbout3bn3 configq 0 0 20 40 0.02 $qbout3bn3 configq 1 0 10 20 0.10 $qbout3bn3 addphbentry 10 0 0 $qbout3bn3 addphbentry 0 1 0 $qtb1n1 meanpktsize $packetsize $qtb1n1 set numqueues_ 2 $qtb1n1 setnumprec 1 $qtb1n1 addpolicyentry [$trafbg1 id] [$receptor1 id] TSW2CM 0 $cir0 $qtb1n1 addpolicerentry TSW2CM 0 0 $qtb1n1 configq 0 0 20 40 0.02 $qtb1n1 configq 1 0 10 20 0.10 $qtb1n1 addphbentry 10 0 0 $qtb1n1 addphbentry 0 1 0 $qtb2n2 meanpktsize $packetsize $qtb2n2 set numqueues_ 2 20

$qtb2n2 setnumprec 1 $qtb2n2 addpolicyentry [$trafbg2 id] [$receptor2 id] TSW2CM 0 $cir0 $qtb2n2 addpolicerentry TSW2CM 0 0 $qtb2n2 configq 0 0 20 40 0.02 $qtb2n2 configq 1 0 10 20 0.10 $qtb2n2 addphbentry 10 0 0 $qtb2n2 addphbentry 0 1 0 $qtb3n3 meanpktsize $packetsize $qtb3n3 set numqueues_ 2 $qtb3n3 setnumprec 1 $qtb3n3 addpolicyentry [$trafbg3 id] [$receptor3 id] TSW2CM 0 $cir0 $qtb3n3 addpolicerentry TSW2CM 0 0 $qtb3n3 configq 0 0 20 40 0.02 $qtb3n3 configq 1 0 10 20 0.10 $qtb3n3 addphbentry 10 0 0 $qtb3n3 addphbentry 0 1 0 $qn1bout1 setschedularmode WRR $qn1bout1 addqueueweights 0 8 $qn1bout1 addqueueweights 1 2 $qn1bout1 meanpktsize $packetsize $qn1bout1 set numqueues_ 2 $qn1bout1 setnumprec 1 $qn1bout1 addphbentry 10 0 0 $qn1bout1 addphbentry 0 1 0 $qn1bout1 configq 0 0 20 40 0.02 $qn1bout1 configq 1 0 10 20 0.10 $qn2bout2 setschedularmode WRR $qn2bout2 addqueueweights 0 8 $qn2bout2 addqueueweights 1 2 $qn2bout2 meanpktsize $packetsize $qn2bout2 set numqueues_ 2 $qn2bout2 setnumprec 1 $qn2bout2 addphbentry 10 0 0 $qn2bout2 addphbentry 0 1 0 $qn2bout2 configq 0 0 20 40 0.02 $qn2bout2 configq 1 0 10 20 0.10 $qn3bout3 setschedularmode WRR $qn3bout3 addqueueweights 0 8 $qn3bout3 addqueueweights 1 2 $qn3bout3 meanpktsize $packetsize $qn3bout3 set numqueues_ 2 $qn3bout3 setnumprec 1 $qn3bout3 addphbentry 10 0 0 $qn3bout3 addphbentry 0 1 0 $qn3bout3 configq 0 0 20 40 0.02 $qn3bout3 configq 1 0 10 20 0.10 $qn1bin setschedularmode WRR $qn1bin addqueueweights 0 8 $qn1bin addqueueweights 1 2 $qn1bin meanpktsize $packetsize $qn1bin set numqueues_ 2 $qn1bin setnumprec 1 $qn1bin addphbentry 10 0 0 $qn1bin addphbentry 0 1 0 $qn1bin configq 0 0 20 40 0.02 $qn1bin configq 1 0 10 20 0.10 $qn2bin setschedularmode WRR $qn2bin addqueueweights 0 8 $qn2bin addqueueweights 1 2 $qn2bin meanpktsize $packetsize $qn2bin set numqueues_ 2 $qn2bin setnumprec 1 $qn2bin addphbentry 10 0 0 $qn2bin addphbentry 0 1 0 $qn2bin configq 0 0 20 40 0.02 $qn2bin configq 1 0 10 20 0.10 $qn3bin setschedularmode WRR $qn3bin addqueueweights 0 8 $qn3bin addqueueweights 1 2 21

$qn3bin meanpktsize $packetsize $qn3bin set numqueues_ 2 $qn3bin setnumprec 1 $qn3bin addphbentry 10 0 0 $qn3bin addphbentry 0 1 0 $qn3bin configq 0 0 20 40 0.02 $qn3bin configq 1 0 10 20 0.10 $qn1tb1 setschedularmode WRR $qn1tb1 addqueueweights 0 8 $qn1tb1 addqueueweights 1 2 $qn1tb1 meanpktsize $packetsize $qn1tb1 set numqueues_ 2 $qn1tb1 setnumprec 1 $qn1tb1 addphbentry 10 0 0 $qn1tb1 addphbentry 0 1 0 $qn1tb1 configq 0 0 20 40 0.02 $qn1tb1 configq 1 0 10 20 0.10 $qn2tb2 setschedularmode WRR $qn2tb2 addqueueweights 0 8 $qn2tb2 addqueueweights 1 2 $qn2tb2 meanpktsize $packetsize $qn2tb2 set numqueues_ 2 $qn2tb2 setnumprec 1 $qn2tb2 addphbentry 10 0 0 $qn2tb2 addphbentry 0 1 0 $qn2tb2 configq 0 0 20 40 0.02 $qn2tb2 configq 1 0 10 20 0.10 $qn3tb3 setschedularmode WRR $qn3tb3 addqueueweights 0 8 $qn3tb3 addqueueweights 1 2 $qn3tb3 meanpktsize $packetsize $qn3tb3 set numqueues_ 2 $qn3tb3 setnumprec 1 $qn3tb3 addphbentry 10 0 0 $qn3tb3 addphbentry 0 1 0 $qn3tb3 configq 0 0 20 40 0.02 $qn3tb3 configq 1 0 10 20 0.10 # ------------ Criacao do trafego (inicio) ----------------------------------- set tcp1 [new Agent/TCP/Newreno] $tcp1 set fid_ 1 $tcp1 set class_ 1 $tcp1 set windows_ 4000 set sink1 [new Agent/TCPSink] $ns attach-agent $transmissor $tcp1 $ns attach-agent $receptor1 $sink1 $ns connect $tcp1 $sink1 set ftp1 [$tcp1 attach-source FTP] $ftp1 set codept_ 10 set tcp2 [new Agent/TCP/Newreno] $tcp2 set fid_ 2 $tcp2 set class_ 1 $tcp2 set windows_ 4000 set sink2 [new Agent/TCPSink] $ns attach-agent $transmissor $tcp2 $ns attach-agent $receptor2 $sink2 $ns connect $tcp2 $sink2 set ftp2 [$tcp2 attach-source FTP] $ftp2 set codept_ 10 set tcp3 [new Agent/TCP/Newreno] $tcp3 set fid_ 3 $tcp3 set class_ 1 $tcp3 set windows_ 4000 set sink3 [new Agent/TCPSink] $ns attach-agent $transmissor $tcp3 $ns attach-agent $receptor3 $sink3 $ns connect $tcp3 $sink3 set ftp3 [$tcp3 attach-source FTP] $ftp3 set codept_ 10 # Trafego com baixa prioridade (background)---------------------------------- 22

set udp1 [new Agent/UDP] $ns attach-agent $trafbg1 $udp1 set cbr1 [new Application/Traffic/CBR] $cbr1 attach-agent $udp1 $cbr1 set packet_size_ $packetsize $udp1 set packetsize_ $packetsize $udp1 set class_ 2 $cbr1 set rate_ $rate0 $cbr1 set codept_ 0 set null1 [new Agent/Null] $ns attach-agent $receptor1 $null1 $ns connect $udp1 $null1 set udp2 [new Agent/UDP] $ns attach-agent $trafbg2 $udp2 set cbr2 [new Application/Traffic/CBR] $cbr2 attach-agent $udp2 $cbr2 set packet_size_ $packetsize $udp2 set packetsize_ $packetsize $udp2 set class_ 3 $cbr2 set rate_ $rate0 $cbr2 set codept_ 0 set null2 [new Agent/Null] $ns attach-agent $receptor2 $null2 $ns connect $udp2 $null2 set udp2b [new Agent/UDP] $ns attach-agent $trafbg2 $udp2b set exp2b [new Application/Traffic/Exponential] $exp2b attach-agent $udp2b $exp2b set packet_size_ $packetsize $udp2b set packetsize_ $packetsize $udp2b set class_ 6 $exp2b set rate_ $rate0 $exp2b set codept_ 0 set null2b [new Agent/Null] $ns attach-agent $receptor2 $null2b $ns connect $udp2b $null2b set udp3 [new Agent/UDP] $ns attach-agent $trafbg3 $udp3 set exp3 [new Application/Traffic/Exponential] $exp3 attach-agent $udp3 $udp3 set packetsize_ $packetsize $udp3 set class_ 4 $exp3 set rate_ $rate0 $exp3 set codept_ 0 set null3 [new Agent/Null] $ns attach-agent $receptor3 $null3 $ns connect $udp3 $null3 set tcp3b [new Agent/TCP/Newreno] $tcp3b set fid_ 8 $tcp3b set class_ 7 $tcp3b set windows_ 2000 set sink3b [new Agent/TCPSink] $ns attach-agent $trafbg3 $tcp3b $ns attach-agent $receptor3 $sink3b $ns connect $tcp3b $sink3b set ftp3b [$tcp3b attach-source FTP] $ftp3b set codept_ 0 # ------------ Criacao do trafego (fim) proc finish {} { global ns nf f $ns flush-trace #Fecha o arquivo de Trace close $f close $nf #Executa o NAM exec nam out.nam & exit 0 } # Definindo o label 23

$ns at 0.0 "$transmissor label transmissor" $ns at 0.0 "$receptor1 label receptor1" $ns at 0.0 "$receptor2 label receptor2" $ns at 0.0 "$receptor3 label receptor3" $ns at 0.0 "$bordain label bordain" $ns at 0.0 "$bordaout1 label bordaout1" $ns at 0.0 "$bordaout2 label bordaout2" $ns at 0.0 "$bordaout3 label bordaout3" $ns at 0.0 "$nucleo1 label nucleo1" $ns at 0.0 "$nucleo2 label nucleo2" $ns at 0.0 "$nucleo3 label nucleo3" $ns at 0.0 "$trafbg1 label trafbg1" $ns at 0.0 "$trafbg2 label trafbg2" $ns at 0.0 "$trafbg3 label trafbg3" #Definindo os momentos em que o trafego entra na rede $ns at 2.0 "$ftp1 start" $ns at 2.0 "$ftp2 start" $ns at 2.0 "$ftp3 start" $ns at 0.0 "$cbr1 start" $ns at 0.0 "$cbr2 start" $ns at 0.0 "$exp2b start" $ns at 0.0 "$exp3 start" $ns at 0.0 "$ftp3b start" $ns at $testtime "$ftp1 stop" $ns at $testtime "$ftp2 stop" $ns at $testtime "$ftp3 stop" $ns at $testtime "$cbr1 stop" $ns at $testtime "$cbr2 stop" $ns at $testtime "$exp2b stop" $ns at $testtime "$exp3 stop" $ns at $testtime "$ftp3b stop" $ns at [expr $testtime + 1.0] "finish" $ns run 24