UsPacketClass - Classify certain types of vendors | docsis.org

You are here

UsPacketClass - Classify certain types of vendors

7 posts / 0 new
Last post
torgeirbu
UsPacketClass - Classify certain types of vendors

Hi,

I have a question regarding matching certain types of modems (vendor / macadr ) in a UsPacketClass.
The purpose is to separate traffic into two serviceflows. The default serviceflow will go through one VRF and the traffic I'm trying to match through another VRF.

I can make it work by matching a specific MAC address (see below), but that would mean making A LOT of config files.
Instead I'm looking for a way to match a certain type of vendor or a mask of macaddresses.

I'm kind of stuck at this so any suggestions would be welcome

UsPacketClass {
ClassifierRef 2;
ServiceFlowRef 2;
RulePriority 20;
ActivationState 1;
LLCPacketClassifier { SrcMacAddress 00:08:B9:11:87:83; }
}

Regards
Torgeir

xsimio
This looks very complicated

This looks very complicated to achieve. I just spent 1 hour thinking about it, but came with no answer.
The MAC address is not the way to go, at least as long as you do not know anything about the two clients which connect behind the modem.

My understanding is that you have N where N>1 clients behind the modem and you want M clients on US SF1 and P clients on US SF2 where M+P=N

What can you tell us about the clients. If there is no way to make a difference between the clients, most probably it will be impossible.
Questions which could help:
- do you know the MAC address of the clients?
- do you know the IP of the clients?
- do you know the interface on which they connect?
- is the traffic they send marked in any way?

There must be something different between the clients, but you did not mention what that is. It looks similar to the CommunityWiFi problem and the difference there was a different SSID for some clients.

Looks interesting, let me know how can you differentiate the clients or what do you know about that traffic.

TLV 22.10.2 does not support a mask, only 22/23.10.1 which is DstMacAddress. I just realized that and it looks weird from MULPI spec perspective. Again, CableLabs specs are weird in many ways so nothing to worry about.

torgeirbu
It's a puzzle :)

Thanks for the reply xsimio.
Sorry about the late answer.

To elaborate this..

I have a set of STB (set-top-box) with known MAC-addresses. These boxes get a fixed range of IP-adresses (10.18.x.x)
I want all traffic from those MAC/IP's to go the SF2.
The customer also have the ability to connect a CPE-unit to the STB and will get a offical IP-address that will go to SF1 (default)

They all connect on Bundle 1.1 today.
The traffic is not marked in any way that we can distinguish.


CMTS
\_ STB
. |_ Modem mgmt IP
. |_ STB-IP (10.18.x.x)
. \
...\___ Customer CPE
...... \__ Official IP

The problem as you describe is in the lack of support for a mask in TLV 22.10.2, which would have solved the problem.

kwesibrunee
Unless I am missing something

Unless I am missing something....

Why don't you create a USClassifier by ip for the STBs instead of by known mac?

like so this is what we do for our MTAs same concept

UsServiceFlow
{
UsServiceFlowRef 2;
QosParamSetType 7;
ServiceClassName "U_STB";
}
UsPacketClass
{
ClassifierRef 100;
ServiceFlowRef 2;
ActivationState 1;
IpPacketClassifier
{
IpProto 257;
IpSrcAddr 10.18.0.0;
IpSrcMask 255.255.0.0;
IpDstAddr 0.0.0.0;
IpDstMask 0.0.0.0;
}
RulePriority 1;
}

If you need to give those settops different IPs based on MAC address or mac prefix (first 6 digits), this is usually best achieved with your dhcp server.

torgeirbu
Only problem with IP classification...

is that we're sending the different SF to different VRF's.
So when the STP asks for a IP (in multicast), it will go through the default SF and default VRF. When the IP is acquired it will try to send a ACK package to the DHCP-server (unicast), but this time, it will go through the SF we classified to those IP's and through another VRF. So the ACK will never reach the DHCP server and we can't finish the initial setup.

kwesibrunee
Gotcha...

Gotcha...

Then will adding the destination address and mask to the Packet classifier help? i.e. traffic from 10.18.0.0/16 destined to 10.18.0.0/16 gets new SF

like so?
UsPacketClass
{
ClassifierRef 100;
ServiceFlowRef 2;
ActivationState 1;
IpPacketClassifier
{
IpProto 257;
IpSrcAddr 10.18.0.0;
IpSrcMask 255.255.0.0;
IpDstAddr 10.18.0.0;
IpDstMask 255.255.0.0;
}
RulePriority 1;
}

xsimio
Classifier by destination IP

Classifier by destination IP can be the answer if the video traffic is SPTS unicast. Which is a good idea to be, I do like that design.
If the video traffic is multicast, the classifier by IP might not work as expected.

Are you doing Multicast traffic via Downstreams?

Log in or register to post comments