Анонсирование меток Downstream Unsolicited
Вообще, LSR ниже по течению ответственен за анонсирование меток, когда он хочет, чтобы вышестоящий LSR использовал конкретную метку. Вышестоящий LSR может послать запрос присвоения метки (mapping request), если он этого захочет.
Комбинация режима Downstream Unsolicited и консервативного удержания метки может вести к ситуации, когда LSR освобождает метку для заданного FEC, которая ему может быть нужна в будущем. Например, если LSR Rd анонсирует LSR Ru метку для FEC, для которого Ru не является следующим шагом, Ru освободит метку. Если следующим шагом Ru для FEC позднее станет Rd, ему потребуется метка, которая была ранее освобождена.
Чтобы разрешить эту проблему, либо Ru может явно запросить метку, когда она ему нужна, либо Rd может периодически предлагать ее Ru. Во многих ситуациях Ru будет знать, когда ему нужна метка от Rd. Например, когда его следующим шагом для FEC становится Rd. Однако могут возникать ситуации, когда Ru не имеет нужной информации. Например, Rd может пытаться сформировать LSP с нестандартными свойствами. Необходимость для Ru в этой ситуации явно запросить метку потребует, чтобы он поддерживал состояния LSP с нестандартными свойствами.
В ситуациях, где Ru знает, что ему нужна метка, он ответственен за явный запрос метки посредством посылки сообщения Label Request. В ситуациях, где Ru не может знать, что ему нужна метка, Rd ответственен за периодическое анонсирование метки Ru.
Для этой версии LDP, единственная ситуация, когда Ru знает, что ему нужна метка для FEC от Rd, это когда Rd является следующим шагом для FEC, Ru не имеет метки от Rd, и LSP для FEC является единственным, который может быть сформирован с TLV, определенными в данном документе.
Анонсирование меток вниз по течению по запросу (Downstream on Demand)
Вообще, при работе в режиме Downstream on Demand (вниз по течению по запросу) вышестоящий LSR ответственен за организацию присвоения меток. Однако если не следовать определенным правилам, может так случиться, что LSR-соседи с разными режимами анонсирования попадут в ситуацию активного тупика, когда все функционирует нормально, но метки не рассылаются. Например, рассмотрим два LSR Ru и Rd, где Ru является вышестоящим LSR, а Rd - нижестоящим LSR для конкретного FEC. В этом примере Ru использует режим анонсирования Downstream Unsolicited, а Rd использует режим Downstream on Demand. В этом случае Rd может предполагать, что Ru, запросит метку, когда он захочет, а Ru может предполагать, что Rd анонсирует метку, если захочет, чтобы Ru ее использовал. Если Rd и Ru работают, как это предполагается, никаких меток не будет посылаться от Rd к Ru.
Эта ситуация активного тупика может быть исключена, если следовать правилу: LSR, работающий в режиме Downstream on Demand, не должен посылать анонсирования установления добровольного соответствия меток (unsolicited mapping). Следовательно, если нижестоящий LSR работает в режиме Downstream on Demand, вышестоящий LSR ответственен за посылку запросов присвоения меток, как это требуется.
Независимое управление присвоением меток
Если LSR сконфигурирован для независимого управления, сообщения установления соответствия передается LSR при выполнении любого из следующих условий:
LSR распознает новый FEC с помощью маршрутной таблицы, и используется режим анонсирования меток Downstream Unsolicited.
LSR получает сообщение запроса от вышестоящего партнера для FEC, присутствующего в маршрутной таблице LSR .
Следующий шаг для FEC изменился, и активизировано детектирование петель.
Атрибуты соответствия изменились.
Отклик на присвоение метки от узла-следующего шага вниз по течению и
не было установления соответствия со стороны выше по течению или
сконфигурировано детектирование петель или
атрибуты соответствия изменились.
Обязательное соответствие PHB-->EXP
PHB Поле EXP
DF > 000
CSn > 000
AFn1 > 001
AFn2 > 010
AFn3 > 011
EF > 000
Партнеры рассылки меток для адресного префикса
LSR R1 и R2 считаются партнерами рассылки меток для адресного префикса X, если и только если выполнено одно из следующих условий:
1. Маршрут R1 к X является маршрутом, который прислан определенным IGP, а R2 является соседом R1 по данным IGP.
2. Маршрут R1 к X является маршрутом, который прислан в какой-то момент в результате работы алгоритма маршрутизации A1, и этот маршрут рассылается алгоритмом маршрутизации A2, а R2 является соседом R1 согласно A2.
3. R1 является выходной точкой LSP-туннеля, который находится внутри другого LSP, а R2 является входной точкой этого туннеля, R1 и R2 являются клиентами IGP, и находятся в той же области IGP (если данный IGP имеет области), а маршрут от R1 к X был получен через IGP, или в результате рассылки R1 данному IGP.
4. Маршрут R1 к X является маршрутом, который прислан BGP, а R2 является BGP-партнером R1.
Вообще, эти правила гарантируют то, что, если маршрут до определенного адресного префикса рассылается через IGP, партнеры рассылки меток для данного адресного префикса являются IGP-соседями. Если маршрут определенного адресного префикса рассылается через BGP, партнеры рассылки меток для данного адресного префикса являются BGP партнерами. В других случаях LSP-туннелирования конечные точки туннеля являются партнерами по рассылке меток.
На момент формирования данной спецификации
На момент формирования данной спецификации не существовало стандартных таблиц соответствия PHB и классов трафика 802.1. Следовательно, LSR, поддерживающий несколько классов трафика 802.1 через интерфейс LAN, должен позволять локальную конфигурацию таблицы PHB-->802.1. Эта таблица относится ко всем исходящим LSP, сформированным LSR для данного интерфейса LAN.
PushUnconditional
Пусть Rd является LSR. Предположим, что:
1. X является адресным префиксом в маршрутной таблице Rd
2. Ru является партнером по рассылке меток Rd с точки зрения X
Когда бы эти условия ни выполнялись, Rd должен связать метку с X и послать эту ассоциацию Ru. Отслеживание ассоциаций, которые посылаются Ru, и контроль того, что Ru всегда имеет эти ассоциации, является областью ответственности Rd.
Эта процедура должна использоваться LSR, которые выполняют не затребованное присвоение меток в независимом режиме управления LSP.
ReleaseOnChange
Ru должен ликвидировать ассоциацию и информировать Rd об этом. Эту процедуру следует использовать в консервативном режиме удержания меток (Label Retention Mode).
Соответствие PHB-->CLP по умолчанию
PHB CLP бит
DF > 0
CSn > 0
AFn1 > 0
AFn2 > 1
AFn3 > 1
EF > 0
Упорядоченное управление присвоением меток
Если LSR осуществляет упорядоченное управление, сообщение установления соответствия передается нижерасположенным LSR при выполнении любого из следующих условий:
LSR распознает новый FEC из маршрутной таблицы, и он является выходным для этого FEC.
LSR получает сообщение запроса от вышестоящего партнера для FEC, присутствующего в маршрутной таблице LSR, и LSR является выходным для этого FEC или имеет установленное соответствие для зоны вниз по течению.
Следующий шаг для FEC изменился и активизировано детектирование петель.
Атрибуты соответствия изменились.
Отклик на присвоение метки от узла следующего шага ниже по течению и
не сформировано никакого соответствия узлом выше по течению или
сконфигурировано детектирование петель или
атрибуты соответствия изменились.
UseImmediate
Ru может начать использовать ассоциацию немедленно. В любое время, когда Ru получил ассоциацию для X от Rd , а Rd является следующим шагом Ru L3 для X, Rd будет также следующим шагом Ru LSP для X . Эта процедура применяется, когда не используется детектирование петель.
Вектор пути в случае присвоения метки
В разделе "Детектирование петель" специфицируются ситуации, когда LSR должен включать TLV вектора пути в сообщения присвоения метки. LSR, который получает вектор пути в сообщении присвоения метки, должен выполнить процедуры, описанные в разделе "Детектирование петель".
Если LSR детектирует петлю, он должен отвергнуть сообщение присвоения метки для того, чтобы исключить зацикливания сообщений. LSR должен:
Передать LSR-отправителю сообщение освобождения метки (Label Release), несущее в себе TLV статуса, сигнализируя о "Детектировании петли".
Не передавать сообщение дальше.
Проверить, относится ли сообщение присвоения метки к существующему LSP. Если это так, LSR должен разъединить любые метки выше по течению, которые объединены для области вниз по течению для заданного FEC.
Заметим, что сообщение присвоения метки с TLV вектора расстояния переадресуется до тех пор пока:
Не обнаружена петля,
Достигнуто начало LSP, или
Достигнут максимум вектора пути или числа шагов. Это обрабатывается, как если бы была детектирована петля.
Вектор пути запроса метки
Раздел "детектирование петель" специфицирует ситуации, когда LSR должен включить TLV вектора пути в сообщение запроса метки.
LSR, который получает вектор пути в сообщении запроса метки, должен выполнить процедуры, описанные в разделе "детектирование петель". Если LSR детектирует петлю, он должен отвергнуть сообщение запроса метки.
LSR должен:
Послать сообщение уведомления LSR-отправителю, сигнализируя, что "Обнаружена петля".
Не передавать дальше сообщение запроса метки.
Заметим, что сообщение запроса метки с TLV вектора пути переадресуется до тех пор пока:
Будет найдена петля,
Будет достигнут конец LSP,
Будет достигнут верхний предел длины вектора пути или числа шагов. Это обрабатывается как, если бы была детектирована петля пути.
Истечение таймера KeepAlive сессии
Это фатальная ошибка, сигнализируемая кодом статуса KeepAlive Timer Expired (таймер KeepAlive истек).
Неизвестный или некорректный TLV
Некорректный TLV, содержащийся в LDP сообщении, которое является частью механизма LDP выявления, приводит к молчаливому отбрасыванию сообщения.
TLV, содержащееся в сообщении LDP, которое получено по TCP-соединению имеет некорректный формат, если:
Длина TLV слишком велика, то есть, указывает, что TLV простирается за пределы содержащего его сообщения. Это фатальная ошибка, сигнализируемая кодом статуса Bad TLV Length (неверная длина TLV).
Тип TLV не известен.
Если тип TLV < 0x8000 (старший бит 0), это ошибка, сигнализируемая кодом статуса Unknown TLV (неизвестный TLV).
Если тип TLV >= 0x8000 (старший бит 1), TLV молча игнорируется.
Значение TLV некорректно. Это случается, когда получатель обрабатывает TLV, но не может декодировать значение TLV. Это интерпретируется как ошибка при отправке или получении LSR. Это фатальная ошибка, сигнализируемая кодом статуса Malformed TLV Value (некорректное значение TLV).
Некорректный PDU или сообщение
Некорректно сформатированные LDP PDU или сообщения, которые являются частью механизма выявления LDP, молча отбрасываются. LDP PDU, полученный через TCP-соединение для LDP-сессии сформатировано некорректно, если:
Идентификатор LDP в заголовке PDU неизвестен получателю, или он известен, но этот идентификатор не ассоциирован получателем с партнером LDP для этой сессии. Это фатальная ошибка, сигнализируемая кодом состояния Bad LDP Identifier (некорректный идентификатор).
Версия протокола LDP не поддерживается получателем, или он поддерживается, но это не та версия, которая согласована при установлении сессии. Это фатальная ошибка, сигнализируемая кодом статуса Bad Protocol Version (плохой код версии).
Поле длины PDU слишком мало (< 14) или слишком велико (> максимальной длины PDU). Это фатальная ошибка, сигнализируемая кодом состояния Bad PDU Length (неверная длина PDU).
LDP-сообщение некорректно, если:
Тип сообщения неизвестен.
Если тип сообщения < 0x8000 (старший бит = 0) - это ошибка, сигнализируемая кодом статуса Unknown Message Type (неизвестный тип сообщения). Если тип сообщения >= 0x8000 (старший бит = 1), оно молча отбрасывается.
Длина сообщения слишком велика, то есть, индицирует, что сообщение занимает места больше, чем отведено в LDP PDU. Это фатальная ошибка, сигнализируемая кодом статуса Bad Message Length (неверная длина сообщения).
В сообщении нет одного или более обязательных параметров. Это не фатальная ошибка, сигнализируемая кодом статуса Missing Message Parameters (пропущены обязательные параметры).
Одностороннее прерывание сессии
Это фатальная ошибка, сигнализируемая кодом статуса Shutdown. Сообщение уведомления может опционно включать в себя TLV расширенного статуса, чтобы объяснить причину Shutdown. LSR-отправитель завершает сессию немедленно, после отправки уведомления.
PushConditional
Пусть Rd является LSR. Предположим, что:
1. X является адресным префиксом в маршрутной таблице Rd
2. Ru является партнером Rd по рассылке меток с учетом X
3. Rd является либо концом LSP, либо прокси концом LSP для X , или следующим шагом Rd L3 для X является Rn, где Rn отличается от Ru, и Rn связал метку с X и послал эту ассоциацию Rd.
Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru.
Поскольку PushUnconditional вызывает рассылку ассоциаций меток всем адресным префиксам маршрутной таблицы, PushConditional вызывает рассылку ассоциаций меток только тем адресным префиксам, для которых получены ассоциации от одного следующего шага LSP, или для которых не существует следующего шага с поддержкой MPLS L3.
Эта процедуру следует использовать LSR, которые выполняют не затребованное присвоение меток в упорядоченном режиме управления LSP.
Рассылаемые метки
Для того чтобы использовать MPLS для переадресации пакетов согласно маршруту шаг-за-шагом, соответствующему какому-либо адресному префиксу, каждый LSR должен:
1. Связать один или более меток с каждым адресным префиксом, который обнаружен в маршрутной таблице.
2. Для каждого такого адресного префикса X, использовать протокол рассылки меток для уведомления партнеров (в рамках Х) о существовании ассоциации метки с данным префиксом.
Существует также обстоятельство, при котором LSR должен рассылать ассоциации меток для адресного префикса, даже если он не является LSR, который установил связь между меткой и префиксом:
3. Если R1 использует BGP для рассылки маршрута до X, называя некоторый другой LSR R2 в качестве следующего BGP шага к X, и если R1 знает, что R2 присвоена метка L, тогда R1 должен разослать уведомление об ассоциации L и X всем BGP-партнерам, которым он рассылает это маршрут.
Эти правила гарантируют, что метки, ассоциированные с адресным префиксам, которые соответствуют маршрутам BGP, рассылаются IGP-соседям, если и только если BGP-маршруты разосланы IGP. Другими словами, метки, привязанные к BGP-маршрутам, рассылаются только другим BGP-агентам.
Эти правила имею целью указать, какие ассоциации меток должны рассылаться данным LSR другим LSR.
Разные события
Существуют события, которые не попадают ни в одну из категорий, перечисленных выше. В данной версии протоколов не определено все многообразие возможных событий.
RequestNoRetry
Ru никогда не должен посылать запрос повторно, предполагая, что Rd предоставит необходимую ассоциацию автоматически, когда она станет доступной. Это полезно, если Rd использует процедуру PushUnconditional или PushConditional, т.e., если применена не запрошенная рассылка меток нижестоящим объектам.
Заметим, что если Rd отвечает, что он не может предоставить ассоциацию Ru, из-за тех же условий ошибки, а не по причине того, что Rd не имеет следующего шага, поведение Ru будет управляться условиями восстановления после ошибки протокола рассылки меток, а не процедурой NotAvailable.
События сообщения инициализации
Согласование инициализации сессии (смотри раздел "Инициализация сессии") может потерпеть неудачу, если параметры сессии, полученные в сообщении инициализации неприемлемы. Это фатальная ошибка. Специфический код статуса зависит от параметров, оказавшихся неприемлемыми.
События, вызванные другими сообщениями
Причиной событий, о которых необходимо сигнализировать партнерам посредством сообщений уведомления, могут быть и сообщения отличные от инициализации LDP. Эти события и статусные коды, используемые в сообщениях уведомления, описаны в разделах, где рассматриваются эти сообщения.
UseIfLoopNotDetected
Эта процедура аналогична UseImmediate, если только Ru не детектировал петлю в LSP. Если детектирована петля, Ru прекратит использовать метку L для переадресации пакетов в Rd.
Эта процедура используется, когда работает детектирование петель маршрутов. Это будет продолжаться до тех пор, пока не изменится следующий шаг для X, или пока не будет ликвидирован петлевой маршрут.
Внутренние ошибки
Реализация LDP может быть способна детектировать проблемные ситуации, специфические для конкретного приложения. Когда такая ситуация мешает реализации нормальной работы с партнером, программа должна, когда возможно, использовать внутренний статусный код ошибки, чтобы уведомить о ней партнера. Это фатальная ошибка.
PulledUnconditional
Пусть Rd является LSR. Предположим, что:
1. X является адресным префиксом в маршрутной таблице Rd
2. Ru является партнером Rd по рассылке меток с учетом X
3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru
Затем Rd должен связать метку с X и послать эту ассоциацию Ru. Заметим, что если X отсутствует в маршрутной таблице Rd, или если Rd не является партнером Ru по рассылке меток с учетом X, тогда Rd должен проинформировать Ru о том, что в данный момент не может предоставить ассоциацию.
Если Rd уже переслал Ru ассоциацию метки для адресного префикса X, и получил новый запрос от Ru ассоциации для адресного префикса X, он свяжет вторую метку, и пошлет новую ассоциацию Ru . Первая ассоциация метки остается в силе.
Эта процедура будет использоваться LSR, выполняющими рассылку меток downstream-on-demand, используя независимый режим управления LSP.
RequestOnRequest
Процедура посылает запрос всякий раз, когда приходит запрос в дополнение к необходимым протокольным запросам (как это описано в разделе 3.1.2.2). Если Ru не способен быть входом LSP, он может выдать запрос, только когда получает запрос сверху.
Если Rd получает такой запрос от Ru, для адресного префикса, для которого Rd уже послал метку Ru, Rd присвоит новую метку, ассоциирует ее с X, и разошлет эту ассоциацию. Может ли Rd послать эту ассоциацию Ru немедленно или нет, зависит от используемой процедуры рассылки. Эту процедуру следует использовать LSR, которые осуществляют рассылку меток downstream-on-demand, но не выполняют объединения меток, например, ATM-LSR, которые не способны объединять VC.
PulledConditional
Пусть Rd является LSR. Предположим, что:
1. X является адресным префиксом в маршрутной таблице Rd
2. Ru является партнером Rd по рассылке меток с учетом X
3. Ru явно запросил Rd связать метку с X и послать эту ассоциацию Ru
4. Rd является либо концом LSP, либо прокси концом LSP для X, или следующим шагом Rd L3 для X является Rn, где Rn отличается от Ru, а Rn связал метку с X и послал эту ассоциацию Rd
Затем, как только все эти условия оказались выполнены, Rd должен связать метку с X и послать эту ассоциацию Ru . Заметим, что если X отсутствует в маршрутной таблице Rd, а получить ассоциацию для X через следующий шаг Rd для X невозможно, или если Rd не является партнером Ru по пересылке меток с учетом X, тогда Rd должен проинформировать Ru, что не может в данный момент предоставить ему необходимую ассоциацию.
Однако, если хотя бы одно условие не выполнено, Rn не выдает метку Rd, а Rd должен отложить отклик для Ru до тех пор, пока Rn не пришлет ассоциацию метки.
Если Rd послал Ru ассоциацию метки для адресного префикса X, а спустя какое-то время любой из атрибутов ассоциации метки изменился, Rd должен заново послать Ru ассоциацию с новым значением атрибута. Он должен сделать это даже если Ru не послал нового запроса. Эту процедуру следует использовать LSR, которые осуществляют ассоциацию меток downstream-on-demand в упорядоченном режиме управления LSP.
В разделе 4.2, мы обсудим то, как выбрать конкретную процедуру, которую следует использовать в конкретной ситуации, и как гарантировать совместимость работы LSR, выбравших разные процедуры.
>5.Формат сообщения Hello
Сообщениями Hello всегда обмениваются только RSVP соседи. Адрес IP отправителя равен IP-адресу узла-отправителя. IP-адрес места назначения равен IP-адресу соседнего узла.
Механизм HELLO предназначен для использования только непосредственными соседями. Когда обмен сообщениями HELLO осуществляют соседи, поле IP TTL всех исходящих сообщений HELLO следует устанавливать равным 1.
Сообщение Hello имеет тип Msg равный 20. Формат сообщения Hello показан ниже:
<Hello Message> ::=
<HELLO>
A.1.Детектирование доступности ресурсов локальной метки
Краткое изложение:
После того как LSR послал LDP-партнеру уведомление No Label Resources, когда ресурсы оказываются доступными, он посылает соответствующее уведомление (Label Resources Available) каждому из партнеров.
Контекст:
LSR. LSR, обрабатывающий событие.
Атрибуты. Атрибуты, записанные в отложенном сообщении присвоения метки.
Алгоритм:
| ResA.1 | Начать итерацию через ResA.4 для каждого партнера, которому LSR посылал ранее уведомление No Label Resources (Нет ресурсов для метки). |
| ResA.2 | Исполнить процедуру Send_Notification(Peer, Label Resources Available) |
| ResA.3 | Стереть запись о том, что ранее было послано партнеру уведомление No Label Resources. |
| ResA.4 | Завершить итерацию в точке ResA.1 |
| ResA.5 | Начать итерацию через ResA.8 для каждой записи ассоциации метка-FEC, необходимой для партнера, когда нет ресурсов. (Смотри замечание 1.) |
| ResA.6 | Исполнить процедуру Send_Label(Peer, FEC, Attributes). Если процедура не прошла, прервать итерацию. |
| ResA.7 | Очистить запись ассоциации метка-FEC, которая нужна, но для этого нет ресурсов. |
| ResA.8 | Завершить итерацию в точке ResA.5 |
| ResA.9 | DONE. |
Замечания:
Итерация с ResA.5 по ResA.8 обрабатывает ситуации, когда LSR использует рассылку меток в режиме Downstream Unsolicited и ранее не мог присвоить метку для FEC.
A.1.Детектирование изменения FEC следующего шага
Краткое изложение:
Отклик LSR на изменение следующего шага для FEC может включать в себя одну или более операций:
Удаление из таблицы маршрутизации метки, соответствующей старому значению следующего шага для FEC;
Передача сообщений присвоения метки для FEC одному или более партнерам LDP;
Передача запроса метки новому узлу следующего шага для заданного FEC;
Любая операция, которая может иметь место, когда LSR получает ассоциацию метка-FEC из узла следующего шага.
Контекст:
LSR. LSR, обрабатывающий событие.
FEC. FEC, для которого изменился следующий шаг.
New Next Hop. Новый следующий шаг для данного FEC.
Old Next Hop. Предыдущий следующий шаг для FEC.
OldLabel. Метка, (если имеется) ранее полученная от старого узла следующего шага.
CurAttributes. Атрибуты, если имеются, ассоциированные в настоящее время с данным FEC.
SAttributes. Атрибуты, подлежащие включению в сообщение запроса метки, (если имеются), которые надо послать новому узлу следующего шага.
Алгоритм :
| NH.1 | Получал ли LSR ранее от старого узла следующего шага и сохранил ли ассоциацию метка-FEC? Если нет, goto NH.6. |
| NH.2 | Удалить метку из маршрутной таблицы. (Смотри замечание 1.) |
| NH.3 | Использует ли LSR свободное сохранение меток? Если да, goto NH.6. |
| NH.4 | Исполнить процедуру Send_Message(Old Next Hop, Label Release, OldLabel). |
| NH.5 | Удалить ассоциацию метка-FEC, ранее полученную от старого узла следующего шага. |
| NH.6 | Имеет ли LSR ожидающий запрос метки со старым значением следующего шага? Если нет, goto NH.10. |
| NH.7 | Использует ли LSR консервативное сохранение меток? Если нет, goto NH.10. |
| NH.8 | Исполнить процедуру Send_ Message(Old Next Hop, Label Abort Request, FEC, TLV), где TLV является ID запроса метки, который несет в себе ID ожидающего запроса метки. |
| NH.9 | Записать запрос ликвидации метки для FEC как ожидающий для старого узла следующего шага. |
| NH.10 | Имеется новый следующий шаг для данного FEC? Если нет, goto NH.16. |
| NH.11 | Получил ли ранее LSR от нового узла следующего шага ассоциацию метка-FEC? Если нет, goto NH.13. |
| NH.12 | Генерировать событие: Получена ассоциация метки от нового узла следующего шага. Goto NH.20. (Смотри замечание 2.) |
| NH.13 | Использует ли LSR анонсирование Downstream on Demand? ИЛИ Использует ли узел следующего шага анонсирование Downstream on Demand? ИЛИ Использует ли LSR консервативное сохранение меток? Смотри замечание 3.) Если да, goto NH.14. Если нет, goto NH.20. |
| NH.14 | Исполнить процедуру Prepare_Label_Request_Attributes(следующий шаг, FEC, CurAttributes, SAttributes) |
| NH.15 | Исполнить процедуру Send_Label_Request(New Next Hop, FEC, SAttributes). (Смотри замечание 4.) Goto NH.20. |
| NH.16 | Продолжить итерацию через NH.19 для следующего партнера |
| NH.17 | Послал ли LSR ранее партнеру ассоциацию метка-FEC? Если нет, продолжить итерацию для следующего партера через NH.16. |
| NH.18 | Исполнить процедуру Send_Label_Withdraw(Peer, FEC, Label previously sent to Peer). |
| NH.19 | Завершить итерацию через NH.16. |
| NH.20 | DONE |
Замечания:
Если метки нет в таблице маршрутизации, NH.2 не имеет последствий.
Если LSR имеет метку для FEC от нового узла следующего шага, ему следует вести себя, как если бы он только что получил метку от нового узла следующего шага.
Целью проверки режима сохранения метки является избежание участка с шагами LMp.12- LMp.13 процедуры обработки сообщения присвоения метки, где LSR, работая в режиме консервативного сохранения метки, может отправить сообщение присвоения метки, полученное от нового узла следующего шага, прежде чем обнаружит, что следующий шаг для данного FEC изменился.
Вне зависимости от используемой LSR процедуры запроса метки, он должен послать запрос метки, если условия в NH.8 выполняются. Следовательно, он выполняет непосредственно процедуру Send_Label_Request, а не процедуру запроса метки LSR.
A.1.Истечение таймаута отложенного запроса метки
Краткое изложение:
Запросы метки откладываются в ответ на уведомления No Route (нет маршрута) и Loop Detected (обнаружена петля). Когда для отложенного запроса метки истекает время таймаута, LSR посылает запрос метки.
Контекст:
LSR. LSR, обрабатывающий событие.
FEC. FEC, ассоциированный с событием таймаута.
Партнер. LDP-партнер, ассоциированный с событием таймаута.
Атрибуты. Атрибуты, запомненные вместе с сообщением отложенного запроса метки.
Алгоритм:
| TO.1 | Извлечь запись отложенного запроса метки. |
| TO.2 | Является ли партнер узлом следующего шага для FEC? Если нет, goto TO.4. |
| TO.3 | Исполнить процедуру Send_Label_Request(Peer, FEC). |
| TO.4 | DONE. |
A.1.LSR решает не переадресовывать пакеты по метке для данного FEC
Краткое изложение:
LSR может в одностороннем порядке решить прекратить использование ассоциации метка-FEC для коммутации пакетов. LSR, который делает это, должен послать партнеру сообщение отзыва метки для FEC (label withdraw).
Контекст:
Партнер. Партнер.
FEC. FEC.
PrevAdvLabel. Метка для FEC, ранее анонсированная для партнера.
Алгоритм:
| NoLS.1 | Исполнить процедуру Send_Label_Withdraw(Peer, FEC, PrevAdvLabel). (Смотри замечание 1.) |
| NoLS.2 | DONE |
Замечания:
LSR может удалить метку из таблицы маршрутизации в результате выполнения освобождения метки в ответ на запрос отзыва.
A.1.Получение Label Release (освобождение метки)
Краткое изложение:
Когда LSR получает от партнера сообщение освобождения метки для FEC, он проверяет, удерживают ли другие партнеры освобожденную метку. Если никто этого не делает, LSR прекращает использование метки для переадресации, если он еще не сделал это, и, если LSR удерживает ассоциацию метки и FEC следующего шага, он освобождает метку.
Контекст:
LSR. LSR, обрабатывающий события.
MsgSource. Партнер LDP, который посылает сообщение.
Метка. Метка, специфицированная в сообщении.
FEC. FEC, специфицированный в сообщении.
Алгоритм:
| LRl.1 | Удалить MsgSource из записи партнеров, где хранится метка для заданного FEC. (Смотри замечание 1.) |
| LRl.2 | Соответствует ли сообщение сообщению отзыва метки для FEC, посланной ранее MsgSource? Если нет, goto LRl.4 |
| LRl.3 | Ликвидировать запись для отзываемой метки, посланную ранее MsgSource. |
| LRl.4 | Способен ли LSR объединять метки для этого FEC? Если нет, goto LRl.6. (Смотри замечание 2.) |
| LRl.5 | Имеет ли LSR метку, ранее анонсированную для этого FEC другим партнерам? Если да, goto LRl.10. |
| LRl.6 | Является ли LSR выходным для этого FEC? Если да, goto LRl.10 |
| LRl.7 | Имеется ли следующий шаг для FEC? И Имеет ли LSR, полученную ранее от узла следующего шага ассоциацию метка-FEC? Если нет, goto LRl.10. |
| LRl.8 | Сконфигурирован ли LSR для переадресации запросов освобождения метки? Если нет, goto LRl.10. (Смотри замечание 3.) |
| LRl.9 | Исполнить процедуру Send_Message (Next Hop, Label Release, FEC, Label from Next Hop). |
| LRl.10 | Удалить метку из MsgSourceи не использовать ее для переадресаций пакетов. |
| LRl.11 | Содержит ли кто-то из партнеров ассоциацию метки и FEC? Если да, goto LRl.13. |
| LRl.12 | Освободить метку. |
| LRl.13 | DONE. |
Замечания:
Если LSR использует режим рассылки меток Downstream Unsolicited, он не должен повторно анонсировать MsgSource ассоциацию метка-FEC до тех пор, пока MsgSource не запросит этого.
Шаги с LRl.4 по LRl.8 служат для определения, следует ли LSR передавать запрос об освобождении метки дальше партнерам ниже по течению (LRl.9).
Если LRl.8 достигнут, ни один LSR выше по течению не содержит ассоциации метки с данным FEC, и LSR получает ассоциацию метка-FEC от узла следующего шага. LSR может передавать запрос освобождения метки узлу следующего шага. Путем передачи запросов освобождения метки LSR освобождает ресурсы для меток. Поступая так, он также увеличивает задержку восстановления LSP.
Рассылка меток будет работать нормально вне зависимости оттого, пересылаются или нет запросы освобождения меток. Решение передавать или нет такие запросы, зависит от таких факторов, как наличие достаточных ресурсов для меток в ОС, требования малой задержки при восстановлении виртуального маршрута, а также от схемы формирования LSP(со стороны входного или выходного узла).
A.1.Получение Label Withdraw (отзыв метки)
Краткое изложение:
Когда LSR получает сообщение отзыва метки для FEC от партнера LDP, он откликается посылкой сообщения освобождения метки и удаляет метку из таблиц переадресации. Если используется упорядоченное управление, LSR посылает сообщение отзыва метки каждому LDP партнеру, которому ранее было послано сообщение присвоения метки для FEC. Если LSR использует режим анонсирования меток Downstream on Demand при независимом управлении, он действует так, как если бы он только что распознал FEC.
Контекст:
LSR. LSR, обрабатывающий события.
MsgSource. LDP партнер, который посылает сообщение.
Label. Метка, специфицированная в сообщении.
FEC. FEC, специфицированная в сообщении.
Алгоритм:
| LWd.1 | Удалить метку из таблицы переадресации. (Смотри замечание 1.) |
| LWd.2 | Исполнить процедуру Send_Message(MsgSource, Label Release, FEC, Label) |
| LWd.3 | Имеет ли LSR полученную ранее от MsgSource и сохраненную ассоциацию метка-FEC? Если нет, goto LWd.13. |
| LWd.4 | Уничтожить ассоциацию метка-FEC, полученную ранее от MsgSource. |
| LWd.5 | Использует ли LSR упорядоченное управление? Если да, goto LWd.8. |
| LWd.6 | Использует ли MsgSource анонсирование меток в режиме Downstream On Demand? Если нет, goto LWd.13. |
| LWd.7 | Генерировать событие: Рапознавание нового FEC. Goto LWd.13. (Смотри замечание 2.) |
| LWd.8 | Продолжить итерацию через LWd.12 для каждого партнера, отличного от MsgSource. |
| LWd.9 | Послал ли LSR ранее партнеру ассоциацию метка-FEC? Если нет, продолжить итерацию для следующего партнера через LWd.8. |
| LWd.10 | Согласуется ли метка, посланная ранее партнеру, с отзываемой меткой? Если нет, продолжить итерацию для следующего партнера черезt LWd.8. (Смотри замечание 3.) |
| LWd.11 | Исполнить процедуру Send_Label_Withdraw(Peer, FEC, Метка посланная ранее партнеру). |
| LWd.12 | Закончить итерацию через LWd.8. |
| LWd.13 | DONE |
Замечания:
Если метка не используется для переадресации, шаг LWd.1 не будет иметь последствий.
LWd.7 обрабатывает случаи, когда LSR использует рассылку меток в режиме Downstream On Demand при независимом управлении. В этой ситуации LSR должен посылать запрос метки в узел следующего шага для FEC, как если бы он только что распознал FEC.
LWd.10 работает как в случае поддержки объединения меток (одна или более входных меток ставится в соответствие одной выходной метке), так и в отсутствии объединения (одна метка ставится в соответствие выходной метке).
A.1.Получение уведомления / детектирование петли
Краткое изложение:
Когда LSR в ответ на запрос или сообщение присвоение метки получает от партнера статусный код, свидетельствующий о наличии петли, он ведет себя так, как если бы он получил уведомление об отсутствии маршрута.
Контекст:
Смотри "Получение уведомления / нет пути".
Алгоритм:
Смотри " Получение уведомления / нет пути"
Замечания:
Когда в ответ на запрос метки приходит уведомление о детектировании петли, оно приходит в TLV статусного кода. Когда это является откликом на присвоение метки, оно прибывает в TLV статусного кода сообщения об освобождении метки.
A.1.Получение уведомления / Нет пути
Краткое изложение:
Когда LSR получает от партнера LDP уведомление No Route в ответ сообщение запроса метки, его реакция диктуется процедурой Label No Route. LSR либо не будет предпринимать никаких действий, либо отложит запрос метки путем запуска таймера и пошлет запрос партнеру позднее, когда время таймера истечет.
Контекст:
LSR. LSR, обрабатывающий события.
FEC. FEC, для которого была запрошена метка.
Атрибуты. Атрибуты, ассоциированные с запросом метки.
MsgSource. LDP-партер, который послал сообщение уведомления.
Алгоритм:
| NoNH.1 | Стереть запись о запросе метки для FEC, посланном в MsgSource. |
| NoNH.2 | LSR выполняет процедуру Label No Route (нет пути для метки). |
Для запросов без дублирования
1. Goto NoNH.3.
Для повторного запроса
Записать отложенный запрос метки для FEC и атрибуты, которые нужно послать MsgSource.
Запуск таймаута. Goto NoNH.3.
NoNH.3 DONE.
A.1.Получение уведомления / Нет ресурсов для метки
Краткое изложение:
Когда LSR получает от LDP-партнера уведомление No Label Resources (нет ресурсов для метки), он прекращает посылать партнеру сообщения запросов метки до тех пор, пока не получит от партнера уведомление Label Resources Available (ресурсы имеются).
Контекст:
LSR. LSR, который обрабатывает событие.
FEC. FEC, для которого запрашивалась метка.
MsgSource. LDP-партнер, который послал уведомление.
Алгоритм:
| NoRes.1 | Стереть запись о запросе метки для FEC, посланный по адресу MsgSource |
| NoRes.2 | Нужна запись ассоциации метка-FEC от MsgSource, но нет ресурсов для метки |
| NoRes.3 | Установить статусную запись, индицирующую, что он не в порядке, чтобы послать MsgSource запрос метки. |
| NoRes.4 | DONE |
A.1.Получение уведомления / ресурсы для метки доступны
Краткое изложение:
Когда LSR получает от LDP-партнера уведомление о доступности ресурсов для метки, он возобновляет посылку запросов метки партнеру.
Контекст:
LSR. LSR, обрабатывающий событие.
MsgSource. LDP-партнер, который послал сообщение уведомления.
SAttributes. Атрибуты, запомненные с отложенным запросом метки.
Алгоритм:
| Res.1 | Установить статусную запись в состояние, указывающее на возможность отправки MsgSource запроса метки. |
| Res.2 | Начать итерацию через Res.6 для каждой записи ассоциации метка-FEC, необходимой MsgSource, для которой нет ресурсов. |
| Res.3 | Является ли MsgSource следующим шагом для FEC? Если нет, goto Res.5. |
| Res.4 | Исполнить процедуру Send_Label_Request(MsgSource, FEC, SAttributes) Если процедура не прошла, прервать итерацию. |
| Res.5 | Стереть запись о том, что нет ресурсов для ассоциации метка-FEC, нужной MsgSource. |
| Res.6 | Завершить итерацию в точке Res.2 |
| Res.7 | DONE. |
A.1.Получение уведомления/запрос метки аннулирован (Label Request Aborted)
Краткое изложение:
Когда LSR получает от LDP партнера уведомление о ликвидации запроса метки, он записывает, что транзакция соответствующего запроса метки, если таковая имелась, завершена.
Контекст:
LSR. LSR, обрабатывающий событие.
FEC. FEC, для которого запрашивалась метка.
RequestMessageID. ID сообщения запроса метки, который следует ликвидировать.
MsgSource. LDP партнер, который послал сообщение уведомления.
Алгоритм :
| LRqA.1 | Соответствует ли уведомление запросу метки для заданного FEC, который надлежит удалить? (Смотри примечание 1). Если нет, goto LRqA.3. |
| LRqA.2 | Записать, что запрос метки для данного FEC удален. |
| LRqA.3 | DONE |
Замечания:
1. LSR использует FEC и Request Message ID, чтобы локализовать свою запись, если она имеется, о ликвидируемом запросе метки.
A.1.Получение запроса ликвидации метки (Label Abort Request)
Краткое изложение:
Когда LSR получает от партнера сообщение запроса ликвидации метки, он проверяет, реагировал ли он уже на этот запрос. Если реагировал, то он молча игнорирует сообщение. Если не реагировал, он посылает партнеру уведомление подтверждения выполнения запроса ликвидации. Кроме того, если он имеет отложенный запрос для рассматриваемого LSP,он посылает нижерасположенному партнеру запрос ликвидации метки.
Контекст:
LSR. LSR, обрабатывающий события.
MsgSource. LDP партнер, который посылает сообщение.
FEC. FEC, специфицированный в сообщении.
RequestMessageID. ID сообщения запроса метки, подлежащего ликвидации.
Next Hop. Следующий шаг для FEC.
Алгоритм:
| LAbR.1 | Согласуется ли сообщение с полученным ранее запросом метки от MsgSource? (Смотри замечание 1.) Если нет, goto LAbR.12. |
| LAbR.2 | Среагировал ли LSR на ранее полученный запрос метки? Если да, goto LAbR.12. |
| LAbR.3 | Исполнить процедуру Send_ Message(MsgSource, Notification, Label Request Aborted, TLV), где TLV характеризует ID сообщения запроса метки, полученное в сообщение запроса ликвидации метки. |
| LAbR.4 | Имеется ли у LSR сообщение запроса метки для FEC? Если да, goto LAbR.7 |
| LAbR.5 | Имеет ли LSR ассоциацию метки и FEC? Если нет, goto LAbR.11 |
| LAbR.6 | Сгенерировать событие: От MsgSource получено сообщение освобождения метки для FEC. (Смотри замечание 2.) Goto LAbR.11. |
| LAbR.7 | Объединяет ли LSR метки LSP для FEC? Если нет, goto LAbR.9. |
| LAbR.8 | Отличаются ли вышестоящие партнеры от MsgSource, который запросил метку для FEC? Если да, goto LAbR.11. |
| LAbR.9 | Исполнить процедуру Send_Message(Next Hop, Label Abort Request, FEC, TLV), где TLV характеризует ID сообщения запроса метки, используемой LSR в сообщении запроса метки. |
| LAbR.10 | Записать, что запрос ликвидации метки для FEC в ожидании. |
| LAbR.11 | Стереть запись запроса метки для FEC от MsgSource. |
| LAbR.12 | DONE |
Замечания:
LSR использует FEC и TLV ID сообщения запроса метки, содержащееся в запросе ликвидации, чтобы найти свою запись (если таковая имеется) для полученного ранее от MsgSource запроса метки.
Если LSR получил ассоциацию метки от NextHop, он должен себя вести так, как если бы он анонсировал эту метку MsgSource, и MsgSource освободил ее.
A.1.Присвоение меток
Краткое изложение:
Отклик LSR на присылку FEC-метки от LDP-партнера может включать одну или более следующих операций:
Передача партнеру LDP сообщения освобождения метки для FEC;
Передача одному или более партнерам LDP сообщения присвоения метки для FEC,
Инсталляция LSR вновь полученных меток для переадресации пакетов.
Контекст:
LSR. LSR, обрабатывающий события.
MsgSource. LDP-партнер, который посылает сообщение.
FEC. Специфицированный в сообщении FEC.
Метка. Специфицированная в сообщении метка.
PrevAdvLabel. Метка для FEC, если имеется, ранее анонсированная вышестоящим партнером.
StoredHopCount. Число шагов ранее записанное для FEC.
RAttributes. Атрибуты, полученные с сообщением. Напр., число шагов, вектор пути.
SAttributes должны быть включены в сообщение присвоения метки, если имеются, то пересылаются вышестоящим партнерам.
Алгоритм:
| LMp.1 | Соответствует ли полученная метка запросу метки FEC, посланному ранее MsgSource. Если нет, goto LMp.3. |
| LMp.2 | Стереть запись запроса метки FEC. |
| LMp.3 | Выполнить процедуру Check_Received_Attributes (MsgSource, LabelMapping, RAttributes). Если не зарегистрировано петель, goto LMp.9. |
| LMp.4 | Получил ли LSR от MsgSource метку для FEC? (Смотри замечание 1.) Если нет, goto LMp.8. (Смотри замечание 2.) |
| LMp.5 | Соответствует ли требованиям метка, полученная ранее от MsgSource (т.e., метка полученная в сообщении)? (Смотри замечание 3) Если нет, goto LMp.8. (Смотри замечание 4.) |
| LMp.6 | Стереть ассоциацию метки для FEC, полученную ранее от MsgSource. |
| LMp.7 | Удалить метку из таблицы маршрутизации. (Смотри замечание 5.) Goto LMp.33. |
| LMp.8 | Исполнить процедуру Send_Message (MsgSource, Label Release, FEC, Label, Loop Detected Status code). Goto LMp.33. |
| LMp.9 | Получил ли LSR ранее ассоциацию метки и FEC от MsgSource для рассматриваемого LSP? (Смотри замечание 6.) Если нет, goto LMp.11. |
| LMp.10 | Соответствует ли метка, полученная ранее от MsgSource, метке в сообщении? (Смотри замечание 3.) Если нет, goto LMp.32. (Смотри замечание 4.) |
| LMp.11 | Определить следующий шаг для FEC. |
| LMp.12 | Является ли MsgSource следующим шагом для FEC? Если да, goto LMp.14. |
| LMp.13 | LSR выполнить процедуру освобождения метки: |
Для консервативного сохранения меток:
1. Goto LMp.32.
Для свободного сохранения меток:
1. Записать ассоциацию метки и FEC и RAttributes, полученные от MsgSource.
Goto LMp.33.
| LMp.14 | Является ли LSR входным для FEC? Если нет, goto LMp.16. |
| LMp.15 | Начать использование метки для переадресации пакетов. |
| LMp.16 | Запись ассоциации метка-FEC и RAttributes были получены от MsgSource. |
| LMp.17 | Продолжить итерацию через LMp.31 для каждого партнера. (Смотри замечание 7). |
| LMp.18 | Послал ли ранее LSR ассоциацию метки и FEC партнерам LSP? (Смотри замечание 8.) Если да, goto LMp.22. |
| LMp.19 | Используется ли LSR режим упорядоченного управления рассылкой меток Downstream Unsolicited? Если нет, goto LMp.28. |
| LMp.20 | Исполнить процедуру Prepare_Label_Mapping_Attributes Peer,FEC,RAttributes,SAttributes, IsPropagating, StoredHopCount). |
| LMp.21 | Исполнить процедуру Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). Goto LMp.28 |
| LMp.22 | Продолжить итерацию через LMp.27 для каждой ассоциации метки и FEC, посланной ранее партнеру. |
| LMp.23 | Являются ли RAttributes в полученной ассоциации метки взаимно согласующимися с ранее посланными партнеру? Если да, продолжить итерацию через LMp.22 для следующей метки. (Смотри замечание 9.) |
| LMp.24 | Выполнить процедуру Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount). |
| LMp.25 | Исполнить процедуру Send_Message(Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). (Смотри замечание 10.) |
| LMp.26 | Обновить запись ассоциации метки с FEC, посланную ранее партнеру, включить новые атрибуты. |
| LMp.27 | Завершить итерацию через LMp.22. |
| LMp.28 | Имеет ли LSR какие-либо запросы метки для FEC от партнера, помеченные как ожидающие? Если нет, goto LMp.30. |
| LMp.29 | LSR выполнить процедуру рассылки метки: |
Для упорядоченного управления в режиме Downstream unsolicited
Процедура исполнения
Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount).
Выполнить процедуру Send_Label (Peer, FEC, SAttributes). Если процедура терпит неудачу, продолжить итерацию для следующего партнера с LMp.17.
Если нет ожидающих запросов для партнера goto LMp.30. (Смотри замечание 11.)
Для независимого управления в режиме Downstream On Demand ИЛИ
Для упорядоченного управления в режиме Downstream On Demand
Продолжить итерацию через шаг 5 для каждого ожидающего запроса метки для FEC.
Исполнить процедуру Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount)
Исполнить процедуру Send_Label (Peer, FEC, SAttributes). Если процедура потерпела неудачу, продолжить итерацию для следующего партнера с LMp.17.
Стереть запись ожидающего запроса.
Завершить итерацию с шага 1.
Goto LMp.30.
| LMp.30 | LSR выполняет процедуру Label Use: |
для использования, когда нет детектированных петель
Продолжить итерацию через шаг 3 для каждой ассоциации метки и FEC, посланных ранее партнеру.
Начать применение метки, полученной и посланной партеру, для переадресации пакетов.
Завершить итерацию с шага 1.
Goto LMp.31.
| LMp.31 | Завершить итерацию через LMp.17. Goto LMp.33. |
| LMp.32 | Исполнить процедуру Send_Message (MsgSource, Label Release, FEC, Label). |
| LMp.33 | DONE. |
Если LSR способен объединять метки, он должен получить как минимум одну ассоциацию метки и FEC для рассматриваемого LSP. В случае без объединения может быть получено много ассоциаций меток для FEC.
Если LSR детектировал петлю и он ранее не получил от MsgSource ассоциацию метки и FEC, он просто освобождает метку.
Соответствует ли метка, полученная в сообщении, какой-либо одной или более ассоциаций, идентифицированных на предыдущем шаге (LMp.4 или LMp.9)?
Добровольная ассоциация с разными метками от одного и того же партнера будет пытаться установить коммутацию по меткам для нескольких путей, которая не поддерживается в данной версии LDP.
Если метка не используется для целей коммутации, шаг LMp.7 не имеет значения.
Если полученное сообщение присвоения метки, соответствует запросу шага LMp.1, тогда (по определению) LSR не получил ранее ассоциации метки и FEC. Если LSR объединяет полученные сверху метки для рассматриваемого LSP, тогда должна быть получена, по крайней мере, одна ассоциация. В случае без объединения, могут быть несколько ассоциаций меток для заданного FEC, по одной для каждого LSP.
LMp.17 итерация включает MsgSource, для того чтобы обработать случай, когда LSR работает в режиме упорядоченного управления Downstream Unsolicited. Упорядоченное управление предотвращает анонсирование метки LSR для FEC, до тех пор пока не получит ассоциацию метки с FEC от узла следующего шага (MsgSource).
Если LSR объединяет LSP, он может иметь ранее посланные ассоциации меток и FEC до одного или более партеров. Если LSR не может объединять метки, он может посылать ассоциации меток LSP по большей части до одного LSR.
При этом тестировании рассматривается атрибут детектирования петель в векторе пути. Если полученный RAttributes включает в себя вектор пути, и ранее партнеру вектор пути не посылался, или если полученный вектор пути не согласуется с аналогичным вектором, посланным ранее партнеру, тогда атрибуты считаются несогласованными. Заметим, что от LSR не требуется запоминание полученного вектора пути, после того как он переслал вектор в сообщении ассоциации метки. Если LSR не запоминает вектор пути, у него нет способа проверить взаимную согласованность вновь полученного вектора пути. Это означает, что когда бы LSR ни получал сообщение, содержащее вектор пути, он должен всегда передавать его дальше.
Шаги с LMp.22 по LMp.27 имеют дело с ситуацией, которая может иметь место, когда LSR использует независимое управление и получает метки со стороны нижерасположенного партнера, после этого он посылает эти сообщения вверх по течению. В этой ситуации LSR следует передавать любые изменения атрибутов, таких как число шагов, вверх. Если сконфигурировано детектирование петель, передаваемые атрибуты должны содержать вектор пути.
LSR, работающий в режиме Downstream Unsolicited, должен обработать любое приходящее сообщение запроса метки. Если имеются отложенные запросы метки, переходим в режим Downstream on Demand, для того чтобы удовлетворить отложенные запросы.
A.1.Распознавание нового FEC
Краткое изложение:
Отклик LSR на получение данных о новом FEC из маршрутной таблицы может включать в себя одну или более операций:
Передача ассоциации метка-FEC одному или более партнерам LDP;
Передача запроса метки для FEC узлу следующего шага;
Любая из этих операций может реализоваться, когда LSR получает ассоциацию метка-FEC от узла следующего шага.
Контекст:
LSR. LSR, обрабатывающий события.
FEC. Вновь распознанный FEC.
Next Hop. Следующий шаг для FEC.
InitAttributes. Атрибуты, которые должны быть сопряжены с новым FEC. (Смотри замечание 1).
SAttributes. Атрибуты, которые должны быть включены в ассоциацию метки или в сообщение запроса метки, если они имеются, то посылаются партнеру.
StoredHopCount. Число шагов, сопряженное с ассоциацией метка-FEC, (если имеется) полученное ранее от узла следующего шага.
Алгоритм:
FEC.1 Выполнение LSR процедуры рассылки меток:
Для независимого управления в режиме Downstream Unsolicited
Осуществить итерацию через шаг 5 для каждого из партнеров.
Получил ли LSR ранее и сохранил ли ассоциацию метка-FEC от узла следующего шага? Если да, установить флаг рассылки равным IsPropagating. Если нет, - установить равным NotPropagating.
Исполнить процедуру Prepare_Label_Mapping_Attributes(Peer, FEC, InitAttributes, SAttributes, Propagating, Unknown hop count(0)).
Исполнить процедуру Send_Label (Peer, FEC, SAttributes)
Завершить итерацию через шаг 1. Goto FEC.2.
Для упорядоченного управления в режиме Downstream Unsolicited
Выполнить итерацию через шаг 5 для каждого из партнеров.
Является ли LSR выходным для этого FEC? ИЛИ получил ли LSR ранее от узла следующего шага и сохранил ли ассоциацию метка-FEC?
Если нет, продолжить итерацию для следующего партнера.
Исполнить процедуру Prepare_ Label_ Mapping_Attributes( Peer, FEC, InitAttributes, SAttributes, Propagating, StoredHopCount).
Исполнить процедуру Send_Label (Peer, FEC, SAttributes)
Завершить итерацию в точке 1. Goto FEC.2.
Для независимого управления в режиме Downstream On Demand ИЛИ
Для упорядоченного управления в режиме Downstream On Demand
1. Goto FEC.2. (Смотри замечание 2.)
| FEC.2 | Получил ли LSR ранее от узла следующего шага и сохранил ли ассоциацию метка-FEC? Если да, goto FEC.5 |
| FEC.3 | Является ли следующим шагом партнер LDP? Если нет, Goto FEC.6 |
| FEC.4 | LSR выполняет процедуру запроса метки: |
1. Goto FEC.6
Для запроса, когда необходимо ИЛИ
для запроса по запросу
Исполнить процедуру Prepare_Label_Request_Attributes(Next Hop, FEC, InitAttributes, SAttributes);
Исполнить процедуру Send_Label_Request (Next Hop, FEC, SAttributes).
Goto FEC.6.
| FEC.5 | Генерировать событие: От узла следующего шага получена ассоциация метки. (Смотри замечание 3.) |
| FEC.6 | DONE. |
Примером атрибута, который может быть частью InitAttributes, является атрибут спецификации желательных характеристик LSP, таких как класс услуг ( CoS). (Заметим, что в то время как текущая версия LDP не специфицирует атрибут CoS, это могут делать расширения).
Заметим, что InitAttributes не включают в себя известное число шагов или вектор пути.
LSR, использующий режим рассылки меток Downstream On Demand, пошлет метку, только если он ранее получил запрос метки, помеченный как ожидающий. LSR не будет иметь таких ждущих запросов, так как он реагирует на любой запрос метки для неизвестного FEC путем посылки запрашивающему LSR уведомления No Route (нет маршрута) и отбрасыванием такого запроса; смотри LRq.3
Если LSR имеет метку для данного FEC от узла следующего шага, он должен вести себя так, как если бы он только что получил метку от узла следующего шага. Это происходит в случае работы в режиме свободного удержания метки.
A.1.Запрос получения метки
Краткое изложение:
Отклик LSR на подтверждение запроса FEC-метки от партнера LDP может включать одну или более операций:
Cообщение уведомления запрашивающему LSR, объясняющее, почему не может быть присвоена метка для данного FEC;
Передача сообщения присвоения метки для FEC запрашивающему LSR;
Передача узлу следующего шага запроса метки для FEC;
Инсталляция меток для переадресации пакетов LSR.
Контекст:
LSR. LSR, обрабатывающий событие.
MsgSource. LDP-партнер, который посылает сообщение.
FEC. FEC, специфицированный в сообщении.
RAttributes. Атрибуты, полученные в сообщении. Например, число шагов, вектор пути.
SAttributes. Атрибуты, подлежащие включению в сообщение запроса метки, и передаваемые узлу следующего шага FEC.
StoredHopCount. Число шагов, если таковые имеются, записанные ранее для FEC.
Алгоритм:
| LRq.1 | Исполняемая процедура Check_Received_Attributes (MsgSource, LabelRequest, RAttributes). Если детектирована петля, goto LRq.13. |
| LRq.2 | Имеется следующий шаг для FEC? Если нет, goto LRq.5. |
| LRq.3 | Является ли MsgSource следующим шагом? Если нет, goto LRq.6. |
| LRq.4 | Исполняется процедура Send_Notification (MsgSource, Loop Detected). Goto LRq.13 |
| LRq.5 | Исполняется процедура Send_Notification (MsgSource, No Route). Goto LRq.13. |
| LRq.6 | LSR получил запрос метки для FEC от MsgSource? Если нет, goto LRq.8. (Смотри замечание 1.) |
| LRq.7 | Является ли запрос метки задублированным? Если да, Goto LRq.13. (Смотри замечание 2.) |
| LRq.8 | Записать запрос метки для FEC, полученный от MsgSource и пометить его, как ожидающий. |
| LRq.9 | LSR выполняет процедуру рассылки метки: |
Для независимого управления в режиме Downstream Unsolicited ИЛИ
Для независимого управления в режиме Downstream On Demand
Получил ли LSR и сохранил ли метку от узла следующего шага для FEC?.
Если да, установить переадресацию на IsPropagating.
Если нет, установить переадресацию на NotPropagating.
Исполняемая процедура
Prepare_Label_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, Propagating, StoredHopCount).
Исполнить процедуру Send_Label (MsgSource, FEC, SAttributes).
Является ли LSR выходным для FEC? ИЛИ
Получил ли LSR и сохранил ли метку от узла следующего шага для FEC?
Если да, goto LRq.11. Если нет, goto LRq.10.
Для упорядоченного управления в режиме Downstream Unsolicited ИЛИ
для упорядоченного управления в режиме Downstream On Demand
Является ли LSR выходным для FEC? ИЛИ
Получил ли LSR и сохранил ли метку от узла следующего шага для FEC? (Смотри замечание 3.) Если нет, goto LRq.10.
Исполняемая процедура
Prepare_Label_Mapping_Attributes(MsgSource,FEC,RAttributes,SAttributes,IsPropagating,StoredHopCount)
Исполнить процедуру Send_Label(MsgSource, FEC, SAttributes).
Goto LRq.11.
| LRq.10 | LSR выполнить процедуру запроса метки: |
1. Goto LRq.13.
Для режима запрос по необходимости ИЛИ
для режима запрос на запрос
Исполнить процедуру Prepare_Label_Request_Attributes (Next Hop, FEC,RAttributes, SAttributes);
Исполнить процедуру Send_Label_Request (Next Hop, FEC, SAttributes).
Goto LRq.13.
| LRq.11 | Послал ли LSR успешно метку для FEC в MsgSource? Если нет, goto LRq.13. (Смотри замечание 4.) |
| LRq.12 | LSR выполнить процедуру Label Use. |
для применения, если петля не детектирована
1. Инсталлировать метку, посланную MsgSource и метку из узла следующего шага (если LSR не является выходным) для выполнения переадресации.
LRq.13 DONE
Замечания:
В случае, когда MsgSource является LSR, неспособным объединять метки, он пошлет запрос метки каждому партнеру LDP выше по течению, с целью получения метки для заданного FEC. LSR должен быть способен отличать такие запросы от MsgSource без поддержки объединения от дублирующих запросов метки.
LSR использует сообщения, полученного запроса метки, чтобы детектировать дублирующие запросы. Это означает, что LSR (партнер выше по течению) не может повторно использовать ID сообщения, примененного в запросе метки, до завершения транзакции запроса метки.
Когда LSR посылает партнеру запрос метки, он записывает, что этот запрос послан и помечает его как предстоящий. Пока запрос помечен предстоящим, LSR не должен посылать другой запрос метки тому же партнеру. Такой второй запрос был бы дублирующим. Процедура Send_Label_Request, описанная ниже подчиняется этому правилу.
Дублирующий запрос метки рассматривается как протокольная ошибка и должен отбрасываться LSR-получателем (возможно с соответствующим уведомлением пославшему MsgSource).
Если LSR не поддерживает объединение меток, такая проверка потерпит неудачу.
Процедура Send_Label может потерпеть неудачу из-за недостатка ресурсов для меток, в таком случае LSR не должен выполнять процедуру Label Use.
A.2.Check_Received_Attributes
Краткое изложение:
Проверка атрибутов, полученных в сообщении присвоения метки или в запросе метки. Если атрибуты включают в себя число шагов или вектор пути, выполнить проверку наличия петли. Если петля обнаружена, послать MsgSource уведомление о детектировании петли.
Параметры:
MsgSource. LDP партнер, который посылает сообщение.
MsgType. Тип полученного сообщения.
RAttributes. Атрибуты в сообщении.
Дополнительный контекст:
LSR Id. Уникальный Id данного LSR.
Hop Count. Число шагов, если таковые имеются в полученных атрибутах.
Path Vector. Вектор пути, если таковой имеется в полученных атрибутах.
Алгоритм:
| CRa.1 | Включает ли в себя RAttributes число шагов? Если нет, goto CRa.5. |
| CRa.2 | Превышает ли число шагов максимально допустимый порог? Если да, goto CRa.6. |
| CRa.3 | Включает ли в себя RAttributes вектор пути? Если нет, goto CRa.5. |
| CRa.4 | Включает ли в себя вектор пути Id LSR? ИЛИ превышает ли длина вектора пути максимально допустимый порог? Если да, goto CRa.6 |
| CRa.5 | Прислать в ответ No Loop Detected (петель не зарегистрировано). |
| CRa.6 | Является ли MsgType (тип сообщения) LabelMapping? Если да, goto CRa.8. (Смотри замечание 1.) |
| CRa.7 | Исполнить процедуру Send_Notification(MsgSource, Loop Detected) |
| CRa.8 | Прислать флаг обнаружения петли |
| CRa.9 | DONE |
Замечания:
Когда проверяемые атрибуты получены в сообщении присвоения метки, LSR посылает уведомление об обнаружении петли в TLV статусного кода сообщения об освобождении метки. Смотри раздел "Получение присвоения метки".
A.2.Prepare_Label_Mapping_Attributes
Краткое изложение:
Эта процедура используется всякий раз, когда нужно послать партнеру сообщение присвоения метки, содержащее число шагов и вектор пути.
Параметры:
Peer. LDP-партнер, которому посылается сообщение.
FEC. FEC, для которого посылается запрос метки.
RAttributes. Атрибуты, которые этот LSR ассоциирует с LSP для FEC.
SAttributes. Атрибуты, подлежащие включению в сообщение присвоения метки.
IsPropagating. LSR посылает сообщение присвоения метки, чтобы реализовать рассылку метки, которую он получил от узла следующего шага для заданного FEC.
PrevHopCount. Число шагов, которые LSR ассоциирует с LSP для FEC.
Дополнительный контекст:
LSR Id. Уникальный Id данного LSR.
Алгоритм:
| PMpA.1 | Нужно ли число шагов для данного партнера (смотри замечание 1.)? ИЛИ Включает ли RAttributes число шагов? ИЛИ Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PMpA.21. |
| PMpA.2 | Является ли LSR выходным для FEC? Если нет, goto PMpA.4. |
| PMpA.3 | Включить число шагов 1 в SAttributes. Goto PMpA.21. |
| PMpA.4 | Имеет ли RAttributes число шагов? Если нет, goto PMpA.8. |
| PMpA.5 | Является ли LSR краевым для домена, чьи LSR не осуществляют декрементацию TTL И Находится ли партнер в этом домене (Смотри замечание 2). Если нет , goto PMpA.7. |
| PMpA.6 | Включить число шагов 1 в SAttributes. Goto PMpA.9. |
| PMpA.7 | Инкрементировать число шагов RAttributes и скопировать результат в SAttributes. Смотри замечание 2. Goto PMpA.9. |
| PMpA.8 | Включить число шагов = unknown (0) в SAttributes. |
| PMpA.9 | Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PMpA.21. |
| PMpA.10 | Имеют ли RAttributes вектор пути? Если да, goto PMpA.19. |
| PMpA.11 | Пересылает ли LSR полученные данные о присвоенных метках? Если нет , goto PMpA.20. |
| PMpA.12 | Поддерживает ли LSR объединение меток? Если нет, goto PMpA.14. |
| PMpA.13 | Посылал ли LSR партнеру ранее сообщение присвоения метки для FEC? Если нет, goto PMpA.20. |
| PMpA.14 | Включает ли RAttributes число шагов? Если нет, goto PMpA.21. |
| PMpA.15 | Равно ли число шагов в Rattributes unknown (0)? Если да, goto PMpA.20. |
| PMpA.16 | Посылал ли LSR ранее партнеру сообщение присвоения метки для FEC? Если нет goto PMpA.21. |
| PMpA.17 | Отличается ли число шагов в RAttributes от PrevHopCount? Если нет goto PMpA.21. |
| PMpA.18 | Является ли число шагов в RAttributes > PrevHopCount? ИЛИ Является ли PrevHopCount unknown(0) Если нет, goto PMpA.21. |
| PMpA.19 | Добавить Id LSR в начало вектора пути из RAttributes и скопировать результат в SAttributes. Goto PMpA.21. |
| PMpA.20 | Включить вектор пути длиной 1, содержащий Id LSR в SAttributes. |
| PMpA.21 | DONE. |
Замечания:
Канал до партнера может требовать, чтобы число шагов было включено в сообщения присвоения метки; например, смотри [RFC3035] и [RFC3034].
Если LSR является пограничным для облака LSR, которые не выполняют декрементацию TTL и он осуществляет пересылку сообщений присвоения меток вверх по течению в этом облаке, он устанавливает число шагов равным 1, так что число шагов через облако оказывается вычисленным верно. Это гарантирует правильное управление TTL для пакетов переадресуемых через область LSP, которая проходит через облако.
Для арифметики числа шагов, unknown + 1 = unknown.
Назад:
Оглавление:
Вперёд:
A.2.Prepare_Label_Request_Attributes
Краткое изложение:
Эта процедура используется всякий раз, когда нужно послать партнеру запрос метки, чтобы вычислить число шагов и вектор пути для включения в сообщение.
Параметры:
Peer. LDP-партнер, которому должно быть послано сообщение.
FEC. FEC, для которого нужно послать запрос метки.
RAttributes. Атрибуты, которые этот LSR ассоциирует с LSP для FEC.
SAttributes. Атрибуты, которые следует включить в сообщение запроса метки.
Дополнительный контекст:
LSR Id. Уникальный Id данного LSR.
Алгоритм :
| PRqA.1 | Нужно ли число шагов данному партнеру (Смотри замечание 1.)? ИЛИ Содержат ли RAttributes число шагов? ИЛИ Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PRqA.14. |
| PRqA.2 | Является ли LSR входным для FEC? Если нет, goto PRqA.6. |
| PRqA.3 | Включить число шагов 1 в SAttributes. |
| PRqA.4 | Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PRqA.14. |
| PRqA.5 | Способен ли LSR объединять метки? Если да, goto PRqA.14. Если нет, goto PRqA.13. |
| PRqA.6 | Включают ли RAttributes в себя число шагов? Если нет, goto PRqA.8. |
| PRqA.7 | Инкрементировать число шагов в RAttributes и копировать полученное значение в SAttributes. (Смотри замечание 2.) Goto PRqA.9. |
| PRqA.8 | Включить число шагов = unknown 0) в SAttributes. |
| PRqA.9 | Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PRqA.14. |
| PRqA.10 | Имеют ли RAttributes вектор пути? Если да, goto PRqA.12. |
| PRqA.11 | Способен ли LSR объединять метки? Если да, goto PRqA.14. Если нет, goto PRqA.13. |
| PRqA.12 | Добавить Id LSR в начало вектора пути из RAttributes и скопировать результат в SAttributes. Goto PRqA.14. |
| PRqA.13 | Включить вектор пути с длиной 1, содержащий Id LSR в SAttributes. |
| PRqA.14 | DONE. |
Замечания:
Канал с партнером может требовать, чтобы число шагов было включено в запрос метки; смотри, например [RFC3035] и [RFC3034].
Для арифметики числа шагов, unknown + 1 = unknown.
A.2.Send_Label
Краткое изложение:
Процедура Send_ Label, если возможно, присваивает метку для LDP партнерf, и посылает партнеру ассоциацию метка-FEC. Если LSR не может присвоить метку, и если он имеет отложенный запрос метки от партнера, он посылает LDP-партнеру уведомление No Label Resources (нет ресурсов для метки).
Параметры:
Партнер. LDP-партнер, которому следует послать ассоциацию метки.
FEC. FEC, для которого послана присвоенная метка.
Атрибуты. Атрибуты, подлежащие включению в ассоциацию метки.
Дополнительный контекст:
LSR. LSR, выполняющий процедуру.
Метка. Присвоенная метка, посланная партнеру.
Алгоритм:
| SL.1 | Должен ли LSR присвоить метку? Если нет, goto SL.9. |
| SL.2 | Присвоить метку и связать ее с FEC. |
| SL.3 | Ввести метку в таблицу маршрутизации. |
| SL.4 | Исполнить процедуру Send_Message(Peer, Label Mapping, FEC, Label, Attributes). |
| SL.5 | Записать ассоциацию метка-FEC и атрибуты, посланные партнеру. |
| SL.6 | Имеет ли LSR запись запроса метки от партнера, помеченную, как отложенная? Если нет, goto SL.8. |
| SL.7 | Стереть запись отложенного запроса метки партнера |
| SL.8 | Вернуть флаг успеха. |
| SL.9 | Имеет ли LSR запрос метки для FEC от партнера, помеченный как отложенный? Если нет, goto SL.13. |
| SL.10 | Исполнить процедуру Send_Notification(Peer, No Label Resources). |
| SL.11 | Стереть запись отложенного запроса метки, поступившего от партнера. |
| SL.12 | Запись уведомления No Label Resources послана партнеру. Goto SL.14. |
| SL.13 | Нужна запись присвоения метки для FEC и атрибуты для партнера, но нет ресурсов для метки. (Смотри замечание 1.) |
| SL.14 | Вернуть флаг неудачи. |
Замечания:
SL.13 обрабатывает ситуацию рассылки меток в режиме Downstream Unsolicited, когда LSR неспособен присвоить метку для FEC, чтобы послать партнеру.
A.2.Send_Label_Request
Краткое изложение:
LSR использует процедуру Send_Label_Request для посылки партнеру LDP запроса метки для FEC, если в текущий момент это разрешено.
Параметры:
Партнер. LDP-партнер, которому следует послать запрос метки.
FEC. FEC, для которого послан запрос метки.
Атрибуты. Атрибуты, подлежащие включению в запрос метки. Например, число шагов, вектор пути.
Дополнительный контекст:
LSR. LSR, выполняющий процедуру.
Алгоритм:
| SLRq.1 | Был ли ранее послан партнеру запрос метки для FEC и помечен ли он как неисполненный? Если да, вернуть флаг успеха. (Смотри замечание 1.) |
| SLRq.2 | Свидетельствует ли статусная запись о готовности послать запросы метки набору партнеров? Если нет, goto SLRq.6 |
| SLRq.3 | Исполнить процедуру Send_Message(Peer, Label Request, FEC, Attributes). |
| SLRq.4 | Запись запроса метки для FEC была послана партнеру и помечена как нереализованная. |
| SLRq.5 | Вернуть флаг успеха |
| SLRq.6 | Отложить запрос метки путем записи ассоциации метка- FEC и необходимых атрибутов от партнера в ситуации, когда ресурсов для метки нет. |
| SLRq.7 | Вернуть флаг неудачи. |
Замечания:
Если LSR не может объединять метки, он должен различать попытки посылки запросов меток для FEC, отправленные разными вышестоящими LDP-партнерами, от дублирующих запросов. Эта процедура не посылает дублирующих запросов меток.
A.2.Send_Label_Withdraw
Краткое изложение:
LSR использует процедуру Send_Label_Withdraw (посылка запроса отзыва метки), чтобы отозвать метку для данного FEC у LDP-партнера. Чтобы выполнить это, LSR посылает партнеру сообщение отзыва метки (Label Withdraw).
Параметры:
Партнер. LDP партнер, которому должно быть послано сообщение отзыва метки.
FEC. FEC, для которого должна быть отозвана метка.
Метка. Метка, подлежащая отзыву.
Дополнительный контекст:
LSR. LSR, выполняющий процедуру.
Алгоритм:
| SWd.1 | Исполнить процедуру Send_Message(Peer, Label Withdraw, FEC, Label) |
| SWd.2 | Запись отзыва метки для FEC была помечена как нереализованная и послана партнеру. |
A.2.Send_Message
Краткое изложение:
LSR использует процедуру Send_Message, чтобы послать LDP-партнеру LDP-сообщение.
Параметры:
Peer. LDP партнер, которому надо послать сообщение.
Message Type. Тип сообщения, которое нужно послать.
Дополнительное содержимое сообщения . . . .
Алгоритм:
Эта процедура является средством, с помощью которого LSR отправляет LDP-сообщение специфицированного типа специфицированному LDP-партнеру.
