A.2.Send_Notification
Краткое изложение:
LSR использует процедуру Send_ Notification, чтобы послать LDP-партнеру сообщение уведомления.
Параметры:
Партнер. LDP-партнер, которому посылается уведомление.
Статус. Статусный код, подлежащий включению в сообщение уведомления.
Алгоритм:
| SNt.1 | Исполнить процедуру Send_Message(Peer, Notification, Status) |
A.3 Сценарий 8 (или менее) BA, общее управление трафиком, общая защита MPLS
Сервис провайдер, работающий через MPLS с 8 (или менее) BA, управляющий трафиком (т.е., реализующий выбор одного общего маршрута для всех BA), может выбрать режим Diff-Serv с одним E-LSP на каждый FEC. При этом обеспечивается общая защита MPLS (т.е., восстановление услуг для всех PSC) и используются вставные заголовки MPLS. Каналы формируются посредством RSVP [RSVP_MPLS_TE] или CR-LDP [CR-LDP_MPLS_TE] с привлечением предварительной конфигурации таблиц соответствия. Процедуры можно суммировать следующим образом:
Сервис провайдер конфигурирует в каждом LSR двунаправленное соответствие между каждым PHB и значением поля EXP (например, 000<-->AF11, 001<-->AF12, 010<-->AF13)
Сервис провайдер конфигурирует каждый LSR, и задает в каждом интерфейсе алгоритм формирования трафика каждого PSC (например, полосу пропускания, выделяемую для AF1) и приоритеты отбрасывания пакетов для каждого PHB (например, схему отбрасывания для AF11, AF12, AF13)
LSR формирует по одному E-LSP на FEC, которые будут использовать предварительное конфигурирование таблиц соответствия:
используя протокол RSVP, как это специфицировано выше (т.e., отсутствие объекта DIFFSERV RSVP в сообщении PATH, содержащем объект LABEL_REQUEST), или
используя протокол CR-LDP, как это специфицировано выше (т.е., отсутствие Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping).
защита активизируется для всех E-LSP, для того чтобы осуществить защиту MPLS за счет механизмов, находящихся за пределами рассмотрения в данном документе.
A.4 Сценарий управление трафиком для каждого OA /защита MPLS
Сервис провайдер, который работает через MPLS с любым числом BA, осуществляет управление трафиком для каждого OA (т.е., выбирая отдельный путь для каждого OA) и выполняет защиту MPLS для каждого OA в сети (т.е., выполняет защиту с потенциально разными уровнями защиты для различных OA), может выбрать режим Diff-Serv через MPLS с использованием одного L-LSP на <FEC,OA>, эта пара устанавливается посредством RSVP или CR-LDP. Процедуры можно суммировать следующим образом:
Сервис провайдер конфигурирует каждый LSR и задает для каждого интерфейса алгоритм формирования трафика каждого PSC (например, полосу пропускания, выделяемую для AF1) и приоритеты отбрасывания пакетов для PHB (например, схему отбрасывания для AF11, AF 12, AF13);
LSR формирует по одному L-LSP для каждого <FEC,OA>:
используя RSVP, как это описано выше, для согласования L-LSP PSC (т.е., объекта DIFFSERV RSVP в сообщении PATH, содержащем LABEL_REQUEST), или
используя протокол CR-LDP, как это специфицировано выше, для согласования L-LSP PSC (т.е., Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping).
активируется разный уровень защиты (потенциально разный уровень защиты для каждого PSC).
A.6 Сценарий отсутствие управления
Сервис провайдер, который не выполняет управление трафиком и не осуществляет защиту MPLS для 8 (или менее) BA, выполняет управление трафиком для каждого OA/защиту MPLS для прочих BA (т.е., формирует отдельный путь для каждого OA, соответствующего другим BA и осуществляет защиту MPLS с потенциально разной политикой для каждого из этих OA) и использует вставные заголовки MPLS, может выбрать режим Diff-Serv через MPLS, используя для каждого FEC:
один E-LSP, использующий предварительную конфигурацию таблиц соответствия, формируемых посредством LDP, чтобы поддерживать набор из 8 (или менее) BA без управления трафиком/без защиты, и
один L-LSP на пару <FEC,OA>, сформированную посредством RSVP или CR-LDP для поддержки других BA.
Процедуры можно суммировать следующим образом:
Сервис провайдер конфигурирует для каждого LSR двунаправленное соответствие между PHB и значением поля EXP для BA, поддерживаемых через E-LSP;
Сервис провайдер конфигурирует каждый LSR и задает для каждого интерфейса алгоритм формирования трафика PSC, поддерживаемый в E-LSP и приоритеты отбрасывания пакетов для каждого PHB;
Сервис провайдер конфигурирует каждый LSR и задает для каждого интерфейса алгоритм формирования трафика PSC, поддерживаемый в L-LSP и приоритеты отбрасывания пакетов для каждого PHB;
LSR сообщают об установлении отдельного E-LSP для каждого FEC в отсутствии управления трафиком для BA, используя LDP, как это специфицировано выше (т.е., без Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping);
LSR сообщают об установлении отдельного L-LSP при <FEC,OA> для остальных BA:
используя протокол RSVP, как это специфицировано выше, для установления L-LSP PSC (т.е., объект DIFFSERV RSVP в сообщении PATH, содержащем объект LABEL_REQUEST), или
используя протокол CR-LDP, как это специфицировано выше, для установления L-LSP PSC (т.е., Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping).
для E-LSP защита не реализуется.
в разных L-LSP достигается соответствующий уровень защиты (потенциально с разным уровнем защиты, зависящим от L-LSP PSC).
A.Обработка событий при рассылке меток
В данном разделе определены процедуры LDP рассылки меток, путем описания алгоритма для каждого варианта рассылки. Требования, предъявляемые к реализации LDP, заключаются в том, что обработка событий должна иметь результат, специфицированный алгоритмом. То есть, реализация не должна следовать в точности шагам, описанным в алгоритме, если достигается аналогичный результат.
Алгоритмы для обработки событий, сопряженных с рассылкой меток, используют аналогичные операции. Приведенные ниже спецификации объединяют эти операции в процедурные блоки. Спецификации этих общих процедур содержатся в разделе "Общие процедуры рассылки меток".
Реализация должна использовать структуры данных, чтобы хранить информацию о протокольной активности. В этом приложении специфицирована информация, которую следует записывать, чтобы охарактеризовать статус алгоритма.
A.Общие процедуры рассылки меток
В этом разделе специфицированы процедуры и утилиты, используемые алгоритмом обработки событий при рассылке меток.
A.Сценарий 8 (или менее) BA, отсутствие управления трафиком, отсутствие защиты MPLS
Сервис провайдер, работающий с 8 (или меньше) BA через MPLS, без управления трафиком, без MPLS-защиты и использующий инкапсуляцию вставных заголовков MPLS, может решить работать с Diff-Serv через MPLS, используя по одному E-LSP на FEC, сформированные посредством LDP. Кроме того, сервис провайдер может решить использовать предварительно сконфигурированную таблицу EXP<-->PHB. Процедуры можно суммировать следующим образом:
Сервис провайдер конфигурирует для каждого LSR, двунаправленное соответствие между каждым PHB и значением поля EXP (например, 000<-->AF11, 001<-->AF12, 010<-->AF13);
Сервис провайдер конфигурирует для каждого LSR, и для каждого интерфейса, порядок обработки каждого PSC (например, полоса пропускания, выделяемая AF1) и приоритеты отбрасывания для каждого PHB (например, режим отбрасывания для AF11, AF12, AF13);
LSR формирует один E-LSP на один FEC, используя LDP в соответствии со спецификацией, представленной выше (т.е., без Diff-Serv TLV в сообщениях LDP запрос метки/ассоциация метки, неявно указывая на то, что является E-LSP и что он использует предварительно сконфигурированное соответствие).
A.Сценарий 8 (или менее) BA, управление трафиком для каждого OA /защита MPLS
Сервис провайдер работающий через MPLS с 8 (или менее) BA, выполняя управление трафиком для каждого OA (т.е., формируя отдельный маршрут для каждого OA) и выполняя защиту MPLS для каждого OA (т.е., осуществляя защиту с потенциально разными уровнями для разных OA), может выбрать работу с Diff-Serv через MPLS, используя по одному E-LSP на пару <FEC,OA>, определяемую посредством RSVP или CR-LDP. Кроме того, сервис провайдер может выбрать предварительное конфигурирование таблиц согласования для всех E-LSP. Процедуры можно суммировать следующим образом:
Сервис провайдер конфигурирует для каждого LSR двунаправленное соответствие между PHB и значением поля EXP (например, 000<-->AF11, 001<-->AF12, 010<-->AF13)
Сервис провайдер конфигурирует каждый LSR и задает для каждого интерфейса, алгоритм формирования трафика каждого PSC (например, полосу пропускания, выделенную для AF1) и приоритеты отбрасывания пакетов для каждого PHB (например, схему отбрасывания для AF11, AF12, AF13)
LSR согласует формирование одного E-LSP для каждого <FEC,OA>:
используя протокол RSVP, как это специфицировано выше, для уведомления о том, что LSP является E-LSP, который использует предварительно сконфигурированную таблицу соответствий (т.е., отсутствие объекта DIFFSERV RSVP в сообщении PATH, содержащем LABEL_REQUEST), или
используя протокол CR-LDP, как это специфицировано выше, для уведомления о том, что LSP является E-LSP, который использует предварительно сконфигурированную таблицу соответствий (т.е., отсутствие Diff-Serv TLV в сообщениях LDP Label Request/Mapping)
Сервис провайдер конфигурирует для каждого E-LSP в начальном конце этого пути критерии отбора/переадресации так, чтобы только пакеты, принадлежащие данному OA, переадресовывались в E-LSP, сформированный для соответствующего FEC и OA.
заданный уровень защиты достигается в разных E-LSP (потенциально с разными уровнями защиты в зависимости от PSC, транспортируемого через каждый E-LSP) за счет механизмов, которые не рассмотриваютсЯ в данной статье.
A.Сценарий Более 8 BA, отсутствие управления трафиком, отсутствие защиты MPLS
Сервис провайдер, работающий через MPLS с более чем 8 BA, без управления трафиком, без использования MPLS защиты и с применением вставных заголовков MPLS, может выбрать режим Diff-Serv поверх MPLS для каждого FEC:
один E-LSP, сформированный с помощью LDP и использующий предварительно сконфигурированную таблицу соответствия для поддержания набора из 8 (или менее) BA, и
один L-LSP, для каждой пары <FEC,OA>, сформированных посредством LDP для поддержания других BA.
Процедуры можно суммировать следующим образом:
Сервис провайдер конфигурирует в каждом LSR двунаправленное соответствие между каждым PHB и значением поля EXP для BA транспортируемого через E-LSP;
Сервис провайдер конфигурирует каждый LSR и определяет в каждом интерфейсе, алгоритм формирования трафика каждого PSC, поддерживаемого для E-LSP , задает приоритеты отбрасывания пакетов для каждого PHB;
Сервис провайдер конфигурирует каждый LSR и определяет в каждом интерфейсе алгоритм формирования трафика каждого PSC, поддерживаемого для L-LSP и задает приоритеты отбрасывания пакетов для каждого PHB;
LSR согласуют формирование отдельного E-LSP для каждого FEC набора E-LSP, транспортирующего BA, используя LDP, как это специфицировано выше (т.е., без Diff-Serv TLV в LDP сообщениях Label Request/Label Mapping, чтобы неявно индицировать, что LSP является E-LSP и что он использует предварительно сконфигурированные таблицы соответствия).
LSR согласуют формирование отдельного L-LSP на каждую пару <FEC,OA> для прочих BA, используя LDP, как это специфицировано выше (т.е., Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping, чтобы индицировать L-LSP PSC).
Административная информация состояний
Административная статусная информация содержится в объекте Admin_Status. Объект предоставляет информацию, относящуюся к административному состоянию конкретного LSP. Информация используется двумя способами. В первом, объект содержится в сообщениях Path и Resv для указания административного состояния LSP. Во втором, объект транспортируется в сообщении уведомления для запроса к входному узлу изменить административное состояние LSP.
Адрес пересылки PDP (PDPRedirAddr)
PDP при закрытии PEP-сессии для конкретного типа клиента может опционно использовать этот объект для того чтобы переадресовать PEP на специфицированный адрес сервера и заданный порт TCP:
C-Num = 13,
C-Type = 1, IPv4-адрес+ TCP порт
| 0 | 1 | 2 | 3 |
| Формат IPv4-адреса | |||
/////////////////////////
C-Type = 2, IPv6-адрес + TCP порт
0
Формат IPv6-адреса
Агрегатирование
В уникастинге различные адреса места назначения объединяются в одной записи маршрутной таблицы, предоставляя один FEC и один LSP.
Гранулярность мультикастинг потоков равна (*, G) для совмещенных деревьев и (S,G) для деревьев отправителя, где S - адрес отправителя, а G - мультикастинг адрес группы.
Одним из путей распределения трафика в FEC является создание отдельного FEC для каждого адресного префикса, появляющегося в маршрутной таблице. Однако в пределах области MPLS, это может вызвать определенные последствия для набора FEC, в частности, все потоки в этих FEC будут следовать одним и тем же маршрутом. Например, набор различных адресных префиксов может иметь один и тот же выходной узел, а обмен меток может быть использован только для доставки трафика до выходного узла. В этом случае, в пределах домена MPLS, объединение таких FEC само является классом FEC. Это предлагает выбор: следует ли ассоциировать отдельные метки с каждым компонентом FEC, или следует ли ассоциировать отдельную метку с объединением, а метку использовать для всего трафика в объединении? Процедура ассоциации отдельной метки с объединением FEC, который сам является FEC (внутри некоторого домена), и применения меток для трафика в объединении, называется "агрегатированием". Архитектура MPLS допускает агрегатирование. Агрегатирование может уменьшить число меток, с которыми нужно иметь дело заданному набору пакетов, и может сократить объем управляющего трафика.
Данный набор FEC, который является "агрегатируемым" в одном FEC, допускается (a) агрегатировать их в один FEC, (b) агрегатировать их в набор FEC, или (c) не агрегатировать их совсем. Таким образом, мы можем говорить о "гранулярности" агрегатирования, начиная с (a) "грубой гранулярности", кончая (c) "тонкой гранулярностью".
Когда используется упорядоченное управление, каждый LSR должен адаптировать для данного набора FEC гранулярность, используемую на следующем шагу для этих FEC.
Когда используется независимое управление, допускается, чтобы имелись два смежных LSR, Ru и Rd, которые агрегатируют некоторый набор FEC по-разному.
Если Ru имеет более тонкую гранулярность, чем Rd, это не создает проблем. Это означает, что, когда Ru нужно переадресовать помеченные пакеты для этих FEC в Rd, может потребоваться установить соответствие между n и m метками, где n > m. В качестве опции Ru может отозвать набор из n меток, который он разослал, и затем разослать набор из m меток, соответствующих уровню гранулярности Rd. Совсем не нужно гарантировать корректность операции, но это вызовет сокращение числа меток, разосланных Ru, Ru не получает какого-либо преимущества при рассылке большего числа меток. Решение делать это или нет, является исключительно локальным.
Если Ru имеет более грубую гранулярность, чем Rd (т.e., Rd разослал n меток для набора FEC, в то время как Ru разослал m, где n > m), имеется два варианта:
- Можно принять более тонкий уровень гранулярности для Rd. Это бы потребовало отзыва разосланных m, и рассылки n меток. Это предпочтительная опция.
- Можно просто установить соответствие между m метками и субнабором Rd из n меток, если он может определить, что это не изменит маршрутизацию. Например, предположим, что Ru использует одну метку для всех потоков, которые должны пройти определенный выходной LSR, тогда как Rd привязывает к такому трафику некоторое число разных меток, в зависимости от места назначения пакетов. Если Ru знает адрес выходного маршрутизатора, и, если Rd связал метку с FEC, который идентифицирован этим адресом, тогда Ru может просто использовать эту метку.
В любом случае, каждый LSR должен знать (при конфигурации) какую гранулярность использовать для формируемых меток. Когда используется упорядоченное управление, требуется чтобы каждый узел знал гранулярность только для FEC, который покидает сеть MPLS в этом узле. Для независимого управления, наилучший результат может быть получен, путем конфигурации всех LSR так, чтобы они знали гранулярность каждого FEC. Однако во многих случаях это может быть сделано путем использования одной метки с гранулярностью, которая реализует все FEC (такой как "одна метка на IP-префикс таблицы переадресации" или "одна метка на выходной узел").
Архитектура мультипротокольной коммутации пакетов по меткам (MPLS)
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
(E. Rosen. Multiprotocol Label Switching Architecture, RFC-3031.)
AСценарий Более 8 BA, отсутствие управления трафиком, отсутствие защиты MPLS
Сервис провайдер, работающий через MPLS с более чем 8 BAs, без управления трафиком, без защиты MPLS и использующий вставные заголовки MPLS, может выбрать режим Diff-Serv, используя два E-LSP на один FEC, установленный посредством LDP и согласованные таблицы EXP<-->PHB.
Процедуры можно суммировать следующим образом:
Сервис провайдер конфигурирует для каждого LSR и каждого интерфейса алгоритм формирования трафика PSC (например, полосу пропускания, выделенную для AF1) и приоритеты отбрасывания пакетов для каждого PHB (например, схему отбрасывания для AF11, AF12,AF13)
LSR сообщают об установлении двух E-LSP для каждого FEC, используя LDP в соответствии с вышеприведенной спецификацией (т.e., Diff-Serv TLV в сообщениях LDP Label Request/Label Mapping для явного указания того, что LSP является E-LSP, а его таблицей соответствия служит EXP<-->PHB). Согласованное соответствие будет указывать на субнабор 8 (или менее) BA, транспортируемых по каждому E-LSP, и на величины EXP, которые согласованы для каждого BA в каждом E-LSP.
Приложение B. Примеры сценариев резервирования полосы пропускания
ATM-коммутаторы в качестве LSR
Процедуры переадресации MPLS подобны тем, что используются в ATM-коммутаторах. ATM-коммутаторы используют входной порт и значение поля VPI/VCI входящего пакета в качестве индекса в таблице коммутации (cross-connect), из которой они получают номер выходного порта и выходного значения VPI/VCI. Следовательно, если одна или более меток могут быть занесены непосредственно в поля заголовков, которые доступны коммутаторам, тогда коммутаторы после модификации программ смогут быть использованы в качестве LSR. Мы будем называть такие устройства "ATM-LSR". Имеется три способа представления меток в заголовках ячеек ATM (предпочтительно использовать AAL5):
1. SVC кодирование
Используется поле VPI/VCI для записи метки, размещенной на верху стека. Эта методика может использоваться в любой сети. Посредством этой методики LSP реализуется как ATM SVC, а протокол рассылки меток становится сигнальным протоколом ATM. ATM-LSR не может выполнять команды "push" или "pop" для стека меток.
2. SVP кодирование
Используется поле VPI для записи метки, размещенной на верху стека, а поле VCI для записи второй метки стека, если такая существует. Эта методика имеет некоторые преимущества по отношению к предыдущей, здесь возможно переключение виртуальных каналов с помощью ATM "VP-switching". То есть, LSP реализуются как ATM SVP.
Однако эта методика не может использоваться всегда. Если сеть включает виртуальный маршрут ATM через ATM-сеть, не поддерживающую MPLS, тогда поле VPI необязательно доступно для использования в MPLS.
Когда используется этот метод представления, ATM-LSR на выходе виртуального канала VP эффективно реализует операцию "pop".
3. Многоточечное кодирование SVP
Для размещения метки на вершине стека используется поле VPI, а для размещения второй метки стека, если таковая имеется, используется часть поля VCI, остальная часть поля VCI служит для идентификации входного LSP. Если применяется эта технология, традиционные возможности ATM VP-коммутации могут использоваться для построения виртуальных маршрутов мультиточка-точка. Ячейки от разных пакетов будут нести тогда разные значения VCI. Как это будет показано в разделе 2.26, это позволяет нам осуществлять объединение меток, не получая проблем перекрытия ячеек, для ATM-коммутаторов, реализующих виртуальные маршруты мультиточка-точка, но которые не имеют возможностей объединения VC.
Эта методика зависит от наличия возможности присвоения 16-битовых значений VCI каждому ATM-коммутатору, так что ни одно значение VCI не будет соответствовать двум разным коммутаторам.
Если имеется больше меток в стеке, чем места в заголовке ATM, тогда ATM представление должно комбинироваться с общей инкапсуляцией.
Атрибут defaultСпецификация политики по умолчанию
Политика маршрутизации по умолчанию специфицируется с помощью атрибута default. Атрибут default имеет следующий синтаксис:
default: to <peering> [action <action>] [networks <filter>]
Спецификации <action> и <filter> являются опционными. Семантика выглядит следующим образом: Спецификация <peering> указывает на AS (и маршрутизатор, если он имеется) по умолчанию; спецификация <action>, если присутствует, указывает на различные атрибуты конфигурации по умолчанию. Например, относительное предпочтение, если определено несколько маршрутов по умолчанию; а спецификация <filter>, если имеется, является фильтром политики. Маршрутизатор использует политику по умолчанию, если он получает от партнера маршруты, которые удовлетворяют требованиям фильтра <filter>.
В следующем примере, AS1 маршрутизируется по умолчанию через AS2.
aut-num: AS1
default: to AS2
В следующем примере, марштутизатор 1.1.1.1 в AS1 маршрутизуется по умолчанию через 1.1.1.2 в AS2.
aut-num: AS1
default: to AS2 1.1.1.2 at 1.1.1.1
В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и AS3, но предпочитает AS2, а не AS3.
aut-num: AS1
default: to AS2 action pref = 1;
default: to AS3 action pref = 2;
В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и использует 128.9.0.0/16 в качестве сети по умолчанию.
aut-num: AS1
default: to AS2 networks { 128.9.0.0/16 }
Атрибут export: Спецификация экспортной политики
Аналогично выражение экспортной политики специфицируется с помощью атрибута export. Атрибут export имеет следующий синтаксис:
| export: | to <peering-1> [action <action-1>] |
| . . . | |
| to <peering-N> [action <action-N>] | |
| announce <filter> |
Спецификация действия является опционной. Семантика атрибута export выглядит следующим образом: набор маршрутов, который соответствует <filter> пересылается всем партнерам, специфицированным в <peerings>, в то время как экспортируемые маршруты из <peering-M>, <action-M> реализуются.
Например
aut-num: AS1
export: to AS2 action med = 5; community .= { 70 }; announce AS4
В этом примере, маршруты AS4 объявляются автономной системе AS2 со значением атрибута med, равным 5 и атрибута community = 70.
Пример:
aut-num: AS1
export: to AS-FOO announce ANY
В этом примере, AS1 объявляет все свои маршруты автономным системам AS из набора AS-FOO.
Атрибут import: Спецификация политики импорта
В RPSL политика импорта определяется двумя выражениями импортной политики. Каждое выражение импортной политики специфицируется с помощью атрибута import. Атрибут import имеет следующий синтаксис:
| import: | from <peering-1> [action <action-1>] . . . |
| from <peering-N> [action <action-N>] | |
| accept <filter> |
Спецификация действия является опционной. Семантика атрибута import выглядит следующим образом: набор маршрутов, который соответствует <filter> импортируется от всех партнеров в <peerings>, в то время как импортируемые маршруты <peering-M>, <>ction-M> реализуются.
Например
aut-num: AS1
import: from AS2 action pref = 1; accept { 128.9.0.0/16 }
Этот пример утверждает, что маршрут 128.9.0.0/16 воспринят от AS2 с предпочтением 1. Далее рассматривается спецификация действий (action).
Атрибуты ассоциации меток (Label Binding)
Конкретная ассоциация метки L и класса FEC F, анонсируемая Rd для Ru, может иметь соответствующие атрибуты. Если Ru работает как нижестоящий LSR, и анонсирует ассоциацию метки и класса FEC F, тогда при определенных обстоятельствах, может оказаться нужно разослать соответствующий атрибут, полученный от Rd.
Аутентичность и целостность сообщений LDP
В этом разделе специфицируется механизм защиты от введения фальсифицированных TCP-сегментов в потоки соединений LDP-сессии. Использование этого механизма должно поддерживаться как конфигурируемая опция.
Механизм базируется на применении опции подписи TCP MD5, описанной в [RFC2385] для BGP. Смотри описание хэш-функций MD5 в [RFC1321].
B.Сценарий отсутствие резервирования полосы пропускания
Рассмотрим случай, когда сетевой администратор решил:
иметь Diff-Serv ресурсы, полностью обеспечиваемые в режиме off-line (например, через интерфейс командной строки, посредством SNMP, COPS,...)
иметь маршрутизацию Shortest Path, используемую для всех видов трафика Diff-Serv.
Это наиболее приемлемая модель обеспечения Diff-Serv через сеть без поддержки MPLS IP. В этом случае, E-LSP и/или L-LSP будут устанавливаться без согласованной полосы пропускания.
B.Сценарий Резервирование полосы
Рассмотрим случай, когда сетевой администратор решил: использовать L-LSP; иметь маршрутизацию, базирующуюся на ограничениях (Constraint Based Routing), реализуемую для каждого PSC отдельно, где одним из ограничения является доступность полосы из ресурса, выделенного соответствующему PSC. иметь динамически адаптируемые ресурсы Diff-Serv.
В этом случае L-LSP будут формироваться с согласованной полосой пропускания. Полоса пропускания, согласованная при формировании L-LSP, будет использоваться LSR при настройке ресурсов для соответствующих PSC (например, веса трафика) и далее для управления, чтобы гарантировать обеспечения ограничений на полосу пропускания для PSC.
Ссылки
| [ANSI/IEEE] | ANSI/IEEE Std 802.1D, 1993 Edition, incorporating IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998 и P802.12e) |
| [ATMF_TM] | ATM Forum, "Traffic Management Specification Version 4.1", March 1999. |
| [CR-LDP_MPLS_TE] | Jamoussi, B., Editor, Andersson, L., Callon, R. и R. Dantu, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. |
| [DCLASS] | Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000. |
| [DIFF_AF] | Heinanen, J., Baker, F., Weiss, W. и J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. |
| [DIFF_ARCH] | Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. и W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. |
| [DIFF_EF] | Davie, B., Charny, A., Baker, F., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. и D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. |
| [DIFF_HEADER] | Nichols, K., Blake, S., Baker, F. и D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 и IPv6 Headers", RFC 2474, December 1998. |
| [DIFF_NEW] | Grossman, D., "New Terminology и Clarifications for Diffserv", RFC 3260, April 2002. |
| [DIFF_TUNNEL] | Black, D., "Differentiated Services и Tunnels", RFC 2983, October 2000. |
| [ECN] | Ramakrishnan, K., Floyd, S. и D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. |
| [IANA] | Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. |
| [IEEE_802.1] | ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision и redesignation of ISO/IEC 10038:98. |
| [LDP] | Andersson, L., Doolan, D., Feldman, N., Fredette, A. и B. Thomas, "LDP Specification", RFC 3036, January 2001. |
| [MPLS_ARCH] | Rosen, E., Viswanathan, A. и R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. |
| [MPLS_ATM] | Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y. и P. Doolan, "MPLS using LDP и ATM VC Switching", RFC 3035, January 2001. |
| [MPLS_ENCAPS] | Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. и A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. |
| [MPLS_FR] | Conta, A., Doolan, P. и A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001. |
| [MPLS_VPN] | Rosen, E., "BGP/MPLS VPNs", Work in Progress. |
| [NULL] | Bernet, Y., Smith, A. и B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000. |
| [PHBID] | Black, D., Brim, S., Carpenter, B. и F. Le Faucheur, "Per Hop Behavior Identification Codes" RFC 3140, June 2001. |
| [RSVP] | Braden, R., Zhang, L., Berson, S., Herzog, S. и S. Jamin, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional pecification", RFC 2205, September 1997. |
| [RSVP_MPLS_TE] | Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. и G. Swallow, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. |
B.Сценарий Резервирование полосы пропускания для управления доступом для каждого PSC
Рассмотрим случай, когда сетевой администратор решил:
иметь ресурсы Diff-Serv, полностью обеспечиваемые в режиме off-line (например, через интерфейс командной строки, посредством SNMP, COPS, и пр.);
использовать L-LSP;
иметь маршрутизацию на базе ограничений, реализуемую отдельно для каждого PSC, где одним из ограничений является доступность полосы пропускания, выделенной соответствующему PSC.
В этом случае L-LSP будут формироваться с согласованной полосой пропускания. Полоса, согласованная на фазе формирования L-LSP, будет использоваться LSR для реализации управления доступом на каждом шаге, чтобы гарантировать доступность требуемой полосы соответствующего PSC.
Базовая модель
Рис. .1. Схема взаимодействия различных частей COPS.
На рисунке .1 показано взаимодействие различных компонентов политики (взято из [WRK]). Здесь, COPS используется для обмена описаниями политики между узлами реализации политики PEP (Policy Enforcement Point) и удаленными пунктами принятия политических решений PDP (Policy Decision Point) в пределах контекста конкретного типа клиента. Может использоваться опционный пункт принятия локального политического решения LPDP (Local Policy Decision Point) в отсутствии PDP.
Предполагается, что каждый конкретный клиент политики функционально совместим с PEP [WRK]. PEP может обмениваться информацией с сервером политики.
PEP ответственен за инициализацию постоянного TCP-соединения с PDP. Узел PEP использует это соединение для посылки запросов и получения откликов-решений от удаленного PDP. Коммуникация между PEP и удаленным PDP происходит в основном в форме обменов запрос-решение, хотя удаленный PDP может по своей инициативе послать PEP и не запрошенное решение, чтобы вызвать изменение одобренных ранее состояний запросов. PEP имеет также возможность сообщать удаленному >PDP, что решение PDP успешно исполнено локально. Узел PEP ответственен за уведомление PDP об изменении состояния запроса в PEP. Наконец, в функции PEP входит аннулирование любого состояния, которое не может быть использовано из-за событий, имевших место у клиента, или в силу решений, принятых сервером.
После этого PEP посылает конфигурационный запрос, и ожидает присылки от PDP именованных блоков конфигурационных данных (в виде сообщений-решений). Когда именованные конфигурационные данные успешно доставлены PEP, он должен послать PDP сообщение-отчет, подтверждающее получение конфигурационных данных. Сервер с помощью сообщения-решения может после этого обновить или удалить конфигурационную информацию. Когда PDP посылает решение об удалении именованной конфигурационной информации на PEP, PEP стирает специфицированные данные и посылает PDP в качестве подтверждения сообщение-отчет.
Протокол политики предполагает коммуникацию с само идентифицируемыми объектами, которые содержат данные, необходимые для идентификации состояний запроса, устанавливающие контекст запроса, его тип, содержащие ссылки на поступившие ранее запросы, принятые политические решения, поступившие сообщения об ошибках и прочие данные специфичные для клиента.
Чтобы идентифицировать разные виды клиентов, в каждом сообщении приводится тип клиента. Разные типы клиентов могут иметь различные специфические данные и могут требовать различных политических решений. Ожидается, что каждый новый тип клиента имеет соответствующее описание, характеризующее специфику его взаимодействия с данным протоколом описания политики.
Контекст каждого запроса соответствует типу события, его вызвавшего. Объект контекста COPS идентифицирует тип запроса и сообщения, которые вызвали данное политическое событие, посредством своих полей типа сообщения и запроса. COPS идентифицирует три типа событий: (1) приход сообщения (2) выделение локальных ресурсов, и (3) переадресацию исходящего сообщения. Каждое из этих сообщений может потребовать различных решений. Содержимое сообщений COPS-запросов/решений зависит от контекста. Четвертый тип запроса полезен для типов клиентов, которые хотят получить конфигурационную информацию от PDP. Это позволяет PEP послать конфигурационный запрос специфическому именованному устройству или модулю, который требует инсталляции конфигурационной информации. PEP может также иметь возможность принимать локальные политические решения с помощью LPDP (Local Policy Decision Point) [WRK], однако, PDP всегда остается точкой принятия решений. Это означает, что соответствующая информация о локальных решениях должна передаваться PDP. То есть, PDP должен быть предоставлен доступ к информации, чтобы принять окончательное политическое решение. Чтобы обеспечить такую возможность, PEP должен послать информацию о локальном решении удаленному PDP посредством объекта решения LPDP. PEP должен затем следовать решению PDP, так как оно является окончательным.
Наконец, допустимость ошибки (fault tolerance) является обязательной особенностью данного протокола, в частности из-за того, что он ассоциируется с управлением услугами и безопасностью в распределенных сетях. Допустимость ошибки может быть достигнута за счет того, что PEP и удаленный PDP постоянно проверяют свое соединение путем посылки тестовых сообщений keep-alive ("еще жив?"). Когда обнаружен отказ, PEP должен попытаться восстановить контакт с удаленным PDP или соединиться с альтернативным (backup) PDP. Пока PEP не имеет связи, он должен ограничиться принятием локальных решений. Как только соединение восстановлено, PEP должен уведомить PDP о любом ликвидированном состоянии или о событиях, которые произошли с момента потери соединения. Кроме того, удаленный PDP может потребовать, чтобы все внутренние состояния PEP были заново синхронизованы (все ранее поступившие запросы должны быть продублированы). После отказа и до того как новое соединение будет восстановлено в полном объеме, ущерб в обслуживании может быть минимизирован, если PEP кэширует переданные ранее решения и продолжает их использовать в течение некоторого ограниченного времени. В разделах 2.3 и 2.5 детально рассмотрены механизмы COPS для обеспечения надежности.
Базовые моменты при посылке почтовых сообщений
Почта в Интернет не совершенная однородная система. Почта может оказаться поврежденной на нескольких этапах ее транспортировки к месту назначения. Почтовое сообщение может проходить через участки среды, использующие различные сетевые технологии. Многие сетевые и почтовые технологии не поддерживают полную функциональность, возможную в рамках протокола SMTP. Почтовое сообщение, проходя через эти среды, может быть модифицировано, для того чтобы решить проблему его передачи адресату.
В сети Интернет имеется большое число почтовых агентов, которые в процессе реализации протокола SMTP, модифицируют сообщения на пролете. Следующие соображения могут оказаться полезными любому, кто разрабатывает формат данных (тип среды), который бы сохранялся неповрежденным в любых сетевых средах и для любых почтовых агентов. Заметим, что данные, закодированные в base64, удовлетворяют этим требованиям, а некоторые хорошо известные механизмы, в частности утилита UNIX uuencode, не удовлетворяет. Заметим также, что данные, закодированные с использованием закавыченных последовательностей печатных символов, успешно преодолевают большинство почтовых шлюзов, но могут быть повреждены в системах, которые используют символьный набор EBCDIC.
| 1) |
При некоторых обстоятельствах кодирование, использованное для данных, может изменить работу почтового шлюза или агента пользователя. В частности, может потребоваться преобразование из base64 в закавыченную печатную форму и обратно. Это может вызвать искажения для последовательностей CRLF, определяющих границы строк в тексте.
"'" (US-ASCII десятичное значение 39)
"(" (US-ASCII десятичное значение 40)
")" (US-ASCII десятичное значение 41)
"+" (US-ASCII десятичное значение 43)
"," (US-ASCII десятичное значение 44)
"-" (US-ASCII десятичное значение 45)
"." (US-ASCII десятичное значение 46)
"/" (US-ASCII десятичное значение 47)
":" (US-ASCII десятичное значение 58)
"=" (US-ASCII десятичное значение 61)
"?" (US-ASCII десятичное значение 63)
Максимально переносимое почтовое сообщение имеет короткие строки, содержащие только эти 73 с имвола. Кодирование base64 отвечает этому правилу.
Заметим, что приведенный выше список не является рекомендацией для почтовых транспортных агентов. В документе RFC-821 не запрещается заменять символы или разрывать длинные строки. Более того, данный список отражает негативную практику для существующих сетей и программные реализации должны быть устойчивы против таких эффектов, с которыми им придется столкнуться.
Базовый механизма выявления
Чтобы запустить базовый механизм выявления в LDP для заданного интерфейса LSR периодически посылает в канал LDP сообщения. Канальные сообщения Hello посылаются в виде UDP-пакетов, адресованных в стандартный порт выявления партнеров LDP, "всем маршрутизаторам субсети" методом мультикастинг-адресации.
Канальное сообщение LDP Hello, посланное LSR, содержит в себе идентификатор LDP для пространства меток, которое LSR намерен использовать для интерфейса, а также дополнительную информацию.
Отклик на канальное сообщение LDP Hello идентифицирует сопредельность (adjacency) с потенциальным LDP партнером, достижимым на канальном уровне интерфейса, а также пространство меток, которое партнер намерен использовать для данного интерфейса.
BGP и LDP
Во многих сценариях, желательно установить связь между метками и FEC, который может быть сопряжен с маршрутами и адресными префиксами (смотри раздел 3.1).
Протокол BGP рассылает маршруты, и, если BGP-отправителю нужно разослать метки своим BGP-партнерам, использование BGP для целей распределения меток (смотри [MPLS-BGP]) имеет ряд преимуществ. В частности, это позволяет BGP рефлекторам маршрутов рассылать метки, таким образом обеспечивая существенную масштабируемость по сравнению с использованием LDP для пересылки меток между BGP партнерами.
Библиография
E. Crawley, R. Nair, B. Rajagopalan, H. Sandick. RFC-2386. A Framework for QoS-based Routing in the Internet. August 1998.
R. Braden, RFC-1633. Integrated Services in the Internet Architecture: an Overview. June 1994.
E. Rosen, Y. Rekhter, RFC-2547. BGP/MPLS VPNs. March 1999.
J. Malcolm, RFC-2702, Requirements for Traffic Engineering Over MPLS. September 1999.
A. Malis, RFC-2917, A Core MPLS IP VPN Architecture, September 2000.
E. Rosen. RFC-3031, Multiprotocol Label Switching Architecture, January 2001
D. Tappan, RFC-3032, MPLS Label Stack Encoding, January 2001.
J. Lawrence, RFC-3035, MPLS using LDP and ATM VC Switching, January 2001.
Y. Katsube, RFC-3063, MPLS Loop Prevention Mechanism, February 2001.
B.Олифер, Н. Олифер, Искусство оптимизации трафика. Журнал сетевых решений LAN, декабрь 2001, стр. 38-47.
В.Олифер, Н. Олифер, Виртуальные частные сети на основе MPLS. Журнал сетевых решений LAN, январь 2002, стр. 58-63.
Д.Гринфильд, Глобальная служба MPLS: опережая время. Журнал сетевых решений LAN, март 2002, стр. 32-38.
В.Олифер, Н. Олифер, MPLS на службе VPN. Журнал сетевых решений LAN, март 2002, стр. 40-47.
L. Wu, RFC-3270, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services, May 2002.
Jim Guichard, Ivan Pepelnjak. MPLS and VPN Architectures. A Practical Guide to Understanding, Designing and Deploying MPLS and MPLS-Enabled VPNs. Cisco Press, 2000.
Sean Harnedy. The MPLS Primer. An Introduction to Multiprotocol Label Switching, Prentice Hall, 2001.
Eric W. Gray, MPLS. Implementing the Technology. With CD-ROM, Addison Wesley, 2001.
Li, T. and Y. Rekhter, RFC-2430, Provider Architecture for Differentiated Services and Traffic Engineering (PASTE). October 1998.
J. Wroclawski. RFC-2210, The Use of RSVP with IETF Integrated Services. September 1997.
L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin «Resource ReSerVation Protocol», RFC-2205. September 1997.
Bates, Y. Rekhter, R., Chandra, D. Katz. Multiprotocol Extensions for BGP-4. RFC-2858. June 2000.
J. Wroclawski. RFC-2211. Specification of the Controlled- Load Network Element Service. September 1997.
S. Shenker. RFC-2212. Specification of Guaranteed Quality of Service. September 1997.
D. Durham, Ed. RFC-2748. The COPS (Common Open Policy Service) Protocol. January 2000.
Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-Based Admission Control", RFC-2753, January 2000.
L. Berger. RFC-2379. RSVP over ATM Implementation Guidelines. August 1998.
L. Berger. RFC-2380. RSVP over ATM Implementation Requirements. August 1998.
E. Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk. RFC-2382. A Framework for Integrated Services and RSVP over ATM. August 1998.
S. Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry. RFC-2749 COPS usage for RSVP. January 2000.
S. Herzog. RFC-2750. RSVP Extensions for Policy Control. January 2000.
R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer. RFC-2814. SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks. May 2000.
F. Baker, C. Iturralde, F. Le Faucheur, B. Davie. RFC-3175. Aggregation of RSVP for IPv4 and IPv6 Reservations. September 2001.
D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. RFC-3209. RSVP-TE: Extensions to RSVP for LSP Tunnels. December 2001.
A. Smith, D. Partain, J. Seligson. RFC-2940. Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients. October 2000.
K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith. RFC-3084. COPS Usage for Policy Provisioning (COPS-PR). March 2001.
Максим Кульгин. Контроль трафика в сетях ATM. LAN/Журнал Сетевых решений #12/98
Алексей Лукацкий. Неизвестная VPN.
(управление трафиком - ТЕ)
Мультипротокольная коммутация по меткам (MPLS).
(“ТрансТелеКом”, обзоры на русском)
(Оффициальная страница группы разработчиков MPLS).
IP-Datentransport ist nur der Anfang. Wilhelm Greiner, LANline 10/2002, стр. 110-115;
MPLS als Hoffnungstraeger. Gerhard Kafka, LANline 10/2002, стр. 122-125.
Keine Zeit fuer Auszeigen. Markus Heis, LANline 10/2002, стр. 126-129;
Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment; RFC-3353, D. Ooms, August 2002.
Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks; RFC-3443, P. Agarwal, January 2003.
Framework for Multi-Protocol Label Switching (MPLS)-based Recovery; RFC-3469, V. Sharma, February 2003.
Generalized Multi-Protocol Label Switching (GMPLS)Signaling Functional Description; RFC-3471, L. Berger, January 2003.
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions; RFC-3472, P. Ashwood-Smith, January 2003.
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions; RFC-3473, L. Berger, January 2003.
Graceful Restart Mechanism for Label Distribution Protocol; RFC-3478, M. Leelanivas, February 2003.
Fault Tolerance for the Label Distribution Protocol (LDP); RFC-3479, A. Farrel, February 2003.
Шринивас Вегешна, "Качество обслуживания в сетях IP", Cisco Press, 2003.
Definition of the Differentiated Services Field (DS Field)in the IPv4 and IPv6 Headers; RFC-2474, K. Nichols, December 1998.
Assured Forwarding PHB Group; RFC-2597,, J. Heinanen, June 1999.
Multiprotocol Label Switching (MPLS)
Jim Guichard, Ivan Pepelnjak, "MPLS and VPN Architectures", Cisco Press, 2001
Цели
Ниже предлагается список основных задач DHCP.
| o | DHCP представляет собой механизм, а не политику. DHCP должен управляться местными системными администраторами, путем задания желательных конфигурационных параметров. |
| o | Клиенты не должны требовать ручной конфигурации. Каждый клиент должен быть способен прочесть локальные конфигурационные параметры. |
| o | Сети не должны требовать ручной конфигурации для отдельных клиентов. В нормальных условиях, сетевой администратор не должен вводить какие-либо индивидуальные конфигурационные параметры клиента. |
| o | DHCP не требует отдельного сервера для каждой субсети. |
| o | Клиент DHCP должен быть готов получить несколько откликов на запрос конфигурационных параметров. Для повышения надежности и быстродействия можно использовать несколько DHCP-серверов, обслуживающих перекрывающиеся области сети. |
| o | DHCP должен сосуществовать с ЭВМ, которые сконфигурированы вручную. |
| o | DHCP должен быть совместим с логикой работы BOOTP-агента, описанной в RFC-951 и RFC-1542 [21]. |
| o | DHCP должен обслуживать существующих клиентов BOOTP. |
DHCP должен:
| o | Гарантировать, что любой специфический сетевой адрес не будет использоваться более чем одним клиентом DHCP одновременно. |
| o | Поддерживать DHCP конфигурацию клиента при стартовой перезагрузке DHCP-клиента. Клиенту DHCP должен, при каждом запросе по мере возможности, присваиваться один и тот же набор конфигурационных параметров (например, сетевой адрес). |
| o | Поддерживать конфигурацию DHCP-клиента при перезагрузке сервера, и, по мере возможности, DHCP-клиенту должен присваиваться один и тот же набор конфигурационных параметров. |
| o | Позволяет автоматически присваивать конфигурационные параметры новым клиентам, чтобы избежать ручной конфигурации. |
| o | Поддерживать фиксированное или постоянное присвоение конфигурационных параметров для заданного клиента. |
Частные расширения LDP производителя
Частные сообщения и TLV производителя используются для обмена между LSR частной информацией производителя.
Частные сообщения LDP производителя
Код типа в диапазоне 0x3E00 - 0x3EFF зарезервирован для частных сообщений производителя.
U бит
Бит неизвестного сообщения. При подтверждении неизвестного сообщения, если U=0, отправителю сообщения возвращается уведомление; если U=1, неизвестное сообщение молча игнорируется.
Определение того, будет ли воспринято частное сообщение производителя, базируется на типе сообщения и параметре ID производителя.
Тип сообщения
Код типа сообщения лежит в диапазоне 0x3E00 - 0x3EFF. Вместе с типом сообщения и ID производителя специфицирует то, как будет интерпретироваться сообщение.
Длина сообщения
Специфицирует суммарную длину в октетах полей ID сообщения, ID производителя, остальных обязательных параметров и опционных параметров.
ID сообщения
32-битовый код, используемый для идентификации этого сообщения. Используется LSR-отправителем, чтобы упростить идентификацию уведомлений, которые могут относиться к этому сообщению. LSR, посылающий уведомление, в качестве отклика на это сообщение, будет включать этот Id в сообщение уведомления; смотри раздел "Сообщение уведомления".
ID производителя
ID производителя 802, как это предписано IEEE.
Остальные обязательные параметры
Набор переменной длины остальных обязательных параметров.
Опционные параметры
Набор переменной длины опционных параметров сообщения.
Частные TLV LDP производителя
Диапазон кодов типа 0x3E00 - 0x3EFF зарезервирован для частных TLV производителя. Формат частных TLV производителя представлен ниже:
U бит
Бит неизвестного TLV. При получении неизвестного TLV, если U=0, отправителю сообщения должно быть прислано уведомление, а само сообщение проигнорировано; если U=1, неизвестное TLV молча игнорируется, а остальная часть сообщения обрабатывается так, как если бы неизвестного TLV не существовало.
Определение того, понятно ли частное сообщение производителя, зависит от типа и обязательного поля ID производителя.
F бит
Бит переадресации неизвестного TLV. Этот бит используется, только когда U=1, а сообщение LDP, содержащее неизвестное TLV, должно быть переадресовано. Если F=0, неизвестное TLV не переадресуется вместе с содержащим его сообщением; если F=1, неизвестное TLV переадресуется вместе с содержащим его сообщением.
Тип
Значение тип лежит в диапазоне 0x3E00 - 0x3EFF. Вместе с типом и Id производителя поле специфицирует, как следует интерпретировать поле данных.
Длина
Специфицирует суммарную длину в октетах идентификатора производителя и поля данных.
Id производителя
ID производителя 802, как это предписано IEEE.
Данные
Остальные октеты после ID производителя в поле значение являются опционными данными, зависящими от производителя.
Client-Accept (CAT) PDP -> PEP
Сообщение Client-Accept используется для позитивного отклика на сообщение Client-Open. Это сообщение пришлет PEP объект таймера, заключающий в себе максимальный временной интервал между сообщениями keep-alive. Опционно, если нужно, может быть добавлен таймер, специфицирующий минимально допустимый интервал между аккоунтинг-сообщениями-отчетами.
<Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<Integrity>]
Если PDP отказывает клиенту, он пошлет сообщение Client-Close.
Таймер KA соответствует максимальному приемлемому времени между сообщениями, посылаемыми от PDP к PEP. Время выдержки таймера определяется PDP и измеряется в секундах. Значение времени выдержки 0 означает, что не требуется верификации вторичного соединения.
Опционный таймер ACCT позволяет PDP проинформировать PEP о том, что периодические аккоунтинг-отчеты не должны превышать специфицированный временной интервал для каждого дескриптора клиента. Это позволяет PDP контролировать частоту, с которой PEP посылает аккоунтинг-отчеты. Вообще, сообщения Report типа аккоунтинг посылаются PDP, когда определен соответствующий PEP. Аккоунтинг-таймер по большей части используется PDP, чтобы поддерживать частоту актуализаций на приемлемом уровне (т.e. предотвращать перегрузку PEP под действием аккоунтинг-отчетов от PDP). Не включение этого объекта в сообщение означает, что не существует для PDP каких-либо ограничений на частоту аккоунтинг-актуализации.
Если PEP получает сообщение Client-Accept с неверным форматом, он должен сгенерировать сообщение Client-Close, где специфицирован соответствующий код ошибки.
Client-Close (CC) PEP -> PDP, PDP -> PEP
Сообщение Client-Close может быть послано как PDP, так и PEP с тем, чтобы обратить внимание противоположной стороны на то, что указанный тип клиента более не поддерживается.
<Client-Close> ::= <Common Header>
<Error>
[<PDPRedirAddr>]
[<Integrity>]
Объект Error включен, чтобы описать причину закрытия (например, запрошенный тип клиента не поддерживается удаленным PDP или отказ в работе клиента).
PDP может опционно включать PDP-объект адреса перенаправления, для того чтобы проинформировать PEP об альтернативном PDP, который он должен использовать для типа клиента, специфицированного в общем заголовке.
Client-Open (OPN) PEP -> PDP
Сообщение Client-Open может использоваться PEP, для того чтобы специфицировать PDP типы клиента, которые PEP может поддерживать, и последний PDP, с которым PEP устанавливал соединение при данном типе клиента. Сообщение Client-Open может быть послано PDP в любое время, допускаются множественные сообщения Client-Open для одного и того же типа клиента (в случае общих изменений состояния).
<Client-Open> ::= <Common Header>
<PEPID>
[<ClientSI>]
[<LastPDPAddr>]
[<Integrity>]
PEPID является символическим именем с переменной длиной, которое однозначно идентифицирует клиента для PDP (смотри раздел 2.2.11).
Именованный объект ClientSI может быть включен для передачи дополнительной глобальной информации о PEP к PDP, когда необходимо (как это специфицировано в соответствующем расширении документа для заданного типа клиента).
PEP может также предоставить объект Last PDP Address в его сообщении Client-Open, специфицирующий последний PDP (для заданного типа клиента), для которого он кэширует решения с момента последней перезагрузки (reboot). PDP может использовать эту информацию, чтобы определить подходящий режим синхронизации (смотри раздел 2.5).
Если PDP получает сообщение Client-Open с неверным форматом, он должен сформировать сообщение Client-Close, специфицирующее соответствующий код ошибки.
Деревья LSP как объекты мультиточка-точка
Рассмотрим случай, когда пакеты P1 и P2 имеют адреса места назначения в префиксе Х. Предположим, что маршрут шаг-за-шагом для P1 представляет собой <R1, R2, R3>, а путем шаг-за-шагом для P2 является <R4, R2, R3>. Давайте предположим, что R3 связывает метку L3 с X, и отсылает эту ассоциацию R2. R2 связывает метку L2 с X, и посылает эту ассоциацию в R1 и R4. Когда R2 получает пакет P1, его входная метка будет также L2. R2 заменит L2 на L3, и пошлет P1 в R3. Когда R2 получает пакет P2, его входная метка будет также L2. R2 снова заменит L2 на L3, и пошлет P2 в R3.
Заметим далее, что когда P1 и P2 двигаются от R2 к R3, они несут одну и ту же метку, и с точки зрения MPLS, они не различимы. Таким образом, вместо того чтобы говорить о двух разных LSP, <R1, R2, R3> и <R4, R2, R3>, мы можем говорить об одном дереве LSP мультиточка-точка (Multipoint-to-Point LSP Tree), которое мы можем обозначить как <{ R1, R4}, R2, R3>.
Это создает трудности, когда мы пытаемся использовать обычные ATM-коммутаторы в качестве LSR. Так как обычные ATM-коммутаторы не поддерживают соединения мультиточка-точка, должны существовать процедуры, гарантирующие, чтобы каждый LSP реализовал VC по схеме точка-точка. Однако если используются ATM-коммутаторы, которые поддерживают VC мультиточка-точка, тогда LSP может быть реализован эффективно по такой схеме. Альтернативой может служить ситуация, когда можно использовать многоточечное представление SVP (раздел 2.25.2), LSP может быть реализован как SVP мультиточка-точка.
Деревья с общим отправителем
Мультикастные IP протоколы маршрутизации формируют либо деревья отправителя (S,G), т.е. по дереву для каждого отправителя (S) и для группы (G), или деревья с совмещением (*, G), т.е. одно дерево для каждой мультикаст-группы (Рис. 1).
Рис. 1. Дерево с совмещением и деревья отправителя
Преимуществом использования деревьев с совмещением, в случае применения переключения по меткам, является то, что деревья с совмещением требуют меньше меток, чем деревья отправителя (1 метка на группу против одной метки на отправителя и на группу). Однако проецирование деревьев с совмещением на уровень L2 подразумевает формирование LSP мультиточка-мультиточка (mp2mp).
Заметим, что на практике деревья с совмещением часто используются только для выявления новых отправителей групп, а переключение на дерево отправителя производится при низких потоках данных.
Детектирование петель
Детектирование петель является конфигурируемой опцией, которая предоставляет механизм нахождения циклических сегментов LSP и для предотвращения зацикливания сообщений запроса метки.
Механизм использует TLV вектора пути и числа шагов, содержащиеся в сообщениях запроса и присвоения метки. Он строится на следующих базовых свойствах этих TLV:
TLV вектора пути содержит список LSR, через которые проходит сообщение, его содержащее. LSR идентифицируется в списке вектора с помощью уникальных Id LSR, которые являются первыми четырьмя октетами идентификатора его LDP. Когда LSR передает сообщение, содержащее TLV вектора пути, он добавляет в список вектора пути свой идентификатор (Id LSR). LSR, который получает сообщение с вектором пути, содержащим его Id, регистрирует, что сообщение прошло по замкнутому пути (по петле). LDP поддерживает понятие максимально допустимой длины вектора пути. LSR, который детектирует, что вектор пути достиг максимальной длины, поступает также как в случае регистрации петлевого маршрута.
TLV числа шагов содержит число LSR, которые сообщение, содержащее его, прошло. Когда LSR пересылает сообщение, содержащее TLV числа шагов, он увеличивает это число на 1. LSR, который регистрирует, что число шагов достигло заданного при конфигурации максимума, ведет себя так, как если бы была зарегистрирована петля. Согласно договоренности число 0 интерпретируется, как неизвестное число шагов. Инкрементирование такого значения сохраняет его величину (unknown =0).
Заметим, что TLV числа шагов и его процедуры используются без TLV вектора пути в ситуации, когда детектирование петель не предусмотрено на уровне конфигурации (смотри [RFC3035] и [RFC3034]).
Diff-Serv TLV
Diff-Serv TLV имеет следующие форматы:
Diff-Serv TLV для E-LSP:
Рис. 11.
T :1 бит
Тип LSP. Устанавливается равным 0 для E-LSP
Зарезервировано: 27 бит
Это поле зарезервировано на будущее. Оно должно быть установлено равным нулю при передаче, и должно игнорироваться при приеме.
MAPnb: 4 бита
Индицирует число записей MAP, включенных в объект DIFFSERV. Оно может быть установлено равным любому числу от 1 до 8.
MAP: 32 бита
Каждая запись MAP определяет соответствие между одним значением поля EXP и одним PHB. Запись MAP имеет формат, показанный на рис. 9.
Diff-Serv TLV для L-LSP:
Рис. 12.
T :1 бит
Тип LSP. Устанавливается равным 1 для L-LSP
Зарезервировано: 15 бит
Это поле зарезервировано на будущее. Оно должно быть установлено равным нулю при передаче, и должно игнорироваться при приеме.
PSC: 16 бит
PSC индицирует класс обслуживания PHB, который должен быть поддержан LSP. PSC кодируется так, как специфицировано в [PHBID].
Дискретные значения типа среды
Пять из семи базовых значений типа среды относятся к дискретным телам. Содержимое этих типов должно обрабатываться с использование механизмов за пределами MIME, они непрозрачны для MIME-процессоров.
4.1. Тип среды Text
Тип среды "text" предназначен для посылки материала, который имеет принципиально текстуальную форму. Параметр "charset" можно использовать для указания символьного набора тела субтипов "text", включая субтип "text/plain", который является общим субтипом для чистого текста. Чистый текст не содержит форматирующих команд, спецификаций атрибутов шрифтов, инструкций обработки, директив интерпретации или разметки. Чистый текст представляет собой последовательность символов, которая может содержать разрывы строк или страниц.
Помимо чистого текста существует много форматов, называемых "богатый" текст ("rich text"). Интересной характеристикой многих таких представлений является то, что они читабельны даже без программы, которая его интерпретирует. Полезно затем отличать их на верхнем уровне от таких нечитабельных данных как изображения, звук или текст, представленный в нечитаемом виде. В отсутствии подходящей интерпретирующей программы разумно показать субтипы "text" пользователю, в то время как это неразумно для большей части нетекстовых данных. Такие форматированные текстовые данные должны представляться с помощью субтипов "text".
4.1.1. Представление разрывов строк
Каноническая форма любого субтипа MIME "text" должна всегда оформлять разрыв строки с помощью последовательности CRLF. Аналогично, любое появление CRLF в тексте MIME должно означать разрыв строки. Использование CR и LF по отдельности вне обозначения разрыва строки запрещено. Это правило работает вне зависимости от используемого символьного набора.
Правильная интерпретация разрывов строк при отображении текста зависит от типа среды. Следует учитывать, что одно и то же оформление разрывов строк при отображении "text/plain" может восприниматься корректно, в то время как для других субтипов "text", например, "text/enriched" [RFC-1896] аналогичные разрывы строк будут восприниматься как неверные. Нет необходимости в добавлении каких-либо разрывов строк при отображении "text/plain", в то время как отображение "text/enriched" требует введения соответствующего оформления разрывов строк.
Некоторые протоколы определяют максимальную длину строки. Например, SMTP [RFC-821] допускает максимум 998 октетов перед последовательностью CRLF. Для того чтобы реализовать транспортировку посредством такого протокола, данные, содержащие слишком длинные сегменты без CRLF, должны быть закодированы с применением соответствующего content-transfer-encoding.
4.1.2. Параметр Charset
Критическим параметром, который может быть специфицирован в поле Content-Type для данных "text/plain", является символьный набор. Он специфицируется параметром "charset", например, как:
Content-type: text/plain; charset=iso-8859-1
В отличие от других значений параметров, значения параметра символьный набор не чувствительны к регистру, в котором написано его имя. Значением по умолчанию параметра символьный набор равно US-ASCII.
Для других субтипов "text", семантика параметра "charset" должна быть определена аналогично параметрам, заданным для "text/plain", т.e., тело состоит полностью из символов данного набора. В частности, авторы будущих определений субтипов "text" должны обратить особое внимание мультиоктетным символьным наборам. Параметр charset для субтипов "text" дает имя символьному набору, как это определено в RFC 2045.
Заметим, что специфицированный символьный набор включает в себя 8-битовые коды и эти символы используются в теле, поле заголовка Content-Transfer-Encoding и для передачи данных с помощью транспортных протоколов (например, SMTP) необходима соответствующая кодировка, такая как [RFC-821].
Значение символьного набора по умолчанию, равное US-ASCII, являлось причиной многих неурядиц в прошлом. Для того чтобы исключить какие-либо неопределенности в будущем, настоятельно рекомендуется новым агентам пользователя задавать символьный набор в явном виде в качестве параметра типа среды в поле заголовка Content-Type. "US-ASCII" не указывает на произвольный 7-битовый символьный набор, а говорит о том, что все октеты в теле должны интерпретироваться как символы US-ASCII. Национальные и ориентированные на приложения версии ISO 646 [ISO-646] обычно не идентичны US-ASCII, и их непосредственное применение в электронной почте может вызвать проблемы. Имя символьного набора "US-ASCII" относится к кодам, заданным в документе ANSI X3.4-1986 [US- ASCII].
Полный набор символов US-ASCII представлен в ANSI X3.4-1986. Заметим, что управляющие символы, включая DEL (0-31, 127) не имеют определенного значения, исключение составляет комбинация CRLF (US-ASCII значения 13 и 10) обозначающая разрыв строки. Два символа имеют широко используемые функции, это: FF (12) - продолжить последующий текст с начала новой страницы, и TAB или HT (9) часто (хотя и не всегда) означает "переместить курсор в следующую колонку. Колонки нумеруются, начиная с нуля и их позиции кратны 8. Помимо этих случаев любые управляющие символы или DEL в теле объекта могут появиться при следующих условиях.
| (1) |
Определены следующие значения charset:
| (1) | US-ASCII - как это определено в ANSI X3.4-1986 [US-ASCII]. |
| (2) |
Символы с кодами в диапазоне 128-159 не имеют стандартизованных значений в рамках ISO-8859-X. Символы с кодами меньше 128 в ISO-8859-X имеют те же значения, что и в US-ASCII.
Значения символьных наборов "ISO-8859-6" и "ISO-8859-8" специфицируют применение визуального метода [RFC-1556].
Все эти символьные наборы используются как чисто 7-битовые или 8-битовые без модификаций связанных или .
Никакие символьные наборы, отличные от определенных выше, не могут использоваться в электронной почте без публикации и формальной регистрации в IANA. Допустимы частные соглашения, в этом случае имя символьного набора должно начинаться с "X-".
Потребителям не рекомендуется определять новые символьные наборы, если это не диктуется крайней необходимостью. Параметр "charset" был первоначально определен для текстовых данных. Однако возможно его использование и для не текстовой информации, обычно это делается для синтаксической совместимости.
Если широко используемый символьный набор А является подмножеством другого символьного набора Б, а тело содержит только символы из набора А, он должен быть помечен как А.
4.1.3. Субтип Subtype
Простейшим и наиболее важным субтипом "text" является "plain". Он указывает, что текст не содержит форматирующих команд или директив. Чистый текст может отображаться непосредственно без какой-либо обработки. По умолчанию для электронной почты предполагается тип среды "text/plain; charset=us-ascii".
4.1.4. Не распознанные субтипы
Не распознанные субтипы "text" должны обрабатываться как чистый текст ("plain"), поскольку реализация MIME знает, как работать с данным символьным набором. Не распознанные субтипы, которые также специфицируют нераспознаваемый символьный набор, должны обрабатываться как "application/octet- stream".
4.2. Тип среды Image
Тип среды "image" указывает, что тело содержит изображение. Субтип называет имя специфического формата изображения. Эти имена не чувствительны к регистру. Исходным субтипом является "jpeg", который использует кодировку JFIF для формата JPEG [JPEG]. Не распознанные субтипы "image" должны обрабатываться как "application/octet-stream".
4.3. Тип среды Audio
Исходный субтип "basic" специфицирован, для того чтобы удовлетворить требованиям, которые соответствуют самому нижнему в иерархии аудио-форматов. Предполагается, что форматы для более высококачественного воспроизведения и/или низко полосной передачи будут определены позднее.
Содержимое субтипа "audio/basic" представляет собой моноканальное звуковое кодирование, использующее 8-битоый ISDN-стандарт с m-функцией преобразования [PCM] с частотой стробирования 8000 Hz. Не распознанные субтипы "audio" должны обрабатываться как "application/octet-stream".
4.4. Тип среды Type
Тип среды "video" указывает, что тело содержит движущееся изображение, возможно цветное и в сопровождении звука. Термин 'video' используется в самом общем значении, и не подразумевает какого-то конкретного формата. Субтип "mpeg" относится к видео закодированного согласно стандарту MPEG [MPEG]. Не распознанные субтипы "video" должны обрабатываться как "application/octet-stream".
4.5. Тип среды Application
Тип среды "application" следует использовать для дискретных данных, которые не могут быть отнесены ни к какой другой категории, в частности для данных, которые должны быть обработаны какой-то прикладной программой. Это информация, которая должна обрабатываться приложением до того как она станет доступной для просмотра пользователем. К предполагаемым применениям типа среды "application" относится файловый обмен, электронные таблицы, диспетчерские системы, базирующиеся на электронной почте.
Такие приложения могут быть определены как субтипы типа среды "application". В данном документе определены два субтипа:
octet-stream и PostScript.
4.5.1. Субтип Octet-Stream (поток октетов)
Субтип "octet-stream" используется для индикации того, что тело содержит произвольные двоичные данные. В настоящее время определены следующие параметры:
| (1) | TYPE - общий тип или категория двоичных данных. Это параметр предназначен для оператора-получателя, а не для программы обработки. |
| (2) | PADDING - число бит заполнителя, добавленного к потоку бит, представляющему действительное содержимое, для того чтобы получить байт-ориентированный поток. Используется, когда число бит в теле не кратно 8 |
4.5.2. Субтип PostScript
Тип среды "application/postscript" указывает на программу PostScript. В настоящее время допускается два варианта языка PostScript. Исходный вариант уровня 1 описан в [POSTSCRIPT], а более новый вариант уровня 2 рассмотрен в [POSTSCRIPT2].
Описания языка PostScript предоставляет возможности внутренней пометки специфических возможностей данного приложения. Эта пометка, называемая DSC (document structuring conventions) PostScript, предоставляет существенно больше информации, чем уровень языка. Использование DSC рекомендуется даже тогда, когда это непосредственно не требуется, так как обеспечивает более широкую совместимость. Документы, которые недостаточно структурированы, не могут быть проверены с целью выяснения того, могут ли они работать в данной среде.
Работа универсальных интерпретаторов PostScript представляет серьезную угрозу безопасности, разработчикам не рекомендуется просто посылать тела PostScript имеющимся ("off-the-shelf") интерпретаторам. В то время как посылка PostScript-файла на принтер обычно безопасна, программисты должны рассмотреть все возможные последствия, прежде чем ввести интерактивное отображение тел типа PostScript на их читающих средствах MIME.
Ниже перечислены возможные проблемы, связанные с транспортировкой объектов PostScript.
| (1) |
Заметим, что этот оператор может раскрыть информацию о том, к каким файлам имеет доступ пользователь, а эти данные могут облегчить задачу хакеру. Отправители сообщений должны избегать использования потенциально опасных файловых операторов, так как такие операторы, скорее всего, недоступны в PostScript приложениях, где приняты меры по обеспечению безопасности. Программное обеспечение, которое используется для приема и отображения, должно блокировать потенциально опасные файловые операторы или принять меры по ограничению их возможностей.
Ожидается, что в будущем будут определены многие другие субтипы "application". Реализации MIME должны уметь обрабатывать нераспознанные субтипы как "application/octet-stream".
Добавление субобъектов в объект Explicit Route
После выбора следующего шага, узел может изменить явный маршрут следующими способами. Если в процессе реализации алгоритма (см. раздел 4.3.4.1) объект EXPLICIT_ROUTE удален, узел может добавить новый объект EXPLICIT_ROUTE.
В противном случае, если узел является членом абстрактного узла первого субобъекта, перед первым субобъектом может быть введена последовательность субобъектов или первый субобъект может быть заменен. Каждый субобъект в этой последовательности должен представлять абстрактный узел, который является субнабором текущего абстрактного узла.
В качестве альтернативы, если первый субобъект является свободным, перед ним может быть введена произвольная последовательность субобъектов.
4.3.5. Петли
Так как объект EXPLICIT_ROUTE имеет конечную длину, существование свободных узлов предполагает, что возможно формирование петлевых путей в период переходных процессов, сопряженных с реализацией маршрутных протоколов. Это может быть детектировано исходным узлом явного маршрута путем использования еще одного непрозрачного объекта маршрута, называемого RECORD_ROUTE. Объект RECORD_ROUTE используется для сбора детальной информации о маршруте и является полезным для детектирования петель и для диагностики.
4.3.6. Прямая совместимость
Ожидается, что со временем могут быть определены новые субобъекты. Узел, который столкнулся в процессе обработки ERO с нераспознанным субобъектом, посылает отправителю PathErr с кодом ошибки "Routing Error" и значением ошибки "Bad Explicit Route Object". Присутствие нераспознанного субобъекта, который не встретился в ходе обработки ERO, следует игнорировать. Он передается далее вместе с остальной частью стека ERO.
4.3.7. Отсутствие поддержки объекта Explicit Route
Маршрутизатор RSVP, который не распознает объект EXPLICIT_ROUTE, посылает отправителю PathErr с кодом ошибки "Unknown object class". Это вызывает отказ формирования пути. Отправитель должен уведомить руководство, что LSP не может быть сформирован и возможно предпримет действия по резервированию без EXPLICIT_ROUTE или с привлечением другого явного маршрута.
Дополнительные поля заголовка MIME
Будущие документы могут содержать дополнительные поля заголовков MIME для различных целей. Любое новое поле заголовка, которое описывает содержимое сообщения должно начинаться со строки "Content-", для того чтобы такие поля можно было с гарантией отличить от обычных полей заголовков сообщения, следующих стандарту RFC-822.
MIME-extension-field := <Любое поле заголовка RFC-822, которое начинается со строки "Content-">
Используя поля заголовка MIME-Version, Content-Type и Content-Transfer-Encoding, можно подключить стандартным образом произвольные типы данных и добиться совместимости с требованиями документа RFC-822. Никакие ограничения введенные документами RFC-821 или RFC-822 не нарушаются, были приняты меры, чтобы исключить проблемы, связанные с дополнительными ограничениями из-за свойств некоторых механизмов пересылки почты по Интернет (см. RFC-2049).
Приложение A -- обзор грамматики
Это приложение содержит грамматические описания всех конструкций, содержащихся в протоколе MIME.
| attribute | := | token | Распознавание атрибутов не зависит от регистра, в котором написаны их имена. |
| composite-type | := | "message" / "multipart" / extension-token | |
| Content | := | "Content-Type" ":" type "/" subtype *(";" parameter) | Распознавание типов среды и субтипов не зависит от регистра, в котором написаны их имена. |
| description | := | "Content-Description" ":" *text | |
| discrete-type | := | "text" / "image" / "audio" / "video" / "application" / extension-token | |
| encoding | := | "Content-Transfer-Encoding" ":" mechanism | |
| entity-headers | := |
[ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ] *( MIME-extension-field CRLF )
II. Типы среды
1. Введение
Поле Content- Type используется для спецификации природы информации в теле MIME-объекта путем присвоения идентификаторов типа и субтипа среды и предоставления дополнительной информации, которая может быть необходима для данной разновидности среды. За именами типа и субтипа среды в поле следует набор параметров, заданных в нотации атрибут/значение. Порядок следования параметров не существенен.
Тип среды верхнего уровня используется для декларации общего типа данных, в то время как субтип определяет специфический формат данного типа информации. Таким образом, тип среды "image/xyz" говорит агенту пользователя, что данные характеризуют изображение и имеют формат "xyz". Такая информация может использоваться, для того чтобы решить, отображать ли пользователю исходные данные нераспознанного субтипа. Такие действия могут быть разумными для нераспознанного фрагмента субтипа "text", но не для субтипов "image" или "audio". По этой причине, зарегистрированные субтипы "text", "image", "audio" и "video" не должны содержать встроенных фрагментов другого типа. Такие составные форматы должны использовать типы "multipart" или "application".
Параметры являются модификаторами субтипа среды, и как таковые не оказывают никакого влияния на содержимое. Набор параметров зависит от типа и субтипа среды. Большинство параметров связано с одним специфическим субтипом. Однако определенный тип среды высшего уровня может определить параметры, которые приложимы к любому субтипу данного типа. Параметры могут быть обязательными или опционными. MIME игнорирует любые параметры, имена которых нераспознаны.
Поле заголовка Content-Type и механизм типа среды спроектированы так, чтобы сохранить масштабируемость, обеспечивая постепенный рост со временем числа пар тип/субтип и сопряженных с ними параметров. Транспортное кодирование MIME, а также типы доступа "message/external-body" со временем могут обрести новые значения. Для того чтобы гарантировать то, что такие значения разработаны и специфицированы корректно, в MIME предусмотрен процесс регистрации, который использует IANA (Internet Assigned Numbers Authority) в качестве главного органа контролирующего данный процесс (см. RFC 2048). В данном разделе описаны семь стандартизованных типов среды верхнего уровня.
Дополнительные выводы 10. Поле TTL
Поле TTL в IP-заголовке обычно используется для детектирования петель. В IP мультикастинге оно также используется для ограничения области распространения пакетов. Таким образом, в LSR, которые не поддерживают функция декрементации TTL (например, ATM LSR), функция ограничения области действия пострадает. Предположим, что можно вычислить заранее число шагов для заданного LSP. В уникастном LSP значение TTL может декрементироваться на входе или выходе из узла. В случае мультикаста все ветви дерева могут иметь разную длину, так что TTL может декрементироваться только на выходе, потенциально растрачивая полосу пропускания, если TTL окажется меньше или равным нулю.
Другие маршрутные протоколы, мультипротокольные
Более сложный синтаксис атрибутов import и export выглядит следующим образом:
import: [protocol <protocol-1>] [into <protocol-2>]
| from <peering-1> [action <action-1>] | . . . | |
| from <peering-N> [action <action-N>] | accept <filter> |
export: [protocol <protocol-1>] [into <protocol-2>]
| to <peering-1> [action <action-1>] | . . . | |
| to <peering-N> [action <action-N>] | announce <filter> |
Этот синтаксис используется там, где при описании политики других протоколов маршрутизации могут использоваться спецификации опционных протоколов, или для введения маршрутов одного протокола в другой протокол, или для многопротокольной маршрутной политики. Корректные имена протоколов определены в словаре. <protocol-1> является именем протокола, чьими маршрутами производится обмен. <protocol-2> представляет собой имя протокола, который принимает данные об этих маршрутах. Как <protocol-1> так и <protocol-2> являются протоколами по умолчанию для IEGP (Internet Exterior Gateway Protocol), в настоящее время его функцию выполняет BGP. В последующем примере все маршруты interAS передаются протоколу RIP.
aut-num: AS1
import: from AS2 accept AS2
export: protocol BGP4 into RIP to AS1 announce ANY
В следующем примере, AS1 воспринимает маршруты AS2, включая любые адресные префиксы больше префиксов маршрутов AS2, но не передает эти дополнительные префиксы протоколу OSPF.
aut-num: AS1
import: from AS2 accept AS2^+
export: protocol BGP4 into OSPF to AS1 announce AS2
В следующем примере, AS1 передает свои статические маршруты (маршруты, которые являются членами набора AS1:RS-STATIC-ROUTES) маршрутному протоколу interAS и дважды добавляет AS1 к своему маршрутному набору AS.
aut-num: AS1
| import: | protocol STATIC into BGP4 from AS1 action aspath.prepend(AS1, AS1); |
| accept AS1:RS-STATIC-ROUTES |
В следующем примере, AS1 воспринимает другой набор уникастных маршрутов для реверсивной мультикастной переадресации из AS2:
aut-num: AS1
import: from AS2 accept AS2
import: protocol IDMR
from AS2 accept AS2:RS-RPF-ROUTES
Другие применения LSP-туннелей, маршрутизированных шаг-за-шагом
Использование LSP-туннелей, маршрутизированных шаг-за-шагом не ограничено туннелями между узлами BGP. Любая ситуация, в которой мог бы использоваться туннель с инкапсуляцией, является приемлемой для применения LSP-туннеля, маршрутизируемого шаг-за-шагом. Вместо инкапсуляции пакета с новым заголовком, чей адрес места назначения является адресом приемной точки туннеля, производится занесение в стек метки, соответствующей адресному префиксу, который ассоциируется с адресом конечной точки туннеля. Пакет, посланный в туннель, может быть помеченным или нет.
Если начальный узел туннеля намеревается направить помеченный пакет в туннель, он должен сначала заменить значение метки в стеке на значение, полученное от узла конца туннеля. Затем он должен занести в стек метку, которая соответствует самому туннелю. Чтобы разрешить это, конечные точки туннеля должны быть явными партнерами обмена метками. Ассоциации меток, которыми они должны обмениваться не играют никакой роли для LSR в пределах туннеля.
Двунаправленные LSP
В этом разделе определены двунаправленные LSP. Поддержка определена для LSP, которые имеют те же требования управления трафиком, включая долю совмещения, защиту и восстановление, LSR, и ресурсные требования (напр., задержка и разброс) для каждого из направлений. В дальнейшем под "инициатором" подразумевается узел, который начинает формирование LSP, а под "терминатором" подразумевается узел, который является конечным пунктом LSP. Заметим, что для полнодуплексных LSP, имеется только один инициатор и один терминатор.
В норме для установления двунаправленного LSP при использовании [RFC3209] или [RFC3212] должны быть независимо сформированы два однонаправленных маршрута. Этот подход имеет следующие недостатки:
Время установления двунаправленного LSP равно одному RTT плюс одна задержка переходного процесса инициатор-адресат. Это время не только покрывает время установления для случая успешного формирования LSP, но распространяется на худший случай обнаружения недоступного LSP, что в два раза больше переходного процесса инициатор-адресат. Эти задержки особенно существенны для LSP, которые формируются для целей восстановления.
Избыточность управления в два раза больше чем в случае однонаправленных LSP. Это связано с тем, что нужно генерировать отдельные управляющие сообщения (напр., Path и Resv) для обоих сегментов двунаправленного LSP.
Из-за ресурсов, занятых в отдельных сегментах выбор маршрута оказывается осложненным. Можно ожидать дополнительной конкуренции при выделении ресурсов, которая может уменьшить вероятность успешного формирования двунаправленного соединения.
Труднее предоставить хороший интерфейс для оборудования SONET/SDH, которое может базироваться на двунаправленных пошаговых маршрутах.
Двунаправленные оптические LSP (или световоды) рассматриваются в качестве требования большинством сетевых сервис-провайдеров.
В случае двунаправленных LSP, пути данных вниз и вверх по течению, т.е., от инициатора до адресата и от адресата к инициатору устанавливаются с использованием одного набора сигнальных сообщений. Это уменьшает время установления до одного RTT между инициатором и адресатом плюс время обработки, и ограничивает избыточность управления до уровня числа сообщений однонаправленного LSP.
Установление двунаправленного LSP отмечается наличием вышестоящей метки (Upstream Label) в сообщении Path. Объект Upstream_Label имеет тот же формат, что и обобщенная метка, смотри раздел 2.3. Объект Upstream_Label использует номер класса 35 (в форме 0bbbbbbb) и C-тип метки.
EXP-Inferred-PSC LSP (E-LSP)
Один LSP может использоваться для поддержки одного или более OA. Такие LSP могут поддерживать до восьми BA для заданного FEC, вне зависимости оттого, сколько OA охватывают эти BA. Для таких LSP, поле EXP заголовка MPLS используется LSR, чтобы определить PHB, которое следует применить к пакету. Это включает как PSC, так и приоритет отбрасывания.
Мы называем такие LSP - "EXP-inferred-PSC LSPs" (E-LSP), так как PSC пакета, транспортируемого по этому LSP, зависит от значения поля EXP конкретного пакета.
Установление соответствия между полем EXP и PHB (т.е., PSC и приоритет отбрасывания) для заданного LSP, либо осуществляется явно путем сигнального обмена при выполнении процедуры set-up, либо базируется на предварительном конфигурировании. Подробное описание E-LSP представлено в разделе 3.
Фальсификация
Существует два вида LDP-коммуникаций, которые могут быть объектом атак фальсификации (spoofing).
1. Выявление обменов, реализуемых через UDP.
LSR, подключенные непосредственно к каналу, обмениваются базовыми сообщениями Hello через этот канал. Угроза фальсификации базовых Hello может быть уменьшена посредством:
Прием базовых Hellos только через интерфейсы, к которым достойные доверия LSR подключены непосредственно.
Игнорирование базовых Hello, которые не адресованы ко всем маршрутизаторам мультикастной группы данной субсети.
LSR, не подключенные непосредственно к каналу, могут использовать сообщения расширенного Hello, чтобы демонстрировать желание установить LDP сессию. LSR может уменьшить угрозу фальсификации расширенных Hello путем фильтрации их и приема только тех, что были отправлены с адресов разрешительного списка.
2. Коммуникационные сессии через TCP.
LDP специфицирует использование опции подписи TCP MD5, чтобы обеспечить аутентичность и целостность сообщений сессии. [RFC2385] декларирует, что аутентификация MD5 рассматривается сейчас как слишком слабая для данного приложения. Отмечается также, что могла бы использоваться аналогичная опция TCP с более сильным алгоритмом хэширования (например, SHA-1). Однако заметим, что LDP может использовать любую технику дайджестов для TCP сообщений.
FEC
Необходимо точно определить, какие пакеты могут быть поставлены в соответствие каждому LSP. Это делается с помощью FEC-спецификации для каждого LSP. FEC идентифицирует набор пакетов, которые могут быть ассоциированы с данным LSP.
Каждый FEC специфицируется как набор из одного или более элементов FEC. Каждый FEC-элемент определяет набор пакетов, которые могут быть ассоциированы с соответствующим LSP. Когда LSP пользуется несколькими элементами FEC, такой LSP завершается в узле (или раньше), где элементы FEC не могут более следовать одним путем.
Ниже определяются типы элементов FEC. Если потребуется, может быть добавлен новый FEC:
Адресный префикс. Этот элемент является адресным префиксом произвольной длины от 0 до полного адреса включительно.
Адрес ЭВМ. Этот элемент является полным адресом ЭВМ.
Мы говорим, что определенный адрес согласуется с заданным адресным префиксом, если и только если адрес начинается с этого префикса. Мы также говорим, что определенный пакет соответствует заданному LSP, если и только если LSP имеет адресный префикс FEC элемента, который согласуется с адресом места назначения пакета.
Процедура установления соответствия конкретного пакета с заданным LSP использует следующие правила. Каждое правило применяется последовательно до тех пор, пока пакет не сможет быть отнесен к заданному LSP.
Если имеется только один LSP, который содержит FEC элемент адреса ЭВМ, идентичный адресу места назначения пакета, тогда пакет ассоциируется с данным LSP.
Если имеется несколько LSP, содержащих FEC элемент адреса ЭВМ, который идентичен адресу назначения пакета, тогда пакет ассоциируется с одним из этих LSP. Процедура выбора одного из этих LSP в данном документе не рассматривается.
Если пакет в точности соответствует одному LSP, пакет ассоциируется с этим LSP.
Если пакет соответствует нескольким LSP, он ассоциируется с LSP, чей префикс длиннее. Если более длинного префикса выявить не удается, пакет ассоциируется с одним из LSP, чей префикс длиннее других. Процедура выбора одного из этих LSP в данном документе не рассматривается.
Если известно, что пакет должен пройти через определенный выходной маршрутизатор, и имеется LSP, который имеет элемент FEC адресного префикса, являющийся адресом этого маршрутизатора, тогда пакет ассоциируется с этим LSP. Процедура выбора одного из этих LSP в данном документе не рассматривается.
Целесообразно отметить несколько следствий этих правил:
Пакет может быть послан по LSP, чей адресный префикс элемента FEC является адресом выходного маршрутизатора, ТОЛЬКО если нет LSP, согласующихся с адресом места назначения пакета.
Пакет может соответствовать двум LSP, одному с FEC элементом адреса ЭВМ, а другому с FEC элементом префикса адреса. В этом случае пакеты ассоциируются всегда со вторым из этих LSP.
Пакет, который не соответствует определенному FEC-элементу адреса ЭВМ, не может быть послан по соответствующему LSP, даже если FEC элемент адреса ЭВМ идентифицирует выходной маршрутизатор для данного пакета.
FEC TLV
Метки связаны с FEC (Forwarding Equivalence Class). FEC представляет собой список из одного или более элементов FEC. TLV FEC кодирует значения FEC. Формат представления FEC показан ниже:
Элементы FEC от 1 до n
Существует несколько типов элементов FEC; смотри раздел "FEC". Кодирование элементов FEC зависит от типа элемента.
Значение элемента FEC кодируется как однооктетное поле, которое специфицирует тип элемента, и поле переменной длины, которое представляет собой значение элемента, зависящее от типа. Заметим, что в то время как представление значения элемента FEC зависит от типа, представление самого элемента FEC является единственным, где стандартное кодирование LDP TLV не используется.
Значения элемента FEC кодируется следующим образом:
| Значение | ||
| Wildcard | 0x01 | Нет значения; т.e., 0 октетов значения; смотри ниже |
| Префикс | 0x02 | Смотри ниже |
| Адрес ЭВМ | 0x03 | Полный адрес ЭВМ; смотри ниже |
Заметим, что эта версия LDP поддерживает использование нескольких элементов FEC на один FEC для сообщения присвоения метки. Использование нескольких элементов FEC в других сообщениях в данной версии запрещено.
Элемент Wildcard FEC
Предназначен для использования только в сообщениях присвоения и отзыва меток. Указывает, что отзыв/присвоение следует применить ко всем FEC, ассоциированным с меткой в пределах следующего TLV метки. Кодирование значений элементов префикса FEC:
Семейство адресов
Двухоктетная величина, содержащая значение из списка кодов семейств адресов (смотри [RFC1700]), которое характеризует семейство адресов для адресного префикса в поле префикс.
PreLen
Однооктетное целое без знака, содержащее длину в битах последующего адресного префикса. Длина равная 0 говорит о том, что префикс соответствует всем адресам (адрес назначения по умолчанию); в этом случае сам префикс имеет нуль октетов).
Префикс
Адресный префикс, закодированный согласно полю семейство адресов, чья длина в битах была специфицирована в поле PreLen, дополненному до границы, кратной байту.
Элемент FEC адреса ЭВМ имеет формат, описанный ниже:
Семейство адресов
Двухоктетная величина, содержащая значение из списка кодов семейств адресов (смотри [RFC1700]), которое характеризует семейство адресов для адресного префикса в поле префикс.
Длина адреса ЭВМ
Длина адреса ЭВМ в октетах.
Адрес ЭВМ
Адрес, закодированный согласно полю семейство адресов.
Формат с привязкой ресурса
Класс SESSION_ATTRIBUTE = 207, LSP_TUNNEL_RA C-тип = 1
Рис. 15.
Исключает любой
Этот флаг позволяет промежуточным маршрутизаторам использовать механизм локального восстановления, который может вызвать нарушение объекта явного маршрута. Когда детектирована ошибка в смежном канале вниз по течению или узле, транзитный маршрутизатор может переадресовать трафик для службы быстрого восстановления.
0x02 Требуется запись меток
Этот флаг указывает, что при записи маршрута информация о метке должна быть включена.
0x04 Желателен стиль SE
Этот флаг индицирует то, что входной узел туннеля может решить изменить маршрут этого туннеля без его удаления. Узел конца туннеля, реагируя на сообщение Resv, должен использовать стиль SE.
