10.14 Принципы формирования кода отклика в системе SMTP
Код | Назначение |
1yz |
Промежуточный позитивный отклик. Команда воспринята. Отправитель должен послать следующую команду. |
2yz |
Позитивное подтверждение завершения операции. Можно посылать следующий запрос. |
3yz |
Позитивный промежуточный отклик, сходный с 1yz, используется в случае групповых команд. |
4yz |
Временный негативный отклик. Команда не исполнена, но характер ошибки временный и выполнение процедуры может быть позже повторено. |
5yz |
Окончательный негативный отклик. Команда не воспринята, запрошенная операция не выполнена и не будет выполнена. |
Вторая цифра кода может иметь следующие значения:
x0z |
Синтаксис - эти отклики относятся к синтаксическим ошибкам или к командам синтаксически корректным но примененным неправильно. |
x1z |
Информация - относится к командам, которые запрашивают информацию, например, статусную или справочную. |
x2z |
Соединения - относится к телекоммуникационному каналу. |
x3z |
Пока не определен. |
x4z |
Пока не определен. |
x5z |
Почтовая система - эти отклики индицируют статус получателя или отправителя почты. |
Третья цифра уточняет смысл второй.
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).
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).
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. |
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 только о классах, которые ему известны, проблемы совместимости возникнуть просто не может.
Прежде чем добавлять новый класс, следует ответить на вопрос, относится ли информация, содержащаяся в объекте, к новому классу.
10.1 Рекомендации CCITT по телекоммуникациям
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 | Стандарт для частного обмена сообщениями |
F.421 | Стандарт для коммуникаций между системами X.400 для обмена частными и телексными сообщениями |
F.500 | Стандарт международной службы каталогов |
G.702 | Иерархия цифровых скоростей обмена |
G.703 | Физические и электрические характеристики цифровых интерфейсов. |
G.707 | Иерархия частот синхронной передачи двоичной цифровой информации |
G.708 | Синхронный интерфейс сетевого узла для цифровой передачи данных в широком диапазоне частот следования. |
G.709 | Структура синхронного мультиплексирования. |
G.711 | Импульсно-кодовая модуляция (PCM) голосовых частот. |
G.721 | Адаптивная дифференциальная кодово-импульсная модуляция (ADPCM) для частоты 32 Кбит/с. |
G.722 | Аудио кодирование в частотном диапазоне 7 кГц для скоростей передачи 64 Кбит/с. |
G.725 | Системные аспекты использования 7 килогерцного аудио кодека на скоростях передачи 64 Кбит/с. |
G.728 | CCITT рекомендация для ADPCM при16 Кбит/с (3.1 кГц) |
H.221 | Структура кадра канала на 64 Кбит/с для аудио и видео приложений. |
H.231 | Многоточечный контроль для скоростей 64-2048 Кбит/с |
H.242 | Коммуникационные процедуры, 64-2048 Кбит/с. |
H.243 | Многоточечные коммуникационные процедуры, 64-2048 Кбит/с. |
H.261 | Видео кодек для аудио-видео сервиса при p*64 Кбит/с (p=1-30). |
H.320 | CCITT рекомендации для узкополосных видео-телефонных систем и терминального оборудования со скоростями не более 1920 Кбит/с. Общее описание CODEC. |
I.110 | Введение и общая структура серии документов “I” для интегрированных цифровых сетей ISDN |
I.111 | Взаимоотношения с другими рекомендациями, относящимися к ISDN |
I.112 | Словарь терминов ISDN |
I.113 | Словарь терминов для широкополосной ISDN |
I.120 | Интегрированные цифровые сети ISDN |
I.121 | Широкополосные аспекты ISDN |
I.122 | Рамки для предоставления услуг в канале, работающем в пакетном режиме |
I.130 | Метод описания телекоммуникационных услуг, поддерживаемых ISDN и сетевые возможности ISDN |
I.140 | Методика атрибутов для описания телекоммуникационных услуг ISDN сетевых возможностей ISDN |
I.141 | Атрибуты сети ISDN |
I.150 | Характеристики ATM B-ISDN |
I.200 | Указатель по серии рекомендаций I.200 |
I.210 | Принципы предоставления телекоммуникационных услуг ISDN и методы их описания |
I.211 | Аспекты услуг B-ISDN |
I.220 | Общее динамическое описание базовых телекоммуникационных услуг |
I.221 | Общие характеристики услуг |
I.327 | Функциональная архитектура сетей B-ISDN. |
I.230 | Определение категорий услуг, предоставляемых каналом |
Коммутация каналов |
|
I.231 | Категории схемных услуг, предоставляемых каналом |
I.231.1 | 64 Кбит/с (структура по 8кбит/с) |
I.231.2 | 64 Кбит/с (структура по 8кбит/с) с возможностью передачи звуковой информации |
I.231.3 | 64 Кбит/с (структура по 8кбит/с) для аудио-передачи с полосой 3.1 кГц |
I.231.4 | 64 Кбит/с (структура по 8кбит/с) попеременный разговор |
I.231.5 | 2* 64 Кбит/с (структура по 8кбит/с) |
I.231.6 | 384 Кбит/с (структура по 8кбит/с) |
I.231.7 | 1536 Кбит/с (структура по 8кбит/с) |
I.231.8 | 1090 Кбит/с (структура по 8кбит/с) |
Коммутация пакетов |
|
I.232 | Категории пакетных услуг, предоставляемых каналом |
I.232.1 | Виртуальный вызов и постоянная виртуальная схема |
I.232.2 | Бессвязная схема |
I.232.3 | Пользовательская сигнальная система |
I.233.1 | Услуги передачи кадров (frame relay) в ISDN - передача кадров |
I.233.2 | Услуги передачи кадров (frame relay) в ISDN - коммутация кадров |
I.240 | Определение удаленных услуг |
I.241 | Удаленные услуги, поддерживаемые ISDN |
I.250 | Определение дополнительных услуг |
I.251 | Идентификационные коды вспомогательных услуг |
I.252 | Запрос вспомогательных услуг |
I.253 | Завершение выполнения вспомогательных услуг |
I.253.1 | Ожидание запроса вспомогательных услуг |
I.254 | Вспомогательные услуги для нескольких клиентов |
I.255.4 | Приоритетное обслуживание |
I.257 | Передача дополнительной информации |
I.310 | Принципы работы сети ISDN |
I.311 | Общие аспекты сети B-ISDN |
I.312(Q.1201) | Принципы архитектуры интеллектуальных сетей |
I.320 | Эталонная модель протоколов ISDN |
I.321 | Эталонная модель протоколов B-ISDN и ее применение |
I.324 | Архитектура сети ISDN |
I.325 | Типы эталонных конфигураций соединений в ISDN |
I.326 | Относительные требования к ресурсам сети |
I.327 | Функциональная архитектура сети B-ISDN |
I.328 (Q.1202) | Интеллектуальная сеть - архитектура плоскости услуг |
I.329 (Q.1203) | Интеллектуальная сеть - архитектура глобальных функций |
I.330 | Принципы нумерации и адресации в ISDN |
I.331 (E.164) | Схема нумерации в ISDN |
I.332 | Принципы нумерации для межсетевых соединений ISDN и сетей с различными схемами нумерации |
I.333 | Выбор терминала в ISDN |
I.334 | Принципы связи чисел/субадресов ISDN и сетевых адресов эталонной модели OSI |
I.335 | Принципы маршрутизации ISDN |
I.351 (G.821/2) | Рекомендации других серий, связанные c работой сети, для эталонной точки T ISDN |
I.352 | Объективные характеристики сети, связанные с задержками соединений в ISDN |
I.361 | Спецификация слоя ATM B-ISDN |
I.362 | Функциональное описание адаптационного уровня для B-ISDN (AAL). |
I.363 | Спецификация уровня адаптации (AAL) ATM B-ISDN |
I.370 | Управление перегрузкой для каналов фрейм-релей ISDN |
I.410 | Общие аспекты и принципы, связанные с рекомендациями для пользовательского интерфейса ISDN |
I.411 | Сетевой интерфейс пользователя ISDN - эталонная конфигурация |
I.412 | Интерфейс пользователя сети ISDN - структура интерфейса возможности доступа |
I.413 | Интерфейс пользовательской сети B-ISDN |
I.420 | Базовый сетевой интерфейс пользователя |
I.421 | Сетевой интерфейс пользователя первичного быстродействия |
I.430 | Базовый сетевой интерфейс пользователя - спецификация слоя 1 |
I.431 | Сетевой интерфейс пользователя первичного быстродействия - спецификация уровня 1 |
I.432 | Сетевой интерфейс пользователя B-ISDN - спецификация физического уровня |
I.440 (Q.920) | Связной информационный уровень сетевого интерфейса пользователя ISDN общие аспекты |
I.441 (Q.921) | Сетевой интерфейс пользователя ISDN - спецификация связного информационного уровня |
I.450 (Q.930) | Сетевой интерфейс пользователя ISDN - уровень 3, общие аспекты |
I.451 (Q.931) | Спецификация уровня 3 для сетевого интерфейса пользователя ISDN для управления базовыми запросами |
I.452 (Q.932) | Общие процедуры для управления дополнительными услугами ISDN |
I.460 | Мультиплексирование, адаптация к скорости передачи и поддержка существующих интерфейсов |
I.461 (X.30) | Поддержка терминального оборудования (DTE) базирующегося на X.21, X.21бис и X.20бис интегрированными цифровыми сетями (ISDN) |
I.462 (X.31) | Базовые процедуры для управления дополнительными услугами ISDN |
I.463 (V.110) | Поддержка ISDN терминального оборудования в пакетном режиме |
I.464 | Мультиплексирование, адаптация к скорости передачи и поддержка существующих интерфейсов для передачи на скоростях 64 Кбит/с |
I.465 (V.120) | Поддержка ISDN терминального оборудования с интерфейсами типа V при статистическом мультиплексировании |
I.470 | Взаимодействие терминальных функций и ISDN |
I.500 | Общая структура рекомендаций для взаимодействия ISDN |
I.510 | Определения и общие принципы взаимодействия в ISDN |
I.511 | Интерфейс уровня 1 для системы ISDN-ISDN |
I.515 | Обмен параметрами при взаимодействии систем ISDN |
I.520 | Общие принципы организации для межсетевых взаимодействий в ISDN |
I.530 | Взаимодействие сетей ISDN и публичных коммутируемых телефонных сетей |
I.540 (X.321) | Общие приспособления для взаимодействия между сетями ISDN и коммутируемыми публичными телефонными сетями (CSPDN) |
I.550 (X.325) | Общие приспособления для взаимодействия между сетями ISDN и публичными сетями с пакетным переключением (PSPDN) для целей передачи информации |
I.560 (U.202) | Требования, предъявляемые к системе ISDN для обеспечения телексных услуг |
I.601 | Общие принципы работы системы доступа для клиента ISDN и инсталляция клиента |
I.602 | Использование принципов ISDN при инсталляции клиентов |
I.603 | Использование принципов работы ISDN для обеспечения доступа |
I.604 | Использование принципов работы ISDN для обеспечения доступа на первичных скоростях обмена |
I.605 | Применение принципов статического мультиплексирования при реализации базового доступа к ISDN |
I.610 | OAM-принципы доступа в B-ISDN |
ISO 2110 | Передача данных 25-контактный соединитель интерфейса DTE-DCE и распределение его контактов. |
ISO 2593 | Распределение контактов разъема для высокоскоростного терминального оборудования. |
ISO 3166 | Коды стран (DCC - Data Country Code). |
ISO 4902 | Передача данных. 37- и 9-контактные разъемы интерфейса DTE-DCE и распределение контактов. |
ISO 4903 | Передача данных. 15-контактный разъем интерфейса DTE-DCE и распределение контактов. |
ISO 8473 | Протокол доступа к сети без непосредственной связи (CLNAP ConnectionLess Network Access Protocol) |
ISO 8877 | Интерфейсный разъем и назначение контактов для эталонных точек доступа ISDN S и T. |
ISO 9282-2 | Метод сжатия стационарного изображения |
ISO 11172-3 | Кодировка движущегося изображения и сопровождающего звука для цифровых систем записи при скоростях передачи 1,5 Мбит/с - Часть 3. Звук. |
Q.500 | Введение и область применения ISDN |
Q.512 | Интерфейс коммутатора для доступа клиентов ISDN |
Q.513 | Интерфейс коммутатора для операций, администрирования и обслуживания |
Q.521 | Функции интерфейса |
Q.522 | Цифровой коммутатор. Связи, управление, вспомогательные функции |
Q.541 | Общая конструкция |
Q.542 | Конструкция, операции и обслуживание |
Q.543 | Рабочие характеристики систем ISDN |
Q.544 | Измерения на коммутаторе ISDN |
Q.551 | Передающие характеристики цифровых коммутаторов |
Q.552 | Передающие характеристики 2-х проводных аналоговых интерфейсов |
Q.553 | Передающие характеристики 4-х проводных аналоговых интерфейсов |
Q.554 | Передающие характеристики цифровых интерфейсов |
Q.700-795 | Спецификация сигнальной системы N7. |
Q.920 | Интерфейс пользователя в сети ISDN, общие аспекты связного уровня. |
Q.921 | Интерфейс пользователя в сети ISDN, спецификация связного уровня. |
Q.922 | Спецификация ISDN связного уровня для пакетной передачи данных. |
Q.930 | Интерфейс пользователя в сети ISDN, слой 3, общие принципы. |
Q.931 | Интерфейс пользователя в сети ISDN, спецификация слоя 3, базовые процедуры управления. |
Q.932 | Базовые операции управления дополнительными процедурами в ISDN. |
Q.933 | Цифровая сигнальная подписная система N1 (DSS1), сигнальные модификации для режима передачи кадров |
T.4 | Стандарт на факсимильное оборудование группы 3 для передачи документации. |
T.6 | Схемы кодирования изображения и кодирование функций управления для факсимильного оборудования группы 3. |
T.81 | Кодирование фотографического изображения. |
T.411-418 | Открытая архитектура документации (ODA) |
T.431-433 | Манипуляция документами и протокол передачи DTAM. |
T.503 | Профайл BTO для передачи факсимильных документов группы 4. |
T.521 | Коммуникационный профайл BTO для пересылки документов большого объема, базирующейся на методике сессий. |
T.563 | Терминальные характеристики факсимильного оборудования группы 4. |
V.24 | Перечень определений цепей связи DTE и DCE (для DTE, работающих с модемами). Этой спецификации соответствуют RS-232-C, RS-449-A. |
V.28 | Электрические характеристики несимметричных цепей интерфейса, работающего с биполярными токовыми сигналами. |
X.3 | Спецификация ПАД для общественных сетей (X.25) |
X.20 | DTE-DCE интерфейс старт-стопной передачи данных по сетям общего пользования |
X.21 | DTE-DCE интерфейс для синхронной передачи данных по сетям общего пользования. Определяет физические характеристики и процедуры управления. |
X.21бис | Использование DTE, рассчитанного на сопряжение с синхронными модемами, удовлетворяющими рекомендациям серии V в сетях обмена данными общего пользования |
X.22 | Мультиплексный интерфейс DTE-DCE для классов обслуживания абонентов 3-6; |
X.24 | Перечень определений цепей интерфейса DTE-DCE. Определяет функции цепей передачи данных, управления и синхронизации. |
X.25 | Протокол пакетного уровня для интерфейса DTE-DCE и терминалов, подключенных к общественным сетям. |
X.26 | Электрические характеристики несимметричных двухполюсных цепей, предназначенных для общего использования в устройствах передачи данных (V.10). |
X.27 | Электрические характеристики симметричных цепей, предназначенных для устройств передачи информации с сетях общего пользования (V.11). |
X.28 | Интерфейс DTE-DCE для старт-стопного режима работы терминального оборудования, работающего в общественных сетях с использованием ПАД. |
X.29 | Процедуры обмена управляющей информацией и данными между ПАД и DTE или другим ПАД (пакетный ассемблер-дизассемблер). |
X.31 | Поддержка терминального оборудования, работающего в пакетном режиме (ISDN). |
X.32 | Интерфейс DTE-DCE для терминалов, работающих в пакетном режиме и связанных с коммутируемой телефонной сетью общего пользования. |
X.75 | Терминальные управляющие процедуры и системы передачи данных для международных межсетевых обменов. |
X.121 | Схема нумерации для общественных информационных сетей |
X.150 | Испытательные шлейфы DTE и DCE для сетей обмена данными общего пользования. |
X.200 | Эталонная модель соединения открытых систем для приложений. |
X.208 | CCITT-версия OSI ASN.1 |
X.209 | Версия OSI ASN.1 базовых правил кодирования (BER) |
X.210 | Рекомендации по сервису в открытых системах на связном уровне. |
X.211 | Физическое определение услуг в OSI для CCITT-приложений |
X.212 | Определения услуг информационных каналов в OSI для CCITT-приложений |
X.213 | Определения сетевых услуг для связей между открытыми системами. |
X.214 | Определение транспортных услуг связи открытых систем для приложений CCITT. |
X.215 | Определение сессий для связанных открытых систем. |
X.216 | Описание процедур презентации для связанных открытых систем. |
X.217 | Описание процедуры управления для связанных открытых систем. |
X.218 | CCITT-эквивалент ISO 9066-1: Надежная пересылка текстов |
X.219 | Удаленные операции: модель, нотация и описание услуг. |
X.223 | Использование X.25 для обеспечения сетевой связи в режиме OSI |
X.224 | Спецификация транспортного протокола связи открытых систем для приложений CCITT. |
X.225 | Спецификация протокола сессий для связанных открытых систем. |
X.226 | Протокол презентаций для связанных открытых систем. |
X.227 | Спецификация протокола управления для связанных открытых систем. |
X.228 | Надежная передача данных, спецификация протокола. |
X.229 | Удаленные операции: спецификация протокола. |
X.237 | Определения передачи, одновременности и служб восстановления для связанных открытых систем. |
X.247 | Спецификация передачи, одновременности и служб восстановления для связанных открытых систем. |
X.400 | Система обработки сообщений: системная модель, элементы сервиса. |
X.401 | Система обработки сообщений: базовые элементы сервиса и опционные пользовательские возможности. |
X.402 | Стандарт для пересылки сообщений |
X.403 | CCITT-система работы с сообщениями: Проверка сохранности |
X.407 | Абстрактные описания услуг |
X.408 | Система обработки сообщений: правила преобразования кодированной информации. |
X.409 | Система обработки сообщений: синтаксис и нотация презентационных пересылок. |
X.410 | Система обработки сообщений: удаленные операции и надежный сервер пересылок. |
X.411 | Система обработки сообщений: уровень передачи сообщений. |
X.413 | Запоминание сообщений: абстрактные определения услуг |
X.419 | Спецификации протоколов |
X.420 | Система обработки сообщений: уровень обмена сообщениями между пользователями сети. |
X.430 | Система обработки сообщений: протокол доступа для терминалов телетекста. |
X.500 | Стандарт на каталоги, базирующийся на OSI (RFC 1279, 1275, 1274) |
X.509 | CCITT-каталоги: Система идентификации |
X.511 | Абстрактные описания услуг |
X.519 | Спецификации протоколов |
X.520 | Некоторые типы атрибутов |
X.521 | Для определенных классов объектов |
Z.100-104 | SDL (Specification and Description Language) язык описания и спецификаций |
Рисунок 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, и
Рисунок 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 позволяет ограничить зону распространения широковещательных пакетов, улучшая эксплуатационные характеристики сети в целом.
Рисунок 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).
Рисунок 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 Мбит/с.
4.5.3.1 Система аутентификации удаленных пользователей при подключении через модем RADIUS
(RFC-2138. Remote Authentication Dial In User Service, P. Vixie, S. Thomson, Y. Rekhter, J. Bound.)
Рисунок .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 выглядит следующим образом:
med = -50; | # -50 лежит вне диапазона |
med = igp; | # igp не является одним из значений enum |
med.assign(10); | # заданный метод не определен |
community.append(AS3561:20); | # первый аргумент должен быть равен 3561. На Рисунок .28 показан более продвинутый пример, использующий rp-атрибут community. В этом примере, AS3561 базирует свое предпочтение при выборе маршрута на атрибуте community. Другие AS могут апосредовано влиять на выбор маршрутов AS3561 путем включения соответствующих значений communities в их оповещения о маршрутах. |
export: | to AS2 action community.={3561:90}; |
to AS3 action community.={3561:80}; | |
announce AS1 |
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. |
Коэффициент | Название |
Коэффициент Дайса (dice) | |
Коэффициент Джаккарда (jaccard) | |
Косинусный коэффициент | |
Коэффициент перекрытия |
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/ |
Номер | Название диапазона | Частота | Длина волны |
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.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.
Таблица .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.
Таблица .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
Таблица 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 содержит по записи на каждую обслуживаемую машину (на каждый маршрут). Запись должна включать в себя:
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 |
Атрибут должен присутствовать в пакете обязательно один раз. |
Таблица 4.4.9.6.1. Правила UDP-инкапсуляции для уникастных сообщений Path и Resv
(D – уникастный адрес места назначения; R – маршрутизатор; Raw – режим произвольных операций сетевого ввода/вывода.)
Узел |
RSVP посылает |
RSVP получает |
Hu |
UDP(D/Ra,Pu) [1] |
UDP(D,Pu) и UDP(D,Pu’) [2] |
Hr |
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. |
Таблица 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(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.
Таблица представляет результаты запроса, направленного системе поиска. Представленная таблица должна существовать для каждого из индексных терминов.
Если мы обладаем всей информацией о релевантных и нерелевантных документах в коллекции документов, то применимы следующие оценки:
Таблица 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. Экспериментаторам предлагается зарегистрировать числа, которые им нужны, а затем аннулировать регистрацию, если необходимость в них отпадет.
Таблица 4.4.9.3.2. Типы SDES
Сокращенное название |
Имя |
Значение |
END | Конец списка SDES | 0 |
CNAME | Каноническое имя | 1 |
NAME | Имя пользователя | 2 |
Электронный адрес пользователя | 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.
Таблица 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
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. Вариант схемы внутренних связей переключателя.
4.4.11.1 Внутренний протокол маршрутизации RIP
Этот протокол маршрутизации предназначен для сравнительно небольших и относительно однородных сетей (алгоритм Белмана-Форда). Протокол разработан в университете Калифорнии (Беркли), базируется на разработках фирмы Ксерокс и реализует те же принципы, что и программа маршрутизации routed, используемая в ОC Unix (4BSD). Маршрут здесь характеризуется вектором расстояния до места назначения. Предполагается, что каждый маршрутизатор является отправной точкой нескольких маршрутов до сетей, с которыми он связан. Описания этих маршрутов хранится в специальной таблице, называемой маршрутной.
Услуга | NAS обеспечивает пользователю, подключенному через модем, определенные услуги, такие как PPP или Telnet. |
Сессия | Каждый вид услуг, предоставляемый NAS через модемную связь, представляет собой сессию. Начало сессии сопряжено с моментом начала предоставления данной услуги, а конец – со временем завершения этого процесса. Пользователь может иметь несколько сессий одновременно, если сервер поддерживает такой режим. |
Это означает, что программа выбрасывает пакет без какой-либо обработки. Программная реализация должна предоставлять возможность диагностирования таких случаев и записи их статистики. |
Рисунок .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} |
Рисунок 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.
Рисунок 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м. Трансивер располагается обычно рядом с антенной.