Network Working Group Request for Comments: 3251 Category: Informational
B. Rajagopalan
Tellium, Inc.
1 April 2002
Electricity over IP
Передача электроэнергии по протоколу IP Статус документа
Данный документ содержит информацию для сообщества 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) и бормотание: «Что же дальше?". Настоящая работа дает ответ на этот вопрос.
This document has also been written as a public service. Был сформирован специальный раздел "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" на корпоративном сайте нашей компании, представив их как революционные идеи.
Эти соображения послужили основой для подготовки данного документа.
Перевод RFC 3521
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 сможет распространить свое влияние на многие технологические области со слабым государственным регулированием.
Ниже приведено туманное рассмотрение технических аспектов новой технологии.
Разрушающего вредного воздействия. Прим. перев. С ослабленным влиянием государства. Прим. перев. Платные центры доступа в Internet. Прим. перев.
2
Перевод RFC 3521
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) моделей
Как было отмечено выше, существуют две модели представления управляющего плана. В оверлейной модели лампы и распределительная сеть используют разные управляющие планы, а одноранговая модель использует общий план управления. Можно привести множество аргументов в пользу той или иной из этих моделей и это будет сделано в последующих документах. coming framework document. Мы лишь отметим, что производители ламп предпочитают одноранговую модель, а производители LSR - оверлейную. Мы, однако, хотим представлять оба эти лагеря, независимо от полезности той или иной модели и, следовательно, отмечаем здесь, что MPLampS поддерживает обе модели и обеспечивает сценарии перехода от оверлейной модели к одноранговой.
7.3 Маршрутизация в ядре сети
Приведенное выше описание иерархической системы распределения незамедлительно открывает возможность применения протоколов OSPF и ISIS с подходящими расширениями. Читатели могут быть уверены в том, что мы уже работаем над такими концепциями, как создание пакетов напряжений (voltage bundling), мультиобластные тарифные расширения, изолированные LSA и т. п. Детальные описания этих концепций будут представлены в будущих документах.
7.4 Сети с защитой по напряжению (VPN)
Технология VPN позволяет заказчикам, имеющим множество сайтов, гарантированно получать электричество с пренебрежимо малыми флуктуациями напряжения в результате интерференции4 от других пользователей. Несомненно, кое-кто может доказывать, что вся архитектура MPLampS может "накрыться медным тазом", если не будет обеспечиваться поддержка VPN. Как бы то ни было, VPN не рассматриваются в данной работе, но заверяем читателей, что мы уделяем серьезное внимание подготовке нескольких документов по этому вопросу. В частности, поддержка BGP для VPN является сферой нашего пристального внимания.
4 Разрушающего вредного воздействия. Прим. перев.
http://rfc.com.ru                                                                3                                                               http://rfc.com.ru
 
Перевод RFC 3521
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
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
http://rfc.com.ru                                                                          4                                                    http://rfc.com.ru
Перевод RFC 3521
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Подтверждение
Поддержка функций RFC Editor в настоящее время обеспечивается Internet Society.
Перевод на русский язык
Николай Малых BiLiM Systems Ltd. Санкт-Петербург 194354, К-354, а/я 153 тел. (812) 449-0770 nmalykh@bilim.com
5
Новый год: горные лыжи курорт Церматт. . Где купить чехол для iphone 4 киев желательно кожаный. Найди себе партнера, взрослые знакомства секс с животными онлайн.