RFC 8175 Dynamic Link Exchange Protocol (DLEP) | Энциклопедия сетевых протоколов

Internet Engineering Task Force (IETF)                        S. Ratliff
Request for Comments: 8175                                    VT iDirect
Category: Standards Track                                        S. Jury
ISSN: 2070-1721                                            Cisco Systems
                                                          D. Satterwhite
                                                                Broadcom
                                                               R. Taylor
                                                  Airbus Defence & Space
                                                                B. Berry
                                                               June 2017

Dynamic Link Exchange Protocol (DLEP)

Протокол DLEP

PDF

Аннотация

Когда устройства маршрутизации используют модемы для организации связи по беспроводным каналам, им нужны своевременные и точные сведения о характеристиках соединений (скорость, состояние и т. п.) для принятия решений о маршрутизации. В мобильной или иной среде с частым изменением таких характеристик ручная настройка или вывод состояния с помощью транспортных протоколов или протоколов маршрутизации не позволяют маршрутизаторам принимать эффективные решений. В этом документе предложен новый протокол DLEP¹, обеспечивающий двухсторонний канал обмена информацией о событиях между модемом и маршрутизатором для упрощения связи при изменении характеристик канала.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF² и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG³. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc8175.

Авторские права

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

В настоящее время имеется множество модемных устройств, управляющих каналами с переменной скоростью и качеством. Примерами таких устройств являются наземные станции радиоканалов прямой видимости (LOS⁴), спутниковые терминалы и широкополосные модемы. Флуктуации скорости икачества этих каналов могут меняться из-за настроек или изменения физических условий, таких как интерференция отраженных сигналов, препятствия, затухание при дожде и т. п. Вполне возможна зависимость скорости и качества канала от конечной точки и типа передаваемого трафика. В качестве примера рассмотрим точку доступа IEEE 802.11, обслуживающую два связанных переносных компьютера. В этой среде ответом скорость соединения 802.11 будет зависеть от используемых компьютеров и типа передаваемого трафика. Один из компьютеров, расположенный ближе к точке доступа, может иметь, например, скорость 54 Мбит/с для индивидуального (unicast) трафика, а расположенный дальше другой компьютре – всего лишь 32 Мбит/с для такого же трафика. Однако групповой трафик от точки доступа будет передаваться с базовой скоростью, которая настраивается, но обычно не превышает 24 Мбит/с.

Кроме каналов с переменной скоростью мобильные сети сталкиваются с проблемой подключения и отключения устройств, не влияющего на состояние интерфейса маршрутизатора (Up или Down). Эффективное использование сравнительно краткосрочного соединения является проблематичным в сетях с маршрутизацией IP, поскольку протоколы маршрутизации IP опираются на состояния интерфейсов и независимые таймеры для поддержки сходимости сети (например, сообщения HELLO и/или распознавание маршрутной смежности DEAD). Такие динамические соединения могут использоваться лучше в парадигме управления по событиям, где обретение нового соседа или потеря имеющегося ведет к сигналу, нежели в парадигме управления по таймерам и/или состоянию интерфейса. Протокол DLEP не только реализует парадигму управления по событиям, но и делает это на уровне локальной (1 интервал – hop) сессии TCP, что гарантирует доставку сообщений.

Другим осложняющим фактором для беспроводных сетей являются разные методы физического подключения модемов к маршрутизаторам. Модем может быть интерфейсной платой маршрутизатора или автономным устройством, подключенным по линии Ethernet или последовательному каналу. При подключении Ethernet с использованием существующих протоколов и методов программы маршрутизации не знают о событиях сходимости на радиоканале (например, подключение или отключение смежных маршрутизаторов) и маршрутизатор не знает о реальной пропускной способности канала. Недостаток информации вкупе с переменной скоростью передачи ведет к усложнению поиска и поддержки лучшего (текущего) маршрута через сеть к данному узлу. Это особенно важно для схем доступа по запросу, таким как DAMA⁵, используемым в некоторых спутниковых системах. В системах на основе DAMA дополнительная полоса может оказаться доступной, но не используемой, пока скорость передачи сетевого устройства не превысит текущую установленную скорость. Увеличение скорости передачи трафика не гарантирует выделение дополнительной полосы и может вместо этого приводить к потере пакетов и дополнительным повторам на канале.

Для решения отмеченных выше проблем предложен протокол DLEP, работающий между маршрутизатором и подключенными к нему модемами и позволяющий модемам сообщать (1) об изменении характеристик канала и (2) событиях схождения (подключения или потеря возможного следующего маршрутизатора). Область распространения пакетов DLEP показана на рисунках 1 и 2.

|-----Локальный узел-----|          |------Удаленный узел----|
|                        |          |                        |
+--------+       +-------+          +-------+       +--------+
|Маршрути|=======| Модем |{~~~~~~~~}| Модем |=======|Маршрути|
|  затор |       |       |          |       |       |  затор |
+--------+       +-------+          +-------+       +--------+
         |       |       | Канальный|       |       |
         |-DLEP--|       | протокол |       |-DLEP--|
         |       |       |(например,|       |       |
         |       |       | 802.11)  |       |       |

Рисунок 1. Сеть DLEP.

На рисунке 1 локальный модем при обнаружении наличия удаленного узла передает сообщение своему маршрутизатору по протоколу DLEP. Это сообщение содержит указание произошедшего на канале изменения (например, появление или исчезновение узла) вместе с набором определенных DLEP эдементов данных (Data Item) с дополнительным описанием изменения. При получении этого сообщения локальный маршрутизатор может предпринять действие, которое он считает целесообразным, такое как запуск протоколов обнаружения и/или выдачу сообщений HELLO для схождения сети. Далее по мере необходимости модемы используют DLEP для информирования об изменении характеристик (скорость, задержка и т. п.) канала. Протокол DLEP не зависит от типа канала и поддерживаемой модемом топологии. Протокол предназначен для использования лишь на локальном канале между маршрутизатором и модемом. Может потребоваться та или иная сигнализация (over-the-air) между локальным и удаленным модемом для обеспечения некоторых параметров сообщений DLEP между локальным модемом и локальным маршрутизатором, но DLEP не задает способ такой сигнализации (определяется производителем модема).

На рисунке 2 показано, как DLEP может поддерживать конфигурацию при подключении маршрутизаторов по разнотипным каналам. В этом примере модемы типа A организуют соединение «точка-точка», а модемы типа B соединяются через общую среду. В обоих случаях используется протокол DLEP для информирования маршрутизаторов о характеристиках канала (скорость, задержка и т. п.). Модем также может использовать сессию DLEP для уведомления маршрутизатора о потере удаленного узла для сокращения времени схождения сети.

         +--------+                     +--------+
    +----+ Модем  |                     | Модем  +---+
    |    |  типа  |                     |  типа  |   |
    |    |    A   |  <===== // ======>  |    A   |   |
    |    +--------+ Канал «точка-точка» +--------+   |
+---+----+                                       +---+----+
|Маршрути|                                       |Маршрути|
|  затор |                                       |  затор |
+---+----+                                       +---+----+
    |     +--------+                     +--------+  |
    +-----+ Модем  |                     | Модем  |  |
          |  типа  |   o o o o o o o o   |  типа  +--+
          |    B   |    o   Общая   o    |    B   |
          +--------+     o  среда  o     +--------+
                          o       o
                           o     o
                            o   o
                              o
                         +--------+
                         | Модем  |
                         |  типа  |
                         |    B   |
                         +---+----+
                             |
                         +---+----+
                         |Маршрути|
                         |  затор |
                         +--------+

Рисунок 2. Сеть DLEP с несколькими модемами.

2. Обзор протокола

Протокол DLEP определяет набор сообщений, используемых модемами и подключенными к ним маршрутизаторами для обмена событиями, которые происходят на физических каналах, поддерживаемых модемом (например, подключение или отключение узла сети, изменение канала). С этими сообщениями связан набор элементом данных (Data Item), описывающих удаленный узел (например, информация об адресе) и/или характеристики канала к удаленному узлу. В этом документе модемы и маршрутизаторы, участвующие в сессии DLEP, называются участниками (DLEP Participant), если не требуется более конкретное указание (например, модем или маршрутизатор).

DLEP работает на основе сессий между модемом и связанным с ним маршрутизатором. При подключении к одному маршрутизатору множества модемов (Рисунок 2) или поддержке модемом множества соединений (через логические или физические интерфейсы) организуется сессия DLEP для каждого модема или соединения. Маршрутизатор и модем формируют сессию с помощью процесса обнаружения и инициализации. Сессия между модемом и маршрутизатором сохраняется, пока (1) не завершится время ожидания (таймаут) при отсутствии трафика DLEP (включая сообщения heartbeat) или (2) сессия не будет явно разорвана отдним из участников DLEP.

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

2.1. Получатели

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

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

Адресат может быть физическим или логическим. Примером физического получателя может быть удаленный оконечный маршрутизатор, подключенный по каналу с переменной скоростью. Здесь следует отметить, что для физического получателя MAC⁶-адресом является адрес оконечного маршрутизатора, а не модема.

Примером логического получателя является групповая адресация (Multicast). Групповой трафик для сети с изменяющимся качеством соединения (доступ через модем) обрабатывается в IP-сети путем выведения адресов L2 (MAC) из адресов L3. В такой схеме групповой трафик поддерживается протоколом DLEP просто трактовкой выведенных MAC-адресов, как любых других получателей в сети.

Для поддержки этих логических адресатов один из участников DLEP (обычно маршрутизатор) информирует другого об их наличии. Модем, узнав о существовании логических получателей, сообщает характеристики канала как для любого другого адресата в сети. Конкретные алгоритмы, применяемые модемом для вывода параметров метрики логических адресатов, выходят за рамки этой спецификации и могут выбираться реализацией.

Во всех случаях использования термина destination (получатель, адресат) в данной спецификации это означает адресуемое место (логическое или физическое), доступное по радиоканалу (каналам).

2.2. Соглашения и терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

3. Требования

Протокол DLEP должен разворачиваться в одном домене L2. Протокол указывает получателей следующего интервала (next-hop), используя MAC-адрес для доставки трафика данных. Каких-либо подстановок или манипуляций не происходит и MAC-адрес из сообщений DLEP используется в качестве Destination MAC в кадрах, передаваемых участвующим в протоколе маршрутизатором. MAC-адреса должны быть уникальными в контексте сессии модем-маршрутизатор.

Для ограничения работы одним доменом L2 реализации должны поддерживать механизм Generalized TTL Security Mechanism [RFC5082], а также должны следовать этой спецификации для всех сообщений DLEP.

DLEP задает групповой трафик UDP для сигнализации обнаружения в одном интервале (single-hop discovery) и TCP – для доставки сообщений. Модемы и маршрутизаторы, участвующие в сессии DLEP, должны иметь топологически согласованные адреса IP. Рекомендациям DLEP рекомендуется использовать адреса IPv6 link-local для снижения административных издержек, связанных с назначением адресов.

DLEP полагается на гарантированную доставку сообщений между модемом и маршрутизатором после завершений процесса обнаружения (1-hop discovery), поэтому для доставки сообщений выбран протокол TCP. Можно применять и другие протоколы с гарантией доставки, но это выходит за рамки данного документа.

4. Варианты развертывания

В процессе разработки спецификации рассматривались два типа развертывания.

Первый можно считать «выделенным развертыванием» В этом режиме маршрутизаторы и модемы DLEP соединены напрямую (например, кросс-кабелями) или подключены к выделенному коммутатору. Примером может служить маршрутизатор со подключенной к одному интерфейсу станцией LOS и спутниковым модемом на другом интерфейсе. В мобильной среде маршрутизатор и подключенные модемы размещаются на мобильной платформк (автомобиль, корабль, самолет). В этом режиме при использовании коммутатора к нему может также подключаться небольшое число вспомогательный устройств (например, переносной компьютер). Однако в любом случае сегмент сети ограничен малым числом устройств и, как правило, не доступен извне.

Другой вариант можно считать «сетевым развертыванием». В этом случае маршрутизатор и модемы DLEP размещаются в доступном извне сегменте сети. Здесь между маршрутизатором и конкретным модемом DLEP может быть несколько физических узлов пересылки. В этом варианте требуется использовать туннель L2 для выполнения требования DLEP в части 1 этапа пересылки (single-hop).

5. Допущения

DLEP предполагает наличие протокола сигнализации между модемами, участвующими в работе. Данная спецификация не задает поведение этой беспроводной (over-the-air) сигнализации, но предполагает передачу (возможность вывода) некой информации, такой как подключение и отключение модемов, а также вариации харакетристик канала между модемами. Предполагается, что эти данные модем использует для реализации DLEP.

Спецификация предполагает, что соединение между модемом и маршрутизатором является статическим в плане скоорости и задержки, а также не вносит задержки, способной создавать «пробку». В системах, где между модемом и маршрутизатором имеется множество физических интервалов пересылки и применяется туннель L2, статистики DLEP для радио-каналов (RF) может оказаться недостаточно для принятия корректного решения о маршрутизации. Это особенно важно в тех случаях, когда туннель L2 между модемом и маршрутизатором включает беспроводные каналы.

6. Параметры метрики

DLEP включает возможность обмена между маршрутизатором и модемом метрическими характеристиками (например, скорость, задержку) используемого канала с переменным качеством. DLEP не задает расчета конкретных параметров метрики, а лишь предполагает что метрика рассчитана разумно (best effort) с учетом всех данных, доступных модему. Метрики, основанные на достаточно больших выборках, позволяют избежать кратковременных пиков трафика в результате неблагоприятного искажения сообщаемых значений.

DLEP позволяет передавать метрику в двух контекстах – для конкретного получателя в сети (например, определенного маршрутизатора) и «на уровне сессии» (применительно ко всем адресатам, доступным через модем). Большинство показателей можно разделить на параметры передачи и приема. Когда метрика предоставляется на уровне сессии, маршрутизатор распространяет параметры на все записи в базе данных для получателей, доступных через модем.

Модем DLEP анонсирует все метрические элементы данных, о которых он будет сообщать в сессии, и указывает для параметров принятые по умолчанию значения в сообщенииSession Initialization Response (12.6. Отклик Session Initialization Response). Для использования типа метрики, не включенного в такое сообщение, модем прерывает сеанс с маршрутизатором сообщением Session Termination (12.9. Сообщение Session Termination) и начинает новую сессию.

Модем DLEP может в любое время передать метрику (1) в контексте сессии через сообщение Session Update (12.7. Сообщение Session Update) и (2) в контексте конкретного адресата – через Destination Update (12.17. Сообщение Destination Update). Более новые данные метрики имеют преимущество независимо от контекста передачи.

Если метрика получена в контексте адресата (Destination Update), обновляются данные для получателя.
Если метрика получена в контексте сессии (Session Update), обновляются параметры для всех получателей, подключенных через этот модем.

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

В дополнение к обмену метрическими данными каналов в DLEP поддерживаются сообщения, позволяющие маршрутизатору запросить у модема другую скорость или задержку. Это сообщения Link Characteristics Request (12.18. Запрос характеристик канала), которые дают маршрутизатору возможность более детерминированно справляться с ростом (снижением) запросов на выделение полосы и задержку.

7. Состояния сессии DLEP

Все участники сессии DLEP проходят через множество состояний в течение срока действия сессии DLEP:

обнаружения партнера (Peer Discovery);
инициализация сессии (Session Initialization);
работа сессии (In-Session);
прерывание сессии (Session Termination);
сброс сессии (Session Reset).

Модемы и маршрутизаторы, поддерживающие обнаружение DLEP, проходят через все перечисленные состояния. Маршрутизаторы, полагающиеся на заранее настроенные адрес и порт TCP, начинают с состояния Session Initialization.

Модемы должны поддерживать состояние Peer Discovery.

7.1. Состояние Peer Discovery

Модемы должны поддерживать состояние Peer Discovery, маршрутизаторы могут поддерживать сигналы обнаружения или полагаться на конфигурацию для нахождения модемов. Если маршрутизатор выбирает поддержку детектирования DLEP, он должен поддерживать все сигналы.

В состоянии Peer Discovery маршрутизатор, поддерживающие обнаружение DLEP, должен передавать Peer Discovery Signal (12.3. Сигнал Peer Discovery ) для инициирования процесса обнаружения модема.

После этого маршрутизатор ждет отклика Peer Offer (12.4. Сигнал Peer Offer ) от модема DLEP. В состоянии Peer Discovery сигналы Peer Discovery должны передаваться маршрутизатором DLEP периодически. Рекомендуется интервал 60 секунд. Интервал должен быть не меньше 1 секунды и следует делать его настраиваемым. Отметим, что эта операция (передача Peer Discovery и ожидание Peer Offer) не входит в модель транзакций DLEP (8. Модель транзакций), поскольку эта модель описывает лишь сообщения в сессии TCP.

Маршрутизатор, получивший сигнал Peer Offer, должен использовать одну из комбинаций адрес-порт в Peer Offer для организации соединения TCP с модемом даже при наличии заданной ранее конфигурации. При наличии нескольких Connection Point в полученной Peer Offer маршрутизатору следует предпочитать точки подключения IPv6 точкам IPv4. При наличии нескольких точек с одним протоколом (IPv6 или IPv4) реализация может использовать свю эвристику для выбора среди них. Если соединение TCP не удается организовать с любой из пар адрес-порт и механизм Discovery применяется, маршрутизатору следует возобновить передачу сигналов Peer Discovery. Если элементов Connection Point нет в сигнале Peer Offer, маршрутизатор должен использовать адрес отправителя из пакета UDP, содержащего Peer Offer, в качестве IP-адреса получателя и общеизвестный порт DLEP.

В состоянии Peer Discovery реализация модема должна слушать входящие сигналы Peer Discovery на общеизвестном порту DLEP группового локального адреса IPv6 и/или IPv4. При получении действительного сигнала Peer Discovery модем должен ответить сигналом Peer Offer.

Модемы должны быть готовы воспринять соединение TCP от маршрутизаторов, не использующих механизм Discovery, т. е. попытки соединения без предшествующего сигнала Peer Discovery.

Реализациям DLEP следует поддерживать и использовать протокол TLS⁷ [RFC5246] для защиты сессии TCP. «Выделенные развертывания» (4. Варианты развертывания) могут использовать DLEP без TLS. Для всех «сетевых развертываний» настоятельно рекомендуется поддерживать и использовать TLS. При использовании TLS сеанс протокола TLS должен быть организован до начала передачи каких-либо сообщений между партнерами. Маршрутизаторы, поддерживающие TLS, должны предпочитать точки соединения, использующие TLS.

После организации соединения TCP (и сессии TLS, если протокол используется), модем и маршрутизатор переходят в состояние Session Initialization. Продожение отправки сигналов Peer Discovery после перехода в состояние Session Initialization реализация выбирает самостоятельно. Реализации модемов должны игнорировать сигналы Peer Discovery от маршрутизатора, с которым уже организовано соединение TCP.

7.2. Состояние Session Initialization

При переходе в состояние Session Initialization маршрутизатор должен передать модему сообщение Session Initialization (12.5. Сообщение Session Initialization). затем маршрутизатор должен дождаться сообщения Session Initialization Response (12.6. Отклик Session Initialization Response) от модема. Прием Session Initialization Response с элементом данных (13.1. Данные состояния) Status, имеющим значение 0 ‘Success’ (таблица 2 в параграфе 13.1. Данные состояния), указывает, что модем получил и обработал сообщение Session Initialization и маршрутизатор должен перейти в состояние In-Session.

При переходе в состояние Session Initialization модем должен ждать от маршрутизатора сообщения Session Initialization. При получении Session Initialization модем должен передать сообщение Session Initialization Response, а затем должен перейти в состояние In-Session. При получении иного сообщения или отказе при анализе принятого Session Initialization модему недопустимо передавать какое-либо сообщение и он должен разорвать соединение TCP connection, а также перейти в состояние Session Reset.

DLEP поддерживает возможность согласования расширений в состоянии Session Initialization (9. Расширения). Поддерживаемые реализацией расширения должны быть объявлены возможным участникам DLEP с использованием элемента данных Extensions Supported (13.6. Extensions Supported). После обмена обоих участников DLEP инициализационными сообщениями реализации недопустимо передавать какие-либо сообщения, сигналы, элементы данных или коды состояния, связанные с расширениями, которые не были указаны в инициализационном сообщении от партнера.

7.3. Состояние In-Session

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

Состояние In-Session поддерживается, пока не произойдет любое из приведенных ниже событий:

прерывание сессии сообщением Session Termination (12.9. Сообщение Session Termination);
прерывание сессии партнером с помощью сообщения Session Termination.

В этом случае реализация должна перейти в состояние Session Termination.

7.3.1. Сообщения Heartbeat

Для поддержки состояния In-Session периодически должны передаваться сообщения Heartbeat (12.20. Сообщение Heartbeat) между модемами и маршрутизаторами. Эти сообщения предназначены для сохранения сессии путем двухсторонней проверки связности между участниками DLEP. Рекомендуется устанавливать между сообщениями интервал 60 секунд. Интервал должен быть не менее 1 секунды и следует делать его настраиваемым.

Каждый участник DLEP отвечает за создание сообщений Heartbeat.

При получении любого действительного сообщения DLEP таймер сообщений Heartbeat должен сбрасываться в 0 (т. е. любое действительное сообщение выступает в качестве Heartbeat).

Реализация должна разрешать по меньшей мере 2 интервала без сообщений прежде, чем разрывать сессию с партнером. При разрыве сеанса должно передаваться сообщение Session Termination Message с элементом данных Status (13.1. Данные состояния), имеющим значение 132 ‘Timed Out’ (Таблица 2), после чего реализация должна перейти в состояние Session Termination.

7.4. Состояние Session Termination

При переходе реализации в состояние Session Termination после отправки сообщения Session Termination (12.9. Сообщение Session Termination) в результате ошибки или приема нейдествительного сообщения она должна дождать от партнера сообщения Session Termination Response (12.10. Отклик Session Termination Response). Отправителю следует выждать 4 интервал Heartbeat прежде, чем счесть партнера недоступным и продолжить разрыв сессии. Любые другие сообщения в процессе такого ожидания должны игнорироваться.

Когда отправитель Session Termination получает от партнера сообщение Session Termination Response или завершается время ожидания, отправитель должен перейти в состояние Session Reset.

Когда реализация получает от партнера сообщение Session Termination, она переходит в состояние Session Termination, а затем должна незамедлительно передать сообщение Session Termination Response и перейти в состояние Session Reset.

7.5. Состояние Session Reset

В состоянии Session Reset реализация должна выполнить указанные ниже действия:

освободить все выделенные для сессии ресурсы;
удалить всех получателей в базе данных, представленных сессией; передача сообщений Destination Down (12.15. Сообщение Destination Down) недопустима;
разорвать соединение TCP.

По завершении указанных действий реализации следует вернуться в подходящее исходное состояние:

модем – Peer Discovery;
маршрутизатор – Peer Discovery или Session Initialization в зависимости от конфигурации.

7.5.1. Неожиданный разрыв сессии TCP

Если соединение TCP между участниками DLEP разрывается, когда реализация не находится в состоянии Session Reset, реализация должна незамедлительно перейти в состояние Session Reset.

8. Модель транзакций

DLEP определяет простую модель транзакций для сообщений – в сессии может обрабатываться лишь один запрос на каждого получателя. Транзакция считается завершенной, когда получен отклик, соответствующий переданному ранее запросу. Если участник DLEP получает запрос для получателя, применительно к которому уже имеется незавершенный запрос, реализация должна прервать сессию сообщением Session Termination (12.9. Сообщение Session Termination), содержащим элемент данных Status (13.1. Данные состояния) с кодом 129 ‘Unexpected Message’ (Таблица 2), и перейти в состояние Session Termination. Не задается ограничений на общее число обрабатываемых одновременно транзакций, если каждая из них относится к своему получателю.

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

Кроме того, в каждый момент может обрабатываться лишь один сеансовый запрос, например, Session Initialization (12.5. Сообщение Session Initialization). Как отмечено выше, транзакция для сообщения считается завершенной при получении отклика, соответствующего переданному ранее запросу. Если участник DLEP получает сеансовый запрос в то время, когда обрабатывается другой сеансовый запрос, он должен прервать сессию сообщением Session Termination, содержажим элемент данных Status с кодом 129 ‘Unexpected Message’ и перейти в состояние Session Termination. Во время обработы сеансовой транзакции могут вводиться лишь сообщения Session Termination. Сообщения Heartbeat (12.20. Сообщение Heartbeat) недопустимо считать частью сеансовой транзакции.

Для транзакций DLEP не предусмотрены отказы и тайм-ауты, за исключением транзакий, не завершенных к моменту сброса сессии DLEP. При прерывании сессии отмена незавершенных транзакций должна выполняться как часть сброса конечного автомата состояний. Реализация может обнаруживать отказ партнера используя механизм Heartbeat в состоянии In-Session (7.3. Состояние In-Session).

9. Расширения

Расширения должны согласовываться на уровне сессии в процессе ее инициализации с помощью механизма Extensions Supported. Реализации в плане соответствия DLEP не обязана поддерживать какие-либо расширения.

Если требуются совместимые расширения протокола, они должны быть стандартизованы путем (1) обновления данного документа или (2) создания отдельной спецификации. Реестры IANA, указанные в разделе 15, содержат достаточно неискользованных кодов для сигналов, сообщений, элементов данных и состояний DLEP, что позволяет расширять протокол.

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

9.1. Экспериментальные расширения

Этот жокумент регистрирует пространство номеров Private Use [RFC5226] для сигналов, сообщений, элементов данных и кодов состояния DLEP, предназначенное для экспериментальных расширений. Цель заключается в предоставлении возможности экспериментировать с новыми сигналами, сообщениями, элементами данных и состояниями, сохраняя документированное поведение DLEP.

В процессе инициализации сеанса использование приватных (Private Use) значений для сигналов, сообщений, элементов данных и/или состояний должно анонсироваться как расширения DLEP с применением идентификаторов из пространства Private Use в реестре Extension Type Values (Таблица 3) с заранее согласованным между участниками значением. Расширения DLEP из пространства номеров Private Use обычно называются экспериментальными.

Можно анонсировать множество расширений в сообщении Session Initialization, однако применение разных расширений в одной сессии может создавать проблемы взаимодействия или приводить к неожиданным результатам (например, конфликты экспериментальных сигналов, сообщений, элементов данных и/или кодов состояния). Поэтому такое использование не рекомендуется. Реализациям оставлено право в таких случаях определять корректный путь обработки (например, прерывание сессии или установку приоритета для конфликтующих расширений).

10. Масштабируемость

Протокол предназначен для поддержки тысяч адресатов с данной парой модем-маршрутизатор. При масштабном развертывании реализации следует рассмотреть применение методов, препядствующих лавинной отправке большого числа сообщений за короткое время. Например, может применяться алгоритм демпфирования для предотвращения генерации устройством с нестабильным подключением большого числа сообщений Destination Up и Destination Down.

Использованием методов гистерезиса позволяет снизить влияние быстрых, но незначительных колебаний качества каналов. Конкретные алгоритмы для реализации этих механизмов выходят за рамки спецификации.

11. Структура сигналов и сообщений DLEP

DLEP определяет два протокольных блока, используемых разными способами, – сигналы и сообщения. Сигналы используются лишь механизмом обнаружения и передаются в дейтаграммах UDP. Сообщения передаются в обоих направлениях через соединения TCP между участниками в состояниях Session Initialization, In-Session, Session Termination.

Сигналы и сообщения включают заголовок, за которым следует неупорядоченный список элементов данных. Заголовок содержит поля типа (Type) и размера (Length), а элементы данных используют формат TLV (тип-размер–значение). Элементы данных после заголовка сигнала или сообщения называют содержащимися в сигнале или сообщении.

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

Все целочисленные значения в полях Header должны указываться в сетевом порядке байтов.

11.1. Заголовок сигнала DLEP

Поля заголовка сигнала DLEP показаны на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      'D'      |      'L'      |      'E'      |      'P'      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type                   | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Заголовок сигнала DLEP.

“DLEP”

Каждый сигнал должен начинаться с последовательности символовU+0044, U+004C, U+0045, U+0050.

Signal Type

16-битовое целое число без знака, указывающее одно из значений DLEP Signal Type, определенных в документе.

Length

16-битовое целое число без знака, указывающее размер (в октетах) всех элементов данных, содержащихся в этом сигнале. В размере элементов данных DLEP недопустимо учитывать размер самого Signal Header.

После заголовка сигнала DLEP могут следовать элементы данных DLEP (Data Item) в формате TLV.

11.2. Заголовок сообщения DLEP

Поля заголовка сообщения DLEP показаны на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type                  | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Заголовок сообщения DLEP.

Message Type

16-битовое целое число без знака, содержащее одно из значений DLEP Message Type, определенных в документе.

Length

16-битовое целое число без знака, указывающее размер (в октетах) всех элементов данных, содержащихся в этом сообщении. В размере элементов данных DLEP недопустимо учитывать размер самого Message Header.

После заголовка сообщения DLEP могут следовать элементы данных DLEP (Data Item) в формате TLV.

11.3. Базовый элемент данных DLEP

Все элементы данных DLEP используют показанный на рисунке заголовок.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Value...                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Базовый элемент данных DLEP.

Data Item Type

16-битовое целое число без знака, указывающее один из типов Data Item.

Length

16-битовое целое число без знака, указывающее размер (в октетах) поля Value в элементе данных. В этом поле недопустимо учитывать размер полей Data Item Type и Length.

Value

Поле размером Length октетов, содержащее данные конкретного Data Item.

12. Сигналы и сообщения DLEP

12.1. Базовые правила обработки

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

Если сигнал получен со значением TTL не равным 255, принимающая реализация должна игнорировать сигнал.

При получении нераспознанного сообщения принимающая реализация должна выдать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент данных Status (13.1. Данные состояния) с кодом 128 ‘Unknown Message’ (Таблица 2), и перейти в состояние Session Termination.

При получении неожиданного сообщения принимающая реализация должна выдать сообщение Session Termination, содержащее элемент данных Status с кодом 129 ‘Unexpected Message’, и перейти в состояние Session Termination.

Если полученное сообщение содержит нараспознанный или недействительный элемент данных или не разрешенные дубликаты Data Item, принимающая реализация должна выдать сообщение Session Termination, содержащее элемент данных Status с кодом 130 ‘Invalid Data’, и перейти в состояние Session Termination.

Если пакет в потоке TCP получен со значением TTL, отличным от 255, принимающая реализация должна незамедлительно перейти в состояние Session Reset.

Перед обменом сообщениями Destination Up (12.11. Сообщение Destination Up) и Destination Up Response (12.12. Отклик Destination Up Response) или Destination Announce (12.13. Сообщение Destination Announce) и Destination Announce Response (12.14. Отклик Destination Announce Response) нельзя передавать сообщения, относящиеся к адресатам. Реализация, принявшая сообщение с неанонсированным адресатом, должна прервать сессию сообщением Session Termination, с элементом данных Status = 131 ‘Invalid Destination’ и перейти в состояние Session Termination.

После обмена сообщениями Destination Down (12.15. Сообщение Destination Down) и Destination Down Response (12.16. Отклик Destination Down Response) не допускается передача других сообщений об адресатах, пока не будет выполнен новый обмен Destination Up или Destination Announce. Реализация, получившая сообщение об адресате, ранее объявленном как отключенный (down), должна прервать сессию сообщением Session Termination, с элементом данных Status = 131 ‘Invalid Destination’ и перейти в состояние Session Termination.

12.2. Обработка кода состояния

Поведение участника DLEP при получении элемента данных Status (13.1. Данные состояния) определяется режимом отказа, связанным с кодом состояния (Таблица 2). Для всех кодов меньше 100 при отказе выполнение продолжается (Continue), для остальных кодов – прерывается (Terminate).

Участник DLEP, получивший сообщение, отличное от Session Termination (12.9. Сообщение Session Termination), с элементом данных Status, для которого задан режим Terminate, должен незамедлительно передать сообщение Session Termination, включив в него полученный элемент Status, а затем перейти в состояние Session Termination.

Участник DLEP при получении сообщения, содержащего элемент данных Status, для которого задан режим Continue, может продолжать обычное использование сессии.

12.3. Сигнал Peer Discovery

Сигнал Peer Discovery маршрутизатору DLEP следует передавать для обнаружения в сети модемов DLEP (7.1. Состояние Peer Discovery.

Сигнал Peer Discovery должен передаваться в пакете UDP. В качестве получателя должен указываться общеизвестный адрес и порт DLEP. Маршрутизаторам, поддерживающим работу DLEP по протоколам IPv4 и IPv6, рекомендуется выбирать транспорт IPv6. В качестве IP-адреса отправителя должен устанавливаться адрес маршрутизатора, связанный с интерфейсом DLEP. Для порта отправителя DLEP не задает требований.

Для создания Peer Discovery Signal устанавливается Signal Type = 1 в Signal Header (15.2. Типы сигналов).

Сигнал Peer Discovery может включать Peer Type Data Item (13.4. Peer Type).

12.4. Сигнал Peer Offer

Сигнал Peer Offer должен передаваться модемом DLEP в ответ на корректно отформатированный и адресованный сигнал Peer Discovery (12.3. Сигнал Peer Discovery ).

Сигнал Peer Offer должен передаваться в пакете UDP. Поля отправителя и получателя IP должны быть значениями из сигнала Peer Discovery, которые поменяны местами. Сигнал Peer Offer завершает процесс обнаружения (7.1. Состояние Peer Discovery).

Для создания Peer Offer Signal устанавливается Signal Type = 2 в Signal Header (15.2. Типы сигналов).

Сигнал Peer Offer Signal может включать Peer Type Data Item (13.4. Peer Type).

Сигнал Peer Offer Signal может включать один или несколько перечисленных ниже Data Item с разными значениями:

IPv4 Connection Point (13.2. IPv4 Connection Point);
IPv6 Connection Point (13.3. IPv6 Connection Point).

Эти элементы указывают индивидуальные адреса, которые маршрутизатор должен использовать в сессии DLEP TCP.

12.5. Сообщение Session Initialization

Сообщение Session Initialization маршрутизатор DLEP должен передавать как первое сообщение в сессии DLEP TCP. Оно передается маршрутизатором после организации соединения TCP через адрес и порт, полученные в соотщении Peer Offer или заданные в конфигурации.

При создании сообщения Session Initialization устанавливается Message Type = 1 в Message Header (15.3. Регистрации Message Type).

Сообщение Session Initialization должно содержать по одному из перечисленных ниже элементов данных:

Heartbeat Interval (13.5. Heartbeat Interval)
Peer Type (13.4. Peer Type)

При поддержке расширения DLEP сообщение Session Initialization должно содержать элемент данных Extensions Supported (13.6. Extensions Supported).

Сообщение Session Initialization может включать 1 или несколько перечисленных ниже элементов данных с разными значениями и установленным (1) флагом Add/Drop (A) (13. Элементы данных DLEP):

IPv4 Address (13.8. IPv4 Address);
IPv6 Address (13.9. IPv6 Address);
IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

Если реализация поддерживает необязательные расширения, они должны быть указаны в элементе данных Extensions Supported. Если элемента Extensions Supported нет в сообщении Session Initialization, модем должен считать, что маршрутизатор не поддерживает расширений.

Сообщения DLEP Heartbeat не передаются до приема сообщения Session Initialization Response (12.6. Отклик Session Initialization Response), поэтому реализация должна применять свою эвристику для времени ожидания.

Исключением из общего правила поведения реализации, получившей в сообщении непонятный элемент данных (12.1. Базовые правила обработки), является сообщение Session Initialization с 1 или несколькими элементами Extensions Supported, анонсирующими поддержку непонятных для реализации расширений. Реализация может игнорировать непонятные элементы данных.

12.6. Отклик Session Initialization Response

Сообщение Session Initialization Response модем DLEP должен передавать в ответ на Session Initialization (12.5. Сообщение Session Initialization).

При создании сообщения Session Initialization Response устанавливается Message Type = 2 в заголовке сообщения (15.3. Регистрации Message Type).

Сообщение Session Initialization Response должно содержжать по одному элементу данных, указанному ниже:

Status (13.1. Данные состояния);
Peer Type (13.4. Peer Type);
Heartbeat Interval (13.5. Heartbeat Interval);
Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
Latency (13.16. Latency).

Сообщение Session Initialization Response должно включать по одному из перечисленных ниже элементов данных, если он используется в сессии:

Resources (13.17. Resources);
Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Если поддерживаются расширения DLEP, сообщение Session Initialization Response должно содержать элемент данных Extensions Supported (13.6. Extensions Supported).

Сообщение Session Initialization Response может включать 1 или несколько перечисленных ниже элементов данных с разными значениями и установленным (1) флагом Add/Drop (A) (13. Элементы данных DLEP):

IPv4 Address (13.8. IPv4 Address);
IPv6 Address (13.9. IPv6 Address);
IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

Сообщение Session Initialization Response завершает организацию сессии DLEP. Модему следует переходить в состояние In-Session, когда это сообщение передано, а маршрутизатору следует переходить в In-Session при получении приемлемого сообщения Session Initialization Response.

Все поддерживаемые элементы данных метрики должны включаться в Session Initialization Response Message с использованием принятых по умолчанию значений в рамках сессии. Это можно считать «декларированием» всех поддерживаемых параметров метрики при инициализации сессии DLEP. Прием любого последующего сообщения DLEP с параметрами метрики, не включенными в Session Initialization Response, должен считаться ошибкой, ведущей к разрыву сессии DLEP между модемом и маршрутизатором.

Если модем поддерживает необязательные расширения, они должны быть указаны в элементе данных Extensions Supported. Если элемента Extensions Supported нет в сообщении Session Initialization Response, маршрутизатор должен считать, что модем не поддерживает расширений. После обмена сообщениями Session Initialization и Session Initialization Response реализация должна использовать лишь расширения, поддерживаемые обоими участниками DLEP (7.2. Состояние Session Initialization).

12.7. Сообщение Session Update

Сообщение Session Update может передать участник DLEP в рамках сессии для индикации смены локального адреса L3 и/или метрических параметров.

В заголовке Session Update устанавливается Message Type = 3 (15.3. Регистрации Message Type).

Сообщение Session Update может включать 1 или несколько указанных элементов данных с разными значениями:

IPv4 Address (13.8. IPv4 Address);
IPv6 Address (13.9. IPv6 Address);
IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

При передаче модемом сообщение Session Update может включать 1 или несколько элементов данных:

Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
Latency (13.16. Latency).

При передаче модемом сообщение Session Update может включать 1 или несколько перечисленных ниже элементов данных, если они используются в сессии:

Resources (13.17. Resources);
Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Если в Session Update представлены параметры метрики (например, Maximum Data Rate), эти параметры считаются относящимися к сессии в целом и должны применяться ко всем адресатам из информационной базы, связанной с сессией DLEP. Это включает адресатов, для которых метрика может быть сохранена на основе полученных сообщений Destination Update.

Следует отметить, что сообщения Session Update могут передавать модемы и маршрутизаторы. Например, добавление адреса IPv4 на маршрутизаторе может служить основанием для сообщения Session Update подключенным модемам. Аналогично, смена модемом Maximum Data Rate (Receive) для всех адресатов может быть отражена в сообщении Session Update для подключенных маршрутизаторов.

Если модем способен понимать и пересылать информацию об адресах и подсетях L3 (механизмы не определены в DLEP), изменение таких сведений побудит все удаленные модемы с поддержкой DLEP передать Destination Update своим локальным маршрутизаторам с указанием новых (или удаленных) адресов и подсетей.

12.8. Отклик Session Update Response

Сообщение Session Update Response должно передаваться участником DLEP в ответ на Session Update (12.7. Сообщение Session Update).

В заголовке Session Update Response устанавливается Message Type = 4 (15.3. Регистрации Message Type).

Сообщение Session Update Response должно включать элемент данных Status (13.1. Данные состояния).

12.9. Сообщение Session Termination

Когда участник DLEP принимает решение о необходимости прервать сессию DLEP, он должен передать (или попытаться) сообщение Session Termination.

В заголовке Session Termination устанавливается значение Message Type = 5 (15.3. Регистрации Message Type).

Сообщение Session Termination должно включать элемент данных Status (13.1. Данные состояния).

Следует отметить, что сообщения Session Termination могут передавать как модемы, так и маршрутизаторы.

12.10. Отклик Session Termination Response

Сообщение Session Termination Response должно передаваться участником DLEP в ответ на Session Termination Message (12.9. Сообщение Session Termination).

В заголовке Session Termination Response устанавливается Message Type = 6 (15.3. Регистрации Message Type).

Элементы данных ни включаются в Session Termination Response.

Прием сообщения Session Termination Response завершает разпыв сессии DLEP (7.4. Состояние Session Termination).

12.11. Сообщение Destination Up

Сообщения Destination Up модем может передавать для оповещения подключенного маршрутизатора о присутствии нового доступного получателя.

В заголовке Destination Up устанавливается значение Message Type = 7 (15.3. Регистрации Message Type).

Сообщение Destination Up должно включать элемент данных MAC Address (13.7. MAC Address).

В сообщение Destination Up следует включать 1 или несколько перечисленных ниже Data Item с разными значениями:

IPv4 Address (13.8. IPv4 Address);
IPv6 Address (13.9. IPv6 Address).

Сообщение Destination Up может включать по одному из перечисленных ниже элементов данных:

Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
Latency (13.16. Latency).

Сообщение Destination Up может включать по 1 из перечисленных ниже элементов данных, если этот элемент используется в сессии:

Resources (13.17. Resources);
Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Сообщение Destination Up может включать по 1 из перечисленных ниже элементов данных с разными значениями:

IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

Маршрутизатор, получивший Destination Up выделяет необходимые ресурсы, создает в информационной базе запись с указанными значениями (MAC Address, Latency, Data Rate и т. п.) для получателя. Информация об этом получателе будет сохраняться в базе до получения маршрутизатором сообщения Destination Down (12.15. Сообщение Destination Down), указывающего, что модем потерял связь с удаленным узлом или реализация перешла в состояние Session Termination.

12.12. Отклик Destination Up Response

Маршрутизатор должен передавать сообщение Destination Up Response в ответ на Destination Up (12.11. Сообщение Destination Up) is received.

В заголовке Destination Up Response устанавливается Message Type = 8 (15.3. Регистрации Message Type).

Сообщение Destination Up Response должно содержать по одному из перечисленных ниже элементов данных:

MAC Address (13.7. MAC Address);
Status (13.1. Данные состояния).

Маршрутизатор, желающий получить дополнительную информацию о получателе, указанном в соответствующем сообщении Destination Up, должен установить в отклике Status = 0 ‘Success’ (Таблица 2). Если маршрутизатор не заинтересован в получателе, указанном в соответствующем сообщении Destination Up, он может установить в отклике Status = 1 ‘Not Interested’.

Модему, получившему Destination Up Response с элементом Status, отличным от 0 ‘Success’, недопустимо передавать другие сообщения Destination для этого адресата, например, Destination Down (12.15. Сообщение Destination Down) или Destination Update (12.17. Сообщение Destination Update) с тем же MAC-адресом.

12.13. Сообщение Destination Announce

Обычно модем обнаруживает присутствие одной или нескольких удаленных пар модем-маршрутизатор и анонсирует появление каждого получателя передачей маршрутизатору соответствующего сообщения Destination Up (12.11. Сообщение Destination Up). Однако могут быть случаи, когда маршрутизатор хочет выразить интерес к адресату, который еще не анонсирован (обычно групповой адресат). В таких случаях маршрутизатор может передать сообщение Destination Announce для обозначения своего интереса.

Сообщение Destination Announce маршрутизатор может также отправлять для запроса информации о получателе, (1) интерес к которому был ранее отвергнут статусом 1 ‘Not Interested’ в сообщении Destination Up Response (12.12. Отклик Destination Up Response, Таблица 2) или (2) который раньше был объявлен отключенным (down), в сообщении Destination Down (12.15. Сообщение Destination Down).

В заголовке сообщения Destination Announce указывается Message Type = 9 (15.3. Регистрации Message Type).

Сообщение Destination Announce должно включать элемент данных MAC Address (13.7. MAC Address).

Сообщение Destination Announce может содержать перечисленные ниже элементы данных с разными значениями:

IPv4 Address (13.8. IPv4 Address);
IPv6 Address (13.9. IPv6 Address).

Одним из преимуществ реализации DLEP является использование знаний модема о каналах между удаленными адресатами, что позволяет маршрутизатору избежать зондирования соседей, поэтому реализациям в модемах следует анонсировать доступных адресатов в сообщениях Destination Up, а не полагаться на Destination Announce.

12.14. Отклик Destination Announce Response

Модем должен передавать сообщение Destination Announce Response в ответ на Destination Announce (12.13. Сообщение Destination Announce).

При создании Destination Announce Response устанавливается Message Type = 10 (15.3. Регистрации Message Type) в заголовке сообщения. Сообщение Destination Announce Response должно содержать по одному элементу данных:

MAC Address (13.7. MAC Address);
Status (13.1. Данные состояния).

Destination Announce Response может включать один или несколько элементов данных с разными значениями:

IPv4 Address (13.8. IPv4 Address);
IPv6 Address (13.9. IPv6 Address);
IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

Сообщение Destination Announce Response может включать по одному элементу данных, перечисленных ниже:

Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
Latency (13.16. Latency).

Destination Announce Response может включать по одному элементу данных, если он применяется в сессии:

Resources (13.17. Resources);
Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Если модем не способен незамедлительно сообщить запрошенные сведения (например, адресат в данный момент не доступен), он должен возвратить элемент данных Status = 2 ‘Request Denied’ (Таблица 2).

После передачи сообщения Destination Announce Response с элементом данных Status Data, содержащим отличное от 0 ‘Success’ значение, модем изменения на канале к адресату в сообщении Destination Update.

При получении Destination Announce Response маршрутизатору следует добавить данные об адресате в свою информационную базу.

12.15. Сообщение Destination Down

Модем должен передавать сообщение Destination Down для информирования о недоступности адресата (удаленный узел или multicast-группа).

Маршрутизатор может передать Destination Down для онформирования о том, что ему больше не нужна информация о получателе.

При создании Destination Down устанавливается значение Message Type = 11 в Message Header (15.3. Регистрации Message Type).

Сообщение Destination Down должно включать элемент данных MAC Address (13.7. MAC Address).

Следует отметить, что сообщения Destination Down могут передавать как модемы, так и маршрутизаторы, независимо от того, кто из них сообщил первым об активности (up) адресата.

12.16. Отклик Destination Down Response

Сообщение Destination Down Response должно передаваться получателем Destination Down (12.15. Сообщение Destination Down) для подтверждения того, что относящиеся к этому адресату данные удалены из базы.

В заголовке Destination Down Response указывается Message Type = 12 (15.3. Регистрации Message Type).

Сообщение Destination Down Response должно содержать по одному элементу данных:

MAC Address (13.7. MAC Address);
Status (13.1. Данные состояния).

12.17. Сообщение Destination Update

Модему следует передавать сообщение Destination Update при обнаруженииизменений в информационной базе для нанного адресата (удаленный узел или multicast-группа). Примерами изменений, вызывающих передачу Destination Update, являются:

изменение метрики канала (например, скорости);
смена адреса L3.

В заголовке Destination Update указывается Message Type = 13 (15.3. Регистрации Message Type).

Сообщение Destination Update должно включать элемент данных MAC Address (13.7. MAC Address).

Destination Update может включать по одному из перечисленных элементов данных:

Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
Latency (13.16. Latency).

Destination Update может включать по одному из указанных элементов данных, если он применяется в сессии:

Resources (13.17. Resources);
Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Destination Update может включать один или несколько элементов данных с разными значениями, указанных ниже:

IPv4 Address (13.8. IPv4 Address);
IPv6 Address (13.9. IPv6 Address);
IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);
IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

Параметры метрики, указанные в сообщении, переопределяют парметры, полученные ранее в сообщениях Session, Destination, Link Characteristics (например, Session Initialization, Destination Up, Link Characteristics Response).

Следует отметить, что для этого сообщения нет соответствующего отклика.

12.18. Запрос характеристик канала

Маршрутизатор может передавать сообщение Link Characteristics Request, чтобы запросить у модема инициирование изменений определенных характеристик канала. Запрос может указывать реального (например, удаленный узел) или логического (например, multicast-группу) адресата в сети.

В заголовке Link Characteristics Request указывается Message Type = 14 (15.3. Регистрации Message Type).

Сообщение Link Characteristics Request должно включать элемент данных MAC Address (13.7. MAC Address).

Сообщение Link Characteristics Request должно также включать по меньшей мере по одному элементу данных:

Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
Latency (13.16. Latency).

Link Characteristics Request может включать один из элементов данных Current Data Rate (Receive) (CDRR) или Current Data Rate (Transmit) (CDRT) для запроса отличной от текущей скорости, а также элемент Latency для запроса значения максимальной задержки на канале.

Передающему сообщение маршрутизатору следует понимать, что выполнение запроса Link Characteristics Request может занять достаточно продолжительное время.

12.19. Отклик с характеристиками канала

Модем должен отвечать сообщением Link Characteristics Response при получении Link Characteristics Request (12.18. Запрос характеристик канала).

В заголовке Link Characteristics Response указывается Message Type = 15 (15.3. Регистрации Message Type).

Сообщение Link Characteristics Response должно включать по одному элементу данных:

MAC Address (13.7. MAC Address);
Status (13.1. Данные состояния).

В сообщение Link Characteristics Response следует включать по одному элементу данных:

Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));
Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));
Current Data Rate (Receive) (13.14. Current Data Rate (Receive));
Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));
Latency (13.16. Latency).

Сообщение Link Characteristics Response может включать по одному элементу перечисленных ниже данных, если такой элемент применяется в сессии:

Resources (13.17. Resources);
Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));
Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));
Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Сообщение Link Characteristics Response должно включать полный набор элементов данных метрики, указывая все параметры, объявленные в Session Initialization Response (12.6. Отклик Session Initialization Response). Значения метрических параметров в Link Characteristics Response должны отражать характеристики канала после выполнения запроса.

Если реализация не способна изменить характеристики канала в соответствии с запросом, она должна указать элемент данных Status с кодом 2 ‘Request Denied’ (Таблица 2).

12.20. Сообщение Heartbeat

Сообщение Heartbeat должно передаваться участником DLEP каждые N мсек, где N задается элементом данных Heartbeat Interval (13.5. Heartbeat Interval) в сообщении Session Initialization (12.5. Сообщение Session Initialization) или Session Initialization Response (12.6. Отклик Session Initialization Response).

При создании сообщения Heartbeat устанавливается значение Message Type = 16 в Message Header (15.3. Регистрации Message Type).

Элементы данных не используются в сообщениях Heartbeat.

Сообщения Heartbeat используются участниками DLEP для обнаружения обрыва связи с партнером по сеансу DLEP (модем или маршрутизатор), как описано в параграфе 7.3.1. Сообщения Heartbeat.

13. Элементы данных DLEP

Элементы данных DLEP (Data Item) перечислены в таблице.

Таблица 1. Типы элементов данных DLEP.

Код типа	Описание
0	Резерв
1	Status (13.1. Данные состояния)
2	IPv4 Connection Point (13.2. IPv4 Connection Point)
3	IPv6 Connection Point (13.3. IPv6 Connection Point)
4	Peer Type (13.4. Peer Type)
5	Heartbeat Interval (13.5. Heartbeat Interval)
6	Extensions Supported (13.6. Extensions Supported)
7	MAC Address (13.7. MAC Address)
8	IPv4 Address (13.8. IPv4 Address)
9	IPv6 Address (13.9. IPv6 Address)
10	IPv4 Attached Subnet (13.10. IPv4 Attached Subnet)
11	IPv6 Attached Subnet (13.11. IPv6 Attached Subnet)
12	Maximum Data Rate (Receive) (MDRR) (13.12. Maximum Data Rate (Receive))
13	Maximum Data Rate (Transmit) (MDRT) (13.13. Maximum Data Rate (Transmit))
14	Current Data Rate (Receive) (CDRR) (13.14. Current Data Rate (Receive))
15	Current Data Rate (Transmit) (CDRT) (13.15. Current Data Rate (Transmit))
16	Latency (13.16. Latency)
17	Resources (RES) (13.17. Resources)
18	Relative Link Quality (Receive) (RLQR) (13.18. Relative Link Quality (Receive))
19	Relative Link Quality (Transmit) (RLQT) (13.19. Relative Link Quality (Transmit))
20	Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU))
21-65407	Не выделены (доступны для будущих расширений)
65408-65534	Резерв для приватного использования (доступны для экспериментов)
65535	Резерв

13.1. Данные состояния

Для сообщений Session Termination (12.9. Сообщение Session Termination) элемент данных Status Data указывает причину разрыва сессии. В остальных сообщениях этот элемент указывает успех или отказ предыдущего полученного сообщения.

Элемент Status Data включает необязательное поле Text, в котором может размещаться текстовое описание статуса. Использование поля Text полностью отдано на откуп принимающей реализации, например, оно может быть записано в системный журнал или просто отброшено. При отсутствии поля Text в элементе данных Status поле Length должно иметь значение 1. Структура Status Data Item показана на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code   | Text...                                       :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

1 + размер Text (в октетах).

Status Code

Один из кодов состояния, указанных в таблице 2.

Text

Строка с кодировкой UTF-8 [RFC3629], описывающая причину состояния для целей, определяемых реализацией. Поскольку это поле служит для описания, реализации следует использовать лишь печатаемые символы. Реализации недопустимо считать поле Text строкой печатаемых символов с NUL-завершением.

Таблица 2. Коды состояния DLEP.

Код	Режим	Описание	Причина
0	Продолжение	Успех	Сообщение успешно обработано.
1	Продолжение	Не интересно	Получатель не заинтересован в предмете (теме) данного сообщения, например, в сообщении Destination Up Response (12.12. Отклик Destination Up Response), для индикации отсутствия других сообщений о получателе.
2	Продолжение	Запрос отвергнут	Получатель отверг выполнение запроса.
3	Продолжение	Несогласованные данные	Один или несколько элементов данных в сообщении описывают логически несогласованное состояние в сети, например, в сообщении Destination Up (12.11. Сообщение Destination Up) указана подсеть, не соответствующая текущей подсети адресата.
4-111	Продолжение	<Не выделено>	Для использования в будущем.
112-127	Продолжение	<Резерв для приватного использования>	Доступно для экспериментов.
128	Прерывание	Неизвестное сообщение	Сообщение не распознано реализацией.
129	Прерывание	Неожиданное сообщение	Сообщение не ожидается в текущем состоянии. Например, сообщение Session Initialization (12.5. Сообщение Session Initialization) в In-Session.
130	Прерывание	Недействительные данные	Один или несколько элементов данных в сообщении недействительны, не ожидаются или некорректно продублированы.
131	Прерывание	Недействительный адресат	Адресат, указанный в сообщении, не соответствует анонсированному ранее, например, в сообщении Link Characteristics Response (12.19. Отклик с характеристиками канала).
132	Прерывание	Тайм-аут	Истекло время ожидания в сессии.
133-239	Прерывание	<Не выделено>	Для использования в будущем.
240-254	Прерывание	<Резерв для приватного использования>	Доступно для экспериментов.
255	Прерывание	Отключение	Партнер прерывает сессию по причине отключения.

13.2. IPv4 Connection Point

Элемент данных IPv4 Connection Point Data Item указывает адрес IPv4 и может также задавать номер порта TCP на модеме для организации соединения. При наличии информации маршрутизатор должен использовать ее для организации соединения TCP с модемом. Формат IPv4 Connection Point показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |               IPv4 Address...                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:  ...cont.     |   TCP Port Number (необязат)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

5 (или 7 при включении порта TCP).

Flags

Поле флагов, описанных ниже.

IPv4 Address

Адрес IPv4, прослушиваемый модемом.

TCP Port Number

Номер порта TCP в модеме.

Если Length = 7, заданный номер порта должен использоваться для организации сессии TCP. Если порт TCP не указан (Length = 5), маршрутизатор должен использовать стандартный порт DLEP (15.4. Регистрации DLEP Data Item).

Поле Flags имеет форму, показанную на рисунке.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |T|
+-+-+-+-+-+-+-+-+

Флаг использования TLS, указывающий, защищено (1) или нет (0) соединение TCP с помощью TLS [RFC5246].

Reserved

Биты зарезервированы для использования в будущем и должны быть сброшены (0).

13.3. IPv6 Connection Point

Элемент данных IPv6 Connection Point Data Item указывает адрес IPv6 и может также задавать номер порта TCP на модеме для организации соединения. При наличии информации маршрутизатор должен использовать ее для организации соединения TCP с модемом. Формат IPv6 Connection Point показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |                IPv6 Address                   :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:  ...cont.     |   TCP Port Number (optional)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

17 (или 19 при включении порта TCP).

Flags

Поле флагов, описанных ниже.

IPv6 Address

Адрес IPv6, прослушиваемый модемом.

TCP Port Number

Номер порта TCP в модеме.

Если Length = 19, заданный номер порта должен использоваться для организации сессии TCP. Если порт не указан (Length = 17), маршрутизатор должен использовать стандартный порт DLEP (15.4. Регистрации DLEP Data Item).

Поле Flags имеет форму, показанную на рисунке.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |T|
+-+-+-+-+-+-+-+-+

Флаг использования TLS, указывающий, защищено (1) или нет (0) соединение TCP с помощью TLS [RFC5246].

Reserved

Биты зарезервированы для использования в будущем и должны быть сброшены (0).

13.4. Peer Type

Элемент данных Peer Type используется маршрутизаторами и модемами для указания дополнительных сведений о типе и свойствах беспроводной (over-the-air) плоскости управления.

В некоторых устройствах доступ к общей радиосреде (RF) строго контролируется. Примером могут служить спутниковые модемы, где протоколы (фирменные по природе) обеспечивают подключение к среде лишь уполномоченных модемов. Другим примером модемов такого класса являются правительственные и военные устройства, в которых применяются механизмы, обеспечивающие доступ к среде только разрешенных устройств. Существуют также модемы, где такого контроля доступа нет. Примером служат модемы, поддерживающие режим 802.11. Для индикации контроля доступа к среде используется флаг Secured Medium (S).

Peer Type Data Item включает текстовое описание партнера, которое предполагается используемым для информационных целей (например, для вывода на дисплей). Поля элемента данных Peer Type показаны на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         | Description...                                :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

1 + размер Description (в октетах).

Flags

Поле флагов, описанных ниже.

Description

Текстовая строка UTF-8 [RFC3629]. Например, спутниковый модем может задать строку “Satellite terminal”. Поскольку это поле предназначено для задания дополнительной информации в командах отображения, следует использовать в поле только печатаемые символы.

Реализациям недопустимо предполагать, что строка Description является строкой печатаемых символом с NUL-символом в конце.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |S|
+-+-+-+-+-+-+-+-+

Поле Flags имеет форму, показанную на рисунке.

Флаг защищенной среды (Secured Medium), используемый модемом для указания контроля доступа к общей среде (RF) – (1) указывает контролируемый доступ, (0) — отсутствие контроля. Флаг имеет значение лишь в сигналах и сообщениях, передаваемых модемом.

Reserved

Биты зарезервированы для использования в будущем и должны быть сброшены (0).

13.5. Heartbeat Interval

Элемент данных Heartbeat Interval используется для задания периода (в мсек) передачи сообщений Heartbeat (12.20. Сообщение Heartbeat). Формат Heartbeat Interval Data Item показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Heartbeat Interval                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

Heartbeat Interval

Интервал (в миллисекундах) между сообщениями Heartbeat, указанный 32-битовым целым числом без знака. Значение 0 недопустимо.

Как указано выше, прием любого действительного сообщения DLEP должен сбрасывать отсчет таймера интервала в 0 (т. е. действительные сообщения DLEP выполняют роль Heartbeat).

13.6. Extensions Supported

Элемент данных Extensions Supported используется модемами и маршрутизаторами для согласования дополнительных функций, которые могут поддерживаться. Поле Extensions List содержит конкатенацию типов поддерживаемых расширений из реестра IANA Extension Type Values. Каждле определение Extension Type указывает дополнительные сигналы и элементы данных, которые будут поддерживаться. Формат элемента данных показан ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions List...                                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

Размер поля Extensions List в октетах (удвоенное число расширений.

Extensions List

Список поддерживаемых расширений, указанных 2-октетными значениями из реестра Extension Type Values.

13.7. MAC Address

Элемент данных MAC Address содержит адрес получателя на удаленном узле.

DLEP может поддерживать MAC-адреса в формате EUI⁸-48 и EUI-64, но все адреса в данной сессии DLEP должны иметь один формат и должны соответствовать MAC-адресу на подключенном модеме (например, если модем подключен к маршрутизатору EUI-48 MAC, все получатели, доступные через этот модем, должны использовать EUI-48).

Примерами виртуальных адресатов могут служить (1) групповой MAC-адрес (2) или широковещательный MAC-адрес FF:FF:FF:FF:FF:FF.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      MAC Address                              :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                MAC Address    :     (для EUI-64)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

6 для формата EUI-48 или 8 для EUI-64.

MAC Address

MAC-адрес получателя.

13.8. IPv4 Address

При включении в сообщение Session Update этот элемент данных содержит партнерский адрес IPv4, а в сообщениях Destination – адреса IPv4 для получателей. В любом случае элемент данных включает также индикацию того, задает ли этот элемент (1) новый или имеющийся адрес или (2) удаление известного ранее адреса. Формат элемента IPv4 Address показан на рисунке.


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         | IPv4 Address                                  :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:  ...продолж.  |
+-+-+-+-+-+-+-+-+

Data Item Type

Length

Flags

Поле флагов, описанное ниже.

IPv4 Address

Адрес IPv4 для адресата или партнера.

Поле Flags имеет вид, показанный на рисунке.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |A|
+-+-+-+-+-+-+-+-+

Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).

Reserved

Резерв на будущее (должны иметь значение 0).

13.8.1. Обработка IPv4 Address

Обработка IPv4 Address должна выполняться в контексте сессии DLEP, где представлен элемент. Обработка ошибочных или логически противоречивых случаев зависит от типа сообщения в элементом данных и описана ниже.

Если сообщение относится к сессии, например, Session Initialization (12.5. Сообщение Session Initialization) или Session Update (12.7. Сообщение Session Update), получатель противоречивых данных должен передать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент Status (13.1. Данные состояния) с кодом 130 ‘Invalid Data’ и перейти в состояние Session Termination. Примеры таких случаев включают:

операцию Drop для адреса, не связанного с партнером в текущей сессии;
операцию Add для адреса, который уже добавлен партнеру в текущей сессии.

Если сообщение относится к адресату, например, Destination Up (12.11. Сообщение Destination Up) или Destination Update (12.17. Сообщение Destination Update), получатель противоречивых данных может передать отклик с элементом Status = 3 ‘Inconsistent Data’, но должен продолжать обработу сессии. Примерами могут служить:

операция Add для адреса, который уже добавлен получателю в текущей сессии;
операция Add для адреса, который связан с другим адресатом или партнером в текущей сессии;
операция Add для адреса, который не имеет смысла, например, определен как непересылаемый [RFC6890];
операцию Drop для адреса, не связанного с получателем в текущей сессии.

Если нет сообщения для ответа (например, Destination Update), реализация должна продолжать обработку сессии.

Модемы, не отслеживающие адреса IPv4, должны игнорировать элементы данных IPv4 Address.

13.9. IPv6 Address

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         | IPv6 Address                                  :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address  |
+-+-+-+-+-+-+-+-+

В сообщении Session Update этот элемент данных содержит партнерский адрес IPv6, а в Destination – адреса IPv6 для получателей. В любом случае элемент данных включает также индикацию того, задает ли этот элемент (1) новый или имеющийся адрес или (2) удаление известного ранее адреса. Формат элемента IPv6 Address показан на рисунке.

Data Item Type

Length

Flags

Поле флагов, описанное ниже.

IPv6 Address

Адрес IPv6 для адресата или партнера.

Поле Flags имеет форму, показанную на рисунке.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |A|
+-+-+-+-+-+-+-+-+

Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).

Reserved

Резерв на будущее (должны иметь значение 0).

13.9.1. Обработка IPv6 Address

Обработка IPv6 Address должна выполняться в контексте сессии DLEP, где представлен элемент. Обработка ошибочных или логически противоречивых случаев зависит от типа сообщения в элементом данных и описана ниже.

операцию Drop для адреса, не связанного с партнером в текущей сессии;
операцию Add для адреса, который уже добавлен партнеру в текущей сессии.

операция Add для адреса, который уже добавлен получателю в текущей сессии;
операция Add для адреса, который связан с другим адресатом или партнером в текущей сессии;
операция Add для адреса, который не имеет смысла, например, определен как непересылаемый [RFC6890];
операцию Drop для адреса, не связанного с получателем в текущей сессии.

Если нет подходящего сообщения для ответа (например, Destination Update), реализация должна продолжать обработку сессии.

Модемы, не отслеживающие адреса IPv6, должны игнорировать элементы данных IPv6 Address.

13.10. IPv4 Attached Subnet

Элемент данных DLEP IPv4 Attached Subnet позволяет устройству объявить о подключенной к нему подсети IPv4 (например, оконечной сети) и указать, что ему известно о присутствии или потере подсети у удаленного адресата. Элемент IPv4 Attached Subnet имеет форму, показанную на рисунке.


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Flags        |          IPv4 Attached Subnet                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...продолж.   |Prefix Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

Flags

Поле флагов, описанное ниже.

IPv4 Attached Subnet

Подсеть IPv4 доступная у адресата.

Prefix Length

Размер префикса (0-32) подсети IPv4. Префиксы, выходящие за указанный диапазон, должны считаться недействительными.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |A|
+-+-+-+-+-+-+-+-+

Поле Flags имеет форму, показанную на рисунке.

Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).

Reserved

Резерв на будущее (должны иметь значение 0).

13.10.1. Обработка IPv4 Attached Subnet

Обработка IPv4 Attached Subnet должна выполняться в контексте сессии DLEP, где представлен элемент.

операцию Drop для подсети, не связанной с партнером в текущей сессии;
операцию Add для подсети, которая уже добавлена партнеру в текущей сессии.

операция Add для подсети, которая уже добавлена получателю в текущей сессии;
операция Add для подсети, которая связана с другим адресатом или партнером в текущей сессии;
операция Add для подсети, которая не имеет смысла, например, определена как непересылаемая [RFC6890];
операцию Drop для подсети, не связанной с получателем в текущей сессии.

Модемы, не отслеживающие подсети IPv4, должны игнорировать элементы данных IPv4 Attached Subnet.

13.11. IPv6 Attached Subnet

Элемент данных DLEP IPv6 Attached Subnet позволяет устройству объявить о подключенной к нему подсети IPv6 (например, оконечной сети) и указать, что ему известно о присутствии или потере подсети у удаленного адресата. Элемент IPv6 Attached Subnet имеет форму, показанную на рисунке.

  0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |         IPv6 Attached Subnet                  :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                   IPv6 Attached Subnet                        :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                   IPv6 Attached Subnet                        :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                   IPv6 Attached Subnet                        :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...продолж.   | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

Flags

Поле флагов, описанное ниже.

IPv6 Attached Subnet

Подсеть IPv6 доступная у адресата.

Prefix Length

Размер префикса (0-128) подсети IPv6. Префиксы, выходящие за указанный диапазон, должны считаться недействительными.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |A|
+-+-+-+-+-+-+-+-+

Поле Flags имеет форму, показанную на рисунке.

Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).

Reserved

Резерв на будущее (должны иметь значение 0).

13.11.1. Обработка IPv6 Attached Subnet

Обработка IPv6 Attached Subnet должна выполняться в контексте сессии DLEP, где представлен элемент. Обработка ошибочных или логически противоречивых случаев зависит от типа сообщения в элементом данных и описана ниже.

операцию Drop для подсети, не связанной с партнером в текущей сессии;
операцию Add для подсети, которая уже добавлена партнеру в текущей сессии.

операция Add для подсети, которая уже добавлена получателю в текущей сессии;
операция Add для подсети, которая связана с другим адресатом или партнером в текущей сессии;
операция Add для подсети, которая не имеет смысла, например, определена как непересылаемая [RFC6890];
операцию Drop для подсети, не связанной с получателем в текущей сессии.

Модемы, не отслеживающие подсети IPv6, должны игнорировать элементы данных IPv6 Attached Subnet.

13.12. Maximum Data Rate (Receive)

Элемент данных Maximum Data Rate (Receive) (MDRR) служит для указания максимальной теоретически доступной скорости (бит/с) приема данных на канале. Формат Maximum Data Rate (Receive) показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MDRR (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        MDRR (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

Maximum Data Rate (Receive)

64-битовое целое число без знака, указывающее максимальную теоретическую скорость приема (бит/с) на канале.

13.13. Maximum Data Rate (Transmit)

Элемент данных Maximum Data Rate (Transmit) (MDRT) служит для указания максимальной теоретически доступной скорости (бит/с) приема данных на канале. Формат Maximum Data Rate (Transmit) показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MDRT (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        MDRT (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

Maximum Data Rate (Transmit)

64-битовое целое число без знака, задающее максимальную теоретическую скорость передачи (бит/с) на канале.

13.14. Current Data Rate (Receive)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        CDRR (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        CDRR (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Элемент данных Current Data Rate (Receive) (CDRR) служит для указания текущей скорости (бит/с) приема данных на канале. При использовании в сообщении Link Characteristics Request Message (12.18. Запрос характеристик канала), Current Data Rate (Receive) представляет желаемую скорость приема в канале (бит/с). Формат Current Data Rate (Receive) показан на рисунке.

Data Item Type

Length

Current Data Rate (Receive)

64-битовое целое число без знака, указывающее текущую доступную скорость приема (бит/с) на канале.

Если Current Data Rate (Receive) и Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive)) не различаются, значение Current Data Rate (Receive) должно устанавливаться равным Maximum Data Rate (Receive). Для Current Data Rate (Receive) недопустимо превышать значение Maximum Data Rate (Receive).

13.15. Current Data Rate (Transmit)

Элемент данных Current Data Rate (Transmit) (CDRR) служит для указания текущей скорости (бит/с) передачи данных на канале. При использовании в сообщении Link Characteristics Request Message (12.18. Запрос характеристик канала), Current Data Rate (Transmit) представляет желаемую скорость передачи в канале (бит/с). Формат Current Data Rate (Transmit) показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        CDRT (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        CDRT (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

Current Data Rate (Transmit)

64-битовое целое число без знака, указывающее текущую доступную скорость передачи (бит/с) на канале.

Если Current Data Rate (Transmit) и Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit)) не различаются, значение Current Data Rate (Receive) должно устанавливаться равным Maximum Data Rate (Transmit). Для Current Data Rate (Transmit) недопустимо превышать значение Maximum Data Rate (Transmit).

13.16. Latency

Элемент данных Latency служит для укаазния задержки на канале в микросекундах. Значение Latency указывает задержку при передаче. Расчет задержки зависит от реализации, например, это может быть средняя задержка, рассчитанная из внутренней очереди. Формат элемента данных Latency показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Latency                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                           Latency                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

Length

Latency

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

13.17. Resources

Элемент данных Resources (RES) служит для указания количества ограниченных (конечных) ресурсов, доступных для передачи и приема данных у адресата, в процентах от 0 (нет ресурсов) до 100 (полный доступ), в предположении прекращения передачи и приема данных при Resources = 0. Примером таких ресурсов может служить заряд батареи, память для очередей, загрузка процессора. Конкретные критерии выходят за рамки спецификации и зависят от реализации. Элемент данных предназначен для индикации тех или иных возможностей модема и/или маршрутизатора на стороне получателя. Формат элемента данных представлен на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     RES       |
+-+-+-+-+-+-+-+-+

Data Item Type

Length

Resources

8-битовое целое число без знака, указывающее доступность ресурса в процентах (0-100). Значения больше 100 должны считаться недействительными.

Если устройство не может рассчитать Resources, использование элемента данных недопустимо.

13.18. Relative Link Quality (Receive)

Элемент данных Relative Link Quality (Receive) (RLQR) служит для индикации качества приема на канале к получателю в процентах. 0 указывает минимальное качество, 100 – наилучшее. Качество в данном контексте определяется стабильностью приема на канале – предполагается, что получатель с высоким значением Relative Link Quality (Receive) имеет стабильные параметры метрики DLEP, а при низком Relative Link Quality (Receive) метрика канала может быстро меняться в широком диапазоне. Формат Relative Link Quality (Receive) показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     RLQR      |
+-+-+-+-+-+-+-+-+

Data Item Type

Length

Relative Link Quality (Receive)

8-битовое целое число без знака, указывающее относительное качество приема в процентах (0-100). Значения больше 100 должны считаться недействительными.

Если устройство не может рассчитать Relative Link Quality (Receive), использование элемента данных недопустимо.

13.19. Relative Link Quality (Transmit)

Элемент данных Relative Link Quality (Transmit) (RLQT) служит для индикации качества передачи на канале к получателю в процентах. 0 указывает минимальное качество, 100 – наилучшее. Качество в данном контексте определяется стабильностью передачи на канале – предполагается, что получатель с высоким значением Relative Link Quality (Transmit) имеет стабильные параметры метрики DLEP, а при низком Relative Link Quality (Transmit) метрика канала может быстро меняться в широком диапазоне. Формат Relative Link Quality (Transmit) показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     RLQT      |
+-+-+-+-+-+-+-+-+

Data Item Type

Length

Relative Link Quality (Transmit)

8-битовое целое число без знака, указывающее относительное качество передачи в процентах (0-100). Значения больше 100 должны считаться недействительными.

Если устройство не может рассчитать Relative Link Quality (Transmit), использование элемента данных недопустимо.

13.20. Maximum Transmission Unit (MTU)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             MTU               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Элемент данных Maximum Transmission Unit (MTU) используется для указания максимального размера (в октетах) пакетов IP, которые можно передать без фрагментирования (с учетом заголовков, но не считая заголовки нижележащих уровней). Поля Maximum Transmission Unit Data Item показаны на рисунке.

Data Item Type

Length

Maximum Transmission Unit

Максимальный размер (в октетах) пакета IP, который можно передать без фрагментирования (с учетом заголовков, но не считая заголовки нижележащих уровней).

Если устройство не способно рассчитать MTU, использование этого элемента данных недопустимо.

14. Вопросы безопасности

При использовании DLEP может возникать несколько проблем безопасности, отмеченных ниже.

Атакующий может представиться участником DLEP путем инициирования сессии или вставки сообщений DLEP в существующую сессию.
Атакующий может менять элементы данных, заставляя принимающую сторону вносить в свою базу некорректные сведения о сети.
Атакующий может подключиться к незащищенной радиосети и инжектировать сигналы (over-the-air), влияющие на сведения, сообщаемые модемом DLEP, что может менять картину пересылки в маршрутизаторе.

Влияние атак на партнеров DLEP пропорционально степени использования данных DLEP плоскостью (уровнем) управления. Хотя использование данных DLEP другими компонентами плоскости управления выходит за рамки этого документа, такие данные могут влиять на работу сети. Например, при использовании статистики DLEP в расчетах стоимости маршрутов, прикинувшийся партнером DLEP злоумышленник может вынудить маршрутизатор к выбору неоптимального пути. Похожие проблемы могут возникать при использовании данных DLEP алгоритмами задания правил – вставка фиктивных данных через DLEP может приводить к принятию этими алгоритмами некорректных решений, нарушающих работу сети.

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

При использовании на транспортном уровне протокола TLS каждому партнеру следует проверять действительность представленных другим партнером свидетельств (credential) в процессе организации сеанса TLS. При «выделенном развертывании» реализации, пытающийся использовать TLS, может потребоваться использование (1) заранее распространенных (pre-shared) ключей, (2) специальных методов проверки отождествления партнеров (3) или методов [RFC5487]. В модели «сетевого развертывания» (4. Варианты развертывания) следует использовать [RFC7525].

На уровне L2, поскольку работа DLEP ограничена одним интервалом (возможно, логическим), реализациям следует защищать также каналы L2. Примеры методов защиты каналов L2 включают [IEEE-802.1AE] и [IEEE-802.1X].

Проверяя флаг Secured Medium в элементе данных Peer Type (13.4. Peer Type), маршрутизатор может принять решение о доверии к информации, представленной модемом DLEP. В иных случаях маршрутизатору следует рассмотреть вопрос ограничения размера подключенных подсетей путем анонсирования элементов данных IPv4 Attached Subnet (13.10. IPv4 Attached Subnet) и/или IPv6 Attached Subnet (13.11. IPv6 Attached Subnet), учитываемых при выборе маршрута.

Для предотвращения возможных DoS-атак (отказ в обслуживании) реализациям, использующим механизм Peer Discovery, рекомендуется (1) поддерживать в информационной базе список хостов, с которыми были связаны отказы при инициализации сессии, даже если такие хосты предоставляют приемлемый сигнад Peer Discovery, и (2) игнорировать от таких хостов последующие сигналы Peer Discovery.

Данная спецификация не касается защиты плоскости данных, поскольку эта плоскость не затрагивается протоколом напрямую и в ней могут использоваться стандартные процедуры защиты.

15. Взаимодействие с IANA

15.1. Регистрации

Агентство IANA создало новый реестр для протокола Dynamic Link Exchange Protocol (DLEP), включающий описанные ниже субреестры.

15.2. Типы сигналов

Агентстов IANA создало реестр DLEP под названием Signal Type Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Код типа	Описания, правила
0	Reserved
1	Peer Discovery Signal
2	Peer Offer Signal
3-65519	Unassigned / Specification Required
65520-65534	Reserved for Private Use
65535	Reserved

15.3. Регистрации Message Type

Агентство IANA создало реестр DLEP Message Type Values. В таблице приведены исходные значения и правила выделения в соответствии с [RFC5226].

Код типа	Описания, правила
0	Резерв
1	Session Initialization
2	Session Initialization Response
3	Session Update
4	Session Update Response
5	Session Termination
6	Session Termination Response
7	Destination Up
8	Destination Up Response
9	Destination Announce
10	Destination Announce Response
11	Destination Down
12	Destination Down Response
13	Destination Update
14	Link Characteristics Request
15	Link Characteristics Response
16	Heartbeat
17-65519	Не выделены, нужна спецификация
65520-65534	Резерв для приватного использования
65535	Резерв

15.4. Регистрации DLEP Data Item

Агентстов IANA создало реестр DLEP под названием Data Item Type Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Код типа	Описания, правила
0	Резерв
1	Status
2	IPv4 Connection Point
3	IPv6 Connection Point
4	Peer Type
5	Heartbeat Interval
6	Extensions Supported
7	MAC Address
8	IPv4 Address
9	IPv6 Address
10	IPv4 Attached Subnet
11	IPv6 Attached Subnet
12	Maximum Data Rate (Receive) (MDRR)
13	Maximum Data Rate (Transmit) (MDRT)
14	Current Data Rate (Receive) (CDRR)
15	Current Data Rate (Transmit) (CDRT)
16	Latency
17	Resources (RES)
18	Relative Link Quality (Receive) (RLQR)
19	Relative Link Quality (Transmit) (RLQT)
20	Maximum Transmission Unit (MTU)
21-65407	Не выделены, нужна спецификация
65408-65534	Резерв для приватного использования
65535	Резерв

15.5. Регистрации DLEP Status Code

Агентстов IANA создало реестр DLEP под названием Status Code Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Код состояния	Режим	Описания, правила
0	Продолжение	Success
1	Продолжение	Not Interested
2	Продолжение	Request Denied
3	Продолжение	Inconsistent Data
4-111	Продолжение	Не выделены, нужна спецификация
112-127	Продолжение	Приватное использование
128	Прерывание	Unknown Message
129	Прерывание	Unexpected Message
130	Прерывание	Invalid Data
131	Прерывание	Invalid Destination
132	Прерывание	Timed Out
133-239	Прерывание	Не выделены, нужна спецификация
240-254	Прерывание	Резерв для приватного использования
255	Прерывание	Shutting Down

15.6. Регистрации DLEP Extension

Агентстов IANA создало реестр DLEP под названием Extension Type Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Таблица 3. Типы расширений DLEP.

Код	Описания, правила
0	Резерв
1-65519	Не выделены, нужна спецификация
65520-65534	Резерв для приватного использования
65535	Резерв

15.7. Флаги DLEP IPv4 Connection Point

Агентстов IANA создало реестр DLEP под названием IPv4 Connection Point Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит	Описания, правила
0-6	Не выделены, нужна спецификация.
7	Индикатор использования TLS [RFC5246].

15.8. Флаги DLEP IPv6 Connection Point

Агентстов IANA создало реестр DLEP под названием IPv6 Connection Point Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит	Описания, правила
0-6	Не выделены, нужна спецификация.
7	Индикатор использования TLS [RFC5246].

15.9. Флаги DLEP Peer Type

Агентстов IANA создало реестр DLEP под названием Peer Type Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит	Описания, правила
0-6	Не выделены, нужна спецификация.
7	Индикатор использования Secured Medium.

15.10. Флаги DLEP IPv4 Address

Агентстов IANA создало реестр DLEP под названием IPv4 Address Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит	Описания, правила
0-6	Не выделены, нужна спецификация.
7	Индикатор Add/Drop.

15.11. Флаги DLEP IPv6 Address

Агентстов IANA создало реестр DLEP под названием IPv6 Address Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит	Описания, правила
0-6	Не выделены, нужна спецификация.
7	Индикатор Add/Drop.

15.12. Флаги DLEP IPv4 Attached Subnet

Агентстов IANA создало реестр DLEP под названием IPv4 Attached Subnet Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит	Описания, правила
0-6	Не выделены, нужна спецификация.
7	Индикатор Add/Drop.

15.13. Флаги DLEP IPv6 Attached Subnet

Агентстов IANA создало реестр DLEP под названием IPv6 Attached Subnet Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит	Описания, правила
0-6	Не выделены, нужна спецификация.
7	Индикатор Add/Drop.

15.14. Порт DLEP

Агентство IANA выделило значение 854 в реестре Service Name and Transport Protocol Port Number Registry (http://www.iana.org/assignments/service-names-port-numbers/) для протокола DLEP, определенного этим документом. Назначение действительно для протоколов TCP и UDP.

15.15. Групповой адрес DLEP IPv4 Link-Local

Агентство IANA выделило групповой адрес IPv4 224.0.0.117 в реестре http://www.iana.org/assignments/multicast-addresses для DLEP Discovery.

15.16. Групповой адрес DLEP IPv6 Link-Local

Агентство IANA выделило групповой адрес IPv6 FF02:0:0:0:0:0:1:7 в реестре http://www.iana.org/assignments/ipv6-multicast-addresses для DLEP Discovery.

16. Литература

16.1. Нормативные документы

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646”, STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, “The Generalized TTL Security Mechanism (GTSM)”, RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.

[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

16.2. Дополнительная литература

[IEEE-802.1AE] “IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Security”, DOI 10.1109/IEEESTD.2006.245590, <http://ieeexplore.ieee.org/document/1678345/>.

[IEEE-802.1X] “IEEE Standards for Local and metropolitan area networks–Port-Based Network Access Control”, DOI 10.1109/IEEESTD.2010.5409813, <http://ieeexplore.ieee.org/document/5409813/>.

[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5487] Badra, M., “Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode”, RFC 5487, DOI 10.17487/RFC5487, March 2009, <http://www.rfc-editor.org/info/rfc5487>.

[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, “Special-Purpose IP Address Registries”, BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”, BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.

Приложение A. Потоки сигналов обнаружения

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор инициирует обнаружение,
|                                     запускает таймер и передает сигнал 
|-------Peer Discovery---->X          Peer Discovery.

         ~ ~ ~ ~ ~ ~ ~                Отсчет таймера завершается до приема
                                      Peer Offer.
|                                     
|-------Peer Discovery---------->|    Маршрутизатор повторяет Peer Discovery.
                                 |
                                 |    Модем получает Peer Discovery.
                                 |
                                 |    Модем передает Peer Offer с данными
|<--------Peer Offer-------------|    Connection Point.
:
:                                     Маршрутизатор МОЖЕТ отключить таймер
:                                     обнаружения и прекратить передачу 
:                                     Peer Discovery.

Приложение B. Потоки сообщений на уровне партнеров

B.1. Инициализация сессии

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор соединяется с найденной
|--Организовано соединение TCP--->    или заданной Modem Connection Point.
|
|                                     Маршрутизатор передает сообщение
|----Session Initialization----->|    Session Initialization.
                                 |
                                 |    Модем получает сообщение
                                 |    Session Initialization.
                                 |
                                 |    Модем передает сообщение Session 
|<--Session Initialization Resp.-|    Initialization Response с элементом 
|                                |    данных 'Success'.
|                                |
|<<============================>>|    Сессия организована.
:                                :    Начинается передача Heartbeat.

B.2. Отвергнутая инициализация сессии

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор соединяется с найденной
|--Организовано соединение TCP--->    или заданной Modem Connection Point.
|
|                                     Маршрутизатор передает сообщение
|----Session Initialization----->|    Session Initialization.
                                 |
                                 |    Модем получает сообщение
                                 |    Session Initialization, но не 
                                 |    поддерживает анонсированные расширения.
                                 |
                                 |    Модем передает сообщение Session 
|<--Session Initialization Resp.-|    Initialization Response с элементом 
|                                     данных 'Request Denied'.
|
|
|                                     Маршрутизатор получает негативный отклик
|                                     Session Initialization Response и
||---------TCP close------------||    разрывает соединение TCP.

B.3. Смена IP-адреса маршрутизатора

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор передает сообщение
|-------Session Update---------->|    Session Update с анонсом смены 
                                 |    адреса IP.
                                 |
                                 |    Модем получает Session Update
                                 |    и обновляет внутреннее состояние.
                                 |
|<----Session Update Response----|    Модем передает Session Update
                                 |    Response.

B.4. Изменение модемом метрики в масштабе сессии

Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                 |    Модем передает Session Update с
|<--------Session Update---------|    анонсом изменения метрики в сессии.
|
|                                     Маршрутизатор получает Session Update
|                                     и обновляет внутреннее состояние.
|
|----Session Update Response---->|    Маршрутизатор передает Session Update
                                 |    Response.

B.5. Разрыв сессии маршрутизатором

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор передает Session Termination
|------Session Termination------>|    с элементом данных Status.
|                                |
|-------TCP shutdown (send)--->  |    Маршрутизатор прекращает передачу сообщений.
                                 |
                                 |    Модем получает Session Termination,
                                 |    прекращает учет полученных Heartbeat
                                 |    и прекращает передачу Heartbeat.
                                 |
                                 |    Модем передает Session Termination
|<---Session Termination Resp.---|    Response с Status = 'Success'.
|
|                                     Модем прекращает передачу сообщений.
|
||---------TCP close------------||    Сессия прервана.

B.6. Разрыв сессии модемом

Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                 |    Модем передает Session Termination
|<----Session Termination--------|    Message с элементом Status.
|
|                                     Модем прекращает передачу сообщений.
|
|                                     Маршрутизатор получает Session
|                                     Termination,  прекращает учет
|                                     полученных Heartbeat и прекращает
|                                     передачу Heartbeat.
|
|                                     Маршрутизатор передает Session Termination
|---Session Termination Resp.--->|    Response с Status = 'Success'.
                                 |
                                 |    Маршрутизатор прекращает передачу сообщений.
                                 |
||---------TCP close------------||    Сессия прервана.

B.7. Сообщения Heartbeat

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|----------Heartbeat------------>|    Маршрутизатор передает Heartbeat.
                                 |
                                 |    Модем сбрасывает таймер Heartbeat.

         ~ ~ ~ ~ ~ ~ ~

|---------[Any Message]--------->|    Модем получает любое сообщение от
                                 |    маршрутизатора.
                                 |
                                 |    Модем сбрасывает таймер Heartbeat.

         ~ ~ ~ ~ ~ ~ ~

|<---------Heartbeat-------------|    Модем передает Heartbeat.
|
|                                     Маршрутизатор сбрасывает таймер Heartbeat.

         ~ ~ ~ ~ ~ ~ ~

|<--------[Any Message]----------|    Маршрутизатор получает любое сообщение
|                                     от модема.
|
|                                     Маршрутизатор сбрасывает таймер Heartbeat.

B.8. Маршрутизатор определил Heartbeat Timeout

Маршрутизатор                Модем    Описание сигнала  
========================================================================
         X<----------------------|    Маршрутизатор не получает Heartbeat.


|        X<----------------------|    Маршрутизатор не получает несколько
|                                     Heartbeat.
|
|
|------Session Termination------>|    Маршрутизатор передает Session 
|                                     Termination с Status = 'Timeout'
:
:                                     Прерывание...

B.9. Модем определил Heartbeat Timeout

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|---------------------->X             Модем не получает Heartbeat.


|---------------------->X        |    Модем не получает несколько
                                 |    Heartbeat.
                                 |
                                 |
|<-----Session Termination-------|    Модем передает Session Termination
                                 |    с Status = 'Timeout'
                                 :
                                 :    Прерывание...

Приложение C. Потоки сообщений на уровне адресата

C.1. Уведомления об адресатах

Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                 |    Модем обнаруживает доступность нового 
                                 |    логического адресата и передает 
|<-------Destination Up----------|    Destination Up.
|
|------Destination Up Resp.----->|    Маршрутизатор передает Destination Up
                                 |    Response.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    логического адресата и передает 
|<-------Destination Update------|    Destination Update.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    логического адресата и передает 
|<-------Destination Update------|    Destination Update.

            ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает недоступность
                                 |    логического адресата и передает 
|<-------Destination Down--------|    Destination Down.
|
|                                     Маршрутизатор получает Destination Down,
|                                     обновляет внутреннее состояние и 
|------Destination Down Resp.--->|    передает Destination Down Response.

C.2. Уведомление о групповом адресате

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор обнаруживает нового
|                                     группового получателя и передает
|-----Destination Announce------>|    Destination Announce.
                                 |
                                 |    Модем обновляет внутреннее состояние
                                 |    для отслеживания группового адресата
|<-----Dest. Announce Resp.------|    и передает Destination Announce
                                      Response.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    группового адресата и передает
|<-------Destination Update------|    Destination Update.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    группового адресата и передает
|<-------Destination Update------|    Destination Update.

            ~ ~ ~ ~ ~ ~ ~
|                                     Маршрутизатор обнаруживает 
|                                     недоступность группового адресата
|--------Destination Down------->|    и передает Destination Down.
                                 |
                                 |    Модем получает Destination Down,
                                 |    обновляет внутреннее состояние и
|<-----Destination Down Resp.----|    передает Destination Down Response.

C.3. Link Characteristics Request

Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                      Адресат уже анонсирован каким-либо
           ~ ~ ~ ~ ~ ~ ~              партнером.

|                                     Модему нужны другие характеристики
|                                     для адресата и он передает Link
|--Link Characteristics Request->|    Characteristics Request.
                                 |
                                 |    Модем пытается настроить свойства
                                 |    канала в соответствии с запросом
                                 |    и передает Link Characteristics
|<---Link Characteristics Resp.--|    Response с новым значением.

Благодарности

Спасибо членам группы разработки DLEP, предоставившим бесценную информацию. В эту команду входят Teco Boot, Bow-Nan Cheng, John Dowdell и Henning Rogge.

Хочется также отметить влияние и вклад Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, Vikram Kaul, Nelson Powell, Lou Berger и Victoria Pritchard.

Адреса авторов

Stan Ratliff

VT iDirect

13861 Sunrise Valley Drive, Suite 300

Herndon, VA 20171

United States of America

Email: sratliff@idirect.net

Shawn Jury

Cisco Systems

170 West Tasman Drive

San Jose, CA 95134

United States of America

Email: sjury@cisco.com

Darryl Satterwhite

Broadcom

Email: dsatterw@broadcom.com

Rick Taylor

Airbus Defence & Space

Quadrant House

Celtic Springs

Coedkernew

Newport NP10 8FZ

United Kingdom

Email: rick.taylor@airbus.com

Bo Berry

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Dynamic Link Exchange Protocol – протокол динамического обмена информацией о соединениях.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Line-of-sight – прямая видимость.

5Demand Assigned Multiple Access – множественный доступ по запросу.

6Media Access Control – управление доступом к среде.

7Transport Layer Security – защита на транспортном уровне.

8Extended Unique Identifier – расширенный уникальный идентификатор.