Эволюция пиринга
Алексанр ИльинИнтернет развивается органически. Не существует общего плана развития Сети, центрального управляющего пункта. Даже протоколы, используемые в Интернете, не являются обязательными, а лишь итогом консенсуса, достигнутого техническим сообществом. В Интернете отсутствует сквозная гарантия качества и маршрута, по которому будет передаваться трафик из точки А в точку Б. И тем не менее, Интернет обеспечивает глобальную связность, открывая все новые возможности и приложения. В основе этого чуда лежит взаимодействие между независимыми операторами по обмену трафиком – так называемый пиринг. О его прошлом, настоящем и будущем я поговорю в этой статье.
Интернет развивается органически. Не существует общего плана развития Сети, центрального управ ляющего пункта. Даже протоколы, используемыев Интернете, не являются обязательными, а лишь итогом консенсуса, достигнутого техническим сообществом.
В Интернете отсутствует сквозная гарантия качества и маршрута, по которому будет передаваться трафик из точки А в точку Б. И тем не менее, Интернет обеспечивает глобальную связность, открывая все новые возможности и приложения. В основе этого чуда лежит взаимодействие между независимыми операторами по обмену трафиком – так называемый пиринг. О его прошлом, настоящем и будущем я поговорю в этой статье.
Немного истории
Предоставление возможности пирингового взаимодействия на Московской точке обмена трафиком появилось как альтернатива дорогому и неэффективному (на тот момент) IP-транзиту. В начале 1990-х международный транзит практически отсутствовал. У крупнейших на то время сетей «Релкома» и «Демоса», например, это были каналы, не превышающие 1 Мбит/с. Рост трафика и желание максимально сократить издержки дали толчок к появлению точки обмена трафиком. При этом было крайне важно определить нейтральную организационную структуру для управления этой точкой, чтобы были максимально учтены интересы всех участников, подписавших первое соглашение о точке обмена трафиком. Таким связующим звеном коллегиально выбрали Российский НИИ развития общественных сетей (РосНИИРОС), и уже в 1995 году был установлен первый коммутатор в Москве на площадке ММТС-9 (М9), способный «переварить» стыки с операторами на скоростях 10 Мбит/с.
По тем временам это казалось более чем достаточно.
Однако с момента появления точки обмена трафиком стало ясно, что организация качественного межоператорского обмена является прежде всего технической задачей. Поначалу это даже выглядело как закрытый клуб по интересам (некоторые международные точки обмена трафиком до сих пор сохраняют похожую модель), ведь чтобы попасть на точку обмена трафиком, было важно не только наличие автономной системы, но и рекомендации как минимум трех участников на вступление нового члена «клуба». Поскольку решение принималось, как правило, на уровне технического директора компании, то по замыслу организаторов, это должно было обеспечить отбор только тех участников, которые имели достаточно высокую техническую квалификацию.
Одновременно с развитием взаимного обмена трафиком велась работа по активному поиску оптимальный среды передачи данных. С этой целью применялись самые разнообразные технологии. Например, в некоторых городах обмен трафиком обеспечивался на основе технологии Frame-Relay, а в Москве помимо устоявшегося Ethernet пытались применить даже решение на базе теперь уже подзабытого ATM (Asynchronous Transfer Mode). «Клуб» рос и развивался, первых участников было так немного, что они знали друг друга буквально поименно и никому не составляло особого труда настроить пиринг между своими сетями. Однако с появлением каждого нового игрока на арене площадки обмена трафиком становилось понятно, что сложность настройки растет, да и вероятность ошибки тоже. Список участников существенно вырос и входить в «клуб» для новых игроков становилось все проще, поэтому правило трех рекомендаций вскоре отменили совсем. Однако технически становилось понятно, что простого межоператорского взаимодействия уже мало, нужно было быстрее вырабатывать правила и систематизировать эту систему. В то время отличие нашей Московской точки обмена трафиком от соответствующих международных систем было существенным. Международная сеть была построена на основе крупных мировых операторов, так называемых Tier1 (ru.wikipedia.org/wiki/Tier-1-операторы), предоставляющих глобальную
связность, что существенно отличалось от России, где на тот момент этих операторов не было. У нас росло количество небольших и средних сетей, которые хотели сэкономить на международной канальной емкости и активно вступали в «клуб» MSK-IX, в то время как в Европе крупнейшие точки росли на основе консолидации трафика, а не по количеству участников.
Сервер маршрутов
Разные подходы к формированию точек обмена порождали разные технические требования и методы решения задач. В частности, на MSK-IX появился инструмент Сервер маршрутов (Route Server) – одна из самых первых реализаций среди точек обмена трафиком. Основной его задачей на этапе запуска было минимизировать количество пиринговых попарных взаимодействий «каждый с каждым» и упростить настройки маршрутизации между всеми участниками. Эта система позволяла передавать маршруты с применением транзитного звена – «арбитра», в то время как основной трафик продолжал передаваться напрямую между участниками. Это существенно сократило сроки переконфигурации при любых изменениях состава участников в точке обмена и позволило быстро включаться новым сетям, ведь теперь не нужно было разыскивать всех своих коллег по пирингу и вести переговоры с каждым из них в отдельности.
Отметим, что модель Route Server оказалась настолько эффективна, что в какой-то момент она стала играть решающую роль в пиринговом обмене. Безусловно, требования к ее надежности были очень высоки, поэтому нами было запущено сразу два таких устройства в разных ЦОДах. С каждым годом по мере развития новых сетей все больше игроков рынка осознавали необходимость резервирования инфраструктуры. В то время активно появлялись запросы на создание резервных стыков с IX. Это было обусловлено сравнительно более низкой надежностью линий связи в отличие от оборудования, а кроме того, маршрутизаторы стоили немалых денег и, пытаясь сэкономить, участники MSK-IX старались зарезервировать хотя бы линии связи. Это привело тогда к очередной насущной технической задаче – необходимости выделения второй IP-сети на платформе IX, ведь один маршрутизатор участника не позволял сделать сразу два стыка с единым пространством MSK-IX (нельзя было применить IP-адреса из одной сети на разных портах маршрутизатора). Особую роль в развитии услуг резервирования в то время сыграл также знаменитый Московский «блэкаут» (25 мая 2005 года), обесточивший половину Москвы, когда частичная связность сохранилась только для тех сетей-участников MSK-IX, кто своевременно озаботился соответствующим резервом.
Существующая на тот момент модель системы Route Server добавляла свою автономную систему в маршрут BGP и со временем стала казаться не очень удобной. Участникам уже было недостаточно просто установить обмен маршрутами, но и хотелось видеть максимально короткий маршрут до своего соседа, исключив необходимость в прямых пирингах. Вообще борьба за «лучший» маршрут развернулась нешуточная, каждая сеть хотела развернуть трафик клиентов именно на себя и оттянуть тем самым трафик от других участников. В таких условиях формулировались и развивались наши правила и технические требования услуги. Совместно с разработчиками нам удалось модернизировать систему Route Server и научиться убирать «лишнюю» автономную систему из пути маршрутизации. Route Server по сути стал прозрачным, что позволило нам выйти на новый уровень взаимодействия, создав для участников полную иллюзию прямого стыка друг с другом. Route Server уже полноценно работал в роли арбитра, помогая не только наладить пиринг, но и отслеживал и блокировал возможные ошибки в построении фильтров операторов (проверяя корректность маршрутов по IRR базам данных). Тут, кстати, тоже было наше отличие от зарубежных точек обмена трафиком. Там Route Server появился как вспомогательный инструмент и отдавал все маршруты, которые ему транслировали участники, без фильтрации, «as is». К сожалению, весьма распространенной была картина, когда администратор сети недолго думая настраивал BGP по базовой литературе (одной из самых лучших книг по протоколу BGP была книга Sam Halabi, Internet Routing Architectures,
максимально просто и без фильтров. Это приводило к взаимной передаче маршрутов от одного участника другому, и лишь бдительное «око» Route Server позволяло отловить подобную ситуацию еще на самом раннем этапе, что помогло нам с годами и набранным опытом выработать доверие к этому инструменту.
Кто бросил валенок на пульт?
Однако одним лишь сервером маршрутов вопросы пиринга не ограничивались, и перед нами регулярно вставали новые интересные задачи. С ростом количества участников наша платформа все больше выступала в роли агрессивной среды передачи данных. Это было обусловлено тем, что обмен трафиком осуществлялся в одной IP-сети, где каждый участник подключался своим оборудованием, зачастую со своими настройками и нестандартными параметрами. Нам требовались новые подходы к контролю нежелательного трафика с целью поддержания стабильности.
С точки зрения производителей (вендоров) оборудования, мы представляли нечто среднее между ЦОДом и корпоративной сетью со множеством участников. Следует отметить, что яркое отличие IX от других проектов заключается в том, что до конца неизвестно, что прячется за портом участника. Это может быть как порт роутера, так и целая сетевая инфраструктура с разнородным оборудованием. Действия одного участника могли в мгновение разрушить пиринг на всей сети. Сеть стала попадать под «штормы», которые порождались самими участниками. Ряд нарушений касался и самой IP-сети IX, которую нельзя анонсировать «в мир». Знаменитая шутка тех лет – «Кто сегодня бросил валенок на пульт?» – именно об этом нарушении.
Схожие задачи вставали и перед зарубежными крупнейшими точками обмена трафиком. Все это подталкивало сообщество к консолидации и обмену опытом. Возникла ассоциация Euro-IX, объединившая деятельность точек обмена трафиком и позволившая оперативно решать целый ряд совместных задач. В результате этой совместной активности, например, появился список требований к вендорам, и они обратили, наконец, внимание на точки обмена. Стали появляться различные механизмы защиты инфраструктуры, которые снимали растущее давление со стороны новых ошибок участников и защищали сеть.
Технологии пирингового обмена не стояли на месте. Участникам хотелось эффективнее управлять своими маршрутами для получения экономической выгоды. Начались различные пиринговые войны и разрывы пирингов, нацеленные на попытки заработать операторами, имеющими значимое присутствие на точке обмена. Появлялись и множились специфические задачи у контент-операторов, требовалась все большая гибкость управления маршрутами. Разработчики придумали, как строить индивидуальные BGP-таблицы Route Server для каждого участника с учетом его потребностей. Так появился полезный функционал MultiRIB для Route Server. Для управления таблицей весьма активно применялись управляющие BGP community.
Стало ясно, что без возможности оперативного анализа таблиц работать неудобно, и появился инструмент Looking Glass. Теперь уже многое можно было увидеть быстро, оперативно. В случае проблем со связностью оператору успешно удавалось самому принимать решение. Свод наших технических правил продолжал пополняться на основе анализа очередных случаев из практики и опыта инженеров. С ростом количества сетей, участвующих в пиринге, росла и сложность возникающих ошибок.
Например, мы сталкивались с блокировками части трафика на выдаваемые маршруты в сторону RS. Это приводило к «черным дырам» в прохождении трафика и негативно сказывалось на пиринге. Безусловно, инструменты, такие как BGP community, позволяли это исправлять, хотя зачастую требовалось немало времени для выяснения причин.
Стандартные средства сетевой диагностики не позволяли быстро выявлять эти ошибки, поскольку они были специфичны для конкретной сети определенного оператора. Рост числа участников стал также приводить к очень частым и типичным ошибкам, таким как «забывчивость» системных администраторов передавать маршруты в сторону IX и ошибками в настройках при смене оборудования. Мы продолжали искать способы выхода из этих ситуаций и повышения качества пиринга. В конечном итоге удалось реализовать целую систему контроля подобных ситуаций с уведомлениями клиентов. Была поставлена задача балансировать на разумном уровне количества уведомлений, чтобы, с одной стороны, не надоедать системным администраторам, а с другой, напомнить им о необходимости исправления ошибок. Таким образом, у нас появилась система уведомлений об ошибках сетевых администраторов, куда впоследствии добавились ошибки на линиях связи, проблемы с фильтрами и другие. Мы придумали весьма наглядную систему светофора (рис. 1). Каждый участник мог видеть не только свой статус подключения к Route Server, но и статус всех соседей по пирингу, причем в яркой наглядной форме («зеленый», «желтый», «красный»), что безусловно многим стало помогать при поиске истинных причин проблем пиринга.
Развитие пиринговых платформ
Семимильными шагами шло не только развитие московской платформы обмена трафиком, но и других региональных точек обмена. В нашей статистике мы фиксировали рост трафика свыше 200% в год, что существенно влияло на рост всей сетевой инфраструктуры. В начале 2000-х годов стартовал проект создания сетей обмена трафиком от Москвы до Владивостока на базе РосНИИРОС.
Однако возникли достаточно большие сложности по внедрению стабильных организационно-технических решений в городах. Было проблематично найти площадки, отвечающие требованиям надежности, доступности для участников и нейтральности по отношению к игрокам рынка. Точки обмена трафиком в первую очередь шли за рынком и вставали на тех площадках, где было возможно объединить максимальное число участников. Однако помимо физического присутствия на площадке требовалось немало работы на этапе взаимодействия с операторами. Нужно было донести до потенциальных участников преимущества модели обмена трафиком и объяснить специфику работы IX а. Поначалу это давалось нелегко – и тут внесли свою активную лепту растущие контент-проекты. Эти участники особенно остро ощущали необходимость продвижения ближе к конечному пользователю и наглядно показывали выгоду от прямого пирингового взаимодействия через IX по сравнению с транзитом.
Рост количества точек обмена трафиком в общемировом пространстве и конкуренция на этом поле вынудили искать новые модели поведения и схемы сети в рамках новых проектов. Одной из таких идей явилась попытка изменить подход к нейтральности точек обмена трафиком, например, разделить участников по какому-либо принципу и компенсировать стоимость сетевой инфраструктуры одних за счет других. Таким образом, появились «контентные» точки обмена трафиком, где предоставлялись максимально удобные условия для поставщиков контента и предпринимались попытки скомпенсировать расходы на инфраструктуру за счет стоимости услуг, предоставляемых потребителям контента.
Интернет-сообщество в определенный момент стало осознавать явную выгоду проектов, объединяемых общей идеей пиринга между сетями, и уже никому не требовалось объяснять преимущества межсетевого обмена трафиком. Это в свою очередь послужило поводом создания еще одной модели, названной PIPEX (от «pipe» – труба) или IXN (Internet Exchange Network). Идея в первую очередь заключалась в том, чтобы выйти за пределы классической модели и соединить географически разделенные сетевые сегменты в единое пространство, сохранив тем не менее название «точка обмена трафиком». Преимущества данной модели выглядят очевидно – не нужно никому объяснять, что такое обмен трафиком, нет необходимости предоставлять участникам полный IP-транзит, а подключение каждого нового города увеличивает размерность сети и расширяет ее географию. Данный подход формирует нечто среднее между классической точкой обмена трафиком и провайдером IP-транзита, хотя по сути своей является упрощенной моделью IP-транзита с неполной связностью, за меньшие (нежели чем транзит) деньги. Для реализации модели потребовалось внедрить прозрачную сетевую инфраструктуру с точки зрения протокола классической маршрутизации BGP4, что стало возможно благодаря наличию функционала «прозрачный Route Server» у большинства крупных вендоров. Это позволило не только построить географически распределенную сеть, но и уйти от broadcast-доменов, включающих все сетевое оборудование, а также применить обычные маршрутизаторы для реализации проекта. Однако, как говорится, дьявол кроется в деталях. Хорошо известно, что отработанный за многие годы протокол BGP4 хотя и не лишен ряда недостатков, но показывает существенную стабильность и устойчивость для организации сетевого взаимодействия. В данном случае в проектах, по сути, использовался «поломанный» BGP, в результате чего пострадал целый ряд сетей, для которых маршрутизация строилась неоптимальным образом, и самое главное, что они были не в силах на это повлиять. У сетей, заимодействующих с PIPEX, фактически стало меньше возможностей влиять на выбор сетевого маршрута, так как длина маршрута сократилась и зачастую стали выбираться неоптимальные пути. Очень сильно участники PIPEX зависели от каналов – связующих звеньев системы. В отличие от классической модели, они имели большую длину, что в условиях отсутствия качественной канальной емкости часто приводило к потерям трафика, а также задержке и её вариации в передаче данных. В качестве примера реальной проблемы можно привести забавную историю про взаимодействие двух участников IX в Екатеринбурге через Амстердам, которое обнаружилось не сразу, так как один из PIPEXов выдал маршрут с одной классической точки обмена трафиком на другую. К сожалению, подобные проекты, помимо некорректного взаимодействия
между сетями, стали приводить к еще более необычным эффектам, таким как асимметричность прохождения маршрутов и связанные с этим возможные блокировки на стороне некоторых операторов. В то же время «классические» точки обмена трафиком тоже расширяли географию, но за счет внедрения схем с привлечением партнеров и расширением возможной территории подключения. Это позволяло операторам тонко управлять своим сетевым взаимодействием, более детально относиться к качеству взаимодействия и давало свободу действия участникам, подключенным географически удаленно на конкурентном рынке.
Инструментарий
Развитие платформы точек обмена трафиком находится в постоянном движении. Модель протокола BGP4, активно применяемая для межоператорского обмена, постоянно обрастает все более новыми возможностями. Об этом регулярно идут дискуссии на IETF, где сообщество ищет реализацию новых идей и усовершенствований. Увы, в последние годы широкое развитие сетей при одновременном отставании учебного процесса привело к снижению качества знаний сетевых специалистов, допущенных к управлению глобальной маршрутизацией. Это сказалось, в том числе, и на модели потребления услуг точек обмена трафиком. Зачастую участник сети просто хочет, чтобы все работало сразу и при его минимальном участии. Понимая, что это – объективная реальность, мы попытались сделать среду работы системного администратора максимально комфортной. Для этого мы в числе первых внедрили усовершенствованный механизм Looking Glass на Route Server, который позволяет не только видеть отвергаемые сетевые маршруты участника, но и самостоятельно анализирует причины и подробно расписывает ошибки по каждому отвергаемому маршруту. Помимо этого возможна отсылка автоматизированных уведомлений участнику о замеченных критичных ошибках. Интерфейс этого инструментария показан на рис. 2.
Уязвимый BGP
Отдельно хотелось бы отметить целый ряд проблем, обобщающихся терминами BGP Route Leak и BGP Hijacking. По сути, это целый комплекс ошибок и упущений настроек протокола, приводящих к самым тяжелым последствиям.
Route Leak заключается в том, что один из участников ошибочно (как правило, без всякого умысла) выдает маршруты на «чужие» сети. Согласно правилам взаимодействия, каждый участник должен анонсировать на точке обмена трафиком только свои сети и сети своих клиентов. Нарушение этого принципа приводит к тому, что сеть из равноправного пира превращается в провайдера транзита, вовлекая в передачу транзитного трафика и саму точку обмена трафиком. Результатом может быть изменение времени отклика сетевых ресурсов, увеличение задержки и потеря трафика. Негативный эффект зачастую выходит за рамки IXP и может поразить систему маршрутизации в глобальном масштабе.
Нами отдельно были внедрены механизмы борьбы с этими неприятными явлениями. С целью защиты от возможных ошибок на сети MSK-IX применяются глубокие механизмы фильтрации, позволяющие анализировать базы данных IRR (Internet Routing Registry) и строить сетевые фильтры по IP-сетям и автономным системам для каждого участника. Мы контролируем дополнительно количество анонсируемых маршрутов каждым участником, фиксируем граничные значения взаимодействия и общей таблицы в целом и оперативно сигнализируем в случае существенного изменения.
BGP Hijacking – значительно более разрушительная ошибка маршрутизации. В результате действия оператора создается новый маршрут в таблице маршрутизации с измененным атрибутом Origin. Как правило, использование этого маршрута приводит к блокировке передающихся данных и фактически – к нарушению сетевого взаимодействия для пострадавших сетей. В последнее время эта ошибка стала все чаще возникать в результате внедрения механизмов фильтрации контента или же организации защиты от DDoS-атак. К счастью, вовремя появились механизмы RPKI, позволяющие проводить проверку («валидацию») подобных маршрутов и избегать возникающих вследствие этого проблем, однако внедрение этих механизмов требует серьезных усилий у валидирующего оператора и поддержки компонентов системы валидации различными производителями оборудования, так что этот этап еще впереди.
Создание «прозрачной» модели передачи маршрутной информации в BGP производителями оборудования изначально было нацелено на задачи создания Route Server и аналогичные проекты. Однако простота модификации BGP-маршрутов стала создавать потенциальную уязвимость для стабильности. Появилась угроза изменения атрибута AS_PATH маршрута с сохранением ASN сети, являющейся его источником. Изначально идея существования атрибута AS_PATH в BGP была нацелена на защиту от петель маршрутизации. Именно поэтому маршрутизатор не принимает от внешней сети маршруты, прошедшие через собственную автономную систему. «Прозрачная» модель BGP на распределенной инфраструктуре, модифицируя AS_PATH и убирая собственную AS из него, несет существенную угрозу маршрутных петель.
К сожалению, до сих пор отсутствует защита от изменений и валидация AS_PATH, хотя регулярно предпринимаются попытки эту ситуацию изменить. Например, в 2004 году компания Cisco вносила в IETF Internet Draft с описанием механизма Secure Origin BGP (soBGP). Суть драфта заключалась в том, чтобы помимо валидации с помощью цифровых подписей автономных систем внедрить валидацию маршрута с помощью построения сетевого графа связности. Предложенный авторами механизм валидации, по сути, предлагал простой алгоритм, где две автономные системы описывали свое взаимодействие друг с другом – и его можно было проверить с помощью цифровой подписи. Если на пути следования между ними появлялась третья автономная система, у которой такой подписи не было, то этому маршруту можно было снизить приоритет или же отбросить. Однако в то время подобные изменения казались слишком сложными, требующими дополнительной памяти и ресурсов маршрутизаторов, поэтому дальше BGP-драфта дело не пошло. Одну из идей, способную частично локализовать проблему утечки маршрутов, предложили коллеги из компании Qrator. Суть предлагаемого метода заключается в том, чтобы прописать характер взаимодействия автономных систем на уровне настройки BGP, разбив их на три типа: клиент/провайдер/пиринг. Таким образом, необходимо, чтобы клиент не принимал маршрут от клиента, на пиринге были только пиринги и т.д. Похожая идея нашла реализацию в виде очередного
RFC8212. В результате анализа ошибок (утечек) маршрутов последнего времени было обнаружено, что они могут возникать в момент первичной настройки (перенастройки) оборудования, когда участник просто забывает прописать фильтры протокола.
Предлагаемый механизм не допускает приема и передачи маршрутов без настроенных на оборудовании фильтров и отчасти помог бы уберечь от ошибок конфигурации такого рода.
На последней конференции NANOG71 в Сан-Хосе в 2017 году Cisco представила свой доклад на тему борьбы с утечкой маршрутов. Суть предлагаемого метода заключается в том, чтобы проводить маркировку с помощью механизма BGP community и последующую валидацию маршрутов на пути следования.
Очередная идея защиты атрибута AS_PATH была недавно стандартизована в IETF. Расширения протокола BGP под общим названием BGPSEC документированы в 4 RFC (www.rfc-editor.org/info/rfc8205, www.rfc-editor.org/info/rfc8206, www.rfc-editor.org/info/rfc8207, www.rfc-editor.org/info/rfc8208). Суть решения заключается в выстраивании цепочки доверия всего маршрута на пути его следования от источника к получателю и позволяет не только валидировать origin маршрута, но и AS_PATH. В перечисленных RFC подробно описан механизм передачи отдельного атрибута с цифровой подписью. Однако очень часто предлагаемые механизмы защиты наталкиваются на серьезное препятствие в виде уже годами работающих алгоритмов и оборудования, которое не в состоянии поддерживать подобный функционал.
Более того, внедрение новых механизмов криптографии в основу сети – ее основной мозг (маршрутизатор) – может сказаться критическим образом на выделяемых ресурсах и потребует существенной перестройки всей глобальной сетевой инфраструктуры, что вряд ли реализуемо без веских на то причин, поскольку связано с очень серьезными трудозатратами.
Взгляд в будущее
Активно продолжается внедрение механизмов, нацеленных на оптимизацию времени сходимости протокола BGP. С этой целью многими точками обмена уже давно и успешно применяется протокол BFD, позволяющий оперативно реагировать на изменение в физической инфраструктуре сети.
Рабочие группы IETF продолжают работу над стандартами и ищут применение все новым глобальным идеям, в том числе, и в механизмах сетевой сигнализации. Есть целый набор нововведений, касающийся задач минимизации обрывов связи в результате подготовки и проведения плановых работ на сети. Не так давно, в июле этого года, в Лондоне ассоциацией Euro-IX проводился Route Server Workshop, где, в том числе, велась работа над стандартизацией набора управляющих BGP community на всех доступных точках обмена трафиком. Это достаточно важно во время консолидации платформ обмена трафиком и в связи с наличием ряда международных проектов сразу на нескольких глобальных точках обмена трафиком.
В заключение хотелось бы отметить, что экосистема точек обмена трафиком – это постоянно растущий организм, который активно взаимодействует с глобальной интернет-средой, изменяя ее и, в свою очередь, изменяясь сам. Разрабатываемые и применяемые на точках обмена трафиком инструментарии и методики вносят существенный вклад в развитие общемирового пирингового обмена.
Ну а впереди на техническом фронте уже просматривается эпоха автоматизации и упрощения сложных процессов, что усилит интерес к использованию подобных проектов большинством участников рынка.