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.3 - Camadas Fontes de Tráfego.......................................................................................................................62


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.2 - Camada ATM do Comutador.............................................................................................................................. 66


4.6.7 - Camadas Físicas ........................................................................................................................................69

4.6.7.1 - Camada Física de Entrada ................................................................................................................................... 70


4.6.7.2 - Camada Física de Saída....................................................................................................................................... 71


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.2 - Estrutura de Filas com Fila por Conexão ............................................................................................................ 75


4.7.2 - Escalonadores (Schedulers) .......................................................................................................................76 4.7.2.1 - Escalonador Default ............................................................................................................................................ 78


4.7.2.2 - Escalonador de Pacotes com Compartilhamento de Processador Generalizado.................................................. 78


4.7.2.3 - Escalonador Regulador de Tráfego Virtual Scheduling ...................................................................................... 80


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.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.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.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.2 - Algoritmo de Descarte Seletivo de Células Baseado no CLP ........................................................................... 108


4.7.5.3 - Algoritmo de Descarte Seletivo de Células Baseado no CLR........................................................................... 109


4.7.6 - Algoritmos de Policiamento de Tráfego..................................................................................................109

4.7.6.1 - Policiador Leaky Bucket ................................................................................................................................... 110


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.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.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






CAPACIDADE DE 50 CÉLULAS (B=3)................................................................................................................................................................ 210



6.4.4.2 - Atraso Médio por Conexão ............................................................................................................................... 214













6.4.4.3 - CLR Médio por Conexão .................................................................................................................................. 231














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


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


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


FIGURA 6.10 – NÚMERO DE CÉLULAS PERDIDAS NA ESTRUTURA DE FILAS DO BTE_0 COM CAPACIDADE DE 50


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


(U)(0)(0)(Z)...........................................................................................................................................199


(U)(0)(1)(Z)...........................................................................................................................................200


(U)(0)(1)(Z)...........................................................................................................................................201


(U)(1)(0)(Z)...........................................................................................................................................202


(U)(1)(0)(Z)...........................................................................................................................................203


(U)(1)(1)(Z)...........................................................................................................................................204


(U)(1)(1)(Z)...........................................................................................................................................205


(U)(2)(0)(Z)...........................................................................................................................................206


(U)(2)(0)(Z)...........................................................................................................................................207

xviii


(U)(2)(1)(Z)...........................................................................................................................................208


(U)(2)(1)(Z)...........................................................................................................................................209


(U)(3)(0)(Z)...........................................................................................................................................210


(U)(3)(0)(Z)...........................................................................................................................................211


(U)(3)(1)(Z)...........................................................................................................................................212


(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


(U)(0)(0)(Z)...........................................................................................................................................216


(U)(0)(1)(Z)...........................................................................................................................................217


(U)(0)(1)(Z)...........................................................................................................................................218


(U)(1)(0)(Z)...........................................................................................................................................219


(U)(1)(0)(Z)...........................................................................................................................................220


(U)(1)(1)(Z)...........................................................................................................................................221


(U)(1)(1)(Z)...........................................................................................................................................222


(U)(2)(0)(Z)...........................................................................................................................................223


(U)(2)(0)(Z)...........................................................................................................................................224

xix


(U)(2)(1)(Z)...........................................................................................................................................225


(U)(2)(1)(Z)...........................................................................................................................................226


(U)(3)(0)(Z)...........................................................................................................................................227


(U)(3)(0)(Z)...........................................................................................................................................228


(U)(3)(1)(Z)...........................................................................................................................................229


(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 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.5 – PESOS E CLR PARA CADA CONEXÃO. ......................................................................................................185


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.


[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.


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.


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.


[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/




[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/


1997.

42


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


Comutador

Estrutura de Fila


Escalonador

Estrutura de Fila

Escalonador

Estrutura de Fila

Escalonador

Escalonador










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



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


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


Ponteiropara uma

Célula


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.



dinâmica. Isto permite que a célula seja deletada e removida da lista de células do


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



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.


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.



dinâmica. Isto permite que a mensagem de gerenciamento de tráfego seja deletada pelo


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.


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.


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.


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.


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.


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




Célula provenienteda PHY_IN.

Célula destinadaa PHY_OUT.


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.


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.


habilitado?


serem descartadas.

Célularecebida

foi deletada?


Célula recebida foideletada?

Sim

Não

Não

Não

Fim


aceitou a célula?


Sim


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)


Estrutura de Fila

Escalonador




CamadaFísica


Figura 4.19 – Iteração entre a camada PHY_IN e os demais gerenciadores de tráfego do bloco comutador.


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.


habilitado?


serem descartadas.

Célularecebida

foi deletada?


Célula recebida foideletada?

Sim

Não

Não

Não

Fim


aceitou a célula?


Sim


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


Estrutura de Fila

Escalonador





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.


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.


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


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.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.


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.


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.


O gerenciador de tráfego PGSP_Scheduler possui quatro amostragens estatísticas: três







� 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


� Espaçador D – Modela um algoritmo Dual Virtual Scheduling para a definição de


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?


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


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?


Não

Sim

End


Recebe uma célula






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?


Não

Sim

End


Recebe uma célula






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.


O gerenciador de tráfego VS_TS_Scheduler possui três amostragens estatísticas: duas






85


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.


O gerenciador de tráfego WF2Q_Scheduler possui quatro amostragens estatísticas: três







� 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


τ

- 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


τ

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.


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:





� 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.


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.


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.


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.


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.


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.


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.


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


� Policiador C – Modela um algoritmo Dual Leaky Bucket para a definição de


� Policiador D – Modela um algoritmo Dual Leaky Bucket para a definição de


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


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


LCT=Time

CLP = 1?

Sim

Sim

LCTs = 0 ?

LCTs=Time

Não

Sim


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).


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.


Aplicativo Determinístico

Camada Fte de Tráfego Determinístico



Figura 4.39 – Estrutura do aplicativo determinístico.

4.8.1.2 - Aplicativo Poissoniano

O modelo Poissonian_App – Poissonian Application possui uma camada

fonte de tráfego poissoniana. A Figura 4.40 ilustra a estrutura do aplicativo

poissoniano.


Aplicativo Poissoniano

Camada Fonte de Tráfego Poissoniano



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.


Aplicativo Externo

Camada Fonte de Tráfego Externo



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



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.



Camada ATM



Estrutura de Fila

Escalonador




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


Comutador

Estrutura de Fila


Escalonador

Estrutura de Fila

Escalonador

Estrutura de Fila

Escalonador

Escalonador










Porta

de

Saíd

a

Porta

de

Entra

da

CamadaFísica

CamadaATM

Estruturas de Filas

Escalonadores



Descarte Seletivo

Camadas Físicas

Camada ATM

Modelos Internos

Escalonadores



Descarte Seletivo


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 ATM



Estrutura de Fila

Escalonador




Camada ATM


Comutador (Switch_0)

Estrutura de Fila


Escalonador

Estrutura de Fila

Escalonador

Estrutura de Fila

Escalonador

Escalonador











Aplicativo Fonte (App_0)




Gerente(Manager_0)



BTE Egresso (BTE_2)


Camada ATM



Estrutura de Fila

Escalonador




Aplicativo Destino (App_4)



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.



Camada ATM



Estrutura de Fila

Escalonador




Camada ATM


Comutador

Estrutura de Fila


Escalonador

Estrutura de Fila

Escalonador

Estrutura de Fila

Escalonador

Escalonador











Aplicativo




Gerente






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



Descarte Seletivo

Camadas Físicas

Camada ATM

Escalonadores

CamadaFísica

CamadaATM

Estruturas 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.


[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.


Simulation, agosto 1997.


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.



[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


4. tit ∆+

Fim do laço

1+= ii

5<iEnquanto


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.


[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.



[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


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


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


175

Figura 6.10 – Número de células perdidas na estrutura de filas do BTE_0 com capacidade de 50 células para


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.


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.



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


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 ATM



Estrutura de Fila

Escalonador

Controle deAdmissão de

Conexões


Descarte Seletivo deCélulas

Camada ATM


Switch_0

Estrutura de Fila


Escalonador

Estrutura de Fila

Escalonador

Estrutura de Fila

Escalonador

Escalonador

Controle de Admissão deConexões






Controle deAdmissão de

Conexões



Camada Criadora de Conexões

App_0 até App_24



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



BTE_1


Camada ATM



Estrutura de Fila

Escalonador




App_25

Camada Removedora de Conexões


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).


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.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.


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


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



5 10 15 20 2510-4

10-3

10-2

10-1

100

CLR



5 10 15 20 2510-4

10-3

10-2

10-1

100

CLR



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


Modelo de CAC Elwalid, de BM com Particionamento Dinâmico e de SD baseado no CLR (V=1)

200


201


202




203


204



205


206




207


208



209


210




211


212



213


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



Figura 6.42 – Atraso na estrutura de filas PHY_OUT_QS_0 do BTE_0 para as configurações (U)(0)(0)(Z).

216


217



218


219




220


221



222


223




224


225



226


227




228


229



230


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



Figura 6.58 – CLR na camada física de saída do BTE_0 para as configurações (U)(0)(0)(Z).

234


235



236


237




238


239



240


241




242


243



244


245




246


247



248


249


[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


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


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


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)


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


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


Figura 12 – Estrutura de um bloco do Hydragyrum.


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 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.


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


de Advertência

Gerenciador de Arquivos de Saída

Gerenciador deConexões Gerenciador de Simulação



Figura 15 – Estrutura de uma camada do Hydragyrum.


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.



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 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


de Advertência

Gerenciador deArquivos de Saída

Gerenciador deConexões Gerenciador de Simulação



Gerenciador deArmazenamento e

Remoção de Mensagens

Figura 17 – Estrutura de um gerenciador de tráfego do Hydragyrum.


A gerenciador de tráfego do Hydragyrum possui os mesmos módulos funcionais que a

camada.


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.


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.




[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.

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

Documents

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