Blocos de um sistema multimidia

Um modelo conceitual para QoS em redes envolve identificar um conjunto de blocos básicos, como ilustrado a seguir. Dois atributos proeminentes de um sistema QoS são granularidade e a escala temporal. O primeiro se refere às unidades de serviço a ser fornecido por tal sistema (ex: fluxos individuais ou fluxos agregados), e o segundo se refere às durações típicas envolvidas para as respostas a serem fornecidas pelo sistema (sgundos, minutos, horas, ...).

Além desses atributos, entende-se que um sistema de QoS é composto por uma arquitetura e uma estratégia. A arquitetura define a parte técnica do sistema, contendo os mecanismos e propriedades relacionados aos serviços oferecidos. A estratégia define como o operador do sistema explora os aspectos técnicos contidos na arquitetura. Por fim, a arquitetura é concebida com base em um modelo de QoS, que especifica tanto como tráfego é representado, como onde ou controle, ou inteligência, do sistema é localizado (se na rede ou nos sistema finais).

Um diagrama entidade-relacionamento para um modelo de sistema para QoS em redes (obtido do livro "Heterogeneous Network Quality of Service Systems", de Jens B. Schmitt)

QoS e a camada de rede

A camada de rede no modelo TCP/IP oferece um serviço de entrega com melhor-esforço. Nenhuma garantia existe de que datagramas serão entregues no destino, muito menos que requisitos de qualidade de serviços serão respeitados. Na RFC 791 explicitamente se define que "There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols". Essa definição vale tanto para IPv4 quanto IPv6. No entanto, algumas predefinições ou extensões relacionadas a QoS existem para esses protocolos.

IPv4

No protocolo IP original, conhecido como IPv4 (curiosamente, essa denominação se tornou popular somente após ser proposta a nova versão IPv6), incluiu-se na definição do serviço a possibilidade de priorizar datagramas. Isso foi especificado por meio de informações contidas no cabeçalho IPv4, e por um comportamento sugerido em roteadores.

Tipo de Serviço (ToS)

No cabeçalho de datagrama IPv4 existe um campo denominado Tipo de Serviço (ToS), cujo valor descreve parâmetros abstratos para a qualidade de serviço desejada (ver seção 3.1 na RFC 791). Esse campo de 8 bits tem o seguinte formato:

.
         0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      |                 |     |     |     |     |     |
      |   PRECEDENCE    |  D  |  T  |  R  |  0  |  0  |
      |                 |     |     |     |     |     |
      +-----+-----+-----+-----+-----+-----+-----+-----+

... sendo que os bits Precedência indicam a classe do datagrama e os bits D, T e R têm estas interpretações:

Bit	Valor 0	Valor 1
D	atraso normal de entrega	baixa atraso de entrega
T	vazão normal	alta vazão
R	confiabilidade normal	alta confiabilidade

Esse campo ToS não impõe nem garante nenhum nível de serviço de encaminhamento ou entrega na rede. Seu propósito é somente informar o núcleo da rede sobre as características de encaminhamento e entrega desejadas, as quais podem ou não serem observadas por roteadores. Por exemplo, se o bit D for 1, os roteadores poderiam priorizar o encaminhamento dos respectivos datagramas, passando-os para a frente da fila de transmissão. Outra possibilidade seria os roteadores descartarem primeiro os datagramas com bit R com valor 0, em caso de congestionamento. De qualquer forma, o campo ToS não impõe qualquer comportamento nos roteadores, e de fato tiveram pouco uso (se tiveram !). A própria RFC 791 é vaga sobre como esse campo poderia efetivamente ser usado e interpretado no âmbito do núcleo da rede. Uma melhor definição sobre esse campo somente foi proposta pela RFC 1349.

A RFC 1349 define claramente que o campo ToS deveria ser usado por hosts para indicarem o nível de serviço desejado para os datagramas enviados. Em paralelo, alguns protocolos de roteamento (ex: OSPF, IS-IS) que surgiram eram capazes de descobrirem rotas com diferentes níveis de qualidade de serviço, e exploravam o campo ToS para escolher que rota cada datagrama deveria usar. Essa RFC também simplificou a interpretação do campo ToS, que ficou assim definido:

.
                0     1     2     3     4     5     6     7
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                 |                       |     |
             |   PRECEDENCE    |          TOS          | MBZ |
             |                 |                       |     |
             +-----+-----+-----+-----+-----+-----+-----+-----+

... sendo que os bits ToS devem ser interpretados desta forma:

Valor	Significado
1000	minimizar atraso
0100	maximizar vazão
0010	maximizar confiabilidade
0001	minimizar custo momentário
0000	serviço normal

A seção 5 da RFC 1349 especifica o uso do campo ToS para alguns protocolos da Internet, tais como ICMP, protocolos de transporte e de aplicação em geral. De qualquer forma, o uso do campo ToS não se difundiu na época, sendo largamente ignorado.

Campo DS

O campo DS (Differentiated Service) foi definido na RFC 2474 em substituição ao campo ToS para datagramas IPv4 (e também IPv6). O valor desse campo, o qual se denominou DSCP (Differentiated Service Code Point) tem uma interpretação mais estrita e alinhada com um modelo para qualidade de serviço denominado serviços diferenciados.

.

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |         DSCP          |  CU   |
      +---+---+---+---+---+---+---+---+

Os valores para o campo DS especificam claramente um comportamento para encaminhamento em roteadores que façam parte de um determinado domínio. Maiores detalhes sobre os valores DSCP no contexto de serviços diferenciados serão vistos a seguir.

IPv6

O protocolo IPv6 oferece um serviço de entrega similar ao IPv4, com características de melhor-esforço. No contexto de QoS, esse protocolo herda o campo DS definido no protocolo IPv4, assim como sua interpretação.

Serviços diferenciados (diffserv)

Diffserv é um modelo para provimento de QoS para Internet, em que fluxos são classificados e então tratados de forma diferenciada dentro da rede. A proposta, contida na RFC 2475, visa definir um modelo flexível e escalável para atendimento de requisitos de QoS.

Flexibilidade: o tratamento de cada classe de tráfego é uma decisão da gerência da rede, e assim não é especificada na proposta.
Escalabilidade: a priorização e condicionamento de tráfego a serem feitos nos roteadores se basearão nas classes de tráfego, e não nos fluxos individuais que passam pela rede (compare com IntServ). Isso proporciona a agregação dos fluxos, que são rotulados com as classes de serviço, facilitando a tarefa dos roteadores no núcleo da rede.

Obs: as figuras abaixo foram obtidas em um artigo da Cisco

Uma visão geral da arquitetura DiffServ pode ser vista na figura abaixo:

Arquitetura DiffServ

Diversos elementos compõem a arquitetura:

Domínios DiffServ: conjuntos de roteadores onde se aplicam uma determinada classificação e diferenciação de tráfego, definidas pela gerência da rede.
Roteadores de borda: roteadores que classificam fluxos que entram num domínio DiffServ. Essa tarefa de classificação e condicionamento de fluxos de entrada pode ser complexa. Por esses roteadores também passam fluxos que saem do domínio, para serem entregues a sistemas finais.
Roteadores de núcleo: roteadores internos de um domínio DiffServ, que encaminham fluxos já classificados. Esses roteadores verificam a conformidade desses fluxos às regras definidas pela gerência da rede para as classes de serviço. Assim, pacotes desses fluxos estão sujeitos a priorizações, enfileiramentos, e mesmo descartes, dependendo das restrições de QoS que foram definidas. Essas regras compõem o que se chama de Comportamento por Salto (PHB - Per-Hop Behaviour), representada no diagrama contido na figura abaixo.

PHB - Per-Hop Behaviour

A classificação feita nos roteadores de borda mapeia características dos fluxos para um número de 6 bits. Assim, podem haver até 64 classes de serviço em um domínio DiffServ. Esse número, chamado de DSCP - DiffServ Code Point, é inscrito no campo ToS dos datagramas IPv4 (ou no campo Traffic Class de datagramas IPv6), como mostrado abaixo:

Os comportamentos por salto podem ser:

Default PHB: pacotes com DSCP de valor 000000 (zero) são tratados com melhor esforço. Isso também deve ser aplicado para pacotes cujos DSCP tenham valores não reconhecidos pelo roteador. Ver maiores detalhes na RFC 2474.
Class-selector PHB: pacotes com DSCP xxx000 são tratados de acordo com uma política tradicional de precedência IP (i.e. classes de tráfego descritas no campo ToS). Também descrito na RFC 2474
Expedited Forwarding PHB (EF): semelhante ao serviço garantido do IntServ. Desenhado para prover um serviço com baixas taxas de perda, baixa latência e jitter, e uma largura de banda garantida. Deve ser usado somente por aplicações críticas. O valor do DSCP deve ser 101110 (ver RFC 2598)
Assured Forwarding PHB (AF): semelhante ao serviço de carga controlada do IntServ. Define quatro classes de serviço, sendo que cada uma tem três níveis de precedência de descarte.

Classes de serviço e precedências de descarte em AF PHB

Uma interpretação sobre Diffserv

Um domínio DiffServ é composto por roteadores com comportamentos predefinidos (PHB - Per Host Behavior), e que policiam e condicionam fluxos de acordo com as classes de tráfego existentes. Dentre os quatro grupos de classes, vale destacar estes dois:

Encaminhamento Acelerado (Expedited Forwarding - EF): proporciona baixo atraso, baixo jitter, baixa perda de pacotes. Uma boa discussão sobre esse PHB pode ser encontrada aqui.

Principal característica: definir um limite superior para atraso de encaminhamento em um nodo, assumindo que a fila de saída esteja usualmente vazia ou seja curta.

Finalidade: atender fluxos que necessitam de atrasos e jitter estritos.
De acordo com a RFC 3246:

Intuitively, the definition of EF is simple: the rate at which EF
traffic is served at a given output interface should be at least the
configured rate R, over a suitably defined interval, independent of
the offered load of non-EF traffic to that interface.

... e complementado pela RFC 3248:

For a traffic stream not exceeding a configured rate the goal of the
DB PHB is a strict bound on the delay variation of packets through a
hop.

Traffic MUST be policed and/or shaped at the source edge (for
example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in
order to get such a bound.  However, specific policing and/or shaping
rules are outside the scope of the DB PHB definition.  Such rules
MUST be defined in any per-domain behaviors (PDBs) composed from the
DB PHB.

Encaminhamento Assegurado (Assured Forwarding - AF): oferece diferentes probabilidades de que pacotes sejam encaminhados.
- Principal característica: a probabilidade de que pacotes sejam encaminhados depende dos recursos alocados (buffer e largura de banda) para cada classe AF e respectivas precedências de descartes em caso de congestionamento.
- Finalidade: limitar a vazão de fluxos, respeitando rajadas em certa medida.
  De acordo com a RFC 2597:
```
In a DS node, the level of forwarding assurance of an IP packet thus
depends on (1) how much forwarding resources has been allocated to
the AF class that the packet belongs to, (2) what is the current load
of the AF class, and, in case of congestion within the class, (3)
what is the drop precedence of the packet.
```

As outras classes são Default PHB, que corresponde a um serviço melhor esforço, e Class Selector PHB, que se baseia na interpretação convencional do campo ToS do cabeçalho IP.

Atividade

Um pequeno provedor possui uma rede como mostrado abaixo. Essa rede é usada para interligar seus clientes, no caso as empresas Ajax e Tabajara.

Para implantar a estrutura DiffServ, deve-se começar com o seguinte:

i) Os roteadores de borda (B1 e B2) devem ser capazes de marcar, policiar e condicionar os datagramas dos clientes. A marcação deve ser feita de acordo com as classes de serviço escolhidas em cada caso.

ii) O roteador de núcleo (N1) deve ter um PHB capaz de atender tanto classes do tipo Encaminhamento Assegurado (AF) quanto Encaminhamento Acelerado (EF). A diferenciação nesse roteador deve ser feita de acordo com a marcação contida nos datagramas - e que foi realizada nos roteadores de borda.

OBS: os links dentro da rede do provedor estão superdimensionados, portanto não apresentam gargalos.

Tendo a estrutura inicial preparada, resolva os seguintes problemas:

O cliente Ajax contratou um link de 1256 kbps, e Tabajara contratou um link de 512 kbps. Em ambos os casos, os links são simétricos. Especifique uma estrutura DiffServ nesse provedor, assumindo que ambos clientes usem classes do tipo Encaminhamento Assegurado (AF).
O cliente Ajax precisa usar parte da capacidade contratada para transmitir streams de audio (voz). Assumindo que as streams estarão codificadas com codec PCMU (aprox. 80 kbps/stream), e que pode haver até 5 streams simultâneas, use a sua estrutura DiffServ para atender essa necessidade.
O cliente Tabajara precisa transmitir streams de audio e videoconferência. Assumindo que possam haver até 4 streams de audio simultâneas, codificadas com GSM (aprox. 13kbps/stream), e a stream de video use 256 kbps, use a estrutura DiffServ para atender essa demanda.
DESAFIO: e se for necessário implementar precedências de descarte para as classes AF ? Por exemplo, dentro da classe AF1 podem existir três precedências de descarte: AF11, AF12 e AF13. A ideia é que, em caso de congestionamento, pacotes marcados com AF13 sejam descartados antes de AF12, e estes sejam descartados antes de AF11. Investigue e especifique como isso poderia ser feito. Sugestão: este artigo seminal sobre controle de congestionamento em redes apresenta um mecanismo largamente disponível atualmente.
Curiosidade: escolha algum grande fabricante de equipamentos de redes (ex: Huawei, Cisco, Juniper ... ou mesmo Mikrotik !), e descreva como esse domínio Diffserv seria implantado. Para o fabricante escolhido, informe que mecanismos seriam utilizados e como poderiam ser parametrizados. Se conseguir gerar exemplos, melhor !

Uma solução aproximada

Configuração para o Netkit: importe-a com File->Import

O primeiro experimento envolve medir a vazão na rede antes de definir qualquer tipo de enfileiramento:
1. EmAjax2 e Tabajara2 execute o comando netserver
2. Em Ajax1 digite este comando (mas não o execute ainda):
```
netperf -f k -H 192.168.1.1
```
  ... e em Tabajara1 digite:
```
netperf -f k -H 192.168.11.1
```
  Em seguida, execute ambos comandos simultaneamente
3. Observe as taxas de bit informadas pelo netperf (coluna da direita)
Agora deve-se repetir a medição, porém implantando o domínio Diffserv no núcleo da rede.
1. Em B1, B2 e N1 execute o script diffserv.sh.
2. Repita os passos 1.2 e 1.3
3. Após verificar a vazão, deve-se testar o atraso fim-a-fim e jitter
4. Em Ajax1 e Ajax2 execute este comando:
```
pjsua --config-file pjsua.cfg
```
5. Em Tabajara1 execute a medição de vazão:
```
netperf -f k -H 192.168.11.1
```
  ... e, simultaneamente, em Ajax1 faça uma chamada para o contato 1 (digite m, seguido de 1 e então ENTER)
6. Em Ajax1 digite dq seguido de ENTER para observar as estatísticas de atraso e jitter da chamada.
7. Como se comportam os atrasos da chamada ?
8. Agora execute o netperf em Ajax e faça a medição de atrasos e jitter entre os hosts de Tabajara. Há alguma diferença ?
Como você poderia testar se Ajax e Tabajara estão recebendo o nível de servuço contratado ? Se Ajax gerar fluxos tanto de dados quanto de áudio, o nível de serviço será aquele esperado ? Crie um experimento para aferir isso !

Serviços Integrados (IntServ)

IntServ: serviços integrados para provimento de QoS fim-a-fim. Nesse modelo, fluxos de pacotes entre um transmissor e um receptor têm seus requisitos de QoS atendidos pela infraestrutura de rede. Para isso, são efetuadas reservas de recursos (largura de banda, priorização) em todos os roteadores ao longo do caminho entre transmissor e um receptor.

IntServ é introduzido pela RFC 1633.

Elementos da arquitetura IntServ:

Especificação de fluxo: define as características de um fluxo e os recursos que ele precisa da rede:
- TSpec (Traffic Specification): especificação de características de um fluxo (gerada pelo transmissor): TokenBucketRate, TokeBucketSize, PeakRate, MinimumPolicedUnit, MaximumPacketSize
- RSpec (Reservation Specification): especificação de características de uma reserva de recursos (gerada pelo receptor). Contém os mesmos parâmetros que TSpec, além de uma classe de serviço (garantida, carga controlada ou melhor-esforço) e um filtro que descreve o fluxo (endereços IP dos pares, ports TCP ou UDP).
RSVP (Resource Reservation Protocol): protocolo de sinalização para negociar reservas de recursos ao longo do caminho a ser usado pelo fluxo.

A sinalização RSVP ocorre em duas etapas:

O transmissor do fluxo envia mensagens PATH para o receptor. Essas mensagens contém a descrição do fluxo (TSpec).
Se aceitar a especificação de fluxo contida na mensagem PATH, o receptor responde com uma mensagem RESV. Essa mensagem especifica a reserva a ser feita ao longo do caminho entre transmissor e receptor (i.e. contém um RSpec) . Cada roteador ao longo do caminho testa se a reserva pode ser satisfeita, e em caso afirmativo propaga a mensagem RESV ao próximo roteador.

Obs: o pedido de reserva feito pelo transmissor (mensagens PATH) deve ocorrer periodicamente. Caso os roteadores ou o receptor fiquem um certo tempo sem receber uma mensagem PATH, as reservas correspondentes são canceladas.
Obs 2: fluxos são unidirecionais, portanto as reservas são feitas também de forma unidirecional.

Segundo um artigo da Cisco, IntServ possui como pontos fortes:

Um tipo de serviço garantido que limita o atraso fim-a-fim e proporciona uma largura de banda para o tráfego que se adequade às especificações da reserva de recursos.
Um tipo de serviço de carga controlada, o qual provê um desempenho superior a melhor esforço, além de um atraso fim-a-fim baixo sob cargas leves ou moderadas na rede.
Possibilidade de proporcionar a qualidade de serviço pedida para cada fluxo na rede, contanto que tenha sido sinalizado usando RSVP e existam recursos disponíveis.

... mas tem também pontos fracos:

Cada equipamento ao longo do caminho de um pacote, incluindo os sistemas finais (ex: PCs e servidores), precisam entender e usar RSVP e serem capazes de sinalizar a QoS pedida.
Reservas de recursos em cada equipamento ao longo do caminho são "brandas", o que significa que precisam ser renovadas periodicamente. Com isso, há um tráfego de sinalização adicional que contribui para o aumento da carga na rede, o qual aumenta a chance de que a reserva expire se os pacotes de renovação forem perdidos.
A manutenção de estados sobre as reservas de recursos em cada roteador, combinada com controle de admissão e uma maior quantidade de memória necessária para suportar um grande número de reservas, aumenta a complexidade de cada nó da rede ao longo do caminho.
Como informação sobre estados para cada reserva precisa ser mantida em todos os roteadores ao longo do caminho, torna-se um desafio manter centenas de milhares de fluxos que passem pelo núcleo da rede.

A seguinte explicação (obtida aqui) aponta outras limitações do Intserv, e comenta sobre sua adoção em redes corporativas e de provedores:

Although IntServ is a straightforward QoS model, end-to-end service guarantees cannot be supported unless all 
nodes along the route support IntServ. This is obviously so because any best-effort node along any route can 
treat packets in such a way that the end-to-end service agreements are violated. In the case of end-end 
implementation of IntServ QoS model, it is recognized by the industry that the support of per-flow guarantees 
in the core of the Internet will pose severe scalability problems. Therefore, scalability is a key 
architectural concern for IntServ, since it requires end-to-end signaling and must maintain a per-flow 
soft state at every router along the path. Other concerns are, how to authorize and prioritize 
reservation requests, and what happens when signaling is not deployed end-to-end. Because of 
these issues, it is generally accepted that IntServ is a better candidate for enterprise 
networks (i.e., for access networks), where user flows can be managed at the desktop user level, 
than for large service provider backbones. A hybrid model (RSVP-DS) that uses RSVP at the edges 
and DiffServ in the backbone has been proposed and seems to be winning consensus as a backbone 
service architecture concept.

Atividade

Leia neste TCC um exemplo de aplicação de alguns elementos do IntServ.
Escolha algum grande fabricante de equipamentos de redes (ex: Huawei, Cisco, Juniper ... ou mesmo Mikrotik !), e descreva como esse domínio Intserv seria implantado. Para o fabricante escolhido, informe que mecanismos seriam utilizados e como poderiam ser parametrizados. Se conseguir gerar exemplos, melhor !

SMU29009: Modelos de QoS

Índice

Blocos de um sistema multimidia

QoS e a camada de rede

IPv4

Tipo de Serviço (ToS)

Campo DS

IPv6

Serviços diferenciados (diffserv)

Uma interpretação sobre Diffserv

Atividade

Uma solução aproximada

Serviços Integrados (IntServ)

Atividade

Menu de navegação

Pesquisa