Способы и устройство для управления трафиком интернет-протокола в глобальной или локальной сети

1 Для данной заявки испрашивается приоритет предварительной заявки за номером 60/184,758, поданной 23 февраля 2000 г., полное раскрытие которой включено в настоящее описание посредством ссылки. Предпосылки изобретения Область, к которой относится изобретение Изобретение относится к сетям связи, в которых применяется интернет-протокол (IP). В частности, изобретение относится к способам и устройству для управления передачей пакетовIP по сети. Уровень техники Уровень техники представлен следующими документами, краткое содержание которых приведено ниже, и которые приложены в полном объеме к вышеупомянутой предварительной заявке и составляют часть настоящего описания.on the Internet, MIT, May 1997 г. (Мэрфи, Давид М. Построение активного узла в Интернете,МТИ, май 1997 г.) Активная IP-сеть объединяет в себе две весьма различные модели сетевого программирования: модель на основе пакетов IP и модель на основе капсулы активной сети. В этом докладе показано, как объединить эти две модели в одном узле, именуемом "активным IP-узлом", и как встроить активный IP-узел в IP-сеть. В нем также представлены некоторые предварительные идеи, касающиеся ограничений, с которыми архитекторы сетей столкнутся при построении активных протоколов для неоднородной сети,содержащей активные и неактивные IP-узлы. Использование модели постоянной и переменной обработки, объединяющей активную и IPархитектуру, обуславливает ясную и простую конструкцию и реализацию узла. Кроме того,механизмы, представленные в этом докладе,например, защищенные буферы, обеспечивают различные защитные ограничения, способствующие объединению. Наконец, в этом докладе представлены некоторые предварительные рабочие результаты, которые, в сочетании с вышеупомянутыми характеристиками, свидетельствуют о том, что активная IP-платформа будет привлекательна для исследователей, желающих изучать интернет-протоколы, ориентированные на приложения.Infocom, San Francisco, April 1998 г. Легендза Улана, Ветерал Давид Дж. и Гуттаг Джон Улучшение характеристик распределенных приложений с использованием активных сетей,Инфоком IEEE, Сан-Франциско, апрель 1998 г.) Активная сеть позволяет приложениям внедрять специализированные программы в сетевые узлы. Это дает возможность быстрее обновлять протокол, облегчая развертывание 2 новых сетевых протоколов даже в глобальных сетях. В этой статье мы доказываем, что возможность внедрения активных протоколов дает большие возможности для улучшения характеристик передачи от точки к точке для распределенных приложений. Мы начинаем с описания активных протоколов, которые обеспечивают новые сетевые услуги, и обсуждаем влияние услуг на характеристики передачи от точки к точке для приложений. Затем мы рассматриваем два активных протокола, которые реализуют ранее изученную услугу надежного мультивещания. Один протокол оптимизирован для поддержки приложений пакетной обработки данных, а другой - для интерактивных приложений. Наконец, мы анализируем характеристики этих протоколов относительно традиционного неактивного протокола. Результаты отчетливо демонстрируют, что введение активных протоколов, приспособленных к потребностям отдельных приложений, может приводить к значительному улучшению характеристик.Issue on Active and Programmable Networks, July 1998 г. (Ветерал Давид Дж., Легендза Улана и Гуттаг Джон Введение новых интернет-услуг: почему и как, специальный выпуск сетевого журнала IEEE, посвященный активным и программируемым сетям, июль 1998 г.) Активные сети позволяют внедрять программы в узлы локальных и, что более важно,глобальных сетей. Это обеспечивает более быстрое обновление услуг за счет облегчения развертывания новых сетевых услуг. В этой статье мы рассматриваем как потенциальное влияние услуг активной сети на приложения, так и пути построения и развертывания таких услуг. Мы исследуем влияние, предлагая выборочные применения и показывая, как такие применения повышают характеристики приложения. Мы исследуем построение активных сетей, представляя новую архитектуру, ANTS, которые добавляют расширяемость на сетевом уровне и обеспечивают возрастающее развертывание активных узлов в сети Интернет. При этом, ANTS берется доказать, что гибкость, обеспечиваемая активными сетями, не оказывает неблагоприятного влияния на характеристики или безопасность. Наконец, мы демонстрируем, как можно выразить новые сетевые услуги в ANTS.Network Working Group, Request for Comments: 2475, December 1998 г. (Сетевая рабочая группа, Запрос комментариев: 2475, декабрь 1998 г.) В данном документе определена архитектура для реализации масштабируемой дифференциации услуг в Интернете. Эта архитектура обеспечивает масштабируемость за счет агрегирования состояния классификации трафика, которое передается посредством маркировки паке 3 та на уровне IP с использованием поля DS[DSFIELD]. Пакеты классифицируются и маркируются для получения конкретного поведения при передаче данных на узлах по путям их следования. Усложненные операции классификации, маркировки, выработки политики и формирования нужно реализовать только на границах сети или хост-компьютерах. Сетевые ресурсы выделяются потокам трафика услугой, обеспечивающей политику, определяющую, как маркируют и задают условия для трафика при вводе в сеть с функцией дифференцированных услуг и порядок передачи трафика в такой сети. Поверх этих стандартных блоков можно реализовать самые разнообразные услуги. Архитектуру дифференцированных услуг,описанную в данном документе, можно противопоставить другим существующим моделям дифференциации услуг. Мы подразделяем эти альтернативные модели по следующим категориям: маркировка по относительному приоритету, маркировка по услуге, коммутация по признаку, интегрированные услуги/RSVP и статическая классификация при передаче по отрезку сети. Примеры модели маркировки по относительному приоритету включают в себя IPv4 с маркировкой по старшинству, описанный вIEEE 802.5 [TR] и принимаемая по умолчанию интерпретация классов трафика по стандартуIEEE 802.1 р [802.1p]. В этой модели приложение, хост-компьютер или узел-посредник выбирает относительный приоритет или старшинство для пакета (например, приоритет по задержке или отбрасыванию), и узлы сети, расположенные на пути передачи, применяют нужное поведение при передаче данных по приоритету,соответствующее значению приоритета, содержащемуся в заголовке пакета. Нашу архитектуру можно рассматривать как уточнение этой модели, поскольку мы более четко определяем роль и значение граничных узлов и формирователей трафика и поскольку наша модель поведения при передаче по отрезку сети допускает более общие варианты поведения при передаче данных, чем относительный приоритет по задержке или отбрасыванию. Примером модели маркировки по услуге является IPv4 TOS (Type of Service) [тип услуги], описанный в [RFC1349 http://www.faqs.org/rfcs/rfcl349.html]. В данном примере каждый пакет маркируется запросом на тип услуги, который может включать в себя минимизировать задержку,максимизировать пропускную способность,максимизировать надежность или минимизировать затраты. Узлы сети могут выбирать пути маршрутизации или варианты поведения при передаче данных, которые оптимально удовлетворяют запрос на услугу. Эта модель немного отличается от нашей архитектуры. Заметим, что мы не описываем 4 использование поля DS в качестве входных данных для выбора маршрута. Маркировки по TOS,заданные в [RFC1349 http://www.fags.org/rfcs/rfcl349.html], имеют очень общий характер и не охватывают диапазон возможных семантик услуг. Кроме того, запрос на услугу связывается с каждым отдельным пакетом, тогда как некоторые семантики услуг могут зависеть от агрегатного поведения при передаче последовательности пакетов. Модель маркировки по услугам не очень хорошо согласуется с ростом количества и диапазона перспективных услуг (поскольку пространство кодовых точек мало) и задействует конфигурацию связи TOSповедение при передаче данных на каждом узле базовой сети. Стандартизация маркировок по услугам подразумевает стандартизацию предложения услуг, что выходит за рамки деятельности IETF. Заметим, что нововведения касаются выделения пространства кодовых точекDS для обеспечения кодовых точек местного значения, которые поставщик услуг может использовать для поддержки семантик маркировки по услуге [DSFIELD]. Примеры модели коммутации по признаку(Multiprotocol Label Swithing) [многопротокольная коммутация по признаку] [FRELAY, ATM]. В этой модели состояние передачи данных по пути и управление трафиком или состояние QoS(quality of service) [качество услуги] устанавливается для потоков трафика на каждом отрезке вдоль сетевого пути. На входном узле агрегаты данных трафика различной степени объединения связывают с путем, коммутированным по признаку, и, на каждом пути, коммутированном по признаку, пакеты/ячейки маркируют признаком передачи, который используется для поиска узла следующего отрезка сети, поведения при передаче данных и замены признака на каждом отрезке сети. Эта модель позволяет повысить степень разбиения при выделении ресурсов потокам трафика, поскольку значения признака не имеют глобальной значимости, но значимы только на одной линии связи; в результате, имеется возможность резервировать ресурсы для агрегата пакетов/ячеек, принимаемых по линии связи с тем или иным признаком, и семантики коммутации по признаку управляют выбором следующего отрезка сети, позволяя потоку трафика следовать по сети специально разработанным путем. Эта повышенная степень разбиения дается ценой дополнительных требований к управлению и конфигурации для установления и поддержки путей, коммутируемых по признаку. Кроме того, количественная характеристика состояния передачи данных, поддерживаемая на каждом узле, в лучшем случае, масштабируется пропорционально количеству периферийных узлов сети (при использовании путей, коммути 5 руемых по признаку, соединяющий узел с несколькими узлами) и, в худшем случае, масштабируется пропорционально квадрату количества периферийных узлов, когда применяются пути,коммутируемые по признаку, соединяющие периферийные узлы, с обеспеченными ресурсами. Модель интегрированных услуг/RSVP [протокол резервирования ресурсов] опирается на традиционную передачу датаграмм в случае, рассматриваемом по умолчанию, но позволяет источникам и приемникам обмениваться сообщениями сигнализации, которые устанавливают дополнительную классификацию пакетов и состояние передачи данных на каждом узле по пути между ними [RFC1633http://www.faqs.org/rfcs/rfcl633.html, RSVP]. В отсутствие агрегирования состояния, количественная характеристика состояния на каждом узле масштабируется пропорционально количеству одновременных вариантов резервирования, которое может быть потенциально большим на высокоскоростных линиях связи. Эта модель также требует поддержки приложений для протокола сигнализацииRSVP. Механизмы дифференцированных услуг можно использовать для агрегирования состояния интегрированных услуг/RSVP в ядре сети [Bernet]. Вариант модели интегрированных услуг/RSVP исключает требование к сигнализации от отрезка к отрезку маршрута за счет использования только статической классификации и политик передачи данных, которые реализуются на каждом узле вдоль сетевого пути. Периодичность обновления этих политик определяется административно, но не в порядке реакции на мгновенную смесь микропотоков, действующих в сети. Требования к состоянию для этого варианта потенциально хуже накладываемых при использовании RSVP, особенно в узлах магистрали, поскольку количество статических политик, которые можно применять в узле в течение времени, может быть больше количества активных сеансов отправитель-получатель,которые могут иметь установленное состояние резервации на узле. Хотя поддержка большого количества правил классификатора и политик передачи данных может быть вычислительно выполнимой, для установления и поддержки этих правил на каждом узле магистральной сети, через которые может проходить поток трафика, требуются значительные усилия по управлению. Хотя мы противопоставляем нашу архитектуру этим альтернативным моделям дифференциации услуг, следует заметить, что линии связи и узлы, где применяются эти методы,можно использовать для расширения вариантов поведения и семантик дифференцированных услуг по коммутируемой инфраструктуре 2-го уровня (например, локальным сетям стандарта 802.1 р, магистралям Frame Relay/ATM), соединяющей между собой DS-узлы, и, в случаеMPLS, можно использовать в качестве альтернативной технологии внутридоменной реализа 004189 6 ции. Ограничения, накладываемые использованием конкретной технологии канального уровня в отдельных областях DS-домена (или в сети,обеспечивающей доступ к DS-доменам), могут предусматривать дифференциацию трафика с меньшей степенью разбиения. В зависимости от отображения РНВ на различные услуги канального уровня и способа диспетчеризации пакетов по ограниченному множеству классов приоритета (или виртуальных каналов различных категорий и емкости) все или подмножество используемых РНВ могут поддерживаться (или быть неразличимыми).Network Working Group, Internet Draft,Multiprotocol Label Switching Architecture, February 2000 г. (Сетевая рабочая группа, Интернетпроект, Архитектура многопротокольной коммутации по признакам, февраль 2000 г). В Интернет-проекте описана архитектура многопротокольной коммутации по признакам(MPLS). Заголовки пакетов содержат значительно больше информации, чем необходимо для выбора следующего отрезка сети. Поэтому выбор следующего отрезка сети можно рассматривать как композицию двух функций. Первая функция разбивает все множество возможных пакетов на множество классов эквивалентности по передаче данных (КЭП). Вторая функция отображает каждый КЭП на следующий отрезок сети. В отношении принятия решения по передаче данных разные пакеты, отображенные в один и тот же КЭП, неразличимы. Все пакеты, принадлежащие конкретному КЭП и приходящие от конкретного узла, будут следовать одним и тем же путем (или, в случае использования определенных видов многопутевой маршрутизации,все они будут следовать одним из множества путей, связанных с КЭП). Розен, Вишванатхан и Кэллон (Rosen, ViswanathanGallon) [стр.4] Интернет-проект draft-ietf-mpls-arch-06.txt, август 1999 г. При традиционной IP-передаче данных конкретный маршрутизатор обычно рассматривает два пакета принадлежащими одному и тому же КЭП, если в таблицах маршрутизации этого маршрутизатора имеется некий префикс X адреса, такой, что X является самым длинным участком совпадения для адреса назначения каждого пакета. При прохождении пакета по сети каждый отрезок сети, в свою очередь, перепроверяет пакет и назначает его к КЭП. ВMPLS назначение отдельного пакета тому или иному КЭП производится только один раз, при входе пакета в сеть. КЭП, которому приписан пакет, кодируется коротким значением фиксированной длины, именуемым признаком. При пересылке пакета на следующий отрезок сети признак посылают вместе с ним; таким образом,пакеты снабжают признаками до их пересылки. На последующих отрезках сети пакеты не подвергаются дополнительному анализу заго 7 ловка сетевого уровня. Вместо этого, признак используется в качестве индекса в таблице, задающей следующий отрезок сети и новый признак. Старый признак заменяется новым признаком, и пакет пересылается на следующий отрезок сети. Ниже приведены краткие характеристики известных механизмов транспортировки пакетов IP по сети ATM. Они включают в себя: классический IP, LANE (эмуляция локальной сети), МРОА (мультипротокол над ATM) иMPLS. Классический IP над ATM (CIP) позволяет существующим пользователям IP мигрировать для использования ATM в качестве технологии транспортировки данных более низкого уровня и, в то же время, использовать существующие приложения, разработанные для традиционныхIP-систем. Для этого сети ATM разбивают на логические IP-подсети (LIS), сообщающиеся друг с другом через маршрутизаторы.LANE действует на уровне MAC и может использоваться совместно с любым протоколом 3 уровня. Напротив, классический IP над ATM работает только с IP. Организация ATM Forum разработала мультипротокол над ATM (МРОА) для преодоления одного существенного недостатка LANE и CIP: эти протоколы требуют, чтобы хосткомпьютеры на разных подсетях (ELAN и LIS) обменивались между собой через промежуточные маршрутизаторы, что значительно снижает пропускную способность пакетной передачи,поскольку каждому маршрутизатору приходится повторно собирать ячейки пакетов 3 уровня для маршрутизации и снова разбивать пакет на ячейки для пересылки. МРОА позволяет клиентам в разных подсетях устанавливать прямые соединения по виртуальному каналу (СВК),именуемые также перемычками, друг с другом и пересылать пакеты непосредственно на 3 уровне, без какой-либо промежуточной повторной сборки и разбиения. В пределах подсети МРОА использует LANE. МРОА предусматривает распределенный,виртуальный маршрутизатор. Пограничные устройства, которые подключают подсети ATM к сегментам традиционной локальной сети ЛС,представляют собой что-то наподобие интерфейсных карт для виртуального маршрутизатора. Вся сеть ATM, соединяющая пограничные устройства, является внутренней объединительной шиной передачи данных виртуального маршрутизатора. Функция передачи пакетов отделена от функции вычисления маршрута,которая осуществляется сервером маршрутизации. В модели MPLS каждый маршрутизатор является также коммутатором. Пакеты, которые были приписаны перемычке, имеют признаки фиксированной длины, помимо обычного заголовка 3 уровня. MPLS позволяет устанавливать 8 перемычки на основании нескольких критериев,например, IP-адреса назначения, классов услуг и политик обслуживания, что дает возможность очень гибко манипулировать сетью. MPLS не привязан к ATM; напротив, он призван работать над любой технологией канального уровня, которая способна поддерживать признаки фиксированной длины для идентификации перемычек. Распределенный интеллект современных сетей пакетной передачи данных создает принципиальные ограничения для развертывания сетей с высокой пропускной способностью, в которых предусмотрены услуги следующего поколения, требующие высокой пропускной способности и/или передачи в режиме реального времени. Основным недостатком остается отсутствие общей координации при совместном использовании различных сетей и между услугами. Ниже приведен перечень принципиальных проблем. 1. Ограничение способности эффективно предоставлять услугу широкому кругу потребителей 2. Ограничение способности обеспечивать функцию контроля усовершенствованных услуг 3. Увеличение стоимости и сложности сетевого оборудования 4. Перегрузка процессоров сетевого оборудования задачами обслуживания, политики,формирования трафика, маршрутизации и коммутации 5. Такая перегрузка сетевого оборудования приводит к снижению QoS, ухудшает обеспечение трафика, чувствительного к QoS. Согласно современной практике, архитектуры сети Интранет могут обеспечивать либо гарантированное качество обслуживания (QoS),управление услугами интернет-протокола (IP),либо гибкость в адаптации новых приложений. Тем не менее, современные процедуры не позволяют решать эти три задачи одновременно. Обеспечение наивысшего качества обслуживания (QoS) требует эмуляции сети с коммутацией каналов, из-за чего резервирование ресурсов происходит до передачи запроса. Однако такие технологии, как режим асинхронной передачи(ATM), не в состоянии обеспечивать диапазон услуг IP, поскольку, по природе своей, не могут маршрутизировать или согласовать структуру адресации IP со своей собственной. Кроме того,активные сети способны динамично переконфигурировать элементы сети, адаптируя сеть к задачам конкретных приложений. Тем не менее,хотя активные сети имеют преимущества на уровне пакетов, они не могут определять общие потребности в сетевых ресурсах в сети Интранет. Современная практика построения IPсетей предусматривает структуру, которая грубо дифференцирует потоки пакетов через систему минимальных усилий. Спецификация COPSOpen Policy Service) предусматривает структуру клиент/сервер между администратором политики и элементами сети. Эта структура способна отображать запросы политики интегрированных услуг (IntServ), ориентированных на приложения, на уровень доступа и установки дифференцированных услуг (DiffServ) в ядре. Принципиальное строение этой архитектуры не в состоянии гарантировать QoS при передаче между конечными точками. Хост-компьютеры передают на основе минимальных усилий, причем политические решения принимаются при обработке на периферийном маршрутизаторе (ПМ). Современная практика формирования сетей ATM предусматривает структуру, которая неэффективно выступает в качестве посредника для IP-передач, жертвуя QoS передачи между конечными точками ATM-передач. При IPмаршрутизации каждый маршрутизатор, через который проходит пакет, назначает пакет классу эквивалентности передачи. При многопротокольной коммутации по признаку (MPLS) пакет назначается к КЭП только один раз - при входе в сеть. Затем КЭП кодируется коротким значением фиксированной длины, именуемым признаком, и этот признак сопровождает пакет на каждом отрезке сети. Когда пакет достигает следующего узла на своем пути, признак используется в качестве индекса в таблице поиска на узле, которая затем обеспечивает новый признак. Старый признак заменяется новым признаком, и осуществляется пересылка пакета. При отображении признаков MPLS на VPI/VCIATM, MPLS объединяет базовые функции IPмаршрутизации с ATM-коммутацией. ОднакоMPLS недостает некоторых возможностей архитектуры IntServ/DiffServ. Хост-компьютеры передают на основе минимальных усилий, причем политические решения принимаются при обработке на пограничном маршрутизаторе признаков (ПМП). Сущность изобретения Для решения этих проблем требуется развитие архитектуры, которая централизует интеллектуальные возможности сети, усиливает хост-компьютеры и модифицирует работу элементов сети. Согласно изобретению можно применять следующие стратегии: 1. Сбор информации из сети о наличии ресурсов 2. Централизация сбора данных и управления политикой/услугами в базах данных на внешних узлах обслуживания 3. Обеспечение хост-компьютеров интеллектуальными возможностями в виде программпосредников, чтобы они могли связываться с внешними узлами обслуживания и отвечать им 4. Разработка программ, которые принимают оптимальные решения для всей сети на основании информации, предоставляемой хосткомпьютерами и обеспеченной в базах данных 10 5. Разработка протокола сигнализации политики обслуживания, который обеспечивает связь между узлами обслуживания, хосткомпьютерами и элементами сети для манипуляции хост-компьютерами и элементами сети на основании решений узлов обслуживания. Для хранения основной сетевой информации можно разработать объектно-ориентированную базу данных. Объекты можно согласовывать со многими переменными, включая базы управленческой информации (MIB), запросы хосткомпьютеров, адреса IP-мультивещания, IP- иATM-адреса или конкретную информацию по услугам. База данных может использовать иерархическую адресацию и таблицы маршрутизации, чтобы эффективно и экономично по времени принимать оптимальные решения. Во внешних узлах обслуживания программа обслуживания политики, использующая информацию, хранящуюся в этих базах данных, может принимать решения,касающиеся оптимального использования сети с учетом потребностей хост-компьютеров и имеющихся сетевых ресурсов. Каждый хосткомпьютер можно снабжать программойпосредником, которая позволяет взаимодействовать с узлом обслуживания, позволяя хосткомпьютерам сообщать узлу обслуживания параметры любой передачи, которую он запрашивает. Обмен между хост-компьютерами, узлами обслуживания и элементами сети обеспечивается протоколом сигнализации услуг/политики,который обеспечивает интегрированные интеллектуальные возможности (информацию) сигнализации по сети передачи пакетов. Эта архитектура позволяет размещать на хост-компьютере увеличенные интеллектуальные возможности (информацию) и согласовывать по услугам решения программы услугполитики с вышеописанными протоколами. Кроме того, эта архитектура обеспечивает бесперебойный и эффективный крупномасштабный контроль предоставляемых услуг. Можно реализовать отслеживание времени и типов используемых услуг, обеспечивая интеллектуальный выбор и распределение перспективных услуг. Эта архитектура обеспечивает широкое разнообразие практических инноваций в предоставлении услуг потребителям. Рассмотрим несколько общих примеров в областях, где можно лучше обслуживать потребителей. Допустим,потребитель запрашиваетwebстраницу. Программа-посредник, установленная на хост-компьютере, использует протокол сигнализации, чтобы послать на узел обслуживания сообщение, извещающее сервер соответствующей информацией о доступе к web-странице. Программа на узле обслуживания обращается к базе данных и принимает решение о доступности ресурсов для доступа к такой web-странице. Узел обслуживания может принять решение о недоступности ресурсов, о возможности обес 11 печения доступности ресурсов путем манипуляции элементами сети, или о доступности ресурсов. Приняв решение о безусловной недоступности ресурсов, он может послать эквивалент сигнала занято. При возможности сделать ресурсы доступными путем манипуляции сетевыми элементами он реализует решение и использует протокол сигнализации для взаимодействия с нужными сетевыми элементами. Таким образом, для обеспечения необходимых ресурсов по запросу, можно манипулировать маршрутизаторами, коммутаторами, протоколами маршрутизации, транспортными протоколами и т.д. Выполнив эти действия, он может сигнализировать web-странице, что пользователь желает просмотреть ее содержимое. Таким образом, узел обслуживания может реагировать на потребности хост-компьютеров. Кроме того, узел обслуживания может профилактически реагировать на потенциальные проблемы в сети благодаря наличию функции принятия решения у программы обеспечения услуг-политики. Посредством протокола сигнализации решения программы могут манипулировать передачей хост-компьютера и сетевыми операциями. Например, программа может принять решение о том, что для снятия перегрузки сети хост-компьютеры должны отложить передачу определенных классов услуг. Программа-посредник на хост-компьютере выполняет такие запросы. Аналогично, программа услуг-политики может принять решение о том,что сетевые элементы должны прервать, отложить или выполнить различные политики формирования трафика. Порядок формирования трафика можно интеллектуально и централизованно определять на узлах обслуживания и выполнить, по необходимости, в надлежащих местах сети. Эта архитектура позволяет значительно усовершенствовать предоставление видеоуслуг. Поскольку видеопередачи осуществляются в режиме реального времени и требуют высокой пропускной способности, их очень трудно доставлять широкой аудитории и с высоким QoS. Эта архитектура позволяет усовершенствовать функции управления услугами и существенно усовершенствует функции политики/формирования трафика. Развертывание большого количества средств IP-мультивещания по большой географической области является обязательным для тех, кто желает обеспечивать кабельное телевидение в среде передачи пакетов. Управление средствами IP-мультивещания, цифровое привставление и отслеживание запросов пользователей являются серьезными задачами. Эта архитектура позволяет переносить информацию запросов от хост-компьютеров, сохранять ее в централизованных базах данных и позволяет программе услуг-политики выполнять решения,относящиеся к транспортировке, регистрации и 12 тарификации. Она позволяет отслеживать соединения и листья IGMP (протокола управления интернет-группами), обеспечивая эффективное и универсальное управление услугами и политикой. Это позволяет поставщикам услуг интеллектуально принимать решения относительно того, как эффективнее осуществлять видеопередачи - в режиме двухточечной связи или в режиме мультивещания - исходя из общей ситуации в сети. Кроме того, возможность постоянно отслеживать запросы хост-компьютеров на эти услуги позволяет объективно оценивать рейтинг популярности программ, включающих в себя содержательный материал и рекламу. Это позволяет поставщику услуг оптимизировать как сетевые ресурсы, так и программы, предлагаемые потребителям. Краткое описание чертежей Фиг. 1 - упрощенная блок-схема последовательности операций взаимодействия хосткомпьютера и локального узла, согласно изобретению. Фиг. 2 - упрощенная блок-схема последовательности операций взаимодействия локального узла и главного узла, согласно изобретению. Фиг. 3 - упрощенная блок-схема последовательности операций взаимодействия локального узла и сетевого оборудования, согласно изобретению. Фиг. 4 - упрощенная блок-схема последовательности операций архитектуры общественного web-сервера сети Интернет. Фиг. 5 - упрощенная схема, иллюстрирующая взаимодействие между хосткомпьютером, локальным узлом, главным узлом и сетевым оборудованием, согласно изобретению. Подробное описание предпочтительных вариантов осуществления Система управления интеллектуальными возможностями активной сети (NAICS), согласно изобретению, предусматривает иерархическую структуру управления для сетей Интранет,охватывающую применение программыпосредника на хост-компьютерах и два уровня активных узлов, координирующих выполнение политики и управление услугами. Протокол сигнализации, AIPv6, разработанный для взаимодействия активных узлов, обеспечивает связь между хост-компьютерами и активными узлами.AIPv6 представляет собой простой протокол запросов и ответов, который можно использовать для обмена информацией о политике и услугах между активным узлом и его клиентами.AIPv6 использует опции, которые были разработаны для поддержки заранее заданной необязательной обработки, чтобы поддерживать динамически задаваемую необязательную обработку. Двухуровневая структура активных узлов играет двоякую роль. Во-первых, применяяAIPv6 для обмена запросами и ответами между 13 хост-компьютерами, локальными узлами и главными узлами, можно распределять по сети решения относительно политики и услуг. Вовторых, эта структура позволяет распределять статистики использования сети, собранные в качестве основы для принятия решений по услугам и политике. Архитектура распределяет эту задачу между локальными активными узлами и главными активными узлами. Локальные активные узлы собирают информацию опроса[простой протокол сетевого управления,(ППСУ)] в заданной области, тогда как главные активные узлы объединяют информацию опроса, полученную локальными активными узлами в их областях. Главные активные узлы перенаправляют существенную информацию на локальные узлы и, по мере необходимости, отвечают на запросы локальных узлов на дополнительную информацию. Локальные узлы выполняют политические решения, передавая извлечения ППСУ, которые переконфигурируют сетевые устройства. Архитектура NAICS позволяет хосткомпьютерам самостоятельно сигнализировать локальным активным узлам посредством запросов AIPv6. Ответы локального активного узла обеспечивают окончательный ответ на запросы хост-компьютеров, обеспечивая параметры услуг и передачи относительно соглашений по уровню услуг и использования сети. Параметры услуг и передачи, передаваемые через активные узлы, обеспечиваются по всей сети Интранет. Современная практика в активных узлах обеспечивает распределенные интеллектуальные возможности для хост-компьютеров, но сетевые устройства еще не обеспечивают структуру для нисходящей политики и управления услугами сетей Интранет. С помощью активных узлов приложения задают процедуры, подлежащие выполнению, а не IP-передачу на активных сетевых узлах, которые пересылают их сообщения. Приложения распределяют часть своей обработки по сети. Современная практика формирования активной сети использует архитектуру, в которой сетевые устройства совместно решают задачу обработки и передачи по протоколу AIPv6. Архитектура NAICS дробит эту задачу, передавая задачу управления политикой и услугами отдельной структуре локальных и главных активных узлов. Сетевые устройства в Интранет передают пакеты на основанииSNMP-сигнализации локальных активных узлов. Преимущества NAICS в сети ЦАЛ/ГС Существующая практика формирования сети типа цифровая абонентская линия 14 коммутаторов ядра ATM. Эта структура соединяет компьютеры конечных пользователей с глобальной сетью, связывающей между собой конечных пользователей и обеспечивающей доступ в общественный Интернет. Однако управление услугами и политикой остается децентрализованным, поскольку осуществляется на разных устройствах. Конечные пользователи перенаправляют трафик на подключенные к ним модемы/маршрутизаторы ЦОЭ, которые передают пакеты по местной проводной линии связи на мультиплексор доступа к ЦАЛ. Динамическое выделение сетевых ресурсов невозможно. Например, запросы конечных пользователей не могут немедленно переконфигурировать сетевые устройства в соответствии с этим запросом. Передачи должны отвечать заранее заданным параметрам. Передача, которая не соответствует, наказывается потенциальным прерыванием или задержкой доставки. Оповещение конечных пользователей происходит только полагаясь на протоколы транспортного уровня, например,протокол управления передачей. Конечные пользователи не имеют универсального механизма определения статуса услуги или передачи. В современной практике управление услугами осуществляется посредством нескольких по разному управляемых устройств. Серверы,работающие по протоколу Remote Access Dial InUser Service (RADIUS) [протокол аутентификации, используемый серверами доступа к сети],обеспечивают услуги аутентификации, авторизации и учета сетевых ресурсов (ААА), существенные для развертывания услуг ЦАЛ, поскольку они контролируют функции пользовательского, технического и делового управления. Сервер доменных имен (DNS) обеспечивает услугу поиска, которая ищет информацию, связанную с именами доменов. Услуги DNS важны для простого и эффективного доступа в Интернет. Динамический протокол конфигурации хост-компьютера (DHCP) позволяет серверу динамически назначать IP-адреса конечным пользователям. DNS и DHCP обычно объединяются в одно сетевое устройство. Механизмы управления подключения к услуге [Service Connection Management] обеспечивают подключение конечных пользователей к ЦАЛ, соотносят абонентов с услугами ЦАЛ, просматривают ловушки SNMP и обращаются к функциям сбоя,конфигурации, учета сетевых ресурсов, производительности, защиты (FCAPS). Современная практика отличается наличием нескольких разных устройств, не оптимизированных для взаимодействия и согласованного осуществления услуг. Наилучшим современным механизмом управления политикой для сетей ЦАЛ/ГС является выполнение механизма общей услуги открытой политики (COPS). Спецификация COPS 15 обеспечивает структуру клиент/сервер между администратором политики и элементами сети. От периферии сети политику минимальных усилий можно предписывать на основании централизованного сервера политики. Однако эта архитектура обеспечивает сигнализацию между периферийными маршрутизаторами и сервером политики. Между хост-компьютерами сети ЦАЛ и централизованными серверами нет никакой сигнализации. Многочисленные устройства,обеспечивающие управление услугами, нельзя интегрировать в эту структуру управления политикой. Кроме того, никакие современные методы предоставления услуг ЦАЛ не могут динамически адаптироваться к потребностям новых и разнообразных приложений. Задача поставщика услуг состоит в аутентификации и выделении ресурсов для тех или иных приложений по требованию своих абонентов ЦАЛ/ГС. В настоящее время наилучшая практика состоит в том, что сетевые устройства позволяют абонентам сигнализировать серверу управления услугами, осуществляющему авторизацию и учет сетевых ресурсов предоставления дополнительной услуги. Чтобы запросить такую услугу, обмениваться запросами и ответами с сервером управления услугами и получать авторизацию на эту услугу, абонент пользуется ГИП (графическим интерфейсом пользователя). Сервер может сигнализировать о доставке определенного приложения. Сервер не может устанавливать требования к политике запрашивающего хост-компьютера. Согласно современной практике, такие решения принимаются на периферии сети. В системе активного управления интеллектуальными возможностями сети (NAICS), для выполнения сетевых запросов используется заранее определенный, но динамически адаптируемый механизм. В современной практике хост-компьютер передает на основе минимальных усилий и принимает ААА через серверы, не выполняющие функции политики и передачи.NAICS использует программы-посредники на хост-компьютерах. Эти программы-посредники содержат базы данных, которые отображают типы приложений в параметры передачи и услуг. Запрашиваемые приложения соответствуют коду, представляющему параметры передачи и услуги. Эти параметры могут сигнализировать системе управления о потребностях конкретного хост-компьютера в услугах и политике. Хосткомпьютер передает пакет усовершенствованного интернет-протокола версии 6 [AdvancedInternet Protocol Version 6] (AIPv6) на локальный активный узел. Локальный активный узел, в ответ, передает хост-компьютеру переменную,хранящуюся в кэш-памяти программ локального узла, которая отображает IP-адрес отправителя. Хост-компьютер, в ответ на эту передачу локального активного узла, передает переменную,присвоенную узлом, и код, представляющий 16 параметры передачи и услуги, необходимые для данного приложения. Локальный активный узел сохраняет переменную, IP-адреса источника и назначения в таблице. Интерпретатор выполняет решение, основанное на содержимом таблицы. В базе данных локального активного узла хранится информация, существенная для выполнения решений по услугам и политике, в том числе, информация по использованию сетиSNMP, таблица IP-маршрутизации, таблица маршрутизации интерфейса с частной сетью(PNNI), протокол управления интернет-группами (IGMP), дополнительные приложения,ААА, DNS и DHCP. Локальный активный узел сообщает решение хост-компьютеру посредством передачи кода, содержащегося в пакетеAIPv6, хост-компьютеру. На основании выполненного решения локальный активный узел использует извлечения SNMP для переконфигурации сетевых устройств. Передача извлечений SNMP облегчает предоставление хосткомпьютеру запросов на конкретные параметры передачи и услуги. Механизм запросов и ответов AIPv6 между хост-компьютерами и локальными активными узлами упрощает существующую практику взаимодействия между хост-компьютерами и различными устройствами управления услугами и восполняет недостаток взаимодействия между хост-компьютерами - и устройствами управления политикой. Механизм запросов и ответов AIPv6 дает возможность локальным активным узлам и главным активным узлам синхронизировать информацию об использовании сети масштабируемым образом. Посредством SNMP активные локальные узлы опрашивают сетевые устройства для определения текущего использования сети. С учетом ограниченного количества устройств и хост-компьютеров, одного локального активного узла достаточно для проверки информации использования сети и для ответа на запросы конечных пользователей. В крупномасштабной сети, например, ЦАЛ/ГС, для выполнения этой задачи требуется несколько локальных активных узлов, и для синхронизации действий локальных активных узлов необходимо устройство более высокого уровня. Главный активный узел отвечает на запросы локальных активных узлов, чтобы гарантировать такую синхронизацию. С определенной периодичностью главный узел принимает пакеты AIPv6 от локальных активных узлов. С определенной периодичностью главный узел передает пакетыAIPv6, содержащие существенную информацию об использовании сети, пересылаемые от других локальных активных узлов. На запрос сигнализации AIPvS от локального активного узла, запрашивающего дополнительную сетевую информацию, главный узел отвечает посредством пакета AIPv6, предоставляющего необходимую информацию. 17 Такая практика обеспечивает прямую связь хост-компьютеров с платформами управления услугами/политикой, которые регистрируют параметры использования сети, передачи и услуг для централизованного выполнения запросов хост-компьютеров. В отличие от современной практики использования раздельных структур для разных платформ и функций, все функции управления услугами и политикой выполняются на единой платформе. Такое решение позволяет пользователям ЦАЛ использовать программу-посредник, которая поддерживает базу данных, обеспечивая сигнализацию AIPv6 системе локальный узел-главный узел, которая согласует запрашиваемые параметры с полномочиями уровня услуг и возможностями сети,тем самым обеспечивая преимущество над структурой управления услугами, основанной на принципах минимальных усилий, периферии и различных платформ, отвечающую уровню техники. Архитектура web-сервера NAICS Стратегия NAICS обеспечивает определение динамической политики, в отличие от современной практики статического применения административно определенных межсетевых фильтров. NAICS позволяет реализовать постоянный контроль, немедленную реакцию и динамическую политику, что гарантирует фильтрацию злонамеренного трафика и, в то же время,открывает доступ интернет-сообщества к webсерверу. Принципиальная архитектура webсервера NAICS предусматривает три компонента. Первый компонент представляет собой граничный маршрутизатор, подключающий webсервер(ы) к глобальной сети (ГС), локальной сети (ЛС) или общественному Интернету. Маршрутизатор сопрягается с платформой защиты активного узла NAICS, которая служит посредником между маршрутизатором и webсервером. Конечным компонентом этой архитектуры является web-сервер, играющий роль активного узла. Маршрутизаторы пересылают запрос клиента на платформу защиты активного узлаNAICS. NAICS пассивно перенаправляет входящие передачи (т.е. передачи, поступающие из сети, через маршрутизатор, на web-сервер), если эти пакеты не отвечают AIPv6. Пакеты AIPv6 обрабатываются, содержащийся в них код считывается, и необходимые решения выполняются. Все остальные пакеты, без обработки, переправляются на web-сервер, выполняющий функцию активного узла. Для таких пакетовNAICS обрабатывает каждый пакет AIPv6, переданный с web-сервера на маршрутизатор. Платформа NAICS содержит таблицы, позволяющие ей считывать пакеты AIPv6 и записы 004189 18 вать содержимое пакета в соответствующие таблицы. Эта контрольная функция согласуется с основными функциями активного узла и строится на их основе. На основе алгоритмов, определенных для контроля действий, согласующихся с распределенными атаками отказа от обслуживания, платформа NAICS записывает пакеты, передаваемые с web-сервера, и согласует таблицы, детализирующие записи этих пакетов, с упомянутыми алгоритмами. Алгоритмы могут выполнять заранее определенные скриптпрограммы, манипулирующие сетевыми устройствами. Платформа NAICS использует два механизма адаптации сетевых устройств для исправления эффектов, снижающих производительность сети. Используя интерфейс к скриптам протокола Telnet, платформа NAICS переконфигурирует список доступа маршрутизатора,принимающего трафик, адресованный webсерверу. Таким же образом, платформа NAICS выполняет скрипт, обеспечивающий осуществление команды tracerout, определяющей источник атаки. Используя тот же механизм для переконфигурации списков доступа, платформаNAICS может переконфигурировать список доступа, включив в него диапазон адресов всего маршрутизатора, от которого исходит атака. Этот механизм пресекает попытку нападающего динамически применять новые IP-адреса посредством блокировки всего диапазона адресов,откуда исходит атака. Второй механизм позволяет платформе NAICS применять пакеты AIPv6 для переконфигурации web-сервера, выполняющего функцию активного узла. ПлатформаNAICS выбирает код, согласующийся со скриптом, вызванным из сервисной атаки. ПакетAIPv6 доставляет код, который переконфигурирует web-сервер так, чтобы он манипулировал сетевыми параметрами для блокировки IPадресов и портов TCP/UDP, отвечающих за распределенные атаки отказа от обслуживания. В этой архитектуре функции активного узла могут быть предоставлены конечным пользователям. Компонент web-сервера позволяет хост-компьютерам загружать программупосредник активного узла, которая оптимизирует передачу между хост-компьютерами и webсервером. Входящие передачи от маршрутизатора, через платформу NAICS на web-сервер обрабатываются и оптимизируются платформойAIPv6 на web-сервер. Эти пакеты обрабатываются платформой NAICS, служащей посредником в передаче трафика между сетью и webсервером. Платформа NAICS считывает код,содержащийся в платформе AIPv6, и соответственно обрабатывает пакет. Выше были описаны и проиллюстрированы несколько вариантов осуществления способов и устройства для управления трафиком интернет-протокола в ГС или ЛС. Хотя были описаны конкретные варианты осуществления изо 19 бретения, изобретение не ограничивается ими,но его нужно рассматривать в самом широком объеме, насколько это позволяет развитие техники и описание изобретения. Поэтому для специалистов в данной области должно быть очевидно, что предложенное изобретение допускает и другие модификации, не выходящие за рамки сущности и объема, определенных формулой изобретения. ФОРМУЛА ИЗОБРЕТЕНИЯ 1. Устройство для управления трафиком в сети связи, содержащееb) множество локальных активных узлов,подключенных к сети, причем каждый локальный активный узел содержитi) средство опроса сетевых устройств для определения текущего использования сети,ii) средство направления запроса главному активному узлу и iii) средство приема ответа от главного активного узла, в котором локальные активные узлы направляют запрос главному активному узлу, запрашивая информацию о сетевых устройствах, опрашиваемых другим локальным активным узлом. 2. Устройство по п.1, отличающееся тем,что каждый локальный активный узел содержит средство передачи информации об опрашиваемых им сетевых устройствах главному активному узлу и главный активный узел содержит средство для периодической передачи информации использования сети локальным активным узлам. 3. Устройство по п.2, отличающееся тем,что локальные активные узлы опрашивают сетевые устройства посредством протокола SNMP(простой протокол управления сетью), и локальные активные узлы связываются с главным активным узлом посредством протокола AIP (усовершенствованного Интернетпротокола). 4. Устройство по п.1, отличающееся тем,что дополнительно содержит совокупность хост-компьютеров, связанных с каждым локальным активным узлом, при 004189 20 чем каждый хост-компьютер содержит средство направления запроса локальному активному узлу, с которым он связан. 5. Устройство по п.4, отличающееся тем,что упомянутые локальные активные узлы содержат средство ответа на запросы связанных с ними хост-компьютеров. 6. Способ управления трафиком в сети связи, содержащий этапы, на которыхa) связывают группы сетевых устройств с локальными активными узлами,b) опрашивают сетевые устройства из связанных с ними локальных активных узлов иc) передают информацию об использовании сетевого устройства от локальных активных узлов на главный активный узел. 7. Способ по п.6, отличающийся тем, что дополнительно содержит по меньшей мере один из этапов, на которыхd) направляют запрос от одного локального активного узла на главный активный узел,запрашивая информацию о сетевых устройствах, опрашиваемых другим локальным активным узлом,e) периодически передают информацию об использовании сети на локальные активные узлы от главного активного узла. 8. Способ по п.6, отличающийся тем, что локальные активные узлы опрашивают сетевые устройства посредством протоколаSNMP, и локальные активные узлы связываются с главным активным узлом посредством протокола AIP. 9. Способ по п.6, отличающийся тем, что дополнительно содержит этапы, на которыхd) связывают совокупность хосткомпьютеров с каждым локальным активным узлом,e) направляют запрос статуса сети с хосткомпьютера на локальный активный узел, с которым он связан. 10. Способ по п.9, отличающийся тем, что дополнительно содержит этап, на которомf) отвечают на запрос хост-компьютера от локального активного узла, связанного с хосткомпьютером.