2004 г.
4.4.24. RSVP-TE: расширение RSVP для LSP-туннелей
Семёнов Ю.А. (ГНЦ ИТЭФ),
book.itep.ru
D. Awduche, RFC-3209, декабрь 2001
1. Введение
В разделе 2.9 описания архитектуры MPLS [2] протокол рассылки меток определен как набор процедур, с помощью которых один маршрутизатор LSR (Label Switched Router) информирует другие о значении меток, используемых для переадресации трафика между ними и через них. Архитектура MPLS не предполагает существования единственного протокола рассылки меток. Данная статья представляет собой спецификацию расширения протокола RSVP для формирования маршрутов (LSP) с коммутацией по меткам в MPLS-сетях.
Несколько новых особенностей, описанных здесь, мотивировались требованиями управления трафиком в рамках MPLS (смотри [3]). В частности, расширенный протокол RSVP поддерживает реализацию явной прокладки LSP, с или без резервирования ресурсов. Он также поддерживает плавное изменение маршрута LSP, установление приоритетов и обнаружение циклических путей.
LSP, сформированные RSVP, могут использоваться для транспортировки потоков трафика ("Traffic Trunks"), как это описано в [3]. Два LSP между отправителем и получателем могут образовывать единый поток трафика. Наоборот несколько потоков трафика могут транспортироваться одним LSP, если бы, например, LSP могли предоставлять несколько классов услуг. Применимость этих расширений обсуждается в [10].
Так как трафик, который проходит по маршруту с коммутацией меток, определен меткой, заданной входным узлом LSP, эти маршруты могут рассматриваться как туннели, обеспечивающие связь между обычной IP-маршрутизацией и механизмами отбора (фильтрации). Когда LSP используется так, мы называем их LSP-туннелями.
LSP-туннели допускают реализацию различных политик оптимизации работы сети. Например, LSP-туннели могут обходить автоматически или вручную точки отказов в сети, области перегрузок или узкие места. Более того, несколько параллельных LSP-туннелей могут быть проложено между двумя узлами, и трафик между этими узлами может быть направлен через эти LSP-туннели согласно местной политике маршрутизации. Хотя предполагается, что управление трафиком (то есть, оптимизация рабочих характеристик сети) является важным приложением этой спецификации, расширенный протокол RSVP может быть использован в более широком контексте.
Целью данной статьи является описание использования RSVP для формирования LSP-туннелей. Предполагается полностью описать все объекты, форматы пакетов и процедуры, необходимые для реализации совместимых реализаций. Определено несколько объектов, которые улучшают управление и диагностику LSP-туннелей. В статье обсуждаются также средства быстрого детектирования отказа узлов посредством нового сообщения HELLO.
Все объекты и сообщения, обсуждаемые в данной статье, являются опционными по отношению RSVP. В данной статье обсуждается ситуация, когда определенный объект не поддерживается конкретным узлом.
1.1. Предпосылки
ЭВМ и маршрутизаторы, которые поддерживают как RSVP [1], так и MPLS (Multi-Protocol 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 без резервирования могут использоваться, например, при реализации наилучшего возможного трафика. Они могут также использоваться во многих других контекстах, включая восстановление системы после отказа и т.д.
1.2. Терминология
Абстрактный узел | Группа узлов, чья исходная топология неизвестна входному узлу LSP. Абстрактный узел называется простым, если он содержит только один физический узел |
LSP, маршрутизируемый явно | LSP, чей маршрут сформирован с помощью обычной IP-маршрутизации |
Маршрут с коммутацией по меткам | Маршрут, сформированный путем объединения одного или более каналов с коммутацией по меткам, допускающий переадресацию пакетов одним MPLS-узлом другому такому узлу. Подробности смотри в [2]. |
LSP | Маршрут с коммутацией по меткам (Label Switched Path) |
LSP-туннель | LSP, который используется для туннелирования на уровне ниже чем обычная IP-маршрутизация и/или для реализации механизмов отбора |
Туннель управления трафиком (TE Tunnel) | Набор из одного или более LSP-туннелей, которые транспортируют трафик |
Транк для трафика | Набор потоков, объединенных в соответствии с их классом услуг и затем помещенных в LSP или набор LSP, названный туннель управления трафиком. Подробности смотри в [3]. |
2. Обзор
2.1. 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. Объект SENDER_TEMPLATE (или FILTER_SPEC) совместно с объектом SESSION однозначно идентифицируют LSP туннель.
2.2. Работа 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 движется вверх по течению в направлении узла-отправителя, формируется маршрут с коммутацией по меткам.
2.3. Классы услуг
Данная статья не определяет типа запросов интегрированных услуг, однако реализации должны поддерживать услугу контролируемой нагрузки (Controlled-Load service) [4] и нулевую услугу (Null Service) [16].
2.4. Стили резервирования
Узел получателя для каждой сессии может выбирать один из возможных стилей резервирования, а каждая сессия RSVP должна иметь определенный стиль. Отправители не имеют никакого влияния на выбор стиля резервирования. Получатель для разных LSP может выбирать различные стили резервирования. Сессия RSVP может вызывать формирование одного или более LSP, в зависимости от выбранного стиля резервирования.
Некоторые стили резервирования, такие как FF, соответствуют определенным резервированиям в конкретном узле отправителя. Другие стили резервирования, такие как WF и SE, могут реализовать совместно резервирования в нескольких узлах отправителях. Более подробное обсуждение стилей резервирования можно найти в [1].
2.4.1. Стиль FF (фиксированный фильтр)
Стиль резервирования FF (Fixed Filter) формирует определенное резервирование для трафика каждого отправителя, которое не используется совместно другими отправителями. Этот стиль является типичным для приложений, в которых трафик от каждого отправителя существует одновременно и совершенно независимо. Общее значение зарезервированной полосы пропускания для сессий, использующих FF, равно сумме резервирований для индивидуальных отправителей.
Так как каждый отправитель имеет свое собственное резервирование, для каждого из них формируется своя метка. Это может привести к формированию индивидуальных LSP туннелей для каждой пары отправитель - получатель.
2.4.2. Стиль WF (Wildcard Filter)
При стиле резервирования WF (Wildcard Filter), одно резервирование используется совместно всеми отправителями сессии. Общее резервирование в канале остается неизменным вне зависимости от числа отправителей.
Один маршрут с коммутацией по меткам со схемой мультиточка-точка формируется для всех отправителей сессии. В каналах, используемых отправителями сессии одновременно, для сессии выделяется одна метка. Если имеется только один отправитель, LSP выглядит как обычное соединение точка-точка. Когда имеется несколько отправителей, формируется LSP со схемой мультиточка-точка (реверсированное дерево).
Этот стиль полезен для приложений, в которых не все отправители передают трафик одновременно. Телефонная конференция, например, является приложением, где не все участники говорят одновременно. Если, однако, все отправители осуществляют передачу одновременно, тогда нет возможности выполнить резервирование корректно. Либо зарезервированная полоса в канале вблизи места назначения окажется меньше требуемой, либо зарезервированная полоса канала вблизи некоторых отправителей окажется больше требуемой. Это ограничивает возможность использования WF для целей управления трафиком.
Кроме того, из-за правил объединения WF, объекты EXPLICIT_ROUTE не могут использоваться для резервирования WF.
2.4.3. Стиль SE (Shared Explicit)
Стиль SE позволяет получателю специфицировать явно список отправителей, которые должны быть включены в резервирование. Существует одно резервирование для всех отправителей, включенных в список. Так как каждый отправитель указан явно в сообщении Resv, разным отправителям могут быть присвоены различные метки, что приводит к формированию независимых LSP.
Стиль резервирования SE может быть реализован при использовании схемы маршрутов с коммутацией по меткам мультиточка-точка или при отдельных LSP для каждого отправителя. LSP мультиточка-точка могут использоваться, когда сообщения path не содержат объект EXPLICIT_ROUTE, или когда сообщения Path имеют идентичные объекты EXPLICIT_ROUTE. В любом из этих случаев может быть присвоена общая метка. Сообщения Path от различных отправителей могут содержать их собственные ERO, а пути, используемые отправителями, могут сходиться и расходиться в любой точке сети. Когда сообщения Path содержат разные объекты EXPLICIT_ROUTE, должны быть сформированы отдельные LSP для каждого объекта EXPLICIT_ROUTE.
2.5. Туннели управления переадресацией трафика
Одним из требований управления трафиком является возможность изменения маршрута сформированного 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, так чтобы при неудаче большего резервирования старое резервирование осталось в силе.
2.6. MTU пути
Стандарт RSVP [1] и Int-Serv [11] предоставляют отправителю RSVP минимальное значение MTU доступное между отправителем и получателем. Эта возможность определения MTU пути предоставляется также и для LSP, созданных посредством RSVP.
Информация о MTU пути содержится в объектах Integrated Services или Null Service (в зависимости оттого, что имеется в наличии). Когда используются объекты Integrated Services, MTU пути поучается на основе процедур, описанных в [11]. Определение MTU пути в случае использования объектов Null Service рассмотрено в [16].
В случае стандарта RSVP, информация о MTU пути используется отправителем, чтобы проверить, какие IP-пакеты имеют размер больше MTU. Пакеты, которые превосходят MTU, отправитель фрагментирует, либо, когда IP-дейтограмма имеет установленный бит "Don't Fragment", отправляет ICMP-сообщение о недостижимости адресата. Такое обслуживание MTU необходимо для LSP, установленных посредством RSVP.
Следующий алгоритм применяется ко всем непомеченным IP дейтограммам и к любым помеченным пакетам, которые узел считает IP-дейтограммами, подлежащими пометке до их переадресации. Для помеченных пакетов ищется дно стека и просматривается IP-заголовок.
Используя терминологию, определенную в [5], LSR должен выполнить следующий алгоритм:
- Пусть N равно числу байт в стеке меток (т.e, числу рекордов в стеке, умноженному на 4), включая метки, добавляемые в данном узле.
- Пусть M меньше чем максимальный исходный размер помеченной IP дейтограммы или (MTU пути - N).
Когда размер дейтограммы IPv4 (без меток) превосходит значение M, если бит DF в IPv4 заголовке не установлен, тогда
(a) Дейтограмма должна быть фрагментирована, размер каждого фрагмента должен быть не больше чем M, и
(b) каждый фрагмент должен быть помечен и затем переадресован.
Если в IPv4-заголовке установлен бит DF, тогда
(a) дейтограмма не должна переадресовываться
(b) Формируется сообщение ICMP о недостижимости адресата:
i. устанавливается его поле Code [12] равным "Fragmentation Required and DF Set",
ii. устанавливается поле MTU следующего шага [13] равным M
(c) Если возможно, посылается отправителю ICMP сообщение о недостижимости адресата для отброшенной дейтограммы.
Когда размер дейтограммы IPv6 (без меток) превышает значение M,
(a) дейтограмма не должна переадресоваться
(b) Формируется ICMP-пакет “сообщение слишком велико”со значением MTU следующего шага [14] равным M
(c) Если возможно, посылается ICMP-пакет, уведомляющий отправителя отвергнутой дейтограммы, что сообщение слишком велико.
3. Форматы сообщений, связанные с LSP туннелями
Пять новых объектов определено в данном разделе:
Имя объекта | Применимые RSVP-сообщения |
LABEL_REQUEST | Path |
LABEL | Resv |
EXPLICIT_ROUTE | Path |
RECORD_ROUTE | Path, Resv |
SESSION_ATTRIBUTE | Path |
Новые C-типы присваиваются также объектам SESSION, SENDER_TEMPLATE и FILTER_SPEC.
Подробные описания новых объектов представлены в последующих разделах. Все новые объекты являются с точки зрения RSVP опционными. Реализация может выбрать поддержку некоторого субнабора объектов. Однако объекты LABEL_REQUEST и LABEL в рамках данного документа являются обязательными.
Объекты LABEL и RECORD_ROUTE являются специфическими для отправителя. В сообщениях Resv они должны появляться после FILTER_SPEC и до любой последующей спецификации FILTER_SPEC.
Относительное положение объектов EXPLICIT_ROUTE, LABEL_REQUEST и SESSION_ATTRIBUTE является лишь рекомендацией. Порядок размещения этих объектов не важно, так что программная реализация должна быть готова воспринимать объекты в любом порядке.
3.1. Сообщение 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> ] |
3.2. Сообщение 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.
4. Объекты, связанные с LSP туннелем
4.1. Объект 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.
4.1.1. Обработка объектов Label в сообщениях Resv
Узел в MPLS может поддерживать большое пространство меток, пространства меток для разных интерфейсов не перекрываются. В последующем обсуждении термин "та же метка" означает идентичность значений меток из общего пространства меток. Все последующие рассмотрения касаются уникастных сессий.
Метки, полученные в сообщениях Resv через разные интерфейсы, всегда считаются разными, даже если их значения идентичны.
4.1.1.1. Внизу по течению
Узел, размещенный внизу по течению, выбирает метку, которая будет представлять поток. Если в запросе специфицирован диапазон меток, метка должна лежать в этом диапазоне. Если свободных меток нет, узел посылает сообщение PathErr с кодом ошибки "routing problem" (проблема маршрутизации) и значением ошибки "label allocation failure" (отказ выделения метки).
Если узел получает сообщение Resv, которое присваивает одно и то же значение метки нескольким отправителям, тогда этот узел может также присвоить одно значение тем же отправителям или любому субнабору этих отправителей. Заметим, что, если узел намерен осуществлять определенную политику в отношении отдельных отправителей в рамках сессии, он должен присвоить уникальную метку этим отправителям.
В случае ATM применимо дополнительное условие. Некоторые ATM узлы не способны объединять потоки. Эти узлы могут уведомлять об этом путем установления бита запроса метки равным нулю. M-бит в объекте LABEL_REQUEST C-Type 2 запроса метки в диапазоне меток ATM служит именно этой цели. M-бит должен быть установлен узлами, которые способны объединять потоки. Если для нескольких отправителей бит M не установлен, узел внизу по течению должен этим отправителям присвоить уникальные метки.
Когда метка присвоена, узел формирует новый объект LABEL. Узел затем посылает новый объект LABEL в качестве части сообщения Resv предшествующему узлу. Узел должен быть готов переадресовывать пакеты, содержащие присвоенные метки, до посылки сообщения Resv. Объект LABEL должен содержаться в блоке состояния резервирования. Он потом используется для формирования Resv сообщения.
Ожидается, что узел пошлет сообщение Resv, прежде чем перезапустит свой таймер, если содержимое объекта LABEL изменяется.
4.1.1.2. Вверху по течению
Узел использует метку, содержащуюся в объекте LABEL, как выходную метку, ассоциированную с отправителем. Маршрутизатор присваивает новую метку и связывает ее с входным интерфейсом этой сессии/отправителя. Это тот же интерфейс, который маршрутизатор использует для переадресации сообщений Resv предшествующим узлам.
Несколько условий могут сделать метку неприемлемой.
- Узел является коммутатором ATM, неспособным объединять потоки, но узел ниже по течению присвоил идентичные метки двум отправителям.
- Присвоена метка нуль, но узел неспособен выполнить предпоследнее извлечение из стека для соответствующего L3PID
- Присвоенная метка находится вне запрошенного диапазона меток.
В любом из этих случаев узел посылает сообщение ResvErr с кодом ошибки "проблема маршрутизации" и значением ошибки "неприемлемое значение метки".
4.1.2. Отсутствие поддержки объекта Label
При нормальных обстоятельствах, узел не должен получать объект LABEL в сообщении Resv, если только оно не содержит объект LABEL_REQUEST в соответствующем сообщении Path. Однако, маршрутизатор RSVP, который не распознает объект LABEL, посылает получателю ResvErr с кодом ошибки "Unknown object class" (неизвестный класс объекта). Это приводит к аннулированию резервирования.
4.2. Объект запроса метки
Класс запроса метки равен 19. В настоящее время существует три возможных значения C_Types. Тип 1 относится к запросам метки без диапазона значений. Тип 2 является запросом метки с диапазоном ATM. Тип 3 является запросом метки с диапазоном Frame Relay. Объект LABEL_REQUEST имеет форматы показанные ниже.
4.2.1. Запрос метки без указания диапазона
Класс = 19, C_Type = 1
Рис. 1
Зарезервировано | Это поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при получении |
L3PID | Идентификатор протокола слоя 3, используемого в этом проходе. Используются стандартные значения для Ethertype. |
4.2.2. Запрос метки с диапазоном ATM
Класс = 19, C_Type = 2
Рис. 2.
Резерв | Это поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при получении |
L3PID | Идентификатор протокола слоя 3, используемого в этом проходе. Используются стандартные значения для Ethertype. |
M | Установка этого бита равным 1 указывает, что узел может объединять потоки. |
Минимум VPI (12 бит) | Это 12 битное поле специфицирует нижнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VPI меньше 12-бит, оно должно быть выровнено по правому полю, а предшествующие биты должны равняться нулю. |
Минимум VCI (16 бит) | Это 16 битное поле специфицирует нижнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VCI меньше 16-бит, оно должно быть выровнено по правому полю, а предшествующие биты должны равняться нулю. |
Максимум VPI (12 бит) | Это 12-битное поле специфицирует верхнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VPI меньше 12-бит оно должно быть выровнено по правому полю, а предшествующие биты должны равняться нулю. |
Максимум VCI (16 бит) | Это 16 битное поле специфицирует верхнюю границу блока идентификаторов виртуального пути, которая поддерживается исходным коммутатором. Если VCI меньше 16-бит, оно должно быть выровнено по правому полю, а предшествующие биты должны равняться нулю. |
4.2.3. Запрос метки с диапазоном Frame Relay
Класс = 19, C_Type = 3
Рис. 3.
Резерв | Это поле зарезервировано. Оно должно равняться нулю при передаче и игнорироваться при получении |
L3PID | Идентификатор протокола слоя 3, используемого в этом проходе. Используются стандартные значения для Ethertype. |
DLI | Индикатор длины DLCI. Число бит в DLCI. Поддерживаются следующие значения: Len бит в DLCI 0 10 2 23 |
Минимум DLCI | Это 23-битное поле специфицирует нижнюю границу блока идентификаторов виртуальных каналов (DLCI), которая поддерживается исходным коммутатором. DLCI должно быть выровнено по правому полю, а неиспользуемые биты должны ровняться нулю |
Maximum DLCI | Это 23-битное поле специфицирует верхнюю границу блока идентификаторов виртуальных каналов (DLCI), которая поддерживается исходным коммутатором. DLCI должно быть выровнено по правому полю, а неиспользуемые биты должны ровняться нулю |
4.2.4. Обработка 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.
4.2.5. Отсутствие поддержки объекта запроса метки
Маршрутизатор 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 non-RSVP capable router stands in the path" (оговорен протокол MPLS, но на пути стоит маршрутизатор без поддержки RSVP). То же самое сообщение следует послать, если маршрутизатор получает объект LABEL_REQUEST в сообщении от маршрутизатора без поддержки RSVP. О том, как маршрутизатор внизу по течению может обнаружить маршрутизатор без поддержки RSVP, смотри в [1].
4.3. Объект явный маршрут
Явные маршруты (Explicit Route) специфицируются с помощью объекта EXPLICIT_ROUTE (ERO). Класс явных маршрутов имеет код 20. В настоящее время определен один C_Type, тип 1 - явный маршрут. Объект EXPLICIT_ROUTE имеет следующий формат:
Класс = 20, C_Type = 1
Содержимое объекта EXPLICIT_ROUTE представляет собой последовательность информационных записей переменной длины, называемых субобъектами. Субобъекты определены в разделе 4.3.3.
Если сообщение Path содержит несколько объектов EXPLICIT_ROUTE, только первый объект имеет смысл. Последующие объекты EXPLICIT_ROUTE могут игнорироваться и не должны пересылаться далее.
4.3.1. Применимость
Объект EXPLICIT_ROUTE предназначен для использования только в уникастной среде. Приложения с явной маршрутизацией для мультикастинга являются предметом дальнейших исследований.
Объект EXPLICIT_ROUTE следует использовать только, когда все маршрутизаторы вдоль явного маршрута поддерживают RSVP и объект EXPLICIT_ROUTE. Объекту EXPLICIT_ROUTE присвоено значение класса в формате 0bbbbbbb. Маршрутизаторы RSVP, которые не поддерживают этот объект, будут откликаться сигналом ошибки "Unknown Object Class".
4.3.2. Семантика объекта явный маршрут (Explicit Route)
Явный маршрут представляет собой конкретный путь в рамках сетевой топологии. Обычно, явный маршрут определяется узлом, с целью направить трафик по этому пути.
Явный маршрут представляется в виде списка групп узлов вдоль явного маршрута. Кроме возможности идентифицировать определенные узлы вдоль пути, явный маршрут может определить группу узлов, через которые должен пролегать путь. Эта возможность предоставляет маршрутной системе значительную гибкость при выполнении запросов по формированию явных маршрутов.
Явный маршрут описывается последовательностью субобъектов, содержащихся в объекте EXPLICIT_ROUTE. Каждый субобъект идентифицирует группу узлов явного маршрута.
Чтобы формализовать обсуждение, мы называем каждую группу узлов абстрактным узлом. Таким образом, мы говорим, что явный маршрут является спецификацией набора абстрактных узлов, через которые должен пролегать маршрут. Если абстрактный узел состоит только из одного узла, его называют простым абстрактным узлом.
В качестве примера концепции абстрактных узлов рассмотрим явный маршрут, который состоит исключительно из субобъектов номеров автономных систем. Каждый субобъект соответствует в глобальной топологии автономной системе. В этом случае каждая автономная система является абстрактным узлом, и явный маршрут является путем, который включает в себя каждую из специфицированных автономных систем. В пределах автономной системы может быть много шагов, но в случае явного маршрута они невидимы для узла отправителя.
4.3.3. Субобъекты
Содержимое объекта EXPLICIT_ROUTE представляет собой последовательность записей переменной длины, называемых субобъектами. Каждый субобъект имеет формат, представленный ниже:
Рис. 4.
L | Бит L является атрибутом субобъекта. Если бит L =1, то субобъект является свободным шагом в явном маршруте. Если бит =0, субобъект является жестким шагом в явном маршруте. |
Тип | Поле тип определяет тип содержимого субобъекта. В настоящее время определены следующие значения: 1 IPv4 префикс
2 IPv6 префикс
32 номер автономной системы |
Длина | Поле длина содержит полную длину субобъекта в байтах, включая поля L, тип и длина. Значение поля длина должно быть кратно 4 и не менее 4. |
4.3.3.1. Строгие и свободные субобъекты
Бит L в субобъекте является однобитовым атрибутом. Если бит L =1, тогда значение атрибута соответствует ‘свободный'. В противном случае, значение атрибута является 'строгим'. Для краткости, будем говорить, что, если значение атрибута субобъекта ‘свободный', тогда это 'свободный субобъект'. В противном случае, это 'строгий субобъект'. Более того, мы говорим, что абстрактный узел строгого или свободного субобъекта является строгим или свободным узлом, соответственно.1
4.3.3.2. Субобъект 1: IPv4 префикс
Рис. 5.
L | Бит L является атрибутом субобъекта. Если бит L=1, то субобъект является свободным шагом в явном маршруте. Если L=0, субобъект является жестким шагом в явном маршруте. |
Тип | 0x01 IPv4 адрес |
Длина | Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля всегда =8 |
IPv4 адрес | IPv4 адрес. Этот адрес рассматривается как префикс, базирующийся на значении длины префикса. Биты за пределами префикса игнорируются при приеме и должны равняться нулю при передаче. |
Длина префикса | Длина префикса IPv4 в битах |
Заполнитель | Нуль при передаче. Игнорируется при приеме. |
Содержимым префикса IPv4 субобъекта является 4-октета IPv4 адреса, 1-октет длины префикса и 1-октет заполнителя. Абстрактный узел, представляемый этим субобъектом, является набором узлов, которые имеют IP адрес в пределах этого префикса. Заметим, что длина префикса 32 указывает на один узел IPv4.
4.3.3.3. Субобъект 2: IPv6 префикс
Рис. 6.
L | Бит L является атрибутом субобъекта. L бит =1, если субобъект представляет собой свободный шаг в явном маршруте. Если L =0, субобъект представляет собой строгий шаг в явном маршруте |
Тип | 0x02 IPv6 адрес |
Длина | Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля длина всегда =20 |
IPv6 адрес | Адрес IPv6. Этот адрес обрабатывается как префикс на основе величины длины префикса. Биты за пределами префикса игнорируются при приеме и должны равняться нулю при передаче. |
Длина префикса | Длина префикса IPv6 в битах |
Заполнитель | Нуль при передаче. Игнорируется при приеме. |
Содержимым префикса IPv6 субобъекта является 16-октетным IPv6 адресом, 1-октет префикса длины и 1-октета заполнителя. Абстрактный узел, представляемый этим субобъектом, является набором узлов, которые имеют IP адрес в пределах этого префикса. Заметим, что длина префикса 128 указывает на один узел IPv6.
4.3.3.4. Субобъект 32: Номер автономной системы
Содержимым субобъекта номера автономной системы (AS) являются два октета номера AS. Абстрактный узел, представленный субобъектом, является набором узлов, принадлежащих автономной системе. Длина номера AS субобъекта составляет 4 октета.
4.3.4. Обработка объекта Explicit Route
4.3.4.1. Выбор следующего шага
Узел, получающий сообщение Path, содержащее объект EXPLICIT_ROUTE, должен определить следующий шаг пути. Это необходимо из-за того, что следующий абстрактный узел вдоль явного маршрута может быть субсетью IP или автономной системой. Следовательно, выбор этого следующего шага может включать в себя выбор одной из возможных альтернатив. Критерии, используемые, чтобы выполнить выбор, зависят от конкретной реализации и могут зависеть от локальной политики. Однако предполагается, что каждый узел сделает все возможное, чтобы исключить кольцевые маршруты. Заметим, что так определенные пути могут быть отвергнуты локальной политикой. Чтобы определить следующий шаг пути, узел выполняет следующие операции:
1) Узел, получив сообщение RSVP должен определить первый субобъект. Если узел не является частью абстрактного узла, описанного первым субобъектом, он получил сообщение с ошибкой и должен прислать сигнал ошибки "Bad initial subobject". Если первого субобъекта вообще нет, сообщение ошибочно и система должна прислать сигнал ошибки "Bad EXPLICIT_ROUTE object".
2) Если нет второго субобъекта, это указывает на конец явного маршрута. Объект EXPLICIT_ROUTE должен быть удален из сообщения Path. Этот узел может быть или не быть концом пути. Рассмотрение обработки продолжается в разделе 4.3.4.2, где допускается добавление нового объекта EXPLICIT_ROUTE в сообщение Path.
3) Далее, узел определяет второй субобъект. Если узел является частью абстрактного узла, описанного во втором субобъекте, тогда узел удаляет первый субобъект и продолжает обработку с пункта 2. Заметим, что это делает второй субобъект первым в следующей итерации и позволяет узлу идентифицировать следующий абстрактный узел пути после возможного повторения шагов 2 и 3.
4) Абстрактный пограничный узел: Узел определяет, является ли он топологически смежным с абстрактным узлом, описанным во втором субобъекте. Если это так, узел выбирает конкретный следующий шаг, адресатом которого является один из членов абстрактного узла. Узел затем убирает первый субобъект и продолжает обработку согласно разделу 4.3.4.2.
5) Случай внутреннего абстрактного узла: В противном случае узел выбирает следующий шаг в пределах абстрактного узла первого субобъекта (к которому данный узел принадлежит), то есть вдоль пути к абстрактному узлу второго субобъекта (который является следующим абстрактным узлом). Если такого пути нет, тогда возможны два варианта:
5a) Если второй субобъект является жестким, имеет место ошибка и узел должен прислать уведомление об ошибке "Bad strict node".
5b) В противном случае, если второй субобъект является свободным, узел выбирает любой следующий шаг вдоль пути к очередному абстрактному узлу. Если такого пути нет, имеет место ошибка, и узел должен прислать сигнал ошибки "Bad loose node".
6) Наконец, узел заменяет первый субобъект любым субобъектом, который указывает на абстрактный узел, содержащий следующий шаг. Это необходимо для того, чтобы при получении следующим узлом явного маршрута, он был воспринят.
4.3.4.2. Добавление субобъектов в объект Explicit Route
После выбора следующего шага, узел может изменить явный маршрут следующими способами. Если в процессе реализации алгоритма (см. раздел 4.3.4.1) объект EXPLICIT_ROUTE удален, узел может добавить новый объект EXPLICIT_ROUTE.
В противном случае, если узел является членом абстрактного узла первого субобъекта, перед первым субобъектом может быть введена последовательность субобъектов или первый субобъект может быть заменен. Каждый субобъект в этой последовательности должен представлять абстрактный узел, который является субнабором текущего абстрактного узла.
В качестве альтернативы, если первый субобъект является свободным, перед ним может быть введена произвольная последовательность субобъектов.
4.3.5. Петли
Так как объект EXPLICIT_ROUTE имеет конечную длину, существование свободных узлов предполагает, что возможно формирование петлевых путей в период переходных процессов, сопряженных с реализацией маршрутных протоколов. Это может быть детектировано исходным узлом явного маршрута путем использования еще одного непрозрачного объекта маршрута, называемого RECORD_ROUTE. Объект RECORD_ROUTE используется для сбора детальной информации о маршруте и является полезным для детектирования петель и для диагностики.
4.3.6. Прямая совместимость
Ожидается, что со временем могут быть определены новые субобъекты. Узел, который столкнулся в процессе обработки ERO с нераспознанным субобъектом, посылает отправителю PathErr с кодом ошибки "Routing Error" и значением ошибки "Bad Explicit Route Object". Присутствие нераспознанного субобъекта, который не встретился в ходе обработки ERO, следует игнорировать. Он передается далее вместе с остальной частью стека ERO.
4.3.7. Отсутствие поддержки объекта Explicit Route
Маршрутизатор RSVP, который не распознает объект EXPLICIT_ROUTE, посылает отправителю PathErr с кодом ошибки "Unknown object class". Это вызывает отказ формирования пути. Отправитель должен уведомить руководство, что LSP не может быть сформирован и возможно предпримет действия по резервированию без EXPLICIT_ROUTE или с привлечением другого явного маршрута.
4.4. Объект Record Route
Маршруты могут записываться с помощью объекта RECORD_ROUTE (RRO). Опционно, могут записываться и метки. Код класса записи маршрута равен 21. В настоящее время определен только один код C_Type, тип 1 (запись маршрута). Объект RECORD_ROUTE имеет достаточно простой формат:
Класс = 21, C_Type = 1
Содержимое объекта RECORD_ROUTE представляет собой последовательность записей переменной длины, называемых субобъектами. Субобъекты определены в разделе 4.4.1.
RRO может присутствовать как в сообщениях RSVP Path, так и Resv. Если сообщение Path содержит несколько RRO, только первое RRO имеет значение. Последующие RRO следует игнорировать и не передавать дальше. Аналогично, если в сообщении Resv имеется несколько RRO, следующих за FILTER_SPEC, только первое RRO имеет смысл. Последующие RRO следует игнорировать и не пересылать далее.
4.4.1. Субобъекты
Содержимое объекта RECORD_ROUTE представляет собой последовательность записей переменной длины, называемых субобъектами. Каждый субобъект имеет поле своей длины. Это поле содержит полную длину субобъекта в байтах, включая поля тип и длина. Значения кода длины должно быть кратно 4 и быть не менее 4.
Субобъекты образуют стек последний вошел - первым вышел (LIFO). Первый субобъект по отношению к началу RRO считается размещенным сверху. Последний субобъект считается помещенным на дно. Когда добавляется новый субобъект, он всегда помещается сверху.
Пустой RRO (без субобъектов) считается некорректным. В настоящее время определено три типа субобъектов.
4.4.1.1. Субобъект 1: адрес IPv4
Рис. 7.
Тип | 0x01 IPv4 адрес |
Длина | Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля всегда =8 |
IPv4 адрес | 32-битный уникастный, адрес ЭВМ. Здесь может быть указан любой достижимый сетевой интерфейс. Недопустимыми адресами могут считаться, например, адреса loopback, они не должны использоваться |
Длина префикса | 32 |
Флаги | 0x01 имеется локальная защита Указывает, что канал вниз по течению от этого узла защищен с помощью некоторого локального механизма восстановления. Этот флаг может =1, если только установлен флаг локальной защиты в объекте SESSION_ATTRIBUTE соответствующего сообщения Path. 0x02 Используется локальная защита Указывает, что в данном туннеле используется локальный механизм восстановления. |
4.4.1.2. Субобъект 2: IPv6 адрес
Рис. 8.
Тип | 0x02 IPv6 адрес |
Длина | Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. Значение поля всегда =20 |
IPv6 адрес | 128-битовый уникастный адрес ЭВМ |
Длина префикса | 128 |
Флаги | 0x01 доступна локальная защита Указывает, что канал вниз по течению от этого узла защищен с помощью некоторого локального механизма восстановления. Этот флаг может =1, если только установлен флаг локальной защиты в объекте SESSION_ATTRIBUTE соответствующего сообщения Path. 0x02 Используется локальная защита Указывает, что в данном туннеле используется локальный механизм восстановления. |
4.4.1.3. Субобъект 3, Метка
Рис. 9.
Тип | 0x03 Label (метка) |
Длина | Поле длина содержит полную длину субобъекта в байтах, включая поля тип и длина. |
Флаги | 0x01 = Глобальная метка Этот флаг указывает на то, что метка будет воспринята корректно любым интерфейсом |
C-тип | C-тип включенного объекта Label. Копируется из объекта Label |
Содержимое объекта Label | Содержимое объекта Label. Копируется из объекта Label |
4.4.2. Применимость
Здесь определено использование только уникастных сессий. Существует три возможных применения RRO в RSVP. Первое, RRO может функционировать как механизм детектирования петель для выявления кольцевых маршрутов на уровне L3, или петель, сопряженных с явным маршрутом.
Второе, RRO собирает текущую маршрутную информацию шаг-за-шагом о сессиях RSVP, предоставляя ценные данные отправителю или получателю. При этом будут сообщаться любые изменения маршрута (в связи с изменением топологии сети).
Третье, синтаксис RRO сконструирован так, чтобы можно было с минимальными изменениями использовать весь объект в качестве входных данных для объекта EXPLICIT_ROUTE. Это полезно, если отправитель получает RRO от получателя в сообщении Resv, применяет его к объекту EXPLICIT_ROUTE в следующем сообщении Path, для того чтобы определить маршрут сессии.
4.4.3. Обработка RRO
Обычно, узел запускает сессию RSVP путем добавления RRO в сообщение Path. Исходное RRO содержит только один субобъект - IP-адреса отправителей. Если узел хочет также записывать метки, он устанавливает флаг Label_Recording в атрибуте SESSION_ATTRIBUTE.
Когда промежуточный маршрутизатор получает сообщение Path, содержащее RRO, он запоминает копию его блока состояния маршрута. RRO затем используется в следующем обновлении Path для форматирования сообщений Path. Когда нужно послать новое сообщение Path, маршрутизатор добавляет новый субобъект в RRO и вставляет полученный RRO в сообщение Path перед передачей.
Вновь добавляемым субобъектом должен быть IP-адрес этого маршрутизатора. Должен быть добавлен адрес интерфейса исходящего сообщения Path. Если имеется несколько адресов, выбор осуществляется исключительно локально. Однако рекомендуется, чтобы выбор адреса осуществлялся по единым правилам.
Когда флаг Label_Recording в объекте SESSION_ATTRIBUTE =1, узлы, осуществляющие запись маршрута, должны включать субобъект Label Record. Если узел использует глобальное пространство меток, тогда ему следует установить флаг Global Label.
Субобъект Label Record вводится в объект RECORD_ROUTE до введения туда IP-адреса узла. Узел не должен вводить субобъект Label Record, не вводя субобъекта IPv4 или IPv6.
Заметим, что при получении исходного сообщения Path, узел вряд ли имеет метку. Как только метка получена, узел должен включить ее в RRO при следующем обновлении Path.
Если вновь добавленный субобъект приводит к тому, что RRO оказывается слишком велико для сообщения Path (или Resv), объект RRO будет выброшен из сообщения, а обработка самого сообщения будет продолжена обычным образом. Должно быть послано отправителю (или получателю) сообщение PathErr (или ResvErr). Код ошибки будет "Notify" (внимание), а значение ошибки "RRO too large for MTU". Если получатель получает такое ResvErr, ему следует послать сообщение PathErr с кодом ошибки "Notify" и значением ошибки "RRO notification". Отправитель, получив любое из этих значений ошибок должен удалить RRO из сообщения Path.
Узлы должны повторно посылать указанные выше сообщения PathErr или ResvErr каждые n секунд, где n более 15 и обновлять интервал для сопряженного сообщения Path или RESV. Узел может применить ограничения и/или таймеры задержки, чтобы уменьшить число посылаемых сообщений.
Маршрутизатор RSVP может решить послать сообщения Path до их времени обновления, если RRO в следующем сообщении Path отличается от предыдущего. Может случиться если содержимое RRO, полученное от маршрутизатора предыдущего шага, изменяется или, если этот RRO вновь добавлен (или удален из) сообщения Path.
Когда узел назначения сессии RSVP получает сообщение Path с RRO, это указывает, что отправителю нужна запись маршрута. Узел назначения инициирует RRO процесс путем добавления RRO в сообщения Resv. Обработка отображает эти сообщения Path. Единственная разница заключается в том, что RRO в сообщении Resv записывает маршрутную информацию в обратном направлении.
Заметим, что каждый узел вдоль пути будет теперь иметь полный маршрут от отправителя до получателя. Path RRO будет иметь маршрут от отправителя до этого узла; Resv RRO будет иметь маршрут от этого узла до места назначения. Это полезно для управления сетью.
Сообщение Path, полученное без RRO, указывает, что узел отправителя не хочет более записывать маршрут. Последующие сообщения Resv не будут содержать RRO.
4.4.4. Обнаружение циклических маршрутов
В процессе обработки входящих RRO, промежуточный маршрутизатор просматривает все субобъекты, содержащиеся в RRO. Если маршрутизатор определяет, что субобъект уже содержится в списке, это означает наличие петлевого маршрута.
Сессия RSVP лишена циклов, если узлы ниже по течению получают сообщения Path или вышестоящие узлы получают сообщения Resv без маршрутных петель, обнаруженных в RRO.
Существует две широкие классификации петель переадресации. К первому классу относятся переходные петли, которые возникают при нормальной работе маршрутизаторов L3. Ко второму классу относятся постоянные петли, которые являются результатом ошибок конфигурации. Действия маршрутизатора при получении RRO зависят от типа сообщения, в котором получено RRO.
Для сообщений Path, содержащих петли переадресации, маршрутизатор формирует и посылает PathErr сообщение "Routing problem", со значение ошибки "loop detected" (обнаружена петля), после чего выбрасывает сообщение Path. Пока петля не ликвидирована, эта сессия не пригодна для переадресации информационных пакетов.
Для сообщений Resv, содержащего петлю переадресации, маршрутизатор просто отбрасывает сообщения. Сообщения Resv не должны циклить, если сообщения Path не имеют петель.
4.4.5. Прямая совместимость
Для RRO могут быть определены новые субобъекты. Когда при обработке RRO, нераспознаны субобъекты, их следует игнорировать и передавать дальше. При обработке RRO на предмет выявления петель, узел должен обходить нераспознанные при разборе объекты. Детектирование петель происходит при обнаружении субобъектов, которые выли введены самим узлом ранее. Это гарантирует, что субобъекты нужные для детектирования петель, всегда будут распознаны.
4.4.6. Отсутствие поддержки RRO
Объект RRO должен использоваться, только когда все маршрутизаторы вдоль пути поддерживают RSVP и объект RRO. Объекту RRO преписывается значение класса в форме 0bbbbbbb. Маршрутизаторы RSVP, которые не поддерживают объект будут откликаться сообщением об ошибке "Unknown Object Class" (неизвестный объект).
4.5. Коды ошибок для ERO и RRO
При обработке, описанной выше, определенные ошибки должны быть объявлены как " Routing Problem" или "Notify" (проблема маршрутизации или внимание). Значение кода ошибки "Routing Problem" равно 24; значение кода "Notify" равно 25. Определены следующие значения ошибок для кода ошибки Routing Problem:
Значение | Ошибка: |
1 | Bad EXPLICIT_ROUTE object (плохой объект EXPLICIT_ROUTE) |
2 | Bad strict node (плохой жесткий узел) |
3 | Bad loose node (плохой свободный узел) |
4 | Bad initial subobject (плохой исходный субобъект) |
5 | No route available toward destination (нет пути до адресата) |
6 | Unacceptable label value (неприемлемое значение метки) |
7 | RRO indicated routing loops (RRO указывает на наличие петли) |
8 | MPLS being negotiated, but a non-RSVP-capable router stands in the path (согласовывался MPLS, но на пути стоит маршрутизатор без поддержки RSVP) |
9 | MPLS label allocation failure (ошибка присвоения MPLS метки) |
10 | Unsupported L3PID (не поддерживаемый L3PID) |
Для кода ошибки Notify, 16 бит значения поля ошибки имеет вид:
ss00 cccc cccc cccc
Старшие биты определены при коде ошибки 1. (Смотри [1]). Когда ss = 00, определены следующие субкоды:
1 RRO для MTU слишком велико
2 RRO уведомление
3 Туннель локально восстановлен
4.6. Объекты сессии, шаблона отправителя и спецификации фильтра
Новые C-типы определены для объектов SESSION, SENDER_TEMPLATE и FILTER_SPEC.
Объекты LSP_TUNNEL имеют следующий формат:
4.6.1. Объект Session
4.6.1.1. Объект сессии LSP_TUNNEL_IPv4
Класс = SESSION, LSP_TUNNEL_IPv4 C-тип = 7
Рис. 10.
IPv4 адрес конца туннеля | IPv4 адрес оконечного узла туннеля |
ID туннеля | 16-битный идентификатор, используемый в сессии и сохраняемый на протяжении жизни туннеля |
Расширенный ID туннеля | 32- битный идентификатор, используемый в сессии и сохраняемый на протяжении жизни туннеля. Обычно устанавливается равным нулю. Входные узлы, которые хотят сузить область сессии до пары вход-выход, могут поместить сюда свой IPv4 адрес в качестве глобально уникального идентификатора. |
4.6.1.2. Объект сессии LSP_TUNNEL_IPv6
Класс = SESSION, LSP_TUNNEL_IPv6 C_тип = 8
Рис. 11.
IPv6-адрес конца туннеля | IPv6 адрес выходного узла туннеля |
ID туннеля | 16-битный идентификатор, используемый в сессии и сохраняемый на протяжении жизни туннеля |
Расширенный ID туннеля | 16-битный идентификатор, используемый в сессии и сохраняемый на протяжении жизни туннеля. Обычно устанавливается равным нулю. Входные узлы, которые хотят сузить область сессии до пары вход-выход, могут поместить сюда свой IPv6 адрес в качестве глобально уникального идентификатора |
4.6.2. Объект отправителя Template (шаблон)
4.6.2.1. Объект шаблона отправителя LSP_TUNNEL_IPv4
Класс = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-тип = 7
Рис. 12.
IPv4-адрес отправителя для туннеля | IPv4 адрес узла отправителя |
LSP ID | 16-битовый идентификатор, используемый в SENDER_TEMPLATE и FILTER_SPEC, который может быть изменен, чтобы позволить отправителю совместное использование ресурсов |
4.6.2.2. Объект шаблона отправителя LSP_TUNNEL_IPv6
Класс = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_тип = 8
Рис. 13.
IPv6 адрес отправителя туннеля | IPv6 адрес узла отправителя |
LSP ID | 16-битовый идентификатор, используемый в SENDER_TEMPLATE и FILTER_SPEC, который может быть изменен, чтобы позволить отправителю совместное использование ресурсов |
4.6.3. Объект спецификации фильтра
4.6.3.1. Объект спецификации фильтра LSP_TUNNEL_IPv4
Класс = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-тип = 7
Формат объекта LSP_TUNNEL_IPv4 FILTER_SPEC идентичен формату LSP_TUNNEL_IPv4 SENDER_TEMPLATE.
4.6.3.2. Объект спецификации фильтра LSP_TUNNEL_IPv6
Класс = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_тип = 8
Формат объекта LSP_TUNNEL_IPv6 FILTER_SPEC идентичен формату LSP_TUNNEL_IPv6 SENDER_TEMPLATE.
4.6.4. Процедура изменения маршрута и увеличения полосы
В этом разделе описывается то, как формируется туннель, способный поддерживать резервирование ресурсов, когда меняется маршрут или когда делается попытка увеличить полосу. В исходном сообщении Path, входной узел образует объект SESSION, присваивает Tunnel_ID, и помещает его IPv4-адрес в Extended_Tunnel_ID. Он также формирует SENDER_TEMPLATE и присваивает LSP_ID. Конфигурация туннеля продолжается согласно обычной процедуре. При получении сообщения Path, оконечный узел посылает входному узлу сообщение Resv со стилем Shared Explicit.
Когда входной узел с установленным проходом хочет изменить маршрут, он формирует новое сообщение Path следующим образом. Используется существующий объект SESSION. В частности не изменяются Tunnel_ID и Extended_Tunnel_ID. Входной узел, чтобы сформировать новый SENDER_TEMPLATE, берет новый LSP_ID. Для нового маршрута он создает объект EXPLICIT_ROUTE. Посылается новое сообщение Path. Входной узел обновляет старое и новое сообщения path. Выходной узел откликается сообщением Resv с дескриптором потока SE, сформированным следующим образом:
<FLOWSPEC> <old_FILTER_SPEC> <old_LABEL_OBJECT> <new_FILTER_SPEC>
<new_LABEL_OBJECT>
(Заметим, что если PHOP отличны, тогда посылается два новых сообщения, каждое из которых снабжено соответствующими FILTER_SPEC и LABEL_OBJECT).
Когда входной узел поучает сообщение Resv, он может начать использовать новый маршрут. Он должен послать сообщение PathTear для старого маршрута.
4.7. Объект атрибута сессии
Атрибут класса сессии равен 207. Определены два C_типа, LSP_TUNNEL, C-тип = 7 и LSP_TUNNEL_RA, C-тип = 1. C-тип LSP_TUNNEL_RA включает в себя те же поля, что и LSP_TUNNEL C-тип. Используются следующие форматы:
4.7.1. Формат без привязки ресурсов
Класс SESSION_ATTRIBUTE = 207, LSP_TUNNEL C-тип = 7
Рис. 14.
Приоритет Setup | Приоритет сессии с учетом используемых ресурсов, в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет Setup используется при решении того, может ли сессия идти вне очереди по отношению к другой сессии |
Приоритет | Приоритет сессии по отношению к удерживаемым ресурсам, в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет владения используется при решении, может ли сессия идти вне очереди по отношению к другой сессии |
Флаги | 0x01 Желательна локальная защита Этот флаг позволяет промежуточным маршрутизаторам использовать механизм локального восстановления, который может привести к порче объекта явный маршрут. Когда обнаружена ошибка в смежном канале вниз по течению или узле, промежуточный маршрутизатор может изменить путь трафика для быстрой службы восстановления. 0x02 нужна запись метки Этот флаг указывает, что при записи маршрута следует включить информацию о метке.
0x04 нужен стиль SE Этот флаг указывает, что входной узел туннеля может решить изменить маршрут без его ликвидации. Выходной узел туннеля должен использовать стиль SE, при реагировании на сообщение Resv |
Длина имени | Длина отображаемой строки в байтах до заполнителя. |
Имя сессии | Строка символов дополненная нулем |
4.7.2. Формат с привязкой ресурса
Класс SESSION_ATTRIBUTE = 207, LSP_TUNNEL_RA C-тип = 1
Рис. 15.
Исключает любой | 32-битный вектор, представляющий набор атрибутов фильтров, сопряженных с туннелем, каждый из которых может объявлять канал неприемлемым |
Включает любой | 32-битный вектор, представляющий набор атрибутов фильтров, сопряженных с туннелем, каждый из которых может объявить канал приемлемым (с точки зрения данного теста). Нулевой набор (все биты равны нулю) автоматически проходит. |
Включают все | 32-битный вектор, представляющий набор атрибутов фильтров, сопряженных с туннелем, каждый из которых должен присутствовать, чтобы канал был приемлем (с точки зрения данного теста). Нулевой набор (все биты равны нулю) автоматически проходит. |
Приоритет Setup | Приоритет сессии с точки зрения захвата ресурсов, в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет Setup используется при решении, может ли сессия идти вне очереди по отношению к другой сессии |
Приоритет удержания | Приоритет сессии с точки зрения удержания ресурсов, в диапазоне от 0 до 7. Значение нуль имеет высший приоритет. Приоритет удержания используется при решении, может ли сессия быть замещена другой сессией |
Флаги | 0x01 Желательна локальная защита Этот флаг позволяет промежуточным маршрутизаторам использовать механизм локального восстановления, который может вызвать нарушение объекта явного маршрута. Когда детектирована ошибка в смежном канале вниз по течению или узле, транзитный маршрутизатор может переадресовать трафик для службы быстрого восстановления.
0x02 Требуется запись меток Этот флаг указывает, что при записи маршрута информация о метке должна быть включена.
0x04 Желателен стиль SE Этот флаг индицирует то, что входной узел туннеля может решить изменить маршрут этого туннеля без его удаления. Узел конца туннеля, реагируя на сообщение Resv, должен использовать стиль SE. |
Длина имени | Длина отображаемой строки до заполнителя в байтах |
Имя сессии | Строка символов дополненная нулем |
4.7.3. Процедуры, применимые к обоим C-типам
Поддержка приоритетов setup и удержания является опционной. Узел может распознать эту информацию, но быть не способен выполнить запрошенную операцию. Узел должен передать информацию вниз по течению неизменной.
Как отмечено выше, приоритетное прерывание обслуживания использовано с привлечением двух приоритетов. Приоритет Setup является приоритетом получения ресурсов. Приоритет удержания является приоритетом удержания ресурса. Точнее, приоритет удержания является приоритетом, при котором ресурсы выделенные этой сессии будут зарезервированы. Приоритет Setup не должен быть никогда выше, чем приоритет удержания для заданной сессии.
Приоритеты setup и удержания являются прямыми аналогами приоритетного прерывания обслуживания и защитного приоритета, как это определено в [9]. В то время как взаимодействие этих двух объектов является в конце концов вопросом политики, следующие взаимодействия рекомендуются по умолчанию.
Когда присутствуют оба объекта, используется элемент приоритетного прерывания обслуживания. Соответствие между этими приоритетами определено следующим образом. Атрибут приоритета сессии S соответствует приоритету прерывания обслуживания P согласно формуле P = 2(14-2S). Таблица соответствия приоритетов представлена ниже.
Приоритетное прерывание
обслуживания | Приоритет атрибута сессии |
0 - 3 | 7 |
4 - 15 | 6 |
16 - 63 | 5 |
64 - 255 | 4 |
256 - 1023 | 3 |
1024 - 4095 | 2 |
4096 - 16383 | 1 |
16384 - 65535 | 0 |
Когда рассматривается новое сообщение Path с точки зрения приемлемости, запрашиваемая полоса сравнивается с возможной полосой в случае приоритета, заданного в Setup.
Если запрашиваемая полоса недоступна, посылается сообщение PathErr с кодом ошибки 01 (Admission Control Failure) и значением ошибки 0x0002. Первый 0 в значении ошибки указывает на глобально определенный субкод и не несет в себе конкретных данных. Код 002 указывает "запрошенная полоса недоступна".
Если запрашиваемая полоса меньше чем неиспользуемая полоса, тогда обработка запроса завершена. Если запрашиваемая полоса доступна, но занята менее приоритетными сессиями, тогда эти сессии (начиная с самой низкоприоритетной) могут быть прерваны для получения требующейся полосы.
Когда поддерживается приоритетное прерывание обслуживания, каждое из таких приоритетных резервирований осуществляет запрос TC_Preempt() локальным клиентам, передав субкод, который указывает на причину этого запроса. В этом случае следует послать ниже стоящим получателям и вышестоящим отправителям ResvErr и/или PathErr с кодом "Policy Control failure".
Поддержка локальной защиты является опционной. Узел может распознать флаг локальной защиты, но быть неспособным выполнить запрашиваемую операцию. В этом случае, узел должен передать информацию вниз по течению без изменений.
Запись субобъекта метка в объект ROUTE_RECORD управляется флагом записи метки в объекте SESSION_ATTRIBUTE. Так как субобъект метка не нужен всем приложениям, он не записывается автоматически. Флаг позволяет приложениям запрашивать это только в случае необходимости.
Содержимым поля имя сессии является строка, обычно отображаемых символов. Поле длина должна всегда быть кратной 4 и быть не меньше 8. Для объектов, длина которых не кратна 4, объект дополняется в конце символами NULL. Поле длина имени содержит длину активной строки.
4.7.4. Процедуры привязки ресурсов
Классы ресурсов и привязки классов ресурсов описаны в [3]. Классы ресурсов могут быть ассоциированы с каналами и объявляться в протоколах маршрутизации. Привязка класса ресурса используется RSVP двумя путями. Для того чтобы канал был признан работающим, он должен пройти три теста. Если тест не прошел, следует послать PathErr с кодом "ошибка управления политикой".
Когда рассматривается новый запрос резервирования для строгого узла в ERO, узел может проверить привязку ресурса к классу ресурса этого канала. Когда узел выбирает канал, для того чтобы расширить свободный узел ERO, узел должен проверить привязку классов ресурсов этих каналов к ресурсам. Если не удается найти приемлемого канала для расширения ERO, узел должен послать сообщение PathErr с кодом ошибки "Проблема маршрутизации" и значением ошибки "нет доступного маршрута до адресата". Для того чтобы быть подтвержденным маршрут должен пройти следующие три теста.
Чтобы точно описать тесты, используем определения объектов, представленные выше. Мы также определяем
Link-attr | 32-битовый вектор, представляющий собой атрибуты, ассоциированные с каналом |
Осуществляется три проверки
1. Исключает любой
Эта проверка исключает канал из рассмотрения, если канал характеризуется одним из атрибутов из набора. (link-attr & exclude-any) == 0
2. Включает любой
Этот тест воспринимает канал, если канал характеризуется любым атрибутом из набора. (include-any == 0) | ((link-attr & include-any) != 0)
3. Включает все
Этот тест воспринимает канал, если только канал характеризуется всеми атрибутами из набора. (include-all == 0) | (((link-attr & include-all) ^ include-all) == 0)
Для канала, который будет воспринят, все три теста должны пройти успешно. Если тест не прошел, узел должен послать сообщение PathErr с кодом ошибки "Проблема маршрутизации" и значением ошибки "нет приемлемого маршрута до адресата".
Если сообщение Path содержит несколько объектов SESSION_ATTRIBUTE, только первый объект имеет смысл. Последующие объекты SESSION_ATTRIBUTE могут игнорироваться и не должны переадресовываться.
Все маршрутизаторы RSVP, вне зависимости от того, поддерживают ли они объект SESSION_ATTRIBUTE или нет, должны переадресовать объект, не модифицируя. Присутствие маршрутизаторов без поддержки RSVP в любой области между отправителями и получателями не оказывает влияния на этот объект.
5. Расширение Hello
Расширение RSVP Hello позволяет узлам RSVP детектировать, когда соседний узел недоступен. Механизм предоставляет возможность поузлового детектирования отказа. Когда такой отказ детектирован, он обрабатывается также как и отказ канального уровня. Этот механизм предназначен для использования, когда нет уведомления об отказе канала и не используются ненумерованные каналы, или когда механизмы детектирования отказов, предоставляемые канальным уровнем, недостаточны для своевременного детектирования отказов узлов.
Следует заметить, что регистрация отказа узла не совпадает с механизмом детектирования отказа канала, в частности в случае нескольких параллельных ненумерованных каналов. Расширение Hello специально сконструировано так, что можно использовать или не использовать этот механизм. Детектирование отказа соседа может быть запущено в любое время. Сюда входит ситуация, когда соседи узнают впервые друг о друге, или когда соседи совмеcтно используют состояния Resv или Path.
Расширение Hello состоит из сообщения Hello, объектов HELLO REQUEST и HELLO ACK. Обработка Hello двумя соседями поддерживает независимый выбор обычно конфигурируемых интервалов детектирования отказов. Каждый сосед может автономно формировать объекты HELLO REQUEST. Получение каждого запроса подтверждается. Сообщения Hello содержат также достаточно информации, так что один сосед может подавить посылку запросов Hello и все же выполнить детектирование отказа соседа. Сообщение Hello может быть включено в виде составной части в блочное сообщение.
Детектирование отказа соседа выполняется путем получения и запоминания атрибута соседа. Если зарегистрировано изменение значения, или если сосед некорректно сообщает локально объявленное значение, тогда сосед предполагается отключенным. Когда обнаружено, что атрибут соседа изменился или когда связь с соседом потеряна, тогда значение атрибута говорит об изменении соседа. Объекты HELLO предоставляют механизм посылки запросов и предоставления значения атрибута. Запрос регистрации включает также значение атрибута отправителя. Это позволяет получателю регистрации опционно обрабатывать эти данные, как неявный отклик на регистрацию. Эта опционная обработка является оптимизацией, которая может уменьшить полное число запросов и откликов, обработанных парами соседей. Во всех случаях, когда обе стороны поддерживают оптимизацию, результатом будет только набор запросов и откликов за интервал детектирования отказа. В зависимости от выбранных интервалов, можно получить выигрыш, даже когда только один сосед поддерживает оптимизацию.
>5.1. Формат сообщения Hello
Сообщениями Hello всегда обмениваются только RSVP соседи. Адрес IP отправителя равен IP-адресу узла-отправителя. IP-адрес места назначения равен IP-адресу соседнего узла.
Механизм HELLO предназначен для использования только непосредственными соседями. Когда обмен сообщениями HELLO осуществляют соседи, поле IP TTL всех исходящих сообщений HELLO следует устанавливать равным 1.
Сообщение Hello имеет тип Msg равный 20. Формат сообщения Hello показан ниже:
<Hello Message> ::= | <Common Header> [ <INTEGRITY> ] <HELLO> |
5.2. Форматы объекта HELLO
Код класса HELLO = 22. Определено два C_типа.
5.2.1. Объект HELLO REQUEST
Класс = HELLO, C_тип = 1
Объект содержит атрибут отправителя (32 бита) и атрибут получателя (32 бита).
5.2.2. Объект HELLO ACK
Класс = HELLO, C_тип = 2
Объект HELLO ACK содержит 32 битный атрибут отправителя Src_Instance и 32-битный атрибут получателя Dst_Instance. Значение должно измениться, если отправитель отключился, когда узел перезагружается, или когда связь с узлом-соседом оборвалась, в противном случае значение остается неизменным. Это поле не должно иметь значения нуль.
Значение атрибута Src_Instance от соседа получено последним. Это поле должно равняться нулю, до тех пор, пока ничего от соседа не получено.
5.3. Использование сообщения Hello
Сообщение Hello является полностью опционным. Все сообщения могут игнорироваться узлами, которые не хотят участвовать в обработке сообщения Hello.
Узел периодически генерирует сообщение Hello, содержащее объект HELLO REQUEST, для каждого соседа, чей статус должен быть отслежен. Периодичность определяется значением hello_interval. Это значение может конфигурироваться для каждого соседа. Значение по умолчанию равно 5 мсек.
При генерации сообщения, содержащего объект HELLO REQUEST, отправитель заносит в поле Src_Instance значение его атрибута для каждого из соседей. Эта величина не должна изменяться в процессе обмена сообщениями Hello с соответствующими соседями. Отправитель заносит также в поле Dst_Instance значение Src_Instance, полученное от соседа последним. Для ссылки, назовем эту переменную Neighbor_Src_Instance. Если от соседа ничего не получено или узел считает связь с соседом потерянной, значение Neighbor_Src_Instance устанавливается равным нулю (0). Генерация сообщения следует подавить, когда объект HELLO REQUEST был получен от узла адресата в пределах интервала hello_interval.
Получив сообщение, содержащее объект HELLO REQUEST, адресат должен сформировать сообщение Hello, содержащее объект HELLO ACK. Получателю также следует проверить, что сосед активен. Это делается путем сравнения значения поля атрибута отправителя Src_Instance со значением, полученным ранее. Если значение Neighbor_Src_Instance равно нулю, а поле Src_Instance не равно нулю, значение Neighbor_Src_Instance обновляется. Если значения отличаются или поле Src_Instance равно нулю, тогда узел должен считать связь с соседом разорванной.
Получатель объекта HELLO REQUEST должен также проверить, что сосед возвращает назад значение атрибута получателя. Это делается путем сравнения полученного значения поля Dst_Instance с Src_Instance, посланным соседу последним. Если сосед продолжает рассылать неверное ненулевое значение после заданного числа временных интервалов, тогда узел считает соседа отключенным.
Получив сообщение, содержащее объект HELLO ACK, адресат должен проверить, что сосед активен. Это делается путем сравнения значения поля отправителя Src_Instance со значением, полученным до этого. Если значение Neighbor_Src_Instance равно нулю, а Src_Instance не равно нулю, величина Neighbor_Src_Instance обновляется. Если значения отличаются или поле Src_Instance не равно нулю, тогда узел должен считать связь с соседом оборванной.
Получатель объекта HELLO ACK должен также проверить, что сосед возвращает назад значение атрибута получателя. Если сосед рассылает неверное значение в поле Dst_Instance, тогда узел должен считать связь с соседом оборванной.
Если не получено от соседа никакого значения атрибута, через посредство объектов REQUEST или ACK, за оговоренное число hello_intervals, тогда узел должен предположить, что он не может связаться с соседом. Значение по умолчанию для этого числа равно 3.5.
Когда канал разорван или предполагается, что разорван, как это описано выше, узел может заново послать HELLO. Если узел не выполнил повторную инициализацию он должен использовать значение Src_Instance отличное от предложенного в предыдущем сообщении HELLO. Это новое значение должно посылаться соответствующим соседям до тех пор, пока не случится сброс или повторная загрузка или пока не будет зарегистрирован новый отказ канала. Если новое значение атрибута от соседа не получено, тогда узел должен установить значение поля Dst_instance равным нулю.
5.4. Соображения по поводу многоканальности
Как отмечалось ранее, расширение Hello имеет целью детектирование отказов узлов. Когда между соседними узлами имеется только один канал или когда все каналы между узлами отказали, отличие между отказами узла и канала не играют большой роли и обработка таких отказов уже рассмотрена. Когда между соседями имеется несколько каналов, нужно рассмотреть дополнительные обстоятельства. Когда каналы между соседями пронумерованы, тогда Hello должны быть посланы по всем каналам и далее применен алгоритм, рассмотренный выше.
Когда каналы ненумерованы, для детектирования отказов каналов нужно привлечь некоторые дополнительные средства помимо Hello. Каждый узел должен использовать один обмен Hello с соседом. Случай, когда все каналы отказали, эквивалентен варианту неполучения никаких данных, рассмотренному в предыдущем разделе.
5.5. Совместимость
Расширение Hello не влияет на обработку других сообщений RSVP. Единственное воздействие заключается в том, что отказ узла или канала становится известен раньше. RSVP-отклик в этом случае не изменяется.
Расширение Hello обладает полной обратной совместимостью. Классу Hello присвоено значение в форме 0bbbbbbb. В зависимости от реализации, программа, которая не поддерживает расширение, либо отбрасывает сообщения Hello либо откликается сигналом ошибки "Unknown Object Class" (неизвестный класс объекта). В любом случае отправитель не получит подтверждения на посланное Hello.
6. Соображения безопасности
На практике эти расширения RSVP не предлагают никакой безопасности в дополнение к RFC 2205 [1]. Однако имеется небольшое изменение в доверительной модели. Трафик обычной RSVP сессии может быть отфильтрован по адресам отправителя и получателя, а также по номерам портов. В этой спецификации, отбор происходит только на основе входных меток. По этой причине администрация может пожелать ограничить область, где могут прокладываться LSP-туннели. Это может быть выполнено путем фильтрации по разным портам, чтобы препятствовать воздействию на сообщение RSVP path со стороны объекта SESSION типа LSP_TUNNEL_IPv4 (7) или LSP_TUNNEL_IPv6 (8).
7. Соображения IANA
IANA присвоила значения протокольным параметрам RSVP. В данном документе определены объекты EXPLICIT_ROUTE и ROUTE_RECORD. Каждый из этих объектов содержит субобъекты. В этом разделе определены правила присвоения кодов субобъектам. Здесь используется терминология BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [15].
Тип субобъекта EXPLICIT_ROUTE
Тип субобъекта EXPLICIT_ROUTE является 7-битовым числом, которое идентифицирует функцию субобъекта. Ограничений на диапазон не накладывается. Могут быть присвоены любые доступные значения.
Следующие разновидности политики рассмотрены в [15], типы субобъектов в диапазоне 0 - 63 (0x00 - 0x3F) присвоены в результате консенсуса IETF, коды в диапазоне 64 - 95 (0x40 - 0x5F) выделены для типов субобъектов “первым пришел - первым обслужен”, а коды в диапазоне 96 - 127 (0x60 - 0x7F) зарезервированы для частного применения.
Тип субобъекта ROUTE_RECORD
Тип субобъекта ROUTE_RECORD является 8-битовым числом, которое идентифицирует функцию субобъекта. Ограничений на диапазон не накладывается. Могут быть присвоены любые доступные значения.
Следующие разновидности политики рассмотрены в [15], типы субобъектов в диапазоне 0 - 127 (0x00 - 0x7F) присвоены в результате консенсуса IETF, коды в диапазоне 128 - 191 (0x80 - 0xBF) выделены для типов субобъектов “первым пришел - первым обслужен”, и диапазон кодов 192 - 255 (0xC0 - 0xFF) зарезервирован для частного применения. В данном документе сделаны следующие присвоения.
7.1. Типы сообщений
Номер сообщения | Имя сообщения Name |
20 | Hello |
7.2. Коды классов и C-типы
Номер класса | Имя класса |
1 | SESSION |
Типы классов или C-типы:
7 LSP туннель IPv4
8 LSP туннель IPv6
10 FILTER_SPEC
Типы классов или C-типы:
7 LSP туннель IPv4
8 LSP туннель IPv6
11 SENDER_TEMPLATE
Типы классов или C-типы:
7 LSP туннель IPv4
8 LSP туннель IPv6
16 RSVP_LABEL
Типы классов или C-типы:
1 Тип 1 Label
19 LABEL_REQUEST
Типы классов или C-типы:
1 Without Label Range
2 With ATM Label Range
3 With Frame Relay Label Range
20 EXPLICIT_ROUTE
Типы классов или C-типы:
1 Тип 1 Explicit Route
21 ROUTE_RECORD
Типы классов или C-типы:
1 Тип 1 Route Record
22 HELLO
Типы классов или C-типы:
1 Запрос
2 Отклик
207 SESSION_ATTRIBUTE
Типы классов или C-типы:
1 LSP_TUNNEL_RA
7 LSP туннель
7.3. Коды ошибок и глобально определенные субкоды ошибок
Ниже приведен список, расширяющий перечень кодов и значений ошибок, которые определены в [RFC2205].
Код ошибки | Значение |
24 | Проблема маршрутизации Этот код ошибки имеет следующие глобально определенные значения субкодов ошибок: 1 | Bad EXPLICIT_ROUTE object (плохой объект EXPLICIT_ROUTE) | 2 | Bad strict node (плохой строгий узел) | 3 | Bad loose node (плохой свободный узел) | 4 | Bad initial subobject (плохой исходный субобъект) | 5 | No route available toward destination (нет маршрута до адресата) | 6 | Unacceptable label value (неприемлемое значение метки) | 7 | RRO indicated routing loops (обнаружены петли маршрута) | 8 | MPLS being negotiated, but a non-RSVP-capable router stands in the path (Согласовывался MPLS, но на пути оказался маршрутизатор без поддержки RSVP) | 9 | MPLS label allocation failure (Ошибка присвоения метки MPLS) | 10 | Unsupported L3PID ( Неподдерживаемый L3PID) |
|
25 | Notify Error (Внимание) Этот код ошибки имеет следующие глобально определенные значения субкодов ошибок: 1 | RRO слишком велик для MTU | 2 | RRO Notification (уведомление) | 3 | Tunnel locally repaired (туннель восстановлен локально) |
|
7.4. Определения субобъектов
Субобъекты объекта EXPLICIT_ROUTE с C-типом 1:
1 префикс IPv4
2 префикс IPv6
32 Номер автономной системы
Субобъекты объекта RECORD_ROUTE с C-типом 1:
1 адрес IPv4
2 адрес IPv6
3 Метка
8. Ссылки
[1] | Braden, R., Zhang, L., Berson, S., Herzog, S. и S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. |
[2] | Rosen, E., Viswanathan, A. и R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. |
[3] | Awduche, D., Malcolm, J., Agogbua, J., O'Dell и J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999. |
[4] | Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. |
[5] | Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. и A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. |
[6] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
[7] | Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992. |
[8] | Nichols, K., Blake, S., Baker, F. и D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 и IPv6 Headers", RFC 2474, December 1998. |
[9] | Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000. |
[10] | Awduche, D., Hannan, A. и X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels", RFC 3210, December 2001. |
[11] | Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. |
[12] | Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. |
[13] | Mogul, J. и S. Deering, "Path MTU Discovery", RFC 1191, November 1990. |
[14] | Conta, A. и S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998. |
[15] | Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. |
[16] | Bernet, Y., Smiht, A. и B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000. |
Назад: 4.4.23. Поддержка дифференцированных услуг многопротокольной системой коммутации по меткам (MPLS, RFC-3270)
Оглавление: Телекоммуникационные технологии
Вперёд: 4.4.25. Спецификация LDP
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
