Инспектор
Вы можете этот курс.
Опубликован: 28.09.2007 | Уровень: специалист | Доступ: платный
Лекция 12:
Спецификация LDP, RSVPTE, GMPLS
Процедуры привязки ресурсов
Классы ресурсов и привязки классов ресурсов описаны в [3]. Классы ресурсов могут быть ассоциированы с каналами и объявляться в протоколах маршрутизации. Привязка класса ресурса используется RSVP двумя путями. Для того, чтобы канал был признан работающим, он должен пройти три теста. Если тест не прошел, следует послать PathErr с кодом ошибка управления политикой.
Когда рассматривается новый запрос резервирования для строгого узла в ERO, узел может проверить привязку ресурса к классу ресурса этого канала. Когда выбирается канал, чтобы расширить свободный узел ERO, узел должен проверить привязку классов ресурсов этих каналов к ресурсам. Если не удается найти приемлемого канала для расширения ERO, узел должен послать сообщение PathErr с кодом ошибки Проблема маршрутизации и значением ошибки нет доступного маршрута до адресата. Для того, чтобы быть подтвержденным, маршрут должен пройти следующие три теста.
Чтобы точно описать тесты, используем определения объектов, представленные выше. Определяется также
Linkattr 32-битовый вектор, представляющий собой атрибуты, ассоциированные с каналом
Осуществляются три проверки.
- Исключает любой
Эта проверка исключает канал из рассмотрения, если он характеризуется одним из атрибутов набора. (linkattr & excludeany) == 0
- Включает любой т тест воспринимает канал, если он характеризуется любым атрибутом из набора. (includeany == 0) | ((linkattr & includeany) != 0)
- Включает все т тест воспринимает канал, если только он характеризуется всеми атрибутами из набора. (includeall == 0) | (((linkattr & includeall) ^ includeall) == 0)
Для канала, который будет воспринят, все три теста должны пройти успешно. Если тест не прошел, узел должен послать сообщение PathErr с кодом ошибки Проблема маршрутизации и значением ошибки нет приемлемого маршрута до адресата.
Если сообщение Path содержит несколько объектов SESSION_ATTRIBUTE, только первый объект имеет смысл. Последующие объекты SESSION_ATTRIBUTE могут игнорироваться и не должны переадресовываться.
Все маршрутизаторы RSVP, вне зависимости от того, поддерживают ли они объект SESSION_ATTRIBUTE или нет, должны переадресовать объект, не модифицируя. Присутствие маршрутизаторов без поддержки RSVP в любой области между отправителями и получателями не оказывает влияния на этот объект.
Расширение Hello
Расширение RSVP Hello позволяет узлам RSVP детектировать, когда соседний узел недоступен. Механизм предоставляет возможность поузлового детектирования отказа. Когда такой отказ детектирован, он обрабатывается так же, как и отказ канального уровня. Этот механизм предназначен для использования, когда нет уведомления об отказе канала и не применяются ненумерованные каналы или когда механизмы детектирования отказов, предоставляемые канальным уровнем, недостаточны для своевременного детектирования отказов узлов.
Следует заметить, что регистрация отказа узла не совпадает с механизмом детектирования отказа канала, в частности, в случае нескольких параллельных ненумерованных каналов. Расширение Hello специально сконструировано так, что можно использовать или не использовать этот механизм. Детектирование отказа соседа может быть запущено в любое время. Сюда входит ситуация, когда соседи узнают впервые друг о друге или когда соседи совместно используют состояния Resv или Path.
Расширение Hello состоит из сообщения Hello, объектов HELLO REQUEST и HELLO ACK. Обработка Hello двумя соседями поддерживает независимый выбор обычно конфигурируемых интервалов детектирования отказов. Каждый сосед может автономно формировать объекты HELLO REQUEST. Получение каждого запроса подтверждается. Сообщения Hello содержат также достаточно информации, так что один сосед может подавить посылку запросов Hello и все же выполнить детектирование отказа соседа. Сообщение Hello может быть включено в виде составной части в блочное сообщение.
Детектирование отказа соседа выполняется путем получения и запоминания атрибута соседа. Если зарегистрировано изменение значения или если сосед некорректно сообщает локально объявленное значение, тогда сосед предполагается отключенным. Когда обнаружено, что атрибут соседа изменился или связь с соседом потеряна, тогда значение атрибута говорит об изменении соседа. Объекты HELLO предоставляют механизм посылки запросов и предоставления значения атрибута. Запрос регистрации включает также значение атрибута отправителя. Это позволяет получателю регистрации опционно обрабатывать эти данные как неявный отклик на регистрацию. Такая опционная обработка является оптимизацией, которая может уменьшить полное число запросов и откликов, обработанных парами соседей. Во всех случаях, когда обе стороны поддерживают оптимизацию, результатом будет только набор запросов и откликов за интервал детектирования отказа. В зависимости от выбранных интервалов, можно получить выигрыш, даже когда только один сосед поддерживает оптимизацию.
Формат сообщения Hello
Сообщениями Hello всегда обмениваются только RSVP соседи. Адрес IP-отправителя равен IP-адресу узла-отправителя. IP-адрес места назначения равен IP-адресу соседнего узла.
Механизм HELLO предназначен для использования только непосредственными соседями. Когда обмен сообщениями HELLO осуществляют соседи, поле IP TTL всех исходящих сообщений HELLO следует устанавливать равным 1.
Сообщение Hello имеет тип Msg равный 20. Формат сообщения Hello показан ниже.
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>Форматы объекта HELLO
Код класса HELLO = 22. Определено два C_типа.
Объект HELLO REQUEST
Класс = HELLO, C_тип = 1
Объект содержит атрибут отправителя (32 бита) и атрибут получателя (32 бита).
Объект HELLO ACK
Класс = HELLO, C_тип = 2
Объект HELLO ACK содержит 32-битный атрибут отправителя Src_Instance и 32-битный атрибут получателя Dst_Instance. Значение должно измениться, если отправитель отключился, когда узел перезагружается или когда связь с узлом-соседом оборвалась, в противном случае значение остается неизменным. Это поле не должно иметь значения нуль.
Значение атрибута Src_Instance равно атрибуту отправителя, полученному последним. Это поле должно равняться нулю, до тех пор, пока ничего от соседа не получено.
Использование сообщения 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 равным нулю.
Соображения по поводу многоканальности
Как отмечалось ранее, расширение Hello имеет целью детектирование отказов узлов. Когда между соседними узлами имеется только один канал или когда все каналы между узлами отказали, отличие между отказами узла и канала не играют большой роли и обработка таких отказов уже рассмотрена. Когда между соседями имеется несколько каналов, нужно рассмотреть дополнительные обстоятельства. Когда каналы между соседями пронумерованы, тогда Hello должны быть посланы по всем каналам и далее применен алгоритм, рассмотренный выше.
Когда каналы не нумерованы, для детектирования отказов каналов нужно привлечь некоторые дополнительные средства помимо Hello. Каждый узел должен использовать один обмен Hello с соседом. Случай, когда все каналы отказали, эквивалентен варианту неполучения никаких данных, рассмотренному в предыдущем разделе.
12.2. Обобщенная мультипротокольная коммутация по меткам (GMPLS)
Введение
Архитектура протокола MPLS [RFC-3031] была определена для переадресации пакетов на основе меток. В этой архитектуре предполагалось, что маршрутизаторы LSR (Label Switching Router) могут:
- распознавать границы пакетов или ячеек, и
- обрабатывать заголовки пакетов (для LSR, способных распознавать границы пакетов) или заголовки ячеек (для LSR, способных распознавать границы ячеек).
Исходная архитектура теперь распространена на LSR, которые не могут распознавать ни границы пакетов, ни границы ячеек и, следовательно, не могут переадресовать данные на основе информации, содержащейся в заголовках пакетов или ячеек. Такие LSR, в частности, включают в себя устройства, где решение о переадресации принимается на основе временного домена, длины волны или номера физического порта. Рассмотренная ниже технология является следующим поколением средств телекоммуникаций (см. также RFC-4003, -4139, -4202, -4206, -4208, -4427, -4257, -4258, -4328, -4397, -4426, -4428, -4783).
Подобные LSR или, точнее, интерфейсы LSR могут быть отнесены к следующим классам.
- Интерфейсы, которые распознают границы пакетов/ячеек и могут переадресовать данные с учетом содержимого заголовка пакета/ячейки. Примерами могут служить интерфейсы маршрутизаторов, которые переадресуют данные на основе содержимого промежуточных заголовков, или интерфейсы ATM-LSR, которые переадресуют данные на основе VPI/VCI (ATM). Такие интерфейсы считаются способными коммутировать пакеты (PSC PacketSwitch Capable).
- Интерфейсы, которые переадресуют данные на основе циклических временных доменов. Примером такого интерфейса является соединение SONET/SDH. Такие интерфейсы считаются мультиплексирующими по времени (TDM).
- Интерфейсы, переадресующие данные на основе длины волны, на которой данные получены. Примером такого интерфейса является оптические коммутаторы, которые работают на уровне длин волн. Такие интерфейсы считаются ?переключателями LSC (Lambda Switch Capable).
- Интерфейсы, которые переадресуют данные на основе положения данных в реальном физическом пространстве. Примером такого интерфейса является оптическое подключение, которое работает на уровне одного (или нескольких) волокон. Такие интерфейсы считаются оптическими переключателями FSC (FiberSwitch Capable).
Использование концепции вложенных путей с коммутацией по меткам (LSP — Label Switching Path) позволяет системе масштабировать построение иерархии переадресаций (см. RFC-3471, L. Berger, январь 2003). На верху этой иерархии находятся интерфейсы FSC, далее следуют интерфейсы LSC, затем TDM, и, наконец, PSC. Таким образом, LSP, который имеет на входе и выходе интерфейс PSC, может образовывать цепи вложения с другими LSP, формируя LSP, который начинается и завершается интерфейсом TDM. Этот LSP, в свою очередь, может вкладываться (вместе с другими LSP) в LSP, который начинается и завершается интерфейсом LSC, который, в свою очередь, вкладывается совместно с другими путями в LSP, начинающийся и завершающийся интерфейсом FSC.
Установление LSP, который покрывает только первый класс интерфейсов, определено в RFC-3036, RFC-3212 и RFC-3209. Ниже предлагается функциональное описание расширений, которые необходимы для обобщения MPLS в направлении поддержки каждого из четырех классов интерфейсов. Форматы, специфические для протокола, определены в RFC-3473 и RFC-3472.
Обзор
Обобщенный MPLS отличается от традиционного тем, что он поддерживает много типов коммутации, т.е., TDM, ?, волоконную коммутацию. Поддержка дополнительных видов коммутации вынуждают обобщенный протокол MPLS расширить некоторые базовые функции MPLS и, в некоторых случаях, добавить новые функции. Эти изменения и дополнения оказывают влияние на то, как осуществляются запросы и транспортировка меток, как пересылаются сообщения об ошибках и как выполняется синхронизация на входе и на выходе.
В традиционном управлении трафиком MPLS (TE), каналы, через которые проходит LSP, могут содержать сегменты с разной кодировкой меток. Например, LSP может содержать каналы, соединяющие маршрутизаторы, каналы между маршрутизаторами и ATM-LSR, и каналы между ATM-LSR. Обобщенный MPLS осуществляет расширение функциональности путем включения каналов, где метка кодируется как временной домен, длина волны или позиция в физическом пространстве, например, номер волокна. Так же, как и в традиционном протоколе MPLS TE, где не все LSR могут распознавать границы IP-пакетов (например, ATM-LSR), обобщенный MPLS включает в себя поддержку LSR, которые не распознают границ IP-пакетов. В традиционном пути MPLS TE, который транспортирует IP, маршрут должен начинаться и завершаться в маршрутизаторе. Обобщенный MPLS требует, чтобы LSP начинался и завершался в LSR того же типа. Кроме того, в обобщенном протоколе MPLS тип данных, который транспортируется через LSP, может включать в себя SONET/SDH, GE или 10-Гбитный Ethernet. Эти изменения традиционного MPLS отражаются в механизме запроса и переноса меток.
Другим базовым отличием традиционного и не-PSC типа обобщенного LSP MPLS, является то, что полоса пропускания выделяется для LSP дискретными порциями. Заметим, что использование FA (Forwarding Adjacencies, смотри [MPLS-HIERARCHY]), предоставляет механизм, который может улучшить использование полосы пропускания, когда выделение полосы осуществляется дискретным образом, а также механизм агрегатирования состояния переадресации, что может сократить требуемое число меток.
Обобщенный MPLS допускает возможность предложения метки вышестоящим узлом. Это предложение может быть отвергнуто нижестоящим узлом, за счет увеличения времени установления LSP. Предлагаемая метка представляет ценность, когда LSP устанавливается через определенное оптическое оборудование, где конфигурирование системы коммутации может быть долгим. Например, микрозеркала могут быть подняты или удалены, и это физическое перемещение и последующее установление потребует времени. Если метки и, следовательно, оптическая система коммутации сконфигурированы в обратном порядке (что является нормой), может потребоваться задержать сообщение MAPPING/Resv на десятки миллисекунд на один шаг, чтобы установить маршрут переадресации. Предлагаемая метка может быть полезной также при восстановлении в случае отказа узла.
Обобщенный MPLS расширяет понятие ограничения диапазона меток, которые могут быть выбраны нижестоящим узлом. В обобщенном MPLS, входной или другой вышестоящий узел может ввести ограничения на метки, которые могут быть использованы в LSP. Эта особенность пришла из оптической области, где бывают случаи, когда длины волн, используемые в пределах маршрута, должны быть ограничены узким диапазоном или даже одной длиной волны. Это требование возникает из-за того, что некоторое оборудование может работать с ограниченным набором длин волн, а некоторые промежуточные устройства не могут вообще выполнять коммутацию по длинам волн.
В то время как традиционный трафик, формируемый MPLS, является однонаправленным, обобщенный MPLS поддерживает установление двунаправленных LSP. Необходимость двунаправленных LSP вызвана не-PSC приложениями (PSC=PacketSwitch Capable). Существует много причин, почему нужны такие LSP, — в частности, конкуренция за ресурсы при формировании LSP с привлечением разных сигнальных сессий и упрощение процедур восстановления при ошибках в случае не-PSC. Двунаправленные LSP имеют также преимущества малой задержки установления канала и малого числа сообщений при реализации этого процесса.
Обобщенный MPLS поддерживает специфические метки для специальных интерфейсов. В документе RFC-3473 рассмотрены также специальные механизмы RSVP для быстрого уведомления об ошибках.
Обобщенный MPLS формализует возможное разделение каналов управления и данных. Такая поддержка особенно важна для технологий, где управление трафиком не может осуществляться в рамках информационного потока.
Форматы, относящиеся к меткам
Для расширения области применения MPLS в сферу оптики и временных доменов, необходимо несколько новых форм меток. Эти новые формы меток называются обобщенными метками. Обобщенная метка содержит достаточно информации, чтобы позволить принимающему узлу программировать коммутацию вне зависимости от типа этого соединения.
Заметим, что, так как узлы, посылающие и принимающие новые формы меток, знают, какой тип канала они используют, обобщенная метка не содержит поля тип, — вместо этого предполагается, что узлы знают из контекста, какие метки следует ожидать.
Обобщенные запросы меток
Запрос обобщенной метки поддерживает коммуникационные характеристики, необходимые для поддержки запрашиваемых LSP. Заметим, что эти характеристики могут быть использованы транзитными узлами, в частности, для поддержки извлечения предпоследнего шага.
Запрос обобщенной метки содержит параметр кодирования LSP, называемый типом кодирования LSP. Этот параметр указывает тип кодирования, скажем, SONET/SDH/GigE и т.д., который будет использоваться для данных, ассоциированных с LSP. Тип кодирования LSP характеризует природу LSP, а не природу каналов, через которые он проходит. Канал может поддерживать несколько форматов кодирования, где под поддержкой подразумевается то, что канал может транспортировать и коммутировать сигналы одного или более форматов кодирования в зависимости от доступных ресурсов и емкости канала. Например, рассмотрим LSP с управлением посредством ?кодирования. Ожидается, что такой LSP не поддерживает электронных преобразований, и ничего не известно о модуляции и быстродействии промежуточных узлов. Другие форматы обычно требуют знания структуры кадров и параметров полей.
Запрос обобщенной метки указывает также на тип коммутации, который запрашивается для канала. Это поле в нормальной ситуации согласуется со всеми сегментами LSP.
Информация, транспортируемая в обобщенном запросе метки, имеет формат, показанный на рис. 12.48:
Тип кодирования LSP: 8 бит
Указывает на запрашиваемый тип кодирования LSP. Ниже представлена таблица возможных значений этого поля (табл. 12.13).
ANSI PDH и ETSI PDH обозначают соответствующие сетевые технологии. DS1 и DS3 являются примерами ANSI PDH LSP. E1 LSP будет ETSI PDH. Тип кодирования Lambda относится к LSP, которые охватывают все длины волн. Тип кодирования волокно (Fiber) относится к LSP, работающим с оптоволоконным портом.
Тип коммутации: 8 бит
Указывает на тип коммутации, которая должна осуществляться в заданном канале. Это поле необходимо для каналов, которые анонсируют более одного типа коммутации; его следует связать с одним из значений, анонсированных для соответствующих каналов в описателе возможностей маршрутной коммутации (Switching Capability Descriptor, смотри [GMPLS-RTG]). В настоящее время определены следующие значения (табл. 12.14)
Обобщенный PID (G-PID): 16 бит
Идентификатор поля данных, транспортируемых через LSP, т.е., идентификатор уровня клиента данного LSP. Он применяется в конечных точках LSP и иногда предпоследним узлом. Стандартные значения Ethertype используются для пакета и Ethernet LSP; прочие значения перечислены в таблице 12.15.
, волокноКодирование полосы пропускания
Кодирование полосы пропускания осуществляется 32-битовым числом в формате IEEE для чисел с плавающей запятой (измеряется в байтах/сек). Для беспакетных LSP полезно определить дискретные величины, чтобы идентифицировать полосу LSP. Некоторые типичные значения для запрошенной полосы перечислены ниже. Дополнительные значения будут определяться по мере необходимости. Значения кодов полосы ассоциируются с протоколами, смотри в таблице 12.16 ([RFC-3473] и RFC-3472).
