Cisco → IP QOS(quality of service) over MPLS usingIntegrated Service

hey,

for my project i am planning to implement a IP QOS over MPLS network using integrated and differential service...

For Differential service i got to know that we should use the DSCP bits and then mapping of those to ESP bits...
but i m not able to find any information or configuration info regarding IP QOS over MPLS n/w using integrated service..plz let me know if ther is any info regarding this...

thx..

INTSERV (integrated services) relies on ip rsvp, which may be used internally within a SP cloud, but customers will usually not be permitted to participate as its a bandwitdh reservation technology.

Providers may deploy INTSERV internally with MPLS traffic engineering tunnels to provide protected bandwidth from PE to PE across the core. This is completely transparent to the customer.

DIFFSERV (differentiated services) is the method deployed for customer participated QOS and differs from provider to provider, you will most usually need to ask how to mark traffic and what they will do with it.

Both require a good understanding of the profile for traffic crossing the links, and what happens to marked traffic based on the provider config, and how to corespondingly configure your equipment.

Also, ESP is an IPSEC term, you might be thinking of EXP (experimental bits) which were officially renamed to TC (traffic class) probablly a year ago?

thax for the reply...

ya i was referring to EXP bits....I kind got to know the concept of DiffService ...i.e consider a PS n/w running on mpls( running ldp protocol )...on the CE routers i try to set the ip dscp bits say for packets from 3 customers a ,b and c...later on for the PE router (ingress of mpls) we map the dscp into exp bits .... based on the class of service we need( i.e best effort or etc )...later on at egress we do reverse mapping from EXP to ip dscp bits...and send it to the CE 2 router ...
so is my understanding regarding Diff service correct??

thx...

Clarifying remark, my comments above and below are in reference to MPLS L3 VPN services.

I believe that most PE devices will properly take the IP PRECadence value (subset of DSCP bits) and map that automagically to the correct TC (traffic class, previously EXPerimental bits). This behavior can be manually overridden with a class-map on a PE facing the PCore matching ip prec or dscp and using the set action to manually force a TC value.

Generally speaking, the IP header is preserved (encapsulated) within 2 or more MPLS headers. There is no need on the egress side of a SP cloud to read the TC and SET any IP PREC or DSCP values, unless the provider is configured for remarking (very rare). Generally speaking, if you send a packet with a DSCP of AF31, it will pop into and back out of the cloud without changing or any special configuration by the provider.

Its important to remember that the IP header values for fields such as IP PRECadence and IP DSCP (differenciated service code point) are independant of the TC (traffic class / EXPerimental bits) transmitted as part of the MPLS labels stacked on top of the original IP payload. With other types of MPLS VPNs (such as L2 VPNs, VPLS, VPWS, etc.) there are many other marking techniques that come into play such as ethernet COS and so on.

ky thax...got to learn a lot...i have a few more questions...
Consider the network having following routers connected :

CE1 - PE1 - P1-P2-PE2-CE2
CE1 , CE2 are customer end routers not in mpls domain.
PE1 , PE2 are edge routers
P1 , P2 are LSR within mpls n/w

As I understand consider :

At CE1 :

-create a class where in we will match for traffic say ip's from a particular access list.
-in policy -set the dscp bits...
- apply on the ingress and egress interfaces with this policy..

At PE1 :

-match for the dscp bits(say af13) and set the corresponding exp values (1)
- apply above policy for ingress interface
- apply another policy say (priority 60 for customer class a , 40 priority for customer class b ) on the egress interface

At P1 :

- match for the mpls exp bits , one policy for applying priority and another policy which sets the mpls exp bits.

At PE2:

- match mpls exp bits and apply the policy which sets the ip dscp value and another which sets the priority for 2 customer classses.

AT CE2:

-match the ip dscp bits and one policy which sets the priority..

SO is this correct ??
So as u told PE2 configuration is not required ryt>??

PS: Sorry for the long post..

thx..

OK so first of all, QOS is a unidirectional mechanism. A router (any router) is atomic, it can only control the order of packets that it sends. That means there is no inbound shaping, queueing, or prioritization. IF you have an inbound policy, its usually only in one place from the customer to the cloud to police the amount of traffic they send you. This is usually done for EF (VOIP PAYLOAD / RTP) marked traffic depending on the provider.

The end device (HOST) should be responsable for marking its own traffic. Traffic classification is far too complex to be the responsibility of "the network".

The CE should have an outbound policy toward the cloud, usually coresponding with the outbound policy of the PE. Keeping the policies synchronized is not always the most efficient but usually best for operational simplicity.

The first PE should police inbound so the customer doesnt tag all packets EF. Usually the % EF priority queue traffic is charged extra in addition to the circuit cost.
Outbound toward the PCORE can match DSCP, and the policy is usually much simpler (fewer classes) depending on hardware support, and does not necessarily have to SET anything.

The P routers do not apply inbound policys, only output policies, usually simple, few classes, such as 50% EF, 50% everything else. Depending on hardware, can match exp bits or ip prec or dscp etc.

The outbound PE doesnt need an inbound policy from the core, but outbound policy on an untagged interface toward the customer is usually most complex, matching DSCP, applying WRED, priority queueing, etc. This PE does not SET DSCP ever, the original DSCP is STILL in the IP packet that was encapsulated in MPLS and unchanged.

In the end, the P would be the only thing looking at EXP/TC bits, but most hardware forwarding platforms dont have to.