O documento discute a necessidade de mecanismos de Qualidade de Serviço (QoS) em redes devido ao aumento de aplicações sensíveis a atrasos. Apresenta as arquiteturas Intserv e Diffserv para implementar QoS em redes IP, permitindo que aplicações especifiquem seus requisitos de QoS e recebam tratamento preferencial. Também descreve protocolos como RSVP para reserva de recursos e conceitos como domínios Diffserv e Acordos de Nível de Serviço.

1. Qualidade do Serviço em Redes Prof. Mauro Tapajós

3. Para uma série de novas aplicações, são necessários mecanismos que garantam o tráfego contínuo de pacotes sem alteração

4. Apesar de IPv4 prever campos para indicação de níveis de QoS, as implementações nos roteadores normalmente ignoram esta facilidade

6. Grupos de trabalho demonstraram que é possível se oferecer este tipo de suporte sobre uma rede assíncrona de datagramas

8. Dificuldade em prover este tipo de serviço sobre redes de pacotes

9. Alternativa escolhida foi redes comutadas por circuito

10. Muitas corporações utilizam rede telefônicas mas poucas implementam suas redes privadas de telefonia (custo!) Exemplo – Redes de Voz (telefônicas)

12. ATM – pronta para QoS

13. Redes determinísticas: Token Ring, FDDI, TDM

14. Outras tecnologias sobre Fibra Ótica – velocidade bastante para garantir demandas

16. Redes privadas

17. Linhas dedicadas entre sites

18. Redes comutadas por circuitos públicas e privadas (interconexão de PABX digitais)

19. ISDN (integração dados e comutação por circuito tradicional) Redes de Dados - Modalidades

21. Normalmente roda sobre UDP e TCP (aplicações básicas da Internet)

23. Melhor exemplo: Tráfego real-time

24. Em caso de congestionamento, continua a enviar a mesma carga na rede (não recua)

25. Requisitos (throughput, atraso, jitter , perda de pacotes)

27. Existe, assim, a exigência então de tratamento preferencial

28. Aplicações que geram este tipo de tráfego devem sinalizar requisitos

29. A rede deve ainda suportar tráfego elástico podendo priorizar recursos para atendimento de tráfego preferencial

32. Indicação do QoS desejado no cabeçalho IP

33. Requisitos de Aplicação - Exemplos

35. Bufferização ( jitter )

36. Enfileiramento diferenciado

37. Traffic Shaping (SLA)

38. Algoritmo de Leaky Bucket (balde vazante)

39. Algoritmo de Token Bucket (balde de fichas)

40. Reserva de recursos

41. Controle de admissão

42. Agendamento de pacotes ( packet scheduli ng )

44. Muitos dos protocolos de camada dois originalmente usados com IP foram desenvolvidos apenas para o escopo das redes de dados antigas: envio de mails e arquivos

45. Estes protocolos não implementavam mecanismos para lidarem com tráfego real-time sensível à atrasos na rede

46. Transmitem os dados em quadros de tamanho variável e mecanismos de controle de erros geram retransmissões de um número incerto de quadros, não há garantia de tempo de entrega de um quadro (redes estatísticas)

51. Uso cada vez maior de multimídia no conteúdo WEB

53. Differentiated services - Diffserv

55. Conceito de Fluxo : sequência distinta de pacotes resultantes da mesma atividade e sujeitos aos mesmos parâmetros de QoS (se difere de uma conexão TCP por ser unidirecional e poder ter mais de um destino – caso multicast)

56. Desta forma, cada pacote pode então ser associado a um fluxo

57. Limitado às redes que suportam a arquitetura (como uma Intranet)

58. Fluxos

61. Controle de admissão

62. Agente de gerenciamento

63. Protocolos de roteamento

65. Selecionador de rota : define o próximo destino do pacote

66. Agendador de pacotes : define e gerencia as várias filas de pacotes baseado nas características de cada fluxo, na situação da interface de saída e das informações de tráfego

68. Algoritmo de roteamento – gera várias rotas podendo oferecer melhores caminhos baseados em várias métricas

69. Algoritmo de enfileiramento – define regras para tratar os pacotes que chegam nas filas dos roteadores

70. Política de descarte – em situação de congestionamento, decidirá quais pacotes tem prioridade e quais são escolhidos primeiro para o descarte

71. Arquitetura ISA - Intserv

73. Carga Controlada

76. Prevê um nível de recursos ou taxa de dados garantida

77. Define um limite superior para o atr a so através do percurso do pacote

78. Não tolera perdas de pacotes por buffer overflow

80. Não define um limite superior para o atraso, mas impede que um porcentagem razoável do tráfego não experimente atrasos muito maiores que o normal

81. Poucas perdas de pacotes

82. Adequado às chamadas a plicações de tempo real adaptativas (vídeo pode experimentar atraso ou perder um frame, voz pode ajustar períodos de silêncio)

84. É a escolha atual para a função de protocolo de reserva de recursos prevista em IntServ

85. Pretende ser adotado de maneira gradual

86. Descrito na RFC 2205

87. Baseado em fluxos ( streams ) ao invés de pacotes individuais

88. É um protocolo simplex que trabalha antes de qualquer informação ser enviada

89. Suporta IPv4 (ToS) e IPv6 (campo flow label )

91. Pode trabalhar com as mudanças nos grupos multicast

92. Receptores podem escolher dentre várias fontes de informação

93. Comunicação Unicast – pode usar reserva de recursos como alterativa para evitar ou sanar congestionamentos

94. Comunicação Multicast – redução de carga é possível quando determinados membros do grupo não querem a transmissão ou não suportam determinado nível de detalhes (exemplo: canais de vídeo de melhor ou pior resolução)

96. O receptor da transmissão inicia a reserva e a mantém

98. Identificador de protocolo (campo protocol )

99. Porta de destino

101. Opera independentemente do protocolo de roteamento utilizado mas deve interagir com o mesmo

102. O host previamente se inclui no grupo multicast relacionado através de IGMP (se unicast o roteamento é automático) e depois emite seu pedido de reserva

103. Acompanha as mudanças nas rotas usadas de forma transparente para a transmissão

104. Soft state – um conjunto de informações de estado num roteador que pode expirar se não for atualizada constantemente pelos usuários através de mensagens

106. Mensagens de caminho ( PATH) : enviada pelo originador da transmissão para divulgar e manter as rotas possíveis num determinado fluxo para os destinos multicast

107. Mensagens de erro e confirmação: sinalizam erro e confirmam reservas ( path-error, reservation-request-error e reservation-request-acknoledgement )

109. Operação RSVP

111. Pode operar de forma transparente através de nós não-RSVP através de tunelamento

112. Cada receptor enviar á uma mensagem RESV reservando recursos para determinada origem dentro de uma sessão

113. Uma sessão é identificada pelo endereço de destino e um identificador de reserva (32 bits)

114. No caminho, os roteadores irão reservando os recursos necessários

115. Caso seja impossível em algum deles, será enviada uma mensagem de erro

116. RSVP

118. Um pedido de reserva (chamado flowdescriptor ) é feito pela destino

119. Um flowdescriptor é composto por um flowspec (define parâmetros no agendador de pacotes – Rspec e Tspec) e um filterspec (define os pacotes a aplicar a reserva)

122. wild card Tipos de Reservas de Recursos

124. Se prevê comunicação de roteadores que suportam RSVP através de tunelamento para criar a malha de roteadores RSVP

125. As nuvens não-RSVP devem ter capacidade em excesso para garantirem o serviço Reservas

127. Para grandes quantidades de tráfego a sinalização prevista pode ser onerosa

128. A informação de estados nos roteadores pode tomar grandes proporções em redes maiores

129. Esta arquitetura é descrito na RFC 2475

130. Prevê uma forma de oferecer serviços QoS simples, fácil e com pouca geração de overhead

131. Não exige que as aplicações suportem a arquitetura – o provedor do serviço irá definir os níveis contratados

133. Pode agregar vários pacotes pertencentes à vários fluxos diferentes - mesmos campos DS são tratados da mesma maneira facilitando a escalabilidade no caso de grandes redes

134. DS prevê implementação nos roteadores encaminhando e enfileirando os pacotes se baseando unicamente no campo ToS

135. Não exige que se armazene nos roteadores informação de estado dos fluxos existentes

137. TOS – a seleção do próximo salto

139. Categorias possíveis (2^6 = 64 classes):

140. Xxxxx0 – usado correntemente para definir classes previstas no padrões em uso (000000 significa serviço comum – melhor esforço)

141. Xxxx11 – reservado para testes e uso local

142. Xxxx01 – reservado para testes e uso local e futuros padrões

144. Se um pacote é endereçado para dentro do domínio, o provedor deve garantir o serviço tal qual foi acertado no SLA – serviço uniforme e consistente

145. Se o pacote é endereçado para fora do domínio, o provedor o encaminha por outros domínios requerendo o serviço que mais se assemelha ao pedido no campo DS

147. O SLA é um contrato firmado entre um provedor de serviço e um cliente (usuário) detalhando os parâmetros de performance da rede em operação

149. Restrições nos pontos de entrada e saída da rede do provedor, definindo o escopo do serviço

150. Perfis de tráfego consistentes com o serviço que será oferecido (ex. Parâmetros token bucket )

151. A resposta da rede ao tráfego em excesso do cliente

152. Operação DiffServ

156. Condicionamento de tráfego para o serviço desejado

157. Maior complexidade nos roteadores

159. SLA - Service Level Agreements Host Egress Router PHB Conditioning and PHB Conditioningand PHB Host Egress Router PHB Conditioning and PHB Conditioningand PHB Host DS Unaware Router Arquitetura DiffServ

161. Medidor ( meter ) – medidor de tráfego para verificar concordância com o perfil definido para o mesmo

162. Marcador ( marker ) – remarca codepoints se necessário de acordo com a política em vigor

163. Delineador ( shaper ) – formata o fluxo de pacotes para o perfil

164. Descartador ( dropper ) Função de Condicionamento de Tráfego Diffserv

166. Pode ter vários propósitos: garantir certo nível de performance, rotear adequadamente em situações de congestionamento ou criar túneis VPN

167. Suporta IP, IPX, Apletalk, ATM e FR e pode trabalhar com protocolos como RSVP e OSPF

168. Define a necessidade de um protocolo para distribuição de labels: por exemplo: Label Distribution Protocol (LDP) entre LSR´s

170. Classe de serviço

172. MPLS

174. Cada fluxo (FEC – Forward Equivalence Class ) tem um caminho específico através de LSR’s definido com base nos seus requisitos de QoS

175. O encaminhamento é feito somente com base no label (o cabeçalho IP não é analisado) identificado em cada pacote e que pode ainda ser substituído

176. O protocolo de roteamento determina a topologia e as condições das rotas para que um caminho seja definido para a FEC

177. Os demais LSR’s são avisados de um novo caminho criado para uma FEC

178. Base de dados de encaminhamento ( Forwarding Information Base – FIB) : possui as entradas de cada label conhecido e seu encaminhamento

180. Cria uma estrutura de suporte QoS semelhante à usada em ATM (mais rápida que o encaminhamento IP)

181. Suporte QoS multiprotocolo orientado à conexão (mesmo sobre redes IP)

182. Cria uma camada de controle e provisionamento de rede independente dos nós da rede (NE – Networks Elements ) e do encaminhamento (roteamento IP)

183. Engenharia de tráfego – permite a definição de rotas dinamicamente, alocação de recursos baseados em demandas conhecidas, balanceamento de tráfego dinâmico e otimização da utilização de rede

184. Suporte a VPN – garantias de performance e segurança

185. Provê níveis SLA específicos e garantidos, diferenciando clientes

186. MPLS - Arquitetura LER de entrada LER de saída LSR

188. Um LSP ( Label Switched Path ) é definido através de um protocolo de distribuição de labels com LDP, RSVP-TE ou CR-LDP

189. MPLS permite roteamento explícito

192. MPLS

194. Exp - Informações DS ou PHB ( Class-of-Service - CoS)

195. S – bit stack

196. TTL

197. Cabeçalhos MPLS em Várias Tecnologias de Redes

199. Exige um protocolo de troca de informações de rotas

200. Protocolos de roteamento com extensões apropriadas para divulgação de rotas e recursos disponíveis na rede

201. Constraint-based routing - CBR - capacidade de encontrar caminhos com base em mecanismos de otimização e critérios de restrição

202. Suporta critérios relacionados com recursos disponíveis (por exemplo: banda disponível) e também relacionados com aspectos administrativos (por exemplo: clientes VIP)

203. Suporte a rotas hot stand-by

204. RSVP pode estabelecer caminhos sobre uma rede MPLS com base em critérios CBR

205. Pode-se ainda estabelecer rotas manualmente

206. Redes Multiserviços Data-Optimized Optical Advanced Services QoS Engine Packet Multiplexing to the Transport Layer