D1.1 Service Flow OIDs

There are no OIDs...OIDs only exist for SNMP objects.
The basic SF information is in simple TLVs - those are described in the Docsis specs.

Here's an example of a few 1.1 SFs and classifiers (decoded with the Docsis tool):

UsPacketClass
{
ClassifierRef 2;
ServiceFlowRef 2;
RulePriority 64;
IpPacketClassifier
{
IpProto 17;
SrcPortStart 2427;
SrcPortEnd 2427;
}
}

UsPacketClass
{
ClassifierRef 3;
ServiceFlowRef 2;
RulePriority 32;
LLCPacketClassifier
{
EtherType 0x030f16;
}
}

UsServiceFlow
{
UsServiceFlowRef 1;
QosParamSetType 7;
TrafficPriority 1;
MaxRateSustained 128000;
SchedulingType 2;
}

UsServiceFlow
{
UsServiceFlowRef 2;
QosParamSetType 7;
TrafficPriority 4;
MaxRateSustained 12000;
SchedulingType 2;
}

DsPacketClass
{
ClassifierRef 102;
ServiceFlowRef 102;
RulePriority 1;
IpPacketClassifier
{
IpProto 17;
DstPortStart 2427;
DstPortEnd 2427;
}
}

DsServiceFlow
{
DsServiceFlowRef 102;
QosParamSetType 7;
TrafficPriority 4;
MaxRateSustained 12000;
}

Hi Dawnrazor,

Could you please tell me what does classify the following:

LLCPacketClassifier
{
EtherType 0x030f16;

Regards,

Sure...

this is from the Docsis 2.0 RFI specs:

---
C.2.1.6.3 Ethertype/DSAP/MacType
Type, eprot1, and eprot2 indicate the format of the layer 3 protocol ID in the Ethernet packet as follows:
If type = 0, the rule does not use the layer 3 protocol type as a matching criterion. If type = 0, eprot1, eprot2 are
ignored when considering whether a packet matches the current rule.
.
.
.
If type = 3, the rule applies only to MAC Management Messages (FC field 1100001x) with a “type” field of its
MAC Management Message header (6.3.1) between the values of eprot1 and eprot2, inclusive. As exceptions,
the following MAC Management message types MUST NOT be classified, and are always transmitted on the
primary service flow:
Type 4: RNG_REQ
Type 6: REG_REQ
Type 7: REG_RSP
Type 14: REG_ACK
.
.
.
Type Length Value
[22/23].10.3 3 type, eprot1, eprot2
----

hex 0f = 15, 16 = 22

Paragraph 8.3.1, table 8-17 contains the different MAC MGMT message types (excerpt):

Type Value Version Message Name Message Description
15 2 DSA-REQ Dynamic Service Addition Request
16 2 DSA-RSP Dynamic Service Addition Response
17 2 DSA-ACK Dynamic Service Addition Acknowledge
18 2 DSC-REQ Dynamic Service Change Request
19 2 DSC-RSP Dynamic Service Change Response
20 2 DSC-ACK Dynamic Service Change Acknowledge
21 2 DSD-REQ Dynamic Service Deletion Request
22 2 DSD-RSP Dynamic Service Deletion Response

So, this classifier puts DSx messages into a SF with a higher than default priority (which is good for VoIP...). For obvious reasons, make sure the priority isn't higher than the one of the RTP SFs, though ;o)

Hi all,

Thanks for the explanation Dawnrazor.

If I'm not bothering you, I would like to make another question.

I can see that you are classifying also the MGCP signaling port 2427, on upstream and downstream, but how the RTP is classified?

Thanks,
Astrit.

Well, this example is for an eMTA...those will dynamically add and delete the SFs and classifiers for the voice traffic, so there's no need to configure them in the CM config.

If you're using a sMTA, you'll have to fiddle around with the config a lot more to get good service even when the DS/US has a high load...you might try UGS/AD for the US and a high priority (5) SF with a max BW of ~120 kbps for the DS.

The C3 has a mode where it can detect SIP traffic from sMTAs and prioritize the voice flows...that makes it easier, of course.

I think that also the CMTS must be qualified for Packetcable to understand these DSA and DSD messages.

If somebody can help me please.

I have a problem with DSx services.

When I generate a call from my network to the phone behind my eMTA everything works just fine, and I see these messages in the eMTA:

CM> RxRingCadence info: duration = 6000 ms; repeat = 1;

Short ring info: patternId=0; type=1; delay=550
P1-P2: 0xfffff000 0x00000000
HDSP: Static tone 'DTAS ONHOOK'

CM>
Generate secret/padCM transmit kDSA_REQ to CMTS
CM received DSA_RSP from CMTS
CM transmit kDSA_ACK to CMTS
CM transmit kDSC_REQ to CMTS
CM received DSC_RSP from CMTS
CM transmit kDSC_ACK to CMTS
SF modify OK for cnx 0
CM>
CM transmit kDSD_REQ to CMTS
CM received DSD_RSP from CMTS

But when I try to call somebody from the eMTA phone, it doesn't work, and the eMTA shows me these messages:

CM>
Default value for provItemId '14' did not exist
HDSP: Static tone 'DIALTONE'

CM>
Generate secret/padCM transmit kDSA_REQ to CMTS
CM received DSA_RSP from CMTS
CM transmit kDSA_ACK to CMTS
Retransmit final-response 2936345, attempt 0:

CM>
Retransmit final-response 2936345, attempt 1:

CM>
Retransmit final-response 2936345, attempt 2:

CM>
MAX RETRANSMIT - PRE-DISCONNECTED FINAL RESPONSE 2936345
CM>
DISCONNECTED FINAL RESPONSE 2936345!

and after a minute or so it deletes the service

CM transmit kDSD_REQ to CMTS
CM received DSD_RSP from CMTS

Does anybody faced with this kind of problem.

Thanks,
Astrit

Could anybody give me a hint;

why the CM could not Acknowledge the CMTS ?

CM>
Generate secret/padCM transmit kDSA_REQ to CMTS
CM received DSA_RSP from CMTS
CM transmit kDSA_ACK to CMTS
Retransmit final-response 2936345, attempt 0:

CM>
Retransmit final-response 2936345, attempt 1:

CM>
Retransmit final-response 2936345, attempt 2:

Please see docsis2.0 spec.

I red the docsis 1.1 and 2.0 specs, I saw how DSA, DSC, DSD messages shoud work, but maybe my CMTS (Juniper G1) doesn't work good with DSx messages. That's why I asked for DQoS in G1 Juniper CMTS!