Gerenciamento Diffserv em Redes IP Móvel utilizando COPS-PR

Thiago Pereira, André Beller, Edgard Jamhour, Mauro Fonseca

PUCPR, PPGIA – Imaculada Conceição, 1155 CEP 90815-901 – Curitiba – PR – Brasil

{tmp,a.beller,jamhour,mauro.fonseca}@ppgia.pucpr.br

Abstract. This paper describes and evaluates a framework based on the IETF standards for managing diffserv configuration on Mobile IP-based networks. In this scenario, users can keep their Quality of Service privileges while they connect in different access networks within a diffserv domain. The diffserv configuration is dynamically provided by COPS-PR protocol to the edge routers, according to the authentication events registered by the home agent during the mobile node’s handoff.

Resumo. Este artigo descreve e avalia uma arquitetura baseada em padrões IETF para o gerenciamento de configuração diffserv em redes IP Móvel. Nesse cenário, os usuários podem manter seus privilégios de Qualidade de Serviço enquanto conectam-se a diferentes redes de acesso dentro de um domínio diffserv. A configuração diffserv é fornecida através do protocolo COPS-PR de maneira dinâmica aos roteadores de borda, conforme os eventos de autenticação registrados pelo home agent durante o handoff do nó móvel.

1. Introdução Este artigo descreve e avalia uma arquitetura para gerenciar especificações de nível de serviço (SLSs – Service Level Specifications) em redes IP Móvel. O Mobile Internet Protocol (MIP) é um padrão IETF no qual, independente do ponto de ligação físico, o nó móvel permanece com seu endereço IP [Perkins 2002]. O MIP pode ser empregado tanto em redes homogêneas – tecnologias de redes celulares (GPRS e EDGE), por exemplo – quanto em redes heterogêneas, nas quais é possível integrar WLANs (Wireless Local Area Networks) com redes celulares.

No cenário considerado neste artigo, os usuários podem manter seus privilégios de qualidade de serviço (atribuições de SLS) enquanto movem-se através de diferentes redes de acesso interconectadas por um domínio diffserv. Um SLS representa um subconjunto contido em um SLA (Service Level Agreement). Enquanto o SLA aborda aspectos legais e administrativos do contrato de serviços, o SLS descreve os aspectos técnicos do contrato, ou seja, a caracterização e tratamento do tráfego, através de parâmetros e métricas de Qualidade de Serviço (QoS – Quality of Service) [Westerinen 2001]. Para manter os SLSs dos nós móveis, os roteadores diffserv de borda (edge routers) devem receber sua configuração de maneira dinâmica, de acordo com os eventos de autenticação relacionados ao handoff do nó móvel.

Este artigo aborda o problema de construir uma arquitetura para suportar a provisão de QoS na presença de mobilidade, explorando os padrões IETF que dizem

respeito ao gerenciamento diffserv. A arquitetura segue a estrutura PEP/PDP (Policy Enforcement Point / Policy Decision Point), usando a abordagem de provisão (provisioning) [Westerinen 2001]. A configuração diffserv é representada em termos de uma diffserv PIB (Policy Information Base), a qual contém uma descrição independente de fabricante da configuração atribuída ao dispositivo [Chan 2003]. A transferência da PIB entre o PEP e o PDP é realizada utilizando o protocolo COPS-PR (Common Open Policy Service for Policy Provisioning) [Chan 2001].

Para suportar a mobilidade dos usuários, a informação da PIB deve ser atualizada e transferida do PDP para o PEP como resposta à confirmação do evento de handoff. Essas atualizações são enviadas através do protocolo COPS-PR, que suporta enviar atualizações não-solicitadas da PIB do PDP para o PEP. Entretanto, um importante aspecto que deve ser analisado é de como preservar os privilégios de QoS em redes distintas, onde os dispositivos de rede implementam diferentes mecanismos de QoS e possuem diferentes quantidades de largura de banda disponíveis. Este artigo aborda esse problema através de um modelo de política de três camadas. O modelo de política de alto nível (HLPM – High Level Policy Model) é utilizado para definir SLSs usando regras que levam em consideração as instalações de cada rede. O modelo de política de nível de configuração (CLPM – Configuration Level Policy Model) é usado para definir a configuração do dispositivo independente das capacidades particulares do dispositivo. Finalmente, uma diffserv PIB é gerada através da compilação do CLPM de acordo com as capacidades particulares do dispositivo.

Este artigo é estruturado da seguinte maneira. A seção 2 revisa os conceitos relacionados ao MIP e ao diffserv. A seção 3 apresenta uma visão da arquitetura proposta para gerenciar a configuração diffserv em redes IP Móvel e também discute a estratégia para implementar as atualizações da PIB. A seção 4 apresenta o modelo de política de três camadas adotado pela arquitetura. A seção 5 aborda alguns resultados acerca da estratégia definida na seção 3. A seção 6 expõe alguns trabalhos relacionados, apontando a principal diferença deste artigo em relação aos outros trabalhos publicados que abordam o gerenciamento de QoS em ambientes móveis. Por fim, a conclusão resume os principais resultados deste trabalho e aponta para desenvolvimentos futuros.

2. IP Móvel e Diffserv O padrão IP Móvel [Perkins 2002] trata do problema que pode surgir quando um nó muda seu endereço IP durante a comunicação. Um nó muda seu endereço IP porque o protocolo IP assume que cada identificador de rede IP é relacionado a uma rede física específica. A alteração do endereço IP durante a sessão de comunicação exige o reinicio de qualquer aplicação que esteja sendo executada no nó móvel.

O MIP resolve esse problema através da técnica de tunelamento. Cada nó móvel possui dois endereços IP. O primeiro endereço é relacionado à sua rede home (home network), onde o nó móvel está registrado, e não muda quando o nó conecta-se a uma rede física diferente. O segundo endereço é relacionado a uma rede estrangeira (foreign network), e muda cada vez que o nó conecta-se a uma rede física diferente (Figura 1). Esse segundo endereço é chamado de CoA (Care-of Address). O roteador conectado ao nó móvel na rede estrangeira é chamado de foreign agent (FA). O roteador da rede home é chamado de home agent (HA), e é responsável por autenticar o nó móvel e manter uma tabela interna mapeando o CoA com o endereço IP home de todo nó móvel

que ele serve. O MIP especifica que é responsabilidade do nó móvel informar ao HA que ele mudou seu CoA. Para fazer isso, ele envia uma mensagem assinada digitalmente “binding update” para o HA cada vez que ele muda seu CoA. Do ponto de vista de um nó que não possui as funcionalidades do MIP, um nó móvel é identificado pelo seu endereço IP home. Pacotes da Internet são entregues ao nó móvel através de um túnel (Figura 2) que o segue enquanto ele muda de posição e conecta-se a diferentes redes.

MIP AdvertisementMIP

Advertisement

MIP Advertisement

FAEdge Router

Rede Estrangeira

FAEdge Router

Rede Estrangeira

Rede Home

HAEdge Router

Core Router

Rede Diffserv

MN Túnel

Figura 1. Diffserv e MIP

...0 95

CoA IP origem ... dados127 159 191

95

IP origem ... dados127 159 191

IP home...0

Figura 2. Tunelamento MIP

A metodologia de qualidade de serviço diffserv define duas entidades principais: o roteador de borda (edge router) e o roteador de núcleo (core router) [Blake 1998]. O roteador de borda é responsável por policiar e atribuir uma classe agregada para os pacotes transmitidos pelos nós a ele conectados. Um roteador de núcleo não diferencia fluxos individuais e manipula os pacotes de acordo com a classe agregada designada pelos roteadores de borda. A Figura 1 ilustra como uma rede IP Móvel pode ser adaptada à metodologia de qualidade de serviço diffserv. Por questões de simplicidade, assume-se que as funções de FA e HA são acumuladas pelos roteadores de borda.

O IETF define quatorze classes agregadas para a rede de núcleo: uma classe expedited forwarding (EF), 12 classes assured forwarding (AF), e uma classe best effort (BE). Um roteador de borda é responsável por policiar o tráfego e atribuir uma classe agregada de acordo com o SLS atribuído ao nó móvel. Considerando o cenário IP Móvel, a configuração do roteador de borda deve ser atualizada quando um nó móvel desloca-se do domínio de um FA para outro domínio de outro FA. Nesse caso, a configuração SLS do nó móvel deve ser adicionada ao FA no domínio de entrada e removida do FA no domínio de saída.

3. Estratégia para atualizar a configuração do Foreign Agent A arquitetura descrita neste artigo adota o padrão diffserv PIB para representar a configuração distribuída dos roteadores de borda [Chan 2003]. Um módulo PIB é uma estrutura de dados nomeados descrita como uma árvore conceitual, onde os galhos representam Provisioning Classes (PRCs) e as folhas representam Provisioning Instances (PRIs). As PRCs diffserv PIB modelam um Traffic Condition Block (TCB), que é formado por zero ou mais classificadores, medidores, ações, algoritmos de descarte, filas e escalonadores de pacotes.

Como mostrado na Figura 3, na diffserv PIB, os elementos funcionais (classificadores, medidores, etc.) e seus parâmetros (filtros IP, parâmetros token-bucket) são representados por PRCs distintas. A Figura 4 mostra um exemplo de como os pacotes de um usuário são classificados (pelo filtro IP – IPfilter) e recebem uma política de tratamento específica (pelo medidor, TBParam e algoritmo de descarte) e ação de marcação específica (DSCPMark). A ação de marcação é responsável por atribuir uma classe agregada de core para os pacotes gerados pelo usuário.

Figura 3. Visão geral da diffserv PIB

ClfrElementId=“User_A”NextSpecific

IPFilterId=“IP_User_A”Negation=“false”AddrType=“4”SrcAddr= “198.168.2.20”SrcPrefixLength=“24”

MeterId=“1”SuceedNextFailNextSpecific

ActionId=“1”Specific

TBParamId=“1”Rate=“1M”BurstSize=“64k”

AlgDropId=“1”Type=“alwaysDrop”

OID

OID

OID OID

OID

DSCPMarkId=“1”Mark=“AF11”

OID

Figura 4. Exemplo de configuração da diffserv PIB

Considerando o cenário IP Móvel, um FA deve conter a configuração de todos os possíveis usuários móveis que podem conectar-se a sua rede. Essa abordagem, entretanto, é, compreensivelmente, não pratica. Portanto, a arquitetura proposta neste artigo adota uma configuração dinâmica dos FAs, a qual é disparada pelos eventos de autenticação gerados pelo HA. Analisando a estrutura da diffserv PIB, pode-se observar que o processo de configuração pode ser significantemente simplificado se os elementos da PIB forem classificados em informações estáticas e informações dinâmicas. Essa abordagem, presente na Figura 5, assume que a maioria dos usuários compartilhará um

pequeno número de definições SLS. As definições SLS são representadas por PRCs “brancas” e são consideradas informações estáticas. As PRCs responsáveis pela atribuição do SLS (isto é, mapear um usuário para uma definição SLS) são representadas por PRCs “escuras” e são consideradas informações dinâmicas. Uma vez que é assumido que todos os túneis são criados entre o FA e o HA, o nó móvel é representado por seu endereço home. A informação estática pode ser provisionada no momento da inicialização do FA. A configuração dinâmica deve ser atualizada quando o nó móvel move-se de um domínio de um FA para outro. Nesse caso, o FA no domínio de entrada deve receber novas informações de filtros para associar os pacotes gerados pelo nó móvel ao SLS atribuído ao usuário. Similarmente, a informação de filtros deve ser removida do FA do domínio anterior.

Figura 5. Configuração estática e dinâmica da PIB

3. configuração diffserv

1. binding request

MIP Advertisement

MIP Advertisement

FA / PEP /Edge Router

Rede Estrangeira

FA / PEP /Edge Router

Rede Estrangeira

Rede Home

FA / PEP /Edge Router

Core Router

Rede Diffserv

MN

Túnel

PDP

2. evento de autenticação

3. configuração diffserv

Figura 6. Visão geral do cenário

A Figura 6 ilustra como a abordagem PEP/PDP pode ser adaptada ao ambiente diffserv em redes IP Móvel. Nesse ambiente, os roteadores diffserv são representados por agentes PEP. Em um cenário de operação típico, quando o HA autentica uma

mensagem “binding request” de um nó móvel (1), ele envia um evento de notificação para o PDP (2). Então, utilizando o protocolo COPS-PR, o PDP atualiza a configuração dos FAs/roteadores diffserv. Para reduzir a latência do processo de atualização, uma escolha lógica é colocar o PDP na mesma rede que o HA.

As mensagens trocadas entre o PDP e os PEPs são ilustradas na Figura 7. O primeiro conjunto de mensagens (1 a 5) corresponde ao provisionamento inicial, no qual o PEP requisita a configuração estática da PIB. Depois disso, o PDP marca a flag da PIB “FullState = False”, informando o PEP que as próximas mensagens DEC devem ser interpretadas como atualizações (isto é, o PEP não deve apagar a PIB encarnation anterior). O processo de atualização é implementado por uma mensagem de decisão não solicitada transmitida do PDP para o PEP.

PEP

7. DEC(FullState = False)

1. OPN(ClientType, PepID)

2. CA(KATimer)

3. REQ(RoleCombo, Capabilities)

4. DEC(Configuração Inicial)

5.RPT(Sucesso) 6. Update(EstadoPep)

8. RPT(Sucesso)9. Update(EstadoPep)

11. RPT(Sucesso)12. Update(EstadoPep)

10. DEC(Atualizar PIB)

PDP

Evento do home agent

Figura 7. Trocas de mensagens do protocolo COPS-PR durante o processo de provisão

4. Modelo de Política de Três Níveis Um importante problema que deve ser resolvido por uma arquitetura de gerenciamento diffserv é como levar em consideração os diferentes mecanismos de QoS implementados pelos roteadores de borda durante o processo de configuração. Uma importante contribuição do IETF para tratar desse problema é o QPIM (Policy QoS Information Model) [Snir 2003], modelo de informação que permite descrever políticas de configuração independentes de dispositivo. Através da definição de um modelo que não é dependente do dispositivo, o QPIM permite o reuso de configurações de QoS.

A configuração QPIM é expressa em forma de “políticas” atribuídas a “interfaces de dispositivos”, e não leva em consideração elementos do nível de negócio, como usuários, aplicações e topologia de rede. Uma ferramenta de gerenciamento de QoS completa deve incluir um modelo de política de mais alto nível que possa gera a configuração QPIM baseada em objetivos do negócio, topologia de rede e metodologia de QoS (diffserv ou intserv) [Snir 2003].

Para tratar desses problemas, este artigo propõe um modelo de três níveis ilustrado na Figura 8. Esse modelo é baseado em uma publicação anterior [Beller 2004], mas algumas modificações foram introduzidas para adaptar a arquitetura ao cenário

MIP, como explicado na seção 3. A explicação no restante desta seção segue os números presentes na Figura 8.

De acordo com a estratégia definida pela arquitetura, um administrador define uma biblioteca de ações QPIM (1) correspondentes aos SLSs que serão atribuídos aos usuários. No modelo de política de alto nível (HLPM) (2), os administrador define os objetivos do negócio atribuindo SLSs (isto é, ações QPIM) aos clientes no ambiente gerenciado. O HLPM estende o modelo do IETF PCIM/PCIMe (Policy Core Information Model / Policy Core Information Model Extensions) e suporta a semântica: “usuário(s) acessando (uma) aplicação(ões) em (um) servidor(es) remoto, a partir de (uma) rede(s) de acesso recebe um nível de serviço específico”. Usuários, aplicações e elementos de rede em uma política de alto nível são expressos em termos de objetos CIM (Common Information Model) (3).

2. HLPM

5. CLPM

4. Processo de Tradução

6. Processo de Decisão (solicitado)

10. Evento Mobilidade

1. Ações QPIM

3. Objetos CIM

5. Evento Request

8. Processo de Distribuição (COPS-

PR)

11. Processo de Decisão (não

solicitado)7. Diffserv PIB(Ações sem

Filtros)

11. Diffserv PIB(Filtros)

referencia

referencia

referencia

Interface, PapéisCapabilities

9. Mapear Estado (PIB, SLS, PRIDs)

Informações de Filtro

referencia

Figura 8. Visão geral da arquitetura

O processo de tradução (4) converte a informação de alto nível em políticas de configuração independentes de dispositivo (isto é, a configuração traduz os efeitos de QoS desejado sem especificar detalhes do mecanismo, como o tipo de escalonador ou o algoritmo de descarte). Por exemplo, “o tráfego com IPorigem=200.1.1.5 e porta=21 recebe BW=25%”. O modelo de política de nível de configuração (CLPM – Configuration Level Policy Model) (5) é definido como uma combinação de classes PCIM/PCIMe e QPIM com o objetivo de suportar a representação de ambos os elementos em uma configuração de dispositivo: identificação de tráfego (condições) e tratamento de tráfego (ações). Condições são descritas em termos de filtros de pacotes baseados no cabeçalho IP e ações são descritas em termos de mecanismos de QoS, como escalonadores e algoritmos de descarte. O CLPM também inclui um mapeamento entre as políticas de configuração e os papéis das interfaces dos dispositivos. Esse mapeamento é deduzido da informação de topologia extraída do HLPM. Os modelos de classes de alto nível e de configuração, bem como o processo de tradução, estão detalhados em [Beller 2004].

No processo de decisão (6), as políticas de configuração são transformadas em instâncias diffserv PIB (7). Esse processo é executado quando o PDP recebe uma mensagem COPS-PR de requisição (REQ) (5) do PEP perguntando por uma configuração de provisão. A mensagem REQ possui dois conjuntos de informações que

são usadas como parâmetros de entrada em um processo de decisão: (i) RoleCombination, que são rótulos associados às interfaces dos dispositivos gerenciados; (ii) DeviceCapabilities, que descrevem mecanismos de QoS específicos suportados pelo dispositivo gerenciado. Primeiramente, o PDP usa o RoleCombination para selecionar as políticas relevantes para a interface do dispositivo gerenciado e, após, o PDP converte as políticas de configuração em instâncias de provisionamento da diffserv PIB, de acordo com o conjunto de DeviceCapabilities. A informação da PIB é gerada da configuração QPIM por um processo de transformação que leva em consideração capabilities (mecanismos de QoS suportados) do dispositivo gerenciado.

Para suportar mobilidade, o provisionamento inicial da PIB gerado pelo evento REQ (5) não contém as definições de filtro, mas somente as ações correspondentes aos SLSs suportados em uma rede de acesso específica representada pelo PEP. As definições de filtro são geradas em resposta a um evento de mobilidade (que consiste em um evento de autenticação gerado pelo home agent). Um evento de autenticação remove as entradas de filtro correspondentes do PEP que representam a rede anterior onde o usuário estava registrado e adiciona novas entradas de filtros ao PEP representando a nova rede onde o usuário está registrado.

Finalmente, o processo de distribuição (8) consiste em transmitir as PRIDs diffserv PIB utilizando o protocolo COPS-PR.

5. Avaliação Para avaliar as estratégias discutidas na seção anterior, foi implementado o protótipo ilustrado nas Figuras 6 e 8. O PDP e o PEP foram implementados em Java e foram hospedados em máquinas Intel Pentium IV, 1.5GHz, rodando a distribuição de Linux Fedora Core 4. O software de IP Móvel, que corresponde ao home agent, ao foreign agent e ao nó móvel é baseado em um código disponível em [Andersson 2001]. O código fonte do programa foi modificado para gerar o evento de notificação do home agent ao PDP, uma vez que o pedido de “binding update” solicitado pelo nó móvel é confirmado.

Como ilustrado na Figura 6, o mesmo dispositivo exerce os papéis de roteador diffserv, foreign agent e PEP. Os mecanismos diffserv são implementados através da ferramenta “linux traffic control” disponível na plataforma Linux. O controle de tráfego consiste em um conjunto de sistemas de fila e mecanismos pelos quais os pacotes são enviados e recebidos em um roteador. O dispositivo que exerce o papel de home agent também acumula a função de roteador diffserv. O PDP é implementado em uma máquina independente, com a mesma configuração das outras máquinas presentes neste cenário, e socket foi o mecanismo utilizado para a comunicação entre o home agent e o PDP.

Os testes foram propostos para avaliar a latência introduzida pelo processo de atualização da diffserv PIB além de verificar o impacto de um número crescente de nós realizando o processo de handoff na latência dos processos de decisão, tanto do MIP quanto da arquitetura proposta, para verificar a escalabilidade do sistema. Para realizar o handoff dos nós móveis, foi utilizado um script em programação bash, onde era possível inserir o intervalo de tempo desejado no qual cada nó móvel alternava para outra rede.

A Figura 9 exibe os atrasos médios obtidos nos eventos mais importantes relacionados ao handoff. Os resultados apresentados devem ser considerados somente como comparação entre os resultados obtidos nesse ambiente de avaliação, uma vez que no ambiente foi considerado somente um salto entre o FA e o HA e os roteadores estão ligados por enlaces de 100Mbps. Os dados da figura referem-se ao primeiro cenário, onde o número aproximado de transições foi 12 handoffs/minuto.

MH FA/PEP HA PDP Linha do Tempo

0.00 sHandoff

3.210 s

MIP Advertisement

MIP Advertisement

MIP Advertisement

Registration Request

Registration Reply

3.405 s

3.416 sEvento

3.440 s

3.527 s

COPS Decision Message

COPS Report State Message

0.111 s

3.416 s

Figura 9. Eventos relacionados ao handoff e seus atrasos médios (12 handoffs/minuto)

A Tabela 1 apresenta os dados do cenário ilustrado na Figura 9, bem como de outros cenários, com diferentes números de handoffs por minuto. São também apresentados o tamanho das mensagens capturadas e o desvio padrão dos atrasos coletados. As mensagens de advertisement do MIP foram capturadas na interface do nó móvel. As mensagens referentes ao processo de registro do nó móvel (registration request e registration reply) foram capturadas na interface pública do home agent, isto é, a interface visível para os foreign agents. As mensagens do protocolo COPS-PR, que transmitem as atualizações da diffserv PIB, foram capturadas no PDP. A sincronização dos tempos das mensagens capturadas em diferentes dispositivos foi realizada através comparação entre o tempo de envio da mensagem em um dispositivo e o tempo de recebimento dessa mesma mensagem em outro dispositivo. O programa de captura utilizado foi o Ethereal, disponível em [Combs 2005].

Pela análise da Figura 9, observa-se que o atraso inserido a partir do momento que o nó móvel tem seu registro confirmado (4) ao momento em que o PEP informa o PDP que as novas políticas foram instaladas com sucesso (6) é de aproximadamente 0.111 segundos. O maior atraso presente é introduzido pelas mensagens do MIP. De acordo com o padrão MIP [Perkins 2002], cada mensagem de advertisement possui um campo de tempo de vida (lifetime) que define por quanto tempo um advertisement do foreign agent é válido, o que significa quanto tempo o foreign agent ainda está disponível na ausência de outras mensagens de advertisement. Após o handoff, o nó móvel deve aguardar que o advertisement recebido do foreign agent anterior expire antes de iniciar o registro na nova rede. O atraso médio de 3.405 segundos entre o evento de handoff e o pedido de registro (3) é o resultado do tempo de vida de 3 segundo da mensagem de advertisement (valor padrão na implementação do MIP

utilizada [Andersson 2001]). Considerando que o campo de tempo de vida nas mensagens de advertisement é um valor inteiro, o menor valor possível esperado é de 1 segundo. O padrão MIP define que as mensagens de advertisement devem ser enviadas em um intervalo não superior a 1/3 do tempo de vida.

Tabela 1. Tempo médio dos eventos relacionados ao evento de handoff do nó móvel

Evento ≈ 12 handoffs/min

≈ 15 handoffs/min

≈ 20 handoffs/min

≈ 29 handoffs/min

≈ 56 handoffs/min

≈ 102 handoffs/min

1. Handoff 0 0 0 0 0 0 2. Terceiro MIP Advertisement

3.210s 3.210s 3.210s 3.210s 3.210s 3.210s

3. Registration Request

3.405s 3.405s 3.405s 3.405s 3.405s 3.405s

4. Registration Reply

3.416s σ = 0.016

3.411s σ = 0.007

3.415s σ = 0.018

3.417s σ = 0.015

3.417s σ = 0.018

3.416s σ = 0.019

5. COPS Decision Message

3.440s σ = 0.026

3.443s σ = 0.025

3.440s σ = 0.022

3.441s σ = 0.023

3.444s σ = 0.023

3.438s σ = 0.024

6. COPS Report State Message

3.527s σ = 0.031

3.531s σ = 0.029

3.529s σ = 0.032

3.532s σ = 0.029

3.537s σ = 0.034

3.528s σ = 0.031

Para verificar o impacto do número de handoffs nos atrasos dos processos de decisão, a Figura 10 expõe de maneira mais propícia os dados presentes na Tabela 1 no que se refere aos atrasos médios dos eventos relacionados ao handoff. Observa-se que os atrasos são pouco influenciados pela freqüência de handoffs dos nós móveis. Desse modo, é possível afirmar que as entidades de diffserv PDP e PEP e mesmo as entidades relacionadas ao MIP, o home agent e o foreign agent, não representam gargalos no processo de autenticação do nó móvel, transporte e aplicação das atualizações da diffserv PIB.

2. Terceiro MIP Advertisement

3. Registration Request

4. Registration Reply

5. COPS Decision Message

6. COPS Report State Message

3.200

3.250

3.300

3.350

3.400

3.450

3.500

3.550

12 15 20 29 56 102

número de handoffs/min

tem

po (s

)

Figura 10. Comparativo do atraso com diferentes freqüências de handoff

6. Trabalhos Relacionados Há um crescente número de significativos trabalhos relacionados ao gerenciamento de QoS de usuários móveis. De maneira geral, esses trabalhos podem ser classificados em

dois grandes grupos: os que tratam da macro-mobilidade e os que tratam da micro-mobilidade. Esses dois tipos de mobilidade são definidos como mudanças do ponto de ligação enquanto uma sessão está em progresso. A micro-mobilidade, maneira mais simples de mobilidade, caracteriza-se pela mudança dentro de um único domínio, onde, geralmente, a mobilidade é controlada em nível da camada de enlace. A macro-mobilidade envolve a mudança entre dois domínios, onde os recursos da camada de enlace não são suficientes para a mudança de rede ser transparente em nível de sessão. O trabalho aqui descrito trata somente da macro-mobilidade.

Enquanto este artigo adota a abordagem de provisão (provisioning), outros trabalhos tratam do problema de QoS propondo um protocolo de sinalização para prover QoS sob demanda. Em [Braun 2001], os autores propõem um novo protocolo de sinalização que permite aos usuários móveis contatar um bandwidth broker diferenciado para a negociação de QoS. O trabalho apresentado em [Bless 2003] propõe uma arquitetura de sinalização que leva em consideração a mobilidade, na qual o gerenciamento de recursos é integrado com o gerenciamento de mobilidade para fornecer a Qualidade de Serviço necessária sob demanda aos usuários móveis. Ele é baseado em um conceito de gerencia de recursos de domínio e suporta o handover antecipado com a pré-alocação de recursos antes que o nó móvel conecte-se ao novo ponto de acesso.

A proposta aqui presente adota a metodologia de QoS diffserv. Outras propostas adotam uma combinação entre metodologias intserv (Integrated Service) e diffserv. Por exemplo, para negociar a especificação de QoS em macro-mobilidade, o trabalho em [Pack 2001] propõe uma arquitetura de provisão de QoS fim-a-fim, combinando as metodologias diffserv e intserv. O projeto europeu BRAIN [BRAIN 1999] e o seu projeto sucessor MIND [MIND 2000] propõe uma rede de acesso que provê mobilidade e QoS transparentes para diferentes aplicações, desde serviços best effort até serviços com altos requisitos de QoS, como, por exemplo, a telefonia IP. A arquitetura de QoS do projeto BRAIN é baseada em ambas as arquiteturas, diffserv e intserv.

7. Conclusão Este artigo apresentou uma arquitetura para suportar a configuração diffserv em redes IP Móvel. A proposta é baseada em padrões IETF relativos à configuração diffserv, onde os elementos mais importantes são a diffserv PIB e o COPS-PR. O estudo aqui exposto mostra que tanto a PIB quanto o COPS-PR fornecem flexibilidade suficiente para tratar do problema de mobilidade sem a introdução de novos protocolos ou modificações nos padrões já existentes. A solução mostrou-se igualmente escalável no que se refere ao número de handoffs realizados pelos nós móveis em unidade de tempo. Este artigo propõe uma estratégia para atualizar a configuração diffserv explorando a estrutura da PIB, onde os mecanismos de ação para garantir a Qualidade de Serviço são provisionados na inicialização dos roteadores diffserv de borda e as definições de filtros são atualizadas dinamicamente, em resposta ao evento de confirmação de registro gerado pelo home agent. A estratégia é de simples implementação e introduz um atraso relativo baixo no processo de configuração, quando comparada com o atraso introduzido pelo processo de handoff do MIP.

Futuros trabalhos avaliarão a estratégia aqui proposta em ambientes ainda maiores, com a presença de mais roteadores de borda e nós móveis. O tipo de túnel

utilizado neste trabalho foi aquele criado entre o home agent e o foreign agent. Nessa abordagem, somente um túnel é criado entre o home agent e o foreign agent, independente do número de nós móveis presentes no domínio do foreign agent. As próximas avaliações verificarão se o outro tipo de tunelamento disponível no padrão MIP, entre o home agent e o nó móvel, não significará um gargalo no sistema, uma vez que, nesse tipo de abordagem, um túnel é criado para cada nó móvel conectado ao home agent.

Referências Andersson, B., et. al. (2001), “Dynamics Mobile IP”, http://dynamics.sourceforge.net,

December.

Beller, A., Jamhour, E., Pellenz, M. (2004). “Defining Reusable Business-Level QoS Policies for DiffServ”, In: Proceedings of Distributed Systems Operations and Management Workshop, p. 40-51.

Blake, S., et. al. (1998). “An Architecture for Differentiated Services”, IETF RFC 2475.

Bless, R., et al. (2003) “Quality-of-Service Signaling in Wireless IP-based Mobile Networks”, In: VTC2003-Fall, Orlando, FL, USA.

BRAIN (1999). “Broadband Radio Access for IP-based Networks”, http://www.istbrain.org. IST-1999-10050.

Braun, T., Stattenberger, G. (2001) “Providing Differentiated Services to Mobile IP Users”, In: The 26th Annual IEEE Conference on Local Computer Networks, Tampa, USA

Chan, K., et. al. (2001). “COPS Usage for Policy Provisioning (COPR-PR)”, IETF RFC 3084.

Chan, K., et. al. (2003). “Differentiated Services Quality of Services Policy Information Base”, IETF RFC 3317.

Combs, Gerald. (2005). “Ethereal: A Network Protocol Analyzer”, http://www.ethereal.com.

MIND (2000). “Mobile IP-based Network Developments”, http://www.ist-mind.org. IST-2000-28584.

Pack, S., Choi, Y. (2001) “An End-to-End QoS Provisioning Architecture in Mobile Network”, In: Proc. International Symposium on Communications and Information Technologies (ISCIT), Chiangmai, Tailand.

Perkins, C. (2002). “IP Mobility Support for IPv4”, IETF RFC 3344.

Snir, Y., et. al. (2003). “Policy Quality of Service Information Model”, IETF RFC 3644.

Westerinen, A., et. al. (2001). “Terminology for Policy-Based Management”, IETF RFC 3198.