Процедуры сообщений Address
LSR, который получает сообщение Address, использует эти адреса, чтобы поддерживать базу данных соответствия между идентификаторами партнеров LDP и адресами узлов следующего шага. Смотри раздел "Идентификаторы LDP и адреса следующего шага".
Когда инициализирована новая LDP сессия, перед тем как послать сообщение присвоения и запроса метки LSR должен анонсировать адреса своих интерфейсов в одном или более сообщениях Address.
Всякий раз, когда LSR "активизирует" новый адрес интерфейса, он должен анонсировать новый адрес с помощью сообщения адреса.
Всякий раз, когда LSR "деактивирует" ранее анонсированный адрес, ему следует отозвать адрес с помощью сообщения отзыва адреса (Address Withdraw); смотри раздел "Сообщение отзыва адреса".
Если LSR не поддерживает семью адресов, специфицированную в TLV списка адресов, он должен послать уведомление "Unsupported Address Family" LDP, сигнализируя об ошибке и прервать обработку сообщения.
Процедуры сообщения Hello
LSR, получающий Hello от другого LSR, поддерживает сопредельность Hello. LSR поддерживает таймер удержания, запуская его каждый раз, когда получает Hello, которое соответствует условию сопредельности. Если таймер удержания истечет, LSR аннулирует сопредельность Hello: смотри раздел "Поддержание сопредельности" и "Поддержание LDP сессий".
Мы рекомендуем, чтобы интервал между посылками Hello составлял не более одной трети от времени удержания Hello.
LSR обрабатывает полученные LDP Hello следующим образом:
LSR проверяет, приемлемо ли сообщение Hello. Критерии определения приемлемости Hello зависят от конкретной реализации (примеры критериев смотри ниже).
Если Hello неприемлемо, LSR его игнорирует.
Если Hello приемлемо, LSR проверяет, имеет ли он сопредельность для отправителя Hello. Если да, то он перезапускает таймер удержания. Если нет, то он формирует сопредельность для Hello отправителя и перезапускает таймер.
Если Hello несет в себе какой-либо опционный TLV, LSR обрабатывает его (смотри ниже).
Наконец, если LSR не имеет сессий LDP для пространства меток, специфицированного идентификатором LDP в заголовке PDU сообщения Hello, он следует процедурам из раздела "Установление сессии LDP".
Ниже представлены критерии приемлемости для сообщений канального и целевого Hello:
Канальное Hello приемлемо, если интерфейс, через который оно получено, сконфигурирован для коммутации по меткам.
Целевое Hello, поступившее от отправителя с адресом A приемлемо, если:
LSR был сконфигурирован для приема целевых Hello, или
LSR был сконфигурирован посылать целевые Hello по адресу A.
Далее описано то, как LSR обрабатывает опционные TLV Hello:
Транспортный адрес
LSR ассоциирует специфицированные транспортные адреса с сопредельностью Hello.
Порядковый номер конфигурации
Опционный параметр порядковый номер конфигурации используется LSR отправителем, чтобы сигнализировать принимающему LSR об изменениях конфигурации. При получении LSR, играющий активную роль в установлении LDP сессии, детектирует изменение конфигурации LSR-отправителя, при обнаружении изменений он может сбросить установки сессии, сопряженные LSR-отправителем (смотри раздел "Инициализация сессии").
LSR-отправитель, использующий этот опционный параметр, ответственен за поддержание порядкового номера конфигурации, который он передает в сообщениях Hello. Когда бы ни произошло изменение конфигурации LSR-отправителя, он инкрементирует порядковый номер конфигурации.
Процедуры сообщения инициализации
Описание общих процедур обработки сообщений инициализации смотри раздел "Установление сессии LDP" и в частности раздел "Инициализация сессии".
Процедуры сообщения KeepAlive
Механизм таймера KeepAlive, рассмотренный в разделе "Поддержка LDP сессий" сбрасывает таймер KeepAlive каждый раз, когда приходит LDP PDU через TCP соединение сессии. Сообщение KeepAlive предназначено для сброса таймера KeepAlive в обстоятельствах, где LSR не имеет другой информации для обмена с LDP партнером.
LSR должен позаботиться, чтобы его партнер получал от него сообщение, по крайней мере, раз за период KeepAlive. Любое протокольное сообщение LDP годится, в обстоятельствах, где никакие другие протокольные LDP сообщения не посылаются в течение этого периода, рекомендуется посылать сообщение KeepAlive.
Процедуры сообщения освобождения метки (Label Release)
LSR передает партнеру сообщение освобождения метки, когда он не нуждается более в ранее полученной или запрошенной метке у данного партнера. LSR должен передать сообщение освобождения метки при выполнении любого из следующих условий:
LSR, который присвоил метку, не является более узлом следующего шага для ассоциации FEC-метка, и LSR сконфигурирован для работы в консервативном режиме.
LSR получает сообщение присвоения метки от LSR, который не является следующим шагом для заданного FEC, а LSR сконфигурирован для работы в консервативном режиме.
LSR получает сообщение отзыва метки.
Заметим, что если LSR сконфигурирован для работы в "свободном режиме", сообщение освобождения никогда не будет передано в случае возникновения условий (1) и (2). В этом случае вышестоящий LSR сохраняет каждую из неиспользованных меток, так что он может немедленно их использовать позднее, если нижестоящий партнер станет следующим шагом для FEC.
TLV FEC специфицирует FEC, для которого следует освободить метки. Если за FEC не следует TLV метки, все метки, ассоциированные с FEC, должны быть освобождены, в противном случае должна быть освобождена только метка, специфицированная в опционном TLV метки.
TLV FEC может содержать элемент Wildcard FEC; если это так, оно может не содержать других элементов FEC. В этом случае, если сообщение освобождения метки содержит опционное TLV метки, тогда метка должна быть освобождена для всех FEC, с которыми ассоциирована. Если в сообщении освобождения метки нет опционного TLV метки, тогда LSR-отправитель освобождает все метки, ассоциации с которыми он получил от LSR-получателя. Подробности смотри в приложении A "Процедуры рассылки меток LDP ".
Процедуры сообщения отзыва метки (Label Withdraw)
LSR посылает сообщение отзыва метки в следующих случаях:
LSR не распознает более известный ранее FEC, для которого была анонсирована метка.
LSR односторонне решил (напр., в результате конфигурации) не коммутировать пакеты для одного или более FEC с меткой, которая была отозвана.
TLV FEC специфицирует FEC, для которого следует отозвать метки. Если за FEC не следует никакого TLV метки, все метки, ассоциированные с FEC, должны быть отозваны; в противном случае следует отозвать только метку, специфицированную в опционном TLV метки.
TLV FEC может содержать элемент Wildcard FEC; если это так, он может не содержать других элементов FEC. В этом случае, если сообщение отзыва метки содержит опционный TLV метки, тогда метка должна быть отозвана для всех FEC, с которыми она ассоциирована. Если в сообщении отзыва метки нет опционного TLV метки, тогда LSR-отправитель отзывает все ассоциации меток, анонсированные ранее LSR-получателю.
LSR, который получает сообщение отзыва метки, должен откликнуться сообщением освобождения метки. Подробности смотри в приложении A "Процедуры LDP для рассылки меток".
Процедуры сообщения присвоения меток
Сообщение присвоения метки используется LSR, чтобы разослать метки для FEC партнерам LDP. Если LSR рассылает ассоциацию метки нескольким LDP-партнерам, он решается локально, следует ли присвоить метку для заданного FEC и разослать это эту ассоциацию всем партнерам, или использовать разные ассоциации для каждого из партнеров.
LSR ответственен за взаимную согласованность распределения меток и за информирование партнеров об этом распределении.
LSR, получая сообщения присвоение меток от LSR ниже по течению, для префикса или элемента FEC адреса ЭВМ, не должны использовать метки для переадресации, если только их маршрутная таблица не содержит записи, которая в точности соответствует элементу FEC. Подробности смотри в приложении A "Процедуры рассылки меток LDP ".
Процедуры сообщения уведомления
Промежуточный и оконечный узлы могут запустить процесс установления административного статуса посредством использования сообщений Notify. Чтобы выполнить это, промежуточный или оконечный узел генерирует сообщение уведомления (Notify) с соответствующей информацией сессии в направлении вверх по течению. Объект административного состояния должен включаться в информацию сессии. Бит R (Reflect) не должен быть установлен. Сообщение Notify может быть, если требуется, инкапсулировано, смотри раздел 4.3.
Входной узел, получив сообщение уведомления, содержащее объект административного состояния с битом D (Delete) =1, должен инициировать процедуру аннулирования, описанную в предыдущем разделе. Другие биты должны передаваться в исходящем сообщении Path обычным образом.
Если LSR сталкивается с ситуацией, требующей от него уведомления партнера об ошибке или передачи ему рекомендаций, он посылает партнеру сообщение уведомления, содержащее TLV статуса, куда заносится информация и опционные дополнительные TLV, которые предоставляют дополнительные данные о ситуации.
Если условие соответствует одной из фатальных ошибок, статусный код в сообщении будет указывать на это. В этом случае после посылки сообщения уведомления LSR должен завершить LDP-сессию путем закрытия TCP-соединения и отбросить все ассоциации метка-FEC, полученные в ходе этой сессии.
Процедуры сообщения запроса ликвидации метки (Label Abort)
LSR Ru может послать сообщение запроса ликвидации метки, чтобы аннулировать определенный запрос метки для FEC, посланный в LSR Rd, при следующих обстоятельствах:
Следующий шаг Ru для FEC изменился с LSR Rd на LSR X; или
Ru не поддерживает объединение, не является входным LSR и получил запрос ликвидации метки для FEC со стороны вышестоящего партнера Y.
Ru поддерживает объединение, не является входным LSR и получил запрос ликвидации метки для FEC со стороны вышестоящего партнера Y, а Y является единственным (последним) вышестоящим LSR, запрашивающим метку для данного FEC .
Могут быть другие ситуации, где LSR решит аннулировать определенный запрос метки, для того чтобы вернуть ресурсы, ассоциированные с LSP. Однако спецификация общей стратегии механизма ликвидации находится за пределами описания LDP.
Когда LSR получает сообщение запроса ликвидации метки, если он до этого не откликался на ликвидируемый запрос метки или какое-то другое сообщение уведомления, он должен подтвердить ликвидацию откликом Label Request Aborted (запрос метки ликвидирован). Уведомление должно включать TLV ID сообщения запроса метки, который несет ID ликвидированного сообщения запроса метки.
Если LSR получает сообщение запроса ликвидации метки после того, как он отреагировал на запрос метки сообщением присвоения или уведомления, он игнорирует запрос ликвидации.
Если LSR получает сообщение присвоения метки в ответ на сообщение запроса метки, после того как он послал сообщение запроса ликвидации метки, метка в сообщении присвоения (Label Mapping) корректна. LSR может решить использовать метку или освободить ее посредством сообщения Label Release.
LSR, ликвидирующий запрос метки может не использовать повторно ID сообщения для запроса метки до тех пор, пока он не получит от своего партнера:
Сообщения уведомления о выполнении ликвидации запроса метки, являющегося подтверждением ликвидации;
Сообщения присвоения метки в качестве отклика на аннулированное сообщение запроса;
Сообщения уведомления в ответ на аннулированное запроса метки (напр., зарегистрирована петля, нет ресурсов для метки, и т.д.).
Чтобы защитить себя от медлительных или неисправных партнеров, реализации LSR могут ввести таймауты для времени ожидания отклика. Время таймаута должно быть относительно большим (несколько минут). Если время таймаута истекает, а отклика от партнера не получено, LSR может повторно использовать Id сообщения запроса метки. Если он так делает, он должен также аннулировать любую запись сообщений запроса и ликвидации метки.
Заметим, что отклик на запрос ликвидации метки никогда не является "упорядоченным". То есть, отклик не зависит от состояния ниже по течению LSP. LSR, получающий сообщение запроса ликвидации метки, должен обработать его немедленно, несмотря на состояние LSP ниже по течению, реагируя на уведомление ликвидации запроса метки или игнорируя его.
Процедуры сообщения запроса метки
Сообщение запроса используется вышестоящим LSR, чтобы в явном виде получить данные о том, какую метку присвоил и анонсировал нижестоящий LSR для заданного FEC. LSR может передать сообщение запроса при реализации одного из следующих условий:
LSR из маршрутной таблицы узнает новый FEC, узлом следующего шага является партнер LDP, а LSR не имеет метки для заданного FEC.
Следующий шаг для FEC изменился, и LSR в сложившихся условиях не имеет метки для данного FEC.
Заметим, что если LSR уже имеет ожидающее сообщение запроса для нового следующего шага, он не должен выдавать дополнительный запрос метки.
LSR получает запрос метки для FEC от вышестоящего партнера, следующим шагом для FEC является партнер LDP и LSR не имеет метки для следующего шага.
Заметим, что LSR, не поддерживающий объединение, должен сформировать отдельный LSP для каждого вышестоящего партнера, запрашивающего метку. Следствием этого является то, что LSR, не поддерживающий объединение, может иметь много сообщений запроса меток для заданного FEC, выставляемых в одно и то же время.
LSR-получатель должен реагировать на запрос метки сообщением присвоения метки (Label Mapping) или сообщением уведомления, объясняющим, почему он не может удовлетворить запрос.
Когда FEC, для которого запрошена метка, является префиксным FEC-элементом или FEC-элементом адреса ЭВМ, LSR-приемник использует свою маршрутную таблицу, чтобы определить отклик. Если его маршрутная таблица не содержит ни одного рекорда, в точности соответствующего запрошенному префиксу или адресу ЭВМ, LSR должен реагировать сообщением уведомления об отсутствии маршрута (No Route). ID сообщения запроса метки служит идентификатором для транзакции запроса метки. Когда LSR-получатель откликается присвоением метки (Label Mapping ), сообщение должно включать опционный параметр TLV ID сообщения запроса/отклика, который содержит ID сообщения запроса метки. Заметим, что, так как LSR используют ID запроса метки в качестве идентификаторов транзакции, LSR не должен повторно использовать ID запроса метки до завершения соответствующей транзакции.
Эта версия протокола определяет следующие статусные коды для сообщений уведомления, которые сигнализируют о невозможности реализовать запрос:
Нет маршрута
FEC, для которого запрошена метка, включает элемент FEC, для которого LSR не имеет маршрута.
Нет ресурсов меток
LSR не может сформировать метку, из-за ограниченности ресурсов. Когда ресурсов становится достаточно, LSR должен проинформировать запрашивающий LSR, послав ему уведомление со статусным кодом “Label Resources Available” (ресурсы для метки имеются). LSR, который получает отклик “No Label Resources” (ресурсов для метки нет), не должен отправлять запрос метки до тех пор, пока не получит сообщение уведомления со статусным кодом “Label Resources Available”.
Детектирование петель
LSR детектировал зацикливание сообщения запроса метки.
Подробности смотри в приложении A "Процедуры рассылки меток LDP ".
Процедуры вектора пути
TLV вектора пути содержат в себе сообщения присвоения и запроса метки, когда предусматривается детектирование петель.
Прочие метки
Базовые метки MPLS и Frame Relay кодируются с выравниванием по правому полю в 32 бита (4 октета). Метки ATM кодируются посредством VPI, выровненными по правому полю в битах 0-15, а VCI выравниваются по правому полю в битах 16-31.
Программа Sendmail
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Одной из досадных особенностей программы Sendmail является огромное количество опций. К счастью большинство из них обычно не используются. Иной раз может показаться, что назначение некоторых опций знает только их автор. Часть этих опций служит для тестирования конфигурационного файла и файла псевдонимов. Такие опции как -bt и -bv используются при изменении конфигурационного файла, чтобы гарантировать, что новые наборы правил работают безошибочно. Наиболее важные опции служат администратору для установления отладочного уровня (-d#), или для установки программы в фоновый режим или режим демона (-bd), или для установки самого отладочного режима (-v).
Почтовая программа sendmail должна запускаться в фоновом режиме с помощью строки в стартовом скрипте. Например:
/usr/lib/sendmail -bd -q30m
Эта командная строка предлагает обрабатывать занесенные в очередь сообщения каждые 30 минут. Время после опции -q может быть задана как произвольная комбинация дней, часов, минут и секунд. В этом случае за числами должны следовать соответственно символы d, h, m или s. Так, например, запись: -q1d2h30m15s указывает, что очередь будет обрабатываться с периодичностью 1 день, 2 часа, 30 минут и 15 секунд.
Конфигурационный файл sendmail является читаемым текстовым. Этот файл начинается с перечня опций и макросов, далее следует набор правил. Эти правила определяют метод дешифровки адресов почтовых сообщений. Обычно настройке подвергаются опции и макросы.
Макросы начинаются с символа D, за которым следует одна буква, определяющая имя макро, и текст расширения. Буква-имя чувствительна к регистру в котором она напечатана. Макросы используются для определения имен (имя ЭВМ, имя домена и т.д.). Практически все опции, доступные при запуске программы sendmail, могут быть описаны и в конфигурационном файле (буквенные имена совпадают).
Описание опции начинается с символа О. В остальном справедливы замечания, представленные в предыдущем абзаце о макро.
Прежде чем изменять конфигурационный файл рекомендуется сделать его копию. Усовершенствования не всегда работают так, как ожидает их автор.
Опция OL# определяет уровень работы журнала операций. Эта опция управляет объемом информации, которая записывается в log-файл при работе программы sendmail. Чем больше число, проставленное вместо символа #, тем больше информации будет записано. Наибольшему уровню соответствует цифра 9.
Опция Om служит для расширения псевдонимов. Если пользователь посылает сообщение адресату, обозначенному псевдонимом, и имя отправителя присутствует в списке псевдонимов, действием по умолчанию будет блокировка посылки самому себе. Опция Om переписывает значение по умолчанию и отправитель также получит свое сообщение. Некоторые пользователи используют такую возможность для контроля того, что сообщение было действительно послано.
Опции Or<время> и OT<время> являются опциями таймаута. Опция ОТ производит запись проблемного сообщения в очередь и осуществляет повторную попытку через специфицированный промежуток времени, прежде чем отправитель будет проинформирован о неудаче. Опция Or специфицирует значение таймаута для операций чтения. Если при получении почты от удаленной ЭВМ возникает пауза, в течение которой не приходит ничего, sendmail по истечение заданного времени прерывает процесс и закрывает соединение. Так как эта опция, вообще говоря, нарушает стандарт RFC-821, значение таймаута должно быть достаточно велико.
Опция OW специфицирует пароль для операций процессора. По существу это лазейка для выполнения пользователем некоторых операций, которые непосредственно для почтовой программы не нужны. Эта опция используется программистами для выявления проблем в работе основной программы, реализующей почтовый протокол.
Сразу после инсталляции следует поменять значение этого пароля (заменить значение, установленное по умолчанию). Удаление строки соответствующей данной опции, автоматически приведет к установлению пароля по умолчанию.
Опция -о или Оо означает, что имена получателей могут разделяться пробелами (стандарт требует применения запятых).
Опция OD служит, для того чтобы автоматически осуществлять актуализацию базы данных при изменении файла псевдонимов (alias).
Привилегированные пользователи могут изменить имя поля From, которое используется при посылке сообщений об ошибках. Это имя может быть изменено с помощью команды –f<пользователь>.
Файл alias обычно размещается в каталоге /usr/lib/aliases и служит для создания почтовых ящиков, которым не соответствует никакой аккоунт пользователя. В этом файле определяется, в какой почтовый ящик следует направлять сообщение, адресованное субъекту с указанным псевдонимом. Допускается направление сообщений вместо какого-либо почтового ящика на stdin. Стандартная строка переадресации в этом файле выглядит как.
alias: имя_пользователя или
alias: имя_пользователя_1, имя_пользователя_2, имя_пользователя_3, …
Первая строка перенаправляет все сообщения, адресованные alias пользователю с указанным именем. Второй пример соответствует случаю, когда все сообщения, адресованные alias переадресовываются всем пользователям из предлагаемого списка. Этот список может быть продолжен на следующей строке, если пред CR ввести символ \. В качестве имен пользователей могут быть записаны полные почтовые адреса типа или локальное имя. Для особо длинных списков имен можно указать файл, где этот список содержится. Для этого в файл /usr/lib/aliases нужно занести стоку типа.
Participants: “:include:/usr/local/lib/participants.list”
Обычно желательно включать псевдоним “почтмейстера” и администратора. Когда пользователь на удаленной ЭВМ не может найти имя аккоунта или ЭВМ, он может послать запрос по одному из этих псевдонимов.
Одной из наиболее эффективных (и опасных в то же самое время) особенностей файла alias является возможность перенаправлять приходящую почту программе, базирующейся на псевдониме. Когда первый символ имени аккоунта в псевдониме является вертикальной чертой (|), имя воспринимается как наименование программы, которой следует передать управление. Приходящее сообщение будет передано этой программе, как если бы этот текст был введен с консоли. В файле псевдонимов вертикальная черта работает также как в ядре UNIX. Таким образом, строка:
listserv: “|/usr/local/bin/listserv –l”
пошлет почтовый файл программе listserv, как если бы вы выполнили команду cat mailfile|listserv –l. В действительности так работают серверы подписных листов (LISTSERV). Администратор устанавливает псевдоним, а программа listserv транслирует строку поля Subject или тела сообщения в качестве команды, управляющей работой почтового сервера рассылки. Следует иметь в виду, что эта техника представляет достаточно серьезную угрозу безопасности. По этой причине ее использование должно быть обставлено соответствующими мерами (например, аутентификацией с использованием шифрованных паролей).
Пространства меток, идентификаторы, сессии и транспорт 2.2.Пространства меток
Выражение "пространство меток" полезно для обсуждения присвоения и рассылки меток:
Пространство меток интерфейса. Входные метки, специфичные для интерфейса, применяются для интерфейсов, которые используют для меток ресурсы интерфейса. Примером такого интерфейса является АТМ-интерфейс, который использует в качестве меток VCI, или интерфейс Frame Relay, который использует в качестве меток DLCI.
Заметим, что использование пространства меток интерфейса имеет смысл только, когда партнеры LDP связаны непосредственно через интерфейс, и метку предполагается использовать для трафика, следующего через этот интерфейс.
Пространство меток платформы. Входные метки, ориентированные на платформу, используются для интерфейсов, которые совместно используют одни и те же метки.
Пространство имен экспериментальных ID
Диапазон экспериментальных Id 0x00000000 - 0xffffffff. Экспериментальные Id в диапазоне 0x00000000 - 0xefffffff выделяются по принципу первым пришел - первым обслужен, а экспериментальные Id в диапазоне 0xf0000000 - 0xffffffff зарезервированы для частного использования.
Пространство имен статусных кодов
Диапазон статусных кодов 0x00000000 - 0x3FFFFFFF. Статусные коды в диапазоне 0x00000000 - 0x1FFFFFFF выделяются в результате консенсуса IETF, коды в диапазоне 0x20000000 - 0x3EFFFFFF выделяются по принципу первым пришел - первым облужен, и коды в диапазоне 0x3F000000 - 0x3FFFFFFF зарезервированы для частного использования.
Пространство имен типа FEC
Диапазон типов FEC 0 - 255. Типы FEC в диапазоне 0 - 127 выделяются в результате консенсуса IETF, типы в диапазоне 128 - 191 выделяются по принципу первым пришел - первым обслужен, а типы в диапазоне 192 - 255 зарезервированы для частных применений.
Пространство имен типа сообщения
LDP делит пространство имен для типов сообщений на три диапазона. Далее предлагаются соображения по распоряжению этими диапазонами:
Типы сообщений 0x0000 - 0x3DFF. Типы сообщений в этом диапазоне являются частью базового протокола LDP. Типы сообщений в этом диапазоне выделяются в результате консенсуса IETF.
Типы сообщений 0x3E00 - 0x3EFF. Типы сообщений в этом диапазоне зарезервированы для частных расширений производителя и являются областью ответственности отдельных производителей (смотри раздел "Частные сообщения производителя LDP"). IANA не вмешивается в распределение пространства типов сообщений в этом диапазоне.
Типы сообщений 0x3F00 - 0x3FFF. Типы сообщений в этом диапазоне зарезервированы для экспериментальных расширений и являются областью ответственности отдельных экспериментаторов (смотри разделы "Экспериментальные расширения LDP" и "Пространство имен экспериментальных ID "). IANA не вмешивается в распределение пространства типов сообщений в этом диапазоне; однако, IANA ответственна за распоряжение частью пространства экспериментальных ID (смотри ниже).
Пространство имен типа TLV
LDP делит пространство имен для типов TLV на три диапазона. Далее предлагаются соображения по распоряжению этими диапазонами:
Типы TLV 0x0000 - 0x3DFF. Типы TLV в этом диапазоне являются частью базового протокола LDP. Типы TLV в этом диапазоне выделяются в результате консенсуса IETF.
Типы TLV 0x3E00 - 0x3EFF. Типы TLV в этом диапазоне зарезервированы для расширений производителей и являются областью ответственности отдельных производителей (смотри раздел "Частные TLV производителей"). IANA не вмешивается в распределение пространства типов TLV в этом диапазоне.
Типы TLV 0x3F00 - 0x3FFF. Типы TLV в этом диапазоне зарезервированы для экспериментальных расширений и являются областью ответственности отдельных экспериментаторов (смотри разделы "Экспериментальные расширения LDP" и "Пространство имен экспериментальных ID"). IANA не вмешивается в распределение пространства TLV в этом диапазоне; однако, IANA ответственна за распоряжение частью пространства экспериментальных ID пространства имен (смотри ниже).
Протокол
2.1. Общий заголовок
Далее рассматриваются форматы сообщений и объекты, которыми обмениваются PEP и удаленный PDP. Каждое сообщение COPS состоит из заголовка, за которым следует некоторое число типизованных объектов.
| 0 | 1 | 2 | 3 | |
| Версия | Флаги | Код операции | Тип клиента | |
| Длина сообщения | ||||
//// далее обозначает зарезервированное поле и должно содержать 0.
В заголовке имеются поля:
| Версия: 4 бита | Номер версии COPS. Текущее значение версии 1. |
| Флаги: 4 бита | Определенные значения флага (все другие флаги должны быть установлены в нулевое состояние): 0x1 Solicited Message Flag Bit. Этот флаг устанавливается, когда поступает запрос COPS. Этот флаг не должен устанавливаться (значение=0), если только не специфицировано обратное в разделе 3 |
Ниже в таблице представлены значения поля код операции.
| Код операции (8 бит) | Функция | Название операции |
| 1 | Запрос | REQ |
| 2 | Решение | DEC |
| 3 | Отчет о состоянии | RPT |
| 4 | Стереть состояние запроса | DRQ |
| 5 | Синхронизовать состояние запроса> | SSQ |
| 6 | Client-Open | OPN |
| 7 | Client-Accept | CAT |
| 8 | Client-Close | CC |
| 9 | Keep-Alive | KA |
| 10 | Завершить синхронизацию | SSC |
Поле Тип клиента: 16 бит
Тип клиента идентифицирует клиента политики. Интерпретация всех инкапсулированных объектов Типы клиента, которые устанавливают старший бит в поле тип клиента, зависят от производителя (enterprise specific; это типы клиентов 0x8000 - 0xFFFF). Для сообщений KA тип клиента в заголовке должен быть установлен равным 0, так как KA используется для проверки связи.
Длина сообщения: 32 бит
Размер сообщения в октетах, который включает в себя стандартный заголовок COPS и все инкапсулированные объекты. Сообщения должны иметь длину кратную 4 октетам.
Протокол COPS (Common Open Policy Service)
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Протокол COPS предназначен для обмена информации о политике между серверами политики (Policy Decision Point или PDP) и их клиентами (Policy Enforcement Points или PEP). Примером клиента политики является RSVP-маршрутизатор, который должен реализовывать управление доступом, базирующееся на определенной политике [RSVP]. Мы предполагаем, что существует, по крайней мере, один сервер, определяющий политику в каждом из доменов. Базовая модель взаимодействия между сервером политики и клиентом совместима с документом по управлению доступом [WRK]. Характеристики протокола COPS содержат следующие моменты (RFC-2748):
| 1. | Протокол использует модель клиент-сервер, где PEP посылает запросы, осуществляет актуализацию данных, отправляет сообщения о ликвидации удаленным PDP, а PDP возвращает отклики-решения узлам PEP. |
| 2. | Протокол использует TCP для надежного обмена сообщениями между клиентами и сервером. Следовательно, не нужно никакого дополнительного механизма для обеспечения надежного взаимодействия между сервером и клиентами. |
| 3. |
Протокол является расширяемым и может работать с любой специфической информацией клиентов без модификации самого протокола COPS. Протокол был создан для общего администрирования, конфигурации и реализации политики.
Протокол динамического конфигурирования ЭВМ DHCP
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Протокол динамической конфигурации ЭВМ DHCP (Dynamic Host Configuration Protocol, RFC-2131, -2132, -2485, -2563, -2610, -2855, -2937, -2939, -3004, -3011, -3046; [22], [23], [24] и [25]) служит для предоставления конфигурационных параметров ЭВМ, подключенных к Интернет. DHCP имеет два компонента: протокол предоставления специфических для ЭВМ конфигурационных параметров со стороны DHCP-сервера и механизм предоставления ЭВМ сетевых адресов.
Протокол DHCP используется, помимо загрузки бездисковых станций или Х-терминалов (BOOTP), сервис-провайдерами для пулов модемов, когда число одновременно занятых модемов существенно меньше их полного числа. Это позволяет сэкономить заметное число IP-адресов. Протокол эффективен для случая распределения адресов за Firewall, где ЭВМ в защищенной зоне все равно бессмысленно выделять реальные IP-адреса.
DHCP построен по схеме клиент-сервер, где DHCP-сервер выделяет сетевые адреса и доставляет конфигурационные параметры динамически конфигурируемым ЭВМ.
ЭВМ не должна действовать как DHCP-сервер, если только она специально не сконфигурирована системным администратором. IP-протокол требует установки многих параметров. Так как IP-протокол может быть использован самым разным сетевым оборудованием, значения этих параметров не могут быть угаданы заранее. Кроме того, схема распределенного присвоения адресов зависит от механизма выявления уже используемых адресов. ЭВМ могут не всегда корректно зарезервировать свои сетевые адреса, таким образом, схема распределенного выделения адресов не может гарантировать уникальности сетевых адресов.
DHCP поддерживает три механизма выделения IP-адресов. При "автоматическом выделении", DHCP присваивает клиенту постоянный IP-адрес. При "динамическом присвоении", DHCP присваивает клиенту IP-адрес на ограниченное время. При "ручном выделении", IP-адрес выделяется клиенту сетевым администратором, а DHCP используется просто для передачи адреса клиенту. Конкретная сеть использует один или более этих механизмов, в зависимости от политики сетевого администратора.
Динамическое присвоение адресов представляет собой единственный механизм, который позволяет автоматически повторно использовать адрес, который не нужен клиенту. Таким образом, динамическое присвоение адресов является оптимальной схемой для клиентов, подключаемых к сети временно, или совместно использующих один и тот же набор IP-адресов и не нуждающихся в постоянных адресах.
Формат сообщений DHCP базируется на формате сообщений BOOTP, чтобы можно было воспользоваться процедурами транспортировки данных, описанными в спецификации BOOTP [7, 21] и обеспечить совместимость DHCP-серверов с существующими клиентами BOOTP. Использование агентов транспортировки BOOTP исключает необходимость наличия DHCP-серверов в каждом физическом сегменте сети.
Протокол резервирования ресурсов RSVP
Если сетевые условия позволяют, то, используя протокол RSVP (где QoS задается в спецификации потока (flowspec) - практически на сегодня это единственное реализуемое решение), можно попытаться зарезервировать для заданной виртуальной сети определенное значение полосы пропускания. Следует иметь в виду, что протокол RSVP приспособлен в основном для резервирования определенного значения полосы пропускания, а не произвольного QoS (спецификации QoS см. в RFC-2210, 2211 и 2212) для существующего виртуального соединения. Если виртуальное соединение разорвано, следом ликвидируются и все резервирования. Следует, разумеется, иметь в виду, что >RSVP может работать как c TCP- так и c UDP-сессиями поверх IPv4 и IPv6. Сессия резервирования инициируется получателем данных. Резервирование может осуществляться как для уникаст, так и мультикаст-потоков. Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin «Resource ReSerVation Protocol», RFC-2205; смотри также RFC-2206-10, -2490, -2745-47, -2750-52, -2872, -2961, -2996, -3097, -3175, -3181, -3209-10) определяет режим резервирования (способ объединения нескольких заявок для одного и того же интерфейса: WF, FF, SE), формирования резервирования и его поддержания в условиях отсутствия поддержки данного протокола в одном или нескольких узлах виртуального пути, пересылки QoS-запросов другим маршрутизаторам и т.д., но решения принимаются маршрутизатором локально без знания условий в остальной части пути. По этой причине здесь не может идти речь о минимизации задержки, обеспечении надежности или безопасности, хотя в перспективе это может стать возможным.
Следует учитывать, что инициатором резервирования в RSVP всегда является клиент (именно он посылает первичные запросы). По этой причине могут возникнуть проблемы при попытке централизованного управления QoS посредством RSVP.
RSVP не имеет механизмов управления очередями в конкретных интерфейсах, а механизм резервирования полосы пропускания для одного из направлений обмена является зоной ответственности изготовителя маршрутизатора и не публикуется. Кроме того, при скоростях несколько сот Мбит/с часто обработка процедур буферизации перепоручается аппаратным средствам (например, в случае компании CISCO).
· RSVP выполняет резервирование для уникастных и мультикастных приложений, динамически адаптируясь к изменениям членства в группе вдоль маршрута.
· RSVP является симплексным протоколом, т.е., он выполняет резервирование для однонаправленного потока данных.
· RSVP ориентирован на получателя, т.е., получатель данных инициирует и поддерживает резервирование ресурсов для потока.
· RSVP поддерживает динамическое членство в группе и автоматически адаптируется к изменениям маршрутов.
· RSVP не является маршрутным протоколом, но зависит от существующих и будущих маршрутных протоколов.
· RSVP транспортирует и поддерживает параметры управления трафиком и политикой, которые остаются непрозрачными для RSVP.
· RSVP обеспечивает несколько моделей резервирования или стилей, для того чтобы удовлетворить требованиям различных приложений.
· RSVP обеспечивает прозрачность операций для маршрутизаторов, которые его не поддерживают.
· RSVP может работать с IPv4 и IPv6.
Подобно приложениям маршрутизации и протоколам управления, программы RSVP исполняется в фоновом режиме.
Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров:
1. "Rspec", который определяет желательное значение QoS, и
2. "Tspec", который описывает информационный поток.
Форматы и содержимое Tspecs и Rspecs определяются общими моделями обслуживания [RFC 2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может использоваться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP).
Так как номера портов UDP/TCP используются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Это вызывает потенциально три проблемы.
1. Необходимо избегать IP-фрагментации потока данных, для которого желательно резервирование ресурсов. Документ [RFC 2210] специфицирует процедуру вычисления минимального MTU для приложений, использующих средства RSVP.
2. IPv6 вводит переменное число Internet заголовков переменной длины перед транспортным заголовком, увеличивая трудность и стоимость классификации пакетов. Эффективная классификация информационных пакетов IPv6 может быть достигнута путем использования поля метки потока заголовка IPv6.
3. IP-уровень безопасности как для IPv4, так и IPv6 может шифровать весь транспортный заголовок, скрывая номера портов промежуточных маршрутизаторов.
Сообщения RSVP, несущие запросы резервирования, исходят со стороны получателя и направляются отправителю информации.
Процесс RSVP проходит стадии проверки допуска и политики. Если какой-либо тест не прошел, резервирование отвергается и посылается сообщение об ошибке. Если все тесты прошли успешно, узел устанавливает классификатор пакетов, для того чтобы отбирать пакеты, указанные в спецификации фильтра. Далее устанавливается контакт с соответствующим канальным уровнем для получения желательного QoS, заданного в flowspec. Для простой выделенной линии, желаемый QoS будет получен с помощью диспетчера пакетов в драйвере канального уровня. Если технология канального уровня поддерживает свои средства управления QoS, тогда RSVP должен согласовать с канальным уровнем получение требуемого QoS.
Когда получатель данных отправляет запрос резервирования, он может запросить также присылку сообщения, подтверждающего резервирование. Процесс резервирования распространяется от получателей к отправителям, от узла к узлу. В каждом узле требования резервирования объединяются и сопоставляются с имеющимися возможностями. Это продолжается до тех пор, пока запрос не достигнет отправителя или пока не возникнет конфликт перегрузки. В результате получатель данных, направивший запрос резервирования, получит сообщение об успехе или ошибке.
Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP, посланные вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.
Запрос резервирования включает в себя набор опций, которые в совокупности называются стилем. Одна опция резервирования определяет способ резервирования различными отправителями в пределах одной сессии.
Другая опция резервирования контролирует выбор отправителей. В одних случаях каждому отправителю ставится в соответствие определенная спецификация фильтра, в других - таких спецификаций не требуется вовсе. В настоящее время определены следующие стили:
· Стиль WF (Wildcard-Filter)
Стиль WF использует опции: "разделенного" резервирования и произвольного выбора отправителя ("wildcard"). Таким образом, резервация со стилем WF создает резервирование, которое делится между потоками всех отправителей. Это резервирование может рассматриваться как общая «труба", чей размер равен наибольшему из ресурсных запросов от получателей, и не зависит от числа отправителей. Стиль резервирования WF передается в направлении отправителей и автоматически распространяется на новых отправителей при их появлении.
· Стиль FF (Fixed-Filter)
Стиль FF использует опции: "четкое" (distinct) резервирование и "явный" (explicit) выбор отправителя. Таким образом, простой запрос со стилем FF создает точно заданное резервирование для информационных пакетов от определенного отправителя, без совместного использования ресурса с другими отправителями в пределах одной и той же сессии.
· Стиль SE (Shared Explicit)
Стиль SE использует опции: "разделенное" (shared) резервирование и "явный" explicit) выбор отправителя. Таким образом, стиль резервирования SE формирует одно резервирование, которое совместно используется несколькими отправителями. В отличие от стиля WF, SE позволяет получателю непосредственно специфицировать набор отправителей.
Для облегчения работы с RSVP разработан протокол COPS (Common Open Policy Service; RFC-2748, The COPS Protocol, D. Durham, Ed. Смотри также RFC-2749, -2940 и -3084).
Протокол COPS предназначен для обмена информации о политике между серверами политики (Policy Decision Point или PDP и их клиентами (Policy Enforcement Points или PEP). Примером клиента политики является RSVP-маршрутизатор, который должен реализовывать управление доступом, базирующееся на определенной политике. Предполагается, что существует, по крайней мере, один сервер, определяющий политику в каждом из доменов. Базовая модель взаимодействия между сервером политики и клиентом совместима с документом по управлению доступом [27-28]. Смотри также
В конфигурационном сценарии PEP выполнит запрос PDP для определенного интерфейса, модуля, или функциональности, которые могут быть специфицированы в информационном объекте именованного клиента. PDP пошлет потенциально несколько решений, содержащих именованные блоки конфигурационных данных PEP. Предполагается, что PEP инсталлирует и использует конфигурацию локально. Конкретная именованная конфигурация может быть актуализована путем отправки дополнительных сообщений-решений для данной конфигурации. Когда PDP более не хочет, чтобы PEP использовал часть конфигурационной информации, он пошлет сообщение-решение, специфицирующее именованную конфигурацию и объект флагов решения (decision flags) с командой удаления конфигурации. PEP должен удалить соответствующую конфигурацию и послать сообщение-отчет PDP, об этом удалении.
При работе с АТМ ситуация ненамного лучше, программное обеспечение АТМ-коммутаторов также обычно не доступно. Но имеется возможность работы RSVP поверх АТМ [29-31].
Рассматривается внедрение протокола RSVP на уровень L2 [34].
При наличии механизмов реализации других типов QoS (смотри, например, RFC-2430 [21] и Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", где предлагается ввести дополнительные биты в заголовок), можно решить проблему в более общем виде (но эта технология находится лишь на стадии обсуждения и не внедрена ни на одном серийном приборе). В рамках одной автономной системы (AS), где используется внутренний протокол маршрутизации OSPF>, можно обеспечить требуемый уровень QoS, но это будет делаться вручную, во всяком случае, на уровне задания значений метрики. Теоретически можно это сделать и автоматически, например, в случае применения версии протокола IGRP (внутренний протокол компании CISCO), поддерживающего автоматическую оценку значений метрики. К сожалению, компания CISCO отошла от первоначального плана и значения метрики там задается в настоящее время также администратором.
Реализация управления QoS предполагает организацию эффективной системы мониторинга базовых параметров, характеризующих требуемый уровень QoS. Для этого требуется контролировать уровень информационных потоков во всех фрагментах VPN, постоянно измерять значение RTT и его дисперсии, контролировать уровень вероятности потери пакетов во всех фрагментах виртуального пути. Желательно также отслеживать корреляции перечисленных параметров и локального значения загрузки. Схема мониторинга и управления QoS показана на рис. 6.
Рис. 6.
Управляющее воздействие может осуществляться с помощью скриптов или с привлечением механизмов политик. В любом случае нужно позаботиться об исключении влияния случайных флуктуаций результатов измерений.
Протоколы рассылки меток
Протокол рассылки меток представляет собой набор процедур, с помощью которых один LSR информирует другие об ассоциациях метка/FEC, которые он сформировал. Два LSR, которые используют протокол рассылки меток для обмена данными об ассоциациях метка/FEC, называются "партнерами рассылки меток". Если два LSR являются партнерами по рассылки меток, мы будем говорить о смежности рассылки меток между ними.
Протокол рассылки меток включает в себя также любые согласования, при которых партнеры изучают MPLS возможности друг друга.
Архитектура не предполагает, что должен существовать только один протокол рассылки меток. В действительности, стандартизовано несколько протоколов рассылки меток. Существующие протоколы расширены так, чтобы рассылка меток можно было совместить друг с другом (смотри, например, [MPLS-BGP], [MPLS-RSVP-TUNNELS]). Определены новые протоколы специально для целей рассылки меток (смотри, например, [MPLS-LDP], [MPLS-CR-LDP]).
В данном документе, мы пытаемся использовать акроним "LDP" для ссылок на протокол, определенный в [MPLS-DP].
QoS/CoS 8.DiffServ
Концепция дифференцированных услуг может быть применена и к мультикастингу. Это приводит к более тонкой гранулированности потоков (DSCP в качестве дополнительного средства разделения потоков). Отправитель может сформировать одно или более деревьев с разными DSCP.
Эти деревья (S,G, DSCP) или (*, G, DSCP) могут быть легко спроектированы на LSP, если используется механизм формирования пути, запускаемый трафиком. В этом случае можно сформировать LSP с разными атрибутами для разных DSCP. Заметим, однако, что эти LSP используют тот же маршрут, так как механизм формирования дерева не использовал значения DSCP.
Работа LSP-туннелей
В данном разделе обобщаются некоторые возможности, поддерживаемые RSVP-ТЕ при работе с LSP туннелями. Сюда входит:
Возможность формирования LSP-туннелей с или без требований QoS. Возможность динамически изменять маршруты сформированных LSP туннелей. Возможность отслеживать действительный маршрут, проходящий через сформированный LSP туннель, Возможность идентифицировать и диагностировать LSP туннели. Возможность устанавливать сформированный LSP туннель под административный контроль и Возможность осуществлять посылку запросов выделения меток, их рассылку и объединение.
Чтобы сформировать LSP туннель, первый узел MPLS - то есть, узел-отправитель -- посылает сообщение RSVP Path с типом сессии LSP_TUNNEL_IPv4 или LSP_TUNNEL_IPv6 и вводит объект LABEL_REQUEST в сообщение Path. Объект LABEL_REQUEST указывает, что запрошена привязка метки к данному пути, а также указывает на протокол сетевого уровня, который используется для этого маршрута. Причиной этого является то, что нельзя сделать предположение о протоколе сетевого уровня, используемом в LSP, это не обязательно IP и нельзя это выяснить по заголовку уровня L2, который просто указывает на вышестоящий протокол - MPLS.
Если узел-отправитель знает, что маршрут с высокой вероятностью отвечает требованиям QoS туннеля, или что он эффективно использует сетевые ресурсы, или, что он удовлетворяет некоторым критериям политики, узел может решить использовать маршрут для некоторых или для всех его сессий. Чтобы сделать это, узел-отправитель добавляет объект EXPLICIT_ROUTE в сообщение RSVP Path. Объект EXPLICIT_ROUTE специфицирует маршрут в виде последовательности абстрактных узлов.
Если после того как сессия успешно установлена, узел-отправитель обнаружит лучший путь, отправитель может динамически изменить маршрут сессии простой заменой объекта EXPLICIT_ROUTE. Если возникли проблемы с объектом EXPLICIT_ROUTE, из-за циклов маршрута или из-за того, что некоторые промежуточные маршрутизаторы его не поддерживают, отправитель об этом уведомляется.
Добавив объект RECORD_ROUTE в сообщение Path, узел-отправитель может получить информацию о действительном маршруте, по которому проходит LSP туннель. Узел-отправитель может также использовать этот объект, чтобы запросить данные об изменении маршрута. Объект RECORD_ROUTE аналогичен вектору пути, и, следовательно, может использоваться для обнаружения циклов маршрута.
Наконец, объект SESSION_ATTRIBUTE может быть добавлен в сообщение Path, чтобы помочь диагностике и идентификации сессии. В этом объекте содержится также информация о конфигурации, приоритетах и ресурсах (смотри [3]).
Маршрутизаторы вдоль маршрута могут использовать конфигурацию и приоритеты совместно с SENDER_TSPEC и любыми объектами POLICY_DATA, содержащимися в сообщениях Path, в качестве входных данных для управления политикой. Например, в приложениях управления трафиком очень полезно использовать сообщение Path в качестве средства проверки того, что имеется полоса при заданном приоритете вдоль всего пути, прежде чем перейти к более низкому уровню приоритета резервирования. Если разрешено распространение сообщения Path при недостаточности ресурсов, тогда имеется опасность того, что резервирования низкого приоритета вниз по течению относительно данной точки будут заменены при бесполезной попытке обслужить этот запрос.
Когда присутствует объект EXPLICIT_ROUTE (ERO), сообщение Path переадресуется по месту назначения вдоль пути, указанного в ERO. Каждый узел вдоль пути записывает ERO в свой блок состояния пути. Узлы могут также модифицировать ERO до переадресации сообщения Path. В этом случае модифицированный ERO должен быть запомнен в блоке состояния пути в дополнение к полученному ERO.
Объект LABEL_REQUEST запрашивает промежуточные маршрутизаторы и узлы-получатели предоставить данные о метке для данной сессии. Если узел не способен предоставить такие данные, он посылает сообщение PathErr с кодом ошибки "unknown object class" (неизвестный класс объекта). Если объект LABEL_REQUEST на всем пути не поддерживается, узел-отправитель будет уведомлен первым узлом, который не может обеспечить такую поддержку.
Узел места назначения пути с коммутацией по меткам реагирует на LABEL_REQUEST путем включения объекта LABEL в свой отклик-сообщение RSVP Resv. Объект LABEL включается в список спецификации отбора, который следует непосредственно за основной спецификацией фильтра.
Сообщение Resv посылается назад вверх по течению в направлении отправителя, следуя состоянию пути, сформированному сообщением Path, в обратном порядке. Заметим, что если состояние пути было сформировано с использованием ERO, тогда в обратном направлении (согласно ERO) последует сообщение Resv.
Каждый узел, который получает сообщение Resv, содержащее объект LABEL, использует эту метку для исходящего трафика в соответствии с этим LSP туннелем. Если узел не является отправителем, он формирует новую метку и помещает ее в соответствующий объект LABEL сообщения Resv, которое посылается вверх по течению к PHOP. Метка, посланная вверх по течению в объекте LABEL, является меткой, которую данный узел будет использовать для идентификации входного трафика, сопряженного с этим LSP туннелем. Эта метка служит также в качестве характеристики спецификации отбора (Filter Spec). Узел может теперь обновить свою карту входных меток ILM (Incoming Label Map), которая используется для определения NHLFE (Next Hop Label Forwarding Entry), смотри [2]. Когда сообщение Resv движется вверх по течению в направлении узла-отправителя, формируется маршрут с коммутацией по меткам.
Работа с ключами
Процедура работы с ключами находится за пределами данного документа, но реализации COPS должны, по крайней мере, предоставить возможность ручной конфигурации ключей и задания их параметров. Ключ, используемый для формирования дайджеста сообщения с объектом Integrity, идентифицируется с помощью поля Key ID. Таким образом, параметр Key ID используется для идентификации одного из множества ключей, используемых совместно PEP и PDP. Key ID имеет отношение к определенному PEPID для PDP, или к определенному PDP для PEP. Для каждого ключа должны быть также определены параметры времени действия и параметры, задающие криптографический алгоритм. Как минимум, все реализации COPS должны поддерживать криптографический алгоритм HMAC-MD5-96 [HMAC][MD5] для вычисления дайджеста сообщения, который включается в объект Integrity (Keyed Message Digest), присоединяемый к сообщению.
Регулярное изменение ключей является хорошей практикой. Ключи должны быть конфигурируемы так, чтобы их время действия перекрывались, обеспечивая плавный переход с одного набора на другой. В середине периода действия ключа отправитель должен запустить процедуру перехода на следующий ключ. Тем временем, получатели просто воспринимают любой идентифицированный ключ, полученный в пределах его периода существования (lifetime) и отклоняют любые другие ключи.
Работа с объектом DIFFSERV
Чтобы сформировать туннель LSP с RSVP, отправитель подготавливает сообщение Path с типом сессии LSP_Tunnel_IPv4 и с объектом LABEL_REQUEST, как и в случае [RSVP_MPLS_TE].
Чтобы сформировать туннель E-LSP с RSVP, который использует предварительно сконфигурированное соответствие EXP<-->PHB, отправитель подготавливает сообщение Path:
с типом сессии LSP_Tunnel_IPv4,
с объектом LABEL_REQUEST и
без объекта DIFFSERV.
Чтобы сформировать туннель E-LSP с RSVP, который использует предварительно сконфигурированную таблицу EXP<-->PHB, отправитель может в качестве альтернативы подготовить сообщение Path : с типом сессии LSP_Tunnel_IPv4,с объектом LABEL_REQUEST и с объектом DIFFSERV для E-LSP, не содержащим записей MAP.
Чтобы сформировать туннель E-LSP с RSVP, который использует согласованное соответствие EXP<-->PHB, отправитель подготавливает сообщение Path:
с типом сессии LSP_Tunnel_IPv4,
с объектом LABEL_REQUEST,
с объектом DIFFSERV для E-LSP, содержащим одну запись MAP для каждого значения EXP, поддерживаемого E-LSP.
Чтобы сформировать туннель L-LSP с RSVP, отправитель подготавливает сообщение Path:
с типом сессии LSP_Tunnel_IPv4,
с объектом LABEL_REQUEST,
с объектом DIFFSERV для L-LSP, содержащего класс обслуживания PHB (PSC), поддерживаемый в этом L-LSP.
Если сообщение path содержит несколько объектов DIFFSERV, только первый имеет значение; последующие объекты DIFFSERV должны игнорироваться и не переадресовываться. Каждый LSR вдоль пути регистрирует объект DIFFSERV, когда он имеется в его блоке состояния пути.
Если в сообщении Path объект DIFFSERV отсутствует, LSR должен интерпретировать это как запрос E-LSP, использующий предварительно сконфигурированную таблицу соответствия EXP<-->PHB. Однако, для целей обратной совместимости с другими опциями QoS без Diff-Serv, допускаемыми [RSVP_MPLS_TE], такими как интегрированные услуги с управляемой загрузкой (Integrated Services Controlled Load) или гарантированные услуги, LSR может поддерживать конфигурируемые опции “пренебрежения” (override). Когда такая опция сконфигурирована, LSR интерпретирует сообщение path без объекта Diff-Serv, как было запрошено для LSP (QoS без Diff-Serv).
Если в сообщении Path присутствует объект DIFFSERV для E-LSP, несодержащего записи MAP, LSR должен интерпретировать это, как запрос E-LSP, использующий предварительно сконфигурированную таблицу соответствия EXP<-->PHB. В частности, это позволяет LSR с опцией “пренебрежения” поддерживать E-LSP c предварительно сконфигурированной таблицей соответствия EXP<-->PHB, и в то же время с LSP с QoS без Diff-Serv.
Если в сообщении Path имеется объект DIFFSERV для E-LSP, содержащего, по крайней мере, одну запись MAP, LSR должен интерпретировать это как запрос E-LSP с согласованным соответствием EXP<-->PHB.
Если в сообщении Path имеется объект DIFFSERV для L-LSP, LSR должен интерпретировать это, как запрос L-LSP.
Адресат LSR E-LSP или L-LSP реагирует на сообщение Path, содержащее объект LABEL_REQUEST, посылкой сообщения Resv :
с объектом LABEL
без объекта DIFFSERV.
Предполагая, что запрос метки принят и метка выделена, Diff-Serv LSR (отправитель, адресат, промежуточные узлы) должны:
актуализовать контекст Diff-Serv, сопряженный с сформированным LSP и их ILM/FTN, как это специфицировано в предыдущих разделах (входная и выходная метка),
инсталлировать необходимую программу переадресации Diff-Serv (формирование трафика и приоритеты отбрасывания) для этого NHLFE (выходная метка).
LSR, который распознает объект DIFFSERV и который получает сообщение path, содержащее объект DIFFSERV, но не имеет объекта LABEL_REQUEST, или тип сессии которого не является LSP_Tunnel_IPv4, посылает отправителю сообщение PathErr с кодом ошибки Diff-Serv Error и значением ошибки Unexpected DIFFSERV object. Эти значения определены ниже в разделе 5.5.
LSR, получающий сообщение Path с объектом DIFFSERV для E-LSP, распознавший его, но не поддерживающий конкретное PHB, закодированное в одном или более записях MAP, посылает отправителю сообщение PathErr с кодом ошибки Diff-Serv Error и значением ошибки Unsupported PHB.
LSR, получающий сообщение Path с объектом DIFFSERV для E-LSP, распознавший его, но определивший, что согласованная таблица EXP<-->PHB некорректна, посылает отправителю сообщение PathErr с кодом ошибки Diff-Serv Error и значением ошибки Invalid EXP<-->PHB mapping. Согласованная таблица соответствия EXP<-->PHB в объекте DIFFSERV для E-LSP некорректна, если:
значение поля MAPnb лежит вне пределов диапазона 0 - 8 или
данное значение EXP присутствует в более чем одной записи MAP, или
кодировка PHBID некорректна.
LSR, получающий сообщение Path с объектом DIFFSERV для L-LSP, распознал DIFFSERV, но не поддерживает конкретный PSC, записанный в поле PSC, посылает отправителю сообщение PathErr с кодом ошибки Diff-Serv Error и значением ошибки Unsupported PSC.
LSR, получающий сообщение Path с объектом DIFFSERV, который распознал объект DIFFSERV, но не может выделить требующийся ресурс для LSP Diff-Serv, посылает отправителю PathErr с кодом ошибки Diff-Serv Error и значением ошибки Per-LSP context allocation failure. LSR должен уметь обрабатывать ситуации, когда запрос метки не может быть воспринят по причине, отличной от уже обсужденных, в соответствии с [RSVP_MPLS_TE]. Например, системой контроля доступа отвергнуто резервирование, метка не может быть присвоена.
Расширение Hello
Расширение RSVP Hello позволяет узлам RSVP детектировать, когда соседний узел недоступен. Механизм предоставляет возможность поузлового детектирования отказа. Когда такой отказ детектирован, он обрабатывается также как и отказ канального уровня. Этот механизм предназначен для использования, когда нет уведомления об отказе канала и не используются ненумерованные каналы, или когда механизмы детектирования отказов, предоставляемые канальным уровнем, недостаточны для своевременного детектирования отказов узлов.
Следует заметить, что регистрация отказа узла не совпадает с механизмом детектирования отказа канала, в частности в случае нескольких параллельных ненумерованных каналов. Расширение Hello специально сконструировано так, что можно использовать или не использовать этот механизм. Детектирование отказа соседа может быть запущено в любое время. Сюда входит ситуация, когда соседи узнают впервые друг о друге, или когда соседи совмеcтно используют состояния Resv или Path.
Расширение Hello состоит из сообщения Hello, объектов HELLO REQUEST и HELLO ACK. Обработка Hello двумя соседями поддерживает независимый выбор обычно конфигурируемых интервалов детектирования отказов. Каждый сосед может автономно формировать объекты HELLO REQUEST. Получение каждого запроса подтверждается. Сообщения Hello содержат также достаточно информации, так что один сосед может подавить посылку запросов Hello и все же выполнить детектирование отказа соседа. Сообщение Hello может быть включено в виде составной части в блочное сообщение.
Детектирование отказа соседа выполняется путем получения и запоминания атрибута соседа. Если зарегистрировано изменение значения, или если сосед некорректно сообщает локально объявленное значение, тогда сосед предполагается отключенным. Когда обнаружено, что атрибут соседа изменился или когда связь с соседом потеряна, тогда значение атрибута говорит об изменении соседа. Объекты HELLO предоставляют механизм посылки запросов и предоставления значения атрибута. Запрос регистрации включает также значение атрибута отправителя. Это позволяет получателю регистрации опционно обрабатывать эти данные, как неявный отклик на регистрацию. Эта опционная обработка является оптимизацией, которая может уменьшить полное число запросов и откликов, обработанных парами соседей. Во всех случаях, когда обе стороны поддерживают оптимизацию, результатом будет только набор запросов и откликов за интервал детектирования отказа. В зависимости от выбранных интервалов, можно получить выигрыш, даже когда только один сосед поддерживает оптимизацию.
Расширение 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 только о классах, которые ему известны, проблемы совместимости возникнуть просто не может.
Прежде чем добавлять новый класс, следует ответить на вопрос, относится ли информация, содержащаяся в объекте, к новому классу.
Ссылки
| [1] | Internet routing registry. procedures. http://www.ra.net/RADB.tools.docs/, http://www.ripe.net/db/doc.html. |
| [2] |
B. Грамматические правила
Ниже рассмотрены формальные грамматические правила RPSL. Основные типы данных определены в разделе 2. Правила записаны с использованием входного языка грамматического разбора GNU Bison.
//**** базовые атрибуты *********************************************
changed_attribute: ATTR_CHANGED TKN_EMAIL TKN_INT
//**** класс aut-num *************************************************
//// as_expression /////////////////////////////////////////////////////
opt_as_expression: | as_expression
as_expression: as_expression OP_OR as_expression_term | as_expression_term
as_expression_term: as_expression_term OP_AND as_expression_factor
| as_expression_term KEYW_EXCEPT as_expression_factor | as_expression_factor
as_expression_factor: '(' as_expression ')' | as_expression_operand
as_expression_operand: TKN_ASNO | TKN_ASNAME
//// router_expression /////////////////////////////////////////////////
opt_router_expression: | router_expression
opt_router_expression_with_at: | KEYW_AT router_expression
router_expression: router_expression OP_OR router_expression_term | router_expression_term
router_expression_term: router_expression_term OP_AND router_expression_factor
| router_expression_term KEYW_EXCEPT router_expression_factor | router_expression_factor
router_expression_factor: '(' router_expression ')' | router_expression_operand
router_expression_operand: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME
//// пиринг ///////////////////////////////////////////////////////////
peering: as_expression opt_router_expression opt_router_expression_with_at
| TKN_PRNGNAME
//// действие ////////////////////////////////////////////////////////////
opt_action: | KEYW_ACTION action
action: single_action | action single_action
single_action: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')' ';'
| TKN_RP_ATTR TKN_OPERATOR list_item ';' | TKN_RP_ATTR '(' generic_list ')' ';'
| TKN_RP_ATTR '[' generic_list ']' ';' | ';'
//// фильтр ////////////////////////////////////////////////////////////
filter: filter OP_OR filter_term | filter filter_term %prec OP_OR | filter_term
filter_term : filter_term OP_AND filter_factor | filter_factor
filter_factor : OP_NOT filter_factor | '(' filter ')' | filter_operand
filter_operand: KEYW_ANY | '<' filter_aspath '>' | filter_rp_attribute | TKN_FLTRNAME
| filter_prefix
filter_prefix: filter_prefix_operand OP_MS | filter_prefix_operand
filter_prefix_operand: TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | TKN_RSNAME
| '{' opt_filter_prefix_list '}'
opt_filter_prefix_list: | filter_prefix_list
filter_prefix_list: filter_prefix_list_prefix | filter_prefix_list ',' filter_prefix_list_prefix
filter_prefix_list_prefix: TKN_PRFXV4 | TKN_PRFXV4RNG
filter_aspath: filter_aspath '|' filter_aspath_term | filter_aspath_term
filter_aspath_term: filter_aspath_term filter_aspath_closure | filter_aspath_closure
filter_aspath_closure: filter_aspath_closure '*' | filter_aspath_closure '?' | filter_aspath_closure '+'
| filter_aspath_factor
filter_aspath_factor: '^' | '$' | '(' filter_aspath ')' | filter_aspath_no
filter_aspath_no: TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | '.' | '[' filter_aspath_range ']'
| '[' '^' filter_aspath_range ']'
filter_aspath_range: | filter_aspath_range TKN_ASNO | filter_aspath_range KEYW_PEERAS
| filter_aspath_range '.' | filter_aspath_range TKN_ASNO '-' TKN_ASNO
| filter_aspath_range TKN_ASNAME
filter_rp_attribute: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')'
| TKN_RP_ATTR TKN_OPERATOR list_item | TKN_RP_ATTR '(' generic_list ')'
| TKN_RP_ATTR '[' generic_list ']'
//// пара пиринг-действий ///////////////////////////////////////////////
import_peering_action_list: KEYW_FROM peering opt_action
| import_peering_action_list KEYW_FROM peering opt_action
export_peering_action_list: KEYW_TO peering opt_action
| export_peering_action_list KEYW_TO peering opt_action
//// фактор import/export //////////////////////////////////////////////
import_factor: import_peering_action_list KEYW_ACCEPT filter
import_factor_list: import_factor ';' | import_factor_list import_factor ';'
export_factor: export_peering_action_list KEYW_ANNOUNCE filter
export_factor_list: export_factor ';' | export_factor_list export_factor ';'
//// термин import/export ////////////////////////////////////////////////
import_term: import_factor ';' | '{' import_factor_list '}'
export_term: export_factor ';' | '{' export_factor_list '}'
//// выражение import/export //////////////////////////////////////////
import_expression: import_term | import_term KEYW_REFINE import_expression
| import_term KEYW_EXCEPT import_expression
export_expression: export_term | export_term KEYW_REFINE export_expression
| export_term KEYW_EXCEPT export_expression
//// протокол ///////////////////////////////////////////////////////////
opt_protocol_from: | KEYW_PROTOCOL tkn_word
opt_protocol_into: | KEYW_INTO tkn_word
//**** атрибуты import/export ****************************************
import_attribute: ATTR_IMPORT
| ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor
export_attribute: ATTR_EXPORT
| ATTR_EXPORT opt_protocol_from opt_protocol_into export_factor
opt_default_filter: | KEYW_NETWORKS filter
default_attribute: ATTR_DEFAULT KEYW_TO peering
filter_attribute: ATTR_FILTER filter
peering_attribute: ATTR_PEERING peering
//**** класс inet-rtr **************************************************
ifaddr_attribute: ATTR_IFADDR TKN_IPV4 KEYW_MASKLEN TKN_INT opt_action
//// атрибут peer ////////////////////////////////////////////////////
opt_peer_options: | peer_options
peer_options: peer_option | peer_options ',' peer_option
peer_option: tkn_word '(' generic_list ')'
peer_id: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME | TKN_PRNGNAME
peer_attribute: ATTR_PEER tkn_word peer_id opt_peer_options
//**** класс route *****************************************************
aggr_bndry_attribute: ATTR_AGGR_BNDRY as_expression
aggr_mtd_attribute: ATTR_AGGR_MTD KEYW_INBOUND
| ATTR_AGGR_MTD KEYW_OUTBOUND opt_as_expression
//// атрибут inject //////////////////////////////////////////////////
opt_inject_expression: | KEYW_UPON inject_expression
inject_expression: inject_expression OP_OR inject_expression_term | inject_expression_term
inject_expression_term: inject_expression_term OP_AND inject_expression_factor
| inject_expression_factor
inject_expression_factor: '(' inject_expression ')' | inject_expression_operand
inject_expression_operand: KEYW_STATIC
| KEYW_HAVE_COMPONENTS '{' opt_filter_prefix_list '}'
| KEYW_EXCLUDE '{' opt_filter_prefix_list '}'
inject_attribute: ATTR_INJECT opt_router_expression_with_at opt_action opt_inject_expression
//// атрибут components //////////////////////////////////////////////
opt_atomic: | KEYW_ATOMIC
components_list: | filter | components_list KEYW_PROTOCOL tkn_word filter
components_attribute: ATTR_COMPONENTS opt_atomic components_list
//**** набор маршрутов *****************************************************
opt_rs_members_list: /* пустой список */
| rs_members_list
rs_members_list: rs_member | rs_members_list ',' rs_member
rs_member: TKN_ASNO | TKN_ASNO OP_MS | TKN_ASNAME | TKN_ASNAME OP_MS
| TKN_RSNAME | TKN_RSNAME OP_MS | TKN_PRFXV4 | TKN_PRFXV4RNG
rs_members_attribute: ATTR_RS_MEMBERS opt_rs_members_list
//**** словарь ******************************************************
rpattr_attribute: ATTR_RP_ATTR TKN_WORD methods
| ATTR_RP_ATTR TKN_RP_ATTR methods
methods: method | methods method
method: TKN_WORD '(' ')' | TKN_WORD '(' typedef_type_list ')'
| TKN_WORD '(' typedef_type_list ',' TKN_3DOTS ')'
| KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ')'
| KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ',' TKN_3DOTS ')'
//// атрибут typedef ////////////////////////////////////////////////
typedef_attribute: ATTR_TYPEDEF TKN_WORD typedef_type
typedef_type_list: typedef_type | typedef_type_list ',' typedef_type
typedef_type: KEYW_UNION typedef_type_list | KEYW_RANGE KEYW_OF typedef_type
| TKN_WORD | TKN_WORD '[' TKN_INT ',' TKN_INT ']'
| TKN_WORD '[' TKN_REAL ',' TKN_REAL ']' | TKN_WORD '[' enum_list ']'
| KEYW_LIST '[' TKN_INT ':' TKN_INT ']' KEYW_OF typedef_type
| KEYW_LIST KEYW_OF typedef_type
enum_list: tkn_word | enum_list ',' tkn_word
//// атрибут protocol ////////////////////////////////////////////////
protocol_attribute: ATTR_PROTOCOL tkn_word protocol_options
protocol_options: | protocol_options protocol_option
protocol_option: KEYW_MANDATORY method | KEYW_OPTIONAL method
//**** Описания лексем *********************************************
//// макросы flex, используемые при определении лексем /////////////////////////////
INT [[:digit:]]+
SINT [+-]?{INT}
REAL [+-]?{INT}?\.{INT}({WS}*E{WS}*[+-]?{INT})?
NAME [[:alpha:]]([[:alnum:]_-]*[[:alnum:]])?
ASNO AS{INT}
ASNAME AS-[[:alnum:]_-]*[[:alnum:]]
RSNAME RS-[[:alnum:]_-]*[[:alnum:]]
RTRSNAME RTRS-[[:alnum:]_-]*[[:alnum:]]
PRNGNAME PRNG-[[:alnum:]_-]*[[:alnum:]]
FLTRNAME FLTR-[[:alnum:]_-]*[[:alnum:]]
IPV4 [0-9]+(\.[0-9]+){3,3}
PRFXV4 {IPV4}\/[0-9]+
PRFXV4RNG {PRFXV4}("^+"|"^-"|"^"{INT}|"^"{INT}-{INT})
ENAMECHAR [^()<>,;:\\\"\.[\] \t\r]
ENAME ({ENAMECHAR}+(\.{ENAMECHAR}+)*\.?)|(\"[^\"@\\\r\n]+\")
DNAME [[:alnum:]_-]+
//// Определения лексем >////////////////////////////////////////////////
TKN_INT {SINT}
TKN_INT {INT}:{INT} if each {INT} is two octets
TKN_INT {INT}.{INT}.{INT}.{INT} if each {INT} is one octet
TKN_REAL {REAL}
TKN_STRING То же самое что и в языке СИ
TKN_IPV4 {IPV4}
TKN_PRFXV4 {PRFXV4}
TKN_PRFXV4RNG {PRFXV4RNG}
TKN_ASNO {ASNO}
TKN_ASNAME (({ASNO}|peeras|{ASNAME}):)*{ASNAME}\
(:({ASNO}|peeras|{ASNAME}))*
TKN_RSNAME (({ASNO}|peeras|{RSNAME}):)*{RSNAME}\
(:({ASNO}|peeras|{RSNAME}))*
TKN_RTRSNAME (({ASNO}|peeras|{RTRSNAME}):)*{RTRSNAME}\
(:({ASNO}|peeras|{RTRSNAME}))*
TKN_PRNGNAME (({ASNO}|peeras|{PRNGNAME}):)*{PRNGNAME}\
(:({ASNO}|peeras|{PRNGNAME}))*
TKN_FLTRNAME (({ASNO}|peeras|{FLTRNAME}):)*{FLTRNAME}\
(:({ASNO}|peeras|{FLTRNAME}))*
TKN_BOOLEAN true|false
TKN_RP_ATTR {NAME} if defined in dictionary
TKN_WORD {NAME}
TKN_DNS {DNAME}("."{DNAME})+
TKN_EMAIL {ENAME}@({DNAME}("."{DNAME})+|{IPV4})
Документ RFC-2280 [3] содержит раннюю версию языка RPSL.
Расширение RSVP для поддержки Diff-Serv
Архитектура MPLS не предполагает использования одного протокола рассылки меток. [RSVP_MPLS_TE] определяет расширение RSVP для установления LSP в сетях MPLS. В данном разделе специфицированы расширения RSVP, кроме тех, которые определены в [RSVP_MPLS_TE], чтобы установить LSP, поддерживающие дифференцированные услуги в сетях MPLS.
Расширения LDP для поддержки Diff-Serv
Архитектура MPLS не предполагает одного протокола рассылки меток. [LDP] определяет протокол рассылки меток LDP (Label Distribution Protocol) и его использование для формирования путей LSP с коммутацией по меткам в сетях MPLS. В данном разделе специфицируются расширения LDP для формирования LSP, поддерживающих дифференциальные услуги в сетях MPLS. Один новый LDP TLV определен в данном документе:
- Diff-Serv TLV
Детальное описание этого TLV представлено ниже. Новый Diff-Serv TLV является опционным с точки зрения LDP. LSR с Diff-Serv, поддерживающий E-LSP, которые используют предварительно сконфигурированную таблицу EXP<-->PHB, в рамках данной спецификации могут поддерживать Diff-Serv TLV. LSR с Diff-Serv, поддерживающий E-LSP, который использует согласованную таблицу EXP<-->PHB, в соответствии с данной спецификацией должен поддерживать Diff-Serv TLV. LSR с Diff-Serv, способный поддерживать L-LSP, в соответствии с данной спецификацией должен поддерживать Diff-Serv TLV.
Расширенный механизм выявления
Сессии LDP между несвязанными напрямую LSR поддерживаются расширенным механизмом выявления партнеров.
Чтобы запустить расширенный механизм выявления, LSR периодически посылает в LDP адресуемые сообщения Hello (Targeted Hello) по определенным адресам. Адресуемые сообщения Hello посылаются в виде UDР-пакетов, направленных в стандартный порт выявления по специфицированному адресу.
Адресуемые сообщения LDP Hello, посылаемые LSR, содержат в себе идентификатор LDP для пространства меток, которое LSR намерен использовать, и, возможно, дополнительную информацию. Расширенное выявление отличается от базового в следующем:
Сообщение адресуемое Hello посылается по специфицированному адресу, а не всем маршрутизаторам мультикастной группы, сопряженной с выходным интерфейсом.
В отличие от базового выявления, которое является симметричным, расширенное - асимметрично.
Один LSR инициирует процесс расширенного выявления в отношении другого LSR, а адресуемый LSR решает, следует ли откликаться или игнорировать данное сообщение адресного Hello. Адресуемый LSR, который решил откликаться, реагирует периодической посылкой адресного Hello LSR-инициатору.
Отклик на адресное Hello идентифицирует сопредельность с потенциальным LDP партнером, достижимым на сетевом уровне, и пространство меток, которое партнер намерен использовать.
Расширяемость LDP и будущая совместимость
В будущем функциональность LDP может быть расширена. Вероятно, в будущем будут использоваться больше типов сообщений и объектов (TLV). Может быть, желательно использовать такие сообщения и TLV в сетях, где работают старые реализации, которые не распознают их. В то время как невозможно сделать все будущие усовершенствования совместимыми со старыми версиями. Данная спецификация определяет правила обработки неизвестных типов сообщений и нераспознанных TLV.
Рассылка меток для LSP, маршрутизированных явно
Управление трафиком [RFC2702] важно для MPLS приложений. MPLS для управления трафиком поддерживает LSP, маршруты которых сформированы явно, и которые не должны следовать традиционным маршрутам, формируемым по схеме шаг-за-шагом согласно маршрутным протоколам базирующимся на адресе места назначения. CR-LDP [CRLDP] определяет расширения LDP, чтобы использовать явно сформированные LSP.
Рассылка меток и управление
Архитектура MPLS [RFC3031] позволяет LSR рассылать данные о соответствии FEC и метки в ответ на прямой запрос другого LSR. Это называется рассылкой меток вниз по течению по запросу (Downstream On Demand). Это также позволяет LSR рассылать метки LSR, которые не запрашивали этого явно. [RFC3031] называет этот метод рассылки меток свободной рассылкой вниз по течению (Unsolicited Downstream); в данном документе этот метод называется Downstream Unsolicited.
Оба эти метода рассылки могут использоваться в одной и той же сети одновременно. Однако, для любой заданной LDP сессии, каждый LSR должен знать о методе рассылки меток, используемым его партнером, для того чтобы избежать ситуации, когда партнер, использующий рассылку меток посредством Downstream Unsolicited, предполагает, что и его партнер делает то же самое.
Разделение каналов управления
Концепция канала управления отличается от концепции канала данных, введенной MPLS в связи с объединением каналов, смотри [MPLS-BUNDLE]. В GMPLS разделение каналов данных и управления может быть связано с несколькими факторами. Сюда относится объединение каналов и другие случаи, такие как информационные каналы, которые не могут транспортировать управляющие данные.
Разрешение конфликта
Существует два потенциальных конфликта, которые следует рассматривать при формировании двунаправленного LSP с поддержкой RSVP-TE. Первый связан с тем, что в RSVP ID узла равно IP-адресу, используемому в объекте RSVP_HOP. Второй связан с тем, что ID узла соседа может быть неизвестен при посылке исходного сообщения Path. Когда это происходит, узел должен выбрать метку случайным образом из доступного набора.
Разрешение конфликтов
Конфликты для меток могут происходить между двумя запросами установления двунаправленных LSP, которые направлены в противоположных направлениях. Этот конфликт происходит, когда обе стороны выделяют одни и те же ресурсы (метки) в одно и то же время. Если нет ограничений на использование меток в двунаправленных LSP и если ресурсы являются альтернативными, тогда оба узла передадут разные метки вверх по течению и конфликта не будет. Однако если имеется ограничение на метки, которые могут быть использованы для двунаправленных LSP (например, если они должны быть физически связаны с одной и той же интерфейсной I/O картой), или если нет более доступных ресурсов, тогда конфликт должен разрешаться другими средствами. Чтобы разрешить конфликт, узел с более высоким значением ID выиграет соревнование и он должен послать сообщение PathErr/NOTIFICATION с указанием "Routing problem/Label allocation failure" (проблема с маршрутизацией/отказ присвоения метки). После получения такого сигнала ошибки, узел должен попытаться выделить другую метку для сегмента выше по течению (и другую предлагаемую метку, если таковая используется) в двунаправленном маршруте. Однако если других ресурсов нет, узел должен начать стандартную процедуру обработки ошибки.
Чтобы уменьшить вероятность конфликта, можно ввести правило, когда узел с более низким ID никогда не предлагает меток для сегмента ниже по течению и всегда воспринимает предлагаемую метку от вышестоящего узла с более высоким значением ID. Кроме того, так как метки пересылаться посредством LMP, может использоваться альтернативное правило, узел с более высоким номером может присваивать метки, начиная с верхнего края диапазона меток, в то время как узел с меньшим номером использует метки нижнего конца диапазона меток. Этот механизм усилит любой алгоритм кластеризации, который может быть использован для оптимизации полосы частот (или длин волн). Особым случаем, на который следует обратить внимание при использовании RSVP и поддержке этого подхода, является то, что ID соседнего узла может быть неизвестно при посылке исходного сообщения Path. Когда такое происходит, узлу следует предложить метку, выбранную из доступного пространства меток случайным образом.
Пример конфликта между двумя узлами (PXC 1 и PXC 2) показан на рис. 1. В этом примере PXC 1 присваивает метку для сегмента выше по течению для канала, соответствующего локальному BCId=2 (локальный BCId=7 для PXC 2), и посылает предлагаемую метку для канала, соответствующего локальному BCId=1 (локальный BCId=6 для PXC 2). Одновременно PXC 2 присваивает метку для сегмента выше по течению для канала, соответствующего его локальному BCId=6 (локальный BCId=1 для PXC 1) и посылает предлагаемую метку для канала, соответствующего его локальному BCId=7 (локальный BCId=2 для PXC 1). Если нет ограничения на метки, которые можно использовать для двунаправленных LSP и если имеются альтернативные ресурсы, тогда PXC 1 и PXC 2 передадут разные метки вверх по течению и конфликт разрешится естественным образом (смотри рис. 2). Однако, если имеются ограничения для меток, используемых в двунаправленных LSP (например, если они должны быть физически подключены к одной I/O карте), тогда конфликт должен быть разрешен с привлечением ID узла (смотри рис. 3).
Рис. 1 . Конфликт меток
В этом примере PXC 1 присваивает метку для сегмента выше по течению, используя BCId=2 (BCId=7 для PXC 2) и рекомендуемую метку, используя BCId=1 (BCId=6 для PXC 2). Одновременно PXC 2 присваивает метку для сегмента выше по течению, используя BCId=6 (BCId=1 для PXC 1) и рекомендуемую метку, используя BCId=7 (BCId=2 для PXC 1).
Рис. 2 . Разрешение конфликта меток без ограничений ресурсов
В этом примере, нет ограничения на метки, которые можно использовать двусторонним соединением и здесь нет конфликта.
Рис. 3 . Разрешение конфликта меток посредством ограничений ресурсов
В этом примере, метки 1,2 и 3,4 для PXC 1 (метки 6,7 и 8,9 для PXC 2, соответственно) должны использоваться одним и тем же двусторонним соединением. Так как PXC 2 имеет больший ID узла, он выигрывает соревнование и PXC 1 должен использовать другой набор меток.
Разрешение неопределенности
Допускается, чтобы один и тот же обмен (peering) был описан в более чем одной спецификации партнерства в пределах выражения политики. Например:
aut-num: AS1
| import: | from AS2 1.1.1.2 at 1.1.1.1 action pref = 2; |
| from AS2 1.1.1.2 at 1.1.1.1 action pref = 1; | |
| accept AS4 |
Это не ошибка, хотя такая запись определенно не желательна. Чтобы убрать неопределенность, используется действие (action), соответствующее первой спецификации партнерства. То есть маршруты воспринимаются с предпочтением, равным 2. Это правило называется правилом порядка спецификаций.
Рассмотрим пример:
aut-num: AS1
| import: | from AS2 action pref = 2; |
| from AS2 1.1.1.2 at 1.1.1.1 action pref = 1; dpa = 5; | |
| accept AS4 |
где обе спецификации партнерства перекрывают маршруты 1.1.1.1-1.1.1.2, хотя вторая спецификация более специфична. Здесь также используется правило порядка спецификаций, выполняется только действие (action) "pref = 2". В действительности, вторая пара пиринговых действий бесполезна, так как первая пара пиринговых действий покрывает действие второй. Если требуется политика, при которой эти маршруты воспринимались данным пирингом с предпочтением 1 и с предпочтением 2 для всех остальных пирингов, пользователь должен специфицировать следующее:
aut-num: AS1
| import: | from AS2 1.1.1.2 at 1.1.1.1 | action pref = 1; dpa = 5; |
| from AS2 | action pref = 2; | |
| accept AS4 |
Допускается также, чтобы более чем одно выражение политики покрывало один и тот же набор маршрутов в рамках одного пиринга. Например:
aut-num: AS1
import: from AS2 action pref = 2; accept AS4
import: from AS2 action pref = 1; accept AS4
В этом случае, также используется правило порядка спецификаций. То есть маршруты AS4 от AS2 воспринимаются с предпочтением 2. Если фильтры перекрываются, но не тождественны:
aut-num: AS1
import: from AS2 action pref = 2; accept AS4
import: from AS2 action pref = 1; accept AS4 OR AS5
маршруты AS4 воспринимаются от AS2 с предпочтением 2 и, тем не менее, маршруты AS5 также воспринимаются, но с предпочтением 1.
Ниже приведено общее правило порядка спецификации для разработчиков программ RPSL. Рассмотрим два расширения политики:
aut-num: AS1
import: from peerings-1 action action-1 accept filter-1
import: from peerings-2 action action-2 accept filter-2
Вышеприведенные выражения политики эквивалентны следующим трем выражениям, где нет неопределенности:
aut-num: AS1
import: from peerings-1 action action-1 accept filter-1
import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1
import: from peerings-4 action action-2 accept filter-2
где peerings-3 - это набор маршрутов, которые покрываются как peerings-1, так и peerings-2, а peerings-4 - набор маршрутов, которые покрываются peerings-2, но не покрываются peerings-1 ("filter-2 AND NOT filter-1" соответствует маршрутам, которые согласуются с filter-2, но не с filter-1).
Пример:
aut-num: AS1
| import: | from AS2 1.1.1.2 at 1.1.1.1 |
| action pref = 2; | |
| accept {128.9.0.0/16} | |
| import: | from AS2 |
| action pref = 1; | |
| accept {128.9.0.0/16, 75.0.0.0/8} |
Рассмотрим два пиринга с AS2, 1.1.1.1-1.1.1.2 и 9.9.9.1- 2.2.2.2. Оба выражения политики покрывают 1.1.1.1-1.1.1.2. Для этого пиринга, маршрут 128.9.0.0/16 воспринимается с предпочтением 2, а маршрут 75.0.0.0/8 воспринимается с предпочтением 1. Пиринг 9.9.9.1-2.2.2.2 покрывается только вторым выражением политики. Следовательно, как маршрут 128.9.0.0/16 так и маршрут 75.0.0.0/8 воспринимаются с предпочтением 1 пирингом 9.9.9.1-2.2.2.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} |
Рис. .34. Перекрывающиеся объединения.
На рис. 34, AS1 вместе с AS2 объединяют 128.8.0.0/16 и 128.9.0.0/16 в 128.8.0.0/15. Вместе с AS3, AS1 объединяет 128.10.0.0/16 и 128.11.0.0/16 в 128.10.0.0/15. Но все вместе они объединяют эти четыре маршрута в 128.8.0.0/14. Предполагая все четыре компоненты доступными, маршрутизатор в AS1 для внешней AS, скажем AS4, сначала сгенерирует 128.8.0.0/15 и 128.10.0.0/15. Это сделает 128.8.0.0/15, 128.10.0.0/15 и его исключение 128.11.0.0/16 доступным для генерации 128.8.0.0/14. Маршрутизатор из этих трех маршрутов будет затем генерировать 128.8.0.0/14. Следовательно, для AS4, 128.8.0.0/14 и его исключение, 128.10.0.0/15 и его исключение 128.11.0.0/16 станут экспортируемыми.
Для AS2, маршрутизатор в AS1 сгенерирует только 128.10.0.0/15. Следовательно, 128.10.0.0/15 и его исключение 128.11.0.0/16 станут экспортируемыми. Заметим, что 128.8.0.0/16 и 128.9.0.0/16 являются также экспортируемыми, так как они не участвуют в объединении, допускающем экспорт в AS2. Аналогично, для AS3, маршрутизатор в AS1 будет генерировать только 128.8.0.0/15. В этом случае 128.8.0.0/15, 128.10.0.0/16, 128.11.0.0/16 могут экспортироваться.
Реализация LSR с интерфейсами LC-ATM
LSR Diff-Serv должны поддерживать L-LSP для интерфейсов LC-ATM. Данная спецификация предполагает, что краевой-LSR области ATM-LSR использует метод инкапсуляции, определенный в [MPLS_ATM].
Реализация LSR с интерфейсами LC-FR
LSR Diff-Serv должны поддерживать L-LSP для интерфейсов LC-Frame Relay. Данная спецификация предполагает, что краевые LSR области FR-LSR используют метод “общей инкапсуляции”, как это рекомендуется в [MPLS_FR].
Приложение A. Примеры реализации сценариев
В данном разделе не предлагается новых спецификаций, а лишь приводятся примеры того, как может быть реализован гибкий подход поддержки Diff-Serv через MPLS.
Регистрация типа среды
Регистрация нового типа среды начинается с формирования регистрационного предложения. Регистрация может произойти в рамках различных регистрационных схем (деревьев), которые предполагают различные требования. Вообще, новое регистрационное предложение оценивается и рассматривается в зависимости от используемой схемы (дерева). Тип среды затем регистрируется, если предложение оказывается приемлемым.
2.1. Деревья регистрации и имена субтипов
Для того чтобы увеличить эффективность и гибкость процесса регистрации различные структуры субтипов имен могут быть зарегистрированы так, чтобы удовлетворить различным естественным требованиям, например, субтип, который будет рекомендованa для широкого использования сообществом Интернет или субтип, который используется для переноса файлов, ассоциированных с некоторой частной программой. Последующие субсекции данного документа определяют регистрационные "деревья", отличающиеся использованием стандартной формы имен (например, имен вида "tree.subtree...type"). Заметим, что некоторые типы среды определены до появления данного документа и их имена не согласуются с данной схемой. Смотри приложение A, где рассматривается эта проблема.
2.1.1. IETF-дерево
Дерево IETF служит для типов, представляющих общий интерес для сообщества Интернет. Регистрация в IETF требует одобрения IESG и публикации данного типа среды в каком-то документе RFC.
Типы среды в IETF-дереве обычно обозначаются именами, которые не оформлены стандартным образом, т.е., не содержат символов точка (".", полный останов).
"Хозяином" регистрации типа среды в рамках дерева IETF предполагается сама группа IETF. Модификации или изменения спецификации требуют той же процедуры, что и регистрация.
2.1.2. Дерево производителя (Vendor Tree)
Дерево производителя используется для типов среды, соответствующих определенным коммерческим продуктам.
Результат регистрации может быть ассоциирован с деревом производителя тем, кто нуждается в замене файлов, сопряженных с определенным программным продуктом. Однако регистрация формально принадлежит производителю или организации, разработавшей программу или формат.
Регистрация в рамках дерева производителя выделяется с помощью префикса имени "vnd.". Далее может следовать имя известного производителя (например, "vnd.lapot"), адрес производителя или место расположения программы, заключительная секция имени может содержать наименование типа среды (например, vnd.bigcompany.funnypictures).
2.1.3. Частное дерево
Регистрация типов среды, созданных с экспериментальными целями, могут быть зарегистрированы в рамках частного дерева. Регистрация такого вида имеет префикс имени "prs.". Хозяином "частной" регистрации и соответствующих спецификаций является человек или объект, осуществивший регистрацию. Публикация частных типов среды не требуется.
2.1.4. Специальное `x.'-дерево
Для удобства и симметрии со схемой регистрации имена типов среды, начинающиеся с "x." могут использоваться для тех же целей, что и имена, начинающиеся с "x-". Эти типы не являются зарегистрированными и могут использоваться партнерами при взаимном согласии.
Однако при упрощенной процедуре регистрации, описанной выше для частных типов и типов среды производителей трудно себе представить ситуацию, когда бы возникла необходимость использования незарегистрированных типов среды.
2.1.5. Дополнительные регистрационные деревья
От случая к случаю как этого требует сообщество, IANA может по согласованию с IESG, создать новое регистрационное дерево верхнего уровня. Предполагается, что такие деревья могут быть созданы для внешней регистрации и управления, например научными сообществами для их внутреннего использования. Вообще, качество рассмотрения спецификаций для этих деревьев регистрации должно быть столь же тщательным, как и в случае IETF. О создании этих новых деревьев уведомляет публикация RFC, одобренная IESG.
2.2. Требования регистрации
Предложения регистрации среды должны соответствовать требованиям изложенным ниже в последующих разделах. Заметим, что требования могут иной раз зависеть от дерева регистрации.
2.2.1. Требования функциональности
Типы среды должны функционировать как настоящий формат среды. Регистрация вещей, которые относятся в большей мере к транспортному кодированию, выбору символьного набора не допускается. Например, хотя существуют приложения, которые осуществляют транспортное декодирование base64 [RFC-2045], base64 не может быть зарегистрировано в качестве типа среды. Это требование не зависит от используемого регистрационного дерева.
2.2.2. Требования к именам
Всем зарегистрированным типам среды должны быть присвоены имена типов и субтипов MIME. Комбинация этих имен служит в дальнейшем для идентификации типа среды и формата субтипа.
При выборе имени типа верхнего уровня должна учитываться природа типа среды. Например, среда, используемая для представления статической картинки должна быть субтипом типа изображение, в то время как среда, способная представлять звуковую информацию должна принадлежать аудио типу. Для получения дополнительной информации смотри RFC-2046.
Новые субтипы типов верхнего уровня должны соответствовать регламентациям этого уровня. Например, все субтипы типа составных данных должны использовать один и тот же синтаксис инкапсуляции.
В некоторых случаях новый субтип среды может не вполне согласовываться с определенным на текущий момент типом содержимого верхнего уровня. Если такое произошло, следует определить новый тип верхнего уровня, который бы согласовывался с данным субтипом. Такое определение должно быть выполнено согласно стандартной процедуре и опубликовано в RFC. Это требование не зависит от используемого регистрационного дерева.
2.2.3. Требования к параметрам
Типы среды могут использовать один или более параметров MIME, некоторые параметры могут оказаться автоматически доступными для типа среды в случае, когда они применимы ко всему семейству субтипов. В любом случае имена, величины и назначение любого параметра должны быть полностью специфицированы при регистрации типа среды в рамках дерева IETF. Они должны быть специфицированы как можно полнее, когда тип среды регистрируется в рамках частного дерева или дерева производителя.
Новые параметры не могут определяться с целью расширения функциональности для типов, зарегистрированных в рамках дерева IETF. Но новые параметры могут быть добавлены для передачи дополнительной информации, которая не изменяет существующую функциональность.
2.2.4. Требования к канонизации и формату
Все зарегистрированные типы среды должны использовать один канонический формат данных вне зависимости от дерева регистрации. Спецификация формата каждого типа среды необходима для всех типов зарегистрированных для дерева IETF, эта информация должна присутствовать и в предложении для регистрации типа среды. Спецификации формата и особенностей обработки могут быть, а могут и не быть общедоступны для типов среды, зарегистрированных для дерева производителя. В предложения регистрации такого вида включаются только спецификации программы и ее версии пригодной для работы с данным типом среды. Включение спецификаций формата или ссылки на них в предложение регистрации желательно, но не обязательно.
Спецификации формата необходимы для регистрации в рамках частного дерева, они могут быть опубликованы в RFC или помещены в депозитарий IANA. Спецификации, помещаемые в депозитарий должны отвечать тем же требованиям, что и регистрируемые.
Некоторые типы среды включают в себя патентованные технологии. Регистрация типа среды, включающего в себя патентованные технологии, также разрешена. Однако устанавливаются ограничения (RFC-1602) на применение патентованных технологий в рамках стандартных протоколов.
2.2.5. Рекомендации по взаимозаменяемости
Типы среды должны быть способны работать с максимально возможным числом систем и приложений. Однако некоторые типы среды неизбежно будут иметь проблемы при работе на некоторых платформах. Могут возникнуть трудности из-за различных версий, порядка байт, специфики работы шлюза и т.д.
Способность работы с любыми типами среды не требуется, но желательно, чтобы были четко описаны границы применимости. Публикация типа среды не предполагает исчерпывающего обзора возможностей работы с различными платформами и приложениями.
2.2.6. Требования к безопасности
Рассмотрение аспектов безопасности необходимо для всех типов, регистрируемых в рамках IETF-дерева. Аналогичный анализ для типов среды регистрируемых в рамках частного дерева или дерева производителя рекомендуется, но не является обязательным. Однако вне зависимости от того что анализ безопасности мог проводиться или нет, все описания соображений по безопасности должны быть выполнены крайне аккуратно вне зависимости от дерева регистрации. В частности, заявление, что "никакие соображения безопасности не сопряжены с этим типом" не следует путать с "безопасность сопряженная с данным типом не анализировалась и не оценивалась".
Не существует требования, чтобы регистрируемые типы среды были безопасны и не несли в себе каких либо рисков. Несмотря на это, все известные риски должны быть идентифицированы при регистрации типа вне зависимости от используемого дерева.
Секция безопасности подлежит дальнейшему развитию. Некоторые аспекты, которые следует учитывать при анализе безопасности типа среды, перечислены ниже.
| (1) |
В асинхронных почтовых системах, где информация о возможностях удаленного почтового агента часто не доступна для отправителя, максимум взаимодействия может быть достигнут путем ограничения числа типов среды, используемых для общих форматов, которые предполагается широко внедрять. Именно эта концепция, принятая в прошлом, явилась причиной ограничения числа возможных типов среды и привела к формированию процесса регистрации типов среды.
Однако необходимость в "общих" типах среды не требует ограничения регистрации новых типов. Если для определенного приложения рекомендуется ограниченный набор типов среды, это должно быть определено отдельным заявлением применимости для приложения или среды реализации.
2.2.7. Требования к публикации
Предложения для типов среды регистрируемых в рамках IETF-дерева должны публиковаться в виде RFC. RFC-публикации типа среды производителя или частного типа среды желательны, но не обязательны. Во всех случаях IANA сохраняет копии всех предложений по типам среды и публикует их как часть самого регистрационного дерева типов среды.
Дерево IETF существует для типов среды, которые действительно требуют серьезного анализа и стандартного процесса одобрения, в то время как деревья производителей и частные деревья такой процедуры не требуют. Ожидается, что заявления о применимости для конкретных приложений будут публиковаться время от времени для типов среды, которые доказали свою эффективность в определенных контекстах.
Как было обсуждено выше, регистрация типа среды верхнего уровня предполагает стандартную процедуру принятия и, следовательно, обязательную RFC-публикацию.
2.2.8. Дополнительная информация
Различные виды опционной информации могут быть включены в спецификацию типа среды, если таковые имеются:
| (1) | Магические числа (длина, значения октетов). Магические числа представляют собой байтовые последовательности, которые всегда имеются и по этой причине могут использоваться для идентификации объектов, принадлежащих данному типу среды. |
| (2) | Расширения имени файлов, используемые на одной или более платформах для индикации того, что файл содержит данный тип среды. |
| (3) | Код типа файла Macintosh (4 октета) используется для маркировки файлов, содержащих данный тип среды. |
Регламентации IANA
В этом разделе представлены значения, используемые в данном документе и регламентированные IANA.
---------------------------------------------------------------------
Типы сообщений
o Сообщение уведомления (Тип сообщения = 21)
---------------------------------------------------------------------
Класс типов
o RSVP_HOP (C-Num 3)
- IPv4 IF_ID RSVP_HOP (C-тип = 3)
- IPv6 IF_ID RSVP_HOP (C-тип = 4)
o ERROR_SPEC (C-Num 6)
- IPv4 IF_ID ERROR_SPEC (C-тип = 3)
- IPv6 IF_ID ERROR_SPEC (C-тип = 4)
o LABEL_REQUEST (Class-Num 19) - Generalized_Label_Request (C-тип = 4)
o RSVP_LABEL (Class-Num = 16)
- Generalized_Label (C-тип = 2)
- Waveband_Switching_Label C-тип (C-тип = 3)
---------------------------------------------------------------------
Новые Class-Nums, C-типы, наследованные от объекта метка (тоже что и CNum16)
o RECOVERY_LABEL Class-Num в форме 0bbbbbbb (= 34)
o SUGGESTED_LABEL Class-Num в форме 10bbbbbb (= 129)
o UPSTREAM_LABEL Class-Num в форме 0bbbbbbb (= 35)
---------------------------------------------------------------------
Новые Class-Num
o LABEL_SET Class-Num в форме 0bbbbbbb (= 36)
- Тип 1 (C-тип = 1)
o ACCEPTABLE_LABEL_SET Class-Num в форме 10bbbbbb (= 130)
- Тип 1 Acceptable_Label_Set (C-тип из label_set cnum)
o NOTIFY_REQUEST Class-Num в форме 11bbbbbb (= 195)
- Запрос уведомления IPv4 (C-тип = 1)
- Запрос уведомления IPv6 (C-тип = 2)
o PROTECTION Class-Num в форме 0bbbbbbb (= 37)
- Тип 1 (C-тип = 1)
o ADMIN STATUS Class-Num в форме 11bbbbbb (= 196)
- Тип 1 (C-тип = 1)
o RESTART_CAP Class-Num в форме 10bbbbbb (= 131)
- Тип 1 (C-тип = 1)
---------------------------------------------------------------------
ERO/RRO типы субобъектов
o Субобъект ERO метки Тип 3 - метка
o Субобъект RRO метки Тип 3 - метка
---------------------------------------------------------------------
Коды ошибок
o "Routing problem/Label Set" (значение = 11)
o "Routing problem/Switching Type" (значение = 12) (duplicate code 13 dropped)
o "Routing problem/Unsupported Encoding" (значение = 14)
o "Routing problem/Unsupported Link Protection" (значение = 15)
o "Notify Error/Control Channel Active State" (значение = 4)
o "Notify Error/Control Channel Degraded State" (значение = 5)
---------------------------------------------------------------------
RequestNever
Никогда не делай запросов. Эта процедура полезна, если нижестоящий LSR использует процедуры PushConditional или PushUnconditional, но она бесполезна, если нижестоящий LSR использует процедуры PulledUnconditional или PulledConditional.
Эта процедура будет использоваться LSR, когда применена не запрошенная рассылка меток и свободный режим удержания меток.
RequestRetry
Ru должен выдать запрос снова спустя некоторое время. То есть, источник запроса ответственен за попытку получить необходимую ассоциацию позднее. Эту процедуру следует использовать, когда применена рассылка меток downstream-on-demand.
RequestWhenNeeded
Осуществляет запрос всякий раз, когда меняется соотношение между следующим шагом L3 и адресным префиксом, или когда прислан новый адресный префикс, и нет уже ассоциации метки от следующего шага для заданного адресного префикса.
Эту процедуру следует использовать LSR, когда применен консервативный режим удержания меток.
Решение (DEC) PDP -> PEP
PDP реагирует посредством REQ с сообщением DEC, которое включает в себя ассоциированный дескриптор клиента и один или более объектов решения, сгруппированные относительно пар типов объектов Context и флагов решения (Decision Flags). Если имела место протокольная ошибка, вместо этого присылается объект ошибки.
Требуется, чтобы первое сообщение решения для нового или актуализованного запроса имело флаг требования в заголовке COPS равный 1. Это исключает отслеживание того, какому модифицированному запросу соответствует конкретное решение (т.е., запрос посылается повторно для того же самого дескриптора). Важно, чтобы для данного дескриптора существовало одно предпочтительное решение, соответствующее определенному запросу. Это по существу означает, что PEP не должен посылать более одного REQ (для данного дескриптора), прежде чем он получит соответствующий DEC с заданным набором флагов сообщения. PDP должен всегда посылать решения для запросов в порядке их получения и каждому запросу должно соответствовать решение.
Чтобы избежать тупиков, PEP может делать выдержку после посылки запроса, пока не будет получено решение. Он должен аннулировать дескриптор, для которого время выдержки истекло, а решение не получено, новая попытка может быть осуществлена с новым дескриптором.
Формат сообщения Decision представлен ниже:
<Decision Message> ::= <Common Header>
<Client Handle>
<Decision(s)> | <Error>
[<Integrity>]
<Decision(s)> ::= <Decision> | <Decision(s)> <Decision>
<Decision> ::= <Context>
<Decision: Flags>
[<Decision: Stateless Data>]
[<Decision: Replacement Data>]
[<Decision: ClientSI Data>]
Сообщение Decision может включать либо объект Error, либо один или более объекта context и соответствующего объекта decision. О проблемах протокола COPS сообщается в объекте Error. Объект Decision зависит от контекста и типа клиента.
Резервирование полосы для E-LSP и L-LSP
Вне зависимости оттого, какой протокол используется для присвоения меток, E-LSP и L-LSP могут быть сформированы с или без резервирования полосы пропускания.
Установление E-LSP или L-LSP с резервированием полосы пропускания означает, что требования на полосу были согласованы для LSP на фазе его формирования. Такие согласованные требования к полосе пропускания могут использоваться LSR при установлении времени выполнения контроля доступа для согласованного LSP к Diff-Serv ресурсам, предоставляемым (например, путем конфигурирования, SNMP или протоколов политики) для привилегированных PSC. Такие согласованные требования к полосе пропускания могут также использоваться LSR во время конфигурирования для выполнения настройки ресурсов Diff-Serv, предназначенных для приоритетных PSC.
Заметим, что установление E-LSP или L-LSP с резервированием полосы пропускания не означает, что необходимо согласование трафика всех LSP. Так как E-LSP и L-LSP специфицированы в данном документе для поддержки дифференцированных услуг, необходимая обработка переадресуемых пакетов (согласование трафика и политики отбрасывания) определяется соответствующим Diff-Serv PHB. Эта процедура переадресации должна осуществляться LSR на уровне гранулярности BA и должна согласовываться со спецификациями PHB. Когда требования к полосе пропускания согласованы на фазе формирования L-LSP, полоса пропускания будет соответствовать PSC L-LSP. Таким образом, LSR, которые используют согласованную полосу пропускания, чтобы осуществить контроль доступа, могут выполнить эту задачу за счет ресурсов Diff-Serv, которые выделены PSC (например, за счет полосы, гарантированной PSC весом его трафика).
Когда требования к полосе пропускания согласованы на фазе формирования E-LSP, полоса ассоциируется со всем LSP и, следовательно, с набором транспортируемых PSC. Таким образом, LSR, которые используют согласованную полосу для осуществления управления доступом, могут выполнять управление доступом к общим ресурсам, используемым совместно набором PSC.
Примеры сценариев, где не используется резервирование и где такое резервирование осуществляется, представлены в Приложении B.
Режим анонсирования меток
Каждый интерфейс LSR сконфигурирован для работы как в режиме анонсирования Downstream Unsolicited, так и Downstream on Demand. LSR обмениваются данными о режимах анонсирования на фазе инициализации. Главное отличие между режимами Downstream Unsolicited и Downstream on Demand определяется тем, какой LSR берет на себя ответственность за инициализацию запросов выделения меток и их анонсирование.
