Собственно аббревиатуру DOCSIS слышали многие, но далеко не все представляют что это и зачем оно нужно. Самые любопытные могли, даже просветится этим вопросом в википедии, но как показывает практика довольно много вопросов все равно остается. Итак,
1. что это?
2. кому это нужно?
3. что для этого нужно?
4. как начать?
Слабонервных не желающих вникать в «How it's made?» просьба под хабракат не заглядывать — там ничего интересного нет.
Итак, начинаем с общей теории.
Аббревиатурой DOCSIS (Data Over Cable Service Interface Specifications) обозначается стандарт передачи данных по телевизионному кабелю, который был принят в 98 году. Сей стандарт в оригинале предполагает передачу данных до 42/38 Мбит/с в даунстриме (к пользователю) и до 10/9 Мбит/с в апстриме (от пользователя).
У столкнувшихся с технологией впервые часто возникает вопрос – это каждому? Нет – полоса разделяется на всех пользователей, висящих на этих DS/US.
Собственно версий DOCSIS существует несколько:
— DOCSIS 1.0
— DOCSIS 1.1
— DOCSIS 2.0
— DOCSIS 3.0
— EURODOCSIS
Если не пускаться в подробности различия между ними сводятся к QoS, частотам, агрегации каналов, полосе и модуляциям. Собственно все это прямо связано со скоростями и жизнеспособностью в зашумленных сетях.
Далее переходим к стратегическим вопросам и экономической стороне.
Кому это нужно?
Нужно это в первую очередь существующим операторам КТВ для расширения спектра услуг предоставлением конечным пользователями высокоскоростного доступа в Интернет и сопутствующих навесок (VoIP, IPTV ну или на что фантазии хватит).
Я выделил слово «существующим» и из-за следующего (думаю очевидного соображения).
Развертывать коаксиальную сеть только ради предоставления доступа к Интернетам пользователям с нуля как минимум глупо и экономически не целесообразно, поскольку есть намного более дешевые и быстрые технологии (например FTTB, ADSL, PON). Как пример если вы не оператор КТВ а скажем АТС то опять же строить коаксиальную сеть по всему городу не представляется полезным значительно дешевле податься в ADSL – думаю понятно.
При существующей грамотно построенной коаксиальной сети накрывающей значительную площадь DOCSIS может стать оптимальным стартом, требующим минимальных вмешательств в физику. Особенно в слабозаселенных районах типа частного сектора, где плотность утыкивания муфтами/свичами/боксами на единицу потребителя может оказаться космической в случае FTTB. Опять же в случае многоэтажной застройки (т.н. спальных районах) с наличествующей конкуренцией в виде «домашних сетей» возможно, имеет смысл развертывать параллельную коаксиальной FTTB сеть или раз уже очень хочется использовать HCNA – будет имхо дешевле и перспективней.
Оборудование
В общих чертах типичная схема будет выглядеть так:
Собственно из загугленной картинки сразу становится понятно что для того чтобы предоставить оконечному пользователю интернет требуется:
1. облачко в котором живет интернет ;)
2. сервер с установленными сервисами DHCP, TFTP
3. CMTS (Cable Modem Termination System)
4. коаксиальная сеть идущая к абоненту
5. модем и желание подключится у пользователя
Кратко пробежимся по указанным выше пунктам.
1. с интернетом все понятно – допустим он у нас есть
2. сервер будем использовать на чем-то с чем знаком администратор. Предположим что знаком он с FreeBSD/Linux ;)
3. CMTS… бывают разные
4. Основным требованием к сети является – обслуживаемость и наличие на усилителях обратного канала. Обслуживаемость – это перманентное вырезание нелегалов и слежение за уровнями сигнала в прямом и обратном каналах. Сезонный шат сигнала может очень существенно подпортить жизнь пользователям и вашей службе поддержки.
5. С кратким перечнем производителей модемов можно ознакомиться здесь. Docsis модем является довольно специфичным устройством предоставляющий довольно широкие возможности – начиная ограничением пропускной способности абонента прямо на его модеме и заканчивая фильтрами (грубо удаленно управляемым фаерволом).
С чего начать?
В последнее время ко мне с завидной регулярностью стучат админы начальство которых, руководствуясь соображениями, изложенными в «Кому это нужно?» купило CMTS (почему-то чаще всего это что-то типа подержанных BSR1000, BSR2000, CiscoUBR) и сказало «засунь интернет в КТВ сеть».
Для людей знакомых уже с Ethernet или ADSL схема работы DOCSIS сети может оказаться не совсем прозрачной а количество телодвижений нужных для того чтобы хотя бы один модем запингался – окончательно упоротым. Довольно сложно что-то сделать не представляя общих принципов того как это должно работать. Первая мысль которая приходит в голову это прикрутить модем напрямую к CMTS и посмотреть что получится. Естественно не получится ничего – модем будет просто светомузыкально мелькать лампочками и все. Больше ничего не случится.
При попытке соединиться модем сканирует весь диапазон частот на тему наличия downstream/upstream и если находит пытается получить адрес посредством DHCP для модема, если адрес получен — модем по TFTP пытается получить специальным образом собранный конфиг для себя родимого, после чего если конфиг нормально прожеван пытается получить по DHCP адрес для CPE (customer-provided equipment) коим являться будет скорее всего сетевая плата либо роутер.
Работать в норме на тестовом стенде оно должно так:
1. CMTS настроена
2. На сервере подняты вышеуказанные сервисы
3. модем подключен через пачку тапов чтобы обеспечить номинальные уровни сигнала для DS/US.
1. На настройке CMTS заострять внимание мы особо не будем, ибо в зависимости от производителя, физических реалий сети и планируемой топологии сети она будет очень сильно разниться. Радует наличие всеобъемлющей документации, которое шло в комплекте со всеми попадавшими ко мне в руки дивайсами – думаю по ней должно быть все более-менее понятно для людей знакомых с cisco-like интерфейсом и общей теорией настройки сетевых устройств.
Минимальные пассы руками которые следует провести над CMTS чтобы она была готова к стендовым испытаниям выглядят как:
— прописываем частоту DS
— прописываем частоты и модуляции для US
— прописываем адрес DHCP сервера который мы будем рилеить
— прописываем secret key для конфигов
— прописываем пароли
— сохраняемся
2. Поднимаем на сервере нужные нам сервисы.
# cd /usr/ports/net/isc-dhcp31-server/ && make install (собираем с поддержкой Option82)
tftpd скорее всего у нас есть по умолчанию, просто раскоментируем его в /etc/inetd.conf
#cd /usr/ports/net-mgmt/docsis && make install
Который нужен нам для генерации бинарных конфигов для DOCSIS-совместимых модемов как гласит pkg-descr.
Допустим CMTS мы настроили как 10.10.10.9 рилеящую DHCP риквесты на сетевую нашего хоста с айпишкой 10.10.10.10 которая смотрит на CMTS. Тогда наш /usr/local/etc/dhcpd.conf должен выглядеть следующим образом
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";
}
Из чего должно быть понятно что мы резервируем под модемы сеть 10.10.100/21 и под пользовательские CPE сеть 10.10.200/21
Для простоты работы в будущем хосты для сабнетов мы инклудим из /usr/local/etc/modems_dhcp.conf и /usr/local/etc/users_dhcp.conf соответственно. Для начала в /usr/local/etc/modems_dhcp.conf мы вписываем наш тестовый модем в виде
host m1002 {
hardware ethernet 00:ff:ff:55:ff:f2;
fixed-address 10.10.100.3;
filename "cm_config/testmodem.b";
}
А в и /usr/local/etc/users_dhcp.conf добавляем свой тестовый хост:
host m10102002 {
hardware ethernet 00:cc:cc:99:aa:ff;
fixed-address 10.10.200.2;
}
Директива filename должна намекать на то что в ней содержится путь (относительно tftp root который обычно в /tftpboot) к забинареному конфигу модема. В простейшем случае конфиг модема (не пригодный к реальному использованию! For testing purposes only! Achtung!) будет выглядеть следующим образом:
#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;
}
Теперь нам следует его скомпилить в приемлемый для модема вид при помощи ранее собранной утилиты docsis используя указанный на CMTS secret-key
#echo "sosecret" > /somewhere/key
#docsis -e /tftpboot/cm_source/testing /somewhere/key /tftpboot/cm_config/testing.b
Прописываем рауты для сетей модемов, и пользователей на CMTS в 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. собираем из
Если мы все сделали правильно то на CMTS в
bsr#show cable modem
Мы увидим что-то типа
Cable 0/0/D0/U0/C0 431 online 1458 26.0 10.10.100.3 00ff.ff55.fff2
И соответственно наши тестовый модем и тестовый хост которые как мы помним 10.10.100.3 и 10.10.200.2 должны пингаться.
Видите как все просто и наглядно? – а вы боялись. =)
В случае сегментирования сети на множество CMTS для обеспечения повышения отказоустойчивости и быстродействия все выглядит аналогичным образом. И сводиться к разнесению разных сетей по раутам.
Вышеприведенный конфиг не адекватен для реального применения по ряду причин:
Как минимум:
— нету фильтров на изоляцию пользователей
— нету прописанных snmp для сбора статистики
— нету привязки модема к конкретному CPE
Еще хорошо было бы сделать:
— шейпинг канала прямо на устройстве
— учесть особенности различных дивайсов
— отрубить веб-лицо модема, пользователю там делать нечего
— грамотно построить QoS
Изначально я очень хотел написать пошаговый мануал по тому, как сделать не просто чтобы «ходили интернеты» а и по тому, как грамотно их продать конечным пользователям, собственно с примерами конфигов, готовой АСР итд. Но так как писатель из меня честно-говоря никакой — мне банально стыдно показывать свой быдлокод который к тому же довольно узкоспецифичен и в любом случае требует глубокой доводки под конкретного оператора :)
В общих чертах требования к биллингу работающему в DOCSIS сети очень просты:
— уметь считать трафик
— уметь считать деньги
— делать из посчитанных денег трафика гибкие тарифы
— гибко ограничивать пользовательскую полосу
— уметь на лету компилировать конфиги к модемам на каждого пользователя + править хосты dhcpd.
Если с первыми четырьмя пунктами все понятно – и собственно все АСР ими в основном и занимаются, то на последнем следует заострить внимание на последнем. Естественно можно выдать один конфиг на всех, а потом аутентификацию пользователя производить при помощи внутренних механизмов АСР (разношерстные авторизаторы) либо скажем методом PPtP тунелля но это я считаю просто дополнительным костылем и сознательным отказом от очень удобных возможностей предоставляемых технологией.
Думаю сейчас много-много людей скажет, что технология мертва, дорога, не актуальна и потыкают меня мордочкой в FTTB, PON, HCNA. Да я в курсе что такие есть и что например в плотнозаселенных многоэтажках намного цена/скорость порта в десятки раз дешевле с FTTB и что HCNA предоставляет по тому же коаксиалу намного более вкусные скорости при сопоставимой стоимости абонентских железок и отсутствии в необходимости покупки относительно дорогой CMTS. Если интересно могу на пальцах объяснить, почему FTTB в частном секторе это дорого, и почему там же HCNA сводится к «почти FTTB» по стоимости порта а так же почему публика пока еще не готова к PON. Опять же для применения любой пока еще живой технологии всегда есть свои мотивы от «давайте использовать существующую сеть» до «иначе будет слишком дорого и долго». Опять же выбор играть в демпинг и гоняться со скоростями домашних сетей не самый хороший вариант при вышеуказанных ТТХ и собственно козырем DOCSIS провайдера должны быть имхо сервисы предоставляемые по одному кабелю и их качество.
На данном этапе развития DOCSIS 2.0 может в полнее успешно конкурировать с ADSL а 3.0 наступает на пятки остальным как перспективная платформа для Triple Play.
Как всегда в конце статьи я использую свою слабую отмазку звучащую как:
«Да я не грамотен, я знаю. Язык не родной, в школе не учили, хотя догадываюсь это слабая отмазка. Если вы воспринимаете пропущенную запятую как личное оскорбление – приношу извинения заранее. Честно – я не хотел»
Как правило, действует ;)
Статья написана по спецзаказу журнала «Кабельщик»