Classification
On the CE, packets will be classified with extended access lists (ACLs). These ACLs can match packets on IP S/D address, protocol type, and UDP/TCP port numbers.
The ACLs for Business (100) Streaming (101) and Voice (102) traffic should be agreed with the customer. Any non-classified traffic will go into Standard traffic class, which is implemented as class-default in MQC defintion.
The following is an example ACL for Voice traffic: !
! Voice !
access-list 102 permit udp any any range 16384 32767 !
! Voice Signalling MGCP !
access-list 102 permit udp any any eq 2427 access-list 102 permit tcp any any eq 2428 access-list 102 permit tcp any any eq 1720 !
! H.323 voice control traffic !
access-list 102 permit tcp any any range 11000 11999 ! MPLS IP IP GSR P MDRR WRED MDRRWRED 7206VXR10k, PE N/A LL Q W R E D 10k, 7206 VXR PE N /A LLQ WRED Managed CE N /A LL Q W R E D Managed CE N /A N /A LA N MPLS LA N Classification (ACL) Marking (CAR, DSCP) Policing (MQCLI) Queuing (DSCP) Cong. mgmt. (DSCP) Classification (QoS-group) Marking (DSCP->EXP auto)
Queuing (DSCP) Cong. mgmt. (DSCP) Classification (DSCP) Queuing (DSCP) Cong. mgmt. (DSCP) Classification (EXP) Queuing (EXP MDRR) Cong. mgmt (EXP) [to-fabric, to-interface]
The ACL for Management (103) traffic should match SNMP, TFTP, TELNET and any other required traffic to and from the network management systems IP address range.
!
access-list 103 permit tcp any any eq bgp access-list 103 permit udp any any eq rip
access-list 103 permit tcp any <NOC_lan> eq telnet access-list 103 permit udp any <NOC_lan> eq snmp access-list 103 permit udp any <NOC_lan> eq tftp !
Voice signalling traffic will need to be classified and marked appropriately. Depending on the customer VoIP implementation, the different possibilities are:
• RTCP: odd RTP port numbers
• H.323 / H.245 standard connect: TCP 11xxx
• H.323 / H.245 fast connect: TCP 1720
• H.323 / H.225 RAS: TCP 1719
• Skinny control traffic: TCP 2000-2002
• ICCP: TCP 8001-8002
• MGCP: UDP 2427, TCP 2428
Dependent on the actual signalling method used (packet sizes), speed of the access links and the number of concurrent voice call set-ups that need to be supported, two possible design options can be taken with regards to the queuing method used.
• Queue the voice signalling packets in the same PQ as the actual voice bearer packets. This will result in a simpler design but could delay the transmission of some of the voice bearer packets (dependent on voice signalling packet size, access link speed and number of concurrent voice call set-ups). This could than have an impact on the voice delay / jitter.
• Queue the voice signalling packets in another normal class queue. This should ideally be a separate class queue from the ones that are used for regular data traffic to ensure delivery of the voice signalling packets. This will result in a more complicated design where bandwidth needs to be allocated for the voice signalling class. Also, voice signalling packets might be delayed through the network resulting in a delay in the voice call set-up process. The advantage is that the actual voice quality will not be impacted as no voice signalling packets will travel in the PQ.
Testing has indicated that, without cRTP (Compressed Real Time Protocol) enabled, the effect of mapping VoIP signalling packets together with the VoIP bearer packets in the same priority queue is negligible. The signalling packets have little effect on the latency nor do they cause any drops due to the default bust size of 200ms that has been built into the priority queue. Therefore, the design recommendation is to match the VoIP signalling packets with ACL 102 and queue them together with the VoIP bearer packets in the priority queue.
It should however be understood that VoIP signalling implementations differ and that some might have a negative effect on the performance of the priority queue. In that event, the VoIP signalling traffic needs to be mapped in another class queue (Business, for example).
The classified traffic will subsequently be mapped in their respective classes using the MQCLI. The Standard traffic will not match any of the classes and will be mapped in the default class (class-default). A maximum of 64 classes can be defined on a single router.
!
class-map match-all business match access-group 100 class-map match-all streaming match access-group 101 class-map match-all voice match access-group 102 class-map match-any management match access-group 103 !
Marking
After classification, packets need to be marked with their appropriate IP precedence or DSCP value. The following is the required configuration for Class Based Marking on CE router.
Marking of Business, Streaming and Voice classes is actually configured through the MQCLI police command, because these classess need to be policed to the SLA limits.
Standard traffic class is not policed, hence we can mark all the traffic with MQCLI “set ip dscp” command. !
policy-map customer_profile class business
police 128000 8000 16000 conform-action set-dscp-transmit 10 exceed-action drop class streaming
police 64000 2000 2000 conform-action set-dscp-transmit 26 exceed-action drop class voice
police 64000 2000 2000 conform-action set-dscp-transmit 46 exceed-action drop class management
police 24000 8000 16000 conform-action transmit exceed-action drop class class-default
set ip dscp 0 !
The following is the required configuration for LPR marking of the locally generated management traffic. As discussed before, ACL 103 matches all management traffic.
!
ip local policy route-map management !
route-map management permit 10 match ip address 103
! here we simulate the set ip dscp 48 command
set ip precedence 6 set ip tos 0 !