cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6890
Views
9
Helpful
6
Replies

DSCP to MPLS EXP field

StevieOliver_2
Level 1
Level 1

Hi

Could someone clarify this for me please.

If I send a packet from a CE to PE with DSCP EF marked my understanding is by default the top 3 bits are copied to the MPLS EXP bits.

So the packet now has a label(s) with EXP value 5 and an internal IP packet with DSCP EF.

Assuming nothing changes the label value as it crosses the MPLS cloud at the EGRESS will the IP packet have the EXP bits imposed on it ?  Thus changing the DSCP value EF to cs5/IP Prec 5 ?  Or will the EXP bits be copied into the ToS byte top 3 bits only leaving the others unchanged ?  This then causing the IP packet to emerge with its original EF marking ?

Or have I completely misunderstood this ?

Thanks, Stephen.

6 Replies 6

StevieOliver_2
Level 1
Level 1

I think by just writing out my previous question I have understood what happens better.

Only the top 3 bits of the ToS byte are acted on as the IP packet leaves the MPLS domain.  So the remaining 3 dscp bits are unchanged across the cloud and the DSCP value is potentially preserved assuming nothing changes the MPLS EXP value in the cloud. 

Is that correct ?

Stephen.

Hi Stevie,

At imposition: The first 3 bits of DSCP/prec are copied into the EXP bits of the MPLS labels. Also, when an already labeled packet is imposed with further labels, the EXP bits at ingress side are copied to the imposed labels at egress side.

At disposition: The EXP bits are not copied down to the exposed IP header. Or, if the MPLS label stack is not empty after a POP operation, then the EXP bits are not copied down to the exposed MPLS label.

If you want the behavior where the EXP bits at ingress side are copied to the IP header or to the exposed MPLS label at egress side, when disposing one or more labels, then you'll need to configure MQC.

Thanks,

Luc

P.S. EXP bits are now renamed to TC or "Traffic Class". See RFC 5462.

Many thanks Luc

So effectively at disposition unless we do a MQC policy then the DSCP bits in the exposed IP packet are that same as those at ingress to the MPLS network.

This is what I want to achieve.  To return the customer the DSCP bits they imposed in the first instance.

Stephen.

Many thanks Luc

So  effectively at disposition unless we do a MQC policy then the DSCP bits  in the exposed IP packet are that same as those at ingress to the MPLS  network.

LDG> Correct.

This is what I want to achieve.  To return the customer the DSCP bits they imposed in the first instance.

LDG> This is the default behavior, the behavior of the pipe or short pipe model.

Stephen.

Hi Luc,

I had a small question here on this topic.

Since the most left 3 significant bit are copied from the TOS field in the IP header to the EXP bit of the MPLS Label, that means ONLY the Precednce marking are copied.

what if the customer is marking based on DSCP value. then the MQC has to be configured on both Ingress and Egress LSRs ignoring/overriting the MPLS exp default behaviour.

I use to suggest customers Mark based on Precedence Value and do MQC at the Egree LSR where the label disposition takes place. This eleminates maintaing huge QoS config and mistakes which can take place across SP and for simplicity purposes.

Your Openion.

Regards,

Mohamed

Hi Mohamed,

Yes, only the first 3 bits are copied. So if anyone uses more bits in DSCP, they'll have to use some mapping on the edge routers.

Using only 3 bits for QOS already gives you 8 levels for QOS, which is enough for most people and gives a shorter configuration, indeed.

Thanks,

Luc

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: