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

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

Аннотация

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

1. Введение

В области MPLS [MPLS_ARCH], когда поток данных проходит по общему пути, маршрут с коммутацией по меткам LSP (Label Switched Path) может быть сформирован с привлечением сигнальных протоколов MPLS. Во входном маршрутизаторе с коммутацией по меткам LSR (Label Switch Router), каждому пакету присваивается метка, и он передается далее “вниз по течению”. В каждом LSR вдоль LSP, метки используются для определения следующего шага переадресации пакета.

При предоставлении дифференцированных услуг Diff-Serv (Differentiated Service) [DIFF_ARCH] все IP-пакеты, проходящие через канал и требующие того же уровня Diff-Serv, образуют ансамбль BA (Behavior Aggregate). Во входном узле области Diff-Serv, пакеты классифицируются и помечаются с помощью кода DSCP (Diff-Serv Code Point), который соответствует их ансамблю BA. В каждом промежуточном узле, DSCP используется для определения пошагового поведения PHB (Per Hop Behavior), которое задает последовательность обработки и, в некоторых случаях, вероятность отбрасывания пакетов.

В данном документе рассмотрена схема поддержки ансамблей ВА Diff-Serv, чье PHB-поведение определено (в [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) для сетей MPLS. Данная схема основана на использовании комбинации двух типов LSP:

• LSP, которые могут транспортировать несколько ансамблей ВА, так что поле EXP заголовка MPLS передает LSR характер PHB, которое следует применить к пакету.
• LSP, которые транспортируют только один ансамбль ВА, так что обработка пакетов в LSR целиком определяется значением их метки, приоритет отбрасывания пакета задается полем EXP заголовка MPLS или на уровне инкапсуляции канала специфическим механизмом отбрасывания (ATM, Frame Relay, 802.1).

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

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

Более того, решение, предлагаемое в данном документе, позволяет сохранять пространство меток и уменьшает объем обменов, сопряженных с процедурами set-up/tear-down, прибегая, где возможно, к использованию нескольких LSP для заданного FEC (Forwarding Equivalent Class) [MPLS_ARCH].

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

Схема, описанная в данном документе, не препятствует использованию битов поля EXP для поддержки явного уведомления о перегрузке ECN (Explicit Congestion Notification) совместно с Diff-Serv в рамках MPLS. Однако способы поддержки ECN в среде MPLS в данной статье не рассматриваются.

1.1 Терминология

FEC	Forwarding Equivalency Class	Класс эквивалентности переадресации
FTN	FEC-To-NHLFE Map	Таблица соответствия FEC и NHLFE
ILM	Incoming Label Map	Карта входящих меток
LC-ATM	Label Switching Controlled-ATM (interface)	Интерфейс АТМ, управляемый метками
LC-FR	Label Switching Controlled-Frame Relay (interface)	Интерфейс Frame Relay, управляемый метками
LSP	Label Switched Path	Путь с коммутацией по меткам
LSR	Label Switch Router	Маршрутизатор с коммутацией по меткам
MPLS	Multi-Protocol Label Switching	Многопротокольная коммутация по меткам
NHLFE	Next Hop Label Forwarding Entry	Рекорд следующего шага переадресации метки
AF	Assured Forwarding	Гарантированная переадресация
BA	Behavior Aggregate	Ансамбль пакетов
CS	Class Selector	Селектор класса
DF	Default Forwarding	Переадресация по умолчанию
DSCP	Differentiated Services Code Point	Код дифференциальных услуг
EF	Expedited Forwarding	Беспрепятственная переадресация
PHB	Per Hop Behavior	Пошаговое поведение
OA	Ordered Aggregate	Набор ансамблей ВА, которые придерживаются общих заказанных ограничений
PSC	PHB Scheduling Class	Набор из одного или более PHB, которые применяются к ансамблю ВА, принадлежащему заданному OA. Например, AF1x является PSC включающим в себя PHB AF11, AF12 и AF13. EF является примером PSC включающим в себя одно PHB, EF PHB

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

CLP	Cell Loss Priority	Приоритет отбрасывания ячейки
DE	Discard Eligibility	Приемлемость отбрасывания
SNMP	Simple Network Management Protocol	Простой протокол сетевого управления
E-LSP	EXP-Inferred-PSC LSP
L-LSP	Label-Only-Inferred-PSC LSP

1.2 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.

1.3 Label-Only-Inferred-PSC LSP (L-LSP)

Отдельный LSP может быть сформирован для одиночной пары <FEC, OA>. Для таких LSP, PSC определяется явно в момент формирования метки, так что после этого LSR может определить PSC исключительно на основании значения метки. В случае, когда используется встроенный заголовок, приоритет отбрасывания, который следует применить LSR к пакету, определяется содержимым MPLS заголовка с помощью поля EXP. Когда вставной заголовок не используется (например, MPLS поверх ATM), приоритет отбрасывания определяется для LSR полями заголовка канального уровня (например, ATM CLP).

Мы называем такие LSP - "Label-Only-Inferred-PSC LSP" (L-LSP), так как PSC может быть целиком определен из метки без привлечения какой-либо иной информации (например, не обращая внимания на значение поля EXP). Детальное описание работы L-LSP представлено в разделе 4.

1.4 Общие принципы работы

Для данного FEC и, если не наложено каких-либо специфических условий, как указано в разделах 7, 8 и 9, данная спецификация допускает любую из ниже перечисленных комбинаций в сфере MPLS Diff-Serv:

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

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

Для заданного FEC, может быть более одного LSP транспортирующего один и тот же OA, например, для целей балансировки нагрузки OA. Однако для того чтобы удовлетворить затребованным ограничениям, все пакеты данного микропотока, охватывающего возможно несколько BA данного OA, должны транспортироваться через тот же самый LSP. Наоборот, каждый LSP должен быть способен поддерживать все (активные) BA заданного OA. Примеры реализации сценариев представлены в приложение A.

1.5 Соотношение между меткой и FEC

[MPLS_ARCH] утверждает в разделе 2.1., что некоторые маршрутизаторы анализируют заголовок пакета сетевого уровня не только для того, чтобы определить следующий шаг, но также с целью определения приоритета или класса обслуживания. Они могут затем применить разные пороги отбрасывания или порядок обработки для разных пакетов. MPLS позволяет (но не требует) получение данных о приоритете или классе обслуживания из метки. В этом случае, можно сказать, что метка предоставляет комбинацию FEC и приоритета или класса обслуживания. В связи с этим мы отмечаем что:

• В случае E-LSP метка представляет собой комбинацию FEC и набор BA, транспортируемых через E-LSP. Когда все транспортируемые BA передаются через E-LSP, метка представляет полный FEC.
• В случае L-LSP метка представляет собой комбинацию FEC и OA.

1.6 Резервирование полосы для E-LSP и L-LSP

Вне зависимости оттого, какой протокол используется для присвоения меток, E-LSP и L-LSP могут быть сформированы с или без резервирования полосы пропускания.

Установление E-LSP или L-LSP с резервированием полосы пропускания означает, что требования на полосу были согласованы для LSP на фазе его формирования. Такие согласованные требования к полосе пропускания могут использоваться LSR при установлении времени выполнения контроля доступа для согласованного LSP к Diff-Serv ресурсам, предоставляемым (например, путем конфигурирования, SNMP или протоколов политики) для привилегированных PSC. Такие согласованные требования к полосе пропускания могут также использоваться LSR во время конфигурирования для выполнения настройки ресурсов Diff-Serv, предназначенных для приоритетных PSC.

Заметим, что установление E-LSP или L-LSP с резервированием полосы пропускания не означает, что необходимо согласование трафика всех LSP. Так как E-LSP и L-LSP специфицированы в данном документе для поддержки дифференцированных услуг, необходимая обработка переадресуемых пакетов (согласование трафика и политики отбрасывания) определяется соответствующим Diff-Serv PHB. Эта процедура переадресации должна осуществляться LSR на уровне гранулярности BA и должна согласовываться со спецификациями PHB. Когда требования к полосе пропускания согласованы на фазе формирования L-LSP, полоса пропускания будет соответствовать PSC L-LSP. Таким образом, LSR, которые используют согласованную полосу пропускания, чтобы осуществить контроль доступа, могут выполнить эту задачу за счет ресурсов Diff-Serv, которые выделены PSC (например, за счет полосы, гарантированной PSC весом его трафика).

Когда требования к полосе пропускания согласованы на фазе формирования E-LSP, полоса ассоциируется со всем LSP и, следовательно, с набором транспортируемых PSC. Таким образом, LSR, которые используют согласованную полосу для осуществления управления доступом, могут выполнять управление доступом к общим ресурсам, используемым совместно набором PSC.

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

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

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

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

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

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

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

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

Рис. 1

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

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

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

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

2.2 Определение входного PHB

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

2.2.1 Определение входного PHB с учетом рекорда стека меток

В разделах 3.3 и 4.3 представлено то, как осуществляется определение входного PHB при рассмотрении рекорда стека меток конкретного входного пакета и/или полученной входной инкапсулированной информации MPLS, зависящей от типа входного LSP и разновидности MPLS инкапсуляции.

В разделе 2.6 представлены детали того, какой рекорд стека меток следует анализировать для определения входного PHB в зависимости от поддерживаемого режима туннелирования Diff-Serv.

2.2.2 Определение входного PHB с учетом IP-заголовка

В разделе 2.6 представлены детали того, когда для определения входного PHB следует рассматривать IP-заголовок, в зависимости от модели туннелирования Diff-Serv. В тех случаях, когда используется IP-заголовок, на данном этапе выполняется все точно то же, что и в случае Diff-Serv IP-маршрутизатора, не поддерживающего MPLS, а для определения входного PHB используется поле DS.

2.3 Определение исходящего PHB с опционным формированием трафика

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

Когда фаза формирования трафика отсутствует, выходное PHB тождественно входному PHB.

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

[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.

2.5 Кодирование информации Diff-Serv на уровне инкапсуляции

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

2.5.1 Кодирование информации Diff-Serv в поле передаваемой метки

В разделах 3.5 и 4.5 подробно описано, как следует выполнять кодирование информации Diff-Serv в транспортируемом стеке меток и/или инкапсулируемые данные MPLS, в зависимости от типа выходного LSP и инкапсуляции MPLS.

В разделе 2.6 описано, в какой записи стека меток следует записывать Diff-Serv данные в зависимости от поддерживаемой модели туннелирования.

2.5.2 Кодирование информации Diff-Serv в транспортируемом IP-заголовке

Для записи информации Diff-Serv в IP заголовок передаваемого пакета, программа работает также как и в случае маршрутизатора, не поддерживающего MPLS IP Diff-Serv и заносит DSCP выходного PHB в поле DS.

В разделе 2.6 подробно описано, когда осуществляется запись Diff-Serv информации в IP заголовок в зависимости от поддерживаемого режима туннелирования Diff-Serv.

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

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

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

Однако, с точки зрения Diff-Serv LSP имеют много существенных отличий от IP-туннелей:

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

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

2.6.2 Модель трубы

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

В этой модели, туннелируемые пакеты должны нести в себе две значимые вещи:

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

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

Рис. 2

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

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

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

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

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

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

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

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

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

Рис. 3.

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

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

Рис. 4.

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

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

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

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

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

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

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

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

• предпоследний LSR определяет входное PHB, рассматривая выходную метку из полученного стека меток. Другими словами, когда нужно выполнить операцию pop для заданного LSP, предпоследний LSR определяет входное PHB до реализации pop.

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

2.6.3 Однородная модель

При однородной модели MPLS-туннели (другими словами LSP) рассматриваются с позиции Diff-Serv, как соединение точка-точка. MPLS-туннели могут использоваться для целей переадресации, но не имеют никакого влияния на Diff-Serv. В этой модели любой пакет содержит только одно поле с информацией Diff-Serv, имеющей какое-то значение, и именно его величина заносится в самую внешнюю метку (или в поле IP DSCP, когда IP-пакет передается непомеченным, например, вначале LSP). Любая информация Diff-Serv, хранящаяся где-либо еще (например, в более глубокой записи стека меток), не играет никакой роли для промежуточных узлов или выхода туннеля и игнорируется. Если формирование трафика в промежуточных узлах LSP оказывает влияние на "выходную" информацию Diff-Serv, актуализованная информация Diff-Serv считается значимой на выходе LSP. Работа однородной модели без PHP проиллюстрирована на рис. 5:

Рис. 5.

(M) - значимая информация Diff-Serv в соответствующем заголовке.
(x) - отсутствие значимой информации Diff-Serv.
I - входной узел LSP
E - выходной узел LSP

Работа однородной модели с PHP проиллюстрирована на рис. 6:

Рис. 6.

(M) - существенная информация Diff-Serv, записанная в соответствующем заголовке.
(x) - безразличная информация Diff-Serv.
I - входной узел LSP;
P - предпоследний узел LSP;
E - выходной узел LSP.

Однородная модель для Diff-Serv поверх происходит так, как если бы MPLS не использовался совсем. Другими словами для работы Diff-Serv MPLS совершенно прозрачен.

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

• при получении непомеченного пакета, LSR определяет входное PHB, просматривая полученный IP-заголовок.

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

• при выполнении операции push для заданного LSP, LSR заносит информацию Diff-Serv в передаваемую метку, записанную в стек. Информация Diff-Serv, занесенную в инкапсулированный заголовок (свопированная запись метки или IP-заголовок), не имеет никакого значения.

• при выполнении операции swap-only для заданного LSP, LSR заносит информацию Diff-Serv в позицию стека меток, которая содержит свопированную метку.

• когда используется PHP, предпоследний LSR должен позаботиться о формировании таблицы PHB-->Encaps для метки, соответствующей обрабатываемому заголовку (или соответствия PHB-->DSCP), для того чтобы выполнить кодирование информации Diff-Serv. В качестве примера, таблица PHB-->DSCP может быть сконфигурирована локально. В качестве другого примера для некоторой среды, вполне приемлемо для предпоследнего LSR предположить, что набор таблиц PHB-->Encaps следует использовать для исходящей метки в обрабатываемом LSR заголовке, если он не выполняет PHP. Заметим также, что данная спецификация предполагает, что предпоследний LSR не осуществляет обмен меток (swapping) для позиции в стеке, для которой выполнена операция pop (и в действительности он даже не смотрит на обрабатываемую метку). Следовательно, ограничения могут быть наложены на кодирование информации Diff-Serv, которые могут быть выполнены предпоследним LSR. Например, данная спецификация не допускает ситуаций, когда предпоследний LSR извлекает из стека метку, соответствующую E-LSP, поддерживающему два PSC, в то время как заголовок при выполнении операции pop содержит значения меток для двух L-LSP, каждый из которых поддерживает один PSC, так как кодирование информации Diff-Serv будет требовать выбора одной или другой метки.

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

2.6.4 Иерархия

За счет механизма стека меток, MPLS позволяет вложенное LSP-туннелирование с любой глубиной вложения. Видно, что с таким вложением, операция push для уровня N+1 осуществляется последующим (или тем же) LSR по отношению LSR, выполняющим push для уровня N, в то время как команда pop уровня N+1 выполняется на предыдущем (или том же) LSR по отношению к LSR, выполняющим pop уровня N. Для заданного уровня N LSP, входной LSR, выполняющий push, и LSR, выполняющий pop (предпоследний LSR или конец LSP), должен работать в рамках той же модели туннеля (т.е., труба, короткая труба или однородная модель). Однако не существует ограничений для совместимых моделей туннелирования разных уровней, так что для LSP на различных уровнях могут использоваться разные модели туннелирования. Иерархия операций проиллюстрирована ниже (рис. 7) для случая двух уровней туннелей:

(1) Модель туннеля 1
(2) Модель туннеля 2
Рис. 7.

Туннельная модель 2 может быть той же, но может и отличаться от модели 1. Для заданного LSP уровня N, LSR должен определить входное PHB и занести информацию Diff-Serv, как это описано в разделе 2.6.2, 2.6.2.1 и 2.6.3 согласно модели туннелирования уровня N LSP и вне зависимости от туннельной модели других уровней LSP.

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

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

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

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

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

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

3.2.1 Предварительно конфигурируемая таблица 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.

3.3 Определение входного PHB для входящего E-LSP

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

При рассмотрении записи в стеке меток E-LSP, соответствующей входному PHB, LSR должен:

• рассмотрев входную метку E-LSP, определить таблицу EXP-->PHB путем анализа соответствия Encaps-->PHB в контексте Diff-Serv, сопряженном с ILM.

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

3.4 Формирование таблицы PHB-->Encaps для исходящего E-LSP

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

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

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

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

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

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

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

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

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

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

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

3.4.2.1 Соответствие PHB-->CLP по умолчанию

PHB CLP бит
DF → 0
CSn → 0
AFn1 → 0
AFn2 → 1
AFn3 → 1
EF → 0

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

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

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

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

3.4.3.1 Соответствие PHB-->DE по умолчанию

PHB Бит DE
DF → 0
CSn → 0
AFn1 → 0
AFn2 → 1
AFn3 → 1
EF → 0

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

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

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

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

3.4.4.1 Предварительная конфигурация соответствия PHB-->802.1

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

3.5 Кодирование информации Diff-Serv для слоя инкапсуляции исходящего E-LSP

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

LSR сначала определяет набор соответствий PHB-->Encaps в контексте Diff-Serv, сопряженном с соответствующей меткой в NHLFE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Детальная работа L-LSP 4.1 Определение L-LSP

L-LSP описаны в разделе 1.3.

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2.1.1 Обязательное соответствие EXP/PSC -->PHB

Поле EXP PSC PHB
000 DF → DF
000 CSn → CSn
001 AFn → AFn1
010 AFn → AFn2
011 AFn → AFn3
000 EF → EF

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

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

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

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

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

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

4.2.2.1 Соответствие CLP/PSC --> PHB по умолчанию

Бит CLP PSC PHB
0 DF → DF
0 CSn → CSn
0 AFn → AFn1
1 AFn → AFn2
0 EF → EF

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

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

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

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

4.2.3.1 Соответствие DE/PSC --> PHB по умолчанию

Бит DE	PSC	PHB
0	DF →	DF
0	CSn →	CSn
0	AFn →	AFn1
1	AFn →	AFn2
0	EF	EF

4.3 Определение входного PHB для входящего L-LSP

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

Когда метка, соответствующая входящему L-LSP рассматривается для определения входного PHB, LSR сначала определяет таблицу соответствия Encaps-->PHB, ассоциированную с данной меткой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.4.1.1 Обязательное соответствие PHB-->EXP

PHB Поле EXP
DF → 000
CSn → 000
AFn1 → 001
AFn2 → 010
AFn3 → 011
EF → 000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.5 Кодирование информации Diff-Serv на уровне инкапсуляции для выходного L-LSP

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

LSR сначала определяет набор PHB-->Encaps для контекста Diff-Serv, ассоциированного с соответствующей меткой в NHLFE и затем осуществляет соответствующее кодирование, как это специфицировано в разделах 3.5.1, 3.5.2, 3.5.3 и 3.5.4.

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

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

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

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

5. Расширение RSVP для поддержки Diff-Serv

Архитектура MPLS не предполагает использования одного протокола рассылки меток. [RSVP_MPLS_TE] определяет расширение RSVP для установления LSP в сетях MPLS. В данном разделе специфицированы расширения RSVP, кроме тех, которые определены в [RSVP_MPLS_TE], чтобы установить LSP, поддерживающие дифференцированные услуги в сетях MPLS.

5.1 Формат сообщений RSVP, связанных с Diff-Serv

В данном документе определен один новый объект RSVP: DIFFSERV. Подробное описание этого объекта представлено ниже. Этот новый объект применим к сообщениям Path. Данная спецификация определяет только использование объекта DIFFSERV в сообщениях Path, предназначенных для установления туннелей LSP в соответствии [RSVP_MPLS_TE], и, таким образом, содержащих объект Session с C-Type равным LSP_TUNNEL_IPv4 и объект LABEL_REQUEST.

Ограничения, определенные в [RSVP_MPLS_TE] для поддержки установления туннелей LSP с помощью RSVP, применимы для формирования туннелей LSP, поддерживающих Diff-Serv: например, поддерживаются только уникастные LSP, а мультикастные будут рассмотрены позднее.

Этот новый объект DIFFSERV является опционным с точки зрения RSVP, для того чтобы реализации RSVP, несвязанные с формированием MPLS LSP не должны поддерживать этот объект.

Объект DIFFSERV является опционным для поддержки туннелей LSP, как это определено в [RSVP_MPLS_TE]. LSR, способный поддерживать Diff-Serv E-LSP, использующий предварительно сконфигурированные таблицы EXP<-->PHB в согласии с этой спецификацией может поддерживать объект DIFFSERV. LSR, способный поддерживать Diff-Serv E-LSP, использующий согласованную таблицу EXP<-->PHB, в согласии с этой спецификацией должен поддерживать объект DIFFSERV. LSR, способный поддерживать Diff-Serv L-LSP, в согласии с этой спецификацией должен поддерживать объект DIFFSERV.

5.1.1 Формат сообщений Path

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

<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[<EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[<SESSION_ATTRIBUTE> ]
[<DIFFSERV> ]
[<POLICY_DATA> ... ]
[<sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[<ADSPEC> ]
[<RECORD_ROUTE> ]

5.2 Объект DIFFSERV

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

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

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

Рис. 8.

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

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

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

Рис. 9.

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

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

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

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

класс = 65, C_Type = 2

Рис. 10.

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

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

5.3 Работа с объектом DIFFSERV

Чтобы сформировать туннель LSP с RSVP, отправитель подготавливает сообщение Path с типом сессии LSP_Tunnel_IPv4 и с объектом LABEL_REQUEST, как и в случае [RSVP_MPLS_TE].

Чтобы сформировать туннель E-LSP с RSVP, который использует предварительно сконфигурированное соответствие EXP<-->PHB, отправитель подготавливает сообщение Path:

• с типом сессии LSP_Tunnel_IPv4,

• с объектом LABEL_REQUEST и

• без объекта DIFFSERV.

Чтобы сформировать туннель E-LSP с RSVP, который использует предварительно сконфигурированную таблицу EXP<-->PHB, отправитель может в качестве альтернативы подготовить сообщение Path :

• с типом сессии LSP_Tunnel_IPv4,
• с объектом LABEL_REQUEST и
• с объектом DIFFSERV для E-LSP, не содержащим записей MAP.

Чтобы сформировать туннель E-LSP с RSVP, который использует согласованное соответствие EXP<-->PHB, отправитель подготавливает сообщение Path:

• с типом сессии LSP_Tunnel_IPv4,

• с объектом LABEL_REQUEST,

• с объектом DIFFSERV для E-LSP, содержащим одну запись MAP для каждого значения EXP, поддерживаемого E-LSP.

Чтобы сформировать туннель L-LSP с RSVP, отправитель подготавливает сообщение Path:

• с типом сессии LSP_Tunnel_IPv4,

• с объектом LABEL_REQUEST,

• с объектом DIFFSERV для L-LSP, содержащего класс обслуживания PHB (PSC), поддерживаемый в этом L-LSP.

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

Если в сообщении Path объект DIFFSERV отсутствует, LSR должен интерпретировать это как запрос E-LSP, использующий предварительно сконфигурированную таблицу соответствия EXP<-->PHB. Однако, для целей обратной совместимости с другими опциями QoS без Diff-Serv, допускаемыми [RSVP_MPLS_TE], такими как интегрированные услуги с управляемой загрузкой (Integrated Services Controlled Load) или гарантированные услуги, LSR может поддерживать конфигурируемые опции “пренебрежения” (override). Когда такая опция сконфигурирована, LSR интерпретирует сообщение path без объекта Diff-Serv, как было запрошено для LSP (QoS без Diff-Serv).

Если в сообщении Path присутствует объект DIFFSERV для E-LSP, несодержащего записи MAP, LSR должен интерпретировать это, как запрос E-LSP, использующий предварительно сконфигурированную таблицу соответствия EXP<-->PHB. В частности, это позволяет LSR с опцией “пренебрежения” поддерживать E-LSP c предварительно сконфигурированной таблицей соответствия EXP<-->PHB, и в то же время с LSP с QoS без Diff-Serv.

Если в сообщении Path имеется объект DIFFSERV для E-LSP, содержащего, по крайней мере, одну запись MAP, LSR должен интерпретировать это как запрос E-LSP с согласованным соответствием EXP<-->PHB.

Если в сообщении Path имеется объект DIFFSERV для L-LSP, LSR должен интерпретировать это, как запрос L-LSP.

Адресат LSR E-LSP или L-LSP реагирует на сообщение Path, содержащее объект LABEL_REQUEST, посылкой сообщения Resv :

• с объектом LABEL

• без объекта DIFFSERV.

Предполагая, что запрос метки принят и метка выделена, Diff-Serv LSR (отправитель, адресат, промежуточные узлы) должны:

• актуализовать контекст Diff-Serv, сопряженный с сформированным LSP и их ILM/FTN, как это специфицировано в предыдущих разделах (входная и выходная метка),

• инсталлировать необходимую программу переадресации Diff-Serv (формирование трафика и приоритеты отбрасывания) для этого NHLFE (выходная метка).

LSR, который распознает объект DIFFSERV и который получает сообщение path, содержащее объект DIFFSERV, но не имеет объекта LABEL_REQUEST, или тип сессии которого не является LSP_Tunnel_IPv4, посылает отправителю сообщение PathErr с кодом ошибки Diff-Serv Error и значением ошибки Unexpected DIFFSERV object. Эти значения определены ниже в разделе 5.5.

LSR, получающий сообщение Path с объектом DIFFSERV для E-LSP, распознавший его, но не поддерживающий конкретное PHB, закодированное в одном или более записях MAP, посылает отправителю сообщение PathErr с кодом ошибки Diff-Serv Error и значением ошибки Unsupported PHB.

LSR, получающий сообщение Path с объектом DIFFSERV для E-LSP, распознавший его, но определивший, что согласованная таблица EXP<-->PHB некорректна, посылает отправителю сообщение PathErr с кодом ошибки Diff-Serv Error и значением ошибки Invalid EXP<-->PHB mapping. Согласованная таблица соответствия EXP<-->PHB в объекте DIFFSERV для E-LSP некорректна, если:

• значение поля MAPnb лежит вне пределов диапазона 0 - 8 или

• данное значение EXP присутствует в более чем одной записи MAP, или

• кодировка PHBID некорректна.

LSR, получающий сообщение Path с объектом DIFFSERV для L-LSP, распознал DIFFSERV, но не поддерживает конкретный PSC, записанный в поле PSC, посылает отправителю сообщение PathErr с кодом ошибки Diff-Serv Error и значением ошибки Unsupported PSC.

LSR, получающий сообщение Path с объектом DIFFSERV, который распознал объект DIFFSERV, но не может выделить требующийся ресурс для LSP Diff-Serv, посылает отправителю PathErr с кодом ошибки Diff-Serv Error и значением ошибки Per-LSP context allocation failure. LSR должен уметь обрабатывать ситуации, когда запрос метки не может быть воспринят по причине, отличной от уже обсужденных, в соответствии с [RSVP_MPLS_TE]. Например, системой контроля доступа отвергнуто резервирование, метка не может быть присвоена.

5.4 Отсутствие поддержки объекта 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).

5.5 Коды ошибок для Diff-Serv

В процедурах, описанных выше, некоторые ошибки должны объявляться Diff-Serv Error. Значение кода Diff-Serv Error равно 27. Ниже представлены коды ошибок для Diff-Serv:

Код	Тип ошибки
1	Нестандартный объект DIFFSERV
2	Неподдерживаемый PHB
3	Некорректное соответствие EXP<-->PHB
4	Неподдерживаемое PSC
5	Неудача выделения ресурсов на каждый LSP

5.6 Тип услуги Intserv

Как E-LSP, так и L-LSP могут быть сформированы с или без резервирования полосы пропускания. Как это специфицировано в [RSVP_MPLS_TE], для установления E-LSP или L-LSP с резервированием полосы, используется услуга управления нагрузкой Int-Serv (или возможно гарантированная услуга) и полоса пропускания согласуется в SENDER_TSPEC (соответственно FLOWSPEC) сообщения path (соответственно Resv).

Как описано в [RSVP_MPLS_TE], для установления E-LSP или L-LSP без резервирования полосы используется служба Null, специфицированная в [NULL].

Заметим, что эта спецификация определяет использование E-LSP и L-LSP только для поддержки услуг Diff-Serv. Безотносительно к услуге Intserv (контролируемая нагрузка, Null-услуга, гарантированное обслуживание,...) и, несмотря на то, предусматривается ли резервирование полосы пропускания, E-LSP и L-LSP определены здесь для поддержки услуг Diff-Serv.

Заметим также, что эта спецификация не касается объекта DCLASS, определенного в [DCLASS], так как этот объект передает информацию о значениях DSCP, которые не существенны в сети MPLS.

6. Расширения LDP для поддержки Diff-Serv

Архитектура MPLS не предполагает одного протокола рассылки меток. [LDP] определяет протокол рассылки меток LDP (Label Distribution Protocol) и его использование для формирования путей LSP с коммутацией по меткам в сетях MPLS. В данном разделе специфицируются расширения LDP для формирования LSP, поддерживающих дифференциальные услуги в сетях MPLS. Один новый LDP TLV определен в данном документе:

- Diff-Serv TLV

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

6.1 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].

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

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

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

6.3 LDP-сообщения, сопряженные с Diff-Serv
6.3.1 Сообщение запроса метки

Формат сообщения запроса метки приведен ниже, это сообщение имеет опционное поле Diff-Serv TLV:

Рис. 13.

6.3.2 Сообщение ассоциации метки

Формат сообщения установления соответствия метки изображен ниже на рис. 14, такое сообщение имеет опционное поле Diff-Serv TLV:

Рис. 14.

6.3.3 Сообщение рассылки метки

Формат сообщения о присвоении метки представлен ниже на рис. 15, он содержит опционное поле статуса TLV:

Рис. 15.

6.3.4 Сообщение анонсирования (Notification Message)

Формат сообщения анонсирования метки отображен ниже на рис. 16, это сообщение содержит опционное поле Diff-Serv TLV:

Рис. 16.

6.4 Обработка Diff-Serv TLV
6.4.1 Обработка Diff-Serv TLV в режиме Downstream Unsolicited

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

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

При формировании метки для L-LSP, ниже расположенный Diff-Serv LSR посылает сообщение ассоциации метки с Diff-Serv TLV для L-LSP, содержащий класс обслуживания PHB (PSC), который нужно поддерживать в этом L-LSP. Предполагая, что формирование метки прошло успешно, нижестоящий и вышестоящий LSR должны:

• актуализовать контекст Diff-Serv, ассоциированный со сформированными LSP и их ILM/FTN, как это специфицировано в предыдущих разделах (входная и выходная метки),

• инсталлировать требуемый алгоритм переадресации Diff-Serv (форматирование трафика и схема отбрасывания пакетов) для этого NHLFE (выходная метка).

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

Вышестоящий Diff-Serv LSR, получивший сообщение ассоциации метки с Diff-Serv TLV для E-LSP и не поддерживающий конкретное PHB, закодированное в одном или более записях MAP, должен отвергнуть эту метку, послав сообщение Label Release, которое содержит TLV метки и статус TLV со статусным кодом Unsupported PHB.

Вышестоящий Diff-Serv LSR, получив сообщение ассоциации метки с Diff-Serv TLV для E-LSP и определив, что согласованная таблица EXP<-->PHB некорректна, должен отвергнуть эту метку, послав сообщение Label Release, которое содержит TLV метки и статус TLV со статусным кодом Invalid EXP<--> PHB mapping. Согласованная таблица EXP <-->PHB в объекте DIFFSERV для E-LSP некорректна, если:

• поле MAPnb находится вне диапазона 1 - 8, или

• данное значение EXP присутствует более одного раза в одной записи MAP, или

• кодирование PHBID некорректно

Вышестоящий Diff-Serv LSR, получив сообщение ассоциации метки с Diff-Serv TLV для L-LSP, содержащий значение PSC, которое не поддерживается, должен отвергнуть эту метку, послав сообщение Label Release, которое содержит TLV метки и статус TLV со статусным кодом Unsupported PSC.

6.4.2 Обработка Diff-Serv TLV в режиме Downstream on Demand

В этом разделе описаны операции, используемые в режиме Downstream on Demand. При запросе метки для E-LSP, который использует предварительно сконфигурированную таблицу EXP<-->PHB, вышестоящий Diff-Serv LSR посылает сообщение Label Request без Diff-Serv TLV.

При запросе метки для E-LSP, который использует согласованную таблицу EXP<-->PHB, вышестоящий Diff-Serv LSR посылает сообщение Label Request с Diff-Serv TLV для E-LSP, которое содержит по одной записи MAP для каждого значения EXP, поддерживаемого в этом E-LSP.

При запросе метки для L-LSP, вышестоящий Diff-Serv LSR посылает сообщение Label Request с Diff-Serv TLV для L-LSP, содержащее PSC, который следует поддерживать в этом L-LSP.

Нижестоящий Diff-Serv LSR, посылая сообщение Label Mapping в ответ на запрос метки для E-LSP или L-LSP не должен включать Diff-Serv TLV в это сообщение ассоциации метки. Предполагая формирование метки успешным, нижестоящий и вышестоящий LSR должны:

• актуализовать контекст Diff-Serv, ассоциированный со сформированными LSP в их ILM/FTN, как это указано в предыдущих разделах (входящая и исходящая метки),

• инсталлировать требуемую обработку переадресации Diff-Serv (формирование трафика и политика отбрасывания) для этого NHLFE (исходящая метка).

Вышестоящий Diff-Serv LSR, получая в ответ на запрос метки сообщение Label Mapping, содержащее Diff-Serv TLV, должен отклонить ассоциацию метки, послав сообщение Label Release, содержащее TLV метки и статус TLV со статусным кодом Unexpected Diff-Serv TLV.

Нижестоящий Diff-Serv LSR, получая сообщение Label Request с несколькими Diff-Serv TLV, принимает во внимание только первый из них. LSR должен игнорировать и не переадресовывать последующие Diff-Serv TLV.

Нижестоящий Diff-Serv LSR, который получает сообщение Label Request с Diff-Serv TLV для E-LSP и не поддерживает конкретное PHB, записанное в одном (или более) записей MAP, должен отвергнуть запрос, послав сообщение со статусным кодом Unsupported PHB.

Нижестоящий Diff-Serv LSR, получив сообщение Label Request с Diff-Serv TLV для E-LSP и определив, что согласованная таблица EXP <-->PHB некорректна, должен отвергнуть запрос, послав сообщение Notification, которое включает в себя статус TLV со статусным кодом Invalid EXP<-->PHB mapping. Согласованная таблица EXP<-->PHB в DIFFSERV TLV для E-LSP является некорректной, если:

• поле MAPnb вне диапазона 1 - 8, или

• данное значение EXP присутствует более одного раза в записи MAP, или

• кодировка PHBID некорректна.

Нижестоящий Diff-Serv LSR, получая сообщение Label Request с Diff-Serv TLV для L-LSP, содержащее значение PSC, которое не поддерживается, должен отвергнуть запрос, послав сообщение Notification которое включает в себя TLV со статусным кодом Unsupported PSC.

Нижестоящий Diff-Serv LSR, который распознает тип Diff-Serv TLV Type в сообщении Label Request, но не может предоставить необходимую для каждого LSP контекстную информацию, должен отвергнуть запрос, послав сообщение Notification, которое включает в себя статус TLV со статусным кодом Per-LSP context allocation failure.

Нижестоящий Diff-Serv LSR, который распознает тип Diff-Serv TLV в сообщении Label Request и поддерживает запрошенный PSC, но не способен удовлетворить запрос метки по другим причинам (например, нет доступной метки), должен послать сообщение Notification в соответствии с существующими процедурами LDP [LDP] (например, со статусным кодом No Label Resource). Это сообщение Notification должно включать в себя запрошенный Diff-Serv TLV.

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

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

6.6 Информация о полосе пропускания

Информация о полосе пропускания может быть также согласована на фазе формирования канала E-LSP и L-LSP, например, для целей управления трафиком, используя параметры трафика TLV, как это описано в [MPLS CR LDP].

7. Поддержка 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 для перечисленных интерфейсов.

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

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

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

8.1 Использование классов трафика ATM и механизмы управления трафиком

Применение "категорий услуг ATM" специфицированных форумом ATM, "ATM Transfer Capabilities", определенных союзом ITU-T или поставщиком специфических классов трафика ATM находятся вне области рассмотрения данным документом. Единственным требованием для совместимых реализаций является общность принципов переадресации на основе ВА для L-LSP в среде ATM LSR Diff-Serv.

Так как имеется только один бит (CLP) для кодирования PHB приоритета отбрасывания в каналах ATM, в ATM LSR поддерживается только два разных уровня приоритета отбрасывания. В разделах 4.2.2 и 4.4.2 определено, как три уровня приоритета отбрасывания AFn OA ставятся в соответствие двум уровням приоритетов отбрасывания в ATM. Это соответствие находится в согласии с требованиями, специфицированными [DIFF_AF] для случая, когда поддерживается только два уровня приоритетов отбрасывания.

Чтобы избежать отбрасывания части пакетов, в ATM-LSR следует разрешать механизмы отбрасывания типа EPD (Early Packet Discard) (смотри [ATMF_TM]) для всех PHB, описанных в данном документе.

8.2 Реализация LSR с интерфейсами LC-ATM

LSR Diff-Serv должны поддерживать L-LSP для интерфейсов LC-ATM. Данная спецификация предполагает, что краевой-LSR области ATM-LSR использует метод инкапсуляции, определенный в [MPLS_ATM].

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

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

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

9.1 Использование параметров трафика Frame Relay и механизмов управления трафиком

Использование параметров трафика Frame Relay, как это специфицировано ITU-T и Frame Relay-Forum или поставщиком специфических механизмов управления трафиком Frame Relay находятся за пределами рассмотрения данным документом. Единственным требованием для совместимости реализаций является то, что механизм переадресации, определяемый BA, вдоль L-LSP Frame Relay LSR должен быть совместимым с соответствующими спецификациями Diff-Serv PHB. Так как имеется только один бит (DE) для кодирования значения PHB приоритета отбрасывания в каналах Frame Relay, такие LSR поддерживают только два уровня приоритета отбрасывания. В разделах 4.2.3 и 4.4.3 определено, как три уровня приоритета отбрасывания AFn OA ставятся в соответствие этим двум уровням в Frame Relay. Это соответствие находится в согласии с требованиями специфицированными в [DIFF_AF] для случая, когда поддерживаются только два уровня приоритета отбрасывания.

9.2 Реализация LSR с интерфейсами LC-FR

LSR Diff-Serv должны поддерживать L-LSP для интерфейсов LC-Frame Relay. Данная спецификация предполагает, что краевые LSR области FR-LSR используют метод “общей инкапсуляции”, как это рекомендуется в [MPLS_FR].

Приложение A. Примеры реализации сценариев

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

A.1 Сценарий 1: 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.2 Сценарий 2: Более 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).

A.3 Сценарий 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 Сценарий 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.5 Сценарий 5: 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.6 Сценарий 6: отсутствие управления трафиком/защиты MPLS для 8 BA, управление трафиком для каждого OA/защита MPLS для прочих BA.

Сервис провайдер, который не выполняет управление трафиком и не осуществляет защиту 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.7. Сценарий 7: Более 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. Примеры сценариев резервирования полосы пропускания

B.1 Сценарий 1: отсутствие резервирования полосы пропускания

Рассмотрим случай, когда сетевой администратор решил:

• иметь Diff-Serv ресурсы, полностью обеспечиваемые в режиме off-line (например, через интерфейс командной строки, посредством SNMP, COPS,...)

• иметь маршрутизацию Shortest Path, используемую для всех видов трафика Diff-Serv.

Это наиболее приемлемая модель обеспечения Diff-Serv через сеть без поддержки MPLS IP. В этом случае, E-LSP и/или L-LSP будут устанавливаться без согласованной полосы пропускания.

B.2 Сценарий 2: Резервирование полосы пропускания для управления доступом для каждого PSC

Рассмотрим случай, когда сетевой администратор решил:

• иметь ресурсы Diff-Serv, полностью обеспечиваемые в режиме off-line (например, через интерфейс командной строки, посредством SNMP, COPS, и пр.);

• использовать L-LSP;

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

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

B.3 Сценарий 3: Резервирование полосы пропускания для управления доступом и настройки ресурсов для каждого PSC

Рассмотрим случай, когда сетевой администратор решил:

• использовать 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.

Назад: 4.4.22. Обзор IP-мультикастинга в среде многопротокольной коммутации по меткам (MPLS)
Оглавление: Телекоммуникационные технологии
Вперёд: 4.4.24. RSVP-TE: расширение RSVP для LSP-туннелей