Работа LSP-туннелей
В данном разделе обобщаются некоторые возможности, поддерживаемые RSVP-ТЕ при работе с LSP туннелями. Сюда входит:
- Возможность формирования LSP-туннелей с или без требований QoS.
- Возможность динамически изменять маршруты сформированных LSP туннелей.
- Возможность отслеживать действительный маршрут, проходящий через сформированный LSP туннель,
- Возможность идентифицировать и диагностировать LSP туннели.
- Возможность устанавливать сформированный LSP туннель под административный контроль и
- Возможность осуществлять посылку запросов выделения меток, их рассылку и объединение.
Чтобы сформировать LSP туннель, первый узел MPLS - то есть, узел-отправитель -- посылает сообщение RSVP Path с типом сессии LSP_TUNNEL_IPv4 или LSP_TUNNEL_IPv6 и вводит объект LABEL_REQUEST в сообщение Path. Объект LABEL_REQUEST указывает, что запрошена привязка метки к данному пути, а также указывает на протокол сетевого уровня, который используется для этого маршрута. Причиной этого является то, что нельзя сделать предположение о протоколе сетевого уровня, используемом в LSP, это не обязательно IP и нельзя это выяснить по заголовку уровня L2, который просто указывает на вышестоящий протокол - MPLS.
Если узел-отправитель знает, что маршрут с высокой вероятностью отвечает требованиям QoS туннеля, или что он эффективно использует сетевые ресурсы, или, что он удовлетворяет некоторым критериям политики, узел может решить использовать маршрут для некоторых или для всех его сессий. Чтобы сделать это, узел-отправитель добавляет объект EXPLICIT_ROUTE в сообщение RSVP Path. Объект EXPLICIT_ROUTE специфицирует маршрут в виде последовательности абстрактных узлов.
Если после того как сессия успешно установлена, узел-отправитель обнаружит лучший путь, отправитель может динамически изменить маршрут сессии простой заменой объекта EXPLICIT_ROUTE. Если возникли проблемы с объектом EXPLICIT_ROUTE, из-за циклов маршрута или из-за того, что некоторые промежуточные маршрутизаторы его не поддерживают, отправитель об этом уведомляется.
Добавив объект RECORD_ROUTE в сообщение Path, узел-отправитель может получить информацию о действительном маршруте, по которому проходит LSP туннель. Узел-отправитель может также использовать этот объект, чтобы запросить данные об изменении маршрута. Объект RECORD_ROUTE аналогичен вектору пути, и, следовательно, может использоваться для обнаружения циклов маршрута.
Наконец, объект SESSION_ATTRIBUTE может быть добавлен в сообщение Path, чтобы помочь диагностике и идентификации сессии. В этом объекте содержится также информация о конфигурации, приоритетах и ресурсах (смотри [3]).
Маршрутизаторы вдоль маршрута могут использовать конфигурацию и приоритеты совместно с SENDER_TSPEC и любыми объектами POLICY_DATA, содержащимися в сообщениях Path, в качестве входных данных для управления политикой. Например, в приложениях управления трафиком очень полезно использовать сообщение Path в качестве средства проверки того, что имеется полоса при заданном приоритете вдоль всего пути, прежде чем перейти к более низкому уровню приоритета резервирования. Если разрешено распространение сообщения Path при недостаточности ресурсов, тогда имеется опасность того, что резервирования низкого приоритета вниз по течению относительно данной точки будут заменены при бесполезной попытке обслужить этот запрос.
Когда присутствует объект EXPLICIT_ROUTE (ERO), сообщение Path переадресуется по месту назначения вдоль пути, указанного в ERO. Каждый узел вдоль пути записывает ERO в свой блок состояния пути. Узлы могут также модифицировать ERO до переадресации сообщения Path. В этом случае модифицированный ERO должен быть запомнен в блоке состояния пути в дополнение к полученному ERO.
Объект LABEL_REQUEST запрашивает промежуточные маршрутизаторы и узлы-получатели предоставить данные о метке для данной сессии. Если узел не способен предоставить такие данные, он посылает сообщение PathErr с кодом ошибки "unknown object class" (неизвестный класс объекта). Если объект LABEL_REQUEST на всем пути не поддерживается, узел-отправитель будет уведомлен первым узлом, который не может обеспечить такую поддержку.
Узел места назначения пути с коммутацией по меткам реагирует на LABEL_REQUEST путем включения объекта LABEL в свой отклик-сообщение RSVP Resv. Объект LABEL включается в список спецификации отбора, который следует непосредственно за основной спецификацией фильтра.
Сообщение Resv посылается назад вверх по течению в направлении отправителя, следуя состоянию пути, сформированному сообщением Path, в обратном порядке. Заметим, что если состояние пути было сформировано с использованием ERO, тогда в обратном направлении (согласно ERO) последует сообщение Resv.
Каждый узел, который получает сообщение Resv, содержащее объект LABEL, использует эту метку для исходящего трафика в соответствии с этим LSP туннелем. Если узел не является отправителем, он формирует новую метку и помещает ее в соответствующий объект LABEL сообщения Resv, которое посылается вверх по течению к PHOP. Метка, посланная вверх по течению в объекте LABEL, является меткой, которую данный узел будет использовать для идентификации входного трафика, сопряженного с этим LSP туннелем. Эта метка служит также в качестве характеристики спецификации отбора (Filter Spec). Узел может теперь обновить свою карту входных меток ILM (Incoming Label Map), которая используется для определения NHLFE (Next Hop Label Forwarding Entry), смотри [2]. Когда сообщение Resv движется вверх по течению в направлении узла-отправителя, формируется маршрут с коммутацией по меткам.