Режим сохранения метки (Retention)
Архитектура MPLS [RFC3031] вводит нотацию режима сохранения
метки, которая специфицирует, поддерживает ли LSR соответствие меток для FEC, полученных от соседа, который не является следующим шагом для FEC.
Режим удержания меток (Retention Mode)
LSR Ru может получить (или уже получил) от LSR Rd ассоциацию метка-FEC, даже несмотря на то, что Rd не является следующим шагом для Ru (для данного FEC).
Ru теперь имеет выбор следует ли ему отслеживать такие ассоциации или отбрасывать их. Если Ru отслеживает такие ассоциации, тогда он может немедленно начать использование этой ассоциации, если Rd в конце концов, становится его следующим шагом для заданного FEC. Если Ru игнорирует такие ассоциации, тогда если Rd позднее станет следующим шагом, ассоциация должна быть воспринята снова. Если LSR поддерживает "свободный режим удержания меток" (Liberal label retention mode), он поддерживает ассоциации между меткой и FEC, который получен от LSR, не являющегося следующим шагом для этого FEC. Если LSR поддерживает "консервативный режим удержания меток" (Conservative label retention mode), он отбрасывает такие ассоциации.
Свободный режим удержания меток допускает быструю адаптацию к маршрутным изменениям, а консервативный режим сохранения меток требует от LSR поддержки много меньшего числа меток.
Режим управления рассылкой меток
Поведение исходной конфигурации LSP определяется тем, работает ли LSR в режиме независимого или упорядоченного управления LSP. LSR может поддерживать оба типа управления.
Режимы консервативного и либерального удержания меток
В консервативном режиме ([ANDE]) только метки, которые используются для переадресации (если следующим шагом для FEC является LSR, который анонсировал метку), присваиваются и поддерживаются. В либеральном режиме метки анонсируются и поддерживаются для всех соседей. Либеральный режим не чувствителен к мультикастингу. Для этого имеется две причины: Все LSR имеют маршрут для каждого уникастного FEC. Это не верно для мультикастных FEC. Для мультикастинга LSR всегда знает, какому соседу следует посылать запросы метки или сообщения о присвоении. Например, в уникастном режиме Downstream Unsolicited (смотри ниже) LSR не знает, куда посылать ассоциацию метки, и в результате должен посылать ее всем своим соседям. В этом случае при поддержке либерального режима лишние сообщения не посылаются (необходима дополнительная статусная информация и некоторое пространство меток) и таким образом порог поддержки либерального режима следует рассмотреть ниже.
В таблице 3 показаны случаи, когда LSR знает, куда посылать запрос на метку.
Таблица 3. Знает ли LSR, куда посылать запросы меток?
Для уникастного потока, LSR могут определить LSR следующего шага, которому следует послать запрос в случае режима работы Upstream Unsolicited или Downstream on Demand. LSR, однако, не может определить маршрутизатор предшествующего шага. Предыдущий шаг необязательно является следующим шагом в направлении отправителя, так как путь от A к B не обязательно совпадает с путем от B к A. Такая ситуация может случиться в результате асимметричных метрик в канале или в случае, когда имеется несколько маршрутов с идентичной метрикой [PAXS].
В случае мультикастинга, LSR знает как следующий шаг, так и предыдущий. Так как мультикастные деревья формируются реверсивным методом кратчайших путей, предшествующим шагом всегда является следующий узел по направлению к отправителю или корню дерева.
RSVP-TE: расширение RSVP для LSP-туннелей
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
D. Awduche, RFC-3209, декабрь 2001
Сессии LDP
LDP-сессии реализуются между LSR, чтобы поддержать обмен метками между ними. Когда LSR использует LDP для анонсирования более чем одного пространства меток, он использует разные LDP-сессии для разных пространств меток.
Сети с множественным доступом
Мультикастный в сетях с множественным доступом представляет собой определенную проблему. LSR, который хочет присоединиться к группе, должен всегда быть готов воспринять метку, которая уже приписана группе LSP. Это может быть достигнуто тремя путями: Каждый LSR канала с множественным доступом запоминает все анонсированные метки канала, даже если он не получил сигнал join для соответствующей группы. Если LSR добавлен к каналу с множественным доступом, он должен получить эту информацию от другого LSR канала или в случае soft state анонсирования меток, он может ждать некоторое время, прежде чем сам сможет сформировать метку. Если LSR формируют метки в один и тот же момент, LSR с более высоким кодом IP-адреса может ее сохранить, в то время как другой LSR отзывает свою метку. Каждый LSR получает свой собственный диапазон меток. Механизм распределения меток описан в [FARI]. Если LSR добавляется к каналу с множественным доступом, диапазон меток должен быть согласован снова и, возможно, некоторые существующие каналы LSP разрываются и восстанавливаются с другими метками. В каждом канале с множественным доступом один LSR может быть выбран ответственным за выделение меток. Когда LSR нужна метка, он может запросить ее у этого LSR, осуществляющим присвоение меток.
В отличие от уникастного варианта, мультикастный поток может иметь более одного нижележащего LSR, которые все должны использовать одну и ту же метку. Можно обсуждать две схемы анонсирования меток: [FARI] предлагает рассылать анонсирования меток мультикастно всем LSR, подключенным к общему каналу. Так как мультикастинг не является надежным, это требует периодического анонсирования меток, что приведет повторным оповещениям об одних и тех же метках.Другой подход заключается в том, что LSR рассылает анонсирования меток уникастно с привлечением, например, протокола TCP всем другим (или всем заинтересованным) LSR, подключенным к общему каналу.
Так как LSP оправданы, если они живут долго, и так как число LSR в используемом совместно канале ограничено, второй подход представляется предпочтительным.
Другой момент, связанный с мультикастингом в сетях с множественным доступом, сопряжен с тем, следует ли использовать для присвоения меток вышестоящий или нижестоящий LSR. Для мультикастного трафика, использование вышестоящего LSR проще, так как там может быть только один вышестоящий узел, принадлежащий данному мультикастному дереву. Этот (вышестоящий) узел может присвоить уникальную метку для заданного FEC. Рассылка меток “вниз по течению” должна учитывать тот факт, что может быть много нижестоящих узлов в заданном дереве для канала с множественным доступом; каждый узел может предложить свою метку для FEC, что потребует некоторого разбирательства, чтобы каждому мультикастному FEC была присвоена лишь одна метка.
Раз метка присвоена, может возникнуть ситуация, когда инициатор возникновения данной метки покинет данное дерево. В случае присвоения меток “вниз по течению”, это может случиться, когда инициатор присвоения покинет группу. В случае присвоения меток “вверх по течению” это может случиться, когда в вышестоящем LSR происходят изменения, сопряженные с вариацией топологии рассылки уникастных сообщений.
Схемы для LSR, которые поддерживают объединение меток
Если Ru и Rd являются партнерами по рассылке меток, и оба поддерживают объединение меток, должна использоваться одна из следующих схем:
1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseImmediate >
Это не затребованная рассылка меток “вниз по течению” с независимым управлением, свободным режимом удержания меток и без детектирования маршрутных петель.
2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected>
Это не затребованная рассылка меток “вниз по течению” с независимым управлением, свободным режимом удержания меток и детектированием петель.
3. <PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange,*>
Это не затребованная рассылка меток “вниз по течению” с упорядоченным управлением (со стороны конца) и консервативным режимом удержанием меток. Детектирование петель опционно.
4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>
Это не затребованная рассылка меток “вниз по течению” с упорядоченным управлением (со стороны конца) и свободным режимом удержанием меток. Детектирование петель опционно.
5. <PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *>
Это рассылка меток “вниз по течению по запросу” (downstream-on-demand) с упорядоченным управлением (инициируемым со стороны входа), консервативным режимом удержания меток и опционным детектированием петель.
6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseImmediate>
Это рассылка меток “вниз по течению по запросу” с независимым управлением, консервативным режимом удержания меток и без детектирования петель.
7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected>
Это рассылка меток “вниз по течению по запросу” с независимым управлением, консервативным режимом удержания меток и детектированием петель.
4.2.2. Схемы для LSR, которые не поддерживают объединение меток
Предположим, что R1, R2, R3 и R4 являются ATM-коммутаторами, которые не поддерживают объединение меток, но используются в качестве LSR. Предположим далее, что маршрут L3 шаг-за-шагом для адресного префикса X имеет вид <R1, R2, R 3, R4>, и что пакеты, адресованные X, могут войти в сеть через любой из этих LSR. Так как здесь нет возможности реализовать схему мультиточка-точка, LSP должны быть реализованы как VC точка-точка, что означает необходимость трех таких VC для адресного префикса X: <R1, R2, R3, R4>, <R2, R3, R4> и <R3, R4>.
Следовательно, если R1 и R2 являются MPLS-партнерами, и любой из них является LSR, который реализован с использованием обычного коммутирующего оборудования ATM (т.e., без подавления перекрытия ячеек), или по какой то иной причине не способен осуществлять объединение меток, используемая схема MPLS между R1 и R 2 должна быть одной из следующих:
1. <PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *>
Это рассылка меток “вниз по течению по запросу” с упорядоченным управлением (инициируемым со стороны входа), консервативным режимом удержания меток и опционным детектированием маршрутных петель.
Использование процедуры RequestOnRequest вынудит R4 послать R3 три метки для X; R3 пошлет R22 метки для X, а R2 пошлет одну метку R1 для X.
2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseImmediate>
Это рассылка меток “вниз по течению по запросу” с независимым управлением, консервативным режимом удержания меток и без детектирования петель.
3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected>
Это рассылка меток “вниз по течению по запросу” с независимым управлением, консервативным режимом удержания меток и с детектированием петель.
Схемы MPLS: поддерживаемые комбинации процедур
Рассмотрим два LSR, Ru и Rd, которые являются партнерами рассылки меток для некоторого набора адресных префиксов, где Ru является вышестоящим партнером, а Rd – нижестоящим.
Схема MPLS, которая управляет взаимодействием Ru и Rd может быть описана с помощью пяти процедур: <Distribution Procedure, Request Procedure, NotAvailable Procedure, Release Procedure, labelUse Procedure>. Так как существует только одна процедура отзыва, она здесь не упоминается. Появление "*" в одной из позиций в качестве подмены, означает, что в данной категории возможна любая процедура; появление "N/A" в некоторой позиции указывает, что не нужна никакая процедура данной категории.
Только схемы MPLS, которые специфицированы ниже, поддерживаются архитектурой MPLS. Другие схемы могут быть добавлены в будущем, если их необходимость будет доказана.
Широкая рассылка и отсекание ветвей
Чтобы сформировать мультикаст дерево протоколы маршрутизации (например, DVMRP, PIM-DM) широко рассылают мультикаст-данные. Отдельные ветви могут быть затем отсечены узлами, которые не хотят получать данные определенных мультикастинг-групп. Этот процесс периодически повторяется.
Широкая рассылка и отсекание ветвей протоколов мультикастинг-маршрутизации имеет некоторые характеристики, которые значительно отличаются от параметров уникастных маршрутных протоколов: Изменчивость. Из-за особенностей протокола Flood & Prune, генерируются деревья с разными структурами. Решения о соответствии динамических деревьев L3 p2mp и L2 p2mp LSP должны быть эффективными с точки зрения сигнальных издержек и времени установления LSP. Варьируемые L2 LSP потребуют большого числа меток, что является недостатком при ограниченном их многообразии.Управление трафиком. Маршрутизатор лишь определяет состояние для определенной группы, когда для нее поступают данные. Маршрутизаторы также независимо принимают решение об удалении состояния, когда истекает время таймера пассивности.
- Таким образом, LSP не могут быть сформированы заранее, как это обычно делается в случае уникастинга. Чтобы минимизировать время между поступлением данных и формированием LSP, желателен достаточно быстродействующий метод конфигурации LSP (setup method).
- Так как формирование и ликвидация маршрута L3 в каждом узле запускается самим трафиком, это предполагает, что LSP, ассоциированный с маршрутом, формировался и уничтожался также процедурой, управляемой трафиком.
- Если LSR не поддерживает переадресацию L3, технология управления трафиком требует, чтобы вышестоящий LSR брал на себя инициативу формирования LSP (анонсирование меток Upstream Unsolicited или Downstream on Demand).
Символьный набор
Секция 'charset' кодировочного слова специфицирует символьный набор, соответствующий незакодированному тексту. 'charset' может представлять любой символьный набор, разрешенный параметром "charset" MIME части тела "text/plain", или любой символьный набор с именем, зарегистрированным IANA для использования с типом содержимого text/plain MIME.
Некоторые символьные наборы используют технику переключения кодов для перехода между режимом "ASCII" и другими режимами. Если текст в кодировочном слове содержит последовательность, которая заставляет интерпретатор символьного набора переключиться из режима ASCII, он должен содержать дополнительные управляющие коды, которые переключат систему в ASCII-режим в конце кодировочного слова.
Когда имеется возможность использования более одного символьного набора для представления текста в кодировочном слове и в отсутствии частного соглашения между отправителем и получателем сообщения, рекомендуется, чтобы предпочтительно использовались члены символьного семейства ISO-8859-*.
Синхронизация
При отсоединении от PDP, PEP должен перейти к принятию локальных решений. При восстановлении соединения PEP информирует PDP обо всех событиях, которые произошли под локальным управлением. Кроме того, удаленный PDP может потребовать, чтобы внутренние состояния всех PEP были заново синхронизованы (все ранее поступившие запросы были заново посланы) путем передачи сообщения синхронизации состояний (Synchronize State).
После неудачи и до полного установления нового соединения, ухудшение сервиса может быть минимизировано, если PEP кэширует переданные ранее решения и продолжает использовать их в течение некоторого времени.
PEP, который кэширует состояние предыдущего обмена PDP, должен сообщить о факте разрыва соединения любому PDP, с которым он может восстановить соединение. Это выполняется путем включения адреса и номера TCP-порта последнего PDP, для которого PEP кэширует состояние в сообщении Client-Open. Объект <LastPDPAddr> будет включен для последнего PDP, с которым PEP был полностью синхронизован. Если прерывание обслуживания было временным и PDP все еще содержит полное состояние для PEP, PDP может выбрать вариант, когда не все состояния синхронизованы. PEP ответственен за актуализацию всех состояний PDP, которые изменились за время прерывания обслуживания. Если PEP выходит из строя и теряет все кэшированные состояния для некоторого типа клиента, он просто не включает <LastPDPAddr> в свое сообщение Client-Open.
Синтаксис кодированных слов (encoded-words)
'Кодировочное слово' определено согласно следующей ABNF-грамматике. Используется нотация RFC-822, за исключением того, что символы “white space” (HT и SP) не должны появляться между компонентами кодировочного слова.
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
| charset = token | ; см. секцию 3 |
| encoding = token | ; см. секцию 4 |
token = 1*
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "="
encoded-text = 1*<Любой печатный ASCII-символ, отличный от "?" или пробела (SP)>
| ; (см. "Использование encoded-words в заголовках сообщений", часть 5) |
Слова 'encoding' и 'charset' не зависят от регистра, в котором напечатаны. Таким образом символьный набор с именем "ISO-8859-1" эквивалентен "ISO-8859-1", а кодирование с именем "Q" может записываться как "Q" или "q".
'Кодировочное слово' (encoded-word) не может быть длиннее 75 символов, включая 'charset', 'encoding', 'encoded-text' и разделители. Если желательно закодировать текст больший, чем 75 символов, можно использовать несколько кодировочных слов, разделенных CRLF SP.
Хотя ограничений на длину многострочного поля заголовка, каждая строка поля заголовка, которая содержит одно или более кодировочных слов, ограничена 76 символами.
Ограничения длины введены, для того чтобы облегчить сетевое взаимодействие различных почтовых шлюзов и упростить работу программ разборки кодировочных слов.
'Кодировочные слова' сконструированы так, чтобы быть узнаваемыми как “атомы” программой грамматического разбора RFC-822. Как следствие, незакодированные символы SP и HT в пределах кодировочных слов запрещены. Например, символьная последовательность
=?iso-8859-1?q?this is some text?=
будет воспринята программой разборки RFC-822 как четыре атома, а не как один атом, или как ''кодировочное слово” (в случае программы разборки, воспринимающей кодировочные слова). Правильный способ закодировать строку "this is some text" - это кодировать и сами пробелы, например:
=?iso-8859-1?q?this=20is=20some=20text?=
Систематика IP-мульткаст LSP триггеров
Формирование LSP для мультикаст-потоков может быть запущено различными событиями (триггерами), которые могут быть отнесены к следующим стандартным категориям запуск запросом, запуск топологией и запуск трафиком. Запуск запросом: перехватывает отправку или получение управляющих сообщений (например, мультикастные маршрутные сообщения, сообщения резервирования ресурсов).Запуск топологией: устанавливает соответствие между деревом уровня L3, которое имеется в мультикастной таблице маршрутизации, и деревом L2. Установление соответствия осуществляется даже при отсутствии трафика.Запуск трафиком: устанавливается соответствие между деревом L3 и деревом L2 тогда , когда поступают данные.
Систематика мултикастных IP протоколов маршрутизации в контексте MPLS
В настоящее время предложено и разрабатывается много мультикастинг протоколов маршрутизации. Все эти протоколы имеют различные характеристики (масштабируемость, вычислительную сложность, задержку, избыточность сообщений управления, тип дерева и т.д.). Целью данного документа не является осуществление исчерпывающей систематики мультикастинг протоколов маршрутизации, а только рассмотрение их характеристик, имеющих отношение к технологии MPLS. Рассматриваются следующие характеристики:
- Агрегатирование
- Широкая рассылка и отсекание ветвей (Flood &Prune)
- Деревья с общим отправителем
- Сосуществование деревьев отправителя и совмещенных деревьев
- Одно и двунаправленные совмещенные деревья
- Инкапсулированные мультикастинг-данные
- Отсутствие петель
Обсуждение этих характеристик не ставит задачу выбора единственного наилучшего мультикастинг протокола маршрутизации. Вполне возможно, что для целей мультикастинга в Интернет будут использованы различные протоколы маршрутизации.
Смешанная переадресация L2/L3 в отдельном узле
Так как уникастный трафик имеет один входной и один выходной интерфейс, трафик переадресуется либо на уровне L2, либо на уровне L3 (Рис. 6). Так как мультикастный трафик может переадресовываться более чем через один выходной интерфейс, можно считать, что трафик в некоторых ветвях переадресуется на уровне L2, а в других на уровне L3 (Рис. 7).
Рис. 6. Уникастная переадресация на уровне L3 или L2
Рис. 7. Мультикастная переадресация на уровне L3, смешанном L2/L3 или L2
Узлы, которые поддерживают эту возможность смешанной переадресации L2/L3, позволяют расщеплять мультикастное дерево на ветви, с переадресацией L3 и L2.
Переадресация L3 должна заботится о том, чтобы трафик не переадресовывался в ветви, которые уже получили свой трафик L2. Это может быть осуществлено, например, добавлением специального бита в записи мультикастинг таблицы маршрутизации.
Хотя смешанная L2/L3-переадресация требует обработки трафика на уровне L3, нагрузка на устройство переадресации L3 обычно меньше, чем в случае узла исключительно уровня L3. Поддержка этой смешенной переадресации L2/L3 имеет следующие преимущества:
a) Пусть LSR A (Рис. 8) является оконечным узлом для ветви к LSR B и узлом ветвления для LSR C. Смешанная переадресация L2/L3 допускает, чтобы ветвь к C не загружалась проблемой возврата на уровень L3 в LSR A
Рис. 8. Смешанная L2/L3-переадресация в узле A
b) Допускает использование триггера, управляемого трафиком, с режимом рассылки меток Downstream Usolicited или Upstream on Demand, как это объяснено в разделе 5.3.1.
Содержимое сообщения
Объект Integrity, если он включен, должен всегда быть последним объектом сообщения. Если необходимо обеспечить безопасность, а полученное сообщение не содержит корректного объекта Integrity, получатель должен послать сообщение Client-Close для Client-Type=0, определяющее соответствующий код ошибки.
Согласование
Программа, формирующая почтовое сообщение и соответствующая данной спецификации, должна гарантировать, что любая строка печатных ASCII-символов, не содержащая HT и SP в пределах '*text' или '*ctext', начинается с "=?" и завершается "?=" является корректным 'кодировочным словом'. ("Начинается" означает: в начале тела сразу после LWS, или сразу после "(" для 'кодировочного слова' в пределах '*ctext'; "завершается" означает: в конце тела, непосредственно перед LWS, или непосредственно перед ")" для 'кодировочного слова' в '*ctext'.) Кроме того, любое 'слово' в 'фразе', которое начинается с "=?" и завершается "?=" должно быть корректным 'кодировочным словом'.
Программа, читающая почтовые сообщения, совместимые с данной спецификацией должна быть способна отделить 'кодировочное слово' от 'text', 'ctext', или 'слов', которые согласуются с правилами секции 6, где бы они не встретились в заголовке сообщения. Она должна поддерживать "B"- и "Q"-кодирование для любых символьных наборов, которые она поддерживает. Программа должна быть способна отобразить не кодированный текст, если символьный набор соответствует "US-ASCII". Для символьных наборов ISO-8859-*, программа должна быть способна, по крайней мере, отобразить символы, которые совпадают с ASCII.
Соображения безопасности
Протокол COPS предоставляет объект Integrity, который может обеспечить аутентификацию, целостность сообщения, и предотвратить подмену с использованием записи предыдущих сообщений. Все реализации COPS должны поддерживать работу с объектом COPS Integrity. Чтобы гарантировать, что клиент (PEP) обменивается с корректным сервером политики (PDP), необходима аутентификация PEP и PDP, с использованием общего ключа (secret), и согласованная проверка того, что соединение является корректным. Ключ используется в сочетании с содержимым сообщения COPS, чтобы вычислить дайджест сообщения, который является частью объекта Integrity. Объект Integrity затем используется для проверки всех сообщений COPS, посланных через TCP-соединение между PEP и PDP.
Объект COPS Integrity предоставляет также порядковый номер, чтобы исключить атаки откликов. PDP выбирает начальный порядковый номер для PEP, а PEP выбирает начальный порядковый номер для PDP. Эти начальные номера затем инкрементируются каждым последующим сообщением, пересланным через данное соединение в соответствующем направлении. Исходный порядковый номер должен быть выбран так, чтобы для заданного ключа в процессе монотонного приращения не получалось идентичных номеров.
Безопасность обмена между клиентом (PEP) и сервером (PDP) может быть обеспечена за счет IP Security [IPSEC]. В этом случае, заголовок аутентификации IPSEC (AH) должен использоваться для проверки правильности соединения; кроме того, безопасное поле данных IPSEC ESP (Encapsulation Security Payload) может использоваться для реализации, как безопасности, так и конфиденциальности.
TLS [Transport Layer Security] может использоваться, как для обеспечения соединения, так и для гарантии конфиденциальности.
Тип клиента идентифицирует Client-type приложения, к которому относится сообщение. Значения типа клиента в диапазоне 0x0001-0x3FFF зарезервированы для статуса необходимой спецификации (Specification Required), как это определено [IANA-CONSIDERATIONS]. Эти значения должны быть зарегистрированы IANA и их поведение и применимость должны быть описана в документе расширения COPS.
Значения типа клиента (Client-type) в диапазоне 0x4000 - 0x7FFF зарезервированы для частного использования, как это определено в [IANA-CONSIDERATIONS].
Значения типа клиента в диапазоне 0x8000 - 0xFFFF относятся к типу "первым пришел - первым обслужен", как это определено в [IANA-CONSIDERATIONS].
Некоторые маршрутизаторы могут реализовать безопасные процедуры, которые зависят от заголовка сетевого уровня, положение которого фиксировано по отношению к заголовку канального уровня. Базовая инкапсуляция MPLS подразумевает введение прослойки между заголовком канального и сетевого уровня. Это может вызвать отказ в работе некоторых процедур безопасности. Метка MPLS имеет свое значение благодаря соглашению между LSR, который записывает метку в стек (источник метки), и LSR, который интерпретирует метку (получатель метки). Если помеченный пакет получен от непроверенного отправителя, или если некоторая метка получена от LSR, которому она не посылалась, тогда пакеты могут маршрутизоваться некорректным образом.
В этом разделе идентифицируются угрозы, к которым LDP может быть чувствителен и обсуждаются средства, которые могут уменьшить эти угрозы.
На практике эти расширения RSVP не предлагают никакой безопасности в дополнение к RFC 2205 [1]. Однако имеется небольшое изменение в доверительной модели. Трафик обычной RSVP сессии может быть отфильтрован по адресам отправителя и получателя, а также по номерам портов. В этой спецификации, отбор происходит только на основе входных меток. По этой причине администрация может пожелать ограничить область, где могут прокладываться LSP-туннели. Это может быть выполнено путем фильтрации по разным портам, чтобы препятствовать воздействию на сообщение RSVP path со стороны объекта SESSION типа LSP_TUNNEL_IPv4 (7) или LSP_TUNNEL_IPv6 (8).
В данном документе не вводится никаких дополнительных мер безопасности за исключением рассмотренных в [RFC3212] или [RFC3209]. Соображения безопасности, упомянутые в [RFC3212] или [RFC3209], относятся к специфическим протокольным формам GMPLS, смотри [RFC3473] и [RFC3472].
Безопасность сообщения RSVP описана в [RFC2747] и обеспечивает целостность сообщения и аутентификацию узла. Для сообщений, передаваемых шаг-за-шагом, в данном документе не предлагается новых возможностей.
В данном документе вводится возможность посылки сообщения уведомления (Notify) вне схемы шаг-за-шагом. Это мешает реализовать модель целостности и аутентификации RSVP. В случае, когда RSVP генерирует сообщения из-конца-в-конец и желательна безопасность, предоставляемая [RFC2747], можно использовать стандарт IPSEC. При использовании IPSEC для обеспечения аутентификации сообщений применяется следующее:
Селекторы
Селектор идентифицирован RSVP сообщениями, которыми обмениваются узлы, не являющиеся смежными. Узлы идентифицируются IP-адресами отправителя и получателя, используемыми в сообщениях Notify.
Режим
Передаваемая информация, как правило, не является конфиденциальной, поэтому шифрование необязательно. Можно использовать AH [RFC2402] или ESP [RFC2406]. Если используется ESP, IP-адрес отправителя должен быть сравнен с адресом, используемым при управлении ключевым обменом.
Управление ключами
Чтобы разрешить детектирование откликов, должна использоваться автоматическая система управления ключами, такая как IKE [RFC2409]. Могут использоваться конфигурируемые ключи.
Политика безопасности
Сообщения не должны восприниматься, если они посланы неизвестными узлами.
Идентификация
Механизмы общих ключей должны быть адекватны исходным установкам для небольших сетей. Для крупномасштабных систем следует применять IKE, базирующуюся на сертификатах. Какая бы система не использовалась, она должна каким-то образом быть привязана к IP-адресу отправителя.
Доступность
Многие маршрутизаторы и переключатели поддерживают IPSEC. Для случаев, когда IPSEC недоступна, а безопасность необходима, следует посылать сообщения Notify по схеме шаг-за-шагом.
Соображения IANA
LDP определяет следующие пространства имен, которые требуют управления:
Пространство имен типа сообщения
Пространство имен типа TLV
Пространство имен типа FEC
Пространство имен статусных кодов
Пространство имен экспериментальных ID.
IANA присвоила значения протокольным параметрам RSVP. В данном документе определены объекты EXPLICIT_ROUTE и ROUTE_RECORD. Каждый из этих объектов содержит субобъекты. В этом разделе определены правила присвоения кодов субобъектам. Здесь используется терминология BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [15].
Тип субобъекта EXPLICIT_ROUTE
Тип субобъекта EXPLICIT_ROUTE является 7-битовым числом, которое идентифицирует функцию субобъекта. Ограничений на диапазон не накладывается. Могут быть присвоены любые доступные значения.
Следующие разновидности политики рассмотрены в [15], типы субобъектов в диапазоне 0 - 63 (0x00 - 0x3F) присвоены в результате консенсуса IETF, коды в диапазоне 64 - 95 (0x40 - 0x5F) выделены для типов субобъектов “первым пришел - первым обслужен”, а коды в диапазоне 96 - 127 (0x60 - 0x7F) зарезервированы для частного применения.
Тип субобъекта ROUTE_RECORD
Тип субобъекта ROUTE_RECORD является 8-битовым числом, которое идентифицирует функцию субобъекта. Ограничений на диапазон не накладывается. Могут быть присвоены любые доступные значения.
Следующие разновидности политики рассмотрены в [15], типы субобъектов в диапазоне 0 - 127 (0x00 - 0x7F) присвоены в результате консенсуса IETF, коды в диапазоне 128 - 191 (0x80 - 0xBF) выделены для типов субобъектов “первым пришел - первым обслужен”, и диапазон кодов 192 - 255 (0xC0 - 0xFF) зарезервирован для частного применения. В данном документе сделаны следующие присвоения.
IANA ответственна за присвоения новых значений для пространства имен, определенных в этом документе. В этом разделе используется терминология [BCP26].
В данном документе определены следующие наборы имен:
Тип кодирования LSP: 8 бит
Тип коммутации:8 бит
Обобщенный PID (G-PID): 16 бит
Действие: 8 бит
Тип Interface_ID :16 бит
Тип кодирования LSP - допустимый диапазон 1-255. В данном документе определены значения 1-11.
Тип коммутации - допустимый диапазон 1-255. В данном документе определены значения 1-4, 100, 150 и 200.
Обобщенный PID (G-PID) - допустимый диапазон 0-1500. В данном документе определены значения 0-46.
Действие - допустимый диапазон 0-255. В данном документе определены значения 0-3.
Тип Interface_ID - допустимый диапазон 1-65535. В данном документе определены значения 1-5.
IANA присваивает значения протокольным параметрам RSVP. В пределах данного документа определено несколько объектов. Каждый из этих объектов содержит C-тип. В этом разделе определены правила присвоения значений C-типа. В этом разделе используется терминология BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].
Согласно [RFC2205], C-тип представляет собой 8-битовое число, которое идентифицирует функцию объекта. Приемлемы все возможные величины за исключением нуля.
Присвоение значений C-типа объектам, определенное в данном документе, делится на три категории. Первая категория наследует C-типы из объекта метки, т.e., номер класса объекта 16 [RFC3209]. Задача IANA ввести политику, в соответствии с которой все значения C-типа, присвоенные объектам метка, присвоены также следующим объектам:
Suggested_Label (Class-Num 129)
Upstream_Label (Class-Num 35)
Recovery_Label (Class-Num 34)
Вторая категория объектов следует независимой политике. В частности, следующие виды политики рассмотрены в [BCP26], значения C-типа в диапазоне 0x00 - 0x3F выделяются по согласованию с IETF, значения из диапазона 00x40 - 0x5F выделяются по принципу “первым пришел - первым обслужен”, а значения из диапазона 0x60 - 0x7F зарезервированы для частного использования. Эта политика применима к следующим объектам.
Label_Set (Class-Num 36)
Notify_Request (Class-Num 195)
Protection (Class-Num 37)
Admin Status (Class-Num 196)
Restart_Cap (Class-Num 131)
Присвоение значений C-типа для остающегося объекта Acceptable_Label_Set, следует правилам присвоения значений C-типа объекта Label_Set. IANA устанавливает политику, в соответствии с которой все значения C-типа, присвоенные для объекта Label_Set, присвоены также и для объекта Acceptable_Label_Set.
Соображения по поводу многоканальности
Как отмечалось ранее, расширение Hello имеет целью детектирование отказов узлов. Когда между соседними узлами имеется только один канал или когда все каналы между узлами отказали, отличие между отказами узла и канала не играют большой роли и обработка таких отказов уже рассмотрена. Когда между соседями имеется несколько каналов, нужно рассмотреть дополнительные обстоятельства. Когда каналы между соседями пронумерованы, тогда Hello должны быть посланы по всем каналам и далее применен алгоритм, рассмотренный выше.
Когда каналы ненумерованы, для детектирования отказов каналов нужно привлечь некоторые дополнительные средства помимо Hello. Каждый узел должен использовать один обмен Hello с соседом. Случай, когда все каналы отказали, эквивалентен варианту неполучения никаких данных, рассмотренному в предыдущем разделе.
Соображения совместимости
Легко видеть, что некоторые пятерки не образуют жизнеспособных схем MPLS. Например:
- <PulledUnconditional, RequestNever, *, *, *>
<PulledConditional, RequestNever, *, *, *>
В этих схемах MPLS, нижестоящий LSR Rd пересылает ассоциации меток вышестоящему LSR Ru только по запросу от Ru, но Ru никогда не делает таких запросов. Очевидно, эти схемы нежизнеспособны, так как они не способны осуществлять корректную рассылку ассоциаций меток.
- <*, RequestNever, *, *, ReleaseOnChange>
В этих схемах MPLS, Rd аннулирует ассоциации, если он их не использует, но он никогда не запрашивает их снова, даже если они ему позднее понадобятся. Эти схемы, таким образом, не гарантируют того, что ассоциации меток будут разосланы корректно.
В этом разделе специфицируются правила предотвращения того, чтобы партнеры по рассылке меток выбирали процедуры, которые ведут к недопустимым схемам MPLS. Эти правила требуют либо обмена информацией между партнерами по рассылке меток во время инициализации системы, либо априорного знания (полученного каким-то методом, который находится за пределами рассмотрения данного документа).
1. Каждый субъект должен объявить, поддерживает ли он объединение меток.
2. Если Rd не поддерживает объединение меток, Rd должен выбрать либо процедуру PulledUnconditional, либо PulledConditional. Если Rd выбирает PulledConditional, Ru вынужден использовать процедуру RequestRetry.
То есть, если нижестоящий LSR не поддерживает объединения меток, его предпочтения имеют приоритет, при выборе схем MPLS.
3. Если Ru не поддерживает объединение меток, а Rd поддерживает, Ru должен выбрать процедуру RequestRetry или RequestNoRetry. Это вынуждает Rd использовать соответственно процедуру PulledConditional или PulledUnConditional.
То есть, если только один из LSR не поддерживает объединение меток, его предпочтения имеют приоритет, при выборе схем MPLS.
4. Если как Ru, так и Rd поддерживают объединение меток, тогда выбор между свободным и консервативным режимами удержания меток остается за Ru. То есть, Ru предоставляется выбрать либо использование RequestWhenNeeded/ReleaseOnChange (консервативный), или использовать RequestNever/NoReleaseOnChange (свободный). Однако, выбор push либо pull и "условный" либо "безусловный" принадлежит Rd. Если Ru выбирает свободный режим удержания меток, Rd может выбрать либо PushUnconditional, либо PushConditional. Если Ru выбирает консервативный режим удержания меток, Rd может выбрать PushConditional, PulledConditional или PulledUnconditional. Такой выбор определяет использование схемы MPLS .
Сообщение Address
LSR посылает сообщение Address партнеру LDP, чтобы анонсировать его адреса интерфейсов. Кодирование сообщения Address представлено ниже:
ID сообщения
32-битовый код идентифицирующий это сообщение.
TLV списка адресов
Список адресов интерфейсов, анонсированных LSR-отправителем. Кодирование TLV списка адресов описано в разделе " TLV списка адресов".
Опционные параметры
Для сообщения адреса опционные параметры не предусмотрены.
Сообщение анонсирования (Notification Message)
Формат сообщения анонсирования метки отображен ниже на рис. 16, это сообщение содержит опционное поле Diff-Serv TLV:
Рис. 16.
Сообщение ассоциации метки
Формат сообщения установления соответствия метки изображен ниже на рис. 14, такое сообщение имеет опционное поле Diff-Serv TLV:
Рис. 14.
Сообщение DHCPDECLINE
Если сервер получает сообщение DHCPDECLINE, клиент каким-то образом обнаружил, что предлагаемый сетевой адрес уже используется. Сервер должен пометить сетевой адрес как недоступный и уведомить администратора системы о возможной конфигурационной проблеме.
Сообщение DHCPINFORM
Сервер реагирует на сообщение DHCPINFORM посылкой сообщения DHCPACK непосредственно по адресу, записанному в поле 'ciaddr' сообщения DHCPINFORM. Сервер не должен уведомлять клиента об истечении времени действия конфигурационного набора и не должен производить запись в 'yiaddr'. Сервер включает в сообщение DHCPACK другие параметры, как это определено в разделе 4.3.1.
Сообщение DHCPRELEASE
При получении сообщения DHCPRELEASE, сервер помечает сетевой адрес, как не присвоенный. Сервер должен хранить запись с конфигурационными параметрами клиента для возможного последующего использования при поступлении соответствующего запроса.
Если клиент более не нуждается в использовании своего сетевого адреса (например, клиент завершил работу через shutdown), клиент посылает серверу сообщение DHCPRELEASE. Заметим, что корректная работа DHCP не зависит от передачи сообщений DHCPRELEASE.
Сообщение DHCPREQUEST
Сообщение DHCPREQUEST может прийти от клиента, реагирующего на сообщение сервера DHCPOFFER, от клиента, верифицирующего ранее выделенный IP-адрес, или от клиента, расширяющего время действия конфигурационного набора. Если сообщение DHCPREQUEST содержит опцию 'server identifier', то это отклик на сообщение DHCPOFFER. В противном случае, сообщение является запросом верификации или расширения времени действия набора. Если клиент использует 'client identifier' в сообщении DHCPREQUEST, он должен использовать его во всех последующих сообщениях. Если клиент включил список запрашиваемых параметров в сообщение DHCPDISCOVER, он должен включить этот список во все последующие сообщения. Любые конфигурационные параметры в сообщении DHCPACK не должны конфликтовать с полученными ранее в сообщении DHCPOFFER. Клиент должен использовать для конфигурации параметры из сообщения DHCPACK. Клиенты посылают сообщения DHCPREQUEST следующим образом:
o DHCPREQUEST, сформированный в состоянии SELECTING:
Клиент вводит адрес выбранного сервера 'server identifier', 'ciaddr' должен быть равен нулю, в ‘запрошенный IP-адрес' должно быть записано значение yiaddr, взятое из DHCPOFFER.
Заметим, что клиент может собрать несколько сообщений DHCPOFFER и выбрать наилучшее предложение. Клиент определяет свой выбор путем идентификации сервера в сообщении DHCPREQUEST. Если клиент получает неприемлемые предложения, клиент может попробовать другое сообщение DHCPDISCOVER. Следовательно, серверы не могут получить DHCPREQUEST, из которого они могли бы решить, принял ли клиент данное предложение. Так как серверы не осуществили присвоение какого-либо сетевого адреса на основе DHCPOFFER, они вольны повторно использовать предложенные сетевые адреса в откликах на последующие запросы. Серверы не должны повторно использовать предложенные адреса и могут реализовать зависимый от реализации механизм таймаутов в процессе принятия решения о повторном использовании предложенных адресов.
o DHCPREQUEST генерируется в состоянии INIT-REBOOT:
Поле 'server identifier' не должно быть заполнено, в опции 'Запрошенный IP-адрес' должен быть записан предшествующий адрес, присвоенный клиенту. 'ciaddr' должен быть равен нулю. Клиент пытается верифицировать присвоенный ранее конфигурационный набор. Сервер должен клиенту послать сообщение DHCPNAK, если ‘запрошенный IP-адрес’ не корректен, или относится к неверной сети.
Определение того, находится ли клиент в состоянии INIT-REBOOT, осуществляется просмотром содержимого 'giaddr', опции 'requested IP-адрес', и базы данных. Если DHCP-сервер обнаружит, что клиент находится не в той сети (т.e., результат наложения локальной маски субсети или маски удаленной субсети (если 'giaddr' не равно нулю) на опцию 'запрошенный IP-адрес' выдает не реальный результат), тогда сервер должен послать клиенту сообщение DHCPNAK. Если с сетью все в порядке, тогда DHCP-сервер должен проверить, корректна ли запись клиента о его IP-адресе. Если нет, сервер должен послать клиенту сообщение DHCPNAK. Если DHCP-сервер не имеет записи об этом клиенте, тогда он должен оставаться пассивным, и может выдать предупреждение сетевому администратору.
Если 'giaddr' в сообщении DHCPREQUEST равен 0x0, клиент находится в той же субсети, что и сервер. Сервер должен широковещательно послать сообщение DHCPNAK по адресу 0xffffffff, так как клиент не может иметь корректный сетевой адрес или сетевую маску, и клиент не может откликаться на ARP-запросы.
Если в сообщении DHCPREQUEST установлен 'giaddr', клиент находится в другой субсети. Сервер должен установить широковещательный бит в DHCPNAK, агент отклика пошлет клиенту сообщение DHCPNAK широковещательно, так как клиент может не иметь корректного сетевого адреса или сетевой маски, и клиент может не откликаться на ARP-запросы.
o DHCPREQUEST генерируется в состоянии RENEWING:
'server identifier' не должен быть заполнен, опция 'запрошенный IP-адрес' не должна быть заполнена, в 'ciaddr' должен быть записан IP-адрес клиента. В этой ситуации, клиент полностью сконфигурирован, и пытается расширить срок действия конфигурационного набора. Это сообщение будет послано по уникастному адресу, таким образом, в обмен не будет вовлечено никаких агентов транспортировки. Так как 'giaddr' не заполнен, DHCP-сервер будет полагаться на значениеn 'ciaddr', и использовать его при передаче данных клиенту.
Клиент может пожелать обновить или расширить время действия конфигурационного набора до T1. Сервер может пожелать не расширять время действия (например, по решению сетевого администратора), но должен в любом случае откликнуться сообщением DHCPACK.
o DHCPREQUEST генерируется в состоянии REBINDING:
'server identifier' не должен быть заполнен, опция 'запрошенный IP-адрес' не должна быть заполнена, в 'ciaddr' должен быть записан IP-адрес клиента. В этой ситуации, клиент полностью сконфигурирован, и пытается увеличить время действия набора параметров. Это сообщение должно быть передано широковещательно по IP-адресу 0xffffffff. DHCP-сервер должен проверить корректность 'ciaddr' прежде чем откликаться на DHCPREQUEST. DHCPREQUEST от клиента в состоянии REBINDING имеет целью согласовать узлы, имеющие несколько DHCP-серверов, а также предложить механизм для согласования времен действия конфигурационных наборов, предлагаемых разными серверами. DHCP-сервер может расширить время действия набора параметров клиента, только если он имеет для этого административные привилегии.
Сообщение Hello
Обмен сообщениями LDP Hello является частью механизма выявления LDP; смотри раздел "Выявление LDP". Формат представления сообщений Hello отображен ниже:
ID сообщения
32-битовый код, используемый для идентификации этого сообщения.
Общие параметры TLV Hello
Специфицирует параметры общие для всех сообщений Hello. Формат представления TLV для общих параметров Hello отображен ниже:
Время удержания (Hold Time).
Время удержания Hello в секундах. LSR сохраняет записи Hello, полученные от потенциальных партнеров (смотри раздел "Процедуры сообщения Hello"). Время удержания Hello специфицирует время, в течение которого LSR-отправитель будет сохранять записи Hello от LSR-получателей, без получения других Hello.
Пара LSR согласует времена удержания, которые они используют для Hello, полученных от партера. Каждый предлагает свое время удержания. Используемое время удержание равно минимуму из предложенных значений в сообщениях Hello.
Значение 0 означает использование значения по умолчанию, которое равно 15 секундам для канальных Hello и 45 секунд для целевых Hello. Значение 0xffff означает бесконечность.
T, целевое Hello
Значение 1 указывает на то, что это целевое Hello. Значение 0 означает, что данное сообщение является канальным Hello.
R, Посылка целевых Hello по запросу
Значение 1 требует от получателя периодической посылки отправителю сообщений целевого Hello. Значение 0 не предполагает никаких действий.
LSR, инициализирующий расширенное выявление устанавливает R=1. Если R=1, принимающий LSR проверяет, был ли он сконфигурирован посылать целевые Hello в ответ на Hello отправителя. Если нет, то он игнорирует запрос. Если да, то он начинает периодически передавать целевые Hello отправителю такого Hello.
Зарезервировано
Это поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при приеме.
Опционные параметры
Это поле переменной длины содержит нуль или более параметров, каждый из которых закодирован в формате TLV. Опционные параметры определенные данной версией протокола перечислены ниже.
| Транспортный адрес IPv4 | 0x0401 | 4 | Смотри ниже | |||
| Последовательный номер конфигурации | 0x0402 | 4 | Смотри ниже | |||
| Транспортный адрес IPv6 | 0x0403 | 16 | Смотри ниже |
Транспортный адрес IPv4
Специфицирует адрес IPv4, который следует использовать для посылки LSR, при открытии сессии LDP через TCP-соединение. Если этот опционный TLV отсутствует, следует использовать адрес отправителя IPv4 из UDP-пакетов, несущих сообщение Hello.
Последовательный номер конфигурации
Специфицирует 4-октетное число без знака, которое является последовательным номером конфигурации LSR-отправителя. Используется принимающим LSR, чтобы определить изменения конфигурации LSR отправителя.
Транспортный адрес IPv6
Специфицирует адрес IPv6, который следует использовать для посылки LSR, при открытии сессии LDP через TCP-соединение. Если этот опционный TLV отсутствует, следует использовать адрес отправителя IPv6 из UDP-пакетов, несущих сообщение Hello.
Сообщение инициализации
Обмен сообщениями инициализации LDP является частью процедуры установления сессии LDP; смотри раздел "Установление сессии LDP ".
Формат сообщения инициализации представлен ниже:
ID сообщения
32-битовый код, используемый для идентификации этого сообщения.
TLV общих параметров сессии
Специфицирует значения, предлагаемые LSR-отправителем для параметров, которые должны быть согласованы для каждой сессии LDP.
Кодирование TLV общих параметров сессии рассмотрено ниже:
Версия протокола
Двухоктетное целое число без знака, содержащее номер версии протокола. В данном документе специфицируется версия LDP 1.
Время KeepAlive
Двухоктетное, неравное нулю целое число без знака, которое определяет число секунд, которое LSR-отправитель предлагает в качестве значения времени KeepAlive. LSR-получатель должен вычислить значение для таймера KeepAlive, используя меньшее из предложенных значений KeepAlive. Выбранное значение для времени KeepAlive указывает максимальное число секунд, которое может пройти между получением последовательных PDU от партнера LDP через TCP-соединение. Таймер KeepAlive сбрасывается при каждом приходе PDU.
A, порядок анонсирования меток
Индицирует тип анонсирования меток. A=0 означает анонсирование Downstream Unsolicited; значение = 1 означает Downstream On Demand.
Если один LSR предлагает Downstream Unsolicited, а другой предлагает Downstream on Demand, правила разрешения конфликта заключаются в следующем:
Если сессия сформирована для ATM или Frame Relay с коммутацией по меткам, тогда должен использоваться режим Downstream on Demand.
В противном случае, должен использоваться режим Downstream Unsolicited.
Если порядок анонсирования определенный таким способом для LSR не приемлем, он в ответ на сообщение инициализации должен послать сообщение уведомления о том, что режим анонсирования сессии отвергнут, сессия при этом не устанавливается.
D, детектирование петель
Индицирует, активизировано ли детектирование петель в векторе пути. Значение 0 означает, что детектирование петель заблокировано; значение 1 означает, что детектирование петель активизировано.
PVLim, ограничение вектора пути
Конфигурируемая максимальная длина вектора пути. Должна равняться 0, если детектирование петель блокировано (D=0). Если процедуры детектирования петель потребуют от LSR посылки вектора пути, длина которого превышает это ограничение, LSR будет себя вести, как если бы для заданного FEC была детектирована петля.
Когда детектирование петель в части сети активировано, рекомендуется, чтобы все LSR в этой части сети были сконфигурированы с одним и тем же ограничением на длину вектора пути. Хотя знание ограничения на длину вектора пути партнера не изменяет поведения LSR, это позволяет ему предупредить оператора о возможной ошибке в конфигурации.
Резерв
Это резервное поле. Оно должно содержать нуль при передаче и игнорироваться при приеме.
Макс. длина PDU
Двухоктетное целое без знака, которое предлагает максимально допустимую длину LDP PDU сессии. Значение 255 или меньше специфицирует максимальную длину по умолчанию 4096 октетов.
LSR-приемник должен вычислить максимальную длину PDU для сессии, взяв минимальное из своего значения и предложения партнера. Значение по умолчанию для максимальной длины PDU, использованное до инициализации сессии более не работает.
Если максимальная длина PDU, определенная таким путем, неприемлема для LSR, он должен послать в ответ на сообщение инициализации уведомление о конфликте со значением длины PDU (Session Rejected/Parameters Max PDU Length) и не устанавливать сессию.
Идентификатор LDP получателя
Идентифицирует пространство меток получателя. Этот идентификатор LDP, совместно с идентификатором отправителя в заголовке PDU позволяет получателю согласовать сообщение инициализации с одной из его сопредельностей Hello; смотри раздел "Процедуры сообщения Hello".
Если приемлемых сопредельностей Hello нет, LSR должен послать в ответ на сообщение инициализации сообщение уведомления “Session Rejected/No Hello” и не устанавливать сессию.
Опционные параметры
Это поле переменной длины содержит нуль или более параметров, каждый из которых закодирован согласно формату TLV. Опционными параметрами являются:
| Параметры сессии ATM | 0x0501 | переменная | Смотри ниже |
| Параметры сессии Frame Relay | 0x0502 | переменная | Смотри ниже |
Параметры сессии ATM
Используется, когда сессия LDP управляет обменом меток для АТМ-канала, для задания специфических параметров ATM-сессии.
M, возможности объединения в ATM
Специфицирует объединение возможностей коммутаторов ATM. В данной спецификации поддерживаются следующие значения:
| 0 | Объединение не поддерживается |
| 1 | Поддерживается объединение VP |
| 2 | Поддерживается объединение VC |
| 3 | Поддерживается объединение VP & VC |
необъединяющие и VC-объединяющие LSR могут легко работать совместно.
Совместная работа коммутаторов, допускающих объединение VP с коммутаторами, не поддерживающими объединение VP является объектом будущего изучения. Когда LSR отличаются по использованию объединения VP, сессия устанавливается, но объединение VP не используется.
Заметим, что если объединение VP используется, входной узел несет ответственность за уникальность выбора VCI в домене LSR (смотри [ATM-VP]).
N, число компонент диапазона меток
Определяет число компонент диапазона меток ATM, включенных в TLV.
D, использование VC по направлениям
Значение 0 специфицирует двунаправленную способность VC, что означает способность LSR (в пределах данного VPI) поддерживать использование этого VCI в качестве метки для обмена через канал в обоих направлениях независимо. Значение 1 определяет однонаправленную способность VC, что означает возможность использования (в пределах данного VPI) заданного VCI для переадресации по меткам только для одного направления канала. Когда один из или оба партнера специфицируют однонаправленную способность, оба LSR используют однонаправленную технику коммутации по меткам. LSR сравнивают свои идентификаторы LDP, как целые числа без знака. LSR с большим идентификатором LDP может присваивать только нечетные значения VCI в диапазоне меток VPI/VCI. Система с меньшим идентификатором LDP может присваивать только четные значения VCI в диапазоне меток VPI/VCI.
Зарезервировано
Это резервное поле. Оно должно содержать нуль при передаче и игнорироваться при приеме.
Один или более компонентов диапазона меток ATM
Список компонентов диапазона меток ATM, которые в совокупности специфицируют диапазон меток, поддерживаемый LSR-отправителем.
LSR-приемник должен вычислить пересечение между приемным диапазоном и своим поддерживаемым диапазоном меток. Пересечение представляет собой диапазон, в котором LSR может присваивать и воспринимать метки. LSR не должны устанавливать сессии с соседом, для которого область пересечения диапазонов равна нулю. В этом случае LSR должен в ответ на сообщение инициализации послать сообщение уведомления “Session Rejected/Parameters Label Range” и не устанавливать сессию.
Формат представления компонента диапазона меток для ATM отображен ниже:
Res
Это резервное поле. Оно должно содержать нуль при передаче и игнорироваться при приеме.
Минимум VPI (12 бит)
Это 12-битное поле специфицирует нижнюю границу блока идентификаторов виртуального пути, который поддерживается на исходном коммутаторе. Если VPI меньше 12-бит он должен быть выровнен по правому краю, освободившиеся левые биты заполняются нулями.
Минимум VCI (16 бит)
Это 16-битное поле специфицирует нижнюю границу блока идентификаторов виртуального пути, который поддерживается исходным коммутатором. Если VCI меньше 16-бит он должен быть выровнен по правому краю, освободившиеся левые биты заполняются нулями.
Максимум VPI(12 бит)
Это 12 битное поле специфицирует верхнюю границу блока идентификаторов виртуального пути, который поддерживается на исходном коммутаторе. Если VPI меньше 12-бит он должен быть выровнен по правому краю, освободившиеся левые биты заполняются нулями.
Максимум VCI (16 бит)
Это 16 битовое поле специфицирует верхнюю границу блока идентификаторов виртуального соединения, который поддерживается исходным коммутатором. Если VCI меньше 16-бит он должен быть выровнен по правому краю, освободившиеся левые биты заполняются нулями.
Когда партнеры LSR не соединены непосредственно посредством ATM VP, LSR-отправитель должен установить минимум и максимум поля VPI равным 0, а LSR-получатель должен игнорировать минимум и максимум полей VPI.
Спецификации полей компонентов диапазона меток ATM, которые следует использовать VP-объединением LSR, смотри в [ATM-VP].
Параметры сессии Frame Relay
Используются, когда сессия LDP управляет обменом меток для каналов Frame Relay, чтобы задать специфические для Frame Relay параметры сессии.
M, Возможности объединения в Frame Relay
Специфицирует объединительные возможности коммутатора Frame Relay. В данной спецификации поддерживаются следующие значения:
| 0 | Объединение не поддерживается |
| 1 | Объединение поддерживается |
N, число компонентов диапазонов меток
Специфицирует число компонентов диапазонов меток Frame Relay, включенных в TLV.
D, использование VC по направлениям
Значение 0 специфицирует двунаправленную способность VC, что означает способность LSR поддерживать использование данного DLCI в качестве метки для обоих направлений канала независимо. Значение 1 специфицирует однонаправленную возможность VC, означающую, что данное DLCI может появиться только среди меток одного направления канала. Когда один из или оба партнера специфицируют однонаправленную возможность VC, оба LSR используют однонаправленное присвоение VC меток. LSR сравнивают свои идентификаторы LDP как целые числа без знака. LSR с большим идентификатором LDP может присваивать в качестве меток нечетные DLCI. Система с меньшим идентификатором LDP может присваивать в качестве меток только четные DLCI.
Зарезервировано
Это резервное поле. Оно должно содержать нуль при передаче и игнорироваться при приеме.
Один или более компонентов диапазона меток Frame Relay
Список компонентов диапазона меток Frame Relay, который совместно с диапазоном LSR-отправителя специфицирует диапазон меток.
LSR-получатель должен вычислить пересечение между полученным и своим собственным диапазоном меток. Пересечение является диапазоном, в котором LSR может присваивать и воспринимать метки. LSR не должны устанавливать сессию между соседями, для которых область пересечения равна нулю. В этом случае в ответ на сообщение инициализации LSR должен послать уведомление “Session Rejected/Parameters Label Range” и не устанавливать сессию. Формат представления компонента диапазона меток для Frame Relay рассмотрен ниже:
Res
Это резервное поле. Оно должно содержать нуль при передаче и игнорироваться при приеме.
Len
Это поле специфицирует число бит DLCI. Поддерживаются следующие значения:
| Len | Биты DLCI |
| 0 | 10 |
| 2 | 23 |
Минимум DLCI
Это 23-битное поле специфицирует нижнюю границу блока идентификаторов соединения канала данных (DLCI = Data Link Connection Identifier), которая поддерживается исходным коммутатором. DLCI должен быть выровнен в по правому краю поля, а неиспользуемые левые биты заполняются нулями.
Максимум DLCI
Это 23-битовое поле специфицирует верхнюю границу блока идентификаторов соединения канала данных (DLCI), которая поддерживается исходным коммутатором. DLCI должен быть выровнен в по правому краю поля, а неиспользуемые левые биты заполняются нулями.
Заметим, что для сессий, анонсирующих общие метки, нет TLV общих параметров сессии.
Сообщение KeepAlive
LSR посылает сообщения KeepAlive в качестве части механизма, который мониторирует целостность транспортного соединения LDP сессии. Кодирование сообщения KeepAlive представлено ниже:
ID сообщения
32-битовое значение, используемое для идентификации этого сообщения.
Опционные параметры
Для сообщения KeepAlive не определено опционных параметров.
Сообщение освобождения метки (Label Release)
LSR посылает LDP-партеру сообщение освобождения метки, чтобы сигнализировать, что LSR не нуждается в специфической ассоциации FEC-метка, ранее запрошенной и/или анонсированной партнером. Формат сообщения освобождения метки представлен ниже:
ID сообщения
32-битовый код, используемый для идентификации этого сообщения.
TLV FEC
Идентифицирует FEC, для которого была освобождена ассоциация FEC-метка.
Опционные параметры
Это поле переменной длины содержит 0 или более параметров, каждый из которых соответствует формату TLV. Опционными параметрами являются:
| TLV метки | переменная | Смотри ниже |
Кодирование TLV метки можно найти в разделе " TLV метки".
Метка
Если присутствует, это означает, что метка освобождена (процедуры смотри ниже).
Сообщение отзыва адреса (Address Withdraw)
LSR посылает партнеру LDP сообщение отзыва адреса, чтобы отозвать ранее анонсированные адреса интерфейсов. Формат сообщения отзыва адреса представлен ниже:
ID сообщения
32-битовый код, используемый для идентификации этого сообщения.
TLV списка адресов
Список адресов интерфейсов, подлежащих отзыву, для LSR-отправителя. Кодирование TLV списка адресов специфицировано в разделе "TLV списка адресов".
Опционные параметры
Для сообщения адреса опционные параметры пока не предусмотрены.
Сообщение отзыва метки
LSR посылает сообщение отзыва метки партнеру LDP, чтобы сигнализировать о том, что партнер не может продолжать использовать ассоциацию FEC-метка, которую LSR ранее анонсировал. Это разрывает соответствие между FEC и метками. Формат сообщения отзыва метки представлен ниже:
ID сообщения
32-битовый код, используемый для идентификации этого сообщения.
TLV FEC
Идентифицирует FEC, для которого отзывается ассоциация FEC-метка.
Опционные параметры
Это поле переменной длины содержит 0 или более параметров, каждый из которых имеет формат TLV. Опционными параметрами являются:
| TLV метки | переменная | Смотри ниже |
Кодирование TLV метки можно найти в разделе " TLV метки".
Метка
Если присутствует, специфицирует отзываемую метку (процедуры смотри ниже).
Сообщение Path
Сообщение Path имеет следующий формат:
<Сообщение Path> ::=
Сообщение присвоения метки (Label Mapping)
LSR посылает сообщение присвоения метки (Label Mapping) партнеру LDP, чтобы анонсировать ему ассоциацию FEC-метка. Формат сообщения присвоения метки представлен ниже:
ID сообщения
32-битовый код, используемый для идентификации этого сообщения.
FEC TLV
Специфицирует FEC-компонент анонсируемого ансамбля FEC-метка. Смотри раздел "FEC TLV ".
TLV метки
Специфицирует компонент Label ассоциации FEC-метка. Кодирование смотри в разделе "TLV метки".
Опционные параметры
Это поле переменной длины содержит 0 или более параметров, каждый из которых имеет формат TLV. Опционными параметрами являются:
| TLV ID сообщения запроса метки | 4 | Смотри ниже |
| TLV числа шагов | 1 | Смотри ниже |
| TLV вектора пути | переменная | Смотри ниже |
Кодирование TLV числа шагов и вектора пути можно найти в разделе "Кодирование TLV для параметров общего использования".
ID сообщения запроса метки
Если это сообщение присвоения метки является откликом на сообщение запроса метки, оно должно включать опционный параметр Id сообщения запроса.
Число шагов
Специфицирует полное число LSR-шагов вдоль LSP, установленное сообщением Label. В разделе "Процедуры числа шагов " описано, как работать с этим TLV.
Вектор пути
Сообщает LSR список узлов LSP, сформированный сообщением Label. В разделе "Процедуры вектора пути" описано, как обрабатывать этот TLV.
Сообщение присвоения метки (Mapping)
Использование TLV вектора пути и числа шагов в сообщении присвоения метки предоставляет механизм нахождения и ликвидации петлевых LSP. Когда LSR получает от узла следующего шага сообщение выделения метки, сообщение распространяется далее вверх по течению, как это специфицировано ниже, вплоть до входного LSR или пока не будет обнаружена петля.
Правила, которые управляют использованием TLV числа шагов в сообщениях выделения меток, посланных LSR R, когда активизировано детектирование петель, рассмотрены ниже:
R должен включать TLV числа шагов.
Если R является выходным, значение числа шагов должно быть равно 1.
Если сообщение присвоения метки посылается в ответ на сообщение, полученное от соседа выше по течению, число шагов должно быть определено следующим образом:
Если R входит в набор LSR домена, чьи LSR не выполняют декрементацию TTL (напр., область ATM LSR или домен Frame Relay LSR), а партнер выше по течению находится в этой области, R должен сделать число шагов равным 1, прежде чем пересылать сообщение дальше.
В противном случае, R должен инкрементировать число шагов, полученное от соседа, прежде чем пересылать сообщение дальше.
Если сообщение присвоения метки посылается с целью дальнейшей рассылки, число шагов должно быть результатом инкрементации значения, известного R из предыдущих сообщений присвоения меток. Заметим, что это значение числа шагов будет неизвестным, если R не получил сообщения о выделении метки от своего соседа.
Любое сообщение присвоения меток может содержать TLV вектора пути. Правила, которые управляют обязательным использованием TLV вектора пути в сообщениях присвоения меток, посланных LSR R, когда активировано детектирование петель, являются следующими:
Если R является выходным, сообщение выделения метки не обязано содержать TLV вектора пути.
Если R посылает сообщение выделения метки с целью дальнейшей рассылки метки, полученной от вышестоящего соседа, тогда:
Если R может объединять метки и если R не посылал ранее сообщений присвоения метки партнеру выше по течению, тогда он должен включить TLV вектора маршрута.
Если полученное сообщение содержит неизвестное число шагов, тогда R должен включить TLV вектора пути.
Если R послал ранее сообщение выделения метки вышестоящему партнеру, тогда он должен включить TLV вектора пути, если полученное сообщение уведомляет об увеличении числа шагов LSP, изменении числа от неизвестного к известному или от известного к неизвестному.
Если выше приведенные правила требуют от R включить в сообщение присвоения метки TLV вектора пути, R вычисляет его следующим образом:
Если полученное сообщение о выделении метки содержит вектор пути, вектор пути, посылаемый вверх по течению, должен быть результатом добавления к нему идентификатора R Id.
Если полученное сообщение не имеет вектора пути, вектор пути, посланный вверх по течению должен иметь длину вектора пути равную 1 и содержать идентификатор R Id.
Если сообщение присвоения метки не было послано для распространения вверх по течению, сообщение присвоения метки должно включать вектор пути с длиной 1 и идентификатор R Id.
Если R получает сообщение присвоения метки с TLV числа шагов от своего следующего узла, которое превышает сконфигурированный максимум, или с TLV вектора пути, содержащим свой собственный LSR Id или с длиной превышающей максимально допустимое значение, тогда R считает, что соответствующий LSP содержит петлю.
Когда R детектирует петлю, он должен прекратить использование метки для переадресации, отбросить сообщение присвоения метки, и с помощью специального сообщения сигнализировать отправителю о детектировании петли.
Сообщение рассылки метки
Формат сообщения о присвоении метки представлен ниже на рис. 15, он содержит опционное поле статуса TLV:
Рис. 15.
Сообщение Resv
Сообщение Resv имеет следующий формат:
<Сообщение Resv> ::=
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
| <SE flow descriptor>
<LABEL> [ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
[ <RECORD_ROUTE> ]
Заметьте: LABEL и RECORD_ROUTE (если имеется), являются связанными с предыдущей спецификацией FILTER_SPEC. За каждой спецификацией FILTER_SPEC может следовать не более одного LABEL и/или RECORD_ROUTE.
Сообщение уведомления
LSR посылает сообщение уведомления, чтобы проинформировать партнера LDP о важном событии. Сообщение уведомления сигнализирует о фатальной ошибке или предоставляет рекомендации, сопряженные с состоянием сессии или результатом обработки сообщения LDP. Формат сообщений уведомления представлен ниже:
ID сообщения
32-битовый код, используемый для идентификации этого сообщения.
TLV статуса
Индицирует сигнализируемое событие. Кодирование TLV статуса смотри в разделе "TLV статуса".
Опционные параметры
Это поле переменной длины содержит нуль или более параметров, каждый из которых представляется в виде TLV. Следующие опционные параметры являются общими и могут присутствовать в любом сообщении уведомления:
| Расширенный статус | 0x0301 | 4 | Смотри ниже |
| Присланный PDU | 0x0302 | Переменная | Смотри ниже |
| Сообщение-отклик | 0x0303 | Переменная | Смотри ниже |
Могут появиться и другие опционные параметры, специфичные для конкретного события.
Расширенный статус
4-октетный код расширенного статуса, который характеризует дополнительную информацию, содержащуюся в коде статуса сообщения уведомления.
Присылаемый PDU
LSR использует этот параметр для присылки LSR части LDP PDU, которую он передает. Значение этого TLV равно заголовку PDU и части данных, следующих за заголовком.
Возвращаемое сообщение
LSR использует этот параметр, чтобы вернуть LSR часть сообщения LDP, которое он послал. Значение этого TLV равно полям типа сообщения, длины и части сообщения, необходимой для объяснения условия, сигнализируемого в уведомлении.
Сообщение Notify предоставляет механизм информирования несмежных узлов LSP о событиях. Сообщения Notify обычно генерируются только после получения объекта запроса уведомления. Сообщение Notify отличается от определенных ранее сообщений об ошибках (т.e., сообщения PathErr и ResvErr) тем, что они могут быть адресованы узлу, отличному от ближайшего соседа сверху или снизу. Сообщение Notify не заменяет существующие сообщения об ошибках. Сообщение Notify может быть послано либо (a) в норме, когда транзитные узлы переадресуют сообщения Notify узлу-адресату, подобно обработке ResvConf в [RFC2205]; или (b) путем инкапсуляции в новый IP заголовок, чье место назначения соответствует IP-адресу места назначения. Вне зависимости от механизма передачи, узлы, получающие сообщение Notify, не адресованное им, просто передают его дальше без модификации.
Чтобы обеспечить надежную доставку сообщения Notify, используется сообщение Ack [RFC2961] для подтверждения получения сообщения. Подробности надежной доставки сообщений RSVP смотри в [RFC2961].
Сообщение запроса аннулирования метки
Сообщение запроса ликвидации метки может использоваться, чтобы ликвидировать определенное сообщение запроса метки. Формат сообщения запроса ликвидации метки представлен ниже:
ID сообщения
32-битный код используется, чтобы идентифицировать это сообщение.
TLV FEC
Идентифицирует FEC, для которого был аннулирован запрос метки.
TLV сообщения запроса метки
Специфицирует ID сообщения запроса метки, которое следует ликвидировать.
Опционные параметры
Для сообщения Label Abort Req опционные параметры не предусмотрены.
Сообщение запроса метки
Использование TLV вектора пути и числа шагов предотвращает зацикливание сообщений запросов метки в среде, содержащей LSR, не поддерживающие объединение меток (non-merge).
Правила, которые управляют использованием TLV числа шагов в сообщениях запроса метки, посланных LSR R (детектирование петель активировано), представлены ниже:
Сообщение запроса метки должно включать в себя TLV числа шагов.
Если R посылает запрос метки, из-за того, что он является входным, он должен включить в сообщение TLV числа шагов со значением равным 1.
Если R посылает запрос метки, как результат получения запроса метки от вышестоящего LSR, и если полученный запрос содержит TLV числа шагов, R должен инкрементировать значение счетчика на 1 и положить результат в TLV числа шагов сообщения запроса метки, передаваемого следующему узлу вдоль маршрута;
Правила, которые управляют использованием TLV вектора пути в сообщениях запроса метки, посылаемых LSR R (детектирование петель активировано) представлены ниже:
Если R посылает запрос метки, из-за того, что он является входным, тогда, если R не поддерживает объединение меток, он должен включить TLV вектора длины со значением 1, содержащее его собственный идентификатор LSR Id.
Если R посылает запрос метки, как результат получения запроса метки от вышестоящего LSR, тогда, если полученный запрос содержит TLV вектора длины или если R не поддерживает объединение меток, то:
R должен добавить к вектору пути собственный Id LSR, и должен передать полученный вектор пути узлу следующего шага в сообщении запроса метки. Если запрос метки не содержит TLV вектора пути, R должен включить TLV вектора пути со значением 1 со своим идентификатором LSR Id.
Заметим, что если R получает сообщение запроса метки для конкретного FEC, а R уже послал ранее запрос метки для этого FEC своему партнеру следующего шага и не получил пока отклика, и, если R намерен объединить вновь полученный запрос метки с существующим незавершенным запросом, тогда R не пересылает этот запрос узлу следующего шага.
Если R получает сообщение запроса метки от узла следующего шага с TLV числа шагов, которое превышает сконфигурированный максимум, или с TLV вектора пути, содержащий его собственный Id или который превышает допустимый предел длины, тогда R считает, что запрос метки прошел через петлю.
Когда R детектирует петлю, он должен послать отправителю запроса метки сообщение предупреждения об этом и выбросить полученное сообщение запроса метки.
LSR посылает запрос метки (Label Request) партнеру LDP, чтобы установить соответствие (mapping ) для FEC. Формат сообщения запроса метки представлен ниже:
ID сообщения
32-битный код используется, чтобы идентифицировать это сообщение.
FEC TLV
FEC, для которого запрашивается метка. Кодирование смотри в разделе "TLV FEC".
Опционные параметры
Это поле переменной длины содержит 0 или более параметров, каждый из которых имеет формат TLV. Опционными параметрами являются:
| TLV числа шагов | 1 | Смотри ниже |
| TLV вектора пути | переменная | Смотри ниже |
Кодирование TLV числа шагов и вектора пути можно найти в разделе "Кодирование TLV параметров общего пользования".
Число шагов
Специфицирует полное число LSR-шагов вдоль LSP, определяется в результате запроса метки . В разделе "Процедуры числа шагов" описано, как обрабатывать эти TLV.
Вектор пути
Специфицирует узлы вдоль LSP. Этот список сформирован посредством сообщения запроса метки. В разделе "Процедуры вектора расстояния" описано, как обрабатывать эти TLV.
Сообщения Addressing Path, PathTear и ResvConf
RSVP сконструирован, чтобы работать с динамическими изменениями маршрута и с узлами не поддерживающими RSVP. С этой целью сообщения Path, PathTear и ResvConf несут в себе адрес места назначения сессии в IP-заголовке. Узлы, которые не могут присваивать метки, не могут существовать в LSP. Другим отличием от традиционного RSVP является то, что временами, сообщение RSVP может транспортироваться за пределами информационного канала LSP.
Сообщения и TLV для расширяемости
Поддержка LDP включает правила работы с битами U и F, которые специфицируют то, как LSR должен обрабатывать неизвестные TLV и сообщения. В этом разделе специфицированы TLV и сообщения для частных применений производителя и экспериментальных целей.
Сообщения клиента
Таблица 4 характеризует различие между сообщениями клиента в различных состояниях
Таблица 4. Сообщения клиента для различных состояний
| INIT-REBOOT | SELECTING | RENEWING | REBINDING | |
| broad/unicast | Широковещ. | Широковещ | Уникастный | Широковещ |
| server-ip | Не должен | Должен | Не должен | Не должен |
| Запрошенный IP | Должен | Должен | Не должен | Не должен |
| ciaddr | нуль | нуль | IP адрес | IP адрес |
Сообщения LDP
Все сообщения LDP имеют следующий формат:
U бит
Бит неизвестного сообщения. При получении неизвестного сообщения, если U=0, в качестве отклика отправителю посылается уведомление; если U=1, неизвестное сообщение молча игнорируется.
Тип сообщения
Идентифицирует тип сообщения
Длина сообщения
Специфицирует суммарную длину в октетах полей идентификатора сообщения, обязательных и опционных параметров.
ID сообщения
32-битовый код, используемый для идентификации этого сообщения. Используется LSR-отправителем, чтобы облегчить идентификацию сообщений уведомления. LSR, отправляющий сообщение уведомления в ответ на это сообщение, должен включить этот Id в TLV статуса, транспортируемый данным сообщением; смотри раздел "Сообщение уведомления".
Обязательные параметры
Набор необходимых параметров, имеющий переменную длину. Некоторые сообщения не имеют обязательных параметров.
Для сообщений, которые нуждаются в обязательных параметрах, эти параметры должны специфицироваться отдельно (смотри последующие разделы).
Опционные параметры
Набор опционных параметров сообщения, имеющий переменную длину.
Для сообщений, которые имеют опционные параметры, эти параметры могут следовать в любом порядке. Заметим, что для первого октета сообщения LDP не существует никаких требований по выравниванию. В данной версии LDP определены следующие типы сообщений:
| Имя сообщения | Заголовок секции |
| Уведомление | "Сообщение уведомления" |
| Hello | " Сообщение Hello " |
| Инициализация | "Сообщение инициализации" |
| KeepAlive | "Сообщение KeepAlive " |
| Адрес | "Сообщение адреса" |
| Отзыв адреса | "Сообщение отзыва адреса" |
| Присвоение метки | " Сообщение присвоения метки " |
| Запрос метки | "Сообщение запроса метки" |
| Запрос ликвидации метки | "Сообщение запроса ликвидации метки" |
| Отзыв метки | " Сообщение отзыва метки " |
| Освобождение метки | "Сообщение освобождения метки" |
В последующих разделах специфицируется кодирование и процедуры для этих сообщений. Некоторые из приведенных выше сообщений связаны друг с другом, например, присвоение метки, запрос метки, отзыв метки и освобождение метки.
Сообщения мультикаст-маршрутизации
В принципе этот механизм может быть использован только мультикастинг протоколами маршрутизации, в которых применяется прямая сигнализация: например, сообщения Join в PIM-SM или CBT. Заметим, что DVMRP и PIM-DM могут быть адаптированы для поддержки этого типа запуска [FARI], однако ценой модификации самого протокола мультикаст-маршрутизации!
IP-сообщения мультикаст-маршрутизации могут формировать как жесткие состояния (например, CBT Join + CBT Join-Ack) так и “мягкие состояния” (например, периодически посылаются сообщения PIM-SM Join). Последние генерируют больше управляющего трафика для поддержания дерева и таким образом требуют больше обработки в модуле.
Запуски формирования маршрута, базирующиеся на сообщениях мультикастинг-протоколов маршрутизации, имеют недостаток, который заключается в том, что вычисление мультикастинг таблицы маршрутизации, выполняемые мультикастным маршрутным демоном, повторяются модулем. Первый определяет дерево, которое будет использоваться на уровне L3, последний вычисляет идентичное дерево, которое будет использоваться на уровне L2. Так как одна и та же задача решается дважды, лучше сформировать мультикастный LSP на основе информации, извлеченной из самой мультикастинг таблицы маршрутизации (смотри раздел 5.2 и 5.3). Вычисление маршрута становится более сложным для протоколов, которые поддерживают переключение от дерева (*, G) к дереву (S, G), так как нужно интерпретировать больше сообщений.
Когда ЭВМ имеет соединение с первым маршрутизатором по схеме точка-точка, может быть сформированы LSP до конечных пользователей путем перехвата не только маршрутных мультикастинг-сообщений, но и сообщений IGMP Join/Prune ([FENN]).
Сообщения резервирования ресурсов
В случае уникаста для запуска процесса формирования маршрута LSP могут использоваться сообщения RSVP Resv. Отправитель мультикастной группы пошлет вниз по дереву сообщение RSVP Path, получатели могут затем откликнуться сообщением RSVP Resv. RSVP хорошо адаптируется и для мультикастинга
a) Сообщения RSVP Resv могут быть совмещены.
b) Сообщения RSVP посылаются только первой ветви, которая выполнила нужное резервирование.
Соотношение между меткой и FEC
[MPLS_ARCH] утверждает в разделе 2.1., что некоторые маршрутизаторы анализируют заголовок пакета сетевого уровня не только для того, чтобы определить следующий шаг, но также с целью определения приоритета или класса обслуживания. Они могут затем применить разные пороги отбрасывания или порядок обработки для разных пакетов. MPLS позволяет (но не требует) получение данных о приоритете или классе обслуживания из метки. В этом случае, можно сказать, что метка предоставляет комбинацию FEC и приоритета или класса обслуживания. В связи с этим мы отмечаем что: В случае E-LSP метка представляет собой комбинацию FEC и набор BA, транспортируемых через E-LSP. Когда все транспортируемые BA передаются через E-LSP, метка представляет полный FEC. В случае L-LSP метка представляет собой комбинацию FEC и OA.
Соответствие CLP/PSC --> PHB по умолчанию
Бит CLP PSC PHB
0 DF > DF
0 CSn > CSn
0 AFn > AFn1
1 AFn > AFn2
0 EF > EF
