Resumo

  • A RFC 5127 permite que várias classes Diffserv usem um tratamento de encaminhamento comum sem perder seus DSCPs ou identidades.
  • A classe carrega requisitos de ponta a ponta; o agregado é uma decisão local sobre como compartilhar recursos.
  • O tratamento comum precisa atender ao requisito mais rigoroso entre os membros, não ao desempenho médio da fila.
  • Classes com exigências parecidas ainda podem exercer pressão diferente por causa de tamanho de pacote, taxa e padrão de rajada.
  • O conceito de cada classe original deve sobreviver para que o próximo domínio possa mapear de outra forma.
  • O desenho preferido mantém o DSCP e classifica vários valores para uma fila; marcações locais precisam ser restauradas na saída.
  • Condicionamento, admissão ou policing por classe continuam necessários antes do controle adicional sobre a soma.
  • Um membro pode exceder sua cota enquanto o agregado permanece abaixo do teto; todos podem respeitar cotas e ainda sobrecarregar a soma simultaneamente.
  • Os quatro agregados da RFC são uma possibilidade, não uma obrigação, limite ou certificado de capacidade.
  • A validade depende de velocidade, utilização, profundidade de fila, scheduler, distribuição de pacotes e carga após falha.
  • Em MPLS, Traffic Class e LSP codificam a política local, mas não provam instalação, PHB observado ou resultado da aplicação.
  • A operação deve separar identidade, direito, medição individual, orçamento coletivo, configuração, telemetria e entrega.

Dois medidores diante da mesma fila

Considere três classes em um agregado Assured Elastic. Cada uma recebe uma taxa comprometida e a possibilidade de excedê-la com maior probabilidade de descarte. A fila também possui um teto total.

No primeiro dia, uma classe usa o dobro de sua parcela enquanto as outras quase não enviam. A soma cabe no teto. O medidor do agregado não encontra problema; o medidor individual mostra que um membro tomou margem que não lhe pertencia.

No segundo dia, cada classe respeita exatamente seu limite. Uma mudança de rota sincroniza seus picos e a soma supera o recurso. Todos os recibos individuais são válidos, mas o modelo coletivo falha.

A perda final pode ser parecida nos dois dias. A correção não é. No primeiro, é preciso restaurar o controle da classe. No segundo, rever capacidade, correlação ou admissão agregada. Guardar apenas o contador da fila destrói essa distinção.

Agregar tratamento não agrega obrigações

A RFC define treatment aggregate como a união de classes de serviço para fins de encaminhamento. Diferentes DSCPs podem compartilhar a mesma fila. Isso difere de um agregado construído ao redor de um único código e PHB.

O serviço de ponta a ponta continua sendo descrito pela classe. A fila apenas executa uma etapa local. Reduzir o número de schedulers não reduz quantos requisitos precisam ser atendidos.

Por isso, o agregado deve cumprir a exigência mais estrita dos membros. Uma classe tolerante não pode rebaixar a proteção de outra ao formar uma média. O resultado agregado pode parecer bom enquanto a distribuição de um membro já viola o objetivo.

Também é necessário observar características de tráfego. Duas classes podem desejar baixa latência, mas uma enviar pacotes pequenos e esparsos e outra produzir rajadas longas. O rótulo comum não descreve como elas disputam a fila.

A admissão vem antes do nome Real-Time

No exemplo Real-Time, telefonia, sinalização, conferência, interatividade e vídeo de difusão compartilham um tratamento. A RFC baseia essa escolha na suposição de que a borda já aplicou admissão e policing por classe.

Essa suposição cria uma cota previsível sobre a chegada. O scheduler protege o agregado contra rajadas elásticas, mas não verifica sozinho se sessões demais foram aceitas.

Uma tela que mostra EF ou Real-Time confirma a intenção de tratamento. Para confirmar a condição, é preciso ver a decisão de admissão, o envelope medido, a versão de política, a duração da autorização e a soma consumida.

Se o controle da borda se perder, a fila pode continuar instalada. O erro só surge quando a carga real encontra a capacidade. O recibo de configuração e o recibo de funcionamento são diferentes.

A identidade deve sair junto com o pacote

Cada domínio pode formar agregados diferentes. A RFC determina que a noção da classe original não seja destruída. O método recomendado mantém o DSCP e faz o classificador enviar vários valores ao mesmo tratamento.

Quando uma rede exige marcas internas, ela deve restaurar a indicação de ponta a ponta ao sair. Um túnel pode conservar a associação entre o valor externo e o interno, mas não prova que o decapsulador executou corretamente.

O registro necessário inclui DSCP de entrada, marca interna, associação de encapsulamento, resultado da saída e classificação no domínio seguinte. Sem ele, uma alteração silenciosa pode manter a conectividade e mudar a qualidade.

O DSCP também não é credencial. Apresentar um valor preferencial não prova direito contratual. Identidade declarada, classificação confiável e autorização permanecem separados.

Quatro agregados não são um teste de conformidade

Network Control, Real-Time, Assured Elastic e Elastic organizam o exemplo. O documento diz que uma rede pode usar mais, menos ou somente parte deles.

Network Control protege tráfego necessário à sobrevivência e pode separar controle do cliente do controle próprio do provedor. Real-Time depende de admissão. Assured Elastic preserva precedências de descarte. Elastic pode descartar CS1 antes de Default/CS0.

Uma interface com quatro cores não mostra membros, orçamento, precedência, classes não suportadas nem política sob falha. Ela mostra a forma escolhida.

A decisão correta pode ser três filas em um backbone muito rápido ou seis em outro ambiente. A quantidade precisa ser consequência de requisitos e medidas, não de deferência ao desenho do RFC.

A física não cabe no DSCP

A RFC relaciona grau de agregação com velocidade do enlace, profundidade de fila, atraso, jitter e scheduler. Links mais rápidos podem suportar maior agregação desde que a utilização permaneça no nível de engenharia.

Durante reroteamento, a mesma interface pode receber vários conjuntos de tráfego. O plano de proteção cumpre sua função e ainda assim elimina a margem de qualidade. Continuidade da rota não é continuidade de SLA.

Filas profundas absorvem rajadas e elevam espera. Filas rasas limitam espera e expõem perda. Pacotes grandes acrescentam serialização; taxas diferentes mudam a ocupação. O scheduler decide qual membro paga primeiro.

Os testes devem usar a mistura real, picos correlacionados e caminhos de contingência. A medição em repouso não valida a política sob pressão.

A fronteira entre provedores preserva classe, não fila

RFC 5127 recomenda que acordos entre provedores se apoiem em classes de serviço. Um domínio pode ter quatro agregados e o outro cinco; nenhum recebe autoridade sobre a arquitetura interna do vizinho.

O contrato precisa indicar classes aceitas, tratamento de classes não suportadas, regras de ingresso, mudanças de marca, restauração e medidas. O nome comercial da fila não fecha nenhuma dessas lacunas.

Ver o mesmo DSCP antes e depois prova continuidade do campo em dois pontos. Não prova recursos intermediários, PHB em cada salto nem experiência da aplicação.

Essa estrutura permite autonomia sem opacidade: o provedor pode mudar implementação, desde que preserve a identidade e prove o resultado acordado.

MPLS tem seu próprio limite de evidência

O apêndice usa E-LSP e o antigo nome EXP para transportar agregados. RFC 5462 renomeou o campo como Traffic Class. Cada domínio decide a própria codificação.

No E-LSP, os bits ajudam a inferir a classe de scheduling e a precedência de descarte. No L-LSP, um LSP representa uma única classe de scheduling e o suporte do agregado passa a ser por caminho.

Label, Traffic Class e escolha do LSP descrevem o plano de transporte. Tabelas instaladas descrevem configuração. Contadores e sondas descrevem execução. Medidas da aplicação descrevem resultado.

O exemplo observa que CS1 pode sofrer starvation em congestionamento. Isso pode ser compatível com baixa prioridade, mas não define entrega mínima, duração ou recuperação. Só a observação responde.

Limite das fontes

RFC Editor e Datatracker registram identidade, data e status Informational. IANA registra valores. Os RFCs correlatos definem arquitetura Diffserv, AF, EF, medidores e MPLS, e documentos posteriores mostram evolução.

As fontes não contêm um provedor atual nomeado, configuração comercial, captura, incidente, índice de adoção ou resultado de cliente. Este texto não atribui implementação nem desempenho; ele delimita o mecanismo e os recibos necessários.

Fontes