RFC 3260 New Terminology and Clarifications for Diffserv

Network Working Group                                    D. Grossman
Request for Comments: 3260                            Motorola, Inc.
Updates: 2474, 2475, 2597                                 April 2002
Category: Informational

Новая терминология и разъяснения для Diffserv

New Terminology and Clarifications for Diffserv

PDF

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

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

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

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

Тезисы

В этом документе собраны соглашения рабочей группы Diffserv, касающиеся новой и переработанной терминологии, а также обеспечивающие технические разъяснения. Задачей документа является обновление RFC 2474, RFC 2475 и RFC 2597. Предполагается, что при стандартизации RFC 2474 и RFC 2597, а также при обновлении RFC 2475 в новые документы будет включено содержимое данного документа, а сам он после этого утратит силу.

1. Введение

В процессе работы группы Diffserv стало ясно, что в некоторых случаях требуется ввести или уточнить термины и определения для проектов стандартов Diffserv. Кроме того, потребовались некоторые технические разъяснения. Этот документ был создан для публикации достигнутых группой соглашений по этим вопросам и не является попыткой пересмотра базовых RFC или повторного запуска процессов стандартизации. Документ частично обновляет RFC 2474, RFC 2475 и RFC 2597. RFC 2598 был отменен в RFC 3246 и достигнутые группой соглашения включены в новый документ.

2. Терминология, связанная с SLA

Архитектура Diffserv [2] использует термин SLA1 для обозначения сервисных контрактов, которые задают условия пересылки пакетов пользователя. SLA может включать правила классификации трафика, которые (по крайней мере, частично) задают правила «кондиционирования» трафика (TCA2). TCA представляет собой соглашение, задающее правила классификации и соответствующие профили трафика, а также применимые правила метрики, маркировки, отбрасывания и/или «формования» (shaping) трафика.

В процессе работы группы Diffserv (а также в группе Policy [6]) стало понятно, что заключение «соглашения» означает рассмотрение такие аспектов, как цены, договоренности и иные вопросы бизнеса, а также некоторых сугубо технических аспектов. В таких соглашениях могут присутствовать другие технические параметры (например, доступность услуг), которые не являются предметом рассмотрения группы Diffserv. В результате было принято решение, что термины SLA и TCA будут использоваться для представления широкого контекста, а для описания элементов обслуживания и кондиционирования трафика, связанных с Diffserv, будет использоваться новая терминология.

  • Спецификация уровня обслуживания (SLS3) представляет собой набор параметров и их значений, которые совместно определяют сервис, предлагаемый для потока трафика доменом DS4.
  • Спецификация кондиционирования трафика (TCS5) представляет собой набор параметров и их значений, которые совместно задают набор правил классификации и профиль трафика. TCS является неотъемлемой частью SLS.

Отметим, что определение потока трафика не изменилось по сравнению с RFC 2475. Поток трафика может представлять собой отдельный микропоток или группу микропотоков (в домене DS отправителя или получателя), а также может быть BA6. Таким образом, SLS можно применять в домене DS отправителя или получателя для одного или группы микропотоков, а также для BA в любом домене DS.

Отметим также, что определение «политики предоставления услуг» (SPP7) не изменилось по сравнению с RFC 2475, где SPP были определены, как «политика, определяющая настройку кондиционеров трафика на граничных узлах DS о отображения потоков трафика на агрегаты поведения DS для обеспечения спектра услуг». Согласно определению, данному в RFC 3198 [6], политика представляет собой «набор правил для администрирования, управления и контроля доступа к сетевым ресурсам». Следовательно, связи между SLS и SPP заключается в том, что последняя является (отчасти) набором правил, выражающий параметры и диапазоны значений, которые могут использоваться первой.

Отметим, что это определение задает более жесткие ограничения по сравнению с определением в RFC 3198.

3. Использование групп PHB

RFC 2475 определяет группу PHB8 следующим образом:

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

Одна из «стандартных» групп PHB определена в RFC 2597 [3], Assured Forwarding PHB Group. AF9 представляет собой вариант режима пересылки с некоторым выделенным уровнем ресурсов очередей и тремя уровнями предпочтения при отбрасывании. Группа AF PHB Group включает три PHB и использует три кода DSCP10.

RFC 2597 определяет 12 кодов DSCP, соответствующих четырем независимым классам AF — AF1x, AF2x, AF3x и AF4x (где x может принимать значения 1, 2 или 3 для задания предпочтений при отбрасывании). Каждый класс AF имеет свой экземпляр группы AF PHB.

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

Авторам новых спецификаций PHB следует быть аккуратными и придерживаться определения группы PHB в RFC 2475. RFC 2475 не запрещает новым спецификациям PHB выделять достаточное число кодов DSCP для представления множества независимых экземпляров группы PHB. Однако такой набор кодов DSCP не должен указывать на одну группу PHB.

4. Определение поля DS

Diffserv использует шесть битов в заголовке IPV4 или IPV6 для передачи кодов DSCP, которые выбирают PHB. В RFC 2474 была предпринята попытка переименовать октет TOS11 заголовка IPV4 и октет Traffic Class заголовка IPV6 в поле DS. Это поле имеет шесть битов кода DS и два неиспользуемых бита.

Отмечено, что эта попытка привела к несогласованности и неоднозначности. В частности неиспользуемые биты (CU12) поля DS не были выделены для Diffserv и после публикации RFC 2474 эти биты были выделены для явной индикации насыщения (ECN13), определенной в RFC 3168 [4]. В настоящем документе в зависимости от контекста DSCP обозначает коды, которые служат для выбора PHB или часть поля DS, которая содержит эти коды.

Данный текст также не согласуется с BCP 37 (IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers) [5]. Поле типа обслуживания IPV4 (TOS) и поле класса трафика IPV6 были заменены 6-битовым полем DS и 2-битовым полем CU. Агентство IANA выделяет значения поля DS в соответствии с разделом «Согласование с IANA» в RFC 2474, как описано в разделе 8 данного документа.

По согласованному мнению рабочей группы DiffServ говорит, что BCP 37 корректно подтверждает структуру прежних поле TOS и класса трафика.

Следовательно, для использования в будущих документах, включая следующее обновление RFC 2474, нужно применять приведенные ниже определения:

  • поле дифференцированного обслуживания (DS) занимает 6 старших битов (бывшего) октета IPV4 TOS и (бывшего) октета IPV6 Traffic Class;
  • код дифференцированного обслуживания (DSCP) представляет собой значение, кодируемое в поле DS, и каждый узел DS должен использовать это значение для выбора PHB, применяемого для каждого пересылаемого пакета.

Два младших бита октетов IPV4 TOS и IPV6 Traffic Class не используются Diffserv.

При обновлении RFC 2474 следует обратить внимание на замену CU на ECN со ссылкой на RFC 3168 (или его новый вариант).

Следует также обновить упоминание BCP 37.

5. Упорядоченные агрегаты и классы планирования PHB

Работа по поддержке Diffserv в маршрутизаторах MPLS (LSR14) привела к реализации концепции, которая была нужна в Diffserv для получения представления набора BA с общими ограничениями по сохранению порядка. Это применяется к агрегатам поведения AF, поскольку узел DS может не менять порядок пакетов микропотока, если они относятся к одному классу AF. Это будет, к примеру, предотвращать в маршрутизаторах MPLS LSR, являющихся узлами DS, дискриминирование пакетов агрегата поведения AF на основе предпочтений при отбрасывании и пересылки пакетов одного класса AF с разными предпочтениями по отбрасыванию через разные LSP. Определены новые термины.

Класс планирования PHB (PHB Scheduling Class) — группа PHB, для которой общее ограничение состоит в том, что порядок должен сохраняться по крайней мере для пакетов одного микропотока.

Упорядоченный агрегат (OA15) — набор BA с общими ограничениями по сохранению порядка. Набор PHB, которые применяются к этому набору BA, определеяет класс планирования PHB.

6. Неизвестные/некорректно отображенные DSCP

Несколько разработчиков отметили неоднозначности и конфликты в Diffserv RFC, касающиеся поведения узлов DS при получении пакетов с непонятным значением DSCP.

В RFC 2475 указано:

«Входные узлы должны кондиционировать весь остальной входящий трафик для обеспечения приемлемости кодов DS; пакеты с неприемлемыми кодами должны отбрасываться или значение кода DS должно меняться на приемлемое до пересылки пакета. Например, входной узел, получая трафик от домена, для которого нет соглашения об улучшенном обслуживании, может сбрасывать код DS в значение, принятое для Default PHB [DSFIELD].»

С другой стороны, в 2474 указано:

«Пакеты, полученные с неизвестным кодом, следует пересылать, как будто они помечены для принятого по умолчанию поведения (см. раздел 4), не меняя в них кода.»

RFC 2474 имеет дело в основном с внутренними узлами DS. Однако такой режим может также применяться на внутренних узлах DS после кондиционирования трафика, требуемого RFC 2475 (в этом случае нераспознаваемые DSCP могут появляться только в следствие некорректной конфигурации). Если приходит пакет со значением DSCP, которое явно не отображается на определенный PHB, это следует трактовать, как пакет, маркированный для принятой по умолчанию обработки. Альтернативой является выделение другого PHB, что может приводить к ошибочному выделению предоставляемых ресурсов или отбрасыванию пакета. Других вариантов в схеме RFC 2474 не возникает. Ни один из этих вариантов не представляется подходящим. Рассматривался вопрос PHB, получающего обслуживание хуже принятого по умолчанию — это может оказаться лучшим вариантом.

RFC 2475 явно посвящен входным узлам DS (точнее, функциям кондиционирования трафика на входных узлах). Это другой контекст, в котором употребление термина «следует» в RFC 2474 обеспечивает гибкость, для которой группа предназначена. Столь жесткое прочтение нежелательно.

Следовательно, утверждение в RFC 2474 разъясняется, чтобы показать, что оно не предназначено для применения к функции кондиционирования на входном узле DS и сослаться для этого случая на RFC 2475.

Аналогичный вопрос возникает при декларировании себя в качестве первой инкарнации EF16. В RFC 2598 указано:

«Для защиты себя от атак на отказ служб (DoS17) периметр домена DS должен строго проверять для всех пакетов с маркировкой EF соответствие скорости согласованному со смежным восходящим доменом значению (скорость должна быть не больше значения, заданного для EF PHB). Пакеты, вызывающие превышение согласованной скорости должны отбрасываться. Если смежные домены не согласовали скорость EF, нисходящий домен должен использовать нулевое значение скорости (т. е., отбрасывать все пакеты с маркировкой EF).»

Проблема возникает при некорректной конфигурации или в связи с проблемами маршрутизации. Выходной узел DS на краю домена DS пересылает пакеты входному узлу DS на краю другого домена DS. Эти пакеты маркируются значением DSCP, которое в понимании выходного узла отображается на EF, но входной узел не распознает. Утверждение RFC 2475 представляется применимым для этого случая. В RFC 3246 [7] содержатся разъяснения этого вопроса.

7. Несовместимость с RFC 1349

По крайней мере один разработчик обратил внимание на несоответствие поля DS, определенного в RFC 2474, использованию битов TOS, описанному в RFC 1349. Применение RFC 1349 было вызвано взаимодействием с расширениями OSPF из RFC 1247. Оно не получило широкого распространения и было исключено из процесса стандартизации при публикации STD 54, RFC 2328. Обработка битов TOS описана, как требования в RFC 1812 [8], RFC 1122 [9] и RFC 1123 [10]. В RFC 2474 указано:

«Здесь не предпринимается попыток обеспечить совместимость с DTR или битами TOS октета IPv4 TOS, определенного в [RFC791].»

Кроме того, RFC 2474 отменяет действие RFC 1349 по решению IESG. Для полноты при обновлении RFC 2474 приведенный выше фрагмент следует выразить иначе:

«Здесь не предпринимается попыток обеспечить совместимость с DTR/MBZ или битами TOS октета IPv4 TOS, как определено в [RFC791] и [RFC1349]. Это означает, что обработка битов TOS, описанная в [RFC1812], [RFC1122] и [RFC1123] также отменяется этим документом. См. также [RFC2780].»

8. Согласование с IANA

В агентство IANA передан запрос на разъяснение RFC 2474 в части регистрации значений DSCP, предназначенных для экспериментов и локального применения. При пересмотре RFC 2474 в раздел 6 следует добавить приведенный ниже текст:

«У агентства IANA запрашивается поддержка реестра рекомендуемых значений DSCP, распределяемых путем стандартизации. Значения EXP/LU18 не регистрируются.»

9. Список ожидаемых изменений

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

RFC 2474 — пересмотр определения поля DS. Разъяснение того, что предложенная пересылка по умолчанию для нераспознанных значений DSCP не применима к входному кондиционированию на входных узлах DS. Разъяснение влияния на RFC 1349 и RFC 1812. Разъяснение того, что IANA регистрирует только рекомендуемые значения DSCP, распределяемые путем стандартизации.

RFC 2475 — пересмотр определения поля DS. Добавление определений SLS и TCS. Обновление текста по использованию SLS и TCS. Добавление определений класса планирования PHB и упорядоченного агрегата.

RFC 2497 — пересмотр с учетом того, что классы AF являются экземплярами группы AF PHB, а не представляют коллективно группу PHB.

Кроме того, в RFC 3246 [7] была добавлена ссылка на RFC 2475 (раздел «Вопросы безопасности») для случая, когда выходной узел DS получает нераспознанное значение DSCP, которое отображается на EF во входном узле DS.

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

Вопросы безопасности не рассматриваются в RFC 2475.

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

В этом документе используются результаты рабочей группы Diffserv. Множество людей приняло участие в дискуссиях рассылки Diffserv и на встречах. Руководителями группы Diffserv были Brian Carpenter и Kathie Nichols. Среди активных участников обсуждения были Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim, Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John Schnizlein, Francois Le Faucheur и Fred Baker. Mike Ayers, Mike Heard и Andrea Westerinen внесли существенные редакторские правки.

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

[1] Nichols, K., Blake, S., Baker, F. and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[2] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, December 1998.

[3] Heinanen, J., Baker, F., Weiss, W. and J. Wrocklawski, «Assured Forwarding PHB Group», RFC 2597, June 1999.

[4] Ramakrishnan, K., Floyd, S. and D. Black «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[5] Bradner, S. and V. Paxon, «IANA Allocation Guidelines for Values in the Internet Protocol and Related Headers», BCP 37, RFC2780, March 2000.

[6] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, «Terminology for Policy-Based Management», RFC 3198, November 2001.

[7] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Le Boudec, J., Chiu, A., Courtney, W., Cavari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, «An Expedited Forwarding PHB (Per-Hop Behavior)», RFC 3246, March 2002.

[8] Baker, F., «Requirements for IP Version 4 Routers», RFC 1812, June 1995.

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

[10] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

Адрес автора

Dan Grossman

Motorola, Inc.

20 Cabot Blvd.

Mansfield, MA 02048

EMail: dan@dma.isg.mot.com


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

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

nmalykh@gmail.com

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

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

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

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

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

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

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

1Service Level Agreement — соглашение об уровне обслуживания.

2Traffic Conditioning Agreement.

3Service Level Specification.

4Differenciated Service — дифференцированное обслуживание. Прим. перев.

5Traffic Conditioning Specification.

6Behavior Aggregate — агрегат поведения. Прим. перев.

7Service Provisioning Policy.

8Per-hop behavior — поэтапное поведение.

9Assured Forwarding — гарантированная пересылка.

10Diffserv Codepoint.

11Type-of-Service — тип обслуживания.

12Currently Unused — в настоящее время не используются.

13Explicit congestion notification – явное уведомление о насыщении (перегрузке).

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

15Ordered Aggregate.

16Expedited Forwarding — ускоренная пересылка.

17Denial of service attack.

18Для экспериментального и локального использования.

19На начало 2009 г. этого не произошло. Прим. перев.




RFC 3251 Electricity over IP

Network Working Group                                 B. Rajagopalan
Request for Comments: 3251                             Tellium, Inc.
Category: Informational                                 1 April 2002

Передача электроэнергии по протоколу IP

Electricity over IP

PDF

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

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

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

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

Тезисы

MPLampS (Mostly Pointless Lamp Switching – наиболее бессмысленная коммутация лампочек) представляет собой архитектуру передачи электроэнергии по протоколу IP (с использованием управляющего плана MPLS). Согласно исследования нашего маркетингового отдела MPLampS дает потенциальные возможности грандиозного снижения цен, упрощения распределения и использования электроэнергии, а также значительного повышения эффективности управления доставкой электроэнергии потребителям. Предпосылкой для создания этого документа послужили работы по таким вопросам, как передача трафика SONET/SDH по протоколу IP/MPLS (приносим свои извинения авторам). Читатели предыдущей работы наблюдали у себя помутнение разума (scratching their heads) и бормотание: «Что же дальше?». Настоящая работа дает ответ на этот вопрос.

Этот документ был написан, как открытый. Был сформирован специальный раздел «Sub-IP», который позволяет всем желающим равные возможности проведения работ, выходящих за пределы традиционных сетей IP, для написания сложных в понимании документов IETF. Многие, вероятно, будут удивлены появлением таких возможностей для достижения широкой известности. Конечной целью этой работы мы видим созданием стандарта «foo-over-MPLS» (или MPLS-управление для произвольных технологий), как наиболее подходящей основы для создания неисчислимого множества нереализуемых документов. Данный документ иллюстрирует ключевые компоненты, которые могут быть включены в любой документ «foo-over-MPLS» или использоваться в качестве заготовки для всех работ такого рода.

1. Используемые в документе соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), делать (DO), не делать (DON’T), требуется (REQUIRED), следует (SHALL), не следует (SHALL NOT), должно (SHOULD), не должно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), может быть (MAY BE) и необязательно (OPTIONAL) в данном документе не означают ровным счетом ничего.

2. Требования к читателям документа

Во многих местах у читателей этого документа могут возникнуть вопросы типа: «А это имеет смысл?», «Такое возможно?», «Автор в своем уме?» Читатель должен подавить в себе эти неуместные вопросы и читать документ дальше. При условии выполнения этого требования от читателя не требуется никаких технических знаний для чтения этого документа. В некоторых случаях (включая данный документ) от читателя может требоваться отсутствие технических знаний.

3. Введение

Недавно мы обратили свое внимание на странный факт – в сетях распределения электроэнергии не используется протокол IP! После того, как закончился вызванный осознанием этого факта шок, мы осознали следующее:

  1. Распределение электроэнергии базируется на некой устаревшей технологии, называемой Legacy Distribution System (унаследованная система распределения), которую далее для краткости будем обозначать как LDS.
  2. Поскольку LDS не использует технологии Internet, это означает необходимость поддержки и администрирования двух разнотипных сетей (электрической и IP). В результате не может быть обеспечено требуемой эффективности, возрастают расходы и бюрократическая неразбериха (в результате этого могли возникнуть перебои с электроэнергией в Калифорнии; сейчас мы изучаем этот вопрос).
  3. Вышесказанное означает, что должна использоваться единая технология (т. е., IP) для передачи электроэнергии и трафика Internet.
  4. Перед началом работ в данной области нужно выпустить рабочие документы (Internet-Draft), пока это не успел сделать кто-то другой.
  5. Эти рабочие документы могут использоваться для подготовки новых рабочих документов. обеспечивая нам (а так же CCAMP, MPLS и другим надежным и доверенным рабочим группам) занятость на многие годы.
  6. Рабочие документы можно также разместить в разделе «white papers» на корпоративном сайте нашей компании, представив их как революционные идеи.

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

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

MPLampS: Mostly Pointless Lamp Switching (наиболее бессмысленная коммутация лампочек) – архитектура, предложенная в настоящем документе.

Lamp – конечная система в архитектуре MPLampS (это не соответствует определению IETF для конечных систем, но для нас такая мелочь не имеет значения).

LER: Lowvoltage Electricity Receptor (низковольтный потребитель электроэнергии) – более изысканный эквивалент термина Lamp.

ES: Electricity source (источник электроэнергии) — генератор.

LSR: LoadSwitching Router (маршрутизатор с коммутацией нагрузки) – устройство MPLampS используемое в ядре сети распределения электроэнергии.

LDS: Legacy Distribution System (унаследованная система распределения) – технология распределения электроэнергии, не обеспечивающая должного качества; MPLampS обеспечивает замену этой устаревшей технологии.

RSVP: Rather Screwedup, but router Vendors Push it (пьяный бред, проталкиваемый производителями маршрутизаторов) – сигнальный протокол IP.

RSVPTE: RSVP with Tariff Extensions (RSVP с тарифным расширением) – адаптация протокола RSVP для технологии MPLampS, предназначенная для использования в новой среде коммунальных услуг со сниженным влиянием государства.

CRLDP: for CRying out Loud, Dont do rsvP (для тех, кто громко кричит, но не выполняет RSVP) – еще один сигнальный протокол IP.

OSPF: Often Seizesup in multiPle area conFigurations (часто заедающий в конфигурации с множеством областей) – иерархический протокол маршрутизации IP.

ISIS: Its not oSpf, yet It somehow Survives (это не OSPF, а какой-то пережиток) – еще один протокол маршрутизации.

OSPF-TE, ISIS-TE: OSPF и ISIS с расширением Tariff Extensions.

COPS: Policemen (полицейский) — люди, которые рыскают повсюду, пытаясь пресечь все попытки нарушения протокола Common Open Policy Service.

VPN: Voltage Protected Network (защищенная по напряжению сеть) — позволяет заказчикам с множеством сайтов получать электричество с пренебрежимо малыми флуктуациями напряжения в результате интерференции1 от других заказчиков.

SUBIP: SUBstitute IP everywhere (протолкнуть IP повсюду) — попытки IETF протянуть свои руки в технические области за пределами традиционных сетей IP (например, MPLampS).

ITU: International Tariffed Utilities association — промышленная группа коммунальщиков, работа которой часто игнорируется IETF.

5. Фундаментальные основы

Мы обратили внимание на технологию распределения электроэнергии для получения базовых знаний в этой области. То, что мы узнали, изумило нас — скажем, возможность подачи напряжения 230V A/C в нашу ванну в то время, когда мы в ней находимся. Проще говоря, электричество генерируется и распределяется через огромное число LDS, в которых нет центрального маршрутизатора (LSR или иного)! Более того, управление устройствами в этой сети осуществляется главным образом вручную — люди просто крутят нужные колесики. После кратковременного удивления (каким образом такая сеть могла сохраниться в 21 веке) мы взяли карандаш и бумагу, чтобы разработать сценарий интеграции сетей LDS с проверенной технологией Internet. Исходными точками для такой интеграции являются следующие предпосылки:

  1. IP-пакеты переносят электричество в дискретной цифровой форме.
  2. Каждый пакет доставляет электроэнергию по назначению (т. е., устройству с заданным адресом IP) в соответствии с запросами потребителей.
  3. MPLS-управление будет использоваться для коммутации пакетов в ядре LDS и краевых системах. Такая архитектура будет называться Mostly-Pointless Lamp Switching (наиболее тупая коммутация ламп или MPLampS).
  4. Архитектурная модель MPLampS будет адаптирована как для моделей с перекрытием (overlay model), где потребляющие электричество устройства (будем называть их лампами — lamp) работают в различных плоскостях управления, так и для одноранговых (peer model) систем, в которых лампы и сеть распределения используют единый управляющий план.
  5. Для организации путей передачи электричества в дерегулированной2 среде можно использовать протокол RSVP-TE (RSVP с тарифным расширением).
  6. Для учета и контроля потребления электричества может использоваться протокол COPS.

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

  1. Коммутаторы и трансформаторы в LDS можно заменить на LSR, создав новый сектор рынка маршрутизаторов.
  2. Электроэнергию можно будет маршрутизировать в такие места, где еще нет электрических соединений и имеются только Internet-киоски3 (например, деревни в Индии).
  3. Инженеров-электриков можно будет заменить на высокооплачиваемых администраторов IP-сетей.
  4. IETF сможет распространить свое влияние на многие технологические области со слабым государственным регулированием.

Ниже приведено туманное рассмотрение технических аспектов новой технологии.

6. Кодирование электричества

Схема DVE (Discrete Voltage Encoding — Дискретное Кодирование Электричества) описана стандартом ITU G.110/230V [2] и предназначена для цифрового кодирования электрических напряжений. Суть этой схемы кодирования состоит в том, что источники электричества ES (например, генераторы) подключаются к устройствам кодирования DV, которые представляют напряжение и ток в виде битовых потоков. Эти битовые потоки можно передавать в пакетах IP различным потребителям (будем называть их LER — Low-voltage Electricity Receptor — низковольтные потребители электричества) по запросам последних. В точке назначения декодер DV корректно выполняет обратное преобразование битового потока в напряжение и ток. Будет определено. где может использоваться протокол RTP (Real-time Transport Protocol — транспортировка в реальном масштабе времени) для обеспечения синхронизации и сквозного управления. Решение задачи подготовки рабочего документа для использования RTP мы оставляем нашим друзьям и коллегам.

7. Архитектура MPLampS

7.1 Обзор

В системах LDS для передачи электроэнергии на большие расстояния используется высокое напряжение. По мере передачи электроэнергии через локальную распределительную сеть в направлении потребителя напряжение поэтапно снижается и доставляется LER со стандартным значением (например, 110 или 220 В). Таким образом, LDS представляет собой иерархическую сеть. Это сразу же дает возможность использования расширений OSPF и ISIS для маршрутизации электричества в транспортной сети, но мы займемся изысканиями в этой важной области немного позже. Сейчас мы ограничим наше обсуждение вопросами управления потоком электроэнергии в распределительной сети на основе протокола IP с использованием архитектуры MPLampS.

В рамках MPLampS напряжение приравнивается метке (label). В распределительной сети каждый коммутационный элемент и трансформатор рассматривается как маршрутизатор с коммутацией нагрузки LSR (load-switching router). Каждый пакет IP, переносящий поток электричества, связывается с меткой, которая соответствует напряжению. Распределение электроэнергии в этом случае можно тривиально реализовать путем коммутации меток (напряжений) как потока электричества через распределительную сеть. Настройка конфигурации коммутационных элементов распределительной сети осуществляется с помощью протокола RSVP-TE, что позволяет предоставлять электроэнергию по запросу потребителей.

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

Пример: Включение лампы (Lamp)

Предполагается, что лампа управляется интеллектуальным устройством (например, (световым) коммутатором с управлением на основе MPLampS). with an MPLampS control plane). Включение лампы заставляет коммутатор передать запрос RSVP-TE (сообщение PATH с новыми объектами) для потока электричества. Такое сообщение PATH передается через сеть устройству ES. В ответ генерируется сообщение RESV, задающее отображение меток (label mapping) в маршрутизаторах LSR. После этого поток электричества начинает передаваться по созданному пути. Ожидается, что выполнение всего процесса будет занимать лишь несколько секунд и обеспечит архитектуре MPLampS заметное преимущество по сравнению с зажиганием свечи посредством отсыревших спичек.

7.2 Сравнение одноранговой (Peer) и оверлейной (Overlay) моделей

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

7.3 Маршрутизация в ядре сети

Приведенное выше описание иерархической системы распределения незамедлительно открывает возможность применения протоколов OSPF и ISIS с подходящими расширениями. Читатели могут быть уверены в том, что мы уже работаем над такими концепциями, как создание пакетов напряжений (voltage bundling), мультиобластные тарифные расширения, изолированные LSA и т. п. Детальные описания этих концепций будут представлены в будущих документах.

7.4 Сети с защитой по напряжению (VPN)

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

8. Групповая адресация

Многократно отмечалась сильная пространственная и временная неоднородность запросов на электроэнергию. Исследовательская группа ITU Study Group 55 изучала этот феномен в течение 10 лет и подготовила предварительный отчет. В отчете отмечается, что включение лампы в одном доме обычно вызывает включение ламп в соседних домах в то же самое время (обычно в сумерки) [3]. Это наблюдение оказывает существенное влияние на масштабирование сигнальных механизмов. В частности, распределительная сеть должна быть способна обслуживать одновременно десятки тысяч запросов. Нагрузка на систему сигнализации может быть снижена за счет использования групповой доставки (multicast delivery). Говоря кратко, запрос на электричество от лампы не передается непосредственно к ES, а обслуживается первым LSR, который уже имеет путь к другой лампе.

Такое решение требует поддержки протоколов групповой маршрутизации вместе с разделяемым резервированием RSVP-TE и разработкой для MPLampS режима групповой пересылки (multicast forwarding). В настоящее время мы изучаем следующие протоколы групповой маршрутизации:

  • DVMRP: Discrete Voltage Multicast Routing Protocol (протокол групповой маршрутизации дискретных напряжений) — этот протокол работает на основе существующих протоколов маршрутизации напряжений, но некоторая опасность его заключается в том, что напряжение доставляется одновременно на все лампы при включении одной из них. Несомненно, что семантика коммутации весьма утомительна и надоедлива — все лампы периодически включаются и, следовательно, нет необходимости каждый раз выключать их вручную.

К другим протоколам, которые мы рассмотрим со временем, относятся CBT (Current-Based Tree – токовое ерево) и PIM (не относящаяся к делу групповая адресация). Вопрос, в котором мы кровно заинтересованы — это групповая адресация. Нам нравится поддержка систем распределения электричества различного масштаба — от ламп на одной рождественской елке до целого города. Нет нужды повторяться — мы напишем множество подробных документов, посвященных этим вопросам.

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

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

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

Этот документ описывает мотивацию и высокий уровень концепций, положенных в основу MPLampS (Mostly Pointless Lamp Switching — наиболее бессмысленная коммутация ламп) — архитектуры передачи электроэнергии по протоколу IP. MPLampS использует DVE (дискретное кодирование напряжения) и управляющий план MPLS в распределительных сетях. Поскольку цель настоящего документа состоит в том, чтобы «застолбить место под солнцем», мы не приводим детального рассмотрения MPLampS. Множество будущих документов, к несчастью, будут пытаться обеспечить такие детали.

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

  1. A. Malis, et al., «SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation», Internet Draft, Work in Progress.
  2. International Tarriffed Utilities association draft standard, ITU G.110/230V, «Discrete Voltage Encoding», March, 1999.
  3. International Tarriffed Utilities association technical report, ITU (SG-55) TR-432-2000, «Empirical Models for Energy Utilization», September, 2000.

12. Отречение

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

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

Bala Rajagopalan

Tellium, Inc.

2 Crescent Place

Ocean Port, NJ 07757

Phone: 732-923-4237

EMail: braja@tellium.com


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

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

nmalykh@gmail.com

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

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

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

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

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

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

Поддержка функций RFC Editor в настоящее время обеспечивается Internet Society.

1 Разрушающего вредного воздействия. Прим. перев.

2 С ослабленным влиянием государства.Прим. перев.

3 Платные центры доступа в Internet. Прим. перев.

4 Разрушающего вредного воздействия. Прим. перев.