Интегрированные сети ISDN

         

Формат записи атрибута Vendor-Specific



Рисунок .7. Формат записи атрибута Vendor-Specific

Старший октет ID изготовителя равен нулю, а младшие три октета представляют собой код изготовителя, как это определено в RFC-1700 (SMI Network Management Private Enterprise Code [2]). Порядок октетов сетевой.

Поле строка имеет один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. Строка должна кодироваться в виде последовательности тип производителя / длина / поля значений, специфические для производителя. Пример формата строки показан на Рисунок .8.




/H Среди параметров оптимизации


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

Практически все методы маршрутизации базируются на следующем утверждении (принцип оптимальности). Если маршрутизатор M находится на оптимальном пути от маршрутизатора I к маршрутизатору J, тогда оптимальный путь от М к J проходит по этому пути. Чтобы убедиться в этом обозначим маршрут I-M R1, а m-j - R2. Если существует маршрут оптимальнее, чем R2, то он должен быть объединен с R1, чтобы образовать более оптимальный путь I-J, что противоречит исходному утверждению об оптимальности пути J-J. Следствием принципа оптимальности является утверждение, что оптимальные маршруты от всех отправителей к общему месту назначения образуют дерево, лишенное циклов (см. разделы "Протокол ospf" и "Элементы теории графов"). Такое дерево (называется sink tree) может быть не единственным, могут существовать другие деревья с теми же длинами пути. А это, в свою очередь означает, что любой пакет будет доставлен за строго ограниченное время, пройдя однократно определенное число маршрутизаторов

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

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

IP делит все ЭВМ на маршрутизаторы и обычные ЭВМ (host), последние, как правило, не рассылают свои маршрутные таблицы. Предполагается, что маршрутизатор владеет исчерпывающей информацией о правильных маршрутах (хотя это и не совсем так). Обычная ЭВМ имеет минимальную маршрутную информацию (например, адрес маршрутизатора локальной сети и сервера имен). Автономная система может содержать множество маршрутизаторов, но взаимодействие с другими as она осуществляет только через один маршрутизатор, называемый пограничным (border gateway, именно он дал название протоколу bgp). Пограничный маршрутизатор нужен лишь тогда, когда автономная система имеет более одного внешнего канала, в противном случае его функции выполняет порт внешнего подключения (gateway). Если адресат достижим более чем одним путем, маршрутизатор должен сделать выбор, этот выбор осуществляется на основании оценки маршрутов-кандидатов. Обычно каждому сегменту, составляющему маршрут, присваивается некоторая величина - оценка этого сегмента. Каждый протокол маршрутизации использует свою систему оценки маршрутов. Оценка сегмента маршрута называется метрикой. Здесь следует обратить внимание на то, что при выборе маршрута всем сегментам пути должны быть даны сопоставимые значения метрики. Недопустимо, чтобы одни сегменты оценивались числом шагов, а другие - по величине задержки в миллисекундах. В пределах автономной системы это обычно не создает проблем, ведь это зона ответственности одного администратора. Но в региональных сетях, где работает много администраторов, проблема выбора метрики может стать реальной трудностью. Именно по этой причине в таких сетях часто используется вектор расстояния, исключающий субъективность оценок метрики.

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


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

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



Большинство алгоритмов учитывают топологию связей, а не их качество (пропускную способность, загрузку и пр.). Но существуют подходы к решению проблемы статической маршрутизации, учитывающие как топологию, так и загрузку (flow-based routing). В некоторых сетях потоки между узлами относительно стабильны и предсказуемы. В этом случае появляется возможность вычислить оптимальную схему маршрутов заранее. Здесь на основе теории массового обслуживания производится оценка средней задержки доставки для каждой связи. Топология маршрутов оптимизируется по значению задержки доставки пакета.Исходными данными при расчете считается описание топологии связей, матрица трафика для всех узлов Ti,j (в пакетах в секунду) и матрица пропускных способностей каналов Bi,j в битах в секунду. Задержка t для каждой из связей оценивается по формуле

ti,j = 1/(p*bi,j - ti,j),

где 1/Р - среднее значение ширины пакета в битах, произведение p*bi,j выражается в пакетах в секунду, а t измеряется в мсек. Сформировав матрицу ti,j, можно получить граф кратчайших связей. Так как вычисления производятся не в реальном масштабе времени, особых трудностей здесь не возникает.

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


Иллюстрация, поясняющее возникновение циклических маршрутов при использовании вектора расстояния



Рисунок 4.4.11.1. Иллюстрация, поясняющее возникновение циклических маршрутов при использовании вектора расстояния.


На верхней части рисунка показана ситуация, когда маршрутизаторы указывают маршрут до сети в соответствии со стрелками. На нижней части связь на участке GW1 оборвана, а GW2 по-прежнему продолжает оповещать о ее доступности с числом шагов, равным 2. При этом GW1, восприняв эту информацию (если GW2 успел передать свою маршрутную информацию раньше GW1), может перенаправить пакеты, адресованные сети А, на GW2, а в своей маршрутной таблице будет характеризовать путь до сети А метрикой 3. При этом формируется замкнутая петля маршрутов. Последующая широковещательная передача маршрутных данных GW1 и GW2 не решит эту проблему быстро. Так после очередного обмена путь от gw2 до сети А будет характеризоваться метрикой 5. Этот процесс будет продолжаться до тех пор, пока метрика не станет равной 16, а это займет слишком много циклов обмена маршрутной информацией.

Проблема может быть решена следующим образом. Маршрутизатор запоминает, через какой интерфейс получена маршрутная информация, и через этот интерфейс эту информацию уже не передает. В рассмотренном выше примере GW2 не станет посылать информацию о пути к сети А маршрутизатору GW1, от которого он получил эти данные. В этом случае в маршрутной таблице GW1 путь до А исчезнет сразу. Остальные маршрутизаторы узнают о недостижимости сети А через несколько циклов. Существуют и другие пути преодоления медленных переходных процессов. Если производится оповещение о коротком пути, все узлы-получатели воспринимают эти данные немедленно. Если же маршрутизатор закрывает какой-то путь, его отмена фиксируется остальными лишь по тайм-ауту. Универсальным методом исключения ошибок при маршрутизации является использование достаточно большой выдержки, перед тем как использовать информацию об изменении маршрутов. В этом случае к моменту изменения маршрута эта информация станет доступной всем участникам процесса маршрутизации.
Но все перечисленные методы и некоторые другие известные алгоритмы, решая одну проблему, часто вносят другие. Многие из этих методов могут при определенных условиях вызвать лавину широковещательных сообщений, что также дезорганизует сеть. Именно малая скорость установления маршрутов в RIP (и других протоколах, ориентированных на вектор расстояния) и является причиной их постепенного вытеснения другими протоколами.

Но даже усовершенствование, изложенное выше, не всегда срабатывает. На Рисунок 4.4.11.1а приведен пример, когда переходной процесс, несмотря на усовершенствование будет идти долго. При обрыве связи В-Г узлы А и Б сообщают узлу В, что они потеряли связь с узлом Г. Узел В делает вывод, что Г не достижим, о чем и сообщает узлам А и Б. К сожалению А знает, что Б имеет проход к Г длиной 2, из чего он делает вывод о достижимости Г за три шага. Аналогично рассуждает Б о возможности достижимости Г через А. Далее при последующих рассылках метрика доступности Г, характеризуется все большими значениями, до тех пор пока не станет равной "бесконечности".


Имена, зарезервированные слова и представления RPSL


2. Имена, зарезервированные слова и представления RPSL

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

Значение любого атрибута имеет определенный тип. Язык RPSL не чувствителен к тому, в каком регистре записаны те или иные выражения. Далее перечислены наиболее часто используемые типы атрибутов.

Многие объекты в RPSL имеют имя. <object-name> составляется из букв, чисел, а также символов подчеркивания ("_") и дефисов ("-"), первым символов всегда должна быть буква, а последним символом - буква или цифра. Следующие слова зарезервированы в RPSL, и не могут использоваться в качестве имен:

any as-any rs-any peeras

and or not

atomic from to at action accept announce except refine

networks into inbound outbound

Имена, начинающиеся с определенных префиксов зарезервированы для определенных типов объектов. Имена, начинающиеся с "as-" зарезервированы для имен автономных систем. Имена, начинающиеся с "rs-" зарезервированы для набора имен маршрутов. Имена, начинающиеся с "rtrs-" зарезервированы для набора имен маршрутизаторов. Имена, начинающиеся с "fltr-" зарезервированы для набора имен фильтров. Имена, начинающиеся с "prng-" зарезервированы для набора имен партнеров.

<as-number>

Номер AS x представляется в виде строки "ASx". То есть автономная система 226 характеризуется с помощью AS226.

<ipv4-address>

Адрес IPv4 характеризуется последовательностью из четырех целых чисел, лежащих в диапазоне от 0 до 255, разделенные символом точка ".". Например, 192.148.166.48.

<address-prefix>

Адресный префикс представляет собой IPv4-адрес, за которым следует символ косой черты "/" и без пробела целое число, лежащее в диапазоне 0-32. Примерами адресных префиксов могут служить:
<
/p> 192.224.128.5/32, 192.148.0.0/16, 0.0.0.0/0. Следующие адресные префиксы являются неверными: 0/0, 192.10/16, так как 0 или 192.10 не являются строками, содержащими четыре целые числа.



<address-prefix-range>
Диапазоном адресных префиксов является адресный префикс, за которым следует опционный оператор диапазона. Операторами диапазона являются:
^- оператор значений “больше, исключая”. Он служит для выделения адресных префиксов больше указанного, но исключая пограничное значение префикса. Например, 128.9.0.0/16^- содержит все префиксы больше 128.9.0.0/16, исключая значение 128.9.0.0/16.
^+ оператор значений “больше, включая”. Он служит для выделения адресных префиксов больше указанного, включая пограничное значение префикса. Например, 5.0.0.0/8^+ содержит все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8.
^n где n целое, выделяет из адресного префикса все значения с длиной n. Например, 30.0.0.0/8^16 содержит все префиксы более 30.0.0.0/8, которые имеют длину 16, такие как 30.9.0.0/16.
^n-m где n и m целые числа, выделяет из адресного префикса все значения с длинами в интервале от n до m. Например, 30.0.0.0/8^24-32 содержит все значения из префикса 30.0.0.0/8, которые имеют длины в интервале 24-32, такие как 30.9.9.96/28.
Операторы диапазона могут применяться для наборов адресных префиксов. Например, для набора маршрутов rs-foo, rs-foo^+ (определенный ниже) содержит все специфические данные о префиксах в rs-foo.

Применение двух операторов диапазона последовательно является ошибкой (напр. 30.0.0.0/8^24-28^+ - ошибка). Однако оператор диапазона может быть применен к набору адресных префиксов, содержащий диапазоны адресных префиксов (напр. {30.0.0.0/8^24-28}^27-30 не является ошибкой). В этом случае, внешний оператор ^n-m располагается над внутренним оператором ^k-l и становится оператором ^max(n,k)-m, если m больше или равно max(n,k), в противном случае префикс удаляется из набора. Заметим, что оператор ^n эквивалентен ^n-n. Префикс/l^+ эквивалентен префиксу prefix/l^l-32.


Префикс/l^- эквивалентен префиксу prefix/l^(l+1)-32. Префикс {prefix/l^n-m}^+ эквивалентен префиксу {prefix/l^n-32}, а префикс {prefix/l^n-m}^- эквивалентен префиксу {prefix/l^(n+1)-32}. Например,

{128.9.0.0/16^+}^- == {128.9.0.0/16^-}
{128.9.0.0/16^-}^+ == {128.9.0.0/16^-}
{128.9.0.0/16^17}^24 == {128.9.0.0/16^24}
{128.9.0.0/16^20-24}^26-28 == {128.9.0.0/16^26-28}
{128.9.0.0/16^20-24}^22-28 == {128.9.0.0/16^22-28}
{128.9.0.0/16^20-24}^18-28 == {128.9.0.0/16^20-28}
{128.9.0.0/16^20-24}^18-22 == {128.9.0.0/16^20-22}
{128.9.0.0/16^20-24}^18-19 == {}
/TR>

<date> Дата представляется в виде восьми десятичных цифр вида YYYYMMDD, где YYYY отображает год, MM представляет месяц (01 - 12) и DD характеризует день месяца (01 - 31). Все даты, если не определено что-то иное, задаются в стандарте UTC. Например, 07 июля 1938 представляется в виде 19380707.
<email-address> описано в RFC-822 [10].
<dns-name> описано в RFC-1034 [17].
<nic-handle> представляет собой уникальный идентификатор, используемый при маршрутизации, присвоении адресов и т.д. для того, чтобы обеспечить однозначную ссылку на контактную информацию. Классы person и role связывают указатели NIC с действительными именами людей и контактной информацией.
<free-form> представляет собой последовательность ASCII-символов.
<X-name> является именем объекта типа X. То есть <mntner-name> является именем объекта mntner.
<registry-name> является именем регистратора IRR.
Значением атрибута может быть также список одного из этих типов. Элементы списка отделяются друг от друга запятыми. Например, "AS1, AS2, AS3, AS4". Заметим, что значение-список ортогонально многозначности. Многозначный атрибут имеет более одного значения, каждое из которых может быть, а может и не быть списком. С другой стороны однозначный атрибут может иметь значение-список. Объект RPSL текстуально представляется в виде списка пар атрибут-значение. Каждая пара атрибут-значение записывается на отдельной строке.


Имя атрибута начинается с колонки 0 и завершается двоеточием. Далее следует значение атрибута. Атрибут, который имеет то же имя, что и класс объекта должен быть специфицирован раньше. Представление объекта завершается пустой строкой. Значение атрибута может занимать несколько строк, для этого очередная строка должна начинаться с символа пробел, табулятор или знак плюс ('+'). Символ "+" для строки продолжения позволяет значениям атрибута содержать пустые строки. Порядок размещения пар атрибут-значение является существенным.

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

Целые числа могут задаваться:

в нотации языка программирования C (напр. 1, 12345),

в виде последовательности четырех одно-октетных целых чисел (в диапазоне 0-255), разделенных символом точка "." (например, 1.1.1.0, 255.255.0.0), в этом случае 4-октетное целое образуется объединением этих однооктетных целых чисел, начиная с наиболее значимых,

в виде двух 2-октетных целых чисел (в диапазоне 0 - 65535), разделенных символом двоеточие ":" (например, 3561:70, 3582:10), в этом случае 4-октетное целое число образуется путем объединения всех октетов в порядке их значимости.




Использование номеров AS и маршрутных наборов



Рисунок .15. Использование номеров AS и маршрутных наборов.

Набор rs-any содержит все маршруты, зарегистрированные в IRR. Набор as-any содержит все AS, зарегистрированные в IRR.

5.4. Класс Filters и filter-set

Атрибуты класса filter-set представлены на Рисунок 16. Объект filter-set определяет набор маршрутов, которые соответствуют этому фильтру. Атрибут filter-set определяет имя фильтра. Он является именем RPSL, которое начинается с "fltr-".

Атрибут

Значение

Тип

filter-set

<object-name>

обязательный, однозначный, ключ класса

filter

<filter>

обязательный, однозначный



Экспортное объединение с исключениями



Рисунок .31. Экспортное объединение с исключениями.

Атрибут inject определяет, какие маршрутизаторы выполняют объединение, и когда они это делают. Синтаксис атрибута показан ниже:

inject:

[at <router-expression>] ...

[action <action>]

[upon <condition>]

где <action> - спецификация действия (см. раздел 6.1.1), <condition> - булево выражение, описанное ниже, <router-expression> описано в разделе 5.6.

Все маршрутизаторы в <router-expression> и в агрегаторе (объединении) AS выполняют агрегацию. Если <router-expression> не специфицировано, все маршрутизаторы внутри агрегатора AS выполняют агрегацию. Спецификация <action> может установить атрибуты path объединения (aggregate), например, определить предпочтения для объединения.

Так как условие является булевым выражением, объединение создается, если и только если это условие истинно. <condition> - булево выражение, использующее логические операторы AND и OR (т.e. оператор NOT не разрешен):

HAVE-COMPONENTS { список префиксов }

EXCLUDE { список префиксов }

STATIC

Список префиксов в HAVE-COMPONENTS может состоять из более специфических префиксов объединения. Список может также включать диапазоны префиксов (т.e. использование операторов ^-, ^+, ^n, и ^n-m). В этом случае, по крайней мере, один префикс из каждого диапазона префиксов должен присутствовать в каждой маршрутной таблице, для того чтобы условие было выполнено. Список префиксов в EXCLUDE может быть произвольным. Условие выполняется, когда ни один из перечисленных префиксов не содержится в маршрутной таблице. Список может содержать диапазоны префиксов, а ни один префикс из этого диапазона не должен присутствовать в маршрутной таблице. Ключевое слово static всегда предполагается равным true.

route:

128.8.0.0/15

origin:

AS1

components:

{128.8.0.0/15^-}

aggr-mtd:

outbound AS-ANY

inject:

at 1.1.1.1 action dpa = 100;

inject:

at 1.1.1.2 action dpa = 110;

route:

128.8.0.0/15

origin:

AS1

components:

{128.8.0.0/15^-}

aggr-mtd:

outbound AS-ANY

inject:

upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16}

holes:

128.8.8.0/24



Класс Advanced route


8. Класс Advanced route

8.1. Спецификация агрегатных маршрутов

Атрибуты components, aggr-bndry, aggr-mtd, export-comps, inject и holes используются для спецификации агрегатных маршрутов [11]. Объект route специфицирует агрегатный маршрут, если специфицирован любой из этих атрибутов за исключением inject. Атрибут origin для агрегатного маршрута производит объединение маршрутов на базе AS. Здесь термин "aggregate" используется в отношении генерируемого маршрута, термин "component" относится к маршрутам, использованным для формирования атрибута объединения (aggregate) path, а термин "more specifics" относится к любому маршруту, который более специфичен для объединения, вне зависимости от того, используется ли он при формировании атрибутов path. Атрибут components определяет, какой из составляющих маршрутов используется для формирования объединения. Его синтаксис выглядит следующим образом:

components: [ATOMIC] [[<filter>] [protocol <protocol> <filter> ...]]

где <protocol> представляет собой имя протокола маршрутизации, такого как BGP4, OSPF или RIP (допустимые значения определяются словарем), а <filter> - выражение политики. Маршруты, соотносятся с одним из этих фильтров и получены с помощью соответствующего протокола, используются для формирования объединения (aggregate). Если <protocol> опущен, по умолчанию предполагается любой протокол. <filter> неявно содержит термин "AND" с более специфическими префиксами объединения, так что выбираются только маршруты компоненты. Если используется ключевое слово ATOMIC, объединение выполнено на уровне атомов [11]. Если атрибут components пропущен, используются все более специфичные префиксы без ключевого слова ATOMIC.

route: 128.8.0.0/15

origin: AS1

components: <^AS2>

route: 128.8.0.0/15

origin: AS1

components:

protocol BGP4 {128.8.0.0/16^+}

protocol OSPF {128.9.0.0/16^+}



Класс aut-num


6. Класс aut-num



Маршрутная политика специфицируется с использованием класса aut-num. Атрибуты класса aut-num представлены на Рисунок .23. Значение атрибута aut-num равно номеру AS, описанной данным объектом. Атрибут as-name является символическим именем (в рамках синтаксиса имен RPSL) AS. Импорт, экспорт и маршрутная политика по умолчанию AS специфицируются, используя атрибуты import, export и default, соответственно.

Атрибут

Значение

Тип

aut-num

<as-number>

обязательный, однозначный, ключ класса

as-name

<object-name>

обязательный, однозначный

member-of

Список <as-set-names>

опционный, многозначный

import

См. раздел 6.1

опционный, многозначный

export

См. раздел 6.2

опционный, многозначный

default

См. раздел 6.5

опционный, многозначный



Класс dictionary


7. Класс dictionary



Класс dictionary обеспечивает расширяемость для RPSL. Объекты словаря определяют атрибуты маршрутной политики, типы и маршрутные протоколы. Атрибуты маршрутной политики, впредь называемые rp-атрибутами, могут соответствовать действительным протокольным атрибутам, таким как атрибуты пути BGP (напр., community, dpa и AS-path), или они могут соответствовать особенностям маршрутизатора (напр., гашение осцилляций маршрутов в BGP). Когда вводятся новые протоколы, новые протокольные атрибуты, или новые возможности миршрутизатора, объект словаря актуализуется, с тем чтобы ввести соответствующее описание rp-атрибута или протокола.

rp-атрибут относится к абстрактному классу, то есть представление данных не доступно. Вместо этого, доступ к ним определяется методом доступа. Например, rp-атрибут для BGP-атрибута AS-path называется aspath, и он имеет метод доступа, называемый prepend,

который вставляет дополнительные номера AS в атрибуты AS-path. Методы доступа могут воспринимать аргументы. Аргументы строго типофицируются. Например, метод prepend воспринимает номера AS в качестве аргументов.

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

Ниже рассматривается синтаксис и семантика класса dictionary. Это описание не существенно для понимания объектов dictionary (но оно существенно для их создания).

Атрибуты класса dictionary представлены на Рисунок .24. Атрибут dictionary является именем объекта словаря, подчиняющимся правилам присвоения имен в RPSL. Может существовать много объектов словаря, однако имеется только один стандартный объект "RPSL". Все средства используют этот словарь по умолчанию.

Атрибут

Значение

Тип

Dictionary

<object-name>

обязательный, однозначный, ключ класса

rp-attribute

См. описание в тексте

опционный, многозначный

typedef

См. описание в тексте

опционный, многозначный

protocol

См. описание в тексте

опционный, многозначный



Класс inet-rtr


9. Класс inet-rtr



Маршрутизаторы специфицируются с использованием класса inet-rtr. Атрибуты класса inet-rtr показаны на Рисунок 35. Атрибут inet-rtr представляет собой допустимое имя DNS описанного маршрутизатора. Каждый атрибут alias, если он присутствует, является каноническим именем DNS для маршрутизатора. Атрибут local-as специфицирует номер AS, которой управляет данный маршрутизатор.

Атрибут

Значение

Тип

inet-rtr

<dns-name>

обязательный, однозначный, ключ класса

alias

<dns-name>

опционный, многозначный

local-as

<as-number>

обязательный, однозначный

ifaddr

См. описание в тексте

обязательный, многозначный

peer

См. описание в тексте

опционный, многозначный

member-of

список <rtr-set-names>

опционный, многозначный



Классы Set


5. Классы Set

При спецификации политики часто полезно определить наборы объектов. Для этих целей определены классы as-set, route-set, rtr-set, filter-set, and peering-set. Эти классы определяют именованный набор. Члены этих наборов могут быть специфицированы непосредственно путем перечисления их в определении набора, или косвенно, имея ссылки членов-объектов на имена наборов. Допускается применение обоих методов.

Имя набора является словом rpsl со следующими ограничениями. Все имена as-set начинаются с префикса "as-". Все имена route-set начинаются с префикса "rs-". Все наборы имен rtr-set начинаются с префикса "rtrs-". Все имена filter-set начинаются с префикса "fltr-". Все имена peering-set начинаются с префикса "prng-". Например, as-foo является корректным именем as-set.

Имена наборов могут быть иерархическими. Имя иерархического набора представляет собой последовательность имен наборов и номеров AS, разделенных символом двоеточие ":". По крайней мере, одна компонента такого имени должна быть действительным именем набора (то есть начинается с одного из префиксов). Все компоненты имени набора иерархического имени должны иметь один и тот же тип. Например, следующие имена корректны: AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2, RS-EXCEPTIONS:RS-BOGUS.

Целью имени иерархического набора является выделение определенного пространства имен, так что администратор набора X1 управляет всем набором нижележащих имен, то есть X1:...:Xn-1. Таким образом, набор объектов с именем X1:...:Xn-1:Xn может быть создан администратором объекта с именем X1:...:Xn-1. То есть, только администратор AS1 может создать набор с именем AS1:AS-FOO. Только администратор AS1:AS-FOO может создать набор с именем AS1:AS-FOO:AS-BAR.

5.1. Класс as-set

Атрибуты класса as-set показан на Рисунок .9. Атрибут as-set определяет имя набора. Он является именем RPSL, которое начинается с "as-". Атрибут members перечисляет членов набора. Атрибут members является списком AS, или других имен as-set.




Атрибут


Значение


Тип
as-set <object-name> обязательный, однозначный, ключ класса
members список <as-numbers> или

опционный, многозначный
Mbrs-by-ref список <mntner-names> опционный, многозначный

Конфигурация маршрутизатора



Рисунок 4.4.9.6.2. Конфигурация маршрутизатора

Для простоты эти примеры показывают flowspec как одномерное кратное повторение некоторого базового качества ресурса B. Колонка "Резервирует" показывает запросы резервирования RSVP, полученные через выходные интерфейсы IВ и IГ, а колонка "Получает" показывает результирующее состояние резервирования для каждого интерфейса. Колонка "Посылает" показывает запросы резервирования, посланные предшествующим узлам (IА и IБ). В колонке "Резервирует” каждая рамка представляет один зарезервированный виртуальный канал с соответствующим дескриптором потока.



Контактная информация


3. Контактная информация



Классы mntner, person и role, а также атрибуты admin-c, tech-c, mnt-by, changed и всех классов характеризуют контактную информацию. Класс mntner специфицирует также аутентификационную информацию, необходимую для того, чтобы создать, ликвидировать или модифицировать другие объекты. Эти классы не специфицируют маршрутную политику и каждый реестр может иметь различные или дополнительные требования. В документе "Routing Policy System Security" [20] описана модель аутентификации и авторизации.

3.1. Класс mntner

Класс mntner специфицирует аутентификационную информацию, необходимую для того, чтобы создать, ликвидировать или модифицировать объекты RPSL. Провайдер прежде чем создавать RPSL-объект, должен создать объект mntner. Атрибуты класса mntner показаны на Рисунок .1. Класс mntner описан в [13].

Атрибут mntner является обязательным и выполняет функцию ключа класса. Его значение – имя RPSL. Атрибут auth специфицирует схему, которая будет использоваться для идентификации и аутентификации запросов актуализации. Атрибут имеет следующий синтаксис:

auth: <scheme-id> <auth-info>

Например, auth: NONE

Атрибут

Значение

Тип

Mntner

<object-name>

обязательный, однозначный, ключ класса

Descry

<free-form>

обязательный, однозначный

Auth

Смотри описание в тексте

обязательный, многозначный

upd-to

<email-address>

обязательный, многозначный

mnt-nfy

<email-address>

опционный, многозначный

tech-c

<nic-handle>

обязательный, многозначный

admin-c

<nic-handle>

опционный, многозначный

remarks

<free-form>

опционный, многозначный

notify

<email-address>

опционный, многозначный

mnt-by

список <mntner-name>

обязательный, многозначный

changed

<email-address> <date>

обязательный, многозначный

source

<registry-name>

обязательный, однозначный



Маршрутизатор, использующий RSVP



Рисунок 4.4.9.6.6. Маршрутизатор, использующий RSVP

На Рисунок 4.4.9.6.6 проиллюстрирована модель RSVP узла маршрутизатора. Каждый поток данных приходит со стороны предшествующего узла через соответствующий входной интерфейс и выходит из маршрутизатора через один или несколько выходных интерфейсов. Один и тот же интерфейс для разных потоков в пределах одной сессии может выполнять как входную, так и выходную роль. Несколько предшествующих узлов и/или последующих узлов могут для коммуникаций использовать один и тот же физический интерфейс; например, на рисунке два узла Г и Г' подключены к широковещательной сети через интерфейс IГ. Существует два фундаментальных типа сообщений RSVP: Resv и Path. Каждый получатель посылает свой RSVP запрос резервирования в виде сообщений (Resv) отправителям данных. Эти сообщения должны двигаться в точности тем же маршрутом с учетом выбора отправителей, что и данные только в противоположном направлении. Они создают и поддерживают состояние резервирования в каждом узле вдоль маршрута. Сообщения Resv должны быть, в конце концов, доставлены ЭВМ-отправителям, таким образом, ЭВМ устанавливают параметры управления трафиком.

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

Шаблон отправителя

Сообщение Path должно нести в себе шаблон отправителя (Sender Template), который описывает формат пакетов данных, посылаемых отправителем. Этот шаблон имеет форму спецификации фильтра, которая может использоваться для отделения пакетов данного отправителя от других пакетов в пределах сессии.

Шаблоны отправителя имеют тот же формат, что и спецификации фильтра, которые используются в сообщениях Resv.
Следовательно, шаблон отправителя может специфицировать только его IP-адрес и опционно UDP/TCP порт, с учетом идентификатора протокола, заданного для сессии.

Спецификация Tspec отправителя

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

Спецификация Adspec

Сообщение Path может нести в себе пакет данных оповещения OPWA, известный, как "Adspec". Пакет Adspec, полученный с сообщением Path, передается системе управления трафиком, которая присылает скорректированную версию Adspec. Последняя пересылается далее в виде сообщения Path.

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

6. Объединение Flowspecs

Сообщение Resv, переадресованное предшествующему узлу, несет в себе спецификацию flowspec, которая является “наибольшей” из всех flowspec, запрошенных последующими узлами, которым будут посылаться данные.

Так как flowspecs непрозрачны для RSVP, действительные правила для сравнения flowspecs должны быть определены и реализованы вне рамок этого протокола. Реализация RSVP потребует обращения к специальной программе для выполнения объединения спецификаций flowspec.

Заметим, что спецификации flowspecs представляют собой в общем случае многомерные векторы; они могут содержать как Tspec, так и Rspec компоненты, каждая из которых может сама быть многомерной. Например, если один запрос требует высокой пропускной способности, а другой – жесткого ограничения задержек, один не может быть "больше" другого. В таком случае, вместо взятия большего, прикладная программа объединения должна быть способна сформировать такую спецификацию flowspec, которая по крайне мере столь же велика, как и каждая из составляющих; математически это наименьший верхний предел LUB (least upper bound).


В некоторых случаях спецификация flowspec по крайне мере настолько мала насколько возможно; это наибольший верхний предел GLB (Greatest Lower Bound).

Для вычисления эффективного значения flowspec (Re, Te), инсталлируемого в интерфейс, используются следующие шаги [RFC 2210]. Здесь Te – эффективная спецификация Tspec, а Re – эффективная спецификация Rspec.

Определяется эффективная спецификация flowspec для выходного интерфейса. В зависимости от технологии канального уровня, это может требовать объединения спецификаций flowspecs различных последующих узлов. Это означает вычисление эффективной спецификации flowspec, как LUB flowspecs. Какие спецификации следует объединять, определяется средой канального уровня, в то время как процедура объединения определяется используемой моделью обслуживания [RFC 2210]. В результате получается спецификация flowspec, которая непрозрачна для RSVP, но в действительности состоит из пары (Re, Resv_Te), где Re является эффективной спецификацией Rspec, а Resv_Te - эффективная спецификация Tspec.

Производится вычисление спецификации Path_Te, зависящей от приложения и представляющей собой сумму всех Tspecs, которые были присланы в сообщениях Path, пришедших от различных предшествующих узлов (напр., некоторые или все узлы A, Б, и Б' на Рисунок 4.4.9.6.6).

(Re, Resv_Te) и Path_Te передаются системе управления трафиком. Управление трафиком вычислит эффективную спецификацию flowspec, как минимум Path_Te и Resv_Te.

7. Гибкое состояние

RSVP использует подход "soft state" (гибкое состояние) для управления состоянием резервирования в маршрутизаторах и ЭВМ. Гибкое состояние RSVP создается и периодически освежается посредством сообщений Path и Resv. Состояние уничтожается, если не приходит подтверждения в течение заданного времени тайм-аута очистки. Состояние может быть стерто также посредством сообщения "teardown" (уничтожение). По истечении каждого таймаута обновления и после любых изменений состояния RSVP осуществляет проверку, для того чтобы подготовить и отправить сообщения обновления Path и Resv последующим узлам.



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

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

Состояние, поддерживаемое RSVP, является динамическим. Для изменения набора отправителей Si или изменения любого запроса QoS, ЭВМ просто начинает посылать измененные сообщения Path и/или Resv. В результате будет осуществлено соответствующее изменение RSVP-состояния во всех узлах вдоль пути, неиспользуемые состояния будут аннулированы по таймауту, если не поступит прямых указаний по их ликвидации до этого.

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



Состояние, которое получено через конкретный интерфейс I* никогда не должно переадресовываться этому интерфейсу. Состояние, которое направляется интерфейсу I* должно вычисляться на основе состояний, полученных от других интерфейсов, исключая I*. Тривиальный пример, поясняющий это правило приведен на Рисунок 4.4.9.6.7, на котором показан маршрутизатор с одним отправителем и одним получателем на каждом интерфейсе (R1, S1 и R2, S2). Интерфейсы IA и IБ выполняют как входные, так и выходные функции. Оба получателя используют WF-стиль резервирования, в котором сообщения Resv переадресуются всем предшествующим узлам группы вдоль маршрута, за исключением узла, от которого это сообщение получено. В результате достигается независимое резервирование для обоих направлений (на Рисунок 4.4.9.6.7 “Получает” и “Отправляет” подразумевает внешнее направление по отношению к маршрутизатору).



Интерфейс IА Интерфейс IБ
Получает Отправляет Получает Отправляет
WF (* {4B}) WF (* {3B}) WF (* {3B}) WF(*{4B})
Резервирует
* {4B} * {3B}

Маршрутизаторы, подключенные к локальной сети



Рисунок 4.4.11.5. Маршрутизаторы, подключенные к локальной сети

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

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

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

стационарные, работающие всегда на своем постоянном месте в локальной сети

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

подвижные, перемещающиеся в пространстве и желающие работать в процессе перемещения.

Предполагается, что все эти пользователи имеют свою постоянную приписку к какой-то сети и соответствующий постоянный IP-адрес. (см. RFC-2794 "Mobile IP Network Access Identifier Extension for IPv4. P. Calhoun, C. Perkins. March 2000). На Рисунок 4.4.11.6 показана схема подключения подвижных пользователей к Интернет. В этой схеме предполагается наличие в каждой области сети Интернет внешнего агента, обеспечивающего доступ к этой зоне подвижных ЭВМ (на рисунке такой агент помечен надписью "чужая LAN"). Доступ может осуществляться через мобильную телефонную сеть. Предполагается также наличие соответствующего агента в "домашней" LAN, куда стационарно приписана данная ЭВМ. Домашний агент отслеживает все перемещения своих пользователей, в том числе и тех, кто подключается к "чужим" LAN.



Некоторые другие процедуры Интернет



4.5.16 Некоторые другие процедуры Интернет

NFS

NFS (network file system, sun microsystems, RFC-1094) обеспечивает прозрачный доступ к удаленным файлам так, что с точки зрения программиста эти файлы выглядят, как местные. При этом даже в написании имен файлов никак не проявляется их истинное местонахождение. NFS является частью операционной системы. Различие работы с местными и удаленными файлами проявляется лишь на системном уровне. Пользователь может почувствовать различие лишь по времени выполнения соответствующих операций обмена. nfs поддерживает операции по созданию, переименованию, копированию и стиранию файлов или каталогов и т.д.

Основой системы NFS является вызов удаленных процедур RPC, схема взаимодействия "клиент-сервер". NFS-сервер получает запросы от клиента в виде UDP-дейтограмм через порт 2049 (



Независимые резервирования



Рисунок 4.4.9.6.7. Независимые резервирования

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

8. Аннулирование (Teardown)

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

Существует два типа RSVP сообщений аннулирования: PathTear и ResvTear. Сообщение PathTear направляется всем получателям и ликвидирует состояние прохода, а также все зависящие от него состояния резервирования. Сообщение ResvTear уничтожает состояние резервирования и направляется всем отправителям.

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

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

Необходимо иметь возможность ликвидировать любой субнабор установленных состояний. Для состояний прохода минимально это может быть один отправитель. Для состояний резервирования таким объектом является спецификация фильтра.
Например, в случае, показанном на Рисунок 4.4.9.6.7, получатель R1 может послать сообщение ResvTear только отправителю S2 (или любому субнабору из списка спецификаций фильтрации), оставляя S1 без изменений.

Сообщение ResvTear специфицирует стиль и фильтры, любая спецификация flowspec игнорируется. Любая рабочая спецификация flowspec будет убрана, если все ее спецификации фильтров будут ликвидированы.

9. Ошибки

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

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

Первая проблема резервирования килера (KR-I) возникает, когда уже имеется резервирование Q0. Если другой получатель делает новое Q1 > Q0, результирующее объединенное резервирование Q0 и Q1 может быть отвергнуто системой контроля доступа в некотором последующем узле. Это не должно вредить услугам на уровне Q0. Решение этой проблемы весьма просто: когда контроль доступа не пропускает запрос резервирования, существующее состояние резервирования сохраняется.

Вторая проблема (KR-II) противоположна первой: получатель, выполняющий резервирование Q1, сохраняется даже в случае не прохождения контроля доступа для Q1 в каком-то узле. Это не должно мешать другому получателю, установить меньшее резервирование Q0, которое бы прошло, если бы не было объединено с Q1.



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

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

Имеется две возможные причины получателю настаивать на резервировании:

Заказываемый ресурс доступен по всей длине пути, или

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

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

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

10. Подтверждение

Чтобы запросить подтверждение на свое резервирование, получатель Rj включает в сообщение Resv объект запроса подтверждения, содержащий IP-адрес Rj. В каждой точке объединения только наибольшая из спецификаций flowspec и соответствующий объект запроса подтверждения посылаются далее.


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

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

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

Получение ResvConf не предоставляет никаких гарантий. Предположим, что два запроса резервирования от получателей R1 и R2 пришли в узел, где они были объединены. R2, чье резервирование было вторым по времени, может получить подтверждение ResvConf от данного узла, в то время как запрос R1 еще не прошел весь путь и он может еще быть отвергнут каким-то последующим узлом. Таким образом, R2 может получить ResvConf, когда не имеется полномасштабного резервирования вдоль всего пути; более того, R2 может получить ResvConf, за которым последует сообщение ResvErr.

11. Управление политикой

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

Когда запрашивается новое резервирование, каждый узел должен ответить на два вопроса: "Имеется ли достаточно ресурсов, чтобы удовлетворить запрос?" и "Позволено ли данному пользователю осуществлять резервирование?" Эти два решения называются "управлением доступа" и "управлением политикой", соответственно.


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

На вход управления политикой поступают специфические блоки данных, которые заключены в объектах POLICY_DATA протокола RSVP. Эти блоки данных могут включать в себя параметры доступа пользователя, его класс, номер аккоунта, пределы квоты и пр. Подобно flowspecs, эти данные недоступны для RSVP, который просто передает их, когда требуется, системе управления политикой. Аналогично, объединение этих данных должно выполняться системой управления политикой, а не самим протоколом RSVP. Заметим, что точки объединения данных, характеризующих политику, должны находиться на границах административных доменов.

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

12. Безопасность

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

Целостность сообщений и аутентификация узлов

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

Аутентификация пользователя

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



Безопасные потоки данных

Первые два пункта касались выполнения операций RSVP. Третий пункт касается резервирования для безопасных потоков данных. В частности, использование IPSEC (IP Security) в потоке данных создает проблему для RSVP: если транспортный и вышележащие заголовки зашифрованы, общие номера порта RSVP не могут использоваться для определения сессии или отправителя.

Для решения этой проблемы определено расширение RSVP, в котором идентификатор секретности (IPSEC SPI) играет ту же роль что и номер порта [RFC 2207].

13. Области, не поддерживающие RSVP

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

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

Хотя RSVP работает корректно и через сетевые области без поддержки RSVP, узлы из этой области могут внести искажения в QoS. При встрече области без поддержки RSVP протокол устанавливает бит-флаг `NonRSVP' и передает его механизму управления трафиком.


Управление трафиком комбинирует этот однобитовый флаг со своей собственной информацией об источниках и передает ее вдоль транспортного пути получателям, используя спецификацию Adspecs [RFC 2210].

При некоторых топологиях маршрутизаторов с и без поддержки RSVP возможна доставка сообщений Resv в не тот узел, или не тот интерфейс. Процесс RSVP должен быть готов обрабатывать такие ситуации. Если адрес места назначения не соответствует ни одному локальному интерфейсу, а сообщение не является Path или PathTear, тогда оно должно передаваться далее без какой-либо обработки в данном узле. Чтобы обработать случай с неправильным интерфейсом, используется дескриптор логического интерфейса LIH (Logical Interface Handle). Информация предыдущего узла, включенная в сообщение Path, содержит не только IP-адрес предшествующего узла, но также и LIH, определяющий логический выходной интерфейс; обе величины записываются в состояние прохода. Сообщение Resv, пребывающее в адресуемый узел, несет в себе IP-адрес и LIH правильного выходного интерфейса, т.е., интерфейса, который должен получить запрошенное резервирование, вне зависимости от того, на какой интерфейс оно попало.

14. Модель ЭВМ

Прежде чем будет сформирована сессия, ей должен быть присвоен идентификатор (DestAddress, ProtocolId [, DstPort]), который рассылается всем отправителям и получателям. Когда RSVP сессия сформировалась, в оконечных системах должны произойти следующие события.

H1 Получатель посредством IGMP подключается к мультикаст-группе, заданной адресом DestAddress.
H2 Потенциальный отправитель начинает посылать сообщения Path по адресу DestAddress.
H3 Приложение получателя принимает сообщение Path.
H4 Получатель начинает посылать соответствующие сообщения Resv, задавая дескрипторы нужных потоков.
H5 Приложение отправителя получает сообщение Resv.
H6 Отправитель начинает посылать информационные пакеты.
Существует несколько соображений, касающихся синхронизации.

H1 и H2 могут произойти в любом порядке.



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

Предположим, что новый отправитель начинает рассылку сообщений Path (H2) и данных (H6) одновременно, и имеется некоторое число получателей, но сообщения Resv пока не достигли отправителя (напр., потому что его сообщения Path еще не дошли до получателей). Тогда исходные данные могут прийти к получателю без желаемого уровня QoS. Отправитель может немного облегчить эту проблему, подождав прибытия первого сообщения Resv (H5). Однако получатели, которые достаточно далеко, могут еще не получить необходимого резервирования.

Если получатель начинает посылать сообщения Resv (H4) до получения какого-либо сообщения Path (H3), RSVP пришлет получателю сообщение об ошибке.

Получатель может просто игнорировать такие сообщения об ошибке или он может избежать их, ожидая сообщений, прежде чем посылать сообщения Resv. Программный интерфейс приложения (API) для RSVP в данной спецификации не определен, так как он может зависеть от ЭВМ и ОС.

15. Функциональная спецификация RSVP

15.1. Формат сообщений RSVP

Сообщение RSVP состоит из общего заголовка, за которым следует тело сообщения, состоящее из переменного числа объектов переменной длины. Для каждого типа сообщения RSVP, существует набор правил допустимого выбора типов объектов. Эти правила специфицированы с использованием стандартных форм Бакуса-Наура (BNF), дополняемых опционными субпоследовательностями, которые помещаются в квадратные скобки. Объекты следуют в определенном порядке. Однако, во многих случаях (но не во всех), порядок объектов не играет роли. Приложение должно создавать сообщения с порядком объектов, предлагаемом в данном документе. Но оно должно быть способно воспринимать объекты в любом порядке.

16. Общий заголовок




Объекты as-set



Рисунок .10. Объекты as-set.

Атрибут mbrs-by-ref представляет собой список имен администраторов (maintainer) или ключевое слово ANY. Если используется этот атрибут, набор AS включает также автономные системы, чьи объекты aut-num зарегистрированы одним из этих администраторов и чей атрибут member-of относится к имени этого набора AS. Если значение атрибута mbrs-by-ref равно ANY, любой объект AS, относящийся к набору, является членом этого набора. Если атрибут mbrs-by-ref пропущен, только AS, перечисленные в атрибуте members, являются членами набора.

as-set: as-foo

members: AS1, AS2

mbrs-by-ref: MNTR-ME

Aut-num: AS3

Aut-num: AS4

member-of: as-foo

member-of: as-foo

mnt-by: MNTR-ME

mnt-by: MNTR-OTHER



Рисунок .11. Объекты as-set.

На Рисунок .11 представлен пример объекта as-set, который использует атрибут mbrs-by-ref. Набор set as-foo

содержит AS1, AS2 и AS3. AS4 не является членом набора as-foo не смотря на то, что объект aut-num ссылается на as-foo. Это происходит потому, что MNTR-OTHER отсутствует в списке атрибута as-foo mbrs-by-ref.

5.2. Класс route-set

Атрибуты класса route-set показаны на Рисунок .12. Атрибут route-set определяет имя набора. Он является именем RPSL, которое начинается с "rs-". Атрибут members перечисляет членов набора. Атрибут members представляет собой список адресных префиксов или других имен route-set. Заметим, что, класс route-set является набором префиксов маршрутов, а не маршрутных объектов RPSL.

Атрибут

Значение

Тип

route-set

<object-name>

обязательный, однозначный, ключ класса

members

список <address-prefix-range> или <route-set-name> или <route-set-name><range-operator>

опционный, многозначный

Mbrs-by-ref

список <mntner-names>

опционный, многозначный



Объекты filter-set



Рисунок .17. Объекты filter-set.

Атрибут filter определяет фильтр политики для данного набора. Фильтр политики является логическим выражением, которое в случае приложения к набору маршрутов в качестве результата возвращает субнабор этих маршрутов. Считается, что фильтр политики соответствует возвращенному субнабору. Фильтр политики может соответствовать маршрутам, использующим любой атрибут BGP-прохода, такой как адресный префикс места назначения (или NLRI), AS-path, или атрибуты community.

Фильтры политики могут составляться путем использования операторов AND, OR и NOT. Ниже представленные фильтры политики могут использоваться для селекции субнабора маршрутов:

ANY

Ключевое слово ANY соответствует всем маршрутам.

Address-Prefix Set

Это список адресных префиксов, заключенных в фигурные скобки '{' и '}'. Фильтр политики соответствует набору маршрутов, чей адресный префикс места назначения содержится в этом наборе. Например:

{ 0.0.0.0/0 }

{ 128.9.0.0/16, 128.8.0.0/16, 128.7.128.0/17, 5.0.0.0/8 }

{ }

За адресным префиксом может опционно следовать оператор диапазона (то есть

{ 5.0.0.0/8^+, 128.9.0.0/16^-, 30.0.0.0/8^16, 30.0.0.0/8^24-32 }

содержит все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8, все префиксы больше 128.9.0.0/16, исключая 128.9.0.0/16, все префиксы больше 30.0.0.0/8, которые имеют длину 16, такие как 30.9.0.0/16, и все префиксы больше 30.0.0.0/8, которые имеют длину в диапазоне 24 – 32, такие как 30.9.9.96/28.

Route Set Name

Имя набора маршрутов соответствует набору маршрутов, которые являются членами набора. Имя набора маршрутов может быть именем объекта route-set, номером AS или именем объекта as-set (номера AS и имена as-set неявно определяют маршрутные наборы). Например:

aut-num: AS1

import: from AS2 accept AS2

import: from AS2 accept AS-FOO

import: from AS2 accept RS-FOO

Ключевое слово PeerAS может использоваться вместо номера AS партнера. PeerAS является особенно полезным, когда партнерство охарактеризовано с помощью AS-выражения.
Например:

as-set: AS-FOO

members: AS2, AS3

aut-num: AS1

import: from AS-FOO accept PeerAS

то же самое, что и:

aut-num: AS1

import: from AS2 accept AS2

import: from AS3 accept AS3

За именем набора маршрутов может также следовать один из операторов '^-', '^+', например, { 5.0.0.0/8, 6.0.0.0/8 }^+ эквивалентно { 5.0.0.0/8^+, 6.0.0.0/8^+ } и AS1^- эквивалентно всем адресным префиксам, соответствующим маршрутам, исходящим из AS1.



Регулярные выражения для проходов AS.

Регулярное выражение AS-path может использоваться в качестве фильтра политики путем заключения его в угловые скобки `'. Фильтр политики AS-path соответствует набору маршрутов, который проходит через последовательность AS, которая согласуется с регулярным выражением AS-path. Маршрутизатор может проверить это, используя атрибут AS_PATH в протоколе BGP [19], или атрибут RD_PATH в протоколе IDRP [18].

Регулярное выражение формируется следующим образом:



ASN
где ASN является номером AS. ASN соответствует AS-path, который имеет длину равную 1 и содержит корректный номер AS (например, регулярное выражение AS-path AS1 соответствует AS-path "1"). Вместо номера AS-партнера может использоваться ключевое слово PeerAS.
AS-set где AS-set является именем набора AS. AS-set соответствует AS-проходам, которые согласуются с одним из AS в AS-set.
. соответствует AS-path, который согласуется с любым номером AS.
[...] является набором номеров AS. Это выражение соответствует AS-path, согласующимся со списком номеров AS, записанных в скобках. Номера AS в наборе отделяются друг от друга пробелом или символом TAB (white space). Если между двумя номерами AS использован символ `-', в набор включаются все AS из этого диапазона. Если в список включено имя as-set, в набор войдут все номера AS as-set.
[^...] является дополнением набора AS. Это выражение соответствует любому AS-path, который не соответствует набору номеров AS из приведенного набора.
^ Соответствует пустой строке в начале AS-path.
$ Соответствует пустой строке в конце AS-path.
<


/p> Далее описываются операторы регулярных выражений. Эти операторы выполняются слева направо.



Унарные постфиксные операторы * + ? {m} {m,n} {m,}



Для регулярных выражений A, запись A* соответствует нулю или более использований A. A+ соответствует одному или более использованию A. A? соответствует нулю или одному использованию A. A{m} соответствует m использованиям A. A{m,n} соответствует от m до n использованиям A/, A{m,} соответствует m или более использованиям A. Например, [AS1 AS2]{2} соответствует AS1 AS1, AS1 AS2, AS2 AS1 и AS2 AS2.



Унарные постфиксные операторы ~* ~+ ~{m} ~{m,n} ~{m,}



Эти операторы имеют аналогичную функциональность, что и соответствующие операторы, перечисленные выше, но все включения регулярного выражения должны соответствовать одному образцу. Например, [AS1 AS2]~{2} соответствует AS1 AS1 и AS2 AS2, но не соответствует AS1 AS2 и AS2 AS1.



Двоичный оператор объединения.

Это неявный оператор, он вставляется между двумя регулярными выражениями A и B, когда не специфицирован другой оператор. Полученное выражение A B соответствует AS-path, если A соответствует некоторому префиксу AS-path, а B соответствует остальной части AS-path.



Двоичный альтернативный оператор |



Для регулярных выражений A и B, A | B соответствует любому AS-path, который соответствует A или B.

Для изменения порядка действий, предусмотренного по умолчанию, можно использовать скобки. Для улучшения читаемости могут использоваться WS (пробел или символ TAB). Ниже приведены примеры фильтров AS-path:

<^AS1>

<^AS1 AS2 AS3$>

<^AS1 .* AS2$>.

Первый пример соответствует любому маршруту, чей AS-path содержит AS3, второй соответствует маршрутам, чьи AS-path начинаются с AS1, третий соответствует маршрутам, чьи AS-path заканчиваются AS2, четвертый соответствует маршрутам, чьи AS-path в точности равны "1 2 3", а пятый соответствует маршрутам, чьи AS-path начинаются в AS1 и заканчиваются в AS2 с любым числом промежуточных AS между ними.



Составные фильтры политики.



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

NOT Дан фильтр политики x, NOT x соответствует набору маршрутов, которые не соответствуют x. Таким образом он представляет отрицание фильтра политики x.
AND Даны два фильтра политики x и y, x AND y соответствует пересечению множеств маршрутов, которые соответствуют как фильтру x так и фильтру y.
OR Даны два фильтра политики x и y, x OR y соответствует объединению множеств маршрутов, которые соответствуют фильтру x или фильтру y. Заметим, что оператор OR может быть неявным, то есть `x y' эквивалентно `x OR y'. Например
NOT {128.9.0.0/16, 128.8.0.0/16}

AS226 AS227 OR AS228

AS226 AND NOT {128.9.0.0/16}

AS226 AND {0.0.0.0/0^0-18}

Первый пример соответствует любому маршруту кроме 128.9.0.0/16 и 128.8.0.0/16. Второй пример соответствует маршрутам AS226, AS227 и AS228. Третий пример соответствует маршрутам AS226, исключая 128.9.0.0/16. Четвертый пример соответствует маршрутам AS226, чья длина не больше 18.

Атрибуты фильтров политики могут использоваться для сравнения значения других атрибутов. Атрибуты, чьи значения могут применяться в фильтрах политики, специфицированы в словаре RPSL. Пример использования атрибута BGP community приведен ниже:

aut-num: AS1

export: to AS2 announce AS1 AND NOT community(NO_EXPORT)

Фильтры, использующие атрибуты маршрутной политики, определенные в словаре, вычисляются до выполнения операторов AND, OR и NOT.



Имя набора фильтров.
Имя набора фильтров отвечает набору маршрутов, которые соответствуют их атрибуту фильтра. Заметим, что атрибут фильтра набора может рекурсивно связан с другими именами наборов фильтров. Например на Рисунок .17, fltr-foo соответствует {5.0.0.0/8, 6.0.0.0/8} и fltr-bar соответствует маршрутам AS1 или { 5.0.0.0/8, 6.0.0.0/8 }, если их путь содержит AS2.
5.5. Класс rtr-set



Атрибуты класса rtr-set представлены на Рисунок .18. Атрибут rtr-set определяет имя набора. Он является словом RPSL, которое начинается с "rtrs-".


Атрибут members перечисляет членов набора. Атрибут members представляет собой список имен inet-rtr, ipv4_addresses или других имен rtr-set.



Атрибут


Значение


Тип
rtr-set <object-name> обязательный, однозначный, ключ класса
members список <inet-rtr-names> или <rtr-set-names> или <ipv4_addresses> опционный, многозначный
mbrsbyref список <mntnernames> опционный, многозначный

Объекты inet-rtr



Рисунок .36. Объекты inet-rtr

Каждый атрибут peer, если он имеется, специфицирует протокольный пиринг с другим маршрутизатором. Значение атрибута peer имеет следующий синтаксис:

<protocol> <ipv4address>

<options>

| <protocol> <inet-rtr-name>

<options>

| <protocol> <rtr-set-name>

<options>

| <protocol> <peering-set-name>

<options>

где <protocol> - имя протокола, <ipv4-address> - IP-адрес маршрутизатора партнера, а <options> - список опций пиринга для <protocol>. Элементы списка разделяются запятыми. Вместо IP-адресов партнеров, может использоваться его inet-rtr-name. Допустимые имена протоколов и атрибуты определены в словаре (см. раздел 7). В выше приведенном примере, маршрутизатор имеет BGP-пиринг с маршрутизатором 192.87.45.195 в AS3334. Он включает подавление осцилляций маршрута, когда импортирует маршруты из этого маршрутизатора.

Вместо одиночного партнера с помощью форм <rtr-set-name> и <peering-set-name> может быть специфицирована группа партнеров. Если использована форма <peering-set- name>, то включаются только пиринги из соответствующего набора данного маршрутизатора. На Рисунок .37 показан пример объекта inet-rtr с пиринг-группами.

rtr-set: rtrs-ibgp-peers

members: 1.1.1.1, 2.2.2.2, 3.3.3.3

peering-set: prng-ebgp-peers

peering: AS3334 192.87.45.195

peering: AS3335 192.87.45.196

inet-rtr: Amsterdam.ripe.net

alias: amsterdam1.ripe.net

local-as: AS3333

ifaddr: 192.87.45.190 masklen 24

ifaddr: 192.87.4.28 masklen 24

ifaddr: 193.0.0.222 masklen 27

ifaddr: 193.0.0.158 masklen 27

peer: BGP4 rtrs-ibgp-peers asno(AS3333), flap_damp()

peer: BGP4 prng-ebgp-peers asno(PeerAS), flap_damp()



Объекты route-set



Рисунок .13. Объекты route-set

route-set: rs-bar

members: 5.0.0.0/8^+, 30.0.0.0/8^24-32, rs-foo^+

содержат все префиксы больше 5.0.0.0/8, включая 5.0.0.0/8, все префиксы больше 30.0.0.0/8, чья длина лежит в пределах 24 – 32, такие как 30.9.9.96/28, и все префиксы больше префиксов из маршрутного набора rs-foo.

Атрибут mbrs-by-ref представляет собой список имен администраторов и может содержать ключевое слово ANY. Если используется этот атрибут, маршрутный набор включает также префиксы, чьи маршрутные объекты зарегистрированы одним из администраторов, и чей атрибут member-of указывает на имя этого маршрутного набора. Если значение атрибута mbrs-by-ref равно ANY, любой объект, связанный с именем маршрутного набора, является его членом. Если атрибут mbrs-by-ref отсутствует, только адресные префиксы, перечисленные в атрибуте members, являются членами этого набора.

route-set: rs-foo

mbrs-by-ref: MNTR-ME, MNTR-YOU

route-set: rs-bar

members: 128.7.0.0/16

mbrs-by-ref: MNTR-YOU

route: 128.9.0.0/16

origin: AS1

member-of: rs-foo

mnt-by: MNTR-ME

route: 128.8.0.0/16

origin: AS2

member-of: rs-foo, rs-bar

mnt-by: MNTR-YOU



Рисунок .14. Объекты route-set.

На Рисунок 14 представлен пример объектов route-set, которые используют атрибут mbrs-by-ref. Набор rs-foo содержит два адресных префикса, в частности 128.8.0.0/16 и 128.9.0.0/16, так как маршрутные объекты для 128.8.0.0/16 и 128.9.0.0/16 отнесены к набору имен rs-foo в их атрибуте member-of. Набор rs-bar содержит адресные префиксы 128.7.0.0/16 и 128.8.0.0/16. Маршрут 128.7.0.0/16 представлен явно в атрибуте members rs-bar, а маршрутный объект для 128.8.0.0/16 связан с именем набора rs-bar в атрибуте member-of. Заметим, что если адресный префикс представлен в атрибуте маршрутного набора members, он является членом этого маршрутного набора. Маршрутный объект, соответствующий этому адресному префиксу не должен содержать атрибут member-of, относящийся к имени этого набора. Атрибут маршрутного класса member-of является дополнительным механизмом для косвенной спецификации членов набора.

5.3. Объекты предопределенных наборов

В этом контексте, который предполагает набор маршрутов (например, атрибут members класса route-set), номер автономной системы ASx определяет набор маршрутов, который исходит из Asx, а as-set AS-X определяет набор маршрутов, которые исходят из автономной системы AS-X. Маршрут p считается начинающимся в ASx, если существует маршрутный объект для p с ASx в качестве значения атрибута origin. Например, на Рисунок .15, набор маршрутов rs-special содержит маршруты 128.9.0.0/16, AS1 и AS2, а также маршруты автономных систем набора AS-FOO.

route-set: rs-special

members: 128.9.0.0/16, AS1, AS2, AS-FOO



Объекты rtr-set



Рисунок .19. Объекты rtr-set.

Атрибут mbrs-by-ref содержит список имен администраторов (maintainer) или ключевое слово ANY. Если использован этот атрибут, набор маршрутизаторов включает также маршрутизаторы, чьи объекты inet-rtr зарегистрированы одним из этих администраторов и чей атрибут member-of согласуется с именем этого набора маршрутизаторов. Если значение атрибута mbrs-by-ref равно ANY, любой объект inet-rtr соотносящийся набору маршрутизаторов, является членом этого набора. Если атрибут mbrs-by-ref отсутствует, только маршрутизаторы перечисленные в атрибуте members, являются членами набора.

rtr-set: rtrs-foo

members: rtr1.isp.net, rtr2.isp.net

mbrs-by-ref: MNTR-ME

inet-rtr: rtr3.isp.net

local-as: as1

ifaddr: 1.1.1.1 masklen 30

member-of: rtrs-foo

mnt-by: MNTR-ME



Рисунок .20. Объекты rtr-set.

На Рисунок 20 представлен пример объекта rtr-set, который использует атрибут mbrs-by-ref. Набор rtrs-foo содержит rtr1.isp.net, rtr2.isp.net и rtr3.isp.net.

5.6. Партнерство и класс peering-set

Атрибуты класса peering-set представлены на Рисунок .21. Объект peering-set определяет набор партнеров, который перечислен в его партнерских атрибутах (peering). Атрибут peering-set определяет имя набора. Он является именем RPSL, которое начинается с "prng-".

Атрибут

Значение

Тип

peering-set

<object-name>

обязательный, однозначный, ключ класса

peering

<peering>

обязательный, многозначный



Объекты SCOPE при резервировании в стиле WF



Рисунок 4.4.9.6.10. Объекты SCOPE при резервировании в стиле WF

Объекты SCOPE не являются необходимыми, если мультикастинг-маршрутизация использует совместные деревья или если стиль резервирования предполагает явный выбор отправителей. При использовании объектов SCOPE в сообщениях ResvErr стиля WF следует придерживаться следующих правил:

Узел, который обнаружил ошибку, отправляет сообщение ResvErr, содержащее копию объекта SCOPE, соответствующего состоянию резервирования или сообщению, которое вызвало ошибку.

Предположим, что узлом получено сообщение ResvErr с произвольным указанием отправителей (wildcard), содержащее объект SCOPE со списком адресов отправителей L. Сообщение ResvErr, переадресованное интерфейсу OI должно содержать объект SCOPE, извлеченный из L и включающий только те адреса отправителей, которые маршрутизированы на OI. Если этот объект SCOPE пуст, сообщение ResvErr не должно посылаться OI.

28. Состояние блокады

Основным правилом при формировании сообщения обновления Resv является объединение спецификаций flowspecs резервирования в узле посредством вычисления их LUB (наименьший верхний предел). Однако это правило модифицируется при наличии "состояния блокады", возникшего из-за сообщений ResvErr при решении проблемы KR-II.

Когда получено сообщение ResvErr, его спецификация flowspec Qe используется для формирования или обновления элемента местного состояния блокады. Каждый элемент состояния блокады состоит из спецификации flowspec Qb, взятой из спецификации сообщения ResvErr и соответствующего таймера блокады Tb. Когда время таймера блокады истекает, соответствующее состояние блокады аннулируется.

Гранулярность состояния блокады зависит от стиля сообщения ResvErr, которое явилось ее причиной. Каждому конкретному стилю может соответствовать свой элемент состояния блокады (Qb(S),Tb(S)), где S - отправитель. Для произвольного стиля выбора отправителя состояние блокады определяется предыдущим узлом P.

Элемент состояния блокады со спецификацией flowspec Qb называется блокадой резервирования со спецификацией flowspec Qi, если Qb не больше чем Qi.
Например, предположим, что LUB ( least upper bound) двух спецификаций flowspecs было вычислено путем выбора максимума составляющих их компонент. Тогда Qb блокирует Qi, если для некоторой компоненты j, Qb[j] ? Qi[j].

Предположим, что узел получает сообщение ResvErr от предыдущего узла P (или, если стиль выбора отправителя S является явным) в результате ошибки доступа. Тогда:

Для P (или S) создается элемент состояния блокады, если он не существует.

Qb(P) (или Qb(S)) делается равным flowspec Qe из сообщения ResvErr.

Запускается (или перезапускается) соответствующий таймер блокады Tb(P) (или Tb(S)) на время Kb*R. Здесь Kb является фиксированным множителем, а R равно интервалу времени обновления состояния резервирования. Kb можно варьировать.

Если имеется локальное состояние резервирования, которое не заблокировано, немедленно генерируется обновление резервирования для P (или S).

Сообщение ResvErr переадресуется последующим узлам. Если бит InPlace=0, сообщение ResvErr направляется всем последующим узлам, где имеется состояние резервирования. Если бит InPlace=1, сообщение ResvErr направляется только следующим узлам, чьи Qi блокированы спецификацией Qb.

В результате предлагается модифицированное правило для объединения спецификаций flowspecs при формировании сообщения обновления резервирования.

Если имеются какие-либо локальные запросы резервирования Qi, которые не заблокированы, они объединяются путем вычисления их LUB. Заблокированные резервирования игнорируются. Это позволяет требовать меньшее резервирование, которое имеет шанс на успех, после того как большее резервирование не удалось.

В противоположном случае (все локальные запросы Qi блокированы), они объединяются путем взятия GLB (Greatest Lower Bound) спецификаций Qi.

Этот алгоритм объединения обновления применяется отдельно для каждого потока (каждого отправителя или PHOP), вносящего вклад в общее резервирование (стили WF или SE).

На Рисунок 4.4.9.6.11 приведен пример использования состояния блокады для совместного резервирования (стиль WF).Имеется два предшествующих узла, помеченных как (a) и (b), и два последующих узла, помеченных как (c) и (d). Большее резервирование 4B пришло сначала от (c), но "застряло" где-то до PHOP (a), а не по пути через PHOP (b).


Операторы



Рисунок .25. Операторы

Атрибут rp-attribute может иметь много методов, определенных для него. Некоторые из методов могут даже иметь то же самое имя, в этом случае их аргументы должны относиться к другому типу. Если список аргументов завершается "...", метод может воспринять переменное число аргументов. В этом случае, действительные аргументы после N-го аргумента имеют тип <type-N>.

Аргумента строго типофицированы. <type> в RPSL является либо предопределенным, типом union, списочным, либо определенным в словаре. Предопределенные типы перечислены на Рисунок .26.

integer[lower, upper]

ipv4_address

real[lower, upper]

address_prefix

enum[name, name, ...]

address_prefix_range

string

dns_name

Boolean

filter

rpsl_word

as_set_name

free_text

route_set_name

email

rtr_set_name

as_number

filter_set_name

 

peering_set_name



Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"



11 Отзывы и вопросы в связи с сервером "Телекоммуникационные технологии"

Этот сервер официально зарегистрирован на Rambler лишь в марте 2002 года, но существует он уже с конца 1999 года. Отклики интересны, прежде всего, тем, что они написаны по инициативе отправителя. Я полагаю, что многие из читателей время от времени просматривают самые разные сайты в Интернет. Но вряд ли многие пишут на них отклики...

Я сознательно исключил переписку, возникавшую в связи с присланными запросами. Не все отклики попали в перечень (я получаю большой объем СПАМа и часто слишком поспешно уничтожаю сообщения от незнакомых лиц). Признаюсь, я не всегда отвечаю на приходящие письма, так как их число превышает 50 в день… География откликов довольно широка (Владивосток, Новосибирск, Иркутск, С-Петербург, Ижевск, Саратов, Ноябрьск, Луганск, Тихорецк, Киев, Эстония, США, Болгария и, конечно же, Москва). В основном они положительны (может быть отчасти потому, что авторы о чем-то просят J). Но был один явно отрицательный отклик, он также включен в перечень. Было несколько запросов относительно off-line версии сервера. Отвечая на них, скажу, что я планирую изготовить CD-версию сервера, но дело это хлопотное и экономически совершенно нерациональное. Обычно в такой версии нуждаются люди с плохим доступом к Интернет (как правило не москвичи), себестоимость такого CD около 2$, плюс цена пересылки, назначить цену, которая бы компенсировала трудозатраты я не могу, да и люди не смогут ее заплатить, а рассылать диски с убытком не позволяет моя зарплата.

Отклики размещены в хронологическом порядке, со временем надеюсь создать “нормальную” книгу посещений-отзывов.

From: Andrey Cherezov andrey@cherezov.koenig.su

To: semenov@ns.itep.ru

Subject: О ваших Книгах

Date: 2 августа 1998 г. 22:15

Добрый день!

Неужели Вы тот самый Ю.А.Семенов, который книгу о Форте написал?! J

Очень рад, что теперь можно с вами поговорить!

Всего наилучшего, Андрей Черезов http://www.enet.ru/win/cherezov/

Date: Sat, 27 Mar 1999 20:38:37

Уважаемый господин Cеменов!

Oглавление, перечисляющее разделы вашего сайта "Cети Интернет", просто потрясающее. Но по каким-то причинам Я не могу открыть большинство страниц. Если они (страницы :-) уже созданы, то хотелось бы, чтоб проблемы, связанные с этим (причинами :-( , поскорее были преодолены.

C уважением,

Bаш потенциальный постоянный посетитель

Aлександр <lommoff@yahoo.com>

Date: Mon, 6 Mar 2000 03:56:49

Восхищен и поражен Вашим сайтом Telecommunication technologies - телекоммуникационные технологии. Творческих успехов и всего хорошего.

Egor Kobylkin egork@iname.com http://i.am/egork

Date: Thu, 1 Jun 2000 13:47:11

Уважаемый Юрий Алексеевич!

С удовольствием прочитал в Интернет Вашу книгу "Сети Интернет..." Благодарю за бесплатное размещение этой очень полезной книги в сети. Пользуясь случаем, прошу оказать помощь в приобретении полного текста. Рекомендаций МСЭ-Т G.703 (Копия, оригинал или адрес в сети). Посоветуйте где это можно найти.

С уважением

Ведущий специалист ЗАО"АКОС" (Сотовая связь. г. Владивосток)

Сергей Гречуха

мой адрес: sgrechuha@akos.ru

Date: Wed, 14 Jun 2000 16:25:45

Добрый день, Юрий Алексеевич.

Я студент МФТИ ФРТК 4-й курс, пишу вам по поводу вашей книги Телекоммуникационные Технологии (http://book.itep.ru). В данный момент занимаюсь моделированием локальных сетей на языке GPSS/PC. В частности, моделирую Ethernet 802.3 коллизийный домен. Я нашел некоторые неоднозначности в разной литературе описывающие протокол CSMA/CD.

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

1. Станция все время прослушивает среду (шину). Если среда свободна (освободилась), то ждет interframe gap

(межкадровый интервал), равный 9,6 мкс (в это время все равно слушает среду). Если в течение этих 9,6 мкс никто не захватил шину, то начинает передавать (шаг 2.). Если кто-то захватил шину в течение этого времени, то возвращается к шагу 1.

2. При передачи, станция все время слушает среду. Если обнаруживает коллизию, то посылает сигнал коллизии 32 BT = 3.2 мкс. И вычисляет задержку по формуле (51,2*(RAND [0,(2^m-1)]), где m = min (к,10), а к - число коллизий, при передачи данного кадра. То есть, если к=1, то возможная задержка (0, 51.2) если к=2, то возможная задержка (0, 51.2, 102.4, 52428.8), и т.д. После ожидания вычисленной задержки, возвращается к шагу 1. Если к=16, станция отказывается отправлять кадры. (Кстати, у Вас задержка вычисляется по формуле (51,2*(RAND [0,(2^m)]))

3.Если коллизии не было, то завершает передачу. Устанавливает к = 0. Возвращается к шагу 1. Я моделирую насыщенный режим работы сегмента и почему-то одна станция захватывает весь эфир. Модель работает к предписано алгоритмом выше. Попробовал аналитически рассмотреть работу >CSMA/CD. Допустим все станции (3 штуки) захотели передавать в одно и тоже время, определив, что шина свободна. Обнаружится коллизия, все станции идут в задержку. прибавляя к 'К' единицу. Далее, кто первее освободился (если задержка 0, то сразу идет к шагу 1), тот начал передачу. Во время передачи этой станции освобождаются, другие станции из коллизийной задержки. Соответственно ждут, пока освободит шину передающая станция (шаг 1). Как только эта станция освобождает шину, она идет в шаг 1. (причем 'к' сбрасывает в нуль) на ровне с другими станциями. Ждут 96 ВТ = 9.6 мкс межкадрового времени, начинают передавать. Опять образуется коллизия. У первой станции 'к' будет равно единицы, а у других 'к'=2. Это говорит о том, что вероятность получить меньшую задержки у первой станции больше чем у других. (у меня так и происходит). станция с к=1 выбирает меньшую задержку, чем другие. Ждет и идет передавать. Далее все идет по циклу, у первой станции 'к' то обнуляется, то равно 1, у других станций 'к' растет, соответственно, вероятность получить большую задержку тоже растет. Я моделировал передачу кадров минимальной длины, что уж говорить о кадров максим. длины 1526КВ. Ситуация на мой взгляд еще больше усугубится. Юрий Алексеевич, подскажите, может быть я не правильно понял алгоритм? Он несколько отличается от Вашего (http://book.itep.ru/4/41/Eth_4111.htm), но мне кажется не принципиально.

Всего доброго, Рябенко Максим maxy@rt.mipt.ru

Date: Wed, 12 Jul 2000 16:45:27

Уважаемый Юрий Алексеевич

В своей книге "Сети Интернет. Архитектура и протоколы", Вы пишите о том, что Вы написали собственную программу для анализа сетевого трафика, и в частности эта программа анализирует содержимое MIB. Меня интересует такой вопрос: как в Вашей программе реализован поиск SNMP-агентов, и можно ли организовать его автоматически?

С уважением, Юрий Чашков. chashkov@mail.ru

Date: Fri, 4 Aug 2000 15:32:33

Здравствуйте.

В Вашей книге (http://book.itep.ru/7/Prog_72.htm)

читаю:

"...(см. также руководство по сетевому контроллеру 8390 и файл NE2.ASM из ссылки ftp.funet.fi)..." Не могли бы Вы уточнить, действительно ли существует описание 8390 в Интернете и как его выловить? (очень надо для отладки драйвера под RTEMS)

Спасибо.

Sincerely, Dmitry Kargapolov, ICQ 54000305, dk@gentex.ru

Date: Tue, 15 Aug 2000 05:16:31

Доброго времени суток Юрий Алексеевич.

Попал на Ваш сайт, и был приятно удивлен количеству полезной информации. Но к сожалению, я не имею постоянной возможности работы в Интернете. И меня интересует, такая возможность, как получить Ваш сайт в виде архива. Для ЛИЧНОГО использования. По некоторым статьям я считаю, что мог бы несколько дополнить их. Но, к сожалению, по причине описанной выше не могу внимательно ознакомится с теми разделами, в которых у меня имеется богатый практический опыт. Рад буду, если Вы откликнитесь на мою просьбу. А также надеюсь на плодотворное сотрудничество.

Заранее спасибо.

С уважением Алексей Алексеевич. mailto:wwfnet@mail.ru

Date: Thu, 31 Aug 2000 12:49:28

Уважаемый Юрий Алексеевич!

Сердечно благодарю Вас за отклик на нашу просьбу. Надеюсь, что Вы сможете, что-нибудь придумать. Информацию о сфере нашей деятельности, заказчиках и др. Вы сможете посмотреть на нашем сайте. Очень горжусь, пусть телефонным, знакомством с Вами и надеюсь, что смогу быть Вам полезным. С Уважением и наилучшими пожеланиями, исполнительный директор НПФ Беркут

Кельганкин Олег

ook@bercut.spb.ru

www.bercut.ru

т/ф (812) 271-48-98

т/ф (812) 274-70-59

т/ф (812) 275-44-91

Россия, Санкт-Петербург, Моисеенко 43.

Date: Thu, 31 Aug 2000 13:48:14

Здравствуйте Юpий Алексеевич!

Ну для начала я представлюсь. Корнилов Игорь Геннадьевич, 25 лет. Работаю ставшим преподавателем на кафедре ВТ ИжГТУ (Ижевский гос. тех. университет). С прошлого года я читаю курсы по корпоративным сетям и Интернету. В подготовке к лекциям в прошлом году мне сильно помогала Ваша книга "Протоколы и ресурсы INTERNET". Позже я стал пользоваться сервером book.itep.ru. Замечательный, полезный сервер! Спасибо Вам огромное>! Но у нас есть одна проблема! Канал через который подключен к инету наш университет не отличается высокой скоростью и надежностью. :( А я бы хотел, чтоб ресурсами вашего сервера могли свободно пользоваться наши студенты. И в связи с этим вопрос: можно ли разместить зеркало вашего сервера на сервере нашей кафедры?

С уважением, Корнилов Игорь. eggog@vao.udmnet.ru

Date: Mon, 04 Sep 2000 10:59:47

Добpый день, Юpий Алексеевич

Зеркало уже почти готово! Скоро я его размещу на нашем сервере zuko.istu.udm.ru. У меня уже есть старая копия, которой я пользовался. Hо из миpа в настоящее время его видно не будет (проблемы с внешними каналами :((( Как только появится возможность доступа к нам из вне я Вам сообщу дополнительно. И вот тут еще. Меня заинтересовало ваше сообщении о новой книге, хотелось бы уточнить, когда она выходит и как ее можно будет заказать (а то тут у нас сложно с ХОРОШЕЙ литературой в магазинах :))) )? eggog@vao.udmnet.ru

С уважением? Игорь Корнилов.

Date: Mon, 4 Sep 2000 18:34:03

Здравствуйте, Юрий Алексеевич!

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

Спасибо Вам за то, что Вы делаете!

С уважением, Артем Глазунов, специалист Иркутского областного телеграфа.

e-mail: gav@irtel.ru

From: "Lex" <3694_KAN@nw.ie.tasur.edu.ru>

Organization: Industrial Electronics of TASCR

To: <semenov@itep.ru>

Date: Mon, 2 Oct 2000 19:40:23

В вашей книге "Протоколы Интернет" описан обработчик приема пакетов для пакетных драйверов receiver - он описан как процедура near а как сделать чтобы этот обработчик обращался к данным прикладной программы, например вставка в receiver строк типа

mov> ah,09h

lea dx,string

int 21h

Где string описана в данных прикладной программы приводит к выводу всякой ваты на экран и зависанию компа при обращении драйвера к receiverу причем $ на конце stringa не забыл указать и относительно другого сегмента пробовал (com программа) cs:[string] все равно Вы моя последняя надежда...

Date: Wed, 01 Nov 2000 11:53:59

Subject: Огромное СПАСИБО за то, что Вы есть!

У меня к Вам убедительная просьба отправить мне ответы на закрепляющие вопросы к теме "Каналы передачи данных" (http://book.itep.ru/) Я хотел бы проверить свои знания в этой области.

С уважением, Колот Сергей <kolot@mail.ru>

Date: Mon, 18 Dec 2000 00:49:29

Глубокоуважаемый Юрий Алексеевич!

Я хотел бы попросить Вас исправить русскоязычное написание имени и фамилии Michael Burrows'a -- одного из авторов WBT ("Burrows-Wheeler Transformation", also known as " Block Sorting"); его зовут Майкл Барроуз. Так получилось, что я работал в Великобритании и знаком с ним.

Спасибо, Андрей Кадач akadatch@microsoft.com

Здравствуйте,

Позвольте поблагодарить Вас, за тот труд, который Вы вложили в создание http://book.itep.ru/, он помог мне заполнить те пробелы в моих знаниях, которые долгое время не давали мне покоя. Спасибо.

Вы пишите:

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

> описания протоколов (конспективность здесь неизбежна) и представить необходимые

> справочные материалы...

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

Kirill V. Krinkin

mailto:krinkin@mailru.com

Brainbench Public Transcript: 173921,

http://www.brainbench.com/transcript.jsp?pid=173921

7 января 2001 г.

Date: Mon, 05 Feb 2001 16:44:31

Здравствуйте. Пишет вам Константин из города Луганска. Я ищу описание дельта кодака. К сожалению я не знаю его точного названия, но знаю что в данном протоколе используется метод адаптивной дельта модуляции, частота передачи 32 Кбит/сек, и на одну линию подсоединяется 8 цифровых т/а. Если описание подобного протокола в вашей книге?

e_mail: kos_k@inbox.ru

Thu, 15 Feb 2001 22:31:43

From: "I. F." <code@dir.bg>

To: <semenov@itep.ru>

Date: Thu, 15 Feb 2001 21:33:47

bravo bravo good book:

about <http://book.itep.ru/1/intro1.htm>

Date: Thu, 22 Feb 2001 17:40:26

Здравствуйте!

Я хотел бы узнать, где можно найти вашу книгу "Telecommunication technologies - телекоммуникационные технологии” в электронном виде.

Алексей В. Майоров МФТИ ФПМЭ. lexa@megasoft.ru

Date: Mon, 12 Mar 2001 18:25:34

Уважаемый Юрий Алексеевич, меня очень понравился сайт (<http://book.itep.ru/>)с вашими книгами. Я осваиваю программирование под Windows, с уклоном в сетевые технологии, и столкнулся с тем, что в Инете очень мало информации по этой теме, на русском языке, поэтому приходилось искать на буржуйских сайтах, но в силу слабости моих познаний английского, меня этот путь не совсем устраивает, и сегодня блуждая по поисковикам наткнулся на вашу главу , посвященную Сокетам, мне она очень понравилась, благодаря своему подробному описанию данного вопроса. Затем посмотрел на оглавление, мне понравилось еще больше, показал друзьям - программистам - они тоже оценили. По моему мнению, это лучшая книга по обработке информации, и сетевым технологиям (по крайней мере среди русскоязычных). Выражаю Вам огромную признательность от своего имени за проделанную колоссальную работу в области развития информационных технологий среди начинающих программистов(и профессиональных также):).

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

С уважением, Вячеслав Потапов, студент МИСиС. VPotapov@estra.ru

Date: Wed, 28 Mar 2001 14:52:42 +0400

From: "maks" <imv@ghost.dn.ua>

Пишет вам студентка Украинской Государственной Академии связи, мой преподаватель выдал мне диплом на тему "видеотелеконференции – как услуга центра документальной электросвязи ", сославшись на то что поискать информацию по этой теме можно в ваших книгах. Причем, какие конкретно книги он мне не сказал. Если вас не затруднит, напишите пожалуйста по этому адресу, какие книги на интересующую меня тему вы написали. Или, если можно и есть публикации в Интернете скиньте пару ссылок на них.

заранее благодарна!

Best regards,

Марина mailto:imv@ghost.dn.ua

From: "Digitman" <digitman@dax.ru>

To: <semenov@itep.ru>

Date: Tue, 3 Apr 2001 13:01:37

Добрый день, ув. Ю.А.!

С интересом проштудировал раздел "Сокеты" http://book.itep.ru

В наст. момент я занимаюсь разработкой пакета Делфи-компонентов, реализующих логику клиент-серверного взаимодействия не базе гнезд. Общая идея, подвигнувшая меня на разработку, заключалась в усовершенствовании базовых решений данных технологий, представленных в виде устойчивых классов TServerSocket и TSocketConnection, c учетом преимуществ технологий MIDAS и ASTA. Не могу утверждать об идеальном понимании мной в данный момент концепции гнезд TCP/IP, но стремление к совершенству результата требует того.

В связи с этим я столкнулся с малопонятой и малодокументированной проблемой, возникающей при использовании сокет-сервером логики установления коннекта с сокет-клиентом с использованием расширенной ф-ции WSAAccept() вместо стандартно применяемой в компонентах VCL Accept():

Я использую гнезда в режиме SOCK_STREAM. По специф-ции MS Winsock2 ф-ция> WSAAccept() должна позволять принимать/отвергать/откладывать вх запросы клиентских гнезд на установление коннекта. С этой целью в Проблемная ситуация состоит в следующем:

1. Если ConditionFunc() возвращает CF_REJECT (отвергнуть вх.запрос на соединение), то WSAAccept() работает правильно, возвращая INVALID_SOCKET, НО клиентский вызов connect(), запросивший соединение, завершается УСПЕШНО, сигнализируя об установлении соединения, ХОТЯ сервер ОТВЕРГ его!

2. Если ConditionFunc() возвращает CF_DEFER (отложить рассмотрение вх.запроса на соединение, не уничтожая его в очереди BackLog), то WSAAccept() работает правильно, возвращая INVALID_SOCKET, НО ТОЛЬКО при первом ее вызове. Повторные вызовы WSAAccept() (как правило, этот вызов - блокирующий и вложен в цикл в отдельном потоке) предполагают повторные проверки условий ф-цией ConditionFunc() для очеред.элемента из BackLog-очереди, которым может оказаться и только что отложенный запрос (!), НО почему-то вызова callback-функции проверки условий в этом случае не происходит !!!! Вместо этого WSAAccept() безусловно возвращает дескриптор нового сокета для вновь установленного соединения (а может, мне его снова нужно было бы отложить? или отвергнуть по каким-либо причинам ?).

САМОЕ ПЕЧАЛЬНОЕ, что при любом раскладе клиентское гнездо СРАЗУ ЖЕ получает подтверждение постановки запроса со стороны "слушающего" серверного гнезда, если сервер вовремя вызвал Listen() и параметры (IP-адрес и порт) кл.гнезда указаны корректно, хотя в этот момент сервер еще не принял решения об акцепте запроса !!!!! Т.е., подтверждение сервером получения клиентского запроса на установление соединения выглядит на клиентской стороне как реальный (а не виртуальный) коннект, и клиент может развернуть последовательность зависимых от успешного коннекта действий (например, начать формирование буфера передачи), не подозревая, что через доли секунды произойдет дисконнект, связанный с отвержением запроса.

Где здесь"зарыта собака" ?

Можно ли обойти проблему и каким образом ?

Слышал, что MS намеренно реализовал такую логику с целью, якобы, минимизации времени на установление коннекта. Но - жесткая ли она, эта логика ? Как ее обойти, возможно, заданием спец. опций TCP-протокола (или QOS) ?? Можно ли найти более-менее понятные и надежные примеры реализации "верной по сути" логики ? (неважно, на чем сверстанные). Есть ли в сети сайты/форумы, посвященные данным проблемам, желательно, в Рунете? Заранее признателен Вам за внимание. Надеюсь на любую помощь в возникших у меня вопросах с учетом Вашей компетенции.

Date: Mon, 9 Apr 2001 13:41:42

Уважаемый госп. Семенов!

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

Наталья Лыкова. <market@atlant-inform.ru>

From: "Shefanovski Dennis" <shefanovski@infosec.ru>

To: <semenov@itep.ru>

Date: Tue, 3 Apr 2001 06:20:34

Посмотрел и стало грустно...

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

Так нельзя.

PS Я прекрасно понимаю, что все охватить невозможно, но все же

Best regards! DennisShefanovski <shefanovski@infosec.ru>

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

Date: Fri, 20 Apr 2001 16:46:44

Уважаемый Юрий Алексеевич, внимательно прочел материалы, размещенные Вами на сервере http://book.itep.ru/ под общим названием Telecommunication technologies - телекоммуникационные технологии.

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

С уважением, Дмитрий <meditech@spb.cityline.ru>

Date: Wed, 16 May 2001 04:04:29

Добрый день, уважаемый Семенов Ю.А.

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

телекоммуникаций, но по работе срочно необходимо написать программу

демодуляции фазоманипулированных сигналов PSK, BPSK, QPSK (источник - звук, принимаемый SoundBlasterom).

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

Заранее крайне Вам признателен.

Александр. <VORONUK@APORT.RU>

Date: Sat, 2 Jun 2001 15:38:00

Добрый день.

Заходил к Вам на сайт, узнал о кафедре "Телекоммуникационные сети и системы". Подскажите? пожалуйста, есть ли у Вас дистанционная, либо заочная форма обучения и каким специальностям у Вас обучают.

С уважением, Анфёров Евгений

Инженер ЭВМ ООО "СК Мост"

676850, г. Белогорск ул. Кирова 279 "Б"

E-Mail: jon@most.com.ru

ICQ# 23629387

www.skmost.ru

Date: Mon, 11 Jun 2001 10:54:20

Добрый день!

У меня к вам большая просьба!

Мне срочно нужна информация по написанию драйверов для сетевого адаптера под MS-DOS (для диплома). Подскажите pls, где можно ее найти. (мои поиски пока ни к чему не приводят, кроме вашей статьи "Программирование при работе с TCP/IP пакетами"). Заранее благодарен,

Александр <phoenix@aib.ru>

P.S. Нет так нет (буду искать)

From: "Alexandr Ivanov" <ivanov@kons.ru>

To: <semenov@itep.ru>

Здравствуйте, Юрий Алексеевич!

Сегодня случайно наткнулся в сети на Вашу книгу. Очень полезное и необходимое издание. Хочу просить Вашего разрешения на зеркалирование этого сайта... Я исключаю любое коммерческое использование. Хочу просто создать копию у себя на сервере и продвигать этот ресурс среди своих клиентов. Компания, в которой я работаю, является крупнейшей телекоммуникационной компанией в регионе. Среди наших клиентов 80% провайдеров города Саратова.

Жду Вашего ответа. Спасибо.

С Уважением, Александр Иванов

Начальник отдела ИТ ЗАО "Конверсия-связь"

______________________________________________

AI1410-RIPE  mailto:ivanov@kons.ru  +7 845 2450544

Date: Wed, 27 Jun 2001 10:26:15

Здравствуйте, Юрий Алексеевич!

Все наши ресурсы построены именно таким образом, что тексты и рисунки лежат в какой-то базе данных. А дизайн - это 2-3 шаблона. Именно из-за того, что информация на Вашем сайте постоянно обновляется и нужен такой вариант, чтобы не выкачивать страницы целиком. а только обновления базы. Цель, которую я преследую такова: есть необходимость иметь локально нужный, интересный и полезный ресурс и пропагандировать его среди своих клиентов. Клиенты создают трафик, чем он больше, тем дешевле стоит и для меня и для клиентов. По-поводу идей: направляю Ваше письмо своему WEB-мастеру. Думаю, он сможет что-то предложить. Адрес, где будет размещено зеркало: book.kons.ru , но это будет позже, когда мой администратор вернется из командировки (на следующей неделе).

С Уважением,

Александр Иванов

Директор департамента ИТ ЗАО "Конверсия-связь"

______________________________________________

AI1410-RIPE  mailto:ivanov@kons.ru  +7 845 2450544

Date: Tue, 03 Jul 2001 19:05:35>

Здравствуйте!

Я обнаружил вашу электронную версию книги "Сети Интернет" Скажи, пожалуйста есть ли у вас версия в PDF и где её можно найти?

С Уважением М.А. Пикулин

Молоток: от Фаберже до неглиже

http://www.molotok.ru/?190

Date: Mon, 9 Jul 2001 17:40:10

Добрый день!

Если у Вас, есть информация по аналоговым интерфейсам:

e&m (типы 1, 2, 3, 4, 5 )

ls/gs Subscriber (FXS)

ls/gs Exchange (FXO)

MRD

по цифровым

v.24/v.28/rs-232c

rs-530-a, v.36/rs-449, x.21 и x.35

OCU-DP

G.703 сонаправленный 64 кбит/с......

и возможность, вышлите ее (информацию), пожалуйста, на evsve@mail.ru

с уважением, Евграфов Сергей!

Date: Thu, 9 Aug 2001 12:34:56

Уважаемый господин Семенов Ю.А.

Должен Вам сообщить о некоторой неточности, которая присутствует в перечислении компаний, работающих в области телекоммуникаций. ( сайт http://book.itep.ru/1/intro1.htm раздел 10). Компаний Wandel Goltermann и Wavetek в настоящее время не существует, т к в 1998 году они путем слияния были преобразованы в корпорацию Wavetek Wandel Goltermann с соответствующим сайтом в Интернете www.wwgsolutions.com. Однако это не последнее преобразование фирмы. В 2000 году произошло следующее слияние компаний WWG и американской ТТС. В результате образованная компания получила название ACTERNA. Именно под этим названием компания и работает в настоящее время. Сайт в Интернете называется - www.acterna.com (или российский сайт - www.acterna.ru)

Date: Sat, 6 Oct 2001 18:22:46

From: "profy.ru" <info@profy.ru>

To: semenov@itep.ru

Уважаемые господа!

Разрешите предложить Вашему вниманию для возможного размещения в разделе ссылок Вашего сайта наш Интернет-проект "Мир Профессионалов"- www.profy.ru . Это универсальный кадровый сервер, с которым сотрудничают и размещают свои вакансии более 1500 компаний и кадровых агентств. Все размещаемые вакансии модерируются, то есть исключены вакансии от недобросовестных работодателей. Надеемся, ссылка на www.profy.ru окажется интересной для Ваших посетителей. Кнопку сайта можно выбрать здесь - http://moscow.profy.ru/linktoprofy.phtml

С наилучшими пожеланиями,

Владимир Ершов,

менеджер проекта

www.profy.ru

info@profy.ru

Date: Fri, 19 Oct 2001 02:34:33

Здравствуйте, Юрий Алексеевич.

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

С уважением

Александр Суворов

Best regards,

Alexandre mailto:spartak@nojabrsk.ru

Date: Thu, 25 Oct 2001 21:44:41

Здравствуйте господин Семенов !

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

solid82@rambler.ru

Бесплатная почта http://mail.Rambler.ru/

Рамблер-Покупки http://ad.rambler.ru/ban.clk?pg=1691&bn=9346

Date: Wed, 12 Dec 2001 15:24:57

Здравствуйте Юрий Алексеевич,

Недавно наткнулся на ?кусочки? ваших электронных лекций у одного из своего знакомых. Очень заинтересовался вашим материалом, но к сожалению, ваших книжек в продаже не нашел. Если вас не затруднит, пожалуйста, напишите, где можно заказать или пробрести вашу литературу, CD (если он вышел) и вышли ли ваши новые труды после ?Протоколы и ресурсы Интернет? (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы? (Сиринъ, М. 1998).

Заранее благодарен,

с уважением, студент 4-го курса СПбГТУ

Бесплатная почта http://mail.Rambler.ru/

Date: Wed, 29 May 2002 13:03:21

Уважаемый Юрий Алексеевич!

Большое спасибо за вашу работу, результатами которой очень приятно пользоваться (а главное с пользой). На сервере представлено очень много информации, но доступ к ней удобен только для тех, кто имеет постоянный доступ в сеть. Не планируете ли вы выкладывать для скачивания оффлайновую версию сайта? george@comtv.ru

From: "Eugene Rybakov" <rybakov@bhv.ru>

To: <semenov@itep.ru>

Date: Thu, 11 Apr 2002 13:07:37

..Данный сервер частично создан на средства, выделенные по проектам РФФИ (99-07-90102 и 01-07-90069). В основу материалов легли тексты книг автора "Протоколы и ресурсы Интернет" (Радио и связь, М. 1996) и "Сети Интернет. Архитектура и протоколы" (Сиринъ, М. 1998), а также "Протоколы Интернет. Энциклопедия" ("Горячая линия - Телеком", М. 2001), которые базировались на двух курсах, читаемых студентам кафедры "Телекоммуникационные сети и системы" МФТИ (факультет ФПФЭ) - "Каналы и сети передачи данных", "Протоколы Интернет".

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


Уважаемый Юрий Алексеевич!

Если Вы не разочаровались окончательно в технике книжных издательств, прошу обратить внимание на возможность издания очередной книги в "BHV-Петербург". Тематика нас весьма интересует.

Рассмотрим встречные предложения.

Евгений Рыбаков, научный редактор.

From: "AdminAtlas" <kisasoft@atlas-nsk.ru>

To: <semenov@itep.ru >

Date: Wed, 11 Sep 2002 12:33:00

Прошу Вашего согласия на размещение текста сайта http://book.itep.ru/ у себя на сайте http://www.atlas-nsk.ru в одном из разделов посвященных сходной тематике. Сохранность авторской редакции текста гарантирую. Ссылки на автора будут установлены. Жду ответа.

С уважением . Семенов Юрий Анатольевич.

From: <safonov@tih.ru>

To: <semenov@itep.ru >

Date: Wed, 27 Nov 2002 09:58:34

Здравствуйте, Юрий Алексеевич.

Совершенно случайно нашел Ваш сайт "телекоммуникационные технологии". Огромное спасибо за него! Я только начинаю администрить и он уже стал моим "настольным" справочником.

С уважением, Сафонов Андрей

mailto:safonov@tih.ru

www.tihoretsk.ru



Перекрывающиеся объединения



Рисунок .34. Перекрывающиеся объединения.

На Рисунок 34, AS1 вместе с AS2 объединяют 128.8.0.0/16 и 128.9.0.0/16 в 128.8.0.0/15. Вместе с AS3, AS1 объединяет 128.10.0.0/16 и 128.11.0.0/16 в 128.10.0.0/15. Но все вместе они объединяют эти четыре маршрута в 128.8.0.0/14. Предполагая все четыре компоненты доступными, маршрутизатор в AS1 для внешней AS, скажем AS4, сначала сгенерирует 128.8.0.0/15 и 128.10.0.0/15. Это сделает 128.8.0.0/15, 128.10.0.0/15 и его исключение 128.11.0.0/16 доступным для генерации 128.8.0.0/14. Маршрутизатор из этих трех маршрутов будет затем генерировать 128.8.0.0/14. Следовательно, для AS4, 128.8.0.0/14 и его исключение, 128.10.0.0/15 и его исключение 128.11.0.0/16 станут экспортируемыми.

Для AS2, маршрутизатор в AS1 сгенерирует только 128.10.0.0/15. Следовательно, 128.10.0.0/15 и его исключение 128.11.0.0/16 станут экспортируемыми. Заметим, что 128.8.0.0/16 и 128.9.0.0/16 являются также экспортируемыми, так как они не участвуют в объединении, допускающем экспорт в AS2. Аналогично, для AS3, маршрутизатор в AS1 будет генерировать только 128.8.0.0/15. В этом случае 128.8.0.0/15, 128.10.0.0/16, 128.11.0.0/16 могут экспортироваться.

8.2. Спецификация статических маршрутов

Атрибут inject может служить для спецификации статических маршрутов, используя "upon static" в качестве условия:

inject:

[at <routerexpression>] ...

[action <action>]

upon static

В этом случае маршрутизатор в <router-expression> выполняет <action> и вводит маршрут в статическую маршрутную систему interAS. <action> может установить определенные маршрутные атрибуты, такие как next-hop router или cost.

В следующем примере, маршрутизатор 1.1.1.1 вводит маршрут 128.7.0.0/16. Маршрутизаторы следующего шага (в этом примере, имеется два маршрутизатора “следующего шага”) для этого маршрута имеют адреса 1.1.1.2 и 1.1.1.3, а маршрут имеет цену 10 для 1.1.1.2 и 20 для 1.1.1.3.

route: 128.7.0.0/16

origin: AS1

inject: at 1.1.1.1 action next-hop = 1.1.1.2; cost = 10; upon static

inject: at 1.1.1.1 action next-hop = 1.1.1.3; cost = 20; upon static



показывает оконечное состояние



Рисунок показывает оконечное состояние после меньшего резервирования 2B пришедшего позднее из (d). Это стабильное состояние нарушается каждые Kb*R секунд, когда состояние блокады удаляется по таймауту. Следующее обновление (4B), посылаемое предыдущему узлу (a), предположительно будет отвергнуто, путем посылки сообщения ResvErr, которое восстановит состояние блокады, возвращая ситуацию к тому, что изображено на рисунке. В то же самое время сообщение ResvErr будет направлено следующему узлу (c) и всем получателям, ответственным за резервирование 4B.



Показывает пример резервирования



Рисунок 4.4.9.6.3 показывает пример резервирования WF именно при этом предположении (стрелками отмечены допустимые маршруты). Так как нет пути от IБ к IВ, резервирование, переадресуемое интерфейсом IБ, рассматривает резервирование только для интерфейса IГ.

5. Механизмы протокола RSVP

5.1. Сообщения RSVP



Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы



4.1.1.4 Повторители, мосты, мультиплексоры, переключатели и маршрутизаторы

На физическом уровне пакет представляет собой цуг импульсов, распространяющихся по коаксиальному кабелю, скрученной паре или оптическому волокну. За счет дисперсии, частичным отражениям от точек подключения и поглощению в среде импульсы в пакете "расплываются" и искажаются (ухудшается отношение сигнал/шум), это является одной из причин ограничения длин кабельных сегментов. Для преодоления этих ограничений вводятся сетевые повторители (repeater). Повторитель воспринимает входные импульсы, удаляет шумовые сигналы и передает вновь сформированные пакеты в следующий кабельный сегмент или сегменты. Никакого редактирования или анализа поступающих данных не производится. Задержка сигнала повторителем не должна превышать 7,5 тактов (750нсек для обычного Ethernet). Повторители могут иметь коаксиальные входы/выходы, AUI-разъемы для подключения трансиверов или других аналогичных устройств, или каналы для работы со скрученными парами.



Предопределенные типы аргументов



Рисунок .26. Предопределенные типы аргументов

За целочисленными и действительными предопределенными типами могут следовать младшие или старшие секции, которые позволяют специфицировать набор допустимых значений аргумента. Спецификация диапазона является опционной. Для представления целых действительных значений и символьных строк используется нотация языка Си (ANSI). За типом enum следует список имен RPSL, которые являются значениями данного типа. Булев тип может принимать значение true или false. as_number, ipv4_address, address_prefix и dns_name типы имеют те же значения, что типы фильтра (раздел 2) и фильтры политики (раздел 6). Значения фильтра следует помещать в скобки.

Синтаксис типа union имеет следующий вид:

union <type-1>, ... , <type-N>

где <type-i> является типом RPSL. Тип union может иметь тип в интервале от <type-1> до <type-N>.

Синтаксис списочного типа приведен ниже:

list [<min_elems>:<max_elems>] of <type>

В этом случае элементы списка представляют <type>, а список содержит по крайней мере <min_elems> элементов, но не больше чем <max_elems>>. Размер спецификации является опционным. Если спецификация отсутствует, то никаких регламентаций на число элементов в списке не накладывается. Значение списочного типа представляется в виде последовательности элементов, разделенных символом запятой "," и заключенных в фигурные скобки "{" и "}". Атрибут typedef в словаре определяет именованный тип следующим образом:

typedef: <name> <type>

где <name> - имя типа <type>. Атрибут typedef является особенно полезным, когда тип не является предопределенным (напр., список объединений [union], список списков и т.д.). Атрибут класса словаря protocol определяет протокол и набор параметров пиринга для этого протокола, которые используются в классе inet-rtr (раздел 9). Его синтаксис представлен ниже:

protocol: <name>
MANDATORY | OPTIONAL <parameter-1>(
<type-1-N1> [,"..."])
...
MANDATORY | OPTIONAL <parameter-M>( <type-M-1>,...,
<type-M-NM> [,"..."])
<
/p> где представляет собой имя протокола, MANDATORY и OPTIONAL являются ключевыми словами, а <parameter-i> - пиринг-параметр протокола, использующий Ni аргументов. Синтаксис и семантика аргументов та же, что и для rp-атрибута. Если используется ключевое слово MANDATORY, параметр является обязательным и должен быть специфицирован для каждого пиринга этого протокола. Если применено ключевое слово OPTIONAL, параметр может быть опущен.



7.1. Исходный словарь RPSL, пример действий политики и фильтры



dictionary: RPSL

rp-attribute: # меньшие значения соответствуют более высокому предпочтению pref

operator=(integer[0, 65535])
rp-attribute: # атрибут BGP multi_exit_discriminator

med
# установить med равным 10: med = 10;
# установить med метрике IGP: med = igp_cost;
operator=(union integer[0, 65535], enum[igp_cost])
rp-attribute: # атрибут предпочтения места назначения BGP (dpa)

dpa
operator=(integer[0, 65535])
rp-attribute: # атрибут BGP aspath

aspath
# prepends AS numbers from last to first order
prepend(as_number, ...)
typedef: # значение community в RPSL равно:

# - 4-байтовому целому (ok to use 3561:70 notation)
# - internet, no_export, no_advertise (смотри RFC-1997)
community_elm union
integer[1, 4294967295],
enum[internet, no_export, no_advertise],
typedef: # список значений community { 40, no_export, 3561:70 }

community_list list of community_elm
rp-attribute: # атрибут BGP community

community
# set to a list of communities
operator=(community_list)
# добавить значения community
operator.=(community_list)
append(community_elm, ...)
# удалить значения community
delete(community_elm, ...)
# фильтр: true если содержится одно из значений community
contains(community_elm, ...)
# shortcut to contains: community(no_export, 3561:70)
operator()(community_elm, ...)
# сравнение равенства, независящее от порядка
operator==(community_list)
rp-attribute: # следующий маршрутизатор в статическом маршруте next-hop
  # установить равным 7.7.7.7: next-hop = 7.7.7.7;
# установить собственный адрес маршрутизатора: next-hop = self;
  operator=(union ipv4_address, enum[self])
rp-attribute: # цена статического маршрута cost
<


/p>
operator=(integer[0, 65535])
protocol: BGP4
  # номер AS маршрутизатора партнера
  MANDATORY asno(as_number)
  # разрешить гашение осцилляций маршрута
  OPTIONAL flap_damp()
  OPTIONAL flap_damp(integer[0,65535],
  # penalty per flap
  integer[0,65535],
  # penalty value for supression
  integer[0,65535],
  # penalty value for reuse
  integer[0,65535],
  # halflife in secs when up
  integer[0,65535],
  # halflife in secs when down
  integer[0,65535])
  # максимальный штраф
protocol: OSPF

protocol: RIP

protocol: IGRP

protocol: IS-IS

protocol: STATIC

protocol: RIPng

protocol: DVMRP

protocol: PIM-DM

protocol: PIM-SM

protocol: CBT

protocol: MOSPF


A Определения объектов


40. Приложение A. Определения объектов

C-типы определены для двух семейств адресов Интернет IPv4 и IPv6. Для работы с другими адресными семействами можно легко определить новый C-тип. Все неиспользуемые поля должны заполняться нулями и игнорироваться при получении .

Класс сессии

Класс сессии = 1.

Объект IPv4/UDP SESSION: Класс = 1, C-тип = 1

Объект IPv6/UDP SESSION: Класс = 1, C-тип = 2

DestAddress

Уникастный или мультикастный IP-адрес места назначения сессии. Это поле не должно быть равно нулю.

Протокол Id

Идентификатор IP-протокола для потока данных. Это поле не должно быть равно нулю.

Флаги

0x01 = E_Police flag

Флаг E_Police используется в сообщениях Path для определения эффективного “края” сети, с целью организации управления трафиком. Если ЭВМ отправитель сама не способна осуществлять управление трафиком, она установит этот бит в сообщениях Path, которые посылает. Первый узел, где RSVP имеется возможность управления трафиком (если это требуется), установит этот флаг равным нулю.

DstPort

UDP/TCP порт места назначения сессии. Допустимо значение нуль, означающее отсутствие порта.

Класс RSVP_HOP

RSVP_HOP класс = 3.

Объект IPv4 RSVP_HOP: Класс = 3, C-Тип = 1

Объект IPv6 RSVP_HOP: Класс = 3, C-Тип = 2

Этот объект несет в себе IP-адрес интерфейса, через который последний RSVP-узел переслал это сообщение. Дескриптор логического интерфейса LIH (Logical Interface Handle) используется, для того чтобы различать логические выходные интерфейсы. Узел, получая LIH в сообщении Path, запоминает его величину и возвращает его в объектах HOP последующих сообщений Resv, посланных узлу, который сформировал LIH. LIH должен быть тождественно равен нулю, если не существует дескриптора логического интерфейса.

Класс INTEGRITY

INTEGRITY класс = 4.

Класс TIME_VALUES

TIME_VALUES класс = 5.

Объект TIME_VALUES: Класс = 5, C-Тип = 1

Период обновления

Период таймаута обновления R, использованного для генерации этого сообщения (в миллисекундах).

Класс ERROR_SPEC

ERROR_SPEC класс = 6.


Объект IPv4 ERROR_SPEC: Класс = 6, C-тип = 1



Объект IPv6 ERROR_SPEC: Класс = 6, C-тип = 2



Поле адрес узла, где произошла ошибка является IP-адресом (IPv4 или Ipv6).

Флаги

0x01 = InPlace

Это значение поля флаги используется только для объектов ERROR_SPEC в сообщении ResvErr. Если флаг = 1, это указывает, что в узле, где произошла ошибка, установлено резервирование.

0x02 = NotGuilty

Это значение поля флаги используется только для объекта ERROR_SPEC в сообщении ResvErr. Это значение устанавливается для интерфейса в прикладной программе получателя. Если флаг имеет такой код, спецификация FLOWSPEC, которая вызвала ошибку, больше запрошенной получателем.

Код ошибки.Одно-октетное поле кода описания ошибки.

Значение ошибки

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

Класс SCOPE = 7.



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

Объект IPv4 SCOPE: Класс = 7, C-тип = 1

Объект Ipv6 SCOPE: Класс = 7, C-тип = 2

Объект имеет ту же структуру, что и предыдущий, только для каждого адреса выделяется 16 байт.

Класс STYLE = 8.



Объект STYLE: Класс = 8, C-тип = 1

Поле Флаги: 8 бит. (Пока не определены)

Вектор опций: 24 бита

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

19 бит: Зарезервировано

2 бита: контроль совместного использования

00b: Зарезервировано

01b: Явное резервирование

10b: Распределенное резервирование

11b: Зарезервировано



3 бита: Управление выбором отправителя

000b: Зарезервировано

001b: Произвольный выбор (Wildcard)

010b: Прямой выбор (Explicit)

011b - 111b: Зарезервировано

Младшие биты вектора опций определяются стилем:

WF 10001b

FF 01010b

SE 10010b

Класс FLOWSPEC

Класс FLOWSPEC = 9.

Зарезервировано (устарело) объект flowspec: Класс = 9, C-Тип = 1

Объект Inv-serv Flowspec: Класс = 9, C-тип = 2

Содержимое и правила кодирования этого объекта описаны в документах, подготовленных рабочей группой int-serv [RFC 2210].

Класс FILTER_SPEC = 10.



Объект IPv4 FILTER_SPEC: Класс = 10, C-тип = 1

Объект IPv6 FILTER_SPEC: Класс = 10, C-тип = 2

Объект имеет ту же структуру, что и предыдущий, только для каждого адреса выделяется 16 байт.

Объект IPv6 Flow-label FILTER_SPEC: Класс = 10, C-тип = 3



SrcAddress. Это поле характеризует IP-адрес источника для ЭВМ отправителя. Его значение не должно быть равно нулю.

SrcPort. UDP/TCP номер порта отправителя, или нуль, указывающий на отсутствие порта.

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

Класс SENDER_TEMPLATE = 11.

Объект IPv4 SENDER_TEMPLATE: Класс = 11, C-тип = 1

Определение то же, что и для объекта IPv4/UDP FILTER_SPEC.

Объект IPv6 SENDER_TEMPLATE: Класс = 11, C-тип = 2

Определение то же, что и для объекта IPv6/UDP FILTER_SPEC.

Объект метки потока IPv6 SENDER_TEMPLATE: Класс = 11, C-тип = 3

Класс SENDER_TSPEC = 12.

Объект Intserv SENDER_TSPEC: Класс = 12, C-тип = 2

Содержимое и правила кодирования для этого объекта специфицированы в документах, подготовленных рабочей группой int-serv.

Класс ADSPEC = 13.

Объект Intserv ADSPEC: Класс = 13, C-тип = 2

Содержимое и формат этого объекта специфицированы в документах, подготовленных рабочей группой int-serv.

Класс POLICY_DATA = 14.

Объект POLICY_DATA: Класс = 14, C-тип = 1

Содержимое этого объекта будет определено в будущем.

Класс Resv_CONFIRM = 15.

Объект IPv4 RESV_CONFIRM: Класс = 15, C-тип = 1

Объект характеризует 4-байтовый IP-адрес получателя (Ipv4).

Объект IPv6 RESV_CONFIRM: Класс = 15, C-тип = 2

Объект характеризует 15-байтовый IP-адрес получателя (Ipv6).




B Коды и значения ошибки


41. Приложение B. Коды и значения ошибки

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

Код ошибки = 00: Подтверждение.

Это код зарезервирован для использования в объекте ERROR_SPEC сообщения ResvConf. Значение ошибки также будет равно нулю.

Код ошибки = 01: Отказ системы управления допуском.

Запрос резервирования отвергнут системой управления допуском из-за недостатка ресурсов. Для этого кода ошибки 16 бит поля значение ошибки имеют формат:

ssur cccc cccc cccc

где биты имеют следующие значения:

ss = 00: Младшие 12 бит содержат глобально-определенный субкод (значение приведены ниже).

ss = 10: Младшие 12 бит содержат организационно-специфический субкод. Предполагается, что RSVP интерпретирует этот код как обычное число.

ss = 11: Младшие 12 бит содержат субкод, зависящий от вида услуг. Предполагается, что RSVP интерпретирует этот код как обычное число.

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

u = 0: RSVP отвергает сообщение без модификации локального состояния

u = 1: RSVP может использовать сообщение для модификации локального состояния и для последующей пересылки. Это означает, что сообщение является информационным.

r: зарезервированный бит, должен быть равен нулю.

cccc cccc cccc: 12 битовый код.

Следующие глобально-заданные субкоды могут появиться в младших 12 битах, когда ssur = 0000:

- Субкод = 1: Предел (bound) по задержке не может быть обеспечен.

- Субкод = 2: Запрашиваемая полоса пропускания недоступна.

- Субкод = 3: MTU в flowspec больше чем MTU интерфейса.

Код ошибки = 02: Policy Control failure

Сообщение резервирования или path было отвергнуто по административным причинам, например, не выполнены условия аутентификации, недостаточная квота и т.д.. Этот код ошибки может появиться в сообщении PathErr или ResvErr.


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

Код ошибки = 03: Нет информации о проходе для этого сообщения Resv. Нет состояния прохода для данной сессии. Сообщение Resv не может быть переслано.

Код ошибки = 04: Нет информации отправителя для этого сообщения Resv. Имеется состояние прохода для этой сессии, но оно не включает в себя записи отправителя, соответствующей дескриптору потока, который содержится в сообщении Resv. Сообщение Resv не может быть переслано.

Код ошибки = 05: Конфликт со стилем резервирования. Стиль резервирования конфликтует со стилем существующего состояния резервирования. Поле значение ошибки содержит младшие 16 бит вектора опций существующего стиля, с которым произошел конфликт. Сообщение Resv не может быть переслано.

Код ошибки = 06: Неизвестный стиль резервирования. Стиль резервирования неизвестен. Сообщение Resv не может быть переслано.

Код ошибки = 07: Конфликт портов места назначения. Появились сессии для одного и того же адреса места назначения с нулевым и ненулевым значением полей порта назначения. Этот код ошибки может появиться в сообщении PathErr или ResvErr.

Код ошибки = 08: Конфликт портов отправителя. Для одной и той же сессии имеются нулевые и ненулевые порты отправителя в сообщениях Path. Этот код ошибки может появиться только в сообщении PathErr.

Код ошибки = 09, 10, 11: (зарезервировано)

Код ошибки = 12: Привилегированное обслуживание. Запрос обслуживания, определенный объектом STYLE, и дескриптор потока были административно перехвачены.

Для этого кода ошибки 16 бит поля значения ошибки имеют формат:

ssur cccc cccc cccc

Ниже приведены значения старших бит ssur, как они определены при коде ошибки 01. Глобально-заданные субкоды, которые могут появиться в младших 12 битах, когда ssur = 0000 должны быть определены в будущем.

Код ошибки = 13: Неизвестный класс объекта. Этот код ошибки содержит 16-битовое слово, состоящее из (Class-Num, C-тип) неизвестного объекта. Эта ошибка должна быть послана только в случае, когда RSVP намеревается отвергнуть сообщение, как это определено старшими битами Class-Num.


Этот код ошибки может появиться в сообщении PathErr или ResvErr.

Код ошибки = 14: Неизвестный объект C-типа. Значение ошибки содержит 6-битовый код, состоящий из (Class-Num, C-тип) объекта.

Код ошибки = 15-19: (зарезервировано)

Код ошибки = 20: Зарезервировано для API. Поле значение ошибки содержит код ошибки API, которая была обнаружена асинхронно и о которой необходимо уведомить систему соответствующим откликом.

Код ошибки = 21: Ошибка управления трафиком. Запрос управления трафиком не прошел из-за формата или содержимого параметров запроса. Сообщения Resv или Path, которые инициировали вызов, не могут быть пересланы, повторные вызовы бесполезны.

Для этого кода ошибки 16 бит поля значения ошибки имеют формат:

ss00 cccc cccc cccc

Ниже представлены значения старших бит ss, как это определено для кода ошибки 01.

Следующие глобально-заданные субкоды могут появляться в младших 12 битах (cccc cccc cccc), когда ss = 00:

Субкод = 01: Конфликт сервиса. Попытка объединить два несовместимых запроса обслуживания.

Субкод = 02: Сервис не поддерживается. Управление трафиком не может обеспечить запрашиваемый сервис или его приемлемую замену.

Субкод = 03: Плохое значение Flowspec. Запрос неверного формата или неприемлемые требования.

Субкод = 04: Плохое значение Tspec. Запрос неверного формата или неприемлемых требований.

Субкод = 05: Плохое значение Adspec. Запрос неверного формата или неприемлемые требования.

Код ошибки = 22: Ошибка системы управления трафиком. Модули управления трафиком обнаружели системную ошибку. Значение ошибки будет содержать специфический для системы код, предоставляющий дополнительную информацию об ошибке. Предполагается, что RSVP не может интерпретировать его значение.

Код ошибки = 23: Системная ошибка RSVP

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

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


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

Единственными ошибками формата сообщений, которые доводятся до сведения оконечной системы, являются несоответствия версии.

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

Неверная длина сообщения: Поле длины RSVP не соответствует реальной длине сообщения.

Неизвестная или неподдерживаемая версия RSVP.

Ошибка в контрольной сумме RSVP

Ошибка в INTEGRITY

Нелегальный тип сообщения RSVP

Нелегальная длина объекта: не кратна 4, или меньше 4 байт.

Адрес предыдущего/следующего узла в объекте HOP является нелегальным.

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

Отсутствует необходимый класс объекта

Нелегальный класс объекта для данного типа сообщения.

Нарушение регламентируемого порядка объектов

Неверное число дескрипторов потока для данного типа сообщения или стиля

Неверный дескриптор логического интерфейса

Неизвестный объект Class-Num.

Адрес места назначения сообщения ResvConf не согласуется с адресом получателя в объекте RESV_CONFIRM.


C UDP-инкапсуляция



42. Приложение C. UDP-инкапсуляция

Реализации RSVP обычно требуют возможности выполнять любые сетевые операции ввода/вывода, т.е., посылать и получать IP-дейтограммы, используя код протокола 46. Однако, некоторые важные классы вычислительных систем могут не поддерживать такого рода операции. Для использования RSVP, такие ЭВМ должны инкапсулировать сообщения RSVP в UDP-дейтограммы.

Базовая схема UDP-инкапсуляции использует два предположения:

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

Маршрутизаторы первого/последнего узлов должны поддерживать RSVP.

Пусть Hu является ЭВМ, которая нуждается в UDP-инкапсуляции, а Hr ЭВМ, способная выполнять любые сетевые операции ввода/вывода. Схема UDP-инкапсуляции должна допускать RSVP взаимодействие ЭВМ типа Hr, Hu и маршрутизаторов.

Сообщения Resv, ResvErr, ResvTear и PathErr посылаются по уникастным адресам, полученным из состояний прохода или резервирования узла. Если узел отслеживает, в каком из предыдущих узлов и в каком интерфейсе нужна UDP-инкапсуляция, эти сообщения при необходимости могут быть посланы с применением UDP инкапсуляции. С другой стороны, сообщения Path и PathTear могут посылаться адресату с применением как мультикастных, так и уникастных адресов.

В таблицах 4.4.9.6.1 и 4.4.9.6.2 приведены базовые правила UDP-инкапсуляции сообщений Path и PathTear, для уникастных и мультикастных DestAddress. Другие типы сообщений, которые работают с уникастными адресами, должны следовать правилам из табл. 4.4.9.6.1. Записи в колонке `RSVP посылает' имеют формат `mode(destaddr, destport)'.

Полезно определить две разновидности UDP-инкапсуляций, одна используется для посылки сообщений от Hu, другая от Hr и R. Это делается, для того чтобы избежать двойной обработки сообщения получателем. На практике эти два вида инкапсуляций разделяются по номерам UDP портов Pu и Pu'.

В таблицах используются следующие символы.

D является портом назначения (DestAddress) конкретной сессии.

G* является стандартным групповым адресом формата 224.0.0.14, т.е., группа ограничена пределами локальной сети.

Pu и Pu' являются стандартными UDP-портами для UDP-инкапсуляции RSVP, с номерами 1698 и 1699.

Ra равен IP-адресу интерфейса маршрутизатора `a'.

Интерфейс маршрутизатора `a' локально доступен для Hu и Hr.



Пример дерева гиперсвязей



Рисунок 4.5.14.1. Пример дерева гиперсвязей


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

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

Для решения этой задачи в большинстве операционных систем имеются специальные утилиты (например, grep для UNIX). Но даже они требуют достаточно много времени, если, например, дисковое пространство лежит в пределах нескольких гигабайт, а каталог весьма разветвлен. В полнотекстных базах данных для ускорения поиска используется индексация по совокупности слов, составляющих текст. Хотя индексация также является весьма времяемкой процедурой, но производить ее, как правило, приходится только один раз. Проблема здесь заключается в том, что объем индексного файла оказывается сравным (а в некоторых случаях превосходит) с исходным индексируемым файлом. Первоначально каждому документу ставился в соответствие индексный файл, в настоящее время индекс готовится для тематической группы документов или для поисковой системы в целом. Такая схема индексации экономит место в памяти и ускоряет поиск. Для документов очень большого размера может использоваться отдельный индекс, а в поисковой системе иерархический набор индексов. Индексированием называется процесс перевода с естественного языка на информационно-поисковый язык. В частности, под индексированием понимается отнесение документа в зависимости от содержимого к определенной рубрике некоторой классификации. Индексирование можно свести к проблеме распознавания образов. Классификация определяет разбиение пространства предметных областей на непересекающиеся классы.
Каждый класс характеризуется набором признаков и специфических для него терминов (ключевых слов), выражающих основные понятия и отношения между ними.
Слова в любом тексте в информационном отношении весьма неравнозначны. И дело не только в том, что текст содержит много вспомогательных элементов предлогов или артиклей (напр., в англоязычных текстах). Часто для сокращения объема индексных регистров и ускорения самого процесса индексации вводятся так называемые стоп-листы. В эти стоп-листы вносятся слова, которые не несут смысловой нагрузки (например, предлоги или некоторые вводные слова). Но при использовании стоп-листов необходима определенная осторожность. Например, занеся в стоп-лист, неопределенный артикль английского языка “а”, можно заблокировать нахождение ссылки на “витамин А”.
Немалое влияние оказывает изменяемость слов из-за склонения или спряжения. Последнее делает необходимым лингвистический разбор текста перед индексацией. Хорошо известно, что смысл слова может меняться в зависимости от контекста, что также усложняет проблему поиска. Практически все современные информационные системы для создания и обновления индексных файлов используют специальные программные средства.
Существующие поисковые системы успешно работают с HTML-документами, с обычными ASCII-текстами и новостями usenet. Трудности возникают для текстов Winword и даже для текстов Postscript. Связано это с тем, что такие тексты содержат большое количество управляющих символов и текстов. Трудно (практически невозможно) осуществлять поиск для текстов, которые представлены в графической форме. К сожалению, к их числу относятся и математические формулы, которые в HTML имеют формат рисунков (это уже недостаток самого языка). Так что можно без преувеличения сказать, что в этой крайне важной области, имеющей немалые успехи, мы находимся лишь в начале пути. Ведь море информации, уже загруженной в Интернет, требует эффективных средств навигации. Ведь оттого, что информации в сети много, мало толку, если мы не можем быстро найти то, что нужно.


И в этом, я полагаю, убедились многие читатели, получив на свой запрос список из нескольких тысяч документов. Во многих случаях это эквивалентно списку нулевой длины, так как заказчик в обоих случая не получает того, что хотел.
Встроенная в язык HTML метка <meta> создана для предоставления информации о содержании документа для поисковых роботов, броузеров и других приложений. Структура метки: <meta http-equiv=response content=description name=description URL=url>. Параметр http-equiv=response ставит в соответствие элементу заголовок HTTP ответа. Значение параметра http-equiv интерпретируется приложением, обрабатывающим HTML документ. Значение параметра content определяется значением, содержащимся в http-equiv.
Современная поисковая система содержит в себе несколько подсистем.
web-агенты. Осуществляют поиск серверов, извлекают оттуда документы и передают их системе обработки.
Система обработки. Индексирует полученные документы, используя синтаксический разбор и стоп-листы (где, помимо прочего, содержатся все стандартные операторы и атрибуты HTML).
Система поиска. Воспринимает запрос от системы обслуживания, осуществляет поиск в индексных файлах, формирует список найденных ссылок на документы.
Система обслуживания. Принимает запросы поиска от клиентов, преобразует их, направляет системе поиска, работающей с индексными файлами, возвращает результат поиска клиенту. Система в некоторых случаях может осуществлять поиск в пределах списка найденных ссылок на основе уточняющего запроса клиента (например, recall в системе altavista). Задание системе обслуживания передается WEB-клиентом в виде строки, присоединенной к URL, наример, http://altavista.com/cgi-bin/query?pg=q&what=web&fmt=/&q=plug+%26+play, где в поле поиска было записано plug & play)
Следует иметь в виду, что работа web-агентов и системы поиска напрямую независимы. WEB-агенты (роботы) работают постоянно, вне зависимости от поступающих запросов. Их задача – выявление новых информационных серверов, новых документов или новых версий уже существующих документов.


Под документом здесь подразумевается HTML-, текстовый или nntp-документ. WEB- агенты имеют некоторый базовый список зарегистрированных серверов, с которых начинается просмотр. Этот список постоянно расширяется. При просмотре документов очередного сервера выявляются URL и по ним производится дополнительный поиск. Таким образом, WEB-агенты осуществляют обход дерева ссылок. Каждый новый или обновленный документ передается системе обработки. Роботы могут в качестве побочного продукта выявлять разорванные гиперсвязи, способствовать построению зеркальных серверов.
Обычно работа роботов приветствуется, ведь благодаря ним сервер может обрести новых клиентов, ради которых и создавался сервер. Но при определенных обстоятельствах может возникнуть желание ограничить неконтролируемый доступ роботов к серверам узла. Одной из причин может быть постоянное обновление информации каких-то серверов, другой причиной может стать то, что для доставки документов используются скрипты CGI. Динамические вариации документа могут привести к бесконечному разрастанию индекса. Для управления роботами имеются разные возможности. Можно закрыть определенные каталоги или сервера с помощью специальной фильтрации по IP-адресам, можно потребовать идентификации с помощью имени и пароля, можно, наконец, спрятать часть сети за Firewall. Но существует другой, достаточно гибкий способ управления поведением роботов. Этот метод предполагает, что робот следует некоторым неформальным правилам поведения. Большинство из этих правил важны для самого робота (например, обхождение так называемых “черных дыр”, где он может застрять), часть имеет нейтральный характер (игнорирование каталогов, где лежит информация, имеющая исключительно локальный характер, или страниц, которые находятся в состоянии формирования), некоторые запреты призваны ограничить загрузку локального сервера.
Когда воспитанный робот заходит в ЭВМ, он проверяет наличие в корневом каталоге файла robots.txt. Обнаружив его, робот копирует этот файл и следует изложенным в нем рекомендациям.


Содержимое файла robots.txt в простейшем случае может выглядеть, например, следующим образом.
# robots.txt for http://store.in.ru


user-agent: * # * соответствует любому имени робота
disallow: /cgi-bin/ # не допускает робот в каталог cgi-bin
disallow: /tmp/ # не следует индексировать временные файлы
disallow: /private/ # не следует заходить в частные каталоги

Файл содержит обычный текст, который легко редактировать, после символа # следуют комментарии. Допускается две директивы. user-agent: - определяет имя робота, к которому обращены следующие далее инструкции, если не имеется в виду какой-то конкретный робот и инструкции должны выполняться всеми роботами, в поле параметра записывается символ *. disallow – указывает имя каталога, посещение которого роботу запрещено. Нужно учитывать, что не все роботы, как и люди, следуют правилам, и не слишком на это полагаться (см. http://info.webcrawler.com/mak/projects/ robots.html).
Автор исходного текста может заметно помочь поисковой системе, выбрав умело заголовок и подзаголовок, профессионально пользуясь терминологией и перечислив ключевые слова в подзаголовках. Исследования показали, что автор (а иногда и просто посторонний эксперт) справляется с этой задачей быстрее и лучше, чем вычислительная машина. Но такое пожелание вряд ли станет руководством к действию для всех без исключения авторов. Ведь многие из них, давая своему тексту образный заголовок, рассчитывают (и не без успеха) привлечь к данному тексту внимание читателей. Но машинные системы поиска не воспринимают (во всяком случае, пока) образного языка. Например, в одном лабораторном проекте, разработанном для лексического разбора выражений, состоящих из существительных с определяющим прилагательным, и по своей теме связанных с компьютерной тематикой, система была не способна определить во фразе “иерархическая компьютерная архитектура” то, что прилагательное “иерархическая” относится к слову “архитектура”, а не к “компьютерная” (Vickery & Vickery 1992).


То есть система была не способна отличать образное использование слова в выражении от его буквального значения.
В свою очередь специалисты, занятые в области поисковых и информационных систем, способны заметно облегчить работу авторам, снабдив их необходимыми современными тезаурусами, где перечисляются нормативные значения базовых терминов в той или иной научно-технической области, а также устойчивых словосочетаний. Параллельно могут быть решены проблемы синонимов.
В настоящее время, несмотря на впечатляющий прогресс в области вычислительной техники, степень соответствия документа определенным критериям запроса надежнее всего может определить человек. Но темп появления электронных документов в сети достигает ошеломляющего уровня (частично это связано с преобразованием в электронную форму старых документов и книг методом сканирования). Написание рефератов для последующего их использование поисковыми системами достаточно изнурительное занятие, требующее к тому же достаточно высокой профессиональной подготовки. Именно по этой причине уже достаточно давно предпринимаются попытки перепоручить этот процесс ЭВМ. Для этого нужно выработать критерии оценки важности отдельных слов и фраз, составляющих текст. Оценку значимости предложений выработал Г.Лун. Он предложил оценивать предложения текста в соответствии с параметром: Vпр =

Пример формата строки



Рисунок .8. Пример формата строки

Поле строка предназначено для записи параметров, специфических для данного производителя.

5.27. Атрибут Session-Timeout

Этот атрибут устанавливает максимальное число секунд, в течение которых будет предоставляться услуга пользователю до завершения сессии или очередного вызова. Этот атрибут может быть послан сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на Рисунок .6. Поле тип = 27, а поле длина = 6.

Поле значение содержит 4 октета, и несет в себе 32-битовое целое число (максимальное число секунд, в течение которых пользователь будет оставаться соединенным с сервером NAS).

5.28. Атрибут Idle-Timeout

Этот атрибут устанавливает максимальное число секунд (непрерывный временной отрезок), в течение которых пользователь может оставаться пассивным, прежде чем соединение с сервером будет разорвано или будет получен вызов. Этот атрибут передается сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на Рисунок .6. Поле тип = 28, а поле длина = 6.

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

5.29. Атрибут Termination-Action

Этот атрибут указывает, какие действия должен выполнить сервер NAS, когда процедура будет завершена. Атрибут используется только в пакетах Access-Accept. Формат записи атрибута показан на Рисунок .6. Поле тип = 29, а поле длина = 6. Поле значение имеет 4 октета. Ниже приведены разрешенные коды поля значения.

0

Значение по умолчанию

1

RADIUS-Request

Если поле значение соответствует RADIUS-Request, по завершении соответствующего сервиса NAS может послать новый запрос Access-Request серверу RADIUS, включив атрибут State, если он имеется.

5.30. Атрибут Called-Station-Id

Этот атрибут позволяет NAS посылать в пакетах Access-Request телефонный номер, который вызывает пользователь.
При этом используется техника DNIS (Dialed Number Identification) или ей подобная. Заметим, что это может быть не тот телефонный номер, через который пришел вызов. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на Рисунок .3. Поле тип = 30, поле длина ³ 3.
Поле строка содержит один или более октетов, содержащих телефонный номер, через который пользователь дозвонился до системы. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

5.31. Атрибут Calling-Station-Id

Этот атрибут позволяет NAS послать в пакете Access-Request телефонный номер, с которого пришел вызов, используя АОН (ANI - Automatic Number Identification) или другую технику. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на Рисунок .3. Поле тип = 31, поле длина ³ 3.
Поле строка содержит один или более октетов, где записан номер телефона, с которого позвонил пользователь. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. Рекомендуется использование печатных ASCII-символов.

5.32. Атрибут NAS-идентификатор

Этот атрибут содержит строку, идентифицирующую запрос Access-Request, посланный сервером NAS. Атрибут используется только в пакетах Access-Request. В пакете Access-Request должен присутствовать атрибут NAS-IP-Address или NAS-Identifier. Формат записи атрибута следует схеме, показанной на Рисунок .3. Поле тип = 32, а поле длина ³ 3.
Поле строка содержит один или более октетов, и должна быть уникальной для NAS в области действия сервера RADIUS. Например, полное имя домена вполне подходит в качестве NAS-идентификатора. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

5.33. Атрибут Proxy-State

Этот атрибут предназначен для посылки прокси-сервером другому серверу при переадресации запроса Access-Request и должен быть возвращен в неизменном виде в сообщениях Access-Accept, Access-Reject или Access-Challenge.


Этот атрибут должен быть удален прокси-сервером, до того как отклик будет переадресован серверу NAS. Использование атрибута Proxy-State зависит от реализации. Формат записи атрибута следует схеме, показанной на Рисунок .3. Поле тип = 33, а поле длина ³ 3.
Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

5.34. Атрибут Login-LAT-Service

Этот атрибут указывает на систему, с которой должен быть соединен пользователь посредством LAT (Local Area Transport). Он может использоваться в пакетах Access-Accept, но только когда в качестве услуги специфицирован LAT (локальный доступ). Атрибут может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер не обязан следовать этой рекомендации.
Администраторы используют атрибут сервиса, когда имеют дело с кластерными системами, такими как VAX или Alpha-кластер. В такой среде несколько процессоров совместно используют общие ресурсы (диски, принтеры и т.д.), и администраторы конфигурируют каждый из них для обеспечения к каждому из ресурсов. В этом случае каждая ЭВМ в кластере оповещает о предоставляемых услугах через широковещательные сообщения LAT.
Продвинутые пользователи часто знают, какие сервис-провайдеры (ЭВМ) обладают большим быстродействием и предпочитают использовать имя узла при установлении LAT-соединения. Некоторые администраторы хотели бы, чтобы определенные пользователи работали с определенными машинами, что представляет собой примитивную форму балансировки нагрузки (хотя LAT имеет собственную систему балансировки). Формат записи атрибута следует схеме, показанной на Рисунок .3. Поле тип = 34, а поле длина ³ 3.
Поле строка имеет один или более октетов и содержит идентификатор LAT-сервиса. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точка), _ (подчеркивание), числа, буквы верхнего и нижнего регистров, а также расширенный символьный набор ISO Latin-1 [6].


Все сравнения в LAT не зависят от регистра символов.

5.35. Атрибут Login-LAT-Node

Этот атрибут указывает на узел, с которым пользователь должен быть соединен автоматически LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда в качестве услуги подключения указан LAT. Он может быть применен в пакете Access-Request в качестве подсказки серверу, но сервер не обязан следовать этим рекомендациям. Формат записи атрибута следует схеме, показанной на Рисунок .3. Поле тип = 35, а поле длина
³ 3.
Поле строка имеет один или более октетов и содержит идентификатор узла LAT, с которым следует соединиться пользователю. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точку), _ (подчеркивание), числа, буквы нижнего и верхнего регистров, а также расширяющий символьный набор ISO Latin-1. Все сравнения в LAT не зависят от регистра символов.

5.36. Атрибут Login-LAT-Group

Этот атрибут содержит строку, идентифицирующую групповой код LAT, который данный пользователь авторизован использовать. Атрибут может использоваться в пакетах Access-Accept, но только когда специфицирован LAT в качестве Login-Service. Он может быть использован в пакете Access-Request в качестве подсказки серверу, но сервер не обязан следовать этим рекомендациям. LAT поддерживает 256 различных групповых кодов, которые LAT использует как некую форму прав доступа. LAT преобразует эти групповые коды в 256 битовую карту соответствия (bitmap).
Администраторы могут приписать один или более бит группового кода сервис-провайдеру LAT. Он будет воспринимать соединения LAT, которые имеют установленные биты, соответствующие их групповым кодам. Администраторы присваивают битовую маску кодов авторизованных групп каждому пользователю. LAT получает эти маски-карты от операционной системы, и использует их в запросах к сервис-провайдерам. Формат записи атрибута следует схеме, показанной на Рисунок .3. Поле тип = 36, а поле длина = 34. Поле строка содержит 32-октетную маску-карту.


Старший октет передается первым.

5.37. Атрибут Framed-AppleTalk-Link

Этот атрибут содержит сетевой номер AppleTalk, который должен быть использован для последовательного канала пользователя, являющимся маршрутизатором сети AppleTalk. Атрибут применяется только в пакетах Access-Accept. Он никогда не используется, когда пользователь не является маршрутизатором. Формат записи атрибута показан на Рисунок .6. Поле тип = 37, а поле длина =6.
Поле значение имеет 4 октета. Допустимый диапазон значений 0 - 65535. Специальное значение 0 указывает, что это ненумерованный последовательный канал. Значения 1-65535 обозначают, что последовательной линии между NAS и пользователем присвоен соответствующий сетевой номер AppleTalk.

5.38. Атрибут Framed-AppleTalk-Network

Этот атрибут представляет собой сетевой номер AppleTalk, который сервер NAS должен попытаться присвоить узлу AppleTalk. Атрибут используется только в пакетах Access-Accept. Атрибут никогда не используется, если пользователем является маршрутизатор. Многократное использование атрибута в пакете указывает на то, что NAS может попытаться использовать один из сетевых номеров, приведенных в атрибутах. Формат записи атрибута показан на Рисунок .6. Поле тип = 38, а поле длина =6.
Поле значение содержит 4 октета. Допустимый диапазон значений 0 - 65535. Специальное значение 0 указывает, что NAS должен назначить сеть для пользователя. Значения в интервале 1 - 65535 (включительно) указывает на сеть AppleTalk, адрес которой должен найти сервер NAS для пользователя.

5.39. Атрибут Framed-AppleTalk-Zone

Этот атрибут указывает на зону AppleTalk по умолчанию, которая должна использоваться для данного пользователя. Атрибут используется только в пакетах Access-Accept. Кратное использование атрибута в одном пакете не допускается. Формат записи атрибута показан на Рисунок .3. Поле тип = 39, а поле длина ³ 3. Поле строка содержит в себе имя зоны AppleTalk по умолчанию, которая должна использоваться для данного пользователя.

5.40.


Атрибут CHAP-Challenge

Этот атрибут содержит сообщение CHAP Challenge, посланное сервером NAS в рамках диалога с пользователем CHAP PPP (Challenge-Handshake Authentication Protocol). Атрибут используется только в пакетах Access-Request. Если значение вызова CHAP содержит 16 октетов, оно может быть помещено в поле аутентификатора запроса, применение данного атрибута тогда уже не нужно. Формат записи атрибута показан на Рисунок .3. Поле тип = 60, а поле длина ³ 7. Поле строка содержит сообщение CHAP Challenge.

5.41. Атрибут NAS-Port-Type

Этот атрибут определяет тип физического порта NAS, где аутентифицируется пользователь. Атрибут может использоваться вместо или в добавление к атрибуту NAS-Port (5). Атрибут используется только в пакетах Access-Request. Атрибут NAS-Port (5) или NAS-Port-Type или оба должны применяться в пакетах Access-Request, если NAS различает порты. Формат записи атрибута показан на Рисунок .6. Поле тип = 61, а поле длина =6.
Поле значение имеет 4 октета. "Виртуальный" (в таблице 7) относится к соединению с NAS через некоторый транспортный протокол. Например, если пользователь осуществил удаленный доступ (telnet) в NAS, для того чтобы аутентифицировать себя как внешнего пользователя, запрос Access-Request может включать атрибут NAS-Port-Type = Virtual в качестве подсказки серверу RADIUS, что пользователь не является физическим портом.

Пример экспортного объединения большого числа AS



Рисунок .30. Пример экспортного объединения большого числа AS.

На Рисунок 30 показан пример экспортного объединения. В этом примере, AS1 и AS2 представляют собой объединение и оповещают окружающий мир только о менее специфических префиксах 128.8.0.0/15, обмениваясь друг с другом более специфическими префиксами. Эта форма объединения полезна, когда некоторые компоненты находятся внутри AS1, а некоторые в AS2.

Когда агрегатируется набор маршрутов, предполагается экспортировать только агрегатные маршруты и блокировать экспорт более специфичных префиксов вне границы объединения, чтобы удовлетворить определенной политике и топологическим ограничениям (напр., компонента со многими интерфейсами (multi-homed)) часто необходимо экспортировать некоторые компоненты. Атрибут export-comps эквивалентен фильтру RPSL, который соответствует более специфичным префиксам. Если этот атрибут опущен, более специфические префиксы не экспортируются за пределы границы объединения. Заметим, что, фильтр export-comps содержит неявный оператор "AND" по отношению более специфичным префиксам объединения.

На Рисунок 31 показан пример экспортного объединения. В этом примере, более специфические префиксы 128.8.8.0/24 экспортируются из AS1 в дополнение к объединению. Это полезно, когда 128.8.8.0/24 является многопортовым узлом, связанным с другими AS.

route:

128.8.0.0/15

origin:

AS1

components:

{128.8.0.0/15^-}

aggr-mtd:

outbound AS-ANY

export-comps:

{128.8.8.0/24}



Пример объекта mntner



Рисунок 2. Пример объекта mntner.

Атрибуты descr, tech-c, admin-c, remarks, notify, mnt-by, changed и source являются атрибутами всех классов RPSL. Их синтаксис, семантика, а также статус mandatory (обязательный), optional (опционный), multi-valued (многозначный), или однозначный те же что и для всех классов RPSL. Единственным исключением является атрибут admin-c, который является обязательным для класса aut-num.

3.2. Класс person

Класс person используется для описания информации о людях. Хотя он не описывает маршрутную политику, его описание здесь приводится, так как многие объекты политики делают ссылки на конкретных людей. Класс person был впервые описан в [15].

Атрибуты класса person представлены на Рисунок .3 Атрибут person представляет собой полное имя человека. Атрибуты phone и fax-no имеют следующий синтаксис:

phone: +<country-code> <city> <subscriber> [ext. <extension>]

Например:

phone: +31 20 12334676

Атрибут

Значение

Тип

Person

<free-form>

обязательный, однозначный

nic-hdl

<nic-handle>

обязательный, однозначный, ключ класса

address

<free-form>

обязательный, многозначный

phone

См. описание в тексте

обязательный, многозначный

fax-no

То же что и phone

опционный, многозначный

e-mail

<email-address>

обязательный, многозначный



Пример объекта person



Рисунок .4. Пример объекта person.

3.3. Класс role

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

Атрибуты класса role показаны на Рисунок .5. Атрибуты лиц nic-hdl и классы role используют совместно одно и то же пространство имен. Атрибут trouble объекта role может содержать дополнительную контактную информацию, которая может быть использована при возникновении проблемы в любом объекте, который ссылается на данный объект role. На Рисунок .6 показан пример объекта role.

Атрибут

Значение

Тип

Role

<free-form>

обязательный, однозначный

nic-hdl

<nic-handle>

обязательный, однозначный, ключ класса

trouble

<free-form>

опционный, многозначный

address

<free-form>

обязательный, многозначный

phone

see description in text

обязательный, многозначный

fax-no

same as phone

опционный, многозначный

e-mail

<email-address>

обязательный, многозначный



Пример объекта role



Рисунок .6. Пример объекта role.

4. Класс route

Каждый маршрут interAS (называемый также междоменным маршрутом), начинающийся в AS, специфицируется с помощью объекта route. Атрибуты класса route представлены на Рисунок .7. Атрибут route представляет собой адресный префикс маршрута, а атрибут origin является номером AS, где этот маршрут начинается. Пара атрибутов route и origin являются ключом класса.

На Рисунок .8 представлены примеры четырех объектов route. Заметим, что последние два объекта route имеют один и тот же адресный префикс 128.8.0.0/16. Однако они являются различными объектами route, так как они начинаются в разных AS (то есть они имеют разные ключи).

Атрибут

Значение

Тип

Route

<address-prefix>

обязательный, однозначный, ключ класса

Origin

<as-number>

обязательный, однозначный, ключ класса

member-of

список <route-set-names>

см. раздел 5

опционный, многозначный

Inject

см. раздел 8

опционный, многозначный

Components

см. раздел 8

опционный, однозначный

aggr-bndry

см. раздел 8

опционный, однозначный

aggr-mtd

см. раздел 8

опционный, однозначный

export-comps

см. раздел 8

опционный, однозначный

holes

см. раздел 8

опционный, многозначный



Пример политики с использованием rp-атрибута community



Рисунок .28. Пример политики с использованием rp-атрибута community.



Пример реализации алгоритма "расширяющееся дерево"



Рисунок 4.1.1.4.7. Пример реализации алгоритма "расширяющееся дерево"


Некоторые современные мосты используют так называемую маршрутизацию отправителя (source routing). Такая маршрутизация предполагает, что отправитель знает, находится ли адресат в пределах локальной сети и может оптимально определить путь доставки. При посылке кадра другой сети отправитель устанавливает старший бит своего адреса равным единице. Одновременно в заголовке кадра прописывается весь маршрут. Каждой сети присваивается 12-битовый идентификатор, а каждому мосту ставится в соответствие 4-битовый код, уникальный в контексте данной сети. Это означает, что мосты в пределах одной сети должны иметь разные идентификаторы, но их коды могут совпадать, если они находятся в разных сетях. Мост рассматривает только кадры с единицей в старшем бите адреса места назначения. Для этих кадров просматриваются коды сети в списке, записанном в заголовке. Если в списке содержится код, совпадающий с тем, который характеризует сеть, где находится мост, кадр переадресуется в эту сеть. Реализация алгоритма может осуществляться программно или аппаратно. Если путь до места назначения неизвестен, отправитель генерирует специальный пакет, посылаемый широковещательно (discovery frame) и достигающий всех мостов и всех субсетей. Когда приходит отклик от адресата, мосты записывают его идентификатор, а первичный отправитель фиксируют маршрут до адресата. Данный алгоритм достаточно прост, но сопряжен с лавинным размножением "исследовательских" пакетов особенно в случае, когда смежные сети соединяются через несколько мостов/переключателей.

Маршрутизатор отличается от переключателя тем, что поддерживает хотя бы один протокол маршрутизации. Существуют внутренние и внешние протоколы маршрутизации. Если маршрутизатор осуществляет связь данной автономной системы с другими автономными системами, его называют пограничным (border). Маршрутизатор же, который имеет только один внешний канал связи, в литературе часто называют gateway (входной порт сети). Любой маршрутизатор может поддерживать в любой момент только один внутренний и один внешний протокол маршрутизации, выбор этих протоколов осуществляет администратор сети из имеющегося списка. Маршрутизаторы представляют собой наиболее сложные сетевые устройства. Главным достоинством маршрутизаторов в локальной сети является ограничение влияния потоков широковещательных сообщений.

В последнее время заметное распространение получил гибрид маршрутизатора и моста – brouter. Некоторые протоколы (например, NetBIOS) не допускают маршрутизации. Когда необходимо использовать такие протоколы совместно с TCP/IP, необходим brouter. Широко используются такие приборы в сетях Token Ring.

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

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



Пример резервирования FF (Fixed-Filter)



Рисунок 4.4.9.6.4. Пример резервирования FF (Fixed-Filter)



Пример резервирования SE (Shared-Explicit)



Рисунок 4.4.9.6.5. Пример резервирования SE (Shared-Explicit)

Приведенные примеры предполагают, что информационные пакеты от S1, S2 и S3 маршрутизируются через оба выходных интерфейса. Нижняя часть Рисунок 4.4.9.6.2 показывает еще одно предположение о маршрутизации: информационные пакеты от S2 и S3 не переадресуются интерфейсу IВ, напр., из-за того что сеть обеспечивает более короткий путь для пакетов отправителя к R1.



Пример резервирования WF (Wildcard-Filter)



Рисунок 4.4.9.6.3. Пример резервирования WF (Wildcard-Filter)

На Рисунок 4.4.9.6.4 проиллюстрирован стиль резервирования FF (Fixed-Filter). Для каждого выходного интерфейса, имеется отдельное резервирование для каждого запрошенного источника, но это резервирование будет общим для всех получателей, которые послали запрос. Дескрипторы для получателей S2 и S3, полученные через выходные интерфейсы IВ и IГ, вкладываются в пакеты запросов, направляемых предыдущему узлу (IБ). С другой стороны, три различных дескриптора потоков, специфицирующих отправителя S1, объединяются в один запрос FF( S1{4B} ), который посылается предыдущему узлу (IА).

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



Пример RTP сети с оконечными системами, смесителями и трансляторами



Рисунок 4.4.9.2.3 Пример RTP сети с оконечными системами, смесителями и трансляторами


Некоторый набор смесителей и трансляторов представлен на Рисунок 4.4.9.2.3. Здесь показано их влияние на SSRC и CSRC-идентификаторы. Оконечные системы обозначены символами ES и выделены желтым цветом. Трансляторы обозначены буквами TRS (на рисунке овалы голубого цвета) и смесители обозначены как MUX (прямоугольники сиреневого цвета). Запись "M1:13(1,17)" обозначает пакет отправленный смесителем MUX1, который идентифицируется случайным значением SSRC 13 и двумя CSRC-идентификаторами 1 и 17, скопированными с SSRC-идентификаторов пакетов оконечных систем ES1 и ES2.

Последовательное включение смесителей

В RTP-сессии могут быть задействованы несколько смесителей и трансляторов, как это показано на Рисунок 4.4.9.2.3. Если два смесителя включены последовательно, так как MUX2 и MUX3, пакеты полученные смесителем могут быть уже объединены и включать CSRC-список со многими идентификаторами. Cмеситель (MUX3) должен формировать CSRC-список для исходящих пакетов, используя CSRC-идентификаторы уже смешанных входных пакетов (выход MUX2) и SSRC-идентификаторы несмешанных входных пакетов, поступивших от ES9 (E:36). Это отмечено на рисунке для выходных пакетов смесителя MUX3 как M3:99(9,11,36). Если число идентификаторов в списке CSRC превышает 15, остальные не могут быть туда включены.

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

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

Не приемлемо также получать идентификаторы SSRC путем простого обращения к функции random() без тщательной инициализации.


Так как идентификаторы выбраны случайным образом, существует малая, но конечная вероятность того, что два или более источников выберут одно и то же число. Столкновение более вероятно, если все источники стартуют одновременно. Если N число источников, а L длина идентификатора (в нашем случае, 32 бита), вероятность того, что два источника независимо выберут одно и то же значение (для больших N [8]) составляет 1 - exp(-N2 / 2(L+1)). Для N=1000, вероятность примерно равна 10-4.
Типовое значение вероятности столкновения много меньше худшего случая, рассмотренного выше. Рассмотрим случай, когда новый источник подключается к RTP-сессии, в которой все остальные источники уже имеют уникальные идентификаторы. Если N равно числу источников, а L длина идентификатора, вероятность столкновения равна N / 2L. Для N=1000, вероятность составит около 2*10-7.
Вероятность столкновения уменьшается еще больше в случае, когда новый источник получает пакеты других участников до того, как передаст свой первый пакет. Если новый источник отслеживает идентификаторы других участников, он легко может устранить вероятность конфликта.
Преодоление столкновений и детектирование петель
Хотя вероятность столкновения идентификаторов SSRC довольно мала, все RTP реализации должны быть готовы обнаруживать столкновения и предпринимать адекватные меры для их преодоления. Если источник обнаруживает в какой-либо момент, что другой источник использует тот же идентификатор SSRC, он посылает пакет RTCP BYE для старого идентификатора и выбирает новый. Если получатель обнаруживает, что два других источника имеют равные идентификаторы (столкновение), он может воспринимать пакеты от одного и игнорировать от другого до тех пор, пока это не будет зарегистрировано отправителями или CNAME.
Так как идентификаторы уникальны, они могут использоваться для детектирования петель, которые могут создаваться смесителем или транслятором. Петля приводит к дублированию данных и управляющей информации:
Транслятор может некорректно переадресовать пакет некоторой мультикастинг-группе, откуда этот пакет получен.


Это может быть сделано непосредственно или через цепочку трансляторов. В этом случае один и тот же пакет появится несколько раз, приходя от разных сетевых источников.
Два транслятора некорректно поставленные в параллель, т.е., с одними и теми же мультикастными группами на обеих сторонах будут направлять пакеты от одной мультикастной группы к другой. Однонаправленные трансляторы могут создать две копии; двунаправленные трансляторы могут образовать петлю.
Смеситель может замкнуть петлю путем посылки пакета по адресу, откуда он был получен. Это может быть выполнено непосредственно, через смеситель или через транслятор.
Источник может обнаружить, что его собственный пакет движется по кругу, или что пакеты других источников осуществляют циклическое движение.
Оба вида петель и столкновения приводят к тому, что пакеты приходят с тем же самым SSRC-идентификатором, но с разными транспортными адресами, которые могут принадлежать оконечной или какой-то промежуточной системе. Следовательно, если источник меняет свой транспортный адрес, он должен также выбрать новый SSRC-идентификатор с тем, чтобы ситуация не была интерпретирована, как зацикливание. Петли или столкновения, происходящие на дальней стороне транслятора или смесителя, не могут быть детектированы с использованием транспортного адреса источника, если все копии пакетов идут через транслятор или смеситель. Однако, столкновения могут быть детектированы, когда фрагменты двух RTCP SDES пакетов содержат равные SSRC-идентификаторы, но разные коды CNAME (см. описание протокола RTCP).
Для того чтобы детектировать и устранять конфликты, реализации RTP должны содержать алгоритм, аналогичный описанному ниже. Он игнорирует пакеты от нового источника, которые входят в противоречие с работающим источником. Алгоритм разрешает конфликты с SSRC-идентификаторами участников путем выбора нового идентификатора и посылки RTCP BYE для старого. Однако, когда столкновение вызвано зацикливанием собственных пакетов участников сессии, алгоритм выбирает новый идентификатор только раз и после этого игнорирует пакеты от транспортного адреса, вызвавшего зацикливание.


Это требуется для того, чтобы избежать потока пакетов BYE.
Этот алгоритм зависит от равенства транспортных адресов для RTP и RTCP пакетов источника. Алгоритм требует модификации приложений, которые не отвечают этому ограничению.
Этот алгоритм требует наличия таблицы транспортных адресов источников, упорядоченных по их идентификаторам. В таблицу заносятся адреса, откуда данный идентификатор был впервые получен. Каждый SSRC или CSRC идентификатор, полученный с информационным или управляющим пакетом ищется в этой таблице, для того чтобы корректно обработать полученные данные. Для управляющих пакетов каждый элемент с его собственным SSRC, например, фрагмент SDES, требует отдельного просмотра. SSRC в сообщениях-отчетах составляют исключение. Если SSRC или CSRC не найдены, создается новая запись в таблице. Эти записи в таблице удаляются, когда приходит пакет RTCP BYE с соответствующим кодом SSRC, или когда достаточно долго не приходит вообще никаких пакетов.
Для того чтобы отслеживать зацикливание собственных пакетов участников, необходимо также завести отдельный список транспортных адресов источников, которые считаются конфликтными. Заметим, что это должен быть короткий список, обычно пустой. Каждый элемент этого списка хранит адрес источника и время, когда был получен последний конфликтный пакет. Элемент может быть удален из списка, когда за время 10 периодов посылки RTCP сообщений-отчетов не прибыло ни одного конфликтного пакета.
Предполагается, что собственные идентификаторы и состояния участников записаны в таблицу идентификаторов источников.
IF SSRC или CSRC-идентификатор не найден в таблице идентификаторов источников:
THEN создать новую запись и внести туда транспортный адрес источника и SSRC или

CSRC вместе с кодом состояния.

CONTINUE (продолжить) обычную процедуру обработки.

Идентификатор найден в таблице

IF транспортный адрес источника из пакета совпадает с одним из записанных в таблице:

THEN CONTINUE Продолжить обычную процедуру обработки.

Обнаружено столкновение идентификаторов или зацикливание



IF идентификатор источника не совпадает с собственным идентификатором участника:

THEN IF идентификатор источника совпадает с тем, что содержится в фрагменте RTCP SDES содержащем элемент CNAME, который отличается от CNAME из рекорда таблицы:

THEN (опционно) Случилось столкновение посторонних идентификаторов.

ELSE (опционно) Случилось зацикливание.

ABORT Прервать обработку информационного или управляющего пакета.

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

IF транспортный адрес найден в списке конфликтных адресов:

THEN IF идентификатор источника не найден во фрагменте RTCP SDES, содержащем CNAME, или если CNAME принадлежит участнику:

THEN (опционно) случилось зацикливание собственного трафика.

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

ABORT (прервать) обработку информационного или управляющего пакета.

Зафиксировать факт столкновения.

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

Послать пакет RTCP BYE с идентификатором SSRC.

Выбрать новый идентификатор.

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

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


Это должно уменьшить лишний трафик. Однако, в крайних случаях, где смеситель или транслятор не прерывают зацикливание, может быть необходимо для оконечных систем прервать передачу.
Когда необходимо шифрование RTP или RTCP, все октеты будут инкапсулированы в одну дейтограмму нижележащего уровня и зашифрованы как единое целое. Для RTCP в начало последовательности перед шифрованием добавляется 32-битное случайное число, чтобы предотвратить возможные атаки. В случае RTP никаких префиксов не требуется, так как порядковый номер и временная метка и без того являются случайными числами.
Алгоритмом шифрования по умолчанию является DES (Data Encryption Standard), работающий в режиме CBC (Cipher Block Chaining), как это описано в RFC 1423 [9], за исключением того, что используется заполнение кратное 8 октетам. Инициализационный вектор равен нулю, так как для RTP-заголовка используются случайные числа. Более подробно о векторах инициализации можно прочесть в [10]. Приложения, которые используют шифрование должны поддерживать алгоритм DES в режиме CBC. Этот метод выбран потому, что он показал на практике свою эффективность при работе с аудио и видео приложениями в Интернет. Возможно применение и других криптографических средств.
В качестве альтернативы шифрованию на уровне RTP, можно определить дополнительные типы поля данных для шифрованных полей данных в профайлах. Этот метод позволяет шифровать только данные, в то время как заголовки остаются незашифрованными. Это может оказаться полезным для реализации шифрования и дешифрования.
Для обеспечения демультиплексирования RTP полагается на нижележащий протокольный уровень. Для UDP и сходных с ним протоколов, RTP использует четные номера портов, а соответствующие RTCP-потоки используют нечетные номера портов. Если приложению предлагается использовать нечетный номер RTP-порта, этот номер должен быть заменен на ближайший четный меньше исходного.
Информационные RTP-пакеты не имеют поля длины или каких-либо других средств ограничения размеров пакета, по этой причине RTP полагается на нижележащий протокол при задании размера поля данных.


Максимальная длина RTP- пакетов ограничена размером используемых транспортных пакетов (например, UDP).
Если RTP-пакеты переносятся посредством протокола, который поддерживает поточный метод передачи, должен быть определен механизм вложения. Механизм вложения должен быть детализован и в случае, когда транспортный протокол использует в поле данных заполнители.
Механизм вложения может быть определен в профайле даже в случае, когда для транспортировки RTP используется не поточный протокол, это позволяет укладывать несколько RTP-пакетов в одну дейтограмму транспортного протокола (например, UDP). Передача нескольких RTP-пакетов в одном транспортном уменьшает издержки, связанные с заголовком и может упростить синхронизацию различных потоков.
Константы, определяющие тип данных (PT) RTP-пакета, задаются профайлом а не самим протоколом. Однако, значение октета RTP-заголовка, который содержит бит(ы) маркера не должно ни при каких обстоятельствах равняться 200 и 201 (десятичные), для того чтобы отличить RTP-пакеты от RTCP-пакетов типа SR и RR.
Использование протокола RTP в различных приложениях может предъявлять различные требования. Адаптация протокола к этим требованиям осуществляется путем выбора определенных параметров, использования различных расширений (см. Рисунок 4.4.9.2.2) или путем вариации формата на основе профайлов. Типовое приложение использует только один профайл. Спецификация формата поля данных определяет то, например, как, закодированный видеосигнал (H.261) должен переноситься RTP-пакетами.
В рамках RTP-стандарта определены следующие элементы поля данных (этот список не следует рассматривать, как окончательный):
Заголовок поля данных RTP. Октет RTP заголовка, содержащий маркер тип поля данных, может быть переопределен с помощью профайла (например, можно изменить число маркерных битов).
Типы поля данных. Профайл обычно определяет набор форматов поля данных (напр., типов кодирования исходных данных) и соответствие между этими форматами и кодами типа поля данных.


Для каждого описанного типа поля данных должна быть определена частота временных меток.
Дополнения к заголовку RTP. К стандартному RTP-заголовку могут быть добавлены новые поля, расширяющие функциональность приложения.
Расширения заголовка RTP. Структура содержимого первых 16 бит расширения RTP-заголовка должна быть определена профайлом (см. Рисунок 4.4.9.2.2).
Безопасность. Профайл может специфицировать, какие услуги и алгоритмы безопасности должно обеспечить приложение.
Установка соответствия между строкой и ключом. Профайл может специфицировать, какому ключу шифрования соответствует введенный пользователем пароль.
Нижележащий протокол. Определяется нижележащий транспортный протокол, который служит для пересылки RTP-пакетов.
Транспортное соответствие. Соответствие RTP и RTCP адресам транспортного уровня, например, UDP-портам.
Инкапсуляция. Инкапсуляция RTP-пакетов может быть определена для того, чтобы позволить транспортировку нескольких RTP-пакетов в одной дейтограмме нижележащего протокола.
Не предполагается, что для каждого приложения требуется свой профайл. В пределах одного класса приложений целесообразно использовать расширения одного и того же профайла. Простое расширение, такое как введение дополнительного типа поля данных или нового типа RTCP-пакета, может быть выполнено путем регистрации их через комитет по стандартным числам Интернет и публикации их описаний в приложении к профайлу.
Алгоритмы работы отправителя и получателя RTP-пакетов описаны в RFC-1889 на примере кодов, написанных на языке СИ.
Нижеприведенные определения заимствованы целиком из RFC, ссылка на который приведена в начале данного раздела. Все цифра представлены в формате, где первым является старший октет. Предполагается, что битовые поля размещаются без заполнителей в том же порядке, что и октеты.
/*

* rtp.h -- Файл заголовка RTP (RFC 1889)

*/

#include <sys/types.h>

/*

* Нижеприведенные определения предполагают 32-битовое представление, а в случаях

* 16- или 64-битового представлений необходимы соответствующие модификации.



*/

typedef unsigned char u_int8;

typedef unsigned short u_int16;

typedef unsigned int u_int32;

typedef short int16;

/*

* Текущая версия протокола.

*/

#define RTP_VERSION 2

#define RTP_SEQ_MOD (1<<16)

#define RTP_MAX_SDES 255 /* максимальная длина текста для SDES */

typedef enum {

RTCP_SR = 200,

RTCP_RR = 201,

RTCP_SDES = 202,

RTCP_BYE = 203,

RTCP_APP = 204

} rtcp_type_t;

typedef enum {

RTCP_SDES_END = 0,

RTCP_SDES_CNAME = 1,

RTCP_SDES_NAME = 2,

RTCP_SDES_EMAIL = 3,

RTCP_SDES_PHONE = 4,

RTCP_SDES_LOC = 5,

RTCP_SDES_TOOL = 6,

RTCP_SDES_NOTE = 7,

RTCP_SDES_PRIV = 8

} rtcp_sdes_type_t;

/*

* Заголовок RTP-пакета

*/

typedef struct {

unsigned int version:2; /* версия протокола */

unsigned int p:1; /* флаг заполнителя */

unsigned int x:1; /* Флаг расширения заголовка */

unsigned int cc:4; /* число CSRC */

unsigned int m:1; /* Бит маркера */

unsigned int pt:7; /* тип поля данных */

u_int16 seq; /* номер по порядку */

u_int32 ts; /* временная метка */

u_int32 ssrc; /* источник синхронизации */

u_int32 csrc[1]; /* опционный список CSRC */

} rtp_hdr_t;

/*

* Общее слово RTCP-заголовка

*/

typedef struct {

unsigned int version:2; /* версия протокола */

unsigned int p:1; /* флаг заполнителя */

unsigned int count:5; /* варьируется в зависимости от типа пакета */

unsigned int pt:8; /* тип пакета RTCP */

u_int16 length; /* Длина пакета в словах */

} rtcp_common_t;

/*

* Маска версии, бита заполнителя и типа пакета

*/

#define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)

#define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)

/*

* Блок отчета о приеме

*/

typedef struct {

u_int32 ssrc; /* Источник, для которого составлен отчет */

unsigned int fraction:8; /* доля потерянных пакетов с момента последнего SR/RR */

int lost:24; /* полное число потерянных пакетов */

u_int32 last_seq; /* номер последнего полученного пакета */

u_int32 jitter; /* разброс времени прихода пакетов */

u_int32 lsr; /* последний SR-пакет от этого источника */



u_int32 dlsr; /* задержка с момента последнего SR пакета */

} rtcp_rr_t;

/*

* элемент SDES

*/

typedef struct {

u_int8 type; /* тип элемента (rtcp_sdes_type_t) */

u_int8 length; /* Длина элемента (в октетах) */

char data[1]; /* текст */

} rtcp_sdes_item_t;

/*

* One RTCP packet

*/

typedef struct {

rtcp_common_t common; /* общий заголовок */

union {

/* sender report (SR) */

struct {

u_int32 ssrc; /* Отправитель, генерирующий этот отчет */

u_int32 ntp_sec; /* временная метка NTP */

u_int32 ntp_frac;

u_int32 rtp_ts; /* временная метка RTP */

u_int32 psent; /* послано пакетов */

u_int32 osent; /* послано октетов */

rtcp_rr_t rr[1]; /* список переменной длины */

} sr;

/* Отчет о приеме (RR) */

struct {

u_int32 ssrc; /* приемник, формирующий данный отчет */

rtcp_rr_t rr[1]; /* список переменной длины */

} rr;

/* описание источника (SDES) */

struct rtcp_sdes {

u_int32 src; /* первый SSRC/CSRC */

rtcp_sdes_item_t item[1]; /* список элементов SDES */

} sdes;

/* BYE */

struct {

u_int32 src[1]; /* список источников */

/* can't express trailing text for reason */

} bye;

} r;

} rtcp_t;

typedef struct rtcp_sdes rtcp_sdes_t;

/*

* Информация состояния источников

*/

typedef struct {

u_int16 max_seq; /* наибольший зарегистрированный номер */

u_int32 cycles; /* shifted count of seq. number cycles */

u_int32 base_seq; /* основной порядковый номер */

u_int32 bad_seq; /* последний 'плохой' порядковый номер + 1 */

u_int32 probation; /* sequ. packets till source is valid */

u_int32 received; /* пакетов получено */

u_int32 expected_prior; /* пакет, ожидаемый в последнем интервале */

u_int32 received_prior; /* пакет, полученный за последний интервал */

u_int32 transit; /* относительное время передачи для предыдущего пакета */

u_int32 jitter; /* оценка временного разброса */

/* ... */

} source;

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


Ограниченная проверка допустима только для нового источника:
В поле версии RTP должен быть записан код 2.

Тип поля данных должен быть из числа известных, в частности он не должен быть равным SR или RR.

Если бит P=1, тогда последний октет пакета должен содержать правильное число октетов, в частности оно должно быть меньше полной длины пакета минус размер заголовка.

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

Длина пакета должна согласовываться с CC и типом поля данных (если длина поля данных известна).
Последние три проверки достаточно сложны и не всегда возможны. Если SSRC-идентификатор в пакете соответствует одному из полученных ранее, тогда пакет вероятно корректен и следует проверить то, что его порядковый номер лежит в нужном диапазоне. Если SSRC-идентификатор ранее не встречался, тогда данный пакет может рассматриваться некорректным до тех пор, пока не будет получено несколько таких последовательно пронумерованных пакетов.
Программа update_seq, приведенная ниже гарантирует, что источник декларирован правильно после получения MIN_SEQUENTIAL последовательно пронумерованных пакетов. Она также проверяет номера пакетов SEQ и актуализует состояние источника пакетов в структуре, на которую указывает S.
Когда новый источник дает о себе знать впервые (т.е. его SSRC-идентификатор отсутствует в таблице), и для описания его состояния выделено место в памяти, S->probation должно быть сделано равным числу последовательных пакетов, которые должны быть зарегистрированы до того, как источник будет объявлен легальным (параметр MIN_SEQUENTIAL ), а переменной s->max_seq присваивается значение SEQ-1. s->probation помечает источник как еще нелегальный, так что описание его состояния может быть выброшено после короткой выдержки.
После того как источник признан легальным, номер по порядку считается корректным, если он не больше чем на MAX_DROPOUT впереди S->max_seq и не больше на MAX_MISORDER после.


В противном случае возвращается нуль, что означает неудачу проверки, а плохой последовательный номер запоминается. Если номер очередного полученного пакета имеет следующий номер по порядку, то он рассматривается как начало новой последовательности (возможно источник рестартовал). Так как при этом теряется много циклов, статистика потерь пакетов сбрасывается.
Приведенные типовые значения параметров базируются на максимальном времени сбоя нумерации равном 2 секундам при скорости 50 пакетов/сек и времени таймаута 1 минута. Параметр таймаута MAX_DROPOUT должен соответствовать небольшой доле от 16-битового диапазона нумерации. Таким образом, после рестарта новый номер пакета с большой вероятностью не должен попасть в допустимый диапазон.
void init_seq(source *s, u_int16 seq)

{

s->base_seq = seq - 1;

s->max_seq = seq;

s->bad_seq = RTP_SEQ_MOD + 1;

s->cycles = 0;

s->received = 0;

s->received_prior = 0;

s->expected_prior = 0;

/* other initialization */

}

int update_seq(source *s, u_int16 seq)

{

u_int16 udelta = seq - s->max_seq;

const int MAX_DROPOUT = 3000;

const int MAX_MISORDER = 100;

const int MIN_SEQUENTIAL = 2;

*

* Источник нелегален до тех пор, пока не будет получено MIN_SEQUENTIAL пакетов

* с последовательно нарастающими номерами.

*/

if (s->probation) {

/* пакет соответствует последовательности */

if (seq == s->max_seq + 1) {

s->probation--;

s->max_seq = seq;

if (s->probation == 0) {

init_seq(s, seq);

s->received++;

return 1;

}

} else {

s->probation = MIN_SEQUENTIAL - 1;

s->max_seq = seq;

}

return 0;

} else if (udelta < MAX_DROPOUT) {

/* в порядке, с допустимым зазором */

if (seq < s->max_seq) {

/*

* Порядковый номер переполнен – начинаем новый 64K цикл.

*/

s->cycles += RTP_SEQ_MOD;

}

s->max_seq = seq;

} else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) {

/* порядковый номер изменился слишком сильно */

if (seq == s->bad_seq) {

/*

* Два последовательных пакета – предполагается, что другая сторона рестартовала, не



* предупредив нас об этом. re-sync (т.е., считаем, что получили первый пакет).

*/

init_seq(s, seq);

}

else {

s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1);

return 0;

}

} else {

/* задублированные пакеты или пакеты с перепутанным порядком прихода */

}

s->received++;

return 1;

}

Проверка корректности может быть и жестче, требуя более двух пакетов с последовательными номерами подряд. Недостатком такого подхода будут трудности, связанные с каналами, где вероятность потери пакета велика. Однако, так как проверка корректности заголовка RTCP-пакета достаточно строга, можно ограничиться требованием двух последовательных информационных пакетов. Если начальная потеря данных в течение нескольких секунд приемлема, приложение может выбрасывать все информационные пакеты до тех пор, пока не будет получен от источника корректный RTCP-пакет.
В зависимости от приложения и используемого кодирования для проверки можно использовать дополнительную информацию о структуре поля данных. Например, для типов данных, где используются временные метки, можно с некоторой точностью предсказывать очередное значение метки на основании знания предыдущей и разности номеров пакетов.
Для того чтобы посчитать частоту потерь пакетов, нужно знать ожидаемое и реально полученное число пакетов для каждого из источников. Число полученных пакетов получается простым их подсчетом с учетом возможного дублирования и запаздывания. Ожидаемое число пакетов может быть подсчитано получателем как разность между наибольшим порядковым номером пакета (s->max_seq) и номером первого пакета в последовательности (S->base_seq). При этом нужно учитывать то, что номера имеют 16 бит, и по этой причине могут переполниться (число переполнений хранится в переменной s->cycles).
extended_max = s->cycles + s->max_seq;

expected = extended_max - s->base_seq + 1;

Число потерянных пакетов определяется как разность между ожидаемым и реально полученным числом пакетов:
lost = expected - s->received;



Доля потерянных пакетов за отчетный период (с момента посылки предыдущего SR или RR пакета) вычисляется из разности ожидаемого и реально полученного числа пакетов за отчетный период, где expected_prior и received_prior представляют собой значения, записанные в момент подготовки предыдущего отчета.:
expected_interval = expected - s->expected_prior;

s->expected_prior = expected;

received_interval = s->received - s->received_prior;

s->received_prior = s->received;

lost_interval = expected_interval - received_interval;

if (expected_interval == 0 || lost_interval <= 0) fraction = 0;

else fraction = (lost_interval << 8) / expected_interval;

Результирующее значение доли равно 8-битовому числу с фиксированной запятой, расположенной слева.
Генерирование псевдослучайных 32-битовых идентификаторов
Ниже приведенная подпрограмма (заимствована из RFC-1889) генерирует псевдослучайные 32-битовые идентификаторы, используя программы MD5, опубликованные в RFC-1321 [11]. Системные программы могут и не присутствовать во всех операционных системах, но они помогают понять, какого рода информация может использоваться.
o getdomainname() ,

o getwd() , или

o getrusage()

"Живые" видео или аудио сигналы могут быть также не плохим источником случайных числе, при этом только следует позаботиться о том, чтобы микрофон не был отключен, а объектив камеры не был закрыт [7].
Использование этой или другой подобной программы предполагает определенную процедуру инициализации, которая нужна для получения первых псевдослучайных чисел. Так как эта программа заметно загружает процессор, ее непосредственное использование для генерации RTCP-периодов нельзя считать приемлемым. Следует заметить, что данная программа выдает один и тот же результат при последовательных вызовах до тех пор, пока не изменится показание системных часов или не будет задано другое значение аргумента type.
/*

* Генерация псевдослучайного 32-битового числа.

*/

#include <sys/types.h> u_long */



#include <sys/time.h> /* gettimeofday() */

#include <unistd.h> /* get..() */

#include <stdio.h> /* printf() */

#include <time.h> /* clock() */

#include <sys/utsname.h> /* uname() */

#include "global.h" /* from RFC 1321 */

#include "md5.h" /* from RFC 1321 */

#define MD_CTX MD5_CTX

#define MDInit MD5Init

#define MDUpdate MD5Update

#define MDFinal MD5Final

static u_long md_32(char *string, int length)

{

MD_CTX context;

union {

char c[16];

u_long x[4];

} digest;

u_long r;

int i;

MDInit (&context);

MDUpdate (&context, string, length);

MDFinal ((unsigned char *)&digest, &context);

r = 0;

for (i = 0; i < 3; i++) {

r ^= digest.x[i];

}

return r;

} /* md_32 */

/*

* Полученный результат - 32- битовое число без знака. Используйте аргумент 'type' если вам

* нужно получить несколько разных величин подряд.

*/

u_int32 random32(int type)

{

struct {

int type;

struct timeval tv;

clock_t cpu;

pid_t pid;

u_long hid;

uid_t uid;

gid_t gid;

struct utsname name;

} s;

gettimeofday(&s.tv, 0);

uname(&s.name);

s.type = type;

s.cpu = clock();

s.pid = getpid();

s.hid = gethostid();

s.uid = getuid();

s.gid = getgid();

return md_32((char *)&s, sizeof(s));

} /* random32 */

Библиография


[1] D. D. Clark и D. L. Tennenhouse, "Architectural considerations for a new generation of protocols," in SIGCOMM Symposium on Communications Architectures и Protocols , (Philadelphia, Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Computer Communications Review, Vol. 20(4), Sept. 1990.
[2] D. E. Comer, Internetworking with TCP/IP , vol. 1. Englewood Cliffs, New Jersey: Prentice Hall, 1991.
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.
[4] Mills, D., "Network Time Protocol Version 3", RFC 1305, UDEL, March 1992.
[5] Reynolds, J., и J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.
[6] Eastlake, D., Crocker, S., и J. Schiller, "Randomness Recommendations for Security", RFC 1750, DEC, Cybercash, MIT, December 1994.
[7] J.-C. Bolot, T. Turletti, и I. Wakeman, "Scalable feedback control for multicast video distribution in the internet," in SIGCOMM Symposium on Communications Architectures и Protocols, (London, England), pp. 58--67, ACM, Aug. 1994.
[8] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, и Identifiers", RFC 1423, TIS, IAB IRTF PSRG, IETF PEM WG, February 1993.
[9] V. L. Voydock и S. T. Kent, "Security mechanisms in high-level network protocols," ACM Computing Surveys, vol. 15, pp. 135--171, June 1983.
[10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science и RSA Data Security, Inc., April 1992.
[11] S. Stubblebine, "Security services for multimedia conferencing," in 16th National Computer Security Conference , (Baltimore, Maryland), pp. 391--395, Sept. 1993.
[12] S. Floyd и V. Jacobson, "The synchronization of periodic routing messages," IEEE/ACM Transactions on Networking , vol. 2, pp. 122-136, April 1994.
<


Пример составного пакета RTCP (#: SSRC/CSRC)



Рисунок 4.4.9.3.1. Пример составного пакета RTCP (#: SSRC/CSRC)


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

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

Трафик управления должен быть ограничен малой долей полной полосы пропускания сессии: настолько малой, чтобы не нанести ущерба основной функции транспортного протокола – переносу информации. Предлагается, чтобы доля трафика сессии, выделенная на RTCP была фиксирована на уровне не более 5%. Параметры, определяющие трафик, должны быть идентичными для всех участников, так чтобы они могли корректно вычислить период рассылки отчетов. Эти параметры фиксируются в соответствующем профайле.

Алгоритм вычисления периода рассылки составных RTCP-пакетов включает в себя следующие моменты:

o Отправители коллективно выделяют по крайней мере 1/4 управляющего трафика, так чтобы в сессиях с большим числом получателей и малым числом отправителей новые участники быстро получали cname узлов отправителей.

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


o Интервалы между RTCP-пакетами варьируются случайным образом в пределах [0.5-1.5] от вычисленного значения, с тем чтобы избежать непреднамеренной синхронизации работы участников [3]. Первый RTCP-пакет, посланный после подключения к сессии, также задерживается случайным образом со средним значением, равным половине вычисленного интервала.
o Для того чтобы адаптироваться к количеству пересылаемой контрольной информации, вычисляется среднее значение размера составного пакета для отправляемых и получаемых дейтограмм.
Этот алгоритм может использоваться для сессий, в которых всем участникам позволено посылать данные. В этом случае полоса пропускания сессии зависит от произведения трафика индивидуального отправителя на число участников сессии, а полоса пропускания RTCP должна быть равна 5% от этого значения.
Вычисление периода рассылки RTCP-пакетов зависит от оценки числа узлов, участвующих в сессии. Новые узлы добавляются к этому числу, когда они услышаны и соответствующие записи занесены в таблицы SSRC или CSRC-идентификаторов. Новые записи не рассматриваются, как действующие, до тех пор, пока не будет получено несколько пакетов с новым SSRC. Записи могут быть стерты из таблицы, когда приходит пакет RTCP Bye с соответствующим идентификатором SSRC.
Участник может пометить другой узел как пассивный, или удалить его из списка, если от него не получено RTP или RTCP-пакетов в течение нескольких периодов RTCP-отчетов (пороговое число периодов предлагается сделать равным 5). Это обеспечивает определенную устойчивость против случайной потери пакетов. Все узлы должны вычислить период RTCP-отчетов, чтобы корректно оценить время тайм-аута.
Если зарегистрированный узел помечен как пассивный, он будет оставаться в списках достаточно долго и учитываться при вычислении распределения полосы пропускания для RTCP. Значение тайм-аута предлагается сделать равным 30 минутам. Заметим, что это значение почти в 5 раз больше, чем наибольшая величина периода рассылки RTCP-отчетов, который составляет 2-5 мин.


Данная спецификация определяет несколько элементов описания источника (SDES). Сюда входит CNAME (каноническое имя), Name (персональное имя) и Email (электронный адрес). Спецификация предлагает также средства для определения типа RTCP-пакетов, специфического для конкретного приложения. Приложения должно проявлять определенную осторожность при выделении полосы для любой дополнительной информации, так как это неизбежно вызовет замедление скорости предоставления отчетов и задержит присылку. Рекомендуется, чтобы дополнительная информация индивидуального участника не занимала более 20% полосы, выделенной для RTCP. Более того, даже не предполагается, что все элементы SDES будут включаться каждым приложением. Например, приложение может посылать только CNAME, name и email и не посылать более никакой дополнительной информации. name может быть присвоен более высокий приоритет чем email, так как name будет отображаться пользовательским интерфейсом приложения постоянно, в то время как Email может отображаться только при запросе. При каждой RTCP рассылке, должны посылаться RR- и SDES-пакеты. Последний содержит элемент Cname. Для небольших сессий, работающих с минимальными периодами рассылки, это будет делаться в среднем каждые 5 секунд. Каждая третья рассылка (15 секунд) может содержать один дополнительный элемент в пакете SDES. Семь из восьми раз это будет элемент name, и каждый восьмой раз (2 минуты) это будет элемент Email.
Когда несколько приложений работают одновременно, например, в случае мультимедиа конференции, допускается, чтобы дополнительная информация пересылалась только в рамках одной RTP-сессии. Остальные сессии будут использовать только элемент cname.
RTP-получатели обеспечивают обратную связь контроля качества, используя RTCP пакеты отчетов, которые могут принимать ту или иную форму в зависимости от того, является ли получатель одновременно и отправителем. Единственным различием между формами отчета отправителя (SR) и получателя (rr), помимо кода типа пакета, является то, что отчет отправителя содержит 20-байтовую секцию информации об отправителе.


SR посылается, если узел отправил какие-либо информационные пакеты за время подотчетного периода (с момента отправки предыдущего отчета), в противном случае отправляется пакет RR.
Как SR так и RR-формы включают в себя нуль или более блоков отчетов о приеме, один для каждого источника синхронизации, от которого получатель принял информационные RTP-пакеты с момента последнего отчета. Отчеты не направляются для источников, перечисленных в списке CSRC. Каждый блок отчета о приеме содержит статистику данных, полученных от конкретного источника. Так как в SR или RR-пакет можно поместить максимум 31 блок отчетов, дополнительные RR-пакеты укладываются после исходного SR или RR-пакета.
Пакет отчета отправителя состоит из трех секций (см. Рисунок 4.4.9.3.2), за которыми может следовать четвертая, которая определяется, если необходимо, профайлом. Первая секция – заголовок, имеет 8 октетов. Эта секция содержит следующие поля:
Версия (v): 2 бита
Идентифицирует версию протокола RTP, которая совпадает с версией RTCP-пакетов. Для данной спецификации v=2.
Заполнитель (p): 1 бит
Если бит заполнителя p=1, то этот пакет RTCP содержит некоторые октеты заполнителя после управляющей информации. Последний октет заполнителя содержит число октетов заполнителя. Заполнитель может быть нужен при некоторых алгоритмах шифрования, использующих фиксированные блоки. В составных RTCP-пакетах, заполнитель может быть нужен только последнему пакету, так как составной пакет шифруется как целое.

Пример топологии, где переходной



Рисунок 4.4.11.1а. Пример топологии, где переходной процесс осуществляется медленно, даже при усовершенствовании алгоритма.


В RIP сообщения инкапсулируются в udp-дейтограммы, при этом передача осуществляется через порт 520. В качестве метрики RIP использует число шагов до цели. Если между отправителем и приемником расположено три маршрутизатора (gateway), считается, что между ними 4 шага. Такой вид метрики не учитывает различий в пропускной способности или загруженности отдельных сегментов сети. Применение вектора расстояния не может гарантировать оптимальность выбора маршрута, ведь, например, два шага по сегментам сети ethernet обеспечат большую пропускную способность, чем один шаг через последовательный канал на основе интерфейса RS-232.

Маршрут по умолчанию имеет адрес 0.0.0.0 (это верно и для других протоколов маршрутизации). Каждому маршруту ставится в соответствие таймер тайм-аута и "сборщика мусора". Тайм-аут-таймер сбрасывается каждый раз, когда маршрут инициализируется или корректируется. Если со времени последней коррекции прошло 3 минуты или получено сообщение о том, что вектор расстояния равен 16, маршрут считается закрытым. Но запись о нем не стирается, пока не истечет время "уборки мусора" (2мин). При появлении эквивалентного маршрута переключения на него не происходит, таким образом, блокируется возможность осцилляции между двумя или более равноценными маршрутами. Формат сообщения протокола RIP имеет вид, показанный на Рисунок 4.4.11.2. Поле команда определяет выбор согласно следующей таблице:



Пример топологии, состоящий



Рисунок .22. Пример топологии, состоящий из трех AS: AS1, AS2 и AS3, двух точек обмена: EX1 и EX2 и шести маршрутизаторов (IP[R1]= 1.1.1.1, IP[R2]= 2.2.2.1, IP[R3]= 1.1.1.2, IP[R4]= 1.1.1.3, IP[R5]= 2.2.2.2, IP[R6]= 2.2.2.3).

При описании партнерства используется топология, показанная на Рисунок .22. В этой топологии имеется три автономные системы, AS1, AS2, and AS3; две точки обмена, EX1 и EX2, и шесть маршрутизаторов (R1-R6). Маршрутизаторы соединены с точками обмена. То есть, 1.1.1.1, 1.1.1.2 и 1.1.1.3 являются партнерами друг для друга, а 2.2.2.1, 2.2.2.2 и 2.2.2.3 – также партнеры друг для друга.

Синтаксис спецификации партнерства:

<as-expression> [<router-expression-1>] [at <router-expression-2>] | <peering-set-name>

где <as-expression> является выражением для номеров AS и наборов AS, использующих операторы AND, OR и EXCEPT, а выражения <router-expression-1> и <router-expression-2> являются функциями IP-адресов маршрутизаторов, имен inet-rtr, и имен rtr-set, использующих операторы AND, OR и EXCEPT. Двоичный оператор "EXCEPT" семантически эквивалентен комбинации "AND NOT". То есть "(AS1 OR AS2) EXCEPT AS2" эквивалентно "AS1".

Эта форма идентифицирует всех партнеров между любым локальным маршрутизатором в <router-expression-2> и любыми маршрутизаторами в <router-expression-1> в автономных системах из <as-expression>. Если <router-expression-2> не специфицировано, это по умолчанию предполагает, что все маршрутизаторы локальной AS связаны с AS из <as-expression>.

Если используется <peering-set-name>, партеры перечислены в соответствующем объекте peering-set. Заметим, что объекты peering-set могут быть рекурсивными.

Возможны также многие специальные формы этой общей спецификации партнеров. Ниже приведенные примеры иллюстрируют наиболее общие случаи с использованием атрибута import класса aut-num. В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2.


(1) aut-num: AS1

import: from AS2 1.1.1.2 at 1.1.1.1 accept { 128.9.0.0/16 }
В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3.
(2) aut-num: AS1

import: from AS2 at 1.1.1.1 accept { 128.9.0.0/16 }
В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3, а 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2.
(3) aut-num: AS1

import: from AS2 accept { 128.9.0.0/16 }
В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3.
(4) as-set: AS-FOO

members: AS2, AS3

aut-num: AS1


import: from ASFOO at 9.9.9.1 accept { 128.9.0.0/16 }

В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3, а 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3.
(5) aut-num: AS1


import: from AS-FOO accept { 128.9.0.0/16 }

В следующем примере AS1 импортирует 128.9.0.0/16 из AS3 через маршрутизатор 9.9.9.1
(6) aut-num: AS1

import: from AS-FOO and not AS2 at not 1.1.1.1 accept { 128.9.0.0/16 }
Это связано с тем, что "AS-FOO and not AS2" эквивалентно AS3 и "not 1.1.1.1" эквивалентно 9.9.9.1.
В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3.

(7) peering-set: prng-bar peering: AS1 at 9.9.9.1

peering-set: prng-foo

peering: prng-bar

peering: AS2 at 9.9.9.1
aut-num: AS1

import: from prng-foo accept { 128.9.0.0/16 }

Предлагается несколько примеров для иллюстрации


6. Примеры

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

6.1. Удаленный доступ пользователя на указанную ЭВМ (Telnet)

Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request в UDP пакете серверу RADIUS для пользователя с именем NEMO, подключаемого к порту 3.
Code = 1 (Access-Request)

ID = 0

Request Authenticator = {16-октетное случайное число}

Атрибуты:

User-Name = "NEMO"
User-Password = {16-октетный пароль, дополненный в конце нулями и объединенный операцией XOR с MD5(общий секретный пароль|Request Authenticator)}
NAS-IP-Address = 192.168.1.16

NAS-Port = 3
Сервер RADIUS аутентифицирует NEMO и посылает запрос Access-Accept в UDP пакете серверу NAS, требуя от него организации удаленного доступа пользователя NEMO к ЭВМ с заданным адресом.
Code = 2 (Access-Accept)

ID = 0 (то же самое, что и в Access-Request)

Response Authenticator = {16-октетная контрольная сумма MD-5 кода (2),
id (0), приведенного выше Request Authenticator, атрибутов этого отклика и общего секретного пароля }
Атрибуты:

Service-Type = Login-User

Login-Service = Telnet

Login-Host = 192.168.1.3

6.2. Кадровая аутентификация пользователя посредством CHAP

Сервер NAS с адресом 192.168.1.16 посылает запрос Access-Request в UDP-пакете серверу RADIUS для пользователя с именем VANYA для подключения к порту 20 в рамках протокола PPP. Аутентификация осуществляется посредством CHAP. NAS посылает атрибуты Service-Type и Framed-Protocol в качестве рекомендаций серверу RADIUS воспользоваться PPP, хотя NAS необязательно этому последует.
Code = 1 (Access-Request)

ID = 1
Request Authenticator = {16-октетное случайное число, используется также в вызове CHAP (CHAP challenge)}
Атрибуты:

User-Name = " VANYA"
CHAP-Password = {1 октет идентификатора CHAP, за которым следует 16 октетов CHAP-отклика}
NAS-IP-Address = 192.168.1.16

NAS-Port = 20

Service-Type = Framed-User

Framed-Protocol = PPP
Сервер RADIUS аутентифицирует VANYA и посылает запрос Access-Accept в UDP-пакете серверу NAS, сообщая, что он отрывает PPP-сессию и приписывает адрес пользователю из имеющегося у него списка.


NAS-IP-Address = 192.168.1.16
NAS-Port = 7

State = {Код из пакета Access-Challenge}

Отклик был некорректен, поэтому сервер RADIUS предлагает NAS отклонить попытку входа в систему.

Code = 3 (Access-Reject)
ID = 3 (то же что и в Access-Request)

Response Authenticator = {16-октетов контрольной суммы MD-5 кода (3), ID (3), описанного выше Request Authenticator, атрибутов этого отклика (если таковые имеются) и общего секретного пароля}
Атрибуты:
(отсутствуют, хотя сообщение Reply-Message может быть послано)
На практике, с сервером RADIUS связывается база данных, где хранятся имена пользователей и соответствующие им секретные пароли. Конкретный именованный пользователь должен аутентифицироваться только одним способом. Это уменьшает возможности атаки путем согласования использования наименее безопасного метода аутентификации. Если пользователь нуждается в использовании разных аутентификационных методов в различных ситуациях, тогда следует данному пользователю в каждом из этих вариантов выступать под разными именами.
Пароли должны храниться в местах с ограниченным доступом. Эти данные должны быть доступны только процессам, которые с ними работают.

На Рисунок 32 показаны два



Рисунок .32. Примеры инжекции.

На Рисунок 32 показаны два примера. В первом случае, объединение вводится в два маршрутизатора, каждый из которых устанавливает атрибут прохода dpa по-разному. Во втором случае, объединение формируется только если в маршрутной таблице присутствуют как 128.8.0.0/16 так и 128.9.0.0/16, в отличие от первого случая, когда присутствия лишь одного из них достаточно для ввода (injection).
Атрибут holes перечисляет компоненты адресных префиксов, которые не достижимы через агрегатный маршрут (возможно, что часть адресного пространства не распределена). Атрибут holes полезен для диагностических целей. На Рисунок .32, второй пример имеет дырку, в частности 128.8.8.0/24. Это может быть связано с тем, что клиент менял провайдера и брал для этой цели эту часть адресного пространства.

8.1.1. Взаимодействие с политикой в классе aut-num

О сформированном объединении другие AS оповещаются только в случае, когда экспортная политика AS позволяет передавать объединения маршрутов. Когда объединение сформировано, более специфические префиксы запрещены для экспорта за исключением AS в aggr-bndry и компонент в export-comps.
Если объединение не сформировано, тогда более специфические префиксы объединения могут экспортироваться другим AS, но только если экспортная политика AS допускает это. Другими словами прежде чем маршрут (объединение) будет экспортировано, производится двойная фильтрация, один отбор основан на маршрутных объектах, а другой –на экспортной политике AS.

route: 128.8.0.0/16
origin: AS1
route: 128.9.0.0/16
origin: AS1
route: 128.8.0.0/15
origin: AS1
aggr-bndry: AS1 or AS2 or AS3
aggr-mtd: outbound AS3 or AS4 or AS5
components: {128.8.0.0/16, 128.9.0.0/16}
inject: upon HAVE-COMPONENTS {128.9.0.0/16, 128.8.0.0/16}
aut-num: AS1
export: to AS2 announce AS1
export: to AS3 announce AS1 and not {128.9.0.0/16}
export: to AS4 announce AS1
export: to AS5 announce AS1
export: to AS6 announce AS1