Resumo das RFC’s

2816 – Uma Estrutura de Serviços Integrada Sobre uma LAN Compartilhada e Comutada de Tecnologia IEEE 802

(A Framework for Integrated Service Over Shared and Switched IEEE 802 LAN Technologies)

e

2815- Serviços Integrados Mapeados em Redes IEEE 802

(Integrated Service Mapping on IEEE 802 Networks)

Segundo Trabalho da Disciplina

de comunicação de dados do

PPGEE/UFPR

Aluno:Cristhian Alberto Celestino Cortez.

RFC 2816

1-Introdução

A Internet tem como tradição proporcionar tráfego somente do tipo "best effort". Entretanto, devido à utilização de serviços em tempo real, foi verificada a necessidade em criar sistemas de controle de prioridade no tráfego.

O controle de prioridade no tráfego nesta rfc (RFC2816) foi proposto para a camada de enlace de dados. Porém, ela pode ser feita na camada IP como é o caso do protocolo de sinalização RSVP (Protocolo de reserva de recursos).

Nesta rfc são definidas algumas regras para o controle dos recursos na camada de enlace de dados para diversas tecnologias.

2-Envio de quadros em redes IEEE 802

2.1- Modelo geral do serviço IEEE 802

A prioridade do usuário é um valor associado à prioridade da transmissão e da recepção em todos os quadros no modelo de serviço IEEE 802. Porém algumas tecnologias, como o Ethernet/IEEE 802.3, não carregam explicitamente em seus quadros a informação de prioridade, enquanto outras, como o Token Ring /IEEE 802.5, carregam. Para resolver o problema de prioridade no tráfego o padrão IEEE 802.1D define uma forma de transportar o valor de prioridade através da camada MAC, utilizando um formato de quadro estendido.

Se a prioridade do usuário é carregada explicitamente no pacote, é utilizado um label habilitando ou desabilitando o fluxo com diferentes classes.

O IEEE 802.1D não especifica a prioridade do usuário que deve ser utilizado, porém é definido o enfileiramento estático como o modo de operação padrão em switches que implementam múltipla filas.

O algoritmo de enfileiramento funciona do seguinte modo:

1- Os pacotes são enfileirados de acordo com a prioridade que receberam, níveis de 0 até 7, definido por um controle local (IEEE 802.1Q, IEEE 802.5, etc).

2- As filas são selecionadas de acordo com o nível de prioridade e do tráfego no momento.

2.2-Ethernet/IEEE 802.3

Não existem classes explicitas ou campos de prioridade de usuário em pacotes Ethernet. Uma alternativa é encápsular o pacote Ethernet através do IEEE 802.1Q, que colocará um campo que explicitará a prioridade do usuário.

Um efeito colateral do encápsulamento é o “overhead”, que é de 22 bytes por pacote IP, para um pacote de tamanho máximo de 1500 bytes, utilizando o padrão 802.1D/Q.

2.3-Token Ring/IEEE 802.5

O padrão Token Ring possui um mecanismo de prioridade que pode ser usado tanto para acesso ao meio compartilhado como para enfileiramento dos pacotes. O mecanismo de prioridade é implementado através dos bits do “Acess Control” (AC) e do “Frame Control” (FC) que são campos do quadro LLC. O AC controla qual estação terá o acesso do anel sendo os três primeiros bits os de prioridade de Token e os outros três são reservados. O FC possui em seus três últimos bits o nível de prioridade recebida das camadas superiores. O nível de prioridade do usuário será transmitido de através das bridges Token Ring de todos os tipos. Token Ring também relaciona a prioridade com a estação que está com o token reservado para a próxima transmissão. Quando uma transmissão é feita, a estação que possui a prioridade de acesso maior ou igual à prioridade reservada poderá transmitir. O padrão IEEE 802.5 recomenda a seguinte tabela de prioridades.

Aplicação	Prioridade do usuário
Dado sem dependência crítica de tempo	0
-	1
-	2
-	3
Gerenciamento da rede	4
Dado sensível ao tempo	5
Dados em tempo real	6
Quadros MAC	7

Tabela 1, prioridades dos usuários.

Para resolver o problema de “jitter” associado ao tráfego de maior prioridade, é recomendado que seja transmitido um quadro por token e que o campo que atravessa o anel deve ter no máximo 4399 octetos. Existem algumas especificações que sugerem que a prioridade dos quadros do LLC, controle da rede, tenham prioridade maior do que 4. A capacidade de gerenciar a prioridade reservada e a prioridade do usuário tornam o Token Ring capaz de suportar um sistema de serviços integrados com garantias de qualidade de serviço (QoS).

O “overhead” resultante de um quadro IP com Token Ring com 4399 bytes sobre um protocolo 802.1D/Q é de 29 bytes.

2.4-Interface de Dados Distribuída por Fibra (FDDI)

O padrão FDDI possui um mecanismo de prioridade que pode ser utilizado para o enfileiramento dos pacotes que serão transmitidos e para o acesso ao meio compartilhado. O mecanismo de prioridade é semelhante ao implementado no sistema Token Ring.

2.5-Prioridade de Demanda/ IEEE 802.12

O padrão IEEE 802.12, protocolo MAC chamado de Prioridade de Demanda, é utilizado para LAN’s de 100Mbps mistas. Os pacotes de dados podem ser transmitidos usando o formato IEEE 802.3 ou IEEE 802.5. No IEEE 802.12 temos dois níveis de prioridade, alta prioridade e prioridade normal.

Se o formato de quadro for o IEEE 802.3 a prioridade do usuário é colocada no começo do pacote de dados do IEEE 802.12. Se o quadro for IEEE 802.5 a prioridade é colocada nos bits do campo FC do próprio IEEE 802.5. Depois, através do encápsulamento IEEE 802.1Q com seu próprio campo de prioridades o quadro é aplicado na rede IEEE 802.12. Em todos os casos os switches são capazes de recuperar a prioridade do usuário transmissor.

Os pacotes, IEEE 802.5 e IEEE 802.1Q, com prioridade de 0 até 4 são transformados para prioridade normal e o restante para alta prioridade. No IEEE 802.12 os pacotes de alta prioridade sempre terão prioridade de transmissão em relação aos pacotes de baixa prioridade. Para não gerar o problema de um pacote de baixa prioridade não ser nunca transmitido, a cada período de 200ms a 300 ms de espera do pacote de baixa prioridade ocorre à promoção de prioridade deste pacote.

3-Necessidades e Objetivos

Os objetivos são os quesitos, de serviços integrados, que poderão ser implementados ou não, enquanto as necessidades são os quesitos que deverão ser implementados.

3.1-Necessidades

· Reserva de Recursos: O mecanismo deve ser capaz de reservar recursos para um segmento simples ou para múltiplos segmentos e para bridges/switches conectados a ele. Ele deve ser capaz de reservar recursos para “unicast” e para “multicast”.

· Controle de admissão: O mecanismo deve ser capaz de identificar a quantidade de recursos que determinada transmissão necessita, para determinada QoS. O sistema deve decidir se a transmissão é possível ou não.

· Separação de fluxo e agendamento: O sistema deve ser capaz de separar o fluxo “best effort” do fluxo em tempo real. Os pacotes em tempo real devem poder ser isolados e agendados de acordo com as necessidades do serviço.

· Monitorando/Padronizando: O tráfego deve ser padronizado e ou controlado pelas estações finais (wokstations, roteadores) para garantir os parâmetros de tráfego negociado. O rotedor inicia uma seção ISSLL de acordo com o mecanismo de controle de tráfego que assegure o serviço integrado.

· Software de estado: O mecanismo deve manter um software de estados de reserva de recursos, que será periodicamente atualizado.

· Implementações centralizadas e distribuídas: No caso de implementações centralizadas uma só entidade gerencia os recursos da subnet. A vantagem de um sistema centralizado é que um único equipamento necessita ser configurado. Porém, em sistemas geograficamente distribuídos uma configuração centralizada não é muito adequada. Em implementações totalmente distribuídas cada segmento da rede é controlado por uma entidade da rede. O problema de um sistema totalmente distribuído é que cada gerenciador deve ser configurado para controlar os recursos de sua região. Uma alternativa seria sistemas mistos, semidistribuídos.

· Escalabilidade: O sistema deve gerar baixo “overhead” e agrupar muitos receptores.

· Tolerância e recuperação de falhas: O sistema deve ser capaz de funcionar mesmo na presença de um ponto de falha. Em sistemas centralizados deve-se ter uma forma de “back-up” e recuperação em caso de falhas.

· Interação com sistemas de gerenciamento de recursos já existentes: O mecanismo deve ser desenvolvido para aproveitar e interagir com os controles já existentes.

3.2-Objetivos

· Independência de protocolos de camadas superiores: O sistema deve ser, o máximo possível, independente de protocolos como RSVP e IP.

· Heterogeneidade de receptores: Esta questão é referente a sistemas multicast em que diferentes receptores requerem diferentes níveis de serviço. O sistema deve reservar diferentes níveis de recurso para diferentes tipos de serviço.

· Suporte para diferentes estilos de filtros: É desejável que o sistema dê suporte para diferentes estilos de filtros definidos pelo RSVP como os filtros fixos e outros.

· Seleção de caminho: Seleção de um caminho apropriado que otimize a utilização dos recursos da rede.

3.3-Suposições

Supõe-se que as sub-redes possuem muitos switches e que a comunicação entre duas estações, utilizando serviços integrados, passa pelo menos por um switch. Os mecanismos e protocolos são facilmente extensíveis para comunicar sistemas no mesmo meio compartilhado. O sistema poderá operar com protocolos de camadas superiores como RSVP e SBM (Gerenciador de largura de banda da sub-rede) de forma independente. O sistema será composto por uma mistura de switches com diferentes capacidades, desde sistemas simples com duas filas por portas até sistemas múltiplas filas. O problema será decomposto nas menores partes independentes, que carregarão os recursos da rede e influenciarão na sua vizinhança.

A principal suposição do modelo IntServ que os fluxos são isolados dos outros que transitam através da rede. Os nós intermediários controlarão e padronizarão o tráfego, o que diverge das necessidades feitas acima, de acordo com as especificações da rede. Esta proposta é feita devido à heterogeneidade dos receptores que possuem diferentes formas de alocar recursos.

4-Arquitetura básica

As funções acima requeridas são referentes ao Gerenciador de largura de banda (BM), que é responsável por fornecer, para aplicações de camadas superiores, o QoS da rede. Para a arquitetura da rede proposta, o BM consiste dos seguintes componentes.

4.1-Componentes

4.1.1-Módulo de pedido

O módulo de pedido (RM) está presente em todas estações finais da sub-rede. Uma das funções do RM é fornecer uma interface com os protocolos de camadas superiores ou entre aplicações e o BM. Uma aplicação pode fazer vários pedidos para o BM em função das primitivas utilizadas. Para iniciar a reserva de recursos alguns parâmetros de pedido são passados para o RM. O serviço desejado (serviço garantido ou carga controlada), os descritores de tráfego, que estão contidos no TSpec e as especificações de recursos que estão no RSpec. O RM deve traduzir o endereço da camada de rede para o endereço da camada de enlace de dados. Outra função do RM é de retornar o estado do pedido feito pela aplicação ou protocolo de camadas superiores.

4.1.2-Alocador de largura de banda

O alocador de largura de banda (BA) é responsável pela admissão, controle e manutenção do estado da reserva de recursos na sub-rede. Uma estação final pode fazer vários pedidos como reserva de largura de banda, modificação da reserva já existente e perguntas sobre os recursos disponíveis. Estes pedidos são processados pelo BA. A comunicação entre a estação final e o BA é feita através do RM. O BA pode estar presente em diversos locais dependendo da configuração da rede, centralizada ou distribuída. Se for centralizada estará em uma única estação. Se for distribuída estará presente em todas estações, switches/bridges. O BA também é responsável pelo controle do fluxo, baseado em um sistema de decisão para admissão. O BA indica para o RM a que classe de tráfego determinado pacote, com determinada prioridade, será mapeado.

4.1.3-Protocolos de comunicação

Os protocolos de comunicação entre os vários componentes do sistema BM devem possuir:

· Comunicação entre protocolos de camadas superiores e o RM: O BM deve definir primitivas para a aplicação como iniciar reserva de recursos, perguntar, sobre recursos disponíveis, modificar ou acabar com a reserva de recursos.

· Comunicação entre RM e o BA: Um mecanismo de sinalização deve ser definido para a comunicação entre o RM e o BA. O protocolo de definir as mensagens que devem ser trocadas entre o RM e o BA em função dos pedidos das camadas superiores.

· Comunicação entre BA’s: Se existir mais de uma BA por sub-rede, cada BA deve ser capaz de decidir se é ou não responsável pelo segmento, pela bridges ou switches. Caso ocorra erro a comunicação entre as BA’s deve ser capaz de recuperar a falha.

4.2-Implementações centralizadas X Implementações distribuídas

A diferença entre um sistema centralizado e um sistema distribuído está no BA. Em um sistema centralizado o BA está presente em um único local, em quanto que em um sistema distribuído o BA está presente em todas as estações finais. O RM está presente em todas as estações independentemente da configuração.

No sistema centralizado o RM está nas estações finais. Porém não está presente nos switches e bridges, pois não participam ativamente do controle de admissão. A figura 1 apresenta a arquitetura do sistema com BA centralizado.

Figura 1, Gerenciador de largura de banda centralizado.

Para sub-redes muito grandes um único BA não é capaz de gerenciar sozinho a sub-rede. Nestes casos é necessário utilizar vários BA’s, que gerenciarão cada um deles uma parte da sub-rede. Para esse tipo de situação existe a necessidade de um conhecimento da topologia da sub-rede para um controle mais eficiente dos recursos. Nesta topologia todos os dispositivos possuem alguma parte do BM. Todas estações finais possuem RM e BA, enquanto os switches e bridges possuem somente BA.

Figura 2, Gerenciador de largura de banda totalmente distribuído.

5-Modelo do Gerenciador de largura de banda na rede

Nesta seção será descrito como o modelo de BM se adapta ao sistema de serviços integrados IETF de endereços IP e roteadores.

5.1-Modelo de Estações finais

5.1.1-Camada 3, modelo do cliente

Nós assumiremos o mesmo modelo de cliente do IntServ e RSVP, onde nós usamos o termo cliente para cada usuário da QoS, dispositivo na camada 3 que está no final do domínio da camada 2. Neste modelo, o cliente é responsável pelo controle da admissão local e agendamento das conexões de acordo com o serviço negociado.

Para um primeiro momento será considerado que o cliente usará um processo RSVP. Neste processo RSVP estará presente uma seção de interface com a aplicação, sinalização da rede, agendamento programado e classificador, e interfaces para monitoramento do módulo.

A figura 3 reproduz as especificações RSVP em um processo de envio de hosts.

Figura 3, RSVP enviando hosts.

5.1.2-Pedidos para a camada 2 ISSLL (serviço integrado sobre link específico)

A entidade de controle de admissão dentro do cliente é responsável pelo mapeamento da camada 3 estabelecendo um pedido na camada 2. Entidades das camadas superiores fazem pedidos, em termos gerais para ISSLL do tipo:
“Eu desejo reservar para tráfego com <características de tráfego > com < performance necessária> de <aqui> até <lá>.”

Onde

<característica de tráfego> = Transmissor Tspec (largura de banda).

<performance necessária> = FlowSpec (latência).

<aqui> = endereço IP.

<lá> = endereço IP (pode ser multicast).

5.1.3-Transmissor para a camada 3

As funções do RM, transmissor, podem ser resumidas como:

· Mapear os pontos finais de conversação para endereços da camada 2 da LAN.

· Comunicar com o BA para a decisão do controle de admissão.

· Criar em função do pedido do SBM, filtros de endereços.

· Receber a resposta da rede e negociar com as camadas superiores os parâmetros da seção.

· Retornar alguma prioridade para o usuário de acordo com a tabela IEEE 802.

Figura 4, ISSLL em uma estação final transmissora

O BA só está presente quando existe o modelo distribuído, e quando presente é basicamente aplicado ao controle de admissão local.

5.1.4-Receptor para a camada 3

As funções do RM, receptor, podem ser resumidas como:

· Manipular qualquer dado de indicação do protocolo SBM.

· Comunicar com algum BA local, para a decisão do controle de admissão local.

· Passar, se tudo certo, indicações para o RSVP.

· Aceitar as confirmações do RSVP e responde-las através da sinalização SBM.

· Um programa deve receber o agendamento e a classificação do tráfego, para reservar os recursos da rede.

· O programa receptor deve retirar as informações do cabeçalho do pacote.

Figura 5, ISSLL em uma estação final receptora.

5.2-Modelo de switch

5.2.1-Alocador de largura de banda centralizado

Em um sistema centralizado não existe um BA no switch, o BA está co-localizado ao switch. O sistema de controle de admissão é implementado pelo SBM.

5.2.2-Alocador de largura de banda distribuído

As características de um switch com protocolo SBM são:

Módulo de controle de admissão local: Um destes em cada porta estima a largura de banda disponível em cada porta.
Módulo de entrada SBM: Realiza os pedidos sobre as performances de cada porta da rede, para informar os clientes e os switches.
Módulo de propagação SBM: Transmissões pedem que o controle de admissão seja passado de uma entrada para uma saída SBM.
Saída de módulo SBM: Passa os pedidos para a próxima camada 2 ou para a camada 3.

· Módulo classificador, agendador e fila: O módulo classificador identifica as informações importantes dos pacotes. As informações serão utilizadas posteriormente pelas bridges que encontrarão a porta de saída, e a correspondente classe pedida. A fila e o agendador implementam, as filas de saída das portas que estarão de acordo com os parâmetros de serviços integrados.

Módulo de classificação do tráfego de entrada e monitoramento: Este módulo monitora o tráfego de entrada e descarta, caso o tráfego não esteja de acordo com os parâmetros negociados.
Módulo de classificação do tráfego de saída: Este módulo mapeia novamente, se necessário, as classes de tráfego de cada porta.

Na figura 6 é apresentado o modelo ISSLL em um switch, que é um super conjunto do modelo de uma bridge IEEE 802.1D.

Figura 6, switch ISSLL.

5.3-Controle de admissão

O controle de admissão recebido através do SBM é usado como exemplo. O comportamento depende da localização do “SBM desenvolvido”, se está dentro ou fora do switch.

Se a entrada do SBM é “desenvolvida” para um específico link, ele ou traduz a prioridade do usuário ou procura a alternativa de classe de tráfego mais próxima disponível.
A entrada do DSBM verifica o estado dos recursos disponíveis e tenta alocar recursos, para a entrada, em alguma classe. O pedido é repassado para o propagador de reservas se aceito.
Se o SBM não for desenvolvido para um determinado link, ele passa o pedido para o propagador de reservas.
O propagador de reservas transmite o pedido para o estimador de largura de banda. Depois, é verificada a possibilidade de reservar recursos em alguns switches.
O estimador de largura de banda verifica o estado das filas de alocação de recursos, dependendo das condições a nova alocação é feita.
O pedido se aceito, pelos switches, é propagado para cada saída dos link’s selecionados.
Se aceito, a confirmação e a prioridade do usuário deve ser passada para o cliente.
Se não aceito, o cliente é notificado.

5.4-Sinalizando QoS

O mecanismo descrito nesta seção é usado para comunicar, através de um protocolo de sinalização, os pedidos do controle de admissão pela rede. Os serviços fornecidos pelo protocolo serão descritos abaixo.

5.4.1-Definições de serviços para o cliente

SBMÛMapeamento de endereços.

Esta é uma função que interage com o protocolo ARP ou algum algoritmo de mapeamento. O endereço da camada 2 é necessário para evitar a utilização de switches, na sinalização são necessárias informações da camada 3 para o mapeamento.

l2_addr = map_address( ip_addr ).

SBMÛ Cabeçalho da camada de enlace de dados.

Informa o caminho de transmissão, através do cabeçalho da camada 2, os valores de prioridade do usuário.

bind_l2_header( flow_id, user_priority ).

SBMÛ Classificador/agendador.

Informa o classificador/agendador de alguma informação adicional associada com o agendamento do fluxo de transmissão de pacotes.

bind_l2schedulerinfo( flow_id, , l2_header, traffic_class ).

SBMÛ Controle de admissão local.

É utilizado para verificar se existe largura de banda suficiente, tamanho de buffer de recepção suficiente, para fazer o controle de admissão local.

status = admit_l2session( flow_id, Tspec, FlowSpec ).

SBMÛ RSVP.
Gerenciamento de interfaces.

5.4.2-Definições de serviços do switch

SBMÛ Classificador.

Informa para o receptor classificador qual é a informação de tráfego associada a alguma classe especifica.

bind_l2classifierinfo( flow_id, l2_header, traffic_class ).

SBMÛ Fila e agendador de pacotes.

Informa o transmissor agendador sobre informações adicionais de uma classe de tráfego.

bind_l2schedulerinfo( flow_id, l2_header, traffic_class ).

SBMÛControle de admissão local.

Mesma função do Controle de admissão local anterior.

SBMÛMapeamento e controle de classe.

Remapeia a prioridade do usuário nas portas de entrada e de saída de um switch.

bind_l2ingressprimap( inport, in_user_pri, internal_priority )

bind_l2egressprimap( outport, internal_priority, out_user_pri )

Controla o tráfego atingido por classe.

bind_l2policing( flow_id, l2_header, Tspec, FlowSpec ).

SBMÛFiltrando base de dados.

A propagação das regras do SBM necessitam de uma base de dados da camada 2 para determinar onde enviar as mensagens SBM.

output_portlist = lookup_l2dest( l2_addr ).

Gerenciamento de recurso.

6-Implementação

O grupo de trabalho de serviços integrados define várias classes de serviços com diferentes níveis de QoS. O serviço de carga controlada é equivalente ao “best effort” e não garante nenhum parâmetro de QoS. Enquanto que o serviço garantido tenta aproximar ao máximo os parâmetros desejados, o que nem sempre é possível devido à configuração da rede.

6.1-Características do switch

O tipo de bridge mais básico foi especificado pelo IEEE 802.1D, em 1993. Este dispositivo possui uma fila por porta de saída. Redes construídas com dispositivos deste tipo não fornecem serviço garantido.

O próximo nível de bridge/switch é o que segue uma versão revisada da IEEE 802.1D. A versão revisada da IEEE 802.1D especifica até oito filas de classes de tráfego separado. Porém este nível de bridge/switch possui limitações com fluxos de dados sem comportamento (prioridade) e com tráfego multicast.

O próximo passo dos dispositivos descritos acima são os dispositivos em que se consegue mapear, através da prioridade do usuário recebida, uma série de parâmetros de entrada. Os parâmetros de entrada serão mapeados em valores de transmissão na saída do switch, o que aumentará o controle do tráfego. Outras funções interessantes seriam a de agendamento e classificação do serviço através de algum campo do cabeçalho da camada de rede.

6.2-Filas

Com o advento de tráfegos que dependem do tempo, viu-se necessária à criação de sistemas que consigam identificar e dar maior prioridade de recursos a essas aplicações. Quanto maior for a prioridade, que certa aplicação recebe, maior é a necessidade de um agendamento disciplinado e um enfileiramento que separe as classes. Para obter um maior isolamento entre as classes de prioridade é necessário um sistema inteligente de enfileiramento.

6.3-Mapeamento do serviço para o nível de prioridade do link

O número de classes de tráfego e métodos de acesso da tecnologia define que serviços são suportados. Porém os novos padrões IEE 802 definem novas características para bridges/switches relacionados a tráfego multimídia e filtros multicast dinâmicos. O pacote carrega a prioridade do usuário em toda a LAN 802. A prioridade do usuário é mapeada em uma das oito classes de tráfego dentro do switch/bridge. A classe de tráfego é definida pela qualidade do serviço desejado.

O usuário deve utilizar o valor de prioridade de usuário do “best effort”, enquanto o BM não reservar os recursos. Depois de alocados os recursos o BM dará um valor especifico de prioridade para o usuário.

6.4-Re-mapeamento de fluxos em não conformidade

Quando o fluxo de algum usuário utiliza mais recursos do que lhe foi negociado isto gera um problema. Uma penalidade que torna os recursos do seu fluxo, prioridade, menor ou igual aos do “best effort”,é uma solução. Porém como o “best effort” é adaptativo, devido ao TCP, muitas vezes essa penalidade fica sem efeito ou difícil de ser definida. Devido ao problema da adaptação é mais conveniente cortar o excesso de tráfego do que re-mapear para uma prioridade inferior.

6.5-Prioridade do usuário acumulada em excesso

Em alguns casos a prioridade de um serviço pode mudar ou ser recebida errada. Uma alternativa é o re-pedido do valor da prioridade para o usuário. Em sistemas mais sofisticados o tráfego é monitorado e auto-ajustado, se necessário, para um novo valor de prioridade.

6.6-Diferentes tipos de reservas

Quando temos a situação em que podemos receber os mesmos dados de mais de um local, nós temos a seguintes situações de transmissão:

1. Um transmissor específico. (filtro fixo)

2. Qualquer de dois ou mais transmissores específicos. (filtro explícito compartilhado)

3. Qualquer transmissor do grupo. (filtro compartilhado wildcard)

O fornecimento dos dois últimos filtros pelo switch implica em um monitoramento do tráfego enviado.

6.7-Heterogeneidade de receptores

Os ramos de uma rede podem ter diferentes necessidades em relação à qualidade de serviço. Alguns ramos podem trabalhar com “best effort”, enquanto outros necessitam de algum QoS. Porém se todos os ramos necessitarem de processo onde todos necessitam de QoS, que aloca mais recursos, o sistema terá que rejeitar alguns pedidos.

Quando temos receptores diferentes, presentes no mesmo ramo, recebendo o mesmo dado, multicast, um em “best effort” e outro com QoS existe a necessidade de se decidir como será feita está transmissão. Uma alternativa é transmitir o dado uma vez só com QoS. Outra alternativa é de se criar vários canais com diferentes níveis de classe de serviços, porém esta alternativa aumenta o número de dados a serem transmitidos em função da quantidade de classes de serviço. No caso de dois receptores em ramos diferentes pode-se criar conexões diferentes para cada switch.

Na transmissão multicast um único pacote de dados é transmitido para diversos receptores. Se os receptores tiverem prioridades diferentes não será possível a recepção, através dos recursos da camada 2. O motivo é que um receptor com recursos de uma classe x não consegue receber dados enviados para uma classe y.

7-Topologias de rede

Para uma rede fornecer serviço garantido são necessárias a identificação e agendamento de fluxo, junto com um controle de admissão e monitoramento. Nesta seção serão apresentadas algumas topologias e tecnologias de LAN’s que podem garantir as necessidades acima. As topologias consideradas aqui são meio compartilhado, comutado half duplex ou full duplex. Na topologia compartilhada, Ethernet, Token Ring e FDDI, múltiplos transmissores compartilham um simples segmento. O half duplex comutado, é uma topologia compartilhada em que somente dois transmissores concorrem pelos recursos no segmento. O full duplex é uma topologia em que toda a largura de banda é fornecida para o transmissor o tempo todo, possui maior capacidade de QoS. Outro fator importante é o suporte para várias classes de tráfego. Serão consideradas seis situações:

1. Compartilhado sem classes de tráfego.

2. Compartilhado com classes de tráfego.

3. Comutado half duplex sem classes de tráfego.

4. Comutado half duplex com classes de tráfego.

5. Comutado full duplex sem classes de tráfego.

6. Comutado full duplex com classes de tráfego.

Existe a possibilidade também de topologias híbridas onde uma ou mais configurações podem coexistir.

7.1-Redes comutadas full duplex

Em redes comutadas full duplex, a camada MAC não é importante. Nesta configuração o estado de latência é igual ao tempo necessário para transmitir o maior pacote. Os valores aproximados das características de vários meios estão na tabela 2.

Tipo	Velocidade	Máximo tamanho de pacote	Máxima latência de acesso
Ethernet	10 Mbps 100 Mbps 1 Gbps	1.2 ms 120 us 12 us	1.2 ms 120 us 12 us
Token Ring	4 Mbps 16 Mbps	9ms 9ms	9ms 9ms
FDDI	100 Mbps	360 us	8.4 ms
Prioridade de demanda	100 Mbps	120 us	120 us

Tabela 2, latência nos meios de acesso full duplex comutado.

Esta topologia oferece grande capacidade de Qos, para carga controlada e serviço garantido.

7.2-Redes de meio compartilhado Ethernet

É problemática do ponto de vista de alocação de recursos e problemas de latência no CSMA/CD com vários transmissores.

7.3-Redes Ethernet full duplex comutadas

Possui os mesmos problemas encontrados nas redes de meio compartilhado Ethernet.

7.4-Redes Token Ring compartilhada e half duplex comutada

Em redes Token Ring, o tempo de acesso do tráfego de maior prioridade está em torno de (N+1)*THTmax, onde N é o número de estações enviando com alta prioridade de tráfego e THTmax é o máximo intervalo de token. O tempo THTmax mais comum é de 10ms. N é um inteiro que vai de 2 até 256 para um anel compartilhado. No caso da topologia half duples comutada N = 2, a mesma análise será usada para FDDI.

Tipo	Velocidade	Máximo tamanho de pacote	Máxima latência de acesso
Token Ring Compartilhado	4/16 Mbps	9 us	2570 ms
Token Ring comutado	4/16 Mbps	9 us	30 ms
FDDI	100 Mbps	360 us	8 ms

Tabela 3, latência nos meios de acesso Token Ring half duplex comutado, Token Ring compartilhado e FDDI.

Os valores de tempo de espera levam em consideração o pior caso em que todas as estações possuem valor de prioridade alto. Porém o sistema de controle de admissão usa um número fixo de estações de alta prioridade. Como este número de estações de alta priorida-de é controlado é possível garantir pequenos atrasos em serviços garantidos.

7.5-Redes half duplex e Prioridade de demanda compartilhada

Em redes IEEE 802.12, a comunicação entre nós finais e hubs, hubs e hubs, é baseada na troca de sinais de controle. Estes sinais são utilizados para o acesso ao meio compartilhado. Se um hub recebe um pacote de dados de alta prioridade, este pacote será imediatamente processado.

O tempo de acesso à rede para um pacote de alta prioridade é basicamente o tempo necessário para retirar o serviço de prioridade normal. O tempo de também depende da topologia da rede e da camada física. Os dados da tabela 4 são referentes ao par trançado sem blindagem (UTP) com 100 m e com tempo máximo de atraso de propagação de 570 ns. Estes valores consideram o pior caso de “overhead” de sinalização e supõe o tamanho de pacote máximo, para o sinal de prioridade normal que estava recebendo o serviço.

Tipo	Velocidade	Máximo tamanho de pacote	Máxima latência de acesso
Prioridade de demanda pacote 802.3, UTP	100 Mbps	120 us	254 us
Prioridade de demanda pacote 802.3, UTP	100 Mbps	360 us	733 us

Tabela 4, latência de acesso no Prioridade de demanda UTP half duplex comutado.

Uma rede IEEE 802.12 pode ser classificada de acordo com o número de hubs em cascata. Para a camada física UTP o padrão indica o máximo de 5 níveis. Várias redes compartilhadas possuem nível 2 com algumas centenas de nós.

Supondo uma fibra ótica, operando no modo dual simplex, com 2 km de extensão multimodo, com dois níveis de cascata de hubs, que é o máximo permitido pelo padrão para a distância. Comparando a fibra com o caso utilizando UTP anterior vemos uma melhoria significativa no tempo de latência.

Tipo	Velocidade	Tamanho máximo do pacote	Máxima latência de acesso
Prioridade de demanda pacote 802.3, fibra	100 Mbps	120us	139 us
Prioridade de demanda pacote 802.5, fibra	100 Mbps	360us	379 us

Tabela 5, latência de acesso no Prioridade de demanda fibra half duplex comutado.

RFC 2815

8-Introdução

A opção de diferenciar as filas por tráfego e os mecanismos de controle e sinalização de admissão, tornaram as redes IEEE 802 mais próximas das necessidades de serviços integrados. Neste artigo serão apresentadas formas de mapear classe de serviço e parâmetros do IETF em parâmetros de redes IEEE 802.1D. O mapeamento de níveis de prioridade IP em classes de tráfego da camada 2, o uso da sinalização RSVP/SBM entre outros também serão abordados.

9-Identificação de tráfego e seleção de classe de tráfego

Um sistema de camada 2 para suportar serviços integrados deve ser capaz de manipular pacotes baseado no fluxo RSVP e especificações de filtros, e utilizar as especificações para classificar os pacotes de dados. Uma implementação na camada 2 com um switch que faz filtragem é muito cara, a medida que aumenta a velocidade do switch.

Os serviços integrados sobre LAN’s IEEE 802 usam um modelo que agrega os fluxos em classes. Neste modelo cada fluxo que chega é marcado com uma classe em seu trajeto. Os tráfegos que necessitam de serviços parecidos são agrupados em uma classe, enquanto que os sistemas de controle de admissão e seletores de regras de classes asseguram os parâmetros de serviço para cada classe de fluxo. Neste modelo o tráfego chega com uma classe definida representada pela “prioridade do usuário”. Duas perguntas são fundamentais neste modelo:

1- Quem determina a correspondência entre o nível IP de tráfego e a classe do nível do link?

2-E como a correspondência deve ser disposta no quadro de dados?

Uma resposta a essas perguntas é a criação de classes universalmente definidas. Esta RFC define quatro padrões de classes 1 = best effort, 2 = 100 ms de pico de delay, 3 =10 ms de pico de delay e 4 = 1 ms de pico de delay. Essas classes universalmente definidas devem ser codificadas nas estações finais, e o mapeamento dos fluxos em classes nos dispositivos de controle da rede.

Esta definição universal é fácil de ser implementada, mas é muito difícil o mapeamento das grandes possibilidades serviços em um número reduzido de classes. No modelo descrito no IS802FRAME o cliente pergunta para a rede que classe de prioridade de usuário o seu fluxo receberá. O valor de prioridade é baseado na topologia da rede, condições de carga e fluxo admitido.

No modelo atual todos os pacotes são tratados com o mesmo nível de prioridade, porém quando existe a necessidade de QoS é preciso criar serviços com prioridades distintas. A prioridade é um parâmetro definido pela rede, por isso depende de um protocolo de perguntas e respostas entre o cliente e a rede. Os pedido e respostas são feitos para o controle de admissão. As perguntas que a rede deve responder para o cliente são.

1-Qual é a classe de tráfego apropriada para este fluxo?

Em geral é verificado o atraso que o fluxo pode aceitar. Por exemplo, se o fluxo suportar 10ms de atraso o fluxo será agrupado na classe de 10ms.

2-Das classes existentes, alguma tem capacidade o bastante para suportar esse fluxo?

Este é um problema de controle de admissão. É necessário comparar o nível de tráfego corrente em cada classe com os recursos livres da rede. Para assegurar que o novo fluxo não atrapalhe o desempenho dos outros fluxos da mesma classe.

Se as perguntas forem positivamente respondidas a rede retorna para o cliente o valor da prioridade do usuário.

10-Encontrando uma classe de prioridade de usuário para o fluxo

Nesta seção é apresentada uma forma de mapear os níveis de fluxos IP em valores de classes de prioridade de usuário IEEE. Os tipos de níveis IP de serviço considerados são o best effort, carga controlada e serviço garantido.

Os pedidos para o sistema de controle de admissão e as necessidades das aplicações são especificadas em termos de um vetor multidimensional, tendo como parâmetros largura de banda, atraso, jitter e classe de serviço. Os parâmetros do vetor multidimensional devem ser mapeados dentro de um conjunto de classes de tráfego. Esses conjuntos de classes de tráfego fornecem somente uma prioridade no enfileiramento entre as diferentes classes. A divisão em classes não garante o absoluto controle de perda de pacotes e nem o atraso.

Para fornecer o absoluto controle da perda e do atraso dos pacotes, ocorrerem três coisas:

1- A quantidade de largura de banda disponível para um fluxo com QoS controlado deve ser conhecida, e o número de fluxos admitidos deve ser limitado.

2- O mecanismo de agendamento de tráfego deve ter preferência em relação a outros serviços.

3-Algum mecanismo deve assegurar que os fluxos do best effort e QoS controlado que excedam as suas disponibilidades, não atrapalhem outros fluxos.

Nas redes IEEE 802, a primeira função, o controle de admissão, é fornecida pelo SBM. O nível do link é utilizado para a segunda função, serviço preferencial para fluxos com necessidades de atrasos baixos. O mecanismo de controle dos fluxos, terceira função, geralmente é implementada por algum dispositivo da camada 3.

10.1-Contexto do controle de admissão e taxas de atraso

O mecanismo proposto anteriormente propõe que o controle de admissão determina que tipo de Int-Serv é oferecido. Dado um conjunto de classes de prioridade de carga controlada com os seus respectivos atrasos, largura de banda, devem ser oferecidos com uma restrição. Os recursos de um carga controlada não devem exceder os recursos do serviço garantido. As taxas de atraso são controladas pelo controle de admissão que está na camada 2, enquanto que os alocadores de banda precisam de partes de dispositivos da camada 3.

10.2-Mapeando serviços

Na tabela 6 são apresentados os valores dos atrasos das classes de prioridade de usuário do IEEE 802.1, porém estes valores podem ser modificados. A modificação pode ser feita nos switches se o gerenciamento de controle achar necessário. No futuro as redes ajustarão as tabelas automaticamente sem a intervenção humana. Através de algum serviço que pergunte ao cliente a classe de serviço e notifique para o switch a sua categoria de tráfego.

Os atrasos da tabela 6 são valores subjetivos típicos de algumas aplicações como voz e vídeo.

Prioridade do usuário	Serviço
0	Normal , best effort
1	Reservado, menos que o best effort
2	Reservado
3	Reservado
4	Sensível a atraso, sem taxa
5	Sensível a atraso, taxa de 100 ms
6	Sensível a atraso, taxa de 10ms
7	Controle da rede

Tabela 6, prioridade do usuário mapeado para serviços.

Pode-se perceber que os valores de atraso estão na ordem inversa em relação à quantidade de atraso. Em relação ao mapeamento não é definido qual mecanismo ou algoritmo deve implementar o mapeamento.

10.3-Comentários

A recomendação das classes 4,5 e 6 como sensíveis a atraso, em alguns controles de admissão, é um tanto arbitrário. Em switches que seguem a recomendação IEEE 802.1D existem duas classes de prioridade.Todos os sensíveis a atraso possuem alta prioridade.

A escolha das taxas de atraso foi ajustada para uma média de uma mistura de aplicações. Pois várias aplicações com diferentes tolerâncias de atraso estão presentes. Esta divisão cria um isolamento entre os tráfegos, o que torna a alocação de recursos mais eficiente.

Colocar o controle da rede para o tráfego de classe 7 é necessário, pois protege tráfegos importantes como os de atualizações e gerenciamento da rede. Porém esta alta prioridade afeta a capacidade de fornecer QoS com segurança. Para gerenciar este controle do tráfego da rede existe um dispositivo de controle de admissão o SBM.

O tráfego da classe 1, menos que o best effort, pode ser usado para penalizar aplicações que excedam suas reservas de recursos. Isto é necessário para isolar os fluxos que cumprem seus contratos dos que não cumprem e prejudicam a qualidade de serviços dos que cumprem. Os fluxos não cumpridores são colocados na classe 1 por algum tempo, mais ordenamentos das filas, ou para sempre.

11-Caracterização dos parâmetros de serviços integrados para dispositivos IEEE 802

No modelo de serviços integrados cada elemento de rede que suporta serviços integrados computa e faz caracterizações de parâmetros que descrevem o comportamento dos elementos. Os parâmetros são computados por cálculos, medidas ou estimações. No caso do IEEE 802 é muito difícil computar os parâmetros com precisão para algumas topologias e algumas tecnologias de switches. Para caracterizar os parâmetros assumiremos um modelo simples de switch que fornece valores que descrevem os dispositivos e admite fluxos conservadoramente.

11.1-Caracterização geral dos parâmetros

Há alguns parâmetros que os dispositivos necessitam usar ou fornecer para todos tipos de serviços.

Acesso ao link.
Saída do link e seus MTU’s. (overhead, mínimo tamanho de pacote)
Largura de banda disponível no caminho.
Mínima latência.

Destes parâmetros, o MTU e o tamanho mínimo de pacote são informações que devem ser fornecidas com precisão. Também, a “quebra de bits” deve ser feita corretamente, pois todos os indicadores de controle de QoS são feitos por bits individuais. A largura de banda disponível pode ser informada com uma precisão menor. A latência deve ser precisa para os elementos de serviços garantidos e menos precisa para elementos de serviços controlados.

11.2-Parâmetros para implementar serviço garantido

Um elemento de rede para suportar serviço garantido deve ser capaz de determinar os seguintes parâmetros:

· Atraso constante através do dispositivo e a entrada no receptor da próxima rede, incluindo valores como propagação através do link.

· Razão proporcional de atraso constante através do dispositivo e a entrada no receptor da próxima rede, incluindo valores como propagação através do link.

· Recursos do receptor devem ser associados com o fluxo (tamanho do buffer, largura de banda) se admitem ou não perda de pacotes e se matem o dentro do Tspec/Rspec fornecido.

· Recursos do transmissor devem ser associados com o fluxo (atraso, largura de banda, tamanho de buffer), caso o fluxo seja aceito.

Os dois últimos parâmetros acima são utilizados para o controle de admissão. Os parâmetros devem ser bem precisos, pois alguma mudança pode melhorar ou piorar o desempenho do serviço.

11.3-Parâmetros para implementar carga controlada

Os elementos de um serviço de carga controlada devem ser capazes de:

· Recursos do receptor devem ser associados com o fluxo (tamanho do buffer, largura de banda), se admitidos.

· Recursos do transmissor devem ser associados com o fluxo (tamanho de buffer), caso o fluxo seja aceito.

Os parâmetros acima são utilizados para o controle de admissão. O carga controlada não exporta nenhum serviço especial de caracterização de parâmetros.

11.4-Parâmetros para implementar o best effort

Em sistemas que implementam somente o best effort não existem parâmetros a serem caracterizados.

12-Unindo partes do RSVP/SBM

Não existe uma regra simples de união que prevê todos os efeitos colaterais abaixo:

Se em um ramo, um novo fluxo necessita de um tráfego com grande atraso isto será danoso para o fluxo já existente que receberá um serviço pior do que antes.
Fluxos novos com baixo atraso sofrerão mais com as falhas do controle de admissão ou outros problemas do que os fluxos anteriormente admitidos, no mesmo ramo.
A promoção de um novo ramo deve ser carregada para rejeitar os pedidos, porque re-classificará para uma classe de tráfego em que não há recursos suficientes para acomoda-los.

A seleção da classe de tráfego é baseada na informação do Tspec. Quando o primeiro RESV chega a classe de tráfego é procurada com base no pedido. Um SBM TCLASS é inserido dentro da mensagem e do controle de admissão para que esteja pronto para o SBM. No segundo RESV o mesmo fluxo chega em um ponto de entrada diferente e o processo começa novamente. O RESV é uma pergunta para o switch verificar se existem recursos para determinado serviço. Se a segunda tentativa não der certa é enviada a mensagem de ResErr (erro de reserva) para a camada 3.

13-Aplicações do mapeamento de serviços

Switches que usam somente padrões da camada 2, precisam interoperar com os roteadores e switches camada 3. Os dispositivos de camada 2 podem operar nas seguintes situações:

· Todos dispositivos ao longo do caminho da rede são camada 3.

· Somente dispositivos de interface são camada 2.

· Todos dispositivos alternados não têm funções da camada 3.

· A maioria dos dispositivos não tem camada 3, exceto por algum controle local.

Se um fluxo de INT_SERV passar por algum equipamento que não suporta serviços integrados ou controle de tráfego 802..1D e que coloca todos os pacotes na mesma fila é obvio que o serviço não atingirá os parâmetros desejados. Para fornecer serviço garantido e controlado é necessário que todos elementos da rede participem do tratamento dos pacotes, aplicando regras de QoS.