Метки для адресных префиксов

Вообще, маршрутизатор R определяет следующий шаг для пакета P путем нахождения подходящего адресного префикса X в своей маршрутной таблице. То есть, пакеты в данном FEC – это пакеты, которые соответствуют заданному адресному префиксу в маршрутной таблице R. В этом случае, FEC может быть идентифицирован адресным префиксом.

Заметим, что пакет P может быть приписан к FEC F, а FEC F может быть идентифицирован адресным префиксом X, даже если адрес места назначения P не согласуется с X.

Метки для явно маршрутизируемых LSP

В некоторых приложениях MPLS, в частности сопряженных с управлением трафиком (ТЕ), желательно формировать пути, маршрутизированные явно от точки входа до точки выхода. Хотелось бы также осуществлять резервирование ресурсов вдоль всего пути. Можно представить два подхода:

-  Начать с существующего протокола, который используется при установлении резервирования, и расширить его в направлении поддержки явной маршрутизации и рассылки меток.

-  Начать с существующего протокола, который используется для рассылки меток, и расширить его в сторону явной маршрутизации и резервирования ресурсов.

Первый подход реализован в протоколе, описанном в [MPLS -RSVP-TUNNELS], второй – специфицирован в [MPLS-CR-LDP].

Метки для RSVP Flowspecs

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

Многоцелевое расширение почты Интернет (MIME)

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Стандарт STD 11, RFC 822 определяет протокол представления сообщений, структуру их заголовков. При этом предполагается, что текст сообщения построен исключительно из кодов US-ASCII. Набор документов MIME (Multipurpose Internet Mail Extensions; RFC-2045-49) задает формат сообщений, который предоставляет следующие возможности.

Передача текстовых сообщений с символьным набором, отличным от US-ASCII.

Передача сообщений нетекстового формата (например, звукового письма).

Использование комбинированных сообщений, содержащих разнородные части.

Размещение в заголовке информации в символьном наборе, отличном от US-ASCII.

Документ RFC-2045 характеризует различные заголовки, которые служат для описания структуры MIME-сообщений. RFC 2046 определяет общую структуру MIME и исходный набор типов среды. RFC 2047 описывает расширения документа RFC 822, позволяя применение в полях заголовков символьных наборов, отличных US-ASCII. RFC 2048 специфицирует различные ограничения, вводимые IANA, для процедур, сопряженных с MIME. RFC 2049 характеризует критерии соответствия требованиям MIME, содержит примеры допустимых форматов и библиографию.

Модель короткой трубы

Модель короткой трубы является опционной вариацией модели трубы, описанной выше. Единственное отличие заключается в том, что для модели короткой трубы, процедура переадресации Diff-Serv в конце LSP реализуется на основе "туннелированной информации Diff-Serv" (т.е., информация Diff-Serv передается в инкапсулированном заголовке), а не на базе "информации LSP Diff-Serv". Работа модели короткой трубы без PHP проиллюстрирована ниже на рис. 3:

Рис. 3.

(M) - "информация LSP Diff-Serv"
(m) - "туннелированная информация Diff-Serv"
I - входной узел LSP
E - выходной узел LSP

Так как конец LSP осуществляет процедуру переадресации на основе "туннелированной информации Diff-Serv", предпоследнему узлу не следует передавать "информацию LSP Diff-Serv" узлу конца LSP. Таким образом, модель короткой трубы может работать также и с PHP. Работа модели короткой трубы с PHP проиллюстрирована ниже на рис. 4:

Рис. 4.

(M) - информация LSP Diff-Serv
(m) - туннелированная информация Diff-Serv
(*) Предпоследний LSR рассматривает информацию LSP Diff-Serv, полученную во внешнем заголовке (т.е., до операции pop), для того чтобы использовать ее при переадресации Diff-Serv (т.е., действительного PHB)
I - входной узел LSP входной узел
P - предпоследний узел LSP
E - выходной узел LSP

Модель короткой трубы особенно эффективна для среды, в которой:

облако "выше по течению" по отношению к входному интерфейсу входа LSP и облако “ниже по течению” по отношению к выходному интерфейсу выхода LSP находятся в областях Diff-Serv, которые используют общий набор услуг, представляющих политики и определения PHB. LSP перекрывает одну (или более) областей Diff-Serv, которые используют различные наборы услуг Diff-Serv, представляющие политики и определения PHB.

выходной интерфейс выхода LSP находится в той же области Diff-Serv, что и облако “вниз по течению” за ним.

Так как каждый выходной интерфейс конца LSP представляет ту же область Diff-Serv, что и облако ниже по течению, каждый выходной интерфейс может потенциально находиться в другом домене Diff-Serv, и нужно аккуратно сконфигурировать узел выхода LSP с учетом соответствующих политик Diff-Serv. Эта избыточность оправдана в некоторых ситуациях, где соответствующие политики для областей Diff-Serv ниже по течению лучше согласуются с предлагаемым уровнем QoS для каждого входного интерфейса, чем общая политика Diff-Serv используемая для LSP. Примером может служить ситуация, когда сервис провайдер предлагает услугу MPLS VPN, и когда некоторые пользователи VPN требуют своей собственной политики управления дифференцированными услугами для определенного канала от выхода LSP до заданного сайта VPN. Модель короткой трубы может поддерживаться опционно.

Для поддержки модели короткой трубы для заданного LSP без PHP, LSR определяет входную PHB и кодирует информацию Diff-Serv тем же способом, что и в модели трубы со следующими исключениями: при получении помеченного пакета, LSR определяет входное PHB, просматривая заголовок (метку или IP-заголовок), который используется для выполнения реальной переадресации. В частности, когда должна быть выполнена операция pop для рассматриваемого LSP, LSR определяет входное PHB после выполнения pop.

При поддержке модели короткой трубы для данного LSP с PHP, LSR определяет входное PHB и кодирует информацию Diff-Serv так же, как и без PHP со следующими исключениями: предпоследний LSR определяет входное PHB, рассматривая выходную метку из полученного стека меток. Другими словами, когда нужно выполнить операцию pop для заданного LSP, предпоследний LSR определяет входное PHB до реализации pop.

Заметим, что поведение предпоследнего LSR в модели короткой трубы с PHP, идентично поведению конца LSP в модели трубы (без PHP).

Модель переадресации меток для Diff-Serv LSR

Так как различные OA данного FEC могут транспортироваться по разным LSP, решение о замене меток Diff-Serv LSR определенно зависит от ВА пакетов. Кроме того, так как поле IP DS переадресуемого пакета может быть невидимо для LSR, способ определения PHB, которое должно быть применено к полученному пакету, и кодирования PHB, может отличаться для маршрутизаторов Diff-Serv, не поддерживающих MPLS.

Таким образом, для того чтобы описать переадресацию по меткам в Diff-Serv LSR, мы моделируем поведение LSR Diff-Serv, коммутирующих по меткам, с использованием четырех шагов:

Определение входного PHB (A) Определение выходного PHB с оптимальным формированием трафика (B) Переадресация по меткам (C) Кодирование информации Diff-Serv на уровне инкапсуляции (EXP, CLP, DE, User_Priority) (D)

Каждый из шагов описан более подробно в последующих разделах.

Очевидно, что для усиления дифференцирования услуг Diff-Serv LSR должен также привлекать процедуры переадресации, соответствующие выходному PHB. Эта модель проиллюстрирована ниже:

Рис. 1

На рис. 1 "Encaps" обозначает данные Diff-Serv, закодированные на уровне инкапсуляции MPLS (например, поле EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority)

(*) когда LSR ведет себя как входной узел MPLS, входные пакеты могут быть получены непомеченными.

(&) когда LSR ведет себя как выходной узел MPLS, исходящие пакеты могут быть непомеченными.

Эта модель представлена здесь, чтобы описать функциональные операции Diff-Serv LSR, а не ограничивать возможности практических реализаций.

Модель трубы

В модели трубы MPLS-туннели (иными словами LSP) используются, чтобы спрятать промежуточные MPLS-узлы между началом LSP и концом с точки зрения Diff-Serv.

В этой модели, туннелируемые пакеты должны нести в себе две значимые вещи: информация Diff-Serv, которая важна для промежуточных узлов LSP включая конец LSP (которую мы называем - информация LSP Diff-Serv). Эта информация LSP Diff-Serv не играет роли за пределами конца LSP: Воздействует ли формирование трафика в промежуточных узлах LSP на информацию LSP Diff-Serv или нет, эта модифицированная информации Diff-Serv не рассматривается значимой за пределами конца LSP и игнорируется. информация Diff-Serv, которая имеет значение после конца LSP (ее мы называем "туннельной информацией Diff-Serv"). Эта информация должна быть передана началом LSP его концу. Эта информация Diff-Serv не имеет значения для промежуточных узлов LSP.

Работа модели трубы без PHP проиллюстрирована ниже:

Рис. 2

(M) обозначает "данные LSP Diff-Serv"
(m) обозначает "туннелированные данные Diff-Serv"
(*) Выход LSP рассматривает информацию LSP Diff-Serv, полученную из выходного заголовка (т.e., до выполнения операции pop), для того чтобы применить ее при осуществлении переадресации Diff-Serv (т.е., реальной PHB)
I обозначает входной узел LSP
E обозначает выходной узел LSP

При модели трубы, информация узлов LSP Diff-Serv должна передаваться концу LSP, так чтобы она могла использоваться для переадресации пакетов. "Туннелируемая информация Diff-Serv" также должна пересылаться концу LSP, чтобы она передавалась дальше “вниз по течению”.

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

В качестве примера, рассмотрим случай, где сервис провайдер предлагает услуги MPLS VPN (в качестве примера архитектуры MPLS VPN смотри [MPLS_VPN]), включая услуги Diff-Serv. Будем считать, что набор сайтов соединен через такую MPLS VPN сеть. Теперь скажем, что этот набор сайтов управляется общей администрацией и поддерживает Diff-Serv. Если администрация VPN-сайта и сервис провайдер не придерживаются общей политики Diff-Serv (например, не поддерживают то же число PHB), тогда работа Diff-Serv в модели трубы поверх MPLS VPN будет допускать, чтобы политика Diff-Serv VPN-сайтов реализовалась совместимым образом между входным и выходным сайтом VPN, обеспечивая прозрачность в области Diff-Serv сервис провайдера. Может быть, полезно рассмотреть такие LSP, как соединения областей Diff-Serv с одной общей областью, сделав граничные точки виртуально смежными, даже если они физически разделены промежуточными сетевыми узлами. Модель трубы должна поддерживаться.

Для поддержки модели трубы для данного LSP без PHP, LSR определяет входное PHB и кодирование информации Diff-Serv следующим образом: при получении непомеченного пакета, LSR осуществляет определение входного PHB, просматривая IP-заголовок полученного пакета.при получении помеченного пакета, LSR определяет входное PHB, просматривая запись выходной метки в полученном стеке меток. В частности, когда должна быть выполнена операция pop для рассмотренного LSP, LSR определяет входное PHB до осуществления этой операции.при выполнении операции push для рассмотренного LSP, LSR:кодирует информацию Diff-Serv, соответствующую выходному PHB в записи передаваемой метки, которая соответствует метке, извлеченной из стека. кодирует информацию Diff-Serv, соответствующую входному PHB в инкапсулированном заголовке (замененная запись метки или IP-заголовка). при выполнении операции swap-only для рассмотренного LSP, LSR кодирует информацию Diff-Serv в записи передаваемой метки, которая содержит заменяемую метку при выполнении операции pop для рассмотренного LSP. LSR не производит кодирования информации Diff-Serv в заголовке, подверженном операции pop (т.е., LSR оставляет заголовок "как есть").

Модели туннелирования Diff-Serv поверх MPLS 2.6.Модели туннелирования Diff-Serv

[DIFF_TUNNEL] рассматривает взаимодействие дифференцированных услуг с IP туннелями различного типа. MPLS LSP не формирует IP-туннелей, так как заголовок инкапсуляции MPLS не содержит IP-заголовка и таким образом MPLS LSP не рассматриваются в [DIFF_TUNNEL]. Однако, хотя MPLS LSP не создают IP-туннелей, туннели все же формируются. С точки зрения Diff-Serv LSP имеют много общего с IP-туннелями: Промежуточные узлы (т.е., узлы, размещенные вдоль LSP) видят и обрабатывают только внешнюю информацию Diff-Serv.LSP являются однонаправленными.Внешняя информация Diff-Serv может быть модифицирована в любом промежуточном узле.

Однако, с точки зрения Diff-Serv LSP имеют много существенных отличий от IP-туннелей: Не существует аналогии для поведения предпоследнего узла PHP (Penultimate Hop Popping), используемого IP-туннелями. Более того, PHP оказывает влияние на внешнюю информацию Diff-Serv, сопряженную с LSP, невидимым на концевом узле. В ситуациях, где эта информация не играет роли на выходе LSP, это, очевидно, не приводит ни к каким последствиям. В ситуациях, где эта информация на выходе LSP важна, она должна получаться каким-то иным образом.

Две концептуальные модели туннелирования Diff-Serv через IP-туннели, определенные в [DIFF_TUNNEL], применимы и полезны в случае Diff-Serv поверх MPLS. Эти две модели называются Модель трубы (Pipe Model) и Однородная модель (Uniform Model). Их работа поверх MPLS специфицирована в последующих главах.

Модификация обработки сообщения Hello для поддержки восстановления состояния

Когда узел определяет, что RSVP связь с соседом потеряна, а узел по прошлому знает, что сосед поддерживает восстановление состояния, он должен подождать, по крайней мере, некоторое время, указанное в параметре Restart Time (время повторного запуска) соседа, прежде чем включать процедуры, сопряженные с потерей соединения. Узел может ждать разное время в зависимости от местной политики или конфигурации.

Во время этого периода ожидания, все сообщения Hello должны посылаться со значением Dst_Instance равным нулю, а Src_Instance должен оставаться неизменным. Во время ожидания узел должен также сохранять состояние переадресации RSVP и MPLS для уже установленного LSP, который проходит между данным узлом и соседом. В известном смысле с точки зрения сформированного LSP узел ведет себя так, как если бы он получал периодически от соседа сообщения обновления RSVP. Узел может сбросить состояния RSVP и переадресации для LSP, которые находятся в процессе установления, в случае таймаута их обновления. Обновление состояний Resv и Path на период ожидания должно быть подавлено.

Во время этого периода ожидания, узел может проинформировать вышестоящие узлы о потере связности посредством сообщения PathErr и/или сообщения уведомления с указанием "Control Channel Degraded State" (канал управления не работает). Если такое уведомление послано, тогда по восстановлении канала управления узел должен информировать другие узлы о восстановлении посредством сообщений PathErr и/или уведомления Notify с индикацией "Control Channel Active State" (управляющий канал в активном состоянии).

Когда от соседа приходит новое сообщение Hello, узел должен определить, произошел ли отказ в канале управления или это выход из строя узла. Этот анализ основывается на полученном от соседа Src_Instance. Если значение отличается от полученного от соседа до отказа, тогда соседа следует считать рестартующим. В противном случае, отказ ограничен каналом управления. Процедуры обработки для каждого из случаев описаны ниже.

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

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

MPLS и маршрутизация при нескольких путях

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

Если специфицировано несколько ассоциаций меток для заданного адресного префикса, они могут иметь разные атрибуты.

MPLS и мультикастинг

Мультикастная маршрутизация осуществляется путем формирования мультикаст-деревьев. Дерево, вдоль которого должен переадресовываться конкретный мультикаст пакет, зависит от адресов отправителя и получателя пакета. Когда конкретный LSR является узлом некоторого мультикаст-дерева, он связывает метку с этим деревом. Он рассылает эту ассоциацию вдоль данного дерева. Если рассматриваемый узел принадлежит локальной сети, и имеет партнеров в этой сети, он должен также рассылать указанные ассоциации своим партнерам. Это позволяет вышестоящим узлам использовать одну метку, когда осуществляется мультикатинг для всех нижестоящих объектов LAN.

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

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

Мультипротокольная коммутация меток (протокол MPLS)

Основы протокола MPLS описаны в официальных документах RFC [3-9 и 14]. Существуют публикации и на русском языке [11-13]. Имеются три монографии, посвященных рассматриваемой проблематике [17-19].

Протокол MPLS хорошо приспособлен для формирования виртуальных сетей (VPN) повышенного быстродействия (метки коммутируются быстрее, чем маршрутизируются пакеты). Принципиальной основой MPLS являются IP-туннели. Для его работы нужна поддержка протокола маршрутизации MP-BGP (RFC-2858 [23]). Протокол MPLS может работать практически для любого маршрутизируемого транспортного протокола (не только IP). После того как сеть сконфигурирована (для этого используются специальные, поставляемые производителем скрипты), сеть существует, даже если в данный момент через нее не осуществляется ни одна сессия. При появлении пакета в виртуальной сети ему присваивается метка, которая не позволяет ему покинуть пределы данной виртуальной сети. Никаких других ограничений протокол MPLS не накладывает. Протокол MPLS предоставляет возможность обеспечения значения QoS, гарантирующего более высокую безопасность. Не следует переоценивать уровня безопасности, гарантируемого MPLS, атаки типа “человек посередине” могут быть достаточно разрушительны. При этом для одного и того же набора узлов можно сформировать несколько разных виртуальных сетей (используя разные метки), например, для разных видов QoS. Но можно использовать возможности АТМ (процедура setup), если именно этот протокол применен в опорной сети (возможные перегрузки коммутаторов не в счет).

Для обеспечения структурирования потоков в пакете создается стек меток, каждая из которых имеет свою зону действия. Формат стека меток представлен на рис. 3 (смотри RFC-3032). В норме стек меток размещается между заголовками сетевого и канального уровней (соответственно L2 и L3). Каждая запись в стеке занимает 4 октета.

Рис. 3. Формат стека меток

Рис. 3а. Размещение меток в стеке

Место заголовка МАС может занимать заголовок РРР. В случае работы с сетями АТМ метка может занимать поля VPI и VCI. Смотри рис 4. Глубина стека в данном случае не может превышать 1.

Рис. 4. Формат меток в ячейках АТМ

На рисунке полю СoS соответствует субполю приоритет поля ToS. Поле CoS имеет три бита, что достаточно для поля приоритета IP-заголовка. 6-битовое поле кода дифференцированной услуги DSCP сюда записать нельзя. Можно попробовать разместить этот код в поле самой метки. S - флаг-указатель дна стека меток; TTL - время жизни пакета MPLS.

Существующие версии программного обеспечения Cisco IOS (например, Cisco IOS Release 12.0) содержат набор средств управления трафиком. В частности, имеется возможность формировать статические маршруты и управлять динамическими маршрутами путем манипулирования значениями метрики. Иногда этого вполне достаточно, но в большинстве случаев провайдер нуждается в более эффективных средствах.

Межрегиональные каналы являются одной из основных расходных статей провайдеров. Управление трафиком позволяет IP-провайдеру предложить оптимальный уровень услуг своим клиентам с точки зрения полосы и задержки. Одновременно эта технология снижает издержки обслуживания сети.

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

Управление коммутацией по меткам основывается на базе данных LIB (Label Information Base). Пограничный маршрутизатор MPLS LER (Label Edge Router) удаляет метки из пакетов, когда пакет покидает облако MPLS, у вводит их во входящие пакеты. Схема работы с помеченными и обычными IP-пакетами показана на рис. 5.



Рис. 5. Обработка помеченных и обычных IP-пакетов

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

Информация об имеющихся ресурсах доводится до сведения заинтересованных субъектов с помощью протокола IPG (Interior Protocol Gateway), алгоритм которого базируется на состоянии канала.

Путь туннеля вычисляется, основываясь на сформулированных требованиях и имеющихся ресурсах (constraint-based routing). IGP автоматически маршрутизирует трафик через эти туннели. Обычно, пакет, проходящий через опорную сеть MPLS движется по одному туннелю от его входной точки к выходной.

Управление трафиком MPLS основано на следующих механизмах IOS: Туннелях LSP (Label-switched path), которые формируются посредством RSVP, c расширениями системы управления трафиком. Туннели LSP представляют собой туннельные двунаправленные интерфейсы IOS c известным местом назначения. Протоколах маршрутизации IGP, базирующиеся на состоянии канала (такие как IS-IS) с расширениями для глобальной рассылки ресурсной информации, и расширениях для автоматической маршрутизации трафика по LSP туннелям. Модуле вычисления пути MPLS, который определяет пути для LSP туннелей. Модуле управления трафиком MPLS, который обеспечивает доступ к и запись ресурсной информации, подлежащей рассылке. Переадресации согласно меткам, которая предоставляет маршрутизаторам возможности, сходные с уровнем L2, перенаправлять трафик через большое число узлов согласно алгоритму маршрутизации отправителя.



Одним из подходов управления опорной сетью является определение сети туннелей между всеми участниками обменов. Протокол IGP, работающий в начале туннеля, определяет то, какой трафик должен проходить через любой оконечный узел. Модули вычисление пути и управления MPLS определяют маршрут LSP туннеля. Для каждого туннеля подсчитывается число пропущенных пакетов и байт.

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

Для реализации MPLS управления трафиком сеть должна поддерживать следующие возможности Cisco IOS: Мультипротокольную переадресацию пакетов с использованием меток (MPLS)IP-переадресацию CEF (Cisco Express Forwarding) Протокол маршрутизации IS-IS (Intermediate System-to-Intermediate System; см. RFC-1142, -1195, -2763, -2966 и -2973)

Дополнительные данные о MPLS и управлении трафиком можно найти в документации Cisco (поддерживается в реализациях 7620, 7640, 7200, 7500 и 12000): Cisco IOS Release 12.0 Switching Services Configuration Guide, глава "Tag Switching"Cisco IOS Release 12.0 Switching Services Command Reference, глава "Tag Switching Commands".Cisco IOS Release 11.3 Switching Services Command Reference, Часть 1, глава "Configuring RSVP"Cisco IOS Release 11.3 Network Protocols Command Reference, Часть 1, глава "RSVP Commands". Cisco IOS Release 12.0 Switching Services Configuration Guide, глава "Tag Switching". Cisco IOS Release 12.0 Switching Services Command Reference, глава "Tag Switching Commands".

Протоколы состояния канала типа IS-IS для вычисления кратчайшего пути для всех узлов сети используют алгоритм Дикстры SPF. Маршрутные таблицы получаются на основе дерева кратчайших путей. Эти таблицы содержат упорядоченный набор адресов места назначения и информацию о ближайших соседей. Если маршрутизатор осуществляет прокладку путей на основе алгоритма шаг-за-шагом, первым шагом является физический интерфейс, соединенный с маршрутизатором.

Новые алгоритмы управления трафиком вычисляют пути до одного или более узлов в сети. Эти маршруты рассматриваются как логические интерфейсы исходного маршрутизатора. В данном контексте эти маршруты представляют собой LSP и рассматриваются как TE-туннели.

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

Управление трафиком MPLS: Исключается необходимость ручной конфигурации сетевых устройств, чтобы задать определенные маршруты. Вместо этого, можно положиться на возможности управления трафиком, предоставляемые MPLS.Производится оценка полосы канала и значения трафика при прокладке маршрута через опорную сеть.Имеет механизмы динамической адаптации, которые позволяют сделать опорную сеть устойчивой к отказам даже в условиях, когда несколько путей были рассчитаны в режиме off-line. В случае отказа узлов производится коррекция топологии опорной сети.

В рекомендациях CISCO [15] можно прочесть, что MPLS позволяет провайдеру маршрутизировать потоки данных так, чтобы клиенту гарантировать минимум задержки и максимум пропускной способности.

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

Рассмотрение описания конфигурации MPLS в аппаратах CISCO [15] показывает отсутствие возможности задания какого-либо значения QoS. Но это не означает, что этого не будет возможно уже в 2003 году.

В данном документе предполагается, что

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

В данном документе предполагается, что любой BGP-партнер (включая тот, который поддерживает мультипротокольные возможности, рассмотренные ниже) должен иметь IPv4 адрес (который будет использоваться в атрибуте AGGREGATOR). Следовательно, чтобы BGP-4 мог поддерживать несколько протоколов сетевого уровня, необходимо добавить две вещи:

возможность ассоциирования конкретного протокола сетевого уровня с данными о следующем шаге и

возможность для заданного протокола сетевого уровня работать с NLRI (Network Layer Reachibility Information).

Чтобы идентифицировать протокол сетевого уровня в данной статье используется понятие семьи адресов (Address Family), как определено в [RFC1700].

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

Чтобы обеспечить обратную совместимость, а также упростить введение мультипротокольных возможностей в BGP-4, в данном документе используются новые атрибуты: многопротокольная NLRI достижимости (MP_REACH_NLRI), и многопротокольная NLRI недостижимости (MP_UNREACH_NLRI). Первый из них (MP_REACH_NLRI) используется для хранения набора достижимых адресатов и данных о следующем шаге, который следует использовать для достижения этих мест назначения. Второй атрибут (MP_UNREACH_NLRI) используется для хранения набора недостижимых адресатов. Таким способом партнер BGP, который не поддерживает мультипротокольные возможности, будет просто игнорировать информацию, содержащуюся в этих атрибутах, и не передаст эти данные другим BGP партнерам.

2. Многопротокольная NLRI достижимости - MP_REACH_NLRI (Код типа 14):

Это опционный не транзитивный атрибут, который может использоваться для следующих целей: (a)Чтобы оповестить о возможном пути до партнера(b)Чтобы позволить маршрутизатору сообщать об адресе сетевого уровня маршрутизатора, который следует использовать в качестве следующего шага на пути к месту назначения, указанному в поле информации достижимости сетевого уровня атрибута MP_NLRI.(c)Чтобы позволить данному маршрутизатору уведомить некоторую или все точки подключения к субсети SNPA (Subnetwork Points of Attachment), которые имеются в локальной системе

Атрибут закодирован следующим образом: Идентификатор семейства адресов (2 октета)Идентификатор семейства последующих адресов (1 октет) Длина сетевого адреса следующего шага (1 октет)Сетевой адрес следующего шага (переменная длина)Число SNPA (1 октет)Длина первого SNPA (1 октет)Первое SNPA (переменная длина)Длина второго SNPA (1 октет)Второе SNPA (переменная длина)………………………..Длина последнего SNPA (1 октет)Последнее SNPA (переменная длина)Информация о достижимости сетевого уровня (переменная длина)

Использование и значения этих полей описаны ниже:

Идентификатор семейства адресов:

Это поле содержит код протокола сетевого уровня, соответствующего последующему сетевому адресу. Определенные на данный момент значения этого поля специфицированы в RFC 1700 (смотри раздел кодов семейств адресов).

Идентификатор семейства последующих адресов:

Это поле предоставляет дополнительные данные о типе информации достижимости сетевого уровня, содержащейся в атрибуте.

Длина сетевого адреса следующего шаг:

1-октетное поле, значение которого определяет длину поля "Сетевой адрес следующего шага", измеренную в октетах.

Сетевой адрес следующего шага:

Поле переменной длины, которое содержит сетевой адрес следующего маршрутизатора на пути к системе назначения.

Число SNPA:

1-октетное поле, которое содержит число SNPA, которые перечислены в последующих полях. Значение 0 может использоваться для индикации отсутствия SNPA в данном атрибуте.

Длина N-го SNPA:



1- октетное поле, чье значение определяет длину поля "N-ый SNPA следующего шага ", выраженную в полуоктетах.

N-ый SNPA следующего шага:

Поле переменной длины, которое содержит SNPA маршрутизатора, чей сетевой адрес размещен в поле "Сетевой адрес следующего шага". Поле длины определяет целое число октетов в длине, точнее округленное до целого значение половины длины SNPA, выраженное в полуоктетах; если SNPA содержит нечетное число полуоктетов, значение этого поля дополняется полуоктетом, заполненным нулями.

Информация о достижимости сетевого уровня:

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

Информация о следующем шаге, записанная в атрибуте пути MP_REACH_NLRI, определяет адрес сетевого уровня пограничного маршрутизатора, который следует использовать в качестве следующего шага, из перечня MP_NLRI в сообщении UPDATE. В случае применения атрибута MP_REACH_NLRI для оповещения внешнего партнера, в компоненте следующего шага атрибута маршрутизатор может использовать один из адресов собственных интерфейсов. BGP-отправитель может анонсировать внешнему партнеру интерфейс любого внутреннего маршрутизатора.

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

BGP-партнер не должен никогда устанавливать маршрут, где он сам является следующим шагом.

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

Сообщение UPDATE, которое содержит MP_REACH_NLRI должно также содержать атрибуты ORIGIN и AS_PATH (как в EBGP так и в IBGP обменах). Более того, в IBGP-обменах такое сообщение должно также содержать атрибут LOCAL_PREF. Если такое сообщение получено от внешнего партнера, локальная система проверит, является ли самая левая AS в атрибуте AS_PATH автономной системой партнера, пославшего это сообщение. Если это не так, локальная система пошлет сообщение предупреждения (NOTIFICATION) с кодом ошибки UPDATE Message Error, и субкодом ошибки Malformed AS_PATH.

Сообщение UPDATE, которое не содержит NLRI, отличных от записанных в атрибуте MP_REACH_NLRI, не должно нести в себе атрибута NEXT_HOP. Если такое сообщение содержит атрибут NEXT_HOP, BGP-партнер, который получает это сообщение, должен игнорировать этот атрибут.



3. Мультипротокольное NLRI недостижимости - MP _UNREACH_NLRI (Код типа 15):

Это опционный не транзитивный атрибут, который может использоваться для целей аннулирования недоступных маршрутов. Атрибут имеет следующий формат: Идентификатор семейства адресов (2 октета)Идентификатор последующего семейства адресов (1 октет)Ликвидируемые маршруты (переменная длина)

Использование и значения этих полей представлено ниже:

Идентификатор семейства адресов:

Это поле содержит идентификатор протокола сетевого уровня, ассоциированного с последующим NLRI. В настоящее время, значения, определенные для этого поля, специфицированы в RFC 1700 (смотри раздел коды адресных семейств).

Идентификатор семейства последующих адресов:

Это поле предоставляет дополнительную информацию о типе данных доступности, содержащихся в атрибуте.

Ликвидируемые маршруты:

Поле переменной длины, где перечисляются NLRI для маршрутов, которые отзываются. Когда поле идентификатора семейства последующих адресов соответствует коду, определенному в данном документе, каждое из NLRI кодируется согласно разделу "Кодирование NLRI ".

Сообщение UPDATE, которое содержит MP_UNREACH_NLRI, не обязано нести какие-либо другие атрибуты пути.

4. Кодирование NLRI

Информация достижимости сетевого уровня кодируется в виде одного или более 2-полуоктетов в форме <длина, префикс>, представленной ниже: Длина (1 октет)Префикс (переменная длина)

Использование и значения этих полей представлено ниже:

a) Длина:

Поле длина указывает длину адресного префикса в битах. Длина равная нулю указывает, что префикс соответствует всем (как это специфицировано семейством адресов) адресам.

b) Префикс:

Поле префикс содержит адресный префикс, за которым следует достаточное число бит, чтобы сделать длину поля кратной октету. Заметим, что значение этих бит, не играет роли.

5. Идентификатор семейства последующих адресов

Этот документ определяет следующие значения для поля идентификатора семейства последующих адресов, содержащегося в атрибутах MP_REACH_NLRI и MP_UNREACH_NLRI:

1 – Информация достижимости сетевого уровня, используемая для уникастной переадресации
2 - Информация достижимости сетевого уровня, используемая для мультикастной переадресации
3 - Информация достижимости сетевого уровня, используемая для уникастной и мультикастной переадресации

6. Обработка ошибок



Если BGP- партнер получает от соседа сообщение Update, которое содержит атрибут MP_REACH_NLRI или MP_UNREACH_NLRI, и партнер определяет, что атрибут некорректен, он должен аннулировать BGP-маршруты, полученные от соседа, чье AFI/SAFI совпадает со значением в некорректном атрибуте MP_REACH_NLRI или MP_UNREACH_NLRI. На время BGP сессии, когда получено сообщение Update, отправитель должен игнорировать все маршруты с AFI/SAFI, полученными в ходе сессии.

Кроме того, партнер может завершить BGP сессию, во время которой получено сообщение Update. Сессия должна быть завершена посылкой сообщения-предупреждения с кодом/субкодом, "Update Message Error "/"Optional Attribute Error" (ошибка сообщения обновления/ошибка опционного атрибута).

7. Использование возможности оповещения в BGP

BGP-партнер, который использует мультипротокольные расширения, должен использовать процедуры оповещения о возможностях [BGP-CAP], чтобы определить, может ли он использовать мультипротокольные расширения с конкретным партнером.

В параметре Опционные возможности содержатся следующие поля. Поле кода возможности устанавливается равным 1 (что указывает на возможность многопротокольных расширений). Поле длины возможностей устанавливается равным 4. Формат поля возможностей представлен ниже:

0

7

15

23

31

AFI Резерв SAFI Использование и значение полей: AFIИдентификатор семейства адресов (16 бит), представленный также как в мультипротокольном расширенииРезервЗарезервированное поле (8 бит). Должно быть установлено равным 0 отправителем и игнорироваться получателем.SAFIИдентификатор семейства последующих адресов (8 бит), кодируется также как и в мультипротокольных расширениях

Партнер, который поддерживает множественные комбинации полубайтов <AFI, SAFI>, включает их как множественные возможности в параметр опционных возможностей.

Чтобы иметь двунаправленный обмен маршрутной информацией для конкретного <AFI, SAFI>, между партнерами BGP, каждый из них должен уведомлять другого (через механизм анонсирования возможностей) о поддержке этих конкретных <AFI, SAFI> маршрутов.

8. Соображения IANA



Как специфицировано в данном документе, атрибуты MPL_REACH_NLRI и MP_UNREACH_NLRI содержат поле SAFI (Subsequence Address Family Identifier). Пространство имен SAFI определено в разделе 9. IANA будет поддерживать и регистрировать значения для пространства имен SAFI следующим образом. Значение SAFI = 0 зарезервировано. Значения SAFI 1, 2 и 3 определены в данном документе. Значения SAFI от 4 до 63 должны быть определены IANA на основе политики "IETF согласия", определенной в RFC 2434. Значения SAFI от 64 до 127 должны будут определены IANA, используя принцип " First Come First Served" (первым пришел – первым обслужен), описанный в RFC 2434. Значения SAFI от 128 до 255 предназначены для частного использования и не будут присваиваться IANA.

9. Сравнение с RFC 2283

Данный документ ограничивает использование атрибута MP_REACH_NLRI только случаем <AFI, SAFI, информация следующего шага, ...>.

Данный документ ограничивает применение атрибута MP_UNREACH_NLRI только случаем <AFI, SAFI, ...>.

Данный документ поясняет использование сообщения UPDATE, которое не содержит NLRI, кроме той, что содержится в атрибуте MP_REACH_NLRI.

Этот документ разъясняет обработку ошибок в присутствии атрибутов MP_REACH_NLRI или MP_ UNREACH_NLRI.

Данный документ специфицирует применение BGP оповещений о возможностях в сочетании с мультипротокольными расширениями.

10. Ссылки

[BGP-CAP]Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000.[BGP-4]Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.[Heffernan]Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.[IPv4]Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.[RFC1700] Postel, J. and J. K. Reynolds, "Assigned Numbers", STD 2, RFC 1700, October 1994. (see also http://www.iana.org/iana/assignments.html)

Набор меток

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

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

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

Использование набора меток является опционным, если его нет, можно использовать все метки из допустимого диапазона. Концептуально отсутствие набора меток предполагает применение набора меток {U}, к которому относятся все допустимые метки.

Неявная метка NULL

Неявная метка NULL представляет собой метку со специальной семантикой, которую LSR может связать с адресным префиксом. Если LSR Ru после получения справки в ILM видит, что помеченный пакет P должен быть переадресован следующему Rd, но что Rd разослал ассоциацию неявной метки NULL с соответствующим адресным префиксом, тогда вместо того, чтобы заменить значение метки на вершине стека, Ru опустошает стек меток, а затем переадресует полученный пакет в Rd.

LSR Rd рассылает ассоциацию неявной метки NULL и адресного префикса X в LSR Ru, если и только если:

1. Правила раздела 3.1.2 указывают, что Rd посылает Ru ассоциацию метки для X, и

2. Rd знает, что Ru может поддерживать неявные метки NULL (т.e., что он может очистить стек меток), и

3. Rd является концом LSP (а не прокси концом) для X.

Это заставляет предпоследний LSR на LSP очистить стек меток. Это вполне приемлемо, если конец LSP является концом MPLS для X, далее если предпоследний LSR не очистит стек меток, конечный узел LSP будет должен просмотреть метку, извлечь метку из стека, и затем посмотреть следующую метку (или просмотреть адрес L3, если меток больше нет). При выполнении предпоследним LSR команды pop для стека меток, конец LSP избавляется от необходимости просмотра двух меток, для того чтобы принять свое решение переадресации.

Однако если предпоследним LSR является ATM-коммутатор, он может не иметь возможности выполнить команду pop для стека меток. Следовательно, может быть послана ассоциация неявной метки в LSR, который может поддерживать эту функцию.

Если предпоследний LSR в LSP для адресного префикса X является прокси концом LSP, он действует, как если бы конец LSP разослал ассоциацию неявной метки NULL для X.

Неявная метка NULL (смотри [RFC3031]) представляется как TLV общей метки со значением поля метка, как это специфицировано в [RFC3032].

Некоторые применения MPLS

3.1.  MPLS и трафик, маршрутизируемый шаг-за-шагом

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

Необъединяющие LSR

Процедура переадресации MPLS очень схожа с используемой в ATM и Frame Relay. То есть, приходит блок данных, ищется метка в коммутационной таблице (VPI/VCI или DLCI), на основе результата поиска выбирается выходной порт, а значение метки переписывается. В действительности, можно использовать такие технологии для переадресации MPLS. Протокол рассылки меток может быть использован в качестве сигнального протокола для формирования коммутационных таблиц. К сожалению, эти технологии необязательно поддерживают возможности объединения меток. В ATM, если попытаться осуществить объединение меток, в результате можно получить перекрытие ячеек от различных пакетов. Если ячейки от разных пакетов оказываются перекрытыми, невозможно осуществить сборку пакетов. Некоторые коммутаторы Frame Relay используют коммутацию ячеек на своих внутренних шинах (backplane). Эти коммутаторы могут также быть неспособными поддерживать объединение меток, по той же причине – ячейки разных пакетов могут перекрываться, и сборка исходных пакетов станет невозможной.

Мы предлагаем поддержать два решения этой проблемы. Первое, MPLS будет поддерживать процедуры, которые позволяют определенным ATM-коммутаторам функционировать как LSR, способные объединять метки.

Так как MPLS поддерживает объединяющие и необъединяющие LSR, MPLS содержит также процедуры, которые гарантируют корректное взаимодействие такого оборудования и программ.

2.26.2.  Метки для объединяющих и необъединяющих LSR

Вышестоящий LSR, который поддерживает объединение меток, должен посылать только одну метку на FEC. Вышестоящий сосед, который не поддерживает объединение меток, должен посылать несколько меток на один FEC. Однако не существует метода узнать заранее, сколько нужно меток. Это будет зависеть оттого, сколько имеется вышестоящих LSR для оговоренного FEC.

В архитектуре MPLS, если определенный вышестоящий сосед не поддерживает объединение меток, ему не посылаются какие-либо метки для заданного FEC, если только он напрямую не запрашивает метку для данного FEC. Вышестоящий сосед может сделать несколько таких запросов, и получать каждый раз новую метку. Когда нижестоящий сосед получает такой запрос “сверху”, а сам он не поддерживает объединения меток, тогда он должен в свою очередь запросить у своего нижестоящего соседа новую метку для заданного FEC.

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

Необходимая информация

Информация, транспортируемая в обобщенном запросе метки, имеет формат:

Тип кодирования LSP :8 бит

Указывает на запрашиваемый тип кодирования LSP. Ниже представлена таблица возможных значений этого поля:

Значение		Тип
1		Пакет
2		Ethernet
3		ANSI/ETSI PDH
4		Зарезервировано
5		SDH ITU-T G.707 / SONET ANSI T1.105
6		Зарезервировано
7		Цифровой конверт
8		Lambda (оптическое)
9		Волокно
10		Зарезервировано
11		FiberChannel

ANSI PDH и ETSI PDH типы обозначают соответствующие сетевые технологии. DS1 и DS3 являются примерами ANSI PDH LSP. E1 LSP будет ETSI PDH. Тип кодирования Lambda относится к LSP, которые охватывают все длины волн. Тип кодирования волокно (Fiber) относится к LSP, работающим с оптоволоконным портом.

Тип коммутации : 8 бит

Указывает на тип коммутации, которая должна осуществляться в заданном канале. Это поле необходимо для каналов, которые анонсируют более одного типа коммутации. Это поле следует связать с одним из значений, анонсированных для соответствующих каналов в описателе возможностей маршрутной коммутации (Switching Capability Descriptor), смотри [GMPLS-RTG]. В настоящее время определены следующие значения:

Значение		Тип
1		Packet-Switch Capable-1 (PSC-1)
2		Packet-Switch Capable-2 (PSC-2)
3		Packet-Switch Capable-3 (PSC-3)
4		Packet-Switch Capable-4 (PSC-4)
51		Layer-2 Switch Capable (L2SC)
100		Time-Division-Multiplex Capable (TDM)
150		Lambda-Switch Capable (LSC)
200		Fiber-Switch Capable (FSC)

Обобщенный PID (G-PID): 16 бит

Идентификатор поля данных, транспортируемых через a LSP, т.е., идентификатор уровня клиента данного LSP. Он используется узлами в конечных точках LSP, и иногда предпоследним узлом. Стандартные значения Ethertype используются для пакета и Ethernet LSP; прочие значения перечислены в таблице:

Значение		Тип		Технология
0		Не определено		Все
1		Зарезервировано
2		Зарезервировано
3		Зарезервировано
4		Зарезервировано
5		Asynchronous mapping of E4		SDH
6		Asynchronous mapping of DS3/T3		SDH
7		Asynchronous mapping of E3		SDH
8		Bit synchronous mapping of E3		SDH
9		Byte synchronous mapping of E3		SDH
10		Asynchronous mapping of DS2/T2		SDH
11		Bit synchronous mapping of DS2/T2		SDH
12		Зарезервировано
13		Asynchronous mapping of E1		SDH
14		Byte synchronous mapping of E1		SDH
15		Byte synchronous mapping of 31 * DS0		SDH
16		Asynchronous mapping of DS1/T1		SDH
17		Bit synchronous mapping of DS1/T1		SDH
18		Byte synchronous mapping of DS1/T1		SDH
19		VC-11 в VC-12		SDH
20		Зарезервировано
21		Зарезервировано
22		DS1 SF Asynchronous		SONET
23		DS1 ESF Asynchronous		SONET
24		DS3 M23 Asynchronous		SONET
25		DS3 C-Bit Parity Asynchronous		SONET
26		VT/LOVC		SDH
27		STS SPE/HOVC		SDH
28		POS - No Scrambling, 16 bit CRC		SDH
29		POS - No Scrambling, 32 bit CRC		SDH
30		POS - Scrambling, 16 bit CRC		SDH
31		POS - Scrambling, 32 bit CRC		SDH
32		ATM mapping		SDH
33		Ethernet		SDH, l , волокно
34		SONET/SDH		l , волокно
35		Зарезервировано (SONET против)		l , волокно
36		Цифровой конверт		l , волокно
37		Lambda		Fiber
38		ANSI/ETSI PDH		SDH
39		Зарезервировано		SDH
40		Протокол доступа к каналу SDH LAPS - X.85 и X.86)		SDH
41		FDDI		SDH, l , волокно
42		DQDB (ETSI ETS 300 216)		FiberChannel
43		FiberChannel-3 (услуги)		FiberChannel+
44		HDLC		SDH
45		Ethernet V2/DIX (only)		SDH, l , волокно
46		Ethernet 802.3 (only)		SDH, l , волокно

Метка : переменная длина

Несет в себе данные метки. Интерпретация этого поля зависит от типа канала, где используется метка.

Коммутация по диапазонам длин волн использует тот же формат, что и обобщенная метка, смотри раздел 3.2.1. В контексте коммутации по диапазонам длин волн обобщенная метка имеет следующий формат:

Id диапазона длин волн : 32 бит.

Идентификатор диапазона длин волн. Значение выбирается отправителем и повторно используется во всех последующих сопряженных сообщениях.

Начальная метка : 32 бит

Указывает на идентификатор канала наинизшей длины волны, образующей диапазон, берется из TLV-объекта отправителя.

Конечная метка : 32 бит

Указывает на идентификатор канала наибольшей длины волны, образующей диапазон, берется из TLV-объекта отправителя.

Идентификаторы канала устанавливаются либо при конфигурации, либо протокольными средствами, такими как LMP [LMP]. Они обычно используются как параметр обобщенной метки PSC и LSC.

Набор меток состоит из одной или более объектов Label_Set/TLV. Каждый объект/TLV содержит один или более элементов набора меток. Каждый элемент воспринимается как идентификатор субканала и имеет тот же формат, что и обобщенная метка. Информация в наборе меток имеет формат:

Действие :8 бит

0 - включающий список

Указывает, что объект/TLV содержит один или более субканальных элементов, которые включены в набор меток.

1 - исключающий список

Указывает, что объект/TLV содержит один или более субканальных элементов, которые исключены из набора меток.

2 - включающий диапазон

Указывает, что объект/TLV содержит диапазон меток. Объект/TLV содержит два субканальных элемента. Первый элемент указывает на начало диапазона. Второй элемент указывает на конец диапазона. Значение нуль говорит о том, что соответствующая часть диапазона не имеет ограничения.

3 - исключающий диапазон

Указывает, что объект/TLV содержит диапазон меток, которые исключены из набора меток. Объект/TLV содержит два субканальных элемента. Первый элемент указывает на начало диапазона. Второй - на конец диапазона. Значение нуль говорит о том, что соответствующая часть диапазона не имеет ограничения.

Зарезервировано :10 бит

Это поле зарезервировано. Оно должно быть установлено равным нулю при передаче и игнорироваться при приеме.

Тип метки : 14 бит

Указывает тип и формат меток, содержащийся в объекте/TLV. Значения зависят от сигнального протокола.

Субканал:

Субканал представляет метку (длина волны, волокно...), которая может быть присвоена. Это поле имеет тот же формат, что описан для меток в разделе 3.2.

Для двунаправленных LSP, надо выделить две метки. Установление двунаправленного LSP отмечается наличием объекта/TLV метки для маршрута вверх по течению в соответствующем сигнальном сообщении. Вышестоящая метка имеет тот же формат, что и обобщенная метка, смотри раздел 3.2.

Явная метка (Label Explicit) и запись маршрутов содержит:

L:1 бит Этот бит должен быть равен 0.

U:1 бит Этот бит указывает направление метки. Оно равно 0 для метки сегмента вниз по течению. Оно равно 1 для метки противоположного направления и используется только для двунаправленных LSP.

Метка : переменная

Это поле идентифицирует используемую метку. Формат этого поля идентичен тому, который используется полем метка в обобщенной метке, смотри раздел 3.2.1. Размещение и порядок этих параметров зависит от сигнального протокола.

Следующие данные содержатся в полях защитной информации:

Вторичный (S):1 бит

Когда равен 1, указывает, что запрошенный LSP является вторичным.

Зарезервировано :25 бит

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

Флаги канала :6 бит

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

Определены следующие флаги:

0x20 Улучшенная

Указывает на то, что следует использовать, ту схему защиты, которая более надежна, чем 1+1, напр., 4 волокна BLSR/MS-SPRING.

0x10 Выделенная 1+1

Указывает, что для LSP следует использовать выделенную схему защиты канального уровня, т.е., защиту 1+1.

0x08 Выделенная 1:1

Указывает, что для LSP следует использовать выделенную схему защиты канального уровня, т.е., 1:1.

0x04 Совместная

Указывает, что для LSP следует использовать совместную схему защиты канального уровня, такую как 1:N.

0x02 Незащищено

Указывает, что LSP не должен использовать средства защиты.

0x01 Дополнительный трафик

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

Следующие данные содержатся в полях административной информации статуса:

Отражение (R):1 бит

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

Зарезервировано :28 бит

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

Тестирование (T):1 бит

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

Административно выключено (A): 1 бит

Когда бит равен 1, это указывает, что локальные действия относятся к состоянию "выключено административно".

Аннулирование в процессе (D): 1 бит

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

В Interface_ID содержится TLV, которые имеют следующий формат:

Длина : 16 бит

Указывает полную длину TLV, т.е., 4 + длина поля значения в октетах. Поле значение , чья длина не кратна четырем, должно дополняться нулями так, чтобы длина TLV стало кратным четырем октетам.

Тип :16 бит

Указывает тип идентифицируемого интерфейса. Определены следующие значения:

Тип		Длина		Формат		Описание
1		8		IPv4 Addr.		IPv4
2		20		IPv6 Addr.		IPv6
3		12		см. ниже		IF_INDEX (индекс интерфейса)
4		12		см. ниже		COMPONENT_IF_DOWNSTREAM (Составной интерфейс)
5		12		см. ниже		COMPONENT_IF_UPSTREAM (Составной интерфейс)

Для типов 3, 4 и 5 поле значение имеет формат:

IP-адрес : 32 бита

Поле IP-адрес может включать IP-адрес канала или IP-адрес соответствующего маршрутизатора, содержащийся в TLV адреса маршрутизатора.

ID интерфейса :32 бита. Для 3-го типа применения, ID интерфейса несет в себе идентификатор интерфейса.

Для типов 4 и 5, ID интерфейса указывает на составной канал. Специальное значение 0xFFFFFFFF может быть использовано для обозначения того, что одна и та же метка служит для всех компонентов канала.

Объект запроса уведомления может транспортироваться в сообщениях Path или Resv, смотри раздел 7. Номер класса Notify_Request равен 195 (в форме 11bbbbbb). Запрос уведомления имеет следующий формат:

o Объект запроса уведомления IPv4

Адрес узла уведомления IPv4: 32 бита

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

o Объект запроса уведомления IPv6

Адрес узла уведомления IPv6: 16 байт

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

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

Сообщение уведомления Notify является обобщенным сообщением уведомления. IP-адрес места назначения устанавливается равным адресу запросившего получателя. Сообщение Notify посылается без аварийной опции маршрутизатора. Одно сообщение Notify может содержать несколько уведомлений.

Сообщение Notify имеет тип сообщения 21. Формат сообщения Notify представлен ниже:

<Notify message> ::= <Common Header> [<INTEGRITY>]

[[<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]

[<MESSAGE_ID> ]

<ERROR_SPEC> <notify session list>

<notify session list> ::= [<notify session list> ]

<upstream notify session> |

<downstream notify session>

<upstream notify session> ::= <SESSION> [ <ADMIN_STATUS> ]

[<POLICY_DATA>...]

<sender descriptor>

<downstream notify session> ::= <SESSION> [<POLICY_DATA>...]

<flow descriptor list>

Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, детектировавшего ошибку или отказавшего канала. Определение ERROR_SPEC смотри в [RFC2205]. MESSAGE_ID и сопряженные с ним объекты определены в [RFC2961].

Непосредственная маршрутизация

Явная маршрутизация для уникастинга сопряжена с переписыванием уникастной маршрутной таблицы, с использованием LSP. " Мультикастная явная маршрутизация" может быть определена как перепись дерева, сформированного мультикастным протоколом маршрутизации, с привлечением другого дерева LSP (например, дерева Штайнера, вычисленного где-то off-line). В этой интерпретации современный мультикастинг протокол маршрутизации 'кратчайшего пути' становится устаревшим и может быть заменен сообщениями рассылки меток, которые следуют явным маршрутом (например, ветвь дерева Штайнера).

Другой способ интерпретации "Мультикастная явная маршрутизация" предполагает, что работают мультикастные протоколы маршрутизации, но что сообщения, генерируемые этими протоколами, для формирования дерева используют явно уникастные маршруты (вместо кратчайших путей IGP).

Нестандартные операции

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

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

Неверные входные метки

Что должен сделать LSR, если он получает помеченный пакет с определенной входной меткой, но не имеет ассоциации для этой метки? Соблазнительно думать, что можно просто удалить метки и пакеты будут переадресовываться как непомеченные IP. Однако в некоторых случаях, реализация этого приведет к зацикливанию пакетов. Если вышестоящий LSR полагает, что метка сопряжена с определенным маршрутом, а нижестоящий LSR не считает метку, связанной с чем бы то ни было, и если маршрутизация шаг-за-шагом непомеченных IP-пакетов приведет пакет назад к вышестоящему LSR, тогда образуется петля.

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

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

Независимое управление рассылкой меток

При независимом управлении LSP, каждый LSR может анонсировать метки своим соседям в любое время, когда он этого захочет. Например, работая в независимом режиме Downstream on Demand, LSR может отвечать на запросы присвоения меток немедленно, не дожидаясь присвоения меток со стороны ближайшего узла. При работе в независимом режиме Downstream Unsolicited, LSR может анонсировать присвоение меток для FEC своим соседям всякий раз, когда он готов осуществлять коммутацию для заданного FEC.

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

Независимое управление рассылкой меток против упорядоченного

Существующая терминология для рассылки меток определена лишь для уникастного случая. Далее рассматривается, какой смысл эти термины могут иметь в случае мультикастинга.

При независимом управлении ([ANDE]) каждый LSR может взять на себя инициативу присвоения меток. При упорядоченном управлении ([ANDE]) LSR ассоциирует метку, когда он уже получил ее от последующего узла.

Все описанные выше методы запуска процесса формирования дерева (раздел 5) имеют отношение к независимому управлению. Заметим, что если используется подход с запуском по запросу при независимом управлении, рассылка меток осуществляется, как если бы применялось упорядоченное управление: управляющие сообщения направляются от выходного узла “вверх по течению”, реализуя ту же последовательность анонсирования меток.

Упорядоченное управление не применимо для запуска, управляемого трафиком в случае, когда узел не поддерживает смешенную L2/L3 переадресацию. Согласно таблице 2, этот случай предполагает, что метки запрашиваются вышестоящим LSR. Предположим, что на рис. 11 имеется LSP от S до R1 и нужно проложить новую вервь до R2. B будет воспринимать метки канала A - B только если они уже ассоциированы с каналом B-C. Однако для того чтобы определить метку для канала B-C, B должен уже получать трафик со стороны канала A-B.

Рис. 11.

Нижестоящий LSR: процедура отзыва

В этом случае существует только одна процедура. Когда LSR Rd решает разорвать ассоциацию между меткой L и адресным префиксом X, тогда это решение должно быть доведено до сведения всех LSR, которым эта ассоциация была прислана. Требуется, чтобы уведомление о разрыве ассоциации между L и X было послано Rd в LSR Ru, прежде чем Rd пришлет Ru какие-либо иные ассоциации L с какими-либо префиксами Y, где X != Y. Если Ru узнал о новой ассоциации L и Y, до того как получил данные о разрыве ассоциации L и X, и если пакеты, соответствующие префиксам X и Y, переадресуются из Ru в Rd, тогда в течение некоторого времени Ru будет помечать пакеты, относящиеся к X и к Y меткой L.

Рассылка и отзыв ассоциаций меток осуществляется через протокол рассылки меток. Все протоколы рассылки меток требуют, чтобы был установлен контакт между партнерами рассылки меток (за исключением неявных партнеров). Если LSR R1 установил контакт по рассылке меток с LSR R2, и получил ассоциации меток от LSR R2 через это соединение, тогда если соединение будет разорвано одним из партнеров (либо в результате поломки, либо обычной работы), все ассоциации, полученные через это соединение, должны рассматриваться как отозванные.

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

Нижестоящий LSR: Процедура рассылки

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

Вне зависимости от используемой процедуры рассылки, если ассоциация метки для заданного адресного префикса была послана нижестоящим LSR Rd вышестоящему LSR Ru, и, если в какой-то момент атрибуты ассоциации (как это определено выше) изменились, тогда Rd должен проинформировать Ru о новых атрибутах.

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

NoReleaseOnChange

Ru должен поддерживать ассоциацию, так что он сможет использовать ее немедленно, если Rd станет позднее следующим шагом Ru L3 для X . Эту процедуру следует использовать для реализации свободного режима удержания меток ( Liberal Label Retention Mode).

Нормативные ссылки

[RFC2119]		Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC3036]		Andersson, L., Doolan, P., Feldman, N., Fredette, A. и B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3209]		Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. и G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3212]		Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. и A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3472]		Ashwood-Smith, P. и L. Berger, Editors, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3473]		Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC2119]		Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205]		Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2210]		Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2402]		Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2401, November 1998.
[RFC2406]		Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2401, November 1998.
[RFC2409]		Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2747]		Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication",RFC 2747, January 2000.
[RFC2961]		Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC3209]		Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3471]		Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3477]		Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource Reservation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.

Объединение E-LSP

В домене MPLS два или более LSP могут быть объединены в один маршрутизатором LSR. E-LSP допускают объединение LSP при выполнении следующих условий: E-LSP могут быть объединены, если они поддерживают один и тот же набор BA.

Для E-LSP, использующих согласованную таблицу соответствий EXP<-->PHB, выше приведенное условие объединения должно отслеживаться LSR при формировании метки путем тщательного просмотра того, что наборы PHB для объединяемых LSP полностью совпадают.

Для E-LSP, использующих предварительно сконфигурированные таблицы EXP<-->PHB, LSR не может полагаться на согласованную информацию при объединении маршрутов, так как PHB, поддерживаемые E-LSP, не согласуются при формировании пути. Однако все E-LSP, использующие предварительно сконфигурированные EXP<-->PHB, требуют поддержки одного и того же набора ВА (Behavior Aggregates) в пределах заданной области MPLS Diff-Serv. Таким образом, объединение E-LSP, использующих предварительно сконфигурированные таблицы EXP<-->PHB, разрешено в пределах заданной области MPLS Diff-Serv.

Объединение L-LSP

В области MPLS, два или более LSP могут быть объединены в один LSP в некотором LSR. L-LSP совместим с LSP-объединением при следующих условиях:

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

Заметим, что когда L-LSP объединяются, полоса пропускания, доступная для PSC ниже по течению относительно точки объединения, должна быть достаточной для транспортировки суммарного трафика. Это особенно важно в случае EF-трафика.

Объединение меток

Предположим, что LSR связал несколько входящих меток с конкретным FEC. При переадресации пакетов в этом FEC, хотелось бы иметь одну выходную метку, которая используется всеми такими пакетами. Тот факт, что два разных пакета класса FEC приходят с разными входными метками является нерелевантным. Хотелось бы переадресовывать их с одной и той же выходной меткой. Реализация этого называется "объединением меток". Будем говорить, что LSR способен объединять метки, если он может получать два пакета от разных входных интерфейсов, и/или с разными метками, а посылать оба пакета с одной и той же выходной меткой. Раз пакеты переданы, информация о том, что они пришли от разных интерфейсов и/или с разными входными метками теряется.

Будем считать, что LSR не способен объединять метки, если для любых двух пакетов, которые приходят из разных интерфейсов, или с разными метками, пакеты должны быть либо переданы через разные интерфейсы, или должны иметь разные выходные метки. ATM-LSR, использующие SVC или SVP представления, не могут реализовывать объединение меток.

Если некоторый LSR не может выполнить объединение меток, тогда, если два пакета в одном и том же FEC приходят с разными входными метками, они должны быть переадресованы с разными выходными метками. При объединении меток, число выходных меток на один FEC должно быть равно 1. Без объединения меток, число выходных меток на один FEC может равняться числу узлов в сети.

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

Архитектура MPLS приспосабливает как объединяющие, так не объединяющие LSR, но допускает также возможность того, что имеются LSR, не поддерживающие коммутацию меток.

Объединение потоков в ATM 2.26.3.1. Методы исключения перекрытия ячеек

Существует несколько методов исключения проблемы перекрытия ячеек в ATM, таким образом, позволяющих ATM-коммутатором поддерживать объединение потоков данных:

1. Объединение VP, использующее мультиточечное представление SVP

Когда используется объединение VP, несколько виртуальных путей объединяются в один путь, но пакеты от разных отправителей отличаются разными VCI в пределах данного VP.

2. Объединение VC

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

Объединение VP имеет преимущество в том, что оно совместимо с подавляющим числом реализаций ATM-коммутаторов. Это делает более вероятным то, что объединение VP может использоваться в существующих сетях. В отличие от объединения VC, объединение VP не приводит к каким-либо задержкам в точках объединения, а также не накладывает никаких требований на буферы. Однако это имеет недостаток, так как требует координации пространства VCI в пределах VP. Существует несколько способов реализации этого.

Этот компромисс между совместимостью с существующим оборудованием, сложностью протокола и масштабируемостью предполагает, что желательна поддержка протоколом MPLS объединения как VP, так и VC. Для того чтобы реализовать это каждый ATM-коммутатор, участвующий в MPLS, должен знать, могут ли ближайшие ATM соседи осуществлять объединение VP или VC.

Объект Accounting-таймер (AcctTimer)

Время кодируется в виде двухоктетых целых чисел и измеряется в секундах. Значение таймера рассматривается как временной интервал между двумя событиями.

C-Num = 15,
C-Type = 1, Значение таймера аккоунтинга

Значение опционного таймера используется для определения минимального интервала между периодическими отчетами о типах аккоунтинга. Оно используется PDP для того чтобы охарактеризовать PEP приемлемое значение интервала между не запрошенными аккоунтинг-актуализациями через сообщения-отчеты, когда это применимо. Он обеспечивает для PDP метод управления объемом аккоунтинг-трафика в сети. Диапазон конечных значений времени лежит в пределах 1 - 65535 секунд (два октета). Значение нуль означает, что не должно быть не запрошенных аккоунтинг-актуализаций.

0	1	2	3
//////////////		CCT Timer Value

2.2.16. Объект целостность сообщения (Message Integrity)

Объект целостности (integrity) включает в себя порядковый номер и дайджест сообщения, полезный для аутентификации и проверки целостности сообщения COPS. Когда используется этот объект, он размещается в самом конце сообщения COPS. Дайджест вычисляется для всего сообщения COPS за исключением самого дайджеста. Отправитель сообщения COPS вычисляет и заполняет дайджест-секцию объекта Integrity. Получатель сообщения вычисляет дайджест для этого сообщения и сравнивает его с тем, что хранится в объекте Integrity.

C-Num = 16,
C-Type = 1, HMAC дайджест

Объект HMAC-целостности для вычисления дайджеста сообщения привлекает HMAC (ключевое хэширование для аутентификации сообщения) [HMAC], при этом используется ключ, общий для PEP и PDP.

Объект Integrity специфицирует 32-битовый ID ключа, который определяет специфический ключ, используемый конкретным PEP и его PDP, а также используемый криптографический алгоритм. Для заданного PEPID ID ключа допускает существование одновременно нескольких ключей для PEP и оответствующих ключей PDP. Ключ, идентифицированный ID ключа, используется для вычисления дайджеста сообщения в объекте Integrity. Все программные реализации, как минимум должны поддерживать HMAC-MD5-96, который реализует алгоритм MD5 [MD5] вычисляющий дайджест сообщения длиной 96-бит.

Этот объект включает в себя также порядковый номер, который представляет собой 32-битовое целое число без знака, которое служит для предотвращения атак откликов. Порядковый номер инициируется на фазе обмена сообщениями Client-Open, Client-Accept и инкрементируется каждый раз при посылке очередного сообщения тому же получателю через существующее TCP-соединение. Если порядковый номер достигает значения 0xFFFFFFFF, следующим номер будет равен нулю и процесс продолжится.

Дайджест сообщения COPS вычисляется для области, начиная с заголовка, и вплоть до объекта Integrity (который должен быть последним объектом в сообщении COPS). В эту область попадают заголовок объекта Integrity, ID ключа и порядковый номер (Sequence Number). В случае HMAC-MD5-96, HMAC-MD5 выдает 128-битовый дайджест, который далее укорачивается до 96 бит.

0123Key IDSequence Number 

...Keyed Message Digest...

 

Объект административного статуса

Использование объекта Admin_Status является опционным. Он использует номер класса (Class-Number) 196 (в виде 11bbbbbb). Формат объекта Admin_Status имеет вид:

Описания параметров смотри в [RFC3471].

Объект атрибута сессии

Атрибут класса сессии равен 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Длина имениДлина отображаемой строки в байтах до заполнителя.Имя сессииСтрока символов дополненная нулем

Объект Context

Специфицирует тип события(ий), которое вызвало запрос. Этот объект необходим для сообщений-запросов. Запросы управления доступом, выделения ресурсов, и переадресации зависят от типов клиентов. Для допустимых типов клиента PEP может также послать запрос PDP с целью получения именованной конфигурационной информации. Эта именованная конфигурационная информация может иметь форму, полезную для установления системных атрибутов в PEP, или она может иметь форму правил политики, которые могут быть непосредственно проверены PEP.

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

C-num = 2, C-тип = 1

0123R-TypeM-Type

R-тип (флаг типа запроса)

0x01	Запрос входящего сообщения/Управления доступом (Incoming-Message/Admission Control)
0x02	Запрос выделения ресурсов
0x04	Запрос исходящего сообщения
0x08	Запрос конфигурации

M-Type (Тип сообщения специфичные для клиента (Client Specific) 16-битовые значения типов протокольного сообщения.

Объект Decision

Решение, принятое PDP. Присутствует в откликах. Специфические необязательные объекты решения необходимы в решениях для определенных запросов в зависимости от типа клиента.

C-Num = 6
C-тип = 1, флаги решения (обязательные)

0123Код командыФлаги

Команды:

0 = Решение NULL (Конфигурационные данные недоступны)
1 = Инсталлировать (Admit request/Install configuration)
2 = Удалить (запрос/конфигурацию)

Флаги:

0x01 = Trigger Error (сообщение об ошибке срабатывания, если установлена)

Trigger Error применима для типов клиентов, которые могут посылать уведомления об ошибках для сигнальных сообщений.

Значения поля флаги не применимые для данного контекста R-типа или типа клиента должны игнорироваться PEP.

C-тип = 2, Stateless Data

Этот тип объекта решения несет в себе дополнительную информацию (stateless), которая может быть использована PEP локально. Этот объект имеет переменную длину и его внутренний формат должен специфицироваться для данного типа клиента в соответствующем расширительном документе COPS. Этот объект для сообщений-решений является опционным и интерпретируется согласно текущему контексту.

Ожидается, что даже посторонние PEP могут принимать некоторые простые политические решения в рамках их LPDP

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

C-тип = 3, Данные замещения

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

C-тип = 4, Данные решения, специфические для клиента

Дополнительные типы решений могут быть введены с помощью информационного объекта специфического решения клиента (Client Specific Decision Data Object). Он имеет переменную длину и его внутренний формат должен быть специфицирован для данного типа клиента в соответствующем документе расширения COPS. Он является опционным в сообщениях-решениях и интерпретируется в соответствии с данным контекстом.

C-тип = 5, именованные данные решения

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

Объект дескриптор (Handle)

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

C-Num = 1
C-Type = 1, дескриптор клиента.

Поле дескриптора имеет переменную длину, дескриптор должен отличаться от других дескрипторов клиента того же самого PEP (соединение COPS TCP)для определенного типа клиента. Он всегда выбирается PEP в исходный момент и ликвидируется, когда он более не нужен. Дескриптор клиента используется, чтобы осуществить ссылку на состояние запроса инициализированного некоторым PEP и инсталлированным для типа клиента PDP. PEP специфицирует дескриптор клиента в своих сообщениях запроса (Request), отклика (Report) и ликвидации (Delete), посланных к PDP. Во всех случаях, дескриптор клиента служит для однозначной идентификации конкретного запроса PEP для данного типа клиента.

Значение дескриптора клиента устанавливается PEP и является непрозрачным для PDP. PDP просто выполняет побайтовое сравнение со значением этого объекта с учетом значений дескрипторов объектов других поступивших запросов.

Объект DIFFSERV

Формат объекта DIFFSERV показан ниже. В настоящее время существует два значения C_Types. Тип 1 соответствует объекту DIFFSERV для E-LSP. Тип 2 соответствует объекту DIFFSERV для L-LSP.

Объект DIFFSERV для E-LSP:

класс = 65, C_тип =1

Рис. 8.

Зарезервировано: 28 бит
Это поле зарезервировано. Оно должно быть установлено равным нулю при передаче, и должно игнорироваться при приеме.

MAPnb: 4 бита
Индицирует число MAP-записей, включенных в объект DIFFSERV. Поле может принимать значения от 0 до 8.

MAP: 32 бита
Каждая запись MAP определяет соответствие между одним полем EXP и одним PHB. Запись MAP имеет следующий формат:

Рис. 9.

Зарезервировано: 13 бит
Это поле зарезервировано. Оно должно быть установлено равным нулю при передаче, и должно игнорироваться при приеме.

EXP: 3 бита
Это поле содержит значение поля EXP для соответствия EXP<-->PHB, определенного в этой записи MAP.

PHBID: 16 бит
Это поле содержит PHBID PHB для соответствия EXP<-->PHB, определенного в этой записи MAP. PHBID кодируется так, как это специфицировано в [PHBID].

Объект DIFFSERV для L-LSP:

класс = 65, C_Type = 2

Рис. 10.

Зарезервировано: 16 бит
Это поле зарезервировано. Оно должно быть установлено равным нулю при передаче, и должно игнорироваться при приеме.

PSC: 16 бит
PSC указывает класс обслуживания PHB (Scheduling Class), который должен поддерживаться LSP. PSC кодируется так, как это специфицировано в [PHBID].

Объект Error

Этот объект используется для идентификации конкретных протокольных ошибок COPS. Поле субкода ошибки содержит дополнительную спецификацию ошибки, характерную для данного клиента. Субкоды ошибки для конкретного типа клиента должны специфицироваться в соответствующем документе расширения.

C-Num = 8, C-тип = 1

0123Код ошибкиСубкод ошибки

Код ошибки	Причина
1	Плохой дескриптор
2	Неверный указатель ссылки (Invalid handle reference)
3	Плохой формат сообщения (Malformed Message)
4	Невозможна обработка (сервер не может обслужить запрос)
5	Отсутствует обязательная информация, специфическая для клиента
6	Неподдерживаемый тип клиента
7	Отсутствует обязательный объект COPS
8	Отказ клиента
9	Коммуникационный отказ (Communication Failure)
10	Не специфицировано
11	Закрытие сессии
12	Переадресация на предпочтительный сервер
13

Неизвестный объект COPS:
Субкод (октет 2) содержит C-Num и C-Type (октет 3) неизвестного объекта.14Неуспех аутентификации15Необходима аутентификация

Объект 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 от соседа получено последним. Это поле должно равняться нулю, до тех пор, пока ничего от соседа не получено.

Объект идентификации PEP (PEPID)

Объект идентификации PEP используется, для того чтобы идентифицировать PEP-клиента удаленному PDP. Это необходимо для сообщений Client-Open.

C-Num = 11, C-Type = 1

Поле переменной длины. Это ASCII-строка, завершающаяся нулем, которая дополняется нулями до границы, кратной 32 бит. Идентификатор PEPID должен содержать ASCII-строку, однозначно идентифицирующую PEP в пределах политической области PEP. Например, он может быть статически приписанным IP-адресом PEP или DNS-именем. Этот идентификатор может использоваться PDP в качестве дескриптора для идентификации PEP в его политических правилах.

Объект In-Interface (IN-Int)

Объект In-Interface используется для идентификации входного интерфейса, к которому относится запрос, и PEP, используется обратный адрес и ifindex.

Объект Interface используется также для идентификации принимающего интерфейса через его ifindex. Поле ifindex может быть использовано, чтобы отличать субинтерфейсы от ненумерованных интерфейсов (смотри, например RSVP LIH). Когда PEP поддерживает SNMP, целое число ifindex должно соответствовать тому же целому числу для интерфейса в индексной интерфейсной таблице MIB-II.

Поле ifindex специфицированное в In-Interface обычно имеет отношение к ниже лежащему потоку протокольных сообщений. Поле ifindex является интерфейсом, через который получаются протокольные сообщения.

C-Num = 3
C-Type = 1, IPv4-адрес + Интерфейс

0123 IPv4 Address format ifindex

Для этого типа объекта интерфейса, IPv4-адрес специфицирует адрес, откуда пришло сообщение.

C-Type = 2, IPv6-адрес + Интерфейс

0123 

IPv6 Address format

 ifindex

Для данного типа объекта интерфейса, IPv6-адрес специфицируетIP-адрес, откуда пришло входное сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II PEP, как это описано выше.

Объект явный маршрут

Явные маршруты (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.

Объект Keep-Alive-таймер (KATimer)

Значение времени кодируются в виде 2-октетных целых чисел и измеряются в секундах. Время выдержки таймера рассматривается как приращение.

C-Num = 10,
C-Type = 1, значение таймера Keep-alive

Объект таймер используется для спецификации максимального временного интервала, в течение которого сообщение COPS должно быть послано или получено. Диапазон значений таймаутов лежит в пределах 1 - 65535 секунд. Значение нуль соответствует бесконечности.

0	1	2	3

//////////////Значение таймера KA

Объект коммутируемого интервала длин волн

Коммутация частотных диапазонов использует тот же формат, что и обобщенная метка, смотри раздел 2.2. Метка полосы частот использует C-тип (3),

В контексте коммутации частотных диапазонов, обобщенная метка имеет следующий формат:

Описание параметров смотри в [RFC3471].

Объект LPDP-решение (LPDPDecision)

Решение принятое LPDP PEP (Local Policy Decision Point) может присутствовать в запросах. Эти объекты имеют формат, идентичный формату объектов специфических решений клиента, описанному выше.

C-Num = 7

C-тип = (тот же C-Type что и для объектов решения)

Объект набора меток

Объект Label_Set использует номер класса 36 (в форме 0bbbbbbb) и C-тип 1. Он используется в сообщениях Path. Label_Set имеет следующий формат:

Тип метки: 14 бит

Указывает на тип и формат меток, содержащихся в объекте. Значения соответствуют C-типу объекта RSVP_LABEL. В этом поле используются только младшие 8 бит. Описания других параметров смотри в [RFC3471].

---

---