Спецификация LDP, RSVPTE, GMPLS

Поддержка сессий LDP

LDP имеет механизмы мониторирования целостности LDP сессии. LDP использует получение регулярных LDP PDU откликов для контроля целостности сессии. LSR управляет таймером KeepAlive для каждой партнерской сессии. Таймер сбрасывается всякий раз при получении от партнера LDP PDU. Если время KeepAlive таймера истечет до получения от партнера LDP PDU, LSR считает, что транспортное соединение отказало или партнер вышел из строя, и завершает LDP сессию, разрывая транспортное соединение.

Рис. 12.1. Диаграмма состояний при инициализации сессии

После того как LDP-сессия установлена, LSR должен устроить так, чтобы партнер получал LDP PDU, по крайней мере, в течение каждого периода KeepAlive, чтобы гарантировать рестарт таймера сессии у партнера. LSR может послать любое протокольное сообщение, чтобы удовлетворить этому требованию. В условиях, когда LSR не имеет другой информации, чтобы взаимодействовать со своим партнером, он посылает сообщение KeepAlive.

LSR может решить прервать LDP сессию с партнером в любой момент. Если LSR принял такое решение, ему следует проинформировать партнера об этом с помощью сообщения Shutdown.

Рассылка меток и управление

Архитектура MPLS [RFC-3031] позволяет LSR рассылать данные о соответствии FEC и метки в ответ на прямой запрос другого LSR. Это называется рассылкой меток вниз по течению по запросу (Downstream On Demand). Это также позволяет LSR рассылать метки LSR, которые не запрашивали этого явно. [RFC-3031] называет этот метод рассылки меток свободной рассылкой вниз по течению (Unsolicited Downstream); здесь этот метод называется Downstream Unsolicited.

Оба эти метода рассылки могут работать в одной и той же сети одновременно. Однако, для любой заданной LDP сессии каждый LSR должен знать о методе рассылки меток, используемом его партнером, для того чтобы избежать ситуации, когда партнер, применяющий рассылку меток посредством Downstream Unsolicited, предполагает, что и его партнер делает то же самое.

Режим управления рассылкой меток

Поведение исходной конфигурации LSP определяется тем, работает ли LSR в режиме независимого или упорядоченного управления LSP. LSR может поддерживать оба типа управления.

При независимом управлении LSP каждый LSR может анонсировать метки своим соседям в любое время, когда он этого захочет. Например, работая в независимом режиме Downstream on Demand, LSR может отвечать на запросы присвоения меток немедленно, не дожидаясь присвоения меток со стороны ближайшего узла. При работе в независимом режиме Downstream Unsolicited, LSR может анонсировать присвоение меток для FEC своим соседям всякий раз, когда он готов осуществлять коммутацию для заданного FEC.

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

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

1. FEC относится к самому LSR (включая один из непосредственно связанных с ним интерфейсов);
2. маршрутизатор следующего шага для FEC находится за пределами сети с коммутацией по меткам;
3. элементы FEC достижимы при пересечении границы маршрутного домена, такого, как другая область сети OSPF или другая внешняя автономная система для OSPF и маршруты BGP [RFC-2328] [RFC-1771].

Заметим: тот факт, что LSR является выходным для данного FEC, может измениться со временем в зависимости от состояния сети и конфигурации LSR.

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

Архитектура MPLS [RFC-3031] вводит нотацию режима сохранения метки, которая специфицирует, поддерживает ли LSR соответствие меток для FEC, полученных от соседа, который не является следующим шагом для FEC.

В режиме Downstream Unsolicited, анонсирование меток всем маршрутизаторам может осуществляться всеми партнерами LSR. При использовании консервативного сохранения меток анонсированные метки сохраняются, только если они будут применены для переадресации пакетов (т.e., если они получены от корректного следующего узла маршрута). При работе в режиме Downstream on Demand LSR будет запрашивать метку только у LSR следующего шага согласно действующей маршрутизации. Так как режим Downstream on Demand в основном нужен, когда сохранение меток желательно (например, ATM-коммутатор с ограниченной зоной коммутаций), он обычно используется в режиме консервативного сохранения меток.

Главное преимущество консервативного режима заключается в том, что только метки, применяемые для переадресации данных, выделяются и поддерживаются. Это особенно важно в LSR, где пространство меток существенным образом ограничено (например, как в ATM-коммутаторах). Недостатком консервативного режима является то, что если для заданного адресата маршрутизация меняет следующий шаг, должна быть получена новая метка, прежде чем пакет будет переадресовываться.

В режиме Downstream Unsolicited выделение меток для всех маршрутов может осуществляться всеми LDP-партнерами. При использовании свободного режима сохранения меток каждая метка, присвоенная партнером LSR, сохраняется вне зависимости от того, является ли LSR узлом следующего шага для анонсированного соответствия. При работе в режиме Downstream on Demand со свободным сохранением меток LSR может запросить выделения меток для всех известных префиксов от всех партнеров LSR. Заметим, однако, что режим Downstream on Demand обычно используется для таких устройств, как ATM-коммутаторы, для которых рекомендуется консервативный подход.

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

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

Каждый интерфейс LSR сконфигурирован для работы в режиме анонсирования как Downstream Unsolicited, так и Downstream on Demand. LSR обмениваются данными о режимах анонсирования на фазе инициализации. Главное отличие между режимами Downstream Unsolicited и Downstream on Demand определяется тем, какой LSR берет на себя ответственность за инициализацию запросов выделения меток и их анонсирование.

Идентификаторы LDP и адреса следующего шага

LSR сохраняет полученные метки в информационной базе данных меток LIB (Label Information Base). При работе в режиме Downstream Unsolicited запись в LIB для адресного префикса ассоциирует набор пар (идентификатор LDP, метка) с префиксом, по одной записи для пары партнеров, анонсирующих метку для префикса.

Когда следующий шаг для префикса меняется, LSR должен извлечь соответствующую запись из LIB, чтобы выявить следующий шаг для переадресации. Чтобы получить метку, LSR должен быть способен установить соответствие между адресом следующего шага для префикса и идентификатором LDP.

Аналогично, когда LSR получает метку для префикса от партнера по LDP, он должен быть способен определить, является ли партнер в настоящее время следующим шагом для префикса и нужно ли использовать новую полученную метку для переадресации пакетов, соответствующих префиксу. Чтобы принять это решение, LSR должен быть способен установить соответствие между идентификатором LDP и адресами партнеров и проверить, являются ли они узлами следующего шага для заданного префикса.

Чтобы LSR мог установить соответствие между идентификаторами партнеров LDP и их адресами, LSR передают свои адреса, используя сообщения Address и Withdraw Address (отзыв адреса).

LSR посылает сообщение Address, чтобы предоставить свой адрес партнеру. LSR посылает сообщение Withdraw Address, чтобы отозвать адрес, присланный ранее партнеру.

Детектирование петель

Детектирование петель является конфигурируемой опцией, которая предоставляет механизм нахождения циклических сегментов LSP для предотвращения зацикливания сообщений запроса метки.

Механизм использует TLV вектора пути и числа шагов, содержащиеся в сообщениях запроса и присвоения метки. Он строится на следующих базовых свойствах этих TLV:

• TLV вектора пути содержит список LSR, через которые проходит сообщение, его содержащее. LSR идентифицируется в списке вектора с помощью уникальных Id LSR, которые являются первыми четырьмя октетами идентификатора его LDP. Когда LSR передает сообщение, содержащее TLV вектора пути, он добавляет в список вектора пути свой идентификатор (Id LSR). LSR, который получает сообщение с вектором пути, содержащим его Id, и регистрирует, что сообщение прошло по замкнутому пути (по петле). LDP поддерживает понятие максимально допустимой длины вектора пути. LSR, который детектирует, что вектор пути достиг максимальной длины, поступает так же, как в случае регистрации петлевого маршрута;
• TLV числа шагов содержит число LSR, которые прошло сообщение, где он располагается. Когда LSR пересылает сообщение, содержащее TLV числа шагов, он увеличивает это число на 1. LSR, который регистрирует, что число шагов достигло заданного при конфигурации максимума, ведет себя так, как если бы была зарегистрирована петля. Согласно договоренности, число 0 интерпретируется как неизвестное число шагов. Инкрементирование такого значения сохраняет его величину ( unknown =0 ).

Заметим, что TLV числа шагов и его процедуры используются без TLV вектора пути в ситуации, когда детектирование петель не предусмотрено на уровне конфигурации (смотри [RFC-3035] и [RFC-3034]).

Сообщение запроса метки

Применение TLV вектора пути и числа шагов предотвращает зацикливание сообщений запросов метки в среде, которая содержит LSR, не поддерживающие объединение меток (nonmerge).

Правила, которые управляют использованием 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 детектирует петлю, он должен послать отправителю запроса метки сообщение предупреждения об этом и выбросить полученное сообщение запроса метки.

Сообщение присвоения метки (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 детектирует петлю, он должен прекратить использование метки для переадресации, отбросить сообщение присвоения метки и с помощью специального сообщения сигнализировать отправителю о детектировании петли.

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

LSR, которые сконфигурированы для детектирования петель, могут не запоминать векторы пути в качестве части состояния LSP.

Заметим, что в сети, где присутствуют только LSR без возможности объединения, векторы пути передаются вниз по течению от входа к выходу и не передаются вверх по течению. Даже когда объединение меток поддерживается, векторы пути не передаются вверх по течению вдоль LSP. Когда для LSR меняется узел следующего шага, необходимо передавать векторы пути вверх по течению, только если невозможно судить по числу шагов, что изменение следующего шага не приведет к образованию петли.

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

Аутентичность и целостность сообщений LDP

Механизм защиты от введения фальсифицированных TCP-сегментов в потоки соединений LDP-сессии базируется на применении опции подписи TCP MD5, описанной в [RFC-2385] для BGP.

Использование LDP опции подписи TCP MD5

LDP использует опцию подписи TCP MD5 следующим образом.

• Применение подписи MD5 для TCP-соединений является конфигурируемой опцией LSR.
• LSR, который задействует опцию подписи MD5, конфигурируется с привлечением пароля (совместно используемый секретный ключ) для каждого потенциального партнера LDP.
• LSR применяет алгоритм MD5, как это специфицировано в [RFC-2385], чтобы вычислить дайджест MD5 для TCP-сегмента, посылаемого партнеру. При этом вычислении используется пароль партнера и сам TCP-сегмент.
• Когда LSR получает TCP-сегмент с дайджестом MD5, он проверяет сегмент, вычисляя дайджест MD5 (используя свою запись пароля) и сравнивает вычисленный дайджест с полученным. Если сравнение неудачно, сегмент отбрасывается, а отклик отправителю не посылается.
• LSR игнорирует сообщения LDP Hello от любого LSR, для которого не был сконфигурирован пароль. Это гарантирует, что LSR устанавливает TCP-соединение только с LSR, для которого пароль был задан.

Рассылка меток для LSP, маршрутизированных явно

Управление трафиком [RFC-2702] важно для MPLS-приложений. Протокол MPLS для управления трафиком поддерживает LSP, маршруты которых сформированы явно и которые не должны следовать традиционным маршрутам, формируемым по схеме шаг-за-шагом согласно маршрутным протоколам, базирующимся на адресе места назначения.

Спецификация протокола

Обмены сообщениями LDP осуществляются путем посылки протокольных данных LDP (PDU) через LDP-секцию TCP-соединений.

Каждый LDP PDU может содержать более одного LDP-сообщения. Заметим, что сообщения в LDP PDU не обязательно должны быть связанными. Например, один PDU может содержать сообщение анонсирования FEC-метки для нескольких FEC, другое сообщение может относиться к запросу меток для ряда других FEC, а третье может быть предупреждением, сигнализирующим о каком-то событии.

LDP PDU

Каждый LDP PDU представляет собой LDP-заголовок, за которым следует одно или более LDP-сообщений. LDP-заголовок имеет формат (рис. 12.2):

Рис. 12.2.

Версия

Двухоктетное целое число без знака, содержащее код номера версии протокола. Здесь описывается версия протокола LDP 1.

Длина PDU

Двухоктетное целое число, специфицирующее общую длину PDU в октетах, исключая поля версии и длины PDU.

Максимально допустимая длина PDU согласуется, когда инициализируется сессия LDP. До завершения согласования максимально допустимая длина равна 4096 байтов.

Идентификатор LDP

Шестиоктетное поле, однозначно идентифицирующее пространство меток LSR-отправителя, для которого это PDU используется. Первые четыре октета идентифицируют LSR и должны быть глобально уникальными. Это должен быть 32-битовый Id маршрутизатора, присвоенный LSR и используемый также для идентификации при детектировании петель в векторах пути. Последние два октета идентифицируют пространство меток заданного LSR. Для пространства меток, ориентированного на платформу, эти два октета должны равняться нулю.

Процедуры LDP

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

• выявление партнера;
• управление сессией;
• рассылка меток;
• уведомление об ошибках и справочная информация.

Процедуры рассылки меток сложны и с трудом могут быть описаны полностью, непротиворечиво и однозначно как собрание отдельных сообщений и спецификаций TLV.

Кодирование TLV (тип-длина-значение)

LDP использует для кодирования информации, транспортируемой в LDP-сообщениях, схему TLV ( TypeLengthValue = тип-длина-значение ).

LDP TLV кодируется как 2-октетное поле, которое использует 14 бит для спецификации типа и 2 бита для спецификации поведения, когда LSR не распознает поле тип; далее следуют 2 октета поля длины, поле значение имеет переменную длину (рис. 12.3).

Рис. 12.3.

U бит

Бит неизвестного TLV. При получении неизвестного TLV, если U=0, отправителю сообщения следует послать предупреждение, а сообщение должно быть проигнорировано; если U=1, неизвестное TLV молча игнорируется, а остальное сообщение обрабатывается, как будто неизвестного TLV нет.

F бит

Бит переадресации неизвестного TLV. Этот бит используется лишь в случае, когда U=1 и сообщение LDP, содержащее неизвестный TLV, нужно переадресовать. Если F=0, неизвестный TLV не переадресуется вместе содержащим его сообщением; если F=1, неизвестный TLV переадресуется.

Тип

Определяет, как следует интерпретировать поле значение.

Длина

Специфицирует длину поля значение в октетах.

Значение

Строка октетов с длиной, определяемой полем длина, где закодирована информация согласно содержимому поля тип.

Заметим, что не существует требований выравнивания для первого октета TLV. Заметим также, что само поле значение может содержать TLV. То есть, TLV могут вкладываться друг в друга.

Схема кодирования TLV является общей. В принципе, все, что появляется в LDP PDU, может быть закодировано как TLV. Эта спецификация не использует всю универсальность схемы TLV. Она не применяется там, где ее универсальность не нужна и где ее применение привело бы к большим не задействованным полям. Это обычно места, где тип кодируемого значения известен, например, по его положению в сообщении, либо когда длина значения фиксирована или просто известна.

Некоторые TLV, определенные для LDP, аналогичны некоторым другим. Например, существует TLV общей метки, TLV метки ATM и TLV Frame Relay.

Кодирование TLV для универсальных параметров

Существует несколько параметров, используемых более чем одним LDP сообщением. Кодирование TLV для этих совместно используемых параметров специфицировано далее.

FEC TLV

Метки связаны с FEC (Forwarding Equivalence Class). FEC представляет собой список из одного или более элементов FEC. TLV FEC кодирует значения FEC. Формат представления FEC показан ниже (рис. 12.4):

Рис. 12.4.

Элементы FEC от 1 до n

Существует несколько типов элементов FEC. Кодирование элементов FEC зависит от типа элемента.

Значение элемента FEC кодируется как однооктетное поле, которое специфицирует тип элемента, и поле переменной длины, которое представляет собой значение элемента, зависящее от типа. Заметим, что в то время как представление значения элемента FEC зависит от типа, представление самого элемента FEC является единственным, где стандартное кодирование LDP TLV не используется.

Значения элемента FEC кодируются следующим образом (таблица 12.2).

Заметим, что эта версия LDP поддерживает использование нескольких элементов FEC на один FEC для сообщения присвоения метки.

Элемент Wildcard FEC

Предназначен для использования только в сообщениях присвоения и отзыва меток. Указывает, что отзыв/присвоение следует применить ко всем FEC, ассоциированным с меткой в пределах следующего TLV метки. Кодирование значений элементов префикса FEC представлено ниже на рис. 12.5:

Рис. 12.5.

Семейство адресов

Двухоктетная величина, содержащая значение из списка кодов семейств адресов (смотри [RFC-1700]), которое характеризует семейство адресов для адресного префикса в поле префикс.

PreLen

Однооктетное целое без знака, содержащее длину в битах последующего адресного префикса. Длина, равная 0, говорит о том, что префикс соответствует всем адресам (адрес назначения по умолчанию); в этом случае сам префикс имеет нуль октетов.

Префикс

Адресный префикс, закодированный согласно полю семейство адресов, чья длина в битах была специфицирована в поле PreLen, дополненному до границы, кратной байту.

Элемент FEC адреса ЭВМ имеет формат, описанный ниже на рис. 12.6:

Рис. 12.6.

Семейство адресов

Двухоктетная величина, содержащая значение из списка кодов семейств адресов (смотри [RFC-1700]), которое характеризует семейство адресов для адресного префикса в поле префикс.

Длина адреса ЭВМ

Длина адреса ЭВМ в октетах.

Адрес ЭВМ

Адрес, закодированный согласно полю семейство адресов.

Процедуры FEC

Если при декодировании FEC TLV LSR сталкивается с элементом FEC семейства адресов, который он не поддерживает, он должен прервать декодирование, прервать обработку сообщения, содержащего TLV, и послать LDP партнеру уведомление "Unsupported Address Family" (неподдерживаемое семейство адресов), сигнализирующее об ошибке.

Если он сталкивается с типом элемента FEC, который он не может декодировать, ему следует прервать декодирование FEC TLV, прервать обработку сообщения, содержащего TLV, и послать LDP партнеру уведомление "Unknown FEC" (неизвестный FEC), сигнализируя об ошибке.

TLV-метки

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

Существует несколько разных видов TLV-меток, которые могут быть применены в случаях, когда требуются метки.