Принципы формирования кода отклика в системе SMTP

10.14 Принципы формирования кода отклика в системе SMTP

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

Код	Назначение
1yz	Промежуточный позитивный отклик. Команда воспринята. Отправитель должен послать следующую команду.
2yz	Позитивное подтверждение завершения операции. Можно посылать следующий запрос.
3yz	Позитивный промежуточный отклик, сходный с 1yz, используется в случае групповых команд.
4yz	Временный негативный отклик. Команда не исполнена, но характер ошибки временный и выполнение процедуры может быть позже повторено.
5yz	Окончательный негативный отклик. Команда не воспринята, запрошенная операция не выполнена и не будет выполнена.

Вторая цифра кода может иметь следующие значения:

x0z	Синтаксис - эти отклики относятся к синтаксическим ошибкам или к командам синтаксически корректным но примененным неправильно.
x1z	Информация - относится к командам, которые запрашивают информацию, например, статусную или справочную.
x2z	Соединения - относится к телекоммуникационному каналу.
x3z	Пока не определен.
x4z	Пока не определен.
x5z	Почтовая система - эти отклики индицируют статус получателя или отправителя почты.

Третья цифра уточняет смысл второй.

Протокол обратного адресного преобразования RARP

4.4.8 Протокол обратного адресного преобразования RARP

Обычно IP-адреса хранятся на диске, откуда они считываются при загрузке системы. Проблема возникает тогда, когда необходимо инициализировать рабочую станцию, не имеющую диска. Бездисковые системы часто используют операции типа TFTP для переноса из сервера в память образа операционной системы, а это нельзя сделать, не зная IP-адресов сервера и ЭВМ-клиента. Записывать эти адреса в ПЗУ не представляется целесообразным, так как их значения зависят от точки подключения ЭВМ и могут меняться. Для решения данной проблемы был разработан протокол обратной трансляции адресов (RARP – Reverse Address Resolution Protocol, RFC-0903, смотри также ниже описание протокола BOOTP). Форматы сообщений RARP сходны с ARP (см. Рисунок 4.4.8.1), хотя сами протоколы принципиально различны. Протокол RARP предполагает наличие специального сервера, обслуживающего RARP-запросы и хранящего базу данных о соответствии аппаратных адресов протокольным. Этот протокол работает с любой транспортной средой, в случае же кадра Ethernet в поле тип будет записан код 803516 (смотри таблицу 4.4.6.2).

Протокол реального времени RTP

4.4.9.2 Протокол реального времени RTP

В Интернет, также как и в некоторых других сетях, возможна потеря пакетов изменение их порядка в процессе транспортировки, а также вариация времени доставки в достаточно широких пределах. Мультимедийные приложения накладывают достаточно жесткие требования на транспортную среду. Для согласования таких требований с возможностями Интернет был разработан протокол RTP. Протокол RTP (См. RFC-2205, -2209, -2210, -1990, -1889; “RTP: A Transport Protocol for Real-Time Applications” H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на идеях, предложенных Кларком и Тенненхаузом [1], и предназначен для доставки данных в реальном масштабе времени (например, аудио- или видео). При этом определяется тип поля данных, производится нумерация посылок, присвоение временных меток и мониторирование доставки. Приложения обычно используют RTP поверх протокола UDP для того, чтобы использовать его возможности мультиплексирования и контрольного суммирования. Но RTP может использоваться и поверх любой другой сетевой транспортной среды. RTP поддерживает одновременную доставку по многим адресам, если мультикастинг поддерживается нижележащим сетевым уровнем.

Следует иметь в виду, что сам по себе RTP не обеспечивает своевременной доставки и не предоставляет каких-либо гарантий уровня сервиса (QoS. Этот протокол не может гарантировать также корректного порядка доставки данных. Правильный порядок выкладки информации может быть обеспечен принимающей стороной с помощью порядковых номеров пакетов. Такая возможность крайне важна практически всегда, но особое внимание этому уделяется при восстановлении передаваемого изображения.

На практике протокол RTP не отделим от протокола RTCP (RTP control protocol). Последний служит для мониторинга qos и для передачи информации об участниках обмена в ходе сессии.

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

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

Заголовок пакета RTP определяет, какой вид кодирования звука применен (PCM, ADPCM или LPC), что позволяет отправителю при необходимости сменить метод кодирования, если к конференции подключился новый потребитель с определенными ограничениями или сеть требует снижения скорости передачи.

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

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

Если в ходе конференции передается не только звук но и изображение, они передаются как два независимых потока с использованием двух пар UDP-портов. RTCP-пакеты посылаются независимо для каждой из этих двух сессий.

На уровне RTP не существует какой-либо взаимосвязи между аудио- и видео сессиями. Только RTCP-пакеты несут в себе одни и те же канонические имена участников.

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

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

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

Смесители и трансляторы могут выполнять и другие функции, например, преобразование IP/UDP пакетов в ST-II при видео конференциях.

Определения

Поле данных RTP: Информация, пересылаемая в пакете RTP, например фрагменты звука или сжатые видео данные.

Пакет RTP: Информационный пакет, содержащий фиксированный заголовок. Один пакет транспортного нижнего уровня, например UDP, обычно содержит один RTP-пакет, но это требование не является обязательным. Поле источников информации может быть пустым.

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

Транспортный адрес: Комбинация сетевого адреса и порта, которая идентифицирует конечную точку канала (например, IP-адрес и UDP-порт). Пакеты следуют от транспортного адреса отправителя к транспортному адресу получателя.

Сессия RTP: Период с момента установления группы участников RTP-обмена до ее исчезновения. Для каждого из участников сессия определяется конкретной парой транспортных адресов (сетевой адрес и номера портов для RTP и RTCP). Транспортный адрес места назначения может быть общим для всех участников сессии. Допускается реализация нескольких сессий для каждого из участников одновременно.

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

Информационный источник CSRC (contributing source): Источник потока RTP-пакетов, который вносит вклад в общий поток, формируемый RTP-смесителем. Смеситель вставляет список SSRC-идентификаторов, которые идентифицируют парциальные источники, в заголовок RTP-пакетов. Этот список называется CSRC-списком. Примером приложения может быть аудио-конференция, где смеситель отмечает всех говорящих, чей голос порождает исходящие пакеты. Это позволяет принимающей стороне идентифицировать говорящего, хотя все пакеты имеют один и тот же SSRC-идентификатор.

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

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

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

Монитор: Приложение, которое получает RTCP-пакеты, посланные участниками RTP-сессии, в частности диагностические сообщения, производит оценку состояния связи, копит долгосрочную статистику обмена.

Все целочисленные поля передаются в соответствии c сетевым порядком, т.е. старший байт следует первым (big-endian). Порядок передачи описан подробно в работе [3]. Если не оговорено обратного все цифровые константы являются десятичными. Все поля заголовка выравниваются по их естественным границам, т.е. 16-битовые поля имеют четное смещение, а 32-битные имеют адрес, кратный 4. Октеты-заполнители содержат нули.

Абсолютное время представляется с помощью временных меток в соответствии с форматом NTP (network time protocol), который характеризует время в секундах от начала суток (UTC) 1 января 1900 [4]. Полное разрешение временной метки NTP определяется 64-битовым числом с фиксированной запятой без знака. Целочисленная часть задается первыми 32 битами, а дробная часть последними. В некоторых полях, где допустимо более компактное представление, используются только средние 32 бита (16 бит целочисленная часть и 16 бит дробная).

Заголовок RTP-пакета имеет следующий формат (см. Рисунок 4.4.9.2.1).

Протокол резервирования ресурсов RSVP

4.4.9.6 Протокол резервирования ресурсов RSVP

Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin “Resource ReSerVation Protocol”, RFC-2205) используется ЭВМ для того, чтобы запросить для приложения определенный уровень качества сетевых услуг QoS (Quality of Service, например, определенный уровень полосы пропускания). RSVP используется также маршрутизаторами для доставки QOS-запросов всем узлам вдоль пути информационного потока, а также для установки и поддержания необходимого уровня услуг. RSVP-запросы обеспечивают резервирование определенных сетевых ресурсов, которые нужны, чтобы обеспечить конкретный уровень QOS вдоль всего маршрута транспортировки данных. Функция этого протокола крайне важна и многообразна, именно по этой причине это один из самых сложных протоколов.

RSVP запрашивает ресурсы только для одного из направлений трафика и только по указанию получателя. RSVP работает поверх IPv4 или IPv6. Протокол относится к числу управляющих, а не транспортных.

RSVP предназначен для работы с существующими и будущими маршрутными протоколами, управляющими как обычными, так и мультикастными потоками. В последнем случае ЭВМ сначала посылает IGMP-запрос, для того чтобы подключиться к мультикастинг-группе, а затем уже RSVP-сообщение для резервирования ресурсов по маршруту доставки.

Механизм обеспечения QOS включает в себя классификацию пакетов, административный контроль и диспетчеризацию. Классификатор пакетов определяет QoS класс (а иногда и маршрут движения) для каждого пакета. В процессе реализации резервирования RSVP-запрос проходит два местных управляющих модуля: "контроль доступа" и "управление политикой". Контроль доступа определяет, имеет ли узел достаточно ресурсов для удовлетворения поступившей заявки. Управление политикой определяет, имеет ли пользователь административное разрешение сделать данное резервирование. Если обе проверки завершились успешно, параметры передаются классификатору пакетов и интерфейсу канального уровня (диспетчеру пакетов).
Если же какой- либо из тестов не прошел, программа RSVP присылает прикладному процессу сообщение об ошибке.

Структура и содержимое параметров QoS документировано в спецификации RFC-2210. Так как число участников группы, а также топология связей меняется со временем, структура RSVP предполагает адаптацию ЭВМ и маршрутизаторов к этим изменениям. Для этой цели RSVP периодически посылает сообщения для поддержания необходимого состояния вдоль всего маршрута обмена. При отсутствии этих сообщений происходит тайм-аут и резервирование аннулируется. Обобщая, можно сказать, что RSVP имеет следующие атрибуты:

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

RSVP является симплексным протоколом, т.е., он выполняет резервирование для однонаправленного потока данных.

RSVP ориентирован на получателя, т.е., получатель данных инициирует и поддерживает резервирование ресурсов для потока.

RSVP поддерживает динамическое членство в группе и автоматически адаптируется к изменениям маршрутов.

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

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

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

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

RSVP может работать с IPv4 и IPv6.

Подобно приложениям маршрутизации и протоколам управления, программы RSVP исполняется в фоновом режиме. Схема работы процесса RSVP показана на Рисунок 4.4.9.6.1.

Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)

4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)

Номер раздела	Название раздела	Объем в страницах	Объем в кбайт
4.4.11	Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)	10	86
4.4.11.1	Внутренний протокол маршрутизации RIP	5	5
4.4.11.2	Протокол OSPF (алгоритм Дикстры)	16	164
4.4.11.3	Протокол IGRP	7	28
4.4.11.4	Внешний протокол BGP	10	89
4.4.11.5	Бесклассовая интердоменная маршрутизация (CIDR)	1	4
4.4.11.6	Автономные системы	1	4
4.4.11.7	Маршрутная политика	5	17
4.4.11.8	Язык описания маршрутной политики RPSL	46	196

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

Алгоритм маршрутизации должен обладать вполне определенными свойствами: надежностью, корректностью, стабильностью, простотой и оптимальностью. Последнее свойство не так прозрачно, как это может показаться на первый взгляд, все зависит от того, по какому или каким параметрам производится оптимизация. Эта задача иногда совсем не проста даже для сравнительно простых локальных сетей (смотри, например, Рисунок 4.4.11.1). Предположим, что поток данных между ЭВМ b и d, соединенных через концентратор (К) весьма высок, что окажет ощутимое влияние на скорость обмена между ЭВМ А и С. Но этот факт довольно трудно выявить, находясь в ЭВМ А или С. Внешне это проявится лишь как повышенная задержка и пониженная пропускная способность участка А-С.

Работа

2. Работа

Когда клиент сконфигурирован для использования RADIUS, любой пользователь предоставляет аутентификационные данные клиенту. Это может быть сделано с помощью традиционной процедуры login, когда пользователь вводит свое имя и пароль. В качестве альтернативы может использоваться протокол типаPPP, который имеет специальные пакеты, несущие аутентификационную информацию.

Когда клиент получил такую информацию, он может выбрать для аутентификации протокол RADIUS. Для реализации этого клиент формирует запрос доступа (Access-Request), содержащий такие атрибуты как имя пользователя, его пароль, идентификатор клиента и идентификатор порта, к которому должен получить доступ пользователь. При передаче пароля используется метод, базирующийся на алгоритме MD5 (RSA Message Digest Algorithm [1]).

Запрос Access-Request направляется по сети серверу RADIUS. Если в пределах заданного временного интервала не поступает отклика, запрос повторяется. Клиент может переадресовать запрос альтернативному серверу, если первичный сервер вышел из строя или недоступен.

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

Если хотя бы какое-то условие не выполнено, сервер посылает отклик "Access-Reject" (отклонение Access-Reject текст комментария.

Если все условия выполнены, сервер может послать отклик-приглашение (Access-Challenge).
Этот отклик может содержать текстовое сообщение, которое отображается клиентом и предлагает пользователю откликнуться на приглашение. Отклик-приглашение может содержать атрибут состояния (State). Если клиент получает Access-Challenge, он может отобразить текст сообщения и затем предложить пользователю ввести текст отклика. Клиент при этом повторно направляет свой Access-Request с новым идентификатором, с атрибутом пароля пользователя, замененным зашифрованным откликом. Этот запрос включает в себя атрибут состояния, содержащийся в приглашении Access-Challenge (если он там был). Сервер может реагировать на этот новый запрос откликами Access-Accept, Access-Reject, или новым Access-Challenge.

Если все условия выполнены, список конфигурационных значений для пользователя укладываются в отклик Access-Accept. Эти значения включают в себя тип услуги (например: SLIP, PPP, Login User) и все параметры, необходимые для обеспечения запрошенного сервиса. Для SLIP и PPP, сюда могут входить такие значения как IP-адрес, маска субсети, MTU, желательный тип компрессии, а также желательные идентификаторы пакетных фильтров. В случае символьного режима это список может включать в себя тип протокола и имя ЭВМ.

2.1. Запрос/Отклик

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

Пакет Access-Challenge обычно содержит сообщение-ответ, включая приглашение (challenge), которое должно быть отображено для пользователя. Обычно оно имеет форму числа и получается от внешнего сервера, который знает, какого типа аутентификатор должен быть применен для данного авторизованного пользователя и, следовательно, может выбрать псевдослучайное число заданной длины.

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

Если отклик соответствует ожидаемому значению, сервер присылает сообщение Access-Accept, в противном случае - Access-Reject.

Пример: NAS посылает серверу RADIUS пакет Access-Request с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (который может быть фиксированной строкой, как приглашение "challenge", но Access-Challenge с сообщениями состояния (State) и Reply-Message вместе со строкой "Challenge 12345678, enter your response at the prompt", которую отображает NAS. NAS предлагает ввести отклик и посылает серверу новый запрос NEW Access-Request (с новым идентификатором) с NAS-идентификатором, NAS-портом, именем пользователя, паролем пользователя (отклик, введенный пользователем, шифруется) и с тем же самым атрибутом состояния, который прислан с Access-Challenge. Сервер затем присылает назад Access-Accept или Access-Reject в зависимости от того, корректен ли отклик или следует послать еще один Access-Challenge.

2. Работа с PAP и CHAP

Для PAP, NAS берет идентификатор PAP и пароль и посылает их в пакете Access-Request в полях имя пользователя и пароль пользователя.. NAS может содержать атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, который предполагает использование услуг PPP.

Для CHAP NAS генерирует псевдослучайное приглашение (желательно 16 октетов) и посылает его пользователю, который возвращает CHAP-отклик вместе с идентификатором и именем пользователя CHAP. NAS посылает затем серверу RADIUS пакет Access-Request с именем CHAP-пользователя в качестве User-Name и с CHAP ID и CHAP-откликом в качестве CHAP-Password (атрибут 3). Случайный вызов может быть включен в атрибут CHAP-Challenge или, если он имеет длину 16 октетов, может быть помещен в поле аутентификатор запроса пакета запроса доступа. NAS может включать в себя атрибуты Service-Type = Framed-User и Framed-Protocol = PPP в качестве подсказки серверу RADIUS, указывая, что предполагается использование канала PPP.

Сервер RADIUS ищет пароль по имени пользователя, шифрует вызов и CHAP-вызов с помощью алгоритма MD5, затем сравнивает результат с CHAP-паролем. Если они совпадают, сервер посылает сообщение Access-Accept, в противном случае - Access-Reject.

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

2.3. Почему UDP?

Может возникнуть вопрос, почему RADIUS использует протокол UDP вместо TCP. UDP был выбран по чисто техническим причинам. Существует большое число моментов, которые нужно понять. RADIUS является протоколом, ориентированным на операции и имеющим ряд интересных особенностей:

1.	Если запрос к первичному аутентификационному серверу не прошел, он должен быть переадресован вторичному серверу. Чтобы удовлетворить этому, копия запроса должна храниться на уровне выше транспортного, с тем, чтобы позволить альтернативную попытку. Отсюда следует, что необходим таймер ретрансмиссии.
2.	Временные требования данного конкретного протокола значительно отличаются от тех, которые обеспечивает TCP.
3.	Природа данного протокола не требует контроля состояния, что упрощает применение протокола UDP.

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

2.4. UDP упрощает реализацию сервера.

В ранних реализациях RADIUS сервер поддерживал один процесс (single threaded). Это означает, что только один запрос принимался, обрабатывался и отправлялся. Это оказалось неприемлемым для сред, где механизм обеспечения безопасности требует определенного времени (1 или более секунд).Очередь запросов в сервере будет значительной и в средах, где сотни людей требуют аутентификации каждую минуту, время обслуживания запроса становится настолько большой, что начинает нервировать пользователей. Очевидным решением проблемы является многопроцессный сервер. Достичь этого проще всего с помощью UDP. Порождаются отдельные процессы для обслуживания каждого запроса, а эти процессы могут напрямую взаимодействовать с клиентом NAS путем отправки UDP-пакета.

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

Расширение RPSL

10. Расширение RPSL

Практика работы с языками описания маршрутной политики (PRDB [2], RIPE-81 [8], and RIPE-181 [7]) показывает, что язык описания должен быть расширяемым. Новые маршрутные протоколы или новые особенности существующих протоколов могут быть легко описаны, с помощью класса dictionary RPSL. Могут быть добавлены новые классы или новые атрибуты существующих классов.

Класс dictionary является первичным механизмом расширения RPSL. Объекты словаря определяют атрибуты маршрутной политики, типы и протоколы маршрутизации.

Чтобы добавить соответствующее определение rp-атрибута, протокола, или новых особенностей маршрутизатора, вводится модификация словаря RPSL.

Когда изменяется словарь, должна быть обеспечена полная совместимость. Например, в случае демпфирования осцилляций аршрута спецификация параметров делается опционной, когда ISP на данном уровне не требует деталей. Предполагается, что любое средство, базирующееся на RPSL, выполняет по умолчанию определенные действия, встретив атрибуты маршрутной политики, которые не распознаны (напр., выдает предупреждение или просто игнорирует). Следовательно, старые средства демпфирования осцилляций маршрутов, обнаружив неизвестные им параметры спецификации, должны эти параметры игнорировать.

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

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

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

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

RSVP в ЭВМ и маршрутизаторе

Рисунок 4.4.9.6.1. RSVP в ЭВМ и маршрутизаторе

1. Потоки данных

RSVP определяет сессию как поток данных с определенным местом назначения и заданным транспортным протоколом. Каждая сессия является совершенно независимой.

Сессия RSVP описывается тремя параметрами: DestAddress, ProtocolId [, DstPort]. DestAddress – IP-адрес места назначения информационных пакетов (уникаст или мультикаст). ProtocolId – идентификатор IP протокола. Опционный параметр DstPort – обобщенный порт места назначения, т.е., еще одна точка демультиплексирования на транспортном или прикладном уровне. DstPort может быть определено полем порта места назначения UDP/TCP.

Заметим, что, строго говоря, не обязательно включать в описание сессии DstPort, когда DestAddress является мультикастным, так как различные сессии могут всегда иметь различные мультикаст-адреса. Однако, DstPort необходим для того, чтобы разрешить более одной уникаст-сессии для одной и той же ЭВМ-получателя.

Для уникастной передачи может быть один получатель, но много отправителей; RSVP может выполнить резервирование для передачи много_точек -> одна_точка.

2. Модель резервирования

Простой запрос резервирования RSVP состоит из "flowspec" (спецификация потока) и "filter spec" (спецификация фильтра); эта комбинация называется "описателем потока". Спецификация flowspec определяет желательное значение QoS. Спецификация фильтра в сочетании со спецификацией сессии определяют тип набора пакетов. Спецификация flowspec используется для задания параметров диспетчеров в узлах, через которые транспортируется поток, а спецификация фильтра – для определения параметров классификатора пакетов. Информационные пакеты, адресованные конкретной сессии, но не удовлетворяющие какой-либо спецификации фильтра обрабатываются без гарантий обеспечения оговоренного QOS.

Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров:

"Rspec”, который определяет желательное значение QoS, и

"Tspec", который описывает информационный поток.

Форматы и содержимое Tspecs и Rspecs определяются общими моделями обслуживания [RFC-2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может использоваться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP).

Так как номера портов UDP/TCP используются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Это вызывает потенциально три проблемы.

Необходимо избегать IP-фрагментации потока данных, для которого желательно резервирование ресурсов. Документ [RFC-2210] специфицирует процедуру вычисления минимального MTU для приложений, использующих средства RSVP.

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

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

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

A. Резервирование канала

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

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

Б. Переадресация запроса назад

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

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

Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP, посланные вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.

3. Стили резервирования

Запрос резервирования включает в себя набор опций, которые в совокупности называются стилем.

Одна опция резервирования определяет способ резервирования различными отправителями в пределах одной сессии.

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

Стиль WF (Wildcard-Filter)

Стиль WF использует опции: "разделенного" резервирования и произвольного выбора отправителя ("wildcard"). Таким образом, резервация со стилем WF создает резервирование, которое делится между потоками всех отправителей. Это резервирование может рассматриваться как общая “труба", чей размер равен наибольшему из ресурсных запросов от получателей, и не зависит от числа отправителей. Стиль резервирования WF передается в направлении отправителей и автоматически распространяется на новых отправителей при их появлении.

Символически можно представить запрос резервирования стиля WF как:

WF( * {Q}),

где звездочка представляет произвольную подстановку при выборе отправителя, а Q – спецификация flowspec

Стиль FF (Fixed-Filter)

Стиль FF использует опции: "четкое" (distinct) резервирование и "явный" (explicit) выбор отправителя. Таким образом, простой запрос со стилем FF создает точно заданное резервирование для информационных пакетов от определенного отправителя, без совместного использования ресурса с другими отправителями в пределах одной и той же сессии. Символически простой запрос резервирования FF можно представить как:

FF(S{Q}),

где S – выбранный отправитель, а Q – соответствующая спецификация flowspec; эта пара параметров образуют дескриптор потока. RSVP позволяет применение нескольких простых стилей резервирования FF одновременно, при этом формируется список дескрипторов потоков:

FF(S1{Q1}, S2{Q2}, ...)

Полное резервирование в канале для данной сессии характеризуется суммой Q1, Q2, ... для всех отправителей, куда посланы запросы.

Стиль SE (Shared Explicit)

Стиль SE использует опции: "разделенное” (shared) резервирование и "явный" (explicit) выбор отправителя. Таким образом, стиль резервирования SE формирует одно резервирование, которое совместно используется несколькими отправителями. В отличие от стиля WF, SE позволяет получателю непосредственно специфицировать набор отправителей. Запрос резервирования SE, содержащий flowspec Q и список отправителей S1, S2, ... можно представить в символьной форме как:

SE((S1,S2,...){Q} )

Разделенное резервирование, выполненное с применением стилей WF и SE, пригодно для мультикастных приложений, где несколько источников данных редко осуществляют передачу одновременно. Пакетная передача голоса может служить примером разделенного резервирования, так как лишь ограниченное число людей говорят одновременно. Каждый получатель может направить запрос резервирования WF или SE на удвоенную полосу пропускания, необходимую одному отправителю, позволяя тем самым говорить обоим партнерам одновременно. С другой стороны стиль FF, который осуществляет четкое резервирование для потоков отдельных отправителей, подходит для передачи видеосигналов.

Правила RSVP не позволяют объединять разделенные резервирования с четкими резервированиями, так как эти модели абсолютно несовместимы. Не допускается также объединение явного и произвольного (wildcard) выбора отправителей, так как это может вызвать предоставление незаказанных услуг получателю, который указал тип услуг явно. Таким образом, стили WF, SE и FF не совместимы.

Можно моделировать эффект WF резервирования, используя стиль SE. Когда приложение запрашивает WF, процесс RSVP получателя может использовать местный статус для выполнения эквивалентного резервирования SE, которое в явном виде перечисляет всех отправителей. Однако резервирование SE вынуждает классификатор пакетов в каждом узле в явном виде выбрать каждого отправителя из списка, в то время как WF позволяет классификатору пакетов осуществить произвольный выбор отправителя и порта с помощью "wild card".

Когда список отправителей велик, стиль резервирования WF обеспечивает значительно меньшие издержки, чем SE.

4. Примеры стилей

На Рисунок 4.4.9.6.2. показан пример маршрутизатора с двумя входными интерфейсами IА и IБ, через которые проходят входные потоки, и двумя выходными интерфейсами IВ и IГ, через которые осуществляется переадресация входных потоков. Пусть существует три отправителя S1 (S2 и S3), подключенные к интерфейсам IА и IБ, соответственно. Имеется три получателя R1 (R2 и R3), которые маршрутизированы через выходные интерфейсы IВ и IГ, соответственно. Будем также предполагать, что интерфейс IГ подключен к широковещательной сети, а R2 и R3 достижимы через разные маршрутизаторы, не показанные на рисунке.

Здесь нужно специфицировать мультикастные маршруты в пределах узла, отображенного на Рисунок 4.4.9.6.2. Предположим сначала, что информационные пакеты от каждого из отправителей Si, показанных на рисунке, маршрутизованы на оба выходных интерфейса. При этих предположениях на рисунках 4.4.9.6.3, 4.4.9.6.4 и 4.4.9.6.5 проиллюстрированы стили резервирования WF, FF и SE, соответственно.

Схема для иллюстрации методики составления маршрутных таблиц g g g- Маршрутизаторы

Рисунок 4.4.11.2 Схема для иллюстрации методики составления маршрутных таблиц.

g1, g2, g3 - Маршрутизаторы

Примитивная таблица маршрутизации для приведенного примера может иметь вид (для маршрутизатора g2):

Сеть-адресат	Маршрут к этой сети
193.0.0.0	Прямая доставка
193.148.0.0	Прямая доставка
192.0.0.0	Через адрес 193.0.0.1
192.166.0.0	Через адрес 193.148.0.7

Заметно сокращает размер маршрутной таблицы маршруты по умолчанию. В этой схеме сначала ищется маршрут в таблицах, а если он не найден, пакет посылается в узел, специально выбранный для данного случая. Так, когда имеется только один канал за рубеж, неудачный поиск в таблице маршрутов по России означает, что пакет следует послать по этому каналу и пусть там с ним разбираются. Маршруты по умолчанию используются обычно тогда, когда маршрутизатор имеет ограниченный объем памяти или по какой-то иной причине не имеет полной таблицы маршрутизации. Маршрут по умолчанию может помочь реализовать связь даже при ошибках в маршрутной таблице. Это может не иметь никаких последствий для малых сетей, но для региональных сетей с ограниченной пропускной способностью такое решение может повлечь серьезные последствия. Экономия на памяти для маршрутных таблиц – дурной стиль, который не доведет до добра. Например, из-за такого рода ошибки довольно долго пакеты из Ярославля в Москву шли через США, я уже не говорю о случае, когда машины, размещенные в соседних комнатах Президиума РАН, вели обмен через Амстердам (правда, это было достаточно давно). Алгоритм выбора маршрута универсален и не зависит от протокола маршрутизации, который используется лишь для формирования маршрутной таблицы. Описание алгоритма выбора маршрута представлено ниже:

Извлечь IP-адрес (ID) места назначения из дейтограммы.

Вычислить IP-адрес сети назначения (IN)

IF INсоответствует какому-либо адресу локальной сети, послать дейтограмму по этому адресу;

else if in присутствует в маршрутной таблице, то послать дейтограмму к серверу, указанному в таблице;

else if описан маршрут по умолчанию, то послать дейтограмму к этому серверу;

else выдать сообщение об ошибке маршрутизации.

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

Одна из базовых идей маршрутизации заключается в том, чтобы сконцентрировать маршрутную информацию в ограниченном числе (в идеале в одном) узловых маршрутизаторов-диспетчеров. Эта замечательная идея ведет к заметному увеличению числа шагов при пересылке пакетов. Оптимизировать решение позволяет backbone (опорная сеть), к которой подключаются узловые маршрутизаторы. Любая as подключается к backbone через узловой маршрутизатор.

"Прозрачные" backbone не работают с адресами класса С (все объекты такой сети должны иметь один адрес, а для c-класса число объектов слишком ограничено). "Прозрачные" мосты трудно диагностировать, так как они не следуют протоколу ICMP (команда ping не работает, в последнее время такие объекты снабжаются snmp-поддержкой). За то они позволяют перераспределять нагрузку через несколько маршрутизаторов, что невозможно для большинства протоколов.

Схема оборудования радиоканала передачи данных

Рисунок 3.3.3. Схема оборудования радиоканала передачи данных

Схемы соединения радиомодемов и традиционных модемов совершенно идентичны (см. Рисунок 3.3.4).

Схема подключения к Интернет подвижных объектов

Рисунок 4.4.11.6. Схема подключения к Интернет подвижных объектов

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

Каждый внешний агент периодически широковещательно рассылает пакет-сообщение, содержащее его IP-адрес. "Вновь прибывшая ЭВМ" может подождать такого сообщения или сама послать широковещательный запрос наличия внешнего агента.

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

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

Домашний агент анализирует параметры аутентификации и, если все в порядке, процедура установления связи будет продолжена.

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

Когда пользователь покидает зону обслуживания данной LAN или MAN, регистрация должна быть анулирована, а ЭВМ должна быть автоматически зарегистрирована в новой зоне. Когда посылается пакет мобильному пользователю, "домашняя LAN", получив его, маршрутизирует пакет внешнему агенту, зарегистрировавшему данного пользователя. Этот агент переправит пакет адресату.

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

В локальных или корпоративных сетях иной раз возникает необходимость разослать некоторую информацию всем остальным ЭВМ-пользователям сети (штормовое предупреждение, изменение курса акций и т.д.).
Отправителю достаточно знать адреса всех N заинтересованных пользователей и послать им соответствующее сообщение. Данная схема крайне не эффективна, ведь обычная широковещательная адресация предлагает решение в N раз лучше с точки зрения загрузки сети (посылается одно а не N сообщений). Широковещательная адресация сработает, если в локальной сети нет маршрутизаторов, в противном случае широковещательные адреса МАС-типа заменяются на IP-адреса (что, впрочем, не слишком изящное решение) или применяется мультикастинг адресация. Маршрутизация для мультикастинга представляет собой отдельную задачу. Ведь здесь надо проложить маршрут от отправителя к большому числу получателей. Традиционные методы маршрутизации здесь применимы, но до крайности не эффективны. Здесь для целей выбора маршрута можно с успехом применить алгоритм "расширяющееся дерево" (spanning tree; не имеет циклических структур). Когда на вход маршрутизатора приходит широковещательный пакет, он проверяет, является ли интерфейс, через который он пришел, оптимальным направлением к источнику пакета. Если это так, пакет направляется через все внешние интерфейсы кроме того, через который он пришел. В противном случае пакет игнорируется (так как скорее всего это дубликат). Этот алгоритм называется Reverse Path Forwarding (переадресация в обратном направлении). Пояснение работы алгоритма представлено на Рисунок 4.4.11.7 (прямоугольниками на Рисунок обозначены маршрутизаторы). Секция I характеризует топологию сети. Справа показано дерево маршрутов для маршрутизатора I (sink tree). Секция III демонстрирует то, как работает алгоритм Reverse Path Forwarding. Сначала I посылает пакеты маршрутизаторам B, F, H, J и L. Далее посылка пакетов определяется алгоритмом.

Схема подключения объектов через радио-бриджи с помощью всенаправленной антенны

Рисунок 3.3.5. Схема подключения объектов через радио-бриджи с помощью всенаправленной антенны

Все соединяемые объекты (А, Б, В, и Г) должны быть оснащены радио-бриджами. Такая схема подключения эквивалентна с одной стороны кабельному сегменту ethernet, так как в любой момент времени возможен обмен лишь между двумя объектами; с другой стороны радио-бриджи А, Б, В и Г логически образуют много портовый бридж (или переключатель), что исключает загрузку локальных сетей объектов “чужими” пакетами. Модификации таких схем связи позволяют строить телекоммуникационные системы по схеме сотовых телефонных сетей.

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

Схема подключения радио-модемов

Рисунок 3.3.4. Схема подключения радио-модемов

Кроме уже указанных примеров перспективным полем применения радиомодемов могут стать “подвижные ЭВМ”. Сюда следует отнести и ЭВМ бизнесменов, клиентов сотовых телефонных сетей, и все случаи, когда ЭВМ по характеру своего применения подвижна, например, медицинская диагностика на выезде, оперативная диагностика сложного электронного оборудования, когда необходима связь с базовым отделением фирмы, геологические или геофизические исследования и т.д. Радиомодемы позволяют сформировать сеть быстрее (если не считать времени на аттестацию оборудования, получение разрешения на выбранную частоту и лицензии на использование данного направления канала). В этом случае могут стать доступными точки, лишенные телефонной связи (что весьма привлекательно для условий России). Подключение объектов к центральному узлу осуществляется по звездообразной схеме. Заметное влияние на конфигурацию сети оказывает ожидаемое распределение потоков информации. Если все объекты, подключенные к узлу, примерно эквивалентны, а ожидаемые информационные потоки не велики, можно в центральном узле обойтись простым маршрутизатором, имеющим достаточное число последовательных интерфейсов.

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

Схема подключения сервера к переключателю

Рисунок 4.1.1.4.6 Схема подключения сервера к переключателю

При использовании в сети большого числа мостов и/или переключателей может сформироваться топология связей, когда от одного сегмента к другому пакет может попасть более чем одним путем (см. Рисунок 4.1.1.4.7). Приведенная на рисунке схема неработоспособна и некоторые связи должны быть ликвидированы. В данном примере проблема может быть решена удалением мостов BR-2 и BR-3 или разрывом связей, помеченных символом “X”.

Проблему ликвидации связей, способных привести к зацикливанию, решает протокол STP (Spanning Tree Protocol; алгоритм предложен Пёлманом в 1992 году), который автоматически блокирует некоторые соединения, а в случае недоступности основного пути открывает эти заблокированные соединения, обеспечивая высокую надежность сети. STP является частью протокола мостов IEEE 802.1d.

При использовании протокола STP каждой связи присваивается при конфигурации определенный вес (чем меньше, тем выше приоритет). Мосты периодически рассылают специальные сообщения (BPDU - Bridge Protocol Data Unit), которые содержат коды их уникальных идентификаторов, присвоенные им при изготовлении. Мост или переключатель с наименьшим значением такого кода становится корневым ("корень дерева"). Затем выявляется наикратчайшее расстояние от корневого моста/переключателя до любого другого моста в сети. Граф, описывающий дерево наикратчайших связей, и является "расширяющимся деревом". Такое дерево включает все узлы сети, но необязательно все мосты/переключатели. Этот алгоритм функционирует постоянно, отслеживая все топологические изменения.

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

Схема реализации nfs-системы клиент-сервер

Рисунок 4.5.16.1. Схема реализации nfs-системы клиент-сервер

RPC (Remote Procedure Call, RFC-1057) процедура, разработанная SUN microsystem, в настоящее время используется практически во всех системах, базирующихся на UNIX. RPC - это программа, которая реализует вызов удаленных подпрограмм, способствуя построению распределенных программ. Она позволяет программе, называемой клиентом, послать сообщение серверу. Далее программа-клиент ожидает сообщения-отклика. RPC работает совместно с универсальной системой представления внешней информации XDP (External Data Representation). Сообщение запрос содержит параметры, которые определяют, что должно быть сделано на удаленной ЭВМ. В свою очередь отклик несет в себе информацию о результатах выполнения запроса.

RPC может работать как на TCP, так и UDP транспортных уровнях. Использование RPC-техники упрощает программирование, так как не требует написания сетевых программ. Если используется протокол UDP, все что связано с обработкой тайм-аутов, повторных пересылок и пр. спрятано в внутри системных RPC-модулей. Формат RPC-запроса для UDP-версии показан на Рисунок 4.5.16.2.

Схема сетевого моста

Рисунок 4.1.1.4.2. Схема сетевого моста

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

Функцию моста с определенными скоростными ограничениями может выполнять и обычная ЭВМ, имеющая два сетевых интерфейса и соответствующее программное обеспечение. Мосты при разумном перераспределении серверов и рабочих станций по сетевым сегментам позволяют выровнять и даже эффективно снизить среднюю сетевую загрузку. Когда на один из входов моста приходит пакет, производится сравнение адреса получателя с содержимым внутренней базы данных. Если адрес в базе данных отсутствует, мост посылает широковещательный запрос в порт, противоположный тому, откуда получен данный пакет с целью выяснения местоположения адресата. Понятно, что появление в субсетях a и Б двух объектов с идентичными адресами ни к чему хорошему не приведет. При поступлении отклика вносится соответствующая запись в базу данных. Параллельно анализируется и адрес отправителя и, если этот адрес в базе данных отсутствует, производится его запись в банк адресов соответствующего порта. В базу данных записывается также время записи адреса в базу данных. Содержимое базы данных периодически обновляется. К любой подсети может вести несколько путей, но для нормальной работы мостов и переключателей все пути кроме одного должны быть заблокированы. Функциональная схема работы моста показана на Рисунок 4.1.1.4.3. Сети, между которыми включается мост, не обязательно должны работать согласно идентичным протоколам. Возможны мосты между Ethernet и Token Ring или между Ethernet и ATM.

Схема сетевого повторителя

Рисунок 4.1.1.4.1 Схема сетевого повторителя

Все входы/выходы повторителя с точки зрения пакетов эквивалентны. Если повторитель многовходовый, то пакет пришедший по любому из входов будет ретранслирован на все остальные входы/выходы повторителя. Чем больше кабельных сегментов объединено повторителями, тем больше загрузка всех сегментов. При объединении нескольких сегментов с помощью повторителя загрузка каждого из них становится равной сумме всех загрузок до объединения. Это справедливо как для коаксиальных кабельных сегментов, так и для повторителей, работающих со скрученными парами (хабы - концентраторы). Некоторые повторители контролируют наличие связи между портом и узлом (link status), регистрируют коллизии и затянувшиеся передачи (jabber – узел осуществляет передачу дольше, чем это предусмотрено протоколом), выполняют согласование типа соединения (autonegotiation). В этом случае они обычно снабжены SNMP-поддержкой.

Для преодоления этого нежелательного явления используются сетевые мосты или переключатели. Мост соединяет два сегмента сети, при инициализации он изучает списки адресов устройств, подсоединенных к каждому из сегментов. В дальнейшем мост записывает в свою память эти списки и пропускает из сегмента в сегмент лишь транзитные пакеты. Существуют мосты, которые оперируют с физическими и с IP-адресами (cм. стандарт IEEE 802.1d).

Схема спутниковой связи VSAT

Рисунок 3.3.8. Схема спутниковой связи VSAT

Терминальные антены vsat имеют диаметр 1-1,5 м и излучаемую мощность 1-4 Вт, обеспечивая широкополосность до 64 кбит/с. Такие небольшие антенны не позволяют таким терминалам общаться непосредственно. На Рисунок 3.3.8. станции А и Б не могут непосредственно друг с другом. Для передачи данных используется промежуточная станция с большой антенной и мощностью (на Рисунок антенна В). Для создания постоянных каналов телекоммуникаций служат геостационарные спутники, висящие над экватором на высоте около 36000 км.

Теоретически три таких спутника могли бы обеспечить связью практически всю обитаемую поверхность земли (см. Рисунок 3.3.9.). Спутники, работающие на одной и той же частоте должны быть разнесены по углу на 2o. Это означет что число таких спутников не может быть больше 180. В противном случае они должны работать в разных частотных диапазонах. При работе в ku-диапазоне угловое расстояние между спутниками можно сократить до 1o. Влияние дождя можно минимизировать, используя далеко отстоящие наземные станции (размеры урагана конечны!).

Схема входового сетевого переключателя

Рисунок 4.1.1.4.4. Схема 8-входового сетевого переключателя

Существуют переключатели, работающие в режиме “на пролет” (cut through). Здесь первые биты пакета поступают на выход переключателя, когда последующие еще только приходят на вход. Задержка в этом случае минимальна, но переключатель пропускает через себя пакеты, поврежденные в результате столкновений. Альтернативой такому режиму является передача через буферную память (схема передачи SAF – Store And Forward). Поврежденные пакеты в этом режиме отбрасываются, но задержка заметно возрастает. Кроме того, буферная память должна иметься на всех входах (или общая многопортовая). При проектировании сетей следует иметь в виду, что переключатели превосходят маршрутизаторы по соотношению производительность/цена.

При проектировании локальной сети следует учитывать то обстоятельство, что узлы с самым напряженным трафиком должны располагаться как можно ближе к повторителю (мосту или переключателю). В этом случае среднее число коллизий в единицу времени будет ниже. По этой причине сервер должен располагаться как можно ближе к повторителю или другому сетевому устройству (см. Рисунок 4.1.1.4.6).

Схема внутренних связей переключателя может отличаться от приведенной на Рисунок 4.1.1.4.4 и иметь конфигурацию, показанную на Рисунок 4.1.1.4.5. Привлекательность такой схемы заключается в возможности реализации обмена по двум непересекающимся направлениям одновременно (См. LAN. Журнал сетевых решений, май 1998, том 4, N5, стр 21. Дмитрий Ганжа). От разделяемых к коммутируемым сетям). При этом эффективная пропускная способность многопортового переключателя может в несколько раз превосходить полосу пропускания сети, например, 10 Мбит/с.

Система аутентификации удаленных пользователей при подключении через модем RADIUS

4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS

(RFC-2138. Remote Authentication Dial In User Service, P. Vixie, S. Thomson, Y. Rekhter, J. Bound.)

Словарь RPSL

Рисунок .27. Словарь RPSL

На Рисунок .27 показан исходный словарь RPSL. Он имеет семь rp-атрибутов: pref для присвоения локального предпочтения воспринимаемым маршрутам; med для присвоения значения атрибуту MULTI_EXIT_DISCRIMINATOR BGP; dpa для присвоения значения атрибуту DPA BGP; aspath для присвоения значения атрибуту AS_PATH BGP; community для присвоения или проверки значения атрибута community BGP; next-hop для назначения следующих маршрутизаторов в случае статических маршрутов; cost для назначения цены статических маршрутов. Словарь определяет два типа: community_elm и community_list. Тип community_elm является либо 4-байтовым целым числом без знака, либо одним из ключевых слов Интернет, no_export или no_advertise. Целое число может быть специфицировано с помощью двух 2-байтовых чисел, разделенных двоеточием ":", чтобы разделить пространство кода community так, чтобы провайдер мог использовать номер AS первых двух байт, и определить семантику выбора последних двух байт.

Исходный словарь (Рисунок .27) определяет только опции для BGP (Border Gateway Protocol): asno и flap_damp. Обязательная опция asno является номером AS партнера-маршрутизатора. Опция flap_damp инструктирует маршрутизатор гасить осцилляции маршрутов [21], при импортировании маршрутов от маршрутизатора-партнера. Она может быть специфицирована с или без параметров. Если параметры опущены, принимаются значения по умолчанию:

flap_damp(1000, 2000, 750, 900, 900, 20000)

То есть, назначается штраф 1000 для каждого переключения маршрута, маршрут закрывается, когда штраф достигает 2000. Штраф снижается вдвое после 15 минут стабильного режима вне зависимости оттого открыт путь или нет. Закрытый маршрут используется вновь, когда штраф падает ниже 750. Максимальный штраф маршрута может достигать 20,000 (т.e. максимальное время закрытия маршрута после стабилизации ситуации составляет около 75 минут).

Действия политики и фильтров, использующих rp-атрибуты

Синтаксис действия политики или фильтра, использующего rp-атрибут x выглядит следующим образом:

x.method(arguments)

x "op" argument

где method представляет собой метод, а "op" – метод оператора rp-атрибута x. Если метод оператора используется при спецификации составного фильтра политики, он определяется раньше, чем операторы составных фильтров политики (т.e. AND, OR, NOT или оператор). rp-атрибуту pref может быть присвоено положительное целое число следующим образом:

pref = 10;

rp-атрибуту med может быть присвоено положительное целое число или слово "igp_cost" следующим образом:

med = 0;

med = igp_cost;

rp-атрибуту dpa может быть присвоено положительное целое число следующим образом:

dpa = 100;

Значением атрибута community BGP является список, который состоит из 4-байтовых целых чисел, каждое их которых характеризует "community". Следующие примеры демонстрируют, как добавлять новые значения community к этому rp-атрибуту:

community .= { 100 };

community .= { NO_EXPORT };

community .= { 3561:10 };

В последнем случае, 4-байтовое целое число, сформированное так, что наиболее значимые два байта равны 3561, а менее значимые два байта равны 10. Следующие примеры показывают, как удалять элементы из rp-атрибута community:

community.delete(100, NO_EXPORT, 3561:10);

Фильтры, которые используют rp-атрибут community могут быть определены, как это показано в следующем примере:

community.contains(100, NO_EXPORT, 3561:10);

community(100, NO_EXPORT, 3561:10); # shortcut

rp-атрибуту community может быть присвоено значение, соответствующее списку community следующим образом:

community = {100, NO_EXPORT, 3561:10, 200};

community = {};

В этом первом случае, rp-атрибут community содержит значения (communities) 100, NO_EXPORT, 3561:10 и 200. В последнем случае, rp-атрибут community обнулен. rp-атрибут community может быть сравнен со списком communities следующим образом:

community == {100, NO_EXPORT, 3561:10, 200}; # точное соответствие

Чтобы повлиять на выбор маршрута, rp-атрибут BGP as_path может быть сделан длиннее путем предварительной прописи номеров AS следующим образом:

aspath.prepend(AS1);

aspath.prepend(AS1, AS1, AS1);

Следующие примеры некорректны:

med = -50;	# -50 лежит вне диапазона
med = igp;	# igp не является одним из значений enum
med.assign(10);	# заданный метод не определен
community.append(AS3561:20);	# первый аргумент должен быть равен 3561. На Рисунок .28 показан более продвинутый пример, использующий rp-атрибут community. В этом примере, AS3561 базирует свое предпочтение при выборе маршрута на атрибуте community. Другие AS могут апосредовано влиять на выбор маршрутов AS3561 путем включения соответствующих значений communities в их оповещения о маршрутах.

aut-num: AS1

export:	to AS2 action community.={3561:90};
	to AS3 action community.={3561:80};
	announce AS1

as-set: AS3561:AS-PEERS

members: AS2, AS3

aut-num: AS3561

import:	from AS3561:AS-PEERS
	action pref = 10;
	accept community(3561:90)
import:	from AS3561:AS-PEERS
	action pref = 20;
	accept community(3561:80)
import:	from AS3561:AS-PEERS
	action pref = 20;
	accept community(3561:70)
import:	from AS3561:AS-PEERS
	action pref = 0;
	accept ANY

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

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

Развитие Интернет начиналось как средство общения и удаленного доступа (электронная почта, telnet, FTP). Но постепенно эта сеть превратилась в средство массовой информации, отличающееся тем, что операторы сети сами могут быть источниками информации и определяют, в свою очередь то, какую информацию они хотят получить.

Среди первых поисковых систем были archie, gopher и wais. Эти относительно простые системы казались тогда чудом. Использование этих систем показало их недостаточность и определенные врожденные недостатки: ограниченность зоны поиска и отсутствие управления этим процессом. Поиск проводился по ограниченному списку серверов и никогда не было известно, насколько исчерпывающую информацию получил клиент.

Первые WWW-системы работали в режиме меню (Mosaic появилась несколько позже) и обход дерева поиска производился вручную. Структура гиперсвязей могла иметь циклические пути, как, например, на Рисунок 4.5.14.1. Число входящих и исходящих гиперсвязей для любого узла дерева может быть произвольным.

Ссылки

[1]

Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992.

[2]

Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980.

[3]

Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

[4]

Kaufman, C., Perlman, R., and Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1.

[5]

Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, Lawrence Berkeley Laboratory, February 1990.

[6]

ISO 8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987.

[7]

Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP Multilink Protocol (MP)", RFC 1717, University of California Berkeley, Lloyd Internetworking, Newbridge Networks Corporation, November 1994.

[8]

Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes LAN Systems, Inc., MIT Laboratory for Computer Science, July 1992.

[9]

Rigney, C., "RADIUS Accounting", RFC 2139, January 1997.

[10]

B. Aboba, G. Zorn, RADIUS Authentication Client MIB. RFC-2618, June 1999.

[11]

G. Zorn, B. Aboba, RADIUS Authentication Server MIB. RFC-2619, June 1999.

[12]

B. Aboba, G. Zorn, RADIUS Accounting Client MIB. RFC-2620, June 1999.

[13]

G. Zorn, B. Aboba, RADIUS Accounting Server MIB. RFC-2621, June 1999.

Ссылки

[1]

Internet routing registry. procedures. http://www.ra.net/RADB.tools.docs/, http://www.ripe.net/db/doc.html.

[2]

Nsfnet policy routing database (prdb). Maintained by MERIT Network Inc., Ann Arbor, Michigan. Contents available from nic.merit.edu.:/nsfnet/announced.networks /nets.tag.now by anonymous ftp.

[3]

Alaettinouglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer, D., Terpstra, M. and C. Villamizer, "Routing Policy Specification Language (RPSL)", RFC 2280, January 1998.

[4]

C. Alaettinouglu, D. Meyer, and J. Schmitz. Application of routing policy specification language (rpsl) on the internet. Work in Progress.

[5]

T. Bates. Specifying an `internet router' in the routing registry. Technical Report RIPE-122, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.

[6]

T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation of ip routing policies in a routing registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.

[7]

Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M. and J. Yu, " Representation of IP Routing Policies in a Routing Registry", RFC-1786, March 1995.

[8]

T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. Representation of ip routing policies in the ripe database. Technical Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993.

[9]

Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC-1997, August 1996.

[10]

Crocker, D., "Standard for ARPA Internet Text Messages", STD 11, RFC-822, August 1982.

[11]

Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC-1519, September 1993.

[12]

D. Karrenberg and T. Bates. Description of inter-as networks in the ripe routing registry. Technical Report RIPE-104, RIPE, RIPE NCC, Amsterdam, Netherlands, December 1993.

[13]

D. Karrenberg and M. Terpstra. Authorisation and notification of changes in the ripe database. Technical Report ripe-120, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.

[14]

B. W. Kernighan and D. M. Ritchie. The C Programming Language. Prentice-Hall, 1978.

[15]

A. Lord and M. Terpstra. Ripe database template for networks and persons. Technical Report ripe-119, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.

[16]

A. M. R. Magee. Ripe ncc database documentation. Technical Report RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May 1997.

[17]

Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC-1034, November 1987.

[18]

Y. Rekhter. Inter-domain routing protocol (idrp). Journal of Internetworking Research and Experience, 4:61--80, 1993.

[19]

Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC-1771, March 1995.

[20]

C. Villamizar, C. Alaettinouglu, D. Meyer, S. Murphy, and C. Orange. Routing policy system security", Work in Progress.

[21]

Villamizar, C., Chandra, R. and R. Govindan, "BGP Route Flap Damping", RFC-2439, November 1998.

[22]

J. Zsako, "PGP authentication for ripe database updates", Work in Progress.

Приведенные коэффициенты, по сути, представляют

Таблица 4.5.14.2

Коэффициент	Название
	Коэффициент Дайса (dice)
	Коэффициент Джаккарда (jaccard)
	Косинусный коэффициент
	Коэффициент перекрытия

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

. Надо сказать, что обратное утверждение, вообще говоря, не верно.
Если P – множество объектов, предназначенных для кластеризации, то функция D определения степени различия документов – это функция, ставящая в соответствие

неотрицательное рациональное число. Функция определения степени различия d удовлетворяет следующим условиям:

Четвертое свойство неявно отображает тот факт, что функция определения степени различия между документами является, в некоторой степени, функцией, определяющей “расстояние” между двумя объектами и, следовательно, логично предположить, что должна удовлетворять неравенству треугольника. Данное свойство выполняется практически для всех функций определения степени различия.
Пример функции, удовлетворяющей свойствам 1 – 4:

, где

представляет собой разность множеств x и y. Она связана, например, с коэффициентами Дайса соотношением

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

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

двух векторов

для косинусного коэффициента соответствия

получаем следующую формулу:

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

она может быть определена как:

.
Если xi и xj - независимы, тогда

(и

). Дополнительно выполняется условие, что

, показывающее, что функция является симметричной.
Функция

интерпретируется как статистическая мера информации, содержащейся в документе

о документе

(и наоборот). Когда данная функция применяется для определения степени связи между двумя индексными терминами, например, i и j, тогда xi и xj являются бинарными переменными. Таким образом,

является вероятностью присутствия индексного термина i и, соответственно P(xi=0) является вероятностью его отсутствия.
Та степень взаимосвязи, которая существует между индексными терминами i и j вычисляется затем функцией

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

для определения степени соответствия (см. Jardine, N. and Sibson, R., Mathematical Taxonomy, Wiley, London and New York (1971)) между парами документов.
Как и в случае автоматической классификации документов, использование вероятностных методов при формировании кластеров содержит в себе достаточно высокий потенциал и представляет крайне интересную область для исследований.
Итак, для формирования кластеров необходимо использовать некую функцию соответствия для определения степени связи между парами документов из коллекции.
Постулируем теперь основную идею, на которой, собственно говоря, и построена вся теория кластерного представления коллекции документов. Гипотеза, приведшая к появлению кластерных методов, называется Гипотезой Кластеров и может быть сформулирована следующим образом: “Связанные между собой документы имеют тенденцию быть релевантными одним и тем же запросам”.
Базисом, на котором построены все системы автоматического поиска информации, является то, что документы, релевантные запросу, отличаются от нерелевантных документов.

Гипотеза кластеров указывает на целесообразность разделения документов на группы до обработки поисковых запросов. Естественно, она ничего не говорит о том, каким образом должно проводиться это разделение.
Проводился ряд исследований по поводу применения кластерных методов в поисковых системах. Некоторые отчеты приведены в работах Б. Литофски, Д. Крауча, Н. Привеса и Д. Смита, а также М. Фритше.
Кластерные методы, выбираемые для использования в экспериментальных поисковых системах должны удовлетворять некоторым определенным требованиям. Это:
методы, создающие кластеры, не должны существенно их изменять при добавлении новых объектов. То есть, должны быть устойчивы по отношению к объему коллекции.
методы должны быть устойчивы и в том отношении, что небольшие ошибки в описании объектов приводят к небольшим изменениям результата процесса кластеризации.
результат, производимый методами кластеризации, должен быть независимым от начального порядка объектов.
Основной вывод из вышесказанного состоит в том, что любой кластерный метод, не удовлетворяющий приведенным условиям, не может производить сколько-нибудь значащие экспериментальные результаты. Надо сказать что, к сожалению, далеко не все работающие кластерные методы удовлетворяют приведенным требованиям. В основном, это происходит из-за значительных различий между реализованными методами кластеризации от теоретически разработанных ад-хок алгоритмов.
Другим критерием выбора является эффективность процесса создания кластеров с точки зрения производительности и требований к объему необходимого дискового пространства.
Необходимость учета данного критерия находится, естественно, в сильной зависимости от конкретных условий и требований.
Возможно, использование процедур фильтрации базы данных таким образом, что из базы данных будет удаляться информация об индексных терминах, встречающихся в более чем, скажем 80% проиндексированных документов. Таким образом, список стоп-слов будет динамически изменяющимся. Как уже говорилось, использование списка стоп-слов может приводить к 30% уменьшению размеров индексных файлов.

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

Список литературы

1	Salton, G., “Automatic Text Analysis”, Science, 168, 335-343 (1970)
2	Luhn, H. P. “The automatic creation of literature abstracts”, IBM Journal of Research and Development, 2, 159-165 (1958)
3	Gerard Salton, Chris Buckley and Edward A. Fox, “Automatic Query Formulations in Information Retrieval”, Cornell University, http://cs-tr.cs.cornell.edu/
4	Tandem Computers Inc. “Three Query Parsers”, http://oss2.tandem.com /search97/doc/srchscr/tpappc1.htm
5	Object Design Inc., “Persistent Storage Engine PSE-Pro documentation”, http://www.odi.com/
6	Roger Whitney, “CS 660: Combinatorial Algorithms. Splay Tree”, San Diego State University. http://saturn.sdsu.edu:8080/~whitney/

Таблица

Таблица 3.3.1.

Номер	Название диапазона	Частота	Длина волны
1	Высокочастотный	3 – 30 МГц	100 – 10 м
2	VHF	50 - 100 Мгц	6 - 3 м
3	УВЧ (UHF)	400-1000 МГц	75-30 см
4	Микроволновый	3 109 – 1011 Гц	10 см – 3 мм
5	Миллиметровый	1011 – 1013Гц	3 мм – 0,3 мм
6	Инфракрасный	1012 – 6 1014	0,3 мм – 0,5 m

Далее следуют диапазоны видимого света, ультрафиолета, рентгеновских и гамма-лучей. Диапазоны часто, используемые различными каналами связи показаны на Рисунок 3.3.1.

Таблица

Таблица 4.5.14.1.

Релевантные документы

Нерелевантные документы

Общее количество документов

атрибутов

Таблица атрибутов

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

Частотные диапазоны, используемые для спутниковых телекоммуникаций

Таблица 3.3.2. Частотные диапазоны, используемые для спутниковых телекоммуникаций

Диапазон	Канал снижения (downlink)[ГГц]	Канал подъема (uplink)[ГГц]	Источники помех
С	3,7-4,2	5,925-6,425	Наземные помехи
ku	11,7-12,2	14,0-14,5	Дождь
ka	17,7-21,7	27,5-30,5	Дождь

Из таблицы видно, что передача ведется на более высокой частоте, чем прием сигнала со спутника. Обычный спутник обладает 12-20 транспондерами (приемопередатчиками), каждый из которых имеет полосу 36-50МГц, что позволяет сформировать поток данных 50 Мбит/с. Такая пропускная способность достаточна для получения 1600 высококачественных телефонных каналов (32кбит/c). Современные спутники используют узкоапертурную технологию передачи vsat (very small aperure terminals). Такие терминалы используют антенны диаметром 1 метр и выходную мощность около 1 Вт. При этом канал к спутнику имеет пропускную способность 19,2 кбит/с, а со спутника более 512 кбит/c. Непосредственно такие терминалы не могут работать друг с другом, разумеется через телекоммуникационный спутник. Для решения этой проблемы используются промежуточные наземные антенны с большим усилением, что, правда увеличивает задержку. Схема связей в технологии VSAT.

Cпецификация стандартизованных значений атрибутов

Таблица .1. Cпецификация стандартизованных значений атрибутов

Код	Назначение
1	Имя пользователя (User-Name)
2	Пароль пользователя (User-Password)
3	CHAP-пароль
4	NAS-IP-адрес
5	NAS-порт
6	Тип услуги (Service-Type)
7	Framed-Protocol
8	Framed-IP-адрес
9	Framed-IP-Netmask
10	Framed-Routing
11	Filter-Id
12	Framed-MTU
13	Framed-Compression
14	Login-IP-Host
15	Login-Service
16	Login-TCP-Port
17	(unassigned)
18	Сообщение-отклик (Reply-Message)
19	Callback-Number
20	Callback-Id
21	(не определено)
22	Framed-Route
23	Framed-IPX-Network
24	Состояние
25	Класс
26	Vendor-Specific
27	Таймаут сессии (Session-Timeout)
28	Idle-Timeout (таймаут пассивного состояния)
29	Termination-Action (процедура завершения)
30	Called-Station-Id
31	Calling-Station-Id
32	NAS-Идентификатор
33	Proxy-State
34	Login-LAT-Service
35	Login-LAT-Node
36	Login-LAT-Group
37	Framed-AppleTalk-Link
38	Framed-AppleTalk-Network
39	Framed-AppleTalk-Zone
40-59	(зарезервировано для акоунтинга)
60	CHAP-вызов (CHAP-Challenge)
61	NAS-Port-Type
62	Port-Limit
63	Login-LAT-Port

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

Поле значение содержит ноль или более октетов и содержит специфическую информацию атрибута. Формат и длина поля значение определяется полями тип и длина. Заметим, что строка в RADIUS не требует завершения символом ASCII NUL, так как имеется поле длины. Поле значение может иметь один из четырех форматов.

строка	0-253 октетов
адрес	32 битовый код, старший октет передается первым.
целое	32 битовый код, старший октет первый.
время	32 битовый код (старший октет первый) равен числу секунд с момента 00:00:00 GMT, 1-го января, 1970. Стандартные атрибуты не используют этот тип данных, но он представлен здесь, так как может быть применен в атрибутах зависящих от производителя (Vendor-Specific).

5.1. Имя пользователя

Этот атрибут указывает имя пользователя, который должен быть аутентифицирован. Он используется в пакетах Access-Request. Формат атрибута показан на Рисунок .3.

Допустимые коды поля значение и их назначения

Таблица .4. Допустимые коды поля значение и их назначения

Код поля значение	Назначение
0	Ничего не делать
1	Посылать маршрутные пакеты
2	Принимать маршрутные пакеты
3	Посылать и принимать

5.11. Атрибут Filter-Id

Этот атрибут указывает на имя списка фильтра для данного пользователя. Нуль или более идентификаторов фильтра может быть переслано в пакете Access-Accept. Идентификация списка фильтра с помощью имени позволяет использовать фильтр с различными NAS вне зависимости от особенностей использования списка фильтра. Формат записи атрибута соответствует Рисунок .3. поле тип = 11, поле длина ³ 3.

Поле строка здесь имеет один или более октетов и его содержимое зависит от программной реализации. Содержимое должно иметь читабельный формат и не должно влиять на работу протокола. Рекомендуется, чтобы отображаемое сообщение содержало 32-126 ASCII-символов.

5.12. Атрибут Framed-MTU

Этот атрибут указывает значение MTU, которое должно быть проставлено для пользователя, когда это не согласуется каким-либо другим образом (например, PPP). Атрибут используется только в пакетах Access-Accept. Формат атрибута аналогичен показанному на Рисунок 6. Поле тип = 12, а поле длина = 6. Поле значение имеет 4 октета и может принимать значения в интервале 64-65535.

5.13. Атрибут Framed-Compression

Этот атрибут указывает на протокол сжатия, который следует использовать при передаче данных. Атрибут используется в пакетах Access-Accept. Атрибут используется в пакетах Access-Request в качестве подсказки серверу о том, какой вид компрессии предпочитает использовать NAS, но сервер не обязан следовать этой рекомендации.

Можно использоваться несколько атрибутов данного типа. Окончательное решение о применении того или иного метода компрессии принимает сервер NAS.

Формат атрибута аналогичен показанному на Рисунок 6. Поле тип = 13, а поле длина = 6. Возможные коды поля значение собраны в таблице .5.

Код поля значение атрибута NAS-Port-Type

Таблица .7. Код поля значение атрибута NAS-Port-Type

Код поля значение	Назначение
0	Async
1	Sync
2	ISDN Sync
3	ISDN Async V.120
4	ISDN Async V.110
5	Виртуальный

5.42. Атрибут Port-Limit

Этот атрибут устанавливает максимальное число портов, предлагаемых сервером NAS пользователю. Этот атрибут может быть послан сервером клиенту в пакете Access-Accept. Он предназначен для использования в среде многоканального PPP [7]. Он может также быть послан сервером NAS серверу в качестве подсказки того, что доступно большое число портов. Формат записи атрибута показан на Рисунок .6. Поле тип = 62, а поле длина = 6.

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

5.43. Атрибут Login-LAT-Port

Этот атрибут указывает порт, с которым должен быть соединен пользователь посредством LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда LAT специфицирован в качестве услуг подключения. Он может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер может не следовать этой рекомендации. Формат записи атрибута показан на Рисунок .3. Поле тип = 63, а поле длина ³ 3.

Поле строка имеет один или более октетов и содержит идентификатор порта LAT, который следует использовать. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точку), _ (подчеркивание), цифры, буквы верхнего и нижнего регистра, а также расширенный набор символов ISO Latin-1. Все сравнения в LAT не зависят от регистра символов.

5.44.

Коды поля значение

Таблица .2. Коды поля значение

Код поля значение	Назначение
1	Login
2	Framed
3	Callback Login
4	Callback Framed
5	Outbound
6	Administrative
7	NAS Prompt
8	Authenticate Only
9	Callback NAS Prompt

Таково назначение кодов атрибута типа услуг при использовании в сообщениях Access-Accept. Когда они применяются в пакетах Access-Request, они должны рассматриваться как подсказки серверу RADIUS и говорят, что NAS имеет причины полагать, что пользователь предпочтет указанные услуги, но сервер не обязан следовать этим подсказкам.

Login	Пользователь должен быть подключен к ЭВМ.
Framed	Для пользователя должен быть запущен пакетный протокол, такой как PPP или SLIP.
Callback Login	Пользователь должен быть отсоединен, выполнен обратный дозвон, после чего осуществлено соединение с ЭВМ.
Callback Framed	Пользователь должен быть отсоединен, выполнен обратный дозвон, после чего для пользователя запущен пакетный протокол типа PPP или SLIP.
Outbound	Пользователю предоставляется доступ к выходным устройствам.
Administrative	Пользователю предоставляется доступ к административному интерфейсу NAS, с которого могут выполняться привилегированные команды.
NAS Prompt	Пользователю предоставляется возможность вводить непривилегированные команды NAS.
Authenticate Only	Запрашивается только аутентификация, ненужно возвращать никакой авторизационной информации Access-Accept (обычно используется прокси-серверами, а не самим NAS).
Callback NAS Prompt	Пользователь должен быть отсоединен, выполнен обратный дозвон, после чего ему предоставляется возможность ввода непривилегированных команд NAS.

5.7. Атрибут Framed-Protocol

Этот атрибут указывает на необходимость использования пакетного доступа. Атрибут может использоваться пакетами Access-Request и Access-Accept. Формат представления атрибута аналогичен формату атрибута NAS-порт (Рисунок .6). Поле тип = 7, поле длина = 6. Коды поля значение собраны в таблице .3.

Таблица .3. Коды поля значение

Код поля значение	Назначение
1	PPP
2	SLIP
3	Протокол удаленного доступа AppleTalk (ARAP)
4	Gandalf владелец протокола SingleLink/MultiLink
5	Xylogics владелец IPX/SLIP

5.8. Атрибут Framed-IP-Address

Этот атрибут указывает на адрес, который следует сконфигурировать для пользователя. Атрибут может использоваться пакетами Access-Accept. Он может использоваться в пакетах Access-Request в качестве подсказки NAS, указывающей на то, что сервер предпочитает данный адрес. Сервер не обязан следовать этой подсказке. Формат атрибута идентичен представлению атрибута NAS-IP-адрес (Рисунок .5).

Поле тип = 8, поле длина = 6.

Поле адрес содержит 4 октета. Значение 0xFFFFFFFF указывает, что NAS следует разрешить пользователю выбрать адрес. Значение 0xFFFFFFFE отмечает, что NAS следует выбрать адрес для пользователя (например, выбрать его из зарезервированного списка, имеющегося в NAS). Другие допустимые значения указывают, что NAS должен использовать этот код в качестве IP-адреса пользователя.

5.9. Атрибут Framed-IP-Netmask

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

5.10. Атрибут Framed-Routing

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

Коды программ, используемых в NFS

Таблица 4.5.16.1. Коды программ, используемых в NFS

Назначение программы	Номер программы	Номер версии	Номер процедуры
Менеджер портов (port mapper)	100000	2	4
NFS	100003	2	15
Монтировщик	100005	1	5
Менеджер блокировки	100021	1,2,3	19
Статус-монитор	100024	1	6

Монтировщик вызывается NFS-клиентом для обеспечения доступа к файловой системе сервера. Взаимодействие с файловой системой производится с помощью указателей файлов (handle), которые для версии 2 требуют 32 байт, а для версии 3 - 64 байт. Хотя NFS с самого начала была сориентирована на применение UDP (что было оправдано для локальных сетей), в настоящее время она в равной мере использует и TCP. Это позволяет NFS работать уже в масштабе всего Интернет. Третья версия NFS предполагает увеличение числа байт на одну команду READ или WRITE с 8192 до 65535 (ограничение, связанное с размером IP-дейтограммы). Увеличена в третьей версии и предельная длина файлов, которая задается уже 64-, а не 32-битным числом.

RLOGIN (RFC-1281) - процедура удаленного доступа, реализованная в 4BSD UNIX. RLOGIN позволяет администратору сети определить список ЭВМ, авторизация и доступ к которым является общими. Пользователь может организовать групповой доступ к разным ЭВМ, где он авторизован, сохраняя для себя возможность общения с любой из машин, не вводя каждый раз пароль. Одной из реализаций RLOGIN является RSH. RSH включает в себя интерпретатор команд. Форма обращения имеет вид: RSH имя_ЭВМ команда. RLOGIN позволяет взаимодействовать как с внутренними, так и с внешними ресурсами сети и с этой точки зрения предоставляет большие возможности чем Telnet.

REXECD представляет собой резидентную управляющую программу (демон), которая позволяет исполнять команды на удаленной ЭВМ в рамках TCP/IP сетей. Команда, выданная одной ЭВМ, может быть выполнена на другой ЭВМ, при этом автоматически, если необходимо, осуществляется процедура авторизации. REXECD использует TCP в качестве транспортной среды. Существуют реализации для сред UNIX, AIX и DOS.

маршрутизации RIP содержит

Таблица маршрутизации RIP содержит по записи на каждую обслуживаемую машину (на каждый маршрут). Запись должна включать в себя:

IP-адрес места назначения.

Метрика маршрута (от 1 до 15; число шагов до места назначения).

IP-адрес ближайшего маршрутизатора (gateway) по пути к месту назначения.

Таймеры маршрута.

Первым двум полям записи мы обязаны появлению термина вектор расстояния (место назначение – направление; метрика – модуль вектора). Периодически (раз в 30 сек) каждый маршрутизатор посылает широковещательно копию своей маршрутной таблицы всем соседям-маршрутизаторам, с которыми связан непосредственно. Маршрутизатор-получатель просматривает таблицу. Если в таблице присутствует новый путь или сообщение о более коротком маршруте, или произошли изменения длин пути, эти изменения фиксируются получателем в своей маршрутной таблице. Протокол RIP должен быть способен обрабатывать три типа ошибок:

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

Для подавления нестабильностей RIP должен использовать малое значение максимально возможного числа шагов (

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

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

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

Таблица .8. Основные характеристики атрибутов

Request	Accept	Reject	Challenge	#	Атрибут
1	0	0	0	1	User-Name
0-1	0	0	0	2	User-Password [*]
0-1	0	0	0	3	CHAP-Password [*]
0-1	0	0	0	4	NAS-IP-Address
01	0	0		5	NASPort
0-1	0-1	0	0	6	Service-Type
0-1	0-1	0	0	7	Framed-Protocol
0-1	0-1	0	0	8	Framed-IP-Address
0-1	0-1	0	0	9	Framed-IP-Netmask
0	0-1	0	0	10	Framed-Routing
0	0+	0	0	11	Filter-Id
0	0-1	0	0	12	Framed-MTU
0+	0+	0	0	13	Framed-Compression
0+	0+	0	0	14	Login-IP-Host
0	0-1	0	0	15	Login-Service
0	0-1	0	0	16	Login-TCP-Port
0	0+	0+	0+	18	Reply-Message
0-1	0-1	0	0	19	Callback-Number
0	0-1	0	0	20	Callback-Id
0	0+	0	0	22	Framed-Route
0	0-1	0	0	23	Framed-IPX-Network
0-1	0-1	0	0-1	24	State
0	0+	0	0	25	Class
0+	0+	0	0+	26	Vendor-Specific
0	0-1	0	0-1	27	Session-Timeout
0	0-1	0	0-1	28	Idle-Timeout
0	0-1	0	0	29	Termination-Action
0-1	0	0	0	30	Called-Station-Id
0-1	0	0	0	31	Calling-Station-Id
0-1	0	0	0	32	NAS-Identifier
0+	0+	0+	0+	33	Proxy-State
0-1	0-1	0	0	34	Login-LAT-Service
0-1	0-1	0	0	35	Login-LAT-Node
0-1	0-1	0	0	36	Login-LAT-Group
0	0-1	0	0	37	Framed-AppleTalk-Link
0	0+	0	0	38	Framed-AppleTalk-Network
0	0-1	0	0	39	Framed-AppleTalk-Zone
0-1	0	0	0	60	CHAP-Challenge
0-1	0	0	0	61	NAS-Port-Type
0-1	0-1	0	0	62	Port-Limit
0-1	0-1	0	0	63	Login-LAT-Port

[*] Запрос Access-Request должен содержать пароль пользователя или CHAP-пароль, но не должен содержать и то и другое.

Ниже в таблице представлены обозначения, использованные в таблице 8.

0	Этого атрибута не должно быть в пакете.
0+	Атрибут может использоваться в пакете нуль или более раз.
0-1	Атрибут может использоваться в пакете нуль или один раз.
1	Атрибут должен присутствовать в пакете обязательно один раз.

Правила UDP-инкапсуляции

Таблица 4.4.9.6.1. Правила UDP-инкапсуляции для уникастных сообщений Path и Resv

(D – уникастный адрес места назначения; R – маршрутизатор; Raw – режим произвольных операций сетевого ввода/вывода.)

Узел

RSVP посылает

RSVP получает

UDP(D/Ra,Pu) [1]

UDP(D,Pu) и UDP(D,Pu’) [2]

Raw(D)

и, если (UDP),

тогда UDP(D, Pu’)

RAW()

и UDP(D, Pu) [2]

(игнорировать Pu’)

R (интерфейс а)

Raw(D)

и, если (UDP),

тогда UDP(D, Pu’)

RAW()

и UDP(Ra, Pu)

(игнорировать Pu’)

[1]

Hu посылает уникастные сообщения Path либо по адресу D, если D является локальным, либо по адресу Ra маршрутизатора первого узла. Ra предполагается известным.

[2]

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

[3]

Это предполагает, что приложение присоединилось к группе D.

Правила UDP-инкапсуляции для мультикастных сообщений Path

Таблица 4.4.9.6.2. Правила UDP-инкапсуляции для мультикастных сообщений Path

Узел	RSVP посылает	RSVP получает
Hu	UDP(G*,Pu)	UDP(D,Pu’) [3] и UDP(G*,Pu)
Hr	Raw(D,Tr) и, если (UDP), тогда UDP(D, Pu’)	RAW() и UDP(G*, Pu) (игнорировать Pu’)
R (интерфейс а)	Raw(D,Tr) и, если (UDP), тогда UDP(D, Pu’)	RAW() и UDP(G*, Pu) (игнорировать Pu’)

Маршрутизатор может определить, нуждается ли его интерфейс Х в UDP-инкапсуляции, контролируя поступление UDP-инкапсулированных сообщений Path, которые были посланы либо G* (мультикаст D) либо по адресу интерфейса X (уникаст D). Для данной схемы существует один неудачный режим: если нет ни одной ЭВМ в сети, которая бы выполняла функцию RSVP отправителя, тогда не будет сообщений прохода (Path), чтобы запустить UDP-инкапсуляцию. В этом случае будет необходимо сконфигурировать UDP-инкапсуляцию для интерфейса локального маршрутизатора.

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

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

Hu может запускать как уникастные, так и мультикастные сессии в UDP(Ra,Pu) с TTL=Ta. Здесь Ta должно быть достаточным, чтобы достичь R. Если Ta слишком мало, сообщение Path не дойдет до R. Если Ta слишком велико, R и последующие маршрутизаторы могут переправлять UDP-пакет до тех пор, пока не иссякнет запас по TTL. Это включит UDP-инкапсуляцию между маршрутизаторами в Интернет, возможно вызвав паразитный UDP трафик. ЭВМ Hu должна быть непосредственно сконфигурирована с использованием Ra и Ta.

Конкретная ЭВМ локальной сети, соединенная с Hu может считаться “транспортной ЭВМ RSVP". Транспортная ЭВМ будет прослушивать (G*,Pu) и переправлять любое сообщение Path непосредственно R, хотя это и не будет маршрутом передачи данных. Транспортная ЭВМ должна быть сконфигурирована с использованием Ra и Ta.

представляет результаты

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

Если мы обладаем всей информацией о релевантных и нерелевантных документах в коллекции документов, то применимы следующие оценки:

Типы пакетов RTCP

Таблица 4.4.9.3.1. Типы пакетов RTCP

Сокращенное название	Имя	Значение
SR	sender report – сообщение отправителя	200
RR	receiver report – сообщение получателя	201
SDES	source description – описание источника	202
BYE	goodbye - завершение	203
APP	application-defined – определен приложением	204

Эти значения типов были выбраны в диапазоне 200-204 для улучшенного контроля корректности заголовков RTCP пакетов. Когда поле типа пакета RTCP сравнивается с соответствующим октетом RTP-заголовка, этот диапазон соответствует маркерному биту 1 (который обычно отсутствует в информационных пакетах) и старшему биту стандартного поля типа данных равному 1 (так как статические типы поля данных обычно лежат в младшей половине).

Другие константы определены IANA. Экспериментаторам предлагается зарегистрировать числа, которые им нужны, а затем аннулировать регистрацию, если необходимость в них отпадет.

Типы SDES

Таблица 4.4.9.3.2. Типы SDES

Сокращенное название	Имя	Значение
END	Конец списка SDES	0
CNAME	Каноническое имя	1
NAME	Имя пользователя	2
EMAIL	Электронный адрес пользователя	3
PHONE	Телефонный номер пользователя	4
OC	geographic user location	5
TOOL	Имя приложения или программного средства	6
NOTE	notice about the source	7
PRIV	Частные расширения	8

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

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

Расширения SR/RR. Секция расширения может быть определена для RTCP SR и RR пакетов, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно передаваться.

Проверка корректности заголовка RTCP

Пакеты RTCP подвергаются следующим проверкам.

RTP поле версии должно быть равно 2.

Поле типа данных первого RTCP пакета в составном пакете должно быть SR или RR.

Бит заполнителя (P) должен быть равен нулю для первого пакета составного RTCP пакета, так как заполнитель может присутствовать только в последнем.

Длина полей индивидуальных RTCP-пакетов должна в сумме равняться полной длине составного пакета.

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

u_int32 len; /* Длина составного RTCP пакета в словах */

rtcp_t *r; /* заголовок RTCP */

rtcp_t *end; /* Конец составного RTCP пакета */

if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {

/* что-то не в порядке с форматом пакета */

}

end = (rtcp_t *)((u_int32 *)r + len);

do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1);

while (r < end && r->common.version == 2);

if (r != end) {

/* что-то не в порядке с форматом пакета */

}
Генерирование пакетов SDES RTCP
Эта функция формирует фрагмент SDES, состоящий из элементов argc, взятых из массивов type, в буфере b.
char *rtp_write_sdes(char *b, u_int32 src, int argc,

rtcp_sdes_type_t type[], char *value[],

int length[])

{

rtcp_sdes_t *s = (rtcp_sdes_t *)b;

rtcp_sdes_item_t *rsp;

int i;

int len;

int pad;

/* SSRC header */

s->src = src;

rsp = &s->item[0];

/* SDES items */

for (i = 0; i < argc; i++) {

rsp->type = type[i];

len = length[i];

if (len > RTP_MAX_SDES) {

/* неверная длина, возможно нужны другие действия */

len = RTP_MAX_SDES;

}

rsp->length = len;

memcpy(rsp->data, value[i], len);

rsp = (rtcp_sdes_item_t *)&rsp->data[len];

}

/* завершить конечным маркером и заполнителем на очередной 4-октетной границе */

len = ((char *) rsp) - b;

pad = 4 - (len & 0x3);

b = (char *) rsp;

while (pad--) *b++ = RTCP_SDES_END;

return b;

}
Разбор пакетов RTCP SDES
Эта функция осуществляет разбор пакета SDES, вызывая функции find_member() для поиска указателя на информацию для члена сессии с идентификатором SSRC и member_sdes() для запоминания новой информации SDES для этого участника. Этой функции необходим указатель на заголовок пакета RTCP.
void rtp_read_sdes(rtcp_t *r)

{

int count = r->common.count;

rtcp_sdes_t *sd = &r->r.sdes;

rtcp_sdes_item_t *rsp, *rspn;

rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)

((u_int32 *)r + r->common.length + 1);

source *s;

while (--count >= 0) {

rsp = &sd->item[0];

if (rsp >= end) break;

s = find_member(sd->src);

for (; rsp->type; rsp = rspn ) {

rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2);

if (rspn >= end) {

rsp = rspn;

break;

}

member_sdes(s, rsp->type, rsp->data, rsp->length);

}

sd = (rtcp_sdes_t *)

((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);

}

if (count >= 0) {

/* некорректный формат пакета */

}

}
Вычисление периода рассылки RTCP
Следующая функция в качестве результата выдает время между посылками RTCP-пакетов, измеренное в секундах. Она должна вызываться после посылки одного составного RTCP-пакета для вычисления времени до посылки следующего пакета. Эта функция должна также вызываться для вычисления времени посылки первого RTCP-пакета при запуске. Это исключает любые кластеры RTCP-пакетов, если приложение запущено в нескольких узлах одновременно, например, в результате объявления об открытии сессии.
Параметры имеют следующий смысл:
rtcp_bw: Предельная полоса RTCP, т.е., полная пропускная способность, которая будет использоваться для RTCP-пакетов всеми участниками сессии, выраженная в октетах в секунду. Она должна быть порядка 5% от "полосы сессии", этот параметр задается при конфигурировании приложения.
senders: Число активных отправителей на момент посылки последнего отчета, известно из конструкции отчетов получателя.
members: Оценка числа членов сессии, включая нас самих. Инкрементируется, когда мы обнаруживаем новых членов сессии при получении RTP или RTCP-пакетов, и декрементируется, когда какой-либо участник покидает сессию (послав RTCP BYE) или он объявлен таковым по тайм-ауту (рекомендуемое время 30 минут). При первом вызове этот параметр должен иметь значение 1.
we_sent: Флаг, который равен true, если мы послали данные за время последних двух интервалов RTCP. Если флаг равен true, составной только что посланный пакет RTCP содержит SR пакет.
packet_size: Размер составного только что посланного пакета RTCP, в октетах, включая сетевую инкапсуляцию (напр., 28 октетов для UDP поверх IP).
avg_rtcp_size: Указатель оценщика размера составных пакетов RTCP; инициализируется и актуализуется для только что посланного пакета этой функцией, актуализуется также идентичной строкой программы приема пакетов RTCP для каждого пакета RTCP, полученного от другого участника сессии.
initial: Флаг, который равен true для первого вызова при инициализации с целью вычисления момента посылки первого отчета.

#include

double rtcp_interval(int members,

int senders,

double rtcp_bw,

int we_sent,

int packet_size,

int *avg_rtcp_size,

int initial)

{

/*

* Минимальное время между пакетами RTCP от данного узла (в секундах). Это время

* предотвращает группирование отчетов, когда в сессии участвует малое число

* участников. Это препятствует чрезмерному уменьшению интервалов межу отчетами.

*/

double const RTCP_MIN_TIME = 5.;

/*

* Доля полосы RTCP, которая должна быть поделена между активными участниками.

* (Эта доля была выбрана так, чтобы в типовой сессии с одним или двумя

* активными отправителями, вычисленный период посылки отчетов был примерно

* равен минимальному интервалу между отчетами. Доля получателя должна равняться

* 1 – доля отправителя.

*/

double const RTCP_SENDER_BW_FRACTION = 0.25;

double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);

/*

* Коэффициент преобразования (сглаживающая константа) для полосового

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

*/

double const RTCP_SIZE_GAIN = (1./16.);

double t; /* интервал */

double rtcp_min_time = RTCP_MIN_TIME;

int n; /* число участников, используемое при вычислении */

/*

* Самый первый вызов приложения использует вдвое меньшую

* минимальную задержку для ускорения оповещения, в то же время оставляя

* некоторое время до отчета для рэндомизации и получения информации

* о других источниках. Таким образом, установление корректного периода

* отчетов произойдет быстрее. Средний размер RTCP пакета

* устанавливается в начальный момент равным 128 октетам

* (предполагается, что все остальные генерируют SR вместо RR:

* 20 IP + 8 UDP + 52 SR + 48 SDES CNAME октетов).

*/

if (initial) {

rtcp_min_time /= 2;

*avg_rtcp_size = 128;

}

/*

* Если имелись активные отправители, надо им дать

* по крайней мере минимальную долю полосы RTCP.

* В противном случае все участники будут делить полосу RTCP поровну

*/

n = members;

if (senders > 0 && senders < members * RTCP_SENDER_BW_FRACTION) {

if (we_sent) {

rtcp_bw *= RTCP_SENDER_BW_FRACTION;

n = senders;

} else {

rtcp_bw *= RTCP_RCVR_BW_FRACTION;

n -= senders;

}

}

/*

* Актуализация оценки среднего размера пакета отчета с учетом

* только что посланного пакета.

*/

*avg_rtcp_size += (packet_size - *avg_rtcp_size)*RTCP_SIZE_GAIN;

/*

* Эффективное число узлов, умножаем на средний размер пакета отчета

* и получаем полное число посланных октетов, если каждый из узлов

* посылает отчет. Деля это число на эффективную полосу,

* получаем средний временной интервал посылки пакетов-отчетов.

*/
t = (*avg_rtcp_size) * n / rtcp_bw;

if (t < rtcp_min_time) t = rtcp_min_time;
/*

* Для того чтобы избежать всплесков трафика из-за непреднамеренной

* синхронизации с другими узлами мы выбираем следующий интервал

* отчета равным случайному числу с равномерным распределением в

* диапазоне 0.5*t - 1.5*t.

*/

return t * (drand48() + 0.5);

}

Библиография

[1]	I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS control of multimedia applications based on RTP," Computer Communications , Jan. 1996.
[2]	S. Floyd and V. Jacobson, "The synchronization of periodic routing messages," in SIGCOMM Symposium on Communications Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco, California), pp. 33--44, ACM, Sept. 1993. also in [24]
[3]	J. A. Cadzow, Foundations of digital signal processing and data analysis New York, New York: Macmillan, 1987
[4]	International Standards Organization, "ISO/IEC DIS 10646-1:1993 information technology -- universal multiple-octet coded character set (UCS) -- part I: Architecture and basic multilingual plane," 1993
[5]	The Unicode Consortium, The Unicode Standard New York, New York: Addison-Wesley, 1991
[6]	Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, USC/Information Sciences Institute, November 1987
[7]	Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987
[8]	Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, Internet Engineering Task Force, October 1989
[9]	Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", RFC 1597, T.J. Watson Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994
[10]	Lear, E., Fair, E., Crocker, D., and T. Kessler, "Network 10 Considered Harmful (Some Practices Shouldn't be Codified)", RFC1627, Silicon Graphics, Inc., Apple Computer, Inc., Silicon Graphics, Inc., July 1994
[11]	Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982
[12]	W. Feller, An Introduction to Probability Theory and its Applications, Volume 1 , vol. 1. New York, New York: John Wiley and Sons, third ed., 1968

Возможные коды поля значение

Таблица .5. Возможные коды поля значение

Код поля значение	Назначение
0	Никакого
1	Сжатие заголовка VJ TCP/IP [5]
2	Сжатие заголовка IPX

5.14. Атрибут Login-IP-Host

Этот атрибут указывает на систему, с которой соединяется пользователь при наличии атрибута Login-Service. Атрибут используется в пакетах Access-Accept, а также Access-Request в качестве подсказки серверу, какую из ЭВМ предпочитает NAS, но сервер не обязан следовать этой рекомендации. Формат записи атрибута аналогичен показанному на Рисунок .5. Поле тип = 14, а поле длина = 6.

Поле адрес имеет 4 октета. Значение 0xFFFFFFFF указывает на то, что NAS должен позволить пользователю выбор адреса. Значение 0 говорит, что NAS должен сам выбрать ЭВМ, с которой будет соединен пользователь. Любые другие значения указывают адрес, с которым сервер NAS должен соединить пользователя.

5.15. Атрибут Login-Service

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

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

5.20. Атрибут Callback-Id

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

5.21. Атрибут типа 21 в настоящее время не определен
5.22. Атрибут Framed-Route

Этот атрибут содержит маршрутную информацию, которая должна быть сконфигурирована сервером NAS для пользователя. Атрибут используется в пакетах Access-Accept и может присутствовать там несколько раз. Формат записи атрибута следует схеме, показанной на Рисунок .3. Поле тип = 22, а поле длина ³
3.
Поле строка содержит один или более октетов, а его содержимое зависит от приложения. Текст должен быть читабельным и не должен влиять на работу протокола. Рекомендуется, чтобы сообщение содержало ASCII-символы с кодами в диапазоне 32 - 126.
Для IP-маршрутов, атрибут должен содержать префикс места назначения в десятично-точечном представлении (как IP-адрес). Далее опционно может следовать косая черта и число старших бинарных единиц, указывающее на количество разрядов префикса, которые следует использовать. Далее следует пробел, адрес шлюза, еще один пробел и один или более кодов метрики, разделенных пробелами. Например, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". Длина спецификатора может быть опущена, тогда для префикса класса А подразумевается длина в 8 бит, для класса В - 16 и для класса С - 24 бита. Например, "192.168.1.0 192.168.1.1 1". Если адрес шлюза равен "0.0.0.0", тогда в качестве IP-адреса шлюза следует использовать адрес пользователя.

5.23. Атрибут Framed-IPX-Network

Этот атрибут содержит сетевое число IPX, конфигурируемое для пользователя.

Атрибут используется в пакетах Access-Accept. Формат записи атрибута показан на Рисунок .6. Поле тип = 23, а поле длина = 6.
Поле значение имеет 4 октета. Значение 0xFFFFFFFE указывает, что сервер NAS должен выбрать для пользователя сеть IPX (т.е. выбрать одну или более IPX-сетей из имеющегося списка). Остальные значения должны рассматриваться как IPX-сети, предназначенные для подключения.

5.24. Атрибут State

Этот атрибут предназначен для посылки сервером клиенту в сообщении Access-Challenge и должен быть передан немодифицированным от клиента к серверу в новом отклике Access-Request на исходный вызов, если таковой имеется.
Этот атрибут может быть послан сервером клиенту в сообщении Access-Accept, которое содержит также атрибут Termination-Action со значением RADIUS-Request. Если сервер NAS выполняет процедуру Termination-Action путем посылки сообщения Access-Request по завершении текущей сессии, атрибут должен включать в себя исходный код атрибута State из запроса Access-Request. В любом случае клиент не должен его интерпретировать. В пакете может содержаться только один атрибут State. Использование атрибута зависит от конкретной реализации. Формат записи атрибута следует схеме, показанной на Рисунок .3. Поле тип = 24, а поле длина ³ 3.
Поле строка имеет один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

5.25. Атрибут Class

Этот атрибут предназначен для посылки сервером клиенту в сообщении Access-Accept, он должен быть переслан в неизменном виде клиентом серверу, куда планируется доступ, в пакете Accounting-Request. Клиент не должен интерпретировать этот атрибут. Формат записи атрибута следует схеме, показанной на Рисунок .3. Поле тип = 25, а поле длина ³ 3. Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.

5.26. Атрибут Vendor-Specific

Этот атрибут служит для того, чтобы позволить производителям обеспечить поддержку их собственных атрибутов, непригодных для общего применения.Атрибут не должен влиять на работу протокола RADIUS.
Серверы, не приспособленные для интерпретации информации, специфической для производителя оборудования или программ, должны игнорировать эти атрибуты (хотя могут и оповещать об этом). Клиенты, которые не получили желательной информации, специфической для изготовителя, должны предпринять попытку работать без этих данных. При этом функциональность может быть сужена (о чем клиент может сообщить пользователю). Формат записи атрибута показан на Рисунок .7. Поле тип = 26, а поле длина ³ 7.

Значения кодов поля команда

Таблица 4.4.11.1. Значения кодов поля команда

Команда	Значение
1	Запрос на получение частичной или полной маршрутной информации;
2	Отклик, содержащий информацию о расстояниях из маршрутной таблицы отправителя;
3	Включение режима трассировки (устарело);
4	Выключение режима трассировки (устарело);
5-6	Зарезервированы для внутренних целей sun microsystem.

Поле версия для RIP равно 1 (для RIP-2 двум). Поле набор протоколов сети i определяет набор протоколов, которые используются в соответствующей сети (для Интернет это поле имеет значение 2). Поле расстояние до сети i содержит целое число шагов (от 1 до 15) до данной сети. В одном сообщении может присутствовать информация о 25 маршрутах. При реализации RIP можно выделить следующие режимы:

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

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

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

Типы пакетов

4. Типы пакетов

Тип пакета RADIUS определяется полем тип, размещенным в первом октете.

4.1. Запрос доступа

Пакеты Access-Request посылаются серверу RADIUS, и передают информацию, которая используется для определения того, позволен ли данному пользователю доступ к специфицированному NAS, и допустимы ли запрошенные услуги. Программная реализация, желающая аутентифицировать пользователя, должна послать пакет RADIUS с кодом поля тип=1 (Access-Request).

При получении запроса (Access-Request) доступа от корректного клиента, должен быть передан соответствующий ответ. Запрос доступа (Access-Request) должен содержать атрибут имени пользователя. Он должен включать в себя атрибут NAS-IP-адреса или атрибут NAS-идентификатора (или оба эти атрибута, хотя это и не рекомендуется). Он должен содержать атрибут пароля пользователя (User-Password) или атрибут CHAP-пароля. Желательно, чтобы он содержал атрибут NAS-порта или NAS-Port-Type или оба эти атрибута, если только тип запрошенного доступа не содержал номер порта.

Запрос доступа (Access-Request) может содержать дополнительные атрибуты - подсказки серверу, но последний не обязан следовать этим подсказкам. Когда присутствует пароль пользователя (User-Password), он защищается с использованием метода, базирующегося на RSA алгоритме MD5 [1]. Формат пакета Access-Request аналогичен показанному на Рисунок .1. Только на месте поля аутентификатор размещается поле аутентификатор запроса (Request Authenticator), а в поле код записывается 1.

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

Значение поля аутентификатор запроса (Request Authenticator) должно изменяться, когда используется новый идентификатор.

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

4.2. Пакеты Access-Accept

Пакеты Access-Accept посылаются сервером RADIUS, и предоставляют специфическую конфигурационную информацию, необходимую для предоставления пользователю соответствующего сервиса. Если все значения атрибутов, полученных с запросом Access-Request, приемлемы, тогда реализация RADIUS должна послать пакет с полем код=2 (Access-Accept). При получении сообщения Access-Accept, поле идентификатор соответствует обрабатываему запросу (Access-Request). Кроме того, поле аутентификатор отклика должно содержать корректный отклик на полученный запрос Access-Request. Пакеты неверного формата молча отбрасываются. Формат пакета Access-Accept идентичен показанному на Рисунок .1. Но здесь вместо поля аутентификатор используется поле аутентификатор отклика, имеющее тот же размер. В поле код при этом записывается число 2.

Поле идентификатор является копией одноименного поля в запросе Access-Request, который инициировал сообщение Access-Accept.

Значение поля аутентификатор отклика (Response Authenticator) вычисляется на основе значения Access-Request, как это описано выше. Поле атрибуты имеет переменную длину и содержит список из нуля или более атрибутов.

4.3. Сообщение Access-Reject

Если какое-либо значение полученного атрибута неприемлемо, тогда сервер RADIUS должен послать пакет с полем код= 3 (Access-Reject). Пакет может содержать один или более атрибутов Reply-Message с текстом, который может быть отображен NAS для пользователя. Поле идентификатор для данного пакета копируется из одноименного поля пакета Access-Request, вызвавшего данный отклик.

Значение поля аутентификатор отклика вычисляется на основе содержимого сообщения Access-Request, как это описано выше.

4.4. Сообщение Access-Challenge

Если сервер RADIUS хочет послать пользователю вызов, требующий отклика, то сервер должен реагировать на запрос Access-Request посылкой пакета с полем код=11 (Access-Challenge). Поле атрибуты может содержать один или более атрибутов Reply-Message, и может опционно включать атрибут состояния.

Никакие другие атрибуты здесь не применимы.

При получении Access-Challenge, поле идентификатор соответствует содержимому пакета Access-Request. Кроме того, поле аутентификатор отклика должно содержать корректный отклик на обрабатываемый запрос Access-Request. Некорректные пакеты молча отбрасываются. Если NAS не поддерживает обмен вызов/отклик (challenge/response), он должен обрабатывать сообщение Access-Challenge, как если бы это был запрос Access-Reject.

Если сервер NAS поддерживает обмен вызов/отклик, получение корректного сообщения Access-Challenge указывает, что следует послать новый запрос Access-Request. Сервер NAS может отобразить текстовое сообщение для пользователя, если таковое имеется, а затем предложить ему ввести отклик. Затем сервер посылает исходное сообщение Access-Request с новым идентификатором запроса и аутентификатором отклика, с атрибутом пароля пользователя, содержащим зашифрованный отклик пользователя. Кроме того, это сообщение содержит атрибут состояния (State) сообщения Access-Challenge, если таковой имелся.

NAS, который поддерживает PAP может переадресовать сообщение Reply-Message клиенту, подключенному по модемному каналу, и принять PAP-отклик, который он может использовать как отклик, введенный пользователем. Если NAS этого сделать не может, он должен воспринимать Access-Challenge, как если бы он получил сообщение Access-Reject. Формат пакета Access-Challenge совпадает с форматом Access-Accept и Access-Request.

Поле идентификатор является копией одноименного поля пакета Access-Request, который вызвал посылку Access-Challenge.

Значение аутентификатора отклика вычисляется так, как это было описано выше. Поле атрибуты имеет переменную длину, и содержит список из нуля или более атрибутов.

Транспортный протокол реального времени RTCP

4.4.9.3 Транспортный протокол реального времени RTCP

Управляющий протокол RTCP (RTP control protocol; см. RFC-1889 “RTP: A Transport Protocol for Real-Time Applications” H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson) базируется на периодической передаче управляющих пакетов всем участникам сессии, используя тот же механизм рассылки, что и для пакетов данных. Этот протокол не имеет самостоятельного значения и используется лишь совместно с RTP. Нижележащий протокол должен обеспечивать мультиплексирование пакетов данных и управления, используя разные номера портов. RTCP выполняет четыре функции:

1. Главной задачей данного протокола является обеспечение обратной связи для контроля качества при рассылке данных. Обратная связь может быть непосредственно полезна при адаптивном кодировании [1,2], но эксперименты с IP мультикастингом показали, что для получателей крайне важно диагностировать ошибки при рассылке пакетов. Посылка сообщений-отчетов о приеме данных всем участникам позволяет тому, кто обнаружил какие-то проблемы, разобраться в том, являются ли эти трудности локальными или глобальными. При механизме рассылки типа IP-мультикастинга, сервис провайдер, который непосредственно не вовлечен в сессию, получив обратную связь, может независимо мониторировать ситуацию в сети.

2. RTCP имеет постоянный идентификатор транспортного уровня для RTP источника, который называется каноническим именем или cname. Так как SSRC-идентификатор может быть изменен, если будет зафиксировано столкновение или источник будет вынужден рестартовать, получатели нуждаются в cname, для того чтобы отслеживать каждого из участников. Получателям также нужно Cname, чтобы установить соответствие между многими потоками данных от одного участника при реализации нескольких сессий одновременно, например, чтобы синхронизовать аудио- и видео-каналы.

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

Статистика приема (в SR или RR) должна посылаться так часто, как это позволяют ограничения пропускной способности, так что каждый периодически посылаемый составной пакет включает в себя пакет отчета.

Новые получатели должны приобрести cname для источника как можно быстрее, каждый составной RTCP-пакет должен включать в себя SDES Cname.

Число типов пакетов, которые могут впервые появиться в составном пакете, должно быть ограничено.

Таким образом, все rtcp-пакеты должны посылаться в составных пакетах (не менее 2) и иметь следующий рекомендованный формат:

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

SR или RR. Первый RTCP-пакет в составном пакете должен быть всегда сообщением-отчетом. Это справедливо, даже если не было послано или получено никаких данных, в этом случае посылается пустой пакет RR. Это справедливо, даже если другим RTCP -пакетом в составной дейтограмме является Bye.

Дополнительные RR. Если число источников, для которых приводится статистика приема, превышает 31, в первый пакет помещается информация по части источников, остальная часть размещается в следующих RR-пакетах.

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

Bye или APP. Другие типы RTCP-пакетов, включая те, которые еще предстоит определить, могут следовать далее в произвольном порядке. Пакет bye, если он присутствует, должен быть последним и содержать SSRC/CSRC. Пакеты одного и того же типа могут повторяться.

Для трансляторов и смесителей рекомендуется объединять RTCP-пакеты от нескольких источников.Пример составного RTCP-пакета, который может быть сформирован смесителем, представлен на Рисунок 4.4.9.3.1. Если полная длина составного пакета превысит максимальный размер пересылаемого блока данных для сети (MTU), он может быть фрагментирован и переслан в нескольких составных пакетах нижележащего транспортного протокола. Заметьте, что каждый составной пакет должен начинаться с SR или RR-пакета.

Приложение может игнорировать RTCP пакеты неизвестного ему типа. Дополнительныетипы RTCP-пакетов могут быть зарегистрированы IANA (internet assigned numbers authority).

Вариант схемы внутренних связей переключателя

Рисунок 4.1.1.4.5. Вариант схемы внутренних связей переключателя.

Внутренний протокол маршрутизации RIP

4.4.11.1 Внутренний протокол маршрутизации RIP

Этот протокол маршрутизации предназначен для сравнительно небольших и относительно однородных сетей (алгоритм Белмана-Форда). Протокол разработан в университете Калифорнии (Беркли), базируется на разработках фирмы Ксерокс и реализует те же принципы, что и программа маршрутизации routed, используемая в ОC Unix (4BSD). Маршрут здесь характеризуется вектором расстояния до места назначения. Предполагается, что каждый маршрутизатор является отправной точкой нескольких маршрутов до сетей, с которыми он связан. Описания этих маршрутов хранится в специальной таблице, называемой маршрутной.

и модемных пулов при большом

1. Введение

Управление последовательных линий и модемных пулов при большом числе пользователей может потребовать весьма значительных административных усилий. Так как модемные пулы по определению являются каналами во внешний мир, они требуют особых мер безопасности. Это может быть реализовано путем поддержки единой базы данных пользователей, которая используется для аутентификации (проверке имени и пароля). Эта база данных хранит в себе и конфигурационные данные, характеризующие вид услуг, предоставляемых пользователю (например, SLIP, PPP, telnet, rlogin).
Модель клиент/сервер
Сервер сетевого доступа NAS (Network Access Server) работает как клиент системы RADIUS (RFC-2138, 2618-2621). Клиент передает информацию о пользователе специально выделенным серверам RADIUS, и далее действует в соответствии с полученным откликом на эти данные.
Серверы RADIUS принимают запросы от пользователей, осуществляют аутентификацию и выдают конфигурационную информацию, которая необходима клиенту, чтобы предоставить пользователю запрошенный вид услуг.
Сервер RADIUS может выполнять функцию прокси-клиента по отношению к другим серверам RADIUS или прочим аутентификационным серверам.
Сетевая безопасность
Взаимодействие клиента и сервера RADIUS аутентифицируются с использованием общего секретного ключа (пароля), который никогда не пересылается по сети. Кроме того, каждый пароль пользователя пересылается от клиента к серверу в зашифрованном виде, чтобы исключить его перехват.
Гибкие аутентификационные механизмы
Сервер RADIUS может поддерживать несколько методов аутентификации пользователя. При получении имени пользователя и его пароля сервер может воспользоваться PPP PAP или CHAP, UNIX login, и другими аутентификационными механизмами.
Масштабируемый протокол
Все операции подразумевают использование ансамблей атрибут-длина-значение. Новое значение атрибута может быть добавлено без редактирования существующей версии реализации протокола.

1.1. Терминология

В этом документе используются следующие термины:

Услуга

NAS обеспечивает пользователю, подключенному через модем, определенные услуги, такие как PPP или Telnet.

Сессия

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

Молчаливое удаление (silently discard)

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

Взаимодействие с политикой в классе aut-num

Рисунок .33. Взаимодействие с политикой в классе aut-num.

На Рисунок 33 показан пример взаимодействия. При рассмотрении маршрутных объектов следует произвести обмен более специфическими префиксами 128.8.0.0/16 и 128.9.0.0/16 между AS1, AS2 и AS3 (граница объединения).

Экспортное объединение выполнено для AS4 и AS5, но не для AS3, так как AS3 находится на границе объединения. Объект aut-num допускает экспортирование обоих компонентов в AS2, и только компонент 128.8.0.0/16 в AS3. Объединение может быть сформировано, если присутствуют все компоненты. В данном случае только об этом объединении оповещены AS4 и AS5. Однако, если одна из компонент не доступна, объединение не может быть создано, и любая из доступных компонент или более специфический префикс будет экспортирован в AS4 и AS5. Вне зависимости от того, выполнено объединение или нет, только более специфические префиксы будут экспортированы в AS6.

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

8.1.2. Разрешение неопределенности для перекрывающихся объединений

Когда специфицированы несколько маршрутных объединений и они перекрываются, т.e. один менее специфичен чем другой, тогда сначала определяются более а затем менее специфичные. Когда для партнера осуществляется экспортное объединение (outbound aggregation), объединение и компоненты, перечисленные в атрибуте export-comps, доступны для генерации следующих менее специфичных объединений. Компоненты, которые не специфицированы в атрибуте export-comps, являются недоступными. Маршрут экспортируем в AS, если это наименее специфическое объединение, экспортируемое в эту автономную систему или маршрут упомянут в атрибуте export-comps. Заметим, что это рекурсивное определение.

route:	128.8.0.0/15
origin:	AS1
aggr-bndry:	AS1 or AS2
aggr-mtd:	outbound
inject:	upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16}
route:	128.10.0.0/15
origin:	AS1
aggr-bndry:	AS1 or AS3
aggr-mtd:	outbound
inject:	upon HAVE-COMPONENTS {128.10.0.0/16, 128.11.0.0/16}
export-comps:	{128.11.0.0/16}
route:	128.8.0.0/14
origin:	AS1
aggr-bndry:	AS1 or AS2 or AS3
aggr-mtd:	outbound
inject:	upon HAVE-COMPONENTS {128.8.0.0/15, 128.10.0.0/15}
export-comps:	{128.10.0.0/15}

Заголовок пакета RTP

Рисунок 4.4.9.2.1. Заголовок пакета RTP

Первые 12 октетов присутствуют во всех RTP-пакетах, в то время как список CSRC-идентификаторов присутствует только, когда пакет формируется смесителем. Поля имеют следующие назначения:

v (Версия): 2 бита

Это поле идентифицирует версию протокола RTP. В настоящее время в это поле записывается код 2. Значение 1 использовалось в опытной версии RTP, а код 0 – в аудио приложении "vat".

p (Заполнитель): 1 бит

Если Р=1, пакет содержит один или более дополнительных октетов-заполнителей в конце поля данных (заполнители не являются частью поля данных). Последний октет заполнителя содержит число октетов, которые должны игнорироваться. Заполнитель нужен при использовании некоторых алгоритмов шифрования при фиксированном размере блоков или при укладке нескольких RTP-пакетов в один UDP.

x (Расширение): 1 бит

Если бит Х=1, далее следует фиксированный заголовок, за которым размещается одно расширение заголовка.

CC(CSRC count – число CSRC): 4 бита

Число CSRC содержит код количества csrc-идентификаторов, которые записаны в пакете.

M (маркер): 1 бит

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

PT(Тип данных): 7 бит

Это поле идентифицирует формат поля данных RTP-пакета и определяет интерпретацию его приложением. Могут быть определены дополнительные коды типа данных. Исходный набор кодов по умолчанию для аудио и видео задан в профайле Internet-draft draft-ietf-avt-profile, и может быть расширен в следующих редакциях стандарта assigned numbers (RFC-1700) [5].

Номер по порядку: 16 бит

Номер по порядку инкрементируется на 1 при посылке очередного RTP-пакета данных, этот код может использоваться получателем для регистрации потерь пакетов и для восстановления истинного порядка присланных фрагментов.
Начальное значение кода является случайным. Алгоритм генерации таких кодов рассмотрен в [6].

Временная метка: 32 бита

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

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

SSRC: 32 бита

Поле SSRC идентифицирует источник синхронизации. Этот идентификатор выбирается случайным образом, так чтобы в пределах одной RTP-сессии не было двух равных SSRC-кодов. Все приложения должны быть способны выявлять случаи равенства SSRC-кодов. Если отправитель изменяет свой транспортный адрес, он должен также сменить и SSRC-идентификатор.

CSRC-список: от 0 до 15 элементов, по 32 бита каждый

CSRC-список идентифицирует источники информации, которые внесли свой вклад в поле данных пакета. Число идентификаторов задается полем CC. Если число источников больше 15, только 15 из них могут быть идентифицированы.

Для эффективной реализации протокола число точек мультиплексирования должно быть минимизировано. В RTP, мультиплексирование осуществляется по транспортным адресам мест назначения, которые определены RTP-сессией. Использование пакетов с различным типом поля данных но с идентичным ssrc создает определенные проблемы:

1. Если один из типов данных будет изменен в ходе сессии, нет универсальных средств для определения, какое из старых значений следует заменить на новое.

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

3. RTCP-сообщения отправителя и получателя могут описать только одно пространство номеров и временных меток для каждого SSRC и не имеют поля типа данных.

4. RTP-смеситель не сможет объединять перекрывающиеся потоки при условии их несовместимости.

5. Работа со многими средами в пределах одной RTP-сессии предполагает: использование различных сетевых путей или разного размещения сетевых ресурсов; приема только одного субнабора, например аудио, когда видео недоступно из-за недостатка широкополосности.

Использование различных ssrc для каждого вида среды, при посылке их в пределах одной RTP-сессии позволяет преодолеть первые три проблемы.

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

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

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

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

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

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

Зашифрованный и незашифрованный RTCP-пакеты (#ssrc)

Рисунок 4.4.9.3.5. Зашифрованный и незашифрованный RTCP-пакеты (#ssrc)

SDES: RTCP-пакет описания источника

Зависимость поглощающей способности земной атмосферы от длины волны

Рисунок 3.3.1а. Зависимость поглощающей способности земной атмосферы от длины волны

Из рисунка видно, что заметную роль в поглощении радиоволн играет вода. По этой причине сильный дождь, град или снег могут привести к прерыванию связи. Поглощение в атмосфере ограничивает использование частот более 30 ГГц. Атмосферные шумы, связанные в основном с грозовыми разрядами, доминируют при низких частотах вплоть до 2 МГц. Галактический шум, приходящий из-за пределов солнечной системы дает существенный вклад вплоть до 200 ГГц. Зависимость поглощения радиоволн в тумане и дожде от частоты показана на Рисунок 3.3.2.

Зависимость поглощения радиоволн в тумане и дожде от частоты

Рисунок 3.3.2. Зависимость поглощения радиоволн в тумане и дожде от частоты

Мощность передатчика обычно лежит в диапазоне 50 мВт - 2 Вт. Модемы, как правило, используют шумоподобный метод передачи SST (spread spectrum transmission). Для устройств на частоты 2.4 ГГц и выше, как правило, используются направленные антенны и необходима прямая видимость между приемником и передатчиком. Такие каналы чаще работают по схеме точка-точка, но возможна реализация и многоточечного соединения. На аппаратном уровне здесь могут использоваться радиорелейное оборудование радиомодемы или радио-бриджи. Схема этих устройств имеет много общего. Отличаются они лишь сетевым интерфейсом (см. Рисунок 3.3.3). Антенна служит как для приема, так и для передачи. Трансивер (приемопередатчик) может соединяться с антенной через специальные усилители. Между трансивером и модемом может включаться преобразователь частот. Модемы подключаются к локальной сети через последовательные интерфейсы типа RS-232 или v.35 (RS-249), для многих из них такие интерфейсы являются встроенными. Отечественное радиорелейное оборудование имеет в качестве выходного интерфейс типа G.703 и по этой причине нуждается в адаптере. Радио-бриджи имеют встроенный Ethernet-интерфейс. Длина кабеля от модема до трансивера лежит в пределах 30-70м, а соединительный кабель между модемом и ЭВМ может иметь длину 100-150м. Трансивер располагается обычно рядом с антенной.

E	Операции, нумерация и маршрутизация.
G	Телекоммуникационные системы передачи.
H	Линии передачи для нетелефонных сигналов.
I	Общие материалы по ISDN.
Q	Сигнальные системы.
T	Терминальное оборудование и протоколы телекоммуникационных услуг.
V	Передача данных по коммутируемым телефонным сетям.
X	Сети передачи данных.

Код рекомендации	Содержание
ANSI T1.102	Цифровая иерархия - электрические интерфейсы;
ANSI T1.111-116	Сигнальная система N7;
ANSI T1.403	Конструкция интерфейса DS1
ANSI T1.408	Спецификация связи пользователя с первым уровнем первичного канала;
ANSI T1.602	Интерфейс базового канала, процедура доступа к первичному каналу, D-канал (LAP1); связной протокол BRI/PRI;
ANSI T1.603	Минимальный набор услуг для интерфейса первичного канала ISDN;
ANSI T1.604	Минимальный набор услуг базового канального интерфейса ISDN;
ANSI T1.605	Спецификация интерфейса базового канала для связи пользователя с сетью; спецификация интерфейса BRA S/T;
ANSI T1.606	Описание услуг Frame Relay;
ANSI T1.607	Основные управляющие процедуры для BRI и PRI;
ANSI T1.608	Пакетные режимы канала. Управляющие процедуры BRI и PRI;
ANSI T1.609	Цифровая система подписки N1 ISDN для межсетевых связей в рамках сигнальной системы N7;
ANSI T1.610	Базовые процедуры для управления вспомогательными услугами ISDN;
ANSI T1.617	Сигнальные спецификации для канальных услуг Frame Relay;
ANSI T1.618	Базовые аспекты протокола Frame Relay;
CCIR 601-1	Параметры кодировки студийного цифрового телевидения;
ECMA-104	Физический уровень интерфейса для доступа к первичному каналу в частных телекоммуникационных сетях;
ECMA-105	Протокол уровня канала данных для D-канала интерфейса в эталонной точке между терминальным оборудованием и частной телекоммуникационной сетью;
ECMA-106	Протокол третьего уровня для управления переадресацией вызовов через интерфейс D-канала в эталонной точке S между терминальным оборудованием и частной телекоммуникационной сетью
ECMA-123	Обмен параметрами в частных ISDN-сетях на базе стандарта ECMA-102;
ECMA-133	Эталонная конфигурация для вызовов через коммутатор частной телекоммуникационной сети;
ECMA-134	Метод спецификации базовых и дополнительных видов сервиса в частных телекоммуникационных сетях.
ECMA-135	Алгоритмы связи коммутаторов частных телекоммуникационных сетей;
ECMA-141	Протокол уровня канала данных для эталонной точки Q сигнального канала между коммутаторами частных телекоммуникационных сетей;
ECMA-142	Влияние спецификации, функциональной модели и потоков данных на управление базовыми услугами в частных телекоммуникационных сетях;
ECMA-143	Протокол третьего уровня для управления переадресацией вызовов между коммутаторами частных телекоммуникационных сетей;
ECMA148	Идентификация дополнительных услуг в частных телекоммуникационных сетях; спецификация, функциональные модели и информационные потоки;
ECMA-155	Адресация в частных телекоммуникационных сетях;
ECMA-156	Основные процедуры для управления дополнительными услугами, используя протокол keypad в эталонной точке S.
ECMA-157	Протокол управления по D-каналу в эталонной точке S интерфейсами между терминальным оборудованием и частной телекоммуникационной сетью для поддержки идентификации дополнительных услуг.
F.60	Стандарт телексной связи
F.69	Стандарт для телексных адресов
F.160	Стандарт на международную общественную факсную связь
F.200	Стандарт телетекстной связи
F.201	Стандарт для служб межсетевого обмена для телетекста и телекса
F.300	Набор рекомендаций для систем видеотекста
F.401	Стандарт на имена и адреса при передаче сообщений
F.410	Стандарт службы передачи сообщений
F.420	Стандарт для частного обмена сообщениями

Принципы формирования кода отклика в системе SMTP

Протокол обратного адресного преобразования RARP

Протокол реального времени RTP

Протокол резервирования ресурсов RSVP

Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)

Работа

Расширение RPSL

Рекомендации CCITT по телекоммуникациям

RSVP в ЭВМ и маршрутизаторе

Схема для иллюстрации методики составления маршрутных таблиц g g g- Маршрутизаторы

Схема оборудования радиоканала передачи данных

Схема подключения к Интернет подвижных объектов

Схема подключения объектов через радио-бриджи с помощью всенаправленной антенны

Схема подключения радио-модемов

Схема подключения сервера к переключателю

Схема реализации nfs-системы клиент-сервер

Схема сетевого моста

Схема сетевого повторителя

Схема спутниковой связи VSAT

Схема входового сетевого переключателя

Система аутентификации удаленных пользователей при подключении через модем RADIUS

Словарь RPSL

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

Ссылки

Ссылки

Приведенные коэффициенты, по сути, представляют

Таблица

Таблица

атрибутов

Частотные диапазоны, используемые для спутниковых телекоммуникаций

Cпецификация стандартизованных значений атрибутов

Допустимые коды поля значение и их назначения

Код поля значение атрибута NAS-Port-Type

Коды поля значение

Коды программ, используемых в NFS

маршрутизации RIP содержит

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

Правила UDP-инкапсуляции

Правила UDP-инкапсуляции для мультикастных сообщений Path

представляет результаты

Типы пакетов RTCP

Типы SDES

Возможные коды поля значение

Значения кодов поля команда

Типы пакетов

Транспортный протокол реального времени RTCP

Вариант схемы внутренних связей переключателя

Внутренний протокол маршрутизации RIP

и модемных пулов при большом

Взаимодействие с политикой в классе aut-num

Заголовок пакета RTP

Зашифрованный и незашифрованный RTCP-пакеты (#ssrc)

Зависимость поглощающей способности земной атмосферы от длины волны

Зависимость поглощения радиоволн в тумане и дожде от частоты