I don't have any lab, but some general tips.
1. Choose how many traffic classes you will provide to the end customer. Usually 4 or 6 classes are used in the world, as we have 8 different values in MPLS TrafficClass/EXP bits, at least 2 classes are reserved for SP itself(CS6 and CS7), maybe also IP Prec 2 will be also special class for SP itself, just for example.
2. Prepare Scheme of QoS for end customers to comply, like 4 class scheme:
Class1 - REALTIME/REA (IP Prec 5)
Class2 - PRIORITY/PRI (IP Prec 3)
Class3 - STANDARD/STD (IP Prec 1)
Class4 - DEFAULT/DEF(BE) (IP Prec 0)
So you customer should mark its traffic egress direction with IP Prec values(or DSCP, but not much outcome) for SP to be able to differentiate traffic in its core/backbone.
3. Prepare several Traffic Profiles your customers will choose from. Its just an example of 4 profiles, you may create more:
Profile 1 (80:60:30:10): REA - 80% of BW, Remaining BW(20%) is devided like: PRI - 60%, STD - 30%, DEF - 10%
Profile 2 (40:80:10:10): REA - 40% of BW, Remaining BW(60%) is devided like: PRI - 80%, STD - 10%, DEF - 10%
Profile 3 (20:40:20:20): REA - 20% of BW, Remaining BW(80%) is devided like: PRI - 40%, STD - 20%, DEF - 20%
Profile 4 (00:40:40:20): REA - 0%, PRI - 40%, STD - 40%, DEF - 20%
4. Define policy, how traffic will be treated in defined profiles. ex.:
REA traffic above defined CIR/CAR in profile will be dropped
PRE traffic above its CIR/CAR will be remarked to DEF/BE(0) class (or to lower class STD(3) if you wish) and transmitted into SP backbone
STD traffic above its CIR/CAR will be remarked to DEF/BE(0) class
DEF/BE traffic above its CIR/CAR will not be policed and SP will try to transmit it further into backbone as lowest priority traffic.
So this means you have to configure POLICING/RATE LIMITING of customer traffic ingress to PE device.
If customer exceeds REA class - you will drop violated traffic. If customer exceeds PRE class - you will just remark its exceeding or violating portion of traffic to lower class or to BE and transmit(try to do).
I assume that CE is directly connected to PE. If there is any last mile or L2 devices between CE and PE, consider where exactly you will be policing: at L2 edge device like switch or at SP MPLS PE device ingress.
Customer should mark each class and SHAPE its egress traffic towards SP PE device it it would like to comply with your profiles and to comply general SLA with SP. HQoS Aggregate shaper will help to comply with overall contracted BW and also eliminate traffic drops during microbursts when customer CIR is sub-line rate for Interface LINE RATE, ex:. customer contracted CIR is 200Mbit/s, but its CE device is connected to SP using 1Gbit/s interface with line rate of 1Bbit/s. If customer will not accordingly shape its egress traffic - SP ingress policer will drop partial amount of legit traffic. In case of sub-line rate customer shaper burst size should be at least twice as lower as SP policer burst size.
About sub-line rate read the book Read the book End-to-End QoS,
page 775 (Sub-Line-Rate Ethernet Design Implications)
page 795 (Sub-Line-Rate Ethernet: Hierarchical Shaping and Queueing Models)
5. At PE device you will configure some ingress policies which matches IP Prec bits from customer CE and set MPLS TC/EXP bits into the topmost label using policy described in section 4.
6. RFC 3270 defines three modes of MPLS DiffServ tunneling:
Uniform Mode - do not use it
Short Pipe Mode - treat traffic in mpls backbone using topmost label TC/EXP bits, but egressing traffic from PE to CE use DSCP/IPP bits in customers IP Packets. Usually when PHP is enabled and label 3 is advertised.
Pipe Mode - I'd prefer this. Configure MPLS Explicit Null label and carry TC/EXP bits unchanged until last hop PE device.
Read the book End-to-End QoS, part VII. There are also some configuration examples.