Кратко

  • RFC 3038 устранял конкретное несоответствие: VPI/VCI был локальной меткой ATM и мог измениться на следующем переходе, но соседним ATM-LSR требовалось связать одну виртуальную цепь в сообщениях LDP.
  • Внутриполосная процедура точка-точка не считала PROPOSE согласием. Сначала должны были пройти совпадающий ACK и последующий LDP REQUEST — три сообщения до того, как сопоставление могло нести VCID.

Одна цепь, несколько локальных имён

В январе 2001 года семейство стандартов MPLS готовило ATM-коммутаторы к роли маршрутизаторов коммутации по меткам. Аппаратура уже пересылала ячейки по полям VPI и VCI, но обычно эти значения относились только к локальному участку канала. При переходе на следующий участок коммутатор мог заменить метки. Поэтому VPI/VCI, видимые соседу LDP, не обязательно давали устойчивое имя виртуальной цепи, которую двум узлам предстояло согласовать.

RFC 3038 добавил рядом с локальной меткой вторую идентичность — Virtual Connection Identifier, VCID. Существенное свойство: оба конца одной VC связывают с ней одинаковое значение. VCID не заменяет VPI/VCI в плоскости данных и не превращает локальную метку в глобальный номер для всей ATM-сети. Он позволяет соседним ATM-LSR связать собственные локальные входящие или исходящие метки с общей идентичностью и использовать её в информации LDP.

Последовательность событий принципиальна. RFC 3038 исходит из того, что VC уже установлена сигнализацией или средствами управления. Уведомление не создаёт ATM-соединение, а согласует, как его распознают два соседа. Только после этого следуют запрос и сопоставление LDP. Установка VC, локальная метка, её связь с VCID, распространение сопоставления и фактический трафик — разные факты. Ни один из них сам по себе не доказывает доставку данных приложению.

Почему ACK не завершал согласование

Для внутриполосной VC точка-точка узел upstream выбирал VCID и отправлял по новой цепи VCID PROPOSE с идентификатором сообщения. Оба конца связывали VCID со своими локальными метками. Узел downstream возвращал ACK с полученными VCID и идентификатором; upstream должен был сверить оба значения и повторить предложение, если ожидаемое подтверждение не пришло.

Затем upstream отправлял LDP REQUEST, содержащий идентификатор сообщения. Downstream считал этот запрос признаком того, что upstream получил ACK. RFC 3038 объясняет необходимость трёх сообщений ненадёжной передачей PROPOSE. Downstream может знать, что отправил подтверждение, но не может заключить, что оно дошло до другой стороны. Пока не пришёл REQUEST, он должен отбрасывать на VC любые пакеты, кроме самого VCID PROPOSE.

После завершения обмена LDP Mapping мог включать VCID в Label TLV. Это подтверждало связь в плоскости управления между соседями, но не успех приложения, не согласие каждого коммутатора на более длинном пути и не прохождение пользовательского трафика.

Процедура зависела от типа соединения

RFC 3038 не требовал одинакового уведомления для всех ATM-связей. Прозрачная прямая связь точка-точка с одинаковым VPI/VCI на обоих концах в уведомлении не нуждалась. Для виртуального пути можно было использовать внутриполосное уведомление или процедуру VPID; при единственном VP к соседу в ограниченном случае могло хватить общего VCI. Для постоянной виртуальной цепи применялась внутриполосная процедура. В переключаемой виртуальной цепи VCID можно было передать через достаточно широкое поле сигнализации, временно использовать меньшее поле либо отправить внутриполосное сообщение.

Имело значение и направление. Уведомление начинал конец upstream. Для двунаправленной VC требовалась отдельная процедура в каждом направлении, для однонаправленной — только в разрешённом. Следовательно, «та же цепь» не была глобальным именем, автоматически известным всей ATM-сети; это была связь, которую требовалось установить между соответствующими парами соседей.

Вариант с малым полем особенно ясно показывает разницу временной корреляции и долговременной связи. Пользовательское поле BLLI могло временно обозначать цепь во время сигнализации. Его нельзя было использовать повторно в другой незавершённой транзакции с тем же соседом; после завершения привязки VCID BLLI освобождался. В многоточечном случае BLLI был уникален на отправителе, но не обязательно на получателе, которому требовался также ATM-адрес отправителя. Ограниченный временный токен следовало освобождать лишь после проверяемого перехода состояния.

RFC 3038 также определил уведомление VPID для виртуального пути: из VPID и VCI можно было составить VCID без отдельного согласования каждой VC. Многоточечная процедура описывалась как будущее применение; документ отмечал, что действовавшая тогда спецификация LDP не поддерживала multicast. Коммутатор без VC-merge мог временно разделить активный LSP, чтобы отправить внутриполосное сообщение при добавлении нового листа, что потенциально влияло на производительность и QoS. Это ограничения, описанные стандартом, а не результаты измерений внедрения.

Историческую границу важно сохранить

RFC 3033, опубликованный в том же месяце, задавал типизированные идентификаторы сеансов и ресурсов для ATM-сигнализации. Это иной предмет, чем VCID в RFC 3038, который связывает локальные метки соседних узлов LDP после установки VC. Определения FEC из RFC 3036 и общая архитектура MPLS относятся к другим уровням. Объединение этих механизмов только потому, что все они используют «идентификаторы», смешало бы установку соединения, классификацию пакетов, пересылку на каждом переходе и доставку.

Сейчас RFC Editor обозначает RFC 3038 как Proposed Standard и указывает, что его обновляет RFC 7274. Последний касается назначения и вывода из употребления специальных меток MPLS и обновляет старое употребление термина «reserved label»; это не отменяет согласование VCID. Ни один из документов не называет развернутую реализацию, не считает внедрения и не приводит межоперационных испытаний. Обоснованный исторический вывод уже: если метка ATM могла быть локальной для перехода, управлению MPLS требовалась общая идентичность соседей, а стандарт делал такое согласие наблюдаемым через небольшой явный обмен сообщениями.

Источники

Эссе Heng Lu указаны только как аналитические рамки; Lu не писал RFC 3038 и не поддерживал его.