Download - Desenvolvimento de Modelos de Simulação para a Análise de Qualidade de Serviço em Redes ATM
UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO DEPARTAMENTO DE COMUNICAÇÕES
Caixa Postal 6101, CEP 13081-970 – Campinas – SP. Telefone: (0xx19) 3788 3703. Fax: (0xx19) 3788 1395.
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.
ii
FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA DA ÁREA DE ENGENHARIA - BAE - UNICAMP
AL17d
Alberti, Antônio Marcos 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.
iii
Em momentos de dificuldade, somente a imaginação é mais importante do que o conhecimento.
Albert Einstein
iv
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.
v
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.
vi
Í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
vii
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
viii
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
ix
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
x
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
xi
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
xii
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
xiii
Í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
xiv
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
xv
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
xvi
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
xvii
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
xviii
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
xix
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
xx
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
xxi
Í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
1
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].
2
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.
3
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
4
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.
5
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
6
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.
7
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
8
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.
9
[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.
10
Página deixada em branco intencionalmente.
11
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
12
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
13
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
14
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
15
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 (1)Evento (1)
Evento (0)Gerenciador de
Eventos
Fila deEventos
Evento (2)Evento (1) Evento (2)
Executa oBloco B(0,1,2)
Executa oBloco A
(1,1)
Executa oBloco C
(1,2)
1
2
4
3
1 Agendamento de eventos pelos blocos.
2 Armazenamento dos eventos na fila com prioridades.
3 Retirada do evento de maior prioridade.
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.
16
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
17
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.
18
� 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.
19
� 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
20
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
21
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
22
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.
23
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
24
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
25
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
26
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.
27
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].
28
� 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
29
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.
30
� Plataformas em que a ferramenta de simulação pode ser instalada.
Características
Nome Desenvolvedor Téc
nica
de
Sim
ulaç
ão
Sim
ulaç
ão P
aral
ela
ou
Dis
trib
uída
Bib
liote
ca d
e M
odel
os
Inte
rfac
e G
ráfic
a
Est
raté
gias
de
Mod
elam
ento
Lin
guag
em d
e
Prog
ram
ação
Plat
afor
ma
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
ATM-TN TeleSim Project Event-driven Sim Separada2 Sim Células C++ e
Java Unix
CLASS Instituto Politécnico de Torino
(Itália) Time-driven Não Junto Não Células C
OpenVMS, Linux, HP-UX,
Ultrix e MS-DOS
Ancles Instituto Politécnico de Torino
(Itália) Event-driven Não Junto Não Chamadas C
OpenVMS, Linux, HP-UX,
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
MODELERTM
MIL 3 Inc.
Washington DC (E.U.A.) Event-driven Não3 Separada Sim
Células ou
Taxas - -
TeD Georgia Tech Institute of
Technology (E.U.A.) Event-driven Sim Separada Sim -
C++ e
C/
Java4
Sun Sparcs, SGI Onyx e
PowerChallenge
Parsec Universidade da Califórnia em
Los Angeles (E.U.A.) Event-driven Sim Separada Sim -
C e
C++5
Solaris 2.5.1, SunOS 4.1.4,
Irix 6.4, FreeBSD 2.2.2.,
AIX,
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.
31
[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.
32
[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.
33
[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.
34
[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.
35
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.
36
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.
37
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
Kernel(.dll)
Programa Executável(.exe)
Modelo (.dll)
Modelo 2 (.dll)
Modelo N (.dll)
Biblioteca deModelos
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.
38
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.
39
layer squeue
block
Bloco
Camada 1
Camada n
Camadas
Gerenciador 1
Gerenciador n
Gerenciadores de Tráfego
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
40
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.
41
[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.
42
Página deixada em branco intencionalmente.
43
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
44
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.
45
Terminal Faixa Larga
Camada de Adaptação ATM
Camada ATM
Camada Física deEntrada
Camada Física deSaída
Estrutura de Fila
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Camada ATM
Camada Física deEntrada
Comutador
Estrutura de Fila
Camada Física deSaída
Escalonador
Estrutura de Fila
Escalonador
Estrutura de Fila
Escalonador
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Camada Requeredora e Removedorade Conexões
Aplicativo
Camada Fonte de Tráfego
Camada Receptora de Tráfego
Camada Finalizadora de Conexões
GerenteGerenciadoresde Tráfego
Camadas
Sentido datransmissãode dados na rede.
Matriz deComutação com
MemóriaCompartilhada
Policiamento deTráfego
Policiamento deTráfego
Policiamento deTrá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-
46
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
47
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.
Campos deInformação
Ponteiropara uma
Célula
Campos deInformação
Ponteiropara umPacote
Pacote
Célula ATM
Célula ATM
Pacote
Célula
Célula
Ficha Fichaa) Segmentação de pacotes em células ATM no
mundo real. b) Modelo utilizado neste trabalho.
Campos de Informação
Campos deInformação
Ponteiropara uma
Célula
Campos deInformação
Ponteiropara umPacote
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
48
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
49
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
50
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.
51
� 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.
ServiceCategorie CLR Max CTD P2P CDV PCR SCR MBS Conformance
Definition PDAM
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.
52
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.
BCI NCI DCI PCell PTC PCellsVector PDAM
Figura 4.7 – Estrutura das mensagens de gerenciamento de tráfego.
53
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.
SourceApp
SourceLayer
DestinyApp
DestinyLayer PTC NCI DCI PDAM
Figura 4.8 – Estrutura das mensagens de roteamento.
54
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.
55
� Samples_Number (Número de Amostras) – Este campo contém o número de amostras
feitas.
Type S1 t_1 v_1 Mean SamplesNumber
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.
56
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.
57
Cabeçalho: informa as variáveis quesão amostradas em cada coluna do
arquivo de saída.
t "Q0" "M_Q0" "D0" "M_D0"0.0000000000 0.0000000000 0.0000000000 0.0000000000 0.00000000000.1000000000 5.0000000000 3.5705956250 0.0113740000 0.00883958280.2000000000 0.0000000000 2.2533809375 0.0004365000 0.00682842710.3000000000 0.0000000000 1.5588218749 0.0006396250 0.00584558200.4000000000 0.0000000000 1.2029290624 0.0005302500 0.00511884710.5000000000 0.0000000000 0.9859109999 0.0004599375 0.00460706070.6000000000 0.0000000000 0.8378645833 0.0012490000 0.00402175000.7000000000 0.0000000000 0.7528446135 0.0010276455 0.00346704760.8000000000 0.0000000000 0.7075419543 0.0011536875 0.00293281640.9000000000 0.0000000000 0.6825142371 0.0001005625 0.00250719521.0000000000 0.0000000000 0.6473560224 0.0009703545 0.0022955887
Notação científica:10 casas após a virgula
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.
58
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.
59
•
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.
60
� 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].
61
ON
OFF
Estadoda
Conexão
Tempo
OFF OFF
ON ON
Padrão Determinístico
ON
OFF
Estadoda
Conexão
TempoOFF
OFF
ON ON
Padrão Exponencial Negativo
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
62
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
63
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.
64
ON
OFF
Tamanhodos
Pacotes
Tempo
OFF OFF
ON ON
Padrão Determinístico de Pacotes
a)
ON
OFF
Tamanhodos
Pacotes
TempoOFF
OFF
ON ON
Padrão Determinístico de Pacotes
b)
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.
ON
OFF
Tamanhodos
Pacotes
Tempo
OFF OFF
ON ON
Padrão Poissoniano-ExponencialNegativo de Pacotes
a)
ON
OFF
Tamanhodos
Pacotes
TempoOFF
OFF
ON ON
Padrão Poissoniano-ExponencialNegativo de Pacotes
b)
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.
65
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.
66
� 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
67
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
FIL
FIL
FOL
FOL
FOL
QS S
QS S
QS S
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
68
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).
Camada ATM
Estrutura de Fila
Escalonador
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Célula provenienteda PHY_IN.
Célula destinadaa PHY_OUT.
Policiamento deTráfego
Porta deSaída 0
Porta deSaída 1
Policiamentode tráfego está
habilitado?
Executa descarte seletivopara escolher a células a
serem descartadas.
Célularecebida
foi descartada?
Executa policiamento detráfego.
Célula recebida foidescartada?
Sim
Não
Não
Não
Fim
Gerenciamentode estrutura de filas
aceitou a célula?
Executa gerenciamento deestrutura de filas.
Sim
Envia célula para aestrutura de filas e para oescalonador da porta de
saída adequada.
Descarta células.
Não
Sim
Recebe Célula
Sim
Identifica a porta de saídapara a qual a célularecebida deve ser
encaminhada.
Iteração entre a camada SW_ATM e os gerenciadores detráfego do comutador.
Algoritmo executado pela camada SW_ATM quando umacélula é recebida da camada física de entrada (PHY_IN).
b)
a)
CamadaATM
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
69
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.
70
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 - ).
71
Célula provenienteda PHY_OUT do
equipamentotransmissor.
Célula destinadaa camada ATM.
Policiamentode tráfego está
habilitado?
Executa descarte seletivopara escolher a células a
serem descartadas.
Célularecebida
foi deletada?
Executa policiamento detráfego.
Célula recebida foideletada?
Sim
Não
Não
Não
Fim
Gerenciamentode estrutura de filas
aceitou a célula?
Executa gerenciamento deestrutura de filas.
Sim
Envia célula para aestrutura de filas e para oescalonador da porta de
saída adequada.
Descarta células.
Não
Sim
Recebe Célula
Sim
Identifica a porta deentrada pela qual a célula
foi recebida.
Iteração entre a camada PHY_IN e os gerenciadores detráfego do comutador para a situação em que existediferença entre a taxa de serviço da camada ATM e a taxade recepção da camada PHY_IN.
Algoritmo executado pela camada PHY_IN quando umacélula é recebida e existe diferença entre a taxa de serviçoda camada ATM e a taxa de recepção da camada PHY_IN.
b)
a)
Camada Física deEntrada
Estrutura de Fila
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
CamadaFísica
Policiamento deTráfego
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
72
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 destinadaao próximo
equipamento darede.
Célulaproveniente dacamada ATM.
Policiamentode tráfego está
habilitado?
Executa descarte seletivopara escolher a células a
serem descartadas.
Célularecebida
foi deletada?
Executa policiamento detráfego.
Célula recebida foideletada?
Sim
Não
Não
Não
Fim
Gerenciamentode estrutura de filas
aceitou a célula?
Executa gerenciamento deestrutura de filas.
Sim
Envia célula para aestrutura de filas e para oescalonador da porta de
saída adequada.
Descarta células.
Não
Sim
Recebe Célula
Sim
Identifica a porta de saídada célula.
Iteração entre a camada PHY_OUT e os gerenciadores detráfego do equipamento transmissor.
Algoritmo executado pela camada PHY_OUT quando umacélula é recebida da camada ATM.
b)
a)
CamadaFísica
Camada Física deSaída
Estrutura de Fila
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Policiamento deTráfego
Figura 4.20 – Iteração entre a camada PHY_OUT e os demais gerenciadores de tráfego dos blocos comutador e
BTE.
73
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
74
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.
75
Estrutura de Filas Default
Fila FIFO
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Células Células
Modelo de Escalonador
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
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.
76
Estrutura de Filas com Filaspor Conexão
Fila para a conexão VCC_1
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Fila para a conexão VCC_2
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Fila para a conexão VCC_n
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Células Células
Modelo de Escalonador
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Modelo de Escalonador
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
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
77
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).
78
� 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 itF2. Para calcular o i
tF2, o primeiro passo é atualizar o valor do tempo
virtual
79
( )∑∈
−+=
jBii
ttttVV
φ12
12 , (1)
onde jB é o conjunto de todas as conexões ativas no intervalo t2 – t1, iφ é o peso da conexão
i e 1t
V é o tempo virtual anterior.
Uma vez atualizado o tempo virtual, é necessário calcular o tempo virtual de inicio de
serviço itS2
{ }212
,max ti
tit VFS = , (2)
onde itF1é o tempo virtual de final de serviço anterior.
Feito isso pode-se calcular tempo virtual de final de serviço itF2 da célula:
i
it
it SF
φ1
22+=
(3)
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 2t
V .
� O tempo virtual de final de serviço anterior itF1.
80
� O tempo virtual de inicio de serviço atual itS2.
� O tempo virtual de final de serviço atual itF2.
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(CBR.1, ABR.1
e UBR.1)
Espaçador B(VBR.1)
Espaçador C(VBR.2)
Cél
ula
Cél
ula
Cél
ula
CET
Transmite célulacujo CET é menorque o tempo de
inicio de um novoslot.
Cél
ula
Fila com prioridades
Ordenação de célulasconforme o CET
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Espaçador D(VBR.3)
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:
81
� 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 - ).
82
CET = 0?
Armazena célula para serservida após o CET
Não
Sim
End
CET=Time
Recebe uma célula
Busca valor do CET para aconexão.
CET=CET+1/PCR
Grava valor do CET para aconexão.
CETp = 0e
CETs = 0?
Armazena célula para serservida após o CET
Não
Sim
End
CETp = TimeCETs = Time
Recebe uma célula
Busca valor de CETp e CETspara a conexão.
CETp=CETp+1/PCRCETs=CETs+1/SCR
Grava valor do CETp e doCETs para a conexão.
BT=(MBS-1).(1/PCR+1/SCR)
CET=max(CETs-BT;CETp)
Time > CET?
Não
Sim
CETp = TimeCETs = TimeCET=max(CETs-BT;CETp)
a) Espaçador A (CBR.1, ABR.1 e UBR.1)
b) Espaçador B (VBR.1)
CET - Conformance Emission TimeCETp - Conformance Emission Time for PCRCETs - Conformance Emission Time for SCRPCR - Peak Cell RateSCR - Sustainable Cell RateMBS - Maximum Burst SizeBT - Burst Tolerance
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
83
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.
84
CETp = 0e
CETs = 0?
Armazena célula para serservida após o CET
Não
Sim
End
CETp = TimeCETs = Time
Recebe uma célula
Busca valor de CETp e CETspara a conexão.
CETp=CETp+1/PCRCETs=CETs+1/SCR
Grava valor do CETp e doCETs para a conexão.
BT=(MBS-1).(1/PCR+1/SCR)
CET=max(CETs-BT;CETp)
CET > Time?
Não
Sim
a) Espaçador C (VBR.2)
SimCETp <= Time
eCLP = 0?
CET = CETpCLP = 1
Não
CLP = 0 ?
Sim
Não CETp=CETp+1/PCR
CETp = 0e
CETs = 0?
Armazena célula para serservida após o CET
Não
Sim
End
CETp = TimeCETs = Time
Recebe uma célula
Busca valor de CETp e CETspara a conexão.
CETp=CETp+1/PCRCETs=CETs+1/SCR
Grava valor do CETp e doCETs para a conexão.
BT=(MBS-1).(1/PCR+1/SCR)
CET=max(CETs-BT;CETp)
b) Espaçador D (VBR.3)
CLP = 0 ?
Sim
Não CETp=CETp+1/PCR
CET - Conformance Emission TimeCETp - Conformance Emission Time for PCRCETs - Conformance Emission Time for SCRPCR - Peak Cell RateSCR - Sustainable Cell RateMBS - Maximum Burst SizeBT - Burst ToleranceCLP - Cell Loss Priority
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.
85
� 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 kt
B sendo servidas simultaneamente em um
escalonador GPS no instante kt . 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
rrktBj j
ii .∑ ∈
=φ
φ,
(4)
onde kt
B é o número de conexões sendo servidas simultaneamente no escalonador no
instante kt , 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 st , 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 st é o pacote que terminaria serviço primeiro no GPS e que já teria começado a
ser servido pelo GPS no instante st .
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
86
escalonador. Consideremos a chegada de um pacote da conexão i no instante kt com tamanho igual
a itk
L bits. No momento da chegada deste pacote, um tempo virtual geral kt
V é incrementado de
acordo com a expressão
( )∑∈
−−+=−
kt
kk
Bjj
kktt
ttVVφ
11 ,
(5)
onde 1−kt
V é o tempo virtual geral no instante 1−kt e kt
B é o número de conexões sendo
servidas simultaneamente no escalonador no instante kt .
Uma vez atualizado o tempo virtual geral, é necessário calcular então os tempos virtuais de
inicio de serviço ( itk
S ) e de final de serviço ( itk
F ) deste pacote no GPS emulado. O tempo virtual de
inicio de serviço itk
S é calculado de acordo com a expressão
{ }kkk t
it
it VFS ,max
1−= , (6)
onde itk
F1−é o tempo virtual de final de serviço anterior.
Feito isso calcula-se o tempo virtual de final de serviço itk
F do pacote
i
iti
ti
tk
kk
LSF
φ+= .
(7)
Tanto no escalonador PGPS quanto no escalonador WF2Q, a ordem de serviço dos pacotes é
determinada em função dos tempos virtuais itk
S e itk
F . Suponhamos que ambos os escalonadores
queiram escolher no instante st 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 itk
F , independente do instante de tempo st . 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 itk
F , cujo itk
S seja menor que o instante de tempo st .
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.
87
Como vimos, o WF2Q serve primeiro o pacote com menor tempo virtual itk
F cujo itk
S seja
menor que o instante de tempo de serviço real st . 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 i
tkF e fila com prioridades para o i
tkF 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 itk
F . A
Figura 4.26 mostra a estrutura do modelo desenvolvido.
As células são armazenadas na fila com prioridades por itk
F 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 itk
F 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
Transmite célulaelegível com o
menor .
Fila com prioridades p/ o itk
F
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Fila com prioridades p/ o(temporária)
Cél
ula
itk
F
Células nãoelegíveis
itk
F
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
88
A Figura 4.27 mostra o fluxograma do algoritmo de armazenamento de células ATM.
Quando uma célula ATM é recebida (instante de tempo kt2), o modelo do escalonador verifica se o
tempo de chegada da célula anterior ( 1−kt ) é igual a zero. Se esta variável for igual a zero, ela é
configurada com o valor de kt . 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 1−kt for igual a zero, a variável BT
também é configurada com o valor de kt .
Ainda na Figura 4.27, o modelo do escalonador WF2Q busca o valor dos pesos para as
conexões do conjunto kt
B . Feito isso, é verificado se a variável kt é maior que a variável 1−kt . 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 (kt
V ). Também é lido o valor do tempo virtual de final de serviço ( itk
F1−)
para a conexão i no instante 1−kt .
Se o tempo virtual kt
V for maior que o itk
F1−, o valor do tempo virtual de inicio de serviço
( itk
S ) para a conexão i é tomado como sendo igual ao kt
V . Caso contrário, o valor do tempo virtual
de inicio de serviço para a conexão i é tomado como sendo igual ao itk
F1−. Então, o i
tkF é atualizado
para o valor do itk
S acrescido de iφ1 . A célula é então armazenada na fila com prioridades para o
itk
F , onde aguarda pelo serviço.
2 Quando a primeira célula ATM é recebida k=1, i
tF0
=0, itS0
=0 e 0t
V =0.
89
Não
Sim
Recebe uma célula
>
Sim
∑∈ ktBj
jφCalcula
( )∑∈
−−+=−
kt
kk
Bjj
kktt
ttVVφ
11
itk
F1−
Busca
itk
F1−
itk
V
1−> kk tt
it
it kk
VS =
Nãoi
tit kk
FS1−
=
i
it
it kk
SFφ1+=
BuscaktBj∈φ
Fim
kt
?01 =−kt Sim kk tt =−1 ktBT =
Não
itk
FArmazena célula na filacom prioridades para o
- Tempo de chegada da célula atual
- Peso para a conexão iiφ1−kt - Tempo de chegada da célula anteriorkt
- Tempo virtual para o instante1−kt
V 1−kt- Tempo virtual para o instante
ktV kt
- Conjunto de conexões ativas emkt
B kti
tkF
1−- Tempo virtual de final de serviço para a conexão i em- Tempo virtual de final de serviço para a conexão i emi
tkF
itk
S - Tempo virtual de inicio de serviço para a conexão i em
1−kt
ktkt
- Período de um frame de serviçoFP- Inicio de um período de atividade no escalonadorBT
Inicia serviço no inicio dopróximo FP
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 itk
F , 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
90
ú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 St . Inicialmente, é executado um laço na fila com
prioridades para o itk
F . O objetivo deste laço é encontrar a célula elegível com menor itk
F . 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 itk
S no sistema GPS com o tempo real de serviço
St . A seguinte expressão foi desenvolvida para possibilitar tal comparação
Sit tBTFPSk
≤+. . (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 itk
S 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 itk
S da célula que se encontra no topo da
fila com prioridades para o itk
F é 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 itk
F 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 itk
F e armazenada na
fila para o itk
F temporária, onde aguarda para ser re-inserida na fila itk
F principal. Neste caso, o laço
prossegue verificando a elegibilidade das demais células armazenadas na fila itk
F 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 itk
F principal for elegível para ser servida no
instante St , o escalonador deverá escolher igual uma célula para ser servida. Neste caso será servida
a célula com menor itk
F que se encontra na fila com prioridade temporária.
91
Serve uma célula
Enquanto a fila comprioridades para onão estiver vazia
St
itk
F
Busca epara a célula com
menor
itk
F itk
S
itk
F
Sit tBTFPSk
≤+.Remove célula da fila com
prioridades para oprincipal
itk
F
Serve célula
Fim do laço
Sim
Armazena célula na filapara o temporáriai
tkF
Não
End
Remove célula da fila comprioridades para o i
tkF
Remove célula da fila comprioridades para o
temporáriai
tkFSe
vazia
Ambasas filas ficaram
vazias?Sim
Não
0=kt
V
01 =−kt
01
=∈
−
kt
k
BjtF
1=k
FPtS +Serve próxima célula noinstante
Enquanto a filapara o
temporaria não estivervazia
Fim do laço
Remove célula da filapara o temporáriai
tkF
Armazena célula na filapara o principal
itk
F
itk
F
Sevazia
- Tempo de chegada da célula atual
- Peso para a conexão iiφ1−kt - Tempo de chegada da célula anteriorkt
- Tempo virtual para o instante1−ktV 1−kt- Tempo virtual para o instante
ktV kt
- Conjunto de conexões ativas emktB kt
itk
F1−- Tempo virtual de final de serviço para a conexão i em- Tempo virtual de final de serviço para a conexão i emi
tkF
itk
S - Tempo virtual de inicio de serviço para a conexão i em
1−kt
ktkt
- Período de um frame de serviçoFP- Inicio de um período de atividade no escalonadorBT
Pára serviç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, 1−kt , kt
V e
kt
k
BjtF ∈
−1são reinicializadas e o escalonador é “desligado”. Caso contrário, é agendando o serviço de
uma próxima célula ATM no instante FPtS + . 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.
92
� O tempo virtual atual 2t
V .
� O tempo virtual de final de serviço anterior itF1.
� O tempo virtual de inicio de serviço atual itS2.
� O tempo virtual de final de serviço atual itF2.
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
Cél
ula
Fila com prioridades H
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Fila com prioridades L
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Transmite célula coma menor etiqueta.
Transfere célula antesque ela utrapasse oseu limite de atraso.
Transfere célula de um fluxo mal comportado.
Figura 4.29 – Estrutura do LFVC_Scheduler.
93
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
( ) fstcT ∆≥− , (9)
onde ( )cT é igual a etiqueta para a célula c, st 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
94
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
( fQ ) 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 fQ . 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 fQ inicia buscando a célula que encontra-se na
cabeceira da fila fQ . 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 ( prevft ) 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 ρτ ++∆+≤ fsf tt . Se esta condição
for verdadeira a célula é considerada de maior prioridade e armazenada na fila H com a etiqueta ft .
Se esta condição for falsa a célula é considerada de menor prioridade e armazenada na fila L com a
etiqueta fft ∆− . 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 τ+mt . 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.
95
Recebe uma célula( )
?1=fQ
Busca na estrutura de filasassociada a célula que
está na cabeçeira da fila.
Sim
Não
Fim
Busca eprevft
fQ
fφ
SCff .
1φ
=∆
( ) fprevfsf ttt ∆+= ,max
fprevf tt =
SC1=τ
?ρτ ++∆+≤ fsf tt Sim
Não
Armazena célula comtempo na fila com
prioridades H.ft
Armazena célula comtempo na fila com
prioridades L.fft ∆−
Processa cabeçeirada fila
Processa cabeçeira
fQ
fQ
Retorna
FLAG_1 = 1?
Fila H estáocupada ou fila L está
ocupada?
Sim
Sim
Agenda retirada dapróxima célula da fila H
no instante τ+mt
Não
Desliga escalonadorNão
Liga escalonador
Busca na estrutura defilas associada.
fQ
Escalonadorestá ligado?
Sim
Não
Agenda retirada de umacélula da fila H
no inicio do próximo frame.
mtda fila ( )mt
- Etiqueta atual de um fluxo f.
- Peso para o fluxo f.- Fila para o fluxo f.
- Etiqueta anterior de um fluxo f.
- Tempo atual do escalonador.
fφ
ft
fQ
prevft
- Período de tempo necessário para transmitir umacélula na taxa alocada para o fluxo f.
f∆
st
- Período dos frames de transmissão doescalonador.
τ
- Parâmetro de arredondamento.ρ- Capacidade do escalonador em células/segundo.SC
- Tempo de chegada de uma célula do fluxo f.mt
Figura 4.30 – Algoritmo implementado para o armazenamento de células no LFVC_Scheduler.
96
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).
Fila Hestá vazia?
Remove umacélula ( )lt
Sim
Não
Fim
Transfere célulasda fila L para a fila H
Existemcélulas na
fila H ?Sim Serve célula da
cabeçeira da fila H
Não
Enquanto houveremcélulas na fila L.
Célula dacabeçeira da fila L é
válida?
Armazena célula na fila H
Sim
( )( )ρ−= min,max ktt ss
Seρτ ++≤ stkmin
Remove célula da fila L
Sim
Retorna
Fim do laço
Sevazia
Não
Transfere célulasda fila L para a fila H
Não
- Etiqueta atual de um fluxo f.
- Peso para o fluxo f.- Fila para o fluxo f.
- Etiqueta anterior de um fluxo f.
- Tempo atual do escalonador.
fφ
ft
fQ
prevft
- Período de tempo necessário para transmitir umacélula na taxa alocada para o fluxo f.
f∆
st
- Período dos frames de transmissão doescalonador.
τ
- Parâmetro de arredondamento.ρ- Capacidade do escalonador em células/segundo.SC
- Tempo de chegada de uma célula do fluxo f.mt
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 st e a diferença entre a etiqueta da célula mais
prioritária da fila L ( mink ) 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
97
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.
Enquanto FLAG_2 = 0
Esta célulaé válida? Não
Retorna
Fim do laço
Remove célula dacabeçeira da fila H.
Aindaexistem células
na fila H?
FLAG_2 = 0
Sim
Não Desliga escalonador.
Envia célula com menorft τ+= ss tt
FLAG_1 = 1
Agenda processamento dacabeçeira da fila
no instantefQ
lt
Sim
FLAG_2 = 1
Serve célula dacabeçeira da fila H
- Etiqueta atual de um fluxo f.- Fila para o fluxo f.- Tempo atual do escalonador.
ft
fQ
st
- Período dos frames de transmissão doescalonador.
τ
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 fQ é agendado para o mesmo instante de tempo lt . 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
98
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 ( 1−ft ).
� A etiqueta atual de uma célula ( ft ).
� 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
99
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:
CE
i =φ onde E é a largura de faixa necessária para a nova conexão.
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.
100
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 PCR PCR*1,25
SCR PCR
CBR
CLR CLR
PCR PCR
SCR SCR
RT-VBR
CLR CLR
PCR PCR
SCR SCR
NRT-VBR
CLR CLR
PCR MCR*1,25
SCR MCR
ABR
CLR 1e-3
101
PCR PCR
SCR PCR/100
UBR
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
0 ?Calcula e0 e b0
e0 < ed eb0 < bd ?
Aceitaconexão
Rejeitaconexão
Calcula e0 e b0
Calcula ej e bj
ej < ed ebj < bd ?
Não
Sim
Não
Sim
Não
Fim
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:
102
1) Se TB
SCRBC > ,
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].
( )
<≤
≤−
+=
PCRSCRCB
BSCR
CBBSCR
SCRPCRB
CBPCR
e
T
T
T
/
/./1
0
(10)
−−
−=SCRPCR
SCReBBb TT
00 .
(11)
−
=
SCRPCRPCRMBSBT
(12)
2) Se TB
SCRBC ≤ :
SCRe =0 (13)
≤
>=
9,0.
9,0..
0
TT
T
BSCR
BCB
BSCR
BC
CBSCR
b
(14)
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:
jj K
Cemax
= , (15)
onde jK max é o número máximo de conexões admissíveis supondo que somente conexões
da classe j sejam admitidas.
−−
−=SCRPCR
SCReBBb j
TTj . (16)
jK max é calculado de duas formas:
103
1) Se TB
SCRBC > :
jK max é o valor de K para o qual
( )
=
−−−+
=SCRw
aawaaKSFk
1log11log.1log.)( * ,
(17)
onde
KeC
a
= 0 e
(18)
0eSCRw = .
(19)
O Elwalid_Mitra_CAC resolve a equação de
=SCR
SFk1log)( * usando o método de Newton-
Raphson [12].
2) Se TB
SCRBC ≤ :
0
maxeCK j =
(20)
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
Ce
i0=φ ou
Ce j
i =φ . (21)
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.
104
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:
105
� 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.
106
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)
Q(t)
(a)Bf
b0,i
α
γ
T(t)
Q(t)
(b)Bf
bi
α
γ
b0,i
µ
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:
( )
≤<≤−+
=fi
ii BtQb
tQtQbtT
)()()(
)(,0
,0
γγγα
, (22)
107
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:
( )( )
≤<−−≤−+
=fii
ii BtQtQb
tQtQbtT
)()()()(
)(,0
,0
γγµγγα
, (22)
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).
108
� 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
109
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
110
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.
111
Policiador de Tráfego Leaky Bucket
Policiador A(CBR.1, ABR.1
e UBR.1)
Policiador B(VBR.1)
Policiador C(VBR.2)
Cél
ula
Cél
ula
Cél
ula
Policiador D(VBR.3)
Cél
ula
Células nãoconformes.
Células conformes.Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
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
112
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.
LCT = 0 ?
NãoSim
End
LCT=Time
Recebe uma célula
Busca valor do LCT e Bpara a conexão.
Grava valor do LCT e do Bpara a conexão.
a) Policiador A (CBR.1, ABR.1 e UBR.1)
b) Policiador B (VBR.1)
LCT - Last Conformance TimeBp - Bucket Size for PCRBs - Bucket Size for SCRPCR - Peak Cell RateSCR - Sustainable Cell RateMBS - Maximum Burst SizeBT - Burst Tolerance
B-(Time-LCT) >CDVT?
Célula não conforme.Descarta célula. Sim
Não
Célula conforme.B=max(0,B-(Time-LCT))+CDVT
LCT=Time
LCT = 0 ?
NãoSim
End
LCT=Time
Recebe uma célula
Busca valor do LCT, Bp eBs para a conexão.
Grava valor do LCT, Bp eBs para a conexão.
Bp-(Time-LCT) >CDVT?
Célula não conforme.Descarta célula. Sim
Não
Célula conforme.Bp=max(0,Bp-(Time-LCT))+CDVT
LCT=Time
Bs-(Time-LCT) >BT+CDVT?
Não
Sim
Bs=max(0,Bs-(Time-LCT))+1/SCR
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
113
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.
114
Policiador C (VBR.2)
LCTp = 0 ?
NãoSim
End
LCTp=Time
Recebe uma célula
Busca valor do LCTp,LCTs, Bp e Bs para a
conexão.
Grava valor do LCTp,LCTs, Bp e Bs para a
conexão.
Bp-(Time-LCTp) >CDVT?
Célula não conforme.Descarta célula.
Não
Célula conforme.Bp=max(0,Bp-(Time-LCTp))+CDVT
LCT=Time
CLP = 1?
Sim
Sim
LCTs = 0 ?
LCTs=Time
Não
Sim
Célula conforme.Bp=max(0,Bp-(Time-LCT))+CDVT
Bs=max(0,Bs-(Time-LCT))+1/SCR
Não
LCTp=TimeLCTs=Time
Célula não conforme.Descarta célula.Sim
Bs-(Time-LCTs) >BT+CDVT?
Não
LCTs - Last Conformance Time for SCRBp - Bucket Size for PCRBs - Bucket Size for SCRPCR - Peak Cell RateSCR - Sustainable Cell RateMBS - Maximum Burst SizeBT - Burst Tolerance
LCTp - Last Conformance Time for PCR
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.
115
Policiador D (VBR.3)
LCTp = 0 ?
NãoSim
End
LCTp=Time
Recebe uma célula
Busca valor do LCTp,LCTs, Bp e Bs para a
conexão.
Grava valor do LCTp,LCTs, Bp e Bs para a
conexão.
Bp-(Time-LCTp) >CDVT?
Célula não conforme.Descarta célula.
Não
Célula conforme.Bp=max(0,Bp-(Time-LCTp))+CDVT
LCT=Time
CLP = 1?
Sim
Sim
LCTs = 0 ?
LCTs=Time
Não
Sim
Célula conforme.Bp=max(0,Bp-(Time-LCTp))+CDVT
Bs=max(0,Bs-(Time-LCTs))+1/SCR
Não
LCTp=TimeLCTs=Time
Célula conforme.Configura CLP para 1.Sim
Bs-(Time-LCTs) >BT+CDVT?
Não
LCTs - Last Conformance Time for SCRBp - Bucket Size for PCRBs - Bucket Size for SCRPCR - Peak Cell RateSCR - Sustainable Cell RateMBS - Maximum Burst SizeBT - Burst Tolerance
LCTp - Last Conformance Time for PCR
Bp=max(0,Bp-(Time-LCTp))+CDVT
Grava valor do LCTp e Bppara a conexão.
LCTp=TimeLCTs=Time
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
116
� 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.
Camada Requeredora e Removedorade Conexões
Aplicativo Determinístico
Camada Fte de Tráfego Determinístico
Camada Receptora de Tráfego
Camada Finalizadora de Conexões
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.
Camada Requeredora e Removedorade Conexões
Aplicativo Poissoniano
Camada Fonte de Tráfego Poissoniano
Camada Receptora de Tráfego
Camada Finalizadora de Conexões
Figura 4.40 – Estrutura do aplicativo poissoniano.
117
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.
Camada Requeredora e Removedorade Conexões
Aplicativo Externo
Camada Fonte de Tráfego Externo
Camada Receptora de Tráfego
Camada Finalizadora de Conexões
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.
118
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
Camada de Adaptação ATM
Camada ATM
Camada Física deEntrada
Camada Física deSaída
Estrutura de Fila
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
CamadaFísica
CamadaATM
AAL
Estruturas de Filas
Escalonadores
Controle deAdmissão deConexões
Gerenciamento deEstrutura de Filas
Descarte Seletivo
Camadas Físicas
Camada ATM
AAL
Modelos Internos
Porta
de
Saíd
a
Porta
de
Entra
da
Policiamento deTráfego Policiamento
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.
119
Camada ATM
Camada Física deEntrada
Comutador
Estrutura de Fila
Camada Física deSaída
Escalonador
Estrutura de Fila
Escalonador
Estrutura de Fila
Escalonador
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Porta
de
Saíd
a
Porta
de
Entra
da
CamadaFísica
CamadaATM
Estruturas de Filas
Escalonadores
Controle deAdmissão deConexões
Gerenciamento deEstrutura de Filas
Descarte Seletivo
Camadas Físicas
Camada ATM
Modelos Internos
Escalonadores
Controle deAdmissão deConexões
Gerenciamento deEstrutura de Filas
Descarte Seletivo
Policiamento deTráfego
Policiamento deTráfego Policiamento
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
120
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:\users\alberti\simulation) 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)
121
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.
122
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
123
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 34
Figura 4.45 – Exemplo de uma rede ATM simples.
124
BTE Ingresso (BTE_0)
Camada de Adaptação ATM
Camada ATM
Camada Física deEntrada
Camada Física deSaída
Estrutura de Fila
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Camada ATM
Camada Física deEntrada
Comutador (Switch_0)
Estrutura de Fila
Camada Física deSaída
Escalonador
Estrutura de Fila
Escalonador
Estrutura de Fila
Escalonador
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Camada Requeredora e Removedorade Conexões
Aplicativo Fonte (App_0)
Camada Fonte de Tráfego
Camada Receptora de Tráfego
Camada Finalizadora de Conexões
Gerente(Manager_0)
Matriz deComutação com
MemóriaCompartilhada
BTE Egresso (BTE_2)
Camada de Adaptação ATM
Camada ATM
Camada Física deEntrada
Camada Física deSaída
Estrutura de Fila
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Aplicativo Destino (App_4)
Camada Finalizadora de Conexões
Camada Receptora de Tráfego
Pacotes
CélulasATM
CélulasATM
Policiamento Policiamento Policiamento
Policiamento
Policiamento
Camadas Caminho percorridopelas células ATM
Gerenciadores deTráfego
Pacotes
ATM_OUT_TP_S
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.
125
Modelos instânciados durante a execução dafunção de estabelecimento de conexão(OnConnect) do bloco.
Modelos instânciados na função de criação(Setup) do bloco.
Terminal Faixa Larga
Camada de Adaptação ATM
Camada ATM
Camada Física deEntrada
Camada Física deSaída
Estrutura de Fila
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Camada ATM
Camada Física deEntrada
Comutador
Estrutura de Fila
Camada Física deSaída
Escalonador
Estrutura de Fila
Escalonador
Estrutura de Fila
Escalonador
Escalonador
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Controle de Admissãode Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivode Células
Camada Requeredora e Removedorade Conexões
Aplicativo
Camada Fonte de Tráfego
Camada Receptora de Tráfego
Camada Finalizadora de Conexões
Gerente
Matriz deComutação com
MemóriaCompartilhada
Policiamento deTráfego
Policiamento deTráfego
Policiamento deTráfego
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.
126
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.
ATM
Comutador
PHY_OUT
PHY_OUT_QS_0
PHY_OUT_S_0
ATM_OUT_QS_S
ATM_OUT_S_0 ATM_OUT_S_1
PHY_OUT_CAC_0
PHY_OUT_BM_0
PHY_OUT_SD_0
ATM_OUT_CAC_S
ATM_OUT_BM_S
ATM_OUT_SD_S
PHY_OUT_QS_1
PHY_OUT_S_1
PHY_OUT_CAC_1
PHY_OUT_BM_1
PHY_OUT_SD_1
PHY_IN
PHY_IN_QS_0
PHY_IN_S_0
PHY_IN_CAC_0
PHY_IN_BM_0
PHY_IN_SD_0
PHY_IN_QS_1
PHY_IN_S_1
PHY_IN_CAC_1
PHY_IN_BM_1
PHY_IN_SD_1
Porta
de
Saíd
a 1
Porta
de
Saíd
a 0
Porta
de
Entra
da 1
Porta
de
Entra
da 0
Estruturas de Filas
Escalonadores
Controle deAdmissão deConexões
Gerenciamento deEstrutura de Filas
Descarte Seletivo
Camadas Físicas
Camada ATM
Escalonadores
CamadaFísica
CamadaATM
Estruturas de Filas
Controle deAdmissão deConexões
Gerenciamento deEstrutura de Filas
Descarte Seletivo
Modeloscompartilhadospelas portas de
saída
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.
127
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.
128
[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.
129
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
130
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).
Servidor NVoD Switch ATM Switch ATM
Filme 1
Filme 2
Filme N
Cliente
Adaptação de Rede
MPEG
MPEG SPTS
AAL 5
ATM
PHY PHY
ATM
PHY
ATM
AAL 5
ATM
PHY
MPEG
MPEG SPTS
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.
131
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.
Desktop PCServidor WWW Switch ATM Switch ATM
ConteúdoWeb
HTTP
AAL 5
ATM
PHY PHY
ATM
PHY
ATM
AAL 5
ATM
PHY
HTTP
Web browser
a) HTTP Nativo
HTTP
AAL 5
ATM
PHY PHY
ATM
PHY
ATM
AAL 5
ATM
PHY
b) HTTP/TCP/IP sobre ATM
TCP
IP
LLC/SNAP
HTTP
TCP
IP
LLC/SNAP
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
132
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.
Switch ATM Switch ATM
AAL 5
ATM
PHY PHY
ATM
PHY
ATM
AAL 5
ATM
PHY
Media Stream
RTP
Gateway H.323-H.323
H.323
Gateway H.323-H.323
H.323
C/D
Media Stream
RTPC/D
Figura 5.3 –Cenário Multimídia em Tempo Real sobre ATM.
133
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.
134
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
135
(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.
136
FrameI
Frame 3
FrameB
FrameB
6 PADFluxo Elementar dePacotes (PES)
Fluxo de VídeoElementar(unidades deacesso)
Fluxo de Vídeo NãoComprimido
(unidades deapresentação)
Fluxo de Transporte(TS)
2 Pacotes TS
AAL CPCS-PDU
8 Células ATM
MPEG
ATM
Frame 2Frame 1
FrameI PAD
6
188
4 FrameI
6
4
188
4 FrameI4
8 TS 1
5 8 TS 1
5 TS 2
384
8 TS 2
TS 1
TS 2
5
5
a)
Fluxo de Transporte(TS)
8 Pacotes TS
6
40
4 FrameI4
40
FrameI
TS 1
TS 8
64 FrameI88
48
55 64 FrameI8
53
88 FrameI
55 8 FrameI
AAL CPCS-PDUs
8 Células ATM
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 maxt , 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
137
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 TSN . 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 prevt∆ prévio. Se ele for menor, o seu valor é
salvo em uma variável mint∆ e a variável prev
t∆ é configurada com o seu valor. Estas variáveis são
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).
138
Cria TransportStream MPEG
End
Fim do laço
Carrega
maxtt <
f
8ff =
6+= fPES
PES_PAD = 184 - PES mod 184
184_ PADPESPESNTS
+=
TSt N
FP=∆
prevtt ∆<∆ tt ∆=∆min
Enquanto
tprevt ∆=∆
0=t FPT =
Tt =
é par ?TSN
P
I
Não
Sim
Sim
Não
IP
2TSNk <Enquanto
Fim do laço
ttt ∆+= .2
FPTT +=
12
+< TSNkEnquanto
Fim do laço
ttt ∆+= .2
Se
Não
2TSNk =
Sim
8<iEnquanto
Salva CPCS-PDU de 40bytes no instante
4. ti
t∆
+
Fim do laço
1+= kk
1+= ii
8<iEnquanto
Salva CPCS-PDU de 40bytes no instante
4. tit ∆+
Fim do laço
1+= ii
5<iEnquanto
Salva CPCS-PDU de 40bytes no instante
5. tit ∆+
Fim do laço
1+= ii
- Tempo principaltT - Tempo de inicio de cada frame
- Período dos framesFP- Tempo final da seqüênciamaxt- Tamanho de um frame MPEGf- Tamanho de um pacote PESPES
PADPES _ - Tamanho do PAD do pacote PES- Número de pacotes de TSTSN- Intervalo de tempo entre pacotes TSt∆
- Intervalo de tempo entre pacotes TS do frameanterior
prevt∆
- Intervalo de tempo mínimo entre pacotes TSmint∆
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 0=k até:
2TSNk < .
139
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é 8<i . 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 t∆.2 .
No caso de um número de pacotes TS impar, é executado um laço de 0=k até:
12
+< TSNk .
Quando 2TSNk = , a invés do laço mais interno ser executado de i = 0 até 8<i , ele é
executado de i = 0 até 5<i , 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).
140
0 500 1000 1500 2000 2500 3000 35000
2,0004,0006,0008,000
10,00012,00014,000
Fra
me
Size
(bits
)
24.5 24.6 24.7 24.8 24.9 25.0 25.1 25.2 25.3 25.4 25.50.0
5.0k
10.0k
Tempo (segundos)
Fram
e Si
ze (b
its)
Figura 5.6 – Seqüência de tamanho de frame MPEG.
24.5 24.6 24.7 24.8 24.9 25.0 25.1 25.2 25.3 25.4 25.50
20
40
AAL
-SD
Us
(byt
es)
24.70 24.75 24.80 24.85 24.90
0
20
40
AAL
-SD
Us
(byt
es)
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:
141
� 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.
142
Categorias de Serviço Atributos
CBR rt-VBR nrt-VBR ABR GFR UBR PCR Especificado.4 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
MFS
Não se aplica. Não se aplica. Não se aplica. Não se aplica. Especificado. Não se aplica.
CLR De acordo.6 De acordo. De acordo. Não considerado. Não
considerado.
Não considerado.
Max-CTD De acordo. De acordo. Não considerado.7 Não considerado. Não
considerado.
Não considerado.
P2P-CDV De acordo. De acordo. Não considerado. Não considerado. Não
considerado.
Não considerado.
Tabela 5.1 – Parâmetros de QoS e descritores de tráfego para as categorias de serviço ATM. Fonte [7].
Definição de Conformidade
Categorias de Serviço
Fluxo PCR
Fluxo SCR
Fluxo MCR
Ação sobre células não conformes
CLR Max-CTD P2P-CDV
CBR.1 CBR 0+18 Não se
aplica
Não se
aplica Descarta 0+1 0+1
VBR.1 rt-VBR
nrt-VBR 0+1 0+1
Não se
aplica Descarta 0+1 0+1 (rt)
VBR.2 rt-VBR
nrt-VBR 0+1 0
Não se
aplica Descarta 0 0 (rt)
VBR.3 rt-VBR
nrt-VBR 0+1 0
Não se
aplica Marca 0 0 (rt)
ABR.1 ABR 0 Não se
aplica 0 Descarta 0 Não se aplica
GFR.1 GFR 0+1 Não se
aplica 0 Descarta 0 Não se aplica
GFR.2 GFR 0+1 Não se
aplica 0 Marca 0 Não se aplica
UBR.1 UBR 0+1 Não se
aplica
Não se
aplica Descarta
Não se
aplica Não se aplica
UBR.2 UBR 0+1 Não se
aplica
Não se
aplica Marca
Não se
aplica Não se 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.
143
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: 410−≤CLR , 310−≤− CTDMax segundos e 4102 −≤− CDVPP 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.
144
� 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:
ISR 1= (1)
� 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
145
LMBF = (2)
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Fluxo de células
FIFO
Buffer Virtual
Policiador
Taxa deserviço
GCRA Célulasconformes
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Cél
ula
Célulasnão conformes
Limite deocupação
ultrapassado.
Limite deconformidadeultrapassado.
a)
b)
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 I1 estará conforme com um algoritmo CGRA(I, L) se ImL .= e
não estará conforme se ( ) ImL .1−< .
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(0T ,
0T ), seguido de um GCRA(ST ,
0TBT + ),
onde:
CDVTPCR
T == 10
(3)
SCRTS
1= (4)
É importante observar, que devido a restrição PCRCDVTT 10 == , 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:
146
� GCRA(0T ,
0T ) – Neste caso I = L = 0T . Então as únicas soluções possíveis para a equação
ImL .= 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(ST ,
0TBT + ) – Neste caso, STI = e
0TBTL += , com SCRTS 1= . Substituindo I e L na equação
ImL .= teremos:
0TSCRMBFBT −= (5)
Esta expressão oferece um valor de BT que resulta na conformidade do fluxo de tráfego VBR
quando submetido a um algoritmo GCRA(ST ,
0TBT + ). 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 0T pode ser previamente obtido através da
aplicação da proposição 1 no policiador GCRA (0T ,
0T ). Uma vez determinado o valor do BT, o valor
correspondente do MBS pode ser obtido a partir da equação:
10
+
−=
TTBTMBS
S
(6)
Portanto, a partir da equivalência do VB com os policiadores GCRA( 0T , 0T ) e GCRA( ST , 0TBT + )
é 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
147
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.
� 1=MBFSR – Taxa de serviço SR que produz MBF = 1.
� 2=MBFSR – Taxa de serviço SR que produz MBF = 2.
� SR∆ – Módulo da diferença entre o
1=MBFSR e o 2=MBFSR .
� Count – Contador do número de iterações realizadas.
148
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 (maxt ) 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 1=MBFSR 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 2=MBFSR e o SR atual.
Finalmente, se nenhuma destas situações ocorreu anteriormente, um ajuste empírico é feito:
( )MBFSRSRSR log.10
+= (7)
� 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
149
um MBF = 1, a taxa SR é incrementada da metade da diferença entre o 1=MBFSR e o
2=MBFSR .
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 2=MBFSR ,
uma vez que buscamos a taxa 1=MBFSR mínima. Portanto, se um SR anterior já produziu um
MBF = 2, a taxa SR é decrescida da metade da diferença entre o 1=MBFSR e o
2=MBFSR . 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 1=MBFSR e o
2=MBFSR (SR∆ ) for menor que 610− e
o MBF for igual a 1. Então, o par (PCR, CDVT) é obtido a partir das expressões:
SRPCR = e SRCDVT 1= .
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 (ST ,
0TBT + ) 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
(EN ) desejadas, ou de pares (SCR, MBS). O programa então varia o valor da taxa SR de
ENSR 1= até
PCRSR = , 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:
[ ] PCRN
kkSCRE
.1
+= , com 0=k até ENk < . (8)
[ ] [ ] CDVTkSCR
MBFkBT −= (9)
[ ] [ ]
[ ]11 +
−=
CDVTkSCR
kBTkMBS (10)
150
Enquanto FLAG = 0
Estima Par(PCR, CDVT)
0=t 0=NoC
0=NST 0=MBF
Cria evento LÊ_TRÁFEGOpara o instante 0.
Enquanto houver eventose
maxtt ≤
Evento é igual aLÊ_TRÁFEGO? Não
Evento é igual aARMAZENA_CELULA
?
Sim
Evento é igual aREMOVE_CELULA?
Fim do laço
2 31
Não
Sim Sim
0=Count
- Tempo principalt- Taxa de serviço do buffer virtualSR
- Taxa de pico da seqüência de entradaPR- Contador do número de iteraçõesCount- Flag de saída da fase de estimaçãoFLAG- Número de células no buffer virtualNoC- Máximo Número de células no buffer virtualMBF- Tempo de inicio do próximo serviçoNST- Tempo da célula, lido a partir da seq. de entradacellt
CPD - Tempo de processamento de uma célula na AAL
- Taxa de serviço do buffer virtual quando MBF = 11=MBFSR- Taxa de serviço do buffer virtual2=MBFSR01 ==MBFSR
02 ==MBFSR0=∆SR
PRSR =
3
1−= NoCNoC
?0=NoC Desliga servidorSim
Não
SRNSTNST 1+=
Cria eventoREMOVE_CELULA para o
instante NST
Volta
5
e?01 >=MBFSR
?02 ==MBFSRe
?02 >=MBFSR
?01 ==MBFSR
Sim
Não
SRSRMBFSR −=∆ =1
2SRSRSR ∆+=
Sim
SRSRMBFSR −=∆ =2
2SRSRSR ∆−=
Não e?01 ==MBFSR
?02 ==MBFSR
Sim
( )MBFSRSRSR log.10
+=
6
Não
4
7
Figura 5.9 – Estimativa de um par (PCR, CDVT) – Parte I.
151
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
Fim do laço
Fim
1+= CountCount
Não
FLAG = 1Sim
SRPCR =SR
CDVT 1=
?3≥MBF
MBF = 2 ?
Não
MBF = 1 ?
?01 >=MBFSRSim
Sim
Não
Não
MBF = 1e
?10 6−<∆ SR
SRSRMBF ==1
21 == −=∆ MBFMBFSR SRSR
2SRSRSR ∆+=Sim
?02 >=MBFSRSim
SRSRMBF ==2
21 == −=∆ MBFMBFSR SRSR
2SRSRSR ∆−=Sim
200+= SRSR
200−= SRSR
Não
Não
6 6
65
Carrega
Enquanto k < 10
1
Cria eventoARMAZENA_CELULA
para o instante
cellt
cellt
Insere atraso deprocessamento
CPDtt cellcell +=
Fim do laço
Cria evento LÊ_TRÁFEGOpara o instante cellt
Volta
2
1+= NoCNoC
?MBFNoC >
Não
Sim NoCMBF =
Servidor estádesligado ?
Sim
Cria eventoREMOVE_CELULA para o
instante NST
Calcula NST
Volta
Não
4
7
152
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.
0 1 2 3 4 5 6 7 8 9 100
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
Tam
anho
dos
fram
es M
PEG
(byt
es)
Tempo (segundos)
Figura 5.11 – Seqüência de frames MPEG de entrada.
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
0
20
40
Tam
anho
dos
AAL
-SD
Us
(byt
es)
Tempo (segundos)
Figura 5.12 – Seqüência de AAL-SDUs resultante da adaptação dos frames MPEG.
153
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.
0 2 4 6 8 100
1000
2000
3000
4000
5000
6000
7000
Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5
Ocu
paçã
o do
Buf
fer V
irtua
l (cé
lula
s)
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.
154
0 2 4 6 8 100
5
10
15
20
25
30
35
40
45
50 Iteração 1 Iteração 2 Iteração 3 Iteração 4 Iteração 5
Ocu
paçã
o do
Buf
fer V
irtua
l (cé
lula
s)
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.
1 2 3 4 5
0
2000
4000
6000
8000
10000
SR = 9129.664565448795
Service_Rate Buffer_Occupancy Error
Iteração
Figura 5.15 – Convergência do algoritmo de estimação do PCR e do CDVT.
155
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.
156
0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000
0
1000
2000
3000
4000
5000 MBS
MBS
(cél
ulas
)
SCR (células/seg.)
-2
0
2
4
6
8
10
12
14
16
18
BT
(seg
undo
s)
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/
157
[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.
158
Página deixada em branco intencionalmente.
159
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
160
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.
AplicativosFonte
Gerente
Par
que
dos
Din
ossa
uros
Silê
ncio
dos
Inoc
ente
sPr
ogra
ma
deE
ntre
vist
asC
orrid
a de
Fórm
ula
1D
esen
hoAn
imad
o
Terminal FaixaLarga Chaveador Aplicativo
DestinoTerminal Faixa
Larga
Taxa dos enlaces:2048 Kbits/seg.
Taxa da matriz decomutação:
149.76 Mbits/seg.
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
161
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
Descritor Seqüência
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.
162
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 CEBi =φ , 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.
163
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
164
porque neste instante esta célula é que possui o menor itk
F . 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 itk
F 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 kt e do itk
F 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.
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
0.0
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0
10.0
11.0
12.0
13.0
ServiçoConexão 9
ServiçoConexão 4
ServiçoConexão 0
ServiçoConexão 6
0.041001Chegada:1 célula conexão 41 célula conexão 9
0.04Chegada:1 célula por conexão
0.040770231Chegada:1 célula conexão 11 célula conexão 6
ServiçoConexão 1
ServiçoConexão 9
ServiçoConexão 4
BTE_0 - PHY_OUT_QS_0
25/9/2001 11:26:49
i φi CLR4 0.5398547053 5x10-99 0.5398547053 10x10-91 0.2650000200 2x10-96 0.2650000200 7x10-90 0.1984810867 1x10-95 0.1984810867 6x10-93 0.1656250204 4x10-98 0.1656250204 9x10-92 0.1532031455 3x10-97 0.1532031455 8x10-9
Ocu
paçã
o da
Est
rutu
ra d
e Fi
las
(Cél
ulas
)
Tempo (Segundos)
"Q0" B=1000 "Q1" B=1000 "Q2" B=1000 "Q3" B=1000 "Q4" B=1000 "Q5" B=1000 "Q6" B=1000 "Q7" B=1000 "Q8" B=1000 "Q9" B=1000 "Qt" B=1000
Figura 6.2 – Ocupação da estrutura de filas do BTE_0 para o modelo de escalonador WF2Q.
kt 1−kt ∑ iφkt
V itk
F1−
itk
S iφ itk
F 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
165
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.
166
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.
167
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
168
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.
169
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.
170
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.
171
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.
172
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
173
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.
174
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.
175
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.
176
Figura 6.11 – CLR na estrutura de filas do BTE_0 com capacidade de 100 células para ambos os modelos de
escalonadores.
177
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
178
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
179
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.
180
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.
181
Figura 6.15 – CLR médio na estrutura de filas do BTE_0 para os dois modelos de escalonadores.
182
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
183
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 do Enlace:2415.09 células/seg.
Taxa por Porta daSwitch Fabric:
353207.54 células/seg.
TerminalFaixaLarga
AplicativoFonte
Comutador TerminalFaixa Larga
AplicativoReceptor
Gerente
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
184
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
Descritor Seqüência
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).
185
� 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.
186
� 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.
187
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.
188
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.
Servidor NVoD Switch ATM
Filme 1
Filme 2
Filme N
Cliente
Adaptação de Rede
MPEG
MPEG SPTS
AAL 5
ATM
PHY PHY
ATM
AAL 5
ATM
PHY
MPEG
MPEG SPTS
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.
189
Figura 6.23 – Cenário NVoD MPEG-4 sobre ATM utilizando o Conjunto de Modelos no Nível de Células.
BTE_0
Camada de Adaptação ATM
Camada ATM
Camada Física deEntrada
Camada Física deSaída
Estrutura de Fila
Escalonador
Controle deAdmissão de
Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivo deCélulas
Camada ATM
Camada Física deEntrada
Switch_0
Estrutura de Fila
Camada Física deSaída
Escalonador
Estrutura de Fila
Escalonador
Estrutura de Fila
Escalonador
Escalonador
Controle de Admissão deConexões
Gerencimento deEstrutura de Filas
Descarte Seletivo deCélulas
Controle de Admissão deConexões
Gerencimento deEstrutura de Filas
Descarte Seletivo deCélulas
Controle deAdmissão de
Conexões
Gerencimento deEstrutura de Filas
Descarte Seletivo deCélulas
Camada Criadora de Conexões
App_0 até App_24
Camada Fonte de Tráfego
Camada Receptora de Tráfego
Camada Removedora de Conexões
Manager_0
PHY_OUT_S_0
PHY_OUT_QS_0
PHY_OUT_CAC_0
PHY_OUT_BM_0
PHY_OUT_SD_0
Matriz deComutação com
MemóriaCompartilhada
BTE_1
Camada de Adaptação ATM
Camada ATM
Camada Física deEntrada
Camada Física deSaída
Estrutura de Fila
Escalonador
Controle de Admissão deConexões
Gerencimento deEstrutura de Filas
Descarte Seletivo deCélulas
App_25
Camada Removedora de Conexões
Camada Receptora de Tráfego
PacotesMPEG-4
CélulasATM
CélulasATM
Policiamento PHY_OUT_TP_0 Policiamento Policiamento
Policiamento
Policiamento
ATM_OUT_QS_S
ATM_OUT_CAC_S
ATM_OUT_BM_S
ATM_OUT_SD_S
ATM_OUT_S_0
ATM_OUT_S_1
Camadas Caminho percorridopelas células ATM
Gerenciadores deTráfego
PacotesMPEG-4
ATM_OUT_TP_S
QS - QueuingStructure S - Scheduler CAC - Connection
Admission ControlBM - BufferManagement
SD - SelectiveDiscard
TP - TrafficPolicie
Figura 6.24 – Visão detalhada do cenário NVoD MPEG-4 sobre ATM utilizando o CMNC.
190
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
191
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.
192
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.
193
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
Descritor Seqüência 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.
194
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
195
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).
196
� 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).
5 10 15 20 2510-4
10-3
10-2
10-1
100
CLR
Carga (Número de Aplicativos)
CLR0 CLR1 CLR2 CLR3 CLR4 CLR5 CLR6 CLR7 CLR8 CLR9 CLR10 CLR11 CLR12 CLR13 CLR14 CLR15 CLR16 CLR17 CLR18 CLR19 CLR20 CLR21 CLR22 CLR23 CLR24
5 10 15 20 2510-4
10-3
10-2
10-1
100
9/10/2001 09:21:58
Escalonador VSEscalonador LFVC
Escalonador WF2QEscalonador Default
CLR
Carga (Número de Aplicativos)
CLR0 CLR1 CLR2 CLR3 CLR4 CLR5 CLR6 CLR7 CLR8 CLR9 CLR10 CLR11 CLR12 CLR13 CLR14 CLR15 CLR16 CLR17 CLR18 CLR19 CLR20 CLR21 CLR22 CLR23 CLR24
5 10 15 20 2510-4
10-3
10-2
10-1
100
CLR
Carga (Número de Aplicativos)
CLR0 CLR1 CLR2 CLR3 CLR4 CLR5 CLR6 CLR7 CLR8 CLR9 CLR10 CLR11 CLR12 CLR13 CLR14 CLR15 CLR16 CLR17 CLR18 CLR19 CLR20 CLR21 CLR22 CLR23 CLR24
5 10 15 20 2510-4
10-3
10-2
10-1
100
CLR
Carga (Número de Aplicativos)
CLR0 CLR1 CLR2 CLR3 CLR4 CLR5 CLR6 CLR7 CLR8 CLR9 CLR10 CLR11 CLR12 CLR13 CLR14 CLR15 CLR16 CLR17 CLR18 CLR19 CLR20 CLR21 CLR22 CLR23 CLR24
Variável deresultado
Variavél deresultado para
a conexão i Z=0 Z=1
Z=3Z=2
U=0 U=1 U=2 U=3 U=4
Configuração de modelos de 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)
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.
197
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
0 × × × × ×
1 × × × × × × × × × ×
2 × × × × × × × × × × × × × × ×
3 × × × × × × × × × × × × × × × × × × × ×
U
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.
198
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).
199
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)
200
Figura 6.28 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(1)(Z).
201
Figura 6.29 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(1)(Z).
202
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).
203
Figura 6.31 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(0)(Z).
204
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).
205
Figura 6.33 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(1)(Z).
206
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).
207
Figura 6.35 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(0)(Z).
208
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).
209
Figura 6.37 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(1)(Z).
210
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).
211
Figura 6.39 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(0)(Z).
212
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).
213
Figura 6.41 – Ocupação da estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(1)(Z).
214
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.
215
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).
216
Figura 6.43 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(0)(Z).
217
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).
218
Figura 6.45 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(1)(Z).
219
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).
220
Figura 6.47 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(0)(Z).
221
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).
222
Figura 6.49 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(1)(1)(Z).
223
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).
224
Figura 6.51 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(0)(Z).
225
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).
226
Figura 6.53 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(2)(1)(Z).
227
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).
228
Figura 6.55 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(0)(Z).
229
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).
230
Figura 6.57 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(3)(1)(Z).
231
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;
232
• 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.
233
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).
234
Figura 6.59 – CLR na camada física de saída do BTE_0 para as configurações (U)(0)(0)(Z).
235
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).
236
Figura 6.61 – CLR na camada física de saída do BTE_0 para as configurações (U)(0)(1)(Z).
237
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).
238
Figura 6.63 – CLR na camada física de saída do BTE_0 para as configurações (U)(1)(0)(Z).
239
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).
240
Figura 6.65 – CLR na camada física de saída do BTE_0 para as configurações (U)(1)(1)(Z).
241
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).
242
Figura 6.67 – CLR na camada física de saída do BTE_0 para as configurações (U)(2)(0)(Z).
243
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).
244
Figura 6.69 – CLR na camada física de saída do BTE_0 para as configurações (U)(2)(1)(Z).
245
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).
246
Figura 6.71 – CLR na camada física de saída do BTE_0 para as configurações (U)(3)(0)(Z).
247
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).
248
Figura 6.73 – CLR na camada física de saída do BTE_0 para as configurações (U)(3)(1)(Z).
249
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.
250
Página deixada em branco intencionalmente.
263
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).
264
Kernel
Executor deEventos
Fila com Prioridades
Even
to
Even
to
Even
to
Even
to
Even
to
Gerenciador deEventos
Interpretador deComandos
Gerenciador deModelos
Cria
e D
elet
a M
odel
os
Ativ
a
Ativa
Executa Comandos
ArmazenaEventos
Des
cobr
eD
estin
o
RodaEventos
Objetos
Carre
ga D
LL´s
Biblioteca deModelos
Modelo 1
Modelo 2
Modelo 3
Modelo N
Rede
Conexão 1
Conexão N
Conexões de Blocos
Conexão 1
Conexão N
Conexões de Rede
Conexão 1
Conexão N
Conexões de Dados
RelógioAuxiliar
Gerenciador deArquivos
Gerenciador deMensagens
Gerenciador deParâmetros
Gerenciador deConexões
Usuários
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
265
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.
266
� 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.
Lê Comando
Retorna
Inicio
Configuração
Interpretação deComandos
Fim
Executa Comando
Interpretação deComandosInicio
Configuração
Interpretação deComandos
Fim
Leitura de ArquivosScript
a) Funcionamento via linhade comandos
b) Funcionamento viaarquivo script
c) Interpretação decomandos
Criação Criação
Figura 2 – Fluxogramas de funcionamento do kernel.
267
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)
268
� 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.
KernelFunções de
Interfaceamento(a)
Programa Executável(.exe)
ModeloFunções de
Comportamento(b)
Biblioteca deModelos
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
269
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.
270
Inicio
Fila comprioridades está
vazia?
Estadode execução é
diferentede 3?
Fila com prioridadesnão está vazia, o tempode simulação é menorque o tempo final desimulação e o estadode execução é igual a
1?
Retorna
Retira evento da filacom prioridades
Atualiza tempo desimulação para o
tempo de execução doevento
Envia evento para omodelo de destino econfigura código deerro, se necessário.
Códigode erro é diferente
de 0?
Códigode erro e estado de
execuçãosão = 0?
Códigode erro = 0 e
estado de exec.= 1?
Não
Sim
Sim
Não
Sim
Não
Códigode erro é diferente
de 0 ?
FimSim
Aciona fase de ResetNão
Sim
Sim
Sim
Não
Executa fase OnStopidentificando parada de
simulação.
Executa fasePosprocessing Executa fase de Reset
Seta estado deexecução = 0
Executa fasePosprocessing
Executa fase OnStopidentificando erro na
execução.
Executa fasePosprocessing
Executa fase de Reset
Não
Não
Estado deexecução = 3?
Aciona fase de Reset
Sim
Fim
Finalização da Simulação e Tratamento de Erros Execução de Eventos
Não
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
271
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)
272
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.
273
Criação
Configuração
Interpretação deComandos
Criação de Modelo
Estabelecimento deConexão de Blocos
Desestabelecimentode Conexão de Blocos
Estabelecimento deConexão de Rede
Desestabelecimentode Conexão de Rede
Estabelecimento deConexão de Dados
Desestabelecimentode Conexão de Dados
Inicialização Tratamento de Erros deIncialização
Execução daSimulação
Tratamento de Paradade Simulação
Pós-Procesamento
Finalização
Primeira FaseCriação dosModelos
Segunda FaseEstabelecimentode Conexões
Terceira FaseExecução daSimulação
Quarta FaseFinalização
Leitura de ArquivoScript
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.
274
auxiliar
stimer
library
netconnection
layer
kernel
eventmng dispatcher
dataconnection
connection
command squeue
block
Classes Base paraConstrução de Modelos
Classes paraRepresentaçã
o dasConexões da
Simulação
Classes Internasdo Kernel
Classes Para Controle dosEventos
Classes que Desempenham as Funções doKernel
Classes Controladas Pelo Kernel
Param
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.
275
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.
276
Conexão de Dados 1
connection
netconnection
dataconnection
Conexão de Rede 1 Conexão de Rede 2
Conexão Blocos 3
Modelo 1(.dll)
Modelo 2(.dll)
Modelo 3(.dll)
Modelo 4(.dll)CB1 CB2 CB3 Modelo 5
(.dll)CB4
CR1CR2
CD1
Conexão Blocos 3
Conexão Blocos 2Conexão Blocos 2
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.
Modelo 1(.dll)
Modelo 2(.dll)
Modelo 3(.dll)
Modelo 4(.dll)CB1 CB2 CB3 Modelo 5
(.dll)CB4
CR1CR2
CD1
Figura 8 – Remoção de conexões no Hydragyrum.
277
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.
Modelo deAplicativo
(.dll)
Modelo deTerminal
(.dll)
Modelo deChaveador
(.dll)
Modelo deTerminal
(.dll)CB1 CB2 CB3
Modelo deAplicativo
(.dll)CB4
Conexão ATM 2Conexão ATM 1
Conexão de Dados Multímidia
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.
278
� 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).
279
� 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.
Time Token Type SourceBlock
DestinationBlock
SourceLayer
or Squeue
DestinationLayer orSqueue
Message NetworkConnection
DataConnection
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.
280
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
Camada 1
Camada n
Camadas
Gerenciador 1
Gerenciador n
Gerenciadores de Tráfego
Conexão 1
Conexão n
Conexões de Blocos
Conexão 1
Conexão n
Conexões de Rede
Conexão 1
Conexão n
Conexões de Dados
Gerenciador deMensagens de Erro e
de Advertência
Gerenciador deCompatibilidade
Gerenciador deArquivos de Saída
Gerenciador deLigação Dinâmica
Gerenciador deIdentificação Gerenciador Gráfico
Gerenciador deConexões
Gerenciador deModelos Gerenciador de Simulação
Gerenciador deTabela de Dados
Gerenciador deParâmetros
Figura 12 – Estrutura de um bloco do Hydragyrum.
A.2.1.2 - Módulos Funcionais
281
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.
282
� 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:
283
� 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.
284
É 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
285
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.
block
new_model
ClasseBase
ClasseBase
ClasseDerivada
NovoBloco
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).
286
� 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.
Segundo Passo:Construir Novos Objetos
Terceiro Passo:Implementar Funções deComportamento
new_model.hDeclaração das
Funções deComportamento
new_model.cppImplementaçãodas Funções deComportamento
new_model.obj
Com
pila
r
Quarto Passo:Compilar Novos Objetos
new_model.dll
Liga
r
kernel.dllQuinto Passo:Ligar Novos Objetos
project.ide
PrimeiroPasso:Criar um NovoProjeto.
Testar Testar
Sexto Passo:Testar naInterface emLinha deComando Sétimo Passo:
Testar naInterfaceGráfica
Figura 14 – Passos necessários para desenvolver um novo bloco para o Hydragyrum.
287
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
Conexão 1
Conexão n
Conexões de Blocos
Conexão 1
Conexão n
Conexões de Rede
Conexão 1
Conexão n
Conexões de Dados
Gerenciador deMensagens de Erro e
de Advertência
Gerenciador de Arquivos de Saída
Gerenciador deConexões Gerenciador de Simulação
Gerenciador deTabela de Dados
Gerenciador deParâmetros
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.
288
� 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.
289
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
290
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.
layer
new_model
ClasseBase
ClasseBase
ClasseDerivada
NovaCamada
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.
291
Gerenciador de Tráfego
Conexão 1
Conexão n
Conexões de Blocos
Conexão 1
Conexão n
Conexões de Rede
Conexão 1
Conexão n
Conexões de Dados
Gerenciador deMensagens de Erro e
de Advertência
Gerenciador deArquivos de Saída
Gerenciador deConexões Gerenciador de Simulação
Gerenciador deTabela de Dados
Gerenciador deParâmetros
Gerenciador deArmazenamento e
Remoção de Mensagens
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.
292
[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.