RFC 8372 | Вопросы идентификации потока MPLS

Аннотация

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

Скачать оригинальный документ на английском языке RFC 8372 PDF

1. Введение
2. Вопросы измерения потерь
3. Задержка измерения соображений
4. Единицы идентификации
5. Типы LSP
6. Область сети
7. Обратная совместимость
8. Плоскость данных
9. Плоскость управления
10. Вопросы конфиденциальности
11. Вопросы безопасности
12. Соображения IANA
13. Информационные ссылки
Благодарности
Адреса авторов

Статус этой заметки

Этот документ не является спецификацией Internet Standards Track; опубликовано в ознакомительных целях.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественную рецензию и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Не все документы, утвержденные IESG, являются кандидатами на любой уровень Интернет-стандарта; см. раздел 2 RFC 7841.

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

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

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (https://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

1. Введение

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

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

Кроме того, [RFC6374] не поддерживает различные степени детализации потока и не учитывает ряд случаев, когда два или более входных маршрутизатора с коммутацией по меткам (LSR) могут отправлять пакеты одному или нескольким получателям.

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

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

2. Вопросы измерения потерь

Современные сети, если не превышать подписку, обычно отбрасывают относительно мало пакетов; таким образом, измерение потери пакетов очень чувствительно к общему разграничению точного набора пакетов, которые должны быть измерены для потери. Без какой-либо формы окраски или маркировки партии, такой как предложенная в [RFC8321], может оказаться невозможным достичь требуемой точности при измерении потерь трафика данных клиента. Таким образом, когда требуется точное измерение потери пакетов, может быть экономически выгодным или даже техническим требованием включать некоторую форму маркировки в пакеты для назначения каждого пакета конкретному счетчику для целей измерения потерь.

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

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

Рассмотрение этого решения по изменению метки идентификатора (метка MPLS, обычно используемая для идентификации LSP, виртуальной частной сети, псевдопроводов и т. Д.) Для указания того, что пакет является влиянием, которое это оказывает на путь, выбранный механизмом ECMP. Когда элемент набора путей ECMP выбирается путем глубокой проверки пакетов, изменение пакета, представленное изменением идентификационной метки, не будет влиять на путь ECMP. Если элемент пути выбирается посредством ссылки на метку энтропии [RFC6790], то изменение идентификатора пакета не приведет к изменению выбранного пути ECMP. ECMP настолько распространен в многоточечных (многоточечных) сетях, что необходимо поддерживать некоторый метод избежания ошибок учета, вносимых ECMP.

3. Задержка измерения соображений

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

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

4. Единицы идентификации

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

В этом документе рассматривается идентификация следующих компонентов трафика:

По источникам LSR: все из одного источника агрегируется
Для группы LSP, выбранных входным LSR: входной LSP агрегирует группу LSP (например, все LSP туннеля)
В LSP: основная форма
На поток [RFC6790] в LSP: мелкозернистый метод

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

Таким образом, мы можем охарактеризовать требование идентификации в следующих широких терминах:

Для выходного LSR должен быть какой-то способ идентифицировать входящий LSR с соответствующей степенью охвата. Эта концепция обсуждается далее в разделе 6.
Должен быть способ идентифицировать конкретный LSP на выходном узле. Это позволяет использовать несколько LSP, работающих между одной и той же парой узлов. В таких случаях идентичность входного ЛСР недостаточна.
Для сохранения ресурсов, таких как метки, счетчики и / или вычислительные циклы, может быть желательно идентифицировать группу LSP, чтобы можно было выполнить операцию над группой как совокупность.
Должен быть способ идентифицировать поток в LSP. Это необходимо при исследовании конкретного потока, который был объединен в LSP.

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

5. Типы LSP

Нам необходимо рассмотреть ряд типов LSP. Два самых простых типа для мониторинга — это двухточечные LSP и двухточечные LSP. Входной LSR для двухточечного LSP, например, созданный с использованием протокола сигнализации Resource — Traffic Engineering (RSVP-TE) [RFC5420] или протоколы, соответствующие транспортному профилю MPLS (MPLS-TP) [RFC5654 ], может быть идентифицирован путем проверки верхней метки в стеке, поскольку на любом маршрутизаторе Provredge (PE) или Provider (P) на пути верхняя метка является уникальной для пары вход-выход на каждом переходе на данном уровне в иерархии LSP. При условии, что предпоследний хоп-запрос (PHP) отключен, идентичность входного LSR двухточечного LSP доступна на выходном LSR; Таким образом, определение идентичности входного LSR должно рассматриваться как решенная проблема. Отметим, однако, что идентичность потока не может быть определена без дополнительной информации, переносимой в пакете или получаемой из некоторого аспекта полезной нагрузки пакета.

В случае многоточечного LSP и при отсутствии PHP, идентичность входного LSR также может быть выведена из верхней метки. Однако, возможно, не удастся адекватно определить поток только по верхней метке; таким образом, дополнительная информация может потребоваться перенести в пакет или почерпнуть из некоторого аспекта полезной нагрузки пакета. При разработке любого решения желательно, чтобы общее решение идентификации потока использовалось как для двухточечных, так и для многоточечных типов LSP. Аналогичным образом, желательно использовать общий метод идентификации группы LSP. В вышеупомянутых случаях для предоставления требуемой идентификационной информации необходимо использовать метку контекста [RFC5331]. Это широко поддерживаемая функция MPLS.

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

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

6. Область сети

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

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

7. Обратная совместимость

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

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

8. Плоскость данных

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

Размер стека является проблемой для многих реализаций MPLS как из-за аппаратных ограничений, так и из-за влияния на сети и приложения, в которых необходимо транспортировать большое количество небольших полезных нагрузок. В частности, одна полезная нагрузка MPLS может переноситься внутри другой. Например, один LSP может переноситься по другому LSP, или псевдопровод (PW) или аналогичная конструкция мультиплексирования может переноситься по LSP, и идентификация может потребоваться на обоих уровнях. Особую озабоченность вызывает внедрение недорогих граничных LSR, которые по причинам стоимости имеют значительное ограничение на количество записей стека меток (LSE), которые они могут навязывать или распоряжаться. Следовательно, любой метод идентификации не должен использовать чрезмерное количество уникальных меток и не должен приводить к чрезмерному увеличению размера стека меток.

Конструкция плоскости данных MPLS предусматривает два типа меток специального назначения: оригинальные 16 зарезервированных меток и гораздо больший набор меток специального назначения, определенных в [RFC7274]. Для оригинальных зарезервированных меток требуется одна LSE, а для новых специальных меток [RFC7274] нужны две LSE. Учитывая незначительное количество оригинальных зарезервированных меток, основным принципом философии дизайна MPLS является то, что этот дефицитный ресурс используется только тогда, когда это абсолютно необходимо. Для использования специальной метки для кодирования идентификатора потока требуются две записи стека меток: одна для зарезервированной метки и одна для идентификатора потока. Использование расширенных специальных меток [RFC7274] требует всего трех записей стека меток для кодирования идентификации потока. Большой набор меток [RFC7274] требует двух записей стека меток для самой метки специального назначения; следовательно, для кодирования идентификатора потока необходимо всего три элемента стека меток.

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

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

Любая схема идентификации потока должна стремиться минимизировать сложность плоскости управления и минимизировать количество координации меток, необходимое для LSR.

10. Вопросы конфиденциальности

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

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

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

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

Более подробное обсуждение методов защиты и защиты от атак MPLS см. В разделе «Структура безопасности для сетей MPLS и GMPLS» [RFC5920].

12. Соображения IANA

В этом документе нет соображений IANA.

13. Информационные ссылки

[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, «MPLS Upstream Label Assignment and Context-Specific Label Space», RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.

[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, «Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)», RFC 5420, DOI 10.17487/RFC5420, February 2009, <https://www.rfc-editor.org/info/rfc5420>.

[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, «Requirements of an MPLS Transport Profile», RFC 5654, DOI 10.17487/RFC5654, September 2009, <https://www.rfc-editor.org/info/rfc5654>.

[RFC5920] Fang, L., Ed., «Security Framework for MPLS and GMPLS Networks», RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.

[RFC6374] Frost, D. and S. Bryant, «Packet Loss and Delay Measurement for MPLS Networks», RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.

[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, «The Use of Entropy Labels in MPLS Forwarding», RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.

[RFC7258] Farrell, S. and H. Tschofenig, «Pervasive Monitoring Is an Attack», BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.

[RFC7274] Kompella, K., Andersson, L., and A. Farrel, «Allocating and Retiring Special-Purpose MPLS Labels», RFC 7274, DOI 10.17487/RFC7274, June 2014, <https://www.rfc-editor.org/info/rfc7274>.

[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, «Alternate-Marking Method for Passive and Hybrid Performance Monitoring», RFC 8321, DOI 10.17487/RFC8321, January 2018, <https://www.rfc-editor.org/info/rfc8321>.

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

Авторы выражают благодарность Нобо Акия, Нагендре Кумар Найнар, Джорджу Ласточке и Деборе Брунгард за их комментарии.

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

Stewart Bryant
Huawei
Email: stewart.bryant@gmail.com

Carlos Pignataro
Cisco Systems, Inc.
Email: cpignata@cisco.com

Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com

Zhenbin Li
Huawei
Email: lizhenbin@huawei.com

Gregory Mirsky
ZTE Corp.
Email: gregimirsky@gmail.com