Qualidade do Serviço em Redes Prof. Mauro Tapajós
Necessidade de QoS <ul><li>A Internet é uma rede baseada no melhor esforço  ( best effort ): trata todos os pacotes do mes...
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
Apesar de IPv4 prever campos para indicação de níveis de QoS, as implementações nos roteadores normalmente ignoram esta fa...
Qualidade do Serviço  - QoS <ul><li>Um mecanismo QoS traduz um pedido de serviço num conjunto de características de tráfeg...
Grupos de trabalho demonstraram que é possível se oferecer este tipo de suporte sobre uma rede assíncrona de datagramas </...
<ul><li>Requer pequenos atrasos com pouca variação nos mesmos
Dificuldade em prover este tipo de serviço sobre redes de pacotes
Alternativa escolhida foi redes comutadas por circuito
Muitas corporações utilizam rede telefônicas mas poucas implementam suas redes privadas de telefonia (custo!) </li></ul>Ex...
Alternativas QoS em Camada 2 <ul><li>802.1p – mecanismos de priorização de quadros em MAN’s
ATM – pronta para QoS
Redes determinísticas: Token Ring, FDDI, TDM
Outras tecnologias sobre Fibra Ótica – velocidade bastante para garantir demandas </li></ul>
<ul><li>Redes públicas (como X.25)
Redes privadas
Linhas dedicadas entre sites
Redes comutadas por circuitos públicas e privadas (interconexão de PABX digitais)
ISDN (integração dados e comutação por circuito tradicional) </li></ul>Redes de Dados - Modalidades
Tipos de Tráfego <ul><li>Elástico </li><ul><li>Se ajusta bem dentro de determinada faixa de variação de atraso e banda
Normalmente roda sobre UDP e TCP (aplicações básicas da Internet)
Ex: FTP (sensível a throughput), SMTP (não é tão afetado por atrasos), TELNET e HTTP (razoavelmente sensível a atraso), to...
Melhor exemplo: Tráfego real-time
Em caso de congestionamento, continua a enviar a mesma carga na rede (não recua)
Requisitos (throughput, atraso,  jitter , perda de pacotes) </li></ul></ul>
Tráfego Inelástico <ul><li>Uma rede terá dificuldade em atender este tipo de tráfego com atrasos variáveis e ocorrência de...
Existe, assim, a exigência então de  tratamento preferencial
Aplicações que geram este tipo de tráfego devem sinalizar requisitos
A rede deve ainda suportar tráfego elástico podendo priorizar recursos para atendimento de tráfego preferencial </li></ul>
Requisitos de Aplicação <ul><li>Existe a necessidade de se permitir que as aplicações apresentem seus requisitos de QoS
Duas maneiras de se fazer isto: </li><ul><li>Criação de um mecanismo para requerimento de QoS (melhor em caso de congetion...
Indicação do QoS desejado no cabeçalho IP </li></ul></ul>
Requisitos de Aplicação - Exemplos
Algumas Técnicas para se  Implementar QoS em Redes <ul><li>Superprovisionamento
Bufferização ( jitter )
Enfileiramento diferenciado
Traffic Shaping  (SLA)
Algoritmo de Leaky Bucket (balde vazante)
Algoritmo de Token Bucket (balde de fichas)
Reserva de recursos
Controle de admissão
Agendamento de pacotes ( packet scheduli ng ) </li></ul>
QoS sobre IP - Aspectos <ul><li>IP, na verdade, é um conjunto de protocolos que viabilizam o serviço IP tornando uma rede ...
Muitos dos protocolos de camada dois originalmente usados com IP foram desenvolvidos apenas para o escopo das redes de dad...
Estes protocolos não implementavam mecanismos para lidarem com tráfego real-time sensível à atrasos na rede
Transmitem os dados em quadros de tamanho variável e mecanismos de controle de erros geram retransmissões de um número inc...
QoS sobre IP <ul><li>Como compartilhar recursos em situação de escassez dos mesmos?
Mecanismos existentes disponíveis: </li></ul><ul><ul><li>Descarte de Pacotes - opção não pode ser levada em conta para se ...
Algoritmo de Roteamento - podem  adapta r  suas rotas às linhas menos congestionadas, mas reagem lentamente demais às muda...
QoS sobre IP <ul><li>Novas características do tráfego Internet: </li><ul><li>Alto volume de aplicações cliente-servidor
Uso cada vez maior de multimídia no conteúdo WEB
Tráfego de tempo-real (por exemplo: transmissões de eventos em tempo real) </li></ul><li>Padrões propostos para QoS pelo I...
Differentiated services  - Diffserv </li></ul></ul>
ISA –  Integrated Services <ul><li>Descrito na RFC 1633
Conceito de  Fluxo : sequência distinta de pacotes resultantes da mesma atividade e sujeitos aos mesmos parâmetros de QoS ...
Upcoming SlideShare
Loading in...5
×

Redes Avançadas - 6.QoS

2,604

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,604
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
201
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Redes Avançadas - 6.QoS

  1. 1. Qualidade do Serviço em Redes Prof. Mauro Tapajós
  2. 2. Necessidade de QoS <ul><li>A Internet é uma rede baseada no melhor esforço ( best effort ): trata todos os pacotes do mesmo modo
  3. 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. 4. Apesar de IPv4 prever campos para indicação de níveis de QoS, as implementações nos roteadores normalmente ignoram esta facilidade </li></ul>
  5. 5. Qualidade do Serviço - QoS <ul><li>Um mecanismo QoS traduz um pedido de serviço num conjunto de características de tráfego para aquele serviço (enfileiramento adequado, roteamento, disponibilização de recursos – capacidade, buffers, etc)
  6. 6. Grupos de trabalho demonstraram que é possível se oferecer este tipo de suporte sobre uma rede assíncrona de datagramas </li></ul>
  7. 7. <ul><li>Requer pequenos atrasos com pouca variação nos mesmos
  8. 8. Dificuldade em prover este tipo de serviço sobre redes de pacotes
  9. 9. Alternativa escolhida foi redes comutadas por circuito
  10. 10. Muitas corporações utilizam rede telefônicas mas poucas implementam suas redes privadas de telefonia (custo!) </li></ul>Exemplo – Redes de Voz (telefônicas)
  11. 11. Alternativas QoS em Camada 2 <ul><li>802.1p – mecanismos de priorização de quadros em MAN’s
  12. 12. ATM – pronta para QoS
  13. 13. Redes determinísticas: Token Ring, FDDI, TDM
  14. 14. Outras tecnologias sobre Fibra Ótica – velocidade bastante para garantir demandas </li></ul>
  15. 15. <ul><li>Redes públicas (como X.25)
  16. 16. Redes privadas
  17. 17. Linhas dedicadas entre sites
  18. 18. Redes comutadas por circuitos públicas e privadas (interconexão de PABX digitais)
  19. 19. ISDN (integração dados e comutação por circuito tradicional) </li></ul>Redes de Dados - Modalidades
  20. 20. Tipos de Tráfego <ul><li>Elástico </li><ul><li>Se ajusta bem dentro de determinada faixa de variação de atraso e banda
  21. 21. Normalmente roda sobre UDP e TCP (aplicações básicas da Internet)
  22. 22. Ex: FTP (sensível a throughput), SMTP (não é tão afetado por atrasos), TELNET e HTTP (razoavelmente sensível a atraso), todas com pequenas variações na exigência de QoS – necessidade modesta de suporte QoS </li></ul><li>Inelástico </li><ul><li>Não se adapta bem a mudanças da qualidade da rede
  23. 23. Melhor exemplo: Tráfego real-time
  24. 24. Em caso de congestionamento, continua a enviar a mesma carga na rede (não recua)
  25. 25. Requisitos (throughput, atraso, jitter , perda de pacotes) </li></ul></ul>
  26. 26. Tráfego Inelástico <ul><li>Uma rede terá dificuldade em atender este tipo de tráfego com atrasos variáveis e ocorrência de congestionamentos
  27. 27. Existe, assim, a exigência então de tratamento preferencial
  28. 28. Aplicações que geram este tipo de tráfego devem sinalizar requisitos
  29. 29. A rede deve ainda suportar tráfego elástico podendo priorizar recursos para atendimento de tráfego preferencial </li></ul>
  30. 30. Requisitos de Aplicação <ul><li>Existe a necessidade de se permitir que as aplicações apresentem seus requisitos de QoS
  31. 31. Duas maneiras de se fazer isto: </li><ul><li>Criação de um mecanismo para requerimento de QoS (melhor em caso de congetionamento da rede – caso a rede esteja congestionada, novos pedidos são negados)
  32. 32. Indicação do QoS desejado no cabeçalho IP </li></ul></ul>
  33. 33. Requisitos de Aplicação - Exemplos
  34. 34. Algumas Técnicas para se Implementar QoS em Redes <ul><li>Superprovisionamento
  35. 35. Bufferização ( jitter )
  36. 36. Enfileiramento diferenciado
  37. 37. Traffic Shaping (SLA)
  38. 38. Algoritmo de Leaky Bucket (balde vazante)
  39. 39. Algoritmo de Token Bucket (balde de fichas)
  40. 40. Reserva de recursos
  41. 41. Controle de admissão
  42. 42. Agendamento de pacotes ( packet scheduli ng ) </li></ul>
  43. 43. QoS sobre IP - Aspectos <ul><li>IP, na verdade, é um conjunto de protocolos que viabilizam o serviço IP tornando uma rede de várias tecnologias numa única rede para a aplicação
  44. 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. 45. Estes protocolos não implementavam mecanismos para lidarem com tráfego real-time sensível à atrasos na rede
  46. 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) </li></ul>
  47. 47. QoS sobre IP <ul><li>Como compartilhar recursos em situação de escassez dos mesmos?
  48. 48. Mecanismos existentes disponíveis: </li></ul><ul><ul><li>Descarte de Pacotes - opção não pode ser levada em conta para se garantir qualidade de serviço
  49. 49. Algoritmo de Roteamento - podem adapta r suas rotas às linhas menos congestionadas, mas reagem lentamente demais às mudanças nos perfis de tráfego </li></ul></ul><ul><li>Será necessária uma forma de se poder indicar os serviços de QoS para IP, isto significa adicionar funcionalidades nos roteadores IP </li></ul>
  50. 50. QoS sobre IP <ul><li>Novas características do tráfego Internet: </li><ul><li>Alto volume de aplicações cliente-servidor
  51. 51. Uso cada vez maior de multimídia no conteúdo WEB
  52. 52. Tráfego de tempo-real (por exemplo: transmissões de eventos em tempo real) </li></ul><li>Padrões propostos para QoS pelo IETF (podem ser complementares) </li><ul><li>Integrated services - Intserv
  53. 53. Differentiated services - Diffserv </li></ul></ul>
  54. 54. ISA – Integrated Services <ul><li>Descrito na RFC 1633
  55. 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. 56. Desta forma, cada pacote pode então ser associado a um fluxo
  57. 57. Limitado às redes que suportam a arquitetura (como uma Intranet) </li></ul>
  58. 58. Fluxos
  59. 59. Arquitetura ISA - Intserv <ul><li>A principal funcionalidade do roteador é encaminhar pacotes
  60. 60. Existem componentes na arquitetura ISA que auxilia m esta tarefa, implementando os mecanismos Intserv : </li><ul><li>Protocolos de reserva de recursos
  61. 61. Controle de admissão
  62. 62. Agente de gerenciamento
  63. 63. Protocolos de roteamento </li></ul></ul>
  64. 64. Intserv – Funções de Encaminhamento <ul><li>Dentro da arquitetura o encaminhamento de pacotes é baseado nos seguintes mecanismos : </li><ul><li>Classificador de pacotes : mapeia os pacotes entrantes em classes de serviço
  65. 65. Selecionador de rota : define o próximo destino do pacote
  66. 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 </li></ul></ul>
  67. 67. Funções ISA - Intserv <ul><li>Controle de admissão – para o estabelecimento de QoS para um fluxo deve-se alocar previamente os recursos da rede, caso algum dos roteadores no percurso não tenha recursos no momento, o pedido é negado
  68. 68. Algoritmo de roteamento – gera várias rotas podendo oferecer melhores caminhos baseados em várias métricas
  69. 69. Algoritmo de enfileiramento – define regras para tratar os pacotes que chegam nas filas dos roteadores
  70. 70. Política de descarte – em situação de congestionamento, decidirá quais pacotes tem prioridade e quais são escolhidos primeiro para o descarte </li></ul>
  71. 71. Arquitetura ISA - Intserv
  72. 72. Arquitetura ISA - Serviços <ul><li>Serviços ( t raffic specification - TSpec) são definidos por fluxo em dois níveis: </li></ul><ul><li>Categorias gerais de serviços </li></ul><ul><ul><li>Garantido
  73. 73. Carga Controlada
  74. 74. Melhor Esforço </li></ul></ul><ul><li>Parâmetros específicos para um determinado fluxo – parâmetros específicos do fluxo </li></ul>
  75. 75. Serviços ISA Serviço Garantido <ul><li>É a categoria de serviço mais exigente (aplicações real-time com rígidas premissas de entrega sem atraso ou perdas)
  76. 76. Prevê um nível de recursos ou taxa de dados garantida
  77. 77. Define um limite superior para o atr a so através do percurso do pacote
  78. 78. Não tolera perdas de pacotes por buffer overflow </li></ul>
  79. 79. Serviços ISA Carga Controlada <ul><li>Apresenta um serviço semelhante à melhor esforço sob condições sem congestionamento
  80. 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. 81. Poucas perdas de pacotes
  82. 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) </li></ul>
  83. 83. RSVP (Resource Re S er V ation Protocol) <ul><li>Protocolo desenvolvido para realizar a prévia reserva de recursos na rede para uma transmissão
  84. 84. É a escolha atual para a função de protocolo de reserva de recursos prevista em IntServ
  85. 85. Pretende ser adotado de maneira gradual
  86. 86. Descrito na RFC 2205
  87. 87. Baseado em fluxos ( streams ) ao invés de pacotes individuais
  88. 88. É um protocolo simplex que trabalha antes de qualquer informação ser enviada
  89. 89. Suporta IPv4 (ToS) e IPv6 (campo flow label ) </li></ul>
  90. 90. RSVP <ul><li>Suporta reservas multicast mas também reservas específicas individuais dentro de um mesmo grupo multicast, acompanhando as mudanças dos membros do grupo
  91. 91. Pode trabalhar com as mudanças nos grupos multicast
  92. 92. Receptores podem escolher dentre várias fontes de informação
  93. 93. Comunicação Unicast – pode usar reserva de recursos como alterativa para evitar ou sanar congestionamentos
  94. 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) </li></ul>
  95. 95. RSVP <ul><li>Prevê que reservas com mesmos requisitos mas feitas separadamente devem poder ser agregadas de forma a minimizar os recursos disponibilizados e otimizar tráfego em função de caminhos semelhantes
  96. 96. O receptor da transmissão inicia a reserva e a mantém
  97. 97. Uma reserva (sessão) é alocada num roteador para uma sessão definida por: </li><ul><li>Endereço IP de destino
  98. 98. Identificador de protocolo (campo protocol )
  99. 99. Porta de destino </li></ul></ul>
  100. 100. RSVP e Roteamento <ul><li>Baseado em roteamento multicast com “spanning trees”, mas o roteamento não é parte do protocolo – usa as rotas definidas pelo protocolo de roteamento existente
  101. 101. Opera independentemente do protocolo de roteamento utilizado mas deve interagir com o mesmo
  102. 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. 103. Acompanha as mudanças nas rotas usadas de forma transparente para a transmissão
  104. 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 </li></ul>
  105. 105. Mensagens RSVP <ul><li>O protocolo possui quatro mensagens básicas: </li></ul><ul><ul><li>Mensagens de reserva ( RESV) : enviadas pelos destinos (unicast ou multicast) em direção aos hosts originadores das transmissões ( upstream ) para criar as reservas
  106. 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. 107. Mensagens de erro e confirmação: sinalizam erro e confirmam reservas ( path-error, reservation-request-error e reservation-request-acknoledgement )
  108. 108. Mensagens de teardown : removem informação de caminho (path) e reservas. São enviadas por aplicações ou roteadores </li></ul></ul><ul><li>Várias mensagens RESV enviadas podem ser agregadas numa única e devem ser periodicamente reenviadas para manter os soft states </li></ul>
  109. 109. Operação RSVP
  110. 110. Operação RSVP <ul><li>Deve ser implementado em todos os roteadores que estejam no caminho das reservas feitas
  111. 111. Pode operar de forma transparente através de nós não-RSVP através de tunelamento
  112. 112. Cada receptor enviar á uma mensagem RESV reservando recursos para determinada origem dentro de uma sessão
  113. 113. Uma sessão é identificada pelo endereço de destino e um identificador de reserva (32 bits)
  114. 114. No caminho, os roteadores irão reservando os recursos necessários
  115. 115. Caso seja impossível em algum deles, será enviada uma mensagem de erro </li></ul>
  116. 116. RSVP
  117. 117. Especificação da Reserva <ul><li>Pode-se oferecer diferentes estilos de reserva onde usuários especificam como as reservas de grupos são agregadas
  118. 118. Um pedido de reserva (chamado flowdescriptor ) é feito pela destino
  119. 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) </li></ul>
  120. 120. <ul><li>Alguns parâmetros: </li></ul><ul><li>Atributo de reserva </li><ul><li>Reserva compartilhada ( shared ) – shared-explicit (SE)
  121. 121. Distinta ( distinct ) – fixed filter (FF) </li></ul><li>Seleção de originadores ( senders ) </li><ul><li>Lista explícita de fontes
  122. 122. wild card </li></ul></ul>Tipos de Reservas de Recursos
  123. 123. <ul><li>Não se espera o uso de RSVP em toda a Internet
  124. 124. Se prevê comunicação de roteadores que suportam RSVP através de tunelamento para criar a malha de roteadores RSVP
  125. 125. As nuvens não-RSVP devem ter capacidade em excesso para garantirem o serviço </li></ul>Reservas
  126. 126. Serviços Diferenciados - DS <ul><li>Arquitetura ISA pode significar grande complexidade a ser incorporada na rede
  127. 127. Para grandes quantidades de tráfego a sinalização prevista pode ser onerosa
  128. 128. A informação de estados nos roteadores pode tomar grandes proporções em redes maiores
  129. 129. Esta arquitetura é descrito na RFC 2475
  130. 130. Prevê uma forma de oferecer serviços QoS simples, fácil e com pouca geração de overhead
  131. 131. Não exige que as aplicações suportem a arquitetura – o provedor do serviço irá definir os níveis contratados </li></ul>
  132. 132. DiffServ - Premissas <ul><li>Os pacotes carregarão a informação de tratamento QoS usando o ca m po ToS do cabeçalho IP v4 ou o campo Traffic Class do IPv6
  133. 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. 134. DS prevê implementação nos roteadores encaminhando e enfileirando os pacotes se baseando unicamente no campo ToS
  135. 135. Não exige que se armazene nos roteadores informação de estado dos fluxos existentes </li></ul>
  136. 136. Campo Tipo do Serviço no padrão IPv4 – ToS <ul><li>Precedence – nível de urgência ou prioridade
  137. 137. TOS – a seleção do próximo salto </li></ul>
  138. 138. Campo DS – IPv4 <ul><li>O campo Codepoint DS define a classe de serviço sendo aplicada ao pacote IP
  139. 139. Categorias possíveis (2^6 = 64 classes):
  140. 140. Xxxxx0 – usado correntemente para definir classes previstas no padrões em uso (000000 significa serviço comum – melhor esforço)
  141. 141. Xxxx11 – reservado para testes e uso local
  142. 142. Xxxx01 – reservado para testes e uso local e futuros padrões </li></ul>
  143. 143. DiffServ - Serviços <ul><li>Um domínio DS é uma porção contígua da rede sujeita a um conjunto de políticas de DS administrada por uma única organização
  144. 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. 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 </li></ul>
  146. 146. SLA – Service Level Agreement <ul><li>O serviço IP oferecido por um provedor é definido em acordos onde se detalha o que será oferecido em termos de serviços e capacidades
  147. 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
  148. 148. Documentos SLA podem conter parâmetros como: </li><ul><li>Throughput, probabilidade de descarte e latência média da rede
  149. 149. Restrições nos pontos de entrada e saída da rede do provedor, definindo o escopo do serviço
  150. 150. Perfis de tráfego consistentes com o serviço que será oferecido (ex. Parâmetros token bucket )
  151. 151. A resposta da rede ao tráfego em excesso do cliente </li></ul></ul>
  152. 152. Operação DiffServ
  153. 153. Diffserv - Operação <ul><li>Interna </li><ul><li>A interpretação das classes de serviço deve ser consistente dentro de um domínio
  154. 154. Roteadores internos tem mecanismos para manipular os pacotes de acordo com as classes definidas </li><ul><li>Enfileiramento preferencial – PHB ( Per Hop Behaviour )
  155. 155. Descarte seletivo </li></ul></ul><li>Externa </li><ul><li>Inclui as regras PHB
  156. 156. Condicionamento de tráfego para o serviço desejado
  157. 157. Maior complexidade nos roteadores </li></ul></ul>
  158. 158. Destination Domain Providers Diffserv Domain Source Domain *Pre-marking *SLA *TCA Providers Diffserv Domain Non-DS Capable Domain *Pre-marking *SLA *TCA Diffserv Routers Non Diffserv Routers Ingress Router Egress Router Egress Router Ingress Router Interior Router *SLA *TCA *SLA *TCA Interior Router <ul><li>TCA - Traffic Conditioning Agreements
  159. 159. SLA - Service Level Agreements </li></ul>Host Egress Router PHB Conditioning and PHB Conditioningand PHB Host Egress Router PHB Conditioning and PHB Conditioningand PHB Host DS Unaware Router Arquitetura DiffServ
  160. 160. <ul><li>Classificador de pacotes – separa o tráfego em classes baseado no Codepoint ou em campos do pacote
  161. 161. Medidor ( meter ) – medidor de tráfego para verificar concordância com o perfil definido para o mesmo
  162. 162. Marcador ( marker ) – remarca codepoints se necessário de acordo com a política em vigor
  163. 163. Delineador ( shaper ) – formata o fluxo de pacotes para o perfil
  164. 164. Descartador ( dropper ) </li></ul>Função de Condicionamento de Tráfego Diffserv
  165. 165. Multiprotocol Label Switching (MPLS) <ul><li>Estratégia do IETF para oferecer recursos de encaminhamento que faltam ao protocolo IP (ou outros) nativamente
  166. 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. 167. Suporta IP, IPX, Apletalk, ATM e FR e pode trabalhar com protocolos como RSVP e OSPF
  168. 168. Define a necessidade de um protocolo para distribuição de labels: por exemplo: Label Distribution Protocol (LDP) entre LSR´s
  169. 169. Pode estabelecer rotas com base em critérios como: </li><ul><li>Endereços IP
  170. 170. Classe de serviço
  171. 171. Políticas </li></ul><li>Viabiliza de maneira fácil engenharia de tráfego (camada 3) </li></ul>
  172. 172. MPLS
  173. 173. MPLS <ul><li>Permite a comutação de pacotes de camada 3 rapidamente através da pesquisa de uma etiqueta ( label ) de 20 bits numa tabela de entradas de tamanho fixo (ao contrário do IP padrão que pesquisa em tabelas de roteamento com base em prefixos)
  174. 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. 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. 176. O protocolo de roteamento determina a topologia e as condições das rotas para que um caminho seja definido para a FEC
  177. 177. Os demais LSR’s são avisados de um novo caminho criado para uma FEC
  178. 178. Base de dados de encaminhamento ( Forwarding Information Base – FIB) : possui as entradas de cada label conhecido e seu encaminhamento </li></ul>
  179. 179. MPLS <ul><li>Idéia: roteadores rápidos como switches ATM (não seria mais necessário ter ambas as tecnologias na mesma rede)
  180. 180. Cria uma estrutura de suporte QoS semelhante à usada em ATM (mais rápida que o encaminhamento IP)
  181. 181. Suporte QoS multiprotocolo orientado à conexão (mesmo sobre redes IP)
  182. 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. 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. 184. Suporte a VPN – garantias de performance e segurança
  185. 185. Provê níveis SLA específicos e garantidos, diferenciando clientes </li></ul>
  186. 186. MPLS - Arquitetura LER de entrada LER de saída LSR
  187. 187. MPLS <ul><li>Cada pacote está associado a uma FEC ( Forwarding Equivalence Class ) através de um label
  188. 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. 189. MPLS permite roteamento explícito
  190. 190. Integração com Diffserv </li><ul><li>MPLS apresenta um campo QoS de 3 bits somente
  191. 191. Diffserv tem um campo de 6 bits podendo ter 64 classes de serviço </li></ul><li>Empilhamento de labels - hierarquia de caminhos </li></ul>
  192. 192. MPLS
  193. 193. Header MPLS <ul><li>Label de 20 bits
  194. 194. Exp - Informações DS ou PHB ( Class-of-Service - CoS)
  195. 195. S – bit stack
  196. 196. TTL </li></ul>
  197. 197. Cabeçalhos MPLS em Várias Tecnologias de Redes
  198. 198. Engenharia de Tráfego <ul><li>Baseada no conceito de encontrar rotas adequadas de acordo com exigências de serviço adequadas
  199. 199. Exige um protocolo de troca de informações de rotas
  200. 200. Protocolos de roteamento com extensões apropriadas para divulgação de rotas e recursos disponíveis na rede
  201. 201. Constraint-based routing - CBR - capacidade de encontrar caminhos com base em mecanismos de otimização e critérios de restrição
  202. 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. 203. Suporte a rotas hot stand-by
  204. 204. RSVP pode estabelecer caminhos sobre uma rede MPLS com base em critérios CBR
  205. 205. Pode-se ainda estabelecer rotas manualmente </li></ul>
  206. 206. Redes Multiserviços Data-Optimized Optical Advanced Services QoS Engine Packet Multiplexing to the Transport Layer
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×