Туннели управления переадресацией трафика

Одним из требований управления трафиком является возможность изменения маршрута сформированного TE туннеля при определенных условиях, на основе административной политики. Например, в некоторых контекстах, административная политика может требовать изменения маршрута TE туннеля, когда оказывается доступен более "оптимальный" путь. Другим важным контекстом, когда TE туннель должен быть заново маршрутизирован, является отказ в ресурсах для установленного TE туннеля. При некоторых политиках, может быть нужно возвратить TE туннель к исходному маршруту, когда исчезнувший ресурс снова стал доступен.

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

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

Аналогичная ситуация может возникнуть, когда нужно увеличить полосу TE туннеля. Новое резервирование будет сделано по максимуму, но в действительности нужно только приращение между новой и старой полосой. Если в промежуточных узлах политика контролирует сообщения PATH, то сообщения PATH, запрашивающие слишком много полосы, будут отбрасываться. В этой ситуации в зависимости от местной политики простой запрос увеличения полосы без изменения SENDER_TEMPLATE может привести к обрыву туннеля. Комбинация объекта LSP_TUNNEL SESSION и стиля резервирования SE естественным образом подходит для плавного изменения полосы и маршрута. Идея заключается в том, чтобы старый и новый LSP-туннели совместно использовали ресурсы в каналах, где они работают. Объект LSP_TUNNEL SESSION используется, чтобы сузить рабочую область сессии RSVP, в частности TE туннеля. Чтобы однозначно идентифицировать TE туннель, мы используем комбинацию IP адреса места назначения (адрес узла в конце туннеля), ID туннеля и IP адрес узла начала туннеля, которые помещаются в поле расширенного ID туннеля.

Во время изменения маршрута или увеличения полосы пропускания, входные узлы туннеля выступают в RSVP-сессии как два разных отправителя. Это достигается путем включения "LSP ID", который несет в себе объекты SENDER_TEMPLATE и FILTER_SPEC. Так как семантика этих объектов изменилась, им присваивается новые C-типы.

Чтобы осуществить изменение маршрута, входной узел выбирает новый LSP ID и формирует новый SENDER_TEMPLATE. Затем входной узел, чтобы определить новый путь, создает новый ERO. После этого узел посылает новое сообщение Path, используя исходный объект SESSION и новые SENDER_TEMPLATE и ERO. Он продолжает использовать старый LSP и обновляет старое сообщение Path. Для каналов, которые не являются общими, новое сообщение Path обрабатывается как обычное конфигурирование нового LSP туннеля. Для каналов, которые являются общими, объект SESSION и стиль SE позволяют сформировать LSP, разделяющий ресурсы со старым LSP. Как только входной узел получает сообщение Resv для нового LSP, он может передавать по нему трафик и аннулировать старый LSP.

Чтобы осуществить увеличение полосы, может использоваться новое сообщение Path с новым LSP_ID. Делается попытка осуществить резервирование большей полосы при сохранении резервирования для текущего LSP_ID, так чтобы при неудаче большего резервирования старое резервирование осталось в силе.

Удаление состояния с помощью сообщения PathErr

Сообщение PathErr, как это определено в [RFC2205], посылается от узла к узлу отправителю соответствующего сообщения Path. Промежуточные узлы могут инспектировать это сообщение, но не должны ничего предпринимать. В среде, где сообщения Path маршрутизируются согласно IGP, а маршруты могут изменяться динамически, такое поведение является позитивным.

Однако когда используется RSVP с явно определенным маршрутом, часто возникает ситуация, когда ошибка может быть исправлена в узле отправителе или другом узле выше по течению. Для того чтобы привести в порядок ресурсы, отправитель должен получить PathErr и затем либо послать PathTear (или ждать таймаута для сообщений). Это приводит к тому, что пассивные ресурсы удерживаются дольше, чем необходимо, и увеличивается нагрузка от сообщений управления. В ситуации, когда управление пытается восстановить систему после серьезного простоя, загрузка от сообщений и задержка освобождения ресурсов препятствует возможности быстрого восстановления.

Ситуация может существенно улучшиться, если разрешить промежуточным узлам при определенных ошибках удалять состояния. Чтобы облегчить эту процедуру, в объекте ERROR_SPEC определен новый флаг. Два описанных в настоящее время объекта ERROR_SPEC (объекты спецификации ошибки IPv4 и IPv6) содержат однобайтное поле флага. В этом поле определены два флага. Данная спецификация определяет третий флаг, 0x04, Path_State_Removed.

Семантика флага Path_State_Removed означает, что узел, переадресующий сообщение ошибки, удалил состояние Path, ассоциированное с PathErr. По умолчанию, флаг Path_State_Removed всегда равен нулю при генерации или при переадресации сообщения PathErr. Узел, который сталкивается с ошибкой, может установить этот флаг, если ошибка вызывает ликвидацию состояния, заданного в Path. Если узел, устанавливающий флаг, не является местом назначения сессии, он должен сформировать соответствующее сообщение PathTear. Узел, получающий сообщение PathErr, которое содержит объект ERROR_SPEC с установленным флагом Path_State_Removed, может также удалить соответствующее состояние Path. Если состояние Path удалено, в исходящем сообщении PathErr следует установить флаг Path_State_Removed. Узел, который не удаляет ассоциированное состояние Path, не должен устанавливать флаг Path_State_Removed. Узел, который получает сигнал ошибки с флагом Path_State_Removed равным нулю, не должен устанавливать этот флаг, если только он не генерирует соответствующее сообщение PathTear. Заметим, что использование этого флага не вызывает каких-либо проблем совместимости.

UDP и TCP порты

UDP порт для LDP сообщения Hello имеет номер 646. TCP порт для установления LDP сессии также имеет номер 646.

Unsolicited Downstream против Downstream-on-Demand

Архитектура MPLS позволяет LSR непосредственно посылать запросы узлу следующего шага относительно конкретного FEC, и ассоциации метка-FEC. Это называется рассылкой меток по схеме "запрос нижележащего" (downstream-on-demand).

Архитектура MPLS позволяет также LSR посылать ассоциации другим LSR, которые напрямую эти данные не запрашивали. Такой обмен называется рассылкой меток нижележащим без запроса (unsolicited downstream).

Ожидается, что некоторые реализации MPLS будут осуществлять рассылку меток только в режиме downstream-on-demand, другие – только в режиме unsolicited downstream, а некоторые - в обоих режимах. Какой из режимов будет реализован, зависит от характеристик интерфейсов, которые поддерживает конкретная реализация. Однако обе эти схемы рассылки меток могут использоваться в некоторых сетях одновременно. В любом конкретном случае вышестоящий и нижестоящий LSR должны согласовать, какая из схем рассылки будет применена.

Упорядоченный режим управления рассылкой меток

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

FEC относится к самому LSR (включая один из непосредственно связанных с ним интерфейсов).

Маршрутизатор следующего шага для FEC находится за пределами сети с коммутацией по меткам.

Элементы FEC достижимы при пересечении границы маршрутного домена, такого как другая область сети OSPF, или другая внешняя автономная система для OSPF и маршруты BGP [RFC2328] [RFC1771].

Заметим, тот факт, что LSR является выходным для данного FEC, может измениться со временем, в зависимости от состояния сети и конфигурации LSR.

Управление топологией

Мультикастинг таблица маршрутизации (MRT) поддерживается демоном протокола мультикастинг маршрутизации. Модуль устанавливает соответствие (мэпинг) этих топологических данных дерева L3 и маршрутов LSP L2 p2mp.

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

Управление трафиком

В настоящее время используется несколько методов управления трафиком:

1.      Динамическая маршрутизация (, , , ) и т.д.). Здесь нет средства резервирования полосы, но имеется механизм изменения маршрута при изменении значений метрики или из-за выхода из строя узла или обрыва канала. Некоторые из таких протоколов (OSPF, IGRP) могут строить отдельные таблицы маршрутизации для каждого уровня TOS/QOS [1], но метрики для каждого уровня задаются сетевым администратором. Здесь имеется возможность запараллеливания потоков с целью увеличения пропускной способности. Эти протоколы работают только в пределах одной автономной системы (AS). Протокол же BGP, используемый для прокладки путей между автономными системами не способен как-либо учитывать уровень TOS/QOS (использует алгоритм вектора расстояния, что связано с трудностью согласования значений метрик состояния канала администраторами разных AS). Новая версия многопротокольного расширения MP-BGP специально создана для совместной работы с MPLS при формировании виртуальных сетей, но и он безразличен к TOS/QOS.

2.      Формирование виртуальных сетей на уровнях L2 и L3. Протоколы VLAN обеспечивают повышенный уровень безопасности, но не способны резервировать полосу. К этому типу относится и протокол MPLS.

3.      Резервирование полосы в имеющемся виртуальном канале (протокол RSVP). RSVP может работать с протоколами IPv4 и IPv6. Протокол достаточно сложен для параметризации, по этой причине для решения этой задачи был разработан протокол COPS, который существенно облегчает параметризацию. Функция COPS сходна с задачей языка RPSL для маршрутизации.

4.      Автоматическое резервирование полосы при формировании виртуального канала процедурой SETUP в сетях ATM, ISDN, DQDB, Frame Relay и т.д. Управления очередями осуществляется аппаратно, но базовые параметры могут задаваться программно. Программы управления трафиком MPLS позволяют расширяют возможности L2 сетей ATM и Frame Relay.

5.      Использование приоритетов в рамках протокола IPv6. Возможность присвоения потокам меток облегчает, например, разделение аудио- и видеоданных.

6.      Управление перегрузкой (окно перегрузки в TCP, ICMP(4) для UDP-потоков ( L2 и т.д.).

Управление трафиком 5.3.Общая часть

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

Если смешанная переадресация L2/3 не поддерживается (смотри раздел 4), запуск формирования LSP от трафика требует установления режима рассылки меток, в котором метки запрашиваются LSR-Up (режим Downstream on Demand или Upstream Unsolicite). На рис. 10 предполагается, что для определенной группы существует LSP до LSR-Dn1, а другой LSR-Dn2 хочет присоединиться к дереву. Для того чтобы LSR-Dn2 инициировал формирование прохода, он должен уже получать трафик от этого дерева. Это может быть реализовано на L2 или L3. Первый вариант представляет собой проблему цыпленок-яйцо. В последнем случае для добавления ветви L3 необходима поддержка смешанной переадресации L2/L3 в LSR-Up.

Рис. 10. LSR-Up должен запросить метку.

Управление запросами 5.1.Общая часть

Установление LSP может быть запущено путем перехвата исходящих (метка должна быть затребована нижестоящим LSR) или входящих (метка должна быть затребована вышестоящим LSR) управляющих сообщений. На рис. 9 проиллюстрированы эти два случая.

Входящие           Исходящие

Рис. 9. Запуск по запросу (перехват resp. входящих и исходящих управляющих сообщений)

Нижестоящий LSR (LSR-Dn) посылает управляющее сообщение вышестоящему LSR (LSR-Up). В случае, когда входные управляющие сообщения перехватываются и модуль в LSR-Up решает установить LSP, он пошлет LSR-Dn команду LDP bind (режим Upstream nsolicited) или запрос LDP bind (режим Downstream on Demand).

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

Установление сессий LDP и управление ими 2.5.Установление сессии LDP

Обмен сообщениями выявления партнеров между двумя LSR запускает LDP сессию. Сессия формируется в два этапа:

Установление транспортного соединения.

Инициализация сессии

Далее описывается установление LDP сессии между LSR1 и LSR2 с точки зрения LSR1. Это предполагает обмен сообщениями Hello, специфицирующими пространство меток LSR1:a для LSR1 и пространство меток LSR2b для LSR2.

Установление соответствия CLP-->PHB

Если LSR не завершает слой вложенных заголовков MPLS для этой входной метки и использует ATM-инкапсуляцию (т.е., это ATM-LSR), тогда таблица Encaps-->PHB для этого входящего L-LSP заполняется следующим образом:

это таблица CLP-->PHB

таблица соответствия является функцией PSC, которая реализуется в LSP, и должна использовать соответствующие строки для этого PSC из таблицы CLP/PSC-->PHB по умолчанию, определенной в разделе 4.2.2.1.

Например, если входная метка соответствует L-LSP, поддерживающему AF1 PSC, тогда таблица Encaps-->PHB должна заполняться следующим образом:

Поле CLP PHB
0 > AF11
1 > AF12

Если таблица Encaps-->PHB является разновидностью соответствия CLP-->PHB, тогда LSR:

- определяет входное PHB путем просмотра поля CLP уровня инкапсуляции ATM и используемой таблицы CLP-->PHB.

Установление соответствия DE-->PHB

Если LSR не завершает уровень вставных заголовков MPLS для заданной входной метки и использует инкапсуляцию Frame Relay (т.е., это FR-LSR), тогда таблица Encaps-->PHB для заданного входящего L-LSP заполняется следующим образом:

это таблица DE-->PHB

таблица соответствия является функцией PSC, которая реализуется в LSP, и должна использовать соответствующие строки для этого PSC из таблицы DE/PSC-->PHB по умолчанию, определенной в разделе 4.2.3.1.

Установление соответствия DE-->PHB mapping

Если таблица Encaps-->PHB является разновидностью соответствия DE-->PHB, тогда LSR:

- определяет входное PHB путем просмотра поля DE уровня инкапсуляции Frame Relay и используемой таблицы DE-->PHB.

Установление соответствия Encaps-->PHB для входящего E-LSP

В данном разделе определяется, как формируются таблицы Encaps-->PHB контекста Diff-Serv для входящих E-LSP, для того чтобы позволить определение входного PHB.

Соответствие Encaps-->PHB для E-LSP всегда имеет форму таблицы EXP-->PHB. Если метка соответствует E-LSP, для которого не было явно согласована таблица EXP<-->PHB на фазе формирования LSP, таблица EXP-->PHB формируется на основе предварительного конфигурирования, которое обсуждается ниже в разделе 3.2.1.

Установление соответствия EXP-->PHB

Если LSR завершает слой MPLS для данного входного L-LSP, а вход L-LSP имеет интерфейс, которого не является ATM или Frame Relay, тогда таблица Encaps-->PHB заполняется следующим образом:

это действительно соответствие EXP-->PHB

это формирование соответствия является функцией PSC, который продолжает этот LSP, и должен использовать подходящие строки из таблицы соответствия для заданного PSC из обязательной таблицы EXP/PSC-->PHB, определенной в разделе 4.2.1.1.

Например, если входная метка соответствует L-LSP, поддерживающему AF1 PSC, тогда таблица Encaps-->PHB будет заполняться следующим образом:

Поле EXP PHB
001 > AF11
010 > AF12
011 > AF13

LSR, поддерживающий L-LSP для интерфейсов PPP и LAN, является примером LSR, завершающего слой вставных заголовков для входных интерфейсов, которые не являются ATM или Frame Relay.

Если LSR завершает слой вставных заголовков MPLS для этого входного L-LSP и является входом L-LSP для интерфейса ATM или Frame Relay, тогда таблица Encaps-->PHB заполняется следующим образом:

это должно быть действительно соответствие EXP-->PHB. В будущем могут быть определены альтернативные опционные способы заполнения таблицы Encaps-->PHB (например, используя таблицу CLP/EXP--> PHB или DE/EXP-->PHB), но это находится за пределами рассмотрения данной статьи.

когда таблицей Encaps-->PHB является EXP-->PHB, установление соответствия в этом случае является функцией PSC, который продолжает L-LSP, и должен использовать подходящие строки таблицы соответствия для этого PSC из обязательной таблицы EXP/PSC -->PHB, определенной в разделе 4.2.1.1.

Краевой LSR областей ATM-MPLS или FR-MPLS является примером LSR завершающим слой вставных заголовков для входного интерфейса ATM/FR.

Если таблица Encaps-->PHB является разновидностью соответствия EXP-->PHB, тогда LSR:

- определяет входное PHB путем просмотра поля EXP рассматриваемой метки и используемой таблицы EXP-->PHB.

Установление соответствия между FEC и NHLFE (FTN)

Методика "FEC-to-NHLFE" (FTN) устанавливает соответствие между каждым FEC и набором NHLFE. Она используется при переадресации непомеченных пакетов, при необходимости их пометки до переадресации. Если FTN устанавливает соответствие между конкретной меткой и набором NHLFE, который содержит более одного элемента, только один из них должен быть выбран, прежде чем пакет будет переадресован. Процедуры выбора элемента из набора находятся за пределами рассмотрения данного документа.

в интерфейсе LAN, который поддерживает

Если LSP завершается в интерфейсе LAN, который поддерживает трафик нескольких классов 802.1 как в случае [IEEE_802.1], тогда к набору PHB--> Encaps для данного выхода LSP добавляется еще одна таблица соответствия PHB-->802.1. Эта таблица PHB-->802.1 заполняется следующим образом:

это функция PHB, поддерживаемых для данного LSP, можно использовать соответствующие записи этих PHB из предварительно сконфигурированных таблиц PHB-->802.1, описанных в разделе 3.4.4.1.

Заметим, что набор соответствий PHB-->Encaps тогда содержит как таблицу PHB--> EXP, так и PHB-->802.1.



Если набор PHB-->Encaps содержит соответствия типа PHB-->802.1, тогда LSR:

определяет значение, которое следует записать в поле User_Priority данных управления метками инкапсулирующего заголовка 802.1 [IEEE_802.1]. Это делается в результате просмотра выходного PHB в таблице PHB-->802.1.



Если LSP имеет выход через интерфейс LAN, где поддерживается несколько классов трафика 802.1, как это определено в [IEEE_802.1], тогда добавляется еще одна таблица PHB-->802.1, как это рекомендовано в разделе 3.4.4.

Установление соответствия PHB-->CLP

Если LSP завершается в интерфейсе ATM, который не поддерживает переключения по меткам, тогда добавляется одна таблица PHB-->CLP к набору соответствий PHB-->Encaps для исходящего LSP. Эта таблица PHB-->CLP заполняется следующим образом:

это функция PHB, поддержанной в этом LSP, могут использоваться соответствующие записи PHB из таблиц по умолчанию PHB-->CLP, определенных в разделе 3.4.2.1. Может использоваться и механизмы установления соответствий, отличные от определенных в разделе 3.4.2.1. В частности, если в будущем соответствие PHB и CLP будет стандартизовано для операций Diff-Serv поверх ATM, такое стандартизованное соответствие может быть также использовано.

Например, если исходящая метка соответствует LSP, поддерживающему AF1 PSC, тогда в таблицу соответствия PHB-->CLP может быть записано:

PHB поле CLP
AF11 > 0
AF12 > 1
AF13 > 1
EF > 0

Заметим, что в этом случае установление соответствия PHB-->Encaps содержит как соответствие PHB-->EXP, так и PHB-->CLP.

Если набор PHB-->Encaps содержит соответствия типа PHB-->CLP, тогда LSR:

определяет значение, которое следует записать в поле CLP инкапсулирующего заголовка ATM. Это делается в результате просмотра выходного PHB в этой таблице PHB-->CLP.

Если L-LSP является выходным для входного интерфейса ATM (т.е., это ATM-LSR или LSR, базирующийся на пересылке пакетов через интерфейс LC-ATM или через интерфейс ATM, который не поддерживает коммутацию по меткам), тогда к набору PHB-->Encaps для заданного исходящего L-LSPдобавляется таблица PHB-->CLP.

Если L-LSP является выходным для выходного АТМ-интерфейса, который не поддерживает коммутацию по меткам, то таблица PHB-->CLP заполняется так, как это описано в разделе 3.4.2.

Если L-LSP является выходным для выходного LC-ATM, таблица PHB-->CLP заполняется следующим образом:

- это функция PSC, поддерживаемая для этого LSP, и должна использоваться подходящая строка таблицы соответствия для этого PSC из таблицы PHB-->CLP по умолчанию, определенной в разделе 3.4.2.1.

Заметим, что если LSR поддерживает L-LSP, исходящий через интерфейс ATM, тогда набор PHB-->Encaps содержит как таблицу PHB-->EXP, так и таблицу PHB-->CLP. Если LSR является ATM-LSR, поддерживающим L-LSP, тогда набор PHB-->Encaps содержит только таблицу PHB-->CLP.

Установление соответствия PHB-->DE

Если LSP завешается в интерфейсе Frame Relay, который не поддерживает коммутацию по меткам, добавляется еще одна таблица соответствия PHB-->DE к набору таблиц PHB-->Encaps для этого выхода LSP. Эта таблица заполняется следующим образом:

это функция PHB, поддерживаемых этим LSP, можно использовать соответствующие записи этих PHB из таблиц по умолчанию PHB-->DE, определенных в разделе 3.4.3.1. Таблицы, отличные от описанных в разделе 3.4.3.1, также могут использоваться. В частности, если в будущем будет стандартизовано соответствие PHB и DE для работы Diff-Serv поверх Frame Relay, такие стандартизованные таблицы также найдут применение.

Заметим, что в этом случае набор соответствий PHB-->Encaps содержит как таблицы PHB--> EXP, так и PHB-->DE.

Если набор PHB-->Encaps содержит соответствия типа PHB-->DE, тогда LSR:

определяет значение, которое следует записать в поле DE инкапсулирующего заголовка Frame Relay. Это делается в результате просмотра выходного PHB в таблице PHB-->DE.

Если L-LSP является выходным для интерфейса Frame Relay (т.е., это LSR посылающий пакеты через интерфейс LC-FR или Frame Relay, который не поддерживает коммутацию по меткам), к набору PHB-->Encaps для исходящего L-LSP добавляется таблица PHB-->DE.

Если L-LSP является выходным для интерфейса FR, который не поддерживает коммутацию по меткам, таблица PHB-->DE заполняется так, как это описано в разделе 3.4.3.

Если L-LSP является выходным для выходного интерфейса LC-FR, таблица PHB-->DE заполняется следующим образом:

- это функция PSC, поддерживаемая для этого LSP, и должна использоваться подходящая строка таблицы соответствия для этого PSC из таблицы PHB-->DE по умолчанию, определенной в разделе 3.4.3.1.

Заметим, что если LSR является маршрутизатором Edge-LSR, поддерживающим L-LSP с выходным интерфейсом LC-FR, тогда набор PHB-->Encaps содержит как таблицу PHB-->EXP, так и PHB-->DE. Если LSR является FR-LSR, поддерживающим L-LSP, тогда набор PHB-->Encaps содержит только таблицу PHB-->DE.

Установление соответствия PHB-->EXP

Исходящий E-LSP должен всегда иметь карту соответствия PHB-->EXP в качестве составной части таблицы PHB -->Encaps в контексте Diff-Serv.

Если метка соответствует E-LSP, для которого не существует согласованной на фазе формирования LSP таблицы соответствия EXP<-->PHB, таблица PHB-->EXP заполняется на основе предварительно сконфигурированных данных EXP<-->PHB, как это рассмотрено в разделе 3.2.1.

Если метка соответствует E-LSP, для которого таблица EXP<-->PHB была явно согласована при формировании LSP, таблица PHB-->EXP заполняется на основе такого согласования.

Если набор PHB-->Encaps содержит соответствия типа PHB-->EXP, тогда LSR:

определяет значение, которое следует записать в поле EXP соответствующей метки требуемого уровня. Это делается после просмотра выходного PHB в таблице PHB-->EXP.

Если LSR использует вставной заголовок MPLS для исходящего L-LSP, тогда добавляется еще одна таблица PHB-->EXP в набор таблиц PHB-->Encaps для исходящего L-LSP. Эта таблица PHB-->EXP заполняется следующим образом:

- это функция PSC, поддерживаемая для этого LSP, и должна использоваться строка соответствующая этому PSC из обязательной таблицы PHB-->EXP, определенной в разделе 4.4.1.1.

Например, если выходная метка соответствует L-LSP, поддерживающему AF1 PSC, тогда к набору PHB-->Encaps добавляется следующая таблица PHB-->EXP:

PHB Поле EXP
AF11 > 001
AF12 > 010
AF13 > 011

Установление транспортного соединения

Результатом обмена сообщениями Hello является формирование Hello сопредельности для LSR1, которое определяет канал связи (L), и пространства меток LSR1:a и LSR2:b.

Если LSR1 не имеет LDP сессии обмена пространствами меток LSR1:a и LSR2:b, он пытается сформировать TCP-соединение для новой LDP сессии с LSR2.

LSR1 определяет транспортные адреса, которые следует использовать на конце (A1) и на конце LSR2 (A2) TCP-соединения. Адрес A1 определяется следующим образом:

Если LSR1 использует опционный объект, в сообщениях Hello LSR2 он посылает транспортный адрес (TLV), чтобы анонсировать адрес. A1 является адресом, который анонсируется LSR1 через посредство опционного объекта;

Если LSR1 не использует опционный объект транспортного адреса, A1 является адресом отправителя в сообщениях Hello, которые отправляет LSR2.

Аналогично, адрес A2 определяется как:

Если LSR2 использует опционный объект транспортного адреса, A2 является адресом, который LSR2 анонсирует через посредство опционного объекта;

Если LSR2 не использует опционный объект транспортного адреса, A2 является адресом отправителя в сообщении Hello, полученном от LSR2.

LSR1 определяет, будет ли он играть активную или пассивную роль в сессии установления, посредством сравнения адресов A1 и A2, как целых чисел без знака. Если A1 > A2, LSR1 играет активную роль; в противном случае - пассивную.

Процедура сравнения A1 и A2 реализуется следующим образом:

Если A1 и A2 принадлежат разным адресным семействам, они несравнимы, и сессия не может быть реализована.

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

Пусть U2 является абстрактным целым числом без знака, полученным от A2 аналогичным образом.

Сравниваем U1 с U2. Если U1 > U2, тогда A1 > A2; если U1 < U2, тогда A1 < A2.

Если LSR1 является активным, он пытается установить TCP-соединение через стандартный номер порта по адресу A2. Если LSR1 является пассивным, он ждет, пока LSR2 не установит TCP-соединение через стандартный номер порта.

Заметим, что когда LSR посылает сообщение Hello, он выбирает транспортный адрес конца соединения сессии и использует Hello, чтобы анонсировать адрес, либо явно путем включения его в опционный TLV транспортного адреса или неявно, опуская TLV, и используя его в качестве адреса отправителя в сообщении Hello.

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

Уведомление

В этом разделе рассмотрено несколько типов расширений, связанных с уведомлениями. Первое расширение определяет объект набора приемлемых меток (Acceptable Label Set) для поддержки уведомлений в случае ошибок, связанных с метками и других событий в узлах, ответственных за восстановление разрушенных LSP. Второе расширение, объект запроса уведомления (Notify Request), определяет ситуацию, при которой следует посылать уведомление. Третье расширение, сообщение Notify, предоставляет уведомление об общих событиях. Последнее расширение, относящееся к уведомлениям, позволяет удалять состояние Path при обработке сообщений PathErr.

Уведомление об ошибках в метках

Существуют случаи в традиционном MPLS и в GMPLS, которые вызывают сообщения об ошибке, содержащие уведомление "Unacceptable label value" (неприемлемое значение метки), смотри [RFC3209], [RFC3472] и [< раздел смотри меток, набору обычному идентичен меток приемлемых набора Формат [RFC3473]. и [RFC3472] ошибке, об сообщении протокольном специальном соответствующем в транспортируется набор Приемлемый меток). (приемлемый Set" Label "Acceptable помощью с информации такой передачи возможность вводит GMPLS случая, этого покрытия Для приемлемы. быть могут метки какие указать, полезно быть, может ошибки, сообщение генерирующего узла, для происходит, такое Когда>

Внизу по течению

Узел, размещенный внизу по течению, выбирает метку, которая будет представлять поток. Если в запросе специфицирован диапазон меток, метка должна лежать в этом диапазоне. Если свободных меток нет, узел посылает сообщение PathErr с кодом ошибки "routing problem" (проблема маршрутизации) и значением ошибки "label allocation failure" (отказ выделения метки).

Если узел получает сообщение Resv, которое присваивает одно и то же значение метки нескольким отправителям, тогда этот узел может также присвоить одно значение тем же отправителям или любому субнабору этих отправителей. Заметим, что, если узел намерен осуществлять определенную политику в отношении отдельных отправителей в рамках сессии, он должен присвоить уникальную метку этим отправителям.

В случае ATM применимо дополнительное условие. Некоторые ATM узлы не способны объединять потоки. Эти узлы могут уведомлять об этом путем установления бита запроса метки равным нулю. M-бит в объекте LABEL_REQUEST C-Type 2 запроса метки в диапазоне меток ATM служит именно этой цели. M-бит должен быть установлен узлами, которые способны объединять потоки. Если для нескольких отправителей бит M не установлен, узел внизу по течению должен этим отправителям присвоить уникальные метки.

Когда метка присвоена, узел формирует новый объект LABEL. Узел затем посылает новый объект LABEL в качестве части сообщения Resv предшествующему узлу. Узел должен быть готов переадресовывать пакеты, содержащие присвоенные метки, до посылки сообщения Resv. Объект LABEL должен содержаться в блоке состояния резервирования. Он потом используется для формирования Resv сообщения.

Ожидается, что узел пошлет сообщение Resv, прежде чем перезапустит свой таймер, если содержимое объекта LABEL изменяется.

Восстановление и истечение пригодности

Клиент поддерживает две временные переменные, T1 и T2, которые специфицируют времена, когда клиент пытается расширить время действия своего сетевого адреса. T1 равно времени, когда клиент попадает в состояние RENEWING и пытается контактировать с сервером, который предоставил клиенту сетевой адрес. T2 равно времени, когда клиент перешел в состояние REBINDING и пытается контактировать с каким-то сервером. T1 должно быть раньше T2, которое в свою очередь, должно быть раньше, чем время, когда истекает период годности конфигурационного набора параметров.

Чтобы исключить необходимость синхронизации часов, T1 и T2 выражаются в опциях в относительных единицах [2].

В момент T1 клиент переходит в состояние RENEWING и посылает серверу (уникастно) сообщение DHCPREQUEST с тем, чтобы продлить действие набора конфигурационных параметров. Клиент устанавливает поле 'ciaddr' в DHCPREQUEST равным его текущему сетевому адресу. Клиент записывает локальное время, когда было послано сообщение DHCPREQUEST. Клиент не должен включать идентификатор сервера в сообщение DHCPREQUEST.

Любые сообщения DHCPACK, которые приходят с 'xid', не согласующимся с ‘xid' из сообщения клиента DHCPREQUEST, игнорируются. Когда клиент получает от сервера DHCPACK, он вычисляет время истечения пригодности конфигурационного набора параметров (равно сумме времени, когда клиент посылал сообщение DHCPREQUEST и длительности пригодности конфигурационного набора параметров из сообщения DHCPACK). Клиент успешно восстанавливает свой сетевой адрес, возвращается в состояние BOUND и может продолжить свою сетевую активность.

Если не приходит никакого DHCPACK до T2, клиент переходит в состояние REBINDING и посылает широковещательно сообщение DHCPREQUEST с целью расширения времени действия конфигурационного набора. Клиент устанавливает поле 'ciaddr' в DHCPREQUEST равным его текущему сетевому адресу. Клиент не должен включать 'server identifier' в сообщение DHCPREQUEST.

Времена T1 и T2 конфигурируются сервером посредством опций. T1 по умолчанию равно (0.5 * duration_of_lease). T2 по умолчанию равно (0.875 * duration_of_lease). Чтобы исключить синхронизацию восстановления состояния клиентов, времена T1 и T2 должны быть выбраны с некоторым случайным разбросом относительно фиксированных значений.

Клиент может решить обновить или продлить время действия конфигурационного набора вплоть до T1. Сервер может решить расширить длительность пригодности конфигурационного набора параметров в соответствии с политикой сетевого администратора.

Как в состоянии RENEWING, так и в REBINDING, если клиент не получает отклика на свое сообщение DHCPREQUEST. Клиент должен ждать половину остающегося времени вплоть до T2 (в состоянии RENEWING) и половину остающегося времени действия конфигурационного набора (в состоянии REBINDING), как минимум 60 секунд, прежде чем осуществить повторную отправку сообщения DHCPREQUEST.

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

Время жизни (TTL)

При традиционной IP переадресации, каждый пакет имеет в заголовке значение поля "Time To Live" (TTL). Когда бы пакет ни проходил через маршрутизатор, его TTL уменьшается на 1. Если TTL достигает 0, прежде чем пакет достигнет места назначения, он отбрасывается.

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

(i)     TTL как способ подавления зацикливания;

(ii)    TTL как метод реализации других функций, таких как ограничение области распространения пакета.

Когда пакет движется по LSP, он должен появляться с тем же значением TTL, которое он бы имел, если бы он проходил через ту же последовательность маршрутизаторов, без коммутации меток. Если пакет проходит через иерархию LSP, полное число пройденных шагов-LSR должно быть отражено в его значении TTL. Способ, которым обрабатывается поле TTL, может варьироваться в зависимости от того, размещены ли значения меток MPLS в прослойке между заголовками [MPLS-SHIM], или метки MPLS транспортируются в заголовке L2, таком как заголовок ATM [MPLS-ATM] или заголовок frame relay [MPLS-FRMRLY].

Если значения меток вставлены в "прослойку", которая размещается между канальным и сетевым заголовками, тогда эта прослойка должна иметь поле TTL, которое должно заполняться также, как аналогичное поле заголовка сетевого уровня, декрементироваться при каждом шаге LSR, и копироваться в TTL-поле заголовка сетевого уровня, когда пакет выходит из его LSP.

Если значения меток записаны в заголовке канального уровня (например, поле VPI/VCI в заголовке AAL5 ATM), а помеченные пакеты переадресуются переключателем уровня L2 (например, ATM-переключателем), а канальный уровень сам не имеет поля TTL, тогда будет невозможно декрементировать TTL при каждом шаге LSR. Сегмент LSP, который состоит из последовательности LSR, которые не способны декрементировать TTL пакетов, будет называться сегментом "non-TTL LSP".

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

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

В облаке MPLS маршруты определяются

В облаке MPLS маршруты определяются протоколом уровня L3. Чтобы улучшить рабочие характеристики сети эти маршруты могут быть преобразованы в пути уровня L2. Кроме этого, MPLS предлагает средства улучшения сетевых услуг, такие как QoS/CoS, управление трафиком и т.д.
Существующие уникастные протоколы маршрутизации формируют некоторый (оптимальный) кратчайший путь для определенной пары отправитель-получатель. Заметим, что уникастные протоколы могут работать по-разному в случае путей с эквивалентной метрикой. Для мультикастинга оптимальное решение (минимальная цена соединения N узлов) предполагает вычисление дерева Штайнера (Steiner). К сожалению, ни один современный мультикастный протокол маршрутизации не может сформировать такого дерева. Разные мультикастные протоколы формируют различные деревья.
Обсуждение в данном документе концентрируется на протоколах внутридоменной мультикастинг маршрутизации.


Документ RFC 822, который прослужил без малого 20 лет, регламентировал работу лишь с текстовыми сообщениями (передача аудио- видео- или графических сообщений в нем не рассматривалась). Но даже в случае чисто текстовых документов возникали проблемы при работе с языковыми наборами, требующими символов, которые отсутствуют в US-ASCII.
Одним из существенных ограничений традиционной электронной почты, базирующейся на RFC 821-822, является установка предельного размера строки (1000 7-битовых US-ASCII символов). Это вынуждало пользователей конвертировать текст различными методами в последовательность US-ASCII-кодов (например, процедура uuencode или преобразование в коды Base-64).
Существенные проблемы возникали при почтовом обмене между узлами, поддерживающими протоколы RFC 822 и X.400. Протокол X.400 [X400] определяет механизм включения нетекстовых материалов в почтовые сообщения. Существующие протоколы согласования работы X.400 и RFC 822 предполагают, что X.400 осуществляет преобразование нетекстовых вставок в формат IA5Text, или такие сообщения просто выбрасываются. Отправитель сообщения часто не знает о возможностях получателя, что может привести к тому, что последний, получив сообщения, попросту не сможет его прочесть. Таким образом, нужен механизм согласования возможностей отправителя и получателя на начальной стадии их взаимодействия до начала передачи тела сообщения.
В протоколе MIME регламентируется следующее:
Поле заголовка MIME-Version, которое характеризует версию протокола и позволяет почтовым агентам согласовать свои возможности и исключить конфликты с устаревшим программным обеспечением.
Поле заголовка Content-Type, которое используется для спецификации типа среды и субтипа данных в теле сообщения, а также для описания канонической формы этих данных.
Поле заголовка Content-Transfer-Encoding, которое может использоваться для задания типа преобразования.
Два дополнительные поля заголовка, предусмотренные для уточнения описания данных в теле сообщения (Content-ID и Content-Description).


Современные протоколы Интернет с самого начала создавались таким образом, чтобы их было легко расширить или модернизировать. В частности, MIME [RFC-2045] является открытой системой, допускающей введение новых типов объектов, символьных наборов и методов доступа без изменения базового протокола. Однако необходим процесс регистрации, чтобы гарантировать, что набор таких значений соответствует стандарту и может использоваться в общедоступных сетях.
Здесь рассматриваются процедуры регистрации, которые осуществляются через IANA (Internet Assigned Numbers Authority), центральной инстанции для решения этих проблем.
Процесс регистрации для типов среды был первоначально определен в контексте асинхронной почтовой среды Интернет. В этой почтовой среде существует необходимость ограничить число возможных типов среды, чтобы увеличить вероятность успешного взаимодействия с удаленной почтовой системой, когда ее возможности заранее не известны.


В разделе 2.9 описания архитектуры MPLS [2] протокол рассылки меток определен как набор процедур, с помощью которых один маршрутизатор LSR (Label Switched Router) информирует другие о значении меток, используемых для переадресации трафика между ними и через них. Архитектура MPLS не предполагает существования единственного протокола рассылки меток. Данная статья представляет собой спецификацию расширения протокола RSVP для формирования маршрутов (LSP) с коммутацией по меткам в MPLS-сетях.
Несколько новых особенностей, описанных здесь, мотивировались требованиями управления трафиком в рамках MPLS (смотри [3]). В частности, расширенный протокол RSVP поддерживает реализацию явной прокладки LSP, с или без резервирования ресурсов. Он также поддерживает плавное изменение маршрута LSP, установление приоритетов и обнаружение циклических путей.
LSP, сформированные RSVP, могут использоваться для транспортировки потоков трафика ("Traffic Trunks"), как это описано в [3]. Два LSP между отправителем и получателем могут образовывать единый поток трафика. Наоборот несколько потоков трафика могут транспортироваться одним LSP, если бы, например, LSP могли предоставлять несколько классов услуг. Применимость этих расширений обсуждается в [10].
Так как трафик, который проходит по маршруту с коммутацией меток, определен меткой, заданной входным узлом LSP, эти маршруты могут рассматриваться как туннели, обеспечивающие связь между обычной IP-маршрутизацией и механизмами отбора (фильтрации). Когда LSP используется так, мы называем их LSP-туннелями.
LSP-туннели допускают реализацию различных политик оптимизации работы сети. Например, LSP-туннели могут обходить автоматически или вручную точки отказов в сети, области перегрузок или узкие места. Более того, несколько параллельных LSP-туннелей могут быть проложено между двумя узлами, и трафик между этими узлами может быть направлен через эти LSP-туннели согласно местной политике маршрутизации. Хотя предполагается, что управление трафиком (то есть, оптимизация рабочих характеристик сети) является важным приложением этой спецификации, расширенный протокол RSVP может быть использован в более широком контексте.
Целью данной статьи является описание использования RSVP для формирования LSP-туннелей. Предполагается полностью описать все объекты, форматы пакетов и процедуры, необходимые для реализации совместимых реализаций. Определено несколько объектов, которые улучшают управление и диагностику LSP-туннелей. В статье обсуждаются также средства быстрого детектирования отказа узлов посредством нового сообщения HELLO.
Все объекты и сообщения, обсуждаемые в данной статье, являются опционными по отношению RSVP. В данной статье обсуждается ситуация, когда определенный объект не поддерживается конкретным узлом.


В области MPLS [MPLS_ARCH], когда поток данных проходит по общему пути, маршрут с коммутацией по меткам LSP (Label Switched Path) может быть сформирован с привлечением сигнальных протоколов MPLS. Во входном маршрутизаторе с коммутацией по меткам LSR (Label Switch Router), каждому пакету присваивается метка, и он передается далее “вниз по течению”. В каждом LSR вдоль LSP, метки используются для определения следующего шага переадресации пакета.
При предоставлении дифференцированных услуг Diff-Serv (Differentiated Service) [DIFF_ARCH] все IP-пакеты, проходящие через канал и требующие того же уровня Diff-Serv, образуют ансамбль BA (Behavior Aggregate). Во входном узле области Diff-Serv, пакеты классифицируются и помечаются с помощью кода DSCP (Diff-Serv Code Point), который соответствует их ансамблю BA. В каждом промежуточном узле, DSCP используется для определения пошагового поведения PHB (Per Hop Behavior), которое задает последовательность обработки и, в некоторых случаях, вероятность отбрасывания пакетов.
В данном документе рассмотрена схема поддержки ансамблей ВА Diff-Serv, чье PHB-поведение определено (в [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) для сетей MPLS. Данная схема основана на использовании комбинации двух типов LSP: LSP, которые могут транспортировать несколько ансамблей ВА, так что поле EXP заголовка MPLS передает LSR характер PHB, которое следует применить к пакету.LSP, которые транспортируют только один ансамбль ВА, так что обработка пакетов в LSR целиком определяется значением их метки, приоритет отбрасывания пакета задается полем EXP заголовка MPLS или на уровне инкапсуляции канала специфическим механизмом отбрасывания (ATM, Frame Relay, 802.1).
Как указано в [DIFF_HEADER], сервис провайдеры не должны использовать одни и те же механизмы узла или конфигурации для дифференциации услуг внутри сети, и свободно могут конфигурировать параметры узла любым способом, который подходит для них и соответствует объективным условиям управления трафиком. Таким образом, предложение, рассмотренное в данном документе, предоставляет сервис провайдерам достаточную свободу того, как осуществлять маршрутизацию для разных классов услуг Diff-Serv или как управлять трафиком в пределах их области ответственности (например, разделить классы услуг, поддерживаемые через разные LSP и маршрутизируемые независимо, и классы услуг поддерживаемые одним LSP и маршрутизируемые вместе).
Так как протокол MPLS ориентирован на маршрут, он может в потенциале обеспечить большее быстродействие и более предсказуемые возможности защиты и восстановления при изменениях топологии, которые обычны для IP-систем, маршрутизируемых пошагово. В данном документе мы называем это "MPLS защитой". Хотя такие возможности и связанные с ними механизмы находятся за пределами данной спецификации, отмечается, что они могут предложить разные уровни защиты для различных LSP. Так как рассмотренное здесь решение позволяет сервис провайдеру выбрать то, как следует установить соответствие между классами обслуживания Diff-Serv и LSP, оно предоставляет определенную гибкость в выборе уровня защиты для различных классов услуг Diff-Serv (например, некоторые классы услуг могут поддерживаться LSP, обеспечивающими такую защиту, другие LSP могут не предлагать такой защиты).
Более того, решение, предлагаемое в данном документе, позволяет сохранять пространство меток и уменьшает объем обменов, сопряженных с процедурами set-up/tear-down, прибегая, где возможно, к использованию нескольких LSP для заданного FEC (Forwarding Equivalent Class) [MPLS_ARCH].
Эта спецификация позволяет поддерживать в рамках сетей MPLS дифференциальные услуги как для IPv4, так и IPv6.
Схема, описанная в данном документе, не препятствует использованию битов поля EXP для поддержки явного уведомления о перегрузке ECN (Explicit Congestion Notification) совместно с Diff-Serv в рамках MPLS. Однако способы поддержки ECN в среде MPLS в данной статье не рассматриваются.


Архитектура протокола MPLS [RFC3031] была определена для переадресации пакетов на основе меток. В этой архитектуре предполагается, что маршрутизаторы LSR способны (a) распознавать границы пакетов или ячеек, и (b) могут обрабатывать заголовки пакетов (для LSR, способных распознавать границы пакетов) или заголовки ячеек (для LSR, способных распознавать границы ячеек).
Исходная архитектура теперь распространена на LSR, которые не могут распознавать ни границы пакетов, ни границы ячеек, и, следовательно, не могут переадресовать данные на основе информации, содержащейся в заголовках пакетов или ячеек. Такие LSR в частности включают в себя приборы, где решение о переадресации принимается на основе временного домена, длины волны или номера физического порта.
Подобные LSR, или точнее интерфейсы LSR, могут быть отнесены к следующим классам:
Интерфейсы, которые распознают границы пакетов/ячеек и могут переадресовать данные с учетом содержимого заголовка пакета/ячейки. Примерами могут служить интерфейсы маршрутизаторов, которые переадресуют данные на основе содержимого промежуточных заголовков, интерфейсы ATM-LSR, которые переадресуют данные на основе VPI/VCI ATM. Такие интерфейсы считаются способными коммутировать пакеты (PSC - Packet-Switch Capable).
Интерфейсы, которыеи переадресуют данные на основе циклических временных доменов. Примером такого интерфейса является соединение SONET/SDH. Такие интерфейсы считаются мультиплексирующими по времени (TDM).
Интерфейсы, которые переадресуют данные на основе длины волны, на которой данные получены. Примером такого интерфейса является оптические коммутаторы, которые работают на уровне отдельных длин волн. Такие интерфейсы считаются l -переключателями LSC (Lambda Switch Capable).
Интерфейсы, которые переадресуют данные на основе положения данных в реальном физическом пространстве. Примером такого интерфейса является оптическое подключение, которое работает на уровне одного (или нескольких) волокон. Такие интерфейсы считаются оптическими переключателями FSC (Fiber-Switch Capable).


Протокол обобщенного MPLS раздвигает его применимость с поддержки пакетных интерфейсов (PSC) и коммутации до поддержки трех новых классов интерфейсов и коммутации:TDM (Time-Division Multiplex - мультиплексирование по времени), l-коммутатор (LSC) и волоконный коммутатор (FSC). Функциональное описание расширений MPLS, необходимых для поддержки новых классов интерфейсов и коммутации сделано в [RFC3471]. Этот документ рассматривает специфические форматы RSVP-TE и механизмы, необходимые для поддержки всех четырех классов интерфейсов.
[RFC3471] следует рассматривать как составную часть этого документа. В этом документе определены также возможности RSVP-TE, для поддержки быстрого уведомления об отказах, смотри разделы 4.2 и 4.3.


Язык описания маршрутной политики RPSL (Routing Policy Specification Language) позволяет оператору сети специфицировать маршрутную политику на различных уровнях иерархии Интернет, например, на уровне автономных систем (AS). Так что низкоуровневые конфигурации маршрутизаторов могут генерироваться на основании спецификаций RPSL. Язык RPSL является расширяемым и не препятствует внедрению новых протоколов маршрутизации.
Язык RPSL призван заменить язык спецификации маршрутной политики, используемый в настоящее время и описанный в документах RIPE-181 [6] или RFC-1786 [7]. RIPE-81 [8] был первым языком, использованным в Интернет для спецификации маршрутных политик. В процессе использования RIPE-181 стало понятно, что некоторые политики не могут быть специфицированы и необходим более совершенный язык.
Язык RPSL был сконструирован так, чтобы описание всей политики маршрутизации записывалось в одну распределенную базу данных, улучшая целостность маршрутизации в Интернет. RPSL не является языком конфигурации маршрутизатора. Язык RPSL сформирован так, чтобы конфигурация маршрутизатора осуществлялась на основе описания маршрутной политики автономной системы (класс aut-num) в сочетании с описанием маршрутизатора (класс inet-rtr), которое предоставляет идентификатор маршрутизатора, номер автономной системы, описания интерфейсов и партнеров маршрутизатора. Эти данные используются совместно с глобальной базой данных карты автономных систем (класс as-set), и информацией об автономных системах отправителях и о маршрутных префиксах (классы route и route-set).
Язык RPSL является объектно-ориентированным, то есть, объекты содержат блоки описания политики и административную информацию. Эти объекты регистрируются в IRR (Internet Routing Registry) авторизованными организациями. О IRR смотри [1, 17, 4].
Далее рассматриваются классы, которые используются для определения различных политик и административных объектов. Класс "mntner" определяет средства, предназначенные для добавления, уничтожения и модификации набора объектов. Классы "person" и "role" описывают технический и административный персонал, с которым можно установить контакт. Автономные системы (AS) специфицируются с помощью класса "aut-num". Маршруты специфицируются посредством класса "route". Наборы объектов могут быть определены с помощью классов "as-set", "route-set", "filter-set", "peering-set" и "rtr-set". Класс "dictionary" предоставляет возможность расширения возможностей языка. Класс "inet-rtr" используется для спецификации маршрутизаторов. Многие из этих классов были определены ранее, смотри [6, 13, 16, 12, 5].

Введение в MPLS

В данном документе специфицирована архитектура многопротокольной коммутации меток (MPLS).

Введение в MPLS, TE и QoS

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

1. Базовые предпосылки

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

Период экстенсивного развития сети Интернет завершился несколько лет тому назад даже в РФ. Сейчас многие сервис-провайдеры пытаются привлечь клиентов дополнительными информационными услугами IP-телефония, интерактивные игры, доступ к разнообразным базам данных и депозитариям, электронным магазинам, видеоконференции, видео-телефония и т. д. Клиенты же ищут не просто доступа к Интернет, а интересуются полосой пропускания, безопасностью, стабильностью связи. Именно с этим сопряжен бум разработок основополагающих документов (RFC) в последние 5 лет. По этой причине многие компании, в первую очередь производящие сетевое оборудование, уделяют повышенное внимание средствам управления трафиком (ТЕ) и QoS.

Если рассмотреть ситуацию на уровне L2, здесь имеется сильная зависимость от физического уровня (L1). В сетях с маркерным доступом (Token Ring или FDDI, см. ) существуют механизмы управления приоритетом и способы контроля доступа, гарантирующие определенное значение задержек сетевого отклика. В сетях ISDN и в особенности в ATM предусмотрен целый арсенал средств управления, работающих на фазе установления виртуального канала (процедура SETUP). Для Ethernet до последнего времени ситуация была много хуже. Здесь только некоторые переключатели поддерживают VLAN. Технология виртуальных сетей L2 позволяет сформировать в локальной сети соединение точка-точка. В таком соединении можно гарантировать пропускную способность на уровне 10/100Мбит/c. К сожалению VLAN L2 создаются и модифицируются, как правило администратором, но можно эту проблему перепоручить сценарию, например, на PERL, работающему с демоном SNMP сетевого прибора. В такой сети можно также гарантировать низкий уровень разброса времени реакции сети. Если сформировать VLAN с числом узлов (N) больше двух, можно гарантировать полосу лишь не ниже (10/100)/N. Для произвольной сети Ethernet никаких гарантий на уровне L2 предоставить нельзя. Здесь можно рассчитывать только на вышележащие уровни (IP/TCP/UDP).

Принципы организации приоритетного трафика на уровне L2 рассмотрены в стандарте 802.1р. Стандарт 802.1р является частью стандарта 802.1D (мостовые соединения). В протоколе 802.1Q определена 4-байта метки (смотри рис.1). Поле EtherType=TPID (Tagged Protocol Identifier) содержит код 0x8100. Это поле соотвествует полю тип протокола стандартного поля кадра Ethernet и указывает на необходимость обработки кадра согласно требованиям IEEE 802.1Q. Смотри .

Рис. 1. Формат меток VLAN на уровне L2 (стандарт 802.1р).

Поле приоритета пользователя - 3 бита, 1-битовое поле CFI (Canonical Format Identifier) и 12-битовое поле VID (идентификатор виртуальной сети) называются TCI (Tagged Control Information). 3-битовое поле IP-приоритета размещается здесь без проблем. После введения метки в кадр нужно пересчитать контрольную сумму FCS. Канальный уровень в этом случае должен поддерживать множественные очереди. Добавление метки может привести к превышению предельно допустимой длины кадра (1518 байт). В этой связи IEEE разрабатывает спецификацию 802.3ас, где максимальная длина кадра равна 1522 октета. Группа IETF, разрабатывающая систему обеспечения требуемого уровня услуг на специфических нижних уровнях ISSLL (Integrated Services over Specific Lower Layers), предлагает способы отображения запросов протокола резервирования уровня L3 (RSVP) на 802.1р с помощью системы управления полосой пропускания субсети SBM (Subnet Bandwidth Manager). Смотри . Протокол SBM предполагает, что одна из станций в субсети выполняет функцию DSBM (Designated SBM), и осуществляет управление доступом для всех запросов на резервирование ресурсов, посылаемых DSBM-клиентами. При работе протокола SBM используются мультикатсинг-адреса 224.0.0.17 (все станции прослушивают этот адрес), а DSBM-кандидаты прослушивают - 224.0.0.16. Данная технология может использоваться, например, в IP-телефонии (TDMoIP - Time Division Multiplexing over IP)). В этом случае UDP-порт порт получателя = 2142.
Топология связей в локальной сети на уровне L3 определяется протоколами маршрутизации (статическими или динамическими - RIP, OSPF, IGRP). В последнее время поставщики сетевого оборудования стали предлагать устройства уровня L2, способные осуществлять отбор пакетов на уровне L3 и даже L4 (TCP/UDP). В принципе ничто не мешает создать сетевые переключатели уровня L2, способные гарантировать пропускную способность, минимизировать вероятность потери пакета и т.д.
Любые способы управления трафиком на уровне L3 для сетей, работающих в рамках стека протоколов TCP/IP, в настоящее время базируются на возможностях этих транспортных протоколов (IP, UDP, TCP).
Протокол (см. ) предусматривает задание значение ToS, определяемое соответствующим полем заголовка. Одно-октетное поле тип сервиса (TOS - Type Of характеризует то, как должна обрабатываться дейтограмма.
Субполе приоритет предоставляет возможность присвоить код приоритета каждой дейтограмме. Значения приоритетов приведены в таблице (в настоящее время это поле не используется).
0 Обычный уровень
1 Приоритетный
2 Немедленный
3 Срочный
4 Экстренный
5 CEITIC/ECP
6 Межсетевое управление
7 Сетевое управление
В новейших разработках (RFC-2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers) поле TOS заменено на поле DSCP (Differentiated Services Code Point), где младшие 6 бит выделены для кода DS (Differentiated Services), а старшие два бита пока не определены и их следует обнулять.
До середины 90-х годов поле TOS в большинстве реализаций игнорировалось. Но после начала разработок средств обеспечения качества обслуживания (QoS) внимание к этому возрасло. Появилось предложение замены поля TOS на поле DSCP (Differenciated Services Code Point), которое также имеет 8 бит (см. RFC-2474). Смотри рис. 2. Биты CU пока не определены. Иногда это поле называется байтом DS (Differenttiated Services).

Рис. 2. Формат поля DSCP.
Биты DS0-DS5 определяют селектор класса. Значения этого кода представлены в таблице ниже. Стандартным значением DSCP по умолчанию является 000000.

Селектор класса	DSCP
Приоритет 1	001000
Приоритет 2	010000
Приоритет 3	011000
Приоритет 4	100000
Приоритет 5	101000
Приоритет 6	110000
Приоритет 7	111000

На базе DSCP разработана технология "пошагового поведения" PHB (per Hop Behavior). В рамках этой политики определяются коды DSCP внутри классов. Например, для политики немедленной переадресации EF рекомендуемое значение DSCP=101110. Эта политика соответствует наиболее высокому уровню обслуживания.
В маршрутизаторах компании CISCO Systems для классификации пакетов и выбора очередей используются два младших бита из трех. По умолчанию классу 0 выделяется 10% полосы, а классам 1, 2 и 3 - 20%, 30% и 40%, соответственно. Для очередей, основанных на классах QoS, пакеты, не принадлежащие ни одной группе, относятся к группе 0 и автоматически получают 1% от общей пропускной способности группы. Общий вес остальных групп не может превышать 99%. При наличии нераспределенной полосы, она относится к группе 0.
В протоколе IPv6 поле приоритет имеет 4 бита (см. ). Биты C, D, T и R характеризуют пожелание относительно способа доставки дейтограммы. В таблице 1 приведены стандартизованные значения поля Type of Service (TOS) IP-пакета.
Таблица .1. Значения TOS для разных протоколов (DTRC)
ПроцедураМинимальная задержкаМаксимальная пропускная способностьМаксимальная надежностьМинимальная стоимостьКод TOS (DTRC)FTP управление
FTP данные10000x1001000x08TFTP10000x10DNS
UDP
TCP10000x1000000x0000000x00Telnet10000x10ICMP0000 0x00 IGP0 0 1 0 0x04 SMTP управление
SMTP данные1 0 0 0 0x10 0 1 0 0 0x08 SNMP0 0 1 0 0x04 NNTP0 0 0 1 0x02
Помимо перечисленных значений может рассматриваться значение “Максимальная безопасность”. Строго говоря, значения TOS и QOS не эквивалентны, но именно значение ToS является базой для задания QoS. Присваивая при формировании IP-пакета определенное значение поля ToS, прикладная программа может попытаться реализовать определенные ограничения на QoS. Это поле может анализироваться маршрутизаторами, которые поддерживают протокол RSVP. В протоколе UDP нет никаких механизмов управления трафиком. Кое-что предлагает набор протоколов RTP/RTCP, предназначенный для мультимедийных приложений (например, позволяет ликвидировать влияние разброса времени доступа в каналах Ethernet на качество воспроизведения изображения и звука.). Некоторые приложения и сетевые приборы способны сигнализировать о перегрузке (потере пакетов из-за переполнения буферов), посылая ICMP(4).
Протокол (смотри ) имеет в заголовке 6-битовое поле флаги (значения представлены в таблице 2). Значения битов флаги предоставляет дополнительные возможности управления.
Таблица 2. Значения бит поля флаги



Обозначение битов (слева на право) поля флаги Значение бита, если он равен 1URGФлаг важной информации, поле Указатель важной информации имеет смысл, если URG=1.ACKНомер октета, который должен был прийти следующим, правилен.PSHЭтот сегмент требует выполнения операции push. Получатель должен передать эти данные прикладной программе как можно быстрее. RSTПрерывание связи. SYNФлаг для синхронизации номеров сегментов, используется при установлении связи. FINОтправитель закончил посылку байтов.
Указанные выше поля заголовков представляют собой основу существующих методов управления трафиком. Конечно, можно использовать и поля данных, но для этого нужно, чтобы это стало международным стандартом.
Существенную проблему составляет необходимость идентифицировать пакеты, принадлежащие определенному процессу. Эта задача легко решается только в рамках протокола IPv6. Там в заголовке предусмотрено поле метка потока. Некоторые возможности предоставляет также протокол MPLS.

Вверху по течению

Узел использует метку, содержащуюся в объекте LABEL, как выходную метку, ассоциированную с отправителем. Маршрутизатор присваивает новую метку и связывает ее с входным интерфейсом этой сессии/отправителя. Это тот же интерфейс, который маршрутизатор использует для переадресации сообщений Resv предшествующим узлам.

Несколько условий могут сделать метку неприемлемой.

Узел является коммутатором ATM, неспособным объединять потоки, но узел ниже по течению присвоил идентичные метки двум отправителям. Присвоена метка нуль, но узел неспособен выполнить предпоследнее извлечение из стека для соответствующего L3PID Присвоенная метка находится вне запрошенного диапазона меток.

В любом из этих случаев узел посылает сообщение ResvErr с кодом ошибки "проблема маршрутизации" и значением ошибки "неприемлемое значение метки".

4.1.2. Отсутствие поддержки объекта Label

При нормальных обстоятельствах, узел не должен получать объект LABEL в сообщении Resv, если только оно не содержит объект LABEL_REQUEST в соответствующем сообщении Path. Однако, маршрутизатор RSVP, который не распознает объект LABEL, посылает получателю ResvErr с кодом ошибки "Unknown object class" (неизвестный класс объекта). Это приводит к аннулированию резервирования.

Выбор маршрута

Выбор маршрута сопряжен с методом, используемым при выборе LSP для определенного FEC. Предлагаемая архитектура протокола MPLS поддерживает две опции выбора маршрута: (1) маршрутизация шаг-за-шагом и (2) явная маршрутизация.

Маршрутизация шаг-за-шагом позволяет каждому узлу независимо выбрать следующий шаг для каждого FEC. Это обычный режим существующих сегодня IP-сетей. "маршрутизируемый шаг-за-шагом LSP" является LSP, чей маршрут выбирается по схеме шаг-за-шагом.

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

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

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

Процедуры формирования явных маршрутов, точных или неточных, находятся за пределами данного документа.

Выбор следующего шага

Узел, получающий сообщение Path, содержащее объект EXPLICIT_ROUTE, должен определить следующий шаг пути. Это необходимо из-за того, что следующий абстрактный узел вдоль явного маршрута может быть субсетью IP или автономной системой. Следовательно, выбор этого следующего шага может включать в себя выбор одной из возможных альтернатив. Критерии, используемые, чтобы выполнить выбор, зависят от конкретной реализации и могут зависеть от локальной политики. Однако предполагается, что каждый узел сделает все возможное, чтобы исключить кольцевые маршруты. Заметим, что так определенные пути могут быть отвергнуты локальной политикой. Чтобы определить следующий шаг пути, узел выполняет следующие операции:

1) Узел, получив сообщение RSVP должен определить первый субобъект. Если узел не является частью абстрактного узла, описанного первым субобъектом, он получил сообщение с ошибкой и должен прислать сигнал ошибки "Bad initial subobject". Если первого субобъекта вообще нет, сообщение ошибочно и система должна прислать сигнал ошибки "Bad EXPLICIT_ROUTE object".

2) Если нет второго субобъекта, это указывает на конец явного маршрута. Объект EXPLICIT_ROUTE должен быть удален из сообщения Path. Этот узел может быть или не быть концом пути. Рассмотрение обработки продолжается в разделе 4.3.4.2, где допускается добавление нового объекта EXPLICIT_ROUTE в сообщение Path.

3) Далее, узел определяет второй субобъект. Если узел является частью абстрактного узла, описанного во втором субобъекте, тогда узел удаляет первый субобъект и продолжает обработку с пункта 2. Заметим, что это делает второй субобъект первым в следующей итерации и позволяет узлу идентифицировать следующий абстрактный узел пути после возможного повторения шагов 2 и 3.

4) Абстрактный пограничный узел: Узел определяет, является ли он топологически смежным с абстрактным узлом, описанным во втором субобъекте. Если это так, узел выбирает конкретный следующий шаг, адресатом которого является один из членов абстрактного узла. Узел затем убирает первый субобъект и продолжает обработку согласно разделу 4.3.4.2.

5) Случай внутреннего абстрактного узла: В противном случае узел выбирает следующий шаг в пределах абстрактного узла первого субобъекта (к которому данный узел принадлежит), то есть вдоль пути к абстрактному узлу второго субобъекта (который является следующим абстрактным узлом). Если такого пути нет, тогда возможны два варианта:

5a) Если второй субобъект является жестким, имеет место ошибка и узел должен прислать уведомление об ошибке "Bad strict node".

5b) В противном случае, если второй субобъект является свободным, узел выбирает любой следующий шаг вдоль пути к очередному абстрактному узлу. Если такого пути нет, имеет место ошибка, и узел должен прислать сигнал ошибки "Bad loose node".

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

Выделение меток “вверх и вниз по течению”

Метка может быть выделена либо нижестоящим LSR (режимы Downstream on Demand, Downstream Unsolicited) или вышестоящим LSR (режимы Upstream on Demand, Upstream Unsolicited, неявный). Преимущества выделения меток “вниз по течению” перечислены ниже: Это тот же самый режим, что и в случае уникастного LDP, таким образом исключается необходимость разработки процедур рассылки меток “вверх по течению”.Можно использовать ту же метку, когда меняется вышестоящий LSR из-за изменения маршрута, что является преимуществом для сетей с множественным доступом (смотри раздел 9).Совместимо с piggy-backing (особенно для режима рассылки “вниз по течению”).

Преимущество присвоения меток вышестоящим объектом заключаются в следующем: Проще выделение меток для сетей с множественным доступом (смотри раздел 9).Может использоваться та же метка, когда нижестоящий LSR (который мог быть инициатором выделения метки в режиме “вниз по течению” в сети с множественным доступом) покидает группу (смотри раздел 9).Режимы рассылки “вверх по течению” и неявный допускают более быстрое установление LSP, когда осуществляется запуск LSP трафиком.

Выявление LDP (Discovery)

Выявление LDP (discovery) является механизмом, который позволяет LSR найти потенциальных партнеров LDP. Выявление делает ненужным явное конфигурирование LSR. Существует два механизма выявления:

Базовый механизм выявления используется для детектирования соседних LSR, которые непосредственно соединены на канальном уровне.

Расширенный механизм выявления используется для нахождения LSR, которые не имеют непосредственных связей на канальном уровне.

Вышестоящие и нижестоящие LSR

Предположим, что Ru и Rd договорились о соответствии метки L и FEC F, для пакетов, посланных из Ru в Rd. Тогда с учетом этого соответствия, Ru является "вышестоящим LSR", а Rd является "нижестоящим LSR".

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

 Вышестоящий LSR: процедура labelUse

Предположим, что Ru является LSR, который получил ассоциацию метки L для адресного префикса X от LSR Rd. Ru является вышестоящим по отношению к Rd с учетом X , и в действительности Rd является следующим шагом Ru L3 для X.

Ru воспользуется ассоциацией, если Rd является следующим шагом Ru L3 для X. Если в момент получения ассоциации Ru, Rd не является следующим шагом Ru L3 для X , Ru не будет использовать эту ассоциацию. Ru может однако начать использовать ассоциацию позже, если Rd станет следующим шагом Ru L3 для X. Процедура labelUse определяет, как Ru использует ассоциацию Rd. Существует две процедуры, которые может использовать Ru:

Вышестоящий LSR: процедура NotAvailable

Если Ru и Rd являются соответственно вышестоящим и нижестоящим партнерами рассылки меток для адресного префикса X, Rd является следующим шагом Ru L3 для X, Ru запрашивает ассоциацию для X от Rd, но Rd отвечает, что не может предоставить ассоциацию в это время, так как он не имеет следующего шага для X. Далее процедура NotAvailable определяет, как должен реагировать Ru. Существует две возможные процедуры, управляющие поведением Ru:

Вышестоящий LSR: процедура Release

Предположим, что Rd является LSR, который связывает метку с адресным префиксом X, и который послал эту ассоциацию LSR Ru. Если Rd не оказался следующим шагом Ru L3 для адресного префикса X, или перестал быть следующим шагом Ru L3 для адресного префикса X, Ru перестанет использовать метку. Процедура Release определяет то, как Ru работает в этом случае. Существует две возможные процедуры, управляющие поведением Ru:

Вышестоящий LSR: процедура запроса

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

IP основным инструментом управления QoS

1.      Для сетей TCP/ IP основным инструментом управления QoS пока является протокол RSVP (это касается и MPLS).
2.      Протокол MPLS является удобным средством формирования корпоративных сетей (VPN), которые позволяют поднять их безопасность.
3.      Для обеспечения работы MPLS необходима поддержка протоколов IS-IS и MP-BGP всеми маршрутизаторами VPN.
4.      Протокол MPLS предоставляет гибкие средства мониторинга трафика в пределах VPN.
5.      Технология управления трафиком ТЕ предполагает совмещение возможностей протоколов уровней L2 и L3.
6.      Протокольных средств управления очередями в Ethernet или в TCP/IP не существует. Такие средства имеются вATM-коммутаторах, ограниченные возможности имеются в некоторых маршрутизаторах CISCO и в коммутаторах L2 (например, выбор между режимами store-and-forward и cutthrough и т.д.). В любом случае такие режимы конфигурируются администратором индивидуально для каждого сетевого устройства. Разумеется, что-то можно сделать с помощью протокола SNMP дистанционно, если имеется пароль доступа (community).
7.      Переход на IPv6 существенно расширяет возможности управления трафиком за счет использования меток потоков (пока не ясно насколько эта возможность поддерживается программно). Данное свойство особенно важно для передачи мультимедийных данных, например, программ цифрового телевидения. Последнее предполагает значительное расширение интегральной полосы каналов опорной сети (хотя бы до 155Мбит/c).
8.      Все выше сказанное отражает ситуацию сегодняшнего дня, когда не стандартизовано дополнительных средств управления трафиком и QoS. Положение может измениться, если будут, например, стандартизованы какие-то дополнительные атрибуты потоков (как это было сделано при введении меток для VPN). Такие работы уже ведутся (см. [3])
9.      Возможности, заложенные в протоколе MPLS, предполагают определенный уровень сотрудничества между администраторами узлов, образующих VPN.

Взаимодействие: объединение VC, объединение VP, и отсутствие объединения

Взаимодействие различных форм объединения в ATM наиболее просто описать на примере взаимодействия систем с объединением VC и без.

В случае, когда соединены узлы, поддерживающие и не поддерживающие объединение VC, переадресация ячеек базируется во всех вариантах на VC (т.e., на соединении VPI и VCI). Для каждого вышестоящего узла, осуществляющего объединение VC, нужен только один набор VPI/VCI (это сходно с требованиями для одиночной метки в случае работы в среде кадров (frame media)). Если вышестоящий сосед не может осуществлять объединение, тогда он будет требовать одного VPI/VCI на поток для себя, плюс достаточное число VPI/VCI, чтобы осуществить передачу вышестоящему соседу. Необходимое число будет определено путем разрешения вышестоящим узлам посылать запросы дополнительных VPI/VCI от своих нижестоящих соседей (это аналогично методике объединения, используемой для кадров).

Аналогично можно поддержать узлы, которые выполняют объединение VP. В этом случае объединяющий VP узел, вместо посылки запроса одного или нескольких VPI/VCI от нижестоящего соседа, может запросить один VP (идентифицируемого посредством VPI), но несколько VCI в пределах VP. Кроме того, предположим, что узел, не поддерживающий объединение ниже расположен по отношению к двум другим узлам, объединяющим VP. Этот узел может нуждаться в запросе одного VPI/VCI (для трафика, исходящего именно из этого узла) плюс два VP (по одному для каждого вышестоящего узла), ассоциированные со специфицированными наборами VCI (в соответствии с запросом от вышестоящего узла).

Для того чтобы поддерживать узлы, объединяющие и не объединяющие VP и VC, необходимо разрешить вышестоящим узлам запрашивать комбинацию из нуля или более идентификаторов VC (состоящих из VPI/VCI), плюс нуль или более VP (идентифицируемых VPI), каждый из которых содержит специфицированное число VC (идентифицированное набором VCI, которые работают в пределах VP). Узлы, объединяющие VP, затребовали бы один VP, содержащий VCI для исходящего трафика (если таковой имеется) плюс VCI для каждого VC, запрошенного свыше (вне зависимости оттого, является или нет VC частью, содержащей VP). Узлы, объединяющие VC, затребовали бы только один VPI/VCI (так как они могут объединить весь трафик от вышестоящих узлов в один VC). Узлы, не поддерживающие объединение, передали бы любые запросы, полученные сверху, плюс запрос VPI/VCI для трафика, генерируемого ими самими (если таковой имеется).

Взаимодействие с политикой в классе aut-num

О сформированном объединении другие AS оповещаются только в случае, когда экспортная политика AS позволяет передавать объединения маршрутов. Когда объединение сформировано, более специфические префиксы запрещены для экспорта за исключением AS в aggr-bndry и компонент в export-comps.

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

route:	128.8.0.0/16
origin:	AS1
route:	128.9.0.0/16
origin:	AS1
route:	128.8.0.0/15
origin:	AS1
aggr-bndry:	AS1 or AS2 or AS3
aggr-mtd:	outbound AS3 or AS4 or AS5
components:	{128.8.0.0/16, 128.9.0.0/16}
inject:	upon HAVE-COMPONENTS {128.9.0.0/16, 128.8.0.0/16}
aut-num:	AS1
export:	to AS2 announce AS1
export:	to AS3 announce AS1 and not {128.9.0.0/16}
export:	to AS4 announce AS1
export:	to AS5 announce AS1
export:	to AS6 announce AS1

Рис. .33. Взаимодействие с политикой в классе aut-num.

На рис. 33 показан пример взаимодействия. При рассмотрении маршрутных объектов следует произвести обмен более специфическими префиксами 128.8.0.0/16 и 128.9.0.0/16 между AS1, AS2 и AS3 (граница объединения).

Экспортное объединение выполнено для AS4 и AS5, но не для AS3, так как AS3 находится на границе объединения. Объект aut-num допускает экспортирование обоих компонентов в AS2, и только компонент 128.8.0.0/16 в AS3. Объединение может быть сформировано, если присутствуют все компоненты. В данном случае только об этом объединении оповещены AS4 и AS5. Однако, если одна из компонент не доступна, объединение не может быть создано, и любая из доступных компонент или более специфический префикс будет экспортирован в AS4 и AS5. Вне зависимости от того, выполнено объединение или нет, только более специфические префиксы будут экспортированы в AS6.

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

Зачем нужно более одного протокола рассылки меток?

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

Закрытие PEP/PDP

Наконец, сообщения Client-Close используются для аннулирования влияния соответствующих сообщений Client-Open, оповещающих партнера о том, что специфицированный тип клиента не поддерживается или не является активным. Когда PEP регистрирует потерю связи, связанную с таймаутом keep-alive он должен послать сообщение Client-Close для каждого открытого типа клиента, специфицирующего код ошибки разрыва соединения. Затем PEP может разорвать соединение с PDP, попытаться восстановить связь или использовать альтернативный PDP. Когда PDP завершает работу, он должен послать сообщения Client-Close всем PEP для всех типов клиента, при этом может специфицироваться альтернативный PDP, который может заменить прежний.

Замена меток

Замена меток (Label swapping) представляет собой использование следующих процедур для переадресации пакетов. Для того чтобы переадресовать помеченный пакет, LSR рассматривает метку на верху стека. Он использует ILM для установления соответствия этой метки набору NHLFE. Используя информацию из NHLFE, он определяет, куда переадресовать пакет, и выполняет некоторую операцию над стеком меток пакета, затем записывает новую метку в стек пакета и переадресует его.

Для того чтобы переадресовать непомеченный пакет, LSR анализирует заголовок сетевого уровня, чтобы определить FEC пакета. Затем он использует FTN, для того чтобы установить соответствие с NHLFE. Используя информацию NHLFE, он определяет, куда переадресовать пакет, и выполняет некоторую операцию над стеком меток пакета. (Извлечение метки из стека в этом случае будет нелегальным).

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

2.14.  Область действия и уникальность меток

Данный LSR Rd может связать метку L1 с FEC F, и переправить эту ассоциацию партнеру Ru1. Rd может также связать метку L2 с FEC F, и переправить эту ассоциацию партнеру Ru2. Является ли L1 == L2 не определяется архитектурой, это вопрос исключительно локальный.

Данный LSR Rd может связать метку L с FEC F1, и переправить эту ассоциацию партнеру Ru1. Rd может также связать метку L с FEC F2, и переправить эту ассоциацию партнеру Ru2. Если и только если Rd может сообщить, когда он получает пакет с меткой на верху стека равной L, занесена ли она в стек RU1 или RU2, архитектура не требует равенства F1 == F2. В таких случаях, мы можем сказать, что Rd использует другое пространство для меток, которые он пересылает Ru1, чем для меток, посылаемых Ru2. Вообще, Rd может лишь сообщить, Ru1 или Ru2 положил данную метку со значением L на верх стека, если выполнены следующие условия:

-  Ru1 и Ru2 являются партнерами, обменивающимися метками, и которым Rd пересылает значение метки L, и

-  Ru1 и Ru2 оба соединены с Rd непосредственно через интерфейс точка-точка.

Когда эти условия выполнены, LSR может использовать метки, имеющие область действия "per interface", т.e., которые являются уникальными для каждого интерфейса. Можно сказать, что LSR использует "пространство меток интерфейса". Когда эти условия не выполнены, метки должны быть уникальными для LSR, который их присвоил, и мы можем сказать, что LSR использует "пространство меток платформы".

Если конкретный LSR Rd связан с некоторым LSR Ru через два интерфейса по схеме точка-точка, тогда Rd может пересылать Ru ассоциацию метки L с FEC F1, также как ассоциацию метки L с FEC F2, F1 != F2, если и только если каждая ассоциация корректна для пакетов, которые Ru посылает Rd через один из интерфейсов. Во всех других случаях, Rd не должен посылать ассоциации Ru, сопрягающие одну и ту же метку с двумя разными FEC.

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

Возникает вопрос, может ли LSR использовать мультиплатформные пространства меток, или использовать много пространств меток интерфейса для одного и того же интерфейсного устройства. Это не запрещено архитектурой. Однако в таких случаях LSR должен иметь некоторые средства, не специфицированные архитектурой, определения для заданной входной метки, какому пространству принадлежит данная метка. Например, [MPLS-SHIM] специфицирует, что различные пространства меток используются для уникастных и мультикастных пакетов, а для разделения этих пространств используется код канального уровня.

Запись Next Hop Label Forwarding (NHLFE)

"Next Hop Label Forwarding Entry" (NHLFE) используется при переадресации помеченных пакетов. Здесь содержится следующая информация:

1. Следующий шаг пакета

2. Операция, которая должна быть произведена над стеком меток. Это одна из следующих операций:

a) заместить метку на верху стека специфицированной новой меткой

b) извлечь метку из стека

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

Она может содержать:

d) инкапсуляцию канальных данных, которая будет использована при пересылке пакета

e) метод кодирования стека меток, при пересылке пакета

f) другую информацию, необходимую для того чтобы корректно отобразить пакет.

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

Это подразумевает, что в некоторых случаях LSR будет должен работать с IP-заголовком, для того чтобы переадресовать пакет.

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

2.11.  Установление соответствия для входных меток ILM (Incoming Label Map)

"Incoming Label Map" (ILM) устанавливает соответствие каждой входящей метки с набором NHLFE. Эта операция используется, когда переадресуемые пакеты являются помеченными.

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

Заполнение набора таблиц PHB-->Encaps для исходящего L-LSP

В данном разделе определено, как набор таблиц PHB-->Encaps контекста Diff-Serv заполняется на фазе формирования метки исходящего L-LSP, для того чтобы разрешить кодирование информации Diff-Serv.

Заполнение таблицы Encaps-->PHB для входящего L-LSP

В данном разделе определено, как формируется таблица Encaps-->PHB в контексте Diff-Serv при формировании меток входящего L-LSP для того, чтобы позволить определение входных PHB.

Запрос (REQ) PEP -> PDP

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

Раз для нового запроса определен дескриптор, любые последующие модификации запроса могут производиться с помощью сообщения REQ, специфицирующего инсталлированный дескриптор. PEP ответственен за уведомление PDP всякий раз, когда изменения его локального состояния отслеживает состояния PEP. Формат сообщения-запроса имеет вид:

<Request Message> ::= <Common Header>
<Client Handle>
<Context>
[<IN-Int>]
[<OUT-Int>]
[<ClientSI(s)>]
[<LPDPDecision(s)>]
[<Integrity>]
<ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI>
<LPDPDecision(s)> ::= <LPDPDecision> | <LPDPDecision(s)> <LPDPDecision>
<LPDPDecision> ::= [<Context>]
<LPDPDecision: Flags>
[<LPDPDecision: Stateless Data>]
[<LPDPDecision: Replacement Data>]
[<LPDPDecision: ClientSI Data>]
[<LPDPDecision: Named Data>]

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

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

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

Наконец, объект LPDPDecision содержит информацию согласно локальному решению, принятому LPDP.

Сообщения Request с неверным форматом должны вызывать сообщения Decision PDP с соответствующим кодом ошибки.

Запрос состояния синхронизации (SSQ) PDP -> PEP

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

<Synchronize State> ::= <Common Header>
[<Client Handle>]
[<Integrity>]

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

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

Защитная информация

Защитная информация транспортируется в новом объекте/TLV. Она используется для описания атрибутов защиты канала запрошенного LSP. Использование информации защиты для конкретного LSP является опционным. Защитная информация указывает на желательный тип защиты канала LSP. Если запрошен конкретный тип защиты, т.е., 1+1, или 1:N, тогда запрос соединения обрабатывается, только если запрашиваемый тип защиты может быть реализованa. Заметим, что возможности защиты канала могут анонсироваться в ходе маршрутизации, смотри [GMPLS-RTG]. Алгоритмы расчета маршрута могут учитывать эту информацию при формировании LSP.

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

Завершение состояния синхронизации (SSC) PEP -> PDP

Сообщение завершения состояния синхронизации (Synchronize State Complete) посылается от PEP к PDP, после того как PDP пошлет запрос синхронизации состояния PEP и PEP завершит синхронизацию. Полезно, чтобы PDP знал, когда все старые состояния клиента успешно повторно запрошены и, таким образом, PEP и PDP полностью синхронизованы. Объект дескриптора клиента (Client Handle) следует включать только тогда, когда соответствующее сообщение синхронизации состояний (Synchronize State Message) непосредственно ссылается на определенный дескриптор (handle).

<Synchronize State Complete> ::= <Common Header>
[<Client Handle>]
[<Integrity>]

Значения статусных кодов Diff-Serv

Для поля статусный код определены следующие значения (Status TLV):

Статусный код	E	Status Data
Непредусмотренный Diff-Serv TLV	0	0x01000001
Неподдерживаемый PHB	0	0x01000002
Неверное соответствие EXP<-->PHB	0	0x01000003
Неподдерживаемый PSC	0	0x01000004
Невозможность выделения LSP-ресурса	0	0x01000005

Значения типа среды Composite (составной)

Оставшиеся два из семи исходных значений Content-Type относятся к составным объектам. Составные объекты обрабатываются с использованием механизмов MIME -- процессор MIME обрабатывает тело объекта непосредственно.

5.1. Тип среды Multipart

В случае составных объектов, когда один или более различных наборов данных объединяется в одном теле, в заголовке объекта должно присутствовать поле типа среды "multipart". Тело должно тогда содержать одну или более частей, каждая из которых начинается с разделительной строки. За разделительной строкой следует заголовок, пустая строка и тело объекта. Таким образом, часть тела по своему синтаксису аналогична сообщению в RFC-822, но имеет другое назначение.

Часть тела является объектом и, следовательно, не должна интерпретироваться как сообщение RFC-822. Начнем с того, что части тела должны иметь заголовки. Допустимы части тела, которые начинаются с пустой строки. В таком случае отсутствие заголовка Content-Type обычно указывает, что соответствующее тело имеет тип содержимого "text/plain; charset=US-ASCII".

Единственные поля заголовка, которые определяют назначение частей тела, имеют имена, начинающиеся с "Content-". Все другие поля в заголовке части тела могут игнорироваться. Для экспериментальных или частных назначений могут создаваться поля, с именами, начинающимися с "X-". Информация, содержащаяся в этих полях может теряться в некоторых шлюзах.

Различие между сообщением RFC-822 и частью тела не велико, но существенно. Шлюз между Интернет и почтовым сервером X.400, например, должен быть способен различать части тела, содержащие изображение и инкапсулированное сообщение, тело которого представляет собой JPEG-образ. Для того чтобы представить последнее, часть тела должна иметь "Content-Type: message/rfc822", и ее тело после пустой строки должно представлять собой инкапсулированное сообщение со своим собственным полем заголовка "Content-Type: image/jpeg". Применение подобного синтаксиса способствует преобразованию сообщений в части тела и обратно.

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

Все существующие и будущие субтипы типа "multipart" должны использовать идентичный синтаксис. Субтипы могут отличаться по своей семантике и могут вводить дополнительные ограничения на синтаксис, но должны согласовываться с базовым синтаксисом типа "multipart". Это требование гарантирует, что все агенты пользователя будут, по крайней мере, способны распознать и разделить части составного объекта, даже если они относятся к нераспознанным субтипам.

Как задано в определении поля Content-Transfer-Encoding [RFC-2045], никакие кодировки кроме "7bit", "8bit" или "binary" не разрешены для объектов типа "multipart". Граничные разделители и поля заголовков "multipart" всегда представляются как 7-битовые коды US-ASCII, а данные внутри частей тела могут быть закодированы по-разному и иметь свои поля Content-Transfer-Encoding для каждой из частей.

5.1.1. Общий синтаксис

Поле Content- Type для составных объектов требует одного параметра - "boundary". Строка-разделитель определяется как строка, содержащая два символа дефис ("-", десятичный код 45), за которыми следует значение пограничного параметра из поля заголовка Content-Type, опционный строчный пробел и заключительные CRLF.

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

Грамматика для параметров поля Content-type такова, что в строке Content-type часто необходимо помещать пограничный параметр в кавычки. Это необходимо не всегда, но никогда не повредит. Программисты должны тщательно изучить грамматику, для того чтобы избежать генерации некорректных полей Content-type. Таким образом, типичное поле заголовка "multipart" Content-Type может выглядеть как:

Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"

Это значение Content-Type указывает, что содержимое состоит из одной или более частей со структурой, которая синтаксически идентична сообщению RFC-822, за исключением того, что область заголовка может быть совершенно пустой, а каждая из частей начинается со строки

--gc0pJq0M:08jU534c0p

Пограничный разделитель должен размещаться в начале строки, т.e., следовать за CRLF, а начальный CRLF рассматривается объединенным со строкой пограничного разделителя, а не частью предшествующей секции. За границей может следовать нуль или более символов строчного пробела (HT, SP). Далее следует еще один CRLF и поля заголовка следующей части, или два CRLF, что означает отсутствие полей заголовка следующей части. Если поле Content-Type отсутствует, предполагается объект типа "message/rfc822" в сообщении "multipart/digest", в противном случае "text/plain".

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

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

--gc0pJq0M:08jU534c0p--

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

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

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

Ниже представлен простой пример составного сообщения, имеющего две части, каждая из которых содержит чистый текст, введенный явно и неявно:

From: Nathaniel Borenstein
To: Ned Freed
Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"

Это преамбула. Она будет проигнорирована, но, тем не менее, это удобное место, чтобы отправитель мог поместить сообщение для принимающей стороны, которая не поддерживает MIME.

простая граница	Это неявно введенный чистый US-ASCII-текст. Он не завершается на данной строке
простая граница	Content-type: text/plain; charset=us-ascii. Это явно введенный чистый US-ASCII-текст. Он завершается на данной строке
простая граница	Это эпилог. Он также игнорируется

Использование типа среды "multipart" в части тела в пределах другого составного объекта вполне допустимо. В таких случаях следует позаботиться о том, чтобы каждый из последовательно вложенных объектов использовал свой уникальный пограничный разделитель. Применение типа среды "multipart" при наличии только одной части тела может быть полезным в определенном контексте и вполне допустимо.

Практика показала, что тип "multipart" с единственной составной частью полезен для посылки сообщений с нетекстовым типом среды. Он имеет возможность формирования преамбулы, как места, где можно поместить инструкции по декодированию. Кроме того, многие шлюзы SMTP перемещают или удаляют заголовки MIME, и хороший MIME-декодер таким путем может получить необходимую информацию даже в отсутствие заголовка Content-Type и корректно декодировать сообщение.

Единственным обязательным глобальным параметром для типа среды "multipart" является граничный параметр, который состоит из 1 - 70 кодов из символьного набора, который надежен по отношению преобразований, осуществляемых почтовыми шлюзами. Значение параметра не должно завершаться пробелом. Формально это записывается в BNF-представлении следующим образом.

boundary := 0*69 bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"

Вообще тело объекта "multipart" может быть специфицировано как:

dash-boundary := "--" boundary
; boundary берется из значения граничного параметра поля Content-Type.
multipart-body := [preamble CRLF]

	dash-boundary transport-padding CRLF
	body-part *encapsulation
	close-delimiter transport-padding
	[CRLF epilogue]

transport-padding := *LWSP-char

Отправители не должны генерировать транспортные
; заполнители ненулевой длины, но получатели
; должны уметь обрабатывать заполнители, введенные
; при транспортировке.



encapsulation := delimiter transport-padding CRLF body-part
delimiter := CRLF dash-boundary
close-delimiter := delimiter "--"
>epilogue := discard-text
; не должен появляться где-либо в теле секции. Заметим, что семантика части тела
; отличается от семантики сообщения, как это описано в тексте.
OCTET := <любое значение октета 0-255 >

Введение пробелов (HT, SP) и комментариев RFC 822 между элементами, показанными выше, не допустимо, так как эти BNF не специфицируют структурированное поле заголовка.

В определенных транспортных зонах регламентации RFC 822, такие как ограничение применения каких-либо символов, помимо печатных кодов US-ASCII могут не действовать. Ослабление этих ограничений может рассматриваться как локальное расширение определения тел, например, чтобы включить октеты вне набора US-ASCII, постольку, поскольку эти расширения поддерживаются системой передачи и соответствующим образом документированы в поле заголовка Content-Transfer-Encoding. Однако заголовки ни в коем случае не могут содержать чего-либо помимо кодов US-ASCII.

5.1.2. Обработка вложенных и составных сообщений

Субтип "message/rfc822" не имеет других условий завершения кроме окончания массива данных. Аналогично, некорректно укороченный составной объект не будет иметь завершающего разделителя, что может вызвать нарушение работы почтовой системы.

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

5.1.3. Субтип Mixed

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

5.1.4. Субтип Alternative

Тип "multipart/alternative" синтаксически идентичен "multipart/mixed", но имеет иную семантику. В частности, каждая часть тела является альтернативой одной и той же информации.

Системы должны распознавать, что содержимое различных частей взаимозаменяемы. Системы должны выбрать наилучший тип на основе локального окружения и в некоторых случаях с использованием диалога с пользователем. Как и для "multipart/mixed", порядок частей тела является существенным. В этом случае, альтернативы появляются в порядке возрастания правдоподобия оригинальному содержимому. Вообще наилучшим выбором является последняя часть типа, поддерживаемая локальной средой приемной системы..

"Multipart/alternative" может использоваться, например, для посылки сообщения в любом формате таким образом, чтобы его было легко отобразить:

From: Nathaniel Borenstein
To: Ned Freed
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
... здесь следует версия сообщения в виде чистого текста ...

--boundary42
Content-Type: text/enriched
... здесь следует версия сообщения RFC 1896 в виде обогащенного текста (text/enriched) ...

--boundary42
Content-Type: application/x-whatever
... здесь следует наиболее причудливая версия сообщения ...
--boundary42--

В этом примере пользователи, чья почтовая система может работать с форматом "application/x-whatever", увидят только причудливую версию сообщения, в то время как другие пользователи увидят версию с обогащенным или чистым текстом, в зависимости от возможностей их системы.

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

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

Каждая часть объекта "multipart/alternative" представляет одну и ту же информацию, версии не необязательно тождественны. Например, информация теряется, когда осуществляется трансляция ODA в PostScript или в чистый текст. Рекомендуется, чтобы каждая часть имела свое значение Content-ID в тех случаях, когда содержимое частей неэквивалентно. Например, там, где несколько частей типа "message/external-body" специфицируют способы доступа к идентичной информации, следует использовать одни и те же значения поля Content-ID. Возможен вариант, когда одно значение Content-ID может относиться к объекту "multipart/alternative", в то время как одно или более других значений Content-ID будут относиться к частям внутри объекта.

5.1.5. Субтип Digest



Этот документ определяет субтип "digest" типа содержимого "multipart". Этот тип синтаксически идентичен "multipart/mixed", но их семантика различна. В частности, в дайджесте, значение по умолчанию Content-Type для части тела меняется с "text/plain" на "message/rfc822". Это сделано, для того чтобы допустить более читаемый формат дайджеста, совместимый с RFC-934.

Хотя можно специфицировать значение Content-Type для части тела в дайджесте, который отличается от "message/rfc822", такая часть как "text/plain", содержащая описание материала в дайджесте, делает это нежелательным. Тип содержимого "multipart/digest" предназначен для использования при посылке группы сообщений. Если необходима часть "text/plain", она должна быть включена как отдельная компонента сообщения "multipart/mixed". Дайджест в этом формате может выглядеть как.

From: Moderator-Address
To: Recipient-List
Date: Mon, 22 Mar 1994 13:34:51 +0000
Subject: Internet Digest, volume 42
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="---- главный разделитель ----"
------ главный разделитель ----
...Вводный текст или содержимое таблицы...
------ главный разделитель ----
Content-Type: multipart/digest;
boundary="---- следующее сообщение ----"
------ следующее сообщение ----
From: someone-else
Date: Fri, 26 Mar 1993 11:13:32 +0200
Subject: my opinion
... здесь размещается тело...
------ следующее сообщение ----

From: someone-else-again
Date: Fri, 26 Mar 1993 10:07:13 -0500
Subject: my different opinion
... здесь размещается следующее тело ...
------ следующее сообщение ------
------ главный разделитель ------

5.1.6. Субтип Parallel

Этот документ определяет субтип "parallel" типа содержимого "multipart". Этот тип синтаксически идентичен "multipart/mixed", но их семантика различна. В частности, в параллельном объекте, порядок частей тела не играет роли.

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

5.1.7. Прочие субтипы Multipart



В будущем ожидается появление новых субтипов "multipart". Реализации MIME должны уметь работать с нераспознанными субтипами "multipart" как с "multipart/mixed".

5.2. Тип среды Message

Часто желательно при посылке почты вложить туда какое-то другое сообщение. Для решения этой задачи определен специальный тип среды "message”. В частности, для вложения в сообщения RFC-822 служит субтип "rfc822"

Субтип "message" часто накладывает ограничения на допустимые типы кодирования. Эти ограничения описаны для каждого специфического субтипа. Почтовые шлюзы, системы транспортировки и другие почтовые агенты иногда изменяют заголовки верхнего уровня в сообщениях RFC 822. В частности, они часто добавляют, удаляют и меняют порядок полей заголовков. Эти операции запрещены для заголовков, вложенных в тело сообщения типа "message."

5.2.1. Субтип RFC822

Тип среды "message/rfc822" указывает, что тело содержит инкапсулированное сообщение. Однако в отличие от сообщений верхнего уровня RFC-822, ограничение, связанное с обязательным присутствием в теле "message/rfc822" заголовков "From", "Date", и, по крайней мере, одного адреса места назначения, здесь удалено. Необходимо лишь присутствие одного из заголовков "From", "Subject" или "Date". Следует заметить, что, несмотря на использование чисел "822", объект "message/rfc822" не должен абсолютно следовать регламентациям RFC-822. Более того, сообщение "message/rfc822" может быть статьей новостей или сообщением MIME.

В теле объекта "message/rfc822" не разрешены никакие кодировки помимо "7bit", "8bit" или "binary". Поля заголовка сообщения содержат только US-ASCII в любом регистре, а информация в теле может быть закодирована. Не-US-ASCII-текст в заголовках инкапсулированного сообщения может быть специфицирован с использованием механизма, описанного в документе RFC-2047.

5.2.2. Субтип Partial



Субтип "partial" определен, для того чтобы разрешить разделять на части слишком большие объекты, которые затем доставляются в виде отдельных почтовых сообщений и автоматически восстанавливаются как единое целое принимающим агентом пользователя. Этот механизм может использоваться, когда промежуточный транспортный агент ограничивает максимальный размер почтового сообщения. Тип среды "message/partial", таким образом, указывает, что тело содержит фрагмент некоторого большого объекта.

Так как данные типа "message" могут не быть закодированны в виде base64 или закавыченной строки печатных символов, может возникнуть проблема, если объекты "message/partial" созданы в среде, которая поддерживает двоичный или 8-битовый обмен. Проблема возникает из-за того, что двоичные данные надо будет разбить на несколько сообщений "message/partial", каждое из которых требует двоичного транспорта. Если такие сообщения встретят по пути шлюз с 7-битовой передачей, не будет никакой возможности перекодировать эти фрагменты для 7-битовой среды. Можно конечно дождаться прихода всех составных частей, собрать исходный объект, закодировать его с помощью, например, base64, после чего начать все с начала. Но даже такой сложный сценарий может оказаться неосуществимым из-за того, что фрагменты могут транспортироваться разными путями. По этой причине, было специфицировано, что объекты типа "message/partial" должны всегда иметь транспортное кодирование “7bit” (по умолчанию). В частности, даже для сред, которые поддерживают двоичный или 8-битовый обмен, использование транспортного кодирования "8bit" или "binary" для MIME-объектов типа "message/partial" запрещено. Это в свою очередь предполагает, что внутреннее сообщение не должно использовать кодирование "8bit" или "binary". Так как некоторые агенты пересылки сообщений могут выбрать автоматическую фрагментацию длинных сообщений, а также из-за того, что эти агенты могут использовать разные пороги фрагментации, может так получиться, что фрагменты после сборки в свою очередь окажутся частями сообщения. Это вполне допустимо.

В поле Content-Type типа "message/partial" необходимо специфицировать три параметра. "id" - уникальный идентификатор, который должен использоваться для привязки фрагментов друг к другу. "number" - целое число, которое является номером фрагмента. "total" - целое число, характеризующее полное число фрагментов. Число фрагментов является опционным и обязательно присутствует только в последнем фрагменте. Заметим также, что эти параметры могут быть заданы в любом порядке. Таким образом, второй сегмент 3-фрагментного сообщения может иметь поля заголовка одного из следующих видов.

ontent-Type: Message/Partial; number=2; total=3;

id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

ontent-Type: Message/Partial;

	id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
	number=2

Но в третьем сегменте должно быть специфицировано полное число фрагментов.

Content-Type: Message/Partial; number=3; total=3;

id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

Заметьте, что нумерация фрагментов начинается с 1, а не 0.

Когда фрагменты объекта, разорванные таким способом, складываются вместе, результатом всегда будет исходный MIME-объект, который может иметь свое собственное поле заголовка Content-Type, и, следовательно, иметь любой другой тип данных.

5.2.2.1. Фрагментация и сборка сообщений

Семантика восстановленных фрагментов сообщений должна соответствовать "внутреннему" сообщению, а не сообщению, в которое оно вложено. Это делает возможным, например, посылку большого аудио-сообщения в виде нескольких сообщений-фрагментов таким образом, что получатель воспримет его как простое аудио-сообщение, а не инкапсулированное сообщение, содержащее аудио-сообщение. Такая инкапсуляция рассматривается как прозрачная. Когда формируются фрагменты и осуществляется сборка составных частей сообщения "message/partial", заголовки инкапсулированного сообщения должны объединяться с заголовками вложенных объектов. При реализации этой процедуры должны выполняться следующие правила:

(1)	Фрагментирующие агенты должны разделять сообщения только по границам строк. Это ограничение вводится из-за того, что при несоблюдении данного правила возникнет транспортная проблема сохранения семантики сообщения, не заканчивающегося последовательностью CRLF. Многие виды транспорта не способны решить такую задачу.
(2)	Все поля заголовка исходного вложенного сообщения, за исключением тех, чьи имена начинаются с "Content-", и специфических полей заголовка "Subject", "Message-ID", "Encrypted" и "MIME-Version", должны копироваться в новое сообщение.
(3)	Поля заголовка вложенного сообщения, начинающиеся с "Content-", плюс поля "Subject", "Message-ID", "Encrypted" и "MIME-Version" fields, должны быть добавлены в порядке к полям нового сообщения. Любые поля заголовка, которые не начинаются с "Content-" (за исключением полей "Subject", "Message-ID", "Encrypted" и "MIME-Version") будут проигнорированы и отброшены.
(4)	Все поля заголовка второго и любых последующих вложенных сообщений отбрасываются принимающей программой в процессе сборки.

5.2.2.2. Пример фрагментации и сборки

Если аудио- сообщение разделено на два фрагмента, первая часть может выглядеть как:

X-Weird-Header-1: Foo
From: Bill@host.com
Subject: Audio mail (part 1 of 2)
Message-ID:
MIME-Version: 1.0
Content-type: message/partial; id="ABC@host.com";
number=1; total=2

X-Weird-Header-1: Bar
X-Weird-Header-2: Hello
Message-ID:
Subject: Audio mail
Content-transfer-encoding: base64
... здесь помещается первая половина закодированных аудио-данных ...
а вторая часть может выглядеть следующим образом:

From: Bill@host.com
To: joe@otherhost.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 2 of 2)
MIME-Version: 1.0
Message-ID:
Content-type: message/partial;
id="ABC@host.com"; number=2; total=2
... здесь помещается вторая половина закодированных аудио-данных ...

Затем, когда фрагментируемое сообщение оказывается собрано, результат, отображаемый для пользователя, должен выглядеть как:

X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail
Message-ID:
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
... здесь помещается первая половина закодированных аудио-данных ...
... здесь помещается вторая половина закодированных аудио-данных ...

Включение в заголовки второго и последующих секций фрагментированного сообщения поля "References" (ссылка), которое указывает на Message-Id (идентификатор сообщения) предшествующей секции, может быть полезно для системы чтения почты, которая умеет отслеживать ссылки. Однако генерация полей "References" является опционной.

Наконец, следует заметить, что поле "Encrypted" заголовка является устаревшим из-за внедрения конфиденциальной почты PEM (Privacy Enhanced Messaging; RFC-1421, RFC-1422, RFC-1423, RFC-1424), но правила описанные выше, несмотря ни на что, описывают правильный путь его обработки, если оно встретится в контексте прямого и обратного преобразования фрагментов "message/partial".

5.2.3. Субтип External-Body



Субтип external-body указывает, что в сообщении содержатся не данные, а ссылка на место, где эти данные находятся. В этом случае параметры описывают механизм доступа к внешним данным.

Когда объект MIME имеет тип "message/external-body", он состоит из заголовка, двух последовательностей CRLF, и заголовка для инкапсулированного сообщения. Если появится еще одна пара последовательностей CRLF, это завершит заголовок инкапсулированного сообщения. Однако так как тело инкапсулированного сообщения само является внешним, оно не появится вслед за заголовком. Например, рассмотрим следующее сообщение:

Content-type: message/external-body;

	access-type=local-file;
	name="/u/nsb/Me.jpeg"

Content-type: image/jpeg
Content-ID:
Content-Transfer-Encoding: binary
Это в действительности не тело!

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

Инкапсулированные заголовки во всех объектах "message/external-body" должны включать в себя поле заголовка Content-ID, для того чтобы предоставить уникальный идентификатор, который служит для ссылки на данные. Этот идентификатор может быть использован в процессе кэширования и для распознавания входных данных, когда типом доступа является "mail-server".

Заметим, что, как это специфицировано здесь, лексемы, которые описывают данные внешнего тела, такие как имена файлов и команды почтового сервера, должны быть записаны с использованием символьного набора US-ASCII.

Как с "message/partial", объекты MIME типа "message/external-body" MUST имеют транспортное кодирование 7-бит (по умолчанию). В частности, даже в среде, которая поддерживает 8-битовую транспортировку, использование транспортного кодирования "8bit" или "binary" категорически запрещено для объектов типа "message/external-body".

5.2.3.1. Общие параметры External-Body



С "message/external- body" могут использоваться следующие параметры:

(1)	ACCESS-TYPE (тип доступа). Слово, характеризующее поддерживаемый механизм доступа, с помощью которого можно получить файл или данные. Это слово не чувствительно к регистру, в котором напечатано. Параметр может принимать следующие значения "FTP", "ANON-FTP", "TFTP", "LOCAL-FILE" и "MAIL-SERVER". Будущие значения, за исключением экспериментальных, начинающихся с "X-", должны регистрироваться IANA, как это описано в RFC-2048. Данный параметр является обязательным и должен присутствовать в каждом "message/external-body".
(2)	EXPIRATION (конец срока действия). Дата (имеет синтаксис "date-time" как в RFC-822, документ RFC-1123 разрешил 4 цифры для обозначения года), после которой существование внешних данных не гарантируется. Этот параметр может использоваться с любым типом доступа и является опционным.
(3)	SIZE (размер). Число октетов данных. Этот параметр предназначен, для того чтобы помочь получателю решить, достаточно ли ресурсов памяти для приема этих внешних данных. Заметим, что параметр описывает размер данных в канонической форме, то есть, до использования какого-либо транспортного кодирования или после декодирования. Этот параметр может использоваться с любым типом доступа и является опционным.
(4)

PERMISSION (разрешение). Не чувствительное к регистру поле, которое указывает, предполагается ли возможность для клиента переписать данные. По умолчанию или, если разрешение соответствует "read", считается, что это запрещено и что, если данные однажды извлечены, они не потребуются никогда. Если PERMISSION соответствует "read-write", такое предположение не верно. "Read" и "Read-write" являются единственными определенными значениями параметра разрешения. Этот параметр используется с любым типом доступа и является опционным.

5.2.3.2. Типы доступа 'ftp' и 'tftp'

Тип доступа FTP или TFTP указывают, что тело сообщения доступно в виде файла с помощью протоколов FTP [RFC-959] или TFTP [RFC- 783], соответственно. Для этих типов доступа необходимы следующие параметры:

(1)	NAME (имя). Имя файла, который содержит тело данных.
(2)	SITE (узел). ЭВМ, с которой может быть получен файл с помощью данного протокола. Это должно быть официально зарегистрированное имя, а не псевдоним.
(3)	Прежде чем какие-либо данные будут извлечены с помощью FTP, пользователь должен выполнить процедуру аутентификации (ввести имя и пароль) на машине, указанной в параметре SITE. По соображениям безопасности имя и пароль не специфицируются параметрами типа доступа, они должны быть получены непосредственно от пользователя.

Кроме того, следующие параметры являются опционными:

(1)	DIRECTORY (каталог). Каталог, из которого должен быть взят файл с именем, заданным параметром NAME.
(2)

MODE (режим). Строка символов, не зависящая от регистра ввода и указывающая на режим, который должен использоваться при извлечении информации. Допустимыми значениями параметра для типа доступа "TFTP" являются "NETASCII", "OCTET" и "MAIL", как это определено для протокола TFTP [RFC- 783]. Допустимыми значениями параметра для типа доступа "FTP" являются "ASCII", "EBCDIC", "IMAGE" и "LOCALn", где "n" - целое число, обычно 8. Они соответствуют типам представления "A" "E" "I" и "L n", как это задано протоколом FTP [RFC-959]. Заметим, что "BINARY" и "TENEX" не являются корректными значениями для MODE и что вместо этого следует использовать "OCTET", "IMAGE" или "LOCAL8". Если параметр MODE не задан, значением по умолчанию является "NETASCII" для TFTP и "ASCII" во всех прочих случаях.

5.2.3.3. Тип доступа 'anon-ftp'

Тип доступа "anon-ftp" идентичен варианту "ftp", за исключением того, что пользователю не нужно предоставлять имя и пароль. Вместо этого протокол ftp воспользуется именем "anonymous" и паролем, равным почтовому адресу пользователя.

5.2.3.4. Тип доступа 'local-file'

Тип доступа "local-file" указывает, что тело данных доступно в виде файла на локальной ЭВМ. Для этого типа доступа определены два дополнительные параметра:

(1)	NAME (имя). Имя файла, который содержит тело данных. Этот параметр является обязательным для типа доступа "local-file".
(2)

SITE (узел). Спецификатор домена для данной ЭВМ или набора машин, которые имеют доступ к данному информационному файлу. Этот опционный параметр используется для описания локального указателя на данные, т.е., узел или группа узлов, откуда данный файл доступен. В качестве символов подмены в имени домена могут использоваться звездочки, как, например, в "*.bellcore.com", чтобы указать на группу ЭВМ, откуда данные доступны непосредственно.



5.2.3.5. Тип доступа 'mail-server' Access-Type

Тип доступа "mail-server" указывает, что тело данных доступно на почтовом сервере. Для этого типа доступа определены два дополнительные параметра:

(1)	SERVER (сервер). Спецификация адреса почтового сервера, с которого может быть получены данные. Этот параметр является обязательным для типа доступа "mail-server".
(2)	SUBJECT (тема сообщения). Тема сообщения (subject), которая используется в почтовом сообщении с целью получения данных. Этот параметр является опционным.

Так как почтовые сервера воспринимают разнообразные синтаксисы, некоторые из которых являются многострочными, полная команда, которая должна быть послана почтовому серверу, не включается в качестве параметра с поле заголовка content-type. Вместо этого, она заносится как тело-фантом, когда тип среды соответствует "message/external-body", а тип доступа - mail-server.

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

В отличие от других типов доступа, доступ к почтовому серверу является асинхронным и происходит в произвольный момент времени. По этой причине важно, чтобы существовал механизм, с помощью которого полученные данные могли быть сопоставлены с исходным объектом "message/external-body". Почтовые серверы MIME должны использовать то же поле Content-ID в сообщении-отклике, которое было использовано в исходных объектах "message/external-body", для того чтобы облегчить такое сопоставление.

5.2.3.6. Соображения безопасности External-Body

Объекты "Message/external-body" подводят к следующим важным соображениям безопасности:

(1)

Доступ к данным через указатель "message/external-body" эффективно приводит к тому, что получатель сообщения выполняет операцию, которую специфицировал отправитель. Следовательно, отправитель сообщения может заставить получателя выполнить нечто, что тот бы в противном случае не сделал. Например, отправитель может специфицировать процедуру, которая попытается извлечь данные, для получения которых тот не имеет авторизации, принуждая получателя помимо его воли нарушить некоторые правила безопасности. По этой причине агенты пользователя, способные работать с внешними указателями, должны сначала описать процедуру, которую ни хотят предложить выполнить получателю, попросить разрешения и только после этого запускать этот процесс.

(2)

Иногда MIME используется в среде, которая предоставляет некоторые гарантии целостности и аутентичности сообщений. В этой ситуации такие гарантии можно отнести только к собственно содержимому сообщения. Что касается механизма MIME "message/external-body", здесь такие гарантии, вообще говоря, могут быть и не реализованы. В частности, имеется возможность разрушить определенные механизмы доступа, даже если сама система доставки сообщений вполне безопасна.

5.2.3.7. Примеры и дальнейшие расширения

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

Для распределенных файловых систем очень трудно знать заранее группу машин, где файл может быть доступен непосредственно. Следовательно, имеет смысл предоставить как имя файла на случай его прямой доступности, так имена одного или нескольких узлов, где может быть доступен этот файл. Программные реализации могут пытаться извлечь удаленные файлы, используя FTP или другой протокол. Если внешнее тело доступно за счет нескольких механизмов, отправитель может включить несколько объектов типа "message/external-body" в секции тела объекта "multipart/alternative".

Однако механизм внешнего тела не ограничивается извлечением файлов, как это показывается типом доступа mail-server. Помимо этого, можно предположить, например, использование видео-сервера для внешнего доступа к видео клипам.

Поля заголовка вложенного сообщения, которые появляются в теле "message/external-body" должны использоваться для декларации типа среды внешнего тела, если оно представляет собой нечто отличное от чистого текста US-ASCII, так как внешнее тело не имеет секции заголовка, чтобы декларировать тип. Аналогично здесь должно быть также декларировано любое транспортное кодирование, отличное от "7bit". Таким образом, полное сообщение "message/external-body", относящееся к объекту в формате PostScript, может выглядеть как:

From: От кого-то
To: Кому-то
Date: Когда-то
Subject: Нечто
MIME-Version: 1.0
Message-ID:
Content-Type: multipart/alternative; boundary=42
Content-ID:

--42
Content-Type: message/external-body; name="BodyFormats.ps";

	site="thumper.bellcore.com"; mode="image";
	access-type=ANON-FTP; directory="pub";
	expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID:
--42
Content-Type: message/external-body; access-type=local-file;

	name="/u/nsb/writing/rfcs/RFC-MIME.ps";
	site="thumper.bellcore.com";
	expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID:

--42
Content-Type: message/external-body;

	access-type=mail-server
	server="listserv@bogus.bitnet";
	expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID:
get RFC-MIME.DOC
--42--

Заметим, что в вышеприведенных примерах в качестве транспортного кодирования для Postscript данных предполагается "7bit".

Подобно типу "message/partial", тип среды "message/external-body" предполагается прозрачным, т.е. передается тип данных внешнего тела, а не сообщение с телом данного типа. Таким образом, заголовки внешней и внутренней частей должны быть объединены с использованием правил, изложенных выше для "message/partial". В частности, это означает, что поля Content-type и Subject переписываются, а поле From сохраняется в неизменном виде.

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

Заметим, что тело сообщения типа "message/external-body" регламентируется базовым синтаксисом сообщения RFC 822. В частности, все, что размещено перед первой парой CRLF является заголовком, в то время как все, что следует после заголовка, представляет собой данные, которые игнорируются для большинства типов доступа.

---

---