ПРИМЕНЕНИЕ НИЗКОСКОРОСТНЫХ ЛИНИЙ СВЯЗИ ДЛЯ ОБЕСПЕЧЕНИЯ ГОЛОСОВОГО ТРАФИКА CISCO 1750S

В связи с развитием IP-телефонии перед Internet провайдерами в новом качестве встала старая задача: как обеспечить трафик? Последние публикации рассматривают широкий круг вопросов, связанных с обеспечением Internet-телефонии, касающихся новых протоколов обеспечения качества, внедрения нового оборудования и т.д. Но в основном в этих публикациях указаны скорости порядка 2 Mbps или как минимум 64 Kbps.

Второй вопрос - какую аппаратуру применять? Предлагаемое на рынке специализированное оборудование и программно-аппаратные комплексы обладают широким спектром реализуемых возможностей, но, как правило, и значительную цену, не позволяющую использовать их на малых Internet-узлах.

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

Руководствуясь этими вопросами, в нашем предприятии было принято решение о проведении опытных работ, результаты которых представлены ниже.

Ставились следующие задачи:

• Какие каналы могут обеспечить передачу голосового трафика?
• Какое оборудование оптимально для описанных задач в малых Internet-узлах?
• Какие могут быть ограничения по топологии Internet-узла.

При выборе оборудования основными приняты следующие критерии: низкая стоимость, способность к совместной работе с наибольшим числом имеющихся провайдеров, а также возможность получения дополнительных выгод, не связанных с Internet-телефонией. В результате нашим выбором стал модульный маршрутизатор Cisco 1750, относительно недавно появившийся на рынке. Из недостатков этого маршрутизатора можно отметить то, что он обладает слабым процессором, ограничивающим использование этой модели в режимах, требующих большого объема сложных операций. Так, например, применение на интерфейсе PPP multilink вместо простого PPP увеличивает время ping примерно на 40 msc, что, на наш взгляд, недопустимо много. Но работать в различных режимах маршрутизации с выходом на низкоскоростные линии ему, безусловно, под силу.

Более серьезным недостатком, связанным, по-видимому, также со слабым процессором, является отсутствие в этой модели кодека g723. Имеющийся кодек g729r8 обеспечивает оцифровку звука с выходным потоком 8 Kbps, что с учетом размера RTP пакета по умолчанию 20 байт и размером всех заголовков (IP,UDP и RTP), вызывает сетевой трафик 24 Kbps. Эта цифра и указана в фирменной документации "VoIP configuration", как основа для расчета полосы пропускания при применении кодека g729.

Первым этапом опытных работ было определение возможностей голосовой связи Cisco-Cisco. В этой конфигурации обеспечивается прекрасное качество при двух одновременных голосовых соединениях на скорости 19 Kbps. В этом случае может использоваться как асинхронное, так и синхронное соединение, но обязательное условие - упаковка RTP заголовков. При некоторых дополнительных ухищрениях два голосовых соединения со скрипом могут проходить и по 14 Kbps.

Если прямое соединение Cisco-Cisco невозможно осуществить на практике, то с одной стороны линии обычно уже установлен UNIX сервер. Для этого случая прорабатывались возможности связи Cisco-Linux. При этом мы наткнулись на непредвиденное затруднение - необъяснимое периодическое взаимонепонимание Linux PPP демона и Cisco 1750. Это проявлялось в том, что каждый второй пакет от Cisco поступал с большой (более 2 сек) задержкой. Это оказалось справедливо для всех видов трафика- как при ping, так и при telnet или HTTP. Аналогичные опыты связи SCO Open Server-Cisco 1750 дали такой же результат. Анализ работы демона и ядра Linux позволил локализовать причину и устранить ее путем изменения исходных текстов и перекомпиляцией ядра Linux. Вопрос работоспособности PPP соединения Cisco 1750 с другими операционными системами остается открытым.

Также встретились определенные затруднения при объединении несколько каналов. Cisco 1750, как и другие модели может решать эту задачу на уровне маршрутизации, распределяя нагрузку равномерно между несколькими путями маршрутизации. С другой стороны, Linux предоставляет объединение последовательных каналов тремя способами: на уровне устройств - организацией последовательного псевдоустройства eql, на уровне сетевых интерфейсов - организацией псевдоустройства teql и на уровне маршрутизации - организацией эквализированных путей в таблице. Объединение на уровне устройств к сожалению не применимо, т.к. для предотвращения порчи пакетов из-за нарушения порядка следования фрагментов по объединенным каналам принимающей стороной должно быть такое же псевдоустройство. При объединении каналов на уровне таблицы маршрутизации, решение о направлении пакетов принимается при начале связного трафика, таким образом, все пакеты, к примеру, от одного ping-a пойдут только по одному каналу. В этом случае равномерное распределение нагрузки возможно только при большом числе соединений небольшой интенсивности. Объединение на уровне сетевых интерфейсов, казалось, должно было отвечать всем необходимым требованиям, так как решение о выборе пути принимается для каждого пакета независимо от источника и цели. Но и здесь выяснилось затруднение, которое оказалось возможным решить только изменением текстов модуля ядра. Причем, из последующей переписки с автором текстов (это наш соотечественник Алексей Кузнецов) выяснилось, что он и не ставил целью добиваться равномерного распределения. Тем не менее, соединение Cisco-Linux по объединенным каналам с равномерным распределением нагрузки опробовано для нужд Internet и передачи голоса. Подобное соединение не сказывается на задержке ping-a, но улучшает качество передачи голоса и уменьшает задержки слов.

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

При работе по низкоскоростным (менее 64 Kbps) линиям важное значение для обеспечения качества передаваемого голоса имеет фрагментация крупных пакетов.Так, при поступлении пакета размером 1500 байт, что равно стандартному для большинства сетей MTU, нам необходимо передать 12Kbit, что при скорости в 24Kbps потребует 500 msc. Эта задержка недопустима для следующего RTP пакета.

Стандартный для Cisco механизм фрагментации пакетов - это PPP Multilink. Применения этого механизма считается неотъемлемым условием при передаче трафика реального времени. Но тут имеются свои подводные камни. Во-первых - достаточно большое время восстановления коннекции после разрыва связи по сравнению с HDLC. Во-вторых - снижение пропускной способности одного канала автоматически снижает пропускную способность следующего.

При передаче голоса дополнительно встает вопрос о приоритетах для голосового трафика. Cisco поддерживает различные конфигурации очередей для обеспечения качества сервиса (QoS) и резервирования полосы пропускания. Различное изменение этих параметров позволяет получать некоторое улучшение качества голоса. Ping-f в любом случае сделает невозможной сколько либо разборчивую голосовую связь. Причина слабого влияния настроек на качество голоса по низкоскоростному каналу видимо в том, что резервировать для голоса приходится большую часть от всей пропускной способности и в этом случае обычный трафик оказывается почти полностью зажатым, что не предусматривается применяемыми алгоритмами. К тому же, продекларированный на интерфейсе bandwidth может не обеспечиваться из-за ухудшившегося качества связи, поэтому очереди в этом случае не смогут правильно управляться. Более надежный аппарат - приоритетные очереди, дающие наиболее жесткие привилегии для голосового трафика независимо от состояния канала. Необходимо сказать, что из команд конфигурирования качества сервиса в Cisco 1750 поддерживаются далеко не все.

Поддержка качества сервиса в Linux продекларирована на уровне ядра достаточно полно. Но механизм организации и управления специализированными очередями находится еще в стадии разработки. Нами были опробованы только "Очереди, базирующиеся на классах" (cbq) и "Очереди с обработкой приоритетов". На некоторые вопросы удалось получить ответы у автора текстов, но здесь пока еще больше вопросов, чем ответов, поэтому придется опять обращаться к переделке текстов.

Дополнительные выгоды от применения модульных маршрутизаторов Cisco достаточно общеизвестны - простота конфигурирования различных связных интерфейсов, поддержка многих сетевых протоколов и т.д. Как дополнительную выгоду для описываемых линий связи можно прежде всего указать упаковку TCP заголовков, дающую по нашей статистике коэффициент использования каждого канала 1,2 - 1,3, что говорит о достаточно большом проценте использования коротких TCP пакетов. Временные затраты на реализацию алгоритма упаковки сказываются, видимо, при большом числе одновременных соединений и не проявляются на низкоскоростных линиях.

Общие выводы:

• эффективное использование низкоскоростных линий для передачи голосового трафика возможно только с применением упаковки заголовков т.к. эффект от этого перевешивает все остальные возможности;
• объединение линий возможно как при связи Cisco-Cisco, так и при связи Cisco-Linux с равномерным распределением нагрузки;
• возможны некоторые различия в реализации PPP, что приводит к нарушению работоспособности при некоторых комбинациях моделей Cisco и версий PPP различных операционных систем;
• использование соединений Cisco-Linux для обеспечения голосовых соединений по низкоскоростным линиям невозможно пока в Linux нет совместимой с Cisco реализации упаковки RTP заголовков;
• при всех видах инкапсуляций невозможно реализовать приоритеты для трафика реального времени на низкоскоростных линиях, обеспечивающие его полную независимость от неприоритетных видов трафика без разбивки крупных пакетов - на фрагменты;
• необходим механизм, аналогичный PPP Multilink для разбивки крупных пакетов на фрагменты при использовании инкапсуляций других видов;
• желательно динамическое изменение весов объединенных каналов, а также настроек приоритетов и качества сервиса при изменении пропускной способности каналов.

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

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

Ведущий специалист ЗАО "Рубцовск" К. Кржеменевский

Доклад на Всероссийском семинаре по IP-телефонии.