Universidade Técnica de Lisboa Instituto Superior Técnico Gestão

Transcrição

Universidade Técnica de Lisboa
Instituto Superior Técnico
Gestão de Políticas de Qualidade de
Serviço
Laércio Cruvinel Júnior
(Licenciado)
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Documento Provisório
Prova concluída em: Setembro de 2004
Resumo
Este documento descreve a implementação de uma arquitectura normalizada
para aprovisionamento e gestão de recursos de qualidade de serviço num
ambiente de rede.
A escalabilidade da solução permite a sua adopção por ambientes corporativos
e educacionais.
A oferta de Qualidade de Serviço em uma rede passa pela correcta avaliação da
relação entre as necessidades dos utilizadores e os recursos disponíveis. A
utilização de políticas reutilizáveis e de atribuição dinâmica permite uma
gestão mais imediata, equilibrada e justa da distribuição dos recursos, segundo
critérios de necessidades dos utilizadores e hora do dia, entre outros.
A arquitectura e mecanismos dos Serviços Diferenciados – DiffServ –
desenvolvida pelo IETF, é aqui utilizada para viabilizar a implementação da
Qualidade de Serviço numa arquitectura normalizada com a definição dos
comandos de políticas de alto nível (SLA – Service Level Agreement) através
de XML, armazenamento destas definições num directório LDAP, e utilização
de uma Base de Informação de Políticas (PIB) independente de plataformas.
Implicando na separação entre gestão e utilização das políticas, este modelo
permite a reutilização dos objectos na hierarquia e a sua distribuição a partir da
PIB às entidades aplicadoras de políticas com o protocolo COPS. Assim, cada
tipo de encaminhador gerido pode ter o seu controlo de tráfego actualizado de
maneira consistente e imediata.
O foco principal deste trabalho é a implementação das políticas e do ambiente
de gestão em máquinas Linux, através da utilização de uma aplicação de
interface entre contratos de serviço com políticas de alto nível e um gestor de
aprovisionamento que distribui políticas de baixo nível para os sistemas
relevantes. Define um conjunto básico extensível de classes de serviço que
poderão auxiliar o administrador a classificar o tráfego e agregar os fluxos de
tráfego com requisitos semelhantes para que obtenham a quantidade adequada
de recursos da rede.
Palavras-chave:
Qualidade de Serviço, DiffServ, Gestão Baseada em
Políticas, PMT, PIB, COPS
i
Abstract
This thesis describes the implementation of a standard architecture for the
provisioning and management of quality of service resources in a network
environment.
The scalability of the solution will allow its adoption in other corporate or
educational networks.
The Quality of Service offers in a network depend on a correct evaluation of
the relationship between users’ needs and available resources. When reusable
and dynamic assignment policies are chosen, benefits include more immediate,
balanced and fair resource assignment, where the possible criteria are, among
many others, the users’ needs, time of the day, type of service, source and
destination of flows.
IETF’s Differentiated Services (DiffServ) architecture and mechanisms are
used here as a framework for Quality of Service implementation where
commands and high level policies (SLA – Service Level Agreement) are
initially defined using XML, then stored in a LDAP repository for further
reference, and mapped to a Policy Information Base (PIB) platformindependent.
The separation between policy management and utilization allows multiples
instantiations of the objects in the hierarchy, and their distribution from the PIB
to the policy enforcement entities (typically routers) with COPS protocol. So,
each type of managed router has its traffic control updated in a consistent and
immediate way.
This work focus on the implementation of the policies and related management
environment in Linux systems, thru the use of an application that provides an
interface between high level policies of service contracts and a provisioning
manager distributing low level policies to the relevant systems. It defines an
extensible framework of service classes, which may help classifying the traffic
and aggregating flows with similar requisits, with the purpose of allowing them
the adequate share of network resources.
Keywords: QoS, DiffServ, Policy-Based Management, PMT, PIB, COPS
iii
Agradecimentos
Agradeço à Prof. Teresa Vazão pelo apoio, orientação, incentivo e confiança
tanto durante este trabalho como na parte curricular do mestrado.
Agradeço ao Prof. Fernando Mira da Silva Corte Real pela confiança e
disponibilidades demonstradas desde o primeiro contacto e continuadas durante
todo o decorrer do mestrado.
Agradeço à Universidade Autónoma de Lisboa, nas pessoas dos directores do
Departamento de Ciências e Tecnologias, em especial ao Prof. Paulo Cabrita e
equipa, pela disponibilização de meios essenciais para a realização deste
trabalho.
À minha família agradeço com especial carinho, pelo incentivo, apoio e
compreensão durante este período de trabalho intenso. Agradeço à minha
amada e admirada esposa Célia, a luz desta família, que sempre nos permite
atracar em porto seguro. Agradeço à Carol e ao Felipe, dois filhos
excepcionais, o nosso orgulho.
Aos colegas Miguel Louro e Sara Silva agradeço o apoio e camaradagem nas
cadeiras deste mestrado.
Agradeço ao Hugo Silva, que também colaborou com equipamento para os
testes efectuados.
Além das pessoas com responsabilidade directa para este trabalho chegar ao
fim, agradeço aos meus pais, sogros, irmãos, cunhados e amigos próximos e
distantes, presentes e ausentes.
v
Índice
1 Introdução ................................................................................................. 1
1.1 Enquadramento Científico .................................................................. 1
1.2 Objectivos .......................................................................................... 3
1.3 Convenções Tipográficas ................................................................... 4
1.4 Estrutura da Dissertação..................................................................... 4
2 Tecnologias Seleccionadas ........................................................................ 7
2.1 Introdução .......................................................................................... 7
2.2 PBN – Policy-Based Networking ........................................................ 7
2.2.1 Introdução ...........................................................................................7
2.2.2 Definição de Política...........................................................................7
2.2.3 Aprovisionamento de Serviços ...........................................................8
2.2.4 Arquitectura ........................................................................................9
2.2.5 Linguagens de Especificação de Políticas ........................................10
2.2.6 O schema de Políticas do IETF.........................................................10
2.3 Serviços Diferenciados..................................................................... 12
2.3.1 Introdução .........................................................................................12
2.3.2 O Campo DS .....................................................................................13
2.3.3 Arquitectura DiffServ .......................................................................15
2.3.4 Sobre Algumas Disciplinas de Filas e Termos Associados ..............15
2.3.5 Classificação e Condicionamento do Tráfego ..................................15
2.3.6 Per-Hop Behaviors ...........................................................................15
2.4 XML ................................................................................................ 15
2.4.1 Introdução .........................................................................................15
2.4.2 DTD e Schema ..................................................................................15
2.4.3 Estrutura do Documento XML .........................................................15
2.4.4 XML e Java.......................................................................................15
2.5 LDAP............................................................................................... 15
2.5.1 Introdução .........................................................................................15
2.5.2 Estrutura da Informação LDAP ........................................................15
2.5.3 Acesso, Autenticação e Autorização.................................................15
2.5.4 Operações LDAP ..............................................................................15
2.5.5 LDAP e Java .....................................................................................15
2.6 PIB................................................................................................... 15
2.6.1 Introdução .........................................................................................15
2.6.2 Conceitos Gerais ...............................................................................15
2.6.3 Relação com MIB .............................................................................15
2.6.4 Operação ...........................................................................................15
2.6.5 O PIB DiffServ .................................................................................15
2.6.6 Implementação de uma Política de Aprovisionamento ....................15
2.7 COPS ............................................................................................... 15
2.7.1 Introdução .........................................................................................15
2.7.2 Principais Características ..................................................................15
2.7.3 Operação ...........................................................................................15
2.8 Trabalho Relacionado ...................................................................... 15
3 Arquitectura Proposta ............................................................................ 15
3.1 Introdução ........................................................................................ 15
ÍNDICE
3.2
3.3
3.4
Análise de Requisitos ....................................................................... 15
3.2.1 Requisitos Genéricos ........................................................................15
3.2.2 Estudo de Caso – Políticas de Qualidade de Serviço no IST............15
Esquema Geral ................................................................................. 15
3.3.1 Diagrama da Arquitectura.................................................................15
3.3.2 Operação ...........................................................................................15
3.3.3 Opções de Implementação ................................................................15
Blocos Funcionais ............................................................................ 15
3.4.1 Introdução .........................................................................................15
3.4.2 Interface do Utilizador ......................................................................15
3.4.3 Gestor de Conflitos e Tradutor de Políticas ......................................15
3.4.4 Repositório........................................................................................15
3.4.5 PDP ...................................................................................................15
3.4.6 PEP....................................................................................................15
3.4.7 Encaminhadores ................................................................................15
4 Detalhes da Solução Implementada ........................................................ 15
4.1 Introdução ........................................................................................ 15
4.2 Blocos Funcionais ............................................................................ 15
4.2.1 Introdução .........................................................................................15
4.2.2 Interface do Utilizador ......................................................................15
4.2.3 Gestor de Conflitos e Tradutor de Políticas ......................................15
4.2.4 Repositório........................................................................................15
4.2.5 PDP ...................................................................................................15
4.2.6 PEP....................................................................................................15
4.2.7 Encaminhadores ................................................................................15
4.3 Funcionamento Integrado ................................................................. 15
4.4 Limitações do Modelo ...................................................................... 15
5 Testes ....................................................................................................... 15
5.1 Introdução ........................................................................................ 15
5.2 Cenário de Testes ............................................................................. 15
5.3 Testes Funcionais ............................................................................. 15
5.3.1 Introdução .........................................................................................15
5.3.2 Configuração dos Encaminhadores...................................................15
5.3.3 Criação de SLA.................................................................................15
5.3.4 Criação do TCS.................................................................................15
5.3.5 Efeito do TCS no Transporte de Pacotes ..........................................15
5.3.6 Eliminação de TCS ...........................................................................15
5.4 Testes de Desempenho ..................................................................... 15
5.4.1 Introdução .........................................................................................15
5.4.2 Desempenho das Aplicações.............................................................15
5.4.3 Policiamento na Interface Externa ....................................................15
5.4.4 Condicionamento no Encaminhador Interior – Classe Única...........15
5.4.5 Condicionamento no Encaminhador Interior – Três Classes............15
5.4.6 Desempenho do Tráfego Condicionado nas Sub-Redes ...................15
6 Conclusões e Trabalho Futuro ................................................................ 15
A. Ficheiros de validação DTD .................................................................... 15
B. O Schema de Políticas LDAP .................................................................. 15
C. PIB – Policy Information Base ................................................................ 15
D. O Script para Encaminhadores ............................................................... 15
E. Diagramas de Classes .............................................................................. 15
Bibliografia ................................................................................................... 15
Acrónimos e Abreviaturas............................................................................ 15
ix
Lista de Figuras
Figura 2.1: Abstracções do Modelo CIM/DEN ...........................................................11
Figura 2.2: Fluxo de Informação na Definição da QdS ...............................................12
Figura 2.3: Os Bits DiffServ em IPv4 ..........................................................................14
Figura 2.4: Arquitectura do Modelo de Serviços Diferenciados .................................15
Figura 2.5: Módulos de Classificação e Condicionamento do Tráfego.......................15
Figura 2.6: Uma Árvore de Informação de Directório (DIT) ......................................15
Figura 2.7: Funcionamento do referral........................................................................15
Figura 2.8: Ordenação dos Elementos do TCB no Data Path.....................................15
Figura 2.9: Data Path para Agregar Tráfego HTTP em AF21....................................15
Figura 2.10: Modelo de Aprovisionamento COPS ......................................................15
Figura 2.11: Mensagens COPS entre PDP e PEP ........................................................15
Figura 3.1: Arquitectura Proposta................................................................................15
Figura 3.2: Opções de Classificação e Condicionamento do Tráfego .........................15
Figura 3.3: A Policy Management Tool.......................................................................15
Figura 3.4: O Policy Decision Point ............................................................................15
Figura 3.5: Construção de uma Política com PIB........................................................15
Figura 3.6: O Policy Enforcement Point......................................................................15
Figura 3.7: Os papéis das interfaces ............................................................................15
Figura 3.8: Tráfego VoIP vs. Tráfego FTP ..................................................................15
Figura 3.9: Processamento de Dados da Rede no Linux .............................................15
Figura 3.10: Configuração da Interface Externa – Policiamento de Entrada ..............15
Figura 3.11: Configuração da Interface Interna – Filas de Saída.................................15
Figura 4.1: Funcionamento da Interface com o Utilizador ..........................................15
Figura 4.2: Ecrã de Configuração dos TCS .................................................................15
Figura 4.3: Relação da PMT com outros Módulos ......................................................15
Figura 4.4: Esquema de Funcionamento do PDP ........................................................15
Figura 4.5: Ficheiro de Configuração para o PEP .......................................................15
Figura 4.6: Esquema de Funcionamento do PEP.........................................................15
Figura 4.7: Realização dos Módulos DiffServ no Linux ............................................15
Figura 4.8: Funcionamento Integrado da Arquitectura Proposta.................................15
Figura 5.1: Ambiente de Testes ...................................................................................15
Figura 5.2: Classes Definidas no Repositório..............................................................15
Figura 5.3: Configuração do Encaminhador de Fronteira ...........................................15
ÍNDICE
Figura 5.4: Configuração do Encaminhador Interior...................................................15
Figura 5.5: Criação de um SLA ...................................................................................15
Figura 5.6: O SLA no Repositório...............................................................................15
Figura 5.7: XML da Criação de um SLA ....................................................................15
Figura 5.8: Condições e Acções Criadas no Repositório.............................................15
Figura 5.9: Atributos do TCS no Repositório..............................................................15
Figura 5.10: XML da Criação de um TCS...................................................................15
Figura 5.11: Comando tc Enviado para a Shell Linux...............................................15
Figura 5.12: Relatório de Filtros no Encaminhador de Fronteira ................................15
Figura 5.13: Análise de um Pacote Capturado.............................................................15
Figura 5.14: XML para Remoção de um TCS .............................................................15
Figura 5.15: Remoção de um TCS no PEP..................................................................15
Figura 5.16: Comandos ping sem Condicionamento...................................................15
Figura 5.17: Comandos ping com Condicionamento ..................................................15
Figura 5.18: Policiamento do Tráfego .........................................................................15
Figura 5.19: Configuração da Classe AF2 ...................................................................15
Figura 5.20: Resultados com Configuração Padrão.....................................................15
Figura 5.21: Descarte de Pacotes AF21 .......................................................................15
Figura 5.22: Policiador AF31 com Remarcação para AF32 e AF33 ...........................15
Figura 5.23: Resultados dos Testes para Diferentes Tamanhos de Pacotes ................15
Figura 5.24: Utilização das Prioridades de Descarte AF3 ...........................................15
Figura 5.25: Execução do ping..................................................................................15
Lista de Tabelas
Tabela 2.1: Prioridade IP .............................................................................................14
Tabela 2.2: Valores DSCP das Classes DiffServ.........................................................15
Tabela 2.3: Entidades Especiais em XML...................................................................15
Tabela 2.4: ObjectClassDescription (RFC 2252)........................................................15
Tabela 2.5: Comandos LDAP ......................................................................................15
Tabela 2.6: Hierarquia de Tabelas PIB na Mensagem notify.......................................15
Tabela 2.7: Hierarquia de Tabelas PIB na Mensagem install......................................15
Tabela 2.8: Parâmetros da PRC frwkIpFilterTable......................................................15
Tabela 3.1: Condicionamento do Tráfego de Saída no IST.........................................15
Tabela 3.2: Condicionamento do Tráfego de Entrada no IST .....................................15
Tabela 3.3: Mapeamento das Classes de Serviço ........................................................15
Tabela 3.4: Configuração de uma Política...................................................................15
Tabela 3.5: Aplicação de Políticas às Interfaces..........................................................15
Tabela 4.1: Comandos Trocados entre PMT e Interface do Utilizador .......................15
Tabela 4.2: Comandos da PMT para o PDP ................................................................15
Tabela 4.3: Atributos da Tabela FrwkIpFilterEntry (RFC 3318)................................15
Tabela 5.1: Policiamento com Diversas Larguras de Banda .......................................15
Tabela 5.2: Policiamento com Diversas Larguras de Banda .......................................15
Tabela 5.3: Perdas e Tempos de Transmissão para a Classe AF21 .............................15
Tabela 5.4: Desempenho do Tráfego não Condicionado.............................................15
Tabela 5.5: Desempenho do Tráfego Condicionado....................................................15
1
Introdução
1.1 Enquadramento Científico
A necessidade de proporcionar Qualidade de Serviço (QdS) ao tráfego da
Internet (ou mais genericamente, em ambientes de redes IP interligadas) tem
resultado num esforço de definição de novos modelos de serviço pelos
organismos competentes.
Actualmente, o tráfego de vídeoconferência, chamadas de voz e outros serviços
multimédia através de redes IP é tratado da mesma forma que qualquer outro
conjunto de informação em trânsito. O tratamento dado pelo protocolo IP à
generalidade dos pacotes baseia-se num modelo de serviço de melhor esforço
(BE – Best Effort) e igualdade de condições. Neste modelo, não há garantias de
entrega dos pacotes nem distinções de prioridade para os diferentes fluxos de
tráfego.
O grande aumento na oferta de largura de banda durante a década de 1990,
aliado á evolução dos sistemas pessoais de computação (PC, PDA, portáteis)
ajudou a criar uma era da ligação: telemóveis e programas de mensagens em
linha (chats e outros) são exemplos de entidades que aliciam utilizadores
através da multimédia. Como resultado, há períodos de congestão nas redes e a
degradação dos serviços é mais facilmente notada nas aplicações multimédia.
Porém, as limitações da largura de banda não são os únicos responsáveis por
um mau desempenho das aplicações multimédia. Estas também são
caracterizadas por exigirem um atraso máximo entre os pacotes recebidos, o
que é incompatível com o tratamento igualitário e tradicional entre este tráfego
e todos os outros pacotes da rede [RFC3714]. Na Internet, esta situação é
agravada pela imprevisibilidade e irregularidade dos padrões de tráfego entre
quaisquer dois destinos de pacotes [Floyd95a], [Pongsiri].
Tal como as auto-estradas têm implicações importantes na economia e na
qualidade de vida das pessoas (ver, por exemplo, um estudo do Banco Mundial
em http://www.worldbank.org/transport/publicat/twu-30.pdf sobre pobreza e
transporte), a banda larga é importante para o bom desempenho das redes de
comunicação hoje em dia. Entretanto, a sua utilização em exclusivo para
solução dos problemas de tráfego vai provavelmente traduzir-se em piores
condições para gestão no médio ou longo prazo. Melhores resultados podem ser
alcançados com o estudo sistemático das condições e perfis do tráfego na rede
em causa, o que pode permitir uma optimização da utilização dos recursos,
evitando desperdícios [Balliache].
O organismo internacional responsável por elaborar e manter as normas
relativas à Internet (entre outras) é o Internet Engineering Task Force (IETF).
Propõe algumas tecnologias para abordar a questão da qualidade de serviço em
redes IP: os modelos IntServ e DiffServ e modelos de Encaminhamento por
Restrições (Constraint Based Routing), tal como o Multiprotocol Label
Switching (MPLS) [RFC2702].
1
1. INTRODUÇÃO
A provisão de QdS fim a fim através de Classes de Serviço para onde são
mapeados os fluxos de tráfego é proposta no modelo IntServ (Integrated
Services) [RFC2210]. Três classes distintas de serviço (BE, Carga Controlada e
Serviço Garantido) permitem a reserva de recursos nos nós da rede através do
protocolo RSVP (Resource Reservation Protocol).
Embora a QdS solicitada para cada fluxo seja garantida, os mecanismos
utilizados para manutenção das reservas prejudicam a adopção do modelo
IntServ em redes de grande dimensão. Não sendo escalável, o modelo ainda é
válido para necessidades específicas de QdS, por exemplo em redes de acesso e
conjugado com outros mecanismos (e.g. DiffServ) [Breslau].
O modelo DiffServ (Differentiated Services) [RFC2475] do IETF pretende
definir uma arquitectura escalável onde políticas de alto nível (SLA) são
negociadas entre o cliente e o fornecedor do serviço. O tráfego é marcado e
agregado para implementar políticas de QdS segundo classes de serviço
configuradas ou implícitas (classe BE). Os encaminhadores da periferia de uma
rede marcam e policiam o tráfego e os encaminhadores internos aplicam a cada
agregado o comportamento especificado em cada classe de serviço. É utilizada
uma parte do antigo campo ToS (Type of Service) no cabeçalho IP dos pacotes.
Os bits 0 a 5 do ToS foram renomeados campo DSCP (DiffServ Code Point),
ficando os bits 6 e 7 actualmente com a designação ECN (Explicit Congestion
Notification) [RFC3168].
As características stateless do DiffServ (não é necessário manter informação de
estado para cada fluxo) o tornam adequado para ser utilizado em redes
nucleares de grandes dimensões. Entretanto, o modelo não impõe limites de
largura de banda aos agregados atribuídos a cada classe e também não
especifica as regras para o controlo do acesso e atribuição dos recursos. Assim,
não será suficiente para resolver as questões de configuração de serviços e
gestão de uma rede com equipamentos heterogêneos e aplicações distribuídas.
O encaminhamento por restrições é uma aproximação que engloba [RFC2702]
o modelo de encaminhamento por QdS utilizado, por exemplo, pelo MPLS.
Este é aplicado em redes nucleares por equipamento devidamente configurado,
e permite a definição de rotas explícitas predefinidas entre redes, rotas estas
que são transportadas numa etiqueta extra em cada pacote, independentemente
do seu protocolo. O encaminhamento por restrições extende este conceito,
podendo incluir múltiplos parâmetros de selecção de rotas.
Também têm sido propostos e testados modelos conjuntos das tecnologias
descritas, sendo provável uma evolução no sentido da utilização de DiffServ e
IntServ nas redes de acesso [RFC2998], e DiffServ e encaminhamento por
restrições nas redes nucleares [MOICANE].
O modelo DiffServ não tem especificações para administração centralizada e
controlo de acesso. Esta lacuna pode ser preenchida com a adopção em paralelo
do PBN (Policy-Based Networking), um modelo desenvolvido pelo grupo RAP
do IETF [RAP], [RFC2753] e orientado também para redes IntServ.
Um dos desafios que uma implementação destes modelos deve propor-se a
resolver é a necessidade de uma interface entre os SLA (políticas de alto nível)
e os comandos de configuração dos diversos encaminhadores (políticas de
baixo nível). O IETF disponibiliza para este fim uma Base de Informação de
2
OBJECTIVOS
Políticas (PIB – Police Information Base) através da qual as políticas podem
ser transportadas entre o gestor de políticas e os equipamentos encaminhadores
onde devem ser aplicadas. O protocolo de transporte de PIB é o COPS
(Common Open Police Service), e o aprovisionamento de políticas é efectuado
com o COPS-PR (COPS Usage for Police Provisioning). Outro elemento
importante da arquitectura DiffServ é o repositório, que armazena e permite a
reutilização de políticas.
1.2 Objectivos
A gestão de políticas para controlo de tráfego numa rede corporativa ou
académica pode ser aplicada por scripts a um encaminhador Linux no ponto de
ligação da rede com o exterior, e nos encaminhadores interiores. A
flexibilidade do software disponível naturalmente no Linux [Hubert] aliada à
disponibilidade de módulos programados para selecção qualitativa do tráfego
[SForge] tem permitido um controlo qualitativo e quantitativo eficaz do tráfego
(ver, por exemplo, diagramas de tráfego publicados pelo Instituto Superior
Técnico em https://ciist.ist.utl.pt/netgraphs/ISTnet.html). Este trabalho propõe
uma adaptação dos procedimentos para controlo do tráfego em redes
(corporativas, académicas), de forma que mais facilmente evoluam para uma
arquitectura normalizada.
A arquitectura sugerida e as ferramentas desenvolvidas permitem:
•
A definição das políticas independentemente da marca ou modelo dos
equipamentos onde serão instaladas.
•
O suporte às classes de serviço DiffServ normalizadas pelo IETF: EF
(Expedited Forwarding), AF1 a AF4 (Assured Forwarding) com três
prioridades de descarte (drop priority) cada uma, e BE (Best Effort).
•
A utilização dos scripts necessários para aplicar as políticas desejadas
em encaminhadores Linux de fronteira e interiores, a partir de uma
interface para políticas de alto nível.
•
A verificação da consistência e gestão de conflitos entre as políticas.
•
A gestão da largura de banda disponível por contrato (SLA) e por fluxo
individual em cada contrato (TCS – Traffic Conditioning Specification).
As tecnologias envolvidas nesta arquitectura incluem:
•
XML para especificação das políticas ao nível mais elevado e
comunicação entre os módulos.
•
LDAP [RFC2251] para prover as funções de repositório e assim permitir
o armazenamento de políticas reutilizáveis.
•
Policy Information Base (PIB) [RFC3317], [RFC3318] para representar
os dados transportados pelo protocolo COPS.
•
SPPI (Structure of Policy Provisioning) [RFC3159], uma linguagem
para definição das tabelas PIB.
3
1. INTRODUÇÃO
•
o protocolo COPS [RFC2748] como opção para a comunicação entre os
pontos (objectos) de decisão e os pontos de aplicação das políticas,
sendo também utilizado para o próprio aprovisionamento de políticas
nos sistemas distribuídos (COPS-PR [RFC3084]).
•
mecanismos DiffServ, tc (traffic control) em sistemas Linux [SForge].
•
programação Java para interface com o utilizador, integração com XML
e LDAP e geração dos PIB e scripts.
Embora não haja implementações completas disponíveis, tem havido
documentos relativos a testes baseados na mesma arquitectura discutida aqui,
ou em parte dela [Majalainen], [Tequila], [Calhariz].
1.3 Convenções Tipográficas
Negro
Utilizado para realçar termos específicos quando de
sua primeira utilização, definição ou caracterização.
Itálico
Formato das palavras ou expressões em língua
estrangeira.
Largura Constante
Exemplos de comandos, código fonte ou referências
no texto a parâmetros ou palavras-chave.
Itálico Constante
Distingue variáveis, palavras chave ou parâmetros a
serem introduzidos do texto literal.
1.4 Estrutura da Dissertação
Este trabalho está estruturado em 6 capítulos e 5 anexos.
Este capítulo faz o enquadramento científico da tese, indica os seus objectivos,
as convenções tipográficas utilizadas e apresenta a estrutura da dissertação.
O capítulo 2 apresenta e analisa as principais tecnologias utilizadas. São
descritos os modelos de gestão por políticas e o DiffServ, o LDAP, a Base de
Informação de Políticas (PIB) e o protocolo COPS. As referências
bibliográficas possibilitam a investigação dos aspectos destas tecnologias que
ultrapassam o interesse para esta tese de mestrado. Também neste capítulo são
indicados alguns trabalhos relevantes relacionados com os temas em discussão.
No capítulo 3 é apresentada a arquitectura base para esta implementação.
Inicialmente, são discutidos os procedimentos correntes para controlo da
qualidade de serviço numa rede típica (rede do Instituto Superior Técnico em
Lisboa), na óptica da possível evolução para o modelo PBN (Policy-Based
Networking). A utilização do modelo PBN
no contexto dos Serviços
Diferenciados, acrescenta as mais-valias da gestão centralizada, abstracção da
informação de gestão, homogeneidade de procedimentos para os vários
equipamentos, interface integrada e consistente [RFC2753]. A partir de um
esquema geral da arquitectura proposta, os seus blocos funcionais são
identificados e analisados.
4
ESTRUTURA DA D ISSERTAÇÃO
A solução aplicada é descrita no capítulo 4. A implementação de cada bloco
funcionais é detalhada e comparada com o modelo conceptual discutido no
capítulo anterior. É feita uma avaliação da adequação do modelo para as
necessidades do IST e são discutidas as suas limitações.
O capítulo 5 detalha o ambiente para os testes efectuados e mostra os resultados
mais relevantes relativamente à funcionalidade e desempenho da
implementação. São utilizadas, sempre que possível, ferramentas padrão do
Linux para simular carga, efectuar medições e apresentar os resultados. Cada
teste é acompanhado de uma avaliação e indicação da sua importância para a
adopção da solução em redes de produção.
As conclusões e sugestões de trabalho futuro são apresentadas no capítulo 6.
O Anexo A apresenta a listagem dos DTD (Document Type Definition,
equivalente a um schema de definição de atributos e valores possíveis)
utilizado para o transporte em formato XML das políticas de alto nível.
O Anexo B contém o schema de políticas de alto nível no repositório LDAP.
No Anexo C encontra-se um exemplo de PIB para implementação das políticas
num encaminhador de fronteira.
O script de implementação das classes DiffServ nos encaminhadores Linux de
fronteira e interiores é apresentado no Anexo D. Este script é consistente com o
PIB exemplo do Anexo C.
O Anexo E mostra o diagrama de classes das aplicações desenvolvidas.
5
2
Tecnologias Seleccionadas
2.1 Introdução
Este capítulo descreve as tecnologias seleccionadas para a implementação do
modelo proposto, algumas em fase de maturação e outras adoptadas com
sucesso nas redes empresariais.
As tecnologias mais recentes aqui abordadas incluem os conceitos de PolicyBased Networking (no que respeita à aplicação de políticas para Qualidade de
Serviço), Serviços Diferenciados (DiffServ), Policy Information Base (PIB) e
protocolo COPS.
Também fazem parte da implementação realizada as tecnologias XML e LDAP,
utilizadas em larga escala nos ambientes de rede modernos.
Outros modelos ou outras tecnologias poderiam ter sido utilizados – por
exemplo, tecnologias baseadas no trabalho desenvolvido pelo professor Morris
Sloman e outros, do Imperial College, em Londres [Lymberopoulos]. A opção
pelo modelo e tecnologias oriundas do IETF justifica-se pelo elevado número
de trabalhos relacionados com qualquer uma delas e pela adopção e
disponibilidade generalizada da maior parte das tecnologias abordadas.
2.2 PBN – Policy-Based Networking
2.2.1 Introdução
Em redes corporativas, novas tecnologias não são introduzidas porque estejam
normalizadas ou facilmente acessíveis, mas se satisfizerem uma necessidade do
negócio. As definições das políticas de alto nível (aquelas visíveis ao operador
da rede e muitas vezes aos clientes) são condicionadas por estas necessidades,
enquanto que as especificidades tecnológicas limitam a definição das políticas
de baixo nível (visíveis pelos equipamentos) [Verma].
O conceito de Policy-Based Networking (PBN) aplicado à Qualidade de
Serviço, permite a definição de políticas de QdS (gestão de prioridades e
utilização de recursos pelos vários tipos de tráfegos em uma rede, de forma a
servir eficientemente os utilizadores) em dois níveis: negócio e tecnologia.
Primeiramente, as políticas são introduzidas com termos relativamente simples
numa estação de administração. Depois, são traduzidas para uma forma mais
adequada do ponto de vista tecnológico e enviadas para os dispositivos de rede.
2.2.2 Definição de Política
A definição de política deriva de duas perspectivas [RFC3198]:
•
É uma meta, curso ou acção que determina decisões presentes e futuras.
7
2. TECNOLOGIAS SELECCIONADAS
•
É um conjunto de regras para administrar e controlar o acesso aos
recursos de uma rede informática.
Um sistema baseado em políticas usa as regras de políticas (policy rules)
como blocos funcionais básicos. Estas regras são ligações entre condições e
acções, onde a avaliação das condições determina que acções serão levadas a
efeito [RFC3060].
As políticas podem ser formalizadas em alto nível ou em baixo nível. As
políticas de alto nível estão especificadas em termos familiares e num formato
intuitivo para o administrador ou utilizador da rede. A sua especificação é
independente da implementação subjacente e pode utilizar qualquer mecanismo
que seja adequado, por exemplo, o XML. O IETF tem definido um modelo de
informação de políticas para representar, administrar, partilhar e reutilizar a
informação de políticas independentemente dos equipamentos específicos em
que serão configuradas (ver a secção 2.2.5).
As políticas de baixo nível são formalizadas de maneira que um agente de
políticas em cada elemento de rede afectado possa fazer o seu mapeamento para
a configuração específica daquele equipamento. A geração de políticas de baixo
nível a partir das políticas de alto nível nem sempre é um processo linear ou
padronizado, devido às particularidades dos mecanismos de configuração de
cada elemento de rede.
Um comando de políticas (policy statement) é um conjunto de definições para
condicionar a atribuição dos recursos da rede aos seus consumidores, que
podem ser utilizadores ou sistemas individuais, departamentos, aplicações, etc.
O termo política de aprovisionamento define um modelo em que os elementos
de rede são configurados por políticas antes de processar quaisquer eventos. A
configuração é enviada para o dispositivo com base numa escala temporal ou na
inicialização do mesmo. Este modelo constrasta com a política de outsourcing,
em que o agente de política no elemento de rede solicita a outro componente
decisões relativas a eventos específicos. Os dois modelos não são mutuamente
exclusivos, podendo ser utilizados em conjunto.
2.2.3 Aprovisionamento de Serviços
Neste trabalho, aplicamos as definições que o IETF faz de serviço e os termos
associados [RFC3198], [RFC3260], no contexto dos Serviços Diferenciados.
Serviço é definido como o comportamento ou funcionalidade oferecidos por
uma rede, elemento de rede ou sistema.
SLA é o documento que resulta da negociação entre cliente e provedor
referente aos atributos do serviço. SLS é o conjunto de parâmetros e seus
valores que definem o serviço oferecido a um fluxo de tráfego por um domínio
DiffServ.
TCA (Traffic Conditioning Agreement) é o acordo que especifica regras de
classificação e os perfis de tráfego correspondentes, bem como as regras de
medição, marcação, descarte e/ou atraso selectivo a aplicar. TCS (Traffic
Conditioning Specification) é o conjunto de parâmetros e seus valores que no
8
PBN – P OLICY-B ASED NETWORKING
todo permitem especificar as regras de classificação e o perfil do tráfego no
ambiente DiffServ.
TCS são parte integral de um SLS. Adicionalmente aos parâmetros definidos
num TCS, o SLS pode especificar:
•
Disponibilidade e fiabilidade do serviço, incluindo o comportamento em
cado de faltas.
•
Serviços e mecanismos de segurança: encriptação, autenticação,
monitorização e auditoria.
•
Restrições de encaminhamento.
•
Definição das responsabilidades em caso de quebra do contrato.
•
Mecanismos de contabilização.
A avaliação do cumprimento de um contrato baseia-se também na qualificação
e no contexto do serviço. Os serviços podem ser categorizados como
qualitativos (e.g. “tráfego com baixo retardo”) e quantitativos (e.g. “99% dos
pacotes devem ser entregues”). O contexto de um serviço define a fronteira
topológica onde ele se aplica, incluindo pontos de entrada e pontos de saída do
tráfego.
O IETF sugere [RFC3670] a definição de um conjunto de classes e associações
que representam um nível de abstracção dos serviços. Esse nível de abstração
permite utilizar uma nomeclatura genérica para os serviços, conhecida como
“Serviço Olímpico”, com classes “Ouro”, “Prata”, “Bronze”.
2.2.4 Arquitectura
Um comando de política de alto nível utilizado por um administrador da rede
deveria ser tão natural como:
“Faça o encaminhamento mais rápido possível do tráfego de videoconferência
oriundo ou destinado à sala de reuniões entre as 15 e as 16 horas.”
Na prática, actualmente são necessários comandos mais detalhados e técnicos,
mas a evolução do modelo de políticas numa arquitectura estruturada permite o
desenvolvimento de níveis de abstracção elevados. A abordagem do IETF ao
modelo PBN [RFC3644], [RFC2753] é exemplo desta evolução e utiliza um
framework padrão de políticas e protocolos relacionados, que incluem:
•
Uma consola de gestão para permitir criar, editar ou consultar políticas
num repositório, através de uma linguagem adequada de especificação.
•
O repositório, que permite armazenar e reutilizar políticas. O IETF
recomenda a sua implementação num directório LDAP [RFC2475].
•
Uma Policy Management Tool (PMT), que faz a manutenção e gestão de
conflitos entre as políticas.
•
Um servidor conhecido como Policy Decision Point (PDP), que lê as
políticas no repositório e faz a sua distribuição aos elementos de rede. O
IETF sugere o formato PIB (Policy Information Base) e o protocolo
COPS (Common Open Policy Service) para distribuição das políticas.
9
•
Equipamentos de rede onde as políticas são implementadas para serem
aplicadas ao tráfego, denominados Policy Enforcement Points (PEP).
Este capítulo analisa cada uma das tecnologias que permitem implementar o
modelo PBN. No capítulo 3 a arquitectura completa é analisada em detalhe.
2.2.5 Linguagens de Especificação de Políticas
Não há uma linguagem de políticas universalmente aceite. Algumas linguagens
são naturalmente proprietárias e ligadas a produtos de gestão particulares. Os
domínios de aplicação de uma linguagem de políticas são o controlo de acesso
e a gestão de recursos [Sloman].
Grupos de trabalho do Imperial College em Londres definiram a linguagem
PONDER (Path Based Policy Language) [PONDER], considerada uma das
mais expressivas e que suporta tanto o controlo de acesso (políticas de
autorização) quanto a gestão de recursos (políticas de obrigação). A seguir
mostramos dois exemplos de definição de políticas com PONDER:
inst auth+ switch ProfileOps {
subject /NetworkAdmin;
target <PerfilT>/Nregion/switches;
action load(),remove(),enable(),disable();}
Membros do domínio NetAdmin ficam autorizados a carregar, rremover,
habilitar e desabilitar objectos do tipo PerfilT no domínio Nregion/switches.
inst auth- /negativeAuth/testRouters {
subject /testEngineers/estagiarios;
action performance_test();
target /routers;}
Os engenheiros em estágio de teste ficam proibidos de realizar testes nos
encaminhadores. A política fica armazenada no domínio /negativeAuth.
Outra aproximação para uma linguagem de especificação de políticas foi a
PFDL (Policy Framework Definition Language), que esteve em processo de
desenvolvimento pelo IETF. Representava os requisitos do negócio num
conjunto de especificações de políticas e produzia uma forma adequada para a
definição e o povoamento do schema.
O IETF tem ou teve várias linguagens de definição de políticas em
desenvolvimento (RPSL, RPCL, SPSL, PFDL, PAX, Keynote). Espera-se que
elas venham a ser unificadas numa só especificação.
2.2.6 O schema de Políticas do IETF
O IETF definiu, através de [RFC3060], um modelo nuclear de informação para
políticas – PCIM – inicial e genérico, ao qual têm sido propostas extensões
mais específicas [RFC3460], [RFC3644]. Este modelo está alinhado com as
especificações CIM (Core Information Model) para políticas do DMTF
[DMTF]. CIM é um modelo orientado a objectos que implementa a abstracção
e o modelo de informação necessários para permitir a gestão das entidades
(sistemas e redes) a níveis acima da instrumentação, como mostra a figura 2.1.
10
PBN – P OLICY-B ASED NETWORKING
O DMTF, via de regra, faz a modelagem da informação independentemente da
implementação subjacente, enquanto que o IETF faz a definição de protocolos,
schema e Application Programming Interfaces (API). A excepção para o DMTF
é a iniciativa DEN (Directory Enabled Network), que faz o mapeamento dos
conceitos CIM (sistemas, serviços, políticas) para um directório LDAP
integrado na infra-estrutura de gestão (ver figura 2.1); e para o IETF as
excepções são os modelos de informação para políticas, que entretanto tendem
a servir de base para outros RFC com os respectivos modelos de dados e
schemas LDAP.
Negócio
CIM
Serviços
DEN
Rede e Sistemas
Componentes e Elementos
Figura 2.1: Abstracções do Modelo CIM/DEN
É este o caso do modelo de informação para políticas, que deu origem a um
modelo de dados destinado a prover a sintaxe LDAP de duas hierarquias de
classes de objectos [RFC3703]:
•
Classes estruturais, que representam a informação de políticas. Para
estas classes, o mapeamento do modelo de informação para LDAP é
directo: classes para classes, propriedades para atributos.
•
Classes de relacionamento, que indicam como as instâncias das classes
estruturais estão relacionadas. Aqui, o mapeamento é feito de três
formas: classes LDAP auxiliares, para atributos que representam
referências a distinguished names (DN) (ver secção 2.5.2) e para
relações entre superior e subordinado na árvore de informação de
directório (DIT).
A representação das políticas de gestão da Qualidade de Serviço
definida pelo IETF e conhecida por QPIM [RFC3644], ainda não
schema oficial associado. É um modelo de informação que contém um
de abstracções para aplicação da QdS em Serviços Integrados e em
Diferenciados através de políticas.
na rede,
tem um
conjunto
Serviços
O QPIM utiliza regras para definir políticas, com base no modelo de
informação para políticas (PCIMex [RFC3460]). As políticas e sua respectiva
informação são organizadas hierarquicamente, e não há necessidade de serem
especificados todos os detalhes da implementação. A atribuição das políticas
aos diversos elementos de rede é feita através dos seus papéis (roles)
11
individuais. A utilização de roles é um mecanismo eficiente e simples para
aumentar o nível de abstracção e tornar as definições mais compactas. Vários
dispositivos podem ter o mesmo role, se desejado (por exemplo, o conjunto dos
encaminhadores de fronteira, o conjunto dos encaminhadores interiores).
Políticas do
Negócio
Topologia
Metodologia
QdS
Modelos
QPIM/PCIM
Capacidades
e role do ER
Configuração
do ER
Figura 2.2: Fluxo de Informação na Definição da QdS
A figura 2.2 mostra de maneira simplificada o fluxo de informação para
definição da Qualidade de Serviço num domínio de políticas. O processo é
dependente da topologia da rede e dos seus dispositivos, das regras e requisitos
do negócio e dos serviços, e do tipo particular de metodologia QdS utilizada,
DiffServ ou outra.
Sendo o modelo DiffServ a arquitectura de QdS escolhida, a topologia deve
incluir as funções (roles) relevantes dos dispositivos: “fronteira” e “interior”,
“saída” e “entrada” ou termos equivalentes.
As regras do negócio podem ter impacto directo na definição das políticas. Por
exemplo, se é essencial para o negócio haver chamadas de voz ou
teleconferências sobre redes IP, o tráfego correspondente deve ser diferenciado
para baixo atraso, baixa variação do atraso e baixa perda. O modelo QPIM é
utilizado como ajuda para o mapeamento de regras do negócio numa forma
adequada para definir os requisitos do condicionamento de tráfego na rede.
2.3 Serviços Diferenciados
2.3.1 Introdução
Serviços Diferenciados (DiffServ) e Serviços Integrados (IntServ) são duas
arquitecturas definidas pelo IETF para a provisão de qualidade de serviço
(QdS) em domínios IP. Uma das principais distinções entre elas é que os
Serviços Integrados utilizam mecanismos de sinalização para garantir o
cumprimento de um acordo de QdS fim a fim, entre domínios, enquanto que os
12
S ERVIÇOS D IFERENCIADOS
Serviços Diferenciados não utilizam sinalização nem armazenamento de estado
dos fluxos e especificam o comportamento dentro de um domínio individual.
O IETF define um Domínio Diffserv como um conjunto contíguo de
encaminhadores a operar com um as mesmas políticas e definições de
comportamentos [RFC2475]. Propõe, através da arquitectura dos Serviços
Diferenciados (DiffServ), que a QdS pode ser realizada num domínio com a
aplicação de regras de agregação do tráfego pelos encaminhadores de fronteira,
de acordo com um contrato que especifica os perfis do tráfego.
Este tipo de classificação é designada como Behavior Aggregate (BA). Cada
agregado fica ligado a um tratamento específico de transporte pelos
encaminhadores interiores, através da marcação do campo DSCP
(Differentiated Services Codepoint) no cabeçalho IP. Estes comportamentos
específicos são designados de Per-Hop Behavior ou PHB (em oposição a PHD
ou Per-Domain Behavior) na arquitectura dos serviços diferenciados.
O maior mérito do DiffServ encontra-se no comportamento dos
encaminhadores de fronteira, onde o tráfego passa obrigatoriamente, e é
medido e agregado. Se necessário, o tráfego também pode ser condicionado
neste ponto para atender às restrições de largura de banda. Uma vez dentro da
rede, o tráfego fica sujeito aos comportamentos de encaminhamento dos nós
interiores baseados no DSCP. Se um conjunto básico de classes de serviço
estiver configurado para toda a rede, atribuições de curto prazo de QdS para
situações específicas podem ser implementadas pela alteração da configuração
dos encaminhadores de fronteira somente, não sendo necessário reconfigurar os
encaminhadores interiores.
O modelo DiffServ adapta-se bem a redes de qualquer dimensão e número de
utilizadores, pelas razões expostas acima (não orientado a sinalização e
configuração nas fronteiras). Adapta-se também ao modelo de negócios e
serviços em pirâmide mostrado na figura 2.1, porque permite o mapeamento
dos acordos de níveis de serviço (SLA), ou, mais especificamente, dos
parâmetros das suas especificações (TCS – Traffic Conditioning Specifications)
em classes de serviço padronizadas.
2.3.2 O Campo DS
Um encaminhador de fronteira numa rede DiffServ é configurado com regras
para verificar/marcar o campo DS dos pacotes. Este campo, na versão 4 do
protocolo IP, substitui o antigo byte ToS (Type of Service) no cabeçalho,
enquanto que na versão 6 substitui o octeto Traffic Class.
Os seis bits menos significativos do campo DS são o DSCP (Differentiated
Services CodePoint) [RFC2474], enquanto que os dois bits mais significativos
foram redefinidos como bits ECN (Explicit Congestion Notification)
[RFC3168] (ver figura 2.3).
13
Antigo byte ToS
DS5
DS4
DS3
DS2
DS1
DS0
ECN
ECN
DSCP
Figura 2.3: Os Bits DiffServ em IPv4
Caso os bits DS0, DS1 e DS2 estejam a zero, o valor do DSCP é mapeado para
a Precedência IP tradicional, como mostra a tabela 2.1. Os bits que se mapeiam
para estes oito valores são denominados Class Selector Code Points (CSCP),
embora seja normal a abreviação para CS.
Precedência
Routine
Priority
Immediate
Flash
Flash override
CRITIC/ECP
Internetwork control
Network control
Precedência
IP (decimal)
0
1
2
3
4
5
6
7
Precedência
IP (bits)
000
001
010
011
100
101
110
111
DSCP
(decimal)
0
8
16
24
32
40
48
56
DSCP
(bits)
000000
001000
010000
011000
100000
101000
110000
111000
Tabela 2.1: Prioridade IP
O IETF definiu, em adição aos oito Class Selectors, 13 valores adicionais para
o DSCP – doze Assured Forwarding (AF) e um Expedited Forwarding (EF)
[RFC2597], [RFC2598] como mostrado na tabela 2.2, que são as classes a
mapear para os PHB. Nesta tabela, estão também indicados os valores ToS
correspondentes para o caso em que os bits ECN estejam a zero, porque na
implementação alguns parâmetros utilizam os oito bits, aplicando ou não uma
máscara (0x3) sobre os últimos dois bits.
Nos valores AFxy, x indica o número da classe (quatro no total) e y é a
precedência de descarte (três para cada classe). As classes AF são destinadas ao
tráfego com exigência de baixa perda de pacotes dentro de uma certa
velocidade, mas que não necessita de garantias de atraso.
A classe EF define um comportamento com baixo retardo, baixa variação no
atraso e pouca perda de pacotes. Só há uma classe EF porque não faria sentido
ter mais que uma classe com estas exigências de serviço – competiriam entre si
pelos mesmos recursos.
14
Aparentemente, cada classe da tabela 2.2 pode ser directamente associada a um
PHB. Entretanto, o IETF esclarece que as classes AF não são PHB individuais,
e sim um tipo de grupo de PHB. Cada uma delas (AF1 a AF4) é uma
instanciação deste tipo de grupo [RFC3260].
Nome
Default (BE)
AF11
AF12
AF13
AF21
AF22
AF23
AF31
AF32
AF33
AF41
AF42
AF43
EF
DSCP
(decimal)
0
10
12
14
18
20
22
26
28
30
34
36
38
46
DSCP
(hexa)
0x00
0x0a
0x0c
0x0e
0x12
0x14
0x16
0x1a
0x1c
0x1e
0x22
0x24
0x26
0x2e
DSCP
(bits)
000000
001010
001100
001110
010010
010100
010110
011010
011100
011110
100010
100100
100110
101110
ToS
(decimal)
0
40
48
56
72
80
88
104
112
120
136
144
152
184
ToS
(hexa)
0x00
0x28
0x30
0x38
0x48
0x50
0x58
0x68
0x70
0x78
0x88
0x90
0x98
0xb8
Tabela 2.2: Valores DSCP das Classes DiffServ
2.3.3 Arquitectura DiffServ
A arquitectura do modelo de Serviços Diferenciados baseia-se nos conceitos de
Domínio e Região DiffServ [RFC2475].
Um Domínio DiffServ é definido como um conjunto contíguo de
encaminhadores com as mesmas políticas e definições de comportamento PHB.
Uma Região DiffServ é um conjunto contíguo de domínios DiffServ onde os
serviços diferenciados podem ser oferecidos de maneira global relativamente a
estes domínios.
Se numa região DiffServ todos os domínios adoptarem as mesmas políticas de
aprovisionamento de recursos e suportarem PHB compatíveis (a nível do
mapeamento do campo DSCP para as classes DiffServ e das características de
cada classe), fica eliminada a necessidade de negociação (SLA, TCS) entre
eles. Caso contrário, será necessário estabelecer os condicionamentos
apropriados nas fronteiras internas da região.
15
Num domínio DiffServ, são distinguidos os encaminhadores de fronteira dos
interiores, como mostrado na figura 2.4. Um encaminhador de fronteira de um
domínio DiffServ liga-se a um encaminhador de outro domínio, que pode ou
não ser um domínio DiffServ. Domínios DiffServ contíguos formam regiões
DiffServ. O facto de uma região DiffServ ter potencialmente mais que uma
ligação a outras redes, como mostrado na figura, requer um planeamento
cuidadoso para um conjunto consistente de políticas comuns para os pacotes
que entram e saem da região.
Nó
Interior
Domínio
DiffServ
Nó de
Fronteira
Nó
Interior
Nó
Interior
Nó de
Fronteira
Região
DiffServ
Nó de
Fronteira
Nó
Interior
Nó
Interior
Domínio
DiffServ
Ligação
a outras
redes
Nó
Interior
Nó de
Fronteira
Ligação
a outras
redes
Figura 2.4: Arquitectura do Modelo de Serviços Diferenciados
Um encaminhador de fronteira é geralmente utilizado como “encaminhador de
saída e de entrada” (egress/ingress router) para diferentes direcções do tráfego.
Funcionalmente, o modelo sugere tratamentos diferentes para os tráfegos de
entrada e de saída, fazendo distinção entre nó de entrada (ingress node) e nó de
saída (egress node). O tráfego sai do domínio DiffServ pelo egress node e entra
no domínio DiffServ pelo ingress node.
O modelo DiffServ prevê [RFC2475] que os encaminhadores de fronteira façam
a classificação e possivelmente o condicionamento do tráfego, e sua associação
com diferentes behavior aggregates, enquanto que os encaminhadores
interiores fazem o encaminhamento de acordo com o PHB associado ao
codepoint DiffServ. Podem, excepcionalmente, trabalhar como encaminhadores
de fronteira e fazer funções limitadas de condicionamento, tal como a
remarcação do campo DSCP. Entretanto, isto poderia levar a comportamentos
inconsistentes no domínio DiffServ, sendo recomendado que apenas façam o
shaping (retardo selectivo) definido pelos PHB.
16
2.3.4 Sobre Algumas Disciplinas de Filas e Termos Associados
Tokens e Buckets: para controlar a saída de pacotes de uma fila, pode-se
calcular a utilização e tempo de permanência por unidade de informação
(pacotes ou bytes). Ao invés disto, um método utilizado largamente no controlo
do tráfego é gerar tokens (neste caso o termo poderia ser traduzido por senhas)
a uma taxa desejada, e somente retirar pacotes da fila se uma token estiver
disponível (mecanismo de atraso selectivo ou shaping). Tokens podem ser
emitidas mesmo se não houver tráfego, e encher um bucket (balde) até a sua
capacidade. Neste caso, todas as tokens disponíveis num bucket podem ser
utilizadas sem restrições de tempo. Buckets são considerados um conceito
chave para o suporte a tráfego caracterizado por rajadas de dados (bursts),
como é o caso do HTTP.
CBQ é a disciplina mais complexa disponível. É baseada num algoritmo pouco
preciso e com pouca empatia com a maneira de funcionar do Linux [Hubert].
Particularmente, tem sido criticada a forma de fazer shaping da CBQ baseada
em medições imprecisas da disponibilidade de uma conexão, e o excessivo
número de parâmetros a configurar.
HTB (Hierarquical Token Bucket) é uma queuing discipline – disciplina de
filas – escrita por Martin Devera (que elabora alguns comentários no site
http://luxik.cdi.cz/~devik/qos/htb/old/htbmeas1.htm) e foi recentemente
implementada no kernel Linux. Tem substituído a disciplina tradicional CBQ
em implementações [Hubert]. Considera-se que HTB tem um design mais claro,
com melhor suporte e comandos mais simples. A sua utilização ao invés de
CBQ dá origem a melhores resultados a nível de comportamento geral (mesmas
referências).
CBQ e HTB são disciplinas de filas hierárquicas com partilha de conexão (linksharing) entre classes, garantindo uma percentagem da largura de banda para
cada classe mesmo durante congestão do tráfego e dividindo entre todas a
largura de banda não utilizada por qualquer delas (“em excesso”) [Floyd95b].
Uma disciplina hierárquica pode condicionar a divisão da largura de banda
entre organizações, famílias de protocolos, classes de serviços e conexões
individuais dentro de uma classe de serviços (nem todas estas estruturas
necessitam de estar sempre presentes).
SFQ (Stochastic Fairness Queuing): baseia-se na família de algoritmos FQ,
que classifica e distribui pacotes em trânsito, associando um pacote a uma de
várias “portas”. A porta é uma entrada de fila, servida em conjunto com outras
(todas filas FIFO), um pacote por vez numa ordem circular (round-robin).
Classifica os fluxos com base em endereços, portas e protocolos. Emprega um
algoritmo de hashing que divide o tráfego por um número limitado de filas.
Alterações frequentes neste algoritmo de hashing evitam colisões de mais de
alguns segundos entre quaisquer duas sessões. Os seus parâmetros incluem a
indicação do número de segundos para reconfigurar o hashing, a quantidade
máxima de bytes que podem sair da fila para cada fluxo de dados, por vez, e o
número total de pacotes que podem ser enviados para as filas antes de iniciar-se
o descarte.
17
ESFQ (Extended SFQ): acrescrenta os parâmetros depth, limit, e opções para a
tabela de hashing, incluindo a utilização de apenas o endereço de origem ou de
destino e o número de linhas da tabela (até um número de 14 bits).
RED (Random Early Detection): evita o problema das disciplinas acima,
baseadas em FIFO, no descarte de pacotes somente na cauda da fila (DropTail).
Isto pode ocasionar uma diferenciação indesejada no tratamento dos diversos
fluxos de pacotes, com alguns dos fluxos tendo seus pacotes consistentemente
discartados em favor de outros fluxos que enviaram mais cedo. RED procura
atender fluxos tão logo quanto seja possível, antes que a fila esteja cheia, para
indicar que está iminente uma situação de congestão. Os descartes são
distribuídos mais equitativamente entre todos os fluxos. O mecanismo de
implementação é baseado no controlo do tamanho médio das filas. Fluxos não
orientados a conexão, como o UDP, são indirectamente limitados pelo controlo
do limite máximo deste tamanho médio. São estabelecidos dois limites
(thresholds), abaixo dos quais nenhum pacote é marcado para descarte. Acima
do limite superior do tamanho médio da fila, todos os pacotes são descartados.
Na região entre os dois limites, pacotes são descartados em função de uma
probabilidade pa (função do tamanho médio da fila).
2.3.5 Classificação e Condicionamento do Tráfego
Os parâmetros dos acordos de serviço a serem honrados pelo domínio DiffServ
podem especificar, ou exigir implicitamente, a existência de regras para
classificação e remarcação dos pacotes, e também definições para perfis de
tráfego e as medidas a serem accionadas para fluxos de tráfego dentro ou fora
de perfil.
Uma política de classificação identifica os pacotes candidatos a um serviço
diferenciado através do seu condicionamento e/ou mapeamento do campo
DSCP para um ou mais behavior aggregates a que ficarão sujeitos dentro do
domínio. Classificadores de BA utilizam exclusivamente o código DSCP para
classificar pacotes, enquanto que os classificadores que analisam um ou mais
campos no cabeçalho do pacote são denominados classificadores de campo
múltiplo.
A utilização de classificadores em cascata permite uma classificação mais
detalhada em cada transição de um classificador para outro.
O condicionamento do tráfego assegura que este está de acordo com a política
de aprovisionamento de serviços do domínio. Para isto, pode realizar as
seguintes acções:
•
18
Medição: os módulos de medição medem as propriedades temporais de
um fluxo de tráfego seleccionado por um classificador, comparando-as
com o perfil configurado. Outras funções de condicionamento recebem
as informações dos módulos de medição e podem realizar acções em
resultado destas medições para cada pacote dentro ou fora de perfil.
•
Atraso Selectivo 1: para fazer com que um fluxo de tráfego esteja de
acordo com o perfil respectivo, módulos de atraso selectivo retardam
alguns ou todos os pacotes deste fluxo, aumentando implicitamente a
probabilidade de descarte destes pacotes devido à falta de espaço para os
armazenar temporariamente (buffer).
•
Policiamento: efectuado por módulos de descarte, consiste em eliminar
alguns ou todos os pacotes em um fluxo de tráfego para que este fique
de acordo com o perfil respectivo. Um módulo de atraso selectivo com o
tamanho do buffer muito pequeno ou igual a zero comporta-se como um
módulo de descarte.
•
Remarcação: os módulos de marcação configuram o campo DS de um
pacote com um codepoint particular relacionado a um behavior
aggregate específico. Quando o codepoint de um pacote é alterado,
então ocorreu a remarcação deste pacote. A alteração pode ser devida a
um comportamento excepcional de um encaminhador interior, ou, se
feita pelo encaminhador de entrada na fronteira, deve-se a ter havido
uma pré-marcação na rede de origem do pacote.
A pré-marcação de pacotes pela rede de origem tem a vantagem de diminuir o
número de regras necessárias no encaminhador de fronteira da rede de destino,
mas este continua a ter a responsabilidade de assegurar que todo o tráfego está
conforme os acordos de serviços negociados e que os pacotes pré-marcados
podem estar no grupo BA designado pelo seu DSCP.
A figura 2.5 representa os blocos funcionais que possibilitam a classificação e
o condicionamento do tráfego, e algumas opções de implementação.
Medidor
Classificador
Condic.
do
Tráfego
Gestão do
Buffer
Scheduler
(Escalonador)
Shaper/
Descartador
Figura 2.5: Módulos de Classificação e Condicionamento do Tráfego
Na secção 3.3.3 serão apresentadas e discutidas algumas possíveis opções de
implementação para estes blocos funcionais.
Os condicionadores de tráfego e classificadores de campo múltiplo devem estar
localizados nos encaminhadores de saída e de entrada de fronteira do domínio.
Também podem existir nos encaminhadores interiores.
1
O termo em inglês é shaping.
19
2.3.6 Per-Hop Behaviors
Um per-hop behavior (PHB) é o tratamento (visível externamente) que cada
encaminhador DiffServ aplica a um behavior aggregate específico (colecção de
pacotes com o mesmo código DSCP), com a atribuição de recursos necessários
e restrição do acesso aos recursos demandados por instâncias mais prioritárias
[RFC2475].
O equivalente ao PHB para todo o domínio é o PDB (Per-Domain Behavior),
que descreve o comportamento dos pacotes com um mesmo código DSCP a
atravessar um domínio DiffServ. A utilidade dos PDB é definir as
características mensuráveis que podem ser utilizadas num SLA ou SLS.
Faz parte da arquitectura DiffServ a especificação de classes de serviços
diferenciados em adição à classe tradicional das redes IP, BE (Best Effort)
[RFC3246], [RFC2597], para qualificar os agregados de tráfego.
Os PHB utilizados nesta implementação são o BE (Default), EF e grupo AF
(ver tabela 2.2). Como já foi dito, AF não é um PHB, mas sim um tipo de grupo
PHB. Cada classe AF é uma instância deste tipo de grupo.
O modelo DiffServ original foi revisto para corrigir algumas inconsistências
sobre o tratamento dado a códigos DSCP não reconhecidos [RFC3260].
Actualmente, é definido que pacotes com códigos DSCP inválidos devem ser
tratados da mesma forma que pacotes marcados para o comportamento Default,
tanto pelos encaminhadores de fronteira quanto pelos interiores.
O PHB Default é utilizado para todos os pacotes que não forem considerados
pertencentes a outro agregado. O tráfego neste agregado tem o tratamento Best
Effort (BE), e o código DSCP recomendado é o 0x00.
A utilização de uma disciplina de fila tipo RED (Random Early Detection) para
o PHB BE justifica-se porque, se houver descartes, estes aplicam-se com uma
aproximação probabilística a pacotes em posições aleatórias na fila (não só da
cauda e não só da cabeça) [Floyd93], de acordo com a filosofia do tratamento
Best Effort.
O PHB EF (Expedited Forwarding) é utilizado para atender a serviços com
requisitos semelhantes aos da utilização de um canal virtual privativo. Suas
propriedades típicas incluem baixo atraso, baixa variação do atraso (jitter),
baixa perda de pacotes e largura de banda garantida [RFC3246]. O DSCP
recomendado é o 0x2e. Este PHB foi revisto em relação ao RFC original, para
obter maior formalismo matemático em benefício de uma definição mais
rigorosa do comportamento associado.
O tráfego EF que não ultrapasse o ritmo limite especificado deve obter todas as
características citadas, o que pode requerer policiamento ou atraso selectivo
nos encaminhadores de fronteira. É recomendado que as implementações
tenham alguma tolerância relativamente às rajadas (quantidade de dados que
podem ser enviados antes que outra classe seja atendida) para não inviabilizar a
agregação de fluxos.
O tráfego EF que ultrapasse o ritmo máximo definido é descartado. A utilização
de uma disciplina de fila tipo FIFO (First In, First Out) é adequada para este
20
XML
caso porque os descartes ocorrem no fim da fila, obedecendo à filosofia deste
serviço particular.
O grupo PHB AF (Assured Forwarding) contém quatro classes, cada uma com
três níveis de precedência de descarte dos pacotes [RFC2597]. O principal
objectivo deste grupo é fornecer um conjunto de serviços em que há baixa
probabilidade de descarte dos pacotes se o tráfego obedecer aos parâmetros
predefinidos.
Dentro de cada classe AF, os pacotes têm uma de três possíveis precedências de
descarte. Em caso de congestionamento, os pacotes com um valor maior de
precedência de descarte são eliminados em primeiro lugar.
A implementação prática do grupo AF leva a que cada precedência de descarte
esteja geralmente associada a uma fila virtual RED, a mais adequada para
atender aos requisitos do IETF. Na implementação, isto é conseguido com a
atribuição da disciplina GRED (Generalized RED) à classe principal (AF1,
AF2, AF3, AF4). Este tipo de fila permite definir várias filas virtuais, cada uma
fazendo a marcação aleatória nos seus pacotes para descarte típica do modelo
RED. Um pacote é direccionado dentro de uma classe AF para uma ou outra
fila virtual (com a respectiva precedência de descarte) através do seu DSCP (o
procedimento para obter este valor num encaminhador Linux é demonstrado no
capítulo 4).
2.4 XML
2.4.1 Introdução
Uma representação textual da informação de gestão pode não ser suficiente ou
adequada para ser esta informação ser transferida em ambientes heterogéneos
[Hegering]. Isto leva à necessidade de uma linguagem consistente para
especificar os parâmetros de gestão. No caso do framework de políticas do
IETF, uma vez que a linguagem não faz parte desta especificação, fica ao
critério de cada implementação particular fazer a escolha.
O XML (Extensible Markup Language) [W3CXML] é um subconjunto da
metalinguagem SGML (Standardized Markup Language) [ISO8879] e é
utilizado para representar dados estruturados em forma textual. Nestas
linguagens (que incluem o HTML), o mecanismo para delimitar a informação
estrutural e semântica dos elementos individuais são as tags de início e fim,
elas próprias delimitadas pelos caracteres “<” e “>”:
<SLA>
<SlaID>sla2907041833</SlaID>
<Classe>EF</Classe>
…
<SLA>
As tags são sensíveis a maiúsculas e minúsculas.
A utilização do formato XML requer que os intervenientes sejam capazes de
estruturar e validar correctamente a informação transferida. Para este efeito, as
21
linguagens de programação e navegadores Internet dispõem de livrarias que
permitem implementar "parsers" (verificadores) XML. Ao nível da
programação e no interesse da interoperabilidade, convém que a aplicação
possa reconhecer, validar os atributos e aplicar comportamentos específicos ao
elementos de um documento XML, e também guardar e reutilizar informação
neste formato.
2.4.2 DTD e Schema
Adicionalmente, um documento XML pode basear-se numa "gramática"
descrita em um documento acessório do tipo DTD (Document Type Definition)
ou do tipo XML Schema. Estes documentos contêm os elementos, atributos,
entidades e notações utilizados num documento XML que faça referência a
eles.
Um documento estruturado de acordo com a especificação XML [W3CXML] é
dito "bem formado". As regras mais importantes são:
•
Não devem ocorrer tags de início sem a correspondente tag de fim.
•
As tags não devem ser sobrepostas, ou seja, não se deve fechar um
elemento após a tag de fim do elemento que o contém.
<elemento 1 início>
... <elemento 2 início> ...
<elemento 1 fim> ... <elemento 2 fim>
•
Os valores dos atributos devem ser delimitados por aspas.
•
Os caracteres “<”, “>” e aspas devem ser sempre representados por
entidades definidas para o efeito.
Ao invés de
<
>
“
Usar
<
>
"
Tabela 2.3: Entidades Especiais em XML
Se, além de bem formado, o conteúdo do documento estiver de acordo com a
gramática especificada no DTD ou no schema, ele é um documento "válido". O
exemplo simples a seguir ilustra este conceito. No DTD há um elemento raiz
denominado “rede” que tem dois possíveis elementos: “subrede” e
“equipamento”:
<!DOCTYPE rede [
<!ELEMENT subrede (#PCDATA)>
<!ELEMENT equipamento (#PCDATA)>
]>
Um documento XML baseado neste DTD poderia ser escrito assim:
<?xml version="1.0" standalone="yes"?>
<!DOCTYPE rede SYSTEM=”rede.dtd”>
22
XML
<rede>
<subrede>Informática</subrede>
<subrede>Assessoria</subrede>
<child>Switch22</child>
<child>Laser43</child>
</family>
Este seria um documento XML válido. Entretanto, se forem acrescentadas tags
ao documento de acordo com o exemplo a seguir, este deixa de ser válido
enquanto o DTD correspondente não for alterado:
<rede>
Esta é a rede da empresa:
<subrede>Informática</subrede>
...
Um DTD pode ser armazenado internamente ou externamente ao documento
XML. Se for interno, deverá estar entre a declaração XML e o elemento raiz no
documento. Um DTD externo é armazenado num documento separado do XML,
tendo a vantagem de ser reutilizável por vários documentos XML.
Declarações DTD internas têm precedência sobre declarações externas, e cada
documento XML pode estar associado a exactamente um DTD através da
declaração DOCTYPE.
A utilização de um schema ao invés do DTD é uma proposição da Microsoft
recentemente adoptada pelo W3C. Acrescenta complexidade ao processo, mas
traz vantagens [W3CXML]:
•
Suportam diferentes tipos de dados e restrições, padrões e conversões
entre eles.
•
Utilizam a sintaxe XML.
•
Tornam os dados mais consistentes, ao definí-los exactamente (por
exemplo, os diferentes formatos de dados tipo data).
•
São extensíveis e reutilizáveis.
Optámos por aderir ao DTD neste trabalho, mas pensamos que seria vantajosa a
utilização do schema para a integridade da informação.
2.4.3 Estrutura do Documento XML
Um documento XML deve iniciar por uma declaração XML, que define a versão
e a codificações utilizadas no documento:
<?xml version=”1.0” encoding=”ISSO-8859-1”?>
A seguir à declaração XML, vem a indicação do elemento raiz do documento,
ou a declaração DOCTYPE para indicar o DTD do documento.
<!DOCTYPE raiz SYSTEM ”politicas.dtd”>
O elemento raiz deve ocorrer exactamente uma vez num documento XML,
sendo definido pelas respectivas tags de início e fim:
23
<elemento_raiz>
…
</elemento_raiz>
Os principais blocos funcionais do XML são os elementos, que representam
logicamente os objectos. Os elementos podem conter texto ou uma hierarquia
de outros elementos.
A qualificação dos elementos é feita através dos seus atributos ou dos seus
elementos filhos. Geralmente, é indiferente do ponto de vista semântico utilizar
atributos ou elementos para implementar as propriedades de um objecto, mas os
elementos são mais adequados do ponto de vista funcional [W3CXML].
Os tipos mais comuns dos elementos são EMPTY ou carácter (PCDATA ou
CDATA). Outros tipos incluem ANY e de conteúdo misto.
O elemento tipo ANY pode conter quaisquer dados XML bem formados, zero ou
mais elementos filhos de qualquer tipo declarado, ou dados tipo carácter. Como
isto é contrário à filosofia de consistência do XML, a melhor opção é não
utilizar este tipo de elemento.
Elementos tipo EMPTY não contêm dados nem elementos filhos; são apenas
repositórios de atributos. A palavra-chave EMPTY pode ser omitida na sua
declaração. Elementos EMPTY podem ser utilizados no DTD para definir os
parâmetros de configuração que utilizam pares nome-valor:
<!ELEMENT TCS EMPTY>
<!ATTLIST TCS
SLAid CDATA #REQUIRED
TCSid CDATA #REQUIRED
Src_IP CDATA #REQUIRED
…>
Neste exemplo, o elemento TCS (Traffic Conditioning Specification) detém os
atributos SLAid, TCSid, Src_IP (e possivelmente outros). Um
documento XML válido baseado neste DTD poderia incluir o seguinte conjunto
de declarações:
<TCS SLAid=”sla1809041200”
TCSid=”bar3009042030”
Src_IP=”150.32.125.00/24”
…
>
</TCS>
Os atributos devem estar sempre delimitados por aspas.
Os elementos tipo carácter são tipos de dados fundamentais do XML, podendo
ser validados ou ignorados pelo parser (PCDATA – parsed character data ou
CDATA – character data, respectivamente).
Elementos de conteúdo misto podem ser criados com um elemento tipo carácter
e elementos filhos. Se o elemento carácter existir, o tipo de elemento é misto
ou carácter. Se não existir o elemento carácter, o tipo de elemento é somente
elemento.
24
XML
A declaração dos elementos filhos pode utilizar listas de sequências ou listas de
escolha. Em qualquer caso, operadores cardinais podem ser utilizados para
indicar quantos filhos podem aparecer numa declaração:
<!ELEMENT E1 (E2*, E3, (E4|E5)?, E6+)>
Neste exemplo, o elemento filho E2 é opcional e pode ocorrer múltiplas vezes,
o elemento E6 é obrigatório e pode ocorrer múltiplas vezes, os elementos E4 e
E5 são opcionais mas só um deles pode ocorrer e só uma vez e o elemento E3
deve ocorrer exactamente uma vez.
2.4.4 XML e Java
A representação que o XML faz da informação estruturada como numa base de
dados facilita a sua conversão para árvores de objectos em linguagens de
programação. A recomendação DOM (Document Object Model) Nível 2 do
W3C [W3CDOM] descreve as interfaces necessárias para representar qualquer
documento XML bem formado, permitindo a sua manipulação como objectos.
Uma forma de utilizar XML em Java é utilizar a Simple API for XML (SAX)
[SAX2]. Um parser SAX é uma classe Java que implementa a interface
org.xml.sax.Parser, a qual permite navegar pela árvore do documento
XML e aplicar os métodos definidos pelo programador em outra classe, na
interface DocumentHandler. O objecto Parser lê o código XML e usa os
métodos de DocumentHandler quando, por exemplo, encontra uma certa
tag.
O pacote org.xml.sax implementa a interface mostrada a seguir na sua
classe HandlerBase:
public interface DocumentHandler {
public abstract void setDocumentLocator
(Locator locator);
public abstract void startDocument ()
throws SAXException;
public abstract void endDocument ()
public abstract void startElement
(String name, AttributeList atts)
public abstract void endElement
(String name)
public abstract void characters
(char ch[], int start, int length)
public abstract void ignorableWhitespace
(char ch[], int start, int length)
25
public abstract void processingInstruction
(String target, String data)
}
O programador deve criar uma classe filha de HandlerBase para sobrepor os
métodos que deseja utilizar. Por exemplo, queremos contar os TCS de todos os
SLA descritos num documento XML:
import org.xml.sax.*;
public class ContaTCS extends HandlerBase {
protected int numTcs = 0;
public int ElementCounter() { }
public void startElement
(String name, AttributeList atts)
throws SAXException {
if (name = “tcs”) {
numTcs ++;
…
}
}
public void endDocument() {
System.out.println("Contém " + numTcs +
" TCS.");
}
};
2.5 LDAP
2.5.1 Introdução
Um directório é uma base de dados local ou distribuída, optimizada para
leitura, navegação e pesquisas [OpenLDAP]. Um serviço global deve definir
um espaço de nomes (namespace) para que a visão dos dados seja independente
do local de onde são vistos.
Descrito pelo IETF nos RFC 2251-2256, 2829-2830, o LDAP (Lightweight
Directory Access Protocol) era inicialmente uma extensão do protocolo X.500
para utilização num ambiente IP. Como o nome sugere, é um protocolo que
requer poucos recursos para acesso a serviços de directório sobre protocolos
orientados a conexão.
O directório LDAP permite agrupar em um único local informações dispersas
de acesso, autenticação e autorização. Sua estrutura lógica baseia-se no
conceito de “entrada” (entry) que contém informação sobre algum objecto (por
exemplo, um SLA ou um BAR). As entradas têm atributos com sintaxe, tipo e
valor(es).
26
LDAP
2.5.2 Estrutura da Informação LDAP
As entradas LDAP organizam-se numa estrutura de árvore, denominada
Diretory Information Tree (DIT). Cada objecto da árvore é globalmente
identificado de forma única através do seu Distinguished Name (dn):
dn:
tcs=TCS1,
cn=tcs,
cn=Acordos de Servico,
ou=CIIST,
o=Instituto Superior Tecnico, c=pt
A informação acima está no formato LDAP Data Interchange Format (LDIF).
Este formato representa as entradas do directório LDAP como texto, de modo a
facilitar a sua manipulação. Os valores para os atributos podem ser UTF-8 ou
dados codificados base 64 (dados binários), ou um URL pode ser fornecido
para a localização do valor real do atributo.
O par atributo-valor tcs=TCS1 é o Relative Distinguished Name (RDN) desta
entrada (relativamente às entradas do mesmo nível). O LDAP pode utilizar
qualquer atributo para criar um RDN, e cabe ao administrador do sistema a
responsabilidade de evitar duplicados. A figura 2.6 mostra uma vista gráfica da
informação exemplificada.
c=pt
c=es
o=Instituto Superior Tecnico
ou=CIIST
cn=Acordos de Servico
cn=
classeQdS
classe=Diamante
slaId=SLA
1
cn=sla
slaId=SL
cn=tcs
tcsId=TCS
1
Figura 2.6: Uma Árvore de Informação de Directório (DIT)
O LDAP permite controlar quais atributos são requeridos e permitidos em uma
entrada através de um atributo especial denominado objectclass. Os
valores deste atributo determinam as regras do schema a serem obedecidas:
objectclass (5.5.5.1 NAME ‘ServiceLevelAgreement’
SUP
top
STRUCTURAL
MUST
(dlmDescription $ slaId $ pcimTPCTime $
slaUser $ classe $ ritmo $ prioridades $
27
srcDst $ pcimRuleEnabled))
O valor 5.5.5.1 é o OID (Object Identifier) desta entrada. Os OID são
cadeias numéricas atribuídas hierarquicamente, o que implica que somente a
autoridade para 5.5.5 pode dizer o que significa 5.5.5.1. A definição
formal dos OID é de responsabilidade da ITU (International
Telecommunications Union) através da sua recomendação X.680 (ASN.1)
[X680]. Vários organismos internacionais registam novos OID (ETSI, IANA,
ANSI, BSI). Esta forma particular e largamente adoptada de representar os OID
foi definida pelo IETF [RFC2252]. A árvore de OID 1.3.6.1.4.1 destina-se
a permitir o registo de entidades privadas, sendo útil, por exemplo, para definir
um conjunto MIB privado.
A definição de ObjectClassDescription feita pelo IETF está resumida na tabela
2.4. Em geral, cada entrada faz referência a uma classe abstracta, pelo menos
um objectclass estrutural e zero ou mais classes auxiliares.
Identificador
NAME
DESC
OBSOLETE
SUP
ABSTRACT
STRUCTURAL
AUXILIARY
MUST
MAY
Descrição
Identificador da Objectclass
Descrição
true se obsoleto, false ou ausente se não obsoleto
Objectclass superior na hierarquia
Tipo de classe que deve conter outras classes
Classe estrutural derivada de uma classe abstracta
Classe auxiliar derivada de uma classe estrutural
Conjunto de atributos obrigatórios
Conjunto de atributos opcionais
Tabela 2.4: ObjectClassDescription (RFC 2252)
2.5.3 Acesso, Autenticação e Autorização
O serviço de directório LDAP é baseado no modelo cliente-servidor. A árvore
do directório pode estar distribuída por diversos servidores. O acesso dos
clientes é feito directamente ao servidor que armazena os elementos de dados
desejados, ou através de um serviço de referência (referral) que redirecciona a
solicitação do cliente para outro servidor caso a solicitação não se refira ao
espaço de nomes local (ver figura 2.7).
3. Nova solicitação
Servidor
Superior
1. Solicitação
Cliente
Servidor
2. Referência
Figura 2.7: Funcionamento do referral
28
LDAP
O acesso aos serviços LDAP está condicionado à autenticação do utilizador.
Este mecanismo informa o servidor LDAP quem está a aceder aos dados e com
que privilégios. Há três tipos de autenticação: anónima, simples e SASL
(Simple Authentication and Security Layer). SASL inclui autenticação e
encriptação da sessão entre o servidor e o cliente [RFC2222, podendo ser
utilizado com Kerberos [RFC1510], TLS (Transport Layer Security)
[RFC2246] ou outro protocolo de segurança.
Se a autenticação do cliente tiver sucesso, cada vez que o servidor receber uma
solicitação vai verificar os privilégios do cliente para aquela acção em
particular. Este processo é a autorização e baseia-se em listas de controlo de
acesso (ACL). Cada entrada numa ACL é um atributo que pode ser associado a
qualquer entrada no directório.
2.5.4 Operações LDAP
A versão 3 do LDAP suporta as seguintes operações de manipulação dos dados:
Bind, Unbind, Search, Modify, Add, Delete, Modify DN, Compare, Abandon,
Extended [RFC2251]. A tabela 2.5 faz a descrição básica destes comandos.
Comando LDAP
bind
unbind
Search
Modify
Add
Delete
Modify DN
Abandon
Extended
Descrição
Inicia uma sessão com o servidor LDAP
Encerra a sessão com o servidor LDAP
Pesquisa uma entrada no directório
Modifica uma entrada no directório
Acrescenta uma entrada ao directório
Elimina uma entrada no directório
Modifica o distinguished name de uma entrada
Cancela uma operação em progresso
Permite definir novas operações
Tabela 2.5: Comandos LDAP
Os comandos LDAP podem ser agrupados funcionalmente da seguinte forma:
•
As operações Add, Delete e Modify alteram as entradas do directório.
•
As operações Bind e Unbind iniciam ou terminam o processo de
autenticação entre o cliente e o servidor LDAP relativamente a
directórios específicos.
•
A operação Search localiza elementos ou serviços específicos na árvore.
•
A operação Compare permite o teste de parâmetros das aplicações
contra a informação armazenada no directório LDAP.
•
A operação Modify DN permite alterar o nome de uma entrada.
•
A operação Abandon cancela uma operação em desenvolvimento.
•
A operação Extended permite que os clientes façam pedidos e recebam
respostas não padrão, mas com sintaxe e semântica personalizadas.
29
Assim, podem ser definidas novas operações para serviços não
disponíveis. Um exemplo desta funcionalidade são as operações e
resultados assinados digitalmente.
2.5.5 LDAP e Java
Está proposta como draft no IETF uma livraria Java de classes LDAP, definida
como “simples, mas poderosa”, que permite o acesso aos serviços de directório
LDAP versão 3 através de mecanismos síncronos e assíncronos que atendem a
todas as possibilidades de solicitações e respostas possíveis do protocolo
[JLDAP].
As classes LDAP deste draft são limitadas às funcionalidades definidas nos
RFC e drafts do IETF, oferecendo compatibilidade binária com outras
implementações da API LDAP em Java.
A API propriamente dita está disponível em fonte e como livraria java (.jar).
No primeiro caso, encontra-se em http://www.openldap.org/jldap e, para se
fazer o build, são necessários o JSDK (Java Software Development Kit), as
classes JSSE (que permitem construir conexões SSL) e a ferramenta Ant. Os
dois primeiros requisitos estão disponíveis no site http://java.sun.com, e o outro
em http://jakarta.apache.org. As livrarias compiladas estão disponíveis em
http://developer.novell.com/ndk. O site OpenLDAP e o site da Novell oferecem
vários exemplos de programas em Java que utilizam a livraria LDAP.
A classe principal da livraria chama-se LDAPConnection, e disponibiliza
métodos para estabelecer uma conexão anónima ou autenticada ao servidor
LDAP. Também tem métodos para pesquisar, modificar, comparar e eliminar
entradas no directório, com parâmetros para número de entradas retornadas,
limites de timeout e outros.
Uma pesquisa síncrona resulta num objecto LDAPSearchResults, que dá
acesso às entradas encontradas. Cada entrada é representada por um objecto
LDAPEntry e os seus atributos estão em objectos LDAPAttribute como
arrays de bytes ou como cadeias de caracteres.
A utilização da API por uma aplicação pode ser feita em quatro passos:
1. Iniciar uma sessão com um servidor LDAP através da construção de
uma conexão: método LDAPConnection.connect().
2. Enviar as credenciais da sessão para fazer a autenticação com o servidor
LDAP: método LDAPConnection.bind().
3. Realizar as operações desejadas e obter os resultados.
4. Encerrar a conexão: método LDAPConnection.disconnect().
Quaisquer erros resultam numa LDAPException, a indicar o código do erro e
a informação específica de contexto disponível.
30
PIB
2.6 PIB
2.6.1 Introdução
Uma Policy Information Base (PIB) define classes de aprovisionamento que
permitem mapear os requisitos de serviço para as capacidades e utilização dos
dispositivos, funcionando como interface entre as políticas de alto nível e o
agente de políticas nos elementos de rede. A estrutura de especificação dos PIB
é descrita pela SPPI (Structure of Policy Provisioning Information), permitindo
que a informação de políticas seja transportada através da rede até ao agente
responsável pela configuração de um dispositivo específico.
O conjunto básico de classes de aprovisionamento de políticas (PRC –
Provisioning Classes) definidas pelo IETF chama-se Framework Policy
Information Base [RFC3318] e inclui também as convenções textuais
(definição de tipos de dados) comuns a todos os clientes de aprovisionamento
de políticas.
O IETF definiu ainda um módulo PIB para dispositivos que implementem a
arquitectura DiffServ [RFC3317]. As classes de aprovisionamento definidas
neste módulo permitem o controlo pelas políticas dos recursos que
implementam os Serviços Diferenciados.
2.6.2 Conceitos Gerais
De forma a ser possível obter um nível de abstracção na definição de políticas
destinadas a equipamentos e interfaces com funcionalidades distintas, os PIB
apoiam-se fundamentalmente no conceito de role, que identifica a função ou
papel desempenhado pelo dispositivo ou interface. Assim, ao invés de
especificar políticas explicitamente para cada interface de cada dispositivo da
rede, a especificação é feita com base na funcionalidade da interface.
No contexto dos PIB, um role é uma cadeia de caracteres associada com uma
interface. Uma interface pode ter mais que um role em simultâneo. O atributo
RoleCombination, das classes de aprovisionamento, é um conjunto
ordenado de roles que tem de ser igual ao conjunto de roles de uma interface
para que sejam aplicadas as instâncias da respectiva classe de
aprovisionamento.
A lista de interfaces e os seus respectivos roles são enviados pelo agente de
configuração de políticas num elemento de rede ao servidor de
aprovisionamento, quando da inicialização do elemento de rede. Em resposta, o
servidor de aprovisionamento pode enviar políticas para serem aplicadas pelo
agente do elemento de rede.
A qualquer momento futuro, o servidor de aprovisionamento pode enviar
actualizações das políticas para uma interface ou para um agregado de
interfaces, devido a uma solicitação específica do agente (por mudança do role
das interfaces) ou em função de uma alteração nas próprias políticas.
No modelo de aprovisionamento, a informação de políticas é uma colecção de
classes de aprovisionamento (PRC) e instâncias de aprovisionamento (PRI) que
31
residem em uma base de dados virtual, a PIB. Um módulo PIB contém
colecções de classes de aprovisionamento relacionadas [RFC3084].
As classes de aprovisionamento PRC, quando instanciadas, são denominadas
PRI (Provisioning Instance).
Também é usual nas definições do IETF a utilização dos termos PDP (Policy
Decision Point) e PEP (Policy Enforcement Point) para fazer referência
respectivamente ao servidor de aprovisionamento e ao agente (um cliente do
PDP) que vai receber as políticas. Estas designações serão detalhadas na secção
2.7, onde abordamos o COPS (Common Open Police Service) [RFC2748] e o
COPS-PR (COPS Usage for Policy Provisioning) [RFC3084].
2.6.3 Relação com MIB
O formato em que os módulos MIB (Management Information Base) do SNMP
são escritos baseia-se na estrutura definida pela SMI (Structure of Management
Information). A SPPI (Structure of Policy Provisioning Information) é um
subconjunto adaptado da SMI, utilizado para escrever módulos PIB [RFC3159].
Por sua vez, a SMI utiliza um subconjunto adaptado da linguagem de definição
de dados ASN.1 [X680].
Uma das principais diferenças entre SMI e SPPI é de que a SPPI não utiliza o
termo “objecto”, mas sim classe de aprovisionamento (PRC) para definir
tabelas e registos, e instância de aprovisionamento (PRI) para uma instanciação
de uma definição de registo. Além disso, a SPPI utiliza o termo “atributo”
como referência aos campos (columnar object) da definição de uma tabela, não
suportando o equivalente dos objectos escalares da SMI.
A SPPI utiliza as seguintes estruturas da SMI:
•
MODULE-IDENTITY: utilizada para definir a semântica de um módulo
PIB.
•
OBJECT-TYPE: utilizada para definir a sintaxe e a semântica dos PRC
e seus atributos.
•
TEXTUAL CONVENTION: permite a definição de novos tipos de dados
com sintaxe e semântica particulares, comuns a vários atributos de um
ou mais PRC.
•
OBJECT-GROUP e MODULE-COMPLIANCE: utilizadas para especificar
limites aceitáveis da implementação dos atributos dos PRC.
Todas as PRC têm um OID (Object Identifier) relativo ao OID raiz do módulo.
Tal como no SNMP, os OID são utilizados para identificar tabelas e atributos.
O termo PRID (Provisioning Instance Identifier) refere-se à conjunção entre o
OID e o identificador de uma instância (InstanceId). PPRID (Prefix PRID) é
utilizado para fazer referência a vários PRID simultaneamente, por exemplo
quando o servidor de aprovisionamento deseja remover múltiplos PRID de uma
só vez.
32
PIB
2.6.4 Operação
Tanto o servidor de aprovisionamento como todos os seus clientes devem
suportar os PIB requeridos, neste caso o PIB de framework e o PIB de DiffServ
referidos em 2.6.1. Cumprido este requisito, o servidor não necessita de saber
se está a comunicar com um encaminhador Linux ou Cisco.
Tabela PIB
PRC support
Component limitations
PIB incarnation
Device identification
Interface capabilities set
-Base interface capabilities
--Classification capabilities
--Metering capabilities
--Algorithmic dropper cap.
--Queuing capabilities
--Scheduler capabilities
--Shaper capabilities
--Data path element
--cascade depth capabilities
--Data path element linkage
--capabilities
-Interface capability set name
-and role combination
Descrição
Indica que tabelas PIB o cliente suporta
Indica limitações no suporte a atributos
Especifica a “incarnação” PIB activa
Contém informação do cliente (tamanho
máximo da mensagem e outros)
Descreve as interfaces do cliente
Direcção (egress, ingress, both)
Indica as facilidades de classificação de
pacotes que o cliente tem
Indica a capacidade de medir fluxos e fazer o
shaping
Indica o tipo de descarte suportado
Dimensionamento e recursos das filas
suportadas
Algoritmos de escalonamento e número de
filas
Algoritmos de shaping
Máximo número de componentes DiffServ
no caminho de um fluxo de pacotes
Ordem em que os componentes funcionais
do data path podem ser ligados
Descreve as combinações de roles que as
interfaces do cliente têm
Tabela 2.6: Hierarquia de Tabelas PIB na Mensagem notify
A aplicação integral da arquitectura DiffServ requer também o suporte por
todas as entidades envolvidas dos protocolos COPS e COPS-PR.
A solicitação inicial do cliente para o servidor de aprovisionamento ocorre
quando o cliente inicializa ou sempre que cliente e servidor perdem uma sessão
(por exemplo, o servidor reinicializou) e iniciam outra. Esta solicitação contém
informação do cliente essencial para o trabalho do servidor, tal como as
descrições e características das interfaces, capacidade de implementação dos
componentes da arquitectura DiffServ (medições, queuing e escalonamento –
ver secções 2.3.3 e 2.3.4) e ainda todas as PRC em ambos os PIB (framework e
DiffServ) com a característica notify. Esta solicitação particular pode por isso
ser referida somente por notify.
As principais tabelas utilizadas na mensagem notify estão listadas na tabela 2.6.
33
A resposta do servidor de aprovisionamento a um notify é uma mensagem
install, utilizada para instalar uma “incarnação” 2 do PIB com a configuração
estática que o cliente deve ter.
Tipicamente, os encaminhadores interiores trocam somente estes tipos de
mensagens com o servidor de aprovisionamento (ou nunca trocam nenhuma),
porque têm um conjunto estático de PHB e não fazem marcações de pacotes.
Novas políticas são tendencialmente aplicadas apenas aos encaminhadores de
fronteira (secção 2.3.6).
À medida que chegam os momentos de honrar políticas com reserva de recursos
(por exemplo, para atender a uma videoconferência), o servidor de
aprovisionamento envia novas mensagens install para os clientes (de fronteira).
A tabela 2.7 mostra as tabelas principais das mensagens install, sua hierarquia
e uma descrição abreviada.
Tabela PIB
PIB incarnation
Data path
-Classifier
--Classifier element
---Base filter
----IP filter
----802 filter
-Meter
--Token Bucket parameter
-Action
--DSCP mark action
-Algorithmic dropper
--Random drop
-Queue
--Shaping rate
--Assured rate
-Scheduler
--Shaping rate
--Assured rate
Descrição
Activa/desactiva “incarnações” PIB no cliente
Configura os pontos iniciais do data path
Especifica um classificador
Elementos a serem instanciados na tabela
Classifier
Filtro base do elemento classificador
Utilizada para filtrar tráfego com base nos
campos do cabeçalho IP
Utilizada para filtrar tráfego com base em
endereços Ethernet e Ids VLAN
Define medidores (encadeados se necessário)
Parâmetros para os medidores
Acção de um bloco de acção específico
Acções especificadas pelos atributos de
marcação
Especifica droppers aleatórios e outros
Parâmetros para um random dropper
Representa uma fila FIFO
Parâmetros da fila
Parâmetros da fila
Especifica um escalonador para seleccionar
pacotes das filas
Parâmetros do escalonador
Parâmetros do escalonador
Tabela 2.7: Hierarquia de Tabelas PIB na Mensagem install
Quando uma solicitação de reserva de recursos expira, o servidor instrui os seus
clientes para eliminar as tabelas PIB correspondentes.
2
Em inglês, incarnation
34
PIB
2.6.5 O PIB DiffServ
A estruturação do PIB DiffServ segue o modelo informal de gestão dos
Serviços Diferenciados definido em [RFC3290], que mostra como modelar as
interfaces de entrada e de saída de um encaminhador. Também descreve a
configuração e gestão de uma interface DiffServ em termos de um Traffic
Conditioning Block (TCB), que é o arranjo dos elementos que integram o data
path. O TCB pode conter zero ou mais classificadores, medidores, acções,
algorithmic droppers, filas e escalonadores.
Um data path é a sequência de elementos de processamento que podem lidar
com um pacote IP de forma a que ele obtenha o correcto tratamento DiffServ.
O tráfego pode ser classificado (por um filtro ou uma ACL); depois de
classificado o tráfego pode ser marcado com um código DSCP (por um
marcador); o tráfego marcado pode ser colocado em uma fila atendida por um
escalonador. Cada elemento é modelado por uma ou mais PRC e há casos em
que os elementos do data path podem seguir qualquer outro elemento, com
excepção do escalonador, como mostrado na figura 2.8.
Pode acontecer que o tratamento para qualquer pacote torne necessária a
repetição de um ou mais destes elementos numa sequência não permitida. Esta
situação pode ser ultrapassada com a modelagem de múltiplos TCB em cascata,
através do atributo Next dos vários elementos.
Na óptica da relevância para este trabalho, descrevemos a seguir alguns
aspectos particulares do PIB DiffServ. Este tem dois grupos:
- DiffServ Capabilities Group: indica o tipo de interfaces suportadas. Não lida
com interfaces individuais.
- DiffServ Policy Group: contém as configurações dos elementos funcionais de
uma política.
O PIB DiffServ representa a sequência de TCB que podem actuar sobre um
pacote através dos atributos Next dos vários elementos. O conceito de TCB a
um nível mais elevado que a modelagem dos seus elementos individuais não é
requerido na parametrização ou na junção dos elementos. Isto permite que
qualquer grupo de elementos construa um TCB, e minimiza alterações a este
PIB se as regras mudarem. São utilizadas diferentes tabelas e definições de
dados para (a) a configuração dos tratamentos sequenciais a serem aplicados a
um pacote e (b) a parametrização destes tratamentos.
É usada a noção de Data Path para indicar um processamento DiffServ. O data
path é individualizado pela combinação de funções (Role Combination),
conjunto de capacidades (capability Set) e direcção do fluxo de um pacote.
Uma entrada na tabela Data Path indica o primeiro elemento (possivelmente
de vários)que vai aplicar tratamento DiffServ ao pacote.
O PIB também inclui tabelas que descrevem as funcionalidades e limitações do
equipamento. Estas tabelas devem ser reportadas ao PDP para que este
determine a configuração dos elementos funcionais do equipamento. O PDP
deve ter controlo de todas as instâncias PRI do PEP.
35
Classificador
Elemento
Elemento
Elemento
Classificador
Classificador
Classificador
Classificador
Medidor
Medidor
Acção
Alg. Dropper
Fila
Acção
Política
Classificador
Medidor
Alg. Dropper
Acção
Classificador
Medidor
Acção
Alg. Dropper
Fila
Classificador
Medidor
Acção
Alg. Dropper
Fila
Alg. Dropper
Fila
Fila
Escalonador
Figura 2.8: Ordenação dos Elementos do TCB no Data Path
As partes de entrada e saída de um encaminhador são configuradas
independentemente. A diferença está num atributo de uma tabela que descreve
o início do data path.
Os elementos mais relevantes do PIB DiffServ para este trabalho incluem:
•
Tabela Data Path: cada instância descreve data paths específicos
segundo a combinação das funções das interfaces e direcção do fluxo. A
decisão de haver ou não haver tratamento DiffServ para uma interface
particular pode ser implícita ou explícita.
•
Tabelas de classificadores e tabelas de elementos classificadores:
permitem especificar um grupo de filtros.
•
Tabelas de medidores: o exemplo TBParam no [RFC3317] mostra como
configurar medidores dos tipos:
o Token Bucket Simples
36
PIB
o Ritmo Médio
o Ritmo Único Três Cores
o Dois Ritmos Três Cores
o Janela Deslizante Três Cores
•
Tabelas de acções
•
Tabelas de funcionalidades (capabilities)
A PRC para o medidor genérico é base para configuração de medições
específicas. Podem ser usadas tabelas padrão ou proprietárias. A PRC TokenBucket tem com os parâmetros ritmo (dsTBParamRate), tamanho de rajada
(dsTBParamBurstSize) e intervalo (dsTBParamInterval), e indicação de tipo do
medidor (dsTBParamType).
As PRC dos elementos funcionais utilizam o TC Prid para indicar o seguimento
do tratamento DiffServ. Um Prid é um identificador de objectos, e aponta para
uma instância de uma PRC em outra tabela.
Uma entrada data path aponta para uma entrada classifier. Esta identifica uma
lista de elementos de classificação, que são as condições do filtro propriamente
ditas. Os elementos de classificação apontam para uma próxima entrada de
classificação ou algum outro elemento funcional do data path.
Os elementos de classificação têm uma ordem de precedência para resolver
ambiguidades na sobreposição de filtros.
Um exemplo de um filtro que pode ser apontado por um elemento classificador
PRI é a PRC frwkIpFilterTable, que permite seleccionar pacotes com base nos
endereços de origem e destino, código DSCP, protocolo de nível 4, porta deste
protocolo, flowid do IPv6 e protocolo IP, TCP, UDP ou qualquer.
Os parâmetros frwkIpFilterEntry da tabela frwkIpFilterTable são listados na
tabela 2.8.
Parâmetro
frwkBaseFilterNegation
frwkIpFilterAddrType
frwkIpFilterDstAddr
frwkIpFilterDstPrefixLength
frwkIpFilterSrcAddr
frwkIpFilterSrcPrefixLength
frwkIpFilterDscp
frwkIpFilterFlowId
frwkIpFilterProtocol
frwkIpFilterDstL4PortMin
frwkIpFilterDstL4PortMax
frwkIpFilterSrcL4PortMin
frwkIpFilterSrcL4PortMax
Descrição
Actua como um NOT para o filtro
IPv4, IPv6
Endereço de destino
Máscara do endereço de destino
Endereço de origem
Máscara do endereço de origem
Código DSCP
FlowId do IPv6
Protocolo do nível 4
Porta mínima de nível 4 no destino
Porta máxima de nível 4 no destino
Porta mínima de nível 4 na origem
Porta máxima de nivel 4 na origem
Tabela 2.8: Parâmetros da PRC frwkIpFilterTable
37
Acções incluem “no action”, “marcar com um DSCP”, ou “acção específica”. A
tabela dsActionTable é utilizada para relacionar uma acção com o elemento
antes ou depois dela. Permite que as acções sejam encadeadas, sendo que a
última acção da cadeia aponta para o próximo elemento do TCB ou para o
próximo TCB.
Podem haver tabelas de acções específicas para tipos diferentes de acções, o
que permite a utilização de acções proprietárias sem impacto nas acções padrão
definidas em [RFC3317]. Esta norma não proíbe considerar o descarte como
um elemento de acção, embora seja formalmente manipulado por um outro
elemento funcional (Algorithmic Dropper).
A acção “DSCP Mark” utiliza uma gama de valores que são especificados na
tabela dsDscpMarkActTable.
O PIB DiffServ utiliza as classes PRC frwkPrcSupportTable e
frwkCompLimitsTable para especificar os PRC suportados por um PEP. As
classes frwkCapabilitySetTable e frwkIfRoleComboTable especificam o
conjunto de funcionalidades, tipos de interfaces e combinações de funções. As
instâncias de PRC que descrevem funcionalidades do tipo de interface são
apontadas por um OID numa instância da tabela frwkCapabilitySetTable.
A PRC dsIfClassificationCaps é utilizada para reportar as funcionalidades de
classificação, incluindo os elementos de informação que o dispositivo pode
utilizar para classificar o tráfego. Outras PRC existem para indicar as outras
funcionalidades.
Se um PEP receber uma política que não pode implementar, deve notificar o
PDP com uma mensagem de falha.
No anexo C, são apresentadas as tabelas PIB relevantes para este trabalho,
conforme codificadas na livraria utilizada (ver o capítulo 4 - Detalhes da
Solução Implementada)
2.6.6 Implementação de uma Política de Aprovisionamento
Este exemplo considera o cenário em que o tráfego HTTP deve ser agregado e
marcado com o código DSCP referente à classe AF21 (ver tabela 2.2 na página
15). O agregado deve ter 20%-30% da largura de banda total. A figura 2.9
mostra o data path que representa a configuração PIB enviada pelo servidor de
aprovisionamento aos seus clientes.
38
COPS
Data Path
ifSet=IFS0
roles=front1
ifDir=out
start
Classifier
Prid=0
reference=1
Classifier
Element
Prid=0
reference=1
precedence=1
Next=
Specific=
Classifier
Prid=0
reference=2
IP Filter
Prid=0
negation=0
addrType=ipv4
dstAddr=127.0.0.1
dstPL=0
srcAddr=151.23.0.0
srcPL=0
dscp=0
flow=0
prot=0
dstMinPort=0
dstMaxPort=65535
srcMinPort=0
srcMaxPort=65535
Classifier
Element
Prid=1
reference=2
precedence=1
Next=
Specific=
IP Filter
Prid=1
negation=0
addrType=ipv4
dstAddr=127.0.0.1
dstPL=0
srcAddr=151.23.0.0
srcPL=0
dscp=0
flow=0
prot=0
dstMinPort=0
dstMaxPort=65535
srcMinPort=80
srcMaxPort=80
DSCPMarkAction
Prid=30
DSCP=72 (AF21)
Next=
Queue
Prid=0
next=
MinRate = 20%
MaxRate = 30%
Scheduler
Prid=0
Next=0.0
Method=wrr
MinRate = 0
MaxRate = 0
Figura 2.9: Data Path para Agregar Tráfego HTTP em AF21
A parte da política referente à condição é traduzida numa lista de acessos
apropriada (elemento classificador e filtro IP), enquanto que a parte de acção é
realizada através de classes PRC específicas (DSCPMarkAction, Queue,
Scheduler) e seus atributos.
2.7 COPS
2.7.1 Introdução
Uma maneira de aprovisionar políticas é através do protocolo COPS (Common
Open Police Service) [RFC2748] com extensões para aprovisionamento
(COPS-PR) [RFC3084]. O protocolo COPS oferece suporte para múltiplos
clientes com provisão de políticas para vertentes específicas tais como QdS ou
segurança. As extensões COPS-PR adicionam as funcionalidades necessárias no
modelo de aprovisionamento PBN (ver a secção 2.2.3).
O COPS usa um modelo cliente/servidor sobre TCP, baseado no atendimento
pelo servidor às solicitações de políticas do cliente. As extensões COPS-PR são
especificadas de forma independente do tipo de política a ser aprovisionada e
definem os mecanismos e convenções utilizadas para a comunicação entre
servidor de aprovisionamento (PDP – Policy Decision Point) e cliente (PEP –
Policy Enforcement Point).
Os termos PDP e PEP são definidos pelo IETF no RFC A Framework for
Police-based Admission Control [RFC2753]. Outros termos definidos neste
RFC incluem:
39
•
Elemento ou Nó de Rede: encaminhadores, switches, hubs.
•
Política: combinação de regras e serviços em que as regras definem os
critérios para acesso e utilização dos recursos
•
Objecto de Política: contém informação de política em resposta a uma
decisão de atribuição de recursos
•
Elemento de Política: unidades de informação do Objecto de Política
•
Modelo Soft State: mecanismo automático de limpeza do estado
instalado num PEP ou PDP. É accionado em caso de falha de
comunicação ou falha do elemento de rede.
•
Estado Instalado: solicitação nova e única feita de um PEP para um
PDP, que deve ser explicitamente removida.
•
LPDP: um PDP existente no mesmo elemento de rede que o cliente PEP.
2.7.2 Principais Características
As especificações do COPS e do COPS-PR definem como suas principais
características:
40
•
No modelo cliente/servidor, o PEP envia mensagens de solicitações,
actualizações e eliminações ao PDP e o PDP retorna decisões ao PEP.
•
O protocolo foi definido para administração, configuração e aplicação de
políticas, e é extensível, podendo suportar objectos auto-identificados e
informações específicas dos clientes.
•
A conexão TCP é iniciada pelo PEP e mantém-se enquanto ambos
estiverem funcionais. A porta TCP padrão onde o PDP fica à escuta de
conexões dos PEP é a 3288
•
O COPS utiliza IPSEC ou TLS para autenticação e segurança do canal
de comunicação entre o PDP e o PEP.
•
É um protocolo stateful (guarda informação sobre os estados da
comunicação entre os clientes e o servidor). O estado de
solicitação/decisão é partilhado entre o cliente e o servidor (até ser
explicitamente eliminado) e os estados de vários eventos podem estar
associados (portanto, novas solicitações podem ter respostas diferentes).
•
O servidor pode enviar informação de configuração para o cliente em
modo não solicitado, e remover esta configuração quando não mais se
aplicar.
•
São suportados dois modelos para o controlo baseado em políticas:
Outsourcing e Provisioning (Aprovisionamento).
•
No modelo Outsourcing, o PEP delega a um PDP externo a
responsabilidade de tomar decisões de políticas sempre que houver
necessidade.
COPS
•
O modelo de Aprovisionamento permite que o PDP envie políticas para
o PEP de maneira pró-activa, em resposta a eventos externos (por
exemplo, a definição de uma nova política) ou eventos do próprio PEP.
•
O Aprovisionamento de políticas pode ser feito com a configuração
completa ou em partes desta.
2.7.3 Operação
A figura 2.10 mostra o modelo de aprovisionamento do COPS.
Encaminhador
de Fronteira
Servidor de
Aprovisionamento
COPS REQ()
PEP
PDP
COPS DEC()
Eventos
Externos
Figura 2.10: Modelo de Aprovisionamento COPS
As solicitações de políticas (COPS REQ()) descrevem o PEP e seus parâmetros
de configuração, e são enviadas sempre que houver uma alteração nestes
parâmetros (supostamente com pouca frequência). As decisões (COPS DEC())
não são necessariamente respostas a solicitações, sendo enviadas com mais
frequência devido a eventos externos ou do próprio PDP (actualizações de
políticas e SLA).
A figura 2.11 mostra a captura de uma troca típica de mensagens entre PEP e
PDP obtida com a implementação disponível no pacote COPSClientSDK da
Intel [IntelCOPS]. Nesta figura:
•
Os pacotes TCP de início de sessão, confirmações e fim de sessão foram
filtrados e correspondem aos índices em falta.
•
O PEP tem o endereço IP 192.168.2.2, e o PDP tem o endereço IP
192.168.2.1.
•
O pacote 4 é a solicitação inicial do PEP para o PDP a indicar a sua
configuração e suas funcionalidades (capabilities). A resposta vem no
pacote 6 com a configuração inicial das políticas.
•
Cliente e servidor trocam frequentemente mensagens Keep-Alive para
manter a sessão COPS.
•
Os pacotes 11, 14 e 15 fazem parte da solicitação que o cliente envia
para obter um novo conjunto de políticas (se o PDP o considerar um
candidato válido para elas). Embora a ferramenta de captura não
conseguisse interpretar o código de operação no pacote 14, o PDP desta
implementação particular certamente conseguiu.
•
O pacote 18 (em destaque) contém a resposta do servidor PDP à
solicitação do PEP. No painel de baixo, podem ser vistos alguns detalhes
41
desta mensagem, que incluem o seu tipo, se foi solicitada ou não, o
tamanho (1252 bytes) e os vários objectos PIB enviados para o cliente.
O objecto expandido faz a remoção das políticas anteriores, enquanto
que os outros abaixo dele representam a nova política a ser aplicada.
•
O PEP responde a uma mensagem de decisão com um Report State (no
pacote 20), que indica se houve sucesso na instalação da configuração,
ou qual a razão da falha, se for o caso.
•
Os diversos Decision Objects enviados ao PEP identificam as classes de
aprovisionamento através dos OID. Como os OID são atribuídos num
PIB, é essencial que o mesmo conjunto de módulos PIB tenha sido
carregado no PDP e nos seus PEP.
Figura 2.11: Mensagens COPS entre PDP e PEP
2.8 Trabalho Relacionado
Muito do trabalho sobre gestão de redes baseada em políticas na comunidade
académica e empresarial trata especificamente da Qualidade de Serviço.
Entretanto, trabalhos apresentados há poucos anos podem encontrar-se já
ultrapassados. A rápida evolução das normas e modelos disponíveis neste
domínio implica em que projectos protótipos muitas vezes não cheguem a
entrar em fase de produção.
42
TRABALHO R ELACIONADO
Alguns trabalhos relevantes associados com a arquitectura DiffServ incluem:
•
Projecto Moicane do IST (Information Society Technologies)
[MOICANE]: disponibiliza um ambiente de rede em larga escala para
permitir a cooperação entre grupos ligados em rede na pesquisa e
exploração de tecnologias diversas com QdS, baseadas nas arquitecturas
definidas pelo IETF. Tem uma rede nuclear que implementa uma região
DiffServ, a qual interage com uma rede de acesso para oferecer
Qualidade de Serviço em ambas, utilizando para isto encaminhadores
híbridos DiffServ/IntServ. Em Portugal, o INESC representa uma ilha
autónoma do projecto, interligada a quatro outras ilhas na Itália,
Roménia e Grécia.
•
QBone [QBone]: é um projecto americano integrado nos trabalhos do
grupo Internet2. Tem características semelhantes às do projecto
Moicane, mas o foco de pesquisa é principalmente na secção estrutural
(backbone) da Internet. Seu principal objectivo é testar e disseminar
mecanismos escaláveis de QdS. Tem conclusões pouco animadoras
sobre a possibilidade de oferecer serviços com qualidade fim a fim,
devido ao excesso de variáveis (hardware, software, modelos de
negócio, operações de rede, etc.) envolvidas.
•
Implementação e Validação da Linguagem Ponder num ambiente
CIM/DiffServ [Lymberopoulos]: grupos de trabalho do Imperial College
de Londres têm apresentado trabalhos relacionados com PBN há mais de
uma década [Sloman]. Este paper recente descreve a implementação de
uma arquitectura de gestão que suporta a configuração de políticas em
encaminhadores DiffServ Linux, fornecendo mecanismos para validação
das políticas no que respeita às capacidades dos encaminhadores que as
vão aplicar.
•
Projecto Faster da Universidade de Tampere, Finlândia: “Faster” é o
nome dado a um conjunto de projectos iniciados no começo da década
de 90 com experimentos da utilização de tecnologia ATM nas redes
universitárias. O grupo de trabalho DiffServ [Faster] produziu uma
implementação completa da arquitectura (descrita em duas teses de
mestrado [Lemponen], [Majalainen]). No contexto de uma arquitectura
DiffServ completa, está desfasada das especificações mais recentes do
IETF. Ainda assim, a implementação tem componentes e livrarias de
interesse e que foram utilizados neste trabalho (ver secção 4.2).
43
3
Arquitectura Proposta
3.1 Introdução
Esta secção descreve a arquitectura da implementação proposta. A arquitectura
da solução baseia-se no modelo DiffServ do IETF, que já foi em parte descrito
no capítulo anterior. O IETF não pressupõe ferramentas específicas de
implementação para a sua arquitectura, embora haja sugestões (e.g. LDAP para
o repositório, RED para classes AF) e trabalhos relacionados em curso (e.g.
linguagens de especificação de políticas).
No domínio da Qualidade de Serviço, a arquitectura DiffServ oferece maior
escalabilidade que a arquitectura IntServ, embora sozinha não consiga garantir
QdS fim a fim. Entretanto, a necessidade de um servidor de aprovisionamento,
que atenda a todos os encaminhadores de fronteira e que seja a interface entre
políticas de alto nível e políticas de baixo nível, pode ser um ponto de
estrangulamento neste modelo, se a geração de políticas ocorrer a um ritmo
muito elevado [Corrente].
A arquitectura proposta apoia-se na implementação de uma configuração
DiffServ básica no domínio, incluindo os encaminhadores de fronteira e os
encaminhadores internos. Esta configuração implementa as classes EF, AF1 a
AF4 e BE, e utiliza alguns parâmetros que podem ser alterados e outros que
devem permanecer em benefício da integração com o restante da arquitectura.
Dentre os parâmetros que podem ser alterados incluem-se a largura de banda
disponível para cada classe, bem como outros valores relacionados (burst, etc.).
A identificação de cada classe (classid) é um exemplo de parâmetro que não
deve ser alterado.
Uma vez implementada a configuração básica, os blocos funcionais da
arquitectura trabalham em conjunto para permitir aplicar e eliminar filtros que
seleccionam fluxos com base nos campos no cabeçalho IP e têm data e hora de
activação e desactivação, entre outras funcionalidades.
Um ponto menos claro na definição inicial da arquitectura foi o tratamento a
dar a pacotes com código DSCP não conhecidos dos encaminhadores. O IETF
reconheceu um conflito de recomendações neste aspecto e sugere [RFC3260]
que os encaminhadores de fronteira descartem o pacote ou alterem o seu DSCP
para colocá-lo na classe padrão (DSCP=0x00). Os encaminhadores interiores
nunca deveriam receber um pacote com um DSCP desconhecido (a não ser que
as próprias aplicações os criem dentro do domínio DiffServ); caso isto
aconteça, devem encaminhá-lo como se fosse da classe padrão.
A arquitectura proposta não é uma implementação completa do modelo
DiffServ, mas baseia-se nos seus conceitos principais para atingir o objectivo
de oferecer uma interface amigável de configuração de fluxos de tráfego em
classes com o respectivo tratamento diferenciado no domínio.
45
3. ARQUITECTURA PROPOSTA
3.2 Análise de Requisitos
3.2.1 Requisitos Genéricos
A arquitectura deve fornecer:
•
Uma implementação normalizada de classes para obter Qualidade de
Serviço em redes. Com a aplicação do modelo DiffServ, a satisfação
deste requisito permite que o domínio DiffServ possa vir a fazer parte
futuramente de uma região DiffServ, com pouco esforço de
compatibilização das metodologias e parâmetros de encaminhamento e
diferenciação do tráfego.
•
Gestão centralizada das políticas dinâmicas. A centralização da
administração é um importante veículo para a escalabilidade de uma
solução no que respeita à reutilização de objectos (políticas) já
definidos. Também permite obter consistência no comportamento global
do domínio (PDB).
•
Transparência entre a definição de uma política pelo utilizador e sua
respectiva configuração nos encaminhadores. Para atender ao modelo de
gestão mostrado na figura 2.1, é necessário haver independência entre as
definições de políticas orientadas ao negócio (alto nível) e as
especificidades tecnológicas de configuração dos equipamentos de rede
(baixo nível).
•
Possibilidade de expansão para suportar clientes (encaminhadores)
diversos e redes de grande dimensão. A escalabilidade do modelo
escolhido deverá ser verificada através de testes específicos.
•
Viabilidade e facilidade de implementação em redes de produção sem
demasiados esforços de configuração e programação. Este requisito é
atendido com o recurso a componentes também normalizados, como é o
caso do XML, LDAP e da própria arquitectura DiffServ.
•
Transparência possível a situações de falta dos componentes. Para
atender a este requisito, pode ser necessário ler e interpretar uma
configuração activa implementada nos encaminhadores. A utilização de
um repositório permite manter informações sobre o estado das políticas,
mesmo em caso de falta dos outros componentes. Para além disso,
nenhum dos componentes deve perder completamente a funcionalidade
se os outros falharem.
3.2.2 Estudo de Caso – Políticas de Qualidade de Serviço no IST
A rede informática do Instituto Superior Técnico em Lisboa beneficia-se há
algum tempo dos conceitos de diferenciação de fluxos de tráfego. Sendo uma
rede universitária de dimensão expressiva e com grande número de utilizadores,
é natural que os serviços mais relevantes sejam afectados pela escassez da
largura de banda, caso a disputem em igualdade de condições com as
aplicações de caráter mais lúdico que proliferam.
46
ANÁLISE DE R EQUISITOS
Ainda que não existissem tais aplicações lúdicas (jogos em rede, download de
músicas), a diferenciação do tráfego seria desejável para beneficiar, por
exemplo, o tráfego interactivo, em detrimento do tráfego ftp ou de correio
electrónico.
Na altura em que foi elaborada esta análise aos procedimentos de QdS na rede
informática do IST, o tráfego externo de chegada e o tráfego de saída eram
organizados através de scripts de configuração do encaminhador Linux em
quatro categorias com diferentes níveis de acesso aos recursos [CIIST]:
1. Interactivo: tráfego SSH/Telnet e transmissões ACK do TCP.
2. Servidores: tráfego de correio electrónico, acesso a páginas internet,
newsgroups em servidores do IST, etc.
3. Bulk: tipicamente o tráfego FTP (File Transfer Protocol) associado ás
transferências de ficheiros.
4. P2P: tráfego peer-to-peer já marcado como tal pelo firewall ou
identificado pelas portas utilizadas.
A configuração impunha que o tráfego externo usasse até um terço da largura
de banda nominal interna (34/100 Mbps), enquanto que o tráfego interno ficava
autorizado a utilizar os outros dois terços (66/100 Mbps).
O tráfego de saída tinha as partilhas da largura de banda mostradas na tabela
3.1.
Serviço
Todos
Interactivo
Servidores
Bulk
P2P
Ritmo Padrão
34 Mbps
2 Mbps
17 Mbps
14 Mbps
50 Kbps
Ritmo Máximo
34 Mbps
5 Mbps
34 Mbps
34 Mbps
1 Mbps
Tabela 3.1: Condicionamento do Tráfego de Saída no IST
O condicionamento dos diversos tipos de tráfego de entrada pode ser
visualizado na tabela 3.2.
Serviço
Todos
Interactivo
Servidores
Bulk
P2P
Ritmo Padrão
66 Mbps
2 Mbps
17 Mbps
13 Mbps
100 Kbps
Ritmo Máximo
66 Mbps
34 Mbps
34 Mbps
34 Mbps
2 Mbps
Tabela 3.2: Condicionamento do Tráfego de Entrada no IST
Além dos filtros de classificação DiffServ, também era efectuada uma selecção
e marcação prévia dos pacotes pelo módulo de firewall do encaminhador Linux.
47
A configuração destas acções destina-se a identificar o tráfego interno e P2P,
este último através de módulos específicos para o comando iptables [SForge].
3.3 Esquema Geral
3.3.1 Diagrama da Arquitectura
A figura 3.1 mostra o esquema geral da arquitectura proposta.
Interface com
o Utilizador
XML
PMT
Comandos e Respostas LDAP
XML
Servidor de
Aprovisionamento
KA, Dec
KA, Req,
RPT
Repositório
LDAP
PDP
KA, Req,
RPT
KA, Dec
PEP
PEP
Cria/Apaga filtros
Configura
Configuração
DiffServ
PHB
Estático
Encaminhador de Fronteira
Encaminhador Interior
Figura 3.1: Arquitectura Proposta
Relativamente à figura anterior:
48
•
PMT é o módulo Policy Management Tool. Este termo não é utilizado
nos RFC que descrevem a arquitectura DiffServ, mas sua funcionalidade
é definida no modelo de informação de políticas [RFC3060] e está
geralmente incorporada juntamente com o PDP (Policy Decision Point)
num componente que adquire a designação de Bandwidth Broker (BB).
•
Os rectângulos com sombra representam sistemas potencialmente
diferentes.
•
A implementação desta solução apenas permite fazer configurações
DiffServ dinâmicas em encaminhadores Linux.
•
Os módulos PEP, PDP e PMT devem executar como daemons (serviços),
embora estejam previstas situações de interactividade para detecção e
correcção de problemas.
ESQUEMA G ERAL
•
A caixa de texto suavizada que representa o PEP no encaminhador
interior indica que trata-se de um componente opcional nestas máquinas,
já que apenas é necessário manter a configuração estática de base. Na
arquitectura DiffServ, somente os encaminhadores de fronteira são
dinamicamente configurados.
É desejável que seja relativamente
simples configurar o módulo PEP para instalar ele próprio a
configuração de base através de um script que deve conhecer (este
procedimento também é útil nos encaminhadores de fronteira no caso de
reinicialização).
•
As mensagens principais trocadas entre PDP e PEP são o Keep-Alive
(KA), Req (para o PEP solicitar uma configuração), RPT (para o PEP
reportar o resultado de uma decisão) e Dec (para o PDP enviar uma
decisão de configuração). As decisões que o PDP envia podem ser não
solicitadas, o que é o modo natural de trabalho do modelo proposto
(modelo de aprovisionamento).
•
A seta pontilhada entre o PDP e o repositório indica que preferimos
optar por uma simplificação da arquitectura onde apenas a PMT interage
com o repositório LDAP. Na arquitectura do IETF para DiffServ, o PDP
busca as políticas a implementar directamente do repositório [RFC2753]
e a PMT não está sequer definida como entidade individual.
3.3.2 Operação
Esta secção descreve de forma sucinta os acontecimentos relevantes na
implementação de uma política. A operação detalhada de cada bloco funcional
da arquitectura será objecto da secção 3.3.3.
Tipicamente, o utilizador (administrador) usa um SLA configurado previamente
para definir um ou mais TCS (Traffic Conditioning Specification) através do
módulo de interface com o utilizador. Por exemplo, deseja estabelecer um
serviço de linha alugada virtual com 500 Kbps entre duas estações particulares,
para fazer videoconferência, das 16 às 17 horas de hoje. O módulo de interface
com o utilizador verifica se o SLA ainda tem esta largura de banda disponível e
interage com o módulo PMT (Policy Management Tool), para saber se é
possível fazer esta atribuição de serviço ou se há conflitos. Ao concretizar a
criação da política, confirma para o utilizador.
O módulo PMT recebe em XML os parâmetros para configurar a política e
verifica a sua correcção e validade. A seguir, faz a detecção de conflitos com
políticas já instaladas, através da avaliação da largura de banda disponível para
cada classe e da verificação de condições sobrepostas (duas políticas diferentes
para um fluxo com mesma origem e mesmo destino). Guarda as informações no
repositório e verifica se já é altura de instalar a política.
Também com recurso ao XML é feita a comunicação entre PMT e PDP. No
nosso modelo simplificado da arquitectura DiffServ, a PMT envia os
parâmetros de configuração para o PDP, e este não interage com o repositório.
A recepção destes parâmetros pelo PDP dá origem a uma decisão de
configuração não solicitada para o(s) PEP.
49
Ao receber a decisão de configuração, o PEP constrói o comando para o
encaminhador e o aplica. Idealmente, saberá interpretar pela resposta se a
operação teve sucesso ou não, e reportar para o PDP. Por sua vez, o PDP
informa a PMT que configura o estado correspondente da política no
repositório.
3.3.3 Opções de Implementação
Nesta secção descrevemos algumas opções de implementação especificamente
para os módulos funcionais DiffServ. A figura 2.5 vem repetida abaixo com a
informação adicional:
Medidor
Classificador
• BA
• MF
Condic.
do
Tráfego
• SRTCM
• TRTCM
• Dummy
Gestão do
Buffer
Scheduler
(Escalonador)
• NORMAL
• AQM
- RED
• CBQ
• HTB
Shaper/
Descartador
• FIFO
• Baseado
• PRIO
no Ritmo
• WRR
• SCFQ
• Hierárquico
Figura 3.2: Opções de Classificação e Condicionamento do Tráfego
As opções para o módulo Classificador incluem:
•
BA: classificação por Behavior Aggregate através do código DSCP.
•
MF: classificação por campos múltiplos do cabeçalho do pacote.
O Condicionamento de Tráfego pode ser feito por:
50
•
SRTCM: (Single Rate Three Color Marker) mede o ritmo de um fluxo e
marca os pacotes a verde, amarelo ou vermelho, de acordo com o
resultado da medição. Na prática as cores são marcadas no campo DS
como diferentes precedências da classe AF.
•
TRTCM: (Two Rate Three Color Marker) semelhante ao anterior, mas
considera também o ritmo e a rajada de pico do fluxo na avaliação. Este
medidor e o anterior podem ser sensíveis a cores (o DSCP dos pacotes
afecta o processo de marcação) ou insensíveis a cores (a marcação é
feita independentemente do código DSCP anterior do pacote).
•
Dummy: sem condicionamento
ESQUEMA G ERAL
A Gestão do Buffer tem as opções:
•
NORMAL: utiliza o mecanismo Tail-Drop Queuing, em que os descartes
são efectuados no fim da fila quando o buffer enche. O principal
problema deste mecanismo é o tempo de resposta do sistema, que pode
levar a perdas indevidas de pacotes em períodos de rajadas.
•
AQM: nome genérico dos mecanismos que fazem a gestão proactiva do
conteúdo da fila.
•
RED: mecanismo Random Early Detection de descarte probabilístico.
Mede o tamanho actual da fila (TF), comparando-o com dois limites. Se
o primeiro limite (L1) não for ultrapassado, nunca há descartes. Entre o
primeiro e o segundo limites, os pacotes têm uma certa probabilidade de
serem descartados (por exemplo, 2%). Acima do segundo limite (L2),
todos os pacotes são descartados. Se LF=(Limite Absoluto da Fila),
então LF > L2 > L1. O descarte de pacotes antes que a fila esteja cheia
sinaliza precocemente para uma origem TCP dos pacotes que há uma
congestão incipiente, daí o termo Early. A característica aleatória do
descarte torna o mecanismo mais justo.
•
CBQ: (Class-Based Queuing) é uma disciplina de filas hierárquica, que
pode conter outros módulos de classificação, marcação e gestão de
buffer. Sua grande vantagem é poder “emprestar” a largura de banda não
utilizada, dividindo-a pelas entidades da hierarquia que a necessitem até
ao máximo configurado em cada uma. Entretanto, CBQ é considerada
muito difícil de configurar, tendo problemas bem identificados ao fazer
estimativas da utilização do canal [Hubert].
•
HTB: (Hierarquical Token Bucket) actua de forma semelhante à CBQ
mas usa o mecanismo Token Bucket Filter para o shaping. Além disso,
distribui a largura de banda disponível de forma ponderada pelo ritmo
(rate) definido em cada subclasse.
As opções para o Escalonador são:
•
FIFO: (First In, First Out) é a forma mais simples de uma fila. O
primeiro pacote a entrar na fila é o primeiro a ser atendido.
•
PRIO: mecanismo de prioridade estática. Subdivide o tráfego em várias
subclasses FIFO com base nos filtros configurados. As subclasses são
atendidas de forma determinística com base na sua prioridade relativa.
•
WRR: (Weighted Round Robin) atende uma fila por vez, e selecciona em
cada uma delas um número de pacotes proporcional à prioridade relativa
da fila.
•
SCFQ: (Self-Clocked Fair Queuing) é uma simplificação menos justa da
disciplina WFQ (Weighted Fair Queuing). As disciplinas FQ (Fair
Queuing) mantêm uma fila separada para cada fluxo de tráfego, evitando
assim que o aumento de pacotes por uma das fontes de tráfego resulte
numa maior ocupação da largura de banda pelo seu fluxo. As filas são
atendidas uma por vez [Nagle].
•
Hierárquico: é uma hierarquia de filas e escalonadores WFQ (Weighted
Fair Queuing).
51
E, finalmente, o módulo de shaping e descarte é implementado para atender a
um determinado ritmo, podendo atrasar ou descartar pacotes para honrar o
ritmo acordado.
A análise das opções apresentadas aqui é complementada pela informação sobre
disciplinas de filas e termos relacionados na secção 2.3.4.
3.4 Blocos Funcionais
3.4.1 Introdução
Nesta secção são descritas as funcionalidades dos blocos individuais no
contexto da arquitectura proposta. O capítulo 4 discute em detalhe os aspectos
práticos na implementação da solução.
3.4.2 Interface do Utilizador
A interface com o utilizador é utilizada para a definição das diferentes políticas
a serem aplicadas na rede, verificação do seu estado e definição das larguras de
banda visíveis nas diversas classes.
Para a especificação de uma política particular, a interface oferece a abstracção
semelhante aos “Serviços Olímpicos” sugeridos pelo IETF (ver secção 2.2.3),
porém com um número mais elevado de classes [Calhariz]. Estas classes superolímpicas são mapeadas para as classes DiffServ de acordo com a tabela 3.3,
que também mostra a acção levada a efeito em cada classe para pacotes fora do
perfil respectivo.
Classe de
Serviço
Diamante
Platina
Ouro
Prata
Bronze
Tradicional
Classe
DiffServ
EF
AF1
AF2
AF3
AF4
BE
Pacotes fora
de perfil
Descarte 3
Remarcação
(DP1 e DP2),
Descarte 4
(DP3)
Nada
Tabela 3.3: Mapeamento das Classes de Serviço
A especificação de uma política inicia com a definição de um SLA associado a
uma das classes, com a indicação da largura de banda máxima e faixa de
3
Pacotes fora do perfil na classe EF devem ser descartados (do fim da fila) para que seja respeitada a
condição de baixo retardo.
4
Caso os pacotes fora de perfil nas classes AF fossem remarcados para outra classe, poderiam ser
entregues fora de sequência, o que é incompatível com a definição do serviço Assured Forward.
52
B LOCOS F UNCIONAIS
prioridades que pode utilizar. Este SLA terá um identificador que futuramente
poderá estar associado a um cliente com permissões para definir os TCS deste
SLA particular.
Um SLA deve ter um ou mais TCS. De facto, são os TCS que definem e
concretizam os filtros que serão configurados nos encaminhadores de fronteira.
Na definição de um TCS fica implícita a classe que vai utilizar, através do SLA
a que pertence. Devem ser indicados os parâmetros para filtrar o tráfego,
prioridade do filtro (dentro da faixa permitida e sem duplicados), ritmo máximo
desejado (até ao máximo disponível no SLA), e alcance temporal.
A filtragem por cabeçalho IP pode incluir:
•
Versão do protocolo IP: IPv4 ou IPv6.
•
Endereço de origem do tráfego e máscara para identificar múltiplos
sistemas de origem. Exemplo: 192.168.2.0/24 refere-se a todos os
sistemas da sub-rede 192.168.2.0.
•
Endereço de destino do tráfego e máscara para identificar múltiplos
sistemas de destino.
•
Protocolo: IP, TCP, UDP, todos.
•
Gama de valores para as portas de origem e portas de destino.
•
Código DSCP: permite seleccionar pacotes pelo código DSCP marcado
anteriormente.
•
Fluxo IPv6: utilizado para rotular sequências de pacotes destinados a
tratamentos especiais.
Nesta arquitectura, definimos que não pode haver filtros simultaneamete
activos com a mesma prioridade. A razão deste impedimento é a forma como o
Linux permite fazer remoção de filtros DiffServ – deve ser indicada uma
prioridade, e todos os filtros com aquela prioridade são removidos.
O ritmo máximo padrão é a largura de banda ainda disponível no SLA deste
TCS.
O alcance temporal do filtro é definido através de uma data/hora de início e
uma data/hora de fim.
A verificação/alteração do estado de um filtro é feita através de uma lista de
todos os filtros configurados por SLA e ainda não expirados. Os estados
possíveis são:
•
Inactivo: data/hora de início ainda não foram alcançadas ou foi
desactivado.
•
Em instalação: o PDP já foi notificado para instalar o filtro.
•
Activo: indica o número de encaminhadores (PEP) que reportaram a
instalação bem sucedida do filtro.
Outra importante função administrativa da interface com o utilizador é permitir
que o administrador da rede configure a divisão da largura de banda da rede
entre as diversas classes de serviço. A arquitectura permite a configuração de
mais ou menos largura de banda que a nominal, numa perspectiva de ajuste fino
53
na oferta de recursos. Na secção 5.4 mostramos os resultados de alguns testes
relativos ao sobredimensionamento da largura de banda nas classes.
3.4.3 Gestor de Conflitos e Tradutor de Políticas
Este módulo é a PMT (Policy Management Tool). Interage com :
•
O repositório, para criar, verificar e eliminar políticas, SLA, TCS e para
verificar se já deve instalar ou remover políticas na rede.
•
A interface com o utilizador, para verificar o contexto de autorização
sobre os objectos do repositório (administrador: tudo; cliente: um SLA e
os seus TCS) e trocar as necessárias informações através de XML.
•
O PDP, para solicitar a instalação, desinstalação ou relatório do estado
das políticas.
A PMT necessita de suportar a noção de políticas de alto nível, que expressam
os objectivos da administração da rede, em oposição a políticas de baixo nível,
que são interpretadas por cada um dos elementos de rede afectados. A figura
3.3 mostra os elementos de interface da PMT.
Políticas de Alto Nível
XML
Para Interface
com o Utilizador
PMT
Para o
Repositório
Comandos
e Respostas
LDAP
Para PDP
Políticas de Baixo Nível
XML
Figura 3.3: A Policy Management Tool
Uma importante tarefa da PMT é fazer a verificação de potenciais conflitos
antes de implementar novas políticas. Os conflitos acontecem quando
diferentes acções são configuradas para o mesmo fluxo de tráfego. Isto pode ser
realizado com a comparação das origens e destinos das novas políticas com a
informação armazenada no repositório, considerando-se ainda as respectivas
datas e horas de activação e desactivação.
Outra possível fonte de inconsistências é a divisão da largura de banda. Esta é
verificada por mera formalidade pela PMT, porque os processos de atribuição
de SLA e de TCS impedem uma sobre-utilização da largura de banda (embora
seja possível que o administrador configure cada classe com mais largura de
banda que a existente na rede – ver secção 5.4).
54
B LOCOS F UNCIONAIS
O envio das políticas para o PDP é feito em XML, mas tanto quanto possível
próximo da estrutura de PIB (Policy Information Base) utilizada na
comunicação entre PDP e PEP. Esta arquitectura simplificada prevê que apenas
a PMT acesse o repositório, portanto deverá indicar todos os parâmetros
relevantes em comunicação directa para o PDP.
3.4.4 Repositório
O repositório oferece o suporte necessário às acções dos diversos módulos,
armazenando definições dos SLA, TCS e políticas. A implementação deve
prever a hipótese de um cliente gerir o seu próprio SLA com a configuração
dos TCS. Isto pode ser realizado com a provisão de um mecanismo de
autenticação entre a PMT e o módulo de interface com o utilizador.
Somente a PMT interage com o repositório nesta arquitectura. O directório
LDAP é um repositório central, que possibilita a administração centralizada das
políticas a partir de um único ponto. É a escolha natural para armazenamento
de políticas, pois trata-se de um standard aberto definido pelo próprio IETF
que beneficia da existência de um schema para o modelos de informação de
políticas (mas não para o modelo de informação de QdS) [RFC3703].
Uma das características desta arquitectura proposta, é de basear-se numa
configuração DiffServ estática dos encaminhadores para prover apenas filtros
adicionais relativos a fluxos de tráfego específicos. Isto permite uma
simplificação do schema a definir no repositório LDAP, não impedindo no
entanto sua futura expansão. A secção 4.2.3 indica os elementos realmente
utilizados no esquema juntamente com o schema desenvolvido de propósito
para este trabalho.
Um importante conceito relacionado com a abstracção das políticas e a sua
definição como um par de grupos (se <condições> então <acções>) é a
possibilidade de reutilização sem que tenha de ser novamente definida por
completo. A provisão para reutilização de políticas baseia-se na estrutura
atómica que seus componentes têm no repositório LDAP, e implica em que as
condições e as acções sejam também elementos reutilizáveis.
Id
1
...
...
...
...
...
Política
Condições
Condições Acções 1: src=192.168.2.65/32
1,2,23
1,15,30 2: dst=192.168.3.22/32
...
...
...
...
...
...
...
...
...
...
...
23: porta=7000
...
...
...
Acções
1: DSCP=EF
2: DSCP=AF1
...
15: LB=500Kbps
16: LB=2Mbps
...
30: polAction=DROP
Tabela 3.4: Configuração de uma Política
A tabela 3.4 mostra um exemplo de configuração de política associando-a com
elementos individuais nas tabelas de condições e acções.
55
No repositório ficam armazenadas as definições de políticas, condições, acções,
definições dos SLA e TCS e também inclui informações de estado sobre estes
elementos.
3.4.5 PDP
O PDP (Police Decision Point) configura os PEP (Policy Enforcement Point)
quando estes assim solicitam e também quando há solicitações da PMT para
implementação ou remoção de políticas.
O modelo do IETF prevê que este componente faça a descoberta dos PEP que
tem a configurar para cada política individual. Na arquitectura proposta neste
documento, o PDP conhece os roles em cada PEP e utiliza-os para decidir se os
configura ou não. Tipicamente, envia as políticas para todos os encaminhadores
de fronteira, informando a PMT sobre suas identidades.
O PDP não tem de conhecer a arquitectura específica dos PEP com que
interage, desde que o PEP suporte a PIB (Policy Information Base) requerida
(ver a secção 2.6). Neste caso, as PIB utilizadas são a PIB Framework e a PIB
DiffServ. O outro requisito importante é o suporte a COPS e COPS-PR (ver a
secção 2.7).
A figura 3.4 mostra as interfaces funcionais do PDP.
XML
Para PMT
Converte as
solicitações da
PMT em PIB
PDP
Converte PIB em
informações para
a PMT
Para PEP
COPS/COPS-PR
Figura 3.4: O Policy Decision Point
A figura 3.5 mostra em esquema como seria parte da construção de um filtro
que usa as classes PRC dos PIB framework e DiffServ. ILabelMark é a etiqueta
interna utilizada para indicar o micro-fluxo entre as interfaces externas e
internas. A marcação propriamente dita (DSCP=AF11) é feita na interface
interna. Esta política inicia com o classificador “Congresso” e indica elementos
para filtros e para acções selectivas.
56
B LOCOS F UNCIONAIS
Data Path
CapSetName = “IfCap1”
Roles = “A+B”
IfDirection = Ingress
Start >>>>>>>>>>>>>>>>>> Clfr Id = Congresso
Clfr
Id = Congresso
ClfrElement
Id=Congresso1
ClfrId=Congresso
Preced=NA
Next >>>>>>>>>>>>>>>>> Clfr Id = C1Aplic
Specific >>>>>>>>>>>>> Filter Congresso1
ClfrElement
Id=Congresso2
ClfrId=Congresso
Preced=NA
Next >>>>>>>>>>>>>>>>> Clfr Id = C2Aplic
Specific >>>>>>>>>>>>> Filter Congresso2
Clfr
Id = C1Aplic
ClfrElement
Id=C1Aplic1
ClfrId=C1Aplic
Preced=NA
Next >>>>>>>>>>>>>>>>> Meter Id = C1A1Ritmo1
Specific >>>>>>>>>>>>> Filter Aplic1
Meter
Id = C1A1Ritmo1
SucceedNext >>>>>>>>>> Action Id=Green
FailNext >>>>>>>>>>>>> Meter Id=C1A1Ritmo2
Specific >>>>>>>>>>>>> TBParam Type=TRTCM
TBParam
Type=TRTCM
Rate
BurstSize
Interval
Action
Next >>>>>>>>>>>>>>>>> AlgDropAF11
Specific >>>>>>>>>>>>> ILabelMark ILabel=AF11
Figura 3.5: Construção de uma Política com PIB
A noção de Data Path é bem visível na figura 3.5, através dos diversos atributos
Next dos elementos. O medidor utilizado é do tipo Token Bucket Two Rate
Three Color Marker.
A implementação de um PIB deve ser feita na ordem contrária, ou seja, os
elementos referenciados nos atributos Next já devem existir na altura em que
forem criados os elementos que os referenciam.
57
3.4.6 PEP
PEP (Policy Enforcement Point) é o dispositivo ou módulo que recebe decisões
do PDP em forma de PIB, faz o mapeamento para comandos de configuração
específicos do sistema onde está instalado, aplica e executa concretamente as
políticas. Também é responsável por monitorizar e reportar estatísticas e outras
informações de operação. Na arquitectura proposta, a funcionalidade de
mapeamento gera sempre comandos para configurar um encaminhador com o
sistema operativo (SO) Linux.
Quando o encaminhador com o PEP inicializa, envia para o PDP informação
sobre seu hardware, software e configuração. Em resposta, o PDP deve enviar
todas as políticas de aprovisionamento relevantes para este sistema [RFC3084].
Outras políticas podem ser recebidas do PDP sem que o processo seja iniciado
pelo PEP.
Todas as políticas recebidas são mapeadas, através de regras de transformação,
para os mecanismos locais de QdS, e instaladas. O PEP deve reportar o sucesso
ou falha da instalação das políticas através de mensagens RPT.
As duas operações principais suportadas pelo PEP são:
•
Instalação: instala ou actualiza uma política
•
Remoção: elimina uma política instalada.
A figura 3.6 mostra um esquema das interfaces funcionais do PEP.
COPS/COPS-PR
Comandos
de
Paraespecíficos
PDP
configuração DiffServ
PEP
Converte PIB
nos comandos
DiffServ locais
Para SO
Reporta estado
da instalação em
PIB
Figura 3.6: O Policy Enforcement Point
3.4.7 Encaminhadores
O modelo dos Serviços Diferenciados não impõe regras rígidas na configuração
dos encaminhadores. Cada implementação particular pode definir os pontos e
tipos de classificação e policiamento e os componentes utilizados na
implementação (ver secção 3.3.3 - Opções de Implementação). Em relação ao
58
B LOCOS F UNCIONAIS
tratamento a dar ao tráfego fora de perfil, as opções são limitadas pelas
características das classes, como explicado pelas notas da tabela 3.3.
Este trabalho propõe uma solução para encaminhadores Linux de fronteira e
interiores ao domínio DiffServ. Outros tipos de encaminhadores podem ser
utilizados se o respectivo PEP estiver implementado com os PIB utilizados e se
a configuração básica estática (que define as classes DiffServ) tiver sido
aplicada. Idealmente, o código utilizado para o PEP admitirá diferentes
módulos de mapeamento para comandos de configuração DiffServ específicos
do sistema.
Na arquitectura proposta, os encaminhadores Linux de fronteira e interiores
têm suas interfaces de rede configuradas com o conjunto básico de classes
DiffServ na sua inicialização. Isto pode ser feito através de um script RC
[SForge] que também lança o PEP, ou dentro do próprio PEP se a opção for por
utilizar um ficheiro de configuração para este último. O ficheiro de
configuração define a localização do script de configuração e o role das
interfaces de rede.
A combinação da localização da interface (externa ou interna ao domínio) com
a direcção do tráfego (saída ou entrada) torna necessário que a configuração
estática atenda de forma eficaz a quatro situações potencialmente diferentes nos
encaminhadores de fronteira. A figura 3.7 mostra os papéis das interfaces em
encaminhadores.
interface externa
direcção=saída
interface externa
direcção=entrada
saída
Nó de
Fronteira
entrada
interface interna
direcção=saída
Domínio
DiffServ
Nó
Interior
interface interna
direcção=entrada
Figura 3.7: Os papéis das interfaces
Para esclarecer a necessidade de diferenciar as configurações como mostrado,
consideramos uma situação de tráfego de voz sobre IP (VoIP). Este tipo de
tráfego utiliza pacotes pequenos (60 a 200 bytes) com grande sobrecarga do
cabeçalho (40 bytes). O protocolo é o RTP (Real Time Protocol) sobre UDP.
A qualidade da transmissão deste tipo de tráfego requer baixo retardo, e baixo
jitter (variação no atraso dos pacotes). Estes parâmetros são afectados pela
distribuição aleatória dos tamanhos de pacotes de outros fluxos que estejam a
ser encaminhados pelos mesmos encaminhadores que o tráfego VoIP.
Suponhamos que o tráfego VoIP está a disputar a largura de banda com
transferências de ficheiros. Se V representar 60 bytes de um pacotes VoIP e F
59
representar o mesmo número de bytes em pacotes FTP, poderíamos ter uma fila
no encaminhador como mostra a figura 3.8.
V
FFFFFFFFFFFFFFFFFFFF
VVV
FFFFFFFFFFFFFFF
VV
Figura 3.8: Tráfego VoIP vs. Tráfego FTP
As configurações DiffServ de controlo do tráfego nos encaminhadores podem
ajudar a minimizar este problema. É necessário estabelecer uma regra na
interface externa, direcção entrada, para que os fluxos VoIP que entram no
domínio sejam sempre encaminhados em primeiro lugar, com um valor de
rajada suficiente para abranger a largura de banda das conversações
individuais, e um valor do ritmo policiado igual ao valor da rajada multiplicado
pelo número de conexões simultâneas que desejamos atender. Em linguagem de
políticas de alto nível:
“Fluxos VoIP de 64 Kbps para o domínio têm prioridade 1 até 512 Kbps”
Esta regra pode ser interpretada pelo sistema de forma a implementar um filtro
na interface externa que seleccione o tráfego VoIP na direcção entrada, dandolhe prioridade 1 no encaminhamento para rajadas até 64 Kbps e ritmo de 512
Kbps, equivalente a oito conexões de 64 Kbps. Pacotes fora do perfil seriam
remarcados (embora essa não seja geralmente a melhor opção para tráfego
multimédia).
Após o policiamento, os pacotes são encaminhados para a rede através de uma
interface diferente, ou para os níveis superiores (e.g. TCP, UDP) se o destino
for a máquina local. O encaminhamento, após seleccionar a interface de saída,
o próximo destino do pacote, e o encapsular, envia os dados para uma fila da
respectiva interface. Esta fila (output queue) também faz parte do mecanismo
de controlo do tráfego no Linux. Os pacotes podem aqui sofrer classificação,
descarte, atraso selectivo, reordenamento, etc., antes de serem entregues ao
driver da interface de rede.
Assim, configura-se outro filtro na interface interna (sem policiamento da
largura de banda desta vez; já houve este policiamento na outra interface) que
envie os pacotes VoIP para a classe de melhor desempenho; a situação óptima
ocorre quando o escalonador usa uma fila do tipo PRIO (ver secção 3.3.3).
TCP, UDP, etc.
Interfaces
de Entrada
Políticas de
Entrada
DeMux de
Entrada
Encaminhamento
Filas de
Saída
Interfaces
de Saída
Controlo do Tráfego
Figura 3.9: Processamento de Dados da Rede no Linux
A figura 3.9 mostra os módulos envolvidos no processamento de um pacote de
rede num sistema Linux [Almesberger].
60
B LOCOS F UNCIONAIS
Para adaptarem-se às políticas DiffServ configuradas no domínio, as acções a
que se sujeitam os pacotes no encaminhador incluem o policiamento com
descarte e o atraso selectivo ou shaping. O shaping só pode ser efectuado sobre
os pacotes que se envia, portanto com as combinações (interface externa –
direcção saída) ou (interface interna – direcção entrada). Na interface interna,
direcção entrada, é conveniente, mas não obrigatório, haver alguma
funcionalidade típica dos PHB dos encaminhadores interiores para evitar que o
tráfego classificado como mais prioritário seja sobrepujado pelos fluxos de
menor prioridade antes mesmo de entrar no domínio [Lemponen]. Na figura, o
módulo onde o shaping pode ser efectuado chama-se Filas de Saída.
O policiamento é configurado sob demanda (novos SLA/TCS) e deve ser feito
tão cedo quanto possível para os pacotes que entram no domínio, porque não
faz sentido manter em tráfego e a consumir recursos, pacotes fora do perfil que
mais cedo ou mais tarde seriam policiados à mesma. No exemplo acima, este
policiamento é efectuado na interface externa, direcção entrada, onde é
estabelecido o primeiro contacto dos pacotes com o domínio. Na figura, este é
o módulo de policiamento de entrada (ingress).
A tabela 3.5 mostra um resumo das conclusões sobre policiamento e shaping.
Caso haja acordo com uma região DiffServ contígua, pode ser necessário
policiar e fazer o shaping no tráfego de saída, nos encaminhadores de fronteira.
Encaminhador de
Fronteira
Interface
Interface
Externa
Interna
Tráfego de
Saída
Tráfego de
Entrada
Policiamento Marcação
(dinâmico) (estático)
Encaminhador
Interior
Todas as
Interfaces
PHB
Configurados
(estáticos)
Tabela 3.5: Aplicação de Políticas às Interfaces
Assim, na arquitectura proposta há três configurações a fazer:
a. Configurar a interface externa dos encaminhadores de fronteira para
permitir adicionar dinamicamente classificadores com ou sem
policiamento. Estes classificadores vão “rotular” cada pacote com o
identificador de fluxo correspondente a uma classe DiffServ.
b. Configurar a interface interna dos encaminhadores de fronteira com o
objectivo de marcar o campo DSCP nos pacotes antes de os enviar para a
rede do domínio. Pode haver algum condicionamento do tráfego pelo
próprio policiamento (ver o capítulo 5 – Testes).
c. Configurar todas as interfaces dos encaminhadores internos com os PHB
adequados à configuração do ponto b.
As figuras a seguir são baseadas em [Calhariz], [Almesberger].
61
TCP, UDP, etc.
Interfaces
de Entrada
Classificador 1
Classificador 2
Classificador n
DeMux de
Entrada
Encaminhamento
Filtrou
Dentro do perfil
Filtrou
Dentro do perfil
Policiador 1
Fora de perfil
Policiador 2
Fora de perfil
Policiador 3
Fora de perfil
Policiador 4
Fora de perfil
Dentro do perfil
Dentro do perfil
Filas de
Saída
Interfaces
de Saída
Marcador EF
Marcador AFx1
Marcador AFx2
Marcador AFx3
Marcador BE
Figura 3.10: Configuração da Interface Externa – Policiamento de Entrada
A figura 3.10 mostra como fica a configuração da(s) interface(s) externa(s) de
um encaminhador de fronteira. O rectângulo maior a tracejado representa o
módulo de policiamento de entrada. As caixas de texto pontilhadas
(classificadores
e
policiadores)
indicam
condições
implementadas
dinâmicamente através dos SLA/TCS; as outras representam a configuração
estática de base. O policiamento é dinâmico mas a atribuição de SLA aos
clientes já contempla e respeita os limites de cada classe (ver secção 3.4.2 Interface do Utilizador).
A figura 3.11 representa a configuração da(s) interface(s) interna(s) de um
encaminhador de fronteira. O rectângulo em pontilhado é o módulo das filas de
saída.
As filas AFx têm, cada uma, três níveis diferentes de prioridade de descarte.
Estes níveis não estão diferenciados nesta figura, embora o estejam na figura
3.10 (ver secção 2.3.3 – Arquitectura DiffServ).
Finalmente, a configuração de qualquer interface dos encaminhadores interiores
é igualmente representada pela figura 3.11. As ligeiras diferenças na
implementação serão detalhadas no capítulo 4. Funcionalmente, não há escolha
nos encaminhadores interiores relativamente ao atraso selectivo (shaping),
como poderia haver nos encaminhadores de fronteira. Os PHB são sempre
aplicados aos pacotes em trânsito no interior do domínio para respeitar a
largura de banda máxima atribuída a cada classe.
62
B LOCOS F UNCIONAIS
TCP, UDP, etc.
Interfaces
de Entrada
Políticas de
Entrada
DeMux de
Entrada
Encaminhamento
Interfaces
de Saída
Fila EF
Classificador EF
Fila AF1
Classificador AF1
Fila AF2
Classificador AF2
Fila AF3
Classificador AF3
Escalonador
por
Prioridade
Fila AF4
Classificador AF4
Fila BE
Figura 3.11: Configuração da Interface Interna – Filas de Saída
A correcta configuração dos encaminhadores de fronteira evita que haja pacotes
com DSCP inválido no interior do domínio DiffServ, excepto por pré-marcação
numa fonte interna (por exemplo, o comando ping com a opção –Q permite
marcar o campo tos). Qualquer pacote com DSCP inválido recebe nos
encaminhadores internos o tratamento padrão (classe BE), mas sem
remarcação, como acontece nos encaminhadores de fronteira [RFC3260].
O que fazer com pacotes AF fora de perfil? Foi verificado empiricamente que o
seu descarte sumário, havendo largura de banda disponível na rede, representa
um desperdício de recursos. Por outro lado, a sua remarcação para outra classe
pode criar um problema de reordenação dos pacotes de um fluxo (alguns
chegam via AF1, outros via AF2, possivelmente fora de ordem), incompatível
com a filosofia de serviço das classes AF. O modelo proposto faz a
implementação de todos os policiadores necessários (1, 2 ou 3) para que
pacotes AF fora de perfil sejam remarcados para a próxima prioridade de
descarte dentro da mesma classe, ou descartados quando a prioridade de
descarte é a última.
63
4
Detalhes da Solução Implementada
4.1 Introdução
A solução proposta destina-se a implementar um nível mínimo mas utilizável
de funcionalidade na configuração de classificadores sobre uma configuração
básica estática. As opções disponíveis para os classificadores baseiam-se na
utilização de filtros por campos do cabeçalho IP, conforme entradas da tabela
frwkIpFilterTable do Framework PIB [RFC3318].
A implementação pretende ser expansível para poder incorporar no futuro toda
a gama de possibilidades descritas pelo IETF ou requeridas localmente por um
domínio específico. Para isto, beneficia da utilização de standards da indústria.
O software desta implementação pode ser classificado da seguinte forma:
a. Tecnologias e livrarias padrão da indústria: OpenLDAP, Java, livrarias
XML e LDAP para Java [OpenLDAP, Java, W3CXML, SAX2, JLDAP].
b. Tecnologias desenvolvidas em projectos académicos: livrarias PIB e
COPS [Lemponen00].
c. Exemplos de utilização das livrarias PIB e COPS para implementação de
PDP e PEP [Lemponen00]. Estes exemplos, na linguagem C, foram
utilizados como base para o desenvolvimento do protótipo funcional
desta parte da arquitectura.
d. Código original do autor. Inclui o módulo de interface com utilizadores
e administradores, o módulo PMT de interface com o repositório e PDP,
métodos diversos implementados sobre os exemplos originais de PDP e
PEP, schemas LDAP e XML, e os scripts para os encaminhadores.
4.2 Blocos Funcionais
4.2.1 Introdução
Nesta secção são descritos os aspectos práticos na implementação da solução.
Está estruturada de forma semelhante à secção 3.4 para facilitar a referência
com a arquitectura proposta mostrada na figura 3.1.
4.2.2 Interface do Utilizador
No módulo de interacção com o utilizador/administrador, houve a preocupação
de apresentar um conjunto de interfaces simples e objectivas. A representação
das políticas como SLA e TCS não pode evitar a abordagem por vezes
demasiado técnica para os parâmetros de configuração dos classificadores e
policiadores, embora estejam implementados mecanismos de ajuda para
esclarecer as diversas opções.
65
4. DETALHES DA SOLUÇÃO IMPLEMENTADA
Este módulo foi desenvolvido em linguagem Java com utilização de um IDE
(Integrated Development Environment) para facilitar a construção das
interfaces gráficas. Seu funcionamento é esquematizado na figura 4.1, onde
cada ecrã da aplicação está representado por uma caixa de texto devidamente
identificada com o nome da classe Java correspondente. Também estão
identificados os contextos do Utilizador e do Administrador.
Identificação
ou Terminar
Utilizador
Ver SLA
configurados
Administrador
Opções de
Administração
ID01
AD01
IU01
Ver os TCS
TCS01
Configurar os
TCS
TCS02
Ver os SLA
AD02
Ajustar Larguras
de Banda das
Classes
AD03
Configurar os
SLA
AD04
Figura 4.1: Funcionamento da Interface com o Utilizador
As duplas setas significam que as classes filhas têm sempre nos ecrãs um botão
associado a um método Abandonar(), que devolve o controlo ao contexto
que as criou. No ecrã ID01, há um botão para encerrar a aplicação.
A classe TCS01 de visualização dos TCS, é partilhada pelo fluxo do utilizador
e pelo fluxo do administrador, mas não há possibilidade de a utilizar para
navegar entre os ecrãs IU01 e AD02, já que, quando encerrada, retorna o
controlo para o contexto em que foi invocada.
As classes não mostradas na figura 4.1, mas que têm um papel importante na
aplicação, incluem:
•
sla: definição e métodos dos objectos SLA.
•
tcs: definição e métodos dos objectos TCS.
•
classesDS: atributos e métodos das classes DiffServ.
As mensagens trocadas entre a Interface com o Utilizador e o módulo PMT
utilizam uma notificação de identificação onde o sufixo Sol indica solicitações
para a PMT, e o prefixo Rsp indica as respostas da PMT após consultar ou
actualizar o repositório:
•
66
IdentSol: Solicita validação da identificação do utilizador ou
administrador.
B LOCOS F UNCIONAIS
•
IdentRsp: Informa se as credenciais são válidas, e se é um utilizador
ou administrador.
•
SLASol: Solicita a árvore de SLA armazenada no repositório, para este
utilizador ou administrador.
•
SLARsp: Envia os dados de SLA e TCS no contexto adequado
(utilizador ou administrador).
•
ClasseDSSol: Solicita envio dos dados referentes às classes DiffServ.
•
ClasseDSRsp: Envia os dados das classes DiffServ.
•
ActualSol: Solicita a actualização de um objecto no repositório e
correspondente configuração na rede se for um TCS.
•
ActualRsp: Indica se a acção de actualização solicitada teve sucesso.
As mensagens são construídas com recurso a XML. Por exemplo, uma
mensagem IdentSol tem o formato:
<IdentSol><Utilizador>Admin</Utilizador><Senha>senha</Senha></IdentSol>
Mensagens não reconhecidas são simplesmente descartadas. Os DTD utilizados
para validar o XML estão listados no anexo A.
A figura 4.2 mostra como exemplo o ecrã de configuração de um TCS na
aplicação.
Figura 4.2: Ecrã de Configuração dos TCS
Cada TCS está associado a um SLA, cuja identificação é apresentada no ecrã da
figura. Também é visível a classe de serviço associada a este SLA, que
condiciona a colocação de pacotes dentro do perfil de tráfego (ritmo desejado)
67
do TCS. O ritmo agregado dos TCS de uma classe não pode ultrapassar o valor
do ritmo do SLA respectivo. É desejável poder criar TCS que não estejam
activados, e acivá-los ou desactivá-los conforme for conveniente, se necessário
com alteração das datas e horas de início e fim da validade.
Os endereços de origem e destino não poderão ser aleatórios. Eles devem ter o
formato de endereço IP, e não podem diferir dos endereços configurados no
SLA excepto para maior especificidade dentro da sub-rede. Por exemplo, se o
SLA estiver configurado com o endereço de origem igual a 192.168.3.0/24, é
possível haver um TCS cujo endereço de origem seja 192.168.3.32/30 ou
192.168.3.132/32, mas não 192.168.4.0/24. Isto evita que um utilizador possa
condicionar o tráfego de redes alheias, já que é o administrador a configurar os
seus SLA.
A prioridade de cada TCS activo deve ser única (porque na remoção de filtros
estes são identificados pela respectiva prioridade) e é condicionada pela faixa
de prioridades atribuída ao SLA. Isto tem como consequência a limitação do
número de TCS activos a qualquer momento, no sistema e por cliente/SLA.
Devido a estas considerações, a definição de prioridade é feita pelo sistema no
momento da activação de um filtro/TCS, e não pelo utilizador. Os filtros da
classe Diamante (EF) têm sempre valores mais baixos para o atributo
prioridade.
4.2.3 Gestor de Conflitos e Tradutor de Políticas
Este módulo é equivalente à Policy Management Tool na arquitectura do IETF
[RFC3460]. Convencionamos fazer referência a ele com o termo PMT.
IdentSol
SLASol
ClasseDSSol
RemoveSol
ActualSol
Interface com
o Utilizador
32881
Search
Modify
Add
Delete
PMT
389
IdentRsp
SLARsp
ClasseDSRsp
FiltrosRsp
RemoveRsp
ActualRsp
Repositório
criaFiltro
32880 removeFiltro
Rpt
Rpt
PDP
Figura 4.3: Relação da PMT com outros Módulos
68
B LOCOS F UNCIONAIS
Como mostrado na figura 4.3, o módulo PMT tem três interfaces:
•
Interface XML com o módulo de interface com o utilizador. Ouve na
porta 32881. A cada solicitação válida corresponde uma resposta da
PMT.
•
Interface com o repositório. Envia comandos LDAP para a porta padrão
LDAP (389). Os comandos e as respostas estão definidos em livrarias
jLDAP (ver secção 2.5.5 – LDAP e Java)
•
Interface XML com o PDP. Usa a porta 32880 configurada no PDP. Está
definido um único modelo de resposta para qualquer comando válido da
PMT.
A tabela 4.1 mostra os comandos que podem ser trocados entre a PMT e a
Interface do Utilizador. Não estão mostradas algumas das respostas.
Comando
Função
Exemplo
Identifica o
<IdentSol><utilizador><nome>Admin</nome>
<IdentSol>
<senha>xyz</senha> </utilizador></IdentSol>
Utilizador ou
(IU → PMT)
Administrador
Responde à
<IdentRsp><utilizador><nome>Admin</nome>
<IdentRsp>
<estado>OK</estado>
solicitação de
(PMT → IU)
</utilizador></IdentRsp>
identificação
<SlaSol>
Informação de
<SLASol><sla> <slaUser>Admin</slaUser>
</sla></SLASol>
(IU → PMT)
SLA e TCS
<ClasseDSSol> Informação das
<ClasseDSSol><classeds> <classe>Prata
DP2</classe>
</classeds></ClasseDSSol>
(IU → PMT)
classes
Solicita
<FiltrosSol>
<FiltrosSol></FiltrosSol>
informação
(IU → PMT)
sobre os filtros
<DelSol>
Elimina
<DelSol><sla> <slaId>Sla200401</slaId>
</sla></DelSol>
(IU → PMT)
objectos
Altera
<ActualSol><classeQdS> <classe>Bronze
<ActualSol>
DP1</classe> <ritmo>12000</ritmo>
atributos
dos
(IU → PMT)
</classeQdS></ActualSol>
objectos
(IU → PMT)
Cria objectos
<ActualSol><tcs><tcsId>Tcs200402</tcsId>
<slaId>Sla200401</slaId>
<pcimRuleName>Segundo TCS</pcimRuleName>
<pcimTPCTime>200408301200200409011133
</pcimTPCTime>
<pcimRulePriority>7</pcimRulePriority>
<condicao>origem 192.168.2.28</condicao>
<condicao>portaUDPdst 44444</condicao>
<accao>DESCARTA</accao>
<pcimRuleEnabled>1</pcimRuleEnabled>
</tcs></ActualSol>
Fim de
Respostas
(PMT → IU)
Indica que a
PMT já enviou
as respostas
<SlaRsp>fim</SlaRsp>
<ActualSol>
Tabela 4.1: Comandos Trocados entre PMT e Interface do Utilizador
69
A PMT traduz as condições e acções dos TCS para facilitar o trabalho do PDP.
O diálogo trocado entre PMT e PDP já é orientado à criação das tabelas PIB,
como mostra a tabela 4.2, com os comandos que podem ser trocados entre a
PMT e o PDP.
O comando <Rpt> é enviado regularmente para o PDP de modo a manter
actualizada a tabela de filtros da PMT, mas sem criar demasiado tráfego.
Em situações de produção, é recomendado existir um script RC (Run Control)
para activar automaticamente este módulo.
Tal como o módulo de interface com o utilizador, este módulo foi desenvolvido
em Java, mas não tem interface gráfica porque em ambiente de produção deverá
executar como um serviço (daemon). Trabalha sempre em contexto
administrativo relativamente ao repositório.
Comando
Função
Cria
<criaPolitica> políticas
no PEP
<rmPolitica>
<Rpt>
Elimina
politicas
no PEP
Solicita
relatório
de
filtros
no PEP
Exemplo
<criaPolitica>
<politica><nome_politica>POL1</nome_politica>
<classificador><clElemento>
<precedencia>181</precedencia>
<filtroIP>
<tipoEnd>1</tipoEnd>
<dstEnd>192.168.3.0</dstEnd>
<dstMask>24</dstMask>
<srcEnd>192.168.2.0</srcEnd>
<srcMask>24</srcMask>
<protocolo>6</protocolo>
<dstPortaMin>20</dstPortaMin>
<dstPortaMax>22</dstPortaMax>
</filtroIP>
<meter>
<nome_meter>M1</nome_meter>
<ritmo>10000</ritmo>
<rajada>1000</rajada>
<sucesso>AF32</sucesso>
<falha>DESCARTA</falha>
</meter>
</clElemento>
</classificador>
</politica>
</criaPolitica>
<rmPolitica> <clElemento>
<precedencia>33</precedencia>
</clElemento> </rmPolitica>
<Rpt><pep> <nome_pep>Linax</nome_pep>
</pep></Rpt>
Tabela 4.2: Comandos da PMT para o PDP
Ao inicializar, este módulo lê um ficheiro de configuração com os endereços e
credenciais para o repositório e para o PDP. Interage com o repositório para
70
B LOCOS F UNCIONAIS
criar os Timers utilizados para implementar ou eliminar políticas nos
encaminhadores através do PDP, nas datas e horas respectivas. Cria um novo
Timer sempre que é definido (e aceite) um TCS.
A verificação de conflitos necessita de ser feita sempre que a interface com o
utilizador propõe a implementação de uma política. Basicamente, é verificado
se o mesmo par de endereços origem-destino tem outra política configurada
para horários sobrepostos. O conflito é sinalizado para a interface com o
utilizador e a requisição é ignorada.
4.2.4 Repositório
O repositório foi criado com recurso ao software OpenLDAP [OpenLDAP]
instalado em um sistema Linux Red Hat versão 9. O OpenLDAP tem uma série
de dependências para software de terceiros não instalado normalmente de forma
padronizada no Red Hat. As dependências por sua vez podem exigir a
instalação de outro software não padrão. Todo o software necessário está
disponível como pacotes linux e tem licenças Open Source.
A seguir listamos as dependências, na ordem em que devem ser instaladas:
•
Livrarias TLS: fornecem serviços Transport Layer Security para que o
software OpenLDAP seja completamente de acordo com a especificação
LDAPv3 do IETF [RFC2251]. As livrarias são instaladas através do
componente OpenSSL disponível em http://www.openssl.org.
•
Serviços de Autenticação Kerberos: o OpenLDAP suporta o mecanismo
SASL/GSSAPI e necessita da instalação das livrarias Kerberos. Os
pacotes estão disponíveis em http://www.pdc.kth.se/heimdal/ ou em
http://web.mit.edu/kerberos/www.
•
Livrarias SASL (Simple Authentication and Security Layer): é requerida
a instalação das livrarias Cyrus SASL, que disponibilizam serviços de
autenticação simples e security layer. Estas livrarias utilizam o software
OpenSSL e Kerberos se já estiver instalado. Estão disponíveis em
http://asg.web.cmu.edu/sasl/sasl-library.html.
•
Software de Base de Dados: a versão actual do OpenLDAP requer o
Sleepcat Software Berkeley DB, versão 4.2. Está disponível na página
http://www.sleepycat.com/download/.
Todos estes pacotes têm de ser descomprimidos para um local temporário. É
essencial a leitura das instruções de instalação, geralmente num ficheiro
Install ou numa subdirectoria doc, para todos estes componentes e também
para o OpenLDAP.
O serviço LDAP propriamente dito fica disponível com o arranque de uma
aplicação que executa como daemon no Linux. Esta aplicação é o slapd e a
sua localização padrão é na directoria /usr/local/libexec. Em
servidores de produção, deve ser considerada a criação de um script RC (Run
Control) para automatizar o arranque dos serviços LAPD.
O slapd tem um ficheiro de configuração normalmente denominado
/usr/local/etc/openldap/slapd.conf, onde são indicados os
71
schemas utilizados, bem como informações sobre referrals (ver secção 2.5),
segurança, políticas de acesso, replicação (se for desejado) e de segurança. Um
ficheiro de schema é assim referenciado no slapd.conf:
include /usr/local/etc/openldap/schema/core.schema
Caso não haja definição de políticas de segurança, qualquer utilizador pode ler
todas as informações, mas a sua alteração é restrita ao elemento identificado
como rootdn nas definições da base de dados:
database: bdb
suffix: “dc=Acordos de Serviço, dc=CIIST, dc=IST, dc=pt”
rootdn: “cn=Admin, dc=Acordos de Serviço, dc=CIIST,
dc=IST, dc=pt”
rootpw: secret
O ficheiro de configuração deve incluir também a indicação da directoria onde
fica localizado fisicamente o repositório e os índices a serem mantidos na base
de dados.
O repositório LDAP foi configurado com um pequeno modelo derivado de
PCIM e PCIMe. Estes modelos mais genéricos têm as classes nucleares para
modelagem de políticas, embora não sejam suficientes muitas vezes para
representar regras concretas [RFC3460]. Para além dos schemas de base e
DiffServ, o schema que implementamos encontra-se listado no anexo B.
As classes do schema do IETF [RFC3318] interessantes para a definição dos
filtros neste trabalho são:
•
A classe PolicyFlowDirectionVariable: indica a direcção de
um fluxo (IN ou OUT) relativamente a um elemento de rede.
•
A classe SimplePolicyAction: modela uma acção de configuração,
por exemplo marcação do DSCP.
•
A classe IpHeadersFilter: contém as propriedades mais comuns
requeridas para construir critérios de selecção com base no conteúdo dos
cabeçalhos IP, TCP ou UDP.
4.2.5 PDP
A implementação do PDP utilizou as livrarias PIB, COPS e COPS-PR e um
código exemplo desenvolvidos em linguagem C na Universidade de Tampere,
Finlândia [Lemponen]. O software data de Setembro de 2002 e está disponível
em http://atm.tut.fi/tut-cops-pr-pib-0.4.tar.gz. Detalhes mais completos do seu
funcionamento podem ser encontrados no trabalho referido.
A instalação deste software tem como requisito livrarias de codificação BER
(Basic Encoding Rule) para preparar as tabelas PIB de forma que possam ser
enviadas pelo COPS e COPS-PR para o PEP. Por sua vez, as livrarias BER
necessitam que as livrarias libabz já estejam instaladas no sistema. Em
http://packages.debian.org/testing/libdevel/libber0-dev as livrarias BER podem
ser encontradas e em http://packages.debian.org/testing/source/libabz estão as
livrarias libabz.
72
B LOCOS F UNCIONAIS
O exemplo existente (versão 0.4) tem as seguintes funcionalidades:
•
Trabalha apenas em modo interactivo.
•
Aceita conexões de sistemas PEP e recebe as suas configurações.
•
Responde às mensagens periódicas KA (Keep-Alive) dos clientes.
•
Quando há uma solicitação do PEP, envia um conjunto padrão de
configurações.
Foi feita uma intervenção para que o código do PDP passasse a:
•
Trabalhar em modo background ou em modo interactivo.
•
Aceitar conexões na porta 32880, para receber da PMT indicações de
instalação e remoção de políticas em XML. Esta personalização das
funções do PDP limita a solução em termos de transparência entre os
níveis funcionais e possibilidade da utilização de outras implementações
PDP-PEP, mas oferece uma compensação importante: permite que a
PMT obtenha indicações dos filtros configurados nos encaminhadores,
sem ter de os conhecer e contactar directamente.
•
Interpretar as mensagens recebidas da PMT e configurar com PIB os
filtros adequados ou mensagens de remoção e enviar para os PEP. A
funcionalidade de detectar necessidades de configuração dos filtros e os
respectivos parâmetros de instalação, é independente da PMT no modelo
do IETF. Ao invés de programar o acesso LDAP no PDP, este trabalho
usa a implementação feita na PMT para o efeito.
•
Enviar para a PMT informações sobre os filtros instalados (referentes à
configuração dinâmica dos encaminhadores de fronteira).
Em ambiente de produção, o PDP deve ser implementado como um serviço
(daemon) que arranca na inicialização do Linux. Isto pode ser feito com um
script de arranque para o PDP e um link para este script por exemplo em
/etc/rcX.d/S99pdp, onde X é o runlevel normal do sistema (pode ser
determinado com o comando runlevel). No caso dos sistemas utilizados
neste trabalho (Linux Red Hat 9) o runlevel é o 5.
A figura 4.4 mostra o esquema de funcionamento do PDP. Os ficheiros DTD de
validação XML estão listados no apêndice A.
73
PMT
PDP
PEP
(inicializa)
Inicia sessão
PIB (Id, Funcionalidades)
KA
.
.
.
KA
<criaPolitica>...</criaPolitica>
ou
<rmPolitica>...</rmPolitica>
PIB (filtros)
KA
.
.
.
PIB decision
<Rpt><pep>...</pep></Rpt>
<Rpt>
<pep><nome>...<nome>
<filtros>
<interface>...</interface>
<precedencia>...</precedencia>
KA
.
.
.
KA
...
</filtros></pep>
...
</Rpt>
Figura 4.4: Esquema de Funcionamento do PDP
4.2.6 PEP
Tal como no caso do PDP, a implementação do PEP utilizou as livrarias e um
código exemplo desenvolvidos em linguagem C na Universidade de Tampere,
Finlândia [Lemponen00]. Detalhes mais completos do seu funcionamento
podem ser encontrados no trabalho referido.
O exemplo existente tem as funcionalidades:
•
Trabalha sempre em modo interactivo.
•
Conexão com o PDP. O endereço deste e porta de ligação podem ser
indicados na linha de comandos.
•
Troca de mensagens KA (Keep-Alive) periodicamente com o PDP.
•
Solicitação de decisões (modelo de outsourcing).
As seguintes funcionalidades foram acrescentadas para satisfazer os requisitos
deste trabalho:
74
B LOCOS F UNCIONAIS
•
Possibilidade de trabalhar em modo background (como um serviço do
sistema) ou em modo interactivo.
•
Leitura de um ficheiro de configuração com as indicações do endereço
do PDP, porta de ligação, interfaces disponíveis no encaminhador local e
o papel de cada uma (exterior/interior), e a localização do ficheiro para a
configuração inicial básica DiffServ.
•
Execução do ficheiro de configuração DiffServ (script Linux com
comandos tc) na inicialização (configuração básica das interfaces), após
ler o seu próprio ficheiro de configuração.
•
Recepção a partir do PDP de comandos de configuração ou remoção de
filtros em formato PIB, tradução para os comandos adequados de
configuração do Linux e aplicação na(s) interface(s) externa(s) do PEP.
•
Envio para o PDP de relatórios relativos aos comandos recebidos e
configuração do encaminhador.
•
Correcção da livraria para evitar bloquear as mensagens KA em caso de
excesso de actividade ou tráfego com o PDP.
A figura 4.5 mostra um exemplo de ficheiro de configuração para o PEP.
# activar modo interactivo com mensagens
debug ON
# Descrição textual para o PEP
desc Linux kernel 2.4.20-8
# Tipo do encaminhador
PEPtipo fronteira
# interfaces do sistema e sua função
interna eth0
externa eth1
# ficheiro config basica DiffServ
PEPscript /etc/config-pep-tc
# endereço do PDP
PDPsrv 192.168.2.2
# porta do PDP
portaPDP 3288
Figura 4.5: Ficheiro de Configuração para o PEP
O funcionamento do PEP está esquematizado na figura 4.6. Ao inicializar, o
PEP lê o seu ficheiro de configuração e lança o script DiffServ para configurar
as interfaces conhecidas segundo a função de cada uma. Se algum dos ficheiros
não existir, a aplicação termina com uma mensagem para o ficheiro
/etc/PEPlog. A seguir envia sua identificação e lista de funcionalidades para o
PDP e os dois sistemas entram num ciclo de keep-alives (KA).
As mensages KA são utilizadas como unidade de tempo para o PEP enviar
periodicamente (de n em n KA) um relatório dos filtros instalados no PEP, que
o PDP passa à PMT em formato XML quando solicitado.
75
Shell/
Kernel
PEP
(inicializa)
Le ficheiro PEP.conf
Cria configuração básica
DiffServ e Interroga filtros tc
PDP
Inicia sessão
PIB (Id, Funcionalidades)
KA
.
.
KA
Interroga filtros tc
PIB (filtros)
KA
.
Cria ou elimina filtro(s) tc
(PEP de fronteira)
.
PIB (instala ou remove política)
KA
.
.
KA
Interroga filtros tc
PIB (filtros)
KA
.
.
Figura 4.6: Esquema de Funcionamento do PEP
A primeira mensagem enviada pelo PEP ao PDP chama-se notify e contém
informação de capacidades do encaminhador (ver a secção 2.7.3 sobre a
operação do COPS e COPS-PR). Em resposta, o PDP pode enviar uma
mensagem install para criar uma configuração básica no PEP. Caso o PDP
esteja inactivo, o PEP instala esta configuração se a conhecer.
Certos pressupostos da arquitectura DiffServ não poderiam ser implementados
sem uma análise exaustiva e porventura modificação e actualização das
livrarias PIB utilizadas. Ao invés de manter um repositório de estado para o
PEP, como sugere o modelo, limitamo-nos a fazer com que a configuração do
encaminhador ficasse transparente para sua operação. O PEP configura ou
remove um filtro na(s) interface(s) externa(s), e envia o resultado desta
operação para as camadas superiores da arquitectura, onde foi concentrado o
esforço principal de desenvolvimento neste trabalho.
76
B LOCOS F UNCIONAIS
O protótipo funcional desenvolvido cria, elimina e reporta do PEP filtros
baseados nos atributos do protocolo IP que se encontram disponíveis na tabela
PIB FrwkIpFilterEntry (ver anexo C). A tabela 4.3 descreve estes atributos.
Atributo
frwkIpFilterAddrType
frwkIpFilterDstAddr
frwkIpFilterDstPrefixLength
frwkIpFilterSrcAddr
frwkIpFilterSrcPrefixLength
frwkIpFilterDscp
frwkIpFilterFlowId
frwkIpFilterProtocol
frwkIpFilterDstL4PortMin
frwkIpFilterDstL4PortMax
frwkIpFilterSrcL4PortMin
frwkIpFilterSrcL4PortMax
Descrição
Tipo de endereço:
1 – IPv4; 2 – IPv6; 16 – Domínio DNS
Endereço de destino dos pacotes
Máscara do endereço de destino
Endereço de origem dos pacotes
Máscara do endereço de origem
Código DSCP dos pacotes
Fluxo IPv6 dos pacotes
Protocolo nível 4 (ex. TCP, UDP,…)
Porta inicial de destino nível 4
Porta final de destino nível 4
Porta inicial de origem nível 4
Porta final de origem nível 4
Tabela 4.3: Atributos da Tabela FrwkIpFilterEntry (RFC 3318)
Em ambiente de produção, o PEP deve ser implementado como um serviço
(daemon) que arranca na inicialização do Linux. Isto pode ser feito com um
script de arranque para o PEP e um link para este script por exemplo em
/etc/rcX.d/S99pep, onde X é o runlevel normal do sistema (pode ser
determinado com o comando runlevel). No caso dos sistemas utilizados
neste trabalho (Linux Red Hat 9) o runlevel é o 5.
4.2.7 Encaminhadores
O controlo do tráfego com componentes DiffServ é parte integrante do kernel
Linux utilizado (versão 2.4.20-8). Além dos módulos QdS, outros componentes
podem actuar sobre tráfego, seleccionar e marcar pacotes. Há um esquema
disponível em http://www.docum.org/docum.org/kptd/ que mostra em detalhe o
caminho percorrido por um pacote num sistema Linux [Balliache].
Relativamente à Qualidade de Serviço, a figura 4.7 mostra como os módulos
DiffServ são realizados pelos serviços do kernel Linux.
Os componentes básicos do controlo de tráfego no Linux são as disciplinas de
filas (qdisc), as classes e os filtros [Almesberger].
As disciplinas de filas e classes são identificadas por dois números
hexadecimais através da notação <maior>:<menor>. Para qdiscs, o segundo
número (menor) é sempre zero e pode ser omitido na notação. Há uma
disciplina especial denominada ingress (ver adiante) que sempre deve ter o
número maior igual a ffff. As outras podem utilizar a faixa de números entre
1 e 0x7fff.
77
Condicionador de
Tráfego DiffServ
Medidor
Classificador
Controlo
do
Tráfego
no kernel
Linux
Marcador
Filtro Política
Shaper/
Descartador
Classe
Classificador
Disciplina de Fila
Figura 4.7: Realização dos Módulos DiffServ no Linux
Para classes, o número menor é sempre acima de zero. O termo identificador
de classe (class ID) é frequentemente utilizado em lugar do número menor.
A atribuição de pacotes de tráfego a classes específicas pode ser feita com os
filtros. Os critérios de filtragem podem incluir endereços, protocolos e portas
da comunicação e outros campos do cabeçalho dos pacotes, além de outras
possibilidades (manipulação prévia pelas rotinas de firewall, por exemplo). Nas
versões 2.4.x do kernel Linux, a filtragem de pacotes é possibilitada por um
conjunto de componentes integrados com o nome genérico de Netfilter, que
inclui as funcionalidades de firewall e masquerading IP. Uma das opções mais
úteis (não utilizada directamente neste trabalho) é a de guardar um registo das
conexões existentes para fazer marcação ou eliminação de pacotes. A
ferramenta utilizada para configurar as regras Netfilter é a aplicação
iptables.
Os parâmetros DiffServ num encaminhador Linux podem ser configurados de
várias formas:
•
Na shell (interactivamente, por script ou pela invocação dentro de um
programa) através do comando tc (traffic conditioning) [Almesberger99,
Hubert02].
•
Dentro de uma aplicação, com a API rtnetlink do kernel [Hubert].
•
Através do agente de configuração remota DSR, que tem um conjunto de
capacidades úteis para muitas situações de utilização dos
encaminhadores, embora não ofereça todo o potencial das soluções
anteriores [Calhariz].
Este trabalho utiliza os comandos tc através de scripts e por invocação da shell
dentro do PEP. Os scripts fazem a configuração estática de base das interfaces
externa e interna, e o PEP aplica e remove filtros na interface externa.
78
B LOCOS F UNCIONAIS
Numa perspectiva prática, o conjunto de definições proposto seria
automaticamente e sempre instalado na inicialização dos encaminhadores de
fronteira e interiores e constituiria uma configuração estática de base. A ideia
principal é disponibilizar as classes normalizadas para as quais serão enviados
fluxos individuais de tráfego classificados por filtros específicos aplicados na
interface externa do encaminhador de fronteira após a configuração base ser
instalada.
Caso a arquitectura esteja totalmente instalada, os filtros classificadores serão
construídos através das interfaces de definição das políticas e implementados
automaticamente; também continua sendo possível a aplicação incremental de
scripts com comandos tc, embora este procedimento seja potencialmente
desestabilizador para a gestão do ambiente. Os parâmetros específicos dos
classificadores e disciplinas de filas, tal como largura de banda e outros,
poderão ser ajustados através da manipulação dos scripts. Este procedimento
deve estar condicionado ao conhecimento do impacte que o ajuste dos
parâmetros tem nos níveis superiores da arquitectura proposta.
A seguir mostramos como fazer o mapeamento da configuração de base
proposta no capítulo anterior para comandos tc, de forma a atribuir pacotes às
classes DiffServ EF, AF11 a AF43 e BE num encaminhador Linux. O script
completo encontra-se no anexo D. A partir desta configuração básica podem ser
acrescentados os filtros de selecção às interfaces externas para classificar os
pacotes nas classes definidas segundo os critérios desejados. Se não forem
definidos filtros, todo o tráfego é classificado como BE e o campo DS de todos
os pacotes fica com a marcação 0x0 após deixar o encaminhador pelas
interfaces internas ao domínio.
Nas interfaces exteriores dos encaminhadores de fronteira, será feita a
classificação e policiamento dos pacotes que entram no domínio, como já foi
explicado. Para tratar apenas os pacotes que vêm para o domínio, não é
necessário configurar PHB nestas interfaces. Assim, apenas é configurada uma
disciplina de fila tipo ingress, que é um classificador com policiamento. Não
coloca pacotes em fila e consome um mínimo de recursos. Os filtros a serem
configurados ou removidos de forma dinâmica para atender aos SLA controlam
o descarte ou a indicação (para as interfaces internas) de marcação dos pacotes
em BA (behavior aggregates), cujo tratamento será feito nos encaminhadores
interiores, de acordo com o comportamento sugerido para as classes DiffServ
correspondentes [RFC2597, RFC3246].
O comando para instalar esta disciplina indica a interface (no exemplo,
$IFaceExt é uma variável à qual terá sido atribuído o nome da interface
exterior):
tc qdisc add dev $IFaceExt handle ffff: ingress
O script não configura mais nada nesta interface.
Nos comandos tc class (linhas 02 a 15), o minor number do parâmetro
classid representa por omissão um valor hexadecimal. Já na definição dos
filtros (linhas 41 a 54), o handle correspondente é representado por um número
decimal. Assim, pacotes marcados pela classe 1:11 têm o handle 17 (0x11) e
pacotes marcados pela classe 1:33 têm o handle 51 (0x33). Os outros seguem o
mesmo critério.
79
Os valores dos minor numbers das classes de marcação (linhas 02 a 15) e
portanto dos handles referidos nos filtros, devem ser escolhidos de tal forma
que os quatro bits menos significativos associem-se correctamente às filas
virtuais DP (Drop Priority ou Prioridade de Descarte) das classes AF
correspondentes. Como cada classe AF tem 3 filas virtuais DP (0001b a
0011b), os valores escolhidos vão respectivamente de 0x11 (10001b) a
0x13 (10011b) para a classe AF1, de 0x21 (100001b) a 0x23 (100011b)
para a classe AF2, de 0x31 (110001b) a 0x33 (110011b) e de 0x41
(1000001b) a 0x43 (1000011b) para a classe AF4.
Disciplina raiz no encaminhador de fronteira:
tc qdisc add dev eth0 handle 1:0 root dsmark \
indices 128 default_index 1
Disciplina raiz no encaminhador interior:
tc qdisc add dev eth0 handle 1:0 root dsmark \
indices 128 default_index 1 set_tc_index
Este comando implementa a disciplina DSMARK, responsável pela marcação
(na fronteira) ou avaliação (no interior) do campo DS dos pacotes [SForge].
DSMARK é uma fila classful, e as suas classes são numeradas até ao valor
(indices -1). Neste caso o elemento 1:0 é a fila principal propriamente dita.
Cada uma das potenciais 127 classes pode ser seleccionada como alvo através
de um filtro correspondente, como será exemplificado adiante.
Marcam o valor DSCP; mask=0x3 preserva os bits ECN [RFC3168] do
ToS:
tc class change dev eth0
mask 0x3 value 0x00 #
mask 0x3 value 0xb8 #
mask 0x3 value 0x28 #
parent 1:0 classid 1:1 dsmark \
BE
EF
AF11
As linhas acima exemplificam as definições das classes com os valores que
serão utilizados para marcar o campo DS dos pacotes quando estiverem prestes
a deixar a disciplina de fila para serem enviados à interface de rede. Como já
foi dito, o minor number do parâmetro classid representa por omissão um valor
hexadecimal que deverá ser igualado mais tarde no filtro respectivo para cada
classe. Como também foi dito acima, a escolha destes valores não é aleatória,
sendo condicionada pela utilização da disciplina GRED para as classes AF.
A marcação é feita através da operação:
Novo_DS = (DS_anterior & máscara) | valor
& e | são os operadores binários AND e OR. A máscara utilizada nas classes
acima (0x3) aplica-se a todo o campo ToS e, com este valor, preserva na
marcação os dois bits ECN (Explicit Congestion Notification) [RFC3168]. Os
valores de marcação (parâmetro value) também aplicam-se a todo o campo
ToS e correspondem aos DSCP recomendados para as classes assinaladas nos
comentários (ver tabela 3.3).
80
B LOCOS F UNCIONAIS
Disciplina comum a todas as classes nos encaminhadores interiores:
tc qdisc add dev eth0 handle 2:0 parent 1:0 htb default 1
Este comando acrescenta uma disciplina de filas HTB (Hierarchical Token
Bucket), que permite o empréstimo da largura da banda não utilizada aos fluxos
de tráfego associados às suas classes, evitando desperdícios [Brown]. As
classes cujo parent é esta disciplina terão o parâmetro classid com o formato
2:<minor number>. Por omissão, o tráfego é enviado para a classe 2:1
(parâmetro default).
Segundo Martin Devera, o criador da disciplina HTB (baseando-se no
mecanismo de partilha formal exposto por Sally Floyd em [Floyd95b]), a sua
utilização é preferível relativamente à disciplina CBQ porque esta última
algumas vezes apresenta resultados inconsistentes. Esta opinião foi
posteriormente suportada por simulações e estatísticas reais, pelo próprio
Martin Devera (http://luxik.cdi.cz/~devik/qos/htb/old/htbmeas1.htm) e outros
[RUSU02].
Classe BE nos encaminhadores interiores:
tc class add dev eth0 classid 2:1 parent 2:0 htb \
rate 85Mbit ceil 100Mbit prio 63
tc qdisc add dev eth0 parent 2:1 handle 60 red \
limit 2000KB min 150KB max 450KB burst 250 \
avpkt 1000 bandwidth 100Mbit probability 0.02
Os comandos acima definem o tratamento por omissão para os fluxos de dados
não enviados para outras classes, ou para aqueles fluxos para os quais o
administrador deseje um tratamento compatível com o comportamento
tradicional da Internet (na base do melhor esforço).
Se o ritmo dos dados nesta classe ultrapassar o valor especificado no parâmetro
rate, ela pode iniciar o empréstimo de largura de banda disponível na classe
mãe (linha 16) até ao valor estipulado pelo parâmetro ceil. Assim, mesmo
estando numa classe com garantias inferiores às das outras, o tráfego BE pode
utilizar toda a largura de banda que não estiver já atribuída. O mesmo passa-se
com o tráfego de qualquer das outras classes.
A disciplina de fila associada será identificada com o handle 60 (útil na
visualização e tratamento de estatísticas do tc) e o seu tipo é RED – Random
Early Detection. Este tipo de fila utiliza um procedimento para selecção
aleatória de pacotes a serem marcados para o descarte – ou seja, os pacotes do
fim da fila não têm maior probabilidade de descarte em caso de congestão,
como na disciplina FIFO. Quando a fila RED tiver um total de bytes entre min
e max, a probabilidade máxima de marcação para descarte em qualquer pacote
é de probability (neste caso de 2%); acima de max todos os pacotes são
marcados para descarte.
A relação sugerida (e mais encontrada em implementações reais) entre os
parâmetros min e max é de 1 para 3. O valor do parâmetro limit indica o
limite físico da fila e deve ser algumas vezes maior que max [Floyd95b].
O parâmetro burst indica a quantidade de dados que pode ser enviada em
cada sessão na velocidade máxima do hardware para uma só classe antes de
81
atender outras classes. O valor deste parâmetro nunca deve ser menor na classe
parent (se especificado) e pode basear-se na seguinte relação empírica entre os
outros parâmetros [Balliachi03 2]:
burst = (2*min + max) MOD (3*avpkt)
O parâmetro avpkt é especificado em bytes e ajuda a determinar a constante
de tempo para os cálculos do tamanho médio da fila. Este valor pode ser
ajustado pelo administrador após medições do tamanho médio dos pacotes.
bandwidth é a taxa física da interface e é utilizado para calcular o tamanho
médio da fila após um período sem tráfego.
Classe EF – disciplina FIFO nos encaminhadores interiores:
tc class add dev eth0 parent 2:0 classid 2:2 htb \
rate 150kbit ceil 200kbit prio 1
tc qdisc add dev eth0 parent 2:2 handle 50 pfifo limit 5
Classe AF1 – três filas virtuais com disciplina GRED nos encaminhadores
interiores:
tc class add dev eth0 parent 2:0 classid 2:10 \
htb rate 15Mbit ceil 100Mbit prio 10
tc qdisc add dev eth0 parent 2:10 handle 10 gred \
setup DPs 3 default 1 grio # 3 RED dinâmicas
tc qdisc change dev eth0 parent 2:10 gred \
avpkt 1000 bandwidth 1000kbit DP 1 \ # AF11
probability 0.02 prio 11
Os comandos acima configuram a classe DiffSer AF1 num encaminhador
interior Linux. Esta classe dispõe de três prioridades de descarte realizadas com
três filas RED virtuais. É possível remarcar pacotes entre as filas virtuais de
uma mesma classe AF sem prejudicar a sua sequência. As outras classes AF são
configuradas de forma semelhante.
Filtros para associar os pacotes do com as classes:
tc filter add dev eth0 parent 2:0 protocol ip prio 63
handle 1 tcindex classid 2:1 pass_on
\
Uma série de comandos como o mostrado acima irão criar classificadores para
a classe HTB principal encaminhar os diversos fluxos de tráfego para as classes
DiffServ adequadas, onde será feito o shaping do tráfego no caso dos
encaminhadores interiores. Nos encaminhadores de fronteira, o tráfego é apenas
marcado na interface interna, tendo já sofrido o policiamento na interface
externa.
82
FUNCIONAMENTO INTEGRADO
4.3 Funcionamento Integrado
A figura 4.8 mostra um exemplo das mensagens resultantes de uma acção do
utilizador ou administrador.
Como os TCS são especificados com uma hora de início e outra de fim, a
sinalização da PMT para o PDP é assíncrona em relação à conversação PDP-IU.
As mensagens 6 e 9 são relatórios dos filtros instalados. São enviadas
assíncronamente em relação à instalação dos filtros propriamente dita, e pode
haver um período de tempo (medido em segundos) em que o comando de
instalação já seguiu, mas qualquer interrogação da PMT não mostra o filtro
instalado. Isto é devido ao tempo que a shell demora para responder à
interrogação por filtros, feita periodicamente pelo PEP. O comando inclui
eliminação de entradas duplicadas e edição com ferramentas da shell para que a
resposta seja formatada adequadamente. A solução encontrada foi enviar o
resultado deste comando para um ficheiro, e depois ler o conteúdo do ficheiro.
(1)
<ActualSol>
<tcs>
Interface com
o Utilizador
32881
(2)
Add dn
PMT
(3) dn
added.
(4)
<ActualRsp>
OK
(6)
<Rpt>
389
Repositório
32880
(5)
<criaPolitica>
(7a)
PIB
PEP1
(8a)
System
tc
Kernel
(7b)
PIB
3288
(9a)
PIB
rpt
PDP
PEP2
3288
(9b)
PIB
rpt
(8b)
System
tc
Kernel
Figura 4.8: Funcionamento Integrado da Arquitectura Proposta
As mensagens completas são (os parâmetros estão exemplificados):
01. <ActualSol><tcs><tcsId>Tcs200402</tcsId><slaId>Sla20040
1</slaId><pcimRuleName>TCS_Exemplo</pcimRuleName><pcimT
PCTime>200408301200200409011133</pcimTPCTime><pcimRuleP
riority>7</pcimRulePriority><condicao>tipo_de_endereço
IPv4</condicao><condicao>origem_192.168.2.28</condicao>
<condicao>ritmo_512</condicao><condicao>rajada_20000</c
ondicao><condicao>protocolo_udp</condicao><condicao>por
83
ta_inicial_de_destino_44444</condicao><condicao>porta_f
inal_de_destino_44444</condicao><accao>DESCARTA</accao>
<pcimRuleEnabled>1</pcimRuleEnabled></tcs></ActualSol>
02. Add dn: TcsId=Tcs200402, dc=Acordos de Servico,
dc=CIIST, dc=Instituto Superior Tecnico, dc=pt
03. dn added: TcsId=Tcs200402, dc=Acordos de Servico,
dc=CIIST, dc=Instituto Superior Tecnico, dc=pt
04. <ActualRsp>OK</ActualRsp>
05. <criaPolitica><politica><nome_politica>TCS_Exemplo</nom
e_politica><classificador><clElemento><precedencia>7</p
recedencia><filtroIP><tipoEnd>1</tipoEnd><dstEnd>192.16
8.3.0</dstEnd><dstMask>24</dstMask><srcEnd>192.168.2.28
</srcEnd><srcMask>32</srcMask><protocolo>17</protocolo>
<dstPortaMin>44444</dstPortaMin><dstPortaMax>44444</dst
PortaMax></filtroIP><meter><nome_meter>TCS_Exemplo</nom
e_meter><ritmo>512</ritmo><rajada>20000</rajada><sucess
o>EF</sucesso><falha>DESCARTA</falha></meter></clElemen
to></classificador></politica></criaPolitica>
06. <Rpt><pep><nome_pep>Linax</nome_pep><filtros><nome_inte
rface>eth1</nome_interface><precedencia>34</precedencia
><precedencia>12</precedencia></filtros></pep></Rpt>
07. São enviados os PIB DS_Action, DS_Meter, DS_ILabel,
Frwk_IPFilter, DS_Classifier, DS_ClElement.
08. tc add filter dev eth1 parent ffff: prio 7 u32 match ip
src 192.168.2.28/32 match ip protocol 17 match ip dport
44444 police 512kbit burst 20kbit drop flowid :2
09. É enviado assincronamente o PIB Frwk_DeviceID, com informação sobre
os filtros instalados em cada PEP no campo Descr.
4.4 Limitações do Modelo
A implementação realizada atende apenas a encaminhadores Linux, embora
esta restrição aplique-se somente ao nível inferior da arquitectura proposta
(PEP).
O modelo implementado configura apenas filtros para atributos da tabela PIB
FrwkIpFilterEntry (ver figura 4.3).
O tipo de programação (sem threads) utilizada para o servidor de
aprovisionamento limita fortemente a sua escalabilidade a nível de clientes
PEP. A PMT já não apresenta este problema.
A tolerância a falhas da solução pode ser muito melhorada se as aplicações
escreverem em ficheiros XML os comandos que trocam entre si e com o
repositório LDAP. Em caso de indisponibilidade temporária do PDP, por
exemplo, a PMT pode enviar os comandos quando aquele estiver novamente
ligado. Se falhar o repositório, a PMT poderia aplicar todas as alterações a
partir de um ficheiro com a informação necessária quando possível.
Outro ponto de relevância é a segurança. Não foram implementadas soluções de
encriptação e protecção dos dados, para facilitar o debugging durante a fase de
84
LIMITAÇÕES DO M ODELO
testes. A autenticação é feita de forma básica, não integrada com sistemas
especializados (e.g. RADIUS).
Alterações ao script de configuração com os comandos tc devem ser feitas
manualmente, mas com extremo cuidado. Este script é essencial para o bom
funcionamento da arquitectura e gestão dos filtros nos encaminhadores de
fronteira.
85
5
Testes
5.1 Introdução
Os testes efectuados são divididos em testes funcionais e testes de
desempenho. Este capítulo caracteriza o ambiente utilizado nos testes e
também explica os requisitos específicos para cada situação testada. Procura
analisar os resultados numa perspectiva de obediência aos objectivos propostos.
5.2 Cenário de Testes
Os testes foram realizados numa rede isolada construída para este propósito, na
qual os computadores utilizados têm o mesmo hardware (IBM NetVista 192
MB RAM e placas de rede Realtek RTL 8139) e o mesmo sistema operativo
(Linux Red Hat 9, kernel 2.4.20-8). A figura 5.1 mostra a disposição,
configuração e funções do equipamento para os testes funcionais e de
desempenho.
linox
192.168.3.2
(Repositório
LDAP)
linix
192.168.3.1
eth0
eth1
(encaminhador)
192.168.1.2
eth0
HUB 100 Mbit
PMT &
Monitorização
(tcpdump)
eth0
192.168.1.1
linax
(encaminhador)
eth1
192.168.2.1
eth0
192.168.2.2
linex
(PDP/IU)
Figura 5.1: Ambiente de Testes
Foi decidido utilizar a estação de monitorização para desempenhar as funções
de PMT porque os testes de desempenho são destinados a caracterizar o
funcionamento DiffServ da rede, num momento em que tipicamente a PMT não
vai gerar tráfego porque já criou as configurações necessárias. Esta observação
87
5. TESTES
aplica-se também à utilização de uma só máquina para as funções de PDP e
Interface do Utilizador.
Cada encaminhador teve o papel de encaminhador de fronteira ou interior,
conforme o teste específico. As aplicações foram configuradas para criar
ficheiros de log com data e hora (ao milésimo ou milionésimo de segundo) das
ocorrências.
Um requisito essencial para o bom funcionamento desta aplicação, é que a
configuração das classes DiffServ esteja consistente no repositório e no script
dos encaminhadores.
5.3 Testes Funcionais
5.3.1 Introdução
Os testes funcionais destinam-se a comprovar:
1 – O correcto funcionamento da Interface do Utilizador na visualização,
criação, alteração e remoção de políticas (SLA e TCS).
2 – A efectiva configuração do(s) encaminhador(es) com a configuração de
base e com as políticas (TCS) definidas na Interface do Utilizador.
Para todo o ambiente de testes, foram pré-configuradas no repositório LDAP as
classes de serviço oferecidas, como mostra a figura 5.2. A ferramenta utilizada
para visualizar estas informações foi o utilitário LDAPBrowser.
Figura 5.2: Classes Definidas no Repositório
5.3.2 Configuração dos Encaminhadores
Para o conjunto de testes funcionais, o sistema Linax representou um
encaminhador de fronteira DiffServ, enquanto que o sistema Linix foi
configurado como um encaminhador interior. Estas configurações são
efectuadas no ficheiro /etc/PEP.conf em cada uma das máquinas (ver a
88
TESTES F UNCIONAIS
secção 3.4.6). Quando a aplicação PEP inicializa, lê este ficheiro e lança o
script de configuração tc com os parâmetros adequados.
A figura 5.3 mostra o resultado de executar a aplicação PEP no encaminhador
de fronteira e a configuração respectiva. Foram utilizados comandos da shell
Linux para obter estas informações.
[root@linax /]# cat /etc/PEP.conf
#######################
# Configuração do PEP #
#######################
debug ON
PEPdesc Linax kernel 2.4.20-8
portaPDP 3288
PDPsrv 192.168.2.2
PEPscript /etc/tcscript.sh
PEPtipo fronteira
externa eth1
interna eth0
[root@linax /]# tc qdisc show dev eth0
qdisc dsmark 1: indices 0x0080 default_index 0x0001
qdisc ingress ffff: ----------------
Figura 5.3: Configuração do Encaminhador de Fronteira
A figura 5.4 mostra o resultado de executar a aplicação PEP no encaminhador
interior, juntamente com o ficheiro de configuração.
[root@linax /]# cat /etc/PEP.conf
#######################
# Configuração do PEP #
#######################
debug ON
PEPdesc Linix kernel 2.4.20-8
portaPDP 3288
PDPsrv 192.168.2.2
PEPscript /etc/tcscript.sh
PEPtipo interior
interior eth0
interior eth1
Figura 5.4: Configuração do Encaminhador Interior
Pode-se ver a diferença na configuração da interface externa (eth1) do
encaminhador de fronteira, onde é criada uma disciplina ingress para
direccionar os fluxos de entrada, de forma que sejam correctamente
89
5. TESTES
classificados antes de abandonarem o encaminhador e entrarem no domínio
propriamente dito.
5.3.3 Criação de SLA
A criação e eliminação dos SLA e TCS são operações efectuadas através da
Interface do Utilizador. Esta executa em qualquer máquina ligada à rede que
disponha do ambiente de execução Java.
A figura 5.5 mostra o ecrã de criação de um SLA.
Figura 5.5: Criação de um SLA
Estes testes assumem que um utilizador (User1) deseja obter uma garantia de
largura de banda de até 256 Kbps entre as 10 e as 23 horas e 59 minutos do dia
14 de Setembro de 2004. O administrador decidiu utilizar a classe DiffServ
AF11 para atender a esta solicitação, e criou um SLA com os parâmetros
visualizados na figura. As prioridades utilizadas devem ser geridas pelo
administrador em conjunto com aquelas atribuídas a outros SLA. O facto de
haver uma faixa de prioridades vai permitir que o utilizador crie mais de um
TCS para este SLA, desde que não entrem em conflito e que sejam respeitados
os parâmetros do SLA.
A figura 5.6 permite visualizar o resultado da operação, a nível do repositório.
Além das classes que já existiam, passa a haver também a definição do SLA
criado.
90
TESTES F UNCIONAIS
Figura 5.6: O SLA no Repositório
O XML entre a IU e a PMT para criação do SLA é mostrado na figura 5.7.
2004-09-14 10:04:13.846 >> <ActualSol><sla><dlmDescription>Tráfego
HTTP</dlmDescription><slaUser>User1</slaUser><pcimTPCTime>20040914100
0200409142359</pcimTPCTime><classe>Platina_DP1</classe><ritmo>256</ri
tmo><prioridades>15:20</prioridades><srcDst>192.168.2.0/24:192.168.3.
2/32</srcDst><pcimRuleEnabled>1</pcimRuleEnabled></sla></ActualSol>
Figura 5.7: XML da Criação de um SLA
5.3.4 Criação do TCS
No capítulo 4, a figura 4.2 mostra o ecrã de criação de um TCS na Interface do
Utilizador. Os campos deixados em branco assumem valores por omissão,
geralmente os do SLA. A criação de um TCS reutiliza ou cria diversas
condições e acções no repositório. A figura 5.8 mostra as condições e acções
que foram criadas neste teste, visto não existirem anteriormente.
Figura 5.8: Condições e Acções Criadas no Repositório
91
5. TESTES
Na figura anterior também é visível a entrada referente ao TCS, mostrada em
detalhe na figura 5.9.
Figura 5.9: Atributos do TCS no Repositório
O XML utilizado para criar o TCS pode ser visto na figura 5.10.
2004-09-14 10:17:07.408 >>
<ActualSol><tcs><slaId>Sla040914100413</slaId><pcimRuleName>Tráfego
HTTP</pcimRuleName><pcimTPCTime>200409141000200409142359</pcimTPCTime
><pcimRuleEnabled>4</pcimRuleEnabled><pcimRulePriority>15</pcimRulePr
iority><condicao>origem 192.168.2.0</condicao><condicao>bits
significativos_na_origem_24</condicao><condicao>destino_192.168.3.2</
condicao><condicao>bits_significativos_no_destino_32</condicao><condi
cao>protocolo_tcp</condicao><condicao>porta_inicial_de_origem_80</con
dicao><condicao>porta_final_de_origem_80</condicao><accao>ritmo_desej
ado 256</accao><accao>classe_QdS_(pacotes_no_perfil)_AF11</accao>
<accao>pacotes fora de perfil REMARCA</accao></tcs></ActualSol>
Figura 5.10: XML da Criação de um TCS
Ao nível dos encaminhadores, a criação de um TCS afecta a interface externa
do encaminhador de fronteira (no caso a interface eth1 da máquina Linax). O
comando enviado pela aplicação PEP para a shell Linux é visível na figura
5.11.
Tue Sep 14 10:17:473816 2004 >> tc filter add dev eth1 parent ffff:
protocol ip prio 15 u32
match ip src 192.168.2.0/24 match ip dst
192.168.3.2/32 match ip protocol 6 0xff
match ip sport 80 0xFFFF
police rate 256kbit burst 20k continue flowid :11
Figura 5.11: Comando tc Enviado para a Shell Linux
Através de um comando tc na shell do encaminhador, podemos solicitar o
relatório dos filtros instalados por interface, como mostra a figura 5.12.
92
TESTES F UNCIONAIS
[root@linax /]# tc filter show dev eth1 root
filter parent ffff: protocol ip pref 15 u32
filter parent ffff: protocol ip pref 15 u32 fh 800: ht divisor 1
filter parent ffff: protocol ip pref 15 u32 fh 800::800 order 2048
key ht 800 bkt 0 flowid :11
police 8 action continue rate 256Kbit burst 20Kb mtu 2Kb
match c0a80302/ffffffff at 12
match c0a80200/ffffff00 at 16
match 00060000/00ff0000 at 8
match 00500000/ffff0000 at 20
Figura 5.12: Relatório de Filtros no Encaminhador de Fronteira
5.3.5 Efeito do TCS no Transporte de Pacotes
O TCS foi configurado com uma hora de início anterior à actual, e assim
resultou imediatamente na aplicação do respectivo filtro tc no encaminhador
de fronteira. Através da aplicação Ethereal, capturamos o tráfego no troço entre
os dois encaminhadores e constatámos que a política desejada estava funcional,
como mostra a figura 5.13.
Figura 5.13: Análise de um Pacote Capturado
Pode-se ver na figura anterior que um pacote com origem na porta 80 do
servidor 192.168.2.2, destinado à rede 192.168.3.0, foi marcado com DSCP
igual a AF11, que corresponde à classe Platina DP1 na aplicação.
5.3.6 Eliminação de TCS
A eliminação de um TCS activo implica também na remoção da política
configurada nos encaminhadores de fronteira. Esta análise é feita pela PMT, a
qual envia os comandos de remoção de política para o PDP, se necessário. A
remoção de uma política, por restrições do comando tc do Linux, é feita
através da designação da sua prioridade. Isto deve ser levado em consideração
93
5. TESTES
tanto pelo administrador quanto pelos utilizadores na configuração dos SLA e
dos TCS.
A eliminação de um TCS não elimina do repositório as condições e acções que
foram utilizadas por ele. Elas poderão servir para outra política futuramente.
O XML entre a Interface do Utilizador e a PMT para remoção de um TCS é
mostrado na figura 5.14.
2004-09-14 11:11:22.769 >>
<DelSol><tcs><tcsId>Tcs040914105819</tcsId></tcs></DelSol>
Figura 5.14: XML para Remoção de um TCS
As tabelas PIB recebidas pelo PEP e o comando para remoção do TCS enviado
para a shell Linux podem ser visualizados na figura 5.15.
Tue Sep 14 11:11:841392 2004 >> handle_packet: received COPS message:
Decision (DEC)
handle_dec: COPS-PR Decision with Command Code 1
DsClfrElementEntry.1: (1.1.2.3.1.1)
dsClfrElementPrid=1073894052
dsClfrElementClfrId=1
dsClfrElementPrecedence=1015
dsClfrElementNext= (1.2.3.4.1)
dsClfrElementSpecific= (1.2.3.4.1)
DsClfrEntry.1: (1.1.2.2.1.1)
dsClfrPrid=1073894072
dsClfrId=1
DsActionEntry.1: (1.1.2.6.1.1)
dsActionPrid=1073893992
dsActionNext= (1.2.3.4.1)
dsActionSpecific= (1.2.3.4.1)
FrwkILabelFilterEntry.1: (1.2.3.4.1.1)
frwkILabelFilterILabel=
Tue Sep 14 11:11:841727 2004 >> tc filter del dev eth1 root pref
15 > fich2 2> fich2 &
Figura 5.15: Remoção de um TCS no PEP
A indicação de que se trata de uma remoção, e qual a política a remover é dada
pelo atributo dsClfrElementPrecedence no elemento classificador.
5.4 Testes de Desempenho
5.4.1 Introdução
Os testes de desempenho têm um conjunto de requisitos para maior fiabilidade:
94
TESTES DE D ESEMPENHO
1 – A rede de testes está isolada e não há aplicações não essenciais em
operação.
2 – Os relógios de todos os computadores envolvidos nos testes devem estar
sincronizados com o NTP (Network Time Protocol). Como se trata de uma rede
isolada, um dos computadores foi escolhido como servidor NTP de referência,
e os outros ajustam o seu relógio por ele.
3 – As medidas relativas ao desempenho do tráfego devem ser efectuadas por
uma estação não participativa neste mesmo tráfego. Caso seja utilizado um
switch para ligação das máquinas, é necessário configurar a porta da estação de
monitorização para que consiga capturar os pacotes das conversações entre os
outros sistemas. A rede de testes utilizou um hub 10/100, que não requer
configuração.
5.4.2 Desempenho das Aplicações
O desempenho da Interface com o Utilizador apresenta as limitações típicas de
uma aplicação gráfica em Java. Após a validação do utilizador, o número de
SLA e TCS a serem apresentados condiciona fortemente o tempo de resposta
para visualização do próximo ecrã. O maior impacto é sentido pelo
administrador, que recebe todos os SLA e TCS configurados no repositório.
Tipicamente, um utilizador terá um SLA e poucos TCS a receber. Neste último
caso, o tempo de resposta médio obtido foi de 1,973 segundos para um SLA e
um TCS.
A criação e remoção de TCS apresentou um tempo de resposta também
próximo dos 2 segundos (2,191 segundos), beneficiando-se do facto de as
operações com o PDP (e deste para o PEP) serem efectuadas de forma
assíncrona relativamente ao tráfego IU-PMT.
5.4.3 Policiamento na Interface Externa
Na arquitectura proposta, o encaminhador de fronteira faz um condicionamento
inicial do tráfego e também a marcação dos pacotes que entram no domínio. Os
encaminhadores interiores utilizam a marcação para fazer o shaping por classe
DiffServ. Foi utilizada a máquina Linax como encaminhador de fronteira e a
máquina Linix como encaminhador interior. Esta última teve desactivada a
configuração DiffServ na maioria dos testes relativos aos policiadores, para não
interferir nos resultados. O comando para desactivar as disciplinas de fila numa
interface do sistema Linux é: tc qdisc del dev <interface> root.
Estes testes foram efectuados através da execução na máquina Linex de um
script para enviar comandos ping aos outros segmentos de rede, com a opção de
flooding activada. Esta opção envia pings com a velocidade permitida pela
interface de rede.
Os resultados obtidos sem condicionamento são mostrados na figura 5.16. O
acesso ao sistema Linox passa por mais um encaminhador, portanto é
penalizado em relação à troca de mensagens com o sistema Linix (embora não
muito).
95
5. TESTES
PING linox.rede.pt (192.168.3.2) 56(84) bytes of data.
PING linix.rede.pt (192.168.1.2) 56(84) bytes of data.
--- linix.rede.pt ping statistics --2000 packets transmitted, 2000 received, 0% packet loss, time 1019ms
rtt min/avg/max/mdev = 0.122/0.127/0.281/0.015 ms, pipe 2, ipg/ewma 0.510/0.127 ms
--- linox.rede.pt ping statistics --2000 packets transmitted, 1998 received, 0% packet loss, time 1082ms
rtt min/avg/max/mdev = 0.179/0.186/0.439/0.012 ms, ipg/ewma 0.541/0.182 ms
Figura 5.16: Comandos ping sem Condicionamento
De seguida, foi criado com a Interface do Utilizador, um TCS para condicionar
o tráfego ICMP entre a máquina Linex e a rede 192.168.3.0 (onde encontra-se a
máquina Linox). O valor para largura de banda foi limitado a 50 Kbps, na
classe Diamante (EF) com descarte para os pacotes fora de perfil. Após
verificar que a política tinha sido implementada no PEP de fronteira, o script
anteriormente utilizado foi novamente executado com os resultados visíveis na
figura 5.17 .
PING linix.rede.pt (192.168.1.2) 56(84) bytes of data.
--- linix.rede.pt ping statistics --2000 packets transmitted, 2000 received, 0% packet loss, time 1635ms
rtt min/avg/max/mdev = 0.181/0.236/0.448/0.052 ms, pipe 2, ipg/ewma 6.872/0.241 ms
Figura 5.17: Comandos ping com Condicionamento
Uma repetição sistemática destes testes indica que os valores aqui exibidos são
representativos do comportamento médio em cada caso. A monitorização do
troço entre os encaminhadores Linax e Linix demonstrou que todo o
condicionamento e descarte de pacotes foi efectuado pelo filtro aplicado à
interface externa do encaminhador de fronteira.
A comparação entre os resultados apresentados na figura 5.16 e os resultados
da figura 5.17 mostra que a activação do TCS resultou na perda e atraso
selectivo dos pacotes destinados ao sistema Linox, em benefício do tráfego de
pacotes para o sistema Linix.
Foi efectuado um estudo mais abrangente do policiamento, com a configuração
de filtros com várias larguras de banda. A tabela 5.1 indica os valores obtidos
para diversas execuções do mesmo script de teste, com alteração da largura de
banda configurado no policiador. A figura 5.18 ilustra estes mesmos resultados
em um gráfico. Foi considerado apenas o fluxo de tráfego afectado (ping para
Linox).
Os resultados destes testes indicam qualitativamente que o policiamento está a
actuar como suposto. Uma análise quantitativa só pode ser elaborada de
maneira superficial, a menos que seja utilizado hardware adequado para
geração de tráfego e medição da largura de banda.
96
Largura de
Banda
(Kbps)
Tempo
Total
(s)
Perdas
(%)
rtt
médio
(ms/10)
25
50
75
100
125
150
175
200
225
250
275
400
500
19,614
13,738
10,440
8,556
7,152
6,244
5,554
4,921
4,430
4,107
3,782
2,800
2,795
48
32
24
19
15
13
10
10
8
7
6
1
0
27,0
23,6
22,3
21,9
21,7
21,0
20,9
20,8
20,7
20,5
20,5
20,3
20,0
Tabela 5.1: Policiamento com Diversas Larguras de Banda
Policiamento do Tráfego
50
40
Tempo (s)
30
Perdas (%)
20
rtt médio (ms/10)
10
0
25
50
75 100 125 150 175 200 225 250 275
Largura de Banda
Figura 5.18: Policiamento do Tráfego
O tamanho do pacote tem grande influência nos resultados, como pode ser
visto na tabela 5.2.
Largura de
Banda
(Kbps)
Perdas
(84
bytes)
Perdas
(1028
bytes)
100
200
300
400
500
19%
10%
3%
1%
0%
79%
66%
56%
49%
43%
Tabela 5.2: Policiamento com Diversas Larguras de Banda
97
5. TESTES
5.4.4 Condicionamento no Encaminhador Interior – Classe
Única
Para obter resultados do condicionamento no encaminhador interior, os filtros
configurados na interface externa do encaminhador de fronteira não podem
restringir demasiado a largura de banda. Contrariamente, a configuração das
classes DiffServ no encaminhador interior será alterada para valores mais
baixos de largura de banda na classe desejada.
Aqui, dispomos de dois pontos de obtenção dos resultados: a aplicação
utilizada (ping, wget, etc.) pode reportar as estatísticas como nos testes da
secção anterior, e o próprio encaminhador interior, através de um comando tc,
mostra as estatísticas de utilização das classes e filas configuradas.
O TCS utilizado para configuração do policiamento de fronteira foi sempre o
mesmo, enviando todo o tráfego ICMP entre Linex e Linox para a classe AF21
até ao limite de 10 Mbps. Foram utilizados pacotes de 1028 bytes, porque os
descartes são mais facilmente forçados.
A classe AF2 e a sua prioridade de descarte DP1 utilizam no script a
configuração mostrada na figura 5.19.
# AF 2 especifico
tc class add dev $INTERFACE parent 2:1 classid 2:20 htb rate 15000Kbit ceil 100Mbit
tc qdisc add dev $INTERFACE parent 2:20 handle 20 gred setup DPs 3 default 2 grio
# AF 2 DP 1
tc qdisc change dev $INTERFACE parent 2:20 gred limit 2000KB min 150KB max 450KB
burst 250 \
avpkt 1000 bandwidth 100Mbit DP 1 probability 0.02 prio 2
Figura 5.19: Configuração da Classe AF2
Com esta configuração, o teste ping teve o resultado mostrado na figura 5.20,
onde foram incluídos os resultados colhidos no encaminhador e na origem dos
dados.
Estatisticas AF2 na interface eth1 - LINIX
qdisc gred 20:
DP:1 (prio 2) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 2000 (bytes 2084000) ewma 7 Plog 24 Scell_log 9
Figura 5.20: Resultados com Configuração Padrão
Os testes simulam a partilha da largura de banda com outros fluxos, através da
alteração do parâmetro ceil na classe AF2. Ou seja, o fluxo marcado como
AF2 fica com uma largura de banda limitada pelo encaminhador interior.
A tabela 5.3 mostra os resultados para diversos valores de ceil. As perdas
relativas a valores de ceil acima de 400 Kbps não foram reportadas como
98
descartes pelo tc, e o mais provável é deverem-se à sobrecarga dos buffers nas
diversas máquinas por onde passa o fluxo.
ceil (Kbps)
Perdas (%)
Tempo (s)
50
100
200
300
400
500
600
700
800
900
1000
1100
1200
1500
2000
3000
4000
70
58
38
16
1
1
0
1
1
1
0
1
0
0
1
0
1
35,165
31,920
32,278
33,880
33,530
32,429
27,038
23,186
20,278
18,042
16,248
14,773
13,541
10,839
8,160
5,475
4,334
Tabela 5.3: Perdas e Tempos de Transmissão para a Classe AF21
A figura 5.21 ilustra uma situação de descarte de pacotes reportada pelo tc no
encaminhador interior, para um valor de ceil igual a 100 Kbps.
Estatisticas AF2 na interface eth1 – LINIX
qdisc gred 20:
Sent 870070 bytes 835 pkts (dropped 1165, overlimits 1165)
Figura 5.21: Descarte de Pacotes AF21
5.4.5 Condicionamento no Encaminhador Interior – Três Classes
No funcionamento normal da arquitectura proposta, os TCS para as classes
Bronze DP2 a Platina DP1 podem especificar a remarcação dos pacotes ao
invés do descarte. Nesta situação, o agente PEP cria filtros adicionais que
permitem a remarcação dentro da mesma classe para outra prioridade de
descarte.
Neste teste é criado um TCS na classe de serviço Prata DP1 (AF31) com
limitação da largura de banda a 50 Kbps, e especificação de remarcação dos
99
5. TESTES
pacotes fora deste perfil. A figura 5.22 mostra os comandos tc enviados pelo
agente PEP para a shell do encaminhador de fronteira.
tc filter add dev eth1 parent ffff: protocol ip prio 31 u32 match ip
src 192.168.2.2/32 match ip dst 192.168.3.0/24 match ip protocol 1
0xff police rate 50kbit burst 20k continue flowid :1f
0xff police rate 50kbit burst 20k continue flowid :20
0xff police rate 50kbit burst 20k drop flowid :21
Figura 5.22: Policiador AF31 com Remarcação para AF32 e AF33
Foi utilizado um valor de largura de banda suficientemente baixo (50 Kbps)
para forçar a remarcação dos pacotes mais pequenos (84 bytes). A figura 5.23
permite comparar os resultados obtidos com pacotes pequenos, médios (528
bytes) e grandes (1028 bytes). Novamente, os pacotes maiores ultrapassam mais
facilmente o perfil e são mais penalizados que os pacotes de menor dimensão.
## Police 50 K Classes AF31 -> AF32 -> AF33 ##
rtt min/avg/max/mdev = 0.184/0.219/0.666/0.041 ms, ipg/ewma
2.327/0.222 ms
11.100/0.577 ms
14.299/0.929 ms
Figura 5.23: Resultados dos Testes para Diferentes Tamanhos de Pacotes
Os relatórios de utilização das classes no encaminhador de fronteira são
mostrados na figura 5.24. Os descartes não aconteceram aqui, foram de inteira
responsabilidade do policiador na interface externa do encaminhador de
fronteira.
Outro ponto de interesse a notar é que foi enviado um número igual de pacotes
para cada classe no caso dos pacotes maiores, e números semelhantes, mas
diferentes, no caso de pacotes menores. Este comportamento indica que há um
factor de incerteza no tratamento dos pacotes, tanto mais elevado quanto menor
o tamanho daqueles, porque os tempos entre pacotes passam a ser mais
100
relevantes, assim como o overhead do processo de tratamento de cada pacote
individual.
## Police 50 Kbps ##
## Pacotes 84 bytes ##
Estatisticas AF3 na interface eth1
qdisc gred 30:
qdisc gred 30:
Packet totals: 307 (bytes 166394) ewma 7
Sent 497556 bytes 918 pkts (dropped 0, overlimits
Plog 24 Scell_log 9
Plog 23 Scell_log 9
Plog 23 Scell_log 9
0)
qdisc gred 30:
Figura 5.24: Utilização das Prioridades de Descarte AF3
101
5. TESTES
5.4.6 Desempenho do Tráfego Condicionado nas Sub-Redes
Este teste mostra como os pacotes são afectados desde o início do tráfego, até
chegarem ao seu destino, passando por um encaminhador de fronteira e por um
encaminhador interior. Estão envolvidas três sub-redes, nas quais foram feitas
medições simultâneas. O tráfego consistiu de pacotes ICMP com 200 bytes
entre as máquinas Linex e Linox. Apenas foi condicionado e avaliado o tráfego
com origem na máquina Linex.
O comando utilizado foi ping –f –c 2000 –s 200 linox e a figura
5.25 mostra os resultados da sua execução na máquina Linex, antes e após
condicionar o tráfego.
## Sem condicionamento ##
## Com condicionamento EF Largura de Banda 200 Kbps ##
Figura 5.25: Execução do ping
A tabela 5.4 mostra os resultados da captura de tráfego não condicionado nas
três sub-redes, indicando o número de pacotes transportados a intervalos de 200
milissegundos medidos na origem do tráfego. A sub-rede 2.0 é a origem dos
dados, a sub-rede 3.0 é o destino dos dados e a sub-rede 1.0 é o troço entre os
dois encaminhadores.
Tempo (ms)
200
400
600
800
1000
1200
1400
1600
1800
2000
2200
2400
Total
Sub-Rede
2.0
148
181
172
183
185
187
179
185
187
183
172
38
2000
Sub-Rede
1.0
148
181
172
182
186
187
179
185
187
183
171
39
2000
Sub-Rede
3.0
148
180
172
183
186
185
179
187
185
184
172
39
2000
Tabela 5.4: Desempenho do Tráfego não Condicionado
102
As diferenças observadas devem-se apenas ao tempo de propagação dos pacotes
e possivelmente a algum factor aleatório relacionado com o hardware.
Após realizar as medições sem condicionamento, foi criado um TCS para
policiar e classificar os pacotes ICMP entre os sistemas Linex e Linox na classe
DiffServ EF com largura de banda máxima igual a 200 Kbps. Também foi
alterado o parâmetro ceil da classe EF no script de configuração tc para o
mesmo valor. Os pacotes transportados a cada segundo em cada sub-rede foram
contados e o resultado é mostrado na tabela 5.5. Os intervalos são medidos em
segundos e não em milissegundos devido ao maior tempo de duração do teste, e
foram utilizados mais intervalos que no teste anterior para uma melhor
caracterização das diferenças para o tráfego condicionado.
Tempo
(s)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Total
Sub-Rede Sub-Rede Sub-Rede
2.0
1.0
3.0
118
117
115
106
107
106
105
105
104
110
110
113
106
106
105
105
105
104
107
107
105
105
105
106
111
111
114
106
106
106
108
108
106
105
105
104
106
106
105
107
107
107
105
105
105
110
110
113
106
106
105
105
105
104
69
69
72
2000
2000
1999
Tabela 5.5: Desempenho do Tráfego Condicionado
Os resultados indicam que o verdadeiro policiamento e shaping (retardo
selectivo) foram efectuados no encaminhador de fronteira, e o fluxo de tráfego
foi pouco afectado pelos limites das classes no encaminhador interior. O pacote
que falta na sub-rede 3.0 foi efectivamente descartado pelo encaminhador
interior, que tinha pouca margem de manobra devido à igualdade entre o ceil
configurado para a classe EF e o ritmo do policiamento à entrada. Também
pode ser deduzido destes testes que o aumento do número de encaminhadores
interiores utilizados teria influência no jitter (variação de atraso dos pacotes),
mesmo na classe EF, embora pouco (o último valor para quantidade de pacotes
na sub-rede 3.0 aumentou ligeiramente comparado com os últimos valores das
outras sub-redes). O administrador deve levar isto em consideração ao
configurar os valores do parâmetro ceil para as diversas classes DiffServ.
103
6
Conclusões e Trabalho Futuro
A gestão das políticas de qualidade de serviço numa rede de computadores
pode ser implementada em conjunto com a arquitectura DiffServ definida pelo
IETF para facilitar e tornar consistente a configuração dos encaminhadores de
fronteira e dos encaminhadores interiores da rede. Este modelo conjunto
permite uma separação entre a definição de alto nível das políticas armazenadas
em um repositório, e as especificadades técnicas da sua implementação nos
encaminhadores. Outro benefício derivado do armazenamento das políticas num
repositório, é a possibilidade de reutilização dos seus elementos sem
necessidade de os redefinir ou armazenar de forma redundante.
A utilização das tabelas virtuais PIB e dos protocolos COPS e COPS-PR para
aprovisionamento de políticas tem a vantagem (para além da separação entre
definições de políticas de alto nível e políticas de baixo nível) de poder atender
a outros serviços diferentes do DiffServ, com requisitos diversos de
aprovisionamento, tais como IPSec, load balancing e contabilização da
utilização de recursos.
A solução implementada, embora limitada ao nível das condições e acções de
filtragem dos pacotes, demonstra a viabilidade e utilidade da arquitectura em
que se baseia e a possibilidade de desenvolvimento desta arquitectura com base
em tecnologias abertas estabelecidas ou em processo de estabelecimento. A
utilização do XML como linguagem de transporte das políticas de alto nível foi
fundamental neste contexto, permitindo uma integração facilitada e consistente
dos módulos envolvidos. O protocolo LDAP mostrou-se adequado para a
construção do repositório, tanto pela facilidade de implementação do schema
como pela simplicidade da interface das livrarias JLDAP. A linguagem Java
utilizada no desenvolvimento da Interface com o Utilizador e da PMT, pôde ser
directamente comparada com a linguagem C, utilizada na adaptação dos
códigos disponíveis para PDP e PEP, com vantagens para o Java na curva de
aprendizagem e disponibilidade de códigos exemplo, além de maior
simplicidade das API de acesso à rede. Os programas escritos em linguagem C
caracterizam-se por uma maior eficiência de execução.
Foi especialmente proveitosa para este trabalho a abrangência da
implementação DiffServ no kernel dos sistemas Linux, e a sua facilidade de
utilização e configuração – embora a documentação de muitas características
não seja especialmente abundante ou fácil de localizar.
Sentimos especial dificuldade na realização do conjunto de “políticas de alto
nível” disponibilizadas para o utilizador. A análise na secção 2.2.2 permite
perceber que definições pouco técnicas implicam numa maior complexidade e
inteligência da solução implementada. Nossa abordagem “cria” uma linguagem
de definição de políticas através do XML e usa termos menos técnicos na
apresentação das especificações de SLA e TCS ao utilizador. No preenchimento
das especificações para um novo TCS, o utilizador tem ainda a possibilidade de
deixar em branco muitos dos campos que serão preenchidos automaticamente
pela aplicação, ou simplesmente ignorados.
105
6. CONCLUSÕES E TRABALHO FUTURO
A entrada em produção da implementação proposta deve ficar condicionada a
testes de funcionalidades e fiabilidade do modelo e de cada aplicação
individual na rede onde for operar.
Dentre as possíveis evoluções deste trabalho, pensamos serem relevantes
intervenções nas aplicações PDP e PEP para utilizarem completamente as
especificações actuais da arquitectura DiffServ, o desenho de módulos PEP
para outros tipos de encaminhadores e uma definição mais completa e
abrangente das políticas de alto nível de forma a atender solicitações não
previstas neste trabalho (por exemplo, integração com módulos para reconhecer
e filtrar certos tipos de tráfego). Na aplicação PMT, uma vez que já está
programado um mecanismo para obter um relatório dos filtros instalados nos
PEP, um melhoramento importante seria a comparação desta informação com a
informação das políticas contidas no repositório, de forma a garantir a todo
momento, a consistência da configuração nos encaminhadores de fronteira. Na
aplicação Interface com o Utilizador, poderiam existir facilidades de
visualização e configuração da largura de banda disponível em cada uma das
classes de serviço configuradas. Finalmente, é desejável o desenvolvimento de
um ambiente de testes completo para ajustar os parâmetros de configuração das
diversas disciplinas de fila no Linux, de modo a utilizar os valores mais
adequados para domínios específicos.
Também são importantes futuras actualizações tecnológicas para que o modelo
não fique ultrapassado relativamente ao trabalho dos organismos normativos.
Um exemplo é a utilização de schema ao invés de DTD para as definições
XML, outro é a actualização das livrarias PIB com as definições mais recentes
do IETF.
106
A. Ficheiros de validação DTD
A.1 Instalação de Políticas (PMT >> PDP)
<!ELEMENT criaPolitica (politica*)>
<!ELEMENT politica (nome_politica, classificador)>
<!ELEMENT nome_politica (#PCDATA)>
<!ELEMENT classificador (clElement)>
<!ELEMENT clElement (ipFilter, meter)>
<!ELEMENT ipFilter (tipoEnd, dstEnd, srcEnd, dstMask, srcMask,
dscp, flow, proto, dstPortaMin, dstPortaMax,
srcPortaMin, srcPortaMax)>
<!ELEMENT tipoEnd (#PCDATA)>
<!ELEMENT dstEnd (#PCDATA)>
<!ELEMENT srcEnd (#PCDATA)>
<!ELEMENT dstMask (#PCDATA)>
<!ELEMENT srcMask (#PCDATA)>
<!ELEMENT dscp (#PCDATA)>
<!ELEMENT flow (#PCDATA)>
<!ELEMENT proto (#PCDATA)>
<!ELEMENT dstPortaMin (#PCDATA)>
<!ELEMENT dstPortaMax (#PCDATA)>
<!ELEMENT srcPortaMin (#PCDATA)>
<!ELEMENT srcPortaMax (#PCDATA)>
<!ELEMENT meter (nome_meter, ritmo, rajada, intervalo, sucesso, falha>
<!ELEMENT nome_meter (#PCDATA)>
<!ELEMENT ritmo (#PCDATA)>
<!ELEMENT rajada (#PCDATA)>
<!ELEMENT intervalo (#PCDATA)>
<!ELEMENT sucesso (#PCDATA)>
<!ELEMENT falha (#PCDATA)>
107
A. FICHEIROS DE VALIDAÇÃO DTD
A.2 Relatório de Filtros (PDP >> PMT)
<!ELEMENT Rpt (pep*)>
<!ELEMENT pep (nome_pep, filtros)>
<!ELEMENT nome_pep (#PCDATA)>
<!ELEMENT filtro (interface*)>
<!ELEMENT interface (nome_interface, precedencia*)>
<!ELEMENT nome_interface (#PCDATA)>
<!ELEMENT precedencia (#PCDATA)>
A.3 Remoção de Políticas (PMT >> PDP)
<!ELEMENT rmPolitica (clElement*)>
<!ELEMENT clElement (precedencia*)>
<!ELEMENT precedencia (#PCDATA)>
108
B. O Schema de Políticas LDAP
#
#
#
#
#
#
#
SLAD_TCS Schema
Mestrado: Politicas de Qualidade de Servico no IST
Instituto Superior Tecnico, Lisboa, 2004
Laercio Cruvinel
Este esquema tem como requisitos os
esquemas CIM_core e Policy_core
B.1 Atributos
attributetype ( 6.6.6.1 NAME 'slaId'
DESC 'Identificacao do SLA.'
EQUALITY octetStringMatch
ORDERING octetStringOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
attributetype ( 6.6.6.2 NAME 'slaUser'
DESC 'Identificacao do SLA.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
attributetype ( 6.6.6.3 NAME 'classe'
DESC 'Classe de Serviço: Diamante (EF),
PlatinaDPx (AF11 a AF13), OuroDPx (AF21 a AF23),
PrataDPx (AF31 a AF33), BronzeDPx (AF41 a AF43).'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
attributetype ( 6.6.6.4 NAME 'ritmo'
DESC 'Ritmo maximo (ex. 500kbit ou 2mbit).'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
attributetype (6.6.6.5 NAME 'prioridades'
DESC 'Prioridades inicial e final do SLA na forma iiifff.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
attributetype (6.6.6.6 NAME 'srcDst'
DESC 'Enderecos origem e destino do SLA na forma
<src/mask>:<dst/mask>.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
attributetype (6.6.6.7 NAME 'classeDS'
DESC 'Classe DiffServ: BE, EF, AF11 a AF13,
AF21 a AF23, AF31 a AF33, AF41 a AF43'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
attributetype ( 6.6.6.10 NAME 'tcsId'
DESC 'Identificacao do TCS.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
109
B. O SCHEMA DE POLÍTICAS LDAP
B.2 Classes
objectclass ( 7.7.7.1 NAME 'ServiceLevelAgreement'
DESC 'SLA - Parametros do Acordo de Servico.'
SUP pcimPolicy
STRUCTURAL
MUST (dlmDescription $ slaId $ pcimTPCTime $
slaUser $ classe $ ritmo $ prioridades $
srcDst $ pcimRuleEnabled) )
objectclass (7.7.7.2 NAME 'TrafficConditioningSpecification'
DESC 'TCS - Parametros para condicionamento do trafego.'
SUP pcimRule
STRUCTURAL
MUST ( pcimRuleName $ tcsId $ slaId $ pcimTPCTime $
pcimRuleConditionList $ pcimRuleActionList $
pcimRulePriority $ pcimRuleEnabled))
objectclass ( 7.7.7.3 NAME 'Condicao'
DESC 'Condicao reutilizavel para as regras.'
SUP top
STRUCTURAL
MUST ( pcimConditionName ) )
objectclass ( 7.7.7.4 NAME 'Accao'
DESC 'Accao reutilizavel para as regras.'
SUP top
STRUCTURAL
MUST ( pcimActionName ) )
objectclass ( 7.7.7.5 NAME 'ClasseQdS'
DESC 'Parametros das diversas classes DiffServ.'
SUP top
STRUCTURAL
MUST ( classe $ classeDS $ ritmo ) )
110
C. PIB – Policy Information Base
São apresentadas as tabelas PIB utilizadas neste trabalho, como definidas na
livraria original.
C.1 Tabelas de Identificação e Capabilities
1. Identificação do PEP
/* creates a new pib_table of type 'FRWK_DEVICE_ID_ENTRY' */
pib_table *create_pib_FrwkDeviceIdEntry (
const uint32_t frwkDeviceIdPrid,
const octet_string_t frwkDeviceIdDescr,
const uint32_t frwkDeviceIdMaxMsg,
const uint32_t frwkDeviceIdMaxContexts,
const uint32_t instance)
2. Funcionalidades do PEP
/* creates a new pib_table of type 'FRWK_CAPABILITY_SET_ENTRY' */
pib_table *create_pib_FrwkCapabilitySetEntry (
const uint32_t
frwkCapabilitySetPrid,
const octet_string_t
frwkCapabilitySetName,
const uint32_t
*
frwkCapabilitySetCapability,
const uint32_t
instance)
3. Suporte do PEP às Provisioning Classes (PRC)
/* creates a new pib_table of type 'FRWK_PRC_SUPPORT_ENTRY' */
pib_table *create_pib_FrwkPrcSupportEntry (
const uint32_t frwkPrcSupportPrid,
const uint32_t * frwkPrcSupportSupportedPrc,
const octet_string_t frwkPrcSupportSupportedAttrs,
C.2 Tabelas para Manipulação de Políticas
4. Marcador do Fluxo (não marcamos o DSCP na entrada)
/* creates a new pib_table of type 'FRWK_I_LABEL_FILTER_ENTRY' */
pib_table *create_pib_FrwkILabelFilterEntry (
const octet_string_t frwkILabelFilterILabel,
5. Filtro IP
/* creates a new pib_table of type 'FRWK_IP_FILTER_ENTRY' */
pib_table *create_pib_FrwkIpFilterEntry (
const int32_t frwkIpFilterAddrType,
const octet_string_t frwkIpFilterDstAddr,
const uint32_t frwkIpFilterDstPrefixLength,
const octet_string_t frwkIpFilterSrcAddr,
const uint32_t frwkIpFilterSrcPrefixLength,
const int32_t frwkIpFilterDscp,
const uint32_t frwkIpFilterFlowId,
const uint32_t frwkIpFilterProtocol,
const uint32_t frwkIpFilterDstL4PortMin,
const uint32_t frwkIpFilterDstL4PortMax,
111
C. PIB – POLICY INFORMATION BASE
const uint32_t frwkIpFilterSrcL4PortMin,
const uint32_t frwkIpFilterSrcL4PortMax,
6. Tabela de Acções
/* creates a new pib_table of type 'DS_ACTION_ENTRY' */
pib_table *create_pib_DsActionEntry (
const uint32_t dsActionPrid,
const uint32_t * dsActionNext,
const uint32_t * dsActionSpecific,
7. Tabela de Descarte
/* creates a new pib_table of type 'DS_ALG_DROP_ENTRY' */
pib_table *create_pib_DsAlgDropEntry (
const uint32_t dsAlgDropPrid,
const int32_t dsAlgDropType,
const uint32_t * dsAlgDropNext,
const uint32_t * dsAlgDropQMeasure,
const uint32_t dsAlgDropQThreshold,
const uint32_t * dsAlgDropSpecific,
8. Tabela de Classificador
/* creates a new pib_table of type 'DS_CLFR_ENTRY' */
pib_table *create_pib_DsClfrEntry (
const uint32_t dsClfrPrid,
const uint32_t dsClfrId,
9. Tabela de Elemento Classificador
/* creates a new pib_table of type 'DS_CLFR_ELEMENT_ENTRY' */
pib_table *create_pib_DsClfrElementEntry (
const uint32_t dsClfrElementPrid,
const uint32_t dsClfrElementClfrId,
const uint32_t dsClfrElementPrecedence,
const uint32_t * dsClfrElementNext,
const uint32_t * dsClfrElementSpecific,
10. Tabela de Medidor
/* creates a new pib_table of type 'DS_METER_ENTRY' */
pib_table *create_pib_DsMeterEntry (
const uint32_t dsMeterPrid,
const uint32_t * dsMeterSucceedNext,
const uint32_t * dsMeterFailNext,
const uint32_t * dsMeterSpecific,
11. Tabela de parâmetros TokenBucket para o policiamento
/* creates a new pib_table of type 'DS_T_B_PARAM_ENTRY' */
pib_table *create_pib_DsTBParamEntry (
const uint32_t dsTBParamPrid,
const octet_string_t dsTBParamType,
const uint32_t dsTBParamRate,
const uint32_t dsTBParamBurstSize,
const uint32_t dsTBParamInterval,
112
D. O Script para Encaminhadores
#! /bin/bash
# Configura as classes DiffServ em Linux
# Autor: Laercio Cruvinel Junior
# Uso: ./tcscript.sh <interface> {externa|interna|interior}
D.1 Subrotinas
config_externa()
{
# Interface Externa num encaminhador de fronteira
$TC qdisc add dev $INTERFACE handle ffff: ingress
}
#####################################################################
marca()
{
# Classes que marcam o valor DSCP; mask=0x3 preserva os bits Class
Selector do ToS
$TC class change dev $INTERFACE parent 1:0 classid 1:1 dsmark mask
0x3 value 0x00 # BE
0x3 value 0xb8 # EF
0x3 value 0x28 # AF11
}
#####################################################################
config_classes_interior()
{
# dsmark principal
tc qdisc add dev $INTERFACE handle 1:0 root dsmark indices 64
set_tc_index
# classificador da dsmark
113
D. O SCRIPT PARA ENCAMINHADORES
tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 tcindex
mask 0xfc shift 2 pass_on
# disciplina htb principal
tc qdisc add dev $INTERFACE parent 1:0 handle 2:0 htb
# classe htb principal
tc class add dev $INTERFACE parent 2:0 classid 2:1 htb rate 100Mbit
ceil 100Mbit
# classificador da classe htb
tc filter add dev $INTERFACE parent 2:0 protocol ip prio 1 tcindex
mask 0xf0 shift 4 pass_on
# AF 1 especifico
tc class add dev $INTERFACE parent 2:1 classid 2:10 htb rate
15000Kbit ceil 100Mbit
tc qdisc add dev $INTERFACE parent 2:10 handle 10 gred setup DPs 3
default 2 grio
# AF 1 DP 1
tc qdisc change dev $INTERFACE parent 2:10 gred limit 2000KB min
150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit DP 1
# AF 1 DP 2
# AF 1 DP 3
# AF 2 especifico
default 2 grio
# AF 2 DP 1
# AF 2 DP 2
# AF 2 DP 3
# AF 3 especifico
default 2 grio
# AF 3 DP 1
# AF 3 DP 2
# AF 3 DP 3
114
O SCRIPT PARA ENCAMINHADORES
# AF 4 especifico
default 2 grio
# AF 4 DP 1
# AF 4 DP 2
# AF 4 DP 3
# BE
tc qdisc add dev $INTERFACE parent 2:50 handle 60 red limit 2000KB
min 150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit
probability 0.4
# EF
10000kbit ceil 10000kbit
tc qdisc add dev $INTERFACE parent 2:60 handle 50 pfifo limit 5
# Elementos do classificador dsmark
# AF 1
tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle
tcindex classid 1:111
# AF 2
# AF 3
# AF 4
# BE
tcindex mask 0 classid 1:1
# EF
10
12
14
18
20
22
26
28
30
34
36
38
0
115
D. O SCRIPT PARA ENCAMINHADORES
tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle 46
# elementos do classificador htb
# EF
# AF 1
# AF 2
# AF 3
# AF 4
# BE
}
#####################################################################
filtros()
{
# Filtros para associar os pacotes com as classes segundo o valor
skb->tc_index
$TC filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle 1
tcindex classid 1:1 pass_on
$TC filter add dev $INTERFACE parent 1:0 protocol ip prio 2 handle 2
tcindex classid 1:2 pass_on
$TC filter add dev $INTERFACE parent 1:0 protocol ip prio 11 handle
11 tcindex classid 1:11 pass_on
43 tcindex classid 1:43
}
#####################################################################
116
O SCRIPT PARA ENCAMINHADORES
config_interna()
{
# Interface Interna ao domínio
# Disciplina raiz
$TC qdisc add dev $INTERFACE handle 1:0 root dsmark indices 128
default_index 1
marca
filtros
}
#####################################################################
config_interior()
{
# Interface Interna ao domínio
config_classes_interior
}
#####################################################################
D.2 Principal
TC=/sbin/tc
INTERFACE=$1
case "$2" in
'externa')
config_externa
;;
'interna')
config_interna
;;
'interior')
config_interior
;;
*)
echo "Utilização: $0 <interface>
exit 1
;;
esac
{externa|interna|interior}"
117
E. Diagramas de Classes
E.1 Policy Management Tool
119
E. DIAGRAMAS DE CLASSES
E.2 Interface com o Utilizador
120
Bibliografia
[Almesberger] W. Almesberger, Linux Network
Implementation Overview, EPFL ICA, Fevereiro 2001.
Traffic
Control
-
[Balliache] L. Balliache, Practical QoS, in http://opalsoft.net/qos/, Fevereiro
2002.
[Breslau] L. Breslau, E. W. Knightly, S. Schenker, I. Stoica, H. Zhang,
Endpoint Admission Control: Architectural Issues and Performance, ACM
SIGCOMM 2000, Estocolmo, Suécia, Agosto 2000.
[Brown] M. Brown, Traffic Control HOWTO: Classful Queuing Disciplines, in
http://programming.linux.com, Setembro 2003.
[Calhariz] J. Calhariz, Um Gestor de Recursos para Uma Rede IP com Suporte
de Serviços Diferenciados, Dissertação de Mestrado, Instituto Superior
Técnico, Universidade Técnica de Lisboa, Julho 2004.
[CIIST] Centro de Informática do Instituto Superior Técnico, Diagramas de
Tráfego da Rede do IST, in https://ciist.ist.utl.pt/netgraphs, 2004.
[Corrente] A. Corrente, M. De Bernardi, R. Rinaldi, Policy Provisioning
Performance Evaluation using COPS-PR in a Policy Based Network, Integrated
Network Management 2003, p201-213, 2003.
[DMTF] Distributed Management Task Force,Inc., in http://www.dmtf.org/,
2004.
[Faster] J. Harju (supervisor), Faster Pro Project, Tampere University of
Technology, in http://www.atm.tut.fi/faster, Tampere, Finlândia, 2001.
[Floyd93] S. Floyd, V. Jacobson, Random Early Detection Gateways for
Congestion Avoidance, IEEE/ACM Transactions on Networking, Agosto 1993.
[Floyd95a] V. Paxson, S. Floyd, Wide-area traffic: The failure of poisson
modeling, IEEE/ACM Trans. Networking, vol. 3 p226-244, 1995.
[Floyd95b] S. Floyd, V. Jacobson, Link sharing and Resource Management
Models for packet Networks, IEEE/ACM Transactions on Networking, Vol. 3
N. 4, Agosto 1995.
[Hegering]
[Hubert] B. Hubert, G. Maxwell, R. van Mook, M. van Oosterhout, P.
Schroeder, J. Spaans, Linux Advanced Routing & Traffic Control HOWTO, in
http://www.lartc.org, v0.9.0, Março de 2002.
[IntelCOPS] Intel Corporation, Intel COPS Client Software Development Kit, in
http://www.intel.com/labs/manage/cops/, Junho 2000.
[ISO8879] International Organization for Standardization (ISO), ISO
8879:1986. Information Processing - Text and Office Systems - Standard
Generalized Markup Language (SGML) [= Traitement de l'information,
Systèmes bureautiques, Langage standard géneralisé de balisage (SGML)],
ISO 8879:1986 (E), Genebra, Outubro 1986.
121
BIBLIOGRAFIA
[Java] Sun Microsystems, Java Technology, in http://java.sun.com, 2004.
[JLDAP] R. Weltman, C. Tomlinson, S. Sonntag, The Java LDAP Application
Program Interface, draft-ietf-ldapext-ldap-java-api-19.txt, Junho 2004.
[Lemponen]
[Lymberopoulos] L. Lymberopoulos, E. Lupu, M. Sloman, Ponder Policy
Implementation and Validation in a CIM and Differentiated Services
Framework, 9º IEEE/IFIP Network Operations and Management Symposium
(NOMS 2004), Seul, Coréia, Maio 2004.
[Majalainen]
[MOICANE] Projecto Moicane in http://www.moicane.com, Information
Society Technologies (IST).
[Nagle] J. Nagle, On Packet Switches with Infinite Storage, IEEE Trans. on
Communications, COM-35, p435-438, 1987.
[OpenLDAP]
[PONDER] N. Damianou, N. Dulay, E. Lupu, M. Sloman, The Ponder Policy
Specification Language, Imperial College of Science Technology and
Medicine, Department of Computing, Londres, Janeiro 2001.
[Pongsiri] J. Pongsiri, M. Parikh, M. Raspopovic, and K. Chandra.
Visualization of Internet Traffic Features, 12th International Conference of
Scientific Computing and Mathematical Modeling. Chicago, EUA, 1999.
[QBone] G. Almes (chair),
http://qbone.internet2.edu, 2004.
Internet2
QoS
Working
Group,
in
[RAP] S. Hahn, M. Stevens, Resource Allocation Protocol (rap) Charter, in
http://www.ietf.org/html.charters/rap-charter.html, IETF, Novembro 2002.
[RFC1510]
[RFC2210] J.Wroclawski, The Use of RSVP with IETF Integrated Services,
RFC 2210, Setembro 1997.
[RFC2222]
[RFC2246]
[RFC2251] M.Wahl, T. Howes, S. Kille, Lightweight Directory Access
Protocol (v3), RFC 2251, Dezembro 1997.
[RFC2252]
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC
2474. Dezembro 1998.
[RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An
Architecture for Differentiated Services, RFC 2475, Dezembro 1998.
[RFC2597]
[RFC2598]
[RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
Requirements for Traffic Engineering Over MPLS, RFC 2702, Setembro 1999.
122
BIBLIOGRAFIA
[RFC2748]
[RFC2753] R. Yavatkar, D. Pendarakis, R. Guerin, A Framework for Policybased Admission Control, RFC 2753, Janeiro 2000.
[RFC2998]
[RFC3060]
[RFC3084]
[RFC3159]
[RFC3168] K.Ramakrishnan, S. Floyd, D. Black, The Addition of Explicit
Congestion Notification (ECN) to IP, RFC 3168, Setembro 2001.
[RFC3198]
[RFC3246]
[RFC3260] D. Grossman, New Terminology and Clarifications for Diffserv,
RFC 3260, Abril 2002.
[RFC3290]
[RFC3317]
[RFC3318]
[RFC3460]
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., B. Moore, Policy
Quality of Service (QoS) Information Model, RFC 3644, Novembro 2003.
[RFC3670]
[RFC3703]
[RFC3714] S. Floyd, J. Kempf, IAB Concerns Regarding Congestion Control
for Voice Traffic in the Internet, RFC 3714, Março 2004.
[RUSU02] I. Wakeman, A. Ghosh, J. Crowcroft, V. Jacobson, S. Floyd,
Implementing Real Time Packet Forwarding Policies using Streams, Usenix
1995 Technical Conference, New Orleans, EUA, p71-82, Janeiro 1995.
[SAX2] D. Brownell, Sax, in http://www.saxproject.org/, Janeiro 2002.
[SForge] SourceForge.net in http://sourceforge.net/.
[Sloman]
[Tequila]
[Verma] D.C. Verma, Simplifying Network Administration Using Policy-Based
Management, IEEE Network Magazine Vol. 16 Nº. 2 pp. 20-26, Março/Abril
2002.
[W3CDOM] A. Le Hors, P. Le Hégaret, L. Wood, G. Nicol, J. Robie, M.
Champion, S. Byrne, Document Object Model (DOM) Level 2 Core
Specification Version 1.0, http://www.w3.org/TR/DOM-Level-2-Core/, W3C
Recommendation, Novembro 2000.
123
BIBLIOGRAFIA
[W3CXML] F. Yergeau, T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler,
Extensible Markup Language (XML) 1.0 (Third Edition), W3C
Recommendation, http://www.w3.org/XML/Core/, Fevereiro 2004.
[X680] Abstract Syntax Notation One (ASN.1): Specification of basic notation,
recomendação ITU-T X.680, Julho 2002.
124
Acrónimos e Abreviaturas
ACL
Access Control List
AF
Assured Forwarding
ANSI
American National Standard Institute
API
Application Program Interface
AQM
Active Queue Management
ASN.1
Abstract Syntax Notation One
BA
Behavior Aggregate
BAR
Bandwidth Allocation Request
BB
Bandwidth Broker
BER
Basic Encoding Rule
BE
Best-Effort
BSI
British Standards Institute
CBQ
Class Based Queueing
COPS-PR COPS Usage for Policy Provisioning
COPS
Common Open Policy Service Protocol
DEN
Directory Enabled Networks
DiffServ
Differentiated Services
DSCP
Differentiated Services Codepoint
DTD
Document Type Definition
EF
Expedited Forwarding
ETSI
European Telecommunications Standards Institute
FIFO
First In First Out
GRED
Generalized Random Early Detection
HTB
Hierarchical Token Bucket
IANA
Internet Assigned Numbers Authority
IETF
Internet Engineering Task Force
IntServ
Integrated Services
IN
Interior Node
IPSec
Internet Protocol Security
LDAP
Lightweight Directory Access Protocol
LDAP
Lightweight Directory Access Protocol
LPDP
Local Policy Decision Point
125
ACRÓNIMOS E ABREVIATURAS
MF
Multiple Field
MIB
Management Information Base
MPLS
Multiprotocol Label Switching
OSPF
Open Shortest Path First
PBN
Policy-Based Networking
PDB
Per Domain Behavior
PDP
Policy Decision Point
PEP
Policy Enforcement Point
PHB
Per-Hop Behavior
PIB
Policy Information Base
PIN
Policy-Ignorant Node
PMT
Policy Management Tool
PPRID
Prefix Provisioning Instance Identifier
PQ
Priority Queueing
PRC
Provisioning Class
PRID
Provisioning Instance Identifier
PRI
Provisioning Instance
qdisc
Queueing Discipline
QoS
Quality of Service
RAA
Resource Allocation Answer
RAR
Resource Allocation Request
RDN
Relative Distinguished Name
RED
Random Early Detection
RFC
Request For Comments
RR
Round Robin
RSVP
Resource Reservation Protocol
RTP
Real-Time Protocol
RTT
Round Trip Time
SCFQ
Self-Clocked Fair Queueing
SFQ
Stochastic Fair Queueing
SGML
Standard Generalized Markup Language
SLA
Service Level Agreement
SLS
Service Level Specification
SMI
Structure of Management Information
SNMP
Simple Network Management Protocol
126
ACRÓNIMOS E ABREVIATURAS
SPPI
Structure of Policy Provisioning Information
SRTCM
Single Rate Three Color Marker
TB
Token Bucket
TBF
Token Bucket Filter
TCA
Traffic Conditioning Agreement
TCB
Transmission Control Block
TCS
Traffic Conditioning Specification
ToS
Type of Service
TRTCM
Two Rate Three Color Marker
WFQ
Weighted Fair Queueing
WRR
Weighted Round Robin
XML
Extensible Markup Language
127

Universidade Técnica de Lisboa Instituto Superior Técnico Gestão

Transcrição

Documentos relacionados

Ficha Cadastral - HOYA Corretora de Valores e Câmbio

Descobrindo a força interior- PEP em Lifeprint, Phoenix, Arizona

A 4R melhora os resultados da Pep Boys

Gestão e análise detalhada de tráfego para redes IP

O PEP na Educação - Universidade de Parkland

Boletim 32

Engenharia de Tráfego - departamento de transportes da ufpr

02/09 - Infraero conclui curso de inglês para profissionais de tráfego

Controladores aéreos

Programas do PEP 2013