Desenvolvimento de Modelos de Simulação para a Análise de Qualidade de Serviço em Redes ATM
Upcoming SlideShare
Loading in...5
×
 

Desenvolvimento de Modelos de Simulação para a Análise de Qualidade de Serviço em Redes ATM

on

  • 2,565 views

Este trabalho propõe o desenvolvimento de um conjunto de modelos de simulação capaz de avaliar com precisão, eficiência e robustez a qualidade de serviço fim-a-fim oferecida para conexões ATM ...

Este trabalho propõe o desenvolvimento de um conjunto de modelos de simulação capaz de avaliar com precisão, eficiência e robustez a qualidade de serviço fim-a-fim oferecida para conexões ATM diante de diferentes cenários de tráfego, de congestionamento e de recursos na rede. Para tanto, o conjunto de modelos desenvolvido deve englobar não apenas as funções de gerenciamento de tráfego ATM e sua complexa interdependência, mas também todas as demais funcionalidades das redes ATM, tais como: o processamento, a comutação e o transporte de células ATM; a negociação do contrato de tráfego; o roteamento e o gerenciamento de conexões virtuais chaveadas. Os resultados obtidos demonstraram que o conjunto de modelos desenvolvido permite avaliar adequadamente a qualidade de serviço fim-a-fim oferecida para conexões ATM diante de diversas situações de tráfego, de congestionamento e de recursos na rede.

Statistics

Views

Total Views
2,565
Views on SlideShare
2,561
Embed Views
4

Actions

Likes
0
Downloads
52
Comments
0

2 Embeds 4

http://antonioalberti.blogspot.com 2
http://www.lmodules.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Desenvolvimento de Modelos de Simulação para a Análise de Qualidade de Serviço em Redes ATM Desenvolvimento de Modelos de Simulação para a Análise de Qualidade de Serviço em Redes ATM Document Transcript

  • UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO DEPARTAMENTO DE COMUNICAÇÕES Desenvolvimento de Modelos de Simulação para a Análise de Qualidade de Serviço em Redes ATM TESE SUBMETIDA À FACULDADE DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO DA UNIVERSIDADE ESTADUAL DE CAMPINAS, DEPARTAMENTO DE COMUNICAÇÕES, COMO PARTE DOS PRÉ-REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO TÍTULO DE DOUTOR EM ENGENHARIA ELÉTRICA. POR ANTÔNIO MARCOS ALBERTI Engenheiro Eletricista pela UFSM em 1996. Mestre em Engenharia Elétrica pela UNICAMP em 1998. ORIENTADOR PROF. DR. LEONARDO DE SOUZA MENDES – DECOM/FEEC/UNICAMP BANCA EXAMINADORA PROF. DR. ANILTON SALLES GARCIA – PPGEE/UFES PROF. DR. DALTON SOARES ARANTES – DECOM/FEEC/UNICAMP PROF. DR. JÔNATAS MANZOLLI – NICS/UNICAMP PROF. DR. MAURÍCIO FERREIRA MAGALHÃES – DCA/FEEC/UNICAMP PROF. DR. NELSON LUIS SALDANHA DA FONSECA – IC/UNICAMP Campinas, 24 de Abril de 2003. Caixa Postal 6101, CEP 13081-970 – Campinas – SP. Telefone: (0xx19) 3788 3703. Fax: (0xx19) 3788 1395.
  • FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA DA ÁREA DE ENGENHARIA - BAE - UNICAMP Alberti, Antônio Marcos AL17d Desenvolvimento de modelos de simulação para a análise de qualidade se serviço em redes ATM / Antônio Marcos Alberti. --Campinas, SP: [s.n.], 2003. Orientador: Leonardo de Souza Mendes. Tese (doutorado) - Universidade Estadual de Campinas, Faculdade de Engenharia Elétrica e de Computação. 1. Simulação (Computadores digitais). 2. Telecomunicações. 3. Sistemas de comunicação em banda larga. 4. Modo de transferência assíncrono. I. Mendes, Leonardo de Souza. II. Universidade Estadual de Campinas. Faculdade de Engenharia Elétrica e de Computação. III. Título. ii
  • Em momentos de dificuldade, somente a imaginação é mais importante do que o conhecimento. Albert Einstein iii
  • Agradecimentos Aos meus pais, Luiz e Leda, pelo apoio, otimismo, carinho e dedicação. À minha esposa, Luzinete, pela compreensão e incentivo. Aos meus irmãos Fernando e Ricardo, pela amizade, compreensão e inspiração. Ao meu orientador, Leonardo de Souza Mendes, pela confiança e amizade. A todos os amigos do LaRCom, DECOM, DT, DMO, DCA, Optiwave, UEL, CT e Incamp, pelos bons momentos de convivência e amizade. A todos que de alguma forma contribuíram com a realização deste trabalho e que me ajudaram a crescer como ser humano. À Fundação de Amparo à Pesquisa do Estado de São Paulo, FAPESP, pelo suporte financeiro que permitiu a realização deste trabalho. iv
  • Resumo Este trabalho propõe o desenvolvimento de um conjunto de modelos de simulação capaz de avaliar com precisão, eficiência e robustez a qualidade de serviço fim-a-fim oferecida para conexões ATM diante de diferentes cenários de tráfego, de congestionamento e de recursos na rede. Para tanto, o conjunto de modelos desenvolvido deve englobar não apenas as funções de gerenciamento de tráfego ATM e sua complexa interdependência, mas também todas as demais funcionalidades das redes ATM, tais como: o processamento, a comutação e o transporte de células ATM; a negociação do contrato de tráfego; o roteamento e o gerenciamento de conexões virtuais chaveadas. Os resultados obtidos demonstraram que o conjunto de modelos desenvolvido permite avaliar adequadamente a qualidade de serviço fim-a-fim oferecida para conexões ATM diante de diversas situações de tráfego, de congestionamento e de recursos na rede. Abstract This work proposes the development of simulation models capable to evaluate with precision, efficiency and robustness the quality of service offered to ATM connections subject to different traffic, congestion and resource scenarios. Therefore, the models developed enclose not only the ATM traffic management functions and their complex interdependence, but also all the other ATM network functionalities, such as the ATM cell processing, switching and transport; the traffic contract negotiation; the routing and management of switched virtual connections. The obtained results had shown that the developed models allow evaluating adequately the end-to-end quality of service for ATM connections subject to several traffic, congestion and resource situations. v
  • Índice CAPÍTULO 1 INTRODUÇÃO ........................................................................................................................................1 1.1 - MOTIVAÇÃO ..........................................................................................................................................................1 1.1.1 - ATM: Qualidade de Serviço Fim-a-Fim......................................................................................................1 1.1.2 - Funções de Gerenciamento de Tráfego ATM..............................................................................................3 1.1.3 - Complexidade e Interdependência entre Funções........................................................................................5 1.2 - OBJETIVOS DO TRABALHO................................................................................................................................7 1.3 - ORGANIZAÇÃO DA TESE....................................................................................................................................7 1.4 - PRINCIPAIS CONTRIBUIÇÕES............................................................................................................................8 1.5 - REFERÊNCIAS BIBLIOGRÁFICAS......................................................................................................................8 CAPÍTULO 2 SIMULAÇÃO DE REDES ATM..........................................................................................................11 2.1 - INTRODUÇÃO ......................................................................................................................................................11 2.2 - SIMULAÇÃO DE SISTEMAS DE COMUNICAÇÕES .......................................................................................11 2.2.1 - Classificação das Ferramentas ...................................................................................................................12 2.2.2 - Principais Características...........................................................................................................................13 2.2.2.1 - Modelamento ...................................................................................................................................................... 13 2.2.2.2 - Gerência de Simulação........................................................................................................................................ 13 2.2.2.3 - Técnicas de Simulação ........................................................................................................................................ 13 2.2.2.3.1 - Simulação Orientada pelo Tempo (Time-Driven Simulation)...................................................................... 14 2.2.2.3.2 - Simulação Orientada por Dados (Data-Driven Simulation) ......................................................................... 14 2.2.2.3.3 - Simulação Orientada por Eventos (Event-Driven Simulation) ..................................................................... 14 2.2.2.4 - Biblioteca de Modelos......................................................................................................................................... 16 2.3 - SIMULAÇÃO DE REDES ATM ...........................................................................................................................16 2.3.1 - Desafios de Desenvolvimento ...................................................................................................................17 2.3.2 - Características Desejáveis .........................................................................................................................18 2.3.3 - Técnicas de Simulação ..............................................................................................................................19 2.3.4 - Estratégias de Modelamento......................................................................................................................20 2.3.4.1 - Modelamento no Nível de Células ...................................................................................................................... 21 2.3.4.2 - Modelamento no Nível de Chamadas.................................................................................................................. 23 2.3.4.3 - Modelamento Fluído ........................................................................................................................................... 23 2.3.4.4 - Modelamento Utilizando Técnicas de Amostragem por Importância ................................................................. 24 2.3.5 - Simulação Paralela ou Distribuída.............................................................................................................26 2.3.6 - Ferramentas de Simulação de Redes ATM................................................................................................27 2.3.6.1 - Comparação entre as Ferramentas....................................................................................................................... 29 2.4 - REFERÊNCIAS BIBLIOGRÁFICAS....................................................................................................................30 vi
  • CAPÍTULO 3 AMBIENTE DE SIMULAÇÃO............................................................................................................35 3.1 - INTRODUÇÃO ......................................................................................................................................................35 3.2 - ESTRUTURA.........................................................................................................................................................36 3.2.1 - Programa Executável .................................................................................................................................37 3.2.2 - Biblioteca de Modelos ...............................................................................................................................38 3.3 - REFERÊNCIAS BIBLIOGRÁFICAS....................................................................................................................40 CAPÍTULO 4 CONJUNTO DE MODELOS NO NÍVEL DE CÉLULAS (CMNC).................................................43 4.1 - INTRODUÇÃO ......................................................................................................................................................43 4.2 - ESTRUTURA.........................................................................................................................................................44 4.3 - MENSAGENS ........................................................................................................................................................46 4.3.1 - Pacote ........................................................................................................................................................47 4.3.2 - Célula ATM...............................................................................................................................................49 4.3.3 - Contrato de Tráfego...................................................................................................................................50 4.3.4 - Ficha ..........................................................................................................................................................51 4.3.5 - Mensagem de Gerenciamento de Tráfego .................................................................................................52 4.3.6 - Mensagem de Roteamento.........................................................................................................................53 4.4 - ESTRUTURAS DE DADOS AUXILIARES.........................................................................................................54 4.4.1 - Variável Estatística Simples ......................................................................................................................54 4.4.2 - Variável Estatística Média.........................................................................................................................54 4.4.3 - Arquivo......................................................................................................................................................55 4.5 - OBJETOS AUXILIARES ......................................................................................................................................55 4.5.1 - Gerente de Entrada e Saída........................................................................................................................55 4.5.1.1 - Gerenciamento de Arquivos................................................................................................................................ 56 4.5.1.2 - Gerenciamento de Amostragens Estatísticas ....................................................................................................... 57 4.5.2 - Gerente de Alocação Dinâmica .................................................................................................................59 4.6 - CAMADAS ............................................................................................................................................................59 4.6.1 - Camadas Requerentes e Removedoras de Conexões.................................................................................60 4.6.1.1 - Amostragens Estatísticas..................................................................................................................................... 62 4.6.2 - Camadas Finalizadoras de Conexões.........................................................................................................62 4.6.2.1 - Amostragens Estatísticas..................................................................................................................................... 62 4.6.3 - Camadas Fontes de Tráfego.......................................................................................................................62 4.6.3.1 - Amostragens Estatísticas..................................................................................................................................... 63 4.6.3.2 - Camada Fonte de Tráfego Determinístico........................................................................................................... 63 4.6.3.3 - Camada Fonte de Tráfego Poissoniano ............................................................................................................... 64 4.6.3.4 - Camada Fonte de Tráfego Externo...................................................................................................................... 64 4.6.4 - Camadas Receptoras de Tráfego ...............................................................................................................65 4.6.4.1 - Amostragens Estatísticas..................................................................................................................................... 65 vii
  • 4.6.5 - Camadas de Adaptação ATM....................................................................................................................65 4.6.5.1 - Camada de Adaptação ATM Tipo 5.................................................................................................................... 65 4.6.5.1.1 - Amostragens Estatísticas .............................................................................................................................. 65 4.6.6 - Camadas ATM...........................................................................................................................................66 4.6.6.1 - Camada ATM do BTE ........................................................................................................................................ 66 4.6.6.1.1 - Amostragens Estatísticas .............................................................................................................................. 66 4.6.6.2 - Camada ATM do Comutador.............................................................................................................................. 66 4.6.6.2.1 - Amostragens Estatísticas .............................................................................................................................. 69 4.6.7 - Camadas Físicas ........................................................................................................................................69 4.6.7.1 - Camada Física de Entrada ................................................................................................................................... 70 4.6.7.1.1 - Amostragens Estatísticas .............................................................................................................................. 71 4.6.7.2 - Camada Física de Saída....................................................................................................................................... 71 4.6.7.2.1 - Amostragens Estatísticas .............................................................................................................................. 73 4.7 - GERENCIADORES DE TRÁFEGO......................................................................................................................73 4.7.1 - Estruturas de Filas (Queueing Structures) .................................................................................................74 4.7.1.1 - Estrutura de Filas Default.................................................................................................................................... 74 4.7.1.1.1 - Amostragens Estatísticas .............................................................................................................................. 75 4.7.1.2 - Estrutura de Filas com Fila por Conexão ............................................................................................................ 75 4.7.1.2.1 - Amostragens Estatísticas .............................................................................................................................. 76 4.7.2 - Escalonadores (Schedulers) .......................................................................................................................76 4.7.2.1 - Escalonador Default ............................................................................................................................................ 78 4.7.2.1.1 - Amostragens Estatísticas .............................................................................................................................. 78 4.7.2.2 - Escalonador de Pacotes com Compartilhamento de Processador Generalizado.................................................. 78 4.7.2.2.1 - Amostragens Estatísticas .............................................................................................................................. 79 4.7.2.3 - Escalonador Regulador de Tráfego Virtual Scheduling ...................................................................................... 80 4.7.2.3.1 - Amostragens Estatísticas .............................................................................................................................. 84 4.7.2.4 - Escalonador WF2Q ............................................................................................................................................. 85 ALGORITMO DE ARMAZENAMENTO DE CÉLULAS ATM .............................................................................................................................. 87 ALGORITMO DE SERVIÇO DE CÉLULAS ATM ................................................................................................................................................. 89 4.7.2.4.1 - Amostragens Estatísticas .............................................................................................................................. 91 4.7.2.5 - Escalonador LFVC.............................................................................................................................................. 92 4.7.2.5.1 - Amostragens Estatísticas.................................................................................................................................. 97 4.7.3 - Algoritmos de Controle de Admissão de Conexões ..................................................................................98 4.7.3.1 - Algoritmo de Controle de Admissão de Conexões Default................................................................................. 98 4.7.3.1.1 - Amostragens Estatísticas .............................................................................................................................. 99 4.7.3.2 - Algoritmo de Controle de Admissão de Conexões Elwalid Mitra....................................................................... 99 4.7.3.2.1 - Amostragens Estatísticas ............................................................................................................................ 103 4.7.4 - Algoritmos de Gerenciamento de Estrutura de Filas ...............................................................................104 4.7.4.1 - Algoritmo de Gerenciamento de Estrutura de Filas Default.............................................................................. 105 viii
  • 4.7.4.1.1 – Amostragens Estatísticas ........................................................................................................................... 105 4.7.4.2 - Algoritmo de Gerenciamento de Estrutura de Filas com Particionamento Dinâmico ....................................... 105 4.7.4.2.1 - Amostragens Estatísticas ............................................................................................................................ 107 4.7.5 - Algoritmos de Descarte Seletivo de Células............................................................................................107 4.7.5.1 - Algoritmo de Descarte Seletivo de Células Default .......................................................................................... 108 4.7.5.1.1 - Amostragens Estatísticas ............................................................................................................................ 108 4.7.5.2 - Algoritmo de Descarte Seletivo de Células Baseado no CLP ........................................................................... 108 4.7.5.2.1 - Amostragens Estatísticas ............................................................................................................................ 109 4.7.5.3 - Algoritmo de Descarte Seletivo de Células Baseado no CLR ........................................................................... 109 4.7.5.3.1 - Amostragens Estatísticas ............................................................................................................................ 109 4.7.6 - Algoritmos de Policiamento de Tráfego ..................................................................................................109 4.7.6.1 - Policiador Leaky Bucket ................................................................................................................................... 110 4.7.6.1.1 - Amostragens Estatísticas ............................................................................................................................ 115 4.8 - BLOCOS...............................................................................................................................................................115 4.8.1 - Aplicativos...............................................................................................................................................116 4.8.1.1 - Aplicativo Determinístico ................................................................................................................................. 116 4.8.1.2 - Aplicativo Poissoniano...................................................................................................................................... 116 4.8.1.3 - Aplicativo Externo ............................................................................................................................................ 117 4.8.1.4 - Aplicativo Receptor .......................................................................................................................................... 117 4.8.2 - Equipamentos ..........................................................................................................................................117 4.8.2.1 - Terminal Faixa Larga ........................................................................................................................................ 118 4.8.2.2 - Comutador......................................................................................................................................................... 118 4.8.3 - Gerente ....................................................................................................................................................119 4.8.3.1 - Gerente.............................................................................................................................................................. 119 4.9 - FUNCIONAMENTO............................................................................................................................................120 4.10 - ALOCAÇÃO DINÂMICA DE MODELOS INTERNOS..................................................................................124 4.11 - NOMENCLATURA DOS MODELOS..............................................................................................................126 4.12 - REFERÊNCIAS BIBLIOGRÁFICAS................................................................................................................127 CAPÍTULO 5 ESPECIFICAÇÃO DE SIMULAÇÕES ............................................................................................129 5.1 - INTRODUÇÃO ....................................................................................................................................................129 5.2 - IDENTIFICAÇÃO DE CENÁRIOS ....................................................................................................................129 5.2.1 - MPEG sobre ATM...................................................................................................................................129 5.2.2 - Internet sobre ATM .................................................................................................................................131 5.2.3 - Multimídia em Tempo Real sobre ATM .................................................................................................132 5.3 - OBTENÇÃO DE SEQÜÊNCIAS DE TRÁFEGO ...............................................................................................133 5.4 - ADAPTAÇÃO DE SEQÜÊNCIAS DE TRÁFEGO ............................................................................................133 5.4.1 - Adaptação de Seqüências de Tamanho de Frame MPEG para Seqüências de Fluxo de Transporte MPEG134 5.5 - CONFIGURAÇÃO DE CONTRATOS DE TRÁFEGO ......................................................................................140 ix
  • 5.5.1 - Escolha da Categoria de Serviço .............................................................................................................143 5.5.2 - Definição dos Parâmetros de QoS ...........................................................................................................143 5.5.3 - Definição dos Descritores de Tráfego .....................................................................................................143 5.5.3.1 - Estimação de Descritores para Tráfego VBR: Técnica do Buffer Virtual......................................................... 144 5.5.3.1.1 - Implementação do VB................................................................................................................................ 146 5.5.3.1.2 - Estimativa de um Par (PCR, CDVT) .......................................................................................................... 147 5.5.3.1.3 - Estimativa de um Conjunto de Pares (SCR, MBS)..................................................................................... 149 5.5.3.1.4 - Resultados .................................................................................................................................................. 151 5.5.4 - Escolha da Definição de Conformidade ..................................................................................................156 5.6 - REFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................................156 CAPÍTULO 6 SIMULAÇÕES.....................................................................................................................................159 6.1 - INTRODUÇÃO ....................................................................................................................................................159 6.2 - SIMULAÇÃO 1: VALIDAÇÃO DO ESCALONADOR WF2Q.........................................................................159 6.2.1 - Configuração da Rede no Simulador .......................................................................................................159 6.2.2 - Definição das Simulações........................................................................................................................160 6.2.3 - Configuração dos Modelos ......................................................................................................................161 6.2.4 - Resultados................................................................................................................................................163 6.2.5 - Validação do Modelo WF2Q_Scheduler .................................................................................................163 6.2.6 - Amostragem por Eventos ........................................................................................................................165 6.2.7 - Amostragem por Tempo ..........................................................................................................................177 6.3 - SIMULAÇÃO 2: ANÁLISE DA QOS EM SVCS ATM .....................................................................................182 6.3.1 - Configuração da Rede no Simulador .......................................................................................................183 6.3.2 - Definição das Simulações........................................................................................................................184 6.3.3 - Configuração dos Modelos ......................................................................................................................184 6.3.4 - Resultados................................................................................................................................................185 6.4 - SIMULAÇÃO 3: CENÁRIO NVOD MPEG-4 SOBRE ATM.............................................................................188 6.4.1 - Configuração do Cenário no Simulador ..................................................................................................188 6.4.2 - Definição das Simulações........................................................................................................................191 6.4.3 - Configuração dos Modelos ......................................................................................................................193 6.4.3.1 - Aplicativos ........................................................................................................................................................ 193 6.4.3.2 - Terminais Faixa Larga ...................................................................................................................................... 194 6.4.3.3 - Chaveador ......................................................................................................................................................... 195 6.4.4 - Resultados................................................................................................................................................195 6.4.4.1 - Ocupação Média por Conexão .......................................................................................................................... 197 CAPACIDADE DE 1000 CÉLULAS (B=0)............................................................................................................................................................ 198 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................198 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................199 x
  • CAPACIDADE DE 500 CÉLULAS (B=1).............................................................................................................................................................. 202 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................202 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................204 CAPACIDADE DE 100 CÉLULAS (B=2).............................................................................................................................................................. 206 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................206 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................208 CAPACIDADE DE 50 CÉLULAS (B=3)................................................................................................................................................................ 210 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................210 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................212 6.4.4.2 - Atraso Médio por Conexão ............................................................................................................................... 214 CAPACIDADE DE 1000 CÉLULAS (B=0)............................................................................................................................................................ 215 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................215 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................217 CAPACIDADE DE 500 CÉLULAS (B=1).............................................................................................................................................................. 219 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................219 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................221 CAPACIDADE DE 100 CÉLULAS (B=2).............................................................................................................................................................. 223 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................223 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................225 CAPACIDADE DE 50 CÉLULAS (B=3)................................................................................................................................................................ 227 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................227 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................229 6.4.4.3 - CLR Médio por Conexão .................................................................................................................................. 231 CAPACIDADE DE 1000 CÉLULAS (B=0)............................................................................................................................................................ 233 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................233 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................235 CAPACIDADE DE 500 CÉLULAS (B=1).............................................................................................................................................................. 237 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................237 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................239 CAPACIDADE DE 100 CÉLULAS (B=2).............................................................................................................................................................. 241 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................241 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................243 CAPACIDADE DE 50 CÉLULAS (B=3)................................................................................................................................................................ 245 Modelo de CAC, BM e SD Default (V=0) ..............................................................................................................................245 Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) .....................................247 6.5 - REFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................................249 CAPÍTULO 7 CONCLUSÃO ......................................................................................................................................251 xi
  • 7.1 - SUMÁRIO DAS ATIVIDADES E CONCLUSÕES ...........................................................................................251 7.2 - PRINCIPAIS CONTRIBUIÇÕES........................................................................................................................258 7.3 - SUGESTÕES DE TRABALHOS FUTUROS......................................................................................................260 7.4 - PUBLICAÇÕES ...................................................................................................................................................260 7.5 - REFERÊNCIAS BIBLIOGRÁFICAS..................................................................................................................262 APÊNDICE A DESCRIÇÃO DETALHADA DO AMBIENTE DE SIMULAÇÃO ...............................................263 A.1 - PROGRAMA EXECUTÁVEL............................................................................................................................263 A.1.1 - Kernel .....................................................................................................................................................263 A.1.2 - Conexões ................................................................................................................................................275 A.1.3 - Parâmetros ..............................................................................................................................................277 A.1.4 - Tabela de Dados .....................................................................................................................................278 A.1.5 - Eventos ...................................................................................................................................................278 A.1.6 - Mensagens ..............................................................................................................................................279 A.2 - BIBLIOTECA DE MODELOS ...........................................................................................................................280 A.2.1 - Blocos .....................................................................................................................................................280 A.2.2 - Camadas..................................................................................................................................................287 A.2.3 - Gerenciadores de Tráfego.......................................................................................................................290 A.3 - REFERÊNCIAS BIBLIOGRÁFICAS.................................................................................................................291 xii
  • Índice de Figuras FIGURA 2.1 – ESQUEMA DE ARMAZENAMENTO E EXECUÇÃO DE EVENTOS. .....................................................................15 FIGURA 3.1 – ESTRUTURA DO HYDRAGYRUM. ................................................................................................................37 FIGURA 3.2 – PROGRAMA EXECUTÁVEL COM INTERFACE EM MODO CARACTERE. ...........................................................37 FIGURA 3.3 – PROGRAMA EXECUTÁVEL COM INTERFACE GRÁFICA. ................................................................................38 FIGURA 3.4 – ESTRUTURA HIERÁRQUICA DE MODELOS NO HYDRAGYRUM......................................................................39 FIGURA 4.1 – ESTRUTURA DO CONJUNTO DE MODELOS NO NÍVEL DE CÉLULAS. ..............................................................45 FIGURA 4.2 – HIERARQUIA DE OBJETOS UTILIZADA PARA MODELAR A FASE DE TRANSMISSÃO DE DADOS NA REDE ATM........................................................................................................................................................47 FIGURA 4.3 – ESTRUTURA DO PACOTE.............................................................................................................................48 FIGURA 4.4 – ESTRUTURA DA CÉLULA ATM. ..................................................................................................................49 FIGURA 4.5 – ESTRUTURA DO CONTRATO DE TRÁFEGO. ..................................................................................................51 FIGURA 4.6 – ESTRUTURA DAS FICHAS. ...........................................................................................................................51 FIGURA 4.7 – ESTRUTURA DAS MENSAGENS DE GERENCIAMENTO DE TRÁFEGO. .............................................................52 FIGURA 4.8 – ESTRUTURA DAS MENSAGENS DE ROTEAMENTO. .......................................................................................53 FIGURA 4.9 – ESTRUTURA DAS VARIÁVEIS ESTATÍSTICA SIMPLES. ..................................................................................54 FIGURA 4.10 – ESTRUTURA DAS VARIÁVEIS ESTATÍSTICA MÉDIAS. .................................................................................55 FIGURA 4.11 – ESTRUTURA DOS ARQUIVOS. ....................................................................................................................55 FIGURA 4.12 – EXEMPLO DE ARQUIVO DE SAÍDA. ............................................................................................................57 FIGURA 4.13 – EXEMPLO DE UM PARÂMETRO MATRICIAL PARA A SELEÇÃO DAS VARIÁVEIS ESTATÍSTICAS QUE FARÃO PARTE DE UMA AMOSTRAGEM..................................................................................................................58 FIGURA 4.14 – PERÍODOS ATIVOS E INATIVOS DAS CONEXÕES CRIADAS PELAS CAMADAS REQUERENTES E REMOVEDORAS DE CONEXÕES..................................................................................................................61 FIGURA 4.15 – PADRÃO DE TRÁFEGO GERADO PELA CAMADA FONTE DE TRÁFEGO DETERMINÍSTICO PARA DUAS SITUAÇÕES: A) CONEXÕES COM DURAÇÕES DETERMINÍSTICAS. B) CONEXÕES COM DURAÇÕES EXPONENCIAIS NEGATIVAS.......................................................................................................................64 xiii
  • FIGURA 4.16 – PADRÃO DE TRÁFEGO GERADO PELA CAMADA FONTE DE TRÁFEGO POISSONIANO PARA DUAS SITUAÇÕES: A) CONEXÕES COM DURAÇÕES DETERMINÍSTICAS. B) CONEXÕES COM DURAÇÕES EXPONENCIAIS NEGATIVAS.......................................................................................................................64 FIGURA 4.17 – ESTRUTURA DA SWITCH FABRIC MODELADA NO CONJUNTO DE MODELOS NO NÍVEL DE CÉLULAS............67 FIGURA 4.18 – ITERAÇÃO ENTRE A CAMADA SW_ATM E OS DEMAIS GERENCIADORES DE TRÁFEGO DO BLOCO COMUTADOR. ...........................................................................................................................................68 FIGURA 4.19 – ITERAÇÃO ENTRE A CAMADA PHY_IN E OS DEMAIS GERENCIADORES DE TRÁFEGO DO BLOCO COMUTADOR. ...........................................................................................................................................71 FIGURA 4.20 – ITERAÇÃO ENTRE A CAMADA PHY_OUT E OS DEMAIS GERENCIADORES DE TRÁFEGO DOS BLOCOS COMUTADOR E BTE. ................................................................................................................................72 FIGURA 4.21 – ESTRUTURA DO GERENCIADOR DE TRÁFEGO DEFAULT_QUEUEING_STRUCTURE. ...................................75 FIGURA 4.22 – ESTRUTURA DO GERENCIADOR DE TRÁFEGO PER_VC_QUEUEING_STRUCTURE. ....................................76 FIGURA 4.23 – ESTRUTURA DO ESCALONADOR VS_TS_SCHEDULER. .............................................................................80 FIGURA 4.24 – ALGORITMOS IMPLEMENTADOS PARA OS ESPAÇADORES: A) A (CBR.1, ABR.1 E UBR.1) E B) B (VBR.1)...................................................................................................................................................82 FIGURA 4.25 – ALGORITMOS IMPLEMENTADOS PARA OS ESPAÇADORES: A) C (VBR.2) E B) D (VBR.3)........................84 FIGURA 4.26 – ESTRUTURA DO MODELO DO ESCALONADOR WF2Q. ...............................................................................87 FIGURA 4.27 – ALGORITMO DE ARMAZENAMENTO DE CÉLULAS ATM. ...........................................................................89 FIGURA 4.28 – ALGORITMO DE SERVIÇO DE CÉLULAS ATM............................................................................................91 FIGURA 4.29 – ESTRUTURA DO LFVC_SCHEDULER........................................................................................................92 FIGURA 4.30 – ALGORITMO IMPLEMENTADO PARA O ARMAZENAMENTO DE CÉLULAS NO LFVC_SCHEDULER...............95 FIGURA 4.31 – ALGORITMO IMPLEMENTADO PARA A TRANSMISSÃO DE CÉLULAS NO LFVC_SCHEDULER......................96 FIGURA 4.32 – ALGORITMO DE SERVIÇO DA CÉLULA DA CABECEIRA DA FILA H..............................................................97 FIGURA 4.33 – FLUXOGRAMA DO CRITÉRIO DE ACEITAÇÃO DE CONEXÕES DO ELWALID_MITRA_CAC. ......................101 FIGURA 4.34 – DINÂMICA DO LIMIAR DE ACEITAÇÃO DE CÉLULAS PARA: A) CLASSE COM MULTIPLEXAÇÃO SEM PERDAS E B) CLASSE COM MULTIPLEXAÇÃO ESTATÍSTICA. .....................................................................106 FIGURA 4.35 – ESTRUTURA DO LEAKY_BUCKET_TP. ...................................................................................................111 FIGURA 4.36 – ALGORITMOS IMPLEMENTADOS PARA OS POLICIADORES: A) A (CBR.1, ABR.1 E UBR.1) E B) B (VBR.1).................................................................................................................................................112 xiv
  • FIGURA 4.37 – ALGORITMO IMPLEMENTADO PARA O POLICIADOR C (VBR.2). .............................................................114 FIGURA 4.38 – ALGORITMO IMPLEMENTADO PARA O POLICIADOR D (VBR.3)..............................................................115 FIGURA 4.39 – ESTRUTURA DO APLICATIVO DETERMINÍSTICO.......................................................................................116 FIGURA 4.40 – ESTRUTURA DO APLICATIVO POISSONIANO. ...........................................................................................116 FIGURA 4.41 – ESTRUTURA DO APLICATIVO EXTERNO. .................................................................................................117 FIGURA 4.42 – ESTRUTURA DO APLICATIVO RECEPTOR. ................................................................................................117 FIGURA 4.43 – ESTRUTURA DO BTE..............................................................................................................................118 FIGURA 4.44 – ESTRUTURA DO COMUTADOR.................................................................................................................119 FIGURA 4.45 – EXEMPLO DE UMA REDE ATM SIMPLES. ................................................................................................123 FIGURA 4.46 – ESTRUTURA INTERNA DOS BLOCOS DA REDE ATM SIMPLES. .................................................................124 FIGURA 4.47 – ALOCAÇÃO DINÂMICA DE CAMADAS E DE GERENCIADORES DE TRÁFEGO NO CMNC. ...........................125 FIGURA 4.48 – NOMENCLATURA DOS MODELOS INTERNOS DO BLOCO COMUTADOR. ....................................................126 FIGURA 5.1 – CENÁRIO NVOD MPEG SOBRE ATM NATIVO........................................................................................130 FIGURA 5.2 – CENÁRIOS INTERNET SOBRE ATM...........................................................................................................131 FIGURA 5.3 –CENÁRIO MULTIMÍDIA EM TEMPO REAL SOBRE ATM..............................................................................132 FIGURA 5.4 – SEGMENTAÇÃO DE FRAMES MPEG EM CÉLULAS ATM: A) SOLUÇÃO COMUMENTE UTILIZADA E B) SOLUÇÃO ADOTADA PELO PROGRAMA DE ADAPTAÇÃO. .........................................................................136 FIGURA 5.5 – ALGORITMO PARA A ADAPTAÇÃO DAS SEQÜÊNCIAS DE FRAMES MPEG EM PACOTES TS MPEG............138 FIGURA 5.6 – SEQÜÊNCIA DE TAMANHO DE FRAME MPEG. ..........................................................................................140 FIGURA 5.7 – SEQÜÊNCIA DE FLUXO DE TRANSPORTE MPEG DE SAÍDA........................................................................140 FIGURA 5.8 – EQUIVALÊNCIA ENTRE: A) BUFFER VIRTUAL E B) POLICIADOR. ..............................................................145 FIGURA 5.9 – ESTIMATIVA DE UM PAR (PCR, CDVT) – PARTE I. .................................................................................150 FIGURA 5.10 – ESTIMATIVA DE UM PAR (PCR, CDVT) – PARTE II. ..............................................................................151 FIGURA 5.11 – SEQÜÊNCIA DE FRAMES MPEG DE ENTRADA. .......................................................................................152 FIGURA 5.12 – SEQÜÊNCIA DE AAL-SDUS RESULTANTE DA ADAPTAÇÃO DOS FRAMES MPEG....................................152 FIGURA 5.13 – OCUPAÇÃO DO BUFFER VIRTUAL DURANTE AS VARIAS ITERAÇÕES DO ALGORITMO DE ESTIMAÇÃO DO PCR E DO CDVT. ..................................................................................................................................153 xv
  • FIGURA 5.14 – OCUPAÇÃO DO BUFFER VIRTUAL DURANTE AS ÚLTIMAS 3 ITERAÇÕES DO ALGORITMO DE ESTIMAÇÃO DO PCR E DO CDVT..............................................................................................................................154 FIGURA 5.15 – CONVERGÊNCIA DO ALGORITMO DE ESTIMAÇÃO DO PCR E DO CDVT..................................................154 FIGURA 5.16 – SCR VERSUS MBS E BT........................................................................................................................156 FIGURA 6.1 – TOPOLOGIA DA REDE UTILIZADA PARA VALIDAR O MODELO WF2Q_SCHEDULER...................................160 FIGURA 6.2 – OCUPAÇÃO DA ESTRUTURA DE FILAS DO BTE_0 PARA O MODELO DE ESCALONADOR WF2Q. ................164 FIGURA 6.3 – OCUPAÇÃO DAS FILAS DE CADA CONEXÃO NA ESTRUTURA DE FILAS DO BTE_0 SUJEITA A CAPACIDADE DE 100 CÉLULAS PARA AMBOS OS MODELOS DE ESCALONADORES.........................................................166 FIGURA 6.4 – OCUPAÇÃO DAS FILAS DE CADA CONEXÃO NA ESTRUTURA DE FILAS DO BTE_0 SUJEITA A CAPACIDADE DE 50 CÉLULAS PARA AMBOS OS MODELOS DE ESCALONADORES...........................................................167 FIGURA 6.5 –ATRASO INSTANTÂNEO DAS CÉLULAS NA ESTRUTURA DE FILAS DO BTE_0 COM CAPACIDADE DE 100 CÉLULAS PARA AMBOS OS MODELOS DE ESCALONADORES.....................................................................169 FIGURA 6.6 – ATRASO INSTANTÂNEO DAS CÉLULAS NA ESTRUTURA DE FILAS DO BTE_0 COM CAPACIDADE DE 50 CÉLULAS PARA AMBOS OS MODELOS DE ESCALONADORES.....................................................................170 FIGURA 6.7 – ATRASO MÉDIO DAS CÉLULAS NA ESTRUTURA DE FILAS DO BTE_0 COM CAPACIDADE DE 100 CÉLULAS PARA AMBOS OS MODELOS DE ESCALONADORES....................................................................................171 FIGURA 6.8 – ATRASO MÉDIO DAS CÉLULAS NA ESTRUTURA DE FILAS DO BTE_0 COM CAPACIDADE DE 50 CÉLULAS PARA AMBOS OS MODELOS DE ESCALONADORES....................................................................................172 FIGURA 6.9 – NÚMERO DE CÉLULAS PERDIDAS NA ESTRUTURA DE FILAS DO BTE_0 COM CAPACIDADE DE 100 CÉLULAS PARA AMBOS OS MODELOS DE ESCALONADORES.....................................................................174 FIGURA 6.10 – NÚMERO DE CÉLULAS PERDIDAS NA ESTRUTURA DE FILAS DO BTE_0 COM CAPACIDADE DE 50 CÉLULAS PARA AMBOS OS MODELOS DE ESCALONADORES.....................................................................175 FIGURA 6.11 – CLR NA ESTRUTURA DE FILAS DO BTE_0 COM CAPACIDADE DE 100 CÉLULAS PARA AMBOS OS MODELOS DE ESCALONADORES. .............................................................................................................176 FIGURA 6.12 – CLR NA ESTRUTURA DE FILAS DO BTE_0 COM CAPACIDADE DE 50 CÉLULAS PARA AMBOS OS MODELOS DE ESCALONADORES. .............................................................................................................177 FIGURA 6.13 – OCUPAÇÃO MÉDIA NA ESTRUTURA DE FILAS DO BTE_0 PARA OS DOIS MODELOS DE ESCALONADORES.178 FIGURA 6.14 – ATRASO MÉDIO NA ESTRUTURA DE FILAS DO BTE_0 PARA OS DOIS MODELOS DE ESCALONADORES. ....179 FIGURA 6.15 – CLR MÉDIO NA ESTRUTURA DE FILAS DO BTE_0 PARA OS DOIS MODELOS DE ESCALONADORES. .........181 FIGURA 6.16 – UTILIZAÇÃO MÉDIA DOS ESCALONADORES. ...........................................................................................182 xvi
  • FIGURA 6.17 – TOPOLOGIA DA UTILIZADA PARA AVALIAR A QOS DE SVCS ATM........................................................183 FIGURA 6.18 – OCUPAÇÃO MÉDIA DA ESTRUTURA DE FILAS DO BTE_0. .......................................................................186 FIGURA 6.19 – ATRASO MÉDIO DAS CÉLULAS NA ESTRUTURA DE FILAS DO BTE_0.......................................................187 FIGURA 6.20 – TAXA MÉDIA DE PERDA DE CÉLULAS NA ESTRUTURA DE FILAS DO BTE_0. ...........................................187 FIGURA 6.21 – ATRASO MÉDIO FIM-A-FIM DAS CÉLULAS NA REDE. ...............................................................................187 FIGURA 6.22 – CENÁRIO VÍDEO SOBRE DEMANDA MPEG-4 SOBRE ATM NATIVO. .......................................................188 FIGURA 6.23 – CENÁRIO NVOD MPEG-4 SOBRE ATM UTILIZANDO O CONJUNTO DE MODELOS NO NÍVEL DE CÉLULAS................................................................................................................................................189 FIGURA 6.24 – VISÃO DETALHADA DO CENÁRIO NVOD MPEG-4 SOBRE ATM UTILIZANDO O CMNC........................189 FIGURA 6.25 – EXEMPLO DE FIGURA DE RESULTADOS PARA A CONFIGURAÇÃO DE SIMULAÇÃO (U)(3)(1)(Z). ..............196 FIGURA 6.26 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(0)(Z)...........................................................................................................................................198 FIGURA 6.27 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(0)(Z)...........................................................................................................................................199 FIGURA 6.28 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(1)(Z)...........................................................................................................................................200 FIGURA 6.29 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(1)(Z)...........................................................................................................................................201 FIGURA 6.30 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(0)(Z)...........................................................................................................................................202 FIGURA 6.31 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(0)(Z)...........................................................................................................................................203 FIGURA 6.32 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(1)(Z)...........................................................................................................................................204 FIGURA 6.33 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(1)(Z)...........................................................................................................................................205 FIGURA 6.34 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(0)(Z)...........................................................................................................................................206 FIGURA 6.35 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(0)(Z)...........................................................................................................................................207 xvii
  • FIGURA 6.36 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(1)(Z)...........................................................................................................................................208 FIGURA 6.37 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(1)(Z)...........................................................................................................................................209 FIGURA 6.38 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(0)(Z)...........................................................................................................................................210 FIGURA 6.39 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(0)(Z)...........................................................................................................................................211 FIGURA 6.40 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(1)(Z)...........................................................................................................................................212 FIGURA 6.41 – OCUPAÇÃO DA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(1)(Z)...........................................................................................................................................213 FIGURA 6.42 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(0)(Z)...........................................................................................................................................215 FIGURA 6.43 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(0)(Z)...........................................................................................................................................216 FIGURA 6.44 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(1)(Z)...........................................................................................................................................217 FIGURA 6.45 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(1)(Z)...........................................................................................................................................218 FIGURA 6.46 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(0)(Z)...........................................................................................................................................219 FIGURA 6.47 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(0)(Z)...........................................................................................................................................220 FIGURA 6.48 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(1)(Z)...........................................................................................................................................221 FIGURA 6.49 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(1)(Z)...........................................................................................................................................222 FIGURA 6.50 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(0)(Z)...........................................................................................................................................223 FIGURA 6.51 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(0)(Z)...........................................................................................................................................224 xviii
  • FIGURA 6.52 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(1)(Z)...........................................................................................................................................225 FIGURA 6.53 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(1)(Z)...........................................................................................................................................226 FIGURA 6.54 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(0)(Z)...........................................................................................................................................227 FIGURA 6.55 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(0)(Z)...........................................................................................................................................228 FIGURA 6.56 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(1)(Z)...........................................................................................................................................229 FIGURA 6.57 – ATRASO NA ESTRUTURA DE FILAS PHY_OUT_QS_0 DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(1)(Z)...........................................................................................................................................230 FIGURA 6.58 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(0)(Z)........................233 FIGURA 6.59 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(0)(Z)........................234 FIGURA 6.60 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(1)(Z)........................235 FIGURA 6.61 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(0)(1)(Z)........................236 FIGURA 6.62 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(0)(Z)........................237 FIGURA 6.63 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(0)(Z)........................238 FIGURA 6.64 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(1)(Z)........................239 FIGURA 6.65 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(1)(1)(Z)........................240 FIGURA 6.66 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(0)(Z)........................241 FIGURA 6.67 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(0)(Z)........................242 FIGURA 6.68 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(1)(Z)........................243 FIGURA 6.69 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(2)(1)(Z)........................244 FIGURA 6.70 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(0)(Z)........................245 FIGURA 6.71 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(0)(Z)........................246 FIGURA 6.72 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(1)(Z)........................247 FIGURA 6.73 – CLR NA CAMADA FÍSICA DE SAÍDA DO BTE_0 PARA AS CONFIGURAÇÕES (U)(3)(1)(Z)........................248 FIGURA A.1 – ESTRUTURA DO KERNEL DO HYDRAGYRUM............................................................................................264 xix
  • FIGURA A.2 – FLUXOGRAMAS DE FUNCIONAMENTO DO KERNEL...................................................................................266 FIGURA A.3 – RELAÇÃO ENTRE AS FUNÇÕES DE INTERFACEAMENTO DO KERNEL E AS FUNÇÕES DE COMPORTAMENTO DOS MODELOS. .......................................................................................................................................268 FIGURA A.4 – FLUXOGRAMA DA FUNÇÃO DE EXECUÇÃO DA SIMULAÇÃO (RUN). ..........................................................270 FIGURA A.5 – FASES NECESSÁRIAS PARA A SIMULAÇÃO DE UMA REDE NO HYDRAGYRUM. ..........................................273 FIGURA A.6 – ESTRUTURA DE CLASSES DO KERNEL DO HYDRAGYRUM [3]. ..................................................................274 FIGURA A.7 – ESTRUTURA HIERÁRQUICA DE CONEXÕES DO HYDRAGYRUM. ................................................................276 FIGURA A.8 – REMOÇÃO DE CONEXÕES NO HYDRAGYRUM...........................................................................................276 FIGURA A.9 – EXEMPLO DE TOPOLOGIA PARA REDES ATM. .........................................................................................277 FIGURA A.10 – ESTRUTURA DOS PARÂMETROS DO HYDRAGYRUM. ..............................................................................278 FIGURA A.11 – ESTRUTURA DOS EVENTOS DO HYDRAGYRUM. .....................................................................................279 FIGURA A.12 – ESTRUTURA DE UM BLOCO DO HYDRAGYRUM. .....................................................................................280 FIGURA A.13 – CONSTRUÇÃO DE NOVOS BLOCOS NO HYDRAGYRUM............................................................................285 FIGURA A.14 – PASSOS NECESSÁRIOS PARA DESENVOLVER UM NOVO BLOCO PARA O HYDRAGYRUM. .........................286 FIGURA A.15 – ESTRUTURA DE UMA CAMADA DO HYDRAGYRUM. ...............................................................................287 FIGURA A.16 – CONSTRUÇÃO DE NOVAS CAMADAS NO HYDRAGYRUM. .......................................................................290 FIGURA A.17 – ESTRUTURA DE UM GERENCIADOR DE TRÁFEGO DO HYDRAGYRUM......................................................291 xx
  • Índice de Tabelas TABELA 2.1 – CARACTERÍSTICAS DE ALGUMAS FERRAMENTAS DE SIMULAÇÃO DE REDES ATM. ...................................30 TABELA 4.1 – MAPEAMENTO DOS DESCRITORES DE TRÁFEGO ORIGINAIS PARA OS DESCRITORES A SEREM UTILIZADOS NO CRITÉRIO DE ACEITAÇÃO DO CAC. .....................................................................................................99 TABELA 4.2 – MAPEAMENTO DOS DESCRITORES DE TRÁFEGO ORIGINAIS PARA OS DESCRITORES A SEREM UTILIZADOS NO CÁLCULO DA LARGURA DE FAIXA EFETIVA E DO ESPAÇO EM GERENCIADOR DE TRÁFEGO EFETIVO. .101 TABELA 5.1 – PARÂMETROS DE QOS E DESCRITORES DE TRÁFEGO PARA AS CATEGORIAS DE SERVIÇO ATM. FONTE [7]..........................................................................................................................................................142 TABELA 5.2 – DEFINIÇÕES DE CONFORMIDADE PARA AS CATEGORIAS DE SERVIÇO ATM. FONTE [7]. ..........................142 TABELA 5.3 – CONJUNTOS DE PARES (SCR, MBS) OU (SCR, BT). ...............................................................................155 TABELA 6.1 – DESCRITORES DE TRÁFEGO ATM UTILIZADOS........................................................................................161 TABELA 6.2 – PESOS E CLR PARA CADA CONEXÃO. ......................................................................................................163 TABELA 6.3 – EVOLUÇÃO DAS VARIÁVEIS DO WF2Q_SCHEDULER DURANTE A EXECUÇÃO DO ALGORITMO DE ARMAZENAMENTO DE CÉLULAS ATM....................................................................................................165 TABELA 6.4 – DESCRITORES DE TRÁFEGO ATM UTILIZADOS........................................................................................184 TABELA 6.5 – PESOS E CLR PARA CADA CONEXÃO. ......................................................................................................185 TABELA 6.6 – DESCRITORES DE TRÁFEGO ATM UTILIZADOS........................................................................................193 TABELA 6.7 – PRINCIPAIS CARACTERÍSTICAS DAS CONEXÕES ESTABELECIDAS A PARTIR DE CADA APLICATIVO DA REDE. .....................................................................................................................................................197 xxi
  • Capítulo 1 Introdução 1.1 - Motivação 1.1.1 - ATM: Qualidade de Serviço Fim-a-Fim Estimuladas pelo vertiginoso crescimento da Internet e pela demanda crescente por serviços que integram dados, voz, vídeo e imagens, as operadoras de telecomunicações têm realizado, nas últimas décadas, grandes investimentos na ampliação de suas infra-estruturas de transmissão. Estas novas infra- estruturas, ao contrário das antigas redes telefônicas, não dependem mais de uma única tecnologia. Redes ópticas, telefônicas, via satélite e sem fio têm se integrado cada vez mais, oferecendo aos usuários uma gama maior de serviços disponíveis, a qualquer tempo e em qualquer lugar. Além disso, uma grande variedade de protocolos, funções e algoritmos são usados desde a camada física até a camada de aplicação da rede. Neste cenário, o uso de ferramentas computacionais tem se demonstrado imprescindível não apenas para reduzir custos, mas também para acelerar o projeto, a análise e a implantação dessas redes. Uma das tecnologias mais utilizadas nessa ampliação de infra-estrutura é a tecnologia ATM (Asynchronous Transfer Mode) [1][2][3][4]. O ATM é fundamentado na transmissão, multiplexação e chaveamento de pequenos pacotes de tamanho fixo, chamados de células, que permitem a integração e o transporte de voz, vídeo, imagens e dados sobre uma mesma rede de alta velocidade. O ATM oferece vantagens em potencial tanto em termos de vazão agregada de comutação quanto no suporte à qualidade de serviço (QoS – Quality of Service). E mais, o ATM pode ser usado em todas as porções de uma rede, desde a rede local até a rede de longa distância, reduzindo assim os custos de operação, administração e manutenção. Com todas estas vantagens em mãos, o ATM foi escolhido em 1988 pelo ITU-T (International Telecommunication Union – Telecommunication Standardization Sector) como o Modo de Transferência da Rede Digital de Serviços Integrados Faixa Larga (B-ISDN – Broadband Integrated Services Digital Network) [1]. 1
  • Na década de 1990, o ATM passou por diversos desenvolvimentos, guiados pelo ITU-T [5] e ATM Fórum [6], que culminaram na implantação de redes mundo afora. Atualmente, o ATM está sendo utilizado principalmente para: prover acesso e interligar redes corporativas que necessitam de muita largura de faixa e que sejam distribuídas geograficamente; construir backbones de longa cobertura e metropolitanos, visando a agregação de tráfego de redes de acesso; interconectar redes de diferentes tecnologias; e oferecer soluções de distribuição de vídeo. Devido as suas características, o ATM têm sido considerado uma das tecnologias mais favoráveis para oferecer QoS fim-a-fim para um grande número de aplicações, tais como telefonia, videoconferência, vídeo sobre demanda, educação à distância e web browsing. Entretanto, o suporte à qualidade de serviço em redes ATM requer um conjunto bastante sofisticado de funções de gerenciamento de tráfego (TM – Traffic Management). Dentre as principais razões que levaram a essa sofisticação podemos destacar a multiplexação estatística de células ATM e a ausência de um mecanismo de controle de fluxo no nível de células. Para suportar a multiplexação estatística, ou seja, o compartilhamento temporal dos enlaces por várias conexões, as redes ATM aceitam muito mais tráfego do que a capacidade de transmissão existente. A idéia é aumentar a eficiência da rede partindo da suposição que o período de surto de tráfego de uma determinada conexão não coincide com o período de surto das demais conexões. Por outro lado, o fato das redes ATM não possuírem um controle de fluxo no nível de células, permite que conexões mal comportadas transmitam um número maior de células do que o negociado. Para evitar que esse tráfego indesejado comprometa a QoS de conexões bem comportadas, as funções de gerenciamento de tráfego devem marcar ou descartar células desse tráfego a fim de evitar o congestionamento. Portanto, os objetivos principais das funções de gerenciamento de tráfego são a prevenção e a reação ao congestionamento na rede. Quando ocorre um congestionamento em uma rede ATM, as funções de gerenciamento de tráfego reagem de forma a manter os objetivos de QoS negociados e ao mesmo tempo maximizar o uso dos recursos disponíveis. Portanto, somente através de um gerenciamento de tráfego adequado é possível manter um nível satisfatório de QoS na rede sem reduzir a sua eficiência. As funções de gerenciamento de tráfego foram definidas pelo ATM Forum [6] na especificação Traffic Management Specification 4.0 [7], e pelo ITU-T [5] na recomendação I.371 Traffic Contract and Congestion Control in B-ISDN Standard [8]. Embora hajam algumas diferenças entre estes documentos, ambos abrangem de forma equivalente o gerenciamento de tráfego nas redes ATM. 2
  • 1.1.2 - Funções de Gerenciamento de Tráfego ATM Formalmente, a especificação TM 4.0 do ATM Forum define as seguintes funções de gerenciamento de tráfego ATM: Controle de Admissão de Conexões (CAC – Connection Admission Control). Controle de Utilização de Parâmetros (UPC – Usage Parameter Control). Descarte Seletivo de Células (Selective Cell Discarding). Formatação de Tráfego (Traffic Shaping). Controle Explícito de Congestionamento na Direção de Transmissão (Explicit Forward Congestion Control). Gerenciamento de Recursos usando Caminhos Virtuais (Resource Management using Virtual Paths). Descarte de Frames (Frame Discard). Controle de Fluxo Genérico (Generic Flow Control). Controle de Fluxo ABR (ABR Flow Control). Na prática, porém, essas funções são implementadas como algoritmos bem definidos, que em alguns casos agrupam mais de uma função de gerenciamento de tráfego. Um exemplo é o algoritmo de descarte seletivo de células que agrupa as funções de descarte seletivo de células e de descarte de frames. Embora a maioria das funções de gerenciamento de tráfego estejam sendo utilizadas em equipamentos comerciais, algumas delas praticamente não saíram do estágio de pesquisa acadêmica. São exemplos as funções de gerenciamento de recursos usando caminhos virtuais e de controle de fluxo genérico. Por outro lado, muitos algoritmos de gerenciamento de tráfego foram desenvolvidos por empresas para aplicação prática sem ter sido formalmente definidos pelo ITU-T ou pelo ATM Forum. São exemplos os algoritmos de escalonamento de células e de gerenciamento de estruturas de filas. Neste trabalho, consideramos os seguintes algoritmos de gerenciamento de tráfego ATM (veja o Capítulo 4): Algoritmos de Escalonamento (Scheduling Algorithms) – São implementados em cada ponto de armazenamento de células da rede (estrutura de filas – queueing structure) para 3
  • selecionar a ordem apropriada de serviço das células, a fim de garantir os objetivos de QoS negociados. Algoritmos de Controle de Admissão de Conexões (CAC Algorithms – Connection Admission Control Algorithms) – Determinam se uma nova conexão ATM pode ou não ser estabelecida na rede, reservando espaço físico nas estruturas de filas da rede e largura de faixa nos algoritmos de escalonamento. Este algoritmo implementa a função de controle de admissão de conexões especificada pelo ATM Forum. Algoritmos de Gerenciamento de Estruturas de Filas (Buffer Manangement Algorithms) – São implementados junto as estruturas de filas da rede a fim de julgar se uma célula recebida pode ou não ser armazenada. Algoritmos de Descarte Seletivo de Células (Selective Cell Discard Algorithms) – Em uma situação de congestionamento, células ATM eventualmente terão que ser descartadas. Nesta situação, algoritmos de descarte seletivo de células são necessários, pois células de menor prioridade devem ser descartadas em benefício de células mais prioritárias. Este algoritmo implementa as funções de descarte seletivo de células e de frames especificadas pelo ATM Forum. Algoritmos de Formatação de Tráfego (Traffic Shaping Algorithms) – Formatam o tráfego das conexões ATM para que esse esteja de acordo com o contrato de tráfego negociado. Este algoritmo implementa a função de formatação de tráfego especificada pelo ATM Forum. Algoritmos de Policiamento de Tráfego (Traffic Policing Algorithms) – Atuam marcando e descartando células ATM a fim de que o tráfego mal comportado de uma determinada conexão satisfaça os descritores de tráfego negociados. Este algoritmo implementa a função de controle de utilização de parâmetros especificada pelo ATM Forum. As funções de controle explícito de congestionamento na direção de transmissão, gerenciamento de recursos usando caminhos virtuais, controle de fluxo genérico e de controle de fluxo ABR não foram consideradas neste trabalho. 4
  • 1.1.3 - Complexidade e Interdependência entre Funções Segundo Giroux et. al [9], a complexidade das funções de gerenciamento de tráfego não é intrínseca das redes ATM, mas sim necessária para qualquer tecnologia que aspire carregar tráfego multimídia de forma eficiente e ao mesmo tempo atender garantias de QoS fim-a-fim. Além disso, na nossa opinião, a complexidade do gerenciamento de tráfego ATM é agravado por outro importante fator: a forte interdependência existente entre essas funções. Por exemplo, consideremos o caso de uma conexão ATM cujo contrato de tráfego negociado assegura um valor máximo de taxa de perda de células (CLR – Cell Loss Ratio) da ordem de 10-6. O CLR obtido para essa conexão dependerá: Da estrutura de armazenamento de células utilizada – Uma estrutura de filas com filas individuais por conexão (per-VC queueing) permite um melhor isolamento de tráfego entre conexões do que uma estrutura de filas com uma única fila FIFO (first-in first-out queuing) [10]. Esse isolamento de tráfego evita que um surto de tráfego mal comportado de uma determinada conexão possa interferir nas células de outras conexões, ocasionando assim um possível congestionamento e a perda de células nessas conexões. Tipicamente, o tráfego de várias conexões é isolado entre si através de divisões físicas ou lógicas da estrutura de filas. Do algoritmo de gerenciamento de estruturas de filas utilizado – Alguns esquemas de particionamento de estruturas de filas oferecem isolamento naturalmente, através da reserva de recursos fixos para cada conexão, como por exemplo o particionamento completo (complete partitioning), enquanto outros precisam ser acoplados a um algoritmo de descarte seletivo de células para oferecer esse isolamento e ao mesmo tempo maximizar o ganho estatístico obtido [9], como por exemplo o particionamento dinâmico (dynamic partitioning) [10]. Uma alocação de espaço em buffer inferior do que a necessária para uma determinada conexão pode ocasionar a perda de células durante uma situação de congestionamento. Do algoritmo de escalonamento adotado – Vários algoritmos de escalonamento podem ser implementados para oferecer diferentes níveis de isolamento, atraso e vazão [11]. A utilização de um algoritmo de escalonamento inadequado pode ocasionar o aumento excessivo da ocupação das estruturas de filas da rede, bem como do tempo de permanência das células nessas estruturas. Neste caso, células ATM poderão ser descartadas devido a 5
  • falta de recursos nas estruturas de filas ou ao atraso excessivo sofrido por essas células na rede. Do algoritmo de controle de admissão de conexões utilizado – Um algoritmo de CAC eficiente produz um alto ganho estatístico sem violar as garantias de QoS negociadas. Na prática, as alocações de largura de faixa e de espaço em buffer feitas pelos algoritmos de CAC são utilizadas para gerenciar os recursos disponíveis nas estruturas de filas e nos algoritmos de escalonamento [12]. Portanto, é de fundamental importância que estas alocações sejam feitas de forma precisa e em acordo com os demais algoritmos de gerenciamento de tráfego implementados na rede. Do algoritmo de descarte de células utilizado – O CLR obtido para a conexão dependerá em grande parte desse algoritmo, uma vez que é ele que decide qual célula ou quais células serão descartadas. Alguns algoritmos de descarte permitem descartar células de conexões menos prioritárias em prol de células de conexões mais prioritárias, aumentando assim o isolamento de tráfego entre as conexões. Do algoritmo de policiamento de tráfego utilizado – Em determinadas circunstâncias, os algoritmos de policiamento de tráfego podem descartar células ATM consideradas não conformes com o contrato de tráfego acordado na fase de estabelecimento da conexão. Portanto, esses algoritmos podem contribuir significativamente para o CLR obtido. Do algoritmo de formatação de tráfego utilizado – Alguns algoritmos de formatação de tráfego funcionam de forma integrada com algoritmos de escalonamento. Portanto, é possível que células de um tráfego mal comportado sejam descartadas devido a falta de recursos nas estruturas de filas que armazenam essas células. Assim sendo, uma boa estimativa do nível de qualidade de serviço obtido para uma determinada conexão deve considerar todas as componentes geradas por esses algoritmos de gerenciamento de tráfego e a sua complexa interdependência. Somente com esse nível de detalhamento é possível estimar com precisão a qualidade de serviço oferecida para uma determinada conexão em termos de CLR, atraso e vazão. 6
  • 1.2 - Objetivos do Trabalho Este trabalho propõe o desenvolvimento de um conjunto de modelos de simulação capaz de avaliar com precisão, eficiência e robustez a qualidade de serviço fim-a-fim oferecida para conexões ATM diante de diferentes cenários de tráfego, de congestionamento e de recursos na rede. Para tanto, o conjunto de modelos desenvolvido deverá englobar não apenas as funções de gerenciamento de tráfego ATM e sua complexa interdependência, mas também todas as demais funcionalidades das redes ATM, tais como: o processamento, a comutação e o transporte de células ATM; a negociação do contrato de tráfego; o roteamento e o gerenciamento de conexões virtuais chaveadas. 1.3 - Organização da Tese A tese está organizada em sete capítulos. O segundo capítulo apresenta uma discussão sobre a simulação de sistemas de comunicação, e em especial de redes ATM. Neste capítulo são abordados os principais aspectos envolvidos na simulação computacional de redes ATM, destacando as várias direções que poderiam ser tomadas na realização deste trabalho. O terceiro capítulo apresenta o ambiente de simulação Hydragyrum 1.0, que foi o software escolhido para o desenvolvimento do conjunto de modelos de simulação. Neste capítulo é mostrada uma visão geral do ambiente de simulação Hydragyrum, abordando a estrutura e as principais características deste ambiente. O quarto capítulo apresenta o conjunto de modelos desenvolvido para a análise da qualidade de serviço em redes ATM, ou seja, o conjunto de modelos no nível de células. Este é o capítulo principal da tese, onde são mostradas as maiores contribuições do trabalho. O quinto capítulo apresenta uma discussão sobre os possíveis cenários de redes que poderiam ser simulados no Hydragyrum utilizando o conjunto de modelos no nível de células. Este capítulo também é importante, pois mostra como especificar simulações baseadas nos modelos desenvolvidos. O sexto capítulo apresenta três simulações realizadas utilizando-se o conjunto de modelos no nível de células e o ambiente de simulação Hydragyrum. Neste capítulo são apresentados os resultados de simulação do trabalho. Estes resultados demonstraram que o conjunto de modelos desenvolvido permite avaliar com precisão, eficiência e robustez a qualidade de serviço fim-a-fim oferecida para conexões ATM diante de diferentes cenários de tráfego, de congestionamento e de recursos na rede. Finalmente, no sétimo capítulo será apresentado um sumário das atividades desenvolvidas, relatando as principais decisões tomadas, soluções adotadas e conclusões 7
  • obtidas durante o desenvolvimento do trabalho. Também serão apresentadas algumas sugestões para trabalhos futuros. 1.4 - Principais Contribuições A principal contribuição do trabalho é o desenvolvimento de uma ferramenta única para a análise da qualidade de serviço em redes ATM. Esta ferramenta permite a análise sofisticada da QoS em redes ATM, uma vez que ela possui um amplo e expansível conjunto de modelos (veja o Capítulo 4), capaz de avaliar a qualidade de serviço oferecida para conexões ATM considerando não apenas as funções de gerenciamento de tráfego e sua complexa interdependência, mas também todas as demais funcionalidades das redes ATM. No Capítulo 6 são mostrados resultados que permitem comparar a qualidade de serviço oferecida para cada conexão de uma rede ATM diante de diferentes cenários de tráfego, de congestionamento e de recursos na rede. Além da ferramenta para a simulação de redes ATM, este trabalho contribuiu ainda com dois outros softwares inéditos (veja o Capítulo 5): um para a adaptação de seqüências de tráfego MPEG e outro para a estimação de descritores de tráfego ATM. 1.5 - Referências Bibliográficas [1] BLACK, UYLESS, “ATM: Foundation for Broadband Networks”, Prentice-Hall, 1995. [2] MINOLLI, D., ALLES, A., “LAN, ATM, and LAN Emulation Technologies”, Artech House, 1996. [3] SACKET, G.C., METZ, C., “ATM and Multiprotocol Networking”, McGraw Hill, January 1997. [4] ALLES, A., “ATM Internetworking”, White Paper, Cisco Systems, Inc., May 1995. [5] http://www.itu.ch [6] http://www.atmforum.com [7] ATM FORUM, “Traffic Management 4.0”, 1996. [8] ITU-T, “Traffic Control and Congestion Control in B-ISDN”, 2000. 8
  • [9] GIROUX, N., GANTI, S., “Quality of Service in ATM Networks: State-of-Art Traffic Management”, Prentice Hall, 1998. [10] KRISHNAN, S., CHOUDHURY, A., CHIUSSI, F., “Dynamic Partitioning: A Mechanism for Shared Memory Management”, IEEE INFOCOM’99, 1999. [11] BENNETT, J.C.R., ZHANG, H., “WF2Q: Worst-case Fair Weighted Fair Queuing'”, INFOCOM'96, March 1996. [12] ELWALID, A., WENTWORTH, R., “A New Approach for Allocating Buffers and Bandwidth to Heterogeneous, Regulated Traffic in an ATM Node”, IEEE Journal on Selected Areas in Communications, 13(6), 1995. 9
  • Página deixada em branco intencionalmente. 10
  • Capítulo 2 Simulação de Redes ATM 2.1 - Introdução Atualmente, a simulação computacional tem sido apontada como a alternativa mais flexível para a análise de desempenho de sistemas de comunicações [1][2][3], e em especial de redes ATM. Um exemplo desta flexibilidade é a facilidade com que mecanismos de gerenciamento de tráfego podem ser projetados e comparados. Outro exemplo é a dinâmica com que diferentes estratégias de modelamento podem ser utilizadas para modelar a arquitetura e os componentes de uma rede ATM. Estes, e outros exemplos mostram que somente a simulação computacional permite a análise de desempenho de redes ATM a um baixo custo e com um nível de flexibilidade adequado, que não é encontrado em outras soluções tais como métodos analíticos e redes de teste. Assim sendo, neste capítulo discutiremos os principais aspectos da simulação computacional de redes ATM. Iniciaremos abordando a simulação de sistemas de comunicações em geral, fazendo uma classificação das ferramentas existentes e discutindo algumas de suas principais características. O objetivo é apresentar as características gerais dos softwares de simulação de sistemas de comunicações. Estas características serão úteis para melhor compreendermos os aspectos fundamentais das ferramentas de simulação de redes ATM. Em seguida, abordaremos a simulação de redes ATM propriamente dita. Discutiremos os principais desafios que, na nossa opinião, devem ser vencidos na simulação de redes ATM. Discutiremos também, as características desejáveis dos softwares de simulação de redes ATM, as técnicas de simulação utilizadas, as principais estratégias de modelamento e a simulação paralela ou distribuída de redes ATM. Apresentaremos também algumas ferramentas de simulação destas redes, fazendo uma comparação entre elas. 2.2 - Simulação de Sistemas de Comunicações Inicialmente, a simulação computacional foi usada para avaliar o desempenho de componentes individuais de um sistema de comunicações, tal como um modem, um satélite ou um receptor. Com o 11
  • passar dos anos, sistemas completos começaram a ser simulados. Entretanto, somente sistemas muito caros e de alto risco eram simulados, em parte devido ao alto custo dos computadores. Hoje em dia, a simulação computacional é utilizada em uma gama muito grande de aplicações, que vão desde o mapeamento genético humano até a análise de investimentos financeiros em bolsas de valores. A popularização da simulação computacional se deve principalmente à redução do custo e ao aumento da capacidade dos computadores, bem como do desenvolvimento de sistemas operacionais mais eficientes e simples de serem usados. Esta popularização também atingiu as ferramentas para a simulação de sistemas de comunicações. Atualmente, tais ferramentas tem sido utilizadas não só no meio acadêmico e empresarial, mas também em microcomputadores pessoais. 2.2.1 - Classificação das Ferramentas Segundo Law [2] existem três tipos principais de softwares de simulação de sistemas de comunicações: Linguagens Gerais de Simulação – Podem em princípio ser utilizadas para simular qualquer sistema. Porém, algumas destas linguagens incluem conjuntos de modelos (veja seção 2.2.2.1 - ) especialmente desenvolvidos para a simulação de redes de comunicações. Talvez a maior vantagem deste tipo de software é que ele possibilita simular qualquer tipo de rede de comunicações, independente da sua complexidade e das suas singularidades. Entretanto, nem sempre é possível atingir o grau de detalhamento desejado quando se utiliza este tipo de ferramenta. Exemplos deste tipo de software que possibilitam a simulação de redes ATM são: MODSIM III [4], SIMSCRIPT II.5 [4] e Parsec [5][6]. Linguagens de Simulação Orientadas às Redes de Comunicações – Como o próprio nome já diz, são direcionadas especificamente para a simulação de redes de comunicação. Dentre as vantagens deste tipo de software podemos destacar a facilidade e a flexibilidade de desenvolvimento de modelos. Exemplos deste tipo de software que possibilitam a simulação de redes ATM são: OPNET Modeler [7] e TeD/GTW [8]. Simuladores Orientados às Redes de Comunicações – São softwares que permitem simular apenas uma classe específica de redes de comunicações. Dentre as vantagens deste tipo de software estão a facilidade de uso e a redução do tempo e da complexidade de desenvolvimento de modelos. Porém, é importante observar que nem todos os softwares 12
  • deste tipo permitem o desenvolvimento de novos modelos. Exemplos destes simuladores são: NIST [10][11], QUARTS-II [12], ATM-TN [13][14], CLASS [15][16], Ancles [17], SimATM (Pennsylvania State University) [18], SimATM (Unicamp) [19][20] e Hydragyrum (Unicamp) [21][22]. 2.2.2 - Principais Características 2.2.2.1 - Modelamento Modelamento é o processo de construir modelos de sistemas e de dispositivos reais para um determinado ambiente de simulação, de forma que estes modelos representem o mais fiel possível o funcionamento desses elementos diante de um certo conjunto de situações. Tipicamente, as ferramentas atuais de simulação [3] usam um diagrama de blocos hierárquico para representar graficamente os modelos de um determinado sistema. Neste diagrama, cada bloco funcional representa um subsistema, que é conectado a outros blocos a fim de representar o sistema completo. Estes blocos são construídos a partir de bibliotecas de modelos disponibilizadas junto com o software de simulação, e possuem parâmetros de simulação e de design. Parâmetros de simulação são usados para configurar o estado de um bloco durante a simulação como, por exemplo, a amostragem ou não de uma determinada variável estatística, enquanto parâmetros de design são usados para configurar o valor de variáveis específicas de um bloco, desta forma permitindo a modificação do seu comportamento. Os blocos funcionais são representados graficamente através de ícones, que uma vez conectados, descrevem o sistema a ser simulado. 2.2.2.2 - Gerência de Simulação As ferramentas atuais de simulação possuem um gerente de simulação, tipicamente chamado de kernel ou núcleo do simulador, que é responsável por acionar os blocos que descrevem um sistema a ser simulado. Este núcleo permite que um bloco utilize os recursos computacionais disponíveis por um intervalo de tempo dependente da técnica de simulação utilizada. Quando este bloco termina suas tarefas, ele avisa o kernel do simulador, que por sua vez aciona outros blocos do modelo de simulação, até que a simulação termine. 2.2.2.3 - Técnicas de Simulação Atualmente, várias técnicas são utilizadas no desenvolvimento de softwares de simulação de sistemas de comunicações [3]. Estas técnicas basicamente diferem na forma como os blocos do sistema 13
  • simulado são acionados (executados), e podem ser classificadas em três categorias: simulação orientada pelo tempo (Time-Driven Simulation), simulação orientada por dados (Data-Driven Simulation) e simulação orientada por eventos (Event-Driven Simulation). 2.2.2.3.1 - Simulação Orientada pelo Tempo (Time-Driven Simulation) Nesta técnica, cada bloco do modelo de simulação é chamado uma vez a cada intervalo de avanço do tempo de simulação (simulation clock). Ou seja, a cada incremento no tempo de simulação, todos os blocos do sistema são executados, atualizam seus estados internos para corresponder ao tempo atual, independente da existência ou não de alguma tarefa a ser executada. Isto torna esta técnica bastante ineficiente do ponto de vista computacional [3]. O tempo global de simulação é atualizado através de um incremento constante. 2.2.2.3.2 - Simulação Orientada por Dados (Data-Driven Simulation) Nesta técnica de simulação, um bloco só é executado se todos os dados necessários para a execução das suas tarefas já estiverem disponíveis. Desta forma, se em cada bloco do sistema simulado for conhecida de antemão a disponibilidade de tais dados, é possível a construção de uma seqüência de chamada de blocos antes do inicio da simulação. Caso contrário, a disponibilidade de tais dados deve ser verificada durante a simulação e os blocos deverão ser executados dinamicamente. A principal vantagem desta técnica é que ela minimiza o número de execuções realizadas a cada bloco. Entretanto, em certas situações, como por exemplo em sistemas com fluxo bidirecional de dados, pode acontecer de não ser possível definir uma seqüência de execução de blocos. Isto inviabiliza a aplicação desta técnica para a simulação de redes de comunicações, porque neste tipo de simulação quase sempre existem realimentações. Entretanto, esta técnica tem sido bastante usada na simulação de sistemas ponto-a-ponto e no nível de sinais, tal como em sistemas ópticos. 2.2.2.3.3 - Simulação Orientada por Eventos (Event-Driven Simulation) Nesta técnica de simulação os blocos agendam execuções, que são armazenadas em uma fila com prioridades na forma de eventos (Figura 2.1). Cada evento possui um tempo de execução. Um gerenciador de eventos (presente no gerente de simulação) retira o evento de maior prioridade (menor tempo de execução) que se encontra na fila e executa o bloco para o qual o evento se destina. Vários eventos podem ser agendados para o mesmo tempo de execução. Neste caso, o kernel deve executar os eventos na ordem em que eles foram agendados, ou seja, segundo a disciplina FIFO (First-in first-out). Toda vez que um evento é retirado da fila, o tempo global de simulação é avançado para o tempo de execução deste evento. Tipicamente, apenas alguns blocos são chamados a cada avanço no 14
  • tempo de simulação. Quando um bloco é acionado, procedimentos específicos são executados. Por exemplo, um bloco que modela um equipamento terminal pode executar um procedimento que representa a transmissão de uma célula ATM através de um enlace até o próximo equipamento da rede ATM. Ao término do processamento dessas funções, o fluxo da simulação é retornado para o kernel, que retira e interpreta outro evento da fila. A simulação prossegue até que não hajam mais eventos para serem executados, ou até que o tempo final de simulação seja alcançado. Na Figura 2.1, os blocos A,B e C agendam eventos na fila com prioridades. O kernel retira o evento com maior prioridade da fila, interpreta este evento e realiza a chamada do bloco a que o evento se destina. Supondo que todos os eventos que são mostrados na figura sejam executados, o bloco A será chamado no instante 1 segundo duas vezes, o bloco B nos instantes 0, 1 e 2 segundos, e o bloco C nos instantes 1 e 2 segundos. Quando um bloco é executado, ele pode agendar novos eventos na fila para instantes de tempo superiores ou iguais ao tempo atual. Bloco A Bloco B Bloco C Evento (1) Evento (2) Evento (2) 1 Executa o Executa o Executa o 4 Bloco A Bloco B Bloco C (1,1) (0,1,2) (1,2) Evento (1) 2 Evento (1) Evento (1) Gerenciador de Evento (0) Eventos Fila de Eventos 3 1 Agendamento de eventos pelos blocos. 3 Retirada do evento de maior prioridade. 2 Armazenamento dos eventos na fila com prioridades. 4 Interpretação e execução do evento retirado da fila. Nota: Os valores entre parênteses indicam tempo de execução em segundos. Figura 2.1 – Esquema de armazenamento e execução de eventos. 15
  • A troca de informações entre blocos pode ser facilmente implementada utilizando-se a simulação orientada por eventos. Por exemplo, um bloco pode agendar um evento para outro bloco contendo as informações a serem trocadas. Assim, quando o kernel interpretar este evento, ele poderá executar o bloco de destino e entregar as informações que lhe pertencem. Neste caso, o kernel funciona como um intermediador para a troca de mensagens entre blocos. Segundo Shanmugan [3], para a simulação de redes de comunicações e sistemas lógicos, a técnica event-driven é mais eficiente do ponto de vista computacional do que a técnica data-driven, devido a sua natureza assíncrona. 2.2.2.4 - Biblioteca de Modelos Os sistemas de comunicações são representados a partir da interconexão de blocos, que representam subsistemas. Geralmente, os blocos disponíveis fazem parte de uma biblioteca de modelos, que é fornecida junto com as ferramentas de simulação. A utilização de bibliotecas de modelos permite a fácil substituição dos blocos durante a fase de configuração do sistema a ser simulado. A biblioteca de modelos pode ser implementada de duas formas: junto do kernel do simulador ou separadamente. Na primeira forma de implementação, a biblioteca de modelos só pode ser expandida se toda a ferramenta for recompilada. Já na segunda solução, novos modelos podem ser incorporados à ferramenta sem a necessidade de recompilar o kernel do simulador. 2.3 - Simulação de Redes ATM No final da década de 80, paralelamente ao desenvolvimento da tecnologia ATM, surgiram os primeiros experimentos de simulação de redes ATM [23][24]. Tipicamente, estes experimentos preocupavam-se somente com a simulação da arquitetura dos comutadores ATM. Logo em seguida, surgiram simuladores capazes de simular o transporte e o processamento de células ATM em toda a rede. No geral, estes softwares eram bastante específicos, desenvolvidos somente para a simulação de redes ATM. Exemplos são os simuladores NIST [10], CLASS [15], SimATM (Pennsylvania State University) [18] e SimATM (Unicamp) [19][20]. Neste mesmo período algumas linguagens gerais ou orientadas às redes de comunicações também incorporaram modelos para a simulação de redes ATM. Um exemplo é a ferramenta Ptolemy [25]. Com o passar do tempo, novas ferramentas de simulação começaram a ser desenvolvidas, ampliando cada vez mais os aspectos simulados. Observando a evolução destas ferramentas, algumas questões fundamentais podem ser levantadas: Quais são os 16
  • desafios que devem ser superados por uma ferramenta de simulação de redes ATM? Como devem ser estas ferramentas? Quais são as características desejáveis para este tipo de software? Como pode ser implementada a dinâmica da simulação? Como serão modelados a arquitetura, os componentes, os algoritmos e as funções presentes nas redes ATM? Pode-se utilizar simulação paralela ou distribuída? Para responder a estas perguntas, em 1998, no inicio deste trabalho, fizemos um estudo cujo os resultados serão apresentados nas seções a seguir. 2.3.1 - Desafios de Desenvolvimento Nesta seção discutiremos os principais desafios que devem ser vencidos por um software de simulação ATM. A partir de nossa revisão bibliográfica agrupamos quatro principais desafios. São eles: Possibilitar a simulação de grandes redes hierárquicas – Um simulador de redes ATM deve possibilitar a simulação de grandes redes hierárquicas [26], uma vez que o ATM utiliza o protocolo de roteamento P-NNI (Private Network-to-Network Interface) [27], que possui estrutura hierárquica e é voltado para redes de longa distância (WAN – Wide Area Network). O objetivo é permitir a análise de desempenho de protocolos de roteamento, a análise de confiabilidade da rede e a análise de perda de células e de atraso em comutadores. Estes problemas podem ser melhor estudados quando se simula redes hierárquicas de grande porte. Possibilitar a simulação de redes multiprotocolos – Um simulador de redes ATM deve possibilitar a simulação de redes multiprotocolos, uma vez que a tecnologia ATM está sendo adotada como uma tecnologia de interconexão de redes de comunicação [27], interconectando um grande número de pilhas de protocolos distintos. O objetivo é permitir a análise de desempenho de redes com várias pilhas de protocolos sobrepostas, como por exemplo, redes TCP/IP [27] sobre ATM, MPEG (Moving Picture Experts Group) sobre ATM e ATM sobre WDM (Wavelength Division Multiplexing). Possibilitar a simulação de eventos raros – Um simulador de redes ATM deve possibilitar a simulação de eventos raros [28], tais como probabilidade de perda de células e probabilidade de atraso excessivo de transporte de células, uma vez que estes eventos são importantes medidas de desempenho em redes ATM. 17
  • Possibilitar a simulação por longas escalas de tempo – Finalmente, um simulador de redes ATM deve possibilitar a simulação por longas escalas de tempo [26][28], a fim de permitir a estimação apurada de probabilidades de ocorrência de eventos raros e de evitar a interpretação incorreta de transitórios de longa duração originários de tráfegos dominados por correlações de longa dependência (tráfego autosimilar) [29]. Como se pode ver, construir um simulador que consiga atender a todos estes pré-requisitos simultaneamente é uma tarefa extremamente complexa. 2.3.2 - Características Desejáveis Para que os desafios de desenvolvimento apresentados na seção anterior possam ser vencidos, acreditamos que um software de simulação de redes ATM deva: Utilizar uma técnica de simulação eficiente – Utilizar uma técnica de simulação eficiente é fundamental para um software de simulação ATM. Como vimos na seção anterior, possibilitar a simulação de grandes redes hierárquicas carregando o tráfego de dezenas de protocolos durante grandes escalas de tempo requer a utilização de técnicas de simulação altamente eficientes. Na seção 2.3.3 - discutiremos as técnicas de simulação que estão sendo empregadas no desenvolvimento destes softwares. Utilizar processamento paralelo ou distribuído – Pela mesma razão do item anterior, a utilização de processamento paralelo ou distribuído no kernel do simulador constitui outra importante característica desejável. Na seção 2.3.5 - discutiremos a simulação paralela ou distribuída de redes ATM. Utilizar uma linguagem de programação que suporte programação orientada a objetos – Outra característica desejável aos softwares de simulação ATM é a utilização de uma linguagem de programação que suporte programação orientada a objetos (OOP – Object Oriented Programming) [30]. Este paradigma de programação permite o design modular, flexível e hierárquico do simulador e de seus modelos. Dentre as linguagens de programação que suportam OOP, a linguagem C++ [30] é a mais indicada devido às suas características. Vários são os simuladores que utilizam esta linguagem: Parsec [5], TeD [8], ATM-TN [13], SimATM (Unicamp) [19] e outros. 18
  • Possuir uma biblioteca de modelos expansível e independente do kernel do simulador – A biblioteca de modelos é o conjunto de todos os modelos que podem ser utilizados para construir uma rede ATM a ser simulada. Portanto, é fundamental que o software de simulação permita o desenvolvimento e a integração de novos modelos a esta biblioteca. Isto deve ser feito de forma transparente, sem que o kernel da ferramenta precise ser modificado. Facilitar o desenvolvimento de modelos – Facilitar o desenvolvimento de modelos é outra característica desejável, uma vez que nem sempre os modelos disponíveis na biblioteca de modelos satisfazem as necessidades de simulação. Permitir a flexibilidade e a eficiência de modelamento – O simulador deve ainda permitir a flexibilidade e a eficiência de modelamento. Em princípio, todas as estratégias existentes de modelamento devem ser suportadas eficientemente. Também é interessante que o simulador disponibilize um ou mais conjuntos básicos de modelos desenvolvidos com diferentes estratégias de modelamento. Na seção 2.3.4 - discutiremos o modelamento de redes ATM, descrevendo as principais estratégias de modelamento que estão sendo utilizadas atualmente. Permitir o modelamento hierárquico – Também é desejável que o simulador ATM permita o modelamento hierárquico, ou seja, que novos modelos possam ser construídos a partir de modelos já existentes. Esta característica facilita bastante o desenvolvimento de modelos em redes ATM, dada a hierarquia lógica de blocos existente em protocolos, equipamentos, aplicativos e outros componentes das redes ATM. Possibilitar o cálculo e a coleta detalhada de estatísticas – Finalmente, o simulador deve ainda incluir recursos para possibilitar o cálculo e a coleta detalhada de estatísticas. Esta característica é bastante importante uma vez que na simulação de redes ATM as fontes de tráfego geralmente possuem comportamento aleatório ou autosimilar. 2.3.3 - Técnicas de Simulação Vários fatores devem ser levados em consideração quando se escolhe a técnica de simulação a ser adotada em um simulador ATM. A técnica escolhida deve ser eficiente, deve permitir a troca flexível de informações entre os modelos da rede, deve possibilitar o modelamento do fluxo assíncrono 19
  • bidirecional de informações presente nos enlaces das redes ATM e ainda deve permitir o modelamento flexível da arquitetura e dos componentes destas redes. Dentre as técnicas de simulação existentes [3], duas técnicas têm sido utilizadas para desenvolver softwares de simulação ATM: técnica orientada por eventos (event-driven) e técnica orientada pelo tempo (time-driven). Ambas as técnicas atendem aos pré-requisitos apresentados, muito embora a técnica event-driven seja mais eficiente do ponto de vista computacional do que a técnica time-driven devido a sua natureza assíncrona. Por esta razão, a técnica event-driven tem sido mais utilizada. Várias são as referências bibliográficas de simuladores que utilizam esta técnica: [10][12][13][15][18][19][31][32][33][34]. Um exemplo de utilização da técnica time-driven pode ser encontrado em [35]. Para o desenvolvimento de ferramentas de simulação paralelas ou distribuídas, a simulação orientada a eventos sofre modificações consideráveis, passando a chamar-se PDES – Parallel Discrete Event Simulation. Maiores detalhes desta técnica podem ser encontrados em [26] e [5]. 2.3.4 - Estratégias de Modelamento Como vimos na seção 2.2.2.1 - , modelamento é o processo de construir modelos de sistemas e de dispositivos reais para um determinado ambiente de simulação, de forma que estes modelos representem o mais fiel possível o funcionamento desses elementos diante de um certo conjunto de situações. Assim sendo, definimos estratégia de modelamento como sendo a estratégia adotada para modelar a arquitetura e os componentes de uma rede ATM. O modelamento das redes ATM é uma tarefa bastante difícil, uma vez que é necessário não apenas o conhecimento do ambiente de simulação para o qual os modelos estão sendo desenvolvidos, mas também o conhecimento de toda a teoria ATM, dos detalhes dos componentes a serem modelados e dos resultados a serem obtidos. Segundo Falkner [9], um fator extremamente importante que deve ser levado em conta quando se desenvolve modelos para redes ATM, é a distinção entre simulação e emulação. Na emulação, o propósito é imitar completamente a rede ou uma função original, representando na totalidade os detalhes envolvidos. Em contraste, na simulação o propósito é obter resultados estatísticos que descrevam a operação destas redes ou funções. Ou seja, na simulação não há necessidade de se representar todas as funções envolvidas, mas somente aquelas cujos detalhes são significativos com respeito às estatísticas de interesse. Do ponto de vista prático, é impossível incorporar os detalhes de todas as funções executadas por um único nó de uma rede ATM e esperar que um simples computador 20
  • simule ou emule tal modelo. Esta é uma das razões da complexidade de desenvolver modelos para redes ATM. Ainda segundo Falkner [9], a chave para o modelamento de redes ATM é incorporar nos modelos somente aqueles detalhes que são significativos para responder as questões de um determinado problema. Entretanto, esta abordagem implica que tanto o problema a ser resolvido quanto as estatísticas de interesse sejam conhecidas. Talvez a maior implicação desta abordagem é que para cada problema a ser resolvido é necessário construir um novo conjunto de modelos. É claro que é possível construir modelos que sejam aplicáveis para resolver vários problemas distintos. Entretanto, o desenvolvimento deste tipo de modelo é ainda mais complexo. De forma geral, quando modelamos uma rede ATM devemos otimizar as relações entre: O nível de detalhamento dos modelos e o custo computacional – O objetivo é não sobrecarregar a simulação com a execução de funções insignificantes em termos de resultados para os problemas que estão sendo estudados. A flexibilidade dos modelos e o custo computacional – Dependendo da estratégia de modelamento adotada diferentes graus de eficiência computacional e de flexibilidade dos modelos podem ser obtidos. O objetivo, portanto, é obter a maior eficiência computacional e ao mesmo tempo manter a flexibilidade dos modelos. Ou seja, de nada adianta desenvolver modelos extremamente eficientes, se eles forem tão específicos que a menor mudança no sistema a ser simulado inviabilize a sua aplicação, tornando necessário desenvolvê-los novamente. Em nosso trabalho, encontramos quatro estratégias de modelamento estão sendo utilizadas atualmente: modelamento no nível de células, modelamento no nível de chamadas, modelamento fluído e modelamento utilizando técnicas de amostragem por importância (importance sampling techniques). A seguir discutiremos em maiores detalhes cada uma destas estratégias de modelamento. 2.3.4.1 - Modelamento no Nível de Células O modelamento no nível de células ATM foi a primeira solução encontrada para a simulação de redes ATM. Neste tipo de simulação os modelos preocupam-se com o transporte, armazenamento, serviço e processamento individual de células ATM. Tipicamente, também são desenvolvidos modelos que preocupam-se com outros tipos de pacotes além das células ATM, como por exemplo: unidades de dados de protocolos (PDUs – Protocol Data Units) [27] das camadas de adaptação ATM (AAL – ATM 21
  • Adaptation Layer) [27], das camadas superiores a AAL e das camadas físicas. Em todos estes casos, somente são modelados os cabeçalhos das PDUs. Ou seja, nenhuma carga útil (payload) é considerada. No modelamento no nível de células, geralmente são desenvolvidos modelos para as camadas físicas, ATM, AAL e para as camadas superiores, que são as fontes de tráfego da rede. Estes modelos de fontes de tráfego geram pacotes que são convertidos em AAL-PDUs nos modelos de camadas de adaptação ATM. Os modelos de camadas ATM montam as células ATM a partir das AAL-PDUs recebidas e enviam ATM-PDUs para os modelos da camada física. Na camada física as células são enviadas para o próximo nó da rede, e assim sucessivamente, até que alcancem o seu destino. Neste ponto, a AAL-PDU é remontada e entregue à camada superior de destino. A maioria das ferramentas de simulação de redes ATM disponibilizam modelos para a simulação no nível de células ATM. Exemplos destes modelos podem ser obtidos a partir das referências: [4][7][9][10][12][13][15][19]. Talvez a principal vantagem do modelamento no nível de células é o nível de detalhamento que pode ser obtido, uma vez que este é o nível natural de funcionamento das redes ATM. Entretanto, de forma geral o modelamento no nível de células é bastante oneroso do ponto de vista computacional. Segundo Kesidis [36], um switch de uma rede telecomunicações pode processar milhões de células por segundo, enquanto o número de células ATM que um simulador pode processar é da ordem de algumas mil células por segundo. Portanto, para simular um segundo de operação de um switch de uma rede de telecomunicações pode ser necessário um tempo de simulação algumas mil vezes maior. Contudo, existem várias aplicações em que o modelamento no nível de células provê os melhores resultados. Um exemplo disto é a aplicação da simulação computacional na análise de desempenho das funções de gerenciamento de tráfego ATM, com exceção da função de controle de admissão de conexões (CAC – Connection Admission Control) [27]. A simulação destas funções individuais e de seus complexos inter-relacionamentos exige que um grande número de detalhes seja considerado. Ou seja, todo o processamento individual de células ATM nestas funções deve ser considerado, a fim de que a estimação precisa do atraso e da perda de células neste cenário possa ser realizada. A estimação precisa destes parâmetros de desempenho é bastante prejudicada quando se utiliza as estratégias de modelamento fluído e no nível de chamadas. Outro exemplo é a aplicação da simulação computacional no meio acadêmico. Neste caso, é interessante que os modelos desenvolvidos permitam que se observe o maior número possível de peculiaridades da tecnologia que está sendo estudada, não importando os pré-requisitos de tempo de simulação. 22
  • 2.3.4.2 - Modelamento no Nível de Chamadas Neste tipo de simulação os modelos preocupam-se com a dinâmica do estabelecimento, manutenção e término de conexões ATM. Tipicamente, sempre que um usuário da rede requisita uma conexão, funções de roteamento e de controle de admissão de conexões são acionadas a fim de que um caminho ótimo em termos de qualidade de serviço (QoS – Quality of Service) seja encontrado. A análise de desempenho destes algoritmos de roteamento e de controle de admissão de conexões em algumas situações é bastante onerosa de ser realizada quando se utiliza o modelamento no nível de células. Dentro deste contexto, a simulação no nível de chamadas consiste de uma aproximação para a simulação no nível de células, que tem por objetivo viabilizar a analise de problemas orientados a rede. Entretanto como vimos na seção anterior, alguns índices e medidas de QoS são demasiados importantes para serem simplesmente aproximados no nível de chamadas. Para resolver este problema, algumas ferramentas utilizam resultados de simulações no nível de células para “alimentar” modelos desenvolvidos no nível de chamadas em outros simuladores, e vice-versa. Um exemplo desta solução são os simuladores CLASS [16] e Ancles [17]. Quando um determinado estado crítico é atingido pela rede que está sendo simulada no simulador Ancles, a configuração desta rede é gravada e repassada para o simulador CLASS. O simulador CLASS por sua vez simula esta rede até obter os índices de desempenho desejados, tais como: atraso de células, variações de atrasos e probabilidade de perda de células, que são então “realimentados” no simulador Ancles. 2.3.4.3 - Modelamento Fluído Esta estratégia de modelamento consiste em modelar as fontes de tráfego e os demais dispositivos de uma rede ATM, não somente como fontes de células ou processadores de células, mas sim como fontes ou processadores de fluxos contínuos de informações que apresentam uma taxa de transmissão em bits por segundo. Modelos de dispositivos construídos em termos de taxas são denominados modelos fluídos. Estes modelos permitem simulações bastante eficientes e, portanto, têm sido amplamente utilizados na avaliação analítica de redes de computadores, e mais recentemente na simulação de redes ATM. Segundo Mitra [32] a simulação no nível de taxas é uma aproximação para o comportamento no nível de células e em tecnologias de alta velocidade, como é o caso do ATM, a vantagem da simulação no nível de taxas surge do fato de que os eventos neste tipo de simulação ocorrem em escalas de tempo muito menores se comparadas com as escalas de ocorrência de eventos em simulações no nível de 23
  • células. Portanto, a priori, a simulação no nível de taxas requer muito menos tempo de simulação do que a simulação no nível de células, por exemplo. Entretanto, segundo experimentos realizados por Kesidis [33], o modelamento no nível de taxas possui melhor eficiência se as fontes de tráfego mantêm taxas altas e constantes. E mais, para redes onde um grande número de componentes é conectado em série (tandem networks), a simulação no nível de taxas pode ter um desempenho menor do que o esperado. Isto pode ocorrer devido a um efeito chamado Ripple Effect [33]. Este efeito é causado pela mudança da taxa de células que chega a um determinado sistema de fila com disciplina de atendimento FIFO. Esta mudança de taxa pode alterar a taxa de chegada de células a sistemas que se situam em posições anteriores na rede. Isto causa o cancelamento e o reagendamento de muitos eventos, prejudicando o desempenho da simulação. Tipicamente, no modelamento fluído os eventos estão relacionados com a mudança da taxa de transmissão de células pela fonte, com a admissão ou remoção de conexões ATM, com o início ou fim de surtos em conexões e com o processamento dos fluxos de células nos modelos da rede. No geral, estes eventos são bem mais complicados que os eventos gerados quando se utiliza o modelamento no nível de células. Portanto, os modelos fluídos podem ser considerados menos flexíveis. Atualmente, poucas ferramentas de simulação ATM disponibilizam modelos fluídos em suas bibliotecas. Alguns exemplos de modelos podem ser encontrados a partir das referências: [32][33][37][38]. 2.3.4.4 - Modelamento Utilizando Técnicas de Amostragem por Importância Como abordamos na seção 2.3.1 - , muitas medidas importantes de desempenho de redes de comunicação são definidas em termos de eventos raros. Dois exemplos destes eventos em redes ATM são: probabilidade de perda de células e probabilidade de atraso excessivo no transporte de células. Obter a estimação precisa destas probabilidades utilizando simulação computacional pode requerer períodos de tempo bastante longos ou até mesmo proibitivos. Segundo Townsend [28], as técnicas de amostragem por importância (IS – Importance Sampling) prometem a redução do tempo de simulação de tais eventos raros. Assim sendo, esta estratégia de modelamento consiste em modelar os componentes de uma rede ATM utilizando as técnicas de IS para acelerar a simulação. A idéia básica da amostragem por importância é modificar o comportamento estocástico do sistema a ser simulado de forma a aumentar o espaço amostral dos eventos raros de interesse. Desta 24
  • forma, o principal esforço de utilizar IS no desenvolvimento de modelos reside em determinar quais parâmetros do sistema devem ser modificados e quanto cada um deles deve ser modificado. Tipicamente, as técnicas de IS são agrupadas em duas categorias [28]: técnicas onde os elementos estocásticos individuais são modificados ou equalizados e técnicas onde a evolução global do sistema é manipulada. As técnicas de modificação de elementos estocásticos individuais envolvem a modificação de distribuições de probabilidade nos geradores de números aleatórios dos modelos. Isto requer um considerável conhecimento prévio sobre a rede a ser simulada, pois deve-se conhecer de antemão como a modificação destas distribuições pode afetar a distribuição dos eventos raros de interesse. Outro aspecto importante diz respeito a quanto modificar as distribuições nestes geradores. Este aspecto é conhecido como otimização de parâmetros de IS [28]. Exemplos de técnicas desta categoria são as técnicas baseadas na teoria dos grandes números (LDT – Large Deviations Theory) [28], técnicas de otimização estocástica [28][39] e técnicas de equalização condicional (conditional biasing) [28][40]. As técnicas aonde a evolução global do sistema é manipulada baseiam-se no aumento do número de visitas nas regiões dos eventos raros de interesse. Isto é feito através do desdobramento de trajetória (trajectory splitting). A idéia fundamental do desdobramento de trajetória [28] é baseada na suposição de que existem estados intermediários em um sistema que são visitados muito mais freqüentemente do que os estados de interesse. Assim, quando estes estados são atingidos (por exemplo através da extrapolação de um limiar pré-definido) o estado atual do sistema é salvo e várias sub- trajetórias são simuladas a partir deste ponto. Porém, para que um avanço considerável de velocidade de simulação seja obtido, é necessário definir um amplo e hierárquico conjunto de condições de desdobramento (limiares). Um exemplo de técnica desta categoria é a técnica RESTART/DPR – Repetitive Simulation Trials After Reaching Thresholds/Direct Probabililty Redistribution [28][41]. A principal vantagem da estratégia de modelamento utilizando técnicas de IS é aceleração da simulação de eventos raros. Resultados recentes mostram acelerações de várias ordens de grandeza para várias técnicas de IS [28]. Entretanto, os modelos construídos utilizando-se IS demonstraram-se um pouco inflexíveis. Isto porque antes da implementação computacional de cada modelo uma fase de análise matemática precisa ser realizada e, dependendo das modificações a serem feitas no modelo, esta fase precisa ser refeita. Outro aspecto importante de ser observado é relativo à complexidade de desenvolvimento de modelos utilizando técnicas de IS. Dependendo da técnica utilizada, o 25
  • desenvolvimento de tais modelos pode requerer sólidos conhecimentos de matemática (processos estocásticos, teoria de deteção e estimação, etc.) e de linguagens de programação. Atualmente, poucas ferramentas de simulação ATM disponibilizam modelos baseados em técnicas de IS. Alguns exemplos de modelos podem ser encontrados a partir das referências: [39][40][41]. 2.3.5 - Simulação Paralela ou Distribuída Simulação paralela ou distribuída é o processo de se utilizar múltiplos processadores simultaneamente para executar uma única simulação, tendo como principal objetivo reduzir o tempo total de execução. Segundo Heegaard [42], existem duas possibilidades para a simulação paralela ou distribuída: PADS – Parallel And Distributed Simulation e PIRS – Parallel Independent Replicated Simulation. A solução PADS distribui subprocessos em vários processadores, enquanto a solução PIRS distribui réplicas completas de um processo de simulação em cada processador. A solução PIRS se aplica a situações onde existe quase nenhuma ou nenhuma interação entre os processos paralelos de simulação, enquanto a solução PADS se aplica a situações onde existe grande interação entre os processos paralelos de simulação. Neste caso, é necessária a sincronização entre processos. Tipicamente, dois tipos de algoritmos são utilizados para a sincronização de processos paralelos: algoritmos conservativos e algoritmos otimistas. Maiores detalhes destes algoritmos podem ser encontrados em [5] e [31]. A principal vantagem do uso de simulação paralela é a redução do tempo de simulação. Como demonstrado em [31], para grandes e complexas redes ATM o uso de simulação paralela pode de fato reduzir o tempo de simulação para níveis toleráveis, tal como de vários dias para algumas horas. A aceleração das simulações tem sido proporcional ao número de processadores presentes em cada máquina utilizada. Entretanto, técnicas de simulação paralelas são inerentemente difíceis e, portanto, o desenvolvimento de modelos para ambientes multiprocessados é muito mais complexo do que para ambientes seqüenciais. E mais, modelos desenvolvidos para ambientes paralelos ou distribuídos são desenvolvidos especificamente para estes ambientes, não podendo ser usados em ambientes seqüenciais, e vice-versa. 26
  • Dados os recentes avanços nas técnicas de simulação paralela ou distribuída acreditamos que tais técnicas constituem uma solução muito eficiente para acelerar a simulação de redes de comunicações, e em especial de redes ATM. Porém, é importante lembrar que apesar da evolução dos computadores, poucas são as empresas e universidades que dispõem de máquinas multiprocessadas. Grande parte dos usuários de softwares de simulação ainda utilizam máquinas seqüenciais. Este é um aspecto importante que deve ser considerado quando se desenvolve uma ferramenta paralela voltada principalmente para o mercado comercial. 2.3.6 - Ferramentas de Simulação de Redes ATM O objetivo desta seção é apresentar algumas ferramentas de simulação de redes ATM. Uma comparação entre as ferramentas é feita a partir de informações obtidas pela Internet e através de artigos. As seguintes ferramentas de simulação de redes ATM foram investigadas: NIST ATM Network Simulator – Esta ferramenta vem sendo desenvolvida no NIST – National Institute of Standards and Technology dos E.U.A., desde 1995. Atualmente encontra-se na quarta versão. Inclui modelos para a simulação de redes HFC (Hybrid Fiber Coax) e ATM [10]. A última versão está disponível a partir do endereço encontrado em [11]. QUARTS-II – Queen’s University ATM Routing Testbed/Simulator II – Esta ferramenta vem sendo desenvolvida pela Universidade de Queen’s, na cidade de Kingston, Canadá. Como o próprio nome já diz, o principal propósito da ferramenta é a simulação de protocolos de roteamento ATM. A ferramenta incorpora várias características avançadas do protocolo de roteamento P-NNI recomendado pelo ATM Forum. Maiores informações podem ser obtidas a partir da referência [12]. ATM-TN – Esta ferramenta vem sendo desenvolvida dentro do contexto do projeto TeleSim. O projeto TeleSim é um projeto de pesquisa desenvolvido em parceria entre as universidades de Calgary e Saskatchewan, no Canadá, e Waikate na Nova Zelândia. O projeto tem por objetivo desenvolver uma ferramenta de simulação de redes ATM de alto desempenho que permita a simulação sob condições de tráfego realísticas. A versão final da ferramenta já se encontra disponível para download. Maiores informações podem ser obtidas a partir das referências [13][14]. 27
  • CLASS – ConnectionLess ATM Services Simulator – CLASS é um simulador de redes ATM que foi desenvolvido pelo Grupo de Redes de Telecomunicações do Instituto Politécnico de Torino, na Itália, em parceria com o CSELT – Centro Studi E Laboratori Telecomunicazioni. A versão 6.2h da ferramenta pode ser obtida livre de taxas a partir do endereço do projeto na Internet [16]. Maiores detalhes sobre a ferramenta podem ser obtidas a partir da referência [15]. Ancles – ATM Networks Call-LEvel Simulator – Esta ferramenta também está sendo desenvolvida pelo Grupo de Redes de Telecomunicações do Instituto Politécnico de Torino. A versão 2.0 da ferramenta pode ser obtida livre de taxas a partir do endereço do projeto na Internet [17]. SimATM – Esta ferramenta foi desenvolvida no Departamento de Comunicações (Decom) da Faculdade de Engenharia Elétrica e de Computação (FEEC) da UNICAMP e encontra-se na sua versão 0.61 [19][20]. O SimATM v0.61 é uma ferramenta desenvolvida especificamente para a simulação de redes ATM. Sua biblioteca de modelos foi implementada junto do kernel do simulador. Hydragyrum – O Hydragyrum 1.0 também foi desenvolvido no DECOM/FEEC/UNICAMP [21] e trata-se de uma nova versão do SimATM v0.61. O Hydragyrum 1.0 é uma ferramenta voltada para a simulação de redes de comunicações em geral. Entretanto, muitas de suas características favorecem o desenvolvimento de modelos para redes orientadas à conexão, tal como redes ATM. A biblioteca de modelos do Hydragyrum 1.0 foi desenvolvida separadamente do kernel do simulador, permitindo, portanto que novos modelos sejam incorporados sem a necessidade de recompilar o núcleo da ferramenta. Como veremos no próximo capítulo, esta foi a ferramenta que escolhemos para desenvolver este trabalho. OPNET MODELERTM – O OPNET MODELER é um ambiente para o modelamento, simulação e análise de desempenho de redes de comunicações, sistemas de computadores e aplicativos e sistemas distribuídos. O OPNET inclui junto com a sua série de ferramentas de simulação de redes, um conjunto de modelos para a simulação de redes ATM, chamado AMS – ATM Model Suite. Segundo o desenvolvedor do ambiente, a Opnet, o AMS 28
  • possibilita a simulação precisa e flexível de redes ATM. Maiores informações sobre o ambiente de simulação podem ser encontradas em [7]. TeD/GTW – Telecommunications Description Language/Georgia Tech Time Warp – O TeD é uma linguagem de modelamento de sistemas de telecomunicações independente do kernel de simulação utilizado. O GTW é um kernel voltado para a simulação paralela de alta eficiência. Dentro deste contexto, o TeD/GTW é um sistema operacional para simulações paralelas que une a linguagem de modelamento TeD e o kernel GTW. Embora o TeD/GTW não tenha sido especificamente desenvolvido para a simulação de redes ATM, ele tem sido usado para a simulação do protocolo de roteamento P-NNI em redes ATM [26]. Maiores informações sobre o software de simulação podem ser encontradas em [8]. Parsec – Parallel Simulation Environment for Complex Systems – Parsec é uma linguagem de simulação paralela que vem sendo desenvolvida pela Universidade de Califórnia em Los Angeles (UCLA). Assim como o TeD/GTW, o Parsec também não foi desenvolvido especificamente para a simulação de redes ATM. Entretanto, segundo os seus desenvolvedores vários modelos para a simulação de redes ATM já foram desenvolvidos. Maiores informações podem ser encontradas em [5] e [6]. 2.3.6.1 - Comparação entre as Ferramentas A seguir apresentaremos na Tabela 2.1 uma comparação feita entre as ferramentas apresentadas na seção anterior. Os seguintes aspectos das ferramentas foram investigados: Técnica de simulação utilizada no desenvolvimento do kernel. Estrutura voltada para a simulação paralela ou distribuída. Forma de implementação da biblioteca de modelos. Existência de interface gráfica. Estratégias de modelamento utilizadas para desenvolver os modelos disponíveis nas ferramentas. Linguagem de programação utilizada no desenvolvimento do kernel, interface gráfica e modelos. 29
  • Plataformas em que a ferramenta de simulação pode ser instalada. Características Simulação Paralela ou Biblioteca de Modelos Técnica de Simulação Interface Gráfica Linguagem de Estratégias de Modelamento Programação Distribuída Plataforma Nome Desenvolvedor NIST Simulator NIST Event-driven Não Junto1 Sim Células C Unix QUARTS-II Queen’s University (Canadá) Event-driven Não Junto Sim Células C Unix C++ e ATM-TN TeleSim Project Event-driven Sim Separada2 Sim Células Unix Java Instituto Politécnico de Torino OpenVMS, Linux, HP-UX, CLASS Time-driven Não Junto Não Células C (Itália) Ultrix e MS-DOS Instituto Politécnico de Torino OpenVMS, Linux, HP-UX, Ancles Event-driven Não Junto Não Chamadas C (Itália) Ultrix e MS-DOS SimATM v0.61 DECOM/FEEC/UNICAMP Event-driven Não Junto Não Células C++ WindowsTM Hydragyrum 1.0 DECOM/FEEC/UNICAMP Event-driven Não Separada Sim Células C++ WindowsTM OPNET MIL 3 Inc. Células ou TM Event-driven Não3 Separada Sim - - MODELER Washington DC (E.U.A.) Taxas C++ e Georgia Tech Institute of Sun Sparcs, SGI Onyx e TeD Event-driven Sim Separada Sim - C/ Technology (E.U.A.) PowerChallenge Java4 Solaris 2.5.1, SunOS 4.1.4, Irix 6.4, FreeBSD 2.2.2., Universidade da Califórnia em Ce Parsec Event-driven Sim Separada Sim - AIX, Los Angeles (E.U.A.) C++5 Redhat Linux 4.1/5.0, Windows 95/NT Tabela 2.1 – Características de algumas ferramentas de simulação de redes ATM. 2.4 - Referências Bibliográficas [1] TRANTER, W. H., KOSBAR, K. L., “Simulation of Communications Systems”, IEEE Communications Magazine, 1994. 1 A biblioteca de modelos é implementada junto do kernel da ferramenta. 2 A biblioteca de modelos é implementada separada do kernel da ferramenta. 3 Recurso em desenvolvimento. 4 O servidor da interface gráfica é feito em C e o cliente é feito em Java. 30
  • [2] LAW, A., McCOMAS, M., “Simulation Software for Communications Networks: The State of the Art”, IEEE Communications Magazine, 1994. [3] SHANMUGAN, S. K., “Simulation and Implementation Tools for Signal Processing and Communication Systems”, IEEE Communications Magazine, Julho 1994. [4] http://www.caciasl.com [5] BAGRODIA, R., MEYER, R., TAKAI, M., CHEN, Y., ZENG, X., MARTI, J., SONG, H., “Parsec: A Parallel Simulation Environment for Complex Systems”, IEEE Computer Magazine, Vol. 31, Num. 10, Outubro 1998. [6] http://may.cs.ucla.edu/projects/parsec/ [7] http://www.opnet.com/products/modeler/home.html [8] http://www.cc.gatech.edu/computing/pads/teddoc.html [9] FALKNER, M., “Modeling ATM Networks with COMNET III”, COMNET III Application Notes, Version 1.0, August 1996. [10] GOLMIE, N., “The NIST ATM/HFC Network Simulator: Operation and Programming Guide”, Versão 4.0, Manual de Operação e Programação, Dezembro 1998. [11] http://w3.antd.nist.gov/Hsntg/prd_atm-sim.html/ [12] SIVABALAN, M., MOUFTAH, H. T., “QUARTS-II: A Routing Simulator for ATM Networks”, IEEE Communications Magazine, Maio 1998. [13] UNGER, B., GOMES, F., XIAO, Z., GBURZYNSKI, P., ONO-TESFAYE, T., RAMASWAMY, S., WILLIAMSON, C., COVINGTON, A., "A High Fidelity ATM Traffic and Network Simulator", Proceedings of the 1995 Winter Simulation Conference, Arlington, VA, Dezembro 1995. 5 Permite executar simulações escritas em C++ através do uso de uma biblioteca chamada Compose. 31
  • [14] http://warp.cpsc.ucalgary.ca/ [15] MARSAN, M. A., CIGNO, R. L., MUFANÒ, M., TONIETTI, A., “Simulation of ATM Computer Networks with CLASS”, 7th International Conference on Modelling Techniques and Tools for Computer Performance Evaluation, Vienna, Austria, Maio 1994. [16] http://www1.tlc.polito.it/class/ [17] http://www1.tlc.polito.it/ancles/ [18] HUNG, A., KESIDIS, G., “SimATM: A cell-level ATM network simulator”, Technical Report (draft), 1993. [19] ALBERTI, A. M., “SimATM: Um Ambiente para a Simulação de Redes ATM”, Tese de Mestrado, Faculdade de Engenharia Elétrica e de Computação, UNICAMP, Orientador: Prof. Dr. Leonardo S. Mendes, Abril 1998. [20] http://www.mc21.fee.unicamp.br/simatm/ [21] ANDRADE NETO, E., ALBERTI, A. M., “Hydragyrum – Ambiente de Simulações de Redes a Eventos Discretos”, SBrT´2000, Setembro 2000. [22] http://www.mc21.fee.unicamp.br/Hydragyrum/ [23] KESIDIS, G., WARLAND, J., “Quick Simulation of ATM Buffers with On-off Multiclass Markov Fluid Sources”, ACM TOMACS, 3, pp. 267-276, Julho 1993. [24] REID, K. L., BUNT, R. B., “An Analysis of Space Priority Queueing in ATM Switches”, MASCOTS, 1994. [25] LAO, A. Y., “Heterogeneous Cell-Relay Network Simulation and Performance Analysis with Ptolemy”, Memorandum No. UCB/ERL M94/8, Electronics Research Laboratory, College of Engineering University of California, Berkeley, CA 94720, Fevereiro 1994. [26] BATHT, S., FUJIMOTO, R., OGIELSKI, A., PERUMALLA, K., “Parallel Simulation Techniques for Large-Scale Networks”, IEEE Communications Magazine, August 1998. 32
  • [27] SACKETT, G. C., METZ, C., “ATM and Multiprotocol Networking”, McGraw Hill, January 1997. [28] TOWNSEND, J. K., HARATZI, Z., FREEBERSYSER, J. A., DEVETSIKIOTIS, M., “Simulation of Rare Events in Communications Networks”, IEEE Communications Magazine, Agosto 1998. [29] DEVETSIKIOTIS, M., FREEBERSYSER, J., TOWNSEND, J. K., “Efficient Simulation of High-Speed Networks Using Importance Sampling and Stochastic Gradient Techniques”, Proc. IEEE GLOBECOM’94, San Francisco, CA, Novembro 1994. [30] STROUSTRUP, B., “The C++ Programming Language”, Addison-Wesley, Terceira Edição, 1997. [31] BHATT, S., FUJIMOTO, R., OGIELSKI, A., PERUMALLA, K., “Parallel Simulation Techniques for Large-Scale Networks”, IEEE Communications Magazine, Agosto 1998. [32] KUMARAN, K., MITRA, D., “Performance and Fluid Simulation of a Novel Shared Buffer Management System”, IEEE INFOCOM’98, 1998. [33] KESIDIS, G., SINGH, A., CHEUNG, D., KWOK, W.W., “Feasibility of Fluid Event-Driven Simulation for ATM Networks”, IEEE GLOBECOM ’96, 1996. [34] HEEGAARD, P. E., “Speedup Simulation Techniques”, Workshop Tutorial on Rare Event Simulation, Agosto 1997. [35] YAN, A., “On Some Modeling Issues in High Speed Networks”, PhD Thesis, Department of Electrical and Computer Engineering, University of Massachusetts Amherst, Fevereiro 1998. [36] KESIDIS, G., SINGH, A., “An Overview of Cell-Level ATM Network Simulation”, HPCS’95, 1995. [37] YAN, A., “On Some Modeling Issues in High Speed Networks”, PhD Thesis, Department of Electrical and Computer Engineering, University of Massachusetts Amherst, Fevereiro 1998. 33
  • [38] YAN, A., GONG, W., “Fluid Simulation for High Speed Networks”, Proceedings of the 15th International Teletraffic Congress, Washington, Junho 1997. [39] DEVETSIKIOTIS, M., AL-QAQ, W., FREEBERSYSER, J., TOWNSEND, J.K.,“Fast Simulation of Queueing Networks Using Stochastic Gradient Techniques and Importance Sampling”, IEEE/ACM Transactions on Networking, Março 1995. [40] AKYAMAÇ, A., TOWNSEND, J. K., “Conditional Importance Sampling and its Application to ATM Switch Analysis”, Technical Report TR- 97/17, 1997. [41] HARASATI, Z., TOWNSEND, J. K., “The Theory of Direct Probability Redistribution and its Application to Rare Event Simulation”, Proceedings of IEEE ICC'98, 1998. [42] HEEGAARD, P. E., “Speedup Simulation Techniques”, Workshop Tutorial on Rare Event Simulation, Agosto 1997. 34
  • Capítulo 3 Ambiente de Simulação 3.1 - Introdução Em 1996, devido ao crescente interesse pela tecnologia ATM, surgiu no Departamento de Comunicações (DECOM) da Faculdade de Engenharia Elétrica e de Computação (FEEC) da Unicamp a necessidade de se ter a disposição uma ferramenta para a simulação computacional de redes ATM. Tal ferramenta seria utilizada no aprendizado, pesquisa, análise e projeto de redes ATM, bem como na validação de novos algoritmos e mecanismos de gerenciamento de tráfego para estas redes. Visando atender a esta necessidade, inicialmente considerou-se o desenvolvimento desta ferramenta como um conjunto de modelos para um ambiente de simulação chamado SimNT1 [1][2][3][4]. O SimNT é um ambiente de simulação voltado para a análise de dispositivos e de sistemas de comunicações em geral, que vem sendo desenvolvido no DECOM/FEEC/UNICAMP desde 1993, onde tem sido aplicado principalmente na simulação de dispositivos e sistemas ópticos. Entretanto, o SimNT emprega a técnica de simulação data-driven (veja a seção 2.2.2.3.2), que, como vimos, é menos indicada para a simulação de redes ATM do que a técnica event-driven (veja a seção 2.2.2.3.3). Assim sendo, em 1996 iniciamos o desenvolvimento de um novo ambiente de simulação que utilizasse a técnica event-driven e que fosse semelhante ao SimNT, porém voltado para a simulação de redes ATM. Este ambiente de simulação foi chamado de SimATM2 [5][6][7]. Assim como o SimNT, o SimATM foi desenvolvido em linguagem de programação C++ [8] e voltado para o sistema operacional WindowsTM. Em 1998, a versão 0.61 do SimATM foi concluída. Esta versão possuía um único conjunto de modelos desenvolvidos utilizando-se a estratégia de modelamento no nível de células (veja a seção 2.3.4.1). Tanto o kernel do SimATM v0.61, quanto os seus modelos eram compilados em um único programa executável (.exe). Portanto, para modificar os 1 O SimNT versão 1.0 foi apresentado pelo colega Jackson Klein a FEEC/UNICAMP como parte integrante dos pré- requisitos necessários para a obtenção do título de Doutor em Engenharia Elétrica. 2 O SimATM versão 0.61 foi apresentado por Antônio Marcos Alberti a FEEC/UNICAMP como parte integrante dos pré- requisitos necessários para a obtenção do título de Mestre em Engenharia Elétrica. 35
  • modelos era necessário recompilar todo o simulador. O SimATM v0.61 não possuía interface gráfica. Somente uma interface em modo caractere foi desenvolvida. A partir de 1998, uma nova versão do SimATM começou a ser desenvolvida no DECOM/FEEC/UNICAMP com o nome de Hydragyrum3 [9][10][11][12]. Esta nova versão trouxe várias melhorias para o ambiente de simulação. Entre elas podemos citar: o desenvolvimento de uma interface gráfica; o desenvolvimento de uma estrutura hierárquica para os modelos; o desenvolvimento de uma biblioteca de modelos expansível separada do kernel do simulador; o desenvolvimento de uma estrutura hierárquica de conexões; e finalmente, o desenvolvimento de uma nova dinâmica de funcionamento (novas funções de comportamento) para o ambiente de simulação. Esta nova dinâmica possibilita aos modelos responderem a situações não previstas no SimATM v0.61, como por exemplo durante a fase de troca de valor de um determinado parâmetro (veja a seção A.2.1.3 do Apêndice A). Devido a estas importantes melhorias e a disponibilidade deste ambiente de simulação no DECOM/FEEC/UNICAMP, em 1998 resolvemos utilizar o Hydragyrum para o desenvolvimento deste trabalho. Assim sendo, neste capítulo descreveremos este ambiente de simulação. 3.2 - Estrutura A estrutura do Hydragyrum versão 1.0 pode ser dividida em duas partes principais (Figura 3.1): programa executável e biblioteca de modelos. O programa executável é a parte principal do Hydragyrum. Ele possui uma instância do kernel (ou núcleo) do simulador. O Hydragyrum disponibiliza dois programas executáveis: um com interface em modo caractere e outro com interface gráfica. A biblioteca de modelos é o conjunto de todos os modelos que podem ser utilizados para construir uma rede a ser simulada. No Hydragyrum os modelos e o kernel são implementados como bibliotecas de ligação dinâmica do sistema operacional WindowsTM (DLLs – Dynamic Link Libraries) [8]. Toda a estrutura do simulador foi desenvolvida utilizando-se a linguagem de programação C++ [8], o que permite, portanto, usufruir das vantagens da programação orientada a objetos (OOP – Object Oriented Programming). A dll do kernel e a biblioteca de modelos foram desenvolvidos utilizando-se o Borland C++ 5.02TM enquanto o programa executável com interface gráfica foi desenvolvido utilizando-se o Borland C++ Builder 3.0TM. Na implementação do Hydragyrum foram utilizados 3 O Hydragyrum versão 1.0 foi apresentado pelo colega Ernesto Luis Andrade Neto a FEEC/UNICAMP como parte integrante dos pré-requisitos necessários para a obtenção do título de Doutor em Engenharia Elétrica. 36
  • recursos avançados da linguagem C++, tais como [8]: encapsulamento, herança múltipla, polimorfismo, friends, sobrecarga de operadores e templates. A utilização destes recursos permitiu a implementação da estrutura do simulador de forma modular e hierárquica. Usuário Hydragyrum v1.0 Programa Executável Biblioteca de (.exe) Modelos Modelo (.dll) Kernel Modelo 2 (.dll) (.dll) Modelo N (.dll) Figura 3.1 – Estrutura do Hydragyrum. 3.2.1 - Programa Executável Como vimos, o Hydragyrum disponibiliza dois programas executáveis: um com interface em modo caractere (Figura 3.2) e outro com interface gráfica (Figura 3.3). Ambos os programas foram desenvolvidos a partir da dll do kernel. A seguir apresentaremos em maiores detalhes a estrutura e o funcionamento desta dll. Figura 3.2 – Programa executável com interface em modo caractere. 37
  • Figura 3.3 – Programa executável com interface gráfica. 3.2.2 - Biblioteca de Modelos Um dos principais recursos do Hydragyrum é permitir que os seus usuários implementem e incorporem novos modelos à biblioteca do ambiente de simulação. Para tanto, os modelos do Hydragyrum são implementados como bibliotecas de ligação dinâmica do WindowsTM (dlls). Além deste recurso, o Hydragyrum possibilita ainda o modelamento hierárquico dos componentes de uma rede de comunicações, ou seja, a construção de modelos a partir de outros modelos internos, tais como camadas e gerenciadores de tráfego. A Figura 3.4 ilustra a estrutura hierárquica dos modelos do Hydragyrum. Esta estrutura se baseia em três classes base: Block, Layer e Squeue. As classes Layer e Squeue constituem um primeiro nível desta estrutura hierárquica, enquanto a classe Block constitui um segundo nível. Portanto, no Hydragyrum os modelos são construídos a partir da derivação das classes base Block, Layer e Squeue. Os modelos derivados destas três classes base são chamados de blocos, camadas e gerenciadores de tráfego. Assim sendo, os blocos podem ou não possuir várias camadas e gerenciadores de tráfego, que chamaremos de modelos internos de um bloco. 38
  • Bloco Camadas Gerenciadores de Tráfego layer squeue Camada 1 Gerenciador 1 Camada n Gerenciador n block Figura 3.4 – Estrutura hierárquica de modelos no Hydragyrum. A criação de modelos através do recurso de herança do C++ [8] permite que um modelo herde a interface com o kernel e outras funcionalidades de sua classe base. Isto facilita bastante o desenvolvimento de novos modelos, uma vez que o programador pode se concentrar no projeto e implementação das peculiaridades destes modelos. É importante observar aqui, que somente os blocos constituem a biblioteca de modelos do simulador, uma vez que somente eles são ligados como dlls. As camadas e gerenciadores de tráfego não são dlls e, portanto, fazem parte indiretamente desta biblioteca como modelos internos dos blocos. Os blocos podem ser utilizados para modelar os principais elementos de uma rede como, por exemplo: equipamentos, aplicativos, gerentes, etc. As camadas podem ser utilizadas para modelar conjuntos de protocolos e funções. Várias camadas podem ser utilizadas para modelar pilhas de protocolos, como por exemplo a pilha de protocolos do modelo de referência da B-ISDN [1][13]. Os gerenciadores de tráfego podem ser utilizados para modelar sistemas de processamento de pacotes, células ATM, etc. Exemplos destes sistemas são: estrutura de filas, escalonadores, algoritmos de gerenciamento de tráfego. Os modelos do Hydragyrum podem se comunicar através de eventos ou das estruturas de dados e funções comuns providas pelo kernel. A estrutura modular do Hydragyrum permite a definição de vários conjuntos de modelos, cada qual voltado para resolver um problema específico ou com diferentes níveis de detalhamento. Um conjunto de modelos é definido no contexto do ambiente de simulação como sendo um grupo de modelos que compreendem e trocam eventos e mensagens comuns, e ainda prevêem diferentes níveis de conexões entre si. Para assegurar a funcionamento adequado de um conjunto de modelos, vários mecanismos de segurança foram implementados pelo kernel, a fim de evitar a conexão e a inserção de modelos que não pertencem a um mesmo conjunto. Isto evita o mal funcionamento ou a “derrubada” do ambiente de simulação quando um usuário tenta 39
  • conectar modelos ou executar simulações incompatíveis. Entretanto, é possível construir conjuntos de modelos compatíveis entre si, ou até mesmos modelos que possam ser utilizados em mais de um conjunto. No Apêndice A é feita uma descrição detalhada do ambiente de simulação Hydragyrum, incluindo a estrutura dos blocos, camadas e gerenciadores de tráfego. 3.3 - Referências Bibliográficas [1] KLEIN, J., “SIMNT – Uma Ferramenta para a Simulação de Sistemas de Comunicação”, Tese de Mestrado, Faculdade de Engenharia Elétrica e de Computação, UNICAMP, Orientador: Prof. Dr. Leonardo S. Mendes, Agosto 1995. [2] KLEIN, J., “Desenvolvimento de uma Ferramenta CAD/CAM para Simulação, Projeto e Ensino de Sistemas de Comunicação”, Tese de Doutorado, Faculdade de Engenharia Elétrica e de Computação, UNICAMP, Orientador: Prof. Dr. Leonardo S. Mendes, Março 1999. [3] RIBEIRO, M. R. N., WALDMAN, H., KLEIN, J., MENDES, L. S., “Error Rate Patterns for Modeling of Optically Amplified Transmission Systems”, IEEE Journal on Selected Areas in Communications, Vol. 15, No. 4, Maio 1998. [4] http://www.mc21.fee.unicamp.br/SimNT/ [5] ALBERTI, A. M., “SimATM: Um Ambiente para a Simulação de Redes ATM”, Tese de Mestrado, Faculdade de Engenharia Elétrica e de Computação, UNICAMP, Orientador: Prof. Dr. Leonardo S. Mendes, Abril 1998. [6] ALBERTI, A. M., ANDRADE NETO, E. L., KLEIN, J., MENDES, L. S., “SimATM: An ATM Network Simulation Environment”, 7TH IEEE CAMAD workshop, São Paulo, 1998. O trabalho não consta dos anais, pois foi convidado para substituir um trabalho ausente. [7] http://www.mc21.fee.unicamp.br/SimATM/ [8] STROUSTRUP, B., “The C++ Programming Language”, Third Edition, Addison-Wesley, 1997. 40
  • [9] ANDRADE NETO, E. L., “Ambiente de Simulação de Redes a Eventos Discretos”, Tese de Doutorado, Faculdade de Engenharia Elétrica e de Computação, UNICAMP, Orientador: Prof. Dr. Leonardo S. Mendes, Setembro 2001. [10] ANDRADE NETO, E. L., ALBERTI, A. M., “Hydragyrum – Ambiente de Simulações de Redes a Eventos Discretos”, SBrT´2000, Setembro 2000. [11] ANDRADE NETO, E. L., “Hydragyrum Network Simulation Environment Programming Manual 1.0”, Dezembro 1999. [12] http://www.mc21.fee.unicamp.br/Hydragyrum/ [13] SACKETT, G. C., METZ, C., “ATM and Multiprotocol Networking”, McGraw Hill, January 1997. 41
  • Página deixada em branco intencionalmente. 42
  • Capítulo 4 Conjunto de Modelos no Nível de Células (CMNC) 4.1 - Introdução No Capítulo 2 identificamos os aspectos que consideramos mais importantes para o desenvolvimento de uma ferramenta de simulação de redes ATM. Uma vez identificados estes aspectos, percebemos que este trabalho poderia tomar várias direções possíveis, dependendo principalmente da estratégia de modelamento adotada. Neste ponto, portanto, precisamos decidir qual seria esta estratégia. Ainda no Capítulo 2, observamos que a melhor estratégia de modelamento a ser utilizada quando se está interessado em estudar um conjunto amplo de problemas é aquela que melhor otimiza a relação entre o nível de detalhamento dos modelos e a eficiência da simulação. Dentre as estratégias de modelamento descritas no Capítulo 2, verificamos que o modelamento no nível de taxas era o mais promissor, uma vez ele era mais eficiente e flexível que os demais. Entretanto, após estudarmos alguns trabalhos que envolviam a simulação de redes ATM [1][2][3][4][5][6], observamos que o modelamento fluído não permitia que certos aspectos importantes da tecnologia ATM fossem analisados adequadamente como, por exemplo, a estimação do atraso de transmissão de células (CTD – Cell Transfer Delay) e da variação de atraso de células (CDV – Cell Delay Variation). Diante deste fato, na época, resolvemos dividir nosso trabalho na construção de dois conjuntos de modelos para a simulação de redes ATM: um no nível de células (CMNC – Conjunto de Modelos no Nível de Células) e outro fluído (CMNT – Conjunto de Modelos no Nível de Taxas). A idéia era de que no final do nosso trabalho pudéssemos comparar as vantagens e as desvantagens de cada uma destas estratégias. Entretanto, o desenvolvimento do conjunto de modelos no nível de células e a realização de outras atividades necessárias para avaliar os modelos desenvolvidos (que serão apresentadas nos próximos capítulos), tais como a escolha de cenários de simulação, a configuração de contratos de tráfego ATM, a obtenção de seqüências de tráfego para simulação e a adaptação destas seqüências para a transmissão em redes ATM, acabaram consumindo um tempo muito maior do que o imaginado. Além disto, baseado na experiência que obtivemos durante o 43
  • desenvolvimento do CMNC, observamos que o tempo necessário para desenvolver o conjunto de modelos no nível de taxas seria ainda maior, uma vez que os modelos no nível de taxas são muito mais complexos do que os modelos no nível de células, e geralmente dependem do desenvolvimento de um sofisticado equacionamento matemático. Neste capítulo descreveremos a estrutura e os modelos do CMNC. Iniciaremos fazendo uma descrição da estrutura do conjunto de modelos. Em seguida, apresentaremos os modelos desenvolvidos. No final do capítulo, descreveremos o funcionamento integrado destes modelos. 4.2 - Estrutura A estrutura do CMNC é baseada em quatro blocos: aplicativo (App – Application), terminal faixa larga (BTE – Broadband Terminal Equipment), comutador (SW – Switch) e gerente (Managers). A Figura 4.1 ilustra esta estrutura. Estes blocos são interconectados entre si através de conexões de blocos para formar a topologia da rede ATM a ser simulada. Com exceção do bloco gerente, todos os outros blocos possuem camadas, que são utilizadas para modelar o Modelo de Referência de Protocolos da B-ISDN [7][8]. Além destas camadas, os blocos terminal faixa larga e comutador possuem ainda vários gerenciadores de tráfego, que são utilizados para modelar as funções de gerenciamento de tráfego ATM [9]. Os blocos aplicativos são responsáveis pela requisição, criação e deleção de conexões chaveadas ATM (SVCs – Switched Virtual Connections) [7][8] e pela transmissão de tráfego de pacotes através da rede ATM. Para tanto, possuem quatro camadas: camada requerente e removedora de conexões, camada finalizadora de conexões, camada fonte de tráfego e camada receptora de tráfego. O conjunto de modelos no nível de células possui quatro modelos de aplicativos: determinístico, poissoniano, externo e receptor. 44
  • Gerenciadores Aplicativo Gerente de Tráfego Camadas Camada Requeredora e Removedora de Conexões Sentido da transmissão de dados na rede. Camada Finalizadora de Conexões Comutador Camada Fonte de Tráfego Controle de Admissão Matriz de de Conexões Comutação com Memória Camada Receptora de Tráfego Compartilhada Gerencimento de Estrutura de Filas Descarte Seletivo de Células Terminal Faixa Larga Escalonador Estrutura de Fila Camada de Adaptação ATM Escalonador Camada ATM Camada ATM Camada Física de Camada Física de Camada Física de Camada Física de Entrada Saída Entrada Saída Estrutura de Fila Estrutura de Fila Estrutura de Fila Escalonador Escalonador Escalonador Controle de Admissão Controle de Admissão Controle de Admissão de Conexões de Conexões de Conexões Gerencimento de Gerencimento de Gerencimento de Estrutura de Filas Estrutura de Filas Estrutura de Filas Descarte Seletivo Descarte Seletivo Descarte Seletivo de Células de Células de Células Policiamento de Policiamento de Policiamento de Tráfego Tráfego Tráfego Figura 4.1 – Estrutura do conjunto de modelos no nível de células. O bloco terminal faixa larga modela um dispositivo de borda da rede ATM, como por exemplo, um cartão de interface de rede (NIC – Network Interface Card). Este modelo possui quatro camadas: camada de adaptação ATM, camada ATM, camada física de entrada e camada física de saída. Estas camadas modelam respectivamente as camadas: AAL, ATM e física do Modelo de Referência de Protocolos da B-ISDN. Além destas camadas, o BTE possui seis gerenciadores de tráfego que implementam os seguintes modelos de algoritmos de gerenciamento de tráfego ATM: estruturas de filas, escalonadores, algoritmos de controle de admissão de conexões, algoritmos de gerenciamento de estruturas de filas, algoritmos de descarte seletivo de células e algoritmos de policiamento de tráfego. O bloco comutador modela um dispositivo de comutação de células ATM. Este modelo possui três camadas: camada ATM, camada física de entrada e camada física de saída, que modelam respectivamente as camadas: ATM e física do Modelo de Referência de Protocolos da B- 45
  • ISDN. Além destas camadas, o comutador ATM possui seis gerenciadores de tráfego que implementam os mesmos modelos de algoritmos de gerenciamento de tráfego existentes no BTE. O bloco gerente modela o plano de controle do Modelo de Referência de Protocolos da B- ISDN. Este bloco não possui camadas e gerenciadores de tráfego. Além destes blocos, camadas e gerenciadores de tráfego, a estrutura do CMNC possui ainda outros componentes que foram desenvolvidos com o objetivo de tornar o conjunto de modelos ainda mais eficiente, prático e robusto. São eles: mensagens, estruturas de dados auxiliares e objetos auxiliares. A partir da próxima seção apresentaremos todos os componentes da estrutura do CMNC, para que finalmente na seção 4.9 - possamos discutir por completo o funcionamento do conjunto de modelos desenvolvido. Dividiremos esta apresentação de acordo com os seguintes tópicos: Mensagens Estruturas de Dados Auxiliares Objetos Auxiliares Camadas Gerenciadores de Tráfego Blocos 4.3 - Mensagens Veremos no Apêndice A todos os dados trocados entre os modelos através de eventos no Hydragyrum devem ser definidos como mensagens. Em nosso conjunto de modelos construímos seis mensagens derivadas da classe base Smessage. São elas: Pacote (Packet) Célula ATM (Cell) Contrato de Tráfego (Traffic Contract) Ficha (Token) Mensagem de Gerenciamento de Tráfego (TM_Message – Traffic Management Message) Mensagem de Roteamento (RT_Message – Routing Message) As mensagens Pacote, Célula e Ficha formam uma hierarquia que é utilizada para modelar a fase de transmissão de dados na rede ATM (veja a Figura 4.2). A Figura 4.2a mostra o processo real 46
  • de segmentção de um pacote de camada superior em duas células ATM. O conteúdo do pacote é transferido para as células ATM. Na Figura 4.2b é mostrado o modelo utilizado neste trabalho, no qual o conteúdo de um pacote não é passado para as células ATM. Ao invés disso, somente uma indicação do tamanho do pacote é informado. A identificação de qual pacote deu origem a quais células é feita através do uso de ponteiros. Portanto, toda estrutura de dados que representa uma célula ATM no simulador possui um ponteiro que permite identificar qual é o pacote que deu origem a esta célula. Além da célula ATM, também utilizou-se neste trabalho uma outra estrutura de dados chamada de ficha. A ficha é utilizada como uma espécie de “procurador” das células ATM, representando as mesmas quando estas são armazenadas em estruturas de filas e escalonadores (veja o final da seção 4.6.6.2 - ). As fichas também possuem ponteiros para identificar qual célula está sendo representada. A utilização de ponteiros permite o acesso rápido as informações, reduzindo o uso de memória. Os campos de informação presentes no Pacote, Célula e Ficha serão explicados nas subseções a seguir. Pacote Pacote Campos de Informação Ponteiro Célula ATM Campos de para um Informação Pacote Célula Ponteiro Célula ATM Campos de para um Informação Pacote Célula Ponteiro Ponteiro Campos de Campos de para uma para uma Informação Informação Célula Célula Ficha Ficha a) Segmentação de pacotes em células ATM no mundo real. b) Modelo utilizado neste trabalho. Figura 4.2 – Hierarquia de objetos utilizada para modelar a fase de transmissão de dados na rede ATM. As mensagens de Gerenciamento de Tráfego e de Roteamento são usadas para modelar a fase de estabelecimento de conexões na rede. 4.3.1 - Pacote A estrutura de dados pacote é uma abstração de uma unidade de dados de protocolo (PDU – Protocol Data Unit) [7][8] das camadas superiores à camada ATM. É utilizado para transportar 47
  • dados entre aplicativos na rede. Cada pacote é associado a uma determinada conexão de dados e de rede. A Figura 4.3 mostra a estrutura do pacote do CMNC. Birth Time Length NCI DCI EoT FLAG NoC NoDC NoRC PDAM Figura 4.3 – Estrutura do pacote. O pacote possui os seguintes campos de informação: Birth Time (Tempo de Criação) – Este campo define o tempo em que o pacote foi criado. Length (Tamanho) – Este campo define o tamanho do pacote (em bytes). NCI (Network Connection Identifier) (Identificador de Conexão de Rede) – Este campo identifica a que conexão de rede o pacote pertence, ou seja, qual é a conexão ATM que está carregando as células do pacote. DCI (Data Connection Identifier) (Identificador de Conexão de Dados) – Este campo identifica a que conexão de dados o pacote pertence. EoT FLAG (End of Transmition Flag) (Flag de Final de Transmissão) – Este indicador (flag) identifica se este pacote é o último pacote a ser transmitido em uma conexão de rede antes da sua remoção. NoC (Number of Cells) (Número de Células) – Este campo contém o número de células em que o pacote foi fragmentado pela camada de adaptação ATM. NoDC (Number of Dropped Cells) (Número de Células Perdidas) – Este campo contém o número de células ATM perdidas durante o trânsito do pacote na rede. Toda vez que uma célula ATM é perdida na rede, o ponteiro que esta célula possui para o pacote que lhe deu origem é utilizado para incrementar este campo, computando a perda de células do pacote. NoRC (Number of Received Cells) (Número de Células Recebidas) – Este campo contém o número de células recebidas ao final do trânsito do pacote na rede. É utilizado da mesma forma que o campo anterior, porém para computar as células recebidas com sucesso. PDAM (Pointer to Dynamic Allocation Manager) (Identificador do Gerente de Alocação Dinâmica) – Este campo contém um ponteiro para o objeto auxiliar gerente de alocação 48
  • dinâmica. Isto permite que o pacote seja deletado e removido da lista de pacotes do gerente de alocação dinâmica. O objeto pacote é implementado na classe Packet. 4.3.2 - Célula ATM A célula ATM é uma PDU de 53 bytes [7][8]. É utilizada para transportar fragmentos de pacotes, que são segmentados na camada de adaptação ATM (AAL – ATM Adaptation Layer). Cada célula é associada a um determinado pacote. Portanto, é possível identificar através deste pacote a conexão de dados e de rede a que a célula pertence. A Figura 4.4 mostra a estrutura da célula ATM do CMNC, que possui os seguintes campos de informação: Birth_Time (Tempo de Criação) – Este campo armazena o instante de tempo em que a célula ATM foi criada. É utilizado para calcular o tempo gasto para transportar a célula desde o ingresso até o egresso da rede ATM. PTI (Payload Type Identifier) (Identificador de Tipo de Carga) – Este campo identifica o tipo de informação que a célula está transportando. CLP (Cell Loss Priority) (Prioridade de Perda de Células) – Este campo identifica a prioridade de descarte da célula. PPacket (Identificador do Pacote de Origem) – Este campo contém um ponteiro para o pacote que deu origem à célula. PDAM (Pointer to Dynamic Allocation Manager) (Identificador do Gerente de Alocação Dinâmica) – Este campo contém um ponteiro para o objeto auxiliar gerente de alocação dinâmica. Isto permite que a célula seja deletada e removida da lista de células do gerente de alocação dinâmica. Birth Time PTI CLP EoP FLAG PPacket PDAM Figura 4.4 – Estrutura da célula ATM. A célula ATM do CMNC possui apenas dois campos do cabeçalho da célula ATM original [8]: PTI (Payload Type Identifier) e CLP (Cell Loss Priority). O campo de carga útil da célula ATM (payload) não foi implementado. Entretanto, é possível saber que informações estão sendo carregadas em cada célula através do campo PPacket, que aponta para o pacote que fora 49
  • previamente segmentado. A célula ATM implementada no Hydragyrum também não possui os identificadores de conexão virtual de caminho (VPI – Virtual Path Identifier) e de canal (VCI – Virtual Channel Identifier) existentes no cabeçalho da célula ATM original. Estes campos foram agrupados em um único campo chamado NCI – Network Connection Identifier. 4.3.3 - Contrato de Tráfego Esta mensagem implementa um modelo para o contrato de tráfego definido pelo ATM Forum na especificação TM 4.0 – Traffic Management Specification [10]. Atualmente, o modelo de contrato de tráfego possui apenas as informações necessárias para o estabelecimento de conexões ATM unidirecionais. A Figura 4.5 mostra a estrutura do contrato de tráfego do CMNC, que possui os seguintes campos de informação: Service_Categorie (Categoria de Serviço) – Categoria de serviço do contrato de tráfego. CLR (Cell Loss Ratio) (Taxa de Perda de Células) – Parâmetro negociável de qualidade de serviço. Presente nos contratos de tráfego das categorias: CBR – Constant Bit Rate, RT-VBR – Real Time Variable Bit Rate e NRT-VBR – Non-real Time Variable Bit Rate. Max CTD (Maximum Cell Transfer Delay) (Máximo Atraso de Transferência) – Parâmetro negociável de qualidade de serviço. Presente nos contratos de tráfego das categorias CBR e RT-VBR. P2P CDV (Peak-to-peak Cell Delay Variation) (Variação de Atraso de Célula Pico-a- pico) – Parâmetro negociável de qualidade de serviço. Presente nos contratos de tráfego das categorias CBR e RT-VBR. PCR (Peak Cell Rate) (Taxa de Pico de Células) – Descritor de tráfego da fonte. Presente no contrato de tráfego de todas as categorias de serviço. SCR (Sustainable Cell Rate) (Taxa Sustentável de Células) – Descritor de tráfego da fonte. Presente nos contratos de tráfego das categorias RT-VBR e NRT-VBR. MBS (Maximum Burst Size) (Máximo Tamanho de Surto) – Descritor de tráfego da fonte. Presente nos contratos de tráfego das categorias RT-VBR e NRT-VBR. MCR (Minimum Cell Rate) (Taxa Mínima de Células) – Descritor de tráfego da fonte. Presente no contrato de tráfego da categoria ABR – Available Bit Rate. Conformance Definition (Definição de Conformidade) – Definição de conformidade do contrato de tráfego. 50
  • PDAM (Pointer to Dynamic Allocation Manager) (Identificador do Gerente de Alocação Dinâmica) – Este campo contém um ponteiro para o objeto auxiliar gerente de alocação dinâmica. Isto permite que o contrato de tráfego seja deletado e removido da lista de contrato de tráfegos do gerente de alocação dinâmica. Service Conformance CLR Max CTD P2P CDV PCR SCR MBS PDAM Categorie Definition Figura 4.5 – Estrutura do contrato de tráfego. 4.3.4 - Ficha A ficha é utilizada para “guardar a vez” de uma célula em uma fila com prioridades. Ou seja, ao invés de armazenarmos diretamente as células ATM nas filas com prioridades, são armazenadas fichas, que apontam através de ponteiros para estas células. A principal razão para isto é que muitas vezes uma célula ATM precisa ser encaminhada para mais de uma fila com prioridades. Então ao invés de duplicar o objeto célula para que este seja encaminhado para cada fila, são alocadas fichas que representam esta célula em cada fila com prioridades. Um exemplo em que esta situação ocorre, é quando uma célula ATM precisa ser armazenada tanto na fila com prioridades de um gerenciador de tráfego que modela uma estrutura de filas (veja a seção 4.7.1 - ) quanto na fila com prioridades de um gerenciador de tráfego que modela um escalonador (veja a seção 4.7.2 - ). A Figura 4.6 mostra a estrutura da ficha do CMNC, que possui os seguintes campos de informação: Birth Time (Tempo de Criação) – Este campo contém o instante de tempo em que a ficha foi criada. PCell (Pointer to a Cell) (Identificador da Célula Associada) – Este campo identifica a qual célula a ficha está associada. PDAM (Pointer to Dynamic Allocation Manager) (Identificador do Gerente de Alocação Dinâmica) – Este campo contém um ponteiro para o gerente de alocação dinâmica. Isto permite que a ficha seja deletada e removida da lista de fichas do gerente de alocação dinâmica. Birth Time PCell PDAM Figura 4.6 – Estrutura das fichas. 51
  • 4.3.5 - Mensagem de Gerenciamento de Tráfego Esta mensagem é utilizada para a troca de informações de gerenciamento de tráfego entre blocos, camadas e gerenciadores de tráfego. Possibilita informar aos algoritmos de gerenciamento de tráfego as conexões de blocos, conexões de rede e conexões de dados de uma determinada célula a ser processada, bem como informar às camadas adequadas a respeito das células marcadas para serem descartadas. Permite também informar qual foi o contrato de tráfego negociado com a rede. A Figura 4.7 mostra a estrutura da mensagem de gerenciamento de tráfego do CMNC, que possui os seguintes campos: BCI (Identificador de Conexão de Blocos) – Este campo identifica a conexão de blocos de interesse. NCI (Identificador de Conexão de Rede) – Este campo identifica a conexão de rede de interesse. DCI (Identificador de Conexão de Dados) – Este campo identifica a conexão de dados de interesse. PCell (Pointer to a Cell) (Identificador da Célula Associada) – Este campo identifica a célula a ser utilizada pelos modelos de gerenciamento de estruturas de filas e de descarte seletivo. PTC (Pointer to a Traffic Contract) (Identificador de Contrato de Tráfego) – Este campo identifica o contrato de tráfego a ser utilizado pelos modelos de controle de admissão de conexões. PCells_Vector (Pointer to a Cells Vector) (Identificador de Vetor de Células a serem Descartadas) – Este campo identifica um vetor de células na qual devem ser inseridas as células a serem descartadas pelos modelos de descarte seletivo de células. PDAM (Pointer to Dynamic Allocation Manager) (Identificador do Gerente de Alocação Dinâmica) – Este campo contém um ponteiro para o objeto auxiliar gerente de alocação dinâmica. Isto permite que a mensagem de gerenciamento de tráfego seja deletada pelo gerente de alocação dinâmica. PCells BCI NCI DCI PCell PTC PDAM Vector Figura 4.7 – Estrutura das mensagens de gerenciamento de tráfego. 52
  • 4.3.6 - Mensagem de Roteamento Esta mensagem é utilizada para a troca de informações de roteamento entre as camadas do bloco aplicativo e o bloco gerente. A Figura 4.8 mostra a estrutura da mensagem de roteamento do CMNC, que possui os seguintes campos de informação: Source_App (Source Application) (Aplicativo Fonte) – Este campo identifica o aplicativo fonte da conexão de dados a ser estabelecida. Source_Layer (Source Layer) (Camada Fonte) – Este campo identifica a camada fonte da conexão de dados a ser estabelecida. Destiny_App (Destiny Application) (Aplicativo de Destino) – Este campo identifica o aplicativo de destino da conexão de dados a ser estabelecida. Destiny_Layer (Destiny Layer) (Camada de Destino) – Este campo identifica a camada de destino da conexão de dados a ser estabelecida. PTC (Pointer to a Traffic Contract) (Identificador de Contrato de Tráfego) – Este campo identifica o contrato de tráfego a ser utilizado pelos modelos de controle de admissão de conexões. Através deste ponteiro é possível acessar todas as informações contidas no contrato de tráfego. NCI (Identificador de Conexão de Rede) – Este campo identifica a conexão de rede a ser removida, uma vez que esta mensagem também é utilizada para encerrar conexões. DCI (Identificador de Conexão de Dados) – Este campo identifica a conexão de dados a ser removida, uma vez que esta mensagem também é utilizada para encerrar conexões. PDAM (Pointer to Dynamic Allocation Manager) (Identificador do Gerente de Alocação Dinâmica) – Este campo contém um ponteiro para o modelo auxiliar gerente de alocação dinâmica. Isto permite que a mensagem de roteamento seja deletada pelo gerente de alocação dinâmica. Source Source Destiny Destiny PTC NCI DCI PDAM App Layer App Layer Figura 4.8 – Estrutura das mensagens de roteamento. 53
  • 4.4 - Estruturas de Dados Auxiliares Estruturas de dados auxiliares são utilizadas para guardar informações que serão utilizadas nos objetos auxiliares (veja a próxima seção). O CMNC possui três estruturas de dados auxiliares: variável estatística simples, variável estatística média e arquivo. 4.4.1 - Variável Estatística Simples A variável estatística simples é uma estrutura de dados utilizada para armazenar uma variável estatística de um determinado modelo. Uma variável estatística é um dado público ou privado de uma classe cujo valor é relevante para representar a evolução do comportamento de um determinado modelo no tempo. A Figura 4.9 mostra a estrutura da variável estatística simples, que possui os seguintes campos de informação: Type (Tipo) – Este campo contém o tipo da variável estatística (Sstring). Value (Valor) – Este campo contém o valor da variável estatística (double). Type Value Figura 4.9 – Estrutura das variáveis estatística simples. 4.4.2 - Variável Estatística Média A variável estatística média é um uma estrutura de dados utilizada para armazenar uma variável estatística média de um modelo. Uma variável estatística média é um dado público ou privado de uma classe cujo valor é relevante para representar a evolução média do comportamento de um determinado modelo no tempo. A Figura 4.10 mostra a estrutura da variável estatística média, que possui os seguintes campos de informação: Type (Tipo) – Este campo contém o tipo da variável (Sstring). S1 (Soma das Amostras) – Este campo contém a soma de todas as amostras da variável. t 1 (Tempo da Amostra Anterior) – Este campo contém o instante de tempo em foi feita a última amostra. Só é utilizado se a variável for ponderada. v 1 (Valor da Amostra Anterior) – Este campo contém o último valor amostrado da variável. Só é utilizado se a variável se a média for ponderada. Mean (Média) – Este campo contém o valor da variável. 54
  • Samples_Number (Número de Amostras) – Este campo contém o número de amostras feitas. Samples Type S1 t_1 v_1 Mean Number Figura 4.10 – Estrutura das variáveis estatística médias. 4.4.3 - Arquivo O arquivo é um objeto derivado da classe fstream da Borland [11]. Ele provê funções que facilitam a manipulação de fstreams. A Figura 4.11 mostra a estrutura do arquivo, que possui os seguintes campos de informação: Name (Nome) – Este campo define o nome do arquivo. Path (Caminho) – Este campo define o diretório onde o arquivo será gravado ou a partir do qual o arquivo será lido. Option (Opção) – Este campo define o tipo do arquivo. Dois tipos são previstos: default e binário. Description (Descrição) – Este campo contém uma descrição do conteúdo do arquivo. Name Path Option Description Figura 4.11 – Estrutura dos arquivos. 4.5 - Objetos Auxiliares 4.5.1 - Gerente de Entrada e Saída O objeto auxiliar IO_Manager – Input/Output Manager expande as funções do kernel do Hydragyrum para a: Manipulação de arquivos de entrada e saída. Manipulação de variáveis estatísticas. Manipulação de amostragens de variáveis estatísticas. 55
  • O objetivo deste modelo é facilitar aos blocos, camadas e gerenciadores de tráfego a manipulação de arquivos, variáveis estatísticas e amostragens de variáveis estatísticas. Para tanto, o gerente de entrada e saída mantém vários containers para o armazenamento de: Variáveis estatísticas simples. Variáveis estatísticas médias. Arquivos de entrada e saída. Variáveis estatísticas que fazem parte de uma determinada amostragem. Estado de uma determinada amostragem. Estas variáveis, arquivos, etc., são manipulados pelo gerente de entrada e saída através de várias funções, que permitem: Criar, configurar e remover arquivos de entrada e de saída – Permite gerenciar arquivos utilizados para salvar resultados e arquivos para carregar seqüências de tráfego. Criar, configurar e remover variáveis estatísticas – Permite gerenciar as variáveis estatísticas de um modelo. Possui funções para configurar o nome, o tipo e o valor (double) de cada variável estatística. Se a variável for média é possível informar o instante de tempo em que a variável foi modificada. Criar e realizar amostragens de variáveis estatísticas – Permite gerenciar amostragens estatísticas. A seguir veremos em maiores detalhes estas funções. 4.5.1.1 - Gerenciamento de Arquivos O IO_Manager permite configurar um nome, um caminho (diretório) e uma descrição para cada arquivo criado. Permite também configurar o tamanho de um campo de saída, o número de casas após a virgula, o tipo de alinhamento, o formato de codificação (binário, decimal, octal ou hexadecimal) e o tipo de notação (fixa ou científica) dos arquivos de saída. O gerente de entrada/saída possui ainda funções que permitem verificar se um arquivo existe, se ele está aberto para leitura ou escrita, se houve erro na abertura de um arquivo e se o final de um arquivo foi atingido. É possível também inserir um cabeçalho contendo uma descrição para cada coluna do arquivo. A Figura 4.12 mostra um exemplo de um arquivo de saída criado pelo IO_Manager. Neste caso, utilizou-se notação científica com 10 casas após a virgula, codificação decimal, alinhamento à esquerda e tamanho de campos de 25 caracteres. 56
  • Cabeçalho: informa as variáveis que são amostradas em cada coluna do arquivo de saída. Notação científica: 10 casas após a virgula t "Q0" "M_Q0" "D0" "M_D0" 0.0000000000 0.0000000000 0.0000000000 0.0000000000 0.0000000000 0.1000000000 5.0000000000 3.5705956250 0.0113740000 0.0088395828 0.2000000000 0.0000000000 2.2533809375 0.0004365000 0.0068284271 0.3000000000 0.0000000000 1.5588218749 0.0006396250 0.0058455820 0.4000000000 0.0000000000 1.2029290624 0.0005302500 0.0051188471 0.5000000000 0.0000000000 0.9859109999 0.0004599375 0.0046070607 0.6000000000 0.0000000000 0.8378645833 0.0012490000 0.0040217500 0.7000000000 0.0000000000 0.7528446135 0.0010276455 0.0034670476 0.8000000000 0.0000000000 0.7075419543 0.0011536875 0.0029328164 0.9000000000 0.0000000000 0.6825142371 0.0001005625 0.0025071952 1.0000000000 0.0000000000 0.6473560224 0.0009703545 0.0022955887 Figura 4.12 – Exemplo de arquivo de saída. 4.5.1.2 - Gerenciamento de Amostragens Estatísticas Uma amostragem estatística é uma estrutura que permite salvar para arquivo um determinado conjunto de variáveis estatísticas. Cada amostragem estatística recebe um nome, que é utilizado para identificar suas variáveis estatísticas e o arquivo de saída associado. A amostragem estatística foi desenvolvida com o objetivo de: automatizar o processo de seleção das variáveis que serão salvas para arquivo; automatizar o processo de criação do arquivo de saída (cabeçalho e formato do arquivo); e finalmente, automatizar a amostragem do valor das variáveis estatísticas no arquivo de saída (salvar uma nova linha no arquivo de saída). A automação do processo de seleção das variáveis estatísticas (que serão salvas para arquivo) é feita através do uso de parâmetros matriciais. Estes parâmetros permitem definir o nome, o tipo, o estado e a descrição das variáveis estatísticas que farão parte de uma determinada amostragem estatística. A Figura 4.13 mostra a partir de um screenshot do editor de parâmetros do Hydragyrum um exemplo de um parâmetro utilizado para definir as características de uma amostragem estatística da camada ATM de um bloco comutador. A automação do processo de criação do arquivo de saída é feita a partir da interpretação do parâmetro matricial que define as características de uma amostragem estatística. A partir desta interpretação, o IO_Manager cria um arquivo já formatado com um cabeçalho que identifica cada uma das variáveis estatísticas selecionadas pelo usuário. A automação da amostragem do valor das variáveis estatísticas é feita através de uma função específica do gerente de entrada/saída. Esta função, quando acionada, salva uma nova linha no arquivo de saída de uma amostragem estatística. Em cada coluna desta nova linha são salvos os valores atuais das variáveis estatísticas que fazem parte da amostragem. 57
  • Nome da Variável Estatística Tipo de Variável Estatística (simples ou média) Estado da Variável Estatística (ON ou OFF) Tipo de Variável Estatística (simples ou média) Figura 4.13 – Exemplo de um parâmetro matricial para a seleção das variáveis estatísticas que farão parte de uma amostragem. No conjunto de modelos no nível de células, todos os modelos que salvam resultados para arquivo possuem gerentes de entrada/saída para automatizar o processo de amostragem de resultados. Nestes modelos, o gerente de entrada/saída é utilizado para criar dois tipos de amostragens estatísticas: Amostragem Estatística por Eventos – Neste tipo de amostragem, as atividades de atualização do valor das variáveis estatísticas no IO_Manager e de amostragem destas variáveis para o respectivo arquivo de saída podem ser realizadas toda vez que acontece alguma modificação significativa no estado das variáveis estatísticas do modelo, como por exemplo a chegada de um pacote ao seu destino ou o descarte de uma célula ATM. Ou seja, neste tipo de amostragem as amostras podem ser feitas toda a vez que algum evento importante ocorra. As amostragens estatísticas por evento dividem-se em dois tipos: • Amostragem Estática: É utilizada para amostrar variáveis estatísticas globais de um modelo, ou seja, que representam valores totais como, por exemplo, o número total de células recebidas, a taxa total de perda de células ou o atraso total médio dos pacotes em um modelo. As amostragens estáticas são criadas durante a execução da função de inicialização dos modelos e permanecem ativas até a execução da função de finalização. 58
  • • Amostragem Dinâmica: É utilizada para amostrar variáveis estatísticas dinâmicas de um modelo, ou seja, que representam valores por conexão, como por exemplo o número de células recebidas em uma conexão, a taxa de perda de células em uma conexão ou o atraso médio dos pacotes de uma conexão. As amostragens dinâmicas são criadas durante a execução das funções de estabelecimento de conexão de blocos, conexão de rede e conexão de dados, e permanecem ativas até a execução das funções de remoção de conexão de bloco, conexão de rede e conexão de dados. Amostragem Estatística por Tempo – Neste tipo de amostragem, as atividades de atualização do valor das variáveis estatísticas no IO_Manager e de amostragem destas variáveis para o respectivo arquivo de saída podem ser realizadas de tempos em tempos, como por exemplo uma vez a cada um segundo. As amostragens estatísticas por tempo também dividem-se em dois tipos: amostragem estática e amostragem dinâmica. 4.5.2 - Gerente de Alocação Dinâmica O objeto auxiliar DA_Manager – Dynamic Allocation Manager expande as funções do kernel do Hydragyrum para a manipulação de parâmetros e mensagens. Ele fornece funções para alocar e desalocar dinamicamente mensagens, vetores e matrizes, que serão armazenados como parâmetros nos modelos. O objetivo deste gerente é facilitar a criação e a remoção de mensagens e de parâmetros vetoriais e matriciais. Como vimos na seção anterior, estes parâmetros são utilizados para configurar as variáveis estatísticas presentes em um modelo. O gerente de alocação dinâmica mantém vários containers para identificar todas as mensagens criadas em um modelo. Quando uma mensagem precisa ser removida, o gerente de alocação dinâmica que criou esta mensagem é acionado. Ele desaloca a memória ocupada pela mensagem e retira o “ponteiro” da mensagem do respectivo container. Desta forma, evita-se que uma mensagem que já tenha sido desalocada, seja desalocada novamente, causando a derrubada do ambiente de simulação. 4.6 - Camadas O CMNC possui quinze modelos de camadas, que podem ser divididas em 7 tipos: Camadas requerentes e removedoras de conexões. Camadas finalizadoras de conexões. Camadas fontes de tráfego. 59
  • Camadas receptoras de tráfego. Camadas de adaptação ATM. Camadas ATM. Camadas físicas. 4.6.1 - Camadas Requerentes e Removedoras de Conexões As camadas requerentes e removedoras de conexões são responsáveis pela requisição de novas conexões virtuais chaveadas (SVC – Switched Virtual Connections) junto ao bloco gerente, e pela remoção das SVCs finalizadas pelas camadas finalizadoras de conexões (veja a próxima seção). O conjunto de modelos no nível de células possui cinco camadas requerentes e removedoras de conexões, cada uma delas desenvolvida com o objetivo de requisitar SVCs de acordo com uma determinada categoria de serviço definida pelo ATM Forum. São elas: Camada Requerente e Removedora de Conexões com Taxa de Bits Constante (CBR_CRDL – Constant Bit Rate Connection Requesting and Deleting Layer). Camada Requerente e Removedora de Conexões com Taxa de Bits Variável em Tempo Real (RT_VBR_CRDL – Real Time Variable Bit Rate Connection Requesting and Deleting Layer). Camada Requerente e Removedora de Conexões com Taxa de Bits Variável Não em Tempo Real (NRT_VBR_CRDL – Non-Real Time Variable Bit Rate Connection Requesting and Deleting Layer). Camada Requerente e Removedora de Conexões com Taxa de Bits Disponível (ABR_CRDL – Available Bit Rate Connection Requesting and Deleting Layer). Camada Requerente e Removedora de Conexões com Taxa de Bits Não Especificada (UBR_CRDL – Unespecified Bit Rate Connection Requesting and Deleting Layer). As camadas requerentes e removedoras de conexões possuem dois parâmetros que permitem configurar a duração do período de tempo em que as conexões de dados e de rede permanecerão ativas e inativas. São eles: ON_Period e OFF_Period. A Figura 4.14 ilustra os períodos ativos (ON) e inativos (OFF) das conexões, quem podem ser determinísticos ou dados por uma distribuição exponencial negativa [12]. 60
  • Estado Estado da da Conexão Conexão Padrão Determinístico Padrão Exponencial Negativo ON ON ON ON ON ON OFF OFF OFF OFF OFF OFF Tempo Tempo Figura 4.14 – Períodos ativos e inativos das conexões criadas pelas camadas requerentes e removedoras de conexões. As camadas requerentes e removedoras de conexões acionam o bloco gerente para requerer o estabelecimento de conexões de dados e de conexões de rede. De acordo com a estrutura do Hydragyrum, para cada conexão de dados requerida a partir de um bloco aplicativo é necessário requerer também uma conexão de rede, que será a conexão SVC ATM propriamente dita. Isto é feito através do acionamento direto da função de execução de simulação (Run) do bloco gerente, que processa um evento chamado CREATE_NC_AND_DC. Este evento contém uma mensagem de roteamento (veja a seção 4.3.6 - ) com todas as informações necessárias para o estabelecimento da SVC, bem como o contrato de tráfego ATM que será negociado em cada equipamento da rede. Este contrato de tráfego (veja a seção 4.3.3 - ) informa a categoria de serviço, os descritores de tráfego, os parâmetros de QoS e a definição de conformidade da conexão que está sendo requisitada. Baseado nestas informações, o bloco gerente tenta estabelecer as conexões de rede e as conexões de dados. Se não for possível estabelecer estas conexões, uma nova tentativa será feita após a soma dos períodos ON e OFF. Se as conexões de rede e de dados foram estabelecidas, elas permanecerão ativas durante um período ON. Neste caso, a camada requerente e removedora de conexões avisa à camada fonte de tráfego do bloco aplicativo o instante de tempo em que as conexões devem ser desativadas. Isto é feito através da configuração do parâmetro Stop_Time da camada fonte de tráfego. Na camada fonte de tráfego, quando é transmitido um pacote, é verificado o instante de tempo de transmissão do próximo pacote a ser transmitido. Se o instante de tempo de transmissão deste pacote for maior que o valor do parâmetro Stop_Time, o campo EoT_FLAG do pacote que está sendo transmitido é configurado para 1, indicando que este é o último pacote a ser transmitido. Quando este pacote chegar ao bloco aplicativo de destino, a camada finalizadora de conexões gera um evento 61
  • DESTROY_SVDC para a camada requerente e removedora das conexões, a fim de que as conexões de dados e de rede sejam removidas. Quando as camadas requerentes e removedoras de conexões processam eventos solicitando a remoção de uma conexão de dados e de rede (DESTROY_SVDC), elas também acionam diretamente a função de execução de simulação (Run) do bloco gerente, para processar um evento chamado DESTROY_NC_AND_DC. Uma mensagem de roteamento também é enviada junto com este evento. Se o número de conexões de dados e de rede removidas for igual ao número de conexões de dados e de rede criadas pela camada requerente e removedora de conexões, uma nova requisição por conexões será feita após o período OFF. 4.6.1.1 - Amostragens Estatísticas As camadas requerentes e removedoras de conexões possuem duas amostragens estatísticas por evento. Nestas amostragens são salvos para arquivo de saída: A duração das conexões criadas pela camada, ou seja, o instante de tempo em que ocorreram transições de ON para OFF e vice-versa. Nesta variável estatística o valor 1 é associado ao período em que as conexões permaneceram ativas, e o valor 0 é associado ao período em que as conexões permaneceram inativas. A duração média das conexões criadas pela camada. O número de tentativas que resultaram no estabelecimento de novas conexões. O número de tentativas que não resultaram no estabelecimento de novas conexões. A probabilidade de bloqueio de conexões, ou seja, a probabilidade de que uma nova conexão não seja criada com sucesso. 4.6.2 - Camadas Finalizadoras de Conexões O conjunto de modelos no nível de células possui somente uma camada finalizadora de conexões. É a camada CEL – Connection Ending Layer, que dispara o processo de remoção de conexões de todas as categorias de serviço da rede. 4.6.2.1 - Amostragens Estatísticas A camada CEL não possui amostragens estatísticas. 4.6.3 - Camadas Fontes de Tráfego As camadas fonte de tráfego são responsáveis pelo envio de pacotes através da rede. Para tanto, elas utilizam as conexões de dados previamente estabelecidas pelo bloco gerente a pedido 62
  • das camadas requerentes e removedoras de conexões. O conjunto de modelos no nível de células possui três camadas fontes de tráfego, cada uma delas desenvolvida com o objetivo de gerar um padrão específico de tráfego para as conexões presentes na rede. São elas: Camada Fonte de Tráfego Determinístico (Deterministic_TSL – Deterministic Traffic Source Layer). Camada Fonte de Tráfego Poissoniano (Poissonian_TSL – Poissonian Traffic Source Layer). Camada Fonte de Tráfego Externo (External_TSL – External Traffic Source Layer). As camadas fontes tráfego permitem definir o instante de tempo em que cada pacote será transmitido na rede, bem como o tamanho de cada pacote, a conexão de dados a que o pacote pertence, a conexão de rede a que o pacote pertence e o campo de informações EoT_FLAG, que indica se o pacote é o último pacote a ser transmitido antes que as conexões de dados e de rede sejam removidas. Uma vez que um pacote é criado, ele é passado para a camada de adaptação ATM do bloco BTE. Isto é feito a partir de um evento chamado CPCS_UNITDATA_INVOKE. 4.6.3.1 - Amostragens Estatísticas As camadas fontes de tráfego determinístico e poissoniano possuem apenas uma amostragem estatística por evento. São salvos para arquivo de saída: O instante de tempo em que os pacotes são criados. O tamanho dos pacotes. O tamanho médio dos pacotes. A camada fonte de tráfego externo não possui amostragem estatística. 4.6.3.2 - Camada Fonte de Tráfego Determinístico A camada Deterministic_TSL – Deterministic Traffic Source Layer gera um padrão determinístico de tráfego, ou seja gera pacotes de tamanho fixo com intervalos também fixos entre pacotes, como ilustra a Figura 4.15. 63
  • Tamanho Tamanho dos dos Pacotes Pacotes Padrão Determinístico de Pacotes Padrão Determinístico de Pacotes ON ON ON ON ON ON OFF OFF OFF OFF OFF OFF a) Tempo b) Tempo Figura 4.15 – Padrão de tráfego gerado pela camada fonte de tráfego determinístico para duas situações: a) Conexões com durações determinísticas. b) Conexões com durações exponenciais negativas. 4.6.3.3 - Camada Fonte de Tráfego Poissoniano A camada Poissonian_TSL – Poisson Traffic Source Layer gera um padrão poissoniano [12] de tráfego, ou seja, gera pacotes de tamanho dado pela distribuição de poisson com intervalos entre pacotes dados pela distribuição exponencial negativa, como ilustra a Figura 4.16. Tamanho Tamanho dos dos Pacotes Pacotes Padrão Poissoniano-Exponencial Padrão Poissoniano-Exponencial Negativo de Pacotes Negativo de Pacotes ON ON ON ON ON ON OFF OFF OFF OFF OFF OFF a) Tempo b) Tempo Figura 4.16 – Padrão de tráfego gerado pela camada fonte de tráfego poissoniano para duas situações: a) Conexões com durações determinísticas. b) Conexões com durações exponenciais negativas. 4.6.3.4 - Camada Fonte de Tráfego Externo A camada External_TSL – External Traffic Source Layer gera um padrão de tráfego carregado a partir de um arquivo externo ao ambiente de simulação. Este arquivo deve conter o instante de tempo em segundos em que cada pacote deve ser criado e o tamanho dos pacotes em bytes. 64
  • 4.6.4 - Camadas Receptoras de Tráfego O CMNC possui somente uma camada receptora de tráfego: a camada TRL – Traffic Receiver Layer. Esta camada remove os pacotes que chegam ao seu destino e calcula estatísticas relacionadas com estes pacotes. A camada TRL ainda é responsável por acionar a camada CEL quando um pacote que indica que uma conexão deve ser removida for recebido. 4.6.4.1 - Amostragens Estatísticas A camada TRL possui duas amostragens estatísticas por evento: estática (variáveis totais) e dinâmica (variáveis por conexão). São salvos para arquivo de saída: O tempo de permanência dos pacotes na rede. O tempo médio de permanência dos pacotes na rede. O tamanho dos pacotes recebidos. O tamanho médio dos pacotes recebidos. 4.6.5 - Camadas de Adaptação ATM O conjunto de modelos no nível de células possui somente uma camada de adaptação ATM: a camada de adaptação ATM tipo 5. Escolhemos modelar esta camada devido a sua popularidade. 4.6.5.1 - Camada de Adaptação ATM Tipo 5 A camada AAL5 – ATM Adaptation Layer 5, modela as funções da camada de adaptação ATM tipo 5 do Modelo de Referência de Protocolos da B-ISDN [7][8]. A camada AAL5 é responsável pela segmentação dos pacotes das camadas superiores em células ATM no ponto de ingresso à rede ATM e pela remontagem destes pacotes a partir das células ATM no ponto de egresso da rede. Isto é feito através de dois eventos: CPCS_UNITDATA_INVOKE e ATM_DATA_INDICATION. O evento CPCS_UNITDATA_INVOKE fragmenta um pacote em células ATM e envia estas células para a camada ATM do bloco BTE, enquanto o evento ATM_DATA_INDICATION reúne as células recebidas para remontar um pacote e enviá-lo ao bloco aplicativo de destino. 4.6.5.1.1 - Amostragens Estatísticas A camada AAL5 possui três amostragens por evento estáticas (variáveis totais), uma amostragem por eventos dinâmica (variáveis por conexão), três amostragens por tempo estáticas e uma amostragem por tempo dinâmica. Estas amostragens salvam para arquivos de saída: O número de células recebidas com sucesso. 65
  • O número de células descartadas na rede. O número total de células recebidas. A probabilidade de perda de células (CLR – Cell Loss Ratio). A média da probabilidade de perda de células. O atraso de transmissão das células na rede. A média do atraso de transmissão das células na rede. O número de pacotes recebidos com sucesso. O número de pacotes perdidos, por que uma ou mais células destes pacotes foram descartadas. O número total de pacotes recebidos. A probabilidade de perda de pacotes (PLR – Packet Loss Ratio). A média da probabilidade de perda de pacotes. 4.6.6 - Camadas ATM As camadas ATM modelam a camada ATM do Modelo de Referência de Protocolos da B- ISDN. O CMNC possui duas camadas ATM: camada ATM do bloco BTE e camada ATM do bloco comutador. A razão porque separamos a camada ATM em duas camadas está na considerável diferença funcional existente entre a camada ATM do bloco BTE e a camada ATM do bloco comutador. 4.6.6.1 - Camada ATM do BTE A camada BTE_ATM – BTE ATM Layer envia as células recebidas da camada de adaptação ATM para a camada física, ou vice-versa. Isto é feito através de dois eventos: ATM_DATA_REQUEST e PHY_DATA_INDICATION. O evento ATM_DATA_REQUEST cria um evento PHY_DATA_REQUEST para enviar uma célula ATM para a camada física de saída do bloco, enquanto o evento PHY_DATA_INDICATION cria um evento ATM_DATA_INDICATION para enviar uma célula ATM para a camada de adaptação ATM do bloco BTE. 4.6.6.1.1 - Amostragens Estatísticas A camada BTE_ATM não possui amostragens estatísticas. 4.6.6.2 - Camada ATM do Comutador A camada SW_ATM – Switch ATM Layer é responsável pela comutação das células ATM de uma camada física de entrada para uma camada física de saída. Para tanto, esta camada interage 66
  • com diversos gerenciadores de tráfego que modelam estruturas de filas (seção 4.7.1 - ), escalonadores (seção 4.7.2 - ), algoritmos de controle de admissão de conexões (seção 4.7.3 - ), algoritmos de gerenciamento de estruturas de filas (seção 4.7.4 - ), algoritmos de descarte seletivo de células (seção 4.7.5 - ) e algoritmos de policiamento de tráfego (seção 4.7.6 - ). A camada SW_ATM implementa um modelo da parte de comutação de células de uma switch fabric (SF) com memória compartilhada [9]. Esta switch fabric consiste de uma memória simples com duas portas, que é compartilhada por todos os enlaces de entrada (FIL – Fabric Input Link) e de saída (FOL – Fabric Output Link) da switch fabric. Esta memória é logicamente (não fisicamente) particionada por FOL. Em nosso modelo de switch fabric, todos os enlaces da SF possuem a mesma taxa em células/segundo. Esta taxa é configurada através do parâmetro Switch_Fabric_Link_Rate. A camada SW_ATM possui também o parâmetro Switch_Fabric_Processing_Delay, que permite configurar o atraso de processamento de células na SF. A Figura 4.17 ilustra a estrutura da switch fabric modelada. Switch Fabric FIL QS S FOL FIL QS S FOL FIL QS S FOL Figura 4.17 – Estrutura da switch fabric modelada no conjunto de modelos no nível de células. Switch fabrics ATM podem ser classificadas como [9]: com bloqueio interno ou sem bloqueio interno. O bloqueio interno ocorre quando uma SF não consegue encaminhar duas células de diferentes FILs para diferentes FOLs. Neste caso, uma estrutura de filas é necessária para armazenar as células que não conseguem transitar pela SF. Switch fabrics sem bloqueio interno não necessitam destas estruturas de filas. Porém, pode haver várias células simultaneamente destinadas para uma mesma FOL. Este fenômeno é chamado de contenção FOL [9]. Uma estrutura de filas também é necessária para resolver este conflito de recursos. Três opções podem ser utilizadas para posicionar estas estruturas de filas: filas na entrada da SF, filas com seleção de janelas (Window Selection) e filas na saída da SF. Escolhemos implementar em nosso conjunto de modelos, um 67
  • modelo de SF sem bloqueio interno, com memória compartilhada e com filas na saída da SF, devido a popularidade destas switch fabrics. A Figura 4.18 mostra a iteração entre a camada SW_ATM e os demais gerenciadores de tráfego do bloco comutador, bem como o algoritmo executado por esta camada quando uma célula ATM é recebida da camada física de entrada (PHY_IN) para ser encaminhada para a camada física de saída (PHY_OUT). Policiamento de Recebe Célula Tráfego Controle de Admissão de Conexões Identifica a porta de saída para a qual a célula recebida deve ser encaminhada. Gerencimento de Estrutura de Filas Camada Descarte Seletivo Policiamento ATM de Células de tráfego está habilitado? Não Escalonador Porta de Executa gerenciamento de Estrutura de Fila Saída 0 Sim estrutura de filas. Escalonador Porta de Executa policiamento de tráfego. Saída 1 Não Gerenciamento Camada ATM de estrutura de filas aceitou a célula? Célula recebida foi descartada? Não Célula proveniente Célula destinada da PHY_IN. a PHY_OUT. Executa descarte seletivo para escolher a células a a) Iteração entre a camada SW_ATM e os gerenciadores de Sim serem descartadas. tráfego do comutador. Fim Descarta células. Sim Sim Célula recebida foi descartada? Não Envia célula para a estrutura de filas e para o escalonador da porta de saída adequada. b) Algoritmo executado pela camada SW_ATM quando uma célula é recebida da camada física de entrada (PHY_IN). Figura 4.18 – Iteração entre a camada SW_ATM e os demais gerenciadores de tráfego do bloco comutador. Inicialmente a camada ATM identifica para qual porta de saída deve ser encaminhada a célula proveniente da camada PHY_IN. Em seguida é verificado se o policiamento de tráfego encontra-se habilitado. Para ativar ou desativar o policiamento de tráfego é utilizado um parâmetro chamado Traffic_Policing_Status. Se o policiamento de tráfego estiver habilitado, a célula recebida é passada para um modelo de policiador de tráfego, que irá decidir se a célula está ou não de acordo com o contrato de tráfego negociado. Se a célula não estiver de acordo com este contrato ela pode ser descartada. Caso o policiamento de tráfego esteja desabilitado, a célula recebida é passada para 68
  • um gerenciador de estrutura de filas, que determinará se a estrutura de filas (que implementa o controle da memória compartilhada da SF) pode ou não armazenar a célula recebida. Se o gerenciador de estrutura de filas decidir que a célula recebida não pode ser armazenada, a camada SW_ATM executa então um modelo de algoritmo de descarte seletivo de células. Este modelo determinará se a célula recebida será descartada ou se outra célula menos prioritária que esteja armazenada na estrutura de filas será descartada em prol da célula recebida. Se a célula recebida não for descartada, ela é enviada tanto para o modelo de estrutura de filas quanto para o modelo de escalonador associado à porta de saída previamente identificada. A principal razão para que esta célula seja encaminhada para ambos os modelos, é que enquanto a estrutura de filas modela o armazenamento das células ATM, o escalonador modela independentemente a execução do serviço destas células. Esta solução permite substituir independentemente os modelos de escalonador e de estrutura de filas utilizados nos equipamentos da rede, aumentando assim o grau de flexibilidade do conjunto de modelos. 4.6.6.2.1 - Amostragens Estatísticas A camada SW_ATM possui quatro amostragens estatísticas: amostragem por eventos estática (variáveis totais), amostragem por eventos dinâmica (variáveis por conexão), amostragem por tempo estática e amostragem por tempo dinâmica. Estas amostragens salvam para arquivos de saída: O número de células ATM não descartadas por modelos de algoritmos de descarte seletivo de células. O número de células ATM descartadas por estes modelos. O número total de células recebidas na camada. A probabilidade de perda de células (CLR). A média da probabilidade de perda de células. 4.6.7 - Camadas Físicas Estas camadas modelam a camada física do Modelo de Referência de Protocolos da B- ISDN. O CMNC possui duas camadas físicas: a camada física de entrada e a camada física de saída. Implementamos duas camadas físicas ao invés de uma para facilitar o desenvolvimento do bloco comutador ATM, uma vez que este possui uma estrutura baseada em portas de entrada e de saída. 69
  • 4.6.7.1 - Camada Física de Entrada A camada PHY_IN – Physical Input Layer é responsável pelo recebimento das células ATM provenientes de outros equipamentos da rede, pelo processamento destas células e pelo encaminhamento das mesmas para a camada ATM do equipamento receptor, que pode ser um bloco BTE ou um bloco comutador. O funcionamento da camada PHY_IN difere dependendo se o bloco em que ela se encontra for um BTE ou um comutador. Se o bloco for um BTE, a camada PHY_IN simplesmente recebe as células e as encaminha para a camada ATM, sem efetuar nenhum processamento. Entretanto, se o bloco for um comutador, é feita uma verificação para determinar se a taxa em que as células estão sendo recebidas do equipamento transmissor é maior do que a taxa em que as células serão atendidas na camada ATM. Estas taxas são definidas através dos parâmetros: Switch_Fabric_Link_Rate do comutador e Output_Link_Rate da camada física de saída do equipamento transmissor. Se estas taxas forem iguais, a camada PHY_IN simplesmente recebe as células e as encaminha para a camada ATM, sem efetuar nenhum processamento. Se estas taxas forem diferentes, a camada PHY_IN, assim como a camada SW_ATM, interage com diversos gerenciadores de tráfego do comutador para processar as células recebidas. Neste caso, os gerenciadores de tráfego são alocados pelo bloco comutador durante a execução de suas funções de estabelecimento de conexão de blocos (OnConnect). A Figura 4.19 mostra esta iteração, bem como o algoritmo executado por esta camada quando uma célula ATM é recebida da camada física de saída (PHY_OUT) do equipamento transmissor. Este algoritmo é praticamente idêntico ao algoritmo executado pela camada SW_ATM (seção 4.6.6.2 - ). 70
  • Célula destinada a camada ATM. Recebe Célula Célula proveniente da PHY_OUT do Camada Física de equipamento Entrada transmissor. Identifica a porta de entrada pela qual a célula Estrutura de Fila foi recebida. Escalonador Policiamento de tráfego está habilitado? Não Controle de Admissão Camada de Conexões Física Executa gerenciamento de Sim estrutura de filas. Gerencimento de Estrutura de Filas Executa policiamento de tráfego. Não Descarte Seletivo Gerenciamento de Células de estrutura de filas aceitou a célula? Célula recebida foi Policiamento de deletada? Tráfego Não Executa descarte seletivo para escolher a células a a) Iteração entre a camada PHY_IN e os gerenciadores de Sim serem descartadas. tráfego do comutador para a situação em que existe diferença entre a taxa de serviço da camada ATM e a taxa de recepção da camada PHY_IN. Fim Descarta células. Sim Sim Célula recebida foi deletada? Não Envia célula para a estrutura de filas e para o escalonador da porta de saída adequada. b) Algoritmo executado pela camada PHY_IN quando uma célula é recebida e existe diferença entre a taxa de serviço da camada ATM e a taxa de recepção da camada PHY_IN. Figura 4.19 – Iteração entre a camada PHY_IN e os demais gerenciadores de tráfego do bloco comutador. 4.6.7.1.1 - Amostragens Estatísticas A camada PHY_IN possui as mesmas amostragens estatísticas que a camada SW_ATM. 4.6.7.2 - Camada Física de Saída A camada PHY_OUT – Physical Output Layer é responsável pelo recebimento das células ATM provenientes da camada ATM do mesmo equipamento de rede, pelo processamento destas células e pelo encaminhamento das mesmas para a camada física de entrada do próximo equipamento da rede, que pode ser um bloco BTE ou um bloco comutador. O funcionamento da camada PHY_OUT difere dependendo se o bloco em que ela se encontra for um BTE ou um comutador. Se o bloco for um BTE, a camada PHY_OUT, assim como a camada SW_ATM, interage com diversos gerenciadores de tráfego do BTE para processar as células recebidas, independentemente das taxas de serviço da camada ATM e de transmissão da camada PHY_OUT. Entrentanto, se o bloco for um comutador, é feita uma verificação para determinar se a taxa em que as células serão servidas na camada ATM é maior do que a taxa em que as células serão 71
  • transmitidas na camada PHY_OUT. Estas taxas são definidas através dos parâmetros: Switch_Fabric_Link_Rate do comutador e Output_Link_Rate da camada PHY_OUT. Se estas taxas forem iguais, a camada PHY_OUT simplesmente recebe as células e as encaminha para a camada PHY_IN do próximo equipamento da rede, sem efetuar nenhum processamento. Se estas taxas forem diferentes, a camada PHY_OUT interage com diversos gerenciadores de tráfego do comutador para processar as células recebidas. Em ambos os casos em que há iteração com os gerenciadores de tráfego, estes são alocados pelos respectivos blocos durante a execução de suas funções de estabelecimento de conexão de blocos (OnConnect). A Figura 4.20 mostra esta iteração, bem como o algoritmo executado pela camada PHY_OUT para transmitir uma célula ATM até o próximo equipamento da rede. Este algoritmo é praticamente idêntico ao algoritmo executado pela camada SW_ATM (seção 4.6.6.2 - ) Célula proveniente da camada ATM. Recebe Célula Célula destinada Camada Física de ao próximo Saída equipamento da rede. Identifica a porta de saída da célula. Estrutura de Fila Escalonador Policiamento de tráfego está habilitado? Não Camada Controle de Admissão de Conexões Física Executa gerenciamento de Sim estrutura de filas. Gerencimento de Estrutura de Filas Executa policiamento de tráfego. Não Descarte Seletivo Gerenciamento de Células de estrutura de filas aceitou a célula? Célula recebida foi Policiamento de deletada? Tráfego Não Executa descarte seletivo para escolher a células a a) Iteração entre a camada PHY_OUT e os gerenciadores de Sim serem descartadas. tráfego do equipamento transmissor. Fim Descarta células. Sim Sim Célula recebida foi deletada? Não Envia célula para a estrutura de filas e para o escalonador da porta de saída adequada. b) Algoritmo executado pela camada PHY_OUT quando uma célula é recebida da camada ATM. Figura 4.20 – Iteração entre a camada PHY_OUT e os demais gerenciadores de tráfego dos blocos comutador e BTE. 72
  • Finalmente, antes de enviar uma célula para o próximo equipamento da rede, a camada PHY_OUT insere um atraso de propagação. O cálculo deste atraso é feito a partir de três parâmetros: Link_Rate, Distance e Propagation_Speed. Link_Rate é a taxa de transmissão do enlace em bits/segundo. Distance é a distância em metros entre os equipamentos de rede. Propagation_Speed é a velocidade de propagação do sinal no enlace em metros/segundo. 4.6.7.2.1 - Amostragens Estatísticas A camada PHY_OUT também possui as mesmas amostragens estatísticas que a camada SW_ATM. 4.7 - Gerenciadores de Tráfego Uma rede ATM provê suporte para uma grande variedade de serviços com diferentes pré- requisitos de QoS (Quality of Service). Estes serviços compartilham os recursos da rede (largura de faixa, armazenamento, etc.) e tentam utilizá-los simultaneamente. Devido a este compartilhamento de recursos, pontos de congestionamento poderão aparecer na rede, causando a necessidade do uso de estruturas de filas [9] (queueing structures) para armazenar temporariamente células ATM. Escalonadores [9] (schedulers) são implementados em cada estrutura de filas para selecionar a ordem apropriada de serviço das células, a fim de garantir os objetivos de QoS negociados. O termo escalonador refere-se ao algoritmo que determina qual fila da estrutura de filas terá a oportunidade de transmitir uma célula em um dado time slot. Algoritmos de gerenciamento de estruturas de filas também devem ser implementados em cada estrutura de filas a fim de julgar se uma célula recebida pode ou não ser armazenada em uma estrutura que enfrenta congestionamento. E mais, numa situação de congestionamento, células ATM eventualmente terão que ser descartadas. Nesta situação, algoritmos de descarte seletivo de células [9][10] são necessários, pois células de menor prioridade devem ser descartadas em benefício de células mais prioritárias. Outro aspecto importante do gerenciamento de tráfego em redes ATM diz respeito ao estabelecimento de conexões, uma vez que o ATM é uma tecnologia orientada à conexão. Para determinar se uma conexão ATM pode ou não ser estabelecida em uma rede, é necessário que em cada equipamento desta rede um algoritmo de controle de admissão de conexões (CAC – Connection Admission Control) [9][10] seja consultado, de forma a verificar se os requisitos de QoS para esta conexão podem ser aceitos sem que o QoS das conexões existes seja deteriorado. Entretanto, a alocação de recursos pelo CAC não é suficiente para assegurar que a QoS negociada seja garantida. Ou seja, uma conexão pode intencionalmente ou acidentalmente exceder os descritores de tráfego contratados, prejudincando assim a QoS de outras conexões bem 73
  • comportadas. Dada que a rede ATM é obrigada a atender a QoS negociada pelo menos para as células que estejam conformes, um ponto crítico do gerenciamento de tráfego em redes ATM é assegurar que o tráfego das conexões ATM estejam de acordo com o contrato de tráfego negociado. Esta tarefa é executada por algoritmos de formatação de tráfego (traffic shaping) e de policiamento de tráfego (traffic policing). Algoritmos de formatação de tráfego modificam as características do tráfego de uma determinada conexão de forma a satisfazer os descritores de tráfego contratados. Algoritmos de policiamento de tráfego atuam marcando e descartando células ATM a fim de que o tráfego mal comportado de uma determinada conexão satisfaça os descritores de tráfego negociados. Estruturas de filas, escalonadores, algoritmos de controle de admissão de conexões, algoritmos de gerenciamento de estruturas de filas, algoritmos de descarte seletivo de células, algoritmos de formatação de tráfego e algoritmos de policiamento de tráfego são modelados em nosso conjunto de modelos como gerenciadores de tráfego. A seguir veremos em maiores detalhes os modelos desenvolvidos. 4.7.1 - Estruturas de Filas (Queueing Structures) As células ATM são geralmente armazenadas em uma memória compartilhada. Esta memória permite que centenas de células compartilhem o mesmo espaço físico. A maneira como estas células são logicamente organizadas em filas é definida como estrutura de filas. Esta estrutura organiza as filas a serem atendidas por um escalonador. O conjunto de modelos no nível de células possui dois modelos de estruturas de filas: estrutura de filas default e estrutura de filas com filas por conexão. A seguir veremos estes gerenciadores de tráfego. 4.7.1.1 - Estrutura de Filas Default A estrutura de filas Default_Queueing_Structure – Default Queueing Structure mantém uma fila FIFO – First In First Out [9] de células ATM. Nesta fila as células aguardam pela transmissão em um enlace entre equipamentos ou interno a uma switch fabric. Um ou mais modelos de escalonador são alocados para servir a fila FIFO. A Figura 4.21 ilustra a estrutura do gerenciador de tráfego Default_Queueing_Structure sendo servida por um modelo de escalonador. 74
  • Estrutura de Filas Default Modelo de Escalonador Fila FIFO Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Células Células Figura 4.21 – Estrutura do gerenciador de tráfego Default_Queueing_Structure. A estrutura de filas default possui um único parâmetro que configura a capacidade da fila FIFO em células. 4.7.1.1.1 - Amostragens Estatísticas O gerenciador de tráfego Default_Queueing_Structure possui três amostragens estatísticas: duas amostragens estáticas por eventos e uma amostragem estática por tempo. Tanto as amostragens por eventos quanto por tempo salvam para arquivos de saída: O número de células ATM na fila FIFO. O número médio de células ATM na fila FIFO. O atraso das células na fila FIFO. O atraso médio das células na fila FIFO. 4.7.1.2 - Estrutura de Filas com Fila por Conexão A estrutura de filas Per_VC_Queueing_Structure – Per VC Queueing Structure mantém várias filas FIFO, uma para cada conexão de rede ATM. Nestas filas as células aguardam pela transmissão em um enlace entre equipamentos ou interno a uma switch fabric. Um ou mais modelos de escalonador são alocados para servir cada uma das filas por conexão. A Figura 4.22 ilustra a estrutura do gerenciador de tráfego Per_VC_Queueing_Structure sendo servida por dois modelos de escalonador. O primeiro deles está servindo as conexões ATM VCC_1 e VCC_2, enquanto o segundo está servindo a conexão VCC_n. 75
  • Estrutura de Filas com Filas por Conexão Modelo de Escalonador Fila para a conexão VCC_1 Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Células Fila para a conexão VCC_2 Células Célula Célula Célula Célula Modelo de Escalonador Fila para a conexão VCC_n Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Figura 4.22 – Estrutura do gerenciador de tráfego Per_VC_Queueing_Structure. A estrutura de filas com filas por conexão também possui um único parâmetro que configura a capacidade total em células. 4.7.1.2.1 - Amostragens Estatísticas O gerenciador de tráfego Per_VC_Queueing_Structure possui duas amostragens estáticas por eventos, uma amostragem estática por tempo, duas amostragens dinâmicas por eventos e uma amostragem dinâmica por tempo. Estas amostragens salvam para arquivos de saída: O número total de células na estrutura de filas e o número de células em cada fila por conexão. A média do número de células na estrutura de filas e do número de células em cada fila por conexão. O atraso total das células na estrutura de filas e o atraso das células em cada fila por conexão. A média do atraso das células na estrutura de filas e do atraso das células em cada fila por conexão. 4.7.2 - Escalonadores (Schedulers) Escalonadores são necessários para extrair células de estruturas de filas e transmiti-las (servi-las) apropriadamente de forma a atender os pré-requisitos de QoS de cada conexão. Portanto, um escalonador é um mecanismo de gerenciamento de tráfego responsável pela arbitração entre 76
  • filas a serem servidas e pela alocação de largura de faixa para estas filas. As filas de uma estrutura de filas podem ser divididas em vários grupos lógicos, cada um dos quais servidos por um escalonador. Um escalonador robusto protege os fluxos de tráfego de fontes ou usuários maliciosos (ou mal comportados) sem depender somente da função de policiamento [9]. Ele também permite o uso eficiente da largura de faixa disponível sob qualquer situação de variação de carga na rede. Os algoritmos de escalonamento podem ser classificados em três tipos [9]: Escalonamento baseado em prioridades (Priority-based scheduling). Escalonamento com divisão justa (Fair-share scheduling). Escalonamento com regulação de tráfego (Traffic shaping). Um escalonador baseado em prioridades aloca uma prioridade para cada fila da estrutura de filas e as serve em ordem de prioridade. Uma fila de baixa prioridade só é servida quando não existir nenhuma célula esperando por serviço em qualquer outra fila de alta prioridade. Ou seja, células cuja fila tem prioridade alta serão servidas primeiro, mesmo que as células de uma fila de baixa prioridade tenham chegado primeiro. Uma alternativa ao escalonamento baseado em prioridades é o escalonamento com divisão justa, na qual para cada fila da estrutura de filas, uma porção da largura de faixa é alocada de acordo com um peso (weigth). Ou seja, o escalonador divide a largura de faixa disponível entre as filas baseado em um peso justo. A divisão justa é um conceito que introduz isolamento entre várias filas durante um congestionamento, minimizando assim a interação entre o tráfego de diferentes filas. Os escalonadores com divisão justa também podem ser classificados em duas categorias: conservativos (work-conserving) e não-conservativos (non- work-conserving). Um escalonador conservativo é aquele que nunca deixa sobrar largura de faixa quando existe tráfego em qualquer uma das filas. Um escalonador não-conservativo funciona ao contrário, ou seja, pode deixar sobrar largura de faixa mesmo que exista tráfego em qualquer uma das filas. Finalmente, temos o escalonamento com regulação de tráfego [9]. O objetivo do traffic shaping é criar um fluxo de células em uma conexão que seja concordante com os seus descritores de tráfego negociados na fase de estabelecimento das conexões. O conjunto de modelos no nível de células possui cinco modelos de escalonadores: Escalonador Default (Default_Scheduler – Default Scheduler). Escalonador PGPS (PGPS_Scheduler – Packet Generalized Processor Sharing Scheduler). 77
  • Escalonador WF2Q (WF2Q_Scheduler – Worst-case Fair Weighted Fair Queuing Scheduler). Escalonador LFVC (LFVC_Scheduler – Leap Forward Virtual Clock Scheduler). Escalonador Regulador de Tráfego Virtual Scheduling (VS_TS_Scheduler – Virtual Scheduling Traffic Shaping Scheduler) 4.7.2.1 - Escalonador Default O escalonador Default_Scheduler – Default Scheduler implementa a disciplina de serviço FCFS (First Come First Served) [9]. Para tanto, é utilizada uma fila com prioridades [13] (baseada em fichas) para ordenar as células ATM de acordo com o seu tempo de chegada no escalonador. O escalonador default pode servir células de uma ou mais filas de uma estrutura de filas. A estrutura do escalonador default é ilustrada na Figura 4.21. O escalonador default possui um único parâmetro que configura a capacidade do escalonador em células/segundo, ou seja, a largura de faixa do escalonador. 4.7.2.1.1 - Amostragens Estatísticas O gerenciador de tráfego Default_Scheduler possui três amostragens estatísticas: duas amostragens estáticas por eventos e uma amostragem estática por tempo. Tanto as amostragens por eventos quanto por tempo salvam para arquivos de saída: A banda efetiva total alocada pelo modelo de CAC. A média da banda efetiva alocada pelo modelo de CAC. A largura de faixa total utilizada. A média da largura de faixa utilizada. 4.7.2.2 - Escalonador de Pacotes com Compartilhamento de Processador Generalizado O escalonador PGSP_Scheduler é uma implementação original de um escalonador PGPS (Packet Generalized Processor Sharing) [9][14]. O PGPS é uma versão baseada em pacotes do GPS (Generalized Processor Sharing). O escalonador PGPS pode ser classificado como um escalonador com divisão justa e conservativa (work-conserving fair-share scheduler). O PGSP_Scheduler também utiliza uma fila com prioridades (baseada em fichas) para ordenar as células ATM, porém no caso do PGSP_Scheduler as células são ordenadas de acordo com um tempo virtual de final de serviço Ft2i . Para calcular o Ft2i , o primeiro passo é atualizar o valor do tempo virtual 78
  • Vt 2 = Vt1 + (t 2 − t1 ) (1) ∑φ i∈B j i , onde B j é o conjunto de todas as conexões ativas no intervalo t2 – t1, φ i é o peso da conexão i e Vt1 é o tempo virtual anterior. Uma vez atualizado o tempo virtual, é necessário calcular o tempo virtual de inicio de serviço S ti2 { S ti2 = max Ft1i , Vt 2 , } (2) onde Ft1i é o tempo virtual de final de serviço anterior. Feito isso pode-se calcular tempo virtual de final de serviço Ft 2i da célula: 1 (3) Ft2i = S ti2 + φi O escalonador PGPS pode servir células de uma ou mais filas de uma estrutura de filas. A estrutura do escalonador PGPS também é ilustrada na Figura 4.21. Assim como o escalonador default, o escalonador PGSP possui um único parâmetro que configura a capacidade do escalonador em células/segundo. 4.7.2.2.1 - Amostragens Estatísticas O gerenciador de tráfego PGSP_Scheduler possui quatro amostragens estatísticas: três amostragens estáticas por eventos e uma amostragem estática por tempo. Tanto as amostragens por eventos quanto por tempo salvam para arquivos de saída: A banda efetiva total alocada pelo modelo de CAC. A média da banda efetiva alocada pelo modelo de CAC. A largura de faixa total utilizada. A média da largura de faixa utilizada. A soma dos pesos φ i das conexões ativas. O tempo virtual atual Vt2 . O tempo virtual de final de serviço anterior Ft1i . 79
  • O tempo virtual de inicio de serviço atual S ti2 . O tempo virtual de final de serviço atual Ft2i . 4.7.2.3 - Escalonador Regulador de Tráfego Virtual Scheduling O escalonador VS_TS_Scheduler – Virtual Scheduling Traffic Shaping Scheduler é uma implementação original do regulador de tráfego Virtual Scheduling Spacer apresentado em [9]. Ao invés de descartar ou marcar as células não conformes com os descritores de tráfego de uma dada conexão, o escalonador VS_TS_Scheduler atrasa as células recebidas até que elas estejam conformes com estes descritores de tráfego. Para isso, o VS_TS_Scheduler mantém um regulador de tráfego para cada conexão sendo servida. Estes reguladores calculam o primeiro instante de tempo em que uma célula recebida estará de acordo com os descritores de tráfego de sua conexão. Este instante de tempo é chamado de tempo de emissão em conformidade (CET – Conformance Emission Time). O escalonador VS_TS_Scheduler utiliza este tempo de emissão para ordenar a transmissão das células ATM em uma fila com prioridades. Para atrasar as células ATM do tempo necessário, o escalonador VS_TS_Scheduler somente transmite uma célula se o seu CET for menor que o tempo de inicio de um novo slot de transmissão. A Figura 4.23 mostra a estrutura do VS_TS_Scheduler. Escalonador Regulador de Tráfego Virtual Scheduling Espaçador A CET Célula Célula (CBR.1, ABR.1 e UBR.1) Espaçador B Fila com prioridades Célula (VBR.1) Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Espaçador C (VBR.2) Transmite célula Ordenação de células cujo CET é menor conforme o CET que o tempo de Espaçador D inicio de um novo (VBR.3) slot. Figura 4.23 – Estrutura do escalonador VS_TS_Scheduler. O VS_TS_Scheduler possui quatro espaçadores, que são utilizados para calcular o CET das células recebidas: 80
  • Espaçador A – Modela um algoritmo Virtual Scheduling para as definições de conformidade CBR.1, ABR.1 e UBR.1 (veja a referência [9]), das categorias de serviço CBR, ABR e UBR, respectivamente. Espaçador B – Modela um algoritmo Dual Virtual Scheduling para a definição de conformidade VBR.1, das categorias de serviço rt-VBR e nrt-VBR. Espaçador C – Modela um algoritmo Dual Virtual Scheduling para a definição de conformidade VBR.2, das categorias de serviço rt-VBR e nrt-VBR. Espaçador D – Modela um algoritmo Dual Virtual Scheduling para a definição de conformidade VBR.3, das categorias de serviço rt-VBR e nrt-VBR. O espaçador A é um espaçador simples, ou seja, somente espaça as células de acordo com os descritores de tráfego PCR (Peak Cell Rate) e CDVT (Cell Delay Variation Tolerance). O espaçador A equivale um algoritmo GCRA (1/PCR, CDVT)1 (GCRA – Generic Cell Rate Algorithm). Os espaçadores B, e C e D são espaçadores duplos, ou seja, espaçam as células de acordo com os descritores de tráfego PCR, CVDT, SCR (Sustainable Cell Rate) e MBS (Maximum Burst Size). Estes espaçadores equivalem a um algoritmo GCRA (1/PCR, CDVT) em série com um algoritmo GCRA (1/SCR, BT-CDVT), onde BT (Burst Tolerance) é a tolerância a surtos da conexão em questão. O parâmetro BT é utilizado para definir o intervalo de tempo em que uma conexão pode transmitir células a uma taxa igual ao PCR. Ou seja, este intervalo corresponde a duração de um surto cujo número de células máximo é igual ao valor do descritor de tráfego MBS. A Figura 4.24a mostra o algoritmo implementado para o espaçador A. Quando uma célula ATM é recebida, o espaçador A busca o valor atual da variável CET para a sua conexão. Se o CET for igual a zero, ele é configurado com o valor do tempo de chegada da célula recém recebida (Time). Feito isso, a célula é armazenada na fila com prioridades, onde aguarda pela sua vez de ser transmitida. O CET da conexão é então incrementado de 1/PCR e gravado para ser consultado quando a próxima célula for recebida. 1 A notação geral é GCRA (I, L), onde I é o incremento e L é o limite de capacidade de um algoritmo de policiamento análogo a um “balde furado” (veja a seção 4.7.6.1 - ). 81
  • Recebe uma célula Recebe uma célula Busca valor do CET para a Busca valor de CETp e CETs conexão. para a conexão. CETp = 0 CET = 0? e CETs = 0? Sim Sim Não Não Armazena célula para ser CETp = Time CET=Time BT=(MBS-1).(1/PCR+1/SCR) servida após o CET CETs = Time CET=CET+1/PCR CET=max(CETs-BT;CETp) Grava valor do CET para a conexão. Time > CET? Sim End Não CETp = Time CET=max(CETs-BT;CETp) CETs = Time a) Espaçador A (CBR.1, ABR.1 e UBR.1) Armazena célula para ser servida após o CET CETp=CETp+1/PCR CETs=CETs+1/SCR CET - Conformance Emission Time CETp - Conformance Emission Time for PCR CETs - Conformance Emission Time for SCR Grava valor do CETp e do PCR - Peak Cell Rate CETs para a conexão. SCR - Sustainable Cell Rate MBS - Maximum Burst Size BT - Burst Tolerance End b) Espaçador B (VBR.1) Figura 4.24 – Algoritmos implementados para os espaçadores: a) A (CBR.1, ABR.1 e UBR.1) e b) B (VBR.1). A Figura 4.24b mostra o algoritmo implementado para o espaçador B. Neste espaçador são mantidas duas variáveis para cada conexão: CETp e CETs. O CETp é o tempo de emissão em conformidade relacionado com o PCR. O CETs é o tempo de emissão em conformidade relacionado com o SCR. Quando uma célula ATM é recebida, o espaçador B busca o valor atual destas variáveis. Se o CETp e o CETs forem iguais a zero, eles são configurados com o tempo de chegada da célula recém recebida. Feito isso, o espaçador B calcula o valor da tolerância a surtos BT para a conexão. De posse do valor da tolerância a surtos, o espaçador B faz uma estimativa do valor do CET resultante a ser utilizado para a armazenar a célula na fila com prioridades. Se o tempo de chegada da célula for maior que este CET, então os CETp e CETs são configurados com o valor do tempo de chegada da célula. Isto é feito para reiniciar o espaçador quando intervalos de tempo 82
  • maiores que 1/PCR são verificados entre células. Então o CET definitivo é calculado e a célula é armazenada na fila com prioridades. O CETp da conexão é então incrementado de 1/PCR, enquanto o CETs é incrementado de 1/SCR. Ambos os valores são então gravados para serem consultados quando a próxima célula for recebida. A Figura 4.25a mostra o algoritmo implementado para o espaçador C. Neste espaçador também são mantidas duas variáveis para cada conexão: CETp e CETs. Quando uma célula ATM é recebida, o espaçador C também busca o valor atual destas variáveis. Se o CETp e o CETs forem iguais a zero, eles também são configurados com o tempo de chegada da célula recém recebida. Feito isso, o espaçador C também calcula o valor do BT da conexão. De posse do valor da tolerância a surtos, o espaçador C faz a mesma estimativa do valor do CET resultante que o espaçador B. Entretanto, se o tempo de chegada da célula for maior que este CET, um novo teste é feito. Se o CETp for menor que o tempo de chegada da célula e a sua prioridade (CLP – Cell Loss Priority) for igual a zero, o CET é considerado como sendo igual ao CETp, o CLP da célula é trocado para um, e a célula é armazenada na fila com prioridades. Entretanto, se o CETp for maior que o tempo de chegada da célula e a sua prioridade (CLP – Cell Loss Priority) não for igual a zero, tanto o CETp quanto o CETs são configurados com o tempo de chegada da célula. Neste caso, então, o CET definitivo é calculado e a célula é armazenada na fila com prioridades com este CET. O incremento do CETp e do CETs difere do espaçador B. Se o CLP da célula armazenada for igual a zero, somente o CETp da conexão é incrementado de 1/PCR, enquanto o CETs permanece com o mesmo valor. Porém, se o CLP da célula for igual a um, o CETp da conexão é incrementado de 1/PCR e o CETs é incrementado de 1/SCR. 83
  • Recebe uma célula Recebe uma célula Busca valor de CETp e CETs Busca valor de CETp e CETs para a conexão. para a conexão. CETp = 0 CETp = 0 e e CETs = 0? CETs = 0? Sim Sim Não Não CETp = Time CETp = Time BT=(MBS-1).(1/PCR+1/SCR) BT=(MBS-1).(1/PCR+1/SCR) CETs = Time CETs = Time CET=max(CETs-BT;CETp) CET=max(CETs-BT;CETp) Armazena célula para ser CETp <= Time servida após o CET CET > Time? Sim e CLP = 0? Sim CET = CETp CLP = 0 ? Não CETp=CETp+1/PCR Não CLP = 1 Não Sim Armazena célula para ser CETp=CETp+1/PCR servida após o CET CETs=CETs+1/SCR Grava valor do CETp e do CETs para a conexão. CLP = 0 ? Não CETp=CETp+1/PCR End Sim CETp=CETp+1/PCR CETs=CETs+1/SCR CET - Conformance Emission Time b) Espaçador D (VBR.3) CETp - Conformance Emission Time for PCR CETs - Conformance Emission Time for SCR Grava valor do CETp e do CETs para a conexão. PCR - Peak Cell Rate SCR - Sustainable Cell Rate MBS - Maximum Burst Size End BT - Burst Tolerance CLP - Cell Loss Priority a) Espaçador C (VBR.2) Figura 4.25 – Algoritmos implementados para os espaçadores: a) C (VBR.2) e b) D (VBR.3). A Figura 4.25b mostra o algoritmo implementado para o espaçador D. Este espaçador possui um algoritmo bastante parecido com o espaçador B. A única diferença diz respeito ao incremento das variáveis CETp e CETs, que é feito da mesma forma que no espaçador C. 4.7.2.3.1 - Amostragens Estatísticas O gerenciador de tráfego VS_TS_Scheduler possui três amostragens estatísticas: duas amostragens estáticas por eventos e uma amostragem estática por tempo. Tanto as amostragens por eventos quanto por tempo salvam para arquivos de saída: A banda efetiva total alocada pelo modelo de CAC. A média da banda efetiva alocada pelo modelo de CAC. A largura de faixa total utilizada. 84
  • A média da largura de faixa utilizada. 4.7.2.4 - Escalonador WF2Q O escalonador WF2Q_Scheduler é uma implementação original de um escalonador WF2Q – Worst-case Fair Weighted Fair Queueing [15]. O escalonador WF2Q é uma aproximação baseada em pacotes do GPS, que tem por objetivo emular este escalonador fluído o mais próximo possível. De acordo com Giroux e Ganti [9], o escalonador WF2Q é classificado como um escalonador com divisão justa e conservativa (work-conserving fair-share scheduler). Portanto, sempre que houver células aguardando para serem servidas, no mínimo uma célula será servida a cada slot de serviço do escalonador. Em outras palavras, o escalonador nunca é “desligado” enquanto existirem células aguardando para serem servidas. Consideremos um conjunto de conexões Btk sendo servidas simultaneamente em um escalonador GPS no instante t k . Para cada conexão i é atribuído um “peso” φi , que determina a fração de serviço que a conexão i receberá. Como no GPS cada conexão tem exatamente um pacote sendo servido, a taxa de serviço instantânea para a conexão i é dada por φi (4) ri = .r , ∑ j∈Bt k φj onde Btk é o número de conexões sendo servidas simultaneamente no escalonador no instante t k , φi é o peso da conexão i no escalonador GPS, φ j é o peso da conexão j no escalonador GPS e r é a taxa total disponível no escalonador. O funcionamento do escalonador WF2Q é bastante semelhante ao do escalonador PGPS (ou WFQ), porém com uma diferença na forma em que os pacotes a serem servidos são selecionados. Quando um escalonador PGPS escolhe um pacote para ser servido no instante t s , ele seleciona, entre todos os pacotes presentes no servidor, o pacote que terminaria serviço primeiro no GPS. Já o escalonador WF2Q, ao invés de escolher o pacote que terminaria serviço primeiro no GPS dentre todos os pacotes presentes no servidor, escolhe somente entre os pacotes que já teriam iniciado serviço no GPS (pacotes elegíveis). Ou seja, no escalonador WF2Q, o pacote escolhido para ser servido no instante t s é o pacote que terminaria serviço primeiro no GPS e que já teria começado a ser servido pelo GPS no instante t s . Tanto o PGPS quanto o WF2Q utilizam o conceito de tempos virtuais [14] para emular o funcionamento do GPS e a partir daí escolher a ordem de serviço dos pacotes presentes no 85
  • escalonador. Consideremos a chegada de um pacote da conexão i no instante t k com tamanho igual a Litk bits. No momento da chegada deste pacote, um tempo virtual geral Vtk é incrementado de acordo com a expressão Vtk = Vtk −1 + (tk − tk −1 ) (5) ∑φ j∈Btk j , onde Vtk −1 é o tempo virtual geral no instante t k −1 e Btk é o número de conexões sendo servidas simultaneamente no escalonador no instante t k . Uma vez atualizado o tempo virtual geral, é necessário calcular então os tempos virtuais de inicio de serviço ( S tik ) e de final de serviço ( Ftki ) deste pacote no GPS emulado. O tempo virtual de inicio de serviço Stik é calculado de acordo com a expressão { Stik = max Ftki −1 , Vtk , } (6) onde Ftki −1 é o tempo virtual de final de serviço anterior. Feito isso calcula-se o tempo virtual de final de serviço Ftki do pacote Litk (7) Ftk = S + i i . φi tk Tanto no escalonador PGPS quanto no escalonador WF2Q, a ordem de serviço dos pacotes é determinada em função dos tempos virtuais Stik e Ftki . Suponhamos que ambos os escalonadores queiram escolher no instante t s um pacote para ser servido. Como vimos, no PGPS é servido primeiro o pacote que terminaria serviço primeiro no GPS, ou seja o pacote que tiver o menor tempo virtual Ftki , independente do instante de tempo t s . Já no escalonador WF2Q, é servido primeiro o pacote elegível que terminaria serviço primeiro no GPS. Ou seja, é servido primeiro o pacote com menor tempo virtual Ftki , cujo Stik seja menor que o instante de tempo t s . Portanto, o escalonador WF2Q, ao invés de utilizar uma disciplina de seleção de pacotes “menor tempo virtual de final de serviço primeiro” (SFF – Smallest virtual Finish time First), utiliza uma disciplina “menor tempo virtual de final de serviço elegível primeiro” (SEFF – Smallest Eligible virtual Finish time First). Ou seja, o escalonador WF2Q escolhe entre todos os pacotes elegíveis, o pacote que tem o menor tempo virtual de final de serviço. 86
  • Como vimos, o WF2Q serve primeiro o pacote com menor tempo virtual Ftki cujo Stik seja menor que o instante de tempo de serviço real t s . Para implementarmos esta disciplina de seleção de pacotes, utilizamos estruturas de dados do tipo filas com prioridades [13]. Tais filas possuem desempenho ótimo de inserção e de retirada de objetos, e foram implementadas utilizando árvores binárias balanceadas [13]. Duas filas com prioridades foram utilizadas: fila com prioridades para o Ftki e fila com prioridades para o Ftki temporária. Uma vez que nosso modelo de escalonador WF2Q foi desenvolvido voltado para a simulação de redes ATM, ambas as filas com prioridades são utilizadas para ordenar células ATM conforme os seus tempos virtuais de final de serviço Ftki . A Figura 4.26 mostra a estrutura do modelo desenvolvido. As células são armazenadas na fila com prioridades por Ftki onde aguardam para serem servidas. No momento em que uma célula é servida, é verificado se a célula no topo da fila é elegível. Se a célula escolhida for elegível, ela é servida. Caso contrário, ela é armazenada na fila com prioridades por Ftki temporária, e uma nova célula é verificada. O processo prossegue até que uma célula elegível seja escolhida ou até que a fila com prioridades fique vazia. Após uma célula ter sido escolhida, as células não elegíveis que se encontram na fila temporária são retornadas à fila principal. Escalonador WF2Q Fila com prioridades p/ o Ftki Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Transmite célula elegível com o menor Ftki . Célula Célula Células não elegíveis Fila com prioridades p/ o Ft ki (temporária) Figura 4.26 – Estrutura do modelo do escalonador WF2Q. O modelo desenvolvido para o escalonador WF2Q possui dois algoritmos principais: algoritmo de armazenamento de células ATM e algoritmo de serviço de células ATM. Algoritmo de Armazenamento de Células ATM 87
  • A Figura 4.27 mostra o fluxograma do algoritmo de armazenamento de células ATM. Quando uma célula ATM é recebida (instante de tempo t k 2), o modelo do escalonador verifica se o tempo de chegada da célula anterior ( t k −1 ) é igual a zero. Se esta variável for igual a zero, ela é configurada com o valor de t k . Uma variável chamada BT (Begin Time) é utilizada para marcar o instante de tempo em que pelo menos uma conexão está presente no escalonador. Em outras palavras, o BT marca o inicio de um período de atividade. Se t k −1 for igual a zero, a variável BT também é configurada com o valor de t k . Ainda na Figura 4.27, o modelo do escalonador WF2Q busca o valor dos pesos para as conexões do conjunto Btk . Feito isso, é verificado se a variável t k é maior que a variável t k −1 . Se esta condição for verdadeira, o somatório dos pesos de todas as conexões ativas é recalculado. Caso contrário, o mesmo valor obtido anteriormente é utilizado. Em seguida é atualizado o valor do tempo virtual do sistema ( Vtk ). Também é lido o valor do tempo virtual de final de serviço ( Ftki −1 ) para a conexão i no instante t k −1 . Se o tempo virtual Vtk for maior que o Ftki −1 , o valor do tempo virtual de inicio de serviço ( Stik ) para a conexão i é tomado como sendo igual ao Vtk . Caso contrário, o valor do tempo virtual de inicio de serviço para a conexão i é tomado como sendo igual ao Ftki −1 . Então, o Ftki é atualizado para o valor do Stik acrescido de 1 φ i . A célula é então armazenada na fila com prioridades para o Ftki , onde aguarda pelo serviço. 2 Quando a primeira célula ATM é recebida k=1, Ft0i =0, S ti0 =0 e Vt0 =0. 88
  • Recebe uma célula tk t k −1 = 0 ? Sim t k −1 = t k BT = t k Não Busca φ j∈Btk t k > t k −1 Sim Não Calcula ∑φ j∈Btk j Vt k = Vt k −1 + (tk − tk −1 ) ∑φ j∈Btk j Busca Ftki −1 Stik = Ftki −1 Não Vt ik > Ftki −1 Sim 1 Ftki = S tik + S tik = Vtki φi Armazena célula na fila com prioridades para o Ft i k Inicia serviço no inicio do próximo FP Fim tk - Tempo de chegada da célula atual tk −1 - Tempo de chegada da célula anterior φi - Peso para a conexão i Vtk −1 - Tempo virtual para o instante tk −1 Vt k - Tempo virtual para o instante tk Btk - Conjunto de conexões ativas em tk Ftki −1 - Tempo virtual de final de serviço para a conexão i em tk −1 Ftki - Tempo virtual de final de serviço para a conexão i em tk S tik - Tempo virtual de inicio de serviço para a conexão i em tk FP - Período de um frame de serviço BT - Inicio de um período de atividade no escalonador Figura 4.27 – Algoritmo de armazenamento de células ATM. Algoritmo de Serviço de Células ATM A Figura 4.28 mostra o fluxograma do algoritmo de serviço de células ATM. Quando uma primeira célula ATM é armazenada na fila com prioridades para o Ftki , automaticamente o modelo do escalonador é “ligado” e o serviço de células começa no inicio do próximo slot de serviço. Uma 89
  • única célula é servida no período de um slot de serviço (FP – Frame Period). Consideremos o caso em que uma célula ATM será servida no instante t S . Inicialmente, é executado um laço na fila com prioridades para o Ftki . O objetivo deste laço é encontrar a célula elegível com menor Ftki . Para verificar a elegibilidade de uma célula, foi necessário desenvolver uma expressão que permitisse comparar o seu tempo virtual de inicio de serviço S tik no sistema GPS com o tempo real de serviço t S . A seguinte expressão foi desenvolvida para possibilitar tal comparação S tik .FP + BT ≤ t S . (8) Uma vez que o equacionamento do escalonador WF2Q foi desenvolvido considerando-se uma taxa de serviço normalizada de 1 célula por segundo, a multiplicação do tempo virtual de inicio de serviço S tik pelo período de um slot de serviço ATM torna este tempo virtual compatível com a taxa de serviço FP do modelo do escalonador WF2Q. O acréscimo do tempo BT é necessário para reajustar o escalonador após um período de inatividade. Portanto, a cada iteração do laço, o tempo virtual S tik da célula que se encontra no topo da fila com prioridades para o Ftki é lido e a expressão (8) é utilizada para verificar a elegibilidade desta célula. Se a expressão (8) for verdadeira, a célula é considerada elegível, sendo, portanto, removida da fila Ftki e servida. Neste caso a execução do laço acaba. Entretanto, se a expressão (8) não for verdadeira, a célula é considerada inelegível, sendo portanto removida da fila Ftki e armazenada na fila para o Ftki temporária, onde aguarda para ser re-inserida na fila Ftki principal. Neste caso, o laço prossegue verificando a elegibilidade das demais células armazenadas na fila Ftki principal até que uma célula elegível seja encontrada ou até que esta fila principal fique vazia. Como vimos, o escalonador WF2Q é um escalonador com divisão justa e conservativa. Portanto, se nenhuma célula da fila com prioridades Ftki principal for elegível para ser servida no instante t S , o escalonador deverá escolher igual uma célula para ser servida. Neste caso será servida a célula com menor Ftki que se encontra na fila com prioridade temporária. 90
  • tk - Tempo de chegada da célula atual tk −1 - Tempo de chegada da célula anterior φi - Peso para a conexão i Vtk −1 - Tempo virtual para o instante tk −1 Serve uma célula Vt k - Tempo virtual para o instante tk tS Bt k - Conjunto de conexões ativas em tk Ftki −1 - Tempo virtual de final de serviço para a conexão i em tk −1 Ftki - Tempo virtual de final de serviço para a conexão i em tk Enquanto a fila com Remove célula da fila com Stik - Tempo virtual de inicio de serviço para a conexão i em tk Se prioridades para o Ft i vazia prioridades para o Ft i não estiver vazia k temporária k FP - Período de um frame de serviço BT - Inicio de um período de atividade no escalonador i Busca Ftk e St k i Ambas k =1 t k −1 = 0 para a célula com Serve célula as filas ficaram Sim Pára serviço j∈Bt k menor Ft i k vazias? Vt k = 0 Ftk −1 =0 Não Remove célula da fila com Se Enquanto a fila End S tik .FP + BT ≤ t S Sim i prioridades para o Ftk Serve próxima célula no para o Ft i vazia instante t S + FP k principal temporaria não estiver vazia Não Remove célula da fila com Remove célula da fila prioridades para o Ft i para o Ft i temporária k k Armazena célula na fila Armazena célula na fila para o F i principal para o Ft i temporária tk k Fim do laço Fim do laço Figura 4.28 – Algoritmo de serviço de células ATM. Depois de escolhida a célula a ser servida, é verificado se restaram células nas filas com prioridades principal e temporária. Se ambas as filas ficaram vazias, as variáveis k, t k −1 , Vtk e j∈B Ftk −1 tk são reinicializadas e o escalonador é “desligado”. Caso contrário, é agendando o serviço de uma próxima célula ATM no instante t S + FP . Neste ponto outro laço é executado. O objetivo é retornar as células inelegíveis não servidas de volta para a fila principal. 4.7.2.4.1 - Amostragens Estatísticas O gerenciador de tráfego WF2Q_Scheduler possui quatro amostragens estatísticas: três amostragens estáticas por eventos e uma amostragem estática por tempo. Tanto as amostragens por eventos quanto por tempo salvam para arquivos de saída: A banda efetiva total alocada pelo modelo de CAC. A média da banda efetiva alocada pelo modelo de CAC. A largura de faixa total utilizada. A média da largura de faixa utilizada. A soma dos pesos φ i das conexões ativas. 91
  • O tempo virtual atual Vt2 . O tempo virtual de final de serviço anterior Ft1i . O tempo virtual de inicio de serviço atual S ti2 . O tempo virtual de final de serviço atual Ft2i . 4.7.2.5 - Escalonador LFVC O escalonador LFVC_Scheduler é uma implementação original de um escalonador LFVC – Leap Forward Virtual Clock [16]. O escalonador LFVC possui as propriedades de atraso máximo (bounded-delay) e de divisão justa de pior caso (worst-case fairness) quase iguais ao do escalonador WF2Q. Porém, o LVFC é considerado menos complexo que o WF2Q. Assim como o PGPS e o WF2Q, o escalonador LFVC também pode ser classificado como um escalonador com divisão justa e conservativa (work-conserving fair-share scheduler). O princípio de funcionamento do escalonador LFVC é baseado em uma estratégia análoga a dos pais de uma criança indisciplinada que colocam os seus filhos de castigo por um certo período de tempo até que eles aprendam a lição. No caso do escalonador LFVC_Scheduler, um fluxo f de células ATM que momentaneamente tenha utilizado mais largura de faixa do que o alocado através de um peso φ f pode ser disciplinado através do armazenamento destas células em uma fila de menor prioridade L (Low priority). Em contrapartida, fluxos de células bem comportados são atendidos a partir de uma fila principal de maior prioridade H (High priority). A Figura 4.29 mostra a estrutura do escalonador LFVC. Escalonador LFVC Transmite célula com a menor etiqueta. Fila com prioridades H Célula Célula Célula Célula Célula Célula Transfere célula antes Transfere célula de Célula Célula Célula Célula Célula Célula Célula Célula Célula que ela utrapasse o um fluxo mal comportado. seu limite de atraso. Célula Célula Célula Célula Fila com prioridades L Figura 4.29 – Estrutura do LFVC_Scheduler. 92
  • Disciplinas de serviço baseadas em relógios virtuais (virtual clock) funcionam alocando etiquetas (tags) para cada célula a ser servida. Estas etiquetas representam o valor do relógio do sistema em que uma célula deve ser transmitida. Portanto, as células ATM são servidas de acordo com a ordem crescente de suas etiquetas. No escalonador LFVC somente as células da fila H são transmitidas. As células da fila L só serão transmitidas quando tiverem sido transferidas primeiramente para a fila H. Portanto, mesmo que as células da fila L tenham etiquetas menores que as células da fila H, as células da fila H serão servidas primeiro. Então, assim como as crianças de nossa analogia não podem ser esquecidas de castigo por um longo período de tempo, o escalonador LFVC precisa transferir células da fila L para a fila H de tempos em tempos. A questão é, portanto, quanto tempo as células podem permanecer na fila L sem que sejam atrasadas em demasiado? Este problema foi resolvido pelos desenvolvedores do LFVC da seguinte forma: seja um fluxo f na fila L e c uma célula na cabeceira desta fila, então o atraso máximo que está célula apode sofrer é dado por T (c ) − t s ≥ ∆ f , (9) onde T (c ) é igual a etiqueta para a célula c, t s denota o valor do relógio atual do escalonador e ∆ f é o tempo necessário para servir a célula c à taxa de serviço alocada para o fluxo f. Portanto, o escalonador LFVC transfere as células de um fluxo f para a fila L quando é provável que elas causem problemas de vazão, e retorna estas células para a fila H antes que as garantias de atraso para estas células sejam violadas. Porém, após terem resolvido o problema do tempo em que as células deveriam permanecer na fila L, restava ainda um problema que deveria ser resolvido para que o escalonador LFVC fosse conservativo: o que aconteceria se todos os fluxos fossem transferidos para a fila L e a fila H estivesse vazia? Para que o escalonador LFVC fosse conservativo, células ATM deviam ser transmitidas mesmo que não fossem elegíveis. A solução para este problema foi avançar o relógio do escalonador o tanto quanto possível sem que violações de variação de atraso ocorressem. Depois deste avanço, pelo menos um fluxo ativo f da fila L se torna elegível e suas células são transferidas para a fila H. Nossa implementação do escalonador LFVC foi feita baseada no algoritmo apresentado na seção 3.3 do artigo [15]. O escalonador LFVC conta com filas com prioridade para organizar as células de um fluxo f na ordem crescente de seus tempos de chegada. Portanto, a dinâmica do algoritmo LFVC é baseada na retirada das células ATM destas filas. A fim de reduzir o consumo de memória, nossa implementação do escalonador LFVC realiza uma parceria com a estrutura de filas 93
  • ao qual o escalonador está servindo. Desta forma não é necessário incluir outras filas internas ao LFVC_Scheduler. A Figura 4.30 mostra o algoritmo implementado para o armazenamento de células ATM no LFVC_Scheduler e o algoritmo para processamento da cabeceira da fila destas células. Quando uma célula ATM é recebida no escalonador, primeiramente é buscada a ocupação da fila para o fluxo f ( Q f ) no modelo de estrutura de filas ao qual o escalonador está servindo. Se esta ocupação for igual a 1, significa que a célula recém recebida no escalonador já encontra-se armazenada na estrutura de filas. Neste caso, é acionado um algoritmo para o processamento da cabeceira da fila Q f . Se a ocupação da fila for diferente de 1, nada precisa ser feito, porque o escalonador já está “ligado”3. O algoritmo de processamento da cabeceira da fila Q f inicia buscando a célula que encontra-se na cabeceira da fila Q f . Esta operação parece inadequada, pois a célula recém recebida já é conhecida. Porém, para permitir a utilização da estrutura de filas externa foi necessário desenvolver o LFVC_Scheduler desta forma. Em seguida são buscados os valores da etiqueta anterior ( t fprev ) e do peso ( φ f ) para o fluxo f, o valor do período de tempo necessário para transmitir uma célula na taxa alocada para o fluxo f é calculado ( ∆ f ), o valor da etiqueta atual de um fluxo f é calculado e o valor da etiqueta anterior atualizado. Feito isso, é calculado o valor do período dos frames de transmissão do escalonador ( τ ). Neste ponto, é verificado se o valor do t f ≤ t s + ∆ f + τ + ρ . Se esta condição for verdadeira a célula é considerada de maior prioridade e armazenada na fila H com a etiqueta t f . Se esta condição for falsa a célula é considerada de menor prioridade e armazenada na fila L com a etiqueta t f − ∆ f . Feito isso, é verificado se o escalonador está “ligado”. Se ele estiver “desligado”, o escalonador é “ligado” e a transmissão de uma célula da fila H é agendada para o instante de tempo de inicio do próximo frame. Na seqüência é verificado se um FLAG_1, utilizado para manter o escalonador “ligado”, possui o valor 1. Se o FLAG_1 for igual a 1, é verificado se a fila H ou a fila L estão ocupadas. Se alguma delas estiver ocupada é agendada a transmissão da próxima célula da fila H no instante t m + τ . Se nenhuma das filas estiver ocupada o escalonador é “desligado”. Se o FLAG_1 for diferente de 1, nada é feito. 3 Estar “ligado” significa estar transmitindo uma célula a cada frame indefinidamente. 94
  • Recebe uma célula Processa cabeçeira (t m) da fila Q f ( t m) Busca Q f na estrutura de Busca na estrutura de filas filas associada. associada a célula que está na cabeçeira da fila Qf . Q f = 1? Processa cabeçeira Sim da fila Q f Busca t fprev e φ f Não 1 Fim ∆f = φ f .SC t m - Tempo de chegada de uma célula do fluxo f. t f - Etiqueta atual de um fluxo f. ( ) t f = max t s , t fprev + ∆ f prev t f - Etiqueta anterior de um fluxo f. φ f - Peso para o fluxo f. Q f - Fila para o fluxo f. t fprev = t f ∆ f - Período de tempo necessário para transmitir uma célula na taxa alocada para o fluxo f. t s - Tempo atual do escalonador. 1 τ= τ - Período dos frames de transmissão do SC escalonador. ρ - Parâmetro de arredondamento. SC - Capacidade do escalonador em células/segundo. Armazena célula com t f ≤ ts + ∆ f + τ + ρ ? Sim tempo t f na fila com prioridades H. Não Armazena célula com Escalonador tempo t f − ∆ f na fila com está ligado? prioridades L. Não Agenda retirada de uma célula da fila H Liga escalonador no inicio do próximo frame. FLAG_1 = 1? Sim Sim Fila H está ocupada ou fila L está Não Desliga escalonador ocupada? Não Sim Agenda retirada da próxima célula da fila H no instante t m + τ Retorna Figura 4.30 – Algoritmo implementado para o armazenamento de células no LFVC_Scheduler. 95
  • A Figura 4.31 mostra o algoritmo implementado para o serviço de células no LFVC_Scheduler. Este algoritmo aciona dois outros algoritmos: algoritmo para a transferência de células da fila L para a fila H (mostrado na Figura 4.31) e algoritmo de serviço da célula da cabeceira da fila H (mostrado na Figura 4.32). Remove uma Transfere células célula ( tl ) da fila L para a fila H Enquanto houverem Se vazia Retorna células na fila L. Fila H Transfere células Sim está vazia? da fila L para a fila H Não Célula da cabeçeira da fila L é válida? Existem Serve célula da células na Sim cabeçeira da fila H fila H ? Sim Não Não t s = max (t s , (k min − ρ )) Fim Se tm - Tempo de chegada de uma célula do fluxo f. k min ≤ t s + τ + ρ t f - Etiqueta atual de um fluxo f. Não t fprev - Etiqueta anterior de um fluxo f. φ f - Peso para o fluxo f. Sim Q f - Fila para o fluxo f. Armazena célula na fila H ∆ f - Período de tempo necessário para transmitir uma célula na taxa alocada para o fluxo f. t s - Tempo atual do escalonador. τ - Período dos frames de transmissão do Remove célula da fila L escalonador. ρ - Parâmetro de arredondamento. SC - Capacidade do escalonador em células/segundo. Fim do laço Figura 4.31 – Algoritmo implementado para a transmissão de células no LFVC_Scheduler. O algoritmo para a transferência de células da fila L para a fila H é acionado somente se a fila H estiver vazia. Este algoritmo executa um laço enquanto houver células na fila L. Inicialmente, é verificado se a célula da cabeceira da fila L é uma célula válida, ou seja, que não foi descartada por um modelo de descarte seletivo enquanto aguardava pelo serviço do escalonador LFVC_Scheduler. Se a célula da cabeceira da fila L for inválida, ela é removida da fila L e uma nova iteração do laço tem inicio. Se a célula da cabeceira da fila L for válida, o tempo do relógio virtual é reajustado para o valor máximo entre o próprio t s e a diferença entre a etiqueta da célula mais prioritária da fila L ( k min ) e um parâmetro de arredondamento ρ . Neste ponto, é verificado se a célula é elegível ou não. Somente são transferidas para a fila H as células cujas etiquetas forem 96
  • menores que a soma do tempo do relógio virtual acrescido de τ e ρ . Se nenhuma célula mais for elegível, o laço é interrompido, retornando para o algoritmo principal. Serve célula da cabeçeira da fila H Envia célula com menor Enquanto FLAG_2 = 0 tf ts = ts + τ Remove célula da Agenda processamento da cabeçeira da fila H. cabeçeira da fila Q f no instante tl t f - Etiqueta atual de um fluxo f. Q f - Fila para o fluxo f. FLAG_1 = 1 t s - Tempo atual do escalonador. τ - Período dos frames de transmissão do escalonador. Retorna Ainda Esta célula Não existem células Não Desliga escalonador. é válida? na fila H? Sim Sim FLAG_2 = 1 FLAG_2 = 0 Fim do laço Figura 4.32 – Algoritmo de serviço da célula da cabeceira da fila H. Na seqüência, é verificado se existem células na fila H. Em caso afirmativo, o algoritmo de serviço da célula da cabeceira da fila H é acionado. Este algoritmo executa um laço enquanto um FLAG_2 for igual a 0. Inicialmente, é retirada a célula da cabeceira da fila H. Em seguida é verificado se esta célula é válida. Se a célula for inválida, é verificado se existem outras células armazenadas na fila H. Em caso afirmativo, o FLAG_2 é mantido igual 0 e uma nova iteração do laço tem inicio. Se não existirem mais células, o escalonador é desligado e o algoritmo é finalizado, retornando para o algoritmo principal. Por outro lado, se a célula for válida, o FLAG_2 é configurado para 1 indicando que o laço deve ser terminado. Então, a célula válida é enviada para o modelo de camada adequado, o tempo do relógio virtual é incrementado de τ e o processamento da cabeceira da fila Q f é agendado para o mesmo instante de tempo tl . Finalmente, o FLAG_1, que mantém o escalonador servindo células, é configurado para 1. Este flag é utilizado no algoritmo de armazenamento de células mostrado na Figura 4.30. 4.7.2.5.1 - Amostragens Estatísticas 97
  • O gerenciador de tráfego LFVC_Scheduler possui quatro amostragens estatísticas: três amostragens estáticas por eventos e uma amostragem estática por tempo. Estas amostragens salvam para arquivos de saída: A banda efetiva total alocada pelo modelo de CAC. A média da banda efetiva alocada pelo modelo de CAC. A largura de faixa total utilizada. A média da largura de faixa utilizada. O peso φ i alocado para cada conexão. O tempo ∆ f necessário para servir uma célula. A etiqueta anterior de uma célula ( t f −1 ). A etiqueta atual de uma célula ( t f ). O período dos frames de transmissão ( τ ). 4.7.3 - Algoritmos de Controle de Admissão de Conexões O conjunto de modelos no nível de células possui dois algoritmos de controle de admissão de conexões ATM. São eles: Algoritmo de Controle de Admissão de Conexões Default (Default_CAC – Default Connection Admission Control). Algoritmo de Controle de Admissão de Conexões Elwalid Mitra (Elwalid_Mitra_CAC – Elwalid Mitra Connection Admission Control). 4.7.3.1 - Algoritmo de Controle de Admissão de Conexões Default O algoritmo de controle de admissões de conexões Default_CAC – Default Connection Admission Control é responsável por verificar se uma nova conexão ATM pode ou não ser estabelecida na rede. O modelo Default_CAC é bastante simples. Baseado nas informações contidas no contrato de tráfego que lhe é passado, o CAC identifica a categoria de serviço da conexão a ser estabelecida. Se a categoria de serviço for CBR, RT-VBR, NRT-VBR ou UBR, o CAC identifica o valor da taxa de pico de células (PCR) desejada para a conexão. Se a categoria de serviço for ABR, o CAC identifica a taxa mínima de células (MCR) desejada para a conexão. Baseado nestas informações o 98
  • CAC mapeia os descritores de tráfego originais para os descritores a serem utilizados no critério de aceitação do CAC (Tabela 4.1). Categoria de Serviço Descritor Mapeado Operação no Descritor Original CBR PCR PCR RT-VBR PCR PCR NRT-VBR PCR PCR ABR PCR MCR UBR PCR PCR/100 Tabela 4.1 – Mapeamento dos descritores de tráfego originais para os descritores a serem utilizados no critério de aceitação do CAC. Uma vez determinada a largura de faixa necessária para a nova conexão (descritor mapeado PCR), o CAC consulta os recursos disponíveis tanto nas estruturas de filas quanto nos escalonadores que se encontram no caminho desta conexão. O critério de aceitação de conexões do Default_CAC é: “O CAC aceitará a nova conexão se a largura de faixa disponível no escalonador for suficiente para atender a nova conexão (descritor mapeado PCR), independente dos recursos disponíveis na estrutura de filas”. Quando o Default_CAC é utilizado em conjunto com os escalonadores PGPS_Scheduler, WF2Q_Scheduler ou LFVC_Scheduler ele configura os pesos das conexões como: E φi = onde E é a largura de faixa necessária para a nova conexão. C Na seção 4.8 - , quando apresentarmos os blocos gerente, BTE e comutador discutiremos onde e quando o CAC é executado. 4.7.3.1.1 - Amostragens Estatísticas O Default_CAC não possui amostragens estatísticas, entretanto é possível acompanhar a as alocações de largura de faixa realizadas a partir das amostragens estatísticas dos modelos de escalonadores. 4.7.3.2 - Algoritmo de Controle de Admissão de Conexões Elwalid Mitra O algoritmo de controle de admissões de conexões Elwalid_Mitra_CAC – Elwalid Mitra Connection Admission Control também é utilizado para verificar se uma nova conexão ATM pode ou não ser estabelecida na rede. 99
  • O modelo Elwalid_Mitra_CAC uma implementação original baseada nos resultados obtidos por Anwar Elwalid, Debasis Mitra e Robert Wentworth em [17]. O trabalho de Elwalid et. al. apresenta um novo método para determinar a admissibilidade de conexões VBR. Para cada fluxo de tráfego regulado (através de traffic shaping) são alocados recursos de espaço em filas e de largura de faixa independentes de outras fontes de tráfego. As alocações de espaço em filas e de largura de faixa são ajustadas de forma ótima para situações de congestionamento, envolvendo um conhecimento mínimo a respeito de outras fontes. O tráfego VBR é dividido em duas classes, uma na qual a multiplexação estatística é efetiva e outra na qual a multiplexação estatística não é efetiva, no sentido de que a perda de células ocasionada pela multiplexação estatística é maior do que os requisitos de QoS do tráfego VBR. A esta classe cuja multiplexação estatística não é efetiva, os autores do trabalho chamaram de multiplexação sem perdas. Para cada fonte de tráfego VBR são determinados: uma largura de faixa efetiva (effective bandwidth) e um espaço em fila efetivo (effective buffer). Também são determinados os critérios de aceitação de conexões VBR. Nosso modelo expande de forma heurística estes resultados para todas as categorias de serviço. Isto é feito a partir de um mapeamento dos descritores de tráfego das categorias CBR, ABR e UBR para a categoria RT-VBR. Baseado nas informações contidas no contrato de tráfego que lhe é passado, o modelo Elwalid_Mitra_CAC identifica a categoria de serviço da conexão a ser estabelecida. Se a categoria de serviço for CBR o CAC identifica o valor da taxa de pico de células (PCR) e da taxa de perda de células (CLR) desejada para a conexão. Se a categoria de serviço for ABR, o CAC identifica a taxa mínima de células (MCR) desejada para a conexão. Se a categoria de serviço for UBR, o CAC identifica a taxa de pico de células (PCR) desejada para a conexão. A Tabela 4.2 mostra o mapeamento dos descritores de tráfego para as várias categorias de serviço. Categoria de Serviço Descritor Mapeado Operação no Descritor Original CBR PCR PCR*1,25 SCR PCR CLR CLR RT-VBR PCR PCR SCR SCR CLR CLR NRT-VBR PCR PCR SCR SCR CLR CLR ABR PCR MCR*1,25 SCR MCR CLR 1e-3 100
  • UBR PCR PCR SCR PCR/100 CLR 1e-2 Tabela 4.2 – Mapeamento dos descritores de tráfego originais para os descritores a serem utilizados no cálculo da largura de faixa efetiva e do espaço em gerenciador de tráfego efetivo. Uma vez determinados os descritores de tráfego mapeados para a nova conexão, o Elwalid_Mitra_CAC executa o fluxograma da Figura 4.33. Inicio CLR é menor que Sim Calcula e0 e b0 0? Não e0 < ed e Aceita Calcula e0 e b0 Sim Fim b0 < bd ? conexão Não Rejeita Calcula ej e bj conexão ej < ed e Não bj < bd ? Sim Figura 4.33 – Fluxograma do critério de aceitação de conexões do Elwalid_Mitra_CAC. Se o CLR for menor que 0, o Elwalid_Mitra_CAC calcula a largura de faixa efetiva (e0) e o espaço em fila efetivo (b0) para a classe com multiplexação sem perdas (lossless multiplexing). Se e0 for menor que a largura de fixa disponível no escalonador (ed) e se b0 for menor que o espaço em fila disponível na estrutura de filas (bd), a nova conexão será aceita. Caso contrário, a conexão será rejeitada. Se o CLR for maior que 0, o Elwalid_Mitra_CAC também calcula e0 e b0, que são utilizados para calcular a largura de faixa efetiva (ej) e o espaço em fila efetivo (bj) para a classe com multiplexação estatística (statistical multiplexing). Se ej for menor que a largura de fixa disponível no escalonador (ed) e se bj for menor que o espaço em fila disponível na estrutura de filas (bd), a nova conexão será aceita. Caso contrário, a conexão será rejeitada. A largura de faixa efetiva (e0) e o espaço em fila efetivo (b0) para classe com multiplexação sem perdas são calculados da seguinte forma: 101
  • C SCR 1) Se > , B BT onde C é a capacidade do escalonador em células/segundo, B é a capacidade da estrutura de filas em células, SCR é o descritor de tráfego sustainable cell rate e BT é o tamanho da fila de tokens do regulador (Leaky Bucket Traffic Shaping) (página 72 da referência [9])[10].  PCR BT (10)   SCR ≤  B/C 1 +  B / C .(PCR − SCR ) e0 =   BT     BT  SCR ≤ SCR < PCR  B/C  e − SCR  (11) b0 = BT − BT . 0   PCR − SCR  MBS (12) BT =  PCR   PCR − SCR    C SCR 2) Se ≤ : B BT e0 = SCR (13)  SCR.B C SCR (14)  C > .0,9  B BT b0 =  C SCR  BT ≤ .0,9   B BT A largura de faixa efetiva (ej) e o espaço em fila efetivo (bj) para a classe com multiplexação estatística são calculados da seguinte forma: C (15) ej = , K max j onde K max j é o número máximo de conexões admissíveis supondo que somente conexões da classe j sejam admitidas.  e j − SCR  (16) b j = BT − BT .  PCR − SCR     K max j é calculado de duas formas: 102
  • C SCR 1) Se > : B BT K max j é o valor de K para o qual  a  1 − a   1  (17) Fk ( S * ) = K a. log  + (1 − a ). log  = log ,   w  1 − w   SCR  onde C  (18)  e   a=  e 0 K SCR (19) w= . e0  1  O Elwalid_Mitra_CAC resolve a equação de Fk ( S * ) = log  usando o método de Newton-  SCR  Raphson [12]. C SCR 2) Se ≤ : B BT C (20) K max j = e0 Se o Elwalid_Mitra_CAC for utilizado em conjunto com o PGPS_Scheduler, WF2Q_Scheduler ou LFVC_Scheduler ele configura os pesos das conexões como e0 ej (21) φi = ou φ i = . C C Mais adiante, quando apresentarmos os blocos gerente, BTE e comutador discutiremos onde e quando o CAC é executado. 4.7.3.2.1 - Amostragens Estatísticas Assim como o Default_CAC, o Elwalid_Mitra_CAC não possui amostragens estatísticas, entretanto é possível acompanhar as alocações de largura de faixa realizadas a partir das amostragens estatísticas dos modelos de escalonadores. 103
  • 4.7.4 - Algoritmos de Gerenciamento de Estrutura de Filas O objetivo dos algoritmos de gerenciamento de estruturas de filas (também conhecidos como mecanismos de particionamento de buffers) é administrar de forma eficiente o espaço disponível em uma estrutura de filas e isolar o tráfego destinado a diferentes filas. Tal eficiência é conseguida através do compartilhamento do espaço físico disponível no maior número possível de filas. Alguns dos algoritmos de gerenciamento oferecem isolamento naturalmente, enquanto outros precisam ser acoplados a algoritmos de descarte seletivo de células mais inteligentes de maneira a prevenir que uma fila da estrutura utilize mais recursos do que o permitido e acabe estorvando outras filas. Existem centenas de algoritmos de gerenciamento de estruturas de filas. Entre eles podemos citar alguns dos fundamentais [9]: Particionamento Completo (complete partitioning) – Divide o espaço disponível de forma fixa para cada fila de estrutura. Mesmo que uma fila esteja desocupada, seu espaço não pode ser utilizado por outras filas. Neste algoritmo, o QoS de uma fila jamais será afetado pelo tráfego em outras filas. Compartilhamento Completo (complete sharing) – Todo o espaço disponível é compartilhado por todas as filas. Qualquer fila pode ocupar todo o espaço disponível. Neste algoritmo, o QoS de uma fila pode ser afetado pelo tráfego em outras filas. Compartilhamento com Alocação Mínima – Reserva um espaço mínimo para cada fila da estrutura. O espaço remanescente pode ser ocupado totalmente por qualquer uma das filas. Portanto, este algoritmo provê um certo nível de isolamento entre as filas. Compartilhamento com Tamanho Máximo de Filas – Cada fila da estrutura pode ocupar um espaço máximo. Quando este espaço é atingido, células serão descartadas mesmo que haja espaço disponível. Este algoritmo protege a estrutura de filas de um uso injusto do espaço disponível, porém não é eficiente, pois descarta células mesmo havendo espaço livre. Compartilhamento com Alocação Mínima e Tamanho Máximo de Filas – Este algoritmo é uma combinação dos dois anteriores e, portanto usufrui das vantagens dos dois mecanismos anteriores. O CMNC possui dois algoritmos de gerenciamento de estrutura de filas. São eles: 104
  • Algoritmo de Gerenciamento de Estrutura de Filas Default (Default_BM – Default Buffer Management). Algoritmo de Gerenciamento de Estrutura de Filas com Particionamento Dinâmico (Dynamic_Partitioning_BM – Dynamic Partitioning Buffer Management). 4.7.4.1 - Algoritmo de Gerenciamento de Estrutura de Filas Default O modelo Default_BM – Default Buffer Management implementa um algoritmo de compartilhamento completo. Como vimos, este algoritmo decide se uma célula pode ou não ser armazenada em uma estrutura de filas. O critério de aceitação do Default_BM é o seguinte: armazena uma célula somente se o número total de células na estrutura de filas somado de uma célula for menor ou igual a capacidade da estrutura de filas. 4.7.4.1.1 - Amostragens Estatísticas O Default_BM não possui amostragens estatísticas. 4.7.4.2 - Algoritmo de Gerenciamento de Estrutura de Filas com Particionamento Dinâmico O modelo Dynamic_Partitioning_BM – Dynamic Partitioning Buffer Management é uma implementação original baseada nos resultados obtidos por Santosh Krishnan, Abhijit Choundhury e Fabio Chiussi em [18]. O trabalho de Krishnan et. al. apresenta um novo esquema para determinar a admissibilidade de células ATM em uma estrutura de filas de uma memória compartilhada. Este novo esquema é semelhante ao particionamento com alocação mínima e tamanho máximo de filas, porém o tamanho das filas é estabelecido dinamicamente. Segundo [18], os principais objetivos do esquema são: Prover alocações de espaço diferenciadas para as filas que utilizam a memória compartilhada, de forma que estas alocações sejam derivadas diretamente dos parâmetros do algoritmo de CAC e satisfaçam diferentes critérios de perda de células. Permitir a existência conjunta de tráfego regulado (através de traffic shaping) e tráfego melhor-esforço (best-effort), obtendo alta eficiência de utilização da estrutura de filas sem violar as alocações mínimas para as conexões reguladas. Proteger conexões bem comportadas que respeitam suas alocações, de conexões mal comportadas. Gerenciar variações no comportamento do tráfego com relação ao que foi previsto pelo CAC, através da distribuição uniforme da perda de células nas várias filas da estrutura de filas. 105
  • No Dynamic Partitioning o tráfego é dividido em duas classes, uma na qual a multiplexação estatística é efetiva e outra na qual a multiplexação estatística não é efetiva, chamada de multiplexação sem perdas. O particionamento dinâmico utiliza duas alocações de espaço em fila derivadas do CAC: uma para a classe com multiplexação estatística (bj) e outra para a classe com multiplexação sem perdas (b0). Estas alocações podem ser derivadas de qualquer CAC, porém o Dynamic Partitioning foi desenvolvido com o objetivo de trabalhar em conjunto com o CAC desenvolvido por Elwalid, Mitra e Wentworth. Assim sendo, o modelo Dynamic_Partitioning_BM trabalha em conjunto com o modelo Elwalid_Mitra_CAC. Porém, é possível que o modelo Dynamic_Partitioning_BM seja utilizado em conjunto com outro modelo de CAC. Para isto basta fornecer as alocações de espaço em fila na forma de dados de tabela (veja a seção 2.2.1.4.). Ou seja, é necessário que o modelo de CAC escreva na sua tabela de dados o valor das duas alocações. O Dynamic_Partitioning_BM decide se uma célula pode ser armazenada ou não na estrutura de filas de acordo com um limiar calculado para a fila de cada conexão i. Portanto, o modelo Dynamic_Partitioning_BM só pode ser utilizado em conjunto com o modelo de estrutura de filas Per_VC_Queueing_Structure. Uma vez calculado o limiar, a célula será descartada se a ocupação da fila exceder o valor calculado. O limiar de aceitação de células do Dynamic_Partitioning_BM é dividido em duas partes, uma para células que pertençam a conexões da classe com multiplexação estatística e outra para conexões que pertençam a classe com multiplexação sem perdas. A Figura 4.34 ilustra a dinâmica do limiar de aceitação de células T(t) em função da ocupação total da estrutura de filas Q(t). T(t) T(t) b0,i α α µ b0,i bi Q(t) Q(t) γ γ Bf Bf (a) (b) Figura 4.34 – Dinâmica do limiar de aceitação de células para: a) classe com multiplexação sem perdas e b) classe com multiplexação estatística. Para a classe com multiplexação sem perdas o limiar é calculado da seguinte forma: b0,i + α (γ − Q(t ) ) Q (t ) ≤ γ (22) Ti (t ) =  ,  b0,i γ < Q (t ) ≤ B f 106
  • onde b0,i é a alocação de espaço em fila para a conexão i, α define a inclinação do limiar na região de Q(t) de 0 até γ, Q(t) é a ocupação total da estrutura de filas, γ define o ponto de ajuste do mecanismo e Bf é a capacidade total da estrutura de filas. Para a classe com multiplexação estatística o limiar é calculado da seguinte forma:  b0,i + α (γ − Q(t ) ) Q (t ) ≤ γ (22) Ti (t ) =  , b0,i − µ i (Q (t ) − γ ) γ < Q (t ) ≤ B f onde µi define a inclinação do limiar na região de Q(t) de γ até Bf. 4.7.4.2.1 - Amostragens Estatísticas O Dynamic_Partitioning_BM não possui amostragens estatísticas. 4.7.5 - Algoritmos de Descarte Seletivo de Células Quando uma célula é recebida em um ponto de acesso a uma estrutura de filas, uma decisão precisa ser tomada: armazenar ou descartar a célula recebida. Esta decisão é baseada na combinação de um ou mais dos seguintes fatores [9]: Prioridade da célula (bit CLP) para serviços que diferenciam o CLP, ou prioridade da classe de serviço se o tráfego de várias classes de serviço for misturado na mesma estrutura de filas. Medidas de ocupação da estrutura de filas combinadas com limiares de aceitação em filas. Estado do descarte de frames para serviços da AAL 5. Alternativamente, uma implementação mais complexa e eficiente consiste em armazenar todas as células recebidas. No caso de um congestionamento, descarta-se uma célula menos prioritária que encontra-se armazenada na estrutura de filas em favor da célula recebida. Se nenhuma das células recebidas é considerada mais importante que as células já armazenadas, então as células recebidas são descartadas. O conjunto de modelos no nível de células possui os seguintes algoritmos de descarte seletivo de células: Algoritmo de Descarte Seletivo de Células Default (Default_SD – Default Selective Discard). Algoritmo de Descarte Seletivo de Células Baseado no CLP (CLP_SD – Cell Loss Priority Selective Discard). 107
  • Algoritmo de Descarte Seletivo de Células Baseado no CLR (CLR_SD – Cell Loss Ratio Selective Discard). 4.7.5.1 - Algoritmo de Descarte Seletivo de Células Default O modelo Default_SD – Default Selective Discard implementa a solução mais simples de descarte de células. Ou seja, se o modelo de algoritmo de gerenciamento de estrutura de filas indicar que não há espaço para armazenar uma nova célula, ela será simplesmente descartada pelo Default_SD. Além de descartar células ATM, o modelo Default_SD preocupa-se com a situação em que todas as células ou a última célula de um pacote que indica final de transmissão de conexão seja descartada. Neste caso, o modelo Default_SD envia um evento para a camada AAL5 do bloco BTE de destino da conexão a que as células pertencem informando que todo o pacote foi deletado. Assim, a camada AAL5 pode realizar as amostragens estatísticas necessárias, bem como controlar o encerramento desta conexão. 4.7.5.1.1 - Amostragens Estatísticas O Default_SD não possui amostragens estatísticas. 4.7.5.2 - Algoritmo de Descarte Seletivo de Células Baseado no CLP As células ATM possuem um bit chamado CLP (Cell Loss Priority – Prioridade de Perda de Célula), que é utilizado para definir dois níveis de descarte de células na rede ATM. As células com CLP = 0 são consideradas mais prioritárias do que as células com CLP = 1. Portanto, em caso de congestionamento, as células com CLP = 1 são descartadas em prol das células com CLP = 0. Assim sendo, o modelo CLP_SD – Cell Loss Priority Selective Discard descarta células ATM de acordo com os seus bits CLP. O CLP_SD funciona integrado a um modelo de estrutura de filas (veja a seção 4.6.6.2 - ) Quando o CLP_SD é acionado para descartar uma célula ATM, primeiramente é verificado qual é o CLP desta célula. Se o CLP for = 1 ela é descartada. Caso contrário, é verificado qual é a conexão de rede desta célula (NCI). O CLP_SD procura então na estrutura de filas associada, se existe alguma célula desta conexão com CLP = 1. Se existir alguma célula desta conexão com CLP = 1, ela é descartada. Caso contrário, é verificado se existem células de outras conexões com CLP = 1 armazenadas na estrutura de filas. Se houverem, é descartada a célula que encontra-se a menos tempo aguardando pelo serviço na estrutura de filas. Caso contrário, a célula recebida pelo CLP_SD é descartada. O modelo CLP_SD implementa o descarte parcial de pacotes (PPD – Partial Packet Discard) [9]. Esta função é acionada através do parâmetro PPD. Quando esta função está ativada, todas as 108
  • células do mesmo pacote de uma célula descartada são descartadas também. O objetivo desta função é aumentar a eficiência das estruturas de filas, uma vez que nas redes ATM o descarte de uma célula causa a rejeição de um pacote inteiro. Portanto, não há razão de se continuar armazenando tais células. Assim como o modelo Default_SD, o modelo CLP_SD também preocupa-se com a situação em que todas as células ou a última célula de um pacote que indica final de transmissão de conexão seja descartada. 4.7.5.2.1 - Amostragens Estatísticas O CLP_SD não possui amostragens estatísticas. 4.7.5.3 - Algoritmo de Descarte Seletivo de Células Baseado no CLR As categorias de serviço CBR, RT-VBR e NRT-VBR possuem um parâmetro negociável de qualidade de serviço chamado CLR (Cell Loss Ratio). O modelo CLR_SD – Cell Loss Ratio Selective Discard descarta células ATM de acordo com o CLR negociado para uma determinada conexão. Assim como o CLP_SD, o CLR_SD funciona integrado a um modelo de estrutura de filas. Quando o CLR_SD é acionado para descartar uma célula ATM, primeiramente é verificado qual é o CLR da conexão desta célula ATM. Em seguida o CLR_SD procura na estrutura de filas qual é a conexão que possui maior CLR. Se a conexão que possuir maior CLR for a conexão da célula que chegou, esta célula será descartada. Caso contrário, é verificado se a estrutura de filas possui células armazenadas da conexão que possui maior CLR. Se existirem células desta conexão, o CLR_SD descartará a célula que encontra-se a mais tempo armazenada na estrutura de filas. Assim como o modelo CLP_SD, o modelo CLR_SD também implementa o descarte parcial de pacotes (PPD). O modelo CLR_SD também preocupa-se com a situação em que todas as células ou a última célula de um pacote que indica final de transmissão de conexão seja descartada. 4.7.5.3.1 - Amostragens Estatísticas O CLR_SD não possui amostragens estatísticas. 4.7.6 - Algoritmos de Policiamento de Tráfego Uma rede ATM precisa assegurar que o tráfego recebido de seus usuários está de acordo com o que foi negociado durante a fase de estabelecimento das conexões, uma vez que ela garante largura de faixa e qualidade de serviço para as células que estiverem em conformidade. Para fazer isso, a rede ATM atua sobre as células não conformes por meio de uma função de policiamento de tráfego (TP – Traffic Policing), que também pode ser chamada de função de controle de utilização 109
  • de parâmetros (UPC – Usage Parameter Control). O policiamento é geralmente realizado na interface UNI (User-to-Network Interface), embora também possa ser realizado entre duas redes. Neste caso, a função de policiamento também é chamada de controle de parâmetros da rede (NPC – Network Parameter Control). Na prática, o policiamento de tráfego é realizado somente na entrada da rede ou logo após a um algoritmo de formatação de tráfego. O policiamento de tráfego é uma função não intrusiva, ou seja, não atrasa ou modifica as características de um determinado fluxo de células, a não ser pela remoção de células não conformes e pela mudança do bit de prioridade CLP. O CMNC possui um modelo de algoritmo de policiamento de tráfego: policiador leaky bucket (Leaky_Bucket_TP – Leaky Bucket Traffic Policer). 4.7.6.1 - Policiador Leaky Bucket O algoritmo do “balde furado” ou leaky bucket [9] é baseado na seguinte analogia. Um “balde” de tamanho B é enchido com I unidades toda vez que uma célula ATM é recebida, e perde constantemente uma unidade a cada unidade de tempo. O “balde” tem a capacidade finita de L unidades. Se uma célula for recebida e a capacidade do balde for menor ou igual a L, então a célula recebida é dita conforme. Caso contrário, a célula é considerada não conforme. O “balde” transborda quando a taxa de chegada de células é maior que a sua taxa de drenagem. O algoritmo é executado toda vez que uma nova célula é recebida e, portanto, o enchimento e a drenagem do “balde” são feitos de acordo com o instante de tempo da chegada da última célula conforme (LCT – Last Conforming Time). Ou seja, quando uma célula é recebida no instante Time, o “balde” esvazia de (Time–LCT), o que é equivalente a continuamente esvaziar o “balde” uma unidade a cada unidade de tempo. Uma ocupação negativa do “balde” é resultado da chegada antecipada de uma célula. Neste caso, é necessário esvaziar todo o “balde” a fim de prevenir o acúmulo de créditos, que acarreta a geração de longos surtos de células (bursts). Se a célula recebida é considerada conforme, o “balde” é enchido de I unidades. O gerenciador de tráfego Leaky_Bucket_TP implementa este algoritmo para verificar se células pertencentes a conexões de diferentes categorias de serviço estão conformes com os descritores de tráfego negociados. A estrutura do policiador leaky bucket é mostrada na Figura 4.35. 110
  • Policiador de Tráfego Leaky Bucket Policiador A Célula Célula Célula Célula Célula Célula (CBR.1, ABR.1 e UBR.1) Células conformes. Policiador B Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula Célula (VBR.1) Célula Célula Célula Célula Célula Célula Célula Policiador C Célula Célula (VBR.2) Policiador D Células não Célula Célula Célula Célula (VBR.3) conformes. Figura 4.35 – Estrutura do Leaky_Bucket_TP. O Leaky_Bucket_TP possui quatro policiadores: Policiador A – Modela um algoritmo Leaky Bucket para as definições de conformidade CBR.1, ABR.1 e UBR.1 (veja a [9]), das categorias de serviço CBR, ABR e UBR, respectivamente. Policiador B – Modela um algoritmo Dual Leaky Bucket para a definição de conformidade VBR.1, das categorias de serviço rt-VBR e nrt-VBR. Policiador C – Modela um algoritmo Dual Leaky Bucket para a definição de conformidade VBR.2, das categorias de serviço rt-VBR e nrt-VBR. Policiador D – Modela um algoritmo Dual Leaky Bucket para a definição de conformidade VBR.3, das categorias de serviço rt-VBR e nrt-VBR. O policiador A é um policiador simples, ou seja, somente espaça as células de acordo com os descritores de tráfego PCR (Peak Cell Rate) e CDVT (Cell Delay Variation Tolerance). O policiador A equivale a um algoritmo GCRA (1/PCR, CDVT), onde o incremento I é igual a 1/PCR e o tamanho do “balde” L é igual ao CDVT. Os policiadores B, e C e D são policiadores duplos, ou seja, policiam as células de acordo com os descritores de tráfego PCR, CVDT, SCR (Sustainable Cell Rate) e MBS (Maximum Burst Size). Estes policiadores equivalem a um algoritmo GCRA (1/PCR, CDVT) em série com um algoritmo GCRA (1/SCR, BT-CDVT). A Figura 4.36a mostra o algoritmo implementado para o policiador A. Quando uma célula ATM é recebida, o policiador A busca o valor atual das variáveis LCT e B para a sua conexão. Se o LCT for igual a zero, ele é configurado com o valor do tempo de chegada da célula (Time). Feito 111
  • isso, é verificado se o valor da ocupação do “balde” B menos a diferença entre o tempo de chegada da célula e o LCT é maior que o CDVT. Se esta condição for verdadeira, a célula é considerada não conforme e marcada para ser descartada por um algoritmo de descarte seletivo. Se a condição for falsa, a célula é considerada conforme. Neste caso, é calculada a nova ocupação do “balde”, o LCT é atualizado para o instante de tempo de chegada da célula, e as variáveis LCT e B são gravadas para serem consultadas quando a próxima célula for recebida. Recebe uma célula Recebe uma célula Busca valor do LCT e B Busca valor do LCT, Bp e para a conexão. Bs para a conexão. LCT = 0 ? LCT = 0 ? Sim Sim Não Não Célula não conforme. B-(Time-LCT) > Bp-(Time-LCT) > Sim LCT=Time LCT=Time Descarta célula. CDVT? CDVT? Sim Não Não Célula conforme. B=max(0,B-(Time-LCT))+CDVT Célula não conforme. Bs-(Time-LCT) > Sim Descarta célula. BT+CDVT? LCT=Time Não Célula conforme. Bp=max(0,Bp-(Time-LCT))+CDVT Grava valor do LCT e do B para a conexão. Bs=max(0,Bs-(Time-LCT))+1/SCR End LCT=Time a) Policiador A (CBR.1, ABR.1 e UBR.1) Grava valor do LCT, Bp e LCT - Last Conformance Time Bs para a conexão. Bp - Bucket Size for PCR Bs - Bucket Size for SCR PCR - Peak Cell Rate End SCR - Sustainable Cell Rate MBS - Maximum Burst Size BT - Burst Tolerance b) Policiador B (VBR.1) Figura 4.36 – Algoritmos implementados para os policiadores: a) A (CBR.1, ABR.1 e UBR.1) e b) B (VBR.1). A Figura 4.36b mostra o algoritmo implementado para o policiador B. Como o policiador B é um policiador duplo, três variáveis são utilizadas ao invés de duas: LCT, Bp e Bs. Portanto, no policiador B existe não apenas um “balde” de tamanho máximo CDVT, mas sim dois baldes: um para o PCR (de tamanho máximo CDVT) e outro para o SCR (de tamanho máximo BT+CDVT). As variáveis Bp e Bs correspondem respectivamente à ocupação dos “baldes” para o PCR e o SCR. Quando uma célula ATM é recebida, o policiador B também busca o valor atual destas variáveis e verifica se o LCT é igual a zero. Da mesma forma que no policiador A, se o LCT for igual a zero ele é configurado com o valor do tempo de chegada da célula (Time). Feito isso, é verificado se o valor da ocupação do “balde” para o PCR (Bp) menos a diferença entre o tempo de chegada da célula (Time) e o LCT é maior que o CDVT. Se esta condição for verdadeira, a célula é considerada 112
  • não conforme e marcada para ser descartada por um algoritmo de descarte seletivo. Se a condição for falsa, a célula é considerada conforme com relação ao PCR. Em seguida, é verificado se a célula está conforme com relação ao SCR. Se o valor da ocupação do “balde” para o SCR (Bs) menos a diferença entre o tempo de chegada da célula (Time) e o LCT é maior que o CDVT acrescido do BT, a célula é considerada não conforme e marcada para ser descartada. Porém, se a condição for falsa, a célula é considerada conforme com relação ao SCR. Então, são calculadas as novas ocupações para os “baldes” Bp e Bs, o LCT é atualizado para o instante de tempo de chegada da célula, e as variáveis LCT, Bp e Bs são gravadas na tabela do policiador para serem consultadas quando a próxima célula for recebida. A Figura 4.37 mostra o algoritmo implementado para o policiador C. Assim como o policiador B, o policiador C é um policiador duplo, entretanto quatro variáveis são utilizadas ao invés de três: LCTp, LCTs, Bp e Bs. As variáveis LCTp e LCTs são respectivamente os tempos de chegada da última célula conforme para os “baldes” do PCR e do SCR. Quando uma célula ATM é recebida, o policiador C busca o valor atual destas variáveis e verifica se o LCTp é igual a zero. Se o LCTp for igual a zero ele é configurado com o valor do tempo de chegada da célula (Time). Feito isso, é verificado se o valor da ocupação do “balde” para o PCR (Bp) menos a diferença entre o tempo de chegada da célula (Time) e o LCTp é maior que o CDVT. Se esta condição for verdadeira, a célula é considerada não conforme e marcada para ser descartada. Se a condição for falsa, a célula é considerada conforme com relação ao PCR. Em seguida, é verificado qual é o valor do bit de prioridade da célula (CLP). Se o CLP da célula for igual a um, é calculada a nova ocupação do “balde” Bp, o LCTp é atualizado para o instante de tempo de chegada da célula, e as variáveis LCTp, LCTs, Bp e Bs são gravadas para serem consultadas quando a próxima célula for recebida. Se o CLP da célula for igual a zero, o policiador C verifica se o LCTs é igual a zero. Se o LCTs for igual a zero ele é configurado com o valor do tempo de chegada da célula (Time). Feito isso, é verificado se o valor da ocupação do “balde” para o SCR (Bs) menos a diferença entre o tempo de chegada da célula (Time) e o LCTs é maior que o CDVT+BT. Se esta condição for verdadeira, a célula é considerada não conforme em relação ao SCR e marcada para ser descartada. Se a condição for falsa, a célula é considerada conforme. Então, são calculadas as novas ocupações para os “baldes” Bp e Bs, o LCTp e o LCTs são atualizados para o instante de tempo de chegada da célula, e as variáveis LCTp, LCTs, Bp e Bs são gravadas para serem consultadas quando a próxima célula for recebida. 113
  • Recebe uma célula LCTp - Last Conformance Time for PCR LCTs - Last Conformance Time for SCR Bp - Bucket Size for PCR Busca valor do LCTp, Bs - Bucket Size for SCR LCTs, Bp e Bs para a conexão. PCR - Peak Cell Rate SCR - Sustainable Cell Rate MBS - Maximum Burst Size BT - Burst Tolerance LCTp = 0 ? Sim Não Bp-(Time-LCTp) > LCTp=Time CDVT? Sim Não Célula não conforme. CLP = 1? Não LCTs = 0 ? Descarta célula. Sim Sim Não Célula conforme. LCTs=Time Bp=max(0,Bp-(Time-LCTp))+CDVT LCT=Time Bs-(Time-LCTs) > Célula não conforme. Sim BT+CDVT? Descarta célula. Não Célula conforme. Bp=max(0,Bp-(Time-LCT))+CDVT Bs=max(0,Bs-(Time-LCT))+1/SCR Grava valor do LCTp, LCTp=Time LCTs, Bp e Bs para a LCTs=Time conexão. End Policiador C (VBR.2) Figura 4.37 – Algoritmo implementado para o policiador C (VBR.2). A Figura 4.38 mostra o algoritmo implementado para o policiador D. Este policiador é praticamente igual ao policiador C. A única diferença diz respeito ao que acontece quando uma célula é considerada não conforme pelo algoritmo do “balde” para o SCR. Ao invés de descartar a célula, o policiador D atua marcando a célula, ou seja, trocando o bit CLP da célula de zero para um. Feito isso, é calculada a nova ocupação do “balde” Bp, o LCTp é atualizado para o instante de tempo de chegada da célula, e as variáveis LCTp e Bp são gravadas para serem consultadas quando a próxima célula for recebida. 114
  • Recebe uma célula LCTp - Last Conformance Time for PCR LCTs - Last Conformance Time for SCR Bp - Bucket Size for PCR Busca valor do LCTp, Bs - Bucket Size for SCR LCTs, Bp e Bs para a conexão. PCR - Peak Cell Rate SCR - Sustainable Cell Rate MBS - Maximum Burst Size BT - Burst Tolerance LCTp = 0 ? Sim Não Bp-(Time-LCTp) > LCTp=Time CDVT? Sim Não Célula não conforme. CLP = 1? Não LCTs = 0 ? Descarta célula. Sim Sim Não Célula conforme. LCTs=Time Bp=max(0,Bp-(Time-LCTp))+CDVT LCT=Time Bs-(Time-LCTs) > Célula conforme. Sim BT+CDVT? Configura CLP para 1. Não Bp=max(0,Bp-(Time-LCTp))+CDVT Célula conforme. Bp=max(0,Bp-(Time-LCTp))+CDVT LCTp=Time LCTs=Time Bs=max(0,Bs-(Time-LCTs))+1/SCR Grava valor do LCTp e Bp Grava valor do LCTp, para a conexão. LCTp=Time LCTs, Bp e Bs para a LCTs=Time conexão. End Policiador D (VBR.3) Figura 4.38 – Algoritmo implementado para o policiador D (VBR.3). 4.7.6.1.1 - Amostragens Estatísticas O Leaky_Bucket_TP não possui amostragens estatísticas. 4.8 - Blocos O conjunto de modelos no nível de células possui sete blocos. Como vimos, estes blocos estão divididos em 3 tipos: Aplicativos Equipamentos 115
  • Gerentes 4.8.1 - Aplicativos São os requerentes de conexões chaveadas e os transmissores de tráfego da rede ATM. O CMNC possui quatro modelos de aplicativos, três deles denominados conforme a sua camada fonte de tráfego e um aplicativo que é utilizado apenas para receber o tráfego no destino da rede. 4.8.1.1 - Aplicativo Determinístico O modelo Deterministic_App – Deterministic Application possui uma camada fonte de tráfego determinístico. A Figura 4.39 ilustra a estrutura do aplicativo determinístico. Aplicativo Determinístico Camada Requeredora e Removedora de Conexões Camada Finalizadora de Conexões Camada Fte de Tráfego Determinístico Camada Receptora de Tráfego Figura 4.39 – Estrutura do aplicativo determinístico. 4.8.1.2 - Aplicativo Poissoniano O modelo Poissonian_App – Poissonian Application possui uma camada fonte de tráfego poissoniana. A Figura 4.40 ilustra a estrutura do aplicativo poissoniano. Aplicativo Poissoniano Camada Requeredora e Removedora de Conexões Camada Finalizadora de Conexões Camada Fonte de Tráfego Poissoniano Camada Receptora de Tráfego Figura 4.40 – Estrutura do aplicativo poissoniano. 116
  • 4.8.1.3 - Aplicativo Externo O modelo External_App – External Application possui uma camada fonte de tráfego externo. A Figura 4.41 ilustra a estrutura do aplicativo externo. Aplicativo Externo Camada Requeredora e Removedora de Conexões Camada Finalizadora de Conexões Camada Fonte de Tráfego Externo Camada Receptora de Tráfego Figura 4.41 – Estrutura do aplicativo externo. 4.8.1.4 - Aplicativo Receptor O modelo Receiver_App – Receiver Application possui apenas duas camadas: camada removedora de conexões e camada receptora de tráfego. A Figura 4.42 ilustra a estrutura do aplicativo receptor. Aplicativo Receptor Camada Finalizadora de Conexões Camada Receptora de Tráfego Figura 4.42 – Estrutura do aplicativo receptor. 4.8.2 - Equipamentos O conjunto de modelos no nível de células possui dois modelos de equipamentos: terminal faixa larga e comutador ATM. 117
  • 4.8.2.1 - Terminal Faixa Larga Como vimos anteriormente, o BTE – Broadband Terminal Equipment é um modelo de dispositivo de borda da rede ATM, como por exemplo, um cartão de interface com a rede (NIC – Network Interface Card). A Figura 4.43 ilustra a estrutura do BTE. Terminal Faixa Larga Modelos Internos AAL Camada de Adaptação ATM AAL Camada ATM Camada ATM Camada ATM Camada Física de Camada Física de Entrada Saída Camadas Físicas Estrutura de Fila Estruturas de Filas Escalonador Escalonadores Controle de Controle de Admissão Camada de Conexões Admissão de Física Conexões Gerencimento de Gerenciamento de Estrutura de Filas Estrutura de Filas Descarte Seletivo de Células Descarte Seletivo Policiamento de Tráfego Policiamento Entrada Saída Porta de Porta de Figura 4.43 – Estrutura do BTE. O BTE aciona o modelo CAC da porta de saída sempre que forem recebidas requisições de largura de faixa e que a conexão de blocos que está sendo investigada tiver como camada de inicio ou de fim a camada física de saída. 4.8.2.2 - Comutador Como vimos anteriormente, o Switch – Switch é um modelo de dispositivo de comutação de células da rede ATM. A Figura 4.44 ilustra a estrutura do comutador. 118
  • Modelos Internos Comutador Controle de Controle de Admissão de Conexões Admissão de Conexões Gerencimento de Gerenciamento de Estrutura de Filas Estrutura de Filas Descarte Seletivo de Células Descarte Seletivo Camada ATM Escalonador Estrutura de Fila Escalonadores Escalonador Camada ATM Camada ATM Camada Física de Camada Física de Entrada Saída Camadas Físicas Estrutura de Fila Estrutura de Fila Estruturas de Filas Escalonador Escalonador Escalonadores Controle de Controle de Admissão Controle de Admissão Camada de Conexões de Conexões Admissão de Física Conexões Gerencimento de Gerencimento de Gerenciamento de Estrutura de Filas Estrutura de Filas Estrutura de Filas Descarte Seletivo Descarte Seletivo de Células de Células Descarte Seletivo Policiamento de Policiamento de Tráfego Tráfego Policiamento Porta de Entrada Porta de Saída Figura 4.44 – Estrutura do comutador. O Switch aciona o modelo CAC de uma das portas de saída sempre que forem recebidas requisições de largura de faixa e que a conexão de blocos que está sendo investigada tiver como camada de inicio ou de fim a camada física de saída. O número da porta é que identifica o modelo de CAC a ser acionado. Para a porta de entrada, o acionamento de um modelo de CAC funciona da mesma forma. 4.8.3 - Gerente O CMNC possui somente um modelo de gerente. 4.8.3.1 - Gerente O Manager – Manager centraliza as funções de estabelecimento e de remoção de conexões na rede. Para isto, o modelo gerente implementa um modelo de protocolo de roteamento que chamamos de Protocolo de Roteamento do Primeiro Caminho com Qualidade de Serviço. Este protocolo encontra um 119
  • caminho na rede que seja capaz de atender aos pré-requisitos de QoS desejados para um nova conexão ATM. O primeiro caminho encontrado que atende a estes pré-requisitos é aceito. Na seção a seguir descreveremos o funcionamento deste protocolo. O Manager também se preocupa em configurar os parâmetros globais da rede. Parâmetros globais são parâmetros que podem ser consultados ou modificados por qualquer um dos modelos presentes no ambiente de simulação. Três parâmetros globais são utilizados: Path – Configura o diretório (por exemplo: c:usersalbertisimulation) aonde os arquivos de entrada e de saída serão lidos/escritos. Simulation_Name – Configura um nome para a simulação que está sendo realizada. Este parâmetro é bastante útil quando se realiza simulações em laço, onde uma mesma rede é simulada várias vezes. Manager_Name – Identifica o nome do modelo gerente para que os outros modelos presentes no ambiente de simulação possam enviar seus eventos. 4.9 - Funcionamento Uma vez que todos os modelos do CMNC já foram apresentados, nesta seção descreveremos o funcionamento do conjunto de modelos como um todo. A Figura 4.45 mostra um exemplo de uma rede simples com seis aplicativos (App_0 até App_5), quatro terminais faixa larga (BTE_0 até BTE_3), um comutador ATM (Switch_0) e um gerente de rede (Manager_0). A Figura 4.46 mostra os modelos internos de cada bloco desta rede. Basicamente, o CMNC funciona de acordo com três fases distintas: 1) Estabelecimento das Conexões – Como vimos anteriormente, são os aplicativos que iniciam o processo de estabelecimento de conexões na rede. Consideremos a requisição de uma conexão de dados a partir do aplicativo fonte App_0 até o aplicativo de destino App_4. Para que esta conexão seja estabelecida, é necessário que uma conexão de rede (ATM) entre os terminais de ingresso (BTE_0) e de egresso (BTE_2) também seja estabelecida. Para estabelecer estas conexões, a camada requerente e removedora de conexões do aplicativo App_0 envia para o bloco gerente um evento contendo os blocos de origem e de destino da conexão de rede e da conexão de dados, bem como um contrato de tráfego contendo os pré-requisitos de QoS para a conexão de rede. O gerente então aciona o Protocolo de Roteamento do Primeiro Caminho com Qualidade de Serviço para tentar encontrar uma conexão apropriada entre o aplicativo fonte (App_0) 120
  • e o aplicativo de destino (App_4). O ponto de partida do protocolo de roteamento é o aplicativo fonte, que chamaremos de bloco que está sendo investigado. O protocolo identifica os blocos vizinhos a este bloco (no caso BTE_0 e App_1). Se um dos blocos vizinho for um aplicativo (App_1), o protocolo de roteamento verifica se este não é o aplicativo de destino procurado4. Se um dos blocos vizinho ao bloco que está sendo investigado for um terminal ou um comutador o protocolo aciona estes blocos para que eles executem os algoritmos de CAC associados à porta relativa a conexão de blocos entre os blocos em questão (conexão 1 da Figura 4.45). Ou seja, são acionados os modelos de CAC cuja porta esteja relacionada a conexão de blocos entre o bloco que está sendo investigado e o seu bloco vizinho. Se um dos algoritmos de CAC não aprovar a nova conexão, o protocolo procurará outro bloco terminal ou comutador que seja vizinho do bloco que está sendo investigado (no caso da Figura 4.45 não há nenhum terminal que possa ser utilizado). Se não houver mais nenhum bloco vizinho ou que aceite a nova conexão de rede, a tentativa de criar as conexões terá falhado. Se todos os modelos de CAC aprovarem a nova conexão, o protocolo avança na direção deste bloco vizinho (bloco BTE_1), que passa a ser o bloco investigado. A busca prossegue até que o aplicativo de destino seja encontrado. Neste ponto, são criadas a conexão de rede e a conexão de dados. O protocolo de roteamento implementado realiza o cranckback, ou seja, pode retornar para blocos anteriores caso um dos blocos que está no caminho escolhido rejeite a nova conexão de rede. Por exemplo, se o BTE_2 rejeitasse, o protocolo tentaria encontrar um caminho alternativo a partir do bloco BTE_3. Uma vez estabelecidas as conexões, a camada fonte de tráfego do aplicativo fonte, começa a transmitir pacotes para a camada de adaptação ATM do bloco terminal de ingresso da rede (BTE_0). Esta camada também informa a camada AAL do terminal de egresso (BTE_2) a respeito do número de pacotes transmitidos durante o período em que as conexões permanecerem ativas. 2) Transmissão de Dados – No terminal de ingresso (BTE_0), os pacotes são adaptados em células ATM e enviados para a camada ATM. Na camada ATM do BTE, o cabeçalho das células é configurado com o campo NCI de acordo com a conexão de rede estabelecida, e estas são então enviadas para a camada física de saída deste terminal. Neste ponto, é executado o modelo do algoritmo de gerenciamento de estrutura de filas, a fim verificar se uma nova célula pode ser armazenada na estrutura de filas deste 4 Aplicativos conectados a um mesmo BTE não podem estabelecer conexão de rede. 121
  • terminal. Se o algoritmo de gerenciamento de estrutura de filas decidir que a nova célula não pode ser armazenada, é executado o modelo de algoritmo de descarte seletivo de células. Dependendo do modelo de descarte seletivo utilizado, será descartada a célula recém recebida ou uma outra célula de menor prioridade que já se encontra armazenada na estrutura de filas. Por outro lado, se o algoritmo de gerenciamento de estrutura de filas decidir que a nova célula pode ser armazenada, ela é então encaminhada tanto para o modelo de estrutura de filas, quanto para o modelo de escalonador. Como vimos na seção 4.6.7 - , a principal razão para que esta célula seja encaminhada para ambos os modelos, é que enquanto a estrutura de filas modela o armazenamento das células ATM, o escalonador modela independentemente a execução do serviço destas células. Após um certo tempo, o modelo de escalonador determina de acordo com o seu algoritmo de escalonamento o inicio do serviço da célula ATM. Feito isso, a célula é encaminhada de volta para a camada física de saída, onde um atraso de propagação é calculado. Na seqüência, a célula é então enviada para o próximo bloco da rede, no caso o comutador Switch_0 mostrado na Figura 4.46. Neste comutador, a célula é enviada diretamente para a camada ATM do comutador, que verifica se a célula recebida pode ser armazenada na estrutura de filas da camada ATM, que é compartilhada por todas as portas de saída da matriz de comutação. Novamente, esta função é realizada por um modelo de algoritmo de gerenciamento de estrutura de filas. Se este algoritmo de gerenciamento de estrutura de filas decidir que a nova célula não pode ser armazenada, é executado então o modelo de algoritmo de descarte seletivo de células. Por outro lado, se o algoritmo de gerenciamento de estrutura de filas decidir que a célula pode ser armazenada, primeiramente é feita a comutação da célula para a porta de saída apropriada (Porta 0 ou 1). Posteriormente, a célula é encaminhada para o modelo de estrutura de filas e para o modelo de escalonador associado a esta porta de saída. Após um certo tempo, o modelo de escalonador apropriado determina de acordo com o seu algoritmo de escalonamento o inicio do serviço da célula ATM. Feito isso, a célula é encaminhada de volta para a camada ATM do comutador, de onde será enviada para a camada física de saída. Nesta camada a célula é tratada da mesma forma que na camada física de saída do terminal de ingresso. A célula é então enviada para o terminal de egresso da rede, onde o processo de remontagem dos pacotes é executado. 3) Remoção das Conexões – Na camada AAL do terminal de egresso da rede é monitorado o recebimento da última célula ATM de cada pacote. No momento da chegada desta 122
  • célula, é verificado se o número de pacotes recebidos com sucesso, acrescido do número de pacotes descartados, é igual ao número de pacotes transmitidos pela camada fonte de trafego do aplicativo App_0. Se a condição for falsa, o período de atividade das conexões é mantido. Se esta condição for verdadeira, o período de atividade das conexões é considerado terminado e a camada AAL avisa a camada finalizadora de conexões do aplicativo App_4 de que as conexões de rede e de dados devem ser removidas. A camada finalizadora de conexões, por sua vez, avisará a camada requerente e removedora de conexões, que realizará amostragens estatísticas, agendará um evento requisitando o estabelecimento de novas conexões a partir de um determinado intervalo de tempo e enviará um evento para o bloco gerente solicitando a remoção das conexões. Então, o bloco gerente remove as conexões e aciona os algoritmos de CAC dos blocos terminal e comutador da rede, a fim de que estes liberem os recursos alocados para as conexões. 1 2 4 3 Figura 4.45 – Exemplo de uma rede ATM simples. 123
  • Aplicativo Fonte (App_0) Pacotes Gerente Camada Requeredora e Removedora (Manager_0) de Conexões Pacotes Camada Finalizadora de Conexões Aplicativo Destino (App_4) Comutador (Switch_0) Camada Fonte de Tráfego Camada Finalizadora de Conexões Controle de Admissão Matriz de de Conexões Comutação com Memória Camada Receptora de Tráfego Compartilhada Camada Receptora de Tráfego Gerencimento de Estrutura de Filas Policiamento Descarte Seletivo de Células ATM_OUT_TP_S BTE Ingresso (BTE_0) Escalonador BTE Egresso (BTE_2) Estrutura de Fila Camada de Adaptação ATM Escalonador Camada de Adaptação ATM Camada ATM Células Camada ATM Células Camada ATM ATM ATM Camada Física de Camada Física de Camada Física de Camada Física de Camada Física de Camada Física de Entrada Saída Entrada Saída Entrada Saída Estrutura de Fila Estrutura de Fila Estrutura de Fila Estrutura de Fila Escalonador Escalonador Escalonador Escalonador Controle de Admissão Controle de Admissão Controle de Admissão Controle de Admissão de Conexões de Conexões de Conexões de Conexões Gerencimento de Gerencimento de Gerencimento de Gerencimento de Estrutura de Filas Estrutura de Filas Estrutura de Filas Estrutura de Filas Descarte Seletivo Descarte Seletivo Descarte Seletivo Descarte Seletivo de Células de Células de Células de Células Policiamento Policiamento Policiamento Policiamento Gerenciadores de Caminho percorrido Camadas Tráfego pelas células ATM Figura 4.46 – Estrutura interna dos blocos da rede ATM simples. 4.10 - Alocação Dinâmica de Modelos Internos A Figura 4.47 mostra em quais funções de comportamento do bloco são criadas (instanciadas) as camadas e gerenciadores de tráfego dos blocos aplicativo, terminal e comutador. 124
  • Aplicativo Gerente Camada Requeredora e Removedora de Conexões Camada Finalizadora de Conexões Comutador Camada Fonte de Tráfego Controle de Admissão de Conexões Matriz de Comutação com Camada Receptora de Tráfego Memória Gerencimento de Compartilhada Estrutura de Filas Descarte Seletivo de Células Terminal Faixa Larga Escalonador Estrutura de Fila Camada de Adaptação ATM Escalonador Camada ATM Camada ATM Camada Física de Camada Física de Entrada Saída Camada Física de Camada Física de Entrada Saída Estrutura de Fila Estrutura de Fila Estrutura de Fila Escalonador Escalonador Escalonador Controle de Admissão de Conexões Controle de Admissão Controle de Admissão de Conexões de Conexões Gerencimento de Estrutura de Filas Gerencimento de Gerencimento de Estrutura de Filas Estrutura de Filas Descarte Seletivo de Células Descarte Seletivo Descarte Seletivo de Células de Células Policiamento de Policiamento de Policiamento de Tráfego Tráfego Tráfego Modelos instânciados na função de criação (Setup) do bloco. Modelos instânciados durante a execução da função de estabelecimento de conexão (OnConnect) do bloco. Figura 4.47 – Alocação dinâmica de camadas e de gerenciadores de tráfego no CMNC. Os modelos não hachurados são instanciados quando o bloco executa a sua função de criação (Setup). Os modelos hachurados são instanciados quando o bloco executa a sua função de estabelecimento de conexão de blocos (OnConnect). Nesta função são instanciados os modelos default de estruturas de filas, escalonadores, algoritmos de controle de admissão de conexões ATM, algoritmos de gerenciamento de estruturas de filas, algoritmos de descarte seletivo e de algoritmos de policiamento de tráfego. Entretanto, é possível trocar os modelos alocados durante a execução destas duas funções. Isso é feito a partir da troca de parâmetros nos blocos. Se um destes parâmetros for modificado, o modelo default existente será removido, e um novo modelo será alocado. A troca de modelos é feita quando o bloco executa a função de troca de parâmetros (OnChangeParameters). Somente os modelos hachurados podem ser trocados nesta fase. 125
  • 4.11 - Nomenclatura dos Modelos O conjunto de modelos no nível de células utiliza uma nomenclatura própria para identificar os modelos internos aos blocos de equipamentos ATM. Utilizaremos a estrutura do modelo comutador (Figura 4.48) para explicar esta nomenclatura. O modelo do comutador é dividido em dois lados: entrada e saída. Cada um dos lados possui várias portas. No caso do comutador, alguns modelos internos são compartilhados por todas as portas de um determinado lado. Comutador ATM_OUT_SD_S Descarte Seletivo Modelos Gerenciamento de ATM_OUT_BM_S compartilhados Estrutura de Filas pelas portas de Controle de saída ATM_OUT_CAC_S Admissão de Camada Conexões ATM ATM_OUT_QS_S Estruturas de Filas ATM_OUT_S_0 ATM_OUT_S_1 Escalonadores ATM Camada ATM PHY_IN PHY_OUT Camadas Físicas PHY_IN_QS_0 PHY_IN_QS_1 PHY_OUT_QS_0 PHY_OUT_QS_1 Estruturas de Filas PHY_IN_S_0 PHY_IN_S_1 PHY_OUT_S_0 PHY_OUT_S_1 Escalonadores Camada Física Controle de PHY_IN_CAC_0 PHY_IN_CAC_1 PHY_OUT_CAC_0 PHY_OUT_CAC_1 Admissão de Conexões Gerenciamento de PHY_IN_BM_0 PHY_IN_BM_1 PHY_OUT_BM_0 PHY_OUT_BM_1 Estrutura de Filas PHY_IN_SD_0 PHY_IN_SD_1 PHY_OUT_SD_0 PHY_OUT_SD_1 Descarte Seletivo Entrada 0 Entrada 1 Porta de Porta de Porta de Saída 0 Porta de Saída 1 Figura 4.48 – Nomenclatura dos modelos internos do bloco comutador. A nomenclatura dos modelos internos do bloco comutador é feita a partir da seguinte regra: Nome do Modelo = Nome da Camada + Lado + Descrição + X, onde o Lado pode ser IN se o modelo estiver do lado da entrada ou OUT se o modelo estiver do lado da saída, a Descrição é uma pequena palavra que representa o tipo de modelo. Por exemplo: CAC representa modelos de algoritmo de controle de admissão de conexões e X pode ser igual ao número da porta ao qual o modelo está associado ou então igual a S, indicando que o modelo é compartilhado por várias portas de um mesmo lado. 126
  • Esta regra também é utilizada para dar nomes aos modelos internos do BTE. Entretanto neste caso, somente o lado de saída é implementado. 4.12 - Referências Bibliográficas [1] KUMARAN, K., MITRA, D., “Performance and Simulation of a Novel Shared Buffer Management System”, IEEE INFOCOM 98, março 1998. [2] YAN, A., GONG, W., “Fluid Simulation for High Speed Networks”, Proceedings of the 15th International Teletraffic Congress, Washington, D.C., junho 1997. [3] KESIDIS, G., SINGH, A., CHEUNG, D., KWOK, W., “Feasibility of Fluid-event-driven Simulation of ATM Networks”, Procedings IEEE Globecom, 1996. [4] KESIDIS, G., SINGH, A., “An Overview of Cell-level ATM Network Simulation”, Proc. High Performance Computer Systems, Montreal, PQ, pp. 202-212, julho 1995. [5] HEEGAARD, P. E., “Speedup Simulation Techniques”, Workshop Tutorial on Rare Event Simulation, agosto 1997. [6] YAN, A., “On Some Modeling Issues in High Speed Networks”, PhD Thesis, Department of Electrical and Computer Engineering, University of Massachusetts Amherst, fevereiro 1998. [7] BLACK, U., “ATM: Foundation for Broadband Networks”, Prentice-Hall, 1995. [8] SACKETT, G. C., METZ, C., “ATM and Multiprotocol Networking”, McGraw Hill, January 1997. [9] GIROUX, N., GANTI, S., “Quality of Service in ATM Networks: State-of-Art Traffic Management”, Prentice Hall, 1998. [10] ATM FORUM, “TM 4.0 – Traffic Management Specification”, 1996. [11] “Borland C++ User´s Guide”, Version 5.0, 1996. [12] PRESS, W. H., TEUKOLSKY, S. A., VETTERLING, W. T., FLANNERY, B. P., “Numerical Recipes in C: The Art of Scientific Computing”, Cambridge University Press, Second Edition, 1993. 127
  • [13] BUDD, T., “Classic Data Structures in C++”, Addison Wesley, 1994. [14] PAREKH, A. K., “A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Single-Node Case”, IEEE/ACM Transactions on Networking, Vol. 1. No 3. Junho de 1993. [15] BENNETT, J., ZHANG, H., “WF2Q: Worst-case Fair Weighted Fair Queueing”, IEEE Infocom 1996. [16] SURI, S., VARGHESE, G., CHANDRANMENON, G., “Leap Forward Virtual Clock: A New Fair Queueing Scheme with Guaranteed Delays and Througthput Fairness”, IEEE Infocom 1997. [17] ELWALID, A., MITRA, D., WENTWORTH, R., “A New Approach for Allocating Buffers and Bandwidth to Heterogeneous, Regulated Traffic in an ATM Node”, IEEE Journal on Selected Areas in Communications, 13(6):1115;1127, agosto de 1995. [18] KRISHNAN, S., CHOUDHURY, A. K., CHIUSSI, F., “Dynamic Partitioning: A Mecanism for Shared Memory Management”, IEEE INFOCOM’99, 1999. 128
  • Capítulo 5 Especificação de Simulações 5.1 - Introdução Uma vez desenvolvido o conjunto de modelos no nível de células (CMNC), nos preocupamos em identificar cenários interessantes para serem simulados. Nos preocupamos também em obter seqüências de tráfego reais para simular estes cenários, uma vez que a síntese através de modelos matemáticos demandaria por um tempo de desenvolvimento que consideramos demasiado. Assim sendo, neste capítulo discutiremos a especificação de simulações para o CMNC. Primeiramente, apresentaremos alguns cenários que foram investigados para serem simulados no Hydragyrum acrescido do CMNC. Em seguida, abordaremos o problema da obtenção de seqüências de tráfego para simular estes cenários e o problema da adaptação das seqüências de tráfego em formatos adequados para os modelos de aplicativos do CMNC. Finalmente, discutiremos o problema da configuração de contratos de tráfego ATM, uma vez que para realizar simulações mais fidedignas é necessário mapear adequadamente as características destas seqüências de tráfego para o modelo de contrato de tráfego do CMNC. 5.2 - Identificação de Cenários Nesta seção apresentaremos três cenários que foram investigados para serem simulados no Hydragyrum acrescido do CMNC: MPEG sobre ATM, Internet sobre ATM e Multimídia sobre ATM. Destes cenários, somente o primeiro deles foi simulado. Os demais foram apenas analisados. 5.2.1 - MPEG sobre ATM O MPEG-4 (Moving Pictures Expert Group) [1] está sendo considerado o padrão mais indicado para as aplicações de vídeo iterativo que utilizarão as futuras redes de telecomunicações faixa larga. Primeiro porque o MPEG-4 provê uma codificação de vídeo muito eficiente, e segundo porque ele cobre desde as taxas mais baixas dos sistemas de comunicação sem fio até as taxas mais altas dos 129
  • sistemas de televisão de alta definição (HDTV – High Definition Television). Além destas razões, outra razão importante é que o MPEG-4 está sendo desenvolvido voltado para sistemas multimídia iterativos, permitindo, portanto, grande flexibilidade na implementação de aplicações. Segundo Orzessek [2], o MPEG e o ATM são duas tecnologias chaves que possibilitarão o crescimento dos serviços de vídeo digital de um estágio acadêmico para a realidade comercial. Apostando nesta perspectiva, mostramos na Figura 5.1 um cenário NVoD (Near Video on Demand) [8] MPEG sobre ATM factível de ser simulado no Hydragyrum usando o CMNC. Neste cenário, o cliente envia uma requisição para o servidor de vídeo e espera até que o servidor inicie a transmissão mais tarde. Durante o playback, o usuário é meramente um observador passivo, não podendo alterar de forma alguma a transmissão já iniciada. Neste cenário, o tráfego MPEG seria apresentado ao modelo aplicativo externo no formato de uma seqüência de pacotes de transporte de programa simples MPEG (MPEG SPTS – Single Program Transport Stream). Filme 1 Filme 2 Adaptação de Rede Servidor NVoD Switch ATM Switch ATM Cliente Filme N MPEG MPEG MPEG SPTS MPEG SPTS AAL 5 AAL 5 ATM ATM ATM ATM PHY PHY PHY PHY Figura 5.1 – Cenário NVoD MPEG sobre ATM Nativo. Este cenário foi escolhido para ser simulado devido a disponibilidade de seqüências de tráfego reais para serem utilizadas nas simulações, a não necessidade de desenvolvimento de novos modelos de protocolos, tais como TCP, IP e RTP, e o ineditismo de trabalhos que relacionem as tecnologias MPEG-4 e ATM. 130
  • 5.2.2 - Internet sobre ATM Ninguém discute a importância da pilha de protocolos TCP/IP na atual conjuntura das telecomunicações globais. Assim sendo, é altamente desejável a interconexão das redes ATM com as redes TCP/IP. A Figura 5.2 mostra duas possibilidades para a simulação de um cenário contendo um servidor WWW no CMNC: a) HTTP direto sobre ATM e b) HTTP/TCP/IP sobre ATM. Conteúdo Web Servidor WWW Switch ATM Switch ATM Desktop PC Web browser HTTP HTTP AAL 5 AAL 5 ATM ATM ATM ATM PHY PHY PHY PHY a) HTTP Nativo HTTP HTTP TCP TCP IP IP LLC/SNAP LLC/SNAP AAL 5 AAL 5 ATM ATM ATM ATM PHY PHY PHY PHY b) HTTP/TCP/IP sobre ATM Figura 5.2 – Cenários Internet sobre ATM. Na primeira possibilidade o tráfego HTTP é transmitido diretamente sobre ATM (tal como em um sistema HTTP nativo sobre ATM), impossibilitando a incorporação do controle de fluxo TCP. A vantagem desta solução é que ela não necessita do desenvolvimento de novos modelos de protocolos (TCP e IP). Contudo, é questionável a validade dos estudos realizados com este tipo de solução, uma vez que muitas das relações temporais existentes no protocolo TCP não seriam consideradas adequadamente. Assim, descartamos a possibilidade de simulação deste cenário. Na segunda possibilidade, todo o controle de fluxo TCP estaria presente. Entretanto, esta solução demanda pelo desenvolvimento de modelos para os protocolos TCP e IP. Dentre estas possibilidades, consideramos a 131
  • segunda mais adequada. Porém, devido a demanda de tempo necessária para o desenvolvimento dos modelos TCP e IP, também descartamos esta possibilidade. Em ambos os cenários da Figura 5.2 tráfego WWW seria apresentado ao modelo aplicativo externo no formato de uma seqüência de pacotes HTTP. 5.2.3 - Multimídia em Tempo Real sobre ATM Em julho de 1999 o ATM Fórum lançou a especificação Gateway for H.323 Media Transport over ATM [9]. Esta especificação basicamente define serviços de Multimídia em Tempo Real sobre ATM (Real-time Multimedia over ATM), incluindo telefonia, vídeo conferência e aprendizado a distância sobre ATM. Em outras palavras, esta especificação apresenta o acesso a uma rede ATM utilizando o padrão H.323. Na Figura 5.3 mostramos um cenário para a simulação de multimídia em tempo real sobre ATM no CMNC. Este cenário utiliza a solução apresentada na seção 1.5.3 da especificação do ATM Fórum. Ou seja, o fluxo de dados do terminal H.323 é passado para o protocolo de transmissão em tempo real (RTP – Real Time Protocol) da pilha de protocolos da Internet. Em um gateway H.323-H.323 é feita a supressão dos cabeçalhos dos protocolos UDP e IP. Além disto, o cabeçalho RTP é comprimido/descomprimido a fim de diminuir ainda mais o overhead. Neste cenário o tráfego de multimídia sobre ATM seria apresentado ao modelo aplicativo externo no formato de uma seqüência de pacotes RTP. H.323 Switch ATM Switch ATM H.323 Gateway H.323-H.323 Gateway H.323-H.323 Media Stream Media Stream RTP RTP C/D C/D AAL 5 AAL 5 ATM ATM ATM ATM PHY PHY PHY PHY Figura 5.3 –Cenário Multimídia em Tempo Real sobre ATM. 132
  • Assim como no cenário TCP/IP sobre ATM, esta solução demandaria pelo desenvolvimento de modelos para os protocolos RTP, UDP e IP, bem como de modelos para outras funções presentes em um gateway H.323. Portanto, resolvemos descartar a possibilidade de simulação deste cenário. 5.3 - Obtenção de Seqüências de Tráfego Para que pudéssemos simular os cenários discutidos na seção anterior da forma mais próxima possível do real, foi necessária a obtenção de seqüências de tráfego (instante de tempo e tamanho dos pacotes a serem transmitidos) que representassem fielmente o tráfego submetido à rede ATM. Estas seqüências poderiam ser reais ou sintetizadas a partir de métodos matemáticos. Procuramos na Internet seqüências de tráfego que pudessem ser utilizadas em nossas simulações. Encontramos as seguintes seqüências: Tráfego MPEG-1 – O servidor de HTTP da Universidade de Wuerzburg na Alemanha [3], disponibiliza seqüências de frames MPEG 1 para vários programas televisivos, incluindo filmes, telejornais, programas de variedades e outros. Tráfego MPEG-4 – O site MPEG-4 and H.263 Video Traces for Network Performance Evaluation [3] disponibiliza seqüências de tamanho de frame MPEG 4 e H.263 para 27 programas televisivos, cada um deles em 7 níveis diferentes de qualidade. 5.4 - Adaptação de Seqüências de Tráfego Para que pudéssemos utilizar as seqüências de tráfego MPEG-1 e MPEG-4 obtidas na Internet, foi necessário primeiro adaptar estas seqüências originais para o nível de pacotes de fluxo de transporte MPEG (MPEG Transport Stream) [1], pois elas se encontravam no nível de tamanho de frames MPEG (Fluxo de Vídeo Elementar). Esta adaptação é necessária, porque de acordo com a estrutura do padrão MPEG os pacotes entregues à rede de transporte devem ser formatados como um fluxo de transporte MPEG. A seguir veremos como isto foi feito. 133
  • 5.4.1 - Adaptação de Seqüências de Tamanho de Frame MPEG para Seqüências de Fluxo de Transporte MPEG Para realizarmos a adaptação das seqüências de tamanho de frame MPEG em seqüências de fluxo de transporte MPEG desenvolvemos um software independente do ambiente de simulação Hydragyrum. Chamamos este software de MPEG Transport Stream Generator. A Figura 5.4 mostra a solução comumente utilizada [1][10][11] para adaptar o fluxo de tamanho de frames MPEG e segmentar o fluxo de pacotes de transporte MPEG resultante em células ATM. A seqüência de tamanho de frames I, P e B MPEG entregue ao programa consiste de um fluxo de vídeo elementar MPEG. Este fluxo é obtido a partir da compressão das unidades de apresentação em unidades de acesso MPEG. De posse da seqüência de frames MPEG (unidades de acesso), o próximo passo é fazer o empacotamento destes frames, o que resulta em um fluxo chamado fluxo elementar de pacotes (PES – Packet Elementary Stream). Os pacotes PES possuem um cabeçalho de 6 bytes e um campo de carga útil fixo ou variável, que é utilizado para transportar um ou mais frames do fluxo de vídeo elementar. Em nosso software de adaptação de seqüências MPEG utilizamos pacotes PES de tamanho variável, portanto transportando apenas um frame MPEG por pacote PES. Escolhemos esta solução devido a sua simplicidade. Neste ponto, é acrescentado um enchimento (PAD) para tornar o pacote PES múltiplo de 184 bytes. Feito isso, os pacotes PES são segmentados em pacotes do fluxo de transporte (TS – Transport Stream) MPEG. A Figura 5.4a mostra dois pacotes TS resultantes desta segmentação. Um cabeçalho de 4 bytes é acrescentado em cada fragmento do pacote PES, resultando portanto em pacotes TS de 188 bytes. Uma vez criado o fluxo de transporte MPEG, resta agora discutir como estes pacotes serão adaptados na rede ATM. O ATM Fórum em sua especificação de vídeo sobre demanda versão 1.1 [10] especificou a adaptação de pacotes de transporte de programa simples MPEG (MPEG Single Program Transport Stream) em células ATM utilizando a camada de adaptação ATM tipo 5 (AAL 5). De acordo com esta especificação, cada dois pacotes TS devem ser mapeados em uma única unidade de dados de serviço AAL 5 (AAL 5 SDU – Service Data Unit). Embora esta especificação seja voltada para o transporte de vídeo MPEG utilizando a categoria de serviço CBR (Constant Bit Rate), este esquema de adaptação de tráfego MPEG também tem sido utilizado para o transporte de vídeo MPEG em outras categorias de serviço ATM, tal como rt-VBR e nrt-VBR. Então, a cada dois pacotes TS é gerado um AAL5 CPCS 134
  • (Common Part Convergence Sublayer) PDU (Protocol Data Unit) de 384 bytes. Finalmente, este PDU é então segmentado em 8 células ATM. Em nosso programa, decidimos utilizar este mesmo esquema de adaptação de fluxo de transporte MPEG sobre ATM. Entretanto, este esquema de adaptação exige que a AAL5 seja capaz de fazer a multiplexação de SDUs, a fim de possibilitar que dois pacotes TS sejam mapeados em um único AAL5-SDU. Como o modelo de AAL5 que utilizaremos para a validação dos descritores de tráfego estimados não suporta esta multiplexação, resolvemos fazer uma simplificação no formato do fluxo de transporte MPEG. Ao invés do programa criar uma seqüência de pacotes TS MPEG propriamente dita, ele cria um fluxo equivalente de pacotes TS MPEG de 40 bytes. Ou seja, a seqüência de pacotes TS MPEG gerada pelo programa produz a mesma seqüência de SAR-SDUs na AAL5 do que uma seqüência de pacotes TS MPEG submetida a uma AAL5 capaz de realizar a multiplexação de SDUs. Isto é ilustrado na Figura 5.4b. A fim de reduzir o surto de células na rede ATM, as células resultantes da segmentação de cada dupla de pacotes TS MPEG são uniformemente espaçadas dentro do período de um frame MPEG. Segundo Oliver Rose [11], esta técnica de transmissão (“average per-frame bit rate”) torna o tráfego MPEG menos susceptível a atrasos e a perdas. 135
  • Fluxo de Vídeo Não Comprimido Frame 1 Frame 2 Frame 3 (unidades de apresentação) Fluxo de Vídeo Frame Frame Frame Elementar I B B (unidades de acesso) 6 6 Frame PAD PAD Fluxo Elementar de I Pacotes (PES) Frame Frame 4 4 6 I TS 1 4 4 6 I TS 1 Fluxo de Transporte Fluxo de Transporte 188 40 (TS) (TS) 2 Pacotes TS 8 Pacotes TS Frame Frame 4 4 I TS 2 I TS 8 MPEG 188 40 384 48 Frame 8 8 TS 1 TS 2 AAL CPCS-PDU 8 8 4 6 I AAL CPCS-PDUs Frame 8 8 5 5 8 TS 1 I 8 Células ATM Frame 5 5 8 4 6 5 5 TS 2 I 53 8 Células ATM Frame 5 5 8 I ATM a) b) Figura 5.4 – Segmentação de frames MPEG em células ATM: a) solução comumente utilizada e b) solução adotada pelo programa de adaptação. Na Figura 5.5 apresentamos o algoritmo utilizado para realizar a adaptação das seqüências de frames MPEG em pacotes TS MPEG. O programa inicia com a configuração dos valores iniciais das variáveis t, que é o tempo principal do programa, e da variável T, que é o tempo de inicio de cada frame MPEG. A variável t é iniciada com valor zero, enquanto a variável T é configurada com o valor do período dos frames MPEG (FP – Frame Period). Por exemplo, se a taxa de frames MPEG for de 25 frames por segundo, então FP é igual a 0.04. Então, o programa entra num laço que dura enquanto o tempo principal t for menor ou igual ao t max , que é o comprimento máximo desejado para a seqüência de saída. Dentro deste laço, em cada iteração, é inicialmente carregado o tamanho em bits de um frame 136
  • MPEG (f). Este valor é então convertido para bytes. Neste ponto, inicia-se a criação de um pacote PES a partir do frame f em bytes. Primeiro são inseridos os 6 bytes equivalentes ao cabeçalho do pacote PES. Depois é calculado o enchimento (PES_PAD) necessário para que o pacote PES resultante seja múltiplo de 184 bytes. Feito isso, o pacote PES resultante é segmentado em pacotes TS. O número de pacotes TS resultante desta segmentação é dado pela variável N TS . Na seqüência, é calculado um ∆ t entre cada pacote TS, de forma que eles sejam “espalhados” uniformemente dentro do período de um frame (FP). Isto é feito não só para os pacotes TS, mas também para as células ATM resultantes da segmentação de cada dupla de pacotes TS. A razão para “espalhar” estes pacotes e células uniformemente dentro do período de um frame, é que segundo Oliver Rose [11] esta técnica (“average per-frame bit rate”) é a mais eficiente em produzir tráfego menos susceptível a atrasos e a perdas. Uma vez calculado este ∆ t , é verificado se ele é menor que um ∆ prev prévio. Se ele for menor, o seu valor é t salvo em uma variável ∆min e a variável ∆ prev é configurada com o seu valor. Estas variáveis são t t guardadas para que no final da execução do programa seja possível fazer uma estimativa do valor de taxa de pico que será produzida pela seqüência de saída quando entrar na rede ATM. Neste ponto, a variável t é configurada com o valor da variável T, o que significa que o primeiro pacote da seqüência de saída será gerado no instante igual a um período de frame MPEG. Em seguida é verificado se o número de pacotes TS é par ou é impar. Se o número de pacotes TS for par, o programa segue para (P), senão para (I). 137
  • Cria Transport P I Stream MPEG N TS N TS t =0 T = FP Enquanto k < Enquanto k < +1 2 2 Enquanto t < tmax Enquanto i < 8 Se N TS Sim Enquanto i < 5 k= 2 Carrega f Salva CPCS-PDU de 40 bytes no instante Não Salva CPCS-PDU de 40 i.∆ t bytes no instante t+ Enquanto i < 8 f = f 8 4 i.∆ t t+ 5 i = i +1 Salva CPCS-PDU de 40 PES = f + 6 bytes no instante i = i +1 i.∆ t t+ 4 Fim do laço Fim do laço PES_PAD = 184 - PES mod 184 i = i +1 t = t + 2.∆ t PES + PES _ PAD N TS = Fim do laço 184 k = k +1 FP t = t + 2.∆ t ∆t = N TS Fim do laço Fim do laço ∆ t < ∆ prev t Sim ∆min = ∆ t t ∆prev = ∆ t t Não t - Tempo principal T - Tempo de inicio de cada frame t =T FP - Período dos frames tmax - Tempo final da seqüência f - Tamanho de um frame MPEG PES - Tamanho de um pacote PES N TS PES _ PAD - Tamanho do PAD do pacote PES Sim P é par ? N TS - Número de pacotes de TS ∆ t - Intervalo de tempo entre pacotes TS Não ∆prev - Intervalo de tempo entre pacotes TS do frame t anterior I ∆min - Intervalo de tempo mínimo entre pacotes TS t T = T + FP Fim do laço End Figura 5.5 – Algoritmo para a adaptação das seqüências de frames MPEG em pacotes TS MPEG. No primeiro caso, é executado um laço de k = 0 até: N TS k< . 2 138
  • Ou seja, o laço é executado tantas vezes quanto o número de pares de pacotes TS. Dentro deste laço, outro laço é executado. Este laço vai de i = 0 até i < 8 . Ou seja, este laço é executado tantas vezes quanto o número de células equivalente a segmentação de dois pacotes TS. Neste laço, são gerados PDUs de 40 bytes para a subcamada CPCS. Cabe aqui uma importante observação: a seqüência de saída do programa não é uma seqüência de pacotes TS propriamente dita. Como o modelo da AAL que desenvolvemos não permite a multiplexação de CPCS-SDUs (no caso a multiplexação de dois pacotes TS) e a segmentação destes CPCS-SDUs em células ATM com atraso variável entre células, nós optamos por gerar uma seqüência de AAL-SDUs que criasse um fluxo de SAR (Segmentation and Reassembly) SDUs equivalente. Ou seja, a seqüência de pacotes gerada pelo programa produz o mesmo “efeito” em termos de células ATM do que uma seqüência de pacotes TS submetida a uma camada de adaptação capaz de realizar a multiplexação de SDUs e a segmentação destes SDUs em células ATM igualmente espaçadas. Quando o laço mais interno termina, o tempo t é avançado de 2.∆ t . No caso de um número de pacotes TS impar, é executado um laço de k = 0 até: N TS k< +1. 2 Quando k = N TS 2 , a invés do laço mais interno ser executado de i = 0 até i < 8 , ele é executado de i = 0 até i < 5 , portanto segmentando o último pacote TS de 188 bytes em 5 células ATM. A Figura 5.6 e a Figura 5.7 mostram um exemplo de adaptação de seqüências MPEG utilizando o programa desenvolvido. A Figura 5.6 mostra a seqüência de tamanho de frames MPEG de entrada. A seqüência de AAL-SDUs de saída do programa é mostrada na Figura 5.7. Como era de se esperar, quanto maior o tamanho de um frame MPEG, maior é a densidade de AAL-SDUs geradas no período entre este frame e o próximo frame (0.04 segundos). 139
  • 14,000 Frame Size (bits) 12,000 10,000 8,000 6,000 4,000 2,000 0 0 500 1000 1500 2000 2500 3000 3500 Frame Size (bits) 10.0k 5.0k 0.0 24.5 24.6 24.7 24.8 24.9 25.0 25.1 25.2 25.3 25.4 25.5 Tempo (segundos) Figura 5.6 – Seqüência de tamanho de frame MPEG. AAL-SDUs (bytes) 40 20 0 24.5 24.6 24.7 24.8 24.9 25.0 25.1 25.2 25.3 25.4 25.5 40 AAL-SDUs (bytes) 20 0 24.70 24.75 24.80 24.85 24.90 Tempo (segundos) Figura 5.7 – Seqüência de fluxo de transporte MPEG de saída. 5.5 - Configuração de Contratos de Tráfego Basicamente, o problema de especificar contratos de tráfego ATM envolve a representação adequada das características e dos anseios do tráfego enviado para a rede pelos seus usuários. A especificação adequada destes contratos de tráfego é de fundamental importância para a realização de simulações mais realistas e precisas. Os contratos de tráfego ATM incluem os seguintes componentes: 140
  • A categoria de serviço a ser utilizada pela conexão (CBR, rt-VBT, nrt-VVR, ABR, UBR e GFR)1. A qualidade de serviço (QoS – Quality of Service) requisitada pela conexão (CLR, Max- CTD, P2P-CDV)2. Os descritores de tráfego da conexão (PCR, CDVT, SCR, MBS, MCR,MFS)3. A definição de conformidade a ser utilizada (CBR.1, VBR.1, VBR.2, etc). A definição de conformidade determina o tipo de células para o qual o QoS e os descritores de tráfego são definidos e quais as ações que a rede está habilitada a fazer sobre estas células. Portanto, a especificação de contratos de tráfegos ATM inclui a especificação adequada de cada um destes componentes. Uma vez que os modelos de aplicativos desenvolvidos incluem a negociação de contratos de tráfego ATM, nós utilizamos a seguinte metodologia para configurar os atributos do contrato de trafego destes modelos: 1. Escolha da categoria de serviço a ser utilizada pela conexão. 2. Definição dos parâmetros de qualidade de serviço e dos descritores de tráfego que se encaixam na categoria escolhida. A Tabela 5.1 mostra a relação destes atributos com a categoria de serviço escolhida. 3. Finalmente, é escolhida a definição de conformidade para a categoria de serviço definida anteriormente. A Tabela 5.2 sumariza as definições de conformidade suportadas por cada categoria de serviços ATM. 1 CBR – Constant Bit Rate, rt-VBR – Real Time Variable Bit Rate, nrt-VBR – Non-real Time Variable Bit Rate, ABR – Available Bit Rate, UBR – Unspecified Bit Rate e GFR – Guaranteed Frame Rate. 2 CLR – Cell Loss Ratio, Max-CTD – Maximum Cell Transfer Delay e P2P-CDV – Peak-to-Peak Cell Delay Variation. 3 PCR – Peak Cell Rate, CDVT – Cell Delay Variation Tolerance, SCR – Sustainable Cell Rate, MBS – Maximum Burst Size, MCR – Minimum Cell Rate e MFS – Maximum Frame Size. 141
  • Categorias de Serviço Atributos CBR rt-VBR nrt-VBR ABR GFR UBR 4 PCR Especificado. Especificado. Especificado. Especificado. Especificado. Especificado. SCR, MBS Não se aplica.5 Especificado. Especificado. Não se aplica. Não se aplica. Não se aplica. MCR Não se aplica. Não se aplica. Não se aplica. Opcional. Não se aplica. Não se aplica. MCR, MBS e Não se aplica. Não se aplica. Não se aplica. Não se aplica. Especificado. Não se aplica. MFS CLR De acordo.6 De acordo. De acordo. Não considerado. Não Não considerado. considerado. Max-CTD De acordo. De acordo. Não considerado.7 Não considerado. Não Não considerado. considerado. P2P-CDV De acordo. De acordo. Não considerado. Não considerado. Não Não considerado. considerado. Tabela 5.1 – Parâmetros de QoS e descritores de tráfego para as categorias de serviço ATM. Fonte [7]. Ação sobre Definição de Categorias de Fluxo Fluxo Fluxo Max-CTD células não CLR Conformidade Serviço PCR SCR MCR P2P-CDV conformes Não se Não se CBR.1 CBR 0+18 Descarta 0+1 0+1 aplica aplica rt-VBR Não se VBR.1 0+1 0+1 Descarta 0+1 0+1 (rt) nrt-VBR aplica rt-VBR Não se VBR.2 0+1 0 Descarta 0 0 (rt) nrt-VBR aplica rt-VBR Não se VBR.3 0+1 0 Marca 0 0 (rt) nrt-VBR aplica Não se ABR.1 ABR 0 0 Descarta 0 Não se aplica aplica Não se GFR.1 GFR 0+1 0 Descarta 0 Não se aplica aplica Não se GFR.2 GFR 0+1 0 Marca 0 Não se aplica aplica Não se Não se Não se UBR.1 UBR 0+1 Descarta Não se aplica aplica aplica aplica Não se Não se Não se UBR.2 UBR 0+1 Marca Não se aplica aplica aplica aplica Tabela 5.2 – Definições de conformidade para as categorias de serviço ATM. Fonte [7]. 4 Significa que o atributo é informado para a rede no momento do estabelecimento da conexão. 5 Significa que o atributo não faz parte do contrato de tráfego de uma dada categoria. 6 Significa que o atributo é informado para a rede no momento do estabelecimento da conexão e que a rede garante estes atributos caso a conexão seja aceita. 7 Significa que o atributo não é considerado no momento da decisão de aceitação de uma nova conexão. 8 0+1 diz respeito ao fluxo de células agregado, ou seja com CLP=0 ou CLP=1. 142
  • 5.5.1 - Escolha da Categoria de Serviço Escolher a categoria de serviço que melhor se ajusta aos pré-requisitos de uma determinada conexão não é uma tarefa simples. Em geral, mais de uma categoria pode ser utilizada para transportar um tipo específico de tráfego. Por exemplo, para o transporte de TCP/IP sobre ATM poderiam ser utilizadas as categorias ABR, UBR, GFR e até mesmo rt-VBR. Portanto, não é possível especificar uma regra única a ser seguida. Entretanto, as recomendações do ITU-T [12] e as especificações do ATM Fórum [13] apresentam em linhas gerais quais são as categorias de serviço mais adequadas para atender um tipo específico de tráfego. Porém, situações mais específicas demandam por uma investigação mais aprofundada. Este é o caso da especificação de categorias de serviço para o tráfego de sistemas de vídeo sobre demanda (VoD – Video on Demand). Dependendo das características do sistema, as categorias CBR, rt-VBR, nrt-VBR e até ABR podem ser utilizadas. 5.5.2 - Definição dos Parâmetros de QoS Os parâmetros de QoS quantificam os pré-requisitos de qualidade de serviço fim-a-fim desejados por uma conexão no nível da camada ATM. Três destes parâmetros são negociados com a rede no momento do estabelecimento das conexões ATM: CLR, Max-CTD e P2P-CDV. A definição destes parâmetros para um determinado aplicativo que utiliza a rede de transporte ATM depende exclusivamente dos pré-requisitos deste aplicativo com relação a rede de transporte. Por exemplo, se um aplicativo tolera atrasos de até 10 ms e suporta perdas de até 1 % dos seus pacotes, ele poderia requisitar da rede ATM os seguintes parâmetros de QoS: CLR ≤ 10 −4 , Max − CTD ≤ 10 −3 segundos e P 2 P − CDV ≤ 10 −4 segundos. Desta forma, ele conseguiria atender os seus pré-requisitos de QoS com relação a rede de transporte. Portanto, o problema da definição dos parâmetros de QoS consiste em mapear os pré-requisitos do aplicativo para os parâmetros de QoS do contrato de tráfego ATM. 5.5.3 - Definição dos Descritores de Tráfego A definição dos descritores de tráfego é com certeza a tarefa mais difícil da configuração de um contrato de tráfego ATM. Dentre as principais razões para isto estão: A incerteza associada ao comportamento das fontes de tráfego. A construção de modelos matemáticos que capturem o comportamento destas fontes. 143
  • A existência de um número infinito de conjuntos de descritores de tráfego que podem ser utilizados para descrever um determinado fluxo. A natureza em tempo real de certos aplicativos, como por exemplo a vídeo conferência. Neste trabalho limitamos este problema estimando os descritores de tráfego para um tráfego VBR armazenado, ou seja, não em tempo real. Para tanto, implementamos a técnica do Buffer Virtual que encontramos na referência [5]. A seguir apresentaremos esta técnica. 5.5.3.1 - Estimação de Descritores para Tráfego VBR: Técnica do Buffer Virtual A técnica do Buffer Virtual (VB) [5][6] é uma técnica eficiente de estimativa de descritores de tráfego ATM, que pode ser utilizada para estimar todos os conjuntos quase mínimos de descritores de tráfego PCR9, CDVT, SCR e MBS para um determinado fluxo de tráfego VBR ATM. Segundo [5], a técnica do buffer virtual é mais eficiente que a avaliação direta utilizando o algoritmo genérico de taxa de células (GCRA – Generic Cell Rate Algorithm), podendo ser utilizada tanto em simulações computacionais quanto em redes reais (através de medições on-line). A técnica do buffer virtual permite substituir a simulação direta de um tráfego VBR aplicado a um policiador duplo GCRA, pela simulação mais eficiente e essencialmente equivalente deste tráfego aplicado a um VB. A técnica do VB é baseada na equivalência existente entre o buffer virtual e um policiador GCRA(I, L), onde I e L são, respectivamente, o incremento e o limite do GCRA. Esta equivalência é ilustrada na Figura 5.8, e apoia-se em três aspectos: A ultrapassagem de um determinado limite de ocupação no VB equivale à ultrapassagem de um determinado limite de conformidade no policiador. Em outras palavras, o evento que causa uma sobrecarga no VB equivale ao evento que declara uma célula não conforme no policiador. Outra equivalência entre os dois sistemas é a equivalência entre a taxa de serviço do VB (SR – Service Rate) e o inverso do incremento I utilizado no policiador GCRA (I, L). Ou seja: 1 (1) SR = I Finalmente, existe a equivalência entre a ocupação máxima do VB (MBF – Maximum Buffer Fill) e o limitante L utilizado no policiador GCRA (I, L). Ou seja: 9 PCR – Peak Cell Rate; CDVT – Cell Delay Variation Tolerance; SCR – Sustainable Cell Rate; MBS – Maximum Buffer Size 144
  • MBF = L (2) Buffer Virtual Limite de ocupação ultrapassado. FIFO Célula Célula Célula Célula Célula Célula Célula Célula Célula Taxa de serviço Fluxo de células a) Célula Célula Célula Célula Célula Célula Célula Célula Célula Policiador Célula Célula Célula Célula Células GCRA conformes Células não conformes b) Limite de conformidade Célula Célula ultrapassado. Figura 5.8 – Equivalência entre: a) Buffer Virtual e b) Policiador. A equivalência entre o VB e o policiador é provada em [5] através da seguinte proposição: Proposição 1: Um fluxo de tráfego que resulta em uma ocupação máxima do VB (MBF) de m células quando processado a uma taxa de 1 I estará conforme com um algoritmo CGRA(I, L) se L = m.I e não estará conforme se L < (m − 1).I . Em [5] esta proposição é utilizada para determinar todos os conjuntos quase mínimos possíveis de descritores de tráfego ATM para um determinado fluxo VBR. Isto é feito a partir da aplicação da proposição 1 em um policiador duplo composto de um GCRA( T0 , T0 ), seguido de um GCRA( TS , BT + T0 ), onde: T0 = 1 = CDVT (3) PCR TS = 1 (4) SCR É importante observar, que devido a restrição T0 = CDVT = 1 PCR , existirá um único valor mínimo de PCR para um determinado fluxo de tráfego VBR. Portanto, aplicando-se a proposição 1 para cada um dos policiadores teremos: 145
  • GCRA( T , T ) – Neste caso I = L = 0 0 T0 . Então as únicas soluções possíveis para a equação L = m.I serão m = 0 e m = 1. Como estamos interessados em encontrar o valor mínimo da taxa de serviço do VB, pois este valor equivale ao PCR do fluxo de tráfego, o valor de m que requer uma menor taxa no VB será de m = 1. Portanto, o PCR do fluxo de tráfego será igual a taxa mínima de serviço do VB que produz um MBF de 1 célula. GCRA( TS , BT + T0 ) – Neste caso, I = TS e L = BT + T0 , com TS = 1 SCR . Substituindo I e L na equação L = m.I teremos: BT = MBF − T0 (5) SCR Esta expressão oferece um valor de BT que resulta na conformidade do fluxo de tráfego VBR quando submetido a um algoritmo GCRA( TS , BT + T0 ). Uma vez que cada taxa de serviço do VB equivale a um SCR válido (desde que a SR esteja entre a taxa média do fluxo VBR e o seu PCR), a expressão (5) oferece um BT mínimo para cada SCR. O valor de T0 pode ser previamente obtido através da aplicação da proposição 1 no policiador GCRA ( T , 0 T0 ). Uma vez determinado o valor do BT, o valor correspondente do MBS pode ser obtido a partir da equação:  BT  (6) MBS =   +1 TS − T0  Portanto, a partir da equivalência do VB com os policiadores GCRA( T0 , T0 ) e GCRA( TS , BT + T0 ) é possível estimar os descritores de tráfego ATM para um dado fluxo de tráfego VBR. Isto é feito através da simulação do tráfego VBR aplicado a uma fila FIFO que é servida a uma taxa constante de SR células por segundo. Assim sendo, a técnica do VB consiste em variar a taxa de serviço SR do VB e medir a ocupação máxima da fila FIFO (MBF) de forma a estimar os descritores de tráfego ATM. Como todas as taxas de serviço do VB correspondem a um SCR válido, em [5] são apresentados dois métodos para que se possa escolher um único par (SCR, BT) para um dado fluxo de tráfego VBR. O primeiro deles é somente discutido no artigo e baseia-se em critérios de banda efetiva. O segundo baseia-se em limitar o MBS a um valor razoável e a partir dai selecionar um valor de SCR correspondente. 5.5.3.1.1 - Implementação do VB 146
  • Nesta seção descreveremos o software: Virtual Buffer VBR Traffic Descriptors Estimator, desenvolvido para a estimativa de descritores de tráfego VBR utilizando a técnica do VB. O software desenvolvido carrega, através da leitura de um arquivo externo, o fluxo de tráfego VBR cujos descritores serão estimados. É importante observar que este fluxo de tráfego deve estar no formato de pacotes (AAL-SDUs – ATM Adaptation Layer – Service Data Units) de 40 bytes. As razões para isto serão melhor discutidas na seção 5.4.1 - . Para simular o sistema da Figura 5.8a, o programa desenvolvido utiliza a técnica de simulação por eventos discretos. Para tanto, ele possui uma fila com prioridades que ordena os eventos do sistema a ser simulado de acordo com um tempo predeterminado de execução. Assim sendo, a dinâmica da simulação é dada pela execução do evento com maior prioridade e pelo avanço do tempo de simulação de acordo com o tempo deste evento. O programa implementado executa dois algoritmos em seqüência. O primeiro deles estima um único par de descritores (PCR, CDVT), enquanto o segundo estima um conjunto de pares de descritores (SCR, MBS). A seguir descreveremos estes algoritmos. 5.5.3.1.2 - Estimativa de um Par (PCR, CDVT) Este algoritmo de estimativa realiza uma simulação iterativa do sistema da Figura 5.8a para obter a melhor estimativa possível de um único par (PCR, CDVT). A cada iteração é monitorada a ocupação da fila do VB quando submetida a um taxa de serviço de SR células por segundo. A convergência é obtida quando é encontrada a menor taxa SR que produz um MBF de 1 célula. Esta situação ocorre no limite entre uma taxa SR que produz MBF = 1 e uma taxa que produz MBF = 2. A Figura 5.10 e a Figura 5.10 mostra o fluxograma deste algoritmo. Primeiramente, é feita a configuração dos valores iniciais das variáveis: SR – Taxa de serviço do VB. É iniciada com o valor da taxa de pico da seqüência de tráfego VBR de entrada. Este valor é fornecido pelo usuário do programa. SRMBF =1 – Taxa de serviço SR que produz MBF = 1. SRMBF = 2 – Taxa de serviço SR que produz MBF = 2. ∆ SR – Módulo da diferença entre o SRMBF =1 eo SRMBF = 2 . Count – Contador do número de iterações realizadas. 147
  • Uma vez configuradas as variáveis iniciais, o programa entra num laço que dura o tempo necessário para que o MBF convirja para 1. Quando esta situação for alcançada, um FLAG é configurado para 1 e a estimativa do par (PCR, CDVT) acaba. Dentro deste laço, a cada iteração uma simulação baseada em eventos é executada. Esta simulação prossegue até que não hajam mais eventos ou até que um tempo máximo de simulação ( tmax ) seja alcançado. Os eventos executados são: LÊ_TRÁFEGO – Este evento lê de um arquivo externo os AAL-SDUs de 40 bytes a serem transmitidos na rede ATM. Para cada AAL-SDU, um atraso de empacotamento de células é acrescentado e um evento ARMAZENA_CÉLULA é agendado na fila de eventos. ARMAZENA CÉLULA – Este evento armazena uma célula na fila FIFO, aumenta o contador de células armazenadas e verifica se um novo máximo de ocupação do VB ocorreu. Se o servidor do VB estiver desligado, um evento REMOVE_CÉLULA é agendado para iniciar as servir as células ATM. REMOVE CÉLULA – Este evento remove uma célula da fila FIFO e decresce o contador de células armazenadas no VB. Se ainda existirem células na fila, um novo evento REMOVE_CÉLULA é agendado para servir outra célula ATM no inicio do próximo slot de transmissão. Quando o laço de execução de eventos acaba, é feito um reajuste no valor da taxa SR que depende do MBF obtido: MBF ≥ 3 – Neste caso, a taxa de serviço do VB (SR) não é suficiente para servir o fluxo de tráfego VBR com MBF = 1. Se um SR anteriormente simulado já produziu um MBF = 1 e nunca produziu um MBF = 2, a taxa SR é decrescida da metade da diferença entre o SRMBF =1 e o SR atual. Entretanto, se um SR anteriormente simulado já produziu um MBF = 2 e nunca um MBF = 1, a taxa SR é incrementada da metade da diferença entre o SRMBF = 2 e o SR atual. Finalmente, se nenhuma destas situações ocorreu anteriormente, um ajuste empírico é feito: SR SR = SR + .log(MBF ) (7) 10 MBF = 2 – Neste caso, a taxa SR ainda não é suficiente para atender o tráfego VBR com no máximo uma célula no VB. Da mesma forma, se um SR anteriormente simulado já produziu 148
  • um MBF = 1, a taxa SR é incrementada da metade da diferença entre o SRMBF =1 eo SRMBF =2 . Caso contrário, a taxa SR é incrementada de um valor empírico de 200 células/segundo. MBF = 1 – Neste caso, a taxa SR já é suficiente para atender o tráfego com no máximo uma célula no VB. Entretanto, é necessário verificar o quão distante o SR está da taxa SRMBF = 2 , uma vez que buscamos a taxa SRMBF =1 mínima. Portanto, se um SR anterior já produziu um MBF = 2, a taxa SR é decrescida da metade da diferença entre o SRMBF =1 eo SRMBF = 2 . Caso contrário, a taxa SR é decrescida de um valor empírico de 200 células/segundo. A convergência é alcançada quando a diferença entre o SRMBF =1 e o SRMBF = 2 ( ∆ ) for menor que 10−6 e SR o MBF for igual a 1. Então, o par (PCR, CDVT) é obtido a partir das expressões: PCR = SR e CDVT = 1 SR . 5.5.3.1.3 - Estimativa de um Conjunto de Pares (SCR, MBS) Como vimos, a equivalência entre o VB e o policiador GCRA ( TS , BT + T0 ) resulta em conjunto infinito de pares (SCR, MBS) conformes com este policiador. Para que se possa obter um único par (SCR, MBS) é necessário definir (fixar) um destes descritores de tráfego de acordo com um método específico. Ao invés de implementar vários métodos para determinar um único par (SCR, MBS), nós optamos por estimar um conjunto de pares (SCR, MBS) de forma a possibilitar que uma escolha externa ao programa pudesse ser realizada. Para tanto, o usuário deve fornecer o número de estimativas ( N E ) desejadas, ou de pares (SCR, MBS). O programa então varia o valor da taxa SR de SR = 1 N E até SR = PCR , simulando novamente o sistema VB para cada uma destas taxas de serviço. Portanto, para cada valor de SR é executada uma nova simulação do sistema da Figura 5.8a, de forma que o par de descritores (SCR, MBS), e a tolerância a surtos BT, sejam obtidos a partir das expressões:  k + 1 SCR[k ] =   N .PCR  , com k = 0 até k < N E . (8)  E  MBF BT [k ] = − CDVT (9) SCR[k ]    BT [k ]  (10) MBS [k ] =   +1  1 − CDVT   SCR [k ]    149
  • 3 Estima Par (PCR, CDVT) t - Tempo principal NoC = NoC − 1 SR - Taxa de serviço do buffer virtual SRMBF =1- Taxa de serviço do buffer virtual quando MBF = 1 SRMBF =1 = 0 Count = 0 SRMBF = 2- Taxa de serviço do buffer virtual SRMBF =2 = 0 SR = PR PR - Taxa de pico da seqüência de entrada ∆ SR = 0 Count - Contador do número de iterações NoC = 0 ? Sim Desliga servidor FLAG - Flag de saída da fase de estimação Enquanto FLAG = 0 7 NoC - Número de células no buffer virtual Não MBF - Máximo Número de células no buffer virtual NST - Tempo de inicio do próximo serviço t =0 NoC = 0 1 tcell - Tempo da célula, lido a partir da seq. de entrada NST = NST + SR CPD - Tempo de processamento de uma célula na AAL NST = 0 MBF = 0 Cria evento Cria evento LÊ_TRÁFEGO REMOVE_CELULA para o para o instante 0. instante NST Volta Enquanto houver eventos e t ≤ t max Evento é igual a Evento é igual a Evento é igual a Não ARMAZENA_CELULA Não LÊ_TRÁFEGO? REMOVE_CELULA? ? Sim Sim Sim 1 2 3 Fim do laço 4 5 SRMBF =1 > 0 ? SRMBF = 2 > 0 ? SRMBF =1 = 0 ? Não Não e e e SRMBF =2 = 0 ? SRMBF =1 = 0 ? SRMBF =2 = 0 ? Sim Sim Sim ∆ SR = SRMBF =1 − SR ∆ SR = SRMBF =2 − SR SR Não SR = SR + . log(MBF ) SR = SR + ∆ SR 2 SR = SR − ∆ SR 2 10 6 Figura 5.9 – Estimativa de um par (PCR, CDVT) – Parte I. 150
  • 4 MBF ≥ 3 ? Sim 5 SR = SR + 200 6 Não Não ∆ SR = SRMBF =1 − SRMBF =2 MBF = 2 ? Sim SRMBF =2 = SR SRMBF =1 > 0 ? Sim SR = SR + ∆ SR 2 Não ∆ SR = SRMBF =1 − SRMBF =2 MBF = 1 ? Sim SR MBF =1 = SR SR MBF = 2 > 0 ? Sim SR = SR − ∆ SR 2 Não Não MBF = 1 6 e Sim FLAG = 1 SR = SR − 200 6 ∆ SR < 10 −6 ? Não Count = Count + 1 1 2 Enquanto k < 10 7 Fim do laço NoC = NoC + 1 1 PCR = SR CDVT = Carrega tcell SR NoC > MBF ? Sim MBF = NoC Fim Insere atraso de processamento Não tcell = tcell + CPD Servidor está Cria evento desligado ? ARMAZENA_CELULA para o instante tcell Sim Fim do laço Calcula NST Não Cria evento Cria evento LÊ_TRÁFEGO REMOVE_CELULA para o para o instante tcell instante NST Volta Volta Figura 5.10 – Estimativa de um par (PCR, CDVT) – Parte II. 5.5.3.1.4 - Resultados A seguir apresentaremos um exemplo de estimação dos descritores de tráfego PCR,CDVT, SCR e MBS para a seqüência de tamanhos de frames MPEG mostrada na Figura 5.11. Primeiramente é utilizado o programa da seção 5.4.1 - para realizar a adaptação desta seqüência de tamanhos de frames 151
  • MPEG para uma seqüência de tamanho de AAL-SDUs. O resultado desta adaptação para o intervalo de tempo de 4,42997 segundos até 5,10851 segundos pode ser vista na Figura 5.12. 10000 9000 Tamanho dos frames MPEG (bytes) 8000 7000 6000 5000 4000 3000 2000 1000 0 0 1 2 3 4 5 6 7 8 9 10 Tempo (segundos) Figura 5.11 – Seqüência de frames MPEG de entrada. 40 Tamanho dos AAL-SDUs (bytes) 20 0 4,45 4,50 4,55 4,60 4,65 4,70 4,75 4,80 4,85 4,90 4,95 5,00 5,05 5,10 Tempo (segundos) Figura 5.12 – Seqüência de AAL-SDUs resultante da adaptação dos frames MPEG. 152
  • A Figura 5.13 mostra a ocupação do buffer virtual durante as varias iterações do algoritmo de estimação do PCR e do CDVT. Pode-se observar que em 5 iterações, o número de células no VB caiu de aproximadamente 7000 células para 1 célula. A Figura 5.14 mostra a ocupação do VB durante as últimas 3 iterações do algoritmo de estimação do PCR e do CDVT. A Figura 5.15 mostra a convergência do algoritmo de estimação do PCR e do CDVT. Novamente, pode-se observar que o algoritmo convergiu em apenas 5 iterações. A execução do algoritmo de estimação do PCR e do CDVT convergiu para um SR igual a 9129.664565448795. Portanto, o valor do PCR estimado é PCR = 9129.664565448795 e o valor do CVDT estimado é CDVT = 0.0001095330494161307. 7000 Ocupação do Buffer Virtual (células) 6000 5000 4000 3000 2000 Iteração 1 Iteração 2 Iteração 3 1000 Iteração 4 Iteração 5 0 0 2 4 6 8 10 Tempo (segundos) Figura 5.13 – Ocupação do buffer virtual durante as varias iterações do algoritmo de estimação do PCR e do CDVT. 153
  • 50 Iteração 1 Iteração 2 45 Iteração 3 Ocupação do Buffer Virtual (células) Iteração 4 Iteração 5 40 35 30 25 20 15 10 5 0 0 2 4 6 8 10 Tempo (segundos) Figura 5.14 – Ocupação do buffer virtual durante as últimas 3 iterações do algoritmo de estimação do PCR e do CDVT. 10000 8000 SR = 9129.664565448795 6000 4000 2000 Service_Rate Buffer_Occupancy Error 0 1 2 3 4 5 Iteração Figura 5.15 – Convergência do algoritmo de estimação do PCR e do CDVT. 154
  • A Tabela 5.3 mostra o conjunto de pares (SCR,MBS) ou (SCR,BT) obtido a partir da execução do algoritmo para a estimação do SCR, MBS e BT com o número de estimações igual a 30. A Figura 5.16 mostra o gráfico do SCR versus o MBS e o BT. Número de Estimativas SCR BT MBS % do PCR 1 304.322152 15.963237 5026 3.33333 2 608.644304 4.495127 2932 6.66667 3 912.966457 1.674651 1699 10 4 1217.288609 0.285772 402 13.33333 5 1521.610761 0.095184 174 16.66667 6 1825.932913 0.072730 167 20 7 2130.255065 0.056691 158 23.33333 8 2434.577217 0.044662 149 26.66667 9 2738.899370 0.034941 137 30 10 3043.221522 0.027493 126 33.33333 11 3347.543674 0.021399 114 36.66667 12 3651.865826 0.016320 100 40 13 3956.187978 0.012023 84 43.33333 14 4260.510131 0.008340 67 46.66667 15 4564.832283 0.004929 46 50 16 4869.154435 0.002150 23 53.33333 17 5173.476587 0.000277 4 56.66667 18 5477.798739 0.000256 4 60 19 5782.120891 0.000236 4 63.33333 20 6086.443044 0.000219 5 66.66667 21 6390.765196 0.000047 2 70 22 6695.087348 0.000040 2 73.33333 23 6999.409500 0.000033 2 76.66667 24 7303.731652 0.000027 2 80 25 7608.053805 0.000022 1 83.33333 26 7912.375957 0.000017 2 86.66667 27 8216.698109 0.000012 2 90 28 8521.020261 0.000008 2 93.33333 29 8825.342413 0.000004 2 96.66667 Tabela 5.3 – Conjuntos de pares (SCR, MBS) ou (SCR, BT). A partir da Tabela 5.3 e da Figura 5.16 é possível escolher um único par (SCR,MBS) ou (SCR,BT) a ser utilizado. Por exemplo, podemos escolher um SCR que seja igual a 50% do valor do PCR. Neste caso, teremos: SCR = 4564.832283, BT = 0.004929, e MBS = 46. Outra escolha possível é limitar o MBS a valores menores que 30. Neste caso, teremos: SCR = 4869.154435, BT = 0.002150, e MBS = 23. 155
  • 18 MBS 5000 16 14 4000 12 BT (segundos) MBS (células) 3000 10 8 2000 6 4 1000 2 0 0 -2 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 SCR (células/seg.) Figura 5.16 – SCR versus MBS e BT. 5.5.4 - Escolha da Definição de Conformidade A definição de conformidade determina o tipo de células ATM para o qual o QoS e os descritores de tráfego são definidos e quais as ações que a rede está habilitada a fazer sobre estas células. A rede ATM deve prover QoS pelo menos para as células conformes, portanto a escolha da definição de conformidade para um determinado aplicativo depende do nível de “risco” que este aplicativo está disposto a bancar. 5.6 - Referências Bibliográficas [1] KOENEN, R.,“MPEG-4: Multimedia for Our Time”, IEEE Spectrum, volume 36, número 2, Fevereiro 1999. [2] ORZESSEK, M., SOMMER, P., “ATM & MPEG-2: Integrating Digital Video in Broadband Networks”, Prentice Hall, 1998. [3] http://nero.informatik.uni-wuerzburg.de/MPEG/ 156
  • [4] FITZEK, F. H., REISSLEIN, M., “MPEG-4 and H.263 Video Traces for Network Performance Evaluation”, IEEE Network Magazine, November 2001. [5] PETR, D. W., VADDI, K. G., LU, Y., “UPC Parameter Estimation Using Virtual Buffer Measurement with Application to AAL 2 Traffic”, IEEE Globecom´99, 1999. [6] ZHU, H., FROST, V. S., “In-Service Monitoring and Estimation of Cell Loss Ratio QoS in ATM Networks”, IEEE/ACM Transactions on Networking, Vol. 4, No. 2, pp. 240-248, Abril 1996. [7] GIROUX, N., GANTI, S., “Quality of Service in ATM Networks: State-of-Art Traffic Management”, Prentice Hall, 1998. [8] ZHENG, B., ATIQUZZAMAN, M., “Multimedia over ATM: Progress, Status and Future”, IEEE International Conference on Computer Communications and Networks, 1998. [9] ATM Forum, “Gateway for H.323 Media Transport Over ATM”, Julho 1999. [10] ATM Forum, “Audivisual Multimedia Services: Video on Demand Specification 1.1”, Março, 1997. [11] ROSE, O., “Traffic Modeling of VBR MPEG Video and its Impacts on ATM Networks”, Tese de Doutorado, Universidade de Wuerzburg, 1997. [12] ITU-T, “I.731 – Types and General Characteristics of ATM Equipment”, 1996. [13] ATM Forum, “TM 4.0 – Traffic Management Specification”, 1996. 157
  • Página deixada em branco intencionalmente. 158
  • Capítulo 6 Simulações 6.1 - Introdução Neste capítulo apresentaremos três simulações realizadas utilizando-se o conjunto de modelos no nível de células e o ambiente de simulação Hydragyrum. A primeira simulação demonstra e valida o funcionamento do modelo de escalonador WF2Q. A segunda simulação faz uma análise da QoS em conexões ATM quando sujeitas a duas situações: congestionamento e congestionamento severo. O objetivo é visualizar como a aceitação de uma nova conexão interfere na QoS das demais. A terceira simulação simula o cenário de vídeo sobre demanda MPEG-4 sobre ATM apresentado no Capítulo 5. Esta simulação faz uma análise preliminar da deterioração da QoS em conexões ATM sujeitas a diversas configurações de rede, que variam desde os recursos disponíveis (capacidade das estruturas de filas) até número de conexões presentes na rede, além de os modelos utilizados nas simulações. 6.2 - Simulação 1: Validação do Escalonador WF2Q Esta simulação tem por objetivo validar o modelo de escalonador WF2Q_Scheduler, que modela um escalonador WF2Q – Worst-case Fair Weighted Fair Queueing, conforme apresentado na seção 4.7.2.4. Para tanto, simularemos o transporte de seqüências de tráfego MPEG-4 [1] sobre uma rede ATM cujos terminais e comutador utilizam escalonadores WF2Q_Scheduler. 6.2.1 - Configuração da Rede no Simulador A Figura 6.1 mostra a topologia da rede utilizada para validar o modelo WF2Q_Scheduler. Fazem parte desta rede dez aplicativos fonte, dois terminais faixa larga, um chaveador ATM, um gerente e um aplicativo de destino. Cada um dos aplicativos fonte (App_0 até App_9) estabelece uma conexão chaveada até o aplicativo de destino (App_10). Os cinco primeiros aplicativos (App_0 até App_4) transmitem respectivamente cinco seqüências de tráfego de pacotes MPEG-4, conforme será apresentado na seção 6.2.3 - . Os cinco aplicativos restantes (App_5 até App_9), também 159
  • transmitem estas mesmas seqüências. Todas as conexões utilizam a categoria de serviço nrt-VBR (Non Real-time Variable Bit Rate) e os descritores de tráfego ATM são configurados de acordo com a Tabela 6.6. O CLR utilizado em cada conexão é incrementado a partir de 1×10-9 (a conexão a partir do App_0 possui CLR = 1×10-9, enquanto conexão a partir do App_9 possui CLR = 10×10-9). Os enlaces entre o terminal BTE_0 e o chaveador SW_0 e entre o chaveador SW_0 e o terminal BTE_1 tem a capacidade de 2.048 Mbits/seg. A taxa de serviço da matriz de comutação em cada porta do chaveador SW_0 foi configurada para 149.76 Mbits/seg. A distância entre o BTE_0 e o SW_0 é de 10 metros, e entre o SW_0 e o BTE_1 é de 80 metros. A velocidade de propagação do sinal é de 200×106 metros/seg. Dinossauros Parque dos Taxa da matriz de comutação: 149.76 Mbits/seg. Silêncio dos Inocentes Gerente Taxa dos enlaces: 2048 Kbits/seg. Programa de Entrevistas Terminal Faixa Terminal Faixa Aplicativo Corrida de Fórmula 1 Chaveador Larga Larga Destino Desenho Animado Aplicativos Fonte Figura 6.1 – Topologia da rede utilizada para validar o modelo WF2Q_Scheduler. 6.2.2 - Definição das Simulações Para avaliarmos o desempenho do modelo do escalonador WF2Q quando sujeito a um tráfego MPEG-4, realizamos 8 simulações para cada tipo de amostragem estatística, variando desde a capacidade das estruturas de filas (1000, 500, 100 e 50 células) até o modelo de escalonador utilizado. Ou seja, simulamos a rede da Figura 6.1 utilizando primeiro o escalonador default (Default_Scheduler – veja a seção 4.7.2.1) e depois o escalonador WF2Q. A idéia era mostrar o desempenho do escalonador WF2Q tendo como referência o escalonador default. A variação da 160
  • capacidade das estruturas de filas revela a importância da ordem de serviço das células ATM na qualidade de serviço garantida para cada conexão. 6.2.3 - Configuração dos Modelos Cinco seqüências de frame size MPEG-4 disponibilizadas pelo Grupo de Redes de Telecomunicações da Universidade Técnica de Berlin [2] foram utilizadas para investigar o desempenho do escalonador WF2Q_Scheduler. São elas: Parque dos Dinossauros (Jurassic Park). Silêncio dos Inocentes (Silence of The Lambs). Programa de Entrevistas (Boulevard Bio). Corrida de Fórmula 1 (Formula 1). Desenho Animado (Simpsons). Entretanto, antes de simular o transporte destas seqüências, foi necessário adaptá-las do nível de tamanho de frames MPEG (Fluxo de Vídeo Elementar) [3] para o nível de pacotes de fluxo de transporte MPEG (MPEG TS – Transport Stream). Esta adaptação foi realizada utilizando- se o software de adaptação de seqüências de frame size MPEG para seqüências de transport stream MPEG apresentado na seção 5.4.1. Também utilizamos o software de estimação de descritores de tráfego MPEG sobre ATM (apresentado na seção 5.5.3.1) para estimar descritores de tráfego quase mínimo para as seqüências de tráfego acima. A Tabela 6.1 sumariza os descritores de tráfego estimados para as seqüências de tamanho de pacotes de transporte MPEG-4. Descritores de Tráfego Seqüência Descritor PCR (células/seg.) CDVT (seg.) SCR (células/seg.) MBS (células) Parque dos Dinossauros 1198.3763 0.000830 958.7010 51 Silêncio dos Inocentes 1600 0.000625 1280 107 Programa de Entrevistas 925 0.001081 740 41 Corrida de Fórmula 1 1000 0.001 800 66 Desenho Animado 3259.5052 0.000307 2607.6041 76 Tabela 6.1 – Descritores de tráfego ATM utilizados. 161
  • Tomando como referência a Figura 6.1, os seguintes modelos de gerenciadores de tráfego foram utilizados nos terminais BTE_0 e BTE_1, e no chaveador Switch_0: Estrutura de Filas – Foi utilizado somente o modelo estrutura de filas com filas por conexão (Per_VC_Queueing_Structure). Este modelo mantém filas lógicas para cada conexão existente na rede. Estas filas são servidas por um modelo de escalonador associado. Escalonador – Foram utilizados dois modelos de escalonadores: escalonador default (Default_Scheduler) e escalonador WF2Q (WF2Q_Scheduler). O modelo de escalonador default serve as células na mesma ordem em que são recebidas. Controle de Admissão de Conexões – Foi utilizado o modelo controle de admissão de conexões com alocação baseada em critérios de banda e buffer efetivos (Elwalid_Mitra_CAC). Este modelo aceita uma nova conexão se a banda e o buffer efetivos calculados para uma nova conexão forem menores que a largura de faixa disponível no escalonador e o espaço disponível na estrutura de filas, respectivamente. Neste caso, o modelo de controle de admissão com alocação baseada em critérios de banda e buffer efetivos ajusta o peso desta conexão de acordo com a expressão φ i = EB C , onde EB é a banda efetiva calculada para a conexão i e C é a capacidade do escalonador. Gerenciador de Estrutura de Filas – Foi utilizado o modelo gerenciador de estrutura de filas com particionamento dinâmico (Dynamic_Partitioning_BM). O gerenciador de estrutura de filas com particionamento dinâmico trabalha em parceria com o modelo de controle de admissão de conexões anterior. Ele mantém vários limiares dinâmicos (um para cada fila por conexão) que são utilizados para determinar se uma célula pode ser aceita ou não em uma estrutura de filas. Estes limiares são calculados a partir das alocações de banda e buffer efetivos feitos pelo controle de admissão de conexões. Descarte Seletivo de Células – Foi utilizado o modelo descarte seletivo de células baseado no CLR (CLR_SD). Em caso de congestionamento, este modelo descarta as células das conexões com menor pré-requisito de CLR em prol das células das conexões com um maior pré-requisito de CLR. 162
  • 6.2.4 - Resultados Inicialmente apresentamos a validação do WF2Q_Scheduler, seguido pelos demais resultados das simulações da rede da Figura 6.1. Estes resultados foram divididos de acordo com os dois tipos de amostragem estatísticas disponíveis: amostragem por eventos e amostragem por tempo. 6.2.5 - Validação do Modelo WF2Q_Scheduler A validação do modelo WF2Q_Scheduler será feita a partir da análise da ordem de serviço obtida na estrutura de filas PHY_OUT_QS_0 do BTE_0 no intervalo de tempo de 0.04 até 0.043 segundos. A fim de facilitar a compreensão dos acontecimentos, a Tabela 6.2 mostra os pesos φi alocados pelo modelo de controle de admissão de conexões para cada conexão i, bem como o CLR definido para cada conexão. Observe que as conexões estão ordenadas na ordem decrescente de seus pesos φi . Na Figura 6.2 é mostrada a ocupação obtida na estrutura de filas PHY_OUT_QS_0 durante o intervalo de tempo considerado. Na Tabela 6.3 é mostrada a evolução das variáveis do modelo neste mesmo intervalo de tempo. Seqüência i φi CLR Desenho Animado 4 0.5398547053 5x10-9 Desenho Animado 9 0.5398547053 10x10-9 Silêncio dos Inocentes 1 0.2650000200 2x10-9 Silêncio dos Inocentes 6 0.2650000200 7x10-9 Parque dos Dinossauros 0 0.1984810867 1x10-9 Parque dos Dinossauros 5 0.1984810867 6x10-9 Corrida de Fórmula 1 3 0.1656250204 4x10-9 Corrida de Fórmula 1 8 0.1656250204 9x10-9 Programa de Entrevistas 2 0.1532031455 3x10-9 Programa de Entrevistas 7 0.1532031455 8x10-9 Tabela 6.2 – Pesos e CLR para cada conexão. No instante 0.04 segundos, 10 células ATM são armazenadas para serviço no escalonador WF2Q (uma de cada conexão). A primeira célula servida pertence a conexão 4. Esta conexão, junto com a conexão 9, é a conexão com maior peso no escalonador. Como ambas as conexões possuem o mesmo peso φi , o desempate é feito baseado na ordem de chegada das células. Em seguida são servidas as células da conexão 9 e da conexão 1, respectivamente. No instante 0.0407702310 ocorre a chegada de mais 2 células, uma da conexão 1 e outra da conexão 6. Apesar da chegada destas duas células, a próxima célula servida será a célula da conexão 6 que chegou no instante 0.04. Isto 163
  • porque neste instante esta célula é que possui o menor Ftki . Na seqüência é servida a célula da conexão 0 que chegou no instante 0.04. Embora esta conexão tenha um peso menor do que a conexão 1, que teve uma nova célula recebida no instante 0.0407702310, ela possui um Ftki menor do que o desta conexão. No instante 0.041001, ocorre a chegada de mais 2 células, uma da conexão 4 e outra da conexão 9. Neste caso, entretanto, devido ao peso destas conexões, ambas as células recém chegadas são servidas antes do que as demais células que aguardam por serviço no escalonador. Os acontecimentos restantes da Figura 6.2 podem ser compreendidos a partir da observação do tempo de chegada t k e do Ftki de cada célula na Tabela 6.3. Concluímos portanto, que os resultados apresentados nesta subseção estão de acordo com a referência [4], validando assim o modelo desenvolvido. 13.0 25/9/2001 11:26:49 12.0 BTE_0 - PHY_OUT_QS_0 0.04 0.041001 0.040770231 Chegada: Chegada: Chegada: 11.0 1 célula por conexão 1 célula conexão 4 1 célula conexão 1 1 célula conexão 9 1 célula conexão 6 10.0 Ocupação da Estrutura de Filas (Células) 9.0 "Q0" B=1000 8.0 i φi CLR "Q1" B=1000 4 0.5398547053 5x10-9 "Q2" B=1000 7.0 "Q3" B=1000 9 0.5398547053 10x10-9 "Q4" B=1000 1 0.2650000200 2x10-9 "Q5" B=1000 6.0 6 0.2650000200 7x10-9 "Q6" B=1000 Serviço 0 0.1984810867 1x10-9 "Q7" B=1000 5.0 5 0.1984810867 6x10-9 "Q8" B=1000 Conexão 6 Serviço 3 0.1656250204 4x10-9 "Q9" B=1000 Conexão 4 Serviço "Qt" B=1000 4.0 8 0.1656250204 9x10-9 Serviço Conexão 9 Conexão 1 2 0.1532031455 3x10-9 3.0 Serviço 7 0.1532031455 8x10-9 Serviço Conexão 0 Conexão 9 Serviço 2.0 Conexão 4 1.0 0.0 0.0400 0.0402 0.0404 0.0406 0.0408 0.0410 0.0412 0.0414 0.0416 0.0418 0.0420 0.0422 0.0424 0.0426 0.0428 0.0430 Tempo (Segundos) Figura 6.2 – Ocupação da estrutura de filas do BTE_0 para o modelo de escalonador WF2Q. tk t k −1 ∑φ i Vtk Ftki −1 S tik φi Ftki i BT 0.0400010000 0.0400010000 0.1984810867 0 0 0 0.1984810867 5.0382634262 0 0.0400010000 0.0400010000 0.0400010000 0.4634811067 0 0 0 0.2650000200 3.7735846208 1 0.0400010000 0.0400010000 0.0400010000 0.6166842522 0 0 0 0.1532031455 6.5272811269 2 0.0400010000 0.0400010000 0.0400010000 0.7823092726 0 0 0 0.1656250204 6.0377351043 3 0.0400010000 0.0400010000 0.0400010000 1.3221639779 0 0 0 0.5398547053 1.8523502531 4 0.0400010000 0.0400010000 0.0400010000 1.5206450646 0 0 0 0.1984810867 5.0382634262 5 0.0400010000 164
  • 0.0400010000 0.0400010000 1.7856450846 0 0 0 0.2650000200 3.7735846208 6 0.0400010000 0.0400010000 0.0400010000 1.9388482301 0 0 0 0.1532031455 6.5272811269 7 0.0400010000 0.0400010000 0.0400010000 2.1044732505 0 0 0 0.1656250204 6.0377351043 8 0.0400010000 0.0400010000 0.0400010000 2.6443279558 0 0 0 0.5398547053 1.8523502531 9 0.0400010000 0.0407702310 0.0400010000 1.5646185452 0.0004916412 3.7735846208 3.7735846208 0.2650000200 7.5471692417 1 0.0407702310 0.0407702310 0.0407702310 1.5646185452 0.0004916412 3.7735846208 3.7735846208 0.2650000200 7.5471692417 6 0.0407702310 0.0410010000 0.0407702310 1.9059921638 0.0006127168 1.8523502531 1.8523502531 0.5398547053 3.7047005063 4 0.0410010000 0.0410010000 0.0410010000 2.4458468691 0.0006127168 1.8523502531 1.8523502531 0.5398547053 3.7047005063 9 0.0410010000 0.0414295710 0.0410010000 1.3661374585 0.0009264268 6.0377351043 6.0377351043 0.1656250204 12.0754702087 3 0.0414295710 0.0414295710 0.0414295710 1.3661374585 0.0009264268 6.0377351043 6.0377351043 0.1656250204 12.0754702087 8 0.0414295710 0.0415394620 0.0414295710 1.3661374585 0.0010068660 7.5471692417 7.5471692417 0.2650000200 11.3207538625 1 0.0415394620 0.0415394620 0.0415394620 1.3661374585 0.0010068660 7.5471692417 7.5471692417 0.2650000200 11.3207538625 6 0.0415394620 0.0420010000 0.0415394620 1.7075110771 0.0012771647 3.7047005063 3.7047005063 0.5398547053 5.5570507594 4 0.0420010000 0.0420010000 0.0420010000 2.2473657824 0.0012771647 3.7047005063 3.7047005063 0.5398547053 5.5570507594 9 0.0420010000 0.0423086920 0.0420010000 1.1676563718 0.0015406771 11.3207538625 11.3207538625 0.2650000200 15.0943384834 1 0.0423086920 0.0423086920 0.0423086920 1.1676563718 0.0015406771 11.3207538625 11.3207538625 0.2650000200 15.0943384834 6 0.0423086920 0.0425010000 0.0423086920 1.1676563718 0.0017053728 6.5272811269 6.5272811269 0.1532031455 13.0545622538 2 0.0425010000 0.0425010000 0.0425010000 1.1676563718 0.0017053728 6.5272811269 6.5272811269 0.1532031455 13.0545622538 7 0.0425010000 0.0428581430 0.0425010000 1.1676563718 0.0020112359 12.0754702087 12.0754702087 0.1656250204 18.1132053130 3 0.0428581430 0.0428581430 0.0428581430 1.1676563718 0.0020112359 12.0754702087 12.0754702087 0.1656250204 18.1132053130 8 0.0428581430 0.0430010000 0.0428581430 1.7075110771 0.0020948998 5.5570507594 5.5570507594 0.5398547053 7.4094010126 4 0.0430010000 0.0430010000 0.0430010000 2.2473657824 0.0020948998 5.5570507594 5.5570507594 0.5398547053 7.4094010126 9 0.0430010000 0.0430779230 0.0430010000 1.7075110771 0.0021399496 15.0943384834 15.0943384834 0.2650000200 18.8679231042 1 0.0430779230 0.0430779230 0.0430779230 1.7075110771 0.0021399496 15.0943384834 15.0943384834 0.2650000200 18.8679231042 6 0.0430779230 0.0438471540 0.0430779230 1.1676563718 0.0027987316 18.8679231042 18.8679231042 0.2650000200 22.6415077251 1 0.0438471540 0.0438471540 0.0438471540 1.1676563718 0.0027987316 18.8679231042 18.8679231042 0.2650000200 22.6415077251 6 0.0438471540 Tabela 6.3 – Evolução das variáveis do WF2Q_Scheduler durante a execução do algoritmo de armazenamento de células ATM. 6.2.6 - Amostragem por Eventos As simulações com amostragens por eventos tiveram uma duração de 0.25 segundos. Novamente, concentraremos nossa análise no BTE_0. Consideremos o intervalo de tempo entre os instantes 0.04 e 0.15 segundos, que é o intervalo de tempo em que acontece o congestionamento dos recursos da rede. A Figura 6.3 e a Figura 6.4 mostram o número de células armazenadas nas filas de cada conexão na estrutura de filas do BTE_0. Podemos observar que quando se utiliza o escalonador default (FCFS – First Coming First Served) as conexões 1, 6, 4, 9, 8 e 3 atingem ocupações maiores que 10 células no período entre 0.04 e 0.15, para o caso de 100 células de capacidade na estrutura de filas. Por outro lado, quando se utiliza o escalonador WF2Q, as conexões 4 e 9, de maior peso no escalonador (veja a Tabela 6.2), possuem ocupações iguais a 1 célula, o que indica que elas estão recebendo tratamento prioritário por parte deste escalonador. 165
  • Figura 6.3 – Ocupação das filas de cada conexão na estrutura de filas do BTE_0 sujeita a capacidade de 100 células para ambos os modelos de escalonadores. 166
  • Figura 6.4 – Ocupação das filas de cada conexão na estrutura de filas do BTE_0 sujeita a capacidade de 50 células para ambos os modelos de escalonadores. Na Figura 6.5 e na Figura 6.6 mostramos o atraso instantâneo sofrido pelas células, enquanto na Figura 6.7 e na Figura 6.8 mostramos o atraso médio das células de cada conexão neste intervalo. Podemos nitidamente ver que o escalonador WF2Q oferece um melhor isolamento de atraso entre as conexões do que o escalonador default. E mais, a partir da Figura 6.7 e da Figura 6.8 podemos ver 167
  • que as células das conexões de maior peso (4 e 9) que no escalonador default tiveram um maior atraso, no escalonador WF2Q estão entre as conexões que tiveram os menores atrasos. Portanto, podemos afirmar que o escalonador WF2Q é capaz de manter garantias de qualidade de serviço para cada conexão da rede, independente da presença de outras conexões. Entretanto, devemos observar que a qualidade de serviço oferecida pelo escalonador WF2Q depende de uma configuração cuidadosa dos pesos φi para cada conexão. Veja por exemplo o caso das conexões 1 e 6, que segundo a Tabela 6.2 estariam em terceiro e quarto lugares em termos de prioridade de atendimento. Estas conexões enfrentaram no período de 0.04 a 0.15 segundos os maiores valores de atraso dentre todas as conexões. Entretanto, isto não quer dizer que a qualidade de serviço negociada para esta conexão esteja sendo violada. De fato, o contrato de tráfego somente será desrespeitado se o algoritmo de controle de admissão de conexões alocar um peso abaixo daquele necessário para atender os descritores de tráfego indicados para uma dada conexão, ou se estes descritores estiverem defasados com relação ao tráfego que está sendo transmitido. 168
  • Figura 6.5 –Atraso instantâneo das células na estrutura de filas do BTE_0 com capacidade de 100 células para ambos os modelos de escalonadores. 169
  • Figura 6.6 – Atraso instantâneo das células na estrutura de filas do BTE_0 com capacidade de 50 células para ambos os modelos de escalonadores. 170
  • Figura 6.7 – Atraso médio das células na estrutura de filas do BTE_0 com capacidade de 100 células para ambos os modelos de escalonadores. 171
  • Figura 6.8 – Atraso médio das células na estrutura de filas do BTE_0 com capacidade de 50 células para ambos os modelos de escalonadores. A Figura 6.9 e a Figura 6.10 mostram o número de células perdidas na entrada da estrutura de filas PHY_OUT_QS_0 do BTE_0, enquanto a Figura 6.11 e a Figura 6.12 mostram a taxa de perda de células obtida. A taxa de perda de células depende fundamentalmente do CLR configurado para cada conexão (veja Tabela 6.2), uma vez que o modelo de algoritmo de descarte seletivo 172
  • utilizado descarta primeiro as células cuja conexão tem maior CLR configurado. A partir da Figura 6.9, e considerando o escalonador default, podemos observar que quando a capacidade da estrutura de filas é igual a 100 células, somente são descartadas células da conexão 91. Isto ocorre porque a quantidade de células que chega para ser armazenada na fila lógica desta conexão no intervalo de tempo considerado é maior do que a de outras conexões, uma vez que o escalonador default atende todas as conexões sem diferenciação. Quando a capacidade da estrutura de filas é igual a 50 células, são descartadas células das conexões 9, 8, 7 e 6, sendo que as conexões 9 e 8 são as mais prejudicadas. Por outro lado, quando se utiliza o escalonador WF2Q o cenário muda drasticamente. As filas para as conexões de maior peso (com exceção das filas para as conexões 1 e 6) mantém-se com tamanhos máximos inferiores do que quando se usa o escalonador default. Portanto o CLR observado é bastante reduzido (para a conexão 9 o CLR foi reduzido para aproximadamente a metade). 1 Observe que na Figura 6.9 o gráfico da conexão 9 está sobreposto pelo gráfico dos totais para todas as conexões. 173
  • Figura 6.9 – Número de células perdidas na estrutura de filas do BTE_0 com capacidade de 100 células para ambos os modelos de escalonadores. 174
  • Figura 6.10 – Número de células perdidas na estrutura de filas do BTE_0 com capacidade de 50 células para ambos os modelos de escalonadores. 175
  • Figura 6.11 – CLR na estrutura de filas do BTE_0 com capacidade de 100 células para ambos os modelos de escalonadores. 176
  • Figura 6.12 – CLR na estrutura de filas do BTE_0 com capacidade de 50 células para ambos os modelos de escalonadores. 6.2.7 - Amostragem por Tempo As simulações com amostragens por tempo tiveram uma duração de 60 segundos. Para as simulações com amostragem por tempo os gráficos das figuras a seguir têm como eixo horizontal a 177
  • capacidade de armazenamento da estrutura de filas PHY_OUT_QS_0 do BTE_0. A Figura 6.13 e a Figura 6.14 mostram a ocupação média e o atraso médio das células nesta estrutura de filas. Figura 6.13 – Ocupação média na estrutura de filas do BTE_0 para os dois modelos de escalonadores. Podemos observar que após 60 segundos de simulação existe uma tendência de que a ocupação média das filas para cada conexão no escalonador default seja aproximadamente a mesma 178
  • para todas as conexões. Já no escalonador WF2Q estas ocupações se mantêm bastante distintas, refletindo, portanto a diferenciação de serviços existente neste escalonador. A mesma observação é válida para o atraso médio. Figura 6.14 – Atraso médio na estrutura de filas do BTE_0 para os dois modelos de escalonadores. 179
  • A Figura 6.15 mostra a taxa média de perda de células na estrutura de filas PHY_OUT_QS_0 e a utilização média dos escalonadores do BTE_0. Consideremos a Figura 6.15a para o escalonador default. Podemos observar que para a capacidade de armazenamento de 1000 células, somente foram perdidas células nas conexões 9, 8, 7 e 6. Para a capacidade de 500 células também foram perdidas células nas mesmas conexões. Para a capacidade de 100 células, além das conexões anteriores, a conexão 5 também perdeu células. Para a capacidade de 50 células, o cenário se manteve. A partir destes resultados, podemos observar que, como esperado, o CLR das conexões aumenta a medida que a capacidade das estruturas de filas diminui. Outro aspecto importante que podemos observar é que as conexões mais afetadas foram aquelas que requereram valores maiores de CLR em seu contrato de tráfego (conexões 9, 8, 7 e 6), de acordo com a Tabela 6.2. Para o escalonador WF2Q (Figura 6.15c) as conexões que tiveram maiores perdas considerando a capacidade de 1000 células também foram as conexões 9, 8, 7 e 6. Para a capacidade de 500 células, o cenário se manteve. Para a capacidade de 100 células, a maioria das conexões tiveram perdas. Para a capacidade de 50 células, o CLR de todas as conexões aumentou como esperado. Podemos observar que o padrão de CLR obtido para as conexões 9, 8, 7 e 6 seguiu a ordem inversa daquele obtido quando se usou o escalonador default. A principal razão para isto é que no escalonador WF2Q as conexões de maior peso (conexões 9 e 6) obtiveram ocupações menores em suas filas do que no escalonador default, compensando assim os altos valores de CLR requeridos em seu contrato de tráfego, conforme mostrado na Tabela 6.2. Com relação a utilização média do escalonador, as figuras: Figura 6.16b e Figura 6.16d mostram que o escalonador WF2Q obteve uma utilização ligeiramente superior a do escalonador default. 180
  • Figura 6.15 – CLR médio na estrutura de filas do BTE_0 para os dois modelos de escalonadores. 181
  • Figura 6.16 – Utilização média dos escalonadores. 6.3 - Simulação 2: Análise da QoS em SVCs ATM O objetivo desta simulação é avaliar se as garantias de QoS negociadas para cada conexão durante a fase de estabelecimento de conexões estão sendo cumpridas. Também é avaliado o 182
  • impacto que uma conexão extra causa sobre as demais conexões existentes. Para tanto, é considerada uma rede ATM sujeita a duas situações: 1. Congestionada – O modelo de CAC aceita quatro SVCs que são criados a partir dos aplicativos App_0, App_1, App_2 e App_3 (Conexões 0 a 3). 2. Severamente Congestionada – O modelo de CAC aceita uma SVC extra que é criada a partir do aplicativo App_4 (Conexão 4). 6.3.1 - Configuração da Rede no Simulador A Figura 6.17 mostra a topologia da rede simulada. Ela é composta por cinco aplicativos externos (App_0 até App_4), dois terminais faixa larga (BTE_0 e BTE_1), um comutador (Switch_0), um gerente (Manager_0) e um aplicativo receptor (App_5). Taxa por Porta da Switch Fabric: 353207.54 células/ Taxa do Enlace: seg. 2415.09 células/seg. Gerente Terminal Comutador Terminal Aplicativo Faixa Faixa Receptor Larga Larga Aplicativo Fonte Figura 6.17 – Topologia da utilizada para avaliar a QoS de SVCs ATM. Os cinco aplicativos transmitem respectivamente cinco seqüências de tráfego de pacotes MPEG-4, conforme será apresentado na seção 6.3.3 - . Todas as conexões utilizam a categoria de serviço nrt-VBR (Non Real-time Variable Bit Rate) e os descritores de tráfego ATM são configurados de acordo com a Tabela 6.4. Os enlaces entre o terminal BTE_0 e o chaveador SW_0 e entre o chaveador SW_0 e o terminal BTE_1 tem a capacidade de 1024 Kbits/segundo. A taxa de serviço da matriz de comutação em cada porta do chaveador SW_0 foi configurada para 149.76 183
  • Mbits/segundo. A distância entre o BTE_0 e o SW_0 é de 10 metros, e entre o SW_0 e o BTE_1 é de 80 metros. A velocidade de propagação do sinal é de 200×106 metros/seg. 6.3.2 - Definição das Simulações Foram realizadas 8 simulações para cada uma das situações de congestionamento definidas anteriormente. Em cada uma delas, a capacidade das estruturas de filas dos blocos BTE_0, BTE_1 e Switch_0 foram configuradas para 16000, 8000, 4000, 2000, 1000, 500, 100 and 50 células, respectivamente. 6.3.3 - Configuração dos Modelos Descritores de Tráfego Seqüência Descritor PCR (células/seg.) CDVT (seg.) SCR (células/seg.) MBS (células) CLR Silêncio dos Inocentes 1400 0.0007143 1120 437 1×10-6 South Park 1191.61 0.0008392 954 52 2×10-6 Simpson’s 1125 0.0008889 900 447 3×10-6 Duro de Matar III 1125 0.0008889 900 46 4×10-6 Futurama 1106.25 0.0009039 885 216 5×10-6 Tabela 6.4 – Descritores de tráfego ATM utilizados. Tomando como referência a Figura 6.17, os seguintes modelos de gerenciadores de tráfego foram utilizados nos terminais BTE_0 e BTE_1, e no chaveador Switch_0: Estrutura de Filas – Foi utilizado somente o modelo estrutura de filas com filas por conexão (Per_VC_Queueing_Structure). Escalonador – Foi utilizado o escalonador LFVC_Scheduler. Controle de Admissão de Conexões – Foi utilizado o modelo controle de admissão de conexões com alocação baseada em critérios de banda e buffer efetivos (Elwalid_Mitra_CAC). Gerenciador de Estrutura de Filas – Foi utilizado o modelo gerenciador de estrutura de filas com particionamento dinâmico (Dynamic_Partitioning_BM). 184
  • Descarte Seletivo de Células – Foi utilizado o modelo descarte seletivo de células baseado no CLR (CLR_SD). 6.3.4 - Resultados A fim de facilitar nossa análise, a Tabela 6.5 mostra os pesos φi alocados pelo modelo de controle de admissão de conexões para cada conexão i. Seqüência i φi CLR Silêncio dos Inocentes 3 0.4637 1×10-6 South Park 2 0.3947 2×10-6 Simpson’s 1 0.3726 3×10-6 Duro de Matar III 4 0.3726 4×10-6 Futurama 0 0.3664 5×10-6 Tabela 6.5 – Pesos e CLR para cada conexão. As figuras: Figura 6.18, Figura 6.19, Figura 6.20 e Figura 6.21 mostram o que acontece com a qualidade de serviço das conexões 0 até 3 quando a conexão 4 é aceita independentemente da recomendação do modelo de CAC. Os seguintes comentários podem ser feitos quando se compara a transição da situação 1 para a situação 2: Conexão 0 – Esta conexão não foi severamente afetada pela presença da conexão 4. Um efeito interessante que pode ser observado é a redução da ocupação da estrutura de filas para capacidades entre 1000 e 4000 células. Isto aconteceu porque a conexão 0 tem o menor peso dentre as conexões (veja a Tabela 6.5), perdendo espaço para as outras conexões. Como conseqüência, o tempo de permanência das células na estrutura de filas seguiu este mesmo padrão. De forma geral, o CLR para a situação 2 também é superior do que para a situação 1. Conexão 1 – Esta conexão foi mais afetada pela presença da conexão 4 do que a conexão 0, especialmente para pequenas e grandes capacidades da estrutura de filas. Tanto o tempo de permanência das células quanto o CLR aumentaram na situação 2. Conexão 2 – Esta conexão foi drasticamente afetada pela presença da conexão 4, não apenas em termos de tempo de permanência das células na fila quanto em termos do CLR. 185
  • Conexão 3 – Esta conexão também foi bastante afetada pela presença da conexão 4 principalmente com relação ao atraso das células. Observe que para todas as conexões, o CLR negociado foi garantido apenas na situação 1 e para capacidades (da estrutura de filas) maiores que 16000 células. Figura 6.18 – Ocupação média da estrutura de filas do BTE_0. 186
  • Figura 6.19 – Atraso médio das células na estrutura de filas do BTE_0. Figura 6.20 – Taxa média de perda de células na estrutura de filas do BTE_0. Figura 6.21 – Atraso médio fim-a-fim das células na rede. 187
  • 6.4 - Simulação 3: Cenário NVoD MPEG-4 sobre ATM Como vimos no Capítulo 5, o MPEG-4 está sendo considerado o padrão mais indicado para as aplicações de vídeo iterativo que utilizarão as futuras redes de telecomunicações faixa larga. Diante desta expectativa, decidimos simular um cenário de vídeo sobre demanda (NVoD – Near Video on Demand) MPEG-4 sobre ATM no Hydragyrum usando o conjunto de modelos no nível de células. Conforme apresentado no Capítulo 5, as principais razões para esta escolha foram: a disponibilidade de seqüências de tráfego reais para serem utilizadas nas simulações, a não necessidade de desenvolvimento de novos modelos de protocolos, tais como TCP, IP e RTP, e o relativo ineditismo de trabalhos que relacionem as tecnologias MPEG-4 e ATM. A Figura 6.22 mostra a pilha de protocolos presente em cada componente do sistema de vídeo sobre demanda MPEG-4 sobre ATM. Filme 1 Filme 2 Adaptação de Rede Cliente Servidor NVoD Switch ATM Filme N MPEG MPEG MPEG SPTS MPEG SPTS AAL 5 AAL 5 ATM ATM ATM PHY PHY PHY Figura 6.22 – Cenário vídeo sobre demanda MPEG-4 sobre ATM nativo. 6.4.1 - Configuração do Cenário no Simulador Nesta seção apresentaremos como foi feito o mapeamento do cenário da Figura 6.22 para os modelos do CMNC. A Figura 6.23 mostra os blocos utilizados para mapear o cenário da Figura 6.22. 188
  • Figura 6.23 – Cenário NVoD MPEG-4 sobre ATM utilizando o Conjunto de Modelos no Nível de Células. App_0 até App_24 Pacotes Manager_0 MPEG-4 Pacotes Camada Criadora de Conexões MPEG-4 Camada Removedora de Conexões App_25 Switch_0 Camada Fonte de Tráfego Controle de Camada Removedora de Conexões ATM_OUT_CAC_S Admissão de Matriz de Conexões Comutação com Memória Camada Receptora de Tráfego Compartilhada Camada Receptora de Tráfego Gerencimento de ATM_OUT_BM_S Estrutura de Filas Policiamento Descarte Seletivo de ATM_OUT_SD_S ATM_OUT_TP_S Células BTE_0 Escalonador ATM_OUT_S_0 BTE_1 ATM_OUT_QS_S Estrutura de Fila Camada de Adaptação ATM Escalonador ATM_OUT_S_1 Camada de Adaptação ATM Camada ATM Células Camada ATM Células Camada ATM ATM ATM Camada Física de Camada Física de Camada Física de Camada Física de Camada Física de Camada Física de Entrada Saída Entrada Saída Entrada Saída Estrutura de Fila PHY_OUT_QS_0 Estrutura de Fila Estrutura de Fila Estrutura de Fila Escalonador PHY_OUT_S_0 Escalonador Escalonador Escalonador Controle de Controle de Admissão de Controle de Admissão de Controle de Admissão de Admissão de PHY_OUT_CAC_0 Conexões Conexões Conexões Conexões Gerencimento de Gerencimento de Gerencimento de Gerencimento de Estrutura de Filas PHY_OUT_BM_0 Estrutura de Filas Estrutura de Filas Estrutura de Filas Descarte Seletivo de Descarte Seletivo de Descarte Seletivo de Descarte Seletivo de Células PHY_OUT_SD_0 Células Células Células Policiamento PHY_OUT_TP_0 Policiamento Policiamento Policiamento Gerenciadores de Caminho percorrido Camadas Tráfego pelas células ATM QS - Queuing CAC - Connection BM - Buffer SD - Selective TP - Traffic S - Scheduler Structure Admission Control Management Discard Policie Figura 6.24 – Visão detalhada do cenário NVoD MPEG-4 sobre ATM utilizando o CMNC. 189
  • O tráfego MPEG-4 será carregado por aplicativos externos (App_0 até App_24) e encaminhado para um terminal faixa larga (BTE – Broadband Terminal Equipment), que funcionará como um servidor de vídeo sob demanda (BTE_0). No ponto final da rede, outro terminal faixa larga (BTE_1) fará o papel de um adaptador de rede, entregando o vídeo codificado MPEG-4 para um único aplicativo de destino (App_25), que fará o papel de todos os clientes do sistema. A Figura 6.24 mostra de uma forma mais detalhada os modelos envolvidos na simulação do deste cenário no Hydragyrum, bem como o trajeto que será percorrido pela células ATM durante a simulação deste sistema. Inicialmente a camada criadora de conexões de cada aplicativo fonte (App_0 até App_24) requisita ao modelo gerente (Manager_0) uma conexão de rede entre o BTE_0 e o BTE_1 e uma conexão de dados entre o aplicativo fonte e o aplicativo de destino (App_25). O contrato de tráfego com os pré-requisitos de qualidade de serviço de cada aplicativo também é informado ao modelo gerente. Este então, iterativamente, escolhe uma rota que liga o BTE_0 ao BTE_1, sendo que em cada equipamento ATM um processo de requisição por recursos é executado nos modelos de controle de admissão de conexões. Se as requisições por novas conexões forem aceitas, a camada fonte de tráfego de cada aplicativo, carrega uma seqüência de pacotes de fluxo de transporte MPEG-4 (MPEG Transport Stream), e envia estes pacotes para a camada de adaptação ATM do BTE_0. No BTE_0 os pacotes MPEG-4 serão adaptados em células ATM e enviados para a camada ATM. Na camada ATM, o cabeçalho das células é configurado, e estas são então enviadas para a camada física de saída (PHY_OUT) do BTE_0. Neste ponto, é executado o modelo do algoritmo de gerenciamento de estrutura de filas (PHY_OUT_BM_0), a fim verificar se uma nova célula pode ser armazenada na estrutura de filas PHY_OUT_QS_0. Se o gerenciador de estrutura de filas decidir que a nova célula não pode ser armazenada, é executado o modelo de algoritmo de descarte seletivo de células (PHY_OUT_SD_0). Dependendo do modelo de descarte seletivo utilizado, será descartada a célula recém recebida ou uma outra célula de menor prioridade que já se encontra armazenada na estrutura de filas. Por outro lado, se o gerenciador de estrutura de filas decidir que a nova célula pode ser armazenada, ela é então encaminhada para o modelo de estrutura de filas PHY_OUT_QS_0 e para o modelo de escalonador PHY_OUT_S_0. Após um certo tempo, o modelo de escalonador PHY_OUT_S_0 determina de acordo com o seu algoritmo de escalonamento o inicio do serviço da célula ATM. Feito isso, a célula é encaminhada de volta para a camada física de saída, onde um atraso de propagação é calculado. Na 190
  • seqüência, a célula é então enviada para o próximo equipamento da rede, no caso o Switch_0. No Switch_0, a célula é enviada diretamente para a camada ATM. Nesta camada é verificado se a célula pode ser armazenada na estrutura de filas ATM_OUT_QS_S, que é compartilhada por todas as portas de saída da matriz de comutação. Novamente, esta função é realizada por um modelo de gerenciador de estrutura de filas (ATM_OUT_BM_S). Se o gerenciador de estrutura de filas decidir que a nova célula não pode ser armazenada, é executado então o modelo de algoritmo de descarte seletivo de células (ATM_OUT_SD_S). Por outro lado, se o gerenciador de estrutura de filas decidir que a célula pode ser armazenada, primeiramente é feita a comutação da célula para a porta de saída apropriada (Porta 0 ou 1). Posteriormente, a célula é encaminhada para o modelo de estrutura de filas ATM_OUT_QS_S e para o modelo de escalonador associado a esta porta de saída (ATM_OUT_S_0 ou ATM_OUT_S_1). Após um certo tempo, o modelo de escalonador apropriado determina de acordo com o seu algoritmo de escalonamento o inicio do serviço da célula ATM. Feito isso, a célula é encaminhada de volta para a camada ATM, de onde será enviada para a camada física de saída (PHY_OUT) do Switch_0. Nesta camada a célula é tratada da mesma forma que na camada física de saída do BTE_0. A célula é então enviada para o BTE_1, onde o processo de remontagem em um pacote MPEG-4 será executado. Finalmente, os pacotes MPEG-4 são entregues ao aplicativo de destino (App_25). 6.4.2 - Definição das Simulações A avaliação de desempenho do cenário MPEG-4 sobre ATM da Figura 6.24 foi realizada através de diversas simulações. Em cada simulação somente um dos seguintes aspectos foi variado: (U)2 Número de aplicativos enviando tráfego na rede – Foram utilizadas cinco configurações de aplicativos cada qual com cinco aplicativos transmitindo (veja a Figura 6.23). Inicialmente somente os aplicativos App_0 até App_4 transmitem (U=0). Na segunda configuração além dos cinco primeiros aplicativos (App_0 até App_4), os 2 Utilizaremos as letras (U), (B), (V) e (Z) para identificar o estado de cada um dos aspectos considerados em cada simulação. Por exemplo, se U=2, B=2, V=1 e Z=1, significa que: a rede simulada possui 15 aplicativos transmitindo (App_0 até App_14); a capacidade máxima das estruturas de filas da rede é de 100 células; foram utilizados os modelos de CAC Elwalid Mitra e de gerenciador de estruturas de filas com particionamento dinâmico; foi utilizado o escalonador WF2Q. Utilizaremos a notação (U)(B)(V)(Z) para identificar os resultados de acordo com os aspectos considerados em cada simulação. 191
  • aplicativos App_5 até App_9 também transmitem (U=1). Na terceira configuração além dos aplicativos (App_0 até App_9), os aplicativos App_10 até App_14 também transmitem (U=2). Na quarta configuração transmitem os aplicativos App_0 até App_19 (U=3), e na última configuração todos os aplicativos transmitem (U=4). (B) Capacidade de armazenamento de células nas estruturas de filas – Foram utilizadas quatro configurações de capacidade de armazenamento de células nas estruturas de filas dos equipamentos BTE_0, Switch_0 e BTE_1. Na primeira configuração todas as estruturas de filas têm capacidade máxima de 1000 células (B=0). Na segunda configuração todas as estruturas têm capacidade máxima de 500 células (B=1). Na terceira e quarta configuração a capacidade máxima das estruturas de filas são de 100 (B=2) e de 50 células (B=3), respectivamente. (V) Modelos de Controle de Admissão de Conexões (CAC), de Gerenciamento de Estruturas de Filas (BM) e de Descarte Seletivo de Células (SD) – Foram utilizadas duas configurações de modelos. Na primeira configuração (V=0) foram utilizados os modelos de CAC, de gerenciamento de estruturas de filas e de descarte seletivo de default. Na segunda configuração (V=1), foi utilizado o modelo de CAC Elwalid Mitra, o modelo de gerenciador de estruturas de filas com particionamento dinâmico e o modelo de descarte seletivo de células baseado no CLR3. (Z) Modelos de Escalonadores – Foram utilizadas quatro configurações de modelos de escalonador. Na primeira configuração (Z=0) todos os equipamentos da rede utilizam o escalonador default. Na segunda configuração (Z=1) todos os equipamentos da rede utilizam o escalonador WF2Q. Na terceira configuração (Z=2) é utilizado o escalonador LFVC, e na quarta configuração (Z=3) é utilizado o escalonador regulador de tráfego virtual scheduling. Foram feitas ao total 160 simulações (U×B×V×Z = 5×4×2×4). A duração de cada simulação foi de 60 segundos, e demorou em torno de 50 minutos para ser executada em um microcomputador Athlon Thunderbird de 1 GHz com 256 Mbytes de memória RAM. Portanto, a duração total das 3 Em caso de congestionamento na rede, este modelo de descarte seletivo descarta as células das conexões com menor pré-requisito de CLR em prol das células das conexões com um maior pré-requisito de CLR. 192
  • simulações ficou em torno de 133 horas (5.54 dias). A seguir veremos como foram configurados os principais parâmetros dos modelos da rede da Figura 6.23. 6.4.3 - Configuração dos Modelos 6.4.3.1 - Aplicativos Os aplicativos fonte (App_0 até App_24) são aplicativos externos capazes de carregar arquivos com seqüências de tráfego de pacotes a serem transmitidas na rede. Portanto utilizam a camada fonte de tráfego externo. Neste exemplo de simulação, utilizaremos cinco seqüências de frame size MPEG-4 disponibilizadas pelo Grupo de Redes de Telecomunicações da Universidade Técnica de Berlin [2]. As seqüências utilizadas foram: Parque dos Dinossauros (Jurassic Park). Silêncio dos Inocentes (Silence of The Lambs). Programa de Entrevistas (Boulevard Bio). Corrida de Fórmula 1 (Formula 1). Desenho Animado (Simpsons). Como vimos no capítulo anterior, antes de utilizar estas seqüências de tráfego, é necessário adaptá-las do nível de tamanho de frames MPEG (Fluxo de Vídeo Elementar) [2] para o nível de pacotes de fluxo de transporte MPEG (MPEG TS – Transport Stream). Também no capítulo anterior, apresentamos um software para a estimação de descritores de tráfego ATM visando o transporte de tráfego MPEG sobre ATM. Neste exemplo de simulação, utilizamos estes dois softwares para adaptar e estimar os descritores de tráfego ATM das seqüências de vídeo codificado MPEG-4 acima. A Tabela 6.6 sumariza os descritores de tráfego estimados para estas seqüências. Descritores de Tráfego Seqüência Descritor PCR (células/seg.) CDVT (seg.) SCR (células/seg.) MBS (células) Parque dos Dinossauros 1198.3763 0.000830 958.7010 51 Silêncio dos Inocentes 1600 0.000625 1280 107 Programa de Entrevistas 925 0.001081 740 41 Corrida de Fórmula 1 1000 0.001 800 66 Desenho Animado 3259.5052 0.000307 2607.6041 76 Tabela 6.6 – Descritores de tráfego ATM utilizados. 193
  • Dependendo da configuração de aplicativos utilizada em cada simulação, cada aplicativo fonte da Figura 6.23 estabelece uma conexão chaveada ATM até o aplicativo de destino App_25. Quando somente os aplicativos App_0 até App_4 transmitem (U=0), as cinco seqüências de tráfego de pacotes MPEG-4 apresentadas na página anterior são utilizadas em seqüência, uma para cada aplicativo. Quando além dos cinco primeiros aplicativos (App_0 até App_4), os aplicativos App_5 até App_9 também transmitem (U=1), as seqüências de tráfego MPEG-4 apresentadas na página anterior são utilizadas em seqüência nos cinco primeiros aplicativos e reutilizadas em seqüência nos demais. A reutilização das seqüências MPEG-4 também é feita para as configurações de aplicativos U=2, U=3 e U=4. Todas as conexões chaveadas estabelecidas a partir dos aplicativos fonte utilizaram a categoria de serviço nrt-VBR (Non Real-time Variable Bit Rate). Portanto, a camada criadora de conexões com taxa de bits variável não em tempo real foi utilizada em todos os aplicativos fonte da Figura 6.23. O CLR utilizado no contrato de tráfego de cada aplicativo é incrementado a partir de 1×10-6. Ou seja, o CLR do contrato de tráfego do aplicativo App_0 é configurado como 1×10-6. Já para o aplicativo App_1 é configurado o CLR de 2×10-6. E assim por diante, até que o CLR do contrato de tráfego do aplicativo App_24 seja configurado como 25×10-6. A definição de conformidade utilizada no contrato de tráfego de todos os aplicativos fonte foi a VBR.1. 6.4.3.2 - Terminais Faixa Larga Tanto no BTE_0 quanto no BTE_1 foram utilizados os modelos de estruturas de filas com filas por conexão (Per VC Queueing Structure). O modelo de policiador leaky bucket permaneceu desligado em ambos os terminais faixa larga. Portanto, nenhuma célula foi descartada por inconformidade nestes terminais. Na camada de adaptação ATM (AAL) do BTE_0 foi utilizado um atraso de empacotamento de células de 1×10-6 segundos. Na camada física de saída do BTE_0 foi utilizado um atraso de propagação de 200×106 metros/segundo e uma distância de 10 metros até o Switch_0. A taxa no enlace de saída do BTE_0 até o Switch_0 foi configurada em 4830.1886 células/segundo, o que equivale a uma taxa de 2.048 Mbits/segundo. Os modelos de controle de admissão de conexões do BTE_0 e do BTE_1 foram desativados, permitindo, portanto que todas as requisições para estabelecer novas conexões fossem aceitas. Isto foi feito para garantir que houvesse congestionamento na rede simulada, uma vez que se este modelo estivesse ativado apenas um número limitado de novas conexões seriam aceitas. Entretanto, é importante observar que o fato dos 194
  • modelos de CAC estarem desativados não implica no cancelamento das demais funções realizadas por estes modelos no BTE_0 e no BTE_1. Nas simulações em que se utiliza o modelo de gerenciamento de estrutura de filas com particionamento dinâmico (V=1) os parâmetros Gama e Alfa deste modelo foram configurados em 0.75 e 1, respectivamente. 6.4.3.3 - Chaveador O chaveador Switch_0 também utiliza os modelos de estruturas de filas com filas por conexão (Per VC Queueing Structure). No Switch_0 os modelos de policiador leaky bucket permaneceram ligados. Portanto, é possível que células sejam descartadas por inconformidade tanto na camada física de entrada quanto na camada ATM do Switch_0. A taxa dos enlaces internos da switch fabric (camada ATM) foi configurada em 353207.5471 células/segundo, ou 149.76 Mbits/segundo. Na camada física de saída do Switch_0 foi utilizado um atraso de propagação de 200×106 metros/segundo e uma distância de 80 metros até o BTE_1. A taxa no enlace de saída do Switch_0 até o BTE_1 também foi configurada em 4830.1886 células/segundo, o que equivale a uma taxa de 2.048 Mbits/segundo. Assim como no BTE_0 e no BTE_1, no Switch_0 os modelos de controle de admissão de conexões associados à camada física de saída e à camada ATM foram desativados, permitindo, portanto que todas as requisições para estabelecer novas conexões fossem aceitas. Da mesma forma também, nas simulações em que se utiliza o modelo de gerenciamento de estrutura de filas com particionamento dinâmico (V=1) os parâmetros Gama e Alfa deste modelo foram configurados em 0.75 e 1, respectivamente. 6.4.4 - Resultados Nesta seção apresentaremos os resultados obtidos a partir da simulação do cenário da Figura 6.22. Os resultados obtidos serão apresentados através de gráficos de colunas, como mostra a Figura 6.25. No eixo X teremos a carga de aplicativos da rede, ou seja, o número de aplicativos transmitindo tráfego MPEG-4 na rede simultaneamente. No eixo Y teremos a ocupação média, o atraso médio e a taxa média de perda de células para cada conexão da rede após 60 segundos de simulação. Cada figura mostrará quatro gráficos, um para cada modelo de escalonador utilizado. Portanto, em cada figura poderemos visualizar os resultados obtidos para cada conexão diante de: Todas as configurações de aplicativos fonte (U). Todas as configurações de modelos de escalonadores (Z). 195
  • Uma determinada capacidade de armazenamento de células (B), como por exemplo, 100 células (B=3). Uma determinada configuração de modelos de CAC, BM e SD (V), como por exemplo, CAC Elwalid Mitra, BM com particionamento dinâmico e SD baseado no CLR (V=1). Capacidade de armazenamento de células de 50 células (B=3) Variavél de Configuração de modelos de CAC Elwalid Mitra, BM com particionamento dinâmico e SD baseado no CLR (V=1) resultado para a conexão i Z=0 Z=1 0 Escalonador Default 0 Escalonador WF2Q 10 10 CLR0 CLR0 CLR1 CLR1 CLR2 CLR2 Variável de CLR3 CLR4 CLR3 CLR4 resultado -1 CLR5 CLR6 -1 CLR5 CLR6 10 CLR7 10 CLR7 CLR8 CLR8 CLR9 CLR9 CLR10 CLR10 CLR11 CLR11 CLR12 CLR12 CLR13 CLR13 -2 -2 CLR CLR 10 CLR14 10 CLR14 CLR15 CLR15 CLR16 CLR16 CLR17 CLR17 CLR18 CLR18 CLR19 CLR19 CLR20 CLR20 -3 CLR21 -3 CLR21 10 CLR22 10 CLR22 CLR23 CLR23 CLR24 CLR24 -4 -4 10 10 5 10 15 20 25 5 10 15 20 25 Carga (Número de Aplicativos) Carga (Número de Aplicativos) 10 0 Escalonador LFVC Z=2 100 Escalonador VS Z=3 CLR0 CLR0 CLR1 CLR1 CLR2 CLR2 CLR3 CLR3 CLR4 CLR4 CLR5 CLR5 -1 CLR6 -1 CLR6 10 CLR7 10 CLR7 CLR8 CLR8 CLR9 CLR9 CLR10 CLR10 CLR11 CLR11 CLR12 CLR12 CLR13 CLR13 -2 -2 CLR CLR 10 CLR14 10 CLR14 CLR15 CLR15 CLR16 CLR16 CLR17 CLR17 CLR18 CLR18 CLR19 CLR19 CLR20 CLR20 -3 CLR21 -3 CLR21 10 CLR22 10 CLR22 CLR23 CLR23 CLR24 CLR24 -4 -4 10 10 5 10 15 20 25 5 10 15 20 25 Carga (Número de Aplicativos) Carga (Número de Aplicativos) 9/10/2001 09:21:58 U=0 U=1 U=2 U=3 U=4 Figura 6.25 – Exemplo de figura de resultados para a configuração de simulação (U)(3)(1)(Z). Antes de iniciarmos a apresentação dos resultados, mostraremos na Tabela 6.7 um resumo das principais características das conexões estabelecidas a partir de cada aplicativo da rede (App_0 até App_24). Como vimos na seção 6.4.3.1 - , as seqüências de tráfego MPEG-4 foram reutilizadas para cada configuração de aplicativos (U) simulada. Devido a esta reutilização, as conexões que transmitem uma mesma seqüência de tráfego MPEG-4 possuem o mesmo o peso φi . A Tabela 6.7 mostra também os pré-requisitos de CLR negociados para cada uma das conexões, bem como os aplicativos que transmitem em cada configuração U. 196
  • Seqüência de Tráfego Desenho Animado Silêncio dos Inocentes Parque dos Dinossauros Corrida de Fórmula 1 Programa de Entrevistas φi 0.5398547053 0.2650000200 0.1984810867 0.1656250204 0.1532031455 Conexão i 4 9 14 19 24 1 6 11 16 21 0 5 10 15 20 3 8 13 18 23 2 7 12 17 22 CLR (×10-6) 5 10 15 20 25 × 2 7 12 17 22 1 6 11 16 21 4 9 14 19 24 3 8 13 18 23 × × × × × U 0 × × × × × × × × × × 1 × × × × × × × × × × × × × × × 2 × × × × × × × × × × × × × × × × × × × × 3 × × × × × × × × × × × × × × × × × × × × × × × × × 4 Tabela 6.7 – Principais características das conexões estabelecidas a partir de cada aplicativo da rede. 6.4.4.1 - Ocupação Média por Conexão Apresentaremos os resultados obtidos na estrutura de filas PHY_OUT_QS_0 do BTE_0. Esta estrutura de filas concentra o tráfego vindo de todos os aplicativos fonte, sendo, portanto o ponto de maior congestionamento da rede. A seguir faremos alguns comentários relativos as figuras: Figura 6.26 até a Figura 6.41: A ocupação média das conexões quando se utiliza o escalonador default é praticamente igual a ocupação média das conexões quando se utiliza o escalonador regulador de tráfego virtual scheduling (VS). Isto ocorre porque a ordem de serviço das células no escalonador VS é praticamente a mesma do que no escalonador default, uma vez que a grande maioria das células ATM encontra-se em conformidade com os descritores de tráfego utilizados para regular o tráfego neste escalonador. Em outras palavras, somente de tempos em tempos a transmissão de uma célula é adiada por no máximo um slot de tempo, portanto não causando diferença significativa na média da ocupação das filas por conexão. Este fenômeno ocorre desde a Figura 6.26 até a Figura 6.41. Existe uma considerável diferença entre a ocupação média das conexões nos escalonadores Default e VS, com relação aos escalonadores WF2Q e LFVC. Nitidamente, tanto o escalonador WF2Q, quanto o escalonador LFVC atendem de forma diferenciada as células das conexões ATM. Já os escalonadores Default e VS, atendem todas as conexões com a mesma prioridade, o que resulta em uma ocupação média por conexão semelhante para todas as conexões. Isto ocorre desde a Figura 6.26 até a Figura 6.41. 197
  • Capacidade de 1000 Células (B=0) Modelo de CAC, BM e SD Default (V=0) Figura 6.26 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(0)(Z). 198
  • Figura 6.27 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(0)(Z). Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) 199
  • Figura 6.28 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(1)(Z). 200
  • Figura 6.29 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(1)(Z). 201
  • Capacidade de 500 Células (B=1) Modelo de CAC, BM e SD Default (V=0) Figura 6.30 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(0)(Z). 202
  • Figura 6.31 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(0)(Z). 203
  • Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) Figura 6.32 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(1)(Z). 204
  • Figura 6.33 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(1)(Z). 205
  • Capacidade de 100 Células (B=2) Modelo de CAC, BM e SD Default (V=0) Figura 6.34 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(0)(Z). 206
  • Figura 6.35 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(0)(Z). 207
  • Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) Figura 6.36 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(1)(Z). 208
  • Figura 6.37 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(1)(Z). 209
  • Capacidade de 50 Células (B=3) Modelo de CAC, BM e SD Default (V=0) Figura 6.38 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(0)(Z). 210
  • Figura 6.39 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(0)(Z). 211
  • Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) Figura 6.40 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(1)(Z). 212
  • Figura 6.41 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(1)(Z). 213
  • 6.4.4.2 - Atraso Médio por Conexão Apresentaremos os resultados obtidos na estrutura de filas PHY_OUT_QS_0 do BTE_0. A seguir faremos alguns comentários relativos as figuras: Figura 6.42 até a Figura 6.57: O atraso médio das células ATM quando se utiliza o escalonador default é praticamente igual ao atraso médio das células quando se utiliza o escalonador regulador de tráfego virtual scheduling (VS). Novamente, isto ocorre porque a ordem de serviço das células no escalonador VS é praticamente a mesma do que no escalonador default, uma vez que a grande maioria das células ATM encontra-se em conformidade com os descritores de tráfego utilizados para regular o tráfego neste escalonador. Este fenômeno ocorre desde a Figura 6.42 até a Figura 6.57. Existe uma considerável diferença entre o atraso médio das células ATM nos escalonadores default e VS, com relação aos escalonadores WF2Q e LFVC. Nitidamente, tanto o escalonador WF2Q, quanto o escalonador LFVC atendem de forma diferenciada as células das conexões ATM. Já os escalonadores Default e VS, atendem todas as conexões com a mesma prioridade, o que resulta em um atraso médio semelhante para as células de todas as conexões. Isto ocorre desde a Figura 6.42 até a Figura 6.57. Também podemos observar que tanto o escalonador WF2Q quanto o escalonador LFVC, são capazes de manter garantias de qualidade de serviço individuais para cada conexão da rede, isolando esta conexão da presença de outras conexões da rede. 214
  • Capacidade de 1000 Células (B=0) Modelo de CAC, BM e SD Default (V=0) Figura 6.42 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(0)(Z). 215
  • Figura 6.43 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(0)(Z). 216
  • Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) Figura 6.44 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(1)(Z). 217
  • Figura 6.45 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(1)(Z). 218
  • Capacidade de 500 Células (B=1) Modelo de CAC, BM e SD Default (V=0) Figura 6.46 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(0)(Z). 219
  • Figura 6.47 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(0)(Z). 220
  • Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) Figura 6.48 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(1)(Z). 221
  • Figura 6.49 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(1)(Z). 222
  • Capacidade de 100 Células (B=2) Modelo de CAC, BM e SD Default (V=0) Figura 6.50 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(0)(Z). 223
  • Figura 6.51 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(0)(Z). 224
  • Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) Figura 6.52 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(1)(Z). 225
  • Figura 6.53 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(1)(Z). 226
  • Capacidade de 50 Células (B=3) Modelo de CAC, BM e SD Default (V=0) Figura 6.54 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(0)(Z). 227
  • Figura 6.55 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(0)(Z). 228
  • Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) Figura 6.56 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(1)(Z). 229
  • Figura 6.57 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(1)(Z). 230
  • 6.4.4.3 - CLR Médio por Conexão Apresentaremos os resultados obtidos na camada física de saída do BTE_0. A seguir faremos alguns comentários relativos as figuras: Figura 6.58 até a Figura 6.73: Quando o modelo de descarte seletivo default é utilizado (V=0), a taxa média de perda de células evidenciada pelas conexões da rede é a mesma para qual quer um dos escalonadores utilizados (Z). Ou seja, neste caso a taxa média de perda de células independe do modelo de escalonador PHY_OUT_S_0 do BTE_0. Como era de esperar, o CLR médio de cada conexão aumenta a medida que o número de aplicativos transmitindo na rede também aumenta. Outro fato interessante, é quando somente cinco aplicativos transmitem dados na rede (U=0) nenhuma célula é perdida independentemente da capacidade da estrutura de filas PHY_OUT_QS_0. Quando o modelo de descarte seletivo baseado no CLR é utilizado (V=1), a taxa média de perda de células evidenciada pelas conexões da rede depende fundamentalmente do CLR configurado para cada conexão (veja a Tabela 6.7), uma vez que este modelo descarta primeiro as células cuja conexão tem maior CLR configurado. Neste caso, o CLR médio evidenciado por uma determinada conexão tanto quando se utilizou o escalonador default quanto quando se utilizou o escalonador VS é o mesmo. Quando o modelo de descarte seletivo baseado no CLR (V=1) e os modelos de escalonadores default, WF2Q e VS são utilizados (Z=0, Z=1 e Z=3), e considerando-se os resultados para quando dez aplicativos transmitem tráfego na rede (U=1), podemos observar que: • Quando a capacidade de armazenamento nesta estrutura de filas é igual a 1000 células (B=0) (veja as figuras: Figura 6.60 e Figura 6.61), somente células das conexões 6, 7, 8 e 9 são perdidas; • Quando a capacidade de armazenamento é igual a 500 células (B=1) (veja as figuras: Figura 6.64 e Figura 6.65), o fenômeno se repete; • Quando a capacidade de armazenamento é igual a 100 células (B=2) (veja as figuras: Figura 6.68 e Figura 6.69), além das conexões 6, 7, 8 e 9 também ocorre a perda de células na conexão 5; 231
  • • Já para a capacidade de 50 células (B=3) (veja as figuras: Figura 6.72 e Figura 6.73), todas as conexões perdem células. 232
  • Capacidade de 1000 Células (B=0) Modelo de CAC, BM e SD Default (V=0) Figura 6.58 – CLR na camada física de saída do BTE_0 para as configurações (U)(0)(0)(Z). 233
  • Figura 6.59 – CLR na camada física de saída do BTE_0 para as configurações (U)(0)(0)(Z). 234
  • Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) Figura 6.60 – CLR na camada física de saída do BTE_0 para as configurações (U)(0)(1)(Z). 235
  • Figura 6.61 – CLR na camada física de saída do BTE_0 para as configurações (U)(0)(1)(Z). 236
  • Capacidade de 500 Células (B=1) Modelo de CAC, BM e SD Default (V=0) Figura 6.62 – CLR na camada física de saída do BTE_0 para as configurações (U)(1)(0)(Z). 237
  • Figura 6.63 – CLR na camada física de saída do BTE_0 para as configurações (U)(1)(0)(Z). 238
  • Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) Figura 6.64 – CLR na camada física de saída do BTE_0 para as configurações (U)(1)(1)(Z). 239
  • Figura 6.65 – CLR na camada física de saída do BTE_0 para as configurações (U)(1)(1)(Z). 240
  • Capacidade de 100 Células (B=2) Modelo de CAC, BM e SD Default (V=0) Figura 6.66 – CLR na camada física de saída do BTE_0 para as configurações (U)(2)(0)(Z). 241
  • Figura 6.67 – CLR na camada física de saída do BTE_0 para as configurações (U)(2)(0)(Z). 242
  • Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) Figura 6.68 – CLR na camada física de saída do BTE_0 para as configurações (U)(2)(1)(Z). 243
  • Figura 6.69 – CLR na camada física de saída do BTE_0 para as configurações (U)(2)(1)(Z). 244
  • Capacidade de 50 Células (B=3) Modelo de CAC, BM e SD Default (V=0) Figura 6.70 – CLR na camada física de saída do BTE_0 para as configurações (U)(3)(0)(Z). 245
  • Figura 6.71 – CLR na camada física de saída do BTE_0 para as configurações (U)(3)(0)(Z). 246
  • Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1) Figura 6.72 – CLR na camada física de saída do BTE_0 para as configurações (U)(3)(1)(Z). 247
  • Figura 6.73 – CLR na camada física de saída do BTE_0 para as configurações (U)(3)(1)(Z). 248
  • 6.5 - Referências Bibliográficas [1] KOENEN, R., “MPEG-4: Multimedia for Our Time”, IEEE Spectrum, volume 36, número 2, Fevereiro 1999. [2] FITZEK, F. H. P., REISSLEIN, M., “MPEG-4 and H.263 Video Traces for Network Performance Evaluation”, Tutorial Técnico, http://www-tkn.ee.tu- berlin.de/research/trace/trace.html/, Outubro 2000. [3] ORZESSEK, M., SOMMER, P., “ATM & MPEG-2: Integrating Digital Video in Broadband Networks”, Prentice Hall, 1998. [4] BENNETT, J., ZHANG, H., “WF2Q: Worst-case Fair Weighted Fair Queueing”, IEEE Infocom 1996. 249
  • Página deixada em branco intencionalmente. 250
  • Apêndice A Descrição Detalhada do Ambiente de Simulação Neste apêndice descreveremos em maiores detalhes o ambiente de simulação Hydragyrum, previamente apresentado no Capítulo 3. A.1 - Programa Executável A.1.1 - Kernel O kernel do Hydragyrum é responsável pelo gerenciamento do processo de simulação, pela carga e descarga de modelos e pelo suporte à iteração com o usuário. A.1.1.1 - Estrutura A Figura 1 mostra a estrutura do kernel do Hydragyrum, cujos componentes podem ser divididos em três grupos: Modelos – São instâncias de objetos (classes) utilizadas para compor a rede a ser simulada. Conexões – São instâncias de objetos (classes) utilizadas para conectar os modelos da rede a ser simulada. Módulos Funcionais – Agrupam logicamente as funções desempenhadas pelo kernel com relação a algum aspecto específico. Por exemplo, o módulo funcional gerenciador de parâmetros reúne todas as funções do kernel relacionadas com o armazenamento, carga e manipulação de parâmetros. Os módulos funcionais podem ser implementados como objetos instanciados pelo kernel (classes) ou como funções do kernel (métodos públicos ou privados da classe kernel). 263
  • Kernel Gerenciador de Gerenciador de Gerenciador de Gerenciador de Arquivos Mensagens Conexões Parâmetros Conexões de Blocos Auxiliar Relógio Conexão 1 Rede Roda Executor de Eventos Eventos Conexão N Modelo 1 Descobre Modelo 2 Destino Conexões de Rede Gerenciador de Modelo 3 Eventos Conexão 1 Armazena Fila com Prioridades Eventos Modelo N Evento Evento Evento Evento Evento Conexão N Cria e Deleta Modelos Ex ec Conexões de Dados ut a Ativa Co m an Conexão 1 do s Gerenciador de Interpretador de Ativa Conexão N Modelos Comandos Carrega DLL´s Objetos Biblioteca de Usuários Modelos Figura 1 – Estrutura do kernel do Hydragyrum. A.1.1.2 - Técnica de Simulação O kernel do Hydragyrum foi desenvolvido utilizando-se a técnica de simulação event-driven. Como vimos no capítulo anterior, nesta técnica os modelos agendam eventos, que são armazenados em uma fila com prioridades. No hydragyrum, esta fila com prioridades foi implementada no módulo gerenciador de eventos (Figura 1). Na seqüência, o módulo executor de eventos retira o evento de maior prioridade (menor tempo de execução) que se encontra na fila do módulo gerenciador de eventos e repassa este evento para o modelo de destino. Toda vez que um evento é retirado da fila, o tempo global de simulação é avançado para o tempo deste evento. Tipicamente, apenas alguns modelos processam eventos a cada avanço no tempo de simulação. Quando um modelo processa um evento, ele executa funções específicas relacionadas com este evento. Ao término da execução dessas funções, o fluxo da simulação é retornado ao módulo executor de eventos, que retira e interpreta outro evento da 264
  • fila. A simulação prossegue até que não hajam mais eventos a serem executados, ou até que o tempo final de simulação seja alcançado. A.1.1.3 - Módulos Funcionais O kernel do Hydragyrum possui os seguintes módulos funcionais: Interpretador de Comandos – É responsável pela execução de comandos junto a rede a ser simulada, pelo acionamento do gerenciador de eventos e do construtor de modelos, e pela troca de comandos com o programa executável. O interpretador de comandos do kernel define uma linguagem de comandos (SCL – Simulator Command Language) que possibilita a iteração direta do usuário com o simulador. Esta linguagem possibilita também a execução de arquivos script, que permitem ao usuário executar várias simulações em laço. A linguagem de comandos do kernel conta com aproximadamente 100 comandos, que possibilitam manipular totalmente a rede presente no ambiente de simulação. Maiores detalhes desta linguagem podem ser obtidos no manual do simulador [1]. Gerenciador de Eventos – É responsável pelo armazenamento dos eventos na fila com prioridades, que ordena os eventos conforme o tempo de chegada. Executor de Eventos – Encaminha os eventos para os modelos de destino. Gerenciador de Modelos – Realiza a carga e a descarga dos modelos (.dll) da biblioteca do simulador para a memória. O gerenciador de modelos possui ainda um grande número de funções que permitem manipular os modelos presentes no ambiente de simulação. Auxiliar – Possui funções para a manipulação de arquivos de configuração de rede (.scl) e arquivos script. Os arquivos de configuração de rede (.scl) possuem uma série de comandos que permitem construir e configurar uma rede a ser simulada. Estes arquivos são gerados automaticamente pelo programa executável quando o usuário salva uma rede presente no ambiente de simulação. Os arquivos .scl também podem ser construídos e/ou editados manualmente pelo usuário. O módulo auxiliar possui ainda funções para carregar temporariamente arquivos de modelos (.dll). Temporizador – Possui um relógio para marcar o tempo gasto nas simulações. 265
  • Gerenciador de Parâmetros – É responsável pelo armazenamento e manipulação de parâmetros globais de simulação, que podem ser acessados por qualquer modelo instanciado no kernel. Gerenciador de Arquivos – É responsável pelo armazenamento dos diretórios de arquivos de rede (.scl), modelos (.dll) e de resultados (.dat), e pela manipulação de destes arquivos. Gerenciador de Mensagens de Erro e de Advertência – O kernel possui uma estrutura hierárquica para o armazenamento e amostragem de mensagens de erro e de advertência geradas pelo próprio kernel e pelos modelos. Este módulo é responsável pela execução destas funções. Gerenciador de Conexões – É responsável pela manipulação de conexões de blocos, conexões de rede e conexões de dados. A.1.1.4 - Funcionamento A.1.1.4.1 - Modos de Funcionamento O funcionamento do kernel do Hydragyrum pode ser melhor compreendido se analisarmos os fluxogramas da Figura 2. Interpretação de Inicio Inicio Comandos Criação Criação Lê Comando Configuração Configuração Executa Comando Interpretação de Leitura de Arquivos Retorna Comandos Script Interpretação de Fim Comandos Fim a) Funcionamento via linha b) Funcionamento via c) Interpretação de de comandos arquivo script comandos Figura 2 – Fluxogramas de funcionamento do kernel. 266
  • O kernel do simulador possui dois modos de funcionamento: o primeiro via linha de comandos e o segundo via arquivos script, que são arquivos que possuem uma série de comandos a serem interpretados em seqüência. Tanto no modo via linha de comandos quanto no modo via arquivos script primeiramente são executadas funções de criação e de configuração (Configure) do kernel. Na função de criação são alocados dinamicamente [2] os seguintes módulos do kernel: interpretador de comandos, gerenciador de eventos, executor de eventos, gerenciador de modelos, gerenciador de parâmetros e auxiliar. Na função de configuração são configurados os diretórios dos modelos (.dll) e do programa executável (.exe). Posteriormente, no primeiro modo de funcionamento é executada uma função de interpretação de comandos (CmdLine). Esta função também é executada no segundo modo de funcionamento, porém antes é executada uma função de leitura de arquivos script (LoadScript), que carrega um arquivo script com comandos a serem executados. Na função de interpretação de comandos, os comandos digitados na linha de comandos ou presentes no arquivo script são interpretados e executados. Esta função permanece ativa até que seja encontrado um comando “quit” ou “exit”. Note que quando se utiliza a linha de comandos não é necessário digitar todos os comandos para criar e configurar uma rede, basta utilizar o comando “load” para carregar um arquivo de configuração de rede (.scl), que já contém os comandos necessários para criar e configurar uma rede a ser simulada. A.1.1.4.2 - Funções de Interfaceamento com os Modelos A partir da execução da função de interpretação de comandos, várias outras funções podem ser acionadas pelo usuário. Chamaremos estas funções de funções de interfaceamento com os modelos. São elas: Função de Criação de Modelo (Setup) Função de Estabelecimento de Conexão de Blocos (OnConnect) Função de Remoção de Conexão de Blocos (OnDisconnect) Função de Estabelecimento de Conexão de Rede (OnNetConnect) Função de Remoção de Conexão de Rede (OnNetDisconnect) Função de Estabelecimento de Conexão de Dados (OnDataConnect) Função de Remoção de Conexão de dados (OnDataDisconnect) 267
  • Função de Inicialização (Initiate) Função de Tratamento de Erros de Inicialização (OnInitiateError) Função de Execução da Simulação (Run) Função de Tratamento de Parada de Simulação (OnStop) Função de Pós-Processamento (OnPosprocessing) Função de Finalização (Terminate) Função de Reset (Reset) Como veremos mais adiante, com exceção da função de reset, todas as outras funções de interfaceamento (Figura 3 (a)) estão presentes nos modelos do simulador. Porém, neste caso estas funções são chamadas de funções de comportamento dos modelos (Figura 3 (b)). Em outras palavras, as funções de comportamento dos modelos (Figura 3 (b)) são acionadas a partir da execução das funções de interfaceamento do kernel (Figura 3 (a)). A seguir veremos cada uma destas funções mais detalhadamente. Programa Executável Biblioteca de (.exe) Modelos Kernel Modelo Funções de Funções de Interfaceamento Comportamento (a) (b) Figura 3 – Relação entre as funções de interfaceamento do kernel e as funções de comportamento dos modelos. Função de Criação de Modelo Nesta função é feita a carga de um modelo (.dll) para a memória. Quando executada esta função aciona também a função de criação (Setup) do modelo que está sendo carregado e também de seus modelos internos. Como veremos na seção A.2 - o kernel do simulador possui uma estrutura hierárquica de construção de modelos, onde um modelo pode possui um ou mais modelos internos. Funções de Estabelecimento de Conexão, Conexão de Rede e Conexão de Dados 268
  • Nestas funções é feito o estabelecimento de conexões entre os modelos presentes no ambiente de simulação. Quando executadas estas funções acionam também as funções equivalentes nos modelos envolvidos e nos seus modelos internos. Funções de Remoção de Conexão, Conexão de Rede e Conexão de Dados Nestas funções é feita a remoção de conexões entre os modelos presentes no ambiente de simulação. Assim como as funções de estabelecimento de conexões, estas funções quando executadas acionam também as funções equivalentes nos modelos envolvidos e nos seus modelos internos. Função de Inicialização (Initiate) Nesta função é feita a configuração do destino das mensagens de erro e de advertência do kernel e dos modelos. Também é feito o armazenamento no kernel do nome associado às conexões e aos modelos criados antes da função de inicialização. Finalmente, é feita e a configuração dos modelos para a geração de eventos. A função de inicialização também executa a função de inicialização (Initiate) de todos os modelos presentes no ambiente de simulação. Função de Tratamento de Erros de Inicialização (OnInitiateError) Quando a função de inicialização dos modelos é executada, uma indicação de que ocorreram erros de inicialização pode ser retornada para o kernel. Neste caso, a função de inicialização do kernel acionará a função de tratamento de erros de inicialização (OnInitiateError). Esta função executa a função de tratamento de parada de simulação (OnStop) em todos os modelos presentes no simulador, repassando que ocorreu um erro na função de inicialização do kernel, no instante de tempo zero e com um código de erro dado pelo modelo que interrompeu a seqüência de funcionamento do kernel. Função de Execução da Simulação (Run) Esta função implementa a técnica de simulação orientada por eventos (event-driven) e é responsável pela execução da simulação de uma rede presente no ambiente de simulação. O fluxograma da Figura 4 descreve esta função do kernel. 269
  • Inicio Fila com prioridades está Sim Fim vazia? Não Estado de execução é Não Aciona fase de Reset diferente de 3? Sim Fila com prioridades não está vazia, o tempo de simulação é menor que o tempo final de Não simulação e o estado de execução é igual a 1? Código Executa fase OnStop de erro e estado de Executa fase Sim identificando parada de Executa fase de Reset Sim execução Posprocessing simulação. são = 0? Retira evento da fila com prioridades Código Atualiza tempo de de erro = 0 e Seta estado de Executa fase simulação para o Não Sim estado de exec. execução = 0 Posprocessing tempo de execução do = 1? evento Sim Envia evento para o modelo de destino e Código Executa fase OnStop configura código de Não de erro é diferente Sim identificando erro na erro, se necessário. de 0 ? execução. Executa fase Não Código Posprocessing de erro é diferente de 0? Estado de Executa fase de Reset Não execução = 3? Retorna Sim Não Aciona fase de Reset Finalização da Simulação e Execução de Eventos Tratamento de Erros Fim Figura 4 – Fluxograma da função de execução da simulação (run). Quando a função de execução da simulação é acionada, o módulo gerenciador de eventos verifica se a sua fila com prioridades está vazia. Se esta fila estiver vazia, a função de execução é terminada, pois não existem eventos a serem processados. Caso contrário, é verificado se o estado de execução da simulação é diferente de 3. A simulação é colocada neste estado se houver um erro na função de inicialização executada anteriormente ao run. Se o estado de execução for igual a 3 é acionada a função de reset. Caso contrário, o gerenciador de eventos entra em um laço para a execução 270
  • de eventos, permanecendo neste laço enquanto a fila com prioridades não esteja vazia e o tempo de simulação seja menor que o tempo final de simulação e o estado de execução seja igual a 1. Neste laço, o gerenciador de eventos retira o evento com maior prioridade da fila, atualiza o tempo de simulação para o tempo de execução deste evento e envia o evento para o módulo executor de eventos. O executor de eventos irá repassar este evento para o modelo de destino. Se houver um erro na execução do evento, o código deste erro será repassado pelo módulo executor de eventos. A execução de eventos prossegue se o executor de eventos retornar um código igual a 0, o que indica que não houve erro na execução do evento. Se ocorrer um erro o gerenciador de eventos inicia o tratamento deste erro. Uma primeira possibilidade é que o código de erro seja igual a 0 e o estado da execução da simulação também seja igual a 0. Neste caso, trata-se do término de uma simulação sem erros. São acionadas em seqüência então as funções de: tratamento de parada de simulação (OnStop), indicando parada de simulação, pós-processamento (Posprocessing) e reset. Uma segunda possibilidade é que o código de erro seja igual a 0 e o estado da execução da simulação seja igual a 1. Neste caso, trata-se da parada de uma simulação em andamento. É configurado então o estado da execução para 0 e acionada a função de pós-processamento (Posprocessing). Uma terceira possibilidade é que o código de erro seja diferente de 0. Neste caso, trata-se do término de uma simulação em que ocorreram erros. São acionadas em seqüência então as funções de: tratamento de parada de simulação (OnStop), indicando erro na execução da simulação, pós-processamento (Posprocessing) e reset. Finalmente, uma quarta possibilidade é que o estado de execução seja igual a 3. Neste caso, trata-se de um erro na função de inicialização. É acionada então a função de reset. Função de Tratamento de Parada de Simulação (OnStop) Esta função executa a função de tratamento de parada de simulação (OnStop) em todos os modelos presentes no simulador, repassando que ocorreu um erro na função de execução da simulação do kernel, o instante de tempo da parada e o código de erro dado pelo modelo que gerou a parada da simulação. Função de Pós-Processamento (OnPosprocessing) Esta função executa a função de pós-processamento em todos os modelos presentes no ambiente de simulação. Função de Finalização (Terminate) 271
  • Esta função executa a função de finalização em todos os modelos presentes no ambiente de simulação. Logo após, remove todos os modelos, conexões e os seguintes módulos do kernel: interpretador de comandos, gerenciador de eventos, executor de eventos, gerenciador de modelos, gerenciador de parâmetros e auxiliar. Função de Reset (Reset) Esta função remove todos os eventos presentes na fila de prioridades do módulo gerenciador de eventos e prepara o simulador para uma nova simulação. A.1.1.5 - Fases Necessárias para uma Simulação A partir das funções apresentadas nas seções anteriores, é possível definir várias fases (Figura 5) necessárias para a simulação de uma rede no Hydragyrum. São elas: Fase de Criação dos Modelos – Nesta fase o usuário deve escolher os modelos que serão utilizados para montar a rede a ser simulada. Fase de Estabelecimento de Conexões – Nesta fase o usuário deve montar a topologia da rede a ser simulada, conectando os modelos presentes no ambiente de simulação. Fase de Execução de Simulação – Nesta fase o usuário inicia o processo de simulação propriamente dito, ou seja, a troca de eventos entre os modelos. Fase de Finalização – Nesta fase o usuário encerra a simulação da rede e deixa o ambiente de simulação. 272
  • Primeira Fase Criação Criação de Modelo Criação dos Modelos Estabelecimento de Desestabelecimento Configuração Conexão de Blocos de Conexão de Blocos Segunda Fase Estabelecimento de Desestabelecimento Estabelecimento Conexão de Rede de Conexão de Rede Leitura de Arquivo de Conexões Script Estabelecimento de Desestabelecimento Conexão de Dados de Conexão de Dados Interpretação de Comandos Tratamento de Erros de Inicialização Incialização Terceira Fase Execução da Tratamento de Parada Execução da Simulação de Simulação Simulação Pós-Procesamento Quarta Fase Finalização Finalização Figura 5 – Fases necessárias para a simulação de uma rede no Hydragyrum. A.1.1.6 - Implementação O kernel do Hydragyrum é implementado na classe kernel. A Figura 6 mostra baseado em um modelo orientado à objetos a estrutura de classes do kernel do simulador. A classe kernel foi construída para prover um conjunto básico de funções aos modelos do simulador. A implementação do kernel é desacoplada da implementação dos modelos, de forma que os modelos podem usar ou estender a funcionalidade do kernel. A estrutura desacoplada do kernel é fundamental para permitir que novos modelos sejam acrescentados à biblioteca do simulador. 273
  • layer auxiliar Param block command squeue kernel Classes Base para library Construção de Modelos stimer connection Classes para Representaçã Classes Internas netconnection o das do Kernel Conexões da Simulação dataconnection eventmng dispatcher Classes Controladas Pelo Kernel Classes Para Controle dos Eventos Classes que Desempenham as Funções do Kernel Figura 6 – Estrutura de classes do kernel do Hydragyrum [3]. A estrutura de classes do kernel é dividida em 4 grupos [3]: Classes internas do kernel. Classes para controle de eventos. Classes base para a construção de modelos. Classes para a representação das conexões entre os modelos. O grupo de classes internas do kernel é composto pelas classes: auxiliar, command, library e stimer. Estas classes implementam respectivamente os módulos: auxiliar, interpretador de comandos, gerente de modelos e temporizador da Figura 1. O grupo de classes para controle de eventos do kernel é composto pelas classes: evenSqueueng e dispatcher. Estas classes implementam respectivamente o gerenciador de eventos e o executor de eventos da Figura 1. 274
  • O grupo de classes base para a construção de modelos do kernel é composto pelas classes: Block, Layer e Squeue. Na seção A.2 - apresentaremos estas classes. O grupo de classes para a representação das conexões entre modelos é composto pelas classes: Connection, NetConnection e DataConnection. Na seção A.1.2 - apresentaremos estas classes. A classe Param é um contaneir para parâmetros globais de simulação, que podem ser acessados e manipulados por qualquer outro modelo instanciado no ambiente de simulação. Esta classe implementa, junto com as funções do kernel relacionadas com a manipulação de parâmetros globais, o gerenciador de parâmetros da Figura 1. A.1.2 - Conexões Conexões são objetos utilizados para representar o relacionamento topológico entre os modelos presentes no ambiente de simulação. O Hydragyrum possui uma estrutura hierárquica de conexões (Figura 7). O primeiro nível desta estrutura é formado pelas conexões de blocos (Connections), que são utilizadas para conectar somente dois modelos (.dll) entre si. O segundo nível é formado pelas conexões de rede (NetConnections), que são utilizadas para estabelecer um caminho entre dois modelos (.dll). Este caminho é definido como um grupo de conexões de blocos, ou seja conexões do primeiro nível hierárquico. Finalmente, o terceiro nível hierárquico é formado pelas conexões de dados (DataConnections), que também são utilizadas para estabelecer um caminho entre dois modelos (.dll). Porém, neste caso, este caminho é definido como um grupo de conexões de rede, ou seja, conexões do segundo nível da hierarquia. Um aspecto importante das conexões no Hydragyrum é a direcionalidade. As conexões de rede e as conexões de dados são unidirecionais, enquanto as conexões de blocos são bidirecionais. Portanto, para estabelecer uma conexão de dados, é necessário que exista uma conexão de rede na mesma direção. A Figura 7 mostra também as classes em que são implementadas as conexões do simulador. São elas: Connection, NetConnection e DataConnection. Estas classes implementam respectivamente, as conexões de blocos, conexões de rede e conexões de dados. 275
  • Conexão de Dados 1 connection Conexão de Rede 1 Conexão de Rede 2 Conexão Blocos 2 Conexão Blocos 2 netconnection Conexão Blocos 3 Conexão Blocos 3 dataconnection CD1 CR2 CR1 Modelo 1 Modelo 2 Modelo 3 Modelo 4 Modelo 5 CB1 CB2 CB3 CB4 (.dll) (.dll) (.dll) (.dll) (.dll) Figura 7 – Estrutura hierárquica de conexões do Hydragyrum. Outro aspecto importante das conexões no Hydragyrum diz respeito a deleção. A Figura 8 mostra a ordem de deleção de conexões no kernel do simulador. Se uma conexão de blocos for removida do kernel, tanto as conexões de rede como as conexões de dados montadas a partir desta conexão devem ser removidas também. Se uma conexão de rede for removida, as conexões de dados montadas a partir desta conexão também devem ser removidas. Portanto, se uma conexão que é utilizada para montar outras conexões de nível superior na hierarquia for removida, estas conexões também serão removidas pelo kernel. CD1 CR2 CR1 Modelo 1 Modelo 2 Modelo 3 Modelo 4 Modelo 5 CB1 CB2 CB3 CB4 (.dll) (.dll) (.dll) (.dll) (.dll) Figura 8 – Remoção de conexões no Hydragyrum. 276
  • A estrutura hierárquica de conexões do Hydragyrum permite construir qualquer topologia de rede que possa ser mapeada para os três níveis de conexões do kernel. As conexões de dados podem ser utilizadas para conectar dois modelos de aplicativos em uma rede, enquanto as conexões de rede podem ser utilizadas para conectar vários modelos de equipamentos e para encaminhar tráfego através da rede. Assim sendo, a estrutura hierárquica de conexões do Hydragyrum é ideal para a simulação de redes orientadas à conexão [4][5][6], como é o caso das redes ATM, pois neste tipo de rede os dados de usuários somente serão transmitidos se já houver uma conexão de rede previamente estabelecida. A Figura 9 ilustra tal situação. Conexão de Dados Multímidia Conexão ATM 1 Conexão ATM 2 Modelo de Modelo de Modelo de Modelo de Modelo de Aplicativo CB1 Terminal CB2 Chaveador CB3 Terminal CB4 Aplicativo (.dll) (.dll) (.dll) (.dll) (.dll) Fibra Óptica Software Figura 9 – Exemplo de topologia para redes ATM. Como vimos na seção A.1.1.4 - , o kernel do Hydragyrum aciona funções nos modelos toda vez que uma conexão é criada. É possível, portanto construir modelos que executem funções ou armazenem informações quando uma conexão é estabelecida entre dois modelos. Este recurso é bastante útil para verificar a compatibilidade entre modelos, alocar recursos em modelos e construir tabelas de comutação. A.1.3 - Parâmetros Parâmetros são variáveis utilizadas para configurar ou modificar o comportamento dos modelos durante a execução das funções de funcionamento do modelo. Os parâmetros do Hydragyrum permitem o armazenamento de valores escalares, vetoriais e matriciais. A Figura 10 mostra a estrutura dos parâmetros do simulador, que possuem os seguintes campos de informação: Name (Nome) – Nome do parâmetro. Type (Tipo) – Identifica o tipo de dado do valor armazenado. 277
  • Rows (Linhas) – Utilizado para descrever o número de linhas de um parâmetro. Parâmetros escalares possuem somente uma linha e uma coluna. Columns (Colunas) – Utilizado para descrever o número de colunas do parâmetro. Value (Valor) – Valor do parâmetro. Atualmente o simulador suporta os seguintes tipos de dados: long, double, int, Sstring e unsigned int. Description (Descrição) – Utilizado para descrever o parâmetro. Option (Opção) – Utilizado para mostrar ou não um parâmetro na interface gráfica. Time Type Rows Columns Value Description Option Figura 10 - Estrutura dos parâmetros do Hydragyrum. O objeto parâmetro do Hydragyrum descende diretamente do objeto parâmetro do SimNT [7][8]. Este objeto é implementado na classe Param. A.1.4 - Tabela de Dados A tabela de dados é uma estrutura de dados flexível desenvolvida com o objetivo de armazenar informações gerais temporárias em cada modelo antes e durante as simulações. As informações armazenadas são acessadas a partir de dois índices, chamados de chaves. A primeira chave armazena várias segundas-chaves, que por sua vez dão acesso as informações. Estas informações podem ser dos mesmos tipos de dados que os valores dos parâmetros, ou seja: long, double, int, Sstring e unsigned int [2]. O objeto tabela de dados do Hydragyrum é implementada na classe Table, que descende diretamente do objeto tabela de dados do SimATM [9][10]. A.1.5 - Eventos Eventos são requisições geradas pelos modelos para executar funções específicas em um determinado instante de tempo. A Figura 11 mostra a estrutura dos eventos do simulador Hydragyrum, que possuem os seguintes campos de informação: Time (Tempo) – Define o tempo para a execução do evento (em segundos). 278
  • Token (Ficha) – Este campo é utilizado para evitar o embaralhamento de eventos agendados para um mesmo instante de tempo. Type (Tipo) – Define a função que será executada no modelo de destino. Source Block (Bloco Fonte) – Identifica o bloco1 onde o evento foi gerado. Destination Block (Bloco Destino) – Identifica o bloco de destino do evento. Source Layer or Squeue (Camada ou Gerenciador de Tráfego Fonte) – Identifica a camada ou gerenciador de fila onde o evento foi gerado. Destination Layer or Squeue (Camada ou Gerenciador de Tráfego de Destino) – Identifica a camada ou gerenciador de tráfego ao qual o evento se destina. Message (Mensagem) – Identifica a mensagem carregada pelo evento. Network Connection (Conexão de Rede) – Identifica a conexão de rede associada com o evento, se houver. Data Connection (Conexão de Dados) – Identifica a conexão de dados associada com o evento, se houver. Source Destination Source Destination Network Data Time Token Type Layer Layer or Message Block Block Connection Connection or Squeue Squeue Figura 11 – Estrutura dos eventos do Hydragyrum. Os eventos do Hydragyrum são implementados na classe Event. A.1.6 - Mensagens Mensagens são estruturas de dados transportadas por eventos. Todos os dados trocados entre os modelos através de eventos devem ser definidos como mensagens. As mensagens são implementadas como classes derivadas da classe base Smessage. 1 Na seção a seguir veremos o que são blocos, camadas e gerenciadores de tráfego. 279
  • A.2 - Biblioteca de Modelos A.2.1 - Blocos Chamamos de blocos os modelos derivados da classe base Block. Em nossa discussão, um bloco pode ser visto como uma estrutura genérica que oferece todos os subsídios necessários para que as peculiaridades dos modelos de equipamentos, aplicativos e gerentes da rede sejam implementadas. A.2.1.1 - Estrutura A Figura 12 mostra a estrutura de um bloco do Hydragyrum, que possui várias camadas, gerenciadores de tráfego, conexões de blocos, conexões de rede, conexões de dados e vários módulos funcionais. Bloco Gerenciador de Gerenciador de Gerenciador de Simulação Modelos Conexões Gerenciador de Gerenciador de Gerenciador de Mensagens de Erro e Gerenciador Gráfico Identificação Ligação Dinâmica de Advertência Gerenciador de Gerenciador de Gerenciador de Gerenciador de Parâmetros Tabela de Dados Compatibilidade Arquivos de Saída Camadas Gerenciadores de Tráfego Camada 1 Gerenciador 1 Camada n Gerenciador n Conexões de Blocos Conexões de Rede Conexões de Dados Conexão 1 Conexão 1 Conexão 1 Conexão n Conexão n Conexão n Figura 12 – Estrutura de um bloco do Hydragyrum. A.2.1.2 - Módulos Funcionais 280
  • Um bloco do Hydragyrum possui os seguintes módulos funcionais: Gerenciador de Simulação – É o módulo mais importante de um bloco. Possui funções para a troca de dados com o kernel, funções para gerar eventos e funções para definir o comportamento do bloco (veja a seção A.2.1.3 - ). Gerenciador de Modelos – Ao contrário do módulo gerenciador de modelos do kernel, este módulo não realiza a carga e a descarga de dlls. Possui apenas várias funções que permitem manipular as camadas e gerenciadores de tráfego associados com o bloco. Gerenciador de Conexões – É responsável pela manipulação de conexões de blocos, conexões de rede e conexões de dados. Gerenciador de Arquivos de Saída – É responsável pela manipulação de arquivos de resultados (.dat). Possui funções para criar, configurar e limpar estes arquivos. Possui ainda uma função para estabelecer o número máximo de arquivos permitidos em um bloco. Gerenciador de Ligação Dinâmica – Possui apenas uma função que aloca dinamicamente uma instância do modelo e repassa um ponteiro [2] deste modelo para o kernel. Gerenciador de Mensagens de Erro e de Advertência – É responsável pelo armazenamento e envio para o kernel de mensagens de erro e de advertência geradas pelo modelo. Gerenciador de Parâmetros – É responsável pelo armazenamento dos parâmetros do bloco. Permite a manipulação dos parâmetros do bloco, de suas camadas e gerenciadores de tráfego. Gerenciador Gráfico – É responsável pelo armazenamento e troca de informações gráficas que são usadas pelo programa executável com interface gráfica. Gerenciador de Compatibilidade – Possui funções para a manipulação de interfaces. Interfaces são identificadores (Sstrings) usados para definir a compatibilidade entre dois modelos que estão sendo conectados através de conexões de blocos. Gerenciador de Tabelas de Dados – É responsável pelo armazenamento dos dados de tabela do bloco. Permite a manipulação dos dados de tabela do bloco, de suas camadas e gerenciadores de tráfego. 281
  • Gerenciador de Identificação – É responsável pelo armazenamento e troca de informações de identificação do bloco com o kernel. A.2.1.3 - Funcionamento O funcionamento do bloco é baseado em várias funções que definem o seu comportamento. Estas funções são chamadas de funções de comportamento do bloco. São elas: Função de Criação (Setup) Função de Estabelecimento de Conexão de Blocos (OnConnect) Função de Remoção de Conexão de Blocos (OnDisconnect) Função de Estabelecimento de Conexão de Rede (OnNetConnect) Função de Remoção de Conexão de Rede (OnNetDisconnect) Função de Estabelecimento de Conexão de Dados (OnDataConnect) Função de Remoção de Conexão de Dados (OnDataDisconnect) Função de Troca de Parâmetros (OnChangeParameter) Função de Inicialização (Initiate) Função de Execução da Simulação (Run) Função de Tratamento de Parada de Simulação (OnStop) Função de Pós-Processamento (PosProcessing) Função de Finalização (Terminate) Com exceção da função de criação, todas as outras funções de comportamento podem ser implementadas em “branco”, ou seja, sem nenhum código C++. A.2.1.3.1 - Função de Criação (Setup) Esta função é executada quando o kernel executa a função de criação de modelo, ou seja, quando um bloco é carregado para a memória. Nesta função o desenvolvedor de modelos deve implementar a: 282
  • Configuração dos dados de identificação do bloco, ou seja: nome, autor, versão, data, copyright e descrição. Configuração dos valores default dos parâmetros. Configuração dos valores default de dados privados. Gravação dos parâmetros default do bloco. Criação de camadas e gerenciadores de tráfego. Configuração do nome e do tipo das novas camadas e gerenciadores de tráfego. Configuração das novas camadas e gerenciadores de tráfego junto ao kernel. Configuração das associações entre as novas camadas e gerenciadores de tráfego. Definição de uma interface para a conexão com outros blocos. Definição da aparência do bloco caso ele seja carregado pelo programa executável com interface gráfica. A.2.1.3.2 - Funções de Estabelecimento de Conexão de Blocos, Conexão de Rede e Conexão de Dados (OnConnect, OnNetConnect e OnDataConnect) Estas funções são executadas quando o kernel executa as funções de estabelecimento de conexão, conexão de rede e conexão de dados, respectivamente. O objetivo destas funções é permitir ao bloco modificar registros em tabelas e executar outras funções sempre que uma nova conexão seja estabelecida. Nesta função o desenvolvedor de modelos deve implementar a: Verificação de compatibilidade com os modelos a que o bloco está se conectando. Criação de camadas e gerenciadores de tráfego. Configuração do nome e do tipo das novas camadas e gerenciadores de tráfego. Configuração das novas camadas e gerenciadores de tráfego junto ao kernel. Configuração das associações entre as novas camadas e gerenciadores de tráfego. Inserção de informações nas tabelas de dados do bloco, camadas e gerenciadores de tráfego. 283
  • É importante observar aqui, que as funções de estabelecimento de conexões são executadas somente após o estabelecimento de uma conexão já ter sido finalizado no kernel. A.2.1.3.3 - Funções de Remoção de Conexão de Bloco, Conexão de Rede e Conexão de Dados (OnDisconnect, OnNetDisconnect e OnDataDisconnect) Estas funções são executadas quando o kernel executa as funções de remoção de conexão de blocos, conexão de rede e conexão de dados, respectivamente. O objetivo destas funções é permitir ao bloco modificar registros em tabelas e executar outras funções sempre que uma conexão for removida. Tipicamente, estas funções retornam o modelo ao estado anterior a criação da conexão que esta sendo removida. É importante observar aqui, que as funções de remoção de conexões, assim como as funções de estabelecimento de conexões, são executadas somente após a remoção de uma conexão já ter sido finalizado no kernel. A.2.1.3.4 - Função de Troca de Parâmetros (OnChangeParameter) Esta função é executada toda vez que um parâmetro é modificado em algum modelo ou no kernel do simulador. O objetivo desta função é permitir ao desenvolvedor de modelos executar verificações de faixas de valores e de consistência em parâmetros ou até mesmo alterar as camadas e gerenciadores de tráfego presentes em um bloco. A.2.1.3.5 - Função de Inicialização (Initiate) A função de inicialização do bloco é executada quando o kernel executa a função de inicialização, ou seja, antes que a rede seja simulada. Nesta função o desenvolvedor de modelos deve implementar a leitura dos valores dos parâmetros do bloco e dos parâmetros globais. A.2.1.3.6 - Função de Execução da Simulação (Run) A função de execução da simulação do bloco é executada quando o kernel executa a função de execução e existe um evento destinado para o bloco, ou quando algum modelo executa diretamente esta função, sem passar pelo kernel da ferramenta. A.2.1.3.7 - Função de Tratamento de Parada de Simulação (OnStop) A função de tratamento de parada de simulação do bloco é executada quando o kernel executa a função de tratamento de parada de simulação, ou seja, quando ocorre um erro durante as funções de 284
  • inicialização ou de execução do kernel ou quando o usuário interrompe a simulação de uma rede. Esta função permite ao bloco responder a estes acontecimentos, e a outros que possam ser incorporados pelo desenvolver dos modelos. A.2.1.3.8 - Função de Pós-Processamento (PosProcessing) A função de pós-processamento do bloco é executada quando o kernel executa a função de pós- processamento, ou seja, quando a execução de uma simulação é finalizada. Esta função pode ser usada para executar qualquer processamento adicional em um bloco após o final de uma simulação. A.2.1.3.9 - Função de Finalização (Terminate) A função de finalização do bloco é executada quando o kernel executa a função de finalização, ou seja, quando o simulador está sendo “fechado”. Esta função pode ser usada para executar a limpeza da memória alocada pelo modelo durante a execução de outras funções. A.2.1.3.10 - Implementação Os blocos são implementados como bibliotecas de ligação dinâmica do WindowsTM e construídos a partir da herança da classe base Block. Portanto, herdam toda a funcionalidade provida por esta classe base. A Figura 13 ilustra, baseado em um modelo orientado à objetos, a construção de novos blocos no simulador. Classe block Base Classe Base Novo new_model Classe Bloco Derivada Figura 13 – Construção de novos blocos no Hydragyrum. Para acrescentar novos blocos ao ambiente de simulação Hydragyrum o usuário pode seguir os seguintes passos (veja a Figura 13): Primeiro Passo – Criar um novo projeto em um compilador C++ (BorlandTM C++ 5.02). 285
  • Segundo Passo – Construir novos objetos derivados das classes base Block, Layer e Squeue. Terceiro Passo – Implementar as funções de comportamento nestes objetos. Quarto Passo – Compilar os novos objetos. Quinto Passo – Ligar dinamicamente os novos modelos com a DLL do kernel. Sexto Passo – Testar na interface em linha de comando. Sétimo Passo – Testar na interface gráfica. new_model.h Declaração das Segundo Passo: Funções de Construir Novos Objetos Comportamento project.ide Terceiro Passo: new_model.cpp Implementar Funções de Implementação Comportamento das Funções de Comportamento Primeiro Compilar Passo: Criar um Novo Projeto. Quarto Passo: Compilar Novos Objetos new_model.obj Ligar Quinto Passo: Ligar Novos Objetos kernel.dll new_model.dll r Te sta s ta Te r Sexto Passo: Testar na Interface em Linha de Comando Sétimo Passo: Testar na Interface Gráfica Figura 14 – Passos necessários para desenvolver um novo bloco para o Hydragyrum. 286
  • A.2.2 - Camadas Chamamos de camadas os modelos derivados da classe base Layer. Em nossa discussão, uma camada pode ser vista como uma estrutura genérica que oferece todos os subsídios necessários para que as peculiaridades dos modelos de camadas da rede sejam implementadas. A.2.2.1 - Estrutura A Figura 15 mostra a estrutura de uma camada do Hydragyrum. Esta estrutura possui várias conexões de blocos, conexões de rede, conexões de dados e vários módulos funcionais. Camada Gerenciador de Gerenciador de Mensagens de Erro e Gerenciador de Simulação Conexões de Advertência Gerenciador de Gerenciador de Gerenciador de Arquivos de Saída Parâmetros Tabela de Dados Conexões de Blocos Conexões de Rede Conexões de Dados Conexão 1 Conexão 1 Conexão 1 Conexão n Conexão n Conexão n Figura 15 – Estrutura de uma camada do Hydragyrum. A.2.2.2 - Módulos Funcionais Uma camada do Hydragyrum possui os seguintes módulos funcionais: Gerenciador de Simulação – Assim como no bloco, este módulo também é o mais importante de uma camada. Ele também possui funções para a troca de dados com o kernel, funções para gerar eventos e funções de comportamento da camada. Gerenciador de Conexões – É responsável pela manipulação de conexões de blocos, conexões de rede e conexões de dados. 287
  • Gerenciador de Arquivos de Saída – É responsável pela manipulação de arquivos de resultados (.dat). Possui as mesmas funções que o módulo gerenciador de arquivos de saída do bloco. Gerenciador de Mensagens de Erro e de Advertência – É responsável pelo armazenamento e envio para o kernel de mensagens de erro e de advertência geradas pela camada. Gerenciador de Parâmetros – É responsável pelo armazenamento dos parâmetros da camada. Permite a manipulação dos parâmetros da camada, do seu bloco e dos gerenciadores de tráfego associados. Gerenciador de Tabelas de Dados – É responsável pelo armazenamento dos dados de tabela da camada. Permite a manipulação dos dados de tabela da camada, do seu bloco e dos gerenciadores de tráfego associados. A.2.2.3 - Funcionamento A camada também possui as mesmas funções de comportamento que o bloco. E mais, com exceção da função de execução de simulação, as funções de comportamento da camada são acionadas pelo kernel logo após as funções de comportamento do bloco. Entretanto, algumas das funções de comportamento da camada diferem em termos de funcionalidade das funções de comportamento do bloco. A seguir veremos estas diferenças. A.2.2.3.1 - Função de Criação (Setup) Nesta função o desenvolvedor de modelos deve implementar a: Configuração dos valores default dos parâmetros da camada. Configuração dos valores default de dados privados da camada. Gravação dos parâmetros default da camada. A.2.2.3.2 - Funções de Estabelecimento de Conexão de Blocos, Conexão de Rede e Conexão de Dados (OnConnect, OnNetConnect e OnDataConnect) Estas funções permitem a camada modificar registros em tabelas e executar outras funções sempre que uma nova conexão for estabelecida. 288
  • A.2.2.3.3 - Funções de Remoção de Conexão de Blocos, Conexão de Rede e Conexão de Dados (OnDisconnect, OnNetDisconnect e OnDataDisconnect) Estas funções permitem a camada retornar ao estado anterior a criação da conexão que está sendo removida. A.2.2.3.4 - Função de Troca de Parâmetros (OnChangeParameter) Esta função é executada toda vez que um parâmetro é modificado em algum modelo ou no kernel do simulador. Permite a camada responder a modificações nos seus parâmetros e a modificações nos parâmetros do kernel e de outros modelos. A.2.2.3.5 - Função de Inicialização (Initiate) Nesta função o desenvolvedor de modelos deve implementar a leitura dos valores dos parâmetros da camada e dos parâmetros globais. A.2.2.3.6 - Função de Execução da Simulação (Run) Nesta função o desenvolvedor de modelos deve implementar o algoritmo de execução de eventos da camada, ou seja, o algoritmo responsável pelo comportamento da camada durante a simulação. A.2.2.3.7 - Função de Tratamento de Parada de Simulação (OnStop) Esta função permite a camada responder a uma parada de simulação. A.2.2.3.8 - Função de Pós-Processamento (PosProcessing) Esta função pode ser usada para executar qualquer processamento adicional em uma camada após o final de uma simulação. A.2.2.3.9 - Função de Finalização (Terminate) Esta função pode ser usada para executar a limpeza da memória alocada pela camada durante a execução de outras funções. A.2.2.3.10 - Implementação 289
  • As camadas são construídas a partir da herança da classe base Layer. Portanto, as camadas herdam toda a funcionalidade provida por esta classe base. A Figura 16 ilustra baseado em um modelo orientado à objetos a construção de novas camadas no simulador. Classe layer Base Classe Base Nova new_model Classe Camada Derivada Figura 16 – Construção de novas camadas no Hydragyrum. O desenvolvimento de uma nova camada consiste em implementar as suas funções de comportamento e compilá-la. A.2.3 - Gerenciadores de Tráfego Chamamos de gerenciadores de tráfego os modelos derivados da classe base Squeue. Em nossa discussão, um gerenciador de tráfego pode ser visto como uma estrutura genérica que oferece todos os subsídios necessários para que as peculiaridades dos modelos de gerenciadores de tráfego sejam implementadas. A.2.3.1 - Estrutura A Figura 17 mostra a estrutura de um gerenciador de tráfego do Hydragyrum. Esta estrutura possui várias conexões de blocos, conexões de rede, conexões de dados e vários módulos funcionais. 290
  • Gerenciador de Tráfego Gerenciador de Gerenciador de Mensagens de Erro e Gerenciador de Simulação Conexões de Advertência Gerenciador de Gerenciador de Gerenciador de Gerenciador de Armazenamento e Parâmetros Tabela de Dados Arquivos de Saída Remoção de Mensagens Conexões de Blocos Conexões de Rede Conexões de Dados Conexão 1 Conexão 1 Conexão 1 Conexão n Conexão n Conexão n Figura 17 – Estrutura de um gerenciador de tráfego do Hydragyrum. A.2.3.2 - Módulos Funcionais A gerenciador de tráfego do Hydragyrum possui os mesmos módulos funcionais que a camada. A.2.3.3 - Funcionamento A gerenciador de tráfego possui as mesmas funções de comportamento que a camada (Seção A.2.2.3 - ), com exceção das funções de estabelecimento e remoção de conexões de blocos, conexões de rede e conexões de dados. As funções de comportamento do gerenciador de tráfego, também são acionadas pelo kernel logo após a execução das funções de comportamento do bloco. A.2.3.4 - Implementação Os gerenciadores de tráfego são construídos a partir da herança da classe base Squeue. O desenvolvimento de um novo gerenciador de tráfego consiste em implementar as suas funções de comportamento e compilá-la. A.3 - Referências Bibliográficas [1] ANDRADE NETO, E. L., “Hydragyrum Network Simulation Environment Programming Manual 1.0”, Dezembro 1999. 291
  • [2] STROUSTRUP, B., “The C++ Programming Language”, Third Edition, Addison-Wesley, 1997. [3] ANDRADE NETO, E. L., “Ambiente de Simulação de Redes a Eventos Discretos”, Tese de Doutorado, Faculdade de Engenharia Elétrica e de Computação, UNICAMP, Orientador: Prof. Dr. Leonardo S. Mendes, Setembro 2001. [4] BLACK, U. D., “ATM: Foundation for Broadband Networks”, Prentice-Hall, 1995. [5] MINOLLI, D., ALLES, A., “LAN, ATM, and LAN Emulation Technologies”, Artech House, 1996. [6] SACKETT, G. C., METZ, C., “ATM and Multiprotocol Networking”, McGraw Hill, January 1997. [7] KLEIN, J., “SIMNT - Uma Ferramenta para a Simulação de Sistemas de Comunicação”, Tese de Mestrado, Faculdade de Engenharia Elétrica e de Computação, UNICAMP, Orientador: Prof. Dr. Leonardo S. Mendes, Agosto 1995. [8] KLEIN, J., “Desenvolvimento de uma Ferramenta CAD/CAM para Simulação, Projeto e Ensino de Sistemas de Comunicação”, Tese de Doutorado, Faculdade de Engenharia Elétrica e de Computação, UNICAMP, Orientador: Prof. Dr. Leonardo S. Mendes, Março 1999. [9] ALBERTI, A. M., “SimATM: Um Ambiente para a Simulação de Redes ATM”, Tese de Mestrado, Faculdade de Engenharia Elétrica e de Computação, UNICAMP, Orientador: Prof. Dr. Leonardo S. Mendes, Abril 1998. [10] ALBERTI, A. M., ANDRADE NETO, E. L., KLEIN, J., MENDES, L. S., “SimATM: An ATM Network Simulation Environment”, 7TH IEEE CAMAD workshop, São Paulo, 1998. O trabalho não consta dos anais, pois convidado para substituir um trabalho ausente. 292