RFC 7575 Autonomic Networking: Definitions and Design Goals

Internet Research Task Force (IRTF)                         M. Behringer
Request for Comments: 7575                                   M. Pritikin
Category: Informational                                     S. Bjarnason
ISSN: 2070-1721                                                 A. Clemm
                                                           Cisco Systems
                                                            B. Carpenter
                                                       Univ. of Auckland
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                            L. Ciavaglia
                                                          Alcatel Lucent
                                                               June 2015

Autonomic Networking: Definitions and Design Goals

Самоуправляющиеся сети – определения и цели разработки

PDF

Аннотация

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

В этом документе определён язык описания и очерчены цели (а также отмечено то, что не является целью) автоматических функций. Высокоуровневая эталонная модель иллюстрирует взаимодействие функциональных элементов в самоуправляемой сети (Autonomic Network или AN). Документ является результатом работы исследовательской группы IRTF Network Management.

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

Документ не содержит какой-либо спецификации (Internet Standards Track) и публикуется с информационными целями.

Документ является результатом работы IRTF (Internet Research Task Force). IRTF публикует результаты исследований и разработок, связанных с Internet. Эти результаты не всегда пригодны для развёртывания. Данный документ RFC представляет согласованный взгляд исследовательской группы Network Management в составе IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус стандартов Internet (см. раздел 2 в RFC 5741).

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc7575.

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

Copyright (c) 2015. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

1. Введение в самоуправляющиеся сети

Самоуправляющиеся (автоматические) системы впервые были описаны в манифесте IBM [Kephart] в 2001 году. Фундаментальная концепция включает устранение внешних систем из контура управления и замыкание этого контура в самой автоматической системе с целью обеспечения ей возможностей самоуправления, включая самонастройку, самовосстановление и самозащиту.

Изначально сети IP разрабатывались с похожими свойствами. Сетям IP следовало быть распределенными и обеспечивающими избыточность для устойчивости к отказам в любой части сети. Протоколы маршрутизации, такие как OSPF и IS-IS, имеют свойства самоуправления и их можно считать самоуправляющимися в соответствии с этим документом.

Однако по мере развития сетей IP постоянно возрастающий уровень «интеллекта» элементов сети зачастую не вносился в протоколы в соответствии с упомянутой парадигмой, а реализовался во внешних системах управления конфигурацией. Это сделало элементы сети зависимыми от неких процессов, которые управляют ими под руководством человека или системы управления сетью.

Самоуправляющиеся функции можно определить двумя способами:

• на уровне узла, когда узлы взаимодействуют между собой образуя контуры обратной связи;

• на уровне системы, где контуры обратной связи включают также централизованные элементы.

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

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

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

Самоуправляющаяся функция не может в каждом случае найти всю требуемую информацию, например, связанные с правилами сведения требуют данных (правил) от человека по самой природе. Там, где требуются данные от той или иной централизованной системы, они предоставляются в абстрактной общесетевой форме.

Самоуправляемые вычисления (Autonomic Computing) в целом и самоуправляющиеся сети в частности много лет служат предметом академического изучения. Имеется много литературы, в том числе несколько полезных обзорных статей (например, [Samaan], [Movahedi], [Dobson]). В этом документе основное внимание уделено концепциям и определениям, которые представляются достаточно зрелыми и способны стать основой для совместимых спецификаций в ближайшем будущем. В частности, такие спецификации должны будут сосуществовать с традиционными методами настройки и управления сетями, а не просто реализовать самоуправляющиеся системы со всеми требуемыми свойствами.

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

В этом документе даны определения и указаны цели проектирования для AN в рамках IETF и IRTF. Документ представляет согласованный взгляд исследовательской группы IRTF Network Management (NMRG).

2. Определения

Autonomic – самоуправляющийся, автоматический

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

Automatic – автоматизированный¹

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

Intent – намерение, цель

Абстрактная, высокоуровневая политика, используемая для работы сети. Областью действия политики является автоматический домен, такой как сеть предприятия. Намерения не включают конфигурацию или сведения для конкретных узлов (в параграфе 3.2 описано сосуществование Intent с другими парадигмами управления). Политика может включать информацию, относящуюся к узлу с определённой ролью (например, к граничному коммутатору) или выполняющему определённую функцию узлу. Намерения обычно задаёт и предоставляет тот или иной централизованный элемент.

Autonomic Domain – домен самоуправления

Группа (набор) автоматических (самоуправляющихся) узлов с общей целью (Intent).

Autonomic Function – функция самоуправления

Свойство или функция, которое не требует настройки и может получить все требуемые сведения путём самообучения, обнаружения или получения цели (Intent).

Autonomic Service Agent – агент самоуправляемой службы

Агент, реализованный на автоматическом узле и выполняющий автоматическую функцию частично (распределенная функция) или полностью.

Autonomic Node – узел с самоуправлением

Узел, реализующий исключительно автоматические функции. Такой узел не требует (!) настройки конфигурации (отметим, что настройка конфигурации может применяться для переопределения автоматической функции, см. параграф 3.2). Autonomic Node может работать на любом уровне сетевого стека. Примерами являются маршрутизаторы, коммутаторы, ПК, менеджеры вызовов (call manager) и т. п.

Autonomic Network – сеть с самоуправлением

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

3. Цели

В этом разделе описаны высокоуровневые цели Autonomic Networking, не зависящие от конкретного решения.

3.1. Самоуправление

Исходная цель проектирования самоуправляющихся систем, описанная в [Kephart] применима и к сетям с самоуправлением (Autonomic Network). Главное целью является самоуправление, которое включает несколько «само» свойств.

• Самонастройка. Функции не требуют настройки администратором или системой управления. Они сами настраивают себя на основе самообучения, обнаружения и целей (Intent). Обнаружение (Discovery) служит используемым по умолчанию способом получения требуемой для работы информации.

• Самовосстановление. Автоматические функции адаптируют себя в соответствии с изменением среды и автоматически восстанавливаются при возникновении проблем.

• Самооптимизация. Самоуправляемые функции автоматически определяют способы оптимизации своего поведения для набора чётко заданных целей.

• Самозащита. Самоуправляемые функции автоматически защищают себя от возможных атак.

Самоуправляемой можно назвать почти любую сеть, если понятие «само» достаточно широко. Например, чётко заданная система программно-определяемых сетей (Software-Defined Networking или SDN), включая контроллеры, может быть описана в целом как самоуправляемая (автоматическая), если контроллер обеспечивает администратору интерфейс, имеющий перечисленные выше свойства (высокий уровень, сеть в целом и т. д.).

В рамках работ IETF и IRTF свойства «само» определяются на уровне узла. Цель проекта заключается в том, чтобы сделать функции узлов самоуправляемыми (минимизировать зависимость от систем управления и контроллеров, а также от участия человека). Самоуправляемым функциям на узле может потребоваться обмен информацией с другими узлами для достижения поставленных целей.

Как отмечено во введении, замкнутый контур управления является важной частью самоуправляющихся систем. Это предполагает диалоги на одном уровне (peer-to-peer) между сторонами, составляющими контур управления. Такой диалог требует двухстороннего согласования между каждой парой или группой партнёров, включённых в контур, поэтому они не могут воспользоваться обычными протоколами «запрос-отклик». Кроме того, для организации замкнутого контура управление не обойтись без процедур обнаружения. Возможно применение многосторонних протоколов, но это ведёт к существенному усложнению.

3.2. Сосуществование с традиционным управлением

В ближайшем будущем узлы и сети с самоуправлением будут скорее исключением, автоматические функции будут определяться поэтапно. Поэтому нужно принимать во внимание сосуществование с другими парадигмами сетевого управления, такими как управление с консоли, SNMP, SDN (с соответствующими API), NETCONF (Network Configuration Protocol) и т. п. Это требует разрешения конфликтов a) принятого по умолчанию автоматического поведения и Intent с b) другими методами. Проблема решается с помощью приоритизации. В общем случае автоматические механизмы определяют поведение на уровне сети, тогда как альтернативные методы обычно работают по узлам. Концепция управления на уровне узла имеет более высокий приоритет по сравнению с другими автоматическими методами. Это соответствует современным примерам автоматических функций, например, в маршрутизации (статический) маршрут имеет преимущество перед алгоритмом маршрутизации. Вкратце можно сказать:

• низший приоритет – принятое по умолчанию автоматическое поведение:

• средний приоритет – автоматические намерения (Intent);

• высший приоритет – концепции управления сетью для конкретного узла, такие как управление с консоли, SNMP, SDN, NETCONF и т. п. (приоритеты этих концепций выходят за рамки документа).

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

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

3.3. Защита по умолчанию

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

Надёжное, криптографически проверяемое отождествление в домене является фундаментом автоматических сетей (Autonomic Networking). Его можно применять для защиты всех коммуникаций без традиционной настройки, например, заранее известных общих ключей. Дополнительную информацию можно найти в документе «Making The Internet Secure By Default» [Behringer].

Автоматические функции должны поддерживать способность адаптировать своё поведение в зависимости от домена или узла, с которым происходит взаимодействие.

3.4. Децентрализация и распределённость

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

В некоторых случаях для современной практики предпочтительней иметь централизованное хранилище информации, например, базу данных о пользователях на сервере проверки подлинности и полномочий, а также учёта (Authentication, Authorization, Accounting или AAA). Автоматической сети следует иметь возможность распределять такие базы данных и по меньшей мере следует предпринимать такие усилия. В зависимости от ситуации распределение может быть простой репликацией или включать более сложные взаимодействия и организацию.

3.5. Упрощение северного интерфейса автоматических узлов

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

Поэтому узлам в Autonomic Network требуется «северный» (northbound) интерфейс. Однако такой интерфейс следует делать как можно более простым и высокоуровневым.

3.6. Абстракции

Администратор или автоматическая система управления взаимодействует с AN на высоком уровне абстракций. Намерение (Intent) определяется на уровне абстракции, который много выше типичных параметров конфигурации. Например, намерением может быть «оптимизация сети по потреблению электроэнергии». Intent недопустимо использовать для передачи низкоуровневых команд или концепций, поскольку они относятся к другому уровню абстракции. Например, администратору не следует раскрывать версию протокола IP, используемого в сети. Со стороны отчётов и обратной связи сеть с самоуправлением абстрагирует информацию и предоставляет сообщения высокого уровня, такие как «связь между узлами x и y не работает» (возможно с указанием конкретного канала, если их несколько).

3.7. Автоматические отчёты.

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

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

Событиям в сети с самоуправлением следует относится к AN в целом, а не к отдельным системам. Например, один и тот же признак отказа не следует сообщать для каждой системе, которая столкнулась с таким отказом, а достаточно указать 1 раз для AN в целом. В конечном итоге сети AN следует поддерживать управления на основе исключений, когда пользователь информируется лишь о событиях, которые действительно требуют его внимания (привлечения). Для этого нужны возможности, позволяющие системам в сети сравнивать информацию и применять конкретные алгоритмы для определения событий, о которых следует сообщать.

3.8. Общая инфраструктура автоматических сетей

В [RFC7576] отмечено, что имеется уже достаточно много автоматических функций. Однако они в большинстве своём независимы и каждая использует свои методы и протоколы для коммуникаций, обнаружения, определения и распространения политики и т. п.

Целью работы группы Autonomic Networking в IETF является не просто создание автоматических функций, но и определение общей инфраструктуры, которую автоматические функции могут использовать. Эта инфраструктура AN может включать общие функции управления и администрирования, обнаружения служб, согласования, распространения намерений, самослежения (мониторинга), диагностики и т. п. Нужен также общий подход к определению и распространению намерений (Intent).

Применительно к описанной ниже эталонной модели всем компонентам вокруг «Агентов автоматических служб» следует быть общими, чтобы агентам не нужно было дублировать задачи.

3.9. Независимость функции и уровня

Автоматические функции могут размещаться на любых уровнях сетевого стека. Например, коммутация L2 сегодня уже сравнительно самоуправляема во многих средах, поскольку большинство коммутаторов можно соединять различными способами и они автоматически образуют простую топологию L2. Функции маршрутизации работают на более высоком уровне и могут быть автоматическими на уровне L3. Даже функции прикладного уровня могут быть автоматическими, например в унифицированных коммуникациях.

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

Для автоматических сетей AN требуется общий уровень управления, чтобы автоматические узлы могли взаимодействовать. В обычных сетях IP протокол IP является связующим уровнем, который объединяет все элементы, и автоматические функции в контексте этой схемы также следует реализовать на уровне IP. Это относится к протоколам обнаружения соседей и другим функциям автоматической плоскости управления (Autonomic Control Plane).

3.10. Поддержка полного жизненного цикла

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

Состояние жизненного цикла автоматического узла отражается в модели состояния. Поведение автоматической функции может различаться в разных состояниях развёртывания.

4. Что не относится к целям разработки

В этом разделе отмечены элементы, которые явно не являются целями разработки для автоматических сетей в IETF и IRTF. Они отмечены для предотвращения недопонимания в части общих намерений, часто отмечаемого в опасениях администраторов и архитекторов сетей.

4.1. Исключение операторов

В параграфе 3.1 сказано: «Цель проекта заключается в том, чтобы сделать функции узлов самоуправляемыми (минимизировать зависимость от систем управления и контроллеров, а также от участия человека)». Однако полное исключение операторов не является целью разработки. Проблема, на решение которой нацелены сети с самоуправлением (Autonomic Networking), состоит в подверженной ошибкам и сложно расширяемой модели индивидуальной настройки элементов сети, традиционно выполняемой с помощью команд, но сегодня в основном использующей сценарии и базы данных конфигурации. Это не означает исключения опытных операторов, которые все равно нужны для надзора, управления правилами, диагностики, реагирования на обращения в службу поддержки и т. п. Основной задачей является снижение нагрузки на операторов для выполнения рутинной работы и привлечение их к решению задач более высокого уровня (им следует быть похожими на врачей, а не санитаров).

4.2. Исключение аварийных исправлений

Сколь бы ни были хорошо автоматические механизмы, иногда могут возникать неисправности или иные ситуации, когда эти механизмы не могут работать корректно. В таких случаях требуется вмешательство квалифицированного оператора, позволяющее устранить или обойти проблему. Есть надежда сделать решить проблему с помощью механизмов высокого уровня (адаптация базы правил), но иногда не удаётся обойтись без прямого вмешательства на уровне устройства. Обычно это происходит при аппаратных сбоях, даже если AN может в данный момент обойти отказ. Замену отказавшего оборудования обычно не удаётся выполнить автоматически. Однако замену можно отложить, если автоматическая система способна обнаружить отказ и перестроиться для минимизации влияния на работу.

4.3. Исключение центрального управления

Хотя цель включает упрощение северного интерфейса (параграф 3.5), она заключается не в исключении централизованного управления а в обеспечении более высокого уровня абстракции. Высшее руководство может опасаться потери управления автоматической сетью AN. Фактически, вероятность этого не выше, чем в традиционных сетях и автоматическое применение общей политики и правил безопасности может обеспечить даже большую централизацию управления.

5. Эталонная модель самоуправления

Автоматическая сеть AN состоит из автоматических узлов (Autonomic Node), которые взаимодействуют между собой через автоматическую плоскость управления (Autonomic Control Plane), которая обеспечивает отказоустойчивые и защищённые коммуникации. Автоматическая плоскость управления является самоорганизующейся и автоматической.

Автоматический узел содержит различные элементы, такие как автоматические агенты служб, реализующие автоматические функции. На рисунке 1 показана эталонная модель автоматического (самоуправляемого) узла. Элементы такого узла перечислены ниже.

• Агенты автоматических служб (Autonomic Service Agent) реализуют автоматическое поведение конкретных служб или функций.

• Самопознание (Self-knowledge) – автоматический узел знает свои свойства и возможности.

• Изучение (обнаружение) сети (Network Knowledge (Discovery)) может потребоваться автоматическим агентам служб для выполнения таких задач как обнаружение служб.

• Контуры обратной связи (Feedback Loop) обеспечивают взаимодействие узла с внешними элементами управления.

• Автоматический пользовательский агент (Autonomic User Agent) предоставляет интерфейс (front-end) для внешних пользователей (администраторы или программы управления), через который можно получать отчёты. и выполнять мониторинг AN.

+------------------------------------------------------------+
|                      +------------+                        |
|                      |  Контуры   |                        |
|                      |обрат. связи|                        |
|                      +------------+                        |
|                            ^                               |
|            Автоматический пользовательский агент           |
|                            V                               |
| +-----------+        +------------+        +------------+  |
| | Само-     |        |   Агенты   |        | Изучение   |  |
| | познание  |<------>| автоматич. |<------>|(обнаружен.)|  |
| |           |        |   служб    |        |   сети     |  |
| +-----------+        +------------+        +------------+  |
|                            ^                     ^         |
|                            |                     |         |
|                            V                     V         |
|------------------------------------------------------------|
|           Автоматическая плоскость управления              |
|------------------------------------------------------------|
|                 Стандартные функции ОС                     |
+------------------------------------------------------------+

Рисунок 1. Эталонная модель для узла с самоуправлением.

На момент завершения этого документа работа над эталонной моделью ещё продолжалась, см. [Reference-Model].

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

В этом документе приведены определения и цели проектирования автоматических сетей (Autonomic Networking). В рамках разработки решений потребуется полный анализ угроз с учётом возможных атак как внутри сети, так и извне.

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

[ACP] Behringer, M., Bjarnason, S., BL, B., and T. Eckert, “An Autonomic Control Plane”, Work in Progress², draft-behringer-anima-autonomic-control-plane-02, March 2015.

[Behringer] Behringer, M., Pritikin, M., and S. Bjarnason, “Making The Internet Secure By Default”, Work in Progress, draft-behringer-default-secure-00, January 2014.

[BOOTSTRAP] Pritikin, M., Behringer, M., and S. Bjarnason, “Bootstrapping Key Infrastructures”, Work in Progress, draft-pritikin-anima-bootstrapping-keyinfra-01, February 2015.

[Dobson] Dobson, S., Denazis, S., Fernandez, A., Gaiti, D., Gelenbe, E., Massacci, F., Nixon, P., Saffre, F., Schmidt, N., and F. Zambonelli, “A survey of autonomic communications”, ACM Transactions on Autonomous and Adaptive Systems (TAAS), Volume 1, Issue 2, Pages 223-259, DOI 10.1145/1186778.1186782, December 2006.

[GANA] ETSI, “Autonomic network engineering for the self-managing Future Internet (AFI); Generic Autonomic Network Architecture (An Architectural Reference Model for Autonomic Networking, Cognitive Networking and Self-Management)”, ETSI GS AFI 002, April 2013, <http://www.etsi.org/deliver/etsi_gs/AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf>.

[Kephart] Kephart, J. and D. Chess, “The Vision of Autonomic Computing”, IEEE Computer, vol. 36, no. 1, pp. 41-50, DOI 10.1109/MC.2003.1160055, January 2003.

[Movahedi] Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, “A Survey of Autonomic Network Architectures and Evaluation Criteria”, IEEE Communications Surveys & Tutorials, Volume 14, Issue 2, Pages 464-490, DOI 10.1109/SURV.2011.042711.00078, 2012.

[Reference-Model] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, L., and B. Liu, “A Reference Model for Autonomic Networking”, Work in Progress³, draft-behringer-anima-reference-model-02, June 2015.

[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, “General Gap Analysis for Autonomic Networking”, RFC 7576, DOI 10.17487/RFC7576, June 2015, <http://www.rfc-editor.org/info/rfc7576>.

[Samaan] Samaan, N. and A. Karmouch, “Towards Autonomic Network Management: an Analysis of Current and Future Research Directions”, IEEE Communications Surveys and Tutorials, Volume 11, Issue 3, Page(s) 22-36, DOI 10.1109/SURV.2009.090303, 2009.

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

Большая часть работы по AN выполнена в рамках крупного проекта Cisco Systems, где участвовали (в алфавитном порядке) Ignas Bagdonas, Parag Bhide, Balaji BL, Toerless Eckert, Yves Hertoghs, Bruno Klauser.

Спасибо за вклад в документ Dimitri Papadimitriou, Rene Struik, Kostas Pentikousis, Dave Oran, Diego Lopez Garcia.

Рабочая группа ETSI AFI <http://portal.etsi.org/afi> определила похожую схему для Autonomic Networking в документе «General Autonomic Network Architecture» [GANA]. Многие из концепций данного документа можно сопоставить со схемой GANA, но это выходит за рамки этого документа. Отдельная благодарность Ranganai Chaparadza за комментарии и помощь при создании документа.

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

Michael H. Behringer

Cisco Systems

Building D, 45 Allee des Ormes

Mougins 06250

France

EMail: mbehring@cisco.com

Max Pritikin

Cisco Systems

5330 Airport Blvd

Boulder, CO 80301

United States

EMail: pritikin@cisco.com

Steinthor Bjarnason

Cisco Systems

Mail Stop LYS01/5

Philip Pedersens vei 1

LYSAKER, AKERSHUS 1366

Norway

EMail: sbjarnas@cisco.com

Alexander Clemm

Cisco Systems

170 West Tasman Drive

San Jose, CA 95134-1706

United States

EMail: alex@cisco.com

Brian Carpenter

Department of Computer Science

University of Auckland

PB 92019

Auckland 1142

New Zealand

EMail: brian.e.carpenter@gmail.com

Sheng Jiang

Huawei Technologies Co., Ltd

Q14, Huawei Campus

No.156 Beiqing Road

Hai-Dian District, Beijing 100095

China

EMail: jiangsheng@huawei.com

Laurent Ciavaglia

Alcatel Lucent

Route de Villejust

Nozay 91620

France

EMail: laurent.ciavaglia@alcatel-lucent.com

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

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

nmalykh@protokols.ru