О структуре и свойствах современных пакетных сетей

Сергей Андронов

Введение

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

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

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

Протокол Frame Relay

Протокол Frame Relay обеспечивает коммутацию пакетов между пользовательскими интерфейсами – оконечным оборудованием данных (Data Terminal Equipment, DTE) и сетевыми интерфейсами (интерфейсами коммутаторов) – оконечным оборудованием каналов передачи данных (Data Circuit-terminating Equipment, DCE) (см. рисунок).

Структура сети с протоколом Frame Relay

Как протокол канального уровня, Frame Relay во многом подобен соответствующим элементам семейства X.25, однако отличается по своей функциональности и формату передаваемых пакетов. В частности, Frame Relay лучше структурирован и обеспечивает более высокую производительность и эффективность использования сетей.

Frame Relay поддерживает статистическое мультиплексирование многочисленных логических соединений по единственному физическому каналу. Такой подход существенно отличается от систем с TDM (Time Division Multiplexing) – мультиплексированием (разделением) по времени. Статистическое мультиплексирование Frame Relay обеспечивает более эффективное и гибкое использование полосы пропускания сети и может применяться самостоятельно или в каналах на базе TDM.

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

Еще одним существенным отличием Frame Relay от X.25 является отсутствие явного (по виртуальным соединениям) управления потоком данных, поскольку в наше время подобные функции управления эффективно реализуются протоколами более высоких уровней. Вместо этого используется механизм уведомлений о приближении к состоянию насыщения, которые передаются на вышележащие уровни, где и реализуются функции управления потоком данных. Более точно, сообщения Backward Explicit Congestion Notification (BECN) передаются в направлении, противоположном затору, для уведомления передающей стороны, а сообщения Forward Explicit Congestion Notification (FECN) уведомляют принимающую сторону.

Современный стандарт Frame Relay поддерживает постоянные виртуальные соединения (Permanent Virtual Circuits, PVC), настраиваемые и управляемые в масштабах сети. Другим типом являются коммутируемые виртуальные соединения (Switched Virtual Circuits, SVC).

В контексте данной статьи наиболее существенными представляются следующие особенности протокола Frame Relay:

• поддержка нескольких виртуальных соединений на один физический порт, множественные PVC;
• управление скоростью передачи:
• гарантированная скорость передачи (Committed Information Rate, CIR),
• форсированная скорость передачи (Excess Information Rate, EIR);
• поддержка уведомлений о насыщении сети.

Протокол ATM

ATM (Asynchronous Transfer Mode) является коммутируемой технологией, предназначенной для одновременной передачи голоса и данных в виде ячеек (cell) фиксированной длины, что уменьшает время на обработку и позволяет обеспечить более равномерную загрузку процессора.

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

Мы остановимся на следующих особенностях сетей ATM:

• ATM-сеть – это сеть с установлением соединений (connection-oriented);
• сети ATM – это коммутируемые сети.

Сети с установлением соединений

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

Сети с установлением соединений могут гарантировать определенное качество сервиса (Quality of Service, QoS). ATM-QoS включает в себя следующие параметры:

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

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

Архитектура ATM

Архитектура (модель) ATM разработана организациями по стандартизации ANSI, ITU и ATM Forum. Данная модель состоит из трех уровней:

• физического;
• уровня ATM;
• уровня адаптации ATM.

Основные элементы архитектуры ATM

Модель ATM проиллюстрирована на рисунке. Ниже приводится более подробная информация о каждом из уровней.

Физический уровень

Стандарты ATM для физического уровня определяют, как получать биты из среды передачи, преобразовывать их в ячейки и посылать эти ячейки уровню ATM. Кроме того, они описывают, какие кабельные системы должны использоваться в сетях ATM и с какими скоростями может работать ATM при каждом типе кабеля. На сегодняшний день наиболее распространенные скорости составляют 25, 155 и 622 Мбит/с.

Скорость 25 Мбит/с поддерживается на:

• неэкранированной витой паре (UTP) категории 3 и выше;
• оптоволокне.

Скорость 155 Мбит/с обеспечивается на:

• UTP категории 5;
• экранированной витой паре (STP) типа 1;
• оптоволоконном кабеле.

Скорость 622 Мбит/с гарантируется только на оптоволоконном кабеле.

Уровень ATM

Стандарты для уровня ATM описывают механизмы:

• получения ячеек;
• формирования заголовков и посылки ячеек уровню адаптации ATM;
• установки соединения с требуемым качеством сервиса (QoS).

Уровень адаптации ATM и качество сервиса

В эталонной семиуровневой модели ISO/OSI стандарты для сетевого уровня определяют, как осуществляется маршрутизация пакетов и управление ими. На уровне адаптации ATM выполняются три аналогичные функции:

• форматируются пакеты;
• предоставляется информация для уровня ATM, которая дает возможность устанавливать соединения с определенным качеством сервиса;
• предотвращаются "заторы".

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

Уровень адаптации ATM определяет также четыре категории сервиса:

• постоянная скорость передачи (Constant Bit Rate, CBR);
• переменная скорость передачи (Variable Bit Rate, VBR);
• неопределенная скорость передачи (Unspecified Bit Rate, UBR);
• доступная скорость передачи (Available Bit Rate, ABR).

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

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

Категория VBR существует в двух видах, которые используются для различных типов трафика:

• VBR реального времени (Real-Time VBR, RT-VBR) применяют, когда требуется жесткая синхронизация между ячейками и поддержка чувствительного к задержкам трафика;
• VBR без требований реального времени (Non-Real-Time VBR, NRT-VBR) не нуждается в жесткой синхронизации между ячейками и поддерживает допускающий задержки трафик.

Поскольку VBR не резервирует полосу пропускания, канал используется более эффективно, чем в случае CBR. Однако, в отличие от CBR, VBR не может гарантировать качества сервиса.

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

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

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

CBR, VBR, UBR, и ABR включают в себя следующие параметры качества сервиса (QoS):

• коэффициент потерь ячеек (Cell Loss Ratio) определяет, какой процент высокоприоритетных ячеек может быть потерян за время передачи;
• задержка передачи ячейки (Cell Transfer Delay) определяет время (или среднее время), требуемое для доставки ячейки адресату;
• вариации задержек при передаче ячеек (Cell Delay Variation, CDV), большая величина CDV приводит к прерыванию аудио- и видеосигналов.

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

Современные аспекты IP-сетей

Требования к IP-сетям

Протокол IP является фактическим стандартом при построении корпоративных сетей передачи данных. На повестке дня – создание единых, "конвергированных" сетей, обеспечивающих передачу данных, голоса и видео.

К конвергенции подталкивают следующие обстоятельства:

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

Для достижения поставленных целей необходимо решить ряд проблем.

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

Для обеспечения приемлемого голосового потока время задержки должно составлять менее 300-600 мс.

Задержки могут возникать на следующих этапах:

• подготовка (кодирование и/или сжатие) и отправка голосового потока;
• передача по сети;
• декодирование на принимающей стороне.

Перечисленные этапы показаны на рисунке. При передаче аудиопотока необходимо контролировать величину задержки на каждом из них.

Основные этапы обработки потоков аудиоданных

Пути изменения структуры и свойств IP-сетей

Ключевыми характеристиками сети при передаче аудио- и видеопотоков являются пропускная способность и качество сервиса.

Наращивание полосы пропускания может происходить за счет перехода на более высокоскоростные интерфейсы и/или технологии. Обычно такое решение является дорогостоящим, так как требует закупки нового сетевого оборудования. Кроме того, оно (решение), как правило, оказывается краткосрочным, поскольку расширенная полоса пропускания быстро "съедается" новыми сетевыми приложениями.

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

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

Для реализации механизмов QoS в заголовке IP-пакета предусмотрено поле типа сервиса размером 8 бит (Type of Service, ToS, см. также [1]), которое задает характер обработки пакета в процессе транспортировки последнего.

Можно управлять следующими параметрами:

• приоритет;
• величина задержек;
• уровень надежности;
• пропускная способность;
• надежность.

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

Распределение разрядов в поле типа сервиса представлено в табл. 1, а назначение различных комбинаций – в табл. 2.

Таблица 1. Распределение разрядов в поле типа сервиса IP-пакета.

Таблица 2. Назначение различных комбинаций в поле типа сервиса IP-пакета.

Механизмы обеспечения качества сервиса

Качество сервиса в IP-сетях определяется следующими параметрами:

• готовность (service availability): надежность соединения пользователя с информационным сервисом;
• задержка (delay): интервал времени между отправлением и получением пакета;
• вариация задержки (delay variation): допустимый интервал между пакетами в потоке;
• пропускная способность (throughput): допустимая пиковая загруженность сети;
• коэффициент потери пакетов (packet loss rate).

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

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

Существует две архитектуры IP-QoS, утвержденные комитетом IETF:

• архитектура с интеграцией сервисов (Integrated Service Architecture, Int-Serv);
• архитектура с дифференциацией сервисов (Differentiated Services Framework, Diff-Serv).

Архитектура QoS Int-Serv

В основе архитектуры Int-Serv (см. [2]) лежит протокол резервирования ресурсов – RSVP (Resource ReSerVation Protocol). Данный протокол позволяет зарезервировать определенную долю сетевых ресурсов, необходимую информационному потоку, на протяжении всего маршрута от станции отправителя до станции получателя. Более подробное описание RSVP дается в следующем разделе. Здесь же мы ограничимся аналогией с коммутируемыми виртуальными соединениями ATM (ATM SVC).

Архитектура QoS Diff-Serv

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

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

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

Продвижение IP-трафика внутри зоны, поддерживающей качество сервиса

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

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

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

Дифференциация сервисов – это относительно новый подход и далеко не все удалось стандартизовать. Основные проблемы состоят в отсутствии:

• стандарта на поле DS;
• утвержденного количества классов обслуживания и их описания;
• механизма эффективной агрегации потоков (на уровне транзитных маршрутизаторов);
• решений по интерпретации с технологией ATM;
• механизма управления.

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

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

По поводу пункта 4 отметим, что хотя вопросы обеспечения качества сервиса в ATM стандартизированы, вопрос трансляции IP QoS в ATM QoS остается открытым.

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

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

Протокол RSVP

Протокол резервирования ресурсов (RSVP – Resource ReSerVation Protocol) – это протокол "точка-точка". Подобно ICMP и IGMP, он является протоколом управления и функционирует в совокупности с протоколами маршрутизации.

Основными компонентами RSVP являются:

• отправитель;
• получатель;
• маршрутизаторы и хосты, находящиеся на пути от получателя к отправителю;
• потоки (совокупность IP-пакетов, посылаемых отправителем одному или более получателям, с соответствующим потоку идентификатором – FlowLabel).

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

В ответ получатель рассылает заявки на резервирование ресурсов всем узлам, находящимся на выбранном маршруте. Данная заявка содержит в себе, помимо IP-адреса отправителя и получателя, поля FlowSpec, AdmissionControl и PolicyControl. Поле AdmissionControl содержит информацию о возможности отправителя предоставить требуемое качество сервиса, а поле PolicyControl характеризует права получателя на проведение операции резервирования QoS. Если оба поля (AdmissionControl и PolicyControl) установлены верно, узел, получающий данную заявку, резервирует требуемые ресурсы.

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

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

Таким образом, механизм RSVP выглядит следующим образом:

• отправитель посылает PathMessage-сообщение получателю;
• получатель получает PathMessage;
• получатель посылает заявку на резервирование QoS на маршрутизаторы между отправителем и получателем;
• каждый маршрутизатор, получив заявку, проверяет поля AdmissionControl и PolicyControl и в случае их достоверности резервирует требуемый QoS;
• отправитель получает уведомление о резервировании QoS;
• отправитель начинает передачу потока пакетов.

Рассмотрим пример (см. рисунок). Пусть станция-отправитель подключена по технологии Fast Ethernet (100 Мбит/с), получатель A – по технологии ATM (155 Мбит/с), получатель B – по технологии Token Ring (16 Мбит/с).

Конфигурация, на примере которой иллюстрируется работа протокола RSVP

Допустим, требуемая полоса пропускания составляет 30 Мбит/с. В этом случае получатель A может запрашивать полную пропускную способность – 30 Мбит/с, а получатель B вынужден использовать сжатие данных, в результате чего экономится часть полосы пропускания. Передача между отправителем и получателями осуществляется до тех пор, пока выполняются характеристики QoS, заданные в поле FlowSpec.

Действия, выполняемые в рамках RSVP отправителем, получателем и промежуточными маршрутизаторами, показаны на рис. 6.

Действия, выполняемые отправителем, получателем и промежуточными маршрутизаторами

При использовании протокола RSVP особое внимание следует уделить следующим аспектам:

• Масштабируемость. Одновременная активность большого количества потоков с высокой пропускной способностью может вызвать перегрузку маршрутизаторов, что влечет блокировку или задержку передачи других критичных данных. Пока IETF не предлагает стандартных механизмов разрешения этой проблемы. Рекомендуется не использовать RSVP на магистральных маршрутизаторах (ограничиваясь периферией сети).
• Безопасность. Следующая сложность, связанная с использованием RSVP, – несанкционированный захват или сокрытие сетевых ресурсов. Такая ситуация возможна в случае, если злоумышленник прослушивает сеть с целью перехвата сообщений PathMessage. В IETF разрабатывается документ RSVP Cryptographic Authentication для обеспечения криптозащиты передаваемых служебных данных; в будущем он, вероятно, обеспечит кардинальное решение. Пока рекомендуется контролировать и протоколировать изменения в служебной информации, особое внимание уделяя полю FlowSpec (спецификатор IP-потока, см. [1] и [4]).
• Политика управления. Протокол RSVP предусматривает и описывает транспортную политику. В то же время в RSVP не описана политика управления. Не определены механизмы того, кто может (должен) осуществлять резервирование, а также средства проверки подлинности. Для решения данной проблемы в рамках комитета по RSVP создана специальная рабочая группа. Решение по поддержке политики безопасности подразумевает использование сервера авторизации, к которому осуществляются запросы при резервировании ресурсов на маршрутизаторе. На момент написания статьи деятельность рабочей группы не была закончена.

Пример поддержки качества сервиса – маршрутизаторы компании Bay Networks

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

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

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

• 3Com;
• Bay (Nortel) Networks;
• CEFRIEL/Politecnico di Milano;
• Cisco Systems;
• Extreme Networks;
• Fore Systems;
• Furukawa Electric;
• IBM.

Характерным примером реализации архитектуры с дифференциацией сервисов является разработка компании Bay Networks (ныне входящей в компанию Nortel Networks) – программное обеспечение для маршрутизаторов BayRS, версии 13.20. Специалистам компании удалось обеспечить простой и стандартный подход к приоритезации приложений и управлению полосой пропускания.

Согласно утверждению Michael J. Hopey (сетевой аналитик университета Нью-Брунсвика), сделанному по результатам тестирования ПО BayRS 13.20, последнее обеспечивает такие услуги, как видео (H.323), и позволяет ограничивать полосу пропускания для обычных, неприоритетных приложений.

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

Классы обслуживания трафика определяются в поле IP заголовка, именуемом байтом DSCP (Differentiated Services Code Point). Идентифицированные таким образом пакеты сохраняют приоритет по всей сети. Маршрутизаторы, на которых работает ПО BayRS 13.20, могут просматривать и устанавливать или сбрасывать байт DSCP в зависимости от правил, определенных для пользователя или приложений.

Еще одна функция, поддерживаемая в ПО BayRS 13.20 и играющая важную роль в сетевом администрировании, – это протокол COPS (Common Open Policy Services, проект IETF). Реализация этого протокола в продуктах Nortel Networks упрощает контроль правил, обеспечивая стандартный механизм связи маршрутизаторов BayRS и централизованных серверов правил.

Программное обеспечение BayRS функционирует на платформах BayStack Access Node (AN) и Access Node Hub (ANH), BayStack Access Remote Node (ARN), BayStack Access Stack Node (ASN), Backbone Node (BN).

Кроме перечисленных функций, программное обеспечение BayRS 13.20 предоставляет новые возможности многоадресной передачи, обеспечивая поддержку стандартного режима PIM-SM (Protocol Independent Multicasting – Sparse Mode), а также широкого спектра других новых функций для предприятий и поставщиков услуг.

Заключение

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

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

Литература

1. Владимир Галатенко , Мирослав Макстенек , Илья Трифаленков – Сетевые протоколы нового поколения. – Jet Info, 7-8, 1998
2. R. Braden , D. Clark , S. Shenker – Integrated Services in the Internet Architecture: an Overview. – RFC, 1633, 1994
3. R. Braden (ред.)L. Zhang , S. Berson , S. Herzog , S. Jamin – Resource ReSerVation Protocol (RSVP). – RFC, 2205, 1997
4. Даниил Виняр – Анализ современных методов маршрутизации. – Jet Info, 2-3, 1998

Статья опубликована в журнале Jet Info, №6, 1999 г.