Мини-Сервер своими руками - это просто! - IP телефония /books/ip-telephony/72-ip5 2021-06-25T01:39:43+03:00 Мини-Сервер singlwolf@mini-server.ru Joomla! - Open Source Content Management 5.13. Организационные аспекты обеспечения параметров качества IP-телефонии - Часть 2 2011-12-02T02:00:00+04:00 2011-12-02T02:00:00+04:00 /books/ip-telephony/72-ip5/1079-5-13-organizacionnye-aspekty-obespecheniya-parametrov-kachestva-ip-telefonii-chast-2 <p>Заказчики должны иметь способ мониторинга реального уровня QoS. Это может де­латься посредством аудита журналов <i>сетевых</i> ресурсов. Сервис-провайдеры также должны вести учет, чтобы быть уверенными, что они выполняют условия контракта.</p> <p>Качество услуг может являться ключевым дифференцирующим фактором между сер­вис-провайдерами в их борьбе за клиентуру. SLA представляют собой один из способов предложить определенный стандарт обслуживания, опираясь на который заказчики могли бы реализовать доставку трафика реального времени.</p> <p></p> <p>Заказчики должны иметь способ мониторинга реального уровня QoS. Это может де­латься посредством аудита журналов <i>сетевых</i> ресурсов. Сервис-провайдеры также должны вести учет, чтобы быть уверенными, что они выполняют условия контракта.</p> <p>Качество услуг может являться ключевым дифференцирующим фактором между сер­вис-провайдерами в их борьбе за клиентуру. SLA представляют собой один из способов предложить определенный стандарт обслуживания, опираясь на который заказчики могли бы реализовать доставку трафика реального времени.</p> <p></p> 5.13. Организационные аспекты обеспечения параметров качества IP-телефонии - Часть 1 2011-12-01T21:21:00+04:00 2011-12-01T21:21:00+04:00 /books/ip-telephony/72-ip5/1078-5-13-organizacionnye-aspekty-obespecheniya-parametrov-kachestva-ip-telefonii-chast-1 <p>Многие компании не имеют ресурсов или опыта управления <em>сетью</em> из конца в конец, поэтому они часто обращаются к сервис-провайдерам (первичным провайдерам) за услугами глобальных <b>сетей</b>. В прошлом провайдерам было достаточно поддерживать постоянную ра­ботоспособность своих сетей, чтобы абоненты могли передавать и получать информацию, когда им необходимо.</p> <p>Но с распространением приложений реального времени, и, в частности, Интернет-телефонии, провайдеры все чаще сталкиваются с тем, что для сохранения своего бизнеса и привлечения клиентов им необходимо принять специальные меры для этих типов информа­ционных потоков.</p> <p>Один из способов сделать это - заключение соглашений об уровне сервиса (Service Level Agreement, SLA), т. е. контрактов, где четко указано, какого уровня доступность, сер­висы и цены ожидает получить заказчик. В таком соглашении сервис-провайдеры должны гарантировать срок бессбойной работы и длительность задержки в конкретное время суток для конкретных видов приложений. Оно также может содержать информацию о доступности пользовательского соединения.</p> <p>SLA должно также определять, какие сервисы и, что более важно, гарантии обслужи­вания предлагаются для каждого класса трафика. Кроме того, оно должно указывать пропу­скную способность (скорость, с которой пакеты передаются по сети), задержку (время между отправкой и приемом пакетов на конечных станциях), процент потерянных пакетов (макси­мально возможное число удаленных при передаче пакетов) и вариацию задержки (разницу во времени доставки пакетов из одного потока).</p> <p>Сервис-провайдер может определить два или более уровней QoS и взимать за них со­ответствующую плату. Наинизший уровень QoS может использоваться для доставки данных по мере возможности по типу Internet. Более высокий уровень обслуживания - для критиче­ски важных данных, включая приложения ERP с низким процентом потерянных пакетов и <b>контролируемой</b> задержкой. Самый высокий уровень обслуживания - для приложений ре­ального времени типа видеоконференции и видеосвязи; этот уровень должен характеризо­ваться очень малой задержкой и вариацией задержки, а также очень низким процентом поте­рянных пакетов.</p> <p>Многие компании не имеют ресурсов или опыта управления <em>сетью</em> из конца в конец, поэтому они часто обращаются к сервис-провайдерам (первичным провайдерам) за услугами глобальных <b>сетей</b>. В прошлом провайдерам было достаточно поддерживать постоянную ра­ботоспособность своих сетей, чтобы абоненты могли передавать и получать информацию, когда им необходимо.</p> <p>Но с распространением приложений реального времени, и, в частности, Интернет-телефонии, провайдеры все чаще сталкиваются с тем, что для сохранения своего бизнеса и привлечения клиентов им необходимо принять специальные меры для этих типов информа­ционных потоков.</p> <p>Один из способов сделать это - заключение соглашений об уровне сервиса (Service Level Agreement, SLA), т. е. контрактов, где четко указано, какого уровня доступность, сер­висы и цены ожидает получить заказчик. В таком соглашении сервис-провайдеры должны гарантировать срок бессбойной работы и длительность задержки в конкретное время суток для конкретных видов приложений. Оно также может содержать информацию о доступности пользовательского соединения.</p> <p>SLA должно также определять, какие сервисы и, что более важно, гарантии обслужи­вания предлагаются для каждого класса трафика. Кроме того, оно должно указывать пропу­скную способность (скорость, с которой пакеты передаются по сети), задержку (время между отправкой и приемом пакетов на конечных станциях), процент потерянных пакетов (макси­мально возможное число удаленных при передаче пакетов) и вариацию задержки (разницу во времени доставки пакетов из одного потока).</p> <p>Сервис-провайдер может определить два или более уровней QoS и взимать за них со­ответствующую плату. Наинизший уровень QoS может использоваться для доставки данных по мере возможности по типу Internet. Более высокий уровень обслуживания - для критиче­ски важных данных, включая приложения ERP с низким процентом потерянных пакетов и <b>контролируемой</b> задержкой. Самый высокий уровень обслуживания - для приложений ре­ального времени типа видеоконференции и видеосвязи; этот уровень должен характеризо­ваться очень малой задержкой и вариацией задержки, а также очень низким процентом поте­рянных пакетов.</p> 5.12. Обеспечение качества IP-телефонии с помощью механизма управления на основе правил - Часть 3 2011-11-19T01:55:00+04:00 2011-11-19T01:55:00+04:00 /books/ip-telephony/72-ip5/1077-5-12-obespechenie-kachestva-ip-telefonii-s-pomoshhyu-mexanizma-upravleniya-na-osnove-pravil-chast-3 <p>Ближайшие перспективы администрирования на основе стратегий в среде, состоящей из продуктов различных производителей, оставляют желать лучшего. К сожалению, реализа­ции механизмов работы с набором правил и алгоритмы формирования трафика сильно раз­личаются не только в продуктах разных производителей, но даже в пределах ассортимента одной компании. Чтобы добиться реальной совместимости устройств или их единого адми­нистрирования, нужны стандартные модели общих функций для задания и выполнения алго­ритмов и формирования трафика. Необходимо также обеспечить единое представление схе­мы реализации QoS и информации о стратегиях в базе данных Policy Information Base (PIB), равно как и поддержку работы с PIB <b>сетевыми</b> устройствами.</p> <p>Большинство производителей ограничивается рамками собственного оборудования и, по мере сил, реализацией совместимости с продукцией Cisco. Однако обширный список ме­ханизмов QoS, поддерживаемых устройствами этой компании, с каждым днем становится все длиннее. На начальном этапе все инициативы в области администрирования <strong>сетей</strong> на основе стратегий сосредоточены на обеспечении QoS, но в дальнейшем органы стандартизации и производители обратят внимание и на <em>сетевую</em> безопасность.</p> <p>За последний год-полтора не осталось ни одного крупного производителя, не анонси­ровавшего решений для управления сетями на основе набора правил; однако пока лишь не­многие из них довели дело до готового продукта.</p> <p></p> <p>Ближайшие перспективы администрирования на основе стратегий в среде, состоящей из продуктов различных производителей, оставляют желать лучшего. К сожалению, реализа­ции механизмов работы с набором правил и алгоритмы формирования трафика сильно раз­личаются не только в продуктах разных производителей, но даже в пределах ассортимента одной компании. Чтобы добиться реальной совместимости устройств или их единого адми­нистрирования, нужны стандартные модели общих функций для задания и выполнения алго­ритмов и формирования трафика. Необходимо также обеспечить единое представление схе­мы реализации QoS и информации о стратегиях в базе данных Policy Information Base (PIB), равно как и поддержку работы с PIB <b>сетевыми</b> устройствами.</p> <p>Большинство производителей ограничивается рамками собственного оборудования и, по мере сил, реализацией совместимости с продукцией Cisco. Однако обширный список ме­ханизмов QoS, поддерживаемых устройствами этой компании, с каждым днем становится все длиннее. На начальном этапе все инициативы в области администрирования <strong>сетей</strong> на основе стратегий сосредоточены на обеспечении QoS, но в дальнейшем органы стандартизации и производители обратят внимание и на <em>сетевую</em> безопасность.</p> <p>За последний год-полтора не осталось ни одного крупного производителя, не анонси­ровавшего решений для управления сетями на основе набора правил; однако пока лишь не­многие из них довели дело до готового продукта.</p> <p></p> 5.12. Обеспечение качества IP-телефонии с помощью механизма управления на основе правил - Часть 2 2011-11-04T02:50:00+04:00 2011-11-04T02:50:00+04:00 /books/ip-telephony/72-ip5/1076-5-12-obespechenie-kachestva-ip-telefonii-s-pomoshhyu-mexanizma-upravleniya-na-osnove-pravil-chast-2 <p>Связь между элементами PDP и PEP обеспечивает несложный протокол запро­сов/ответов Common Open Policy Service (COPS). Его преимущества перед SNMP состоят в ориентации на соединения (он охватывает процесс установления/разрыва соединения), большей надежности и наличии механизмов, предотвращающих попытки одновременного обновления данных одной точки PEP несколькими PDP.</p> <p>Однако предложенная <i>схема</i> не определяет способов реализации означенной инфра­структуры. Возможны сосуществование на одном сервере различных компонентов или рабо­та каждого из них на отдельном компьютере.</p> <p>Типичная сеть с поддержкой администрирования на основе стратегий и механизмов обеспечения QoS показана на рис. 5.11. Ее построение потребует интеграции множества сер­веров, LDAP-каталогов, использования разных протоколов и сетевых устройств: коммутато­ров/маршрутизаторов опорной <strong>сети</strong> PEP 1, коммутаторов/маршрутизаторов непосредствен­ного подключения терминалов PEP 2, коммутаторов/маршрутизаторов территориально-распределенной сети PEP 3.</p> <p><img src="//images/stories/knigi/ip-phone/image094.jpg" width="539" height="414" class=""/></p> <p>Рис. 5.11. Типичная <i>сеть</i> с поддержкой администрирования на основе стратегий и механизмов обеспечения QoS</p> <p>Чтобы обеспечить оптимальный процесс хранения и извлечения из хранилища правил, составляющих стратегии, их внутреннее представление должно быть формализовано в струк­туру данных. Рабочая группа IETF Policy Framework Working Group (PFWG) разработала мо­дель Policy Framework Core Information Model, в которой определен высокоуровневый набор объектно ориентированных классов, достаточный для представления базовых стратегий управления. Объектные классы могут расширяться производными классами конкретных ти­пов стратегий - например, обеспечения QoS или безопасности.</p> <p>Уже сейчас между производителями существует соглашение, закрепляющее некото­рые технические аспекты данной технологии. Так, информация о стратегиях должна хра­ниться в LDAP-совместимом каталоге. Группа PFWG построила отображение модели Core Information Model на структуру каталога LDAP. Концепции, заложенные в эту модель, не только пользуются широкой поддержкой производителей, но и закреплены IETF в проектах нескольких стандартов. Хотя ни один из них еще не достиг стадии предложений по специфи­кациям (request for comments, RFC), они дают ясное представление о том, как построить сеть, управляемую по заданным правилам.</p> <p>Связь между элементами PDP и PEP обеспечивает несложный протокол запро­сов/ответов Common Open Policy Service (COPS). Его преимущества перед SNMP состоят в ориентации на соединения (он охватывает процесс установления/разрыва соединения), большей надежности и наличии механизмов, предотвращающих попытки одновременного обновления данных одной точки PEP несколькими PDP.</p> <p>Однако предложенная <i>схема</i> не определяет способов реализации означенной инфра­структуры. Возможны сосуществование на одном сервере различных компонентов или рабо­та каждого из них на отдельном компьютере.</p> <p>Типичная сеть с поддержкой администрирования на основе стратегий и механизмов обеспечения QoS показана на рис. 5.11. Ее построение потребует интеграции множества сер­веров, LDAP-каталогов, использования разных протоколов и сетевых устройств: коммутато­ров/маршрутизаторов опорной <strong>сети</strong> PEP 1, коммутаторов/маршрутизаторов непосредствен­ного подключения терминалов PEP 2, коммутаторов/маршрутизаторов территориально-распределенной сети PEP 3.</p> <p><img src="//images/stories/knigi/ip-phone/image094.jpg" width="539" height="414" class=""/></p> <p>Рис. 5.11. Типичная <i>сеть</i> с поддержкой администрирования на основе стратегий и механизмов обеспечения QoS</p> <p>Чтобы обеспечить оптимальный процесс хранения и извлечения из хранилища правил, составляющих стратегии, их внутреннее представление должно быть формализовано в струк­туру данных. Рабочая группа IETF Policy Framework Working Group (PFWG) разработала мо­дель Policy Framework Core Information Model, в которой определен высокоуровневый набор объектно ориентированных классов, достаточный для представления базовых стратегий управления. Объектные классы могут расширяться производными классами конкретных ти­пов стратегий - например, обеспечения QoS или безопасности.</p> <p>Уже сейчас между производителями существует соглашение, закрепляющее некото­рые технические аспекты данной технологии. Так, информация о стратегиях должна хра­ниться в LDAP-совместимом каталоге. Группа PFWG построила отображение модели Core Information Model на структуру каталога LDAP. Концепции, заложенные в эту модель, не только пользуются широкой поддержкой производителей, но и закреплены IETF в проектах нескольких стандартов. Хотя ни один из них еще не достиг стадии предложений по специфи­кациям (request for comments, RFC), они дают ясное представление о том, как построить сеть, управляемую по заданным правилам.</p> 5.12. Обеспечение качества IP-телефонии с помощью механизма управления на основе правил - Часть 1 2011-10-01T12:07:00+04:00 2011-10-01T12:07:00+04:00 /books/ip-telephony/72-ip5/1075-5-12-obespechenie-kachestva-ip-telefonii-s-pomoshhyu-mexanizma-upravleniya-na-osnove-pravil-chast-1 <p>Одним из перспективных направлений в реализации гарантированных уровней качест­ва сервиса (QoS) в среде IP является разрабатываемая в настоящее время технология управ­ления на основе правил.</p> <p>Набор правил, или стратегия, описывает способ распределения ресурсов <b>сети</b> между ее клиентами - пользователями, приложениями или хост-машинами. Выделение этих ресурсов может происходить статически и динамически, в зависимости от разных факторов, например, времени дня, объема самих свободных ресурсов или наличия у клиентов подтвержденных авторизацией привилегий.</p> <p>Высокоуровневые формулировки стратегии (например, «Предоставлять приоритет всем пакетам трафика voice-over-IP») преобразуются в структурированный набор правил ви­да «если &lt;условие&gt;, то &lt;реакция&gt;», который хранится в базе администратора, извлекается и интерпретируется различными сетевыми компонентами. Заметим, что системы первого по­коления не могли сами интерпретировать высокоуровневые формулировки, а требовали от администратора формализованных условных операторов вида «если порт = HTTP (80), то установить приоритет трафика IP = 4».</p> <p>Один из наиболее многообещающих проектов в области управления сетью на основе правил реализуется в настоящее время IETF: это исследования, связанные с определением стандартной инфраструктуры для применения данной методологии, а также набора необходи­мых протоколов и <strong>схем</strong> работы. Согласно уже имеющимся материалам IETF, в составе типич­ной сети, администрируемой по набору правил, должны присутствовать следующие элементы:</p> <p>• консоль для задания стратегий - средство администрирования, с помощью которого сетевой администратор создает и редактирует набор правил управления;</p> <p>• точка принятия решений (policy decision point, PDP) - сервер, обеспечивающий выбор­ку правил из хранилища и выработку решений;</p> <p>• точки реализации стратегий (policy enforcement point, PEP) - различные сетевые уст­ройства (маршрутизаторы, коммутаторы и брандмауэры), претворяющие в жизнь ре­шения PDP (т. е. правила управления сетью) с помощью списков доступа, алгоритмов управления очередями и других средств;</p> <p>• хранилище стратегий - способный работать с протоколом LDAP <a href="/">сервер</a>, на котором в специальном каталоге хранятся стратегии.</p> <p>Одним из перспективных направлений в реализации гарантированных уровней качест­ва сервиса (QoS) в среде IP является разрабатываемая в настоящее время технология управ­ления на основе правил.</p> <p>Набор правил, или стратегия, описывает способ распределения ресурсов <b>сети</b> между ее клиентами - пользователями, приложениями или хост-машинами. Выделение этих ресурсов может происходить статически и динамически, в зависимости от разных факторов, например, времени дня, объема самих свободных ресурсов или наличия у клиентов подтвержденных авторизацией привилегий.</p> <p>Высокоуровневые формулировки стратегии (например, «Предоставлять приоритет всем пакетам трафика voice-over-IP») преобразуются в структурированный набор правил ви­да «если &lt;условие&gt;, то &lt;реакция&gt;», который хранится в базе администратора, извлекается и интерпретируется различными сетевыми компонентами. Заметим, что системы первого по­коления не могли сами интерпретировать высокоуровневые формулировки, а требовали от администратора формализованных условных операторов вида «если порт = HTTP (80), то установить приоритет трафика IP = 4».</p> <p>Один из наиболее многообещающих проектов в области управления сетью на основе правил реализуется в настоящее время IETF: это исследования, связанные с определением стандартной инфраструктуры для применения данной методологии, а также набора необходи­мых протоколов и <strong>схем</strong> работы. Согласно уже имеющимся материалам IETF, в составе типич­ной сети, администрируемой по набору правил, должны присутствовать следующие элементы:</p> <p>• консоль для задания стратегий - средство администрирования, с помощью которого сетевой администратор создает и редактирует набор правил управления;</p> <p>• точка принятия решений (policy decision point, PDP) - сервер, обеспечивающий выбор­ку правил из хранилища и выработку решений;</p> <p>• точки реализации стратегий (policy enforcement point, PEP) - различные сетевые уст­ройства (маршрутизаторы, коммутаторы и брандмауэры), претворяющие в жизнь ре­шения PDP (т. е. правила управления сетью) с помощью списков доступа, алгоритмов управления очередями и других средств;</p> <p>• хранилище стратегий - способный работать с протоколом LDAP <a href="/">сервер</a>, на котором в специальном каталоге хранятся стратегии.</p> 5.11. Спецификация IEEE 802.1р 2011-09-23T07:45:00+04:00 2011-09-23T07:45:00+04:00 /books/ip-telephony/72-ip5/1074-5-11-specifikaciya-ieee-802-1r <p>Рабочая группа IEEE 802.1 по высокоуровневым протоколам для локальных сетей раз­работала спецификацию 802.1р для приоритезации трафика в соответствии с восемью класса­ми - от обработки по мере возможности до поддержки передачи голоса и видео в реальном времени. Промежуточные уровни между ними занимают классы для потокового мультимедиа типа неинтерактивных видеоклипов и для важного трафика типа запросов к базам данных.</p> <p>802.1р анализирует поля приоритета в заголовке пакета. Ей в помощь IEEE предложил спецификацию 802.1Q. предусматривающую 32-разрядный заголовок пакета, предшествующий адресам отправителя и получателя в кадре Ethernet. Этот 32-разрядный заголовок может быть определен маршрутизаторами, коммутаторами и даже станциями конечных пользователей. Он содержит информацию о группах виртуальных локальных <i>сетей</i> и сигнализации 802.1р.</p> <p>На основании этого заголовка маршрутизаторы и коммутаторы (на втором и на треть­ем уровнях) могут принимать решения о приоритете трафика с учетом предопределенных правил, заданных администратором сети.</p> <p>Стандарт 802.1 р призван обеспечить QoS при коммутации в локальных <strong>сетях</strong>, поэтому он может быть не столь привлекательным, как рассмотренные выше технологии для глобаль­ных <b>сетей</b> Интернет-телефонии.</p> <p></p> <p>Рабочая группа IEEE 802.1 по высокоуровневым протоколам для локальных сетей раз­работала спецификацию 802.1р для приоритезации трафика в соответствии с восемью класса­ми - от обработки по мере возможности до поддержки передачи голоса и видео в реальном времени. Промежуточные уровни между ними занимают классы для потокового мультимедиа типа неинтерактивных видеоклипов и для важного трафика типа запросов к базам данных.</p> <p>802.1р анализирует поля приоритета в заголовке пакета. Ей в помощь IEEE предложил спецификацию 802.1Q. предусматривающую 32-разрядный заголовок пакета, предшествующий адресам отправителя и получателя в кадре Ethernet. Этот 32-разрядный заголовок может быть определен маршрутизаторами, коммутаторами и даже станциями конечных пользователей. Он содержит информацию о группах виртуальных локальных <i>сетей</i> и сигнализации 802.1р.</p> <p>На основании этого заголовка маршрутизаторы и коммутаторы (на втором и на треть­ем уровнях) могут принимать решения о приоритете трафика с учетом предопределенных правил, заданных администратором сети.</p> <p>Стандарт 802.1 р призван обеспечить QoS при коммутации в локальных <strong>сетях</strong>, поэтому он может быть не столь привлекательным, как рассмотренные выше технологии для глобаль­ных <b>сетей</b> Интернет-телефонии.</p> <p></p> 5.10. Обеспечение качества IP-телефонии на базе MPLS - Часть 3 2011-09-23T05:38:00+04:00 2011-09-23T05:38:00+04:00 /books/ip-telephony/72-ip5/1073-5-10-obespechenie-kachestva-ip-telefonii-na-baze-mpls-chast-3 <p></p> <p></p> 5.10. Обеспечение качества IP-телефонии на базе MPLS - Часть 2 2011-08-31T17:39:00+04:00 2011-08-31T17:39:00+04:00 /books/ip-telephony/72-ip5/1072-5-10-obespechenie-kachestva-ip-telefonii-na-baze-mpls-chast-2 <p>При использовании меток MPLS маршрутизатор или коммутатор может присвоить метки записям из своих таблиц маршрутизации и в виде меток передать информацию о мар­шрутизации конкретным маршрутизаторам и коммутаторам. Считав метку, каждый коммута­тор или маршрутизатор узнает информацию о следующем адресате на пути, не анализируя заголовок пакета. Это экономит время и ресурсы ЦПУ. Пакеты с метками MPLS могут, сле­довательно, передаваться от отправителя к получателю без задержек на обработку, причем все промежуточные узлы знают, как нужно обрабатывать каждый пакет.</p> <p>По сути, MPLS привносит коммутацию каналов, какую мы имеем в ATM, в мир па­кетных сетей, связанных с IP. На практике MPLS можно использовать для доставки IP-трафика по <em>сетям</em> IP.</p> <p>Следует отметить, что DiffServ функционирует на третьем уровне, a MPLS - на вто­ром, поэтому с технической точки зрения обе технологии могут мирно существовать друг с другом. Как уже упоминалось, DiffServ классифицирует пакеты при их поступлении на крае­вой маршрутизатор, поэтому данный стандарт, скорее всего, будет использоваться на грани­це сети, например, между компанией и ее сервис-провайдером.</p> <p>А ввиду того, что MPLS предполагает включение дополнительных меток и использо­вание маршрутизаторов/коммутаторов, способных интерпретировать данную информацию, он, вероятно, найдет применение исключительно внутри корпоративных <b>сетей</b> или базовой <strong>сети</strong> оператора, где требуется высокий уровень QoS для IР-трафика.</p> <p>Если DiffServ требует некоторой настройки <i>сетевых</i> маршрутизаторов, то MPLS пред­полагает более серьезную модернизацию, чтобы маршрутизаторы могли читать метки и на­правлять пакеты по конкретным маршрутам.</p> <p>В настоящее время DiffServ пользуется более широким вниманием, и он ближе к окончательной стандартизации, чем MPLS. Однако каждая из технологий имеет свои пре­имущества в конкретных областях <b>сети</b>, поэтому поставщики, скорее всего, будут поддержи­вать их обе.</p> <p>При использовании меток MPLS маршрутизатор или коммутатор может присвоить метки записям из своих таблиц маршрутизации и в виде меток передать информацию о мар­шрутизации конкретным маршрутизаторам и коммутаторам. Считав метку, каждый коммута­тор или маршрутизатор узнает информацию о следующем адресате на пути, не анализируя заголовок пакета. Это экономит время и ресурсы ЦПУ. Пакеты с метками MPLS могут, сле­довательно, передаваться от отправителя к получателю без задержек на обработку, причем все промежуточные узлы знают, как нужно обрабатывать каждый пакет.</p> <p>По сути, MPLS привносит коммутацию каналов, какую мы имеем в ATM, в мир па­кетных сетей, связанных с IP. На практике MPLS можно использовать для доставки IP-трафика по <em>сетям</em> IP.</p> <p>Следует отметить, что DiffServ функционирует на третьем уровне, a MPLS - на вто­ром, поэтому с технической точки зрения обе технологии могут мирно существовать друг с другом. Как уже упоминалось, DiffServ классифицирует пакеты при их поступлении на крае­вой маршрутизатор, поэтому данный стандарт, скорее всего, будет использоваться на грани­це сети, например, между компанией и ее сервис-провайдером.</p> <p>А ввиду того, что MPLS предполагает включение дополнительных меток и использо­вание маршрутизаторов/коммутаторов, способных интерпретировать данную информацию, он, вероятно, найдет применение исключительно внутри корпоративных <b>сетей</b> или базовой <strong>сети</strong> оператора, где требуется высокий уровень QoS для IР-трафика.</p> <p>Если DiffServ требует некоторой настройки <i>сетевых</i> маршрутизаторов, то MPLS пред­полагает более серьезную модернизацию, чтобы маршрутизаторы могли читать метки и на­правлять пакеты по конкретным маршрутам.</p> <p>В настоящее время DiffServ пользуется более широким вниманием, и он ближе к окончательной стандартизации, чем MPLS. Однако каждая из технологий имеет свои пре­имущества в конкретных областях <b>сети</b>, поэтому поставщики, скорее всего, будут поддержи­вать их обе.</p> 5.10. Обеспечение качества IP-телефонии на базе MPLS - Часть 1 2011-08-19T00:06:00+04:00 2011-08-19T00:06:00+04:00 /books/ip-telephony/72-ip5/1071-5-10-obespechenie-kachestva-ip-telefonii-na-baze-mpls-chast-1 <p>Конкурентом DiffServ на роль протокола для обеспечения QoS является другой проект 1ETF под названием «Многопротокольная коммутация меток» (Multiprotocol Label Switching, MPLS).</p> <p>При IP-коммутации узел анализирует первые несколько пакетов поступающего трафи­ка и, в случае короткой посылки, например запроса DNS или SNMP, обрабатывает их как обычный маршрутизатор. Но если узел идентифицирует длительный поток - от трафика telnet или ftp до загрузки файлов через Web и мультимедийных приложений, то IP-коммутатор переключается на нижележащую структуру ATM и применяет сквозную комму­тацию для быстрой доставки данных адресату.</p> <p>IP-коммутация поддерживает различные уровни QoS и может использовать ATM, имеющий многочисленные встроенные средства поддержки QoS, и RSVP.</p> <p>Конкуренцию IP-коммутации составила тег-коммутация. Как видно из названия, данная технология предполагает присоединение к пакетам меток для информирования коммутаторов и маршрутизаторов о природе трафика. Не углубляясь в анализ пакета, устройства просто счи­тывают метку в заголовке для определения соответствующего маршрута потоку трафика.</p> <p>Если DiffServ задействует заголовок DS, уже имеющийся в пакетах IPv4, то MPLS ис­пользует 32-разрядную информационную метку, добавляемую к каждому IP-пакету. Эта мет­ка, добавляемая при входе в <b>сеть</b> с поддержкой MPLS, сообщает каждому маршрутизатору вдоль пути следования, как надо обрабатывать пакет. В частности, она содержит информа­цию о требуемом для данного пакета уровне QoS.</p> <p>В отличие от поля DS, метка MPLS изначально не является частью пакета IP. Скорее, она добавляется при поступлении пакета в <em>сеть</em> и удаляется при выходе пакета из <b>сети</b> MPLS.</p> <p>В обычной ситуации маршрутизаторы анализируют заголовок пакета для определения его адресата. Ввиду того, что такой анализ проводится на каждом транзитном узле независи­мо, предсказать, каким маршрутом будет следовать пакет, практически невозможно, поэтому обеспечение гарантированного уровня QoS оказывается невероятно сложной задачей.</p> <p>Конкурентом DiffServ на роль протокола для обеспечения QoS является другой проект 1ETF под названием «Многопротокольная коммутация меток» (Multiprotocol Label Switching, MPLS).</p> <p>При IP-коммутации узел анализирует первые несколько пакетов поступающего трафи­ка и, в случае короткой посылки, например запроса DNS или SNMP, обрабатывает их как обычный маршрутизатор. Но если узел идентифицирует длительный поток - от трафика telnet или ftp до загрузки файлов через Web и мультимедийных приложений, то IP-коммутатор переключается на нижележащую структуру ATM и применяет сквозную комму­тацию для быстрой доставки данных адресату.</p> <p>IP-коммутация поддерживает различные уровни QoS и может использовать ATM, имеющий многочисленные встроенные средства поддержки QoS, и RSVP.</p> <p>Конкуренцию IP-коммутации составила тег-коммутация. Как видно из названия, данная технология предполагает присоединение к пакетам меток для информирования коммутаторов и маршрутизаторов о природе трафика. Не углубляясь в анализ пакета, устройства просто счи­тывают метку в заголовке для определения соответствующего маршрута потоку трафика.</p> <p>Если DiffServ задействует заголовок DS, уже имеющийся в пакетах IPv4, то MPLS ис­пользует 32-разрядную информационную метку, добавляемую к каждому IP-пакету. Эта мет­ка, добавляемая при входе в <b>сеть</b> с поддержкой MPLS, сообщает каждому маршрутизатору вдоль пути следования, как надо обрабатывать пакет. В частности, она содержит информа­цию о требуемом для данного пакета уровне QoS.</p> <p>В отличие от поля DS, метка MPLS изначально не является частью пакета IP. Скорее, она добавляется при поступлении пакета в <em>сеть</em> и удаляется при выходе пакета из <b>сети</b> MPLS.</p> <p>В обычной ситуации маршрутизаторы анализируют заголовок пакета для определения его адресата. Ввиду того, что такой анализ проводится на каждом транзитном узле независи­мо, предсказать, каким маршрутом будет следовать пакет, практически невозможно, поэтому обеспечение гарантированного уровня QoS оказывается невероятно сложной задачей.</p> 5.9. Обеспечение качества IP-телефонии на базе дифференцированного обслуживания - Часть 2 2011-07-20T07:25:00+04:00 2011-07-20T07:25:00+04:00 /books/ip-telephony/72-ip5/1070-5-9-obespechenie-kachestva-ip-telefonii-na-baze-differencirovannogo-obsluzhivaniya-chast-2 <p>В настоящее время только 6 из 8 бит в поле DS были определены, и только одно на­значение было стандартизовано. Это назначение известно как принятое по умолчанию - Default (DE), - и оно определяет класс обслуживания по мере возможности. Другое предпо­лагаемое назначение, срочная отправка (Expedited Forwarding, EF), должно обеспечить со­кращение задержек и потерь пакетов.</p> <p>При поступлении трафика в <em>сеть</em> краевой маршрутизатор классифицирует график в соответствии с информацией, содержащейся в поле DS. Он передает следующим за ним маршрутизаторам эту информацию, на основании которой они узнают, каким образом обра­батывать данный конкретный поток.</p> <p>DiffServ, кроме того, сокращает служебный трафик по сравнению с RSVP и IntServ, опирающимися на сигнализацию из конца в конец. DiffServ классифицирует потоки в соот­ветствии с предопределенными правилами и затем объединяет однотипные потоки. Подоб­ный механизм делает DiffServ гораздо более масштабируемым, чем его предшественника IntServ. Весь трафик с одинаковыми метками рассматривается одинаковым образом, поэтому реализация DiffServ в <b>сети</b> крупного предприятия или по каналам глобальной <i>сети</i> оказыва­ется более реальной задачей.</p> <p>Как можно догадаться, преимущества DiffServ нельзя получить автоматически. Мар­шрутизаторы должны понимать «меченые потоки» и уметь соответствующим образом реаги­ровать на них. Это потребует модернизации микропрограммного обеспечения маршрутиза­торов. К счастью, с популяризацией DiffServ все большее число производителей намеревает­ся поддерживать данную архитектуру в будущих версиях своих продуктов.</p> <p></p> <p>В настоящее время только 6 из 8 бит в поле DS были определены, и только одно на­значение было стандартизовано. Это назначение известно как принятое по умолчанию - Default (DE), - и оно определяет класс обслуживания по мере возможности. Другое предпо­лагаемое назначение, срочная отправка (Expedited Forwarding, EF), должно обеспечить со­кращение задержек и потерь пакетов.</p> <p>При поступлении трафика в <em>сеть</em> краевой маршрутизатор классифицирует график в соответствии с информацией, содержащейся в поле DS. Он передает следующим за ним маршрутизаторам эту информацию, на основании которой они узнают, каким образом обра­батывать данный конкретный поток.</p> <p>DiffServ, кроме того, сокращает служебный трафик по сравнению с RSVP и IntServ, опирающимися на сигнализацию из конца в конец. DiffServ классифицирует потоки в соот­ветствии с предопределенными правилами и затем объединяет однотипные потоки. Подоб­ный механизм делает DiffServ гораздо более масштабируемым, чем его предшественника IntServ. Весь трафик с одинаковыми метками рассматривается одинаковым образом, поэтому реализация DiffServ в <b>сети</b> крупного предприятия или по каналам глобальной <i>сети</i> оказыва­ется более реальной задачей.</p> <p>Как можно догадаться, преимущества DiffServ нельзя получить автоматически. Мар­шрутизаторы должны понимать «меченые потоки» и уметь соответствующим образом реаги­ровать на них. Это потребует модернизации микропрограммного обеспечения маршрутиза­торов. К счастью, с популяризацией DiffServ все большее число производителей намеревает­ся поддерживать данную архитектуру в будущих версиях своих продуктов.</p> <p></p>