Briefly about DOCSIS or is there life in CATV?
Actually, many have heard the abbreviation DOCSIS, but not everyone understands what it is and why it is needed. The most curious could even be enlightened by this issue in Wikipedia, but as practice shows, quite a lot of questions still remain. So,
1. what is it?
2. who needs it?
3. What is needed for this?
4. How to start?
Nervous people who do not want to delve into “How it's made?”, Please do not look under the habrakat - there is nothing interesting there.
So, we start with a general theory.
The acronym DOCSIS (Data Over Cable Service Interface Specifications) refers to the standard for data transmission over a television cable, which was adopted in 1998. This standard in the original implies data transfer up to 42/38 Mbit / s in downstream (to the user) and up to 10/9 Mbit / s in upstream (from the user).
When faced with technology for the first time, the question often arises - is it for everyone? No - the band is divided into all users hanging on these DS / US.
')
Actually there are several versions of DOCSIS:
- DOCSIS 1.0
- DOCSIS 1.1
- DOCSIS 2.0
- DOCSIS 3.0
- EURODOCSIS
If you do not go into details, the differences between them are reduced to QoS, frequencies, channel aggregation, bandwidth and modulations. Actually all this is directly related to the speed and viability in noisy networks.
Next, go to the strategic issues and the economic side.
Who needs it?
First of all, it is necessary for existing cable TV operators to expand the range of services by providing end users with high-speed Internet access and related links (VoIP, IPTV, or what fantasy is enough for).
I highlighted the word "existing" and because of the following (I think an obvious consideration).
Deploying a coaxial network just for the sake of providing users with access to the Internet from scratch is at least foolish and economically unwise, since there are much cheaper and faster technologies (for example, FTTB, ADSL, PON). As an example, if you are not a KTV operator, but let's say a PBX, then again building a coaxial network throughout the city does not seem to be useful. It’s much cheaper to go to ADSL - I think that’s understandable.
With the existing well-constructed coaxial network covering a large area, DOCSIS can be an optimal start, requiring minimal interventions in physics. Especially in sparsely populated areas such as the private sector, where the density of coupling with clutches / switches / boxes per customer unit may be space in the case of FTTB. Again, in the case of multi-storey buildings (so-called residential areas) with the existing competition in the form of “home networks”, it may make sense to deploy a parallel coaxial FTTB network, or if you really want to use HCNA, it will be cheaper and more promising.
Equipment
In general terms, a typical scheme would look like this:
Actually, it becomes immediately clear from the gutted image that in order to provide the end user with Internet access is required:
1. A cloud in which the Internet lives;)
2. server with installed DHCP, TFTP services
3. CMTS (Cable Modem Termination System)
4. coaxial network going to the subscriber
5. modem and the desire to connect the user
Briefly run through the above points.
1. everything is clear with the Internet - let's say we have it
2. the server will be used on something with which the administrator is familiar. Suppose he is familiar with FreeBSD / Linux;)
3. CMTS ... there are different
4. The main network requirement is the serviceability and availability of a return channel on the amplifiers. Serviceability is the permanent cutting out of illegal immigrants and tracking signal levels in the forward and reverse channels. Seasonal signal shat can very significantly spoil the lives of users and your support service.
5. A short list of manufacturers of modems can be found here . The Docsis modem is a rather specific device providing quite wide possibilities - starting with limiting the subscriber’s bandwidth directly on its modem and ending with filters (roughly remotely controlled by the firewall).
Where to begin?
Recently, administrators have been banging me with an enviable regularity; their administrators, guided by the considerations outlined in “Who needs it?”, Bought the CMTS (for some reason, this is often something like used BSR1000, BSR2000, CiscoUBR) and said “stick the Internet into KTV network.
For people familiar with an Ethernet or ADSL network, the DOCSIS network may not be completely transparent, and the number of gestures necessary for at least one modem to stop will be completely overloaded. It is rather difficult to do something without presenting the general principles of how this should work. The first thought that comes to mind is to screw the modem directly to the CMTS and see what happens. Naturally, nothing will work out - the modem will just light and light to flash with light bulbs and that's it. Nothing more will happen.
When trying to connect, the modem scans the whole range of frequencies for downstream / upstream availability and if it finds it tries to get the address via DHCP for the modem, if the address is received - the TFTP modem tries to get the specially assembled config for itself, then it tries to get a normal chew DHCP address for CPE (customer-provided equipment) which will most likely be a network card or router.
To work normally on a test bench, it should:
1. CMTS is configured
2. On the server raised the above services
3. The modem is connected via a bundle of tapes to provide nominal signal levels for DS / US.
1. We will not particularly focus on setting up the CMTS, because depending on the manufacturer, the physical realities of the network and the planned network topology, it will be very different. I am pleased with the presence of comprehensive documentation, which was bundled with all the devices that came into my hands - I think it should be more or less clear for people familiar with the cisco-like interface and the general theory of configuring network devices.
Minimal passes with the hands that should be carried out over the CMTS so that it is ready for bench tests look like:
- we register frequency DS
- we register frequencies and modulations for US
- we register the address of the DHCP server which we will reel
- we register secret key for configs
- prescribe passwords
- save
2. We raise on the server the services we need.
# cd / usr / ports / net / isc-dhcp31-server / && make install (build with Option82 support)
tftpd most likely we have a default, just uncomment it in /etc/inetd.conf
#cd / usr / ports / net-mgmt / docsis && make install
We need it to generate binary configurations for DOCSIS-compatible modems, as stated by pkg-descr.
Suppose we have configured the CMTS as 10.10.10.9, a DHCP rikvesta on the network of our host with an aipish 10.10.10.10, which looks at the CMTS. Then our /usr/local/etc/dhcpd.conf should look like this.
option domain-name "catv";
option domain-name-servers 10.10.10.10;
default-lease-time 3600;
max-lease-time 43200;
authoritative;
ddns-update-style none;
log-facility local7;
one-lease-per-client true;
deny duplicates;
subnet 10.10.200.0 netmask 255.255.248.0 {
default-lease-time 3600;
max-lease-time 86400;
option domain-name-servers 10.10.10.10;
option subnet-mask 255.255.248.0;
option routers 10.10.200.1;
include "/usr/local/etc/users_dhcp.conf";
}
subnet 10.10.100.0 netmask 255.255.248.0 {
default-lease-time 3600;
option subnet-mask 255.255.248.0;
option routers 10.10.100.1;
server-name "10.10.10.10";
option tftp-server-name "10.10.10.10";
option bootfile-name "cm_config/other.b";
next-server 10.10.10.10;
filename "cm_config/other.b";
option time-servers 10.10.10.10;
option time-offset 2;
include "/usr/local/etc/modems_dhcp.conf";
}
From which it should be clear that we reserve a network for modems on 10.10.100 / 21 and for user CPE networks on 10.10.200 / 21
For simplicity in the future, we will include hosts for sabnets from /usr/local/etc/modems_dhcp.conf and /usr/local/etc/users_dhcp.conf, respectively. To begin with, in /usr/local/etc/modems_dhcp.conf we enter our test modem as
host m1002 {
hardware ethernet 00:ff:ff:55:ff:f2;
fixed-address 10.10.100.3;
filename "cm_config/testmodem.b";
}
And in /usr/local/etc/users_dhcp.conf we add our test host:
host m10102002 {
hardware ethernet 00:cc:cc:99:aa:ff;
fixed-address 10.10.200.2;
}
The filename directive should hint that it contains the path (relative to the tftp root which is usually in / tftpboot) to the modem configuration. In the simplest case, the modem config (not suitable for real use! For testing purposes only! Achtung!) Will look like this:
#cat /tftpboot/cm_source/testing
Main {
NetworkAccess 1;
GlobalPrivacyEnable 0;
UsServiceFlow
{
UsServiceFlowRef 200;
QosParamSetType 7;
MaxRateSustained 0;
SchedulingType 2;
}
DsServiceFlow
{
DsServiceFlowRef 100;
QosParamSetType 7;
TrafficPriority 3;
MaxRateSustained 0;
}
MaxCPE 16;
}
Now we should compile it into a view acceptable to the modem using the previously collected docsis utility using the secret-key specified on the CMTS
#echo "sosecret" > /somewhere/key
#docsis -e /tftpboot/cm_source/testing /somewhere/key /tftpboot/cm_config/testing.b
Register routings for modem networks, and users on the CMTS in rc.conf:
static_routes="cable modem"
route_cable="10.10.200.0/21 10.10.10.9"
route_modem="10.10.100.0/21 10.10.10.9"
3. we assemble from
If we did everything right then on the CMTS in
bsr#show cable modem
We will see something like
Cable 0/0/D0/U0/C0 431 online 1458 26.0 10.10.100.3 00ff.ff55.fff2
And, accordingly, our test modem and test host, which as we remember on 10.10.100.3 and 10.10.200.2, should ping.
See how everything is simple and clear? - and you were afraid. =)
In the case of segmentation of the network into multiple CMTS to ensure increased fault tolerance and performance, everything looks the same. And boil down to the separation of different networks in the bashes.
The above configuration is not adequate for real use for several reasons:
Least:
- there are no filters for user isolation
- there is no prescribed snmp to collect statistics
- there is no modem binding to a specific CPE
Another good thing would be to do:
- channel shaping directly on the device
- take into account the features of various devices
- chop off the modem's web face, the user has nothing to do there
- competently build QoS
Initially, I really wanted to write a step-by-step manual on how to do it not just to “go Internet”, but also on how to correctly sell them to end users, with examples of configs, ready-made ASR, and so on. But as a writer from me honestly speaking, no - I am ashamed to be ashamed to show my bylokod which, moreover, is rather narrowly specific and in any case requires deep refinement for a particular operator :)
In general, the billing requirements for a DOCSIS network are very simple:
- be able to count traffic
- be able to count money
- make flexible fares out of calculated traffic money
- flexibly restrict user strip
- be able to compile configs to modems for each user on the fly + edit dhcpd hosts.
If everything is clear with the first four points - and actually all of the ASR are mainly engaged in them, then the last one should focus on the last one. Naturally, you can give one config to all, and then authenticate the user using internal ASR mechanisms (disparate authorizers) or, say, using the PPtP tunnel method, but I think this is just an additional crutch and a conscious rejection of the very convenient features provided by the technology.
I think now many, many people will say that the technology is dead, the road is not relevant and they poke me with a muzzle in FTTB, PON, HCNA. Yes, I know that there are such and that, for example, in densely populated high-rise buildings, the price / speed of the port is ten times cheaper with FTTB and that HCNA provides much more tasty speeds for the same coaxial price and the lack of the need to purchase a relatively expensive CMTS. If I'm interested, I can explain on my fingers why FTTB in the private sector is expensive, and why HCNA comes down to “almost FTTB” at the cost of the port, and why the public is not yet ready for PON. Again, for the application of any yet alive technology, there are always motives from “let's use the existing network” to “otherwise it will be too expensive and long”. Again, the choice to play dumping and chasing the speeds of home networks is not the best option for the above performance indicators and the DOCSIS provider’s trump card itself should be IMHO services provided over a single cable and their quality.
At this stage of development, DOCSIS 2.0 can more successfully compete with ADSL and 3.0 comes on the heels of the rest as a promising platform for Triple Play.
As always, at the end of the article I use my weak excuse that sounds like:
“Yes, I am not literate, I know. Language is not native, the school did not learn, although I guess this is a weak excuse. If you perceive the missing comma as a personal insult - I apologize in advance. Honestly - I did not want "
As a rule, acts;)
Article written by special order of the magazine "The Cableman"
Source: https://habr.com/ru/post/102429/
All Articles