DSCP and IP Precedence

[gomez.juan]

We have an edge router (Cisco), and has a marking of packets based on DSCP. The edge router is connected to an ISP (not Cisco) which has a QoS based on IP Precedence. I understand that there is a conversion table between DSCP and IP Precedence, I wondered if this conversion is done automatically between routers, or must I have to configure a package marked on the edge router with IP Precedence to the exit to the ISP.

.

[rsavena14]

You can do remarking on your edge router or if your ISP can do the remarking for you it will be better.

Example:

Your marking is

DSCP EF (VOICE)

DSCP AF41 (Important Traffic)

Default (OTHERS)

ISP Marking is

IP Precedence 5

Important traffic is 3

Default is 0

you can do is create a policy-map that match DSCP EF and set the conform packet to IP Precedence 5

you can do the same with DSCP 41 set conform traffic to IP Precedence 3

but the last class you do not need to do anything because it's Zero.

[John Blakley]

In addition to what was said above, you'll want to make sure that your ISP recognizes your markings and agrees with them because they can remark to 0 as well.

[Vasileios Bouloukos MSc, ITIL, CCIE]

Hi Gomez,

There is not actually any need for remarking between the IP prec or TOS byte

The router just read different fields from the  ToS byte in case of IPprec or DSCP.

The IP prec is just the first 3 high order bits of the TOS byte.

The DSCP is the first 6 high order bits.

You can read the next doc for detailed info

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml

However, it is easier to have a common reference with your ISP regarding the QoS values to be eihter DSCP or IP Prec.

Finally, pay attention if you use encryption over the ISP (e.g. IPsec or GRE.)

In this case, you have to use the relevant conf. to your edge router in order to have the correct QoS prioritization (qos pre classify command) over the ISP.

I hope that helps,

Vasilis

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Short version, you probably don't need to do anything.  Long version . . .

As Vasileios correctly describes, IP Prec and DSCP both use the ToS byte.  DSCP usage, which uses the next 3 bits (as also noted by Vasileios), was designed for backward compatibility as DSCP Class groups map into IP Prec, e.g. AF2x maps to IP Prec 2.

As long as your provider only examines IP Prec, you seldom have a problem beyond agreeing that a IP Prec will treat the DSCP class as you desire.  An example of possible treatment difference, under DSCP recommendations, CS1 and AF1x are used for scavenger and bulk traffic and may receive priority lower than best effort traffic, but under IP Prec, precedence 1 might receive higher priority than IP Prec 0 (best effort).

Under really, really old RFCs, the extra bits in the ToS byte have meanings too, but very unlikely your provider uses these rules, although wouldn't hurt to ask - they might answer huh?

If your provider wants to remark ToS, that can cause some issue as just resetting IP Prec would leave the extra bits as they were.  For example, you have a packet marked as AF43, your provider remarks it to IP Prec 3, you'll then see it as AF33 not CS3.  Most providers, though, usually don't remark.

PS:

On other than really old IOS images, ToS marking are copied from an original packet's ToS to the tunnel's ToS.  QoS pre classify is only need when, on the tunneling router, you want to look at other header fields after the packet has been encapsulated.

[rsavena14]

Hi Gomez,

I think you do not need to do remarking if your isp ip precedence match you dscp.You will need rematking if the isp does not match you dscp marking. let's say you made you defaulft class to af1 instead of zero. but if you isp has the narkping as you (which rarely happens) you do nit need remarking. so my example above using dscp ef and ip precedence 5 may not need remarking.