We currently have two service flows defined in our EMTA config, I'm looking for info on how this works? It appears the voice has allocated 384k and prioritized via a packetclass on the upstream and downstream. Is this bandwidth carved out of the CMTS or only used when a voice call is setup/active? See below. I'd like to unify our CM configs and EMTA configs, if the bandwidth isn't carved upon registration, I'm hoping it is dynamically allocated only during a call. See my SF config below.
UsServiceFlow
{
UsServiceFlowRef 1;
QosParamSetType 7;
TrafficPriority 0;
MaxRateSustained 5242880;
MaxTrafficBurst 40000;
MinReservedRate 0;
MinResPacketSize 64;
ActQosParamsTimeout 0;
AdmQosParamsTimeout 200;
MaxConcatenatedBurst 3044;
SchedulingType 2;
RequestOrTxPolicy 0x00000080;
IpTosOverwrite 0xfc00;
}
UsServiceFlow
{
UsServiceFlowRef 2;
QosParamSetType 7;
TrafficPriority 1;
MaxRateSustained 384000;
MaxTrafficBurst 4000;
MinReservedRate 128000;
MinResPacketSize 64;
ActQosParamsTimeout 0;
AdmQosParamsTimeout 200;
MaxConcatenatedBurst 4000;
SchedulingType 2;
RequestOrTxPolicy 0x00000088;
}
DsServiceFlow
{
DsServiceFlowRef 101;
QosParamSetType 7;
TrafficPriority 0;
MaxRateSustained 28343360;
MaxTrafficBurst 40000;
MinReservedRate 0;
MinResPacketSize 64;
ActQosParamsTimeout 0;
AdmQosParamsTimeout 200;
}
DsServiceFlow
{
DsServiceFlowRef 102;
QosParamSetType 7;
TrafficPriority 1;
MaxRateSustained 384000;
MaxTrafficBurst 4000;
MinResPacketSize 64;
ActQosParamsTimeout 0;
AdmQosParamsTimeout 200;
MaxDsLatency 5000;
}
UsPacketClass
{
ServiceFlowRef 2;
ClassifierRef 2;
RulePriority 1;
ActivationState 1;
IpPacketClassifier
{
IpProto 17;
IpSrcAddr 0.0.0.0;
IpSrcMask 0.0.0.0;
IpDstAddr 192.168.1.40;
IpDstMask 255.255.255.0;
SrcPortStart 2727;
SrcPortEnd 2727;
}
}
DsPacketClass
{
ServiceFlowRef 102;
ClassifierRef 102;
RulePriority 1;
ActivationState 1;
IpPacketClassifier
{
IpProto 17;
IpSrcAddr 192.168.1.40;
IpSrcMask 255.255.255.0;
IpDstAddr 0.0.0.0;
IpDstMask 0.0.0.0;
DstPortStart 2727;
DstPortEnd 2727;
}
}
/* CmMic 5d3429f0becbff3789bf496a0dea1d45; */
/* CmtsMic 196b9992dc49dea8f564d3aa52f4d81d; */
/*EndOfDataMkr*/
/* Pad */
}
It is reserving 128K US regardless of whether a call is active or not.
Probably not a good idea if you have many EMTA...
(although maybe the AdmQosParamsTimeout tears it down? I am not super familiar with that parameter)
The better solution :
Most EMTA can be configured to use DSX / DQOS-Lite to dynamically create UGS upstream flow and high-prio BE downstream flow while call is active.
If I look at a user with a call I see a couple extra SF's, with throughput up/down, they go away when the call is completed. Looks like it's dynamic, not sure where the minreserve comes from though. Notice SFID 7276, 7238, those appear to be dynamic and being used for voice. The other SFID's are what I created in my config file.
toombs#show cable modem 10.30.9.53 qos
Sfid Dir Curr Sid Sched Prio MaxSusRate MaxBrst MinRsvRate Throughput
State Type
32765 US act 623 BE 0 5242880 40000 0 2792
32564 US act 293 BE 1 384000 4000 128000 0
7276 US act 4726 UGS 0 0 0 0 87226
32764 DS act N/A N/A 0 28343360 40000 0 2873
32565 DS act N/A N/A 1 128000 4000 128000 0
7238 DS act N/A N/A 5 87200 1522 87200 87652
toombs#show packetcable global
Packet Cable Global configuration:
Packetcable DQOS Enabled : Yes
Packetcable Multimedia Enabled : No
Element ID: 14010
Max Gates : 2097152
Allow non-PacketCable UGS
Default Multimedia Timer value -
T1 : 200000 msec
Persistent gate : 0 hour
Volume Limit : STOPPED
Default DQoS Timer value -
T0 : 30000 msec
T1 : 300000 msec
Client Accept Timer: Disabled
Client Accept Timer Expired: 0
Packetcable DQOS Gate Send SubscriberID Enabled: No
GateID i/f SubscriberID GC-Addr State Type SFID(us) SFID(ds)
116964 Ca5/1/1 10.30.12.251 192.168.1.40 AUTH DQoS 0 0
333648 Ca6/1/0 10.30.1.201 192.168.1.40 AUTH DQoS 0 0
71676 Ca6/1/1 10.30.4.82 192.168.1.40 AUTH DQoS 0 0
40656 Ca7/0/0 10.30.4.60 192.168.1.40 AUTH DQoS 0 0
73448 Ca7/0/0 10.30.11.134 192.168.1.40 AUTH DQoS 0 0
24600 Ca7/0/3 10.30.8.98 192.168.1.40 AUTH DQoS 0 0
90316 Ca7/0/4 10.30.2.57 192.168.1.40 AUTH DQoS 0 0
139540 Ca7/0/5 10.30.6.122 192.168.1.40 AUTH DQoS 0 0
237872 Ca7/0/5 10.30.1.150 192.168.1.40 AUTH DQoS 0 0
60992 Ca8/0/1 10.30.11.132 192.168.1.40 AUTH DQoS 0 0
110172 Ca8/0/1 10.30.9.210 192.168.1.40 AUTH DQoS 0 0
44852 Ca8/0/3 10.30.10.190 192.168.1.40 AUTH DQoS 0 0
95724 Ca8/1/1 10.30.3.24 192.168.1.40 AUTH DQoS 0 0
259532 Ca8/1/1 10.30.8.196 192.168.1.40 AUTH DQoS 0 0
47152 Ca8/1/6 10.30.17.136 192.168.1.40 AUTH DQoS 0 0
OK that is interesting
Sfid Dir Curr Sid Sched Prio MaxSusRate MaxBrst MinRsvRate Throughput
State Type
32765 US act 623 BE 0 5242880 40000 0 2792 <====== data flow US (cm config file)
32564 US act 293 BE 1 384000 4000 128000 0 <====== voice flow US (cm config file)
7276 US act 4726 UGS 0 0 0 0 87226 <======= voice flow US (dyanmic DQOS)
32764 DS act N/A N/A 0 28343360 40000 0 2873 <====== data flow DS (cm config file)
32565 DS act N/A N/A 1 128000 4000 128000 0 <====== voice flow DS (cm config file)
7238 DS act N/A N/A 5 87200 1522 87200 87652 <====== voice flow DS (dynamic DQOS)
As you can see, there are DQOS flows being created dynamically when the call is active.
UGS for US, and high prio BE for DS.
87Kbps of traffic passing through for g.711 or whatever.
This is good!
And there are also some manually created voice flows.
Which are carrying no traffic.
This is bad, they are reserving traffic for no purpose.
They can probably be removed.
If it were me, I would remark out these voice flows from the cm config file and then run some further testing.
You will need to test every model of EMTA, to confirm they are all using packetcable DQOS, and none are using those manual voice flows
Good luck!
Ok, that's what I think too, we only support VOICE on modems we provide, so I just need to do a bit more testing, it appears we may have what we need.
Some MTA models require DQOS to be explicitly activated. Depending on the model, it is a proprietary SNMP setting, or a TLV entry that must be configured.