CURSO DE ESPECIALIZACÃO EM CONFIGURAÇÃO E GERENCIAMENTO DE SERVIDORES E EQUIPAMENTOS DE REDES
GEROLINO MOURA
ESTUDO REFERENTE AOS FUNDAMENTOS DE ARQUITETURAS QoS
MONOGRAFIA
CURITIBA 2011
ESTUDO REFERENTE AOS FUNDAMENTOS DE ARQUITETURAS QoS
Monografia apresentada como requisito parcial para obtenção do grau de especialista em Configuração e Gerenciamento de Servidores e Equipamentos de Redes, do Departamento Acadêmico de Eletrônica da Universidade Tecnológica Federal do Paraná.
Orientador: Prof. Dr. Kleber Kendy Horikawa Nabas
CURITIBA 2011
Moura ,Gerolino. Estudo referente aos fundamentos de arquiteturas QoS 2011. 37 f, Monografia (Especialização em Configuração e Gerenciamento de Servidores e Equipamentos de Redes). Universidade Tecnológica Federal do Paraná. Curitiba, 2011.
Este estudo é referente aos princípios que fundamentam as arquiteturas QoS, qualidade de serviços em redes de dados , descrevendo princípios e parâmetros exigidos para a garantia de serviços de dados e multimídia entre equipamentos de redes .O trabalho mostra a forma como os elementos da arquitetura interagem com as camadas do modelo OSI , considerando que a arquitetura QoS trabalha em conjunto com os protocolos de redes existentes mas com objetivo de garantir qualidade seja entrega correta de pacotes em tempo hábil como evitar taxas altas de erro desde a origem ao equipamento final.Cita e comenta modelos que deram origem às arquiteturas atuais desenvolvido algumas empresas e universidades na primeira metade da década de 90.
1. Principios QoS... 05
1.1 Princípio da Integração... 06
1.2- Princípio de Separação... 07
1.3 Princípios da Transparência... 07
1.4 Princípios de Gerenciamento de Recurso Assíncrono... 08
1.5 Principio do Desempenho... 08
2. Especificações QoS... 08
2.2 Especificação de Sincronização de fluxo ("Orquestração")...09
2.3. Especificação de Desempenho de Vazão... 09
2.4 Compromisso QoS... 10
2.5 Política de gestão de QoS...10
2.6 Custo do Serviço... 10 2.7 Mecanismos de QoS... 11 2.8 Provisão de QoS... 11 2.9 Mapeamento de QoS... 12 2.10 Teste de Admissão... 12 2.11 Reserva de Recursos... 13 3.1 Formador de Fluxo... 13 3.2 Agendamento de Fluxo... 14
3.3 Monitoramento de Fluxo (FLOW POLICING)...14
3.4 Controle de Fluxo... 14 3.5 Sincronização de fluxo... 15 3.6 Gerenciamento de QoS...15 3.7 Monitoramento QoS... 16 3.8 Manutenção de QoS... 16 3.9 Degradação de QoS... 16 3.10 Sinalização QoS... 17 3.11 Escala de QoS... 17 4.1 Padroes de QoS... 18
4.2 Interconexão de Sistemas Abertos... 18
5 FORUM ITU-TS e ATM ... 21
5.1 IETF int-serv e Grupos de RSVP... 22
6. ARQUITETURAS QoS EMERGENTES , decada de 90... 25.
6.1 A Universidade Columbia Extended Modelo de Referência Integrada XRM-... ... 26
6.2- FRAMEWORK QOS OSI... ... 31
6.3- Arquitetura OMEGA ,UNIVERSIDADE DA PENSILVANIA... 33
7- Conclusão... ... 35
1. PRINCIPIOS QoS
Cinco princípios governam a construção de arquiteturas QoS. Estes princípios são integração, separação, transparência, gerenciamento de recurso assíncrono e desempenho.
1.1 Princípio da Integração
O principio da integração estabelece que a qualidade de serviço deve ser configurável, previsível e passível de manutenção em todas as camadas da arquitetura QoS para atender a qualidade de serviço fim-a-fim. Módulos de serviço QoS dos fluxos que atravessam a CPU, memória, dispositivos e rede em cada camada dos dispositivos de origem, fluem para baixo através da pilha de protocolo de origem pela rede, sobem através da pilha de protocolos para o dispositivo final. Cada módulo percorrido deve prover qualidade serviço configurável (com base na especificação QoS), garantia de recursos, fornecido por mecanismos de controle QoS e manutenção com base em mecanismos de monitoramento de fluxos em tempo real.
1.2- Princípio de Separação.
O principio da separação estabelece que o meio de transferência, controle e gerenciamento são funcionalmente distintos de atividades da arquitetura. O principio estabelece que estas atividades devem ser separadas da arquitetura framework. Um aspecto da separação e a distinção entre sinalização e meio de transferência. Fluxos, que são isócronos por natureza, geralmente requerem uma ampla variedade banda larga, baixa latência, serviços sem garantia com alguma forma de correção de jitter em dispositivos finais. Por outro lado, a sinalização, que é full duplex é mais assíncrona por natureza, geralmente requer baixa largura de banda e serviço do tipo assegurado sem restrição de jitter.
O princípio da transparência estabelece que as aplicações devem ser blindadas da complexidade da especificação QoS subjacente e funções de gerenciamento QoS tais como monitoramento e manutenção QoS. Um aspecto importante da transparência é a API QoS em que os níveis de qualidade de serviço são estabelecidos. O benefício da transparência é triplo. Ela reduz a necessidade de funcionalidade qualidade serviço embutida em aplicações. Esconde os detalhes de especificação de serviço subjacente da aplicação e atribui a complexidade de manipular atividades de gerenciamento ao framework(quadro) QoS subjacente.
1.4 Princípios de Gerenciamento de Recurso Assíncrono
O Princípio de Gerenciamento de Recurso Assíncrono orienta a divisão de funcionalidade entre módulos da arquitetura e pertence aos mecanismos de modelamento de controle e gerenciamento. Isto em virtude de reflexo de restrições de tempo que acontece em paralelo às atividades como agendamento, fluxo de controle, roteamento, gerenciamento QoS, em ambientes de comunicação distribuída. O status do sistema de comunicação distribuído é estruturado de acordo com estas diferentes escalas de tempo. O ponto de operação das atividades de comunicação é atingido através de algoritmos assíncronos que funcionam e trocam dados de controle periodicamente entre si.
1.5 Principio do Desempenho
O Principio do desempenho implementa um número amplo de regras estabelecidas para implementação e projeto de comunicação com princípios QoS. Estas regras orientam a divisão de funcionalidade na estruturação de comunicação para alto desempenho de acordo com princípios de projetos de sistemas Saltzer[Saltzer,84], revogação de multiplexação, recomendações para estruturação de protocolos de comunicação como divisão de frames da camada de aplicação e processamento de camada que integra o hardware
assistidos por protocolos de processamento.
2 Especificações QoS
A especificação QoS se preocupa em capturar requisitos em nível de aplicação dos requisitos de qualidade de serviço e política de gestão ,que geralmente é diferente em cada camada do sistema e é usado para configurar e manter mecanismos de QoS residente em cada camada. Em nível sistema de plataforma distribuída a especificação de QoS é orientada ao usuário , ao invés de ser orientada a sistema. Considerações em baixo nível, tais como sincronização cerrada de múltiplos fluxos de transporte relacionados à taxa e tamanho das rajadas de fluxos ou os detalhes de agendamento de segmento devem ser todos escondidos,a este nível.
A especificação QoS é, de natureza declarativa ou seja os usuários especificam o que é necessário, ao invés ser alcançado por mecanismos de QoS subjacentes . A especificação de qualidade de serviço abrange as seguintes áreas:
2.2 Especificação de Sincronização de fluxo ("Orquestração")
A Especificação de sincronização de fluxo caracteriza o grau de acoplamento cerrado de sincronização entre múltiplos fluxos relacionados. As perspectivas de vídeo gravados simultaneamente deve ser executados em sincronia exata frame-a-frame, para que aspectos relevantes possam ser observados simultaneamente. Por outro lado, a sincronização labial nos fluxos de multimídia não precisa ser absolutamente preciso, quando o canal de informação principal é auditivo e o vídeo só é usado para aumentar a sensação de presença.
A especificação de desempenho de fluxo caracteriza os requisitos de desempenho de fluxo do usuário. A capacidade para garantir taxas de transferência de tráfego, atraso, jitter e taxas de perda, é particularmente importante para comunicações multimídia. Essas métricas baseada em desempenho tendem a variar de uma aplicação para outra. Para ser capaz de comprometer recursos de rede e sistema-fim necessários a arquitetura de QoS ,é preciso ter conhecimento prévio das características de tráfego esperado associado a cada fluxo antes que o comprometimento e a garantia de recursos sejam feitas.
2.4 Compromisso QoS
O compromisso QoS especifica o grau fim-a-fim de comprometimento de recursos necessários que é determinista, preditiva, adaptativa [Campbell, 95] e melhor esforço. Enquanto a especificação de desempenho de fluxo permite ao usuário expressar métricas de desempenho exigido de forma quantitativa, o compromisso QoS permite que estes requisitos sejam refinados de forma qualitativa, de modo a permitir que uma distinção seja feita entre garantias de desempenho rígida, firme e flexível. O compromisso QoS expressa um grau de certeza de que os níveis de QoS solicitados no estabelecimento de fluxo ou re-negociação vai realmente ser confirmados.
2.5 Política de gestão de QoS
Política de gestão de QoS capta o grau de adaptação de QoS (contínua ou discreta) que um fluxo pode tolerar e ações de escala a serem tomadas em caso de violações em QoS contratadas. A curva de desempenho de qualidade temporal e espacial para largura de banda disponível, ou manipular o tempo de reprodução de mídia contínua em resposta a variações nos fluxos de retardo de áudio e vídeo pode aparecer no dispositivo final com percepção mínima de distorção. adaptativas.
2.6 Custo do Serviço
Custo do serviço especifica o preço que o usuário está disposto a pagar para o nível de serviço; custo do serviço é um fator importante quando se considera a especificação de QoS. Se não há noção de custo envolvido na especificação de QoS, não há razão para que o usuário selecione qualquer outra coisa do que o nível máximo de serviço (por exemplo, garantia de QoS nos períodos de pico). Esta filosofia conduziria inevitavelmente a ineficiências de recursos. Para contrariar esta condição a função de custo deve incorporar diferenciais de preços para encorajar o usuário a selecionar o compromisso de QoS otimo e parâmetros de desempenho de QoS, tal como uma politica de compromisso de custo mais baixo.[
2.7 Mecanismos de QoS
Os mecanismos de QoS são selecionados de acordo com a especificação fornecida pelo usuário de QoS (descrito acima), disponibilidade de recursos e da política de gestão de recursos. Na gestão de recursos, os mecanismos de QoS são classificados como estáticos ou dinâmicos por natureza. O gerenciamento de recurso estático lida com o estabelecimento de fluxo e as fases de renegociação de QoS fim-a-fim (que é descrita como provisao QoS) e o gerenciamento de recursos dinâmico que trata da fase de transferência de mídia (que é descrito como controle e gerenciamento de QoS). A distinção entre o primeiro e último é devido a diferentes escalas de tempo em que operam e é uma conseqüência direta do princípio de gerenciamento recursos assíncronos. O controle de QoS distingue-se de gerenciamento na medida em que opera em uma escala de tempo mais rápida ,mais reativa (agendamento de célula opera em escalas de tempo mais rápido do que o tempo de reprodução , evoluindo para um fluxo específico para o dispositivo de reprodução).
2.8 Provisão de QoS
Provisão de QoS é composto por três componentes Mapeamento de QoS
Testes de admissão Reserva de recursos. 2.9 -Mapeamento de QoS
Mapeamento de QoS executa a função de tradução automática entre as representações de QoS em níveis diferentes do sistema operacional, camada de transporte, rede) e assim libera o usuário da necessidade de pensar em termos de especificação de nível inferior. No nível de transporte a especificação de QoS pode expressar necessidades de fluxo em termos de compromisso QoS, as limitações de largura de banda média e pico, jitter, perda e atraso - todas relacionadas com o transporte de pacotes.
[Campbell, 23]
Para os testes de admissão e propósitos de alocação de recursos esta representação pode ter de ser traduzida em algo mais significativo para o agendador sistema-fim. Por exemplo (como ilustrado na figura acima), uma função de mapeamento de QoS é derivar o período, quantum (ou seja, unidade de trabalho) e os tempos limites (deadline time), tópicos relacionados com a especificação de desempenho de fluxo em nivel de transporte .
2.10- Teste de Admissão
Teste de admissão é responsável por comparar a exigência de recursos decorrentes da QoS solicitada contra os recursos disponíveis no sistema. A decisão sobre se um novo pedido pode ser acomodado em geral, depende de todo o sistema de políticas de gestão de recursos e disponibilidade de recursos simples. Assim que o teste de admissão foi concluído com êxito em um módulo de QoS particular, os recursos locais são reservados imediatamente e entao comprometidos mais tarde, se o teste de controle de admissão fim-a-fim(ou seja, a acumulação do hip hop através de testes) é bem sucedido.
2.11 Reserva de Recursos
Protocolos de reserva de recursos providenciam a adequada alocação de sistema fim e recursos de rede, em conformidade com a especificação de QoS do usuário. Ao fazer isso, o protocolo de reserva de recursos interage com roteamento baseado em QoS para estabelecer um caminho através da rede, em primeira instância, então, com base no mapeamento de QoS e controle de admissão em cada módulo de QoS local percorrido (por exemplo ,CPU, memória, dispositivos de I / O , switches, roteadores) fim-a-fim os recursos são alocados e reservados. O resultado líquido é que os mecanismos de gerenciamento e controle de QoS , tais como agendador de celula em nível de rede e monitores de fluxo em nivel de transporte são configurados adequadamente.
3.1- Formador de Fluxo.
A formacão de fluxo regula os fluxos com base em especificações de desempenho fornecidas pelo usuário . A formação do fluxo pode ser baseada em uma taxa fixa de rendimento (exemplo, taxa de pico) ou alguma forma de representação estatística (ou seja, taxa de pico, a taxa sustentável e fator burstiness (fator de perda de pacotes) da largura de banda necessária.
O benefício da formação do trafego(traffic shaping) é que ele permite a arquitetura de QoS empenhar recursos fim-a-fim suficiente para configurar agendadores e formatadores de fluxo para regular o tráfego através dos sistemas de ponta e de rede. Tem sido provado matematicamente que a combinação de traffic shaping na borda da rede e o agendamento na rede pode oferecer garantias de desempenho rígido. Parekh mostrou que se um fluxo de fonte é formado por um algoritmo token bucket(que controla a transmissao de pacotes na rede) com controle do algoritmo leaky bucket , que controla a largura de banda, taxa e agendado pela disciplina de serviço de prioridades agendadas [weighted fair queueing ], é possível alcançar fortes garantias em caso de retardo. Esta é a teoria por trás do int-serv, serviço de retardo garantido que é oferecido em uma integração de serviços
Internet.
3.2 Agendamento de Fluxo
O agendamento de fluxo gerencia o encaminhamento dos fluxos (pedaços de mídia com base em enquadramento da camada de aplicação), no sistema-FIM e de rede (pacotes / células) de forma integrada. Fluxos são geralmente agendados de forma independente nos sistemas finais, mas podem ser agregados ou agendados de forma independente na rede. Isso é independente do compromissode QoS e do esquema de de agendamento adotado.
3.3 Monitoramento de Fluxo (FLOW POLICING)
O policiamento de Fluxo pode ser visto como um duplo monitoramento, geralmente associado com a gestao de QoS - observa se a QoS contratada a um fornecedor está sendo mantida, observa se a QoS contratada por um usuário está sendo respeitada.Policiamento muitas vezes é apropriado só onde as fronteiras administrativas e de carregamento estão sendo cruzadas, por exemplo, em uma interface de usuário-para-rede. Um bom de formador de fluxo na fonte permite que o mecanismo de policiamento para detecte facilmente fluxos mal comportados. A ação tomada pela função de policiamento pode variar em aceitar as violações e apenas notificar o usuário, ate a de moldar o tráfego para um nível de QoS aceitável. Considera-se que os o policiamento de fluxos no sistema final ou rede deve ser uma função do sistema-final ou nivel de agendamento de fluxo de rede e mecanismos de controle de modelagem de QoS.
3.4 Controle de Fluxo
Controle de fluxo inclui esquemas de circuito tanto em malha aberta e fechada. Controle de fluxo em malha aberta é amplamente utilizada em
telefonia e permite que o remetente inserir dados na rede em níveis acordados já que os recursos foram empenhados com antecedência. Em contraste, controle de fluxo de loop fechado requer que o remetente ajuste a taxa com base no feed-back do receptor [Shenker, 93] ou de rede [ATMF, 95a]. Aplicações usando protocolos baseados em controle de fluxo de malha fechada , deve ser capaz de se adaptar rapidamente às flutuações de QoS disponíveis.Muitas aplicações multimídia são adaptativas e pode operar em tais ambientes. Alternativamente, aplicações multimídia que não pode ajustar a mudanças na QoS entregues são mais adequados para esquemas de circuito aberto em que um atraso e atraso da largura de banda pode ser deterministicamente garantido e gerido de forma isolada de outros fluxos concorrentes (isto é, os recursos são barrados por firewall) enquanto durar a sessão.
3.5- Sincronização de fluxo
Sincronização de fluxo é necessária para controlar a ordem do evento e o timming exato das interações multimídia. Lip-sync é a forma mais comumente citada de sincronização multimídia (fluxos de sincronização de vídeo e áudio em um dispositivo de reprodução). Outros cenários de sincronização incluem: sincronização de eventos com e sem interação do usuário, a sincronização contínua diferente da sincronização lip-sync , sincronização contínua para diferentes fontes e absorvedores. Todos os requisitos de QoS sao fundamentais em protocolos de sincronização de fluxo. Gerenciamento dinâmico de QoS associado com a sincronização de fluxo se preocupa principalmente com o 'aperto' de sincronização entre fluxos.
3.6 Gerenciamento de QoS
Para manter SLA´s de QoS muitas vezes não é suficiente apenas para comprometer recursos mas em gerenciamento de QoS frequentemente é
necessário que a qualidade servico contratada seja mantida. A gestao de fluxos de QoS é funcionalmente semelhante ao controle de QoS. No entanto, opera em uma escala de tempo mais lento.
Mecanismos de gerenciamento de QoS de gestão incluem o seguinte: monitoramento de QoS, Manutenção de QoS, degradação de QoS, Sinalização de QoS , Escalabidade QoS.
3.7 Monitoramento QoS
Monitoramento de QoS permite em cada nível do sistema rastrear os níveis de QoS em curso realizado pela camada inferior. Que muitas vezes desempenha um papel integral em um loop de realimentacao de manutenção de QoS que mantém a qualidade do serviço a ser alcançada pelos módulos de recursos monitorados. Algoritmos de monitoramento operam em escalas de tempo diferentes. Por exemplo, eles podem ser executados como parte do agendador de tarefas (como um mecanismo de controle de QoS) para medir o desempenho individual dos fluxos em curso no nível do pacote de transporte ou como parte do formador de fluxo que monitora as células inseridas na rede. Neste caso, as estatísticas de medição podem ser usadas para controlar programação de pacotes e formação de fluxo (que pode incluir ações de descarte de células) e para controle de admissão. Outro uso do monitoramento do fluxo é a determinação do tempo de reprodução de mídia em um dispositivo de entrega em situação com jitter.- isto é particularmente pertinente para aplicações adaptativas. Alternativamente, eles podem operar como parte de um mecanismo de feedback em nível de transporte [Campbell, 92b].
3.8 Manutenção de QoS
A manutenção de QoS compara a qualidade do serviço monitorada em relação ao desempenho esperado e, em seguida, exerce uma operação de sintonia (ou seja, ajustes fino de recursos ) em módulos de recursos
para sustentar a QoS entregue. A degradação de QoS é ajustada via contadores pelo ajuste de módulos de QoS (como a perda através do gerenciador de buffer, filas atrasos através do agendador de fluxo e rendimento através do regulador de fluxo [Campbell, 93]) ou recurso remoto para manter o desempenho desejado.
3.9 Degradação QoS
A degradação de QoS levanta algumas questoes sobre QoS (ou seja, evento de sinal de QoS) para os usuários quando ele determina que as camadas inferiores não conseguiram manter a QoS dos fluxos e nada mais pode ser feito pelo mecanismo de manutenção QoS. Em resposta a tais indicações, o usuário pode optar por adaptar-se ao nível de serviço disponível ou adaptar-se a um novo nível reduzido de serviço (ou seja, proceder a uma renegociação de ponta a ponta, que é também conhecida como escala de QoS).
3.10 Sinalização QoS
A sinalização de QoS permite ao usuário especificar o intervalo em que um ou mais parâmetros de QoS (atraso, jitter, largura de banda, perda e sincronização,) pode ser monitorada e o usuário é informado sobre o desempenho entregue (através de um sinal de QoS) no final do intervalo. Ambos os sinais de QoS simples e múltiplos podem ser selecionados, dependendo se o usuário solicitou política de gerenciamento de QoS. Métricas de medidas de desempenho são particularmente úteis no caso de aplicações adaptativas, por exemplo, aplicações de vídeo adaptativas operando sobre redes de melhor esforço, atraves do melhor esforço na
internet .
3.11 Escala de QoS
A escala de QoS é composta de filtragem QoS (que manipula os fluxos à medida que trafegam através do sistema de comunicações) e de adaptação de mecanismos QoS (cujas escalas fluem somente em sistemas fim) . Muitas aplicações de mídia contínua apresentam robustez em adaptar-se às flutuações de qualidade de adaptar-serviço fim-a-fim . Com baadaptar-se na politica de gerenciamento de QoS fornecida pelo usuário , a adaptação de QoS nos sistemas finais pode tomar ações corretivas para dimensionar os fluxos de forma inteligente. adapta ao recurso disponível ou procura escalornar para níveis mais baixos de serviço. A resolução qualidade de serviço heterogêneo é um problema particularmente agudo no caso de fluxos multicast. Neste caso receptores individuais podem ter diferentes capacidades de consumir fluxos áudio-visual. A filtragem de QoS ajuda a transpor esta lacuna de heterogeneidade (ou seja, incompatibilidade da capacidade de comunicação) ao mesmo tempo atende requisitos de qualidade de serviço de receptores individuais.
4.1 Padroes de QoS
Novas aplicaçoes e ambientes tecnológicos iniciados em 1996 começaram a ter impacto nas as arquiteturas de rede.Não conseguiam resolver de forma abrangente a necessidade de suporte de QoS para aplicações multimídia distribuídos , operando em redes de alta velocidade. Esta seção revisa o modelo de referência OSI, as recomendações do Fórum
de redes ATM e as normas de projeto de trabalho int-serv proposto.
4.2 Interconexão de Sistemas Abertos
A ISO desenvolveu um conjunto de padrões para comunicação de computadores na forma do modelo de referência de sete camadas OSI e esses padrões são amplamente implementado. O modelo de referência OSI evoluiu em um ambiente de aplicaçoes apenas de dados executados em redes de baixa velocidade e com o suporte de QoS fornecidos pelo modelo de referência OSI reflete os requisitos limitados de QoS desta classe de aplicações.
Parâmetros.
Rendimento (Throughput)
O número máximo de bytes, contida em Unidades de Data Service (SDUs) que podem ser transferidos com sucesso na unidade de tempo pelo prestador de serviços através da conexão de forma sustentada.
Retardo de trânsito
O tempo de retardo entre a emissão de um DATA.REQUEST e a DATA.INDICATION correspondente. O parâmetro é especificado como um par de valores, uma média estatística e um máximo. Estes dados transferidos sao excluidos onde um utilizador de serviços de recepção exercita um fluxo de controle. Os cálculos são todos baseados em SDUs de um tamanho fixo. Taxa de erro residual
A probabilidade de que uma SDU é transferida com o erro, ou que é perdida, ou que uma cópia duplicada é transferida.
Atraso estabelecimento
O atraso entre a emissão CONNECT.REQUEST e os correspondentes connect.confirm.
Probabilidade de falha estabelecimento
A probabilidade de que uma conexão solicitada não seja estabelecida dentro do retardo especificado maximo aceitavel de estabelecimento como conseqüência de ações que são exclusivamente atribuíveis ao prestador do serviço.
Probabilidade de transferência de falha
A probabilidade de que o desempenho observado em relação ao atraso de trânsito taxa de erro, residual ou de throughput será pior do que o nível de desempenho especificado. A probabilidade de falha é, especificada para cada medida de desempenho de transferência de dados.
Resiliência
A probabilidade de que um provedor de serviços, por conta própria, liberar a conexão, ou resetá-la, dentro de um intervalo de tempo especificado.
Retardo de Liberação
O atraso máximo entre a emissão de uma primitiva DISCONNECT.REQUEST pelo utilizador dos serviços e uma primitiva DISCONNECT.INDICATION correspondente emitida pelo prestador do serviço.
Probalidade de falha de Liberação
liberar a conexão dentro de um retardo de liberação maximo expecificado. O suporte de QoS no modelo de referencia OSI , é limitado aos parâmetros definidos estaticamente,planejados para dar suporte às camadas de sessao e transporte . Para habilitar aplicativos para acessar as facilidades de QoS , as camadas superiores do modelo OSI (camadas de aplicação e apresentação) simplesmente mapeia os pararâmetros de QoS (dimensões) (parâmetros) até as camadas inferiores inalteradas. Na camada de transporte, os parâmetros de QoS se relacionam com cada uma das fases da sessão, isto é, o estabelecimento da conexão, transferência de dados (tambem conhecido como transferência de mídia no novo ambiente) e liberação de conexão.
PARÂMETROS
PROTEÇÃO
É a medida que um prestador de serviços tenta evitar que a monitorização não autorizada ou manipulação de dados do usuário. O nível de protecção é especificado qualitativamente selecionando (i) nenhuma proteção; (ii) proteção contra monitoramento passivo; (iii) a protecção contra a adição, alteração ou supressão, ou (iv) uma combinação de (i) e (ii).
PRIORIDADE
Conexões de alta prioridade são atendidas antes das mais baixas. Pacotes de menor prioridade de conexão serao descartados que que pacotes de alta prioridade venham tornar a rede congestionada.
Os parâmetros também são classificados como orientado a desempenho ou não orientados a desempenho. Parâmetros não orientados a desempenho não afetam diretamente o desempenho das comunicações, mas estão estao diretamente relacionados com prioridade, proteção e categorias de custos de QoS. O conjunto completo de parâmetros, juntamente com suas
interpretações é apresentado nas paginas anteriores, que relaciona os parâmetros de desempenho orientados e na pagina os parâmetros nao orientados a desempenho.
5 FORUM ITU-TS e ATM
ITU-TS e mais tarde o Fórum ATM reconheceu a necessidade de configurabilidade de QoS nos padrões emergentes para B-ISDN que devem ser baseados em ATM tecnologia de rede. Como resultado deste reconhecimento, a ITU-TS emitiu uma série de recomendações, conhecidas como as recomendações serie I , e ATM Forum um conjunto de padrões provisórios que define um conjunto bastante abrangente de parâmetros de QoS (que o Fórum ATM descreve como atributos QoS) no ATM e camadas de adaptação. A caracterização de QoS em redes ATM é aplicável em três níveis diferentes. O controle de chamadas e os níveis de conexão estão preocupados com o estabelecimento (ou seja,provisao de QoS) e liberação de chamadas e a alocação de recursos ao longo dos nós de comutação ATM. O nível de controle celular se preocupa com a fase de transferência de mídia propriamente dito.
A lista de atributos de QoS anteriormente descritas é abrangente. Destina-se a permitir o tráfego (fluxos) para ser caracterizado com antecedência para que a a função de gerenciamento de recursos rede (protocolos de sinalização) possa alocar recursos para suportar os padrões de tráfego desejado. Os atributos de QoS também são usados como uma base para supervisionar o trafego inserido na rede pelo usuário para garantir que o usuário não tente inserir mídia na rede maior do que a QoS , anteriormente contratata. Destina-se também usar esses parâmetros para suporte à renegociação de QoS (conhecida como call-renegociação). A renegociação de conexao de QoS ainda estava aprovada pelos orgaos de padroes ATM, (em 1996).
5.1 IETF int-serv e Grupos de RSVP
O IETF int-serv foi um grupo de trabalho RSVP foram os geradores primários de soluções para o problema QoS fim-a-fim. Embora a Carta int-serv cubra todo e qualquer definição de int-serviços e mecanismos de apoio fim-a-fim QoS, em uma inter-rede o trabalho de RSVP é focado exclusivamente na concepção, implementação e integração de um protocolo de sinalização de nova reserva chamado RSVP. Os dois itens de trabalho são cruciais para o avanço dos serviços de multimídia na Internet.
Trabalhos do grupo int-serv incluiu a definição de um quadro QoS usado para especificar a funcionalidade dos componentes de sistema internetwork (chamados "elementos") que suportam múltiplas, qualidades de serviço dinamicamente selecionável para aplicações em uma intenetwork. O comportamento de elementos, tais como roteadores, sub-redes e sistemas finais do sistema operacional é capturado como um conjunto de serviços de alguns ou todos que são oferecidos por cada elemento. Cada elemento é QoS-aware (ou preparado para atender QoS) e suporta interfaces exigidas pela definição de serviço. A concatenação destes serviços ao longo de um caminho fim-a-fim usada por um aplicativo fornece uma declaração geral de QoS fim-a-fim.
O seguinte serviços int-serv são oferecidos, além do serviço de melhor esforço atual: atraso controlado [Shenker, 95b], que tenta fornecer vários níveis de atraso que o aplicativo pode escolher entre; • atraso previsto [Shenker, 95b], que fornece um atraso estatístico vinculado semelhante ao serviço de estatística do Grupo de Telnet [Ferrari, 92] e os Grupos de Comet serviço garantido [Lazar, 90]; atraso garantido [Shenker, 95b], que fornece um atraso absoluto garantido vinculado. Cada definição de serviço também especifica os parâmetros de QoS utilizados para chamar o serviço.
O conjunto de serviços específicos em 1996 , são apropriados para uma ampla gama de fluxos de multimídia e aplicações de dados. Enquanto a definição enfatiza o elemento "rede" o framework em sua generalidade completa é a aplicável sistemas finais como a rede. O objetivo do grupo int-serv é concentrar-se na rede, em primeira instância, e então no sistema-final.
Fluxos são caracterizados por duas especificações:
(i) especificação de tráfego (TSpec), que é uma especificação do padrão de tráfego que se espera expor de um fluxo. Um exemplo desta especificação pode assumir a forma de largura de banda do fluxo e burstiness especificado por um token bucket [Partridge, 92], e
(ii) uma especificação de solicitação de serviço (RSpec), que é uma especificação da qualidade do serviço um fluxo que se espera alcançar a partir de um elemento de rede e da forma que é altamente específico para um determinado serviço. Um exemplo desta especificação pode tomar a forma de representar o atraso máximo tolerável. No caso do serviço retardo garantido descrito acima, o serviço é invocado especificando o tráfego (TSpec) e o serviço desejado (RSpec). O TSpec assume a forma de um token bucket, com uma bucket depth (b) e bucket rate (r). O RSpec é uma taxa (R), onde R deve ser maior ou igual a r. Especificações de tráfego são mais freqüentemente criadas pelo gerador do fluxo de dados.Por outro lado , as especificações solicitação de serviço podem se originar de o remetente ou receptor de um fluxo.O modelo de serviços integrados é restrito à rede em primeira instância e é composto por quatro componentes:
i) um agendador de pacotes, que encaminha o pacote fluxos usando um conjunto de filas e temporizadores;
ii) um classificador, que mapeia cada pacote que entra em um conjunto de classes de QoS;
iii) um controlador de admissão, que implementa o algoritmo de controla de admissão para determinar se um novo fluxo pode ser admitido ou negado, e
iv) um protocolo de instalação de reserva (por exemplo, RSVP, que é necessário para criar e manter o estado de fluxo específico nos roteadores ao longo do trajeto do fluxo.
Em 1996 ,as definições de serviço do modelo OSI não forneciam a especificação de uma faixa de dimensões de QoS incluindo jitter, criticidade e custo. Além disso,havia suporte para QoS de monitoramento ou interface para renegociação. A semântica exata das responsabilidades e garantias não eram claras. Mais limitante é o fato de que no nível de protocolo não existe noção de gerencimento de QoS em termos, negociação ,mapeamento, alocação de recursos e manutenção de QoS. Supõe-se que o provedor de rede subjacente apoiará os níveis de QoS solicitada.As recomendações do Fórum ATM são compreensivas incluem um modelo de caracterização detalhada do tráfego em termos de categorias de serviço ATM e atributos associados de QoS. O modelo de serviço ATM caracteriza um fluxo por tipo de tráfego (com base nas categorias de serviço ATM) e um conjunto de parâmetros de QoS (com base nos atributos ATM QoS) que são integradas em um contrato de tráfego. Esta abordagem elimina a necessidade de classes de QoS na UNI 3.0. Em 1996, cada conexão virtual tinha um contrato de tráfego associado a ele. Os principais serviços relacionados com a limitação aqui é a falta de consideração de como a caracterização de tráfego na camada ATM podem ser derivadas de usuário das necessidades de QoS na camada de transporte e acima. E como os requisitos de aplicativos em nível de QoS são mapeadas para o conjunto de categorias e atributos QoS. Abaixo da interface do serviço, o estado da padronização ATM sofre com a falta de gerenciamento de QoS encontrado no modelo OSI.Há uma série de semelhanças na abordagem do Fórum de ATM e IETF em atender aos requisitos de QoS de comunicação. Ambos os grupos
quando abordam os problemas de QoS fazem de diferentes perspectivas.
6.ARQUITETURAS QoS EMERGENTES , década de 90
fig.6.1-planos e camadas OSI , que sustentam a arquitetura QoS.
prestação de garantias de QoS era focada em modelos de rede orientada para o tráfego e disciplinas de agendamento de serviços. Essas garantias não são, do tipo fim-a-fim, ao invés disso garante QoS apenas entre os pontos de acesso à rede em que os sistemas estão ligados [Gopalakrishna, 94]. O trabalho de QoS da arquitetura de sistemas finais devem estar integrados com serviços de QoS configuravel de rede e protocolos para atender requisitos de aplicaçao-para-aplicaçao. [Campbell, 92]. Em reconhecimento a isso, os pesquisadores propuseram novas arquiteturas de comunicação, que são mais amplas em alcance e cobertura de dominios de e sistemas finais. A seguir uma relação de modelos de tecnologias emergentes decada de 90 , que deram origem as redes com qualidade de serviços atuais 2011, e seguem evoluindo como no caso modelo OMEGA oriundas das das Telecomunicações, Computer Communications e comunidades de padronização.
• Extended Integrated Reference Model (XRM), Columbia University, • OSI QoS Framework, ISO SC21 QoS Working Group.
• OMEGA Architecture, the University of Pennsylvania. • Heidelberg QoS Model, IBM’s European Networking Center. • Tenet Architecture, University of California at Berkeley. . End System QoS Framework, Washington University.
• IETF QoS Manager (QM), the int-serv group, qos da estratégia para internet de serviços integrados.
• TINA QoS Framework, TINA Consortium.
• MASI End-to-End Architecture, Université Pierre et Marie Curie. [CAMPBEL,43]
6.1 A Universidade Columbia Extended Modelo de Referência Integrada
XRM-O grupo CXRM-OMET na Universidade de Columbia (Nova York) desenvolveu um Modelo de Referência Extended Integrado (XRM) como uma estrutura de modelagem para controle e gerenciamento de redes de telecomunicações de multimídia (que incluem plataformas de computação multimídia e redes de banda larga). O grupo COMET argumenta que as bases para a operacionalidade (ie, controle e gerenciamento) da computação multimídia e dispositivos de rede são equivalentes, as duas classes de dispositivos podem ser modelados como produtores, consumidores e processadores de mídia. O COMET organiza o XRM em cinco planos distintos, como ilustrado na figura abaixo.
1) função de gerenciamento , que reside no plano de gerenciamento de rede (plano-N), abrange as áreas funcionais do modelo OSI e gerenciamento de sistema;
2) função de controle de tráfego, que compreende o controle de recursos (plano-M) e gerenciamento de conexão e controle (plano-C). Controle de
recursos constitui no agendamento de celulas ,chamada para admissão, encaminhamento de chamadas na rede, agendamento de processos, gerenciamento de memória, roteamento, controle de admissão e controle de fluxo nos sistemas finais.
3) função de informação de transportes, que está localizado no plano de transportes do usuário (Plano-U), modela os protocolos de mídia e entidades para o transporte de informações do usuário tanto na rede quanto nos sistemas finais.
4) telebase, que reside na abstração de dados e plano de gerenciamento (plano-D), coletivamente representa as abstrações informações de dados existentes na rede e sistemas finais. O telebase implementa os princípios de mpartilhamento de dados (via gestão de recursos assíncrona) entre todos os outros planos XRM.
A subdivisão da XRM em diferentes planos é motivada por uma série de principios de QoS - principios da separação de camadas. e o princípio de gerenciamento de recursos assíncronos. A subdivisão entre as funções de gerenciamento e de controle de tráfego, por um lado, e as funções de transporte de informações por outro, é baseada no princípio da separação entre controle e comunicação. A separação entre gerenciamento e controle do tráfego é devido a diferentes escalas de tempo em que estes planos operam. Isto é motivado pelo principio de gerenciamento de recursos assincronos.
O modelo XRM é construído sobre o trabalho teórico garantindo requisitos de QoS em redes ATM e sistemas finais populado com dispositivos multimédia. Conceitos gerais para caracterizar a capacidade da rede e dispositivos do sistema final dispositivos (por exemplo, discos, switches) foram desenvolvidos. Na camada de rede, o XRM caracteriza a regiao de estabilidade de um multiplexador ATM com garantias de QoS como uma região agendavel. Recursos de rede, como largura de banda de comutação e capacidade de enlace são alocados com base em quatro classes de nível de
célula de tráfego (Classe I, II, III, e C) para emulação de circuito, voz e vídeo, dados e gerenciamento de rede, respectivamente. A classe de tráfego é caracterizado por suas propriedades estatísticas e requisitos de QoS. Tipicamente requisitos de QoS refletem a perda de células e as restrições de atraso. , A fim de satisfazer de forma eficiente os requisitos de QoS do nível de celulas,agendamento e algoritmos de gerenciamento de buffer alocam dinamicamente largura de banda de comunicação e espaço de buffer de forma adequada. A região agendavel representa a capacidade multidimensional do multiplexador; sua dimensionalidade depende do número de classes de tráfego e representa a região de estabilidade. A região agendavel é uma abstração de recursos que permite uma separação de escalas de tempo: as escalas de tempo das células e à escala de tempo de chamada chegadas e partidas. Em [Hyman, 92] é mostrado como a separação de escalas de tempo é um instrumento adequado para resolver decisões de controle de admissão. Baseado em um cálculo de regiões agendaveis, a QoS na rede pode ser garantida. As três classes de tráfego na figura 3.6 correspondem aos fluxos de vídeo, voz e dados. Classe de tráfego que é caracterizada por um quadro de duração de 62,5 ms e uma taxa de pico de 10 Mbps, tráfego de Classe II é modelado como uma fonte on-off com chegadas constante com um período exponencialmente distribuídos ativos e 64 Kbps de taxa de pico, e Classe III tráfego é modelado como uma fonte de Poisson com taxa média de 1 Mbps. A superfície representada na figura 3.6 delimita a região de estabilidde do multiplexador. Qualquer combinação do número de chamadas (ou seja, os fluxos de ativos) abaixo desta superfície tem a QoS garantida. O sistema final da arquitetura do Modelo XRM é uma uma estação de trabalho multimidia baseada em multiprocessadores , composta dos seguintes dispositivos multimídia: (i) uma unidade de vídeo e audio, que é responsável pelo processamento de multimídia, e oferece suporte a tarefas de processamento de mídia de maneira determinista, e roda em um processador dedicado (s), (ii) um subsistema de entrada / saída que é modelada de forma semelhante, separadamente através de uma
unidade de armazenamento em disco, e também é executado em um processador separado (s), (iii) uma unidade de processador principal executa as tarefas do sistema, tanto para aumentar a velocidade quanto para remover interrupções externas, bem como sobrecarga de outro sistema operacional associado com as tarefas da aplicação. No sistema final, requisitos de fluxos são modelados por meio de especificações classes de serviços com restrições de QoS . Por exemplo, na unidade de áudio e vídeo a especificação de classe de serviço é em termos qualidade de fluxo de JPEG, MPEG-I, MPEG II- vídeo e
CD áudio com garantias de QoS. Qualidade do serviço para essas classes é especificado por um conjunto de quadros de atraso e restrições de perda. A metodologia de recursos de caracterização rede é extendida até o sistema final para representar a capacidade de dispositivos multimídia. Usando o conceito de uma região de estabilidade multimídia para o problema dos fluxos de programação no sistema final torna-se idêntico ao exercício de emcapsulamento em tempo real da camada de rede. Uma diferença significativa entre a região e a região agendavel da regiao de
estabilidade multimídia é o número de classes suportadas. O número de classes de serviço a nível de usuário é esperado para exederem em muito o número de classes de tráfego no multiplexador. Uma serie de classes de serviço no entanto podem ser mapeadas em uma classe de trafego unica do multiplexador , e portanto o suporte a um grande numero de classes de serviço nao exige aumento do numero de classes trafego.
A implementação de XRM, incluindo abstrações de recursos-chave, tais como a região de estabilidade agendavel e multimídia está compreendida como sendo parte de uma arquitetura de ligação [Lazar, 94]. A arquitetura de ligação atinge ligação perfeita entre redes e dispositivos multimídia. Os blocos de construção da arquitetura consiste de um conjunto de interfaces, métodos e primitivas. O primeiro abstrai as funcionalidades de dispositivos de rede multimídia e organiza-os em uma base de interface de ligação (BIB). Os métodos e as primitivas são invocados para implementação de ligação de aplicações. A comunicação entre as interfaces da arquitetura é suportada por CORBA da OMG [OMG, 93]. Requisitos obrigatórios surgem em cada um dos planos do XRM. Requisitos de vinculação dinamica, no entanto, são particularmente exigentes nos planos C e M do XRM. A arquitetura de ligação reside nos planos M, D e C do XRM. Especificamente, a base da interface de ligação reside no plano-D e os algoritmos de ligação execute de dentro dos planos M e C-. A arquitetura de ligação ou vinculação representa um ambiente de software em onde aplicações de ligação sao excutadas. Exemplos de aplicações de ligação surgem em conexão a configuração de redes de banda larga, sistemas distribuídos implementação de protocolos de sincronização de fluxo,protocolo de alocação de recursos, tais como os destinados à Internet, plataformas de computação multimídia. As novas aplicações de ligação pode ser adicionadas sem alterar a arquitetura subjacente vinculativa.
Uma contribuição inicial para o campo da arquitetura de QoS é o QoS-Framework que se concentra principalmente na qualidade de serviço de suporte para comunicações OSI. O Framework/OSI define a terminologia e conceitos para QoS e fornece um modelo que identifica os objetos de interesse para QoS nos padrões de sistema aberto. A QoS associada com objetos e suas interações é descrito através da definição de um conjunto de características QoS.
Os principais conceitos quadro de QoS incluem:
• Requisitos de QoS - que são realizados através de QoS de gestão e entidades de manutenção;
• Características de QoS, que são uma descrição das medidas de QoS que precisam ser gerenciadas no sistema de comunicação;
• Categorias de QoS , representam uma política que rege um grupo de requisitos de QoS específicos para um determinado ambiente, tais como tempo crítico comunicações .
• Funções de gerenciamento de QoS, que podem ser combinadas de várias formas e aplicado a várias características QoS, a fim de atender aos requisitos de QoS.
O Framework de QoS ,OSI (ilustrado na figura 3.7) é composta de dois tipos de entidade gestora que tentam cumprir os requisitos de QoS através do monitoramento, manutenção e controle de QoS fim-a-fim. [Campbell, 47].
Entidades de Camada específicas: A tarefa da função de controle de políticas é determinar a política que se aplica a uma camada específica do sistema aberto. A função de controle de política modela açoes de prioridade que devem ser executadas para controlar a operação da camada. A definição de uma política específica é de camada específica e, portanto, não podem ser generalizadas. A política pode, no entanto, incluir aspectos de segurança, comunicações de tempo crítico e controle de recursos. O papel da função de controle de QoS é determinar, selecionar e configurar as entidades protocolo apropriado para atender aos objetivos específicos da camada de
QoS.[Campbell,92]
Entidades de todo o sistema: O agente de gerenciamento do sistema é usado em conjunto com os protocolos OSI de gerenciamento de sistemas para permitir que os recursos do sistema sejam gerenciados remotamente. O gerenciador de recursos local representa os recursos de controle de sistema final. A função de controle de sistema de QoS combina duas capacidades de todo o sistema: para ajustar o desempenho de entidades de protocolo e de modificar a capacidade de sistemas remotos via gerenciamento de sistemas OSI.A interface de gerenciamento de sistemas OSI é suportado pelo gerente de gestão de sistemas que fornece uma interface padrão para monitorar, controlar e gerenciar sistemas finais. A função de controle da política do sistema interage com cada função de controle da camada de políticas específicas para fornecer uma seleção geral de funçoes de QoS e instalaçoes.
6.3 Arquitetura OMEGA ,UNIVERSIDADE DA PENSILVANIA.
arquitetura chamada de arquitetura OMEGA. A arquitetura OMEGA é o resultado de um esforço de pesquisa interdisciplinar que verifica a relação entre requisitos de aplicação de QoS (que faz exigências rigorosas de recursos) e a capacidade de (o sistema operacional) local e a gestão de recursos global (combinação de comunicação e recursos gerenciados remotamente) para atender a essas demandas. A arquitetura OMEGA assume um subsistema de rede que fornece limites de atraso, erros e pode atender às demandas de largura de banda e um sistema operacional que é capaz de fornecer garantias de QoS em tempo de execução. A essência da arquitetura OMEGA é reserva de recursos e gestão de ponta a ponta de recursos. A Comunicação é precedida por uma fase de configuração de chamada onde os requisitos de aplicação, expresso em termos de parâmetros de QoS, são negociados, e garantias são feitas em vários níveis lógicos, tais como entre aplicações e o subsistema de rede, aplicações e o sistema operacional, o subsistema de rede e operação do sistema. Isto estabelece conexões personalizadas e os resultados na alocação de recursos apropriados para atender aos requisitos de aplicativos e sistema operacional / capacidades da rede.
Arquitetura Omega ,da Universidade da Pensilvania.
Pensilvânia também desenvolveu um modelo de corretagem, que incorpora tradução de negociação e renegociação de QoS. A noção de eras é introduzido para descrever as variações nos parâmetros de QoS para o complexo, de longa aplicações duração aplicações. Negociação e renegociação fornecem um mecanismo para sinalizar variações de parâmetros de desempenho QoS na interface utilizador-rede. Eles são invocados nos limites era e pode ajudar a alocação de recursos. No modelo, os requisitos de aplicação e alocação de recursos de rede são expressos em termos fundamentalmente diferentes e linguagens. Uma parte fundamental do modelo, chamado de QoS Broker [Nahrstedt, 95a] é responsável pela tradução de QoS na interface utilizador-rede. Trabalho mais recente tem abordado as questões do sistema operacional, tais como controle de admissão para QoS garantido [Nahrstedt, 94] ver também [Nahrstedt, 95b] para um levantamento abrangente das questões de gestão de recursos em multimídia em rede.
A arquitetura OMEGA é particionada em componentes distribuídos e local: Um modelo de comunicações e um modelo de recurso nos pontos extremos. O sistema de comunicação é modelado como um sistema de duas camadas, como ilustrado na figura 3.8. A camada de subsistema de transporte é baseada no princípio de desempenho (camada de processamento integrado). Funções como gerenciamento de conexão, correção de erros de encaminhamento, detecção de falhas de tempo e movimento de dados temporizados formam o núcleo do protocolo de rede em tempo real. A camada de subsistema de aplicativo contém as funções das camadas de aplicação e sessão, tais como gerenciamento de chamadas, controle de taxa de dispositivos de multimídia, entrada / saída (por exemplo, a visualização de vídeo), a fragmentação e remontagem dos dados de unidades de aplicação. Estas funções são o núcleo do Protocolo de Aplicação em Tempo Real. (RTAP). Ambos os subsistemas devem fornecer serviços de QoS garantido durante chamadas especificas / conexões para aplicações. Portanto, eles exigem garantias sobre os recursos necessários para as
comunicações. Garantias de recursos são negociadas durante o estabelecimento da chamada, pelo protocolo de QoS Broker que está presente no aplicativo e subsistemas de transporte.
7. Conclusão.
O que na atualidade tem se tornado essencial para o bom desempenho das comunicações busca apoio na qualidade de serviço inter-redes isso incluindo a internet. Mas até chegar ao estágio atual existiu um trabalho árduo de universidades e cientistas da ciência da computação em buscar modelos que pudessem trabalhar de forma paralela ao fluxo de informação sempre evitando retardos e perdas de pacotes por interferência aos dados em trânsito. Para isso os modelos se apoiaram em modelos de abstração conforme descritos nos modelos acima, onde o monitoramento
permanente colabora na garantia da largura de banda, taxa de erros e entrega de pacotes em tempo hábil assegurando a QoS entre cliente e fonte de informação.
O assunto qualidade de serviço está presente praticamente em todos os equipamentos gerenciáveis onde os parâmetros são definidos a partir das escolhas que garanta um bom desempenho e melhor qualidade da conexão. Sempre levando em conta que as concessionárias de serviço também garantam parâmetros de qualidade aceitáveis pelos órgãos reguladores e definidores de padrões. As arquiteturas descritas são alguns exemplos, há pelos dez que surgiram na década de 90, mas algumas poucas continuam em evolução a exemplo das arquiteturas Best-Effort, Omega, Intserv e Diffserv.
REFERÊNCIAS
Campbell, Andrew T, Campbell,"A Quality of Service Architecture", .1996 ATM Forum, ATM Forum, “ATM User-Network Interface Specification Version 4.0”, 1995.
Campbell, A., G. Coulson and D. Hutchison, "A Suggested QOS Architecture for Multimedia Communications", ISO/IEC JTC1/SC21/WG1 N1201, International Standards Organisation, UK, November, 1992.
Campbell, A., Coulson G., García F., and D. Hutchison, "A Continuous Media Transport and Orchestration Service", Proc. ACM SIGCOMM ‘92, Baltimore, Maryland, USA.
Campbell, A., Coulson, G., García, F., Hutchison, D., and H. Leopold, “Integrated Quality of Service for Multimedia Communications”, Proc. IEEE Infocom’93, Hotel Nikko, San Francisco, CA, March 1993.
Campbell, A., Coulson G., and D., Hutchison, “A Multimedia Enhanced Transport Service in a Quality of Service Architecture”, Proc. Fourth International Workshop on Network and Operating System Support for Digital and Audio and Video, Lancaster, UK, October 1993, and ISO/IEC JTC1/SC6/WG4 N832, International Standards Organisation, UK, November, 1993.
Campbell, A., Coulson, G. and Hutchison, D., “A Quality of Service Architecture”, ACM Computer Communications Review, April 1994.
Campbell, A., Coulson, G., and D. Hutchison, “Flow Management in a Quality of Service Architecture”, 5th IFIP Conference on High Performance Networking, Grenoble, France, June 1994.
Campbell, A., Coulson G. and D. Hutchison, “Supporting Adaptive Flows in a Quality of Service Architecture”, Multimedia Systems Journal, November, 1995 (to be published).
Gopalakrishna, G., and G. Parulkar, “Efficient Quality of Service in Multimedia Computer Operating Systems”, Department of computer science, Washington University, Report WUCS-TM-94-04, August 1994.
Hyman, J., Lazar, A., and G. Pacifici, "Joint Scheduling and Admission Control for ATS-based Switching Nodes", Proc. ACM SIGCOMM ‘92, Baltimore, Maryland, USA, August 1992.
Lazar, A. A., Temple, A and Gidron, “An Architecture for Integrated Networks that Guarantees Quality of Service”, International Journal of Digital and Analog Communications Systems, Vol. 3, No. 2.
Nahrstedt K. and J. Smith, “The QoS Broker”, IEEE Multimedia, Spring 1995.
OMG, “The Common Object Request Broker: Architecture & Specification,Rev 1.3., December 1993.
Partridge, C., "A Proposed Flow Specification; RFC-1363" Internet
Request for Comments, no. 1363, Network Information Center, SRI International, Menlo Park, CA, September 1990.
Saltzer, J., Reed, D., and D. Clark,"End-to-end Arguments in Systems Design", ACM Trans. on Computer Systems, Vol. 2., No. 4.
Shenker, S., and C. Partridge, “Specification of Predictive Quality of Service”, Working Draft, draft-ietf-intserv--svc-template.02.txt, November 1995.
