Qualidade de Serviço (QoS) em Redes IP Princípios Básicos, Parâmetros e Mecanismos

Transcrição

1 Qualidade de Serviço (QoS) em Redes IP Princípios Básicos, Parâmetros e Mecanismos Fonte : Prof. Dr Joberto Martins Por: Prof Hugo Santana Universidade Santa Cecília - Unisanta 1

2 1. INTRODUÇÃO 3 2. CENÁRIO E NOVAS APLICAÇÕES EM REDES IP "QUALQUER APLICAÇÃO SOBRE REDE DE PACOTE" "QUALQUER APLICAÇÃO SOBRE REDES IP" DESAFIOS - REDES IP NOVAS APLICAÇÕES 5 3. QUALIDADE DE SERVIÇO (QOS) QUALIDADE DE SERVIÇO (QOS) - PRINCÍPIOS QOS COMO MECANISMO GERENCIAL QOS -PARÂMETROS QUAIS APLICAÇÕES NECESSITAM DE QOS? VAZÃO LATÊNCIA (ATRASO) JITTER PERDAS DISPONIBILIDADE QOS - ALTERNATIVAS TÉCNICAS CENÁRIO - IMPLEMENTAÇÃO DA QOS QOS EM REDES IP - ALTERNATIVAS TÉCNICAS INT SERV - INTEGRATED SERVICES ARCHITECTURE E RSVP - RESOURCE RESERVATION PROTOCOL DIFFSERV - DIFFERENTIATED SERVICES FRAMEWORK MPLS - MULTIPROTOCOL LABEL SWITCHING SBM - SUBNET BANDWIDTH MANAGEMENT DIMENSIONAMENTO QOS - MECANISMOS PROTOCOLOS DE SINALIZAÇÃO PRIORIDADES ESCALONAMENTO CONTROLE DE FILAS CONGESTIONAMENTO 23 2

3 1. Introdução A Qualidade de Serviço (QoS JI ) em redes é um aspecto de implantação e operação importante para as redes de pacote como um todo e para as redes IP em particular. Este documento discute os parâmetros, os protocolos e os mecanismos envolvidos com a garantia de qualidade de serviço com ênfase nas redes de pacotes tipo IP. 2. Cenário e Novas Aplicações em Redes IP As redes TCP/IP [Com95] ou simplesmente, redes IP, têm uma imensa base instalada com milhões de computadores que continua crescendo em praticamente todo o mundo. O forte crescimento e a aceitabilidade das redes IP ocorre em função de dois fatores mais importantes, a saber: O crescimento da rede Internet e A aceitação cada vez maior pelas empresas da base tecnológica TCP/IP como plataforma de suporte às suas aplicações em rede. Isso decorre em parte do sucesso da capilaridade da Internet e do seu potencial (Comércio eletrônico,...). Em princípio, este cenário não tende a mudar no próximos anos e, assim sendo, teremos cada vez mais computadores utilizando o TCP/IP para suas comunicações na Internet e, possivelmente, no âmbito das empresas. Neste contexto o IP é certamente uma alternativa bastante atrativa como plataforma padrão de suporte para as aplicações, pois está naturalmente presente em milhões de máquinas. A questão importante a verificar então vem a ser se realmente esta é a tendência para as redes como um todo (Redes privadas, redes metropolitanas, redes de telecomunicações, redes industriais,..) ou se existem outras tendências a considerar. O fato é que o IP não é a única opção tecnológica para o suporte de aplicações em redes. 2.1 "Qualquer Aplicação sobre Rede de Pacote" Existe um certo consenso de que as tecnologias de comutação (Níveis 2 e 3), algumas vezes denominadas genericamente de "comutação de pacotes" (Packet Switching), devem prevalecer como opção tecnológica para as redes de computadores e como suporte às aplicações como um todo. As opções mais comuns de tecnologias de comutação disponíveis para utilização em redes sem maiores restrições de porte, desempenho ou cobertura geográfica (LAN - Local Area Networks, MAN - Metropolitan Area Networks ou WAN - Wide Area Networks) são as seguintes [Tan96]: ATM - Asynchronous Transfer Mode (Nível 2) Frame Relay (Nível 2) IP (Nível 3) JI - Termos do Jargão Internacional (norte-americano) utilizados no texto visando uma simplificação da nomenclatura utilizada. 3

4 Considerando especificamente estas alternativas, o ATM, o Frame Relay e o IP em particular podem ser utilizados de formas distintas pelas aplicações, a saber: A aplicação utiliza efetivamente a tecnologia de comutação (ATM, Frame Relay,...) e, no caso, pode eventualmente prescindir do recursos ou mesmo da utilização do IP ou A comutação no IP é efetivamente a plataforma para as aplicações e, assim sendo, ele define as vantagens, desvantagens e limitações da rede. A primeira situação corresponde à utilização, por exemplo, da tecnologia ATM como um backbone JI de rede. Neste backbone, as aplicações utilizam as conexões lógicas de alto desempenho do ATM e, eventualmente, podem prescindir ou depender pouco do IP. Exemplos específicos neste contexto são as aplicações de voz sobre ATM (VTOA - Voice Transport over ATM) [Dan98] e o MPOA (MultiProtocol over ATM) [Dav96]. Este cenário é mais comum em redes proprietárias de alto desempenho. Uma idéia semelhante pode ser citada para o Frame Relay quando o mesmo é utilizado em redes corporativas MAN e WAN. Na segunda situação, o IP predomina e é o maior responsável pela comunicação fim-a-fim (usuário-a-usuário). Nada impede entretanto que na implementação da comunicação utilize-se em trechos da rede o protocolo IP (Nível 3) sobre algumas das tecnologias de rede de nível 2 citadas. Segue alguns exemplos de alternativas possíveis: IP over ATM IP over Frame Relay IP over Ethernet IP over Ethernet Switched Outras O importante a considerar nesta discussão é que estas tecnologias são, neste caso, meramente mecanismos de transporte de pacotes entre roteadores e, assim sendo, prevalece na rede as características do IP. Este é um cenário típico das redes de grande público (Internet, intranets,...) e, também, das redes de acesso. Assim sendo, as aplicações tendem a executar sobre redes de pacotes e, dependendo do tipo da rede, as opções são de execução sobre IP (com dependência do mesmo) ou sobre alguma tecnologia de nível 2 de alto desempenho. 2.2 "Qualquer Aplicação sobre Redes IP" A rede TCP/IP foi desenvolvida tendo como uma de suas premissas básicas o requisito de poder ser utilizada com os diversos tipos de meios físicos e tecnologias existentes na época de sua criação ("IP sobre Tudo" - Anos 70) de forma a viabilizar a comunicação entre as aplicações fim-a-fim em rede. Em termos práticos, a rede IP foi desenvolvida de forma a ser capaz de comutar sobre meios físicos e tecnologias de nível 2 confiáveis, não-confiáveis, de alto desempenho, de baixo desempenho, etc. Neste contexto histórico, as decisões arquiteturais tomadas na concepção do protocolo IP foram, na sua maioria, no sentido da simplicidade visando atender o cenário 4

5 imaginado na época para sua implantação em termos de rede. Este paradigma de concepção impõe algumas restrições técnicas ao IP e, por conseqüência, restringe as aplicações suportadas às aplicações com poucos requisitos de operação (P. ex.: aplicações de dados podem perder pacotes, permitem a existência de atrasos,...). O cenário atual das redes IP mudou. Hoje, o cenário de utilização das redes IP exige que "qualquer aplicação" possa rodar com qualidade sobre o IP. Ou seja, a situação do IP atualmente é no sentido do "Tudo sobre IP" mantendo a premissa básica de projeto do "IP sobre Tudo" dos anos 70. De certa forma o paradigma mudou e a questão que segue vem a ser a identificação das eventuais limitações do IP e procedimentos necessários para adequa-lo à nova realidade das redes. Como veremos adiante, a qualidade de serviço em redes IP não é necessariamente resolvida com um único protocolo ou algoritmo. Na maioria dos casos e dependendo da necessidade da(s) aplicação(ões), um conjunto de novos recursos deve ser utilizado. 2.3 Desafios - Redes IP Os desafios na utilização do IP como plataforma de suporte para aplicações em redes são em resumo os seguintes: O IP, como protocolo, não tem praticamente nenhuma garantia de qualidade de serviço e A base instalada do IP é muito grande, o que torna a mudança do protocolo uma idéias pouco factível. O primeiro desafio é de caráter técnico e diz respeito ao paradigma inicialmente previsto para o protocolo que enfatizava a simplicidade de concepção. Por exemplo, o IP não tem nenhuma garantia de vazão constante para uma aplicação em particular. Além disso, uma aplicação não pode obter do IP nenhuma garantia de entrega da próprios pacotes que eventualmente são descartados ou perdidos sem que nenhum tipo de correção ou ação seja tomada. Não existe igualmente nenhuma garantia de tempo de entrega para os pacotes. O segundo desafio é uma questão de como se adequar ao novo paradigma sem efetivamente mudar o protocolo. O IP (Versão 4) deverá em breve mudar para o IP (Versão 6) [Tho96] mas, mesmo neste caso, a escolha foi de manter o paradigma de simplicidade inicial do IPv4 para o IPv6. O IPv6 ou IPng (New Generation) aborda outras questões de implementação do protocolo (Endereçamento, segurança,...) e não apresenta nenhuma solução completa para os desafios citados. A forma de abordar as "deficiências" do IP consiste então em propor novos protocolos, algoritmos e mecanismos que tratem das deficiências tecnológicas intrínsecas ao protocolo e permitam o suporte efetivo de qualquer tipo de aplicação sobre redes IP. 2.4 Novas Aplicações 5

6 Como citado anteriormente, o IP tem uma base instalada muito grande e a tendência é que ele suporte as novas aplicações em rede, a saber: Telefonia e Fax sobre IP (VoIP - Voice over IP) Comércio Eletrônico (E_commerce) Vídeo sobre IP Educação à Distância (EAD) (Distance Learning) Vídeo-Conferência Aplicações Colaborativas e de Grupo Aplicações Multimídia Aplicações Tempo Real Outras Genericamente, a maioria das aplicações citadas são aplicações multimídia na medida em que envolvem a transferência de múltiplos tipos de mídia (Dados, voz, vídeo, gráficos,...) com requisitos de tempo e sincronização para a sua operação com qualidade. 3. Qualidade de Serviço (QoS) A qualidade de serviço (QoS) nas redes IP é um aspecto operacional fundamental para o desempenho fim-a-fim das novas aplicações (VoIP, multimídia,...). Assim sendo, é importante o entendimento dos seus princípios, parâmetros, mecanismos, algoritmos e protocolos desenvolvidos e utilizados para a obtenção de uma QoS. A obtenção de uma QoS adequada é um requisito de operação da rede e suas componentes para viabilizar a operação com qualidade de uma aplicação. Em seguida discute-se com mais detalhe o que vem a se termo "Qualidade de Serviço". 3.1 Qualidade de Serviço (QoS) - Princípios Numa primeira abordagem o termo "Qualidade de Serviço" pode ser entendido da seguinte forma: Qualidade de Serviço (QoS) é um requisito da(s) aplicação(ões) para a qual exige-se que determinados parâmetros (atrasos, vazão, perdas,...) estejam dentro de limites bem definidos (valor mínimo, valor máximo). A QoS é garantida pela rede, suas componentes e equipamentos utilizados. Do ponto de vista dos programas de aplicação, a QoS é tipicamente expressa e solicitada em termos de uma "Solicitação de Serviço" ou "Contrato de Serviço". A solicitação de QoS JI da aplicação é denominada tipicamente de SLA (Service Level Agreement) [Job99] [Jam98]. A SLA JI deve definir claramente quais requisitos devem ser garantidos para que a(s) aplicação(ões) possam executar com qualidade. Um exemplo típico de SLA para uma aplicação de voz sobre IP (VoIP - Voice over IP) com algumas centenas de canais voz simultâneos numa rede IP WAN poderia ser: 6

7 Vazão 2 Mbps; Atraso 250 mseg Disponibilidade 99,5% Uma vez que a rede garanta esta SLA, tem-se como resultado que a aplicação VoIP em questão poderá executar garantindo a qualidade de voz prevista para os seus usuários se comunicando simultaneamente através da rede IP. Do ponto de vista dos usuários, tem-se normalmente que a qualidade obtida de uma aplicação pode ser variável e, a qualquer momento, pode ser alterada ou ajustada (para melhor qualidade ou pior qualidade). Por exemplo, pode-se assistir um vídeo com uma qualidade de 32 fps (Frames per Second) ou 4 fps e, fundamentalmente, isto depende da qualidade de vídeo esperada pelo usuário final. Embora este comportamento possa ser dinâmico dos ponto de vista dos usuários finais (seres humanos), do ponto de vista das redes as SLAs são estáticas e, eventualmente, podem ser alteradas. A alteração numa SLA implica, como veremos adiante, normalmente numa nova solicitação de qualidade de serviço à rede em questão. 3.2 QoS como Mecanismo Gerencial Do ponto de vista de um gerente ou administrador de redes, a percepção da qualidade de serviço é mais orientada no sentido da utilização de mecanismos, algoritmos e protocolos de QoS em benefício de seus clientes e suporte às aplicações. Ou seja, como efetivamente a rede e suas componentes podem garantir as inúmeras SLAs definidas para diversos usuários e aplicações. Outras aspectos importantes do ponto de vista gerencial são a escalabilidade e flexibilidade da solução implantada. A escalabilidade dos protocolos, algoritmos e mecanismos de QoS é um assunto de pesquisa (P&D) e se torna particularmente relevante quando consideramos a possibilidade de estender a garantia de QoS através de múltiplos domínios administrativos IP. A flexibilidade dos mecanismos de controle de QoS é um fator determinante na aceitabilidade do mesmos pela comunidade. 3.3 QoS -Parâmetros Como definido anteriormente, a QoS necessária às aplicações é definida em termos de uma SLA. Na especificação das SLAs são definidos os parâmetros de qualidade de serviço e alguns dos mais comumente utilizados são: 7 Vazão (Banda) Atraso (Latência) Jitter JI Taxa de Perdas, Taxa de Erros,... Disponibilidade

8 Outros Em seguida, discute-se quais aplicações realmente necessitam da garantia de QoS e, em seguida, discute-se os parâmetros básicos de especificação da qualidade de serviço indicados acima Quais Aplicações Necessitam de QoS? Inicialmente, é necessário considerar que não são todas as aplicações que realmente necessitam de garantias fortes e rígidas de qualidade de serviço (QoS) para que seu desempenho seja satisfatório. Dentre as novas aplicações identificadas anteriormente, as aplicações multimídia são, normalmente, aquelas que têm uma maior exigência de QoS. No mínimo, as aplicações sempre precisam de vazão (banda) e, assim sendo, este é o parâmetro mais básico e certamente mais presente nas especificações de QoS. Este parâmetro da qualidade de serviço é normalmente considerado durante a fase de projeto e implantação da rede e corresponde a um domínio de conhecimento bem discutido e relatado na literatura técnica. As considerações que seguem tentam identificar as exigências em termos de QoS das aplicações multimídia ilustrando algumas situações práticas. Uma aplicação multimídia offline JI envolvendo, por exemplo, dados, gráficos e arquivos com animação (vídeo,...) não necessita de sincronização e, assim sendo, não necessita de "cuidados especiais" (QoS) da rede. Observe que tem-se dados correspondentes a uma animação que, em termos práticos, necessita de uma determinada vazão, eventualmente carrega a rede, mas não exige atrasos, sincronização ou tempo de resposta. Este é um caso típico onde a necessidade de QoS reduz-se a uma necessidade de vazão, normalmente atendida pelo próprio projeto da rede. Por outro lado, para uma aplicação multimídia de conferência de áudio, garantir apenas a vazão não é suficiente. Neste caso específico, os atrasos de comunicação e as perdas de pacotes influenciam na interatividade dos usuários e na qualidade da aplicação. Considerando números, se esta aplicação gera uma vazão (fluxo de dados) de 64 Kbps, mesmo a utilização de uma LP (Linha Privada) em rede WAN de 256 Kbps pode não ser suficiente. Neste caso, os atrasos e perdas decorrentes da operação podem prejudicar a qualidade da aplicação. Diz-se então que a aplicação exige uma qualidade de serviço da rede Vazão A vazão (banda) é o parâmetro mais básico de QoS e é necessário para a operação adequada de qualquer aplicação. Em termos práticos as aplicações geram vazões que devem ser atendidas pela rede. A tabela 1 em seguida ilustra a vazão típica de algumas aplicações: Aplicação Vazão (Típica) 8

9 Aplicações Transacionais Quadro Branco (Whiteboard) Voz Aplicações Web (WWW) Transferência de Arquivos (Grandes) Vídeo (Streaming JI ) Aplicação Conferência Vídeo MPEG Aplicação Imagens Médicas Aplicação Realidade Virtual 1 Kbps a 50 Kbps 10 Kbps a 100 Kbps 10 Kbps a 120 Kbps 10 Kbps a 500 Kbps 10 Kbps a 1 Mbps 100 Kbps a 1 Mbps 500 Kbps a 1 Mbps 1 Mbps a 10 Mbps 10 Mbps a 100 Mbps 80 Mbps a 150 Mbps Tabela 1 - Vazão Típica de Aplicações em Rede Como discutido, o atendimento do requisito vazão para a qualidade de serviço é um dos aspectos levados em conta no projeto da rede Latência (Atraso) A latência e o atraso são parâmetros importantes para a qualidade de serviço das aplicações. Ambos os termos podem ser utilizados na especificação de QoS, embora o termo "latência" seja convencionalmente mais utilizado para equipamentos e o termo "atraso" seja mais utilizado com as transmissões de dados (P. ex.: atrasos de transmissão, atrasos de propagação,...). De maneira geral, a latência da rede pode ser entendida como o somatório dos atrasos impostos pela rede e equipamentos utilizados na comunicação. Do ponto de vista da aplicação, a latência (atrasos) resulta em um tempo de resposta (tempo de entrega da informação - pacotes,...) para a aplicação. Os principais fatores que influenciam na latência de uma rede são os seguintes: Atraso de propagação (Propagation Delay); Velocidade de transmissão e Processamento nos equipamentos. O atraso de propagação corresponde ao tempo necessário para a propagação do sinal elétrico ou propagação do sinal óptico no meio sendo utilizado (fibras ópticas, satélite, coaxial,...) e é um parâmetro imutável onde o gerente de rede não tem nenhuma influência. A tabela 2 em seguida ilustra a título de exemplo alguns valores para o atraso de propagação entre cidades numa rede WAN utilizando fibras ópticas como meio físico de comunicação. Trecho (Round Trip Delay) Miami a São Paulo New York a Los Angeles Los Angeles a Hong Kong Atraso de Propagação 100 mseg 50 mseg 170 mseg 9

10 Tabela 2 - Atrasos de Propagação - Fibras Ópticas - Exemplos A velocidade de transmissão é um parâmetro controlado pelo gerente visando normalmente a adequação da rede à qualidade de serviço solicitada. Em se tratando de redes locais (LANs) [Tan96], as velocidades de transmissão são normalmente bastante elevadas, tendendo a ser tipicamente superior à 10 Mbps dedicada por usuário (p. ex.: utilizando LAN Switches [Mat97]). Além disso, considere-se também que: Num cenário de redes locais (LANs - redes proprietárias confinadas) tem-se apenas custos de investimento e Nas LANs não tem-se, pelo menos em termos de equipamentos, custos operacionais mensais. Em se tratando de redes de longa distância (Redes corporativas estaduais e nacionais, redes metropolitanas, intranets metropolitanas,...) as velocidades de transmissão são dependentes da escolha de tecnologia de rede WAN (Linhas privadas, frame relay, satélite, ATM,...). Embora exista obviamente a possibilidade de escolha da velocidade adequada para garantia da qualidade de serviço, observa-se neste caso restrições e/ ou limitações nas velocidades utilizadas, tipicamente devido aos custos mensais envolvidos na operação da rede. Além desse fator, observa-se também algumas restrições quanto à disponibilidade tanto da tecnologia quanto da velocidade de transmissão desejada. Em termos práticos, trabalha-se em WAN tipicamente com vazões da ordem de alguns megabits por segundo (Mbps) para grupos de usuários. O resultado das considerações discutidas é que a garantia de QoS é certamente mais crítica em redes MAN e WAN pelo somatório de dois fatores, ambos negativos: Trabalha-se com velocidades (Vazão) mais baixas e A latência (Atrasos) é muito maior quando compara-se com o cenário das redes locais. O terceiro fator que contribui para a latência da rede é a contribuição de atraso referente ao processamento realizado nos equipamentos. A título de exemplo, numa rede IP os pacotes são processados ao longo do percurso entre origem e destino por: Roteadores (comutação de pacotes) LAN Switches (comutação de quadros) Servidores de Acesso Remoto (RAS) (comutação de pacotes,...) Firewalls JI (processamento no nível de pacotes ou no nível de aplicação,...) Outros Considerando que a latência é um parâmetro fim-a-fim, os equipamentos finais (hosts JI ) também têm sua parcela de contribuição para o atraso. No caso dos hosts, o atraso depende de uma série de fatores, a saber: Capacidade de processamento do processador; Disponibilidade de memória; Mecanismos de cache; 10

11 Processamento nas camadas de nível superior da rede (Programa de aplicação, camadas acima da camada IP,...); Etc... Em resumo, observe-se que os hosts são também um fator importante para a qualidade de serviço e, em determinados casos, podem ser um ponto crítico na garantia de QoS. Esta consideração é particularmente válida para equipamentos servidores (Servers) que têm a tarefa de atender solicitações simultâneas de clientes em rede Jitter O jitter é um outro parâmetro importante para a qualidade de serviço. No caso, o jitter é importante para as aplicações executando em rede cuja operação adequada depende de alguma forma da garantia de que as informações (pacotes) devem ser processadas em períodos de tempo bem definidos. Este é o caso, por exemplo, de aplicações de voz e fax sobre IP (VoIP), aplicações de tempo real, etc... Do ponto de vista de uma rede de computador, o jitter pode ser entendido como a variação no tempo e na seqüência de entrega das informações (p. ex.: pacotes) (Packet-Delay Variation) devido à variação na latência (atrasos) da rede. Conforme discutido no item anterior, a rede e seus equipamentos impõem um atraso à informação (p. ex.: pacotes) e este atraso é variável devido a uma série de fatores, a saber: Tempos de processamento diferentes nos equipamentos intermediários (roteadores, switches,...); Tempos de retenção diferentes impostos pelas redes públicas (Frame relay, ATM, X.25, IP,...) e Outros fatores ligados à operação da rede. A figura 3.1 ilustra o efeito do jitter entre a entrega de pacotes na origem e o seu processamento no destino. Observe que o jitter causa não somente uma entrega com periodicidade variável (Packet-Delay Variation) como também a entrega de pacotes fora de ordem. Tempo Pacotes no emissor T1 T2 Pacotes fora de ordem Figura Efeito do Jitter para as Aplicações Pacotes no receptor Em princípio, o problema dos pacotes fora de ordem poderia ser resolvido com o auxílio de um protocolo de transporte como o TCP (Transmission Control Protocol) [Ste94] que verifica o 11

12 sequenciamento da mensagens e faz as devidas correções. Entretanto, na prática tem-se que a grande maioria das aplicações multimídia optam por utilizar o UDP (User Datagram Protocol) [Ste94] ao invés do TCP pela maior simplicidade e menor overhead deste protocolo. Nestes casos, o problema de sequenciamento deve ser resolvido por protocolos de mais alto nível normalmente incorporados à aplicação como, por exemplo, o RTP (Real Time Transfer Protocol) [Mau98]. O jitter introduz distorção no processamento da informação na recepção e deve ter mecanismos específicos de compensação e controle que dependem da aplicação em questão. Genericamente, uma das soluções mais comuns para o problema consiste na utilização de buffers JI ( Técnica de "buffering") Perdas As perdas de pacotes em redes IP ocorrem principalmente em função de fatores tais como: Descarte de pacotes nos roteadores e switch routers JI (Erros, congestionamento,...) e Perda de pacotes devido à erros ocorridos na camada 2 (PPP - Point-to-Point Protocol, ethernet, frame relay, ATM,...) durante o transporte dos mesmos. De maneira geral, as perdas de pacotes em redes IP são um problema sério para determinadas aplicações como, por exemplo, a voz sobre IP. Neste caso específico, a perda de pacotes com trechos de voz digitalizada implica numa perda de qualidade eventualmente não aceitável para a aplicação. O que fazer em caso de perdas de pacotes é uma questão específica de cada aplicação em particular. Do ponto de vista da qualidade de serviço da rede (QoS) a preocupação é normalmente no sentido de especificar e garantir limites razoáveis (Taxas de Perdas) que permitam uma operação adequada da aplicação Disponibilidade A disponibilidade é um aspecto da qualidade de serviço abordada normalmente na fase de projeto da rede. Em termos práticos, a disponibilidade é uma medida da garantia de execução da aplicação ao longo do tempo e depende de fatores tais como: Disponibilidade dos equipamentos utilizados na rede proprietária (Rede do cliente) (LAN, MAN ou WAN) e Disponibilidade da rede pública, quando a mesma é utilizada (Operadoras de telecomunicações, carriers JI, ISPs - Internet Service Providers,...). As empresas dependem cada vez mais das redes de computadores para a viabilização de seus negócios (Comércio eletrônico, home-banking JI, atendimento online JI, transações online,...) e, neste sentido, a disponibilidade é um requisito bastante rígido. A título de exemplo, 12

13 requisitos de disponibilidade acima de 99% do tempo são comuns para a QoS de aplicações WEB, aplicações cliente/ servidor e aplicações de forte interação com o público, dentre outras. 4. QoS - Alternativas Técnicas Uma vez identificado os parâmetros relacionados com a qualidade de serviço das aplicações, discute-se os protocolos, mecanismos e algoritmos utilizados na implementação efetiva da qualidade de serviço. 4.1 Cenário - Implementação da QoS Numa rede IP a qualidade de serviço consiste num mecanismo fim-a-fim (host de origem a host de destino) de garantia de entrega informações (Pacotes,...). Assim sendo, a implementação da garantia de QoS pela rede implica em atuar nos equipamentos envolvidos na comunicação fim-a-fim visando o controle dos parâmetros de QoS. Os parâmetros (atrasos, jitter,...) que devem ser controlados visando a obtenção da qualidade de serviço não são, infelizmente, localizados num único equipamento ou componente da rede. A figura 4.1 em seguida ilustra um exemplo de situação onde na trajetória fim-a-fim dos pacotes tem-se equipamentos tipo LAN Switch, roteadores, Firewalls, utiliza-se uma rede pública de comutação de pacotes e, obviamente, tem-se os próprios hosts dos usuários finais. Os mecanismos de QoS devem portanto atuar nestes equipamentos, camadas de protocolo e entidades de forma cooperada. Uma das atribuições dos gerentes de Tecnologia da Informação (TI) é justamente a escolha e implementação adequada dos mecanismos de QoS discutidos adiante num cenário como o da figura 4.1. LAN Switch Roteador Pacote IP Rede Pública: - ATM, FR,... Firewall Hosts Mecanismos de QoS Atuação - Gerente TI Protocolos, Algoritmos, Técnicas,... Figura Equipamentos e Componentes de Rede Envolvidos na Qualidade de Serviço (QoS) 13

14 Uma outra questão importante a perceber-se na implementação dos mecanismos de controle da qualidade de serviço é a percepção do momento onde estes mecanismos são necessários. Efetivamente, a necessidade de garantir a qualidade de serviço se coloca mais fortemente nos períodos de pico de tráfego quando a rede enfrenta uma situação de congestionamento ou de carga muito elevada. Neste tipo de situação os mecanismos de QoS buscam soluções para decisões do tipo: Como alocar os escassos recursos (p. ex.: banda) Como selecionar o tráfego de pacotes Como priorizar os pacotes Como descartar pacotes (quais e quando) 4.2 QoS em Redes IP - Alternativas Técnicas As alternativas técnicas básicas para a qualidade de serviço em redes IP são as seguintes: IntServ - Integrated Services Architecture com o RSVP (Resource Reservation Protocol); DiffServ - Differentiated Services Framework; MPLS (MultiProtocol Label Switching); SBM (Subnet Bandwidth Management); Dimensionamento e Soluções Proprietárias. Todas as alternativas citadas, excetuando-se as soluções proprietárias, são iniciativas do IETF (Internet Engineering Task Force) [IETF]. O IETF está fortemente empenhado em propor um conjunto de soluções para os mecanismos de controle de QoS que garanta a interoperabilidade dos mesmos entre diferentes fornecedores. Isto se dá em função da importância das redes IP para o suporte de novas aplicações multimídia, tempo real, etc. Em seguida, resume-se os princípios, os mecanismos específicos e a estratégia destas alternativas técnicas Int Serv - Integrated Services Architecture e RSVP - Resource Reservation Protocol A alternativa técnica IntServ [IntServCharter] está atualmente sendo definida pelo IETF e corresponde a um conjunto de recomendações (RFCs - Request for Comments) visando a implantação de uma infra-estrutura robusta para a Internet que possa suportar o transporte de áudio, vídeo e dados em tempo real além do tráfego de dados transportado na infra-estrutura atual. O conjunto de recomendações proposto é denominado de "Arquitetura de Serviços Integrados" (Integrated Services Architecture) [Brad94] e visa uma garantia de qualidade de serviço (QoS) para as aplicações. A arquitetura IntServ tem um princípio básico de concepção (Princípio arquitetural): 14

15 A qualidade de serviço (QoS) na arquitetura IntServ é garantida através de mecanismos de reserva de recursos na rede. Na arquitetura IntServ a aplicação reserva os recursos que vai utilizar antes de iniciar o envio de dados (áudio, vídeo,...) pela rede. Na definição da arquitetura IntServ dois aspectos operacionais precisam ser definidos: 1. Como as aplicações solicitam sua necessidade de QoS à rede, ou seja, como elas fazem suas reservas e 2. Como os elementos da rede (Roteadores,...) devem proceder para garantir a qualidade de serviço solicitada (Garantir a reserva). As aplicações solicitam suas necessidades de QoS à rede através do protocolo de sinalização RSVP (Resource Reservation Protocol) [Rsvp_2205] onde: A aplicação cliente identifica sua necessidade de QoS; A aplicação cliente solicita à rede a garantia da qualidade de serviço que lhe é conveniente (Reserva) através do protocolo RSVP; A rede (Equipamentos roteadores e switch routers) aceita eventualmente a solicitação e "tenta garantir" a reserva solicitada e Uma vez aceita a reserva, os fluxos de dados (streams) correspondentes à aplicação são identificados e roteados segundo a reserva feita para os mesmos. O RSVP é um protocolo de sinalização que atua sobre o tráfego de pacotes (p. ex.: pacotes IP) numa rede (Internet, redes privadas,...). O RSVP é um protocolo eficiente do ponto de vista da qualidade de serviço (QoS) na medida em que provê granularidade e controle fino das solicitações feitas pelas aplicações. Sua maior desvantagem é a complexidade inerente à sua operação nos roteadores que, eventualmente, pode causar dificuldades nos backbones JI de grandes redes. O RSVP é um protocolo bem aceito pelo mercado e é disponibilizado na grande maioria dos ambientes operacionais (Unix, NT, Windows 98,...) e equipamentos de rede de diversos fornecedores. A maneira como os elementos de rede devem proceder para a garantia da qualidade de serviço solicitada é detalhada em várias recomendações (RFCs) relacionadas à arquitetura IntServ. Segue comentários sobre algumas recomendações mais importantes: RFC Specification of the Controlled-Load Network Element Service: Define como um elemento de rede (Roteador,...) garante uma solicitação de reserva para um serviço de "carga controlada" solicitado por uma aplicação. RFC Specification of Guaranteed Quality of Service: Define como um elemento de rede (Roteador,...) garante uma solicitação de reserva para um serviço tipo "garantido" solicitado por uma aplicação. 15 RFC General Characterization Parameters for Integrated Services Network Elements: Define o conjunto de parâmetros gerais de caracterização e controle dos fluxos com QoS para os elementos da rede (Roteadores,...).

16 RFC Integrated Services Management Information Base using SMIv2: Define aspectos técnicos relativos à base de dados de gerenciamento dos serviços na arquitetura IntServ. Para uma relação completa de recomendações relacionadas com a arquitetura IntServ consultar [JSMNet] e [IntServ_Charter] DiffServ - Differentiated Services Framework A alternativa técnica DiffServ [DiffServer_Charter] é uma outra iniciativa do IETF com o objetivo de permitir também o transporte de áudio, vídeo, dados em tempo real e dados "convencionais" na Internet. A alternativa DiffServ tem um princípio básico de concepção (Princípio arquitetural): A qualidade de serviço na solução DiffServ é garantida através de mecanismos de priorização de pacotes na rede. A solução DiffServ não utiliza nenhum tipo de mecanismo de reserva de recursos. Nesta solução os pacotes são classificados, marcados e processados segundo o seu rótulo (DSCP - Differentiated Service Code Point) [Dscp_2474]. A idéia básica da solução DiffServ é reduzir o nível de processamento necessário nos roteadores para fluxos de dados (streams). Isto é realizado com a definição de poucas "Classes de Serviço" numa estrutura comum de rede. Os inúmeros fluxos de tráfego (Pacotes IP) gerados pelas aplicações são agregados a poucas classes de serviço em função da qualidade de serviço (QoS) especificada para o fluxo. Esta tarefa é tipicamente realizada nos roteadores de entrada do backbone (Edge routers JI ) e, desta forma, o processamento nos roteadores intermediários (Core JI ) fica mais simplificado e independente dos fluxos individuais das aplicações. Os roteadores de backbone/ core processam os pacotes (Forwarding) segundo basicamente as "classes de serviço". Em outras palavras, os roteadores de backbone roteiam "agregados de fluxos". A figura 4.2 adiante ilustra os blocos funcionais principais num equipamento (Roteador,...) utilizando a solução DiffServ. Todas as funções estão normalmente presentes nos roteadores de entrada e saída da rede (Edge routers) e, eventualmente, são acionadas nos roteadores intermediários (Core routers/ Backbone routers). Classificador de Pacotes (Classifier) Condicionador de Pacotes (Traffic Conditioner) Marcador de Pacotes (Marker) Monitor de Pacotes (Traffic Meter) 16 Classifica Pacotes Processa os Pacotes Marca Pacotes Monitora fluxos de Pacotes

17 Fig Blocos Funcionais do DiffServ A figura 4.3 ilustra a marcação dos DSCP para o protocolo IPv4. No IPv4 utiliza-se o campo TOS (Type of Service) do IP. No IPv6 utiliza-se o campo "Traffic Class". Em resumo, a operação de DiffServ é como segue: Cada pacote recebe um processamento baseado na sua marcação (DSCP). O DiffServ define duas classes de serviço que podem também ser entendidas como "comportamentos" (PHB - Per-Hop Behavior), na medida em que definem como os equipamentos (Roteadores,...) se comportam com relação aos pacotes (Como os pacotes são processados): Expedited Forwarding (EF): Esta classe de serviço provê o maior nível de qualidade de serviço. A idéia é emular uma linha dedicada convencional minimizando os atrasos, probabilidade de perda e jitter para os pacotes. EF utiliza mecanismos de traffic shaping JI, buferização (buffering) e priorização de filas discutidos adiante. Assured Forwarding (AF): Esta classe de serviço emula um comportamento semelhante a uma rede com pouca carga mesmo durante a ocorrência de congestionamento. A latência negociada é garantida com um alto grau de probabilidade. O serviço AF define 4 níveis de prioridade de tráfego (Ouro, Prata, Bronze e Best Effort JI ) (Os níveis de prioridade foram inspirados na premiação dos jogos olímpicos). Para cada nível de prioridade são definidos 3 preferências de descarte de pacotes (semelhante ao Frame Relay). Este serviço usa mecanismos de Traffic Shaping (Token Bucket) e usa o algoritmo RED (Randon Early Detection), discutido adiante, durante o congestionamento. Outros serviços poderão ser definidos no escopo das recomendações DiffServ ` DSCP Class Selector NU Differentiated Service Code Point NU - Não utilizado RFC ` Precedence Type of Service Z Campo TOS no IPv4 (RFC 791) Z - Zero RFC 1122 RFC

18 Fig DSCP - Differentiated Service Code Point As alternativas IntServ e DiffServ não são concorrentes ou mutualmente exclusivas. Na realidade, estas são soluções complementares que podem ser utilizadas conjuntamente. Uma alternativa de uso conjunto das duas soluções seria a utilização do DiffServ no backbone de roteadores (core), na medida em que é uma solução mais "leve" e o IntServ/ RSVP nas redes de acesso, na medida em que provê um bom controle com granularidade dos requisitos de QoS das aplicações. A solução DiffServ ainda está em fase de desenvolvimento e, no momento, é menos presente que a solução IntServ/ RSVP nos ambientes operacionais e equipamentos de rede. Para uma relação completa de recomendações relacionadas com a arquitetura DiffServ consultar [JSMNet] e [DiffServ_Charter] MPLS - MultiProtocol Label Switching A solução MPLS [Mpls_Charter] tem uma certa relação com a questão da qualidade de serviço em redes e, neste sentido, é importante discutir os seus princípios. Do ponto de vista técnico a solução MPLS tem algumas similaridades com a solução DiffServ, a saber: 18 Os pacotes são marcados com um rótulo (MPLS Label) de 20 bits; Os pacotes são marcados pelo MPLS na entrada da rede (MPLS edge routers) e Os rótulos são retirados dos pacotes na saída da rede (MPLS edge routers). No que toca a operação, o MPLS utiliza os seus rótulos basicamente para indicar o próximo roteador (Next hop) para onde o pacote deve ser encaminhado (Forwarding). Este aspecto operacional diferencia-o substancialmente das soluções anteriores na medida em que: O MPLS é uma solução mais orientada para uma engenharia de tráfego de pacotes na rede que para uma garantia efetiva de qualidade de serviço (QoS); Um dos ganhos mais importantes com a utilização do MPLS é a simplificação da função de roteamento nos roteadores, reduzindo assim o overhead JI nos mesmos e as suas latências. Obviamente, com a redução da latência nos roteadores, melhora-se as condições de operação na rede e isso leva a uma melhor qualidade de serviço. Entretanto, o MPLS não provê controles específicos quanto à garantia de QoS na rede. Outros aspectos que diferenciam o MPLS das soluções InteServ e DiffServ são os seguintes: O MPLS não é controlável pela aplicação. Não existe API (Application Programmming Interface) para o MPLS nos hosts; O MPLS é residente apenas nos roteadores; O MPLS é independente do protocolo de rede (IP, IPX,...), o que representa uma vantagem importante desta solução.

19 Para a operação efetiva do MPLS faz-se necessário a distribuição dos rótulos (MPLS Labels) entre os roteadores e a gerência dos mesmos. O protocolo LDP (Label Distribution Protocol) [LDP_Spec] é um protocolo de sinalização desenvolvido com esta finalidade SBM - Subnet Bandwidth Management A garantia de qualidade de serviço (QoS) é fim-a-fim, ou seja, envolve os equipamentos de rede (Roteadores,...), os hosts de origem e destino e os equipamentos e tecnologias utilizados nas suas interconexões (Redes locais, LAN Switches, redes públicas,...). Desta forma a garantia de qualidade de serviço, como numa corrente, tem como seu ponto mais fraco o elo mais frágil da cadeia de comunicação fim-a-fim e, neste sentido, todos os elos são importantes. As soluções discutidas anteriormente abordam a garantia de QoS usando mecanismos de reserva de recursos e priorização exclusivamente para o tráfego de pacotes no nível 3 (Nível de rede) que, certamente, é o elo mais crítico da cadeia. No que toca a garantia da qualidade de serviço nos hosts e interconexões, tem-se dois aspectos básicos a considerar conforme ilustrado na figura 4.4: A comunicação entre a aplicação e as camadas superiores da rede (Níveis 4, 5...) deve ser priorizada para as aplicações com requisitos de QoS. Normalmente, este é um aspecto local vinculado ao ambiente operacional (Sistema operacional, cache,...) e utiliza recursos específicos do ambiente. O ajuste e definição desta "priorização" é uma tarefa normalmente atribuída ao gerente da rede ou do sistema em particular. Um segundo aspecto da qualidade de serviço nos hosts (origem e destino) e nas interconexões dos equipamentos é a garantia de QoS nas tecnologias de nível 2 (Ethernet, FDDI, outras). Segue uma discussão referente a esta questão em particular. Aplic. 4 Camadas Superiores TCP, UDP,... Comunicação entre camadas deve ser priorizada (Aspecto local dos hosts) 3 IP IP IntServ, DiffServ, RSVP, MPLS, LAN Como habilitar QoS nas tecnologias de redes locais (LANs) 19

20 Figura QoS nos Hosts A garantia de qualidade de serviço com as tecnologias de nível 2 se coloca nas seguintes situações práticas: Comunicação host - roteador; Comunicação roteador - host e Comunicação roteador - roteador em redes locais (LANs). Neste caso, a questão que deve ser resolvida é a seguinte: Como garantir que quadros (Frames) com pacotes prioritários (vinculados a um fluxo com QoS) possam ser priorizados entre si? Este problema pode ser abordado em determinados tipos de redes como segue: Nas implementações do ethernet usando LAN Switches, os padrões IEEE 802.1p e 802.1Q definem mecanismos de priorização de quadros; A tecnologia ATM tem embutida na sua concepção e definição inúmeros recursos para a garantia de qualidade de serviço das células e, assim sendo, pode facilmente priorizar células com pacotes prioritários; Outras tecnologias como o FDDI (Fiber Distributed Data Interface) possuem bits de prioridade que podem ser utilizados também para priorizar quadros com pacotes vinculados a fluxos com QoS. A questão mais global que segue é como definir e, eventualmente, padronizar o mapeamento da qualidade de serviço das aplicações com os diferentes mecanismos existentes nas tecnologias de rede de nível 2. Neste contexto o IETF está trabalhando na iniciativa ISSLL (Integrated Services over Specific Link Layers) [ISSLL_Charter]. O objetivo da iniciativa ISSLL é o mapeamento dos protocolos e serviços de QoS de nível superior (N 3) nos mecanismos dos protocolos de nível 2 como, por exemplo, o ethernet. Um dos resultados desta iniciativa é o desenvolvimento do SBM (Subnet Bandwidth Management) [SBM_Draft] para tecnologias de nível 2 compartilhadas (P. ex.: ethernet em hubs) e comutadas (P. ex.: ethernet em LAN Switches). O ISSLL define aspectos como: Estrutura de operação e comunicação SBM; Mapeamento da QoS (Nível superior < > Nível 2) e Protocolo de sinalização. Para uma relação completa de recomendações relacionadas com a solução SBM consultar [JSMNet] e [ISSLL_Charter]. 20

21 4.2.5 Dimensionamento A alternativa denominada "dimensionamento" é o que pode chamar-se de uma alternativa trivial. A idéia é bastante simples. No caso, a rede e seus recursos são dimensionados na fase de projeto de forma a não termos congestionamento. Por exemplo, faz-se um superdimensionamento da banda utilizada o que resulta na ausência de congestionamento ou de períodos de escassez de recursos durante a operação da rede. Esta solução apresenta duas dificuldades principais. A primeira corresponde ao custo associado na implementação do super-dimensionamento. Em particular para as redes WAN esta normalmente é uma alternativa proibitiva. A segunda dificuldade é a identificação dos pontos de ocorrência de congestionamento dada a multiplicidade e diversidade de equipamentos utilizados e a própria complexidade das redes. De maneira geral, esta não é uma solução muito prática e realista embora seja factível. 5. QoS - Mecanismos As alternativas técnicas discutidas são implementadas através da utilização de diversos tipos de mecanismos, a saber: Protocolos de sinalização Algoritmos de prioridade Algoritmos de escalonamento Algoritmos de controle de filas Algoritmos de congestionamento Em seguida, discutimos a funcionalidade e aplicabilidade de cada um destes mecanismos e identificamos implementações dos mesmos que são utilizadas em roteadores, hosts e outros equipamentos visando a garantia de qualidade de serviço. 5.1 Protocolos de Sinalização A finalidade de um protocolo de sinalização (Signalling Protocol) [Wu98] no contexto da qualidade de serviço em redes IP pode ser entendida como segue: 21 O protocolo de sinalização é utilizado pelas aplicações (hosts) para informar ou solicitação à rede sua necessidade de qualidade de serviço (QoS); Além disso, os protocolos de sinalização permitem também que os equipamentos de rede (Roteadores,...) possam trocar informações no sentido de cooperarem visando a garantia da qualidade de serviço aceita pela rede. Segue exemplos de protocolos de sinalização no contexto da qualidade de serviço: RSVP - Resource Reservation Protocol: utilizado na iniciativa IntServ do IETF LDP - Label Distribution Protocol: utilizado na alternativa MPLS para a distribuição de rótulos entre os equipamentos roteadores.

22 5.2 Prioridades Os algoritmos de prioridade (Priority Algorithms) são um outro mecanismo utilizado pelos equipamentos de rede para a garantia da qualidade de serviço. Neste contexto, a prioridade pode ser entendida como um mecanismo que provê diferentes tempos de espera para o processamento da informação (P. ex.: pacotes e/ ou quadros). Estes algoritmos são tipicamente implementados em roteadores mas algumas tecnologias de rede de nível 2 também suportam a utilização deste mecanismos. Segue alguns exemplos de algoritmos utilizados: IP Precedence: IP Precedence é definido na RFC 1122 e é uma solução de priorização de pacotes prevista no IPv4 no campo TOS (Type of Service) do cabeçalho dos pacotes IP. Priority Queuing: Algoritmo utilizado por alguns fornecedores utilizado para priorização de pacotes IP nas filas de saída de roteadores. Dentre as tecnologias de rede de nível 2 mais difundidas que suportam mecanismos de priorização eventualmente úteis na implantação de garantias de qualidade de serviço, podemos citar: ATM (Asynchronous Transfer Mode); Ethernet em LAN Switches (Padrões IEEE 802.1p e IEEE 802.1Q); FDDI (Fiber Distributed Data Interface); Token Ring e 100VG-AnyLAN 5.3 Escalonamento No contexto da qualidade de serviço discutida, o mecanismo de escalonamento tipicamente presente em equipamentos roteadores procura garantir que fluxos (streams) diferentes de pacotes obtêm os recursos que lhes foram alocados (banda e processamento). No caso, a banda e o processamento disponíveis são distribuídos de forma justa (Fairness) entre os fluxos ativos existentes no equipamento em questão. Alguns dos mecanismos de escalonamento utilizados são os seguintes: WRR - Weighted Round Robin GPS - Generalized Processor Sharing CBQ - Class Based Queuing WFQ - Weighted Fair Queuing 22

23 5.4 Controle de Filas Um outro aspecto que deve ser controlado numa fila diz respeito aos mecanismos de descarte de pacotes. A política de descarte de pacotes é necessária na ocorrência de um congestionamento e visa igualmente a garantia de eqüidade (Fairness) quanto à distribuição da banda e do processamento. Estes mecanismos normalmente não fazem nenhuma tentativa de evitar proativamente a ocorrência do congestionamento e podem ser parte integrante dos algoritmos de escalonamento de filas. Segue alguns exemplos de algoritmos lidando com o controle de filas: SFQ - Stochastic Fair Queuing CFQ - Class-Based Fair Queuing WFQ - Weighted Fair Queuing Como no caso anterior, estes mecanismos são utilizados tipicamente em equipamentos roteadores. 5.5 Congestionamento Os mecanismos de controle de congestionamento são também importantes para a implantação da qualidade de serviço numa rede IP. A idéia básica destes mecanismos é a inibição dos fluxos de pacotes durante o período de congestionamento de forma que os geradores de fluxos de pacotes IP reduzam a sua carga sobre a rede. Com menos pacotes sendo entregues à rede tem-se uma tendência de redução no nível de congestionamento. Neste sentido, estes mecanismos podem ser entendidos como mecanismos de controle de fluxo de pacotes. Segue alguns exemplos de algoritmos lidando com o congestionamento de filas de pacotes IP: RED - Random Early Detection WRED - Weighted Random Early Detection ECN - Explicit Congestion Notification Bibliografia [Com95] [Dscp_2474] [Dan98] [Dav96] Douglas E. Comer, "Internetworking with TCP/IP - Principles, Protocols and Architecture", Vol. 1, Prentice-Hall, K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, Daniel Minoli and Emma Minoli, "Delivering Voice over Frame Relay and ATM", Wiley Computer Publishing, David Ginsburg, "ATM Solutions for Enterprise Internetworking", Addison- Wesley,

24 [DiffServ_2474] [DiffServ_2475] [DiffServ_2597] K. Nichols, S. Blake, F. Baker, D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, December 1998 S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architecture for Differentiated Services, RFC 2475, December 1998 J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, Assured Forwarding PHB Group,RFC 2597, June 1999 [DiffServ_2598] V. Jacobson, K. Nichols, K. Poduri, An Expedited Forwarding PHB, RFC 2598, June 1999 [DiffServ_Charter] [IntServ_2211] [IntServ_2212] [IntServ_2215] [IntServ_2216] [IntServ_Charter] [ISSLL_Charter] [Jam98] [Job99] [JSMNet] [LDP_Spec] "IETF Differentiated Services Working Group". Em e J. Wroclawski, "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997 S. Shenker, C. Partridge, R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, Sept 1997 S. Shenker, J. Wroclawski, General Characterization Parameters for Integrated Service Network Elements, RFC 2215, September 1997 S. Shenker, J. Wroclawski, "Network Element Service Specification Template", RFC 2216, Sept 1997 "IETF Integrated Services Working Group". Em e "Integrated Services over Specific Link Layers", Em James D. McCabe, Practical Computer Network Analysis and Design, Morgan Kaufmann Series in Networking, Joberto Martins, "Redes Corporativas MultiServiço - Caracterização das Aplicações e Parâmetros Básicos de Operação", Em "JSMNet - Estado da Arte e P&D em Redes de Computadores". Em B. Thomas, N. Feldman, P. Doolan, L. Andersson, A. Fredette, LDP Specification, June 1999, <draft-ietf-mpls-ldp-05.txt>, Work in Progress. 24