Спецификация LDP, RSVPTE, GMPLS

12.1. RSVP-TE: расширение RSVP для LSP-туннелей

Введение

В описании архитектуры MPLS [2] протокол рассылки меток определен как набор процедур, с помощью которых один маршрутизатор LSR (Label Switched Router) информирует другие о значении меток, используемых для переадресации трафика между ними и через них. Архитектура MPLS не предполагает существования единственного протокола рассылки меток. Данная статья представляет собой спецификацию расширения протокола RSVP для формирования маршрутов (LSP) с коммутацией по меткам в MPLS-сетях (RFC-3209).

Несколько новых особенностей, описанных здесь, мотивировались требованиями управления трафиком в рамках MPLS (смотри [3]). В частности, расширенный протокол RSVP поддерживает реализацию явной прокладки LSP с или без резервирования ресурсов. Он также поддерживает плавное изменение маршрута LSP, установление приоритетов и обнаружение циклических путей.

LSP, сформированные RSVP, могут использоваться для транспортировки потоков трафика (Traffic Trunks), как это описано в [3]. Два LSP между отправителем и получателем могут образовывать единый поток трафика. Наоборот, несколько потоков трафика могли бы транспортироваться одним LSP, если бы, например, LSP могли предоставлять несколько классов услуг. Применимость этих расширений обсуждается в [10].

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

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

Предпосылки

ЭВМ и маршрутизаторы, которые поддерживают как RSVP [1], так и MPLS (MultiProtocol Label Switching) [2] могут ассоциировать метки с потоками RSVP. Когда комбинируются MPLS и RSVP, определение потока можно сделать более гибко. Когда маршрут с коммутацией по меткам (LSP) сформирован, трафик по этому пути определяется меткой, присвоенной ему входным узлом LSP. Установление соответствия между меткой и трафиком может быть выполнено с помощью нескольких различных критериев. Набор пакетов, которым присвоена определенным узлом одна и та же метка, относятся к одному классу переадресации FEC (forwarding equivalence class) ([2]) и эффективно определяет RSVP-поток. Когда трафик ассоциирован с маршрутом LSP, мы рассматриваем LSP как LSP-туннель. Когда метки ассоциированы с потоками трафика, для маршрутизатора становится возможным идентифицировать определенное состояние резервирования для пакета с помощью его метки.

Модель протокола управления использует рассылку меток по запросам из области внизу по течению. Запрос установления соответствия метки и определенного LSP-туннеля инициируется входным узлом с помощью сообщения RSVP Path. Для этой цели сообщение RSVP Path дополняется объектом LABEL_REQUEST. Метки формируются внизу по течению и рассылаются вверх с помощью сообщения RSVP Resv. Для этой цели сообщение RSVP Resv расширяется с помощью специального объекта LABEL.

Модель протокола управления поддерживает также возможность явной маршрутизации. Это осуществляется путем введения простого объекта EXPLICIT_ROUTE в сообщения RSVP Path. Объект EXPLICIT_ROUTE содержит в себе набор шагов, которые непосредственно характеризуют маршрут. Применяя этот объект, проходы, используемые RSVP-MPLS потоками, управляемыми метками, могут быть предопределены независимо от традиционной IP-маршрутизации. Явно сформированный маршрут может быть специфицирован административно или вычислен автоматически в соответствии с требованиями QoS и политики маршрутизации, принимая во внимание базовое состояние сети. Вообще, вычисление маршрута может управляться директивно или данными. Механизмы, процессы и алгоритмы, используемые для явного вычисления маршрутов, в данной статье не рассматриваются.

Одним полезным приложением явной маршрутизации является управление трафиком. Используя явно сформированные LSP, входной узел домена MPLS может управлять маршрутом, по которому проходит трафик сети MPLS. Явная маршрутизация может быть применена, чтобы оптимизировать использование сетевых ресурсов и улучшить рабочие характеристики сети, ориентированные на трафик.

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

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

Преимуществом использования RSVP для формирования LSP-туннелей является возможность выделения ресурсов вдоль всего маршрута. Например, полоса пропускания может быть выделена LSP-туннелю с привлечением стандартного RSVP-резервирование и классов интегрированных услуг [4].

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

Терминология

Абстрактный узел

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

LSP, маршрутизируемый явно

LSP, чей маршрут сформирован с помощью обычной IP-маршрутизации

Маршрут с коммутацией по меткам

Маршрут, сформированный путем объединения одного или более каналов с коммутацией по меткам, допускающий переадресацию пакетов одним MPLS-узлом другому. Подробности смотри в [2].

LSP

Маршрут с коммутацией по меткам (Label Switched Path)

LSP-туннель

LSP, который используется для туннелирования на уровне ниже, чем обычная IP-маршрутизация, и/или для реализации механизмов отбора

Туннель управления трафиком (TE Tunnel)

Набор из одного или более LSP-туннелей, которые транспортируют трафик

Транк для трафика

Набор потоков, объединенных в соответствии с их классом услуг и затем помещенных в LSP, или набор LSP, названный туннелем управления трафиком. Подробности смотри в [3]

Обзор. LSP туннели и туннели управления трафиком (TE)

Согласно [1], "RSVP определяет сессию, как поток данных с определенным местом назначения и протоколом транспортного уровня". Однако когда RSVP и MPLS используются совместно, поток или сессия могут быть определены с большей гибкостью и общностью. Входной узел LSP может задействовать разные средства, чтобы определить, каким пакетам следует присвоить определенную метку. После того как набору пакетов метка присвоена, она эффективно определяет поток через LSP. Мы называем такой LSP "LSP-туннелем", так как трафик через него непрозрачен для промежуточных узлов вдоль LSP.

Новые объекты RSVP SESSION, SENDER_TEMPLATE и FILTER_SPEC, названные LSP_TUNNEL_IPv4 и LSP_TUNNEL_IPv6, были определены для поддержки LSP-туннелей. В действительности, IPv4(v6), появляющейся в названии объекта, указывает только на то, что адрес места назначения является IPv4(v6) адресом.

В некоторых приложениях полезно ассоциировать наборы LSP-туннелей. Это может быть полезно при операциях изменения маршрута или при прокладке транка. В приложениях управления трафиком такой набор называется сформированным туннелем трафика (TE-туннелем). Чтобы сделать возможной идентификацию и ассоциацию таких LSP-туннелей, предусмотрены два идентификатора. ID-туннель является частью объекта SESSION. Объект SESSION однозначно определяет сформированный туннель трафика. Объекты SENDER_TEMPLATE и FILTER_SPEC содержат в себе LSP ID. Объект S ENDER_TEMPLATE (или FILTER_SPEC ) совместно с объектом SESSION однозначно идентифицируют LSP-туннель.

Работа LSP-туннелей

В данном разделе обобщаются некоторые возможности, поддерживаемые RSVP-ТЕ при работе с LSP туннелями. Сюда входит:

1. возможность формирования LSP-туннелей с требованиями QoS или без них;
2. возможность динамически изменять маршруты сформированных LSP-туннелей;
3. возможность отслеживать действительный маршрут, проходящий через сформированный LSP-туннель;
4. возможность идентифицировать и диагностировать LSP-туннели;
5. возможность устанавливать сформированный LSP-туннель под административный контроль; и
6. возможность осуществлять посылку запросов выделения меток, их рассылку и объединение.

Чтобы сформировать 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 в качестве средства проверки того, что имеется полоса при заданном приоритете вдоль всего пути, прежде чем перейти к более низкому уровню приоритета резервирования.

Когда присутствует объект 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 движется вверх по течению в направлении узла-отправителя, формируется маршрут с коммутацией по меткам.

Реализации должны поддерживать услугу контролируемой нагрузки (ControlledLoad service) [4] и нулевую услугу (Null Service) [16].

Стили резервирования

Узел получателя для каждой сессии может выбирать один из возможных стилей резервирования, а каждая сессия RSVP должна иметь определенный стиль. Отправители не имеют никакого влияния на выбор стиля резервирования. Получатель для разных LSP может выбирать различные стили резервирования. Сессия RSVP может вызывать формирование одного или более LSP, в зависимости от выбранного стиля резервирования.

Некоторые стили резервирования, такие, как FF, соответствуют определенным резервированиям в конкретном узле отправителя. Другие стили резервирования, такие, как WF и SE, могут реализовать совместно резервирования в нескольких узлах-отправителях. Более подробное обсуждение стилей резервирования можно найти в [12.1].

Стиль FF (фиксированный фильтр)

Стиль резервирования FF (Fixed Filter) формирует определенное резервирование для трафика каждого отправителя, которое не используется совместно другими отправителями. Этот стиль является типичным для приложений, в которых трафик от каждого отправителя существует одновременно и совершенно независимо. Общее значение зарезервированной полосы пропускания для сессий, применяющих FF, равно сумме резервирований для индивидуальных отправителей.

Так как каждый отправитель имеет свое собственное резервирование, для каждого из них формируется своя метка. Это может привести к формированию индивидуальных LSP туннелей для каждой пары отправитель-получатель.

Стиль WF (Wildcard Filter)

При стиле WF (Wildcard Filter) одно резервирование применяется совместно всеми отправителями сессии. Общее резервирование в канале остается неизменным вне зависимости от числа отправителей.

Один маршрут с коммутацией по меткам со схемой мультиточка-точка формируется для всех отправителей сессии. В каналах, используемых отправителями сессии одновременно, для сессии выделяется одна метка. Если имеется только один отправитель, LSP выглядит как обычное соединение точка-точка. Когда имеется несколько отправителей, формируется LSP со схемой мультиточка-точка (реверсированное дерево).

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

Кроме того, из-за правил объединения WF, объекты EXPLICIT_ROUTE не могут использоваться для резервирования WF.

Стиль SE (Shared Explicit)

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

Стиль резервирования SE может быть реализован при использовании схемы маршрутов с коммутацией по меткам мультиточка-точка или при отдельных LSP для каждого отправителя. LSP мультиточка-точка могут использоваться, когда сообщения path не содержат объект EXPLICIT_ROUTE или когда сообщения Path имеют идентичные объекты EXPLICIT_ROUTE. В любом из этих случаев может быть присвоена общая метка. Сообщения Path от различных отправителей могут содержать их собственные ERO, а пути, используемые отправителями, могут сходиться и расходиться в любой точке сети. Когда сообщения Path содержат разные объекты EXPLICIT_ROUTE, должны быть сформированы отдельные LSP для каждого объекта EXPLICIT_ROUTE.

Туннели управления переадресацией трафика

Одним из требований управления трафиком является возможность изменения маршрута сформированного TE-туннеля при определенных условиях, на основе административной политики. Например, в некоторых контекстах административная политика может требовать изменения маршрута TE-туннеля, когда оказывается доступен более "оптимальный" путь. Другим важным контекстом, когда TE-туннель должен быть заново маршрутизирован, является отказ в ресурсах для установленного TE-туннеля. При некоторых политиках может быть нужно возвратить TE-туннель к исходному маршруту, когда исчезнувший ресурс снова стал доступен.

Вообще, крайне желательно не нарушать трафик и избегать неблагоприятного воздействия на работу сети в процессе изменения маршрута TE-туннеля. Это адаптивное изменение маршрута требует формирования нового LSP-туннеля и перевода трафика из старого LSP-туннеля до его демонтажа. Эта концепция называется "сделай-прежде_чем-сломаешь". Может возникнуть проблема из-за того, что старый и новый LSP-туннели могут бороться друг с другом за ресурсы сетевых сегментов, которые они используют совместно. В зависимости от доступности ресурсов, эта конкуренция может привести к тому, что управление доступом запретит создание нового LSP туннеля. Преимущество использования RSVP для формирования LSP-туннелей заключается в том, что эта проблема решается достаточно элегантно.

Чтобы поддерживать такой режим работы, необходимо, чтобы в общих для старого и нового LSP-туннелей каналов ресурсы, используемые старым LSP-туннелем, не освобождались до того, как трафик переключится в новый LSP-туннель. Резервирования при этом не должны учитываться дважды, так как это может привести к тому, что управление доступом запретит формирование нового LSP-туннеля.

Аналогичная ситуация может возникнуть, когда нужно увеличить полосу TE-туннеля. Новое резервирование будет сделано по максимуму, но в действительности нужно только приращение между новой и старой полосой. Если в промежуточных узлах политика контролирует сообщения PATH, то сообщения PATH, запрашивающие слишком много полосы, будут отбрасываться. В этой ситуации в зависимости от местной политики простой запрос увеличения полосы без изменения SENDER_TEMPLATE может привести к обрыву туннеля. Комбинация объекта LSP_TUNNEL SESSION и стиля резервирования SE естественным образом подходит для плавного изменения полосы и маршрута. Идея заключается в том, чтобы старый и новый LSP-туннели совместно использовали ресурсы в каналах, где они работают. Объект LSP_TUNNEL SESSION используется, чтобы сузить рабочую область сессии RSVP, в частности, TE-туннеля. Чтобы однозначно идентифицировать TE-туннель, мы используем комбинацию IP адреса места назначения (адрес узла в конце туннеля), ID туннеля и IP адрес узла начала туннеля, которые помещаются в поле расширенного ID-туннеля.

Во время изменения маршрута или увеличения полосы пропускания входные узлы туннеля выступают в RSVP-сессии как два разных отправителя. Это достигается путем включения "LSP ID", который несет в себе объекты SENDER_TEMPLATE и FILTER_SPEC. Так как семантика этих объектов изменилась, им присваивается новые C-типы.

Чтобы осуществить изменение маршрута, входной узел выбирает новый LSP ID и формирует новый SENDER_TEMPLATE. Затем входной узел, чтобы определить новый путь, создает новый ERO. После этого узел посылает новое сообщение Path, используя исходный объект SESSION и новые SENDER_TEMPLATE и ERO. Он продолжает использовать старый LSP и обновляет старое сообщение Path. Для каналов, которые не являются общими, новое сообщение Path обрабатывается как обычное конфигурирование нового LSP-туннеля. Для каналов, которые являются общими, объект SESSION и стиль SE позволяют сформировать LSP, разделяющий ресурсы со старым LSP. Как только входной узел получает сообщение Resv для нового LSP, он может передавать по нему трафик и аннулировать старый LSP.

Чтобы увеличить полосы, может использоваться новое сообщение Path с новым LSP_ID. Делается попытка осуществить резервирование большей полосы при сохранении резервирования для текущего LSP_ID так, чтобы при неудаче большего резервирования старое резервирование осталось в силе.

MTU пути

Стандарт RSVP [12.1] и Int-Serv [12.11] предоставляют отправителю RSVP минимальное значение MTU, доступное между отправителем и получателем. Эта возможность определения MTU пути предоставляется также и для LSP, созданных посредством RSVP.

Информация о MTU пути содержится в объектах Integrated Services или Null Service (в зависимости оттого, что имеется в наличии). Когда используются объекты Integrated Services, MTU пути получается на основе процедур, описанных в [12.11]. Определение MTU пути в случае использования объектов Null Service рассмотрено в [12.16].

В случае стандарта RSVP информация о MTU пути используется отправителем, чтобы проверить, какие IP-пакеты имеют размер больше MTU. Пакеты, которые превосходят MTU, отправитель фрагментирует либо, когда IP-дейтограмма имеет установленный бит "Don't Fragment", отправляет ICMP-сообщение о недостижимости адресата. Такое обслуживание MTU необходимо для LSP, установленных посредством RSVP.

Следующий алгоритм применяется ко всем непомеченным IP дейтограммам и к любым помеченным пакетам, которые узел считает IP-дейтограммами, подлежащими пометке до их переадресации. Для помеченных пакетов ищется дно стека и просматривается IP-заголовок.

Используя терминологию, определенную в [12.5], LSR должен выполнить следующий алгоритм.

1. Пусть N равно числу байт в стеке меток (т.e, числу рекордов в стеке, умноженному на 4), включая метки, добавляемые в данном узле.
2. Пусть M меньше чем максимальный исходный размер помеченной IP дейтограммы или (MTU пути — N ).

Когда размер дейтограммы IPv4 (без меток) превосходит значение M, если бит DF в IPv4 заголовке не установлен, тогда

• дейтограмма должна быть фрагментирована, размер каждого фрагмента должен быть не больше чем M, и
• каждый фрагмент должен быть помечен и затем переадресован.

Если в IPv4-заголовке установлен бит DF, тогда

• дейтограмма не должна переадресовываться;
• формируется сообщение ICMP о недостижимости адресата:
  • его поле Code устанавливается [12] равным "Fragmentation Required and DF Set",
  • поле MTU следующего шага устанавливается[13] равным M.
• Если возможно, посылается отправителю ICMP сообщение о недостижимости адресата для отброшенной дейтограммы.

Когда размер дейтограммы IPv6 (без меток) превышает значение M,

• дейтограмма не должна переадресоваться;
• формируется ICMP-пакет сообщение слишком велико со значением MTU следующего шага [14], равным M ;
• если возможно, посылается ICMP-пакет, уведомляющий отправителя отвергнутой дейтограммы, что сообщение слишком велико.

Форматы сообщений, связанные с LSP туннелями

Пять новых объектов определено в данном разделе:

Новые C-типы присваиваются также объектам SESSION, SENDER_TEMPLATE и FILTER_SPEC.

Подробные описания новых объектов представлены в последующих разделах. Все новые объекты являются с точки зрения RSVP опционными. Реализация может выбрать поддержку некоторого субнабора объектов. Однако объекты LABEL_REQUEST и LABEL в рамках данного документа являются обязательными.

Объекты LABEL и RECORD_ROUTE являются специфическими для отправителя. В сообщениях Resv они должны появляться после FILTER_SPEC и до любой последующей спецификации FILTER_SPEC.

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

Сообщение Path

Сообщение Path имеет следующий формат:

<Сообщение Path> ::=  <Common Header> [ <INTEGRITY> ]
              <SESSION> <RSVP_HOP>
              <TIME_VALUES>
              [ <EXPLICIT_ROUTE> ]
              <LABEL_REQUEST>
              [ <SESSION_ATTRIBUTE> ]
              [ <POLICY_DATA> ... ]
              <sender descriptor>

<дескриптор         <SENDER_TEMPLATE> <SENDER_TSPEC>
отправителя> ::=   
              [ <ADSPEC> ]
              [ <RECORD_ROUTE> ]

Сообщение Resv

Сообщение Resv имеет следующий формат:

<Сообщение Resv> ::=   <Common Header> [ <INTEGRITY> ]
              <SESSION> <RSVP_HOP>
              <TIME_VALUES>
              [ <RESV_CONFIRM> ] [ <SCOPE> ]
              [ <POLICY_DATA> ... ]
              <STYLE> <flow descriptor list>
<список дескрипторов потока>::=  <FF flow descriptor list>
                    | <SE flow descriptor>
<список дескрипторов потока FF>::=  <FLOWSPEC> <FILTER_SPEC>
                      <LABEL> [ <RECORD_ROUTE> ]
                      | <FF flow descriptor list>
                      <FF flow descriptor>
<дескриптор потока FF>::=  [ <FLOWSPEC> ] 
                <FILTER_SPEC> <LABEL>
                [ <RECORD_ROUTE> ]
<дескриптор потока SE>::=  <FLOWSPEC> <SE filter spec list>
                <SE filter spec list> ::= <SE filter spec>
                | <SE filter spec list> <SE filter spec>
<спецификация фильтра SE>::=  <FILTER_SPEC> <LABEL> 
                  [ <RECORD_ROUTE> ]

Заметьте: LABEL и RECORD_ROUTE (если имеется), являются связанными с предыдущей спецификацией FILTER_SPEC. За каждой спецификацией FILTER_SPEC может следовать не более одного LABEL и/или RECORD_ROUTE.

Объекты, связанные с LSP-туннелем. Объект Label

Метки могут транспортироваться сообщениями Resv. В стилях FF и SE метка присваивается для каждого отправителя. За меткой отправителя в сообщении Resv должна непосредственно следовать FILTER_SPEC. Объект LABEL имеет следующий формат:

Класс LABEL = 16, C_Type = 1

Содержимое LABEL занимает 4 октета. Каждая метка MPLS является целым числом без знака в диапазоне от 0 до 1048575. Метки MPLS и FR представляют собой 4-х октетные коды, выровненные по правым разрядам. Метки ATM кодируются в битах 0-15 поля VPI, выровненными справа, и в битах 16-31 поля VCI.

Обработка объектов Label в сообщениях Resv

Узел в MPLS может поддерживать большое пространство меток, пространства меток для разных интерфейсов не перекрываются. В последующем обсуждении термин "та же метка" означает идентичность значений меток из общего пространства меток. Все последующие рассмотрения касаются уникастных сессий.

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

Внизу по течению

Узел, размещенный внизу по течению, выбирает метку, которая будет представлять поток. Если в запросе специфицирован диапазон меток, метка должна лежать в этом диапазоне. Если свободных меток нет, узел посылает сообщение PathErr с кодом ошибки routing problem (проблема маршрутизации) и значением ошибки label allocation failure (отказ выделения метки).

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

В случае ATM применимо дополнительное условие. Некоторые ATM-узлы не способны объединять потоки. Эти узлы могут уведомлять об этом путем установления бита запроса метки равным нулю. M-бит в объекте LABEL_REQUEST C-тип 2 запроса метки в диапазоне меток ATM служит именно этой цели. M-бит должен быть установлен узлами, которые способны объединять потоки. Если для нескольких отправителей бит M не установлен, узел внизу по течению должен этим отправителям присвоить уникальные метки.

Когда метка присвоена, узел формирует новый объект LABEL и посылает его в качестве части сообщения Resv предшествующему узлу. Узел должен быть готов переадресовывать пакеты, содержащие присвоенные метки, до посылки сообщения Resv. Объект LABEL должен содержаться в блоке состояния резервирования.

Ожидается, что узел пошлет сообщение Resv, прежде чем перезапустит свой таймер, если содержимое объекта LABEL изменяется.

Вверху по течению

Узел применяет метку, содержащуюся в объекте LABEL, как выходную метку, ассоциированную с отправителем. Маршрутизатор присваивает новую метку и связывает ее с входным интерфейсом этой сессии/отправителя. Это тот же интерфейс, который маршрутизатор использует для переадресации сообщений Resv предшествующим узлам.

Несколько условий могут сделать метку неприемлемой.

1. Узел является коммутатором ATM, неспособным объединять потоки, но узел ниже по течению присвоил идентичные метки двум отправителям.
2. Присвоена метка нуль, но узел неспособен выполнить предпоследнее извлечение из стека для соответствующего L3PID
3. Присвоенная метка находится вне запрошенного диапазона меток.

В любом из этих случаев узел посылает сообщение ResvErr с кодом ошибки проблема маршрутизации и значением ошибки неприемлемое значение метки.

Отсутствие поддержки объекта Label

При нормальных обстоятельствах узел не должен получать объект LABEL в сообщении Resv, если только оно не содержит объект LABEL_REQUEST в соответствующем сообщении Path. Однако, маршрутизатор RSVP, который не распознает объект LABEL, посылает получателю ResvErr с кодом ошибки Unknown object class (неизвестный класс объекта), что приводит к аннулированию резервирования.

Объект запроса метки

Класс запроса метки равен 19. В настоящее время существует три возможных значения C_Types. Тип 1 относится к запросам метки без диапазона значений. Тип 2 является запросом метки с диапазоном ATM. Тип 3 является запросом метки с диапазоном Frame Relay. Объект LABEL_REQUEST имеет форматы, показанные ниже на рис. 12.33.

Запрос метки без указания диапазона

Класс = 19, C_Type = 1

Рис. 12.33.

Запрос метки с диапазоном ATM

Класс = 19, C_Type = 2

Запрос метки с диапазоном Frame Relay

Класс = 19, C_Type = 3

Рис. 12.35.

Len         DLCI [бит]
        0                   10
        2                   23

Обработка LABEL_REQUEST

Чтобы сформировать LSP-туннель, отправитель посылает сообщение Path с объектом LABEL_REQUEST. Объект LABEL_REQUEST указывает, что запрашивается подключение метки к данному пути, и определяется сетевой протокол, который используется на этом пути. Это позволяет в LSP применять сетевые протоколы не-IP типа. Данная информация может быть также полезной при выделении метки, так как некоторые зарезервированные метки являются протокольно зависимыми [5].

LABEL_REQUEST должен быть записан в блоке состояния прохода, так что сообщения обновления Path будут также содержать объект LABEL_REQUEST. Когда сообщение Path приходит к получателю, присутствие объекта LABEL_REQUEST заставляет получателя присвоить метку и поместить ее в объект LABEL соответствующего сообщения Resv. Если был специфицирован диапазон меток, метка должна быть взята из данного диапазона. Получатель, который воспринимает объект LABEL_REQUEST, должен включать объект LABEL в сообщения Resv, сопряженные с сообщением Path. Если объект LABEL_REQUEST в сообщении Path отсутствовал, узел не должен включать объект LABEL в сообщение Resv, для сопряженной с сообщением Path сессии и PHOP.

Узел, который посылает объект LABEL_REQUEST, должен быть готов воспринять и корректно обработать объект LABEL в соответствующих сообщениях Resv.

Узел, который распознает объект LABEL_REQUEST, но не может его поддержать (возможно, из-за невозможности присвоить метку), должен послать PathErr с кодом ошибки Routing problem (проблема маршрутизации) и значением ошибки MPLS label allocation failure (отказ присвоения метки MPLS). Это включает в себя случай, когда специфицирован диапазон меток, а метка не может быть из этого диапазона выделена. Узел, который получает и переадресует сообщение Path с объектом LABEL_REQUEST, должен скопировать L3PID из полученного объекта LABEL_REQUEST в переадресуемый объект LABEL_REQUEST.

Если получатель не поддерживает протокол L3PID, ему следует послать PathErr с кодом ошибки Routing problem и значением ошибки Unsupported L3PID. Это вызовет прерывание сессии RSVP.

Отсутствие поддержки объекта запроса метки

Маршрутизатор RSVP, который не распознал объект LABEL_REQUEST, посылает отправителю PathErr с кодом ошибки Unknown object class. Маршрутизатор RSVP, который распознал объект LABEL_REQUEST, но не распознал C_Type, посылает отправителю PathErr с кодом ошибки Unknown object C_Type. Это приводит к прерыванию формирования маршрута. Отправитель должен уведомить руководство, что LSP не может быть установлен, и, возможно, предпринять действия по резервированию без LABEL_REQUEST.

RSVP сконструирован для успешной работы с маршрутизаторами, которые не поддерживают RSVP, размещенными на пути от отправителя к получателю. Однако, очевидно, маршрутизаторы без RSVP не могут транспортировать метки через RSVP. Это означает, что, если маршрутизатор имеет соседа без поддержки RSVP, он не должен анонсировать объект LABEL_REQUEST, посылая сообщения, которые проходят через маршрутизаторы без поддержки RSVP. Маршрутизатор должен послать отправителю PathErr с кодом ошибки Routing problem и значением ошибки MPLS being negotiated, but a nonRSVP capable router stands in the path (оговорен протокол MPLS, но на пути стоит маршрутизатор без поддержки RSVP). То же самое сообщение следует послать, если маршрутизатор получает объект LABEL_REQUEST в сообщении от маршрутизатора без поддержки RSVP. О том, как маршрутизатор ниже по течению может обнаружить маршрутизатор без поддержки RSVP, смотри в [1].

Объект Explicit Route

Явные маршруты (Explicit Route) специфицируются с помощью объекта EXPLICIT_ROUTE (ERO). Класс явных маршрутов имеет код 20. В настоящее время определен один C_Type = 1 — явный маршрут. Объект EXPLICIT_ROUTE имеет следующий формат:

Класс = 20, C_Type = 1

Содержимое объекта EXPLICIT_ROUTE представляет собой последовательность информационных записей переменной длины, называемых субобъектами.

Если сообщение Path содержит несколько объектов EXPLICIT_ROUTE, только первый объект имеет смысл. Последующие объекты EXPLICIT_ROUTE могут игнорироваться и не должны пересылаться далее.

Применимость

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

Объект EXPLICIT_ROUTE следует использовать, только когда все маршрутизаторы вдоль явного маршрута поддерживают RSVP и объект EXPLICIT_ROUTE. Объекту EXPLICIT_ROUTE присвоено значение класса в формате 0bbbbbbb. Маршрутизаторы RSVP, которые не поддерживают этот объект, будут откликаться сигналом ошибки Unknown Object Class.

Семантика объекта Explicit Route

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

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

Явный маршрут описывается последовательностью субобъектов, содержащихся в объекте EXPLICIT_ROUTE. Каждый субобъект идентифицирует группу узлов явного маршрута.

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

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

Субобъекты

Содержимое объекта EXPLICIT_ROUTE представляет собой последовательность записей переменной длины, называемых субобъектами. Каждый субобъект имеет формат, представленный ниже (рис. 12.36):

Рис. 12.36.

1  IPv4 префикс
2  IPv6 префикс 
32 номер автономной системы

Строгие и свободные субобъекты

Бит L в субобъекте является однобитовым атрибутом. Если бит L =1, тогда значение атрибута соответствует значению 'свободный'. В противном случае, значение атрибута является 'строгим'. Для краткости, будем говорить, что, если значение атрибута субобъекта 'свободный', тогда это 'свободный субобъект'. В противном случае, это 'строгий субобъект'. Более того, мы говорим, что абстрактный узел строгого или свободного субобъекта является строгим или свободным узлом, соответственно.

Рис. 12.37.

Субобъект 1. IPv4 префикс

Содержимым префикса IPv4 субобъекта является 4-октета IPv4 адреса, 1-октет длины префикса и 1-октет заполнителя. Абстрактный узел, представляемый этим субобъектом, является набором узлов, которые имеют IP адрес в пределах этого префикса. Заметим, что длина префикса 32 указывает на один узел IPv4.

Рис. 12.38.

Субобъект 2. IPv6 префикс

Содержимым префикса IPv6 субобъекта является 16-октетный IPv6-адрес, 1-октет префикса длины и 1-октета заполнителя. Абстрактный узел, представляемый этим субобъектом, является набором узлов, которые имеют IP адреса в пределах этого префикса. Заметим, что длина префикса 128 указывает на один узел IPv6.

Субобъект 32: Номер автономной системы

Содержимым субобъекта номера автономной системы (AS) являются два октета номера AS. Абстрактный узел, представленный субобъектом, является набором узлов, принадлежащих автономной системе.

Обработка объекта Explicit Route. Выбор следующего шага

Узел, который получает сообщение Path, содержащее объект EXPLICIT_ROUTE, должен определить следующий шаг пути. Это необходимо из-за того, что следующий абстрактный узел вдоль явного маршрута может быть субсетью IP или автономной системой. Следовательно, выбор этого следующего шага может включать в себя выбор одной из возможных альтернатив. Критерии, используемые, чтобы выполнить выбор, зависят от конкретной реализации и могут зависеть от локальной политики. Однако предполагается, что каждый узел сделает все возможное, чтобы исключить кольцевые маршруты. Заметим, что так определенные пути могут быть отвергнуты локальной политикой. Чтобы определить следующий шаг пути, узел выполняет следующие операции.

1. Узел, получив сообщение RSVP, должен определить первый субобъект. Если узел не является частью абстрактного узла, описанного первым субобъектом, он получил сообщение с ошибкой и должен прислать сигнал ошибки Bad initial subobject. Если первого субобъекта вообще нет, сообщение ошибочно и система должна прислать сигнал ошибки Bad EXPLICIT_ROUTE object.
2. Если нет второго субобъекта, это указывает на конец явного маршрута. Объект EXPLICIT_ROUTE должен быть удален из сообщения Path. Этот узел может быть или не быть концом пути.
3. Далее, узел определяет второй субобъект. Если узел является частью абстрактного узла, описанного во втором субобъекте, тогда узел удаляет первый субобъект и продолжает обработку с пункта 2. Заметим, что это делает второй субобъект первым в следующей итерации и позволяет узлу идентифицировать следующий абстрактный узел пути после возможного повторения шагов 2 и 3.
4. Абстрактный пограничный узел. Узел определяет, является ли он топологически смежным с абстрактным узлом, описанным во втором субобъекте. Если это так, узел выбирает конкретный следующий шаг, адресатом которого является один из членов абстрактного узла.
5. Случай внутреннего абстрактного узла: В противном случае узел выбирает следующий шаг в пределах абстрактного узла первого субобъекта (к которому данный узел принадлежит), то есть вдоль пути к абстрактному узлу второго субобъекта (который является следующим абстрактным узлом). Если такого пути нет, тогда возможны два варианта:
   • если второй субобъект является жестким, имеет место ошибка и узел должен прислать уведомление об ошибке Bad strict node;
   • в противном случае, если второй субобъект является свободным, узел выбирает любой следующий шаг вдоль пути к очередному абстрактному узлу. Если такого пути нет, имеет место ошибка, и узел должен прислать сигнал ошибки Bad loose node.
6. Наконец, узел заменяет первый субобъект любым субобъектом, который указывает на абстрактный узел, содержащий следующий шаг. Это необходимо для того, чтобы при получении следующим узлом явного маршрута, он был воспринят.

Добавление субобъектов в объект Explicit Route

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

В противном случае, если узел является членом абстрактного узла первого субобъекта, перед первым субобъектом может быть введена последовательность субобъектов или первый субобъект может быть заменен. Каждый субобъект в этой последовательности должен представлять абстрактный узел, который является субнабором текущего абстрактного узла.

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