ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

5 минут чтени€

“реть€ часть тут

ѕоскольку трафик в реальном времени начал передаватьс€ по сет€м с коммутацией пакетов, QoS стал серьезной проблемой. ѕередача голоса и видео полагаетс€ на то, что сеть способна быстро переносить трафик между хостами (с низкой задержкой) и с небольшими колебани€ми межпакетного разнесени€ (jitter). ƒискуссии вокруг QoS фактически начались в первые дни сети с коммутацией пакетов, но достигли высшей точки примерно в то врем€, когда рассматривалс€ ATM. Ќа самом деле, одним из главных преимуществ ATM была возможность тщательно контролировать способ, которым обрабатывались пакеты, когда они передавались по сети с коммутацией пакетов.

— провалом ATM на рынке, по€вились два направлени€ идей о приложени€х, которые требуют сильного контрол€ над jitter и delay:

  • Ёти приложени€ никогда не будут работать в сет€х с коммутацией пакетов. “акого рода приложени€ всегда должны запускатьс€ в отдельной сети.
  • Ёто просто поиск правильного набора элементов управлени€ QoS, чтобы позволить таким приложени€м работать в сет€х с коммутацией пакетов.

ќсновное, что больше всего волновало большинство провайдеров и инженеров, была голосова€ св€зь, и основной вопрос сводилс€ к следующему: можно ли обеспечить приличную голосовую св€зь по сети, также передающей большие файлы и другой "nonreal - time" трафик? Ѕыли изобретены сложные схемы, позвол€ющие классифицировать и маркировать пакеты (называемые QoS-маркировкой), чтобы сетевые устройства знали, как правильно их обрабатывать.  артографические системы были разработаны дл€ переноса этих маркировок QoS из одного типа сети в другой, и много времени и усилий было вложено в исследование механизмов массового обслуживани€-пор€дка, в котором пакеты отправл€ютс€ по интерфейсу. Ќа рис. 1 показана примерна€ диаграмма одной системы QoS, и сопоставлени€ между приложени€ми и маркировками QoS будет достаточно, чтобы проиллюстрировать сложность этих систем.

ѕланирование QoS

”величение скорости св€зи оказывают двойной эффект на обсуждение QoS:

  • Ѕолее быстрые каналы св€зи будут (это очевидно) нести больше данных. ѕоскольку любой отдельный голосовой и видеопоток становитс€ сокращающейс€ частью общего использовани€ полосы пропускани€, необходимость строго сбалансировать использование полосы пропускани€ между различными приложени€ми стала менее важной.
  • ¬рем€, необходимое дл€ перемещени€ пакета из пам€ти в провод через микросхему, уменьшаетс€ с каждым увеличением пропускной способности.

ѕо мере того, как доступна€ пропускна€ способность увеличивалась, потребность в сложных стратеги€х массового обслуживани€ дл€ противодействи€ jitter становилась все менее значимой. Ёто увеличение скорости было дополнено новыми системами массового обслуживани€, которые гораздо эффективнее управл€ют различными видами трафика, уменьша€ необходимость маркировки и обработки трафика детализированным способом.

“акое увеличение пропускной способности часто обеспечивалось переходом от медного волокна к стекловолокну. ќптоволокно не только обеспечивает большую полосу пропускани€, но и более надежную передачу данных. —пособ построени€ физических св€зей также эволюционировал, дела€ их более устойчивыми к поломкам и другим материальным проблемам. ¬торым фактором, увеличивающим доступность полосы пропускани€, стал рост »нтернета. ѕо мере того, как сети становились все более распространенными и более св€занными, отказ одного канала оказывал меньшее вли€ние на объем доступной полосы пропускани€ и на потоки трафика по сети.

ѕоскольку процессоры стали быстрее, по€вилась возможность разрабатывать системы, в которых отброшенные и задержанные пакеты будут иметь меньшее вли€ние на качество потока в реальном времени. ”величение скорости процессора также позволило использовать очень эффективные алгоритмы сжати€, уменьша€ размер каждого потока. Ќа стороне сети более быстрые процессоры означали, что control plane могла быстрее вычисл€ть набор loop-free путей через сеть, уменьша€ как пр€мые, так и косвенные последстви€ сбоев св€зи и устройств.

¬ конечном счете, хот€ QoS все еще важен, его можно значительно упростить. „етырех-шести очередей часто бывает достаточно дл€ поддержки даже самых сложных приложений. ≈сли требуетс€ больше, некоторые системы теперь могут либо проектировать потоки трафика через сеть, либо активно управл€ть очеред€ми, чтобы сбалансировать сложность управлени€ очеред€ми и поддержки приложений.


÷ентрализованный Control Plane - есть ли смысл?

¬ 1990-х годах, чтобы решить многие из предполагаемых проблем с сет€ми с коммутацией пакетов, таких как сложные плоскости управлени€ и управление QoS, исследователи начали работать над концепцией, называемой активной сетью. ќбща€ иде€ состо€ла в том, что плоскость управлени€ дл€ сети с коммутацией пакетов может и должна быть отделена от устройств пересылки, чтобы позволить сети взаимодействовать с приложени€ми, запущенными поверх нее.

Ѕазова€ концепци€ более четкого разделени€ плоскостей управлени€ и данных в сет€х с коммутацией пакетов была вновь рассмотрена при формировании рабочей группы по переадресации и разделению элементов управлени€ (ForCES) в IETF. Ёта рабоча€ группа в основном занималась созданием интерфейса, который приложени€ могли бы использовать дл€ установки пересылки информации на сетевые устройства. –абоча€ группа была в конечном итоге закрыта в 2015 году, и ее стандарты никогда не примен€лись широко.

¬ 2006 году исследователи начали эксперимент с плоскост€ми управлени€ в сет€х с коммутацией пакетов без необходимости кодировани€ модификаций на самих устройствах- особа€ проблема, поскольку большинство этих устройств продавались поставщиками как неизмен€емые устройства (или black boxes).  онечным результатом стал OpenFlow, стандартный интерфейс, который позвол€ет приложени€м устанавливать записи непосредственно в таблицу пересылки (а не в таблицу маршрутизации). »сследовательский проект был выбран в качестве основной функции несколькими поставщиками, и широкий спектр контроллеров был создан поставщиками и проектами с открытым исходным кодом. ћногие инженеры считали, что технологи€ OpenFlow позволила бы реконструировать инженерные сети за счет централизации управлени€.

¬ реальности, все будет по-иному-то, что, скорее всего, произойдет в мире сетей передачи данных: лучшие части централизованной control plane будут поглощены существующими системами, а полностью централизованна€ модель будет выброшена на обочину, оставив на своем пути измененные представлени€ о том, как control plane взаимодействует с приложени€ми и сетью в целом.