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

Internet Draft Bala Rajagopalan

Document: Tellium, Inc.

This draft expires on November, 7, 2001

MPLampS: Electricity over IP (with an MPLS control plane)

MPLampS: электропередача по протоколу IP (с управлением на базе MPLS)

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

Этот документ является рабочим документом (Internet-Draft) и полностью соответствует требованиям главы 10 RFC2026 [1].

В настоящее время основная часть работы в данном направлении завершена и документ выпущен как RFC 3251. Перевод документа на русский язык вы сможете найти здесь

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

Internet-Draft - это рабочий документ IETF, различных комитетов и рабочих групп IETF. Отметим, что другие группы могут также распространять свои рабочие документы, как Internet-Drafts. Рабочие документы представляют собой предварительные версии [стандартов], срок действия которых ограничен 6 месяцами; эти документы могут быть обновлены, заменены или обновлены в любой момент другими документами. Допускается использование документов Internet- Draft как справочных материалов, а также их цитирование с пометкой "работа не завершена" (work in progress).

Текущий список рабочих документов Internet-Drafts можно загрузить, пользуясь ссылкой http://www.ietf.org/ietf/1id-abstracts.txt.

1. Тезисы

Mostly Pointless Lamp Switching (MPLampS, наиболее тупая коммутация ламп) представляет собой архитектуру передачи электроэнергии по протоколу IP (с управлением на основе MPLS). Согласно исследованиям маркетингового отдела MPLampS может многократно снижать стоимость, упрощать распределение и использование, а также может обеспечивать более эффективное управление и доставку электроэнергии. Этот рабочий документ основан на разработках SONET/SDH over IP/MPLS [2] (приносим авторам свои извинения). Читатели упомянутой работы наблюдали у себя помутнение рассудка и бормотали: "Что же дальше?" Данный документ содержит ответ на этот вопрос.

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

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

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

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

Примечание-шаблон для разработчиков новых документов: эта глава должна присутствовать во всех документах foo-over-MPLS

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

4. Введение
Примечание-шаблон для разработчиков новых документов: в этой главе фабрикуется обоснование "foo-over-MPLS"
Недавно наше внимание привлек факт передачи электроэнергии без использования IP-сетей! После того, как прошел шок в результате этой новости, в голову пришли следующие мысли:

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

Поскольку LDS не использует технологии Internet, это означает необходимость поддержки и администрирования двух разнотипных сетей (электрической и IP). В результате не может быть обеспечено требуемой эффективности, возрастают расходы и бюрократическая неразбериха (в результате этого могли возникнуть перебои с электроэнергией в Калифорнии; сейчас мы изучаем этот вопрос).

Вышесказанное означает, что должна использоваться единая технология (т. е., IP) для передачи электроэнергии и трафика Internet.

Перед началом работ в данной области нужно выпустить рабочие документы (Internet-Draft), пока это не успел сделать кто-то другой.

Эти рабочие документы могут использоваться для подготовки новых рабочих документов. обеспечивая нам (а так же CCAMP, MPLS и другим ответственным рабочим группам) занятость на многие годы.

Рабочие документы можно также разместить в разделе "white papers" на корпоративном сайте нашей компании, представив их как революционные идеи.

Эти соображения послужили основой для подготовки данного документа.
5. Терминология
Примечание-шаблон для разработчиков новых документов: Any respectable "foo-over-MPLS" draft SHOULD have a terminology section

MPLampS

Mostly Pointless Lamp Switching (наиболее тупая коммутация ламп) - архитектура, разработанная в данном документе.

Lamp - лампа

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

LER

Low-voltage Electricity Receptor (низковольтный потребитель электричества) - модное название лампы (Lamp).

ES

Electricity source (источник электричества) - генератор.

LSR

Load-Switching Router (маршрутизатор с переключением нагрузки) - устройство MPLampS, используемое в ядре (core) сети распределения электроэнергии.

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 and ISIS with Tariff Extensions - OSPF и ISIS с тарифным расширением.

COPS

Полицейские - люди, которые рыскают повсюду, пытаясь пресечь все попытки нарушения протокола Common Open Policy Service.

VPN

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

SUB-IP

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

ITU

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

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

IP-пакеты переносят электричество в дискретной цифровой форме.

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

MPLS-управление будет использоваться для коммутации пакетов в ядре LDS и краевых системах. Такая архитектура будет называться Mostly-Pointless Lamp Switching (наиболее тупая коммутация ламп или MPLampS).

Архитектурная модель MPLampS будет адаптирована как для моделей с перекрытием (overlay model), где потребляющие электричество устройства (будем называть их лампами - lamp) работают в различных плоскостях управления, так и для одноранговых ( peer model) систем, в которых лампы и сеть распределения используют единый план управления.

RSVP-TE (RSVP с тарифным расширением) можно использовать для организации путей передачи электричества в дерегулированной среде.

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

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

Коммутаторы и трансформаторы в LDS можно заменить на LSR, создав новый сектор рынка маршрутизаторов.

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

Инженеров-электриков можно будет заменить на высокооплачиваемых администраторов IP-сетей.

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

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

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

8.1 Обзор

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

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

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

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

8.2 Сравнение одноранговой и оверлейной моделей

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

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

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

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

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

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

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

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

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

10. Вопросы безопасности
Примечание-шаблон для разработчиков новых документов: следующий параграф должен присутствовать во всех рабочих документах foo-over-MPLS drafts
Этот документ должен храниться в закрытом, безопасном помещении для предотвращения его немедленного выбрасывания в мусорную корзину.

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

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

Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

"SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation," Work in Progress.

International Tarriffed Utilities association draft standard, ITU G.110/230V, "Discrete Voltage Encoding", March, 1999.

International Tarriffed Utilities association technical report, ITU (SG-55) TR-432-2000, "Empirical Models for Energy Utilization", September, 2000.

13. Отречение

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

14. Адреса авторов
   Bala Rajagopalan
   Tellium, Inc.
   2 Crescent Place
   Ocean Port, NJ 07757

   Phone: 732-923-4237

   Email: [email protected]
Перевод на русский язык
   Николай Малых
   BiLiM Systems Ltd.
   PO Box 153, K-354
   St. Petersburg, Russia, 194354

   Телефон: (812) 325-2068

   EMail: [email protected]

Страница обновлена 01.04.2002