По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Перед тем как начать: почитайте про перераспределение между плоскостями управления в сетях.
Сетевые инженеры обычно думают, что плоскость управления выполняет самые разные задачи, от вычисления кратчайшего пути через сеть до распределения политики, используемой для пересылки пакетов. Однако идея кратчайшего пути проникает в концепцию оптимального пути. Точно так же идея политики также проникает в концепцию оптимизации сетевых ресурсов. Хотя важны и политика, и кратчайший путь, ни один из них не лежит в основе того, что делает плоскость управления. Задача плоскости управления - сначала найти набор путей без петель через сеть. Оптимизация - хорошее дополнение, но оптимизация может быть "сделана" только в контексте поиска набора путей без петель.
Таким образом, в этом разделе будет дан ответ на вопрос: как плоскость управления вычисляет пути без петель через сеть?
Этот цикл статей начнется с изучения взаимосвязи между кратчайшим или наименьшим метрическим путем и безцикловыми путями. Следующая рассматриваемая тема - свободные от циклов альтернативные пути (LFA), которые не являются лучшими путями, но все же свободны от циклов. Такие пути полезны при проектировании плоскостей управления, которые быстро переключаются с наилучшего пути на альтернативный путь без петель в случае сбоев или изменений в топологии сети. Затем обсуждаются два конкретных механизма, используемых для поиска набора безцикловых путей.
Какой путь свободен от петель?
Связь между кратчайшим путем, обычно в терминах метрик, и свободными от циклов путями довольно проста: кратчайший путь всегда свободен от циклов. Причина этой связи может быть выражена наиболее просто в терминах геометрии (или, более конкретно, теории графов, которая является специализированной областью изучения в рамках дискретной математики). Рисунок 1 используется для объяснения этого.
Какие есть пути из A, B, C и D к месту назначения?
Из A: [B, H]; [C, E, H]; [D, F, G, H]
Из B: [H]; [A, C, E, H]; [A, D, F, G, H]
Из D: [F, G, H]; [A, C, E, H]; [A, B, H]
Если каждое устройство в сети должно выбирать путь, который оно будет использовать к месту назначения независимо (без привязки на путь, выбранный любым другим устройством), можно сформировать постоянные петли. Например, A может выбрать путь [D, F, G, H], а D может выбрать путь [A, C, E, H]. Затем устройство A будет перенаправлять трафик к пункту назначения в D, а D затем перенаправит трафик к пункту назначения в A. Должно быть какое-то правило, отличное от выбора пути, реализованного алгоритмом, используемым для вычисления пути на каждом устройстве, например, выбрать самый короткий (или самый дешевый) путь. Но почему выбор кратчайшего (или самого дешевого) пути предотвращает возникновение петли? Рисунок 2 иллюстрирует это.
На рисунке 2 предполагается, что A выбирает путь [D, F, G, H] к месту назначения, а D выбирает путь через A к месту назначения. Чего D не может знать, поскольку он вычисляет путь к месту назначения, не зная, что вычислил A, так это того, что A использует путь через D сам для достижения места назначения. Как может плоскость управления избежать такого цикла? Обратите внимание на то, что стоимость пути вдоль цикла всегда должна включать стоимость цикла, а также элемент пути без петель. В этом случае путь через A с точки зрения D должен включать стоимость от D до места назначения. Следовательно, стоимость через A, с точки зрения D, всегда будет больше, чем наименьшая доступная стоимость из D. Это приводит к следующему наблюдению:
Путь с наименьшей стоимостью (или кратчайший) не может содержать путь, который проходит через вычислительный узел или, скорее, кратчайший путь всегда свободен от петель.
В этом наблюдении есть два важных момента.
Во-первых, это наблюдение не говорит о том, что пути с более высокой стоимостью являются определенно петлями, а только о том, что путь с наименьшей стоимостью не должен быть петлей. Можно расширить правило, чтобы обнаружить более широкий набор путей без петель, помимо пути с наименьшей стоимостью- они называются альтернативами без петель (Loop-Free Alternates).
Во-вторых, это наблюдение справедливо, только если каждый узел в сети имеет одинаковое представление о топологии сети. Узлы могут иметь разные представления о топологии сети по ряду причин, например:
Топология сети изменилась, и все узлы еще не были уведомлены об изменении; отсюда и микропетли.
Некоторая информация о топологии сети была удалена из базы данных топологии путем суммирования или агрегирования.
Метрики настроены так, что путь с наименьшей стоимостью несовместим с разных точек зрения.
Плоскости управления, используемые в реальных сетях, тщательно продуманы, чтобы либо обойти, либо минимизировать влияние различных устройств, имеющих разные представления о топологии сети, что потенциально может привести к зацикливанию пути. Например:
Плоскости управления тщательно настраиваются, чтобы минимизировать разницу во времени между изучением изменения топологии и изменением пересылки (или отбрасывать трафик во время изменений топологии, а не пересылать его).
При обобщении топологии или агрегировании достижимости необходимо позаботиться о сохранении информации о затратах.
"Лучшие общепринятые практики" проектирования сети поощряют использование симметричных метрик, а многие реализации затрудняют или делают невозможным настройку каналов с действительно опасными показателями, такими как нулевая стоимость канала.
Часто требуется много работы, чтобы найти, обойти или предотвратить непреднамеренное нарушение правила кратчайшего пути в реальных протоколах плоскости управления.
Почему бы не использовать список узлов?
На этом этапе должен возникнуть очевидный вопрос: почему бы просто не использовать список узлов для поиска маршрутов без петель? Например, на рисунке 1, если A вычисляет путь через D, может ли D каким-то образом получить путь, вычисленный A, обнаружить, что сам D находится на пути, и, следовательно, не использовать путь через A?
Первая проблема с этим механизмом заключается в процессе обнаружения. Как D должен узнать о пути, выбранном A, и A узнать о пути, выбранном D, не вызывая состояния гонки? Два устройства могут выбрать друг друга в качестве следующего перехода к пункту назначения в один и тот же момент, а затем информировать друг друга в один и тот же момент, в результате чего оба одновременно выбирают другой путь. Результатом может быть либо стабильный набор путей без петель, когда два устройства циклически выбирают друг друга и не имеют пути к месту назначения, либо состояние насыщения, при котором нет пути к месту назначения.
Вторая проблема с этим механизмом - резюмирование - преднамеренное удаление информации о топологии сети для уменьшения количества состояний, переносимых на уровне управления. Плоскость управления будет иметь только метрики, с которыми можно работать, везде, где обобщается топология. Следовательно, лучше использовать правило, основанное на метриках или стоимости, а не на наборе узлов, через которые проходит путь.
Обратите внимание, что обе эти проблемы решаемы. На самом деле существуют алгоритмы вектора пути, которые полагаются на список узлов для вычисления путей без петель через сеть. Хотя эти системы широко распространены, они часто считаются слишком сложными для развертывания во многих ситуациях, связанных с проектированием сетей. Следовательно, широко используются системы на основе метрик или стоимости.
Теперь почитайте материал про построение деревьев в сетях
Доброго времени суток, уважаемый читатель! Сегодня постараемся дать ответ на очень частый у системных администраторов вопрос: как выбрать правильный VoIP шлюз для подключения Asterisk? Какой нужен шлюз для конкретной конфигурации и как выбрать между FXO, FXS, BRI и PRI. Разбираться будем на примере следующих сценариев:
Подключение IP – АТС Asterisk к ТфОП
На примере ISDN линии
Подключение через аналоговую линию
Подключение аналоговых устройств к Asterisk
Подключение обычной АТС и Asterisk к ISDN и аналоговой линии одновременно
Подключение обычной АТС к SIP - провайдеру
Подключение IP – АТС Asterisk к ТфОП
В данном примере у нас есть IP – АТС Asterisk и устойчивое желание подключить ее к ТфОП (Телефонная сеть общего пользования). Разберем два случая: подключение через ISDN и через обычный аналог.
На примере ISDN линии
Для начала разберемся с терминологией. ISDN (Integrated Services Digital Network) – цифровая сеть с интеграцией услуг (позволяет использование телефон, факса, обмен данными и прочие) имеет два типа подключения: BRI и PRI:
PRI (primary rate interface) – интерфейс первичного уровня. В России и Европе представлен потоком Е1, который имеет 32 канала, в котором 30 отведены на передачу голосу, а 2 остальных это сигнальные каналы. В России Е1 так же именуется ИКМ-30 (импульсно – кодовая модуляция, 30 каналов передачи). В США данный тип называется Т1.
Для простоты, обозначим, что Е1 PRI позволяет совершать 30 одновременных вызовов.
BRI (basic rate interface) – интерфейс базовой скорости. Основное различие состоит в том, что BRI предоставляет всего 3 канала, 2 из которых предназначены для передачи данных со скоростью 64 кбит/с, а 3 канал существует для передачи сигнальной информации. Для более простого понимания, запомним, что BRI позволяет совершать 2 одновременных вызова.
На выбор того, или иного подключения может повлиять количество одновременных вызовов у вас в организации. Например, вы совершаете максимум 6 одновременных вызовов. В данном случае вам нужно 3 BRI линии, и, соответственно для подключения к ним 3 портовый BRI шлюз. В другом примере, если вы совершаете максимум 28 одновременных вызовов, то рассмотрите PRI линию и соответствующий к ней PRI шлюз.
Интерфейс ISDN образуется всегда образуется между двумя типами оборудования:
TE (Terminal Equipment) – терминальное оборудование пользователя. Это может быть компьютер, рабочая станция, телефонные аппараты, ISDN – совместимый маршрутизатор и прочее совместимое оборудование, которое может быть установлено у конечных пользователей.
NR (Network Termination) – так называемое «сетевое окончание». Это конец линии, который подключается в ISDN коммутатор, завершая канал связи.
Теперь, когда мы обладаем необходимым «бэкграундом» для понимания принципов работы ISDN, схематично изобразим подключение Asterisk к ISDN через шлюз:
Вот небольшой список неплохих E1 PRI шлюзов:
Модель
Количество портов Е1
Примерная стоимость
Dinstar MTG200-1E1
1
1000 USD
Sangoma A101 1xE1
1
1500 USD
Yeastar NeoGate TE100
1
1050 USD
Beronet 1xE1, Box
1
1700 USD
Подключение через аналоговую линию
При подключении IP – АТС Asterisk через аналоговую линию все весьма тривиально – вам нужен обычный FXO шлюз. Одна аналоговая линия позволяет совершать 1 одновременный вызов. Схема соединения приведена ниже:
Ниже небольшой список совместимых с Asterisk FXO – шлюзов:
Модель
Количество FXO портов
Примерная стоимость
Dinstar DAG1000-4O
4
180 USD
Yeastar Neogate TA410
4
200 USD
D-Link DVG-7111S
1
50 USD
Grandstream GXW-4104
4
250 USD
Подключение аналоговых устройств к Asterisk
Теперь давайте разберем вариант, когда необходимо подключить аналоговое устройство к IP – АТС Asterisk. Это может быть простой аналоговый телефон или, например, факс. В данной конфигурации вам нужен FXS шлюз. Подключение одного устройства осуществляется в один порт FXS шлюза. Схема подключения приведена ниже:
Если вы находитесь в состоянии выбора FXS – шлюза, то обратите внимание на эти модели:
Модель
Количество FXS портов
Примерная стоимость
Audiocodes MP-114, 4FXS
4
600 USD
Dinstar DAG1000-4S
4
150 USD
Grandstream HT-704
4
120 USD
Yeastar Neogate TA800
8
230 USD
Подключение обычной АТС и Asterisk к ISDN и аналоговой линии одновременно
Рассмотрим весьма интересный сценарий: в нашем корпоративном контуре существует обычная офисная АТС и IP –АТС на базе Asterisk. К ТфОП они подключены через ISDN линию по интерфейсу E1 PRI.
В данном случае необходимо осуществить подключение обычной АТС по Е1 потоку до PRI шлюза, а так же, подключить IP – АТС по протоколу SIP к этому же шлюзу. Изобразим наглядно на схеме:
Подходящие для этой конфигурации модели:
Модель
Количество E1 портов
Примерная стоимость
Dinstar MTG200-2E1
2
1500 USD
Beronet 4xE1, Box
4
4300 USD
Теперь взглянем на подключение обычной АТС и IP – АТС Asterisk через аналог. Нам понадобится шлюз, оснащенный FXS и FXO портами. Учтите, что аналоговая линия позволяет совершать только 1 одновременный вызов, поэтому, выберите шлюз с достаточном количеством портов. Схема работы будет следующая:
Ну и конечно оборудование:
Модель
Количество FXO портов
Количество FXS портов
Примерная стоимость
Audiocodes MP-114, 2FXO/2FXS
2
2
650 USD
Dinstar DAG1000-4S4O
4
4
300 USD
Dinstar DAG2000-8S8O
8
8
500 USD
Подключение обычной АТС к SIP - провайдеру
Итак, осталось с разобраться с подключением обычной офисной АТС к SIP – провайдеру. В данном случае мы будем выбирать лишь как подключить АТС к шлюзу: через ISDN(PRI или BRI) или через аналог. За шлюзом у нас будет осуществляться подключение через сеть интернет по протоколу SIP. Соответственно, нужно также принять решение, будет это PRI – шлюз, или FXS – шлюз. Схема подключения АТС к SIP провайдеру через Е1 поток приведена ниже:
И соответственно схема для подключения АТС через аналог до шлюза:
Web real-time communication (WebRTC) стандарт, который появился совсем недавно и нацелен на осуществление общения в реальном времени с помощью веб-браузера с использованием одно ранговой сети.
Проект WebRTC является открытым и его целью является позволить браузерам нативно поддерживать пиринговую передачу данных в реальном времени.
В настоящее время много веб-сервисов используют RTC (связь в режиме реального времени), но при этом требуется установка приложений или специальных плагинов. К примеру – Skype, Facebook (так же работает через Skype) и Google Hangouts (использует плагин Google Talk). Установка и обновление плагинов может быть достаточно трудоёмким и нудным процессом, после которого могут появляться новые ошибки. С этой точки зрения технология WebRTC действительно привносит множество новшеств, таких как:
Нет необходимости в лицензировании
Интеграция являет собой процесс с использованием стандартных Web API
Отсутствие проприетарных плагинов
Нет необходимости в скачивании и установке чего-либо, достаточно просто зайти на веб-страницу.
Целями данной технологии являются, главным образом – минимум трудозатрат при связи, поддержка большинства браузеров, поддержка популярных в данный момент сервисов для голосовой или видеосвязи – Skype, WhatsApp и т.д. Главное – уменьшение капитальных затрат и повышение эффективности связи при использовании данной разработки.
Основные моменты
До первой коммуникации браузеры «не знают» о существовании друг друга
JavaScript управляет процессом установки соединения через сервер
Потоки медиа-данных используют кратчайшие пути с целью уменьшения задержки. На схеме ниже изображен процесс соединения абонентов:
Для веб-приложения WebRTC необходима следующая информация:
Получение доступа к потоковой передачи голоса иили видео данных
Получение сетевой информации – сетевой адрес, порт и обмен данной информацией с другими пирами
Синхронизация сигнальной информации для открытия и закрытия сессий, выявления ошибок
Обмен информацией о совместимости таких параметров как: тип браузера, разрешение и тип кодека
Соединение входящего и исходящего потока медиа-данных
Что касается сигнализации при использовании данной технологии, первоначальной идеей было использовать SDP (Session Description Protocol), однако данный подход выявил несколько неразрешимых проблем. IETF принял решение стандартизировать протокол JSEP (Javascript Session Establishment Protocol), что дословно переводится как протокол открытия сессии с помощью Javascript. JSEP предоставляет интерфейс для приложения, позволяющий оперировать локальными и удаленными описаниями сессий. Подход с использованием данного протокола делегирует ответственность по управлению состоянием сигнализации исключительно приложению.
Что же с точки зрения безопасности?
Есть несколько путей, которыми может быть скомпрометировано приложение или плагин RTC:
Незашифрованные медиа-данные могут быть перехвачены между абонентами или между абонентом и сервером
Приложение может записывать звонки и распространять их без ведома пользователя
Вирусы могут установлены вместе с приложением или плагином при установке из неблагонадежного источника
В технологии WebRTC было добавлено несколько функций, которые позволяют избежать вышеописанного:
Реализации WebRTC используют безопасные протоколы, такие как DTLS и SRTP
Шифрование обязательно для всех компонентов WebRTC, включая сигнальные механизмы.
WebRTC не является плагином или отдельной программой – всего компоненты запускаются в браузере, причем не являясь отдельным процессом. Компоненты WebRTC обновляются при обновлении браузера.
Конечно, вышеописанное справедливо только при использовании поддерживаемых браузеров и соблюдении обычных правил безопасности в интернете.
Преграды для быстрого развития
Необходимость наличия сервера для осуществления четырех задач:
Поиск пользователей
Сигнализация
Механизмы прохождения сигнальной и медиа информации через NAT
Механизмы обеспечения прохождения информации через межсетевой экран
Отсутствие нативных приложений и SDK – WebRTC технология для связи абонентов через браузер, однако нет SDK, позволяющего разработать нативное приложение для IOS и Android
Невозможность конференций – благодаря своей пиринговой натуре (peer-to-peer), WebRTC является чрезвычайно легко масштабируемой технологией, но при этом отсутствует необходимый инструментарий для организации аудио и видеоконференций.
Выводы
Стандартизация различных API для WebRTC может снизить цены на связь и позволит использовать WebRTC во многих индустриях – телекоммуникационной, игровой, новостной и так далее. Кроме того, можно с уверенностью сказать, что WebRTC окажет сильное влияние на Интернет в общем – разработки веб-приложений с открытым кодом, на рост совместимости между браузерами и т.д