vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

#263 Одна модель адресов и маршрутизации в Интернет

Дата публикации: 14.03.2006
Количество просмотров: 8295

Отсутствие законов
не освобождает от ответственности.

Разное.

Начать придется с дополнения прошлого выпуска (о подсчете трафика с помощью NetFlow на гигабитных потоках) - небольшого отчета о испытаниях биллинга UTM5.

Декларируемый результат - на обычном PC-компьютере, далеко не запредельной конфигурации, можно принять и обсчитать данные от потока в 3 Гбит/сек. При этом сама передача NetFlow (3000 пакетов в секунду) занимает всего лишь 35 Мбит.

Большие скорости не исследовались. Максимальный трафик, обсчитываемый одним из пользователей UTM, около 100 ТБ в месяц, а это значительное меньше 3 гигабит...

Как продолжение темы можно рассматривать и следующую ссылку - томский Интернет станет платным. Местный филиал ОАО "Сибирьтелеком" собирается начать продавать свой внутригородской трафик по 5-10 копеек за мегабайт. Говорят, что "довели":
У нас есть клиенты, потребляющие свыше 500 гигабайт информации в месяц, естественно, все это внутренний бесплатный трафик.

Впрочем, волна протестов пользователей оказалась слишком крутой для менеджмента компании. Появилось опровержение, в котором говорится о планах тарифицировать только областной (а не городской) трафик. Таким образом, можно наблюдать еще одно вредное проявление "халявы" - ее очень сложно "отменить".

 


Традиционная забавная фотография. Конечно, не совсем из быта провайдеров, но все же...

Душевая кабинка Душевая кабинка

Что бы посетители не задавали вопросов, была сделана надпись "душевая кабинка" (прислал Alexey).

 


О грустном. МРК Связьинвеста начинают очередное наступление на рынок. Причем с использованием своего любимого оружия.

Вот статья Дальсвязь против нас. Пользуясь новым законодательством, телефонный монополист решил задушить альтернативных операторов коммутируемого доступа повременной оплатой звонков. Увы, Ethernet там развит слабо, а без своих кабельных коммуникаций противопоставить такому произволу по сути нечего. :-(

Есть и официальное заявление Дальсвязи по текущей ситуации. Вот примечательная цитата:
Дальсвязь не намерена идти на неоправданные риски из-за несознательности партнеров по бизнесу и оставляет за собой право на ограничение доступа к сети этих операторов до приведения в соответствие с законом договорных отношений...

Еще один срез рынка в статье журнала "Эксперт Урал" - Игра в наперстки.
Впрочем, вопрос там вспахан с хорошим замахом, но неглубоко. Все сведено лишь к IP-телефонии и дальней связи, а более серьезное структурное изменение схемы работы операторов лишь упомянуто как второстепенный фактор. Вывод отчасти верен - монополия на телефонную связь в ходе реформ заметно укрепилась. Но увы, это далеко не вся проблема, как можно видеть из ситуации с Дальсвязью.

Остается только надеяться, что перманентная политическая возня по продаже Связьинвеста будет сковывать этого монстра еще по крайней мере пару лет. Упорные попытки идти сразу в нескольких направлениях не способствуют успешной коммерции.

Читать стоит. Конечно, много декларативного, но префиксы МГ/МН получены реально, да и оптическая сеть растет не только на бумаге (готово к запуску стекло до Нижнего Новгорода). Вот только небольшим и средним операторам России от этого польза сомнительная. Ведь развивается не новый "транспортник-оптовик", а их же конкурент в борьбе за корпоративного и (уже) частного пользователя.

 


Природа не терпит пустоты. Если зарегулированный до полной неподвижности рынок традиционной телефонии оказался плоховосприимчив к новым технологиям, они найдут параллельный путь. Причем неожиданный и эффективный.

Сначала Google запустил jabber-based службу GoogleTalk с привязкой к GoogleMail. Недавно обьявил о приёме на хостинг доменов (MXs), что дает возможность размешать там корпоративную почту.

И вот GoogleTalk обучился VoIP, да еще с открытыми исходниками и протоколами своих voice-расширений. Вдобавок обещана поддержка SIP... Думаю и видео туда же подтянется со временем.

Сервис вырисовывается могучий, удобный, и дешевый. Вернее, пока вообще бесплатный. Потенциально на него могут пересесть коммерсанты и... "Мобилизованная" молодежь. Сочетание убойное - впереди уже начинает обретать реальность призрак утилизации телекомовских кабелей "как лом меди".

А главное, законодательные игры отдельных министерств перестают казаться чем-то серьезным. Так, детские шалости на фоне действительно глубоких структурных проблем. Не в этой плоскости будущее и деньги, и судя по всему не в нашей, увы, стране. Телеком не отдельный мир, он так же подвластен глобализации. Но об этом подробнее в одном из следующих обзоров, мне нужен тайм-аут на осмысление.

 


Небольшие ссылки.
Статья о arp-спуфинге. В принципе, тема не новая (#132), но повторение не помешает.

Несколько фотографий замерзших антенн. Много снега и экстрима (прислал Andrew Bogorodsky).

Алгоритмы модуляции технологий xDSL, Каналы передачи данных, Оценка скоростного потенциала ADSL по сопротивлению шлейфа и емкости пары, (прислал Кинзябулатов Рамиль).

 


Обновление в разделах

Одна модель адресов и маршрутизации в Интернет.

 

Критически о существующей модели

Современная модель маршрутизации в Интернете выросла из вполнеконкретных условий: подключенные по проводам стационарные компьютеры, принадлежащие крупным организациям (корпорациям и универистетам). Сеть росла и ширилась, возникали новые проблемы, которые решались в стилеad-hoc, архитектурное наследство накапливалось слой за слоем. Если сравнивать Интернет со зданием, то подойдёт аналогия старого замка,который достраивали и расширяли в разные эпохи. Я выделю два объекта для критики. Первый - это умножение сущностей, второй - существующая система маршрутизации.

Умножение сущностей

Умножение сущностей происходит по очень простой причине. Когда людям дают технологию со всеми её достоинствами и недостатками, люди начинают её как-то использовать. И если какой-то умник вдруг решит что-то в технологии поменять, то он обнаружит, что даже самые нелепые фичи и баги кем-то используются и кто-то на них уже "забился". Поэтому развитие чаще происходит по пути создания некоторых новых механизмов, новых сущностей поверх старых. Если мы взглянем на маршрутизацию, то мы увидим такие сущности, как само устройство, его адреса, сетки/маски, уровнем выше - например, области  OSPF, ещё уровнем выше - автономные системы.

Маршрутизация

Изначально рассчитывалось, что маршрутизация будет иметь иерархически-географический характер, по аналогии с телефонией. Но затем обнаружилось, что эта схема совсем не прогрессивна - и понеслось.

В настоящий момент используется схема с областями, дающая сублинейную сложность. Если объяснять на пальцах, то сложность маршрутизации на любой адрес (4 байта) разбита на задачу маршрутизации к соответствующей автономной системе (их ~2 байта), а затем внутри неё (оставшиеся 2 условных байта). Причём, внутри AS маршрутизация также может осуществляться между областями (OSPF, например). Т.о. система становится сложней, различных маршрутизационных таблиц больше, маршруты несколько кривей идеальных, однако каждая из маршрутизационных таблиц имеет приемлемый размер. При этом стоит заметить, что на каждом из уровней маршрутизация осуществляется алгоритмом типа Дейкстры или Форда-Беллмана. Или иерархически.

Эта схема начала активно проседать, когда маленькие провайдеры и большие клиенты начали активно повышать свою связность (например, для повышения надёжности или балансировки нагрузки) и анонсировать длинные префиксы. Маршрутизационная таблица в DFZ начала расти экспоненциально (Default Free Zone - это те, кто держат полную маршрутизационную таблицу). Некоторое время (года два) ситуацию спасала агрегация по CIDR, но затем экспоненциальный рост возобновился. А что такое экспоненциальный рост, мы учили в школе :)

Есть самые разные предложения, что с этим ростом делать. Например, D.Krioukov и др. из CAIDA предложили как-нибудь повторить трючок - объединить, например, автономки в области. Тогда всё шоколадно, две маршрутизационные таблицы в DFZ, каждая порядка байта (т.е. где-то до сотен записей). Эта затея продвигается под слоганом compact interdomain routing. К недостаткам технологии можно отнести повышение сложности системы (а соответственно, и понижение надёжности), а также тот обидный факт, что качество маршрутов несколько ухудшится.

Теоретически, удлинение составит до 3х раз в таких несмешных единицах, как AS hop (т.е. пройденные пакетом автономные системы). Практически, на scale-free топологиях, среднее удлинение оценивается Крюковым и др в 10%. Проблема также в том, что AS hop может происходить внутри одной стойки, а может - через океан. Как, впрочем, и обычный ip hop. Также стоит заметить, что при современном случайном распределении префиксов между автономками, эти префиксы всё равно придётся перечислять. Т.е. красиво и такой трюк проделать не получится.

Что же тут плохо?

На мой скромный взгляд, тут есть два базовых порока:

 

  1. Хоп в качестве метрики расстояния ненадёжен - может различаться на три-пять порядков по цене, дистанции, времени. Это влечёт необходимость ручных подкруток, исключает автоматическую агрегацию.
  2. Адреса не соответствуют топологии - возникает необходимость описывать взаимоотношение адресов и топологии сети. Адреса не соответствуют "областям" (напр, AS) - возникает необходимость описывать взаимоотношения адресов и AS. Сущности притом абсолютно виртуальные.

В следующей части я попробую нарисовать лучший Интернет - каким бы он мог бы быть, если эти пороки исправить.

 

Модель: Интернет, как океан

Необходимые предпосылки

Мера расстояния

Для разумной маршрутизации необходимо сохранить локальность, т.е. метрику расстояния. Лучше всего для этого подходит RTT. Я на досуге расчёл, что в радиусе ~150км задержки, вызванные оборудованием, нивелируют нижнюю границу, обусловленную c. На больших расстояниях - уже c сказывается. Единственный видимый мне способ использовать RTT в маршрутизации - производить замеры с маршрутизирующих устройств, т.е. подмешивать в проходящий поток свои пинги.

Если у нас есть локальность - уже маршрутизация требует O(log N), а не O(N0.5), как BGP.  А если маршрутизационная таблица имеет логарифмический размер, то трючок с делением на области (BGP, OSPF, compact routing) нам уже не нужен. При маршрутизации используем только префикс, который одновременно является идентификатором устройства (или группы устройств) и идентификатором области - а именно, области, содержащей даунлинки данного устройства. 

Адреса - лишь отражение топологии сети

Во-первых, mobilis in mobili, как говаривал капитан Немо. Все сопли относительно сложностей переадресации устройств необходимо отбросить. Устройство получает адрес от аплинка, меняется аплинк - меняется адрес устройства. Автоматически.

Во-вторых, поскольку сеть имеет топологию далеко не древообразную, каждое устройство может иметь несколько аплинков, а значит и несколько адресов. Если сейчас маршрутизацию плющит и колбасит от того, что небольшие провайдеры и большие клиенты начали мультихомиться, то у нас каждый сотик будет мультихомиться, когда пожелает - получая адреса от каждого из аплинков (вероятно, сот). В результате получается топоним, как я это называю, т.е. набор адресов каждого устройства - это ациклический ориентированный граф.

  Топоним конечного устройства, ((A:1:A,(A:2,B:1):A):1,(B:2:A,...):1) :A::,((B:2:A,...):2):B:: , представляет из себя набор IPv6-префиксов, каждый из которых достаточен для маршрутизации. Однако, поскольку разные адреса соответствуют разным маршрутам, то для участников из разных частей сети, а также в зависимости от других условий, какие-то адреса работают лучше, какие-то хуже. Единственный способ разобраться - методом проб и ошибок (т.е. статистически).

  • A:1:A:1:A::
  • A:2:A:1:A::
  • B:1:A:1:A::
  • B:2:A:1:A::
  • B:2:A:2:B::
  • ...:2:B::

Таким образом, уже необходимо проапгрейдить стек конечных устройств - чтобы они могли работать со множественными адресами и выбирать лучший. Это требует изменений на 4 уровне (напр. TCP), ip-пакет же на 3-м уровне остаётся прежним. Отчасти это перекликается с shim6, если не считать того момента, что авторы shim6 всё ещё надеются приделать это, как патч к IPv6-стеку. Поскольку один адрес - это частный случай множества адресов, возможно сохранение прозрачной совместимости с современным TCP.

Возникает вопрос, а что же будет корнем в такой системе адресации? Совершенно однозначно, это IX. Поскольку это а) точки, б) точки с очень хорошей connectivity. Это позволит нам практиковать гео-аггрегацию (см. далее).

Маршрутизация - дело каждого

Раз маршрутизационные таблицы зависят от количества всех устройств логарифмически, то такие таблицы можно поддерживать чуть ли не на каждом ip-устройстве. А что?
Впрочем, устройство может поступать крайне просто: посмотрев адрес назначения (это обязательно!), маршрутизировать пакет в сторону ближайшего общего аплинка, наподобие сегодняшнего default gw. Назовём это каноническим путём. Тогда маршрутизационная таблица по размеру вообще равна количеству аплинков устройства.

Для того, чтобы использовать peering links, т.е. такие линки, которые не вовлечены в отношения аплинк/даунлинк, разрешим устройствам обмениваться анонсами вида "данный префикс достижим через меня с таким-то RTT". Поскольку те устройства, что всё-таки держат маршрутизационные таблицы, пингуют содержащиеся в них префиксы, то таким сведениям можно доверять. По сложности такой протокол будет уступать BGP, но несколько превзойдёт ARP. Даже если такая схема даст сбой, устройство сможет это понять и откатиться к канонической маршрутизации. Автоматически.

Оценка сложности

Глобально

В этой статье я доказываю, что глобально такая схема будет иметь вычислительную сложность O(log N). Вкратце, доказательство базируется на следующем: на настоящий момент сети густо покрывают поверхность планеты, а маршруты оптимизированы и, как правило, RTT находится в диапазоне tc..10tc, подразумевая под tc кратчайшее возможное время прохождения сигнала по кратчайшей географической дистанции (по глобусу). В общем-то, нам важен тот факт, что в оптимизированной сети на дистанциях больше 100 км RTT определяется в первую очередь длиной провода.В таком случае, маршрутизатор может использовать следующую политику поддержания маршрутизационной таблицы: удалять все префиксы, которые не дают 10% выгоды в RTT относительно более общего префикса (т.е. если IPv6- префикс 000A:000B:000C::/48 примерно на том же расстоянии, что и 000A:000B::/32, то можно не заморачиваться подробностями и более длинный префикс удалить). Чем больше расстояние - тем более короткие префиксы (более крупные агрегаты) достаточны для описания картины.

Что также интересно, когда пакет "прыгает" к цели, каждый последующий маршрутизатор имеет всё более точное представление о том, где эта цель находится.

Всё это даёт нам маршрутизационную таблицу логарифмического размера при фиксированном stretch (допустимом удлинении маршрута). Например, при stretch=1,1 на расстоянии 10.000 км мы можем работать с агрегатами размером до 4000 км - т.е., по сути, помнить только направление до соответствующего IX.

В окрестности 100 км

В такой окрестности расстояние имеет второстепенное значение - важней топология сети, количество хопов, характеристики устройств. На иерархическую маршрутизацию в окрестности 100 км рассчитывать наивно. Маршрутизация по Дейкстре требует O(N) - если, конечно, не провернуть тот самый трючок с областями. Но мы от этого пытались уйти.

Жизнь станет проще, если рассматривать окрестность не как случайный/ обычный/ простой/ любой граф, а как граф со scale-free топологией. Данная топология характеризуется степенным (k) распределением степеней вершин, т.е. есть мало вершин с большой степенью (количеством связей) и много - с малой. Вершины с большой степенью называются хабы. Такая топология много где встречается - в социальных связях, половых контактах, связности аэропортов, графе ссылок WWW, связности автономных систем и отдельных маршрутизаторов. (Хотя есть модели с большим количеством измерений, напр. HOT, которые претендуют на более точное описание топологии Сети, здесь достаточно и этой.) Вопрос о сложности  маршрутизации в scale-free сети, при условии, что используется система адресации подобная описанной выше, изложен мной в этой статье. Результат следующий: для решения задачи о кратчайших путях и имя и маршрутизационная таблица должны быть сублинейны, ориентировочно имя размера O(N0.2) и таблица размера O(N0.5). Принимая количество рутеров в окрестности 100 км за 1 миллион, это ~10 и 1000 соответственно.

Устойчивость

Высказываю на правах гипотезы. Если

  • замеры происходят на порядок чаще, чем изменения и
  • изменения происходят постепенно

то система может прийти к "рыночному равновесию".

Т.е. если у нас два линка, eRTT 100ms и 102ms, мы шлём 60% через один и 40% через другой. Один линк начинает проседать (пошли дропы) - перекладываем по 5% на другой, причём временной шаг перекладывания, повторяюсь, в 10 раз больше шага замера. Вопрос во временном масштабе. Какие (микро)колебания игнорировать, а за какими (макро)колебаниями следовать. Например, изменения паттернов трафика в зависимости от времени дня/выходных/праздников - это то, к чему нужно адаптироваться. А кратковременные всплески не должны существенно повлиять на маршрутизацию. (Траффик имеет фрактальную, микроосциллированную природу.)

Последствия

Задача сети - передавать данные быстро, дёшево и без сбоев. Описанный подход к маршрутизации позволит выполнить эту задачу лучше.

Самонастройка

Устройства могут сами себя настраивать, а конструкция обладает избыточностью. Как пример следствия, устройство может само "попробовать" новый аплинк и либо оставить его, либо убрать. Общая идея: монтёр проложил провод - и оно работает. Также интересный эффект заключается в том, что подобная сеть сможет собраться из кусочков, как Терминатор. Сама собой. Также, поскольку список адресов можно произвольно пополнять/сокращать - появляется возможность transparent ip-level handoff. Т.е. на уровне ip происходит то же, что сейчас с сотовым телефоном - устройство перемещается, и постоянно остаётся на связи, но: независимо от технологии доступа. Есть рядом хот-спот - есть видеоконференцсвязь. Есть сота - доступен голос. В Пикулях - ограничимся текстом.

Получаем полный digital convergence. И чтобы этого достичь, с массой мелких устройств, необходима технология, работающая абсолютно без админов. Вообще. Администрирование должно сводится к следующему: горит красная лампочка - поднял, отправил в ремонт. Прислали - положил обратно :)

Успех цифровых фотоаппаратов и рост функционала сотовых телефонов - хорошие показатели того, к чему дело идёт.

Базовый QoS

QoS в public ip network разрешается непосредственным практическим образом - перебираем разные ip-адреса цели и смотрим, где eRTT меньше получается. Разные адреса соответствуют разным путям. (Под eRTT далее подразумевается "эффективный RTT": средний RTT за период, при этом в случае дропа время ретрансмиссии добавляется к RTT. Вообще-то, вопрос тут ещё сложней.)

Аналогично может вести себя каждый промежуточный маршрутизатор: раз он замеряет eRTT до префиксов в своей маршрутизационной таблице - он может посылать пакеты более короткими путями. Сам. С учётом переполнения каналов (когда пинги теряться начнут). Черезпакетица и jitter, в худшем случае, вымениваются на задержку. По черновой прикидке, мы получаем буфер размером порядка не более всего трафика, находящегося в полёте. (Я прикинул VHS поток в Австралию, 2Mbit/s * 0.5sec / 2, и получилось ~64 килобайта.) Т.е. некоторый практический уровень QoS осуществим в подобной публичной сети. Если у пользователя особые запросы - то нужны и особые средства, реализовывать которые "для всех" довольно дорого.

Надёжность

Надёжность достигается многократным дублированием на всех уровнях и через overprovisioning. Overprovisioning (прокладывание каналов избыточной на сегодня пропускной способности) и сегодня является самой простой и надёжной мерой обеспечения качества связи. Учитывая, что новые технологии позволяют на порядки увеличить пропускную способность уже существующих каналов, а проложить второй провод рядом с первым - дешевле, чем первый, то так оно, по-видимому, и останется (© A.Odlyzko).

Кстати, если верить RFC3439, то основные источники ненадёжности - это усложнение систем и человеческий фактор (80%). Система в нашем случае получается чрезвычайно простая (одноуровневая), а человек из процесса исключён.

Конкуренция и кооперация

Интересная особенность описываемой технологии, что при нескольких аплинках их возможности в плане покрытия и пропускной способности складываются: получается + или U, а не max, как при выборе одного ("лучшего") оператора. В частности, это позволяет побороть основное противоречие беспроводных технологий: чем выше частота, тем меньше радиус действия (и, соответственно, дороже выстроить покрытие). В нашем случае: достаточно покрыть продвинутой технологией только те участки, где она востребована. Также, не требуется многократного покрытия.

Когда же?

Заметим, что в изложенной схеме используется крайне мало абсолютно оригинальных идей. Разве что использование RTT в качестве метрики при маршрутизации если и предлагалось, то не обсуждалось широко. Самоназначение адресов - DHCP, префиксы - CIDR, множественность адресов - shim6, автоматическое вычисление методом проб и ошибок похоже на определение окна в TCP и т.д. В данном подходе сделана лишь попытка всё разобрать и собрать заново по-правильному (кайдзен).
В конце концов, сегодня и оборудование и провода - лишь стремительно дешевеющие продукты глубокой переработки песка. Чем популярней изделие, тем оно дешевле, и т.д. и т.п. Реально дефицитный ресурс - это люди. И если схема действует на 20% менее эффективно, но требует на 50% меньше людей - то это хорошая схема. Потому что грешно экономить песок и слабые электромагнитные импульсы за счёт людей. И невыгодно.

Кто знает, может и увидим подобную, а то и лучшую сеть, ещё при нашей жизни.

Зарисовки сетей.

Подготовка к переносу скобы

Разматывать П-296 начали не с того конца. В результате он перекрутился. Подняли проволокой на другом доме, через дорогу. Подъехала милиция, но к большому удивлению, даже не поинтересовались ничем.

Набивали вручную, в мороз под -10°. Но результат того стоил - прибавка 7-ми юзеров к существующим 24-ем.

Прислал Mastroyan, город Владивосток, сеть Exhaust.

 


Один из начинающих конструкторов домашних сетей из города Кишинева прислал несколько фотографий:

коробка нашего телевизионного кабельного оператора

 

Прислал Васильев Артем, Молдавия.

 


На фотографиях коммутация "системы городского оповещения" и реальная воздушка кабельного ТВ. Не времянка.

коммутация коммутация

 

Прислал Sergey Shvedov

 


Фотографии атмосферных лазерных приёмопередатчиков в городе Йошкар-Ола, возле офиса MTS.

МТС и лазерные линии связи

МТС и лазерные линии связи

Устройство направлено предположительно на самое высокое здание в округе, но разглядеть на нём второе устройство так и не удалось. Сам прибор от PAV Data Systems, вроде бы серия SkyCell, которая позиционируется производителем в основном для нужд операторов связи.

Прислал Leshij

Анонс

 

  • Зарисовки по сети Диван-ТВ (увы, в этот выпуск просто не вошло по объему);
  • Магистральная дедовщина (в осмыслении);
  • Коммуникации Тайланда, много фотографий;
  • Пример настройки сервера для терминирования PPPoE;
  • Узел в Минске, сращивание кабеля, и другие зарисовки узлов разных провайдеров. Вечная тема (много фотографий гарантировано);
  • Традиционный пункт - ссылки на интересные места Сети. Присылайте письма - они очень нужны для обзоров. Обязательно сообщайте, нужна ли Ваша подпись, ссылка, или лучше обойтись без нее;
  • В "ужастиках" - узел старейшего провайдера города Дмитров.
Долгострой:
  • Послегрозовой ремонт управляемых коммутаторов (надеюсь дойдут руки);
  • Не все Vlan'ы одинаково полезны;
  • Публичный проект сети в небольшом городе (именно они выходят на первый, авангардный план интернатизации России, в мегаполисах "уже все давно ясно"). Т.е. еженедельные отчеты о строительстве и работе "с нуля".

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/reviews/15568/odna-model-adresov-i-marshrutizatsii-v-internet.html

Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться