Инструменты OAM (Operations and Management — эксплуатация и управление) имеют важное значение для успеха развертывания всех сетей.
Требования OAM для сетей GMPLS описаны в документе [GMPLS-OAM]. Этот документ отмечает, что в протокольные решения для отдельных сетевых уровней следует включать механизмы для OAM или обеспечивать наследование функций OAM от физических сред уровней. Дальнейшее обсуждение этого вопроса выходит за пределы данного документа.
При работе OAM в MLN следует принимать во внимание вопрос обеспечения OAM для сквозных LSP, проходящих через границы уровней (которые могут быть также административными границами), и координации сообщений об ошибках и сигналов тревоги, детектируемых серверным уровнем, которые нужно передавать на клиентский уровень. Эти рабочие вопросы должны оставаться открытыми для сервис-провайдеров и разработчиков протоколов MLN, а также должны включать следующие функции:
В контексте и технологии высшего уровня в LSP (т. е., уровня технологии первого интервала маршрутизации) должна обеспечиваться возможность сквозного OAM для MLN LSP. Эта функция появляется на входном LSP как обычная функция OAM на базе LSP [GMPLS-OAM], но на границах уровней, в зависимости от метода, используемого для прохождения через нижележащий уровень, может потребоваться отображение операций OAM клиентского уровня на операции OAM серверного уровня. Большинство таких требований сильно зависит от средств OAM технологии плоскости данных на клиентском и серверном уровнях. Однако механизмы плоскости управления, используемые на клиентском уровне в соответствии с [GMPLS-OAM], должны отображаться и включать OAM на серверном уровне.
Работа OAM, включаемая в соответствии с [GMPLS-OAM] на клиентском уровне для LSP, должна выполняться на всей протяженности LSP. Это означает, что при пересечении LSP домена технологии нижележащего уровня, операции OAM клиентского уровня должны гладко соединяться внутри клиентского уровня на обоих концах LSP клиентского уровня.
Функции OAM на серверном уровне должны быть контролируемыми с клиентского уровня так, чтобы LSP серверного уровня, которые поддерживают LSP клиентского уровня, имели функции OAM, включаемые по запросу клиентского уровня. Такой контроль следует осуществлять в соответствии с правилами на границе уровня, когда автоматическое включение и запросы LSP на серверный уровень контролируются политикой.
Информация о состоянии, включающая сообщения об ошибках и сигналы тревоги, применимые к LSP серверного уровня, должны быть доступными на клиентском уровне. Эту информацию следует делать настраиваемой для автоматического уведомления клиентского уровня на границе уровня; кроме того, к этой информации следует применять политику, позволяющую серверному уровню фильтровать или скрывать часть информации, передаваемой на клиентский уровень. Более того, на клиентском уровне следует обеспечивать возможность фильтрации такой информации.
Отметим, что интерфейс между уровнями находится внутри узла сети и, следовательно, не обязательно соответствует спецификациям протоколов. Разработчики могут использовать стандартизованные методы (такие, как модули MIB) для доставки информации о состоянии (такой, как сообщения об ошибках и сигналы тревоги) между уровнями, но решение этих вопросов выходит за пределы данного документа.