Сегодня мы присутствуем при появлении новой концепции — сетей с интеграцией сервисов (СИС), которые наследуют лучшие свойства своих предшественников.
Эволюция сетевых технологий
Телефонные сети
Телефонные сети общего пользования появились еще в прошлом веке. Их современное состояние стало результатом развития цифровых технологий передачи данных и мультиплексирования каналов. Примечательно, что более чем за сто лет цифровые технологии (прежде всего — методы уплотнения и передачи, PDH, а затем и SDH) модернизировали лишь опорную структуру ТфОП, в то время как средства доступа принципиально не изменились: они по-прежнему ориентированы на аналоговый канал, сформированный при помощи медной пары.
В 80-е гг. телефонные компании предприняли попытку адаптироваться к изменившимся условиям и предоставить клиентам новый тип услуги — ISDN. Но и эта технология не отошла от общих принципов построения ТфОП, поэтому получила меньшее распространение, чем ожидалось. Некоторые компоненты ISDN, однако, оформились в самостоятельные технологии; примером может служить семейство методов доступа к СПД по цифровым абонентским линиям (xDSL).
Сети передачи данных
Строительство первой глобальной сети передачи данных ARPANET, основанной на коммутации пакетов, началось в США около 30 лет назад. В 1974 г. на базе пятилетних исследований сети ARPANET была разработана модель TCP/IP, которая вскоре дополнилась другими протоколами и оказалась «двигателем» Internet.
C развитием инфраструктуры глобальных сетей, ростом их пропускной способности и уменьшением задержек, связанных с обработкой пакетов, видоизменялись и сетевые приложения. В частности, возросла доля трафика, приходящегося на мультимедиа-объекты, появился ряд совершенно новых мультимедийных сервисов, например аудио и видео по запросу, IP-телефония.
Сети ATM
Метод асинхронной передачи, основанный на коммутации ячеек данных, представляет собой определенный компромисс между двумя указанными выше группами технологий. Для обмена данными он требует предварительной установки (и резервирования) виртуального канала, по которому будут передаваться ячейки, но пользуется преимуществами статистического мультиплексирования. В совершенствовании технологии АТМ принимают активное участие как компании, традиционно специализировавшиеся на СПД, так и представители телефонии. Поэтому АТМ отлично подходит и для сетей передачи данных, и для сетей с интеграцией сервисов и телефонных систем.
Весьма элегантная и хорошо продуманная технология асинхронной передачи, однако, не получила того распространения, особенно в области ЛВС, которое предрекали эксперты. Произошло это главным образом потому, что в качестве универсальной сетевой среды АТМ оказалась сложной в настройке и сопровождении, а соответствующее оборудование — сравнительно дорогим. Тем не менее АТМ определенно имеет будущее и как самостоятельная технология, и как составная часть СИС.
Появление концепции СИС
 |
| Рис. 1. Эволюция основных телекоммуникационных систем |
Сети с интеграцией сервисов, позволяющие объединить различные типы трафика — от обычных данных до аудио и видео в реальном времени, — и стали качественным скачком в развитии сетевых технологий. СИС унаследовали лучшие свойства своих предшественников — ТфОП и СПД (рис. 1). На роль основы таких сетей наилучшим образом подходит технология коммутации пакетов, используемая в Internet и позаимствовавшая некоторые важные свойства у сетей с коммутацией каналов.
Составные части СИС
Чтобы IP-сеть превратилась в сеть с интеграцией услуг, необходимо поменять саму модель обслуживания Internet (сказанное относится к любой сети, использующей стек протоколов TCP/IP). Правда, такое изменение не означает полного отказа от старой модели «best effort», в соответствии с которой оборудование IP-коммутации старается доставить данные как можно быстрее. Документ RFC 1633 определяет расширение модели обслуживания Internet как архитектуру интегрированных сервисов (Integrated Services Architecture), чьей основой являются две важные концепции.
Во-первых, нужно, чтобы ресурсы сети допускали явное управление, иначе не удастся гарантировать качество обслуживания (QoS). В результате механизм резервирования ресурсов и система управления соединениями становятся главными составляющими СИС. Дабы обеспечивать определенный уровень QoS, маршрутизаторы должны резервировать ресурсы под нужды отдельных потоков и, соответственно, хранить информацию о проходящих через них потоках. Именно этот факт и означает отход от традиционной концепции СПД, подразумевающей, что каждый пакет обрабатывается независимо от предыдущих.
Другими словами, сетевые устройства СИС должны управлять судьбой любого пакета в потоке. Потоком называется последовательность пакетов, для которых требуется одинаковое качество обслуживания. IP-адрес, тип и порт транспортного протокола получателя определяют поток, который в СИС является наименьшим объектом, различимым сетевыми устройствами и допускающим задание параметров QoS.
Во-вторых, для реализации функций передачи обычных данных, трафика реального времени и мультимедийного трафика нужно задействовать единую сетевую инфраструктуру и одно семейство протоколов. Совместная транспортировка по одной сети различных типов трафика дает не только те преимущества, которые были упомянуты выше; она выгодна еще и потому, что увеличивает эффективность использования сетевых ресурсов за счет статистического мультиплексирования потоков.
В рамках модели интеграции сервисов (ИС) сеть должна предоставлять приложениям несколько классов обслуживания с варьируемыми параметрами. Практически все существующие приложения можно разделить на три основных типа: неадаптивные приложения реального времени, адаптивные реального времени и «эластичные» (см. таблицу). Запросы «эластичных» приложений наилучшим образом удовлетворяются классом сервиса Internet «best effort», а вот два других типа требуют более предсказуемого поведения сети по отношению к генерируемому или обрабатываемому ими трафику. Поэтому в дополнение к «best effort» в архитектуру ИС были включены еще два класса: гарантированного сервиса (guaranteed service) и сервиса контролируемой загрузки (controlled load service).
Типы и характеристики сетевых приложений
| Тип приложений | Характеристика | Пример |
| Неадаптивные приложения реального времени | Если данные не доставляются вовремя, они оказываются бесполезными | Дистанционное управление, мультимедиа-потоки без буферизации, приложения, ориентированные на сервис сети с коммутацией каналов, некоторые виды распределенных систем |
| Адаптивные приложения реального времени | Данные, доставленные немного раньше или немного позже требуемого времени, будут использованы | Мультимедиа-потоки с адаптивной буферизацией, приложения с низким уровнем интерактивности, приложения, ориентированные на мультимедиа-сервисы Internet, инструменты mbone |
| Гибкие, или «эластичные», приложения | Данные будут использованы сразу после получения | Традиционные протоколы обмена данными — HTTP, FTP, SMTP и др.; большинство «традиционных» приложений Internet |
Класс гарантированного сервиса ориентирован на неадаптивные приложения реального времени. Он вводит жесткие ограничения на задержку и гарантирует отсутствие потерь пакетов при буферизации в процессе передачи, если характеристики потока соответствуют указанным в спецификации.
Класс сервиса контролируемой загрузки должен обеспечивать потребности адаптивных приложений реального времени и мультимедиа-программ. Приложения получают сервис, аналогичный классу «best effort» в состоянии малой нагрузки, однако, в отличие от последнего, качество этого сервиса остается неизменным при увеличении нагрузки на сеть.
Понятие QoS
Главное требование большинства интерактивных и мультимедиа-приложений — ограничение времени задержки данных в сети. Понятие качества сервиса, введенное для IP-сетей в спецификациях RFC 2212, предусматривает следующее. Гарантируется, что задержка, связанная с буферизацией пакетов при их передаче сетевыми устройствами, не превысит некоторого максимально возможного значения. Причем сеть «обязуется» соблюдать ограничение по задержке и минимизировать вероятность потери пакетов в том случае, если пользовательская программа выдерживает объявленные параметры генерируемого ею трафика. Таким образом, поддержка требуемого уровня обслуживания является результатом соглашения между пользователем и СИС. Чтобы реализовать механизм взаимодействия пользователя с сетью, консорциум IETF разработал и стандартизировал протокол резервирования ресурсов RSVP (Resource Reservation Protocol).
Сигнализация и резервирование ресурсов
Данные о необходимых потоку ресурсах могут быть введены в сетевые устройства несколькими способами: вручную с применением процедур управления, с помощью протоколов управления сетью и с использованием протокола RSVP. Последний способ является наиболее динамичным и стандартным.
RSVP — это не протокол передачи данных или маршрутизации, а управляющий протокол Internet, как, например, ICMP. Достаточно сложный по своей сути, он позволяет приложениям информировать сеть (т. е. сетевые устройства, через которые проходит маршрут) о необходимости зарезервировать определенные ресурсы для выполнения требований приложения к QoS. Основные свойства протокола RSVP таковы:
- ресурсы резервируются только для потока, передаваемого в одном направлении. Другими словами, протокол логически отделяет источник трафика от приемника;
- резервирование инициализируется получателем данных, что обеспечивает хорошую масштабируемость;
- протокол поддерживает потребности многоадресной рассылки (multicasting), т. е. область резервирования ресурсов ограничивается ближайшей точкой дерева рассылки многоадресных сообщений;
- сами сообщения RSVP могут передаваться либо средствами отдельного протокола (поверх IP), либо путем инкапсуляции в сообщения UDP.
Принципы функционирования. В начале сеанса клиент передает RSVP-запрос (RESV) на маршрутизатор, который является ближайшим на пути к источнику потока. Запрос содержит описания потока (flow spec) и фильтра (filter spec), а кроме того, однозначно идентифицирует поток, для которого запрашивается резервирование ресурсов. Описание фильтра и идентификатор потока определяют набор пакетов, которым требуется запрашиваемый уровень обслуживания. Описание потока указывает на необходимый класс сервиса и в общем случае содержит два набора параметров: Tspec устанавливает параметры самого потока, а Rspec — нужное QoS.
Приложения, запрашивающие гарантированный класс сервиса, должны сообщать сети параметры ожидаемого потока и свои требования к качеству обслуживания, причем последние могут быть указаны с той или иной степенью точности, что позволяет уменьшить вероятность отказа за счет увеличения коэффициента неточности (slack term). Количественная характеристика QoS потока выражается как верхняя граница задержки, вызванной буферизацией пакетов при передаче. Зная собственное распределение ресурсов, характеристики запрашиваемого потока и суммарную задержку в цепочке сетевых устройств, функционирующий в маршрутизаторе объект протокола RSVP совместно с контроллером соединений (см. ниже) могут определить, не станет ли прохождение трафиком данного устройства причиной суммарной задержки, которая окажется больше запрошенной приложением (с учетом коэффициента неточности). Если требования соединения не удастся выполнить, клиенту будет послано сообщение RSVP, уведомляющее о неудаче запроса (т. е. фактически об отказе в обслуживании).
В каждом из промежуточных сетевых узлов получение RSVP-запроса приводит к двум событиям:
- непосредственному резервированию ресурсов в канале;
- передаче сообщения RSVP узлу, находящемуся ближе к источнику потока. Перед этим сетевое устройство произведет перерасчет параметров, при необходимости увеличив значение статистической ошибки и уменьшив коэффициент неточности в описании требуемого класса сервиса.
Когда RSVP-запрос достигнет участка дерева многоадресной рассылки, где для данного потока уже зарезервированы ресурсы, параметры которых больше или равны запрашиваемым, процесс резервирования завершится.
 |
| Рис. 2. Компоненты архитектуры сети с интеграцией сервисов |
Принципы управления QoS
Основной задачей контроллера соединений является принятие решения о выделении ресурсов для очередного поступившего запроса или об отказе в соединении с требуемым QoS. Диспетчер обеспечивает различные уровни обслуживания для потоков, попадающих на один выходной порт, в то время как классификатор определяет принадлежность каждого конкретного пакета к одному из потоков.
Контроллер соединений. Механизм управления соединениями принимает или отвергает поступающие запросы на установление соединения с определенным QoS, исходя из наличия требуемых ресурсов. Клиенту будет отказано, если обслуживание запрашиваемого соединения может привести к деградации качества сервиса, предоставляемого уже существующим потокам, т.е. в том случае, когда для обслуживания всех соединений, включая и запрашиваемое, необходимо больше ресурсов, чем имеет маршрутизатор (вопрос об адекватной оценке доступных ресурсов до сих пор является предметом многочисленных исследований). Кроме того, решение об обслуживании по запросу зависит от установленных управляющих параметров; может потребоваться идентификация клиента.
В дополнение к функциям управления соединениями важными задачами контроллера являются учет и тарификация использования ресурсов клиентами, а также, естественно, своевременное уведомление администратора сети о возникающей нехватке ресурсов СИС.
Диспетчер пакетов. Этот важнейший элемент архитектуры СИС непосредственно обслуживает пакеты, предоставляя отдельным потокам соответствующие уровни обслуживания. Диспетчер распоряжается наборами очередей для отдельных интерфейсов маршрутизатора.
Способов организации системы очередей может быть несколько. Наиболее предпочтительная схема — организация отдельной динамической очереди для каждого потока и дополнительной очереди для класса «best effort» на каждом интерфейсе (при использовании буферизации на выходных портах). Такая схема буферизации позволяет наиболее гибко управлять ресурсами, но довольно сложна в реализации. Возможны и другие варианты, например создание по одной очереди на любой класс сервиса.
Логически диспетчер соответствует канальному уровню эталонной модели OSI, поскольку он должен быть реализован в том месте, где происходит буферизация готовых к отправке пакетов.
Процесс корректного управления очередями требует от диспетчера детального взаимодействия с используемой канальной технологией. Нужно, чтобы диспетчер умел задействовать средства организации канала (ATM, frame relay) в целях резервирования пропускной способности на канальном уровне. Если же канальная технология не позволяет зарезервировать полосу, то диспетчеру придется самостоятельно обеспечивать отправку пакетов в сеть с заданной скоростью, пользуясь системой таймеров. Поскольку диспетчер пакетов функционирует в режиме реального времени, в подавляющем большинстве маршрутизаторов его механизм реализован на аппаратном уровне.
Для выполнения обеих процедур диспетчеру необходимо обмениваться контрольной информацией с объектом протокола RSVP. Такой обмен происходит с помощью совместного доступа к базе ресурсов.
Классификатор. Для управления трафиком СИС и тарификации использования ресурсов требуется, чтобы каждый обслуживаемый пакет был причислен к определенному классу. В пределах данного класса все пакеты обслуживаются одинаково. Класс содержит один или несколько потоков — в зависимости от конкретной реализации маршрутизатора. Класс является абстракцией, локальной для конкретного устройства; в других устройствах тот же самый поток может быть причислен к другому классу.
Подобно диспетчеру, классификатор использует данные протокола RSVP, а именно — описание фильтра и идентификатор резервируемого потока. Кроме того, предусмотрена возможность модификации управляющих структур классификатора объектом протокола RSVP. Классификатор, который должен работать со скоростью коммутирующей магистрали маршрутизатора, реализуется аппаратно совместно с механизмом коммутации.
 |
| Рис. 3. Механизмы системы управления буферизацией |
После того как классификатор принял решение о принадлежности пакета к конкретному классу, этот пакет поступает на вход алгоритма управления очередью, соответствующей его классу. С помощью данного алгоритма принимается решение о постановке пакета в очередь или его отбрасывании.
Простые алгоритмы типа Drop Tail отбрасывают пакет, если длина очереди превысила максимально возможную. В случае применения более сложных, вероятностных, алгоритмов, например RED (Random Early Detection), вероятность отбрасывания пакета зависит от средней длины очереди, что способствует как уменьшению этой длины (т.е. сокращению задержки буферизации), так и более эффективному использованию пропускной способности за счет лучшего управления трафиком. Однако применение алгоритма RED целесообразно лишь при условии, что трафик порождается адаптивным транспортным протоколом типа TCP. Разновидность алгоритма RED — WRED (Weighted RED) — реализуется в маршрутизаторах, которые поддерживают несколько классов трафика. В зависимости от приоритета класса WRED по-разному вычисляет вероятность отказа в обслуживании пакета данного класса.
Если имеется единственная выходная очередь, она обслуживается со скоростью линии соответствующего интерфейса. Если же очередей несколько, то необходим арбитр, переключающий обслуживание между очередями с учетом приоритета каждой. Роль такого арбитра могут играть, например, разновидности алгоритма HRR (Hierarchical Round Robin), который обслуживает каждую очередь последовательно и способен «уделять максимум внимания» более приоритетным очередям.
Кроме того, в интеллектуальных маршрутизаторах существуют механизмы управления буферизацией, формирующие при необходимости (например, при появлении нового класса трафика) новые очереди и перераспределяющие память после устранения очереди.
Наконец, такие системы управления трафиком, как WFQ (Weighted Fair Queuing), одновременно формируют очереди, управляют их наполнением и осуществляют их обслуживание. Кстати, WFQ берет на себя еще и функции классификатора пакетов, но поскольку этот механизм не позволяет распределять пакеты по потокам с разными потребностями, в качестве сервиса для СИС разработан вариант WFQ (CBWFQ — Class Based Weighted Fair Queuing), в котором используются те же классы, что и в моделях ИС.
Концепция построения СИС
Развертывание СИС — далеко не тривиальная задача как с точки зрения разработки самой концепции сети и выбора технологий, так и в плане расчета параметров сети. По мнению аналитиков, крупных производителей оборудования и поставщиков решений, на сегодня наиболее перспективной моделью СИС является IP-сеть, развернутая поверх интеллектуальной инфраструктуры канального уровня вроде ATМ.
Исследование современных тенденций в телекоммуникационной отрасли позволило сотрудникам Current Analysis выявить три главные составляющие концепции построения СИС:
- применение протокола IP в качестве интегратора доступа;
- интеграция сетевой и канальной технологий;
- использование интеллектуальной высокоскоростной транспортной подсети.
IP как интегратор доступа
Без сомнения, IP — наиболее широко распространенная сетевая технология. Это единственный протокол, который применяется на всех участках сети — от рабочего стола пользователя до скоростных магистралей. IP хорошо приспособлен как для низкоскоростных каналов доступа, так и для гигабитных линий. Кроме того, эта технология привычна для сетевых администраторов, программистов и пользователей и используется подавляющим большинством приложений.
Протокол IP продолжает успешно играть роль интегратора доступа, обеспечивая единый универсальный интерфейс для приложений, транспортных протоколов и операционных систем. Как технология, которая попадает в поле зрения конечного пользователя, IP объединяет все виды трафика (видео, голос, данные, электронные сообщения и т.д.) на единой платформе. Задача IP — передавать биты от отправителя к получателю, а назначение сети — обеспечивать минимальные потери и своевременность такой передачи, чтобы доставленные по назначению данные не оказались бесполезными.
Вертикальная интеграция уровней
Многие распространенные технологии канального уровня могут не только выделять гарантированную долю общей пропускной способности и ограничивать задержки передачи потоков средствами механизмов СИС, встроенных в узлы IP-сети, но и существенно влиять на качество обслуживания. Рабочая группа по интегрированным сервисам для различных канальных уровней (Integrated Services over Specific Link Layers) в составе IETF разрабатывает варианты реализации модели ИС для различных технологий канального уровня. Этот коллектив рассматривает функционирование и каналов «точка—точка», и ЛВС.
Технологии локальных сетей, такие как разновидности Ethernet, в своем современном состоянии могут внести серьезные нарушения в работу СИС. Даже в коммутируемой ЛВС возникают проблемы, связанные с отсутствием детерминированности в поведении сетевых протоколов. Помочь в их преодолении призваны новые стандарты IEEE 802.1p и 802.1Q. Стандарт 802.1p «Поддержка трафика реального времени» описывает возможности приоритезации трафика ЛВС и многоадресной рассылки в среде коммутируемых и виртуальных ЛВС; функционирование последних регламентирует стандарт 802.1Q. В указанных документах определены механизмы встраивания информации о приоритете в кадр канального уровня и обработки сетевыми устройствами трафика с разными значениями приоритета. В зависимости от технологии и топологии ЛВС приоритет может влиять как на задержку буферизации, так и на время доступа к среде передачи.
Если в качестве несущей подсистемы используется сеть АТМ, которая допускает наличие сложной топологии и развитой системы управления трафиком и уровнями обслуживания, то необходимо иметь возможность отображения классов IP-трафика на различные сервисные категории сети АТМ и передачи информации о резервировании ресурсов с уровня IP на уровень АТМ.
АТМ в ядре транспортной сети
Технология АТМ идеально подходит для использования в качестве основы подсети СИС. Она изначально разрабатывалась для поддержки всех допустимых видов трафика (от голоса, передаваемого по традиционным каналам ТфОП, до данных) с множеством промежуточных градаций QoS. Поэтому реализация интегрированных сервисов в сети АТМ является не предметом компромисса, а центральной частью самой концепции такой сети.
IETF ведет интенсивную работу по стандартизации механизмов АТМ, служащих для передачи IP-трафика с гарантированным качеством обслуживания. Основные аспекты такого применения технологии АТМ и варианты реализации указаны в RFC 2382. В качестве «объединяющего начала» для IP и ATM в сети с интеграцией сервисов немалый интерес представляет технология MPLS.
IPv6 как протокол для СИС
Хотя версия IPv6 разрабатывается в качестве замены IPv4, решающей, главным образом, проблему исчерпания адресного пространства, она содержит много новых механизмов, часть которых имеет непосредственное отношение к реализации модели ИС.
Поля заголовка
Заголовок пакета IPv6, в отличие от IPv4, имеет фиксированную длину и содержит меньшее количество полей. Благодаря фиксированному размеру этого заголовка (опции могут передаваться в виде дополнительных подзаголовков) в общем случае ускоряется обработка пакета IPv6, а новое 24-битное поле идентификатора потока позволяет маршрутизатору однозначно определить поток по адресу отправителя и значению идентификатора. Очевидно, что IPv6 дает выигрыш в скорости по сравнению с IPv4, использующим для определения потока адрес получателя, тип протокола и номер порта.
Дополнительные возможности
Реализованные в IPv6 возможности задания маршрута отправителем унаследованы от механизмов IPv4, но гораздо более тщательно проработаны и стандартизированы. Подзаголовок маршрутизации (Routing options) позволяет создать список узлов (не обязательно полный), через которые должен пройти пакет на своем пути к месту назначения. Выше уже говорилось о том, что протокол RSVP не является протоколом маршрутизации, т.е. не определяет маршрут следования сначала запроса на резервирование ресурсов, а затем и потока, для которого осуществляется резервирование. Зная, как устроена система доступа в его организации, с помощью подзаголовка маршрутизации IPv6 пользователь может выбирать наиболее благоприятные маршруты для различных типов приложений. Конечно, на решение о маршрутизации влияет не только этот подзаголовок, но он позволяет самому приложению определять путь следования трафика.
Наряду с заголовком маршрутизации важную роль в установлении состояния потока (маршрутизаторами) может играть подзаголовок опций для каждого узла (Hop-by-hop options). Пока существуют лишь самые общие соображения о том, как реализовать эту возможность, однако они представляют значительный интерес. Например, если включить сообщения протокола RSVP в подзаголовок опций для каждого узла, то при наличии еще и подзаголовка маршрутизации удастся избежать задержки, связанной с процедурой установления соединения. Встроенная в протокол IPv6 система безопасности, в которую входят средства однозначной идентификации и обеспечения конфиденциальности информации, может способствовать стандартизированному решению задачи идентификации пользователя при резервировании ресурсов. Это лишь наиболее очевидные преимущества использования IPv в качестве протокола СИС.
Интеграция с архитектурой MPLS
Компоненты СИС обеспечивают эффективное управление резервированием ресурсов сети и, следовательно, ее трафиком. Однако масштабирование СИС порой вызывает затруднения, а кроме того, ограничено непомерными нагрузками на маршрутизаторы сетей крупных провайдеров. Большую часть этих проблем весьма элегантно решает технология MPLS (см. статью «Введение в архитектуру MPLS» в этом же номере).
Кроме того, MPLS позволяет сервис-провайдерам использовать имеющуюся АТМ-магистраль в качестве базовой инфраструктуры и пополняет набор предлагаемых ими сервисов за счет множества свойств интеллектуальной технологии третьего уровня. MPLS может работать не только в сети ATM, но и в обычной сети с коммутацией пакетов. Хотя технология MPLS создавалась с ориентацией на IPv4, ее применение с IPv6 имеет ряд преимуществ. В настоящее время стандарты MPLS находятся в стадии разработки.
Интеграция с сетями ATM
Как и в случае с четвертой версией, интеграция IPv6 как протокола СИС с сетью АТМ, выступающей в качестве транспортной подсети, сулит множество преимуществ, если, конечно, имеется возможность распространить резервирование ресурсов на канальный уровень. Принципы передачи пакетов IPv6 по сетям АТМ определены в спецификации RFC 2492.
Перспективы СИС
В процессе своей эволюции СПД претерпели качественное изменение: родилась концепция СИС, объединившая в себе лучшие свойства СПД и ТфОП. Новую технологию поддерживают как потенциальные клиенты, так и разработчики. Крупные поставщики сетевого оборудования и решений, включая Cisco, FORE (подразделения GEC) и 3Com, открыто выражают заинтересованность в развитии и продвижении технологий СИС, которые способствуют дальнейшему усилению позиций сетей с коммутацией пакетов по сравнению с другими телекоммуникационными системами.
Способы реализации новой модели обслуживания являются предметом интенсивных исследований и ждут своего часа в процессе стандартизации. И хотя первые результаты уже налицо, многие компоненты архитектуры СИС еще долго будут предметом обсуждений. Особенный интерес представляет потенциальная возможность вертикальной интеграции различных уровней сетевой иерархии, например АТМ и RSVP, MPLS и RSVP, СИС и канальных технологий.
Спрос на решения СИС, в свою очередь, стимулирует разработку и внедрение новых технологий, вроде IPv6 и MPLS, которые изначально учитывают потребности архитектуры СИС и в недалеком будущем заменят либо дополнят традиционные подходы. Взаимовыгодное объединение СИС с АТМ будет способствовать и дальнейшему распространению технологии асинхронной передачи.
Итак, у СИС есть прекрасные шансы стать доминирующей телекоммуникационной технологией XXI века. Возможности удостовериться в справедливости подобного прогноза осталось ждать совсем недолго.
Работа была поддержана грантами РФФИ и OSI. Автор выражает глубокую благодарность А.И. Русакову и М.Н. Захаровой за оказанную помощь.
ОБ АВТОРЕ
Игорь Алексеев (aiv@yars.free.net) — эксперт по информационным системам Центра Интернет Ярославского государственного университета.| Дополнительные источники информации |
|