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. Эта функциональность может послужить для оптимизации использования сетевых ресурсов и повышения производительности ориентированных на трафик систем.

Оглавление

Исключено из версии HTML

1.0 Введение

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

С помощью этой сравнительно простой парадигмы можно разработать набор мощных конструкций для решения множества вопросов в части дифференциации услуг Internet. Одним из наиболее значимых стартовых приложений MPLS будет построение трафика (TE2). Важность этого приложение уже достаточно очевидна (см. [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 рассматривается схема основанной на ограничениях маршрутизации3 в доменах MPLS, а раздел 8 содержит заключительные ремарки.

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

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

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

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

2.1 Цели TE

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

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

Ориентированные на трафик цели повышения производительности включают аспекты повышения эффективности QoS для потоков трафика. При одном классе (модель сервиса best effort5, принятая в 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) маршрутизацию на базе ограничений6 на уровне VC, (2) поддержку административно настраиваемых явных путей VC, (3) компрессию путей, (4) функции управления вызовами, (5) функции формовки трафика, а также (6)выживаемость VC. Эти возможности позволяют реализовать различные правила TE. Например, для виртуальных устройств можно легко изменить маршрутизацию для перемещения трафика с перегруженных ресурсов на относительно свободные.

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

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

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

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

Замечание по терминологии. В этом документе широко используется понятие транков трафика MPLS. В работе Li и Rekhter [3] транк трафика7 определен, как агрегат (объединение) потоков трафика одного класса, который может быть помещен в путь с коммутацией по меткам (LSP8). Важно отметить, что транк является абстрактным представлением трафика, с которым могут быть связаны конкретные характеристики. Полезно рассматривать транки, как объекты, которые могут маршрутизироваться (т. е., путь, через который проходит транк, может быть изменен). В этом смысле транки похожи на виртуальные устройства в сетях 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

В этом параграфе вводится концепция индуцированного графа MPLS9, который является важным элементом 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), служит для передачи трафика от получателя к отправителю. Будем называть объединение двух таких транков «двухсторонним транком» (BTT10) при выполнении двух условий:

  • оба транка организуются в одной операции на одном 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 rule11. Этот атрибут представляет собой двоичную переменную, которая показывает, относится административно заданный путь к обязательным (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 Коэффициент выделения

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

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

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

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

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

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

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

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

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

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

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

В этом разделе рассматриваются вопросы, связанные с маршрутизацией на базе ограничений в доменах MPLS. В современной терминологии маршрутизацию на базе ограничений часто называют QoS Routing13 [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 Progress14.

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

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

[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). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

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

1Multiprotocol Label Switching.

2Traffic Engineering.

3Constraint-based routing.

4Autonomous System.

5Наилучшее обслуживание с учетом возможностей.

6Constraint-based routing.

7Далее для краткости будет использоваться термин «транк», если это не будет приводить к неоднозначности. Прим. перев.

8Label Switched Path.

9Induced MPLS graph.

10Bidirectional traffic trunk.

11Правило предпочтения пути.

12Maximum allocation multiplier.

13Маршрутизация по качеству обслуживания.

14Работа завершена и опубликована в RFC 3031.

15Работа над этим документом не была завершена. Последний черновой вариант доступен по ссылке http://tools.ietf.org/id/draft-ietf-mpls-framework. Прим. перев.

16Работа над этим документом не была завершена. Последний черновой вариант доступен по ссылке http://tools.ietf.org/id/draft-zhang-qos-ospf. Прим. перев.




RFC 2685 Virtual Private Networks Identifier

Network Working Group                                         B. Fox
Request for Comments: 2685                       Lucent Technologies
Category: Standards Track                                 B. Gleeson
                                                     Nortel Networks
                                                      September 1999

Идентификатор виртуальной частной сети (VPN)

Virtual Private Networks Identifier

PDF

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

Данный документ содержит спецификацию протокола, предложенного сообществу Internet, и служит запросом к дискуссии в целях развития протокола. Информацию о статусе данного протокола можно найти в текущей редакции документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться свободно.

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

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

Тезисы

Виртуальные частные сети IP могут покрывать множество автономных систем (AS) или сетей сервис-провайдеров (SP). Это порождает требование использования уникальных в глобальном масштабе идентификаторов VPN, которые позволят определить конкретные VPN (см. параграф 6.1.1 в документе [1]). В данном документе предложен формат уникального в глобальном масштабе идентификатора VPN.

1. Введение

По мере расширения публичной сети Internet и глобального расширения сетевой инфраструктуры существенно возрос интерес в виртуальным частным сетям (VPN1) на основе IP. VPN эмулирует частную сеть IP через публичные или разделяемые инфраструктуры. Сети VPN обеспечивают ряд преимуществ как для сервис-провайдеров, так и для их заказчиков. Для заказчиков VPN позволяет включить в единую сеть IP удаленные офисы и отдельных пользователей подключаемых к сети разными способами. Подключение к сети в каждом случае может осуществляться наиболее экономичным способом и это позволяет снизить расходы заказчика на оборудование, услуги и поддержку. Сервис-провайдеры могут повысить эффективность использования своей инфраструктуры, предлагая своим заказчикам подключение и/или услуги IP VPN.

Существует множество способов реализации услуг IP VPN. В базовом документе по таким сетям [1] выделены четыре типа поддерживаемых VPN: виртуальные выделенные линии (VLL2), виртуальные частные маршрутизируемые сети (VPRN3), виртуальные частные сети с коммутируемым доступом (VPDN4) и сегменты виртуальных частных ЛВС (VPLS5). В дополнение к упомянутому документу во множестве проектов спецификация описаны методы, которые могут использоваться сервис-провайдерами и/или их заказчиками для организации сервиса VPN. Решения могут выбираться для отдельных заказчиков или сети в целом. Сетевые решения могут обеспечивать подключение и услуги уровня 2 и/или 3. Устройствами, вовлеченными в реализацию решения могут быть оборудование заказчика (CPE6), оконечное оборудование сервис-провайдера (SPE7), и оборудование ядра сети сервис-провайдера, а также комбинации этих устройств.

Хотя различные методы реализации сервиса VPN еще будут обсуждаться, существуют два пункта, по которым имеется согласие:

поскольку VPN является частной сетью, в ней могут использоваться блоки адресов, которые могут перекрываться с блоками других VPN или публичной сети Internet;

VPN может простираться через множество автономных систем (AS) IP или сервис-провайдеров.

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

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

2. Глобальный идентификатор VPN

Задачей VPN-ID является идентификация VPN. Этот идентификатор может использоваться разными способами в зависимости от метода реализации сервиса VPN. Например, VPN-ID может быть включен:

  • в базу MIB для конфигурирования атрибутов VPN или выделения физического или логического интерфейса доступа для конкретной VPN;
  • в пакет данных управления для идентификации «зоны действия» приватного адреса IP и VPN, к которой относятся данные.

Необходимо обеспечить возможность идентификации VPN, с которой связан пакет данных. Идентификатор VPN-ID может использоваться для решения этой задачи явно (например, путем включения VPN-ID в заголовок инкапсуляции [2]) или неявно (например, путем включения VPN-ID в сигнальный обмен ATM [3]). Приемлемость использования VPN-ID в других вариантах контекста требует внимательного изучения.

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

Эти функции требуют глобальной зоны действия идентификатора VPN и возможности его использования в разных решениях. Для того, чтобы идентификатор VPN был уникальным в глобальном масштабе, формат идентификатора не должен основываться на каких-либо допущениях о разделяемой сети (сетях). И наоборот, формат не следует определять таким образом, чтобы возникали ограничения на использование возможностей разделяемой сети (сетей). Необходимо отметить, что одна и та же VPN может идентифицироваться на разных уровнях одной разделяемой сети (например, на уровнях ATM и IP). Для обоих уровнях следует в таких случаях использовать общее значение и формат VPN-ID.

Методы использования VPN-ID выходят за пределы данного документа.

3. Требования к формату глобального идентификатора VPN

К формату идентификатора VPN следует предъявлять перечисленные здесь требования:

  • значение идентификатора VPN должно быть уникальным и используемым в сетях разных сервис-провайдеров;
  • должны поддерживаться не связанные с IP идентификаторы VPN-ID для использования в VPN канального уровня.
  • VPN-ID должен идентифицировать VPN Authority.

4. Формат глобального идентификатора VPN

Глобальный идентификатор VPN включает

3-октетный идентификатор агентства VPN (VPN OUI8) [4]

за которым следует

4-октетный индекс VPN (VPN Index), идентифицирующий VPN в рамках OUI

   0 1 2 3 4 5 6 7 8
   +-+-+-+-+-+-+-+-+
   | VPN OUI (MSB) |
   +-+-+-+-+-+-+-+-+
   |   VPN OUI     |
   +-+-+-+-+-+-+-+-+
   | VPN OUI (LSB) |
   +-+-+-+-+-+-+-+-+
   |VPN Index (MSB)|
   +-+-+-+-+-+-+-+-+
   |  VPN Index    |
   +-+-+-+-+-+-+-+-+
   |  VPN Index    |
   +-+-+-+-+-+-+-+-+
   |VPN Index (LSB)|
   +-+-+-+-+-+-+-+-+

VPN OUI (IEEE 802-1990 Organizationally Unique Identifier) [4] идентифицирует Агентство VPN. Этот орган будет являться основным администратором VPN. Агентством может быть компания/организация, к которой относится VPN, или сервис-провайдер, обеспечивающий инфраструктуру VPN с использованием своей (или других сервис-провайдеров) разделяемой сети. 4-октетный индекс VPN идентифицирует отдельную VPN, обслуживаемую агентством VPN.

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

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

6. Литература

[1] Gleeson, Heinanen, Lin, Armitage, Malis, «A Framework for IP Based Virtual Private Networks», Work in Progress9.

[2] Grossman, D. and J. Heinanen, «Multiprotocol Encapsulation over ATM Adaptation Layer 5», RFC 2684, September 1999.

[3] «MPOA v1.1 Addendum on VPN Support», ATM Forum, af-mpoa-0129.000, August, 1999, Bernhard Petri, editor, final ballot document.

[4] http://standards.ieee.org/regauth/oui/index.html

7. Адреса авторов

Barbara A. Fox

Lucent Technologies

300 Baker Ave, Suite 100

Concord, MA 01742-2168

Phone: +1-978-287-2843

EMail: barbarafox@lucent.com

 

Bryan Gleeson

Nortel Networks

4500 Great America Parkway,

Santa Clara, CA 95054

Phone: +1-408-855-3711

EMail: bgleeson@shastanets.com


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

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

nmalykh@protocols.ru

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

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

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

1Virtual Private Network

2Virtual Leased Line

3Virtual Private Routed Network

4Virtual Private Dial Network

5Virtual Private LAN Segment

6Customer Premises Equipment

7Service Provider Edge

8Organizationally Unique Identifier — уникальный идентификатор организации.

9Работа завершена и опубликована в RFC 2764. Прим. перев.




RFC 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5

Network Working Group                                    D. Grossman
Request for Comments: 2684                            Motorola, Inc.
Obsoletes: 1483                                          J. Heinanen
Category: Standards Track                                      Telia
                                                      September 1999

 

Многопротокольная инкапсуляция с использованием AAL.5

Multiprotocol Encapsulation over ATM Adaptation Layer 5

PDF

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

Данный документ содержит спецификацию протокола, предложенного сообществу Internet, и служит запросом к дискуссии в целях развития протокола. Информацию о статусе данного протокола можно найти в текущей редакции документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться свободно.

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

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

Тезисы

Этот документ заменяет RFC 1483. Документ описывает два метода инкапсуляции при передаче межсетевого трафика с использованием AAL типа 5 по сети ATM. Первый метод позволяет мультиплексировать множество протоколов через одно виртуальное соединение ATM, а во втором методе предполагается наличие отдельного виртуального соединения ATM для каждого из протоколов.

Применимость

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

1. Введение

Глобальные, кампусные и локальные сети ATM используются для доставки дейтаграмм IP и другого трафика, не требующего организации соединений, между хостами, маршрутизаторами, мостами и другими сетевыми устройствами. В данном документе описываются два метода транспортировки протокольных модулей данных PDU, не требующих организации соединений и использующих маршрутизацию или мосты, через сети ATM. Метод инкапсуляции LLC (LLC Encapsulation) позволяет мультиплексировать множество протоколов через одно виртуальное соединение ATM (VC). Тип протокола для каждого PDU идентифицируется заголовком уровня управления логическим каналом — IEEE 802.2 LLC. При использовании метода мультиплексирования виртуальных соединений (VC Multiplexing) каждое из виртуальных соединений ATM VC служит для передачи PDU только одного протокола. При необходимости транспортировки множества протоколов для каждого из них организуется отдельное виртуальное соединение.

В сетях ATM для передачи данных используются блоки размером 53 октета, которые называют ячейками. Каждая ячейка содержит заголовок размером 5 октетов и 48 октетов информации (payload). PDU переменной длины (включая и описываемые в настоящем документе) должны быть сегментированы для размещения в 48-байтовых информационных полях ячеек ATM. На приемной стороне должна обеспечиваться обратная операция по сборке сегментированных пакетов. В данном документе описывается использование для решения этой задачи уровня адаптации AAL5 (ATM Adaptation Layer type 5) в соответствии с рекомендациями ITU-T (I.363.5 [2]). PDU переменной длины передаются в полях Payload ячеек подуровня AAL5 Common Part Convergence (CPCS).

Данный документ описывает только передачу PDU, требующих маршрутизации или организации мостов, непосредственно через AAL5 CPCS (т. е., подуровень SSCS1 AAL5 отсутствует). Если поверх CPCS используется подуровень FR-SSCS (Frame Relay Service Specific Convergence Sublayer), описанный в рекомендациях ITU-T (I.365.1 [3]), PDU, требующие маршрутизации или организации мостов, передаются с использованием мультиплексирования NLPID, описанного в RFC 2427 [4]. Инкапсуляция RFC 2427 должна использоваться в тех случаях, когда применяется Frame Relay Network Interworking или Service Interworking в прозрачном режиме [9]; не рекомендуется использовать такую инкапсуляцию для других приложений. В Приложении A (исключительно с информационной целью) описан формат FR-SSCS-PDU для случаев инкапсуляции пакетов IP и CLNP в FR-SSCS в соответствии с RFC 2427.

Данный документ описывает также инкапсуляцию для использования с VPN, работающими на базе подсети ATM.

Если вы хотите использовать возможности протокола PPP и существуют прямые (точка-точка) связи между системами одного уровня (peer systems), обратитесь к RFC 2364, где содержится информация, применимая к таким задачам.

2. Соглашения

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

3. Выбор метода мультиплексирования

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

Когда оконечные системы ATM хотят обмениваться PDU без организации соединений через ATM PVC2, выбор метода мультиплексирования задается конфигурацией. При использовании коммутируемых виртуальных соединений ATM (SVC) для согласования метода инкапсуляции служат сигнальные процедуры управления соединениями ATM. Процедуры согласования описаны в документах [5] и [8].

4. Формат AAL5 PDU

Для обоих вариантов мультиплексирования PDU, требующие маршрутизации или организации мостов, должны инкапсулироваться в поля Payload пакетов AAL5 CPCS-PDU.

Рекомендации ITU-T I.363.5 [2] содержат полное определение формата AAL5 PDU и описание процедур приема и передачи. Должен использоваться сервис режима сообщений AAL5 (message mode service) без обеспечения гарантий (non-assured). Использование опции corrupted delivery (доставка при повреждении) является недопустимым. Может использоваться таймер сборки ячеек (reassembly timer). Ниже приведено описание формата AAL5 CPCS-PDU.

.
.
CPCS-PDU Payload до 216 — 1 октетов (65535)
.
.

PAD (заполнение) — 0 — 47 октетов

CPCS-UU — 1 октет

Трейлер

CPCS-PDU

CPI — 1 октет

Длина — 2 октета

CRC — 4 октета

Поле Payload содержит пользовательскую информацию и может иметь размер до 216 — 1 октетов.

Поле PAD (заполнение) служит для выравнивания CPCS-PDU по границе ячеек ATM так, чтобы последнее 48-октетное поле, создаваемое подуровнем SAR (фрагментация и сборка пакетов) совпадало с границей трейлера CPCS-PDU.

Поле CPCS-UU (индикация пользователь-пользователь) служит для прозрачной передачи информации CPCS между пользователями. Это поле не используется при мультипротокольной инкапсуляции ATM, описываемой в данном документе, и может иметь любое значение.

Поле CPI (Common Part Indicator — индикатор общей части) выравнивает трейлер CPCS-PDU по 64-битовой границе. Поле должно иметь значение 0x00.

Поле Length (длина) указывает размер поля Payload в октетах. Максимальное значение этого поля составляет 65535. Значение Length = 0x00 используется в качестве функции прерывания.

Поле CRC (контрольная сумма) служит для обнаружения ошибок в CPCS-PDU с помощью алгоритма CRC-32.

5. Инкапсуляция LLC

Инкапсуляция LLC нужна в тех случаях, когда требуется передача множества протоколов с использованием одного виртуального соединения (VC). Для того, чтобы на приемной стороне была возможность корректной обработки входящих AAL5 CPCS-PDU, поле Payload содержит информацию, обеспечивающую идентификацию протокола PDU, для которого нужна маршрутизация или организация моста. При инкапсуляции LLC эта информация должна содержаться в заголовке LLC, размещаемом в начале передаваемого пакета PDU.

Хотя в настоящем документе рассматриваются лишь протоколы, работающие поверх LLC типа 1 (режим без организации соединений и передачи подтверждений), такие же принципы инкапсуляции применимы и для протоколов, работающих поверх LLC типа 2 (с организацией соединений). В последнем случае формат и содержание заголовков LLC должно соответствовать требованиям стандартов IEEE 802.1 и IEEE 802.2.

5.1. LLC-инкапсуляция для маршрутизируемых протоколов

При использовании инкапсуляции LLC тип протоколов PDU, для которых нужна маршрутизация или организация мостов, должен указываться с помощью префиксов заголовка IEEE 802.2 LLC для каждого PDU. В некоторых случаях вслед за заголовком LLC должен размещаться заголовок IEEE 802.1a SNAP (SubNetwork Attachment Point). При работе с LLC типа 1 заголовок LLC должен содержать три 1-октетных поля:

DSAP

SSAP

Control

При инкапсуляции LLC для маршрутизируемых протоколов поле Control должно иметь значение 0x03, указывающее на UI (Unnumbered Information) Command PDU.

Значение заголовка LLC 0xFE-FE-03 должно использоваться для идентификации маршрутизируемых PDU в формате ISO NLPID (см. [6] и Приложение B). Для NLPID-форматируемых и маршрутизируемых PDU поле Payload в AAL5 CPCS-PDU должно иметь следующий формат:

LLC 0xFE-FE-03

NLPID (1 октет)

.
PDU (до 216 — 4 октетов)
.

Маршрутизируемые протоколы должны идентифицироваться 1-октетным полем NLPID, которое является частью протокольных данных (Protocol Data). Значения NLPID выделяются ISO и ITU-T. Текущие значения идентификаторов определены в документе ISO/IEC TR 9577 [6], некоторые из этих значений приведены в Приложении C.

Значение NLPID = 0x00 определено в ISO/IEC TR 9577 как Null Network Layer или Inactive Set. Поскольку это значение не имеет смысла в контексте данной схемы инкапсуляции, использование NLPID = 0x00 недопустимо.

Хотя существует значение NLPID (0xCC) для индикации протокола IP, формат NLPID недопустимо использовать для IP. Вместо этого дейтаграммы IP должны указываться заголовком SNAP, описанным ниже.

Присутствие заголовка IEEE 802.1a SNAP обозначается заголовком LLC = 0xAA-AA-03. Заголовок SNAP имеет форму:

OUI

PID

Заголовок SNAP содержит 3-октетный идентификатор организации OUI (Organizationally Unique Identifier) и 2-октетный идентификатор протокола PID. Значения OUI выдаются IEEE и идентифицируют организацию, которая администрирует значения PID. Таким образом, заголовок SNAP обеспечивает уникальную идентификацию для протоколов маршрутизации и мостов. Значение OUI = 0x00-00-00 показывает, что поле PID содержит значение EtherType.

Формат поля Payload для AAL5 CPCS-PDU маршрутизируемых протоколов, не относящихся к NLPID, показан ниже.

LLC 0xAA-AA-03

OUI 0x00-00-00

EtherType (2 октета)

.
PDU с отличным от NLPID форматом (до 216 — 9 октетов)
.

Для частного случая IPv4 PDU значение Ethertype = 0x08-00 и поле Payload должно использовать формат:

LLC 0xAA-AA-03

OUI 0x00-00-00

EtherType 0x08-00

.
IPv4 PDU (до 216 — 9 октетов)
.

Этот формат согласуется с определением RFC 1042 [7].

5.2. Инкапсуляция LLC для Bridged-протоколов

При использовании инкапсуляции LLC PDU, требующие организации мостов, инкапсулируются путем идентификации bridged-среды в заголовке SNAP. Присутствие заголовка SNAP должно указываться с помощью заголовка LLC = 0xAA-AA-03. Значение OUI в заголовке SNAP должно быть кодом организации для 802.1 (0x00-80-C2). Тип bridged-среды должен задаваться 2-октетным значением PID. Поле PID должно также говорить о реальном присутствии контрольной суммы FCS (Frame Check Sequence) в передаваемом через мосты PDU. В Приложении B приведен список типов сред (значений PID), которые могут использоваться при ATM-инкапсуляции.

Поле Payload в AAL5 CPCS-PDU, служащее для переноса PDU, требующих организации мостов, должно использовать один из рассмотренных ниже форматов. После поля PID должны быть добавлены октеты заполнения для выравнивания полей Ethernet/802.3 LLC Data, 802.4 Data Unit, 802.5 Info, FDDI Info или 802.6 Info передаваемого через мосты PDU по 4-октетной границе. Порядок битов MAC-адреса должен быть такой же, какой используется в ЛВС или MAN (например, канонический для Ethernet/IEEE 802.3 PDU или 802.5/FDDI для 802.5 PDU).

Формат для пакетов Bridged Ethernet/802.3 PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-01 или 0x00-07

PAD 0x00-00

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-01)

Физический уровень Ethernet/802.3 требует заполнения кадров до минимального размера. Мост, который использует формат инкапсуляции Bridged Ethernet/802.3 с сохраненным полем LAN FCS, должен включать заполнение. Мост, который использует формат инкапсуляции Bridged Ethernet/802.3 без сохранения контрольной суммы LAN FCS может не включать битов заполнения. Когда мост принимает кадр в таком формате без контрольной суммы LAN FCS, он должен вставить требуемые биты заполнения (если их нет) до передачи кадра в подсеть Ethernet/802.3 .

Формат Payload для пакетов Bridged 802.4 PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-02 или 0x00-08

PAD 0x00-00-00

Frame Control (1 октет)

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-02)

Формат поля Payload для пакетов Bridged 802.5 PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-03 или 0x00-09

PAD 0x00-00-XX

Frame Control (1 октет)

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-03)

Поскольку поле управления доступом 802.5 AC не имеет значения за пределами локальной подсети 802.5, это поле трактуется при данном способе инкапсуляции как последний октет 3-октетного поля заполнения PAD. Это поле может иметь любое значение (устанавливает передающий мост), а принимающий мост должен просто игнорировать значение данного поля.

Формат поля Payload для пакетов Bridged FDDI PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-04 или 0x00-0A

PAD 0x00-00-00

Frame Control (1 октет)

MAC-адрес получателя

(остальная часть кадра MAC)

LAN FCS (если PID = 0x00-04)

Формат поля Payload для пакетов Bridged 802.6 PDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-0B

Резервное поле

BEtag

Общий заголовок PDU

BAsize

MAC-адрес получателя

(остальная часть кадра MAC)

Общий трейлер PDU

В передаваемых с использованием мостов пакетов 802.6 PDU присутствие поля CRC-32 указывается битом CIB в заголовке кадра MAC. Следовательно, во всех случаях используется одно значение PID (независимо от присутствия контрольной суммы CRC-32 в PDU).

Заголовок и трейлер Common PDU передаются для того, чтобы обеспечить возможность организации конвейерной обработки (pipelining) на мосту, являющемся выходом в подсеть 802.6. В частности, заголовок Common PDU содержит поле BAsize, в котором указан размер PDU. Если это поле недоступно выходному мосту 802.6, этот мост не сможет начать передачу сегментированного PDU до тех пор, пока PDU не будет принят полностью, рассчитан его размер и значение размера не будет помещено в поле BAsize. Если данное поле доступно, выходной мост 802.6 может определить размер пакета из поля BAsize в заголовке Common PDU, вставить это значение в соответствующее поле первого сегмента и незамедлительно начать передачу сегмента в подсеть 802.6. Таким образом, мост может начать передачу пакета 802.6 PDU до того, как будет завершен прием всего PDU.

Отметим, что заголовок и трейлер Common PDU Header инкапсулируемого кадра не должны просто копироваться в выходную (outgoing) подсеть 802.6, поскольку инкапсулированное значение BEtag может конфликтовать с предыдущим значением Betag, переданным этим мостом.

Входной мост 802.6 может прервать пакет AAL5 CPCS-PDU, установив Length=0. Если выходной мост уже начал передачу сегментов этого PDU в подсеть 802.6, этому мосту передается уведомление о том, что передача AAL5 CPCS-PDU прервана — в результате может быть незамедлительно сгенерирована ячейка EOM, приводящая к отказу от 802.6 PDU на принимающем мосту. Такая ячейка EOM может, к примеру, содержать некорректное значение поля Length в трейлере Common PDU .

Формат поля Payload для пакетов BPDU

LLC 0xAA-AA-03

OUI 0x00-80-C2

PID 0x00-0E

6. Мультиплексирование VC

При мультиплексировании виртуальных соединений VC организуются ассоциации между ATM VC и типом сетевого протокола, передаваемого с помощью этого VC. Таким образом, в данной ситуации не нужно передавать информацию для идентификации протокола в информационном поле каждого AAL5 CPCS-PDU. Это снижает объем служебной информации (overhead) и упрощает обработку пакетов. Мультиплексирование VC может повысить эффективность передачи пакетов за счет снижения числа ячеек, требуемых для передачи PDU определенной длины.

Для ATM PVC тип протокола, передаваемого через каждое постоянное соединение (PVC), должен задаваться конфигурацией. Для коммутируемых соединений ATM SVC должно использоваться согласование на основе RFC 1755 [5].

6.1. VC-мультиплексирование для маршрутизируемых протоколов

PDU маршрутизируемых протоколов должны передаваться только как содержимое информационных полей (Payload) пакетов AAL5 CPCS-PDU. Формат поля Payload пакетов AAL5 CPCS-PDU рассмотрен ниже.

Формат поля Payload для маршрутизируемых PDU

.
Передаваемый пакет PDU (до 216 — 1 октетов)
.

6.2. VC-мультиплексирование для Bridged-протоколов

PDU для протоколов, использующих мосты, должны передаваться в поле Payload пакетов AAL5 CPCS-PDU в точности так же, как было описано в параграфе 5.2. Единственным отличием является то, что после PID должно включаться только одно поле. Поля Payload для пакетов AAL5 CPCS-PDU при передаче трафика с использованием мостов должны, следовательно, использовать приведенные ниже форматы.

Формат поля Payload для пакетов Bridged Ethernet/802.3 PDU

PAD 0x00-00

MAC-адрес получателя


(остальная часть кадра MAC)

LAN FCS (зависит от VC)

Формат поля Payload для пакетов Bridged 802.4/802.5/FDDI PDU

PAD 0x00-00-00 или 0x00-00-XX

Frame Control (1 октет)

MAC-адрес получателя


(остальная часть кадра MAC)

LAN FCS (зависит от VC)

Отметим, что поле 802.5 AC (Access Control — управление доступом) не имеет смысла за пределами локальной подсети 802.5. Это касается последнего октета 3-байтового поля PAD, которое для кадров 802.5 может принимать любое значение (XX).

Формат поля Payload для пакетов Bridged 802.6 PDU

Резервное поле

BEtag

Общий заголовок PDU

BAsize

MAC-адрес получателя

(остальная часть кадра MAC)

Общий трейлер PDU

Формат поля Payload для пакетов BPDU

BPDU в соответствии

с 802.1(d) или 802.1(g)

Для пакетов Ethernet, 802.3, 802.4, 802.5 и FDDI наличие или отсутствие завершающего поля LAN FCS должно явно указываться VC, поскольку поле PID не включается. Пакеты PDU с LAN FCS и PDU без LAN FCS рассматриваются как относящиеся к различным протоколам, даже если тип сред, для которых организуется мост, совпадает.

7. Организация мостов в сетях ATM

Мост с интерфейсом ATM, служащий в качестве канала связи с одним или несколькими мостами, должен быть способен фильтровать, пересылать и распространять всем (flood) пакеты PDU, пересылаемые через мост.

Лавинная маршрутизация (Flooding) выполняется путем передачи PDU по всем возможным и приемлемым адресам. В среде ATM это означает, что PDU будет передаваться через все, относящиеся к делу VC. Это может выполняться путем явного копирования пакета в каждое соединение VC или за счет организации виртуальных соединений “один со многими” (point-to-multipoint VC).

Для пересылки PDU мост должен быть способен связать MAC-адрес получателя с VC. Неразумно (а в некоторых случаях — невозможно) требовать статической настройки мостов для создания ассоциаций между всеми возможными MAC-адресами получателей и VC. Следовательно, мосты ATM должны предоставлять достаточную информацию для того, чтобы интерфейс ATM мог динамически определять такие ассоциации.

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

8. Идентификация VPN

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

Механизм глобальной идентификации многопротокольных VPN описан в документе [11]. Семиоктетное поле VPN-Id содержит 3-октетный идентификатор OUI (IEEE 802-1990 Organizationally Unique Identifier), связанный с VPN, за которым следует 4-октетный индекс VPN, связанный с владельцем VPN-related OUI. Обычно значения VPN-related OUI предоставляются поставщикам услуг VPN, которые выделяют индексы VPN своим заказчикам.

8.1 Заголовок инкапсуляции VPN

Форматы заголовков VPN-инкапсуляции рассмотрены ниже:

Заголовок инкапсуляции VPN

LLC 0xAA-AA-03

OUI 0x00-00-5E

PID 0x00-08

PAD 0x00

VPN related OUI (3 октета)

VPN Index (4 октета)

(остальная часть PDU)

При использовании заголовка инкапсуляции остальная часть PDU должна быть структурирована в соответствии с приемлемым форматом из числа описанных в параграфах 5 и 6 (т.е. заголовок инкапсуляции VPN предшествует PDU в пакете AAL5 CPCS SDU).

8.2 Маршрутизация и мосты для PDU с LLC-инкапсуляцией в VPN

Когда пакеты с LLC-инкапсуляцией передаются с использованием маршрутизации или мостов внутри VPN, использующей ATM поверх AAL5, заголовок инкапсуляции VPN должен предшествовать заголовку соответствующего формата PDU для маршрутизации или мостов (см. параграф 5.1 и 5.2).

8.3 Мультиплексирование VC для PDU внутри VPN

При передаче PDU, использующих маршрутизацию или мосты, внутри VPN с мультиплексированием VC идентификатор VPN может быть указан заранее с использованием сигнализации управления соединениями ATM или административного присваивания для интерфейса ATM; можно указывать идентификатор VPN и c использованием заголовка инкапсуляции.

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

Если идентификаторы VPN административно выделяются для интерфейса ATM, все PDU, передаваемые через любые ATM VC на одном интерфейсе, оказываются связанными с одной VPN. В этом случае формат информационных полей PDU с использованием маршрутизации или мостов должен соответствовать описаниям, приведенным в параграфах 6.1 и 6.2. Если принимаемый PDU содержит заголовок инкапсуляции VPN при административном распределении идентификаторов VPN, принимающая сторона может отбросить такие пакеты и/или выполнить по отношению к ним иные действия (в зависимости от реализации). Рассмотрение механизмов (таких как MIB) распределения идентификаторов VPN на интерфейсах ATM выходит за пределы настоящего документа.

Если идентификатор VPN указывается с использованием заголовка инкапсуляции, заголовок инкапсуляции VPN должен предшествовать PDU для маршрутизации или мостов с соответствующим форматом (см. параграфы 6.1 и 6.2).

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

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

На безопасность системы могут оказывать влияние и свойства нижележащих уровней ATM. ATM Forum публикует материалы по безопасности, в которых можно найти информацию, связанную с инкапсуляцией ([12], [13]).

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

Этот документ заменяет RFC 1483, разработанный группой IP over ATM и подготовленный Juha Heinanen (в то время Telecom Finland, сейчас — Telia). Данный документ был создан в рабочей группе IP-over-NBMA (ION) и Dan Grossman (Motorola) — один из авторов — принимал участие и в разработке RFC 1483.

В данном документе содержатся переработанные материалы из других RFC ([1] и [4]). Спасибо авторам этих документов — Terry Bradley, Caralyn Brown, Andy Malis, Dave Piscitello и C. Lawrence. Важный вклад в работу внесли Carpenter (CERN), Rao Cherukuri (IBM), Joel Halpern (в тот момент Network Systems), Bob Hinden (Sun Microsystems, сейчас — Nokia) и Gary Kessler (MAN Technology).

Материалы, связанные с VPN, подготовили Barbara Fox (Lucent) и Bernhard Petri (Siemens).

Литература

[1] Piscitello, D. и C. Lawrence, «The Transmission of IP Datagrams over the SMDS Service», RFC 1209, март 1991.

[2] ITU-T Recommendation I.363.5, «B-ISDN ATM Adaptation Layer (AAL) Type 5 Specification», август 1996.

[3] ITU-T Recommendation I.365.1, «Frame Relaying Service Specific Convergence Sublayer (SSCS), ноябрь 1993.

[4] Brown, C. и A. Malis, «Multiprotocol Interconnect over Frame Relay», RFC 2427, сентябрь 1998.

[5] Perez M., Liaw, F., Mankin, E., Grossman, D. и A. Malis, «ATM Signalling Support for IP over ATM», RFC 1755, февраль 1995.

[6] Information technology — Telecommunications and Information Exchange Between Systems, «Protocol Identification in the Network Layer». ISO/IEC TR 9577, октябрь 1990.

[7] Postel, J. и J. Reynolds, «A Standard for the Transmission of IP Datagrams over IEEE 802 Networks», STD 43, RFC 1042, февраль 1988.

[8] Maher, M., «IP over ATM Signalling — SIG 4.0 Update», RFC 2331, апрель 1998.

[9] ITU-T Recommendation I.555, «Frame Relay Bearer Service Interworking», сентябрь 1997.

[10] Bradner, S. «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, март 1997.

[11] Fox, B. and B. Gleeson, «Virtual Private Networks Identifier», RFC 2685, сентябрь 1999.

[12] The ATM Forum, «ATM Security Framework Version 1.0», af-sec-0096.000, февраль 1998.

[13] The ATM Forum, «ATM Security Specification v1.0», af-sec-0100.001, февраль 1999.

Приложение A. Многопротокольная инкапсуляция поверх FR-SSCS

Рекомендации ITU-T I.365.1 определяют связанный с коммутацией кадров подуровень конвергенции FR-SSCS (Frame Relaying Specific Convergence Sublayer) для использования поверх общей части подуровня конвергенции CPCS (Common Part Convergence Sublayer) AAL типа 5 для межсетевого взаимодействия Frame Relay/ATM. Сервис, предоставляемый FR-SSCS, соответствует Core-сервису для коммутации кадров (Frame Relaying), описанной в I.233.

Пакеты FR-SSCS-PDU содержат поле адреса Q.922, за которым следует информационное поде Q.922. Флаги Q.922 и FCS не используются, поскольку соответствующие функции обеспечиваются AAL. Ниже показан формат FR-SSCS-PDU, вложенных в поле Payload пакетов AAL5 CPCS-PDU.

             FR-SSCS-PDU в поле Payload пакетов AAL5 CPCS-PDU
            +-------------------------------+ -------
            |      Поле адреса Q.922        | Заголовок FR-SSCS-PDU 
            |         (2-4 octets)          |
            +-------------------------------+ -------
            |             .                 |
            |             .                 |
            |    Информационное поле Q.922  | Данные FR-SSCS-PDU 
            |             .                 |
            |             .                 |
            +-------------------------------+ -------
            |      Трейлер AAL5 CPCS-PDU    |
            +-------------------------------+

PDU, использующие маршрутизацию или мосты, инкапсулируются в FR-SSCS-PDU в соответствии с RFC 2427. Информационное поле Q.922 начинается с поля Q.922 Control, за которым следует необязательный октет заполнения, используемый для выравнивания остальной части кадра по приемлемой для отправителя границе. Протокол передаваемых PDU указывается с помощью предшествующих PDU идентификаторов протокола сетевого уровня ISO/IEC TR 9577 NLPID.

В частном случае IP PDU идентификатор NLPID = 0xCC и пакет FR-SSCS-PDU имеет следующий формат:

Формат FR-SSCS-PDU для маршрутизируемых IP PDU

Поле адреса Q.922

(2 или 4 октета)

0x03 (Q.922 Control)

NLPID 0xCC

.
IP PD (до 216 — 5 октетов)
.

Отметим, что согласно RFC 2427, адрес Q.922 должен содержать 2 или 4 октета, т.е. 3-октетные адреса использовать недопустимо.

Для частного случая CLNP PDU идентификатор NLPID = 0x81 и формат FR-SSCS-PDU приведен ниже:

Формат FR-SSCS-PDU для маршрутизируемых CLNP PDU

Поле адреса Q.922

(2 или 4 октета)

0x03 (Q.922 Control)

NLPID 0x81

.
Остальная часть CLNP PD
.

Отметим, что для протоколов ISO поле NLPID формирует первый октет PDU и не должно повторяться.

Описанная выше инкапсуляция применима только к тем из маршрутизируемых протоколов, которые имеют уникальный идентификатор NLPID. Для остальных маршрутизируемых протоколов (и для протоколов, использующих мосты) требуется обеспечить иной механизм простой идентификации протокола. Для решения этой задачи можно использовать значение NLPID = 0x80, чтобы указать следующий далее заголовок IEEE 802.1a SNAP.

Детальное описание многопротокольной инкапсуляции поверх FRCS приведено в RFC 2427.

Приложение B. Список локально распределяемых OUI 00-80-C2

С сохранением FCS

Без сохранения FCS

Среда

0x00-01

0x00-07

802.3/Ethernet

0x00-02

0x00-08

802,4

0x00-03

0x00-09

802,5

0x00-04

0x00-0A

FDDI

0x00-05

0x00-0B

802,6

0x00-0D

Фрагменты

0x00-0E

BPDU

Приложение C. Частичный список NLPID

0x00    Null Network Layer или Inactive Set (не используется с ATM)
0x80    SNAP
0x81    ISO CLNP
0x82    ISO ESIS
0x83    ISO ISIS
0xCC    Internet IP

Приложение D. Применение многопротокольной инкапсуляции

Мультипротокольная инкапсуляция необходима (но, в общем случае, недостаточна) для маршрутизации и организации мостов через сети ATM. С момента публикации RFC 1483 (предшественник данного документа) IETF и ATM Forum подготовили несколько спецификаций по различным аспектам маршрутизации и организации мостов. В этом приложении содержится краткий список таких спецификаций.

  1. Point-to-point connection between routers and bridges — многопротокольная инкапсуляция поверх ATM PVC используется для организации простых каналов “точка-точка” между мостами и маршрутизаторами через сеть ATM. Для этого сценария требуется выполнять некоторое количество настроек вручную (например, INARP).

  2. Classical IP over ATM — RFC 22255 (первоначальный вариант — RFC 1577) обеспечивает среду, где сеть ATM выступает в качестве логической подсети IP (LIS). Поддерживаются ATM PVC с преобразованием адресов на основе INARP. Для ATM SVC используется ATMARP (новая форма ARP), обеспечивающая взаимодействие через сеть ATM между хостом (или маршрутизатором) и сервером ATMARP. При использовании репликации сервера для повышения надежности и производительности применяется протокол SCSP (Server Synchronization Cache Protocol — протокол синхронизации серверных кэшей), определенный в RFC 2335. Classical IP over ATM по умолчанию использует инкапсуляцию LLC/SNAP.

  3. LAN Emulation — Спецификация эмуляции ЛВС ATM Forum обеспечивает среду, где возможности ATM расширяются за счет использования серверов LAN Emulation, работающих как локальные сети на основе мостов (bridged LAN). Станции получают конфигурационные параметры и регистрируются на сервере LECS (LAN Emulation Configuration Server); MAC-адреса преобразуются в адреса ATM с помощью служб сервера эмуляции ЛВС и станции могут передавать пакеты с широковещательными (broadcast) и групповыми (multicast) адресами, а также пакеты для индивидуальных адресов (unicast), не связанных явно с VC, специальному серверу широковещания (Broadcast and Unicast Server). LANE использует мультиплексирование VC для инкапсуляции кадров Bridged Etherent/802.3 (без LAN FCS) или Bridged 802.5 (без LAN FCS) для Data Direct, LE Multicast Send и Multicast Forward VCCS. Однако, изначальное поле заполнения PAD, описанное в данном документе, используется как заголовок LE и не должно состоять из одних нулей.

  4. Next Hop Resolution Protocol (NHRP) — В некоторых случаях ограничения Classical IP over ATM (поддержка единственного LIS) ведут к снижению производительности. Протокол NHRP, описанный в RFC 2332, расширяет возможности Classical IP over ATM, позволяя работать с несколькими LIS.

  5. Multiprotocol over ATM (MPOA) — Спецификация ATM Forum MPOA объединяет возможности LANE и NHRP для обеспечения базовой среды с поддержкой маршрутизации и мостов.

  6. IP Multicast — RFC 2022 расширяет возможности Classical IP за счет поддержки IP multicast (групповая адресация). Сервер преобразования групповых адресов MARS может использоваться совместно с multicast-сервером для рассылки по групповым адресам IP через сеть ATM с использованием виртуальных соединений point-to-multipoint и/или point to point.

  7. PPP over ATMRFC 2364 расширяет возможности многопротокольной инкапсуляции поверх ATM для использования протокола PPP. В этом расширении используется как мультиплексирование VC, так и инкапсуляция LLC/SNAP. Это расширение обычно используется в сетях ATM с соединениями “точка-точка” для поддержки протокола PPP.

Приложение E. Отличия от RFC 1483

Этот документ заменяет RFC 1483. Документ избавлен от анахронизмов, устраняет неоднозначности, обнаруженные в ранних реализациях и расширяет возможности протокола с учетом стандартов IETF. Было сделано также множество редакторских правок с учетом соглашений RFC 2119 [10]. Ниже перечислены основные изменения, внесенные в документ. Ни одно из этих изменений не должно противоречить реализациям RFC 1483:

  • использование инкапсуляции NLPID описано с учетом соглашений RFC 2119;
  • добавлена ссылка на RFC 2364 (PPP over ATM);
  • включены ссылки на RFC 1755 и RFC 2331, описывающие согласование инкапсуляции взамен давно устаревших рабочих документов CCITT (не ITU-T);
  • использование AAL5 описано на основе ITU-T I.363.5 (эта опция AAL5 была создана после публикации RFC 1483);
  • внесена ясность в форматирование маршрутизируемых NLPID PDU (routed ISO PDU в RFC 1483);
  • внесена ясность в использование заполнения для PID и MAC-адресов получателей для PDU с использованием мостов, а также порядок битов для MAC-адресов;
  • внесена ясность в использование заполнения для кадров Ethernet/802.3;
  • добавлена инкапсуляция для VPN;
  • добавлено рассмотрение вопросов безопасности;
  • в новом приложении D приведено резюме использования многопротокольной инкапсуляции поверх ATM.

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

Dan Grossman
Motorola, Inc.
20 Cabot Blvd.
Mansfield, MA 02048

EMail: dan@dma.isg.mot.com

Juha Heinanen
Telia Finland
Myyrmaentie 2
01600 Vantaa, Finland

EMail: jh@telia.fi


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

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

nmalykh@protocols.ru

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

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

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

1 Service Specific Convergence Sublayer — специфичный для сервиса подуровень схождения (конвергенции).

2 Постоянные виртуальные соединения

5Эта спецификация обновлена в RFC 5494. Прим. перев.