SBrT 2000 – XVIII Simpósio Brasileiro de Telecomunicações, 3 a 6 de Setembro, 2000, Gramado-RS
MAPEADOR DE TRÁFEGO INTERDOMÍNIOS
EXTENSÍVEL A NOVAS ARQUITETURAS DE QoS
(MATRIX)
Mauro Margalho Coutinho, Judith Kelner, Djamel Sadok
msc@mauro.margalho.nom.br, jk@cin.ufpe.br ,jamel@cin.ufpe.br
Universidade da Amazônia, Universidade Federal de Pernambuco
CIn, Caixa Postal 7851
CEP: 50.732-970, Recife, Pernambuco, Brasil
RESUMO
Diferentes arquiteturas e mecanismos têm sido recentemente propostos a fim de fornecer Qualidade de Serviço na Internet (QoS)[13]. Isto inclui, Serviços Integrados (IntServ), Serviços Diferenciados (DiffServ), Multiprotocol Label Switching (MPLS), Roteamento com QoS e Engenharia de Tráfego (TE). O possível emprego de uma vasta gama de arquiteturas QoS introduz um novo problema de interoperabilidade relacionado à QoS: Como garantir a ligação entre domínios com diferentes arquiteturas, sem degradar a qualidade de serviço fim-a-fim? Este artigo propõe um novo protocolo para mapeamento dinâmico inter-domínio de QoS, permitindo que o fluxo seja ajustado e mantido quando cruzando novos domínios, baseado em requisitos de aplicações armazenados em BBs (Bandwidth Brokers) [11].
1.
INTRODUÇÃO
A tendência de integração entre diversos serviços ligados a área de telecomunicações e os providos por ISPs (Internet Services Providers) pode vir a ser definitivamente consolidada através do casamento Internet2 e Qualidade de Serviços. De um lado uma infra-estrutura baseada em backbones extremamente velozes. De outro um conjunto de arquiteturas com mecanismos capazes de priorizar o tráfego de acordo com sua especificidade. Viabilizar aplicações de tempo real tem sido objeto de inúmeras propostas para a IETF(Internet Engineering Task Force). Dentre outras, pode-se destacar [13] a arquitetura de Serviços Integrados, a arquitetura de Serviços Diferenciados, Multiprotocol Label Switching (MPLS), Roteamento com QoS e Engenharia de Tráfego. Todas elas convergem para o que vem sendo tratado, genericamente, por Qualidade de Serviço (QoS). QoS pode ser expressa como sendo uma combinação de exigências da rede com relação a quatro itens [14]: atraso, que é o tempo decorrido para um pacote ser passado de um transmissor, através da rede, para um cliente, jitter, que é a variação de atraso em uma transmissão fim-a-fim, largura de banda, que é a taxa máxima de transferência que pode ser sustentada entre dois pontos finais e integridade, que diz respeito a entrega correta dos pacotes para o cliente na mesma ordem em que foram despachados pelo transmissor. Uma rede que suporte QoS deve prover mecanismos para diferenciação de tráfego, priorizando certos pacotes ou fluxos em detrimento a outros. O cerne da questão é
que certas aplicações, como videoconferência e telemedicina, são mais susceptíveis a esses parâmetros do que outras, como correio eletrônico e transferência de arquivos.
A Internet2 [16], que é um projeto desenvolvido pela UCAID (University Corporation for Advanced Internet Development), tem se tornado palco de diversos experimentos de QoS. O sucesso destes experimentos pode vir a revolucionar vários serviços que hoje carecem de suporte adequado como é o caso de ensino a distância e voz sobre IP (VoIP). Simulações que avaliam a eficiência de alguns desses serviços estão disponíveis em [12] e [15].
Na Arquitetura de Serviços Integrados destaca-se um protocolo chamado RSVP (Resource Reservation Protocol) [8] que se propõe a dar suporte tanto a aplicações Unicast como Multicast. O RSVP é o projeto de um modelo baseado no cliente, o qual é responsável pela escolha do seu próprio nível de reserva de recursos, iniciando a reserva e a mantendo ativa tanto tempo quanto precise. De certa forma, esta é uma solução distribuída para o problema de reserva de recursos. Ela permite que clientes heterogêneos façam reservas especificamente de acordo com suas necessidades. A sobrecarga gerada pelo processo de sinalização e a falta de escalabilidade, causada pela manutenção das tabelas de estado dos fluxos nos hosts e roteadores, constituem-se nas principais desvantagens desta solução. Na Arquitetura de Serviços Diferenciados os fluxos são agregados e encaminhados com prioridades diferenciadas. Isso ocorre através de uma marcação no cabeçalho dos pacotes IP(Internet Protocol). No IPv4 há um mapeamento do octeto
Type of Service (ToS) e no IPv6 no Traffic Class (TC). Seis
bits, denominados Codepoint, são usados para definir o comportamento do pacote por salto ou PHB (Per Hop Behavior). Destacam-se o PHB EF (Expedited Forwarding) [5] que garante um serviço expresso para aplicações mais vulneráveis a atraso e jitter, e o PHB AF (Assured Forwarding) [6] que possui maior variedade de opções uma vez que oferece quatro classes de encaminhamento e três níveis de descarte. No processo de transição para as arquiteturas que implementam QoS, diferentes Domínios poderão optar por uma variedade de tecnologias alternativas. DiffServ e MPLS nos backbones, IntServ nas redes de acesso, roteamento com QoS no backbone, etc. Além disso, a mesma arquitetura pode vir a ser implementada de diferentes maneiras. DiffServ é um exemplo,
uma vez que a IETF somente normatiza os mecanismos de encaminhamento (Per Hop Behavior - PHBs) e não os serviços. O caráter heterogêneo das diversas propostas apresentadas trouxe a tona uma preocupação com a questão da interoperabilidade em termos de garantias de QoS. Uma vez que as diferentes arquiteturas possuem diferentes mecanismos, faz-se necessário uma alternativa que traga independência da tecnologia e garanta um controle de QoS interdomínios. A especificação de tal mecanismo constitui-se na principal contribuição deste trabalho.
Este artigo encontra-se estruturado em 6 sessões. A sessão 1 faz uma breve introdução acerca do estado da arte em Qualidade de Serviço na Internet. A sessão 2 mostra a atual visão da IETF para comunicação entre Domínios. A seção 3 especifica a arquitetura do protocolo proposto. A sessão 4 analisa os resultados obtidos a partir de simulações feitas com o Network Simulator. A sessão 5 apresenta as conclusões e a 6 as principais referências bibliográficas.
2.
SUPORTE IETF PARA
COMUNICAÇÃO ENTRE DOMÍNIOS
Na visão da IETF um agente chamado BB(Bandwidth Broker) [11] atua como negociador de banda entre os diferentes Domínios. Ele pode ser considerado como um tipo de gerente de políticas que guarda informações sobre os recursos disponíveis na rede e é responsável pela coordenação da alocação e provisionamento de recursos. Basicamente o que ocorre é uma solicitação de alocação de recursos, através de um processo denominado RAR (Resource Allocation Request). Esse processo é mantido entre o usuário e o BB. Em seguida o BB negocia com outros BBs adjacentes. Isso ocorre através de um outro processo denominado CAC (Connection Admission Control) que se propaga até que os recursos sejam garantidos fim a fim. Esse modelo é eficiente em ambientes homogêneos, como por exemplo entre Domínios puramente DiffServ [7] ou IntServ [9]. Entretanto existe uma lacuna entre Domínios que implementam diferentes arquiteturas. Nesse ponto, faz-se necessário uma ação de mapeamento para que a conversão ocorra com um mínimo de perdas.
O protocolo proposto pode ser considerado como sendo uma extensão dos BBs (Bandwidth Brokers). Nas seções seguintes estaremos refinando uma proposta com esse objetivo, onde se busca garantir, fim a fim, os níveis de qualidade acordados nos contratos de usuários ou SLA's (Service Level Agreement).
3.
ESPECIFICAÇÃO DA ARQUITETURA
DO PROTOCOLO
O protocolo de mapeamento proposto, que pode ser considerado um serviço adicional dos BBs, baseia-se em dois parâmetros para escolher o serviço equivalente em outro Domínio. O
primeiro é obtido através de um processo de monitoração e tem como objetivo calcular a taxa média de transmissão dos fluxos. O segundo avalia as características ou requisitos de QoS associados a cada fluxo. A partir da integração desses dados, pode-se proceder o mapeamento entre quaisquer arquiteturas de QoS.
Para mapear serviços e mecanismos de QoS, precisamos primeiro identificar, quantitativamente, as suas características em termos de parâmetros QoS. Por isso, a fase inicial da arquitetura proposta contém um módulo de monitoração.
3.1
Monitoração Dinâmica de Fluxos
Em um ambiente de QoS, caberá ao provedor [4], escolher o serviço que melhor se ajuste às necessidades das aplicações de seus usuários. Esta tarefa, entretanto, nem sempre é trivial e pode implicar em uso inadequado dos recursos, seja pela superutilização, seja pela subutilização dos mesmos.
Um mecanismo que observe o tráfego dinamicamente e determine qual o serviço mais adequado ao mesmo, além de essencial ao mapeamento automático, pode ser encarado como uma importante ferramenta de auxílio ao Provedor de Serviços Internet - ISP (ver Fig. 1).
Basicamente, a monitoração dos fluxos implica em proceder medições em unidades de tempo preestabelecidas. A avaliação estatística dos resultados, feita através de uma interação com o marcador, permitirá que se eleja o serviço mais adequado. Atuando de forma semelhante ao IP Switching [3] quanto a monitoração e observação de fluxos IP, poder-se-ia obter vantagens em dois importantes aspectos:
O ISP não mais agiria intuitivamente na tarefa de escolher um serviço adequado as suas aplicações. Isso implicaria em uma racionalização de seus recursos, uma vez que o processo se daria de forma automática.
Além disso, esse novo componente traria uma contribuição ímpar no processo de mapeamento interdomínios.
Figura 1. Monitoração e Marcação Dinâmicas de Fluxos.
Esse simples processo de avaliação de amostragem pode disponibilizar parâmetros essenciais a um mapeamento mais eficiente. Por exemplo, monitorando dinamicamente os fluxos pode-se deduzir qual a taxa média de transmissão, caracterizar rajadas, etc.
Deve-se considerar que um período inicial de ajuste será necessário para adequar as leituras aos respectivos serviços. Para fluxos duradouros mostramos que o efeito desta fase de ajuste é mínimo na QoS fim-a-fim. Há de se destacar também que esse ajuste incide nas taxas efetivas e não nas aproximadas. Isso minimiza o desperdício de recursos resultantes de reservas super dimensionadas ou inativas.
3.2
Negociação entre Domínios Heterogêneos
O elemento da rede responsável pelo processo de negociação entre os diversos Domínios continua sendo o BB (Bandwidth Broker). Para que a negociação ocorra de forma transparente e uniforme, faz-se necessário que alguns serviços sejam parametrizados segundos seus requisitos de QoS. Um exemplo dessa proposta de parametrização é mostrado na Tab. 1 [1].
Tabela 1. Parametrização segundo requisitos de QoS.
3.3
Arquitetura Interna do Bandwidth Broker
No protocolo proposto cada BB guardaria uma tabela denominada PPT (Policy Parameterization Table). A PPT faria a associação de requisitos de QoS aos serviços das diversas arquiteturas (ex. serviço EF-Premium em DiffServ associado aos requisitos de vídeo Interativo - Tab. 2).
Tabela 2. Policy Parameterization Table (PPT).
Já nos roteadores de borda uma segunda tabela denominada FRT (Flow Requirements Table) guardaria os requisitos de QoS de cada fluxo, individualmente (Tab. 3). Esses requisitos seriam comparados com os da PPT, no momento da migração, e seriam mantidos durante o tempo de transmissão.
Tabela 3. Flow Requirements Table (FRT).
3.4
Manutenção das Tabelas PPT e FRT
Para alimentar e atualizar a tabela FRT, poder-se-ia fazer uso de um processo de sinalização entre o transmissor e os nós de borda. Nossa proposta consiste na utilização de mensagens com a estrutura mostrada na Fig. 2. Esta sinalização seria feita no início da transmissão, tão logo o BB negociasse os recursos fim a fim.
Figura 2. Lay-out da Mensagem usada na sinalização. A tabela PPT, como é responsável pelo armazenamento das políticas de mapeamento, seria atualizada via COPS (Common Open Policy Service) [10].
3.5
Estudo de Caso
Nas próximas subseções mostraremos os detalhes de mapeamento entre Domínios heterogêneos típicos de QoS: IntServ-RSVP, DiffServ e MPLS.
3.5.1
mapeamento intserv-diffserv
Esta situação supõe que um fluxo, de vídeo por exemplo, será enviado de uma fonte localizada no Domínio RSVP para um destino localizado no Domínio DiffServ. O procedimento inicial requer uma sinalização da fonte com o BB (RAR). O objetivo é fornecer os requisitos necessários a negociação com os administradores de outros Domínios. Também faz-se necessário uma atualização da tabela de requisitos de fluxos (FRT), mantida nos roteadores de borda.
Caberá então, aos roteadores de borda, consultar o BB local e comparar as entradas da tabela de requisitos de fluxos (FRT) às da tabela de parametrização de políticas (PPT). Supondo que a
taxa reservada para o vídeo, via RSVP, fosse de 500k e que suas características de QoS fossem equivalentes as da Tab. 1 (Streamed Video), o mapeamento se daria no serviço Premium-EF do Domínio DiffServ.
3.5.2
mapeamento diffserv-mpls
Para viabilizar o mapeamento, as rotas são associadas a etiquetas MPLS (labels) que , por sua vez, são associadas a um conjunto de requisitos de QoS na tabela de parametrização de políticas (PPT). Dessa forma pode-se fazer o mapeamento com base na rota mais adequada às características de QoS de determinado fluxo.
No caso do mapeamento específico DiffServ-MPLS, basta obter, no Domínio MPLS, o rótulo de entrada equivalente ao serviço usado. (AF11, EF, etc.) Exemplo disso seria, na PPT, vincular a etiqueta "1" ao serviço EF.
3.5.3
trabalhos relacionados
A IETF mantém um WG (Work Group) chamado ISSLL (Integrated Services over Specific Link Layers) [20] que discute propostas de mapeamento de Serviços Integrados sobre Domínios de Serviços Diferenciados. No draft [21] existe uma proposta de mapeamento sobre as classes AF e EF. Tal mapeamento prevê o controle tanto a nível de Domínio quanto a nível do caminho percorrido pelo fluxo mapeado até o cliente (PATH). A informações necessárias ao mapeamento são obtidas via TSPEC (Traffic Specification). Para acomodar esse tráfego adicional, cria-se uma instância dos PHBs requeridos no mapeamento. No caso de mapeamento AF o controle será feito por um token bucket e no caso do mapeamento EF pelo escalonador. O mapeamento pode ocorrer tanto a nível de carga controlada (Controlled load Service), quanto de serviço garantido (Guaranteed Service). Essa proposta entretanto é restrita ao mapeamento entre dois Domínios específicos.
4.
ANÁLISE DE DESEMPENHO
Para mostrar a importância do mapeador proposto, apresentaremos uma análise de qualidade do serviço fim a fim em um ambiente com diferentes arquiteturas de QoS. A Fig. 3 reflete a topologia utilizada no processo de simulação feito com o Network Simulator versão 2.1b5 [18]. Para avaliar o desempenho, criou-se uma estrutura composta de 23 nós ligados por enlaces que variam de 512Kbps a 2Mbps e atrasos de 10 milisegundos onde serão transmitidos fluxos de vídeo e áudio. A topologia envolve três diferentes tecnologias: IntServ (RSVP), DiffServ e MPLS. Deve-se considerar que o Domínio MPLS implementa um mecanismo de Engenharia de Tráfego que otimiza o uso da rede permitindo assim que os fluxos de vídeo e áudio sejam encaminhados pelo trajeto menos congestionado (N12,N16,N13), enquanto que os demais fluxos usam o caminho mais curto (N12,N13), porém extremamente congestionado
.
Espera-se, com isso, mostrar que a qualidade fim a fim das aplicações pode ser mantida com um processo eficiente de mapeamento Interdomínios.
O experimento consiste em enviar fluxos de fontes CBR, via UDP, baseadas no Domínio RSVP para destinos baseados no Domínio MPLS (ver Tab. 4) e analisar os resultados nos pontos de medição denominados "A", "B" e "C" conforme mostra a Fig. 3. Três métricas de análise são usadas para se estabelecer um comparativo com e sem o protocolo de mapeamento proposto: vazão, atraso e jitter. O tempo total de simulação foi de 70 segundos.
Figura 3. Topologia Utilizada na Simulação.
Apenas os fluxos que retratam áudio e vídeo (provenientes de N0 e N1 com destino a N13) foram mapeados. Os demais serviram como tráfego de background. Os detalhes são mostrados na Tab. 4.
Tabela 4. Fontes de Tráfego.
Inicialmente mostraremos o comportamento das médias aritméticas de vazão (fluxos de vídeo e áudio) nos três pontos de monitoração especificados na Fig. 3. Nesta etapa, cada medição foi realizada em um Domínio diferente, sem o uso do mapeador. O resultado, que pode ser observado no Fig. 4, apresenta uma queda progressiva na vazão a medida que novos Domínios são percorridos.
Figura 4. Monitoração de Vazão Média sem o Mapeador
O mesmo experimento foi reproduzido, desta vez com o uso do mapeador proposto atuando nos pontos especificados na Fig. 3. O resultado, que pode ser observado na Fig. 5, apresenta uma vazão estável nos três pontos de monitoração. Como as mesmas condições foram mantidas, pode-se atribuir, à eficiência do mapeador, a manutenibilidade na vazão média dos fluxos de vídeo e áudio. Esta avaliação enfatiza a necessidade de mapeamento Interdomínio, sem o que a qualidade fim a fim das aplicações ficaria bastante comprometida.
.
Figura 5. Monitoração de Vazão Média com o Mapeador .
A perda que ocorre sem o processo de mapeamento pode ser visualizada na Fig. 6. Aqui mostramos a vazão média no ponto "C" (Fig. 3) com e sem o uso mapeador.
É importante frisar que a eficiência do processo de monitoração depende de um bom provisionamento de recursos nos diversos Domínios. Uma rede, em situação de sobrecarga generalizada, não apresentará melhorias significativas para fluxos mapeados.
Figura 6. Monitoração da Vazão Média fim a fim.
Uma vez que os recursos do mapeador são negociados via Bandwidth Brokers, temos uma certa garantia de que os Domínios envolvidos oferecem condições mínimas para fazer fluir o tráfego que estão recebendo.
Outras métricas avaliadas, dentro das mesmas condições, foram o atraso e o jitter fim a fim. As Figs. 7 e 8 refletem, respectivamente, a média dos atrasos de vídeo e áudio computados no ponto "C" (vide Fig. 3) com e sem o uso do mapeador.
Figura 7. Monitoração do Atraso Médio.
Como pode-se observar, a média dos atrasos, de praticamente 100% dos pacotes, fica em torno de 120 milisegundos, o que é aceitável para aplicações de vídeo e áudio. Isso quando o mapeador é usado. Sem ele este valor sobe para cerca de 400 milisegundos.
Avaliando a métrica jitter, ou seja, a variação do atraso fim a fim, os ganhos também foram significativos. Usando-se o mapeador, os níveis médios de praticamente 100% dos pacotes ficaram em torno de 3 milisegundos. Sem ele estes valores sobrem para cerca de 14 milisegundos. A Fig. 8 mostra os resultados obtidos.
Figura 8. Monitoração do Jitter Médio.
Os patches necessários à reprodução deste experimento poderão ser requeridos enviando-se e-mail, com subject "Patches do MATRIX", para msc@mauro.margalho.nom.br.
5.
CONCLUSÃO
Observa-se, na simulação, que parâmetros como a vazão, o atraso e o jitter sofrem a influência significativa de um processo de mapeamento eficiente. Estes indicativos nos fazem acreditar na eficiência do modelo.
Deve-se considerar que interoperabilidade é um dos requisitos mais importantes em redes WAN. Por outro lado, não se pode impor um padrão. Esta, inclusive, já vem sendo uma política adotada pela IETF. Daí surge a necessidade de se definir políticas e protocolos que permitam, às diversas aplicações, trafegarem sem perda de qualidade. Nossa contribuição converge para maior integração das tecnologias de QoS. Estas vem se firmando, dia a dia, como uma tendência já para os próximos anos na Internet2.
Vemos, como importante vantagem da proposta apresentada, uma maior transparência para os ISPs que, em grande maioria, não têm qualificação para proceder as diversas intervenções de negociação e mapeamento exigidos em ambientes heterogêneos de QoS.
Uma variedade de soluções enfoca QoS dentro de um escopo local. Ao propormos o mapeamento baseado em uma extensão dos BBs, estamos manifestando nossa preocupação com gerenciamento de QoS fim-a-fim.
Deve-se ressaltar que o protocolo apresentado não é restrito ao mapeamento interdomínios. Ele também pode ser usado para interligar e classificar o tráfego, observando redes de acesso e
Hosts que ainda não têm a capacidade de fazer reservas ou
trabalhar com QoS. Por conseguinte, sua importância na convivência harmônica entre os ambientes existentes e aqueles que estão surgindo.
Como trabalhos futuros sugerimos a exploração de BBs dinâmicos, onde políticas de mapeamento podem ser avaliadas em função de fatores como hora do dia, caminho fim-a-fim adotado, contratos por usuários, etc.
6.
REFERÊNCIAS
[1] Croll, A.; Packman, E.; "Managing Bandwidth - Deploying QoS in Enterprise Networks", Prentice Hall, ISBN: 0-13-011391-3, http://www.phptr.com, 1999 (1)
[2] Ferguson, P.; Huston, G.; "Quality of Service - Delivering QoS on the Internet and in Corporate Networks", Wiley Computer Publishing, ISBN: 0-471-24358-2, 1998. [3] Newman, P.; Minshall, G.; Lyon, T.; Huston, L.; "IP
Switching and Gigabit Routers", IEEE Comunications Magazine, January 97
[4] Plzak, R.; Wells, A.; Krol, E.; "FYI on Questions and Answers – Answers to Commoly Asked 'New Internet User' Questions"; RFC2664, August 99
[5] Jacobson, V; Nichols, K; Poduri, K.; "An Expedited Forwarding PHB"; RFC2598, June 99
[6] Heinanen, J.; Baker, F.; Weiss, W.; Wroclawski, J.; "Assured Forwarding PHB Group", RFC2597 June 99 [7] Blake, S.; Black, D.; Carlson, M.; Davies, E.; Wang, Z.;
Weiss, W.; "An Architecture for Differentiated Services", RFC2475, December 98
[8] Braden, R.; Zhang, L.; Berson, S.; Herzog, S.; Jamin, S.; "Resource Reservation Protocol", RFC2205, September 97. [9] Braden, R.; Clark, D.; Shenker, S.; "Integrated Services in the Internet Architecture: na Overview", RFC1633, June 94.
[10]Boyle, J.; Cohen, R.; Durham, D.; Herzog, S.; Rajan, R.; Sastry, A.; "The COPS Protocol"; work in progress, draft-ietf-rap-cops-08.txt, 99.
[11]Nielson, R.; Wheeler, J.; Reichmeyer, F.; Hares, S.; "A Discussion of Bandwidth Broker Requirements for Internet2 Qbone Deployment", version 0.7; August 99. [12]Rezende, J. F.; "Assured Service Evaluation"; Globecom'99
General Conf., 99.
[13]Xiao, X.; Ni, L.M., "Internet QoS: A Big Picture, IEEE Network", March/April 99.
[14]Ferguson, P.; Huston, G.; "Quality of Service in the Internet: Fact, Fiction or Compromise?", July 98, presented at INET’98, Geneva, Switzerland.
[15]Greis, M.; "An Implementation of RSVP for the Network Simulator NS-2"; University of Bonn - http://titan.cs.uni-bonn.de/~greis/rsvpns.
[16]UCAID, Internet2 Project - http://www.internet2.edu. [17]Murphy, Sean; "A diffserv implementation for the ns
simulator "; 99 http://www.teltec.dcu.ie/~murphys/ns-work/diffserv/index.html;
[18]Fall, K.; Varadhan, K.; "ns Notes and Documentation", April 98, http://www-mash.cs.berkeley.edu/ns.
[19]DiffServ Work Group (Differentiated Service) http://www.ietf.org/html.charters/diffserv-charter.html. [20]ISSLL Work Group (Integrated Services over Specific Link
Layers); http://www.ietf.org/html.charters/issll-charter.html [21]Wroclawski, J.; Charny, A.; "Integrated Service Mappings for Differentiated Services Networks", Internet Draft; Expires September, 2000; http://search.ietf.org/internet-drafts/draft-ietf-issll-ds-map-00.txt.
