ГОСТ Р 58210-2018/ISO/IEC TR 29181-1:2012. Национальный стандарт Российской Федерации. Информационные технологии. Сети будущего. Формулировка проблем и требования. Часть 1. Общие аспекты

(утв. и введен в действие Приказом Росстандарта от 04.09.2018 № 559-ст)

от 4 сентября 2018 г. № 559-ст

Предисловие

1 Подготовлен Федеральным государственным бюджетным образовательным учреждением высшего образования «Российский экономический университет им. Г.В. Плеханова» (ФГБОУ ВО «РЭУ им. Г.В. Плеханова») на основе собственного перевода на русский язык англоязычной версии документа, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 4 сентября 2018 г. № 559-ст

4 Настоящий стандарт идентичен международному документу ISO/IEC TR 29181-1:2012 «Информационные технологии. Сети будущего. Формулировка проблем и требования. Часть 1. Общие аспекты. (ISO/IEC TR 29181-1:2012, Information technology — Future Network — Problem statement and requirements — Part 1: Overall aspects», IDT)

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

ИСО (Международная организация по стандартизации) и МЭК (Международная электротехническая комиссия) образуют специализированную систему всемирной стандартизации. Национальные органы, являющиеся членами ИСО или МЭК, участвуют в разработке международных стандартов с помощью технических комитетов, созданных соответствующей организацией для рассмотрения конкретных областей технической деятельности. Технические комитеты ИСО и МЭК сотрудничают в областях, представляющих взаимный интерес. В работе также принимают участие и другие международные организации, правительственные и неправительственные, совместно с ИСО и МЭК. В области информационных технологий ИСО и МЭК учредили Объединенный технический комитет ИСО/МЭК ОТК 1.

Международные стандарты разрабатываются в соответствии с правилами, приведенными в инструкциях ИСО/МЭК, часть 2.

Основная задача Объединенного технического комитета состоит в подготовке международных стандартов. Проекты международных стандартов, подготовленные Объединенным техническим комитетом, рассылаются национальным комитетам на голосование. Публикация в качестве международного стандарта требует утверждения не менее чем 75% национальных комитетов, участвующих в голосовании.

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

Обращается внимание на то, что некоторые элементы настоящего международного стандарта могут быть объектом патентных прав. ИСО и МЭК не несут ответственности за определение какого-либо или всех таких патентных прав.

Документ ISO/IEC TR 29181-1 разработан Объединенным техническим комитетом ИСО/МЭК ОТК 1 «Информационные технологии», подкомитетом 6 «Телекоммуникации и обмен информацией между системами».

ISO/IEC TR 29181 состоит из следующих частей под общим заголовком «Информационные технологии. Будущие сети. Изложение проблемы и требования».

• Часть 1. Общие положения.

В разработке находятся следующие части:

• Часть 2. Присвоение имен и адресов.
• Часть 3. Коммутация и маршрутизация.
• Часть 4. Мобильность.
• Часть 5. Безопасность.
• Часть 6. Распространение средствами массовой информации.
• Часть 7. Содержание сервиса.

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

Но, несмотря на столь высокий уровень развития, мы продолжаем наблюдать ряд проблем, связанных с техническими аспектами современного Интернета, включая IP-сети: проблемы с масштабированием, вездесущностью, безопасностью, надежностью, мобильностью, разнородностью, качеством сервиса (QoS), способностью к изменению конфигурации, восприятием контента, управляемостью, экономичностью и т.д. Кроме того, развитие устройств хранения данных большого объема, высокоскоростных вычислительных устройств и технологий ультраширокополосной передачи (например, peta/exa/zeta бод) приводит к появлению многих новых устройств, таких как датчики, микроустройства, средства доставки и т.д. Полученная в результате этого новая форма архитектуры информационно-коммуникационных технологий (ИКТ) и огромное количество новых сервисов не могут поддерживаться современными сетевыми технологиями на должном уровне.

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

В данной части документа ISO/IEC TR 29181 описаны общие аспекты БС, включая определение, общую концепцию, проблемы и требования.

Кроме того, здесь обсуждается этап стандартизации БС.

1 Область применения

Настоящий стандарт дает определение, описывает общую концепцию, проблемы и требования для Будущих сетей (БС). В нем также рассматривается этап стандартизации БС. В содержание этого стандарта также входят:

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

2 Нормативные ссылки

Нормативные ссылки отсутствуют.

3 Термины и определения

В настоящем стандарте применены следующие термины и определения:

3.1 будущая сеть (БС): Сеть будущего, построенная «с нуля», с поэтапным подходом к проектированию.

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

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

Примечание — При подходе «с нуля» обратная совместимость может не потребоваться [1], [2].

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

Примечание — Виртуализация сети дает возможность объединения многочисленных ресурсов, представляемых в виде единого ресурса [3], [4].

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

3.5 автономный сервис: Сервис, позволяющий пользователям или мобильным сервисам автономно настраивать сети и управлять сетями.

3.6 контекстно-ориентированный сервис: Сервис, позволяющий приложениям или сервисам адаптировать свое поведение под физическую среду.

3.7 организация сети на основе контента: Технология, позволяющая поддерживать маршрутизацию на основе контента, а не физического местоположения.

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

3.9 технология настройки отношения QoS/QoE (качество сервиса/качество услуги на основе оценки (восприятия) пользователем): Технология, позволяющая поддерживать предпочтительные настройки и, соответственно, компоновку/перекомпоновку сервиса.

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

3.11 метод «конструктивных элементов» (BB): Метод разработки набора стандартов путем создания некоторых базовых модулей или элементов, которые могут быть объединены вместе для получения общей архитектуры или целых операций.

Примечание 1 — Этот подход может быть использован для разработки новой сложной технологии, такой как Future Network, в которой на текущем этапе не всем основным связанным элементам можно дать определение.

Примечание 2 — Определение Интернета и NGN (сеть следующего поколения).

Интернет — набор взаимосвязанных сетей, использующих интернет-протокол, который позволяет им функционировать как единая крупномасштабная крупная виртуальная сеть [5]. Интернет — глобальная система взаимосвязанных компьютерных сетей, которые обмениваются данными путем коммутации пакетов с использованием стандартизованного пакета интернет-протокола (TCP/IP). Это «сеть из сетей», состоящая из миллионов частных и общественных, академических, деловых и правительственных сетей от локального до глобального масштаба, которые связаны медными проводами, оптоволоконными кабелями, беспроводными соединениями и с помощью других технологий [5].

Сеть следующего поколения (NGN) — пакетная сеть, способная предоставлять телекоммуникационные сервисы и использовать несколько широкополосных технологий трафика с поддержкой QoS, в которой функции, связанные с сервисом, не зависят от базовых технологий трафика. Она обеспечивает неограниченный доступ пользователей к сетям и конкурирующим поставщикам сервисов и (или) сервисам по их выбору. Сеть следующего поколения поддерживает обобщенную мобильность, которая позволит обеспечить постоянное и повсеместное предоставление сервисов пользователям [6].

4 Сокращения

AAA — (Authentication, Authorization, and Accounting) аутентификация, авторизация и учет;

BB — (Building Blocks) конструктивные элементы;

DNS — (Domain Name System) система доменных имен;

FA — (Functional Architecture) функциональная архитектура;

FI — (Future Internet) интернет будущего;

FIRE — (Future Internet Research and Experiments) исследования и эксперименты в области Интернета будущего;

FN — (Future Network) будущие сети;

FP7 — (Framework Program 7) рамочная программа 7;

GENI — (Global Environment for Network Innovations) глобальная среда для сетевых инноваций;

ICT — (Information Communication Technology) информационно-коммуникационные технологии (ИКТ);

IoT — (Internet of Things) интернет вещей (физических объектов);

IP — (Internet Protocol) интернет-протокол;

IPv4 — (Internet Protocol version 4) интернет-протокол, версия 4;

IPv6 — (Internet Protocol version 6) интернет-протокол, версия 6;

ISP — (Internet Service Provider) интернет-провайдер;

NAT — (Network Address Translation) трансляция сетевых адресов;

NGN — (Next Generation Networks) сети следующего поколения;

NwGN — (New Generation Network) сеть нового поколения;

P2P — (Peer-to-Peer) одноранговая сеть;

PI — (Provider Independent) независимый от провайдера;

QoE — (Quality of Experience) качество услуги на основе оценки (восприятия) пользователем;

QoS — (Quality of Service) качество сервиса;

SOA — (Service Oriented Architecture) сервисно-ориентированная архитектура.

5 Обзор

5.1 Необходимость в исследовании и стандартизации Будущих сетей

Существующая технология на основе IP имеет значительные недостатки, которые необходимо устранить, прежде чем она может стать единой глобальной коммуникационной инфраструктурой. В частности, в существующих IP-сетях есть проблемы с большим количеством хостов, таких как датчики, различные беспроводные и мобильные узлы, множественными интерфейсами и узлами, объединяющими несколько домов, а также проблемы с необходимостью поддержки мобильных технологий в реальном времени и быстродействующих мобильных хостов, с необходимостью обеспечения безопасности электронных транзакций, качества гарантийного обслуживания, с бизнес-аспектами и т.д. Поэтому для решения этих проблем были проведены различные исследования. Кроме того, в настоящее время проявляется значительная обеспокоенность в связи с тем, что недостатки не будут полностью устранены традиционным способом текущих исследований с «обратной совместимостью» и мер по стандартизации. Именно по этой причине исследования БС называют «разработкой архитектуры новой сети с нуля». Предполагается, что разработка БС должна обсуждаться на основе подхода «с нуля», а также пошагового проектирования.

В связи с этим необходимо изучить и стандартизировать БС, которая преодолеет ограничения существующих сетей и обеспечит новые сервисы, обладающие богатыми возможностями.

5.2 Значение и концепция Будущих сетей

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

Кроме того, БС смогут предоставлять миллионы/миллиарды сервисов, поэтому для предоставления контекстно-ориентированных сервисов БС потребуется гибкая структура. Контекстно-ориентированный сервис — это ключевая функциональность, необходимая для предоставления динамически адаптируемых сервисов, и ключевая функция, гарантирующая бесперебойное предоставление медиасервисов, что позволит создавать расширенные и обновленные сервисы для конечных пользователей.

Видение развития БС приведено на рисунке 1.

Рисунок 1 — Видение развития Будущих сетей

Сегодняшние сети, как правило, основаны на интернет-протоколе IPv4. Для совершенствования Интернета существует два подхода к проектированию: разработка «с нуля» и пошаговое проектирование. Интернет будущего будет разработан «с нуля», смоделирован и развернут примерно в период между 2015 и 2020 годами. В то же время сегодняшние сети будут постепенно эволюционировать. Таким образом, будут сосуществовать две различные сетевые технологии, для поддержки беспроблемной интеграции которых потребуется федерация и миграция сервисов. Федерация должна определяться как взаимосвязь нескольких гетерогенных сетей (например, IPv4, IPv6, Будущего интернета или сетей, не основанных на IP). Федерация обычно объединяет географически распределенные сети, которые управляются различными организациями/интернет-провайдерами. Однако они будут считаться частью единой сети, поскольку работают в общей структуре управления в рамках единого органа управления. Таким образом, несколько гетерогенных сетей в конечном итоге будут рассматриваться как единая федеративная сеть — БС. БС охватывают все «прорывные» сети, а также другие существующие сети. БС имеет более широкий охват, чем Будущий интернет, и включает в себя другие сети, отличные от IP-сетей (например, датчики, сети транспортных средств, спутники и т.д.).

6 Сервисы и приложения в Будущих сетях

В настоящем разделе представлены следующие сервисы сети будущего, которые рассматриваются как ориентиры для создания БС.

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

Исследовательские проекты	Предполагаемые будущие сервисы
GENI [7] (глобальная среда для сетевых инноваций)	- Повсеместно доступное здравоохранение - Сбор информации о городской среде с участием ее жителей - Обращение с персональными данными - Теле-присутствие
NwGN [8] (архитектура сети нового поколения)	- Критически важные сервисы: здравоохранение, транспорт, помощь в чрезвычайных ситуациях
EU FP-7 [9] (рамочная программа 7 Европейского союза)	- Создание персональных сервисов - Дом будущего - Будущее транспорта - Виртуальная реальность - Инструменты для повышения производительности
Стратегии развития и распространения Интернета будущего Республики Корея [10]	- Сервисы интеллектуальных сетей - Сервисы облачных сетей - Сервисы Интернета вещей

Отличаясь от традиционных КТ (коммуникационных технологий) или ИТ (информационных технологий), сервисы будущего должны быть пересмотрены в соответствии с более широкой концепцией, поскольку БС будут охватывать широкий спектр гетерогенных сетей [11], учитывающей проблемы: вездесущности, функциональности, мощности, детализации, времени, масштаба, интеллекта, ролей, людей и их имущества, а также принципа «к вашим услугам».

Это сервисы, которые появятся к 2020 году.

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

Сервисы, ориентированные как на пользователя (I-Centric), так и на сеть (Net-Centric). Целью сервисов будущего является удовлетворение потребностей и обеспечение максимального удобства для конечных пользователей при оптимальном использовании сетевых ресурсов.

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

Рисунок 2 — Концепция сервисов Будущих сетей

В число ключевых функций, которые должны поддерживать сервисы БС, входят:

• контекстно-ориентированный подход;
• динамическая адаптивность;
• самоорганизация и самоконфигурирование;

- самодиагностика и самовосстановление;

• распределенное управление;
• управление большими данными.

7 Формулирование проблем

Для БС проблемы можно классифицировать как: 1) основные проблемы и 2) проблемы, связанные с основополагающими принципами проектирования существующего Интернета. Большинство из них также изучаются и исследуются во многих организациях и исследовательских проектах, таких как IETF/IRTF [12, 13], ITU-T [14], группа FIA Arch EU [15].

7.1 Основные проблемы

7.1.1 Отказы маршрутизации и масштабируемость

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

7.1.2 Незащищенность

Одна из главных проблем существующего Интернета заключается в незащищенности коммуникаций. Коммуникации сегодня не всегда вызывают доверие, при этом очевидны такие проблемы как рост уязвимостей, распространение вирусов («червей»), а также сетевые атаки. Даже без атак сервис часто бывает недоступен из-за отказов оборудования, поддерживающего ненадежные протоколы IP-маршрутизации.

7.1.3 Мобильность

Существующие IP-технологии предназначены для хостов в фиксированных местоположениях и плохо подходят для поддержки мобильных хостов. Для поддержки мобильности хоста был разработан протокол Mobile IP, однако он имеет некоторые проблемы, связанные с задержкой обновления, сбоями при передаче данных, с обеспечением конфиденциальности местоположения. Кроме того, существующая архитектура протокола Mobile IP сталкивается с трудностями при быстрой вертикальной передаче. Более того, недавно стали доступны множественные интерфейсы для пользовательских устройств для доступа к гетерогенным сетям множественного доступа. В этом случае необходим контроль трафика уровня потока в дополнение к управлению мобильностью на уровне хоста.

7.1.4 Качество сервиса

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

7.1.5 Гетерогенные физические уровни, приложения и архитектура

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

7.1.6 Управление сетью

У существующей архитектуры Интернета недостаточно возможностей в плане управления. Мгновенное и простое управление крайне необходимо для пользователей, поскольку Интернет будущего может состоять из вновь возникающих гетерогенных беспроводных, мобильных и ситуативных архитектур. Например, для будущих мобильных сетей следует предусмотреть следующее автономное управление: самозащита, самовосстановление, самоконфигурация, самооптимизация и т.д.

7.1.7 Отказ при избыточной нагрузке

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

7.1.8 Вероятностные коммуникации

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

7.1.9 Быстрая междугородная связь

Существующий Интернет основан на принципе сквозной пересылки пакетов, то есть поиска наилучшего по скорости канала, поэтому в узком месте возникает задержка. С увеличением расстояния вероятность появления «узкого места» становится выше.

7.1.10 Отсутствие эффективного распространения медиа-информации

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

7.1.11 Адаптируемость

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

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

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

7.1.12 Экономика и политика

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

7.2 Проблемы, основополагающие принципы проектирования существующего Интернета

7.2.1 Коммутация пакетов

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

7.2.2 Модели по сквозному принципу

Модели сквозного принципа постепенно разрушались, главным образом за счет использования трансляторов сетевых адресов (NAT), которые изменяют адреса брандмауэров и других промежуточных устройств, для которых необходимо понимание семантики любого номера порта (например, для блокировки или дифференциальной обработки потока). В результате конечные хосты часто не могут подключиться, даже если политика безопасности допускает такие подключения. Эта проблема будет только усугубляться с ростом необходимости в переходе с IPv4 на IPv6. Помимо этого, прочие изменения в способе использования Интернета повлияли на исходную модель уникального адреса/порта в транспортных соединениях.

7.2.3 Разделение на уровни

Разделение на уровни была одной из важных характеристик современных интернет-технологий, но на данном этапе она неизбежно теряет эффективность. Одной из сложных проблем является поддержка быстрой мобильности в гетерогенной многоуровневой архитектуре. Необходимо исследовать, где находятся интерфейсы, и какие сервисы должен предоставлять каждый уровень.

7.2.4 Присвоение имен и адресов

Схемы именования и адресации являются двумя важными и ключевыми элементами в архитектуре сети и предоставлении сервисов. Разработка концепции именования и адресации имеет решающее значение для характеристик и эффективности сетей. Фундаментальная структура схемы именования и адресации в современных сетях, особенно в IP-сетях, в основном была разработана более 40 лет назад и представляет собой основной корень проблем, с которыми сталкиваются существующие сети. Например, процесс поиска IP-адреса в DNS и процесс трансляции, централизованная регистрация имени домена, иерархическая структура и так далее ограничивают потенциал существующих сетей. Следует изучить новые принципы именования и адресации, чтобы помочь достижению целей БС.

8 Общие требования к Будущим сетям

В данном разделе приведено описание новых целей проектирования и высоких требований к БС.

8.1 Масштабируемость

БС должны поддерживать масштабируемую архитектуру маршрутизации. Проблема масштабируемости возникает по мере постоянного роста культурных требований к созданию сетей будущего. Предполагается, что в течение следующих 10 — 15 лет телекоммуникационные сети, включая Интернет, претерпят ряд значительных изменений в отношении технологий, сервисов, масштаба и т.д. Например, может быть распространена связь между машинами в дополнение к существующему способу общения между людьми. Масштабируемость должна включать в себя следующие аспекты:

• архитектура маршрутизации и адресации;
• множественная адресация и независимость провайдеров (маршрутизация PI).

8.2 Схема присвоения имен и адресов

Для БС могут потребоваться новые схемы именования и адресации, для которых потребуется следующее:

- новые схемы именования и адресации должны использовать преимущество разработки «с нуля», чтобы исследовать, идентифицировать и экспериментально завершить полностью новую архитектуру;

• эта архитектура не должна подчиняться старым правилам именования и адресации сетей, но, с другой стороны, вопрос совместимости и взаимодействия также следует учитывать при оценке технических предложений;
• архитектура, которая могла бы помочь БС достичь таких целей, как масштабируемость, безопасность, мобильность, надежность, гетерогенность, качество сервисов, адаптируемость и наличие экономических стимулов;
• способность интеграции различных сетей, поддержки новых протоколов, создания баз для новых приложений и сервисов и поддержки новых сетевых технологий.

8.3 Безопасность

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

8.3.1 Конфиденциальность

Из практических соображений по предотвращению таких атак, как «спуфинг», следует закрепить каждого пользователя или устройство за одним идентификатором. Тем не менее, пользователи ценят конфиденциальность и вряд ли будут использовать системы, которые требуют отказаться от своей анонимности. Например, большинство пользователей будут недовольны такой системой, как мобильная IP-сеть, которая позволяет другим знать их местоположение. Увязка вопросов конфиденциальности с необходимостью проверки подлинности в БС потребует шифрования из правовых, социальных и практических соображений.

8.3.2 Мобильность

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

8.3.3 Одноранговая сеть

Почему сегодня аутентификация и доверие к корреспонденту становятся проблемой в сетях? Одна из важных причин заключается в том, что многие механизмы аутентификации не способны обеспечить полноценную процедуру взаимной аутентификации. Например, сейчас внимание сосредоточено на том, как идентифицировать станцию «спуфинга» сервером, в то время как на станции обычно нет эффективной схемы проверки подлинности сервера в сети. Следовательно для БС должны быть разработаны механизмы аутентификации в одноранговой сети и обеспечения коллективной безопасности.

8.3.4 Ресурс

С ростом повсеместной доступности сетей становится очевидно, что ограничения размера и стоимости узла также ограничивают энергоэффективность, объем памяти и производительность вычислений, что создает проблему аутентификации для БС. Например, при нехватке ресурсов процессоров и памяти нецелесообразно использовать асимметричные криптосистемы, такие как криптосистема RSA, для аутентификации в беспроводных сетях датчиков, где каждый узел состоит из медленного маломощного процессора с объемом оперативной памяти всего 4 Кб.

8.3.5 Гетерогенность

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

8.3.6 Атака

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

8.4 Мобильность

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

Разделение идентификатора пользователя и сетевого адреса.

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

Отделение функции управления мобильностью от функции передачи пользовательских данных

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

Конфиденциальность местоположения в мобильной сети

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

Поддержка встроенного управления мобильностью на основе сети

Для эффективного обеспечения мобильности пользователей в БС должны быть предусмотрены функции управления мобильностью на основе сети. В частности, функциональность управления мобильностью должна предоставляться по принципу «встроенная функциональность», а не «добавленная функциональность».

Оптимизация маршрута

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

Использование информации нижнего уровня

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

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

Когда на хосте одновременно активны несколько интерфейсов, система должна быть способна динамически распределять каждый поток сервисов в одну из наиболее подходящих и эффективных для него сетей доступа, чтобы предоставлять пользователю широкий диапазон QoS/QoE. Приложение также должно иметь несколько соединений и разрешать любому трафику использовать сеть доступа с наиболее подходящими для него характеристиками. Поэтому Будущий Интернет должен быть в состоянии обеспечить механизм для поддержки управления множественными подключениями и мобильностью потока.

Кроме того, в контексте мобильности в БС должны быть обеспечены следующие функции.

8.4.1 Контекстно-ориентированный подход

Ожидается, что мобильность в БС будет поддерживать распознавание контекста (ситуации). В 8.7.4 приведены детали распознавания контекста. Несмотря на то, что определение местоположения является основополагающим, ситуационная осведомленность о местоположении не обязательно отражает все представляющие интерес изменяющиеся или мобильные аспекты.

8.4.2 Многоузловая структура и плавное переключение потоков

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

8.4.3 Гетерогенность

Ожидается, что мобильность в БС будет поддерживать гетерогенность. В 8.6 приведена подробная информация о гетерогенности.

8.5 Адаптируемое качество сервисов

БС должны поддерживать качество сервиса (QoS) с точки зрения пользователей и (или) приложений. Кроме того, ожидается, что QoS в БС будет поддерживать структуру сервиса и распознавание контекста, описанные в 8.7.2 и 8.7.4 соответственно.

8.6 Гетерогенность и сетевая виртуализация

БС должны обеспечить гораздо лучшую поддержку широкого спектра приложений/сервисов и предоставлять новые приложения/сервисы. Кроме того, БС должна учитывать гетерогенные физические среды. Также, в контексте поддержки гетерогенности, в БС должны быть обеспечены следующие функции.

8.6.1 Гетерогенность приложения/сервиса

БС должны быть рассчитаны на поддержку новых сервисов и (или) приложений, например сервисов, ориентированных на данные. Существующий Интернет был разработан, как ориентированный на хосты, что означает, что пользователи сообщают клиенту указание связаться с другим хостом (например, telnet, ftp). Однако вновь возникающие сервисы, скорее всего, ориентированы на данные. Пользователи хотят получить доступ к определенным данным или сервису (например, P2P), не заботясь о том, где находятся данные или сервис.

8.6.2 Гетерогенность устройства

БС должны будут поддерживать новые устройства, такие как датчики, радиочастотные идентификаторы (RFID) и т.д.

8.6.3 Гетерогенность физической среды

БС должны размещать разнородные физические носители, такие как оптическое волокно, сети беспроводного доступа (например, IEEE 802.11/16/15.4 ...) и т.д. Эта физическая гетерогенность создает огромные проблемы для архитектуры Будущего Интернета.

8.6.4 Виртуализация сети

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

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

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

8.7 Оповещение о состоянии сервисов

БС должны эффективно предоставлять сервисы с учетом требований, предъявляемых каждым переданным сообщением. Таким образом, предоставление сервисов должно учитывать потребности с точки зрения QoE и предпочтения запрашивающей стороны. Следовательно, запрашивающая сторона улучшит свой сервис, если ее требования будут рассмотрены.

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

БС должны иметь возможность обнаруживать и составлять сервисы с учетом параметров QoE, предпочтений и состояния контекста.

Следующие функции являются фундаментальными для их принятия БС:

обнаружение сервиса;

содержание сервиса;

самоорганизующийся контекстно-ориентированный сервис;

сервис QoE.

8.7.1 Обнаружение сервиса

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

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

8.7.2 Содержание сервиса

БС должны поддерживать эффективные методы составления для составных сервисов. БС должны поддерживать статический и динамический состав сервисов, когда статический состав набирается во время разработки, а динамический состав наполняется во время исполнения.

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

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

8.7.3 Самоорганизующийся сервис

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

В БС потребуется обеспечить эффективные механизмы самоорганизации размещения и координации сервисов внутри сети, поскольку они позволяют выполнять автономную конфигурацию и адаптацию к динамическим изменениям с учетом доступности сервисов, перегрузки или сбоя.

В частности способность самоорганизации сервисов включает в себя самоконфигурацию, самооптимизацию и самовосстановление сервисов.

8.7.4 Контекстно-ориентированный подход

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

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

Такой контекст включает в себя, в том числе пользователя, устройство, сервис, системные ресурсы и сетевой контекст. Контекст пользователя может включать в себя характеристики пользователя, его местоположение, предпочтения, а также ограничения среды для пользователя (например, общественные места, где требуется тишина, рабочее место, дом и т.д.). Контекст устройства может включать в себя тип и возможности устройства. Контекст сервиса может включать в себя доступность сервисов, необходимый уровень QoS и эффективность обслуживания. Контекст системных ресурсов может включать в себя ЦПУ, память, процессор, диск, устройства ввода/вывода и хранилище. Сетевой контекст может включать в себя пропускную способность, трафик, топологию и эффективность сети.

Такой контекст можно обрабатывать как совокупно, так и отдельно с каждым пользователем, устройством, сервисом и сетевым контекстом. Например, составной контекст может быть сконструирован объединением контекста пользователя и сети. Такой составной контекст может быть использован при составлении сервисов или при внешнем использовании сервисами, чтобы им не приходилось дополнительно собирать или обосновывать другие типы контекста.

БС должны поддерживать управление контекстом для предоставления настраиваемых и контекстно-ориентированных сервисов.

8.7.5 Показатель QoE сервиса

БС должны быть способны предоставлять настраиваемые сервисы в соответствии с контекстом или предпочтениями пользователей, чтобы максимизировать показатель QoE (качества восприятия пользователем), необходимый для сервиса.

Показатель QoE является субъективной оценкой удовлетворенности пользователя при использовании определенного сервиса. Метрики, необходимые для оценки уровня QoE, зависят от конкретного сервиса, запрашиваемого пользователем. Кроме того, показатель QoE тесно связан с QoS — показателем, призванным объективно оценить сервис, предоставляемый провайдером.

8.8 Передача медиаданных

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

8.9 Новая многоуровневая архитектура

Для БС может потребоваться новая многоуровневая архитектура. В целом разделение на уровни было одной из важных характеристик современных интернет-технологий, но в последнее время также отмечается, что иногда это неизбежно снижает эффективность. Следовательно БС могут обеспечивать межуровневые функции связи. Чтобы добиться этого, нужно сначала исследовать зависимость между уровнями протокола для повышения производительности, а затем создать новые интерфейсы между уровнями, переопределить границы этих уровней, разработать протокол уровня, основываясь на деталях проектирования другого уровня, совместной настройке параметров по уровням, или создать совершенно новую абстрактную конструкцию. Цель коммуникаций между уровнями состоит в обеспечении способа прямой связи между протоколами на несмежных уровнях или обмена переменными между уровнями. Мы принимаем этот принцип только для мобильных, беспроводных, сенсорных подсетей, поскольку всегда существует компромисс между оптимизацией и сложностью (абстракцией). Таким образом измерение и мониторинг должны быть обеспечены заранее. Кроме того, этот принцип предназначен для поддержки на любом уровне (например, от физического уровня до уровня приложения) и должен быть реализован через виртуализацию сети для поддержки гибкости и программируемости.

8.10 Управление

БС должны поддерживать мгновенное и простое управление. БС будут становиться все более сложной по мере появления новых сервисов и за счет разнообразия архитектуры. В контексте управления в БС должны предоставляться следующие возможности.

8.10.1 Надежность

БС должны быть такими же надежными, отказоустойчивыми и доступными, как проводная телефонная сеть сегодня. Надежность следует рассматривать в следующих аспектах: автоматическая отчетность о сбоях связи и отказах оборудования и немедленная повторная маршрутизация в обход сбоев; возможность устранения отказов оборудования и устойчивость к атакам типа «отказ в обслуживании» и аналогичным атакам.

8.10.2 Автономность

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

8.11 Энергоэффективность

БС должны обеспечить возможности энергосбережения для поддержки экологически чистых сред ИКТ. Энергосбережение в сетях означает сетевые возможности там, где систематически потребляется общая мощность сетевого оборудования, такого как маршрутизаторы и коммутаторы, позволяя снизить потребление энергии по сравнению с существующими сетями.

8.12 Экономические стимулы

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

8.12.1 Качество сервиса/восприятия пользователем

БС должны обеспечивать достаточное качество сервиса (QoS) и (или) восприятия пользователем (QoE) с точки зрения пользователей и (или) приложений. Кроме этого, ожидается, что QoS/QoE в БС будут способны распознавать контекст, например местоположение.

8.12.2 Управляемость

БС будут становиться все более сложной за счет появления новых сервисов и разнообразия архитектуры. Поэтому в БС желательно обеспечить быструю и простую управляемость. Доступность ресурсов — одна из важных проблем, которые нужно решать с точки зрения экономических стимулов в БС.

8.12.3 Адаптируемость

Должна иметься возможность настройки БС с учетом различных требований и (или) предпочтений каждого пользователя.

8.12.4 AAA и безопасность

Для обеспечения экономических стимулов БС должны строиться на основе принципа AAA (аутентификация, авторизация и учет) и безопасности.

8.12.5 Операционный аспект

БС должны предоставлять сетевым провайдерам и (или) интернет-провайдерам рабочую платформу (инфраструктуру и архитектуру) для обеспечения экономической деятельности.

9 Этапы стандартизации БС

В данном разделе описывается набор перспективных элементов для стандартизации БС.

9.1 Общий план работы

Данный технический отчет описывает постановку задачи и требования к БС. В ходе обсуждений БС был разработан набор требований по проектированию для дальнейшей работы по стандартизации БС.

На основе этих результатов необходимо разработать архитектуру БС и обеспечить разработку конкретных протоколов в качестве будущих рабочих элементов, как показано на следующем рисунке 3.

Рисунок 3 — Общие этапы стандартизации БС

На этапе 1 в данном отчете определен набор требований для проектирования архитектуры БС. На этапе 2 будет разработана архитектура БС. Разработку архитектуры БС можно выполнить с помощью набора конструктивных элементов (BB) общей архитектуры БС. Подход на основе BB — это метод разработки набора стандартов путем создания определенных базовых модулей или элементов, которые могут быть объединены для получения общей архитектуры или целых операций. Это связано с тем, что архитектура БС содержит множество технических особенностей, которые следует учитывать, таких как сервисы/приложения, идентификация, именование/адресация, управление мобильностью, QoS, безопасность и виртуализация сети, перенос из текущей сети в БС. При данном подходе на основе конструктивных элементов набор архитектур BB приведет к созданию общей архитектуры БС. Из архитектуры БС на этапе 3 может быть разработан один или несколько специфических протоколов БС. Подробная информация о протоколах для БС, которые предстоит разработать, потребует дальнейшего изучения.

9.2 Архитектура БС

Архитектура БС будет разрабатываться на основе набора архитектурных компонентов, являющихся конструктивными элементами (BB). Эти BB могут включать в себя следующие компоненты архитектуры, но не все из перечисленных:

• сервисы/сетевая модель и функциональная архитектура (FA);
• присвоение имен и адресов;
• коммутация и маршрутизация;

• безопасность;

• содержание сервиса;
• федерация.

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

Рисунок 4 — Компоненты конструктивных элементов (BB) для архитектуры Будущих сетей

Как показано на рисунке 4, сервисы и конструктивные элементы сети будут использоваться в качестве основных ресурсов для разработки общей функциональной архитектуры BB. На основе функциональной архитектуры BB могут быть разработаны следующие конкретные функциональные BB: коммутация/маршрутизация, композиция сервисов, распространение медиаданных, безопасность, мобильность и другие дополнительные конструктивные элементы. Для стандартизации каждый из BB будет выполнен как часть общей архитектуры БС.

В вышеуказанный список можно добавить еще несколько частей (конструктивных элементов) в зависимости от ситуации.

9.2.1 Архитектура Будущих сетей: сервисы/сетевая модель и функциональная архитектура

В качестве базовой архитектуры следует определить сервисы и сетевую модель для БС. Эта работа призвана решить следующие проблемы:

сервисы, включая определенный набор целевых сервисов и ключевых приложений, должны предоставляться в среде БС;

модель сети должна учитываться при проектировании архитектуры БС, которая будет включать в себя сеть стационарного/беспроводного доступа, основную/резервную сеть, взаимодействие между сетями доступа и базовыми сетями;

абстрактный стек протоколов в многоуровневой архитектуре;

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

Блоки BB функциональной архитектуры FA станут основной частью архитектуры БС. Необходимо определить подробности функциональности, требуемые для БС, и описать взаимосвязь или взаимодействие между функциями БС. Следует также изучить схемы или принципы маршрутизации/коммутации для БС. Эта работа призвана решить следующие проблемы:

функциональность, требуемая для БС, такая как маршрутизация, контроль мобильности, QoS, безопасность и т.д.;

конкретный стек протоколов, содержащий протоколы БС в архитектуре;

9.2.2 Архитектура Будущих сетей: присвоение имен и адресов

Данный конструктивный элемент должен представить архитектуру присвоения имен и адресов для БС. Эта работа призвана решить следующие проблемы:

идентификация и идентификатор;

разделение идентификатора пользователя и сетевого адреса;

масштабируемое присвоение имен и адресов.

9.2.3 Архитектура Будущих сетей: коммутация и маршрутизация

Данный BB должен представить архитектуру коммутации/маршрутизации для БС. Эта работа призвана решить следующие проблемы:

модель уровня управления и уровня данных;

функциональная архитектура для коммутации/маршрутизации;

требования к протоколам уровня управления;

совместимость и миграция.

9.2.4 Архитектура Будущих сетей: мобильность

Данный BB должен представить архитектуру контроля мобильности для БС. Эта работа призвана решить следующие проблемы:

схема контроля мобильности в БС;

управлением местоположением мобильных пользователей;

беспроблемный перенос поддержки для мобильных пользователей;

разделение идентификатора пользователя и сетевого адреса;

отделение функции переноса данных пользователя от функции контроля за мобильностью;

контекстно-ориентированный подход;

множественная адресация и поддержка вертикального переноса;

гетерогенность сетей со стационарным и беспроводным доступом.

9.2.5 Архитектура Будущих сетей: безопасность

Данный BB должен решить вопрос обеспечения безопасности пользователей БС и может включать в себя исследование пригодности множества существующих схем обеспечения безопасности для БС. Эта работа призвана решить следующие проблемы:

рост числа уязвимостей;

распространение «червей»;

атаки типа «отказ в обслуживании».

9.2.6 Архитектура Будущих сетей: поток медиаданных

Данный BB должен решить вопрос передачи медиаданных пользователям БС. Эта работа призвана решить следующие проблемы:

обнаружение медиаданных;

управление сессиями медиаданных;

механизм распространения медиаданных;

управление QoS/QoE;

личное пространство и безопасность.

9.2.7 Архитектура Будущих сетей: состав сервиса

Данный BB должен представить архитектуру состава сервиса для БС. Эта работа призвана решить следующие проблемы:

сервисно-ориентированная архитектура (SOA);

разделение и перекомпоновка сервисов;

возможность повторного конфигурирования и определение местоположения сервиса;

маршрутизация сервиса;

динамическая адаптация.

9.2.8 Архитектура Будущих сетей: федерация

Данный BB должен решить вопрос инкорпорирования многочисленных гетерогенных сетей в единую будущую сеть. Эта работа призвана решить следующие проблемы:

глобальное пространство для имен;

сервисы метаданных;

автономность сайта;

сбор и обмен ресурсами;

разделение аутентификации и авторизации.

9.2.9 Протоколы для Будущих сетей

На следующем этапе необходимо разработать набор конкретных протоколов для разработанной архитектуры БС. Эта работа должна быть выполнена в качестве нового проекта в ОТК 1/СК 6.

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

протоколы для маршрутизации и коммутации данных и пакетов управления в БС;

взаимодействие протоколов маршрутизации/коммутации с гетерогенными базовыми технологиями доступа;

сквозные протоколы передачи данных для обработки и управления пользовательскими данными;

протоколы для конкретных приложений.

Приложение A (справочное)

ОБЩАЯ КОНЦЕПЦИЯ БУДУЩИХ СЕТЕЙ

Общая концепция БС может быть описана следующим образом:

будущая сеть — это сеть будущего, которая разрабатывается «с нуля» с поэтапным подходом к проектированию. Следует обратить внимание на то, что подход «с нуля» понимается как принцип проектирования, а не аспект внедрения;

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

будущая сеть не должна зависеть от существующих технологий и решений;

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

Рисунок A.1 иллюстрирует общую концептуальную модель БС. Концептуальная модель БС описывается в двух аспектах: сетевая архитектура и сервисная архитектура.

Сетевая архитектура — это структура коммуникационной сети для определения физических компонентов сети и их функциональной организации и конфигурации, принципов сети и процедур работы, а также форматов данных, используемых в ее работе. Сетевая архитектура БС определяется тем, как сеть использует пакет компонентов архитектуры, таких как конструктивные элементы (BB), а не традиционный пакет Интернет-протоколов TCP/IP. Такие BB могут включать в себя следующие компоненты архитектуры, но не все из перечисленных:

присвоение имен и адресов;

маршрутизация;

борьба со спамом, безопасность;

QoS/QoE;

энергоэффективность;

управление.

Кроме того, виртуализация сети предоставляет возможности для внедрения пакета гетерогенных архитектурных компонентов в рамках единой интегрированной БС-архитектуры.

Сервисная архитектура — это конструкция коммуникационного сервиса. Сервисная архитектура БС также представляет собой набор сервисов и приложений, таких как BB. Эти сервисы обмениваются данными друг с другом. Данные BB могут включать в себя следующие сервисные компоненты, но не все из перечисленных:

контекстно-ориентированный подход;

сервисы, связанные с данными;

содержание сервиса;

Интернет вещей;

вещание и медиаданные;

семантически структурированная сеть.

Рисунок A.1 — Общая концепция Будущих сетей

Приложение B (справочное)

АНАЛИЗ РАЗЛИЧИЙ

В настоящем приложении B обсуждаются различия между существующими стандартами и концепцией БС.

Соответствующие технологии и архитектура для анализа различий следующие:

IETF Интернет на основе IPv6 [18].

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

ITU-T (сектор по стандартизации телекоммуникаций в составе союза ITU) предпринимает усилия по разработке NGN и публикует весьма важные результаты по NGN, которые описывают требования и необходимые функции. NGN, выпуск 1 и текущая версия выпуска 2 охватывают широкую область технологий, включая межсетевые операции, взаимодействие с сетями, не относящимися к NGN, транспортные соединения, управление медиаресурсами, качество сервиса, безопасность, управление сетью, открытую среду сервисов, мультимедийную подсистему, учет и выставление счетов и т.д. Будет обеспечено подключение всех традиционных сетей в NGN и поддержка беспроблемных сервисов для цифровых приложений будущего.

NGN может в дальнейшем определяться следующими основными характеристиками. Эти характеристики можно сравнить с целями проектирования БС [16, 17]:

пакетная передача с использованием IP-адреса;

разделение функций управления между возможностями канала, вызовом/сеансом и приложением/сервисом;

отделение предоставления сервисов от транспорта и предоставление открытых интерфейсов;

взаимодействие с традиционными сетями через открытые интерфейсы;

неограниченный доступ пользователей к различным провайдерам услуг;

различные схемы идентификации;

унифицированные характеристики для сервиса, выбранного пользователем;

конвергентные сервисы между стационарной/мобильной сетью;

независимость функций, связанных с сервисом, от базовых транспортных технологий;

поддержка нескольких технологий «последней мили»;

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

Если сопоставить список целей при проектировании БС и общих требований к характеристикам NGN, то можно заметить, что они очень похожи друг на друга, и это можно рассматривать как основные футуристические задачи сети будущего.

Основные отличия заключаются в том, что в настоящее время для БС не предполагается какая-либо сетевая архитектура или технология коммутации пакетов на основе IP, тогда как в основу NGN положены IP-сети и пакетная передача. Кроме того, исследования по NGN основаны на краткосрочном/среднесрочном эволюционном подходе, поэтому технологии NGN могут быть преобразованы из существующей IP-сети. При этом БС основывается на проектировании «с нуля» с долгосрочным революционным подходом.

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

Тем временем были поставлены некоторые вопросы по текущей сети. Они возникли из-за «агонии» сегодняшнего Интернета, которая указывает на некоторые непредвиденные последствия.

• Правильно ли сохранить текущую роль Интернет-адреса, который определяет то, кем вы являетесь, где вы находитесь, и как должны доставляться пакеты?
• Создает ли текущий механизм адресации большие проблемы для поддержки мобильности?
• Является ли спам неизбежным следствием доставки почты по Интернету?
• Почему идентификация и доверие конечных пользователей становятся проблемой?
• Почему измерение показателя QoS оказалось коммерчески неудачным?
• Способен ли хост-ориентированный Интернет плавно перейти в Интернет, ориентированный на использование данных?

Считается, что NGN разрабатывается для поддержки беспроблемной мобильности, высокой безопасности, QoS и так далее, что включает в себя все эти проблемы. Тем не менее, пока неясно, были ли эти проблемы неизбежны, и не перейдут ли они в NGN. Таким образом необходимы исследования, чтобы найти ответы и внести вклад в разработку за пределами NGN или других будущих проектов.

B.2 Интернет на основе IPv6 против БС (особенности)

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

Требования и цели разработки для IPv6 были следующими [18]:

количество адресов;

эффективность в маршрутизаторах с низкой и очень высокой пропускной способностью;

безопасность;

мобильность;

автоматическая конфигурация;

беспроблемный переход.

Как следует из сказанного выше, IPv6 был разработан как дополнение к существующему IP, IPv4, поэтому главной задачей IPv4 было унаследовать текущие характеристики IP. Таким образом, когда рассматривается развертывание и миграция с текущего IPv4, IPv6 может стать лучшим подходом к сети будущего. Некоторые исследователи рассматривают IPv6 как одно из предлагаемых решений для БС. Однако IPv6 имеет такие же ограничения, как IPv4, и IPv6, не может выполнить все требования к БС.

Если сравнить список целей проектирования БС и общих требований с характеристиками IPv6, то станет ясно, что они очень схожи в некоторых позициях, но многие другие новые требования в IPv6 по-прежнему отсутствуют, например гетерогенность, возможность переконфигурации, распознавание контекста, ориентированность на данные, сетевая виртуализация, экономические стимулы. На самом деле эти новые требования не могут быть удовлетворены без новой попытки перепроектирования.

БИБЛИОГРАФИЯ

[1]	A. Feldmann, «Internet Clean-Slate Design: What and Why?,» ACM SIGCOMM Computer Communication Review, Vol. 37, No. 3., pp 59 — 64, 2007 (Фельдман А. Проектирование Интернета «с нуля»: Что и почему?, ACM SIGCOMM//Обзор по компьютерным коммуникациям — Т. 37 — № 3., С. 59 — 64, 2007)
[2]	Standford Univ, «Clean Slate Designs for the Internet», http://cleanslate.stanford.edu (Университет Стэнфорда «Проектирование Интернета „с нуля“», http://cleanslate.stanford.edu)
[3]	ITU-T Draft Recommendation Y.Fnvirt, Framework of Network Virtualization for Future Networks, (Work-in-Progress), 2011 (Проект рекомендаций ITU-T, Y. Fnvirt, Схема виртуализации сети для Future Network (исследование продолжается), 2011 г.)
[4]	T. Anderson et al, «Overcoming the Internet Impasse through Virtualization,» IEEE Computer, 2005 (Андерсон и др. Вывод Интернета из тупика через виртуализацию//IEEE Computer, 2005)
[5]	Wikipedia, http://www.wikipedia.com (Википедия, http://www.wikipedia.com)
[6]	ITU-T Recommendation Y.2001 (12/2004), General overview of NGN, 2004 (Рекомендация ITU-T, 2001 (12/2004), Общий обзор NGN, 2004)
[7]	GENI Research Plan GDD-06-28 Version 4.5 of April 23, 2007 (План исследований GENI GDD-06-28, Версия 4.5 от 23 апреля, 2007)
[8]	New Generation Network Architecture AKARI Conceptual Design (ver 1.1), http://akariproject.nict.go.jp/eng/index2.htm, October 2008 (Сеть нового поколения, архитектура AKARI, концептуальный дизайн (вер. 1.1), http://akariproject.nict.go.jp/eng/index2.htm, октябрь 2008)
[9]	FP7 FIRE White Paper, 2009, FIRE: Future Internet Research and Experimentation, 2009 (Экспертный доклад FP7 FIRE, 2009, FIRE: эксперименты и исследования Future Internet, 2009)
[10]	Korean Future Internet R&D Strategies, 2011 (Стратегии НиОКР Интернета будущего в Корее, 2011)
[11]	The future Internet: the operator's vision, Eurescom P1657, EDIN 0546-1657, 2007.11 (Будущий интернет: видение оператора, Eurescom P1657, EDIN 0546-1657, 2007.11)
[12]	Internet Engineering Task Force (IETF), http://www.ietf.org (Инженерная рабочая группа Интернета (IETF), http://www.ietf.org)
[13]	Internet Research Task Force (IRTF), http://www.irtf.org (Инженерная рабочая группа Интернета (IRTF), http://www.ietf.org)
[14]	ITU-T FG-FN (Focus Group on Future Networks), http://www.itu.int/en/ITU-T/focusgroups/fn/I (TU-T FG-FN (Фокус-группа по Будущим сетям), http://www.itu.int/en/ITU-T/focusgroups/fn/)
[15]	EC FIArch Group, Fundamental Limitations of current Internet and the path to Future Internet, 2011 (EC FIArch Group, Фундаментальные ограничения существующего Интернета и путь к Интернету будущего, 2011)
[16]	ITU-T Recommendation Y.2011 (2004), General principles and general reference model for Next Generation Networks, 2004 (Рекомендация ITU-T, 2001 (2004) «Общие принципы и общая эталонная модель для сетей следующего поколения», 2004)
[17]	ITU-T Recommendation Y.2601 (2006), Fundamental characteristics and requirements of future packet-based networks, 2006 (Рекомендация ITU-T Y.2601 (2006) «Основные характеристики и требования будущих сетей на основе пакетов», 2006)
[18]	S. Deering, R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998 (Диринг С., Хинден Р. Интернет-протокол, версия 6 (IPv6), RFC 2460, декабрь 1998)
[19]	T. Koponen et al., «A data-oriented (and beyond) network architecture,» In Proc, of ACM SIGCOMM 07, 2007 (Копонен Т. и др. Ориентированная на данные (и за их пределы) сетевая архитектура//In Proc. ACM SIGCOMM 07, 2007)
[20]	Future Internet of Creative Media. Report of a workshop organized by the Networked Media Systems Unit of the Information Society and Media, Directorate General of the European Commission. January, 2008 (Будущий интернет творческих СМИ. Доклад на семинаре, организованном Группой сетевых медиа-систем Генерального директората по вопросам информационного общества и средств массовой информации Европейской комиссии. — Январь, 2008)
[21]	Future Internet and NGN Design requirements and principles for a Future Media and 3D Internet. Created by «Future Media and 3D Internet Task Force». Coordinated and supported by the Networked Media Unit of the DG Information Society and Media of the European Commission. Feb 2009 (Требования к Будущему интернету и NGN-дизайну для СМИ будущего и 3D-Интернета. Разработка «Группы по решению проблем СМИ будущего и 3D-Интернета» (Координируется и поддерживается Группой сетевых медиа-систем Генерального директората по вопросам информационного общества и средств массовой информации Европейской комиссии). — Февраль, 2009)
[22]	Elisabetta Di Nitto, Dimka Karastoyanova, Andreas Metzger, Michael Parkin, Marco Pistore, Klaus Pohl, Fabrizio Silvestri, Willem-Jan Van den Heuvel, «S-Cube: Addressing Multidisciplinary Research Challenges for the Internet of Services», Towards the Future Internet: a European Research Perspective. IOS Press, Amsterdam (Ди Нито Е., Карастоянова Д., Мецгер А., Паркин М., Писторе М., Пол К., Силвестри Ф., Ван Ден Хевел В.: Решение многодисциплинарных исследовательских задач для Интернета услуг: Навстречу Интернету будущего: европейская перспектива исследований//IOS Press, Амстердам)
[23]	ITU-T Recommendation Y.3001 (2011), Future Networks: Objectives and Design Goals, 2011 (Рекомендация ITU-T Y.3001 (2011) «Сети будущего: Цели и задачи проекта», 2011)

УДК 004.75, 004.77:006.354	ОКС 35.100.30
Ключевые слова: конкурентоспособность, безопасность работ и услуг

---