Кратко

  • RFC 3186 заменял на входе один или два октета PPP/POS-кадра адресом MAPOS, пересылал кадр по общей сети и восстанавливал исходные значения на выходе.
  • Реальный путь зависел от двух портов, свободной пары адресов, устойчивой пересылки в обоих направлениях и изоляции. База OAM описывала путь, но не пересылала данные.

Документ вышел в декабре 2001 года как Informational. В примечании IESG сказано, что он не был продуктом рабочей группы и не относился к Standards Track, поэтому не обязательно прошёл столь же широкое рассмотрение. Его схема и испытание — ограниченные исторические свидетельства.

Механизм использовал сходство форматов. PPP over SONET/SDH начинался фиксированными значениями, а MAPOS размещал там внутренний адрес назначения. Входной коммутатор подставлял адрес удалённого порта, сеть пересылала кадр, выходной коммутатор возвращал значения PPP.

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

Переход в режим туннеля состоял из нескольких действий. На клиентском порту отключались NSP и SSP, broadcast и multicast MAPOS, менялась C2 и включалась перезапись. Возврат к MAPOS выполнялся в обратном порядке. Одно поле режима не могло подтвердить каждую стадию.

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

Пара адресов идентифицировала управляемое намерение. Она не доказывала совпадение режимов, двустороннюю достижимость или доставку кадра.

RFC предлагал path database для OAM&P и предотвращения дубликатов. В примере были пользователь, скорость, режим, пара и статус. Однако база прямо не участвовала в forwarding.

Строка “Up and running” была административным утверждением. Исполняли SSP, порты и перезапись. База могла отставать от изменений, а правильная строка не гарантировала следующую доставку.

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

Отказ был виден по-разному. Разрыв рядом с CPE вызывал местную SONET/SDH-аварию. Дальний физический порт оставался поднятым, потому что оптический путь завершался на границе. После истечения LCP Echo он показывал “link up, line protocol down”.

Timeout подтверждал лишь отсутствие ответа в срок. Он не локализовал разрыв, не отличал одностороннюю потерю и не описывал приложение. Внутренний SSP мог менять топологию, пока клиент видел только конечный симптом.

Вид частной линии не означал выделенную ёмкость. В MAPOS не было протокольного QoS, в POS — flow control. RFC называл гарантию throughput трудной и требовал достаточной межкоммутаторной полосы и справедливости по портам.

Испытание задержки имело узкие условия: указанное оборудование, односторонняя OC12c-нагрузка 30%, фиксированные параметры, 25 запусков по 150 секунд. Тестовый коммутатор оказался быстрее сравниваемого маршрутизатора. Это не вывод для всех нагрузок, потерь и производителей.

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

В кадре MAPOS отсутствовал адрес источника. В смешанной среде это усложняло принадлежность кадра. Невидимость внутреннего устройства для клиента не доказывала внутреннюю безопасность.

RFC 3186 показывает цену удобной абстракции. За простой линией нужны отдельные записи: заказ, пара адресов, порты, стадии перехода, сходимость по направлениям, версия базы, изоляция, аварии, LCP Echo и наблюдение кадра. Ни один зелёный статус не должен подменять эту историю.