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

Определения субобъектов


Субобъекты объекта EXPLICIT_ROUTE с C-типом 1:

1 префикс IPv4

2 префикс IPv6

32 Номер автономной системы

Субобъекты объекта RECORD_ROUTE с C-типом 1:

1 адрес IPv4

2 адрес IPv6

3 Метка



Основы MPLS


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



Отделение канала управления


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



Отказ обработки Diff-Serv TLV


LSR, который не распознал тип Diff-Serv TLV при получении сообщения Label Request или Label Mapping, должен вести себя согласно с процедурами, специфицированными в [LDP] для неизвестного TLV, чей U-бит и F-бит установлены равными 0, т.e. он должен игнорировать сообщение, и присылать отклик Notification со статусом Unknown TLV.



Отказ в обслуживании (DoS)


LDP предоставляет две потенциальные мишени для атак отказа в обслуживания (DoS):



1. Стандартное выявление UDP-порта для LDP

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

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

DoS атаки через посредство расширенных Hello представляют потенциально более серьезную угрозу. Этой угрозе можно противостоять путем фильтрации расширенных Hello с помощью списков доступа, которые определяют адреса, откуда расширенное выявление (extended discovery) разрешено. Однако осуществление фильтрации требует ресурсов LSR.

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

2. Стандартный TCP порт для установления сессии LDP

Подобно другим протоколам управления, которые используют TCP, LDP может быть мишенью DoS атак, таких как SYN-атаки. Протокол LDP не более уязвим к этому виду атак, чем другие протоколы управления, используемые совместно с TCP. Угроза таких атак может быть несколько уменьшена посредством следующих мер:

LSR следует избегать тотального прослушивания (promiscuous) TCP для установления сессий LDP. Ему следует использовать только прослушивание части пакетов с целью выявления партнеров. Это позволяет отбросить пакеты атак.

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

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



Отказы канала управления


В случае отказа канала управления узел должен обновить все состояния, которые являются общими с соседом. Следует использовать совокупность процедур восстановления [RFC2961] с флагом ACK_Desired =1 (если они поддерживаются).



Отказы узлов


Восстановление при отказе узла использует один новый объект и другие существующие протокольные сообщения и объекты.



Отсутствие петель


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

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



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


LSR, который не распознает объект DIFFSERV Class-Num должен вести себя в соответствии с процедурами, специфицированными в [RSVP] для неизвестного Class-Num, чей формат имеет вид 0bbbbbbb т.е., он должен послать отправителю сообщение PathErr с кодом ошибки Unknown object class.

LSR, который распознал Class-Num объекта DIFFSERV, но не распознал его C-Type, должен вести себя согласно процедурам, специфицированным в [RSVP] для неизвестного C-type т.e., он должен послать отправителю сообщение PathErr с кодом ошибки Unknown object C-Type.

В обеих ситуациях, это вызывает прерывание формирования пути. Отправитель должен оповестить управляющую систему о том, что L-LSP не может быть сформирован и должен, возможно, предпринять попытку повторного формирования LSP без объекта DIFFSERV (например, попытаться использовать E-LSP с предварительно сформированной таблицей EXP<-->PHB).



Отсутствие выходной метки


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

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

-  Если пакет попадает в LSP маршрутизируемый явно, это может привести к образованию петель.

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

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



Партнерство и класс peering-set


Атрибуты класса peering-set представлены на рис. .21. Объект peering-set определяет набор партнеров, который перечислен в его партнерских атрибутах (peering). Атрибут peering-set определяет имя набора. Он является именем RPSL, которое начинается с "prng-".

АтрибутЗначениеТип
peering-set<object-name>обязательный, однозначный, ключ класса
peering<peering>обязательный, многозначный

Рис. .21. Атрибуты класса filter

Атрибут peering определяет партнеров, которые могут быть использованы для импорта или экспорта маршрутных данных.

Рис. .22. Пример топологии, состоящий из трех AS: AS1, AS2 и AS3, двух точек обмена: EX1 и EX2 и шести маршрутизаторов (IP[R1]= 1.1.1.1, IP[R2]= 2.2.2.1, IP[R3]= 1.1.1.2, IP[R4]= 1.1.1.3, IP[R5]= 2.2.2.2, IP[R6]= 2.2.2.3).

При описании партнерства используется топология, показанная на рис. .22. В этой топологии имеется три автономные системы, AS1, AS2, and AS3; две точки обмена, EX1 и EX2, и шесть маршрутизаторов (R1-R6). Маршрутизаторы соединены с точками обмена. То есть, 1.1.1.1, 1.1.1.2 и 1.1.1.3 являются партнерами друг для друга, а 2.2.2.1, 2.2.2.2 и 2.2.2.3 - также партнеры друг для друга.

Синтаксис спецификации партнерства:

<as-expression> [<router-expression-1>] [at <router-expression-2>] | <peering-set-name>

где <as-expression> является выражением для номеров AS и наборов AS, использующих операторы AND, OR и EXCEPT, а выражения <router-expression-1> и <router-expression-2> являются функциями IP-адресов маршрутизаторов, имен inet-rtr, и имен rtr-set, использующих операторы AND, OR и EXCEPT. Двоичный оператор "EXCEPT" семантически эквивалентен комбинации "AND NOT". То есть "(AS1 OR AS2) EXCEPT AS2" эквивалентно "AS1".

Эта форма идентифицирует всех партнеров между любым локальным маршрутизатором в <router-expression-2> и любыми маршрутизаторами в <router-expression-1> в автономных системах из <as-expression>. Если <router-expression-2> не специфицировано, это по умолчанию предполагает, что все маршрутизаторы локальной AS связаны с AS из <as-expression>.

Если используется <peering-set-name>, партеры перечислены в соответствующем объекте peering-set. Заметим, что объекты peering-set могут быть рекурсивными.

Возможны также многие специальные формы этой общей спецификации партнеров. Ниже приведенные примеры иллюстрируют наиболее общие случаи с использованием атрибута import класса aut-num. В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2.

(1) aut-num: AS1
import: from AS2 1.1.1.2 at 1.1.1.1 accept { 128.9.0.0/16 }

В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3.

(2) aut-num: AS1
import: from AS2 at 1.1.1.1 accept { 128.9.0.0/16 }

В следующем примере 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3, а 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2.

(3) aut-num: AS1
import: from AS2 accept { 128.9.0.0/16 }

В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3.

(4) as-set: AS-FOO
members: AS2, AS3


aut-num: AS1
import: from ASFOOat 9.9.9.1 accept { 128.9.0.0/16 }
В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3, а 1.1.1.1 импортирует 128.9.0.0/16 из 1.1.1.2 и 1.1.1.3.

(5) aut-num: AS1
import: from AS-FOOaccept { 128.9.0.0/16 }
В следующем примере AS1 импортирует 128.9.0.0/16 из AS3 через маршрутизатор 9.9.9.1

(6) aut-num: AS1
import: from AS-FOO and not AS2 at not 1.1.1.1 accept { 128.9.0.0/16 }

Это связано с тем, что "AS-FOO and not AS2" эквивалентно AS3 и "not 1.1.1.1" эквивалентно 9.9.9.1.

В следующем примере 9.9.9.1 импортирует 128.9.0.0/16 из 2.2.2.2 и 2.2.2.3.
(7) peering-set: prng-bar peering: AS1 at 9.9.9.1
peering-set: prng-foo
peering: prng-bar
peering: AS2 at 9.9.9.1

aut-num: AS1
import: from prng-foo accept { 128.9.0.0/16 }


Переадресация меток


[MPLS_ARCH] описывает, как LSR осуществляет смену меток во входных помеченных пакетах с помощью ILM (Incoming Label Map), где каждой входной метке соответствует один или более NHLFE. [MPLS_ARCH] описывает так же, как LSR осуществляет присвоение метки входным непомеченным пакетам, используя карту соответствия FEC->NHLFE (FTN), где каждому входному FEC ставится в соответствие один или более NHLFE. Контекст Diff-Serv для метки состоит из: тип LSP (т.е., E-LSP или L-LSP);поддерживаемые PHB;таблица соответствия Encaps-->PHB для входящих меток;таблица соответствия PHB-->Encaps для выходных меток

Данная спецификация определяет, что контекст Diff-Serv запоминается в ILM для каждой входной метки.

[MPLS_ARCH] утверждает, что NHLFE может содержать любую другую информацию, необходимую для того, чтобы корректно перенаправить пакет. В соответствии с этим данная спецификация определяет то, что контекст Diff-Serv записывается в NHLFE для каждой выходной метки.

Эта контекстная информация Diff-Serv заносится в ILM и FTN при начальном формировании метки. Если метка соответствует E-LSP, для которого не было установлено ассоциации EXP<-->PHB при формировании LSP, поддерживаемые PHB записываются с помощью набора PHB предварительно сконфигурированных ассоциаций EXP<-->PHB.

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

Если метка соответствует L-LSP, поддерживаемые PHB определяются набором PHB, образующих PSC, который согласован на фазе формирования LSP.

Процедуры определения соответствия Encaps-->PHB или набора пар PHB-->Encaps описаны в разделах 3 и 4.

[MPLS_ARCH] утверждается, что:

Если ILM [или FTN] устанавливает соответствие конкретной метки набору NHLFE, который содержит более одного элемента, прежде чем пакет будет переадресован, из набора должен быть выбран только один элемент. Установленное соответствие ILM [или FTN] метки [соответственно, FEC] набору, содержащему более одного NHLFE, может быть полезным, если, например, желательно сбалансировать нагрузку нескольких маршрутов с равными метриками.

В соответствии с этим, данная спецификация позволяет установить для целей Diff-Serv соответствие между входной меткой [или FEC] и несколькими NHLFE (например, когда разные NHLFE соответствуют выходным меткам, поддерживающим разные наборы PHB). Когда метка [соответственно FEC] соответствует нескольким NHLFE, Diff-Serv LSR должен выбрать один NHLFE, чей контекст Diff-Serv указывает на то, что он поддерживает выходное PHB переадресуемого пакета.

Когда пакет [соответственно FEC] соответствует нескольким NHLFE, которые поддерживают выходное PHB, процедура выбора одного из них в данном документе не рассматривается. Эта ситуация может случиться, когда желательно осуществить балансировку нагрузки ВА для нескольких LSP. В таких ситуациях, чтобы удовлетворить имеющимся ограничениям, все пакеты данного микропотока должны транспортироваться через один и тот же LSP.



Перечень сообщений


Следующие сообщения LDP определены в данной версии протокола.

Имя сообщения

Тип

Заголовок раздела

Notification 0x0001 Сообщение уведомления
Hello 0x0100 Сообщение Hello
Initialization 0x0200 Сообщение инициализации
KeepAlive 0x0201 Сообщение KeepAlive
Address 0x0300 Сообщение Address
Address Withdraw 0x0301 Сообщение отзыва адреса
Label Mapping 0x0400 Сообщение присвоения метки
Label Request 0x0401 Сообщение запроса метки
Label Withdraw 0x0402 Сообщение отзыва метки
Label Release 0x0403 Сообщение освобождения метки
Label Abort Request 0x0404 Сообщение запроса ликвидации метки
Vendor-Private 0x3E00-0x3EFF Частные расширения LDP производителя
Experimental 0x3F00-0x3FFF Экспериментальные расширения LDP



Поддержка дифференцированных услуг многопротокольной системой коммутации по меткам (MPLS, RFC-3270)


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

Аннотация

Данный документ определяет гибкое решение для поддержки дифференцированных услуг (Diff-Serv) в сетях с мультипротокольной коммутацией по меткам (MPLS). Это решение позволяет администратору сети MPLS выбрать, как связать совокупности реализаций BA (Behavior Aggregates) Diff-Serv с маршрутами, коммутируемыми по меткам (LSP), чтобы можно было обеспечить требуемый уровень Diff-Serv управления трафиком для конкретной сети. Например, это позволяет сетевому администратору решить, следует ли разные наборы BA ставить в соответствие одному или нескольким LSP.



Поддержка 'кодировочных слов'


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

'кодировочные слова' должны распознаваться как:

(1) Поле заголовка любого сообщения или части тела, определенное как '*text', или любое поле заголовка, определенное пользователем, должно разбираться следующим образом: Начало обозначается LWS (HR|SP|CRLF), любая последовательность вплоть до 75 печатных символов (не содержащая LWS) должна рассматриваться как кандидат в 'кодировочные слова' и проверяться на соблюдение правил синтаксиса, описанных в секции 2 данного раздела. Любую другую последовательность печатных символов следует рассматривать как обычный ASCII-текст.
(2) Любое поле заголовка, не определенное как '*text' должно разбираться согласно синтаксическим правилам для данного поля заголовка. Однако любое 'слово', которое появляется в пределах 'фразы' должно обрабатываться как 'кодировочное слово', если оно отвечает синтаксическим правилам секции 2. В противном случае оно должно обрабатываться как обычное 'слово'.
(3) Внутри 'комментария', любая последовательность с длиной до 75 символов (не содержащая LWS), которая отвечает синтаксическим правилам секции 2, должна обрабатываться как 'кодировочное слово'. В противном случае оно должно обрабатываться как обычный текст комментария.
(4) Поле заголовка MIME-Version может отсутствовать в 'кодировочных словах', которые обрабатываются согласно данной спецификации. Причиной этого является то, что программа чтения почты не предполагает разбирать весь заголовок сообщения, прежде чем отображать строки, которые могут содержать 'кодировочные слова'.

6.2. Отображение кодированных слов

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

Декодирование и отображение закодированных слов происходит, после того как структурные поля тела будут разобраны на лексемы. Следовательно, возможно спрятать 'специальные' символы в 'кодировочных словах', которые при отображении будут неотличимы от 'специальных' символов окружающего текста. По этой и другим причинам вообще невозможно транслировать заголовок сообщения, содержащий 'кодировочные слова', к виду, который может анализироваться программой чтения почты (RFC-822).

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

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

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

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

6.3. Обработка почтовой программой некорректно сформированных 'кодировочных слов'

Возможно, что 'кодировочное слово', которое легально согласно синтаксическим правилам секции 2, не корректно сформировано с точки зрения регламентаций использованного правила кодирования. Например:

(1) 'Кодировочное слово', которое содержит символы нелегальные для конкретного кодирования (Например, "-" в "B"-кодировании, или SP и HT в "B"- или "Q"-кодировании), является некорректно сформированным.
(2) Любое 'кодировочное слово', которое кодирует нецелое число символов или октетов является некорректно сформированным.

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



Поддержка MPLS Diff-Serv для интерфейсов LC-ATM


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

Данный документ допускает любое число L-LSP для заданного FEC в пределах домена MPLS ATM Diff-Serv. E-LSP не поддерживаются для интерфейсов LC-ATM.



Поддержка MPLS Diff-Serv для интерфейсов LC-FR


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

В данном документе разрешено любое число L-LSP на один FEC в домене MPLS Frame Relay Diff-Serv. E-LSP для интерфейсов LC-FR не поддерживаются.



Поддержка MPLS Diff-Serv поверх PPP, LAN, Non-LC-ATM и Non-LC-FR-интерфейсов


Общие принципы поддержки MPLS Diff-Serv, включая переадресацию по меткам и формирование LSP, специфицированы в предыдущих разделах. В данном разделе описываются специфические операции, необходимые для поддержки MPLS Diff-Serv через интерфейсы PPP, LAN, ATM и Frame Relay, которые не поддерживают коммутацию пакетов по меткам. Для этих интерфейсов, данная спецификация допускает любую из ниже перечисленных комбинаций LSP - FEC :

нуль или любое число E-LSP, и

нуль или любое число L-LSP.

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

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



Поддержка сессий LDP


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

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

LSR может решить прервать LDP сессию с партнером в любой момент времени. Если LSR принял такое решение, ему следует проинформировать партнера об этом с помощью сообщения Shutdown.



Поддержка сопредельности Hello


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

LDP имеет механизмы выявления необходимости LDP сессии и ее Hello сопредельностей.

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

Диаграмма состояний при инициализации сессии



Подробное описание работы E-LSP 3.Определение E-LSP


E-LSP определены в разделе 1.2. В пределах заданного домена MPLS Diff-Serv, все E-LSP базирующиеся на предварительно заданном (сконфигурированном) соответствии, способны транспортировать один и тот же набор из 8, или менее, BA. Каждый из этих E-LSP может действительно транспортировать этот полный набор BA или любой произвольный субнабор этого набора.

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



Поле заголовка Content-Description


Часто оказывается желательным установить соответствие между описательной информацией и данным телом. Например, может быть полезным пометить тело типа "image" как "изображение старта космического корабля". Такой текст может быть помещен в поле заголовка Content-Description. Это поле всегда является опционным.

description := "Content-Description" ":" *text

Предполагается, что описание дается с использованием символьного набора US-ASCII, хотя механизм, специфицированный в RFC 2047, может быть использован и для значений Content-Description, не соответствующих стандарту US-ASCII.



Поле заголовка Content-ID


При создании агента пользователя высокого уровня, может быть желательно, допустить одному телу ссылаться на другое. Тела могут быть помечены с помощью поля заголовка "Content-ID", которое синтаксически идентично полю "Message-ID":

id := "Content-ID" ":" msg-id

Подобно значениям Message-ID, значения Content-ID должны генерироваться уникальными.

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



Поле заголовка Content-Type


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

Поле заголовка Content-Type было первым, определенным в документе RFC-1049. В RFC-1049 использовался более простой и менее мощный синтаксис, который, в прочем, вполне согласуется с регламентациями MIME.

Поле заголовка Content-Type специфицирует природу данных в теле объекта, сообщая тип среды и идентификаторы субтипа, а также предоставляя вспомогательную информацию, которая может требоваться для определенного типа среды. После типа среды и имен субтипов может следовать набор параметров, который описывается в нотации атрибут = значение. Порядок параметров не имеет значения. Тип среды верхнего уровня используется для декларирования общего типа данных, в то время как субтип определяет специфический формат информации. Таким образом, типа среды "image/xyz" достаточно, чтобы сообщить агенту пользователя, что данные представляют собой изображение, даже если агент пользователя не имеет представления о формате изображения "xyz". Такая информация может использоваться, например, для того чтобы решить, следует ли показывать пользователю исходные данные нераспознанного субтипа. Такая операция разумна для нераспознанного субтипа текста, но бессмысленна для изображения или звука. По этой причине, зарегистрированные субтипы текста, изображения, аудио и видео не должны содержать вложенной информации другого типа. Такой составной формат должен быть представлен с использованием "multipart" или "application" типов.

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

Например, параметр "charset" применим к любому субтипу "текста", в то время как параметр "boundary" необходим для любого субтипа типа среды "multipart". Не существует параметров, применимых для всех типов среды.

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

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

4.1. Синтаксис поля заголовка Content-Type


В нотации BNF, значение поля заголовка Content-Type определяется следующим образом:
content := "Content-Type" ":" type "/" subtype *(";" parameter)
; Распознавание типа и субтипа среды всегда не зависит от регистра, в котором они напечатаны. type := discrete-type / composite-type   discrete-type :="text" / "image" / "audio" / "video" / "application" / extension-token  composite-type:="message" / "multipart" / extension-token  extension-token:=ietf-token / x-token  ietf-token:=<Лексема расширения, определенная стандартом RFC и зарегистрированная IANA.>  x-token:=<Два символа "X-" или "x-", за которыми следует без пробела лексема (token)>  subtype:=extension-token / iana-token  iana-token:=<Общедоступная лексема расширения. Лексемы этой формы должны быть зарегистрированы IANA, как это указано в RFC 2048.>   parameter := attribute "=" value  attribute :=token; Распознавание атрибутов не зависит от регистра, в котором они напечатаны. value:=token / quoted-string  token := 1*   tspecials :="(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "="; Должно представлять собой строку в кавычках Заметим, что определение "tspecials" совпадает с определением "specials" в RFC 822 с добавлением трех символов "/", "?" и "=" и удалением "." (точка).

Заметим также, что спецификация субтипа является MANDATORY - она не может быть удалена из поля заголовка Content-Type. Не существует субтипов по умолчанию. Тип, субтип и имена параметров не зависят от регистра, в которых они напечатаны. Например, TEXT, Text и TeXt являются эквивалентными типами среды верхнего уровня. Значения же параметров в норме чувствительны к регистру, в котором они напечатаны, но иногда интерпретируются без учета регистра в зависимости от приложения. (Например, границы типа multipart являются чувствительными к регистру, а параметр "access-type" для сообщения message/External-body не чувствителен.)

Обратите внимание, что значение строки в кавычках не включает в себя сами кавычки. В полях заголовка в соответствии с RFC 822 допускаются комментарии. Таким образом, две приведенные ниже формы являются эквивалентными.

Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii".

Предполагается, что имена субтипов при их применении не вызовут конфликтов. Так недопустимо, чтобы в различных приложениях "Content-Type: application/foobar" означало различные вещи. Существует два приемлемых механизма определения новых субтипов среды.

Частные значения (начинающиеся с "X-") могут быть определены для двух взаимодействующих агентов без официальной регистрации или стандартизации.

Новые стандартные значения должны регистрироваться IANA, как это описано в RFC 2048.



4.2. Значения по умолчанию Content-Type

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

Content-type: text/plain; charset=us-ascii

Это значение подразумевается, если не специфицировано поле заголовка Content-Type. Рекомендуется, чтобы это значение по умолчанию использовалось в случае, когда встретилась нераспознанное значение поля заголовка Content-Type. В присутствии поля заголовка MIME-Version и отсутствии поля Content-Type, принимающий агент пользователя может также предположить, что отправитель предлагает простой текст в ASCII-кодировке. Простой ASCII-текст может предполагаться в отсутствии MIME-Version или в присутствии синтаксически некорректного поля заголовка Content-Type, хотя это может и не совпадать с намерениями отправителя.

5. Поле заголовка Content-Transfer-Encoding

Многие типы среды, которые могут передаваться посредством электронной почты, представляются в своем естественном формате, таком как 8-битовые символы или двоичные данные. Такие данные не могут быть переданы посредством некоторых транспортных протоколов. Например, RFC 821 (SMTP) ограничивает почтовые сообщения 7-битовым символьным набором ASCII со строками короче 1000 символов, включая строчные разделители CRLF.

Таким образом, необходимо определить стандартный механизм кодировки таких данных в 7-битный формат с короткими строками. В MIME для этой цели используется поле заголовка "Content-Transfer-Encoding". Это поле не было определено каким-либо прежним стандартом.

5.1. Синтаксис Content-Transfer-Encoding

Значения полей Content-Transfer-Encoding представляют собой лексему, характеризующую тип кодирования, как это описано ниже.
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token
Эти значения не чувствительны к регистру, в котором напечатаны. - Base64, BASE64 и bAsE64 эквивалентны. Тип кодировки 7BIT требует, чтобы тело уже имело 7-битовое представление, пригодное для передачи. Это значение по умолчанию, означает, что в отсутствии поля Transfer-Encoding предполагается "Content-Transfer-Encoding: 7BIT".

5.2. Семантика Content-Transfer-Encodings



Лексема Content-Transfer- Encoding предоставляет два вида информации. Она специфицирует, какому виду кодового преобразования подвергнуто тело сообщения и, следовательно, какая процедура декодирования должна использоваться при восстановлении исходного вида сообщения.

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

В настоящее время определены три преобразования: тождественное (никакого преобразования), преобразование в последовательность печатных символов и в последовательность кодов "base64".

Значения Content-Transfer-Encoding "7bit", "8bit" и "binary" означают, что никакого преобразования не произведено. Они указывают на тип тела сообщения, и позволяют предполагать, какое кодирование может потребоваться при передаче данных.

Кодирование в последовательность печатных символов или в кодовую последовательность base64 предполагает преобразование из произвольного исходного формата в представление "7bit", что позволяет передачу через любые транспортные среды.

Всегда должна использоваться корректная метка Content-Transfer-Encoding. Пометка данных, преобразованных программой UUENCODE и содержащих 8-битовые символы, как "7bit" не допустима, такие данные должны помечаться только как "binary".

При прочих равных условиях предпочтительным представлением является последовательность печатных символов или кодов base64.

Передача почтовых сообщений закодированных программой uuencode описана в документе RFC 1652. Но следует иметь в виду, что ни при каких обстоятельствах Content-Transfer-Encoding "binary" нельзя считать приемлемым для e-mail. Однако когда используется MIME, двоичное тело сообщение может быть помечено как таковое.

5.3. Новое значение Content-Transfer-Encodings



Программисты могут, если необходимо, определить частные значения Content-Transfer-Encoding. При этом должны использоваться x-лексемы, которые представляют собой имена с префиксом "X-", что указывает на нестандартный статус, например, "Content-Transfer- Encoding: x-my-new-encoding". Дополнительные стандартизованные значения Content-Transfer-Encoding должны быть специфицированы в официальных документах RFC.

В отличие от типов среды и субтипов, формирование новых значений Content- Transfer-Encoding категорически не рекомендуется, так как может привести к полному выходу из строя системы.

5.4. Реализация и применение

Если поле заголовка Content-Transfer-Encoding появляется как часть заголовка сообщения, оно относится ко всему телу сообщения. Если поле заголовка Content-Transfer-Encoding появляется в качестве части заголовка объекта, то зоной его действия будет тело этого объекта. Если объект имеет тип "multipart", то Content-Transfer-Encoding не может иметь значение "7bit", "8bit" или "binary". Следует заметить, что большинство типов среды определены в терминах октетов, а не бит, поэтому описываемые механизмы относятся к кодировке произвольных потоков октетов, а не бит. Если необходимо закодировать битовую последовательность, она должна быть преобразована в последовательность октетов с сетевой последовательностью бит ("big-endian"), в которой более ранние биты становятся старшими битами октетов. Битовые потоки, длина которых не кратна 8, должны быть дополнены нулями.

Механизмы кодировки, определенные здесь, осуществляют преобразование любых данных в ASCII. Таким образом, предположим, например, что объект имеет следующие поля заголовка:

Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64

Это должно интерпретироваться так, что тело имеет кодировку base64, а исходные данные имели представление в ISO-8859-1.

Определенные значения Content-Transfer-Encoding могут использоваться только с определенными типами среды. В частности, категорически запрещено использовать любую кодировку отличную от "7bit", "8bit" или "binary" с любым составным типом среды, т.e. включающим и другие поля Content-Type. В настоящее время допустимы составные типы среды "multipart" и "message". Все кодировки, допустимые для тел типа multipart или message должны использоваться на самом внутреннем уровне.

Следует также заметить, что по определению, если составной объект имеет значение transfer-encoding равное "7bit", но один из составляющих объектов имеет менее регламентирующее значение, например, "8bit", тогда либо внешняя метка "7bit" является ошибкой, или внутренняя метка "8bit" устанавливает слишком высокое требование к транспортной системе (следовало проставить 7bit).

Хотя запрет использования content-transfer-encodings для составного тела может показаться чрезмерно регламентирующим, следует избегать вложенных кодирований, в которых данные подвергаются последовательно обработке несколькими алгоритмами. Вложенные кодирования заметно повышают сложность агентов пользователя. Помимо очевидных проблем эффективности при множественном кодировании они могут затемнить базовую структуру сообщения. В частности они могут подразумевать, что необходимо несколько операций декодирования, чтобы определить, какие типы тел содержит сообщение. Запрет вложенных кодировок может осложнить работу некоторых почтовых шлюзов, но это представляется меньшей бедой, чем осложнение жизни агентов пользователя при вложенном кодировании.

Любой объект с нераспознанным значением Content-Transfer-Encoding должен рассматриваться, как если бы он имел код Content-type "application/octet-stream", вне зависимости оттого, что утверждается полем заголовка Content-Type.

Может показаться, что Content-Transfer-Encoding может быть выяснено из характеристик среды, для которой нужно осуществить кодирование или, по крайней мере, что определенное Content-Transfer-Encodings может быть предназначено для использования с определенными типами среды. Есть несколько причин, почему это не так. Во-первых, существующие различные типы транспорта, используемые для почты, некоторые кодирования могут годиться для определенных комбинаций типов среды и транспорта, но быть непригодными для других. Например, при 8-битовой передаче, при определенном символьном наборе для текста не потребуется никакого кодирования, в то время как такое кодирование очевидно необходимо для 7-битового SMTP.

Во-вторых, определенные типы среды могут требовать различного транспортного кодирования при разных обстоятельствах. Например, многие PostScript-тела могут целиком состоять из коротких строк 7-битовых кодов, и, следовательно, совсем не требуют кодирования. Другие тела PostScript (в особенности те, что используют механизм двоичного кодирования уровня 2 PostScript) могут быть представлены с использованием двоичного транспортного кодирования. Наконец, так как поле Content-Type ориентировано на то, чтобы предоставлять открытые механизмы спецификации, строгие ассоциации типов среды и кодирования эффективно соединяют спецификацию прикладного протокола с определенным транспортом нижнего уровня. Это нежелательно, так как разработчики типа среды не должны заботиться обо всех видах транспорта и их особенностях.

5.5. Транслирующее кодирование



Кодирование с использованием закавыченных строк печатных символов и кодов base64 устроено так, чтобы позволить взаимные преобразования. Единственная проблема, которая здесь возникает, это обработка принудительных разрывов строк для закавыченных последовательностей печатных символов. При преобразовании закавыченных строк в коды base64 принудительные разрывы строк отображаются последовательностями CRLF. Аналогично, последовательность CRLF в канонической форме данных, полученной после декодирования из base64, должна преобразоваться в принудительный разрыв строки в случае представления текста в виде закавыченной строки печатных символов. Каноническая модель кодирования представлена в документе RFC 2049.

5.6. Транспортное кодирование содержимого Quoted-Printable

Кодирование Quoted-Printable имеет целью представление данных, состоящих по большей части из октетов, которые соответствуют печатным символам ASCII-набора. Оно преобразует данные таким образом, что результирующие октеты не будут видоизменены при транспортировке почты. Если преобразуемые данные представляют собой ASCII-текст, то после кодирования они сохранят читабельность. Тело, которое целиком состоит из ASCII-кодов, может быть также представлено в виде закавыченной строки печатных символов. При этом сохраняется целостность текста в процессе прохождении через шлюз, который осуществляет трансляцию символов и/или обработку разрывов строк. При этом кодировании октеты должны определяться согласно изложенным ниже правилам:

(1)
8-битовое представление. Любой октет, за исключением CR или LF, которые являются частью последовательности разрыва строки CRLF, канонического (стандартного) формата данных может быть представлен с помощью символом "=", за которым следуют две шестнадцатеричные цифры, характеризующие значение октета. Для этих целей используются цифры шестнадцатеричного алфавита "0123456789ABCDEF". Должны использоваться прописные буквы; использование строчных букв недопустимо. Так, например, десятичное значение 12 (ASCII FF) может быть представлено как "=0C", а десятичное значение 61 (ASCII символ знака равенства) представляется с помощью "=3D". Это правило должно выполняться всегда за исключением случаев, когда правила допускают альтернативное кодирование. (2)Литеральное представление. Октеты с десятичными кодами в интервале 33 - 60 включительно, и 62 - 126, включительно, могут представляться ASCII-символами, которые соответствуют этим октетам (с ! до < и с > до ~ соответственно). (3)Пробелы. Октеты со значениями кодов 9 и 32 могут отображаться с помощью ASCII-символов TAB (HT) и пробел, соответственно, но не должны использоваться в конце строки. За любым символом TAB (HT) или пробел в кодируемой строке должен следовать печатный символ. В частности, символ "=" в конце каждой кодируемой строки, обозначающий "мягкий" разрыв строки (смотри правило #5), может следовать за одним или более символами TAB (HT) или SP. Отсюда следует, что октет, равный 9 или 32 появляющийся в конце кодируемой строки должен быть представлен в форме, указанной правилом #1. Это правило необходимо, так как некоторые MTA (Message Transport Agents, программы, которые передают сообщения от одного пользователя другому) дополняют строки пробелами, а другие удаляют пробелы (HT или SP) в конце строки. Следовательно, при декодировании тела, представленного в форме закавыченных печатных последовательностей, любые HT или SP должны быть удалены. (4)Разрывы строк. Разрыв строки в теле текста, представленный последовательностью CRLF в канонической форме, для закавыченной печатной строки отмечается CRLF. Последовательности типа "=0D", "=0A", "=0A=0D" и "=0D=0A" появляются в нетекстовых данных, представленных в виде закавыченных строк печатных символов.
Заметим, что многие реализации могут выбрать для кодирования непосредственно локальное представление различных типов содержимого, а не преобразование в каноническую форму, кодирование и только затем преобразование в локальное представление. В частности, такая техника может быть применена к простому тексту в системах, которые используют для межстрочных разрывов последовательности, отличные от CRLF. Такая оптимизация конкретной программной реализации вполне допустима, но только когда комбинированный шаг канонизация-кодирование эквивалентен выполнению всех трех шагов отдельно. (5)Мягкие разрывы строки. Кодирование с помощью закавыченных строк печатных символов требует, чтобы строки содержали не более 76 символов. Если нужно закодировать более длинные строки вводятся “мягкие” разрывы строк. Символ равенства в конце строки как раз и обозначает такой разрыв.



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

Now's the time for all folk to come to the aid of their country.

Это может быть представлено следующим образом с помощью закавыченных строк печатных символов:

Now's the time =
to the aid of their country.

Это предоставляет механизм, с помощью которого длинные строки преобразуются таким образом, как они должны быть запомнены агентом пользователя. Ограничение в 76 символов не учитывает завершающие строку CRLF, но включают все прочие символы, включая знаки равенства. Так как символ дефис ("-") может отображаться в закавыченных строках самим собой, нужно следить за тем, чтобы при инкапсуляции закодированного так фрагмента, в одном или более составных объектов пограничные разделители не появились в закодированном теле. Хорошей стратегией является выбор в качестве границы последовательности символов "=_", которая не может встретиться в закавыченной строке печатных символов.

Преобразование в закавыченные строки печатных символов представляет собой компромисс между читабельностью и надежностью при транспортировке. Тела, закодированные с помощью закавыченных строк печатных символов, пропускаются без проблем большинством почтовых шлюзов. Проблемы могут возникать только со шлюзами, осуществляющими трансляцию в коды EBCDIC. Кодирование с помощью base64 обеспечивает более высокий уровень надежности. Методом получения разумно высокой надежности транспортировки через шлюзы EBCDIC является представление символов !"#$@[\]^`{|}~ согласно правилу #1.

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

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

(1)
Символ "=", за которым следует две шестнадцатеричные цифры, одна или обе из которых являются строчными символами (abcdef). Надежные реализации могут распознавать их как прописные буквы. (2)Символ "=", за которым следует символ, не являющийся ни шестнадцатеричной цифрой (включая abcdef), ни CR из комбинации CRLF. Это не может стать частью ASCII-текста, включенного в сообщение, без преобразования в закавыченную последовательность печатных кодов. Разумным решением для надежной реализации может быть включение символа "=" и следующих за ним кодов в декодированную последовательность, без какого-либо преобразования и, если возможно, дать и сигнал агенту пользователя, что декодирование в этом месте оказалось невозможным. (3)Символ "=" не может быть последним или завершающим символом в кодируемом объекте. Решением проблемы можно считать способ, предложенный в пункте (2).(4)Управляющие символы, отличные от TAB, CR и LF (в качестве части CRLF) не должны присутствовать. То же справедливо для октетов с десятичными значениями больше чем 126. Если такие коды обнаруживаются в приходящих закавыченных последовательностях печатных символов, корректная реализация может исключить из декодированных данных и предупредить пользователя о том, что обнаружен нелегальный символ. (5) Закодированные строки не должны быть длиннее 76 символов, не считая завершающие CRLF. Если во входном потоке обнаружены более длинные строки, надежная реализация может их декодировать, но должна предупредить пользователя об ошибке.
Если двоичные данные закодированы в виде закавыченных последовательностей печатных символов, следует позаботиться о том, чтобы символы CR и LF были представлены в виде "=0D" и "=0A", соответственно. В частности, последовательность CRLF в двоичных данных должна кодироваться как "=0D=0A". В противном случае, если CRLF была бы представлена как “жесткий” разрыв строки, она может декодироваться некорректно на платформах с различными способами обработки разрывов строки. С формальной точки зрения, закавыченные последовательности печатных символов подчиняются следующей грамматике.
quoted-printable := qp-line *(CRLF qp-line)
qp-line := *(qp-segment transport-padding CRLF) qp-part transport-padding
qp-part := qp-section ; Максимальна длина 76 символов
qp-segment := qp-section *(SPACE / TAB) "=" ; Максимальна длина 76 символов
qp-section := [*(ptext / SPACE / TAB) ptext]
ptext := hex-octet / safe-char
safe-char :=
<любой октет с десятичным кодом от 33 до 60 включительно, и от 62 до 126>; Символы, не включенные в список "mail-safe" RFC 2049, не рекомендуются к применению. hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F"); Октет должен использоваться для символов с кодами > 127, =, SP или TAB в конце строк, и рекомендуются для любого символа не указанного в списке "mail-safe" документа RFC 2049. transport-padding := *LWSP-char ; Составители не должны генерировать заполнители ненулевой длины, но получатели должны быть способны обрабатывать заполнители, добавленные при транспортировке. Добавление LWSP между элементами, показанное в данном BNF-представлении, не допустимо, так как данное BNF не специфицирует структурированных полей заголовка.

5.7. Транспортное кодирование Base64 (Content-Transfer-Encoding)

Транспортное кодирование на основе Base64 создано для представления произвольной последовательности октетов в форме, которая не обязательно должна быть приемлемой для прочтения человеком. Алгоритмы кодирования и декодирования просты. Это кодирование сходно с тем что используется в почтовом приложении PEM (Privacy Enhanced Mail), как это определено в RFC-1421.

Здесь используется 65-символьный субнабор ASCII, для каждого печатного символа выделено по 6 бит. Дополнительный 65-ый символ "=", используется для обозначения специальных функций обработки.

Этот субнабор имеет важное свойство, которое заключается в том, что он представляется идентично во всех версиях ISO 646, включая US-ASCII, и все символы субнабора имеют аналоги во всех версиях EBCDIC. Другие популярные кодировки, такие как применение утилиты uuencode, Macintosh binhex 4.0 [RFC-1741] и base85, специфицированная как часть уровня 2 PostScript, имеют отличающиеся свойства и, следовательно, не выполняют условий переносимости, которым должна удовлетворять двоичное транспортное кодирование электронной почты.

При кодировании входные 24-битовые группы преобразуют в 4 символа. Входная группа формируется из трех 8-битовых кодов и обрабатывается слева направо. Эти 24 бита рассматриваются в дальнейшем как 4 6-битовые группы, каждая из которых транслируется в одно число из алфавита base64. Когда кодируется битовый поток с использованием base64, предполагается, что старший бит передается первым. То есть, первый бит потока станет старшим битом первого 8-битового байта, а 8-ой бит станет его последним битом.

Каждая 6-битовая группа используется как индекс массива из 64 печатных символов. Символ, на который указывает индекс, берется из массива и помещается в выходной поток. Эти символы представлены в таблице .1., из их перечня исключены коды, имеющие особое значение для протокола SMTP (например, ".", CR, LF), а также разграничитель секций составного сообщения "-" (RFC-2046).

Таблица .1. Коды Base64



Код
символа
(6 бит)ASCII
символКод
символа
(6 бит)ASCII
символКод
символа
(6 бит)ASCII
символКод
символа
(6 бит)ASCII
символ 0 A 10 Q 20 g 30 w 1 B 11 R 21 h 31 x 2 C 12 S 22 i 32 y 3 D 13 T 23 j 33 z 4 E 14 U 24 k 34 0 5 F 15 V 25 l 35 1 6 G 16 W 26 m 36 2 7 H 17 X 27 n 37 3 8 I 18 Y 28 o 38 4 9 J 19 Z 29 p 39 5 A K 1A a 2A q 3A 6 B L 1B b 2B r 3B 7 C M 1C c 2C s 3C 8 D N 1D d 2D t 3D 9 E O 1E e 2E u 3E + F P 1F f 2F v 3F / Закодированный выходной поток должен иметь формат последовательности из одной или более строк длиной не более 76 символов каждая. Все разрывы строк или другие символы, не содержащиеся в таблице .1. должны игнорироваться декодирующим программным обеспечением. В данных, представленных в кодах base64, символы отличные от тех, что представлены в таблице .1., разрывы строк и другие пробелы обычно указывает на ошибку передачи, которая вызовет предупреждение или даже выбрасывание сообщения.

Если число бит в группе меньше 24, используется специальная обработка. Неполная битовая группа дополняется нулями справа до 24. Заполнение в конце информационной группы осуществляется с использованием символа "=". Так как последовательность кодов base64 представляет собой поток октетов, возможны следующие случаи:

последний блок кодируемых данных кратен 24 битам; здесь, завершающий выходной блок будет содержать в себе 4 символа и никакого заполнителя,

завершающий блок кодируемых данных содержит ровно 8 бит; здесь, оконечный выходной блок будет содержать два символа, за которыми будут следовать два символа заполнителя, или

последний блок кодируемой информации содержит ровно 16 бит; здесь, оконечный блок на выходе будет иметь три символа плюс один символ заполнителя "=".

Так как "=" используется для дополнения, его наличие указывает на то, что достигнут конец массива данных. Такая уверенность не возможна, когда число переданных октетов кратно трем и нет ни одного символа "=". Любые символы, не входящие в алфавит base64-должны игнорироваться.

Следует позаботиться о том, чтобы использовались корректные октеты в качестве разделителей строк при работе с base64. В частности, разрывы строк должны быть преобразованы в последовательности CRLF до выполнения кодирования base64.


Поле заголовка MIME-Version


Так как документ RFC 822 был опубликован в 1982, там имелся только один формат для сообщений, передаваемых по каналам Интернет, и по этой причине не было необходимости декларировать тип такого стандарта. MIME является независимым дополнением документа RFC 822. Хотя протокол MIME строился так, чтобы обеспечить совместимость с RFC 822, бывают обстоятельства, когда почтовому агенту желательно выяснить, составлено ли сообщение с учетом нового стандарта. Поле заголовка "MIME-Version" служит как раз для того, чтобы можно было определить, какому стандарту соответствует тело сообщения. Сообщения, соответствующие MIME обязаны содержать такое поле заголовка со следующим текстом:

MIME-Version: 1.0

Присутствие этого поля заголовка означает, что сообщение подготовлено согласно требованиям MIME. Так как существует возможность того, что в будущем формат документов может быть изменен, формальное BNF-представление поля MIME-Version следует записать следующим образом:

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

Таким образом, будущие спецификаторы формата, которые могут заменить версию "1.0", ограничены двумя цифровыми полями, разделенными точкой. Если сообщение получено со значением поля MIME-version, отличным от "1.0", оно может не соответствовать данному описанию.

Заметим, что поле заголовка MIME-Version должно располагаться в самом начале сообщения. При составном сообщении не требуется, чтобы каждая из частей начиналась с поля версии. Это необходимо лишь в случае, когда заголовки встроенных сообщений типа "message/rfc822" или "message/partial" объявляют о совместимости со стандартом MIME.

Для некоторых приложений согласование версий должно проводиться независимо. Некоторые форматы (такие как application/postscript) имеют внутреннюю систему нумерации версий для каждого типа среды. Там где имеет место такое соглашение, MIME не предпринимает попыток подменить эту систему. Там где такого соглашения нет, тип среды MIME может использовать параметр "version" в поле типа содержимого. При проверке значений MIME-Version любые строки комментария RFC 822 должны игнорироваться. В частности, следующие четыре записи поля MIME-Version эквивалентны.

MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0

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

Нельзя быть уверенным, что почтовое сообщение, не согласованное с MIME, является непременно обычным текстом в кодировке ASCII, так как оно может содержать код согласно локальному соглашению (например, результат работы процедуры UUTNCODE или какого-то архиватора).



Поля заголовка MIME


MIME определяет ряд новых полей заголовков по сравнению с RFC 822. Они описывают содержимое MIME-объекта. Эти поля заголовков используются в двух контекстах:

В качестве части стандартного заголовка RFC 822.

В MIME-заголовке в рамках составной конструкции сообщения.

Ниже представлено формальное описание этих полей заголовка.

entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ]
*( MIME-extension-field CRLF )
MIME-message-headers := entity-headers fields version CRLF

; Порядок полей заголовка, представленный в данном BNF-определении, не имеет никакого значения.

MIME-part-headers := entity-headers [ fields ]

; Любое поле, не начинающееся с "content-" не может иметь какого-либо значения и может игнорироваться.

; Порядок полей заголовка, представленный в данном BNF-определении, не имеет никакого значения.



Помеченные пакеты


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

Метод кодирования метки должен быть согласован субъектом, ее формирующим и субъектом адресатом.



Последний адрес PDP (LastPDPAddr)


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

C-Num = 14,
C-Type = 1, IPv4-адрес (тот же формат, что и для PDPRedirAddr)
C-Type = 2, IPv6-адрес (имеет тот же формат, что и PDPRedirAddr)



Постановка задачи


Протокол DHCP предназначен для предоставления клиентам DHCP конфигурационных параметров, описанных в RFC Host Requirements. После получения через DHCP необходимых параметров, клиент DHCP должен быть готов к обмену пакетами с любой другой ЭВМ в Интернет. Параметры стека TCP/IP, предоставляемые протоколом DHCP перечислены в приложении A. Не все эти параметры необходимы для первичной инициализации клиента. Клиент и сервер могут согласовывать список необходимых параметров.

Протокол DHCP позволяет, но не требует конфигурации параметров клиента, не имеющих прямого отношения к IP-протоколу. DHCP не обращается к системе DNS для регистрации адреса [12, 13]. DHCP не может использоваться для конфигурации маршрутизаторов.



Поведение клиента DHCP


На рис. 5 представлена диаграмма состояний для DHCP-клиента. Клиент может получить следующие сообщения от сервера:

o DHCPOFFER
o DHCPACK
o DHCPNAK

Сообщение DHCPINFORM не показано на рис. 5. Клиент просто посылает DHCPINFORM и ждет сообщения-отклика DHCPACK. Раз клиент выбрал свои параметры, он завершил процесс конфигурации.

Таблица 5 описывает использование полей и опций DHCP-сообщения клиента.

Рис. 5. Диаграмма состояний DHCP-клиента



Предложенная метка


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

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

Информация, содержащаяся в предлагаемой метке, идентична содержащейся в обобщенной метке.



Предпосылки


ЭВМ и маршрутизаторы, которые поддерживают как RSVP [1], так и MPLS (Multi-Protocol Label Switching) [2] могут ассоциировать метки с потоками RSVP. Когда комбинируются MPLS и RSVP, определение потока можно сделать более гибко. Когда маршрут с коммутацией по меткам (LSP) сформирован, трафик по этому пути определяется меткой, присвоенной ему входным узлом LSP. Установление соответствия между меткой и трафиком может быть выполнено с помощью нескольких различных критериев. Набор пакетов, которым присвоен определенным узлом одна и та же метка, относятся к одному классу переадресации FEC (forwarding equivalence class) (смотри [2]), и эффективно определяет "RSVP-поток". Когда трафик ассоциирован с маршрутом LSP, мы рассматриваем LSP как "LSP-туннель". Когда метки ассоциированы с потоками трафика, для маршрутизатора становится возможным идентифицировать определенное состояние резервирования для пакета с помощью его метки.

Модель протокола управления использует рассылку меток по запросам из области внизу по течению. Запрос установления соответствия метки и определенного LSP-туннеля инициируется входным узлом с помощью сообщения RSVP Path. Для этой цели, сообщение RSVP Path дополняется объектом LABEL_REQUEST. Метки формируются внизу по течению и рассылаются вверх по течению с помощью сообщения RSVP Resv. Для этой цели, сообщение RSVP Resv расширяется с помощью специального объекта LABEL. Процедуры выделения метки, рассылки, ассоциирования, и помещения в стек описаны в последующих разделах.

Модель протокола управления поддерживает также возможность явной маршрутизации. Это осуществляется путем введения простого объекта EXPLICIT_ROUTE в сообщения RSVP Path. Объект EXPLICIT_ROUTE содержит в себе набор шагов, которые непосредственно характеризуют маршрут. Используя этот объект, проходы, которые используемые RSVP-MPLS потоками, управляемыми метками, могут быть предопределены независимо от традиционной IP-маршрутизации. Явно сформированный маршрут может быть специфицирован административно, или вычислен автоматически в соответствии с требованиями QoS и политики маршрутизации, принимая во внимание базовое состояние сети. Вообще, вычисление маршрута может управляться директивно или данными. Механизмы, процессы и алгоритмы, используемые для явного вычисления маршрутов, в данной статье не рассматриваются.

Одним полезным приложением явной маршрутизации является управление трафиком. Используя явно сформированные LSP, входной узел домена MPLS может управлять маршрутом, по которому проходит трафик сети MPLS. Явная маршрутизация может быть использована, чтобы оптимизировать использование сетевых ресурсов и улучшить рабочие характеристики сети, ориентированные на трафик.

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

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

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

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



Предварительно конфигурируемая таблица EXP<-->PHB


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

Предварительно сконфигурированная таблица EXP<-->PHB не должна согласовываться на каждом шагу E-LSP в пределах области MPLS Diff-Serv LSP.

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



AПроцедуры рассылки меток LDP


В этом разделе описана схема рассылки в терминах отклика LSR на следующие события:

Получение сообщения запроса метки;

Получение сообщения присвоения метки;

Получение сообщения запроса ликвидации метки;

Получение сообщения освобождения метки;

Получение сообщения отзыва метки;

Распознание нового FEC;

Детектирование изменения FEC следующего шага;

Получение сообщения уведомления / аннулирован запрос метки;

Получение сообщения уведомления / нет ресурсов для метки;

Получение сообщения уведомления / Нет маршрута;

Получение сообщения уведомления / детектирована петля;

Получение сообщения уведомления / для метки есть ресурсы;

Детектирование доступности локальных ресурсов для метки;

LSR решает не использовать коммутацию по метке для данного FEC;

Таймаут для отложенного запроса метки.

Спецификация поведения LSR в ответ на событие имеет три части:

Краткое изложение. Описание того, как реагирует LSR на события.

Контекст. Список элементов относящихся к части алгоритма спецификации. (Смотри 3.)

Алгоритм. Алгоритм отклика LSR на событие.

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

Алгоритмы в данном разделе используют процедуры, определенные спецификацией архитектуры MPLS [RFC 3031] для маршрутизации трафика шаг-за-шагом. Это следующие процедуры:

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

Независимое управление Downstream Unsolicited , называемое в [RFC3031] PushUnconditional .

Упорядоченное управление Downstream Unsolicited? называемое в [RFC 3031] PushConditional.

Независимое управление Downstream On Demand, называемое в [RFC 3031] PulledUnconditional.

Упорядоченное управление Downstream On Demand, называемое в [RFC 3031] PulledConditional.


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

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

Никаких запросов. LSR никогда не посылает запросов метки.

Запросить, когда нужно. LSR запрашивает метку, когда она ему требуется.

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

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

Консервативное сохранение (retention) метки, называемое освобождение при замене (Release On Change) [RFC3031].

Свободное сохранение метки, называемое никакого освобождения при замене (No Release On Change) [RFC3031].

Процедура использования метки (Label Use ), которая выполняется LSR, чтобы определить, когда начать использование переадресации для ассоциации FEC-метка. Архитектура определяет три процедуры использования метки:

Немедленное использование (Use Immediate). LSR немедленно использует для переадресации, метку, полученную от узла следующего шага для заданного FEC.

Использование, если нет петель. LSR использует для переадресации пакетов FEC-метку, полученную от узла следующего шага для данного FEC, если только заранее известно, что это не приведет к зацикливаниям.

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

Процедура Label No Route (называемая в [RFC3031] Label Not Available [метка недоступна]), которая выполняется вышестоящим LSR, чтобы определить, как реагировать на уведомление об отсутствии маршрута от нижестоящего LSR в ответ на запрос FEC-метки. Архитектура спецификации определяет две процедуры Label No Route:

Повторная попытка запроса. LSR должен выдать запрос метки позднее.

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


Пример реализации


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

Современные реализации на Unix-платформах мультикастинг протоколов маршрутизации (DVMRP, PIM) имеют MFC (Multicast Forwarding Cache). MFC является кэшированной копией мультикастинг таблицы маршрутизации. MFC запрашивает рекорд для определенной мультикаст-группы, когда обнаруживает отсутствие нужной информации в кэше для входящего пакета. Недостающая маршрутная информация предоставляется мультикаст-демоном. Если позднее ситуация с маршрутами изменится (добавлен или удален выходной интерфейс), мультикаст-демон обновит MFC.

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

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



Ниже приведены примеры заголовок сообщений,


Ниже приведены примеры заголовок сообщений, содержащих 'кодировочные слова':
From: =?US-ASCII?Q?Keith_Moore?=
To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?=
CC: =?ISO-8859-1?Q?Andr=E9?= Pirard
Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
=?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
В выше приведенном примере в 'кодировочном слове' поля, последний символ "=" в конце кодированного текста необходим, так как каждое 'кодировочное слово' должно быть самодостаточным (символ "=" завершает группу из 4 символов base64 представляющих 2 октета). Дополнительный октет может быть закодирован в первом 'кодировочном слове' (так чтобы 'кодировочное слово' содержало число октетов кратное трем). Второе 'кодировочное слово' использует символьный набор, не совпадающий с тем, что применен в первом слове.
From: =?ISO-8859-1?Q?Olle_J=E4rnefors?=
To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
>Subject: Time for ISO 10646?
To: Dave Crocker
Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
Subject: Re: RFC-HDR care and feeding
From: Nathaniel Borenstein
(=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
To: Greg Vaudreuil , Ned Freed
, Keith Moore
Subject: Test of new header generator
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Правила несколько отличаются для полей, определенных как '*text' так как "(" и ")" не распознаются в качестве разделителей комментария. [Секция 5, параграф (1)].
В каждом из следующих примеров, если бы одна и та же последовательность встретилась в поле '*text', форма "Отображается как" не рассматривалась бы как кодировочные слова, а была бы идентична форме "Кодированное представление". Это происходит, потому что каждое из 'кодировочных слов' в ниже приведенных примерах соседствуют с символами "(" или ")".
Кодированное представление Отображается как
(=?ISO-8859-1?Q?a?=) (a)
(=?ISO-8859-1?Q?a?= b) (a b)

В пределах 'комментария', HT или SP должны появляться между 'кодировочным словом' и окружающим текстом. [Секция 5, параграф (2)]. Однако HT или SP не нужны между начальным символом "(", который открывает 'комментарий', и 'кодировочным словом'.
(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab)

HT или SP между смежными 'кодировочными словами' не отображаются.
(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab)

Даже кратные пробелы между 'кодировочными словами' игнорируются.

(=?ISO-8859-1?Q?a?=
=?ISO-8859-1?Q?b?=) (ab) Любое число LWS между 'кодировочными словами', даже если там содержится CRLF, за которым следует один или более пробелов, игнорируется.
(=?ISO-8859-1?Q?a_b?=) (a b)

Для того чтобы пробел был отображен в пределах кодированного текста, SP должен быть закодирован в качестве части 'кодировочного слова'.
(=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b)

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

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


В архитектуре MPLS, решение об установлении соответствия конкретной метки L и класса FEC F принимается LSR, который является нижестоящим по отношению к этой ассоциации. Нижестоящий LSR информирует вышестоящий LSR об установлении этой ассоциации. Таким образом, метки присваиваются нижестоящим объектом и рассылаются "снизу-вверх".

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



Прямое управление по меткам


В традиционном MPLS, интерфейсы, используемые LSP могут управляться через определенный маршрут, т.е., ERO или ER-Hop. Это допускает включение определенных узлов/интерфейсов, и завершение LSP в конкретном выходном интерфейсе выходного LSR. Где могут нумероваться интерфейсы, смотри в [MPLS-UNNUM].

Существуют случаи, когда существующая явная семантика маршрута не предоставляет достаточно информации для управления LSP на желательном уровне. Это происходит в случае, когда LSP-инициатор хочет выбрать метку, используемую каналом. Точнее проблема заключается в том, что ERO и ER-Hop не поддерживают явных субобъектов меток. Примером, где желателен такой механизм, является случай, где имеется два LSP, которые должны быть связаны друг с другом, т.е., где конец первого LSP нужно связать с началом второго LSP. Этот последний случай, вероятно, следует использовать в не-PSC классах каналов. Чтобы покрыть этот случай, введен Label ERO subobject/ER Hop.



Процедура аннулирования


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

Входной узел предваряет ликвидацию LSP введением объекта административного статуса в сообщение Path и установкой битов R (Reflect) и D (Delete).

Транзитные и выходной узлы обрабатывают объект административного статуса, как это было описано выше.

По получении объекта административного статуса с битом D (Delete) =1 в сообщении Resv, входной узел посылает сообщение PathTear вниз по течению, чтобы ликвидировать LSP, при выполняется обычная обработка RSVP.

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

Выходной узел индицирует свое желание аннулирования путем введения объекта своего административного состояния в сообщение Resv и установки битов R (Reflect) и D (Delete).

Транзитные узлы обрабатывают объект административного состояния, как это описано выше.

По получении в сообщении Resv объекта Admin Status с битом D (Delete) =1, входной узел посылает сообщение PathTear вниз по течению, чтобы ликвидировать LSP.



Процедура регистрации


Следующая процедура была применена IANA для обзора и одобрения новых типов среды. Для регистрации в рамках дерева IETF, нужно следовать обычной процедуре, осуществляя на первом этапе рассылку интернет-проекта. Для регистрации в рамках частного дерева или дерева производителя осуществляется без широкого обсуждения. Проект непосредственно направляется IANA (по адресу iana@iana.org).

2.3.1. Представление типа среды на суд сообщества

Все начинается с посылки предложения регистрации типа среды лист-серверу . Отклики ожидаются в течение двух недель. Этот подписной лист был учрежден для целей обсуждения предлагаемых типов среды и доступа. Предложенные типы среды, если они формально не зарегистрированы, не могут быть использованы; префикс "x-", специфицированный в RFC-2045, может применяться до тех пор, пока процесс регистрации не завершится.

Типы среды, регистрируемые в рамках дерева IETF должны представляться на одобрение IESG.

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



Процедуры


Узел, обрабатывающий сообщение Path, содержащее запрос обобщенной метки, должен проверить, что запрошенные параметры отвечают возможностям интерфейса, которому приходящая метка должна быть присвоена, самого узла, и интерфейса, через который передается трафик. Узел может непосредственно поддерживать LSP или использовать туннель (FA), т.е. другой класс коммутации. В любом случае, должен проверяться каждый параметр. Заметим, что локальная политика узла определяет то, когда могут использоваться туннели и когда они могут создаваться. Локальная политика допускает динамическое создание туннелей или динамическое управление. Более подробную информацию о туннелях и обработке ER-шагов при использовании туннелей можно найти в [MPLS_HIERARCHY].

Транзитные и оконечный узел должны проверять, что сам узел и, где необходимо, интерфейс или туннель, куда предается трафик, поддерживают запрошенный тип кодирования LSP. Если кодирование не поддерживается, узел должен генерировать сообщение PathErr, с указанием "Routing problem/Unsupported Encoding" (проблема маршрутизации/неподдерживаемое кодирование).

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

Параметр G-PID контролируется только на выходе. Если указанный G-PID не поддерживается, тогда выходной узел должен сформировать сообщение PathErr с указанием "Routing problem/Unsupported L3PID" (проблема маршрутизации/неподдерживаемый L3PID). В этом случае PSC и, когда запрашивается выдача предпоследнего узла (PHP), предпоследний узел также проверяет (запоминает) G-PID при обработке сообщения Resv. При этом если G-PID не поддерживается, тогда предпоследний узел должен сформировать сообщение ResvErr с указанием "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Сформированное сообщение ResvErr может содержать набор приемлемых меток, смотри раздел 4.1.

Когда не формируется сообщение об ошибке, происходит нормальная обработка. В случае транзитных узлов это обычно приводит к передаче сообщения Path. В случае оконечного узла и специального варианта PHP это вызывает генерацию сообщения Resv.


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

Получатель сообщения Resv, содержащего обобщенную метку, проверяет, приемлемость полученных параметров. Если метка неприемлема, тогда получатель должен сформировать сообщение ResvErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/ошибка присвоения обобщенной метки MPLS).




Процедуры, определенные в разделе 2.3.1, работают при коммутации диапазонов длин волн. Если какое-либо поле метки не распознано или имеет неприемлемое значение, генерируется сообщение ResvErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/ошибка присвоения обобщенной метки MPLS).

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

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




Набор меток определяется одним или более объектами Label_Set. Специфические метки/субканалы могут быть добавлены или удалены из набора меток посредством объектов операций нуль (0) и один (1), соответственно. Диапазоны меток/субканалов могут дополняться или удаляться из набора меток посредством действий два (2) и три (3) объектов, соответственно. Когда объекты Label_Set только перечисляют метки/субканалы, подлежащие удалению, это подразумевает, что остальные метки приемлемы. Отсутствие любого объекта Label_Set подразумевает, что все метки приемлемы. Набор меток (Label Set) включается, когда узел желает ограничить перечень меток, которые могут использоваться ниже по течению.

По получении сообщения Path, принимающий узел ограничит выбор меток одной из (Label Set). Узлы, способные осуществлять преобразования меток, могут также удалять набор меток, прежде чем переадресовать сообщение Path. Если узел не может извлечь метку из набора, или если возникает проблема с анализом объектов Label_Set, тогда реализация запроса завершается, и формируется сообщение PathErr с указанием "Routing problem/Label Set" (проблема маршрутизации/набор меток).

По получении сообщения Path, список меток сравнивается с набором доступных меток для нисходящего интерфейса и список перекрытия пересылается в сообщении Path. Когда результирующий набор меток пуст, маршрут разрывается и посылается сообщение PathErr с указанием "Routing problem/Label Set" (проблема маршрутизации/набор меток).

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

При обработке сообщения Resv в промежуточном узле, метка, передаваемая наверх должна входить в перечень меток (Label Set).

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




Процесс установления двунаправленного LSP реализуется также как и для однонаправленного LSP с некоторыми дополнениями. Для поддержки двунаправленных LSP в сообщение Path добавляется объект Upstream_Label. Объект Upstream_Label должен определять метку, которая пригодна для переадресации в момент отправки сообщения Path.

Когда получено сообщение Path, содержащее объект Upstream_Label, получатель сначала проверяет то, что вышестоящая метка приемлема. Если метка неприемлема, получатель должен послать сообщение PathErr с указанием "Routing problem/Unacceptable label value" (проблема маршрутизации/неприемлемое значение метки). Сформированное сообщение PathErr может содержать набор приемлемых меток, смотри раздел 4.1.

Промежуточный узел должен присвоить метку для исходящего интерфейса и установить внутренние проходы для данных перед записью исходящей метки и отправкой сообщения Path. Если промежуточный узел не может присвоить метку или выделить внутренние ресурсы, то он должен послать сообщение PathErr с указанием "Routing problem/MPLS label allocation failure" (проблема маршрутизации/отказ выделения метки MPLS). Оконечные узлы обрабатывают сообщения Path как обычно, за исключением того, что вышестоящая метка может быть использована немедленно для передачи трафика данных, ассоциированных с LSP в направлении узла-инициатора.

Когда удаляется двунаправленный LSP, upstream (вышестоящая) и downstream (нижестоящая) метки аннулируются, после чего они становятся непригодными для пересылки данных.




Объект запроса уведомления (Notify Request) может быть введен в сообщение Path или Resv, чтобы указать адрес узла, который должен быть уведомлен об отказе LSP. Как было замечено выше, могут посылаться запросы уведомления как вверх, так и вниз по течению. Уведомления, направленные вверх, отмечаются включением объекта запроса уведомления (Notify Request Object) в соответствующее сообщение Path. Уведомления, направленные вниз, отмечаются включением объекта запроса уведомления в соответствующее сообщение Resv. Узел, получающий сообщение, которое содержит объект запроса уведомления, должен запомнить адрес узла уведомления (Notify Node Address) в соответствующем блоке состояний. Если узел является транзитным, он также должен включить объект запроса уведомления в исходящее сообщение Path или Resv. Исходящий адрес узла уведомления может корректироваться на основе местной политики.

Заметим, что включение объекта запроса Notify не гарантирует того, что сообщение Notify будет генерировано.




Сообщения Notify чаще всего генерируются узлами, которые зарегистрировали ошибку, которая запустила процесс формирования сообщения PathErr или ResvErr. Если нужно сформировать сообщение PathErr и получен объект запроса уведомления в соответствующем сообщении Path, тогда должно быть сформировано сообщение Notify, адресованное указанному узлу. Если должно быть сформировано сообщение ResvErr и в соответствующем сообщении Resv получен объект запроса уведомления, тогда должно быть сформировано сообщение Notify, адресованное указанному узлу. Как ранее упоминалось, одна ошибка может вызвать сообщения Notify, направленные вверх и вниз по течению. Заметим, что сообщение Notify не должно генерироваться, если только не получен соответствующий объект запроса уведомления.

Когда генерируются сообщения Notify, узел должен попытаться объединить уведомления, адресованные одному и тому же узлу, и использовать в сообщении Notify одну и ту же общую ERROR_SPEC. Средства, с помощью которых узел определяет, какую информацию можно объединить, зависят от конкретной реализации. Если для этой цели используется таймер, реализация должна позволять пользователю конфигурировать интервал, в течение которого уведомления объединяются. Когда используется таймер, длительность интервала уведомлений по умолчанию равна 1 мсек. Сообщения Notify должны доставляться с использованием механизма надежной доставки, описанного в [RFC2961].

По получении сообщения уведомления узел должен послать соответствующие сообщение Ack.




Субобъект метки следует за субобъектом, содержащим IP-адрес, или идентификатор интерфейса [RFC3477], ассоциированные с каналом, где его планируется использовать. Могут присутствовать до двух субобъектов метки, один для метки вниз и один для метки вверх по течению. В следующих ситуациях вырабатывается сигнал ошибки "Bad EXPLICIT_ROUTE object" (плохой объект явного маршрута):

Если субобъект, содержащий IP-адрес, не предшествует первый субобъект метки или идентификатор интерфейса [RFC3477], ассоциированные с исходящим каналом.

Для субобъекта метки, следующего за субобъектом с установленным битом L.

При установке однонаправленного LSP, если должен быть субобъект метки с установленным битом U.

Если имеются два субобъекта метки с идентичными значениями бита U.

Чтобы поддерживать субобъект метки узел должен проверять, является ли субобъект, следующий за его ассоциированным адресом/интерфейсом, субобъектом метки. Если это так, один суьобъект просматривается для однонаправленных LSP и два - для двунаправленных. Если бит U субобъекта равен нулю, тогда значение метки копируется в новый объект Label_Set. Этот объект Label_Set должен быть включен в соответствующее исходящее сообщение Path.

Если U-бит рассматриваемого субобъекта равен 1, тогда метка относится к восходящему потоку (для двунаправленного LSP). Если эта метка неприемлема, должно формироваться сообщение ошибки "Bad EXPLICIT_ROUTE object" (плохой объект явного маршрута). Если метка приемлема, она копируется в новый объект Upstream_Label. Этот объект Upstream_Label должен быть включен в соответствующее исходящее сообщение Path. После обработки субобъекты метки, удаляются из ERO.

Из рассмотрения описанных процедур следует вывод, что субобъекты метки никогда не могут быть первыми субобъектами во вновь полученном сообщении. Если субобъект метки является первым субобъектом в полученном ERO, тогда ситуация должна рассматриваться как ошибка "Bad strict node".




Субобъекты RRO метки включаются в RRO, как это описано в [RFC3209]. Единственной модификация использования и обработки по сравнению с [RFC3209] заключается в том, что когда метки записываются для двунаправленных LSP, должны быть добавлены субобъекты для обоих направлений.




Транзитные узлы, обрабатывающие сообщение Path, которое содержит объект защиты (Protection Object), должны проверять, можно ли реализовать запрашиваемую защиту в выходном интерфейсе или туннеле (FA). Если это невозможно, узел должен сформировать сообщение PathErr, со значением "Routing problem/Unsupported Link Protection" (проблема маршрутизации/неподдерживаемая защита канала).




Объект IF_ID RSVP_HOP используется вместо определенных выше объектов RSVP_HOP. Он применяется в соединениях, где нет однозначных ассоциаций между каналами управления и данных, смотри [RFC3471]. Поля Hop Address (адрес шага) и указатель логического интерфейса используются в соответствии со стандартом RSVP [RFC2205].

TLV применяются для идентификации каналов данных, ассоциированных с LSP. Для однонаправленных LSP, должен быть указан нисходящий канал данных. Для двунаправленных LSP, указывается общий нисходящий и восходящий информационный канал. В специальном случае, когда двунаправленный LSP проходит через многоканальное (объединенное) соединение, можно специфицировать нисходящий информационный канал, отличающийся от восходящего канала. Информационные каналы специфицируются с точки зрения отправителя сообщения Path. Объект IF_ID RSVP_HOP не должен использоваться, когда TLV не нужны.

Узел, получающий один или более TLV в сообщении Path, сохраняет их величины и возвращает в объектах HOP последующих сообщений Resv, посылаемых узлу, откуда пришли TLV.

Заметим, что узел, создающий объект IF_ID должен гарантировать, что выбранный выходной интерфейс, как это определено в объекте IF_ID, согласуется с ERO. Узел, который получает объект IF_ID, должен проверить является ли информация, содержащаяся в объекте, совместимой с данными, полученными в ERO, и, если это не так, должен послать отправителю сообщение PathErr с кодом ошибки "Routing Error" (ошибка маршрутизации) и значением ошибки "Bad Explicit Route Object" (плохой объект явного маршрута). Эта проверка не может быть выполнена, когда исходный субобъект ERO не является входным интерфейсом.




Узлы, желающие указать, какая ошибка относится к какому интерфейсу, должны использовать соответствующий объект IF_ID ERROR_SPEC в сообщениях PathErr или ResvErr. Объекты IF_ID ERROR_SPEC должны генерироваться и обрабатываться также, как и другие объекты ERROR_SPEC, смотри [RFC2205].



Процедуры анонсирования и использования меток


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

-  Процедуру рассылки и
- Процедуру отзыва.

Вышестоящий LSR должен выполнить:
-  Процедуру Request и
-  Процедуру NotAvailable и
-  Процедуру Release и
-  Процедуру labelUse.

Архитектура MPLS поддерживает несколько разных вариантов каждой процедуры. Однако архитектура MPLS не поддерживает все комбинации возможных вариантов. Набор поддерживаемых комбинаций будет обсужден в разделе 4.2, где рассматривается совместимость различных комбинаций.



Процедуры числа шагов


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

Если LSR R пересылает сообщение присвоения метки для LSP вышестоящему партнеру или запрос метки партнеру вниз по течению, он должен определить число шагов, чтобы включить его в передаваемые сообщения:

Если это сообщение запроса метки, R должен инкрементировать полученное значение числа шагов;

Если это сообщение присвоения метки, R определяет число шагов следующим образом:

Если R является одним из пограничных LSR домена, где не производится декрементация TTL, а вышестоящий партнер находится внутри домена, R, преже чем пересылать сообщение, должен сбросить счетчик числа шагов в 1.

В противном случае, R должен инкрементировать полученное число шагов.

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

По соглашению значение 0 говорит, что число шагов неизвестно. Результатом инкрементации неизвестного числа шагов остается значение 0.

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

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

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

Если сконфигурировано детектирование петель, LSR должен следовать процедурам, рассмотренным в разделе "Детектирование петель".



Процедуры для перезапускаемого узла


После того как узел перезапускает свои функции управления, узел, который поддерживает состояние восстановления, должен проверить, способен ли он сохранить свое состояние переадресации MPLS. Если никакого состояния переадресации не сохранено, тогда в сообщении Hello, посланном своим соседям, узел должен установить время восстановления равным 0.

Если состояние переадресации сохранено, тогда узел инициирует процесс восстановления. Период, в течение которого узел поддерживает процесс восстановления, называется периодом восстановления (Recovery Period). Полная длительность периода восстановления анонсируется восстанавливающимся узлом в параметре Recovery Time (время восстановления) объекта Restart_Cap. Время восстановления должно быть установлено равным длительности периода восстановления во всех сообщениях Hello, посланных за время периода восстановления. Состояние, которое не синхронизовано в период восстановления, должно быть удалено в конце этого периода.

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

Когда узел получает сообщение Path за время периода восстановления, узел сначала проверяет, имеется ли состояние RSVP, ассоциированное с сообщением. Если состояние найдено, тогда узел обрабатывает это сообщение согласно определенным ранее процедурам.

Если состояние RSVP не найдено, и сообщение не содержит в себе объект Recovery_Label, узел рассматривает это, как сигнал к установлению нового LSP, и обрабатывает его согласно определенным ранее процедурам.

Если состояние RSVP не найдено, а сообщение несет в себе объект Recovery_Label, узел ищет в его маршрутной таблице MPLS (которая восстановлена при перезапуске) рекорд, чей входной интерфейс согласуется с сообщением Path, и чья входная метка равна метке, содержащейся в объекте Recovery_Label.


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

Если рекорд маршрутной таблицы MPLS найден, формируется состояние RSVP, рекорд связывается с LSP, ассоциированным с сообщением, а состояние переадресации обрабатывается как корректное и обновленное. Должна быть произведена также обработка обычного сообщения Path. При отправке соответствующего исходящего сообщения Path узел должен включить в него объект Suggested_Label со значением метки, согласованным с рекордом восстановленной таблицы маршрутизации. Выходной интерфейс должен выбираться также с учетом рекорда маршрутной таблицы. В особом случае, где перезапускаемый узел имеет также перезапускаемого нижерасположенного соседа, вместо объекта Suggested_Label следует использовать объект Recovery_Label.

Кроме того, для двунаправленных LSP, узел извлекает метку из объекта UPSTREAM_LABEL, содержащегося в полученном сообщении Path, и просматривает таблицу маршрутизации MPLS на предмет рекорда, чья выходная метка равна метке, содержащейся в объекте (в случае многоканальности связи, это может также включать идентификацию соответствующего входного компонента соединения).

Если рекорд таблицы маршрутизации MPLS не найден, узел рассматривает это, как сигнал к установлению нового LSP, и обрабатывает его согласно определенным ранее процедурам.

Если рекорд таблицы маршрутизации MPLS найден, рекорд связывается с LSP, ассоциированным с сообщением Path, и рекорд рассматривается как ресинхронизированный. Кроме того, если узел не является окончанием LSP, посылаются соответствующие сообщения Path с входной меткой, которая содержится в объекте UPSTREAM_LABEL рекорда.

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


Процедуры для сообщений Path и Resv


Объект Admin_Status используется для уведомления каждого узла вдоль пути о состоянии LSP. Статусная информация обрабатывается всеми узлами, основываясь на местной политике, и затем передается соответствующими сообщениями. Объект может быть вставлен в сообщение Path для входного узла или Resv для выходного. Отсутствие объекта эквивалентно получению объекта, со всеми значениями равными нулю. Транзитные узлы, получая сообщения non-refresh Path или Resv, содержащие объект Admin_Status, обновляют свое локальное состояние, выполняют какую-то локальную операцию в соответствии со статусом и затем передают полученный объект Admin_Status посредством исходящего сообщения Path или Resv. Если значения объекта Admin_Status, полученного в сообщении Resv отличаются от значений, полученных в сообщении Path, тогда, с одним исключением, никаких локальных действий не должно быть предпринято, но значения должны быть переданы дальше. Единственная ситуация, когда с полученными в Resv значениями следует осуществить некоторые локальные действия, это случай получения R и D битов равными 1.

Краевые узлы, получающие сообщение non-refresh Path или Resv, содержащее объект Admin_Status, также обновляют свои состояния и выполняют соответствующие локальные операции с учетом текущего состояния. Когда получен объект административного состояния с битом R =1, получивший краевой узел должен перенести полученные значения в соответствующее исходящее сообщение. В частности, если выходной узел получает сообщение Path с битом R Admin_Status =1, а узел ранее послал сообщение Resv, соответствующее сообщению Path, узел должен послать обновленное сообщение Resv, содержащее объект Admin_Status с тем же набором значений, за исключением бита R. Более того, выходной узел должен гарантировать, что последующие сообщения Resv, посланные узлом, содержат тот же самый объект административного состояния.

Кроме того, если входной узел получает сообщение Resv с установленным битом R объекте Admin_Status, узел должен послать обновленное сообщение Path, содержащее объект Admin_Status со значениями, полученными в сообщении Resv, за исключением R-бита. Кроме того, входной узел должен также гарантировать, что последующие сообщения Path, посланные этим узлом, содержат объект административного статуса (Admin Status Object).



Процедуры для соседа перезапускаемого узла


Ниже специфицированы процедуры, которые используются, когда узел восстанавливает коммуникации с системой управления соседа в пределах периода рестарта (Restart Time). Узел определяет (используя процедуры, определенные в разделе 5 [RFC3209]), какую систему управления соседа следует перезапустить, и сохранил ли сосед состояние переадресации при перезапуске. Заметим, что значение времени перезапуска 0xffffffff означает бесконечный временной интервал.

После детектирования рестарта соседа, который поддерживает восстановление состояния, узел должен обновить все состояния Path, используемые совместно с соседом. Исходящие сообщения Path должны включать объект Recovery_Label, содержащий значение метки, соответствующее метке, полученной в последнем сообщении Resv. Все состояния Path должны быть обновлены в пределах примерно 1/2 от времени восстановления, объявленного рестартующим соседом. Если имеется несколько LSP проходящих через рестартующий узел, соседний узел должен избегать посылки сообщений Path в пределах ограниченного временного интервала, чтобы не перегружать ЦПУ соседа. Вместо этого, ему следует распределить сообщения в пределах 1/2 времени восстановления. После детектирования рестарта соседа, который поддерживает восстановление состояния, все состояния Resv используемые совместно с рестартующим узлом не должны обновляться до тех пор, пока не будет получено соответствующее сообщение Path. Это требует подавления обычной обработки Resv и обновлений на время восстановления, объявленного рестартующим соседом. Как только приходит соответствующее сообщение Path, должно быть послано сообщение Resv и разрешена обычная обработка состояния.



Процедуры FEC


Если при декодировании FEC TLV LSR сталкивается с элементом FEC семьи адресов, который он не поддерживает, он должен прервать декодирование FEC TLV, прервать обработку сообщения, содержащего TLV, и послать LDP партнеру уведомление "Unsupported Address Family" (неподдерживаемое семейство адресов), сигнализирующее об ошибке.

Если он сталкивается с типом элемента FEC, который он не может декодировать, ему следует прервать декодирование FEC TLV, прервать обработку сообщения, содержащего TLV, и послать LDP партнеру уведомление "Unknown FEC" (неизвестный FEC), сигнализируя об ошибке.



Процедуры LDP


LDP определяет сообщения, TLV и процедуры в следующих областях:

Выявление партнера;

Управление сессией;

Рассылка меток;

Уведомление об ошибках и справочная информация.

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

Приложение A, "Процедуры рассылки меток LDP", описывает процедуры рассылки меток в терминах событий, которые могут произойти в LSR, и как LSR должен на них реагировать. Приложение A является спецификацией процедур рассылки меток LDP. Если процедура, описанная где-то в этом документе, конфликтует с приложением A, корректным следует считать описание из приложения A.



Процедуры пересылки меток (Hop-by-Hop)


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



Процедуры, применимые к обоим C-типам


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

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

Приоритеты setup и удержания являются прямыми аналогами приоритетного прерывания обслуживания и защитного приоритета, как это определено в [9]. В то время как взаимодействие этих двух объектов является в конце концов вопросом политики, следующие взаимодействия рекомендуются по умолчанию.

Когда присутствуют оба объекта, используется элемент приоритетного прерывания обслуживания. Соответствие между этими приоритетами определено следующим образом. Атрибут приоритета сессии S соответствует приоритету прерывания обслуживания P согласно формуле P = 2(14-2S). Таблица соответствия приоритетов представлена ниже.

Приоритетное прерывание
обслуживанияПриоритет атрибута сессии0 - 374 - 15616 - 63564 - 2554256 - 102331024 - 409524096 - 16383116384 - 655350

Когда рассматривается новое сообщение Path с точки зрения приемлемости, запрашиваемая полоса сравнивается с возможной полосой в случае приоритета, заданного в Setup.

Если запрашиваемая полоса недоступна, посылается сообщение PathErr с кодом ошибки 01 (Admission Control Failure) и значением ошибки 0x0002. Первый 0 в значении ошибки указывает на глобально определенный субкод и не несет в себе конкретных данных. Код 002 указывает "запрошенная полоса недоступна".

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

Когда поддерживается приоритетное прерывание обслуживания, каждое из таких приоритетных резервирований осуществляет запрос TC_Preempt() локальным клиентам, передав субкод, который указывает на причину этого запроса. В этом случае следует послать ниже стоящим получателям и вышестоящим отправителям ResvErr и/или PathErr с кодом "Policy Control failure".

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

Запись субобъекта метка в объект ROUTE_RECORD управляется флагом записи метки в объекте SESSION_ATTRIBUTE. Так как субобъект метка не нужен всем приложениям, он не записывается автоматически. Флаг позволяет приложениям запрашивать это только в случае необходимости.

Содержимым поля имя сессии является строка, обычно отображаемых символов. Поле длина должна всегда быть кратной 4 и быть не меньше 8. Для объектов, длина которых не кратна 4, объект дополняется в конце символами NULL. Поле длина имени содержит длину активной строки.



Процедуры привязки ресурсов


Классы ресурсов и привязки классов ресурсов описаны в [3]. Классы ресурсов могут быть ассоциированы с каналами и объявляться в протоколах маршрутизации. Привязка класса ресурса используется RSVP двумя путями. Для того чтобы канал был признан работающим, он должен пройти три теста. Если тест не прошел, следует послать PathErr с кодом "ошибка управления политикой".

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

Чтобы точно описать тесты, используем определения объектов, представленные выше. Мы также определяем

Link-attr32-битовый вектор, представляющий собой атрибуты, ассоциированные с каналом

Осуществляется три проверки

1. Исключает любой

Эта проверка исключает канал из рассмотрения, если канал характеризуется одним из атрибутов из набора. (link-attr & exclude-any) == 0

2. Включает любой

Этот тест воспринимает канал, если канал характеризуется любым атрибутом из набора. (include-any == 0) | ((link-attr & include-any) != 0)

3. Включает все

Этот тест воспринимает канал, если только канал характеризуется всеми атрибутами из набора. (include-all == 0) | (((link-attr & include-all) ^ include-all) == 0)

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

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

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