MPLS QoS DiffServ Tunneling
Neste artigo abordaremos os três modos de DiffServ Tunneling em redes MPLS: Uniform mode, Pipe mode, Short pipe mode.
Aproveite e fique ligado na TechRebels e siga-me no Medium clicando follow lá em cima para acompanhar os próximos posts.
A tecnologia MPLS, também conhecida como label switching, insere um novo paradigma de encaminhamento, onde a decisão de encaminhar o pacote é baseada no valor de label presente no cabeçalho MPLS, que por sua vez é posicionado entre o cabeçalho da camada de rede e o cabeçalho da camada de enlace. Este label é bem simples, e possui 32 bits no total. Destes 32 bits, 3 bits correspondem ao campo EXP (Experimental) que é utilizado para classificar e escalonar os pacotes, de uma forma similar com o que ocorre com o campo ToS ou DSCP (IP) ou CoS (802.1q).
No momento do label imposition (label push), por default, a marcação de DSCP existente no pacote IP (no caso de IP sobre MPLS) é copiada para o valor EXP (bem, apenas os três primeiros bits), para que os routers internos do backbone (os que fazem somente label switching) possam aplicar as devidas políticas de queueing e scheduling. Este método é conhecido como ToS reflection.
Havendo uma marcação manual (através de uma policy) ou utilizando o ToS reflection, o foco deste post é a maneira como esta marcação no Label MPLS é tratada e o quão isso tem a ver com a marcação interna imposta (geralmente) pelo cliente, mo momento em que o label MPLS é removido (pop) e o pacote sai da rede MPLS.
Vale lembrar que, devido ao comportamento de PHP, na maioria dos casos temos que configurar a sinalização de explicit-null.
Uniform mode:
Neste modo, existe apenas um domínio de QoS. O PE de entrada (Ingress PE) realiza a classificação e marcação dos bits EXP no(s) label(s). À medida que o pacote trafega pelo core MPLS, esta marcação (EXP) pode ou não ser alterada. Caso haja alguma alteração neste valor, esta alteração é refletida no pacote IP no momento em que o pacote IP deixa a rede MPLS.
Este modo é o que introduz menor complexidade. Porém, pelo fato de a marcação original de QoS ser “perdida”, não atende alguns requisitos de SLA geralmente exigidos por clientes, onde a retenção da marcação fim a fim é desejada.
Pipe modes:
Existem dois tipos de Pipe modes, Short pipe e pipe (ou Long pipe). Os modos Pipe consistem em separar os domínios de QoS, fazendo com que a marcação do cliente permaneça intocada, fim a fim. Desta forma, tais modos atendem a requisitos mais específicos de SLA.
Em ambos os modos Pipe, o PE de entrada é responsável por classificar os valores DSCP do cliente e os mapear à uma determinada classe interna no backbone, sendo este último domínio de QoS transparente ao cliente.
O único comportamento que difere o modo short pipe e long pipe é a maneira como o queueing é feito ao sair da rede MPLS (no momento em que o label é removido e enviado através da interface PE-CE).
No modo long pipe, este queueing é feito baseado na marcação MPLS, independente do tipo de marcação presente no pacote IP. Caso o campo EXP do label MPLS tenha sido alterado durante o trânsito pelo backbone, a policy de queuing será baseada nesta nova marcação.
Já no modo short pipe, neste momento final do encaminhamento, o que vale é a marcação do cliente — que não foi alterada em momento algum. Sendo assim, o cliente tem um maior controle na maneira como seu tráfego é classificado e tratado durante o hop final.
Na prática:
Nos exemplos, utilizaremos o modelo 4-CoS para manter a simplicidade. O foco dos exemplos é apenas nos elementos MPLS (PE e P). Configurações do CE não são exemplificadas.
Vale ressaltar que os exemplos abaixo são meramente ilustrativos, e os valores configurados são arbitrários.
- Uniform mode:
No uniform mode, há apenas um domínio de QoS — fazendo com que este método, por ser o mais simples de ser implementado e gerenciado, seja normalmente utilizado em redes MPLS “self-managed”, onde toda a rede (incluindo o backbone MPLS) está sob o mesmo domínio administrativo.
Muitas plataformas, por padrão, automaticamente suportam configurar mapeamentos de certa marcação para a outra (table-maps). Porém, como uma melhor prática, é recomendado que as marcações sejam feitas explicitamente em policies (compatibilidade entre diversas plataformas).
Sumário de policies e pontos onde são aplicadas:
Ingress PE, link PE-CE -> Classificação e marcação DSCP->EXP
Ingress PE, interface backbone -> WFQ baseado em EXP
Egress PE, interface backbone -> Mapeamento MPLS EXP->QoS Group
Egress PE, interface PE-CE -> Mapeamento QoS Group->DSCP
PE1:
Ingress PE (interface PE-CE):!
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5
class-map match-any AF3
match ip dscp af31
match ip dscp af32
match ip dscp af33
match ip dscp cs3
class-map match-any AF2
match ip dscp af21
match ip dscp af22
match ip dscp af23
match ip dscp cs2
!
policy-map CUST1-INGRESS-4class
class REALTIME
police cir percent 30 conform-action set-mpls-exp-topmost-transmit 5 exceed-action drop
class AF3
police cir percent 10 conform-action set-mpls-exp-topmost-transmit 3 exceed-action set-mpls-exp-topmost-transmit 7
class AF2
police cir percent 35 conform-action set-mpls-exp-topmost-transmit 3 exceed-action set-mpls-exp-topmost-transmit 7
class class-default
police cir percent 25 conform-action set-mpls-exp-topmost-transmit 0 exceed-action set-mpls-exp-topmost-transmit 7
!
interface GigabitEthernet0/0/0.10
vrf forwarding CustomerA
encapsulation dot1q 10
service-policy input CUST1-INGRESS-4class
!
Ingress PE (interface do backbone):!
class-map match-any REALTIME-EXP
match mpls exp topmost 5
class-map match-any AF3-EXP
match mpls exp topmost 3
class-map match-any AF2-EXP
match mpls exp topmost 2
!
policy-map BACKBONE-4class
class REALTIME-EXP
priority percent 30
class AF3-EXP
bandwidth percent 10
fair-queue
class AF2-EXP
bandwidth percent 35
fair-queue
class class-default
bandwidth remaining percent 30
!
interface TenGigabitEthernet1/0/0
description To-BACKBONE
service-policy output BACKBONE-4class
!
PE2:
Egress PE (interface do backbone):!
class-map match-any REALTIME-EXP
match mpls exp topmost 5
class-map match-any AF3-EXP
match mpls exp topmost 3
class-map match-any AF2-EXP
match mpls exp topmost 2
!
policy-map EXP-TO-QG
class REALTIME-EXP
set qos group 5
class AF3-EXP
set qos group 3
class AF2-EXP
set qos group 2
!
interface TenGigabitEthernet2/0/0
description From-BACKBONE
service-policy input EXP-TO-QG
!
Egress PE (interface PE-CE):!
class-map match-any REALTIME-QG
match qos group 5
class-map match-any AF3-QG
match qos group 3
class-map match-any AF2-QG
match qos group 2
!
policy-map Queueing-UNIFORM
class REALTIME-QG
set dscp cs5
priority percent 30
class AF3-QG
set dscp cs3
bandwidth percent 10
class AF2-QG
set dscp cs2
bandwidth percent 35
class class-default
set dscp default
!
interface GigabitEthernet0/1/1.990
vrf forwarding CustomerA
encapsulation dot1q 990
ip address 192.168.1.1 255.255.255.254
service-policy output Queueing-UNIFORM
!
- Pipe modes:
Em contraste, nos Pipe modes temos um domínio de QoS do cliente, e um domínio de QoS da operadora. O mais importante a se lembrar à respeito dos Pipe modes é que a marcação não deve ser copiada para o cabeçalho IP no momento em que o pacote sai da rede MPLS.
Sumário de policies e pontos onde são aplicadas:
Long pipe e Short pipe:
Ingress PE, link PE-CE -> Classificação e marcação DSCP->EXP
Ingress PE, interface backbone -> WFQ baseado em EXP
PE1:
Ingress PE (interface PE-CE): !
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5
class-map match-any AF3
match ip dscp af31
match ip dscp af32
match ip dscp af33
match ip dscp cs3
class-map match-any AF2
match ip dscp af21
match ip dscp af22
match ip dscp af23
match ip dscp cs2
!
policy-map CUST1-INGRESS-4class
class REALTIME
police cir percent 30 conform-action set-mpls-exp-topmost-transmit 5 exceed-action drop
class AF3
police cir percent 10 conform-action set-mpls-exp-topmost-transmit 3 exceed-action set-mpls-exp-topmost-transmit 7
class AF2
police cir percent 35 conform-action set-mpls-exp-topmost-transmit 3 exceed-action set-mpls-exp-topmost-transmit 7
class class-default
police cir percent 25 conform-action set-mpls-exp-topmost-transmit 0 exceed-action set-mpls-exp-topmost-transmit 7
!
interface GigabitEthernet0/0/0.10
vrf forwarding CustomerA
encapsulation dot1q 10
service-policy input CUST1-INGRESS-4class
!
Ingress PE (interface do backbone): !
class-map match-any REALTIME-EXP
match mpls exp topmost 5
class-map match-any AF3-EXP
match mpls exp topmost 3
class-map match-any AF2-EXP
match mpls exp topmost 2
!
policy-map BACKBONE-4class
class REALTIME-EXP
priority percent 30
class AF3-EXP
bandwidth percent 10
fair-queue
class AF2-EXP
bandwidth percent 35
fair-queue
class class-default
bandwidth remaining percent 30
!
interface TenGigabitEthernet1/0/0
description To-BACKBONE
service-policy output BACKBONE-4class
!
A diferença na implementação dos métodos Long pipe e Short pipe se dá nesta última policy. No modo Long pipe, o queueing é baseado nas classes da operadora (se baseando no valor EXP).
Já no modo Short Pipe, o queueing é baseado na marcação DSCP do cliente.
Long pipe:
Egress PE, interface backbone -> Mapeamento MPLS EXP->QoS Group
Egress PE, interface PE-CE -> WFQ baseado em QoS Group
PE2:
Egress PE (interface do backbone): !
class-map match-any REALTIME-EXP
match mpls exp topmost 5
class-map match-any AF3-EXP
match mpls exp topmost 3
class-map match-any AF2-EXP
match mpls exp topmost 2
!
policy-map EXP-TO-QG
class REALTIME-EXP
set qos group 5
class AF3-EXP
set qos group 3
class AF2-EXP
set qos group 2
!
interface TenGigabitEthernet2/0/0
description From-BACKBONE
service-policy input EXP-TO-QG
!Egress PE (interface PE-CE): !
class-map match-any REALTIME-QG
match qos group 5
class-map match-any AF3-QG
match qos group 3
class-map match-any AF2-QG
match qos group 2
!
policy-map Queueing-LongPipe
class REALTIME-QG
priority percent 30
class AF3-QG
bandwidth percent 10
class AF2-QG
bandwidth percent 35
class class-default
set dscp default
!
interface GigabitEthernet0/1/1.990
vrf forwarding CustomerA
encapsulation dot1q 990
ip address 192.168.1.1 255.255.255.254
service-policy output Queueing-LongPipe
!
Short Pipe:
Egress PE, interface PE-CE -> WFQ baseado em DSCP
PE2:
Egress PE (interface PE-CE):!
class-map match-any REALTIME
match ip dscp ef
match ip dscp cs5
class-map match-any AF4
match ip dscp cs4
match ip dscp af41
match ip dscp af42
match ip dscp af43
class-map match-any AF3
match ip dscp af31
match ip dscp af32
match ip dscp af33
match ip dscp cs3
class-map match-any AF2
match ip dscp af21
match ip dscp af22
match ip dscp af23
match ip dscp cs2
class-map match-any AF1
match ip dscp af11
match ip dscp af12
match ip dscp af13
match ip dscp cs1
!
policy-map Queueing-Short-CustA
class REALTIME
priority percent 10
class AF4
bandwidth percent 20
fair queue
class AF3
bandwidth percent 10
fair queue
random detect
class AF2
bandwidth percent 20
fair queue
random detect
class AF1
bandwidth percent 10
fair queue
random detect
class class-default
bandwidth percent 30
!
interface GigabitEthernet0/1/1.990
vrf forwarding CustomerA
encapsulation dot1q 990
ip address 192.168.1.1 255.255.255.254
service-policy output Queueing-Short-CustA
!
Conclusão
Neste post abordamos os conceitos de diferentes modos de se implementar tunelamento de DiffServ em redes MPLS, Uniform, Long pipe e Short pipe; e exemplificamos os modelos de:
Policing no ingresso;
Mapeamento DSCP -> EXP;
Mapeamento EXP -> QoS Group (se necessário);
Queueing baseado em DSCP ou EXP (usando QoS groups).
Curtiu? Se quiser estender a leitura, seguem algumas referências sobre o tema:
https://www.amazon.com/End-End-QoS-Network-Design/dp/1587143690
Esse artigo sobre MPLS te ajudará no dia-a-dia?
Faltou algum ponto importante?
Fala pra gente nos comentários?
Se gostou do conteúdo, peço para compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)
Sobre o autor:
Bernardo, CCIE #57862
Cloud Network Engineer
