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