Объект набора приемлемых меток
Объекты Acceptable_Label_Set используют номер класса 130 (в форме 10bbbbbb). Остальное содержимое объекта, включая C-тип, имеет идентичный формат с объектом Label_Set, смотри раздел 2.6.
Объекты Acceptable_Label_Set могут транспортироваться в сообщениях PathErr и ResvErr. Процедуры определения приемлемого списка меток (Acceptable Label Set) следуют за процедурами определения набора меток (Label Set), смотри раздел 2.6.1. В частности, приемлемый набор меток определяется из одного или нескольких объектов Acceptable_Label_Set. С помощью объектов действия нуль (0) и один (1), соответственно, могут быть добавлены или исключены специфические метки/субканалы из перечня приемлемых меток. С помощью объектов действия нуль (2) и один (3), соответственно, могут быть добавлены или исключены диапазоны меток/субканалов. Когда объекты Acceptable_Label_Set просто перечисляют метки/субканалы, подлежащие удалению. Это подразумевает, что все остальные метки являются приемлемыми.
Включение объектов Acceptable_Label_Set является опционным. Если он включен, сообщение PathErr или ResvErr должно содержать указание на "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Отсутствие объекта Acceptable_Label_Set не имеет никакого специального значения.
Объект обобщенной метки
Ниже представлен формат объекта обобщенной метки:
Описание параметров и кодирования меток смотри в [RFC3471].
Объект Out-Interface (OUT-Int)
Объект Out-Interface используется для идентификации выходного интерфейса, которому адресован запрос, и адреса, куда должен быть переправлено сообщение. Для потоков или сообщений, направляемых локальной ЭВМ PEP, используется обратный адрес и ifindex. Out-Interface >имеет те же форматы, что и объект In-Interface. Этот интерфейсный объект используется также для идентификации выходного интерфейса через его ifindex. Поле ifindex может быть использовано для отличия субинтерфейсов от ненумерованных интерфейсов (смотри, например, RSVP LIH). Когда PEP поддерживает SNMP, целое число ifindex должно соответствовать тому же целому числу для интерфейса в индексной интерфейсной таблице MIB-II.
Поле ifindex специфицированное в Out-Interface обычно связано с потоком протокольных сообщений. Поле ifindex определяет один из адресов, куда протокольное сообщение может быть переадресовано.
C-Num = 4
C-Type = 1, IPv4-адрес + интерфейс
Некоторые форматы C-типа выступают в качестве объекта In-Interface. IPv4-адрес специфицирует адрес, куда направлено исходящее сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II для PEP.
C-Type = 2, IPv6-адрес + интерфейс
Тот же формат C-типа, что и в случае объекта In-Interface. Для этого типа объекта интерфейса, адрес IPv6 специфицирует IP-адрес, которому адресовано исходящее сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II для PEP.
Объект предлагаемой метки
Формат объекта Suggested_Label аналогичен описанному для обобщенной метки. Он используется в сообщениях Path. Объект Suggested_Label использует номер класса 129 (в форме 10bbbbbb) и C-тип предлагаемой метки.
Ошибки в полученных объектах Suggested_Label должны игнорироваться. Это касается любых полученных несогласованных и неприемлемых значений.
Согласно [RFC3471], если в нижерасположенный узел приходит метка, которая отличается от предложенной сверху, вышестоящий LSR должен либо реконфигурироваться, либо отравлять сообщение ResvErr с указанием "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Кроме того, входной узел не должен передавать данные, используя предложенную метку до тех пор, пока нижерасположенный узел не пришлет соответствующую метку вверх.
Объект Reason
Этот объект специфицирует причину, почему состояние запроса было стерто. Объект появляется в запросах стирания (DRQ). Поле субкода причины зарезервировано для более подробного описания причины, специфической для клиента и описанной в соответствующих документах.
C-Num = 5, C-тип = 1
0
Код причины
Субкод (октет 2) содержит неизвестный C-Num объекта (октет 3) содержит неизвестный C-тип объекта
Объект 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 (без субобъектов) считается некорректным. В настоящее время определено три типа субобъектов.
Объект Restart_Cap
Объект Restart_Cap транспортируется в сообщении Hello. Объект Restart_Cap имеет формат:
Время перезагрузки: 32 бита
Время перезагрузки (повторного старта) измеряется в миллисекундах. Время повторного старта должно быть установлено равным сумме времени, необходимого отправителю объекта для перезапуска его компонента RSVP-TE (до точки, где он может обмениваться сообщениями RSVP Hello со своими соседями) и коммуникационного канала, который используется для RSVP коммуникаций. Значение 0xffffffff указывает, что рестарт управляющей функции отправителя может произойти через неопределенное время и что работа его информационной части не нарушена отказом в системе управления.
Время восстановления: 32 бит
Период времени, в миллисекундах, спустя которое отправитель хотел бы ресинхронизоваться с получателем состояния переадресации RSVP и MPLS после восстановления синхронизации Hello. Значение нуль указывает на то, что состояние переадресации MPLS не было сохранено при перезагрузке системы.
Класс = SESSION, LSP_TUNNEL_IPv6 C_тип = 8
Рис. 11.
4.6.2. Объект отправителя Template (шаблон)
4.6.2.1. Объект шаблона отправителя LSP_TUNNEL_IPv4
Класс = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-тип = 7
Рис. 12.
4.6.2.2. Объект шаблона отправителя LSP_TUNNEL_IPv6
Класс = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_тип = 8
Рис. 13.
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.
Объект Session
4.6.1.1. Объект сессии LSP_TUNNEL_IPv4
Класс = SESSION, LSP_TUNNEL_IPv4 C-тип = 7
Рис. 10.
IPv4 адрес конца туннеля
Объект специфической информации клиента (ClientSI)
Для запросов необходимы различные типы этого объекта, он используется в откликах и, когда необходимо, в процедурах open. Объект содержит специфическую информацию для клиента данного типа.
C-Num = 9,
C-Type = 1, Signaled ClientSI.
Поле переменной длины. Все объекты/атрибуты, специфичные для сигнального протокола клиента или внутреннего состояния, инкапсулируются в один или более информационных объектов, специфических для клиента. Формат данных, инкапсулированных в объект ClientSI, определяется типом клиента.
C-Type = 2, Именованный ClientSI.
Поле переменной длины. Содержит именованную конфигурационную информацию, полезную для передачи специфических данных о PEP, запросе, или сконфигурированном состоянии серверу PDP.
Класс = 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 для старого маршрута.
Объект тип отчета (Report-Type)
Тип отчета, соответствующий запросу состояния для данного дескриптора:
C-Num = 12, C-Type = 1
| 0 | 1 | 2 | 3 |
| P ALIGN="CENTER" style="font-family:arial;font-size:12pt">Report-Type | ///////////// | ||
Report-Type:
1 = Success : Решение было успешным для PEP 2 = Failure : Решение не могло быть реализовано PEP
3 = Accounting: Актуализация аккоунтинга для инсталлированного состояния.
Объект запроса метки
Класс запроса метки равен 19. В настоящее время существует три возможных значения C_Types. Тип 1 относится к запросам метки без диапазона значений. Тип 2 является запросом метки с диапазоном ATM. Тип 3 является запросом метки с диапазоном Frame Relay. Объект LABEL_REQUEST имеет форматы показанные ниже.
4.2.1. Запрос метки без указания диапазона
Класс = 19, C_Type = 1
Рис. 1
Зарезервировано
4.2.2. Запрос метки с диапазоном ATM
Класс = 19, C_Type = 2
Рис. 2.
Резерв
4.2.3. Запрос метки с диапазоном Frame Relay
Класс = 19, C_Type = 3
Рис. 3.
Len бит в DLCI
0 10
2 23
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].
Объект запроса обобщенной метки
Сообщение Path должно содержать специфический тип кодирования LSP (Label Switched Path - путь с коммутацией по меткам), чтобы гарантировать максимальную гибкость коммутации в транзитных LSR. Объект запроса обобщенной метки устанавливается входным узлом, передается без изменений транзитными узлами, и используется оконечным узлом. Поле тип коммутации может изменяться от шага к шагу. Формат объекта запроса обобщенной метки показан ниже:
Описание параметров смотри в [RFC3471].
Объект защиты
Использование объекта защиты является опционным. Объект включается для описания специфических атрибутов защиты LSP. Объект защиты использует номер класса 37 (в форма 0bbbbbbb). Объект защиты имеет формат:
Описания параметров смотри в [RFC3471].
Объекты IF_ID ERROR_SPEC
Формат объекта IPv4 IF_ID ERROR_SPEC имеет вид:
Формат объекта IPv6 IF_ID ERROR_SPEC имеет вид:
Описание адресов, флагов, кодов ошибок и значений поля ошибка можно найти в [RFC2205]. Описание параметров и кодирования TLV имеется в [RFC3471].
Объекты IF_ID RSVP_HOP
Формат объекта IPv4 IF_ID RSVP_HOP:
Формат объекта IPv6 IF_ID RSVP_HOP:
Описания адресов узлов и полей указателя смотри в [RFC2205]. Описания параметров и кодирование TLV содержится в [RFC3471].
Объекты предопределенных наборов
В этом контексте, который предполагает набор маршрутов (например, атрибут members класса route-set), номер автономной системы ASx определяет набор маршрутов, который исходит из Asx, а as-set AS-X определяет набор маршрутов, которые исходят из автономной системы AS-X. Маршрут p считается начинающимся в ASx, если существует маршрутный объект для p с ASx в качестве значения атрибута origin. Например, на рис. .15, набор маршрутов rs-special содержит маршруты 128.9.0.0/16, AS1 и AS2, а также маршруты автономных систем набора AS-FOO.
route-set: rs-special
members: 128.9.0.0/16, AS1, AS2, AS-FOO
Рис. .15. Использование номеров AS и маршрутных наборов.
Набор rs-any содержит все маршруты, зарегистрированные в IRR. Набор as-any содержит все AS, зарегистрированные в IRR.
Объекты сессии, шаблона отправителя и спецификации фильтра
Новые C-типы определены для объектов SESSION, SENDER_TEMPLATE и FILTER_SPEC.
Объекты LSP_TUNNEL имеют следующий формат:
Объекты, связанные с LSP туннелем 4.Объект 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 через разные интерфейсы, всегда считаются разными, даже если их значения идентичны.
Объекты запросов уведомления
Уведомления могут посылаться с помощью сообщений Notify, определенных ниже. Объект запроса уведомления используется для запроса генерации уведомления. Уведомление, т.e., посылка сообщения Notify, может быть запрошено как сверху, так и снизу LSP.
Обязательное соответствие EXP/PSC -->PHB
Поле EXP PSC PHB
000 DF > DF
000 CSn > CSn
001 AFn > AFn1
010 AFn > AFn2
011 AFn > AFn3
000 EF > EF
Обмен сообщениями LDP
Существует четыре категории сообщений LDP:
Сообщения выявления (Discovery), используются для объявления и поддержания присутствия LSR в сети. Сообщения сессий, используются для установления, поддержки и завершения сессий между LDP партнерами. Сообщения анонсирования (Advertisement), используются для формирования, изменения и ликвидации соответствия между меткой и FEC. Сообщения уведомления (Notification), используются для предоставления рекомендаций и уведомления об ошибках.
Сообщения выявления предоставляют механизм, посредством которого LSR оповещает о своем присутствии в сети посредством периодической посылки сообщения Hello. Оно посылается в виде UDP-пакета на вход LDP-порта всем маршрутизаторам субсети через групповой мультикастинг-адрес. Когда LSR решает установить сессию с другим LSR, опознанным с помощью сообщения Hello, он использует процедуру инициализации LDP с привлечением протокола TCP. При успешном завершении процедуры инициализации, два LSR становятся LDP-партнерами, и могут обмениваться сообщениями анонсирования.
Момент запроса или анонсирования метки партнеру, определяется локальными соображениями LSR. Вообще, LSR запрашивает метку у соседнего LSR, когда она ему нужна, и анонсирует метку соседнему LSR, когда он хочет, чтобы сосед использовал эту метку.
Корректная работа LDP требует надежной и упорядоченной доставки сообщений. Чтобы удовлетворить этим требованиям LDP использует в качестве транспортного протокола TCP для сообщений сессий, предупреждений и анонсирования; т.e., для любых обменов кроме механизмов выявления, базирующихся на UDP.
Обобщенная метка
Обобщенная метка расширяет функциональность традиционной метки, допуская представление не только меток, которые транспортируются соответствующими информационными пакетами, но также меток, которые идентифицируют временные домены, длины волн, или пространственное мультиплексирование по положению. Например, обобщенная метка может содержать данные, которые представляют (a) одно волокно из пучка, (b) один волновой диапазон в волокне, (c) одну длину волны из диапазона (или волокна), или (d) набор временных доменов для заданной длины волны (или волокна). Метка может также нести данные о базовой метке MPLS, метке Frame Relay, или метке ATM (VCI/VPI).
Обобщенная метка не идентифицирует класс, к которому принадлежит метка. Это определяется возможностями мультиплексирования канала, где используется метка.
Обобщенная метка несет в себе лишь метку одного уровня, т.е., она не является неиерархическим объектом. Когда требуется несколько уровней меток (LSP внутри LSP), каждый LSP должен быть сформирован отдельно, смотри [MPLS-HIERARCHY]. Каждый TLV-объект обобщенной метки несет в себе параметр метки переменной длины.
Обобщенные запросы меток
Запрос обобщенной метки поддерживает коммуникационные характеристики, необходимые для поддержки запрашиваемых LSP. Эти характеристики включают в себя кодирование LSP и поля данных LSP. Заметим, что эти характеристики могут быть использованы транзитными узлами, например, для поддержки извлечения предпоследнего шага.
Запрос обобщенной метки содержит параметр кодирования LSP, называемый тип кодирования LSP. Этот параметр указывает тип кодирования, например, SONET/SDH/GigE и т.д., который будет использоваться для данных, ассоциированных с LSP. Тип кодирования LSP характеризует природу LSP, а не природу каналов, через которые он проходит. Канал может поддерживать несколько форматов кодирования, где под поддержкой подразумевается то, что канал может транспортировать и коммутировать сигналы одного или более форматов кодирования в зависимости от доступных ресурсов и емкости канала. Например, рассмотрим LSP с управлением с помощью l -кодирования. Ожидается, что такой LSP не поддерживает электронных преобразований и ничего не известно о модуляции и быстродействии промежуточных узлов. Другие форматы обычно требуют знания структуры кадров и параметров полей.
Запрос обобщенной метки указывает также на тип коммутации, который запрашивается для канала. Это поле в норме согласуется со всеми сегментами LSP.
Обработка Diff-Serv TLV 6.4.Обработка Diff-Serv TLV в режиме Downstream Unsolicited
В данном разделе описываются операции режима Downstream Unsolicited. При выделении метки для E-LSP, который использует предварительно сконфигурированную таблицу соответствия EXP<-->PHB, ниже расположенный Diff-Serv LSR посылает сообщение ассоциации метки без Diff-Serv TLV.
При формировании метки для E-LSP, который использует согласованную таблицу EXP<-->PHB, ниже расположенный Diff-Serv LSR посылает сообщение ассоциации метки с Diff-Serv TLV для E-LSP, который содержит одну запись MAP, для каждого значения EXP, поддерживаемого для этого E-LSP.
При формировании метки для L-LSP, ниже расположенный Diff-Serv LSR посылает сообщение ассоциации метки с Diff-Serv TLV для L-LSP, содержащий класс обслуживания PHB (PSC), который нужно поддерживать в этом L-LSP. Предполагая, что формирование метки прошло успешно, нижестоящий и вышестоящий LSR должны:
актуализовать контекст Diff-Serv, ассоциированный со сформированными LSP и их ILM/FTN, как это специфицировано в предыдущих разделах (входная и выходная метки),
инсталлировать требуемый алгоритм переадресации Diff-Serv (форматирование трафика и схема отбрасывания пакетов) для этого NHLFE (выходная метка).
Вышестоящий Diff-Serv LSR, получив сообщение ассоциации метки с несколькими Diff-Serv TLV, рассматривает только первый. LSR должен игнорировать и не переадресовывать последующие Diff-Serv TLV.
Вышестоящий Diff-Serv LSR, получивший сообщение ассоциации метки с Diff-Serv TLV для E-LSP и не поддерживающий конкретное PHB, закодированное в одном или более записях MAP, должен отвергнуть эту метку, послав сообщение Label Release, которое содержит TLV метки и статус TLV со статусным кодом Unsupported PHB.
Вышестоящий Diff-Serv LSR, получив сообщение ассоциации метки с Diff-Serv TLV для E-LSP и определив, что согласованная таблица EXP<-->PHB некорректна, должен отвергнуть эту метку, послав сообщение Label Release, которое содержит TLV метки и статус TLV со статусным кодом Invalid EXP<--> PHB mapping. Согласованная таблица EXP <-->PHB в объекте DIFFSERV для E-LSP некорректна, если:
поле MAPnb находится вне диапазона 1 - 8, или
данное значение EXP присутствует более одного раза в одной записи MAP, или
кодирование PHBID некорректно
Вышестоящий Diff-Serv LSR, получив сообщение ассоциации метки с Diff-Serv TLV для L-LSP, содержащий значение PSC, которое не поддерживается, должен отвергнуть эту метку, послав сообщение Label Release, которое содержит TLV метки и статус TLV со статусным кодом Unsupported PSC.
Обработка Diff-Serv TLV в режиме Downstream on Demand
В этом разделе описаны операции, используемые в режиме Downstream on Demand. При запросе метки для E-LSP, который использует предварительно сконфигурированную таблицу EXP<-->PHB, вышестоящий Diff-Serv LSR посылает сообщение Label Request без Diff-Serv TLV.
При запросе метки для E-LSP, который использует согласованную таблицу EXP<-->PHB, вышестоящий Diff-Serv LSR посылает сообщение Label Request с Diff-Serv TLV для E-LSP, которое содержит по одной записи MAP для каждого значения EXP, поддерживаемого в этом E-LSP.
При запросе метки для L-LSP, вышестоящий Diff-Serv LSR посылает сообщение Label Request с Diff-Serv TLV для L-LSP, содержащее PSC, который следует поддерживать в этом L-LSP.
Нижестоящий Diff-Serv LSR, посылая сообщение Label Mapping в ответ на запрос метки для E-LSP или L-LSP не должен включать Diff-Serv TLV в это сообщение ассоциации метки. Предполагая формирование метки успешным, нижестоящий и вышестоящий LSR должны:
актуализовать контекст Diff-Serv, ассоциированный со сформированными LSP в их ILM/FTN, как это указано в предыдущих разделах (входящая и исходящая метки),
инсталлировать требуемую обработку переадресации Diff-Serv (формирование трафика и политика отбрасывания) для этого NHLFE (исходящая метка).
Вышестоящий Diff-Serv LSR, получая в ответ на запрос метки сообщение Label Mapping, содержащее Diff-Serv TLV, должен отклонить ассоциацию метки, послав сообщение Label Release, содержащее TLV метки и статус TLV со статусным кодом Unexpected Diff-Serv TLV.
Нижестоящий Diff-Serv LSR, получая сообщение Label Request с несколькими Diff-Serv TLV, принимает во внимание только первый из них. LSR должен игнорировать и не переадресовывать последующие Diff-Serv TLV.
Нижестоящий Diff-Serv LSR, который получает сообщение Label Request с Diff-Serv TLV для E-LSP и не поддерживает конкретное PHB, записанное в одном (или более) записей MAP, должен отвергнуть запрос, послав сообщение со статусным кодом Unsupported PHB.
Нижестоящий Diff-Serv LSR, получив сообщение Label Request с Diff-Serv TLV для E-LSP и определив, что согласованная таблица EXP <-->PHB некорректна, должен отвергнуть запрос, послав сообщение Notification, которое включает в себя статус TLV со статусным кодом Invalid EXP<-->PHB mapping. Согласованная таблица EXP<-->PHB в DIFFSERV TLV для E-LSP является некорректной, если:
поле MAPnb вне диапазона 1 - 8, или
данное значение EXP присутствует более одного раза в записи MAP, или
кодировка PHBID некорректна.
Нижестоящий Diff- Serv LSR, получая сообщение Label Request с Diff-Serv TLV для L-LSP, содержащее значение PSC, которое не поддерживается, должен отвергнуть запрос, послав сообщение Notification которое включает в себя TLV со статусным кодом Unsupported PSC.
Нижестоящий Diff-Serv LSR, который распознает тип Diff-Serv TLV Type в сообщении Label Request, но не может предоставить необходимую для каждого LSP контекстную информацию, должен отвергнуть запрос, послав сообщение Notification, которое включает в себя статус TLV со статусным кодом Per-LSP context allocation failure.
Нижестоящий Diff-Serv LSR, который распознает тип Diff-Serv TLV в сообщении Label Request и поддерживает запрошенный PSC, но не способен удовлетворить запрос метки по другим причинам (например, нет доступной метки), должен послать сообщение Notification в соответствии с существующими процедурами LDP [LDP] (например, со статусным кодом No Label Resource). Это сообщение Notification должно включать в себя запрошенный Diff-Serv TLV.
Обработка объекта Restart_Cap
Узлы, поддерживающие восстановление состояния, анонсируют эту способность, транспортируя объект Restart_Cap в сообщениях Hello. Такие узлы должны включать объекты Restart_Cap во все сообщения Hello. (Заметим, что это касается сообщений Hello, содержащих объекты ACK.) Когда узел получает сообщение Hello с объектом Restart_Cap, он должен записать значения полученных параметров.
Обработка ошибок LDP
Предупреждение партнеров об ошибках LDP и других событиях осуществляется с помощью сообщений уведомления. Существует два сорта сообщений уведомления:
Уведомления об ошибке, используются, чтобы предупредить о фатальных сбоях. Если LSR получает от партнера уведомление об ошибке для конкретной LDP сессии, он завершает 'ne сессию, закрывая транспортное TCP соединение и ликвидируя все ассоциации меток, полученные за время этой сессии.
Сообщения-рекомендации используются для передачи LSR-информации о LDP сессии или статусе некоторых полученных ранее сообщений.
Обработка отказов
Имеется два новых отказа, которые должны обрабатываться, когда канал управления независим от канала данных. В первом, существует канальный или другой тип отказа, который ограничивает возможность соседних узлов передавать сообщения управления. В такой ситуации, соседние узлы в течение некоторого времени не могут обмениваться управляющими сообщениями. Как только связь восстановится, нижележащий управляющий протокол должен сигнализировать, что узлы сохранили свое состояние во время отказа. Управляющий протокол должен также гарантировать, что любое изменение состояния, произошедшее за время отказа, произошло синхронно для всех вовлеченных узлов.
Во втором варианте управление узлов отказывает и затем стартует снова, при этом оказывается потерянной большая часть статусной информации. В этом случае, вышестоящий и нижестоящий узлы должны синхронизовать свою статусную информацию со стартующим узлом. Для того чтобы ресинхронизация стала возможной, стартующий узел нуждается в сохранении некоторых данных, таких как соответствие входящих и исходящих меток.
Заметим, что эти случаи применимы, когда имеются механизмы детектирования отказов канала данных независимо от отказов канала управления.
Обработка двух типов отказов в системе управления рассмотрены ниже. Первый, связан с отказами узлов, и относится к случаю, когда узел теряет свое состояние управления (напр., после повторного старта), но не теряет своего состояния переадресации данных. Второй связан с отказом в канале управления, и относится к случаю, когда между узлами потеряно управляющее соединение. Обработка обоих отказов поддерживается объектом Restart_Cap, определенным ниже и требующим использования сообщений Hello. Заметим, что, объект Restart_Cap не должен посылаться, когда нет механизма разделения отказов каналов данных и управления.
Общие операции 4.Согласование уровня безопасности и номера по порядку
Безопасность сообщения COPS согласуется один раз на соединение и работает для всего последующего обмена через это соединение. Если требуется определенный уровень безопасности COPS, он должен быть согласован во время начального обмена сообщениями Client-Open/Client-Accept, специфицирующего тип клиента равный нулю (который зарезервирован для согласования уровня соединения и верификации соединения).
Если PEP не конфигурировался для использования средств безопасности COPS, он просто пошлет PDP сообщения Client-Open для поддерживаемых типов клиента, как это задано в разделе 4.3 и не будет включать объект Integrity в какие-либо сообщения COPS.
В противном случае, средства безопасности могут быть инициализированы PEP, если он посылает PDP сообщение Client-Open с Client-Type=0 до открытия любого другого типа клиента (Client-Type). Если PDP получает Client-Open с Client-Type=0, после того как другой тип клиента уже успешно открыт, он должен прислать сообщение Client-Close (для Client-Type=0) к PEP. Это первое сообщение Client-Open должно специфицировать Client-Type=0 и должно предоставить объекты PEPID и COPS Integrity. Этот объект Integrity будет содержать начальный порядковый номер, который PDP должен инкрементировать в дальнейшем, после исходного обмена Client-Open/Client-Accept и Key ID, идентифицирующего алгоритм и ключ, которые используются для вычисления дайджеста.
Аналогично, если PDP принимает ключ безопасности PEP и алгоритм путем проверки дайджеста сообщения с использованием идентифицированного ключа, PDP должен послать PEP сообщение Client-Accept с Client-Type =0, содержащего объект Integrity. Этот объект Integrity будет включать исходный порядковый номер, идентификатор ключа (Key ID), задающий ключ и алгоритм, использованные для вычисления дайджеста.
Если PEP, от перспективного PDP, который требует безопасности, потерпит неудачу или вообще не выполнит согласование требований безопасности, не послав исходное сообщение Client-Open с Client-Type=0, содержащее корректный объект Integrity, PDP должен послать PEP сообщение Client-Close с Client-Type=0, специфицирующее соответствующий код ошибки. Аналогично, если PDP, в процессе диалога с PEP, который требует безопасности, не выполнил согласования параметров, не послав сообщение Client-Accept со значением Client-Type=0 и корректным объектом Integrity, PEP должен послать PDP сообщение Client-Close со значением Client-Type=0, специфицируя соответствующий код ошибки. Такое сообщение Client-Close не должно нести в себе объект integrity (так как согласование безопасности еще не завершено).
Инициализация безопасности может потерпеть неудачу по одной из следующих причин:
| 1. |
Партнер, получающий сообщение требует обеспечения уровня безопасности COPS, но объект Integrity не прислан.
Раз начальное согласование уровня безопасности завершено, PEP знает, какие порядковые номера ожидает PDP, а PDP знает, какие порядковые номера ожидает PEP. Все сообщения COPS должны включать согласованный объект Integrity, специфицирующий корректный порядковый номер с соответствующий дайджест сообщения (включая сообщения Client-Open/Client-Accept для специфических типов клиента). Все последующие сообщения от PDP к PEP должны вызывать инкрементацию порядкового номера, осуществляемую PEP в объекте Integrity исходного сообщения Client-Open. Аналогично, все последующие сообщения от PEP к PDP должны вызывать инкрементацию порядкового номера, осуществляемую PDP в объекте Integrity исходного сообщения Client-Accept. Порядковые номера увеличиваются на 1, начиная с исходного значения. Например, если порядковый номер задан для PEP в исходном сообщении Client-Accept равным 10, следующее сообщение PEP посылаемое к PDP, предоставит объект Integrity с порядковым номером 11. Следующее сообщение, которое посылает PEP в направлении PDP, будет иметь порядковый номер 12 и т.д. Если любое последующее сообщение содержит неверный порядковый номер, неопределенный Key ID, некорректный дайджест сообщения, или не имеет объекта Integrity при условии, что параметры безопасности согласованы, то для Client-Type=0 должно быть сгенерировано сообщение Client-Close, содержащее корректный объект Integrity, где специфицируется соответствующий код ошибки. После этого соединение должно быть разорвано.
Общие принципы работы
Для данного FEC и, если не наложено каких-либо специфических условий, как указано в разделах 7, 8 и 9, данная спецификация допускает любую из ниже перечисленных комбинаций в сфере MPLS Diff-Serv: нуль или любое число E-LSP, инуль или любое число L-LSP.
Сетевой администратор выбирает действительную комбинацию LSP из набора допустимых комбинаций и выбирает то, как на самом деле ансамбль транспортируется через комбинацию LSP, для того чтобы обеспечить наилучшее соответствие параметров среды и поставленного задания в терминах поддержки Diff-Serv, управления трафиком и защиты MPLS. Критерии выбора такой комбинации находятся вне пределов рассмотрения данной спецификации.
Для заданного FEC, может быть более одного LSP транспортирующего один и тот же OA, например, для целей балансировки нагрузки OA. Однако для того чтобы удовлетворить затребованным ограничениям, все пакеты данного микропотока, охватывающего возможно несколько BA данного OA, должны транспортироваться через тот же самый LSP. Наоборот, каждый LSP должен быть способен поддерживать все (активные) BA заданного OA. Примеры реализации сценариев представлены в приложение A.
Обсуждение
Если желательно детектирование петель в домене MPLS, тогда оно должно быть активировано во всех LSR в пределах этой области MPLS, в противном случае детектирование петель не будет работать корректно и может привести пропуску петель или к ложному детектированию петель.
LSR, которые сконфигурированы для детектирования петель, могут не запоминать векторы пути в качестве части состояния LSP.
Заметим, что в сети, где присутствуют только LSR без возможности объединения, векторы пути передаются вниз по течению от входа к выходу, и не передаются вверх по течению. Даже когда объединение меток поддерживается, векторы пути не передаются вверх по течению вдоль LSP. Когда для LSR меняется узел следующего шага, необходимо передавать векторы пути вверх по течению, только когда невозможно судить по числу шагов, что изменение следующего шага не приведет к образованию петли.
В случае упорядоченной рассылки меток, сообщения выделения меток распространяются от выхода к входу, естественно, формируя по дороге вектор пути. В случае независимой рассылки меток, LSR может порождать сообщение присвоения метки для FEC до получения сообщения присвоения метки от своего партнера ниже по течению. В этом случае последующее сообщение для FEC, полученное от партнера ниже по течению, рассматривается как обновление атрибута LSP, а сообщение присвоения метки должно пересылаться вверх по течению. Таким образом, рекомендуется, чтобы детектирование петель конфигурировалось в сочетании с упорядоченной рассылкой меток, чтобы минимизировать число сообщений обновления присвоения меток.
Обзор
Поскольку пакеты в случае протокола сетевого уровня без установления соединения переносятся от одного маршрутизатора к другому, каждый из них совершенно независим в принятии решения переадресации. То есть, каждый маршрутизатор анализирует заголовок пакета и каждый маршрутизатор реализует алгоритм маршрутизации сетевого уровня. Маршрутизатор независимо выбирает следующий шаг для пакета, основываясь на результатах анализа его заголовка и результата работы маршрутного алгоритма. Заголовки пакета содержат значительно больше информации, чем нужно для выбора следующего шага. Выбирая следующий шаг можно, следовательно, выполнять две процедуры. Первая делит весь набор пакетов на классы FEC (Forwarding Equivalence Classes). Вторая ставит в соответствие каждому FEC следующий шаг маршрута. В той части, которая касается переадресации, разные пакеты, поставленные в соответствие определенному FEC, не различимы. Все пакеты, которые принадлежат определенному FEC, и которые отправлены из конкретного узла будут следовать одним и тем же путем (или в случае многомаршрутного протокола, они будут следовать через один и тот же набор путей, ассоциированный с FEC).
При обычной IP переадресации, маршрутизатор рассматривает два пакета принадлежащими к одному FEC, если существует адресный префикс X в таблицах маршрутизации маршрутизатора, такой что Х, соответствует каждому адресу места назначения. Когда пакет проходит через сеть, на каждом шагу пакет последовательно просматривается и ему присваивается FEC.
В MPLS присвоение пакету определенного FEC делается только раз, когда пакет входит в сеть. FEC, к которому приписан пакет, кодируется, как код фиксированной длины, называемый меткой. Когда пакет переадресуется на следующем шагу, метка посылается вместе с ним, так что пакеты оказываются помечены, до того, как будут переадресованы.
При последующих шагах не производится никакого анализа заголовков пакетов сетевого уровня. Здесь для индексации следующего шага и новой метки используется присвоенная ему на входе метка. Старая метка замещается новой и пакет переадресуется в следующий узел.
В парадигме переадресации MPLS, поскольку пакет приписан определенному FEC, никакого последующего анализа заголовков в маршрутизаторах по пути следования не производится, а переадресация управляется исключительно на основе меток. Это имеет много преимуществ перед традиционной маршрутизацией на сетевом уровне.
- MPLS-переадресация может быть выполнена переключателями, которые способны осуществлять просмотр меток и их замещение, но не могут анализировать заголовки сетевого уровня (во всяком случае с достаточной скоростью).
- Так как пакет поставлен в соответствие определенному FEC, когда он входит в сеть, входной маршрутизатор может использовать при определении соответствия любую информацию, которую он имеет о пакете, даже если такая информация не может быть извлечена из заголовка сетевого уровня. Например, пакеты, приходящие через разные порты, могут быть связаны с разными FEC. Традиционная переадресация может рассматривать только информацию, которая транспортируется внутри пакета в его заголовке.
- Пакет, который входит в сеть через определенный маршрутизатор, может быть помечен иначе, чем такой же пакет, вошедший в сеть через другой маршрутизатор, и в результате решение о переадресации зависит от входного маршрутизатора и может быть легко осуществлено. Это не может быть сделано традиционной переадресацией, так как идентичность входного маршрутизатора не путешествует вместе с пакетом.
- Соображения, которые определяют то, как пакету ставится в соответствие FEC, могут становиться даже более сложными, без каких-либо последствий для маршрутизаторов, которые просто переадресуют помеченные пакеты.
- Иногда желательно заставить пакеты следовать определенным маршрутом, который выбран перед входом или во время входа пакета в сеть, вместо следования нормальному динамическому протоколу маршрутизации. Это может быть сделано в соответствии с разной политикой, или с привлечением техники управления трафиком. При традиционной переадресации это требует, чтобы пакет нес в себе информацию о маршруте, по которому он должен двигаться (маршрутизация отправителя). В MPLS, метка может использоваться для представления маршрута, так что идентичность маршрута не переносится вместе с пакетом.
Некоторые маршрутизаторы анализируют заголовок пакета сетевого уровня не только с целью выбора следующего шага, но и для определения приоритета и класса услуг. Они могут затем применить различные пороги отсева или графика обслуживания пакетов. MPLS допускает (но не требует) приоритетность или класс обслуживания, зависящие полностью или частично от метки. В этом случае, можно сказать, что метка представляет собой комбинацию FEC, приоритета или класса обслуживания. В MPLS "Multiprotocol" означает многопротокольный, так как его техника применима к любому протоколу сетевого уровня. В данном документе, однако, внимание сконцентрировано на использовании IP в качестве протокола сетевого уровня. Маршрутизатор, который поддерживает MPLS, называется "Label Switching Router", или LSR (маршрутизатором с коммутацией по меткам).
Обобщенный MPLS отличается от традиционного MPLS тем, что он поддерживает много типов коммутации, т.е., TDM, l -, волоконную коммутацию. Поддержка дополнительных видов коммутации вынуждают обобщенный протокол MPLS расширить некоторые базовые функции MPLS и, в некоторых случаях добавить определенные функции. Эти изменения и добавления оказывают влияние на то, как осуществляются запросы и транспортировка меток, как пересылаются сообщения об ошибках и как выполняется синхронизация на входе и на выходе.
В традиционном управлении трафиком MPLS (TE), каналы, через которые проходит LSP, могут содержать сегменты с разной кодировкой меток. Например, LSP может содержать каналы, соединяющие маршрутизаторы, каналы между маршрутизаторами и ATM-LSR, и каналы между ATM-LSR. Обобщенный MPLS осуществляет расширение функциональности путем включения каналов, где метка кодируется как временной домен, длина волны, или позиция в физическом пространстве. Также как и в традиционном MPLS TE, где не все LSR могут распознавать границы IP-пакетов (напр., ATM-LSR) при переадресации, обобщенный MPLS включает в себя поддержку LSR, которые не распознают границ IP-пакетов. В традиционном MPLS TE LSP, который транспортирует IP, должен начинаться и завершаться в маршрутизаторе. Обобщенный MPLS требует, чтобы LSP начинался и завершался в LSR того же типа. Кроме того, в обобщенном MPLS тип данных, который транспортируется через LSP, может включать в себя SONET/SDH, GE или 10Гбитный Ethernet. Эти изменения традиционного MPLS отражаются в механизме запроса и переноса меток, смотри разделы 3.1 и 3.2. Специальный случай l -переключения, называемого волновой коммутацией, описан в разделе 3.3.
Другим базовым отличием традиционного и не-PSC типа обобщенного LSP MPLS, является то, что полоса пропускания, выделяется для LSP дискретными порциями, смотри раздел 3.1.3. Заметим, что использование FA (Forwarding Adjacencies), смотри [MPLS-HIERARCHY], предоставляет механизм, который может улучшить использование полосы пропускания, когда выделение полосы осуществляется дискретным образом, а также механизм агрегатирования состояния переадресации, что может сократить требуемое число меток.
Обзор 2.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 туннель.
Обзор базовых типов среды верхнего уровня
Имеется пять дискретных типов среды высокого уровня.
| (1) | text |
- текстовая информация. Субтип "plain" в частности указывает, что текст не содержит команд форматирования или каких-либо директив. Такой текст нужно отображать, так как он есть. Не нужно никакого специального программного обеспечения для восприятия такого текста, помимо поддержки указанного символьного набора. Другие субтипы должны использоваться для обогащенного текста (enriched) в форме, где прикладное программное обеспечение может улучшить представление текста. Но такая программа не нужна для общей обработки содержимого. Возможные субтипы "text" включают в себя любые форматы, которые могут быть прочитаны без обращения к программе, которая понимает этот формат. В частности, форматы, которые используют встроенное двоичное форматирование, не считаются непосредственно читаемыми. Очень простой и портативный субтип, "richtext", был определен в документе RFC 1341, и позднее пересмотрен в RFC 1896 под именем "enriched".
Существует два составных типа среды высшего уровня.
| (1) | multipart | - данные, состоящие из нескольких объектов с различными типами данных. Определены четыре первичных субтипов, включая базовый субтип "mixed", специфицирующий смешанный набор частей, "alternative" - для представления одних и тех же данных в различных форматах, "parallel" - для частей, которые должны представляться одновременно и "digest" - для составных объектов, в которых каждая часть имеет тип по умолчанию "message/rfc822". |
| (2) | message |
Обзор IP-мультикастинга в среде многопротокольной коммутации по меткам (MPLS)
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Перевод RFC-3353
Аннотация
В данном документе формулируются принципы внедрения IP -мультикастинга в среду MPLS. Представлен обзор последствий внедрения технологии MPLS в IP-мультикастинг. Рассматриваются плюсы и минусы существующих IP-мультикастинговых протоколов маршрутизации в контексте и обсуждаются соотношения различных способов запуска процессов формирования виртуальных путей на основе использования меток. Перечислены последствия применения различных технологий уровня 2 (L2). Обсуждаются сетевые схемы точка-точка и сети с множественным доступом.
Таблица сокращений
CoS
Обзор LDP
Архитектура MPLS [RFC3031] определяет протокол рассылки меток как набор процедур, с помощью которых один LSR (Label Switched Router) информирует другого о значении меток, используемых для переадресации трафика между ними и через них.
Архитектура MPLS не предполагает наличия одного протокола рассылки меток. В действительности, стандартизовано несколько различных протоколов. Некоторые существующие протоколы были расширены так, чтобы позволить рассылку меток. Сформулированы новые протоколы. Архитектура MPLS предполагает учет некоторых соображений при выборе протокола рассылки меток для конкретных MPLS приложений в частности в случае управления трафиком [RFC2702].
Протокол рассылки меток LDP (Label Distribution Protocol), определенный в этом документе, является новым протоколом для рассылки меток. Это набор процедур и сообщений, с помощью которых LSR формирует сетевой LSP (Label Switched Path) путем установления соответствия между маршрутной информацией и каналами передачи данных. Эти LSP могут иметь оконечные точки непосредственно у партнера (сопоставимо с IP переадресацией шаг-за-шагом), или могут иметь оконечную точку в выходном узле сети, позволяя коммутацию через все промежуточные узлы.
LDP ставит в соответствие FEC (Forwarding Equivalence Class) [RFC3031] каждому LSP, который он создает. FEC ассоциированный с LSP определяет, какие пакеты должны следовать по этому LSP. LSP прокладываются через сеть так, что каждый LSR обеспечивает стыковку входной метки для FEC с выходной меткой, соответствующей следующему шагу для данного FEC. Дополнительные данные о применении LDP можно найти в [RFC3037].
В данной статье предполагается знакомство с архитектурой MPLS [RFC3031]. Заметим также, что [RFC3031] содержит словарь терминов MPLS.
В тексте считается, что данные следуют от LSR-отправителя (вышестоящий) к LSR-получателю вниз по течению, а служебная информация может следовать и вверх по течению.
Одно и двунаправленные деревья с совмещением
Двунаправленные деревья с совмещением (например, CBT [BALL]) имеют недостаток, который связан с формированием большого числа точек смежности (M) в узлах (N) совмещенного дерева. На рис. 4 показаны эти точки, полученные при двух отправителях S1 и S2 двунаправленного дерева.
Рис. 4. Потоки мультикаст-данных от двух отправителей для двунаправленного дерева
На рис. 5 показана та же ситуация для однонаправленных деревьев. В этом случае данные отправителя направляются через туннель к корневому узлу R, формируя всего одну точку смежности (сам корень дерева).
Рис. 5. Потоки мультикаст-данных от двух отправителей для однонаправленного дерева
Однородная модель
При однородной модели MPLS-туннели (другими словами LSP) рассматриваются с позиции Diff-Serv, как соединение точка-точка. MPLS-туннели могут использоваться для целей переадресации, но не имеют никакого влияния на Diff-Serv. В этой модели любой пакет содержит только одно поле с информацией Diff-Serv, имеющей какое-то значение, и именно его величина заносится в самую внешнюю метку (или в поле IP DSCP, когда IP-пакет передается непомеченным, например, вначале LSP). Любая информация Diff-Serv, хранящаяся где-либо еще (например, в более глубокой записи стека меток), не играет никакой роли для промежуточных узлов или выхода туннеля и игнорируется. Если формирование трафика в промежуточных узлах LSP оказывает влияние на "выходную" информацию Diff-Serv, актуализованная информация Diff-Serv считается значимой на выходе LSP. Работа однородной модели без PHP проиллюстрирована на рис. 5:
Рис. 5.
(M) - значимая информация Diff-Serv в соответствующем заголовке.
(x) - отсутствие значимой информации Diff-Serv.
I - входной узел LSP
E - выходной узел LSP
Работа однородной модели с PHP проиллюстрирована на рис. 6:
Рис. 6.
(M) - существенная информация Diff-Serv, записанная в соответствующем заголовке.
(x) - безразличная информация Diff-Serv.
I - входной узел LSP;
P - предпоследний узел LSP;
E - выходной узел LSP.
Однородная модель для Diff-Serv поверх происходит так, как если бы MPLS не использовался совсем. Другими словами для работы Diff-Serv MPLS совершенно прозрачен.
Для поддержки однородной модели для заданного LSP, LSR определяет входное PHB и кодирование информации Diff-Serv следующим образом:
при получении непомеченного пакета, LSR определяет входное PHB, просматривая полученный IP-заголовок.
при получении помеченного пакета, LSR определяет входное PHB, просматривая верхнюю позицию полученного стека меток. В частности, для рассматриваемого LSP должна быть выполнена операция pop, LSR определяет входное PHB до осуществления команды pop.
при выполнении операции push для заданного LSP, LSR заносит информацию Diff-Serv в передаваемую метку, записанную в стек. Информация Diff-Serv, занесенную в инкапсулированный заголовок (свопированная запись метки или IP-заголовок), не имеет никакого значения.
при выполнении операции swap-only для заданного LSP, LSR заносит информацию Diff-Serv в позицию стека меток, которая содержит свопированную метку.
когда используется PHP, предпоследний LSR должен позаботиться о формировании таблицы PHB-->Encaps для метки, соответствующей обрабатываемому заголовку (или соответствия PHB-->DSCP), для того чтобы выполнить кодирование информации Diff-Serv. В качестве примера, таблица PHB-->DSCP может быть сконфигурирована локально. В качестве другого примера для некоторой среды, вполне приемлемо для предпоследнего LSR предположить, что набор таблиц PHB-->Encaps следует использовать для исходящей метки в обрабатываемом LSR заголовке, если он не выполняет PHP. Заметим также, что данная спецификация предполагает, что предпоследний LSR не осуществляет обмен меток (swapping) для позиции в стеке, для которой выполнена операция pop (и в действительности он даже не смотрит на обрабатываемую метку). Следовательно, ограничения могут быть наложены на кодирование информации Diff-Serv, которые могут быть выполнены предпоследним LSR. Например, данная спецификация не допускает ситуаций, когда предпоследний LSR извлекает из стека метку, соответствующую E-LSP, поддерживающему два PSC, в то время как заголовок при выполнении операции pop содержит значения меток для двух L-LSP, каждый из которых поддерживает один PSC, так как кодирование информации Diff-Serv будет требовать выбора одной или другой метки.
Заметим, что поведение LSR для моделей трубы, короткой трубы и однородной модели отличаются только при выполнении операций push или pop. Таким образом, промежуточные LSR, которые выполняют для LSP только операции swap, ведут себя в точности также, вне зависимости оттого, какая из моделей использована. При реализации Diff-Serv, поддерживающей несколько моделей туннелирования, только LSR, ведущие себя как вход LSP, предпоследний LSR или выход LSP, должны конфигурироваться для работы с определенной моделью.
характеризуют безопасность, достижимую при использовании
Следующие выдержки из [RFC2385] характеризуют безопасность, достижимую при использовании опции подписи TCP MD5:
"IESG заявление
Этот документ описывает существующую практику обеспечения безопасности BGP против определенного типа простых атак. Понятно, что система имеет определенные слабости в отношении некоторых атак".
"Аннотация
Этот меморандум описывает расширение TCP с целью улучшения безопасности BGP. Он определяет новую опцию TCP для формирования MD5-дайджеста в сегменте TCP [RFC1321]. Этот дайджест действует подобно подписи для этого сегмента, вводя информацию, известную только конечным пунктам соединения. Так как BGP применяет TCP в качестве транспорта, использование этой опции способом, описанным в данном документе, значительно сокращает опасность определенных атак на BGP."
"Введение
Первоначальная мотивация этой опции заключается в разрешении для BGP защитить себя от введения фальсифицированных TCP сегментов в поток соединения. Особое внимание уделяется сигналам сброса TCP (reset).
Чтобы сфальсифицировать соединения с использованием схемы, описанной в данном документе, атакер должен не только угадать номера TCP-сегментов, но также получить пароль, вставленный в дайджест MD5. Этот пароль никогда не появляется в потоке соединения, а действительная форма пароля определяется приложением. Он может быть изменен за время жизни конкретного соединения при условии синхронности изменения для обоих концов виртуального канала (хотя повторная передача может вызвать проблемы в некоторых TCP реализациях с изменением пароля).
Наконец, не существует процедуры согласования использования этой опции при соединении, скорее это является вопросом политики, использовать данную опцию или нет".
"MD5 в качестве алгоритма хэширования
Так как данный меморандум был сначала выпущен под другим заголовком, алгоритм MD5 был признан уязвимым для атак поиска столкновений [Dobb], и рассматривался как недостаточно строгий для данного типа соединений".
Этот меморандум специфицирует алгоритм MD5, однако, так как опция уже использовалась в работе, и не существует поля "тип алгоритма", чтобы позволить обновление, используется тот же самый номер опции. Исходный документ не специфицирует поле тип, так как это потребовало бы, по крайней мере, на один байт больше, и кажется, что использование 19 байт для полной опции (которая, вероятно в TCP реализации займет за счет заполнителя 20 байт) слишком много для ограниченного пространства опций.
Это не препятствует применению другой подобной опции, которая бы использовала другой алгоритм хэширования (например, SHA-1). Кроме того, если большинство реализаций все равно дополняют 18 байт опции до 20 байт, было бы хорошо определить новую опцию, которая бы содержала поле тип.
На этом выдержки из [RFC2385] завершаются
Опция: присвоение метки Egress Targeted
Существуют ситуации, в которых начало LSP Ri, знает, что пакеты нескольких разных FEC должны следовать одним и тем же LSP, завершающимся, скажем, конечным Re. В этом случае, корректная маршрутизация может быть реализована использованием одной метки для всех таких FEC, необязательно иметь отличающиеся метки для каждого FEC. Если и только если выполняются следующие условия:
1. Адрес LSR Re сам находится в маршрутной таблице (host route), и
2. Существует некоторый способ для Ri определить, что Re является концом LSP для всех пакетов в конкретном наборе FEC.
Затем Ri может связать одну метку со всеми элементами набора FEC. Это называется "Egress-Targeted Label Assignment".
Как может LSR Ri определить, что LSR Re является концом LSP для всех пакетов в конкретном FEC? Существует несколько возможных путей:
- Если сеть реализует алгоритм маршрутизации состояния канала, а все узлы в области поддерживают MPLS, тогда алгоритм маршрутизации предоставляет Ri достаточно информации, чтобы определить маршрутизаторы, через которые пакеты в данном FEC должны покинуть домен маршрутизации или область.
- Если сеть реализует BGP, Ri может определить, какие пакеты в заданном FEC должны покинуть сеть через некоторый конкретный маршрутизатор, который является "BGP Next Hop" для этого FEC.
- Можно использовать протокол рассылки меток, чтобы передать информацию о том, какие адресные префиксы подключены к какому концевому LSR. Этот метод имеет преимущество отсутствия зависимости от наличия маршрутизации по состоянию канала.
Если используется присвоение меток egress-targeted, число меток, которые необходимо поддерживать во всей сети может быть сокращено. Это может быть важно, если используется аппаратные переключатели для реализации MPLS, а коммутирующее оборудование может поддерживать ограниченное число меток.
Возможным подходом могло бы быть конфигурирование сети для использования присвоения меток egress-targeted по умолчанию, но при конфигурации конкретных LSR не использовать присвоения меток egress-targeted для одного или более адресных префиксов, для которых он является концом LSP. Мы вводим следующее правило:
- Если какой-то LSR не является концом LSP для некоторого набора адресных префиксов, тогда он должен присваивать метки адресным префиксам так же, как это делается узлом следующего шага LSP для этих адресных префиксов. То есть, предположим, Rd является маршрутизатором следующего шага (Ru) LSP для адресного префикса X1 и X2. Если Rd приписывает ту же метку X1 и X2, Ru должен сделать то же самое. Если Rd присваивает разные метки X1 и X2, тогда и Ru должен это сделать.
Например, предположим, что хочется осуществить присвоение метки egress-targeted по умолчанию, но присвоить разные метки тем адресным префиксам, для которых существует несколько возможных концов LSP (т.e., для тех адресных префиксов, которые являются multi-homed). Можно сконфигурировать все LSR для использования присвоения меток egress-targeted, и затем конфигурировать LSR, чтобы приписать разные метки тем адресным префиксам, которые являются multi-homed. Для конкретного адресного префикса multi-homed X, было бы нужно сконфигурировать LSR, которые являются либо концами LSP, либо прокси концами LSP для X.
Важно заметить, что если Ru и Rd являются смежными LSR в LSP для X1 и X2, переадресация будет выполнена корректно, если Ru присваивает разные метки X1 и X2, в то время как Rd присваивает одну метку для них обоих. Это лишь означает, что R1 будет устанавливать соответствие между разными входными метками и одной выходной.
Аналогично, если Rd присваивает разные метки X1 и X2, но Ru присваивает им обоим метку, соответствующую адресу их конца LSP или прокси конца, переадресация будет, тем не менее, осуществляться корректно. Ru будет лишь устанавливать соответствие между входной меткой и меткой, которую сформировал Rd для адреса конца LSP .
Операции Keep-Alive
Сообщение Keep-Alive используется для проверки соединения между клиентом и сервером, чтобы проверить функциональность соединения даже в отсутствие обмена сообщениями между PEP и PDP. PEP должен формировать COPS KA-сообщение случайным образом в диапазоне от одной четвертой до 3/4 минимальной величины выдержки KA таймера, заданной PDP в сообщении Client-Accept. При получении сообщения Keep-Alive от PEP, PDP должен реагировать на это сообщение Keep-Alive посылкой отклика Keep-Alive к PEP. Если любая из сторон не получит сообщение Keep-Alive или любого другого сообщения COPS за время выдержки KA-таймера, соединение должно считаться разорванным.
Операции конфигурирования
В конфигурационном сценарии PEP выполнит запрос PDP для определенного интерфейса, модуля, или функциональности, которые могут быть специфицированы в информационном объекте именованного клиента. PDP пошлет потенциально несколько решений, содержащих именованные блоки конфигурационных данных PEP. Предполагается, что PEP инсталлирует и использует конфигурацию локально. Конкретная именованная конфигурация может быть актуализована путем отправки дополнительных сообщений-решений для данной конфигурации. Когда PDP более не хочет, чтобы PEP использовал часть конфигурационной информации, он пошлет сообщение-решение, специфицирующее именованную конфигурацию и объект флагов решения (decision flags) с командой удаления конфигурации. PEP должен удалить соответствующую конфигурацию и послать сообщение-отчет PDP, об этом удалении.
В любом случае, PEP может уведомить удаленный PDP о локальном статусе инсталлированного состояния, используя сообщение-отклик. Это сообщение, если нужно, может содержать специфическую информацию клиента.
Определение исходящего PHB с опционным формированием трафика
Этап конфигурирования трафика является опционным и может использоваться на LSR для осуществления формирования трафика, включая уменьшение или увеличение ВА. В целях спецификации Diff-Serv посредством MPLS-переадресации, мы просто отмечаем, что PHB, заданное и пересланное нижестоящему LSR, может отличаться от PHB, которое было ассоциировано с пакетом предыдущим LSR.
Когда фаза формирования трафика отсутствует, выходное PHB тождественно входному PHB.
Определение типов среды верхнего уровня
Определение типа среды верхнего уровня состоит из:
| (1) |
Имя и описание типа, включая критерии, согласно которым можно решить, относится ли данная среда к указанному типу.
Определение входного PHB
Эта фаза определяет, к какому ансамблю ВА принадлежит полученный пакет.
Определение входного PHB для входящего E-LSP
В этом разделе рассказано, как осуществляется определение входного PHB, когда рассматриваемая метка в полученном стеке соответствует E-LSP. Это требует, чтобы соответствие Encaps-->PHB формировалось так, как это определено в разделе 3.2.
При рассмотрении записи в стеке меток E-LSP, соответствующей входному PHB, LSR должен:
рассмотрев входную метку E-LSP, определить таблицу EXP-->PHB путем анализа соответствия Encaps-->PHB в контексте Diff-Serv, сопряженном с ILM.
определить входное PHB, просмотрев поле EXP, рассмотренной метки в таблице соответствия EXP-->PHB.
Определение входного PHB для входящего L-LSP
В данном разделе определено, как осуществляется определение входного PHB, когда рассматриваемая метка в полученном стеке меток соответствует L-LSP. Это требует, чтобы таблица Encaps-->PHB заполнялась так, как это определено в разделе 4.2.
Когда метка, соответствующая входящему L-LSP рассматривается для определения входного PHB, LSR сначала определяет таблицу соответствия Encaps-->PHB, ассоциированную с данной меткой.
Определение входного PHB с учетом IP-заголовка
В разделе 2.6 представлены детали того, когда для определения входного PHB следует рассматривать IP-заголовок, в зависимости от модели туннелирования Diff-Serv. В тех случаях, когда используется IP-заголовок, на данном этапе выполняется все точно то же, что и в случае Diff-Serv IP-маршрутизатора, не поддерживающего MPLS, а для определения входного PHB используется поле DS.
Определение входного PHB с учетом рекорда стека меток
В разделах 3.3 и 4.3 представлено то, как осуществляется определение входного PHB при рассмотрении рекорда стека меток конкретного входного пакета и/или полученной входной инкапсулированной информации MPLS, зависящей от типа входного LSP и разновидности MPLS инкапсуляции.
В разделе 2.6 представлены детали того, какой рекорд стека меток следует анализировать для определения входного PHB в зависимости от поддерживаемого режима туннелирования Diff-Serv.
