Universidade Tcnica de Lisboa Instituto Superior Tcnico

Gesto de Polticas de Qualidade de Servio

Larcio Cruvinel Jnior (Licenciado)

Dissertao para obteno do Grau de Mestre em Engenharia Informtica e de Computadores

Documento Provisrio
Prova concluda em: Setembro de 2004

Resumo
Este documento descreve a implementao de uma arquitectura normalizada para aprovisionamento e gesto de recursos de qualidade de servio num ambiente de rede. A escalabilidade da soluo permite a sua adopo por ambientes corporativos e educacionais. A oferta de Qualidade de Servio em uma rede passa pela correcta avaliao da relao entre as necessidades dos utilizadores e os recursos disponveis. A utilizao de polticas reutilizveis e de atribuio dinmica permite uma gesto mais imediata, equilibrada e justa da distribuio dos recursos, segundo critrios de necessidades dos utilizadores e hora do dia, entre outros. A arquitectura e mecanismos dos Servios Diferenciados DiffServ desenvolvida pelo IETF, aqui utilizada para viabilizar a implementao da Qualidade de Servio numa arquitectura normalizada com a definio dos comandos de polticas de alto nvel (SLA Service Level Agreement) atravs de XML, armazenamento destas definies num directrio LDAP, e utilizao de uma Base de Informao de Polticas (PIB) independente de plataformas. Implicando na separao entre gesto e utilizao das polticas, este modelo permite a reutilizao dos objectos na hierarquia e a sua distribuio a partir da PIB s entidades aplicadoras de polticas com o protocolo COPS. Assim, cada tipo de encaminhador gerido pode ter o seu controlo de trfego actualizado de maneira consistente e imediata. O foco principal deste trabalho a implementao das polticas e do ambiente de gesto em mquinas Linux, atravs da utilizao de uma aplicao de interface entre contratos de servio com polticas de alto nvel e um gestor de aprovisionamento que distribui polticas de baixo nvel para os sistemas relevantes. Define um conjunto bsico extensvel de classes de servio que podero auxiliar o administrador a classificar o trfego e agregar os fluxos de trfego com requisitos semelhantes para que obtenham a quantidade adequada de recursos da rede. Palavras-chave: Qualidade de Servio, DiffServ, Gesto Baseada em Polticas, PMT, PIB, COPS

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. IETFs 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
Agradeo Prof. Teresa Vazo pelo apoio, orientao, incentivo e confiana tanto durante este trabalho como na parte curricular do mestrado. Agradeo ao Prof. Fernando Mira da Silva Corte Real pela confiana e disponibilidades demonstradas desde o primeiro contacto e continuadas durante todo o decorrer do mestrado. Agradeo Universidade Autnoma de Lisboa, nas pessoas dos directores do Departamento de Cincias e Tecnologias, em especial ao Prof. Paulo Cabrita e equipa, pela disponibilizao de meios essenciais para a realizao deste trabalho. minha famlia agradeo com especial carinho, pelo incentivo, apoio e compreenso durante este perodo de trabalho intenso. Agradeo minha amada e admirada esposa Clia, a luz desta famlia, que sempre nos permite atracar em porto seguro. Agradeo Carol e ao Felipe, dois filhos excepcionais, o nosso orgulho. Aos colegas Miguel Louro e Sara Silva agradeo o apoio e camaradagem nas cadeiras deste mestrado. Agradeo ao Hugo Silva, que tambm colaborou com equipamento para os testes efectuados. Alm das pessoas com responsabilidade directa para este trabalho chegar ao fim, agradeo aos meus pais, sogros, irmos, cunhados e amigos prximos e distantes, presentes e ausentes.

ndice
1 Introduo ................................................................................................. 1 1.1 Enquadramento Cientfico .................................................................. 1 1.2 Objectivos .......................................................................................... 3 1.3 Convenes Tipogrficas ................................................................... 4 1.4 Estrutura da Dissertao..................................................................... 4 2 Tecnologias Seleccionadas ........................................................................ 7 2.1 Introduo .......................................................................................... 7 2.2 PBN Policy-Based Networking ........................................................ 7 2.2.1 Introduo ...........................................................................................7 2.2.2 Definio de Poltica...........................................................................7 2.2.3 Aprovisionamento de Servios ...........................................................8 2.2.4 Arquitectura ........................................................................................9 2.2.5 Linguagens de Especificao de Polticas ........................................10 2.2.6 O schema de Polticas do IETF.........................................................10 2.3 Servios Diferenciados..................................................................... 12 2.3.1 Introduo .........................................................................................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 Classificao e Condicionamento do Trfego ..................................15 2.3.6 Per-Hop Behaviors ...........................................................................15 2.4 XML ................................................................................................ 15 2.4.1 Introduo .........................................................................................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 Introduo .........................................................................................15 2.5.2 Estrutura da Informao LDAP ........................................................15 2.5.3 Acesso, Autenticao e Autorizao.................................................15 2.5.4 Operaes LDAP ..............................................................................15 2.5.5 LDAP e Java .....................................................................................15 2.6 PIB................................................................................................... 15 2.6.1 Introduo .........................................................................................15 2.6.2 Conceitos Gerais ...............................................................................15 2.6.3 Relao com MIB .............................................................................15 2.6.4 Operao ...........................................................................................15 2.6.5 O PIB DiffServ .................................................................................15 2.6.6 Implementao de uma Poltica de Aprovisionamento ....................15 2.7 COPS ............................................................................................... 15 2.7.1 Introduo .........................................................................................15 2.7.2 Principais Caractersticas ..................................................................15 2.7.3 Operao ...........................................................................................15 2.8 Trabalho Relacionado ...................................................................... 15 3 Arquitectura Proposta ............................................................................ 15 3.1 Introduo ........................................................................................ 15

NDICE 3.2 3.3 Anlise de Requisitos ....................................................................... 15 3.2.1 Requisitos Genricos ........................................................................15 3.2.2 Estudo de Caso Polticas de Qualidade de Servio no IST............15 Esquema Geral ................................................................................. 15 3.3.1 Diagrama da Arquitectura.................................................................15 3.3.2 Operao ...........................................................................................15 3.3.3 Opes de Implementao ................................................................15 Blocos Funcionais ............................................................................ 15 3.4.1 Introduo .........................................................................................15 3.4.2 Interface do Utilizador ......................................................................15 3.4.3 Gestor de Conflitos e Tradutor de Polticas ......................................15 3.4.4 Repositrio........................................................................................15 3.4.5 PDP ...................................................................................................15 3.4.6 PEP....................................................................................................15 3.4.7 Encaminhadores ................................................................................15

3.4

4 Detalhes da Soluo Implementada ........................................................ 15 4.1 Introduo ........................................................................................ 15 4.2 Blocos Funcionais ............................................................................ 15 4.2.1 Introduo .........................................................................................15 4.2.2 Interface do Utilizador ......................................................................15 4.2.3 Gestor de Conflitos e Tradutor de Polticas ......................................15 4.2.4 Repositrio........................................................................................15 4.2.5 PDP ...................................................................................................15 4.2.6 PEP....................................................................................................15 4.2.7 Encaminhadores ................................................................................15 4.3 Funcionamento Integrado ................................................................. 15 4.4 Limitaes do Modelo ...................................................................... 15 5 Testes ....................................................................................................... 15 5.1 Introduo ........................................................................................ 15 5.2 Cenrio de Testes ............................................................................. 15 5.3 Testes Funcionais ............................................................................. 15 5.3.1 Introduo .........................................................................................15 5.3.2 Configurao dos Encaminhadores...................................................15 5.3.3 Criao de SLA.................................................................................15 5.3.4 Criao do TCS.................................................................................15 5.3.5 Efeito do TCS no Transporte de Pacotes ..........................................15 5.3.6 Eliminao de TCS ...........................................................................15 5.4 Testes de Desempenho ..................................................................... 15 5.4.1 Introduo .........................................................................................15 5.4.2 Desempenho das Aplicaes.............................................................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 Trs Classes............15 5.4.6 Desempenho do Trfego Condicionado nas Sub-Redes ...................15 6 Concluses e Trabalho Futuro ................................................................ 15 A. Ficheiros de validao DTD .................................................................... 15 B. O Schema de Polticas LDAP .................................................................. 15

C. PIB Policy Information Base ................................................................ 15 D. O Script para Encaminhadores ............................................................... 15 E. Diagramas de Classes .............................................................................. 15 Bibliografia ................................................................................................... 15 Acrnimos e Abreviaturas............................................................................ 15

ix

Lista de Figuras
Figura 2.1: Abstraces do Modelo CIM/DEN ...........................................................11 Figura 2.2: Fluxo de Informao na Definio da QdS ...............................................12 Figura 2.3: Os Bits DiffServ em IPv4 ..........................................................................14 Figura 2.4: Arquitectura do Modelo de Servios Diferenciados .................................15 Figura 2.5: Mdulos de Classificao e Condicionamento do Trfego.......................15 Figura 2.6: Uma rvore de Informao de Directrio (DIT) ......................................15 Figura 2.7: Funcionamento do referral........................................................................15 Figura 2.8: Ordenao dos Elementos do TCB no Data Path.....................................15 Figura 2.9: Data Path para Agregar Trfego 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: Opes de Classificao e Condicionamento do Trfego .........................15 Figura 3.3: A Policy Management Tool.......................................................................15 Figura 3.4: O Policy Decision Point ............................................................................15 Figura 3.5: Construo de uma Poltica com PIB........................................................15 Figura 3.6: O Policy Enforcement Point......................................................................15 Figura 3.7: Os papis das interfaces ............................................................................15 Figura 3.8: Trfego VoIP vs. Trfego FTP ..................................................................15 Figura 3.9: Processamento de Dados da Rede no Linux .............................................15 Figura 3.10: Configurao da Interface Externa Policiamento de Entrada ..............15 Figura 3.11: Configurao da Interface Interna Filas de Sada.................................15 Figura 4.1: Funcionamento da Interface com o Utilizador ..........................................15 Figura 4.2: Ecr de Configurao dos TCS .................................................................15 Figura 4.3: Relao da PMT com outros Mdulos ......................................................15 Figura 4.4: Esquema de Funcionamento do PDP ........................................................15 Figura 4.5: Ficheiro de Configurao para o PEP .......................................................15 Figura 4.6: Esquema de Funcionamento do PEP.........................................................15 Figura 4.7: Realizao dos Mdulos 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 Repositrio..............................................................15 Figura 5.3: Configurao do Encaminhador de Fronteira ...........................................15

NDICE Figura 5.4: Configurao do Encaminhador Interior...................................................15 Figura 5.5: Criao de um SLA ...................................................................................15 Figura 5.6: O SLA no Repositrio...............................................................................15 Figura 5.7: XML da Criao de um SLA ....................................................................15 Figura 5.8: Condies e Aces Criadas no Repositrio.............................................15 Figura 5.9: Atributos do TCS no Repositrio..............................................................15 Figura 5.10: XML da Criao de um TCS...................................................................15 Figura 5.11: Comando tc Enviado para a Shell Linux...............................................15 Figura 5.12: Relatrio de Filtros no Encaminhador de Fronteira ................................15 Figura 5.13: Anlise de um Pacote Capturado.............................................................15 Figura 5.14: XML para Remoo de um TCS .............................................................15 Figura 5.15: Remoo 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 Trfego .........................................................................15 Figura 5.19: Configurao da Classe AF2 ...................................................................15 Figura 5.20: Resultados com Configurao Padro.....................................................15 Figura 5.21: Descarte de Pacotes AF21 .......................................................................15 Figura 5.22: Policiador AF31 com Remarcao para AF32 e AF33 ...........................15 Figura 5.23: Resultados dos Testes para Diferentes Tamanhos de Pacotes ................15 Figura 5.24: Utilizao das Prioridades de Descarte AF3 ...........................................15 Figura 5.25: Execuo 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: Parmetros da PRC frwkIpFilterTable......................................................15 Tabela 3.1: Condicionamento do Trfego de Sada no IST.........................................15 Tabela 3.2: Condicionamento do Trfego de Entrada no IST .....................................15 Tabela 3.3: Mapeamento das Classes de Servio ........................................................15 Tabela 3.4: Configurao de uma Poltica...................................................................15 Tabela 3.5: Aplicao de Polticas 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 Transmisso para a Classe AF21 .............................15 Tabela 5.4: Desempenho do Trfego no Condicionado.............................................15 Tabela 5.5: Desempenho do Trfego Condicionado....................................................15

Introduo

1.1 Enquadramento Cientfico

A necessidade de proporcionar Qualidade de Servio (QdS) ao trfego da Internet (ou mais genericamente, em ambientes de redes IP interligadas) tem resultado num esforo de definio de novos modelos de servio pelos organismos competentes. Actualmente, o trfego de vdeoconferncia, chamadas de voz e outros servios multimdia atravs de redes IP tratado da mesma forma que qualquer outro conjunto de informao em trnsito. O tratamento dado pelo protocolo IP generalidade dos pacotes baseia-se num modelo de servio de melhor esforo (BE Best Effort) e igualdade de condies. Neste modelo, no h garantias de entrega dos pacotes nem distines de prioridade para os diferentes fluxos de trfego. O grande aumento na oferta de largura de banda durante a dcada de 1990, aliado evoluo dos sistemas pessoais de computao (PC, PDA, portteis) ajudou a criar uma era da ligao: telemveis e programas de mensagens em linha (chats e outros) so exemplos de entidades que aliciam utilizadores atravs da multimdia. Como resultado, h perodos de congesto nas redes e a degradao dos servios mais facilmente notada nas aplicaes multimdia. Porm, as limitaes da largura de banda no so os nicos responsveis por um mau desempenho das aplicaes multimdia. Estas tambm so caracterizadas por exigirem um atraso mximo entre os pacotes recebidos, o que incompatvel com o tratamento igualitrio e tradicional entre este trfego e todos os outros pacotes da rede [RFC3714]. Na Internet, esta situao agravada pela imprevisibilidade e irregularidade dos padres de trfego entre quaisquer dois destinos de pacotes [Floyd95a], [Pongsiri]. Tal como as auto-estradas tm implicaes 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 comunicao hoje em dia. Entretanto, a sua utilizao em exclusivo para soluo dos problemas de trfego vai provavelmente traduzir-se em piores condies para gesto no mdio ou longo prazo. Melhores resultados podem ser alcanados com o estudo sistemtico das condies e perfis do trfego na rede em causa, o que pode permitir uma optimizao da utilizao dos recursos, evitando desperdcios [Balliache]. O organismo internacional responsvel por elaborar e manter as normas relativas Internet (entre outras) o Internet Engineering Task Force (IETF). Prope algumas tecnologias para abordar a questo da qualidade de servio em redes IP: os modelos IntServ e DiffServ e modelos de Encaminhamento por Restries (Constraint Based Routing), tal como o Multiprotocol Label Switching (MPLS) [RFC2702].

1. INTRODUO A proviso de QdS fim a fim atravs de Classes de Servio para onde so mapeados os fluxos de trfego proposta no modelo IntServ (Integrated Services) [RFC2210]. Trs classes distintas de servio (BE, Carga Controlada e Servio Garantido) permitem a reserva de recursos nos ns da rede atravs do protocolo RSVP (Resource Reservation Protocol). Embora a QdS solicitada para cada fluxo seja garantida, os mecanismos utilizados para manuteno das reservas prejudicam a adopo do modelo IntServ em redes de grande dimenso. No sendo escalvel, o modelo ainda vlido para necessidades especficas 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 escalvel onde polticas de alto nvel (SLA) so negociadas entre o cliente e o fornecedor do servio. O trfego marcado e agregado para implementar polticas de QdS segundo classes de servio configuradas ou implcitas (classe BE). Os encaminhadores da periferia de uma rede marcam e policiam o trfego e os encaminhadores internos aplicam a cada agregado o comportamento especificado em cada classe de servio. utilizada uma parte do antigo campo ToS (Type of Service) no cabealho 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 designao ECN (Explicit Congestion Notification) [RFC3168]. As caractersticas stateless do DiffServ (no necessrio manter informao de estado para cada fluxo) o tornam adequado para ser utilizado em redes nucleares de grandes dimenses. Entretanto, o modelo no impe limites de largura de banda aos agregados atribudos a cada classe e tambm no especifica as regras para o controlo do acesso e atribuio dos recursos. Assim, no ser suficiente para resolver as questes de configurao de servios e gesto de uma rede com equipamentos heterogneos e aplicaes distribudas. O encaminhamento por restries uma aproximao 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 definio de rotas explcitas predefinidas entre redes, rotas estas que so transportadas numa etiqueta extra em cada pacote, independentemente do seu protocolo. O encaminhamento por restries extende este conceito, podendo incluir mltiplos parmetros de seleco de rotas. Tambm tm sido propostos e testados modelos conjuntos das tecnologias descritas, sendo provvel uma evoluo no sentido da utilizao de DiffServ e IntServ nas redes de acesso [RFC2998], e DiffServ e encaminhamento por restries nas redes nucleares [MOICANE]. O modelo DiffServ no tem especificaes para administrao centralizada e controlo de acesso. Esta lacuna pode ser preenchida com a adopo em paralelo do PBN (Policy-Based Networking), um modelo desenvolvido pelo grupo RAP do IETF [RAP], [RFC2753] e orientado tambm para redes IntServ. Um dos desafios que uma implementao destes modelos deve propor-se a resolver a necessidade de uma interface entre os SLA (polticas de alto nvel) e os comandos de configurao dos diversos encaminhadores (polticas de baixo nvel). O IETF disponibiliza para este fim uma Base de Informao de 2

OBJECTIVOS Polticas (PIB Police Information Base) atravs da qual as polticas podem ser transportadas entre o gestor de polticas e os equipamentos encaminhadores onde devem ser aplicadas. O protocolo de transporte de PIB o COPS (Common Open Police Service), e o aprovisionamento de polticas efectuado com o COPS-PR (COPS Usage for Police Provisioning). Outro elemento importante da arquitectura DiffServ o repositrio, que armazena e permite a reutilizao de polticas.

1.2 Objectivos
A gesto de polticas para controlo de trfego numa rede corporativa ou acadmica pode ser aplicada por scripts a um encaminhador Linux no ponto de ligao da rede com o exterior, e nos encaminhadores interiores. A flexibilidade do software disponvel naturalmente no Linux [Hubert] aliada disponibilidade de mdulos programados para seleco qualitativa do trfego [SForge] tem permitido um controlo qualitativo e quantitativo eficaz do trfego (ver, por exemplo, diagramas de trfego publicados pelo Instituto Superior Tcnico em https://ciist.ist.utl.pt/netgraphs/ISTnet.html). Este trabalho prope uma adaptao dos procedimentos para controlo do trfego em redes (corporativas, acadmicas), de forma que mais facilmente evoluam para uma arquitectura normalizada. A arquitectura sugerida e as ferramentas desenvolvidas permitem: A definio das polticas independentemente da marca ou modelo dos equipamentos onde sero instaladas. O suporte s classes de servio DiffServ normalizadas pelo IETF: EF (Expedited Forwarding), AF1 a AF4 (Assured Forwarding) com trs prioridades de descarte (drop priority) cada uma, e BE (Best Effort). A utilizao dos scripts necessrios para aplicar as polticas desejadas em encaminhadores Linux de fronteira e interiores, a partir de uma interface para polticas de alto nvel. A verificao da consistncia e gesto de conflitos entre as polticas. A gesto da largura de banda disponvel por contrato (SLA) e por fluxo individual em cada contrato (TCS Traffic Conditioning Specification). XML para especificao das polticas ao nvel mais elevado e comunicao entre os mdulos. LDAP [RFC2251] para prover as funes de repositrio e assim permitir o armazenamento de polticas reutilizveis. Policy Information Base (PIB) [RFC3317], [RFC3318] para representar os dados transportados pelo protocolo COPS. SPPI (Structure of Policy Provisioning) [RFC3159], uma linguagem para definio das tabelas PIB.

As tecnologias envolvidas nesta arquitectura incluem:

1. INTRODUO o protocolo COPS [RFC2748] como opo para a comunicao entre os pontos (objectos) de deciso e os pontos de aplicao das polticas, sendo tambm utilizado para o prprio aprovisionamento de polticas nos sistemas distribudos (COPS-PR [RFC3084]). mecanismos DiffServ, tc (traffic control) em sistemas Linux [SForge]. programao Java para interface com o utilizador, integrao com XML e LDAP e gerao dos PIB e scripts.

Embora no haja implementaes completas disponveis, tem havido documentos relativos a testes baseados na mesma arquitectura discutida aqui, ou em parte dela [Majalainen], [Tequila], [Calhariz].

1.3 Convenes Tipogrficas

Negro Itlico Largura Constante Itlico Constante Utilizado para realar termos especficos quando de sua primeira utilizao, definio ou caracterizao. Formato das palavras ou expresses em lngua estrangeira. Exemplos de comandos, cdigo fonte ou referncias no texto a parmetros ou palavras-chave. Distingue variveis, palavras chave ou parmetros a serem introduzidos do texto literal.

1.4 Estrutura da Dissertao

Este trabalho est estruturado em 6 captulos e 5 anexos. Este captulo faz o enquadramento cientfico da tese, indica os seus objectivos, as convenes tipogrficas utilizadas e apresenta a estrutura da dissertao. O captulo 2 apresenta e analisa as principais tecnologias utilizadas. So descritos os modelos de gesto por polticas e o DiffServ, o LDAP, a Base de Informao de Polticas (PIB) e o protocolo COPS. As referncias bibliogrficas possibilitam a investigao dos aspectos destas tecnologias que ultrapassam o interesse para esta tese de mestrado. Tambm neste captulo so indicados alguns trabalhos relevantes relacionados com os temas em discusso. No captulo 3 apresentada a arquitectura base para esta implementao. Inicialmente, so discutidos os procedimentos correntes para controlo da qualidade de servio numa rede tpica (rede do Instituto Superior Tcnico em Lisboa), na ptica da possvel evoluo para o modelo PBN (Policy-Based Networking). A utilizao do modelo PBN no contexto dos Servios Diferenciados, acrescenta as mais-valias da gesto centralizada, abstraco da informao de gesto, homogeneidade de procedimentos para os vrios equipamentos, interface integrada e consistente [RFC2753]. A partir de um esquema geral da arquitectura proposta, os seus blocos funcionais so identificados e analisados. 4

ESTRUTURA DA D ISSERTAO A soluo aplicada descrita no captulo 4. A implementao de cada bloco funcionais detalhada e comparada com o modelo conceptual discutido no captulo anterior. feita uma avaliao da adequao do modelo para as necessidades do IST e so discutidas as suas limitaes. O captulo 5 detalha o ambiente para os testes efectuados e mostra os resultados mais relevantes relativamente funcionalidade e desempenho da implementao. So utilizadas, sempre que possvel, ferramentas padro do Linux para simular carga, efectuar medies e apresentar os resultados. Cada teste acompanhado de uma avaliao e indicao da sua importncia para a adopo da soluo em redes de produo. As concluses e sugestes de trabalho futuro so apresentadas no captulo 6. O Anexo A apresenta a listagem dos DTD (Document Type Definition, equivalente a um schema de definio de atributos e valores possveis) utilizado para o transporte em formato XML das polticas de alto nvel. O Anexo B contm o schema de polticas de alto nvel no repositrio LDAP. No Anexo C encontra-se um exemplo de PIB para implementao das polticas num encaminhador de fronteira. O script de implementao 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 aplicaes desenvolvidas.

Tecnologias Seleccionadas

2.1 Introduo
Este captulo descreve as tecnologias seleccionadas para a implementao do modelo proposto, algumas em fase de maturao e outras adoptadas com sucesso nas redes empresariais. As tecnologias mais recentes aqui abordadas incluem os conceitos de PolicyBased Networking (no que respeita aplicao de polticas para Qualidade de Servio), Servios Diferenciados (DiffServ), Policy Information Base (PIB) e protocolo COPS. Tambm fazem parte da implementao 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 opo pelo modelo e tecnologias oriundas do IETF justifica-se pelo elevado nmero de trabalhos relacionados com qualquer uma delas e pela adopo e disponibilidade generalizada da maior parte das tecnologias abordadas.

2.2 PBN Policy-Based Networking

2.2.1 Introduo
Em redes corporativas, novas tecnologias no so introduzidas porque estejam normalizadas ou facilmente acessveis, mas se satisfizerem uma necessidade do negcio. As definies das polticas de alto nvel (aquelas visveis ao operador da rede e muitas vezes aos clientes) so condicionadas por estas necessidades, enquanto que as especificidades tecnolgicas limitam a definio das polticas de baixo nvel (visveis pelos equipamentos) [Verma]. O conceito de Policy-Based Networking (PBN) aplicado Qualidade de Servio, permite a definio de polticas de QdS (gesto de prioridades e utilizao de recursos pelos vrios tipos de trfegos em uma rede, de forma a servir eficientemente os utilizadores) em dois nveis: negcio e tecnologia. Primeiramente, as polticas so introduzidas com termos relativamente simples numa estao de administrao. Depois, so traduzidas para uma forma mais adequada do ponto de vista tecnolgico e enviadas para os dispositivos de rede.

2.2.2 Definio de Poltica

A definio de poltica deriva de duas perspectivas [RFC3198]: uma meta, curso ou aco que determina decises presentes e futuras. 7

2. TECNOLOGIAS SELECCIONADAS um conjunto de regras para administrar e controlar o acesso aos recursos de uma rede informtica.

Um sistema baseado em polticas usa as regras de polticas (policy rules) como blocos funcionais bsicos. Estas regras so ligaes entre condies e aces, onde a avaliao das condies determina que aces sero levadas a efeito [RFC3060]. As polticas podem ser formalizadas em alto nvel ou em baixo nvel. As polticas de alto nvel esto especificadas em termos familiares e num formato intuitivo para o administrador ou utilizador da rede. A sua especificao independente da implementao subjacente e pode utilizar qualquer mecanismo que seja adequado, por exemplo, o XML. O IETF tem definido um modelo de informao de polticas para representar, administrar, partilhar e reutilizar a informao de polticas independentemente dos equipamentos especficos em que sero configuradas (ver a seco 2.2.5). As polticas de baixo nvel so formalizadas de maneira que um agente de polticas em cada elemento de rede afectado possa fazer o seu mapeamento para a configurao especfica daquele equipamento. A gerao de polticas de baixo nvel a partir das polticas de alto nvel nem sempre um processo linear ou padronizado, devido s particularidades dos mecanismos de configurao de cada elemento de rede. Um comando de polticas (policy statement) um conjunto de definies para condicionar a atribuio dos recursos da rede aos seus consumidores, que podem ser utilizadores ou sistemas individuais, departamentos, aplicaes, etc. O termo poltica de aprovisionamento define um modelo em que os elementos de rede so configurados por polticas antes de processar quaisquer eventos. A configurao enviada para o dispositivo com base numa escala temporal ou na inicializao do mesmo. Este modelo constrasta com a poltica de outsourcing, em que o agente de poltica no elemento de rede solicita a outro componente decises relativas a eventos especficos. Os dois modelos no so mutuamente exclusivos, podendo ser utilizados em conjunto.

2.2.3 Aprovisionamento de Servios

Neste trabalho, aplicamos as definies que o IETF faz de servio e os termos associados [RFC3198], [RFC3260], no contexto dos Servios Diferenciados. Servio definido como o comportamento ou funcionalidade oferecidos por uma rede, elemento de rede ou sistema. SLA o documento que resulta da negociao entre cliente e provedor referente aos atributos do servio. SLS o conjunto de parmetros e seus valores que definem o servio oferecido a um fluxo de trfego por um domnio DiffServ. TCA (Traffic Conditioning Agreement) o acordo que especifica regras de classificao e os perfis de trfego correspondentes, bem como as regras de medio, marcao, descarte e/ou atraso selectivo a aplicar. TCS (Traffic Conditioning Specification) o conjunto de parmetros e seus valores que no

PBN P OLICY-B ASED NETWORKING todo permitem especificar as regras de classificao e o perfil do trfego no ambiente DiffServ. TCS so parte integral de um SLS. Adicionalmente aos parmetros definidos num TCS, o SLS pode especificar: Disponibilidade e fiabilidade do servio, incluindo o comportamento em cado de faltas. Servios e mecanismos de segurana: encriptao, autenticao, monitorizao e auditoria. Restries de encaminhamento. Definio das responsabilidades em caso de quebra do contrato. Mecanismos de contabilizao.

A avaliao do cumprimento de um contrato baseia-se tambm na qualificao e no contexto do servio. Os servios podem ser categorizados como qualitativos (e.g. trfego com baixo retardo) e quantitativos (e.g. 99% dos pacotes devem ser entregues). O contexto de um servio define a fronteira topolgica onde ele se aplica, incluindo pontos de entrada e pontos de sada do trfego. O IETF sugere [RFC3670] a definio de um conjunto de classes e associaes que representam um nvel de abstraco dos servios. Esse nvel de abstrao permite utilizar uma nomeclatura genrica para os servios, conhecida como Servio Olmpico, com classes Ouro, Prata, Bronze.

2.2.4 Arquitectura
Um comando de poltica de alto nvel utilizado por um administrador da rede deveria ser to natural como: Faa o encaminhamento mais rpido possvel do trfego de videoconferncia oriundo ou destinado sala de reunies entre as 15 e as 16 horas. Na prtica, actualmente so necessrios comandos mais detalhados e tcnicos, mas a evoluo do modelo de polticas numa arquitectura estruturada permite o desenvolvimento de nveis de abstraco elevados. A abordagem do IETF ao modelo PBN [RFC3644], [RFC2753] exemplo desta evoluo e utiliza um framework padro de polticas e protocolos relacionados, que incluem: Uma consola de gesto para permitir criar, editar ou consultar polticas num repositrio, atravs de uma linguagem adequada de especificao. O repositrio, que permite armazenar e reutilizar polticas. O IETF recomenda a sua implementao num directrio LDAP [RFC2475]. Uma Policy Management Tool (PMT), que faz a manuteno e gesto de conflitos entre as polticas. Um servidor conhecido como Policy Decision Point (PDP), que l as polticas no repositrio e faz a sua distribuio aos elementos de rede. O IETF sugere o formato PIB (Policy Information Base) e o protocolo COPS (Common Open Policy Service) para distribuio das polticas. 9

2. TECNOLOGIAS SELECCIONADAS Equipamentos de rede onde as polticas so implementadas para serem aplicadas ao trfego, denominados Policy Enforcement Points (PEP).

Este captulo analisa cada uma das tecnologias que permitem implementar o modelo PBN. No captulo 3 a arquitectura completa analisada em detalhe.

2.2.5 Linguagens de Especificao de Polticas

No h uma linguagem de polticas universalmente aceite. Algumas linguagens so naturalmente proprietrias e ligadas a produtos de gesto particulares. Os domnios de aplicao de uma linguagem de polticas so o controlo de acesso e a gesto 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 (polticas de autorizao) quanto a gesto de recursos (polticas de obrigao). A seguir mostramos dois exemplos de definio de polticas com PONDER: inst auth+ switch ProfileOps { subject /NetworkAdmin; target <PerfilT>/Nregion/switches; action load(),remove(),enable(),disable();} Membros do domnio NetAdmin ficam autorizados a carregar, rremover, habilitar e desabilitar objectos do tipo PerfilT no domnio Nregion/switches. inst auth- /negativeAuth/testRouters { subject /testEngineers/estagiarios; action performance_test(); target /routers;} Os engenheiros em estgio de teste ficam proibidos de realizar testes nos encaminhadores. A poltica fica armazenada no domnio /negativeAuth. Outra aproximao para uma linguagem de especificao de polticas foi a PFDL (Policy Framework Definition Language), que esteve em processo de desenvolvimento pelo IETF. Representava os requisitos do negcio num conjunto de especificaes de polticas e produzia uma forma adequada para a definio e o povoamento do schema. O IETF tem ou teve vrias linguagens de definio de polticas em desenvolvimento (RPSL, RPCL, SPSL, PFDL, PAX, Keynote). Espera-se que elas venham a ser unificadas numa s especificao.

2.2.6 O schema de Polticas do IETF

O IETF definiu, atravs de [RFC3060], um modelo nuclear de informao para polticas PCIM inicial e genrico, ao qual tm sido propostas extenses mais especficas [RFC3460], [RFC3644]. Este modelo est alinhado com as especificaes CIM (Core Information Model) para polticas do DMTF [DMTF]. CIM um modelo orientado a objectos que implementa a abstraco e o modelo de informao necessrios para permitir a gesto das entidades (sistemas e redes) a nveis acima da instrumentao, como mostra a figura 2.1. 10

PBN P OLICY-B ASED NETWORKING O DMTF, via de regra, faz a modelagem da informao independentemente da implementao subjacente, enquanto que o IETF faz a definio de protocolos, schema e Application Programming Interfaces (API). A excepo para o DMTF a iniciativa DEN (Directory Enabled Network), que faz o mapeamento dos conceitos CIM (sistemas, servios, polticas) para um directrio LDAP integrado na infra-estrutura de gesto (ver figura 2.1); e para o IETF as excepes so os modelos de informao para polticas, que entretanto tendem a servir de base para outros RFC com os respectivos modelos de dados e schemas LDAP.

Negcio CIM Servios Rede e Sistemas Componentes e Elementos Figura 2.1: Abstraces do Modelo CIM/DEN este o caso do modelo de informao para polticas, 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 informao de polticas. Para estas classes, o mapeamento do modelo de informao para LDAP directo: classes para classes, propriedades para atributos. Classes de relacionamento, que indicam como as instncias das classes estruturais esto relacionadas. Aqui, o mapeamento feito de trs formas: classes LDAP auxiliares, para atributos que representam referncias a distinguished names (DN) (ver seco 2.5.2) e para relaes entre superior e subordinado na rvore de informao de directrio (DIT). na rede, tem um conjunto Servios

DEN

A representao das polticas de gesto da Qualidade de Servio definida pelo IETF e conhecida por QPIM [RFC3644], ainda no schema oficial associado. um modelo de informao que contm um de abstraces para aplicao da QdS em Servios Integrados e em Diferenciados atravs de polticas.

O QPIM utiliza regras para definir polticas, com base no modelo de informao para polticas (PCIMex [RFC3460]). As polticas e sua respectiva informao so organizadas hierarquicamente, e no h necessidade de serem especificados todos os detalhes da implementao. A atribuio das polticas aos diversos elementos de rede feita atravs dos seus papis (roles) 11

2. TECNOLOGIAS SELECCIONADAS individuais. A utilizao de roles um mecanismo eficiente e simples para aumentar o nvel de abstraco e tornar as definies mais compactas. Vrios dispositivos podem ter o mesmo role, se desejado (por exemplo, o conjunto dos encaminhadores de fronteira, o conjunto dos encaminhadores interiores).

Polticas do Negcio

Topologia

Metodologia QdS

Modelos QPIM/PCIM Capacidades e role do ER Configurao do ER Figura 2.2: Fluxo de Informao na Definio da QdS A figura 2.2 mostra de maneira simplificada o fluxo de informao para definio da Qualidade de Servio num domnio de polticas. O processo dependente da topologia da rede e dos seus dispositivos, das regras e requisitos do negcio e dos servios, 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 funes (roles) relevantes dos dispositivos: fronteira e interior, sada e entrada ou termos equivalentes. As regras do negcio podem ter impacto directo na definio das polticas. Por exemplo, se essencial para o negcio haver chamadas de voz ou teleconferncias sobre redes IP, o trfego correspondente deve ser diferenciado para baixo atraso, baixa variao do atraso e baixa perda. O modelo QPIM utilizado como ajuda para o mapeamento de regras do negcio numa forma adequada para definir os requisitos do condicionamento de trfego na rede.

2.3 Servios Diferenciados

2.3.1 Introduo
Servios Diferenciados (DiffServ) e Servios Integrados (IntServ) so duas arquitecturas definidas pelo IETF para a proviso de qualidade de servio (QdS) em domnios IP. Uma das principais distines entre elas que os Servios Integrados utilizam mecanismos de sinalizao para garantir o cumprimento de um acordo de QdS fim a fim, entre domnios, enquanto que os

12

S ERVIOS D IFERENCIADOS Servios Diferenciados no utilizam sinalizao nem armazenamento de estado dos fluxos e especificam o comportamento dentro de um domnio individual. O IETF define um Domnio Diffserv como um conjunto contguo de encaminhadores a operar com um as mesmas polticas e definies de comportamentos [RFC2475]. Prope, atravs da arquitectura dos Servios Diferenciados (DiffServ), que a QdS pode ser realizada num domnio com a aplicao de regras de agregao do trfego pelos encaminhadores de fronteira, de acordo com um contrato que especifica os perfis do trfego. Este tipo de classificao designada como Behavior Aggregate (BA). Cada agregado fica ligado a um tratamento especfico de transporte pelos encaminhadores interiores, atravs da marcao do campo DSCP (Differentiated Services Codepoint) no cabealho IP. Estes comportamentos especficos so designados de Per-Hop Behavior ou PHB (em oposio a PHD ou Per-Domain Behavior) na arquitectura dos servios diferenciados. O maior mrito do DiffServ encontra-se no comportamento dos encaminhadores de fronteira, onde o trfego passa obrigatoriamente, e medido e agregado. Se necessrio, o trfego tambm pode ser condicionado neste ponto para atender s restries de largura de banda. Uma vez dentro da rede, o trfego fica sujeito aos comportamentos de encaminhamento dos ns interiores baseados no DSCP. Se um conjunto bsico de classes de servio estiver configurado para toda a rede, atribuies de curto prazo de QdS para situaes especficas podem ser implementadas pela alterao da configurao dos encaminhadores de fronteira somente, no sendo necessrio reconfigurar os encaminhadores interiores. O modelo DiffServ adapta-se bem a redes de qualquer dimenso e nmero de utilizadores, pelas razes expostas acima (no orientado a sinalizao e configurao nas fronteiras). Adapta-se tambm ao modelo de negcios e servios em pirmide mostrado na figura 2.1, porque permite o mapeamento dos acordos de nveis de servio (SLA), ou, mais especificamente, dos parmetros das suas especificaes (TCS Traffic Conditioning Specifications) em classes de servio 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 verso 4 do protocolo IP, substitui o antigo byte ToS (Type of Service) no cabealho, enquanto que na verso 6 substitui o octeto Traffic Class. Os seis bits menos significativos do campo DS so 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 Precedncia IP tradicional, como mostra a tabela 2.1. Os bits que se mapeiam para estes oito valores so denominados Class Selector Code Points (CSCP), embora seja normal a abreviao para CS. Precedncia Routine Priority Immediate Flash Flash override CRITIC/ECP Internetwork control Network control Precedncia IP (decimal) 0 1 2 3 4 5 6 7 Precedncia 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 adio 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 so as classes a mapear para os PHB. Nesta tabela, esto tambm indicados os valores ToS correspondentes para o caso em que os bits ECN estejam a zero, porque na implementao alguns parmetros utilizam os oito bits, aplicando ou no uma mscara (0x3) sobre os ltimos dois bits. Nos valores AFxy, x indica o nmero da classe (quatro no total) e y a precedncia de descarte (trs para cada classe). As classes AF so destinadas ao trfego com exigncia de baixa perda de pacotes dentro de uma certa velocidade, mas que no necessita de garantias de atraso. A classe EF define um comportamento com baixo retardo, baixa variao no atraso e pouca perda de pacotes. S h uma classe EF porque no faria sentido ter mais que uma classe com estas exigncias de servio competiriam entre si pelos mesmos recursos.

14

S ERVIOS D IFERENCIADOS Aparentemente, cada classe da tabela 2.2 pode ser directamente associada a um PHB. Entretanto, o IETF esclarece que as classes AF no so PHB individuais, e sim um tipo de grupo de PHB. Cada uma delas (AF1 a AF4) uma instanciao deste tipo de grupo [RFC3260]. 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

Nome Default (BE) AF11 AF12 AF13 AF21 AF22 AF23 AF31 AF32 AF33 AF41 AF42 AF43 EF

Tabela 2.2: Valores DSCP das Classes DiffServ

2.3.3 Arquitectura DiffServ

A arquitectura do modelo de Servios Diferenciados baseia-se nos conceitos de Domnio e Regio DiffServ [RFC2475]. Um Domnio DiffServ definido como um conjunto contguo de encaminhadores com as mesmas polticas e definies de comportamento PHB. Uma Regio DiffServ um conjunto contguo de domnios DiffServ onde os servios diferenciados podem ser oferecidos de maneira global relativamente a estes domnios. Se numa regio DiffServ todos os domnios adoptarem as mesmas polticas de aprovisionamento de recursos e suportarem PHB compatveis (a nvel do mapeamento do campo DSCP para as classes DiffServ e das caractersticas de cada classe), fica eliminada a necessidade de negociao (SLA, TCS) entre eles. Caso contrrio, ser necessrio estabelecer os condicionamentos apropriados nas fronteiras internas da regio.

15

2. TECNOLOGIAS SELECCIONADAS Num domnio DiffServ, so distinguidos os encaminhadores de fronteira dos interiores, como mostrado na figura 2.4. Um encaminhador de fronteira de um domnio DiffServ liga-se a um encaminhador de outro domnio, que pode ou no ser um domnio DiffServ. Domnios DiffServ contguos formam regies DiffServ. O facto de uma regio DiffServ ter potencialmente mais que uma ligao a outras redes, como mostrado na figura, requer um planeamento cuidadoso para um conjunto consistente de polticas comuns para os pacotes que entram e saem da regio. Domnio DiffServ N de Fronteira N Interior N Interior N de Fronteira Regio DiffServ N Interior N Interior N Interior N Interior Ligao a outras redes

N de Fronteira

Domnio DiffServ

N de Fronteira

Ligao a outras redes

Figura 2.4: Arquitectura do Modelo de Servios Diferenciados Um encaminhador de fronteira geralmente utilizado como encaminhador de sada e de entrada (egress/ingress router) para diferentes direces do trfego. Funcionalmente, o modelo sugere tratamentos diferentes para os trfegos de entrada e de sada, fazendo distino entre n de entrada (ingress node) e n de sada (egress node). O trfego sai do domnio DiffServ pelo egress node e entra no domnio DiffServ pelo ingress node. O modelo DiffServ prev [RFC2475] que os encaminhadores de fronteira faam a classificao e possivelmente o condicionamento do trfego, e sua associao 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 funes limitadas de condicionamento, tal como a remarcao do campo DSCP. Entretanto, isto poderia levar a comportamentos inconsistentes no domnio DiffServ, sendo recomendado que apenas faam o shaping (retardo selectivo) definido pelos PHB.

16

S ERVIOS D IFERENCIADOS

2.3.4 Sobre Algumas Disciplinas de Filas e Termos Associados

Tokens e Buckets: para controlar a sada de pacotes de uma fila, pode-se calcular a utilizao e tempo de permanncia por unidade de informao (pacotes ou bytes). Ao invs disto, um mtodo utilizado largamente no controlo do trfego 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 disponvel (mecanismo de atraso selectivo ou shaping). Tokens podem ser emitidas mesmo se no houver trfego, e encher um bucket (balde) at a sua capacidade. Neste caso, todas as tokens disponveis num bucket podem ser utilizadas sem restries de tempo. Buckets so considerados um conceito chave para o suporte a trfego caracterizado por rajadas de dados (bursts), como o caso do HTTP. CBQ a disciplina mais complexa disponvel. 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 medies imprecisas da disponibilidade de uma conexo, e o excessivo nmero de parmetros a configurar. HTB (Hierarquical Token Bucket) uma queuing discipline disciplina de filas escrita por Martin Devera (que elabora alguns comentrios no site http://luxik.cdi.cz/~devik/qos/htb/old/htbmeas1.htm) e foi recentemente implementada no kernel Linux. Tem substitudo a disciplina tradicional CBQ em implementaes [Hubert]. Considera-se que HTB tem um design mais claro, com melhor suporte e comandos mais simples. A sua utilizao ao invs de CBQ d origem a melhores resultados a nvel de comportamento geral (mesmas referncias). CBQ e HTB so disciplinas de filas hierrquicas com partilha de conexo (linksharing) entre classes, garantindo uma percentagem da largura de banda para cada classe mesmo durante congesto do trfego e dividindo entre todas a largura de banda no utilizada por qualquer delas (em excesso) [Floyd95b]. Uma disciplina hierrquica pode condicionar a diviso da largura de banda entre organizaes, famlias de protocolos, classes de servios e conexes individuais dentro de uma classe de servios (nem todas estas estruturas necessitam de estar sempre presentes). SFQ (Stochastic Fairness Queuing): baseia-se na famlia de algoritmos FQ, que classifica e distribui pacotes em trnsito, associando um pacote a uma de vrias 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 endereos, portas e protocolos. Emprega um algoritmo de hashing que divide o trfego por um nmero limitado de filas. Alteraes frequentes neste algoritmo de hashing evitam colises de mais de alguns segundos entre quaisquer duas sesses. Os seus parmetros incluem a indicao do nmero de segundos para reconfigurar o hashing, a quantidade mxima de bytes que podem sair da fila para cada fluxo de dados, por vez, e o nmero 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 parmetros depth, limit, e opes para a tabela de hashing, incluindo a utilizao de apenas o endereo de origem ou de destino e o nmero de linhas da tabela (at um nmero 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 diferenciao 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 to logo quanto seja possvel, antes que a fila esteja cheia, para indicar que est iminente uma situao de congesto. Os descartes so distribudos mais equitativamente entre todos os fluxos. O mecanismo de implementao baseado no controlo do tamanho mdio das filas. Fluxos no orientados a conexo, como o UDP, so indirectamente limitados pelo controlo do limite mximo deste tamanho mdio. So estabelecidos dois limites (thresholds), abaixo dos quais nenhum pacote marcado para descarte. Acima do limite superior do tamanho mdio da fila, todos os pacotes so descartados. Na regio entre os dois limites, pacotes so descartados em funo de uma probabilidade pa (funo do tamanho mdio da fila).

2.3.5 Classificao e Condicionamento do Trfego

Os parmetros dos acordos de servio a serem honrados pelo domnio DiffServ podem especificar, ou exigir implicitamente, a existncia de regras para classificao e remarcao dos pacotes, e tambm definies para perfis de trfego e as medidas a serem accionadas para fluxos de trfego dentro ou fora de perfil. Uma poltica de classificao identifica os pacotes candidatos a um servio diferenciado atravs do seu condicionamento e/ou mapeamento do campo DSCP para um ou mais behavior aggregates a que ficaro sujeitos dentro do domnio. Classificadores de BA utilizam exclusivamente o cdigo DSCP para classificar pacotes, enquanto que os classificadores que analisam um ou mais campos no cabealho do pacote so denominados classificadores de campo mltiplo. A utilizao de classificadores em cascata permite uma classificao mais detalhada em cada transio de um classificador para outro. O condicionamento do trfego assegura que este est de acordo com a poltica de aprovisionamento de servios do domnio. Para isto, pode realizar as seguintes aces: Medio: os mdulos de medio medem as propriedades temporais de um fluxo de trfego seleccionado por um classificador, comparando-as com o perfil configurado. Outras funes de condicionamento recebem as informaes dos mdulos de medio e podem realizar aces em resultado destas medies para cada pacote dentro ou fora de perfil.

18

S ERVIOS D IFERENCIADOS Atraso Selectivo 1: para fazer com que um fluxo de trfego esteja de acordo com o perfil respectivo, mdulos de atraso selectivo retardam alguns ou todos os pacotes deste fluxo, aumentando implicitamente a probabilidade de descarte destes pacotes devido falta de espao para os armazenar temporariamente (buffer). Policiamento: efectuado por mdulos de descarte, consiste em eliminar alguns ou todos os pacotes em um fluxo de trfego para que este fique de acordo com o perfil respectivo. Um mdulo de atraso selectivo com o tamanho do buffer muito pequeno ou igual a zero comporta-se como um mdulo de descarte. Remarcao: os mdulos de marcao configuram o campo DS de um pacote com um codepoint particular relacionado a um behavior aggregate especfico. Quando o codepoint de um pacote alterado, ento ocorreu a remarcao deste pacote. A alterao 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-marcao na rede de origem do pacote.

A pr-marcao de pacotes pela rede de origem tem a vantagem de diminuir o nmero de regras necessrias no encaminhador de fronteira da rede de destino, mas este continua a ter a responsabilidade de assegurar que todo o trfego est conforme os acordos de servios 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 classificao e o condicionamento do trfego, e algumas opes de implementao.
Medidor

Classificador

Condic. do Trfego

Gesto do Buffer

Scheduler (Escalonador)

Shaper/ Descartador

Figura 2.5: Mdulos de Classificao e Condicionamento do Trfego Na seco 3.3.3 sero apresentadas e discutidas algumas possveis opes de implementao para estes blocos funcionais. Os condicionadores de trfego e classificadores de campo mltiplo devem estar localizados nos encaminhadores de sada e de entrada de fronteira do domnio. Tambm podem existir nos encaminhadores interiores.

O termo em ingls shaping.

19

2. TECNOLOGIAS SELECCIONADAS

2.3.6 Per-Hop Behaviors

Um per-hop behavior (PHB) o tratamento (visvel externamente) que cada encaminhador DiffServ aplica a um behavior aggregate especfico (coleco de pacotes com o mesmo cdigo DSCP), com a atribuio de recursos necessrios e restrio do acesso aos recursos demandados por instncias mais prioritrias [RFC2475]. O equivalente ao PHB para todo o domnio o PDB (Per-Domain Behavior), que descreve o comportamento dos pacotes com um mesmo cdigo DSCP a atravessar um domnio DiffServ. A utilidade dos PDB definir as caractersticas mensurveis que podem ser utilizadas num SLA ou SLS. Faz parte da arquitectura DiffServ a especificao de classes de servios diferenciados em adio classe tradicional das redes IP, BE (Best Effort) [RFC3246], [RFC2597], para qualificar os agregados de trfego. Os PHB utilizados nesta implementao so o BE (Default), EF e grupo AF (ver tabela 2.2). Como j foi dito, AF no um PHB, mas sim um tipo de grupo PHB. Cada classe AF uma instncia deste tipo de grupo. O modelo DiffServ original foi revisto para corrigir algumas inconsistncias sobre o tratamento dado a cdigos DSCP no reconhecidos [RFC3260]. Actualmente, definido que pacotes com cdigos DSCP invlidos 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 no forem considerados pertencentes a outro agregado. O trfego neste agregado tem o tratamento Best Effort (BE), e o cdigo DSCP recomendado o 0x00. A utilizao 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 aproximao probabilstica a pacotes em posies aleatrias na fila (no s da cauda e no s da cabea) [Floyd93], de acordo com a filosofia do tratamento Best Effort. O PHB EF (Expedited Forwarding) utilizado para atender a servios com requisitos semelhantes aos da utilizao de um canal virtual privativo. Suas propriedades tpicas incluem baixo atraso, baixa variao do atraso (jitter), baixa perda de pacotes e largura de banda garantida [RFC3246]. O DSCP recomendado o 0x2e. Este PHB foi revisto em relao ao RFC original, para obter maior formalismo matemtico em benefcio de uma definio mais rigorosa do comportamento associado. O trfego EF que no ultrapasse o ritmo limite especificado deve obter todas as caractersticas citadas, o que pode requerer policiamento ou atraso selectivo nos encaminhadores de fronteira. recomendado que as implementaes tenham alguma tolerncia relativamente s rajadas (quantidade de dados que podem ser enviados antes que outra classe seja atendida) para no inviabilizar a agregao de fluxos. O trfego EF que ultrapasse o ritmo mximo definido descartado. A utilizao 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 servio particular. O grupo PHB AF (Assured Forwarding) contm quatro classes, cada uma com trs nveis de precedncia de descarte dos pacotes [RFC2597]. O principal objectivo deste grupo fornecer um conjunto de servios em que h baixa probabilidade de descarte dos pacotes se o trfego obedecer aos parmetros predefinidos. Dentro de cada classe AF, os pacotes tm uma de trs possveis precedncias de descarte. Em caso de congestionamento, os pacotes com um valor maior de precedncia de descarte so eliminados em primeiro lugar. A implementao prtica do grupo AF leva a que cada precedncia de descarte esteja geralmente associada a uma fila virtual RED, a mais adequada para atender aos requisitos do IETF. Na implementao, isto conseguido com a atribuio da disciplina GRED (Generalized RED) classe principal (AF1, AF2, AF3, AF4). Este tipo de fila permite definir vrias filas virtuais, cada uma fazendo a marcao aleatria nos seus pacotes para descarte tpica do modelo RED. Um pacote direccionado dentro de uma classe AF para uma ou outra fila virtual (com a respectiva precedncia de descarte) atravs do seu DSCP (o procedimento para obter este valor num encaminhador Linux demonstrado no captulo 4).

2.4 XML
2.4.1 Introduo
Uma representao textual da informao de gesto pode no ser suficiente ou adequada para ser esta informao ser transferida em ambientes heterogneos [Hegering]. Isto leva necessidade de uma linguagem consistente para especificar os parmetros de gesto. No caso do framework de polticas do IETF, uma vez que a linguagem no faz parte desta especificao, fica ao critrio de cada implementao 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 informao estrutural e semntica dos elementos individuais so as tags de incio e fim, elas prprias delimitadas pelos caracteres < e >: <SLA> <SlaID>sla2907041833</SlaID> <Classe>EF</Classe> <SLA> As tags so sensveis a maisculas e minsculas. A utilizao do formato XML requer que os intervenientes sejam capazes de estruturar e validar correctamente a informao transferida. Para este efeito, as 21

2. TECNOLOGIAS SELECCIONADAS linguagens de programao e navegadores Internet dispem de livrarias que permitem implementar "parsers" (verificadores) XML. Ao nvel da programao e no interesse da interoperabilidade, convm que a aplicao possa reconhecer, validar os atributos e aplicar comportamentos especficos ao elementos de um documento XML, e tambm guardar e reutilizar informao neste formato.

2.4.2 DTD e Schema

Adicionalmente, um documento XML pode basear-se numa "gramtica" descrita em um documento acessrio do tipo DTD (Document Type Definition) ou do tipo XML Schema. Estes documentos contm os elementos, atributos, entidades e notaes utilizados num documento XML que faa referncia a eles. Um documento estruturado de acordo com a especificao XML [W3CXML] dito "bem formado". As regras mais importantes so: No devem ocorrer tags de incio sem a correspondente tag de fim. As tags no devem ser sobrepostas, ou seja, no se deve fechar um elemento aps a tag de fim do elemento que o contm. <elemento 1 incio> ... <elemento 2 incio> ... <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 invs de < > Usar &lt; &gt; &quot;

Tabela 2.3: Entidades Especiais em XML Se, alm de bem formado, o contedo do documento estiver de acordo com a gramtica especificada no DTD ou no schema, ele um documento "vlido". O exemplo simples a seguir ilustra este conceito. No DTD h um elemento raiz denominado rede que tem dois possveis 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>Informtica</subrede> <subrede>Assessoria</subrede> <child>Switch22</child> <child>Laser43</child> </family> Este seria um documento XML vlido. Entretanto, se forem acrescentadas tags ao documento de acordo com o exemplo a seguir, este deixa de ser vlido enquanto o DTD correspondente no for alterado: <rede> Esta a rede da empresa: <subrede>Informtica</subrede> ... Um DTD pode ser armazenado internamente ou externamente ao documento XML. Se for interno, dever estar entre a declarao XML e o elemento raiz no documento. Um DTD externo armazenado num documento separado do XML, tendo a vantagem de ser reutilizvel por vrios documentos XML. Declaraes DTD internas tm precedncia sobre declaraes externas, e cada documento XML pode estar associado a exactamente um DTD atravs da declarao DOCTYPE. A utilizao de um schema ao invs do DTD uma proposio da Microsoft recentemente adoptada pelo W3C. Acrescenta complexidade ao processo, mas traz vantagens [W3CXML]: Suportam diferentes tipos de dados e restries, padres e converses entre eles. Utilizam a sintaxe XML. Tornam os dados mais consistentes, ao defin-los exactamente (por exemplo, os diferentes formatos de dados tipo data). So extensveis e reutilizveis.

Optmos por aderir ao DTD neste trabalho, mas pensamos que seria vantajosa a utilizao do schema para a integridade da informao.

2.4.3 Estrutura do Documento XML

Um documento XML deve iniciar por uma declarao XML, que define a verso e a codificaes utilizadas no documento: <?xml version=1.0 encoding=ISSO-8859-1?> A seguir declarao XML, vem a indicao do elemento raiz do documento, ou a declarao 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 incio e fim: 23

2. TECNOLOGIAS SELECCIONADAS <elemento_raiz> </elemento_raiz> Os principais blocos funcionais do XML so os elementos, que representam logicamente os objectos. Os elementos podem conter texto ou uma hierarquia de outros elementos. A qualificao dos elementos feita atravs dos seus atributos ou dos seus elementos filhos. Geralmente, indiferente do ponto de vista semntico utilizar atributos ou elementos para implementar as propriedades de um objecto, mas os elementos so mais adequados do ponto de vista funcional [W3CXML]. Os tipos mais comuns dos elementos so EMPTY ou carcter (PCDATA ou CDATA). Outros tipos incluem ANY e de contedo misto. O elemento tipo ANY pode conter quaisquer dados XML bem formados, zero ou mais elementos filhos de qualquer tipo declarado, ou dados tipo carcter. Como isto contrrio filosofia de consistncia do XML, a melhor opo no utilizar este tipo de elemento. Elementos tipo EMPTY no contm dados nem elementos filhos; so apenas repositrios de atributos. A palavra-chave EMPTY pode ser omitida na sua declarao. Elementos EMPTY podem ser utilizados no DTD para definir os parmetros de configurao 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) detm os atributos SLAid, TCSid, Src_IP (e possivelmente outros). Um documento XML vlido baseado neste DTD poderia incluir o seguinte conjunto de declaraes: <TCS SLAid=sla1809041200 TCSid=bar3009042030 Src_IP=150.32.125.00/24 > </TCS> Os atributos devem estar sempre delimitados por aspas. Os elementos tipo carcter so tipos de dados fundamentais do XML, podendo ser validados ou ignorados pelo parser (PCDATA parsed character data ou CDATA character data, respectivamente). Elementos de contedo misto podem ser criados com um elemento tipo carcter e elementos filhos. Se o elemento carcter existir, o tipo de elemento misto ou carcter. Se no existir o elemento carcter, o tipo de elemento somente elemento.

24

XML A declarao dos elementos filhos pode utilizar listas de sequncias ou listas de escolha. Em qualquer caso, operadores cardinais podem ser utilizados para indicar quantos filhos podem aparecer numa declarao: <!ELEMENT E1 (E2*, E3, (E4|E5)?, E6+)> Neste exemplo, o elemento filho E2 opcional e pode ocorrer mltiplas vezes, o elemento E6 obrigatrio e pode ocorrer mltiplas vezes, os elementos E4 e E5 so 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 representao que o XML faz da informao estruturada como numa base de dados facilita a sua converso para rvores de objectos em linguagens de programao. A recomendao DOM (Document Object Model) Nvel 2 do W3C [W3CDOM] descreve as interfaces necessrias para representar qualquer documento XML bem formado, permitindo a sua manipulao 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 mtodos definidos pelo programador em outra classe, na interface DocumentHandler. O objecto Parser l o cdigo XML e usa os mtodos 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 mtodos 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("Contm " + numTcs + " TCS."); } };

2.5 LDAP
2.5.1 Introduo
Um directrio uma base de dados local ou distribuda, optimizada para leitura, navegao e pesquisas [OpenLDAP]. Um servio global deve definir um espao de nomes (namespace) para que a viso dos dados seja independente do local de onde so vistos. Descrito pelo IETF nos RFC 2251-2256, 2829-2830, o LDAP (Lightweight Directory Access Protocol) era inicialmente uma extenso do protocolo X.500 para utilizao num ambiente IP. Como o nome sugere, um protocolo que requer poucos recursos para acesso a servios de directrio sobre protocolos orientados a conexo. O directrio LDAP permite agrupar em um nico local informaes dispersas de acesso, autenticao e autorizao. Sua estrutura lgica baseia-se no conceito de entrada (entry) que contm informao sobre algum objecto (por exemplo, um SLA ou um BAR). As entradas tm atributos com sintaxe, tipo e valor(es).

26

LDAP

2.5.2 Estrutura da Informao LDAP

As entradas LDAP organizam-se numa estrutura de rvore, denominada Diretory Information Tree (DIT). Cada objecto da rvore globalmente identificado de forma nica atravs do seu Distinguished Name (dn): dn: tcs=TCS1, cn=tcs, cn=Acordos de Servico, ou=CIIST, o=Instituto Superior Tecnico, c=pt

A informao acima est no formato LDAP Data Interchange Format (LDIF). Este formato representa as entradas do directrio LDAP como texto, de modo a facilitar a sua manipulao. Os valores para os atributos podem ser UTF-8 ou dados codificados base 64 (dados binrios), ou um URL pode ser fornecido para a localizao do valor real do atributo. O par atributo-valor tcs=TCS1 o Relative Distinguished Name (RDN) desta entrada (relativamente s entradas do mesmo nvel). 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 grfica da informao exemplificada.

c=pt

c=es o=Instituto Superior Tecnico ou=CIIST cn=Acordos de Servico

cn= classeQdS

cn=sla

cn=tcs

classe=Diamante

Figura 2.6: Uma rvore de Informao de Directrio (DIT)

slaId=SLA 1

slaId=SL

tcsId=TCS 1

O LDAP permite controlar quais atributos so requeridos e permitidos em uma entrada atravs 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 so cadeias numricas atribudas hierarquicamente, o que implica que somente a autoridade para 5.5.5 pode dizer o que significa 5.5.5.1. A definio formal dos OID de responsabilidade da ITU (International Telecommunications Union) atravs da sua recomendao X.680 (ASN.1) [X680]. Vrios 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 definio de ObjectClassDescription feita pelo IETF est resumida na tabela 2.4. Em geral, cada entrada faz referncia 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 Descrio Identificador da Objectclass Descrio true se obsoleto, false ou ausente se no 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 obrigatrios Conjunto de atributos opcionais

Tabela 2.4: ObjectClassDescription (RFC 2252)

2.5.3 Acesso, Autenticao e Autorizao

O servio de directrio LDAP baseado no modelo cliente-servidor. A rvore do directrio pode estar distribuda por diversos servidores. O acesso dos clientes feito directamente ao servidor que armazena os elementos de dados desejados, ou atravs de um servio de referncia (referral) que redirecciona a solicitao do cliente para outro servidor caso a solicitao no se refira ao espao de nomes local (ver figura 2.7). 3. Nova solicitao Servidor Superior

1. Solicitao Cliente 2. Referncia Figura 2.7: Funcionamento do referral 28 Servidor

LDAP O acesso aos servios LDAP est condicionado autenticao do utilizador. Este mecanismo informa o servidor LDAP quem est a aceder aos dados e com que privilgios. H trs tipos de autenticao: annima, simples e SASL (Simple Authentication and Security Layer). SASL inclui autenticao e encriptao da sesso entre o servidor e o cliente [RFC2222, podendo ser utilizado com Kerberos [RFC1510], TLS (Transport Layer Security) [RFC2246] ou outro protocolo de segurana. Se a autenticao do cliente tiver sucesso, cada vez que o servidor receber uma solicitao vai verificar os privilgios do cliente para aquela aco em particular. Este processo a autorizao e baseia-se em listas de controlo de acesso (ACL). Cada entrada numa ACL um atributo que pode ser associado a qualquer entrada no directrio.

2.5.4 Operaes LDAP

A verso 3 do LDAP suporta as seguintes operaes de manipulao dos dados: Bind, Unbind, Search, Modify, Add, Delete, Modify DN, Compare, Abandon, Extended [RFC2251]. A tabela 2.5 faz a descrio bsica destes comandos. Comando LDAP bind unbind Search Modify Add Delete Modify DN Abandon Extended Descrio Inicia uma sesso com o servidor LDAP Encerra a sesso com o servidor LDAP Pesquisa uma entrada no directrio Modifica uma entrada no directrio Acrescenta uma entrada ao directrio Elimina uma entrada no directrio Modifica o distinguished name de uma entrada Cancela uma operao em progresso Permite definir novas operaes Tabela 2.5: Comandos LDAP Os comandos LDAP podem ser agrupados funcionalmente da seguinte forma: As operaes Add, Delete e Modify alteram as entradas do directrio. As operaes Bind e Unbind iniciam ou terminam o processo de autenticao entre o cliente e o servidor LDAP relativamente a directrios especficos. A operao Search localiza elementos ou servios especficos na rvore. A operao Compare permite o teste de parmetros das aplicaes contra a informao armazenada no directrio LDAP. A operao Modify DN permite alterar o nome de uma entrada. A operao Abandon cancela uma operao em desenvolvimento. A operao Extended permite que os clientes faam pedidos e recebam respostas no padro, mas com sintaxe e semntica personalizadas. 29

2. TECNOLOGIAS SELECCIONADAS Assim, podem ser definidas novas operaes para servios no disponveis. Um exemplo desta funcionalidade so as operaes 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 servios de directrio LDAP verso 3 atravs de mecanismos sncronos e assncronos que atendem a todas as possibilidades de solicitaes e respostas possveis do protocolo [JLDAP]. As classes LDAP deste draft so limitadas s funcionalidades definidas nos RFC e drafts do IETF, oferecendo compatibilidade binria com outras implementaes da API LDAP em Java. A API propriamente dita est disponvel em fonte e como livraria java (.jar). No primeiro caso, encontra-se em http://www.openldap.org/jldap e, para se fazer o build, so necessrios o JSDK (Java Software Development Kit), as classes JSSE (que permitem construir conexes SSL) e a ferramenta Ant. Os dois primeiros requisitos esto disponveis no site http://java.sun.com, e o outro em http://jakarta.apache.org. As livrarias compiladas esto disponveis em http://developer.novell.com/ndk. O site OpenLDAP e o site da Novell oferecem vrios exemplos de programas em Java que utilizam a livraria LDAP. A classe principal da livraria chama-se LDAPConnection, e disponibiliza mtodos para estabelecer uma conexo annima ou autenticada ao servidor LDAP. Tambm tem mtodos para pesquisar, modificar, comparar e eliminar entradas no directrio, com parmetros para nmero de entradas retornadas, limites de timeout e outros. Uma pesquisa sncrona resulta num objecto LDAPSearchResults, que d acesso s entradas encontradas. Cada entrada representada por um objecto LDAPEntry e os seus atributos esto em objectos LDAPAttribute como arrays de bytes ou como cadeias de caracteres. A utilizao da API por uma aplicao pode ser feita em quatro passos: 1. Iniciar uma sesso com um servidor LDAP atravs da construo de uma conexo: mtodo LDAPConnection.connect(). 2. Enviar as credenciais da sesso para fazer a autenticao com o servidor LDAP: mtodo LDAPConnection.bind(). 3. Realizar as operaes desejadas e obter os resultados. 4. Encerrar a conexo: mtodo LDAPConnection.disconnect(). Quaisquer erros resultam numa LDAPException, a indicar o cdigo do erro e a informao especfica de contexto disponvel.

30

PIB

2.6 PIB
2.6.1 Introduo
Uma Policy Information Base (PIB) define classes de aprovisionamento que permitem mapear os requisitos de servio para as capacidades e utilizao dos dispositivos, funcionando como interface entre as polticas de alto nvel e o agente de polticas nos elementos de rede. A estrutura de especificao dos PIB descrita pela SPPI (Structure of Policy Provisioning Information), permitindo que a informao de polticas seja transportada atravs da rede at ao agente responsvel pela configurao de um dispositivo especfico. O conjunto bsico de classes de aprovisionamento de polticas (PRC Provisioning Classes) definidas pelo IETF chama-se Framework Policy Information Base [RFC3318] e inclui tambm as convenes textuais (definio de tipos de dados) comuns a todos os clientes de aprovisionamento de polticas. O IETF definiu ainda um mdulo PIB para dispositivos que implementem a arquitectura DiffServ [RFC3317]. As classes de aprovisionamento definidas neste mdulo permitem o controlo pelas polticas dos recursos que implementam os Servios Diferenciados.

2.6.2 Conceitos Gerais

De forma a ser possvel obter um nvel de abstraco na definio de polticas destinadas a equipamentos e interfaces com funcionalidades distintas, os PIB apoiam-se fundamentalmente no conceito de role, que identifica a funo ou papel desempenhado pelo dispositivo ou interface. Assim, ao invs de especificar polticas explicitamente para cada interface de cada dispositivo da rede, a especificao 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 simultneo. 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 instncias da respectiva classe de aprovisionamento. A lista de interfaces e os seus respectivos roles so enviados pelo agente de configurao de polticas num elemento de rede ao servidor de aprovisionamento, quando da inicializao do elemento de rede. Em resposta, o servidor de aprovisionamento pode enviar polticas para serem aplicadas pelo agente do elemento de rede. A qualquer momento futuro, o servidor de aprovisionamento pode enviar actualizaes das polticas para uma interface ou para um agregado de interfaces, devido a uma solicitao especfica do agente (por mudana do role das interfaces) ou em funo de uma alterao nas prprias polticas. No modelo de aprovisionamento, a informao de polticas uma coleco de classes de aprovisionamento (PRC) e instncias de aprovisionamento (PRI) que 31

2. TECNOLOGIAS SELECCIONADAS residem em uma base de dados virtual, a PIB. Um mdulo PIB contm coleces de classes de aprovisionamento relacionadas [RFC3084]. As classes de aprovisionamento PRC, quando instanciadas, so denominadas PRI (Provisioning Instance). Tambm usual nas definies do IETF a utilizao dos termos PDP (Policy Decision Point) e PEP (Policy Enforcement Point) para fazer referncia respectivamente ao servidor de aprovisionamento e ao agente (um cliente do PDP) que vai receber as polticas. Estas designaes sero detalhadas na seco 2.7, onde abordamos o COPS (Common Open Police Service) [RFC2748] e o COPS-PR (COPS Usage for Policy Provisioning) [RFC3084].

2.6.3 Relao com MIB

O formato em que os mdulos MIB (Management Information Base) do SNMP so 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 mdulos PIB [RFC3159]. Por sua vez, a SMI utiliza um subconjunto adaptado da linguagem de definio de dados ASN.1 [X680]. Uma das principais diferenas entre SMI e SPPI de que a SPPI no utiliza o termo objecto, mas sim classe de aprovisionamento (PRC) para definir tabelas e registos, e instncia de aprovisionamento (PRI) para uma instanciao de uma definio de registo. Alm disso, a SPPI utiliza o termo atributo como referncia aos campos (columnar object) da definio de uma tabela, no suportando o equivalente dos objectos escalares da SMI. A SPPI utiliza as seguintes estruturas da SMI: MODULE-IDENTITY: utilizada para definir a semntica de um mdulo PIB. OBJECT-TYPE: utilizada para definir a sintaxe e a semntica dos PRC e seus atributos. TEXTUAL CONVENTION: permite a definio de novos tipos de dados com sintaxe e semntica particulares, comuns a vrios atributos de um ou mais PRC. OBJECT-GROUP e MODULE-COMPLIANCE: utilizadas para especificar limites aceitveis da implementao dos atributos dos PRC.

Todas as PRC tm um OID (Object Identifier) relativo ao OID raiz do mdulo. Tal como no SNMP, os OID so utilizados para identificar tabelas e atributos. O termo PRID (Provisioning Instance Identifier) refere-se conjuno entre o OID e o identificador de uma instncia (InstanceId). PPRID (Prefix PRID) utilizado para fazer referncia a vrios PRID simultaneamente, por exemplo quando o servidor de aprovisionamento deseja remover mltiplos PRID de uma s vez.

32

PIB

2.6.4 Operao
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 no 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 Descrio Indica que tabelas PIB o cliente suporta Indica limitaes no suporte a atributos Especifica a incarnao PIB activa Contm informao do cliente (tamanho mximo da mensagem e outros) Descreve as interfaces do cliente Direco (egress, ingress, both) Indica as facilidades de classificao 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 nmero de filas Algoritmos de shaping Mximo nmero de componentes DiffServ no caminho de um fluxo de pacotes Ordem em que os componentes funcionais do data path podem ser ligados Descreve as combinaes de roles que as interfaces do cliente tm

Tabela 2.6: Hierarquia de Tabelas PIB na Mensagem notify A aplicao integral da arquitectura DiffServ requer tambm o suporte por todas as entidades envolvidas dos protocolos COPS e COPS-PR. A solicitao inicial do cliente para o servidor de aprovisionamento ocorre quando o cliente inicializa ou sempre que cliente e servidor perdem uma sesso (por exemplo, o servidor reinicializou) e iniciam outra. Esta solicitao contm informao do cliente essencial para o trabalho do servidor, tal como as descries e caractersticas das interfaces, capacidade de implementao dos componentes da arquitectura DiffServ (medies, queuing e escalonamento ver seces 2.3.3 e 2.3.4) e ainda todas as PRC em ambos os PIB (framework e DiffServ) com a caracterstica notify. Esta solicitao particular pode por isso ser referida somente por notify. As principais tabelas utilizadas na mensagem notify esto 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 incarnao 2 do PIB com a configurao esttica 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 tm um conjunto esttico de PHB e no fazem marcaes de pacotes. Novas polticas so tendencialmente aplicadas apenas aos encaminhadores de fronteira (seco 2.3.6). medida que chegam os momentos de honrar polticas com reserva de recursos (por exemplo, para atender a uma videoconferncia), 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 descrio 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 Descrio Activa/desactiva incarnaes 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 trfego com base nos campos do cabealho IP Utilizada para filtrar trfego com base em endereos Ethernet e Ids VLAN Define medidores (encadeados se necessrio) Parmetros para os medidores Aco de um bloco de aco especfico Aces especificadas pelos atributos de marcao Especifica droppers aleatrios e outros Parmetros para um random dropper Representa uma fila FIFO Parmetros da fila Parmetros da fila Especifica um escalonador para seleccionar pacotes das filas Parmetros do escalonador Parmetros do escalonador

Tabela 2.7: Hierarquia de Tabelas PIB na Mensagem install Quando uma solicitao de reserva de recursos expira, o servidor instrui os seus clientes para eliminar as tabelas PIB correspondentes.
2

Em ingls, incarnation

34

PIB

2.6.5 O PIB DiffServ

A estruturao do PIB DiffServ segue o modelo informal de gesto dos Servios Diferenciados definido em [RFC3290], que mostra como modelar as interfaces de entrada e de sada de um encaminhador. Tambm descreve a configurao e gesto 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, aces, algorithmic droppers, filas e escalonadores. Um data path a sequncia de elementos de processamento que podem lidar com um pacote IP de forma a que ele obtenha o correcto tratamento DiffServ. O trfego pode ser classificado (por um filtro ou uma ACL); depois de classificado o trfego pode ser marcado com um cdigo DSCP (por um marcador); o trfego 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 excepo do escalonador, como mostrado na figura 2.8. Pode acontecer que o tratamento para qualquer pacote torne necessria a repetio de um ou mais destes elementos numa sequncia no permitida. Esta situao pode ser ultrapassada com a modelagem de mltiplos TCB em cascata, atravs do atributo Next dos vrios elementos. Na ptica da relevncia 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. No lida com interfaces individuais. - DiffServ Policy Group: contm as configuraes dos elementos funcionais de uma poltica. O PIB DiffServ representa a sequncia de TCB que podem actuar sobre um pacote atravs dos atributos Next dos vrios elementos. O conceito de TCB a um nvel mais elevado que a modelagem dos seus elementos individuais no requerido na parametrizao ou na juno dos elementos. Isto permite que qualquer grupo de elementos construa um TCB, e minimiza alteraes a este PIB se as regras mudarem. So utilizadas diferentes tabelas e definies de dados para (a) a configurao dos tratamentos sequenciais a serem aplicados a um pacote e (b) a parametrizao destes tratamentos. usada a noo de Data Path para indicar um processamento DiffServ. O data path individualizado pela combinao de funes (Role Combination), conjunto de capacidades (capability Set) e direco do fluxo de um pacote. Uma entrada na tabela Data Path indica o primeiro elemento (possivelmente de vrios)que vai aplicar tratamento DiffServ ao pacote. O PIB tambm inclui tabelas que descrevem as funcionalidades e limitaes do equipamento. Estas tabelas devem ser reportadas ao PDP para que este determine a configurao dos elementos funcionais do equipamento. O PDP deve ter controlo de todas as instncias PRI do PEP.

35

2. TECNOLOGIAS SELECCIONADAS

Classificador

Elemento Elemento Elemento Classificador Classificador Classificador Classificador Medidor

Classificador Medidor Aco Alg. Dropper Fila Classificador Medidor Aco Alg. Dropper Fila

Medidor

Aco Alg. Dropper Fila

Aco Poltica Classificador Medidor Alg. Dropper Aco Alg. Dropper Fila

Fila

Escalonador

Figura 2.8: Ordenao dos Elementos do TCB no Data Path As partes de entrada e sada de um encaminhador so configuradas independentemente. A diferena est num atributo de uma tabela que descreve o incio do data path. Os elementos mais relevantes do PIB DiffServ para este trabalho incluem: Tabela Data Path: cada instncia descreve data paths especficos segundo a combinao das funes das interfaces e direco do fluxo. A deciso de haver ou no haver tratamento DiffServ para uma interface particular pode ser implcita ou explcita. 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 Mdio o Ritmo nico Trs Cores o Dois Ritmos Trs Cores o Janela Deslizante Trs Cores Tabelas de aces Tabelas de funcionalidades (capabilities)

A PRC para o medidor genrico base para configurao de medies especficas. Podem ser usadas tabelas padro ou proprietrias. A PRC TokenBucket tem com os parmetros ritmo (dsTBParamRate), tamanho de rajada (dsTBParamBurstSize) e intervalo (dsTBParamInterval), e indicao 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 instncia de uma PRC em outra tabela. Uma entrada data path aponta para uma entrada classifier. Esta identifica uma lista de elementos de classificao, que so as condies do filtro propriamente ditas. Os elementos de classificao apontam para uma prxima entrada de classificao ou algum outro elemento funcional do data path. Os elementos de classificao tm uma ordem de precedncia para resolver ambiguidades na sobreposio 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 endereos de origem e destino, cdigo DSCP, protocolo de nvel 4, porta deste protocolo, flowid do IPv6 e protocolo IP, TCP, UDP ou qualquer. Os parmetros frwkIpFilterEntry da tabela frwkIpFilterTable so listados na tabela 2.8. Parmetro frwkBaseFilterNegation frwkIpFilterAddrType frwkIpFilterDstAddr frwkIpFilterDstPrefixLength frwkIpFilterSrcAddr frwkIpFilterSrcPrefixLength frwkIpFilterDscp frwkIpFilterFlowId frwkIpFilterProtocol frwkIpFilterDstL4PortMin frwkIpFilterDstL4PortMax frwkIpFilterSrcL4PortMin frwkIpFilterSrcL4PortMax Descrio Actua como um NOT para o filtro IPv4, IPv6 Endereo de destino Mscara do endereo de destino Endereo de origem Mscara do endereo de origem Cdigo DSCP FlowId do IPv6 Protocolo do nvel 4 Porta mnima de nvel 4 no destino Porta mxima de nvel 4 no destino Porta mnima de nvel 4 na origem Porta mxima de nivel 4 na origem

Tabela 2.8: Parmetros da PRC frwkIpFilterTable

37

2. TECNOLOGIAS SELECCIONADAS Aces incluem no action, marcar com um DSCP, ou aco especfica. A tabela dsActionTable utilizada para relacionar uma aco com o elemento antes ou depois dela. Permite que as aces sejam encadeadas, sendo que a ltima aco da cadeia aponta para o prximo elemento do TCB ou para o prximo TCB. Podem haver tabelas de aces especficas para tipos diferentes de aces, o que permite a utilizao de aces proprietrias sem impacto nas aces padro definidas em [RFC3317]. Esta norma no probe considerar o descarte como um elemento de aco, embora seja formalmente manipulado por um outro elemento funcional (Algorithmic Dropper). A aco DSCP Mark utiliza uma gama de valores que so 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 combinaes de funes. As instncias de PRC que descrevem funcionalidades do tipo de interface so apontadas por um OID numa instncia da tabela frwkCapabilitySetTable. A PRC dsIfClassificationCaps utilizada para reportar as funcionalidades de classificao, incluindo os elementos de informao que o dispositivo pode utilizar para classificar o trfego. Outras PRC existem para indicar as outras funcionalidades. Se um PEP receber uma poltica que no pode implementar, deve notificar o PDP com uma mensagem de falha. No anexo C, so apresentadas as tabelas PIB relevantes para este trabalho, conforme codificadas na livraria utilizada (ver o captulo 4 - Detalhes da Soluo Implementada)

2.6.6 Implementao de uma Poltica de Aprovisionamento

Este exemplo considera o cenrio em que o trfego HTTP deve ser agregado e marcado com o cdigo DSCP referente classe AF21 (ver tabela 2.2 na pgina 15). O agregado deve ter 20%-30% da largura de banda total. A figura 2.9 mostra o data path que representa a configurao 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 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=

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

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 Trfego HTTP em AF21 A parte da poltica referente condio traduzida numa lista de acessos apropriada (elemento classificador e filtro IP), enquanto que a parte de aco realizada atravs de classes PRC especficas (DSCPMarkAction, Queue, Scheduler) e seus atributos.

2.7 COPS
2.7.1 Introduo
Uma maneira de aprovisionar polticas atravs do protocolo COPS (Common Open Police Service) [RFC2748] com extenses para aprovisionamento (COPS-PR) [RFC3084]. O protocolo COPS oferece suporte para mltiplos clientes com proviso de polticas para vertentes especficas tais como QdS ou segurana. As extenses COPS-PR adicionam as funcionalidades necessrias no modelo de aprovisionamento PBN (ver a seco 2.2.3). O COPS usa um modelo cliente/servidor sobre TCP, baseado no atendimento pelo servidor s solicitaes de polticas do cliente. As extenses COPS-PR so especificadas de forma independente do tipo de poltica a ser aprovisionada e definem os mecanismos e convenes utilizadas para a comunicao entre servidor de aprovisionamento (PDP Policy Decision Point) e cliente (PEP Policy Enforcement Point). Os termos PDP e PEP so 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. Poltica: combinao de regras e servios em que as regras definem os critrios para acesso e utilizao dos recursos Objecto de Poltica: contm informao de poltica em resposta a uma deciso de atribuio de recursos Elemento de Poltica: unidades de informao do Objecto de Poltica Modelo Soft State: mecanismo automtico de limpeza do estado instalado num PEP ou PDP. accionado em caso de falha de comunicao ou falha do elemento de rede. Estado Instalado: solicitao 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 Caractersticas

As especificaes do COPS e do COPS-PR definem como suas principais caractersticas: No modelo cliente/servidor, o PEP envia mensagens de solicitaes, actualizaes e eliminaes ao PDP e o PDP retorna decises ao PEP. O protocolo foi definido para administrao, configurao e aplicao de polticas, e extensvel, podendo suportar objectos auto-identificados e informaes especficas dos clientes. A conexo TCP iniciada pelo PEP e mantm-se enquanto ambos estiverem funcionais. A porta TCP padro onde o PDP fica escuta de conexes dos PEP a 3288 O COPS utiliza IPSEC ou TLS para autenticao e segurana do canal de comunicao entre o PDP e o PEP. um protocolo stateful (guarda informao sobre os estados da comunicao entre os clientes e o servidor). O estado de solicitao/deciso partilhado entre o cliente e o servidor (at ser explicitamente eliminado) e os estados de vrios eventos podem estar associados (portanto, novas solicitaes podem ter respostas diferentes). O servidor pode enviar informao de configurao para o cliente em modo no solicitado, e remover esta configurao quando no mais se aplicar. So suportados dois modelos para o controlo baseado em polticas: Outsourcing e Provisioning (Aprovisionamento). No modelo Outsourcing, o PEP delega a um PDP externo a responsabilidade de tomar decises de polticas sempre que houver necessidade.

40

COPS O modelo de Aprovisionamento permite que o PDP envie polticas para o PEP de maneira pr-activa, em resposta a eventos externos (por exemplo, a definio de uma nova poltica) ou eventos do prprio PEP. O Aprovisionamento de polticas pode ser feito com a configurao completa ou em partes desta.

2.7.3 Operao
A figura 2.10 mostra o modelo de aprovisionamento do COPS. Encaminhador de Fronteira
COPS REQ()

Servidor de Aprovisionamento Eventos Externos

PEP
COPS DEC()

PDP

Figura 2.10: Modelo de Aprovisionamento COPS As solicitaes de polticas (COPS REQ()) descrevem o PEP e seus parmetros de configurao, e so enviadas sempre que houver uma alterao nestes parmetros (supostamente com pouca frequncia). As decises (COPS DEC()) no so necessariamente respostas a solicitaes, sendo enviadas com mais frequncia devido a eventos externos ou do prprio PDP (actualizaes de polticas e SLA). A figura 2.11 mostra a captura de uma troca tpica de mensagens entre PEP e PDP obtida com a implementao disponvel no pacote COPSClientSDK da Intel [IntelCOPS]. Nesta figura: Os pacotes TCP de incio de sesso, confirmaes e fim de sesso foram filtrados e correspondem aos ndices em falta. O PEP tem o endereo IP 192.168.2.2, e o PDP tem o endereo IP 192.168.2.1. O pacote 4 a solicitao inicial do PEP para o PDP a indicar a sua configurao e suas funcionalidades (capabilities). A resposta vem no pacote 6 com a configurao inicial das polticas. Cliente e servidor trocam frequentemente mensagens Keep-Alive para manter a sesso COPS. Os pacotes 11, 14 e 15 fazem parte da solicitao que o cliente envia para obter um novo conjunto de polticas (se o PDP o considerar um candidato vlido para elas). Embora a ferramenta de captura no conseguisse interpretar o cdigo de operao no pacote 14, o PDP desta implementao particular certamente conseguiu. O pacote 18 (em destaque) contm a resposta do servidor PDP solicitao 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 no, o tamanho (1252 bytes) e os vrios objectos PIB enviados para o cliente. O objecto expandido faz a remoo das polticas anteriores, enquanto que os outros abaixo dele representam a nova poltica a ser aplicada. O PEP responde a uma mensagem de deciso com um Report State (no pacote 20), que indica se houve sucesso na instalao da configurao, ou qual a razo da falha, se for o caso. Os diversos Decision Objects enviados ao PEP identificam as classes de aprovisionamento atravs dos OID. Como os OID so atribudos num PIB, essencial que o mesmo conjunto de mdulos 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 gesto de redes baseada em polticas na comunidade acadmica e empresarial trata especificamente da Qualidade de Servio. Entretanto, trabalhos apresentados h poucos anos podem encontrar-se j ultrapassados. A rpida evoluo das normas e modelos disponveis neste domnio implica em que projectos prottipos muitas vezes no cheguem a entrar em fase de produo. 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 cooperao entre grupos ligados em rede na pesquisa e explorao de tecnologias diversas com QdS, baseadas nas arquitecturas definidas pelo IETF. Tem uma rede nuclear que implementa uma regio DiffServ, a qual interage com uma rede de acesso para oferecer Qualidade de Servio em ambas, utilizando para isto encaminhadores hbridos DiffServ/IntServ. Em Portugal, o INESC representa uma ilha autnoma do projecto, interligada a quatro outras ilhas na Itlia, Romnia e Grcia. QBone [QBone]: um projecto americano integrado nos trabalhos do grupo Internet2. Tem caractersticas semelhantes s do projecto Moicane, mas o foco de pesquisa principalmente na seco estrutural (backbone) da Internet. Seu principal objectivo testar e disseminar mecanismos escalveis de QdS. Tem concluses pouco animadoras sobre a possibilidade de oferecer servios com qualidade fim a fim, devido ao excesso de variveis (hardware, software, modelos de negcio, operaes de rede, etc.) envolvidas. Implementao e Validao da Linguagem Ponder num ambiente CIM/DiffServ [Lymberopoulos]: grupos de trabalho do Imperial College de Londres tm apresentado trabalhos relacionados com PBN h mais de uma dcada [Sloman]. Este paper recente descreve a implementao de uma arquitectura de gesto que suporta a configurao de polticas em encaminhadores DiffServ Linux, fornecendo mecanismos para validao das polticas no que respeita s capacidades dos encaminhadores que as vo aplicar. Projecto Faster da Universidade de Tampere, Finlndia: Faster o nome dado a um conjunto de projectos iniciados no comeo da dcada de 90 com experimentos da utilizao de tecnologia ATM nas redes universitrias. O grupo de trabalho DiffServ [Faster] produziu uma implementao completa da arquitectura (descrita em duas teses de mestrado [Lemponen], [Majalainen]). No contexto de uma arquitectura DiffServ completa, est desfasada das especificaes mais recentes do IETF. Ainda assim, a implementao tem componentes e livrarias de interesse e que foram utilizados neste trabalho (ver seco 4.2).

43

Arquitectura Proposta

3.1 Introduo
Esta seco descreve a arquitectura da implementao proposta. A arquitectura da soluo baseia-se no modelo DiffServ do IETF, que j foi em parte descrito no captulo anterior. O IETF no pressupe ferramentas especficas de implementao para a sua arquitectura, embora haja sugestes (e.g. LDAP para o repositrio, RED para classes AF) e trabalhos relacionados em curso (e.g. linguagens de especificao de polticas). No domnio da Qualidade de Servio, a arquitectura DiffServ oferece maior escalabilidade que a arquitectura IntServ, embora sozinha no 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 polticas de alto nvel e polticas de baixo nvel, pode ser um ponto de estrangulamento neste modelo, se a gerao de polticas ocorrer a um ritmo muito elevado [Corrente]. A arquitectura proposta apoia-se na implementao de uma configurao DiffServ bsica no domnio, incluindo os encaminhadores de fronteira e os encaminhadores internos. Esta configurao implementa as classes EF, AF1 a AF4 e BE, e utiliza alguns parmetros que podem ser alterados e outros que devem permanecer em benefcio da integrao com o restante da arquitectura. Dentre os parmetros que podem ser alterados incluem-se a largura de banda disponvel para cada classe, bem como outros valores relacionados (burst, etc.). A identificao de cada classe (classid) um exemplo de parmetro que no deve ser alterado. Uma vez implementada a configurao bsica, os blocos funcionais da arquitectura trabalham em conjunto para permitir aplicar e eliminar filtros que seleccionam fluxos com base nos campos no cabealho IP e tm data e hora de activao e desactivao, entre outras funcionalidades. Um ponto menos claro na definio inicial da arquitectura foi o tratamento a dar a pacotes com cdigo DSCP no conhecidos dos encaminhadores. O IETF reconheceu um conflito de recomendaes neste aspecto e sugere [RFC3260] que os encaminhadores de fronteira descartem o pacote ou alterem o seu DSCP para coloc-lo na classe padro (DSCP=0x00). Os encaminhadores interiores nunca deveriam receber um pacote com um DSCP desconhecido (a no ser que as prprias aplicaes os criem dentro do domnio DiffServ); caso isto acontea, devem encaminh-lo como se fosse da classe padro. A arquitectura proposta no uma implementao completa do modelo DiffServ, mas baseia-se nos seus conceitos principais para atingir o objectivo de oferecer uma interface amigvel de configurao de fluxos de trfego em classes com o respectivo tratamento diferenciado no domnio.

45

3. ARQUITECTURA PROPOSTA

3.2 Anlise de Requisitos

3.2.1 Requisitos Genricos
A arquitectura deve fornecer: Uma implementao normalizada de classes para obter Qualidade de Servio em redes. Com a aplicao do modelo DiffServ, a satisfao deste requisito permite que o domnio DiffServ possa vir a fazer parte futuramente de uma regio DiffServ, com pouco esforo de compatibilizao das metodologias e parmetros de encaminhamento e diferenciao do trfego. Gesto centralizada das polticas dinmicas. A centralizao da administrao um importante veculo para a escalabilidade de uma soluo no que respeita reutilizao de objectos (polticas) j definidos. Tambm permite obter consistncia no comportamento global do domnio (PDB). Transparncia entre a definio de uma poltica pelo utilizador e sua respectiva configurao nos encaminhadores. Para atender ao modelo de gesto mostrado na figura 2.1, necessrio haver independncia entre as definies de polticas orientadas ao negcio (alto nvel) e as especificidades tecnolgicas de configurao dos equipamentos de rede (baixo nvel). Possibilidade de expanso para suportar clientes (encaminhadores) diversos e redes de grande dimenso. A escalabilidade do modelo escolhido dever ser verificada atravs de testes especficos. Viabilidade e facilidade de implementao em redes de produo sem demasiados esforos de configurao e programao. Este requisito atendido com o recurso a componentes tambm normalizados, como o caso do XML, LDAP e da prpria arquitectura DiffServ. Transparncia possvel a situaes de falta dos componentes. Para atender a este requisito, pode ser necessrio ler e interpretar uma configurao activa implementada nos encaminhadores. A utilizao de um repositrio permite manter informaes sobre o estado das polticas, mesmo em caso de falta dos outros componentes. Para alm disso, nenhum dos componentes deve perder completamente a funcionalidade se os outros falharem.

3.2.2 Estudo de Caso Polticas de Qualidade de Servio no IST

A rede informtica do Instituto Superior Tcnico em Lisboa beneficia-se h algum tempo dos conceitos de diferenciao de fluxos de trfego. Sendo uma rede universitria de dimenso expressiva e com grande nmero de utilizadores, natural que os servios mais relevantes sejam afectados pela escassez da largura de banda, caso a disputem em igualdade de condies com as aplicaes de carter mais ldico que proliferam.

46

ANLISE DE R EQUISITOS Ainda que no existissem tais aplicaes ldicas (jogos em rede, download de msicas), a diferenciao do trfego seria desejvel para beneficiar, por exemplo, o trfego interactivo, em detrimento do trfego ftp ou de correio electrnico. Na altura em que foi elaborada esta anlise aos procedimentos de QdS na rede informtica do IST, o trfego externo de chegada e o trfego de sada eram organizados atravs de scripts de configurao do encaminhador Linux em quatro categorias com diferentes nveis de acesso aos recursos [CIIST]: 1. Interactivo: trfego SSH/Telnet e transmisses ACK do TCP. 2. Servidores: trfego de correio electrnico, acesso a pginas internet, newsgroups em servidores do IST, etc. 3. Bulk: tipicamente o trfego FTP (File Transfer Protocol) associado s transferncias de ficheiros. 4. P2P: trfego peer-to-peer j marcado como tal pelo firewall ou identificado pelas portas utilizadas. A configurao impunha que o trfego externo usasse at um tero da largura de banda nominal interna (34/100 Mbps), enquanto que o trfego interno ficava autorizado a utilizar os outros dois teros (66/100 Mbps). O trfego de sada tinha as partilhas da largura de banda mostradas na tabela 3.1. Servio Todos Interactivo Servidores Bulk P2P Ritmo Padro 34 Mbps 2 Mbps 17 Mbps 14 Mbps 50 Kbps Ritmo Mximo 34 Mbps 5 Mbps 34 Mbps 34 Mbps 1 Mbps

Tabela 3.1: Condicionamento do Trfego de Sada no IST O condicionamento dos diversos tipos de trfego de entrada pode ser visualizado na tabela 3.2. Servio Todos Interactivo Servidores Bulk P2P Ritmo Padro 66 Mbps 2 Mbps 17 Mbps 13 Mbps 100 Kbps Ritmo Mximo 66 Mbps 34 Mbps 34 Mbps 34 Mbps 2 Mbps

Tabela 3.2: Condicionamento do Trfego de Entrada no IST Alm dos filtros de classificao DiffServ, tambm era efectuada uma seleco e marcao prvia dos pacotes pelo mdulo de firewall do encaminhador Linux.

47

3. ARQUITECTURA PROPOSTA A configurao destas aces destina-se a identificar o trfego interno e P2P, este ltimo atravs de mdulos especficos 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 Repositrio LDAP KA, Req, RPT KA, Dec PEP Cria/Apaga filtros Configurao DiffServ Encaminhador de Fronteira Configura PHB Esttico Encaminhador Interior

PDP

KA, Dec PEP

KA, Req, RPT

Figura 3.1: Arquitectura Proposta Relativamente figura anterior: PMT o mdulo Policy Management Tool. Este termo no utilizado nos RFC que descrevem a arquitectura DiffServ, mas sua funcionalidade definida no modelo de informao de polticas [RFC3060] e est geralmente incorporada juntamente com o PDP (Policy Decision Point) num componente que adquire a designao de Bandwidth Broker (BB). Os rectngulos com sombra representam sistemas potencialmente diferentes. A implementao desta soluo apenas permite fazer configuraes DiffServ dinmicas em encaminhadores Linux. Os mdulos PEP, PDP e PMT devem executar como daemons (servios), embora estejam previstas situaes de interactividade para deteco e correco de problemas.

48

ESQUEMA G ERAL A caixa de texto suavizada que representa o PEP no encaminhador interior indica que trata-se de um componente opcional nestas mquinas, j que apenas necessrio manter a configurao esttica de base. Na arquitectura DiffServ, somente os encaminhadores de fronteira so dinamicamente configurados. desejvel que seja relativamente simples configurar o mdulo PEP para instalar ele prprio a configurao de base atravs de um script que deve conhecer (este procedimento tambm til nos encaminhadores de fronteira no caso de reinicializao). As mensagens principais trocadas entre PDP e PEP so o Keep-Alive (KA), Req (para o PEP solicitar uma configurao), RPT (para o PEP reportar o resultado de uma deciso) e Dec (para o PDP enviar uma deciso de configurao). As decises que o PDP envia podem ser no solicitadas, o que o modo natural de trabalho do modelo proposto (modelo de aprovisionamento). A seta pontilhada entre o PDP e o repositrio indica que preferimos optar por uma simplificao da arquitectura onde apenas a PMT interage com o repositrio LDAP. Na arquitectura do IETF para DiffServ, o PDP busca as polticas a implementar directamente do repositrio [RFC2753] e a PMT no est sequer definida como entidade individual.

3.3.2 Operao
Esta seco descreve de forma sucinta os acontecimentos relevantes na implementao de uma poltica. A operao detalhada de cada bloco funcional da arquitectura ser objecto da seco 3.3.3. Tipicamente, o utilizador (administrador) usa um SLA configurado previamente para definir um ou mais TCS (Traffic Conditioning Specification) atravs do mdulo de interface com o utilizador. Por exemplo, deseja estabelecer um servio de linha alugada virtual com 500 Kbps entre duas estaes particulares, para fazer videoconferncia, das 16 s 17 horas de hoje. O mdulo de interface com o utilizador verifica se o SLA ainda tem esta largura de banda disponvel e interage com o mdulo PMT (Policy Management Tool), para saber se possvel fazer esta atribuio de servio ou se h conflitos. Ao concretizar a criao da poltica, confirma para o utilizador. O mdulo PMT recebe em XML os parmetros para configurar a poltica e verifica a sua correco e validade. A seguir, faz a deteco de conflitos com polticas j instaladas, atravs da avaliao da largura de banda disponvel para cada classe e da verificao de condies sobrepostas (duas polticas diferentes para um fluxo com mesma origem e mesmo destino). Guarda as informaes no repositrio e verifica se j altura de instalar a poltica. Tambm com recurso ao XML feita a comunicao entre PMT e PDP. No nosso modelo simplificado da arquitectura DiffServ, a PMT envia os parmetros de configurao para o PDP, e este no interage com o repositrio. A recepo destes parmetros pelo PDP d origem a uma deciso de configurao no solicitada para o(s) PEP.

49

3. ARQUITECTURA PROPOSTA Ao receber a deciso de configurao, o PEP constri o comando para o encaminhador e o aplica. Idealmente, saber interpretar pela resposta se a operao teve sucesso ou no, e reportar para o PDP. Por sua vez, o PDP informa a PMT que configura o estado correspondente da poltica no repositrio.

3.3.3 Opes de Implementao

Nesta seco descrevemos algumas opes de implementao especificamente para os mdulos funcionais DiffServ. A figura 2.5 vem repetida abaixo com a informao adicional:
Medidor

Classificador

Condic. do Trfego

Gesto do Buffer

Scheduler (Escalonador)

Shaper/ Descartador

BA MF

SRTCM TRTCM Dummy

NORMAL AQM - RED CBQ HTB

FIFO Baseado PRIO no Ritmo WRR SCFQ Hierrquico

Figura 3.2: Opes de Classificao e Condicionamento do Trfego As opes para o mdulo Classificador incluem: BA: classificao por Behavior Aggregate atravs do cdigo DSCP. MF: classificao por campos mltiplos do cabealho do pacote. 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 medio. Na prtica as cores so marcadas no campo DS como diferentes precedncias da classe AF. TRTCM: (Two Rate Three Color Marker) semelhante ao anterior, mas considera tambm o ritmo e a rajada de pico do fluxo na avaliao. Este medidor e o anterior podem ser sensveis a cores (o DSCP dos pacotes afecta o processo de marcao) ou insensveis a cores (a marcao feita independentemente do cdigo DSCP anterior do pacote). Dummy: sem condicionamento

O Condicionamento de Trfego pode ser feito por:

50

ESQUEMA G ERAL A Gesto do Buffer tem as opes: NORMAL: utiliza o mecanismo Tail-Drop Queuing, em que os descartes so 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 perodos de rajadas. AQM: nome genrico dos mecanismos que fazem a gesto proactiva do contedo da fila. RED: mecanismo Random Early Detection de descarte probabilstico. Mede o tamanho actual da fila (TF), comparando-o com dois limites. Se o primeiro limite (L1) no for ultrapassado, nunca h descartes. Entre o primeiro e o segundo limites, os pacotes tm uma certa probabilidade de serem descartados (por exemplo, 2%). Acima do segundo limite (L2), todos os pacotes so descartados. Se LF=(Limite Absoluto da Fila), ento LF > L2 > L1. O descarte de pacotes antes que a fila esteja cheia sinaliza precocemente para uma origem TCP dos pacotes que h uma congesto incipiente, da o termo Early. A caracterstica aleatria do descarte torna o mecanismo mais justo. CBQ: (Class-Based Queuing) uma disciplina de filas hierrquica, que pode conter outros mdulos de classificao, marcao e gesto de buffer. Sua grande vantagem poder emprestar a largura de banda no utilizada, dividindo-a pelas entidades da hierarquia que a necessitem at ao mximo configurado em cada uma. Entretanto, CBQ considerada muito difcil de configurar, tendo problemas bem identificados ao fazer estimativas da utilizao do canal [Hubert]. HTB: (Hierarquical Token Bucket) actua de forma semelhante CBQ mas usa o mecanismo Token Bucket Filter para o shaping. Alm disso, distribui a largura de banda disponvel de forma ponderada pelo ritmo (rate) definido em cada subclasse. 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 esttica. Subdivide o trfego em vrias subclasses FIFO com base nos filtros configurados. As subclasses so atendidas de forma determinstica com base na sua prioridade relativa. WRR: (Weighted Round Robin) atende uma fila por vez, e selecciona em cada uma delas um nmero de pacotes proporcional prioridade relativa da fila. SCFQ: (Self-Clocked Fair Queuing) uma simplificao menos justa da disciplina WFQ (Weighted Fair Queuing). As disciplinas FQ (Fair Queuing) mantm uma fila separada para cada fluxo de trfego, evitando assim que o aumento de pacotes por uma das fontes de trfego resulte numa maior ocupao da largura de banda pelo seu fluxo. As filas so atendidas uma por vez [Nagle]. Hierrquico: uma hierarquia de filas e escalonadores WFQ (Weighted Fair Queuing). 51

As opes para o Escalonador so:

3. ARQUITECTURA PROPOSTA E, finalmente, o mdulo de shaping e descarte implementado para atender a um determinado ritmo, podendo atrasar ou descartar pacotes para honrar o ritmo acordado. A anlise das opes apresentadas aqui complementada pela informao sobre disciplinas de filas e termos relacionados na seco 2.3.4.

3.4 Blocos Funcionais

3.4.1 Introduo
Nesta seco so descritas as funcionalidades dos blocos individuais no contexto da arquitectura proposta. O captulo 4 discute em detalhe os aspectos prticos na implementao da soluo.

3.4.2 Interface do Utilizador

A interface com o utilizador utilizada para a definio das diferentes polticas a serem aplicadas na rede, verificao do seu estado e definio das larguras de banda visveis nas diversas classes. Para a especificao de uma poltica particular, a interface oferece a abstraco semelhante aos Servios Olmpicos sugeridos pelo IETF (ver seco 2.2.3), porm com um nmero mais elevado de classes [Calhariz]. Estas classes superolmpicas so mapeadas para as classes DiffServ de acordo com a tabela 3.3, que tambm mostra a aco levada a efeito em cada classe para pacotes fora do perfil respectivo.

Classe de Servio Diamante Platina Ouro Prata Bronze Tradicional

Classe DiffServ EF AF1 AF2 AF3 AF4 BE

Pacotes fora de perfil Descarte 3 Remarcao (DP1 e DP2), Descarte 4 (DP3) Nada

Tabela 3.3: Mapeamento das Classes de Servio A especificao de uma poltica inicia com a definio de um SLA associado a uma das classes, com a indicao da largura de banda mxima e faixa de
3

Pacotes fora do perfil na classe EF devem ser descartados (do fim da fila) para que seja respeitada a condio de baixo retardo.
4

Caso os pacotes fora de perfil nas classes AF fossem remarcados para outra classe, poderiam ser entregues fora de sequncia, o que incompatvel com a definio do servio 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 permisses para definir os TCS deste SLA particular. Um SLA deve ter um ou mais TCS. De facto, so os TCS que definem e concretizam os filtros que sero configurados nos encaminhadores de fronteira. Na definio de um TCS fica implcita a classe que vai utilizar, atravs do SLA a que pertence. Devem ser indicados os parmetros para filtrar o trfego, prioridade do filtro (dentro da faixa permitida e sem duplicados), ritmo mximo desejado (at ao mximo disponvel no SLA), e alcance temporal. A filtragem por cabealho IP pode incluir: Verso do protocolo IP: IPv4 ou IPv6. Endereo de origem do trfego e mscara para identificar mltiplos sistemas de origem. Exemplo: 192.168.2.0/24 refere-se a todos os sistemas da sub-rede 192.168.2.0. Endereo de destino do trfego e mscara para identificar mltiplos sistemas de destino. Protocolo: IP, TCP, UDP, todos. Gama de valores para as portas de origem e portas de destino. Cdigo DSCP: permite seleccionar pacotes pelo cdigo DSCP marcado anteriormente. Fluxo IPv6: utilizado para rotular sequncias de pacotes destinados a tratamentos especiais.

Nesta arquitectura, definimos que no pode haver filtros simultaneamete activos com a mesma prioridade. A razo deste impedimento a forma como o Linux permite fazer remoo de filtros DiffServ deve ser indicada uma prioridade, e todos os filtros com aquela prioridade so removidos. O ritmo mximo padro a largura de banda ainda disponvel no SLA deste TCS. O alcance temporal do filtro definido atravs de uma data/hora de incio e uma data/hora de fim. A verificao/alterao do estado de um filtro feita atravs de uma lista de todos os filtros configurados por SLA e ainda no expirados. Os estados possveis so: Inactivo: data/hora de incio ainda no foram alcanadas ou foi desactivado. Em instalao: o PDP j foi notificado para instalar o filtro. Activo: indica o nmero de encaminhadores (PEP) que reportaram a instalao bem sucedida do filtro.

Outra importante funo administrativa da interface com o utilizador permitir que o administrador da rede configure a diviso da largura de banda da rede entre as diversas classes de servio. A arquitectura permite a configurao de mais ou menos largura de banda que a nominal, numa perspectiva de ajuste fino 53

3. ARQUITECTURA PROPOSTA na oferta de recursos. Na seco 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 Polticas

Este mdulo a PMT (Policy Management Tool). Interage com : O repositrio, para criar, verificar e eliminar polticas, SLA, TCS e para verificar se j deve instalar ou remover polticas na rede. A interface com o utilizador, para verificar o contexto de autorizao sobre os objectos do repositrio (administrador: tudo; cliente: um SLA e os seus TCS) e trocar as necessrias informaes atravs de XML. O PDP, para solicitar a instalao, desinstalao ou relatrio do estado das polticas.

A PMT necessita de suportar a noo de polticas de alto nvel, que expressam os objectivos da administrao da rede, em oposio a polticas de baixo nvel, que so interpretadas por cada um dos elementos de rede afectados. A figura 3.3 mostra os elementos de interface da PMT. Polticas de Alto Nvel XML Para Interface com o Utilizador Para o Repositrio Para PDP Polticas de Baixo Nvel XML Comandos e Respostas LDAP

PMT

Figura 3.3: A Policy Management Tool Uma importante tarefa da PMT fazer a verificao de potenciais conflitos antes de implementar novas polticas. Os conflitos acontecem quando diferentes aces so configuradas para o mesmo fluxo de trfego. Isto pode ser realizado com a comparao das origens e destinos das novas polticas com a informao armazenada no repositrio, considerando-se ainda as respectivas datas e horas de activao e desactivao. Outra possvel fonte de inconsistncias a diviso da largura de banda. Esta verificada por mera formalidade pela PMT, porque os processos de atribuio de SLA e de TCS impedem uma sobre-utilizao da largura de banda (embora seja possvel que o administrador configure cada classe com mais largura de banda que a existente na rede ver seco 5.4).

54

B LOCOS F UNCIONAIS O envio das polticas para o PDP feito em XML, mas tanto quanto possvel prximo da estrutura de PIB (Policy Information Base) utilizada na comunicao entre PDP e PEP. Esta arquitectura simplificada prev que apenas a PMT acesse o repositrio, portanto dever indicar todos os parmetros relevantes em comunicao directa para o PDP.

3.4.4 Repositrio
O repositrio oferece o suporte necessrio s aces dos diversos mdulos, armazenando definies dos SLA, TCS e polticas. A implementao deve prever a hiptese de um cliente gerir o seu prprio SLA com a configurao dos TCS. Isto pode ser realizado com a proviso de um mecanismo de autenticao entre a PMT e o mdulo de interface com o utilizador. Somente a PMT interage com o repositrio nesta arquitectura. O directrio LDAP um repositrio central, que possibilita a administrao centralizada das polticas a partir de um nico ponto. a escolha natural para armazenamento de polticas, pois trata-se de um standard aberto definido pelo prprio IETF que beneficia da existncia de um schema para o modelos de informao de polticas (mas no para o modelo de informao de QdS) [RFC3703]. Uma das caractersticas desta arquitectura proposta, de basear-se numa configurao DiffServ esttica dos encaminhadores para prover apenas filtros adicionais relativos a fluxos de trfego especficos. Isto permite uma simplificao do schema a definir no repositrio LDAP, no impedindo no entanto sua futura expanso. A seco 4.2.3 indica os elementos realmente utilizados no esquema juntamente com o schema desenvolvido de propsito para este trabalho. Um importante conceito relacionado com a abstraco das polticas e a sua definio como um par de grupos (se <condies> ento <aces>) a possibilidade de reutilizao sem que tenha de ser novamente definida por completo. A proviso para reutilizao de polticas baseia-se na estrutura atmica que seus componentes tm no repositrio LDAP, e implica em que as condies e as aces sejam tambm elementos reutilizveis. Poltica Condies Condies Aces 1: src=192.168.2.65/32 1,2,23 1,15,30 2: dst=192.168.3.22/32 ... ... ... ... ... ... ... ... ... ... ... 23: porta=7000 ... ... ... Aces 1: DSCP=EF 2: DSCP=AF1 ... 15: LB=500Kbps 16: LB=2Mbps ... 30: polAction=DROP

Id 1 ... ... ... ... ...

Tabela 3.4: Configurao de uma Poltica A tabela 3.4 mostra um exemplo de configurao de poltica associando-a com elementos individuais nas tabelas de condies e aces.

55

3. ARQUITECTURA PROPOSTA No repositrio ficam armazenadas as definies de polticas, condies, aces, definies dos SLA e TCS e tambm inclui informaes 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 tambm quando h solicitaes da PMT para implementao ou remoo de polticas. O modelo do IETF prev que este componente faa a descoberta dos PEP que tem a configurar para cada poltica individual. Na arquitectura proposta neste documento, o PDP conhece os roles em cada PEP e utiliza-os para decidir se os configura ou no. Tipicamente, envia as polticas para todos os encaminhadores de fronteira, informando a PMT sobre suas identidades. O PDP no tem de conhecer a arquitectura especfica dos PEP com que interage, desde que o PEP suporte a PIB (Policy Information Base) requerida (ver a seco 2.6). Neste caso, as PIB utilizadas so a PIB Framework e a PIB DiffServ. O outro requisito importante o suporte a COPS e COPS-PR (ver a seco 2.7). A figura 3.4 mostra as interfaces funcionais do PDP. XML Para PMT Converte as solicitaes da PMT em PIB Converte PIB em informaes para a PMT

PDP

Para PEP

COPS/COPS-PR Figura 3.4: O Policy Decision Point A figura 3.5 mostra em esquema como seria parte da construo 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 marcao propriamente dita (DSCP=AF11) feita na interface interna. Esta poltica inicia com o classificador Congresso e indica elementos para filtros e para aces 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: Construo de uma Poltica com PIB A noo de Data Path bem visvel na figura 3.5, atravs dos diversos atributos Next dos elementos. O medidor utilizado do tipo Token Bucket Two Rate Three Color Marker. A implementao de um PIB deve ser feita na ordem contrria, 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 mdulo que recebe decises do PDP em forma de PIB, faz o mapeamento para comandos de configurao especficos do sistema onde est instalado, aplica e executa concretamente as polticas. Tambm responsvel por monitorizar e reportar estatsticas e outras informaes de operao. 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 informao sobre seu hardware, software e configurao. Em resposta, o PDP deve enviar todas as polticas de aprovisionamento relevantes para este sistema [RFC3084]. Outras polticas podem ser recebidas do PDP sem que o processo seja iniciado pelo PEP. Todas as polticas recebidas so mapeadas, atravs de regras de transformao, para os mecanismos locais de QdS, e instaladas. O PEP deve reportar o sucesso ou falha da instalao das polticas atravs de mensagens RPT. As duas operaes principais suportadas pelo PEP so: Instalao: instala ou actualiza uma poltica Remoo: elimina uma poltica instalada.

A figura 3.6 mostra um esquema das interfaces funcionais do PEP. COPS/COPS-PR Comandos especficos de Para PDP configurao DiffServ PEP Para SO Reporta estado da instalao em PIB

Converte PIB nos comandos DiffServ locais

Figura 3.6: O Policy Enforcement Point

3.4.7 Encaminhadores
O modelo dos Servios Diferenciados no impe regras rgidas na configurao dos encaminhadores. Cada implementao particular pode definir os pontos e tipos de classificao e policiamento e os componentes utilizados na implementao (ver seco 3.3.3 - Opes de Implementao). Em relao ao 58

B LOCOS F UNCIONAIS tratamento a dar ao trfego fora de perfil, as opes so limitadas pelas caractersticas das classes, como explicado pelas notas da tabela 3.3. Este trabalho prope uma soluo para encaminhadores Linux de fronteira e interiores ao domnio DiffServ. Outros tipos de encaminhadores podem ser utilizados se o respectivo PEP estiver implementado com os PIB utilizados e se a configurao bsica esttica (que define as classes DiffServ) tiver sido aplicada. Idealmente, o cdigo utilizado para o PEP admitir diferentes mdulos de mapeamento para comandos de configurao DiffServ especficos do sistema. Na arquitectura proposta, os encaminhadores Linux de fronteira e interiores tm suas interfaces de rede configuradas com o conjunto bsico de classes DiffServ na sua inicializao. Isto pode ser feito atravs de um script RC [SForge] que tambm lana o PEP, ou dentro do prprio PEP se a opo for por utilizar um ficheiro de configurao para este ltimo. O ficheiro de configurao define a localizao do script de configurao e o role das interfaces de rede. A combinao da localizao da interface (externa ou interna ao domnio) com a direco do trfego (sada ou entrada) torna necessrio que a configurao esttica atenda de forma eficaz a quatro situaes potencialmente diferentes nos encaminhadores de fronteira. A figura 3.7 mostra os papis das interfaces em encaminhadores. interface externa direco=sada interface externa direco=entrada sada entrada interface interna direco=sada interface interna direco=entrada Figura 3.7: Os papis das interfaces Para esclarecer a necessidade de diferenciar as configuraes como mostrado, consideramos uma situao de trfego de voz sobre IP (VoIP). Este tipo de trfego utiliza pacotes pequenos (60 a 200 bytes) com grande sobrecarga do cabealho (40 bytes). O protocolo o RTP (Real Time Protocol) sobre UDP. A qualidade da transmisso deste tipo de trfego requer baixo retardo, e baixo jitter (variao no atraso dos pacotes). Estes parmetros so afectados pela distribuio aleatria dos tamanhos de pacotes de outros fluxos que estejam a ser encaminhados pelos mesmos encaminhadores que o trfego VoIP. Suponhamos que o trfego VoIP est a disputar a largura de banda com transferncias de ficheiros. Se V representar 60 bytes de um pacotes VoIP e F N de Fronteira Domnio DiffServ N Interior

59

3. ARQUITECTURA PROPOSTA representar o mesmo nmero de bytes em pacotes FTP, poderamos ter uma fila no encaminhador como mostra a figura 3.8.
V FFFFFFFFFFFFFFFFFFFF VVV FFFFFFFFFFFFFFF VV

Figura 3.8: Trfego VoIP vs. Trfego FTP As configuraes DiffServ de controlo do trfego nos encaminhadores podem ajudar a minimizar este problema. necessrio estabelecer uma regra na interface externa, direco entrada, para que os fluxos VoIP que entram no domnio sejam sempre encaminhados em primeiro lugar, com um valor de rajada suficiente para abranger a largura de banda das conversaes individuais, e um valor do ritmo policiado igual ao valor da rajada multiplicado pelo nmero de conexes simultneas que desejamos atender. Em linguagem de polticas de alto nvel: Fluxos VoIP de 64 Kbps para o domnio tm prioridade 1 at 512 Kbps Esta regra pode ser interpretada pelo sistema de forma a implementar um filtro na interface externa que seleccione o trfego VoIP na direco entrada, dandolhe prioridade 1 no encaminhamento para rajadas at 64 Kbps e ritmo de 512 Kbps, equivalente a oito conexes de 64 Kbps. Pacotes fora do perfil seriam remarcados (embora essa no seja geralmente a melhor opo para trfego multimdia). Aps o policiamento, os pacotes so encaminhados para a rede atravs de uma interface diferente, ou para os nveis superiores (e.g. TCP, UDP) se o destino for a mquina local. O encaminhamento, aps seleccionar a interface de sada, o prximo destino do pacote, e o encapsular, envia os dados para uma fila da respectiva interface. Esta fila (output queue) tambm faz parte do mecanismo de controlo do trfego no Linux. Os pacotes podem aqui sofrer classificao, 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 situao ptima ocorre quando o escalonador usa uma fila do tipo PRIO (ver seco 3.3.3).
TCP, UDP, etc.

Interfaces de Entrada

Polticas de Entrada

DeMux de Entrada

Encaminhamento

Filas de Sada

Interfaces de Sada

Controlo do Trfego Figura 3.9: Processamento de Dados da Rede no Linux A figura 3.9 mostra os mdulos envolvidos no processamento de um pacote de rede num sistema Linux [Almesberger]. 60

B LOCOS F UNCIONAIS Para adaptarem-se s polticas DiffServ configuradas no domnio, as aces 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 combinaes (interface externa direco sada) ou (interface interna direco entrada). Na interface interna, direco entrada, conveniente, mas no obrigatrio, haver alguma funcionalidade tpica dos PHB dos encaminhadores interiores para evitar que o trfego classificado como mais prioritrio seja sobrepujado pelos fluxos de menor prioridade antes mesmo de entrar no domnio [Lemponen]. Na figura, o mdulo onde o shaping pode ser efectuado chama-se Filas de Sada. O policiamento configurado sob demanda (novos SLA/TCS) e deve ser feito to cedo quanto possvel para os pacotes que entram no domnio, porque no faz sentido manter em trfego 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, direco entrada, onde estabelecido o primeiro contacto dos pacotes com o domnio. Na figura, este o mdulo de policiamento de entrada (ingress). A tabela 3.5 mostra um resumo das concluses sobre policiamento e shaping. Caso haja acordo com uma regio DiffServ contgua, pode ser necessrio policiar e fazer o shaping no trfego de sada, nos encaminhadores de fronteira. Encaminhador de Fronteira Interface Interface Externa Interna Trfego de Sada Trfego de Entrada Policiamento Marcao (dinmico) (esttico) Encaminhador Interior Todas as Interfaces PHB Configurados (estticos)

Tabela 3.5: Aplicao de Polticas s Interfaces Assim, na arquitectura proposta h trs configuraes a fazer: a. Configurar a interface externa dos encaminhadores de fronteira para permitir adicionar dinamicamente classificadores com ou sem policiamento. Estes classificadores vo 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 domnio. Pode haver algum condicionamento do trfego pelo prprio policiamento (ver o captulo 5 Testes). c. Configurar todas as interfaces dos encaminhadores internos com os PHB adequados configurao do ponto b. As figuras a seguir so baseadas em [Calhariz], [Almesberger].

61

3. ARQUITECTURA PROPOSTA
TCP, UDP, etc.

Interfaces de Entrada

DeMux de Entrada

Encaminhamento

Filas de Sada

Interfaces de Sada

Classificador 1

Filtrou

Classificador 2

Policiador 1 Fora de perfil

Dentro do perfil

Marcador EF

Filtrou Classificador n

Policiador 2 Fora de perfil Policiador 3 Fora de perfil Policiador 4 Fora de perfil

Dentro do perfil Dentro do perfil Dentro do perfil

Marcador AFx1 Marcador AFx2 Marcador AFx3

Marcador BE

Figura 3.10: Configurao da Interface Externa Policiamento de Entrada A figura 3.10 mostra como fica a configurao da(s) interface(s) externa(s) de um encaminhador de fronteira. O rectngulo maior a tracejado representa o mdulo de policiamento de entrada. As caixas de texto pontilhadas (classificadores e policiadores) indicam condies implementadas dinmicamente atravs dos SLA/TCS; as outras representam a configurao esttica de base. O policiamento dinmico mas a atribuio de SLA aos clientes j contempla e respeita os limites de cada classe (ver seco 3.4.2 Interface do Utilizador). A figura 3.11 representa a configurao da(s) interface(s) interna(s) de um encaminhador de fronteira. O rectngulo em pontilhado o mdulo das filas de sada. As filas AFx tm, cada uma, trs nveis diferentes de prioridade de descarte. Estes nveis no esto diferenciados nesta figura, embora o estejam na figura 3.10 (ver seco 2.3.3 Arquitectura DiffServ). Finalmente, a configurao de qualquer interface dos encaminhadores interiores igualmente representada pela figura 3.11. As ligeiras diferenas na implementao sero detalhadas no captulo 4. Funcionalmente, no h escolha nos encaminhadores interiores relativamente ao atraso selectivo (shaping), como poderia haver nos encaminhadores de fronteira. Os PHB so sempre aplicados aos pacotes em trnsito no interior do domnio para respeitar a largura de banda mxima atribuda a cada classe.

62

B LOCOS F UNCIONAIS
TCP, UDP, etc.

Interfaces de Entrada

Polticas de Entrada

DeMux de Entrada

Encaminhamento

Interfaces de Sada

Fila EF Classificador EF Fila AF1 Classificador AF1 Fila AF2 Classificador AF2 Fila AF3 Classificador AF3 Fila AF4 Classificador AF4 Fila BE Escalonador por Prioridade

Figura 3.11: Configurao da Interface Interna Filas de Sada A correcta configurao dos encaminhadores de fronteira evita que haja pacotes com DSCP invlido no interior do domnio DiffServ, excepto por pr-marcao numa fonte interna (por exemplo, o comando ping com a opo Q permite marcar o campo tos). Qualquer pacote com DSCP invlido recebe nos encaminhadores internos o tratamento padro (classe BE), mas sem remarcao, como acontece nos encaminhadores de fronteira [RFC3260]. O que fazer com pacotes AF fora de perfil? Foi verificado empiricamente que o seu descarte sumrio, havendo largura de banda disponvel na rede, representa um desperdcio de recursos. Por outro lado, a sua remarcao para outra classe pode criar um problema de reordenao dos pacotes de um fluxo (alguns chegam via AF1, outros via AF2, possivelmente fora de ordem), incompatvel com a filosofia de servio das classes AF. O modelo proposto faz a implementao de todos os policiadores necessrios (1, 2 ou 3) para que pacotes AF fora de perfil sejam remarcados para a prxima prioridade de descarte dentro da mesma classe, ou descartados quando a prioridade de descarte a ltima.

63

Detalhes da Soluo Implementada

4.1 Introduo
A soluo proposta destina-se a implementar um nvel mnimo mas utilizvel de funcionalidade na configurao de classificadores sobre uma configurao bsica esttica. As opes disponveis para os classificadores baseiam-se na utilizao de filtros por campos do cabealho IP, conforme entradas da tabela frwkIpFilterTable do Framework PIB [RFC3318]. A implementao pretende ser expansvel para poder incorporar no futuro toda a gama de possibilidades descritas pelo IETF ou requeridas localmente por um domnio especfico. Para isto, beneficia da utilizao de standards da indstria. O software desta implementao pode ser classificado da seguinte forma: a. Tecnologias e livrarias padro da indstria: OpenLDAP, Java, livrarias XML e LDAP para Java [OpenLDAP, Java, W3CXML, SAX2, JLDAP]. b. Tecnologias desenvolvidas em projectos acadmicos: livrarias PIB e COPS [Lemponen00]. c. Exemplos de utilizao das livrarias PIB e COPS para implementao de PDP e PEP [Lemponen00]. Estes exemplos, na linguagem C, foram utilizados como base para o desenvolvimento do prottipo funcional desta parte da arquitectura. d. Cdigo original do autor. Inclui o mdulo de interface com utilizadores e administradores, o mdulo PMT de interface com o repositrio e PDP, mtodos 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 Introduo
Nesta seco so descritos os aspectos prticos na implementao da soluo. Est estruturada de forma semelhante seco 3.4 para facilitar a referncia com a arquitectura proposta mostrada na figura 3.1.

4.2.2 Interface do Utilizador

No mdulo de interaco com o utilizador/administrador, houve a preocupao de apresentar um conjunto de interfaces simples e objectivas. A representao das polticas como SLA e TCS no pode evitar a abordagem por vezes demasiado tcnica para os parmetros de configurao dos classificadores e policiadores, embora estejam implementados mecanismos de ajuda para esclarecer as diversas opes. 65

4. DETALHES DA SOLUO IMPLEMENTADA Este mdulo foi desenvolvido em linguagem Java com utilizao de um IDE (Integrated Development Environment) para facilitar a construo das interfaces grficas. Seu funcionamento esquematizado na figura 4.1, onde cada ecr da aplicao est representado por uma caixa de texto devidamente identificada com o nome da classe Java correspondente. Tambm esto identificados os contextos do Utilizador e do Administrador. Utilizador Ver SLA configurados
IU01

Identificao ou Terminar
ID01

Administrador Opes de Administrao

AD01

Ver os TCS
TCS01

Ver os SLA
AD02

Ajustar Larguras de Banda das Classes

AD03

Configurar os TCS
TCS02

Configurar os SLA
AD04

Figura 4.1: Funcionamento da Interface com o Utilizador As duplas setas significam que as classes filhas tm sempre nos ecrs um boto associado a um mtodo Abandonar(), que devolve o controlo ao contexto que as criou. No ecr ID01, h um boto para encerrar a aplicao. A classe TCS01 de visualizao dos TCS, partilhada pelo fluxo do utilizador e pelo fluxo do administrador, mas no h possibilidade de a utilizar para navegar entre os ecrs IU01 e AD02, j que, quando encerrada, retorna o controlo para o contexto em que foi invocada. As classes no mostradas na figura 4.1, mas que tm um papel importante na aplicao, incluem: sla: definio e mtodos dos objectos SLA. tcs: definio e mtodos dos objectos TCS. classesDS: atributos e mtodos das classes DiffServ.

As mensagens trocadas entre a Interface com o Utilizador e o mdulo PMT utilizam uma notificao de identificao onde o sufixo Sol indica solicitaes para a PMT, e o prefixo Rsp indica as respostas da PMT aps consultar ou actualizar o repositrio: IdentSol: Solicita validao da identificao do utilizador ou administrador.

66

B LOCOS F UNCIONAIS IdentRsp: Informa se as credenciais so vlidas, e se um utilizador ou administrador. SLASol: Solicita a rvore de SLA armazenada no repositrio, 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 actualizao de um objecto no repositrio e correspondente configurao na rede se for um TCS. ActualRsp: Indica se a aco de actualizao solicitada teve sucesso.

As mensagens so construdas com recurso a XML. Por exemplo, uma mensagem IdentSol tem o formato:
<IdentSol><Utilizador>Admin</Utilizador><Senha>senha</Senha></IdentSol>

Mensagens no reconhecidas so simplesmente descartadas. Os DTD utilizados para validar o XML esto listados no anexo A. A figura 4.2 mostra como exemplo o ecr de configurao de um TCS na aplicao.

Figura 4.2: Ecr de Configurao dos TCS Cada TCS est associado a um SLA, cuja identificao apresentada no ecr da figura. Tambm visvel a classe de servio associada a este SLA, que condiciona a colocao de pacotes dentro do perfil de trfego (ritmo desejado) 67

4. DETALHES DA SOLUO IMPLEMENTADA do TCS. O ritmo agregado dos TCS de uma classe no pode ultrapassar o valor do ritmo do SLA respectivo. desejvel poder criar TCS que no estejam activados, e aciv-los ou desactiv-los conforme for conveniente, se necessrio com alterao das datas e horas de incio e fim da validade. Os endereos de origem e destino no podero ser aleatrios. Eles devem ter o formato de endereo IP, e no podem diferir dos endereos configurados no SLA excepto para maior especificidade dentro da sub-rede. Por exemplo, se o SLA estiver configurado com o endereo de origem igual a 192.168.3.0/24, possvel haver um TCS cujo endereo de origem seja 192.168.3.32/30 ou 192.168.3.132/32, mas no 192.168.4.0/24. Isto evita que um utilizador possa condicionar o trfego de redes alheias, j que o administrador a configurar os seus SLA. A prioridade de cada TCS activo deve ser nica (porque na remoo de filtros estes so identificados pela respectiva prioridade) e condicionada pela faixa de prioridades atribuda ao SLA. Isto tem como consequncia a limitao do nmero de TCS activos a qualquer momento, no sistema e por cliente/SLA. Devido a estas consideraes, a definio de prioridade feita pelo sistema no momento da activao de um filtro/TCS, e no pelo utilizador. Os filtros da classe Diamante (EF) tm sempre valores mais baixos para o atributo prioridade.

4.2.3 Gestor de Conflitos e Tradutor de Polticas

Este mdulo equivalente Policy Management Tool na arquitectura do IETF [RFC3460]. Convencionamos fazer referncia a ele com o termo PMT.
IdentSol SLASol ClasseDSSol RemoveSol ActualSol Search Modify Add Delete

Interface com o Utilizador

32881 IdentRsp SLARsp ClasseDSRsp FiltrosRsp RemoveRsp ActualRsp

PMT

389

Repositrio

criaFiltro 32880 removeFiltro Rpt Rpt

PDP

Figura 4.3: Relao da PMT com outros Mdulos

68

B LOCOS F UNCIONAIS Como mostrado na figura 4.3, o mdulo PMT tem trs interfaces: Interface XML com o mdulo de interface com o utilizador. Ouve na porta 32881. A cada solicitao vlida corresponde uma resposta da PMT. Interface com o repositrio. Envia comandos LDAP para a porta padro LDAP (389). Os comandos e as respostas esto definidos em livrarias jLDAP (ver seco 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 vlido da PMT.

A tabela 4.1 mostra os comandos que podem ser trocados entre a PMT e a Interface do Utilizador. No esto mostradas algumas das respostas. Funo 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> solicitao de (PMT IU) </utilizador></IdentRsp> identificao <SlaSol> Informao de <SLASol><sla> <slaUser>Admin</slaUser> </sla></SLASol> (IU PMT) SLA e TCS <ClasseDSSol> Informao das <ClasseDSSol><classeds> <classe>Prata DP2</classe> </classeds></ClasseDSSol> (IU PMT) classes Solicita <FiltrosSol> <FiltrosSol></FiltrosSol> informao (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
<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> <SlaRsp>fim</SlaRsp>

Comando

<ActualSol>

(IU PMT)

Cria objectos

Fim de Respostas (PMT IU)

Indica que a PMT j enviou as respostas

Tabela 4.1: Comandos Trocados entre PMT e Interface do Utilizador

69

4. DETALHES DA SOLUO IMPLEMENTADA A PMT traduz as condies e aces dos TCS para facilitar o trabalho do PDP. O dilogo trocado entre PMT e PDP j orientado criao 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 trfego. Em situaes de produo, recomendado existir um script RC (Run Control) para activar automaticamente este mdulo. Tal como o mdulo de interface com o utilizador, este mdulo foi desenvolvido em Java, mas no tem interface grfica porque em ambiente de produo dever executar como um servio (daemon). Trabalha sempre em contexto administrativo relativamente ao repositrio. Comando Funo 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>

Cria <criaPolitica> polticas no PEP

<rmPolitica>

<Rpt>

Elimina politicas no PEP Solicita relatrio de filtros no PEP

<Rpt><pep> <nome_pep>Linax</nome_pep> </pep></Rpt>

Tabela 4.2: Comandos da PMT para o PDP Ao inicializar, este mdulo l um ficheiro de configurao com os endereos e credenciais para o repositrio e para o PDP. Interage com o repositrio para

70

B LOCOS F UNCIONAIS criar os Timers utilizados para implementar ou eliminar polticas nos encaminhadores atravs do PDP, nas datas e horas respectivas. Cria um novo Timer sempre que definido (e aceite) um TCS. A verificao de conflitos necessita de ser feita sempre que a interface com o utilizador prope a implementao de uma poltica. Basicamente, verificado se o mesmo par de endereos origem-destino tem outra poltica configurada para horrios sobrepostos. O conflito sinalizado para a interface com o utilizador e a requisio ignorada.

4.2.4 Repositrio
O repositrio foi criado com recurso ao software OpenLDAP [OpenLDAP] instalado em um sistema Linux Red Hat verso 9. O OpenLDAP tem uma srie de dependncias para software de terceiros no instalado normalmente de forma padronizada no Red Hat. As dependncias por sua vez podem exigir a instalao de outro software no padro. Todo o software necessrio est disponvel como pacotes linux e tem licenas Open Source. A seguir listamos as dependncias, na ordem em que devem ser instaladas: Livrarias TLS: fornecem servios Transport Layer Security para que o software OpenLDAP seja completamente de acordo com a especificao LDAPv3 do IETF [RFC2251]. As livrarias so instaladas atravs do componente OpenSSL disponvel em http://www.openssl.org. Servios de Autenticao Kerberos: o OpenLDAP suporta o mecanismo SASL/GSSAPI e necessita da instalao das livrarias Kerberos. Os pacotes esto disponveis em http://www.pdc.kth.se/heimdal/ ou em http://web.mit.edu/kerberos/www. Livrarias SASL (Simple Authentication and Security Layer): requerida a instalao das livrarias Cyrus SASL, que disponibilizam servios de autenticao simples e security layer. Estas livrarias utilizam o software OpenSSL e Kerberos se j estiver instalado. Esto disponveis em http://asg.web.cmu.edu/sasl/sasl-library.html. Software de Base de Dados: a verso actual do OpenLDAP requer o Sleepcat Software Berkeley DB, verso 4.2. Est disponvel na pgina http://www.sleepycat.com/download/.

Todos estes pacotes tm de ser descomprimidos para um local temporrio. essencial a leitura das instrues de instalao, geralmente num ficheiro Install ou numa subdirectoria doc, para todos estes componentes e tambm para o OpenLDAP. O servio LDAP propriamente dito fica disponvel com o arranque de uma aplicao que executa como daemon no Linux. Esta aplicao o slapd e a sua localizao padro na directoria /usr/local/libexec. Em servidores de produo, deve ser considerada a criao de um script RC (Run Control) para automatizar o arranque dos servios LAPD. O slapd tem um ficheiro de configurao normalmente denominado /usr/local/etc/openldap/slapd.conf, onde so indicados os 71

4. DETALHES DA SOLUO IMPLEMENTADA schemas utilizados, bem como informaes sobre referrals (ver seco 2.5), segurana, polticas de acesso, replicao (se for desejado) e de segurana. Um ficheiro de schema assim referenciado no slapd.conf: include /usr/local/etc/openldap/schema/core.schema Caso no haja definio de polticas de segurana, qualquer utilizador pode ler todas as informaes, mas a sua alterao restrita ao elemento identificado como rootdn nas definies da base de dados: database: bdb suffix: dc=Acordos de Servio, dc=CIIST, dc=IST, dc=pt rootdn: cn=Admin, dc=Acordos de Servio, dc=CIIST, dc=IST, dc=pt rootpw: secret O ficheiro de configurao deve incluir tambm a indicao da directoria onde fica localizado fisicamente o repositrio e os ndices a serem mantidos na base de dados. O repositrio LDAP foi configurado com um pequeno modelo derivado de PCIM e PCIMe. Estes modelos mais genricos tm as classes nucleares para modelagem de polticas, embora no sejam suficientes muitas vezes para representar regras concretas [RFC3460]. Para alm 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 definio dos filtros neste trabalho so: A classe PolicyFlowDirectionVariable: indica a direco de um fluxo (IN ou OUT) relativamente a um elemento de rede. A classe SimplePolicyAction: modela uma aco de configurao, por exemplo marcao do DSCP. A classe IpHeadersFilter: contm as propriedades mais comuns requeridas para construir critrios de seleco com base no contedo dos cabealhos IP, TCP ou UDP.

4.2.5 PDP
A implementao do PDP utilizou as livrarias PIB, COPS e COPS-PR e um cdigo exemplo desenvolvidos em linguagem C na Universidade de Tampere, Finlndia [Lemponen]. O software data de Setembro de 2002 e est disponvel 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 instalao deste software tem como requisito livrarias de codificao 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 esto as livrarias libabz. 72

B LOCOS F UNCIONAIS O exemplo existente (verso 0.4) tem as seguintes funcionalidades: Trabalha apenas em modo interactivo. Aceita conexes de sistemas PEP e recebe as suas configuraes. Responde s mensagens peridicas KA (Keep-Alive) dos clientes. Quando h uma solicitao do PEP, envia um conjunto padro de configuraes. Trabalhar em modo background ou em modo interactivo. Aceitar conexes na porta 32880, para receber da PMT indicaes de instalao e remoo de polticas em XML. Esta personalizao das funes do PDP limita a soluo em termos de transparncia entre os nveis funcionais e possibilidade da utilizao de outras implementaes PDP-PEP, mas oferece uma compensao importante: permite que a PMT obtenha indicaes 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 remoo e enviar para os PEP. A funcionalidade de detectar necessidades de configurao dos filtros e os respectivos parmetros de instalao, independente da PMT no modelo do IETF. Ao invs de programar o acesso LDAP no PDP, este trabalho usa a implementao feita na PMT para o efeito. Enviar para a PMT informaes sobre os filtros instalados (referentes configurao dinmica dos encaminhadores de fronteira).

Foi feita uma interveno para que o cdigo do PDP passasse a:

Em ambiente de produo, o PDP deve ser implementado como um servio (daemon) que arranca na inicializao 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 validao XML esto listados no apndice A.

73

4. DETALHES DA SOLUO IMPLEMENTADA

PMT

PDP PEP (inicializa) Inicia sesso 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 implementao do PEP utilizou as livrarias e um cdigo exemplo desenvolvidos em linguagem C na Universidade de Tampere, Finlndia [Lemponen00]. Detalhes mais completos do seu funcionamento podem ser encontrados no trabalho referido. O exemplo existente tem as funcionalidades: Trabalha sempre em modo interactivo. Conexo com o PDP. O endereo deste e porta de ligao podem ser indicados na linha de comandos. Troca de mensagens KA (Keep-Alive) periodicamente com o PDP. Solicitao de decises (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 servio do sistema) ou em modo interactivo. Leitura de um ficheiro de configurao com as indicaes do endereo do PDP, porta de ligao, interfaces disponveis no encaminhador local e o papel de cada uma (exterior/interior), e a localizao do ficheiro para a configurao inicial bsica DiffServ. Execuo do ficheiro de configurao DiffServ (script Linux com comandos tc) na inicializao (configurao bsica das interfaces), aps ler o seu prprio ficheiro de configurao. Recepo a partir do PDP de comandos de configurao ou remoo de filtros em formato PIB, traduo para os comandos adequados de configurao do Linux e aplicao na(s) interface(s) externa(s) do PEP. Envio para o PDP de relatrios relativos aos comandos recebidos e configurao do encaminhador. Correco da livraria para evitar bloquear as mensagens KA em caso de excesso de actividade ou trfego com o PDP. # activar modo interactivo com mensagens debug ON # Descrio textual para o PEP desc Linux kernel 2.4.20-8 # Tipo do encaminhador PEPtipo fronteira # interfaces do sistema e sua funo interna eth0 externa eth1 # ficheiro config basica DiffServ PEPscript /etc/config-pep-tc # endereo do PDP PDPsrv 192.168.2.2 # porta do PDP portaPDP 3288 Figura 4.5: Ficheiro de Configurao para o PEP O funcionamento do PEP est esquematizado na figura 4.6. Ao inicializar, o PEP l o seu ficheiro de configurao e lana o script DiffServ para configurar as interfaces conhecidas segundo a funo de cada uma. Se algum dos ficheiros no existir, a aplicao termina com uma mensagem para o ficheiro /etc/PEPlog. A seguir envia sua identificao e lista de funcionalidades para o PDP e os dois sistemas entram num ciclo de keep-alives (KA). As mensages KA so utilizadas como unidade de tempo para o PEP enviar periodicamente (de n em n KA) um relatrio dos filtros instalados no PEP, que o PDP passa PMT em formato XML quando solicitado.

A figura 4.5 mostra um exemplo de ficheiro de configurao para o PEP.

75

4. DETALHES DA SOLUO IMPLEMENTADA

Shell/ Kernel

PEP (inicializa) Le ficheiro PEP.conf

PDP

Cria configurao bsica DiffServ e Interroga filtros tc

Inicia sesso PIB (Id, Funcionalidades) KA . . KA

Interroga filtros tc

PIB (filtros) KA .

Cria ou elimina filtro(s) tc (PEP de fronteira)

. PIB (instala ou remove poltica) 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 contm informao de capacidades do encaminhador (ver a seco 2.7.3 sobre a operao do COPS e COPS-PR). Em resposta, o PDP pode enviar uma mensagem install para criar uma configurao bsica no PEP. Caso o PDP esteja inactivo, o PEP instala esta configurao se a conhecer. Certos pressupostos da arquitectura DiffServ no poderiam ser implementados sem uma anlise exaustiva e porventura modificao e actualizao das livrarias PIB utilizadas. Ao invs de manter um repositrio de estado para o PEP, como sugere o modelo, limitamo-nos a fazer com que a configurao do encaminhador ficasse transparente para sua operao. O PEP configura ou remove um filtro na(s) interface(s) externa(s), e envia o resultado desta operao para as camadas superiores da arquitectura, onde foi concentrado o esforo principal de desenvolvimento neste trabalho.

76

B LOCOS F UNCIONAIS O prottipo funcional desenvolvido cria, elimina e reporta do PEP filtros baseados nos atributos do protocolo IP que se encontram disponveis 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 Descrio Tipo de endereo: 1 IPv4; 2 IPv6; 16 Domnio DNS Endereo de destino dos pacotes Mscara do endereo de destino Endereo de origem dos pacotes Mscara do endereo de origem Cdigo DSCP dos pacotes Fluxo IPv6 dos pacotes Protocolo nvel 4 (ex. TCP, UDP,) Porta inicial de destino nvel 4 Porta final de destino nvel 4 Porta inicial de origem nvel 4 Porta final de origem nvel 4

Tabela 4.3: Atributos da Tabela FrwkIpFilterEntry (RFC 3318) Em ambiente de produo, o PEP deve ser implementado como um servio (daemon) que arranca na inicializao 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 trfego com componentes DiffServ parte integrante do kernel Linux utilizado (verso 2.4.20-8). Alm dos mdulos QdS, outros componentes podem actuar sobre trfego, seleccionar e marcar pacotes. H um esquema disponvel 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 Servio, a figura 4.7 mostra como os mdulos DiffServ so realizados pelos servios do kernel Linux. Os componentes bsicos do controlo de trfego no Linux so as disciplinas de filas (qdisc), as classes e os filtros [Almesberger]. As disciplinas de filas e classes so identificadas por dois nmeros hexadecimais atravs da notao <maior>:<menor>. Para qdiscs, o segundo nmero (menor) sempre zero e pode ser omitido na notao. H uma disciplina especial denominada ingress (ver adiante) que sempre deve ter o nmero maior igual a ffff. As outras podem utilizar a faixa de nmeros entre 1 e 0x7fff.

77

4. DETALHES DA SOLUO IMPLEMENTADA

Condicionador de Trfego DiffServ

Medidor

Classificador

Marcador

Shaper/ Descartador

Controlo do Trfego no kernel Linux

Filtro Poltica Classificador Disciplina de Fila

Classe

Figura 4.7: Realizao dos Mdulos DiffServ no Linux Para classes, o nmero menor sempre acima de zero. O termo identificador de classe (class ID) frequentemente utilizado em lugar do nmero menor. A atribuio de pacotes de trfego a classes especficas pode ser feita com os filtros. Os critrios de filtragem podem incluir endereos, protocolos e portas da comunicao e outros campos do cabealho dos pacotes, alm de outras possibilidades (manipulao prvia pelas rotinas de firewall, por exemplo). Nas verses 2.4.x do kernel Linux, a filtragem de pacotes possibilitada por um conjunto de componentes integrados com o nome genrico de Netfilter, que inclui as funcionalidades de firewall e masquerading IP. Uma das opes mais teis (no utilizada directamente neste trabalho) a de guardar um registo das conexes existentes para fazer marcao ou eliminao de pacotes. A ferramenta utilizada para configurar as regras Netfilter a aplicao iptables. Os parmetros DiffServ num encaminhador Linux podem ser configurados de vrias formas: Na shell (interactivamente, por script ou pela invocao dentro de um programa) atravs do comando tc (traffic conditioning) [Almesberger99, Hubert02]. Dentro de uma aplicao, com a API rtnetlink do kernel [Hubert]. Atravs do agente de configurao remota DSR, que tem um conjunto de capacidades teis para muitas situaes de utilizao dos encaminhadores, embora no oferea todo o potencial das solues anteriores [Calhariz].

Este trabalho utiliza os comandos tc atravs de scripts e por invocao da shell dentro do PEP. Os scripts fazem a configurao esttica de base das interfaces externa e interna, e o PEP aplica e remove filtros na interface externa. 78

B LOCOS F UNCIONAIS Numa perspectiva prtica, o conjunto de definies proposto seria automaticamente e sempre instalado na inicializao dos encaminhadores de fronteira e interiores e constituiria uma configurao esttica de base. A ideia principal disponibilizar as classes normalizadas para as quais sero enviados fluxos individuais de trfego classificados por filtros especficos aplicados na interface externa do encaminhador de fronteira aps a configurao base ser instalada. Caso a arquitectura esteja totalmente instalada, os filtros classificadores sero construdos atravs das interfaces de definio das polticas e implementados automaticamente; tambm continua sendo possvel a aplicao incremental de scripts com comandos tc, embora este procedimento seja potencialmente desestabilizador para a gesto do ambiente. Os parmetros especficos dos classificadores e disciplinas de filas, tal como largura de banda e outros, podero ser ajustados atravs da manipulao dos scripts. Este procedimento deve estar condicionado ao conhecimento do impacte que o ajuste dos parmetros tem nos nveis superiores da arquitectura proposta. A seguir mostramos como fazer o mapeamento da configurao de base proposta no captulo 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 configurao bsica podem ser acrescentados os filtros de seleco s interfaces externas para classificar os pacotes nas classes definidas segundo os critrios desejados. Se no forem definidos filtros, todo o trfego classificado como BE e o campo DS de todos os pacotes fica com a marcao 0x0 aps deixar o encaminhador pelas interfaces internas ao domnio. Nas interfaces exteriores dos encaminhadores de fronteira, ser feita a classificao e policiamento dos pacotes que entram no domnio, como j foi explicado. Para tratar apenas os pacotes que vm para o domnio, no necessrio configurar PHB nestas interfaces. Assim, apenas configurada uma disciplina de fila tipo ingress, que um classificador com policiamento. No coloca pacotes em fila e consome um mnimo de recursos. Os filtros a serem configurados ou removidos de forma dinmica para atender aos SLA controlam o descarte ou a indicao (para as interfaces internas) de marcao 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 varivel qual ter sido atribudo o nome da interface exterior): tc qdisc add dev $IFaceExt handle ffff: ingress O script no configura mais nada nesta interface. Nos comandos tc class (linhas 02 a 15), o minor number do parmetro classid representa por omisso um valor hexadecimal. J na definio dos filtros (linhas 41 a 54), o handle correspondente representado por um nmero decimal. Assim, pacotes marcados pela classe 1:11 tm o handle 17 (0x11) e pacotes marcados pela classe 1:33 tm o handle 51 (0x33). Os outros seguem o mesmo critrio. 79

4. DETALHES DA SOLUO IMPLEMENTADA Os valores dos minor numbers das classes de marcao (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 vo 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, responsvel pela marcao (na fronteira) ou avaliao (no interior) do campo DS dos pacotes [SForge]. DSMARK uma fila classful, e as suas classes so 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 atravs 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 definies das classes com os valores que sero 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 parmetro classid representa por omisso um valor hexadecimal que dever ser igualado mais tarde no filtro respectivo para cada classe. Como tambm foi dito acima, a escolha destes valores no aleatria, sendo condicionada pela utilizao da disciplina GRED para as classes AF. A marcao feita atravs da operao: Novo_DS = (DS_anterior & mscara) | valor & e | so os operadores binrios AND e OR. A mscara utilizada nas classes acima (0x3) aplica-se a todo o campo ToS e, com este valor, preserva na marcao os dois bits ECN (Explicit Congestion Notification) [RFC3168]. Os valores de marcao (parmetro value) tambm aplicam-se a todo o campo ToS e correspondem aos DSCP recomendados para as classes assinaladas nos comentrios (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 emprstimo da largura da banda no utilizada aos fluxos de trfego associados s suas classes, evitando desperdcios [Brown]. As classes cujo parent esta disciplina tero o parmetro classid com o formato 2:<minor number>. Por omisso, o trfego enviado para a classe 2:1 (parmetro default). Segundo Martin Devera, o criador da disciplina HTB (baseando-se no mecanismo de partilha formal exposto por Sally Floyd em [Floyd95b]), a sua utilizao prefervel relativamente disciplina CBQ porque esta ltima algumas vezes apresenta resultados inconsistentes. Esta opinio foi posteriormente suportada por simulaes e estatsticas reais, pelo prprio 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 omisso para os fluxos de dados no enviados para outras classes, ou para aqueles fluxos para os quais o administrador deseje um tratamento compatvel com o comportamento tradicional da Internet (na base do melhor esforo). Se o ritmo dos dados nesta classe ultrapassar o valor especificado no parmetro rate, ela pode iniciar o emprstimo de largura de banda disponvel na classe me (linha 16) at ao valor estipulado pelo parmetro ceil. Assim, mesmo estando numa classe com garantias inferiores s das outras, o trfego BE pode utilizar toda a largura de banda que no estiver j atribuda. O mesmo passa-se com o trfego de qualquer das outras classes. A disciplina de fila associada ser identificada com o handle 60 (til na visualizao e tratamento de estatsticas do tc) e o seu tipo RED Random Early Detection. Este tipo de fila utiliza um procedimento para seleco aleatria de pacotes a serem marcados para o descarte ou seja, os pacotes do fim da fila no tm maior probabilidade de descarte em caso de congesto, como na disciplina FIFO. Quando a fila RED tiver um total de bytes entre min e max, a probabilidade mxima de marcao para descarte em qualquer pacote de probability (neste caso de 2%); acima de max todos os pacotes so marcados para descarte. A relao sugerida (e mais encontrada em implementaes reais) entre os parmetros min e max de 1 para 3. O valor do parmetro limit indica o limite fsico da fila e deve ser algumas vezes maior que max [Floyd95b]. O parmetro burst indica a quantidade de dados que pode ser enviada em cada sesso na velocidade mxima do hardware para uma s classe antes de 81

4. DETALHES DA SOLUO IMPLEMENTADA atender outras classes. O valor deste parmetro nunca deve ser menor na classe parent (se especificado) e pode basear-se na seguinte relao emprica entre os outros parmetros [Balliachi03 2]: burst = (2*min + max) MOD (3*avpkt) O parmetro avpkt especificado em bytes e ajuda a determinar a constante de tempo para os clculos do tamanho mdio da fila. Este valor pode ser ajustado pelo administrador aps medies do tamanho mdio dos pacotes. bandwidth a taxa fsica da interface e utilizado para calcular o tamanho mdio da fila aps um perodo sem trfego. 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 trs 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 dinmicas 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 dispe de trs prioridades de descarte realizadas com trs filas RED virtuais. possvel remarcar pacotes entre as filas virtuais de uma mesma classe AF sem prejudicar a sua sequncia. As outras classes AF so 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 srie de comandos como o mostrado acima iro criar classificadores para a classe HTB principal encaminhar os diversos fluxos de trfego para as classes DiffServ adequadas, onde ser feito o shaping do trfego no caso dos encaminhadores interiores. Nos encaminhadores de fronteira, o trfego 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 aco do utilizador ou administrador. Como os TCS so especificados com uma hora de incio e outra de fim, a sinalizao da PMT para o PDP assncrona em relao conversao PDP-IU. As mensagens 6 e 9 so relatrios dos filtros instalados. So enviadas assncronamente em relao instalao dos filtros propriamente dita, e pode haver um perodo de tempo (medido em segundos) em que o comando de instalao j seguiu, mas qualquer interrogao da PMT no mostra o filtro instalado. Isto devido ao tempo que a shell demora para responder interrogao por filtros, feita periodicamente pelo PEP. O comando inclui eliminao de entradas duplicadas e edio com ferramentas da shell para que a resposta seja formatada adequadamente. A soluo encontrada foi enviar o resultado deste comando para um ficheiro, e depois ler o contedo do ficheiro.
(1) <ActualSol> <tcs> (2) Add dn

Interface com o Utilizador

32881 (4) <ActualRsp> OK (6) <Rpt> (7a) PIB

PMT

389 (3) dn added.

Repositrio
(5) <criaPolitica> (7b) PIB

32880

PEP1
(8a) System tc (9a) PIB rpt

3288

PDP

3288 (9b) PIB rpt

PEP2
(8b) System tc

Kernel

Kernel

Figura 4.8: Funcionamento Integrado da Arquitectura Proposta As mensagens completas so (os parmetros esto 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_endereo 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 SOLUO 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. So 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 informao sobre os filtros instalados em cada PEP no campo Descr.

4.4 Limitaes do Modelo

A implementao realizada atende apenas a encaminhadores Linux, embora esta restrio aplique-se somente ao nvel inferior da arquitectura proposta (PEP). O modelo implementado configura apenas filtros para atributos da tabela PIB FrwkIpFilterEntry (ver figura 4.3). O tipo de programao (sem threads) utilizada para o servidor de aprovisionamento limita fortemente a sua escalabilidade a nvel de clientes PEP. A PMT j no apresenta este problema. A tolerncia a falhas da soluo pode ser muito melhorada se as aplicaes escreverem em ficheiros XML os comandos que trocam entre si e com o repositrio LDAP. Em caso de indisponibilidade temporria do PDP, por exemplo, a PMT pode enviar os comandos quando aquele estiver novamente ligado. Se falhar o repositrio, a PMT poderia aplicar todas as alteraes a partir de um ficheiro com a informao necessria quando possvel. Outro ponto de relevncia a segurana. No foram implementadas solues de encriptao e proteco dos dados, para facilitar o debugging durante a fase de 84

LIMITAES DO M ODELO testes. A autenticao feita de forma bsica, no integrada com sistemas especializados (e.g. RADIUS). Alteraes ao script de configurao com os comandos tc devem ser feitas manualmente, mas com extremo cuidado. Este script essencial para o bom funcionamento da arquitectura e gesto dos filtros nos encaminhadores de fronteira.

85

Testes

5.1 Introduo
Os testes efectuados so divididos em testes funcionais e testes de desempenho. Este captulo caracteriza o ambiente utilizado nos testes e tambm explica os requisitos especficos para cada situao testada. Procura analisar os resultados numa perspectiva de obedincia aos objectivos propostos.

5.2 Cenrio de Testes

Os testes foram realizados numa rede isolada construda para este propsito, na qual os computadores utilizados tm 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 disposio, configurao e funes do equipamento para os testes funcionais e de desempenho.

linox
(Repositrio LDAP)

192.168.3.2

192.168.3.1

eth0

eth1

linix
(encaminhador)

192.168.1.2

eth0

HUB 100 Mbit

PMT & Monitorizao (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 estao de monitorizao para desempenhar as funes de PMT porque os testes de desempenho so destinados a caracterizar o funcionamento DiffServ da rede, num momento em que tipicamente a PMT no vai gerar trfego porque j criou as configuraes necessrias. Esta observao

87

5. TESTES aplica-se tambm utilizao de uma s mquina para as funes de PDP e Interface do Utilizador. Cada encaminhador teve o papel de encaminhador de fronteira ou interior, conforme o teste especfico. As aplicaes foram configuradas para criar ficheiros de log com data e hora (ao milsimo ou milionsimo de segundo) das ocorrncias. Um requisito essencial para o bom funcionamento desta aplicao, que a configurao das classes DiffServ esteja consistente no repositrio e no script dos encaminhadores.

5.3 Testes Funcionais

5.3.1 Introduo
Os testes funcionais destinam-se a comprovar: 1 O correcto funcionamento da Interface do Utilizador na visualizao, criao, alterao e remoo de polticas (SLA e TCS). 2 A efectiva configurao do(s) encaminhador(es) com a configurao de base e com as polticas (TCS) definidas na Interface do Utilizador. Para todo o ambiente de testes, foram pr-configuradas no repositrio LDAP as classes de servio oferecidas, como mostra a figura 5.2. A ferramenta utilizada para visualizar estas informaes foi o utilitrio LDAPBrowser.

Figura 5.2: Classes Definidas no Repositrio

5.3.2 Configurao 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 configuraes so efectuadas no ficheiro /etc/PEP.conf em cada uma das mquinas (ver a

88

TESTES F UNCIONAIS seco 3.4.6). Quando a aplicao PEP inicializa, l este ficheiro e lana o script de configurao tc com os parmetros adequados. A figura 5.3 mostra o resultado de executar a aplicao PEP no encaminhador de fronteira e a configurao respectiva. Foram utilizados comandos da shell Linux para obter estas informaes.
[root@linax /]# cat /etc/PEP.conf ####################### # Configurao 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: Configurao do Encaminhador de Fronteira A figura 5.4 mostra o resultado de executar a aplicao PEP no encaminhador interior, juntamente com o ficheiro de configurao.
[root@linax /]# cat /etc/PEP.conf ####################### # Configurao 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: Configurao do Encaminhador Interior Pode-se ver a diferena na configurao 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 domnio propriamente dito.

5.3.3 Criao de SLA

A criao e eliminao dos SLA e TCS so operaes efectuadas atravs da Interface do Utilizador. Esta executa em qualquer mquina ligada rede que disponha do ambiente de execuo Java. A figura 5.5 mostra o ecr de criao de um SLA.

Figura 5.5: Criao 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 solicitao, e criou um SLA com os parmetros visualizados na figura. As prioridades utilizadas devem ser geridas pelo administrador em conjunto com aquelas atribudas 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 no entrem em conflito e que sejam respeitados os parmetros do SLA. A figura 5.6 permite visualizar o resultado da operao, a nvel do repositrio. Alm das classes que j existiam, passa a haver tambm a definio do SLA criado. 90

TESTES F UNCIONAIS

Figura 5.6: O SLA no Repositrio O XML entre a IU e a PMT para criao do SLA mostrado na figura 5.7.
2004-09-14 10:04:13.846 >> <ActualSol><sla><dlmDescription>Trfego 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 Criao de um SLA

5.3.4 Criao do TCS

No captulo 4, a figura 4.2 mostra o ecr de criao de um TCS na Interface do Utilizador. Os campos deixados em branco assumem valores por omisso, geralmente os do SLA. A criao de um TCS reutiliza ou cria diversas condies e aces no repositrio. A figura 5.8 mostra as condies e aces que foram criadas neste teste, visto no existirem anteriormente.

Figura 5.8: Condies e Aces Criadas no Repositrio

91

5. TESTES Na figura anterior tambm visvel a entrada referente ao TCS, mostrada em detalhe na figura 5.9.

Figura 5.9: Atributos do TCS no Repositrio 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>Trfego 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 Criao de um TCS Ao nvel dos encaminhadores, a criao de um TCS afecta a interface externa do encaminhador de fronteira (no caso a interface eth1 da mquina Linax). O comando enviado pela aplicao PEP para a shell Linux visvel 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 Atravs de um comando tc na shell do encaminhador, podemos solicitar o relatrio 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: Relatrio de Filtros no Encaminhador de Fronteira

5.3.5 Efeito do TCS no Transporte de Pacotes

O TCS foi configurado com uma hora de incio anterior actual, e assim resultou imediatamente na aplicao do respectivo filtro tc no encaminhador de fronteira. Atravs da aplicao Ethereal, capturamos o trfego no troo entre os dois encaminhadores e constatmos que a poltica desejada estava funcional, como mostra a figura 5.13.

Figura 5.13: Anlise 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 aplicao.

5.3.6 Eliminao de TCS

A eliminao de um TCS activo implica tambm na remoo da poltica configurada nos encaminhadores de fronteira. Esta anlise feita pela PMT, a qual envia os comandos de remoo de poltica para o PDP, se necessrio. A remoo de uma poltica, por restries do comando tc do Linux, feita atravs da designao da sua prioridade. Isto deve ser levado em considerao

93

5. TESTES tanto pelo administrador quanto pelos utilizadores na configurao dos SLA e dos TCS. A eliminao de um TCS no elimina do repositrio as condies e aces que foram utilizadas por ele. Elas podero servir para outra poltica futuramente. O XML entre a Interface do Utilizador e a PMT para remoo 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 Remoo de um TCS As tabelas PIB recebidas pelo PEP e o comando para remoo 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: Remoo de um TCS no PEP A indicao de que se trata de uma remoo, e qual a poltica a remover dada pelo atributo dsClfrElementPrecedence no elemento classificador.

5.4 Testes de Desempenho

5.4.1 Introduo
Os testes de desempenho tm um conjunto de requisitos para maior fiabilidade: 94

TESTES DE D ESEMPENHO 1 A rede de testes est isolada e no h aplicaes no essenciais em operao. 2 Os relgios 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 referncia, e os outros ajustam o seu relgio por ele. 3 As medidas relativas ao desempenho do trfego devem ser efectuadas por uma estao no participativa neste mesmo trfego. Caso seja utilizado um switch para ligao das mquinas, necessrio configurar a porta da estao de monitorizao para que consiga capturar os pacotes das conversaes entre os outros sistemas. A rede de testes utilizou um hub 10/100, que no requer configurao.

5.4.2 Desempenho das Aplicaes

O desempenho da Interface com o Utilizador apresenta as limitaes tpicas de uma aplicao grfica em Java. Aps a validao do utilizador, o nmero de SLA e TCS a serem apresentados condiciona fortemente o tempo de resposta para visualizao do prximo ecr. O maior impacto sentido pelo administrador, que recebe todos os SLA e TCS configurados no repositrio. Tipicamente, um utilizador ter um SLA e poucos TCS a receber. Neste ltimo caso, o tempo de resposta mdio obtido foi de 1,973 segundos para um SLA e um TCS. A criao e remoo de TCS apresentou um tempo de resposta tambm prximo dos 2 segundos (2,191 segundos), beneficiando-se do facto de as operaes com o PDP (e deste para o PEP) serem efectuadas de forma assncrona relativamente ao trfego IU-PMT.

5.4.3 Policiamento na Interface Externa

Na arquitectura proposta, o encaminhador de fronteira faz um condicionamento inicial do trfego e tambm a marcao dos pacotes que entram no domnio. Os encaminhadores interiores utilizam a marcao para fazer o shaping por classe DiffServ. Foi utilizada a mquina Linax como encaminhador de fronteira e a mquina Linix como encaminhador interior. Esta ltima teve desactivada a configurao DiffServ na maioria dos testes relativos aos policiadores, para no 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 atravs da execuo na mquina Linex de um script para enviar comandos ping aos outros segmentos de rede, com a opo de flooding activada. Esta opo envia pings com a velocidade permitida pela interface de rede. Os resultados obtidos sem condicionamento so mostrados na figura 5.16. O acesso ao sistema Linox passa por mais um encaminhador, portanto penalizado em relao troca de mensagens com o sistema Linix (embora no 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 trfego ICMP entre a mquina Linex e a rede 192.168.3.0 (onde encontra-se a mquina Linox). O valor para largura de banda foi limitado a 50 Kbps, na classe Diamante (EF) com descarte para os pacotes fora de perfil. Aps verificar que a poltica tinha sido implementada no PEP de fronteira, o script anteriormente utilizado foi novamente executado com os resultados visveis 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 repetio sistemtica destes testes indica que os valores aqui exibidos so representativos do comportamento mdio em cada caso. A monitorizao do troo 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 comparao entre os resultados apresentados na figura 5.16 e os resultados da figura 5.17 mostra que a activao do TCS resultou na perda e atraso selectivo dos pacotes destinados ao sistema Linox, em benefcio do trfego de pacotes para o sistema Linix. Foi efectuado um estudo mais abrangente do policiamento, com a configurao de filtros com vrias larguras de banda. A tabela 5.1 indica os valores obtidos para diversas execues do mesmo script de teste, com alterao da largura de banda configurado no policiador. A figura 5.18 ilustra estes mesmos resultados em um grfico. Foi considerado apenas o fluxo de trfego afectado (ping para Linox). Os resultados destes testes indicam qualitativamente que o policiamento est a actuar como suposto. Uma anlise quantitativa s pode ser elaborada de maneira superficial, a menos que seja utilizado hardware adequado para gerao de trfego e medio da largura de banda. 96

TESTES DE D ESEMPENHO Largura de Banda (Kbps)

25 50 75 100 125 150 175 200 225 250 275 400 500

Tempo Total (s)

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

Perdas (%)
48 32 24 19 15 13 10 10 8 7 6 1 0

rtt mdio (ms/10)

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 Trfego
50 40 30 20 10 0 25 50 75 100 125 150 175 200 225 250 275 Largura de Banda Tempo (s) Perdas (%) rtt mdio (ms/10)

Figura 5.18: Policiamento do Trfego O tamanho do pacote tem grande influncia nos resultados, como pode ser visto na tabela 5.2. Largura de Banda (Kbps)
100 200 300 400 500

Perdas (84 bytes)

19% 10% 3% 1% 0%

Perdas (1028 bytes)

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 no podem restringir demasiado a largura de banda. Contrariamente, a configurao 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 obteno dos resultados: a aplicao utilizada (ping, wget, etc.) pode reportar as estatsticas como nos testes da seco anterior, e o prprio encaminhador interior, atravs de um comando tc, mostra as estatsticas de utilizao das classes e filas configuradas. O TCS utilizado para configurao do policiamento de fronteira foi sempre o mesmo, enviando todo o trfego ICMP entre Linex e Linox para a classe AF21 at ao limite de 10 Mbps. Foram utilizados pacotes de 1028 bytes, porque os descartes so mais facilmente forados. A classe AF2 e a sua prioridade de descarte DP1 utilizam no script a configurao 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: Configurao da Classe AF2 Com esta configurao, o teste ping teve o resultado mostrado na figura 5.20, onde foram includos 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 Configurao Padro Os testes simulam a partilha da largura de banda com outros fluxos, atravs da alterao do parmetro 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 no foram reportadas como

98

TESTES DE D ESEMPENHO descartes pelo tc, e o mais provvel deverem-se sobrecarga dos buffers nas diversas mquinas por onde passa o fluxo. ceil (Kbps)
50 100 200 300 400 500 600 700 800 900 1000 1100 1200 1500 2000 3000 4000

Perdas (%)
70 58 38 16 1 1 0 1 1 1 0 1 0 0 1 0 1

Tempo (s)
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 Transmisso para a Classe AF21 A figura 5.21 ilustra uma situao 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 Trs Classes

No funcionamento normal da arquitectura proposta, os TCS para as classes Bronze DP2 a Platina DP1 podem especificar a remarcao dos pacotes ao invs do descarte. Nesta situao, o agente PEP cria filtros adicionais que permitem a remarcao dentro da mesma classe para outra prioridade de descarte. Neste teste criado um TCS na classe de servio Prata DP1 (AF31) com limitao da largura de banda a 50 Kbps, e especificao de remarcao 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 Remarcao para AF32 e AF33 Foi utilizado um valor de largura de banda suficientemente baixo (50 Kbps) para forar a remarcao dos pacotes mais pequenos (84 bytes). A figura 5.23 permite comparar os resultados obtidos com pacotes pequenos, mdios (528 bytes) e grandes (1028 bytes). Novamente, os pacotes maiores ultrapassam mais facilmente o perfil e so mais penalizados que os pacotes de menor dimenso.
## 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 relatrios de utilizao das classes no encaminhador de fronteira so mostrados na figura 5.24. Os descartes no 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 nmero igual de pacotes para cada classe no caso dos pacotes maiores, e nmeros 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: Utilizao das Prioridades de Descarte AF3

101

5. TESTES

5.4.6 Desempenho do Trfego Condicionado nas Sub-Redes

Este teste mostra como os pacotes so afectados desde o incio do trfego, at chegarem ao seu destino, passando por um encaminhador de fronteira e por um encaminhador interior. Esto envolvidas trs sub-redes, nas quais foram feitas medies simultneas. O trfego consistiu de pacotes ICMP com 200 bytes entre as mquinas Linex e Linox. Apenas foi condicionado e avaliado o trfego com origem na mquina Linex. O comando utilizado foi ping f c 2000 s 200 linox e a figura 5.25 mostra os resultados da sua execuo na mquina Linex, antes e aps condicionar o trfego.
## 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: Execuo do ping A tabela 5.4 mostra os resultados da captura de trfego no condicionado nas trs sub-redes, indicando o nmero de pacotes transportados a intervalos de 200 milissegundos medidos na origem do trfego. 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 troo 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 Trfego no Condicionado

102

TESTES DE D ESEMPENHO As diferenas observadas devem-se apenas ao tempo de propagao dos pacotes e possivelmente a algum factor aleatrio relacionado com o hardware. Aps realizar as medies 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 mxima igual a 200 Kbps. Tambm foi alterado o parmetro ceil da classe EF no script de configurao 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 so medidos em segundos e no em milissegundos devido ao maior tempo de durao do teste, e foram utilizados mais intervalos que no teste anterior para uma melhor caracterizao das diferenas para o trfego 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 Trfego Condicionado Os resultados indicam que o verdadeiro policiamento e shaping (retardo selectivo) foram efectuados no encaminhador de fronteira, e o fluxo de trfego 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. Tambm pode ser deduzido destes testes que o aumento do nmero de encaminhadores interiores utilizados teria influncia no jitter (variao 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 considerao ao configurar os valores do parmetro ceil para as diversas classes DiffServ.

103

Concluses e Trabalho Futuro

A gesto das polticas de qualidade de servio numa rede de computadores pode ser implementada em conjunto com a arquitectura DiffServ definida pelo IETF para facilitar e tornar consistente a configurao dos encaminhadores de fronteira e dos encaminhadores interiores da rede. Este modelo conjunto permite uma separao entre a definio de alto nvel das polticas armazenadas em um repositrio, e as especificadades tcnicas da sua implementao nos encaminhadores. Outro benefcio derivado do armazenamento das polticas num repositrio, a possibilidade de reutilizao dos seus elementos sem necessidade de os redefinir ou armazenar de forma redundante. A utilizao das tabelas virtuais PIB e dos protocolos COPS e COPS-PR para aprovisionamento de polticas tem a vantagem (para alm da separao entre definies de polticas de alto nvel e polticas de baixo nvel) de poder atender a outros servios diferentes do DiffServ, com requisitos diversos de aprovisionamento, tais como IPSec, load balancing e contabilizao da utilizao de recursos. A soluo implementada, embora limitada ao nvel das condies e aces 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 utilizao do XML como linguagem de transporte das polticas de alto nvel foi fundamental neste contexto, permitindo uma integrao facilitada e consistente dos mdulos envolvidos. O protocolo LDAP mostrou-se adequado para a construo do repositrio, tanto pela facilidade de implementao do schema como pela simplicidade da interface das livrarias JLDAP. A linguagem Java utilizada no desenvolvimento da Interface com o Utilizador e da PMT, pde ser directamente comparada com a linguagem C, utilizada na adaptao dos cdigos disponveis para PDP e PEP, com vantagens para o Java na curva de aprendizagem e disponibilidade de cdigos exemplo, alm de maior simplicidade das API de acesso rede. Os programas escritos em linguagem C caracterizam-se por uma maior eficincia de execuo. Foi especialmente proveitosa para este trabalho a abrangncia da implementao DiffServ no kernel dos sistemas Linux, e a sua facilidade de utilizao e configurao embora a documentao de muitas caractersticas no seja especialmente abundante ou fcil de localizar. Sentimos especial dificuldade na realizao do conjunto de polticas de alto nvel disponibilizadas para o utilizador. A anlise na seco 2.2.2 permite perceber que definies pouco tcnicas implicam numa maior complexidade e inteligncia da soluo implementada. Nossa abordagem cria uma linguagem de definio de polticas atravs do XML e usa termos menos tcnicos na apresentao das especificaes de SLA e TCS ao utilizador. No preenchimento das especificaes para um novo TCS, o utilizador tem ainda a possibilidade de deixar em branco muitos dos campos que sero preenchidos automaticamente pela aplicao, ou simplesmente ignorados.

105

6. CONCLUSES E TRABALHO FUTURO A entrada em produo da implementao proposta deve ficar condicionada a testes de funcionalidades e fiabilidade do modelo e de cada aplicao individual na rede onde for operar. Dentre as possveis evolues deste trabalho, pensamos serem relevantes intervenes nas aplicaes PDP e PEP para utilizarem completamente as especificaes actuais da arquitectura DiffServ, o desenho de mdulos PEP para outros tipos de encaminhadores e uma definio mais completa e abrangente das polticas de alto nvel de forma a atender solicitaes no previstas neste trabalho (por exemplo, integrao com mdulos para reconhecer e filtrar certos tipos de trfego). Na aplicao PMT, uma vez que j est programado um mecanismo para obter um relatrio dos filtros instalados nos PEP, um melhoramento importante seria a comparao desta informao com a informao das polticas contidas no repositrio, de forma a garantir a todo momento, a consistncia da configurao nos encaminhadores de fronteira. Na aplicao Interface com o Utilizador, poderiam existir facilidades de visualizao e configurao da largura de banda disponvel em cada uma das classes de servio configuradas. Finalmente, desejvel o desenvolvimento de um ambiente de testes completo para ajustar os parmetros de configurao das diversas disciplinas de fila no Linux, de modo a utilizar os valores mais adequados para domnios especficos. Tambm so importantes futuras actualizaes tecnolgicas para que o modelo no fique ultrapassado relativamente ao trabalho dos organismos normativos. Um exemplo a utilizao de schema ao invs de DTD para as definies XML, outro a actualizao das livrarias PIB com as definies mais recentes do IETF.

106

A. Ficheiros de validao DTD

A.1 Instalao de Polticas (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 VALIDAO DTD

A.2 Relatrio 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 Remoo de Polticas (PMT >> PDP)

<!ELEMENT rmPolitica (clElement*)> <!ELEMENT clElement (precedencia*)> <!ELEMENT precedencia (#PCDATA)>

108

B. O Schema de Polticas 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 Servio: 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 POLTICAS 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

So apresentadas as tabelas PIB utilizadas neste trabalho, como definidas na livraria original.

C.1 Tabelas de Identificao e Capabilities

1. Identificao 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 Manipulao de Polticas

4. Marcador do Fluxo (no 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 Aces
/* 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 parmetros 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

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 domnio # Disciplina raiz $TC qdisc add dev $INTERFACE handle 1:0 root dsmark indices 128 default_index 1 marca filtros } ##################################################################### config_interior() { # Interface Interna ao domnio config_classes_interior } #####################################################################

D.2 Principal
TC=/sbin/tc INTERFACE=$1 case "$2" in 'externa') config_externa ;; 'interna') config_interna ;; 'interior') config_interior ;; *) echo "Utilizao: $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, Sucia, 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 Servios Diferenciados, Dissertao de Mestrado, Instituto Superior Tcnico, Universidade Tcnica de Lisboa, Julho 2004. [CIIST] Centro de Informtica do Instituto Superior Tcnico, Diagramas de Trfego 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, Finlndia, 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, Maro 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, Systmes bureautiques, Langage standard gneralis 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, Coria, 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, Maro 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, Maro/Abril 2002. [W3CDOM] A. Le Hors, P. Le Hgaret, 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, recomendao ITU-T X.680, Julho 2002.

124

Acrnimos e Abreviaturas
ACL AF ANSI API AQM ASN.1 BA BAR BB BER BE BSI CBQ COPS DEN DiffServ DSCP DTD EF ETSI FIFO GRED HTB IANA IETF IntServ IN IPSec LDAP LDAP LPDP Access Control List Assured Forwarding American National Standard Institute Application Program Interface Active Queue Management Abstract Syntax Notation One Behavior Aggregate Bandwidth Allocation Request Bandwidth Broker Basic Encoding Rule Best-Effort British Standards Institute Class Based Queueing Common Open Policy Service Protocol Directory Enabled Networks Differentiated Services Differentiated Services Codepoint Document Type Definition Expedited Forwarding European Telecommunications Standards Institute First In First Out Generalized Random Early Detection Hierarchical Token Bucket Internet Assigned Numbers Authority Internet Engineering Task Force Integrated Services Interior Node Internet Protocol Security Lightweight Directory Access Protocol Lightweight Directory Access Protocol Local Policy Decision Point 125

COPS-PR COPS Usage for Policy Provisioning

ACRNIMOS E ABREVIATURAS MF MIB MPLS OSPF PBN PDB PDP PEP PHB PIB PIN PMT PPRID PQ PRC PRID PRI qdisc QoS RAA RAR RDN RED RFC RR RSVP RTP RTT SCFQ SFQ SGML SLA SLS SMI SNMP 126 Multiple Field Management Information Base Multiprotocol Label Switching Open Shortest Path First Policy-Based Networking Per Domain Behavior Policy Decision Point Policy Enforcement Point Per-Hop Behavior Policy Information Base Policy-Ignorant Node Policy Management Tool Prefix Provisioning Instance Identifier Priority Queueing Provisioning Class Provisioning Instance Identifier Provisioning Instance Queueing Discipline Quality of Service Resource Allocation Answer Resource Allocation Request Relative Distinguished Name Random Early Detection Request For Comments Round Robin Resource Reservation Protocol Real-Time Protocol Round Trip Time Self-Clocked Fair Queueing Stochastic Fair Queueing Standard Generalized Markup Language Service Level Agreement Service Level Specification Structure of Management Information Simple Network Management Protocol

ACRNIMOS E ABREVIATURAS SPPI SRTCM TB TBF TCA TCB TCS ToS TRTCM WFQ WRR XML Structure of Policy Provisioning Information Single Rate Three Color Marker Token Bucket Token Bucket Filter Traffic Conditioning Agreement Transmission Control Block Traffic Conditioning Specification Type of Service Two Rate Three Color Marker Weighted Fair Queueing Weighted Round Robin Extensible Markup Language

127