RFC 2702 Requirements for Traffic Engineering Over MPLS

Network Working Group                                     D. Awduche
Request for Comments: 2702                                J. Malcolm
Category: Informational                                   J. Agogbua
                                                           M. O'Dell
                                                          J. McManus
                                                UUNET (MCI Worldcom)
                                                      September 1999

Требования к построению трафика в сетях MPLS

Requirements for Traffic Engineering Over MPLS

PDF

Статус документа

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

Авторские права

Copyright (C) The Internet Society (1999). All Rights Reserved.

Аннотация

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

1.0 Введение

Мультипротокольная коммутация по меткам (MPLS¹) [1,2] объединяет в себе парадигмы коммутации по меткам и маршрутизации на сетевом уровне. Основная идея заключается в присваивании пакетам коротких меток фиксированного размера на входе в облако MPLS (на основе концепции классов эквивалентной пересылки [1,2]). В рамках домена MPLS присоединенные к пакетам метки служат для принятия решений о пересылке (обычно без анализа заголовка исходного пакета).

С помощью этой сравнительно простой парадигмы можно разработать набор мощных конструкций для решения множества вопросов в части дифференциации услуг Internet. Одним из наиболее значимых стартовых приложений MPLS будет построение трафика (TE²). Важность этого приложение уже достаточно очевидна (см. [1,2,3]).

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

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

Среди недавних работ по построению трафика и управлению трафиком в MPLS следует отметить работу Li и Rekhter [3], а также ряд других документов. В работе [3] предложена архитектура, которая использует MPLS и RSVP для развертывания масштабируемых систем с дифференциацией услуг, а также для построения трафика Internet. Этот документ служит дополнением к упомянутой работе. Здесь отражен опыт авторов в части управления крупными магистральными сетями Internet.

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

Предполагается, что читатель знаком с терминологией MPLS, определенной в [1].

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [11].

1.2 Организация документа

Оставшаяся часть документа организована следующим образом — в разделе 2 рассматриваются базовые функции TE в Internet, в разделе 3 дан обзор возможностей MPLS в части построения трафика (разделы 1 — 3 являются базовыми для дальнейшего понимания), в разделе 4 дан обзор фундаментальных требований к построению трафика в MPLS, в разделе 5 описаны желаемые атрибуты и характеристики транков, относящиеся к TE, раздел 6 посвящен набору атрибутов, которые могут быть связаны с ресурсами для ограничения маршрутизируемости транков трафика и LSP через них, в разделе 7 рассматривается схема основанной на ограничениях маршрутизации³ в доменах MPLS, а раздел 8 содержит заключительные ремарки.

2.0 Построение трафика

В этом разделе рассмотрены базовые функции построения трафика в автономной системе (AS⁴) современной сети Internet. Отмечены ограничения современных протоколов IGP в части управления трафиком и ресурсами. Этот раздел служит мотивацией для разработки требований к MPLS.

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

Основной целью построения трафика Internet является достижение эффективной и надежной работы сети вкупе с оптимизацией использования сетевых ресурсов и высокой производительностью. TE становится необходимым для множества крупных AS, по причине высокой стоимости сетевых активов, а также коммерциализации и конкуренции в сети Internet. Эти факторы усиливают требование обеспечения максимальной операционной эффективности.

2.1 Цели TE

Ключевые цели повышения производительности, связанные с построением трафика, можно классифицировать, как:

1. ориентированные на трафик;
2. ориентированные на ресурсы.

Ориентированные на трафик цели повышения производительности включают аспекты повышения эффективности QoS для потоков трафика. При одном классе (модель сервиса best effort⁵, принятая в Internet) ориентированные на трафик цели повышения производительности включают: минимизацию потери пакетов, минимизацию задержек, максимизацию пропускной способности, а также выполнение соглашений об уровне обслуживания. В рамках одноклассовой модели обслуживания Internet минимизация потери пакетов является одной из важнейших целей, ориентированных на трафик. Статистические параметры производительности (такие, как вариации задержки, доля теряемых пакетов, максимальная задержка при передаче пакета) могут оказаться более полезными для начинающейся дифференциации услуг Internet.

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

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

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

Для первого случая проблему перегрузок можно решить (i) добавлением ресурсов, (ii) использованием классических механизмов контроля насыщения или (iii) комбинацией этих методов. Классические методы контроля насыщения пытаются урегулировать запросы таким образом, чтобы трафик «вписывался» в доступные ресурсы. Классические методы включают: ограничение скорости, управление окном потока данных, управление очередями в маршрутизаторах, управление на основе планирования, а также другие методы (см. документ [8] и ссылки в нем).

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

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

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

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

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

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

1. изменение параметров управления трафиком;
2. изменение параметров, связанных с маршрутизацией;
3. изменение атрибутов и ограничений, связанных с ресурсами.

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

2.3 Ограничения современных механизмов управления IGP

В этом параграфе рассмотрены некоторые известные ограничения протоколов внутренней маршрутизации (IGP) в части построения трафика.

Возможностей управления, предлагаемых современными протоколами внутренней маршрутизации Internet, недостаточно для TE. Это осложняет реализацию эффективных правил для решения проблем сетевой производительности. Действительно, протоколы IGP, основанные на алгоритмах поиска кратчайшего пути, вносят существенный вклад в возникновение проблем перегрузки в автономных системах Internet. Алгоритмы SPF в общем случае оптимизируются на базе простой аддитивной метрики. Эти протоколы зависят от топологии и характеристики трафика не принимаются во внимание при решении вопросов о выборе маршрута. В результате этого перегрузка зачастую возникает, когда наблюдается любое из приведенных ниже условий:

1. кратчайшие пути для множества потоков трафика сводятся в конкретные каналы или интерфейсы маршрутизаторов;
2. данный поток трафика маршрутизируется через канал или интерфейс маршрутизатора, который не обеспечивает требуемой для потока полосы пропускания.

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

Популярным вариантом преодоления неадекватности современных IGP является использование модели с перекрытием типа IP over ATM или IP over Frame Relay. Модели с перекрытием расширяют возможности организации, разрешая использовать произвольные виртуальные топологии «поверх» топологии физической сети. Виртуальная топология строится из виртуальных устройств, которые выглядят физическими каналами с точки зрения протоколов маршрутизации IGP. Модели с перекрытием дополнительно обеспечивают важные типы сервиса для поддержки управления трафиком и ресурсами, включая: (1) маршрутизацию на базе ограничений⁶ на уровне VC, (2) поддержку административно настраиваемых явных путей VC, (3) компрессию путей, (4) функции управления вызовами, (5) функции формовки трафика, а также (6)выживаемость VC. Эти возможности позволяют реализовать различные правила TE. Например, для виртуальных устройств можно легко изменить маршрутизацию для перемещения трафика с перегруженных ресурсов на относительно свободные.

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

3.0 MPLS и построение трафика

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

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

Замечание по терминологии. В этом документе широко используется понятие транков трафика MPLS. В работе Li и Rekhter [3] транк трафика⁷ определен, как агрегат (объединение) потоков трафика одного класса, который может быть помещен в путь с коммутацией по меткам (LSP⁸). Важно отметить, что транк является абстрактным представлением трафика, с которым могут быть связаны конкретные характеристики. Полезно рассматривать транки, как объекты, которые могут маршрутизироваться (т. е., путь, через который проходит транк, может быть изменен). В этом смысле транки похожи на виртуальные устройства в сетях ATM и Frame Relay. Важно подчеркнуть, что между транками и путями LSP, через которые они проходят существует фундаментальное различие. LSP представляет собой спецификацию пути с коммутацией по меткам, через который проходит транк. На практике же термины LSP и транк трафика часто используются, как синонимы. Дополнительные характеристики транков, используемые в этом документе, приведены в параграфе 5.0.

Привлекательность MPLS для построения трафика можно объяснить несколькими факторами: (1) явные пути с коммутацией по меткам, не привязанные к получателям, как в традиционной парадигме пересылки, легко можно создавать путем административных действий вручную или автоматически с помощью протоколов нижележащих уровней, (2) LSP можно управлять достаточно эффективно, (3) транки трафика можно создавать и отображать на LSP, (4) с транком трафика можно связать набор атрибутов, который позволит изменить характеристики поведения транка, (5) с ресурсами можно связать наборы атрибутов, которые будут ограничивать размещение LSP и транков трафика с использованием этих ресурсов, (6) MPLS разрешает агрегирование и деагрегирование, тогда как классическая парадигма пересылки на базе IP-адреса получателя разрешает только агрегирование, (7) MPLS сравнительно легко интегрируется в модель маршрутизации на базе ограничений, (8) хорошая реализация MPLS может существенно снизить издержки, вносимые конкурирующими решениями для TE.

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

3.1 Индуцированный граф MPLS

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

Индуцированный граф MPLS состоит из набора LSR, которые образуют узлы графа, и набора LSP, обеспечивающих соединения «точка-точка» между LSR и, следовательно, служащих ребрами индуцированного графа. Можно создать иерархию индуцированных графов MPLS на основе концепции стека меток, описанной в [1].

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

Пусть G = (V, E, c) — взвешенный граф, отражающий физическую топологию сети. Здесь V указывает множество узлов сети, а E — набор каналов (т. е., для узлов v и w из множества V объект (v,w) относится к множеству E, если узлы v и w напрямую соединены в рамках G). Параметр c содержит набор значений «емкости» и других ограничительных параметров, связанных с E и V. Будем называть граф G «базовой» топологией сети.

Пусть H = (U, F, d) — индуцированный граф MPLS. Здесь U — подмножество V, представляющее набор LSR в сети (или, более точно, набор LSR, являющихся конечными точками по крайней мере одного LSP). F — множество LSP, в котором для x и y из множества U объект (x, y) относится к множеству F, если существует LSP с конечными точками x и y. Параметр d задает набор потребностей и ограничений, связанных с F. Очевидно, что H является направленным графом. Можно видеть, что H зависит от параметров транзитивности графа G.

3.2 Фундаментальные проблемы организации трафика в MPLS

Существует три фундаментальных проблемы, связанных с TE в MPLS:

• как отображать пакеты в классы эквивалентной пересылки;
• как отображать классы эквивалентной пересылки в транки трафика;
• как отображать транки трафика на физическую топологию сети через пути с коммутацией по меткам.

В этом документе не рассматриваются решения двух первых проблем (хотя они достаточно важны). Вместо этого в оставшейся части документа будут рассмотрены возможности, которые позволят использовать сторонние функции отображения так, чтобы повысить эффективность и надежность работы сетей. Реально решаемой проблемой является отображение индуцированного графа MPLS (H) на «базовую» топологию сети (G).

4.0 Дополнительные возможности построения трафика в MPLS

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

Предлагаемая функциональность включает:

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

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

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

5.0 Атрибуты и характеристики транков

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

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

• транк трафика представляет собой «агрегат» потоков трафика, относящихся к одному классу; в зависимости от контекста может оказаться желательным ослабление этого определения, позволяющее включать в агрегат потоки трафика разных классов;
• в модели с одним классом обслуживания (как в современной сети Internet) транк будет инкапсулировать весь трафик между входным и выходным LSR или подмножество этого трафика;
• транки являются маршрутизируемыми объектами (подобно ATM VC);
• транк отличается от LSP, через который он проходит; в работающей сети транк может переходить с одного пути на другой;
• транк трафика является односторонним.

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

Двумя наиболее значимыми вопросами являются (1) параметризация транков и (2) организация и обслуживание путей для транков.

5.1 Двухсторонние транки

Хотя транки трафика по своей природе являются односторонними, на практике зачастую полезно создавать одновременно два встречных транка между парой конечных точек. Два таких транка объединяются логически. Один транк, называемый прямым (forward), передает трафик от отправителя к получателю. Другой транк, называемый обратным (backward), служит для передачи трафика от получателя к отправителю. Будем называть объединение двух таких транков «двухсторонним транком» (BTT¹⁰) при выполнении двух условий:

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

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

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

5.2 Базовые операции в транках

Ниже перечислены базовые операции на транках трафика, значимые для целей TE.

• Establish (организация) — создание экземпляра транка трафика.
• Activate (активация) — активизация транка для начала передачи трафика. Организация и активация транка логически разделены, но могут быть реализованы или выполнены за одну операцию.
• Deactivate (деактивация) — действие по прекращению передачи через транк.
• Modify Attributes (изменение атрибутов) — действие по изменению атрибутов транка.
• Reroute (перемаршрутизация) — действие по изменению маршрута для транка. Это может быть административная операция или автоматически выполняемое действие протоколов нижележащего уровня.
• Destroy (разрушение) — действие по удалению экземпляра транка из сети и освобождению всех выделенных для него ресурсов (пространство меток и, возможно, полоса каналов).

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

5.3 Учет и мониторинг производительности

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

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

5.4 Базовые TE-атрибуты транков

Атрибутами транков трафика являются параметры, присвоенные транкам и влияющие на их поведение.

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

Наиболее значимые для TE базовые атрибуты транков перечислены ниже:

• атрибут параметров трафика;
• атрибут выбора пути и управления им;
• атрибут приоритета;
• атрибут очередности;
• атрибут гибкости;
• атрибут политики.

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

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

5.5 Атрибуты параметров трафика

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

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

5.6 Атрибуты выбора и поддержки пути

Атрибуты выбора и поддержки пути определяют правила выбора маршрута для транка и поддержки организованных путей.

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

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

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

Для процессов выбора пути и его поддержки требуется набор атрибутов. Базовые атрибуты и характеристики поведения в части выбора и поддержки путей для транков описаны в оставшейся части этого подраздела.

5.6.1 Административно задаваемые явные пути

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

С явно заданными административными средствами путями следует связывать атрибут path preference rule¹¹. Этот атрибут представляет собой двоичную переменную, которая показывает, относится административно заданный путь к обязательным (mandatory) или необязательным (non-mandatory).

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

Однако, если для административно заданного пути установлен атрибут non-mandatory, этот путь следует использовать по возможности, а при отсутствии такой возможности можно воспользоваться альтернативным путем, выбранном нижележащими протоколами.

5.6.2 Иерархия правил предпочтения при множестве путей

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

5.6.3 Атрибуты приемлемости класса ресурсов

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

<resource-class, affinity>; <resource-class, affinity>; ..

Параметр resource-class задает класс ресурсов, для которого определяются отношения приемлемости (т. е., указывает, какие члены класса ресурсов будут включены в путь для транка или исключены из этого пути). Параметр affinity может быть двоичной переменной, принимающей значение для (1) явного включения или (2) явного исключения ресурса.

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

Если атрибуты приемлемости не заданы, используется отношение «не имеет значения» между транком и любыми ресурсами. В этом случае не предъявляется требований по явному включению или явному исключению тех или иных ресурсов для пути транка. На практике по умолчанию следует использовать этот вариант.

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

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

1. для явного включения отвергаются все ресурсы, не относящиеся к заданным классам, до начала расчета пути;
2. для явного исключения отвергаются все ресурсы, относящиеся к заданным классам, до начала расчета пути.

5.6.4 Атрибут адаптивности

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

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

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

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

Реоптимизация отличается от отказоустойчивости. Для задания параметров устойчивости транка трафика к отказам используется другой набор атрибутов (см. параграф 5.9). На практике представляется разумным ждать от транков с реоптимизацией большей устойчивости к отказам в пути. Однако для транков без реоптимизации, чей путь административно задан, как обязательный (mandatory), также может требоваться устойчивость к отказам каналов и узлов пути.

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

5.6.5 Распределение нагрузки между параллельными транками

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

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

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

5.7 Атрибут приоритета

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

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

5.8 Атрибут вытеснения

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

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

С помощью атрибута вытеснения можно установить четыре режима для транков трафика: (1) preemptor enabled, (2) non-preemptor, (3) preemptable и (4) non-preemptable. Транк в режиме preemptor enabled может вытеснять трафик транков с низким приоритетом, помеченных, как preemptable (вытесняемый). Трафик с атрибутом non-preemptable не может быть вытеснен другими транками, независимо от уровней приоритета для этих транков. Транк с атрибутом preemptable может быть вытеснен высокоприоритетными транками с атрибутом preemptor enabled.

Легко видеть, что некоторые из режимов вытеснения являются взаимоисключающими. С учетом приведенной выше нумерации режимов для транков допустимы комбинации атрибутов (1, 3), (1, 4), (2, 3) и (2, 4). По умолчанию следует использовать вариант (2, 4).

Транк A может вытеснить транк B только при выполнении всех 5 приведенных условий: (i) A имеет более высокий приоритет, (ii) A претендует на ресурсы, используемые B, (iii) имеющихся ресурсов недостаточно для одновременного использования транками A и B на основе того или иного деления, (iv) A имеет аттрибут preemptor enabled, (v) B имеет атрибут preemptable.

Атрибут вытеснения Preemption не рассматривается в качестве обязательного для принятой в современной сети Internet модели сервиса best effort, хотя он достаточно полезен. Однако в сценарии с дифференцированием услуг вытеснение становится более востребованным. Кроме того, в некоторых архитектурах межсетевого взаимодействия по оптическим каналам, когда часть функций защиты и восстановления переносится с уровня оптики на уровень сетевого оборудования (гигабитные и терабитные маршрутизаторы с коммутацией по меткам) для снижения расходов, стратегии вытеснения могут служить для снижения времени восстановления высокоприоритетных транков при отказах.

5.9 Атрибут отказоустойчивости

Атрибут отказоустойчивости определяет поведение транка при возникновении отказов на пути транка. В таких обстоятельствах требуется решать три основных задачи: (1) обнаружение отказа, (2) уведомление об отказе, (3) восстановление. Обычно реализации MPLS включают механизмы для решения всех этих задач.

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

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

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

Атрибуты отказоустойчивости предполагают тесное взаимодействие между MPLS и маршрутизацией.

5.10 Атрибут политики

Атрибут политики определяет действия, которые следует выполнять протоколам нижележащих уровней в тех случаях, когда транк трафика перестает соответствовать заданной политике (заданным в контракте параметрам трафика). В общем случае атрибуты политики могут определять для несоответствующего политике трафика ограничение скорости, маркировку или пересылку без выполнения каких-либо действий. При использовании политики для трафика выполнение соответствующих функций может осуществляться за счет адаптации используемых алгоритмов типа ATM Forum GCRA [11].

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

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

6.0 Атрибуты ресурсов

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

6.1 Коэффициент выделения

Атрибут транка MAM¹² для ресурса представляет собой задаваемый административно параметр, который определяет часть ресурса, доступную для выделения этому транку. Этот атрибут применим, прежде всего, в пропускной способности. Однако его можно использовать и для буферных ресурсов LSR. Концепция MAM аналогична концепции подписки и бронирования в сетях Frame Relay и ATM.

Значение MAM можно выбрать так, что при распределении ресурсов может возникнуть их избыток (неполное распределение) или нехватка. Ресурс распределен не полностью, если суммарные потребности всех транков трафика (выраженные в параметрах транков) всегда меньше возможностей этого ресурса. Ресурс распределен с превышением, если суммарные потребности всех транков, которым этот ресурс выделен, превышают возможности ресурса.

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

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

6.2 Атрибут класса ресурсов

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

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

1. применения одинаковых правил к набору ресурсов, которые могут быть топологически разделены;
2. задания относительных предпочтений наборов ресурсов при организации пути транка;
3. явного ограничения размещение транков на указанных подмножествах ресурсов;
4. реализации обобщенных правил включения/исключения ресурсов;
5. реализации политики удержания локального трафика (правил, привязывающих локальный трафик к заданной топологической области сети).

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

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

7.0 Маршрутизация на базе ограничений

В этом разделе рассматриваются вопросы, связанные с маршрутизацией на базе ограничений в доменах MPLS. В современной терминологии маршрутизацию на базе ограничений часто называют QoS Routing¹³ [5,6,7,10].

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

Маршрутизация на базе ограничений обеспечивает сосуществование парадигмы маршрутизации с учетом потребностей и ограниченности ресурсов с протоколами поэтапной внутренней маршрутизации Internet.

При маршрутизации на базе ограничений входными данными для выбора маршрута являются:

• атрибуты, связанные с транками трафика;
• атрибуты, связанные с ресурсами;
• топологическая информация о состоянии сети.

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

Маршрутизация на базе ограничений позволяет существенно снизить объем ручной настройки конфигурации и участие операторов в реализации правил TE.

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

7.1 Базовые функции маршрутизации на основе ограничений

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

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

• сначала отсечь ресурсы, которые не соответствуют требованиям в атрибутах транка;

• использовать алгоритм поиска кратчайшего пути в оставшейся части графа.

    ------------------------------------------
   |           Интерфейс управления           |
    ------------------------------------------
       |                |                  |
 ----------     -----------------    -------------
|    MPLS  |<->|     Процесс     |  |   Обычный   |
|          |   |  маршрутизации  |  | процесс IGP |
 ----------     -----------------    -------------
                    |                     |
      -----------------------    ------------------
     |    База данных о      |  | База данных о    |
     | доступности ресурсов  |  | состоянии каналов|
      -----------------------    ------------------

Рисунок 1. Процесс Constraint-Based Routing в Layer 3 LSR

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

7.2 Вопросы реализации

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

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

1. расширить протоколы IGP (типа OSPF и IS-IS) для поддержки маршрутизации на базе ограничений (такие усилия для протокола OSPF уже предпринимаются [5,7]);
2. добавить процесс маршрутизации на базе ограничений в маршрутизаторы IGP (см . Рисунок 1).

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

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

• механизмы поддержки топологической информации;

• взаимодействие процессов маршрутизации на базе ограничений и IGP;
• механизмы адаптации требований адаптивности транков;
• механизмы адаптации требований отказоустойчивости и жизнестойкости транков.

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

8.0 Заключение

В этом документе представлен набор требований для TE в MPLS. Описано множество возможностей повышения уровня применимости MPLS к построению трафика в Internet.

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

9.0 Вопросы безопасности

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

10.0 Литература

[1] Rosen, E., Viswanathan, A. and R. Callon, «A Proposed Architecture for MPLS», Work in Progress¹⁴.

[2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G. and A. Viswanathan, «A Framework for Multiprotocol Label Switching», Work in Progress¹⁵.

[3] Li, T. and Y. Rekhter, «Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)», RFC 2430, October 1998.

[4] Rekhter, Y., Davie, B., Katz, D., Rosen, E. and G. Swallow, «Cisco Systems’ Tag Switching Architecture — Overview», RFC 2105, February 1997.

[5] Zhang, Z., Sanchez, C., Salkewicz, B. and E. Crawley «Quality of Service Extensions to OSPF», Work in Progress¹⁶.

[6] Crawley, E., Nair, F., Rajagopalan, B. and H. Sandick, «A Framework for QoS Based Routing in the Internet», RFC 2386, August 1998.

[7] Guerin, R., Kamat, S., Orda, A., Przygienda, T. and D. Williams, «QoS Routing Mechanisms and OSPF Extensions», RFC 2676, August 1999.

[8] C. Yang and A. Reddy, «A Taxonomy for Congestion Control Algorithms in Packet Switching Networks,» IEEE Network Magazine, Volume 9, Number 5, July/August 1995.

[9] W. Lee, M. Hluchyi, and P. Humblet, «Routing Subject to Quality of Service Constraints in Integrated Communication Networks,» IEEE Network, July 1995, pp 46-55.

[10] ATM Forum, «Traffic Management Specification: Version 4.0» April 1996.

11.0 Благодарности

Авторы благодарят Yakov Rekhter за просмотр черновых вариантов документа. Авторы также выражают свою благодарность Louis Mamakos и Bill Barns за внесенные предложения и Curtis Villamizar за полезные отклики.

12.0 Адреса авторов

Daniel O. Awduche

UUNET (MCI Worldcom)

3060 Williams Drive

Fairfax, VA 22031

Phone: +1 703-208-5277

EMail: awduche@uu.net

Joe Malcolm

UUNET (MCI Worldcom)

3060 Williams Drive

Fairfax, VA 22031

Phone: +1 703-206-5895

EMail: jmalcolm@uu.net

 

Johnson Agogbua

UUNET (MCI Worldcom)

3060 Williams Drive

Fairfax, VA 22031

Phone: +1 703-206-5794

EMail: ja@uu.net

 

Mike O’Dell

UUNET (MCI Worldcom)

3060 Williams Drive

Fairfax, VA 22031

Phone: +1 703-206-5890

EMail: mo@uu.net

 

Jim McManus

UUNET (MCI Worldcom)

3060 Williams Drive

Fairfax, VA 22031

Phone: +1 703-206-5607

EMail: jmcmanus@uu.net

---

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

13.0 Полное заявление авторских прав

Copyright (C) The Internet Society (1999). Все права защищены.

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

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.