Universidade Técnica de Lisboa Instituto Superior Técnico Gestão
Transcrição
Universidade Técnica de Lisboa Instituto Superior Técnico Gestã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 2. TECNOLOGIAS SELECCIONADAS • 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 2. TECNOLOGIAS SELECCIONADAS 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 2. TECNOLOGIAS SELECCIONADAS 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 S ERVIÇOS D IFERENCIADOS 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 2. TECNOLOGIAS SELECCIONADAS 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 S ERVIÇOS D IFERENCIADOS 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 2. TECNOLOGIAS SELECCIONADAS 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. S ERVIÇOS D IFERENCIADOS • 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. TECNOLOGIAS SELECCIONADAS 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 2. TECNOLOGIAS SELECCIONADAS 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 2. TECNOLOGIAS SELECCIONADAS <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 () throws SAXException; public abstract void startElement (String name, AttributeList atts) throws SAXException; public abstract void endElement (String name) throws SAXException; public abstract void characters (char ch[], int start, int length) throws SAXException; public abstract void ignorableWhitespace (char ch[], int start, int length) throws SAXException; 25 2. TECNOLOGIAS SELECCIONADAS public abstract void processingInstruction (String target, String data) throws SAXException; } 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 2. TECNOLOGIAS SELECCIONADAS 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 2. TECNOLOGIAS SELECCIONADAS 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 2. TECNOLOGIAS SELECCIONADAS 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 2. TECNOLOGIAS SELECCIONADAS 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 2. TECNOLOGIAS SELECCIONADAS 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 2. TECNOLOGIAS SELECCIONADAS 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 2. TECNOLOGIAS SELECCIONADAS • 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 2. TECNOLOGIAS SELECCIONADAS 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 3. ARQUITECTURA PROPOSTA 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 3. ARQUITECTURA PROPOSTA 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 3. ARQUITECTURA PROPOSTA 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 3. ARQUITECTURA PROPOSTA 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 3. ARQUITECTURA PROPOSTA 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. ARQUITECTURA PROPOSTA 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 3. ARQUITECTURA PROPOSTA 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 3. ARQUITECTURA PROPOSTA 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 4. DETALHES DA SOLUÇÃO IMPLEMENTADA 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 4. DETALHES DA SOLUÇÃO IMPLEMENTADA 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 4. DETALHES DA SOLUÇÃO IMPLEMENTADA 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 4. DETALHES DA SOLUÇÃO IMPLEMENTADA 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 4. DETALHES DA SOLUÇÃO IMPLEMENTADA 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 4. DETALHES DA SOLUÇÃO IMPLEMENTADA 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 4. DETALHES DA SOLUÇÃO IMPLEMENTADA 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 # tc class change dev eth0 mask 0x3 value 0xb8 # tc class change dev eth0 mask 0x3 value 0x28 # parent 1:0 classid 1:1 dsmark \ BE parent 1:0 classid 1:2 dsmark \ EF parent 1:0 classid 1:11 dsmark \ 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 4. DETALHES DA SOLUÇÃO IMPLEMENTADA 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 \ limit 600KB min 150KB max 450KB burst 200 \ avpkt 1000 bandwidth 1000kbit DP 1 \ # AF11 probability 0.02 prio 11 tc qdisc change dev eth0 parent 2:10 gred \ limit 600KB min 150KB max 450KB burst 200 \ avpkt 1000 bandwidth 1000kbit DP 2 \ # AF12 probability 0.04 prio 12 tc qdisc change dev eth0 parent 2:10 gred \ limit 600KB min 150KB max 450KB burst 200 \ avpkt 1000 bandwidth 1000kbit DP 3 \ # AF13 probability 0.06 prio 13 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 4. DETALHES DA SOLUÇÃO IMPLEMENTADA 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 [root@linax /]# tc qdisc show dev eth1 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 [root@linax /]# tc qdisc show dev eth0 qdisc dsmark 1: indices 0x0080 default_index 0x0001 [root@linax /]# tc qdisc show dev eth1 qdisc dsmark 1: indices 0x0080 default_index 0x0001 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 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 1635ms rtt min/avg/max/mdev = 0.122/0.140/0.286/0.020 ms, ipg/ewma 0.818/0.137 ms --- linox.rede.pt ping statistics --2000 packets transmitted, 1344 received, 32% packet loss, time 13738ms 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 TESTES DE D ESEMPENHO 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 --- linox.rede.pt ping statistics --2000 packets transmitted, 1974 received, 1% packet loss, time 4610ms rtt min/avg/max/mdev = 0.743/0.793/1.023/0.040 ms, ipg/ewma 2.306/0.799 ms 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 TESTES DE D ESEMPENHO 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: DP:1 (prio 2) Average Queue 0b Measured Queue 0b Packet drops: 1165 (forced 1155 early 10) Packet totals: 2000 (bytes 2084000) ewma 7 Plog 24 Scell_log 9 DP:2 (prio 3) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 0 (bytes 0) ewma 4 Plog 19 Scell_log 18 DP:3 (prio 4) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 0 (bytes 0) ewma 4 Plog 18 Scell_log 18 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 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 :20 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 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 ## PING linox.rede.pt (192.168.3.2) 56(84) bytes of data. --- linox.rede.pt ping statistics --2000 packets transmitted, 1813 received, 9% packet loss, time 4653ms rtt min/avg/max/mdev = 0.184/0.219/0.666/0.041 ms, ipg/ewma 2.327/0.222 ms PING linox.rede.pt (192.168.3.2) 500(528) bytes of data. --- linox.rede.pt ping statistics --2000 packets transmitted, 909 received, 54% packet loss, time 22190ms rtt min/avg/max/mdev = 0.456/0.572/0.974/0.069 ms, ipg/ewma 11.100/0.577 ms PING linox.rede.pt (192.168.3.2) 1000(1028) bytes of data. --- linox.rede.pt ping statistics --2000 packets transmitted, 583 received, 70% packet loss, time 28584ms rtt min/avg/max/mdev = 0.769/0.931/1.058/0.091 ms, ipg/ewma 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 TESTES DE D ESEMPENHO 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: DP:1 (prio 2) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 625 (bytes 61250) ewma 7 Plog 24 Scell_log 9 DP:2 (prio 3) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 605 (bytes 59290) ewma 7 Plog 23 Scell_log 9 DP:3 (prio 4) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 584 (bytes 57232) ewma 7 Plog 23 Scell_log 9 Sent 177772 bytes 1814 pkts (dropped 0, overlimits 0) ## Pacotes 528 bytes ## Estatisticas AF3 na interface eth1 qdisc gred 30: DP:1 (prio 2) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 307 (bytes 166394) ewma 7 DP:2 (prio 3) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 306 (bytes 165852) ewma 7 DP:3 (prio 4) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 305 (bytes 165310) 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) ## Pacotes 1028 bytes ## Estatisticas AF3 na interface eth1 qdisc gred 30: DP:1 (prio 2) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 197 (bytes 205274) ewma 7 Plog 24 Scell_log 9 DP:2 (prio 3) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 197 (bytes 205274) ewma 7 Plog 23 Scell_log 9 DP:3 (prio 4) Average Queue 0b Measured Queue 0b Packet drops: 0 (forced 0 early 0) Packet totals: 197 (bytes 205274) ewma 7 Plog 23 Scell_log 9 Sent 615822 bytes 591 pkts (dropped 0, overlimits 0) 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 ## PING linox.rede.pt (192.168.3.2) 200(228) bytes of data. --- linox.rede.pt ping statistics --2000 packets transmitted, 1998 received, 0% packet loss, time 2241ms rtt min/avg/max/mdev = 0.279/0.307/0.711/0.032 ms, ipg/ewma 1.121/0.301 ms ## Com condicionamento EF Largura de Banda 200 Kbps ## PING linox.rede.pt (192.168.3.2) 200(228) bytes of data. --- linox.rede.pt ping statistics --2000 packets transmitted, 1993 received, 0% packet loss, time 18609ms rtt min/avg/max/mdev = 0.287/23.799/86.544/28.419 ms, ipg/ewma 9.309/25.241 ms 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 TESTES DE D ESEMPENHO 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.' EQUALITY octetStringMatch ORDERING octetStringOrderingMatch 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).' EQUALITY octetStringMatch ORDERING octetStringOrderingMatch 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).' EQUALITY octetStringMatch ORDERING octetStringOrderingMatch 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.' EQUALITY octetStringMatch ORDERING octetStringOrderingMatch 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>.' EQUALITY octetStringMatch ORDERING octetStringOrderingMatch 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' EQUALITY octetStringMatch ORDERING octetStringOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) attributetype ( 6.6.6.10 NAME 'tcsId' DESC 'Identificacao do TCS.' EQUALITY octetStringMatch ORDERING octetStringOrderingMatch 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, const uint32_t instance) 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, const uint32_t instance) 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, const uint32_t instance) 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, const uint32_t instance) 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, const uint32_t instance) 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, const uint32_t instance) 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, const uint32_t instance) 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, const uint32_t instance) 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, const uint32_t instance) 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 $TC class change dev $INTERFACE parent 1:0 classid 1:2 dsmark mask 0x3 value 0xb8 # EF $TC class change dev $INTERFACE parent 1:0 classid 1:11 dsmark mask 0x3 value 0x28 # AF11 $TC class change dev $INTERFACE parent 1:0 classid 1:12 dsmark mask 0x3 value 0x30 # AF12 $TC class change dev $INTERFACE parent 1:0 classid 1:13 dsmark mask 0x3 value 0x38 # AF13 $TC class change dev $INTERFACE parent 1:0 classid 1:21 dsmark mask 0x3 value 0x48 # AF21 $TC class change dev $INTERFACE parent 1:0 classid 1:22 dsmark mask 0x3 value 0x50 # AF22 $TC class change dev $INTERFACE parent 1:0 classid 1:23 dsmark mask 0x3 value 0x58 # AF23 $TC class change dev $INTERFACE parent 1:0 classid 1:31 dsmark mask 0x3 value 0x68 # AF31 $TC class change dev $INTERFACE parent 1:0 classid 1:32 dsmark mask 0x3 value 0x70 # AF32 $TC class change dev $INTERFACE parent 1:0 classid 1:33 dsmark mask 0x3 value 0x78 # AF33 $TC class change dev $INTERFACE parent 1:0 classid 1:41 dsmark mask 0x3 value 0x88 # AF41 $TC class change dev $INTERFACE parent 1:0 classid 1:42 dsmark mask 0x3 value 0x90 # AF42 $TC class change dev $INTERFACE parent 1:0 classid 1:43 dsmark mask 0x3 value 0x98 # AF43 } ##################################################################### 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 probability 0.02 prio 2 # AF 1 DP 2 tc qdisc change dev $INTERFACE parent 2:10 gred limit 2000KB min 150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit DP 2 probability 0.04 prio 3 # AF 1 DP 3 tc qdisc change dev $INTERFACE parent 2:10 gred limit 2000KB min 150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit DP 3 probability 0.06 prio 4 # 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 # AF 2 DP 2 tc qdisc change dev $INTERFACE parent 2:20 gred limit 2000KB min 150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit DP 2 probability 0.04 prio 3 # AF 2 DP 3 tc qdisc change dev $INTERFACE parent 2:20 gred limit 2000KB min 150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit DP 3 probability 0.06 prio 4 # AF 3 especifico tc class add dev $INTERFACE parent 2:1 classid 2:30 htb rate 15000Kbit ceil 100Mbit tc qdisc add dev $INTERFACE parent 2:30 handle 30 gred setup DPs 3 default 2 grio # AF 3 DP 1 tc qdisc change dev $INTERFACE parent 2:30 gred limit 2000KB min 150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit DP 1 probability 0.02 prio 2 # AF 3 DP 2 tc qdisc change dev $INTERFACE parent 2:30 gred limit 2000KB min 150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit DP 2 probability 0.04 prio 3 # AF 3 DP 3 tc qdisc change dev $INTERFACE parent 2:30 gred limit 2000KB min 150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit DP 3 probability 0.06 prio 4 114 O SCRIPT PARA ENCAMINHADORES # AF 4 especifico tc class add dev $INTERFACE parent 2:1 classid 2:40 htb rate 15000Kbit ceil 100Mbit tc qdisc add dev $INTERFACE parent 2:40 handle 40 gred setup DPs 3 default 2 grio # AF 4 DP 1 tc qdisc change dev $INTERFACE parent 2:40 gred limit 2000KB min 150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit DP 1 probability 0.02 prio 2 # AF 4 DP 2 tc qdisc change dev $INTERFACE parent 2:40 gred limit 2000KB min 150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit DP 2 probability 0.04 prio 3 # AF 4 DP 3 tc qdisc change dev $INTERFACE parent 2:40 gred limit 2000KB min 150KB max 450KB burst 250 avpkt 1000 bandwidth 100Mbit DP 3 probability 0.06 prio 4 # BE tc class add dev $INTERFACE parent 2:1 classid 2:50 htb rate 15000Kbit ceil 100Mbit 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 tc class add dev $INTERFACE parent 2:1 classid 2:60 htb rate 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 tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle tcindex classid 1:112 tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle tcindex classid 1:113 # AF 2 tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle tcindex classid 1:121 tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle tcindex classid 1:122 tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle tcindex classid 1:123 # AF 3 tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle tcindex classid 1:131 tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle tcindex classid 1:132 tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle tcindex classid 1:133 # AF 4 tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle tcindex classid 1:141 tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle tcindex classid 1:142 tc filter add dev $INTERFACE parent 1:0 protocol ip prio 1 handle tcindex classid 1:143 # BE tc filter add dev $INTERFACE parent 1:0 protocol ip prio 2 handle 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 tcindex classid 1:151 # elementos do classificador htb # EF tc filter add dev $INTERFACE parent 2:0 protocol ip prio 1 handle 5 tcindex classid 2:60 # AF 1 tc filter add dev $INTERFACE parent 2:0 protocol ip prio 1 handle 1 tcindex classid 2:10 # AF 2 tc filter add dev $INTERFACE parent 2:0 protocol ip prio 1 handle 2 tcindex classid 2:20 # AF 3 tc filter add dev $INTERFACE parent 2:0 protocol ip prio 1 handle 3 tcindex classid 2:30 # AF 4 tc filter add dev $INTERFACE parent 2:0 protocol ip prio 1 handle 4 tcindex classid 2:40 # BE tc filter add dev $INTERFACE parent 2:0 protocol ip prio 1 handle 0 tcindex classid 2:50 } ##################################################################### 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 $TC filter add dev $INTERFACE parent 1:0 protocol ip prio 12 handle 12 tcindex classid 1:12 pass_on $TC filter add dev $INTERFACE parent 1:0 protocol ip prio 13 handle 13 tcindex classid 1:13 pass_on $TC filter add dev $INTERFACE parent 1:0 protocol ip prio 21 handle 21 tcindex classid 1:21 pass_on $TC filter add dev $INTERFACE parent 1:0 protocol ip prio 22 handle 22 tcindex classid 1:22 pass_on $TC filter add dev $INTERFACE parent 1:0 protocol ip prio 23 handle 23 tcindex classid 1:23 pass_on $TC filter add dev $INTERFACE parent 1:0 protocol ip prio 31 handle 31 tcindex classid 1:31 pass_on $TC filter add dev $INTERFACE parent 1:0 protocol ip prio 32 handle 32 tcindex classid 1:32 pass_on $TC filter add dev $INTERFACE parent 1:0 protocol ip prio 33 handle 33 tcindex classid 1:33 pass_on $TC filter add dev $INTERFACE parent 1:0 protocol ip prio 41 handle 41 tcindex classid 1:41 pass_on $TC filter add dev $INTERFACE parent 1:0 protocol ip prio 42 handle 42 tcindex classid 1:42 pass_on $TC filter add dev $INTERFACE parent 1:0 protocol ip prio 43 handle 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