Negociação e Autenticação de Serviços com QoS em Intra-Domínio
Carlos Rabadão1, 2, Edmundo Monteiro2
crab@estg.iplei.pt edmundo@dei.uc.pt
1 Escola Superior de Tecnologia e Gestão
Instituto Politécnico de Leiria Morro do Lena – Alto do Vieiro
2411-901 Leiria
http://www.estg.ipleiria.pt
2 Laboratório de Comunicações e Telemática
CISUC / DEI Universidade de Coimbra
Pólo II, Pinhal de Marrocos, 3030-290 Coimbra
http://lct.dei.uc.pt
Resumo
O principal objectivo do modelo de Serviços Diferenciados da IETF (DiffServ) é permitir o suporte de diferentes níveis de serviço a diferentes fluxos de informação agregados em classes de serviço (CoS), sobre uma infra-estrutura de comunicações TCP/IP. Este tratamento diferenciado poderá levar a que alguns utilizadores tentem obter melhor Qualidade de Serviço (QoS) para os seus fluxos sem contudo assumirem os custos associados, levando ao roubo de recursos que, em situações extremas, poderá ter como consequência a negação da qualidade de serviço – Denial of QoS (DQoS) – contratada pelos utilizadores para os seus fluxos de informação.
No modelo DiffServ a autenticação de fluxos é realizada, pacote a pacote, à entrada do domínio, com base na análise de um conjunto de campos do cabeçalho dos pacotes IP. Esta abordagem apresenta algumas limitações de segurança. De forma a minorar estas limitações, inerentes ao modelo DiffServ é, neste trabalho, proposto um sistema de negociação e de autenticação de QoS, destinado a autenticar clientes e a autorizar fluxos, de forma dinâmica, à entrada dos domínios DiffServ.
São apresentados dois cenários para autenticação de clientes e autorização de fluxos com QoS. Os aspectos de segurança considerados restringem-se à autenticação dos clientes e a autorização de fluxos para acesso aos recursos de comunicação. As questões relacionadas com a confidencialidade e integridade da informação são relegadas para outros módulos do sistema de comunicações, concretamente, para os protocolos TLS e IPSec. Para resolver a questão da autenticação dos fluxos são propostos e apresentados, neste trabalho, dois protocolos destinados ao funcionamento em ambiente intra e inter-domínio.
Palavras-chave
1. Introdução
Em sistemas de comunicação, a designação Qualidade de Serviço (QoS) é usada para caracterizar a capacidade de um sistema de comunicação suportar fluxos de dados com parâmetros de serviço (débito, atraso, jitter, perdas, etc.) garantidos de forma mais ou menos estrita. Os mecanismos de QoS impõem prioridades de acesso aos recursos disponíveis no sistema de comunicações. No caso particular do modelo DiffServ [1] esta prioritização de tráfego é suportada na identificação das Classes de Tráfego (grupos de múltiplos fluxos) efectuada com base no cabeçalho dos pacotes IP [2]. Esta abordagem apresenta algumas limitações de segurança conforme é discutido em [3].
De forma a minorar as limitações de segurança inerentes ao modelo DiffServ, são propostos na Secção 2 deste documento dois cenários de uma arquitectura para negociação de serviços com QoS. Nesta proposta, o cliente que pretende originar um fluxo terá inicialmente de se autenticar num Servidor de Autenticação que lhe disponibilizará credenciais para contactar o servidor de QoS. Posteriormente, o cliente solicitará ao Servidor de QoS a alocação de recursos de rede com as características pretendidas para o seu fluxo. A partir daqui e com baseado no contrato de serviço – Service Level Agreement (SLA) pré-estabelecido pelo cliente, o servidor poderá autorizar o novo fluxo, recorrendo para o efeito à reconfiguração do router de entrada no domínio DiffServ. Após a terminação da validade da autorização, o router será novamente configurado de forma a ser barrado ao fluxo o acesso ao domínio DiffServ.
Na Secção 3 serão apresentados dois protocolos complementares. . Estes protocolos pretendem oferecer um método mais seguro para negociação de estabelecimentos de fluxos com QoS. O primeiro protocolo estabelece os procedimentos do cliente enquanto que o segundo estabelece os procedimentos do lado do servidor.
Posteriormente, na Secção 4, será apresentado o testbed, constituído para validar os protocolos propostos, a sua forma de operar e alguns resultados experimentais.
Por fim, a Secção 5, será dedicada à avaliação do sistema proposto, sendo apresentadas algumas conclusões e indicações para trabalho futuro.
2. Arquitectura de Autenticação e Autorização para DiffServ
O modelo DiffServ tem por base um conjunto de mecanismos relativamente simples. À entrada de uma rede o tráfego é classificado, condicionado e integrado numa de diferentes classes de tráfego [1], sendo cada classe caracterizada pelo respectivo Differentiated Service Code Point (DSCP) [2].
Desta forma, o modelo DiffServ permite o suporte de diferentes níveis de serviço a diferentes fluxos de informação agregados em classes de serviço (CoS), sobre uma infra-estrutura de comunicações TCP/IP.
No modelo DiffServ a autenticação e autorização de fluxos é realizada, pacote a pacote, à entrada do domínio, com base na análise de um conjunto de campos do cabeçalho do pacote IP. Esta abordagem apresenta algumas limitações que poderão ser exploradas por utilizadores menos escrupulosos que tentem obter melhor qualidade de serviço para os seus fluxos sem
contudo assumirem os custos associados, levando ao roubo de recursos que, em situações extremas, poderá ter como consequência a negação da qualidade de serviço –Denial of QoS
(DQoS) – contratada pelos utilizadores para os seus fluxos de informação.
De forma a minorar estas limitações de segurança, inerentes ao modelo DiffServ, são propostos, nesta secção, dois cenários para autenticação dinâmica de clientes e autorização de fluxos, à entrada dos domínios DiffServ.
2.1 Cenário I: Autenticação e Gestão de SLA no ISP.
Neste cenário, o mais simples dos dois, o cliente não dispõe de qualquer tipo de equipamento para autenticação local nem para gestão de SLAs. Assim, sempre que o cliente pretenda originar um fluxo terá inicialmente de se autenticar no Servidor de Autenticação do Internet
Service Provider (ISP) que lhe disponibilizará credenciais para contactar o Bandwidth Broker
do domínio (BB). Posteriormente, o cliente solicitará ao BB a alocação de recursos de rede com as características pretendidas para o seu fluxo. A partir daqui, e com base no SLA pré-estabelecido do cliente, o BB poderá autorizar o novo fluxo, recorrendo para o efeito à reconfiguração do router de entrada no domínio DiffServ (Ingress Router). Após a terminação da validade da autorização, o router será novamente configurado, e desta forma será barrado ao fluxo o acesso ao domínio DiffServ. A Figura 1 apresenta o cenário descrito.
Figura 1 – Cenário I: Autenticação e Gestão de SLA no ISP.
A Figura 2 apresenta com maior detalhe este cenário, decomposto em 5 camadas: Gestão de SLA, Segurança, Contabilização, QoS e Equipamento.
2.1.1 Sistema Cliente
São as seguintes as funcionalidades dos diversos módulos que constituem o Sistema Cliente da arquitectura proposta: BB Autent CLIENTE ISP Cliente Contab. Router Router
Figura 2 – Cenário I decomposto em Camadas
Módulo de SLAs: responsável por negociar novos SLA ou alterações a SLA existentes, junto
do Sistema de Gestão de SLAs do ISP.
Módulo de Contabilização: responsável pela consulta à informação de contabilização
respeitante aos recursos utilizados pelo cliente.
Módulo de Autenticação: responsável por autenticar o cliente no Servidor de Autenticação do
ISP e receber credenciais para com elas se autenticar no Servidor de QoS do ISP.
Módulo de QoS: responsável por interceptar os requisitos de QoS pretendidos pelas aplicações
do cliente, encaminhar esses requisitos para o módulo Servidor de QoS e, nos casos em que o seu SLA o permita, encaminhar o fluxo após a remarcação dos cabeçalhos dos pacotes IP com o DSCP indicado pelo Servidor de QoS. A remarcação é facultativa pois também será efectuada no router de entrada do domínio DiffServ.
2.1.2 Sistema de Gestão
São as seguintes as funcionalidades dos diversos módulos que contituem o Sistema de Gestão da arquitectura proposta:
Módulo de SLAs: responsável pelas políticas de acesso ao domínio DiffServ. Negoceia novas
SLAs e renegoceia as já existentes, e após concluir a negociação actualiza a base de dados de
SLA SLA Contabilização Autenticação Autenticação QoS Controlo ER QoS Route r Autenticação Contabilização BB Cliente
Sistema Cliente Sistema de Gestão do ISP
QoS Equipamento Autenticação Accounting SLA Contabilização
políticas de acesso e os módulos de contabilização com os dados do novo cliente e de autenticação com uma nova conta de acesso ao domínio.
Módulo de Contabilização: disponibiliza informação do estado do accounting ao cliente.
Poderá utilizar-se informação referente à duração das credenciais, disponibilizada pelo módulo de Autenticação, em conjunto com informação disponibilizada pelo módulo de QoS referente aos requisitos de QoS disponibilizados, para contabilizar os recursos utilizados pelo cliente.
Módulo de Autenticação: responsável por proceder à autenticação do cliente no ISP e
disponibilizar credenciais para que o cliente se possa autenticar no módulo de QoS. A duração das credenciais poderá ser utilizada pelo módulo de contabilização.
Módulo de QoS: tem como principais tarefas a recepção de pedidos de disponibilização de
recursos provenientes dos clientes, a verificação dos requisitos pretendidos estarem de acordo com a SLA do respectivo cliente e em caso afirmativo a reconfiguração do router de entrada no domínio e a comunicação da disponibilidade de recursos ao módulo de QoS do cliente. Poderá também disponibilizar aos sistemas de contabilização informações referentes aos recursos utilizados.
2.2 - Cenário II: Autenticação e Gestão de SLA Local.
Neste cenário o cliente está inserido numa infra-estrutura de comunicações local que disponibiliza sistemas de autenticação e gestão de SLAs. O funcionamento do sistema entre o cliente e os sistemas locais assemelha-se em tudo ao funcionamento do Cenário I, que opera num âmbito intra-domínio. A grande diferença deste cenário relativamente ao anterior é o seu âmbito de funcionamento que se estende a dois domínios DiffServ distintos, isto é, opera num âmbito inter-domínio. Contudo, a solução proposta, limita-se à comunicação entre os domínios DiffServ do cliente e do ISP, não sendo apropriado para um cenário de comunicação global, envolvendo vários ISPs e consequentemente múltiplos domínios DiffServ. A Figura 3 apresenta o cenário descrito.
Figura 3 - Cenário II: Autenticação e Gestão de SLA Local.
Cliente
BB
DOMÍNIO ISP
Contab Autent Contab Autent
BB
DOMÍNIO CLIENTE
O funcionamento do sistema é semelhante ao do Cenário I até ao ponto em que o BB local recebe o pedido de alocação de recursos do cliente. O passo seguinte consiste na solicitação de credenciais por parte do módulo de autenticação local ao Sistema de Autenticação do ISP, para que o BB local possa comunicar com o BB do domínio do ISP. A partir daqui, e baseado no SLA pré-estabelecido do domínio cliente, o BB do ISP poderá autorizar o novo fluxo, informando o BB do cliente e procedendo à reconfiguração dos router de entrada do seu domínio DiffServ. Após a recepção da confirmação de alocação de recursos, o BB local irá informar o cliente e reconfigurar o seu router de entrada no domínio para que o fluxo se possa estabelecer.
Figura 4 – Cenário II decomposto em Camadas
Na Figura 4 é ilustrada uma estrutura mais detalhada, por camadas, do cenário descrito, tendo sido omitido o relacionamento entre o Cliente e o Sistema de Gestão do Cliente por ser em tudo semelhante ao descrito no Cenário I.
O funcionamento dos diversos módulos do Sistema de Gestão do Cliente combinam as funcionalidades de Sistema de Gestão e de Cliente do cenário anterior, pois comportam-se como sistema de Gestão quando solicitados pelo cliente e como Cliente quando solicitam o Sistema de Gestão do ISP. Já o funcionamento do Sistema de Gestão do ISP é em tudo semelhante ao descrito no cenário anterior.
SLA SLA Contabilização Contabilização Autenticação Autenticação QoS Controlo ER QoS Autenticação Contabilização BB
Sistema de Gestão do Cliente Sistema de Gestão do ISP
Autenticação BB Router Controlo ER Accounting SLA Autenticação QoS Equipamento Router Contabilização
3. Protocolos de Negociação
O primeiro dos cenários apresentados é, de todos, o mais simples, dispondo, no entanto, de todas as funcionalidades necessárias para testar a proposta. As diferenças entre os cenários resultam da reutilização de funcionalidades já contidas no primeiro cenário. Assim, serão propostos dois protocolos para o cenário descrito.
3.1 Protocolo de Negociação do Cliente
Este protocolo suporta a negociação de QoS do ponto de vista do Cliente. Para a descrição deste protocolo serão utilizados um Diagrama de Estados (Figura 5) e a correspondente Tabela de Transições (Figura 6).
Figura 5 – Diagrama de Estados do Protocolo de Negociação do Cliente
Conforme ilustrado na Figura 5, o Protocolo de Negociação do Cliente possui os seguintes estados:
Idle: estado atingido quando o protocolo é inicializado ou quando ocorre algum dos seguintes
eventos: Time Expires, QoS NACK, Auth. NACK e Timeout. O protocolo permanece neste estado até que seja recebido um pedido de estabelecimento de ligação (Connect Request).
Authentication Sent: após recepção do evento Connect Request, o protocolo transita para este
novo estado. As acções tomadas neste estado são: o pedido de credenciais ao Servidor de Autenticação e posterior autenticação no Servidor de QoS.
BAR Sent: o protocolo transita para este novo estado após o sucesso no processo de
autenticação, sinalizado pelo evento Auth. ACK. Após a recepção deste evento será enviado um pedido de alocação de recursos ao Servidor de QoS, denominado por BAR (Bandwidth
Allocation Request).
Data Transfer: se o pedido realizado no estado BAR Sent for satisfeito pelo Servidor de QoS
(QoS ACK), o protocolo transitará para este novo estado, onde a acção a tomar será o envio de dados com os parâmetros de QoS solicitados no BAR. Ao fim do tempo estabelecido para Duração do Fluxo, o protocolo sairá deste estado e passará para o estado inicial Idle.
Idle Authentication Sent BAR Sent Data Transfer Connect Request Auth. ACK QoS ACK Time Expires QoS NACK Auth. NACK/ Timeout
Na figura seguinte é apresentada a Tabela de Transições associada à máquina de estados anteriromente descrita. Event Present State Connect
Request Auth. ACK NACK Auth. Timeout ACK QoS NACK QoS Expires Time
Auth. Action Idle (0) 1 New state BAR NA NA Action Authentication Sent (1) 2 0 0 New state StartData NA Action BAR Sent (2) 3 0 New state StopData Action Data Transfer (3) 0 New state
Auth. – Envia informação para autenticação; BAR – Pedido de alocação de recursos com QoS StartData – Inicia a
transmissão de dados; StopData – Termina o envio de dados; NA – No Action
Figura 6 – Tabela de Transições do Protocolo de Negociação do Cliente
3.2 Protocolo de Negociação do Servidor de QoS
Este protocolo suporta a Negociação de QoS do ponto de vista do Servidor. Tal como na subsecção anterior, será utilizado um Diagrama de Estados (Figura 7) e uma da Tabela de Transições (Figura 8), para descrever o funcionamento do protocolo.
Figura 7 – Diagrama de Estados do Protocolo de Negociação do Servidor
Idle QoS Verify Router Configuration BAR BAR ACK Authentication Verify Wait Client Auth. Request Auth ACK/NACK BAR Timeout Client ACK/NACK Router ACK/NACK BAR NACK
Conforme ilustrado na Figura 7, o Protocolo de Negociação do Servidor possui os seguintes estados:
Idle: este estado é atingido quando o protocolo é inicializado ou quando ocorre algum dos
seguintes eventos: Client ACK, Client NACK, Auth NACK e Auth ACK. Permanece neste estado até ocorra um de 3 eventos: Pedido de autenticação (Auth. Request), Pedido de Alocação de Recursos (BAR) ou Fim de Validade do Pedido de Alocação de Recursos (BAR Timeout).
Authentication Verify: após a recepção do pedido de autenticação proveniente do Cliente
(Auth. Request) o protocolo transita para este estado. As acções tomadas neste estado serão a disponibilização de credenciais ao cliente por parte do Servidor de Autenticação e posteriormente a validação desses dados por parte do Servidor de QoS. Após esta validação o cliente poderá comunicar com o Servidor de QoS.
QoS Verify: após a recepção do evento BAR, transita para este novo estado. A acção tomada
neste estado é a validação do pedido de reserva de recursos, por parte do Servidor de QoS.
Router Configuration: o protocolo transita para este estado quando a resposta do Servidor de
QoS é favorável (BAR ACK). Aqui irá adicionar regras de filtragem ao Edge Router, para permitir novo fluxo.
Wait Client: o protocolo transitará para este estado se uma de três situações ocorrer: Pedido de
Alocação de Recursos negado (BAR NACK), Filtro adicionado ao Router (Router ACK) ou Filtro removido ao Router (Router NACK). Neste estado será informado o cliente relativamente à acção ocorrida.
Na figura seguinte é apresentada a Tabela de Transições correspondente à máquina de estados do protocolo, anteriormente descrita.
Event Present State Auth. Request Auth. ACK Auth. NACK BAR BAR ACK BAR NACK Router ACK Router NACK Client ACK Time Expires
AuthVer SLAVer RmFilt Action
Idle (0)
1 2 3 New state
SACK SNACK Action
Authentication Verify
(1) 0 0 New state
AddFilt SNACK Action
QoS Verify
(2) 3 4 New state
SACK SNACK Action
Router Configuration (3) 4 4 New state NA Action Wait Client (4) 0 New state
AuthVer – Verifica autenticidade do cliente; SACK – Envia ACK ao cliente; SNACK – Envia NACK ao cliente; SLAVer –
Verifica disponibilidade de recursos na SLA do cliente AddFilt – Adiciona filtro ao Router de entrada no domínio; RmFilt – Remove filtro do Router de entrada no domínio; NA – No Action.
4. Implementação
Nesta secção será abordada a implementação do testbed construído para validar os protocolos anteriormente apresentados, seguindo-se a descrição do funcionamento do sistema recorrendo a informações adquiridas no testbed.
4.1 Descrição do Protótipo
Na Figura 9 é apresentada a estrutura do protótipo construído para validar as propostas apresentadas na secção anterior. São descritos os diversos módulos que compõem o protótipo e os equipamentos aos quais estão associados.
Cliente: neste componente são implementados os módulos Cliente de QoS e Cliente de
Autenticação. O sistema operativo desta máquina é o Linux RedHat 6.2, com suporte de Kerberos V5 (Cliente de Autenticação). A implementação do Cliente de QoS baseia-se no DiffServ Daemon – (DSD), pertencente ao Bandwidth Broker da Universidade do Kansas [4] e num patch ao Kernel (2.2.17-05) para que os pedidos realizados ao kernel relacionados com serviços de rede sejam interceptados. Tem também instalado a aplicação ttcp alterada (ttcpds) com suporte de DiffServ. Esta aplicação destina-se à realização de testes com fluxos QoS.
Servidor: Neste componente são implementadas as funcionalidades do Sistema de Gestão do
ISP num único PC equipado com Linux RH 7.2, com suporte de DiffServ, HTTPd Apache com PHP, Base de Dados MySQL e Kerberos V5.
O módulo de Servidor de QoS é implementado em parte com recurso ao pacote de software do BB da Universidade do Kansas [4] e com recurso a uma ferramenta baseada no Traffic Control do Linux [5] para reconfiguração dos routers fronteira do domínio.
O Edge Router realiza a análise dos fluxos, pacote a pacote e a sua marcação/remarcação em conformidade com o estabelecido durante a autorização do fluxo, de acordo com o apresentado no ponto seguinte. BD CLIENTE Servidor de Autenticação BB Módulo Comunicação Módulo Configuração ROUTER Servidor Cliente de Autenticação Cliente de QoS CLIENTE 1 2 3 11 12 4 5 6,13 10,17 7,14 9,16 8,15 12
4.2 Experimentação
Inicialmente, foram definidos alguns SLAs, com recurso a alguns scripts, para que posteriormente fossem originados fluxos de informação com suporte de QoS. As características destes SLAs são guardadas na Base de Dados MySQL (BD).
O Cliente pretende estabelecer um fluxo de dados, através da aplicação ttcpds. O primeiro passo a dar será a autenticação da aplicação / utilizador, junto do Servidor de Autenticação e a posterior solicitação de credenciais (1) para que possa comunicar com o BB.
Após tomar posse das referidas credenciais (2), será iniciado o estabelecimento de um fluxo pela aplicação ttcpds, com destino ao PC servidor. Esta aplicação começa por disponibilizar um conjunto de parâmetros, necessários para o estabelecimento do processo de autorização do fluxo com QoS.
ttcpds –t –q –TEF –S09 –P10 –R10 -b100 10.3.0.249
O fluxo é interceptado pelo daemon DSD que com os parâmetros recolhidos, abre um socket TCP, e solicita autorização (3) junto do BB, para o estabelecimento de um novo fluxo, enviando um BAR
O BB identifica o cliente que originou o pedido através da SLA e, através da consulta à BD (4)(5), verifica se este ainda dispõe dos recursos necessários para estabelecer este fluxo. Em caso afirmativo, o BB acciona o módulo de comunicação com o router (6) que passa informação ao módulo de configuração do router (7). Posteriormente, este módulo irá configurar as regras de filtragem do router de fronteira do domínio (8) para que sejam disponibilizados os recursos solicitados para estabelecimento do fluxo em causa, pois o estado inicial do router de fronteira só permite o estabelecimento de fluxos Best Effort. Estas regras são implementados através do Traffic Control do Linux, que também realiza o policiamento e a marcação/remarcação dos pacotes do fluxo. O módulo de configuração do router informa o módulo de comunicação (9) de que já realizou a configuração das regras de filtragem e este por sua vez informa o BB (10)
De seguida, o BB autoriza o cliente (DSD) a estabelecer o fluxo e disponibiliza o DSCP a utilizar para marcar o fluxo (11) e o fluxo é estabelecido (12).
Caso o cliente já não disponha de recursos disponíveis, o fluxo é bloqueado pelo DSD.
Desta forma o fluxo originado no Cliente irá passar a dispor dos recursos solicitados para comunicar com o Cliente. No caso de serem ultrapassados os parâmetros solicitados, o comportamento do router fronteira dependerá do tipo de PHB do fluxo. Para o PHB AF os pacotes excedentes serão remarcados para Best Effort, e para o PHB EF o tráfego excedente será descartado.
No final do tempo pelo qual a reserva foi estabelecida, o BB volta a accionar o módulo de comunicação com o router (13) que passa informação ao módulo de configuração do router (14) para que este reconfigure as regras de filtragem do router de fronteira do domínio (15) e consequentemente os recursos deixem de ser disponibilizados ao fluxo em causa. O módulo de configuração do router informa o módulo de comunicação com o router (16) de que já realizou a configuração das regras de filtragem e este por sua vez informa o BB (17).
A Figura 10 mostra dois screen shots do protótipo, um referente ao funcionamento do BB (a) e o outro referente ao funcionamento do sistema de configuração do router (b).
(a) (b) Figura 10 – Screen Shots do testbed: (a) Bandwidth Broker (b) Router
Estas figuras resultam das respostas, do BB e do módulo de configuração do router, a um pedido de alocação de recursos (BAR) do Cliente, cuja resposta foi afirmativa. Após o período de duração da reserva, especificado no BAR, os recursos foram libertados através da reconfiguração do router de entrada no domínio.
5. Conclusão e trabalho futuro
Neste artigo foi discutida uma arquitectura para autenticação e autorização de fluxos com QoS. Os aspectos de segurança abordados restringiram-se à autenticação dos clientes e a autorização de fluxos para acesso aos recursos de comunicação. Para resolver a questão da autenticação dos fluxos foram propostos e apresentados dois protocolos, um relativamente ao funcionamento ao BB e outro relativamente ao funcionamento da configuração do router de fronteira de domínio. Os resultados preliminares apresentados mostram a potencialidade que estes protocolos têm para contribuir para uma maior segurança na autenticação de clientes e autorização de estabelecimento de fluxos com QoS.
Para trabalho futuro fica a experimentação mais exaustiva focando os aspectos de escalabilidade e desempenho da configuração dos routers fluxo a fluxo e o estudo do funcionamento do sistema de contabilização.
Agradecimentos
Este trabalho foi parcialmente financiado pelo programa de PRODEP suportado pelo Estado Português e pela União Europeia no âmbito do Fundo Social Europeu.
Referências
[1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architecture for
Differentiated Services, RFC 2475, IETF, Dezembro 1998.
[2] K. Nichols, S. Blake, F. Baker, D. Black, Definition of the Differentiated Services Fields
(DS Fields) in the IPv4 and IPv6 Headers, RFC 2474, IETF, Dezembro 1998.
[3] C. Rabadão, E. Monteiro, Segurança e QoS no Modelo DiffServ, CRC2002 – 5ª Conferência sobre Redes de Computadores, Faro – Portugal, Universidade do Algarve, 26 e 27 de Setembro de 2002.
[4] Bandwidth Broker da Universisade do Kansas, http://www.ittc.ku.edu/~kdrao/BB/
[5] Bert Hubert et al, Linux Advanced Routing & Traffic Control Howto, Revision 1.3.2, LDP, 5 de Março de 2003.
