Re-alocação Dinâmica de Banda em Redes MPLS
Taumaturgo Antônio M. Oliveira1, Eduardo G. Nobre2, Joaquim Celestino Júnior1
1
LARCES – Universidade Estadual do Ceará (UECE)
Av. Paranjana 1700 – Itaperi – 60740-000 – Fortaleza – CE – Brasil
2
Programa de Pós-Graduação em Engenharia Elétrica Universidade Federal do Ceará (UFC)
Av. Mr. Hull, s/n – Pici – 60455-760 – Fortaleza – CE – Brasil
{taumaturgo, eduardo, celestino}@larces.uece.br
Abstract. The objective of this paper is to present a performance comparison
between the static bandwidth reallocation and dynamic bandwidth reallocation in MPLS networks and to show the efficiency of the dynamic reallocation over the static reallocation. This comparison was realized by Network Simulator 2 simulations. To enable the simulation of the dynamic re-allocation, we had to implement the RFC 3214 concepts.
Resumo. O objetivo deste artigo é apresentar uma comparação de desempenhos
entre as re-alocações estática e dinâmica de banda em redes MPLS e mostrar a eficiência da re-alocação dinâmica sobre a estática. Esta comparação foi realizada com base em simulações executadas no Network Simulator 2. Para habilitar a simulação da re-alocação dinâmica, implementamos os conceitos da RFC 3214.
1. Introdução
Nos últimos anos a intensidade das transmissões dos diversos tipos de mídias através da Internet tem aumentado, exigindo que os pacotes que as transportam tenham tratamento diferenciado, como, por exemplo, a garantia de entrega, de retardo mínimo e de máxima variação do retardo, que tornam o serviço qualificado para o usuário final.
O desenvolvimento das tecnologias de transmissão de dados possibilitou o surgimento das redes de alta velocidade com capacidade de transportar informações na ordem de milhões de bits por segundo. A existência dessas redes tornou possível a utilização de aplicações multimídia que requerem grande capacidade de transmissão. No entanto, a migração das redes antigas para as de alta velocidade tem se mostrado demasiadamente lenta, tendo em vista o custo para sua aquisição, proporcionando ao IPv4 uma vida mais longa do que era esperada para este protocolo. Permanecem, assim, as redes que utilizam protocolos não adaptados para a qualidade de serviço, como o IPv4.
O MPLS (Multiprotocol Label Switching) tem então um papel importante, pois, principalmente, possibilita o estabelecimento de circuitos virtuais através dos diversos tipos de protocolos e tecnologias utilizadas pelas redes ao longo do caminho de uma conexão entre dois dispositivos. O controle sobre esses circuitos virtuais possibilita a implementação de políticas de qualidade de serviço aliadas à engenharia de tráfego.
A engenharia de tráfego preocupa-se com a otimização de desempenho operacional nas redes, em geral une a tecnologia a princípios científicos para medir, modelar, caracterizar e controlar o tráfego e a aplicação de tais conhecimentos e técnicas para alcançar objetivos
específicos (dependentes do contexto do problema) de desempenho [Awduche 1999]. É um processo que melhora a utilização da rede pela tentativa de criar uma distribuição uniforme e diferenciada do tráfego através da mesma. Um dos resultados desse processo é a eliminação do congestionamento em qualquer caminho. É importante notar, ainda, que a utilização de engenharia de tráfego nem sempre implica na escolha do menor caminho entre dois dispositivos. É possível que, para dois fluxos de pacotes de dados, os pacotes percorram caminhos completamente diferentes, mesmo se as estações de saída e chegada forem iguais para ambos os fluxos.
O grande objetivo da engenharia de tráfego, portanto, é facilitar operações eficientes e confiáveis da rede enquanto simultaneamente otimiza a utilização dos recursos e o desempenho do tráfego [Awduche 1999]. Em uma rede de comunicação, um dos recursos que pode ter sua utilização otimizada é a largura de banda. Em relação a esse recurso, o tráfego multimídia geralmente não possui comportamento estático. Grande parte do tráfego é do tipo variável que, durante a conexão, altera suas necessidades. Um exemplo desse fato é a transmissão de vídeo comprimido. Para garantir essa transmissão, uma reserva de banda levando em conta o valor de pico pode ser realizada. Isso garante a transmissão, mas subtiliza os recursos da rede. Então, a solução mais correta seria inicialmente alocar a banda com um valor médio, ou até mesmo mínimo e, durante a transmissão, ao surgir a necessidade de alteração de banda, renegociar esse valor.
Do mesmo modo, o ideal seria que a rede MPLS pudesse manter os circuitos virtuais dos usuários sempre alocados e não necessitasse alocá-los. Em uma situação real, a re-alocação de circuitos virtuais é uma tarefa comum. A engenharia de tráfego aliada ao MPLS possibilita que esta tarefa seja realizada automática e estaticamente. A proposta da RFC 3214 [Ash 2002] é tornar a re-alocação estática em dinâmica, agilizando e facilitando o processo.
Esse trabalho trata de engenharia de tráfego em redes MPLS, com foco voltado para o gerenciamento de re-alocação de banda passante. Ao tratar o gerenciamento da banda de forma dinâmica, podem ser feitos ajustes nos caminhos estabelecidos, sem prejudicar o serviço prestado ao cliente.
A contribuição desse trabalho pode ser vista principalmente como a análise comparativa de duas formas de re-alocação de banda no MPLS, estática e dinâmica, demonstrando a eficiência da re-alocação dinâmica sobre a estática. Esta análise foi feita a partir de dados coletados de simulações realizadas no MNSv2 [MNSv2 2001] que é um pacote para o Network Simulator 2 [NS2 2001] que habilita a simulação de redes MPLS. As simulações utilizam novas características (propostas pela RFC 3214), por nós implementadas diretamente no pacote MNSv2, que até então não estavam incorporadas.
2. Qualidade de Serviço em Uma Rede TCP/IP
A qualidade de serviços em uma rede TCP/IP está totalmente vinculada à necessidade de tratamentos diferenciados a serem dados aos diferentes tipos de aplicações. Desde o seu desenvolvimento, a rede TCP/IP foi definida para ser utilizada por diversos tipos de tecnologias e meios físicos existentes, fossem eles confiáveis ou não confiáveis e de alto ou baixo desempenho. Para atender a tais requisitos, desde o início a simplicidade foi a premissa que norteou o desenvolvimento das redes/protocolos.
No entanto, ao longo do tempo, novas exigências apareceram e se avolumaram, o que expõe os usuários, para determinados tipos de serviços, às restrições do protocolo IP tais como: baixa garantia de entrega, descarte de pacotes, sobrecarga na reordenação dos pacotes no destino e alta variação de retardo, em condições (comuns) de congestionamento. Estas
restrições fazem com que as aplicações possíveis de serem utilizadas na rede sejam aquelas que requerem menos restrições para o seu funcionamento correto, como as aplicações de transferência de dados, que permitem atraso e perda de pacotes, por exemplo.
Contratos de serviço, denominados SLAs (Service Level Agreement), devem ser realizados entre as partes através de protocolos que trabalhem com IP e devem estabelecer parâmetros para garantia do serviço. A partir do momento em que os níveis de serviço contratados no SLA são estabelecidos, obtém-se o resultado esperado e a qualidade desejada é garantida. É importante frisar que estes serviços poderão sofrer variações e novos contratos poderão ser estabelecidos ao longo do período. Isto pode ser obtido de uma forma que os serviços utilizados pelos usuários sofram, temporariamente ou não, uma solução de continuidade. Daí a necessidade das alterações ocorrerem dinamicamente, para que o usuário seja atendido em sua plenitude, sem sofrer interrupções da sua atividade durante a troca de parâmetros.
3. MPLS
O MPLS (Multiprotocol Label Switching) é uma técnica de comutação de rótulos que fornece significativos benefícios às redes com uma arquitetura somente IP, às redes com IP sobre ATM, ou redes com combinações de quaisquer outras tecnologias. Isto ocorre pela possibilidade de se trabalhar utilizando LSPs (Label Switched Paths), que são como circuitos virtuais estabelecidos através do núcleo da rede, definindo uma rota de encaminhamento para os pacotes, iniciando em qualquer roteador e terminando em qualquer outro roteador da rede [Rosen e Viswanathan, et al. 2001]
A principal característica de uma rede MPLS é a utilização de rótulos identificadores para determinar os caminhos a serem seguidos pelos pacotes. Estes rótulos possuem um tamanho de vinte bits (fixo). Para inserir o rótulo é necessário que este pacote seja mapeado em uma classe chamada FEC (Forwarding Equivalence Class). O pacote deverá ser encaminhado de acordo com os critérios estabelecidos pela classe a que pertence. No MPLS, FECs podem ser criadas diretamente a partir das tabelas de rotas.
A NHLFE (Next Hop Label Forwarding Entry) é a tabela principal, que contém todas as informações que devem ser aplicadas a um pacote (rotulado ou não) como, por exemplo, o endereço e a interface do próximo roteador, o novo rótulo a ser colocado e se o rótulo existente deve ser retirado. Esta tabela está presente em todos os roteadores de uma rede MPLS.
Ao entrar na rede, o endereço IP de destino do pacote é mapeado em uma FEC (como acontece nos roteadores IP comuns) e depois mapeado para uma NHLFE. A escolha do rótulo a ser adicionado ao pacote acontece a partir da tabela FTN (FEC-to-NHLFE), que é utilizada somente nos roteadores de borda e onde cada FEC é mapeada para uma ou mais NHLFEs. Quando duas ou mais NHLFEs são mapeadas, apenas uma deve ser escolhida.
No núcleo da rede MPLS, o mapeamento de cada rótulo em um conjunto de NHLFEs é realizado pela busca em outra tabela, chamada ILM (Incoming Label Mapping). Nesta tabela será escolhida uma entrada (NHLFE) a partir do rótulo, que irá determinar as operações a serem realizadas. Assim como a FTN, quando duas ou mais NHLFEs estão mapeadas, apenas uma deve ser escolhida.
LER (Label Edge Routers) é a nomenclatura utilizada para os roteadores que operam nas bordas da rede e geralmente suportam múltiplas portas de acesso através de diferentes tipos de rede tais como ATM, Frame Relay e Ethernet. Estes roteadores encaminham pacotes
rotulados através da escolha de um ou mais LSPs estabelecidos, ou podem criar novos LSPs que atenderão às novas demandas. É também de sua responsabilidade inserir e retirar rótulos dos pacotes no tráfego de entrada e saída da rede MPLS. Estes são os roteadores que utilizam a FTN (FEC-to-NHLFE).
Os LSRs (Label Switched Routers) são os roteadores que estão situados no núcleo da rede e têm a responsabilidade de fazer a troca, retirada e inserção de rótulos na pilha mediante o mapeamento na tabela ILM. Atuam, junto aos LERs, na manutenção dos LSPs.
3.1 LDP
O protocolo de distribuição de rótulos LDP (Label Distribution Protocol) é o protocolo padrão do MPLS que garante, por meio de troca de mensagens TCP e UDP, que todas as suas entradas estão atualizadas e sem conflitos, a fim de manter corretamente os LSPs. O LDP cuida das requisições e atribuições de rótulos entre os roteadores, bem como de todas as notificações. O MPLS não necessariamente utiliza somente um único protocolo de distribuição de rótulos. Protocolos já existentes foram estendidos para que a distribuição de rótulos possa ser adicionada, enquanto novos protocolos foram definidos apenas para o propósito de distribuição de rótulos [Andersson 2001].
Existem quatro categorias de mensagens no LDP: mensagens de Descoberta, para anunciar e manter a presença de um LSR na rede, através do protocolo UDP; mensagens de Sessão, para estabelecer, manter e terminar sessões TCP entre LSRs; mensagens de Advertência (requisição, mapeamento e liberação de rótulos), para criar, alterar e terminar mapeamentos ILM e FTN e mensagens de Notificação, para prover informações e sinalizar erros. As mensagens de Advertência são as que irão efetivamente manter os LSPs.
3.2 Usando CR-LDP para distribuição de rótulos
O CR-LDP (Constraint-Based Routing LDP) é um protocolo de distribuição de rótulos que adiciona características, como restrições e mensagens de erro ao LDP, a fim de se poder implementar engenharia de tráfego. As restrições do CR-LDP são parâmetros passados para os roteadores nas mensagens LDP a fim de determinar se eles podem ou não fornecer a qualidade de tráfego desejada. Esses parâmetros são: ER (Explicit Route), onde se indica um conjunto de nós ou um CR-LSP (Constraint-Based Routed LSP) já existente para serem seguidos; Tráfego (Traffic Parameters); Preempção (Preemption); LSP-ID; Classes (ou cores) de recursos (Resource Class) e Route Pinning [Jamoussi 2002].
A figura 1 demonstra como se dá o estabelecimento de um CR-LSP onde, para uma banda disponível, os parâmetros requisitam uma determinada porção dessa banda. O processo ocorre da mesma forma que no LDP, no qual o roteador de ingresso LER1 faz uma requisição de rótulo, mas com a diferença de que apenas os roteadores que podem oferecer a banda desejada responderão à requisição. Antes, o roteador faz uma verificação para certificar-se da existência de algum CR-LSP que atenda às especificações de banda que estão sendo solicitadas. Como, neste caso, não existe este CR-LSP, a requisição é transmitida através da rede, até chegar ao roteador de saída LER3. Caso os roteadores atendam às especificações de banda, os mesmos retornam mensagens de mapeamento de rótulos, que percorrem o caminho inverso.
Atribuição do rótulo “R” para FEC “F” Atribuição do rótulo “S” para FEC “F”
LER 1 LSR 2 LER 3
Requisição de atribuição da FEC “F” Requisição de atribuição da FEC “F”
Figura 1. Estabelecendo um CR-LSP
3.3 Modificando recursos dinamicamente utilizando MPLS.
A modificação de recursos de um CR-LSP é utilizada para adequação do mesmo às mudanças nas condições de tráfego da rede, acontecendo, portanto, após o estabelecimento deste e a verificação de que o mesmo está ativo.
A modificação dinâmica dos parâmetros de um CR-LSP está especificada em [Ash 2002] e depende primeiramente da verificação do LSPID e do campo “ActFlag” da mensagem de requisição. Quando uma mensagem de requisição de rótulo for enviada, os roteadores deverão verificar o LSPID desta mensagem. Caso não exista nenhum CR-LSP com este identificador, a requisição deve ser tratada como uma mensagem de requisição normal. Caso exista e o campo “ActFlag” contiver o valor “modificar” o roteador detectará que está havendo uma requisição de mudança de alguma característica deste CR-LSP e o mesmo terá sua rota ou seus recursos modificados, dependendo dos parâmetros da mensagem.
Após a conclusão do mapeamento, existirão dois conjuntos de rótulos para uma mesma FEC e um mesmo CR-LSP estabelecidos, enquanto que apenas o novo conjunto de rótulos estará em funcionamento. É necessário que o rótulo antigo seja liberado, o que é feito a partir do roteador de origem do CR-LSP, através de uma mensagem de liberação específica para os rótulos antigos.
No caso de um aumento de banda, por exemplo, o valor requisitado na mensagem não é o novo valor total da banda a ser utilizado, mas, apenas a diferença entre o valor anterior e o novo valor a ser utilizado. Tal procedimento é necessário para evitar que haja alocação desnecessária e desperdício de banda.
3.3.1 Re-alocação de recursos
Para melhor explicar como ocorre o processo de re-alocação de recursos em redes MPLS, tomemos como exemplo uma situação em que uma interface de um roteador dispõe de uma banda de 5Mbps. É então requisitado inicialmente um CR-LSP a partir desta interface e que utilize 3Mbps. Em virtude de uma necessidade por parte do serviço, a banda utilizada pelo CR-LSP deve ser alterada para 5Mbps. Este exemplo está ilustrado na figura 2, onde, a primeira coluna de cada tabela contém a FEC, o LSPID, o antigo rótulo de entrada (ROTE), o antigo rótulo de saída (ROTS) e a banda inicialmente alocada (BAND), enquanto a segunda coluna contém os valores do novo CR-LSP a ser ativado.
Na figura 2, com um CR-LSP já estabelecido, o usuário solicitou uma ampliação de banda de 3Mbps para 5Mbps. Neste momento, o roteador de ingresso (R1) requisita novamente um CR-LSP com o mesmo LSPID do CR-LSP inicial, mas, com o ActFlag contendo o valor “modificar” e a banda adicional solicitada de 2Mbps. Em cada roteador do caminho (Ri, Rj e Rk) é verificado se o LSPID já existe e, após a confirmação, é criado um novo rótulo de entrada sem liberar o antigo, enquanto a banda adicional de 2Mbps é alocada. Ao chegar no último roteador, este retorna uma mensagem de mapeamento e o processo se repete pelo caminho inverso, criando-se um novo rótulo de saída em cada roteador. Nota-se que, ao final deste processo, dois conjuntos de rótulos pertencem a um mesmo CR-LSP e o
roteador de ingresso agora direciona o tráfego utilizando apenas o novo rótulo de saída. FEC 1 1 LSPID 1 1 ROTE ROTS A B BAND 3 2 FEC 1 1 LSPID 1 1 ROTE A B ROTS X P BAND 3 2 FEC 1 1 LSPID 1 1 ROTE X P ROTS Y Q BAND 3 2 FEC 1 1 LSPID 1 1 ROTE Y Q ROTS BAND 3 2 Rl Ri Rj Rk Mensagem de mapeamento Mensagem de requisição
Figura 2. Modificação da banda utilizada por um CR-LSP
3.3.2 Liberando os rótulos
Após o novo conjunto de rótulos estar ativado, é necessário liberar o antigo. A figura 3 ilustra o processo. O roteador de entrada envia uma mensagem de liberação através dos roteadores que faziam parte do antigo CR-LSP, até o roteador de saída. Esta mensagem leva consigo o LSPID e o rótulo antigo para indicar qual conjunto de rótulos deve ser liberado. Como, neste caso, trata-se de um aumento de banda, a operação realizada é apenas a liberação dos rótulos. No caso de uma redução de banda, além da liberação do rótulo, a diferença de banda também será liberada. FEC 1 1 LSPID 1 1 ROTE ROTS A B BAND 3 2 FEC 1 1 LSPID 1 1 ROTE A B ROTS X P BAND 3 2 FEC 1 1 LSPID 1 1 ROTE X P ROTS Y Q BAND 3 2 FEC 1 1 LSPID 1 1 ROTE Y Q ROTS BAND 3 2 Rl Ri Rj Rk Mensagem de liberação
Figura 3. Liberação dos rótulos
Ao final deste processo, a banda disponível para o CR-LSP estará acrescida de 2Mbps passando de 3Mbps para os 5Mbps solicitados pelo usuário. Neste caso, onde a banda total disponível é de 5Mbps, a re-alocação estática não seria viável, pois, este processo consistiria da criação de um CR-LSP de 5Mbps para, depois, liberar o CR-LSP de 3Mbps. Já o processo de re-alocação dinâmica apenas incrementa a diferença de 2Mbps no CR-LSP existente. Um outro fator também preponderante é que, ao alocar apenas a diferença de banda, evita-se a interrupção da transmissão dos dados.
4. Simulando um exemplo no Network Simulator 2
O Network Simulator 2 [NS2 2001] é um simulador de redes desenvolvido nas linguagens C++ e Object TCL e tem como vantagens o fato de ter seu código aberto e possuir pacotes que o auxiliam na simulação de diversos tipos de redes. Para realizar as implementações e simulações apresentadas neste artigo, baseamo-nos no pacote MNSv2 [MNSv2 2001], que foi desenvolvido para habilitar simulações de redes MPLS no NS2.
Apesar do pacote MNSv2 conter muitas funções do MPLS, ainda não continha a modificação dinâmica de CR-LSPs, especificada em [Ash 2002]. Algumas novas funções foram criadas e outras alteradas dentro do código fonte do MNSv2 para permitir esta modificação.
Nesta seção serão apresentadas duas simulações, no mesmo cenário, de modificação de CR-LSP: uma de re-alocação estática de banda e outra de re-alocação dinâmica. Utilizamos o seguinte cenário: duas estações (“A” e “B”) conectadas através de quarenta e oito roteadores MPLS. Os roteadores de números “1” e “48” são LERs. Os outros roteadores são LSRs que irão encaminhar os pacotes rotulados. A estação “A” está conectada ao roteador “1”, enquanto a estação “B” ao roteador “48”, conforme mostra a figura 4. O enlace entre a estação “A” e o roteador “1” possui 3Mbps de banda, enquanto todos os outros enlaces do cenário possuem 1Mbps. O retardo de todos os enlaces é de 1ms. O tamanho máximo dos pacotes é de 1500 bytes. Todos os roteadores possuem enfileiramento do tipo CBQ
(Class-Based Queueing), método que prioriza o descarte de pacotes baseando-se em classes.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 A B
Figura 4. Cenário dos testes de simulação
Neste cenário existem: seis fluxos com característica de melhor esforço simples (Simple Best-effort Traffic ou SBT), SBT, SBT1, SBT2, SBT3, SBT4 e SBT5, um fluxo de melhor esforço com alta prioridade (Higher priority Best-effort Traffic ou HBT), HBT e dois fluxos de tempo real (Real-Time ou RT), RT1 e RT2. Todos os fluxos utilizam o protocolo UDP com tamanho do pacote 200bytes e retardo de 5ms. Também, todos os fluxos iniciam na estação “A” e possuem um volume de tráfego de 350Kbps perfazendo um total requerido de 3,1Mbps para uma banda disponível de apenas 1Mbps entre os roteadores do núcleo.
No primeiro teste desta simulação, tentamos aumentar a banda reservada pelo fluxo RT2 (que flui por um CR-LSP de LSPID 1300) de 350Kbps para 450Kbps. Este primeiro processo de modificação estática de CR-LSP constituiu-se dos seguintes passos:
1. Criação de um novo CR-LSP temporário de LSPID 1400 para reservar 450Kbps de banda, uma vez que o processo estático não permite a criação de um CR-LSP com o mesmo identificador 1300;
2. Atribuição do fluxo RT2, já associado ao CR-LSP 1300, ao 1400, numa tentativa de não interrupção de serviço;
3. Liberação do CR-LSP 1300.
Essa primeira tentativa resultou no não-estabelecimento do CR-LSP 1400, pois, o pedido de recurso foi barrado pelo controle de admissão que retornou o erro “Recurso não disponível”. Isto ocorreu porque havia apenas 300Kbps de banda disponível para os tráfegos RTs (700Kbps de um total de 1Mbps), o que não suportou o pedido de 450Kbps.
Como esse teste resultou no impedimento da alocação dos novos recursos, um novo teste foi feito, apenas invertendo-se os passos 1 e 2 do procedimento anterior. Inicialmente liberamos o CR-LSP estabelecido com 350Kbps, para, posteriormente, estabelecermos um novo CR-LSP com 450Kbps.
Nesse segundo teste de alocação estática, consideramos que o operador do sistema, ao solicitar a modificação do recurso, disparou a liberação do antigo CR-LSP e, em seguida, estabeleceu o novo. Considerou-se também que, entre a liberação do antigo CR-LSP e o início do estabelecimento do novo, houve um intervalo de 60ms. Este intervalo foi escolhido por ser o retardo máximo aceitável para uma transmissão de tráfego de voz não-compactada, que é a característica do fluxo RT2. Este valor dependerá de vários fatores como, por exemplo, a velocidade de processamento dos roteadores, os recursos disponíveis na rede e os métodos utilizados pelo operador do sistema para realizar a operação.
Uma observação a ser feita neste segundo teste é que há uma proporcionalidade entre o tempo de substituição dos CR-LSPs e o número de pacotes perdidos neste intervalo, quando a rede está na sua utilização máxima. Neste teste, obtivemos 2522 pacotes enviados com sucesso pelo fluxo RT2.
Observando a metade superior do gráfico 1 (resultante do segundo teste, onde o eixo X é o tempo decorrido e o eixo Y a banda utilizada) verifica-se que, no intervalo de tempo entre a liberação do CR-LSP antigo (no 5º segundo) e o estabelecimento do novo (no segundo 5,06), a característica do fluxo RT2, que era de tempo real, foi modificada para melhor esforço por causa da inexistência de CR-LSP para transportá-lo. Tal fato provocou uma queda brusca no volume de banda utilizada por RT2 e um certo descarte de pacotes deste mesmo fluxo, durante o intervalo tempo. A partir do segundo 5,06 o fluxo RT2 volta a utilizar o CR-LSP e, portanto, gradativamente se estabiliza até atingir a utilização de banda de 450Kbps aproximadamente no segundo 5,4.
Os fluxos SBT e HBT, por terem prioridade menor que os RTs e estarem em uma situação de congestionamento, tiveram uma baixa utilização de banda, enquanto o fluxo RT1 não teve alteração na sua utilização de banda, como já era esperado.
Gráfico 1. Ampliação de banda do fluxo RT2 no 5° segundo, utilizando alocação estática de banda e o comportamento dos demais fluxos SBTs, HBTs e RT1
4.2 Simulando a modificação dinâmica de banda de um CR-LSP
Nesta simulação de alocação dinâmica de banda, também estabelecemos um CR-LSP de identificador 1300 com uma reserva inicial de 350Kbps de banda para o fluxo RT2. O cenário desta simulação tem as mesmas características do utilizado na alocação estática de banda: seis fluxos SBT, um fluxo HBT e dois fluxos RT, com 350Kbps de banda inicialmente alocada para todos.
Para a ampliação da banda foi utilizada a nova função “modify-crlsp-resource”. Esta função foi executada no 5º segundo pelo LER1 que enviou um pedido de ampliação de banda 100Kbps para o CR-LSP 1300. Não houve interrupção do serviço e nem problemas com o controle de admissão. Ao compararmos com a modificação estática de banda, a modificação dinâmica realizada no CR-LSP provocou um aumento de pacotes enviados com sucesso de 2522 para 2555. A vantagem da modificação dinâmica de banda, comparada com os 60ms gastos para a modificação estática de apenas um CR-LSP, foi um ganho real de 33 pacotes enviados. Como utilizamos pacotes de 200 bytes, isso significa que 6600 bytes não foram perdidos.
Ao observar a metade superior do gráfico 2 (semelhante ao gráfico 1), nota-se claramente o não-comprometimento do fluxo RT2, apesar da ampliação de banda. É importante relembrar que todos os fluxos juntos geram um total de tráfego de 3,1Mbps para uma banda disponível de apenas 1Mbps no núcleo da rede, provocando descarte de pacotes no LER1 para os fluxos com baixa prioridade.
Gráfico 2. Ampliação de banda do fluxo RT2 no 5° segundo, utilizando alocação dinâmica de banda e o comportamento dos demais fluxos SBTs, HBTs e RT1
Nos fluxos SBT, verifica-se uma utilização insatisfatória de banda e, assim como no processo estático, uma grande oscilação desta utilização durante a simulação. No fluxo RT1, que é um fluxo do tipo tempo real, não houve influência pelas modificações realizadas pelo procedimento dinâmico, mantendo a sua utilização de banda em 350Kbps, como estabelecido durante a reserva do início ao final do processo.
Também percebemos uma redução na totalidade de pacotes enviados pelos fluxos SBT de 622 (na simulação de modificação estática) para 613 pacotes, pois, na modificação dinâmica de banda, o fluxo RT2 não teve seus pacotes descartados.
O fluxo HBT, que é de melhor esforço com prioridade sobre os fluxos SBT, teve um rendimento levemente superior se comparado a estes fluxos, mas, com características de grande oscilação na utilização da banda e elevado descarte de pacotes. Por fim, o fluxo RT2, que passou pelo processo de modificação de reserva de banda, não sofreu nenhum descarte, desordem ou atraso de seus pacotes.
Apesar de mostrarmos nesta seção apenas a ampliação de banda de CR-LSPs, as implementações realizadas permitem também a sua redução. Esta operação é realizada do mesmo modo que a ampliação de banda, mas, com a diferença de banda sendo reduzida apenas ao final do processo, pela mensagem de liberação, e não pela mensagem de mapeamento, como acontece na ampliação.
5. Conclusões Finais
Nos testes de re-alocação estática, para ampliar a banda reservada por um CR-LSP sem correr risco de não aceitação do pedido de modificação, foi necessário interromper o CR-LSP, liberando-o. O único problema desta operação ocorreu entre o instante da liberação do antigo CR-LSP e o estabelecimento do novo, pois, neste intervalo de tempo, ou (1) armazena-se os pacotes que estão sendo transmitidos até que o novo CR-LSP esteja pronto para ser utilizado no envio destes pacotes ou (2), os pacotes são transmitidos e seguem por melhor esforço, sem
garantia de entrega e de reserva de banda e sem seguir por um caminho específico. Mesmo o armazenamento pode tornar-se problemático, pois, dependendo do volume de pacotes recebidos naquele instante pelo roteador, pode haver a necessidade de descarte de pacotes, o que não se admite para uma transmissão em tempo real. Neste artigo, utilizamos esta última opção, que foi permitir aos pacotes seguirem utilizando o melhor esforço. Nos testes, isto também provocou elevada perda de pacotes (devido ao congestionamento), inviabilizando a transmissão de dados em tempo real.
Diante das situações de perda de pacotes e de não estabelecimento do CR-LSP, constatou-se que, para haver segurança na transmissão dos pacotes de uma estação para outra, possibilitando qualquer modificação do volume de banda passante reservada pelo usuário sem a interrupção do CR-LSP, foi necessário que a re-alocação fosse realizada dinamicamente. Desse modo como implementamos, em nenhum momento houve descarte de pacotes, pois, não deixaram de trafegar através de um CR-LSP, mesmo com as modificações de suas características ocorrendo durante a transmissão.
Na re-alocação dinâmica de banda, ainda foi garantido que os pacotes seguissem sempre pelo caminho inicialmente estabelecido do CR-LSP e que os pacotes não chegassem desordenados ao seu destino. Isto evitou a sobrecarga da reordenação nas pilhas dos protocolos de níveis mais altos, evitando, também, mais um motivo de aumento de retardo. Referências
Andersson, L., et al. (2001) “LDP Specification”, RFC 3036, Janeiro.
Ash, J., et al. (2002) “LSP Modification using CR-LDP”, RFC 3214, Janeiro.
Ashwood-Smith, P. and Jamoussi, B. (1999) “MPLS Tutorial”, Nortel Networks, http://www.nanog.org/mtg-9905/ppt/mpls.ppt, Maio.
AT&T, FAQ: Transmission (2003), http://www.att.com/cpetesting/faq.html.
Awduche, D., et al. (1999) “Requirements for Traffic Engineering over MPLS”, RFC 2702, Setembro.
Bakin, D. S. (2001) “Application QoS Networking Infrastructure for High Performance, High
Reliability Web Operations”, http://www.ewh.ieee.org/r2/baltimore/Chapter/Comm/dlt_talk, Maio.
Black, U., MPLS and Label Switching Networks, Prentice-Hall, 2001.
Braden, R., et al. (1997) “Resource Reservation Protocol (RSVP) -- Version 1 Functional Specification”, RFC 2205, Setembro.
Conta, A., et al. (2001) “Use of Label Switching on Frame Relay Networks Specification”, RFC 3034, Janeiro.
Davie, B., et al. (2001) “MPLS using LDP and ATM VC Switching”, RFC 3035, Janeiro. Ethier, P. (1999) “How to set up a basic VPN between two OpenBSD gateways using
ISAKMP”, http://www.antioffline.com/ipsec/vpn/.
IEC, The International Engineering Consortium (2001) “Multiprotocol Label Switching”, http://www.iec.org/online/tutorials/mpls/, Outubro.
Jamoussi, B., et al. (2002) “Constraint-Based LSP Setup using LDP”, RFC 3212, Janeiro. Martins, J. (2002) “Qualidade de Serviço (QoS) em Redes IP, Princípios Básicos, Parâmetros
e Mecanismos”, http://www.networkdesigners.com.br/Artigos/qos/qos.html, Outubro. Metcalfe, R. and Boggs, D. (2002) “Ethernet: Distributed Packet Switching for Local
Computer Networks”, http://www.acm.org/classics/apr96/.
MNSv2: MPLS extension for NS2 (2001),
http://www.isi.edu/nsnam/archive/ns-users/webarch/2001/msg05364.html, Novembro.
Mota, O. T. (2000) “Internet com Qualidade: um Estudo da Proposta de Diferenciação de Serviços”, Pontifícia Universidade Católica do Rio de Janeiro (PUC).
NS2: Network Simulator versão 2.1b8a (2001), http://www.isi.edu/nsnam/ns/, Junho. Rosen, E., Tappan, D., et al. (2001) “MPLS Label Stack Encoding”, RFC 3032, Janeiro. Rosen, E., Viswanathan. A., et al. (2001) “Multiprotocol Label Switching Architecture”, RFC
3031, Janeiro.
Stallings, W. (2001) “Multiprotocol Label Switching MPLS”, Cisco Systems, http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac180/about_cisco_ipj_archive_art icle09186a00800c83a3.html.
Wang, Z., Internet QoS: Architectures and Mechanisms for Quality of Service. Morgan Kaufmann Publishers, 2001.
Wroclawski, J. (1997) “Specification of the Controlled-Load Network Element Service”, RFC 2211, Setembro.
