Глава 5

ОБЕСПЕЧЕНИЕ КАЧЕСТВА IР-ТЕЛЕФОНИИ

5.1. Показатели качества IP-телефонии

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

Сети с коммутацией пакетов не обеспечивают гарантированной пропускной способности, поскольку не обеспечивают гарантированного пути между точками связи.

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

Основными составляющими качества IP -телефонии являются (рис. 5.1):

• Качество речи, которое включает:

— диалог — возможность пользователя связываться и разговаривать с другим пользователем в реальном времени и полнодуплексном режиме;

— разборчивость — чистота и тональность речи;

— эхо — слышимость собственной речи;

— уровень — громкость речи.

• Качество сигнализации, включающее:

— установление вызова — скорость успешного доступа и время установления соединения;

— завершение вызова — время отбоя и скорость разъединения;

— DTMF — определение и фиксация сигналов многочастотного набора номера. Факторы, которые влияют на качество IP-телефонии, могут быть разделены на две категории:

• Факторы качества IP-сети:

— максимальная пропускная способность — максимальное количество полезных и избыточных данных, которая она передает;

— задержка — промежуток времени, требуемый для передачи пакета через сеть;

— джиттер — задержка между двумя последовательными пакетами;

— потеря пакета — пакеты или данные, потерянные при передаче через сеть.

• Факторы качества шлюза:

-требуемая полоса пропускания — различные вокодеры требуют различную полосу. Например, вокодер G.723 требует полосы 16,3 кбит/с для каждого речевого канала; задержка — время, необходимое цифровому сигнальному процессору DSP или другим устройствам обработки для кодирования и декодирования речевого сигнала;

-буфер джиттера — сохранение пакетов данных до тех пор, пока все пакеты не будут получены и можно будет передать в требуемой последовательности для минимизации джиттера;

потеря пакетов — потеря пакетов при сжатии и/или передаче в оборудовании IP- телефонии;

-подавление эхо — механизм для подавления эхо, возникающего при передаче по сети; - управление уровнем — возможность регулировать громкость речи.

5.2. Влияние сети на показатели качества IP-телефонии

Задержка

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

Затруднение диалога и перекрытие разговоров становятся серьезным вопросом, когда задержка в одном направлении передачи превышает 250 мс. Можно выделив следующие источники задержки при пакетной передачи речи из конца в конец (рис. 5.2).

• Задержка накопления (иногда называется алгоритмической задержкой): эта задержки обусловлена необходимостью сбора кадра речевых отсчетов, выполняемая в речевой кодере. Величина задержки определяется типом речевого кодера и изменяется от нс. больших величин (0,125 мкс) до нескольких миллисекунд. Например, стандартные речевые кодеры имеют следующие длительности кадров:

G.729 CS-ACELP (8 кбит/с) — 10 мс G.723.1 Multi Rate Coder (5,3; 6,3 кбит/с) — 30 мс. •Задержка обработки: процесс кодирования и сбора закодированных отсчетов в пакеты для передачи через пакетную сеть создает определенные задержки. Задержка кодирования или обработки зависит от времени работы процессора и используемого типа алгоритма обработки. Для уменьшения загрузки пакетной сети обычно несколько кедров речевого кодера объединяются в один пакет. Например, три кадра кодовых слов G.729, соответствующих 30 мс речи, могут быть объединены для уменьшения размера одного пакета.

•Сетевая задержка: задержка обусловлена физической средой и протоколами, используемыми для передачи речевых данных, а также буферами, используемыми для удаления джиггера пакетов на приемном конце. Сетевая задержка зависит от емкости сети и процессов передачи пакетов в сети.

Время задержки при передаче речевого сигнала можно отнести к одному из трех уровней:

первый уровень до 200 мс — отличное качество связи. Для сравнения, в телефонной сети общего пользования допустимы задержки до 150-200 мс;

второй уровень до 400 мс — считается хорошим качеством связи. Но если сравнивать с качеством связи по сетям ТфОП, то разница будет видна. Если задержки постоянно удерживается на верхней границе 2-го уровня (на 400 мс), то не рекомендуется использовать эту связь для деловых переговоров;

третий уровень до 700 мс — считается приемлемым качеством связи для ведения неделовых переговоров. Такое качество связи возможно также при передаче пакетов по спутниковой связи.

Качество Интернет-телефонии попадает под 2-3 уровни, причем невозможно уверенно сказать, что тот или иной провайдер Интернет-телефонии работает по второму уровню, так как задержки в сети Интернет изменчивы. Более точно можно сказать о провайдерах IP-телефонии, работающих по выделенным каналам. Они попадают под 1-2 уровни. Также необходимо учитывать задержки при кодировании/декодировании голосового сигнала. Средние суммарные выдержки при использовании IP-телефонии обычно находятся в пределах 150-250 мс.

В сети Интернет задержки пакетов существенно зависят от времени. Кривая этой зависимости имеет большой динамический диапазон и скорость изменения. Заметные изменения времени распространения могут произойти на протяжении одного непродолжительного сеанса связи, а колебания времени передачи могут быть в диапазоне от десятков до сотен миллисекунд и даже превышать секунду.

Важно отметить тот факт, что задержки в сетях с коммутацией пакетов влияют не только на качество передачи речевого трафика в реальном времени. Не менее важно и то, что ванные задержки в определенных ситуациях могут нарушить правильность функционирования телефонной сигнализации в цифровых трактах El/Tl на стыке голосовых шлюзов с оборудованием коммутируемых телефонных сетей. Причиной этого можно назвать тот факт, что набор рекомендаций Н.323 в момент своего появления в 1997 г. был ориентирован на Мультимедийные приложения, осуществляющие аудио и видеоконференцсвязь через сети IP. Данное решение позволяло значительно снизить стоимость таких систем по сравнению с их аналогами, работающими в сетях традиционной телефонии с коммутацией каналов. В процессе выделения IP-телефонии в самостоятельное направление и развития ее до услуги операторского уровня возникла необходимость соединения IP-шлюзов с телефонными станциями ТфОП по цифровым трактам El/Tl. При этом, шлюзы осуществляют взаимодействие с цифровыми АТС, используя стандартные механизмы телефонной сигнализации Q.931, интерпретированные через команды Н.225 и транслируемые в IP-сети с использованием протокола ТСР. Согласно рекомендации Q.931, при установлении телефонного соединения значения временных задержек между фазами выполнения команд сигнализации строго регламентированы. Однако, при интерпретации в IP-шлюзах команд телефонной сигнализации Q.931 стеком Н.225/ТСР/1Р, задержки, возникшие на пути прохождения сигнала, увеличивают заданные временные интервалы между командами ф931, и в большинстве случаев нарушают целостность функционирования данного протокола. Хотя версия 2 набора рекомендаций Н.323 в фазе 2 предусматривает процедуру Н.323ч2 Fast Connect, ускоряющую обработку команд Q.931 стеком Н.225/ТСР, задержки IP-канала, особенно характерные для инфраструктуры Интернет, могут заведомо превышать все допустимые значения временных интервалов протокола ф931. Данное обстоятельство можно расценивать как еще один аргумент в пользу использования выделенных каналов при построении сетей IP-телефонии.

Джиттер

Когда речь или данные разбиваются на пакеты для передачи через IP-сеть, пакеты часто прибывают в пункт назначения в различное время и в разной последовательности. Это создает разброс времени доставки пакетов (джиттер). Джиттер приводит к специфическим нарушениям передачи речи, слышимым как трески и щелчки. Различают три формы джиттера:

1. джиттер, зависимый от данных (Data Dependent Jitter — DDJ) — происходит в случае ограниченной полосы пропускания или при нарушениях в сетевых;

2. искажение рабочего цикла (Duty Cycle Distortion — DCD) — обусловлено задержкой распространения между передачей снизу вверх и сверху вниз;

3. случайный джиттер (Random Jitter — RJ) — является результатом теплового шума. На рис. 5.3 приведены гистограммы джиттера пакетов в локальной сети и в сети Интернет с различными скоростями работы, показывающие эмпирические распределения вероятностей задержек. На оси абсцисс отложена относительная задержка, характеризующая реальное положение пакета в последовательности на временной оси по отношению к идем ному в предположении, что первый пакет пришел без задержки.

Рис. 5.3. Гистограммы джиттера пакетов

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

Потеря пакетов

Потерянные пакеты в IP-телефонии нарушают речь и создают искажения тембра существующих IP-сетях все голосовые кадры обрабатываются как данные. При пиковых

грузках и перегрузках голосовые кадры будут отбрасываться, как и кадры данных. Однако кадры данных не связаны со временем и отброшенные пакеты могут быть успешно переданы путем повторения. Потеря голосовых пакетов, в свою очередь, не может быть восполнена

таким способом и в результате произойдет неполная передача информации. Предполагается, что потеря до 5% пакетов незаметна, а свыше 10-15% — недопустима. Причем данные величины существенно зависят от алгоритмов компрессии/декомпрессии.

На рис. 5.4 представлены гистограммы потерь пакетов. По оси абсцисс отложено подряд потерянных пакетов. Анализ гистограммы показывает, что наиболее вероятны потери одного, двух и трех пакетов. Потери больших пачек пакетов редки.

Существенно, что потеря большой группы пакетов приводит к необратимым локальным искажениям речи, тогда как потери одного, двух, трех пакетов можно пытаться компенсировать.

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

Взаимосвязь методов обеспечения качества IP-телефонии, показателей качества сети и качества вызова представлена на рис. 5.5.

5.3. Процедуры обработки речи в IP-телефонии

Для обеспечения качественной передачи речевых сигналов в IP-телефонии необходима их следующая обработка.

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

Эффективное эхоподавления и уменьшение шумов абсолютно необходимо в любой конфигурации с «открытым микрофоном» и с громкоговорителем на базе персонального компьютера (ПК) для традиционной и IP-телефонии. Эти функции все в большей мере реализуются аудиокомпонентами ПК, так что сама система IP-телефонии может их и не иметь. Шлюзам IP-телефонии требуется выполнять меньший объем предварительной обработки, нежели конечным решениям, потому что МАТС и телефонная сеть обеспечивают фильтрацию и уменьшение шумов.

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

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

4. «Нарезание» сжатых голосовых данных на короткие сегменты равной длины, их нумерация по порядку, добавление заголовков пакетов и передача. Хотя стек протоколов ТСР/IP поддерживает пакеты переменной длины, их использование затрудняет достижение устойчивой и предсказуемой межсетевой маршрутизации в голосовых приложениях. Маршрутизаторы быстро обрабатывают небольшие пакеты и рассматривают обычно все передаваемые по одному и тому же IP-адресу пакеты одного размера одинаковым образом. В результате пакеты проходят по одному маршруту, поэтому их не надо переупорядочивать.

5. Прием и переупорядочивание пакетов в адаптивном «буфере ресинхронизации» для обеспечения интеллектуальной обработки потерь или задержек пакетов. Главной целью здесь является преодоление влияния переменной задержки между пакетами. Решение этой проблемы состоит в буферизации достаточного числа поступающих пакетов (при отложенном их воспроизведении) с тем, чтобы воспроизведение было непрерывным, даже если время между поступлением пакетов сильно разнится. Лучшие продукты для IP-телефонии моделируют производительность сети и регулируют размер буфера ресинхронизации соответствующим образом — уменьшая его (сокращая задержку перед воспроизведением), когда сеть ведет себя предсказуемым образом, и увеличивая в противоположной ситуации.

5.4. Методы кодирования речевой информации

Одним из важных факторов эффективного использования пропускной способности IP- канала, является выбор оптимального алгоритма кодирования/декодирования речевой ин- формации — кодека.

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

1. Кодеки с импульсно-кодовой модуляцией (ИКМ) и адаптивной дифференциальной

импульсно-кодовой модуляцией (АДИКМ), появившиеся в конце 50-х годов и использующиеся сегодня в системах традиционной телефонии. В большинстве случаев, представляют собой сочетание АЦП/ЦАП.

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

3. Комбинированные (гибридные) кодеки сочетают в себе технологию вокодерного преобразования/синтеза речи, но оперируют уже с цифровым сигналом посредством специализированных DSP. Кодеки этого типа содержат в себе ИКМ или АДИКМ кодек и реализованный цифровым способом вокодер.

На рис. 5.6 представлена усредненная субъективная оценка качества кодирования речи для вышеперечисленных типов кодеков.

В голосовых шлюзах IP-телефонии понятие кодека подразумевает не только алгоритма кодирования/декодирования, но и их аппаратную реализацию. Большинство кодеков, используемых в Ip-телефонии, описаны рекомендациями семейства ((G» стандарта Н.323 (рис. 5.7).

Все методы кодирования, основанные на определенных предположениях о форме сигнала, не подходят при передаче сигнала с резкими скачками амплитуды. Именно такой вид имеет сигнал, генерируемый модемами или факсимильными аппаратами, поэтому аппаратура, поддерживающая сжатие, должна автоматически распознавать сигналы факс-аппаратов и модемов и обрабатывать их иначе, чем голосовой трафик. Многие методы кодирования берут свое начало от метода кодирования с линейным предсказанием LPC (Linear Predictive Coding). В качестве входного сигнала в LPC используется последовательность цифровых значений амплитуды, но алгоритм кодирования применяется не к отдельным цифровым значениям, а к определенным их блокам. Для каждого такого блока значений вычисляются его характерные параметры: частота, амплитуда и ряд других. Именно эти значения и передаются по сети. При таком подходе к кодированию речи, во-первых, возрастают требования к вычислительным мощностям специализированных процессоров, используемых для обработки сигнала, а во-вторых, увеличивается задержка при передаче, поскольку кодирование применяется не к отдельным значениям, а к некоторому их набору, который перед началом преобразования следует накопить в определенном буфере.

Важно, что задержка в передаче речи связана не только с необходимостью обработки цифрового сигнала (эту задержку можно уменьшать, увеличивая мощность процессора), но и непосредственно с характером метода сжатия. Метод кодирования с линейным предсказанием LPC позволяет достигать очень больших степеней сжатия, которым соответствует полоса пропускания 2,4 или 4,8 кбит/с, однако качество звука здесь сильно страдает. Поэтому в коммерческих приложениях он не используется, а применяется в основном для ведения служебных переговоров. Более сложные методы сжатия речи основаны на применении LPC в сочетании с элементами кодирования формы сигнала. В этих алгоритмах используется кодирование с обратной связью, когда при передаче сигнала осуществляется оптимизация кода. Закодировав сигнал, процессор пытается восстановить его форму и сличает результат с исходным сигналом, после чего начинает варьировать параметры кодировки, добиваясь наилучшего совпадения. Достигнув такого совпадения, аппаратура передает полученный код по линиям связи; на противоположном конце происходит восстановление звукового сигнала. Ясно, что для использования такого метода требуются еще более серьезные вычислительные мощности.

Одной из самых распространенных разновидностей описанного метода кодирования является метод LD CELP (Low-Delay Code-Excited Linear Prediction). Он позволяет достичь удовлетворительного качества воспроизведения при пропускной способности 16 кбит/с. Алгоритм применяется к последовательности цифр, получаемых в результате аналого- цифрового преобразования голосового сигнала с 16-разрядным разрешением. Пять последовательных цифровых значений кодируются одним 10-битовым блоком — это и дает те самые 16 кбит/с. Для применения этого метода требуются большие вычислительные мощности; в частности, в марте 1995 г. ITU принял новый стандарт — G.723, который предполагается использовать при сжатии речи для организации видеоконференций по телефонным сетям. Этот стандарт представляет собой часть более общего стандарта Н.324, описывающего подход к организации таких видеоконференций. Цель — организация видеоконференций с использованием обычных модемов. Основой О.723 является метод сжатия речи MP-MLQ (Multipulse Maximum Likelihood Quantization). Он позволяет добиться весьма существенного сжатия речи при сохранении достаточно высокого качества звучания. В основе метода лежит описанная выше процедура оптимизации; с помощью различных усовершенствований можно сжимать речь до уровня 4,8; 6,4; 7,2 и 8,0 кбит/с. Структура алгоритма позволяет на основе программного обеспечения изменять степень сжатия голоса в ходе передачи. Вносимая кодированием задержка не превышает 20 мс. Повышая эффективность использования полосы пропускания, механизмы сжатия речи в то же время могут привести к ухудшению ее качества и увеличению задержек.

Далее рассмотрены некоторые основные кодеки, используемые в шлюзах IP. телефонии операторского уровня.

Кодек G.711

Рекомендация G.711, утвержденная МККТТ в 1984 г., описывает кодек, использующий ИКМ преобразование аналогового сигнала с точностью 8 бит, тактовой частотой 8 кГц и простейшей компрессией амплитуды сигнала. Скорость потока данных на выходе преобразователя составляет 64 кбит/с (8 битх8 кГц). Для снижения шума квантования и улучшении преобразования сигналов с небольшой амплитудой при кодировании используется нелинейное квантование по уровню (рис. 5.8) согласно специальному псевдо-логарифмическому закону: А-закон для европейской системы ИКМ-30/32 или ц- закон для североамериканской системы ИКМ-24.

Первые ИКМ кодеки с нелинейным квантованием появились уже в 60-х годах. Кодеки G.711 широко распространен в системах традиционной телефонии с коммутацией каналов, Несмотря на то, что рекомендация G.711 в стандарте Н.323 является основной и первичной, в шлюзах IP-телефонии данный кодек применяется редко из-за высоких требований к полосе пропускания и задержкам в канале передачи (все-таки 64 кбит/с это много). Использование G.711 в системах IP-телефонии обосновано лишь в тех случаях, когда требуется обеспечить максимальное качество кодирования речевой информации при небольшом числе одновременных разговоров. Одним из примеров применения кодека G.711 могут послужить IP- телефоны компании Cisco.

Кодек G.726

Один из старейших алгоритмов сжатия речи ADPCM — адаптивная дифференциальная ИКМ (стандарт G.726 был принят в 1984 г.). Этот алгоритм дает практически такое же качество воспроизведения речи, как и ИКМ, однако для передачи информации при его использовании требуется полоса всего в 16-32 кбит/с. Метод основан на том, что в аналоговом сигнал передающем речь, невозможны резкие скачки интенсивности. Поэтому, если кодировать не саму амплитуду сигнала, а ее изменение по сравнению с предыдущим значением, то можно обойтись меньшим числом разрядов. В ADPCM изменение уровня сигнала кодируется четырехразрядным числом, при этом частота измерения амплитуды сигнала сохраняется неизменной. Процесс преобразования не вносит существенной задержки и требует от DSP 5,5- 6,4 MIPS (Million Instructions Per Second). Кодек может применяться совместно с кодеком G.711 для снижения скорости кодирования последнего. Кодек предназначен для использования в системах видеоконференций.

Кодек G.723.1

Рекомендация G.723.1 описывает гибридные кодеки, использующие технологию кодирования речевой информации, сокращенно называемую — MP-MLQ (Multy-Pulse — Multy Level quantization — множественная импульсная, многоуровневая квантизация), данные кодеки можно охарактеризовать, как комбинацию АЦП/ЦАП и вокодера. Своим возникновением гибридные кодеки обязаны системам мобильной связи. Применение вокодера позволяет снизить скорость передачи данных в канале, что принципиально важно для эффективного использования рялиотракта и IP-канала. Основной принцип работы вокодера — синтез исходного речевого сигнала посредством адаптивной замены его гармонических составляющих соответствующим набором частотных фонем и согласованными шумовыми коэффициентами. Кодек О.723 осуществляет преобразование аналогового сигнала в поток данных со скоростью 64 кбит/с (ИКМ), а затем при помощи многополосного цифрового фильтра/вокодера выделяет частотные фонемы, анализирует их и передает по IP-каналу информацию только о текущем состоянии фонем в речевом сигнале. Данный алгоритм преобразования позволяет снизить скорость кодированной информации до 5,3-6,3 кбит/с без видимого ухудшения качества речи. Кодек имеет две скорости и два варианта кодирования: 6,3 кбит/с с алгоритмом MP-MLQ и 5,3 кбит/с с алгоритмом CELP. Первый вариант предназначен для сетей с пакетной передачей голоса и обеспечивает лучшее качество кодирования по сравнению с вариантом CELP, но менее адаптирован к использованию в сетях со смешанным типом трафика (голос/данные).

Процесс преобразования требует от DSP 16,4-16,7 MIPS и вносит задержку 37 мс. Ко Лен G.723.1 широко применяется в голосовых шлюзах и прочих устройствах IP-телефони

и. Кодек уступает по качеству кодирования речи кодеку G.729а, но менее требователен к ресурсам процессора и пропускной способности канала.

Кодеки G.729

Семейство включает кодеки G.729, G.729 Аппех А, G.729 Аппех В (содержит VAD , и генератор комфортного шума). Кодеки G.729 сокращенно называют CS-ACELP Conjugate Structure — Algebraic Code Excited Linear Prediction — сопряженная структура с управляемым алгебраическим кодом линейным предсказанием. Процесс преобразования "использует DSP 21,5 MIPS и вносит задержку 15 мс. Скорость кодированного речевого сигнала составляет 8 кбит/с. В устройствах VoIP данный кодек занимает лидирующее положение, обеспечивая наилучшее качество кодирования речевой информации при достаточно высокой компрессии.

Кодек G.728

Гибридный кодек, описанный в рекомендации G.728 в 1992 г. относится к категории LD-CELP — Low Delay — Соде Excited Linear Prediction — кодек с управляемым кодом линейным предсказанием и малой задержкой. Кодек обеспечивает скорость преобразована 16 кбит/с, вносит задержку при кодировании от 3 до 5 мс и для реализации необходим процессор с быстродействием более 40 MIPS. Кодек предназначен для использования, в основном, в системах видеоконференций. В устройствах IP-телефонии данный кодек применяется достаточно редко.

Основные характеристики рассмотренных кодеков приведены в табл., 5.1

Количественными характеристиками ухудшения качества речи являются единицы QDU (Quantization Distortion Units): 1 QDU соответствует ухудшению качества при оцифровке с использованием стандартной процедуры ИКМ; значения QDU для основных методов компрессии приведены в табл. 5.2.

Дополнительная обработка речи всегда ведет к дальнейшей потере качества. Согласно рекомендациям МСЭ-Т, для международных вызовов величина QDU не должна превышать 14, причем передача разговора по международным магистральным каналам ухудшает качество речи, как правило, на 4 QDU. Следовательно, при передаче разговора по национальным сетям должно теряться не более 5 QDU. Поэтому для качественной передачи речи процедуру компрессии/декомпрессии желательно применять в сети только один раз. В некоторых странах это является обязательным требованием регулирующих органов по отношению к корпоративным сетям, подключенным к сетям общего пользования. Подавление пауз (silence suppression) — важная функция АТМ-коммутаторов. Суть технологии подавления пауз заключается в определении различия между моментами активной речи и молчания в период. В результате применения этой технологии генерация ячеек происходит только в активного разговора. Поскольку в процессе типичного разговора по телефону тишина составляет до 60% времени, происходит двукратная оптимизация по количеству данных, должны быть переданы по линии. Объединение технологии сжатия речи и подавления пауз речи в коммутаторах приводит к уменьшению потока данных в канале до восьми раз.

Современные продукты для IP-телефонии применяют самые разные кодеки, стандартные и нестандартные. Конкурентами являются кодеки GSM (13,5 кбит/с) и кодеки МСЭ-Т серии G, использование которых предусматривается стандартом Н.323 для связи по IP-сети. Единственным обязательным для применения кодеком в Н.323-совместимых продуктах остается стандарт G.711: выдаваемые им массивы данных составляют от 56 до 64 кбит/с. В качестве дополнительных высокопроизводительных кодеков стандарт Н.323 рекомендует G.723 и G,729 — последние способны сжимать оцифрованную 16-разрядную ИКМ- речь длительностью 10 мс всего в 10 байт. Стандарт G.729 уже получил широкое распространение в передачи голоса по IP; его поддерживают значительное число производителей продуктов для IP-телефонии.

5.5. Комплексная оценка качества IP-телефонии

Искажения от компрессии/декомпрессии оценивают путем опроса разных групп людей по пятибалльной шкале единицами субъективной оценки MOS (Mean Opinion Score). Оценки 3,5 баллов и выше соответствуют стандартному и высокому телефонному качеству, 3,0...3,5 — приемлемому, 2,5...3,0 — синтезированному звуку. Для передачи речи с хорошим 'качеством целесообразно ориентироваться на MOS не ниже 3,5 баллов. Значения MOS для 'наличных стандартов кодеров приведены в табл. 5.3.

Несмотря на большое разнообразие, характеризуемое пропускными способностями, числом маршрутизаторов, характеристиками физических линий и прочими характеристиками, реально действующие каналы Интернет характеризуются следующими параметрами:

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

• трафиком, также являющимся функцией времени;

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

• потерей пакетов, обусловленной наличием «узких мест», очередями;

• перестановкой пакетов, пришедших разными путями.

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

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

5.6. Обеспечение качества IP-телефонии на базе протокола RSYP

Одним из средств обеспечения качества IP-телефонии и особенно Интернет-телефонии является использование протокола резервирования ресурсов (Resource Reservation Protocol, RSVP), рекомендованного комитетом IETF. С помощью PSVP мультимедиа-программы мо- гут потребовать специального качества обслуживания (specific Quality of service, ЯОБ) по- средством любого из существующих сетевых протоколов — главным образом IP, хотя воз- можно использовать и UDP — чтобы обеспечить качественную передачу видео- и аудиосигналов. Протокол RSVP предусматривает гарантированное QoS благодаря тому, что через каждый компьютер, или узел, который связывает между собой участников телефонного разговора, может передаваться определенное количество данных.

Протокол RSVP предназначен только для резервирования части пропускной способности. Используя RSVP, отправитель периодически информирует получателя о свободном количестве ресурсов сообщением RSVP Path (рис. 5.9). Транзитные маршрутизаторы по мере прохождения этого сообщения также анализируют имеющееся у них количество свободных ресурсов и подтверждают его соответствующим сообщением RSVP Resv, передаваемым в обратном направлении. Если ресурсов достаточно, то отправитель начинает передачу. Если ресурсов не достаточно, получатель должен снизить требования или прекратить передачу информации.

RSVP Path

Одна из интересных особенностей RSVP заключается в том, что запросы на резервирование ресурсов направляются только от получателей данных отправителям, а не наоборот. Такой подход обусловлен тем, что лишь устройство-получатель знает, с какой скоростью оно должно получать данные, чтобы надежно декодировать аудио- или видеосигналы. Другая уникальная особенность RSVP состоит в том, что резервирование производится лишь для много направления. Кроме того, RSVP не допускает смешения аудио- и видеосигналов на зарезервированном канале.

Когда RSVP-программы закончат сеанс связи, они должны вызвать функцию отмены, предусмотренную этим протоколом. Отмена аннулирует все запросы на ресурсы, сделанные

программой, и позволяет другим прикладным программам использовать возможности Internet. Если программе не удается выполнить отмену, то предусмотрено протоколом средства по истечении некоторого промежутка времени обнаружат это и автор отменят запрос на ресурсы.

Недостатком протокола RSVP является то, что полоса пропускания, выделяемая источнику информации, при снижении активности источника не может быть использована передачи другой информации. Поскольку для реализации QoS протокол RSVP требует верования ресурсов или каналов связи, небрежные или безответственные пользователи захватить ресурсы сети, инициируя несколько сеансов QoS подряд. Как только канал sale, он становится недоступным для других пользователей, даже если тот, кто затребовал, ничего не передает. К сожалению, в RSVP отсутствует четкий механизм предотвращения подобных ситуаций, и решение этой проблемы возлагается на сетевых администраторов. Очевидно, что необходимо предусмотреть более жесткий контроль, чтобы RSVF имел успех.

Как альтернатива этому способу может использоваться алгоритм управления потоками на основе системы приоритетов, однако в существующей версии IP этот механизм развит . достаточно. Механизм управления приоритетами должен быть реализован в следующей шестой версии IP, где предусматривается введение до 16 приоритетов, а также возможность организации нескольких логических потоков в рамках одного физического соединения. Однако в настоящее время аппаратура, реализующая IP версии 6, только начала появляться на рынке.

Ввиду зависимости RSVP от совместимости промежуточных узлов — в случаев маршрутизаторов — это влечет за собой неизбежные проблемы, в частности, s глобальных сетях. Если какой-либо маршрутизатор достиг предела своих возможностей, когда он не может гарантировать запрошенный уровень QoS, все последующие будут игнорироваться и удаляться. При отказе только одного узла обслуживать запрос act стройная система RSVP распадается на части.

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

5.7. Обеспечение качества IP-телефонии на базе протоколов RTP и RTCP

Для уменьшение значений джиттера и задержек на сетевом уровне применяются гарантирующие пользователю заданный уровень качества механизмы RSVP, MPLS, РН-Serv, АТМ и др. Они улучшают качество услуг, предоставляемых сетью, но не могут полностью устранить образование очередей в сетевых устройствах, а, следовательно, и совсем убрать джиттер. Компенсировать его негативное влияние позволяет разработанный IETF протоков прикладного уровня RTP (Real-time Transport Protocol), который используется технологиями Н.323 и SIP.

Протокол RTP (RFC1889) предназначен для доставки чувствительной к задержкам информации с использованием сетевых служб одноадресной или групповой рассылки. Он не имеет собственных механизмов, гарантирующих своевременную доставку пакетов или другие параметры качества услуг — это осуществляют нижележащие протоколы. Он даже не

обеспечивает все те функции, которые обычно предоставляют транспортные протоколы, в частности, функции по исправлению ошибок или управлению потоком. Обычно RTP работает поверх UDP и использует его службы, но может функционировать и поверх других транспортных протоколов (рис. 5.10).

Служба RTP предусматривает указание типа полезной нагрузки и последовательного номера пакета в потоке, а также применение временных меток. Отправитель помечает каждый RTP-пакет временной меткой, а получатель извлекает ее и вычисляет суммарную задержку. Разница в задержке пакетов позволяет определить джиттер и смягчить его влияние- все пакеты будут выдаваться приложению с одинаковой задержкой.

Таким образом, главная особенность RTP — это вычисление средней задержки некоторого набора принятых пакетов и выдача их пользовательскому приложению с постоянной, равной этому среднему значению. Однако следует иметь ввиду, что временная метка RTP соответствует моменту кодирования первого дискретного сигнала пакета. Поэтому, если RTP-пакет, например, с видеоинформацией, разбивается на несколько пакетов нижележащего уровня, то временная метка уже не будет соответствовать истинному времени их передачи, поскольку они перед передачей могут быть организованы в очередь.

Еще одно преимущество RTP состоит в том, что его можно использовать с RSVP для передачи синхронизированной мультимедиа информации с определенным уровнем качества обслуживания. Кроме того, разговоры передаются по сети Internet в незашифрованном виде. Поэтому любой узел, находящийся на пути следования данных, может подключиться к этой линии и прослушать ваш разговор. Чтобы решить эту проблему, в RTP предлагается механизм, до некоторой степени обеспечивающий защиту от несанкционированного доступа и конфиденциальность. Эти средства довольно ненадежны и могут рассматриваться лишь как временное решение проблемы — пока протоколы, поверх которых работает RTP, не будут располагать развитыми механизмами безопасности данных.

Возможности RTP можно расширить, объединив его с еще одним протоколом IETF, а именно с протоколом управления передачей в реальном времени (Real-time Transport Control Protocol, RTCP). С помощью RTCP контролируется доставка RTP-пакетов и обеспечивается

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

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

При всех своих достоинствах протокол RTP далеко не совершенен. Например, кол никак не способен повлиять на задержку в сети, но он помогает сократить дрожание звука при воспроизведении при наличии задержек. Кроме того, хотя пакеты UDP получают рядковые номера, при этом принимающая станция может установить факт потери пакетик, RTP не предпринимает никаких мер для восстановления потерянных пакетов.

Один из способов расширения возможностей RTP состоит в использовании его с протоколом RSVP, который официально не входит в комплект протоколов Н.323, нс. поддерживается многими приложениями реального времени.

5.8. Обеспечение качества IР-телефонии на базе протокола IPv6

После нескольких лет тестирования организация Internet Assigned Numbers Authority приступила к развертыванию IPvб (версии 6 протокола Internet Protocol) — системы цифровой адресации Internet нового поколения.

Начать разработку IPvб организацию Internet Engineering Task Force побудили , что Internet израсходует весь запас уникальных адресов. Первоначально сеть Internet была рассчитана на связь небольшого количества исследовательских сетей. Поэтому поле адреса в используемой в настоящее время системе адресации IPv4 может принимать около 4 млрд. уникальных значений. Число уникальных адресов, обеспечиваемых новой системой- десять в восемнадцатой степени, или миллиард миллиардов. Этого должно хватить на много лет вперед.

Переход на 1Рчб начат с трех крупнейших региональных регистрационных каталогов, которые приступают к выдаче новым пользователям удлиненных адресов; полный перевод на новую систему всей сети может быть завершен, как ожидается, в течение 6-10 лет. IPvб включает следующие возможности, отсутствующие у IPv4:

• расширенное адресное пространство: IPvб использует 128-битовые адреса вместе

32-битовых IPv4. В результате адресное пространство увеличивается в 296 раз, что явно достаточно даже в случае неэффективного распределения сетевых адресов;

• улучшенные возможности маршрутизации: в связи с увеличением межсетевого трафика, связанного с обработкой больших объемов мультимедийной информации и расширением использования сети Интернет в различных сферах деятельности, весьма существенной является необходимость обеспечения высоких скоростей маршрутизации. Без применения эффективных алгоритмов обработки пакетов данных становится невозможным повысить скорости работы маршрутизаторов до уровня, сравнимого с скоростями передачи информации по каналам связи;

• управление доставкой информации: IPv6 позволяет отмечать соответствие конкретного пакета определенным условиям его передачи, заданным отправителем. В результате достигается регулирование скорости передачи определенных потоков данных, что позволяет обеспечивать эффективную поддержку специальных протоколов (например, видео в режиме реального времени и др.). За счет назначения приоритетов передачи данных по определенным протоколам, появляется возможность гарантировать первоочередность обработки наиболее критической информации и предоставления важным данным всей полосы пропускания канала связи. Другие особенности, имеющиеся у IPv6, позволяют протоколам этого семейства обеспечивать одновременную многоадресную доставку информации. Данная возможность находит свое применение в рассылке информации "по подписке" или "по требованию", а также в других приложениях;

• средства обеспечения безопасности: IPv6 предоставляет возможности защиты от атак, связанных с подменой исходных адресов пакетов, и от несанкционированного доступа к полям данных пакетов. Эти возможности достигаются за счет применения алгоритмов аутентификации и шифрования.

Не вызывает сомнений тот факт, что переход от IPv4 к IPv6 не может быть мгновенными. Долгое время две версии IP будут сосуществовать. Более того, поначалу узлы, реализующие 1Рчб, не будут предоставлять всех необходимых сервисов, а их расположение напоминающим острова в океане IPv4. Следовательно, от узлов с IPv6 требуется выполнение двух свойств:

• возможность взаимодействовать с IPv4-узлами;

• возможность передавать пакеты IPv6 через существующую инфраструктуру IPv4. Чтобы выполнить эти требования, рабочая группа по переходу на IP нового поколений, два основных метода:

• одновременная поддержка в узлах (и в хостах, и в маршрутизаторах) IPv6 двух стеков протоколов (1РчбЛРч4);

• туннелирования пакетов IPv6 для их передачи через инфраструктуру IPv4.

5.9. Обеспечение качества IP-телефонии на базе дифференцированного обслуживания

Еще одна технология обеспечения QoS разработана рабочей группой IETF по обслуживанию (Differentiated Services, Diff-Serv). Эта группа выделилась из рабочей группы по интегрированному обслуживанию (Integrated Services, IntServ), задача второй состоит в разработке стандартов для поддержки трафика

Internet реального времени.

Проводимая в рамках IntServ работа отражает некоторые из особенностей концепции

15VP. Интегрированное обслуживание предполагает сигнализацию из конца в конец и в действительности использует RSVP между отправителями и получателями.

IntServ определяет три класса обслуживания для IP-сетей:

• по мере возможности — то, что сейчас предлагает Internet;

• с контролируемой загруженностью — приложение получает тот уровень обслуживания, какой оно имело бы в слабо загруженной сети;

• гарантированным обслуживанием — необходимая пропускная способность в течение всего сеанса предоставляется с гарантией на параметры качества обслуживания

Как и RSVP, интегрированное обслуживание имеет проблемы с масштабированием, этому данная технология вряд ли пробьется за пределы корпоративных сетей. И, как было а мечено, RSVP предполагает весьма значительные накладные расходы, так как каждый у вдоль пути следования пакетов должен согласиться предоставить запрошенное качество услуг,

Дифференцированное обслуживание предлагает более простой и масштабируемый а QoS для приложений реального времени. Одним из ключевых моментов в работе DiffServ является переопределение 8-битного поля «Тип сервиса» в заголовке IPv4. Названое «Дифференцированным обслуживанием» (DS), это поле может содержать информацию, на основании которой узлы вдоль маршрута определяют, как им следует обрабатывать пакт ты и передавать их следующему маршрутизатору.

В настоящее время только 6 из 8 бит в поле DS были определены, и только одно as значение было стандартизовано. Это назначение известно как принятое по умолчанию- Default (DE), — и оно определяет класс обслуживания по мере возможности. Другое предполагаемое назначение, срочная отправка (Expedited Forwarding, EF), должно обеспечить сокращение задержек и потерь пакетов.

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

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

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

5.10. Обеспечение качества IP-телефонии на базе MPLS

Конкурентом DiffServ на роль протокола для обеспечения QoS является другой проект IETF под названием «Многопротокольная коммутация меток» (Multiprotocol Label Switching, MPLS).

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

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

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

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

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

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

При использовании меток MPLS маршрутизатор или коммутатор может присвоить метки записям из своих таблиц маршрутизации и в виде меток передать информацию о маршрутизации конкретным маршрутизаторам и коммутаторам. Считав метку, каждый коммутатор или маршрутизатор узнает информацию о следующем адресате на пути, не анализируя заголовок пакета. Это экономит время и ресурсы ЦПУ. Пакеты с метками MPLS могут, следовательно, передаваться от отправителя к получателю без задержек на обработку, причем все промежуточные узлы знают, как нужно обрабатывать каждый пакет.

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

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

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

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

5.11. Спецификация IEEE 802.1р

Рабочая группа IEEE 802.1 по высокоуровневым протоколам для локальных сетей разработала спецификацию 802.1р для приоритезации трафика в соответствии с восемью класса- w — от обработки по мере возможности до поддержки передачи голоса и видео в реальном времени. Промежуточные уровни между ними занимают классы для потокового типа неинтерактивных видеоклипов и для важного трафика типа запросов к базам данных.

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

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

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

5.12. Обеспечение качества 1Р-телефонии с помощью механизма управления на основе правил

Одним из перспективных направлений в реализации гарантированных уровней качества сервиса (QoS) в среде IP является разрабатываемая в настоящее время технология управления на основе правил.

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

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

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

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

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

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

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

Связь между элементами PDP и PEP обеспечивает несложный протокол запросов/ответов Common Open Policy Service (COPS). Его преимущества перед SNMP состоят в ориентации на соединения (он охватывает процесс установления/разрыва соединения), большей надежности и наличии механизмов, предотвращающих попытки одновременного обновления данных одной точки PEP несколькими PDP.

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

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

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

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

Ближайшие перспективы администрирования на основе стратегий в среде, состоящей из продуктов различных производителей, оставляют желать лучшего. К сожалению, реализации механизмов работы с набором правил и алгоритмы формирования трафика сильно различаются не только в продуктах разных производителей, но даже в пределах ассортимент одной компании. Чтобы добиться реальной совместимости устройств или их единого администрирования, нужны стандартные модели общих функций для задания и выполнения алгоритмов и формирования трафика. Необходимо также обеспечить единое представление схемы реализации QoS и информации о стратегиях в базе данных Policy Information Вазе (PIB), равно как и поддержку работы с PIB сетевыми устройствами.

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

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

5.13. Организационные аспекты обеспечения параметров качества IP-телефонии

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

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

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

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

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

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

Глава 6

АДРЕСАЦИЯ В СЕТЯХ IP-ТЕЛЕФОНИИ

6.1. Нумерация в телефонных сетях общего пользования

В настоящее время нумерация в сетях общего пользования с коммутацией канала, предоставляющих услуги телефонной связи (телефонные сети, сети ISDN, интеллектуальный сети, сотовые сети и др.), реализуется в соответствии с Рекомендацией ITU-Т Е.164.

Система нумерации таких сетей включает международный и национальные планы нумераций.

Каждая телефонная Администрация разрабатывает национальный план нумерации для своей сети. Этот план разрабатывается таким образом, чтобы любой абонент национально сети может быть доступен по одному и тому же номеру для разных услуг. Причем это доля выполняться для всех входящих международных вызовов. Национальный план нумерации страны должен быть такой, чтобы анализ цифры не превышал установленные пределы, применимые к национальному (значащему) номеру N(S)N.

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

Рис. 6.1. Структура международного номера

Поле «Код страны (СС)» используется для определения страны или географической области назначения. Данный код имеет различную длину, конкретные значения кодов для стран мира приведены в Рекомендации 1Т1.1-Т Е.164. Следует отметить, что код страны начинается с номера мировой зоны нумерации. В настоящее время территория всего земного разделена на 9 мировых зон нумерации:

Зона 1 — Северная Америка;

Зона 2 — Arhnuvs.

Зоны 3 и 4 — Европа;

Зона 5 — Центральная и Южная Америка;

Зона 6 — Австралия и Океания;

Зона 7 — Россия и Казахстан;

Зона 8 — Юго-Восточная Азия;

Зона 9 — Азия.

Поле «Национальный (значащий) номер N(S)N» используется для определения абонента в сети. При выборе требуемого абонента иногда необходимо определить и сеть назначения. В этом случае национальный код включает поле национального кода назначения (NDC). Национальный код назначения может иметь различную длину в зависимости от требований национальных Администраций.

Поле «Номер абонента SN» также имеет произвольную длину в каждой национальной согласно Рекомендации ITU-Т Е.160.

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

6.2. Адресация в IP-сетях Типы адресов в IP-сетях

Каждый терминал в сети ТСР/I1P имеет адреса трех уровней:

1. Физический (МАС-адрес) — локальный адрес узла, определяемый технологией, с которой построена отдельная сеть, в которую входит данный узел. Для узлов, входящих в локальные сети - это МАС-адрес сетевого адаптера или порта маршрутизатора, например, 11-АО-17-3D-ВС-01. Эти адреса назначаются производителями оборудования и являются уникальными адресами, так как управляются централизовано. Для всех существующих технологий локальных сетей MAC-адрес имеет формат 6 байтов: старшие 3 байта — идентификатор фирмы производителя, а младшие 3 байта назначаются уникальным образом самим производителем. Для узлов, входящих в глобальные сети, включая Х.25 или frame relay, локальный адрес назначается администратором глобальной сети.

2. Сетевой (Ip-адрес), состоящий из 4 байт, например, 109.26.17.100. Этот адрес используется на сетевом уровне. Он назначается администратором во время конфигурирования компьютеров и маршрутизаторов. IP-адрес состоит из двух частей: номера сети и номера узла. Номер сети может быть выбран администратором произвольно или назначен по рекомендации специального подразделения Internet (Network Information Center, NIC), если сеть должна работать как составная часть Internet. Обычно провайдеры услуг Internet, получают диапазоны подразделений NIC, а затем распределяют их между своими абонентами. Номер узла в протоколе IP назначается независимо от локального адреса узла. Деление IP-адреса на поле номера сети и номера узла — гибкое, и граница между этими полями может устанавливаться весьма произвольно. Узел может входить в несколько IP-сетей. В этом случае, узел должен иметь несколько IP-адресов, по числу сетевых связей. Таким образом, IP- адрес характеризует не отдельный компьютер или маршрутизатор, а одно сетевое соединение.

3. Символьный (DNS-имя) — идентификатор-имя, например, SERVI.IBM.СОМ. Этот

адрес назначается администратором и состоит из нескольких частей, например, имени машины, имени организации, имени домена. Такой адрес, называемый также DNS-именем, пользуется на прикладном уровне, например, в протоколах FTP или telnet.

Три основных класса IP-адресов

IP-адрес имеет длину 4 байта и обычно записывается в виде четырех чисел, представляющих значения каждого байта в десятичной форме, и разделенных точками, например:

128.10.2.30 - традиционная десятичная форма представления адреса,

10000000 00001010 00000010 00011110 — двоичная форма представления этого же адреса. На рис. 6.2 показана структура IP-адреса.

Адрес состоит из двух логических частей — номера сети и номера узла в сети. Каких часть адреса относится к номеру сети, а какая к номеру узла, определяется значениями первых битов адреса:

• Если адрес начинается с О, то сеть относят к классу А, и номер сети занимает один байт, остальные 3 байта интерпретируются как номер узла в сети. Сети класса номера в диапазоне от 1 до 126. (Номер 0 не используется, а номер 127 зарезервирован для специальных целей, о чем будет сказано ниже.) В сетях класса А количеств узлов должно быть больше 216, но не превышать 224.

• Если первые два бита адреса равны 10, то сеть относится к классу В и является сетью средних размеров с числом узлов 28-216. В сетях класса В под адрес сети и под адрес узла отводится по 16 битов, то есть по 2 байта.

• Если адрес начинается с последовательности 110, то это сеть класса С с числом узлов не больше 28. Под адрес сети отводится 24 бита, а под адрес узла — 8 битов.

• Если адрес начинается с последовательности 1110, то он является адресом класса D и обозначает особый, групповой адрес — multicast. Если в пакете в качестве адреса назначения указан адрес класса D, то такой пакет должны получить все узлы, которым присвоен данный адрес.

• Если адрес начинается с последовательности 11110, то это адрес класса Е, он зарезервирован для будущих применений.

В табл. 6.1 приведены диапазоны номеров сетей, соответствующих каждому классу сетей.

Отображение физических адресов на IP-адреса

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

Локальный адрес используется в протоколе IP только в пределах локальной сети при 06MCHe данными между маршрутизаторам и узлом этой сети. Маршрутизатор, получив пакет узла одной из сетей, непосредственно подключенных к его портам, должен для передачи пакета сформировать кадр в соответствии с требованиями принятой в этой сети технологии и указать в нем локальный адрес узла, например его МАС-адрес. В пришедшем пакете этот адрес не указан, поэтому перед маршрутизатором встает задача поиска его по известному IP- адресу, который указан в пакете в качестве адреса назначения. С аналогичной задачей сталкивается и конечный узел, когда он хочет отправить пакет в удаленную сеть через маршрутизатор, подключенный к той же локальной сети, что и данный узел.

Для определения локального адреса по IP-адресу используется протокол разрешения вереса Address Resolution Protocol, АКР. Протокол ARP работает различным образом в зависимости от того, какой протокол канального уровня работает в данной сети — протокол сети (Ethernet, Token Ring, FDDI) с возможностью широковещательного доступа одновременно ко всем узлам сети, или же протокол глобальной сети (Х.25, Frame Relay), как правило, не поддерживающий широковещательный доступ. Существует также протокол, решающий обратную задачу — нахождение IP-адреса по известному локальному адресу. Он называется реверсивный ARP — RARP (Reverse Address Resolution Protocol) и используется пре старте бездисковых станций, не знающих в начальный момент своего IP-адреса, но знающих адрес своего сетевого адаптера.

В локальных сетях протокол ARP использует широковещательные кадры протокола уровня для поиска в сети узла с заданным IP-адресом.

Узел, которому нужно выполнить отображение IP-адреса на локальный адрес, формирует ARP-запрос, вкладывает его в кадр протокола канального уровня, указывая в нем известный IP-адрес, и рассылает запрос широковещательно. Все узлы локальной сети получают ARP-запрос и сравнивают указанный там IP-адрес с собственным. В случае их совпадения узел формирует ARP-ответ, в котором указывает свой IP-адрес и свой локальный адрес и отправляет его уже направленно, так как в ARP-запросе отправитель указывает свой локальный адрес. ARP-запросы и ответы используют один и тот же формат пакета. Так как локальные адреса могут в различных типах сетей иметь различную длину, то формат пакета протокол ARP зависит от типа сети. На рис. 6.3 показан формат пакета протокола ARP для передачи по сети Ethernet.

В поле типа сети для сетей Ethernet указывается значение 1. Поле типа протокола позволяет использовать пакеты ARP не только для протокола IP, но и для других сетевых протоколов. Для IP значение этого поля равно 0800

Длина локального адреса для протокола Ethernet равна 6 байтам, а длина IP-адреса -4 байтам. В поле операции для ARP запросов указывается значение 1 для протокола ARP и 2 для протокола КАИР.

Узел, отправляющий ARP-запрос, заполняет в пакете все поля, кроме поля искомого локального адреса (для RARP-запроса не указывается искомый IP-адрес). Значение этого поля заполняется узлом, опознавшим свой IP-адрес.

В глобальных сетях администратору сети чаще всего приходится вручную формировать ARP-таблицы, в которых он задает, например, соответствие IP-адреса адресу узла сети Х.25, который имеет смысл локального адреса. В последнее время наметилась тенденция автоматизации работы протокола ARP и в глобальных сетях. Для этой цели среди всех маршрутизаторов, подключенных к какой-либо глобальной сети, выделяется специальный маршрутизатор, который ведет ARP-таблицу для всех остальных узлов и маршрутизаторов этой сети. При таком централизованном подходе для всех узлов и маршрутизаторов вручную нужно задать только IP-адрес и локальный адрес выделенного маршрутизатора. Затем каждый узел и маршрутизатор регистрирует свои адреса в выделенном маршрутизаторе, а при необходимости установления соответствия между IP-адресом и локальным адресом узел обращается к выделенному маршрутизатору с запросом и автоматически получает ответ без участия администратора.

Отображение символьных адресов на IP-адреса

Служба DNS (Domatn Name System) — это распределенная база данных, поддерживающая иерархическую систему имен для идентификации узлов в сети Internet. Служба DNS предназначена для автоматического поиска IP-адреса по известному символьному имени узла. Спецификация DNS определяется стандартами RFC 1034 и 1035. DNS требует статической конфигурации своих таблиц, отображающих имена компьютеров в IP-адрес.

Протокол DNS является служебным протоколом прикладного уровня. Этот протокол несимметричен — в нем определены DNS-серверы и DNS-клиенты. DNS-серверы хранят часть распределенной базы данных о соответствии символьных имен и IP-адресов. Эта база данных по административным доменам сети Internet. Клиенты сервера DNS знают IP-адрес сервера DNS своего административного домена и по протоколу IP передают запрос, в котором известное символьное имя и просят вернуть соответствующий ему IP-адрес.

Если данные о запрошенном соответствии хранятся в базе данного DNS-сервера, то он посылает ответ клиенту, если же нет — то он посылает запрос DNS-серверу другого , который может сам обработать запрос или передать его другому DNS-серверу. Все DNS-серверы соединены иерархически, в соответствии с иерархией доменов сети Internet опрашивает эти серверы имен, пока не найдет нужные отображения. Этот процесс ускоряется из-за того, что серверы имен постоянно кэшируют информацию, предоставляемую по запросам. Клиентские компьютеры могут использовать в своей работе IP-адреса нескольких DNS-серверов для повышения надежности своей работы.

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

Корень базы данных DNS управляется центром Internet Network Information Center. домены верхнего уровня назначаются для каждой страны, а также на организационной основе. Имена этих доменов должны следовать международному стандарту ISO 3166. Для обозначения стран используются трехбуквенные и двухбуквенные аббревиатуры, а для различных типов организаций используются следующие аббревиатуры:

• com — коммерческие организации (например, Microsoft com);

• edu — образовательные (например, mit.edu);

• gov — правительственные организации (например, nsf.gov);

• org — некоммерческие организации (например, fidonet.org);

• net — организации, поддерживающие сети (например, nsf.net).

Каждый домен DNS администрируется отдельной организацией, которая обычно разбивает свой домен на поддомены и передает функции администрирования этих поддоменов другим организациям. Каждый домен имеет уникальное имя, а каждый из поддоменов имеет уникальное имя внутри своего домена. Имя домена может содержать до 63 символов. Каждый хост в сети Internet однозначно определяется своим полным доменным именем (fully qualified domaine пате, FQDN), которое включает имена всех доменов по направлению от роста к корню. Пример полного DNS-имени: citint.dol.ru.

Автоматизация процесса назначения IP-адресов

Как уже было сказано, IP-адреса могут назначаться администратором сети вручную. Это представляет для администратора утомительную процедуру. Ситуация усложняется еще тем, что многие пользователи не обладают достаточными знаниями для того, чтобы конфигурировать свои компьютеры для работы в интерсети и должны поэтому полагаться на администраторов.

Протокол динамической настройки хоста Dynamic Host Configuration Protocol (DHCP) был разработан для того, чтобы освободить администратора от этих проблем. Основным назначением DHCP является динамическое назначение IP-адресов. Однако, кроме динамического, DHCP может поддерживать и более простые способы ручного и автоматического статического назначения адресов.

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

При автоматическом статическом способе DHCP-сервер присваивает IP-адрес (и, во> можно, другие параметры конфигурации клиента) из пула наличных IP-адресов без вмешательства оператора. Границы пула назначаемых адресов задает администратор при конфигурировании DHCP-сервера. Между идентификатором клиента и его IP-адресом по-прежнему, как и при ручном назначении, существует постоянное соответствие. Оно устанавливается 3 момент первичного назначения сервером DHCP IP-адреса клиенту. При всех последуют запросах сервер возвращает тот же самый IP-адрес.

При динамическом распределении адресов DHCP-сервер выдает адрес клиенту на ограниченное время, что дает возможность впоследствии повторно использовать IP-адреса другими компьютерами. Динамическое разделение адресов позволяет строить IP-сеть, количество узлов в которой намного превышает количество имеющихся в распоряжении администратора IP-адресов.

DHCP обеспечивает надежный и простой способ конфигурации сети ТСРЛР, гарантируя отсутствие конфликтов адресов за счет централизованного управления их распределением. Администратор управляет процессом назначения адресов с помощью параметра «npoдолжительности аренды» (lease duration), которая определяет, как долго компьютер можно использовать назначенный IP-адрес, перед тем как снова запросить его от сервера DHCP в аренду.

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

Протокол DHCP использует модель клиент-сервер. Во время старта системы компьютер-клиент DHCP, находящийся в состоянии «инициализация», посылает сообщение discover (исследовать), которое широковещательно распространяется по локальной сети и передается всем DHCP-серверам частной интерсети. Каждый DH

CP-сервер, получивший это сообщение, отвечает на него сообщением offer (предложение), которое содержит IP-адрес и конфигурационную информацию.

Компьютер-клиент DHCP переходит в состояние «выбор» и собирает конфигурационные предложения от DHCP-серверов. Затем он выбирает одно из этих предложений, переходит в состояние «запрос» и отправляет сообщение request (запрос) тому DHCP-серверу, предложение было выбрано.

Выбранный DHCP-сервер посылает сообщение DHCP-acknowledgment (подтверждение), содержащее тот же IP-адрес, который уже был послан ранее на стадии исследования, в также параметр аренды для этого адреса. Кроме того, DHCP-сервер посылает параметры ceтевой конфигурации. После того, как клиент получит это подтверждение, он переходит в состояние «связь», находясь в котором он может принимать участие в работе сети ТСРЛIP. Компьютеры-клиенты, которые имеют локальные диски, сохраняют полученный адрес для использования при последующих стартах системы. При приближении момента истечения срока аренды адреса компьютер пытается обновить параметры аренды у DHCP-сервера, а если этот IP-адрес не может быть выделен снова, то ему возвращается другой IP-адрес.

В протоколе DHCP описывается несколько типов сообщений, которые используются для обнаружения и выбора DHCP-серверов, для запросов информации о конфигурации, для

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

Однако использование DHCP несет в себе и некоторые проблемы. Во-первых, это проблема согласования информационной адресной базы в службах DHCP и DNS. Как известно, DNS служит для преобразования символьных имен в IP-адреса. Если IP-адреса будут динамически изменятся сервером DHCP, то эти изменения необходимо также динамически вносить в базу данных сервера DNS. Хотя протокол динамического взаимодействия между службами DNS и DHCP уже реализован некоторыми фирмами (так называемая служба Dynamic DNS), стандарт на него пока не принят.

Во-вторых, нестабильность IP-адресов усложняет процесс управления сетью. Системы управления, основанные на протоколе SNMP, разработаны с расчетом на статичность IP-адресов. Аналогичные проблемы возникают и при конфигурировании фильтров маршрутизатор, которые оперируют с IP-адресами.

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

Служба каталогов на базе протокола LDAP

Протокол LDAP (Lightweight Directory Access Protocol — упрощенный протокол доступа к каталогам) является стандартом доступа к службам сетевых каталогов, а протокол DHCP используется для динамического присвоения IP-адресов пользователям для доступа к сетевым ресурсам. Как заявляют компании-разработчики, объединение этих двух технологий поможет разрешить некоторые серьезные проблемы, присущие протоколу ТСР/IP, например, управление адресами, разработку стратегии безопасности и одновременное использование информации об адресах (на что не способны DHCP-серверы).

Протокол LDAP упрощает работу в сетевой среде. Так, пользователи получают возможность входить в систему с любого узла сети и работать с привычными для себя настройками, поскольку информация о них будет сохраняться в основанном на LDAP каталоге. В будущем основанные на LDAP каталоги могут применяться для поддержки инфраструктуры интрасетей и Internet. Например, службы типа системы именования доменов (DNS) и DHCP будут использовать серверы каталогов на базе LDAP в качестве своих хранилищ информации. Тогда эти службы приобретут дополнительные достоинства — модульную структуру и независимость от места размещения.

Протокол LDAP специально предназначен для использования с управляющими и браузерными приложениями, которые обеспечивают интерактивный доступ к каталогам с возможностью чтения и записи. LDAP — это протокол взаимодействия клиента и сервера, обеспечивающий доступ к службе каталогов и работающий непосредственно поверх протокола ТСР/IP.

Набор API-интерфейсов протокола LDAP достаточно прост. Протокол становится одним из наиболее предпочтительных для работы с каталогами в Internet. Поскольку уже более 40 компаний обеспечивают поддержку LDAP в своих продуктах или заявили о таком намерении, этот протокол быстро завоевывает себе популярность и получает все более широкое распространение. В настоящее время серверы LDAP выпускаются компаниями Microsoft, Netscape Communications, Lucent Technologies, ISODE, Critical Angle, Novell, Banyan Systems и др. Некоторые браузеры Web, например Netscape Communicator, имеют встроенный клиент LDAP.

Применяемая в LDAP информационная модель основана на схеме, использованной в протоколе Х.500, которая, в свою очередь, базируется на «именных записях». Именные записи обозначают либо реальные объекты, например какого-нибудь пользователя, лицо некоторую сетевую службу, например службу преобразования адресов. Каждая записи сопровождается атрибутами, имеющими одно или несколько значений, и хранит информацию, которую при необходимости можно найти. Как правило, каталог на базе LDAF поддерживает репликацию, что повышает надежность и увеличивает быстродействие системы.

Система именования доменов (DNS) нужна для того, чтобы компьютеры могли друг друга в сети. С помощью коммуникационных протоколов служба DHCP информацию об IP-адресах и другие сведения среди клиентов сети; обычно это делается при запуске системы. Службу DHCP можно настроить таким образом, чтобы времен но присваивать клиентам динамические адреса из некоторого банка свободных адресов переназначать эти адреса по мере необходимости.

Автоматическое присвоение IP-адреса требует относительно тесной связи между серверами DNS и DHCP, установленными на данном узле сети. Эта связь необходима, присваивая клиенту IP-адрес, сервер DHCP должен иметь возможность обновления информации о соответствии имени клиента присвоенному ему адресу.

Совмещение технологий DHCP и DNS с возможностями каталогов на базе LDAP позволит добиться как минимум следующих преимуществ:

• доступ к информации — новая система позволит организовать стандартный метод для поиска и сохранения данных в информационном хранилище серверов DHCF и DNS;

• гибкость построения сети — поскольку сетевой протокол LDAP способен работать различных платформах, появляется возможность размещения серверного хранилище информации на других машинах;

• репликация — уже сейчас многие поставщики встраивают функции репликации в ими службы каталогов на базе LDAP; в будущем они еще больше расширится, так как комитет IETF начинает разрабатывать стандартный протокол LDAP возможностью репликации.

Главная цель объединения серверов — дать пользователям возможность встраивать их системы управления сетевыми адресами средства повышения надежности, безопасности н синхронизации имен и адресов.

Процесс взаимодействия серверов LDAP и DHCP показан на рис. 6.4. Клиент запрос на доступ в Internet с указанием нужного адреса и ресурса. Сервер DHCP автоматик присваивает клиенту IP-адрес и связывает пользователя с ресурсами в каталоге LDAF. Сервер LDAP находит указанные ресурсы и автоматически соединяет пользователя с узлом сети.

Как и DNS, LDAP — это служба каталогов в архитектуре клиент-сервер. Каталоги содержать самую разную информацию, например, базу данных пересчета телефонный номеров Е.164 в IP-адреса для пользователей IP-телефонии. Составляющие дерево каталки LDAP данные хранятся на одном или более серверах LDAP. Если при обращении клиент LDAP, например шлюза IP-телефонии, сервер не может ответить на запрос, то во всяком он может возвратить ему указатель на другой сервер LDAP, где запрашиваемая может быть найдена.

Адресация в IPv6

Одним из основных отличий внедряемого в настоящее время протокола IPv6 от протокола IPv4 является использование более длинных адресов. Адреса получателя и источника в IPv6 имеют длину 128 бит или 16 байт. Версия 6 обобщает специальные типы адресов версии 4 в следующих типах адресов:

• Unicast — индивидуальный адрес. Определяет отдельный узел — компьютер или порт маршрутизатора. Пакет должен быть доставлен узлу по кратчайшему маршруту.

• Cluster — адрес кластера. Обозначает группу узлов, которые имеют общий адресный префикс (например, присоединенных к одной физической сети). Пакет должен быть маршрутизирован группе узлов по кратчайшему пути, а затем доставлен только одно- му из членов группы (например, ближайшему узлу).

• Multicast — адрес набора узлов, возможно в различных физических сетях. Копии пакета должны доставлены каждому узлу набора, используя аппаратные возможности групповой или широковещательной доставки, если это возможно.

Как и в версии IPv4, адреса в версии IPv6 делятся на классы, в зависимости от значения нескольких старших бит адреса.

Большая часть классов зарезервирована для будущего применения. Наиболее интересным для практического использования является класс, предназначенный для провайдеров услуг Internet, названный Provider-Assigned Unicast.

Адрес этого класса имеет следующую структуру:

Каждому провайдеру услуг Internet назначается уникальный идентификатор, которым помечаются все поддерживаемые им сети. Далее провайдер назначает своим абонентам уникальные идентификаторы и использует оба идентификатора при назначении блока адресов абонента. Абонент сам назначает уникальные идентификаторы своим подсетям и узлам этих сетей.

Абонент может использовать технику подсетей, применяемую в версии IPv4, для дальнейшего деления поля идентификатора подсети на более мелкие поля.

Описанная схема приближает схему адресации IPv6 к схемам, используемым в территориальных сетях, включая телефонные сети или сети Х.25. Иерархия адресных полей позволит магистральным маршрутизаторам работать только со старшими частями адреса, оставляя обработку менее значимых полей маршрутизаторам абонентов.

Под поле идентификатора узла требуется выделения не менее 6 байт, для того чтобы можно было использовать в IP-адресах МАС-адрес локальных сетей непосредственно.

Для обеспечения совместимости со схемой адресации версии IPv4, в версии IPv6 имеется класс адресов, имеющих 0000 0000 в старших битах адреса. Младшие 4 байта адрес этого класса должны содержать адрес IPv4. Маршрутизаторы, поддерживающие обе версия адресов, должны обеспечивать трансляцию при передаче пакета из сети, поддерживающий адресацию IPv4, в сеть, поддерживающую адресацию IPv6, и наоборот.

6.3. Проблемы адресации в сетях IP-телефонии

В системах IP-телефонии, так же как и в сетях с коммутацией каналов, номера в cooтветствии с Рекомендацией Е.164 используются конечными пользователями, чтобы идентифицировать вызов. В IP-системах, когда конечный пользователь идентифицируется, номер Е.164 этого конечного пользователя временно связан с адресом IP (транспортный адрес) этого терминала (оконечной точки). Проблема нумерации в сети IP-телефонии связан с определением точки назначения вызова при внутридоменной и междоменной связи в IF- сети. В качестве такой конечной точки может выступать или IP-терминал с соответствующим приложением пользователя или шлюз для доступа в сеть с коммутацией каналов.

От решения задач адресации в IP-телефонии во многом зависят удобство пользования услугой, работа алгоритмов маршрутизации, обеспечение мобильности номеров и т.д. проблема организации взаимодействия сетей с коммутацией каналов и IP-сетей заключается в том, что единственный метод адресации обычного терминала абонента телефоний сети — это использование номера этого терминала (в сетях общего пользования номер Е.164). Вопрос преобразования номера сети с коммутацией каналов в IP-адрес представляется пока еще достаточно сложным и разрабатывается не только рабочей группой 4 в рамка проекта TIPHON, но и другими организациями, например IETF. В то же время ITU-Т только подходит к решению вопросов взаимодействия услуг IP-телефонии и ТфОП, ограничиваясь пока рассмотрением функций межсетевого взаимодействия на уровне транспортных технологий. Такая позиция объясняется, в частности, отсутствием общих для всех национальная администраций связи подходов к определению статуса услуги IP-телефонии.

Оператору Ip-телефонии, предлагающему свои услуги абонентам сетей с коммутацией каналов, необходимо, естественно, использовать уже имеющиеся схемы нумерации. Согласно рекомендациям TIPHON, для организации вызовов от абонентов сетей с коммутацией каналов пользователям IP-сети желательно, чтобы последние имели номер Е.164. В проекта TIPHON также исследуется возможность использования в Интернет кода страны и кода услуги, которые будут задействованы в Интернет-телефонии.

В сетях IP-телефонии, построенных на базе стандарта Н.323, преобразование телефонных номеров Е.164 в IP-адреса и обратно входит в функции gatekeeper. В системах, использующих протокол SIP, эти функции выполняются в специальном сервере.

Табл. 6.2 показывает отношения между именами и адресами для телефонных сетей я приложений Интернет. Она также включает различия в адресации между концепцией TIPHON и решениями по Интернет-телефонии, основанными на протоколе SIP.

Цель преобразования номера — замена цифр, набранных вызывающим пользователем, в имена Е.164 и преобразование этих имен в адреса, имена или идентификаторы, которая необходимо использовать для маршрутизации IP-сообщений управления телефонными. При этом телефонные соединения устанавливаются внутри домена или между доменами и/или далее маршрутируются в сеть с коммутацией каналов. Для выполнения функций маршрутизации при обслуживании вызовов необходимо иметь базу данных о пользователя и шлюзах, о преобразованиях номеров, имен и адресов.

Сети IP-телефонии должны поддержать преобразование номеров в двух случаях:

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

2. Маршрутизируемые вызовы направляются в сеть с коммутацией пакетов (IP-сеть). В stov случае вызывающий пользователь использует номер Е.164 как имя, идентифицирующее IP-сети. При этом возможен только один маршрут через соответствующий шлюз.

В соответствии с концепцией TIPHON сети IP-телефонии должны поддерживать, по крайней мере, одну из следующих схем нумерации:

1. Домены сети IP-телефонии должны поддержать все схемы нумерации на сетях связи с коммутацией каналов и обеспечивать надлежащее межсетевое взаимодействие с ними.

2. План нумерации для пользователей сетей IP-телефонии может быть таким же, как и пользователей сетей с коммутацией каналов, причем с учетом национальных особенностей.

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

Система нумерации IP-телефонии должна обеспечивать возможность замены одного номера Е.164 на другой. Это необходимо для обеспечения поддержки следующих услуг:

• мобильность номера;

• персональная нумерация;

• негеографические услуги типа freephone.

При таких услугах номер направляется в виде запроса на шлюз IP-телефонии и идентифицируется как номер маршрутирования Е.164. Ответ на запрос будет всегда в виде номера Е.164.

В системе IP-телефонии может существовать два вида планов нумерации: открытый (внутренний и международный) и частный. При этом возможны три формата номеров:

1. Фиксированный — набираемый номер фиксирован;

2. Переменный — набираемый номер может изменяться;

3. Корпоративный — набираемый номер определяется данными конфигурации корпоративного плана набора (Custom Dailing Plan).

Формат номера внутреннего плана имеет следующий вид:

•Фиксированный: внутренний национальный код (если есть) + код города + номер абонента;

•Переменный: набираемый номер зависти от следующих факторов:

— локальный вызов (код города соответствует коду, определенному для шлюза Интернет-телефонии) — набирается только номер абонента;

— междугородный звонок (код города отличается от кода, определенного для шлюз) — набирается внутренний национальный код (если есть) + код города + номер абонента;

•Корпоративный: набираемый номер конфигурируется администратором и зависит m определенных им кодов.

Формат номера международного плана имеет следующий вид:

•Фиксированный: код выхода на международную сеть + код страны + код городах номер абонента;

•Корпоративный: набираемый номер конфигурируется администратором и зависит m определенных им префиксов.

Формат номера частного плана имеет следующий вид:

•Фиксированный: номер абонента;

•Переменный: набираемый номер зависит от следующих факторов:

— локальный вызов (код частной зоны соответствует коду, определенному для шлюза) — набирается только номер абонента;

— междугородный звонок (код частной зоны отличается от кода, определенного для шлюза)

— внутренний национальный код (если есть) + код города + номер абонента

•Корпоративный: набираемый номер конфигурируется администратором и зависит m определенных им кодов.

Глава 7

СИСТЕМЫ БИЛЛИНГА И МЕНЕДЖМЕНТА ПОЛЬЗОВАТЕЛЕЙ IP- ТЕЛ ЕФОНИИ

7.1. Особенности систем биллинга и менеджмента пользователей IP-телефонии

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

Традиционные пакетно-ориентированные биллинг-системы просто неспособны выполнить требования провайдеров IP-телефонии. Такие биллинг-системы первоначально разрабатывались для более медленных темпов расчетов и с пакетно-ориентированным составлением счетов для услуг телефонной связи, обеспечивали предоставление информации по запросу только в конце цикла расчетов или месяца (рис. 7.1, а). Эти системы обычно разрабатывались под конкретного заказчика, с длинными циклами развития и недостаточной гибкостью, которая требуется для быстро развивающихся услуг IP-телефонии.

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

Таким образом, реализация услуг IP-телефонии требует нового подхода к построению систем менеджмента и биллинга. Провайдеры должны иметь такие системы, которые обеспечат комплексные возможности в реальном масштабе времени, неограниченную гибкость и масштабируемость для менеджмента и ускоренного внедрения мультисервисных IP-услуг (рис. 7.1, б). Это позволит им быстро разрабатывать новые услуги, снижать тарифы, эффективно управлять пользователями и осуществлять расчетные операции при сохранении достаточной гибкости в ответ на изменяющиеся требования рынка и запросы потребителей.

7.2. Требования к системе биллинга и менеджмента пользователей IP-телефонии

Работа в реальном масштабе времени

При традиционной телефонной связи программное обеспечение, которое выполняет расчеты за пользование услугами телефонной связи, не имеет непосредственного контакта с абонентом во время разговора. Детальная информация о вызовах (CDR) поступает от телефонных станций в течение месяца и только в конце месяца (или расчетного периода) вся собранная информация о вызовах передается в биллинг-систему.

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

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

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

Поддержка предоплаты

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

• поиск наилучшего пути для вызова;

• множественный доступ при одном предоплаченном счете;

• уведомление по электронной почте при уменьшении ниже нормы суммы на счету;

• пополнение счета через телефон или WEB-интерфейс;

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

Поддержка вторичных провайдеров

Вторичные провайдеры (субпровайдеры) — быстро развивающийся и прибыльный сегмент бизнеса IP-телефонии. Это позволяет первичным провайдерам воспользоваться преимуществом модели бизнеса вне своей фирменной марки, когда их корпоративные пользователи становятся "виртуальными" провайдерами IP-телефонии или провайдерами фирменно услуг (Branded Service Provider — BSP). Такие вторичные провайдеры предлагают продукта или услуги Интернет-телефонии под их собственной корпоративной маркой без необходимости создания инфраструктуры менеджмента и поддержки услуг первичной сети.

Системы биллинга и менеджмента пользователей вторичных провайдеров должен поддерживаться подобной системой первичного провайдера для обеспечения всех услуг IP- телефонии. Это дает возможность первичным провайдерам предложить их вторичным провайдерам полный диапазон услуг по биллингу и менеджменту — создание счетов, тарификация, расчет, составление счетов, менеджмент пользователями и выписка счетов.

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

Идентификация в реальном масштабе времени

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

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

Авторизация в реальном масштабе времени

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

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

Такие запросы означают, что система биллинга и менеджмента, используемая для IP- телефонии, должна позволять провайдерам выполнять авторизацию в реальном масштабе времени перед тем, как услуга будет доступна пользователю (см. рис. 7.3).

Создание новых услуг и планов тарификации

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

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

Поддержка комплекса услуг

Провайдер, который предлагает услуги IP-телефонии, как правило, предлагает и другие услуги связи на рынок. Эти услуги могут включать традиционную модемную связь для доступа в Интернет и электронной почты, а также другие выгодные бизнес-услуги: предоставление необходимой полосы пропускания в сети, виртуальная частная сеть (VPN) и видео- конференц связь.

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

Обеспечение качества обслуживания (QoS)

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

Как правило, пользователи IP-телефонии требуют обеспечения определенного качеств обслуживания, платя больше за более высокое качество и надежность или меньше — за

низкокачественные услуги, например, за одностороннюю связь. Система биллинга и менеджмента пользователей должна обеспечивать возможность провайдерам выбирать направление передачи вызовов: или через каналы сети Интернет с заранее определенной временной задержкой, или через частные IP-сети для самого высокого качества суживания, или через IP-сети общего пользования, когда стоимость, а не качество пере речи является более существенным фактором.

Гибкость системы

Чтобы оставаться лидерами в предоставлении любых IP-услуг, провайдеры дол иметь возможность быстро добавить или изменить услуги, информацию о пользователе, рифы и другие данные без прерывания выполняемых функций и без расходов на дополнительное программирование. Программное обеспечение системы биллинга и пользователей IP-телефонии должно строится по блочно-функциональному принципу обеспечения его быстрого внедрения у провайдера и возможностей масштабирования. Кроме этого, система должна работать с любым сетевым окружением для сбора детальной о вызовах (CDR) и интегрироваться с любыми прикладными системами финансов учета (рис. 7.4).

Поддержка шлюзов IP-телефонии

В настоящее время переход речевого трафика из коммутируемых сетей общего пользования в IP-сети обеспечивает различное оборудование шлюзов VoIP. Этот подход сто все более критическим местом для системы биллинга и менеджмента пользователей, так как она должна работать с разнообразными шлюзами VoIP. Кроме этого постоянно развитие аппаратно-программных средств IP-телефонии. Следовательно, перспективная

системы биллинга и менеджмента пользователей IP-телефонии должна обеспечить быструю и легкую интеграцию с новыми шлюзами и другими компонентами телефонной связи в единую систему (рис. 7.5).

7.3. Обзор систем биллинга и менеджмента пользователей IP-телефонии

Система Internet Management System

Система Internet Management System (IMS 3.1) фирмы Belle Systems является много- функциональной системой биллинга и менеджмента пользователей IP-телефонии, основан- ной на взаимодействии с сетевыми элементами. Данная система позволяет конфигурировать и управлять широким спектром сетевого оборудования, включая серверы доступа, маршрутизаторы и голосовые шлюзы фирмы Cisco. Интеграция с программным обеспечением фирм Atlantech Technologies и Orchestream, обеспечивает универсальный интерфейс для управления уровнем сетевых элементов. В систему встраивается сервер RADIUS для обеспечения идентификации пользователей при доступе через коммутируемую сеть. Система IMS обеспечивает гибкие схемы тарификации для пользователей, возможность контроля параметров AS, поддержку систем финансового учета и бизнес-управления типа Oracle Financials и SAP. для телефонных сетей общего пользования и мобильных сетей система IMS может интегрироваться с финансовыми системами фирм EHPT, Кепап и Saville на базе платформы CORBA. Система рассчитана на поддержку более 20 миллионов счетов и 1 миллиона пользователей.

Система iPhoneEX

Система биллинга и менеджмента пользователей IP-телефонии iPhoneEX 'фирмы MIND CTI полностью интегрирована со всеми версиями шлюзов VocalTec, а также работает с фирм Ascend, Lucent и Arelnet. Система может поддерживать от 100 до 100.000 пользователей. Составление счетов может выполняться из одного центрального пункта для всех узлов сети и в каждом узле сети.

Система IPhoneEX обеспечивает четыре различных формы расчетов с пользователями.

• Неограниченный кредит — пользователи имеют неограниченную возможность получения услуг Интернет-телефонии.

• Ограниченный кредит — при достижении предела кредита учетная запись автоматически блокируется в реальном масштабе времени и пользователю дается отказ в предоставлении услуг до оплаты кредита.

Дебетовая плата/Телефонные карточки — при достижении заранее оплаченного количества минут разговора дальнейшие запросы на услугу отвергаются и учетная запись блокируется.

Дебетовая плата с пополнением — производится определенная предоплата, когда стоимость разговоров достигает оплаченного количества, учетная запись блокируется, но имеется возможность доплатить снова.

В состав системы IPhoneEX входят следующие модули:

• Модуль межсетевого биллинга Inter-Billing system — обеспечивает взаиморасчеты между провайдерами Интернет-телефонии в сети. Модуль позволяет распределять затраты между различными узлами и различными операторами. Обеспечивает детальные сообщения данных по требованию для каждого провайдера.

• Модуль управления вызовами Call Management Module — обеспечивает пользователям большой набор сложных запросов сообщений управления. Система содержит мощный Генератор запросов, который позволяет пользователю генерировать настроенные сообщения с необходимой информацией. Все итоговые сообщения, созданные Генератором Запросов, могут быть представлены в графической форме.

• Модуль безопасности Guard Module — обеспечивает обнаружение несанкционированного доступа с помощью контроля за определенным набором параметров, задаваемых самим пользователем.

• Модуль трафика Traffic — является инструментом для анализа загрузок шлюза. Полученные данные могут служить основой для оптимального распределения ресурсов и наиболее эффективных мер экономии финансовых затрат. Возможна генерация сообщений, которые включают число вызовов в минуту для некоторой области, группу номеров, шлюзы и т.д.

Системные требования:

• Операционная система Windows NT 4;

• Процессор Pentium, оперативная память 64 Мбайт, жесткий диск 4 Гбайт.

Система Infranet IPT

Система Infranet IPT фирмы Portal Software объединяет управление всеми основными операциями бизнеса IP-телефонии, включая способность регистрировать, управлять пользователями и организовывать расчеты за предоставленные услуги. Ее архитектура функционирует в реальном масштабе времени и является открытой средой развития, обеспечивая платформу для создания службы управления телефонной связи в IP-сети.

Особенности работы системы Infranet IPT в реальном масштабе времени включают:

• регистрацию пользователя;

• идентификацию вызывающего абонента;

• проверку предела кредита;

• добавление к заранее оплаченной сумме и включение в учетную запись;

• работу с кредитными карточками;

• возможность выбора маршрута наименьшей стоимости;

• междоменное согласование и регулирование тарифов.

Система имеет специальную архитектуру абстрактного уровня шлюзов, которая позволяет настраивать работу со шлюзами IP-телефонии любого производителя. Infranet IFT может поддерживать обслуживание нескольких миллионов пользователей и ее программно обеспечение основывается на операционных системах HP UNIX, Microsoft Windows NT, SUN/Solaris и сервере Oracle или Microsoft SQL.

Система Talking NT Enterprise SQL

Система Talking NT Enterprise SQL фирмы Telephony Experts является мультимедийными приложением на основе операционной системы Windows NT, способным к обработан многих типов телефонных разговоров. Система интегрируется со шлюзом VocalTec управления трафиком, который терминирует шлюз. Система Talking NT включает базу денных сервера MS SQL и обеспечивает составление счетов в реальном масштабе времени, гиб- кий выбор маршрута наименьшей стоимости, качество обслуживания по требованию, предупреждение об окончании предоплаты, автоматическое завершение вызова при окончании оплаты, управление вызовом со стороны пользователя.

Система Talking NT обеспечивает следующие дополнительные возможности:

• заранее оплаченная и без предварительной оплаты дебетовая карточка;

• международный обратный вызов;

• 1 + набор номера (группа особенностей D);

• заранее оплаченный беспроводный доступ;

• услуги 800/888;

• услуга персонального номера;

• речевая почта с пейджингом;

• пополняемая кредитная карточка.

Пример использования системы Talking NT на сети показан на рис. 7.7.

Система Telephony Gateway Billing Manager

Система Telephony Gateway Billing Manager™ фирмы Telephony Experts (рис. 7.8) может применяться в сети IP-телефонии, построенной на базе шлюза Telephony Gateway™ Series 30™ и на Ensemble Architecture™ (VEA), используя VocalTec Gatekeeper. Система является платформой аутентификации и биллинга, основанной на Windows NT ™ и SQL Microsoft ™ Server 6.5 или выше. Стандартные особенности включают средства контроля доступа к услугам и биллинга в реальном времени на базе предоплаты или платы а также различные средства управления учетными записями. Система может масштабироваться для обработки фактически неограниченного числа учетных записей и может быть сконфигурирована для защищенного доступа в любой точке через Интернет.

Система BizBill

Биллинговая система BizBill фирмы Biztrans позволяет провайдерам Интернет предоставить услуги Интернет-телефонии через их узлы доступа и обеспечивает все расчетные операции s одном центре. Система BizBill обеспечивает интеграцию расчетов за Интернет и Интернет- телефонию, рассчитывает баланс и выдает необходимую информацию. Используемый в системе интерфейс Интернет дает возможность пользователю регистрироваться интерактивно. Система глотает под управлением Windows NT/95 и предназначена для работы со шлюзами VocalTec.

Система IAF Horizon

Система IAF Horizon фирмы Solect Technology Group является многофункциональной платформой для поддержки IP-услуг. Система используется с оборудованием IP-телефонии

ведущих производителей: Cisco, Ericsson, Nokia и Telcordia Technologies. В дополнение традиционным услугам тарификации IP-телефонии с предоплатой система IAF Horizon обеспечивает:

• предоставление услуг по заранее оплаченным телефонным карточкам с оценкой в реальном масштабе времени;

• поддержку управления вызовом во время соединения;

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

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

• простоту создания и управления алгоритмами тарификации, включая создание приличных вариантов тарификации применительно к географическим комбинациям;

• перенаправление вызова и блокирование номера;

• расширенные возможности составления счетов, например, с посекундной оплатой, а свободным периодом и с различными коэффициентами и параметрами дисконтированях Система IAF Horizon обеспечивает аутентификацию в реальном масштабе и расчет

абонентами сети Интернет-телефонии, построенной на базе оборудования фирм Cisco и Ericsson. Архитектура системы IAF Horizon показана на рис. 7.9.

Глава 8

БЕЗОПАСНОСТЫР-ТЕЛЕФОНИИ

8.1. Типы угроз в сетях IP-телефонии

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

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

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

3. Манипулирование данными Данные, которые передаются по каналам связи, в принципе можно изменить. Во многих методах шифрования используется технология защиты целостности данных, предотвращающая их несанкционированное изменение.

4. Отказ от обслуживания (Denial of Sепчсе — DoS) Отказ от обслуживания (DoS) является разновидностью хакерской атаки, в результате которой важные системы становятся недоступными. Это достигается путем переполнения системы ненужным трафиком, на обработку которого уходят все ресурсы системной памяти и процессора. Система связи должна иметь средства для распознавания подобных атак и ограничения их воздействия на сеть.

Базовыми элементами в области безопасности являются аутентификация, целостность и активная проверка. Аутентификация призвана предотвратить угрозу обезличивания и несанкционированного доступа к ресурсам и данным. Хотя авторизация не всегда включает в свой состав аутентификацию, но чаще всего одно обязательно подразумевает другое. Целостность обеспечивает защиту от подслушивания и манипулирования данными, поддерживая конфиденциальность и неизменность передаваемой информации. И, конец, активная проверка означает проверку правильности реализации элементов технологии безопасности и помогает обнаруживать несанкционированное проникновение в сеты атаки типа DoS.

8.2. Методы криптографической защиты информации

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

В системах обеспечения безопасности используются три основных криптографических метода:

• симметричное шифрование;

• асимметричное шифрование;

• односторонние хэш-функции.

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

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

В настоящее время широко используются алгоритмы секретных ключей типа Dats Encryption Standards (DES), ЗРЕЯ (или «тройной DES») и International Data Encryption Algorithm (IDEA). Эти алгоритмы шифруют сообщения блоками по 64 бита. Если объем сообщения превышает 64 бита (как это обычно и бывает), необходимо разбить его на блоки 64 бита в каждом, а затем каким-то образом свести их воедино. Такое объединение, как пpaвило, происходит одним из следующих четырех методов: электронной кодовой книги (ЕСВ), цепочки зашифрованных блоков (CBC), х-битовой зашифрованной обратной связи (CFB-х) или выходной обратной связи (OFB).

Шифрование с помощью секретного ключа чаще всего используется для поддержки конфиденциальности данных и очень эффективно реализуется с помощью неизменяемых «вшитых» программ (firmware). Этот метод можно использовать для аутентификации и поддержания целостности данных, но метод цифровой подписи является более эффективным.

Метод секретных ключей имеет следующие недостатки:

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

• трудно обеспечить безопасное генерирование и распространение секретных ключей. Асимметричное шифрование часто называют шифрованием с помощью общего ключа, котором используются разные, но взаимно дополняющие друг друга ключи и алгоритмы шифрования и расшифровки. Этот механизм полагается на два взаимосвязанных ключа: общего ключа и частного ключа. Наиболее типичные примеры использования алгоритмов общих ключей:

• обеспечение конфиденциальности данных;

• аутентификация отправителя;

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

Механизмы генерирования пар общих/частных ключей являются достаточно сложными, в результате получаются пары очень больших случайных чисел, одно из которых становится общим ключом, а другое — частным. Генерирование таких чисел требует больших процессорных мощностей, поскольку эти числа, а также их произведения должны отвечать строгим математическим критериям. Однако этот процесс генерирования абсолютно необходим для обеспечения уникальности каждой пары общих/частных ключей. Алгоритмы шифрования с помощью общих ключей редко используются для поддержки конфиденциальности данных из-за ограничений производительности. Вместо этого их часто используют в приложениях, где аутентификация проводится с помощью цифровой подписи и управления ключами.

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

Хэш-функция принимает сообщение любой длины и выдает на выходе хэш фиксированной длины. Обычные хэш-функци

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

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

Цифровым сертификатом называется сообщение с цифровой подписью, которое настоящее время обычно используется для подтверждения действительности общего ключа Цифровой сертификат в стандартном формате Х.509 включает следующие элементы:

• номер версии;

• серийный номер сертификата;

• эмитент информации об алгоритме;

• эмитент сертификата;

• даты начала и окончания действия сертификата;

• информация об алгоритме общего ключа субъекта сертификата;

• подпись эмитирующей организации.

На практике часто используют совместно шифрование и цифровые сертификаты. Например, маршрутизатор и межсетевой экран имеют по одной паре общих/частных ключей (рис. 8.1). Предположим, что эмитирующей организации (СА) удалось получить сертификаты Х.509 для маршрутизатора и межсетевого экрана по защищенным каналам. Далее предположим, что маршрутизатор и межсетевой экран тоже получили копии общего ключа СА защищенным каналам. Теперь, если на маршрутизаторе имеется трафик, предназначенный для межсетевого экрана, и если маршрутизатор хочет обеспечить аутентификацию и конфиденциальность данных, необходимо предпринять следующие шаги.

1. Маршрутизатор отправляет в эмитирующую организацию СА запрос на получения общего ключа межсетевого экрана.

2. СА отправляет ему сертификат межсетевого экрана, зашифрованный частным ключом СА

3. Маршрутизатор расшифровывает сертификат общим ключом СА и получает общий ключ межсетевого экрана.

4. Межсетевой экран направляет СА запрос на получение общего ключа маршрутизатора

5. СА отправляет ему сертификат маршрутизатора, зашифрованный частным ключом СА.

6. Межсетевой экран расшифровывает сертификат общим ключом СА и получает общий ключ маршрутизатора.

7. Маршрутизатор и межсетевой экран используют алгоритм Диффи-Хеллмана и шифрование с помощью общих ключей для аутентификации.

8. С помощью секретного ключа, полученного в результате использования алгоритма Диффи-Хеллмана, маршрутизатор и межсетевой экран проводят обмен конфиденциальными данными.

8.3. Технологии аутентификации

Под аутентификацией понимается определение пользователя или конечного устройства (клиента, сервера, коммутатора, маршрутизатора, межсетевого экрана и т.д.) и его местоположения в сети с последующей авторизацией пользователей и конечных устройств. Наиболее простым способом аутентификации является использование паролей, но для поддержания высокого уровня безопасности пароли приходится часто менять. Методы использования одноразовых паролей применяются по-прежнему широко. Среди них можно отметить методы аутентификации по протоколу S/Key или при помощи специальных аппаратных средств (Token Password authentication). Механизм аутентификации по протоколу РоЫ4о- Point Protocol (РРР) часто применяется в среде модемного доступа и включает использование

Extensible Authentication Protocol (EAP). Разработка протокола ЕАР все еще продолжается, но уже сейчас он дает возможность более гибкого использования существующих и только появляющихся технологий аутентификации в каналах РРР. TACACS+ и Remote Access Dial-In User Service (RADIUS) — это протоколы, которые поддерживают масштабируемые решения в ,области аутентификации. Протокол Kerberos (Цербер) используется в ограниченных областях для поддержки единой точки входа в сеть.

Система одноразовых паролей S/Кеу, определенная в RFC 17бО, представляет систему генерирования одноразовых паролей на основе стандартов MD4 и MD5. Она означена для борьбы «повторными атаками», когда хакер подслушивает канал, выделяет трафика идентификатор пользователя и его пароль и в дальнейшем использует их для нс. санкционированного доступа.

Система S/Кеу основана на технологии клиент-сервер, где клиентом обычно является персональный компьютер, а сервером — сервер аутентификации. Вначале и клиента, и сервер нужно настроить на единую парольную фразу и счет итерации. Клиент начинает обмен S/Кеу, отправная серверу пакет инициализации, а сервер в ответ отправляет порядковый номер и случайное так называемое «зерно» (seed). После этого клиент генерирует одноразовый пароль.

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

Аутентификация с помощью аппаратных средств работает по одной из двух альтернативных схем:

• по схеме запрос-ответ;

• по схеме аутентификации с синхронизацией по времени.

В схеме запрос-ответ пользователь подключается к серверу аутентификации, который, в свою очередь, предлагает ввести персональный идентификационный номер (PIN) пользовательский идентификатор (User ID). Пользователь передает PIN или user ID на сервер, который затем делает «запрос» (передает случайное число, которое появляется на экране на кредитную карточку, где число запроса шифруется с помощью пользовательском шифровального ключа. Результат шифрования отображается на экране. Пользователь справляет этот результат на сервер аутентификации. В то время как пользователь этот результат, сервер аутентификации рассчитывает этот же результат самостоятельно, используя для этого базу данных, где хранятся все пользовательские ключи. Получив отнят от пользователя, сервер сравнивает его с результатом собственных вычислений. Если сбоя результата совпадают, пользователь получает доступ к сети. Если результаты оказываются разными, доступ к сети не предоставляется.

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

Протокол PPP

Аутентификация на основе протокола Point-to Point Protocol (PPP) — это средство инкапсуляции (упаковки), которое часто используется в глобальных сетях. В ero состав входят три основных компонента:

• метод инкапсуляции дейтаграмм в последовательных каналах;

• протокол Link Control Protocol (LCP), который используется для установления, конфигурирования и тестирования связи;

• семейство протоколов Network Control Protocols (NCP) для установки и конфигурирования различных протоколов сетевого уровня.

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

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

Протоколы EAP и CТAP представляют собой два метода аутентификации протокола PPP. EAP — это общий протокол аутентификации PPP, который поддерживает множество идентификационных механизмов. Этот протокол находится в процессе доработки, и в будущем он сможет поддерживать более современные механизмы аутентификации в рамках аутентификации PPP. Аутентификация происходит после согласования LCP и до согласования IP Control Protocol (IPCP), в ходе которого происходит обмен адресами IP. Этот процесс аутентификации проходит в автоматическом режиме и не требует от пользователей ввода в компьютер каких-либо данных при подключении PPP. Часто аутентификация PAP или СНАР занимает место переговорного сценария, который отвечает на запросы о вводе сетевого имени пользователя (login) и пароля. CТAP поддерживает более высокий уровень безопасности, поскольку не передает реальный пароль по каналу PPP. Однако PAP используется чаще.

Протокол TACACS

TACACS — это простой протокол управления доступом, основанный на стандартах User Datagram Protocol (UDP) и разработанных компанией Bolt, Beranek and Newman, Inc. (BBN). Компания Cisco несколько раз совершенствовала и расширяла протокол TACACS, и в результате появилась ее собственная версия ТАСАСS, известная как TACACS+. TACACS+ пользуется транспортным протоколом TCP. Демон сервера «слушает» порт 49, который является портом протокола IP, для протокола TACACS. Этот порт зарезервирован для выделенных номеров RFC в протоколах UDP и TCP. Все текущие версии TACACS и расширенные варианты этого протокола используют порт 49.

Протокол TACACS+ работает по технологии клиент-сервер, где клиентом TACACS+ обычно является NAS, а сервером TACACS+, как правило, считается "демон" (процесс, за- пускаемый на машине UNIX или NT). Фундаментальным структурным компонентом протокола TACACS+ является разделение аутентификации, авторизации и учета (ААА

Authentication, Authorization, Accounting). Это позволяет обмениваться идентификационными сообщениями любой длины и содержания, и, следовательно, использовать для клиентов TACACS+ любой идентификационный механизм, в том числе PPP PAP, PPP CТAP, аппаратные карты и Kerberos (рис. 8.2). Аутентификация не является обязательной. Она рассматривается как опция, которая конфигурируется на месте. В некоторых местах она вообще требуется, в других местах она может применяться лишь для ограниченного набора услуг.

Авторизация — это процесс определения действий, которые позволены данному пользователю. Обычно аутентификация предшествует авторизации, однако это не обязательно. В запросе на авторизацию можно указать, что аутентификация пользователя не проведена (личность пользователя не доказана). В этом случае лицо, отвечающее за авторизацию, должно самостоятельно решить, допускать такого пользователя к запрашиваемым услуги или нет. Протокол TACACS+ допускает только положительную или отрицательную авторизацию, однако этот результат допускает настройку на потребности конкретного заказчика Авторизация может проводиться на разных этапах, например, когда пользователь впервые входит в сеть и хочет открыть графический интерфейс или когда пользователь запускает PPP и пытается использовать поверх PPP протокол IP с конкретным адресом IP. В этих случаях демон сервера TACACS+ может разрешить предоставление услуг, но наложить ограничения по времени или потребовать список доступа IP для канала PPP.

Учет обычно следует за аутентификацией и авторизацией. Учет представляет собой запись действий пользователя. В системе TACACS+ учет может выполнять две задачи. Во. первых, он может использоваться для учета использованных услуг (например, для выставления счетов). Во-вторых, его можно использовать в целях безопасности. Для этого ТАСАСР поддерживает три типа учетных записей. Записи «старт» указывают, что услуга должна быть запущена. Записи «стоп» говорят о том, что услуга только что окончилась. Записи "обновление" (update) являются промежуточными и указывают на то, что услуга все еще предоставляется. Учетные записи TACACS+ содержат всю информацию, которая используется в xone авторизации, а также другие данные: время начала и окончания (если это необходимо) и данные об использовании ресурсов.

Транзакции между клиентом TACACS+ и сервером TACACS+ идентифицируются с помощью общего «секрета», который никогда не передается по каналам связи. Обычно этот Секрет вручную устанавливается на сервере и на клиенте. TACACS+ можно настроить на шифрование всего трафика, который передается между клиентом TACACS+ и демоном TACACS+.

Протокол RADIUS

Протокол RADIUS был разработан компанией Livingston Enterprises, Inc. в качестве протокола аутентификации серверного доступа и учета. В настоящее время спецификация RADIUS (RFC 2058) и стандарт учета RADIUS (RFC 2059) предложены для утверждения в общепринятых стандартов IETF.

Связь между NAS и сервером RADIUS основана на протоколе UDP. В целом считается, что протокол RADIUS не имеет отношения к подключению. Все вопросы, связанные с сервера, повторной передачей данных и отключениями по истечении времени ожидания, контролируются устройствами, работающими под управлением протокола RADIUS, но не самим протоколом передачи.

Протокол RADIUS основан на технологии клиент-сервер (рис. 8.3). Клиентом RADIUS обычно является NAS, а сервером RADIUS считается «демон», работающий на машине UNIX или NT. Клиент передает пользовательскую информацию на определенные серверы RADIUS, а затем действует в соответствии с полученными от сервера инструкциями. Серверы RADIUS принимают запросы пользователей на подключение, проводят идентификацию пользователей, а затем отправляют всю конфигурационную информацию, которая необходима клиенту для обслуживания пользователя. Для других серверов RADIUS или идентификационных серверов других типов сервер RADIUS может выступать в роли клиент посредника (Proxy).

8.4. Особенности системы безопасности в IP-телефонии

В системе IP-телефонии должны обеспечиваться два уровня безопасности: системный и вызывной.

Для обеспечения системной безопасности используются следующие функции.

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

• Запись отказов в доступе.

• Функции безопасности интерфейса доступа, включая:

— проверку идентификатора и пароля пользователя с ограничением доступа по чтению/записи;

— проверку прав доступа к специальному WEB-серверу для администрирования.

• Функции обеспечения безопасности вызова включают:

— проверку идентификатора и пароля пользователя (необязательно); — статус пользователя; — профиль абонента.

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

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

• голос ТфОП — ТфОП;

• факс ТфОП — ТфОП;

• компьютер — ТфОП;

• службы, определенные пользователем (при помощи API).

Профиль абонента используется для проверки права доступа абонента к запрошенным службам.

8.5. Обеспечение безопасности в системах на базе стандарта Н.323

Для систем IP-телефонии, построенных на базе Рекомендации ITU-Т Н.323, вопросы безопасности рассматриваются в Рекомендации Н.235 (рис. 8.4). Эта рекомендация

а ряд технических требований, включая вопросы безопасности: аутентификация и шифрование данных. Предложенная схема обеспечения безопасности применима и к простым двухточечным и к многоточечным конференциям для любых терминалов, которые используют протокол управления Н.245. Если для IP-телефонии стандарта Н.323 используются сети с пакетной коммутацией, не обеспечивающие гарантированного качества обслуживания QoS, то по тем же самым техническим причинам не обеспечивается и безопасное обслуживание. Для обеспечения гарантированной связи в реальном масштабе времени по опасным сетям необходимо рассматривать две главных области обеспечения безопасности- аутентификация и секретность.

В соответствии с Рекомендацией Н.235 в системе должны быть реализованы четыре основные функции безопасности:

• аутентификация;

• целостность данных;

• секретность;

• проверка отсутствия долгов.

Аутентификация пользователя обеспечивается управлением доступа в конечной точа сети и выполняется gatekeeper, являющимся администратором зоны Н.323. Аутентификация основывается на использовании общих ключей с цифровым сертификатом. Для авторизации сертификатов они включают, например, идентификаторы провайдера услуг. Рекомендация Н.235 не определяет содержание цифровых сертификатов, используемых соответствующие протоколом аутентификации, а также их генерацию, администрирование и распределение.

Целостность данных и секретность обеспечивается криптозащитой. Проверка , вия долгов гарантируется тем, что конечная точка может отказать в обслуживании вызов, Для обеспечения безопасности согласно рекомендации Н.235 могут использоваться существующие стандарты: IP-безопасность (IP Security — IPSec) и безопасность транспортного ypoвня (Transport Layer Security — TLS).

Для обеспечения безопасной связи в системе на базе Рекомендации Н.323 используются механизмы защиты информации канала управления вызовами Q.931, информации канав управления для мультимедиа коммуникаций Н.245, информации каналов передачи мультимедиа. Канал управления вызовом (Н.225.0) и канал сигнализации (Н.245) должны оба работать в защищенном или незащищенном режимах, начинающимся с первой станции. Для канала управления вызовом защита сделана априорно (для систем в соответствии с Рекомендацией Н.323 безопасность транспортного уровня обеспечивается соответствующим протоколом ТИАР [порт 1300], который должен использоваться для Q.931 сообщений). Для канал сигнализации режим «защита» определяется информацией, переданной с помощью протокола начальной установки и подключения терминалов стандарта Н.323.

В целом следует отметить, что все основные механизмы аутентификации, определенные в Рекомендации Н.235, идентичны или получены из алгоритмов, разработанных Международной организации по стандартизации ISO, или основаны на протоколах IETF.

8.6. Механизмы безопасности в проекте TIPHON

В проект TIPHON включены следующие механизмы защиты для обеспечения безопасной телефонной связи с конечных устройств, основанные на приложении J Рекомендации ITU-Т Н.323:

• механизм защиты, основанный на цифровых сертификатах (CBSP);

• механизм защиты, основанный на паролях (PBSP);

• механизм защиты, основанный на шифровании информации

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

Криптографическая защита информации является необязательным требованием и используется только в сценариях, когда необходимо обеспечить секретность передаваемой информации. Оба механизма CBSP и PBSP используют модель безопасности при маршрутизации через шлюз на базе Приложения F Рекомендации Н.323.

8.7 Обеспечение безопасности на базе протокола OSP

Компании 3Com, Cisco Systems, GRIC Communications, iPass и TransNexus сообщили о предварительного стандарта IP-телефонии — Open Settlement Protocol (OSP для решения вопросов взаимодействия сетей различных провайдеров простой протокол, позволяющий различным компаниям — владельцам средств коммуникации в пределах всей страны. К примеру, он позволяет звонка, санкционировать обслуживание вызова и указывать расчетную будет включена в записи, содержащие подробные данные об этой транзакции.

European Telecommunications Standards Institute (ETSI) протокол, а производители в ближайшее время намерены провести его тестированный протокол был разработан в рамках проекта TIPHON. Протоколу OSP еще процедуру окончательной ратификации. Однако ведущие компании услуги IP-телефонии, включая Ascend, GTE, AT&T и Internet Telephony Exchange (ITXC), уже заявили о поддержке протокола OSP. В то же время компании Lucent и выразили свою заинтересованность и в целом готовы поддержать стандарты на IP-, но от окончательной оценки OSP пока воздержалась основные характеристики спецификации Open Settlement Protocol (OSP): Secure Sockets Layer;

Безопасная аутентификация участников сеанса связи с помощью шифрования открытым и частным ключами;

поддержка технологии цифровой подписи; обмен информацией с помощью XML.

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

8.8. Обеспечение безопасности IP-телефонии на базе VPN

Одним из механизмов обеспечения безопасности IP-телефонии может быть использование виртуальных частных сетей (Virtual Private Network, VPN).

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

Виртуальная частная сеть (VPN) создается между инициатором туннеля и туннеля. Обычная маршрутизируемая сеть IP (она не обязательно включает в себя обще - доступную сеть Интернет) определяет маршрут между инициатором и терминатором. Инициатор туннеля инкапсулирует пакеты в новый пакет, содержащий наряду с исходными данными новый заголовок с информацией об отправителе и получателе. Хотя все передаваемые по туннелю пакеты являются пакетами IP, в принципе, инкапсулируемые пакеты могут принадлежать к протоколу любого типа, включая пакеты немаршрутизируемых протоколов, например, NetBEUI. Терминатор туннеля выполняет процесс, обратный инкапсуляции, ударяя новые заголовки и направляя исходный пакет в локальный стек протоколов или адресату в локальной сети.

Сама по себе инкапсуляция никоим образом не повышает конфиденциальности или туннелируемых данных. Конфиденциальность обеспечивается с помощью Поскольку методов шифрования данных существует множество, очень важно, что- бы инициатор и терминатор туннеля использовали один и тот же метод. Кроме того, для дешифрования данных они должны иметь возможность обмена ключами. Чтобы туннели создавались только между уполномоченными пользователями, конечные точки требуется идентифицировать. Целостность туннелируемых данных можно обеспечить с помощью некоей формы выборки сообщения или хэш-функции для выявления изменений или, удалений. Для реализации унифицированного способа инкапсуляции трафика третьего уровня (высоких уровней) на клиентах и серверах Windows компании Microsoft, Ascend Communications и 3Com разработали туннельный протокол между двумя точками (Pointto- Foint Tunneling Protocol, PPTP), представляющий собой расширение протокола PPP. В PPTP специфицируется конкретный метод шифрования, однако, клиенты удаленного доступа в Windows NT 4.0 и Windows 95 с Dial-Up Networking 1.2 поставляются с версией шифрования DES компании RSA Data Security, получившей название «шифрование двухточечной связи Microsoft» (Microsoft Point-to-Point Encryption, MPPE). Компания Cisco Systems разработала протокол пересылки на втором уровне модели OSI (Layer-2 Forwarding, L2F), с помощью которой удаленные клиенты могут связаться по каналам провайдера Internet и быть идентифицированы. При этом ISP не нужно осуществлять конфигурацию адресов и выполнять идентификацию.

Протокол L2F стал компонентом операционной системы IOS (Internetwork Operating System) компании Cisco и поддерживается во всех выпускаемых ею устройствах межсетевого взаимодействия и удаленного доступа. Оба этих тесно связанных друг с другом протокола IETF были объединены, и получившийся в результате протокол, включивший лучшее из PPTP и L2F, называется проток лом туннелирования второго уровня (Layer-2 Tunneling Protocol, L2TP). Его поддерживают компании Cisco, Microsoft, 3Com, Ascend и многие другие производители. Как и предшествующие протоколы второго уровня, спецификация L2TP не описывает методы идентификации и шифрования. Спецификацией IETF, где описаны стандартные методы для всех компонентов VPN, является протокол Internet Protocol Security, или IPSec, — иногда его называют туннелированием третьего уровня (Layer-3 Tunneling). IPSec предусматривает стандартные методы идентификации пользователей или компьютеров при инициации туннеля, стандартные способы использования шифрования конечными точками туннеля, а также стандартные методы обмена и управления ключами шифрования между конечными точками. Этот гибкий стандарт предлагает несколько способов для выполнения каждой задачи. Выбранные методы для одной задачи обычно не зависят от методов реализации других задач. Идентификацию можно выполнять с помощью спецификации IPSec, причем она является обязательным компонентом протокола IPv6. IPSec может работать совместно с L2TP, в результате эти два протокола обеспечивают, надежную идентификацию, стандартизованное шифрование и целостность данных.

Следует отметить, что спецификация IPSec ориентирована на IP и, таким образом, для трафика любых других протоколов сетевого уровня. Туннель IPSec между двумя сетями может поддерживать множество индивидуальных каналов передачи данных, в результате чего приложения данного типа получают преимущества с точки зрения масштабирования по сравнению с технологией второго уровня. Некоторые поставщики VPN используют другой подход под названием «посредники сигналов» (circuit proxy), или VPN пятого уровня. Этот метод функционирует над транспортным уровнем и ретранслирует трафик из защищенной сети в общедоступную сеть Internet каждого сокета в отдельности. (Сокет IP идентифицируется комбинацией ТСР- соединению конкретного порта или заданным портом UDP. Протокол IP не имеет пятого — сеансового- уровня, однако ориентированные на сокеты операции часто называют операциями сеансом. го уровня.)

Шифрование информации, передаваемой между инициатором и терминатором ля, часто осуществляется с помощью защиты транспортного уровня (Transport Layer Secure, TLS), ранее протокола защищенных сокетов (Secure Sockets Layer, БЯ.). Для стандартизации аутентифицированного прохода через брандмауэры IETF определил протокол под названием SOCKS, и в настоящее время SOCKS 5 применяется для стандартизованной реализации средников каналов.

В SOCKS 5 клиентский компьютер устанавливает аутентифицированный сокет (или сеанс) с сервером, выполняющим роль посредника (proxy). Этот посредник — единственными способ связи через брандмауэр. Посредник, в свою очередь, проводит любые операции, запрашиваемые клиентом. Поскольку посреднику известно о трафике на уровне сокета, он может осуществлять тщательный контроль, например, блокировать конкретные приложению пользователей, если они не имеют необходимых полномочий. Для сравнения, виртуальную частные сети уровня 2 и 3 обычно просто открывают или закрывают канал для всего трафим по аутентифицированному туннелю. Это может представлять проблему, если нет гарантии защиты информации на другом конце туннеля.

Следует отметить на наличие взаимосвязи между брандмауэрами и VPN. Если туннеля завершаются на оборудовании провайдера Интернет, то трафик будет передаваться по вашей локальной сети или по линии связи с провайдером Интернет в незащищенном виде. Если конечная точка расположена за брандмауэром, то туннелируемый трафик можно контролировать с помощью средств контроля доступа брандмауэра, но никакой дополнительной щиты при передаче по локальной сети это не даст. В этом случае конечную точку будет связывать с брандмауэром незащищенный канал.

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

Как и любая другая вычислительная функция, работа по созданию сетей VPN проводится с помощью программного обеспечения. Между тем программное обеспечение для VPN может выполняться на самых разных аппаратных платформах. Маршрутизаторы или коммутаторы третьего уровня могут поддерживать функции VNP по умолчанию (или в качестве дополнительной возможности, предлагаемой за отдельную плату). Аппаратно и программно реализуемые брандмауэры нередко предусматривают модули VPN со средствами управления трафиком или без них. Некоторые пограничные комбинированные устройства включают в себя маршрутизатор, брандмауэр, средства управления пропускной способностью и функции VPN (а также режим конфигурации). Наконец, ряд чисто программных продуктов выполняется на соответствующих серверах, кэширует страницы Web, реализует функции брандмауэра и VPN.

Механизм VPN немыслим без идентификации. Инфраструктура с открытыми ключами (Public Кеу Infrastructure, PKI) для электронной идентификации и управления открытыми мечами является в настоящее время основной. Данные PKI целесообразнее всего хранить в глобальном каталоге, обращаться к которому можно по упрощенному протоколу доступа к каталогу (Lightweight Directory Access Protocol, LDAP).

В табл. 8.2 представлены некоторые системы для организации взаимодействия между пользователями VPN в сети Интернет-телефонии.

8.9. Реализация функций ФОРМ в IP-телефонии

Так как в сетях IP-телефонии используется передача речевой информации между, то такие сети подпадают под действие системы оперативно-разыскных мероприятий (ФOPM). Для реализации необходимых функций ФOPM необходимо обеспечить возможность фиксации не только всей справочной информации о телефонных вызовах (источники получатель вызова, дата и время разговора и др.), но и возможность полной записи разговора В сети IP-телефонии реализация функций ФOPM может быть различным способами. В том случае, когда вызывающий абонент включен в телефонную сеть пользования (например, сценарии 2 и 3 проекта TIPHON), то функции ФOPM реализуют существующими средствами на телефонных станциях.

При включении исходящих терминалов (например, терминалов Н.323 на базе перс сальных компьютеров) IР-сеть реализации функций COP должны решаться в оборудовании доступа сети с пакетной коммутацией (серверы маршрутизаторы, коммутаторы и др.).