Энциклопедия сетевых протоколов

Internet Engineering Task Force (IETF)                         J. Fabini
Request for Comments: 7312               Vienna University of Technology
Updates: 2330                                                  A. Morton
Category: Informational                                        AT&T Labs
ISSN: 2070-1721                                              August 2014

Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)

Усовершенствованная схема для потоков и выборки IPPM

PDF

Аннотация

Для получения повторяемых результатов в современных сетях описания тестов требуют расширения для указания параметров потоков, дополняющих аспекты тестовых пакетов Type-P. Этот документ обновляет схему показателей производительности (IP Performance Metrics или IPPM), представленную в RFC 2330, дополнительным рассмотрением методологии измерений и тестирования. Имеющаяся модель в основном предполагает детерминированную связность и представление тестовым потоком характеристик пути при его объединении с другими потоками. Сети развиваются и вместе с этим должны развиваться описания тестовых потоков, поскольку в ином случае на измерение производительности могут влиять неожидаемые свойства сети. В этом документе описаны новые параметры потоков для характеризации сети и поддержки разработки приложений, использующих показатели IPPM.

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

Этот документ не относится к категории проектов стандартов (Internet Standards Track) и публикуется для информации.

Документ является результатом работы IETF¹ и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG². Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 5741.

Информация о текущем статусе этого документа, обнаруженных ошибках и способах обратной связи может быть найдена по ссылке http://www.rfc-editor.org/info/rfc7312.

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

Авторские права ((c) 2014) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Рабочая группа IETF IPPM описала схему разработки показателей в [RFC2330]. Эта схема проверена временем и позволила создать множество фундаментальных показателей, хотя обновлялась лишь один раз в [RFC5835].

Модель IPPM [RFC2330] обычно опирается на несколько допущений, одно из которых не указано явно, но предполагается — для слабо загруженных путей соблюдается зависимость «задержка сериализации = размер пакета / пропускную способность» и в пути не сохраняется состояние или история (с некоторыми исключениями; например, учитываются межсетевые экраны). Однако такое допущение не всегда применимо в современных сетевых технологиях, таких как реактивные пути (с выделением ресурсов по запросам) и каналы с временными интервалами. Для тестовых потоков могут организовываться состояния и такая обработка оказывает влияние на измеряемые характеристики, поэтому её следует учитывать. История потока также влияет на производительность приложений и заметна для пользователей.

Кроме того, в разделе 4 и параграфе 6.2 [RFC2330] явно рекомендуются воспроизводимые показатели и методики. Измерения в современных сетях доступа показывают, что методические рекомендации [RFC2330] нужно расширить с учётом реактивной природы сетей. Предложены расширения, позволяющие методикам соблюдать требование непрерывности, указанное в параграфе 6.2 [RFC2330], но они не обеспечивают гарантии этого. Практические измерения подтверждают, что некоторые типы каналов дают разные отклики при повторе измерений с идентичными условиями (картинами трафика). При наличии возможности соответствующая тонкая настройка картины измерительного трафика может улучшить повторяемость измерений для таких каналов, как показано в [IBD].

Этот документ обновляет схему IPPM [RFC2330] расширенным рассмотрением методик измерения и тестов. Отмечено, что область действия IPPM в момент публикации [RFC2330] (и более 10 последующих лет) была ограничена активными измерениями и методами с генерацией потоков, предназначенных для измерения без мониторинга пользовательского трафика. Данный документ не меняет сферу действия схемы.

Это обновление [RFC2330] не отменяет и не требует вносить изменения в определения аналитических показателей, подготовленные рабочей группой IPPM. Документ, скорее, добавляет рассмотрение методик активных измерений и повышает важность введённых [RFC2330] соглашений и обозначений, таких как пакеты Type-P.

Среди эволюционных изменение сетей имеется явление, которое названо здесь «реактивным поведением».

1.1. Определение реактивного поведения пути

Реактивное поведение пути будет наблюдаемым потоком тестовых пакетов как повторяемое явление при «изменении» характеристик производительности потока пакетов в соответствии с предыдущими наблюдениями за интересующим потоком пакетов (на «реактивном» хосте или канале). Поэтому реактивное поведение пути номинально является детерминированным по отношению к интересующему потоку. Другие потоки или условия нагрузки могут вызывать дополнительную реакцию, но она будет внешней по отношению к интересующему потоку.

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

За исключением размера данных (payload) на интересующем уровне и самого заголовка, содержимое пакета не влияет на измерения. Реактивное поведение на уровне IP не зависит, например, от используемых портов TCP. Поэтому указание реактивного поведения должно включать уровень, на котором выполняются измерения.

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

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

1.2. Уровни требований

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

2. Область действия

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

Документ обновляет основные разделы [RFC2330], добавляя соображения, которые помогут при разработке новых методик измерения, предназначенных для современных сетей IP. В частности, документ описывает полезные параметры потоков, которые дополняют параметры, описанные в параграфе 11.1 [RFC2330] и параграфе 4.2 [RFC3432] для периодических потоков.

Документ также рассматривает обновление критериев для показателей из раздела 4 в [RFC2330], методик измерений из параграфа 6.2 в [RFC2330] и других вопросов, связанных с качеством показателей и методов (раздел 4).

Другие аспекты [RFC2330], которые могут быть обновлены или дополнены, оставлены на будущее. Это включает вопросы пассивных и гибридных (активные и пассивные) измерений.

3. Новые и пересмотренные параметры потоков

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

1. Обработка в сети полностью зависит от определения «пакета Type-P» в [RFC2330], с которым связан ряд моментов, указанных ниже.

• • В разных точках пути часто поддерживаются состояния на уровне потоков, при этом «поток» определяется уровнем IP и другими уровнями. Имеются существенные различия в трактовке простейшего параметра Type-P — размера пакетов. Рекомендуется использовать разные размеры.

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

2. История пакетов (мгновенная или недавняя скорость теста или бездействие с учётом не связанного с тестом трафика) оказывает существенное влияние на измеряемую производительность наряду с параметрами Type-P, описанными в [RFC2330].

3. В процессе тестирования может смениться технология доступа с изменением пропускной способности и метода доступа. При использовании разных интерфейсов ищущий доступ хост знает о смене технологии, что отличает этот вариант смены пути от других изменений состояния сети. В разделе 14 [RFC2330] рассматривается возможность наличия у хоста нескольких соединений с сетью, а также учёт того, что измерительный путь (маршрут) действителен в течение определённого времени (разделы 5 и 7 в [RFC2330]). Здесь эти два соображения объединены на основе допущения возможности более частых изменений и наличия более существенного влияния на показатели производительности.

4. Пути, включающие каналы или узлы с услугами на основе временных интервалов (time-slot) представляют некоторые сложности для измерений (когда интервал обслуживания становится заметным).

• • Случайные (несмещенные) выборки становятся невозможными за пределами одного такого канала в пути.

  • Вышеизложенное способствует сегментированному подходу к сквозным измерениям, как описано в [RFC6049] для Network Characterization (определено в [RFC6703]), чтобы увидеть весь диапазон задержек и их вариаций на пути. Если целью является оценка производительности приложения (как определено в [RFC6703]), может быть достаточно потока с несмещенными свойствами или известным смещением [RFC3432].

  • Мультимодальные вариации задержки делают центральную статистику малозначимой и взамен следует применять иные варианты.

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

3.1. Тестовые пакеты Type-P

Рекомендуется добавить два параметра Type-P к факторам, влияющим на показатели производительности пути, а именно — размер пакетов и тип содержимого (payload). Тщательный выбор этих параметров может улучшить методики измерения, с точки зрения их непрерывности и повторяемости на реактивных путях.

3.1.1. Размеры тестовых пакетов

Многие случаи характеризации сетей с использованием метрик IPPM основаны на тестах с одним размером пакетов. При оценке производительности доступа или агрегированного трафика в методах сравнительного анализа применяется диапазон фиксированных размеров и тесты с фиксированным размером часто дополняются измерениями для разных размеров (Internet Mix или IMIX), как описано в [RFC6985].

Размер тестовых пакетов влияет на измерение задержки, поскольку метрика односторонней задержки в IPPM [RFC2679] включает время сериализации от первого бита до последнего в требования к временным меткам. Однако разные размеры пакетов могут оказывать большее влияние на задержку и её вариации, нежели отмеченная выше сериализация. Это влияние может быть нелинейным и мгновенные значения производительности могут быть разными для пакетов разного размера.

Повторяемость важна для методики измерений, как отмечено в параграфе 6.2 [RFC2330]. Для исключения влияния смены размера пакетов на результат в измерениях следует использовать идентичные картины трафика. На практике комбинация произвольного содержимого (payload) и произвольного времени запуска может давать репрезентативный результат, как показано в [IRR].

3.1.2. Оптимизация содержимого тестовых пакетов

Стремление к эффективному использованию сетевых ресурсов привело к развёртыванию методов сжатия без потерь или с незначительными потерями на серверах и в системах клиент-сервер для некоторых каналов и путей. Такая оптимизация включает попытки сжать трафик с большим объёмом для снижения загрузки сети. Файлы анализируются на уровне приложений и отдельные их части (например, комментарии) могут отбрасываться. Хотя такое сжатие обычно применяется для HTTP и файлов JPEG, оно может влиять и на измерительные пакеты. В частности, такие пакеты подлежат сжатию, если в них помещается обычное текстовое содержимое. Использование шифрования на транспортном уровне будет препятствовать анализу на сетевом уровне и может снизить эффективность сжатия.

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

Оптимизация может выходить за рамки одного потока данных или измерений. К настоящему времени предложено или стандартизовано много технологий оптимизации на уровне клиента или сети, включая ROHC (Robust Header Compression) и агрегирование Voice over IP [EEAW]. Там, где оптимизация возможна и нужна, могут применяться многие из таких технологий. В общем случае с ростом числа одновременных потоков на промежуточных хостах и длины общих путей для таких потоков растёт потребность в агрегировании потоков из разных источников. При измерениях следует учитывать эту дополнительную неопределённость в части повторяемости. Агрегирование потоков в сетевых устройствах может приводить, например, к их взаимному влиянию друг на друга и это может на порядки превышать влияние очередей.

3.2. История пакетов

Недавняя история пакетов и мгновенная скорость данных влияют на результаты измерений для реактивных каналов, поддерживающих выделение пропускной способности по запросам. Неоднозначность измерений можно снизить, зная историю пакетов и общую загрузку хоста. Кроме того, незначительные изменения истории, например, в результате потери пакетов на пути, могут стать причиной существенного изменения производительности. Например, задержки в реактивных сетях 3G, таких как HSPA (High Speed Packet Access) в значительной степени зависят от скорости передачи тестового трафика. Стратегия реактивного выделения ресурсов в таких сетях влияет, в частности, на восходящее направление. Незначительные изменения скорости данных могут более чем на 200% увеличивать задержку в зависимости от конкретного размера пакетов. Подробный теоретический и практический анализ переходов в каналах RRC (Radio Resource Control), которые могут вызывать такое поведение в сетях UMTS (Universal Mobile Terrestrial System), представлен, например, в [RRC].

3.3. Смена технологии доступа

В [RFC2330] рассматривается вариант с многодомными хостами. Если хост узнаёт о смене технологии доступа (например, по смене адреса IP или информации канального уровня) и делает эти сведения доступными, методика измерения может воспользоваться этими данными для повышения репрезентативности и релевантности измерений.

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

3.4. Каналы с временными интервалами — устранение случайности

Операции на путях с временными интервалами (time-slot) на интерфейсах, маршрутизаторах или каналах пути через сеть создают для измерений значительные проблемы, особенно при продолжительных временных интервалах. Основное наблюдение, как расширение выборки Пуассона для потока из [RFC2330], заключается в том, что первый элемент с временными интервалами нарушает несмещенную выборку потока измерений. В худшем случае работа с временными интервалами превращает несмещенный случайный поток измерений в периодический. Значительное смещение пакетов может взаимодействовать с периодическим поведением последующих элементов с временными интервалами [TSRC].

Отмена случайного поведения элементами с временными интервалами (Time-slotted randomness cancellation или TSRC) может возникать практически в любой системе, элементе сети или пути, причём её влияние на измерения имеет тот же порядок, что и сами измеряемые показатели. Примерами источников TSRC могут служить дискретность часов, тактирование операционных систем, компоненты сети или операции с использованием временных интервалов и т. п. Смещение измерений определяется конкретным измерительным потоком, относительным смещением между выделенными временными интервалами в последовательных элементах пути, вариациями задержки на путях и другими изменениями. Результаты измерений могут меняться с течением времени в зависимости от степени синхронизации передающего и приёмного хостов, а также элементов измерительного пути между собой и с абсолютным временем. Если сегменты пути поддерживают состояние потока, изменение параметров или перераспределение потока могут приводить к существенному изменению результатов измерений.

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

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

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

4. Качество показателей и методик

В [RFC6808] предложено считать воспроизводимость непрерывность свойствами показателей, определяющими качество измерений. В зависимости главным образом от набора контролируемых параметров измерений, повторные измерения на конкретном пути через сеть могут давать повторяющиеся или не повторяющиеся результаты. Сложные варианты измерений для адекватного управления параметрами включают беспроводные и реактивные сети, а также сети с временными интервалами, упомянутые выше. В этом разделе представлено расширенное определение воспроизводимости, дополняющее определение [RFC2330], а также расширенное представление «непрерывности» [RFC2330] и её ограниченной применимости.

4.1. Пересмотренное определение воспроизводимости

В [RFC2330] воспроизводимость определена в общем виде:

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

Задача состоит в развитии этого определения, чтобы оно стало объективным критерием (независимым от рассматриваемой ниже концепции непрерывности. Этот вопрос рассматривался в других работах IPPM. В BCP 176 [RFC6576] были согласованы критерии эквивалентности в качестве заменителя функциональной совместимости при оценке RFC для показателей в качестве Standards Track. Критерии эквивалентности были выражены в форме объективных статистических требований для сравнений одних и тех же и независимых реализаций в планах тестирования, относящихся к каждому оцениваемому RFC ([RFC2679] в плане тестирования [RFC6808]).

Тесты [RFC6808] полагаются на наличие почти идентичных условий для анализа и допускают, что эти условия не могут в точности выполняться на используемых путях реальных сетей. Планы тестирования позволяют применять некоторые корректировки (некоторые статистические тесты слишком чувствительны к различиям средних значений в распределении) и признают выводы [RFC2330] в части избыточного размера выборок.

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

Хотя в плане тестирования [RFC6808] приведены числовые критерии эквивалентности, в общем случае невозможно задать точные численные критерии для воспроизводимости. Были успешно применены процесс [RFC6576] и статистика [RFC6808], а числовые критерии воспроизводимости метики следует согласовывать между заинтересованными сторонами до измерений.

Пересмотренное определение воспроизводимости приведено ниже.

Методике для показателя следует иметь свойство воспроизводимости — если методика применяется несколько раз, методу должны давать эквивалентные результаты измерений.

4.2. Непрерывность больше не является критерием воспроизводимости

В исходной схеме [RFC2330] (параграф 6.2) была введена концепция непрерывности для предоставления смягчённых критериев оценки повторяемости параграфе:

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

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

BTC (Bulk Transfer Capacity) [RFC3148] в разделе 1 (стр. 2) содержит приведённый ниже текст.

Имеются сведения о том, что большинство реализаций TCP демонстрирует нелинейное изменение производительности в некоторой части рабочей области. Можно привести простые примеры моделирования, в которых постепенное улучшение пути (например, рост скорости в канале данных) будет приводить к снижению общей пропускной способности TCP (или BTC) [Mat98].

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

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

4.3. Показателям следует быть действенными

Документ IP Performance Metrics Framework [RFC2330] включает критерий полезности метрики:

«… Показатели должны быть полезными для пользователей и провайдеров в понимании производительности, которая наблюдается или предоставляется.»

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

Концепцию полезности можно расширить, сделав её частью того, что здесь названо критерием действенности. Отметим, что это не связано с юридическим термином.

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

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

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

4.4. Консервативность может быть невозможна

В [RFC2330] применяется термин «консервативная» к методикам измерения, для которых:

«… акт измерения не меняет или меняет слабо значение показателя производительности, которое методика пытается измерить.»

Следует отметить, что определение «консервативности» в смысле [RFC2330] зависит в значительной степени от технологии и характеристик пути измерений. В частности, при развёртывании на реактивных путях, субпутях, каналах или хостах, соответствующих определению параграфа 1.1, тестовые пакеты могут вызывать (пере)распределение пропускной способности. Кроме того, незначительные вариации измерительного потока могут приводить к значительным изменениям результатов измерений, наблюдаемым другими пользователями на том же пути. Из этого следует, что:

Метод не всегда может быть консервативным.

4.5. Пространственная и временная композиция для несмещенной выборки

Концепции, связанные с пространственной и временной композицией показателей из раздела 9 в [RFC2330], были расширены в [RFC5835], где определены новые типы показателей, включая Spatial Composition (пространственная композиция), Temporal Aggregation (временное агрегирование), Spatial Aggregation (пространственное агрегирование). До сих пор стандартизованы лишь показатели для Spatial Composition [RFC6049], что даёт возможность оценивать производительность пути на основе показателей субпутей. Пространственная композиция согласуется с выводом [TSRC] о невозможности беспристрастной выборки за пределами первого канала с временными интервалами на пути измерений.

В случаях, когда беспристрастное измерение для всех сегментов пути невозможно по причине наличия канала с временными интервалами, рекомендуется восстанавливать случайность выборки, как представлено в [TSRC], в комбинации с пространственной композицией (Spatial Composition) [RFC6049].

4.6. Отсечка распределения Пуассона

В параграфе 11.1.1 [RFC2330] описаны выборки Пуассона, где для межпакетных интервалов применяется распределение Пуассона. Элемент пути с реактивным поведением, чувствительным к отсутствию активности в потоке, может изменить состояние, если случайный интервал между пакетами слишком велик.

Рекомендуется отсекать «хвост» распределения Пуассона для предотвращения смены состояния реактивных элементов.

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

5. Заключение

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

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

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

Вопросы безопасности, связанные с активными измерениями на работающих путях, применимы и в данном случае. См.[RFC4656] и [RFC5357].

При рассмотрении приватности участников измерений или тех, чей трафик подвергается измерениям, конфиденциальные сведения, доступные потенциальным наблюдателям сильно ограничены при использовании активных методов, которые и рассматриваются в этом документе. Пассивные измерения пользовательского трафика вызывают проблемы, связанные с приватностью. Читателям рекомендуется обратиться к обсуждению приватности в схеме LMAP (Large Scale Measurement of Broadband Performance) [LMAP], охватывающей активные и пассивные методы.

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

Авторы благодарны Rudiger Geib, Matt Mathis, Konstantinos Pentikousis, Robert Sparks за полезные комментарии к документу, Alissa Cooper и Kathleen Moriarty за предложенные способы «обновления обновлений» для повышения осведомлённости о приватности и связанных с этим последствиях, Ann Cerveny за редакторскую рецензию и комментарии, которые повысили уровень читаемости документа в целом.

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

8.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, «Framework for IP Performance Metrics», RFC 2330, May 1998.

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, «A One-way Delay Metric for IPPM», RFC 2679, September 1999.

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, «Network performance measurement with periodic streams», RFC 3432, November 2002.

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, «A One-way Active Measurement Protocol (OWAMP)», RFC 4656, September 2006.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, «A Two-Way Active Measurement Protocol (TWAMP)», RFC 5357, October 2008.

[RFC5835] Morton, A. and S. Van den Berghe, «Framework for Metric Composition», RFC 5835, April 2010.

[RFC6049] Morton, A. and E. Stephan, «Spatial Composition of Metrics», RFC 6049, January 2011.

[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, «IP Performance Metrics (IPPM) Standard Advancement Testing», BCP 176, RFC 6576, March 2012.

[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, «Reporting IP Network Performance Metrics: Different Points of View», RFC 6703, August 2012.

8.2. Дополнительная литература

[EEAW] Pentikousis, K., Piri, E., Pinola, J., Fitzek, F., Nissilae, T., and I. Harjula, «Empirical Evaluation of VoIP Aggregation over a Fixed WiMAX Testbed», Proceedings of the 4th International Conference on Testbeds and research infrastructures for the development of networks and communities (TridentCom ’08), Article No. 19, March 2008, <http://dl.acm.org/citation.cfm?id=139059>.

[IBD] Fabini, J., Karner, W., Wallentin, L., and T. Baumgartner, «The Illusion of Being Deterministic — Application-Level Considerations on Delay in 3G HSPA Networks», Lecture Notes in Computer Science, Volume 5550, pp. 301-312 , May 2009.

[IRR] Fabini, J., Wallentin, L., and P. Reichl, «The Importance of Being Really Random: Methodological Aspects of IP-Layer 2G and 3G Network Delay Assessment», ICC’09 Proceedings of the 2009 IEEE International Conference on Communications, doi: 10.1109/ICC.2009.5199514, June 2009.

[LMAP] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, «A framework for large-scale measurement platforms (LMAP)», Work in Progress, June 2014.

[Mat98] Mathis, M., «Empirical Bulk Transfer Capacity», IP Performance Metrics Working Group report in Proceedings of the Forty-Third Internet Engineering Task Force, Orlando, FL, December 1998, <http://www.ietf.org/proceedings/43/slides/ippm-mathis-98dec.pdf>.

[RFC3148] Mathis, M. and M. Allman, «A Framework for Defining Empirical Bulk Transfer Capacity Metrics», RFC 3148, July 2001.

[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, «Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track», RFC 6808, December 2012.

[RFC6985] Morton, A., «IMIX Genome: Specification of Variable Packet Sizes for Additional Testing», RFC 6985, July 2013.\

[RRC] Peraelae, P., Barbuzzi, A., Boggia, G., and K. Pentikousis, «Theory and Practice of RRC State Transitions in UMTS Networks», IEEE Globecom 2009 Workshops, doi: 10.1109/GLOCOMW.2009.5360763, November 2009.

[TSRC] Fabini, J. and M. Abmayer, «Delay Measurement Methodology Revisited: Time-slotted Randomness Cancellation», IEEE Transactions on Instrumentation and Measurement, Volume 62, Issue 10, doi:10.1109/TIM.2013.2263914, October 2013.

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

Joachim Fabini

Vienna University of Technology

Gusshausstrasse 25/E389

Vienna 1040

Austria

Phone: +43 1 58801 38813

Fax: +43 1 58801 38898

EMail: Joachim.Fabini@tuwien.ac.at

URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/

 

Al Morton

AT&T Labs

200 Laurel Avenue South

Middletown, NJ 07748

USA

Phone: +1 732 420 1571

Fax: +1 732 368 1192

EMail: acmorton@att.com

URI: http://home.comcast.net/~acmacm/

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                        T. Mizrahi
Request for Comments: 7276                                       Marvell
Category: Informational                                      N. Sprecher
ISSN: 2070-1721                             Nokia Solutions and Networks
                                                           E. Bellagamba
                                                                Ericsson
                                                           Y. Weingarten
                                                               June 2014

An Overview of Operations, Administration, and Maintenance (OAM) Tools

Обзор инструментария OAM

PDF

Аннотация

Базовый термин OAM¹ относится к набору средств для обнаружения и изоляции отказов, а также измерения производительности. За многие годы инструменты OAM были созданы для разных уровней стека протоколов.

Этот документ описывает некоторые инструменты OAM, определенные в IETF в контексте индивидуальной адресации IP, MPLS, MPLS-TP², псевдопроводов и TRILL³. Документ посвящен инструментам для обнаружения и изоляции отказов в сетях, а также для мониторинга производительности. Аспекты управления и поддержки OAM выходят за рамки этого документа. Функции восстановления, такие как FRR⁴ и защитное переключение также не рассматриваются здесь, хотя они зачастую вызываются протоколами OAM.

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

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

Документ не является проектом стандарта Internet и публикуется с информационными целями.

Документ является результатом работы IETF⁵ и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG⁶. Не все одобренные IESG документы претендуют на статус Internet Standard (см. раздел 2 в RFC 5741).

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc7276.

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

Авторские права (Copyright (c) 2014) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

OAM служит общим термином для обнаружения, изоляции, информирования об отказах и мониторинга работы сетей.

Имеется несколько интерпретаций аббревиатуры OAM. В этом документе используется Operations, Administration, and Maintenance (эксплуатация, администрирование, обслуживание), как рекомендовано в разделе 3 [OAM-Def].

Здесь рассмотрены несколько инструментов OAM, определенных IETF в контексте индивидуальной адресации IP, MPLS, MPLS-TP, псевдопроводов и TRILL.

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

1.1. Обоснование

Методы OAM, исходно применявшиеся в традиционных технологиях связи, таких как E1 и T1, перешли в PDH⁷, а затем в SONET/SDH⁸. ATM была возможно первой технологией со встроенной изначально поддержкой OAM, тогда как в других технологиях функции OAM обычно добавлялись специальным образом уже после определения и развертывания технологии. Сети на основе пакетов традиционно считались ненадежными и доставляющими данные по мере возможности (best effort). По мере развития пакетных сетей они становились базовым транспортом для передачи данных и телефонии, заменив традиционные транспортные протоколы. Поэтому предполагается, что в пакетных сетях будет обеспечиваться «операторский уровень» и, в частности, поддержка более развитых функций OAM в дополнение к ICMP и router hello, которые традиционно служили для обнаружения отказов.

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

Рисунок 1 показывает сеть, в которой трафик IP между двумя абонентскими границами передается через операторскую сеть MPLS. На уровне провайдера применяется MPLS OAM для мониторинга соединений между двумя граничными точками, а на уровне абонента применяется IP OAM для сквозного мониторинга соединений между двумя абонентскими сетями.

      |<------------ Абонентский уровень OAM ------------>|
            IP OAM (Ping, Traceroute, OWAMP, TWAMP)

                   |<-Провайдерский уровень->|
                       MPLS OAM (LSP Ping)

+-----+       +----+                         +----+       +-----+
|     |       |    |=========================|    |       |     |
|     |-------|    |          MPLS           |    |-------|     |
|     |  IP   |    |                         |    |  IP   |     |
+-----+       +----+                         +----+       +-----+
Граница       Граница                       Граница       Граница
абонента      провайдера                    провайдера   абонента

Рисунок 1. Пример многоуровневой организации OAM.

1.2. Целевая аудитория

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

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

• Производители оборудования и сетевые операторы могут пользоваться этим документом в качестве краткого справочника по инструментам IETF OAM.

Следует отметить, что для понимания и использования этого документа нужны некоторые базовые знания в части OAM. Предполагается, что читателю понятен термин OAM [OAM-Def], мотивы использования OAM и различия между OAM и управлением сетью [OAM-Mng].

1.3. Связанные с OAM работы в IETF

Этот документ содержит обзор разных наборов инструментов OAM, определенных IETF. Описанные здесь инструменты OAM применимы к индивидуальному трафику IP, MPLS, псевдопроводам, MPLS-TP и TRILL. Инструменты OAM имеются и для других технологий, но они выходят за рамки документа.

Этот документ сосредоточен на документах IETF, опубликованных как RFC, а другие работы, связанные с OAM, не рассматриваются. В IETF определены протоколы и инструменты OAM в разном контексте. Эти работы разделены на несколько крупных категорий связанных с OAM документов RFC, которые перечислены в таблице 1. Каждая категория определяет набор логически связанных RFC, хотя некоторые группы пересекаются.

Дальнейшее обсуждение в этом документе упорядоченно по этим группам (сокращения описаны в параграфе 2.1).

Таблица 1. Инструментальные средства OAM в документах IETF.

 

Инструмент	Транспортная технология
IP Ping	IPv4/IPv6
IP Traceroute	IPv4/IPv6
BFD	Базовая
MPLS OAM	MPLS
MPLS-TP OAM	MPLS-TP
Pseudowire OAM	Псевдопровода
OWAMP и TWAMP	IPv4/IPv6
TRILL OAM	TRILL

 

Этот документ сосредоточен на инструментах OAM, разработанных в IETF. Краткий обзор наиболее значимых стандартов OAM, разработанных другими организациями, приведен в приложении A.2.

1.4. Сосредоточенность на уровне данных

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

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

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

2. Терминология

2.1. Сокращения

ACH

Associated Channel Header — заголовок связанного канала.

AIS

Alarm Indication Signal — сигнал индикации тревоги.

ATM

Asynchronous Transfer Mode — асинхронный режим передачи.

BFD

Bidirectional Forwarding Detection — детектирование двухсторонней пересылки.

CC

Continuity Check — проверка непрерывности (работы).

CC-V

Continuity Check and Connectivity Verification — проверка связности и непрерывности.

CV

Connectivity Verification — проверка связности.

DM

Delay Measurement — измерение задержки.

ECMP

Equal-Cost Multipath — множество равноценных путей.

FEC

Forwarding Equivalence Class — класс эквивалентной пересылки.

FRR

Fast Reroute — быстрая перемаршрутизация.

G-ACh

Generic Associated Channel — базовый связанный канал.

GAL

Generic Associated Channel Label — метка базового связанного канала.

ICMP

Internet Control Message Protocol — протокол управляющих соединений Internet.

L2TP

Layer 2 Tunneling Protocol — протокол туннелирования на канальном уровне.

L2VPN

Layer 2 Virtual Private Network — виртуальная частная сеть на канальном уровне.

L3VPN

Layer 3 Virtual Private Network — виртуальная частная сеть на сетевом уровне.

LCCE

L2TP Control Connection Endpoint — конечная точка управляющего соединения L2TP.

LDP

Label Distribution Protocol — протокол распространения меток.

LER

Label Edge Router — краевой маршрутизатор по меткам.

LM

Loss Measurement — измерение потерь.

LSP

Label Switched Path — путь с коммутацией по меткам.

LSR

Label Switching Router — маршрутизатор с коммутацией по меткам.

ME

Maintenance Entity — элемент (сущность) обслуживания.

MEG

Maintenance Entity Group — группа элементов (сущностей) обслуживания.

MEP

MEG End Point — конечная точка MEG.

MIP

MEG Intermediate Point — промежуточная точка MEG.

MP

Maintenance Point — точка обслуживания.

MPLS

Multiprotocol Label Switching — многопротокольная коммутация по меткам.

MPLS-TP

MPLS Transport Profile — транспортый профиль MPLS.

MTU

Maximum Transmission Unit — максимальный передаваемый блок.

OAM

Operations, Administration, and Maintenance — эксплуатация, администрирование, обслуживание.

OWAMP

One-Way Active Measurement Protocol — протокол одностороннего активного измерения.

PDH

Plesiochronous Digital Hierarchy — плезиохронная цифровая иерархия

PE

Provider Edge — провайдерский край (периметр)

PSN

Public Switched Network — коммутируемая сеть общего пользования.

PW

Pseudowire — псевдопровод.

PWE3

Pseudowire Emulation Edge-to-Edge — сквозной псевдопровод.

RBridge

Routing Bridge — маршрутизирующий мост.

RDI

Remote Defect Indication — индикация удаленного дефекта.

SDH

Synchronous Digital Hierarchy — синхронная цифровая иерархия.

SONET

Synchronous Optical Network — синхронная оптическая сеть.

TRILL

Transparent Interconnection of Lots of Links — прозрачное соединение множества каналов.

TTL

Time To Live — время жизни.

TWAMP

Two-Way Active Measurement Protocol — протокол двухстороннего активного измерения.

VCCV

Virtual Circuit Connectivity Verification — проверка связности виртуального устройства (канала).

VPN

Virtual Private Network — виртуальная частная сеть.

2.2. Терминология в стандартах OAM

2.2.1. Базовые термины

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

Интересный обзор термина OAM и его производных представлен в [OAM-Def]. Справочник терминов MPLS-TP представлен в [TP-Term], где приведен хороший обзор некоторых терминов, связанных с OAM.

2.2.2. OAM

Приведенное ниже определение OAM заимствовано из [OAM-Def].

Компоненты аббревиатуры OAM (и предоставление) определяются, как показано ниже.

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

• Администрирование (administration) включает контроль ресурсов сети и их использования, а также учет, который нужен для отслеживания ресурсов и контролируемой сети.

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

2.2.3. Функции, инструменты и протоколы

OAM Function — функция OAM

Функцией OAM является тип инструментального измерения или диагностики.

Функции OAM являются неделимыми (atomic) блоками OAM и каждая функция определяет некую возможность OAM.

Типовые примеры функций OAM представлены в разделе 3.

OAM Protocol — протокол OAM

Протокол OAM служит для реализации одной или множества функций OAM.

Примером такого протокола является OWAMP-Test [OWAMP].

OAM Tool — инструмент OAM

Инструментом OAM называют конкретный способ выполнения одной или множества функций OAM.

В некоторых случаях протокол OAM является инструментом, например, OWAMP-Test. В иных случаях инструмент OAM применяет множество протоколов, которые могут быть не связаны строго с OAM, например, Traceroute (параграф 4.2) можно реализовать с использованием UDP и сообщений ICMP без протоколов OAM.

2.2.4. Уровни данных, управления и поддержки

Data Plane — уровень данных

Уровень данных представляет собой набор функций, применяемых для передаче данных в рассматриваемом «слое» или уровне [ITU-Terms].

Уровень данных называют также уровнем пересылки и пользовательским уровнем.

Control Plane — уровень управления

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

Management Plane – уровень поддержки

Термин уровень поддержки (Management Plane), как описано в [Mng], применяется для описания обмена сообщениями по протоколам управления (часто доставляются с помощью IP и транспортных протоколов IP) между программами управления и управляемыми объектами, такими как узлы сети.

Сравнение уровней данных, управления и поддержки

Различие между уровнями не всегда достаточно четко. Например, приведенное выше определение Control Plane может подразумевать, что инструменты OAM (ping, BFD и др.) фактически относятся к уровню управления.

Этот документ посвящен инструментам для мониторинга уровня данных. Хотя эти инструменты можно отнести к уровню управления, на деле они контролируют уровень данных и поэтому трафик OAM для мониторинга уровня данных должен передаваться вместе с трафиком, для которого выполняется мониторинг.

Другая неопределенность относится к различию между уровнями поддержки и управления. Уровень поддержки можно считать отдельным, но он может перекрываться с уровнем управления (см. [Mng]).

2.2.5. Участники процесса

Инструменты OAM используются между двумя (или более) партнерами. В документах IETF применяются различные термины для обозначения участников OAM. В таблице 2 указаны термины, применяемые для каждого набора инструментов, описанных здесь.

Таблица 2. Точки поддержки.

 

Инструмент	Термины
Ping/Traceroute ([ICMPv4], [ICMPv6], [TCPIP-Tools])	Host — хост Node — узел Interface — инетрфейс Gateway — шлюз
BFD [BFD]	System — система
MPLS OAM [MPLS-OAM-FW]	LSR
MPLS-TP OAM [TP-OAM-FW]	End Point — MEP — конечная точка MEP Intermediate Point — MIP — промежуточная точка MEP
Pseudowire OAM [VCCV]	PE LCCE
OWAMP и TWAMP ([OWAMP], [TWAMP])	Host — хост End system — конечная система
TRILL OAM [TRILL-OAM]	RBridge — маршрутизирующий мост

 

2.2.6. Режим активации

Разные инструменты OAM можно использовать в одном из двух, описанных ниже, режимах активации.

Proactive — проактивный

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

On-demand — по запросу

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

2.2.7. Проверка связности и непрерывности

В протоколах OAM применяются два разных класса функций контроля отказов — проверка связности (Connectivity Verification) и проверка непрерывности работы (Continuity Check). Различия между этими функциями определены в [MPLS-TP-OAM] и данный документ следует этому определению.

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

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

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

Функция Connectivity Verification (CV) позволяет одному из партнеров (Alice) проверить наличие соединения с другим (Bob). Отмечено, что при выполнении функции CV на уровне данных «ожидаемый путь» предопределен уровнем управления или уровнем поддержки. Протокол CV обычно использует сообщение CV, на которое передается отклик CV. Функция CV может вызываться проактивно или по запросу.

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

Функции CV можно применять и для проверки MTU на пути между парой точек.

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

2.2.8. Режимы коммуникаций

Connection-Oriented

В ориентированных на соединения технологиях организуется сквозное соединение (протоколом управления или системой поддержки) до начала передачи данных.

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

Connectionless

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

Обсуждение

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

В ориентированных на соединения технологиях OAM служит для мониторинга конкретного соединения, пакеты OAM передаются по одному маршруту с пакетами данных и обрабатываются аналогично. В технологиях без организации соединений OAM применяется между источником и получателем без указания конкретного соединения. Например, IP Ping (параграф 4.1) проверяет доступность заданного адресата для конкретного источника, а ориентированный на соединения тест LSP Ping (параграф 4.4.1) служит для мониторинга заданного LSP (соединение) и позволяет отслеживать все пути, используемые LSP.

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

2.2.9. Парные и многоточечные службы

Point-to-point (P2P)

Служба P2P (точка-точка) доставляет данные от одного источника к одному получателю.

Point-to-multipoint (P2MP)

Многоточечная служба P2MP доставляет данные от источника одному или множеству получателей (см. [Signal]).

MP2MP представляет собой службу доставки данных из одного или множества источников одному или многим получателям (см. [Signal]).

Примечание. Определения P2MP и MP2MP заимствованы из [Signal]. Хотя [Signal] относится к службам P2MP и MP2MP в MPLS, эти определения подходят и в других случаях.

Обсуждение

Описанные в документе инструменты OAM включают средства для служб как P2P, так и P2MP.

Различие между службами P2P и P2MP влияет на соответствующие инструменты OAM. Мониторинг служб P2P обычно проще, поскольку включает лишь пару конечных точек. Услуги P2MP и MP2MP сложнее для мониторинга. Например, в P2MP механизм OAM не только проверяет доступность каждого получателя, но и проверяет целостность и отсутствие петель в дереве распространения P2MP.

2.2.10. Отказы

Термины «отказ» (Failure), «сбой» (Fault) и «дефект» (Defect) используются в стандартах взаимозаменяемо применительно к неполадкам, которые моут быть обнаружены путем проверки связности или непрерывности. В некоторых стандартах, таких как 802.1ag [IEEE802.1Q], эти термины не различаются, а в других могут обозначать разные типы неполадок.

Терминология IETF MPLS-TP OAM основана на терминологии ITU-T, где эти три понятия трактуются, к описано ниже [ITU-T-G.806].

Fault — сбой

Термин Fault указывает неспособность выполнить требуемое действие, например, неудача при доставке пакета.

Defect — дефект

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

Failure — отказ

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

3. Функции OAM

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

• Проверка связности (CV), проверка пути и проверка непрерывности (CC) описаны в параграфе 2.2.7.

• Обнаружение пути и локализация неисправностей.

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

  Отметим, что термин «трассировка маршрута» (или Traceroute), используемый в контексте IP и MPLS, иногда относится к «трассировке пути» в контексте других протоколов, например, TRILL.

• Мониторинг производительности обычно включает:

  • учет потерь (LM) — мониторинг числа теряемых пакетов;

  • измерение задержки (DM) — мониторинг задержки и ее вариаций (jitter).

4. Подробное описание инструментов IETF OAM

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

4.1. IP Ping

Ping является одним из основным диагностических приложений в сетях IP и работает на основе ICMP. В соответствии с [NetTerms], ping является сокращением Packet internet groper, хотя термин используется настолько широко, что стал самодостаточным. Как указано в [NetTerms], — это программа для тестирования доступности адресатов с помощью отправки им сообщений ICMP Echo и ожидания отклика.

Обмен запросами и откликами ICMP Echo в Ping служит функцией CC для протокола IP. Источник передает пакет с запросом ICMP Echo, а получатель возвращает отклик Echo. Программа ICMP Ping существует в двух вариантах — [ICMPv4] для IPv4 и [ICMPv6] для IPv6.

Ping можно применять для индивидуального или группового адресата. В последнем случае все члены multicast-группы будут возвращать отправителю отклик Echo.

Реализации Ping обычно применяют сообщения ICMP. UDP Ping является вариантом программы с использованием сообщений UDP вместо ICMP Echo.

Ping является односторонним инструментом CC, т. е. позволяет проверить доступность адресата инициатору запроса Echo. Если желательно проверить доступность в обоих направлениях, обе стороны вызывают Ping независимо.

Отметим, что в результате фильтрации ICMP на некоторых маршрутизаторах и межсетевых экранах программа Ping может иногда не работать в сети Internet. Это ограничение относится и к Traceroute.

4.2. IP Traceroute

Traceroute ([TCPIP-Tools], [NetTools]) позволяет пользователю проследить путь между источником и адресатом IP.

В наиболее распространенном варианте реализации Traceroute [TCPIP-Tools] программа передает серию пакетов в порт адресата UDP 33434. По умолчанию Traceroute начинает с передачи трех пакетов (это число настраивается в большинстве реализаций Traceroute), со значением IP TTL (Hop Limit для IPv6) 1 в адрес получателя. Срок жизни этих пакетов заканчивается на первом маршрутизаторе в пути, поэтому маршрутизатор возвращает три сообщения ICMP Time Exceeded приложению Traceroute. Затем Traceroute передает три других пакета UDP с TTL = 2. Срок действия этих пакетов завершается на втором маршрутизаторе и он возвращает сообщения ICMP. Этот процесс продолжается с ростом значения TTL, пока пакеты не достигнут адресата. Поскольку ни одно приложение не прослушивает порт 33434 у адресата, он возвращает сообщения ICMP Destination Unreachable, указывающие недоступность порта. Это указывает приложению Traceroute завершение проверки. Программа Traceroute выводит время кругового обхода для каждой итерации.

Хотя Traceroute является средством поиска пути из A в B, следует отметить, что трафик из A в B зачастую пересылается по множеству равноценных путей (ECMP). Paris Traceroute [PARIS] является расширением Traceroute, которое пытается найти все доступные пути из A в B путем сканирования различных полей заголовков (например, портов UDP) в пробных пакетах.

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

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

Несколько расширений ICMP ([ICMP-MP], [ICMP-Int]) были определены в контексте Traceroute, включая сообщение ICMP Destination Unreachable, которое может применяться приложениями Traceroute.

Traceroute позволяет определять путь для индивидуальных адресов. Для групповой адресации определен аналогичный инструмент [mtrace], который позволяет проследить маршрут группового пакета IP от источника к конкретному адресату.

4.3. BFD

4.3.1. Обзор

Хотя для разных протоколов в стеке было определено множество инструментов OAM, двухстороннее детектирование пересылки [BFD], определенное рабочей группой IETF BFD, является базовым средством OAM, которое может быть развернуто для разных типов инкапсуляции и сред передачи. В IETF были определены варианты для IP ([BFD-IP], [BFD-Multi]), MPLS LSP [BFD-LSP] и псевдопроводов [BFD-VCCV]. Применение BFD в MPLS-TP определено в [TP-CC-CV].

BFD включает двк основных функции OAM, использующие два типа пакетов, BFD Control и BFD Echo.

4.3.2. Терминология

BFD работает между системами. Протокол BFD применяется между двумя или множеством систем после организации сессии.

4.3.3. BFD Control

BFD поддерживает двухстороннюю проверку непрерывности (CC), используя пакеты BFD, передаваемые в рамках сессии BFD, которая может работать в одном из двух режимов, описанных ниже.

• Асинхронный (проактивный) режим использует периодическую отправку пакетов BFD Control. Если получатель не обнаруживает пакетов BFD Control в течение заданного интервала, он сообщает об ошибке.

• В режиме работы по запросу пакеты BFD Control передаются по запросу. При возникновении потребности система инициирует отправку серии пакетов BFD Control для проверки непрерывности сессии. Пакеты BFD Control передаются в каждом направлении независимо.

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

В процессе нормальной работы (т. е. при отсутствии отказов) сессия BFD находится в состоянии Up (активна). Если в течение интервала, заданного параметром Detection Time, не будет получено пакетов BFD Control, сессия переводится в состояние Down (отключено). Время детектирования является функцией заданной в конфигурации или согласованной скорости передачи и параметра Detect Mult, определяющего число пакетов BFD Control, после отсутствия которых объявляется состояние Down. Этот параметр включается в пакет BFD Control.

4.3.4. BFD Echo

Пакет BFD Echo создается одним из партнеров и возвращается отправителю. Эхо-фукция может вызываться в проактивном режиме или по запросу.

Функция BFD Echo определена в BFD для IPv4 и IPv6 ([BFD-IP]), но не применяется в BFD для MPLS LSP и PW, а также в BFD для MPLS-TP.

4.4. MPLS OAM

Рабочая группа IETF MPLS определила OAM для MPLS LSP. Требования и схема описаны в [MPLS-OAM-FW] и [MPLS-OAM], соответственно. Определенным в этом контексте инструментом OAM является is LSP Ping [LSP-Ping]. Определение OAM для служб P2MP дано в [MPLS-P2MP].

BFD для MPLS [BFD-LSP] обеспечивает дополнительные средства обнаружения отказов на уровне данных, как описано ниже.

4.4.1. LSP Ping

Инструмент LSP Ping разрабатывался на основе парадигмы Ping/Traceroute и может работать в одном из двух режимов:

• Ping — приложение LSP Ping служит для сквозной проверки CV между двумя LER;

• режим Traceroute применяется для поэтапного (hop-by-hop) поиска неисправностей.

LSP Ping работает на базе операции ICMP Ping (CV на уровне данных) с дополнительной проверкой согласованности уровней данных и управления для классов FEC, а также обнаружением проблем MTU.

Функциональность Traceroute можно использовать для изоляции и локализации отказов MPLS с помощью индикатора TTL для инкрементной идентификации части пути LSP, которую удается пройти до отказа на канале или узле.

В сетях MPLS проблема заключается в том, что трафик данного LSP может быть распределен по множеству равноценных путей (ECMP). LSP Ping отслеживает все доступные пути LSP путем мониторинга различных FEC. Отметим, что MPLS-TP не применяет ECMP и поэтому не требует тестов OAM по разным путям.

Другая проблема заключается в том, что MPLS LSP может не иметь обратного пути, поскольку трафик от выходного LSR к входному LSR не обязательно передавать через MPLS LSP и он может проходить по другому маршруту, например, IP. Поэтому отклик на сообщение LSP Ping не так прост, как для IP Ping, где отвечающий узел просто меняет местами IP-адреса отправителя и получателя. Отметим, что этой проблемы не возникает в MPLS-TP, где путь возврата всегда доступен.

Следует отметить, что LSP Ping поддерживает однозначное указание LSP в рамках домена адресации. Указание проверяется с использованием полной идентификации FEC. LSP Ping можно расширять, добавляя информацию, нужную для поддержки новой функциональности с помощью конструкций TLV⁹. Использование TLV обычно обрабатывается на уровне управления, поскольку его сложно реализовать на аппаратном уровне.

LSP Ping поддерживает асинхронную активацию и вызовы по запросу.

4.4.2. BFD для MPLS

BFD [BFD-LSP] можно использовать для обнаружения отказов на уровне данных MPLS LSP.

Сессия BFD организуется для каждого проверяемого MPLS LSP. Пакеты BFD Control должны передаваться по тому же пути, что и тестируемый LSP. Если LSP связан с множеством FEC, сессия BFD организуется для каждого FEC.

Хотя LSP Ping можно применять для обнаружения отказов на уровне данных MPLS и проверки уровня данных MPLS LSP относительно уровня управления, BFD можно применять лишь для первого случая. BFD можно использовать вместе с LSP Ping, как в случае MPLS-TP (параграф 4.5.4).

4.4.3. OAM для VPN в сетях MPLS

В IETF опеределены два класса VPN — L2VPN и L3VPN. В [L2VPN-OAM] представлены требования и схема OAM в контексте L2VPN, а также определены уровни OAM для L2VPN в сетях MPLS. В [L3VPN-OAM] представлен схема работы и управления для L3VPN.

4.5. MPLS-TP OAM

4.5.1. Обзор

Рабочая группа MPLS определила набор инструментов OAM, удовлетворяющий требованиям MPLS-TP OAM. Полный набор требований к MPLS-TP OAM представлен в [MPLS-TP-OAM] и включает общие требования к поведению инструментов OAM и набор поддерживаемых ими операций. Набор требуемых механизмов более подробно рассмотрен в [TP-OAM-FW], где описана общая архитектура системы OAM и приведен обзор функций инструментов.

Некоторое базовые требования к набору инструментов OAM для MPLS-TP приведены ниже.

• От MPLS-TP OAM требуется поддержка работа в средах как с поддержкой IP, так и без таковой. В среде IP, где доступна маршрутизация и пересылка IP, инструментам MPLS-TP OAM следует опираться на возможности маршрутизации и пересылки IP. В остальных средах инструменты OAM должны быть способны обходиться без маршрутизации и пересылки IP.

• Пакеты OAM должны передаваться вместе с пользовательским трафиком (в основной полосе) и не требуется различать эти типы пакетов на уровне данных. С этим требованием связан принцип независимости MPLS-TP OAM от имеющегося уровня управления, хотя это не должно исключать возможности применения функциональности уровня управления. Пакеты OAM указываются меткой GAL¹⁰, для которой в MPLS зарезервировано значение 13.

4.5.2. Терминология

Элемент обслуживания (ME)

Инструменты MPLS-TP OAM разработаны для мониторинга и управления ME. В соответствии с [TP-OAM-FW] ME определят связи (отношения) между двумя точками транспортного пути, к которым применяются операции мониторинга и управления.

Термин Maintenance Entity (ME) используется в рекомендациях ITU-T (например, [ITU-T-Y1731]), а также в терминологии MPLS-TP ([TP-OAM-FW]).

Группа элементов обслуживания (MEG)

Один или множество ME на одном транспортном пути, для которых выполняется общий мониторинг и управление (см. [TP-OAM-FW]).

Точка обслуживания (MP)

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

Термин MP используется в IEEE 802.1ag и был адаптирован в MPLS-TP ([TP-OAM-FW]).

MEG End Point (MEP)

Конечной точкой ME (MEP) называют каждую из точек ME, она может инициировать сообщения OAM и/или отвечать на них (см. [TP-OAM-FW]).

MEG Intermediate Point (MIP)

Между MEP может присутствовать одна или множество промежуточных точек ME (см. [TP-OAM-FW]).

Точки MIP обычно не создают кадров OAM (за исключением используемых для уведомлений AIS), но способны реагировать на приходящие кадры OAM. MIP в MPLS-TP идентифицируют пакеты OAM, адресованные им, по истечени срока жизни (поле TTL) пакета OAM. Термин «точка обслуживания» (MP) обычно включает MEP и MIP.

Восходящие (Up) и нисходящие (Down) MEP

В IEEE 802.1ag [IEEE802.1Q] определено различие между Up MEP и Down MEP. MEP выполняет мониторинг трафика в направлении сети или в направлении моста. Down MEP — это точка MEP, принимающая пакеты OAM из сети и передающая такие пакеты в направлении сети. Up MEP принимает пакеты от моста и передает в направлении моста. В MPLS-TP ([TP-OAM-FW]) используется похожее различие в местоположении MEP — входная, выходная или пересылающая функция узла (Down/Up MEP). Размещение важно при определении точки отказа.

Отметим, что термины Up MEP и Down MEP никак не связаны с обычно применяемыми терминами Up/Down, где Down говорит о нерабочем, а Up — о рабочем состоянии.

Это различие между Up и Down MEP определено в [TP-OAM-FW], но не применялось в других MPLS-TP RFC на момент написания этого документа.

4.5.3. Базовый связанный канал

Для выполнения требований передачи трафика MPLS-TP OAM в основной полосе MPLS-TP использует базовый связанный канал G-ACh, определенный в [G-ACh] для трафика OAM на базе LSP. Этот механизм основан на тех же концепциях, которые применяются механизмами PWE3 ACH [PW-ACH] и VCCV [VCCV]. Однако для удовлетворения потребностей LSP, отличающихся от PW, были определены две приведенные ниже концепции [G-ACh].

• Заголовок связанного канала (ACH), формат которого похож на PW Control Word [PW-ACH], является 4-байтовым заголовком в начале пакетов OAM.

• Метка базового связанного канала GAL с зарезервированным в MPLS значением 13 указывает, что пакет относится к ACH и данные следуют сразу за стеком меток.

Хотя G-ACh был определен как часть MPLS-TP, следует отметить, что G-ACh является базовым средством, которое можно применять в MPLS в целом, а не только в MPLS-TP.

4.5.4. Инструменты MPLS-TP OAM

Для реализации требуемой от набора инструментов OAM функциональности рабочая группа MPLS провела анализ имеющихся инструментов OAM от IETF и ITU-T. Результаты анализа опубликованы в [OAM-Analys]. MPLS-TP использует комбинацию инструментов OAM, основанную на предшествующих стандартах и адаптированную к требованиям [MPLS-TP-OAM]. Базовые блоки этого решения включают:

• двухстороннее детектирование пересылки ([BFD], [BFD-LSP]) для проактивных тестов CC и CV;

• LSP Ping [LSP-Ping] дле тестов CV по запросу;

• новые пакеты протокола, использующие G-ACH для расширения функцинальности;

• протоколы измерения производительности.

В следующих параграфах описаны инструменты OAM, определенные для MPLS-TP [TP-OAM-FW].

4.5.4.1. Проверка непрерывности и связности

Тесты CC и CV представлены в параграфе 2.2.7 этого документа. Как показано здесь, эти инструменты могут использоваться проактивно или по запросу. В проактивном режиме инструменты обычно применяются в тандеме.

Для MPLS-TP имеется два разных инструмента — проактивный определен в [TP-CC-CV], а используемый по запросу — в [OnDemand-CV]. При работе по запросам эта функция должна поддерживать мониторинг между MEP, а также между MEP и MIP. В [TP-OAM-FW] отмечено, что в тестах CV требуется включать в сообщения CC-V однозначное указание MEG для мониторинга и MEP — инициатора сообщения.

Проактивный инструмент [TP-CC-CV] основан на расширении BFD (параграф 4.3) с дополнительным ограничением скорости передачи и приема на основе конфигурации, заданной оператором. Инструмент для проверок по запросу [OnDemand-CV] является адаптацией LSP Ping (параграф 4.4.1) в соответствии с требованиями MPLS-TP.

4.5.4.2. Трассировка маршрута

[MPLS-TP-OAM] указывает потребность в функциональности, позволяющей конечной точке пути идентифицировать промежуточные и конечные точки пути. Эта функция будет применяться в тестах по запросу. Обычно такой путь применяется для двухсторонних PW, LSP и секций (Section), а односторонние пути могут поддерживаться лишь при наличии пути возврата. Инструмент для этого основан на функциональности LSP Ping (параграф 4.4.1) и описан в [OnDemand-CV].

4.5.4.3. Блокировка пути

Функция Lock Instruct [Lock-Loop] служит для уведомления конечной точки транспортного пути о необходимости административного запрета транспортного пути. Обычно это применяется вместе с той или иной интрузивной функцией OAM, например, измерением производительности или диагностическим тестированием, для минимизации побочного влияния на пользовательский трафик.

4.5.4.4. Сообщение о блокировке

Функция Lock Reporting применяется конечной точкой пути для информирования удаленной стороны о блокировке, влияющей на путь.

4.5.4.5. Сообщение о тревоге

Сообщения о тревоге [TP-Fault] позволяют подавить аварийные сигналы после обнаружения неполадок на серверном подуровне. Эти сообщения применяются промежуточными точками пути, которые узнают о сбое в пути и информируют об этом конечные точки. В [TP-OAM-FW] указано, что это может быть результатом дефекта, обнаруженного на серверном подуровне. Генерируется сигнал AIS, который сохраняется до устранения проблемы. Последующие действия этой функции описаны в [TP-OAM-FW].

4.5.4.6. Индикация удаленного дефекта (RDI)

RDI применяется проактивно конечной точкой пути для уведомления партнерской конечной точки о дефекте, обнаруженном в двухсторонних коммуникациях между ними. В [MPLS-TP-OAM] указано, что эта функция может быть применена к односторонним LSP лишь при наличии пути возврата. В [TP-OAM-FW] указано, что эта функция связана с проактивной функцией CC-V.

4.5.4.7. Индикация отказа клиента (CFI)

Функция CFI определена в [MPLS-TP-OAM] для того, что позволить распространение информации с одного края сети на другой. Эта информация относится к дефектам клиентов, при которых клиент не может поддерживать уведомлений о тревоге.

4.5.4.8. Мониторинг производительности

Определение мониторинга производительности MPLS было вызвано требованиями MPLS-TP [MPLS-TP-OAM], но дано в общем виде для MPLS в [MPLS-LM-DM]. Дополнительный документ [TP-LM-DM] определяет профиль мониторинга производительности для MPLS-TP.

4.5.4.8.1. Измерение потерь (LM)

Функция измерения потери пакетов служит для проверки качества обслуживания. Потеря пакетов в соответствии с [IPPM-1LM] и [MPLS-TP-OAM] показывает отношение числа потерянных пользовательских пакетов к общему числу пакетов, переданных в интервале времени.

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

• При использовании пакетов OAM можно рассчитать статистику на основе серии пакетов OAM. Однако этот показатель является искусственным и может не отражать реальность, поскольку часть потерь пакетов может зависеть от их размера и реализации MEP, участвующих в протоколе.

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

4.5.4.8.2. Измерение задержки (DM)

Функция измерения задержки служит для определения задержки в одно или двух направлениях между парой конечных точек пути (PW, LSP, Section).

• Односторонняя задержка в соответствии с [IPPM-1DM] — это время от начала передачи первого бита пакета узлом-источником до получения последнего бита приемником. Отметим, что это измерение требует синхронизации часов в конечных точках.

• Двухсторонняя задержка в соответствии с [IPPM-2DM] — это время от начала передачи первого бита пакета узлом-источником до получения последнего бита этим же узлом после «заворота» пакета на удаленной стороне. Отметим, что в результате асимметрии пути односторонняя задержка между точками может отличаться от половины значения двухсторонней задержки. Синхронизация часов при измерении двухсторонней задержки не требуется.

Для каждой из этих функций DM возможно измерение как задержки, так и ее вариаций. Измерение задержки выполняется с помощью пакетов OAM с временными метками, передаваемых между участвующими MEP.

4.6. OAM для псевдопроводов

4.6.1. OAM для псевдопроводов с использованием VCCV

VCCV в соответствии с [VCCV] обеспечивает способ сквозного детектирования отказов и средства диагностики для PW (независимо от технологии туннелирования). Функция коммутации VCCV обеспечивает канал управления (CC), связанный с каждым PW. [VCCV] определяет три типа CC, т. е. 3 возможных метода передачи и идентификации сообщений OAM.

• Тип 1. VCCV по основному каналу, как описано в [VCCV], называется также PWE3 Control Word with 0001b as first nibble¹¹. Используется заголовок связанного канала PW [PW-ACH].

• Тип 2. VCCV по отдельному каналу, как описано в [VCCV], называется также MPLS Router Alert Label. Канал управления создается с помощью метки MPLS router alert [MPLS-ENCAPS] непосредственно над меткой PW.

• Тип 3. VCCV с минимальным TTL, как описано в [VCCV], называется также MPLS PW Label with TTL == 1, где канал управления указывается значение TTL = 1 в метке PW.

VCCV в настоящее время поддерживает инструменты OAM ICMP Ping, LSP Ping и BFD. ICMP и LSP Ping инкапсулируются в IP перед отправкой через PW ACH. BFD для VCCV [BFD-VCCV] поддерживает два режима инкапсуляции — IP/UDP (с заголовокм IP/UDP) или PW-ACH (без заголовка IP/UDP) и обеспечивает поддержку сигнализации состояния AC. Использование канала управления VCCV обеспечивает контекст, основанный на метке MPLS-PW, который нужен для привязки и загрузки сессии BFD для конкретного псевдопровода (FEC), избавляя от необходимости обмена значениями Discriminator.

VCCV состоит из двух компонент: (1) сигнальная компонента для передачи возможностей VCCV как часть метки VC и (2) коммутационная компонента, заставляющая трактовать данные PW как пакет управления.

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

Рабочая группа PWE3 провела исследование VCCV [VCCV-SURVEY] и анализ применяемых на практике механизмов.

4.6.2. OAM для псевдопроводов с использованием G-ACh

Как отмечено выше, VCCV поддерживает OAM для PW за счет применения канала управления (CC) для пакетов OAM. При использовании PW в сетях MPLS-TP вместо CC, определенных в VCCV, можно применять G-ACh, как определено в [PW-G-ACh].

4.6.3. Устройство присоединения — отображение псевдопровода

Рабочая группа PWE3 определила отображение и уведомление о дефектных состояниях между псевдопроводом (PW) и устройствами присоединения (AC¹²) при сквозной эмуляции сервиса. Это отображение очень важно для сквозной функциональности. Отображение обеспечивается, в частности, [PW-MAP], [L2TP-EC] для псевдопроводов L2TPv3 и параграфом 5.3 [ATM-L2] для ATM.

В [L2VPN-OAM] приведены требования и схема OAM в контексте L2VPN и определены уровни OAM для L2VPN на основе псевдопроводов.

Отображение, заданное в [Eth-Int], позволяет организовать сквозную эмуляцию Ethernet через псевдопровода.

4.7. OWAMP и TWAMP

4.7.1. Обзор

Рабочая группа IPPM в IETF определила общие критерии и метрику для мониторинга производительности IP ([IPPM-FW]). В RFC, опубликованных этой группой, определена метрика для проверки связности [IPPM-Con], измерения задержки ([IPPM-1DM], [IPPM-2DM]) и потери пакетов [IPPM-1LM]. Следует отметить, что работа IETF в контексте метрики производительности не ограничивается сетями IP. В [PM-CONS] представлены общие рекомендации для рассмотрения новых параметров производительности.

Рабочая группа IPPM определила не только метрику измерения производительности, но и протоколы для выполнения измерений. В [OWAMP] и [TWAMP] определены методы и протоколы измерения производительности в сетях IP.

OWAMP [OWAMP] позволяет измерять в одном направлении характеристики сетей IP, такие как задержка и потеря пакетов. Для корректной работы OWAMP требуется корректная установка времени суток на всех конечных точках.

Протокол TWAMP [TWAMP] обеспечивает похожую функциональность и позволяет проводить измерения в одном или двух (round-trip — круговой обход) направлениях.

OWAMP и TWAMP включают в себя по два протокола, указанных ниже.

• OWAMP-Control/TWAMP-Control служит для инициирования, запуска и остановки тестовых сессий, а также сбора результатов теста. Тесты CC и CV выполняются и подтверждаются с помощью организации соединения TCP для управляющего протокола OWAMP/TWAMP.

• OWAMP-Test/TWAMP-Test служит для обмена тестовыми пакетами между двумя узлами. Поддерживаются функции измерения задержки и потерь, а также обнаружение иных аномалий, таких как дублирование и изменение порядка пакетов.

Хотя [OWAMP] и [TWAMP] определяют инструменты для измерения производительности, следует отметить, что точность этих инструментов не задается и зависит от масштаба, реализации и конфигурации сети.

Для мониторинга производительности определены и другие протоколы, например, в MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]) и Ethernet OAM [ITU-T-Y1731].

4.7.2. Протоколы управления и тестирования

Протоколы управления OWAMP и TWAMP работают на основе TCP, а протоколы тестирования применяют UDP. Задача протоколов управления заключается в инициировании, запуске и остановке тестовой сессии, а для OWAMP также в сборе результатов. Протоколы тестирования передают тестовые пакеты (с порядковыми номерами и временными метками) по тестируемому пути IP в соответствии с планированием, а затем записывают статистику прибывших пакетов. Можно одновременно организовать множество сессий, каждая из которых будет иметь свой идентификатор, и задать число передаваемых пакетов, размер заполнения (размер пакета), время начала и планирование передачи (постоянный или псевдослучайный интервал с экспоненциальным распределением). Статистика записывается в соответствии с подходящими IPPM RFC.

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

4.7.3. OWAMP

OWAMP определяет логические роли Session-Sender, Session-Receiver, Server, Control-Client и Fetch-Client. Session-Sender создает тестовый трафик, который принимает Session-Receiver. Server настраивает и поддерживает сессию, а также возвращает результаты. Control-Client инициирует запросы тестовых сессий, запускает сессии и может инициировать их завершение. Fetch-Client запрашивает результаты завершенной сессии. Один хост может выступать одновременно в нескольких ролях, например, Control-Client, Fetch-Client и Session-Sender, а другой может выступать в качестве Server и Session-Receiver.

В типичной сессии OWAMP элемент Control-Client организует соединение TCP с портом 861 на элементе Server, который отвечает приветственным сообщением, указывающим поддерживаемые режимы защиты и целостности. Control-Client отвечает с использованием выбранного режима коммуникаций и Server воспринимает этот режим. Затем Control-Client запрашивает и полностью описывает тестовую сессию, а Server отвечает информацией о приемлемости и поддержке. Дополнительные сообщения позволяют запросить несколько сессий. Далее Control-Client запускает тестовую сессию, Server подтверждает ее и инструктирует элемент Session-Sender начать тест. Session-Sender передает тестовые пакеты с псевдослучайным заполнением элементу Session-Receiver, пока сессия не будет завершена или Control-Client не остановит ее.

По завершении Session-Sender передает элементу Server отчет с данными от Session-Receiver. Затем Fetch-Client может передать запрос элементу Server, который отвечает подтверждением и сразу же передает результаты.

4.7.4. TWAMP

TWAMP определяет несколько логических ролей — Session-Sender, Session-Reflector, Server и Control-Client. Они похожи на роли OWAMP, но Session-Reflector не собирает информации о пакетах и не требуется для Fetch-Client.

В типовой сессии TWAMP элемент Control-Client организует соединение TCP с портом 862 на сервере и режим согласуется как в OWAMP. Затем Control-Client запрашивает сессию и начинает ее. Session-Sender передает тестовые пакеты с псевдослучайным заполнением элементу Session-Reflector, который возвращает их с временной меткой.

4.8. TRILL

Требования к OAM для TRILL заданы в [TRILL-OAM]. Проблема TRILL OAM, похожая на случай MPLS, состоит в том, что трафик между RBridge RB1 и RB2 может пересылаться по множеству путей. Поэтому протокол OAM между RB1 и RB2 должен быть способен отслеживать все доступные пути между парой мостов RBridge.

На момент написания этого документа процесс определения инструментов TRILL OAM еще не был завершен. В этом параграфе приведены основные требования TRILL OAM [TRILL-OAM].

• Проверка непрерывности (CC) — протокол TRILL OAM должен поддерживать функцию CC между любой парой RBridge.

• Проверка связности (CV) — связность между парой RBridge может быть проверена на уровне потока.

• Трассировка пути позволяет RBridge отследить все доступные пути к партнерскому RBridge.

• Мониторинг производительности позволяет RBridge отслеживать потери и задержки пакетов, отправленных партнерскому RBridge.

5. Сводка

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

5.1. Сводка инструментов OAM

В этом параграфе приведена краткая сводка описанных в документе наборов инструментов OAM.

Подробный список RFC, относящихся к каждому набору, приведен в приложении A.1.

Таблица 3. Связанные с OAM инструменты IETF.

Инструмент	Описание	Технология
IP Ping	Ping ([IntHost], [NetTerms]) представляет собой простую программу для тестирования доступности с использованием сообщений ICMP Echo ([ICMPv4], [ICMPv6]).	IPv4/IPv6
IP Traceroute	Traceroute ([TCPIP-Tools], [NetTools]) является приложением, которое позволяет пользователям трассировать путь между источником и адресатом IP с идентификацией промежуточных узлов пути. При наличии нескольких путей Traceroute проверяет один из них. Наиболее распространенная реализация Traceroute использует сообщения UDP, хотя есть и реализации на основе протоколов ICMP и TCP. Paris Traceroute [PARIS] является расширением, которое пытается найти все доступные пути между точками A и B путем сканирования различных полей заголовков.	IPv4/IPv6
BFD	Двухстороннее детектирование пересылки (BFD) определено в [BFD] как модель облегченного базового инструмента OAM. Целью является определение базового средства для использования с разными типами инкапсуляции, сетевого окружения и сред передачи.	Все
MPLS OAM	MPLS LSP Ping в соответствии с определением [MPLS-OAM], [MPLS-OAM-FW] и [LSP-Ping] является инструментом OAM для парных и многоточечных MPLS LSP. Инструмент имеет две основных функции — Ping и Traceroute. BFD [BFD-LSP] является дополнительным средством поиска отказов на уровне данных MPLS LSP.	MPLS
MPLS-TP OAM	Средства MPLS-TP OAM определены в нескольких RFC. Требования OAM для транспортного профиля MPLS (MPLS-TP) заданы в [MPLS-TP-OAM]. Каждый из инструментов набора OAM определен в своем RFC, как указано в приложении A.1.	MPLS-TP
OWAMP и TWAMP	Протоколы активного измерения в одном [OWAMP] и двух [TWAMP] направлениях определены рабочей группой IP Performance Metrics (IPPM) в IETF. Эти протоколы позволяют измерять разные параметры, включая потерю пакетов, задержку и ее вариации, дублирование и изменение порядка доставки.	IPv4/IPv6
Pseudowire OAM	Архитектура PWE3 OAM определяет каналы управления, поддерживающие использование имеющихся инструментов IETF OAM для псевдопровода (PW). Каналы управления, определенные в [VCCV] и [PW-G-ACh], могут применяться вместе с ICMP Ping, LSP Ping и BFD для выполнения тестов CC и CV. Кроме того, каналы поддерживают использование любых инструментов OAM на базе MPLS-TP для распространения их функциональности на PW.	Pseudowire
TRILL OAM	Требования к OAM в TRILL определены в [TRILL-OAM] и включают, CC, CV, трассировку пути и мониторинг производительности. На момент написания этого документа работа по детальному определению инструментов TRILL OAM не была завершена.	TRILL

5.2. Сводка функций OAM

В таблице 4 указаны функции OAM, поддерживаемые каждым набором инструментов, который рассмотрен в этом разделе. В столбцах таблицы указаны типовые функции OAM, описанные в параграфе 1.3.

Таблица 4. Функциональность OAM в инструментах IETF OAM.

Инструменты	Проверка связности	Верификация связности	Обнаружение пути	Мониторинг производит.	Другие функции
IP Ping	Echo
IPTraceroute			Traceroute
BFD	BFD Control/Echo	BFD Control			RDI с применением BFD Control
MPLS OAM (LSP Ping)		Режим Ping	Режим Traceroute
MPLS-TP OAM	CC	CV (проактивно или по запросу)	Трассировка маршрута	-LM -DM	-Diagnostic Test -Lock -Alarm Reporting -Client Failure Indication -RDI
Pseudowire OAM	BFD	-BFD -ICMP Ping -LSP Ping	LSP Ping	-DM -LM
OWAMP и TWAMP	Протокол управления
TRILL OAM	CC	CV	Трассировка пути	-DM -LM

5.3. Рекомендации производителям сетевого оборудования

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

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

OAM имеет тесную связь со стабильностью сети. Успешная атака на протокол OAM может создать иллюзию отказов или воспрепятствовать детектированию реальных отказов и это может приводить к отказам в обслуживании.

Некоторые из представленных в документе инструментов OAM включают механизмы безопасности, обеспечивающие защиту целостности, что позволяет предотвратить подмену и искажение атакующими пакетов OAM. Например, [BFD] включает необязательный механизм аутентификации для пакетов BFD Control с использованием SHA1, MD5 или простого пароля. В [OWAMP] и [TWAMP] имеется 3 режима защиты — без аутентификации (unauthenticated), с аутентификацией (authenticated) и шифрование (encrypted). Для аутентификации применяется SHA1 в качестве алгоритма HMAC, а для шифрования служит алгоритм AES.

Конфиденциальность обычно не требуется от протоколов OAM. Однако использование шифрования (например, в [OWAMP] и [TWAMP]) может усложнить атакующим идентификацию пакетов OAM и атаки на протоколы OAM.

OAM может применяться также в качестве средства зондирования сети — данные об адресах, номерах портов, топологии и производительности сети могут быть получены путем пассивного перехвата пакетов OAM или активной генерации пакетов OAM и сбора откликов на них. Полученная информация может применяться для организации атак. Отметим, что часть такой информации (например, адреса и номера портов) может быть получена даже при использовании шифрования ([OWAMP], [TWAMP]).

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

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

Авторы признательны Sasha Vainshtein, Carlos Pignataro, David Harrington, Dan Romascanu, Ron Bonica, Benoit Claise, Stewart Bryant, Tom Nadeau, Elwyn Davies, Al Morton, Sam Aldrin, Thomas Narten и другим членам рабочей группы OPSA WG за полезные комментарии в почтовой конференции.

Этот документ был подготовлен с использованием шаблона 2-Word-v2.0.template.dot.

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

8.1. Нормативные документы

[OAM-Def] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, «Guidelines for the Use of the «OAM» Acronym in the IETF», BCP 161, RFC 6291, June 2011.

8.2. Дополнительная литература

[ATM-L2] Singh, S., Townsley, M., and C. Pignataro, «Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)», RFC 4454, May 2006.

[BFD] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD)», RFC 5880, June 2010.

[BFD-Gen] Katz, D. and D. Ward, «Generic Application of Bidirectional Forwarding Detection (BFD)», RFC 5882, June 2010.

[BFD-IP] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)», RFC 5881, June 2010.

[BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, «Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)», RFC 5884, June 2010.

[BFD-Multi] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD) for Multihop Paths», RFC 5883, June 2010.

[BFD-VCCV] Nadeau, T., Ed., and C. Pignataro, Ed., «Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)», RFC 5885, June 2010.

[Comp] Bonaventure, O., «Computer Networking: Principles, Protocols and Practice», 2008.

[Dup] Uijterwaal, H., «A One-Way Packet Duplication Metric», RFC 5560, May 2009.

[Eth-Int] Mohan, D., Ed., Bitar, N., Ed., Sajassi, A., Ed., DeLord, S., Niger, P., and R. Qiu, «MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking», RFC 7023, October 2013.

[G-ACh] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., «MPLS Generic Associated Channel», RFC 5586, June 2009.

[ICMP-Ext] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, «ICMP Extensions for Multiprotocol Label Switching», RFC 4950, August 2007.

[ICMP-Int] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, N., and JR. Rivers, «Extending ICMP for Interface and Next-Hop Identification», RFC 5837, April 2010.

[ICMP-MP] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, «Extended ICMP to Support Multi-Part Messages», RFC 4884, April 2007.

[ICMPv4] Postel, J., «Internet Control Message Protocol», STD 5, RFC 792, September 1981.

[ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 4443, March 2006.

[IEEE802.1Q] IEEE, «IEEE Standard for Local and metropolitan area networks — Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks», IEEE 802.1Q, October 2012.

[IEEE802.3ah] IEEE, «IEEE Standard for Information technology — Local and metropolitan area networks — Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications», IEEE 802.3ah, clause 57, December 2008.

[IntHost] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[IPPM-1DM] Almes, G., Kalidindi, S., and M. Zekauskas, «A One-way Delay Metric for IPPM», RFC 2679, September 1999.

[IPPM-1LM] Almes, G., Kalidindi, S., and M. Zekauskas, «A One-way Packet Loss Metric for IPPM», RFC 2680, September 1999.

[IPPM-2DM] Almes, G., Kalidindi, S., and M. Zekauskas, «A Round-trip Delay Metric for IPPM», RFC 2681, September 1999.

[IPPM-Con] Mahdavi, J. and V. Paxson, «IPPM Metrics for Measuring Connectivity», RFC 2678, September 1999.

[IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, «Framework for IP Performance Metrics», RFC 2330, May 1998.

[ITU-G8113.1] ITU-T, «Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)», ITU-T Recommendation G.8113.1/Y.1372.1, November 2012.

[ITU-G8113.2] ITU-T, «Operations, administration and maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS», ITU-T Recommendation G.8113.2/Y.1372.2, November 2012.

[ITU-T-CT] Betts, M., «Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)», RFC 6671, November 2012.

[ITU-T-G.806] ITU-T, «Characteristics of transport equipment — Description methodology and generic functionality», ITU-T Recommendation G.806, January 2009.

[ITU-T-Y1711] ITU-T, «Operation & Maintenance mechanism for MPLS networks», ITU-T Recommendation Y.1711, February 2004.

[ITU-T-Y1731] ITU-T, «OAM Functions and Mechanisms for Ethernet-based Networks», ITU-T Recommendation G.8013/Y.1731, July 2011.

[ITU-Terms] ITU-R/ITU-T, «ITU-R/ITU-T Terms and Definitions», 2013, <http://www.itu.int/pub/R-TER-DB>.

[L2TP-EC] McGill, N. and C. Pignataro, «Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values», RFC 5641, August 2009.

[L2VPN-OAM] Sajassi, A., Ed., and D. Mohan, Ed., «Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework», RFC 6136, March 2011.

[L3VPN-OAM] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, «Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management», RFC 4176, October 2005.

[Lock-Loop] Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed., Vigoureux, M., Ed., and X. Dai, Ed., «MPLS Transport Profile Lock Instruct and Loopback Functions», RFC 6435, November 2011.

[LSP-Ping] Kompella, K. and G. Swallow, «Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures», RFC 4379, February 2006.

[Mng] Farrel, A., «Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts», RFC 6123, February 2011.

[MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, «MPLS Label Stack Encoding», RFC 3032, January 2001.

[MPLS-LM-DM] Frost, D. and S. Bryant, «Packet Loss and Delay Measurement for MPLS Networks», RFC 6374, September 2011.

[MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, «Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks», RFC 4377, February 2006.

[MPLS-OAM-FW] Allan, D., Ed., and T. Nadeau, Ed., «A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)», RFC 4378, February 2006.

[MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, «Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks», RFC 4687, September 2006.

[MPLS-TP-OAM] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., «Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks», RFC 5860, May 2010.

[mtrace] Fenner, W. and S. Casner, «A «traceroute» facility for IP Multicast», Work in Progress, July 2000.

[NetTerms] Jacobsen, O. and D. Lynch, «A Glossary of Networking Terms», RFC 1208, March 1991.

[NetTools] Enger, R. and J. Reynolds, «FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices», FYI 2, RFC 1470, June 1993.

[OAM-Analys] Sprecher, N. and L. Fang, «An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks», RFC 6669, July 2012.

[OAM-Label] Ohta, H., «Assignment of the ‘OAM Alert Label’ for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions», RFC 3429, November 2002.

[OAM-Mng] Ersue, M., Ed., and B. Claise, «An Overview of the IETF Network Management Standards», RFC 6632, June 2012.

[OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, «MPLS On-Demand Connectivity Verification and Route Tracing», RFC 6426, November 2011.

[OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, «A One-way Active Measurement Protocol (OWAMP)», RFC 4656, September 2006.

[PARIS] Augustin, B., Friedman, T., and R. Teixeira, «Measuring Load-balanced Paths in the Internet», IMC ’07 Proceedings of the 7th ACM SIGCOMM conference on Internet measurement, 2007.

[PM-CONS] Clark, A. and B. Claise, «Guidelines for Considering New Performance Metric Development», BCP 170, RFC 6390, October 2011.

[PW-ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson, «Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN», RFC 4385, February 2006.

[PW-G-ACh] Li, H., Martini, L., He, J., and F. Huang, «Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)», RFC 6423, November 2011.

[PW-MAP] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., Nadeau, T., and Y(J). Stein, «Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping», RFC 6310, July 2011.

[Reorder] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, «Packet Reordering Metrics», RFC 4737, November 2006.

[Signal] Yasukawa, S., Ed., «Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)», RFC 4461, April 2006.

[TCPIP-Tools] Kessler, G. and S. Shepard, «A Primer On Internet and TCP/IP Tools and Utilities», FYI 30, RFC 2151, June 1997.

[TP-CC-CV] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed., «Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile», RFC 6428, November 2011.

[TP-Fault] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed., Boutros, S., and D. Ward, «MPLS Fault Management Operations, Administration, and Maintenance (OAM)», RFC 6427, November 2011.

[TP-LM-DM] Frost, D., Ed., and S. Bryant, Ed., «A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks», RFC 6375, September 2011.

[TP-OAM-FW] Busi, I., Ed., and D. Allan, Ed., «Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks», RFC 6371, September 2011.

[TP-Term] van Helvoort, H., Ed., Andersson, L., Ed., and N. Sprecher, Ed., «A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T’s Transport Network Recommendations», RFC 7087, December 2013.

[TRILL-OAM] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. Watve, «Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)», RFC 6905, March 2013.

[TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, «A Two-Way Active Measurement Protocol (TWAMP)», RFC 5357, October 2008.

[VCCV] Nadeau, T., Ed., and C. Pignataro, Ed., «Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires», RFC 5085, December 2007.

[VCCV-SURVEY] Del Regno, N., Ed., and A. Malis, Ed., «The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results», RFC 7079, November 2013.

Приложение A. Список документов OAM

A.1. Список документов IETF OAM

В таблице 5 перечислены связанные с OAM документы RFC, выпущенные IETF.

Важно подчеркнуть, что в таблице указаны разные по природе RFC. Например, некоторые из этих документов определяют инструменты или протоколы OAM (или то и другое), а другие определяют протоколы, не связанные напрямую с OAM, но применяемые инструментами OAM. В таблицу также включены RFC, определяющие требования к схемам OAM в конкретном контексте (например, MPLS-TP).

RFC в таблице разбиты по категориям, определенным в параграфе 1.3.

Таблица 5. Список RFC, связанных с IETF OAM.

Инструмент	Название документа	Документ
IP Ping	Requirements for Internet Hosts — Communication Layers [IntHost]	RFC 1122
	A Glossary of Networking Terms [NetTerms]	RFC 1208
	Internet Control Message Protocol [ICMPv4]	RFC 792
	Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [ICMPv6]	RFC 4443
IP Traceroute	A Primer On Internet and TCP/IP Tools and Utilities [TCPIP-Tools]	RFC 2151
	FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices [NetTools]	RFC 1470
	Internet Control Message Protocol [ICMPv4]	RFC 792
	Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification [ICMPv6]	RFC 4443
	Extended ICMP to Support Multi-Part Messages [ICMP-MP]	RFC 4884
	Extending ICMP for Interface and Next-Hop Identification [ICMP-Int]	RFC 5837
BFD	Bidirectional Forwarding Detection (BFD) [BFD]	RFC 5880
	Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) [BFD-IP]	RFC 5881
	Generic Application of Bidirectional Forwarding Detection (BFD)[BFD-Gen]	RFC 5882
	Bidirectional Forwarding Detection (BFD) for Multihop Paths [BFD-Multi]	RFC 5883
	Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) [BFD-LSP]	RFC 5884
	Bidirectional Forwarding Detection for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) [BFD-VCCV]	RFC 5885
MPLS OAM	Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks [MPLS-OAM]	RFC 4377
	A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) [MPLS-OAM-FW]	RFC 4378
	Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures [LSP-Ping]	RFC 4379
	Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks [MPLS-P2MP]	RFC 4687
	ICMP Extensions for Multiprotocol Label Switching [ICMP-Ext]	RFC 4950
	Bidirectional Forwarding Detection for MPLS Label Switched Paths (LSPs) [BFD-LSP]	RFC 5884
MPLS-TP OAM	Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks [MPLS-TP-OAM]	RFC 5860
	MPLS Generic Associated Channel [G-ACh]	RFC 5586
	Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks [TP-OAM-FW]	RFC 6371
	Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile [TP-CC-CV]	RFC 6428
	MPLS On-Demand Connectivity Verification and Route Tracing [OnDemand-CV]	RFC 6426
	MPLS Fault Management Operations, Administration, and Maintenance (OAM) [TP-Fault]	RFC 6427
	MPLS Transport Profile Lock Instruct and Loopback Functions [Lock-Loop]	RFC 6435
	Packet Loss and Delay Measurement for MPLS Networks [MPLS-LM-DM]	RFC 6374
	A Packet Loss and Delay Measurement Profile for MPLS-Based Transport [TP-LM-DM]	RFC 6375
Pseudowire OAM	Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires [VCCV]	RFC 5085
	Bidirectional Forwarding Detection for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) [BFD-VCCV]	RFC 5885
	Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) [PW-G-ACh]	RFC 6423
	Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping [PW-MAP]	RFC 6310
	MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking [Eth-Int]	RFC 7023
OWAMP и TWAMP	A One-way Active Measurement Protocol (OWAMP) [OWAMP]	RFC 4656
	A Two-Way Active Measurement Protocol (TWAMP) [TWAMP]	RFC 5357
	Framework for IP Performance Metrics [IPPM-FW]	RFC 2330
	IPPM Metrics for Measuring Connectivity [IPPM-Con]	RFC 2678
	A One-way Delay Metric for IPPM [IPPM-1DM]	RFC 2679
	A One-way Packet Loss Metric for IPPM [IPPM-1LM]	RFC 2680
	A Round-trip Delay Metric for IPPM [IPPM-2DM]	RFC 2681
	Packet Reordering Metrics [Reorder]	RFC 4737
	A One-Way Packet Duplication Metric [Dup]	RFC 5560
TRILL OAM	Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) [TRILL-OAM]	RFC 6905

A.2. Отдельные документы других организаций

В дополнение к инструментам OAM, определенным IETF, IEEE и ITU-T тоже определили средства OAM для Ethernet и различных транспортных сетевых сред. Эти разные инструменты, определенные 3 организациями, зачастую тесно связаны и влияют друг на друга. ITU-T и IETF определили инструменты OAM для MPLS LSP, [ITU-T-Y1711] и [LSP-Ping]. Перечисленные ниже стандарты OAM от IEEE и ITU-T являются некоторым расширением указанных ранее инструментов IETF OAM и приведены лишь для справки.

• Инструменты OAM для уровня L2 определены ITU-T в [ITU-T-Y1731] и IEEE в 802.1ag [IEEE802.1Q]. Стандарт IEEE 802.3 определяет OAM для одноинтервальных (one-hop) каналов Ethernet [IEEE802.3ah].

• Комитет ITU-T определил OAM для MPLS LSP в [ITU-T-Y1711], MPLS-TP OAM в [ITU-G8113.1] и [ITU-G8113.2].

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

В таблице 6 указаны некоторые стандарты OAM, опубликованные другими организациями (не IETF). Этот документ посвящен стандартам IETF OAM, но перечисленные в таблице документы упоминаются в нем.

Таблица 6. Список связанных с этим документом стандартов других организаций.

	Название документа	Документ
ITU-T MPLS OAM	Operation & Maintenance mechanism for MPLS networks [ITU-T-Y1711]	ITU-T Y.1711
	Assignment of the ‘OAM Alert Label’ for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions [OAM-Label]	RFC 342913
ITU-T MPLS-TP OAM	Operations, administration and Maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS [ITU-G8113.2]14	ITU-T G.8113.2
	Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)	ITU-T G.8113.1
	Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM) [ITU-T-CT]	RFC 667115
ITU-T Ethernet OAM	OAM Functions and Mechanisms for Ethernet-based Networks [ITU-T-Y1731]	ITU-T Y.1731
IEEE CFM	Connectivity Fault Management [IEEE802.1Q]16	IEEE 802.1ag
IEEE DDCFM	Management of Data Driven and Data Dependent Connectivity Faults [IEEE802.1Q]17	IEEE 802.1ag
OAM канального уровня IEEE 802.3	Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks [IEEE802.3ah]18	IEEE 802.3ah

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

Tal Mizrahi

Marvell

6 Hamada St.

Yokneam 20692

Israel

EMail: talmi@marvell.com

Nurit Sprecher

Nokia Solutions and Networks

3 Hanagar St. Neve Ne’eman B

Hod Hasharon 45241

Israel

EMail: nurit.sprecher@nsn.com

Elisa Bellagamba

Ericsson

6 Farogatan St.

Stockholm 164 40

Sweden

Phone: +46 761440785

EMail: elisa.bellagamba@ericsson.com

Yaacov Weingarten

34 Hagefen St.

Karnei Shomron 4485500

Israel

EMail: wyaacov@gmail.com

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

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

nmalykh@protokols.ru