Автор: Тарас Юшков. Рубрики: Сети и телекоммуникации. Опубликовано: Апрель 2nd, 2010

Протокол LDP регламентируется стандартом IETF «LDP Specification» RFC 3036. Протокол LDP функционирует в рамках архитектуры MPLS. Для полного понимания работы LDP рекомендуется сначала ознакомиться с данной архитектурой.

Назначение протокола LDP

Протокол LDP предназначен для построения целостных маршрутов коммутации по меткам LSP.

Установка соседских отношений

Установление соседских отношений между маршрутизаторами осуществляется в две фазы:

1. обмен сообщениями Hello;
2. установление сессии LDP.

Фаза №2 исполняется только при успешном выполнении фазы №1.

Обмен сообщениями Hello

Сообщения Hello посылаются маршрутизатором через все интерфейсы, на которых включен LDP, каждые 15 секунд на адрес 224.0.0.2 (all-routers), порт 646, транспортный протокол UDP. Возможен обмен сообщений Hello и между LSR-ами не соединенными непосредственно. В этом случае сообщение посылается на уникастовый адрес.
Сообщения Hello содержат следующую информацию:
Holddown timer — промежуток времени, в течении которого, соседи должны послать хотя бы одно сообщение Hello. Если соседи предлагают разное значение, то принять они должны минимальное. Так как протокол UDP не обеспечивают гарантии доставки, то рекомендуется посылать сообщения Hello с периодом в три раза меньшим, чем Holddown timer. Если Holddown timer равен 0, то принимаются следующие значения по умолчанию:

• 15с — для обыкновенных hello сообщений на адрес all-routers;
• 45c — для сообщений посылаемых на конкретный адрес (Targeted Hello).

Значение Holddown timer равное 0xFFFF означает бесконечность, но зачем оно — RFC умалчивает.
T bit — (Targeted Hello) если данный бит 1, то это означает, что сообщение послано на конкретный (unicast) адрес, иначе сообщение послано на 224.0.0.2.
R bit — (Request Send Targeted Hellos) если данный бит 1, то это означает, что получатель должен ответить на это сообщение (Hello), иначе не должен. Данный бит может быть установлен в 1, только в случае если T-bit=1.


Примечание: Targeted Hello используются при реализации дополнительного функционала на базе MPLS.


Transport Address — данное поле в Hello пакете не обязательно. Если оно присутствует, то адрес, указанный в нем, используется в дальнейшем для установления LDP сессии между устройствами. Если данное поле отсутствует, то для установления сессии должен использоваться адрес источника Hello пакета. Адрес, используемый для установки LDP сессии, мы будем называть «транспортный адрес».
Configuration Sequence Number — Поле содержит номер конфигурации. При изменении настроек на LSR, соответственно меняется этот номер. Изменение номера может вызывать переустановление LDP сессии (а может и не вызывать — RFC тут не однозначно).
Сообщения hello могут отбрасываться, и соответственно, фаза №1 установления соседских отношений может быть не выполнена, в силу следующих  причин:

• LSR-у административно запрещено принимать сообщения hello определенного типа (например, TargetHello) или с определенного адреса;
•  Не совпадения типов транспортных адресов (например, IPv4 и IPv6).

Установление LDP сессии

LDP сессия функционирует по верх TCP/IP (порт 646). LSR1 и LSR2 при обмене сообщениями hello узнают транспортные адреса друг друга. Если транспортный адрес LSR1 больше чем транспортный адрес LSR2, то LSR1 становиться «активным» соседом, а LSR2 «пассивным», иначе, наоборот. Далее, LDP сессия устанавливается по следующему сценарию:

1. «Активный» сосед устанавливает TCP/IP сессию на порт 646.
2. «Активный» сосед посылает сообщение Init, включающее в себя свои параметры LDP сессии (формат см.далее).
3. «Пассивный» сосед проверяет параметры LDP сессии в сообщении Init на предмет совместимости с локальными настройками LDP.
4. «Пассивный» сосед отвечает сообщением Init , включающее в себя свои параметры LDP сессии.
5. «Активный сосед проверяет параметры LDP сессии в сообщении Init на предмет совместимости с локальными настройками LDP
6. Сессия установлена.

Если на каком-то этапе происходит что-то не предвиденное (приходит не тот тип пакета, ожидаемое сообщение не приходит вообще, или не совпадают параметры LDP сессии в сообщении Init и т.п.), то сессия считается не установленной. LSR, обнаруживший ошибку посылает сообщение Shutdown или Reject своему соседу.

Сообщение Init

Сообщение Init содержит следующую информацию:
Protocol Version — версия протокола.
KeepAlive Time — максимальное время между служебными сообщениями KeepAlive. Обе стороны могут предлагать различные значения — использоваться должно минимальное.
A-bit, Label Advertisement Discipline — режим обмена информацией о метках. Возможно использование двух режимов обмена информацией о метках:

• 1 — Downstream On Demand;
• 0 — Downstream Unsolicited.

D-but, Loop Detection — механизм предотвращения циколов LSP. 0 — выключен, 1 — включен.
PVLim, Path Vector Limit — Переменная используется для работы механизма предотвращения циклов.
Max PDU Length — LDP сообщения группируются в PDU (Protocol Data Units) и передаются в одном пакете TCP/IP. Max PDU Length — означает максимально возможную длину совмещенных сообщений LDP в байтах. Соседи могут предлагать различные значения, но оба должны выбрать минимальное. Заметим, что даже одно сообщение упаковывается внутрь PDU.
Receiver LDP Identifier — Идентификатор пространства меток (или Label Space Identifier). Формат поля следующий: LSR_ID:Label_Space_ID. LSR_ID это идентификатор LSR. Данный идентификатор должен быть уникален в рамках домена MPLS и един для каждого LSR-а. Label_Space_ID — это идентификатор множества меток. Label Space Identifier указывается в заголовке PDU, идентифицируя тем самым соседа и интерфейс по которому установлено соседство. Например, два LSR-а могут быть соединены двумя каналами, и для каждого канала должен быть выделен разные Label Space Identifier, отличаться которые будут только значением Label_Space_ID.


Примечание: Сообщение Init так же содержит несколько дополнительных, необязательных полей, описание которых опущено. Толку от этих полей в сетях IP все равно нет.


LDP сессия устанавливается при выполнении следующих условий:

• совпадение версий протокола (в прямую RFC этого не требует, но если в этом поле будет что-то неожиданное, уважающий себя LSR не установит LDP сессию);
• совпадение значений А-бит, в сети на разных соединениях возможно использование различных режимов распространения информации о метках, но на одном соединение режим должен совпадать.

Несовпадение PVLim, в соответствии с RFC не должно приводить к закрытию сесси, но может вызывать предупреждение на LSR.

Сообщения KeepAlive

За каждой сессией LDP LSR должен закреплять таймер. После получения любого сообщения LDP, LSR устанавливает таймер в 00:00 и снова запускает его. До достижения таймером значения «KeepAlive Time» соседний  LSR должен прислать любое LDP сообщение. Если у соседа нет информативных сообщений для пересылки, то он должен послать сообщение KeepAlive.


Примечание: При конкретной реализации таймер может работать как от 00:00 до «KeepAlive Time», так и в обратную сторону.


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

Обмен информацией о метках

Рассмотрим схему представленную на рис. №1.

С точки зрения LSR1 для FEC 10.1.1.0/24 соседей LSR1 можно разделить на две группы:

•  Upstream LSR-ы — это LSR3, LSR4.
•  Downstream LSR — это LSR2. Иначе Downstream LSR можно назвать next-hop-LSR (NH-LSR).

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

Существует несколько параметров функционирования LDP:

•  режим обмена информацией о метках (Label Distribution Mode)
•  режим контроля над распространением меток (Label Distribution Control)
•  механизм сохранения меток (Label Retention Mode)

Режим обмена информацией о метках

Между соседями возможно использования двух режимов обмена информацией о метках:

•  Downstream On Demand — с запросом;
•  Downstream Unsolicited — без запроса.

При режиме Downstream On Demand LSR должен запрашивать метку для создания LSP (для FEC) от соседнего LSR, который является next-hop-ом для этого FEC. При режиме Downstream Unsolicited LSR для каждого FEC находящегося у него в таблице IP-маршрутизации назначает метку и рассылает ее всем своим соседям. Если для соседнего LSR исходный LSR является next-hop-ом, то метка устанавливается в таблицу коммутации.

Механизм контроля над распространением меток

Также существует несколько механизмов контроля над распространением меток (Label Distribution Control Mode):

•  Independent Label Distribution Control — независимый контроль;
•  Ordered Label Distribution Control — упорядоченный контроль.

При использовании независимого контроля над распространением меток LSR может выделять метки для FEC своим соседям даже в случае, если LSR не имеет выходной метки для себя от следующего LSR. Если используется упорядоченный контроль над распространением меток, то LSR не будет выделять метки своим соседям, пока сам LSR не получит выходную метку для заданного FEC от NH-LSR-а. При этом режиме первый отсылает метку тот LSR, к которому непосредственно присоединен FEC.

Режим сохранения меток

Режим сохранения меток (Label Retention Mode):

• Conservative Label Retention Mode (сдержанный режим сохранения меток);
• Liberal Label Retention Mode (свободный режим сохранения меток).

При использовании сдержанного режима сохранения меток при уничтожении маршрута на FEC метка удаляется. Для восстановления LSP необходимо, что бы метка была заново выделена соседним NH-LSR-ом. Если используется свободный режим сохранения меток, то при
уничтожении маршрута на FEC метка не удаляется, а лишь помечается как неактивная. И в случае, если маршрут на FEC восстанавливается через тот же NH-LSR, то метка не запрашивается, а используется старая, статус которой меняется на активный.


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


Протокол LDP должен реагировать на следующие события:

•  появления новой записи FEC в таблице маршрутизации;
•  исчезновение записи FEC из таблицы маршрутизации;
•  смена next-hop для записи FEC.

Возможные комбинации режимов работы протокола LDP, а так же примеры функционирования приведены в табл. №1.
Табл. №1. Режимы функционирования протокола LDP.

Режим обмена информацией о метках Downstream Unsolicited Downstream Unsolicited Downstream Unsolicited Downstream On Demand Downstream On Demand
Механиз контроля над распростра-
нением меток
Independed Control Ordered Control Ordered Control Ordered Control Independed Control
Режим удержания меток liberal liberal conservative conservative conservative
появления новой записи FEC 1) Отсылаем всем соседям метки на все известные FEC.
2) Ожидаем метку от NH-LSR.
3) Используем полученную метку для коммутации
1) Ждем, пока придет метка от NH-LSR.
2) Отсылаем всем соседям метку на FEC
3) Используем полученную метку для коммутации
PS. Первый отсылает метку маршрутизатор присоединенный к FEC

1) Посылаем запрос NH-LSR о выделении метки
2) Ждем ответа
3) Используем полученную метку для коммутации.
смена next-hop для записи FEC 1) Ищем метку в списке «отложенных».
2) Если не находится то посылаем запрос NH-LSR о выделении метки, иначе п.4.
3) ждем ответа.
4) Используем полученную метку для коммутации.
1) Посылаем запрос NH-LSR о выделении метки
2) Ждем ответа
3) Используем полученную метку для коммутации
Получение запроса на выделение метки метку выделяем, не дожидаясь ответа от своего NH-LSR. метку выделяем только после ответа от своего NH-LSR. метку выделяем, не дожидаясь ответа от своего NH-LSR.

При исчезновении записи FEC из таблиц маршрутизации все LSR должны в обязательном порядке отозвать назначенные метки для коммутации FEC у своих соседей. Делается это посредством посылки сообщения Label Withdraw.

Механизм предотвращения циклов

Протокол LDP имеет в своем составе механизм предотвращения циклов. Назначение этого механизма не допускать зацикливания запросов и маршрутов. Данный эффект достигается включением во все сообщения Label Mapping и Label Mapping Request информации об LSR через которые данные запросы прошли. В случае если LSR-ы функционируют в режиме Ordered Control данный эффект достигается легко. Если LSR-ы используют Independed Control, то в этом случае LSR-ы должны заново отсылать запросы и ответы на них, так как информация о LSR-ах, через которые прошли запросы, будет обновляться.
Механизм предотвращения циклов может и не использоваться, так как по идее отсутствие циклов должен гарантировать протокол IP-маршрутизации, информацию от которого использует LDP.
Зацикливания могут возникать на не продолжительный период, только в случае если протокол IP-маршрутизации медленно сходиться и LDP работает быстрее, чем протокол IP-маршрутизации.

Типы сообщений LDP

В табл. №2 приведены типы LDP сообщений:
Табл. №2. Сообщения протокола LDP.

Сообщение Описание
Hello Сообщение используется для идентификации соседей, установления фазы №1 соседских отношений.
Init Сообщение используется для установления соседских отношений (фаза №2), обмена и согласования параметров LDP сессии.
KeepAlive Сообщение используется для поддержания активного статуса LDP сессии.
Address Message Сообщение используется для оповещения соседей о появлении новых, непосредственно присоединенных к LSR, IP сетей.
Address Withdraw Сообщение используется для оповещения соседей об исчезновении, непосредственно присоединенных к LSR, IP сетей.
Label Mapping Сообщение содержит описание FEC и метку, назначенную посылающим LSR-ом.
Label Request Данным сообщением LSR запрашивает у соседей метку для коммутации для конкретного FEC. Описание FEC включается в запрос.
Label Release Поддтверждение получения метки в сообщении Label Mapping. Посылается в случае, если метка запрашивалась Label Request-ом.
Label Abort Request Отмена запроса на выделение метки предворительно посланного в сообщении Label Request
Label Withdraw Отзыв назначенной метки у соседа. Сосед должне прекратить использовать отозванную метку для коммутации.

Поделиться

Опубликовать в Facebook
Опубликовать в Google Buzz
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс

Мы в социальных сетях

Читать ProITClub в TwitterЧитать ProITClub в RSSЧитать ProITClub в п&##1086;чтовой подпискеЧитать ProITClub в Живом ЖурналеЧитать ProITClub в LinkedInЧитать ProITClub в LinkedIn
Вы можете оставить комментарий, или поставить трэкбек со своего сайта.

Написать комментарий

Вы должны войти чтобы добавить сообщение.