Мини-Сервер своими руками - это просто! - IP телефония/books/ip-telephony/72-ip52021-06-25T01:39:43+03:00Мини-Серверsinglwolf@mini-server.ruJoomla! - Open Source Content Management5.13. Организационные аспекты обеспечения параметров качества IP-телефонии - Часть 22011-12-02T02:00:00+04:002011-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-телефонии - Часть 12011-12-01T21:21:00+04:002011-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-телефонии с помощью механизма управления на основе правил - Часть 32011-11-19T01:55:00+04:002011-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-телефонии с помощью механизма управления на основе правил - Часть 22011-11-04T02:50:00+04:002011-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-телефонии с помощью механизма управления на основе правил - Часть 12011-10-01T12:07:00+04:002011-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») преобразуются в структурированный набор правил вида «если <условие>, то <реакция>», который хранится в базе администратора, извлекается и интерпретируется различными сетевыми компонентами. Заметим, что системы первого поколения не могли сами интерпретировать высокоуровневые формулировки, а требовали от администратора формализованных условных операторов вида «если порт = 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») преобразуются в структурированный набор правил вида «если <условие>, то <реакция>», который хранится в базе администратора, извлекается и интерпретируется различными сетевыми компонентами. Заметим, что системы первого поколения не могли сами интерпретировать высокоуровневые формулировки, а требовали от администратора формализованных условных операторов вида «если порт = 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:002011-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 - Часть 32011-09-23T05:38:00+04:002011-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 - Часть 22011-08-31T17:39:00+04:002011-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 - Часть 12011-08-19T00:06:00+04:002011-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-телефонии на базе дифференцированного обслуживания - Часть 22011-07-20T07:25:00+04:002011-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>