Алгоритм Reverse Path Forwarding
Рисунок 4.4.11.7. Алгоритм Reverse Path Forwarding
При передаче мультимедиа информации используются принципиально другие протоколы маршрутизации. Здесь путь прокладывается от получателя к отправителю, а не наоборот. Это связано с тем, что там при доставке применяется мультикастинговый метод. Здесь, как правило, один отправитель посылает пакеты многим потребителям. При этом важно, чтобы размножение пакета происходило как можно ближе к кластеру адресатов. Такая стратегия иной раз удлинняет маршрут, но всегда снижает результирующую загрузку сети. Смотри описания протоколов
DVMRP и PIM.
В последнее время конфигурирование сетевого оборудования (маршрутизаторов, DNS и почтовых серверов усложнилось нкастолько, что это стало составлять заметную часть издержек при формировании коммуникационного узла. Заметного упрощенияи удешевления маршрутизаторов можно ожидать при внедрении IPv6. Следующим шагом станет внедрение объектно-ориентированного языка описания маршрутной политики RPSL (Routing Policy Specification Language). Здесь конфигурирование маршрутизатора будет осуществляться на основе описанной маршрутной политики.
Теперь немного подробнее о наиболее популярных протоколах маршрутизации - RIP, OSPF, IGRP и BGP-4. Начнем с внутреннего протокола маршрутизации RIP.
Алгоритм шифрования RSA
6.4.2 Алгоритм шифрования RSA
Алгоритм RSA предполагает, что посланное закодированное сообщение может быть прочитано адресатом и только им. В этом алгоритме используется два ключа – открытый и секретный. Данный алгоритм привлекателен также в случае, когда большое число субъектов (N) должно общаться по схеме все-со-всеми. В случае симметричной схемы шифрования каждый из субъектов каким-то образом должен доставить свои ключи всем остальным участникам обмена, при этом суммарное число используемых ключей будет достаточно велико при большом значении N. Применение асимметричного алгоритма требует лишь рассылки открытых ключей всеми участниками, суммарное число ключей равно N.
Сообщение представляется в виде числа M. Шифрование осуществляется с помощью общедоступной функции f(M), и только адресату известно, как выполнить операцию f-1. Адресат выбирает два больших простых (prime) числа p и q, которые делает секретными. Он объявляет n=pq и число d, c (d,p-1)=(d,q-1)=1 (один из возможных способов выполнить это условие, выбрать d больше чем p/2 и q/2). Шифрование производится по формуле:
f(M) є Md mod n,
где M и f(M) оба Ј n-1. Как было показано, может быть вычислено за разумное время, даже если M, d и n содержит весьма большое число знаков. Адресат вычисляет M на основе Md, используя свое знание p и q. В соответствие со следствием 6, если
dc є(p-1)1, тогда (Md)eє p1.
Исходный текст M получается адресатом из зашифрованного F(M) путем преобразования: M = (F(M))e (mod pq). Здесь как исходный текст, так и зашифрованный рассматриваются как длинные двоичные числа.
Аналогично (Md)e є qM, если dc є (q-1)1. e удовлетворяет этим двум условиям, если cd є (p-1) (q-1)1. Теорема 1 гласит, что мы можем позволить e=x, когда x является решением уравнения dx + (p-1)(q-1)y = 1.
Так как (Md)e – M делимо на p и q, оно делимо и на pq, следовательно, мы можем определить M, зная Md, вычислив его значение в степени e и определив остаток от деления на pq. Для соблюдения секретности важно, чтобы, зная n, было нельзя вычислить p и q. Если n содержит 100 цифр, подбор шифра связан с перебором ~1050 комбинаций. Данная проблема изучается уже около 100 лет. RSA-алгоритм запатентован (20 сентября 1983, действует до 2000 года).
Теоретически можно предположить, что возможно выполнение операции f-1, не вычисляя p и q. Но в любом случае задача эта не проста и разработчики считают ее трудно факторизуемой.
Предположим, что мы имеем зашифрованный текст f(M) и исходный текст M, и мы хотим найти значения p и q. Нетрудно показать, что таких исходных данных для решения задачи недостаточно – надо знать все возможные значения Mi.
Проясним использование алгоритма RSA на конкретном примере. Выбираем два простые числа p=7; q=17 (на практике эти числа во много раз длиннее). В этом случае n = p*q будет равно 119. Теперь необходимо выбрать e, выбираем e=5. Следующий шаг связан с формированием числа d так, чтобы d*e=1 mod [(p-1)(q-1)]. d=77 (использован расширенный алгоритм Эвклида). d – секретный ключ, а e и n характеризуют открытый ключ. Пусть текст, который нам нужно зашифровать представляется M=19. С = Memod n. Получаем зашифрованный текст C=66. Этот “текст” может быть послан соответствующему адресату. Получатель дешифрует полученное сообщение, используя М= Cdmod n и C=66. В результате получается M=19.
На практике общедоступные ключи могут помещаться в специальную базу данных. При необходимости послать партнеру зашифрованное сообщение можно сделать сначала запрос его открытого ключа. Получив его, можно запустить программу шифрации, а результат ее работы послать адресату. На использовании общедоступных ключей базируется и так называемая электронная подпись, которая позволяет однозначно идентифицировать отправителя. Сходные средства могут применяться для предотвращения внесения каких-либо корректив в сообщение на пути от отправителя к получателю. Быстродействующие аппаратные 512-битовые модули могут обеспечить скорость шифрования на уровне 64 кбит в сек. Готовятся ИС, способные выполнять такие операции со скоростью 1 Мбайт/сек. Разумный выбор параметра e позволяет заметно ускорить реализацию алгоритма.
Атрибуты
5. Атрибуты
Атрибуты RADIUS несут в себе специфическую аутентификационную и конфигурационную информацию для запросов и откликов. Некоторые атрибуты могут быть включены в список более одного раза. Воздействие такого использования зависит от типа атрибута.
Конец списка атрибутов определяется кодом, содержащимся в поле пакета длина. Формат записи атрибута показан на Рисунок .2.
Атрибуты класса as-set
Рисунок .9. Атрибуты класса as-set
На Рисунок .10 представлены два объекта as-set. Набор as-foo содержит две AS, в частности AS1 и AS2. Набор as-bar содержит членов набора as-foo и AS3, т.е. он содержит AS1, AS2, AS3. Набор as-empty не содержит членов.
|
as-set: as-foo |
as-set: as-bar |
as-set: as-empty |
|
members: AS1, AS2 |
members: AS3, as-foo |
Атрибуты класса aut-num
Рисунок .23. Атрибуты класса aut-num
6.1. Атрибут import: Спецификация политики импорта
В RPSL политика импорта определяется двумя выражениями импортной политики. Каждое выражение импортной политики специфицируется с помощью атрибута import. Атрибут import имеет следующий синтаксис:
| import: | from <peering-1> [action <action-1>] . . . |
| from <peering-N> [action <action-N>] | |
| accept <filter> |
Спецификация действия является опционной. Семантика атрибута import выглядит следующим образом: набор маршрутов, который соответствует <filter> импортируется от всех партнеров в <peerings>, в то время как импортируемые маршруты <peering-M>, <>ction-M> реализуются.
Например
aut-num: AS1
import: from AS2 action pref = 1; accept { 128.9.0.0/16 }
Этот пример утверждает, что маршрут 128.9.0.0/16 воспринят от AS2 с предпочтением 1. Далее рассматривается спецификация действий (action).
6.1.1. Спецификация действия (Action)
Действия политики в RPSL устанавливают или модифицируют атрибуты маршрутов, таких как предпочтение маршрута, добавляет атрибут BGP community или устанавливает атрибут MULTI-EXIT-DISCRIMINATOR. Действия политики могут также инструктировать маршрутизаторы по выполнению специальных операций, таких как гашение осцилляций маршрутов.
Атрибуты маршрутной политики, чьи значения могут быть модифицированы посредством действий политики, специфицированы в словаре RPSL. Каждое действие при записи в RPSL завершаются символом точка с запятой (';'). Имеется возможность формировать составные действия политики путем последовательного их перечисления. В этом случае действия выполняются в порядке слева направо. Например,
aut-num: AS1
import: from AS2 action pref = 10; med = 0; community.append(10250, 3561:10);
| accept { 128.9.0.0/16 } |
устанавливает pref = 0, med = 0, и затем добавляет 10250 и 3561:10 к атрибуту прохода community BGP. Атрибут pref является инверсным по отношению к атрибуту local-pref (т.e.
local-pref == 65535 - pref). Маршрут с атрибутом local- pref всегда предпочтительнее, чем без него.
aut-num: AS1
| import: | from AS2 action pref = 1; |
| from AS3 action pref = 2; | |
| accept AS4 |
aut-num: AS1
| import: | from AS2 1.1.1.2 at 1.1.1.1 action pref = 1; | |
| from AS2 | action pref = 2; | |
| accept AS4 |
6.2. Атрибут export: Спецификация экспортной политики
Аналогично выражение экспортной политики специфицируется с помощью атрибута export. Атрибут export имеет следующий синтаксис:
| export: | to <peering-1> [action <action-1>] |
| . . . | |
| to <peering-N> [action <action-N>] | |
| announce <filter> |
Например
aut-num: AS1
export: to AS2 action med = 5; community .= { 70 }; announce AS4
В этом примере, маршруты AS4 объявляются автономной системе AS2 со значением атрибута med, равным 5 и атрибута community = 70.
Пример:
aut-num: AS1
export: to AS-FOO announce ANY
В этом примере, AS1 объявляет все свои маршруты автономным системам AS из набора AS-FOO.
6.3. Другие маршрутные протоколы, мультипротокольные маршрутные протоколы и обмен маршрутами между протоколами
Более сложный синтаксис атрибутов import и export выглядит следующим образом:
import: [protocol <protocol-1>] [into <protocol-2>]
| from <peering-1> [action <action-1>] | . . . | |
| from <peering-N> [action <action-N>] | accept <filter> |
/p> export: [protocol <protocol-1>] [into <protocol-2>]
| to <peering-1> [action <action-1>] | . . . | |
| to <peering-N> [action <action-N>] | announce <filter> |
aut-num: AS1
import: from AS2 accept AS2
export: protocol BGP4 into RIP to AS1 announce ANY
В следующем примере, AS1 воспринимает маршруты AS2, включая любые адресные префиксы больше префиксов маршрутов AS2, но не передает эти дополнительные префиксы протоколу OSPF.
aut-num: AS1
import: from AS2 accept AS2^+
export: protocol BGP4 into OSPF to AS1 announce AS2
В следующем примере, AS1 передает свои статические маршруты (маршруты, которые являются членами набора AS1:RS-STATIC-ROUTES) маршрутному протоколу interAS и дважды добавляет AS1 к своему маршрутному набору AS.
aut-num: AS1
| import: | protocol STATIC into BGP4 from AS1 action aspath.prepend(AS1, AS1); |
| accept AS1:RS-STATIC-ROUTES |
aut-num: AS1
import: from AS2 accept AS2
import: protocol IDMR
from AS2 accept AS2:RS-RPF-ROUTES
6.4. Разрешение неопределенности
Допускается, чтобы один и тот же обмен (peering) был описан в более чем одной спецификации партнерства в пределах выражения политики.
Например:
aut-num: AS1
| import: | from AS2 1.1.1.2 at 1.1.1.1 action pref = 2; |
| from AS2 1.1.1.2 at 1.1.1.1 action pref = 1; | |
| accept AS4 |
Рассмотрим пример:
aut-num: AS1
| import: | from AS2 action pref = 2; |
| from AS2 1.1.1.2 at 1.1.1.1 action pref = 1; dpa = 5; | |
| accept AS4 |
aut-num: AS1
| import: | from AS2 1.1.1.2 at 1.1.1.1 | action pref = 1; dpa = 5; |
| from AS2 | action pref = 2; | |
| accept AS4 |
aut-num: AS1
import: from AS2 action pref = 2; accept AS4
import: from AS2 action pref = 1; accept AS4
В этом случае, также используется правило порядка спецификаций. То есть маршруты AS4 от AS2 воспринимаются с предпочтением 2. Если фильтры перекрываются, но не тождественны:
aut-num: AS1
import: from AS2 action pref = 2; accept AS4
import: from AS2 action pref = 1; accept AS4 OR AS5
маршруты AS4 воспринимаются от AS2 с предпочтением 2 и, тем не менее, маршруты AS5 также воспринимаются, но с предпочтением 1.
Ниже приведено общее правило порядка спецификации для разработчиков программ RPSL.
Рассмотрим два расширения политики:
aut-num: AS1
import: from peerings-1 action action-1 accept filter-1
import: from peerings-2 action action-2 accept filter-2
Вышеприведенные выражения политики эквивалентны следующим трем выражениям, где нет неопределенности:
aut-num: AS1
import: from peerings-1 action action-1 accept filter-1
import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1
import: from peerings-4 action action-2 accept filter-2
где peerings-3 – это набор маршрутов, которые покрываются как peerings-1, так и peerings-2, а peerings-4 – набор маршрутов, которые покрываются peerings-2, но не покрываются peerings-1 ("filter-2 AND NOT filter-1" соответствует маршрутам, которые согласуются с filter-2, но не с filter-1).
Пример:
aut-num: AS1
| import: | from AS2 1.1.1.2 at 1.1.1.1 |
| action pref = 2; | |
| accept {128.9.0.0/16} | |
| import: | from AS2 |
| action pref = 1; | |
| accept {128.9.0.0/16, 75.0.0.0/8} |
6.5. Атрибут default. Спецификация политики по умолчанию
Политика маршрутизации по умолчанию специфицируется с помощью атрибута default. Атрибут default имеет следующий синтаксис:
default: to <peering> [action <action>] [networks <filter>]
Спецификации <action> и <filter> являются опционными. Семантика выглядит следующим образом: Спецификация <peering> указывает на AS (и маршрутизатор, если он имеется) по умолчанию; спецификация <action>, если присутствует, указывает на различные атрибуты конфигурации по умолчанию.
Например, относительное предпочтение, если определено несколько маршрутов по умолчанию; а спецификация <filter>, если имеется, является фильтром политики. Маршрутизатор использует политику по умолчанию, если он получает от партнера маршруты, которые удовлетворяют требованиям фильтра <filter>.
В следующем примере, AS1 маршрутизируется по умолчанию через AS2.
aut-num: AS1
default: to AS2
В следующем примере, марштутизатор 1.1.1.1 в AS1 маршрутизуется по умолчанию через 1.1.1.2 в AS2.
aut-num: AS1
default: to AS2 1.1.1.2 at 1.1.1.1
В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и AS3, но предпочитает AS2, а не AS3.
aut-num: AS1
default: to AS2 action pref = 1;
default: to AS3 action pref = 2;
В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и использует 128.9.0.0/16 в качестве сети по умолчанию.
aut-num: AS1
default: to AS2 networks { 128.9.0.0/16 }
6.6. Спецификация структурированной политики
Политики импорта и экспорта (рассылки и приема маршрутной информации) могут быть структурированы. Применение структурированной политики рекомендуется для продвинутых пользователей RPSL. Синтаксис спецификации структурированной политики выглядит следующим образом:
| <import-factor> ::= | from <peering-1> [action <action-1>] | |
| . . . | ||
| from <peering-N> [action <action-N>] | ||
| accept <filter>; | ||
| <import-term> ::= | <import-factor> | | |
| LEFT-BRACE | ||
| <import-factor> | ||
| . . . | ||
| <import-factor> | ||
| RIGHT-BRACE | ||
| <import-expression> ::= | <import-term> | | |
| <import-term> EXCEPT <import-expression> | | | |
| <import-term> REFINE <import-expression> | ||
| import: | [protocol <protocol1>] [into <protocol2>] | |
| <import-expression> |
Семантика <import-term> заключается в объединении <import-factor> с использованием правила порядка спецификаций. <import-expression> представляет собой либо один <import-term>, либо <import-term>, за которым следуют ключевые слова "except" и "refine", с завершающим <import-expression>. Заметим, что данное определение допускает вложенные выражения. Следовательно, могут существовать исключения к исключениям, уточнения к уточнениям или даже уточнения к исключениям и т.д.
Семантика для оператора except имеет вид. Результатом операции исключения является еще один член <import-term>. Результирующий набор политики содержит описание политики правой стороны, но его фильтры модифицированы так, что остаются только маршруты, соответствующие левой стороне. Политика левой стороны, в конце концов, включается, а ее фильтры модифицируются так, чтобы исключить маршруты, соответствующие левой стороне. Заметим, что фильтры модифицированы во время этого процесса, но действия скопированы один к одному. При нескольких уровнях вложения операции (принять или уточнить) выполняются справа налево.
Рассмотрим следующий пример:
| import: | from AS1 action pref = 1; | accept as-foo; |
| except | { | |
| from AS2 action pref = 2; | accept AS226; | |
| except | { | |
| from AS3 action pref = 3; | accept {128.9.0.0/16}; |
}
где маршрут 128.9.0.0/16 порождается AS226, а AS226 является членом набора AS as-foo. В этом примере, маршрут 128.9.0.0/16 воспринят от AS3, любой другой маршрут (не 128.9.0.0/16) порожденный AS226 воспринимается от AS2, и любые другие маршруты AS из as-foo получены от AS1. Можно прийти к тому же заключению, используя алгебраические выкладки, определенные выше. Рассмотрим спецификацию внутреннего исключения:
from AS2 action pref = 2; accept AS226;
except { from AS3 action pref = 3; accept {128.9.0.0/16};}
Эквивалентно
{ from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};
from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};}
Следовательно, исходное выражение эквивалентно:
| import: | from AS1 action pref = 1; accept as-foo; |
| except { from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16}; | |
| from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16}; } |
| import: | { from AS3 action pref = 3; |
| accept as-foo AND AS226 AND {128.9.0.0/16}; | |
| from AS2 action pref = 2; | |
| accept as- foo AND AS226 AND NOT {128.9.0.0/16}; | |
| from AS1 action pref = 1; | |
| accept as-foo AND NOT | |
| (AS226 AND NOT {128.9.0.0/16} OR AS226 AND {128.9.0.0/16}); } |
| import: | { |
| from AS3 action pref = 3; accept {128.9.0.0/16}; | |
| from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16}; | |
| from AS1 action pref = 1; accept as-foo AND NOT AS226; | |
| } |
| import: | { from AS-ANY action pref = 1; accept community(3560:10); |
| from AS-ANY action pref = 2; accept community(3560:20); | |
| } refine { from AS1 accept AS1; | |
| from AS2 accept AS2; | |
| from AS3 accept AS3; } |
К тому же заключению можно прийти, используя алгебраические методы, описанные выше. То есть, это пример эквивалентен:
| import: | { |
| from AS1 action pref = 1; accept community(3560:10) AND AS1; | |
| from AS1 action pref = 2; accept community(3560:20) AND AS1; | |
| from AS2 action pref = 1; accept community(3560:10) AND AS2; | |
| from AS2 action pref = 2; accept community(3560:20) AND AS2; | |
| from AS3 action pref = 1; accept community(3560:10) AND AS3; | |
| from AS3 action pref = 2; accept community(3560:20) AND AS3; } |
| import: | { |
| from AS-ANY action med = 0; accept {0.0.0.0/0^0-18}; | |
| } refine { | |
| from AS1 at 1.1.1.1 action pref = 1; accept AS1; | |
| from AS1 action pref = 2; accept AS1; } |
| import: | { |
| from AS1 at 1.1.1.1 action med=0; pref=1; | |
| accept {0.0.0.0/0^0-18} AND AS1; | |
| from AS1 action med=0; pref=2; | |
| accept {0.0.0.0/0^0-18} AND AS1; } |
Атрибуты класса dictionary
Рисунок .24. Атрибуты класса dictionary
Атрибут rp-attribute имеет следующий синтаксис:
rp-attribute: |
|
|
<method-1>(<type-1-1>, ..., <type-1-N1> [, "..."]) |
|
... |
|
<method-M>(<type-M-1>, ..., <type-M-NM> [, "..."]) |
где <name> является именем rp-атрибута, а <method-i> является названием метода доступа для rp-атрибута, требующего Ni аргументов, где j-ый аргумент имеет тип <type-i-j>. Название метода является либо именем RPSL, либо одним из операторов, определенных на Рисунок .25. Операторные методы за исключением operator() и operator[] могут воспринимать только один аргумент.
operator= |
operator== |
operator<<= |
operator< |
operator>>= |
operator> |
operator+= |
operator>= |
operator-= |
operator<= |
operator*= |
operator!= |
operator/= |
operator() |
operator.= |
operator[] |
Атрибуты класса filter
Рисунок .16. Атрибуты класса filter
filter-set: fltr-foo
filter: { 5.0.0.0/8, 6.0.0.0/8 }
filter-set: fltr-bar
filter: (AS1 or fltr-foo) and
Рисунок .21. Атрибуты класса filter
Атрибут peering определяет партнеров, которые могут быть использованы для импорта или экспорта маршрутных данных.
Атрибуты класса inet-rtr
Рисунок .35. Атрибуты класса inet-rtr
Значение атрибута ifaddr имеет следующий синтаксис:
<ipv4-address> masklen <integer>> [action <action>]
IP-адрес и длина маски являются обязательными для каждого интерфейса. Опционно можно специфицировать действие (action), которое позволяет установить другие параметры этого интерфейса.
На Рисунок .36 предложен пример объекта inet-rtr. Имя маршрутизатора "amsterdam.ripe.net". "amsterdam1.ripe.net" является каноническим именем для маршрутизатора. Маршрутизатор соединен с четырьмя сетями. Их IP-адреса и длины масок специфицированы в атрибутах ifaddr.
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 192.87.45.195 asno(AS3334), flap_damp()
Атрибуты класса mntner
Рисунок .1. Атрибуты класса mntner
auth: CRYPT-PW dhjsdfhruewf
auth: MAIL-FROM .*@ripe\.net
В настоящее время для <scheme-id> определены значения: NONE, MAIL-FROM, PGP-KEY и CRYPT-PW. <auth-info> представляет дополнительную информацию, необходимую для конкретной схемы: в случае MAIL-FROM, это регулярное выражение, соответствующее корректному электронному почтовому адресу. В случае CRYPT-PW, это пароль в крипто-формате UNIX. В случае PGP-KEY, это указатель на объект key-certif [22], содержащий открытый ключ PGP-пользователя. Если специфицировано несколько атрибутов auth, запрос эксплуатационный актуализации, удовлетворяющий любому из них, будет аутентифицирован.
Атрибут upd-to представляет собой электронный почтовый адрес. При неавторизованной попытке актуализации объекта, по этому адресу будет послано сообщение. Атрибут mnt-nfy также представляет собой почтовый адрес. При добавлении, изменении или удалении объекта по этому адресу посылается уведомляющее сообщение.
Атрибут descr является коротким текстовым описанием объекта, выполненным в произвольной форме. Атрибут tech-c представляет собой контактный дескриптор NIC. Он используется при возникновении технических проблем, например, при неверной конфигурации. Атрибут admin-c представляет собой административный контактный дескриптор NIC. Атрибут remarks представляет собой текстовый комментарий или разъяснение. Атрибут notify представляет собой электронный адрес, куда следует отправлять уведомление об изменении этого объекта. Атрибут mnt-by является списком имен объектов mntner. Атрибут changed определяет, кто последний раз изменял данный объект, и когда это изменение было произведено. Его синтаксис имеет следующий формат:
changed:
Например
changed: johndoe@terabit-labs.nn 19900401
<email-address> идентифицирует человека, который внес последние изменения. <YYYYMMDD> представляет собой дату изменения. Атрибут source специфицирует реестр, где объект зарегистрирован. На Рисунок .2 показан пример объекта mntner.
В этом примере использован криптографический формат UNIX для паролей аутентификации.
| mntner: | RIPE-NCC-MNT |
| descr: | RIPE-NCC Maintainer |
| admin-c: | DK58 |
| tech-c: | OPS4-RIPE |
| upd-to: | ops@ripe.net |
| mnt-nfy: | ops-fyi@ripe.net |
| auth: | CRYPT-PW lz1A7/JnfkTtI |
| mnt-by: | RIPE-NCC-MNT |
| changed: | ripe-dbm@ripe.net 19970820 |
| source: | RIPE |
Атрибуты класса
Рисунок .3: Атрибуты класса person
phone: + 44 123 987654 ext. 4711
На Рисунок .4 приведен пример объекта person.
| person: | Daniel Karrenberg |
| address: | RIPE Network Coordination Centre (NCC) |
| address: | Singel 258 |
| address: | NL-1016 AB Amsterdam |
| address: | Netherlands |
| phone: | +31 20 535 4444 |
| fax-no: | +31 20 535 4445 |
| e-mail: | Daniel.Karrenberg@ripe.net |
| nic-hdl: | DK58 |
| changed: | Daniel.Karrenberg@ripe.net 19970616 |
| source: | RIPE |
Атрибуты класса role
Рисунок .5. Атрибуты класса role
|
role: |
RIPE NCC Operations |
trouble:
|
address: |
Singel 258 |
|
address: |
1016 AB Amsterdam |
|
address: |
The Netherlands |
|
phone: |
+31 20 535 4444 |
|
fax-no: |
+31 20 545 4445 |
|
e-mail: |
ops@ripe.net |
|
admin-c: |
CO19-RIPE |
|
tech-c: |
RW488-RIPE |
|
tech-c: |
JLSD1-RIPE |
|
nic-hdl: |
OPS4-RIPE |
|
notify: |
ops@ripe.net |
|
changed: |
roderik@ripe.net 19970926 |
|
source: |
RIPE |
Атрибуты класса route
Рисунок 7: Атрибуты класса route
|
route: |
128.9.0.0/16 |
|
origin: |
AS226 |
|
route: |
128.99.0.0/16 |
|
origin: |
AS226 |
|
route: |
128.8.0.0/16 |
|
origin: |
AS1 |
|
route: |
128.8.0.0/16 |
|
origin: |
AS2 |
Атрибуты класса route-set
Рисунок .12. Атрибуты класса route-set
На Рисунок .13 приведены некоторые примеры объектов route-set. Набор rs-foo содержит два адресных префикса, в частности 128.9.0.0/16 и 128.9.0.0/24. Набор rs-bar содержит члены набора rs-foo и адресный префикс 128.7.0.0/16.
За адресным префиксом или именем route-set в атрибуте members может опционно следовать оператор диапазона. Например, следующий набор:
route-set: rs-foo
members: 128.9.0.0/16, 128.9.0.0/24
route-set: rs-bar
members: 128.7.0.0/16, rs-foo
Атрибуты класса rtr-set
Рисунок .18. Атрибуты класса rtr-set
На Рисунок .19 представлены два объекта rtr-set. Набор rtrs-foo содержит два маршрутизатора, в частности rtr1.isp.net и rtr2.isp.net. Набор rtrs-bar содержит членов набора rtrs-foo и rtr3.isp.net, то есть он содержит rtr1.isp.net, rtr2.isp.net, rtr3.isp.net.
|
rtr-set: rtrs-foo |
rtr-set: rtrs-bar |
|
members: rtr1.isp.net, rtr2.isp.net |
members: rtr3.isp.net, rtrs-foo |
B Грамматические правила
B. Грамматические правила
Ниже рассмотрены формальные грамматические правила RPSL. Основные типы данных определены в разделе 2. Правила записаны с использованием входного языка грамматического разбора GNU Bison.
//**** базовые атрибуты *********************************************
changed_attribute: ATTR_CHANGED TKN_EMAIL TKN_INT
//**** класс aut-num *************************************************
//// as_expression /////////////////////////////////////////////////////
opt_as_expression: | as_expression
as_expression: as_expression OP_OR as_expression_term | as_expression_term
as_expression_term: as_expression_term OP_AND as_expression_factor
| as_expression_term KEYW_EXCEPT as_expression_factor | as_expression_factor
as_expression_factor: '(' as_expression ')' | as_expression_operand
as_expression_operand: TKN_ASNO | TKN_ASNAME
//// router_expression /////////////////////////////////////////////////
opt_router_expression: | router_expression
opt_router_expression_with_at: | KEYW_AT router_expression
router_expression: router_expression OP_OR router_expression_term | router_expression_term
router_expression_term: router_expression_term OP_AND router_expression_factor
| router_expression_term KEYW_EXCEPT router_expression_factor | router_expression_factor
router_expression_factor: '(' router_expression ')' | router_expression_operand
router_expression_operand: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME
//// пиринг ///////////////////////////////////////////////////////////
peering: as_expression opt_router_expression opt_router_expression_with_at
| TKN_PRNGNAME
//// действие ////////////////////////////////////////////////////////////
opt_action: | KEYW_ACTION action
action: single_action | action single_action
single_action: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')' ';'
| TKN_RP_ATTR TKN_OPERATOR list_item ';' | TKN_RP_ATTR '(' generic_list ')' ';'
| TKN_RP_ATTR '[' generic_list ']' ';' | ';'
//// фильтр ////////////////////////////////////////////////////////////
filter: filter OP_OR filter_term | filter filter_term %prec OP_OR | filter_term
filter_term : filter_term OP_AND filter_factor | filter_factor
filter_factor : OP_NOT filter_factor | '(' filter ')' | filter_operand
filter_operand: KEYW_ANY | '' | filter_rp_attribute | TKN_FLTRNAME
| filter_prefix
filter_prefix: filter_prefix_operand OP_MS | filter_prefix_operand
filter_prefix_operand: TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | TKN_RSNAME
| '{' opt_filter_prefix_list '}'
opt_filter_prefix_list: | filter_prefix_list
filter_prefix_list: filter_prefix_list_prefix | filter_prefix_list ',' filter_prefix_list_prefix
filter_prefix_list_prefix: TKN_PRFXV4 | TKN_PRFXV4RNG
filter_aspath: filter_aspath '|' filter_aspath_term | filter_aspath_term
filter_aspath_term: filter_aspath_term filter_aspath_closure | filter_aspath_closure
filter_aspath_closure: filter_aspath_closure '*' | filter_aspath_closure '?' | filter_aspath_closure '+'
| filter_aspath_factor
filter_aspath_factor: '^' | '$' | '(' filter_aspath ')' | filter_aspath_no
filter_aspath_no: TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | '.' | '[' filter_aspath_range ']'
| '[' '^' filter_aspath_range ']'
filter_aspath_range: | filter_aspath_range TKN_ASNO | filter_aspath_range KEYW_PEERAS
| filter_aspath_range '.' | filter_aspath_range TKN_ASNO '-' TKN_ASNO
| filter_aspath_range TKN_ASNAME
filter_rp_attribute: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')'
| TKN_RP_ATTR TKN_OPERATOR list_item | TKN_RP_ATTR '(' generic_list ')'
| TKN_RP_ATTR '[' generic_list ']'
//// пара пиринг-действий ///////////////////////////////////////////////
import_peering_action_list: KEYW_FROM peering opt_action
| import_peering_action_list KEYW_FROM peering opt_action
export_peering_action_list: KEYW_TO peering opt_action
| export_peering_action_list KEYW_TO peering opt_action
//// фактор import/export //////////////////////////////////////////////
import_factor: import_peering_action_list KEYW_ACCEPT filter
import_factor_list: import_factor ';' | import_factor_list import_factor ';'
export_factor: export_peering_action_list KEYW_ANNOUNCE filter
export_factor_list: export_factor ';' | export_factor_list export_factor ';'
//// термин import/export ////////////////////////////////////////////////
import_term: import_factor ';' | '{' import_factor_list '}'
export_term: export_factor ';' | '{' export_factor_list '}'
//// выражение import/export //////////////////////////////////////////
import_expression: import_term | import_term KEYW_REFINE import_expression
| import_term KEYW_EXCEPT import_expression
export_expression: export_term | export_term KEYW_REFINE export_expression
| export_term KEYW_EXCEPT export_expression
//// протокол ///////////////////////////////////////////////////////////
opt_protocol_from: | KEYW_PROTOCOL tkn_word
opt_protocol_into: | KEYW_INTO tkn_word
//**** атрибуты import/export ****************************************
import_attribute: ATTR_IMPORT
| ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor
export_attribute: ATTR_EXPORT
| ATTR_EXPORT opt_protocol_from opt_protocol_into export_factor
opt_default_filter: | KEYW_NETWORKS filter
default_attribute: ATTR_DEFAULT KEYW_TO peering
filter_attribute: ATTR_FILTER filter
peering_attribute: ATTR_PEERING peering
//**** класс inet-rtr **************************************************
ifaddr_attribute: ATTR_IFADDR TKN_IPV4 KEYW_MASKLEN TKN_INT opt_action
//// атрибут peer ////////////////////////////////////////////////////
opt_peer_options: | peer_options
peer_options: peer_option | peer_options ',' peer_option
peer_option: tkn_word '(' generic_list ')'
peer_id: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME | TKN_PRNGNAME
peer_attribute: ATTR_PEER tkn_word peer_id opt_peer_options
//**** класс route *****************************************************
aggr_bndry_attribute: ATTR_AGGR_BNDRY as_expression
aggr_mtd_attribute: ATTR_AGGR_MTD KEYW_INBOUND
| ATTR_AGGR_MTD KEYW_OUTBOUND opt_as_expression
//// атрибут inject //////////////////////////////////////////////////
opt_inject_expression: | KEYW_UPON inject_expression
inject_expression: inject_expression OP_OR inject_expression_term | inject_expression_term
inject_expression_term: inject_expression_term OP_AND inject_expression_factor
| inject_expression_factor
inject_expression_factor: '(' inject_expression ')' | inject_expression_operand
inject_expression_operand: KEYW_STATIC
| KEYW_HAVE_COMPONENTS '{' opt_filter_prefix_list '}'
| KEYW_EXCLUDE '{' opt_filter_prefix_list '}'
inject_attribute: ATTR_INJECT opt_router_expression_with_at opt_action opt_inject_expression
//// атрибут components //////////////////////////////////////////////
opt_atomic: | KEYW_ATOMIC
components_list: | filter | components_list KEYW_PROTOCOL tkn_word filter
components_attribute: ATTR_COMPONENTS opt_atomic components_list
//**** набор маршрутов *****************************************************
opt_rs_members_list: /* пустой список */
| rs_members_list
rs_members_list: rs_member | rs_members_list ',' rs_member
rs_member: TKN_ASNO | TKN_ASNO OP_MS | TKN_ASNAME | TKN_ASNAME OP_MS
| TKN_RSNAME | TKN_RSNAME OP_MS | TKN_PRFXV4 | TKN_PRFXV4RNG
rs_members_attribute: ATTR_RS_MEMBERS opt_rs_members_list
//**** словарь ******************************************************
rpattr_attribute: ATTR_RP_ATTR TKN_WORD methods
| ATTR_RP_ATTR TKN_RP_ATTR methods
methods: method | methods method
method: TKN_WORD '(' ')' | TKN_WORD '(' typedef_type_list ')'
| TKN_WORD '(' typedef_type_list ',' TKN_3DOTS ')'
| KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ')'
| KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ',' TKN_3DOTS ')'
//// атрибут typedef ////////////////////////////////////////////////
typedef_attribute: ATTR_TYPEDEF TKN_WORD typedef_type
typedef_type_list: typedef_type | typedef_type_list ',' typedef_type
typedef_type: KEYW_UNION typedef_type_list | KEYW_RANGE KEYW_OF typedef_type
| TKN_WORD | TKN_WORD '[' TKN_INT ',' TKN_INT ']'
| TKN_WORD '[' TKN_REAL ',' TKN_REAL ']' | TKN_WORD '[' enum_list ']'
| KEYW_LIST '[' TKN_INT ':' TKN_INT ']' KEYW_OF typedef_type
| KEYW_LIST KEYW_OF typedef_type
enum_list: tkn_word | enum_list ',' tkn_word
//// атрибут protocol ////////////////////////////////////////////////
protocol_attribute: ATTR_PROTOCOL tkn_word protocol_options
protocol_options: | protocol_options protocol_option
protocol_option: KEYW_MANDATORY method | KEYW_OPTIONAL method
//**** Описания лексем *********************************************
//// макросы flex, используемые при определении лексем /////////////////////////////
INT [[:digit:]]+
SINT [+-]?{INT}
REAL [+-]?{INT}?\.{INT}({WS}*E{WS}*[+-]?{INT})?
NAME [[:alpha:]]([[:alnum:]_-]*[[:alnum:]])?
ASNO AS{INT}
ASNAME AS-[[:alnum:]_-]*[[:alnum:]]
RSNAME RS-[[:alnum:]_-]*[[:alnum:]]
RTRSNAME RTRS-[[:alnum:]_-]*[[:alnum:]]
PRNGNAME PRNG-[[:alnum:]_-]*[[:alnum:]]
FLTRNAME FLTR-[[:alnum:]_-]*[[:alnum:]]
IPV4 [0-9]+(\.[0-9]+){3,3}
PRFXV4 {IPV4}\/[0-9]+
PRFXV4RNG {PRFXV4}("^+"|"^-"|"^"{INT}|"^"{INT}-{INT})
ENAMECHAR [^()<>,;:\\\"\.[\] \t\r]
ENAME ({ENAMECHAR}+(\.{ENAMECHAR}+)*\.?)|(\"[^\"@\\\r\n]+\")
DNAME [[:alnum:]_-]+
//// Определения лексем >////////////////////////////////////////////////
TKN_INT {SINT}
TKN_INT {INT}:{INT} if each {INT} is two octets
TKN_INT {INT}.{INT}.{INT}.{INT} if each {INT} is one octet
TKN_REAL {REAL}
TKN_STRING То же самое что и в языке СИ
TKN_IPV4 {IPV4}
TKN_PRFXV4 {PRFXV4}
TKN_PRFXV4RNG {PRFXV4RNG}
TKN_ASNO {ASNO}
TKN_ASNAME (({ASNO}|peeras|{ASNAME}):)*{ASNAME}\
(:({ASNO}|peeras|{ASNAME}))*
TKN_RSNAME (({ASNO}|peeras|{RSNAME}):)*{RSNAME}\
(:({ASNO}|peeras|{RSNAME}))*
TKN_RTRSNAME (({ASNO}|peeras|{RTRSNAME}):)*{RTRSNAME}\
(:({ASNO}|peeras|{RTRSNAME}))*
TKN_PRNGNAME (({ASNO}|peeras|{PRNGNAME}):)*{PRNGNAME}\
(:({ASNO}|peeras|{PRNGNAME}))*
TKN_FLTRNAME (({ASNO}|peeras|{FLTRNAME}):)*{FLTRNAME}\
(:({ASNO}|peeras|{FLTRNAME}))*
TKN_BOOLEAN true|false
TKN_RP_ATTR {NAME} if defined in dictionary
TKN_WORD {NAME}
TKN_DNS {DNAME}("."{DNAME})+
TKN_EMAIL {ENAME}@({DNAME}("."{DNAME})+|{IPV4})
Документ RFC-2280 [3] содержит раннюю версию языка RPSL.
Беспроводные (радио) каналы и сети
3.3 Беспроводные (радио) каналы и сети
Применение электромагнитных волн для телекоммуникаций имеет уже столетнюю историю. Спектр используемых волн делится на ряд диапазонов, приведенных в таблице 3.3.1.
Библиография
Библиография
|
[Baker96] |
Baker, F., "RSVP Cryptographic Authentication", Work in Progress. |
|
[RFC 1633] |
Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and PARC, June 1994. |
|
[FJ94] |
Floyd, S. and V. Jacobson, "Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, Vol. 2, No. 2, April, 1994. |
|
[RFC 2207] |
Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. |
|
[RFC-2208] |
“Resource Reservation Protocol (RSVP) – Version 1. Applicability Statement”. |
|
[RFC-2209] |
“Resource Reservation Protocol (RSVP) – Version 1.Message Processing Rules” |
|
[RFC 2113] |
Katz, D., "IP Router Alert Option", RFC 2113, cisco Systems, February 1997. |
|
[RFC 2210] |
Wroclawski, J., "The Use of RSVP with Integrated Services", RFC 2210, September 1997. |
|
[RFC-2211] |
“Specification of the Controlled-Load Network Element Service” |
|
[RFC-2212] |
“Specification of Guarantied Quality of Service” |
|
[PolArch96] |
Herzog, S., "Policy Control for RSVP: Architectural Overview". Work in Progress. |
|
[OPWA95] |
Shenker, S. and L. Breslau, "Two Issues in Reservation Establishment", Proc. ACM SIGCOMM '95, Cambridge, MA, August 1995. |
Блок-схема работы сетевого моста
Рисунок 4.1.1.4.3 Блок-схема работы сетевого моста
Мост, имеющий более двух портов, называется переключателем. Первый переключатель был разработан фирмой Калпане в 1991 году. Иногда переключатели называются маршрутизаторами, тем более что некоторые из них поддерживают внутренние протоколы маршрутизации (например, RIP). Переключатели имеют внутреннюю параллельную магистраль очень высокого быстродействия (от десятков мегабайт до гигабайт в сек.). Эта магистраль позволяет переключателю совместить преимущества повторителя (быстродействие) и моста (разделение информационных потоков) в одном устройстве. Схемы реализации переключателей варьируются значительно, каких-либо единых стандартов не существует. Алгоритм работы с адресами здесь тот же, что и в случае мостов. На Рисунок 4.1.1.4.4 приведена схема 8-входового переключателя. В переключателе все входы идентичны, но внешняя информация, записанная в их память, делает входы неэквивалентными. Определенные проблемы возникают, когда к одному из входов переключателя подключен сервер, с которым работают пользователи подключенные к остальным входам. Если все ЭВМ, подключенные к переключателю, одновременно попытаются обратиться к серверу, переключатель перегрузится и все каналы будут на некоторое время блокированы (будет послан сигнал перегрузки – jam). При данной схеме вероятность таких событий значительна, так как несколько каналов с пропускной способностью 10 Мбит/с работают на один общий канал с той же полосой пропускания. Для преодоления проблем этого рода следует распределять нагрузки между портами переключателя равномерно, а также подключать серверы через полнодуплексные каналы. Полнодуплексные каналы полезны и для соединения переключателей между собой. Современные переключатели имеют много различных возможностей – SNMP поддержка, автоматическая настройка быстродействия и определения типа соединения (дуплексная/полудуплексная). Имеется возможность внешней загрузки программы работа переключателя. Способы проверки производительности переключателей описаны в документах RFC-1242 и RFC-1944 (тесты Бреднера, см. www.wiley.com/compbooks/fastethernet и www.tolly.com).
Блокада для стиля WF
Рисунок 4.4.9.6.11. Блокада для стиля WF
29. Локальное восстановление
Когда маршрут изменяется, следующее сообщение обновления Path или Resv установит проход или состояние резервирования (соответственно) вдоль нового маршрута. Чтобы обеспечить быструю адаптацию к изменениям маршрута, не вводя чрезмерно коротких периодов обновления, местный модуль протокола маршрутизации может сообщить процессу RSVP об изменении маршрута до определенных мест назначения. Процесс RSVP должен использовать эту информацию для запуска обновления в соответствующих областях с учетом изменения маршрута.
При этом используются следующие правила спецификации:
Когда маршрутизация обнаруживает изменение набора выходных интерфейсов для места назначения G, RSVP должен обновить состояние прохода, подождать короткий период W и затем послать сообщение обновление Path всем сессиям G/* (т.е., любой сессии с местом назначения G, вне зависимости от порта назначения). Короткая выдержка перед рассылкой сообщения обновления Path нужна, чтобы позволить завершиться переходным процессам в маршрутном протоколе. В настоящее время предлагается W = 2 сек; однако, эта величина должна быть задана при конфигурировании каждого интерфейса.
Когда приходит сообщение Path с адресом предыдущего узла, который отличается от записанного в состоянии прохода, RSVP должен немедленно послать сообщение обновления Resv этому PHOP.
30. Временные параметры
Существует два временных параметра, соответствующие каждому элементу прохода или состоянию резервирования RSVP в узле: период обновления R между последовательными коррекциями состояния соседнего узла и время жизни локального состояния L. Каждое сообщение RSVP Resv или Path может содержать объект TIME_VALUES, специфицирующий значение R, которое было использовано при генерации данного сообщения обновления. Эта величина R затем используется для определения значения L. Величины R и L могут варьироваться от узла к узлу.
Более подробно:
Флойд и Джакобсон [FJ94] показали, что периодические сообщения, генерируемые независимыми сетевыми узлами, могут взаимно синхронизоваться.
Это может привести к деградации сетевых услуг, так как периодические сообщения могут сталкиваться с другими сетевыми пакетами. Так как RSVP периодически посылает сообщения обновления, он должен избегать синхронизации сообщений и гарантировать, чтобы любая возникшая синхронизация не была стабильной. По этой причине таймер обновления должен быть рэндомизован в диапазоне [0.5R, 1.5R].
Чтобы избежать преждевременной потери состояния, L должно удовлетворять условию L ? (K + 0.5)*1.5*R, где K небольшое целое число. Тогда в худшем случае, K-1 последовательных сообщений могут быть потеряны без ликвидации состояния. Чтобы вычислить время жизни L для комбинации состояний с различными R R0, R1, ..., заменяем R на max(Ri). В настоящее время по умолчанию K = 3. Однако может быть необходимо установить большее значение K для узлов с высокой вероятностью потерь. K может устанавливаться при конфигурации интерфейса вручную или с помощью какой-либо адаптивной процедуры.
Каждое сообщение Path или Resv несет в себе объект TIME_VALUES, содержащий время обновления R, использованное при генерации обновлений. Узел получателя использует это R для определения времени жизни L записанного состояния, созданного или обновленного данным сообщением.
Время обновления R выбирается локально для каждого из узлов. Если узел не использует локального восстановления резервирования, нарушенного в результате изменения маршрута, меньшее значение R ускоряет адаптацию к изменениям маршрута, но увеличивает издержки RSVP. Узел может настраивать эффективное значение R динамически, чтобы контролировать уровень издержек, связанных с сообщениями обновления. В настоящее время по умолчанию выбирается R = 30 секундам. Однако значение по умолчанию Rdef должно выбираться индивидуально для каждого интерфейса.
Когда R меняется динамически, существует предел того, как быстро оно может расти. Отношение величин R2/R1 не должно превосходить 1 + Slew.Max. В настоящее время, Slew.Max равно 0.30. При K = 3, один пакет может быть потерян без таймаута состояния, в то время как R увеличивается на 30% за период обновления.
Чтобы улучшить надежность, узел может временно после изменения состояния посылать сообщения обновления более часто.
Значения Rdef, K и Slew.Max, используемые в приложении, должны легко модифицироваться для каждого интерфейса.
31. Политика в области трафика и узлы с не интегрированными услугами
Некоторые уровни QoS могут требовать определенной политики в управлении трафиком в некоторых или всех перечисленных ниже случаях:
Краевые точки сети.
Точки объединения данных от многих отправителей.
Точки ветвления, где трафик в различных ветвях может требовать различных уровней резервирования.
RSVP знает, где такие точки находятся, и должен обеспечивать этими данными механизм управления трафиком. С другой стороны, RSVP не интерпретирует информацию в flowspec и, следовательно, не знает, использованы ли рекомендации управления в каждом конкретном случае.
Процесс RSVP передает управлению трафиком специальный флаг политики для каждой из трех указанных выше ситуаций.
E_Police_Flag – управление входом
Этот флаг устанавливается для первого узла RSVP, который реализует управление трафиком. Например, ЭВМ-отправители должны поддерживать RSVP, но многие из них не поддерживают управление трафиком. В этом случае флаг E_Police_Flag в ЭВМ-отправителе должен быть равен нулю, флаг устанавливается равным 1, когда достигнута первая ЭВМ, поддерживающая управление трафиком. Это контролируется флагом E_Police в объектах SESSION.
M_Police_Flag – управление объединением
Этот флаг должен быть установлен для резервирования, использующего стили WF или SE, когда объединяются потоки более чем одного отправителя.
B_Police_Flag –управление ветвлением
Этот флаг должен быть установлен, когда инсталлированная flowspec меньше или сравнима с FLOWSPEC какого-либо другого интерфейса для того же самого FILTER_SPEC и SESSION.
RSVP должен также проверять наличие вдоль пути узлов, не поддерживающих RSVP, и переправлять эту информацию управлению трафиком. На основании этого флага и другой сопутствующей информации система контроля трафиком может обнаружить узлы, которые не способны обеспечить управление QoS.
Эта информация передается получателям в спецификации Adspecs [RFC 2210].
При обычной IP-переадресации, RSVP может обнаружить узлы без поддержки RSVP путем сравнения значения IP TTL, с которым послано сообщение Path, с полученным TTL. Для этой цели TTL помещается в общий заголовок. Однако, TTL не всегда является надежным индикатором узлов без поддержки RSVP, и для этих целей иногда используются другие средства. Например, если маршрутный протокол использует туннели с IP-инкапсуляцией, этот протокол должен проинформировать RSVP о наличии узлов, лишенных поддержки RSVP. В отсутствии автоматических механизмов осуществляется ручная конфигурация.
32. ЭВМ с несколькими сетевыми интерфейсами
При работе с ЭВМ, имеющими несколько сетевых интерфейсов, требуется выполнение ряда специальных правил. К такого рода устройствам относятся и маршрутизаторы, которые поддерживают локальные прикладные программы.
Приложение, исполняемое на такой машине, должно явно указывать через какой интерфейс осуществляется передача данного информационного потока, для того чтобы заменить интерфейс, заданный по умолчанию системой.
Посылка данных
Приложение отправителя использует API вызов для декларации характеристик его информационного потока для RSVP. Этот вызов может опционно включать локальный IP-адрес отправителя. Если он установлен приложением, этот параметр должен быть адресом интерфейса для отправки информационных пакетов, в противном случае, используется системный интерфейс по умолчанию.
Процесс RSVP ЭВМ посылает затем приложению сообщения Path только через специфицированный интерфейс.
33. Выполнение резервирования
Приложение-получатель использует вызов API для запроса резервирования RSVP. Этот вызов может опционно включать локальный IP-адрес получателя, т.е., адрес интерфейса для получения информационных пакетов. В случае мультикаст-сессий это интерфейс, к которому подключилась группа. Если этот параметр опущен, система использует значение по умолчанию.
Процесс RSVP должен посылать сообщения Resv приложению через специфицированный интерфейс.
Однако, когда приложение исполняется в маршрутизаторе, а сессия является мультикастной, возникает более сложная ситуация. Предположим, что в этом случае приложение получателя присоединяется к группе через интерфейс Iapp, который отличается от Isp – ближайшего интерфейса по пути к отправителю. Теперь имеется два возможных пути для мультикастной маршрутизации при доставке информационных пакетов приложению. Процесс RSVP должен определить, какой вариант выбрать, просмотрев состояние прохода и решив, какой из входных интерфейсов следует использовать для посылки сообщений.
Протокол мультикастной маршрутизации может создавать отдельные ветви дерева доставки к Iapp. В этом случае будет иметься состояние прохода для обоих интерфейсов Isp и Iapp. Состояние прохода в Iapp должно только соответствовать резервированию локального приложения. Оно должно быть помечено процессом RSVP как "Local_only". Если существует состояние прохода "Local_only" для Iapp, сообщение Resv должно посылаться через Iapp. Заметим, что имеется возможность для блоков состояния прохода Isp и Iapp иметь один и тот же следующий узел, если в маршрут вклинивается область, не поддерживающая RSVP.
Протокол мультикастной маршрутизации может переадресовать данные в пределах маршрутизатора от Isp к Iapp. В этом случае Iapp появится в списке выходных интерфейсов состояния прохода Isp и сообщения Resv должны будут посылаться через Isp.
Когда сообщения Path и PathTear переадресованы, состояние прохода, помеченное как "Local_Only", должно игнорироваться.
34. Будущая совместимость
В будущем для существующих классов могут быть описаны новые объекты C-Типа, а могут быть определены и новые классы объектов. Крайне желательно использовать такие объекты Интернет в рамках старых приложений, которые их не распознают. К сожалению, это возможно с заметными ограничениями. Здесь нужно придерживаться следующих правил (`b' означает бит).
1. Неизвестный класс
Существует три возможных способа, чтобы приложение RSVP могло работать с объектом неизвестного класса.
Этот выбор определяется двумя старшими битами октета Class-Num.
Class-Num = 0bbbbbbb. Все сообщение должно быть отброшено и возвращена ошибка "Unknown Object Class" (неизвестный класс объекта).
Class-Num = 10bbbbbb. Узел должен игнорировать объект без дальнейшей пересылки или отправки сообщений об ошибке.
Class-Num = 11bbbbbb. Узел должен игнорировать объект, но может переадресовать его далее без модификации со всеми сообщениями, вызванными данным запросом.
Ниже приведены более детализированные правила для работы с нераспознанными классами объектов для Class-Num вида 11bbbbbb:
Такие объекты неизвестного класса, включенные в сообщения PathTear, ResvTear, PathErr или ResvErr, должны немедленно переадресовываться в рамках того же сообщения.
Такие объекты неизвестного класса, включенные в сообщения Path или Resv, должны быть записаны в соответствующие состояния и посланы в сообщениях обновления, сопряженных с указанным состоянием.
Когда формируется обновление Resv путем объединения нескольких запросов резервирования, сообщение обновления должно включать в себя объединение объектов неузнанных классов всех компонентов запроса. В этом объединении каждый такой объект может присутствовать только один раз.
Исходный порядок таких объектов необязательно сохранять. Однако формируемое сообщение должно подчиняться общим правилам в отношении упорядочения объектов.
Хотя объекты с неизвестным классом не могут объединяться, эти правила позволяют передать их вплоть до узла, который сможет их распознать и объединить.
2. Неизвестный C-Тип для известного класса
Появление объекта с неизвестным C-типом приведет к выбрасыванию всего сообщения и генерации сообщения об ошибке (ResvErr или PathErr). Сообщение об ошибке будет включать Class-Num и C-тип, который был не распознан. Оконечная система, которая отправила нераспознанное сообщение может использовать эту информацию, чтобы попытаться повторить попытку с объектом другого C-типа.
Объекты определенных классов (FLOWSPEC, ADSPEC и POLICY_DATA) не прозрачны для RSVP, который просто передает их системе управления трафиком или другим модулям управления.
В зависимости от внутренних правил любой из упомянутых модулей может отвергнуть C-Тип и информировать об этом RSVP-процесс; RSVP должен тогда отвергнуть такое сообщение и проинформировать об ошибке.
35. Интерфейсы RSVP
RSVP в маршрутизаторе имеет интерфейсы для управления трафиком, а в ЭВМ - интерфейсы для приложений (т.е., API), а также для управления трафиком (если такой контроль предусмотрен).
35.1. Интерфейс приложения RSVP
Структура реального интерфейса может зависеть от операционной системы. Некоторые из вызовов предполагают асинхронную присылку информации.
Регистрация сессии
Вызов: SESSION( DestAddress , ProtocolId, DstPort
[ , SESSION_object ]
[ , Upcall_Proc_addr ] ) -> Session-id
Этот вызов инициирует RSVP обработку сессии, заданной DestAddress, ProtocolId и, возможно, номером порта DstPort. В случае успеха вызов SESSION возвращает локальный идентификатор сессии Session-id, который может использоваться при последующих вызовах.
Параметр Upcall_Proc_addr определяет адрес вызова процедуры получения кода ошибки или информации о событии. Параметр SESSION_object включен для организации механизма поддержки более общего описания сессии ("обобщенный порт назначения"). Обычно SESSION_object опускается.
Определение отправителя
Вызов: SENDER( Session-id
[ , Source_Address ] [ , Source_Port ]
[ , Sender_Template ]
[ , Sender_Tspec ] [ , Adspec ]
[ , Data_TTL ] [ , Policy_data ] )
Отправитель использует этот вызов, чтобы определить или модифицировать атрибуты информационного потока. Первое обращение к SENDER для регистрации сессии как `Session-id' заставит RSVP начать рассылку сообщений Path для данной сессии; последующие вызовы будут модифицировать информацию о проходе.
Параметры SENDER интерпретируются следующим образом:
Source_Address. Это адрес интерфейса через который будут посылаться данные. Если этот параметр пропущен, будет использоваться интерфейс по умолчанию. Этот параметр необходим для ЭВМ с двумя и более сетевыми интерфейсами.
Source_Port. Это UDP/ TCP порт, через который будут посылаться данные.
Sender_Template. Этот параметр включен для поддержки механизма более общего описания отправителя ("обобщенный порт источника"). Обычно этот параметр может быть опущен.
Sender_Tspec. Этот параметр описывает трафик потока; смотри [RFC 2210].
Adspec. Этот параметр может быть специфицирован для инициализации вычисления свойств QoS вдоль пути; смотри [RFC 2210].
Data_TTL. Это IP TTL параметр, который несут в себе информационные пакеты. Он необходим, чтобы гарантировать условие, при котором сообщения Path не будут попадать за пределы зоны мультикастинг-сессии.
Policy_data. Это опционный параметр несет в себе управляющую информацию для отправителя. Эта информация может задаваться системной службой и для приложения может быть недоступной.
RESERVE
Вызов: RESERVE( session-id, [ receiver_address , ]
[ CONF_flag, ] [ Policy_data, ]
style, style-dependent-parms )
Получатель использует этот вызов, для того чтобы осуществить или модифицировать резервирование для сессии `session-id'. Первое обращение RESERVE инициирует периодическую передачу сообщений Resv. Последующие вызовы RESERVE могут служить для модификации параметров предыдущих обращений.
Опционный параметр `receiver_address' может использоваться получателем в маршрутизаторе или ЭВМ с несколькими сетевыми интерфейсами; это IP-адрес одного из интерфейсов узла. Флаг CONF_flag должен быть установлен, если желательно подтверждение резервирования. Параметр `Policy_data' специфицирует управляющие данные получателя, в то время как параметр `style' указывает на стиль резервирования. Остальные параметры зависят от стиля; обычно они соответствуют спецификациям фильтра и flowspecs.
Отбой
Вызов: RELEASE( session-id )
Этот вызов удаляет состояние RSVP для сессии, указанной в session-id. Узел затем шлет соответствующие сообщения отмены (teardown) и прекращает рассылку сообщений обновления для session-id.
Вызовы Error/Event (ошибка/событие)
Общая форма вызова имеет вид:
Обращение: <Upcall_Proc>( ) -> session-id, Info_type,
information_parameters
"Upcall_Proc" представляет собой процедуру, чей адрес был дан при вызове SESSION. Это обращение может произойти асинхронно в любое время после вызова SESSION до вызова RELEASE и служит для индикации ошибки или события.
В настоящее время имеется пять типов обращений, отличающихся параметром Info_type. Выбор информационных параметров зависит от типа.
1. Info_type = PATH_EVENT
Обращение Path Event приводит к тому, что получение первого сообщения Path для данной сессии, указывает приложению получателя на наличие, по крайней мере, одного отправителя или на изменение состояние прохода.
Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type = PATH_EVENT,
Sender_Tspec, Sender_Template
[ , Adspec ] [ , Policy_data ]
Это обращение выдает спецификации Sender_Tspec, Sender_Template, Adspec и управляющую информацию из запроса Path.
2. Info_type = RESV_EVENT
Обращение Resv Event запускается в результате получения первого сообщения RESV, или как следствие модификации предшествующего состояния резервирования для данной сессии.
Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type = RESV_EVENT,
Style, Flowspec, Filter_Spec_list
[ , Policy_data ]
`Flowspec' – эффективное значение QoS, которое получено. Заметим, что сообщение Resv (стиль FF) может вызвать несколько обращений RESV_EVENT, по одному для каждого дескриптора потока.
3. Info_type = PATH_ERROR
Событие Path Error индицирует ошибку в информации отправителя, которая была специфицирована в запросе SENDER.
Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type=PATH_ERROR,
Error_code , Error_value ,
Error_Node , Sender_Template
[ , Policy_data_list ]
Параметр Error_code определяет ошибку, а Error_value может нести в себе некоторую дополнительную (возможно системно-зависимую) информацию об ошибке. Параметр Error_Node специфицирует IP-адрес узла, который обнаружил ошибку.
Параметр Policy_data_list, если он присутствует, содержит любые объекты POLICY_DATA из неудачного сообщения Path.
4. Info_type = RESV_ERR
Событие Resv Error указывает на ошибку в сообщении резервирования, в формирование которого приняло участие данное приложение.
Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type = RESV_ERROR,
Error_code , Error_value ,
Error_Node , Error_flags ,
Flowspec, Filter_spec_list
[ , Policy_data_list ]
Параметр Error_Node специфицирует IP-адрес узла, который обнаружил данное событие.
Имеется два флага Error_flags:
- InPlace
Этот флаг может быть равен 1 при ошибке контроля доступа для индикации наличия резервирования в узле, где произошла ошибка. Этот флаг устанавливается при ошибке и транспортируется сообщениями ResvErr.
- NotGuilty
Этот флаг может быть равен 1 при ошибке контроля доступа для индикации того, что запрошенная получателем спецификация flowspec оказалась меньше той, которая вызвала ошибку. Этот флаг устанавливается API получателя.
Filter_spec_list и Flowspec содержат соответствующие объекты из ошибки дескриптора потока. List_count специфицирует число FILTER_SPECS в списке Filter_spec_list. Параметр Policy_data_list содержит любые объекты POLICY_DATA из сообщения ResvErr.
5. Info_type = RESV_CONFIRM
Событие Подтверждение указывает, что получено сообщение ResvConf.
Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type = RESV_CONFIRM,
Style, List_count,
Flowspec, Filter_spec_list
[ , Policy_data ]
Параметры интерпретируются также как и для отклика Resv Error.
Хотя сообщения RSVP, указывающие на события path или resv могут приходить периодически, API должно послать соответствующие асинхронные отклики приложению только на первое из них или при изменении полученной информации. Все события, сопряженные с ошибками или подтверждениями должны доводиться до сведения приложения.
36. Интерфейс управления трафиком RSVP
Трудно представить общий интерфейс для управления трафиком, так как детали установления резервирования сильно зависят от технологии реализации канального уровня в интерфейсе.
Объединение RSVP-резервирований необходимо из- за мультикастной доставки данных, при которой информационные пакеты размножаются для отправки последующим узлам. В каждой такой точке размножения, RSVP должен объединять запросы резервирования от последующих узлов путем выбора “максимума” их спецификаций flowspecs. В данном маршрутизаторе или ЭВМ может присутствовать несколько таких точек объединения/размножения.
1. IP-уровень
Мультикастная IP рассылка выполняет разветвление потока на IP-уровне. В этом случае RSVP должен объединять резервирования, соответствующих выходных интерфейсов для последующей отправки запроса резервирования далее.
2. Сеть
Размножение пакетов может иметь место и после узла, например, в широковещательных сетях, в переключателях канального уровня или системе маршрутизаторов, не поддерживающих RSVP. В этих случаях RSVP должен объединять запросы резервирования от ряда предыдущих узлов, для того чтобы выполнить резервирование для одного выходного интерфейса
3. Драйвер канального уровня
В технологиях со множественным доступом размножение пакетов может осуществляться на уровне канального драйвера или сетевого интерфейса.
В общем, эти сложности не влияют на реализацию протокола RSVP, нужно только четко определить какие запросы резервирования следует объединить. Может оказаться желательным организовать реализацию RSVP из двух блоков: ядро, которое выполняет канально-независимую обработку и адаптационный уровень, учитывающий канальную специфику.
Выполнение резервирования
Вызов: TC_AddFlowspec( Interface, TC_Flowspec,
TC_Tspec, TC_Adspec, Police_Flags )
-> RHandle [, Fwd_Flowspec]
Параметр TC_Flowspec определяет желательное значение QoS для управления доступом;. Его значение вычисляется как максимум совокупности спецификаций flowspecs для последующих узлов (см. ниже описание вызова Compare_Flowspecs). Параметр TC_Tspec определяет эффективное значение спецификации отправителя Tspec Path_Te. Параметр TC_Adspec задает спецификацию Adspec. Параметр Police_Flags несет в себе три флага E_Police_Flag, M_Police_Flag и B_Police_Flag.
Если данный вызов оказался успешным, он устанавливает новый канал резервирования, соответствующий RHandle; в противном случае, он возвращает код ошибки. Код RHandle используется вызывающей программой для будущих ссылок на это резервирование. Если служба управления трафиком модифицирует flowspec, вызов вернет модифицированный объект Fwd_Flowspec.
Модификация резервирования
Вызов: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
TC_Tspec, TC_Adspec, Police_flags )
[ -> Fwd_Flowspec ]
Этот вызов используется для модификации существующего резервирования. TC_Flowspec передается блоку контроля разрешения. Если разрешения нет, текущая спецификация flowspec остается в силе. Соответствующие спецификации фильтров, если таковые имеются, остаются не затронутыми. Другие параметры определены также как и в TC_AddFlowspec. Если система модифицирует flowspec, вызов вернет также модифицированный объект Fwd_Flowspec.
Уничтожение спецификации Flowspec
Вызов: TC_DelFlowspec( Interface, RHandle )
Этот вызов ликвидирует существующее резервирование, включая спецификацию flowspec и все сопряженные спецификации фильтров.
Добавление спецификации фильтра
Вызов: TC_AddFilter( Interface, RHandle,
Session , FilterSpec ) -> FHandle
Этот вызов добавляет новую спецификацию фильтра для резервирования, заданного RHandle. Запрос посылается после успешного вызова TC_AddFlowspec. Этот вызов возвращает дескриптор фильтра FHandle.
Уничтожение спецификации фильтра
Вызов: TC_DelFilter( Interface, FHandle )
Этот вызов используется для удаления какого-либо фильтра, идентифицируемого FHandle.
Модификация OPWA
Вызов: TC_Advertise( Interface, Adspec,
Non_RSVP_Hop_flag ) -> New_Adspec
Этот вызов используется при OPWA и служит для вычисления выходной спецификации New_Adspec для заданного интерфейса. Битовый флаг Non_RSVP_Hop_flag должен устанавливаться в случае, когда демон RSVP обнаруживает, что предшествующий узел содержит один или более маршрутизаторов, не поддерживающих RSVP. TC_Advertise вставит эту информацию в New_Adspec для оповещениястить обнаружения такого узла.
Запрос резервирования
Обращение (отклик): TC_Preempt() -> RHandle, Reason_code
Для того чтобы выдать новый запрос резервирования, модули контроля разрешения и управления могут осуществить выделение квот для одного или двух существующих резервирований. Это вызовет отклик TC_Preempt() на каждое привилегированное RSVP резервирование, отправляя дескриптор резервирования RHandle и субкод причины.
37. Интерфейс маршрутизации RSVP
Реализация RSVP нуждается в следующей поддержке со стороны механизма маршрутизации узла.
Запрос маршрута
Для пересылки сообщений Path и PathTear процесс RSVP должен быть способен запрашивать процесс маршрутизации с целью получения маршрутных данных.
Ucast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag ) -> OutInterface
Mcast_Route_Query( [ SrcAddress, ] DestAddress,
Notify_flag )
-> [ IncInterface, ] OutInterface_list
В зависимости от протокола маршрутизации запрос может зависеть или нет от SrcAddress, т.е., от IP-адреса ЭВМ-отправителя, который является также IP-адресом источника сообщения. IncInterface характеризует интерфейс, через который ожидается прибытие пакета. Некоторые мультикастные протоколы маршрутизации могут не выдавать этот адрес. Если флаг Notify_flag = True, блок маршрутизации отправит сообщение о непреднамеренном изменении маршрута, если такое изменение произойдет.
Мультикастный маршрутный запрос может вернуть пустой список OutInterface_list, если за оговоренным маршрутизатором нет ни одного получателя. Запрос маршрутной информации может вернуть сообщение `No such route' (такой маршрут отсутствует) возможно, в результате временной рассогласованности (например, сообщение Path или PathTear для запрошенного маршрута не дошло). В любом случае локальное состояние должно быть актуализовано так, как это требуется в запросе, который не может быть переслан далее.
Сообщение об изменении маршрута
При маршрутном запросе с флагом Notify_flag = True, процесс маршрутизации может послать асинхронное сообщение процессу RSVP, который уведомляет об изменении определенного маршрута.
Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
OutInterface
Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,
[ IncInterface, ] OutInterface_list
Обнаружение списка интерфейсов
RSVP должен быть способен запоминать, какой реальный и виртуальный интерфейсы являются активными, а также их IP-адреса.
Должна быть предусмотрена возможность логической дезактивации интерфейса для RSVP. Когда интерфейс дезактивирован, сообщения Path не должны проходить через данный интерфейс, если сообщение RSVP получено, оно должно быть отброшено (возможно, с соответствующей записью в журнале операций).
38. Пакетные I/O интерфейсы RSVP
Реализация RSVP нуждается в следующей поддержке со стороны систем ввода/вывода пакетов и со стороны механизма переадресации узла.
Неизбирательный режим приема сообщений RSVP
Пакеты, полученные для IP-протокола (код 46) но не адресованные узлу, должны быть переправлены программе RSVP для последующей обработки. Сообщения RSVP переправляемые таким образом включают сообщения Path, PathTear и ResvConf. Эти типы сообщений несут в себе IP-опцию оповещение маршрутизатора (Router Alert), которая может быть использована для выделения этих пакетов в высокоскоростном канале переадресации. В качестве альтернативы узел может перехватывать все пакеты с кодом протокола 46.
В маршрутизаторе или ЭВМ с несколькими сетевыми интерфейсами идентификация интерфейса (реального и виртуального), через который получено заданное сообщение, также как IP-адрес источника и TTL, с которым оно получено, должна быть также доступна для процесса RSVP.
Спецификация выходного канала
RSVP должен уметь обеспечить посылку дейтограммы через специальный выходной интерфейс (реальный или виртуальный) в обход обычного механизма маршрутизации. Виртуальным каналом может быть, например, мультикастный туннель.
Спецификация адреса источника и TTL
RSVP должен быть способен специфицировать IP-адрес отправителя и TTL, которые могут использоваться при посылке сообщений Path.
Оповещение маршрутизатора
RSVP должен быть способен вызвать посылку сообщения Path, PathTear и ResvConf с опцией оповещения маршрутизатора (Router Alert).
39. Манипуляции, зависящие от вида услуг
Flowspecs, Tspecs и Adspecs являются объектами, совершенно недоступными для RSVP; их содержимое определено в документах спецификации услуг. Для того чтобы манипулировать этими объектами процесс RSVP должен иметь в своем распоряжении следующие программы, зависящие от типа услуг.
Сравнение спецификаций потоков
Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->
result_code
Возможный результат операции result_codes указывает: flowspecs равны, Flowspec_1 меньше, Flowspec_2 больше, flowspecs совместимы и можно вычислить LUB, или flowspecs не совместимы. Заметим, что, сравнивая две спецификации, мы косвенно сопоставляем Tspecs, которые они содержат. Хотя процесс RSVP не может сам осуществить разбор flowspec с целью извлечения Tspec, он может использовать вызов процедуры Compare_Flowspecs для косвенного вычисления Resv_Te.
Сравнение LUB Flowspecs
LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_LUB
Вычисление GLB Flowspecs
GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->
Flowspec_GLB
Сравнение Tspecs
Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code
Возможным результатом процедуры result_codes может быть: Tspecs равны или Tspecs не равны.
Сумма Tspecs
Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum
Этот вызов используется для вычисления Path_Te.
Демонстрируя стиль WF, показывает две ситуации, в которых требуется объединение
Рисунок 4.4.9.6.3, демонстрируя стиль WF, показывает две ситуации, в которых требуется объединение.
Каждый из двух узлов, следующих за интерфейсом IГ посылают независимые запросы резервирования RSVP, эти два запроса должны быть объединены в одну спецификацию flowspec (3B), которая используется для выполнения резервирования в интерфейсе IГ.
Резервирования для интерфейсов IB и IГ должны быть объединены, для того чтобы осуществить переадресацию запросов резервирования далее и получить спецификацию flowspec (4B).
Диаграмма излучения параболической антенны
Рисунок 3.3.7. Диаграмма излучения параболической антенны
Стоимость антенного комплекса обычно пропорциональна кубу диаметра антенны. Стандартная антенна intelsat имеет диаметр 30 м и угол излучения 0,010.
Спутниковые каналы используют диапазоны перечисленные в таблице 3.3.2.
Диапазоны частот различных телекоммуникационных каналов
Рисунок 3.3.1. Диапазоны частот различных телекоммуникационных каналов.
Если не используется направленная антенна и на пути нет препятствий, радиоволны распространяются по всем направлениям равномерно и сигнал падает пропорционально квадрату расстояния между передатчиком и приемником (удвоение расстояния приводит к потерям 6дБ). Радио каналы для целей передачи информации используют частотные диапазоны 902-928 МГц (расстояния до 10 км, пропускная способность до 64кбит/с), 2,4 ГГц и 12 ГГц (до 50 км, до 8 Мбит/с). Они используются там, где не существует кабельных или оптоволоконных каналов или их создание по каким-то причинам невозможно или слишком дорого. Более низкие частоты (например, 300 МГц) мало привлекательны из-за ограничений пропускной способности, а большие частоты (>30 ГГц) работоспособны для расстояний не более или порядка 5км из-за поглощения радиоволн в атмосфере. При использовании диапазонов 4, 5 и 6 следует иметь в виду, что любые препятствия на пути волн приведут к их практически полному поглощению. Для этих диапазонов заметное влияние оказывает и поглощение в атмосфере. Зависимость поглощения от длины волны радиоволн показана на Рисунок 3.3.1а.
Два объекта агрегатных маршрутов
Рисунок .29. Два объекта агрегатных маршрутов.
На Рисунок 29 показаны два объекта route. В первом примере объединяются более специфические префиксы 128.8.0.0/15 с проходами, начинающимися с AS2. Во втором примере агрегатированы некоторые маршруты, полученные от BGP и некоторые маршруты, полученные из OSPF.
Атрибут aggr-bndry является AS-выражением для номеров и наборов (см. раздел 5.6). Результат определяет набор AS, который задает границу объединения (aggregation). Если атрибут aggr-bndry опущен, исходная AS является единственной границей объединения. За пределами границы объединения экспортируется только это объединение, а более специфичные префиксы передаваться не могут. Однако в пределах границы, более специфичные префиксы также могут пересылаться.
Атрибут aggr-mtd определяет то, как формируется объединение. Его синтаксис показан ниже:
|
aggr-mtd: |
inbound |
|
| outbound [<as-expression>] |
где <as-expression> - выражение для номеров AS и наборов (см. раздел 5.6). Если <as-expression> опущено, по умолчанию предполагается AS-ANY. Если специфицировано экспортное объединение, более специфические префиксы будут присутствовать в пределах AS, а объединение будет сформировано перед отправкой на всех inter-AS границах с AS в <as-expression>, за исключением AS, которые находятся на границе объединения. Если специфицировано импортное объединение, объединение формируется на всех границах inter-AS прежде чем переносить маршруты в агрегатор AS. Заметим, что <as-expression> не может быть специфицировано с использованием импортного объединения. Если атрибут aggr-mtd опущен, он не выполняет функции "outbound AS-ANY".
|
route: 128.8.0.0/15 |
route: 128.8.0.0/15 |
|
origin: AS1 |
origin: AS2 |
|
components: {128.8.0.0/15^-} |
components: {128.8.0.0/15^-} |
|
aggr-bndry: AS1 OR AS2 |
aggr-bndry: AS1 OR AS2 |
|
aggr-mtd: outbound AS-ANY |
aggr-mtd: outbound AS-ANY |
Формат атрибута
Рисунок .3. Формат атрибута
Поле тип=1, длина ³
3. Поле строка имеет один или более октетов. NAS может ограничить максимальную длину имени пользователя, но рекомендуется, чтобы программа была способна обрабатывать как минимум 63 октета. Применяется несколько форматов имени пользователя:
| монолитный | Состоит только из буквенно-цифровых символов. Эта простая форма может использоваться для локального управления NAS. |
| простой | Состоит только из печатных символов ASCII. |
| name@fqdn SMTP адрес | Стандартное имя домена (Fully Qualified Domain Name; с или без завершающей точкой) указывает область, где применимо имя. |
| уникальное имя | Имя в формате ASN.1 используется в аутентификационных системах с общедоступным ключом. |
5.2. Пароль пользователя
Этот атрибут указывает на пароль аутентифицируемого пользователя или на вводимые пользователем данные в ответ на Access-Challenge. Этот атрибут используется только в пакетах Access-Request.
При передаче пароль шифруется. Пароль сначала дополняется нулями до границы кратной 16 октетам. Затем согласно алгоритму MD5 вычисляется хэш-функция. Это вычисление производится для потока октетов, состоящего из о бщего секретного пароля, за которым следует аутентификатор запроса (Request Authenticator). Для полученного кода и первых 16 октетов пароля производится операция XOR. Результат кладется в первых 16 октетов поля строка атрибута пароля пользователя.
Если пароль длиннее 16 символов, вычисляется вторая хэш-функция для потока данных, включающего в себя общий секретный пароль и результат предыдущей операции XOR. Полученный результат и вторые 16 октетов пароля объединяются с помощью операции XOR, а полученный код кладется во вторые 16 октетов поля строка атрибута User-Password. Если необходимо, эта операция повторяется. Следует только иметь в виду, что поле строка не может превышать 128 символов.
Данный метод заимствован из книги "Network Security" Кауфмана, Пелмана и Спесинера [4; стр. 109-110]. Более формализовано алгоритм можно описать следующим образом:
Берется общий секретный ключ S и псевдослучайный 128- битный аутентификатор запроса RA. Пароль разбивается на 16-октетные блоки p1, p2, …, pi. последний из них дополняется нулями до размера кратного 16 октетам. Далее реализуется алгоритм MD5. Берутся блоки шифрованного текста c(1), c(2), …, c(i), получаются промежуточные значения b1, b2, … bi:
| b1 = MD5(S + RA) | c(1) = p1 XOR b1 |
| b2 = MD5(S + c(1)) | c(2) = p2 XOR b2 |
| . | . |
| . | . |
| . | . |
| bi = MD5(S + c(I-1)) | c(i) = pi XOR bi |
При получении осуществляется обратный процесс и получается исходная форма пароля. В результате формируется атрибут, где в поле тип записан код 2, в поле длина число в интервале 18-130, а в поле строка - 16-128 октетов зашифрованного пароля.
5.3. Атрибут CHAP-пароль
Этот атрибут характеризует значение отклика, полученного через протокол PPP CHAP (Challenge-Handshake Authentication Protocol) от пользователя в ответ на вызов. Атрибут используется только в пакетах Access-Request. Значение CHAP-вызова хранится в атрибуте CHAP-Challenge (60), если таковой имеется, в противном случае - в поле аутентификатор запроса. Формат атрибута CHAP-Password показан на Рисунок .4.
Формат атрибута CHAP-Password
Рисунок .4. Формат атрибута CHAP-Password
Поле CHAP ID имеет один октет и содержит идентификатор CHAP из CHAP-отклика пользователя. Поле строка имеет 16 октетов и содержит CHAP-отклик пользователя.
5.4. Атрибут NAS-IP-Address
Этот атрибут указывает IP-адрес сервера NAS, который запрашивает аутентификацию пользователя. Атрибут применяется только в пакетах Access-Request. В пакете Access-Request должен присутствовать NAS-IP-адрес или NAS-идентификатор. Формат атрибута NAS-IP-Address представлен на Рисунок .5.
Формат атрибута NAS-IP-Address
Рисунок .5 Формат атрибута NAS-IP-Address
Поле адрес имеет протяженность 4 октета (IPv4).
5.5. Атрибут NAS-порт
Этот атрибут несет в себе номер порта NAS, который аутентифицируется пользователем. Атрибут применяется только в пакетах Access-Request. Заметим, что здесь термин порт определяет физическое соединение с NAS, а не используется в значении, принятом в протоколах TCP или UDP. NAS-порт или NAS-Port-Type (61) или оба эти атрибута должны присутствовать в пакете Access-Request, если NAS использует несколько портов. Формат атрибута NAS-порт представлен на Рисунок .6.
Формат атрибута NAS-порт
Рисунок .6. Формат атрибута NAS-порт
Диапазон кодов в поле значение составляет 0 - 65535.
5.6. Атрибут тип услуги (Service-Type)
Этот атрибут указывает на тип услуг, которые заказал или получит пользователь. Атрибут используется в пакетах Access-Request и Access-Accept. NAS не требует реализации всех типов услуг и должен обрабатывать атрибуты неизвестных или неподдерживаемых видов услуг, как запросы Access-Reject. Формат записи атрибута идентичен формату NAS-порт. Только поле тип=6. Коды поля значение перечислены в таблице .2..
Формат Cname
Рисунок 4.4.9.3.7. Формат Cname
Идентификатор cname имеет следующие свойства:
Так как характеризуемый случайным числом идентификатор ssrc может измениться, если обнаруживается конфликт или если программа перезапускается, элемент cname должен обеспечить связь между идентификатором SSRC и источником, которая должна оставаться неизменной.
Подобно идентификатору SSRC, идентификатор cname должен быть уникальным для каждого из участников RTP-сессии.
Чтобы обеспечить связь между мультимедийными средствами, используемыми одним и тем же участником в наборе взаимосвязанных RTP-сессий, cname должно быть зафиксировано для данного участника.
Для того чтобы обеспечить независимый мониторинг, Cname должно быть удобным средством идентификации источника как для программы, так и для человека.
Следовательно, cname должно по возможности получаться алгоритмически, а не вводиться вручную. Чтобы удовлетворить этому требованию следует использовать описанный ниже формат, если другой синтаксис или семантика не задана. Элемент cname должен иметь формат "user@host", или "host", если имя пользователя не доступно, как это бывает в однопользовательских системах. Для обоих форматов, "host" является либо полным именем домена ЭВМ, откуда поступают данные в реальном масштабе времени, форматированные согласно требованиям документов RFC-1034 [7], RFC-1035 [8] и раздела 2.1 RFC-1123 [9]; или стандартным ASCII-представлением цифрового, сетевого адреса интерфейса ЭВМ, используемого для RTP-обмена. Например, стандартное ASCII-представление IP-адреса (версия 4) в "точечно-цифровом" виде. Стандартное полное имя домена более удобно для человека и исключает необходимость посылать в дополнение элемент Name, но в некоторых обстоятельствах его может быть трудно или невозможно получить. Примерами могут служить "dwarf@sleepy.beauty.com" или "dwarf@192.166.148.9" для мультипользовательских систем. В системах, где нельзя получить имя пользователя, можно применить “sleepy.beauty.com" или "192.166.148.9".
Имя пользователя должно иметь форму, которая может быть использована в запросах "Finger" или "Talk", т.е., это скорее имя, вводимое при аутентификации, чем истинное имя пользователя. Имя ЭВМ не обязательно идентично электронному почтовому адресу участника.
Этот синтаксис не обеспечит уникальность имени в тех случаях, когда приложение позволяет пользователю сформировать несколько источников на своей ЭВМ. Такое приложение должно полагаться на SSRC для дополнительной идентификации источника, или на профайл, для которого приложение должно будет специфицировать синтаксис идентификаторов cname.
Если каждое приложение создает свои cname независимо, в результате можно получить дублирующие имена. Если необходимо осуществить связь между сессиями, работающими в разных средах, должны быть использованы специальные средства, которые с одной стороны обеспечат уникальность имен, а с другой припишут идентичные имена источникам, размещенным в одной ЭВМ, но работающих с разными средами.
Разработчики приложений должны учитывать возможность того, что использование сетевого адреса, например, для Net-10 (описано в документе RFC-1597 [10]) может привести к появлению имен дубликатов. Дубликаты имен могут возникать, когда ЭВМ с частными адресами, не имеющие выхода в Интернет, переадресуют свои RTP-пакеты в Интернет через транслятор RTP-уровня. (См. также RFC-1627 [11].) Для того чтобы разрешать такие конфликты приложение должно иметь средства для выработки и присвоения уникальных имен cname.
Name: Имя пользователя (Рисунок 4.4.9.3.8).
Формат элемента Email
Рисунок 4.4.9.3.9. Формат элемента Email
Адрес электронной почты должен иметь формат, согласующийся с требованиями документа RFC-822 [12], например, "yuri.semenov@itep.ru". Значение элемента Email предполагается неизменным в пределах сессии.
phone: Телефонный номер
Формат элемента LOC
Рисунок 4.4.9.3.11. Формат элемента LOC
Различная детализация этого элемента сильно зависит от приложения. Для использования во время конференций строки типа "Zuzino, Moscow" может быть достаточно, в то время как для активной системы поиска сотрудников приемлемой может стать строка "room 322, itep bl 180". Значение LOC предполагается неизменным на время сессии. Исключение могут составлять мобильные ЭВМ.
TOOL: Имя приложения или программного средства
Формат элемента Name
Рисунок 4.4.9.3.8. Формат элемента Name
Это настоящее имя, используемое для описания источника, напр., "Иван Дурак, russia.com". Оно может быть сформировано пользователем в произвольной форме. Для приложений типа конференций эта форма имени может быть наиболее желательной при отображении в списках участников и, следовательно, может посылаться более часто, чем любые другие элементы помимо cname. Такой приоритет может быть установлен профайлом. Значение name предполагается неизменным, по крайней мере в пределах сессии. В то же время не требуется, чтобы оно было уникальным для группы участников сессии.
Email: Адрес электронной почты (Рисунок 4.4.9.3.9).
Формат элемента Note
Рисунок 4.4.9.3.13. Формат элемента Note
Для этого элемента предлагается следующая семантика (она может быть определена профайлом). Элемент note предназначен для сообщений, характеризующих текущее состояние источника, напр., "on the phone, can't talk". Или, во время семинара этот элемент может быть использован для передачи темы обсуждения. Он может служить только для передачи необычной информации и не должен включаться в систематическую рассылку, так как замедлит скорость передачи отчетов. В частности, он не должен включаться в конфигурационный файл пользователя.
Так как может быть важно отобразить элемент Note (в случае, когда он активен), скорость, с которой передаются другие элементы (кроме cname), такие как Name, может быть уменьшена с тем, чтобы передать элемент Note. Когда сообщение становится не актуальным, элемент note передается еще несколько раз с той же частотой, но с длиной строки, равной нулю. Однако, получатели должны рассматривать элемент Note потерявшим актуальность, если они не получают его, например, на протяжении 20-30 RTCP-интервалов.
PRIV: Элемент частного расширения SDES
Формат элемента phone
Рисунок 4.4.9.3.10. Формат элемента phone
Телефонный номер должен иметь формат с символом плюс, замещающим международный код. Например, , "+7 095 129 9442" для номера в России.
LOC: Географический адрес пользователя
Формат элемента расширения PRIV
Рисунок 4.4.9.3.14. Формат элемента расширения PRIV
Этот элемент используется, для того чтобы определить экспериментальные или специфические для приложения расширения SDES. Элемент содержит префикс, включающий в себя субполя длины и строки префикса, за которыми следует строка значения, занимающая остальное пространство элемента, и несущая необходимую информацию. Поле длины префикса занимает 8 бит. Строка префикса представляет собой имя, определенное человеком, который сформировал элемент PRIV. Это имя должно быть уникальным и никакой другой элемент priv не может иметь такое же. Разработчик приложения может выбрать имя приложения плюс, если необходимо, дополнение.
Заметьте, что префикс занимает некоторое место, из числа 255 октетов элемента, по этой причине желательно, чтобы он был короче.
Префиксы SDESpriv не нужно регистрировать в IANA. Если некоторая форма элемента PRIV окажется достаточно универсальной, она должна быть приписана некоторому регулярному типу элемента SDES, зарегистрированному IANA, так что необходимость в префиксе отпадет. Это упростит использование и увеличит эффективность передачи.
Bye: Пакет завершения сессии RTCP
Формат элемента TOOL
Рисунок 4.4.9.3.12. Формат элемента TOOL
Строка, сообщающая имя и, возможно, версию приложения, формирующего поток, напр., "VC 2.1". Эта информация может быть полезной для отладочных целей и сходна с SMTP-заголовками. Предполагается, что значение TOOL остается постоянным в течение сессии.
Note: Уведомление/статус
Формат объекта
Рисунок 4.4.9.6.9. Формат объекта
Заголовок объекта имеет следующие поля:
Длина в байтах
16-битовое поле, содержащее полную длину объекта в байтах. Длина должна быть кратна 4 октетам, минимальное значение равно 4.
Class-Num
Идентифицирует класс объекта. Каждый класс объекта имеет свое имя, которое в данном документе записывается прописными буквами. Приложения RSVP должны распознавать следующие классы:
NULL
Объект NULL имеет код Class-Num равный нулю, а его C-тип игнорируется. Его длина должна быть, по крайней мере, равна 4, но может быть любой кратной 4. Объект NULL может появиться где угодно в последовательности объектов. Его содержимое получателем игнорируется.
SESSION
Содержит IP-адрес места назначения (DestAddress), идентификатор протокола IP, и обобщенный номер порта назначения, для того чтобы специфицировать сессию для других объектов, которые следуют далее. Этот класс должен присутствовать в любом сообщении RSVP.
RSVP_HOP
Несет в себе IP-адрес узла, поддерживающего протокол RSVP, который послал это сообщение, и дескриптор логического выходного интерфейса (LIH). Этот класс характеризует предшествующий узел (previous hop).
TIME_VALUES
Содержит значение периода обновления R, используемого отправителем сообщения. Необходим в каждом сообщении Path и Resv.
STYLE
Определяет стиль резервирования, а также зависящую от стиля информацию, которая не включена в объекты FLOWSPEC или FILTER_SPEC. Необходим в каждом сообщении Resv.
FLOWSPEC
Определяет желательный уровень QoS, в сообщениях Resv.
FILTER_SPEC
Определяет субнабор информационных пакетов сессии, которые должны получить желательный уровень QoS (специфицированный объектом FLOWSPEC), в сообщениях Resv.
SENDER_TEMPLATE
Содержит IP-адрес отправителя и, может быть, некоторые дополнительную информацию, идентифицирующую отправителя. Необходим в сообщениях Path.
SENDER_TSPEC
Определяет характеристики информационного трафика отправителя. Необходим в сообщениях Path.
ADSPEC
Несет в себе данные OPWA, в сообщении Path.
ERROR_SPEC
Специфицирует ошибку в сообщениях PathErr, ResvErr, или подтверждение в сообщении ResvConf.
POLICY_DATA
Несет в себе информацию, которая позволит локальному модулю, определяющему политику, принять решение, допустимо ли административно соответствующее резервирование. Может присутствовать в сообщениях Path, Resv, PathErr или ResvErr.
INTEGRITY
Несет в себе криптографические данные для аутентификации исходного узла и для верификации содержимого сообщения RSVP. Использование объекта INTEGRITY описано в ссылке [Baker96] в конце данного документа.
SCOPE
Несет в себе список ЭВМ-отправителей, к которым должно быть переадресовано данное сообщение. Может присутствовать в сообщениях Resv, ResvErr или ResvTear.
RESV_CONFIRM
Несет в себе IP-адрес получателя, который запросил подтверждение. Может присутствовать в сообщениях Resv или ResvConf.
C-Type
Тип объекта, уникален в пределах класса Class-Num.
Максимальная длина объекта равна 65528 байт. Поля Class-Num и C-Тип могут использоваться совместно, как 16-битовое число, для определения уникального типа для каждого из объектов.
Старшие два бита Class-Num используются для определения того, какие действия должен предпринять узел, если он не распознает Class-Num объекта.
18. Сообщения Path
Каждая ЭВМ-отправитель периодически отправляет сообщения Path для каждого из информационных потоков, берущих здесь свое начало. Это сообщение содержит объект SENDER_TEMPLATE, определяющий формат пакетов данных, и объект SENDER_TSPEC, специфицирующий характеристики трафика потока. Опционно сообщение может содержать объект ADSPEC, несущий в себе информацию о потоке (OPWA).
Сообщение Path направляется от отправителя к получателю по тому же маршруту, по которому движутся информационные пакеты. IP-адрес источника в сообщении Path должен характеризовать адрес отправителя, в то время как адрес места назначения должен быть равен DestAddress для текущей сессии. Эти адреса гарантируют, что сообщение будет корректно маршрутизовано даже через области сети, не поддерживающие RSVP.
Формат сообщения Path имеет следующий вид:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
Если присутствует объект INTEGRITY, он должен следовать непосредственно за стандартным общим заголовком. Не существует каких-либо иных ограничений порядка передачи, хотя упомянутое выше требование является рекомендательным. Число объектов POLICY_DATA может быть произвольным.
Объект PHOP (т.е., RSVP_HOP) каждого сообщения Path содержит адрес предшествующего узла, напр., IP-адрес интерфейса, через который только что было послано сообщение Path. Он также содержит дескриптор логического интерфейса (LIH).
Каждый узел, поддерживающий RSVP, вдоль пути перехватывает сообщение Path и обрабатывает его, с тем чтобы сформировать состояние пути для отправителя, заданного объектами SENDER_TEMPLATE и SESSION. Любой из объектов POLICY_DATA, SENDER_TSPEC и ADSPEC также записываются в состояние пути. Если случилась ошибка при обработке сообщения Path, посылается сообщение PathErr первичному отправителю сообщения Path.
Периодически процесс RSVP в узле сканирует состояние прохода, чтобы сформировать новые сообщения Path для посылки их получателям. Каждое сообщение содержит дескриптор, характеризующий одного отправителя, несет в себе IP-адреса отправителя и его источника.
Процесс RSVP переадресует и размножает (если требуется, например при мультикастинге) сообщения Path, используя маршрутную информацию, которую он получает от соответствующих процессов маршрутизации. Маршрут зависит от DestAddress сессии и для некоторых протоколов маршрутизации от адреса источника. Маршрутная информация обычно включает в себя список выходных интерфейсов, куда должно направляться сообщение Path. Так как каждый выходной интерфейс имеет свой IP адрес, сообщения Path, посланные разными интерфейсами содержат отличные адреса PHOP.
Кроме того, объекты ADSPEC, содержащие сообщения Path, будут отличаться для разных выходных интерфейсов.
Состояние пути для данной сессии и отправителя не обязательно должны иметь уникальные PHOP или уникальный входной интерфейс. Существует два случая, соответствующие мультикастной и уникастной сессиям.
Мультикастные сессии
Мультикастинговая маршрутизация позволяет иметь стабильное дерево распределения, в котором сообщения Path от одного и того же отправителя приходят от более чем одного PHOP, и RSVP должен быть готов поддерживать все такие состояния пути. RSVP не должен пересылать сообщения Path, которые прибывают через входной интерфейс, отличный от указанного в маршрутной таблице.
Уникастные сессии
В течение короткого периода времени, следующего после изменения уникастного маршрута, узел может получать сообщения Path от нескольких PHOP для данной сессии и отправителя. Узел не может надежно определить, какой из PHOP является правильным, хотя узел будет получать одновременно только один из PHOP. Одним из вариантов реализации RSVP является игнорирование PHOP и допущение для PHOP переключаться между имеющимися кандидатами. Другим вариантом является поддержание состояния пути для каждого PHOP и посылка сообщения Resv всем таким PHOP. В любом варианте ситуация является переходной, неиспользуемые состояния пути все равно будут удалены (явно или по таймауту).
19. Сообщения Resv
Сообщения Resv несут в себе запросы резервирования от узла к узлу, от получателей к отправителям в направлении противоположном движению потока данных. IP-адрес места назначения сообщения Resv является уникастным адресом предшествующего узла, полученным из состояния прохода. IP-адрес источника является адресом узла, который посылает сообщение. Сообщение Resv имеет следующий формат:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>
Если присутствует объект INTEGRITY, он должен непосредственно следовать за общим заголовком. За объектом STYLE следует список дескрипторов потоков. Объекты в списке дескрипторов должны следовать требованиям записанных в BNF.
Объект NHOP (напр., RSVP_HOP) содержит IP-адрес интерфейса, через который посылаются сообщения Resv, и LIH для логического интерфейса, где требуется резервирование.
Появление объекта RESV_CONFIRM сигнализирует о запросе подтверждения резервирования и несет в себе IP-адрес получателя, которому должен быть послан ResvConf. Число объектов POLICY_DATA не лимитировано.
Ниже приведены правила, которые специфицируют структуру дескриптора потока для каждого из стилей резервирования.
Стиль WF:
<flow descriptor list> ::= <WF flow descriptor>
<WF flow descriptor> ::= <FLOWSPEC>
Стиль FF:
<flow descriptor list> ::=
<FLOWSPEC> <FILTER_SPEC> |
<flow descriptor list> <FF flow descriptor>
<FF flow descriptor> ::=
[ <FLOWSPEC> ] <FILTER_SPEC>
Каждый запрос стиля FF описывается одной парой (FLOWSPEC, FILTER_SPEC), несколько таких запросов могут быть уложены в один список дескрипторов потока сообщения Resv. Объект FLOWSPEC может быть опущен, если он идентичен последнему такому объекту в списке; первый дескриптор потока стиля FF должен содержать FLOWSPEC.
Стиль SE:
<flow descriptor list> ::= <SE flow descriptor>
<SE flow descriptor> ::=
<FLOWSPEC> <filter spec list>
<filter spec list> ::= <FILTER_SPEC>
| <filter spec list> <FILTER_SPEC>
Набор отправителей (reservation scope), которым направляется конкретный запрос резервирования, определяется следующим образом:
Явный выбор отправителя
Резервирование переадресуется всем отправителям, чьи объекты SENDER_TEMPLATE, записанные в состоянии прохода соответствуют объекту FILTER_SPEC.
Произвольный выбор отправителей (wildcard)
Запрос с произвольным выбором отправителя соответствует всем отправителям, которые маршрутизированы на данный выходной интерфейс.
Когда сообщение Resv с произвольным выбором отправителя переадресуется более чем одному предыдущему узлу, в сообщение должен быть включен объект SCOPE. В этом случае список IP адресов для рассылки хранится именно в этом объекте.
Сообщение Resv, которое пересылается узлом, является в общем случае результатом объединения входящих сообщений Resv. Если одно из этих объединенных сообщений содержит объект RESV_CONFIRM и имеет число FLOWSPEC, больше чем FLOWSPEC всех других объединенных запросов резервирования, тогда этот объект RESV_CONFIRM переадресуется в виде исходящего сообщения Resv. Объект RESV_CONFIRM из одного из объединенных запросов (чья спецификация flowspecs равна, меньше или сравнима с объединенной спецификацией flowspec и которая не подвергнута блокаде) запустит генерацию сообщения ResvConf, содержащего RESV_CONFIRM. Объект RESV_CONFIRM в запросе, который подвергнут блокаде, не будет переадресован или возвращен, он будет аннулирован в текущем узле.
20. Сообщения отмены прохода
Получение сообщения PathTear (path teardown) аннулирует состояния прохода. Соответствующее состояние должно согласовываться с объектами SESSION, SENDER_TEMPLATE и PHOP. Кроме того, сообщение PathTear для мультикастной сессии может соответствовать только состоянию прохода для входного интерфейса, через который получено сообщение PathTear. Если соответствия состоянию прохода нет, сообщение должно быть отброшено без дальнейшей рассылки.
Сообщения PathTear инициализируются непосредственно отправителем или в результате таймаута состояния прохода в каком-либо узле и направляются всем отправителям. Уникастное PathTear не должно переадресовываться, если состояние прохода соответствует той же сессии и отправителю, но имеет другой PHOP.
Сообщение PathTear должно маршрутизоваться в точности также как соответствующие сообщения Path.
Следовательно, его IP- адрес места назначения должен совпадать с DestAddress, а его IP-адрес источника должен быть адресом отправителя из состояния прохода.
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition)
Сообщение PathTear может содержать в своем дескрипторе отправителя объект SENDER_TSPEC или ADSPEC, но они должны игнорироваться.
Удаление состояния прохода в результате получения сообщения PathTear или таймаута должно модифицировать состояние резервирования в данном узле. Эта модификация зависит от стиля резервирования. Например, предположим, что PathTear удаляет состояние прохода отправителя S. Если стиль специфицирует явный выбор отправителя (FF или SE), всякое резервирование со спецификацией фильтрования, соответствующей отправителю S, должно быть удалено; если стиль предусматривает произвольный выбор отправителя (WF), резервирование удаляется, если S является последним отправителем, участвующим в сессии. Эти изменения резервирования не должны вызвать немедленную посылку сообщения обновления Resv, так как сообщение PathTear уже вызвало необходимые изменения. Они не должны также вызвать отправку сообщения ResvErr, так как это может вызвать лавину таких сообщений.
21. Сообщения отмены Resv
Получение сообщения ResvTear (reservation teardown) удаляет соответствующие состояния резервирования. При этом проверяется соответствие объектов SESSION, STYLE и FILTER_SPEC, а также LIH в объекте RSVP_HOP. Если соответствие не обнаружено, сообщение ResvTear игнорируется. Сообщение ResvTear может отменить любой субнабор спецификаций фильтрации в состояниях резервирования стилей FF или SE.
Сообщения ResvTear отправляются получателями или любым узлом, в котором состояние резервирование аннулируется в результате таймаута, далее они движутся в направлении получателей.
Сообщение ResvTear должно маршрутизироваться аналогично соответствующим сообщениям Resv, а его IP-адрес места назначения является уникастным адресом предыдущего узла.
<ResvTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP>
[ <SCOPE> ] <STYLE>
<flow descriptor list>
<flow descriptor list> ::= (see earlier definition)
Объекты FLOWSPEC в списке дескрипторов потоков сообщения ResvTear будут игнорироваться и могут быть опущены. Сообщение ResvTear может включать в себя объект SCOPE, но он должен игнорироваться.
В зависимости от изменения состояния узла получение сообщения ResvTear может вызвать переадресацию этого сообщения, посылку модифицированного сообщения Resv или не вызвать никакого сообщения. Эти три случая могут быть проиллюстрированы для стиля резервирования FF на Рисунок 4.4.9.6.4.
Если получатель R2 посылает сообщение ResvTear для резервирования S3{B}, соответствующее резервирование удаляется из интерфейса (IГ) и посылается ResvTear для S3{B} интерфейсу (IБ).
Если получатель R1 посылает ResvTear для резервирования S1{4B}, соответствующее резервирование удаляется из интерфейса (IВ) и немедленно посылается модифицированное сообщение Resv FF( S1{3B} ) интерфейсу (IА).
Если получатель R3 посылает сообщение ResvTear для S1{B}, никаких изменений резервирования не происходит и никаких сообщений далее не посылается.
22. Сообщения об ошибке прохода
Сообщения PathErr (path error) несут в себе данные об ошибке в обрабатываемых сообщениях Path. Они направляются отправителям данных и маршрутизируются от узла к узлу, используя состояние прохода. При каждом шаге IP-адрес места назначения является уникастным адресом предыдущего узла. Сообщения PathErr не модифицируют состояния узлов, через которые проходят; они предназначаются только приложению отправителя.
<PathErr message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
[ <POLICY_DATA> ...]
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition)
Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил эту ошибку (Error Node Address).
Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA.
23. Сообщения об ошибках Resv
Сообщения ResvErr (reservation error) сообщают об ошибках при обработке сообщений Resv, или о спонтанном нарушении резервирования, напр., в результате административного вмешательства.
Сообщения ResvErr направляются соответствующим получателям, они маршрутизируются от узла к узлу с использованием состояния резервирования. В каждом из узлов в качестве IP-адреса места назначения используется уникастный адрес следующего узла.
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <POLICY_DATA> ...]
<STYLE> [ <error flow descriptor> ]
Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил ошибку (Error Node Address). Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA. Объект RSVP_HOP содержит адрес предыдущего узла, а объект STYLE копируется из сообщения Resv.
Следующие правила, зависящие от стиля, определяют структуру ошибки дескриптора потока.
Стиль WF:
<error flow descriptor> ::= <WF flow descriptor>
Стиль FF:
<error flow descriptor> ::= <FF flow descriptor>
Каждый дескриптор потока в сообщении Resv стиля FF должен обрабатываться независимо и для каждого из них, имеющего ошибку, должно посылаться отдельное сообщение ResvErr.
Стиль SE:
<error flow descriptor> ::= <SE flow descriptor>
Сообщение ResvErr стиля SE может представит список субнабора спецификаций фильтрации, которые вызвали ошибки, в соответствующем сообщении Resv.
Заметим, что сообщение ResvErr содержит только один дескриптор потока. Следовательно, сообщение Resv, которое содержит N > 1 дескрипторов потока (стиль FF) может быть причиной N сообщений ResvErr.
Вообще говоря, сообщение ResvErr следует пересылать всем получателям, которые могут быть причиной данной ошибки.
Конкретнее:
Узел, который обнаружил ошибку в запросе резервирования посылает сообщение ResvErr узлу, от которого получен ошибочный запрос резервирования.
Это сообщение ResvErr должно содержать информацию, необходимую для определения ошибки и для маршрутизации сообщения об ошибке последующим узлам. Такое сообщение, следовательно, включает в себя объект ERROR_SPEC, копию объекта STYLE и соответствующий дескриптор потока, где зафиксирована ошибка. Если ошибка является результатом отказа при попытке увеличить резервирование, тогда существующее резервирование должно быть сохранено и должен быть установлен бит-флаг InPlace в ERROR_SPEC сообщения ResvErr.
Узлы переадресуют сообщение ResvErr последующим узлам, которые имеют локальное состояние резервирования. Для резервирования с произвольным выбором отправителей имеется дополнительное ограничение на пересылку сообщений ResvErr, связанное с блокировкой возможных циклических маршрутов. Существует строгое правило рассылки сообщений при ошибке, связанной с разрешением доступа. Сообщение ResvErr, которое посылается, должно нести в себе спецификацию FILTER_SPEC соответствующего состояния резервирования.
Когда сообщение ResvErr достигает получателя, приложение должно принять объект STYLE, список дескрипторов потока и объект ERROR_SPEC (включая его флаги).
24. Сообщения подтверждения
Сообщения ResvConf посылаются в ответ на запрос подтверждения резервирования. Сообщение ResvConf посылается в результате появления объекта RESV_CONFIRM в сообщении Resv. Сообщение ResvConf посылается по уникастному адресу ЭВМ получателя, адрес берется из объекта RESV_CONFIRM.
<ResvConf message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <ERROR_SPEC>
<RESV_CONFIRM>
<STYLE> <flow descriptor list>
<flow descriptor list> ::= (see earlier definition)
Объект RESV_CONFIRM является копией объекта в сообщении Resv, который вызвал подтверждение. ERROR_SPEC используется только для переноса IP-адреса исходного узла в поле адрес узла с ошибкой (Error Node Address).
Равенство кода ошибки и значения (Value) нулю свидетельствует о подтверждении. Список дескрипторов потоков специфицирует конкретное резервирование, которое подтверждается. Это может быть субнабор из списка дескрипторов потоков Resv, для которого запрошено подтверждение.
25. Использование портов
Сессия RSVP определяется в норме тремя параметрами: DestAddress, ProtocolId, DstPort. Здесь DstPort является полем порта назначения UDP/TCP. DstPort может быть опущен (сделан равным нулю), если ProtocolId специфицирует протокол, который не имеет поля порта места назначения.
RSVP допускает любое значение для ProtocolId. Однако, реализации оконечных систем RSVP могут знать об определенных значениях для этого поля и в частности значения для UDP и TCP (17 и 6 соответственно). Оконечная система может выдать сигнал ошибки приложению, которая:
специфицирует ненулевое значение DstPort для протокола, который не имеет портов типа UDP/TCP, или
специфицирует нулевое значение DstPort для протокола, который имеет порты, специфицированные для UDP/TCP.
Спецификации фильтра и шаблоны отправителя определяют пару: SrcAddress, SrcPort, где SrcPort поле UDP/TCP порта. В некоторых случаях SrcPort может быть опущен (установлен равным нулю). Существуют следующие правила использования нулевого значения полей DstPort и/или SrcPort в RSVP.
1. Порты назначения должны быть взаимосогласованными.
Состояния прохода и резервирования для одного и того же DestAddress и ProtocolId должны иметь свои значения DstPort, которые все равны нулю или все не равны нулю. Нарушение этого условия в узле является ошибкой "конфликт портов назначения (Conflicting Dest Ports)".
2. Правило портов назначения.
Если DstPort в описании сессии равен нулю, все поля SrcPort, используемые для этой сессии, также должны быть равны нулю. При этом предполагается, что протокол не имеет портов типа UDP/TCP. Нарушение этого условия в узле вызовет ошибку "Bad Src Ports".
3. Порты источников должны быть взаимосогласованы.
ЭВМ- отправитель не должна посылать состояния прохода со значением SrcPort равным так и неравным нулю. Нарушение этого условия вызовет ошибку "Conflicting Sender Port". Заметим, что протокол не допускает произвольного назначения номеров портов (wildcard), т.е., нулевой порт не может соответствовать ненулевому порту.
26. Посылка сообщений RSVP
Сообщения RSVP посылаются от узла к узлу между RSVP-маршрутизаторами, поддерживающими этот протокол, в виде IP-дейтограмм с кодом протокола 46. IP-дейтограммы предназначены также для использования между оконечными системами и первыми/последними маршрутизаторами.
Сообщения Path, PathTear и ResvConf должны посылаться с опцией Router Alert IP [RFC-2113] в их IP-заголовках.
По прибытии RSVP-сообщения M, которое меняет статус, узел должен немедленно послать сообщение о модификации состояния. Однако это не должно привести к посылке сообщения через интерфейс, откуда пришло M (что может случиться, если приложение запустит процедуру обновления состояний для текущей сессии). Это правило предотвращает лавину пакетов в сетях с широковещательной рассылкой.
Каждое RSVP-сообщение должно пересылаться только в одной IP-дейтограмме. Если оно превосходит MTU, такая дейтограмма будет фрагментирована. Восстановление сообщения будет произведено узлом-получателем. Это имеет несколько следствий:
Одиночное RSVP-сообщение не должно превосходить максимального размера IP-дейтограммы, примерно 64K байт (на практике значительно меньше!).
Перегруженные сетевые области, которые не поддерживают RSVP, могут потерять отдельные фрагменты, а это приведет к потере всего сообщения.
RSVP использует свой механизм периодического обновления для предотвращения влияния случайной потери отдельных пакетов. При перегрузке сети, однако, существенные потери RSVP-сообщений могут вызвать серьезные нарушения при резервировании сетевых ресурсов. Для контроля задержек, связанных с обслуживанием очереди, и влияния потерь RSVP пакетов, маршрутизаторы должны быть сконфигурированы так, чтобы обеспечивать для данных целей приоритетное обслуживание.
Если RSVP- пакеты идут через область сети, где вероятность потери значительна, следует увеличить значение таймаутов.
Некоторые мультикастные протоколы маршрутизации обеспечивают туннели, которые организуют IP-инкапсуляцию мультикастных пакетов и их транспортировку через маршрутизаторы, которые не поддерживают мультикастную маршрутизацию. RSVP может работать через такие мультикастные туннели следующим образом:
Когда узел N направляет сообщение Path выходному логическому интерфейсу L, он включает в сообщение дескриптор логического интерфейса LIH (logical interface handle). Значение LIH содержится в объекте RSVP_HOP.
Следующий узел N' запоминает значение LIH в своем состоянии прохода.
Когда N' посылает сообщение Resv узлу N, он включает в него значение LIH из состояния прохода (содержится в объекте RSVP_HOP).
Когда сообщение Resv прибывает в N, его значение LIH выдает информацию, необходимую для осуществления резервирования в определенном логическом интерфейсе. Заметим, что узел N создает и интерпретирует LIH, которое совершенно не доступно для узла N'.
27. Исключение циклов сообщений RSVP
Переадресация сообщений RSVP должна исключать возможность образования петель. В спокойном состоянии сообщения Path и Resv направляются каждому узлу только раз за период обновления. Это исключает зацикливание пакетов, но имеется еще возможность петель "автоматического обновления". Такие петли автоматического обновления сохраняют состояние "вечно", даже если оконечные узлы прекращают их обновление до тех пор, пока получатели не покинут мультикастинг-группу и/или отправители прекратят посылку сообщения Path. С другой стороны сообщения об ошибке и об аннулировании (teardown) посылаются немедленно и могут служить причиной возникновения циклов.
Рассмотрим каждый тип сообщения.
Сообщения Path. Эти сообщения направляются точно тем же путем, что и информационные IP-пакеты. Следовательно, не должно возникать циклов для сообщений типа Path (за исключением циклов, связанных с переходными процессами установления маршрута).
Сообщения PathTear. Эти сообщения используют ту же маршрутизацию, что и сообщения Path и, следовательно, не могут образовывать циклов.
Сообщения PathErr. Так как сообщения Path не образуют циклов, они формируют состояние прохода, которое описывает обратный маршрут для каждого из отправителей, который не может иметь петель. Сообщения PathErr всегда направлены определенному отправителю и, следовательно, не могут образовывать циклов.
Сообщения Resv. Эти сообщения направлены определенному отправителю и не могут иметь циклов. Однако, сообщения Resv с произвольным выбором отправителя (wildcard) (стиль WF) имеет потенциал для запуска циклов обновления.
Сообщения ResvTear. Хотя сообщения ResvTear маршрутизируются также как и сообщения Resv. При повторном проходе по петле состояние будет отсутствовать (аннулировано), и любое сообщение ResvTear будет отброшено.
Сообщения ResvErr. Эти сообщения для стиля резервирования WF могут вызывать зацикливание по той же причине, что и для сообщений Resv.
Сообщения ResvConf. Эти сообщения направляются фиксированному уникастному получателю и не могут приводить к циклам.
Если топология не содержит петель, зацикливания сообщений Resv и ResvErr при произвольном выборе отправителя можно избежать, следуя приведенному выше правилу: состояние, которое получено через определенный интерфейс, никогда не должно переадресовываться через этот же интерфейс. Однако, когда топология содержит петли, необходимы дополнительные усилия для предотвращения циклов автоматического обновления для сообщений Resv и ResvErr с произвольным выбором отправителя. Решением этой проблемы может быть включение списка адресов получателей в объект SCOPE.
Когда сообщение Resv с стилем WF должно быть переадресовано определенному предыдущему узлу, следует определить новый список адресов для объекта SCOPE на основе аналогичного объекта, полученного с соответствующими сообщениями Resv. Если новый объект SCOPE пуст, сообщение не направляется предыдущему узлу. Правила для вычисления нового объекта SCOPE/ для сообщения Resv приведены ниже:
Образуется объединение наборов IP- адресов отправителей, перечисленных во всех объектах SCOPE состояния резервирования данной сессии. Если состояние резервирования от некоторых NHOP не содержит объектов SCOPE, должен быть создан заменяющий список отправителей, который и помещается в указанное объединение. Для сообщения, которое получено выходным интерфейсом OI, список замен представляет собой набор отправителей, которые маршрутизированы на этот OI.
Любые локальные отправители (т.е., любое приложение отправителя в данном узле) удаляются из этого списка.
Если объект SCOPE должен быть послан PHOP, следует удалить из набора любого отправителя, который не присылает данные через PHOP.
На Рисунок 4.4.9.6.10 показан пример Resv сообщений (стиль WF). Адресный список объекта SCOPE показан в квадратных скобках.
Интерфейс IА |
Интерфейс IБ |
Интерфейс IВ |
|||
Получает |
Отправляет |
Получает |
Отправляет |
Получает |
Отправляет |
| WF([S1,S2,S3]) | WF([S4]) | WF([S2,S3,S4]) | WF([S1]) | WF([S4,S1]) | WF([S2,S3]) |
Формат общего заголовка
Рисунок 4.4.9.6.8. Формат общего заголовка
В общем заголовке имеются следующие поля:
Vers. 4 бита – Номер версии протокола. В данном описании = 1.
Флаги: 4 бита - 0x01-0x08. Зарезервированы.
Флаги пока не определены.
Тип Msg. Тип сообщения (8 бит).
1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 = PathTear
6 = ResvTear
7 = ResvConf
Контрольная сумма RSVP: 16 бит
Дополнение по модулю один контрольной суммы сообщения (в процессе вычисления поле контрольной суммы считается нулевым). Если в поле записан нуль, это означает, что контрольная сумма не вычислялась.
Send_TTL: 8 бит
Значение TTL для протокола IP, с которым было послано сообщение.
Длина RSVP: 16 бит
Полная длина RSVP сообщения в байтах, включая общий заголовок и объекты переменной длины, которые за ним следуют.
17. Форматы объектов
Каждый объект состоит из одного или более 32-битных слов с 4-байтовым заголовком. Формат объекта показан на Рисунок 4.4.9.6.9:
Формат пакета
3. Формат пакета
Один пакет RADIUS вкладывается в одну UDP-дейтограмму [2]. При этом порт назначения равен 1812 (десятичное). При формировании отклика коды портов отправителя и получателя меняются местами. Формат пакета RADIUS показан на Рисунок .1. Разряды пронумерованы в порядке их передачи.
Формат пакета Bye
Рисунок 4.4.9.3.15. Формат пакета Bye
Пакет Bye указывает на то, что один или более источников покинули сессию.
Поля версия (V), заполнитель (P) и длина имеют то же назначения что и в случае SR-пакетов
Тип пакета (PT): 8 бит
Содержит код 203, который указывает на то, что это RTCP пакет Bye.
Число источников (SC): 5 бит
Число фрагментов SSRC/CSRC, содержащихся в данном bye-пакете. Значение нуль допустимо, но бесполезно.
Если пакет bye получен смесителем, он переадресует этот пакет с идентификаторами SSRC/CSRC без изменений. Если сам смеситель отключается, он должен послать пакет Bye, перечислив все источники, вносившие вклад в поток, с которым он работал, а также свой идентификатор SSRC. Опционно пакет Bye может содержать 8-битовое число октетов, за которым следует текст соответствующей длины, объясняющий причину отключения, например "camera malfunction" или "RTP loop detected". Строка имеет то же кодирование, что описано для SDES. Если строка заполняет пакет до очередной 32-битовой границы, то в конце ее не будет нуля. В противном случае, пакет Bye дополняется нулевыми октетами.
app: RTCP-пакет, определенный приложением
Формат пакета отчета о приеме (RR)
Рисунок 4.4.9.3.4. Формат пакета отчета о приеме (RR)
Формат пакета отчета о приеме (RR) аналогичен формату SR пакета за исключением того, что поле типа содержит код 201 и опущены первые пять слов информации об отправителе (это NTP/RTP временные метки, а также число пакетов и октетов отправителя). Остальные поля имеют то же самое значение, как и для пакета SR.
Когда нет информации об отправке или приеме, в начало составного RTCP-пакета вставляется пустой RR-пакет (RC = 0).
Профайл должен определять специфические для приложения расширения в докладах получателей и отправителей, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно сообщаться. Этот метод предпочтительнее, чем описание нового типа RTCP-пакета, так как не требует дополнительных издержек:
меньше октетов в пакете (нет rtcp-заголовка или поля SSRC);
проще и быстрее разбор, так как приложение, работающее под управлением профайла, будет запрограммировано всегда ожидать поля расширения с известным их положением в пакетах отчетов.
Если необходима дополнительная информация, она должна быть включена в первую очередь в расширение для отчета отправителя, но не будет присутствовать в отчетах о приеме. Если должна быть подключена информация о получателях, эти данные могут структуризоваться в виде массива блоков дополнительно к существующему массиву блоков-отчетов, т.е., число блоков будет задано полем RC.
Ожидается, что качество обратной связи важно не только для отправителя и получателей, но и для независимых мониторов. Отправитель может модифицировать свою передачу на основе обратной связи, получатели могут определить, являются ли проблемы локальными, региональными или глобальными. Менеджер сети может использовать независимые мониторы, которые получают только RTCP-пакеты, а не соответствующие информационные RTP-пакеты, для оценки эксплуатационных параметров своей сети для мультикастного обмена.
На основе информации отправителя независимый монитор может вычислить усредненное значение потока данных, не получая этих данных. Если можно предположить независимость вероятности потери пакета от его размера, тогда число полученных пакетов, умноженное на средний размер поля данных, может дать оценку для пропускной способности получателя.
Для RTCP допустимо расщепление составных пакетов на пакеты нижележащего уровня, один зашифрованный и один открытый. Например, информация SDES может быть зашифрована, в то время как отчеты о приеме будут посылаться открыто для обеспечения мониторинга. В примере, представленном на Рисунок 4.4.9.3.5 информация SDES должна быть присоединена к RR-пакету, не содержащему отчета. Таким образом, соблюдается правило о том, что все составные пакеты начинаются с SR или RR пакетов.
Формат пакета RADIUS
Рисунок .1. Формат пакета RADIUS
Поле код содержит один октет и идентифицирует тип пакета RADIUS. Если получен пакет с неверным значением поля код, он молча отбрасывается.
Стандартизованы следующие значения поля код:
Код |
Назначение |
1 |
Запрос доступа (Access-Request) |
2 |
Доступ разрешен (Access-Accept) |
3 |
Доступ не разрешен (Access-Reject) |
4 |
Accounting-Request |
5 |
Accounting-Response |
11 |
Access-Challenge |
12 |
Сервер состояния (экспериментальный) |
13 |
Клиент состояния (экспериментальный) |
255 |
Зарезервировано |
Коды 4 и 5 будут описаны в документе [RFC-2139]. Коды 12 и 13 зарезервированы для возможного использования.
Поле идентификатор имеет один октет, и служит для установления соответствия между запросом и откликом.
Поле длина имеет два октета. Оно определяет длину пакета, включая поля код, идентификатор, длина, аутентификатор и атрибуты. Октеты за пределом, указанным полем длина,
рассматриваются как заполнитель и игнорируются получателем. Если пакет короче, чем указано в поле длина, он должен быть молча выкинут. Минимальная длина равна 20, а максимальная - 4096.
Поле аутентификатор имеет 16 октетов. Старший октет пересылается первым. Этот параметр служит для аутентификации отклика от сервера RADIUS, и используется в алгоритме сокрытия пароля.
В пакетах Access-Request, значение поля аутентификатор равно 16-октетному случайному числу, называемому аутентификатор запроса. Его значение должно быть непредсказуемым и уникальным на протяжении жизни секретного пароля, совместно используемого клиентом и RADIUS-сервером.
Значение аутентификатора запроса в пакете Access-Request должно быть также непредсказуемым, чтобы исключить возможные атаки.
Хотя протокол RADIUS не может исключить всех возможных атак, в частности с использованием подключения к линии в реальном масштабе времени, но генерация псевдослучайных аутентификаторов все же обеспечивает относительную безопасность.
NAS и сервер RADIUS используют секретный пароль совместно. Этот секретный пароль и аутентификатор запроса пропускаются через хэширование MD5, чтобы получить 16-октетный дайджест, который объединяется посредством операции XOR с паролем, введенным пользователем, результат помещается в атрибут пароля пользователя пакета Access-Request.
Значение поля аутентификатор в пакетах Access-Accept, Access-Reject, и Access-Challenge называется аутентификатором отклика (Response Authenticator). Оно представляет собой однопроходную хэш- функцию MD5, вычисленную для потока октетов, включающих в себя: пакет RADIUS, начинающийся с поля код, и включающий поля идентификатор, длина, аутентификатор запроса из пакета Access-Request, и атрибуты отклика, за которыми следует общий секретный пароль. То есть ResponseAuth = MD5(Код+ID+длина+RequestAuth+атрибуты+секретный_пароль) где знак + означает присоединение.
Секретный пароль, совместно используемый клиентом и сервером RADIUS, должен быть достаточно большим и непредсказуемым, как хороший пароль. Желательно, чтобы секретный пароль имел, по крайней мере, 16 октетов. Сервер RADIUS должен использовать IP-адрес отправителя UDP-пакета, чтобы решить, какой секретный пароль использовать.
Когда используется переадресующий прокси-сервер, он должен быть способен изменять пакет при проходе в том или ином направлении. Когда прокси переадресует запрос, он может добавить атрибут Proxy-State, а при переадресации отклика, он удаляет атрибут Proxy-State. Так как ответы Access-Accept и Access-Reject аутентифицированы по всему своему содержимому, удаление атрибута Proxy-State сделает сигнатуру пакета некорректной. По этой причине прокси должен вычислить ее заново.
Атрибуты
Многие атрибуты могут быть записаны несколько раз, в этом случае порядок следования атрибутов одного и того же типа должен быть сохранен. Порядок атрибутов различных типов может быть изменен.
В данном документе регламентированы атрибуты для пакетов с полем код, равным 1, 2, 3 и 11. Чтобы определить, какие атрибуты допускаются для пакетов с полем код=4 и 5, смотри [9].
Формат пакета SDES
Рисунок 4.4.9.3.6. Формат пакета SDES
Пакет SDES состоит из заголовка и нескольких фрагментов, каждый из которых содержит элементы описания источника, соответствующего данному фрагменту (число фрагментов может быть равно нулю).
Поля версия (v), заполнитель (p) и длина имеют то же назначения что и в случае SR-пакетов.
Тип пакета (pt): 8 бит
Содержит константу 202, которая идентифицирует данный пакет как RTCP SDES.
Число источников (SC): 5 бит
Число фрагментов SSRC/CSRC, содержащихся в данном SDES-пакете. Значение нуль допустимо, но бесполезно.
Каждый фрагмент состоит из идентификатора SSRC/CSRC, за которым следует список элементов описания источника SSRC/CSRC (число элементов может равняться нулю). Каждый фрагмент начинается на 32-битовой границе. Каждый элемент состоит из 8-битового поля типа, 8-битового поля числа октетов, характеризующего длину текста, исключая эти 2 октета заголовка, и собственно текста. Заметьте, что текст не может содержать более 255 октетов, но это вполне согласуется с требованиями ограничений на полосу, выделяемую для RTCP-пакетов.
Текст кодируется согласно требованиям UTF-2, описанным в стандарте 10646 [5,6], annex F ISO. Эта кодировка известна также под названием UTF-8 или UTF-FSS. Она описана в документе "File System Safe UCS Transformation Format (FSS_UTF)", “X/open preliminary specification”, документ номер P316 и “Unicode Technical Report #4". US-ASCII являются модификациями данного кодирования и требуют определенных доработок. Присутствие многооктетного кодирования задается путем установления старшего бита октета символа равным 1.
Описания элементов плотно прилегают друг к другу, т.е., их описания не выравниваются на 32-битовые границы путем индивидуального заполнения. Текст не завершается нулем, так как мультиоктетное кодирование может включать в себя нули. Список элементов в каждом фрагменте завершается одним или несколькими нулевыми октетами, первый из которых интерпретируется как тип элемента нуль, завершающий список, а последующие служат для заполнения до 32-битовой границы. Фрагменты, содержащие только нулевые элементы (4 нулевых октета), допускаются, но бесполезны.
Оконечные системы посылают один пакет SDES, содержащий их собственный идентификатор источника (то же, что и SSRC в фиксированных RTP-заголовках). Смеситель посылает один пакет SDES, содержащий фрагмент для каждого источника, от которого поступает SDES-информация, или несколько SDES-пакетов описанного выше формата в случае, когда число таких источников больше 31.
Из числа SDES-элементов только cname является обязательным. Некоторые элементы, описанные ниже, могут оказаться полезными только для определенных профайлов, но типы элементов выделяются из общего кодового пространства, с тем чтобы обеспечить совместную работу различных приложений. Дополнительные элементы могут быть определены в профайле путем регистрации их кодов IANA.
cname: Канонический идентификатор конечной системы (Рисунок 4.4.9.3.7).
Формат пакета, задаваемого приложением
Рисунок 4.4.9.3.16. Формат пакета, задаваемого приложением
Пакет APP предназначен для экспериментального использования при разработке новых приложений или новых функций. Здесь не требуется регистрация типа пакета. APP-пакеты с не узнанными именами должны игнорироваться. После тестирования, когда предполагается широкое использование, рекомендуется новый APP-пакет переопределить без субтипа и поля имени, после чего его следует зарегистрировать в IANA (Internet Assigned Numbers Authority), как новый тип RTCP-пакета.
Поля версия (V), заполнитель (P) и длина имеют то же назначения что и в случае SR-пакетов.
Субтип: 5 бит
Может использоваться в качестве субтипа, допуская описание набора APP-пакетов с уникальным именем, или для любых данных, специфических для конкретного приложения.
Тип пакета (PT): 8 бит
Содержит код 204, который указывает на то, что это RTCP пакет APP.
Имя: 4 октета
Имя, выбираемое разработчиком, который определил набор APP-пакетов. Это имя должно быть уникальным и не совпадать ни с одним другим именем другого APP-пакета данного приложения. Разработчик приложения может использовать для данной цели имя приложения. При этом новые типы пакетов приложения будут отличаться друг от друга кодом субтипа. Имя интерпретируется как последовательность четырех ASCII-символов, где строчные и прописные буквы не являются тождественными.
Поле информация, зависящая от приложения имеет переменную длину.
Информация, зависящая от приложения используется в APP-пакетах опционно. Она интерпретируется приложением, а не самим RTP. Размер поля должен быть кратным 32 бит.
Обработка RTCP в трансляторах
Кроме переадресации информационных пакетов (иногда с некоторой модификацией) трансляторы и мультиплексоры должны также обрабатывать RTCP-пакеты. Во многих случаях они разделяют на составные части комбинированные RTCP-пакеты, полученные от оконечных систем, собирают SDES-информацию и модифицируют SR или RR-пакеты. Пересылка этой информации может инициироваться приходом пакета или RTCP-таймером транслятора или смесителя.
Транслятор, который не модифицирует информационные пакеты, например такой, который осуществляет связь между мультикастными и уникастными адресами, может просто переадресовывать RTCP-пакеты. Транслятор, который каким-то образом модифицирует поле данных, должен выполнить соответствующие преобразования в SR и RR-информации, так чтобы она отражала качество приема. Такие трансляторы не должны просто переадресовывать RTCP-пакеты. Вообще транслятор не должен объединять SR и RR-пакеты от различных источников, так как это ухудшит точность измерения задержки распространения, использующего поля LSR и DLSR.
Информация отправителя SR. Транслятор не генерирует своей собственной информации отправителя, а переадресует SR-пакеты, полученные из одной области и адресованные в другие области. SSRC остается неизменным, но, если необходима трансляция, информация отправителя должна быть модифицирована. Если транслятор изменяет кодировку данных, он должен изменить поле число октетов отправителя. Если он объединяет несколько информационных пакетов в один, то нужно изменить поле число пакетов отправителя. Если он изменяет частоту временных меток, нужно модифицировать поле временная метка RTP в SR-пакете.
Блоки отчетов о приеме SR/RR: Транслятор переадресует доклады о приеме, полученные из одной области сети в другие. Заметим, что эти сообщения движутся в направлении противоположном данным. SSRC при этом остается неизменным. Если транслятор объединяет несколько информационных пакетов в один выходной пакет, и, следовательно, изменяет номер по порядку, он должен позаботиться о модификации полей потерянных пакетов и наибольший номер из числа полученных пакетов.
Транслятор не нуждается в своем собственном SSRC-идентификаторе, но может и завести такой идентификатор, для того чтобы посылать отчеты о том, что получено. Такие отчеты будут посылаться во все области сети, подключенные к транслятору.
SDES. Трансляторы осуществляют переадресацию без изменения SDES-информации, полученной из сетевых областей, участвующих в сессии.
Но они могут, например, решить отфильтровывать некоторую информацию, если этого требуют ограничения пропускной способности. Транслятор, который генерирует свои собственные RR-пакеты, должен посылать SDES CNAME-информацию о самом себе в область сети, куда он шлет эти RR-пакеты.
BYE. Трансляторы переадресуют пакеты BYE без изменений. Трансляторы, имеющие свой собственный SSRC должны генерировать пакеты BYE с этим SSRC-идентификатором, если они намереваются прекратить свою работу по переадресации.
APP. Трансляторы переадресовывают APP-пакеты без каких-либо изменений.
Обработка RTCP в смесителях
Так как смеситель генерирует, свой собственный информационный поток, он не пропускает через себя SR или RR-пакеты и вынужден формировать новые пакеты для отправки в обоих направлениях.
Информация отправителя SR. Смеситель не пропускает через себя данные об отправителе от источников, которые он объединяет, так как характеристики потока при смешении кардинально меняются. Как источник синхронизации смеситель генерирует свои собственные SR-пакеты с информацией отправителя и посылает их в том же направлении, что и смешанный поток.
Блоки отчетов о приеме SR/RR. Смеситель генерирует свои собственные отчеты о приеме для каждой из сетевых областей и посылает их туда. Он не посылает эти отчеты о приеме другим областям и не переадресует отчеты из одной области в другую.
SDES. Смесители обычно переадресуют без изменений SDES-информацию, которую они получают из сетевых областей зоны обслуживания, но могут отфильтровывать любую SDES-информацию помимо CNAME в случае ограничения полосы пропускания. CNAME должны доставляться, чтобы обеспечить работу по обслуживанию столкновений идентификаторов SSRC. (Идентификатор в списке CSRC, сгенерированный смесителем может вызвать столкновение с SSRC-идентификатором, сформированным оконечной системой.) Смеситель должен послать SDES CNAME информацию о самом себе той сетевой области, куда он посылает SR или RR пакеты.
Так как смесители не переадресуют SR или RR пакеты, они обычно извлекают SDES-пакеты из составных RTCP-пакетов.Для того чтобы минимизировать издержки, фрагменты из SDES-пакетов могут быть уложены в один SDES-пакет, который вкладывается в SR или RR пакет, посылаемый смесителем.
Смеситель, который не вводит идентификаторы CSRC, может также воздерживаться от пересылки SDES CNAME. В этом случае пространства идентификаторов SSRC для обоих сетевых областей оказываются независимыми.
BYE. Смесители должны переадресовывать пакеты BYE. Они должны генерировать пакеты BYE со своим собственным идентификатором SSRC, если они намериваются прервать пересылку пакетов.
APP. Обработка APP-пакетов смесителями зависит от вида приложения.
Формат RARP-сообщения
Рисунок 4.4.8.1. Формат RARP-сообщения
Здесь обозначения те же, что и в описании ARP-формата. Значение n определяется числом, записанным в поле HA-Len, а m - числом из поля PA-Len. Для Internet PA-Len=4 и тип протокола=2048, а для Ethernet равно HA-Len=6 и тип оборудования=1. В RARP используется два кода операции. Код операции=3 используется для RARP-запросов, а код операции=4 - для RARP-откликов. В первом случае поле протокольный адрес отправителя и протокольный адрес адресата не определены. Обычно локальная сеть имеет несколько RARP-серверов, что позволяет загрузиться бездисковым машинам, даже если какой-то из серверов выключен или не исправен.
Формат расширения заголовка
Рисунок 4.4.9.2.2. Формат расширения заголовка
Если бит x в RTP-заголовке равен 1, то к заголовку добавлено расширение переменной длины, за которым может следовать список csrc. Расширение заголовка содержит 16-битовое поле длины, определяющее число 32-битных слов в расширении, исключая 4-октета заголовка расширения (т.о. значения поля длина, равное нулю вполне допустимо). Информационный заголовок RTP может иметь только одно расширение. Для того чтобы обеспечить работу различных приложений с различными расширениями заголовка или чтобы обеспечить работу с более чем одним типом расширений, первые 16 бит расширения заголовка остаются свободными для выбора идентификаторов или параметров. Формат этих 16 бит определяется спецификацией профайла, с которым работает приложение.
Кроме оконечных систем RTP поддерживает трансляторы и смесители, которые рассматриваются как промежуточные системы на уровне RTP.
RTP транслятор/смеситель соединяет две или более области на транспортном уровне. Обычно каждая область определяется сетью и транспортным протоколом (например, ip/udp), мультикаст-адресом или парой уникаст-адресов, а также портом назначения транспортного уровня. Одна система может служить транслятором или смесителем для нескольких RTP сессий.
Для того чтобы исключить зацикливание при использовании транслятора или смесителя следует придерживаться следующих правил:
Каждая из областей, соединенных транслятором или смесителем, участвующих в одной RTP-сессии должна отличаться от всех других, по крайней мере, одним параметром (протоколом, адресом, портом) или должна быть изолирована от других на сетевом уровне.
Следствием первого правила является то, что области не должны быть соединены более чем одним смесителем или транслятором.
Аналогично все оконечные системы RTP, которые взаимодействуют через один или более трансляторов или смесителей, принадлежат одной и той же ssrc-области, т.е., ssrc-идентификаторы должны быть уникальными для задействованных оконечных систем. Существует большое разнообразие трансляторов и смесителей, спроектированных для решения различных задач и приложений.
Некоторые служат для шифрования/ дешифрования несущих дейтограмм. Различие между смесителями и трансляторами заключается в том, что последние пропускают через себя потоки данных, при необходимости их преобразуя, а смесители объединяют несколько потоков в один.
Транслятор. Переадресует RTP-пакеты, не изменяя их SSRC-идентификаторы. Это позволяет получателям идентифицировать отдельные источники, даже если пакеты от всех источников проходят через один общий транслятор и имеют сетевой адрес транслятора. Некоторые типы трансляторов передают данные без изменений, другие кодируют данные и соответственно изменяют коды типа данных и временные метки. Приемник не может заметить присутствия транслятора.
Смеситель. Принимает потоки RTP-данных от одного или нескольких источников, может изменять формат данных, определенным образом объединяет потоки и затем формирует из них один общий поток. Так как объединяемые потоки не синхронизованы, смеситель производит синхронизацию потоков и формирует свою собственную временную шкалу для исходящего потока. Смеситель является источником синхронизации. Таким образом, все пакеты данных, переадресованные смесителем, будут помечены SSRC-идентификатором смесителя. Для того чтобы сохранить информацию об источниках исходных данных, смеситель должен внести свои SSRC-идентификаторы в список CSRC-идентификаторов, который следует за фиксированным RTP-заголовком пакета. Смеситель, который, кроме того, вносит в общий поток свою составляющую, должен включить свой собственный SSRC-идентификатор в CSRC-список для данного пакета.
Для некоторых приложений смеситель может не идентифицировать источники в CSRC-списке. Однако это создает опасность того, что петли, включающие эти источники, не смогут быть выявлены.
Преимуществом смесителя перед транслятором для аудио- приложений является то, что выходная полоса не превосходит полосы одного источника, даже когда в сессии на входе смесителя присутствуют несколько участников. Недостатком является то, что получатели с выходной стороны не имеют никаких средств для контроля того, какой из источников передает данные даже в случае наличия дистанционного управления смесителем.
Формат RPC-отклика
Рисунок 4.5.16.3. Формат RPC-отклика
Поле отклик, содержащее 1, указывает на то, что данное сообщение представляет собой отклик на поступивший ранее запрос. Поле статус содержит 0 в случае, если запрос воспринят. Запрос игнорируется при конфликте кодов RPC-версии или неудачной идентификации клиента. Поле флаг результата принимает значение 0 при успешной обработке запроса. Ненулевое значение этого поля указывает на ошибку.
Для записи параметров RPC-запросов, откликов, параметров и результатов выполнения процедуры используется внешнее представление данных (XDR – External Data Representation, RFC-1014). Отправитель, формируя RPC-сообщение, использует XDR-формат, а получатель преобразует данные из этого формата в традиционное представление.
Существует два базовых вида отклика: MSG_ACCEPTED (сообщение принято) и MSG_DENIED (не принято). Факт приема сообщения не означает выполнение запрошенных процедур, поэтому клиенту выдается дополнительная информация о результатах взаимодействия его запроса с удаленной системой. RPC может найти применение при построении больших распределенных информационных систем, баз данных и систем управления. XDR позволяет программисту избежать написания специальных программ преобразования. Например, в разных ЭВМ используются различные форматы представления чисел с плавающей запятой. XDP берет на себя согласование форматов и делает написание прикладных программ машинно-независимым.
Программы RPC-сервера используют большое число портов с нестандартизованными номерами. Для управления использованием этих портов имеется специальная программа (portmapper), которая имеет номер 100000, номер версии -2 и сама пользуется портом номер 111. Распределение номеров портов можно посмотреть с помощью программы:
/usr/etc/rpcinfo -p
|
program |
vers |
proto |
port |
|
[программа |
версия |
протокол |
порт |
название программы] |
100000 |
2 |
tcp |
111 |
portmapper |
100000 |
2 |
udp |
111 |
portmapper |
100029 |
1 |
udp |
664 |
keyserv |
100005 |
1 |
udp |
702 |
mountd (монтирует демон для NFS) |
100005 |
2 |
udp |
702 |
mountd |
100005 |
1 |
tcp |
705 |
mountd |
100005 |
2 |
tcp |
705 |
mountd |
100003 |
2 |
udp |
2049 |
nfs (сама NFS) |
100026 |
1 |
udp |
714 |
bootparam |
100024 |
1 |
udp |
717 |
status |
100024 |
1 |
tcp |
719 |
status |
100021 |
1 |
tcp |
720 |
nlockmgr (NFS-менеждер) |
100021 |
1 |
udp |
1031 |
nlockmgr |
100021 |
3 |
tcp |
724 |
nlockmgr |
100021 |
3 |
udp |
1032 |
nlockmgr |
100010 |
1 |
udp |
718 |
etherstatd |
100020 |
2 |
udp |
1033 |
llockmgr |
100020 |
2 |
tcp |
729 |
llockmgr |
100021 |
2 |
tcp |
732 |
nlockmgr |
100021 |
2 |
udp |
1034 |
nlockmgr |
100011 |
1 |
udp |
1041 |
rquotad |
100001 |
2 |
udp |
1042 |
rstatd |
100001 |
3 |
udp |
1042 |
rstatd |
100001 |
4 |
udp |
1042 |
rstatd |
100002 |
1 |
udp |
1043 |
rusersd |
100002 |
2 |
udp |
1043 |
rusersd |
100012 |
1 |
udp |
1044 |
sprayd |
100008 |
1 |
udp |
1045 |
walld |
Отсюда видно, что некоторые программы имеют несколько версий, а каждая комбинация номера программы, версии и протокола имеет свой собственный номер порта. В таблице 4.5.16.1 приведены ссылки на некоторые RPC-программы, используемые с NFS.
Формат RPC-запроса
Рисунок 4.5.16.2. Формат RPC-запроса
Поле идентификатор процедуры устанавливается программой-клиента, пакет-отклик использует тот же идентификатор, что позволяет контролировать их соответствие. Каждый новый RPC-запрос имеет новый идентификатор. В настоящее время номер версии rpc равен 2. Следующие три поля содержат переменные: номер программы, номер версии и номер процедуры, которые определяют тип запрашиваемой клиентом процедуры. В поле идентификатор клиента может быть записан цифровой код клиента, идентификатор группы или вообще ничего. Поле верификатор используется при пересылке зашифрованных сообщений. Формат параметров процедуры зависит от типа этой процедуры. Размер поля параметров равен длине UDP-дейтограммы минус сумма длин остальных полей, включая верификатор. В случае работы с TCP-сегментами, где длина пакета не определена, между TCP-заголовком и XID вводится 4-x октетное поле длины RPC-сообщения. Формат RPC-отклика для UDP-версии (
Формат RTCP пакета сообщения отправителя
Рисунок 4.4.9.3.2. Формат RTCP пакета сообщения отправителя
Число отчетов о приеме (RC): 5 бит
Число блоков отчетов о приеме, содержащихся в этом пакете. Допустимо значение нуль.
Тип пакета(pt): 8 бит
Содержит константу 200 для пакетов RTCP SR.
Длина: 16 бит
Длина rtcp-пакета в 32-битных словах минус один, включая заголовок и заполнитель.
ssrc: 32 бит
Идентификатор источника синхронизации для отправителя sr-пакета.
Вторая секция информации из 20 октетов присутствует в каждом пакете отправителя. Поля этой секции имеют следующие значения:
Временная метка NTP: 64 бита
Указывает абсолютное время, когда данный доклад был послан, оно может быть использовано в комбинации с временными метками, присланными в докладах о приеме другими получателями, для измерения RTT до этих получателей.
Временная метка rtp: 32 бита
Соответствует тому же времени, что и временная метка ntp, но измеряется в тех же единицах и с тем же произвольным смещением, что и временные метки информационных пакетов RTP. Это соответствие может использоваться для внутри- и межсредовой синхронизации для источников, чьи временные метки NTP синхронизованы, и может быть использовано получателями, независящими от среды для оценки номинальной задающей частоты RTP. Заметьте, что в большинстве случаев эти временные метки не будут равны временным меткам RTP в любых последовательных информационных пакетах.
Число пакетов отправителя: 32 бита
Полное число информационных RTP-пакетов, переданных отправителем от начала передачи до момента генерации SR-пакета. Число сбрасывается в нуль, если отправитель изменяет свой SSRC-идентификатор.
Число октетов отправителя: 32 бита
Полное число октетов поля данных (исключая заголовки и заполнители), переданных в информационных RTP-пакетах отправителем, начиная с начала передачи до момента генерации SR-пакета. Это число сбрасывается в нуль, когда отправитель меняет свой SSRC-идентификатор. Это поле может быть использовано для оценки среднего потока данных.
Третья секция состоит из нуля или более блоков отчета о приеме в зависимости от числа источников, пакеты от которых приняты с момента последнего отчета.
Оценка статистической вариации периода прихода RTP-пакетов, измеряемого с помощью временных меток и характеризуемого целым числом. Разброс периода прихода пакетов j определяется как усредненное отклонение разности D расстояния между пакетами со стороны получателя по отношению к той же величине для стороны отправителя. Эта величина характеризует относительный разброс времени транспортировки пакетов.
Если si равно временной метке i-го пакета RTP, а ri – время прибытия в единицах временной метки пакета i, тогда для двух пакетов i и j D может быть выражено как
di,j =(rj-ri)-(sj-si)=(rj-sj)-(ri-si)
Разброс времени доставки вычисляется непрерывно для каждого пребывающего от SSRC_n пакета i, используя разность D для данного пакета и предыдущего пакета i-1 согласно формуле
j=j+(|di-1,i|-j)/16
Вычисление разброса времени доставки позволяет мониторам, независимым от профайла, осуществлять интерпретацию докладов, приходящих от различных приложений. Это алгоритм является оптимальным первым приближением и масштабный параметр 1/16 обеспечивает приемлемое уменьшение влияние шума и разумную скорость сходимости [4].
Последняя временная метка (LSR) (last SR): 32 бита
Средние 32 бита из 64 во временной метке NTP, полученной как часть последнего отчета RTCP-отправителя (SR) об источнике SSRC_n. Если SR пока не получено, в поле заносится нуль.
Задержка с момента последнего SR (DLSR- delay of last sr): 32 бита
Задержка, выраженная в единицах 1/65536 секунды, между моментом получения последнего SR-пакета от источника SSRC_n и временем посылки блока отчета о приеме. Если ни одного пакета SR от ssrc_n пока не получено, в поле DLSR заносится нуль.
Пусть SSRC_r обозначает получателя, отправляющего отчет о приеме. Источник SSRC_n может вычислить циклическую задержку маршрута RTT для SSRC_r путем записи времени a, когда этот блок доклада о приеме был получен. Он вычисляет полное время RTT A-LSR, используя поле последней временной метки SR (LSR), и затем путем вычитания получает (A - LSR- DLSR).
Это проиллюстрировано на Рисунок 4.4.9.3.3.
Это может быть использовано в качестве меры расстояния до кластера получателей, хотя некоторые связи имеют весьма асимметричный характер задержек.
rr: rtcp-пакет отчета о приеме (RFC-1889)
[10 nov 1995 11:33:25.125] [10 nov 1995 11:33:36.5]
n sr(n) a=b710:8000 (46864.500 s)
---------------------------------------------------------------->
v ^
ntp_sec =0xb44db705 v ^ dlsr=0x0005.4000 ( 5.250s)
ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
(3024992016.125 s) v ^
r v ^ rr(n)
---------------------------------------------------------------->
||
(5.250 s)
a 0xb710:8000 (46864.500 s)
dlsr -0x0005:4000 ( 5.250 s)
lsr -0xb705:2000 (46853.125 s)
-------------------------------
delay 0x 6:2000 ( 6.125 s)
Формат
Рисунок 4.4.11. 3 Формат сообщений протокола RIP-2
Проблемы аутентификации в протоколе RIP-2 c использованием дайджестов MD5 обсуждаются в документе RFC-2082
Формат сообщения RIP
Рисунок 4.4.11.2. Формат сообщения RIP.
Регулярные коррекции. Каждые 30 секунд вся или часть таблицы маршрутизации посылается всем соседним маршрутизаторам. Могут посылаться и специальные запросы при локальном изменении таблицы. RIP достаточно простой протокол, но, к сожалению не лишенный недостатков:
RIP не работает с адресами субсетей. Если нормальный 16-бит идентификатор ЭВМ класса B не равен 0, RIP не может определить является ли не нулевая часть cубсетевым ID, или полным IP-адресом.
RIP требует много времени для восстановления связи после сбоя в маршрутизаторе (минуты). В процессе установления режима возможны циклы.
Число шагов важный, но не единственный параметр маршрута, да и 15 шагов не предел для современных сетей.
Протокол RIP-2 (RFC-1388, 1993 год) является новой версией RIP, которая в дополнение к широковещательному режиму поддерживает мультикастинг; позволяет работать с масками субсетей. На Рисунок 4.4.11.3 представлен формат сообщения для протокола RIP-2. Поле маршрутный демон является идентификатором резидентной программы-маршрутизатора. Поле метка маршрута используется для поддержки внешних протоколов маршрутизации, сюда записываются коды автономных систем. При необходимости управления доступом можно использовать первые 20 байт с кодом набора протоколов сети 0xFFFF и меткой маршрута =2. Тогда в остальные 16 байт можно записать пароль.
Формат записи атрибута
Рисунок .2. Формат записи атрибута
Поле тип имеет один октет. Возможные значения этого поля перечислены в документе RFC-1700 "Assigned Numbers" [3]. Значения 192-223 зарезервированы для экспериментального использования, значения 224-240 выделены для специальных реализаций, а значения 241-255 зарезервированы на будущее. Ниже в таблице 1. представлена спецификация стандартизованных значений атрибутов. Сервер и клиент RADIUS могут игнорировать атрибуты неизвестного типа.
