RFC 3251 Electricity over IP

Опубликовано 01.04.2002 автором Nikolai Malykh 
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: Low–voltage Electricity Receptor (низковольтный потребитель электроэнергии) – более изысканный эквивалент термина Lamp.

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

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

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

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

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

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

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

ISIS: It‘s 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 от других заказчиков.

SUB–IP: 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@protokols.ru

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

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

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

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

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

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

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

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

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

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

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

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.