По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В предыдущих статьях были рассмотрены три обширные задачи, которые должна решать каждая плоскость управления для сети с коммутацией пакетов, и рассмотрен ряд решений для каждой из этих задач. Первой рассматриваемой задачей было определение топологии сети и ее доступности. Во-вторых, вычисление свободных от петель (и, в некоторых случаях, непересекающихся) путей через сеть. Последняя задача- это реакция на изменения топологии, на самом деле представляет собой набор задач, включая обнаружение и сообщение об изменениях в сети через плоскость управления.
В этой серии лекций мы объединим эти заждачи и решения путем изучения нескольких реализаций распределенных плоскостей управления, используемых для одноадресной пересылки в сетях с коммутацией пакетов. Реализации здесь выбраны не потому, что они широко используются, а потому, что они представляют собой ряд вариантов реализации среди решений, описанных в предыдущих лекциях. В каждом конкретном случае рассматривается базовая работа каждого протокола; в последующих статьях мы будем углубляться в вопросы сокрытия информации и другие более сложные темы в плоскостях управления, поэтому здесь они не рассматриваются.
Классификация плоскости управления
Плоскости управления обычно классифицируются по двум характеристикам. Во-первых, они разделяются в зависимости от того, где вычисляются loop-free пути, будь то на передающем устройстве или выключенном. Плоскости управления, в которых фактические коммутационные устройства непосредственно участвуют в расчете loop-free путей, затем разделяются на основе вида информации, которую они несут о сети. Классификация, основанная на алгоритме, используемом для вычисления loop-free путей, отсутствует, хотя это часто тесно связано с типом информации, передаваемой плоскостью управления.
В то время как централизованные плоскости управления часто связаны с несколькими (или одним, концептуально) контроллерами, собирающими информацию о достижимости и топологии от каждого коммутационного устройства, вычисляющими набор loop-free путей и загружающими полученную таблицу пересылки на коммутационные устройства, концепция гораздо менее строгая. Ц В более общем смысле централизованная плоскость управления означает просто вычисление некоторой части информации о пересылке где-нибудь, кроме фактического устройства пересылки. Это может означать отдельное устройство или набор устройств; это может означать набор процессов, запущенных на виртуальной машине; это может означать вычисление всей необходимой информации о пересылке или (возможно) большей ее части.
Плоскости распределенного управления обычно различаются тремя общими характеристиками:
Протокол, работающий на каждом устройстве и реализующий различные механизмы, необходимые для передачи информации о доступности и топологии между устройствами.
Набор алгоритмов, реализованных на каждом устройстве, используемый для вычисления набора loop-free путей к известным пунктам назначения.
Способность обнаруживать и реагировать на изменения доступности и топологии локально на каждом устройстве.
В распределенных плоскостях управления не только каждый прыжок (hop by hop) с коммутацией пакетов, но и каждый прыжок определяет набор loop-free путей для достижения любого конкретного пункта назначения локально. Плоскости распределенного управления обычно делятся на три широких класса протоколов: состояние канала, вектор расстояния и вектор пути.
В протоколах состояния канала каждое устройство объявляет состояние каждого подключенного канала, включая доступные пункты назначения и соседей, подключенных к каналу. Эта информация формирует базу данных топологии, содержащую каждое звено, каждый узел и каждый достижимый пункт назначения в сети, через который алгоритм, такой как Dijkstra или Suurballe, может быть использован для вычисления набора loop-free или непересекающихся путей. Протоколы состояния канала обычно заполняют свои базы данных, поэтому каждое устройство пересылки имеет копию, которая синхронизируется с каждым другим устройством пересылки.
В протоколах вектора расстояния каждое устройство объявляет набор расстояний до известных достижимых пунктов назначения. Эта информация о достижимости объявляется конкретным соседом, который предоставляет векторную информацию или, скорее, направление, через которое может быть достигнут пункт назначения. Протоколы вектора расстояния обычно реализуют либо алгоритм Bellman-Ford, либо алгоритм Garcia-Luna’s DUAL, либо аналогичный алгоритм для расчета маршрутов без петель в сети.
В протоколах вектора пути, путь к пункту назначения, записывается по мере того, как объявление о маршрутизации проходит через сеть, от узла к узлу. Другая информация, такая как показатели, может быть добавлена для выражения некоторой формы политики, но первичный, свободный от петель, характер каждого пути вычисляется на основе фактических путей, по которым объявления проходят через сеть.
На рисунке 1 показаны эти три типа распределенных плоскостей управления.
На рисунке 1:
В примере состояния связи- вверху каждое устройство объявляет, что оно может достичь любе друге устройство в сети. Следовательно, A объявляет достижимость B, C и D; в то же время D объявляет достижимость 2001:db8:3e8:100::/64 и C, B и A.
В примере вектора расстояния - в середине D объявляет достижимость до 2001:db8:3e8:100:: 24 до C с его локальной стоимостью, которая равна 1. C добавляет стоимость [D,C] и объявляет достижимость до 2001:db8:3e8:100::64 со стоимостью 2 до B.
В примере вектора пути - внизу D объявляет о достижимости до 2001:db8:3e8:100::/24 через себя. C получает это объявление и добавляет себя к [D,C].
Плоскости управления не всегда аккуратно вписываются в ту или иную категорию, особенно когда вы переходите к различным формам сокрытия информации. Некоторые протоколы состояния канала, например, используют принципы вектора расстояния с агрегированной информацией, а протоколы вектора пути часто используют некоторую форму расположения метрик вектора расстояния для увеличения пути при вычислении loop-free путей. Эти классификации - централизованный, вектор расстояния, состояние канала и вектор пути - важны для понимания и знакомства с миром сетевой инженерии.
Привет, коллега. Сегодня хотим сделать небольшой обзор двух продуктов компании Cisco, а именно, сервер обеспечения голосовых сообщений Cisco Unity Connection (CUC) и сервер обмена мгновенным сообщениями и доступностью абонента Cisco Unified Presence (Instant Messaging and Presence, IM&P).
Cisco Unity Connection
Данное решение компании Cisco Systems предназначено для сервиса голосовых сообщений, голосовой почты и распознавания голоса. Сервер CUC обеспечивает доступ пользователей к голосовой почте в рамках архитектуры Unified Communications. Один высокопроизводительный сервер может обеспечить взаимодействие с 20 000 пользователей. Функционал распознавания речи, который создан как для внутренних так и для внешних пользователей, позволяет управлять системой с помощью голоса. Встроенный почтовый сервер обеспечивает автоматическую отправку голосовых сообщений, а так же, предоставляется возможность прослушивать свою почту через WEB – интерфейс через интернет браузер.
Cisco Unity Connection – одно из пяти продуктов компании Cisco базирующихся на операционной системе Linux. Вся информация, такая как медиа данные, а так же статистические данные хранятся локально на сервере в БД IBM Informix. Сервер CUC поддерживает интеграцию с различными телефонными станциями, поддерживая соединение как через IP, так и через TDM. Для удобства одновременной настройки большого числа пользователей, понимает стандартный формат Comma-Separated Values (CSV). Данный файл содержит информацию о множестве пользователей, может быть создан через Microsoft Office и импортирован через консоль Unity Connection. Параллельно, поддерживается ручная настройка пользователей и синхронизация с Active Directory по протоколу Lightweight Directory Access Protocol (LDAP).
Сервер Cisco Unity Connection обеспечивает традиционный телефонный интерфейс пользователя Telephone User Interface (TUI) для взаимодействия через Dual-Tone Multi-Frequency (DTMF) протокол.
Лицензирование
Следующие лицензии на CUC предоставляется производителем:
SpeechView - данная технология распознает голосовое сообщение и отправляет его в виде текста на почтовый ящик. Распространяется в расчете 1 лицензия / 1 пользователь.
Голосовой ящик - лицензия на 1 пользовательский ящик для голоса.
Аппаратная платформа
Продукт Cisco Unity Connection может быть установлен на различных аппаратных платформах, например, HP или IBM. Рекомендуется инсталляция на сервера Cisco Convergence Server (MCS).
Cisco Unified Presence (Instant Messaging and Presence, IMP)
Данное решение компании Cisco Systems предназначено для расширения базовых статусов доступности и состояния абонента, передающихся с Cisco Unified Communications Manager (CUCM), таких как трубку поднята или снята. Продукт IMP предназначен для передачи информации о состоянии коллег и бизнес партнеров (доступен, занят и отошел), которая видна пользователю еще до звонка. Корпоративный обмен мгновенными сообщениями, Instant Messaging (IM), обеспечивает чат –группами или индивидуальными чат – сессиями отдельных пользователей.
Основная цель IM&P это сокращение времени дозвона до абонента корпоративной сети, путем обеспечения статуса доступности этого абонента. Пользователи могут самостоятельно менять статус, а так же, сообщать тип устройства через которое они доступны, например, это может быть мобильный или стационарный телефон. Сервер IM&P настраивается в связке с CUCM, который обеспечивает телефонную сигнализацию и базовый статус о доступности, такой как поднятие и снятие телефонной трубки. Основные протоколы, обеспечивающие передачу статусов пользователей, это SIP for Instant Messaging and Presence Protocol (SIMPLE) и Extensible Messaging and Presence Protocol (XMPP).
Итак, Instant Messaging and Presence предоставляет следующие конкурентные преимущества:
Корпоративный обмен мгновенными сообщениями - коммуникации сотрудников в режиме реального времени путем обмена сообщениями в чате. Решение предоставляет возможность как индивидуального, так и группового обмена мгновенными сообщениями
Архивация и хранение данных - решение предоставляет возможность сохранять листинг переписки в PostgreSQL базе данных. Это позволяет всегда вернуться к важной корпоративной переписке.
Виртуальное присутствие - удобная визуализация статуса доступности абонента делает решение максимально привлекательным для корпоративного сегмента.
Десятая часть тут.
Вы входите в комнату и кричите: «Игорь!» Ваш коллега Игорь оборачивается и начинает разговор о будущем IT-индустрии. Эта способность использовать один носитель (воздух, по которому движется ваш голос) для обращения к одному человеку, даже если многие другие люди используют этот же носитель для других разговоров в одно и то же время, в сетевой инженерии называется мультиплексированием. Более формально:
Мультиплексирование используется, чтобы позволить нескольким объектам, подключенным к сети, обмениваться данными через общую сеть.
Почему здесь используется слово объекты, а не хосты? Возвращаясь к примеру «разговор с Игорем", представьте себе, что единственный способ общения с Игорем — это общение с его ребенком-подростком, который только пишет (никогда не говорит). На самом деле Игорь-член семьи из нескольких сотен или нескольких тысяч человек, и все коммуникации для всей этой семьи должны проходить через этого одного подростка, и каждый человек в семье имеет несколько разговоров, идущих одновременно, иногда на разные темы с одним и тем же человеком. Бедный подросток должен писать очень быстро, и держать много информации в голове, например: "Игорь имеет четыре разговора с Леной", и должен держать информацию в каждом разговоре совершенно отдельно друг от друга. Это ближе к тому, как на самом деле работает сетевое мультиплексирование- рассмотрим:
К одной сети могут быть подключены миллионы (или миллиарды) хостов, и все они используют одну и ту же физическую сеть для связи друг с другом.
Каждый из этих хостов на самом деле содержит много приложений, возможно, несколько сотен, каждое из которых может связываться с любым из сотен приложений на любом другом хосте, подключенном к сети.
Каждое из этих приложений может фактически иметь несколько разговоров с любым другим приложением, запущенным на любом другом хосте в сети.
Если это начинает казаться сложным, то это потому, что так оно и есть. Вопрос, на который должен ответить эта лекция, заключается в следующем:
Как эффективно мультиплексировать хосты через компьютерную сеть?
Далее рассматриваются наиболее часто используемые решения в этом пространстве, а также некоторые интересные проблемы, связанные с этой основной проблемой, такие как multicast и anycast.
Адресация устройств и приложений
Компьютерные сети используют ряд иерархически расположенных адресов для решения этих проблем. Рисунок 1 иллюстрирует это. На рисунке 1 показаны четыре уровня адресации:
На уровне физического канала существуют адреса интерфейсов, которые позволяют двум устройствам обращаться к конкретному устройству индивидуально.
На уровне хоста существуют адреса хостов, которые позволяют двум хостам напрямую обращаться к конкретному хосту.
На уровне процесса существуют номера портов, которые в сочетании с адресом хоста позволяют двум процессам обращаться к конкретному процессу на конкретном устройстве.
На уровне диалога (разговора) набор порта источника, порта назначения, адреса источника и адреса назначения может быть объединен, чтобы однозначно идентифицировать конкретный разговор или поток.
Эта схема и объяснение кажутся очень простыми. В реальной жизни все гораздо запутаннее. В наиболее широко развернутой схеме адресации - интернет-протоколе IP отсутствуют адреса уровня хоста. Вместо этого существуют логические и физические адреса на основе каждого интерфейса.
Идентификаторы (адреса) мультиплексирования и мультиплексирование иерархически расположены друг над другом в сети.
Однако есть некоторые ситуации, в которых вы хотите отправить трафик более чем на один хост одновременно. Для этих ситуаций существуют multicast и anycast. Эти два специальных вида адресации будут рассмотрены в следующих лекциях.
О физических каналах, Broadcasts, и Failure Domains
Простая модель, показанная на рисунке 1, становится более сложной, если принять во внимание концепцию широковещательных доменов и физического подключения. Некоторые типы мультимедиа (в частности, Ethernet) разработаны таким образом, что каждое устройство, подключенное к одной и той же физической линии связи, получает каждый пакет, передаваемый на физический носитель—хосты просто игнорируют пакеты, не адресованные одному из адресов, связанных с физическим интерфейсом, подключенным к физическому проводу. В современных сетях, однако, физическая проводка Ethernet редко позволяет каждому устройству принимать пакеты любого другого устройства. Вместо этого в центре сети есть коммутатор, который блокирует передачу пакетов, не предназначенных для конкретного устройства, по физическому проводу, подключенному к этому хосту.
В этих протоколах, однако, есть явные адреса, отведенные для пакетов, которые должны передаваться каждому хосту, который обычно получал бы каждый пакет, если бы не было коммутатора, или что каждый хост должен был получать и обрабатывать (обычно это некоторая форма версия адреса все 1 или все 0). Это называется трансляцией (broadcasts). Любое устройство, которое будет принимать и обрабатывать широковещательную рассылку, отправленную устройством, называется частью широковещательной рассылки устройства. Концепция широковещательного домена традиционно тесно связана с областью сбоев, поскольку сбои в сети, влияющие на одно устройство в широковещательном домене, часто влияют на каждое устройство в широковещательном домене.
Не удивляйтесь, если вы найдете все это довольно запутанным, потому что на самом деле это довольно запутанно. Основные понятия широковещания и широковещательных доменов все еще существуют и по-прежнему важны для понимания функционирования сети, но значение этого термина может измениться или даже не применяться в некоторых ситуациях. Будьте осторожны при рассмотрении любой ситуации, чтобы убедиться, что вы действительно понимаете, как, где и, что такие широковещательные домены действительно существуют, и как конкретные технологии влияют на отношения между физической связью, адресацией и широковещательными доменами.