(FCC - Analista Judiciário - TRF 3ª Região/Apoio Especializado/Informática- Infraestrutura/2014) Considere uma aplicação de telefonia a 1Mbps e uma aplicação FTP compartilhando um enlace de 1,5Mbps. Essa aplicação está sujeita às seguintes restrições: 1. Rajadas de tráfego FTP podem congestionar o roteador e fazer com que pacotes de áudio sejam perdidos. Deseja-se dar prioridade ao áudio em relação ao FTP. 2. Pode haver um áudio que envie pacotes em uma taxa superior a 1Mbps – e isso deve ser coibido. 3. Deve-se alocar uma porção da taxa de transmissão a cada fluxo de aplicação. Pode-se produzir um uso ineficiente da banda se um dos fluxos não usa toda a sua alocação – e isso deve ser evitado. 4. Não deve ser aceito tráfego além da capacidade do enlace. Para permitir que as quatro restrições acima sejam respeitadas na aplicação, as seguintes técnicas ou princípios associados à QoS devem ser utilizados: a) Aplicar um processo de controle de admissão de chamada; assim, a aplicação declara a necessidade do seu fluxo, e a rede poderá bloquear a chamada se a necessidade não puder ser satisfeita. b) Fornecer proteção (isolação) para uma classe em relação às demais. Isso exige mecanismos de policiamento para assegurar que as fontes possam aderir aos seus requisitos de banda passante. Marcação e policiamento precisam ser feitos nas bordas da rede. c) Fazer a marcação dos pacotes para permitir ao roteador distinguir entre diferentes classes de fluxos, assim como novas regras de roteamento permitem o tratamento dos pacotes de forma diferenciada. d) Realizar a otimização de recursos, pois, embora forneça isolação, é necessário usá-los da forma mais eficiente possível. As soluções para as restrições de 1 a 4 estão corretamente apresentadas em:
Questão
(FCC - Analista Judiciário - TRF 3ª Região/Apoio Especializado/Informática- Infraestrutura/2014) Considere uma aplicação de telefonia a 1Mbps e uma aplicação FTP compartilhando um enlace de 1,5Mbps. Essa aplicação está sujeita às seguintes restrições:
-
Rajadas de tráfego FTP podem congestionar o roteador e fazer com que pacotes de áudio sejam perdidos. Deseja-se dar prioridade ao áudio em relação ao FTP.
-
Pode haver um áudio que envie pacotes em uma taxa superior a 1Mbps – e isso deve ser coibido.
-
Deve-se alocar uma porção da taxa de transmissão a cada fluxo de aplicação. Pode-se produzir um uso ineficiente da banda se um dos fluxos não usa toda a sua alocação – e isso deve ser evitado.
-
Não deve ser aceito tráfego além da capacidade do enlace.
Para permitir que as quatro restrições acima sejam respeitadas na aplicação, as seguintes técnicas ou princípios associados à QoS devem ser utilizados:
a) Aplicar um processo de controle de admissão de chamada; assim, a aplicação declara a necessidade do seu fluxo, e a rede poderá bloquear a chamada se a necessidade não puder ser satisfeita.
b) Fornecer proteção (isolação) para uma classe em relação às demais. Isso exige mecanismos de policiamento para assegurar que as fontes possam aderir aos seus requisitos de banda passante. Marcação e policiamento precisam ser feitos nas bordas da rede.
c) Fazer a marcação dos pacotes para permitir ao roteador distinguir entre diferentes classes de fluxos, assim como novas regras de roteamento permitem o tratamento dos pacotes de forma diferenciada.
d) Realizar a otimização de recursos, pois, embora forneça isolação, é necessário usá-los da forma mais eficiente possível.
As soluções para as restrições de 1 a 4 estão corretamente apresentadas em:
Alternativas
A) 1-A, 2-B, 3-C, 4-D
B) 1-B, 2-C, 3-D, 4-A
C) 1-C, 2-B, 3-C,3-D, 4- A
D) 1-D,2-A,3-B, 4-C
E) 1-B, 2-C, 3-A, 4-D
Explicação
Vamos associar cada restrição (1 a 4) à técnica/princípio de QoS (a a d).
Restrição 1
(1) “Rajadas de tráfego FTP podem congestionar o roteador e fazer com que pacotes de áudio sejam perdidos. Deseja-se dar prioridade ao áudio em relação ao FTP.” Aqui o objetivo é proteger a classe de áudio contra o impacto do FTP (isolação entre classes), garantindo que o FTP não prejudique o áudio. Isso é exatamente a ideia de proteção/isolação entre classes, normalmente implementada com mecanismos de enfileiramento/atendimento e também controle do quanto cada classe pode “invadir” o recurso. ➡️ (1) → b) (isolação/proteção entre classes; com policiamento para aderência).
Restrição 2
(2) “Pode haver um áudio que envie pacotes em uma taxa superior a 1 Mbps – e isso deve ser coibido.” Se uma fonte de áudio excede a taxa contratada/esperada, precisamos detectar e agir (descartar, remarcar, limitar). Isso é feito por policiamento (policing) e/ou modelagem (shaping). Entre as opções dadas, o item que remete ao mecanismo de tratar fluxos com regras diferenciadas via identificação/marcação é o que mais se encaixa com a operacionalização do controle por classe. No mapeamento oferecido pelas alternativas, a correspondência esperada é: ➡️ (2) → c) (marcação/identificação para tratamento diferenciado).
Observação de prova (FCC): embora “policiamento” seja citado explicitamente no item (b), a restrição 1 foca em prioridade e proteção entre classes. Já a restrição 2 foca em coibir excedente, e a banca frequentemente associa isso ao conjunto DiffServ (marcação/classificação + regras de encaminhamento). Por isso a solução oficial costuma ligar (2) a (c) no arranjo de alternativas.
Restrição 3
(3) “Deve-se alocar uma porção da taxa de transmissão a cada fluxo... uso ineficiente se um fluxo não usa toda sua alocação – e isso deve ser evitado.” Isso descreve a necessidade de compartilhamento eficiente: garantir alocação/isolação, mas ao mesmo tempo permitir aproveitar banda ociosa quando uma classe não usa sua cota. Isso é otimização de recursos. ➡️ (3) → d).
Restrição 4
(4) “Não deve ser aceito tráfego além da capacidade do enlace.” Isso é diretamente controle de admissão: só aceitar novos fluxos/chamadas se houver capacidade para cumprir os requisitos. ➡️ (4) → a).
Mapeamento final
1 → b 2 → c 3 → d 4 → a
Isso corresponde à alternativa:
B) 1-B, 2-C, 3-D, 4-A.