Мини-Сервер своими руками - это просто! - IP телефония /books/ip-telephony/72-ip5 Fri, 25 Jun 2021 01:39:42 +0300 Joomla! - Open Source Content Management ru-ru singlwolf@mini-server.ru (Мини-Сервер) 5.13. Организационные аспекты обеспечения параметров качества IP-телефонии - Часть 2 /books/ip-telephony/72-ip5/1079-5-13-organizacionnye-aspekty-obespecheniya-parametrov-kachestva-ip-telefonii-chast-2 /books/ip-telephony/72-ip5/1079-5-13-organizacionnye-aspekty-obespecheniya-parametrov-kachestva-ip-telefonii-chast-2 Заказчики должны иметь способ мониторинга реального уровня QoS. Это может де­латься посредством аудита журналов сетевых ресурсов. Сервис-провайдеры также должны вести учет, чтобы быть уверенными, что они выполняют условия контракта.

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

]]>
ОБЕСПЕЧЕНИЕ КАЧЕСТВА IP-ТЕЛЕФОНИИ Fri, 02 Dec 2011 02:00:00 +0400
5.13. Организационные аспекты обеспечения параметров качества IP-телефонии - Часть 1 /books/ip-telephony/72-ip5/1078-5-13-organizacionnye-aspekty-obespecheniya-parametrov-kachestva-ip-telefonii-chast-1 /books/ip-telephony/72-ip5/1078-5-13-organizacionnye-aspekty-obespecheniya-parametrov-kachestva-ip-telefonii-chast-1 Многие компании не имеют ресурсов или опыта управления сетью из конца в конец, поэтому они часто обращаются к сервис-провайдерам (первичным провайдерам) за услугами глобальных сетей. В прошлом провайдерам было достаточно поддерживать постоянную ра­ботоспособность своих сетей, чтобы абоненты могли передавать и получать информацию, когда им необходимо.

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

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

SLA должно также определять, какие сервисы и, что более важно, гарантии обслужи­вания предлагаются для каждого класса трафика. Кроме того, оно должно указывать пропу­скную способность (скорость, с которой пакеты передаются по сети), задержку (время между отправкой и приемом пакетов на конечных станциях), процент потерянных пакетов (макси­мально возможное число удаленных при передаче пакетов) и вариацию задержки (разницу во времени доставки пакетов из одного потока).

Сервис-провайдер может определить два или более уровней QoS и взимать за них со­ответствующую плату. Наинизший уровень QoS может использоваться для доставки данных по мере возможности по типу Internet. Более высокий уровень обслуживания - для критиче­ски важных данных, включая приложения ERP с низким процентом потерянных пакетов и контролируемой задержкой. Самый высокий уровень обслуживания - для приложений ре­ального времени типа видеоконференции и видеосвязи; этот уровень должен характеризо­ваться очень малой задержкой и вариацией задержки, а также очень низким процентом поте­рянных пакетов.

]]>
ОБЕСПЕЧЕНИЕ КАЧЕСТВА IP-ТЕЛЕФОНИИ Thu, 01 Dec 2011 21:21:00 +0400
5.12. Обеспечение качества IP-телефонии с помощью механизма управления на основе правил - Часть 3 /books/ip-telephony/72-ip5/1077-5-12-obespechenie-kachestva-ip-telefonii-s-pomoshhyu-mexanizma-upravleniya-na-osnove-pravil-chast-3 /books/ip-telephony/72-ip5/1077-5-12-obespechenie-kachestva-ip-telefonii-s-pomoshhyu-mexanizma-upravleniya-na-osnove-pravil-chast-3 Ближайшие перспективы администрирования на основе стратегий в среде, состоящей из продуктов различных производителей, оставляют желать лучшего. К сожалению, реализа­ции механизмов работы с набором правил и алгоритмы формирования трафика сильно раз­личаются не только в продуктах разных производителей, но даже в пределах ассортимента одной компании. Чтобы добиться реальной совместимости устройств или их единого адми­нистрирования, нужны стандартные модели общих функций для задания и выполнения алго­ритмов и формирования трафика. Необходимо также обеспечить единое представление схе­мы реализации QoS и информации о стратегиях в базе данных Policy Information Base (PIB), равно как и поддержку работы с PIB сетевыми устройствами.

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

За последний год-полтора не осталось ни одного крупного производителя, не анонси­ровавшего решений для управления сетями на основе набора правил; однако пока лишь не­многие из них довели дело до готового продукта.

]]>
ОБЕСПЕЧЕНИЕ КАЧЕСТВА IP-ТЕЛЕФОНИИ Sat, 19 Nov 2011 01:55:00 +0400
5.12. Обеспечение качества IP-телефонии с помощью механизма управления на основе правил - Часть 2 /books/ip-telephony/72-ip5/1076-5-12-obespechenie-kachestva-ip-telefonii-s-pomoshhyu-mexanizma-upravleniya-na-osnove-pravil-chast-2 /books/ip-telephony/72-ip5/1076-5-12-obespechenie-kachestva-ip-telefonii-s-pomoshhyu-mexanizma-upravleniya-na-osnove-pravil-chast-2 Связь между элементами PDP и PEP обеспечивает несложный протокол запро­сов/ответов Common Open Policy Service (COPS). Его преимущества перед SNMP состоят в ориентации на соединения (он охватывает процесс установления/разрыва соединения), большей надежности и наличии механизмов, предотвращающих попытки одновременного обновления данных одной точки PEP несколькими PDP.

Однако предложенная схема не определяет способов реализации означенной инфра­структуры. Возможны сосуществование на одном сервере различных компонентов или рабо­та каждого из них на отдельном компьютере.

Типичная сеть с поддержкой администрирования на основе стратегий и механизмов обеспечения QoS показана на рис. 5.11. Ее построение потребует интеграции множества сер­веров, LDAP-каталогов, использования разных протоколов и сетевых устройств: коммутато­ров/маршрутизаторов опорной сети PEP 1, коммутаторов/маршрутизаторов непосредствен­ного подключения терминалов PEP 2, коммутаторов/маршрутизаторов территориально-распределенной сети PEP 3.

Рис. 5.11. Типичная сеть с поддержкой администрирования на основе стратегий и механизмов обеспечения QoS

Чтобы обеспечить оптимальный процесс хранения и извлечения из хранилища правил, составляющих стратегии, их внутреннее представление должно быть формализовано в струк­туру данных. Рабочая группа IETF Policy Framework Working Group (PFWG) разработала мо­дель Policy Framework Core Information Model, в которой определен высокоуровневый набор объектно ориентированных классов, достаточный для представления базовых стратегий управления. Объектные классы могут расширяться производными классами конкретных ти­пов стратегий - например, обеспечения QoS или безопасности.

Уже сейчас между производителями существует соглашение, закрепляющее некото­рые технические аспекты данной технологии. Так, информация о стратегиях должна хра­ниться в LDAP-совместимом каталоге. Группа PFWG построила отображение модели Core Information Model на структуру каталога LDAP. Концепции, заложенные в эту модель, не только пользуются широкой поддержкой производителей, но и закреплены IETF в проектах нескольких стандартов. Хотя ни один из них еще не достиг стадии предложений по специфи­кациям (request for comments, RFC), они дают ясное представление о том, как построить сеть, управляемую по заданным правилам.

]]>
ОБЕСПЕЧЕНИЕ КАЧЕСТВА IP-ТЕЛЕФОНИИ Fri, 04 Nov 2011 02:50:00 +0400
5.12. Обеспечение качества IP-телефонии с помощью механизма управления на основе правил - Часть 1 /books/ip-telephony/72-ip5/1075-5-12-obespechenie-kachestva-ip-telefonii-s-pomoshhyu-mexanizma-upravleniya-na-osnove-pravil-chast-1 /books/ip-telephony/72-ip5/1075-5-12-obespechenie-kachestva-ip-telefonii-s-pomoshhyu-mexanizma-upravleniya-na-osnove-pravil-chast-1 Одним из перспективных направлений в реализации гарантированных уровней качест­ва сервиса (QoS) в среде IP является разрабатываемая в настоящее время технология управ­ления на основе правил.

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

Высокоуровневые формулировки стратегии (например, «Предоставлять приоритет всем пакетам трафика voice-over-IP») преобразуются в структурированный набор правил ви­да «если <условие>, то <реакция>», который хранится в базе администратора, извлекается и интерпретируется различными сетевыми компонентами. Заметим, что системы первого по­коления не могли сами интерпретировать высокоуровневые формулировки, а требовали от администратора формализованных условных операторов вида «если порт = HTTP (80), то установить приоритет трафика IP = 4».

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

• консоль для задания стратегий - средство администрирования, с помощью которого сетевой администратор создает и редактирует набор правил управления;

• точка принятия решений (policy decision point, PDP) - сервер, обеспечивающий выбор­ку правил из хранилища и выработку решений;

• точки реализации стратегий (policy enforcement point, PEP) - различные сетевые уст­ройства (маршрутизаторы, коммутаторы и брандмауэры), претворяющие в жизнь ре­шения PDP (т. е. правила управления сетью) с помощью списков доступа, алгоритмов управления очередями и других средств;

• хранилище стратегий - способный работать с протоколом LDAP сервер, на котором в специальном каталоге хранятся стратегии.

]]>
ОБЕСПЕЧЕНИЕ КАЧЕСТВА IP-ТЕЛЕФОНИИ Sat, 01 Oct 2011 12:07:00 +0400
5.11. Спецификация IEEE 802.1р /books/ip-telephony/72-ip5/1074-5-11-specifikaciya-ieee-802-1r /books/ip-telephony/72-ip5/1074-5-11-specifikaciya-ieee-802-1r Рабочая группа IEEE 802.1 по высокоуровневым протоколам для локальных сетей раз­работала спецификацию 802.1р для приоритезации трафика в соответствии с восемью класса­ми - от обработки по мере возможности до поддержки передачи голоса и видео в реальном времени. Промежуточные уровни между ними занимают классы для потокового мультимедиа типа неинтерактивных видеоклипов и для важного трафика типа запросов к базам данных.

802.1р анализирует поля приоритета в заголовке пакета. Ей в помощь IEEE предложил спецификацию 802.1Q. предусматривающую 32-разрядный заголовок пакета, предшествующий адресам отправителя и получателя в кадре Ethernet. Этот 32-разрядный заголовок может быть определен маршрутизаторами, коммутаторами и даже станциями конечных пользователей. Он содержит информацию о группах виртуальных локальных сетей и сигнализации 802.1р.

На основании этого заголовка маршрутизаторы и коммутаторы (на втором и на треть­ем уровнях) могут принимать решения о приоритете трафика с учетом предопределенных правил, заданных администратором сети.

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

]]>
ОБЕСПЕЧЕНИЕ КАЧЕСТВА IP-ТЕЛЕФОНИИ Fri, 23 Sep 2011 07:45:00 +0400
5.10. Обеспечение качества IP-телефонии на базе MPLS - Часть 3 /books/ip-telephony/72-ip5/1073-5-10-obespechenie-kachestva-ip-telefonii-na-baze-mpls-chast-3 /books/ip-telephony/72-ip5/1073-5-10-obespechenie-kachestva-ip-telefonii-na-baze-mpls-chast-3

]]>
ОБЕСПЕЧЕНИЕ КАЧЕСТВА IP-ТЕЛЕФОНИИ Fri, 23 Sep 2011 05:38:00 +0400
5.10. Обеспечение качества IP-телефонии на базе MPLS - Часть 2 /books/ip-telephony/72-ip5/1072-5-10-obespechenie-kachestva-ip-telefonii-na-baze-mpls-chast-2 /books/ip-telephony/72-ip5/1072-5-10-obespechenie-kachestva-ip-telefonii-na-baze-mpls-chast-2 При использовании меток MPLS маршрутизатор или коммутатор может присвоить метки записям из своих таблиц маршрутизации и в виде меток передать информацию о мар­шрутизации конкретным маршрутизаторам и коммутаторам. Считав метку, каждый коммута­тор или маршрутизатор узнает информацию о следующем адресате на пути, не анализируя заголовок пакета. Это экономит время и ресурсы ЦПУ. Пакеты с метками MPLS могут, сле­довательно, передаваться от отправителя к получателю без задержек на обработку, причем все промежуточные узлы знают, как нужно обрабатывать каждый пакет.

По сути, MPLS привносит коммутацию каналов, какую мы имеем в ATM, в мир па­кетных сетей, связанных с IP. На практике MPLS можно использовать для доставки IP-трафика по сетям IP.

Следует отметить, что DiffServ функционирует на третьем уровне, a MPLS - на вто­ром, поэтому с технической точки зрения обе технологии могут мирно существовать друг с другом. Как уже упоминалось, DiffServ классифицирует пакеты при их поступлении на крае­вой маршрутизатор, поэтому данный стандарт, скорее всего, будет использоваться на грани­це сети, например, между компанией и ее сервис-провайдером.

А ввиду того, что MPLS предполагает включение дополнительных меток и использо­вание маршрутизаторов/коммутаторов, способных интерпретировать данную информацию, он, вероятно, найдет применение исключительно внутри корпоративных сетей или базовой сети оператора, где требуется высокий уровень QoS для IР-трафика.

Если DiffServ требует некоторой настройки сетевых маршрутизаторов, то MPLS пред­полагает более серьезную модернизацию, чтобы маршрутизаторы могли читать метки и на­правлять пакеты по конкретным маршрутам.

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

]]>
ОБЕСПЕЧЕНИЕ КАЧЕСТВА IP-ТЕЛЕФОНИИ Wed, 31 Aug 2011 17:39:00 +0400
5.10. Обеспечение качества IP-телефонии на базе MPLS - Часть 1 /books/ip-telephony/72-ip5/1071-5-10-obespechenie-kachestva-ip-telefonii-na-baze-mpls-chast-1 /books/ip-telephony/72-ip5/1071-5-10-obespechenie-kachestva-ip-telefonii-na-baze-mpls-chast-1 Конкурентом DiffServ на роль протокола для обеспечения QoS является другой проект 1ETF под названием «Многопротокольная коммутация меток» (Multiprotocol Label Switching, MPLS).

При IP-коммутации узел анализирует первые несколько пакетов поступающего трафи­ка и, в случае короткой посылки, например запроса DNS или SNMP, обрабатывает их как обычный маршрутизатор. Но если узел идентифицирует длительный поток - от трафика telnet или ftp до загрузки файлов через Web и мультимедийных приложений, то IP-коммутатор переключается на нижележащую структуру ATM и применяет сквозную комму­тацию для быстрой доставки данных адресату.

IP-коммутация поддерживает различные уровни QoS и может использовать ATM, имеющий многочисленные встроенные средства поддержки QoS, и RSVP.

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

Если DiffServ задействует заголовок DS, уже имеющийся в пакетах IPv4, то MPLS ис­пользует 32-разрядную информационную метку, добавляемую к каждому IP-пакету. Эта мет­ка, добавляемая при входе в сеть с поддержкой MPLS, сообщает каждому маршрутизатору вдоль пути следования, как надо обрабатывать пакет. В частности, она содержит информа­цию о требуемом для данного пакета уровне QoS.

В отличие от поля DS, метка MPLS изначально не является частью пакета IP. Скорее, она добавляется при поступлении пакета в сеть и удаляется при выходе пакета из сети MPLS.

В обычной ситуации маршрутизаторы анализируют заголовок пакета для определения его адресата. Ввиду того, что такой анализ проводится на каждом транзитном узле независи­мо, предсказать, каким маршрутом будет следовать пакет, практически невозможно, поэтому обеспечение гарантированного уровня QoS оказывается невероятно сложной задачей.

]]>
ОБЕСПЕЧЕНИЕ КАЧЕСТВА IP-ТЕЛЕФОНИИ Fri, 19 Aug 2011 00:06:00 +0400
5.9. Обеспечение качества IP-телефонии на базе дифференцированного обслуживания - Часть 2 /books/ip-telephony/72-ip5/1070-5-9-obespechenie-kachestva-ip-telefonii-na-baze-differencirovannogo-obsluzhivaniya-chast-2 /books/ip-telephony/72-ip5/1070-5-9-obespechenie-kachestva-ip-telefonii-na-baze-differencirovannogo-obsluzhivaniya-chast-2 В настоящее время только 6 из 8 бит в поле DS были определены, и только одно на­значение было стандартизовано. Это назначение известно как принятое по умолчанию - Default (DE), - и оно определяет класс обслуживания по мере возможности. Другое предпо­лагаемое назначение, срочная отправка (Expedited Forwarding, EF), должно обеспечить со­кращение задержек и потерь пакетов.

При поступлении трафика в сеть краевой маршрутизатор классифицирует график в соответствии с информацией, содержащейся в поле DS. Он передает следующим за ним маршрутизаторам эту информацию, на основании которой они узнают, каким образом обра­батывать данный конкретный поток.

DiffServ, кроме того, сокращает служебный трафик по сравнению с RSVP и IntServ, опирающимися на сигнализацию из конца в конец. DiffServ классифицирует потоки в соот­ветствии с предопределенными правилами и затем объединяет однотипные потоки. Подоб­ный механизм делает DiffServ гораздо более масштабируемым, чем его предшественника IntServ. Весь трафик с одинаковыми метками рассматривается одинаковым образом, поэтому реализация DiffServ в сети крупного предприятия или по каналам глобальной сети оказыва­ется более реальной задачей.

Как можно догадаться, преимущества DiffServ нельзя получить автоматически. Мар­шрутизаторы должны понимать «меченые потоки» и уметь соответствующим образом реаги­ровать на них. Это потребует модернизации микропрограммного обеспечения маршрутиза­торов. К счастью, с популяризацией DiffServ все большее число производителей намеревает­ся поддерживать данную архитектуру в будущих версиях своих продуктов.

]]>
ОБЕСПЕЧЕНИЕ КАЧЕСТВА IP-ТЕЛЕФОНИИ Wed, 20 Jul 2011 07:25:00 +0400