Nesse módulo, veremos como a qualidade de serviço (QoS) pode ser implementada em redes IP.

Transcrição

1 Nesse módulo, veremos como a qualidade de serviço (QoS) pode ser implementada em redes IP. A implementação do QoS envolve dois aspectos: mecanismos de controle de tráfego implementados nos roteadores e uma metodologia de QoS, que define como os mecanismos são utilizados. Os mecanismos de QoS alteram a forma de encaminhamento de pacotes pelos roteadores. Por default, a forma de encaminhamento adotada pelos roteadores é o FIFO (First In First Out), isto é, os pacotes são encaminhados pelo roteador na mesma ordem que são recebidos. Os mecanismos de QoS permitem diferenciar a forma que os pacotes são tratados, de forma a oferecer garantias para o tráfego transportado. As metodologias de QoS, por outro lado, definem como os diversos elementos da rede devem cooperar de forma a prover garantias fim-a-fim para o tráfego dos usuários. As metodologias atualmente propostas pelo IETF são: serviços integrados, serviços diferenciados e MPLS.

2 Podemos definir qualidade de serviço como sendo um conjunto de garantias que a rede oferece para o tráfego que está sendo transportado. Contudo, antes de iniciarmos a discussão sobre a necessidade de qualidade de serviço (QoS), é importante estabelecermos uma distinção entre as formas de comutação dos diversos tipos de tecnologias de rede disponíveis. A forma de comutação afeta diretamente como os recursos de uma rede são gerenciados e conseqüentemente, o tipo de garantias que são oferecidos para o tráfego. Como veremos, a necessidade de mecanismos adicionais para prover garantias de tráfego em uma rede comutada por circuito é muito menor que em redes comutadas por pacote. Nas redes comutadas por circuito, com as redes de telefonia baseadas em SDH, existe uma reserva explícita de recursos para todo o tráfego transportado. A banda total de um enlace da rede é dividida em slots multiplexados no tempo (canais). Nesse tipo de rede, existe um pedido explicito para estabelecimento do circuito. Se existe um canal disponível, o pedido é aceito. Caso contrário, ele é negado. Dessa forma, se um circuito é estabelecido, sempre haverá recursos reservados, independente de haver tráfego ou não. A vantagem desse modo é que o tráfego de diferentes canais não concorrem por recursos, de modo que o tráfego é transportado com o mesmo desempenho até que seja feito um pedido explícito de encerramento do circuito, e o canal seja liberado para outro usuário. A desvantagem desse modo é o grande desperdício de recursos, pois os recursos subutilizados em um canal não pode ser aproveitado pelos demais canais. Nas redes comutadas por pacotes a alocação de recursos é dinâmica, isto é, o recurso só é alocado quando existe tráfego. O modelo original proposto para a tecnologia IP seguia radicalmente este conceito. O modo de operação do IP era denominado de "melhor esforço", pois os pacotes eram servidos na medida em que chegavam na rede sem nenhum tipo de reserva prévia. Essa abordagem evita o desperdício de banda, mas pode levar a um desempenho muito pobre para o tráfego transportado se houver congestionamento (excesso de tráfego) na rede.

3 A qualidade de serviço pode ser medida através das garantias que a rede oferece para o tráfego transportado. Originalmente, o único modo de operação suportado pelo IP era o melhor esforço (best effort). Nesse modo, a qualidade de serviço oferecida para o tráfego transportado pode variar muito em condições de congestionamento. Existem basicamente dois tipos de garantia: de desempenho e de disponibilidade. As garantias de desempenho estão relacionadas a como a entrega do tráfego (pacotes) será feita. Os parâmetros que medem o desempenho são: Atraso: indica quanto tempo o pacote leva para ser enviado da origem até o destino Jitter (variação do atraso): indica que pacotes podem chegar espaçados de forma diferente em relação a como foram transmitidos, podendo, inclusive, chegar fora de ordem. Perda de pacotes: indica a porcentagem de pacotes transmitidos que chega ao seu destino A principal causa que afeta o desempenho de uma rede é o congestionamento, isto é, quando mais tráfego é injetado na rede do que ela é capaz de suportar. Algumas tecnologias de camada de enlace, como o ATM ou o Frame-Relay, já foram concebidas com o intuito de tratar esse problema. O mundo IP, contudo, ignorou o assunto até recentemente. Com a obsolescência gradativa da tecnologia ATM nos últimos anos, várias técnicas foram introduzidas para tratar desses problemas ao nível da camada de rede (IP). O objetivo deste módulo é justamente estudar essas técnicas.

4 A figura ilustra o relacionamento entre as métricas de desempenho e o congestionamento da rede. Primeiro, observe o desenho ilustrando a comunicação entre dois roteadores. O tráfego chega ao roteador "1" através dos enlaces A e B. O tráfego é então transmitido para o roteador 2 através do enlace C, que por sua vez encaminha os pacotes pelos enlaces D e E. Nesse cenário existem duas fontes de atraso: o atraso de propagação e o atraso de fila. O atraso de propagação é um valor constante (fixo) que independe da carga da rede. Ele corresponde ao tempo que um sinal elétrico ou ótico leva para se propagar através de um enlace de longa distância. Por exemplo, um enlace de fibra ótica conectando as cidades de São Paulo e Miami introduz um atraso de propagação na ordem de 100 ms. Esse atraso existe independentemente de a rede estar congestionada ou não. O atraso de fila é variável, pois depende da carga da rede. No cenário da figura, se a soma do tráfego que chega pelas enlaces A e B exceder a capacidade do enlace C, mesmo que momentaneamente, haverá formação de fila no roteador O mesmo ocorrerá no roteador 2, se a quantidade de pacotes exceder momentaneamente a capacidade dos enlaces D ou E. Como conseqüência, existe uma curva característica de atraso para redes de pacotes, conforme ilustrado pela figura. Essa curva é descrita como a probabilidade de um pacote sofrer uma certa quantidade de atraso. Observa-se que a probabilidade de um pacote chegar ao destino em um tempo menor que o atraso de propagação é zero. Para muitas aplicações, quando um pacote chega com atraso em demasia ele é considerado perdido. Na figura, a porcentagem de pacotes que chegam acima do máximo atraso aceitável é alfa. Uma porcentagem (1- alfa) dos pacotes será transmitida entre o atraso fixo e o valor máximo aceitável pré-definido.

5 A disponibilidade está relacionadas a garantias que o serviço de conectividade estará "quase" sempre disponível. As redes comutadas por circuito oferecem boas garantias de desempenho, mas podem sofrer com problemas de disponibilidade. Já as redes comutadas por pacotes podem sofrer com problemas de desempenho e disponibilidade. Em uma rede comutada por circuito o excesso de carga (por exemplo, um número excessivo de usuários fazendo chamadas telefônicas) pode provocar problemas de indisponibilidade, pois as chamadas só são atendidas quando existem recursos disponíveis na rede. Em uma rede comutada por pacotes, o excesso de carga causa problemas de desempenho. Outra causa de problemas de indisponibilidade são as falhas de equipamentos e da estrutura física (enlaces) da rede. Para esse tipo de causa, os seguintes parâmetros são utilizados para medir a disponibilidade da rede: MTBF (mean time between failures): indica o intervalo médio esperado entre duas falhas sucessivas da rede. Ele corresponde ao inverso da taxa de falhas (número de falhas pelo período observado). MTTR (mean time to recover): indica o tempo médio que o serviço leva para ser restaurado, uma vez que a falha aconteça. Disponibilidade: indica a porcentagem de tempo que serviço fica disponível. É calculado de acordo com a fórmula indicada na figura.

6 Um termo bastante usado quando ser fala em qualidade de serviço (QoS) é o "acordo de nível de serviço" (SLA - Service Level Agreement). O SLA é um acordo entre um cliente e um provedor de serviço. Geralmente, o SLA é definido em termos do desempenho fim-afim do tráfego, isto é, da conectividade entre dois pontos da rede. Por essa razão, o SLA é mais comum em circuitos virtuais vendidos para empresas do que para usuários residenciais. Na figura, considere que existe um SLA para transmissão de pacotes entre os pontos A e B. Geralmente o provedor do serviço só garante o SLA se o tráfego do usuário estiver dentro de um certo limite máximo. Um SLA possui dois componentes principais: Disponibilidade: (MTBF, tempo de recuperação). Desempenho: (atraso, jitter e perda de pacotes). Considerando aspectos desempenho, o SLA define em relação ao total de pacotes transmitidos pelo usuário: a) O tempo médio de atraso esperado para os pacotes. Esse tempo irá variar bastante de acordo com o tipo de tráfego transportado. Por exemplo, se o SLA se referir a um acordo para transmissão de tráfego VoIP pode-se definir que o atraso médio deverá ser inferior a 50 ms e o atraso máximo inferior a 100 ms. Uma outra forma de especificar o atraso é em termos de probabilidade. Por exemplo, a probabilidade do atraso ser inferior a 75 ms deve ser 99,9968 % b) Quantos pacotes são esperados chegar ao destino dentro dos limite atraso. Pacotes que chegam após o limite são considerados perdidos. Novamente, os valores dependem muito do tipo de tráfego transportado. Um valor típico para taxa máxima de perda de pacotes é 0.1%. c) A variância do atraso (jitter) esperada para os pacotes. O jitter é mais importante que o atraso para os equipamentos que tem pouca capacidade de bufferização. Em especial, por razões de compatibilidade entre a rede VoIP e o sistema de telefonia convencional, convenciona-se estabelecer limites de jitter bastante rígidos para a telefonia IP. Por exemplo, o SLA pode especificar que a variância do atraso deve ser inferior a < 5 ms.

7 Este módulo irá se focar apenas nos mecanismos que permitem oferecer garantias de desempenho para redes IP. Os aspectos de disponibilidade são muitas vezes tratados através de enlaces redundantes e recursos disponíveis ao nível da camada de enlace, e esse assunto está fora do escopo desse módulo que é focado em recursos diretamente relacionados ao IP. Alguns protocolos como o MPLS (que tem bastante relação com o IP) possuem mecanismos para aumentar a disponibilidade da rede, como será visto na seqüência do curso. Como dito anteriormente, a principal causa de problemas de desempenho é o congestionamento da rede. Existem vários mecanismos que podem ser empregadas para evitar o congestionamento. Os principais são listadas a seguir: 1) Controle de admissão: mecanismos que controla se o tráfego de um usuário será ou não admitido na rede 2) Policiamento: controla a quantidade de tráfego que um usuário pode injetar na rede 3) Priorização: tratamento diferenciado para certos tipos de tráfego (de acordo com a origem ou o tipo) 4) Condicionamento de tráfego: suavização do tráfego para eliminação ou redução de rajadas 5) Descarte preventivo: descarte preventivo de pacotes visando redução do atraso e jitter da rede

8 Convém lembrar que até o início dos anos 80, o IETF adotava a metodologia do melhor esforço que, por definição, é a ausência de QoS. Isto é, os pacotes são encaminhados por um roteador na mesma ordem em que chegaram em suas interfaces, sem nenhum esquema de priorização. Essa abordagem foi, por muitos anos, apontada como um dos grandes responsáveis pelo sucesso da metodologia IP, pois conferia uma simplicidade enorme aos equipamentos e evitava o desperdício de recursos, como ocorre no método de comutação por circuito. A partir dos anos 90 cresceu o interesse em adotar a tecnologia IP como sendo o principal protocolo para empresas de telecomunicações. Para que o IP pudesse ser usado como meio de transporte para aplicações de tempo real (video e voz) ou de missão crítica (como serviços de conectividade para empresas) era necessário incluir no IP mecanismos que oferecem garantias quanto ao atraso, jitter e a perda de pacotes. A tabela acima mostra como diferentes tipos de aplicação necessitam de garantias distintas a fim de serem transmitidas com a qualidade adequada. Por exemplo, aplicações de VoIP são muito sensíveis a perda de pacotes, atraso e jitter. Isto significa que este tipo de tráfego não pode ser bufferizado (isto é, armazenado em memória para subseqüente transmissão) e precisa ser tratado com grande prioridade na rede, mesmo que necessitando de pequenas quantidades de banda. Por outro lado, o streaming de vídeo apresenta altos requisitos de banda, mas os dados podem ser recebidos com certo atraso e jitter, sem grande perda de qualidade para o usuário. Isso significa que os dados podem ser buferizados pelos roteadores da rede. Esse tipo de tráfego não precisa ser tratado com prioridade excessiva. Dessa forma, a fim de que os recursos de uma rede IP possam ser melhor aproveitados, é necessário introduzir mecanismos de QoS diferenciados para cada tipo de tráfego.

9 Antes de discutirmos mais a fundo quais são os mecanismos para implementar QoS em equipamentos de rede, convém apresentarmos as metodologias desenvolvidas pelo IETF para qualidade de serviço. Para que o QoS possa ser implantado, é necessário que vários elementos da rede cooperem, tendo uma visão comum de como os pacotes devem ser tratados. Essa visão comum é denominada de "metodologia de QoS". A figura ilustra os elementos que participam em uma transmissão fim a fim na rede. Os elementos listados na figura são os seguintes: 1. Mecanismos de QoS: correspondem aos recursos disponíveis nos equipamentos de rede para efetuar um tratamento diferenciado dos pacotes que trafegam pela rede. Os mecanismos mais comuns de QoS são a priorização, o descarte preventivo de pacotes, o policiamento, a marcação e o modelamento de tráfego. 2. Sinalização: corresponde a um protocolo que configura automaticamente os mecanismos de QoS entre dois pontos da rede. A sinalização simplifica a tarefa de administração do QoS pois a configuração pode ser feita e desfeita a partir de ordens enviadas pelos extremos da rede, sem a necessidade de intervenção manual com cada elemento da rede. 3. Ferramenta de Gerenciamento: quando a sinalização não está disponível, é necessário criar políticas de QoS em cada equipamento. Existe um esforço do IETF para padronização de protocolos de gerência e MIBs especiais para essa finalidade. Convém ainda destacar que o QoS pode ser fim a fim ou não. O QoS fim a fim ocorre quanto um caminho com recursos controlados é criado entre os dois hosts da rede. O caminho não é fim a fim se o controle de recursos for feito apenas entre os roteadores. Outra diferenciação é se o QoS é feito por fluxo ou para agregados. O QoS por fluxo cria uma política individualizada para cada conexão (definido pelo par IP:PORTA de origem e destino) entre dois hosts na rede. O QoS agregado trabalha com grandes classes de tráfego, onde os usuários são agrupados e tratados em grandes categorias.

10 Nos anos 90, o IETF elaborou três metodologias de QoS, aproximadamente na seguinte ordem cronológica: 1) Serviços Integrados: define uma estratégia de controle de qualidade por fluxo (isto é, cada aplicação de um usuário da rede). Esse modelo introduziu um protocolo de sinalização para QoS denominado RSVP (Resource Reservation Protocol). O método de serviços Integrados foi considerado complexo demais para ser adotado em grande escala na Internet 2) Serviços Diferenciados (DiffServ): definiu uma abordagem mais simples, mas menos precisa de implementar QoS. Nessa estratégia, existe tratamento diferenciado apenas para algumas grandes classes de tráfego. As classes do DiffServ recebem nomes padronizados como "EF (expedited forwarding)", "AF (assured forwarding)" e "BE (best effort)". Cada uma dessas classes é tratada de forma diferenciada pelos roteadores IP. O tráfego individualizado dos usuários é classificado nessas grandes classes. Essa metodologia não usa protocolo de sinalização. 3) MPLS (MultiProtocol Label Switching): inicialmente, o MPLS foi considerado como uma alternativa para acelerar o processo de roteamento, que era considerado muito complexo nas redes IP. Contudo, nos últimos anos, protocolos de sinalização como o RSVP-TE e o CR-LDP formam introduzidos, tornando o MPLS uma importante ferramenta para engenharia de tráfego. Através do MPLS, é possível definir caminhos com banda reservada ao longo dos roteadores. Isso tornou o MPLS uma das tecnologias mais importantes para criar circuitos virtuais comercializáveis.

11 Uma das metodologias de QoS propostas pelo IETF foi denominada serviços integrados. Nessa abordagem, aplicações podem negociar a reserva de recursos fim a fim na rede para oferecer garantias para fluxos específicos de tráfego. A metodologia de serviços integrados é baseada na introdução de um protocolo de sinalização, denominado RSVP (Resource Reservation Protocol). O RSVP foi padronizado pela RFC 2205, de setembro de Diversas outras RFCs completaram a descrição do seu funcionamento. O termo protocolo de sinalização refere-se ao fato que o RSVP não transporta os dados, mas apenas estabelece e termina caminhos com reservas de recursos ao longo da rede. Para ilustrar como o RSVP funciona, considere o exemplo mostrado na figura. Na abordagem de serviços integrados, o RSVP precisa estar implementado em todos os elementos da rede. Isto inclui as aplicações no cliente e servidor e os roteadores. O objetivo do RSVP é criar um caminho fixo com garantia de recursos ao longo da rede. O caminho do RSVP é sempre unidirecional, garantindo recursos apenas para o tráfego de download, isto é, do servidor para o cliente. O RSVP define um conjunto de mensagens padronizadas. A criação de uma reserva RSVP inicia-se a pedido do cliente, ao estabelecer um pedido de conexão com um servidor. O servidor responde ao cliente com a mensagem padronizada PATH que, além de congelar um caminho entre o servidor e o cliente, também informa ao cliente qual a quantidade de recursos que ele deve solicitar a rede a fim de receber a transmissão com qualidade. O cliente efetua o pedido de reserva de recursos através da mensagem RESV, que segue o mesmo caminho da mensagem PATH. Se todos os roteadores ao longo do caminho forem capazes de satisfazer o pedido de reserva, o servidor confirma o sucesso através da mensagem RESVconf, e a transmissão dos dados pode acontecer utilizando o protocolo nativo da aplicação (TCP ou UDP).

12 Uma regra importante em relação ao QoS em redes IP é: quanto menos comportado o tráfego, mais recursos de rede ele consome. Um tráfego comportado é aquele que mantém uma taxa aproximadamente constante durante todo o período de transmissão. Um tráfego mal comportado, por outro lado, pode intercalar períodos de silêncio com períodos de rajadas. Observe que dois tráfegos com a mesma taxa média podem ter um comportamento bem diferente. Um tráfego de VoIP, por exemplo, mantém uma taxa aproximadamente constante e igual a sua taxa média (o perfil do tráfego é ON-OFF quando se usa supressão de silêncio e constante quando não se usa). Um tráfego de vídeo compactado, por outro lado, pode apresentar longos períodos de baixo tráfego intercalados por rajadas, que correspondem a variações bruscas nas imagens transmitidas. Enquanto a quantidade de recursos necessária para acomodar múltiplos fluxos de VoIP é facilmente previsível, o mesmo não pode ser dito em relação ao tráfego de vídeo. No primeiro caso, a reserva é simplesmente o produto entre a taxa média de transmissão do VoIP e o número de fluxos. No segundo caso, reservar apenas a taxa média pode levar a uma redução da qualidade percebida pelo usuário, se múltiplos fluxos estiverem na taxa de pico ao mesmo tempo..

13 Um modelo muito usado para medir o nível de comportamento do tráfego é o balde de fichas. Esse modelo permite definir o comportamento de uma fonte transmissora (indicada como F na figura) e funciona da seguinte forma: a) Um balde de fichas é alimentado a uma taxa constante r. Suponha que cada ficha dá ao transmissor o direito de transmitir um byte, de maneira que a taxa média do transmissor é limitada a r bytes por segundo. b) Se houver bytes aguardando transmissão quando uma ficha chega no balde, então o byte é imediatamente transmitido. c) Se não houver bytes aguardando transmissão, então a ficha é acumulada no balde. d) As fichas se acumulam no balde até a quantidade máxima de b bytes. Além desse valor, não há mais acúmulo de fichas. e) A fonte pode utilizar as fichas acumuladas no balde para transmitir uma rajada na taxa de p bytes por segundo. A duração máxima da rajada é dada pela relação b/p segundos. Observe que esse modelo define uma fonte com taxa média conhecida r, mas podendo ser mais ou menos comportada, de acordo com o valor de b. Uma fonte com valor b pequeno é bem comportada (ela é um CBR Constant Bit Rate se b for igual a zero) e com "b" grande é muito mal comportada. Se um roteador puder bufferizar indefinidamente as rajadas emitidas pela fonte, ele pode garantir a transmissão de todos os bytes sem perdas reservando apenas um valor de R=r bytes/s no seu enlace de saída. O valor de R=r é um limite instável, pois a fila do roteador pode atingir um tamanho não conhecido. Para garantir uma transmissão com um tamanho limitado de fila o roteador deve reservar um valor de R > r. Quanto maior a relação R/r, menor o tamanho médio da fila, e menor o atraso médio experimentado pelos pacotes.

14 A figura ilustra como ocorre o procedimento de reserva utilizando o RSVP. Primeiramente, o servidor define um caminho fixo para o cliente através da mensagem PATH. Essa mensagem inclui a descrição dos parâmetros do tráfego que será transmitido, utilizando o modelo de balde de fichas (taxa média, taxa de pico e tamanho do balde). O cliente por sua vez efetua o pedido de reserva de recursos para o roteador 1, indicando o quanto de banda necessita (isto é, o valor R, definido quando falamos do modelo de balde de fichas) e uma folga de atraso. A folga de atraso permite que os roteadores ao longo do caminho utilizem uma banda menos prioritária para transportar os pacotes da reserva. Quanto mais folga for cedido ao roteador, mais ele poderá bufferizar os pacotes recebidos aguardando a passagem de momentos de congestionamento para transportar os pacotes. Se a folga for muito pequena, o roteador precisará utilizar recursos privilegiados, que são mais escassos. Como veremos adiante, esses recursos correspondem a filas internas de alta prioridade, que geralmente são reservadas apenas para tráfego de VoIP e VideoConferência. No exemplo, o roteador 1 não tem banda suficiente para tratar a requisição sem atraso. Por isso, ele aloca a reserva em sua faixa menos privilegiada, consumindo 10 ms da folga. Observe que o pedido de reserva é passado para o roteador 2 com a folga reduzida a 20 ms. O processo se repete até que a reserva chegue no servidor. O servidor por sua vez, envia a mensagem de confirmação da reserva para o cliente. Se algum dos roteadores ao longo do caminho não puder atender a reserva, uma mensagem de erro é retornada ao cliente. Por exemplo, se o roteador 1 não puder atender a reserva, ele simplesmente retorna um erro ao cliente sem repassar o pedido ao roteador 2.

15 Computadores e roteadores, para terem suporte ao protocolo RSVP, precisam conter internamente alguns elementos capazes de interpretar as mensagens do protocolo e também alterar a forma como os pacotes são tratados. Os principais elementos envolvidos no processo RSVP estão ilustrados na figura. Observe, primeiramente, que o fluxo de mensagens RSVP e o fluxo de pacotes de dados são independentes. Os elementos de rede, como roteadores, possuem diversos mecanismos para efetuar o tratamento diferenciado de pacotes, conforme será estudado na seqüência deste módulo. Um roteador com suporte RSVP precisa ter pelo menos três mecanismos básicos: 1) Classificador: determina quais pacotes correspondem a reserva RSVP estabelecida 2) Policiador: garantem que o roteador não irá receber mais pacotes do que estabelecido na reserva. 3) Escalonador/Formatador de Tráfego: gerencia de qual fila do roteador cada pacote será retirado. As filas internas permitem criar vários níveis de prioridade para diferentes tipos de tráfego (por exemplo, fila com pouco atraso e fila com muito atraso). A função principal do RSVP é configurar os elementos do roteador para que ele trate os pacotes de forma diferenciada. O "software" de RSVP tem três funções principais: 1) Controle de Admissão: determina se o enlace de saída ainda tem recursos suficientes para atender a demanda vinda da mensagem RESV. 2) Controle de Política: determina se o solicitante tem direitos suficientes para fazer o pedido de reserva. O controle de política utiliza informações de autenticação do usuário disponíveis nas mensagens RSVP. 3) Configuração: uma vez que a reserva seja aceita, cria as regras para: a) Direcionar o tráfego do fluxo para fila de saída adequada, através do Classificador. b) Descartar o excesso de tráfego através do policiador.

16 A metodologia de Intserv, baseada no RSVP, foi considerada pouco escalável para ser utilizada na Internet, pois como a configuração dos mecanismos de QoS é dinâmica, e feita por fluxo, roteadores de backbones poderiam ter que manter o estado de milhares de fluxos simultaneamente. Como alternativa, o IETF propôs uma outra metodologia, visando eliminar, ou pelo menos reduzir significativamente, a necessidade de criar regras de QoS em roteadores de backbone. Essa metodologia foi denominada "Serviços Diferenciados", ou Diffserv (definida na RFC 2475, de 1998). A metodologia de Diffserv denomina "domínio Diffserv" um conjunto de roteadores que disponibilizam serviço de comunicação IP com QoS. Os roteadores de um domínio Diffserv são divididos em dois grandes grupos: roteadores de borda (EDGE) e roteadores de núcleo (CORE). Os roteadores de borda são aqueles que fazem interface direta com a rede do cliente. Geralmente, são os roteadores que fazem a fronteira entre a rede de acesso e o backbone (como o B-RAS utilizado no acesso via ADSL). Os roteador de núcleo interconectam os roteadores de borda. Na topologia física eles corresponderiam aos roteadores do backbone. A idéia básica do Diffserv foi que os roteadores de núcleo tratariam apenas grandes classes de tráfego, deixando a tarefa de discriminar os fluxos individuais apenas para os rotedores de borda. O Diffserv utiliza o conceito de qualidade de serviço para o tráfego agregado ao invés de fluxos individuais como o Intserv. De acordo com essa metodologia, os roteadores de núcleo possuem uma configuração estática, capaz de diferenciar apenas algumas poucas classes de tráfego. Essa configuração estática é denominada de "PHB - Per Hop Behavior". Os PHBs padronizados são definidos nas RFC 2597 e 2598, de A principal função dos roteadores de borda é determinar a qual classe agregada o tráfego do usuário pertence. Para marcar a classe nos pacotes IP, um novo campo denominado "Campo DS" foi criado em substituição ao antigo campo TOS do IP (definido pela RFC 2474, de 1998).

17 A figura ilustra a relação que existe entre os roteadores de borda e os roteadores de núcleo. De acordo com a metodologia Diffserv, os roteadores de borda possuem regras para usuários individuais. Por exemplo, um roteador de borda sabe como identificar um usuário de ADSL específico. Isto é, ele sabe qual o seu plano, a quantidade de banda, e o tipo de tráfego que ele transmite (suporte ou não a VoIP, por exemplo). Conforme dito anteriormente, um roteador de borda corresponde geralmente ao roteador que faz a fronteira entre a rede de acesso e o backbone. Na arquitetura ADSL, ele seria o B-RAS (Broadband Remote Access Server). Essas regras são geralmente dinâmicas. Por exemplo, quando é feita a venda de uma linha para um novo usuário de ADSL, um regra é criada no B-RAS. Quando o contrato é terminado, a regra é removida. Já os roteadores de núcleo possuem regras estáticas, que independem da venda de assinaturas para usuários finais. Nos roteadores de núcleo todos os usuários pertencentes a uma mesma classe são tratados da mesma forma. Um roteador de borda executa duas funções principais: a) Marcação: ele determina a qual classe agregada o tráfego do usuário pertence. Por exemplo, o roteador de borda 1 determinaria que o usuário A pertence a classe ouro, o B a classe prata e o C e D a classe bronze. Já o roteador de borda 2 indicaria que os usuários E e F pertence a classe ouro e os usuários G e H a classe bronze. O roteadores de borda marcam os pacotes do usuário com códigos padronizados utilizando um novo campo no cabeçalho IP, a fim de permitir que os roteadores de núcleo identifiquem a classe dos pacotes sem possuir regras para cada usuário. b) Policiamento: o roteador de borda diminui a prioridade ou descarta o tráfego do usuário que exceda ao seu contrato. O roteador de núcleo, por sua vez, implementa o tratamento diferenciado para cada uma das classes agregadas pré-definidas utilizando os mecanismos clássicos de QoS, como priorização, descarte preventivo, escalonamento com múltiplas filas e controle da taxa de transmissão.

18 Os pacotes IP precisam ser marcados nas fronteiras de entrada de uma rede administrada segundo a metodologia Diffserv. A versão 4 do IP já continha um campo cuja finalidade era definir uma forma diferenciada de tratamento para os pacotes IP. Esse campo era denominado TOS (Type of Service). Através desse campo, era possível definir níveis de prioridade para os pacotes transportados, e o tipo de tratamento desejado. O TOS era utilizado como mais um classificador para que os pacotes seguissem rotas alternativas. Por exemplo, de acordo com a marcação, o rotedor poderia escolher uma rota confiável, mas lenta (para evitar perdas), uma rota rápida (para evitar atraso) ou, simplesmente, uma rota barata (para reduzir custos). Apesar do TOS ser implementado em muitos roteadores, sua adesão foi considerada pouco significativa. Então, o IETF propôs um campo alternativo que ocupa exatamente os mesmos 8 bits do campo TOS. Esse campo foi denominado "Differentiated Services Field" (o campo DS). O campo DS, por sua vez, foi dividido em dois campos menores: o DSCP (Differentiated Services Code Point) e o ECN (Explicit Congestion Notification). O DSCP corresponde, efetivamente, ao campo utilizado para marcação das classes agregadas da metodologia Diffserv. O ECN é uma proposta experimental, que permite aos roteadores indicar que estão congestionados ao nível do protocolo IP, de forma similar ao que já existe nas tecnologias ATM e Frame-Relay. Os roteadores de borda utilizam o campo DSCP para informar aos roteadores de núcleo como o pacote deve ser tratado. Enquanto um roteador de borda precisa ter regras para cada usuário (ou redes), os roteadores de núcleo podem ter regras genéricas, para tratar códigos DSCP específicos. Apesar do DSCP permitir a criação de até 2^6= 64 códigos, o IETF definiu apenas alguns códigos padronizados para a metodologia Diffserv. As regras que os roteadores de núcleo utilizam para tratar esses códigos padronizados são denominadas PHB (Per Hop Behavior). O termo Per Hop é uma referência ao fato que os roteadores do domínio Diffserv adotam um tratamento local para os pacotes recebidos, sem se preocupar com o efeito do QoS fim-a-fim, como na metodologia Intserv.

19 Utilizando os 6 bits do DSCP, é possível definir até 64 valores distintos para tratamento do tráfego agregado. O IETF denomina PHB o tratamento associado ao valor do campo DSCP. Os PHBs são definidos em 3 grupos: B'xxxxx0' PHBs padronizados. Os roteadores devem implementar um comportamento padronizado para todos os pacotes recebidos com esses códigos. B'xxxx11' PHBs de uso experimental ou local. Esses códigos tem significado apenas para um único domínio de serviços diferenciados (isto é, para uma empresa específica). O administrador pode definir um comportamento customizado para esses códigos, mas não deve enviar pacotes com essa marcação para outros domínios. B'xxxx01' PHBs de uso experimental ou local, mas com potencial de serem agregados ao grupo de PHBs padronizados. Esses códigos não são usados pelo IETF, mas podem vir a ser utilizados no futuro. Todos os PHBs padronizados utilizam o valor zero no bit menos significativo do DSCP (bit DS1 na figura), de maneira que apenas 5 bits são utilizados para distinguir os códigos. Esses cinco bits são, por sua vez, definidos da seguinte forma: Seletores de classe: 3 bits mais significativos, Códigos dentro da classe: 2 bits menos significativos.

20 Apesar de ser possível definir até 8 classes com os seletores de classes, o IETF definiu apenas 6 classes padronizadas: DF: Default Forwading (Encaminhamento Default ou Melhor Esforço): Corresponde ao código AF1: Assured Forwarding 1 (Encaminhamento Garantido): Corresponde ao código 010xx0 AF2: Assured Forwarding 2 (Encaminhamento Garantido): Corresponde ao código 011xx0 AF3: Assured Forwarding 3 (Encaminhamento Garantido): Corresponde ao código 100xx0 AF4: Assured Forwarding 4 (Encaminhamento Garantido): Corresponde ao código 101xx0 EF: Expedited Forwarding (Encaminhamento Expresso): Corresponde ao código Internamente no roteador, cada uma dessas classes é tratada como uma fila independente, sendo que a fila EF é a mais prioritária e a fila DF é a menos prioritária. Dessa forma, a qualidade do serviço oferecido varia nessa mesma ordem, isto é, EF é a máxima qualidade e DF é a mínima.

21 A classe EF corresponde a prioridade máxima dentro da rede. Isto significa que um pacote marcado como EF será sempre entregue com o menor atraso possível, passando a frente de todos os outros tipos de pacotes no roteador. Essa classe é indicada para as aplicações de telefonia sobre IP (VoIP). As classes AF, por sua vez, são usadas para transporte de tráfego que deve ter poucas perdas, mas que admite um certo nível de atraso e jitter. A classe AF4 é a mais prioritária entre as AF, sendo utilizada para tráfego sensível ao atraso como a Video Conferência. O streaming admite mais atraso que a vídeo conferência, podendo assim usar a classe AF3. A classe AF2 é designada para tráfego de dados sensível ao atraso, como o SSH, por exemplo, e a AF1 para tráfego de grande volume e pouco sensível ao atraso, como o FTP. Cada uma das classes AF é dividida em subclasses. Por exemplo, a classe AF1 é subdivida em AF11, AF12 e AF13. Essas subdivisões (denominadas cores) são usadas para dar diferentes níveis de descarte para o tráfego atribuído a classe. Elas permitem que o usuário injete tráfego excedente na rede, caso a rede esteja com recursos livres, mas descarta o excesso quando a rede está congestionada. Por exemplo, um usuário transmitindo dados dentro de uma faixa "garantida" seria marcado como AF11. Caso o usuário injete mais tráfego na rede que seu limite garantido, o tráfego excedente é marcado como AF12. Em caso de congestionamento, o tráfego AF12 será descartado antes do AF11. O mesmo raciocínio se aplica a classe AF13. A classe DF corresponde a ausência de tratamento diferenciado. Os pacotes sem marcação (valor 0 no campo DSCP) estão nessa classe, e são tratados como best effort.

22 A figura ilustra os mecanismos que devem estar disponíveis em um nó (tipicamente, um roteador) com suporte a metodologia Diffserv. Observe que o roteador utiliza múltiplas filas para diferenciar o tráfego. Por exemplo, ele pode ter uma fila para o EF, uma fila para o AF (ou quatro filas, se todos os AF forem usados) e uma fila para o DF. A quantidade de filas no roteador pode variar bastante, uma vez que o IETF não obriga que todas as classes padronizadas sejam utilizadas. É muito comum que provedores de acesso a Internet utilizem apenas três filas: EF, AF (sem distinção) e DF. Internamento, o roteador precisa ter os seguintes mecanismos básicos de QoS: Classificador: Determina para qual fila cada pacote recebido deve ser encaminhado. Medidor: Contabiliza as estatísticas associadas aos fluxos de pacotes (taxa média, balde de fichas, etc.) Marcador: Marca o campo DSCP do pacote com os códigos EF, AF11, AF12, AF13, AF21, etc. Formatador de Tráfego: Determina a velocidade com o qual os pacotes serão retirados da fila e enviados para rede Descartador: Determina se alguns pacotes serão descartados de maneira preventiva para evitar o congestionamento da rede A implementação desses elementos no equipamento de rede pode varias bastante. Mas geralmente, existe um conjunto independente desses elementos para cada uma das interfaces do equipamento. Isto é, se um roteador tiver três interfaces, poderemos ter um conjunto independente de filas de saída para cada interface do roteador. Isto significa que o processo de QoS só terá início após o roteador determinar para qual de suas interfaces o pacote será encaminhado, através da consulta a sua tabela de roteamento. Então, considere na figura que o classificador recebe o pacote do módulo de roteamento.

23 A configuração interna de um roteador de borda (edge) e core (núcleo) não é idêntica. Conforme discutimos anteriormente, o objetivo da metodologia Diffserv foi reduzir ao máximo a necessidade de alterar a configuração nos roteadores dos backbones. Tipicamente, um roteador de borda tem todos os mecanismos de QoS descritos anteriormente. Já o roteador de núcleo não tem os elementos de policiamento e marcação. A responsabilidade de policiar e marcar o tráfego é feita exclusivamente pelos roteadores de borda (isto é, apenas o roteador de borda sabe que usuários da rede IP /24 podem transmitir no máximo 1 Mbps em AF11 e até 2 Mbps em AF12). Os roteadores de núcleo, por sua vez, farão todo o possível para transportar o tráfego AF11 sem perda, sacrificando o tráfego AF12 apenas se necessário. O classificador de um roteador de borda pode ser complexo. Ele precisa determinar a qual classe agregada cada pacote pertence utilizando qualquer conjunto de atributos disponíveis no cabeçalho de rede e transporte do pacote. Já o classificador de um roteador de núcleo é bem mais simples, pois ele precisa apenas interpretar o campo DSCP. O IETF define os classificadores em dois grandes grupos: Multicampos (MF): Tipicamente utilizado pelos roteadores de Borda. Utiliza o DSCP e outros campos do cabeçalho IP (IP, Porta, etc.) Comportamento Agregado (BA): Tipicamente utilizado pelos roteadores de Núcleo. Utiliza apenas o campo DSCP

24 Em uma rede Diffserv, o controle do tráfego injetado na rede deve ser feito pelos roteadores de borda. Os roteadores de borda realizam duas tarefas que estão diretamente relacionadas: Policiamento e Marcação. Essas tarefas são realizadas com a ajuda de um terceiro elemento, denominado genericamente de Medidor. O medidor é geralmente implementado utilizando um algoritmo do tipo balde de fichas (token bucket). Para as classes AF, que possuem até três subníveis, utiliza-se geralmente uma seqüência de balde de fichas em cascata. A figura ilustra como o cascateamento de baldes é usado em um cenário em que a classe AF1 é subdividida nas classes AF11 e AF12. O IETF não obriga que todas as subdivisões sejam utilizadas, cabendo ao administrador da rede essa escolha. A política que é implementada pelos baldes é a seguinte: Se o usuário transmitir até 500 kbps, todo o seu tráfego será marcado como AF11 (pouca possibilidade de descarte). O tráfego do usuário que estiver entre 500 kbps e 1 Mbps, será transmitido como AF12 (média possibilidade de descarte). O tráfego do usuário que estiver acima de 1 Mbps será descartado imediatamente, mesmo que não haja congestionamento da rede. Conforme vimos anteriormente, o balde de fichas permite que o usuário envie rajadas de amplitude superior a taxa média, desde que ele compense essas rajadas com períodos de baixa transmissão. A duração das rajadas é definida pelo tamanho do balde. Um balde de 62,5 Kbytes (500 Kbits) permite que o usuário transmita a uma taxa de 1 Mbps por um segundo, sem que nenhum pacote seja marcado como AF12. Somente os pacotes da rajada que excederem a duração de um segundo irão para o segundo balde. Nesse mesmo cenário, para esvaziar o balde e ganhar o direito de transmitir outra rajada, o usuário deve ficar 1 segundo sem transmitir. O mesmo raciocínio se aplica aos pacotes que chegam no segundo balde.

25 O condicionador de tráfego (Traffic Shaping) determina em que velocidade os pacotes que foram alocados nas filas do roteador serão removidos e encaminhados para rede. Existem inúmeras estratégias utilizadas para condicionamento de tráfego. A figura ilustra o efeito de um formatador de tráfego implementado segundo a estratégia do balde de fichas (token bucket). Como vimos, o balde de fichas determina que o tráfego deve respeitar a uma certa taxa média, mas admite que rajadas de duração controlada sejam transmitidas, desde que essas sejam posteriormente compensadas por períodos de baixa transmissão. Suponha que o tráfego que chega na entrada do roteador é mal comportado, contendo rajadas de duração superior ao permitido. Se os pacotes não forem descartados pelo mecanismo de policiamento, eles serão alocados na fila de saída do roteador para posterior transmissão. O tempo que os pacotes irão aguardar na fila dependerá do formatador de tráfego. Se a taxa de retirada e envio dos pacotes for definida pelo balde de fichas, então o perfil do tráfego na saída do roteador será conforme ilustrado no lado direito da figura. Observe que na saída o tráfego respeita perfeitamente ao limites imposto pelo balde. A formatação do tráfego é usualmente empregada para "suavizar" o tráfego, isto é, reduzir as rajadas e aproximar o perfil do tráfego de sua taxa média, tornado-o mais comportado. Esse efeito é muito útil para rede, pois evita o congestionamento instantâneo dos enlaces devido a superposição de rajadas. A formatação, contudo, tem o aspecto negativo de introduz atraso e jitter no tráfego do usuário, pois os pacotes deverão aguardar um tempo variável na fila se chegarem com um perfil diferente daquele imposto na saída.

26 O formatador de tráfego deve determinar duas coisas: a) Se uma dada fila tem pacotes "prontos" para serem transmitidos. b) Se mais de uma fila tiver pacotes "prontos", de qual fila o pacote será removido primeiro. Antes de discutirmos o significado de pacotes "prontos", precisamos considerar que existem basicamente duas estratégias para escolher qual fila será servida primeiro: a estratégia justa e a injusta (a ação de escolher em que ordem as filas são servidas é comumente denominada "escalonamento"). Na estratégia injusta, uma prioridade é atribuída a cada uma das filas. No exemplo da figura, as filas poderiam ser ordenadas da mais prioritária para menos prioritária como AF4, AF3, AF2 e AF1. Nessa estratégia, todos os pacotes das filas estão sempre "prontos", isto é, cada fila pode ser servida individualmente na capacidade máxima do enlace de saída. Dessa forma, a fila AF4 é servida enquanto tiver pacotes. A fila AF3 será servida apenas se não houver pacotes na AF2 e assim por diante. Essa estratégia é chamada de injusta pois pode acontecer que as filas menos prioritárias jamais sejam servidas. Na estratégia justa, um balde de fichas define uma taxa de transmissão para cada fila. Nessa abordagem, os pacotes deverão aguardar a chegada das fichas de maneira a estarem "prontos" para transmitir. No exemplo da figura, AF4 será servido antes das demais filas até uma taxa máxima de 1 Mbps. Se a chegada de pacotes na fila for acima de 1 Mbps, eles terão que aguardar na fila, cedendo sua vez para as filas menos prioritárias. Nessa abordagem, garante-se que todas as filas irão receber um mínimo de banda. A abordagem também garante que a fila AF4 será sempre servida com menos atraso que as demais filas, desde que não seja excedido o seu limite de banda.

27 O descarte preventivo de pacotes é uma estratégia comum para diminuir o atraso total imposto aos pacotes que atravessam um roteador. Para entender como essa estratégia funciona, suponha que exista um roteador com um enlace de saída de 4 Mbps, e uma fila única com capacidade de 4 Mbits. Suponha também que em algum instante, o roteador receba uma rajada de 5 Mbps durante 4 segundos, e que depois disso a taxa de chegada fique fixa em 4 Mbits. O resultado desse cenário é que o excedente de 1 Mbps durante 4 segundos irá encher completamente a fila do roteador. Após isso, todos os pacotes que chegarem ao roteador serão transmitidos com um atraso de 1s, mesmo que a taxa de chegada se mantenha nos 4 Mbps suportados pelo enlace. Para evitar que isso aconteça, o roteador precisa evitar que sua fique cheia por muito tempo. Dependendo da aplicação, o atraso de 1s pode fazer com que os pacotes transmitidos não sejam mais úteis para o destino final (isso seria o caso se o pacote for de VoIP). Dessa forma, é melhor descartar alguns pacotes quando a fila cresce muito, pois isso irá beneficiar todos os pacotes que chegarão depois. Para a classe AF da metodologia Diffserv, o descarte de pacotes é implementado usando as subdivisões de classe (AFX1, AFX2, AFX3). Por exemplo, suponha que uma fila é responsável por servir a classe AF4, que deve garantir níveis baixos de atraso, mas aceita níveis mais elevados de perdas e jitter. Uma política possível para essa fila é a seguinte: Um novo pacote está chegando para a classe AF4: - Se a fila estiver com mais de 90 de ocupação descartar o pacote - Se a fila estiver entre 75 e 90% de ocupação aceitar apenas AF41 - Se a fila estiver entre 50 e 70% de ocupação aceitar AF41 e AF42 - Se a fila estiver entre 0 e 50% de ocupação aceitar AF41, AF42 e AF43

28 O MPLS: Multiprotocol Label Switching foi originalmente proposto pelo IETF em 1997, como uma solução para acelerar o processo de roteamento na Internet. A idéia principal por trás do MPLS era introduzir uma técnica de comutação por rótulos, similar a existente nas tecnologias Frame-Relay e ATM. A técnica de comutação por rótulos (Label Switching) é considerada mais eficiente que a técnica Hop by Hop usada pelo protocolo IP. No protocolo IP, o endereço de destino de um pacote pode estar contido em múltiplas rotas de destino ao mesmo tempo. Por exemplo, o endereço pode estar nas rotas /24, /16, /8 e até mesmo /0. Dessa forma, um roteador precisa localizar a melhor rota para encaminhar um pacote. No MPLS, por outro lado, o próprio quadro traz um código que identifica a rota de destino de maneira única. Além disso, a técnica de comutação por rótulos permite definir múltiplos caminhos para um mesmo destino. Essa característica tornou o MPLS um instrumento primordial para engenharia de tráfego, pois ele permite uma melhor distribuição do tráfego pelas rotas alternativas que uma rede WAN oferece. Antes de discutir esse aspecto do MPLS, convém ilustrar porque o roteamento Hop-by-Hop é considerado inadequado para engenharia de tráfego. Considere o exemplo ilustrado na figura. Suponha que uma operadora de telecomunicações vendeu para um cliente um canal de 100 Mbps para a subrede /25 e 50 Mbps para a subrede /24. No roteamento hop-by-hop os pacotes são sempre roteados pelo caminho de menor custo. Considerando as velocidades dos enlaces, o caminho de menor custo para a rede /25 é e para rede /24 é Suponha agora que a operadora deseja vender mais um canal de 50 Mbps para a rede /25. Considerando a velocidade dos enlaces, o melhor caminho para essa rede também é Como o enlace 2-3 já está exaurido, o novo canal não pode ser vendido. Contudo, observando a rede, ainda seria possível alocar o canal usando o trajeto

29 O MPLS utiliza uma técnica de roteamento denominada "comutação de rótulos" (LABEL switching), que é muito utilizada pelas tecnologias que permitem criar "circuitos virtuais", como o ATM e o Frame Relay. No MPLS, o termo LSP (LABEL Switch Path) é utilizado ao invés de circuito virtual, todavia seu significa é muito similar. Um LSP é um caminho fixo entre dois pontos da rede, definido como uma seqüência de enlaces de roteadores. Cada enlace de roteador usado por um caminho específico é identificado por um LABEL, de forma que um LSP é definido por uma seqüência de LABELs. Um LABEL é um número inteiro (de 12 bits), contido no cabeçalho MPLS. O cabeçalho MPLS é colocado entre os cabeçalhos de enlace (camada 2) e rede (camada 3) de cada pacote. Por essa razão o MPLS é classificado com sendo pertencente a camada 2.5 do modelo OSI. A figura ilustra o conceito de LSP e comutação por LABELs. Primeiramente, considere o caminho do cliente para a rede /5 (indicado em vermelho na figura). Esse LSP é definido como sendo a seqüência de LABELs Do ponto de vista do cliente, contudo, o caminho é identificado apenas como sendo LABEL 10. Para o cliente usar o caminho ele simplesmente configura a regra: "marcar com LABEL 1 todos os pacotes direcionados para a rede /25). Cada roteador possui uma tabela que indica como encaminhar pacotes marcados com LABELs. Essa tabela denomina-se LFIB (LABEL Forwarding Information Base). A LFIB indica duas informações básicas: para onde enviar o pacote e com que valor de LABEL. O LABEL precisa ser trocado pelo roteador a fim de que não seja necessário ter um sistema centralizado para evitar o uso de LABELs repetidos. Usando a estratégia de comutação por LABELs, o valor dos LABELS tem significado apenas local ao enlace, isto é, os valores de LABEL podem ser repetidos em enlaces distintos, mesmo que pertençam ao mesmo caminho. 29

30 A figura ilustra como ficaria o cenário considerando os três caminhos simultaneamente. Um caminho (LSP - LABEL Switched Path) é criado preenchendo-se as tabelas de encaminhamento de LABELs (LFIB) de todos os roteadores da rede. Essa tabela pode ser preenchida manualmente pelo administrador da rede quando o LSP é criado, ou automaticamente, utilizando protocolos de sinalização criados para o MPLS, como o RSVP-TE e o CR-LDP. Caso a tabela seja preenchida manualmente, caberá ao administrador a escolha dos valores dos LABELs. Os valores podem ser usados livremente, desde que não se use LABELS repetidos para caminhos distintos no mesmo enlace. Por exemplo, se o caminho vermelho for o primeiro a ser criado, poder-se-ia usar o mesmo valor de LABEL para todos os enlaces (LABEL=1). Contudo, o LABEL=1 não pode ser mais usado para identificar o caminho verde no enlace de entrada do roteador 1. Dessa forma, foram escolhidos os LABELs 2 e 3 para identificar os caminhos verde e azul. Observe que na saída do roteador 1, o caminho vermelho continua com LABEL=1 e o caminho verde continua com LABEL=2. Contudo, o caminho azul foi comutador para LABEL=1. Apesar do caminho azul e vermelho usarem o mesmo valor de LABEL, não existe conflito, pois se tratam de enlaces distintos. Quando as tabelas são preenchidas através de um protocolo de sinalização, a escolha do LABEL é feita pelo próprio roteador, simplesmente escolhendo um valor de LABEL aleatório que não tenha sido ainda usado em seu enlace. O roteador pode escolher esse LABEL sem necessidade de conhecer os outros LABELs usados na rede, o que justifica a estratégia de LABEL switching. 30

31 Como sabemos, o roteamento puramente IP já estava bastante difundido quando o MPLS foi introduzido. Dessa forma, quando o MPLS é adotado por uma operadora de telecomunicações em seu backbone, é necessário criar mecanismos de conversão entre os pacotes puramente IP vindos dos clientes e os pacotes marcados com MPLS usados no backbone. Isto é, quando um cliente puramente IP injeta um pacote na rede o LABEL (ou rótulo) deve ser inserido, e quando o pacote deixa o domínio da operadora o LABEL deve ser removido para que os roteadores que não suportam MPLS possam interpretar o pacote. Dessa forma, podemos definir que em uma rede MPLS existem dois tipos de roteadores os LER (LABEL Edge Routers) e os LSR (LABEL Switch Routers). Roteadores LER ficam nas bordas de um domínio MPLS. Sua função é inserir ou remover o cabeçalho MPLS que contém os LABELs, fazendo o mapeamento entre o mundo IP e o MPLS. Já os roteadores LSR realizam operações de encaminhamento de pacotes usando unicamente as informações de LABEL. A figura ilustra esse conceito. Observe que os roteadores A e G são roteadores do tipo LER e os roteadores B, C, E e F são do tipo LSR. Um roteador do tipo LER possui uma tabela especial, que associa a cada rota possível de destino um LABEL. Devemos lembrar que os caminhos LSPs são sempre unidirecionais, sendo que os pacotes são sempre transmitidos de um nó de ingresso para um nó de egresso. Para se ter um caminho bidirecional entre os roteadores A e G é necessário criar dois LSPs distintos. Os roteadores LER podem ser de dois tipos: LER de ingresso (que faz a inserção do LABEL) e LER de egresso (que faz a remoção do LABEL). Observe que essa denominação é feita por caminho, isto é, um roteador LER pode se comportar como ingresso para um dado caminho, e como egresso para outro. 31

32 Em uma tabela de roteamento IP, o destino é sempre uma sub-rede (isto é, um endereço de base e uma máscara de sub-rede). No MPLS, os destinos recebem uma denominação mais genérica denominada FEC (Forward Equivalence Class). Uma FEC é definida como um ou mais destinos para os quais os pacotes são encaminhados da mesma forma, isto é, seguindo sempre o mesmo LSP (LABEL Switch Path). O conceito de FEC permite a agregação de vários endereços, mesmo descontínuos, e a diferenciação de caminhos para um mesmo destino, mas para aplicações ou níveis de serviços distintos. A figura ilustra esse conceito. No exemplo, a FEC1 agrupa as sub-redes /24 e /24. Isto significa, que os pacotes enviados para qualquer uma dessas duas sub-redes seguirão sempre o mesmo caminho, pelo menos na parte da rede que está estrutura em MPLS. Após o LER de egresso, os pacotes podem seguir caminhos distintos, pois o roteamento passa a ser puramente IP. As FECs 2 e 3 referem-se a mesma sub-rede /24. Contudo, a FEC2 representa o tráfego do tipo Best Effort e a FEC3 do tipo Expedited Forwarding. Usando duas FECs distintas permite que o tráfego EF siga um caminho com enlaces exclusivos, garantindo que os pacotes com esse tipo de marcação sofram pouco atraso. O roteador LER de ingresso (LER1) possui uma tabela que relaciona cada uma das FEC a um LSP específico. O LER de ingresso é responsável por determinar por qual caminho cada pacote irá percorrer. As regras de mapeamento de LABELs nas FECs podem levar em conta diversos campos do pacote, como IP de origem, IP de destino, Tipo de Protocolo, byte DS (DSCP) ou, até mesmo, as portas do protocolo de transporte. 32

33 A estrutura do cabeçalho MPLS é mostrada na figura. Observe que o cabeçalho MPLS está situado entre os cabeçalhos das camada 2 e 3. Por exemplo, o cabeçalho MPLS pode estar entre o cabeçalho Ethernet e o IP. Por essa razão, muitos autores situam o MPLS como um protocolo da camada 2.5. Um cabeçalho MPLS pode aparecer múltiplas vezes em um mesmo pacote, criando uma pilha de LABELs. Um roteador MPLS analisa sempre o LABEL que está no topo da pilha (isto é, o que está no cabeçalho mais externo), a fim de tomar sua decisão de encaminhamento. Os demais LABELs são considerados apenas quando o cabeçalho do topo é removido. Como veremos, o empilhamento de LABELs é utilizado para criar túneis MPLS, que permite evitar conflitos entre os LABELs adotados por uma operadora de serviços de comunicação e seus clientes privados. Um cabeçalho MPLS possui 32 bits, e contém apenas quatro campos: LABEL (20 bits): contém o valor do LABEL MPLS. Note que é possível definir mais de 1 milhão de valores de LABELs distintos por enlace. Exp (3 bits): bits reservados para uso experimental. Atualmente, sua maior aplicação é o mapeamento de uma marcação similar ao DiffServ ao nível do cabeçalho MPLS. Se mais do que um LSP atravessar o mesmo roteador, os pacotes de cada LSP poderão ser alocados em filas distintas, e com um PHB específico, de acordo com o valor marcado nesses bits. S (1 bit): base da pilha. Conforme ilustrado na figura, uma cabeçalho MPLS pode ser empilhado. O valor 1 indica que o rótulo é a base da pilha, isto é, que ele é o último cabeçalho empilhado; TTL (8 bits): Time to Live = determina a quantidade máxima de saltos que o pacote poderá percorrer. Quando o cabeçalho MPLS é inserido pelo LER, esse campo é copiado do TTL do IP. 33

34 Conforme dito anteriormente, o empilhamento de LABELs é utilizado para criar túneis MPLS, onde os LABELs de uma operadora não entram em conflito com os LABELs utilizados por seus clientes privados. A figura ilustra esse conceito. Considere que uma organização privada deseja interligar dois sites remotos utilizando a tecnologia MPLS. Suponha que esses sites precisam ter dois LSPs distintos (indicados nas cores vermelha e azul na figura). Um desses LSPs poderia estar sendo usado para transportar dados e outro para tráfego VoIP. A figura mostra a seqüência de LABELs para cada um dos LSPs conforme configurado pelos administradores da organização privada. Suponha que a organização não possua o enlace necessário para conectar os roteadores C e F dos dois sites. Ela então precisará contratar um circuito virtual junto a uma operadora. Suponha que a rede da operadora responsável por conectar os dois sites é formada pelos roteadores D e E, mostrados na parte inferior da figura. Como a operadora também utiliza a tecnologia MPLS para criar os circuitos virtuais, é necessário criar algum mecanismo para evitar que os LABELs usados pelas organizações privadas sejam comutados pela rede da operadora. Na situação ideal, os pacotes que chegarem ao roteador F precisam ter exatamente os mesmos valores de LABEL que teriam caso o enlace entre os roteadores C e F fosse físico. Para esconder os LABELs de seus clientes, a operadora utiliza o empilhamento de LABELs. Um novo LABEL de topo é inserido assim que o pacote do cliente entra na rede da operadora. Durante o trajeto dentro da operadora, apenas o LABEL de topo é alterado. Quando o pacote é entregue ao site remoto, o LABEL da operadora é removido, e o roteador F recebe os pacotes em situação idêntica ao de um enlace físico. O trecho da rede onde os pacotes são transportados com empilhamento de LABELs é usualmente denominado túnel. É preciso ter cuidado, contudo, pois alguns autores utilizam a palavra túnel de maneira indiscriminada, como um sinônimo de LSP, mesmo quando o empilhamento não é utilizado. 34

35 O LDP (Label Distribution Protocol) foi o primeiro protocolo de distribuição de LABELs definido pelo IETF (Janeiro de 2001). A estrutura de uma mensagem LDP é definida conforme a figura. Assim como muitos protocolos modernos, o LDP é formado por várias mensagens distintas, todas elas, com um cabeçalho fixo e uma quantidade de campos variável. Os campos do LDP carregam uma série de opções (tipos), definidas através do formato TLV (Tipo -Tamanho - Valor). O LDP define quatro tipos de mensagens: 1. Discovery messages: HELLO (UDP Multicast) Anuncia e mantem a presença de um LSR na rede; 2. Session messages: Inicialização de Sessão (TCP) Estabelece, mantem e termina sessões entre roteadores vizinhos; 3. Advertisement messages: Anúncio de Endereço e Rótulo (TCP) Cria, muda e termina mapeamentos 4. Notification messages: Notificação de Erro (TCP) Consulta e sinaliza erros. O LDP suporta dois métodos de distribuição de rótulos: Downstream por Demanda e Downstream não Solicitado. O método é escolhido durante a fase de Inicialização de Sessão (IS) do LDP. Nessa fase, cada roteador informa ao seu vinzinho qual o método desejado. Em caso de desacordo, a RFC 3036 define que o método será escolhido conforme a tecnologia do enlace que liga os roteadores, da seguinte forma: ATM e Frame-Relay: Por Demanda Outras Tecnologias: Não Solicitado Os dois modos podem ser combinados em diferentes enlaces de uma nuvem MPLS 35

36 A figura ilustra uma seqüência típica de estabelecimento de negociação LDP. A descoberta de nós vizinhos, isto é roteadores LSR com suporte ao MPLS, é feita através de mensagens HELLO. Uma vez que um vizinho tenha sido descoberto, o LSR ativo (aquele com o menor ID recebido na mensagem de HELLO) estabelece uma conexão TCP com seu vizinho passivo. Após essa fase, os roteadores trocam mensagens de inicialização, que definem qual o modo de propagação de LABELs desejado (Não Solicitado ou Sob Demanda), a periodicidade das mensagens Keep Alive e o MTU do enlace. A mensagem de anúncio de endereços permitem que um roteador conheça os endereços de toda as interfaces de seu vizinho. A mensagem de solicitação de LABEL é enviada apenas no modo Sob Demanda. O LDP define as seguintes mensagens de controle de LABEL: Anúncio de LABEL: oferece ao vizinho um caminho associado a um FEC Remoção de LABEL: remove a oferta de LABEL para uma FEC previamente anunciada Liberação de LABEL: informa ao vizinho que um LABEL previamente solicitado para uma FEC não é mais necessário. A mensagem de notificação é utilizada quando ocorrem erros ou eventos adicionais durante a troca de mensagens entre os LSRs. Exemplos de mensagens de notificação são: TVL desconhecida para LSRs que não suportam CR-LDP, recursos insuficientes, etc. 36

37 A figura ilustra o funcionamento de uma distribuição de LABELs no modo Downstream Não Solicitado. O termo "Downstream" indica transmissão no sentido do LER de ingresso e "Upstream" no sentido do LER de egresso. Observe que os dados são sempre transmitidos no sentido Upstream e os LABELs se propagam no sentido Downstream. No modo não solicitado, os roteadores fazem ofertas de caminho para todas as FEC que conhecem para todos os seus vizinhos. Observe que um roteador pode conhecer a rota para uma FEC em duas situações: 1) Porque está conectado diretamente a ela 2) Porque recebeu uma oferta de um roteador vizinho O modo não solicitado não é útil para aplicações de engenharia de tráfego (isto é, quando se deseja distribuir a carga por vários caminhos alternativos na rede). Sua função principal é substituir o método de roteamento baseado puramente no endereço IP de destino pelo roteamento baseado em LABELs, considerado mais eficiente. Com a criação dos protocolos de suporte distribuição de LABELs com restrições, esse método tornou-se pouco utilizado. 37

38 A figura ilustra o funcionamento de uma distribuição de LABELs no modo Downstream Sob Demanda. No modo sob demanda, um roteador LER de ingresso faz a solicitação de um LABEL para uma determinada FEC enviando uma mensagem de solicitação de LABEL para o(s) seu(s) vizinho(s), no sentido Upstream. Quando um LSR recebe a solicitação, se ele conhecer a FEC, ele responde imediatamente. Caso contrário, ele repassa a solicitação a seus vizinho. Quando a solicitação encontra um roteador que conhece a FEC, um anúncio de LABEL é feito no sentido Downstream, apenas para o roteador que fez a solicitação. O anúncio se propaga até atingir o LABEL de ingresso. 38

39 Os métodos de distribuição de LABELS não solicitado e por demanda podem ser combinados em uma mesma rede, pois a escolha do método é feita para roteadores vizinhos. Dessa forma, um roteador pode ter um acordo de distribuição de LABELs pelo método não solicitado com um vizinho, e com outro vizinho um acordo de distribuição de LABELs sob demanda. A figura ilustra esse conceito. Observe que há um acordo de anúncio não solicitado entre os roteadores LSR5 e LSR4, assim como entre os roteadores LSR4 e LSR4. Entre os roteadores LSR3 e LSR2 o acordo é no modo solicitado, assim como entre os roteadores LSR2 e o LER1. Em uma situação inicial, o roteador LSR5 fará o anúncio de sua FEC conhecida para seu vizinho LSR4 que, por sua vez, propagara esse anúncio para o LSR3. Contudo o LSR3 não propagará o anúncio adiante. Quando o LER1 desejar obter um LABEL, ele fará a solicitação ao LSR2, que por não conhecer a FEC solicitada, repassará o pedido para o LSR3. Como o LSR3 já conhece a FEC, ele responde ao LSR2 sem repassar o pedido aos demais roteadores. 39

40 O LDP foi o primeiro protocolo de distribuição de LABELs para o MPLS e não suporta restrições. Quando o MPLS passou a ser visto como uma solução de engenharia de tráfego (TE), e não apenas um método para acelerar o roteamento, novos protocolos com suporte a restrições precisaram ser desenvolvidos. O IETF definiu que a fim de suportar a engenharia de tráfego, esses novos protocolos deveriam ser capazes de: a) Definir um LSP distinto do sugerido pelo OSPF b) Fazer reserva dinâmica de recursos junto com o estabelecimento do LSP c) Distribuir o tráfego por LSPs paralelos d) Criar e Remover dinamicamente LSPs conforme as necessidades da rede e) Tratar falhas pela migração de tráfego entre LSPs altenativos e criação de LSPs backups ou de espera. f) Suportar rotas explícitas g) Fazer controle de admissão para solicitação (a criação do LSP é negada caso não haja recursos suficientes) h) Fazer priorização de LSPs e preempção Um desses protocolos foi denominado foi denominado CR-LDP, definido pela RFC 3212 de janeiro de O CR-LDP é baseado na adição de TLVs nas mensagens LDP existentes. As principais características do CR_LDP são as seguintes: a) Criação de LSPs fim-a-fim sob restrições, utilizando o modo Downstream por demanda. As restrições são impostas pelo LSR de ingresso, e os LABELs são distribuídos a partir do LSR de egresso. b) Prioridades podem ser atribuídas para as LSPs para suportar o esquema de preempção. c) Re-roteamento ou não em caso de falha. d) Suporte a duas classes de restrições: Rotas Explícitas e Parâmetros de Tráfego 40

41 Quando um LER de ingresso faz a solicitação de um LABEL para uma determinada FEC ele pode escolher de forma parcial ou absoluta o caminho até a FEC de destino utilizando as restrições do tipo Rota Explícita. O CR-LDP permite que a rota seja explicitada por endereços IPv4, IPv6, SAs ou identificadores de LSR. Uma rota explícita é definida como uma seqüência de nós abstratos, onde um nó abstrato é formado por um ou mais LSRs. A rota deve passar por pelo menos um LSR do nó abstrato. São definidos dois tipos de nós abstratos: Estrito: Nenhum nó não especificado pode ser inserido entre o nó estrito e o nó anterior. Flexível: A passagem pelo nó é obrigatória, mas ela pode ser feita inserindo-se nós não especificados entre o nó flexível e o nós precedentes da rota. 41

42 O segundo tipo de restrição suportado pelo CR-LDP é baseado em parâmetros de tráfego. Nesse tipo de restrição, quando o LER faz a solicitação de um LABEL para uma data FEC ele inclui dois conjuntos de informações: Trafego Prometido e Serviço Desejado. O tráfego transmitido é uma descrição daquilo que será enviado através do LSP. O Tráfego Prometido é descrito na forma de dois parâmetros: PDR (Peak Data Rate): taxa de pico de transmissão de dados (bytes por segundo) PBS (Peak Burst Size): tamanho da rajada na taxa de pico (em bytes) O Serviço Desejado é definido por três parâmetros: CDR (Commited Data Rate): taxa média solicitada (bytes por segundo) EBS (Commited Burst Size): tamanho da rajada garantida (bytes) EBS (Excess Burst Size): tamanho da rajada permitida em momentos de pouco congestionamento, mas não garantida em outros momentos (bytes). A mensagem de requisição de LABEL inclui ainda as seguintes informações complementares: Freqüência de Amostragem: Quando se solicita uma garantida de taxa média (CDR), é necessário especificar sobre qual período a taxa média será amostrada. Os valores possíveis são: Muito freqüente: CDR garantido para quaisquer 2 pacotes Freqüente: CDR garantido para uma média de poucos pacotes pequenos Não Especificado: Uso de uma intervalo razoável (i.e., 1 segundo) Peso: Indica a capacidade do LSR de utilizar recursos disponíveis de outros LSRs para transporte de tráfego excedente. O LSR com maior peso tem prioridade sobre os LSRs de menor peso: Valor de 1 a 255 Flag de Negociação: A TLV de parâmetros de tráfego define um campo flag (1 byte), para indicar quais itens do pedido podem ser re-negociados, caso não haja recursos na rede para atender ao pedido inicial: bit 0: reservado; bit 1: reservado; bit 2: PDR; bit 3: PBS; bit 4: CDR; bit 5: CBS; bit 6: EBS; bit 7: Peso 42

43 A figura ilustra uma seqüência típica de mensagens trocadas segundo o protocolo CR-LDP. 1) O LSR A (ingresso) envia a mensagem de LABEL Request com a TLV de parâmetros de tráfego, indicando os itens negociáveis. 2) Se houver recursos suficientes, o LSR B efetua a reserva e repassa a mensagem adiante. Se não houver recursos suficientes, mas houverem parâmetros negociáveis, o LSR B faz uma reserva menor e repassa o pedido alterado para frente. 2*) Se o LSR B não tiver recursos e não houver itens renegociáveis, ele notifica a falha para o LSR A 3) O LSR C executa o mesmo procedimento que o LSR B, podendo novamente, encaminhar uma mensagem de LABEL Request modificada, com menos recursos que os recebidos do LSR B. 3*) Caso o LSR C não tenha recursos para efetuar a reserva, ele encaminha uma mensagem de notificação para B, fazendo com que ele libere os recursos previamente alocados. 4) O LSR D (egresso) envia uma mensagem de LABEL Mapping, que ecoa os parâmetros de tráfego (que são os menores ao longo do caminho). 5) O LSR C ao receber a mensagem atualiza sua reserva, e repassa a mensagem ao LSR B alterando apenas o valor do LABEL. 6) O LSR B também atualiza sua reserva e repassa a mensagem de LABEL Mapping ao nó de ingresso. 7) Ao receber a mensagem de LABEL Mapping, o nó de ingresso decide se os parâmetros alocados são suficientes. Se não forem, ele envia uma mensagem de LABEL Release, que irá se propagar até o nó de egresso. 43

44 A fim de suportar o mecanismo de preempção (tomada de recursos de LSR sobre outro já estabelecido), uma prioridade deve ser associada a cada LSR. O mecanismo de preempção adotado pelo CR-LDP define dois parâmetros de prioridade: prioridade de retenção: prioridade em reter recursos prioridade de configuração: prioridade para tomar recursos Dessa forma, caso não exista recursos suficientes para atender ao pedido de criação de um novo LSR, um LSP menos prioritário pode ser terminado, a fim de liberar recursos na rede. Isso é feito se: prioridade de configuração do novo LSR > prioridade de retenção do LSR já estabelecido O exemplo da figura ilustra nesse conceito. Observe que a rede já possui dois LSRs estabelecidos: em vermelho (com Retenção=2) e em azul (com Retenção=3). Suponha que a rede tenha recebido o pedido para criação de um novo LSR em verde a partir do roteador 1. Como não existem recursos disponíveis para atender o pedido, um dos LSRs já estabelecidos precisa ser desfeito. Nesse caso, o LSR vermelho será desfeito pois sua prioridade de retenção é inferior ao do novo caminho. 44

45 O segundo protocolo de distribuição de LABELs com restrições definido para o MPLS é o RSVP-TE, definido pela RFC 3209 de dezembro de O RSVP-TE (Resource Reservation Protocol - Traffic Extension) é baseado no RSVP, definido para a metodologia de QoS denominada serviços integrados. O RSVP permite fazer reservas fim-fim para fluxos de tráfego individuais, mas não possui recursos para distribuição de LABELS. No RSVP-TE as mensagens foram expandidas para suportar distribuição de LABELs e outros recursos previstos para um protocolo de sinalização para o MPLS. As modificações foram: a) Suporte ao gerenciamento de LABELs: Objetos "LABEL Request" na mensagem Path e "LABEL" na mensagem Resv b) Dois novos tipos de classe de serviço: IPv4 LSP Tunnel, IPv6 LSP Tunnel, em adição aos serviços existentes: Carga Controlada (cria caminho sem reserva) e Serviço Garantido (cria caminho com reserva). c) Suporte a Requisição e Registro de Rotas Explícitas: Objetos "Rota Explícita" na mensagem Path e "Registro de Rota" nas mensagens Path e Resv [Opcional] d) Suporte a preempção: Objeto "Atributo de Sessão" inclui as prioridades na mensagem Path e) Manutenção de conectividade entre LSRs: Além dos objetos incluídos nas mensagens já existentes, uma nova mensagem denominada Hello para a ser trocada entre LSRs adjacentes 45

46 O RSVP-TE utiliza duas mensagens Principais: Path: Solicita um LABEL para uma FEC, incluindo restrições como Rota explícita e banda requisitada ao longo do caminho RESV: Enviada do receptor para o transmissor. Anuncia o LABEL caso a reserva possa ser atendida. Além do LABEL, a mensagem RESV contém os seguintes parâmetros: Flow Spec: Especifica a reserva desejada Service Class: Serviço Garantido ou Carga Controlada Tspec: requisitos do transmissor Rspec: taxa de transmissão solicitada Filter Spec: identifica os pacotes que devem de beneficiar da reserva Protocolo de transporte e número de porta. Um reserva em RSVP é caracterizada por uma estrutura de dados denominada Flowspec. Flowspec é composta por dois elementos: Rspec (Reserve Spec): indica a classe de serviço desejada. Tspec (Traffic Spec): indica o que será Transmitido. OBS. Rspec e Tspec são definidas na RFC 2210 e são opacos para o RSVP. Serviço de Carga Controlada (RFC 2211). Rspec não é especificado, apenas Tspec. Não é feita reserva de banda. Os dispositivos evitam a deterioração das condições da rede limitando o tráfego das aplicações. Limite (num intervalo T): < rt +b (bytes) Serviço Garantido (RFC 2212): RSpec e TSpec são especificados. É feita reserva de banda. 46

47 Um exemplo de mensagens PATH e RESV é mostrado a seguir: Resource ReserVation Protocol (RSVP): PATH Message. RSVP Header. PATH Message. SESSION: IPv4-LSP, Destination , Tunnel ID 0, Ext ID a HOP: IPv4, TIME VALUES: ms EXPLICIT ROUTE: IPv , IPv LABEL REQUEST: Basic: L3PID: IP (0x0800) SESSION ATTRIBUTE: SetupPrio 7, HoldPrio 7, SE Style, [C1_t0] SENDER TEMPLATE: IPv4-LSP, Tunnel Source: , LSP ID: 13. SENDER TSPEC: IntServ: Token Bucket, bytes/sec. ADSPEC Resource ReserVation Protocol (RSVP): RESV Message. RSVP Header. RESV Message. SESSION: IPv4-LSP, Destination , Tunnel ID 0, Ext ID a HOP: IPv4, TIME VALUES: ms STYLE: Shared-Explicit (18) FLOWSPEC: Controlled Load: Token Bucket, bytes/sec. FILTERSPEC: IPv4-LSP, Tunnel Source: , LSP ID: 13. LABEL: 0 47