Briefly about DOCSIS or is there life in KTV?


    Actually the abbreviation DOCSIS has been heard by many, but not everyone knows what it is and why it is needed. The most curious could even enlighten on this issue on Wikipedia, but as practice shows, quite a few questions remain. So, we begin to pluck covers, let's deal with the questions:
    1. what is it?
    2. Who needs it?
    3. What is needed for this?
    4. How to start?

    The faint-hearted not wanting 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 transmitting data over a television cable, which was adopted in 98. This standard in the original assumes 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).
    Those who come across technology for the first time often have a question - is this for everyone? No - the band is divided into all users hanging on these DS / US.

    There are several versions of DOCSIS itself:
    - 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, band and modulations. Actually all this is directly related to speeds and vitality in noisy networks.



    Next, we turn to strategic issues and the economic side.

    Who needs this?
    First of all, it is necessary for existing KTV operators to expand the range of services by providing end users with high-speed Internet access and related add-ons (VoIP, IPTV, or whatever you have enough imagination).
    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 Internet access to users from scratch is at least stupid and not economically feasible, since there are much cheaper and faster technologies (for example FTTB, ADSL, PON). As an example, if you are not a KTV operator but, say, a telephone exchange, then again building a coaxial network throughout the city does not seem to be much cheaper to go to ADSL - I think it’s clear.

    With the existing well-built coaxial network covering a significant area, DOCSIS can be an optimal start, requiring minimal intervention in physics. Especially in sparsely populated areas such as the private sector, where the density of plugging with clutches / switches / boxes per consumer unit may turn out to be cosmic in the case of FTTB. Again, in the case of multi-storey buildings (the so-called sleeping areas) with 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 circuit will look like this:


    Actually, from the googled image, it immediately becomes clear that in order to provide the Internet to the end user, it is required:
    1. the cloud where the Internet lives;)
    2. a server with installed DHCP, TFTP services
    3. CMTS (Cable Modem Termination System)
    4. coaxial network going to to the subscriber
    5. modem and the desire to connect with the user

    Briefly go over the above points.
    1. everything is clear with the Internet - let's say we have it
    2. we will use the server on something the administrator is familiar with. Suppose that he is familiar with FreeBSD / Linux;)
    3. CMTS ... there are different black, white dirty with a short list of manufacturers can be found hereFor those completely ignorant, this (very rude) is such a large and expensive modem to which subscriber modems link.
    4. The main requirement for the network is serviceability and the presence of reverse channel amplifiers. Serviceability is the permanent cutting out of illegal immigrants and tracking signal levels in the forward and reverse channels. Seasonal signal shifts can greatly damage the lives of users and your support team.
    5. A short list of modem manufacturers can be found here . The Docsis modem is a rather specific device providing quite wide possibilities - starting with limiting the bandwidth of a subscriber right on his modem and ending with filters (roughly remotely controlled by a firewall).

    Where to begin?
    Recently, administrators of my boss have been knocking at me with enviable regularity, guided by the considerations outlined in "Who needs this?" bought CMTS (for some reason, most often it’s something like a used BSR1000, BSR2000, CiscoUBR) and said “put the Internet in the KTV network”.
    For people already familiar with Ethernet or ADSL, the DOCSIS network operation scheme may not be completely transparent, and the number of gestures necessary for at least one modem to ping will be completely frustrated. It is quite 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 turn out - the modem will simply flash light and music with lights and that's it. Nothing else will happen.

    When trying to connect, the modem scans the entire frequency range for the presence of downstream / upstream, 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 receive a specially assembled config for its darling, after which it tries to get the config via DHCP the address for CPE (customer-provided equipment) which will most likely be the network card or router.

    It should work normally on a test bench as follows:
    1. The CMTS is configured
    2. The above services are raised on the server
    3. The modem is connected through a bunch of tapes to ensure nominal signal levels for DS / US.

    1. We will not particularly focus on the CMTS setup, because depending on the manufacturer, the physical realities of the network and the planned network topology, it will vary greatly. I am glad that there is comprehensive documentation that came 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 setting up network devices.

    The minimum passes with your hands that you should spend on the CMTS so that it is ready for bench tests look like:
    - we prescribe the DS frequency
    - we prescribe frequencies and modulations for the US
    - we prescribe the DHCP server address that we will relay
    - we prescribe a secret key for configs
    - we prescribe passwords
    - we save

    2. We raise the services we need on the server.

    # cd / usr / ports / net / isc-dhcp31-server / && make install (compiled with Option82 support)
    tftpd most likely we have it by default, just uncomment it in /etc/inetd.conf
    #cd / usr / ports / net-mgmt / docsis && make install
    Which we need to generate binary configs for DOCSIS-compatible modems as pkg-descr says.

    Let's say we configured CMTS as 10.10.10.9 relaying DHCP rikvesta on the network of our host with ip 10.10.10.10 which looks at CMTS. Then our /usr/local/etc/dhcpd.conf should look like this. From which it should be clear that we reserve a network 10.10.100 / 21 for modems and a user CPE network 10.10.200 / 21
    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";

    }




    For ease of work in the future, we will include hosts for sabnet 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 in the form A in and /usr/local/etc/users_dhcp.conf add our test host: the filename directive should hint that it contains a path ( regarding tftp root which is usually in / tftpboot) to the modem’s logged in config In the simplest case, the modem config (not suitable for real use! For testing purposes only! Achtung!) Will look like this: Now we should compile it into a modem acceptable form using the previously compiled docsis utility using the secret-key specified on the CMTS

    host m1002 {
    hardware ethernet 00:ff:ff:55:ff:f2;
    fixed-address 10.10.100.3;
    filename "cm_config/testmodem.b";
    }




    host m10102002 {
    hardware ethernet 00:cc:cc:99:aa:ff;
    fixed-address 10.10.200.2;
    }




    #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;
    }




    #echo "sosecret" > /somewhere/key
    #docsis -e /tftpboot/cm_source/testing /somewhere/key /tftpboot/cm_config/testing.b


    We write down the routings for modem networks and users on CMTS in rc.conf: 3. we assemble a design combining DS and one of the US from matches and acorns of pigtails and tapes and ensuring the signal levels specified in the documentation pass to the modem. If we did everything correctly, then on CMTS we will see something like And, accordingly, our test modem and test host, which as we remember 10.10.100.3 and 10.10.200.2 should respond. See how simple and clear it is? “But you were afraid.” =) In the case of segmenting the network into multiple CMTS to ensure increased fault tolerance and performance, everything looks the same way. And boil down to spacing different networks on routs.

    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"





    bsr#show cable modem


    Cable 0/0/D0/U0/C0 431 online 1458 26.0 10.10.100.3 00ff.ff55.fff2








    The above config is not adequate for real use for several reasons:

    At least:
    - there are no filters for isolating users
    - there are no prescribed snmp for statistics collection
    - there is no modem binding to a specific CPE
    It would also be nice to do:
    - channel shaping directly on the device
    - take into account the features of various device
    - chop off the modem’s web face, the user has nothing to do there
    - correctly build QoS

    Initially, I really wanted to write a step-by-step manual on how to make it not just so that the Internet would go around, but also on how to competently sell them to end users, actually with examples of configs, ready-made ASR, etc. But since I’m honestly not a writer, it’s banal to me to show my bydcode which is also quite specific and in any case requires deep refinement for a specific operator :)
    In general terms, the requirements for billing operating in DOCSIS networks are very simple:
    - be able to to count traffic
    - to be able to count money
    - to make flexible tariffs from the calculated traffic money
    - to flexibly limit the user bandwidth
    - to 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 ASRs are mainly engaged in them, then the latter should focus on the latter. Naturally, you can issue one config for all, and then authenticate the user using the internal ACP mechanisms (mottled authorizers) or, say, 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, expensive, not relevant and poke me in the face in FTTB, PON, HCNA. Yes, I am aware that there are such ones and that, for example, in densely populated high-rise buildings, the price / port speed is much tens of times cheaper with FTTB and that HCNA provides much better tastes for the same coaxial with comparable cost of subscriber glands and no need to buy a relatively expensive CMTS. If it’s interesting, I can explain on my fingers why FTTB in the private sector is expensive, and why there HCNA comes down to “almost FTTB” at the cost of the port, and also why the public is not yet ready for PON. Again, for the application of any technology still alive, there are always motives from “let's use the existing network” to “otherwise it will be too expensive and long.”
    At this stage of development, DOCSIS 2.0 can more fully compete with ADSL, and 3.0 is 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'm not literate, I know. The language is not native, they did not learn at school, although I guess this is a weak excuse. If you perceive the missing comma as a personal insult - I apologize in advance. Honestly - I didn’t want it ”

    As a rule, it works;) The

    article was written on special order of the Cable Guy magazine

    Also popular now: